Опыт построения прототипа регионально-распределительной системы в Amazon AWS Virtual Private Cloud
•Als PPTX, PDF herunterladen•
1 gefällt mir•1,301 views
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Опыт построения прототипа регионально-распределительной системы в Amazon AWS Virtual Private Cloud
Ähnlich wie Опыт построения прототипа регионально-распределительной системы в Amazon AWS Virtual Private Cloud (20)
Mehr von Altoros
Mehr von Altoros (20)
Опыт построения прототипа регионально-распределительной системы в Amazon AWS Virtual Private Cloud
- 1. Сергей Сверчков © ALTOROS Systems | CONFIDENTIAL
- 2. Система медицинского назначения, поставляется клиентам в виде отдельной локальной установки вместе с приборами Слишком много инсталляций для сопровождения Лицензионные отчисления - платформа MS Windows Server Нерасширяемая и неотказустойчивая архитектура – все компоненты в одном сервере Нет аналитики и агрегированных данных в целом по всем клиентам © ALTOROS Systems | CONFIDENTIAL 2
- 3. 1. Значительное снижение затрат на поддержку решения для заказчика 2. Система должна поддерживать от 100.000 устройств сразу, и быть масштабируемой в 10 раз 3. Высокая надежность и доступность всех сервисов 4. Система должна быть доступна в разных регионах с минимальной latency 5. Высокие требования по безопасности 6. Multi-tenancy – много клиентов на одной платформе © ALTOROS Systems | CONFIDENTIAL 3
- 4. 1. Решение для отдельных клиентов с установкой на их площадке – “локальный сервис”. 2. “Большой публичный сервис” для всех клиентов, регионально – распределенный. 3. Единая архитектура для “публичного сервиса” и “локального сервиса”. 4. Масштабируемость системы без перестроения архитектуры. 5. Без привязки к определенной платформе IaaS 6. Максимальное использование open-source компонентов © ALTOROS Systems | CONFIDENTIAL 4
- 5. Архитектура решения должна поддерживать несколько вариантов “поставки” сервиса для различных клиентов Устройства работают напрямую с “публичным” сервисом Устройства работают через VPN канал с “публичным” сервисом “Локальный” сервис для отдельных клиентов © ALTOROS Systems | CONFIDENTIAL 5
- 6. Рассматривали 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 6
- 7. Cassandra HBase MongoDB Weight on decision Requirements 1. Multi-data center (regions) bi-directional replication to multi regions 10 10 2. Support for active/active reads across regions 10 10 3. Auto resynchronization of data between regions in the event of loss of connectivity 9 8 5. Support for active/active writes across regions 10 10 7. Tunable Consistency for reads and writes 10 0 8. Survive loss of nodes and up to an entire region without impacting clients and ability to serve requests (read and write) 10 10 9. Ability to add nodes in a cluster and rebalance data with minimal impact 10 10 15. Security: Kerberos or similar authentication models to support secure server communication 8 10 19. Security: Transparent data encryption 8 9 20. Bulk Loading and Extract/Dump capability 8 10 21. Adapters for data transfer to Hadoop 9 10 © ALTOROS Systems | CONFIDENTIAL TOTAL SCORE: 1414 1249 6 10 10 10 5 10 5 10 9 9 6 8 10 8 8 8 7 6 9 9 1197 3 3 7
- 8. MariaDB Galera Cluster поддерживает: Разрабатывается паралельно с MySQL (но независимо) “оригинальной” командой MySQL. Доступен по лицензии GNU General Public License, version 2 Настоящий failover SQL кластер Синхронная паралельная репликация, на уровне строк Активная multi-master топология - чтение и запись на любой узел кластера Автоматическое синхронизация данных при добавлении нового узла Автоматическое восстановление состояния узла кластера после сбоя © ALTOROS Systems | CONFIDENTIAL 8
- 9. 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 9
- 10. © ALTOROS Systems | CONFIDENTIAL 10
- 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 © ALTOROS Systems | CONFIDENTIAL 11
- 12. 7. Эмулятор устройств с возможностью создания заданного количества соединений по протоколу web sockets 8. Размер каждого пакета данных в эмуляторе ~ 256 байт 9. Каждое соединение отправляет данные раз в 30 секунд 10. Сетевой сервер на основе библиотеки Netty пишет в Cassandra 11. Интерактивный Dashboard на Angular.js читает из Cassandra 12. Нагрузочное тестирование до 100.000 соединений ~ 3.000 сообщений в секунду. © ALTOROS Systems | CONFIDENTIAL 12
- 13. © ALTOROS Systems | CONFIDENTIAL 13
- 14. Сетевая топология кластера - 2 датацентра DC1 (N. Virginia) и DC2 (Oregon) # Cassandra Node IP=Data Center:Rack 10.0.1.188=DC1:RAC1 10.0.1.189=DC1:RAC2 10.0.1.190=DC1:RAC3 172.38.0.176=DC2:RAC1 172.38.0.177=DC2:RAC2 172.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 14
- 15. Use case 1: Запись и чтение данных в двух датацентрах A. Позволяет ли система записывать и читать данные в обоих датацентрах? Use case 2: Поддерживамая нагрузка A. Может ли система обеспечивать обработку данных для 100.000 устройств? Use case 3: Отказоустойчивость - Fault tolerance A. Будет ли система обеспечивать сохранение и чтение данных при выключении / отказе одного или нескольких серверов? B. Восстанавливается ли состояние сервиса когда сервер восстановлен? C. Будет ли система работать если сервера одного из регионов недоступны? © ALTOROS Systems | CONFIDENTIAL 15
- 16. © ALTOROS Systems | CONFIDENTIAL 16
- 17. Используем AWS CLI для регистрации инстанса при старте. Пример скрипта: EC2_INSTANCE_ID=`wget -q -O - http://169.254.169.254/latest/metadata/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 17
- 18. © ALTOROS Systems | CONFIDENTIAL 18
- 19. Все сервера работают, 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 19
- 20. Выключаем все сервера в Oregon – имитируя “отказ” региона Делаем трассировку по доменному имени через небольшой интервал: >tracert hsp.altoros.com Tracing 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.114 13 * * * 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 20
- 21. © ALTOROS Systems | CONFIDENTIAL 21
- 22. © ALTOROS Systems | CONFIDENTIAL 22
- 23. Спасибо Сергей Сверчков sergey.sverchkov@altoros.com © ALTOROS Systems | CONFIDENTIAL 23
Hinweis der Redaktion
- Сегодня поговорим об опыте прототипирования нового решения с использованием Amazon AWS. Заказчик проекта –крупная компания которая работает в сфере медицины, производит и продает специализированные приборы. Приборы поставляются клиентам вместе с программным обеспечением, устанавливаются и работают в локальной сети. Клиенты могут сами выбирать сервера для установки (по рекомендации заказчика), и сами выполнять установку ПО по заданной инструкции. Программное обеспеспечение создано как единый (неделимый на модули) комплекс, выполняется на платформе Windows. Основными проблемами являются с точки зрения бизнеса – слишком большое количество установок для поддержки, дополнительные лицензионные отчисления, нерасширяемая и неотказустойчивая архитектура, невозможность получить глобальную аналитику об использовании устройств. Развитие бизнеса таким экстенсивным путем – увеличением количества установок очень проблемно.
- Поэтому заказчик принимает решение о создании новой платформы, где возможно значительное снижение затрат на установку и поддержку решения путем консолидации сервисов для множества клиентов на одной платформе, регионально-распределенной, но при этом доступной глобально для управления, расширения и развития. Решение должно поддерживать работу порядка 100.000 устройств, которые уже есть у клиентов, быть масштабируемыем в 10 раз без изменения архитектуры, простым добавленияем ресурсов. Высокая надежность и отказустойчивость к различным видам сбоев – сетевого оборудования, серверов, дисков должна быть реализована на всех уровнях решения. Отдельные требования предъявляются к безопасности системы в целом и ее составляющих компонентов, где контроль проводит федеральная служба в области медицины. В частности не могут использоваться компоненты ПО, которые недоступны для полного самостоятельного тестирования или, скажем, их алгоритмы работы не является открытым.
- Первым этапом работ над новым решением стала планирование и обсуждение архитектуры системы, выбор и оценка компонентов для построения публичного и локального сервисов. А также построение прототипа решения для проверки архитектуры. Изначально сравнивали провайдеров публичных облачных инфраструктур - Amazon AWS, Windows Azure, Rackspace, но было очевидно что публичные платформы недостаточны чтобы создать версию решения для поставки клиентам как локальный сервис. Поэтому стали рассматриватье доступные решения для построения своей инфраструктуры. Рассматривали OpenStack, CloudStack, Eucalyptus, vCloud Director. Каждая платформа имеет свои особенности и плюсы-минусы. OpenStackбыл рекомендована как одна из наиболее динамично развивающихся открытых платформ по лицензии Apache, над которой работают крупные игроки на рынке ПО. Важным фактором в пользу OpenStackявляется то, что некоторые провайдеры публичных облаков строят и продвигают свои платформы на основе OpenStack. OpenStack доступен для установке на Ubuntu, RedHat, CentOS, практически независим от hardware, весь кластер можно запустить для тестов на одной машине.
- Следующим элементом, для которого рассматривались различные решения - это кластер для хранения данных. А примерная оценка объема данных от всех существующих устройств – это сотни терабайт данных, и основная операция – это запись данных. Возможные решения – это масштабируемые NoSQL, где операция расширения кластера – scale out – одна из основных. Мы строили матрицу оценки решений NoSQLпо многим атрибутам, некоторые из них представлены на слайде. Ключевые требования – поддержка распределенного на несколько регионов кластера, возможность активной записи и чтения в любой регион и любую часть кластера, автоматическая синхронизация после потери соединения, настраиваымые уровни согласованного чтения и записи. Результаты сводили в таблицу, где для каждого пункта был задан свой вес в общей оценке. Наибольший результат по сравнению получила Cassandra (причем здесь мы учитывали как свободную редакцию, так и возможности Enterprise версии от Datastax)
- Определенные данные в системе должны храниться в структурированном виде, поэтому реляционная база тоже является частью нового решения. В качестве хорошего кандидата на роль SQL кластера подходит MariaDBGalera Cluster. Решение разрабатывается одновременно с MySQL командой “оригинальных” разработчиков MySQL. Поддерживает активное чтение и запись в любой узел кластера, синхронную паралелльную репликацию, автоматическую синхронизацию данных при добавлении или восстановлении узла в кластере. Основное назначение кластерной конфигурации – это failover, т.к. каждый кластерный узел содержит полную базу данных.
- Ну и конечно же инфраструктура Amazon AWS тоже оказывается полезной, в первую очередь для быстрого создания прототипа регионально – распределенного решения, т.к. Amazon дает возможность работать с многими датацентрами, в разных географических регионах. Вот как раз об некоторых аспектах опыта создания пилотной версии решения мы сегодня и будем говорить.Итак основные элементы которые мы использовали из Amazon AWS:Частные облака Virtual Private Cloud в 2 регионахVPN соединение между регионами настроенные с помощью IPSECELB в каждом регионе для распределения входящих потоков данных между рабочими серверамиRoute 53 hosted zone c тестовым доменомEBS диски для постоянного храненияElastic IP адреса для внешнего доступа
- In POC deployment hsp-cassandra1 host with IP 10.0.1.188 was chosen as master. Replication settings are next: [mariadb]wsrep_cluster_address=gcomm://10.0.1.188wsrep_provider=/usr/lib64/galera/libgalera_smm.sowsrep_sst_auth=root:passwordwsrep_node_address=10.0.1.188log-error=/var/log/mysql.log Configurationin“non-master” nodes points wsrep_cluster_address to “master” node IP wsrep_cluster_address=gcomm://10.0.1.188 [mariadb]wsrep_cluster_address=gcomm://10.0.1.188wsrep_provider=/usr/lib64/galera/libgalera_smm.sowsrep_sst_auth=root:passwordwsrep_node_address=10.0.1.189log-error=/var/log/mysql.log Start MariaDBGalera cluster. “Master” node is started in the first place. mysqld --wsrep_cluster_address=gcomm:// --user=mysql >> /var/log/mysql/mysql_cluster.log 2>&1 & Then all other nodes are started and join the cluster: mysqld --wsrep_cluster_address=gcomm://10.0.1.188 --user=mysql >> /var/log/mysql/mysql_cluster.log 2>&1 &
- Controller Node : Controller node has been configured to use 2 separate networks to divide public network traffic and management traffic.EM1 inet interface: used for private networking, management and storage traffic. EM2 inet interface: used for public network access only. Compute Node : Compute node has been configured to use 2 separate networks to divide public network traffic and management traffic.EM1 inet interface: used for private networking, management and storage traffic. EM2 inet interface: used for public network access only. Network Configuration:Current deployment is using Neutron GRE networking. GRE tunnels encapsulate isolated layer 2 network traffic in IP packets that are routed between compute and networking nodes using the hosts' network connectivity and routing tables. Using GRE tunnels as tenant networks in Neutron avoids the need for a network interface connected to a switch configured to trunk a range of VLANs.All nodes network cards are connected to different switches.Open vSwitch is configured to route traffic between VM instance using host private network. If instance has Floating IP then router allows traffic between EM1 and EM2 interfaces.