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
When configuring a NAT Network Profile you have two options. You can configure a one-to-one or a one-to-many. Here we are going to walk through creating a one-to-many NAT Network Profile. One-to-many NAT network are networks that do source NAT only. This will allow any machine provisioned onto the network to communicate out of the network under one IP address, however there is no NAT translation configured to come into the network for any services. When you use a one-to-many NAT network profile in a Multi-Machine Blueprint an NSX Edge Gateway will be deployed, however routing will not be enabled and a Source NAT rule and relevant firewall rules will be created. NAT network get IP address from a pool of IP’s that will be reused over and over again for each deployment. The nature of NAT let’s us reuse the IP’s because the different apps being deployed will all communicate using unique IP address on the outside of the provisioned Edge Gateway. Although I am using a class C network in my example I really don’t need to. If I will never have more than six machines on the NAT network I could use a /29 network if I wanted to, but for simplicity I used a class C and assigned a fairly large range……just in case 😉
In the below diagram I’m going to represent the orange network as a one-to-many NAT network. All machines provisioned behind the router will get an IP address from the NAT Pool and all will SNAT to the upstream network as the external IP address of the router. The external IP is assigned from the External Network Profile that is assigned to the NAT Network Profile.
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.
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:
More and more frequently I get asked about support for configuring LVM(Logical Volumes) in Linux guests provisioned by vCAC. The short answer is the guest agent by default will partition a disk as a standard Linux partition. However because the guest agent allows us to execute scripts we can overcome this and configure LVM volumes within the guest. In this article I’m going to to walk you through just how to do that.
Using the Linux Guest Agent to config LVM
To begin we need a working vCAC environment that can provision Linux VM’s with a working Linux Guest Agent. You can find information on all the needed topics to install and configure vCAC 6 here.
Next we need a script that we will use to setup the LVM inside the guest Linux operating system. Below I have a very basic script for this example. This script assumed only one additional hard disk will be added to the VM. Any additional disks will not be included in the LVM.
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”
That big ole title pretty much says it all. In this article I’m going to walk through how to deploy RHEL (Centos) Linux onto a Physical HP Server over the iLo interface using Kickstart. When provisioning to Physical servers such as an HP Proliant DL360 there are two methods built into vCAC. One is the use of PXE boot, and the other is via the iLo interface.
There are pro and cons to both PXE and remote mounting an ISO over the iLo interface. PXE has the obvious cons of the network requirements, having a PXE server available and if you want true flexibility you will need to do a little custom work. ISO mount over iLo tend to be a bit slower due to the over head of remote mounting a ISO and the speed of the iLo interface. In this article I will be covering remote mounting an ISO over iLo, but I will be covering PXE is a later article.
What do we need
To start we need the Physical HP server to be racked and cabled up. It’s iLo interface should be configured and licensed, the network interfaces should be cabled in and the switches should be configured for the appropriate Vlans etc. The drives in the server should also be initialized. vCAC will not create any raid groups etc for you, you must do this manually. My examples also requires a web server that can be utilized to store the needed files on the network.