In a previous post, I showed how you can create a Helion Development Platform microcloud in the HP Public Cloud. In this post, I will show you how to add DEA’s to this in preparation to deploy your applications.
There are 2 types of DEA you can add, Windows or Linux. This post will cover Linux. I will cover Windows in a later post.
There are also 2 ways you can add a node, using the cf-mgmt tool, or by creating a nova instance and performing a manual configuration. Either works, but we will use cf-mgmt. Why? Well a DEA doesn’t need much configuration, so there is little value/flexibility in creating a nova instance and performing the steps manually (although a side project on my side project is to use Ansible to do all of this).
So lets get started. I’m attached to my jump box, and creating a couple of new scripts – add-dea.sh and add-dea.yml.
The first script add-dea.sh is basically the cf-mgmt command wrapped in a script. This allows me to pop it into source control.
~/linux-amd64/cf-mgmt add-role dea –load add-dea.yml
The add-dea.yml file is the configuration file used by the script:
constructor-image-name: HP Helion Development Platform – Application Lifecycle Service Installer 126.96.36.1992
seed-node-image-name: HP Helion Development Platform – Application Lifecycle Service Seed Node 188.8.131.522
Most of the above should be pretty straight forward however:
- Version: yes its the version
- constructor-image-name & seed-node-image-name: these are the image names from OpenStack to use to create the cluster. You can use nova image-list | grep Application to view the available images.
- cluster-prefix: is the prefix you previously used when creating the cluster.
- count: this is how many instances to create. I recommend only doing a couple at a time otherwise you could hit authentication token timeout issues.
- az: this is the AZ you wish to create the instances in. See my note below for more.
- constructor-flavor: this is the constructor image size
- flavor: this is the DEA node size
- network-id: this is the internal network id. You can grab this using neutron net-list.
- external-network-id: this is the network id of the network that contains the floating ips – it’s probably called Ext-Net. See above for the command to list the networks.
- keypair: the keypair you used to create the cluster in the first place.
- stack: lucid64 is the ubuntu stack we will use.
AZ’s and high availability of DEA’s
To increase your HA capability, I’d advise you to deploy multiple DEA’s in each AZ. There are 3 AZ’s in public cloud, so i created DEA instances in each. Simply change the az: tag in the configuration file to change the target az. I ended up creating a total of 12 DEAs, which is a good size to give the platform a run for its money.
Once you have the AZ’s defined in OpenStack – you have to do the same in ALS. To do this you need to connect to each DEA and run the following:
kato node availabilityzone AZ1
kato process restart
You can view your Availability Zones from the web console by hitting Settings/DEA then Availability Zones.
Now when an application is deployed with more than one instance (which is always a good idea) ALS will deploy the instances across availability zones.
Although we now have DEA’s across multiple AZ’s there are other parts of the cluster that we will also need to make highly available. I’ll be covering that in later posts.
THIS POSTING IS PROVIDED “AS IS” WITH NO WARRANTIES, AND CONFERS NO RIGHTS