Skip to Content

 Introduction

We will go through step by step hands-on scenario to build virtual appliance for SAP HANA on AWS in this hands-on. It includes how to install SAP HANA on AWS and we will go through the steps required to install and configure SAP HANA on AWS. I hope the information contained in this hands-on provide you basic idea about what AWS services are and how to configure SAP HANA on AWS environment.

 

The hands-on is composed of following posts:

  1. Prior knowledge
  2. EC2 instance creation
  3. EC2 instance configuration
  4. SAP HANA installation for the master
  5. Adding worker to SAP HANA landscape.

This post handles the second part of the hands-on.

We will try most steps in command line (awscli) but you should know that all tasks in this hands-on could be done on AWS console too.

2. EC2 instance creation

We will create a EC2 instance where SAP HANA instance will live. This chapter is highly referring to below links:

We have to prepare some information before going to create new EC2 instance. That’s explained through the next few sections.

2.1. Planning subnet

We will define new subnet (or we can use existing subnet too) for new EC2 instances.

2.1.1. Find your VPC CIDR

Subnet will be created in VPC (or you can use the existing subnet). You can find the current VPC information (VpcId and CidrBlock) with below command:

yourLinux:~ # aws ec2 describe-vpcs
{
    "Vpcs": [
        {
            "VpcId": "vpc-b49ab4dc",
            "InstanceTenancy": "default",
            "CidrBlockAssociationSet": [
                {
                    "AssociationId": "vpc-cidr-assoc-c3d368ab",
                    "CidrBlock": "172.31.0.0/16",
                    "CidrBlockState": {
                        "State": "associated"
                    }
                }
            ],
            "State": "available",
            "DhcpOptionsId": "dopt-960819fe",
            "CidrBlock": "172.31.0.0/16",
            "IsDefault": true
        }
    ]
}
 
Information Value
VpcId vpc-b49ab4dc
CidrBlock of Vpc 172.31.0.0/16

2.1.2. Create your subnet

For this task, we have to choose the correct availability zone in the current region first. We can find usable availability zones within the region:

yourLinux:~ # aws ec2 describe-availability-zones --region ap-northeast-2
{
    "AvailabilityZones": [
        {
            "State": "available",
            "ZoneName": "ap-northeast-2a",
            "Messages": [],
            "RegionName": "ap-northeast-2"
        },
        {
            "State": "available",
            "ZoneName": "ap-northeast-2c",
            "Messages": [],
            "RegionName": "ap-northeast-2"
        }
    ]
}

You can choose any name among a couple of availability zone names displayed, for example, ap-northeast-2c in this hands-on.

Information Value
Region name ap-northeast-2
Availability zone ap-northeast-2c

We will create a subnet by splitting CidrBlock of VpcId. It’s done by adding more bits to VPC CIDR and specifying different network IP address. In this example, I add just one more bit to VPC CIDR block to create a new subnet. That is, VPC CIDR is 172.31.0.0/16 (10101100. 00011111.), and I will use 172.31.128.0/17 (10101100. 00011111.1) for new subnet.

yourLinux:~ # aws ec2 create-subnet --vpc-id vpc-b49ab4dc --cidr-block 172.31.128.0/17 --availability-zone ap-northeast-2c
{
    "Subnet": {
        "AvailabilityZone": "ap-northeast-2c",
        "AvailableIpAddressCount": 32763,
        "DefaultForAz": false,
        "Ipv6CidrBlockAssociationSet": [],
        "VpcId": "vpc-b49ab4dc",
        "State": "pending",
        "MapPublicIpOnLaunch": false,
        "SubnetId": "subnet-0ec93994701de0193",
        "CidrBlock": "172.31.128.0/17",
        "AssignIpv6AddressOnCreation": false
    }
}

You need to check if the new subnet becomes available with “aws ec2 describe-subnets” command.

