Сегодня поговорим об опыте прототипирования нового решения с использованием 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.