Как сделать доступным интернет проект 24/7?

Question

[lexstile]

Провайдер: reg ru
Проблема хостинга: периодически (раз в 1-3 месяца) проводятся технические работы и сервер выключается на 2-4 часа.
Написал в поддержку поводу VPS: сказали, что переход на VPS не решит проблему и технические работы также могут производиться. Ответили лишь тем, что переход на выделенный сервер решит проблему, там я сам себе хозяин - делаю, что и когда захочу.

Но возникает вопрос, я не поверю, что сервер никогда не нужно будет перезагружать. Рано или поздно это потребуется и проект отвалится на 30-60 секунд.

Как можно решить подобную проблему, чтобы проект работал всегда?

Comments

[Сергей Соколов]

а что за проект? Статичный HTML, или там WebSocket'ы стримят потоки данных?

[lexstile]

Сергей Соколов, без сокетов, но есть SSE.
Система управления заказами для бизнеса.

Answer 1

[Drno]

Ну в целом сервер ненадо перезагружать, если только он не завис намертво. Да и есть ли смысл платить x2 а то и x3 каждый месяц из-за простоя в 60 секунд?

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

Comments

[lexstile]

Благодарю за ответ.
Соглашусь, что стоит 2 раза подумать, нужно ли это.
Если с размещением FE/BE на втором сервере все понятно, то как быть с БД?
Как избежать рассинхронизации?

[Drno]

lexstile, ну БД как обычно делается Мейн и реплика... они синхронятся фактически в релтайме

В целом, по моему опыту, у меня за 3 года своего сервера на хетзннер(железного) ни разу не было чтобы доступ пропадал полностью. Было что отключалось резервное питание на 1 из 2х БП, было что канал станавился узким, когда работы были, но чтоб полностью....

Год как на селектел переехали, вроде пока тоже проблем нету таких.

[Василий Банников]

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

[Herest]

Важное уточнение!
Делая DNS запрос, клиент получает не один, а сразу весь список доступных IP адресов.

root@vps:~# resolvectl query vk.com
        93.186.225.208
        87.240.190.78
        87.240.190.72
        87.240.190.67
        87.240.137.158
        87.240.139.194

И если вдруг по первому в списке IP адресу сервер не отвечает, то браузер автоматически попробует подключиться по второму адресу. Это самая простая отказоустойчивость, которую вообще только можно реализовать. Но для этого нужно иметь от 2-х и более рабочих копий вашего сайта под разными IP адресами. А чтобы все клиенты не ломились только в одну калитку, используется DNS балансировщик Round-robin, когда список адресов циклически перебирается и у разных пользователей на первом месте будут разные IP.

[mayton2019]

Herest, про DNS можно говорить если рассуждать только о физических отказах. Помимо этого бывают еще Blue-Green deployments. А это - тоже часть процесса 24/7.

[Herest]

mayton2019, безусловно, это так, но автору вопроса будет достаточно и простого DNS, потому что это хостинг провайдер выключает его сервер. А Blue-Green deployments нужен, только если ты сам вдруг накосячил на своём сервере и надо быстро сделать откат к рабочему состоянию.

Answer 2

[Vitaly Karasik]

Когда говорят о high availability, обычно ее выражают в процентах - 99%, 99.9, и так до 99.999%.
Если коротко, то чем больше, тем намного дороже. Факт, что даже Гугл, Фейсбук, которые вкладывают миллиарды, не могут обеспечить 100% своим сервисам. Поэтому советую оценить, какой уровень high availability вам нужен, и сколько вы готовы в это вкладывать.
С технической точки зрения - см. мой ответ https://qna.habr.com/q/760831#answer_1607711

Comments

[mayton2019]

Я не знаю как мерять доступность сервиса google. У него практически нет единой точки отказа. Возможно падают какие-то региональные dns или гейты но завалить гугл так-же технически сложно как и отключить мобильную связь по всей планете. Ну а чтоб страховаться от патчей - используют различные стратегии типа Blue-Green.

[Vitaly Karasik]

mayton2019, Google - это сотни разных сервисов, бегущих на десятках датацентров по всему миру. И разумеется, у них куча стратегий, методов и систем для обеспечения HA.
И все же - https://www.computerworld.com/article/2496273/rece...
https://en.wikipedia.org/wiki/Google_services_outa....

То же самое верно для AWS и прочих гигантов - 100% нет ни у кого.

[mayton2019]

Vitaly Karasik, мне борьба с процентами напоминает борьбу с зайцами в троллейбусах. Если хотим поймать вообще всех - то транспорт просто станет невыгодным. Надо наверное остановиться на каком-то разумном числе и сказать что ... вот так вот. Дальше мы просто не попрём. Идеализм граничит с идиотизмом и потерей экономических смыслов.

Да и как можно говорить о постоянном присутствии сервиса когда природа например нам подкидывает сюрпризы. Но наводнения. То цунами. Я вот замечаю что мобильная связь становится многократно хуже если дождь или туман.

[Vitaly Karasik]

mayton2019, Абсолютно точно - про это я и написал в своем ответе. Как и всегда, архитектура - это искусство компромисса. Между надежностью и стоимостью, между безопасностью и usability, качеством продукта и временем разработки и т.д.

Answer 3

[Griboks]

Специально для вас придумали облака. Там всё само за вас перезагружается и балансируется. От вас требуется только грамотно настроить конфигурацию.

Единственный нюанс: вместо перезагрузки конкретно вашего сервиса вы поднимаете другой экземпляр (инстанс) и указывается облаку, чтобы новый трафик отправлялся туда. Когда последний запрос на старом инстансе обработался, он выключается.

Answer 4

[Кирилл Горелов]

Что-то какая-то ерунда......

Тут дело не в балансировщике или high availability и не в SLA, а в провайдере.
Я бы от такого бежал. Сам сидел несколько лет на vps и на хостинге, никаких проблем с доступностью из-за провайдера не было.
Смени провайдера....

Answer 5

[mayton2019]

Обычно ставят умный балансировщик нагрузки который в час Х просто подменяет трафик.

Comments

[lexstile]

Спасибо за ответ.
А можете, пожалуйста, чуть подробнее описать или дополнить ответ ссылкой, чтобы посмотреть принцип работы?

[mayton2019]

AWS продает эту услугу под названием ApiGateway https://aws.amazon.com/ru/api-gateway/

У других поставщиков Azure/GCP облаков тоже наверное есть ее аналог.

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

Answer 6

[d-stream]

Ну обычно во-первых надо начать поиски более другого хостера.
Потом (если этого будет мало) - арендовать у хостера несколько виртуалок и сервис балансировки
Потом смотреть в сторону нескольких хостеров и балансировку осуществлять третьей стороной между ними
Потом озаботится вопросом близости данных к получателям и задействовать cdn
Ну и потом уже начать размещать свои cache-servers в центрах обмена трафиком и у крупных провайдеров

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

Answer 7

[Дмитрий X]

Я поставил себе дома сервер, и купил ip. Всё работает круглые сутки, если свет (гады) не отключают.

Comments

[d'Ivan]

Ага. Еще UPS и бесперебойную линию связи.

[Дмитрий X]

Román Mirilaczvili, От упсу толку нет. О держит от силы 3 минуты. Поэтому я его не покупал. Вместо этого поставил защиту от перепадов в сети. Линия связи и так почти бесперебойная. Перебои бывают 2-3 раза в год.