Configuring HA Cloud Proxy and DR Cloud Account in Cloud Assembly (SKKB1055)

In this blog post we are going show how to configure a Highly Available (HA) Cloud Proxy in VMware Cloud Assembly. Same setup can be used to configure a Cloud Accounts for Disaster Recovery (DR) / Hotspare scenarios.

 

Update Log:

Introduction

Cloud Assembly does not offer a native way to configure a Cloud Proxy for high availability nor an obvious way to configure Cloud Account for DR/Hotspare. We are going to examine the following use cases:

  • UC01: Configuring a HA Cloud Proxy for a single vCenter Cloud Account
  • UC02: Configuring an DR vSphere Cloud Account.
  • UC03: Configuring HA Cloud Proxy and a DR vSphere Cloud Account. (UC01+UC02)

UC01: Configuring HA Cloud Proxy

Let’s see how we can achieve the first use case.

In this case we have a single vCenter server. Because Cloud Assembly will not let me add the same vCenter twice as a Cloud Account with the same name, I had to create an alias record for the same vCenter and NSX-T Endpoint.
So we end up with:

  1. DNS: vcsa-01a.corp.local and vcsa-01a-hotspare.corp.local, nsxmgr-01a.corp.local, nsxmgr-01a-hotspare.corp.local.
  2. All vCenter DNS records point to the same vCenter and all NSX records point to the same NSX Manager
  3. 2 Cloud Accounts. Each of which connected to the same vCenter and NSX Manager (different DNS’s) via different Cloud Proxy.
  4. For each NetworkA, StorageA and ImageA profile created for CloudAccountA we have the same created for CloudAccountB. These all point to the same networks, datastores and images. All A profiles have the same tags ass all B profiles.

Now as you have seen from the screenshots we have vCenter (On-Prem) (CloudAccountA) and vCenter (On-Prem) – Hotspare (CloudAccountB) Cloud Accounts. We can set provisioning path in two ways:

  • Use constraint tags in the BP to preferably provision on CloudAccountA and If this is not responding/available for deployment, use CloudAccountB. Our BP will have the same constraints for network, storage and image profiles, but it will have a soft constraint for the cloud account pointing to CloudAccountA. Again from the screenshots we can see that CloudAccountA has a tag cas.clouid.account.cap:primary (account.constraint:A) and CloudAccountB has a tag cas.clouid.account.cap:hotspare (account.constraint:B). By specifying account.constraint:A:soft in our blueprint we can guide the deployment to our Primary path. If this path is not available for deployment, as we are using a soft constraints, deployment will go to the Hotspare path. In this case note that the cloud zone priority on a project level for both cloud zones is the same.

  • Use Cloud Zone priority on a Project level to achieve the same. In this case we will guide the deployment by selecting higher (0) priority for the Primary deployment path and lower (1) priority for the Hotspare path. As we are using priority to guide the deployment all profiles and account have the same tags and we are not using any soft tags in the blueprint. 

If I run a deployment it will:

  • Use Network Profile A, Storage Profile A, Image Profile A, Cloud Account A, Cloud Proxy A to connect to vCenter A

If I simulate a failover (e.g. disconnect Cloud Proxy A from the network) and run a deployment it will:

  • Use Network Profile B, Storage Profile B, Image Profile B, Cloud Account B, Cloud Proxy B to connect to vCenter A

 

UC02: Configuring DR vSphere Cloud Account

Now to achieve DR/Hotspare use case where we have two different vCenter and we want to use one for failover/hotspare, we can use very similar approach
So we end up with:

  • Two vCenters
  • Distinct Network , Storage , image profiles and Cloud Accounts and Proxies for each vCenter.
  • We can exactly the same configuration of all these profiles and accounts , including all the tags, as shown in the screenshots at the beginning.

Now if we consider the same screenshots we have vCenter (On-Prem) (CloudAccountA) and vCenter (On-Prem) – Hotspare (CloudAccountB) Cloud Accounts. These are now connected to two different vCenters. We can set provisioning path in two ways, same as before:

  • Use constraint tags in the BP to preferably provision on CloudAccountA and If this is not responding/available for deployment, use CloudAccountB.

  • Use Cloud Zone priority on a Project level to achieve the same. In this case we will guide the deployment by selecting higher (0) priority for the Primary deployment path and lower (1) priority for the Hotspare path.

If I run a deployment it will:

  • Use Network Profile A, Storage Profile A, Image Profile A, Cloud Account A, Cloud Proxy A to connect to vCenter A

If I simulate a failover (e.g. disconnect Cloud Proxy A from the network) and run a deployment it will:

  • Use Network Profile B, Storage Profile B, Image Profile B, Cloud Account B, Cloud Proxy B to connect to vCenter B

UC03: Configuring HA Cloud Proxy and DR vCenter Cloud Account

IN this use case we just need to do a combination of UC01 and UC02. Which means we will create a second set of profiles/accounts/proxies to point to the same vCenterA. We will then multiple this by two and create the same for vCenterB. Same tagging and priority strategy apply.

 

 

 

Final Step

If all went well, go grab a beer.

DISCLAIMER; This is a personal blog. Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity, unless explicitly stated. Any views or opinions are not intended to malign any religion, ethnic group, club, organization, company, or individual.
All content provided on this blog is for informational purposes only. The owner of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. The owner will not be liable for any errors or omissions in this information nor for the availability of this information. The owner will not be liable for any losses, injuries, or damages from the display or use of this information.
Photos
Unless stated, all photos are the work of the blog owner and are licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. If used with watermark, no need to credit to the blog owner. For any edit to photos, including cropping, please contact me first.
Recipes
Unless stated, all recipes are the work of the blog owner and are licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. Please credit all recipes to the blog owner and link back to the original blog post.
Downloadable Files
Any downloadable file, including but not limited to pdfs, docs, jpegs, pngs, is provided at the user’s own risk. The owner will not be liable for any losses, injuries, or damages resulting from a corrupted or damaged file.
Comments
Comments are welcome. However, the blog owner reserves the right to edit or delete any comments submitted to this blog without notice due to
– Comments deemed to be spam or questionable spam
– Comments including profanity
– Comments containing language or concepts that could be deemed offensive
– Comments containing hate speech, credible threats, or direct attacks on an individual or group
The blog owner is not responsible for the content in comments.
This policy is subject to change at anytime.

Leave a Reply

Your email address will not be published. Required fields are marked *