SAP has certified the Amazon Web Services cloud as a suitable platform for running production instances of some products. The Amazon cloud is probably the most well known of the Infrastructure as a Service cloud vendors. Before making any sizing decisons or or decisons regarding using AWS for SAP systems, please check the latest version of the Operating SAP Solutions on AWS White Paper (PDF).  This details the special considerations for SAP Systems on AWS, including some Operating System restrictions.

However, there are some other caveats and gotchas that you need to be aware of before putting any system (SAP or otherwise – even your Development, Testing or QA instances, let alone Production instances) in any cloud environment. It is sometimes tempting, even at a very high-level, to think of cloud based infrastructure as a form of what used to be called remote computing, where the datacenter is located some distance from the users, administrators and developers, just much cheaper to use and much quicker to provision. For most parts of an SAP implementation, this does hold true; users connect via NWBC, a browser or the
SAP GUI to a DNS name, and manipulate the information they find – they add to it, update it, share it, regardless of where it’s stored and the computer(s) used to perform the work.

However, this does avoid a key concept of Cloud computing which the idea of commodity virtualisation of everything. So, bearing this in mind, let’s explore some important lessons about Cloud Computing.

Lesson 0: Only the paranoid survive

Andrew Grove was chairman of Intel when he published a business book called ‘Only the Paranoid Survive’. It sounds like an awfully cold way to deal with business colleagues, but when it comes to down to me and the computers, it has been a useful one.

Lesson 1: SLAs Are Meaningless

You can’t compare any kind of hosting services based on their advertised SLAs. Instead, base your comparisons on their response to you and your company’s issues. Regardless of what they say, ‘stuff’ will happen. Yes, Amazon has a service level agreement for EC2 of 99.95% uptime, averaged over the last year. You would imagine that this was set (by Amazon) based on historical information. However, as they say in the financial pages “historical behaviour is not an indicator of future performance”. And when ‘stuff’ happens, where are you in the queue, for personal attention, recompense, or even just a communication of some sort ?

By the way, due mainly to the recent outage, EC2′s uptime over the last year is around 99.5%.

Lesson 2: YOUR Architecture CAN save You from Cloud Failures, but …

Disaster Recovery processes have two major SLAs; the Recovery Time Objective, which is a duration of time (an SLA, really) within which a business process must be restored after a disaster (or disruption), and the Recovery Point Objective which describes the acceptable amount of data loss measured in time. By the way, the O stands for Objective, not Agreement or Mandate (see Lesson 1).

This means that if an instance becomes unavailable to the business, they want a working system within the RPO time, with data loss of less than the RTO. This requires the same thinking and planning that goes into Disaster Recovery planning for an in house system. In turn, this means managing and planning for Disaster Recovery and Data Security, and allowing for the typical requirements of a Disaster Recovery Plan, except with a Cloud twist to them…

• You still need to choose the right infrastructure,
  i.e. Does your vendor have seperate physical locations ?
• You need to manage your view of the infrastructure,
  i.e. How easy is it to transfer backups from one physical location to another ?
• You still need to test the transfer of backup data,
• You still need to test the restore / restart of your system in the alternate location,
• Your vendor may provide alternate physical locations,
  but do you have / need an alternate provider ?
• and so on.

Lesson 3: There is a BIG difference between virtual machines and the hardware.

Things get a little more difficult at the micro level. Fault-tolerant environments are a centerpiece of the cloud hype, but generally, most developers don’t see, and therefore don’t think, about the difference between virtual and physical hardware. The issue with virtual machines (in-house virtualisation or clouds) is that the view from the operating system ends at the hypervisor. You can not see what happens at the metal. Now, for computer systems to work as we have grown to expect, certain things are sacrosanct. This is because without them, there is no guarantee that what we write will be there when we go to read it (this applies just as much to memory as it does to disk).

