AutoScaling commands : new universal CLI

Here is an example of creating an auto scaling group using the new CLI:

aws autoscaling create-launch-configuration --launch-configuration-name NiravTestASconfig --image-id ami-35792c5c --security-groups NiravTestSecGrp --instance-type t1.micro --key-name niravkothariaws

aws autoscaling create-auto-scaling-group --auto-scaling-group-name NiravTestASGrp --launch-configuration-name NiravTestASconfig --min-size 2 --max-size 4 --default-cooldown 300 --load-balancer-names NiravTestELB --tags Key=Name,Value=CreatedBYAS --availability-zones us-east-1c --termination-policies NewestInstance

ADDARN=`aws autoscaling put-scaling-policy --auto-scaling-group-name NiravTestASGrp --policy-name NiravTestADDPolicy --scaling-adjustment +1 --adjustment-type ChangeInCapacity --cooldown 300 | grep -i "PolicyARN" | awk '{print $2}' | sed 's/"//g’`

DELARN=`aws autoscaling put-scaling-policy --auto-scaling-group-name NiravTestASGrp --policy-name NiravTestDELPolicy --scaling-adjustment -1 --adjustment-type ChangeInCapacity --cooldown 300 | grep -i "PolicyARN" | awk '{print $2}' | sed 's/"//g'`

echo ARN for scale-up policy $ADDARN

echo ARN for scale-down policy $DELARN

aws autoscaling put-notification-configuration --auto-scaling-group-name NiravTestASGrp --topic-arn arn:aws:sns:us-east-1:228152208343:niravtestsns --notification-types autoscaling:EC2_INSTANCE_LAUNCH autoscaling:EC2_INSTANCE_TERMINATE

sleep 10s

On premise mapped to AWS

A question that often comes up when companies are migrating Oracle workloads to AWS is: "How do my on premise IT architecture components map to AWS?".  Here are some of the most common components mapping from on premise to AWS:

Understanding auto scaling policy and CloudWatch alarms

Taking a look at an example auto scaling policy you can see that there is nothing to indicate when to scale up or down:

as-put-scaling-policy reachforce-scale-in-policy --auto-scaling-group reachforce-as-grp --adjustment=20 --type PercentChangeInCapacity

ARM - arn:aws:autoscaling:us-west-2:649163059618:scalingPolicy:d9a6780b-3319-4b00-98f1-e98dcfc68d82:autoScalingGroupName/reachforce-as-grp:policyName/reachforce-scale-in-policy

This policy does specify the "how"; scale 20% (adjustment) for a percentage change in capacity (how much you will scale up or down as a percentage of current capacity).

This is controlled using a CloudWatch metrics alarm.  

mon-put-metric-alarm --alarm-name AddCapacity --metric-name CPUUtilization --namespace "AWS/EC2" --statistic "Average" --evaluation-periods 6 --period 120 --threshold 80 --comparison-operator GreaterThanOrEqualToThreshold --dimensions "AutoScalingGroupName=reachforce-as-grp"  --alarm-actions arn:aws:autoscaling:us-west-2:649163059618:scalingPolicy:69270ce4-3350-48f4-9d6f-71bc64225554:autoScalingGroupName/reachforce-as-grp:policyName/reachforce-scale-out-policy

This command ties a cloudwatch metrics to the auto scaling policy above.  The parameters that define the what and when are:
1. What : -metric-name CPUUtilization -- : CPU utilization is the most common metric used.  You also see the threshold of 80% for the CPU utilization.  So, when the CPU is on average over 80%.
2. When: Controlled by the evaluation periods, period and threshold:
A. Evaluation periods : The number of times to check if the alarm metric has been meet before triggering the alarm/policy.
B. Period : Is the length of time to check the alarm metric (in this case CPU utilization).  This value is in seconds.  So, in this case for 2 minutes.

If you look in the AWS CloudWatch console, you see this metrics threshold defined as:
the value is  80 for 12 minutes. This is because you specified 120 seconds for the periods
and 6 for the number of periods.
You also specify evaluation periods and period on the scale down alarm so you don't get constant
scaling up and down of the auto scaling group.

Running web application on AWS

In most cases, you will not just be running just an Oracle database on AWS.  You will be running a web based application.  For Oracle focused developers and engineers, running web applications on AWS is not an area of expertise. Here are the best documents, documentation, and diagrams to review for developing web based applications on AWS:

