Back when the first announcement was made that HANA would be available on AWS, a bunch of developers flocked to the SAP HANA Development Center and installed SAP HANA using the great write-up from Juergen Schmerder “Get your own SAP HANA One, developer edition on Amazon Web Services” at http://scn.sap.com/docs/DOC-28294. Unfortunately, the next day – boom – many of us couldn’t access our AWS HANA instances because parts of the Amazon data center in NorthVirginia were down.
Lesson 1: Consider using two instances in different data centers if you what your development team to be productive. Fortunately for me, our dev team used an SVN source code repository for the database scripts and we had a copy of our data CSV files that we could use to install onto a new instance in Oregon. In the process, we stumbled on the fact that you need a new key-value-pair if you are going to a different data center. To save costs, you only need your backup instance running when you perform your restore operation. You can stop it when you are done with the restore. You’ll need to use SFTP file transfer plug in for the Amazon SSH client to copy the backup files to your remote instance.
Lesson 2: Learn how to do backup and restore operations as soon as you create your first database and load it with some data. The “Backup and Recovery Guide – SAP In-Memory Database” – http://www.saphana.com/docs/DOC-1078 document us the first think you’ll want to read up on.Creating a backup is easy with SAP HANA Studio – see page 18 to get started. Recovery of the database is a little tricky – but it’s something you will want your team to practice using the guide. I recommend using in instance on another AWS data center for practice so that you can test out things like making sure you have the right key value pair files available, having your hosts file configured, etc.
Lesson 3: Know your environment so that you can best react to a disk failure. Your HANA instance on AWS uses EBS storage – http://aws.amazon.com/ebs/. When I initially looked at the EBS volumes for the HANA instance, I saw 7 blocks, 1 10 GB block used for the root (OS & HANA software), and 6 20 GB blocks used for the rest. I was thinking nice SAP was thinking about disaster recovery here – but that’s not the case. Issuing the df -l Linux command showed that the /dev/md0 device was a full 120GB. Following up with the mdadm –detail /dev/md0 Linux command revealed that the 6 drives are configured for RAID 0. This is great for performance as you can multiple the IOPS by 6, but it also means that if one of the drives goes down, the entire system won’t boot. AWS does have “mirrored” storage but beware of events like “Great Reddit Fail of 2011” – http://news.cnet.com/8301-30685_3-20056029-264.html. To learn more about alternative configurations like using RAID1+0, see http://blog.9minutesnooze.com/raid-10-ebs-data.
For a dev environment, using the default configuration is likely to be very safe, it wouldn’t hurt to create a new storage device for your backup files and another for your log files. This would be similar to the configuration you get with a HANA appliance. The good news is that the “production” version of SAP HANA One does use a separate storage drive for backup, but it doesn’t have separate storage for the log.
A little bit of understanding of your environment can go a long way to having a productive dev environment and prepare you for disaster recovery now and for when you decide to go into production with AWS.
Please let me know what you think about this article.
Bill Ramos, Data Architect at Advaiya