Update A CMDB As Part Of IaaS Machine Life Cycle

A good way of demonstrating VMware vCloud Automation Center 3rd party integrations is around a CMDB use case. The most obvious example will be to write to a DB table once the machine has been provisioned and then once again when it has been disposed of.

I am using vCAC 6.01 with the embedded vCO so I have the vCO SQL plugin already installed but if you are using an external vCO most probably you will need to installed the SQL plugin. It can be downloaded from here: Download

Next steps:

1. Make sure you have a DB to connect to and a DB table to write to. I have create a demo DB called ‘CMDB’ in an instance of SQL Server 2008 Express. Inside that DB I have a table called ‘machines’ with the following fields:

table

2. In vCO run the workflow ‘JDBC Workflow Generator’. This will help you form the JDBC URL you will need for the next step. As I am using SQL Express my URL looks like this:

jdbc:jtds:sqlserver://vcac-w8-01a.corp.local:1433/CMDB;instance=sqlexpress;domain=corp.local

3. In vCO run the workflow ‘Add a Database’. Use the JDBC URL generated in the previous step. If you still encounter difficulties then check that TCP/IP is enable: Launch the SQL Server Configuration Manager Click on the “Protocols for SQLEXPRESS” node, Right click on “TCP/IP” in the list of Protocols and choose, “Enable” Check that Static Port 1433 and NOT the Dynamic port is configured: Click on the “TCP/IP” child node, You will notice an entry on the right panel for “IPAll”, right click on this and select, “Properties” Clear out the value for “TCP Dynamic Ports” and Give a TcpPort number to use when making remote connections, i.e., “1433”.

4. In vCO run the workflow ‘Add a table to a Database’. Point to the table you have created before.

5. In vCO run the workflow ‘Generate CRUD workflows for a table’ and point to the table you have added to the DB in the previous step. You will need to specify in which vCO folder you want this workflow to be created. The workflow name will be something like “Create Active Record for ‘machines’ ” where ‘machines’ is the name of the DB table we have been working with all along.

6. Create a net new vCO workflow called ‘CMDB add machine Record’ for example. In it have a scriptable task to unwrap vCAC object properties and then call the “Create Active Record for ‘machines'” workflow to update the CMDB table:

workflow1

I will add the workflow as an example at the end as a reference. In the workflow ‘General’ tab make sure you set the vCACHost parameter to point to your vCAC server as explained in my previous blog post 

7. Create a net new vCO workflow called ‘CMDB update machine Record’ for example. In it have a scriptable task to unwrap vCAC object properties as previously mentioned and then call the ‘Execute a Custom query’ workflow to update the CMDB table. The scriptable task in this workflow will look like this:

var timestamp = new Date();
System.log(“The timestamp is: ” + timestamp);
time = timestamp;
machine_state = state;
hostname = machine_name;
query = “UPDATE machines SET state= ” + “‘” + machine_state + “‘” + “,” + “timestamp= ” + “‘” + time + “‘” + “WHERE machine_name= ” + “‘” + hostname + “‘” + “;” ;
System.log(“Executing query ” + query + ” on database ” + database.name );
rowsAffected = database.executeCustomQuery(query);
System.log(“Rows affected: “+ rowsAffected);

As you can see all we want to update is the machine state and timestamp columns with the state of the machine (now destroyed) and the time it has been destroyed.

workflow2

In the workflow ‘General’ tab make sure you set the vCACHost parameter to point to your vCAC server as explained in my previous blog post  and also make sure the ‘database’ parameter is pointing to CMDB DB you are working with.

8. Now we need to associate these 2 workflows with a vCAC external Stubs. More information about vCAC external stubs and how they can be associated with vCO workflows and triggered at runtime can be found here in my previous blog post 

Make sure you associate your ‘CMDB add machine Record’ workflow with MachineProvisioned stub and  ‘CMDB update machine Record’ workflow with MachineDisposing stub as described in my previous blog post 

Job Done.

For your convenience the two vCO workflows mentioned above can be downloaded from here:

http://tinyurl.com/q6y3u6k

