DefinIT

vCAC 6.1 – Creating a user selectable network dropdown that sets Network and Network Profile correctly

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.

image

When I deploy the Blueprint without any custom properties, the network selection is round-robin and so the VM gets it’s virtual NIC assigned to “192.168.1.0-VLAN1” or “192.168.10.0-VLAN10” alternately – this is the expected behaviour. The Virtual Machines are assigned an IP address based on the Network Profile of the assigned network.

All good so far. Still with me? (more…)

vCAC 6.1 build out to distributed model: Clustered vCAC Appliances

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

Deploy vCAC Appliances

Deploy three vCAC appliances by running through the OVF deployment wizard, two to be configured as vCAC Appliance nodes and one to be the external vPostgres database.

  • vCAC-61-PG-01.definit.local
  • vCAC-61-VA-01.definit.local
  • vCAC-61-VA-02.definit.local

image image

image image (more…)

vCAC 6.0/6.1 build out to distributed model: Deploy the Identity Appliance

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!

Deploying the OVF

Deploying the OVF is very simple, just run through the wizard:

image image

image image

image image

image image

The appliance will perform a reverse lookup to get it’s hostname – if you have pre-staged a DNS A and PTR record, and have a reservation set for the VM. If you statically assign an IP address, make sure you use the FQDN in the hostname field – not doing so will cause issues with the self-signed certificates and also when you join the Active Directory domain. (more…)

HTTP Error 500 installing vCAC IaaS Model Manager Data

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:

##InitializeRepo Registering solution user in the VA, initializing Repository MetaModel and Authorization 
"C:\Program Files (x86)\VMware\vCAC\Server\Model Manager Data\Cafe\Vcac-Config.exe" RegisterSolutionUser -url https://vcloud.definit.local --Tenant "vsphere.local" -cu "administrator@vsphere.local" -cp ******  --FileName "C:\Program Files (x86)\VMware\vCAC\Server\Model Manager Data\Cafe\Vcac-Config.data" -v 
    VMware.Cafe.HtmlResponseException: Internal Server Error (500) 
    at VMware.Cafe.JsonRestClient.<HandleErrorResponse>d__8d`1.MoveNext() 
  --- End of stack trace from previous location where exception was thrown --- 
     at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
     at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
     at VMware.Cafe.JsonRestClient.<CreateResource>d__2d`1.MoveNext() 
  --- End of stack trace from previous location where exception was thrown --- 
     at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
     at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
     at VMware.Cafe.ComponentRegistryClient.<CreateSolutionUserAsync>d__5.MoveNext() 
  Http response: 
  StatusCode: 500, ReasonPhrase: 'Internal Server Error', Version: 1.1, Content: System.Net.Http.StreamContent, Headers: 
  { 
    Vary: Accept-Encoding 
    Vary: User-Agent 
    Connection: close 
    Date: Thu, 10 Jul 2014 23:20:43 GMT 
    Content-Length: 3784 
    Content-Type: text/html; charset=utf-8 
  } 
  Warning: Non-zero return code. Command failed. 
C:\Program Files (x86)\VMware\vCAC\Server\Model Manager Data\DeployRepository.xml(556,5): error MSB3073: The command ""C:\Program Files (x86)\VMware\vCAC\Server\Model Manager Data\Cafe\Vcac-Config.exe" RegisterSolutionUser -url https://vcloud.definit.local --Tenant "vsphere.local" -cu "administrator@vsphere.local" -cp ******  --FileName "C:\Program Files (x86)\VMware\vCAC\Server\Model Manager Data\Cafe\Vcac-Config.data" -v" exited with code 1. 
Done Building Project "C:\Program Files (x86)\VMware\vCAC\Server\Model Manager Data\DeployRepository.xml" (InitializeRepo target(s)) -- FAILED. 
Build FAILED.

image

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!

I tried all sorts of things before noticing the HTTP header – specifically the Date – which showed an incorrect time. I jumped on the VCAC appliances via SSH and checked the time using “date”. One of my appliances was indeed out of skew – somehow the NTP service had been stopped after I configured it previously.

I edited the ntp.conf (vi /etc/ntp.conf) and checked I had entries in there – e.g. “server 0.uk.pool.ntp.org” and then started the NTP daemon using “rcntp start”, then sync’d using “rcntp ntptimeset”

The moral of the story – check time sync on ALL vCAC components – it’s important!

vCAC 6.0 build-out to distributed model – Part 4: Deploying and clustering a secondary vCAC Appliance

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.

vCAC deployment with clustered and load balanced vCAC Appliances

vCAC deployment with clustered and load balanced vCAC Appliances

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

(more…)

vCAC 6.0 build-out to distributed model – Part 3.2: Configure load balancing with NSX

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

image

vCAC Simple Install with vPostgres deployed and load balancers prepared

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

(more…)

vCAC 6.0 build-out to distributed model – Part 3.1: Configure Load Balancing with vCNS

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

image

vCAC simple configuration with vPostgres and Load Balancers prepared

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

(more…)

vCAC 6.0 build-out to distributed model – Part 2: vPostgres

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.

vCAC topology with vPostgre

vCAC deploymnent with vPostgres deployed

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

(more…)

VCAC 6.0 build-out to distributed model – Part 1: Certificates

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

image

Simple vCAC deployment

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.

The distributed model can improve availability, redundancy, disaster recovery and performance, however it is more complex to install and manage, and there are still single points of failure – e.g. the vPostgres database is not highly available and although protected by vSphere HA could be the cause of an outage. Clustering the database would provide an improved level of availability but may not be supported by VMware. Similarly the Identity Appliance is currently a single point of failure, although there are also options for high availability there too.

An overview of the steps required is 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

(more…)

Sponsors