http://media.amazonwebservices.com/architecturecenter/AWS_ac_ra_web_01.pdf

http://media.amazonwebservices.com/AWS_Web_Hosting_Best_Practices.pdf

http://docs.aws.amazon.com/gettingstarted/latest/wah-linux/web-app-hosting-intro.html

Support for session state and database failover when application server goes down are a couple of details that most Oracle folks ask about.  Information can be found here:

Session state: Good blog post here: http://harish11g.blogspot.com/2012/10/web-session-synchronization-aws-ec2.html . The last option is DynamoDB which is the method used most often.

Database failover:

1. Using RDS this is automatic: When automatic failover occurs, your application can remain unaware of what's happening behind the scenes. The CNAME record for your DB instance will be altered to point to the newly promoted standby. Your client library must be able to close and reopen the connection in the event of a failover.
2. Using Oracle on EC2 : You would use Elastic Ips and use this pattern : http://aws.amazon.com/articles/2127188135977316 . You cloud use ENIs so private Ips could be used http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#create-a-low-budget-high-availability-solution

Auto Scaling based upon schedule

Sometime you may have nightly, monthly, year end, or periodic (calendar based) schedules where you would like to scale out your AWS infrastructure.  Here is more information on schedule based auto scaling:
http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/schedule_time.html

Auto Scaling Script

Auto Scaling with VPC 

This example uses the CLI version 1.0.61.2 (API 2011-01-01).  There is now a newer version of the CLI.

Overall notes:

1. Create an image (aka: gold image) that has a health check on it that consists of a simple static HTML page such as a ping.html or an index.html. 

2. The ELB (need an ELB before creating Auto Scaling group) hat has the instances running from your gold image AMI created in step 1. Could potentially (nothing is preventing you from doing) create a auto scale launch configuration (step 6 in process below) with an AMI that is different, with a different instance type as instance type is another parameter of your launch configuration, than the instance that will be part of your auto scaling group.  Both are possible but most will have the same AMI (gold image, so you know you have a health check) and the same instance type.

3. Before you create the ELB you should have instances running of the  gold image to make sure the ELB is working properly.  To provide true HA, make sure to put the instances in two AZs. (for example: us-west-2a, us-west-2b)

4. When creating elb that is using subnets, limitation on ELB is that only one subnet per AZ is allowed.  

5. When creating autoscaling group (as-create-auto-scaling-group)

 need to make sure to specific the VPC subnets and AZs.  The VPC subnets need to be in the AZs specified in the AZ parameter for command.

Steps:

Prework:

1. Identify the VPC : For example, VPC: vpc-9b120cf2

2. Add subnets : In this case, using two public subnets. I had to create the second one (subnet) which was private by default and I had to add an igw to make it public.

3. Subnets -

            A. Subnet: subnet-9f120cf6

            CIDR: 10.0.0.0/24   VPC: vpc-9b120cf2   Availability Zone: us-west-2a

            B. Subnet: subnet-8c130de5

            CIDR: 10.0.5.0/24   VPC: vpc-9b120cf2   Availability Zone: us-west-2b

4. Luanch two instances from AMI that has Apache installed with ping.html (or some other file) as a health check. One instance in subnet A and the other in subnet B. 

5. Create an ELB with the two instances across subnets.  ELB is healthy with two instances running in two AZs in two different public subnets. Limitation on ELB is that one subnet per AZ. 

6. Auto Scaling:

A. as-create-launch-config vpcautoscaling-as-lc --image-id ami-dcd344ec --instance-type t1.micro --key AutoScalingKey

B. as-create-auto-scaling-group vpcautoscaling-as-grp --launch-configuration vpcautoscaling-as-lc  --min-size 4 --max-size 12 --load-balancers VpcautoscalingAutoScalingELB --vpc-zone-identifier subnet-9f120cf6,subnet-8c130de5 --availability-zones us-west-2a,us-west-2b

C. as-describe-auto-scaling-groups --headers

output of command:

INSTANCE  INSTANCE-ID  AVAILABILITY-ZONE  STATE      STATUS   LAUNCH-CONFIG

INSTANCE  i-3af6e708   us-west-2b         InService  Healthy  vpcautoscaling-as-lc

