Your application, hardware failure and you
john.hawkins 270006E9RX Visits (1850)
Although PureApplication System has some great local hot swap and off-site Disaster Recovery technology you still need to understand what it means for you and your application. I haven't found any concise documentation for this so I'm sharing what I've found out here.
Pure has the ability to shut down the workloads on a compute node and move it to another Compute node. This is called "evacuation". Evacuations can be planned or unplanned (you can guess the difference !).
"Why would I do a planned evacuation?" you may be asking yourself. Well, if you need to upgrade your compute nodes for instance. Or maybe it's got an intermittent fault that needs looking at (it happens – even with IBM hardware).
With PureApplication systems you can plan to close down a node. If a planned evacuation takes place then Pure will migrate your running vms to other nodes. In this case the Pure "magic" makes sure that your workload never knows what happened: it gets the same IP address, same disk etc. Now, that's good, but the real sauce is that it mirrors the exact state of the VM when you took it down – that's pretty cool ! To be clear: your complete memory, CPU, disk, network resources are migrated, even your tcp adapter/packet state is preserved with no data loss or discrepancy. This means that your application will be restarted on a new node and continue right where it left off – even if it was in the middle of a transaction !
One minor downside is that you may notice a slight decrease in performance for one or two minutes, but, if that's the price you pay for not having to worry about a node being brought down then that's cheap by my book.
For an unplanned evacuation (failure) of a Node - Pure will still move the workload VMs to another node in the rack. However, in this case, the move won't be so smooth. To the application, it will look like the VM has crashed and it's been restarted (naturally enough because that's what happened). There's no attempt to reproduce active memory state or anything else. In this case, standard transaction semantics apply and, if you care that you don't lose data, then you need to code around it. There are plenty of discussions on how to code transactions so I won't go into that here.
Not only can Pure do hot-swap and VM evacuation across a single Pure box but it can do Disaster-Recovery across two racks. Disaster-Recovery is usually between two distant data-centers which you don't think will be affected by the same physical problems at the same time. Look at this video to see just how easy that can be setup: http
The functions just described are at the infrastructure level. Pure can also help you at the software level too. For instance, the in-built WebSphere Application Server application pattern will deploy two WAS nodes on two different compute nodes. This means that if the first compute node fails then the second one takes over while the first recovers (this may mean that the first instance gets moved to a different node remember – but all that's taken care of for you). Be careful though, this does require you to set your scalability policy so that there a minimum of two WAS nodes in the cluster.
So, to summarise: Pure is IBM's latest system of expertise. They've not only given it expertise in terms of the software patterns but they also help you manage the solutions at runtime too.
For a planned shutdown of a node you have no fears. Your solution is in very safe hands – the application will not know that it ever got moved nor will the clients that connected to it.
For a node failure the application will get rebooted, as if it had just started up, so you're going to need to code around any data loss issues you may have. This applies to whether the failure was a local inter-rack failure or a planned or unplanned Disaster-Recovery (cross-rack) scenario.