Rocket Steam Elastic SAP

Transcription

1 Rocket Steam Elastic SAP For SAP ABAP systems running on Linux platforms using Oracle as their RDBMS Release information Release Independent release that can work both on systems launched through the Rocket Steam SAP Formation tool or previously existent systems. Excerpt This document goal is to provide the technical steps required to set up ElasticSAP in a currently existing SAP system. Elastic SAP makes posible for SAP systems to enjoy the possibilities of AWS Autoscaling framework. Elastic SAP has been tested with the following versions of SAP: - Business Suite: o ERP 6 EHP 6 o ERP 6 EHP 7 o CRM o SRM - Netweaver suite o 7.0+ o 7.2+ o 7.3+ o 7.4+ The target audience for this document is the system/devops team responsible of the implementation and maintenance of SAP systems in the Amazon Web Services cloud. To understand the requirements of Elastic SAP the reader must have a deep knowledge of: - SAP Basis - Linux (RHEL6) - Amazon Web Services (especially the Cloud Watch, IAM and EC2 services) - Oracle 11g

2 Subscribe to the public AMI Please go to the AWS MarketPlace and subscribe to the Elastic SAP AMI before performing any configuration task: Region US East (N. Virginia) US West (Oregon) US West (N. California) EU (Ireland) Asia Pacific (Singapore) Asia Pacific (Sydney) Asia Pacific (Tokyo) South America (Sao Paulo) ID ami- 5a174f32 ami- 5f6a496f ami- 9536d2d1 ami- e953c39e ami- 6086b132 ami ami- 01ce2001 ami- b57cc5a8

3 Preparation of your AWS- based SAP for Elastic SAP On the following pages you will find the steps needed to prepare your SAP system so you can use Elastic SAP. NFS shares Since you will be deploying new application servers for your SAP system, the NFS shares under /sapmnt/sid must be available for the new EC2 instances in the autoscale group. To achieve this, ensure that your Central Instance server exports /sapmnt/sid and /usr/sap/trans to the network segment where the EC2 instances will be deployed. The next example shows a /etc/exports file that shares the specified resources to the network /24: sapprd01:~ # cat /etc/exports /sapmnt/prd /24(rw,no_root_squash,sync,no_subtree_check) /usr/sap/trans /24(rw,no_root_squash,sync,no_subtree_check) Transport the Elastic SAP functions and Roles Download the transport from the following link site and import it into the SAP system where you wish to implement Elastic SAP. eu- west- 1.amazonaws.com/rocket- steam- tools/elasticsap/linux/oracle/abapesap.tar.gz You must ignore the component versions when importing to ensure the completion of the transport import. User in client 000 Rocket Steam Elastic SAP requires a user in the SAP system that will be used to issue the remote calls used to: - start the new server - un/register the instances from/into the specified logon group(s) - un/register the instances from/into the specified rfc group(s) - shutdown the server As this user does not need to access any private data, it should be created into client 000. You can use the following role for this new user: ZAWS, it only allows the user to call the needed RFC functions. Take note of the password, as you ll need it when you setup the auto scale group.

4 NAT instance Elastic SAP checks at boot time for newer versions, to do that the network where the auto scale group is defined needs to have access to the internet. If the update process cannot reach the Internet, the Elastic SAP software won t launch. Template profile Elastic SAP needs a template profile that will be adapted when launching a new instance. You can either create a copy of the instance/start profile you want to use as a template or use one of your existing profiles, the only condition is that the name of the files keep the standard syntax: - For instance profile: SID_Dxx_hostname - For start profile: START_Dxx_hostname Whenever a new auto scale instance gets started, this profile will be copied and adapted with the settings retrieved from the rocket steam API. Keep the name of the template profiles in hand for the settings you will need to use in the end.

5 Parameters for your RDBMS Oracle RDBMS needs to be adapted in order to allow the growth of instances in your landscape. You need to be especially careful with the PROCESSES and SESSIONS parameters. The following table provides the amount of additional PROCESSES and SESSIONS needed per possible instance, depending on the EC2 instance type that you will use: DB instance type AutoScale Instance type Increase of PROCESSES Increase of SESSIONS M3.2xlarge M3.2xlarge M3.4xlarge R3.8xlarge M3.4xlarge M3.2xlarge M3.4xlarge R3.8xlarge R3.8xlarge M3.2xlarge M3.4xlarge R3.8xlarge For example, if you have a DB instance in a r3.8xlarge and you setup an auto scale group with a maximum of 10 M2.2xlarge instances, you ll have to add: to your current PROCESSES parameter to your current SESSIONS parameter Package for /usr/sap/sid/d00 In order to provide the AutoScale Group instances with the SAP Kernel and instance filesystems, you need to create a package. If you just have a /usr/sap/sid/dvbemgsxx or a /usr/sap/sid/dxx, it s ok. Just copy the DVEBMGSxx/Dxx directory into D00 and follow the next procedure to create the package (run as root) # cd / # tar zcvf /usr/sap/trans/d00_sid.tgz /usr/sap/sid/d00 /usr/sap/sid/sys For instance, if your system name were PRD the command would be: # cd / # tar zcvf /usr/sap/trans/d00_prd.tgz /usr/sap/prd/d00 /usr/sap/prd/sys Services file To ensure that the Elastic SAP servers can access all the systems of your defined RFCs, ensure that an updated copy of the /etc/services is copied to /usr/sap/trans as well

