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.
