Configuring new VEEAM Backup Server for direct SAN access

[avrham_g]

Make sure all your LUNs are presented the same way to the Veeam backup server. Maybe it's worth to contact your storage manufacturer to consult.

the LUNs are presented to the veeam backup exactly like they presented to the esxi because they are on the same host group in the dell system.i use dell MD3200i.
how the LUNs should be on the veeam backup server in the disk management?
i've setup another server for testing with windows 2008 r2 sp1 and i get the same results.
i don't know if i need to initialized the disk or not.

[Vitaliy S.]

Disks shouldn't be initialized, please review the instructions provided on the very first page of this thread:

Hopefully real FC SAN administrators will come to help with this (because I am not one - I never touched FC SAN before)
I do know we have EMC CX users for sure!!

But here is my understanding:
1. Open command prompt on Veeam Backup server as adminstrator, and type "diskpart" and then "automount disable".
2. If you did not do this yet, plug-in FC HBA into Veeam Backup server and install the latest drivers. Not sure if any client side settings needed for HBA to point to the storage. In case of iSCSI storage, you need to enter iSCSI target IP in the initiator settings.
3. If EMC CX has this functionality, allow read access to your VMFS LUNs for Veeam Backup server in the SAN configuration (optional).
4. If you do everything correctly, your VMFS LUNs should appear in Windows Disk Management snap-in. Don't initialize them!
5. That's it - Veeam Backup&Replication will now be able to work in the direct SAN access mode.

On top of that, we have a blog post that you might find very useful: Using the iSCSI initiator within Veeam Backup & Replication in a VM

Hope this helps!

[cffit]

I am having this exact issue with connecting for Direct SAN backup to an EMC SAN.

http://www.veeam.com/KB1107

I do have a support case open, but I was wondering if anyone else has had the issue and if they found any other resolution because I need to run MPIO for connecting to our Equallogic SAN for backup. I'm pasting the article contents here to save me from typing..

KB ID: 1107
Problem: SAN-mode jobs work well, but after enabling Windows MPIO jobs start to fail with the errors:

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).

Backup Server can see all the LUNs and shows them in disk manager. However, Veeam cannot perform a SAN backup from them. Running vcbsandbg gives an error that the lun does not contain any VMFS/LVM signatures.
Cause: Incorrect configuration of MPIO software.
Solution: Install the latest version of MPIO software. If you are using EMC storage, then instead of using Windows MPIO you should install the latest version of PowerPath with service packs. After that you can reboot Veeam Backup server and check if vcbsandbg starts seeing all the LUNs.

[mpasaa]

We use an EMC SAN and to do direct SAN you simply need to add all the datastores to the storage group of your backup server if it is physical. Unisphere gives you a warning that attaching LUNs that are currently used in other storage groups may result in disk corruption or errors but it's not a problem--Veeam only connects in READ only mode and I've never had an issue. If you use Veeam in a VM you don't have direct SAN access available. That's it. Make sure you use the diskpart automount disable command on the physical server to prevent Windows from mounting these VMFS datastores as windows drives--that would be very bad

I tried Veeam in a VM and used appliance mode but it was terrible...performance was hit or miss and I had intermittent network issues and such. however, this could due to our environment and others may have better luck. I went back to my physical blade and backups work perfectly in SAN mode and I also incorporated using that backup proxy feature to enhance read access to the jobs to run more concurrently.

Hope this helps

[bhwong]

This is no more or less risky than accidentally formatting VMFS datastores from vSphere Client. It is a matter of security, and not giving random people access to high privilege accounts.

Yes, that is correct. You may want to read up the corresponding section of sticky FAQ for more info on this. Thanks!

I disagreed. When you attempt to format VMFS datastores from vSphere Client, vSphere will warn you that all data will be wipe off. You can also browse the datastores to confirm what you are going to wipe off.

With Windows prompting to initialize the unknown volume, there is no such warning at all. This mislead the user to think it's safe! You also can't browse the volume to confirm what you are going to initialize. It's really an disaster waiting to happen. I know it because it has happen to us in the past.

btw, is there any SAN storage in the market that allows read-only for Windows but read-write for vSphere from the same volume in the first place???

[dellock6]

I do not think you can have different ACL based on the OS trying to access the LUN, but many storage products have ACL to guarantee read/write or Read-only access to LUNs based on the server connecting to it, both via iqn (for iscsi) or wwn (for FC). There was a thread about Equallogic for example not beeing able to assign read only per iqn but only to entire luns, but many other storages can do that.

Luca.

[Gostev]

I disagreed.

The main point of my post was this:
"It is a matter of security, and not giving random people access to high privilege accounts."

It does not matter how easy or hard something is, because as soon as you give users a chance to mess up your systems, trust me - they immediately will. They will find out most unreasonable way to do something (that you could never even think about - being "normal" hehe), and will cause complete havoc with their unnecessary high privileges.