6 Name resolution You need to put the entries for the already existing application servers in /usr/sap/trans/hostnames_existent if you want your autoscaled servers to be able to communicate with your already existing appservers. Our recommendation in any case is to stop your old appservers once you get the autoscale group working. An example of /usr/sap/trans/hostnames_existent file: #already existing hosts in PRD landscape sapprd sapprd sapprd sapprd sapprd sapprd dbciprd If /usr/sap/trans/hostnames_existent does not exist, the setup and startup of Elastic SAP will work normally, but name resolution won t work. Rocket- Steam ElasticSAP also assigns autogenerated hostnames to the EC2 instances created in the AutoScale group. To ensure that all the nodes in the SAP landscape can access the ElasticSAP servers, we provide the setuphosts tool, which must be run on all the systems (it basically generates all possible hostnames and add them to /etc/hosts) You can download and run this tool as follow in each EC2 that may need to access the EC2 instances generated by ElasticSAP (example for SID DEV): # wget # chmod +x setuphosts #./setuphosts -s DEV

7 Create an IAM role for your ElasticSAP pool Elastic SAP needs to monitor the status of your servers through Cloud Watch in order to integrate with AWS Auto scaling functions. It also needs to be able to modify certain parameters of its auto scaling group. For this to work you need to create an IAM Role with the following policy paper to work (please note that you may restrict it to the specific Cloud Watch alerts created for the auto scale group if you want) { "Version": " ", "Statement": [ { "Sid": "Stmt ", "Effect": "Allow", "Action": [ "autoscaling:describe*", "cloudwatch:describe*", "cloudwatch:list*", "cloudwatch:get*" "autoscaling:setdesiredcapacity", "autoscaling:terminateinstanceinautoscalinggroup" ], "Resource": [ "* ] } ] } For instance, we will use the role name AutoScaleSapPRD

8 Create your auto- scale group for SAP First of all, you ll need a system with the command line interface tools for AWS properly setup. You can find all the documentation about this in: chap- getting- set- up.html Once you have the CLI tools installed and working, you can proceed with the following steps: 1. Create the rocket- steam user data configuration This file will contain the configuration to be used by the EC2 instances in the Auto Scale group. This configuration will allow the instance to: a) Mount the NFS shares for trans and sapmnt b) Initialize the instance c) Start SAP d) Register into the specified logon groups and RFC groups The syntax of the file follows: [rocket-steam] RS_SID=<SID_of_the_system> RS_SIDADM=<sidadm user> RS_ADMUID=<sidadm UID> RS_ADMGID=<sapsys GID> RS_CI_SERVER=<IP_ci_server> RS_DB_SERVER=<IP_db_server> RS_LOGON_GROUPS=<comma separated list of logon groups> RS_RFC_GROUPS=<comma separated list of RFC groups> RS_USER=<user in client 000> RS_PASSWORD=<password for RS_USER> RS_TEMPLATE_DI=<name of the template for instance profile> RS_TEMPLATE_ST=<name of the template for start profile> RS_ASG_NAME = <name of the AutoScaling Group> RS_TZ= <timezone> Description of each parameter: o RS_SID - > SID of the system, for instance, PRD o RS_SIDADM - > sidadm user (ex: prdadm) o RS_ADMUID - > uid of sidadm user (ex: 6000) o RS_ADMGID - > gid of sapsys group (ex: 200) o RS_CI_SERVER - > ip of the CI server. CI server runs the ASCS system and hosts/shares the /sapmnt and /usr/sap/trans server via NFS o RS_DB_SERVER - > ip of the DB server o RS_CI_HOSTNAME - > hostname of the CI server as stated in your DEFAULT.PFL o RS_DB_HOSTNAME - > hostname of the DB server as stated in your DEFAULT.PFL

