Next: vRA Part 4 – IaaS Server Deployment –>
Ok, now that we’ve established the need for a dedicated management cluster to host the vRA management components, lets look at the deployement highlights of the vRA components within the management cluster.
- vRA Identity Appliance:
- If you want to use the vRA’s own identity management appliance, that should be the first component to be deployed. Deployment of this appliance is pretty straight forward and is self explanatory, hence I will not be covering here. However I will instead be using the vSphere SSO as the identity management source for vRA environment also, in order to keep all authentication for the my virtual infrastructure centralised (and simple).
- But if you are NOT planning on using vSphere SSO, make sure you download the vRA identity appliance from VMware and deploy on to the management cluster.
- Once deployed, ensure to configure the time zone and the NTP server settings using the management IP (specified during the Appliance deployment)
- vRA Appliance deployment
- Download the vRA appliance from VMware. Documentation for the latest release can be found here
- Deploy the appliance on to the Management Cluster using the vCenter server that manages it. You would need the following information during the deployment
- Configure the vRA Appliance
- Once the appliance deployment is complete, use the URL https://<FQDN/IP of the vRA appliance>:5480 to access the management interface
- Login with username root and password as specified during the deployment
- Set up the Time Zone (System->Time Zone)
- Set up the Host name (Network->Address) & Proxy server (Network->Proxy) if applicable
- Set up NTP to sync time (Admin->Time Settings)
- Set up the vRA specific settings
- Setup SSL (vRA Settings->Host Settings) – You can either self generate a Certificate or import a certificate obtained from a CA
- Set up SSO (vRA Settings->SSO) – You can connect to default vRA identity appliance or the vSphere SSO (>5.5 1b) as below using default SSO admin account. Note the following key points regarding the SSO host name
- Important Note: If you have an existing vRA / vCAC deployment already that is using a vSphere SSO server, note that you CANNOT use the same SSO server for another vRA server. I had number of issues when I attempted this, and the most notable one 1 where the non of the group / roles created within the default tenant (such as infrastructure admin & tenant Admin) would work and may come up with “401 – Unauthorized: Access is denied due to invalid credentials” error when logged in. This doesn’t appear to be correctly documented so watch out, but shouldn’t apply to most as its unlikely that you’d have multiple vRA deployments in the same organisation. the only way around this (if you have to use the same SSO source for multiple vRA’s) is to create a tenant rather than using the default tenant. Note the tenant name should be unique within the whole SSO too (if you have Tenant-A in vRA-A, you cannot add another Tenant-A on vRA-B using the same SSO)
- Host Name: When using the vSphere SSO server, host name should have the same case as what’s been registered in the vCenter SSO (if unsure, browse to https://ssoserver:7444/websso/SAML2/Metadata/vsphere.local and save the vsphere.download file when prompted. Open the vsphere.download file in notepad or some text editor. Locate the entityID attribute of the EntityDescriptor element. Use the SSO server name in the way its specified here paying attention to the case)
- Port: 7444 in the host name for the vCenter SSO is NOT required with the vRA6.2.1 (this was required to be specifically specified in the host name field with the earlier versions of vCAC)
- Add the appropriate license.(vRA Settings->License). It should be noted here that the license key added here should be the vRA standard or vRA Adavnced and not the vCloud suite license.
- Database connectivity (vRA Settings->Database) can be ignored in most cases unless you want to connect to an external Postgre SQL server / cluster
- Messaging (vRA Settings->Messaging) can also be ignored as this should have been automatically configured.
- Cluster configuration (vRA Settings->Cluster) can be bypassed unless you are creating a vRA appliance cluster in which case you can join an existing cluster here.
- Once all above are configured, allow couple of minutes and ensure all vRA services are now registered within the “Services” tab.
- Configure the Identity stores
- Here, you can create new tenants (for a multi tenant deployment) or use the default tenant (automatically created). I’m going to use the default tenant here.
- Login to vRA UI using the URL “https://<FQDN of the vRA Appliance>/shell-ui-app” with the default SSO administrator credentials (Administrator@vsphere.local). The default vSphere.local tenant should be available.
- Click on the vSphere.local, go to Identity stores and verify the default domain name listed (by default, the native ad domain would have been added here)
- If you need a separate identity / authentication realm (AD or open LDAP supported), you add it here
- Setup Tenant Administrators for the tenants
- Add the inbound and outbound email servers within the Email Servers tab on the left
- (Optional) Set up branding for the vRA user interface if required using the Branding tab
That’s it, the vRA appliance is not set up and the Tenant Admin account is also setup. Next up would be the IAAS server installation.