Высокая доступность в гибридном облаке на базе Azure Traffic Manager. Jelastic - контейнерная платформа как сервис, которая может быть установлена как в частный ЦОД, так и в глобальное облако, например Microsoft Azure. Также возможен гибридный сценарий, когда часть приложения размещается в частном ЦОД, а другая часть в одном или нескольких регионов Azure. Мы пытались решить задачу организации максимальной доступности и отказоустойчивости приложений в гибридном облаке, а также миграции комплексных приложений без downtime из одного ЦОД в другой. Решая ее мы перепробовали несколько архитектурных вариантов: Anycast IP, Global IP, Anycast DNS на базе Nginx и bind, а также Azure Traffic Manager. В докладе расскажем про апробацию различных архитектурных паттернов высокой доступности и отказоустойчивости в многоцодовой конфигурации, а также про реализацию итогового решения на базе Azure Traffic Manager.

1. Высокая доступность в
гибридном облаке на базе
Azure Traffic Manager
Дмитрий Лазаренко, Jelastic
Директор по развитию бизнеса в России и СНГ

2. Проблема

3. Единая точка отказа

4. Высокая доступность и отказоустойчивость
App
DB

5. Высокая доступность и отказоустойчивость
App
DB
App
Load balancer

6. Высокая доступность и отказоустойчивость
App
DB
App
Load balancer Load balancer
DB

7. Высокая доступность и отказоустойчивость
App
DB
App
Load balancer Load balancer
DBReplica

8. Гибридная облачная платформа Jelastic
PaaS для Java, .NET, Ruby, PHP, Node.JS, Python и Docker приложений
• Автоматизированная платформа, позволяющая запускать
и масштабировать любое приложение на Java, .NET, PHP,
Python, Ruby и Node.JS
• SQL и NoSQL СУБД, серверы приложений,
балансировщики нагрузки, очереди сообщений
• Как Azure, только для Java + можно установить в свой
ЦОД
Платформа PaaS как коробочный продукт

9. Гибридная облачная платформа Jelastic
PaaS для Java, .NET, Ruby, PHP, Node.JS, Python и Docker приложений
• Основные сценарии: среды разработки и тестирования,
высокодоступные автомасштабируемые облачные среды для
приложений
• Клиенты
 50+ Хостинг-провайдеров (MyCloud.by)
 Корпоративные пользователи (ISV, системные интеграторы)
• Конкуренты – OpenShift, CloudFoundry, Heroku
• Можно развернуть свой экземпляр PaaS для Java в Azure с
помощью Azure Marketplace
Платформа PaaS как коробочный продукт

10. Визуальный конструктор облачных окружений

11. Физические серверы и контейнеры
1 ЦОД

12. Типичная конфигурация – MS Azure в миниатюре
• 10-50 физических серверов
• 32 – 256 GB RAM каждый
• На каждом сервере
• 250-2000 контейнеров
• Итого в кластере
• 8000 – 64000 контейнеров
• 160-1400 приложений конечных
пользователей

13. Распределение контейнеров для HA
Affinity & Anti-Affinity
• Для высокой доступности
• Для защиты от
неравномерной загрузки
серверов

14. Пользовательские домены
DNS-сервер Bind
Proxy-server NGINX

15. Глобальная точка входа

16. Высокая доступность для точки входа

17. Высокая доступность для точки входа

18. Высокая доступность для точки входа

19. 17 ЦОД в
8 странах
11 ЦОД, 23 зон
доступности в
8 странах
3 ЦОД, 10 зон
доступности в
3 странах
25 ЦОД в
11 странах
36 ЦОД в
25 странах
Межцодовая оркестрация в Jelastic

20. Private Cloud
Гибридное облако

21. Мульти-облако

22. Как обеспечить высокую доступность в сценарии
гибридного или мульти-облака?
• Сервис должен работать одновременно в 2+ ЦОД
• При выходе из строя одного из экземпляров сервиса,
его работу автоматом должны подхватить другие
• Решение должно поддерживать любые ЦОД и облака
• Для клиента такое переключение должно быть
прозрачным

23. Проблемы
• Внутренние подсети в каждом облаке разные
• 172.160.200.* vs. 172.155.100.*
• Базовое доменное имя каждого облака разное
• *.cloudA.jelastic.com vs. *.cloudB.jelastic.com
• Внешние IP-адреса каждого облака разные

24. • Anycast IP
• Global IP/Failover IP
• Global/Anycast DNS своими силами
• Azure Traffic Manager
HA между ЦОД - варианты

