AWS EBS required for HANA ?

[Former Member]

Hello,

I have started the SAP HANA Development training on OpenSAP and I am going to request an AWS HANA instance.

When I check the document from Jurgen Schmerder on the different options (http://scn.sap.com/docs/DOC-31722) and the detailed how-to guide for Amazon (http://scn.sap.com/docs/DOC-28294) it recommends using the m2.xlarge or the m2.2xlarge, but it does not make any reference to EBS.

My question is: do we need EBS for a minimal HANA instance ?

I don't plan to load big amounts of data.

Any experience from fellow AWS users is welcome !

Thanks in advance,

Pedro

[former_member182779 · Accepted solution]

For the initial configuration you need EBS but that's done automatically...and we provide enough so you don't need to buy more...

Greetings,

Blag.

[henrique_pinto]

Just follow video4 in week1, e.g. go through the HANA Development Center AWS setup button.

Even though it uses EBS underneath, I didn't have to worry about it.

The only things it doesn't show is how to create an AWS account (duh) and a keypair (though it's also very simple - as simple as clicking on "create key pair" and adding a name for it ).

Cheers,

Henrique.

[Former Member]

Hi Henrique,

   I have to chuckle at the famous last words - you don't have to worry about it (EBS).

For Pedro,

    The EBS storage is configured automatically for you. But, it's useful to know how it's configured for HANA operations. Like any good configuration the database files, log files, and backup files are all located on separate mounted devices. When you configure HANA One for the labs, you will notice 13 EBS volumes are created for you, but the df command in Linux shows you something like this:

hanaserver:~ # df -h                                                           

Filesystem            Size  Used Avail Use% Mounted on

/dev/hda1             9.9G  3.0G  6.5G  32% /

devtmpfs               30G  152K   30G   1% /dev

tmpfs                  30G     0   30G   0% /dev/shm

/dev/md0              119G  4.5G  108G   4% /hanalog

/dev/md1              197G   13G  175G   7% /hanadata

/dev/md2              197G  1.6G  186G   1% /backup

/dev/xvdj              30G   11G   18G  37% /usr/sap

/dev/xvdt             5.0G  1.3G  3.5G  28% /hci

This is because the /hanalog (four EBS volumes), /hanadata (four EBS volumes) and /backup (two volumes) devices use a RAID0 configuration to get more performance out of the devices. Basically, one EBS drive gives you 100 IOPS. If you tie four drives together, you can get up to 400 IOPS performance. This is a good thing for the /hanalog device as it used four. Having four drives for the /hanadata helps startup performance, but not much after data is loaded from disk into memory. Having the /backup drive with only two drives makes sense as this is not a common occurrence. 

So, depending on your workload requirements, how HANA One configures it's drives can have a big impact. For purposes of the training - no problem. If you have to support very fast inserts, then having a really fast log drive needs to be a consideration as a transaction in memory must also be written to the log for durability.

The other thing you have to realize is what happens if a drive fails. With a traditional RAID0 configuration, if one drive goes down, the entire device is down - unlike other RAID configurations like RAID5. The good news is that AWS "mirrors" the EBS drives for you so you are getting what looks like RAID10 without the performance hit. The bad news is - there have been tragic instances where the AWS sysadmin as turned off the replication and a bad drive took down huge chunks of the AWS data center as a result of a cascading disk failure. I'm guessing since the last time this has happened, there is a big sign on the console that tells the system admin.

If you are using HANA One for a production environment, consider advice from people who have been there and done that like David - http://davidralbrecht.com/blog/tag/aws/ and Bruce@AWS - http://aws.amazon.com/articles/1074.

Regards,

Bill

[henrique_pinto]

I meant from an user perspective.

Not all people creating AWS HANA instances are system admins, you know...

BTW, he was talking about the HANA Developer Edition, not HANA One.

[Former Member]

Hi Henrique,

   I know . WRT to system admins, it's always good to know what operating environment you are working under so that you can deal with failure - which is evitable with cloud hardware. Amazon runs their hardware hard to maximize their investment.

   Related to Developer Edition, if I recall the data, log and backup files are all on the same device. This is a disaster waiting to happen. I understand the need to control expenses with the EBS storage, but even developers would be better off with separate non-raid0 drives for the data, log, and backup files. I remember when one of our devs overloaded the one drive with data files for importing and didn't realize what happened - ie - a disk full error - that crashed the server. In order to boot the server, we had to clean out the import files. Makes sense in retrospect and sometimes you need to pay attention to the alerts that HANA Studio displays.   This is why I wrote a few blogs posts last year on:

1. http://scn.sap.com/community/developer-center/hana/blog/2012/11/25/protect-your-aws-hana-dev-environ...
2. http://scn.sap.com/community/developer-center/hana/blog/2012/12/03/handling-the-disk-full-error--or-...
3. http://scn.sap.com/community/developer-center/hana/blog/2013/01/01/linux-challenged-no-problem--chec...

Cheers,

Bill

[Former Member]

Hi Bill,

Your comments about separating logs and data volumes make a lot of sense, even for the developer edition. However, most users we asked expressed the view that cost was their primary concern.

A bit odd, but factual... This is also the reason we kept the EBS allocation to a bare minimum, and I had a few "out of disk space" situations myself, especially with out-of-control log backups...

I will suggest to change the disk layout for the bigger (34GB and 68GB) instance sizes, while keeping it to an absolute minimum for the cheapest m2.xlarge...

cheers

--juergen

[Former Member]

Hi Juergen,

   Thanks for looking out for your dev community. At least you have a starting point. I'm getting ready to put together a blog post on how to mount a new EBS drive and use it for a log drive. Also, I recently used the Google s3fs bits - http://s3fs.googlecode.com/files/s3fs-1.67.tar.gz to mount an S3 device to a Linux instance do that it could be used for a cheaper backup drive - yet another blog post in the works.

Regards,

Bill