Сервера в разных ДЦ разных провайдеров — как осуществить?

Question

[Салават Ситдиков]

Добрый день всем.


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


Что можете посоветовать в качестве решения этой проблемы?


Вариант с балансировкой nginx'a — понятен, но ведь на удаленных серверах необходимо еще держать и копию всех файлов. А бывает, что среди файлов — видео весом ~ 35-50 Мб.


Решение, которое мне представляется — это кластерные ФС. Но я не уверен, что думаю в верном направлении.


Если есть у кого опыт — буду признателен за советы и консультацию.

Comments

[Салават Ситдиков]

Дополню: задача — в случае падения одного из серверов — работу на себя должны взять другие.

Answer 1

[rukhem]

clusterFS это все очень медленно.
Мы сделали так — выделил 1 сервер как master-stat и на него выкладываются обновления.

Остальные stat сервера (в других дата-центрах) если локально не могут найти файл файл лезут на этот конкретный master-stat и скачивают недостающий файл:

set $root /opt/www/img.domain.com;

location / {
root $root;
try_files $uri @master-stat;
}

location @master-stat{
internal;
proxy_pass img.master-stat.domain.com;
proxy_set_header Host img.domain.com;
proxy_store on;
proxy_store_access user:rw group:rw all:r;
proxy_temp_path /opt/tmp;
root $root;
break;
}

Ну и раз в сутки с mster-stat rsync на все остальные, чтоб удалить ненужное и перелазить обновленные (редко но всеже надо).

Comments

[Салават Ситдиков]

А обновление кода? Хуками для коммита?

И правильно ли я понимаю, что приведенный конфиг — это конфиг nginx для stat серверов?

[rukhem]

да да простите, это nginx для stat серверов. так только статику автоматом раскладывать. и не думать отработал rsync Не отработал. nginx сам забирает файл которого нет. Тормозить будет только у первого посетителя.

Обновление кода — да хуками.

[rukhem]

Есть еще вариант такой логики:
если локально нет файла — пройтись по остальным stat серверам и попробовать забрать его оттуда. Но отказались от этой схемы. Она нужна когда обновления заливают в разные stat. а у нас сложилось так что все равно заливают в один.

[Салават Ситдиков]

А как живется с «тяжелым» контентом?

[rukhem]

Для тяжелого не подходит. Думаю максимум 10М.
Все что больше имхо надо выкладывать сразу на все stat сервера.

А мелочь, всякие картинки — просто летает. И голова не болит.

Эта схема реализована в нескольких онлайн газетах и онлайн магазинах — где основная отдача статика. Прекрасно работает.

[Салават Ситдиков]

У нас газета. С изображениями я уже представил profit. А вот что делать с видео, хранящемся на серверах — понятия не имею. По CDN — дорого выходит. Либо просто использовать отдельный сервер под это дело.

[rukhem]

разливать видео сразу на несколько серверов.
либо заливать на один а потом принудительно дергать на каждом stat-01.domain.com/video/aaaa.avi чтоб nginx его запнул с img.master-stat.domain.com

[Салават Ситдиков]

rukhem, похоже что только так. Просто рассматриваю способы — без внесения изменений в исходный код ПО.

Answer 2

[Alexander Kouznetsov]

Собственно я не хотел бы привязываться в ответе к конкретным реализациям (nginx, apache, etc), т.к. сам сейчас работаю в основном с Windows Azure (по нему могу и конкретно с реализацией подсказать).
По задачам:
1. Нужно, чтобы какой-то из серверов откликнулся на запрос, даже при отказе одного из них — это делается фокусами с DNS
2. Нужно, чтобы копия UGC, была доступна с других серверов например — загруженных файлов, особенно если они большие.
Вот тут я бы делал примерно следующее: сервер получивший файл, сообщает другим серверам, что у него есть новый файл. Те складывают это знание себе в базу. При запросе пользователем этого файла с другого сервера — осуществляется загрузка файлика на сервер, ставим отметку, что фай2л у нас теперь есть и отдаем его пользователю.
Если речь идет, допустим, о блог записях — то проще при получение записи сразу реплицировать ее на другие сервера.

Comments

[Alexander Kouznetsov]

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

[script88]

Предложенный Вами вариант, явно раз в 100 уступает любой кластерной FS + к этому, все выше описанное нужно будет реализовать своими силами! На что требуется не только время но и опыт

