Successfully reported this slideshow.
Your SlideShare is downloading. ×

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

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 58 Ad

More Related Content

Slideshows for you (20)

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

Advertisement

More from Ontico (20)

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 Large Instance (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 Instances Amazon Route 53 Amazon ELB Amazon 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

×