yourLinux:~ # aws ec2 describe-subnets
{
    "Subnet": {
        "AvailabilityZone": "ap-northeast-2c",
        "AvailableIpAddressCount": 32763,
        "DefaultForAz": false,
        "Ipv6CidrBlockAssociationSet": [],
        "VpcId": "vpc-b49ab4dc",
        "State": "available",
        "MapPublicIpOnLaunch": false,
        "SubnetId": "subnet-0ec93994701de0193",
        "CidrBlock": "172.31.128.0/17",
        "AssignIpv6AddressOnCreation": false
    }
}

You will find SubnetId and CidrBlock in the output.

Information Value
SubnetId subnet-0ec93994701de0193
Cidr Block for SubnetId 172.31.128.0/17

Now, you get to know where EC2 instance will be located, which VPC, which Availability Zone and which subnet in VPC.

Once subnet is decided, you can define EC2 instance’s private IP address within the subnet. For example, 172.31.128.21/17.

Information Value
Private IP address 172.31.128.21/17

Memo.

How many IP addresses are available for 172.31.128.0/17 ?

  • Last 15 bits will be used for Host IP address, that is, 32767 (7FFF) IP addresses.
  • One IP address, 171.31.255.255, is reserved for broadcast IP address).
  • Another three IP addresses (172.31.128.1, 172.31.128.2, 172.31.128.3) are reserved for AWS use.
  • That is, 32767 -4 = 32763 IP addresses are available.

2.2. Choose an AMI

Next, we will choose Amazon Machine Image (AMI) to be used for our EC2 instance.

Code for naming convenience Name ImageId
SLES11SP4HVM suse-sles-11-sp4-v20180104-hvm-ssd-x86_64 ami-afc565c1
SLES12SP1HVM suse-sles-12-sp1-v20161021-hvm-ssd-x86_64 ami-1ced3972
SLES12SP2HVM suse-sles-12-sp2-v20170620-hvm-ssd-x86_64 ami-86d00fe8
SLES12SP3HVM suse-sles-12-sp3-v20180215-hvm-ssd-x86_64 ami-e22b898c
SLES12SP1SAPHVM suse-sles-sap-12-sp2-v20180215-hvm-ssd-x86_64-e3458d64-5c36-4577-bd98-0ee19e3eaeec-ami-4cd6c836.4 ami-5f993e31
SLES12SP2SAPHVM suse-sles-sap-12-sp2-v20180215-hvm-ssd-x86_64-e3458d64-5c36-4577-bd98-0ee19e3eaeec-ami-4cd6c836.4 ami-003f9d6e
SLES12SP3SAPHVM suse-sles-sap-12-sp3-v20180215-hvm-ssd-x86_64-da7aa9c3-97db-4573-89a6-7fe7348d90b0-ami-92d5cbe8.4 ami-6202a00c
SLES12SP1SAPBYOSHVM suse-sles-sap-12-sp1-byos-v20170123-hvm-ssd-x86_64 ami-b5f928db
SLES12SP2SAPBYOSHVM suse-sles-sap-12-sp2-byos-v20180215-hvm-ssd-x86_64 ami-9e2d8ff0
SLES12SP3SAPBYOSHVM suse-sles-sap-12-sp3-byos-v20180215-hvm-ssd-x86_64 ami-1433917a

The AMIs listed in above table are based on https://github.com/aws-quickstart/quickstart-sap-netweaver-abap/blob/master/templates/sap-netweaver-hana-abap.template.

AMIs from each region has different AMI ID (ImageId in above table). ImageId in this table is for “ap-northeast-2” region because this hands-on is done in the region. If you are in different region than “ap-northeast-2”, you have to find the ImageId matching to your region. You can find an ImageId with “aws ec2 describe-images ” command:

