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

http://gurkulindia.com/main/2011/09/general-procedure-for-kernel-patching-in-solaris/  —–> Manual Procedure

Yogesh Raheja

Yogesh working as a Consultant in Unix Engineering by profession. And he has multiple years experience in Solaris, Linux , AIX and Veritas Administration. He has been certified for SCSA9, SCSA10, SCNA10, VXVM, VCS, ITILv3. He is very much passionate about sharing his knowledge with others. Specialties: Expertize in Unix/Solaris Server, Linux (RHEL), AIX, Veritas Volume Manager, ZFS, Liveupgrades, Storage Migrations, Cluster deployment (VCS and HACMP) and administration and upgrade on Banking, Telecom, IT Infrastructure, and Hosting Services.

3 Responses

  1. Ramdev Ramdev says:

    Good One Yogesh.

    As part of step 2.e, I want to add a point : Dont forget to get Veritas license for new version before proceeding for any upgrade, ofcourse there is a workaround if we dont have it in handy i.e. applying demo license.

    Warning: Just for headsup, there are cases that SA upgrade VxVM on Production servers with demo license as quickfix to continue with the migration plan and later forget to apply the original license to the server, which inturn causes VxVM fails the Production server during some unexpected time due to expired demo license.

  1. September 17, 2015

    […] Read – Pre-Planning/Pre-work required for Storage Migrations in Unix. […]

  2. July 22, 2016

    […] Read – Pre-Planning/Pre-work required for Storage Migrations in Unix. […]

What is in your mind, about this post ? Leave a Reply

Close
  Our next learning article is ready, subscribe it in your email

What is your Learning Goal for Next Six Months ? Talk to us