Quantum Forum V

Quantum Forum for DXi V5000

Dear,

We are just validating the DXi-V5000 as a potential replacement in our global backup strategy for our remote sites. We are using consequently Veeam Backup & Replication v11 to manage this.

Today we have dominant Windows based remote proxies to our hypervisors and store there either on ReFS or NTFS the primary backups. To achieve secondary offsite backups, we are using either central StoreOnce appliances remotely via their native Catalyst protocol, ScaleOut repositories towards AWS S3 (not Glacier yet), or local StoreOnces replicating to central ones.

The DXi-V5000 appealed itself recently, and we try to find out, how far we can go to use it later, either as community or paid version. Depends on sizing and support needs.

I just performed a couple of steps, am happy so far with the results, however handful points are appeared, and I wanted to use the community here to kickoff a discussion.

  • NIC shows 1GBit in the GUI while from the Linux kernel messages it shows the correct 10GBit
  • Difference in network throughput doing backups and restoring backups, a kind of "in" is the double than compared to "out"
  • Sadly to see, even it seems to be a standard CentOS platform, the Veeam v10 Linux based VMware proxy role cannot be installed (Veeam declined it due it is a "Quantum DXi")
  • After a first replication between two DXi, which worked greatly, I was able to recover a snapshot and was able load the restore points back to Veeam. However, when I trie to delete the recovered snapshots, I got and odd message "feature VTL is not supported on this system". No idea, how to get rid of the thingy
  • The worst thing I noticed, I did set a ScaleOut repository in Veeam to conjunct the DXi as primary backup target to an onprem S3 object storage and started the tiering. Unexpectectly the throughput was not acrossing 10 MB/s, which is cleary too low. For the insiders of Veeam, I set the DXi to be the "gateway" towards the S3 object storage, which simulates the case or our remote sites, as they have their own broadband Internet circuit.

Any kind of feedback is highly appreciated!

PS: To be fair, I forgot to mention, it is a great product anyway, and the approach to open it for small use cases, is making the solution truly sexy to look at.

Regards,

Nico

Views: 60

Reply to This

Replies to This Discussion

Hi Nico -- thanks for the post! I'll try to research your Veeam specific questions but unfortunately our Veeam people are out for the week. For other issues:

The 1G NIC shown in GUI -- since this is a virtual port in VM that can cause confusion between GUI and Linux.

If this is a physical 10G NIC port mapped into the VM, the V5000 likely does not treat the link speed as it should. Known issue, We're addressing it. But it does not matter for functionality or actual speed.

In terms of snapshot, was it a replication snapshot or a secure snapshot? I haven't seen that error. it is true that VTL isn't supported in the V5000, of course, but that's an inappropriate error. Can you give any more details as to how it happened?

Thanks again, and I'll look at Veeam questions when I can. Veeam is one of the products most commonly used with DXi so we have a lot of customers using it in the field and we have a good relationship with Veeam as a company so if we are lacking something we can identify the issue resolutions.

Hi Steve,

thanks for your prompt reply.

About the odd message, I understood, to make any replication state on the target system available to an attached VBR instance, I need to "recover" a received snapshot. That works as expected!

In the moment, I want to cleanup the recovery jobs, aka "Delete Job Info" of the selected snapshot recovery job, it throws the error. I uploaded a screenshot to document it a bit more.

Thanks for the comment about the link speed, I understood it is a minor and cosmetic error, as the link speed of the vNIC is 10GBit, while the vNIC is configured as Paravirtual. I tried also VmxNet3, but same result. I ignore that for the moment.

About the other points, we scheduled for tomorrow a meeting with a consultant of Quantum, maybe we got some traction from there as well.

Keep the post updated from my end...

Regards,

Nico

Attachments:

Thanks Nico!

I'm passing the screenshot on but I may not have an answer until Monday on the Veeam issues. I know you'll get good help from the consultant as well. I will that person know what I am doing as well.

Hi Nico,

Been talking to some people about this, and this is what I got back:

The modern versions of Veeam cannot install as we are “integrated” with Veeam. 

Veeam (on standard linux systems) will install a resident data mover and open a port/listener for jobs.  We do not do this. Our VDMS integration loads a temporary data mover to accomplish the same thing.  The reason Veeam does this on standard linux systems is to support “immutability”.  The DXi does the same thing via secure snapshot (one of our included features).  The message during repository configuration should not be alarming.

The S3 scaleout backup repository should support good performance when migrating to S3 with the DXi as the gateway (this avoids an unnecessary hop to a Veeam server for a gateway).  The network path should be analyzed to ensure that the data is being transferred directly from the DXi to the S3 cloud storage and not otherwise.  This can be done by monitoring the Veeam server network to ensure the data is not landing there prior to transfer to S3. But as I understand your S3 target is on prem, so not WAN to worry about.

Also -- I've been thinking about our VDMS option. It takes quite a bit of memory. Does your VM have considerably more memory than the minimum?

thanks!

RSS

Tips + Tricks

© 2022   Created by Quantum Forum V.   Powered by

Badges  |  Report an Issue  |  Terms of Service