yourLinux:~ # aws ec2 describe-images --owners self amazon aws-marketplace  --filters "Name=name, Values=suse-sles-12-sp3-v20180215-hvm-ssd-x86_64"
{
    "Images": [
        {
            "VirtualizationType": "hvm",
            "Description": "SUSE Linux Enterprise Server 12 SP3 (HVM, 64-bit, SSD-Backed)",
            "Hypervisor": "xen",
            "ImageOwnerAlias": "amazon",
            "EnaSupport": true,
            "SriovNetSupport": "simple",
            "ImageId": "ami-e22b898c",
            "State": "available",
            "BlockDeviceMappings": [
                {
                    "DeviceName": "/dev/sda1",
                    "Ebs": {
                        "Encrypted": false,
                        "DeleteOnTermination": true,
                        "VolumeType": "gp2",
                        "VolumeSize": 10,
                        "SnapshotId": "snap-07d6aad627cbd5fe3"
                    }
                }
            ],
            "Architecture": "x86_64",
            "ImageLocation": "amazon/suse-sles-12-sp3-v20180215-hvm-ssd-x86_64",
            "RootDeviceType": "ebs",
            "OwnerId": "013907871322",
            "RootDeviceName": "/dev/sda1",
            "CreationDate": "2018-02-15T14:54:50.000Z",
            "Public": true,
            "ImageType": "machine",
            "Name": "suse-sles-12-sp3-v20180215-hvm-ssd-x86_64"
        }
    ]
}

We get ImageId of the AMI, which is for “suse-sles-12-sp3-v20180215-hvm-ssd-x86_64” in “ap-northeast-2” region.

Information Value
Image name suse-sles-12-sp3-v20180215-hvm-ssd-x86_64
Image Id ami-e22b898c

I will use this AMI (ami-e22b898c). All steps in this hands-on are for “suse-sles-12-sp3”. You need to find AMI in your region with the name “suse-sles-12-sp3-v20180215-hvm-ssd-x86_64”.

We can go to next steps for choosing instance type.

2.3. Choose an EC2 instance type

“Instance types” define combinations of vCPU, memory, storage, network performance (capacity). You can choose a mix of resources for your applications or databases.

Usually following instance types are considered for high-performance databases, in-memory databases and other memory intensive enterprise applications. It’s started with “x” or “r”.

Instance Type vCPU Mem (GiB)

Storage

(GB)

Networking

Performance

(Gigabit)

Physical Processor

Clock

Speed

(GHz)

x1.16xlarge 64 976 1 X 1,920 SSD 10 Intel Xeon E7-8880 v3 2.3
x1.32xlarge 128 1,952 2 X 1,920 SSD 25 Intel Xeon E7-8880 v3 2.3
x1e.xlarge 4 122 1 X 120 SSD Up to 10 Intel Xeon E7-8880 v3 2.3
x1e.2xlarge 8 244 1 X 240 SSD Up to 10 Intel Xeon E7-8880 v3 2.3
x1e.4xlarge 16 488 1 X 480 SSD Up to 10 Intel Xeon E7-8880 v3 2.3
x1e.8xlarge 32 976 1 X 960 SSD Up to 10 Intel Xeon E7-8880 v3 2.3
x1e.16xlarge 64 1,952 1 X 1,920 SSD 10 Intel Xeon E7-8880 v3 2.3
x1e.32xlarge 128 3,904 2 X 1,920 SSD 25 Intel Xeon E7-8880 v3 2.3
r4.large 2 15.25 Up to 10 Intel Xeon E5-2686 v4 2.3
r4.xlarge 4 30.5 Up to 10 Intel Xeon E5-2686 v4 2.3
r4.2xlarge 8 61 Up to 10 Intel Xeon E5-2686 v4 2.3
r4.4xlarge 16 122 Up to 10 Intel Xeon E5-2686 v4 2.3
r4.8xlarge 32 244 10 Intel Xeon E5-2686 v4 2.3
r4.16xlarge 64 488 25 Intel Xeon E5-2686 v4 2.3

Excerpt from https://aws.amazon.com/ec2/instance-types/

Memo.

Minimum 24 GB memory is required to install SAP HANA. So r4.large is NOT eligible for SAP HANA installation.

For your reference,

  • The first character means the purpose of the instance:

“t or m” : for general purpose.

“c” : for compute oriented

“r or x” : for memory optimized.

“p or g” : for accelerated computing.

“d or h or I” : for storage optimized.

  • The second character means the generation of the instance type (the higher, the newer).
  • Large, xlarge, 2xlarge, …. is the instance size. It increases double in every aspect including the capacity and price rate on demand, etc.

Memo.

