VCAP-CMA Deploy – Objective 2.1

Disclaimer: These are my notes from studying for the 3V0-31.18 exam. If something doesn’t make sense, please feel free to reach out.

The main goal for the whole of section 2 is to understand how to configure vRA to be able to consume resources.

Objective 2.1 – Create and Manage Multiple Endpoints

References

As I’ve said previously the VCAP-CMA exam is objective based, so you’re likely to be asked to achieve an end goal. This end goal could well involve:

  • Creating endpoint(s)
  • Creating fabric group
  • Creating reservations
  • And so on..

Each stage needs to be successful to be able to complete the later stages. So for example, the endpoint needs to be created correctly for data collection to be successful, which in turn is necessary to be able to create a fabric group etc.

I’d expect the exam to focus on the internal VMware type endpoints, unless I’m being short sighted about the exam.. 🙂

vSphere Endpoint – Key to note that the proxy agent needs to be installed and configured prior to creating this endpoint. If you wish to use the proxy agent’s credentials to access vCenter, you can mark the checkbox for ‘Use integrated credentials’, otherwise enter in the credentials you wish to use.

NSX Endpoint – No longer needed to add in as a vRO endpoint for most operations. However, same as vSphere, if you wish to perform XaaS type actions against this you’ll need to add it into vRO anyway. More on the vRO side later.

The NSX & vSphere endpoints need to be associated so that vRA understands which endpoint is connected.

vRO Endpoint – Add exactly as you’d expect. I’m using the internal vRO endpoint which is the URL of vRA + \vco.

At the point where you click ok, it will test the connection. If there are any errors, you will remain on the same screen so you can check out the error & resolve.

Endpoint_InvalidCredsEndpoint_InvalidLocation

Once all the relevant endpoints are created, the compute resource should be discovered & a fabric group can be created. Once the fabric group is created, this is where you can check how the data collection is getting on and configure to collect at a different interval should you desire. By default it’s daily, which is fine for the vast majority of environments. On occasions where you need something pulled through, you can manually kick off a collection.

The next batch of endpoints, for XaaS resources, are the vRO endpoints. Some of these can be added from within vRA, the remainder need to be added through vRO. To check if it’s already added from with vRO, launch the java based client and browse the inventory and see if the endpoint is populated with any data. Below you can see the NSX plug-in is populated, but the vCenter one is not.

vRO_Endpoints

To configure an endpoint from within vRO, browse the workflows under the relevant area, configuration and run the ‘add endpoint xxx’.

vRO_Endpoint_workflow

Or from within vRA, go to Administration, vRO Configuration, Endpoints.

vRA_vRO_Endpoint

VCP7-CMA – Objective 6.2

Disclaimer: These are my notes from taking the 2V0-731 exam. If something doesn’t make sense, please feel free to reach out.

The goal of this objective is be comfortable with subscription events.

Objective 6.2 – Create and Manage Event Broker Subscriptions

  • Determine appropriate subscription option based on design (blockable, replyable, schema)
  • Configure subscription conditions based on the design (data, core event message values)
  • Configure subscription workflow including input and output parameters based on the design
  • Configure subscription details based on the design (priority, timeout, blocking)

References

All subscriptions are configured per tenant, nothing global.

Different types of subscriptions are:

  • Non blocking:
    • Applied asynchronously
    • Can not rely on the run order
    • Values returned don’t impact the values in the request
  • Blocking:
    • Will prevent other subscriptions being triggered until complete
    • When have multiple, can prioritise with 0 being the highest
    • Values returned can impact the values or the status of a request
  • Replyable
    • Will accept a reply event that provides workflow output
    • Approval subscriptions are replyable

Events can be two states:

  • Pre-State Phase
    • For blocking events it’s possible that the returns values can impact status & values of the request, so the request will not continue until these are returned
  • Post-State Phase
    • Non-blocking workflows will not impact status
    • Blocking events will not fail request but this can be configured through custom properties

Add the subscriptions at Administration, Events, Subscriptions to Add

Add based on the event type:

New_sub_workflow_type

Once the event type is selected, choose the conditions that the event will trigger:

New_sub_workflow_conditions

In this instance we’ve selected machine provisioning and will choose data, Lifecycle State, Lifecycle State Name – Equals – VMPSMasterWorkflow32.MachineProvisioned. This would suit an event being fired to update a CMDB for example.

Next is to select the vRO workflow to fire:

New_sub_workflow_vRO

These would need building based on the event subscription (e.g. into Service Now)

Finally update the details, including configuring whether it is a blocking event or not.