25. Unicast адресация
«Позвонить маме»

26. Anycast адресация
«Позвонить 911»

27. Anycast IP – маршрут запросов

28. • IP-адрес живет одновременно в нескольких ЦОД
• Быстрота. Трафик идет до ближайшего сервера (не гео)
• В случае DDoS-атаки траффик равномерно
распределяется между всеми точками вещания
• Если сервер умирает – маршрут автоматом
перестраивается до ближайшего рабочего сервера
• Абсолютно прозрачно для клиента
Преимущества Anycast

29. • Поддерживается малым количеством ЦОД
• Не поддерживается глобальными облачными
провайдерами: Azure, AWS, SoftLayer
• Очень дорого: $2700 - $8500 в месяц за небольшой
сервер (Host Virtual)
Недостатки Anycast

30. • IP-адрес активен только на одном сервере в один
момент времени
• Если мастер-сервер умирает, то можно выбрать новый
мастер-сервер
• Новый мастер-сервер может быть как в текущем, так и
в другом ЦОД
Failover IP

31. • 2 сервера в разных географических регионах
• Каждый сервер владеет своим failover IP
• В случае падения одного из серверов, его IP
автоматом переназначается на его backup-сервер
• В итоге backup-сервер владеет сразу 2 failover IP, весь
трафик идет на backup-server
• Пока не оживет первый сервер
Failover IP – пример работы на IBM SoftLayer/OVH

32. • Поддерживается не всеми глобальными облачными
провайдерами
• Сложно реализовать между разными ЦОД (частный и
публичный)
• В AWS failover IP есть только в рамках текущего
региона
• Задержки до 5 минут при первом падении сервера
Недостатки Failover IP

33. • Распределили точку входа по нескольким ЦОД
(nginx+bind)
• Добавили глобальное DNS-имя, независимое от ЦОД
• *.globalcloud.jelastic.com
• Каждое приложение теперь доступно по 2м DNS-именам
• Глобальному
• Локальному, связанному с его текущим ЦОД
HA на базе DNS своими руками

34. HA на базе DNS своими руками

35. • Сложность масштабирования вверх
• Сложность гео-маршрутизации
• Высокие накладные расходы
HA на базе DNS своими руками - недостатки

36. Azure Traffic Manager
• Запрос к DNS
• Определение
Endpoint
• Отправка трафика
на один и тот же
endpoint, пока он
жив

37. Azure Traffic Manager – Round robin балансировка

38. Azure Traffic Manager - Failover routing

39. Geo-routing

40. Azure Traffic Manager - Performance/Geo routing

41. Azure Traffic Manager – Встроенный мониторинг

42. Azure Traffic Manager – Многоуровневая иерархия

43. Azure Traffic Manager – Многоуровневая иерархия
Гео-балансировка
ЦОД ЦОД ЦОД
Сервис Сервис

44. Azure Traffic Manager - недостатки
• Кэш DNS обновляется редко, часть запросов может идти
на упавший endpoint
• Мониторинг производится только GET-запросом
• Веса в Round-Robin статичны
• Нельзя использовать собственные метрики мониторинга

45. Azure Traffic Manager в Jelastic

46. Живая миграция из частного ЦОД в Azure

47. Живая миграция из AWS в Azure

49. Azure Traffic Manager - преимущества
• Поддержка гео-балансировки
• Поддержка плавных обновлений сервиса по цепочке
• Встроенный мониторинг и failover
• Многоуровневая DNS-иерархия
• Поддержка как веб-сервисов Azure, так и произвольных
веб-сервисов в публичном или частном облаке

50. За рамками задачи остаются…
• Автоматическое горизонтальное масштабирование
• Репликация данных серверов приложений
• Распределенные блокировки
• Репликация и шардинг данных в СУБД
• Репликация и высокая доступность Storage
• Автоматическое восстановление данных Storage после
аппаратных сбоев

51. Многое решается фреймворками для микросервисов
Consul.io

52. Выводы
• Anycast IP – дорого и привязано к конкретным ЦОД
• Global IP/Failover IP – доступно у некоторых крупных
игроков
• Global DNS – можно реализовать где угодно, но трудно
обслуживать и масштабировать
• Azure Traffic Manager – простой и удобный способ
настроить гео-балансировку в гетерогенной среде

53. Дмитрий Лазаренко
dl@jelastic.com
@lazarenkod
@jelastic