Overview of VMware vCloud Availability 3.0 – Provider Deployment

In this post, we will be reviewing the steps on setting up and operationalizing vCloud Availability 3.0 (vCAv) for a provider site.

There is a presumption that you will be deploying for production, so that is what I’ll be reviewing. The consolidated (combined) appliance would be an easier deployment, but still requires the below configurations post-deployment.

Recap of the Provider steps:

  1. Deployment of Cloud Replication Management (CRM) Instance
    1. Initial Replication Management Setup
    2. Initial Setup Wizard
  2. Deploy vCAv Replicator(s)
  3. Deploy vCAv Tunnel
  4. Configuration of CRM instance and start of site wizard
  5. Configuration of Replicator
    1. Pairing Replicator with Replication Manager
  6. Configuration of Tunnel
  7. Validation

Prerequisites

  1. Available DNS and NTP server
  2. SSO Lookup Service Address
  3. Routing and Firewall Ports in place – see below for further insight
  4. vCenter and vCD on interoperability matrix
  5. Certificate Management – all certificates can be managed via the UI utilizing PKCS#12 certificates. Services must be restarted post-import.

Provider Port Mapping

Below is a diagram my esteemed peer, Chris Johnson, worked up for our upcoming EMPOWER presentation.

Takeaways:

  1. Establishing a DNAT rule from 443 to 8048 is crucial for tunnel connectivity. This also has to be set as the API endpoint and will be pushed from the CRM instance.
  2. Ensure we can route and have direct port access between payload/resource vCenters, replicators, and Cloud Management.

Deployment of Cloud Replication Management (CRM) Instance

All of the roles we deploy for the provider will be coming from a single OVF – this is very similar to other VMware based virtual appliances. However, during the OVF deployment process, you will be prompted for the below role selection. For deployment of CRM, select Cloud Replication Management.

Initial Replication Manager Setup

Wait a few moments post-power on for initial configuration to take place, then open a browser to https://crm-fqdn:8441 so we can set the initial lookup service configuration.

We will be prompted for changing the default password. Note this is the same process for any newly deployed vCAv appliance and must be done on initial login –

From our initial screen, we can see that we have two issues: 1) missing Lookup Service settings and 2) Configured Replicators – there is none. The latter is fine for now, we will pair the replicator once we are done with the site wizard.

Let’s go over to Configuration and set the lookup service –

Accept the certificate…

As discussed prior, we will not see any replicators right now and will come back at a later time.

Initial Setup Wizard

Open a new tab to https://crm-fqdn/ui/admin and log in with your root account.

From here, we can see a link to run the initial setup wizard –

This is a very simple wizard that brings us through the site setup. From the beginning, we need to set a sitename. Note that you cannot utilize spaces and it is case-sensitive.

Second, set your public API endpoint address. Note this is where the traffic will ingress in from your tunnel node. In my lab environment, I will be directly connecting over 8048 (compared to traditional perimeter environment that would utilize 443 and DNAT rule to forward that traffic).

Here’s what I would if that was the case.

Next, lookup service address. You’ll be setting this quite a bit. 🙂

vCD configuration – note that you must include /api after the vCD FQDN. Also, during this initial setup, vCAv will take care of publishing the Availability plugin to your vCD instance. On boot of the CRM vCAv appliance (or during any upgrade), the plugin will refresh or push an update if required – very nice.

Apply your vCAv license key –

Consent or remove the check for the VMware Customer Experience Improvement Program (CEIP) –

Finally, we review our desired state. Verify everything looks to your specification, and hit complete.

This will take a few moments for the configuration. You will be prompted to log back in and you will be brought to the vApp Replication Manager Admin UI page. You can now utilize vCD administrative credentials too!

Let’s click on the Configuration link on the left side. As we can see, we still have some work to do for the Replicator and Tunnel configuration.

Deploy vCAv Replicator(s)

Next up, let’s configure the Replicator instance. Repeat this process for every required Replicator needed for your environment.

Open a tab to https://replicator-fqdn/ui/admin

After setting your password, you will be prompted to set the lookup service address –

That’s it for the replicator! Now, we are ready to pair this replicator with the Replication Manager.

