Опыт построения прототипа регионально-распределительной системы в Amazon AWS Virtual Private Cloud

© ALTOROS Systems | CONFIDENTIAL

Опыт построения прототипа

регионально-распределенной

системы в

Amazon AWS Virtual Private CloudСергей Сверчков

© ALTOROS Systems | CONFIDENTIAL 2

Проблемы текущего решения

Система медицинского назначения, поставляется клиентам в виде

отдельной локальной установки вместе с приборами

Слишком много инсталляций для сопровождения

Лицензионные отчисления - платформа MS Windows Server

Нерасширяемая и неотказустойчивая архитектура – все

компоненты в одном сервере

Нет аналитики и агрегированных данных в целом по всем клиентам


Некотороые бизнес - требования к новому решению

1. Значительное снижение затрат на поддержку решения для заказчика

2. Система должна поддерживать от 100.000 устройств сразу, и быть

масштабируемой в 10 раз

3. Высокая надежность и доступность всех сервисов

4. Система должна быть доступна в разных регионах с минимальной

latency

5. Высокие требования по безопасности

6. Multi-tenancy – много клиентов на одной платформе


1. Решение для отдельных клиентов с установкой на их площадке –

“локальный сервис”.

2. “Большой публичный сервис” для всех клиентов, регионально –

распределенный.

3. Единая архитектура для “публичного сервиса” и “локального сервиса”.

4. Масштабируемость системы без перестроения архитектуры.

5. Без привязки к определенной платформе IaaS

6. Максимальное использование open-source компонентов

Архитектурные требования к новому решению


Модель – варианты работы нового решения

Архитектура решения должна поддерживать несколько вариантов “поставки” сервиса для различных клиентов

Устройства работают напрямую с

“публичным” сервисом

“Локальный” сервис для отдельных

клиентов

Устройства работают через VPN канал с

“публичным” сервисом


Выбор технологий - 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

благодаря возможностям и стабильности.


Выбор технологий – кластер хранения данных в 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


Выбор технологий – MariaDB Galera Cluster как SQL база

MariaDB Galera Cluster поддерживает:

Разрабатывается паралельно с MySQL (но независимо) “оригинальной”

командой MySQL.

Доступен по лицензии GNU General Public License, version 2

Настоящий failover SQL кластер

Синхронная паралельная репликация, на уровне строк

Активная multi-master топология - чтение и запись на любой узел

кластера

Автоматическое синхронизация данных при добавлении нового узла

Автоматическое восстановление состояния узла кластера после сбоя


Выбор технологий – 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


Архитектура прототипа в Amazon AWS


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


7. Эмулятор устройств с возможностью создания заданного количества

соединений по протоколу web sockets

8. Размер каждого пакета данных в эмуляторе ~ 256 байт

9. Каждое соединение отправляет данные раз в 30 секунд

10.Сетевой сервер на основе библиотеки Netty пишет в Cassandra

11. Интерактивный Dashboard на Angular.js читает из Cassandra

12.Нагрузочное тестирование до 100.000 соединений ~ 3.000 сообщений в

секунду.

Архитектура прототипа в Amazon AWS


Архитектура прототипа в Amazon AWS – MariaDB Galera Cluster


Архитектурная прототипа в 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;


Use case 1: Запись и чтение данных в двух датацентрах

A. Позволяет ли система записывать и читать данные в обоих датацентрах?

Use case 2: Поддерживамая нагрузка

B. Может ли система обеспечивать обработку данных для 100.000 устройств?

Use case 3: Отказоустойчивость - Fault tolerance

C. Будет ли система обеспечивать сохранение и чтение данных при

выключении / отказе одного или нескольких серверов?

D. Восстанавливается ли состояние сервиса когда сервер восстановлен?

E. Будет ли система работать если сервера одного из регионов недоступны?

Прототип в AWS – тестовые сценарии


Elastic Load Balancer – как работает service healthcheck

Концепция в AWS – уроки имплементации


Elastic Load Balancer – регистрация инстанса


Используем 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

http://169.254.169.254/latest/meta-data/instance-id%60

http://169.254.169.254/latest/meta-data/instance-id%60


Route 53 routing policy – latency или failover




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



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


Концепция с OpenStack – диаграмма компонентов


Концепция с OpenStack – выбор hardware


Спасибо

Сергей Сверчков

[email protected]

mailto:[email protected]

Technology

Опыт построения прототипа регионально-распределительной системы в Amazon AWS Virtual Private Cloud