LINUX.ORG.RU
решено ФорумAdmin

Отказоустойчивые решения

 


3

3

Подскажите, какие существуют на данный момент отказоустойчивые решения для веб-приложений? Архитектура приложения на данный момент такая - клиент (веб и десктопный) - nginx (отдельный виртуалхост с поддоменом на логическую группу клиентов) - tomcat (одно здоровенное ява-приложение на спринге) - mysql (отдельная база на ту же логическую группу клиентов плюс общесистемная база). Сейчас всё довольно бодро крутится на одном medium-инстансе на амазоне плюс small-инстанс rds (даже без multi-az). Планировалось после раскрутки проекта нарастить мощность и использовать некоторые фичи амазона вроде балансировщика и route 53, но законы и курс доллара вынуждают переезжать в Россию, где хостингов с подобной инфраструктурой нет. Так что надо изобразить что-то минимальное самому.

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

Вариант 2. Round-robin на днсах. Два равноценных сервера в разных датацентрах, mysql в режиме мастер-мастер либо же galera с арбитром. В случае падения одного сервера или датацентра опять слушаем ругань клиентов, но уже вдвое меньше. Опять же, до тех пор, пока не обновятся днсы либо пока не воспрянет упавший сервер/датацентр. Из минусов ещё и то, что само приложение не рассчитано и не тестировалось на параллельную работу, возникают потери сессий и тому подобное непотребство. Но это можно минимально пофиксить, отправляя на nginx'ах одних и тех же клиентов на один и тот же апстрим. Ну и скорость работы при синхронной репликации будет заметно ниже.

Вариант 3, вариация классического. Добавляем перед основным сервером парочку фронт-эндов, этакий недо-cdn. В это случае, имея один сервер приложения в горячем резерве, простой можно свести ко времени таймаута ожидания ответа от апстрима. Но если падает фронт-энд, всё опять же сводится к первому варианту.

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

UPD. Работал всего с двумя российскими хоситнг-провайдерами, у обоих регулярно падала маршрутизация (это не считая иных проблем, напрямую к теме не относящихся).

★★★

по поводу серверов - копай в сторону heartbeat, corosync, pacemaker, GFS, GlusterFS, MySQL Cluster. Есть довольно забавная консоль LCMC, но она в продакшн пока слишком глючная. Как тест - подними две виртуалки и урони одну. Поднимать сервак руками смысла нет.

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

upcFrost ★★★★★ ()
Последнее исправление: upcFrost (всего исправлений: 2)

вынуждают переезжать в Россию, где хостингов с подобной инфраструктурой нет.

Ну подними сам на OpenStack, если так хочется.

AnDoR ★★★★★ ()
Ответ на: комментарий от upcFrost

ну в любом случае лучше использовать 3 сервера вместо 2х. а потом 5 вместо 3х. потом 8 и так далее.

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

Nurmukh ★★★ ()
Ответ на: комментарий от Nurmukh

когда второй не поднял это мелочи жизни. Хуже когда второй поднялся, а первый не лег (master-slave, потеря связи между нодами). Далее имеем фееричный split-brain. Но да, 3 сервера разумеется лучше двух. Тут уже финансы, возможности и т.п.

upcFrost ★★★★★ ()
Ответ на: комментарий от upcFrost

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

Nurmukh ★★★ ()
Ответ на: комментарий от Nurmukh

у меня еще было что если во время такого «прилета» намекнуть кто именно не дал бабки на еще один сервак - количество ненависти увеличивается раз в 5

upcFrost ★★★★★ ()
Ответ на: комментарий от upcFrost

увеличивается раз в 5

Точно, теперь я такие моменты на бумаге пишу или в почте, с обоснованием и рисками.

petav ★★★★★ ()
Ответ на: комментарий от petav

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

upcFrost ★★★★★ ()

Единственное «отказоустойчивое решение», которое удалось заставить работать и которое действительно отказоустойчивое - виртуалка под Xen + Remus на двух железках. Да и то, оно толком не доделано пока как следует, до сих пор какие-то проблемы при восстановлении работоспособности упавшей железки и перекидывании виртуального хоста обратно на неё. Но вообще таки да, железку, на которой всё работает выдёргиваешь из розетки, а из внешних проявлений сего события - только задержка в 100-200мс при ответе на запросы. Никаких потерянных пакетов и соединений, всё продолжает непрерывно работать уже на другой железке. Клиенты не заметят вообще ничего.

Всё остальное на звание «отказоустойчивого решения» не тянет вообще никак, ибо не обеспечивает 100% непрерывности работы, да ещё и сделано как-то уродливо и погано. Оно либо называться должно по-другому, типа «набор костылей чтобы типа как бы сервис поменьше лежал, вдруг никто не заметит», либо оное следует закопать, чтоб в заблуждение не вводило, и внимание не отжирало. Remus надо доделывать, а не вот эти все костыли костылять.

Stanson ★★★★★ ()
Ответ на: комментарий от Nurmukh

Разумеется, про три сервера я в курсе, та же Galera требует арбитра. Просто бывает всякое, третий сервер тоже может упасть.

lizard ★★★ ()
Ответ на: комментарий от Stanson

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

lizard ★★★ ()
Ответ на: комментарий от lizard

Там с виртуализацией всё просто, на самом деле. Самое сложное организовать максимально широкий прямой канал между железками и подобрать оптимальную частоту Remus'а. Вообще, производительность падает чуть меньше чем в 2 раза по сравнению с обычной работой на одной железке - это собственно и есть главная плата за отказоустойчивость.

Stanson ★★★★★ ()
Ответ на: комментарий от upcFrost

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

Я составляю акт, о поломке и утверждаю, что для устранения будущих поломок необходима замена узла так как (тут техническое обоснование). На этом документе ставят клеймо «Утверждаю» или «Отклонить», будущие поломки и простой на кол-во рублей, прикрываем отказом в замене сбойного блока.

А телефон и почта, если это не внутренний документооборот, это все нет то.

petav ★★★★★ ()
Ответ на: комментарий от petav

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

upcFrost ★★★★★ ()
Ответ на: комментарий от petav

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

upcFrost ★★★★★ ()
Ответ на: комментарий от upcFrost

количество ненависти увеличивается раз в 5

man 'стратагема «покажи врагу дорогу к жизни»'

zolden ★★★★★ ()

Вариант №2 это решение для высокой нагрузки, не для отказоустойчивости.

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

ya-betmen ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.