Привет!

Сегодня мы хотим поделиться с вами опытом использования Microsoft Azure для обеспечения масштабируемости и отказоустойчивости нашей системы мониторинга серверов и сайтов CloudStats.me.

Необходимо отметить, что до начала работы в 6-м наборе акселератора ФРИИ и получения гранта на использование ресурсов Microsoft Azure наша платформа, как и у большинства, работала на обычных выделенных серверах, разделенных на OpenVZ виртуальные машины при помощи панели SolusVM.

Изначально, мы использовали несколько серверов Online.net, Redstation и OVH в конфигурации 2 x Intel Xeon E5 2620v3, 128 GB RAM, 2 x 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).

Привет!

Это первый пост от лица нашей компании на Хабре и в нём мы хотим вам немного рассказать об архитектуре нашего облачного сервиса мониторинга серверов и веб сайтов CloudStats.me, с которым мы в данный момент проходим акселерацию во ФРИИ в Москве. Мы также хотим поделиться с вами нашей текущей статистикой и рассказать о планах на ближайшее будущее, но обо всём по порядку.

1. Архитектура системы

Наша платформа нацелена на системных администраторов, которым не хочется долго возиться с настройкой Nagios или Zabbix, а просто нужно отслеживать основные параметры серверов, не тратя много времени и ресурсов на мониторинг. Мы стараемся не перегружать интерфейс системы количеством настроек, поэтому всё построено по принципу KISS (keep it simple stupid).

Почти вся система написана на Ruby on Rails (за исключением python агента, которого мы скоро также заменим на агента на Ruby), с использованием RactiveJS. Front-end работает на Tomcat, нагрузка на которые распределяется с помощью Haproxy. В качестве CDN мы используем CloudFlare, через которую проходят только статичные файлы JS, CSS, PNG и т.д. Тем не менее, даже для такого достаточно простого и пока что не очень большого сервиса, нам уже приходится применять балансировку нагрузки на всех частях платформы для избежания перегрузок.

Архитектура сервиса на конец июня:



(большая картинка)

Как видно на картинке, задачи создаются отдельным нодом Scheduler и обрабатываются несколькими Worker нодами, которые в свою очередь связываются по API с серверами проверок Ping/Port/URL, расположенными в 3х зонах — France, UK, USA. Если один из серверов проверок вернул «Ping Failed» статус для какого-либо IP, то осуществляются дополнительные проверки в двух других зонах, чтобы исключить false positives. В будущем мы планируем вывести всё это во front-end чтобы вы смогли видеть, из каких локаций ваш IP недоступен (допустим, в ситуации с DDoS или routing issues).