Pre-Planning/Pre-work required for Storage Migrations in Unix.
In this post I will try to make a base which is used in Storage Migrations in Unix. I will be taking this post as a base and will post the storage migrations posts with reference to this one. Here I will be considering Solaris OS and EMC Storage (DMX). We will see how to move older storage DMX to newer EMC storage VMAX.
Before proceeding with the Storage Migrations from Storage side we have to make our OS at best acceptable level so that new storage will be completely compatible with the OS levels. Below are the steps which we have to follow in order to find our OS specifications w.r.t new storage.
1.) Run EMCgrub and provide the output file to EMC storage so that they will provide you with the report and acceptable OS package/patch levels which must be required in order to move your older storage to new one.
EMCgrab –> Its same as that of running explorer (in SUN). Its is just a data collector script which can be easily available at EMC site or can be taken while raising a case with EMC. It will generate an output file which contains your running OS level information. We need to upload this file at EMC site for there analysis. EMC guys will then compare the OS specification with the required OS specification which your OS must own for successful Migration to new storage.
2.) The EMC provide us with the detailed report with all the requirements which needs to be fulfilled from OS side. This report mainly contain the below information in the form of report with RED mark:
a) OS Kernel patch level, which also contains all of the required Storage patches (The OS must be at certain specific kernel patch level, so patching is required).
b) EMC powerpath package level (EMCpowerpath version should be upgraded to the latest one or upto specific level as per new storage compatibility)
c) EMC symmetrix package level (EMC symmetrix version should be upgraded to the latest one or upto specific level as per new storage compatibility)
d) HBA Firmware and Driver version (Depending upon HBA type (either LPFC or Emulex) firmware and driver versions should also be upgraded upto storage compatible level)
e) Vxvm (veritas volume manager) & VCS/SUN Clusters (Veritas Clusters) versions (VXVM/VCS/SUN clusters version should be storage compatible else these should also be upgraded before proceeding with the Storage migration).
Before moving ahead with storage migrations our OS specification should be completely compatible with the new storage. So above upgrades should be performed before actually moving to physical storage movement.
In our upcoming posts we will post these pre steps and then will try to show the methods used for actual storage movements from older one to newer one.
Note: We have already posted the Kernel Patching (manual and via Liveupgrade) procedure. You can go through them for any patching related queries. Below are the links which you can go through:
http://gurkulindia.com/main/2011/10/solaris-patching-using-live-upgrade/ —–> using Liveupgrade