Форум компании ITRM

Отправка сообщения

Вы не вошли на форум, сообщение будет отправлено анонимно.

Форум:

Отказоустойчивые системы

Заголовок:

Иконка сообщения:

Нет иконки

Форматирования:

Текст:

Параметры форума:
HTML - выключен
BBcode - включен
Картинки - выключены
Смайлики - выключены
Период возможности редактирования: Неограниченно

[quote title=sergey писал(а) Вск, 25 Апрель 2010 15:42]ну, географически распределенный кластер - это отдельная песня. если позволяет бюджет, то на каждом сайте нужно делать свой кластер, либо ставить фронтэнд-прокси, который будет быстрее реагировать на отказ бэкендов и проксировать запросы на живой сайт пока не обновятся DNS.

т.о. схема может быть такой:
site1
-----
proxyA + proxyB -> backend1..N

site2
-----
proxyA + proxyB -> backend1..N

прокси дублируют друг друга и могут перехватить разделяемые ip-адреса при выпадении соседа (например, с помощью heartbeat). если отваливаются backend'ы (которых, по идее, должно быть несколько), то запросы можно отправлять на второй сайт. DNS отдает А-записи на оба сайта (в засимости от задачи, можно по разному отдавать), если сайт ушел в даун, то отдаем записи живого. это - общее решение, в зависимости от задач и средств можно варьировать состав схемы.

что касается корневых DNS, то ты что-то путаешь - корневые сервера держат лишь NS-записи top-level доменов. поэтому проблемы с медленными DNS находятся в доступной зоне ответственности - сколько нужно, столько в TTL и прописывается.[/quote]

Пожалуйста, введите код подтверждения, который вы видите ниже:

На изображении нет цифр 0 и 1.
      

Параметры:

Просмотр темы

Re: Отказоустойчивость

Срд, 28 Апрель 2010 09:50

sergey

распространенная архитектура

Re: Отказоустойчивость

Втр, 27 Апрель 2010 19:31

exist

Что скажете по поводу схемы во вложении?

Вложение: отказоустойчивость.png
(Размер: 56.58KB, Загружено 1627 раз)

Re: Отказоустойчивость

Втр, 27 Апрель 2010 12:42

sergey

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

PS. да, живая миграция между железными нодами в основных системах виртуализации есть, но опять же - расстояние и трафик!

Re: Отказоустойчивость

Пнд, 26 Апрель 2010 20:53

exist

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

Re: Отказоустойчивость

Вск, 25 Апрель 2010 15:42

sergey

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

т.о. схема может быть такой:
site1
-----
proxyA + proxyB -> backend1..N

site2
-----
proxyA + proxyB -> backend1..N

прокси дублируют друг друга и могут перехватить разделяемые ip-адреса при выпадении соседа (например, с помощью heartbeat). если отваливаются backend'ы (которых, по идее, должно быть несколько), то запросы можно отправлять на второй сайт. DNS отдает А-записи на оба сайта (в засимости от задачи, можно по разному отдавать), если сайт ушел в даун, то отдаем записи живого. это - общее решение, в зависимости от задач и средств можно варьировать состав схемы.

что касается корневых DNS, то ты что-то путаешь - корневые сервера держат лишь NS-записи top-level доменов. поэтому проблемы с медленными DNS находятся в доступной зоне ответственности - сколько нужно, столько в TTL и прописывается.

Re: Отказоустойчивость

Сбт, 24 Апрель 2010 20:56

exist

Репликация базы - согласен, rsync для остального контента, как быть с ДНС?

Проблема в том, что если сервера расположены в различных сетях, то надо выдать как можно быстрее информацию корневым ДНС-серверам о смене А-записи, в случае возникновения проблем на одном из серверов. А корневые бывают порой довольно неторопливы. Может быть выход в максимальном уменьшении TTL для А-записей?

А какое мнение по поводу использования nginx для решения этой проблемы?

Re: Отказоустойчивость

Чтв, 22 Апрель 2010 21:44

sergey

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

Ну например, для сайтов на mysql+php нужно будет обеспечить репликацию как БД mysql, так и файлов (тот самый контент, а также, например, сессионные файлы). Если первое более-менее надежно может быть сделано встроенными средствами, то со вторым придется городить костыли: SAN, решения типа drbd или простой rsync. Соответственно, отказоустойчивость будет довольно относительная - если основная нода упадет, то сервис будет поднят на резервной ноде.

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

Отказоустойчивость веб-сервисов

Чтв, 22 Апрель 2010 18:37

exist

Мне интересно ваше мнение, как добиться отказоустойчивости веб-сервисов.

Понятно из чего состоит стандартный веб-сервис - это:
- Веб-сервер
- База данных
- ДНС
- Контент

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

Какие будут еще мысли? Smile