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.
Continue reading “vRealize Autoamtion – vCAC 6.1 – Creating a One to One NAT Network Profile”
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
Continue reading “vRealize Automation – vCAC 6.1 – Creating a Private Network Profile”
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.
Continue reading “vRealize Automation – vCAC 6.1 – Creating a One to Many 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.
Continue reading “vRealize Automation – vCAC 6.1 / NSX 6.1 – Creating NSX Reservations”
Item 2 updated for vRA 7
vCO Endpoints are used by vCAC when vCAC needs to execute vCO workflows. These can be out of the box workflows such as the NSX workflows, or they can be workflows that you created and want vCAC to execute as part of a deployment state transitions such as during building machine, machine provisioned, machine destroyed or various other master workflow states. vCAC cannot execute these workflows without first having a vCO endpoint to which it can query and call to execute. vCAC can pass machine custom properties and other information through to vCO as part of the execution to parameterize the workflows.
Continue reading “vRealize Automation – vCAC 6.1 – Adding a vCO Endpoint”
Building a cloud is easy right? There are products out there that can stand up a cloud for you in a week and automate your entire IT infrastructure practically overnight, isn’t there? This is what some vendors would try to have you believe. The fact is building a cloud and/or automating your IT infrastructure is very complex and each network is as unique as the DNA that sets each of us apart.
Today IT infrastructures are living breathing organisms ever evolving, growing, and adapting to the rapidly changing organizations that rely on them. Trying to simply understand these infrastructures is a huge feat let alone automate them. One could spend years trying to understand these infrastructures like a documentary on the nature channel.
Continue reading “vRealize Automation (vCAC) – The cost of being agile”
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:
- We start by going to the Infrastructure tab, then choosing Endpoints from the side menu and then Endpoints again. Once there hover over the New Endpoint item on the right side of the page.
Continue reading “vCloud Automation Center – vCAC 6.0 – Creating an Amazon AWS Endpoint”
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.
1.) Navigate to the Infrastructure tab and select Endpoints form the left Menu then select Credentials.
2.)The select New Credentials form the right side of the page.
Continue reading “vCloud Automation Center – vCAC 6.0 – Creating Amazon AWS 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:
- vSphere Credential
- vSphere EndPoint
- Fabric Group (with the vSphere resources assigned)
- vSphere Reservation
Continue reading “vCloud Automation Center – vCAC 6.0 – Creating a vSphere Clone Blueprint”
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.
If the guest agent is installed in the template and the appropriate properties are configured it will automatically perform the first two items as part of the vCAC provisioning process. In order to execute scripts you will need to tell vCAC to inform the guest agents of the scripts that need to be executed.
Continue reading “vCloud Automation Center – vCAC 6.0 – Installing the vCAC 6.0 Linux Guest Agent”