New_sub_workflow_blocking

VCP7-CMA – Objective 6.1

Disclaimer: These are my notes from taking the 2V0-731 exam. If something doesn’t make sense, please feel free to reach out.

The goal of this objective is be comfortable setting the vRO endpoints up.

Objective 6.1 – Configure vRealize Orchestrator for use with vRealize Automation

  • Configure vRealize Automation to use an external vRealize Orchestrator server
  • Configure default vRealize Orchestrator settings in vRealize Automation
  • Set tenant specific vRealize Orchestrator settings in vRealize Automation

References

Not a great deal to this one, but we’ll crack on anyway. 🙂

To configure an external vRO server goto Administration, vRO Configuration, Server Configuration. make the mark to use an external vRO server, fill in the form. Default port is 8281.

External_vRO_Server

Roles required to be able to configure vRO are (taken straight from Configuring vRealize Automation).

vRO_Roles

Configure the default vRO server by configuring in vsphere.local system admin page. To configure the workflow folders, go to Advanced Services, Default vRO Folder.

If logged into a tenant with admin rights, can configure a separate vRO endpoint for your tenant. The vRO endpoint in vsphere.local is the default for all tenants.

 

VCP7-CMA – Objective 5.2

Disclaimer: These are my notes from taking the 2V0-731 exam. If something doesn’t make sense, please feel free to reach out.

The goal of this objective is be comfortable managing the fabric and associated reservations.

Objective 5.2 – Create and Manage Fabric Groups, Reservations and Network Profiles

  • Create and configure a fabric group
  • Select compute resources to include in the fabric group
  • Configure compute resource Data Collection
  • Create a vSphere reservation
  • Assign a business group to the vSphere reservation
  • Create a vCloud Air reservation
  • Create and configure network profile type
    • For static IP address assignment
    • External network profiles
    • NAT network profile
    • Routed network profile
  • Create and configure machine prefixes

References

Permissions:

  • IaaS administrator to create the endpoints & the fabric, plus allocating the fabric administrator.
  • Fabric administrator to create the machine prefixes, network profiles & reservations.

Log in as the IaaS administrator to create the compute endpoint (vCenter, AWS etc.). Go to Infrastructure, Endpoints, Fabric Groups.

Add the fabric group, assign a name & the fabric administrators. Select the compute resource for the group.

Data collection can be configured under Infrastructure, Compute Resources. Can be enabled/disabled or the frequency can be changed.

Pre-requisites for a reservation are:

  • Logged in as a fabric administrator
  • Tenant administrator has created a business group
  • Compute resource exists
  • Network settings have been configured

To create a reservation, browse to Infrastructure, Reservations. Choose new and select the type (vSphere in my case). Give it a name and allocate the reservation to a business group. Each business group needs to have a reservation created to be able to provision resources. For the priority setting – the lowest number wins. This is used when a business group has access to multiple reservations. You can also specify a reservation policy but this is not mandatory.

On the resource tab, you need to select the compute resource for the reservation, along with the maximum number of machines that can be powered on (powered off or archived machines do not count) against this reservation, the total Memory & Storage that can be added. Can also configure machines to be created in a resource pool if required.

On the network tab, you can select which networks the machines can be provisioned on and the network profile that is allocated to each. The network profile is there to specify static IP settings, this isn’t necessarily required if DHCP is going to be used.

Custom properties can be defined on the properties tab. Capacity alerts can be generated and emailed out to an appropriate person if required.

If a network profile is specified on the blueprint (Using custom property) then this takes precedence over the network profile defined on the reservation.

The 3 network types are:

  • External – Existing network on vSphere server
  • NAT – Created during provisioning. 1-1 NAT network, address on internal & address on external.
  • Routed – NSX network, routable IP.

These are described as below (taken from Configuring vRealize Automation documentation).

Network_Profiles

When using a network profile to dish out static IP addresses (using vRA IPAM), the process to reclaim unused IP addresses runs every 30 minutes.

To create a network profile, login as a fabric administrator and browse to Infrastructure, Reservations, Network Profiles.

Add name, enter subnet mask, gateway & DNS. Go to the IP ranges tab to allocate a block of IPs for use within the profile. The IP ranges can be uploaded within a csv file.

Creating a NAT network profile. Pre-req’s are an external network profile.

Creating a routed network profile – requires NSX Distributed Logical Router (DLR)

VCP7-CMA – Objective 5.1

Disclaimer: These are my notes from taking the 2V0-731 exam. If something doesn’t make sense, please feel free to reach out.

