As you probably read already on the news recently, IBM raised the bar a little bit higher with IBM expert integrated systems, especially with the IBM PureApplication System. This new solution is a product of collaboration between the hardware branch (Systems Technology Group, STG) and the software branch (Software Group, SWG) of IBM.
I just came back from an intensive week at the IBM Raleigh Triangle Park (RTP) in North Carolina where I, and several colleagues of mine, met several IBM PureApplication System specialists. What I can immediately say is that all you hear about IBM PureApplication System is true. Indeed with IBM PureApplication System you can leverage years of expertise and software improvement to deploy complex DB2 and WebSphere Application Server environments faster than you ever dreamed. Time-to-market or time-to-value simply change their scales and are now in the range of hours.
This being said, companies that are looking for such fast deployments, and that can benefit from such a solution in a highly competitive landscape also need business continuity. So during this week we dig a little to find answers. The remainder of this article has some information, which will, I hope, bring you peace of mind and let your interest for IBM expert integrated systems and PureApplication especially grow.
First, let’s look at the hardware
Because I am a hardware guy, working for IBM STG, starting from the physical layer seems easier to me. IBM consolidates its decades of expertise to design a solution without any single point of failure (SPOF). Indeed each single piece of hardware component is redundant, from the power supplies to the top-of-rack (TOR) switches. That might sound like a strange approach but this is actually how the PureApplication System is physically set up within the rack; believe me, I saw and touched a couple of racks in the RTP data center.
I did not take pictures of the IBM PureApplication System but some of my colleagues did. I will point you to their blog entries, but in the meantime, the following screen capture is from the PureApplication System Manager.
This GUI is so powerful in terms of management that I thought it was worth showing it. At the bottom of the rack are three chassis. Each has redundant power supplies, redundant fans, redundant Fibre Channel switches, redundant Ethernet switches, and depending on your configuration — small, medium, large, or extra large (S, M, L, or XL) — a predefined number of Integrated Technology Element (ITE) nodes. In addition to these basic elements, in the two first chassis (the two at the very bottom) are redundant system managements: two PureApplication System Managers and two Virtual System Managers.
On top of these three chassis resides the storage, which consists of two IBM Storwize V7000 backend storage units.
Before joining IBM Switzerland in storage pre-sales, I was working for IBM France in Montpellier and building remote demonstrations. The most popular one was the V7000, so I am familiar with that product for many years now. As you can guess, I presented the product many times; there was one question I was never able to answer until a few ago: Why does IBM gather all mature technology, such as storage virtualization from the IBM high-end storage into the IBM Storwize V7000, which is a midrange product? Now I know, this was a part of the IBM expert integrated systems strategy.
In addition to basic functionalities inherent to storage products — such as controllers in an active/active configuration, or disks (HDD and SSD) protected by RAID-5 configuration, and redundant power supplies with batteries to empty the cache to disk in case of power alimentation failure — the V7000 brings enhanced features like storage virtualization in order to strengthen the PureApplication System. Finally at the very top of the rack you can see two redundant switches, which can connect the PureApplication System to the customer network.
Then, the patterns of expertise
In addition to the hardware protection, from a software level now, IBM has consolidated its experience in patterns of expertise. These pattern, can help you more quickly deploy your complex DB2 and WebSphere Application Server environments, but they are also deployed in a cluster mode for both DB2 and WebSphere Application Server.
Last but not least, the PureApplication System itself is smart enough to deploy each clustered instance on physically separate ITE nodes (when possible). That means that each virtual machine (VM), because of the cluster mode, has its mirror on another ITE node, avoiding any disruption even in case of ITE hardware failure.
If you need more information see the High availability topologies for IBMPureApplication System article by:
- Kyle Brown (IBM Distinguished Engineer)
- Rohith Ashok (the lead architect of PureApplication Systems)
- Andre Tost (Senior Technical Staff Member in the IBM WebSphere organization),
The article also has high availability configuration information but keep in mind that the article is only the first of a set of documents to be released later, which will cover all other aspects and give more detailed examples.
Need more protection? Look at the high-availability configuration
Thanks to the DB2 HADR and the WebSphere Application Server high availability (HA) capabilities, you can, through additional manual interventions, configure your two PureApplication Systems together. Within the same datacenter or through two datacenters geographically distributed.
Although the article listed above might talk more to software developers, or at least WebSphere Application Server and DB2 people, I do think describing it at the very high level for hardware people like me is worth it to help you understand a little bit more how IBM improves the synergy between STG and SWG.
The two options described (same data center or geographically distributed data center) require an additional external load balancer, which will be in charge of the failover in case of an entire site or PureApplication System failure.
The main difference between the two is how the cell is configured. In the first option, you have only one cell containing all IBM HTTP Servers, all WebSphere Application Servers, and one Deployment Manager (DMgr) located in the first PureApplication System. In the second option, you have one cell on each site containing IBM HTTP Servers, WebSphere Application Server, and DMgr.
In addition to these cells, for both options you need to create two DB2 HADR nodes: one primary on the first PureApplication System and a secondary on the other one.
For the first option during the failover, the cell, even reduced by half of the WebSphere Application Server and IBM HTTP Server nodes, will still be able to reach the DB2 node because of the HADR configuration.
For the second option, the main difference is that each cell will behave as though it were alone — no communication between cells in order to avoid WAN communication. However the DB2 HADR works the same as the first option and the load balancer will also do the job in case of PureApplication System failure just as in the first option.
So what are additional differences between the two?
On one hand, the first option is better in term of load-balancing and manageability because only one cell, meaning one DMgr, is handling both racks, but it requires a more complex setup.
On the other hand the second option is easier to configure and safer in case of site disaster, but it requires double management on both PureApplication Systems.
From a backup standpoint
So we went through the hardware protection, the patterns of expertise protection, and the high availability protection — but what if we just want to back up the solution?
I agree that a disaster recovery (DR) solution as I mentioned is much safer, but having two IBM PureApplication System might be expensive. So probably the first question you need to ask yourself is, do I need a recovery time objective and recovery point objective equal to zero for all my applications? If the answer is no, then keep reading — I think the following information might interest you.
If the goal is to back up the PureApplication System, then to back up data you can use a backup software like IBM Tivoli Storage Manager. First, back up your Management Console. This operation ensures that the very high level configuration of your IBM PureApplication System, which includes all patterns of expertise and the catalog for example, will be saved. Obviously this step is performed outside the PureApplication System rack on another server through IP and through the Secure Copy Protocol (SCP). This server can be located remotely as long as it is reachable by the PureApplication System.
Next, back up your deployment configuration, which means, for example, all the patterns currently deployed and all virtual machines currently deployed. I figured out, during my intensive week at RTP, that the patterns of expertise and catalog are one thing, the other is the deployment configuration based (or not based) on these patterns or catalog. So you need to back up both.
Finally, thanks to the Tivoli Storage Manager agents embedded in the PureApplication System, you can back up through an external Tivoli Storage Manager server your virtual machines and data.
Note that Tivoli Storage Manager agents are already embedded but licenses are not, and that you need an additional module for Tivoli Storage Manager to handle a virtualized environment. But you may use another backup software if you want.
From a recovery stand point, you must first restore the Management console from the external server, still through the Secure Copy Procol (SCP) on a new PureApplication System. Then, restore the deployment configuration in order to redeploy all patterns and VMs. Finally, use Tivoli Storage Manager to restore all your data.
Note that you may restore the content through Tivoli Storage Manager (still through the appropriate module) on another VMware environment if you do not have a second PureApplication System.
I hope this is clearer now, and that you feel more confident with expert integrated systems.
Stay tuned for more information about IBM expert integrated systems.