Vcac

I am aware that that’s not a catchy blog post title. In fact, it doesn’t even really describe the problem or solution very well - for that I need to go into a little bit more depth!

Suppose I have configured a Reservation with two Networks ticked (“192.168.1.0-VLAN1” and “192.168.10.0-VLAN10”). As you can see in the screenshot below, each of the networks has a Network Profile created and assigned with a network pool to provide IP addressing for the VMs.

With the release of vCAC 6.1 there have been some great improvements in the setup of the clustered vCAC appliances - none of the previous copying of configuration files between appliances - just a simple wizard to do it all for you. In my opinion this is superb.

You’ll need to have deployed a load balancer of some sort - vCAC 6.0 build-out to distributed model – Part 3.1: Configure Load Balancing with vCNS or vCAC 6.0 build-out to distributed model – Part 3.2: Configure load balancing with NSX

SSO is a fundamental requirement when deploying vCAC, whether for a distributed or simple installation. This walk through goes through the deployment and configuration of the vCAC Identity Appliance, which provides a stand alone SSO instance for vCAC.

Some of the posts in this series are completed with vCAC 6.0.1, others will be with 6.1. Where there are differences I will aim to point them out!

This was a fun little error, whilst installing the distributed IaaS roles I couldn’t seem to get the IaaS components to install – when I got the Website and Model Manager Data install it would fail with the following message:

I’ve pasted it in here because I couldn’t find anything through google that referred to my error messages – hopefully if you’re reading this you’ve found it because you’re looking for it!

This is the fourth article in a series about how to build-out a simple vCAC 6 installation to a distributed model.

By the end of this post we will have deployed a second vCAC Appliance, clustered it with the first appliance and registered the load balanced URL with the Identity Appliance. This will mean logging on to https://vcloud.definit.local/shell-ui-app will be successful.

An overview of the steps required are below:

This is the second part of the 3rd article in a series about how to build-out a simple vCAC 6 installation to a distributed model.

By the end of this part, we will not have modified the vCAC deployment in any way, we’ll just have 3 configured load balanced URLs

An overview of the steps required are below:

This is the first part of the 3rd article in a series about how to build-out a simple vCAC 6 installation to a distributed model.

By the end of this part, we will not have modified the vCAC deployment in any way, we’ll just have 3 configured load balanced URLs

An overview of the steps required are below:

This is the second article in a series about how to build-out a simple vCAC 6 installation to a distributed model.

The diagram below shows the deployment at the end of this part, with vPostgres deployed and the vCAC Appliance running from the remote database.

An overview of the steps required are below:

• Issue and install certificates
• Deploy an external vPostgres appliance and migrate the vCAC database
• Configure load balancing
• Deploy a second vCAC appliance and configure clustering
• Install and configure additional IaaS server
• Deploy vCenter Orchestrator Appliance cluster

Create the required DNS records

First of all, create DNS records for your vPostgres database server – you need both an A and PTR record. Most VMware appliances will check for a reverse DNS lookup when they boot and will set the hostname accordingly.

This is the first article in a series about how to build-out a simple vCAC 6 installation to a distributed model.

In a simple installation you have the Identity Appliance, the vCAC appliance (which includes a vPostgres DB and vCenter Orchestrator instance) and an IaaS server. The distributed model still has a single Identity Appliance but clusters 2 or more vCAC appliances behind a load balancer, backed by a separate vPostgres database appliance. The IaaS components are installed on 2 or more IaaS Windows servers and are load balanced, backed by an external MSSQL database. Additionally, the vCenter Orchestrator appliance is used in a failover cluster, backed by the external vPostgres database appliance.

On the 3rd of June we had our second South West UK VMUG  and I am pleased to say it went superbly well.

As before we held it at the Mshed facilities in Bristol.

We had a great day with many sessions from sponsors,vendors and community speakers alike!

Big thanks go to our speakers that day who were..