IBM PureSystems for SAP
On April 11, 2012, IBM announced a new family of converged architecture systems called PureSystems. IBM does not use the term “converged architecture” in the materials released with this announcement, preferring the term “Expert Integrated Systems” due to the fact that it goes well beyond the traditional definition of converged infrastructure. Other companies have offered converged infrastructure in one form or another for a few years now. HP introduced this concept several years ago, but in my countless meetings with customers, I have yet to hear a single customer mention it. They talk about HP blades frequently, but nothing about the converged solution. Cisco UCS, on the other hand, is much more often mentioned in this context. While Oracle might try to suggest that they offer a set of converged infrastructure solutions, I believe that would be a stretch as each of the Exa offerings stand on their own, each with their own management, storage and network framework. The Exa solutions might better be described as special purpose appliances with a converged hardware/software stack. Dell’s converged solution is basically a management layer on top of their existing systems. This would be like IBM trying to suggest that IBM Systems Director is a converged infrastructure, which has never been the case as this would imply that IBM is ignorant.
IBM learned from the missteps and mistakes of our competitors and designed a solution that takes a leadership position. Let’s take a short journey through this new set of offerings during which I will attempt to illustrate how it is superior to competitive offerings. A more comprehensive look at PureSystems can be found at: http://www.ibm.com/ibm/puresystems/us/en/index.html
Converged infrastructures generally include servers, storage, networking, virtualization and management. Efficient utilization of resources is at the cornerstone of the value proposition in that businesses can deliver significantly more application environments with fewer personnel, lower hardware costs, greater datacenter density and lower environmental costs. Whether and how well companies deliver on these promises is where the story gets interesting.
Issues #1: open vs. closed. Some, such as Oracle’s Exa systems, are so closed that existing storage, servers, virtualization or software that you may have from a company other than Oracle, with rare exceptions, cannot be part of an Exa system. Others suggest openness, but rapidly become more closed as you take a closer look. Cisco UCS is open as long as you only want x86 systems, networking and SAN switches only from Cisco and virtualization only from VMware or Microsoft HyperV. VCE takes UCS further and limits choices by including only EMC V-Max or Clarion CS4-480 and VMware. By comparison, PureSystems are built on openness starting with the choice of nodes, x86 and Power, and OSs, Microsoft Windows, RedHat and SUSE Linux, AIX and IBM i. Supported virtualization offerings include VMware, HyperV, KVM and PowerVM. Storage can be almost anything that is supported by the IBM V7000 which includes most EMC, HDS, HP, Netapp and, of course, all IBM storage subsystems. Networking is built into each PureSystems chassis but supports network adapters from Broadcom, Emulex and Mellanox and Fibre Channel adapters from Qlogic, Emulex and Brocade plus both QDR and FDR Infiniband adapters. Top of rack (TOR) switching can be provided by just about any network technology of your choosing. Management of the nodes, networking, storage and chassis is provided by IBM, but is designed to be compatible with IBM Systems Director, Tivoli and a variety of upstream managers.
Issue #2: management interface. IBM spent a great many person years developing a consistent, intuitive and integrated management environment for PureSystems. Among a wide variety of cross system management features, this new interface provides a global search feature allow an administrator to quickly identify where a virtual resource is located in the physical world. Ask any administrator and you will find this is a lot more difficult than it sounds. Cisco does a great job of demonstrating UCS based on an impressive level of prep work. They show how easily images can be cloned and provisioned and this is indeed a significant accomplishment. The problem is that a significant amount of prep work is required. Likewise, when changes occur in the underlying environment, e.g. a new storage subsystem is attached or expanded, or a new network environment is added, a different set of management tools must be utilized, each with their own interface and some less intuitive than others. VCE offers a more consistent and intuitive interface, but at the cost of a very rigid set of components and software. For instance, “Vblocks”, the term for VCE systems, must be implemented in large chunks, not granularly based on customer demands, must be “approved” for SW or firmware updates by VCE, even emergency fixes for known security issues, and do not allow any sort of outside components at all.
Issue #3: the network is the computer. This is a bit tongue in cheek as that was the slogan of the old Sun company, anyone remember them? Cisco’s architecture seems to be an echo of this old and outdated concept. PureSystems, as noted above, provides an integrated network but allows a wide variety of adapters and upstream devices. By choice, customers can directly integrate multiple chassis together without the need for a top of rack switch until and whenever they want to communicate with external networks. For instance, should an SAP application server have to use a TOR switch to talk to a SAP DB server? Should a DB2 PureScale cluster have to use a TOR switch to talk among its nodes and to a central lock manager? Should an Oracle RAC cluster have to incur additional latency when communicating with its distributed lock manager? IBM believes the answer to all of the above is that it is up to the customer. If you want to use a TOR switch, you should, but that should be your choice, not a mandate. After all, IBM’s goal is to provide an excellent computing infrastructure, not sell switches. By comparison, Cisco’s architecture is dependent on very expensive 6100 and similar interconnects. In fact, Cisco even suggests that customers utilize VM-FEX technology as they claim that it greatly simplifies network management. What some customers may not realize is that to utilize this technology, you must disable the virtual switch used by VMware. This switch allows different VMs on a single system to communicate at near memory speeds. Using VM-FEX, this switch is disabled and communication, even between adjacent VMs, must communicate via TOR switches and instead of interconnect latencies measured in 100s of nanoseconds, those latencies can take several orders of magnitude greater time.
For SAP, it is reasonable to ask whether a converged infrastructure solution is required. Clearly, the answer is no, as customers have been successfully implementing SAP on everything from single, massive, 2-tier virtualized servers to large arrays of 3-tier, small, non-virtualized systems and everything in between for many years now. There is nothing on the SAP roadmap that specifies or certifies such technology. But, is there value in such a solution. The answer, obviously, is yes.
While consolidation of many different SAP instances on large, 2-tier virtualized systems offers tremendous value to customers, there are a variety of reasons why customers chose to utilize a landscape with multiple, smaller servers. Cost of acquisition is usually the biggest factor and is almost always less when small servers are utilized. The desire to not have all eggs in one basket is another. Some customers prefer to keep production and non-production separate. Yet others are uncomfortable with the use of virtualization for some systems, e.g. Oracle database systems under VMware. This is not intended to be a comprehensive list as there may be many other factors that influence the use of such an architecture.
If multiple systems are utilized, it is very easy to get into a situation in which their utilization is low, the number of systems is multiplying like rabbits, the cost of management is high, flexibility is low, the space required is ever increasing and power/cooling is a growing concern. In this situation, a suitably flexible converged infrastructure solution may be the optimal solution to these problems.
PureSystems may be the best solution for many SAP customers. For existing Power Systems customers, it allows for a very smooth and completely binary compatible path to move into a converged architecture. Both 2 socket and 4 socket Power nodes are available, the p260 and p460. Pure Systems feature an improved airflow design and a higher power capacity than IBM’s BladeCenter, which therefore allows for nodes that can be outfitted with the latest processors running at their nominal frequency and with full memory complements. As a result, these new nodes feature performance that is very close to the standalone Power 740 and 750 systems respectively. With a very fast 10Gb/sec Ethernet backbone, these new nodes are ideal for virtualized application and non-production servers. The p460 offers additional redundancy and support of dual VIO servers which makes it an excellent platform for all types of servers including database. One, or many, of these nodes can be used for part of an SAP landscape featuring existing rack mount servers and BladeCenter blades. Live Partition Mobility is supported between any of these nodes assuming compatible management devices, e.g. HMC, SDMC or PureFlex Manager.
Entire SAP landscapes can be hosted completely within one or more Pure Systems chassis. Not only would such a configuration result in the most space efficient layout, but it would provide for optimized management and the fastest, lowest latency possible connections between app and DB servers and between various SAP components.
Some SAP customers feel that a hybrid approach, e.g. using Power Systems for database and x86 systems for application servers, is the right choice for them. Once again, PureSystems delivers. Power and x86 nodes may coexist in the same chassis, using the same management environment, the same V7000 virtualized data storage and, of course, the same network environment. Clearly, the OSs, virtualization stacks and system characteristics are dependent on the underlying type of node, but regardless, they are all designed to work seamlessly together.
Yet other customers may prefer a 100% x86 landscape. This is also completely supported and offers similar benefits as the 100% Power environment described above, with the inherent advantages or disadvantages of each respective platform characteristics, which has been discussed at some length in my other blog postings.
There are many good blogs that have discussed PureSystems. Here are but a few that you may wish to check out: