Nsx

Its time to think about deploying our networks through vRA. Deploying servers are cool, but deploying three tiered applications in different networks is cooler. So lets add VMware NSX to our cloud portal and get cracking. The first step is to have NSX up and running in your vSphere environment. Once this simple task is complete, a Distributed Logical Router should be deployed with an Uplink interface configured. The diagram below explains what needs to be setup in vSphere prior to doing any configurations in vRealize Automation. A Distributed Logical Router with a single uplink to an Edge Services Gateway should be configured first, then any new networks will be built through the vRealize Automation integration. While the section of the diagram that is manual, will remain roughly the same throughout, the section handled by vRealize Automation will change often, based on the workloads that are deployed. Note: be sure to setup some routing between your Provider Edge and the DLR so that you can reach the new networks that vRA creates. ...

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. ...

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. ...