could anybody explain, what's the main differences between iSCSI-SnapDrive and RAW LUN Mapping are? both technologies are just a LUN on the NetApp, but what about the network-side? are there any advantages or disadvantages compared to the other technology?
we have only used iSCSI-devices for our databases, but these devices are not supported by Veeam Backup & Replication. As Veeam can make application consistent backups of databases, I consider to change the type of the disk ... is it useful?
Well there is practically no difference in LUN w.r.t to iSCSI Snapdrvie or RAW.
The difference is who owns the File systems on the LUN.
In iSCSI Snapdrive LUN you format the LUN using VMFS and ask you application to sit on top of that.
In RAW disc there is no formating with VMFS and its a RAW disc only. Some application does require RAW discs as their preferred way to work with storage. ( They don't like OS File system to take control).
In your case your application fits in 2nd category and hence you have to provide RAW disc to it.
w.r.t to working there is really no difference to the Storage since in both the cases the File system is not with NetApp and works in the same manner like your iSCSI Snapdrive LUN.
thank you for your explanation! the only difference is the usage of the network-connection, isn't it? iSCSI-SnapDrive uses its dedicated network-connection, whereas a RAW Disk is connected thru the normal Intranet-network-connection! Am I right?
is it possible to backup the RAW Disk over SAN?
I have encountered the following error message on my test-backup:
Backing up file "[vm_os_vol0] dbtst2008/dbtst2008_1-rdm.vmdk" Unable to establish direct connection to the shared storage (SAN). Please ensure that: - HBA is properly installed in the Veeam Backup server computer, or software iSCSI initiator is configured correctly. - SAN volume can be seen by operating system in the Windows Disk Management snap-in on the Veeam Backup server. - Read access is allowed for the Veeam Backup server computer on the corresponding LUN (refer to your SAN documentation). Direct SAN connection is not available, failing over to network mode...
the backup-server is mapped to the raw disk (if it does matter) ... btw. [vm_os_vol0] isn't the right volume - the raw-disk has its own volume on our NetApp!
edit: the RAW-Disk is listed in the Windows disk management of the backup-server!
edit 2: i have started a second run and now the error-message didn't appeared anymore 😉
Erm....I hate to be contrary but this isn't exactly right.
With either a LUN accessed via SnapDrive inside the guest OS or an RDM, the LUN is given directly to the VM in question and formatted by the VM with the guest OS's file system (i.e. NTFS, ext3, etc.).
The main difference is in the igroup assignment -- if using SnapDrive/Windows iSCSI initiator, the LUN is assigned to the iqn of the specific Windows OS. If RDM, the LUN is assigned to the iqn's of the ESX server (or multiple servers if talking a DRS/HA cluster).