{"id":1628,"date":"2016-08-15T10:30:08","date_gmt":"2016-08-15T09:30:08","guid":{"rendered":"http:\/\/www.tekhead.org\/blog\/?p=1628"},"modified":"2016-10-11T10:59:57","modified_gmt":"2016-10-11T09:59:57","slug":"amazon-aws-tips-and-gotchas-part-7","status":"publish","type":"post","link":"http:\/\/tekhead.it\/blog\/2016\/08\/amazon-aws-tips-and-gotchas-part-7\/","title":{"rendered":"Amazon AWS Tips and Gotchas – Part 7 – AWS EMR, Spot Instances & PGs"},"content":{"rendered":"

Continuing in this series of blog posts taking a bit of a \u201cwarts and all\u201d view of a few Amazon AWS features, below are a handful more tips and gotchas when designing and implementing solutions on Amazon AWS, including EMR, Spot Instances and Placement Groups.<\/p>\n

For the first post in this series with a bit of background on where it all originated from, see here:
\nAmazon #AWS Tips and Gotchas \u2013 Part 1<\/a><\/p>\n

For more posts in this series, see here:
\nIndex of AWS Tips and Gotchas<\/a><\/p>\n

AWS Tips and Gotchas \u2013 Part 7<\/b><\/span><\/h4>\n
    \n
  1. As detailed in the EMR FAQ<\/a>, EMR does not support multi-master config, only one master node per EMR cluster (plus of course, multiple slaves). If that master node goes offline, you lose your cluster and all data which is being processed at the time. The AWS recommended workaround for this is to checkpoint your EMR cluster regularly, which allows resuming of the cluster from the last checkpoint\u00a0in the event of a failure.\u00a0\"AWS<\/a><\/li>\n
  2. Spot instances and sticky sessions do not play well together!!! If you use spot instances as a method for providing cheap burst resources, make sure your application is not dependent on sticky sessions.
    \nIf it is, you risk losing user sessions when the spot instances are terminated with only     2 minutes notice<\/a>.
    \nThere are a couple of\u00a0mitigation methods for this, the best of which is simply to not use sticky sessions, and store your session data in another system such as ElastiCache or DynamoDB (or both!).
    \nAlternatively, you could setup a script within the EC2 guest OS to monitor the Spot Instance Termination Notifications (    http:\/\/169.254.169.254\/latest\/meta-data\/spot\/termination-time<\/a>) and devise a\u00a0method to cleanly migrate off any remaining sessions from your instance and remove it from the load balancer.
    \nNOTE: It is best to avoid terminating your spot instances yourself, as AWS will not charge you for the hour in which they terminate your\u00a0instance, so you can save some budget\u00a0over shutting your own instances down.<\/em><\/em><\/li>\n
  3. Placement groups were designed specifically for high bandwidth applications, which require low latency, 10Gbps connectivity between instances.
    \n    \"AWS<\/a>If you do not start all instances in a placement group at the same time, you cannot guarantee that they will end up optimally close to each other later. Indeed, as stated in the placement groups KB “If you try to add more instances to the placement group later, or if you try to launch more than one instance type in the placement group, you increase your chances of getting an insufficient capacity error”.
    \nIf you do want to add more instances to your placement group later, the best thing to do is stop and restart all of your instances concurrently.<\/li>\n<\/ol>\n

    Find\u00a0more posts in this series here:
    \n    Index of AWS Tips and Gotchas<\/a><\/p>\n

    Amazon AWS Tips and Gotchas \u2013 Part 8 \u2013 AWS EC2 Reserved Instances<\/a><\/p><\/blockquote>\n