You may meet an error “Client.Unsupported: The requested configuration is currently not supported”. This means the instance type is not supported in your Availability Zone.

You can check which instance types are supported in your region / availability zone with “aws ec2 describe-reserved-instances-offerings” command, for example,

# aws ec2 describe-reserved-instances-offerings --filters "Name=availability-zone,Values=ap-northeast-2c" --region ap-northeast-2

In this hands-on, I choose r4.2xlarge for simple configuration test. r4.2xlarge will provide 8 vCPUs, 61 GB memory, EBS as a storage type.

Information Value
Instance Type r4.2xlarge

2.4. Configure instance details

You need to decide more on instance details in addition to AMI and instance type:

  • “Number of Instances” means how many instances you want to create. You can specify value larger than or equal to 1. In case you want to configure scale-out landscape, you may specify 2, 3, etc. We will use 1 for “Number of Instances” in this hands-on. You can create another instance later when scale-out requirement newly comes up.
  • “Placement group”, AWS instances that exist within the same availability zone can be grouped into a placement group. Group members are able to communicate with one another in a way that provides low latency and high throughput. Placement group can be created using one of the two strategies, cluster or spread.
    • The original purpose of placement groups, being to co-locate instances to provide benefits such as low latency/high bandwidth networking, is still met by the ‘Cluster’ configuration.
    • The ‘Spread’ configuration though is a very different use case that essentially allows you to place instances far apart from each other to reduce the risk of common failures occurring on shared hardware.

Summarily, cluster strategy limits placement group to 1 Availability Zone, whereas the spread can span multiple Availability zones (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html).

We will create our own placement group so all instances are placed in it.

  • With “Shutdown behavior”, you can specify the instance behavior when OS level shutdown performs. “stop” will only stop the instance but “terminate” will make an instance unusable anymore (instance will vanish and all objects will be terminated).
  • “EBS-optimized instance” means that EBS-optimized instances deliver dedicated bandwidth to Amazon EBS, with options between 425 Mbps and 14,000 Mbps, depending on the instance type you will use. You can check below link to find if your instance is set EBS-optimized by default and what maximum bandwidth (Mbps) is: https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EBSOptimized.html
  • When “Enable termination protection” is enabled, you cannot terminate the instance until you explicitly disable this option. This is for protecting instance from being accidentally terminated.

2.5. Prepare block device mappings

We need a storage for database files and backup, etc. We will obtain the storage from EBS (Elastic Block Storage).

We will add EBSes based on a couple of factors:

  • Size estimation for database or other requirements.
  • The strategy in volume creations, eg. Stripe for performance, etc.
  • We will create one volume group for database files and backup (/hana/data, /hana/log, /hana/shared and /backup file systems). Using this volume group, we will create four logical volumes for four file systems and each logical volume will use four stripes.
  • We will create a json file (eg. /tmp/ebs.json) using the following content, which will be used for allocating and attaching EBSes to EC2 instance while launching.
yourLinux:~ # cat /tmp/ebs.json
[
{"DeviceName":"/dev/sda1","Ebs":{"VolumeSize":100,"VolumeType":"gp2","DeleteOnTermination":true}},
{"DeviceName":"/dev/sdf","Ebs":{"VolumeSize":667,"VolumeType":"gp2","DeleteOnTermination":true}},
{"DeviceName":"/dev/sdg","Ebs":{"VolumeSize":667,"VolumeType":"gp2","DeleteOnTermination":true}},
{"DeviceName":"/dev/sdh","Ebs":{"VolumeSize":667,"VolumeType":"gp2","DeleteOnTermination":true}},
{"DeviceName":"/dev/sdi","Ebs":{"VolumeSize":667,"VolumeType":"gp2","DeleteOnTermination":true}},
{"DeviceName":"/dev/sdj","Ebs":{"VolumeSize":50,"VolumeType":"gp2","DeleteOnTermination":true}},
{"DeviceName":"/dev/sdk","Ebs":{"VolumeSize":50,"VolumeType":"gp2","DeleteOnTermination":true}}
]

