Опыт построения прототипа...
TRANSCRIPT
© ALTOROS Systems | CONFIDENTIAL
Опыт построения прототипа
регионально-распределенной
системы в
Amazon AWS Virtual Private CloudСергей Сверчков
© ALTOROS Systems | CONFIDENTIAL 2
Проблемы текущего решения
Система медицинского назначения, поставляется клиентам в виде
отдельной локальной установки вместе с приборами
Слишком много инсталляций для сопровождения
Лицензионные отчисления - платформа MS Windows Server
Нерасширяемая и неотказустойчивая архитектура – все
компоненты в одном сервере
Нет аналитики и агрегированных данных в целом по всем клиентам
© ALTOROS Systems | CONFIDENTIAL 3
Некотороые бизнес - требования к новому решению
1. Значительное снижение затрат на поддержку решения для заказчика
2. Система должна поддерживать от 100.000 устройств сразу, и быть
масштабируемой в 10 раз
3. Высокая надежность и доступность всех сервисов
4. Система должна быть доступна в разных регионах с минимальной
latency
5. Высокие требования по безопасности
6. Multi-tenancy – много клиентов на одной платформе
© ALTOROS Systems | CONFIDENTIAL 4
1. Решение для отдельных клиентов с установкой на их площадке –
“локальный сервис”.
2. “Большой публичный сервис” для всех клиентов, регионально –
распределенный.
3. Единая архитектура для “публичного сервиса” и “локального сервиса”.
4. Масштабируемость системы без перестроения архитектуры.
5. Без привязки к определенной платформе IaaS
6. Максимальное использование open-source компонентов
Архитектурные требования к новому решению
© ALTOROS Systems | CONFIDENTIAL 5
Модель – варианты работы нового решения
Архитектура решения должна поддерживать несколько вариантов “поставки” сервиса для различных клиентов
Устройства работают напрямую с
“публичным” сервисом
“Локальный” сервис для отдельных
клиентов
Устройства работают через VPN канал с
“публичным” сервисом
© ALTOROS Systems | CONFIDENTIAL 6
Выбор технологий - OpenStack как инфраструктурная платформа
Рассматривали OpenStack, CloudStack, Eucalyptus, vCloud
OpenStack - по лицензии Apache 2.0, поддерживается и развивается
вендорами Cisco, Dell, NASA, Intel, AMD, AT&T, RedHat, Ubuntu, …
OpenStack поддерживает множество гипервизоров (KVM , XEN
ESXi/VMWare, Hyper-V and “baremetal”)
Консоль управления сервисами и виртуальными машинами.
Крупные провайдеры cloud сервисов используют платформу OpenStack
благодаря возможностям и стабильности.
© ALTOROS Systems | CONFIDENTIAL 7
Выбор технологий – кластер хранения данных в NoSQL
Requirements
Cassandra HBase MongoDBWeight on
decision 1. Multi-data center (regions) bi-directional replication to multi regions 10 10 6 102. Support for active/active reads across regions 10 10 10 103. Auto resynchronization of data between regions in the event of loss of connectivity 9 8 5 105. Support for active/active writes across regions 10 10 5 97. Tunable Consistency for reads and writes 10 0 10 98. Survive loss of nodes and up to an entire region without impacting clients and ability to serve requests (read and write) 10 10 6 89. Ability to add nodes in a cluster and rebalance data with minimal impact 10 10 10 815. Security: Kerberos or similar authentication models to support secure server communication 8 10 8 719. Security: Transparent data encryption 8 9 8 620. Bulk Loading and Extract/Dump capability 8 10 9 321. Adapters for data transfer to Hadoop 9 10 9 3
TOTAL SCORE: 1414 1249 1197
© ALTOROS Systems | CONFIDENTIAL 8
Выбор технологий – MariaDB Galera Cluster как SQL база
MariaDB Galera Cluster поддерживает:
Разрабатывается паралельно с MySQL (но независимо) “оригинальной”
командой MySQL.
Доступен по лицензии GNU General Public License, version 2
Настоящий failover SQL кластер
Синхронная паралельная репликация, на уровне строк
Активная multi-master топология - чтение и запись на любой узел
кластера
Автоматическое синхронизация данных при добавлении нового узла
Автоматическое восстановление состояния узла кластера после сбоя
© ALTOROS Systems | CONFIDENTIAL 9
Выбор технологий – Amazon AWS для прототипирования
Amazon AWS подходит для быстрого прототипирования. Используем:
Virtual Private Cloud в нескольких регионах
IPSEC для коммуникации между VPC в разных регионах
Elastic Load Balancer для распределения нагрузки по доступным
серверам
Route 53 hosted zone с тестовым доменом как DNS сервис для
нескольких регионов
Elastic Block Storage volumes с заданным значением IOPS
Статические IP адреса внутри VPC
Опционально - Elastic IP адреса для внешнего доступа на инстансы в
VPC
© ALTOROS Systems | CONFIDENTIAL 10
Архитектура прототипа в Amazon AWS
© ALTOROS Systems | CONFIDENTIAL 11
1. Решение размещено в двух регионах (Oregon and North Virginia)
2. Регионально-распределенные кластеры Cassandra and MariaDB Galera
3. Балансирощик нагрузки ELB в каждом регионе с проверкой доступности
прикладного сервиса (TCP healthcheck порт 8083).
4. High availability and fault tolerance на каждом уровне архитектуры
5. Распределенный мониторинг с помощью Ganglia
6. Route 53 hosted zone with failover / latency routing policy
Архитекта прототипа в Amazon AWS
© ALTOROS Systems | CONFIDENTIAL 12
7. Эмулятор устройств с возможностью создания заданного количества
соединений по протоколу web sockets
8. Размер каждого пакета данных в эмуляторе ~ 256 байт
9. Каждое соединение отправляет данные раз в 30 секунд
10.Сетевой сервер на основе библиотеки Netty пишет в Cassandra
11. Интерактивный Dashboard на Angular.js читает из Cassandra
12.Нагрузочное тестирование до 100.000 соединений ~ 3.000 сообщений в
секунду.
Архитектура прототипа в Amazon AWS
© ALTOROS Systems | CONFIDENTIAL 13
Архитектура прототипа в Amazon AWS – MariaDB Galera Cluster
© ALTOROS Systems | CONFIDENTIAL 14
Архитектурная прототипа в AWS – Cassandra cluster
Сетевая топология кластера - 2 датацентра DC1 (N. Virginia) и DC2 (Oregon)
# Cassandra Node IP=Data Center:Rack10.0.1.188=DC1:RAC110.0.1.189=DC1:RAC210.0.1.190=DC1:RAC3 172.38.0.176=DC2:RAC1172.38.0.177=DC2:RAC2172.38.0.178=DC2:RAC3
Keyspace с фактором репликации 2 в каждом датацентре DC1 и DC2: CREATE KEYSPACE mednet WITH placement_strategy = 'NetworkTopologyStrategy' AND strategy_options={DC1:2,DC2:2};
Данные с эмуляторов устройств сохраняются в COLUMN FAMILY device_record :
CREATE COLUMN FAMILY device_record WITH key_validation_class = UTF8Type AND default_validation_class = UTF8Type AND comparator = LongType;
© ALTOROS Systems | CONFIDENTIAL 15
Use case 1: Запись и чтение данных в двух датацентрах
A. Позволяет ли система записывать и читать данные в обоих датацентрах?
Use case 2: Поддерживамая нагрузка
B. Может ли система обеспечивать обработку данных для 100.000 устройств?
Use case 3: Отказоустойчивость - Fault tolerance
C. Будет ли система обеспечивать сохранение и чтение данных при
выключении / отказе одного или нескольких серверов?
D. Восстанавливается ли состояние сервиса когда сервер восстановлен?
E. Будет ли система работать если сервера одного из регионов недоступны?
Прототип в AWS – тестовые сценарии
© ALTOROS Systems | CONFIDENTIAL 16
Elastic Load Balancer – как работает service healthcheck
Концепция в AWS – уроки имплементации
© ALTOROS Systems | CONFIDENTIAL 17
Elastic Load Balancer – регистрация инстанса
Концепция в AWS – уроки имплементации
Используем AWS CLI для регистрации инстанса при старте. Пример скрипта:
EC2_INSTANCE_ID=`wget -q -O - http://169.254.169.254/latest/meta-data/instance-id`
LOAD_BALANCER_NAME=vpc2
case $1 in start)
aws elb deregister-instances-from-load-balancer --load-balancer-name $LOAD_BALANCER_NAME --instances $EC2_INSTANCE_ID
aws elb register-instances-with-load-balancer --load-balancer-name $LOAD_BALANCER_NAME --instances $EC2_INSTANCE_ID
© ALTOROS Systems | CONFIDENTIAL 18
Route 53 routing policy – latency или failover
Концепция в AWS – уроки имплементации
© ALTOROS Systems | CONFIDENTIAL 19
Концепция в AWS – уроки имплементации
Route 53 routing policy –failover
Все сервера работают, Primary выбран Oregon. Делаем трассировку по доменному имени:
>tracert hsp.altoros.com
Tracing route to hsp.altoros.com [54.201.193.252] over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms ip-10-172-72-3.us-west-1.compute.internal [10.172.72.3] 2 <1 ms <1 ms <1 ms ip-10-1-86-5.us-west-1.compute.internal [10.1.86.5]4 <1 ms <1 ms <1 ms 216.182.236.114…..10 32 ms 32 ms 32 ms ec2-54-201-193-252.us-west-2.compute.amazonaws.com [54.201.193.252] – это Load Balancer в Oregon, заданный как Primary Record в Route 53
© ALTOROS Systems | CONFIDENTIAL 20
Концепция в AWS – уроки имплементации
Route 53 routing policy –failover
Выключаем все сервера в Oregon – имитируя “отказ” региона Делаем трассировку по доменному имени через небольшой интервал:
>tracert hsp.altoros.comTracing route to hsp.altoros.com [54.84.49.149] over a maximum of 30 hops:
1 3 ms <1 ms <1 ms ip-10-172-72-3.us-west-1.compute.internal [10.172.72.3]4 31 ms 3 ms 4 ms 216.182.236.11413 * * * Request timed out. 14 83 ms 83 ms 83 ms ec2-54-84-49-149.compute-1.amazonaws.com [54.84.49.149] – это Load Balancer в N.Virginia заданный как Failover Record в Route 53
© ALTOROS Systems | CONFIDENTIAL 21
Концепция с OpenStack – диаграмма компонентов
© ALTOROS Systems | CONFIDENTIAL 22
Концепция с OpenStack – выбор hardware
© ALTOROS Systems | CONFIDENTIAL 23
Спасибо
Сергей Сверчков