One-to-One NAT environments allow you to perform both SNAT and DNAT for all machines provisioned behind and NSX Edge Gateway. For each machine provisioned onto the One-to-One NAT network an External IP is added to the Edge gateway for the NAT translation. The External IP is assigned from the External Network Profile that is assigned to the One-to One NAT Network Profile. Although the One-To-One NAT network will use NAT translation to communicate with the upstream networks (North – South) it is routed to other networks connected to the same NSX Edge Gateway. When deploying a multi-tier application that has multiple network tiers attached to an NSX Edge Gateway all the back-end networks are routable so it’s important no to re-use IP space across different Network Profiles.
In the below diagram there are three Multi-Machine apps. Each one has three web servers, two app servers, and two database servers. The database servers are on a private network, no NAT translation to the upstream networks. The App servers are using a One-to-Many NAT network where they are using SNAT to get access to the upstream network, and the Web Servers are using DNAT for both inbound and outbound traffic. You will notice that each of the Multi-Machine Apps are using the same Up address on the backend, however the IP’s assigned to the NSX Edge Gateway’s external interfaces are different. Notice for the One-to-One NAT that there is an equal number of external IP address. Lao notice in this scenario where we are using both One-to-One and One-To Many the external IP’s are on the same subnet. They all should come from the same External Network Profile that the related to the network that the NSX Edge Uplink interface is provisioned to.
Private networks have no upstream (North – South) NAT or routing when they are deployed. They are networks attached to the deployed NSX Edge Gateway that have East – West routing to other netowrks attached to the same NSX Edge Gateway and that is it. Due to this unlike the other NSX related Network Profiles we can create the Private Network Profile does not need to have an External Network Profile attached to it. It’s simply a range of IP’s to be used for the machines provisioned on to the network.
In the below diagram the blue network will be my private network. Machines placed on the blue network will only be able to communicate with machines placed on the orange or green network and not anything upstream. I can also limit it’s communications further by using security policies which we will discuss as a separate topic
The out of the box vCAC –> NSX integration requires the use of Multi-Machine blueprints. Multi-Machine blueprints are basically a blueprint that pulls together one of more single-machine blueprint. In order to create a three tier web application like the one I will be walking through we will need three standard blueprints to utilize within our Multi-Machine blueprint. In the below example will be configuring a Multi-Machine blueprint that will deploy an NSX Edge Gateway on to it’s own reservation and then deploy three different blueprints each onto a different network specific to it’s tier. Example below:
I will be walking through how to create a Multi-Machine blueprint that will build out the equivalent of the above diagrams Multi-Machine App.
When integrating vCAC with NSX you will need to configure reservations for use with NSX. Depending on your configuration you may need one or more reservations. One reservation for your provisioned workloads, and one reservation for the provisioned NSX Edge router.
You have the option of provisioning the Edge Router to the same reservation as the Multi-Machine blueprint, or you can specify a separate reservation for the Edge Router. In the MoaC lab I will be using a separate reservation for the Edge Router because all routers are to be deployed in the Management Cluster and all workloads in the Services Cluster.
Before we create the reservations we are going to create a Reservation Policy. Reservation Policies are basically a tag that allows you to target reservations that are assigned with targeted Reservation Policy.
Creating a Reservation Policy
Go to Infrastructure –> Reservations –> Reservation Policies
Select New Reservation Policy
Give the Policy a Name and click the green check.
That’s it. Like I said it’s just a tag.
Create a Reservation Policy to use with an Edge Gateway Reservation.
What is the cloud client you ask? The CloudClient is a verb based command-line utility aimed at simplifying interactions with multiple product api’s. The CloudClient also provides common security, exception handling, json, & CVS support. Currently vRealize Automation (vRA)( Formerly vCAC), Site Recovery Manager (SRM), & vRealize Orchestrator (vRO)(Formerly vCO).
Creating an Amazon AWS Endpoint is really just assigning the credentials you would like to use to communicate with Amazon. vCAC already knows how to communicate with Amazon, it just doesn’t know what it needs to authenticate. To create the AWS Enpoint perform the following steps:
Creating an Amazon AWS credential has a few extra steps then a general set of credentials. You will need to login to your AWS account and access your Acess Key Id as well as your Secret Access Key to be utilized in the creation. The steps below outline the process to create an Amazon AWS set of credentials.
In this article we are going to be creating a vSphere Clone Blueprint. To do this we need to have a few things in place before we begin. Within the blueprint configuration there is a template picker that will allow you to pick form the available templates in your environment. In order for templates to show up in the template picker there are some items that need to be configured in the vCAC environment. You will need to have the following already configured:
In this article we are going to cover how to install the vCAC 6.0.x Linux Guest Operations Agent. The Linux Guest Operations agent is used to perform post provisioning tasks inside the Linux Guest Operating system as part of the vCAC provisioning process. The Linux guest agent runs after the vSphere Customization Specifications runs to perform additional configuration tasks against the machine. There are three common built in features of the guest agent that are commonly used. THose are:
Partition, Format, & Mount additional disks added to the machine.
Configure additional network interfaces added to the machine<./li>
Execute scripts within the guest to install applications, or perform additional configuration.
Creating a blueprint for VCHS has a few pieces to it that are a little different that creating a standard vSphere blueprint. We need to start by creating a component blueprint that will then be utilized by the blueprint that we will publish to the catalog. The reason for this so you could potentially create multi-component application blueprints that can be requested from your users. If you use the vCloud Director integration you will recognize the similarities. This article provides a brief run through of creating a basic VCHS blueprint that can be provisioned against VMware’s VCHS cloud service. Continue reading “vCloud Automation Center – vCAC 6.0 – Creating a VMware VCHS blueprint”