The above EBS configuration is under below idea:

  1. Root file system will be 100 GB or so (“/dev/sda1” is used for “/” file system by default).
  2. Database related file systems need more I/O throughput. We will create one volume group with four EBSes, total 2.6 TB. Four logical volumes will be created in this volume group for data(/hana/data), log(/hana/log), backup(/backup) and hana shared (/hana/shared) file systems. As you will see later, /hana/shared and /backup file systems will be shared between a master and a worker. This means that you don’t need to create backup(/backup) and hana shared (/hana/shared) file systems in workers.
  3. We will create a file system (“/usr/sap”) for local SAP files. It only has database configuration and executable files, libraries and a link to /hana/shared file system with not much performance requirement, so we will use single EBS for this file system.
  4. One more file system (/media) is required to keep SAP HANA installation media files. It’ll be used for installation purpose only and you are free to remove the file system and deallocate EBS once an installation is done on a master.All above considerations are dependent on your requirements. So, you may feel free to change the volume size or volume group configuration.
Information Value
Block-device-mapping file file:///tmp/ebs.json

2.6. Configure security groups

A security group is for opening TCP/UDP ports for inbound and outbound communications.

We will create a security group and permit a few ports for inbound. For outbound communications from a master and a worker, we will open all ports.

yourLinux:~ # aws ec2 create-security-group --group-name SecGrp --description "SecGrp for test" --vpc-id vpc-b49ab4dc
{
    "GroupId": "sg-07d8b7d9bc71e0e5d"
}

 

Information Value
Security group name SecGrp
Security group Id sg-07d8b7d9bc71e0e5d

We have to configure this security group for INBOUND and OUTBOUND. Normally OUTBOUND is allowed for all ports in TCP.

<INBOUND>

Rule Type Proto

Port,

Port range(-)

Cidr Purpose
SSH TCP 22 DMZCIDR SSH, SCP
Custom UDP 111 PrivSubCIDR Ports for NFS communication
Custom TCP 1128-1129 DMZCIDR Host agent access (saphostctrl, saphostctrls)
Custom UDP 2049 PrivSubCIDR Ports for NFS communication
Custom UDP 4000-4002 PrivSubCIDR Ports for NFS communication
Custom TCP 43## DMZCIDR Access to XSEngine (HTTPS)
Custom TCP 80## DMZCIDR Access to XSEngine (HTTP)
Custom TCP 8080 DMZCIDR Software Update Manager (SUM) access(HTTP)
Custom TCP 8443 DMZCIDR Software Update Manager (SUM) access(HTTPS)
Custom TCP 3##13 DMZCIDR Database client access for System DB in MDC
Custom TCP 3##15 DMZCIDR Database client access
Custom TCP 3##17 DMZCIDR Database client access
Custom TCP 3##41-3##44 DMZCIDR Database client access for tenant DBs in MDC
Custom TCP 5##13-5##14 DMZCIDR Allow access for HANA Studio from RDP.
Custom TCP 1-65535 PrivSubCIDR Communications between the master and slave instances

*) ## means SAP HANA instance number, eg. 00

*) PrivSubCIDR is for private subnet. In this hands-on, it’s 172.31.128.0/17

*) DMZCIDR is for DMZ network. We won’t configure DMZ in this hands-on and we use “0.0.0.0/0”.

*) In case you won’t be in MDC environment, you don’t need to open 3##13, 3##41-3##44.

 

<OUTBOUND>

Rule Type Protocol Port, Port range Cidr Purpose
Custom TCP 1-65535 0.0.0.0/0 EC2 instance can connect to internet.

If you mean to configure scale-out, INBOUND and OUTBOUND settings between EC2 master and EC2 worker instances will be different because Master and Workers have different communication requirements. For example, port 2049/udp (for NFS) should be opened in Master to export file system share, but it is not necessary to open in Workers. This means that we have to create two security groups, one for a master and the other for a worker, in production environments. But we’ll share one security group for own convenience in the hands-on.

For security protection, it makes sense to open the minimum number of ports to minimize security vulnerability.

The security group is created and we need to specify ports and protocols to be opened for INBOUND and OUTBOUND rules.

yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol tcp --port 22 --cidr 0.0.0.0/0
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol udp --port 111 --cidr 172.31.128.0/17
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol tcp --port 1128-1129 --cidr 0.0.0.0/0
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol udp --port 2049 --cidr 172.31.128.0/17
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol udp --port 4000-4002 --cidr 172.31.128.0/17
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol tcp --port 4300 --cidr 0.0.0.0/0
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol tcp --port 8000 --cidr 0.0.0.0/0
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol tcp --port 8080 --cidr 0.0.0.0/0
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol tcp --port 8443 --cidr 0.0.0.0/0
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol tcp --port 30015 --cidr 0.0.0.0/0
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol tcp --port 30017 --cidr 0.0.0.0/0
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol tcp --port 30041-30044 --cidr 0.0.0.0/0
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol tcp --port 50013-50014 --cidr 0.0.0.0/0
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol tcp --port 1-65535 --cidr 172.31.128.0/17
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol tcp --port 1-65535 --cidr 172.31.128.0/17
yourLinux:~ # aws ec2 authorize-security-group-egress --group-id sg-07d8b7d9bc71e0e5d --protocol=tcp --port 1-65535 --cidr=0.0.0.0/0

 

Memo.

You may notice that two subcommands are used, authorize-security-group-ingress and authorize-security-group-egress.

You may also notice that both group-name and group-id can be used in authorize-security-group-ingress, but only group-id is used in authorize-security-group-egress.

 

You can check the security group configuration:

yourLinux:~ # aws ec2 describe-security-groups –group-names SecGrp

 

2.7. Create key pair

 

A keypair is imperatively required in accessing EC2 instance. It has an extension PEM (Privacy Enhanced Mail). Public key is kept in EC2 instance and private key is written to a keypair PEM file while keypair is created.

yourLinux:~ # aws ec2 create-key-pair --key-name KeyPair --output text > KeyPair.pem

 

Information Value
Keypair name KeyPair
Keypair PEM file KeyPair.pem

KeyPair.PEM file from above command needs a slight modification. You have to edit the file so the content looks like below. That means it should start with “—–BEGIN RSA PRIVATE KEY—–and end with —–END RSA PRIVATE KEY—–:

Eg. KeyPair.pem

