Posted on

vRealize Automation – vCAC 6.1 / NSX 6.1 – Creating a Multi-Machine Blueprint w/NSX Routed Gateway Support

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:

image

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.

Continue reading “vRealize Automation – vCAC 6.1 / NSX 6.1 – Creating a Multi-Machine Blueprint w/NSX Routed Gateway Support”

Posted on

vRealize Automation – vCAC 6.1 / NSX 6.1 – Creating NSX Reservations

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

  1. Go to Infrastructure –> Reservations –> Reservation Policies
  2. Select New Reservation Policy
  3. Give the Policy a Name and click the green check.
  4. 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”

Posted on

vRealize Automation – vCAC 6.1 / NSX6.1 – Routed Network Profiles

Routed Network Profiles have a very specific function.  Routed Network Profiles are used in conjunction with NSX and Multi-Machine vCAC blueprints.  Routed Network Profiles are used to define the networks that will be used by the Multi-Machine component machines.  These networks will sit behind a deployed NSX Edge Gateway that is deployed as part of the Multi-Machine deployment.

While creating a Routed Network profile you will need to select an External Network Profile for the Routed Network profile to use.  The External Network Profile is used to assign the IP address to the Uplink Interface of the NSX Edge Gateway that is deployed as part of a Multi-Machine Request.  Routed Network Profiles also consists of IP Network Ranges, not IP address ranges.

IP Network Ranges are used to allocate a Range of IP’s to be used for a specific component Machine.  An example would be if you have a web server component in a Multi-Machine blueprint and you want to deploy two of them.  If the range was a /30 network range you would have two IP addresses available for your two web servers

Below is a diagram representing the Architecture of NSX when using Routed Network Profiles in vCAC.  The External Network Profile that is defined in a Routed Network Profile if depicted as the Purple network in the diagram.  As you can see in the diagram this is the Logical Network that connects the vCAC deployed routers to the pre-existing NSX Edge.  The Green, Orange, and Blue networks represent the Routed Networks that are assigned from the Routed Network Profile.

Continue reading “vRealize Automation – vCAC 6.1 / NSX6.1 – Routed Network Profiles”

Posted on

vRealize Automation – vCAC 6.1 – External Network Profiles

External Network profiles in vCAC enable you to create a range of IP addresses that can used to statically assign IP address to provisioned workloads in your environment.  There are two part to an External Network Profile.  There is the Network Profile Information in which you specify the network specific information such as netmask, gateway, DNS Server, Suffixes, and WINs Servers.  Then there is the IP ranges these can be one contiguous range of IP address or multiple ranges within the subnet that are broken up.

The Network profile is then assigned to a network within a Reservation and any machine provisioned to that reservation an attached to a network will get it’s IP information form the assigned Network profile.  There are a number of ways to utilize External Network Profiles within vCAC , below are some examples:

Continue reading “vRealize Automation – vCAC 6.1 – External Network Profiles”

Posted on

vRealize Automation – vCAC 6.1 – Registering the Application Services Cloud Provider and Templates

Once your vCAC Application Services appliance is installed and configured, you must set up a Cloud Provider.  A Cloud Provider is a system that will provide infrastructure services for the applications you will manage.  In this case, we are using vCAC.  At the same time, you can create Templates based on the vCAC Blueprints you’d like to consume.

Follow the steps below to create your Cloud Provider and Templates.

  1. Choose a user account and add it to the Group Manager role in a vCAC Business Group with the privilege to deploy the Blueprint you would like to use as a base for your application installation.

    image 

  2. Next login to the Application Services appliance, open the Applications menu in the upper right-hand corner, and navigate to Cloud Providers.

    image

  3. Click the green plus sign to add a new Cloud Provider.

    image

  4. Select the appropriate Cloud Provider Type, vCAC in this case.

    image

  5. Fill in the Name and Description for the Cloud Provider.  The vCAC Cloud Provider Type also requires you to input the vCAC Infrastructure URL (the Windows machine, NOT the catalog appliance), as well as your chosen User Name and Password.  Be sure to click Validate Connection after you’ve completed all required fields.

    image

  6. To add a Template, click the green plus sign next to the Templates heading in the lower section of the page.

    image

  7. Click the check box for the Blueprints you’d like to enable as Templates in Application Services, then click OK.  You can also click the ellipsis to show more information about a Blueprint.

    image

  8. If you’d like, you can change the Name and/or Description of the Template(s).  When you are finished, click Save.

    image

This Cloud Provider and Template will now be available for Application deployments.

Posted on

VMware NSX 6.1 & vCAC 6.1 – Connecting NSX to vCAC

Now that we have installed and configured NSX I think it’s time we connected it to vCAC.  In version 6.1 there are some changes to the integration with NSX and vCAC.  When I say changes I should say there are some great new changes.  The integration now utilizes a vCO Plug-in that handles all the interactions between NSX and vCAC.

Benefits of vCO plug-in for NSX to vCAC integration

The benefits of the vCO plug-in are huge.  These workflows that now exist in vCO are there for you to use in your own customization giving you the ability to interact with NSX in a custom way without having to code against it’s api.  Personally I await the day for all integrations to be this way.

As most of you know the vCAC appliance has vCO built in and the built in vCO server already has the NSX plug-in installed for.  If you want to use an external vCO you will have to deploy the plug-in to that appliance before trying to connect vCAC to NSX.

Continue reading “VMware NSX 6.1 & vCAC 6.1 – Connecting NSX to vCAC”

Posted on

vRealize Automation – vCAC 6.1 – Adding a vCO Endpoint

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”

Posted on

vRealize Automation (vCAC) – The cost of being agile

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”

Posted on

The MoaC Lab

moac-sslvpn_banner copy

I have been received a number of questions about the MoaC Lab so I decided to put together an article to cover what the MoaC is.  The MoaC or Mother of all Clouds lab is a project Tom Bonanno and myself (Sid Smith) started to help with sharing information.  The goal is to build a lab that will allow us to build the use cases that everyone wants to learn about.  It’s not about building a lab that has a huge number of resources, but a lab that has a huge number of integrations.  Integrations that that we can document and share with the world.

The MoaC Lab consists of two site.  Site 1 is located in my basement in Harrisburg, PA and Site 2 is located in Tom’s Basement near Atlantic City, NJ.  The two site are currently connected using an IPSec VPN run over NSX.

Continue reading “The MoaC Lab”

Posted on

VMware NSX 6.1 for vSphere – Configuring OSPF route distribution

In my previous NSX articles we covered installing and configuring NSX, We discussed deploying/configuring Transport Zones, Logical Switches, Logical Routers,  Edge Gateways, and connecting the Logical and Edge Gateways.  With all these completed we now have an environment that with the appropriate routes and transport traffic from our physical network to our logical networks that we deployed.  The missing price is the routes.  We could go and configure a bunch of static routes throughout all the NSX routers and our physical routers, but that wouldn’t be fun.  It also wouldn’t be automated.  In this post I am going to walk through configuring the NSX routers to use OSPF for route distribution.

Continue reading “VMware NSX 6.1 for vSphere – Configuring OSPF route distribution”