Now we know that it works, we just use the HBA330 controllers for storage spaces. The drawback of that would be with the chosen front bay is we have the 8 NVMe slots that cannot be used by the controller. When ReFS gives us trouble, we can revert to RAID mode and use NTFS where deduplication could help with the capacity efficiency. If mirror accelerated parity (MAP) doesn’t work out, we can always create an NVMe and SSD pool and leverage those with backup copy based tiering. These allow for running in passthrough mode, which you set in BIOS, and it has support for stand-alone storage spaces (non S2D) use. With our initial designs, we used Dell H740P controllers. For our needs, we chose the 24x 2.5″ (hot-swap) front bay configuration with 8 NVMe and 16 SSD slots. We used DELL R740XD servers to build all-flash backup target servers.
The reason for the latter, in that case, might be to work around LUN size limitations or provide yourself with some wiggle room and not consume all available storage in a single extent. But you can certainly start that way with a SOBR based on one server, with one or multiple extents. You can have multiple SOBR extents on the same server, but generally, you do not want to build a SOBR out of extents living solely on the same server. These are the actual storage units (a LUN, a file share) that live on a server. The building blocks of a SOBR are extents. For that, we leverage S3 compatible object storage that supports immutability via object lock. It also delivers “air-gapped” off-site copies via the capacity tier. SOBR rocks for scale-out backups in regards to flexibility and life cycle management of the backup repository. In the end, we built a backup target solution based on Veeam Scale-Out Backup Repositories (SOBR). We combined that with smarts in negotiations and design to achieve a viable solution. Luckily prices for NVMe and SSD are dropping. On top of that, by going all-flash, we could give them stellar performance and capacity in only six rack units with room to expand if ever needed. To give you an idea, going from 32 rack units to 6 rack units reduces hosting costs over five years so significantly it becomes economically feasible. With HDDs this comes at a cost in power consumption, cooling, and rack space.Īs it happens in this situation, the price of a rack unit per month was significant enough to warrant spending money to reduce rack units, especially if it also brought other benefits. We need large amounts of spindles to achieve even acceptable IOPS and latencies. HDDs can deliver capacity efficiently, but when you also need performance, there is a kink in the cable. For one, the need for multiple concurrent back-ups and restore jobs sounds like a match for NVMe storage or at least SSD. There are a couple of challenges that combined present an opportunity. The 3-2-1 rule still applies, and having an air-gapped copy is the new normal in the era of ransomware and wipers. Finally, there is also a need for long term retention and off-site, air-gapped backup copies. But those are subjects for other articles. On top of that, we secure it all with credential disclosure preventative measures, firewall rules, an internet proxy, and MFA. We deploy the solution in a hardened, non-domain joined setup where the backup infrastructure has no dependencies on the fabrics and workloads it is protecting. There is also the need for excellent performance in as little as possible rack units.įor SAN-based Hyper-V clusters, there is the request to keep leveraging Off-Host proxies (yes, they use Veeam Backup & Replication v10), while we also need to have a performant solution for HCI based Hyper-V deployments. The source clusters for all this are recent era all-flash arrays and servers in a mix of SAN and HCI solutions like StarWind or S2D.Įverything we mentioned above means they require backup storage capacity. Next to that, they also need the ability to do multiple restores in parallel without affecting performance too much. They want to have concurrent backup jobs running without observing noticeable slowdowns in throughput. So they need a solution in a small footprint. What is also important is that they have severe rack unit constraints, both in numbers and in cost. They are diverse in their content, and quite a lot of them contain data that does not deduplicate well.
The size of those virtual machines varies from small to large in CPU, memory, and storage. These virtual machines live on all-flash arrays. Imagine an environment that has many, many hundreds of virtual machines to backup, every day, multiple times a day with no exceptions. StarWind Virtual Tape Library (VTL) OEM.
#VEEAM BACKUP APPLIANCE SOFTWARE#
0 kommentar(er)
