What is proper setup for Veeam 11 and Pure Storage iSCSI

[electricd7]

Hello-

I am about to implement an environment which houses all VMware VMs on a PureStorage Array that is connected to the hosts via iSCSI. I have a virtual Veeam server in that environment as well as 4 Windows 2019 proxy servers that are virtualized as well. I am waiting on a Pure FlasyArray for a storage target (which I will setup with SMB/CIFS), but for the time being I have scale-out repository made up of a couple of Linux NFS storage targets.

I have installed the PureStorage plugin for Veeam and have connected to the array within Veeam. I am able to see the volumes as well as the snapshots on those volumes inside of Veeam. I have (for the time being) a single backup job which is auto-selecting proxy servers and does have the "backup from storage snapshot" checked. This appears to be working as I do see the array taking a snapshot and see the proxy servers saying they are retrieving data from the storage snapshot. So I think its all "working" but I want to be sure I have everything configured properly and am following best practices. My proxy servers are setup as follows:

-3 VMXNet3 NICs (1 on vm network, 1 on iSCSI-A network, and 1 on iSCSI-B network)
-I gave each iSCSI NIC a static IP address
-I enabled the iSCSI service on each proxy (and made no other changes or connections within the iSCSI service)
-I didnt make any changes in Pure to allow the proxy servers to connect to the iSCSI volumes in storage
-I disabled the proxy service on the Veeam server itself (just to keep the waters clear)

As i said this appears to work, but I am unclear "why". How can the proxy servers connect to the Pure if I didn't add their initiators to Pure or allow those initiators within the volumes? Is this orchestrated automatically by Veeam when the snapshot is created and converted to a volume? (if so, this is very cool!). Secondly, do I need both iSCSI networks on the proxy servers? Does veeam make use of MPIO or will it fail if one side goes down?

Finally as I stated, I am waiting on a FlashBlade which I intend to use as a storage repository when it arrives. I read in a veeam doc that it will require a mount server to write its backups to. As I am 100% virtual, should I use another server for this purpose, a proxy server, or the Veeam server itself? The reason I am not using Veeam as a proxy is because I still want to be able to utilize the server when backups are occurring and way back in the Veeam 7 days, when I was using Veeam as a proxy server it was almost unresponsive at KVM/RDP while backups were happening. I have Case # 05180737 opened for this question, but its not getting too much attention and I really want to get this configuration "blessed" ASAP.

Thanks!

Ed7

[HannesK]

Hello,
I would invest in one physical machine to optimize performance, traffic flow and simplify the setup. Going through the whole network stack of the hypervisor sounds ugly to me (yes I know, many customers do that).

- virtual Veeam backup server is fine
- one virtual proxy for full disk / VM restore is something I would also do for HotAdd restore
- best practice would be to use block storage. As you write in the end (vs. beginning), that you plan to use FlashBlade... then there is a whitepaper on that configuration available.
- connection both iSCSI networks makes sense, yes
- yes, don't use the backup server as proxy

Yes, we do a lot of things automatically. That's why it "just works".

If you write to NAS shares, the gateway server is relevant. You can do everything virtual (but I would not do it). If you stay with everything virtual, then automatic selection would work (check the link about the used components... the backup server might be involved unintendedly). Mount server also can be any of your virtual Windows proxies. Again, traffic flow though the hypervisor (which is why I recommend the physical server). And you probably need to configure active full backups because merges are probably too slow on NAS repositories (which also solves some fail over to backup server scenarios)

I asked support to close the case as support is available to fix problems, while Veeam partners (or the forums for free) are available for designs.

Best regards,
Hannes

[electricd7]

Thanks for the info. One item I still don't understand is does a Veeam proxy make use of both iSCSI network adapters such that a backup/restore would continue to work if one of my switches were to fail. This is handled within ESXi on a per host setup, but I am unclear how the proxy servers are configured when connecting to Pure for data movement? I would also think utilizing MPIO on iSCSI would increase overall throughput for retrieving data from the Pure volume it is reading. Thank you, again.

[electricd7]

Another question I have.

Lets say we have 75 VMs within this environment and all are on 1 or 2 datastores housed on Pure. I understand that if I don't tell it otherwise, pure will hold off creating the storage snapshot until all VMs within the job have completed their VMware snapshot for application aware. That makes sense to me if I have a single job with all 75 machines contained to limit the number of vms to say 10, so that it won't wait for all 75. I actually have 2 questions about this:

1. If I set up a single job which contains 75 VMs and set the limit to 10, will it get the first 10 VMware snapshots, then storage snap, then backup and delete that storage snap before moving to the next 10, or will it get the first 10 vmware snapshots, take a storage snap, begin backing up using that snap and also start the next 10 (and take a second storage snap and so on until they are all processed?)

2. If I have 5 or 6 jobs each containing VMs on the same 2 datastores and use backup from storage snapshot, can those jobs run concurrently? Will the storage just take multiple snapshots of the volume since both jobs will be processing VMs held on the same underlying storage volume?

Thanks!

[foggy]

Hi Chad, both your assumptions are correct. VM groups in a single job are processed one by one. If you want more parallelism, you can create multiple jobs - in this case, snapshots will be created in parallel and you can limit the number of concurrent snapshots per datastore via registry.