Привет!

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

Добрый день.

В завершение «недели NGINX», мы решили рассказать об очень интересной сборке «безопасной» версии NGINX китайской компании Neusoft, о которой не было замечено ни одной статьи на Хабре, а именно — SeNginx. В дополнение к этому, мы также расскажем вам о втором веб сервере, которому не уделяется так много внимания, как Nginx — Hiawatha Web Server, и постараемся сравнить Hiawatha с SeNginx в плане использования их для обеспечения безопасности вашего сайта или web приложения.



Отметим, что за 5 лет существования нашей хостинговой компании нам довелось повидать целый спектр атак различных уровней и типов на сайты и web приложения наших клиентов, а также поработать с London Metropolitan Police в поиске и поимке одного управляющего ботнетом. Сегодня DDoS атаки стали настолько частыми, что только за вчерашний день Arbor в одном из наших датацентров зафиксировал 49 DDoS атак 3/4 уровней мощностью до 20-25 Gbit/s (график 1 и график 2). И, хотя Arbor девайсы и могут при определенной настройке неплохо справляться с атаками 3 и 4 уровня, они практически бесполезны при атаках 7 уровня, целью которых является перегрузка ресурсов сервера, а также поиск уязвимостей в вашем приложении.

Самым бюджетным вариантом отражения атак 7 уровня являются различные варианты с использованием DNS RoundRobin + HaProxy, Nginx, Varnish Cache и т.д., которые либо позволяют рассредоточить атаку между несколькими серверами клиента, либо дают возможность обработать запросы ботов «в лоб» с помощью отдачи кешированной версии страницы. Данный подход, к сожалению, часто требует ручной настройки, постоянного мониторинга и редко эффективен при меняющихся типах атак.

Наглядное представление DNS RoundRobin + Nginx (источник):



После длительных поисков нами был найден отличный модуль к NGINX, написанный русскими программистами на Perl в 2012 году и позволяющий фильтровать ботов, которые заходят на ваш сайт в автоматическом режиме — Roboo (статья на Хабре). Модуль показал себя с наилучшей стороны, позволяя фильтровать сотни тысяч запросов от ботов с помощью NGINX с минимальной нагрузкой на сервер.

Добрый день.

Некоторое время назад проект нашей компании по мониторингу серверов и сайтов перешел из категории «сделано для себя» в плоскость привлечения массовых пользователей. Этому частично способствовало получение проектом посевных инвестиций от ФРИИ и плюс, конечно же, наличие желания поделиться с миром нашей технологией, которую мы также используем для мониторинга своих серверов. Но, это не рекламный пост, а практический, поэтому о проекте потом.

Итак, с ростом нагрузки на базу данных, а наш сервис — это SaaS платформа по сбору метрик с серверов, количество запросов на запись в нашу базу данных (сейчас более 1000 серверов посылают порядка 20 своих метрик в БД каждые 4 минуты) начало приводить к перегрузке БД и нестабильной работе сервиса. Это зачастую происходило из-за превышения установленного максимального количества соединений к MySQL и большой нагрузки на сервер. К сожалению, все попытки оптимизации MySQL, увеличения серверных ресурсов и настройки параметров max_connections, query cache и т.д. не приводили к успеху.

Т.к. у нас нет отдельного человека, отвечающего за базы данных, а программисты и системные администраторы не могут каждый день тратить кучу времени на поддержание стабильности MySQL и реагировать на каждое падение, мы решили перейти на MariaDB Galera кластер с master-master репликацией и балансировкой нагрузки с помощью HaProxy. У нас до этого не было опыта внедрения бд кластера в production environment и поэтому пришлось наступать на все грабли самостоятельно.

К счастью, на Хабре нашлось много полезных статей на тему настройки Percona XtraDB, HaProxy и Zabbix для Percona, а также серия статей «Идеальный Кластер», которые нам очень помогли в начальной установке.

Уважаемые Хабражители, после экспериментов с самарским коворкингом и другими проектами, мы наконец решили начать писать что-нибудь для Хабра по основному виду нашей деятельности, то есть хостингу, серверам и связанным с этим технологиям. Для начала хотелось бы написать о популярных ныне среди разработчиков облачных ресурсах и сравнить основных игроков на этом рынке.

Вступление

Слово “облачный” хорошо известно всем владельцам сайтов. Облачные технологи предоставляются как сервис — есть доступ к ресурсам (оперативной памяти, процессору, устройствам хранения информации и т. д.), без указания, где конкретно в какой момент ресурсы эти ресурсы находятся.



«Облачность» предполагает возможность предоставления ресурсов с высокой гарантией их наличия. Иными словами, если аппаратные ресурсы на части физических компьютеров облака выйдут из строя или будут отключены, облако как целое может продолжать функционировать (в ряде случаев без существенной потери эффективности), или даже восстановить работоспособное состояние автоматически («самоизлечение», self-healing).

В случае, если есть необходимость выбора облачного провайдера, ниже предлагается список, с которого можно начать знакомство. Все они годятся в т.ч. для хостинга сайтов.

Мы с партнером считаем себя первопроходцами в области развития коворкинга в регионах. Наш коворкинг появился в Самаре почти полтора года назад. За это время мы уже успели набить множество шишек, порадоваться каким-то успехам, попробовать разные пути развития: в общем, опыта набрались достаточно. Именно им я бы и хотел поделиться.



Дело в том, что за время работы нашего центра мне поступила куча сообщений из соседних регионов с просьбами рассказать, как идут дела, выгодно ли это, есть ли спрос на наше предложение. Многие хотят повторить наш подвиг (а по большому счету такие проекты в регионах по-другому и не назвать) в своих городах, но опасаются, что деньги вылетят в трубу. Как ответ всем тем, кто хочет открыть свой коворкинг в провинции, я решился на написание этого поста.

В минувшую пятницу, 13 Июля, как и было обещано, состоялось открытие коворкинг-инкубатора в Самаре.

Предлагаем вам фотоотчет с этого события. Теперь мы официально работаем и ждем всех в гости.

Было очень интересно пообщаться со всеми посетившими нас людьми и мы благодарны всем за визит.



К открытию подготовили небольшой фуршет с канапе и шампанским. Вроде всем понравилось.

Доброго времени суток всем!

Это наш первый пост на Хабре, надеемся вам понравится.

Итак, 13 июля, наша компания открывает первый коворкинг-инкубатор в самом центре Самары, для всех свободных или почти свободных людей, то есть для — фрилансеров, стартаперов, начинающих предпринимателей, а также всех тех, кто предпочитает работать удаленно, но ненавидит тоску и хочет работать в социально-богатой и приятной атмосфере.

Приглашаем всех на открытие и объявляем конкурс на лучшее название для нашего центра!