The goal of this objective is be comfortable adding endpoints to support the various integrations with other VMware endpoints. Some of this has changed in later versions, but the exam is based around vRA 7.0 so that is where this will focus.

Objective 5.1 – Create and Manage VMware Endpoints

  • Integrate vRealize Automation with NSX
  • Add a vRealize Orchestrator endpoint to vRealize Automation
  • Configure the NSX plugin in vRealize Orchestrator
  • Perform data collection in vRealize Automation
  • Create and configure a vSphere Endpoint
  • Configure NSX Network and Security for the vSphere endpoint
  • Create and configure a vCloud Air endpoint

References

NSX is integrated via vRO, it can’t be added as an endpoint directly in vRA (NB: this is something that changed in later versions).

Login to vRO, run the ‘Create NSX Endpoint’ workflow. You can check it’s added by browsing the orchestrator endpoints.

vRO_NSX_Endpoint

From within vRA, make sure the vRO endpoint is added (if not, you’ll need to do this). Browse to the vCenter endpoint & tick the box to specify a Network & Security Manager. Fill in the NSX Manager details to bind vCenter to NSX within vRA.

vSphere_Endpoint

The only network feature available in a blueprint without NSX is to add an Existing Network. NSX adds the below:

  • Existing Security Group
  • Existing Security Tag
  • On-Demand Load Balancer
  • On-Demand NAT Network
  • On-Demand Routed Network
  • On-Demand Security Group

From Infrastructure, Endpoints – you can performa a data collection against any endpoint.

To add a vSphere endpoint (As IaaS Administrator):

  • Install a proxy agent on a Windows server, make sure the agent name is correct (case sensitive)
  • Add & Save credentials within vRA to connect to the endpoint
  • Add the endpoint from Infrastructure, Endpoints

VCP7-CMA – Objective 4.5

Disclaimer: These are my notes from taking the 2V0-731 exam. If something doesn’t make sense, please feel free to reach out.

The goal of this objective is be able to view the provisioned resources in terms of compute/storage. Short post for this one!

Objective 4.5 – Manage Provisioned Resources

  • Identify and locate owned items by assigned role
  • Define resource quotas for managed resources based on design requirements
  • Add resource portliest to the vRealize Automation homepage

References

Permissions required for various scenarios, screenshot taken directly from the Managing vRealize Automation document.

Resource_Monitor_Perms

The simplest way to remember this is that if you want to monitor resources outside of your area (tenant or business group), you need to be a fabric administrator.

To define the quotas, modify the reservation allocated to each business group.

On home tab, click the edit button on the top right corner. From here you can add a number of pre-defined portlets. The information received depends on what your permissions are.

VCAP-CMA Deploy – Objective 1.5

Disclaimer: These are my notes from studying for the 3V0-31.18 exam. If something doesn’t make sense, please feel free to reach out.

The main goal for the whole of section 1 is to understand blueprint creation and modification in depth.

Objective 1.5 – Consume NSX components of a complex blueprint

References

For this objective, have a think about everything you may need to put in place to consume an NSX element within a blueprint.

First lets start with a list of NSX components that can add to a blueprint:

  • Existing Security Group
  • Existing Security Tag
  • On-Demand Load Balancer
  • On-Demand NAT Network
  • On-Demand Routed Network
  • On-Demand Security Group

Existing Security Groups/Tags

Fairly simplistic this one – drag the appropriate component onto the canvas, then select it. Click on the ellipsis button to select the pre-existing component (as the name suggests this should already be created within NSX).

Existing_Security_Group

Once the security group/tag is defined, select the VM object you want to associate with the group/tag. Go to the security tab and put a tick in the approriate box(es).

Associate_Security_Group

Once you’ve done this, you’ll see the security group/tag link up on the main canvas.

Linked_Security_Group_tag

On-Demand Security Group

This one involves a bit more work, but it will create/delete security groups as part of the deployment/destruction of a blueprint.

First you’ll need to create a Security Policy within NSX Service Composer. This is the policy that will apply to the on-demand group, otherwise NSX doesn’t know what you want from the security group!

I kept mine simple, just clicked through the wizard without adding anything in. You can quite easily create rules here, but I chose to leave it as this is just for a lab environment.

Once the policy is created, go back to your blueprint and drag the On-Demand Security Group component on to the canvas. From here give the component a meaningful name, and click on the add button underneath security policies. Then select the policy you created earlier.

On-demand_Security_Group

Once you’ve got the right security group on the canvas, you can link it under the security tab just like earlier.

On-Demand Routed Network

