Head in the cloud? Keep your feet on the ground with IBM with cloud computing for SAP.
Cloud means many things to many people. One definition, popularized by various internet based organizations refers to cloud as a repository of web URLs, email, documents, pictures, videos, information about items for sale, etc. on a set of servers maintained by an internet provider where any server in that cluster may access and make available to the end user the requested object. This is a good definition for those types of services, however SAP does not exist as a set of independent objects that can be stored and made available on such a cloud.
Another definition involves the dynamic creation, usage and deletion of system images on a set of internet based servers hosted by a provider. Those images could contain just about anything including SAP software and customer data. Security of customer data, both on disk and in transit across the internet, service level agreements, reliability, backup/recovery and government compliance (where appropriate) are just a few of the many issues that have to be addressed in such implementations. Non-production systems are well suited for this type of cloud since many of the above issues may be less of a concern than for production systems. Of course, that is only the case when no business data or intellectual property, e.g. developed ABAP or Java code, is stored on such servers in which case these systems become more and more sensitive, like production. This type of public cloud may offer a low cost for infrequently accessed or low utilization environments. Those economics can often change dramatically as usage increases or if more controls are desired.
Yet another definition utilizes traditional data center hosting providers that offer robust security, virtual private networks, high speed communications, high availability, backup/recovery and thorough controls. The difference between conventional static hosting and cloud hosting is that the resources utilized for a given customer or application instance may be hosted on virtual rather than dedicated systems, available on demand, may be activated or removed via a self-service portal and may be multi-tenant, i.e. multiple customers may be hosted on a shared cloud. While more expensive than the above cloud, this sort of cloud is usually more appropriate for SAP production implementations and is often less expensive than building a data center, staffing it with experts, acquiring the necessary support infrastructure, etc.
As many customers already own data centers, have large staffs of experts and host their own SAP systems today, another cloud alternative is often required: a Private Cloud. These customers often wish to reduce the cost of systems by driving higher utilization, shared use of infrastructure among various workloads, automatic load balancing, improvements in staff productivity and potentially even self-service portals for on demand systems with charge back accounting to departments based on usage.
Utilizing a combination of tools from IBM and SAP, customers can implement a private cloud and achieve as many of the above goals as desired. Let’s start with SAP. SAP made its first foray into this area several years ago with their Adaptive Computing Controller (ACC). Leveraging SAP application virtualization it allowed for start, stop and relocate of SAP instances under the control of basis administrators. This helped SAP to get a much deeper appreciation for customer requirements which enabled them to develop SAP NetWeaver Landscape Virtualization Management (LVM). SAP, very wisely, realized that attempting to control infrastructure resources directly would require a huge effort, continuous updates as partner technology changed not to mention an almost unlimited number of testing and support scenarios. Instead, SAP developed a set of business workflows to allow basis admins to perform a wide array of common tasks. They also developed an API and invited partners to write interfaces to their respective cloud enabling solutions. In this way, while governing a workflow SAP LVM simply has to request a resource, for example, from the partner’s systems or storage manager, and once that resource is delivered, continue with the rest of the workflow on the SAP application level.
IBM was an early partner with SAP ACC and has continued that partnership with SAP LVM. By integrating storage management, the solution and enablement in the IBM Power Systems environment is particularly thorough and is probably the most complete of its kind on the market. IBM offers two types of systems managers, IBM Systems Director (SD) and IBM Flex Systems Manager (FSM). SD is appropriate for rack based systems including conventional Power Systems in addition to IBM’s complete portfolio of systems and storage. As part of that solution, customers can manage physical and virtual resources, maintain operating systems, consolidate error management, control high availability and even optimize data center energy utilization. FSM is a manager specifically for IBM’s new PureSystems family of products including several Power Systems nodes. FSM is focused on the management of the components delivered as part of a PureSystems environment where SD is focused on the entire data center including PureSystems, storage and rack based systems. Otherwise, the functions in an LVM context, are largely the same. FSM may be used with SD in a data center either side by side or with FSM feeding certain types of information up to SD. IBM also offers a storage management solution called Tivoli Storage FlashCopy Manager (FCM). This solution drives the non-disruptive copying of filesystems on appropriate storage subsystems such as IBM’s XIV as well as virtually any IBM or non-IBM storage subsystem through the IBM SAN Volume Controller (SVC) or V7000 (basically an SVC packaged with its own HDD and SSD).
Using the above, SAP LVM can capture OS images including SAP software, find resources on which to create new instances, rapidly deploy images, move them around as desired to load balance systems or when preventative maintenance is desired, monitor SAP instances, provide advanced dashboards, a variety of reports, and make SAP system/db copies, clones or refreshes including the SAP relevant post-copy automation tasks.
What makes the IBM Power Systems implementation unique is the integration between all of the pieces of the solution. Using LVM with Power Systems with either SD, FSM or both, a basis admin can see and control both physical and virtual resources as PowerVM is built in and is part of every Power System automatically. This means that when, for instance, a physical node is added to an environment, SD and FSM can see it immediately meaning the LVM can also see it and start using it. In the x86 world, there are two supported configurations for LVM, native and virtualized. Clearly, a native installation is limited by its very definition as all of the attributes of resource sharing, movement and some management features that come with virtualization are not present in a native installation.
According to SAP Note 1527538 – SAP NetWeaver Landscape Virtualization Management 1.0, currently only VMware is supported for virtualized x86 environments. LVM with VMware/x86 based implementations rely on VMware vCenter meaning they can control only virtual resources. Depending on customer implementation, systems admins may have to use a centralized systems management tool for installation, network, configuration and problem management, i.e. the physical world, and vCenter for the virtual world. This contrasts with SD or FSM which can manage the entire Power Systems physical and virtual environment plus all of the associated network and chassis management, where appropriate.
LVM with Power Systems and FCM can drive full database copy/clone/refresh activity through disk subsystems. Disk subsystems such as IBM XIV, can make copies very fast in a variety of ways. Some make pointer based copies which means that only changed blocks are duplicated and a “copy” is made available almost immediately for further processing by LVM. In some situations and/or with some disk subsystems, a full copy process, in which every block is duplicated, might be utilized but this happens at the disk subsystem or SAN level without involving a host system so is not only reasonably fast but also does not take host system resources. In fact, a host system in this configuration does not even need to stop processing but merely place the source DB into “logging only” mode which is then resumed into normal operating mode a short time later after the copy is initiated.
LVM with x86 offers two options. Option 1, utilize VMware and its storage copy service. Option 2, utilize LVM native or with VMware and use a separate plugin with from a storage subsystem vendor. Option 2 works pretty much the same as the above described Power/FCM solution except that only certain vendors are supported and any integration of plugins from different companies, not to mention any troubleshooting is a customer task. It might be worthwhile to consider the number of companies that might be required to solve a problem in this environment, e.g. SAP, VMware, the storage subsystem vendor, the OS vendor and the systems vendor.
For Option 1, VMware drives copies via vCenter using a host only process. According to above mentioned SAP Note, “virtualization based cloning is only supported with Offline Database.” This might be considered a bit disruptive by some and impossible to accommodate by others. Even though it might be theoretically possible to use a VMware snapshot, a SID rename process must be employed for a clone and every table must be read in and then out again with changes to the SID. (That said, for some other LVM activities not involving a full clone, a VMware snapshot might be used.) As a result, VMware snapshots may quickly take on the appearance of a full copy, so may not be the best technology to use both for the overhead on the system and the fact that VMware itself does not recommend keeping database snapshots around for more than a few days at most, so the clone process typically uses the full copy option. When the full copy is initiated by VMware, every block must be read into VMware and then back out. Not only is this process slow for large databases, but it places a large load on the source system potentially resulting in poor performance for other partitions during this time. Since a full copy is utilized, a VMware based copy/clone will also take radically more disk storage than a Power/XIV based clone as it is fully supported with a “changed block only” copy.
Of course, the whole discussion of using LVM with vCenter may be moot. After all, the assumption is that one would be utilizing VMware for database systems. Many customers choose not to do this for a variety of reasons, from multiple single points of failure, to scaling to database vendor support to potential issues in problem resolution due to the use of a multi-layer, multi-vendor stack, e.g. hardware from one vendor with proprietary firmware from another vendor, processor chip from another vendor, virtualization software from VMware, OS from Microsoft, SUSE, Red Hat or Oracle not to mention high availability and other potential issues. Clearly, this would not be an issue if one eliminates database systems from the environment, but that is where some of the biggest benefit of LVM are realized.
LVM, as sophisticated as it is currently, does not address all of the requirements that some customers might have for a private cloud. The good news is that it doesn’t have to. IBM supplies a full range of cloud enabling products under the brand name of IBM Smart Cloud. These tools range from an “Entry” product suitable for adding a simple self-service portal, some additional automation and some accounting features to a full feature “Enterprise” version. Those tools call SD or FSM functions to manage the environment which is quite fortunate as any changes made by those tools is immediately visible to LVM, thereby completing the circle.
SAP and IBM collaborated to produce a wonderful and in-depth document that details the IBM/Power solution: https://scn.sap.com/docs/DOC-24822
A blogger at SAP has also written extensively on the topic of Cloud for SAP. You can see his blog at: http://blogs.sap.com/cloud/2012/07/24/sap-industry-analyst-base-camp-a-recap-of-the-sap-cloud-strategy-session/
No comments yet.