Как стать автором
Обновить
52
Карма
-1
Рейтинг
Александр Фролов @AlexandreFrolov

Управляющий директор

Доступная отказоустойчивость для вашего сайта

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

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

Доступная отказоустойчивость для вашего сайта

А кто его знает, провалится или нет. Сервис keepalived может и заработает, а вот все остальное я предпочитаю смотреть вручную. А то я буду думать, что со слейвом все хорошо, а там, например, nginx перестал работать или еще что испортилось, или он начнет периодически перезагружаться.

Конечно, Zabbix при этом пришлет много нехороших писем, но уж лучше я не буду рисковать и посмотрю все сам. Все проблемы от лени)

Что касается балансировщика, то я изучал возможность использования Селектеловского, они мне и прислали инструкцию по настройке репликации мастер-мастер для Maria DB.

Доступная отказоустойчивость для вашего сайта

По хорошему тут бы два слейв-сервера, чтобы при выходе мастера из строя сохранялась отказоустойчивость. Но это дополнительные расходы.

Доступная отказоустойчивость для вашего сайта

Ну мы обсуждаем репликацию мастер-мастер при использовании балансировщика. А если VRRP и keepalived, то не очень понятно, зачем тут мастер-мастер.

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

Мало ли что было с мастер-сервером, и почему он перестал работать. Тут безопаснее вначале проверить все на нем, а потом уже включать его в работу.

Может там ОС надо переустанавливать или какие-нибудь пакеты, может быть файлы конфигурации испортились или еще чего. Может там оперативная память вышла из строя и он будет перезагружаться каждые десять минут, у меня такое было.

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

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

Доступная отказоустойчивость для вашего сайта

Да, этот способ позволит не запускать пакетные задания, если VIP на сервере не поднят. Только я вот точно не знаю, в случае балансировщика появляется этот VIP на сетевом интерфейсе сервера (как при keepalived), или же там только перенаправление трафика.

Надо еще посмотреть, как работает балансировщик. Подозреваю это все же не то, что позволяет управлять, на каких серверах что нужно запускать, а а что нет.

Если сервер вышел из строя, то балансировщик не будет направлять на него трафик, но как остальные серверы об этом узнают, пока непонятно.

И ведь балансировщик будет направлять трафик сразу на несколько серверов, если они все рабочие.

Доступная отказоустойчивость для вашего сайта

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

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

Доступная отказоустойчивость для вашего сайта

Кстати, а что будет при одновременном обращении по VIP к базе с разных серверов? Возможно что ничего хорошего, если бекофис на это не рассчитан. Так что по любому придется просматривать все подряд.

А вот при репликации master-slave это все разрулить намного проще. Но тоже нужно блокировать запуск на slave скриптов, которые обращаются к базе для записи.

Доступная отказоустойчивость для вашего сайта

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

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

Но если подвернется заказчик с подходящим бюджетом — обязательно попробую.

Доступная отказоустойчивость для вашего сайта

Так просто не получится. Вот, например, процессы экспорта заказов в службу доставки и импорта ассортимента и наличия от поставщиков не могут идти сразу на нескольких серверах — будет большая беда.

А если на одном, то на каком из двух?

Значит нужно отслеживать, какие серверы доступны и запускать только на одном из них.

Это только на поверхности, а в глубине наверняка есть еще похожие проблемы.

С файлами да, отдельная боль.

Доступная отказоустойчивость для вашего сайта

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

Доступная отказоустойчивость для вашего сайта

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

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

Доступная отказоустойчивость для вашего сайта

Правильно ли я понимаю, что там все же нужно три сервера брать, а не два, чтобы не было проблем с расщеплением мозга?

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

Переделать конечно можно, но это затраты для клиента.

Подозреваю, что настройка схемы с балансировщиком будет далеко не тривиальной. Да и производительность в нашем случае очень важна.

А если это будет стоить дороже, чем сейчас, клиент откажется. Ведь целесообразность настройки таких схем определяется убытками во время простоя. Для многих клиентов потенциальный простой даже в 1-2 дня не является причиной дополнительных затрат, не говоря уже о 2-3 часах. Все же серверы и дата-центры выходят из строя относительно редко. Если что, можно поднять новый сервер и развернуть сайт из бекапов.

У кого-то продажи идут равномерно и нет явных пиков, когда убытки от аварий очень велики. Кто-то еще не знает, что серверы и дата-центры могут выходить из строя, ведь работали же несколько лет, и нечего такого не было. Это как бекапы, которые кто-то уже делает, а кто-то — еще нет.

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

Доступная отказоустойчивость для вашего сайта