-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAnCVxAiUH6u4fx8NcZMN7S0I+rcpMIyX2H+UaDBPcfPFOkmpmOyIO0jQFwGli
yob1F75szE+PtUdboKjGSCL9HzGpEl+pqIv09JqzGEW/5ogU7JVrELVT+5BffO2EGQo/RSqHVETr
VWPnukMXaV0zB9mz48IyXuxlKjiLvauFzI6H2374oXkPQk/oAQIbJJAxyMwBxa6PkOXRorQIZsMa
UTJ9DQkayV48e87/8XN6VQ8V9NpA3Hr1zZjRNuc0HdLYb6VVVSOKUz/oCE/+MGnP4MERtMfE8vzM
CrwkU22oF6W6aYOcrn/x67MrBudJVxow9r2APPeJzaQe09rqxdJlFwIDAQABAoIBAAVVpiG7oCSf
lAhgHUT4BLtSfQ+07Jr6zgjS6+vjtdGy8MtBxVJZ3IXD7zpen1hp+e+gutjUEwXPdUrs2TFXuKwb
JzqQeBxhA7JjoqC+qUq39XcLt8evWjoq+YgsGSo91mGHjW4MmLmnGyCa8C7SV076WhH67XueueoS
WnvVY1HUswHWTVc3UxmI1n6yxOT0TCNHxBkwC3sgze1eaqKeC3dw5xEo1z7Eud+xino/ebLzE4Oo
IZCqQCAalUKTsyntEAjF/QX9J4PGMrZo3Pg3Q6LiCISklMg3gNQ5iea6iG47i3utsZb9p+ZUF8nL
H3/VLlq3Ig9b9ueCMOERHI6/ZdECgYEA3+JlvqwgLqWE7LeR6WXXxcoB6pPH8IsZ3N7um/S5RnTa
EC9/RBHgYGX3prWz6lE4BJ7cXJ4xsIiO3oO+DuJ5ZtH0gDWisl/8Lut+XzGATEMmU329qaYdYXLG
dTQzgBSMB8dIMGC+J2OmbVlJysNkLNfWwv7fruSttrx3lq7q+OkCgYEAsouHT/dURI8UYeZkdtYF
7oB1UuJOXM1IHpeZD3xdgzKgoMRlFyIOiV8yrx/bAmriGviBPTh54z4Y/7dIC8cLA2oCCOuS9ywf
bDVzIrPhacI64goYAdOHXzDmdn6mEm3kytj6rYMChKxo4gzeLPITSyK7qPLbV0Ea8zWwNKm3rf8C
gYEA30ea0R44uky41Jv/GRZIqylb3+aicHNJx81Nipv2ax3+nEXCVtC9RWZsJgbw968ofvMwMe5T
AAww8BnTYmTbTn/1qCfVqq+vgdu6nJVxrp0JjBrLHHZetuEQq7Lz6biULu3AQP86pW3sfQGfZmiX
b2GS/cXSr0nBNY2gdtbb4IECgYBn7v0XubweJMQSsVEuNCxDyBeD5iUDtKQU2t7Iuvaclu4WZ/0I
2FRp9zbD5uFQqPNyC9L/1k5t0AoxYXnZEUcB98Wzd56Xr+Gi1gJt4xSGwgAQ8RtEhOQ6r3aY5+S4
uawDwQc71hWzMcHkROVYeJpulIt1L9orEsUjas9l+J3p9QKBgQCJrMhr9yfnPHQm5WtZzSVNm/zV
CZFjK/mW2TbS15RhgteE36enh4iQ+hY3sYulsoiJtoN4dkhvIu06wkr28WN3LG60weZYefm7tB2r
xSivSj6mmfjk5ZlF2ANSZVun5vNdvHyknfpyG8uvo867D/sXHj6DLnq8wWnLP0C/ehLWcg==
-----END RSA PRIVATE KEY-----

PEM file is used to connect to EC2 instance once EC2 instance is successfully launched.

Memo.

A key pair versus an access key:

  • PEM file (key pair file) is for keeping private key to connect to the specific EC2 instance.
  • Access key id and secret access key is for authenticating your account while accessing to AWS services.

Memo.

The keypair PEM file is required whenever you connect to EC2 instance. You should know where this keypair PEM file is downloaded or saved. In case it’s not in the current working directory, you have to specify the full file path on SSH command with “-i” option.

Memo.