INSTANCE  i-3cf6e70e   us-west-2a         InService  Healthy  vpcautoscaling-as-lc

INSTANCE  i-3ef6e70c   us-west-2a         InService  Healthy  vpcautoscaling-as-lc

INSTANCE  i-38f6e70a   us-west-2b         InService  Healthy  vpcautoscaling-as-lc

D. as-put-scaling-policy vpcautoscaling-scale-out-policy --auto-scaling-group vpcautoscaling-as-grp --adjustment=30 --type PercentChangeInCapacity

ARN: arn:aws:autoscaling:us-west-2:649163059618:scalingPolicy:69270ce4-3350-48f4-9d6f-71bc64225554:autoScalingGroupName/vpcautoscaling-as-grp:policyName/vpcautoscaling-scale-out-policy

E.  as-put-scaling-policy vpcautoscaling-scale-in-policy --auto-scaling-group vpcautoscaling-as-grp --adjustment=1 --type PercentChangeInCapacity

ARM - arn:aws:autoscaling:us-west-2:649163059618:scalingPolicy:d9a6780b-3319-4b00-98f1-e98dcfc68d82:autoScalingGroupName/vpcautoscaling-as-grp:policyName/vpcautoscaling-scale-in-policy

F. mon-put-metric-alarm --alarm-name AddCapacity --metric-name CPUUtilization --namespace "AWS/EC2" --statistic "Average" --evaluation-periods 6 --period 120 --threshold 80 --comparison-operator GreaterThanOrEqualToThreshold --dimensions "AutoScalingGroupName=vpcautoscaling-as-grp"  --alarm-actions arn:aws:autoscaling:us-west-2:649163059618:scalingPolicy:69270ce4-3350-48f4-9d6f-71bc64225554:autoScalingGroupName/vpcautoscaling-as-grp:policyName/vpcautoscaling-scale-out-policy

G. mon-put-metric-alarm --alarm-name RemoveCapacity --metric-name CPUUtilization --namespace "AWS/EC2" --statistic "Average" --evaluation-periods 2 --period 120 --threshold 40 --comparison-operator LessThanOrEqualToThreshold --dimensions "AutoScalingGroupName=vpcautoscaling-as-grp"  --alarm-actions arn:aws:autoscaling:us-west-2:649163059618:scalingPolicy:d9a6780b-3319-4b00-98f1-e98dcfc68d82:autoScalingGroupName/vpcautoscaling-as-grp:policyName/vpcautoscaling-scale-in-policy

H. as-describe-policies --auto-scaling-group vpcautoscaling-as-grp —headers

AWS Auto Scaling for batch processing

Can I use Auto Scaling for scaling out a set of servers that run periodically (auto scaling of zero) ?  This is not the typical auto scaling use case but it is possible.  This would most likely be used for use cases such as batch processing where instances would be spun up to support processing that happens periodically.  Here are some ways to solve this use case:

• Auto Scaling, SQS and CloudWatch : You can but it would require to use AWS SQS with Auto Scaling and you would set up an alarm that uses SQS instead of CloudWatch or a custom metrics.  See more here:
  http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/as-using-sqs-queue.html
  It is possible to set up an auto scaling group with min EC2 size of ):
  http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/US_BasicSetup.html. You can issue this command: as-create-auto-scaling-group my-test-asg --launch-configuration my-test-lc --availability-zones us-east-1a --min-size 0 --max-size 10 --desired-capacity 1
• OpsWorks : OpsWorks provides a graphical tool for scheduling time-based auto scaling (e.g. “start an instance every Monday at 8:00am and shut it down at 5:00p.m.”).
• Auto Scaling and Cron : The auto scaling API supports a cron-style "recurrence" attribute for scheduled actions:
  
  
  http://docs.aws.amazon.com/AutoScaling/latest/APIReference/API_PutScheduledUpdateGroupAction.html

Horizontal Scaling of Oracle on AWS

Just came across this solution.
Parelastic: http://www.parelastic.com (MySQL only at this time)

I really enjoyed the 'sharding sucks' mantra.  Being an 'old school' Oracle guy, the new world answer to  database scaling is sharding...I think that is very naive.

I know of these two companies in this space as well:

Scalearc (MySQL and SQL Server)

Scalebase : http://www.scalebase.com (MySQL only at this time)