An example is the sync() or fsync() system call, that instructs the Operating System to write all the data currently in the filesystem buffers, out to disk. Now, in virtual machines, whether or not fsync() does what it should is a bit of a mystery. In fact, there has been suggestions that in particular circumstances and under high load Amazon’s Elastic Block Store, at least according to sources close to Reddit, will happily accept calls to fsync(), saying that the data has been written to disk, when it may not have been.

No amount of virtual architecture is going to save you from virtual hardware that lies.

Lesson 4: You don’t HAVE to put ANYTHING in the cloud.

The general rule is that if the machine / image dies, then you must be able to recover data, or restore the service. If you’re hosting a database server, then it will need to be restored or recovered. On the other hand, an application server is much simpler; just write some configuration files. Once you start looking at it like this, it may make sense for a more risk adverse site to put some server types into the cloud and leave others in the data centre. In short, Virtualisation and Cloud computing is not a universal panacea to hardware resource problems.

Of course, many people would say that “commodity” computing is a misnomer, because servers are not really something that should be commoditized, that a “pick one of four sizes” offering is insulting. To a certain extent this is true, but Cloud computing servers are so cheap that you can build around inefficiencies in some parts of the commodity offering by overcompensating in others.

For example, once people realise how cheap CPU and Memory are on IaaS services, they tend to go at least one ‘size’ higher than they would for an in-house server, and they still see massive savings. Regardless of what the purist thinks, it is becoming much more business-efficient to throw hardware at performance problems than it is to spend time investigating the root cause, which leads into …..

Lesson 5: You still need to tune and manage your systems.

In Cloud computing costs are tied directly to resource usage. The virtues of cloud computing are a double edged-sword; Because
provisioning systems is so easy, you may see developers running a dozen tests at once, instead of one after another, to speed up implementation cycles. This means any inefficiencies in the base systems used for such
testing will be magnified, which will directly impact costs.

Just as importantly, resource usage variations in your production systems will show up directly in the bill. However, the customer or business user paying the bill will want to know why these variations have occured. Are they due to different processing rules, different volumes,
program or system changes ? You want to see a consistent relationship
between the business workload and the resource usage (and therefore
cost). This makes budgeting and planning much easier for the Business,
and provides them with confidence in both the SAP support teams and the
platform.

Lesson 6: It is not enough to be secure….

…you need to be seen to be secure. Amazon already performs regular scans of the AWS entry points, and independent security firms perform regular external vulnerability threat assessments, but these are checks of the AWS infrastructure (such as their payment gateways, user security and so on). They don’t replace your own vulnerability scans and penetration tests. Because it may be mistaken as a network attack, Amazon ask to be advised of any penetration tests you wish to perform.  These must be limited to your own instances.

Being seen to be secure also means using all the features (including the Amazon Virtual Private Cloud) that are referenced in the AWS Security White Paper. This document, which is updated regularly, describes Amazon’s physical and operational security principles and practices.
It includes a description of the shared responsibility for security, a
summary of their control environment, a review of secure design
principles, and detailed information about the security and backup
considerations related to each part of AWS including the Virtual Private
Cloud, EC2, and the Simple Storage Service,

The new AWS Risk and Compliance White Paper
covers a number of important topics including (again) the shared
responsibility model, additional information about the control
environment and how to evaluate it, and detailed information about the AWS
certifications. Importantly, it also includes a section on key compliance
issues which addresses a number of topics that get asked about on a
regular basis.

Summary

There are differences between managing real servers, virtual servers and Cloud based servers. However, much of what is required for SAP landscapes and Implementations is the same which ever platform you use. In fact the BASIS team may be the only people who notice the difference. One of the biggest differences is the perception of control and ownership, because you can’t “hug your server” any more. What are the biggest differences you see, and how do you see them impacting you if or when your organisation starts implementing SAP systems in the Amazon Cloud ?

After my previous post, you either have your own Windows 64-bit AMI image, or access to the Public AMI I have created, called sap.nw70.win-64.db2. In this exercise, we will use this as the basis of a new, private, image that will:
* contain the appropriate installation data (including registery keys) for SAP NW7,
* be capable of online / offline backups, using SAP tools,
* provide a painless way of running 24×7.

