2011-03-15 08:45 AM
I have an exchange migration that is fairly large, data is located on an HP storage migrating to Netapp Boxes.
If Anyone has tips or gotchas to share, it will be very much appreciated.
Solved! SEE THE SOLUTION
2011-03-15 01:35 PM
You can use SME to migrate the database. There is nothing special there. Since we use file copy to migrate the database, and the database is fairly large, it will take a while for the migration to complete. You may also choose to migrate one SG at a time so you can easily isolate the issue if any.
2012-07-24 05:19 AM
Hi , I have the same task but difference is : Databases are stored in IBM SAN storage and exchange is on VMs , i want to migrate DBs to NetApp via SME , since I m new in this task I will be very appreciate if you share your knowledge with me . I need to know what the requirements and process I have to take.
2012-07-24 05:27 AM
Actually I'd do this a completely different way. If you are planning an Exchange 2010 migration I would set up a fresh DAG copy connected to the NetApp storage and then allow Exchange to create the replica. Then you can make the copy attached to the NetApp storage the active copy. That eliminates any downtime. You only need one 'swing server' at a time and if you're virtualized there's no problem even with the swing server. If you're running 2007 SCC you can set up a new cluster and then do mailbox moves. That might be a little less than desirable for the largest mailboxes. If you are on 2007 CCR you can essentially follow the process I mentioned for the 2010 DAG.
You need to look at connecting one server to two storage systems and all of the restrictions, albeit temporary, involved. It's easier to keep the servers connected to only one storage system at a time.
What version of Exchange is it you're running?
2012-07-24 05:58 AM
Thanks marnold for the details .
The version of exchange we are using is 2010 .
here is the scenario : exchange 2010 was installed on VM , and the VM's hypervisor is installed on the local blade servers , exchange Data bases are in IBM SAN storage . we want to move the exchange DBs and logs from IBM to the NetApp. as far as I understood we have the option of providing one LUN from NetApp to ESX and moving the vmdk (VM that has exchange server on it) to NetApp , then installing snap drive and snapmanager for exchange on that server then creating LUN with snap drive and providing them into SME for data migration. (this is the layout but im not sure about the process details) so the question is that this scenario is correct or I have to approach a different process for this scenario ? if its correct what are the steps , limitations and prerequisites ? if its wrong then what should we do?
2012-07-24 06:05 AM
Since you're on 2010 you are in good shape. If you are involved in moving the VMDK that holds the OS and Exchange binaries you need to shut the server down and move it. That means you're experiencing downtime whilst you move, or you are moving a DAG copy and being in a lowered HA state. I would advise you to set up a new server connected to NetApp storage and create replicas of all the databases. That is a zero downtime operation. When you're synced up you can activate the DAG copy on the NetApp storage and then decommission the copies on the other storage.
Does that make sense and if so, is it possible for you to do that or do you have some constraint on the ESX environment that would prevent you setting some extra servers up?
2012-07-24 06:17 AM
Thanks a lot marnold for your supports ,
It seems your way is easier , but to do so , what would be my requirements? do I engage SME for this process? if we create new server in VM but connected to NetApp and do replica as what you mentioned , would all the DBs LUN and logs which were connected to my source will migrate to NetApp automatically? do I need any downtime here? would you recommend a document or TR which has more details about what you just said?
2012-07-24 06:24 AM
You would not need to use SME for the process. Part of the Exchange 2010 process is that it sets up a new replica and it does the file by file copy from the current database to the new location. Once they're in sync both will be running in unison and the copy that is active will be sending logs to the other copy or copies (you can have up to 16 copies of the same database across 16 different servers. Using the DAG copy process at the application level means there will be zero downtime.
Take a peek at:
http://www.exchange-genie.com/2009/04/database-availability-group-dag-exchange-2010/ to understand a bit more on DAGs, how they work and why there isn't any downtime.