Насколько я понимаю, сделать такую отказоустойчивую сеть стоит довольно дорого. Все же нам проще пользоваться готовой сетью, тем более она стоит порядка 5-6 тыс. руб. в месяц. Ради этих денег вкладывать миллионы в собственную отказоустойчивую сеть для нас пока не выгодно)

И даже покупать свои серверы, вместо того чтобы арендовать, тоже выгода небольшая. К тому же, свои серверы нужно самим ремонтировать, и это тоже затраты.

Доступная отказоустойчивость для вашего сайта

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

Но мы не пытались получить приз за новизну, потратив кучу денег клиента. Ему не нужна бесшовная отказоустойчивость. Он также не готов платить за полную переработку архитектуры давно и надежно работающего сайта с целью внедрения отказоустойчивости.

Практика показала, что решение на базе VRRP и keepalive недорогое и оно реально выручало при выходе из строя сервера.

Что касается геораспределеннной отказоустойчивой сети VRRP, то это в зоне ответственности Селектела. Оно работает и нам подошло.

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

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

Кстати, новая версия Perl v5.36 вышла всего полгода назад. Если кто-то предпочитает другие языки, то он сможет без проблем реализовать на них алгоритмы, необходимые при использовании keepalived.

Доступная отказоустойчивость для вашего сайта

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

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

Доступная отказоустойчивость для вашего сайта

Так ведь правильная организация сопровождения сайтов — это тема для нескольких статей как минимум. У нас есть технология и свой инструментарий, которым мы пользуемся уже примерно 15 лет. Кое-чем я пытаюсь поделиться.

Но как говорил Козьма Прутков, "нельзя объять необъятое". Я надеюсь постепенно добавить и другие статьи.

Вот например, я уже написал немало статей про мониторинг серверов и сервисов с помощью Zabbix для блога FirstVDS, а мониторинг — тоже элемент защиты от отказов ПО и железа.

Про репликацию файлов статья есть, и на нее имеется ссылка в статье про доступную отказоустойчивость. Статья про многоуровневое резервное копирование в планах, напишу, как только появится время.

Но если кратко - храните копии за 5 дней непосредственно на хостинговом сервере, за 5 дней и 2-3 недели и месячные копии на серверах бекапов, расположенных в другом датацентре, и держите архивные копии (3 недельных, 3 месячных, полугодовые и годовые) на сервере в офисе, который включается только на время копирования.

Результаты копирования контролируйте с помощью Zabbix, также проверяйте возможность восстановления копий.

Остальное — детали, которые нужно прорабатывать в каждом конкретном случае, тема бекапов не очень простая. Вот, например, у нас в день 20 ТБайт бекапов, такие объемы сами по себе создают трудности.

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

А предпринимателям покажет, что имеются различные способы реализации отказоустойчивости с различным бюджетом. И если не требуется так называемая "бесшовная" отказоустойчивость, то можно не тратить на отказоустойчивость все свои деньги.

Доступная отказоустойчивость для вашего сайта

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

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

Доступная отказоустойчивость для вашего сайта

Я не ставлю под сомнение ваши слова (хотя не думаю, что вы наблюдали за сайтом клиента более 8 лет), но если это так, то описано крайне маловероятное событие.

То есть вы думаете, что я вас обманываю? Зачем бы это мне. У нас есть сайты, которые мы сопровождаем уже больше 10 лет. За это время мы открыли сотни сайтов интернет-магазинов, и они находились у нас на постоянном сопровождении.

Насчет вероятности выхода из строя сервера — она не велика, но есть. Настоящие проблемы начинаются, когда сервер ломается именно в пике продаж.

Доступная отказоустойчивость для вашего сайта

Балансировщик - хорошее решение, но для него нужно настраивать репликацию базы данных MASTER-MASTER, что привносит свои проблемы. Снижение производительности, например, и возможность "расщепления мозга". Там тоже не все тривиально.

Опять же, интересно было бы услышать, чем именно лучше. Решение на базе VRRP у нас работает без проблем уже несколько лет и не раз выручало при выходе из строя серверов.

Про альтернативы тоже интересно было бы услышать.

Доступная отказоустойчивость для вашего сайта

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

В первый раз когда отказал арендованный сервер на его ремонт потребовалось около трех часов, при этом отказ произошел в пике продаж. После настройки отказоустойчивости с использованием VRRP и keepalived в аналогичной ситуации время простоя составило одну минуту, которая ушла на автоматическое переключение с главного сервера на резервный. Обратное переключение было выполнено в плановом режиме, когда посещаемость сайта была минимальна.

Настройка репликации базы данных и файлов обеспечила очень быстрое переключение с минимальной потерей заказов.

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

Ну и в чем тут лукавство?

Информация

В рейтинге
Не участвует
Откуда
Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность