- PVSM.RU - https://www.pvsm.ru -
В начинающем бизнесе всё сосредоточено на завоевании рынка. Любые усилия должны быть направлены на то, что нужно здесь и сейчас. Это касается и серверной инфраструктуры. Множество резервирующих серверов в географически удаленных друг от друга дата-центрах — это, конечно, круто и надежно. Но когда у вас несколько десятков клиентов, какой в этом смысл?
Мы исходили из того же подхода, когда начали разрабатывать облачный сервис Okdesk [1]. Продукт увидел свет на «минимально жизнеспособной инфраструктуре»: виртуальная машина в западном дата-центре, на которой было установлено приложение и СУБД (со временем поисковый движок переехал на соседнюю «виртуалку»). Вокруг этого хозяйства был настроен минимальный мониторинг через ping-admin и регулярные бекапы в облако другого провайдера.
В статье: о причинах переезда, выборе способа переключений дата-центров, выборе дата центра и первых результатах.
С такой инфраструктурой мы продержались “без падений” и показали доступность сервиса в 99,97% (2 часа простоя в год, включая плановые), при этом за всё время мы ни разу не получали жалоб со стороны клиентов на “тормоза” или “простои”.
Но с ростом клиентской базы росли не только выручка и мощность виртуальной машины. Росло и нервное напряжение. Сон становился все более беспокойным, а на прогулке с ребенком внутренний дежурный ожидал сигнала на телефон об инфраструктурной проблеме. Когда количество активных клиентов Okdesk приблизилось к сотне, стало понятно, что дальше так жить нельзя. “Минимально жизнеспособная инфраструктура” себя исчерпала: при серьезной инфраструктурной проблеме простой сервиса мог составить 2 и более часа. И одно дело — когда сервер «лежит» 2 часа для десяти клиентов, и совсем другое — когда доступа нет у сотен. Первое как-то можно пережить, а после второго восстановить репутацию будет куда сложнее, чем работоспособность сервиса.
Итак, мы решили внедрять более надежную инфраструктуру для Okdesk. И вот что из этого получилось…
С чего начать проектирование инфраструктуры облачного сервиса? Нет, не с изучения современных подходов и технологий :) Начать нужно с определения бизнес-требований.
Okdesk — это SaaS для управления клиентскими заявками в сервисных бизнесах. А значит — бизнес-критичная система для потребителей. Исходя из этого мы сформулировали следующие требования:
Два написанных выше требования стали направляющими при проектировании инфраструктуры и выборе конечного решения.
Мы не стали изобретать велосипед и на первом шаге применили следующий подход. В основном дата-центре на двух физических серверах установлено приложение и СУБД. В резервном дата-центре установлен один физический сервер с СУБД и приложением. Между СУБД в резервном дата-центре и СУБД в основном дата-центре настроена репликация данных. В случае аварии в основном дата-центре мы будем перенаправлять трафик в резервный дата центр (см. следующий раздел), время на переключение трафика по плану не должно превышать 5 минут (решение о переключении трафика принимает человек, поэтому в эти 5 минут не включено время реакции на инцидент).
Следующим шагом, когда нагрузка на приложение потребует более мощных серверов (примерно через 4-6 месяцев по нашим расчетам), мы планируем перейти к кластерной модели (балансировщик + ноды с приложением). Можно было бы использовать один мощный сервер, это дешевле. Но при отказе одного большого сервера придется переключать трафик в резервный дата-центр (несколько минут недоступности сервиса), тогда как в случае отказа одной небольшой ноды, максимум что могут почувствовать клиенты — это временная и не критичная деградация производительности. А вот в резервном дата-центре все с точностью до наоборот. По мере роста планируем увеличивать мощности резервного сервера: риск одновременного “падения” основного дата-центра и резервного минимальный, поэтому допустимо немного сэкономить.
Как мы выяснили, есть 3 самых распространенных способа организации быстрого переключения IP адреса, закрепленного за доменным именем:
Остановимся подробнее на плюсах и минусах каждого из способов.
Плюсы:
— быстрое переключение;
— низкая стоимость.
Минусы:
— предоставляется не всеми дата-центрами;
— настраивается дата-центром, в случае необходимости изменений процесс может затянуться;
— не понятно насколько хорошо дела обстоят с резервированием.
Плюсы:
— полный контроль над логикой работы;
— невысокая стоимость;
— несколько ДНС серверов, куда делегирована зона: можно говорить о резервировании.
Минусы:
— некоторые DNS серверы игнорируют TTL переданный от держателя зоны. По нашей информации, число таких упорных серверов очень мало. Но они есть (т.е. не для всех пользователей переключение между IP может сработать оперативно).
Плюсы:
— простая настройка;
— практически мгновенное переключение между IP адресами.
Минусы:
— появляется ещё одна теоретическая точка отказа. С нашей точки зрения в этом плане условный cloudflare с большей вероятностью даст сбой, чем днс амазона или vrrp;
— т.к. все запросы к сервису будут проходить через cloudflare, а наши пользователи в основном находятся на территории СНГ, то это приведёт к увеличению времени ответа от сервера.
В результате мы приняли решение остановиться на route 53 от Amazon. Решение не идеальное, но всегда приходится чем-то жертвовать. При этом мы продолжим изучать другие возможные варианты.
По историческим причинам наш мониторинг состоит из следующих компонент:
Некоторые функции наших мониторингов дублируются, но это, пожалуй, тот случай, когда лучше больше, чем меньше.
При выборе дата-центра исходили из следующих требований:
Исходя из этих требований выбирали между Selectel [6] и Servers [7].
У каждого из провайдеров свои плюсы и минусы.
Плюсы:
— широкая линейка dedicated серверов;
— приемлемые цены;
— много лет на рынке, много доп. сервисов (например, vrrp, которого нет в Servers.ru);
— среди клиентов есть Вконтакте — можно ожидать, что это мотивирует провайдера быть на переднем крае технологий.
Минусы:
— в последнее время наблюдаем много сообщений от знакомых и коллег по цеху о проблемах со стабильностью.
Плюсы:
— дата-центры в нескольких странах, серверы в разных ДЦ можно объединить в одну сеть “из коробки” (т.е. это не дополнительная услуга). Пока наш основной бизнес в СНГ и наличие зарубежных ДЦ не имеет большого значения. Но в обозримом будущем мы планируем выходить на другие рынки, поэтому использование инфраструктуры одно провайдера – хорошее подспорье;
— новые брендовые серверы Dell;
— гибкость и клиентоориентированность как в саппорте (ответы прилетают быстро), так и в продажах (например, без проблем можно договориться об изменении стандартной конфигурации: добавить дисков или памяти).
Минусы:
— есть большой разрыв между конфигурациями серверов. Так, например, самая простая конфигурация включает 1 процессор с 4 ядрами, а следующая 2 процессора по 16 ядер (с разницей в цене 2 раза);
— при прочих равных, цены выше.
В итоге мы выбрали Servers, так как разница цены за
По итогам переезда мы не только стали спать спокойнее, мы значительно улучшили показатели. Например, среднее время отклика уменьшилось в 4 раза
Ну а клиенты Okdesk [1] могут продолжать не беспокоиться о сохранности и доступности данных.
p.s. в рамках статьи мы не погружались в технические аспекты инфраструктуры. Мы хотели сделать акцент на том, что выбор технических решений должен основываться на базе бизнес-требований. На вопросы по техническим аспектам по мере возможности ответим в комментариях.
Автор: Okdesk
Источник [9]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/start-up/269301
Ссылки в тексте:
[1] Okdesk: https://okdesk.ru/?utm_source=habr&utm_medium=blog&utm_campaign=infrastructure
[2] Ping-admin: https://ping-admin.ru/
[3] Monit: https://en.wikipedia.org/wiki/Monit
[4] Scoutapp: https://scoutapp.com/
[5] ИТ-Сумма: https://www.itsumma.ru/
[6] Selectel: https://selectel.ru/
[7] Servers: https://servers.ru/
[8] хостинг: https://www.reg.ru/?rlink=reflink-717
[9] Источник: https://habrahabr.ru/post/343266/
Нажмите здесь для печати.