Отказоустойчивость web-сервиса — DNS Failover, SQL, PHP. Правильно ли мыслю?
Есть Web-сервис, работающий на VPS, не сильно требовательный к ресурсам (PHP/Laravel, MariaDB, Nginx), но важен постоянный доступ. Простои больше 10 минут - уже критичны. Хостинг подходит только Российский , перепробовал за несколько лет много разных, но не нашел такого, чтобы все время проработал стабильно.
Хочу повысить отказоустойчивость сервиса.
Перечитал много разной теории про балансировщиков, nginx, docker swarm и kubernetes и т.д. В таких вещах смущает что все равно есть какой-то центральный сервер или мастер-нода, которая рулит балансировкой или мониторит доступность нод/серверов. И если он не будет работать, то вообще ничег не будет работать. Поэтому этот вариант мне не очень нравится...
Я планирую сделать так:
1. DNS Failover - через платный сервис cloudns.
2. Два VPS сервера в разных локациях (например Москва и Казань)
3. Репликация БД MariaDB через Master-Master
4. Синхронизация файлов через Unison
Сам в этом деле нуб, на практике никогда не сталкивался. Поэтому ткните в правильном ли направлении мыслю и двигаюсь?
На VPS-ках (и не двух, а больше) ставите reverse-proxy Nginx, пусть направляют трафик на основной сервер, при его падении - уже на запасной (второй запасной, третий и т.д.). Соответсвенно MySQL-сервера будут Master-Slave, и надо только позаботиться о репликации Slave->Master.
koltykov, Да они все надёжные.
Бэкапы надо делать и деплой тренировать, чтобы в случае чего быстро подняться.
Потому что сгореть, как OVH, или потерять базу через инъекцию в ламерском пхпе скрипте можно где угодно.
Ипатьев, бэкапы базы и файлов у меня на 2 сервера делаются - VPS другого провайдера (master-slave) и домашний. Плюс бесплатный снэпшот от хостера. Деплой с автотестами также настроен.
Но вопрос тут несколько в другом был, а не про бэкапы...
Ну и как показал опыт пользования хостингом с 99-го года, далеко не все надежные. Самый надежный дедик что у меня был - hetzner. 1200+ дней без перезагрузки и какаих-либо проблем. Популярный некоммерческий проект. Работает до сих пор. Почти 20 лет на хетзнере, раза 3 сервак менял только на более мощный.
Но сейчас проект в РУ должен быть.
koltykov, очень хорошо, бэкапы вы делаете. А хоть раз вы их разворачивали? А реьч именно об этом. О времени, которое проходит с момента нажатия кнопки до момента, когда сайт начинает обрабатывать запросы. А не о "деплое с автотестами"
И если речь идет о таких цыплячьих нагрузках, как стоимость впс, то быстро разворачиваемый бэкап будет оптимальным решением.
Но если вам просто для себя, на кошках потренироваться, то и разворачивайте себе всё по этому плану. Уже на этапе репликации вам надоест. Но зато опыт получите. В отличие от ковыряния в носу на Хабре. Про Манилова в школе проходили?
хорошо, что еще есть люди которые умеют читать вопрос, а то я увидел про DNS балансировку и возбудился Ипатьев в общем то прав: быстрый деплой из последнего бэкапа ближе подведет вас к решению проблемы "поднять за 10 минут"
Как допвариант возможно избыточной схемы для koltykov:
приложение работает на хостингА
1. научите приложение определять сбой и перезапускаться самостоятельно внутри виртуалки
1а. если приложение фейлится постоянно или проблема с виртуалкой - полный редеплой подготовленными скриптами на новую VM
2. разделите БД (включая файлы) и приложение на разные сервера (если не используете сервис для БД)
2а. частые бэкапы данных на внешний сервис.
2аа. регулярная проверка восстановления (скриптом) данных с внешнего сервиса на хостингБ и А
2б. Если умер сервер\недоступен сервис с данными: скриптами полный редеплой и восстановление данных из бэкапа
3. если умер хостингА - теми же скриптами деплой на хостингБ
4. публичный эндпойнт-балансировщик, внешний для хостераА и хостераБ, с возможностью переключения серверов. Скриптом конечно ) В случае фейла хостингА вы просто деплоитесь в хостингБ используя последние бэкапы и переключаетесь. Сервис работает, вы ждете пока вам ответит хостерА и затем, по возможности, восстанавливаете потерянную разницу в БД
Повторюсь, эта схема слегка избыточна. Возможно вы сможете найти хостера в ру который будет как "hetzner. 1200+ дней без перезагрузки" и хостингБ вам в принципе не понадобится.
Однако написать и оттестировать скрипты деплоя приложения и БД, регулярно тестировать восстановление данных - это шаги к быстрому восстановлению сервиса
полагаться на DNS = полагаться на всю цепочку DNS резолверов которая может участвовать в доставке изменений до клиента. (гугловый кеш, клаудфлейр, как самые популярные. Затем DNS провайдеров интернета, использующихся по умолчанию на многих клиентских устройствах, а сейчас еще, в связи с растущей популярностью средств обхода блокировок - даже локальные пользовательские DNS резолверы)
И никто не гарантирует что все настроено корректно, протухшие записи удаляются, TTL соблюдается именно тот который вы настроили у себя и тд и тп.
На вашем месте я бы все таки завязался на единую точку входа, но выбрал бы сервис, который обеспечивает достаточную надежность.
Например cloudflare (спрятать ваши два сервера за ним) или, если хочется именно российского, думаю, можно доверять Яндексу, если у них есть соответствующий сервис (network load balancer насколько я понял - для внутренних ресурсов в облаке)
Сделать самому high availbility очень сложно, а с репликацией базы еще сложнее. Поэтому да - просто выбрать надежного хостера для вебсервера, а если есть деньги - хостера, который дает готовые решения для этого.
Например, multi-availability zone architecture in AWS.
У вас неверная информация.
Я про "Перечитал много разной теории про балансировщиков, nginx, docker swarm и kubernetes и т.д. В таких вещах смущает что все равно есть какой-то центральный сервер или мастер-нода, которая рулит балансировкой или мониторит доступность нод/серверов. И если он не будет работать, то вообще ничег не будет работать.".
Есть балансировщики как услуга с высокой доступностью, за которой не нужно следить вам.
А в общем и целом рассуждать о построении прода и одновременно признавать, что вы "Сам в этом деле нуб" - это как то странно.
Средний
