Subscribe

SnapDrive for Unix (SDU)

Snapdrive for Unix:

SDU ( Snapdrive for Unix) is an tool for storage provisioning and storage management from host side.

Without SDU , an administrator has to do tedious job for creating lun's on the storage system, exposed them on the host, creating file system on the exposed lun's and mount the filesystem on the host, such that applications can make use of the networked storage. With snapdrive its a single line command for the storage administrator irrespective of the host volume manager and filesystem knowledge.

SDU uses NetApp snapshot technology for data backup and recovery.

Re: SnapDrive for Unix (SDU)

To add more to what Nikhil has mentioned, I must say that SDU is extremely useful tool

for the server admins. It works as a bridge between the server and the storage array (without

much involvement of storage admins).

To provide a feel of how tedious (which Nikhil has already cited above) it would be for a server

admin in absence of SDU, let me illustrate a bit further.


In absence of SDU:

Every time when there is a requirement for some amount of storage on a server (say, for

some database applications), below sequence of tedious steps needs to be followed:

(1) The server admin requests the storage admin to create a LUN of a given size for the server.

(2) The storage admin creates a LUN on a storage array volume.

(3) The storage admin maps the LUN to the initiator (iSCSI or FCP).

(4) The server admin then runs a scsi scan command (e.g. 'ioscan' in HPUX, 'cfgmgr' in AIX,

'devfsadm' in Solaris, 'iscsi reload' for Linux (iSCSI), etc.). This will discover the device(s)

connected to the newly created LUN. Or in other words, the scsi scan command will map the LUN

to a device-file through which the server admin can perform I/O on the LUN.

(5a) In some cases, the server admin needs to create a file-system on top of the discovered device-file,

and then to mount the file-system in order to perform an I/O.

(5b) Again in some cases, the server admin might need to bring the LUN under Volume Manger control,

i.e. the admin might need to create a diskgroup on top of the device-files. In addition to that,

he/she might need to create a host-volume (logical volume) on the diskgroup, and also if needed,

on top of the host-volume a file-system has to be created and then mounted.

(6) And just imagine, the complexity if the server admin needs to create one more LUN and to bring the same

under an already existing diskgroup, i.e. resizing a diskgroup by adding a new LUN.

(7) Also, if a LUN needs to be deleted (along with its over-lying host-side entities), similar sequence

of afore-said steps needs to be followed (in the reverse direction).


Additional steps in case of backup and restore (in absence of SDU):

(8) When the server admin needs to create a backup of the LUN data, he/she needs to request the same

to the storage admin to perform a backup create operation on the storage array.

[Note: This does not ensure the snapshot to contain a host-side consistent data (because I/O might

be still running on the device-file(s) mapped to the LUN).]

(9) Also, when the server admin needs to restore the LUN data,he/she again needs to request the storage

admin to perform the backup restore process.

[Note: This restore does not restore the host-side entities like diskgroup, host-volume and file-system

mount-point, if changed or deleted. The server admin needs to re-create these entities on top of the

LUN data, and ensuring data integrity in this case is very complicated].

We can easily realize the complexities or the disadvantages of the above model:

(i ) The time required to properly sequence the steps of manual intervention is quite high.

(ii) The storage admin becomes a bottle-neck for every storage operation (and also for backup create and

restore operations).

(iii) One can not ensure the host-side data consistency during backup creation and restoration (unless

appropriate measures are explicitly taken on the server).

Now I will tell how SDU comes into picture and makes this scenario much simpler.


In presence of SDU:

For creation of storage through SDU, only the following steps are required:

(1) The storage admin initially creates volume(s) of some specific size on the storage array, and allots

the same for the server (or for some server application on the server). And thus storage admin does

not become a bottle-neck during every LUN storage operation.

(2) The server admin issues a single command (with specific options depending on the case) which will

internally take care of LUN creation, LUN-to-initiator mapping, scsi scan/device discovery, and finally

if needed, the creation of diskgroup, host-volume and file-system mount points.

(3) If the server admin needs to resize a diskgroup, he just needs to issue a single CLI and that's all.

(4) Also, deleting the storages is also just executing a simple SDU CLI.


Backup and restore (in presence of SDU):

(5) The server admin will issue a single command of SDU to create the backup. Also, SDU ensures that the

host-side data is consistent (as it will freeze the IO) during backup creation.

(6) Similarly, in order to restore the backup, the server admin just needs to execute a SDU CLI. This will

not only take care of LUN data restoration, but the host-side entities also.


Still more ... (in presence of SDU):

(7) If the server admin needs a copy of the backup data, this can be done very efficiently with just one

command of SDU. The copy can be created on the server from which the backup was created, and/or also

on a different server. The copy will infact create a copy of the LUN and also the host-side entities

(if applicable).

(8) The server can execute SDU CLI get the list of backups, their contents and properties, etc. without even

logging into the storage array.

(9) SDU CLI can display all the LUNs discovered on the server and also the over-lying Volume Manager entities

and file-system mount points.

(10) There are more functionalities like exporting or importing of host-side entities, mapping-unmapping of

already created LUN, discovery-undiscovery of already mapped LUN, and so on.

The disadvantages of traditional model (in absence of SDU) are clearly resolved by SDU (as shown in the above

list). However, in addition to these, there are some innovative measures taken in SDU which makes it extremely

advanced and useful tool:

(i ) SDU works on most of the popular flavours of Unix. The list includes IBM AIX, HPUX, Solaris, RedHat

Linux and SUSE Linux.

(ii) It provides unique virtualization of the platforms, protocols (iSCSI and FCP) and Volume-Manager

(NativeLVM, Veritas Volume Manager, etc). It is because, SDU CLIs make the underlying platforms,

protocols, volume-managers transparent to the user. So, the user need not worry about the inhrenet

diversities and complexities among these platforms, protocols and volume managers.

(iii) It supports various multipathing solutions and clustering softwares.

(iv) It also provides secure communication faclity with the storage array through 'https'.

You just keep using it and you will discover more fun with SDU.

Re: SnapDrive for Unix (SDU)

Here is a very good technical report (by Anil Degwekar) on how SnapMirror can be used with SDU:

http://media.netapp.com/documents/tr_3611.pdf

Currently SDU does not have any specific CLI through which disaster recovery can be acheived directly from the SnapMirror destination storage system. Afore-said technical report shows how the mirrored snapshot can be connected to the host using SDU with the addition of a few intermediate manual steps.

Re: SnapDrive for Unix (SDU)

hi

Can we do a single file -restoration using SDU in a SAN environment instead of having to restore the entire volume if this is possible can i know the steps and also can i have the same mount points and configuration if try to mount a snapshot of one host to another host which has SDU installed.