Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Cluster configuration prerequisites

Create an Amazon CLI profile on both Amazon EC2 instances

The cluster resource agents use the Amazon CLI. The Amazon CLI profile will be created for the root account on both instances. You can either edit the config file manually at /root/.aws, or use the aws configure cli command.

It is not necessary to provide an Amazon Access Key and a Secret Access Key. The permissions will be provided through the IAM roles that are attached to the Amazon EC2 instances.

For RHEL and SLES

# aws configure
AWS Access Key ID [None]:
AWS Secret Access Key [None]:
Default region name [None]: xxxxxxx
Default output format [None]:

Only for SLES

The profile name is arbitrary. In the following example, it is cluster. The Amazon Region of the instance also needs to be added.

# aws configure –profile cluster
AWS Access Key ID [None]:
AWS Secret Access Key [None]:
Default region name [None]: xxxxxxx
Default output format [None]:    

Note: Update the Region with appropriate values.

Hostname resolution

Ensure that both systems can resolve the hostnames of both cluster nodes without problems. If there are DNS issues, add the hostnames of both cluster nodes to /etc/hosts, as depicted in the following example.

# cat /etc/hosts
10.0.0.1 hahost01.example.com hahost01
10.0.0.2 hahost02.example.com hahost02

Disable the source/destination check

Each Amazon EC2 instance performs source/destination checks by default. This means that the instance must be the source or destination of any traffic it sends or receives. For cluster instances, source/destination check must be disabled on the Amazon EC2 instances that are supposed to receive traffic from the Overlay IP address. You can use the Amazon CLI or Amazon Management Console to disable the source/destination check. For details, see the ec2 modify-instance-attribute documentation.

Amazon roles and policies

The Amazon EC2 instances run the SLES and RHEL cluster software and its resource agents. To perform failover activities, these resource agents need to access Amazon resources. They require specific Amazon IAM permissions.

Create a new IAM role and associate it to the two Amazon EC2 instances that are a part of the cluster. Attach the following IAM policies to this IAM role:

Create the STONITH policy

Both instances of the cluster need the permission to start and stop other nodes in the cluster. Create a policy as shown in the following example and attach it to the IAM role assigned to both cluster instances.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances",
                "ec2:DescribeTags"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances",
                "ec2:StopInstances"
            ],
            "Resource": [
                "arn:aws:ec2:<Region-name>:<account-id>:instance/<instance-id>",
                "arn:aws:ec2: <Region-name>:<account-id>:instance/<instance-id>"
            ]
        }
    ]
}
        

Note: replace Region name, account-id, and instance-id with appropriate values.

Create an Overlay IP agent policy

Amazon VPC setup includes the assignment of subnets to your primary/secondary nodes for the SAP NetWeaver database. Each of these configured subnets has a classless inter-domain routing (CIDR) IP assignment from the VPC, which resides entirely within one Availability Zone. This CIDR IP assignment cannot span multiple zones or be reassigned to the secondary instance in a different Availability Zone during a failover scenario. Therefore, Amazon enables you to configure the Overlay IP outside of your Amazon VPC CIDR block, to access the active SAP instance. With the overlay routing, you can allow the Amazon network to use a non-overlapping RFC1918 private IP address that resides outside a VPC CIDR range. You can also direct the SAP traffic to any instance setup across the Availability Zone within the VPC, by changing the routing entry in Amazon using the SLES/RHEL Overlay IP agent.

For the SLES/RHEL Overlay IP agent to change a routing entry in Amazon routing tables, create the following policy and attach it to the IAM role that's assigned to both cluster instances.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ec2:ReplaceRoute",
            "Resource": [
"arn:aws:ec2:<Region>:<account-id>:route-table/<route table identifier 1>",
"arn:aws:ec2:<Region>:<account-id>:route-table/<route table identifier 2>”
]
        },
        {
            "Effect": "Allow",
            "Action": "ec2:DescribeRouteTables",
            "Resource": "*"
        }
    ]
}
        

Note: replace Region name, account-id, and route table identifiers with the appropriate values.

Update routing tables

Add a routing entry to the routing tables that are assigned to the subnets of your ASCS and ERS instances. The IP address is the virtual IP (overlay IP) address of the cluster, which needs to be outside the CIDR range of the Amazon VPC. To modify or add a route to a route table using the Amazon Web Services Management Console, follow these steps:

Note: add the overlay IP address for both ASCS and ERS services.

Overlay IP address in route table

Enable cluster instances to use the overlay IP address

The overlay IP address must be configured as a secondary IP address on the standard interface eth0 of the two cluster instances. This is a temporary addition and the assignment will be lost if a reboot is performed prior to the cluster being in place. When the setup is complete, the cluster will control the assignment. This can be achieved by using the following commands.

On Node 1

# ip addr add x.x.x.x/32 dev eth0

On Node 2

# ip addr add x.x.x.x/32 dev eth0

Note: update the overlay IP addresses with appropriate values.

You must have root permissions on both instances when using these commands. Add the ASCS overlay IP address on the ASCS node. Add the Enqueue replication server overlay IP on its node.

Tagging the Amazon EC2 instances (required only for SLES)

In SLES, the Amazon EC2 STONITH agent uses the Amazon resource tags to identify the Amazon EC2 instances. Create a tag for the primary and secondary Amazon EC2 instances by using the Amazon Web Services Management Console or the Amazon CLI. Use the same tag key and respective hostnames as values for both Amazon EC2 instances.

In the following example, the user has chosen pacemaker as the hostname, as shown in the uname -n command.

Tagging the ASCS/ERS node 1 Amazon EC2 instance

Tagging the ASCS/ERS node 2 Amazon EC2 instance