Ravindra BagaleCourses & study guides मराठी Track your progress

Chapter 17: Scaling

17.11 Every Auto Scaling policy

Desired is one number. A policy is who may change it. Every example uses minimum 1, maximum 3, starting at desired 1. This lab uses simple scaling: add 1 on cpu-high-lab, remove 1 on cpu-low-lab, cooldown 300 seconds. The others are here so you can tell them apart.

Manual. Why: you are at the console. What: you type desired.

  1. Open scale-lab-asg.
  2. At 18:00 set desired from 1 to 2.
  3. You should see one new instance launch.
  4. At 19:00 set desired from 2 to 1.
  5. You should see one instance terminate.
  6. If you are asleep, none of these lines run. Desired stays where you left it.

Simple scaling (the lab). Why: one alarm, one fixed add. What: it runs when the alarm enters ALARM, then waits out a cooldown.

  1. Create policy add-one-on-cpu.
  2. Choose type Simple scaling.
  3. Choose add 1 when cpu-high-lab is in ALARM.
  4. Set cooldown to 300 seconds.
  5. When the averages are 82 then 91, you should see desired go from 1 to 2.
  6. You should not see a third instance just because the alarm stays in ALARM.
  7. Create remove-one-on-cpu the same way, removing 1 when CPU is at or under 30 for two periods.
  8. You should see desired return toward 1. The OK email does not do that step.

Step scaling. Why: a continued breach should add another server. What: bands past 70, plus a warm-up.

  1. Create a policy of type Step scaling.
  2. If CPU is above 70, add 1.
  3. Set warm-up to 300 seconds.
  4. On CPU 78, you should see desired go from 1 to 2.
  5. After warm-up, if CPU is still 91, you should see desired go from 2 to 3.
  6. You should not see desired become 4, because maximum is 3.
  7. This is not the policy the lab buttons use. The lab uses simple scaling.

Target tracking. Why: you care about the level. What: keep average CPU near 50.

  1. Create a policy of type Target tracking.
  2. Choose average CPU utilization.
  3. Set the target to 50.
  4. With one server at 90, you should see the group add capacity.
  5. With two servers near 45, you should see it stop adding.
  6. Near 20, it may remove one, and minimum 1 should block 0.
  7. Do not enable this in the lab, or CloudWatch hides the alarm you built.

Scheduled scaling. Why: the rush is on a clock. What: set desired at a time.

  1. Create a scheduled action.
  2. Set the time zone to Asia/Kolkata.
  3. At 08:50 set desired to 2, before a 09:00 class.
  4. At 21:00 set desired to 1.
  5. You should see the extra server leave at night.
  6. A reel at 01:00 is not on this schedule. Keep a dynamic policy for that.

Predictive scaling. Why: a repeating peak should be ready before users arrive. What: a forecast from past load.

  1. Leave predictive scaling off for this lab.
  2. Read a forecast only after the group has history.
  3. If dinner is busy every evening, the forecast can raise desired before 19:00.
  4. A brand-new sale is not in that history. The alarm still has to catch it.

Lab

Chala, six lines in the notebook.

  1. Manual: at 18:00 desired becomes 2. At 19:00 it becomes 1.
  2. Simple: 82 then 91, desired 1 to 2. Underline this row. The lab uses it.
  3. Step: still above 70 after warm-up, desired 2 to 3. Maximum stops 4.
  4. Target tracking: aim at 50% CPU.
  5. Scheduled: 08:50 desired 2, 21:00 desired 1, time zone Asia/Kolkata.
  6. Predictive: only if past evenings show the peak. It misses a brand-new rush.