With this blog I'm starting a series about SAP on Cisco UCS and some configurations and observations I have made in our labs. Among the many HA solutions which are certified for SAP, I mostly worked with SLES High Availability Extension, therefore this will be used for showcasing. Beyond that, SUSE is providing detailed best practice guides for SAP HA, so I won't go too much into detail.
The first hit will be about Service Profiles as part of a standardized SAP HA stack. In Cisco UCS, the configuration of a blade is stored in a Service Profile which is defined and applied by the UCS Manager. The Service Profile comprises basically the whole hardware identity of a server, such as MAC addresses, HBA configuration, BIOS settings, etc.
In this simple setup, two Service Profiles have been assigned. Each blade now holds the attributes defined in the Service Profile. For maximal flexibility, we do not use the local disks of the blades, neither for the OS nor for any other data. Every data is stored on a storage system (SAN and / or NAS) which makes them available to any blade which is physically connected to the storage. This concept enables every system to be booted from every blade. The right OS image will be identified through the MAC address (PXE boot) or the WWN (SAN boot) of the assigned Service Profile.
In case of a hardware failure, without the abstraction provided by Service Profiles, a faulty server has to be fixed first before it can join the cluster again. With Cisco UCS, the Service Profile can easily be migrated to a spare blade. The new blade does not even have to be the exact same hardware.
The re-assignment of a Service Profile takes roughly 5 minutes. Even when adding the OS boot and cluster join, the time where the cluster resources are running unprotected on only one node is significantly lower than in other environments that are struck by a server hardware failure.
A nice bonus for SAP systems not using the SAP License Server is the fact that the hardware key does not change. Therefore, only one license key per Service Profile has to be maintained.
In the next blog, we're going to add virtual machines as cluster nodes and talk about storage fencing between virtual and physical nodes.
1 Comment
