Enterprise Unix system administrators will always have two challenges, every day, to deal with … the first one is providing sufficient Computing resources for the business applications and the second one is providing sufficient storage for the business applications.We will discuss about managing computing resources( CPU and Memory) in different post, in this post we will be focusing on the SAN storage requests that an enterprise system administrator has to handle in his every day life.
Why SAN?
Because it is the common trend for most of Organisations to use SAN ( Storage area Networking) as an option to deal with the on-demand requests of the storage.
Note: I am using the word “Enterprise”, just to give you an idea that the environment is composed of heterogeneous technologies in Server hardware(HP / SUN / IBM ) , operating systems( Solaris / Linux / Windows) and applications (Databases / Middle ware / third party).
Types of Storage Requests related to SAN
1. New SAN Storage Allocation for newly build Servers2. Additional SAN storage allocation for existing Servers
3. Unused Storage Reclaim for existing Servers
4. Storage migration from one SAN storage device to another
1. New SAN Storage Allocation for Newly Build Servers
These requests usually arise after installing a new server in the environment with an operating systems, and before configuring the applications / database in that server.
Steps Involved in Configuring SAN Storage to New Server
1. Finding Storage Requirement
- Size of the Storage Required
- Type of Redundancy required – RAID 5 or RAID 0
2. Install Server with SAN Storage STACK
- Installing HBA Card drivers – Qlogic , Emulex , SUN native
- Installing Powerpath software - EMC Powerpath, STMS , MPXIO, SAS …etc
- Disk Management / Volume Management
3. SAN Storage Allocation
- Zoning
- Lun Masking
- Providing LUN number to System Administrators for Server Side Configuration
4. Recognize and Configure storage from the Server Operating System
- Detect and Configure New Storage LUNs from the Operating system – either dynamically or with reconfiguration reboot.
- Configure Server to use all available fiber paths to the SAN Storage
- Label the LUN Devices into local operating system
- Volume Management on New Storage LUNS – using SVM or VxVM
- Creating Filesystems on New Storage LUNS ( Note : Some Database applications like Sybase wont’ require filesystems to be created on all storage devices, it will raw deviced directly for the database operations)
- Creating Mount points for the new filesystems and configure them to automount during the boot.
There are different procedures involved at this step depending on the Storage device, Operating System and Volume manager. For now I am not discussing that part here, but will be posting the actual implementation steps for different scenarios in my next posts
Below is the diagram where you can see a complete picture of how the SAN allocation happens to a server , and how the storage will be accessed and configured from the server side.
2. Additional SAN Storage Allocation for Existing Servers
These requests usually arise when ever an existing server, configured with storage, has reached it’s storage thresh-hold (for example : the condition that 80% of total allocated storage utilized )
Steps Involved in Configuring Additional SAN Storage to Existing Server
1. SAN Storage Allocation- Zoning
- Lun Masking
- Providing LUN number to System Administrators for Server Side Configuration
2. Recognize and Configure storage from the Server Operating System
- Detect and Configure New Storage LUNs from the Operating system – either dynamically or with reconfiguration reboot.
- Configure Server to use all available fiber paths to the SAN Storage
- Label the LUN Devices into local operating system
- Volume Management on New Storage LUNS – using SVM or VxVM
- Creating Filesystems on New Storage LUNS ( Note : Some Database applications like Sybase wont’ require filesystems to be created on all storage devices, it will raw deviced directly for the database operations)
- Creating Mount points for the new filesystems and configure them to automount during the boot.
3. Reclaiming Unused Storage from Existing Servers
There are two situation that initiates the Storage reclaim requests , the first one is Server decommission ( means Server going to be removed from the network) and the second one is Specific application in the server which is using external storage has decommissioned but the server is still alive in the network and supporting other applications.
Steps involved in Reclaiming Storage
1. Unconfigure Storage from the server
- Unmount all related filesystems which are residing on top of the storage that is going to reclaim.
- Detach the Storage Disks from any of the existing volumes
- Clear the devices identification ..example : Veritas disk unsetup using vxdiskunsetup …etc
- Zone changes
- Changes to Lun-masking
- Reconfigure storage multipathing software to cleanup the storage entries those are reclaimed
- Server Operating system that use dynamic reconfiguration during the initial detection of the storage disks, will keep the information inside operating system configuration and it is possible that Operating systems complain with storage errors ( device not found) once the storage completely removed from this server. Hence it is always recommended to perform reconfiguration reboot after the storage reclaim in order to allow operating system to adjust it’s configuration according to the existing Storage connections.
4. Migrating Storage from One Storage Device to Another Device
These Requests normally arise when ever the existing storage not able to meet the on-going storage demand or the existing Storage have reached to End of life support from it’s vendor. And these could also arise if the organisation plans to move from high expensive storage to low expensive storage.
There are two types of migration techniques are in practice now a days , they are
1. Host Based Storage Migration
In host based storage migration, it is system administrator responsibility to replicate the existing data from the old storage to new storage once the Storage allocated new storage to the system.
And in this migration Operating system will see both new storage LUNs and old Storage Luns simultaneously for the period of that data replication happening from Operating System Side.
Once the Replication completes, the system administrator will follow the above storage reclaim procedure to release old storage LUNs from the operating system.
2.Storage side Migration
In Storage side migration , data replication from old storage to new storage will be taken care by the storage team. Once the data replicated system administration will make reconfiguration reboot to the server so that the operating system recognizes the storage disks from the new storage devices using the same existing storage paths.