Prerequisites

* EC2 and S3 Accounts with Amazon,
* access to a Solution Manager system (for the installation key),
* access to an OSS ID with download authorisation.

Architechture

Once we terminate an Amazon instance, we lose all changes to it. Saving our database and configuration changes by bundling the changed system into a new AMI will take a non trivial amount of time; Certainly enough to prevent it being run 24×7. Additionally we will lose lots of usefull ABAP and JAVA stack logs unless we bundle the running instance every time we shut it down.

Just as well there’s an alternative, called Elastic Block Storage. This allows you to create data volumes and mount them on your image. They are persistent, and more importantly, can be backed up by snapshots, from the AWS Management Console.

So that leads to an architechture (or rather, disk layout) as follows:

• Drive C: AMI instance, boot disk
• Drive D: AMI instance, ephemeral disk (data lost whenever instance shuts down)
• …
• Drive H: AMI instance, ephemeral disk (data lost whenever instance shuts down)
• Drive W: Persistent Disk, for storing disk-to disk backups DBMS and / or logs
• Drive X: Persistent Disk, for SAP and DB2 Intallation
• Drive Y: Persistent Disk, for DB2 logs
• Drive Z: Persistent Disk, for storing installation files

Creating EBS (Persistent) Volumes

To create EBS Volumes, go to the EBS Volumes section of the Amazon Management Console. The major issue with creating volumes is that you can only attach / mount an EBS volume on an instance that is running in the same Availability Zone. This does mean that all your volumes must be in the same Availability Zone, if they are to be attached to the same instance.

• Drive W: vol-a82bc7c1, for storing disk-to disk backups DBMS and / or logs
• Drive X: vol-3f658956, for SAP and DB2 Intallation
• Drive Y: vol-4451bc2d, for DB2 logs
• Drive Z: vol-fc2bcb95, for storing installation files

Note that these are empty, unformatted, unmounted, unattached volumes (at the moment…).

Attaching EBS Volumes to our Instance

To attach the volumes to an instance, we need to have an instance running. Start up an instance of your image or of sap.nw70.win-64.db2.

You assign a name to a volume when you are formatting it. You do this by running the Computer Management (if you’re running an instance of sap.nw70.win-64.db2, this should be on the Desktop of user sapinstall) and formatting and naming the volumes. Make the names distinctive, and related to their purpose, for example sw_repository.

Now use the C:\Program Files (x86)\Amazon\Ec2ConfigSetup\Ec2ConfigServiceSettings.exe program and the Drive Mapping tab to control which volume gets mounted to which drive letter. This is important, because we want to make sure that our sap_install, db2_logs, and backups volumes are always mounted on the same drives. Once the current image is bundled and registered, any instance launched from the new AMI will contain the setting we have configured in Ec2ConfigServiceSettings.exe.

System Specific Configuration

Change the hostname (or in Windows terms, the Computer Name) to one of your choosing (Start –> Control Panel — System –> Computer Name –> Change). Run Ec2ConfigServiceSettings.exe. and make sure the Set Computer Name flag and the Sysprep flag on the Syprep tab are disabled – They should already be disabled, if you are using a copy of sap.nw70.win-64.db2.

Check the swap space (Start –> Control Panel — System –> Advanced –> Performance Settings — Advanced, Virtual memory). Again, this should already be correctly set if you are using a copy of sap.nw70.win-64.db2.

Edit the hosts file in C:\windows\system32\drivers\etc to include your Computer Name as a valid host name, for internal SAP and DBMS connectivity.

Finally, bundle the instance using the AWS Management Console and register the resulting image under your own image name. The purpose here is to save the customisation you have done if you have a problem with the SAP installation. As part of the process of bundling, the instance is shut down and restarted.

For future reference, if you restart the instance yourself, using Start –> Shutdown and specifying Restart, you don’t loose any information or configuration from the C drive as you would if you terminated it from the AWS Management Console. This is because the later removes the underlying resources, while using Start –> Shutdown –> Restart doesn’t release the underlying resources.

Security and Firewalls

EC2 provides its own set of firewall rules called Security Groups. The defaults values are, essentially, just enough to get you access to the server itself.

Installation

Download the appropriate files from http://service.sap.com/swdc (you’ll need an S number with download authorisation), extract / expand them and store the results on the Z drive. I stored the download files under Z:\NW70SR3 and expaneded them into their own folders on the Z drive.

Make sure you read the appropriate OSS notes. For the ECC6 IDES, the important ones are:
0799639 – General IDES related
0956921 – NW7 ECC6 SR3 IDES related
1244548 – NW7 ECC6 SR3 IDES related
and
1126127 – DB6: Deferred Table Creation and Row Compression

Otherwise, the install follows the standard process, as detailed in the appropriate installation guide (in my case, the NW7.0 SR3 ABAP+JAVA / Windows/ DB2). The two exceptions are:
* Specify that the SAP and DBMS Installations go on an EBS volume (i.e drive X)
* in my case, specify that the DB2 logs go on an EBS volume (i.e. drive Y)

The full IDES install took around 30 hours run time (think of it as $20 or so well spent) from when I started sapinst (that time did include checking and amending my previous implementation notes). The majority of the time is spent loading about 150GB data into the DB2 database. However, once sapinst had accepted the Solution Manager Key, you can disconnect RDP and leave the install running.

Saving your image

Once the installation is complete, you’ll want to back it up before you go any further. Using the SAP MMC, shut down SAP (or logon to Windows as the SAPService<sid> user and shut down SAP).

Use the AWS Management Console to bundle your running instance.

Basically, the image consists of whats on the C Drive, so backing up your EBS Volumes requires you to use the AWS Management Console to save snapshots of them. The EBS volumes are stored and charged for at the Amazon S3 rates. Just like EC2, however, you are only charged fo what you use. This means that if you define a 500GB volume, write a 1 GB file to it and create 4 snapshots of the volume, you will charged for 5GB of storage; 1GB data on the volume, plus 4 lots of 1GB of snapshot. backup.

When you’re finished with the instance, shut down SAP and don’t forget to terminate tthe instance via the AWS Management Console (otherwise you’ll be charged for it !!).

Running your SAPSystem

Start an instance of your image and attach the EBS volumes to the running instance. The work of of assigning drive letters, in the correct order, to each volume is controlled by our configuration work earlier in Attaching EBS Volumes to our Instance. One of the issues currently outstanding is that thess will actually get mounted on subsequent restarts of this instance (which we perform below).

Logon to the instance and update / verify the Swap Space sttings via Start –> Control Panel — System –> Advanced –> Performance Settings — Advanced, Virtual memory.

Accessing your SAP System

Assuming you have opened the correct ports in the Security Group specified for this instance, you can now put the appropriate values into your SAP GUI …..

Whats next ?

You now have a running SAP system. However

• No DBA processing, i.e. no DB13 jobs, no backing up of logfiles etc has
  been implemented, so once you’ve tested connectivity, stop the SAP and
  DBMS systems and take snapshots of your SAP & Database volume.
• The SAP*, DDIC and IDADMIN passowrds are well known (or easily determined). Change them
• No post implementation work (i.e. SGEN) has been done,

The purpose of the exercise is to demonstrate how quickly you can run up a demonstration, training or testing system. Depending on how many resources you want to pay for (CPUs and memory), this can be quicker or slower.

However, it has been my experience, based on several green fields implementations, individual system implementations and upgrades, and feedback from others, that building an appropriate server – whether physical or virtual – can take up to 2 weeks. Using the approach detailed here, services such as provided by the Amazon EC2 service reduce this to the 45 minutes it takes to configure and bundle a standard public instance.

One of the obvious issues is that it is well and good using predefined data, which you can download, in zipped form, from OSS (such as the IDES data I used in this example). What about copying ‘real’ data fron an existing SAP system, especially if we’re talking TerraBytes ?

I’ll discuss this, the bandwidth of a portable hard disk and more of the Amazon Web Services features that are particularly useful for SAP in my next post.

UPDATE: I have tidied this up a bit, to make some things clearer and to include the name of an AWS Public Image that can be used as the source for the subsequent step.

In this post, I describe how I setup a windows environment to install SAP ABAP and Java stacks, using the Amazon Simple Storage Service (S3) to store persistent data.  I needed to:
* install and modify an appropriate Windows 2003 Server environment,
* save this environment for future use

In a subsequent post, I will describe the installation of an IDES system running NW7 and DB2.  The three major challenges were
* setting up persistent storage of the NW and DB2 installation,
* suitable for using standard SAP and AWS functionality to support sustained (i.e. 24×7) operation of the SAP system
* and allowing you to stop and start the SAP system and / or server without losss of persistent data.

The result is a fast and cheap way of running up multiple systems, with the following features:

* You are only charged running costs for those systems that are running
* Low running costs (at the time of writing, $US 50 cents an hour)
* Low storage costs ($US 15 cents / GB / month for your 50TB)
* No more waiting for hardware – you can start implementation right now
* Systems (i.e. extra application servers) can be implemented, but not running

What did I know I would need ?

After reading the NW 70 SR3 installation Guide for Windows / DB2, I knew the following:
* I needed a 64 bit Windows Server with authentication services,
* I needed a reasonable amount of RAM, plus a decent swap space,
* I needed JAVA 1.4.

After reading the AWS EC2 documentation, I also knew that it was not practical to keep any volatile datasets (i.e. DB2 itself, DB2 logs, SAP process logs, etc) as part of the server, and that I would need to use the Amazon EBS servcie for persistent storage.

Signing up for Amazon EC2 and S3

An excellent account of how to setup a Windows Server image, and the principles behind this, can be found at Dave Winer’s EC2 for Poets. It also gives a good overview of how to sign up for both EC2 and S3 and the issues around persistent data.

Creating the base Amazon Machine Image (AMI)

Logon to the AWS Management Console and select the Amazon EC2 tab.

Select the Launch Instance button…

.. then find and select the Basic 64-bit Microsoft Windows Server 2003 with Authentication Services image.

 Once the server shows up as running, logon using the techniques described in Dave Winer’s EC2 for Poets.  One of the first things I did was to create a sapinstall user.  This allows me to logon (via RDP) as user sapinstall / password without having to muck around with the keypairs. 

Changes to standard AWS Windows 2003 64-bit Image

There were five issues that needed to be dealt with.

First I had to disable the Windows Attachment Manager (for non-windows people, this is a security setting that Windows uses to stop you writing dangerous file types to your disk) before Internet Explorer would let me save files.  See the Microsoft Knowledge Base Article 883260 for a rundown on how it works.  The quickest way to disable it is to uninstall the Internet Explorer Enhanced Security Configuration. To do this, click Add or remove programs in Control Panel, click Add/Remove Windows Components, and then click to clear the Internet Explorer Enhanced Security Configuration check box.

2) Both SAP and DB/2 (my target DBMS) require that the host name of the server its installed and running on remains the same.  However, the default action every time you restart an AWS image is to have the host name set to IP-xxxxxx where xxxxxx represents the internal (to Amazon) host name the server is running on.

While you can perform arcane scripting to fix the host name, Amazon provide a tool, bundled within every AWS windows instance, that will ensure the hostname remains set to what ever you set in the System –&gt; properties screen.   The tool is C:\Program Files (x86)\Amazon\Ec2ConfigSetup\Ec2ConfigServiceSettings.exe

3) I wanted to make sure I had enough swap spacxe to run my SAP system.  The base instance we are using gives us 15GB of memory, but, especially if we want to install multiple JAVA engines, this may not be enough.  I allocated another 1500MB on each of two of the ephemeral disks.

4) My initial installation is going to be an NetWeaver 7 ECC6 system. This means we need to download and install java 1.4 from Sun’s Sekrit Squirrell place for old releases.  Don’t forget to setup the Environment variables (JAVA_HOME and PATH) correctly. 

5) The last change was to incorporate a Dynamic DNS Update tool.  This is used to pass the IP address of the server we are “running on” to a service that will then set a fixed Domain name to specify the same DNS name to users and tools whenever I ran my instance.  I use dyndns org.  You can register a limited number of domain names for free, and they provide a tool (DynDNS Updater) that allows you to register your IP address against one or more of your Domain names.

Save your Amazon Machine Image (AMI)

Now you have an instance you can use to install and run SAP on.  However, we need to make sure that all our changes are not lost.  This utdown means you need to “bundle” your running system into a standalone Amazon Machine Image.  Go to the Amazoin EC2 tab of the Amazon Management Console, select Instances, then select the instance you want bundled.  Right click on More Actions and select Bundle Windows AMI.

This generates a popup screen.  Fill out the appropriate details and clcik bundle. The Bundle Name refers to the S3 folder that will hold the AMI.  This must already exist.  The Key Name is appended to the name of manifest.xml filre that contains the S3 layout and location of your image.

 Once you click bundle your request is confirmed.

.

You can follow the progresss of the bundling by examining the Bundle Tasks screen.  There are three steps that bundling Windows instances needs to follow- The instance must shutdown, the Amazon bundling process must occur, and the resulting data must be stored.

Once the image has been bundled and stored, you must register the bundle as an Amazon machine Image.

An alternative to repeating all the work shown above is to grab a copy of the Public AMI I have created, called sap.nw70.win-64.db2.  You will need to change the hostname (as descibed above), implement your own DynDNS org domain name  and bundle and register the changed image.

Either way, you now have your own mildly customised image copy of a Windows 2003 Server, running on the  Amazon Web Services cloud.  This image is ready for installation of a non-trivial SAP system, such as the NW7 ECC6 IDES system.  

In the next post, I will describe how I used the sap.nw70.win-64.db2 image to install the Windows DB2 IDES for ECC6 system.

For any SAP install except the Trial Editions available from SDN (and Solution Manager itself), you need to obtain a Installation/Upgrade Key (sometimes known as the ‘magic number’) from a Solution Manager system.  Usually, you should get this from the Solution Manager system that will be used for managing changes, software diagnostics etc for you installation.  However, note that you do not have to use any particular Solution Manager system, to get the the installation up and running.

Procedure

On the SAP Solution Manager System :

1. Call the System Landscape Maintenance (transaction SMSY) in your Solution Manager system.

2. Create your SAP System in the system landschape:

a. Select the landscape component Systems, and choose Create New System, in the context menu.

b. Enter the system ID as the system, in the following dialog box.

c. Choose the product (i.e. SAP ECC), and the product version (i.e. SAP ECC 5.0 or higher), from the possible entries help, and Save.

d. Complete the system data, as far as possible.

e. Save your entries.

3. Generate the key:

a. Choose System Landscape ® Other Object….

b. Set the System flag, and choose the system which is to be installed or upgraded, from the possible entries help. If you have created a system in the SAP Solution Manager, in the previous step, choose it.

c. Choose Generate Installation/Upgrade Key.

d. Enter the required data and choose Generate Key.

The system displays the key.

Installation/upgrade tool

Specify this key in the installation or upgrade tool when requested.  This is (usually) the last step of the ‘Check Parameters phase’, immediately prior to the start of the ‘Execute Service’ phase.

UPDATE:
Please do not request that I supply Installation keys.

They are available from sap.com/solutions/netweaver/minisap.asp (for the trial and developer editions) and service.sap.com/LICENSEKEY.