2. EC2 instance creation

former_member395922 · ‎2018 Jul 04

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:

Prior knowledge

EC2 instance creation

EC2 instance configuration

SAP HANA installation for the master

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:

https://d1.awsstatic.com/enterprise-marketing/SAP/SAP-HANA-on-AWS-Manual-Setup-Guide.pdf

All scripts from https://github.com/aws-quickstart/quickstart-sap-hana

https://docs.aws.amazon.com/quickstart/latest/sap-hana/welcome.html

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

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:

Root file system will be 100 GB or so (“/dev/sda1” is used for “/” file system by default).

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.

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.

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

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

Hands-on: Configure SAP HANA on AWS - part2

2. EC2 instance creation

2.1. Planning subnet

2.1.1. Find your VPC CIDR

2.1.2. Create your subnet

2.2. Choose an AMI

2.3. Choose an EC2 instance type

2.4. Configure instance details

2.5. Prepare block device mappings

2.6. Configure security groups

2.7. Create key pair

2.8. Create placement group

2.9. Add tags

2.10. Launch EC2 instance

2.11. Elastic IP address

Get Your SAP HANA Idea Incubator Badge Today!

SCN Mission - SAP HANA Quiz Challenge is now retired

Share your #HANAStory and Win