Thanks!

Yuval T

Advertisements

, , , ,

5 Comments

Application Aware High Availability – AppHA 1.1 is now Generally Available

vSphere App HA stands for “Application Aware High Availability”. It is a plug-in to the vSphere Web Client. App HA enables you to define high availability for the applications that are running on the virtual machines in your environment. Currently, vCenter Server allows users to define HA (High Availability) at the infrastructure level. The main use case here however is to make sure the application is Highly available. That means – consider the availability of the service (middleware). This is what AppHA is all about. Making sure that the service is up and if it’s not, try to restart it for several times, and then if necessary, call the vSphere HA API.

vSphere AppHA 1.1 Release Notes: Release Notes

Main use case is:

VI Admin wants to ensure high availability of the middleware:
  • Get alerts when service is down
  • Remediation through automatic restart of service and VM
Main advantages:
  • Simple to use
  • Adds another layer to currently working vSphere HA:
  • Integrated into vSphere web client
  • Integrated with vCenter Server (VC alarms)
  • Integrated with vSphere HA (Reset VM)
  • Works with vMotion

What’s new in AppHA 1.1:

  • More platform support: vSphere 5.5U1 & vSphere 5.1U2, ESX 5.1 & 5.5, NGC 5.1 & 5.5, Hyperic 5.8.1, Vmtools
  • You can create a custom AppHa service to manage non default AppHa services.
  • You can edit policies, including those that have already been assigned to services.
  • Translation for 6 languages
  • Services Supported by vSphere App HA – Out of the box support for of Oracle and Postgres.

All Services now supported by AppHA are listed here: Services

This release is part of:

  • vSphere 5.5 UP1 Enterprise +
  • vCloud Suite 5.5 UP1 Standard
  • vCloud Suite 5.5 UP1 Advanced
  • vCloud Suite 5.5 UP1 Enterprise
  • vS w/Ops Mgmt Enterprise + 5.5 UP1
How the product interacts with other VMware products:
  • Hyperic: App HA backend is actually VMware Hyperic server. Hyperic server and agents are responsible for monitoring the availability of the services and remediates them.
  • vSphere: VC alarms – when the user configures to fire VC alarms (in case service is down), App HA creates a VC alarm based on an event that Hyperic creates when the service is down.
  • vSphere: NGC – App HA is a plugin to NGC
  • vSphere HA – Resetting the VM is based on vSphere HA API. For that to work the requirements are: ESX 5.5/5.1, running VMtools and Configuration of vSphere HA on that cluster.
List of Network port needed for each component:
  • 5432 – App HA Postgres DB
  • 22- Port for enabling SSH access to the vSphere App HA virtual appliance •
  • 7443 – Communication with vFabricHyperic server. NOTE This port can change because it is dependent on what you select during the installation of the vFabricHypericserver.
  • 8443 – Port for the REST API.
More information can be found in the AppHA 1.1 documentation landing page: Landing Page

, , ,

Leave a comment

Add/remove vCAC IaaS VMs to/from DNS

Add/remove vCAC IaaS VMs to/from DNS server use-case:

A use case which is often required and which I finally found the time to wrap together and do it without the need for any Powershell connection.

How? Well I took Christophe Decanini great “Guest Script Manager” package from this Communities post. More specifically the run dnscmd.exe example from this link but then repackaged it so that it now works when called from vCAC external Stubs MachineProvisioned and MachineDisposing. The only object these two workflows take as input parameter is vCAC:Entity, which comes dynamically from IaaS and nothing else. All other required attributes are pre-set in the workflow and so need to be edited and filled with the relevant information when ported from one environment to the next.

The dnscmd command needs to run on a Windows VM which resides in a vCenter Server which is both connected to vCO via the vCenter plugin (so can be pointed at as VC:VirtualMachine) and that has dnscmd.exe installed.

Here is a screenshot of the Attributes one needs to set before running the workflow:

dns

And here they are in the table below:

Name Type Value Description
vcacHost vCAC:VCACHost Insert you vCAC Server here Your vCAC Server
vm VC:VirtualMachine Insert Windows VM with dnscmd installed Windows VM with dnscmd installed
vmUsername String Insert DNS admin username DNS admin username
vmPassword SecureString Insert DNS admin password DNS admin password
dnsServerFqdn String Insert your DNS Server FQDN DNS Server FQDN
zoneNameFqdn String Insert your domain Domain Name
recordType String A Example: A
createPtr Boolean Set Yes or No Optional PTR Yes or No

Now we need to associate these 2 workflows with a vCAC external Stub. More information about vCAC external stubs and how they can be associated with vCO workflows and triggered at runtime can be found here in Chris Alleaume’s excellent blog: Chris’s Blog

Make sure you associate your “add to DNS…” workflow with MachineProvisioned stub and  “Delete record from DNS…” workflow with MachineDisposing stub as described in Chris’s blog.

Job Done.

For your convenience the two vCO workflows mentioned above can be downloaded from here:

http://tinyurl.com/o3xymhp

Note: if you are facing an issue with UAC on 2012 and getting and error that it is unable to access file c:\Windows\system32\cmdANSI.exe (Workflow: Copy file from vCO to guest / Scriptable task (item1)#11), know that disabling UAC from the control panel might not be enough as you may also need to modify the registry and reboot as described here: http://social.technet.microsoft.com/wiki/contents/articles/13953.windows-server-2012-deactivating-uac.aspx

Thanks!

Yuval T

, , , , ,

13 Comments

Part 2 – Integrating vCAC with F5 BIG-IP LTM- Day Two Operations

In Part 1 of this blog series we have looked at an IaaS use-case where as part of the user requesting a machine from the vCAC Self Service Portal or disposing it the machine is dynamically added to an F5 Pool or removed from it. See here: Part 1 

In Part 2 we are going to explore the 2nd identified use-case which is all around machines day two activities- So the machine is already deployed and running but maybe now we need to add or remove it from an F5 Pool for example.

This use-case will be achieved using the new Advanced Service Designer (ASD) which is a new capability in vCAC 6.*

Requirements:

BIG-IP LTM 11.* and above.
vCAC 6.0 or 6.0.1
vCO 5.1 and above (I am using the embedded vCO 5.5.1 which is part of vCAC 6.0.1)
F5 vCO plugin version 2. I got it from here: https://devcentral.f5.com/d/f5-management-plug-in-for-vmware-vcenter-orchestrator-v200?download=true but best thing is to send an email vco@f5.com and they will supply you with the latest version, free of charge as far as I know.

Steps:

1. If not already installed then go ahead and install the F5 vCO plugin as explaind here: Install F5 vCO Plugin

2. Next you need to run the Attach LTM workflow in vCO if you haven’t done so already. Have a look for Part 1 of this blog series for some tips around that.

3. Build a vCO workflow to add VM to an F5 Pool. This workflow will be different than the one we have created in Part 1 of this blog series because Advanced Service Designer (ASD) is expecting a VC:VirtualMachine object as input parameter otherwise you will not be able to associate the Resource Action we intend to create with a VM day 2 operation. (As a side note I will say that I intend to write a separate blog post in the future to explain the differences between the types of input parameters vCO can receive from vCAC or vCenter and what are the benefit and use cases to use each type and more importantly when to use it.)

The workflow will look identical to the one we have used in Part 1 of this blog series only difference is that the the 1st scriptable task will use the VC:VirtualMachine inout parameter to get the IP of the VM we need to add as member to the F5 Pool. The (very simple 1 line) script will look like this:

ip = vCenterVm.guest.ipAddress;

Where vCenterVm is mapped to VC:VirtualMachine input parameter. Two other input parameters are required here: memberPort and PortName but they will be prompting the user at request time.

4. Build a vCO workflow to remove a member from an F5 Pool. In contrast to the workflow we have created in Part 1 of this blog series, this one will not delete Virtual Server or the Pool but simply remove the specific member from the Pool. This is because the Pool may still include other members so we don’t want to delete it just remove a specific member.

The workflow will look like this:

asd remove

Note: Two input parameters in this one. PoolName will come from vCAC ASD so the user who initiates the action will be prompted for the Pool Name. The 2nd input param VC:VirtualMachine will come dynamically from vCAC ASD.

5. Log into vCAC tenant where you wish to add this functionality (https://vCAC_FQDN/shell-ui-app/org/your_tenant_name)

6. Providing you have a user with the appropriate permission go to Advanced Services tab>Resource Actions and click on the “+” sign.

7.  Select your vCO workflow and pay attention to the input parameters the workflow expects. Note how VC:VirtualMachine is defined as input parameter as well as memberPort and PoolName, last two will be prompting the user for input:

ASD2

8. Set Resource Type to be IaaS VC VirtualMachine (OOTB parameter) and Input Parameter as the one you have mapped to VC:VirtualMachine in your vCO workflow previously (in my case I have called it vCenterVm):

asd3

9. Next name the action.

10. Now (optionally) edit the form to the make the PoolName field a Drop-down or a list with some pre-defined values (E.G. web, app etc..)

asd4

11. Leave memberPort as a Decimal Field but set the default value to the constant “80” to make it easier for the requester:

constant

12. Publish the action:

publish

13. (Optional but nice touch) Go to Administration>Catalog Management>Actions and configure your action to have a nice F5 icon:

icon

14. Go to Administration>Catalog Management>Entitlements and entitle your newly created action:

entitle

15. Now do the exact same thing for the “Remove Member from F5 Pool…” workflow.

You are basically done. So now look at the “Items” tab in vCAC for your already requested and running VM’s, you will notice they now have some new options for the user to take:

result

If the user selects to add the VM to an F5 Pool the form will look like this:

this

Job Done.

For your convenience the two vCO workflows mentioned above can be downloaded from here:

http://tinyurl.com/q8z6mhr

Thanks!

Yuval T

, , , ,

Leave a comment

Part 1 – Integrating vCAC with F5 BIG-IP LTM- IaaS Use Case

VMware vCloud Automation Center (vCAC) can be easily integrated with 3rd party solutions to cater for various use cases. I was recently involved in a project where there was a need to integrate with F5.
There are maybe 3 integration points where F5 touches vCAC:
1. As part of IaaS – so as part of the user requesting a machine from the vCAC Self Service Portal or disposing it, then that machine is dynamically added to an F5 Pool or removed from it.
2. As part of a day two activity- the machine is already deployed and running but maybe now we need to add or remove it from an F5 Pool.
3. “F5 as a Service” or “LB as a Service”- so now we don’t talk about machines anymore. We now want to offer in the Self-Service Portal different items like for example “Create Pool”, “Create Virtual Server” etc…

Use-Case 1 will be achieved and covered by the IaaS capabilities of vCAC.
Use-Cases 2 and 3 will be achieved using the new Advanced Service Designer (ASD) which is a new capability in vCAC 6.*

This 3-part blog series will cover all 3 integration points staring with the first one: IaaS.

Requirements:

BIG-IP LTM 11.* and above.
vCAC 6.0 or 6.0.1
vCO 5.1 and above (I am using the embedded vCO 5.5.1 which is part of vCAC 6.0.1)
F5 vCO plugin version 2. I got it from here: https://devcentral.f5.com/d/f5-management-plug-in-for-vmware-vcenter-orchestrator-v200?download=true but best thing is to send an email vco@f5.com and they will supply you with the latest version, free of charge as far as I know.

Steps:

1. Install the F5 vCO plugin as explain here: https://devcentral.f5.com/articles/automating-application-delivery-with-big-ip-and-vmware-vcenter-orchestrator#.Uy2G-q1_sRE

2. Next you need to run the Attach LTM workflow in vCO. Most likely the Attach LTM workflow will appear to work OK, but when you try to run other workflows afterwards it says your device is disconnected. This is caused by an SSL certificate issue. Ensure your self-signed cert on the BIG-IP matches the name with which you are connecting to it, and also import that certificate into vCO using the vCO configuration user interface (https://your_vco_ip:8283) and restart vCO server.

When you run the “Attach LTM” workflow make sure the “use Rest API” is set to “no” as it is still in Early-Access mode so better use Soap (see below):

attach

3. Build a vCO workflow to add VM to an F5 Pool. My workflow looks like this:

w1

First scriptable task step will be to get the IP from the VM vCAC is dynamically provisioning. Next scriptable task step will be to find if the Pool name we have set as custom property at the blueprint level in vCAC exist or if we need to create it. If it exists then we just add the VM IP to the existing F5 Pool. If not then we create the Pool, then generate a random IP (192.168.110.*) to assign to the F5 Virtual Server (this customer didn’t have an IPAM solution but if they did then this is where I would call out to an IPAM system like Infoblox for example to get an IP), create the F5 Virtual Server, add an icmp monitor to the pool and then eventually add the VM IP as a pool member.

Input parameters will look like this:

1

Note: the two input parameters memberPort and PoolName will come from vCAC IaaS blueprint so needs to be defined at the blueprint level. the 3rd parameter vCAC:Entity will come dynamically from vCAC IaaS.

4. Build a vCO workflow to delete the Virtual Server, remove all VM’s from an F5 Pool and then delete the pool. My workflow looks like this:

w2

First scriptable task step will be to get all Pools from LTM then find the specific Pool we are after. Next scriptable task step will delete the Virtual Server, then remove all IP members from the Pool and finally delete the Pool itself.

You can alternatively write a workflow that doesn’t delete the Virtual Server or the Pool but just remove the specific member from the Pool. In fact I will show that use case in part 2 of this blog series.

5. Now we need to associate these 2 workflows with a vCAC external Stub. More information about vCAC external stubs and how they can be associated with vCO workflows and triggered at runtime can be found here in Chris Alleaume’s excellent blog: http://www.virtualnebula.com/blog/2014/1/24/running-vco-workflows-from-vcac-during-the-provisioning-of-a-virtual-machine

Make sure you associate your “add member to pool…” workflow with MachineProvisioned stub and your “remove member from pool…” workflow with MachineDisposing stub as described in Chris’s blog.

Make sure that these 3 properties are populated with values in your blueprint:

ExternalWFStubs.MachineProvisioned.memberPort >> for example ’80’

ExternalWFStubs.MachineProvisioned.PoolName >> for example ‘Web’

That’s it you are ready to rock!

You can request machines from the vCAC Self Service Portal and it will be automatically added to the F5 Pool of your choice and removed from it when the machine is disposed.

Here is how it will look like in LTM if the process has been successful (Pool is created and monitored and includes 1 member):

f5

For your convenience the two vCO workflows mentioned above can be downloaded from here:

http://tinyurl.com/mjzjf9m

Thanks!

Yuval T

, , , , , ,

Leave a comment

Managing The Software-Defined Enterprise

If you think about it – today, we care about applications more than ever – traditional or modern, the creation, delivery and management of those applications is a serious challenge for any IT organization.

Software-Defined Data Center (SDDC) is all about leveraging the basic principles of virtualization, Abstraction & Pooling, and now applying it to the Network, and Storage.  By virtualizing all aspects of the data center  IT organizations are moving to a completely virtualized infrastructure heavily dependent of Software rather than Hardware as was the case in the past.

By having the virtualized infrastructure fully abstracted from hardware, workloads running in the data center, can be deployed seamlessly on the any environment: on premise, hosted publicly or a combination of both.

A software-defined environment requires not just common management, but rather policy-based automation.  The Management & Automation Solutions this blog will discuss will cover the main VMware offerings including Cloud Automation, Cloud Operations and solutions to help manage the business and financial dimensions of your cloud implementation.

This is what they call the Software-Defined Data Center.

The Software-Defined Data Center is the ideal environment to create, run and manage your applications and the whole point of delivering applications to the business is to serve the users themselves.  There are a variety of solutions that leverage the software-defined data center to address the high demand from the internal IT customers, while maintaining IT control. This blog aspire to cover those solutions and provide tips on how to be successful when embarking on the Journey to the Software-Defined Enterprise.

Leave a comment