For Windows, file redirection defaults to UTF-8 encoding, which cannot be used in some SSH clients. You must explicitly specify ASCII encoding in the out-file command(https://docs.aws.amazon.com/cli/latest/userguide/cli-ec2-keypairs.html).

 

C:\> aws ec2 create-key-pair --key-name KeyPair --output text | out-file -encoding ascii -filepath KeyPair.pem

2.8. Create placement group

You can create placement group with the following command:

yourLinux:~ # aws ec2 create-placement-group --group-name myplsgrp --strategy cluster

You can check the list of plancement groups:

yourLinux:~ # aws ec2 describe-placement-groups
Information Value
Placement group name myplsgrp
Placement group strategy cluster

2.9. Add tags

It’s an optional action to assign metadata or alias to AWS resources (eg. EC2 instance). You can simply put any tags for Instances and Volumes. We will add a tag as follows for EC2 instance to be created.

Information Value
Tag::Key Name
Tag::Value SAP HANA Master

2.10.  Launch EC2 instance

Below table contains all checkpoint information in this hands-on. We’ve gathered the information or created some AWS objects if required:

Information Value
VpcId vpc-b49ab4dc
SubnetId subnet-0ec93994701de0193
ImageId ami-e22b898c
Instance type r4.2xlarge
Tag for master EC2 instance

Key:Name

Value:SAP HANA Master

Security group name SecGrp
Security group Id sg-07d8b7d9bc71e0e5d
Keypair name keyPair
Placement group name myplsgrp
block-device-mappings file:///tmp/ebs.json

You need to run the following command to launch your EC2 instance.

yourLinux:~ # aws ec2 run-instances  \
--image-id ami-e22b898c \
--count 1 \
--instance-type r4.2xlarge \
--ebs-optimized  \
--private-ip-address 172.31.128.21 \
--key-name=KeyPair \
--security-group-ids sg-07d8b7d9bc71e0e5d \
--subnet-id subnet-0ec93994701de0193 \
--placement AvailabilityZone=ap-northeast-2c,GroupName=myplsgrp \
--instance-initiated-shutdown-behavior stop \
--block-device-mappings file:///tmp/ebs.json \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=SAP HANA Master}]'

You can refer to “2.4. Configure Instance details”  regarding the options, –count, –ebs-optimized, –instance-initiated-shutdown-behavior.

You need to keep InstanceId from the output. In my case, it’s i-0a8eb78dbab3d9353 as below, for instance.

{
    "Instances": [
        {
            "Monitoring": {
                "State": "disabled"
            },
            "PublicDnsName": "",
            "StateReason": {
                "Message": "pending",
                "Code": "pending"
            },
            "State": {
                "Code": 0,
                "Name": "pending"
            },

            "InstanceId": "i-0a8eb78dbab3d9353",
            "ImageId": "ami-e22b898c",

}
Information Value
InstanceId i-0a8eb78dbab3d9353

You can check the status of EC2 instance by the command:

yourLinux:~ # aws ec2 describe-instance-status --instance-ids i-0a8eb78dbab3d9353
{
    "InstanceStatuses": [
        {
            "InstanceId": "i-0a8eb78dbab3d9353",
            "InstanceState": {
                "Code": 16,
                "Name": "running"
            },
            "AvailabilityZone": "ap-northeast-2c",
            "SystemStatus": {
                "Status": "ok",
                "Details": [
                    {
                        "Status": "passed",
                        "Name": "reachability"
                    }
                ]
            },
            "InstanceStatus": {
                "Status": "ok",
                "Details": [
                    {
                        "Status": "passed",
                        "Name": "reachability"
                    }
                ]
            }
        }
    ]
} 

You will need to check the status while running the command several times. We say that EC2 instance are ready when “InstanceState” is “running” and both “InstanceStatus” and “SystemStatus” change to “passed”.

2.11. Elastic IP address

We can connect to the newly created EC2 instance. Once EC2 instance is created, we need public IP address of EC2 instance. We have to go through two steps to allocate a public IP address using elastic IP address.

  • Create elastic IP address.
yourLinux:~ # aws ec2 allocate-address
{
    "PublicIp": "52.78.39.220",
    "Domain": "vpc",
    "AllocationId": "eipalloc-043cfeff6c4e8c711"
}
  •  Associate elastic IP address to instance’s private IP address.
yourLinux:~ # aws ec2 associate-address --instance-id i-0a8eb78dbab3d9353 --allocation-id eipalloc-043cfeff6c4e8c711
{
    "AssociationId": "eipassoc-0c8ec2f0d5122bfa5"
}

The elastic IP address is associated to EC2 instance. Any pre-existing public IP address is replaced with this elastic IP address.

The list of elastic IP addresses can be displayed with below command:

yourLinux:~ # aws ec2 describe-addresses
{
    "Addresses": [
        {
            "Domain": "vpc",
            "InstanceId": " i-0a8eb78dbab3d9353",
            "NetworkInterfaceId": "eni-0072c65d64864c809",
            "AssociationId": " eipassoc-0c8ec2f0d5122bfa5",
            "NetworkInterfaceOwnerId": "786447197291",
            "PublicIp": "52.78.39.220",
            "AllocationId": " eipalloc-043cfeff6c4e8c711",
            "PrivateIpAddress": "172.31.128.21"
        }
    ]
}

EC2 instance has been started and we can connect to this instance by the elastic IP address, 52.78.39.220.

We’ve done in “EC2 instance creation”. We have to move forward to setup the EC2 instance (https://blogs.sap.com/2018/07/04/hands-on-configure-sap-hana-on-aws-part3/).

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply