Vcac6

So far we’ve talked a lot about using our automation solution to automate network deployments with NSX. But one of the best features about NSX is how we can firewall everything! Lucky for us, we can automate the deployment of specific firewall rules for each of our blueprints as well as deploying brand new networks for them. Use Case: There are plenty of reasons to firewall your applications. It could be for compliance purposes or just a good practice to limit what traffic can access your apps. ...

Just deploying virtual machines in an automated fashion is probably the most important piece of a cloud management platform, but you still need to be able to manage the machines after they’ve been deployed. In order to add more functionality to the portal, we can create post deployment “actions” that act on our virtual machine. For instance an action that snapshots a virtual machine would be a good one. We refer to these actions that take place after the provisioning process a “Day 2 Operation”, probably because it’s likely to happen on the second day or later. Clever huh? ...

If you’re building a multi-machine blueprint or multi-tiered app, there is a high likelihood that at least some of those machines will want to be load balanced. Many apps require multiple web servers in order to provide additional availability or to scale out. vRealize Automation 6 coupled with NSX will allow you to put some load balancing right into your server blueprints. Just to set the stage here, we’re going to deploy an NSX Edge appliance with our multi-machine blueprint and this will load balance both HTTPs and HTTP traffic between a pair of servers. ...

You’re network isn’t fully on IPv6 yet? Ah, well don’t worry you’re certainly not alone, in fact you’re for sure in the majority. Knowing this, you’re probably using some sort of network address translation (NAT). Luckily, vRealize Automation can help you deploy translated networks as well as routed and private networks with a little help from NSX. A quick refresher here, a translated network is a network that remaps an IP Address space from one to another. The quickest way to explain this is a public and a private IP Address. Your computer likely sits behind a firewall and has a private address like 192.168.1.50 but when you send traffic to the internet, the firewall translates it into a public IP Address like 143.95.32.129. This translation can be used to do things like keeping two servers on a network with the exact same IP Address. ...

Any corporate network thats larger than a very small business is likely going to have a routed network already. Segmenting networks improves performance and more importantly used for security purposes. Many compliance regulations such as PCI-DSS state that machines need to be segmented from each other unless there is a specific reason for them to be on the same network. For instance your corporate file server doesn’t need to communicate directly with your CRM database full of credit card numbers. The quickest way to fix this is to put these systems on different networks but this can be difficult to manage in a highly automated environment. Developers might need to spin up new applications which may need to be on different network segments from the rest of the environment. Its not very feasible to assume we can now spin up test and delete hundred of machines each day, but need the network team to manually create new network segments and tear them down each day. That wouldn’t be a nice thing to do to your network team. ...

Of the types of networks available through NSX, private networks are the easiest to get going because they don’t require any NSX edge routers to be in place. Think about it, the NSX edge appliance is used to allow communication with the physical network which we won’t need for a private network. A quick refresher here, a private network is a network that is not connected to the rest of the environment. Machines that are on the private network can communicate with each other, but nothing else in the environment. Its simple, think of some machines connected to a switch and the switch isn’t connected to any routers. The machines connected to the switch can talk to each other, but thats it. ...

This is a series of posts helping you get familiarized with how VMware’s vRealize Automation 6 can leverage VMware’s NSX product to provide software defined networking. The series will show you how to do some basic setup of NSX as well as how to use Private, Routed and NAT networks all from within vRA. vRealize Automation 6 with NSX - NSX Setup vRealize Automation 6 with NSX - Private Networks vRealize Automation 6 with NSX - Routed Networks vRealize Automation 6 with NSX - NAT vRealize Automation 6 with NSX - Load Balancing vRealize Automation 6 with NSX - Firewall

Before we can start deploying environments with automated network segments, we need to do some basic setup of the NSX environment. NSX Manager Setup It should be obvious that you need to setup NSX Manager, deploy controllers and do some host preparation. These are basic setup procedures just to use NSX even without vRealize Automation in the middle of things, but just as a quick review: Install NSX Manager and deploy NSX Controller Nodes NSX Manager setup can be deployed from an OVA and then you must register the NSX Manager with vCenter. After this is complete, deploy three NSX Controller nodes to configure your logical constructs. ...

vRealize Automation is at its best when it can leverage multiple infrastructures to provide a hybrid cloud infrastructure. One of the things we might want to do is to set up VMware vCloud Air integration with your vRA instance. To start, we need to have a vCloud Air account which you can currently sign up for with some initial credits to get you started for free. Once you’ve got an account you’ll be able to setup a VDC and will have some catalogs that you can build VMs from. If you’re concerned about these steps, don’t worry a default VDC including some storage and a network will be there for you by default. ...

If you’re planning on doing a full distributed installation of vRealize Automation, you’ll likely want to have some protection for the vPostgres database. Having a single point of failure defeats the purpose of doing a full distributed install. I’ve been doing a bunch of work on this lately and wanted to warn people of a gotcha if you’re using a load balancer. Non-Distributed Install To give us a better understanding, take a look at a pair of vRealize Automation Appliances that aren’t in a high availability solution. In the picture below, there are two vRealize Automation Appliances and each of them is communicating with their own embedded vPostgres Database. This is the default configuration when deployed from VMware and works just fine. ...