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 24x7.

 

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 24x7. 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.

I've created four volumes, corresponding to the Drive Letteres I gave in the Architechture section above.

• 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.

Note that I am creating an x.large instance in the availability zone US-east-1b. I need the x.large instance to provide enough RAM and Swap Space for an IDES ECC6 system, and I'm starting it in the US-east-1b availability zone because thats where I located my volumes (no particular reason).

 

Once the instance is running, we can attach our volumes via the Attach Volume Button.

The result is that our volumes are now "physically" attached to our instance. Again, these are empty unformatted unmounted volumes.

Now we need to logon to this instance. If you are running an instance of sap.nw70.win-64.db2, you can logon as user sapinstall, password sap123. Use the Remote Desktop Connection, and specify the public dns name from your instance. 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.

Note the relationship between the volumes and Drive letters in the image below compared to the description of each volume given in the Architecture description above.

 

 

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.

Do not forget to change the password of the sapinstall user. Otherwise, anyone who reads this will know the password. 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.

You do need to have an S3 Bucket (or directory) to store the Image in.

However, you can store multiple images in the same bucket, by varying the Amzon S3 Key Name.

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.

Since SAP communicates via TCP/IP, we need to make sure that our instance(s) can be accessed via the ports used by SAP for its various services. This means we need to add the ABAP and Java ports for both our instance and the diagnostic instance.

Remember that the Windows Server underlying your new SAP system is on the Internet, and is accessible (by Design !!) from anywhere else on the internet, so only open the bare minimum of ports.

 

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.

Once it is bundled, register the bundle as an instance.

You can share this with anyone with an EC2 account, by using Permissions to mark it Public, or you can share with individuals if you know their EC2 Account number. Note - Bundling a windows instance restarts the 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 SAP System

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.

Regardless of the previous paragraph, restart the image using Start --> Shutdown -> Restart. With all Drives correctly assigned, and sufficient Swap Space assigned the DB2 and SAP Services for SAP MMC will start. Go into SAP MMC and start your SAP instance. Once SAP is running, you can disconnect from the instance.

 

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 .....

.....and access the ABAP Engine.

Again assuming you have opened the correct ports in the Security Group specified for this instance, you can go into the SMICM transaction and enable a simple service, then access it via a browser or web service.

 

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.

It has been my experience, based on several green fields implementations, individual system implementations and upgrades, and feedback from others, that getting a server - whether physical or virtual - installed and configured, ready to install SAP, in a traditional Data centre can take weeks. 

• Hardware has to be ordered,
• It has to be delivered,
• It has to be connected to the Data Centre powersupply
• It has to be connected to the Data Centre Networks
• and so on and so on...

 

By comparison, the time to set up an AWS system ready to install SAP on is very short.  Without stopping for taking notes, screenshots and the like, I would suggest aproximately 45 minutes to produce sap.nw70.win-64.db2 from the standard images supplied by Amazon.

 

Questions Answers and Ruminations

One of the more 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.