9 o RS_LOGON_GROUPS - > list of all the logon groups where the instance has to be registered at startup, separated by comma, for instance: PUBLIC,ACCOUNTING,SYSTEMS o RS_RFC_GROUPS - > list of all the RFC groups where the instance has to be registered at startup, separated by comma o RS_USER - > The username we created in client 000 o RS_PASSWORD - > the password of the user created in client 000 o RS_TEMPLATE_DI - > name of the instance profile you ll use as a template o RS_TEMPLATE_ST - > name of the start profile you ll use as a template, should you have a 7.30 system without start profile, set this parameter to FALSE o RS_ASG_NAME - > name of the autoscaling group o RS_TZ - > timezone of your system File example: [rocket-steam] RS_SID=PRD RS_SIDADM=prdadm RS_ADMUID=6000 RS_ADMGID=200 RS_CI_SERVER= RS_DB_SERVER= RS_CI_HOSTNAME=sapprd RS_DB_HOSTNAME=dbciprd RS_LOGON_GROUPS=PUBLIC,ACCOUNTING RS_RFC_GROUPS=PUBLIC,ACCOUNTING RS_USER=rsuser RS_PASSWORD=0xawi38q80ai0q s RS_TEMPLATE_DI=PRD_D00_sapprd04 RS_TEMPLATE_ST=START_D00_sapprd04 RS_ASG_NAME=SAPPRD-Autoscale-1a RS_TZ=US/Eastern 2. Create the auto scaling group Suppose that you created the user- data.txt file with the content shown above, and that you want to create an auto- scale group that ranges from 2 to 8 EC2 instances of m2.2xlarge size. The following command would allow you to do that: [user@yoursystem ~]$ aws autoscaling create-launch-configuration --launchconfiguration-name SAPPRD-Autoscale-1a --image-id ami-484fed3f --instance-type m2.2xlarge --user-data file://user-data.txt --key-name your_key_name --securitygroups sg-your-group-id --iam-instance-profile AutoScaleSapPRD [user@yoursystem ~]$ aws autoscaling create-auto-scaling-group --auto-scaling-groupname SAPPRD-Autoscale-1a --launch-configuration-name SAPPRD-Autoscale-1a --min-size 1 --max-size 4 --vpc-zone-identifier subnet-a40dfac1 --tags Key=Name,Value=sapprdappserver_as,PropagateAtLaunch=1

10 Now we need to define how we will scale out (increase the number of appservers) and scale in (decrease the number of appservers). Take note of the policies ARN (marked in green) ~]$ aws autoscaling put-scaling-policy --auto-scaling-group-name SAPPRD-Autoscale-1a --policy-name SAPPRD-asgUP-policy --scaling-adjustment 1 -- adjustment-type ChangeInCapacity --cooldown 300 { "PolicyARN": "arn:aws:autoscaling:eu-west-1: :scalingpolicy:c58f99fb- 735d-4233-a782-88ae9df750fe:autoScalingGroupName/SAPPRD-Autoscale- 1a:policyName/SAPPRD-asgUP-policy" } Which means that when the autoscale up function gets triggered, it will startup a new EC2 instance and it will wait 5 minutes until checking if another instance is needed. [user@yoursystem ~]$ aws autoscaling put-scaling-policy --auto-scaling-group-name SAPPRD-Autoscale-1a --policy-name SAPPRD-asgDOWN-policy --scaling-adjustment adjustment-type ChangeInCapacity --cooldown 300 { "PolicyARN": "arn:aws:autoscaling:eu-west-1: :scalingpolicy:d6f010d4-6bc0-4ed5-829e-1d6257c31838:autoscalinggroupname/sapprd-autoscale- 1a:policyName/SAPPRD-asgDOWN-policy" } Now we need to setup the AutoScale triggers, which can be defined by any cloudwatch metric. Also For upscale via CPU: [user@machine ~]$ aws cloudwatch put-metric-alarm --alarm-name AddCapacitySAPPRD -- metric-name CPUUtilization --namespace "AWS/EC2" --statistic Average --period threshold 70 --comparison-operator GreaterThanOrEqualToThreshold --dimensions "Name=AutoScalingGroupName,Value=SAPPRD-Autoscale-1a" --evaluation-periods 2 -- alarm-actions "arn:aws:autoscaling:eu-west-1: :scalingpolicy:9e2090c9- af2b-48d5-bb23-9cdcbf317090:autoscalinggroupname/sapprd-autoscaleasg:policyname/sapprd-asgup-policy" For downscale via CPU, we must create an alert with the name SAP<SID>TerminateAppserver_ASGNAME, for PRD, the example would be: [user@machine ~]$ aws cloudwatch put-metric-alarm --alarm-name SAPPRDTerminateAppserver_SAPPRD-Autoscale-1a --metric-name CPUUtilization -- namespace "AWS/EC2" --statistic Average --period threshold comparison-operator LessThanOrEqualToThreshold --dimensions "Name=AutoScalingGroupName,Value=SAPPRD-Autoscale-1a" --evaluation-periods 2

11 Notes on Elastic SAP About SSFS SSFS is mandatory for SAP kernel releases from Elastic SAP automatically sets up its environment for SSFS if the following file exists: /usr/sap/dev/sys/global/security/rsecssfs/data /usr/sap/dev/sys/global/security/rsecssfs/key Should you store those files in a different path, contact us.