[Alexander Kouznetsov]

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

[Салават Ситдиков]

unconnected, script88 — Хочу отметить, что основная задача, это обеспечить бесперебойную работу серверов в случае выхода одного из них из строя (поэтому и разделение на разные ДЦ, разные хостинг-провайдеры). В случае выхода всех N серверов, можно считать, что апокалипсис и отправляться на заслуженный отдых.

[Alexander Kouznetsov]

А как называется решение доступное, «в случае выхода всех N серверов»? Я такое очень хочу :) Возьму сразу два. А если еще и без каналов связи будут доступны — все три :-D

[Владислав Росс]

Не забудьте, что надо еще придумать как раскидывать пользователей по этим серверам. Т.е. они должны иметь одно и тоже доменное имя. И у пользователей не должна рваться сессия, если их перекинет на другую ноду.
Идеальный вариант все-таки своя серверная, два интернет-канала, несколько серверов и общая отказоустойчивая полка. А территориально распределенный кластер, имхо, гораздо сложнее сделать.

[Alexander Kouznetsov]

Еще и сессию отказоустойчивой делать? Зачем?! Сервера не каждый день валятся — введет еще раз логин-пароль. А своя серверная не надежней одного ДЦ получится.

[Салават Ситдиков]

gag_fenix, я соглашусь с unconnected, своя серверная — не вариант, особенно в нашем случае, когда первостепенная задача — оградиться от проблемы выхода из строя ДЦ, серверов и так далее.
По поводу раскидывания пользователей и сессий — ip_hash на nginx и балансировка им же.

[Владислав Росс]

Я не совсем ясно выразился. Своя серверная не надежней, а проще :)

Answer 3

[Alexander Kouznetsov]

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

Я бы строил механизм репликаций.

Comments

[Салават Ситдиков]

Я вас правильно понял, что вы имеете ввиду статику в CDN, а backend'ы оставить как есть — точнее балансировку nginx'a как раз использовать?

По поводу механизмов репликаций — относительно к БД представление и небольшой опыт имеется, но вот чтобы скрипты реплицировать между серверами разными — нет.

[script88]

Я правильно понял, что под скриптами имеется ввиду механизм который будет обращаться к N-ому количеству БД?

[Салават Ситдиков]

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

[script88]

Для более быстрой и гибкой синхронизации можете воспользоваться утилитой csynс2. Конфиг можно поделить на части, и запускать с разной периодичностью.
Опять таки, надо понимать что тут контроль нужен над каждым сервисом отдельно, ибо если упадет на 1 сервере mysql или же memcached, то уже надо надо переводить всех клиентов на 2 других сервера.

[Салават Ситдиков]

script88, по поводу БД — смотрю в сторону решения репликацией master-master от Percona, либо master-master (active-passive).
С мемкешед — пока даже не представляю решения.

[script88]

С мемкешед — пока даже не представляю решения.

А что мешает сделать такой же кластер для memcached сервиса?!

[Салават Ситдиков]

Этот вопрос еще не изучал, если честно.

Answer 4

[Салават Ситдиков]

gag_fenix, мы ищем надежное решение :) Спасибо!
P.S. Промахнулся, ответ на комментарий

Answer 5

[polyakstar]

Виртуализация + репликация между ДЦ средствами СХД.
дорого.

Comments

[Салават Ситдиков]

ДЦ не от одного хостинг-провайдера. СХД в таких рамках так же эффективно будет?

[polyakstar]

Тут важно не столько кому принадлежит ДЦ, сколько провайдеры, какие каналы между ДЦ они могут предоставить и за какие деньги

Answer 6

[rukhem]

Есть еще вариант такой логики:
если локально нет файла — пройтись по остальным stat серверам и попробовать забрать его оттуда. Но отказались от этой схемы. Она нужна когда обновления заливают в разные stat. а у нас сложилось так что все равно заливают в один.

Comments

[rukhem]

промазал сори.

Answer 7

[CLaiN]

Ну например на винде есть DFSR, который все вопросы репликации файлов берет на себя. + RR в днс для отказоустойчивости между цодами. Репликация бд зависит от решения, но обычно достаточно мастер-слейв репликации с витнесом в третьем цоде.

Подозреваю, что в никсах есть свои похожие механизмы репликации файлов.