Wiki code for Data Migration Manager

Hide Line numbers
1: ==News!
2: 
3: *07/08 Source code drop #2 is now available below in the Source Code section.
4: 
5: *04/23 DMM discussed on [[Storage Stop>>http://blogs.sun.com/storage]] during the Q/A session at the FAST ’08 OpenSolaris BoF (Feb 25-29, San Jose CA)
6: *04/18/08  First DMM source code drop is now available!   See Source Code below.
7:   We also will be debuting the DMM blog shortly where we can move discussion about DMM and migration in general to that forum.  Stay tuned!
8: *03/13/08  We’re here!!
9: *01/23/09  This project is no longer resourced so we’re temporarily on hiatus.
10: 
11: 
12: === Welcome to DMM
13: 
14: And welcome to the evolving DMM project page!
15: 
16: Data Migration Manager (DMM) is a tool which facilitates the movement of file systems from one platform to another over the NFS and/or CIFS protocols.    Why not simply use tar or cpio and cp for this?   Those work fine for small file systems, say 10Gb, but fall short when it comes to larger file systems and in general ~-- answers to the 3 ’W’ questions.  What are those?
17: 
18: // //Where exactly is file X at this moment?*
19: // //When can I resume reading and writing to it?*
20: // //What happens if a failure occurs while those programs are running?*
21: 
22: DMM answers all three of these questions with a simple answer.  It’s available immediately on the target platform that you specified.  You can read and write to it to your heart’s content and in the unlikely event there were link failures or crashes along the way, each and every byte from the source along with any newly written bytes are all safely tucked away in a Solaris file system.
23: 
24: DMM is designed to be the solution you trust when you have large amounts of data to move that will take days to complete.
25: 
26: ====Key DMM Features
27: 
28: * Allows read/write access to file system content while a migration is running.
29: * Migrates one or more file systems from source platform A to target B.
30: * Migrates files and related metadata over the CIFS and NFS protocols.
31: * Uses a phased-commit approach to ensure that data is protected from failures.
32: * Very mindful of its presence ~-- tries very hard to make sure that an application cannot tell that it is there.
33: * Easy to use GUI or command line interface.
34: * Event-driven scheduling allows a migration to consume more resources at off-hours, etc.
35: * Migrates files in the background while still responding to on-demand requests made by active processes.
36: * Limited policy allows influence over the order of files to be migrated asynchronously.
37: 
38: ===High-level Architectural Overview
39: 
40: DMM is divided into two major pieces, the user-space portions and a kernel portion.
41: 
42: ====User-Space
43: 
44: The DMM user space is a collection of processes which scales to the number of concurrent migrations running at any given time.  There is a master migration process which controls each set of tasks representing a file system migration.
45: This master talks to the GUI or CLI and has overall responsibility for operations.
46: 
47: A central component of the user-space environment is the database that is the brain of DMM.   DMM is using mySQL 5.1 for its first release.   This database tracks among other things, directories and files to be moved as well as the overall state of each migration.
48: 
49: Each file system that is being migrated has a set of processes monitoring and controlling that migration.  Two major things are going on here during this time:
50: *Events are being posted via the
51:  [[Solaris Doors>>attach:Community Group edu.WebHome@chap2.6IPC2.pdf]]
52: interface from the DMM kernel module.  These events indicate that files are being examined or read/written to by processes running on the target.   These are high-priority things that get attention immediately.
53: *When events from the kernel have slowed down to the point where DMM can do other things, it is looking through the database for files to be moved.  Some of these may have been specified by the user thorough the policy component of the GUI to be moved at a higher priority.
54: 
55: At some point, all the files from the read-only source have been migrated and the migration process packs up and goes home.  The file system on the target is now fully operational with no remaining ties to DMM.
56: 
57: ====Kernel
58: 
59: DMM has a lightweight kernel component designed to interpose between the virtual file system operational layer (VOP) and the file system itself.  For each file system being migrated, DMM attaches a [[Solaris FEM>>Community Group arc.172]] monitor to each vnode that arises for that file system.  That’s our hook ~-- //Whaa Haa Ha!! we’re now in control and rule the world!//       Errr, never mind..
60: 
61: Each vnode operation (VOP~_READ, VOP~_GETATTR, etc) likely triggers an event which is routed to the DMM user-space portion via one of two Solaris Doors that we established to user-space for that file system’s migration.   DMM’s user-space then does all the work of
62: determining how to proceed at this point.  It may decide to bring the whole file across if it’s pretty small, it may decide to just bring across the data or information being requested on that call.  We don’t want to hold up the application too much so we’ll be pretty smart about this part.
63: 
64: The key here is we can hold the application inside
65: the kernel while we retrieve the data.  That is the heart of what DMM is all about.
66: 
67: Remember that database we talked about above (our brain)?   Let’s say a file is being deleted before we’ve brought it across.
68: Worse yet, let’s say it’s being renamed.  Our event to user-space may be one that indicates that we’re about to
69: delete or rename the file.  Once we get the okey-dokey that the user-space DMM has logged this intent in our database, we’ll perform the VOP~_RENAME for example.  We’ll update the DB when we’re done with that portion, etc.
70: This is the phased commit approach we talked about above in the features section.  We //have// to assume that the target host could crash at any moment (as unlikely as that is..)
71: 
72: We’re absolutely paranoid in DMM about ever losing a byte of a file, ever.
73: 
74: Once any file is migrated, we remove the FEM monitor from its vnode and all future dealings that the application has with that file are handled directly by the file system.
75: 
76: === Source Code
77: 
78: Our latest source code drop can be obtained here [[Latest DMM Source code>>attach:dmmdrop2.tgz]]
79: 
80: It’s starting to take shape nicely.  Since we’re still very actively developing this, you’ll see incremental changes all over the place.  Most notably, the code has been restructured to match OpenSolaris which is where it will eventually reside.
81: 
82: It is operational but not very easy to use yet.  You can take this code base, overlay it on an OpenSolaris source tree, decend to the dmm directory and build it.   If you build all of OpenSolaris, at this point DMM will not be built.
83: 
84: Our previous source code drop can be obtained here [[Previous DMM Source code>>attach:dmmdrop1.tgz]]
85: 
86: ===Related Projects
87: 
88: [[CIFS Client>>Project smbfs.WebHome]]
89:
OpenSolaris

Top Menu

Wiki code for Data Migration Manager

Search

Collectives

Community Group

Project

User Group

Subsites

Project dmm Pages
