Использование Microsoft Azure для обеспечения масштабируемости и отказоустойчивости проекта CloudStats.me
Привет!
Сегодня мы хотим поделиться с вами опытом использования Microsoft Azure для обеспечения масштабируемости и отказоустойчивости нашей системы мониторинга серверов и сайтов CloudStats.me.
Необходимо отметить, что до начала работы в 6-м наборе акселератора ФРИИ и получения гранта на использование ресурсов Microsoft Azure наша платформа, как и у большинства, работала на обычных выделенных серверах, разделенных на OpenVZ виртуальные машины при помощи панели SolusVM.
Изначально, мы использовали несколько серверов Online.net, Redstation и OVH в конфигурации 2 x Intel Xeon E5 2620v3, 128 GB RAM, 2×500 GB SSD, H/W RAID1, дисковая система которых обеспечивает до 15,000 IOPS судя по нашим тестам. Для любой платформы сбора статистики производительность дисковой системы является особенно важной из-за необходимости обработки большого потока входящих данных и операций на запись в базу данных.
Как мы писали ранее, мы использовали бесплатный балансировщик нагрузки HaProxy с Apache Tomcat и кластером MySQL MariaDB для распределения нагрузки на наши сервера. С одной стороны, выделенные серверы обеспечивали необходимую производительность, но с другой стороны требовали отдельного мониторинга ресурсов и не позволяли обеспечить отказоустойчивость из-за отсутствия отдельного балансировщика на стороне датацентра, что могло привести к отказу системы при падении нашего load balancer’a.
Благодаря работе со специалистами Microsoft в рамках акселератора и программы BizSpark, нами были протестированы возможности Azure и разделено хранилище данных на два типа — SQL (MariaDB Cluster) и NoSQL (DocumentDB).
Итак, что же было сделано?
В первую очередь, нами была протестирована дисковая система виртуальных машин в Azure. В соответствии с характеристиками, стандартные виртуальные машины типа A0-A7 имеют достаточно низкие показатели IOPS в районе 500 IOPS на каждую VM. Это обусловлено тем, что виртуальные машины используют удаленное сетевое хранилище, в отличие от обычных VPS, которые располагаются на выделенных серверах.
Тем не менее, существует несколько вариантов увеличения количества IOPS вашей виртуальной машины, с помощью RAID и дополнительных настроек, которые можно найти тут. Надо отметить, что при использовании RAID0 количество IOPS действительно возрастает, мы смогли добиться порядка 2000–3000 IOPS с 4 дисками, объединенными в RAID0.
Если же этого недостаточно, можно использовать виртуальные машины типа «DS», которые имеют локальное SSD хранилище, а также позволяют подключать диски типа Premium (SSD), которые предоставляют гораздо больше ресурсов (ссылка).
Availability Sets / Auto-Scaling / Load Balancing
Несмотря на особенности дисковой системы, Azure предоставляет достаточно гибкие возможности настройки для обеспечения отказоустойчивости приложения (Availability Sets), а также масштабируемости (Auto-Scaling).
Мы были предупреждены, что все компоненты системы необходимо дублировать и добавлять в Availability Sets для избежания отказов в обслуживании во время технических работ и обновления систем Microsoft Azure, которые происходят довольно часто. Технические работы могут приводить к случайным перезагрузкам виртуальных машин и их недоступности в течении определенных периодов.
Нужно отметить, что в случае создания копий виртуальных машин и добавления их в Availability Set и Auto-Scaling их можно выключить и тем самым сэкономить, т.к. машины в статусе Stopped (Deallocated) не подлежат оплате (кроме хранилища).
В дополнение, в Azure присутствует балансировщик нагрузки, который можно легко использовать с front-end виртуальными машинами, например для распределения нагрузки на Nginx/Apache. Тем не менее, для распределения нагрузки на базу данных (например, MariaDB) данный балансировщик не подойдет, т.к. в MySQL кластере необходимо отслеживать статус серверов с базой данных, что Azure load balancer делать пока не умеет. Для MySQL лучше подойдет HaProxy или MaxScale (поставляется MariaDB, но не имеет графического интерфейса для отслеживания статуса).
DocumentDB vs MongoDB
В рамках работы в стресс тест лаборатории Microsoft перед нами была поставлена задача обеспечения бесперебойной работы базы данных нашего приложения. На тот момент мы использовали только MySQL Mariadb Cluster с балансировщиком нагрузки HaProxy, которая не позволяла обеспечить необходимую степень отказоустойчивости из-за возможных рассинхронизаций кластера и необходимости ручного добавления новых серверов в кластер.
Т.к. используемая схема не являлась оптимальной, нами было решено разделить хранилище данных на два типа — SQL (MariaDB) и NoSQL. Мы решили продолжить использовать MySQL для пользовательских данных, таких как учетные записи пользователей, данные по оплатам и т.д., и выделить статистические и исторические данные по мониторингу серверов в NoSQL хранилище, тем самым разгрузив основную базу.
Нами были протестированы Azure DocumentDB и MongoDB как варианты NoSQL хранилища. На данный момент DocumentDB не имеет встроенной поддержки Ruby приложений, поэтому мы использовали Java библиотеку с базовой odm оберткой (можем выложить по запросу). Т.к. DocumentDB является DBaaS решением, плюсом является то, что не нужно тратить время и силы на поддержку серверов, в отличие от MongoDB, который опять таки нужно настраивать на самой виртуальной машине вручную. С другой стороны, MongoDB позволит легко мигрировать инфраструктуру сервиса при необходимости смены датацентра.
В данный момент мы остановились на DocumentDB, хотя и продолжаем тестировать решения CouchDB (имеет удобную панель управления) и MongoDB.
Что необходимо помнить при работе с платформой Microsoft Azure:
- Виртуальные машины Azure имеют достаточно жесткие ограничения по IOPS, которые тем не менее можно увеличить с помощью RAID0 и дополнительного тюнинга системы
- Виртуальные машины необходимо добавлять в Availability Sets для исключения простоев и случайных перезагрузок во время технических работ в датацентрах Microsoft
- Auto-Scaling позволит вам сэкономить денежные средства запуская виртуальные машины только по мере необходимости
- Запуск виртуальных машин занимает до нескольких минут, что нужно учитывать при конфигурации параметров Auto-Scaling
- Каждая подпска Azure имеет доступ только к 5 зарезервированным публичным IP адресам
- Желательно проводить оптимизацию кода приложения для сокращения затрат на облачные ресурсы
- Балансировщик нагрузки в Azure может легко быть использован для front-end виртуальных машин Nginx/Apache, но не подойдет для распределения нагрузки на базу данных
- При использовании Azure желательно отдельно приобретать пакет технической поддержки, которая отсутствует по умолчанию
- Протокол ICMP (ping) заблокирован в Azure и вы не сможете пинговать свои виртуальные машины. Используйте telnet или psping, чтобы определить открыт или закрыт тот или иной порт
Что мы получили в итоге?
Мы смогли обеспечить отказоустойчивость приложения с помощью виртуальных машин для front-end’a с Nginx/Tomcat, балансировщика нагрузки встроенного в Azure, а также Availability Sets и Auto-Scaling. Мы разделили хранилища данных на SQL и NoSQL для распределения нагрузки на базу данных. Мы надеемся, что использование DocumentDB позволит в долгосрочной перспективе сократить издержки на настройку, мониторинг и поддержку серверов, как в случае с MongoDB.
Также, благодаря ресурсам Azure мы смогли снизить ограничения бесплатных аккаунтов и разрешить мониторинг 100 серверов, 100 веб сайтов и 100 IP адресов полностью бесплатно. Попробовать можно тут.
В ближашее время мы обновим платформу CloudStats и добавим мониторинг приложений по модели New Relic, но об этом в следующей статье.