Pairing Replicator with Replication Manager

Open your tab to https://crm-fqdn:8441 and browse to Replicators on the left side –

Let’s click the New button and open up the wizard –

We need to provide the fully qualified domain name along with port 8043 (this is what’s utilized for the Replication Manager to Replicator API connectivity) along with the appliance password and SSO administrator credentials.

Once paired, we will see it in the list. Repeat this process for any additional replicators.

Now, from the CRM Provider UI, we can see a newly added Replicator instance. Next up, Tunnel configuration.

Configuration of Tunnel

Final configuration – let’s configure the tunnel for inbound and outbound connectivity. Browse to https://tunnel-fqdn/ui/admin and login –

Once you set your password, you will be prompted to set two things: 1) lookup service address and 2) Public API endpoint

As discussed before, the public API endpoint will be based off of your network topology. For my lab, I am using direct 8048 access. However, if I was going to DNAT from a public IP/FQDN utilizing 443, I would have the following –

Once completed, we will see the two fields completed.

Let’s hop over to the CRM Provider UI configuration and configure the tunnel –

From here, we need to establish CRM to Tunnel API communication, which happens on port 8047 –

Type in the appliance password. Once applied, we will see a tunnel configuration (again, I was using 443 for a period of time, but you will see 8048 for future configurations).

After any port changes, we recommend doing a service restart. This can be achieved by going to System Monitoring and clicking Restart Service –

Validation

After a site deployment and configuration, I always walk through to see service health.

From the main provider UI page, I can see overall system health –

From my System Monitoring page, we can see everything is green and I see my Tunnel and associated Replicators –

From vCloud Director, my plugin is also available too for self-service management.

Final Thoughts:

  1. As depicted above, deployment is rather straight forward and pretty seamless.
  2. Site Deployment must be done on a per-vCD instance basis. So if you have four sites, expect to do this four times.

Next up, Tenant/On-Premises setup.

-Daniel

Utilizing Central Point of Management (CPoM) in VMware vCloud Director 9.7

One of the extremely exciting additions to VMware vCloud Director (vCD) is the ability to present vCenter instances securely to tenant organizations utilizing the vCD user interface – this is referred to as Central Point of Management, or what we abbreviate to as CPoM. Tom Fojta did a great job highlighting what’s new inside of vCD 9.7 here.

In this post, I am going to review the steps required to successfully deploy your first vCenter-SDDC to an organization inside of vCloud Director 9.7. You will need to utilize the CloudAPI, but do not be alarmed, I will walk you through these steps.

First off, what the heck is CPoM?

CPoM is the ability to present a dedicated vCenter instance to an organization, or tenant, via the vCloud Director user interface. In the past, we’ve had many providers providing hosted or dedicated private cloud services.

With the addition of this functionality, we can now utilize vCloud Director to manage both shared and dedicated cloud resources from a single portal.

In essence, the VMware Cloud Provider team is delivering on the promise of transforming vCloud Director into a services platform – and this additional functionality demonstrates that.

So, how do we get started?

High-Level Steps

  1. Add new vCenter instance to vCD Provider Management – UI
  2. Creating a new SDDC instance – API
  3. Publish to specific org/tenant – API
  4. Add Tenant permissions and CPoM Plugin -UI
  5. Proxy Configuration – UI
  6. Enjoy dedicated vCenter-SDDC access via vCD

Adding new vCenter Instance to vCD Provider Management

First up, we need to add this dedicated vCenter instance to the provider management.

My tenant is T1 and will be adding vcsa-01b.corp.local to their organization.

Before, we go into the steps, let’s review the documentation that talks about the high-level steps required.

Managing SDDCs and SDDC Proxies

One important note – you cannot attach an existing vCenter that’s utilized as a provider VDC (pVDC). This is pointed out in the documentation –

First, let’s navigate to vSphere Resources -> vCenters and click the Add button –

Let’s plug in our required connection data –

Next up is the configuration of the NSX-V Manager. I had a conversation with Engineering on this and the applicability for CPoM. While this is not mandatory for accessibility, a tenant can also proxy NSX commands via the proxy configuration. Therefore, depending on your use case, you may or may not want to set this up.