Saying that something will not be done because there is clear warning is just wrong... users do not read warnings! Trust the UI designer

[rbrambley]

With Windows prompting to initialize the unknown volume, there is no such warning at all. This mislead the user to think it's safe! You also can't browse the volume to confirm what you are going to initialize. It's really an disaster waiting to happen. I know it because it has happen to us in the past.

True, but the point we are all making is that because Microsoft assumes that anyone who opens Disk Manager knows what they are configuring on that server, you have to prevent "users" from even opening Disk Manager so they never have a chance to make the mistake of initializing. You can disable access to DM via local policy or via account privileges, or do not give "users" the ability to log on at all. You must control that for obvious reasons - even without Veeam!

[bhwong]

The main problem is not with the end user of course, but new IT colleagues who may not be familiar with our existing infrastructure and assume that it's an unused volume he/she can initialize and make it available for Windows to use.

[habibalby]

The main problem is not with the end user of course, but new IT colleagues who may not be familiar with our existing infrastructure and assume that it's an unused volume he/she can initialize and make it available for Windows to use.

A proper documentation of what's going on in your infrastructure is the way to go, any new guy employed he/she must be well-guided on how things are done and setup / configured.

Thanks,

[nmace]

Quick question. I am setting up Veeam in Direct SAN mode (Veeam is on a physical box) with an Equal Logic SAN. Veeam has two 10 gig connections to our dedicated iSCSI network. Should I use the plain Windows Server iSCSI Initiator? Or should I install Equal Logic Windows Host Integration Toolkit to get MPIO?

[Vitaliy S.]

I believe you should be good to go with plain Windows Server iSCSI initiator. According to the feedback coming from our existing customers, it's better not to use MPIO, as it might affect your backup job performance rate in a negative way.

[nmace]

I went with just the vanilla Windows initiator (not Dell's MPIO) and configured a single 10 gig nic with proper iSCSI access. I got 200+ MB/sec (yes, MB) on my test backup job. That is beyond awesome.

However, that is using a single port going to a single switch. How would be the best way to add redundancy with my second port and second switch? Is it just as simple as adding another iSCSI IP to my second nic, assigned access to the VMFS volume, and setting up the Windows initiator with Round Robin with both IPs? Sorry, I've not had to deal with Windows iSCSI networking in a long long time (that has been all vSphere for forever).

[Vitaliy S.]

I'm not expert in Windows iSCSI networking either, but to the best of my knowledge, if you want to achieve redundancy and maximum performance while using iSCSI interface, it would be preferred if you could use dynamic link aggregation (assuming your storage vendor supports this technique).

Here is a really good blog post that describes everything in details for vSphere Environment, might be worth checking out:
A “Multivendor Post” to help our mutual iSCSI customers using VMware

[chimera]

However, that is using a single port going to a single switch. How would be the best way to add redundancy with my second port and second switch?

MPIO / iSCSI redundancy for the backup box? Probably not much point?

Is it just as simple as adding another iSCSI IP to my second nic, assigned access to the VMFS volume, and setting up the Windows initiator with Round Robin with both IPs??

You would install Dell HIT for Windows to get MPIO support.

Sorry to hijack this thread... but I have a similar query in regards to performance (or potential lack of). A client of mine has a Dell EqualLogic SAN (tier 1 storage) and a Dell MD3600i SAN (tier 2 storage) connected up across 6 x ESXi hosts. Its been a battle to get both these working together due to the way the SAN's function (both have 4 x physical ports - 2 controllers / 2 ports per controller, however EQL has a "group IP" - or virtual IP if you like that dynamically spreads the load across physical IP's on each port, whereas the MD3600i has no "virtual IP" but instead, for optimal performance, requires half the IP's in different subnets... I digress) So getting these working together under VMWare when sharing the same 10GbE NIC's and retain performance was a nightmare (had to VLAN off and trunk iSCSI up to the vmk's...) but anyways, even more tricky to get going on the Veeam server side AND continue utilising Direct SAN backups. In this case, I've have 2 x 10GbE (unfortunately Broadcom) NIC's, 1 x NIC is dedicated to EQL and the other to MD3600i, each with their own IP (and tried adding a secondary IP to the MD3600i to get the 2nd subnet going). I can get Direct SAN backups from EQL, but not from MD3600i, I believe due to the ownership of a path / LUN,... but anyway, back to my point - nmace - a question for you, if you run Task Manager whilst Veeam is running a direct from SAN backup job, what utilisation of the NIC's are you seeing? In fact, anyone running Direct SAN backups over iSCSI, are you 1Gbps or 10GbE and secondly what average and maximum NIC utilisation are you seeing in Task Manager/Resource Manager? Mine seems quite low, so I'm sure there must be some tweaks that can be done on the NIC to improve performance (I already disabled Windows TCP autotuning as per this post viewtopic.php?f=2&t=4093 )