Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Partly cloudyПостроение отказоустойчивыхсистем в AWS минимальными         средствами
Евгений Потапов10 лет опыта веб-разработки3 года опыта использованияоблачных технологийгенеральный директоркомпании «Сумма...
Поддержка высоконагруженных веб-сайтов90 миллионов уникальных посетителей в сутки113 инстансов на поддержке в Amazon AWSИс...
Построение отказоустойчивых систем в AWS минимальными средствами  Amazon Web Services с точки зрения  эксплуатации  Перехо...
Мы забываемРеальную сущность облаковНе думаем о стоимости внедренияВерим в чудо
Владельцы хотятВысокой надежностиПростой масштабируемостиПлатить за используемые ресурсы
13    новостей за суткиПоказывают яндекс.новости по запросу«Облачные вычисления»
Ложные причины перехода в AWS     Искажение реальности     Потеря доверия к текущей     хостинг-площадке
Полный переход в AWSРешение станет дорожеОтказоустойчивости по умолчанию нетПоявляются новые проблемы
Процессор: Quad Core Xeon 3450 2.66GHz w/HTОперативная память: 8GB DDR3 Registered 1333Дисковая подсистема: 4x500GB SATA H...
Процессор: High-CPU Extra LargeInstance (8 virtual cores)Оперативная память: 7 GB of memoryДисковая подсистема: EBS 1000GB...
$501       1yr upfront: $2000, Instance: $0.16 per hour       ($2000 / 12) + ($0.16*24*30) = $166.6+$115.2       EBS: 1000...
Но может быть AWS надёжнее?
Даунтайм: 53 часа (21 апреля 2011 года)Причина: нарушение маршрутизацииЗона: US EastНачало аварии: 12:47 29.04.2011Конец а...
21 апреля 2011 годаМы понимаем то значение, которое оказалоэто событие на наших клиентов,Мы хотим извиниться, и хотим сказ...
Даунтайм: 36 часов (7 августа 2011 года)Причина: отказ подстанцииЗона: EU WestНачало аварии: 10:41 07.08.2011Конец аварии:...
7 августа 2011 годаМы понимаем то значение, которое оказалоэто событие на наших клиентов,Мы хотим извиниться, и хотим сказ...
Даунтайм: 7 часов (29 июня 2012 года)Причина: отказ подстанцииЗона: US EastНачало аварии: 19:24 29.06.2012Конец аварии: 02...
29 июня 2012 годаМы извиняемся за те неудобства, котороеоказало это событие на наших клиентов…Мы проведем много часов дела...
Uptime 100%
Во всех случаях авария затронула несколькоAvailability зон в пределах одной географической                      локации
Специфика виртуализации        EBS тормозит
Специфика виртуализации Производительность EBS нестабильнаhttp://blog.scalyr.com/2012/10/16/a-systematic-look-at-ec2-io/
Специфика виртуализацииПропускная способность непропорциональна типу инстанса
Но, хорошие решения существуют
1      Гибридный бэкап             (показания к применению)    Текущий хостинг в основном    устраивает    Допустим «откат...
1      Гибридный бэкап             (особенности решения)    Сайт находится на физическом    хостинге все время, кроме авар...
1   Гибрный бэкап      (нормальный режим)
1   Гибридное облако     (авария на физической площадке)
1       Гибридный бэкап              (минусы решения)    Время простоя – время между реакцией на    падение физического хо...
1       Гибридный бэкап              (рекоммендации)    Необходимо поддерживать актуальное    состоние AMI и EBS Snapshot-...
2     Бюджетное облако             (показания к приминению)    Текущий хостинг в основном    устраивает    При failover в ...
2      Бюджетное облако            (особенности решения)    Проект находится на физическом хостинге,    но реплицируется н...
2   Бюджетное облако       (нормальный режим)
2   Бюджетное облако     (авария на физической площадке)
2        Бюджетное облако                (минусы решения)    Время простоя – время между реакцией на    падение физическог...
2       Бюджетное облако              (рекоммендации)    «Минимальная конфигурация»    должна быть способна выдержать    в...
Переход ради    масштабирования«Взять слабый инстанс иавтоматически масштабировать егопри росте нагрузок в пиковыечасы»
Переход ради   масштабированияВертикальное масштабирование:Апгрейд инстанса – 4-10 минутГоризонтальное масштабирование:Соз...
Горизонтальное3     масштабирование v.1                (применение)    Текущий хостинг всем устраивает, но    нагрузка воз...
Горизонтальное3     масштабирование v.1                (особенности решения)    Вариация «Бюджетного клауда».    Проект на...
Горизонтальное3   масштабирование v.1         (нормальный режим)
Горизонтальное3   масштабирование v.1       (рост нагрузки, синхронизация)
Горизонтальное3   масштабирование v.1         (итоговое состояние)
Горизонтальное3     масштабирование v.1                (минусы решения)    До запуска в AWS конфигурации способной    выде...
Горизонтальное3     масштабирование v.1                (рекомендации)    При использовании решений не    поддерживающих mu...
Горизонтальное4     масштабирование v.2                (применение)    Текущий хостинг всем устраивает, но    нагрузка воз...
Горизонтальное4     масштабирование v.2                (плюсы решения)    Проект целиком находится в AWS,    классический ...
Горизонтальное4   масштабирование v.1          (нормальный режим)
Горизонтальное4   масштабирование v.2          (рост нагрузки)
Специальные сервисыEC2 Spot InstancesAmazon Route 53Amazon ELBAmazon Glacier
Специальные сервисыSpot Instances:Amazon позиционирует spot instances какинструмент для cloud computingДействительно, можн...
Специальные сервисыRoute 53: сервис работает хорошо, ноamazon.com использует другие NS    amazon.com    amazon.com   names...
Специальные сервисыELB: последнее падение затронуло ELBПроекты которые полагались толькона ELB в пределах одного регионаок...
Специальные сервисыGlacier: высокая стоимостьвосстановления данных    Дешевизна и надежность архивирования    компенсирует...
Точка зренияРеально оценивайте пользу от облаковЭффективные решения находятся в областикомбинирования подходовВсегда читай...
Построение отказоустойчивых систем в AWS минимальными средствами               Евгений Потапов               http://itsumm...
Partly cloudy. Построение отказоустойчивых систем в aws минимальными средствами (Евгений Потапов)
Upcoming SlideShare
Loading in …5
×

