SLES for SAP on GCE
OK let’s spell that out, SUSE Linux Enterprise Server for SAP Applications on Google Compute Engine, that’s a mouth full and would have made for a really long title.
If you are following Google Cloud Platform news or SAP news you are most likely aware of the announcement that took place during the GCP Next ’17 conference that SAP HANA is now certified and fully supported by SAP on GCE. With the certification of SAP we have released SUSE Linux Enterprise Server 12 SP1 for SAP Applications and SLES 12 SP2 for SAP as on-demand and BYOS images on GCE. Also announced was the SAP HANA Express Edition which is based on SUSE Linux Enterprise Server 12 SP2.
The BYOS images are, like other SUSE BYOS images available to you by subscribing to the “suse-byos-cloud [at] googlegroups [dot] com” mailing list. This works by sending a message from your Google account to “suse-byos-cloud+subscribe [at] googlegroups [dot] com”. Once subscribed you can access the BYOS images. The on demand images are published in a “well known project” and are public by default. As always you can find the image names using pint.
Update 2017-05-26: The google group “suse-byos-cloud at googlegroups dot com” has been deleted and BYOS image in GCE are public and can be instantiated just like other public images.
As we were going through the preparations to get SLES for SAP ready for release one of the questions that was asked more or less frequently was, “Why SLES for SAP and not “regular” SLES for production?” SLES for SAP has some great features such as inclusion of HA but since we do not yet have a fencing agent what’s the advantage? Well, we will have a fencing agent eventually and that will only be available with a SLES for SAP instance, but even if you think you are not going to use HA, SLES for SAP is the right choice for production. The key feature is the overlap time for updates. All SUSE images have a lifecycle. This lifecycle is modeled to follow the distribution lifecycle model.
For SUSE Linux Enterprise Server the overlap period for updates is 6 months, but for SUSE Linux Enterprise Server for SAP Applications the overlap period for updates is 18 months. If we look specifically at the current cycle we have the following concrete timing:
SLES 12 SP2 and SLES 12 SP2 for SAP were both released in November during SUSECon ’16 that means updates for SLES 12 SP1 will end in May of 2017 but updates for SLES 12 SP1 for SAP will continue until May of 2018. This also means that the SLES 12 SP1 images have already been marked as deprecated and they will be remove in May when regular updates end but the SLES 12 SP1 for SAP images have not been marked deprecated and both the SLES 12 SP1 for SAP and SLES 12 SP2 for SAP images are active. The SLES 12 SP1 for SAP images will not get marked as deprecated until November 2017, the deprecation period is 6 months. Images that are active will be refreshed when there is a critical security vulnerability in any of the packages that are part of the image.
The practical implication is this; it takes a while to get SAP HANA certified on a new service pack. If this certification happens to take longer than 6 months than a SAP HANA installation running on SLES would run on an instance that no longer gets updates. If there is a security vulnerability disclosed after the 6 months overlap period for SLES the admin of the system has to choose to either move forward to the next service pack to get a fix for the issue and thus run on an unsupported, by SAP, version of SLES, or continue to run on the previous version of SLES with the vulnerability. Certainly not a good place to be in. This is where the extended support overlap period provided by SLES for SAP is worth its extra time in Gold. Historically SAP HANA certifies on a new service pack between 8 and 12 months after the new SP is released, thus well within the 18 months overlap period but most often after the 6 months overlap period of SLES. Therefore, when it comes to production there should be no question that SLES for SAP instances are the right choice.