Once completed, we can now see the new vCenter (and what I called vCenter-T1 since it will be dedicated to organization T1) being added to the vCD Provider UI.

Once the operation is complete, we should see this as enabled, but not published to a SP or Tenant.

Creating a new SDDC instance

This has be done via the CloudAPI. First off, let’s explore the new API Explorer which provides some examples and how to parse this utilizing Postman, Curl, or whatever you choose. Navigate to https://vcd-fqdn/api-explorer/provider

Under the sddcs section, we have the following commands available –

Okay, let’s get our bearer-token first. If you are new on setting up Postman for connectivity, Fojta did a great blog post on utilizing the new bearer token with the CloudAPI functionality here.

Get our initial token and pass it through as a variable –

POST https://vcd-fqdn/api/sessions

Now, I want to view the current list of sddcs inside of this vCD instance. I realize we do not have any as of yet, but let’s see what it returns.

GET https://vcd-fdqn/cloudapi/1.0.0/sddcs

As expected, we do not have any SDDCs just yet. Let’s create our first one!

Our POST command will require a JSON body like the below. There are many more fields, but these are the required fields.

{
  "name":"<name of your new SDDC>",
  "description":"<description for your new SDDC>",
"vcId":"<ID of the VC recorded>"
}

But before we add it, we have a prerequisite – we need to get the vCenter ID of the newly added vCenter instance.

To do this, we need to run a GET command to vCenter ID. You will need to run the following:

GET https://vcd-fdqn/api/admin/extension/vimServerReferences

Okay, here’s my results –

And here is my “vCenter-T1” ID!

So for my vCenter-T1, my ID is the following:

id="urn:vcloud:vimserver:419173a9-56bd-471f-929c-3f00c287d21b"

We will add this to the body for when we add this as a new SDDC.

Creation of my JSON body –

{
"name":"vCenter-T1",
"description":"T1 dedicated vCenter",
"vcId":"urn:vcloud:vimserver:419173a9-56bd-471f-929c-3f00c287d21b"
}

Alright, ready to hit the Send button…

And accepted…

I could use the Postman API to check the task, but I also see it running in the UI…

Completed!

Let’s check and see what we have from the API now. Excellent, we now see vCenter-T1 as a new SDDC –

We also see the new ID for this SDDC:

This will be important as we will need this to publish it to the organization T1. First, let’s check and ensure it’s not published to anyone yet.

GET https://vcd-fdqdn/cloudapi/1.0.0/sddcs/urn:vcloud:sddc:29bf292b-07df-4d2f-9155-97dce2bad95d/tenants

As expected, no one has this from a tenant perspective –

Next pre-requisite – we need to get the orgID so we can create the body for the POST to publish this to T1. Our body will need to look like this:

[
{
"name":"org1Name",
"id":"URN-ID"
}
]

Okay, let’s do a GET to /api/org –

Now, let’s crack open the T1 org further – /api/org/<org-ID> to get the URN –

So for my T1 organization, my ID is:

id="urn:vcloud:org:efb57814-44f2-4f60-9848-215be81f1294"

Assembling my body for the POST –

[
{
"name":"T1",
"id":"urn:vcloud:org:efb57814-44f2-4f60-9848-215be81f1294"
}
]

Let’s send it!

Got a 200 OK –

Now, if I do a GET to see what tenants/orgs have it..

GET https://vcd-fqdn/cloudapi/1.0.0/sddcs/urn:vcloud:sddc:29bf292b-07df-4d2f-9155-97dce2bad95d/tenants

We can see T1 has it published:

Behold, I can see the new vCenter-T1 from my T1 Org Admin! But why is it showing a red X?

Because by default, when you add the new SDDC, it defaults to false on “enabled”

So we have to enable it, here’s the body for my PUT – (changed it from false to true)

{
"name": "vCenter-T1",
"id": "urn:vcloud:sddc:29bf292b-07df-4d2f-9155-97dce2bad95d",
"enabled": true,
"vcId": "urn:vcloud:vimserver:419173a9-56bd-471f-929c-3f00c287d21b"
}

