{"id":1246,"date":"2023-10-08T00:09:00","date_gmt":"2023-10-08T00:09:00","guid":{"rendered":"https:\/\/labiol.xyz\/?p=1246"},"modified":"2024-01-19T10:30:19","modified_gmt":"2024-01-19T10:30:19","slug":"vcdr-vmware-cloud-disaster-recovery-product-description-personal-experiences-working-with-the-product","status":"publish","type":"post","link":"https:\/\/www.labiol.xyz\/index.php\/2023\/10\/08\/vcdr-vmware-cloud-disaster-recovery-product-description-personal-experiences-working-with-the-product\/","title":{"rendered":"VCDR – VMware Cloud Disaster Recovery, product description, personal experiences working with the product."},"content":{"rendered":"\n

VCDR – VMware Cloud Disaster Recovery is a service offered by VMware to create a Disaster Recovery solution based on public cloud infrastructure and VMware solutions. The concept is to easily calculate the costs of operating such a DR solution, making it easily scalable, and, perhaps most importantly, easy to deploy and maintain. In my assessment, all these parameters have been met, and VCDR is a very good solution. Additionally, VCDR can address contemporary issues such as ransomware recovery. After a ransomware attack, it’s possible to restore the machine to its state just before the incident. VCDR not only introduces DR implementation in the cloud but also leverages existing, albeit not very commonly used, on-premise solutions, such as fast snapshots (quick in deletion).<\/p>\n\n\n\n

I don’t know if it’s an indicator of the complexity of the product, but take a look at the weight of the documentation for this product, and you’ll immediately know that it’s not the most complicated application in the VMware stable – and that’s the whole idea. <\/p>\n\n\n\n

To start with the product you don’t really need to know the AWS Public Cloud as well. Very basic knowledge is enough. In addition you will probably have to communicate to VMware that you are going to test\/implement that product so it will be visible in VMware Cloud “Cocpit” (or whatever that side is called when you will be implementing that product). <\/p>\n\n\n\n

VCDR has many well-thought-out solutions from an architectural standpoint. In my opinion, one of the most important is that during a DR event, there is no need to restore the system to the target SDDC. Resources from CFS (see below) are mounted to physical ESXi hosts, and the mechanism can intelligently power on the requested machines\u2014with a specified date\u2014so that they can essentially run on this storage. Only when they are powered on does the process of migrating them to the target SDDC storage (such as vSAN) take place. This significantly speeds up the system’s start at the moment of failover. It’s worth paying attention to this when choosing DR technology.<\/p>\n\n\n\n

Architecture, project design<\/strong><\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

From one side we have protected DC (usually your on-prem DC, but of course it can be VMC implementation as well – or even AVS and other (there were announcements for future implementation)<\/p>\n\n\n\n

Bluebox (DRaaS connector) is a product (appliance) that need to be implemented in the source DC (check below requrements). Connector needs from one side of course get access to our local infrastructure, from the other to Cloud File System (CFS) which is implemented in the cloud. From that point of view, DRaaS connector is a crucial component, as it needs to be properly implemented by VMware ifrastructure administrator (together with Network administrator) and at the end it needs to be properly maintained as without that component there DR will not work. It might be good practice to implement more than one connector and plan place\/number of connector to your infrastructure (number of cluster, number of management netwoks, etc). <\/p>\n\n\n\n

CFS (Cloud File System) – place (hidden S3?) is used to store snapshots from the on-premise DC. Also eventually to restore VM (in some situtation). Can also be use to restore individual files (check systems that are supported). Also backuped images are mounted during DR (real DR situation or testing) in a way, that VMs can be started before it is fully migrated to SDDC datastore (vSAN). More information: https:\/\/docs.vmware.com\/en\/VMware-Cloud-Disaster-Recovery\/services\/vmware-cloud-disaster-recovery\/GUID-085F853C-307E-4D63-ACFB-59586E2FAD8A.html<\/a><\/p>\n\n\n\n

Cloud DR orchestration – for us, is it nicely working web UI, very intuitive<\/p>\n\n\n\n

SDDC on VMC (AWS) – this component is necessary to run our workload in the Cloud (after DR recovery – both, real or during tests). It is important to understand and well design VMC as it not necessarily needs to be up and running all time. <\/p>\n\n\n\n

Network communication:<\/p>\n\n\n\n

<\/p>\n\n\n\n

Preparation<\/strong><\/p>\n\n\n\n

Very nice checklist can be found on the following page: https:\/\/docs.vmware.com\/en\/VMware-Cloud-Disaster-Recovery\/services\/vcdr-predeployment-checklist\/GUID-9DFCE5CD-C979-4F48-91ED-D9E241489617.html<\/a> I guarantee that you will be back to that list at the beginning quite often.<\/p>\n\n\n\n

Verify the network requirements and connector resource requirements:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

Requirements for AWS:<\/p>\n\n\n\n