Partly cloudy. Построение отказоустойчивых систем в aws минимальными средствами (Евгений Потапов)

1,842 views

Published on

  • Be the first to comment

Partly cloudy. Построение отказоустойчивых систем в aws минимальными средствами (Евгений Потапов)

  1. 1. Partly cloudyПостроение отказоустойчивыхсистем в AWS минимальными средствами
  2. 2. Евгений Потапов10 лет опыта веб-разработки3 года опыта использованияоблачных технологийгенеральный директоркомпании «Сумма АйТи»
  3. 3. Поддержка высоконагруженных веб-сайтов90 миллионов уникальных посетителей в сутки113 инстансов на поддержке в Amazon AWSИспользовали AWS, Softlayer Cloudlayer, Rackspace Cloud, Scalaxy
  4. 4. Построение отказоустойчивых систем в AWS минимальными средствами Amazon Web Services с точки зрения эксплуатации Переход работающих проектов Использование особенностей облака минимальными средствами
  5. 5. Мы забываемРеальную сущность облаковНе думаем о стоимости внедренияВерим в чудо
  6. 6. Владельцы хотятВысокой надежностиПростой масштабируемостиПлатить за используемые ресурсы
  7. 7. 13 новостей за суткиПоказывают яндекс.новости по запросу«Облачные вычисления»
  8. 8. Ложные причины перехода в AWS Искажение реальности Потеря доверия к текущей хостинг-площадке
  9. 9. Полный переход в AWSРешение станет дорожеОтказоустойчивости по умолчанию нетПоявляются новые проблемы
  10. 10. Процессор: Quad Core Xeon 3450 2.66GHz w/HTОперативная память: 8GB DDR3 Registered 1333Дисковая подсистема: 4x500GB SATA HDD, RAID 10Траффик: 5000 гигабайтПропускная способность: 1 гигабит
  11. 11. Процессор: High-CPU Extra LargeInstance (8 virtual cores)Оперативная память: 7 GB of memoryДисковая подсистема: EBS 1000GBТраффик: 1000 гигабайтПропускная способность: неконтролируется
  12. 12. $501 1yr upfront: $2000, Instance: $0.16 per hour ($2000 / 12) + ($0.16*24*30) = $166.6+$115.2 EBS: 1000GB = 1000 * $0.01 = $100 Траффик – 1000GB = $0.12*1000 = $120$399 $166+$115+$100+$120 = $501
  13. 13. Но может быть AWS надёжнее?
  14. 14. Даунтайм: 53 часа (21 апреля 2011 года)Причина: нарушение маршрутизацииЗона: US EastНачало аварии: 12:47 29.04.2011Конец аварии: 18:15 23.04.2011
  15. 15. 21 апреля 2011 годаМы понимаем то значение, которое оказалоэто событие на наших клиентов,Мы хотим извиниться, и хотим сказатьчто мы сделаем выводы из этогопроисшествия. http://aws.amazon.com/message/65648/
  16. 16. Даунтайм: 36 часов (7 августа 2011 года)Причина: отказ подстанцииЗона: EU WestНачало аварии: 10:41 07.08.2011Конец аварии: 20:25 08.08.2011
  17. 17. 7 августа 2011 годаМы понимаем то значение, которое оказалоэто событие на наших клиентов,Мы хотим извиниться, и хотим сказатьчто мы сделаем выводы из этогопроисшествия. http://aws.amazon.com/message/2329B7/
  18. 18. Даунтайм: 7 часов (29 июня 2012 года)Причина: отказ подстанцииЗона: US EastНачало аварии: 19:24 29.06.2012Конец аварии: 02:45 30.06.2012
  19. 19. 29 июня 2012 годаМы извиняемся за те неудобства, котороеоказало это событие на наших клиентов…Мы проведем много часов делая выводы изэтого происшествия. http://aws.amazon.com/message/2329B7/
  20. 20. Uptime 100%
  21. 21. Во всех случаях авария затронула несколькоAvailability зон в пределах одной географической локации
  22. 22. Специфика виртуализации EBS тормозит
  23. 23. Специфика виртуализации Производительность EBS нестабильнаhttp://blog.scalyr.com/2012/10/16/a-systematic-look-at-ec2-io/
  24. 24. Специфика виртуализацииПропускная способность непропорциональна типу инстанса
  25. 25. Но, хорошие решения существуют
  26. 26. 1 Гибридный бэкап (показания к применению) Текущий хостинг в основном устраивает Допустим «откат» в данных на период последнего бэкапа Бюджет минимален
  27. 27. 1 Гибридный бэкап (особенности решения) Сайт находится на физическом хостинге все время, кроме аварийных ситуаций В AWS находятся только образы подсистем проекта и регулярные бэкапы, которые поднимаются только в случае аварии
  28. 28. 1 Гибрный бэкап (нормальный режим)
  29. 29. 1 Гибридное облако (авария на физической площадке)
  30. 30. 1 Гибридный бэкап (минусы решения) Время простоя – время между реакцией на падение физического хостинга и окончательным запуском всех сервисов в AWS Данные актуальны на дату последнего бэкапа Необходимо поддерживать две разные площадки
  31. 31. 1 Гибридный бэкап (рекоммендации) Необходимо поддерживать актуальное состоние AMI и EBS Snapshot-ов Код проекта должен быть абстрагирован от текущего хостинга Стоит запланировать регулярные процедуры перехода в «резервное» облако
  32. 32. 2 Бюджетное облако (показания к приминению) Текущий хостинг в основном устраивает При failover в резервную платформу данные должны быть актуальны Бюджет чуть менее минимален 
  33. 33. 2 Бюджетное облако (особенности решения) Проект находится на физическом хостинге, но реплицируется на минимально возможную конфигурацию в Amazon Минимальная конфигурация масштабируется до необходимой в случае аварии Стоимость резервирования равна стоимости минимально выдерживающего процесс репликации инстанса
  34. 34. 2 Бюджетное облако (нормальный режим)
  35. 35. 2 Бюджетное облако (авария на физической площадке)
  36. 36. 2 Бюджетное облако (минусы решения) Время простоя – время между реакцией на падение физического хостинга и окончанием масштабирования инстанса
  37. 37. 2 Бюджетное облако (рекоммендации) «Минимальная конфигурация» должна быть способна выдержать входящий поток репликации За самим процессом репликации следует следить
  38. 38. Переход ради масштабирования«Взять слабый инстанс иавтоматически масштабировать егопри росте нагрузок в пиковыечасы»
  39. 39. Переход ради масштабированияВертикальное масштабирование:Апгрейд инстанса – 4-10 минутГоризонтальное масштабирование:Создание инстанса – 5-10 минут
  40. 40. Горизонтальное3 масштабирование v.1 (применение) Текущий хостинг всем устраивает, но нагрузка возрастает в сезонные периоды (т.е. праздники, выходные и т.д.) При появлении пиковой нагрузки можно некоторое время «потормозить» Бюджет сравним с «гибридным бэкапом»
  41. 41. Горизонтальное3 масштабирование v.1 (особенности решения) Вариация «Бюджетного клауда». Проект находится на физическом хостинге, реплика хранится в AWS При необходимости масштабирования необходимое количество инстансов запускается в AWS и синхронизируется с «минимального» инстанса.
  42. 42. Горизонтальное3 масштабирование v.1 (нормальный режим)
  43. 43. Горизонтальное3 масштабирование v.1 (рост нагрузки, синхронизация)
  44. 44. Горизонтальное3 масштабирование v.1 (итоговое состояние)
  45. 45. Горизонтальное3 масштабирование v.1 (минусы решения) До запуска в AWS конфигурации способной выдержать текущую нагрузку скорость актуальность данных будет ограничиваться пингом между площадками Если до этого горизонтальное масштабирование не использовалось - большие усилия направленные на изменения архитектуры проекта
  46. 46. Горизонтальное3 масштабирование v.1 (рекомендации) При использовании решений не поддерживающих multi-master архитектуры необходимо учитывать наличие только одной (двух) мастер-машин (либо использовать циркулярную репликацию) Очень легко масштабировать чтение, очень сложно масштабировать запись (синхронизация данных при удалении инстанса)
  47. 47. Горизонтальное4 масштабирование v.2 (применение) Текущий хостинг всем устраивает, но нагрузка возрастает в короткий промежуток времени (часы) При появлении пиковой нагрузки нет времени на синхронизацию данных – данные должны быть актуальны
  48. 48. Горизонтальное4 масштабирование v.2 (плюсы решения) Проект целиком находится в AWS, классический облачный хостинг  Минимальный пинг между отдельными компонентами системы Для резервной конфигурации расходы остаются небольшими
  49. 49. Горизонтальное4 масштабирование v.1 (нормальный режим)
  50. 50. Горизонтальное4 масштабирование v.2 (рост нагрузки)
  51. 51. Специальные сервисыEC2 Spot InstancesAmazon Route 53Amazon ELBAmazon Glacier
  52. 52. Специальные сервисыSpot Instances:Amazon позиционирует spot instances какинструмент для cloud computingДействительно, можно взять EC2-инстансвысокой конфигурации за небольшие деньги.Этот инстанс будет остановлен как только кто-топредложит большую ставку при дефицитеинстансов.
  53. 53. Специальные сервисыRoute 53: сервис работает хорошо, ноamazon.com использует другие NS amazon.com amazon.com nameserver = ns4.p31.dynect.net. amazon.com nameserver = pdns1.ultradns.net. amazon.com nameserver = pdns2.ultradns.net. amazon.com nameserver = pdns3.ultradns.org. amazon.com nameserver = pdns4.ultradns.org. amazon.com nameserver = pdns5.ultradns.info. amazon.com nameserver = pdns6.ultradns.co.uk. amazon.com nameserver = ns1.p31.dynect.net.
  54. 54. Специальные сервисыELB: последнее падение затронуло ELBПроекты которые полагались толькона ELB в пределах одного регионаоказались недоступны на весь периодвремени
  55. 55. Специальные сервисыGlacier: высокая стоимостьвосстановления данных Дешевизна и надежность архивирования компенсируется стоимостью и скоростью выгрузки данных: «Стоимость выгрузки 3 терабайт данных может дойти до $22082» http://news.ycombinator.com/item?id=4412886
  56. 56. Точка зренияРеально оценивайте пользу от облаковЭффективные решения находятся в областикомбинирования подходовВсегда читайте, что написано мелким шрифтом
  57. 57. Построение отказоустойчивых систем в AWS минимальными средствами Евгений Потапов http://itsumma.ru eapotapov@itsumma.ru http://twitter.com/eapotapov

×