Successful….

And green check mark in the T1 org admin view!

Add Tenant permissions and CPoM Plugin

By default, the rights bundles and the organization admin global role does not have SDDC access. Also, we need to publish the CPoM Plugin. Let’s do that first.

Under Provider UI, hit the hamburger menu -> Customize Portal, check the CPoM Extension and Publish –

Publish to selected tenants –

Let’s now provide the correct permissions.

On the Provider UI, toggle to Administration -> Tenant Access Control -> Rights Bundles – select the respective rights bundle you need to provide SDDC access and click Edit:

Under Infrastructure – SDDC, we can see the SDDC View and Manage option. Click View –

Ensure this rights bundle is published to your respective organizations –

Now, under Organization Administrator for the Global Role, add this new view permission –

Finally, publish –

Now, any organization admin can see the associated/published SDDC from their login. This can also apply to another role you might deem necessary.

Proxy Configuration and Logging In

There are three steps that need to take place for successful login:

  1. Checking out the default proxy to line up to the vCD VIP/cells
  2. Activating the proxy
  3. Downloading and configuring the proxy configuration file
  4. Importing the .PEM for certificate management

First, let’s GET the existing proxy configuration –

https://vcd-fdqn/cloudapi/1.0.0/sddcsProxies

Now let’s get the explicit body for this default proxy –

GET https://vcd-fqdn/cloudapi/1.0.0/sddcProxies/urn:vcloud:sddcProxy:625ddc5a-66ee-4d1a-94a3-603a83604cd2

Now if I wanted to create a specific one, I can do a POST and do the following –

We can now see I have two proxies now. So, this is a great way to explicitly state what you’re trying to do.

Next, click on Manage Proxies –

Activate the default proxy –

Now activated, one can download the proxy configuration file, configure it to your browser and also download the proxy certificate (and upload it).

The proxy configuration file is pretty basic –

We can also see how it does the redirection from the cell to the T1-vCenter (check the bottom URL):

Again, before we can successfully login, ensure you’ve configured your browser for the PAC/proxy configuration. If you click the ? icon, there is a tutorial on configuring it for Chrome, Firefox, etc.

Once clicked, you are prompted for the org user along with the access token, and voila! Login.


Conclusion

I am extremely pleased with this new functionality inside of vCloud Director. While you need to know how to utilize the CloudAPI for initial configuration, it’s quite simple and elegant to utilize with Postman. The API-Explorer provides examples too. This is the first iteration of the CPoM service and will only get better as time progresses.

I believe this is a solid use case for dedicated private cloud alongside existing cloud organization VDCs – great way to provide distinct cloud services in a secure manner.

More to come, enjoy!

-Daniel

Overview of VMware vCloud Availability 3.0 – Introduction, Roles, Deployment Process

In this series of blog posts, I will be discussing the new release of VMware vCloud Availability 3.0 (vCAv). This is a very exciting release for the VMware Cloud Provider team. vCAv 3.0 will be out shortly (by end of our fiscal quarter) and I want to provide my insight into this platform. I will be focusing on the following points –

  1. Introduction to vCAv 3.0
  2. High-Level Architecture
  3. vCAv 3.0 Service Roles
  4. Deployment Process
  5. Deployment Approach for Provider
  6. Deployment for Tenant (On-Premises)
  7. Protection Workflow
  8. Resources

Introduction to vCAv 3.0

First off, let’s discuss what vCAv provides from a functionality perspective. vCAv is what I like to call “functional convergence.” In the past, we had many different products that provided some level of availability or migration capability –

In my opinion, this was a duplication of appliances and could be confusing to customers. The team has done a great job of putting forth a significant investment into vCAv 3.0 to simplify the architecture. Therefore, here’s where we are today –

Therefore, no need for multiple tools for migration, DR from/to Cloud, or between Clouds. We now have a single solution that answers all of the above.

vCAv 3.0 Key Functionality

