Going from theory to delivery AWS style
Up to now all the work I have done has been theoretical, with the view to deployment at some point in the future.
Well as some wise person said, “The future starts here”, and so in November I was asked to deploy an SAP landscape in the AWS cloud for a client blueprint project.
I was given 6 days to deploy the following landscape
An ECC 6.0 system with CRM Best practices,
A Portal 7 system,
A CRM 7 system with CRM Best practices,
A Solution Manager system,
A BI system.
A challenge to be sure, but one I was keen to complete in order to prove the skills I had built up over the course of my adventures in the Cloud.
System Builds – Planning
In order to provide the systems in the shortest time possible I ran the installations in parallel, which takes a bit more planning in order to get the installation parameters decided from the outset
During the original POC with SAP I built an excel spreadsheet in order to keep track of the SAP Instances, the Elastic IP and the storage volumes used by each system.
SAP Instance Worksheet
Disk Config Worksheet
Elastic IP sheet
Of course you do not have to follow what I have done, for me this method works, although I can see why in a distributed team this is open to serious error.
I think that something like a Google Document or a simple web application which provides the same details in a multi-user setting.
As you can see above, I was able to plan out several of the key details before starting.
I could define the SID, the DNS name and the the disk volumes then fill in the AWS provided parameters, like Instance name and Volume name.
System Builds – Installation
So once the planning was done, it was time to get my hands dirty and crack on with the installations 🙂
I chose a public AMI – Windows 2003 Server 64bit, since I was unable to use any of the AMI’s from the SAP POC as they are on a different account I had to begin form stratch.
Which was a very good test of the theory I had laid down in the previous blogs.
So using the previous blog Creating the AMI, preparing for the SAP install, I created the AMI and prepared it for the SAP install.
- Change the system name;
- Create the page files;
- Create administration users;
- Create the disk volumes and assign to particular drive letters.
Once the AMI is prepared the SAP installation is executed in the normal way.
System Builds – Securing the SAP System
The previous blog regarding security was based on using the system for a POC, now security is vital and needs careful consideration as if there is ANY customer data on the system then the company providing the AWS service is liable.
In order to use an SAP system several ports need to be opened
- SAP Dialog Port – 32xx
- SAP Gateway Port – 33xx
- SAP Message Server Port – 36xx
- SAP Portal Port – 5xx00
The requirements for access to this environment are
- Accessible from the client site – reasonably easy to provide as there is a single/range of IP addresses that can be added for access.
- Accessible from Capgemini India – reasonably easy to provide as there is a single/range of IP addresses that can be added for access.
- Accessible from Public Internet – this is the problem, consultants with 3g cards using dynamic IP addresses
As result it becomes necessary to use a ‘choke point’ to reduce the number IP addresses to be granted access.
How to do this is open to debate, obvious possibilities are
- Corporate VPNs
- Internet gateways
- Software VPNs
So more work is needed to be completed in order to work out the Pros and Cons of each method.
SAP Password security is also vital – if there are ports open to the Internet the last line of defence of the system is the strength of it’s passwords.
There are specific SAP parameters to enforce password security, but these should be implemented in line with corporate policy with a risk based view on the public internet facing aspects of the systems.
I will not give away my favourite method of constructing passwords so that they are both memorable but only breakable using brute force methods.
These is a massive gotcha in the provision of the RDP service on Windows systems – never ever ever open the RDP port to the internet.
If does not matter if you have 20 IP addresses that you use to access the RDP port, but the RDP port is something that will be abused if you open it up.
At the minute I only have it opened to two static IP addresses in order to protect the servers.
Post Installation tasks
At this point I have been working on the Installation for about 12 hours and have completed the base installations and initial security setup.
In order to complete the installation and have the system ready the following 3 tasks need to be completed
- Reconfigure the Database logging parameters and setup backups;
- Perform a client copy to create the development client;
- Perform a system generation.
I found that the disk to CPU performance could be faster, and it is noticable when performing an SGEN.
But to be fair, there are worse things in life and until I see more people on the system I do not know if it will adversely affect performance on a regular basis.
These tasks were completed within10 hours, so the systems were delivered ready for use (without additional software) within 22 hours.
So now I have been able to deliver a system landscape in the cloud that is now being used to provide a Blueprint system in a time that is utterly amazing.
The system so far has been stable and the performance has been excellent.