PowerStore Plugin Question

[lampshade]

Hi All,

New veeam user here. We are working on configuring our new backup infrastructure and i have a question with regards to the powerstore plugin. I have connected to the powerstore from within veeam with its management IP but this is not what I want. I want it to use the NICs that are directly on the SAN fabric.

First - we are using a physical proxy server which I have cabled 2 NIC's to our SAN fabric. Do we add the powerstore unit under the plugin using the powerstore's "global discovery IP" or do we use the 2 controller IP's? In our case - they are on the same subnet. Do we need to setup windows iscsi initiator manually to connect to the powerstore or does the veeam plugin do this? As I said previously I have used the management IP of the powerstore within the plugin and it setup the iscsi initiator automatically (I was just testing) or should i follow EMC's guide on connecting a windows server to the powerstore ( which includes installing MPIO drivers, adding in some advanced settings, configuring the iscsi initiator etc.. All well documented by DELL/EMC).

thanks

[popjls]

Mine is setup to point to the Global IP Management Cluster. I also have dedicated nics going to each fabric on the storage subnet which I think I did manually.

[Andreas Neufert]

In general you need to give Veeam an IP address or DNS name that leads to a management endpoint within the storage.
I do not know if it is possible within the storage to give any access port as well the option to answer to management traffic. This is a question more for Dell.

In case of the iSCSI configuration. Veeam will create automatically the hosts entries for the Veeam and Windows iSCSI initiators. No manual action needed.

[lampshade]

Mine is setup to point to the Global IP Management Cluster. I also have dedicated nics going to each fabric on the storage subnet which I think I did manually.

Thanks - i will try this. Did you setup the windows iscsi initiator manually or just let veeam do its thing with it? I am going to try to point the Powerstore plugin to the global discovery IP

[foggy]

Why do you want to do this? Just use the management IP and Veeam will do the iSCSI initiator stuff automatically for you.

[Andreas Neufert]

You can not create the needed iSCSI initiators yourself without some workaround. The reason is that we are not only using the Microsoft Initiator but as well our own (faster for some tasks when you scan hundreds of snapshots). This IQN can be only found in the Veeam logs. Anyway the plug-in automates the iSCSI hosts entry creation and no manual action is needed.

[popjls]

Thanks - i will try this. Did you setup the windows iscsi initiator manually or just let veeam do its thing with it? I am going to try to point the Powerstore plugin to the global discovery IP

Let Veeam do it automatically. The iqn is not known until you get it working so kinda hard that way.

[lampshade]

Ok thanks for the help everyone!

[lampshade]

Another Question...

Is there a "best practice" to the amount of VM's in one job when using storage integration like this powerstore plugin?? Just want to get some ideas on how to start laying out our backup jobs.

[foggy]

There are no strict recommendations, you can start from whatever you prefer from the job management perspective, for example. Depending on the observed environment performance/impact, you may want to consider playing with the max number of VMs per snapshot parameter.

[lampshade]

thanks for the assistance - i did see this option and was confused - does this mean we shouldn't have VM's under the same job but in different LUN's? One could easily make a backup job (via storage snap) that has 30 VM's but all reside on different LUN's or does this option just group the VM's (based on the limit you set) for better efficiency?

[Andreas Neufert]

Overall our concept is to process VMs and not volumes… You select a bunch of VMs or management containers like folders, clusters, datastores and Veeam makes sure that all volumes go into snapshots that are part of any VM constelation. If you have hundreds of VMs on the same volume you can use the option shared by Alexander to process multiple snapshots for same volume in the same run. Idea here is that it can take a long time until all VMs are brought into consistent state and processing snapshots more frequently helps to keep the first processed VMs not so long in that state.

[foggy]

In other words, this setting works for every volume involved in the job separately - if you set it to, say, 10 VMs per snapshot, VMs on each of the backed up volumes will be processed in groups to ensure a separate snapshot is created for max 10 VMs on the volume.