So what does vCAv 3.0 provide?

  1. Simple, Unified Architecture
    1. There is a single OVF for the Provider and the Tenant. On the Provider side, each role can be easily deployed used by the vSphere Client or CLI.
    2. Deployment is very intuitive and scalable – each role can be quickly deployed in a matter of minutes.
    3. On-Premises Appliance is unified and provides vCenter UI integration for management.
  2. On-Premises Migration and Protection
    1. On-Premises appliance provides the same UI experience as connected to the Cloud instance, but built into vCenter.
    2. Migration and/or protection of workloads can be done with a few clicks.
    3. Allows for protection/migration to and from vCloud instances.
  3. Cloud to Cloud Migration and Protection
    1. Very similar behavior to C2C 1.5, we can protect workloads (vApps and VM’s) between vCD instances.
  4. Network Mapping and Re-Addressing
    1. One of the new additions is the ability to re-address and map out protected workflows for faster recovery at the destination site.
    2. This maps to existing vCD oVDC Network constructs such as Static IP pools.
  5. Scale
    1. As discussed before, the team is aware of scalability requirements for Providers. For this version, here is the stated guidelines:
      1. 300 tenants with active protections paired to vCloud Director instance
      2. 20 vCAv Replicator instances per instance
      3. 500 active protections per vCAv Replicator instance
      4. 9,500 active protections across tenants to a Cloud
      5. 5TB protected VM size (contingent upon Cloud storage)

Business Value

Direct and native vCloud Director integration for providers and tenants – with the ability to provide self-service, this provides a unique experience that meets DRaaS requirements and migration functionality.


Ease of Operationalization – I’ve done several deployments during the development process and it’s one of the easiest VMware Cloud Provider solutions to deploy. Once we review the roles and concepts, anyone should be able to operationalize this with ease.

Cost-Effective Approach – vCAv 3.0 will be part of the VMware Cloud Provider Program (VCPP). This is based on the monthly consumption of points, which is a very cost-effective solution that can be modeled and productized for DRaaS and migration offerings.

High-Level Architecture

In the following diagram, we can see how this all comes together with a single, on-premises vCenter along with two vCD instances. One can pair this up with vCD multi-site federation capability.

Moreover, this pairs very well with existing vCD services such as CrossVDC Networking or L2VPN connectivity between on-premises and organization VDCs.

vCAv 3.0 Service Roles

Let’s review the distinct service roles of vCAv 3.0.

Provider

On the Provider side, we have the following –

  1. Cloud Replication Management
    1. This is a logical entity that consists of the core of vCAv 3.0.
    2. vCloud Availability Portal – User Interface for the tenant and provider. All UI configuration ingresses from this service and applies all to all necessary connected components.
    3. vCloud Availability vApp Replication Manager – communicates directly to vCD and understands tenancy constructs such as organizations, vApps, etc. Also responsible for enabling protections or migrations.
    4. vCloud Availability Replication Manager – understands vCenter and ESXi concepts and will interoperate between the replicators and protected vCenters.
  2. vCloud Availability Replicator – lightweight node responsible for executing on the host-based replication from a specific host. Typically, you deploy a replicator per vCenter.
  3. vCloud Availability Tunnel – this is the tunneling service that is responsible for providing secure connectivity between on-premises vCenter(s) and connected vCD instances.

Each of these roles can be deployed separately or in a combined virtual appliance. For production deployments (which we will review later), the recommendation is standalone deployments for each role.

Tenant / On-Premises

On the tenant side, we have a single appliance that has a combined appliance approach –

  1. vCloud Availability Replicator – just like on the Provider side, the Replicator is responsible for executing the host-based replication (HBR) process
  2. vCloud Availability Tunnel – provides secure connectivity between on-premises and vCloud environment. All traffic securely ingresses and egresses through this service.
  3. vCloud Availability Plugin – this plugin provides local vCenter UI management that is the same experience as connecting the vCAv Cloud environment.

Deployment Process

While this blog series will cover the Provider and On-Premises side in further detail, we will have the following steps to execute on for a successful deployment.

Provider:

  1. Deployment of Cloud Replication Management (CRM) Instance
  2. Deploy vCAv Replicator(s)
  3. Deploy vCAv Tunnel
  4. Configuration of CRM instance and start of site wizard
  5. Configuration of Replicator
  6. Configuration of Tunnel
  7. Validation