This is an on-demand network created at the provisioning stage connected to an existing Logical NSX Router. I’m making an assumption that in the exam you’ll already have the appropriate parts of NSX configured for you. After all, they’re not testing on that product. Briefly though, you’ll need:

  • Edge Services Gateway
  • Distributed Logical Router
  • Dynamic Routing
  • Subnet to allocate within vRA

Within vRA, we need things in place before we can consume a routed network on a blueprint:

  • External network profile
  • Routed network profile
  • Access to these profiles through the appropriate reservation

On the network profiles page, click New, External. Once you’ve entered a name, you’re done for the routed network requirements. The remaining items are if you want to use the network profile for other things as well. If you choose to fill in the DNS page, the spawned profiles (routed & NAT) will use these values to complete the same page. However it’s not necessary, your call!

External_Network_Routed

Back on the network profiles page, click New, Routed. Complete the page, entering a name, the external network profile you created earlier and fill in the network details:

  • Subnet mask: This is the network prefix for the master block of IPs you’re allocating to this profile.
  • Range subnet mask: The network prefix for each network that will get created. Think about how many VMs you might have in a single deployment.
  • Base IP: Network address for the master block

Routed_Network_General

The DNS page will either be filled in or you can complete it manually, depending on the settings you chose in the external network profile earlier. On network ranges, if you’ve truly allocated the whole subnet, you can select Generate Ranges. This will populate all the subnets based on the Base IP, Subnet mask & Range subnet mask from the General tab. Of course you can also complete this manually.

Routed_Network_Ranges

Now you’ve got the profiles created, you’ll need to link these profiles up in the reservation. The only change you’ll need to make is on the reservation, Network tab. Allocate the appropriate external network to the pre-existing DLR.

Reservation_DLR

This is enough to make the routed network available to the users of that reservation.

Every time you deploy a blueprint that has machines allocated to this profile, it will use a different range. The already deployed DLR will be the gateway, in conjunction with dynamic routing, you’ll be able to route to these VMs.

On-Demand NAT Network

Very similar to the On-Demand Routed Network, key differences are:

  • Need to complete all the configuration within the External profile. This is because when you provision a NAT network, vRA will request a new ESG from NSX. The IP settings within this profile are what the ESG will use to talk to the outside world.
  • Still need a subnet to allocate, but this doesn’t need to be routable as it will be NAT’d behind the NSX ESG. In fact, if you deploy multiple times from the same blueprint, you’ll end up with multiple items using the same IP address.

So lets assume you’ve already got an external network profile in place and we’re going to create the NAT network profile. Go to the network profiles page and click New, NAT.

NAT_Network_General

Key points on this main page:

  • External network profile: External network profile that will be used to house the NSX ESG.
  • NAT Type: 1:1 or 1:Many, very much depends on the use case. In this instance I’ll be using 1:1.
  • Subnet/Gateway: Network details for the NAT’d network. The Gateway will be on the ESG.

As before, if it’s configured in the external profile, the DNS tab will already be populated. The network ranges tab is where you add in the ranges that will be allocated to VMs on this network. Multiple deployments can overlap as these aren’t exposed to the rest of the network.

Once the profiles are configured, the external network profile needs to be linked up on the appropriate reservation. It needs to be configured on whichever logical switch is the transit network.

Once this is complete they can be added to the canvas like any other network.

On-Demand Load Balancer

Exactly what it says on the tin, a load balancer that is deployed in NSX, on-demand. This is a configuration item on the ESG that is deployed with the deployment. If you’re not deploying one for anything else, this will deploy one for you.

The initial configuration is pretty straightforward.

  • ID: Name of the load balancer on the blueprint
  • Member: The object on the blueprint the load balancer is going to forward traffic to
  • Member Network: The network card on the object to forward traffic to
  • VIP Network: The network that the Virtual IP is going to be on
  • IP Address: The static IP that you want to be the VIP. This would make the blueprint single use, so not used often

Further down, create the virtual server. This is where there is more configuration options. Initially you can choose the protocol, port & description. There’s then an option to choose the default settings or to customise. If you select customise it opens up the other tabs on the option box.

LB_New_Virtual_Server

There are options for:

  • Distribution
    • Algorithm
    • Persistence
  • Health Check
    • Health Check URL
    • Interval etc.
  • Advanced
    • Connection limits
    • Transparency
    • Acceleration (L4 vs L7)

If you hover over the information symbol for each option it will tell you what each option will give you.

LB_Distrib_Algo

Transport Zone

Key point with NSX, which I frequently forget, is to select the correct transport zone on both the blueprint & the reservation. If these aren’t present, deployment will fail!