Overview of PureApplication HA and DR

When I visited IBM customers and business partners in Bangkok and Manila last week, many of our conversations revolved around high availability and disaster recovery.

I previously contributed to an IBM Redbook on high availability and disaster recovery in PureApplication System that you can refer to as a resource. But now I’ve also completed a new overview presentation on implementing high availability and disaster recovery in PureApplication System. This presentation provides some background on HA and DR best practices in PureApplication System, summarizes the PureApplication features that serve as HA and DR building blocks, identifies a number of topologies that you can build using these building blocks, and closes with some important detailed considerations.

I hope you find this helpful as you design, implement, and test your solution!

PureApplication in Thailand and the Philippines

PureApplication in Thailand and the Philippines

Last week I spent time in Bangkok and Manila with the IBM PureApplication local teams and with IBM’s customers and business partners. It’s exciting to see continued growth in production workloads running on PureApplication System in ASEAN.

There were two repeated themes to many of our conversations. First was the importance of PureApplication’s pattern technology for building a DevOps pipeline that allows application and infrastructure teams to build greater confidence in the handoff from team to team between QA and production. Second was the strong interest in building high availability or disaster recovery solutions using PureApplication System. PureApplication provides many building blocks, such as GPFS and disk replication, that can serve as foundations for building HA and DR solutions.

See also: PureApplication High Availability and Disaster Recovery

Cookie size in nginx

I find in the age of corporate single sign-on and the multiplication of web applications and services, that more and more frequently I am running into server-side limits on cookie size. All of these servers and services are polluting my browser with their cookie crumbs. This results in web applications returning a 400 error due to header or cookie size limits.

While many web applications are beyond my control, I am taking the time to adjust my own servers so that they can accommodate these growing cookies. For nginx I’ve made the following adjustment to the server clause in my nginx configuration:

server {
  large_client_header_buffers 8 64k;
  client_header_buffer_size 64k;
  . . .
}

Understanding how the PureApplication placement engine works

IBM’s PureApplication products (System, Software and Service) include a sophisticated placement engine that works to manage and optimize factors such as system availability, application availability, CPU usage, and licensing.

But perhaps you’ve found yourself wondering just how, when and why PureApplication makes its placement decisions. Why did this virtual machine get migrated? Why didn’t that one get migrated? To help answer questions like these, Roy Brabson, Hendrik Van Run and I have just published an article describing in detail how virtual machine placement works in PureApplication System, Software and Service. We hope that this satisfies your curiosity!

PureApplication's two placement tiers

Ansible Playbook for Wekan

Ansible Playbook for Wekan

My team is experimenting with using open-source tools deployed internally for Kanban cards.

One tool we are exploring is Wekan, formerly known as Libreboard.

I deployed a Wekan instance to a RHEL 7 virtual machine for our testing. For this deployment, I wrote a simple Ansible playbook with a few additional configuration files (nginx config, Node PM2 configuration), in case there is ever a need to re-deploy the instance.

You can find my playbook and associated files on Github: wekan-setup. The files are as follows:

  • purekan.yml—Ansible playbook
  • wekan.yml—Node PM2 configuration
  • wekan.conf—nginx proxy configuration

You’ll need to customize things slightly based on your domain name or if you are using a distribution other than RHEL.

Corporate Service Corps

Corporate Service Corps

I had never heard of IBM’s Corporate Service Corps until my friend David Wierbowski participated in one of IBM’s 2014 corporate service teams.

IBM’s corporate service program is one of the ways that IBM contributes back to the communities where it does business. From what I’ve seen, it is also a fantastic experience for the individuals involved, offering both professional and personal challenges and rewards.

Dave recounted and reflected on his experience before, during, and after his service on his CSC blog. I enjoyed reading about the corporate service program through his eyes.

Stopping all instances on your PureApplication System

If your PureApplication System is protected by an uninterruptible power supply (UPS), you likely want to automate a graceful and orderly system shutdown in case of a power loss. To do this, you might create a Linux or AIX virtual machine nearby or even within your PureApplication System, have it monitor for SNMP traps indicating the UPS has detected a power loss, and then trigger an orderly shutdown of both the deployed application instances in your system, as well as triggering the shutdown of the system itself.

Here is a simple PureApplication command-line script that will stop all application instances on a system. If you are running this within the system itself, you should remember to exclude your own deployment from the list of deployments being stopped, and stop it last. This script stops all deployments without regard to dependencies between deployments. You may need to modify it so that dependent deployments are stopped in a particular order.

Finally, this script uses a different method than calling stop() on virtual system and virtual application objects. The built-in stop() method waits for each instance to complete stopping before moving to the next. Instead, this script initiates the stop of all instances in parallel, and then waits for all instances to complete stopping.

# Collect all deployments
listOfVsysClassic = deployer.virtualsystems.list()
listOfVsysRegular = deployer.virtualsysteminstances.list()
listOfVApps = deployer.virtualapplicationinstances.list()

# Initiate stops for all deployments
for vsys in listOfVsysClassic :
  print "Stopping vsys classic: %s" % vsys.name
  vsys.stop() # vsys classic method does not wait
for vsys in listOfVsysRegular :
  print "Stopping vsys: %s" % vsys.deployment_name
  deployer.http.putJSON(vsys.uri, {"operation": "stop"})
for vapp in listOfVApps : # This includes shared services
  print "Stopping vapp: %s" % vapp.deployment_name
  deployer.http.putJSON(vapp.uri, {"operation": "stop"})

# Wait for all deployments to reach a non-transient state
print "Waiting for all instances to stop"
for vsys in listOfVsysClassic :
  vsys.refresh()
  vsys.waitFor()
for vsys in listOfVsysRegular :
  vsys.refresh()
  vsys.waitFor()
for vapp in listOfVApps :
  vapp.refresh()
  vapp.waitFor()