Tenant:

  1. Deploy vCAv On-Premises Appliance
  2. Start configuration wizard
  3. Connect to vCAv Cloud Tunnel
  4. Configuration of local placement
  5. Validation

Next up, I will review the Provider deployment process in further detail while providing the step-by-step procedures. Stay tuned!

-Daniel

VMware vCloud Director – Installation of PostgreSQL and Migration from Oracle

In one of my lab instances, I currently have Oracle still running as my backend vCloud Director database. In this post, I am going to document the steps it takes to install Postgres10 and migrate away from Oracle.

Preparation

First, taking a snapshot of my vCD instance – always back up before making any type of database changes! 🙂

Next, my system is a little dated, so I am running a yum update to get all of the latest binaries before we install PgSQL.

I am also running RHEL, so your steps may different based on your distribution.

Installing and Starting PostgreSQL 10

My esteemed colleague, Sean Smith, wrote a nice post on setting up an all-in-one vCD appliance here so I am going to borrow his steps on installing PgSQL 10.

Get the RPM and start the install –

rpm -Uvh https://yum.postgresql.org/10/redhat/rhel-7-x86_64/pgdg-centos10-10-2.noarch.rpm
yum install postgresql10-server postgresql10

Let’s initialize the database –

service postgresql-10 initdb

From there, using chkconfig to enable it to start on boot –

chkconfig postgresql-10 on

Ready to start!

service postgresql-10 start

Let’s change the password to the default postgres account (ignore my superweak password) –

Before we can make the authentication change, we need to set the default postgres user password.

Switch user to postgres and type in psql followed by a \password to set it –

su - postgres
psql
\password

\q and go back into the root console.

Finally, we need to allow authentication to the database. I am going to allow full access to local and remote logins to the database.

Edit the /var/lib/pgsql/10/data/pg_hba.conf file and modify this line –

local all all  peer

to

local all all md5

And adding this line below –

host all all 0.0.0.0/0 md5

Now, edit the postgresql.conf file and remove the # from the ‘listen_addresses line –

Finally, restart the postgresql-10 service –

We are now ready for the next step which is creating the new vCloud database that we can move over to.

Setting up the new vCloud database on PostgreSQL 10

We are now ready to create our new database and prepare it for the migration.

First, let’s switch user over to the postgres account and enter psql –

su - postgres

We need to create the vcloud account with a password –

create user vcloud with password 'vcloudpass';

Now I’m ready to create my vcloud database. I already have my vcloud user account on the system, so no need to create that again. Following these instructions from the VMware master docs.

create database vcloud owner vcloud;

Finally, altering it so it enables the database owner on login:

alter role vcloud with login;

From here, one can setup SSL for secured communication. Since this is my lab, I’m going to skip over that configuration.

Stopping the vCD Instance and Migrating

Let’s stop the vCD service –

Now we can follow the instructions here on the documentation on using the cell-management-tool for dbmigrate

cell-management-tool is under /opt/vmware/vcloud-director/bin –

Now we are ready to run the cell-management-tool dbmigrate command. For me, this was my configuration – it will differ based on your setup.

./cell-management-tool dbmigrate -dbhost vcd-01a.corp.local -dbport 5432 -dbuser vcloud -dbname vcloud -dbpassword vcloudpass

Processing….

Awesome!

Ready now to run the reconfigure-database command, and boom! Complete.

/opt/vmware/vcloud-director/bin/cell-management-tool reconfigure-database -dbhost vcd-01a.corp.local -dbport 5432 -dbuser vcloud -dbname vcloud -dbpassword vcloudpass -dbtype postgres

Let’s start back up vCD….

We are back up and running!

Lessons Learned

  1. While this was not a difficult task, every distribution is different, inclusive of Sean’s post where he did the installation and setup of PostgreSQL-10.
  2. The cell-management-tool works great for database migrations to PostgreSQL-10.
  3. Note that I did not setup SSL communication. This requires further steps to set it up. Sean did a great job on the steps here.
  4. Test, test, test before you do this in production.

Thanks!

-Daniel