Direct access to SAN via iSCSI or other transport modes ...

[Didi7]

Hello,

let me try to explain our VMware environment. We have an HP MSA2040 storage with 2 controllers equipped with 4x 10GBit/s Ethernet iSCSI Ports on each controller. Our two HP DL380p Gen8 servers (running ESXi v5.5 Update 2) each have 2x 10GBit/s Ethernet Ports. The storage and the ESXi hosts are directly connected without a physical switch.

Am I right, when I say that direct iSCSI target access to the LUN's in the MSA storage is impossible on a virtual machine (with Veeam proxy) running in one of those ESXi hosts? And if yes, what other options do I have to quickly backup my VMDK's. If direct SAN access to my iSCSI storage is impossible, how should I configure my ESXi hosts, which besides the 2x 10GBit/s Ethernet ports are further equipped with 8x 1GBit/s Ethernet ports each?

The upcoming Veeam backup server, which also will host the repository for the backup data, is equipped with 4x 1GBit/s Ethernet ports.

Any suggestions?

Regards,
Didi7

[Didi7]

Maybe someone can at least tell me, if iSCSI target access from a virtual machine is possible in our Environment or not in the first step before making any recommendations how to distribute the 8x 1GBit/s vmnic's on different vSwitches?

[foggy]

Direct SAN access is possible with your configuration, please review the corresponding FAQ section for the tips on how to configure it. Since your Veeam B&R server is a VM, you can also consider using hotadd to retrieve source VMs data from the storage.

[Didi7]

Hello foggy,

ok, just to clarify things up again. The B&R Proxy would be a VM inside one of those ESXi Hosts, the B&R Management console and repository would be a pyhsical Server with lots of space for backup data, which finally would be dumped to a tape library, also attached to this physical B&R Server.

You indirectly told me, that iSCSI Initiator would not make sense in my B&R Proxy VM, cause I don't get access to the iSCSI Targets, because the storage and the ESXi Hosts are directly attached without a physical Switch, right?

I read a lot about Virtual Appliance mode (hot add) and those additional SCSI Adapters to configure in this B&R Proxy VM, but I still haven't understand, how that works.

Do I get access to the datastore or do I hot add SCSI disks from other virtual machines residing on the datastore, so that the SCSI disk from another VM is temporarily bound to the B&R Proxy VM and at the same time bound to the VM to which the disk originally belongs?

And if a virtual disk (VMDK) from another VM is also bound to the B&R Proxy VM via hot add, is there no risk for the temporarily added disk?

Still sounds odd to me

Regards,
Didi7

[Vitaliy S.]

You indirectly told me, that iSCSI Initiator would not make sense in my B&R Proxy VM, cause I don't get access to the iSCSI Targets, because the storage and the ESXi Hosts are directly attached without a physical Switch, right?

If you cannot connect from proxy VM via iSCSI initiator to the target storage, then direct SAN access mode will not be possible.

I read a lot about Virtual Appliance mode (hot add) and those additional SCSI Adapters to configure in this B&R Proxy VM, but I still haven't understand, how that works.

Do I get access to the datastore or do I hot add SCSI disks from other virtual machines residing on the datastore, so that the SCSI disk from another VM is temporarily bound to the B&R Proxy VM and at the same time bound to the VM to which the disk originally belongs?

When hotadd backup mode is used, virtual disks of the backed up VMs are attached to the proxy VM, and then backup server copies the content of these virtual disks. After backup job is complete, disks are unmounted and are added back to the production VM. During backup job operation your source/production VM is running on a snapshot.

And if a virtual disk (VMDK) from another VM is also bound to the B&R Proxy VM via hot add, is there no risk for the temporarily added disk?

Not sure I fully understand this question. Can you please clarify it?

[dellock6]

Didi7,
vmdk are snapshotted on the VM owning them and then mounted as read-only on the hotadd proxy, so there's no risk at all in this kind of operation. No way a proxy can write or modify the original vmdk.

[Didi7]

Hello Vitaly S. and dellock6,

first of all many thanks for your answers. I now understand that the production VM is working on the snapshot VMDK, whereas the consistent VMDK is read-only attached via hotadd to the Veeam Proxy server and no harm to the VMDK is possible! Now, how is the data from this hotadded SCSI VMDK copied to the Veeam Repository server? Is this done via the virtual NIC of the Veeam Proxy server? And if yes, how fast (MB/s) can this be (I know this is also dependent on the underlying storage)?

And if the data from the hotadded VMDK is copied via the virtual NIC from the Veeam Proxy, does it make sense to add more than 1 virtual NIC with 1GBit/s to the Veeam Proxy VM? Maybe a trunk of 4x 1GBit/s NICs or a second NIC with a Backup VLAN, which is also available on the Veeam Backup Repository server?

As direct SAN storage access is impossible in my configuration, as long as I don't add the iSCSI-Ports from the HP MSA storage and ESXi-hosts to an Ethernet switch, instead of connecting the MSA and ESXi-hosts directly. Is hotadding the fastest way to copy VMDK data to the Veeam Repository server as transport mode?

Regards,
Didi7

[Vitaliy S.]

Is this done via the virtual NIC of the Veeam Proxy server? And if yes, how fast (MB/s) can this be (I know this is also dependent on the underlying storage)?

Depens on your configuration, but if you're using a remote repository (not hosted on the proxy server), then VM data is transferred over the network to your repository. Performance of the job will depend on the connection link (LAN) you have between proxy and repository.

And if the data from the hotadded VMDK is copied via the virtual NIC from the Veeam Proxy, does it make sense to add more than 1 virtual NIC with 1GBit/s to the Veeam Proxy VM? Maybe a trunk of 4x 1GBit/s NICs or a second NIC with a Backup VLAN, which is also available on the Veeam Backup Repository server?

First check what bottleneck stats show you after running at least one backup job. Based on this data, you will be find out what is the "weakest" component in your infrastructure which should be imporved if you want to get better performance.

As direct SAN storage access is impossible in my configuration, as long as I don't add the iSCSI-Ports from the HP MSA storage and ESXi-hosts to an Ethernet switch, instead of connecting the MSA and ESXi-hosts directly. Is hotadding the fastest way to copy VMDK data to the Veeam Repository server as transport mode?

Yes, hotadd backup mode is comparable to direct SAN access mode in terms of source data retrieval speed and usually provides better job performance rates as opposed to network mode.

Thanks!