Комментарии 44
Т.е. это можно реализовать только в рамках одного хостера? А если что-то случится с хостером? Тут есть подобные истории...
Какова технология если нужно реализовать VIP между ДЦ разных провайдеров?
Как сделать VIP маршрутизируемым в совершенно разные подсети?
Своими силами никак или трудно (дорого), но думаю что можно заказать создание такой сети компаниям, владеющим дата-центрами. Тут опять же, вопрос цены.
Я выбрал Селектел, так как у него есть дата-центры в разных городах, и недорогая отказоустойчивая геораспределенная сеть. При этом все работает надежно уже несколько лет. При выходе из строя памяти на серверах оно срабатывало, ощутимых простоев сайта не было, что и требовалось получить.
Самым частым и хорошим решением будет создать свою AS (автономная система) и публиковать по bgp протоколу свои публичные адреса с разных точек присутствия. Дальше уже обрабатывать входящий трафик. Такая сетевая схема была построена на заре нулевых в яндексе.
Да, решение хорошее, но дорогостоящее по сравнению с использованием уже готовых и настроенных отказоустойчивых сетей. Для крупных компаний может и подойдет, а для клиентов с одним сервером и ограниченным бюджетом — не факт, к сожалению.
Если у вас много клиентов, то можете купить AS и продавать свою отказоустойчивую сеть. Вместо того чтоб клиенты платили Селектелу, они могут платить вам :)
Насколько я понимаю, сделать такую отказоустойчивую сеть стоит довольно дорого. Все же нам проще пользоваться готовой сетью, тем более она стоит порядка 5-6 тыс. руб. в месяц. Ради этих денег вкладывать миллионы в собственную отказоустойчивую сеть для нас пока не выгодно)
И даже покупать свои серверы, вместо того чтобы арендовать, тоже выгода небольшая. К тому же, свои серверы нужно самим ремонтировать, и это тоже затраты.
Описанное вами решение с репликацией позволит обеспечить устойчивость только при проблемах с железом сервера или с сетью. В то время как обычно наиболее частой причиной отказов в обслуживании является нарушение конфигурации программного обеспечения.
Проектирование отказоустойчивой системы необходимо начинать с прикладного уровня, и только уже всё сделав на уровне бизнес-логики и общесистемного ПО, вы доберётесь до железа, а при этом будет уже более-менее понятно, какие требования к нему закладывать, исходя из выбранной архитектуры отказоустойчивости приложения.
В то время как обычно наиболее частой причиной отказов в обслуживании является нарушение конфигурации программного обеспечения.
При правильной технологии сопровождения сайта все изменения конфигурации и ПО должно предварительно отлаживаться на тестовом сервере.
Проектирование отказоустойчивой системы необходимо начинать с прикладного уровня, и только уже всё сделав на уровне бизнес-логики и общесистемного ПО
В идеальном случае да. Реально вы уже имеете систему, работающую на протяжении ряда лет, и когда нужно обеспечить ее отказоустойчивость, приходится вносить изменения в работающий код, а может быть и в архитектуру. Кроме того нужно оценить затраты на изменения.
Когда мы делали такую систему для одного из наших клиентов, изменения в конфигурации ПО сайта были минимальны.
В каждом случае перед внедрением отказоустойчивости необходимо изучить существующую систему и принимать решение индивидуально, в том числе анализируя бюджет клиента на реализацию отказоустойчивости.
Реально вы уже имеете систему, работающую на протяжении ряда лет, и когда нужно обеспечить ее отказоустойчивость
Это лукавство и злоупотребление ожиданиями клиента, когда ему под видом отказоустойчивого решения продают дублирование железа.
Вы измеряли коэффициент готовности конечного прикладного решения?
Сайт клиента работает очень надежно более 8 лет, и единственные серьезные проблемы, которые с ним происходили, были связаны именно с отказом железа.
В первый раз когда отказал арендованный сервер на его ремонт потребовалось около трех часов, при этом отказ произошел в пике продаж. После настройки отказоустойчивости с использованием VRRP и keepalived в аналогичной ситуации время простоя составило одну минуту, которая ушла на автоматическое переключение с главного сервера на резервный. Обратное переключение было выполнено в плановом режиме, когда посещаемость сайта была минимальна.
Настройка репликации базы данных и файлов обеспечила очень быстрое переключение с минимальной потерей заказов.
Перед тем как предложить это решение клиенту, был проведен анализ различных способов реализации отказоустойчивости с оценкой затрат. Все остальные предложения были как минимум на порядок дороже, при этом у них не было никаких особых преимуществ.
Ну и в чем тут лукавство?
Лукавство вот в этом примере:
Сайт клиента работает очень надежно более 8 лет, и единственные серьезные проблемы, которые с ним происходили, были связаны именно с отказом железа.
Я не ставлю под сомнение ваши слова (хотя не думаю, что вы наблюдали за сайтом клиента более 8 лет), но если это так, то описано крайне маловероятное событие.
Я не ставлю под сомнение ваши слова (хотя не думаю, что вы наблюдали за сайтом клиента более 8 лет), но если это так, то описано крайне маловероятное событие.
То есть вы думаете, что я вас обманываю? Зачем бы это мне. У нас есть сайты, которые мы сопровождаем уже больше 10 лет. За это время мы открыли сотни сайтов интернет-магазинов, и они находились у нас на постоянном сопровождении.
Насчет вероятности выхода из строя сервера — она не велика, но есть. Настоящие проблемы начинаются, когда сервер ломается именно в пике продаж.
Настоящие проблемы начинаются, когда сисадмин по ошибке или по злому умыслу вводит rm -rf /, а репликатор это подхватывает.
Во-первых, у нас работают вменяемая техническая поддержка. Во-вторых, реализовано многоуровневое резервное копирование данных. В третьих, репликация файлов затрагивает только данные сайта, которые есть в резервной копии, а не весь диск сервера со всем его содержимым.
И кстати, не ко всем резервным копиям есть доступ у технической поддержки, и не все копии постоянно онлайн.
Так вот хотелось бы, в частности, про все эти вещи прочитать в статье, которая называется “доступная отказоустойчивость”, а не про банальную мысль продублировать железку.
Так ведь правильная организация сопровождения сайтов — это тема для нескольких статей как минимум. У нас есть технология и свой инструментарий, которым мы пользуемся уже примерно 15 лет. Кое-чем я пытаюсь поделиться.
Но как говорил Козьма Прутков, "нельзя объять необъятое". Я надеюсь постепенно добавить и другие статьи.
Вот например, я уже написал немало статей про мониторинг серверов и сервисов с помощью Zabbix для блога FirstVDS, а мониторинг — тоже элемент защиты от отказов ПО и железа.
Про репликацию файлов статья есть, и на нее имеется ссылка в статье про доступную отказоустойчивость. Статья про многоуровневое резервное копирование в планах, напишу, как только появится время.
Но если кратко - храните копии за 5 дней непосредственно на хостинговом сервере, за 5 дней и 2-3 недели и месячные копии на серверах бекапов, расположенных в другом датацентре, и держите архивные копии (3 недельных, 3 месячных, полугодовые и годовые) на сервере в офисе, который включается только на время копирования.
Результаты копирования контролируйте с помощью Zabbix, также проверяйте возможность восстановления копий.
Остальное — детали, которые нужно прорабатывать в каждом конкретном случае, тема бекапов не очень простая. Вот, например, у нас в день 20 ТБайт бекапов, такие объемы сами по себе создают трудности.
В любом случае создание надежного отказоустойчивого решения, да еще с высокой нагрузочной способностью требует опыта и денег. Я надеюсь, что моя статья поможет начинающим администраторам реализовать отказоустойчивость, когда у клиента нет большого бюджета.
А предпринимателям покажет, что имеются различные способы реализации отказоустойчивости с различным бюджетом. И если не требуется так называемая "бесшовная" отказоустойчивость, то можно не тратить на отказоустойчивость все свои деньги.
Кстати, там очень много всего сделано для отказоустойчивости, мониторинг настроен железа и сервисов, многоуровневое резервное копирование данных, для отладки используются выделенные серверы девелоперов и так далее.
Опять же, сделать дублирование, а точнее горячее резервирование железа, чтобы оно работало и не стоило слишком дорого, и обеспечивало малое время простоя при выходе из строя сервера или дата-центра — не совсем тривиальная задача. Там много разных тонкостей и граблей.
Не, коллеги, если вам нужна отказоустойчивость, то никогда не используйте VRRP и подобные протоколы.
Я не большой сторонник селектела, но если быть его клиентом, то для отказоустойчивости лучше использовать https://selectel.ru/lab/general-load-balancer/ что намного лучше ,чем carp, hsrp vrrp и прочая хрень.
И кроме селектела есть альтернативы, и по цене доступные и по функционалу.
Балансировщик - хорошее решение, но для него нужно настраивать репликацию базы данных MASTER-MASTER, что привносит свои проблемы. Снижение производительности, например, и возможность "расщепления мозга". Там тоже не все тривиально.
Опять же, интересно было бы услышать, чем именно лучше. Решение на базе VRRP у нас работает без проблем уже несколько лет и не раз выручало при выходе из строя серверов.
Про альтернативы тоже интересно было бы услышать.
Использование FHRP оправдано внутри одной площадки (когда вам нужно зарезервировать gateway, например). За растягивание такого между двумя городами (порядка 700км) я бы... Ну, как минимум, посмотрел был косо. Все-таки, мир не стоит на месте. Да и скрипт на Perl намекает на то, что решение явно не ново (я не имею ничего против Perl, сам когда-то писал скрипты - лет 15 назад).
Я к тому, что делать отказоустойчивость между разными площадками - не всегда тривиальная задача. Но явно не та, чтобы решать ее с помощью FHRP.
Вот в чем согласен — это в том, что делать отказоустойчивость в любом случае задача не тривиальная. И весьма дорогостоящая, особенно если подходить к этому без анализа реальных потребностей заказчика.
Но мы не пытались получить приз за новизну, потратив кучу денег клиента. Ему не нужна бесшовная отказоустойчивость. Он также не готов платить за полную переработку архитектуры давно и надежно работающего сайта с целью внедрения отказоустойчивости.
Практика показала, что решение на базе VRRP и keepalive недорогое и оно реально выручало при выходе из строя сервера.
Что касается геораспределеннной отказоустойчивой сети VRRP, то это в зоне ответственности Селектела. Оно работает и нам подошло.
Как я уже писал, альтернативные решения по бюджету были кратно дороже. Возможно, при неограниченном бюджете мы бы переписали все для контейнеров, но в данном случае с точки зрения требований по отказоустойчивости в этом нет никакой необходимости.
Я бы с удовольствием послушал, как еще можно сделать защиту от выхода из строя сервера и дата-центра, оставаясь в рамках затрат на аренду двух серверов и сети между дата-центрами, которая стоит несколько тысяч рублей в месяц.
Кстати, новая версия Perl v5.36 вышла всего полгода назад. Если кто-то предпочитает другие языки, то он сможет без проблем реализовать на них алгоритмы, необходимые при использовании keepalived.
Современный мультимастер работает на gtid и уже сплитбрейны не проблема. Но перформанс конечно чуть-чуть уменьшается. Зато никаких ручных действий никогда не надо делать.
Правильно ли я понимаю, что там все же нужно три сервера брать, а не два, чтобы не было проблем с расщеплением мозга?
И еще придется вносить изменения в архитектуру сайта, которая изначально создана для работы на одном сервере. А там очень сложные процессы в бэкофисе (делали несколько лет), и их придется переделывать, чтобы, например, они не шли одновременно на всех серверах. А значит надо еще отслеживать, какие серверы работают и распределять по ним процессы.
Переделать конечно можно, но это затраты для клиента.
Подозреваю, что настройка схемы с балансировщиком будет далеко не тривиальной. Да и производительность в нашем случае очень важна.
А если это будет стоить дороже, чем сейчас, клиент откажется. Ведь целесообразность настройки таких схем определяется убытками во время простоя. Для многих клиентов потенциальный простой даже в 1-2 дня не является причиной дополнительных затрат, не говоря уже о 2-3 часах. Все же серверы и дата-центры выходят из строя относительно редко. Если что, можно поднять новый сервер и развернуть сайт из бекапов.
У кого-то продажи идут равномерно и нет явных пиков, когда убытки от аварий очень велики. Кто-то еще не знает, что серверы и дата-центры могут выходить из строя, ведь работали же несколько лет, и нечего такого не было. Это как бекапы, которые кто-то уже делает, а кто-то — еще нет.
В данном случае был выбран компромисс, когда обратное переключение выполняется вручную, но при авариях на главном сервере сайт не работает всего минуту-две. Оптимизация при этом сделана на бюджет при допустимом времени простоя.
Нет, вы понимаете не правильно. Реализовать multimaster можно и из 2х серверов, древняя статья лет 5 назад была у перконы https://www.percona.com/blog/2018/03/13/the-multi-source-gtid-replication-maze/ где базируется на 2х нодах мультимастера. GTID репликация решает вопрос сплитбрейна за счёт глобального идентификатора.
Это хорошо, с идентификатором понятно, но вообще репликация мастер-мастер еще накладывает разные ограничения, требует ревизии SQL-запросов и логики работы приложения. В целом я посчитал что в данном случае проще обойтись репликацией мастер-слейв.
Ничего не надо, приложение смотрит всегда в свою базу и работает как и сейчас и ничего не меняется. Только репликация между бд по другому настраивается. А для репликации файлов вместо rsync лучше использовать lsync работающий на inotify событиях.
Правда для файлов сплитбрейн возможен и я бы попробовал drbd мультимастер с diskless, как делает это linstore.
Так просто не получится. Вот, например, процессы экспорта заказов в службу доставки и импорта ассортимента и наличия от поставщиков не могут идти сразу на нескольких серверах — будет большая беда.
А если на одном, то на каком из двух?
Значит нужно отслеживать, какие серверы доступны и запускать только на одном из них.
Это только на поверхности, а в глубине наверняка есть еще похожие проблемы.
С файлами да, отдельная боль.
У вас есть VIP, он всегда указывает только на один какой-то сервер, он является маркером какой сервер активен. Обращение к бд должны идти через вип, тогда они всегда будут попадать только на один из двух серверов.
Да, это решает часть проблем. Однако все равно потребуется ревизия всего проекта — там все очень сложно, много людей делали несколько лет. Хотя бы те же обращения к базе нужно все проверять, искать поля в таблицах с автонумерацией и т.п.
И еще к базе придется обращаться по сети, что будет тормозом, помимо того что надо дожидаться выполнения транзакций на других мастер-серверах.
Но если подвернется заказчик с подходящим бюджетом — обязательно попробую.
Кстати, а что будет при одновременном обращении по VIP к базе с разных серверов? Возможно что ничего хорошего, если бекофис на это не рассчитан. Так что по любому придется просматривать все подряд.
А вот при репликации master-slave это все разрулить намного проще. Но тоже нужно блокировать запуск на slave скриптов, которые обращаются к базе для записи.
Приложение будут корректно работать.
Чем возможно? Какая разница сколько копий приложения обращается к бд? Что надо просматривать, не совсем вас понял?
Ну вот представьте себе, что на двух серверах запустился одновременно или с небольшим интервалом длительный пакетный процесс выгрузки заказов в службу доставки. В этом случае выгрузка будет выполнена дважды. С двойной отметкой в базе данных магазина.
Аналогичные проблемы будут при одновременном запуске двух пакетных заданий импорта ассортимента и наличия. Если не предпринимать никаких мер, одно и тоже будет импортировано дважды.
Вы же в своей статье указали, что пакетные задания вы включаете там где вип, какая разница мультимастер у вас бд или нет?
Да, этот способ позволит не запускать пакетные задания, если VIP на сервере не поднят. Только я вот точно не знаю, в случае балансировщика появляется этот VIP на сетевом интерфейсе сервера (как при keepalived), или же там только перенаправление трафика.
Надо еще посмотреть, как работает балансировщик. Подозреваю это все же не то, что позволяет управлять, на каких серверах что нужно запускать, а а что нет.
Если сервер вышел из строя, то балансировщик не будет направлять на него трафик, но как остальные серверы об этом узнают, пока непонятно.
И ведь балансировщик будет направлять трафик сразу на несколько серверов, если они все рабочие.
Какого балансировщика? Вы перепутали ветку?
Ну мы обсуждаем репликацию мастер-мастер при использовании балансировщика. А если VRRP и keepalived, то не очень понятно, зачем тут мастер-мастер.
Возможно это позволило бы автоматизировать обратный переход на отказавший мастер-сервер после его восстановления, но едва ли стоит это делать.
Мало ли что было с мастер-сервером, и почему он перестал работать. Тут безопаснее вначале проверить все на нем, а потом уже включать его в работу.
Может там ОС надо переустанавливать или какие-нибудь пакеты, может быть файлы конфигурации испортились или еще чего. Может там оперативная память вышла из строя и он будет перезагружаться каждые десять минут, у меня такое было.
И уж точно нужно копировать файлы обратно со слейва на мастер, за время недоступности мастера они изменятся на слейве.
В любом случае я не рискну автоматически возобновлять доступ к отказавшему серверу, если он вдруг снова появился в сети. Не исключено, что он стал негодным для использования.
Ни про какой балансировщик я не говорил, не упоминал и не имел ввиду. Если вышедший из строя сервер вернётся в работу, то попытка восстановить его как слейв в случае проблем провалиться, а в случае успеха уберёт необходимость ручных действий. Что бы с сервером не произошло, вернуть его в работу как слейв можно.
А кто его знает, провалится или нет. Сервис keepalived может и заработает, а вот все остальное я предпочитаю смотреть вручную. А то я буду думать, что со слейвом все хорошо, а там, например, nginx перестал работать или еще что испортилось, или он начнет периодически перезагружаться.
Конечно, Zabbix при этом пришлет много нехороших писем, но уж лучше я не буду рисковать и посмотрю все сам. Все проблемы от лени)
Что касается балансировщика, то я изучал возможность использования Селектеловского, они мне и прислали инструкцию по настройке репликации мастер-мастер для Maria DB.
По хорошему тут бы два слейв-сервера, чтобы при выходе мастера из строя сохранялась отказоустойчивость. Но это дополнительные расходы.
Сильно не пинать но возможно наверное с разными хостерами реализовать через Docker. тестировал nginx балансировщик через Docker+keepalived запускался для тестов. в прод не зашло из-за избыточности. За развернутую статью с бд спасибо. на досуге попробую потестировать.
В данном случае сайт изначально не был разработан для Docker, а переделка для контейнеров будет чрезмерно дорогой. Кроме того значительно увеличатся расходы на сопровождение — ведь специалисты по Kubernetes стоят ну очень дорого. И таких хорошо бы как минимум два.
Кроме того, контейнеры сами по себе никак не решают проблему отказоустойчивости базы данных. Этим придется заниматься отдельно.
Доступная отказоустойчивость для вашего сайта