Quantum Forum for DXi V5000
Veeam in conjunction with V5000 - First Validation
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
Replies to This Discussion
-
Permalink Reply by Steve Wright on
-
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.
-
Permalink Reply by Nico Kretschmar on
-
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!
-
-
Hi Steve,
I appreciate you response!
As a tentative summary and each's bullet points status
- 10 GBit vNIC is shown as 1GBit interface in the GUI
- known issue. Cosmetically only.
- Difference in throughput between restore and backup processes
- Not directly addressed, potentially linked to a pending memory adjustment
- Here I would like to get more assistance to configure an appropriate environment (VM and appliance settings)
- Missing ability to install the VMware Proxy for Standard Linux systems
- I believe, we are misaligned. It is not about the process how to integrate the local resources into a Veeam repository, but how the instance is treating VMware source instances. Normally, there are ways, like SAN (Direct Storage Access), HotAdd (Virtual Appliance), or as a fallback Network (Net block device). I was hoping, that we can use one of the first two, but I think, we need to be fine with the third, which has a natural limit of 10GBit (NIC's link speed of all involved systems, like Hypervisors to access the storage and the Appliance VM)
- Performance to an S3 compatible object storage (MinIO on Windows)
- This turned out to be a clear performance issue on the target side. I managed to use another MinIO instance, and got much better results.
- Can be considered to be solved.
So, in a nutshell, may you please review the Italic and Bold portion above and feedback?
Thanks and regards,
Nico
- 10 GBit vNIC is shown as 1GBit interface in the GUI
-
-
Hi Nico!
Great to hear from you again. Sorry I didn’t answer your questions the first time, but let me try again. I’m not a Veeam expert unfortunately but fortunately we do have some on staff.
- Difference in throughput between restore and backup processes
- Missing ability to install the VMware Proxy for Standard Linux systems
- I believe, we are misaligned. It is not about the process how to integrate the local resources into a Veeam repository, but how the instance is treating VMware source instances. Normally, there are ways, like SAN (Direct Storage Access), HotAdd (Virtual Appliance), or as a fallback Network (Net block device). I was hoping, that we can use one of the first two, but I think, we need to be fine with the third, which has a natural limit of 10GBit (NIC's link speed of all involved systems, like Hypervisors to access the storage and the Appliance VM)
So I think these are best addressed together.
You should be able to use “hotadd” transport mode. That’s all dependent upon the Veeam B&R ESX/datastore availability and the DXi doesn’t matter. A Veeam proxy can’t be installed on the DXi, but your configuration of Veeam + ESX and datastore access should allow for hotadd.
Apparently it’s best to have a VM proxy on the ESX server that has access to all relevant datastores. Then that has to be configured within Veeam. That’s a common configuration.
So the VM Proxy can directly mount the datastore that contains the VM (VM to be backed up) vritual disks and send data directly to the DXi.g
Does this help?
-
-
Hi Steve,
basically, it confirms, it should work in a hotadd mode. I need to say, my test environment runs in our data center, where we are usually work with a storage integration, so with our Veeam backup server and its proxies, which are all physically, we fetch the backups directly from the primary storage snapshots.
As this is hard to tweak, and also not representing our real use case for the DXI V5000, I will pick a remote site and deploy an appliance there, to have better real life conditions for another test run.
Btw, I noticed also in the file system (/var/log/Veeam) some well known log files... ;-)
I will keep you posted on the result of the remote site testing.
Regards,
Nico
-
-
Hi Nico,
I don't think this is a very complete response but I didn't have much time today. so I'm passing on what I got but didn't have time to delve into it further. I apologize for that. I'll try again if I can. But does this help:
DXi could be a secondary copy location for the primary backups. That way you have a deduplicated copy of the backup on V5000 and could replicate efficiently offsite further increasing protection!
In my lab environment I do not have primary storage that has integration with Veeam (for direct snapshot) so i cant really test this scenario in-house. But this could be a great option.
-
-
Hi Steve,
no worries at all. Next validation step is on my side. Of course, my clear aim is to consolidate any competitor's deduplication appliance AND the current primary backup targets, running on Windows. Not for big size sites, but the DXI is seen as the clear option to work in micro or midi sites as THE backup target.
Additionally, AND if we got a deal with Quantum about an onprem Active Scale, we are extremely excited to use it as performance tier within an ScaleOut repository.
The true only missing feature from Veeam is the PowerNFS / MountServer support for all Linux based appliances, being the source of an Instant Recovery (Running a VM from a backup source directly). But thats somehow on the Veeam roadmap, however not scheduled.
Regards,
Nico
-
-
Just one thing ... the DXi supports instant recovery from a deduplicated share already (direct). It works well.
-
-
when we do instant recovery the DXi serves up the data independently of the Veeam server. The Veeam server will only record changes to data and apply IF the VM is migrated to production
-
-
Ufffh...This sounds amazing!
And right in time, as I am working to deploy a new DXI instance to a real remote site.
When I am get you correctly, I need only to make sure, the repository for the DXI has been set without a mount server. And with that, Veeam will still present the Instant recovery from the DXI based repository.
-
© 2024 Created by Quantum Forum V.
Powered by
