Архитектура Web-сервера(ов)

[Mikav]

Есть задача обеспечить функционирование 3-5 сайтов с посещаемостью около 10000 хостов в день. VPS использовать не хочется, т.е. нежен свой сервер.
Бюджет теоретически неограничен. Самый важный параметр - надежность. Простой всего проекта в день обойдется где-то от 10к баксов убытков.
Мне видится такой способ организации надежности - покупка 4 серверов которые настраиваются на полное клонирование размещаемой информации, 2 сервера размещаются на одной площадке, 2 сервера на другой. В DNS прописываются 2 IP шника, таким образом, чтобы половина запросов отсылалась на одну площадку к одному серверу, а вторая половина соотвественно на другую. Вторые сервера на каждой из площадок простаивают и ждут пока сломаются первые сервера. В случае поломки первого сервера на любой из площадок, быстренько (вручную, или можно автоматически?) подменяется ИПшник второго сервера этой площадки на ИПшник первого. Если же падает площадка у хостера, то быстро (вручную) меняется DNS - оставляется только IPшник работающей площадки. Таким образом в случае если ломается один сервер на одной из площадок мы теряем посетителей (точнее половину) всего 5-10 минут. Если же падает целая площадка, то мы теряем посетителей (опять же - половину) на время изменения DNS (ХЗ сколько).

Затраты на каждый сервер примерно 2к баксов (двухъядерник с САТА, 1U). Размещение каждого сервера - 50 баксов. Получается на покупку меньше 10к, ежемесячно 200 баксов.

Стоит использовать такую архитектуру серверов или есть что-то более надежное?

[a_shats]

Сделаю copy-paste своего ответа с forum.ixbt.com

Классическое решение - файловерный кластер на разные площадки (минимум 2), с зеркалированием дисковых. IP - не серверов, но - кластерный. Стоит недешево (минимум 4 сервера и 2 дисковых с опцией зеркалирования средствами контроллера, ну и нехилый канал между площадками надо), цена вопроса - примерно в 20-25 раз больше указанной Вами в затратах

И это только за железо, без учета стоимости аренды или создания каналов между площадками

[Oleg2]

Мне видится такой способ организации надежности - покупка 4 серверов которые настраиваются на полное клонирование размещаемой информации, 2 сервера размещаются на одной площадке, 2 сервера на другой. В DNS прописываются 2 IP шника, таким образом, чтобы половина запросов отсылалась на одну площадку к одному серверу, а вторая половина соотвественно на другую. Вторые сервера на каждой из площадок простаивают и ждут пока сломаются первые сервера. В случае поломки первого сервера на любой из площадок, быстренько (вручную, или можно автоматически?) подменяется ИПшник второго сервера этой площадки на ИПшник первого. Если же падает площадка у хостера, то быстро (вручную) меняется DNS - оставляется только IPшник работающей площадки. Таким образом в случае если ломается один сервер на одной из площадок мы теряем посетителей (точнее половину) всего 5-10 минут. Если же падает целая площадка, то мы теряем посетителей (опять же - половину) на время изменения DNS (ХЗ сколько).

Мне кажется, что из-за кэширования DNS запросов локальными серверами, даже после обновления DNS записи, пользователи будут продолжать ломиться на старый IP адрес. По крайней мере до истечения времени TTL  в записи доменной зоны. IMHO, конечно.

[Mikav]

Ну 200 тыс. долларов - это перебор. Если рассматривать что система проработает лет 6, то за 6 лет за эти деньги сайт может целых 20 дней быть сломан, а это довольно много. Мне кажется с моим бюджетом вероятность того что сайт будет из 2000 дней - 20 недоступен ооочень мала.

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

Меня больше интересует есть ли средства позволяющие автоматически поднимать на сервере нужный IP в случае падения первого сервера?

[Oleg2]

Ну 200 тыс. долларов - это перебор. Если рассматривать что система проработает лет 6, то за 6 лет за эти деньги сайт может целых 20 дней быть сломан, а это довольно много. Мне кажется с моим бюджетом вероятность того что сайт будет из 2000 дней - 20 недоступен ооочень мала.

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

Меня больше интересует есть ли средства позволяющие автоматически поднимать на сервере нужный IP в случае падения первого сервера?

Мне кажется, что  если не использовать полноценное кластерное решение, то велика вероятность схлопотать split brain состояние (т.е. когда каждая нода считает себя единственной выжившей).
К тому же, если серверы стоят на разных площадках, то вариант с подъёмом IP адреса умершего сервера на интерфейсе выжившего не прокатит - ибо маршрутизаторы провайдера об этом ничего не будут знать и он останется недоступным для внешнего мира. ИМХО, конечно.

А затея с редактированием DNS "на лету" выглядит немного странно - она прокатывает, только если Primary DNS будет находиться где то в третьем месте. Как то косенько всё выгладит....

[def]

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

2Oleg2: что именно Вы называете "полноценным кластерным решением"?

[Oleg2]

2Oleg2: что именно Вы называете "полноценным кластерным решением"?

то, о чём выше упоминали коллеги.
Специализированный софт и зеркалированное хранилище данных.

[Mikav]

Хм. А ваша контора занимается подобного рода услугами? Может быть сможете предложить что-то конкретное (интересует готовое решение, с настроенным софтом)

[def]

то, о чём выше упоминали коллеги.
Специализированный софт и зеркалированное хранилище данных.

Как вы будете синхронизировать информацию 2х дисковых массивов через публичную сеть (причём на совсем не гарантированной полосе пропускания)? А если даже сможете, стоит ли оно того, когда есть много других способов? А каким способом "решение" может раскидать нагрузку в географически распределённой системе?

Я к чему ворчу то: просто Вы на многие задачи предлагаете людям какие-то громоздкие решения. В данном случае это вообще никак задачу не решает.
Шла бы речь про Oracle в 2х собственных ДЦ, соединённые своей оптикой - тогда это единственный разумный вариант.

2автор топика:
проблема синхронизации решается под конкретную задачу.
По поводу балансировки: есть удачный опыт эксплуатации следующей схемы.
В третьем месте ставится одна из реализаций DNS сервера, умеющего проверять статусы сервисов и на основании их доступности отвечать на запросы (есть как патчи к bind,  так и другие решения). TTL выставляется в 10 секунд (нагрузка конечно будет заметна, но её не так трудно побороть). Никто не спорит, что есть достаточно много кэширующих серверов, не смотрящих на TTL, но их число минимально. В каждом ДЦ по паре серверов. В пределах одного сегмента можно легко использовать миграцию IP или даже ARP балансировку.
Кроме того, у http протокола есть и другие механизмы перекидывания нагрузки (редиректы, проксирование). Вобщем вариантов много.

Это навскидку, в качестве альтернативы предложенному ранее варианту.
PS. Ничего личного =) Альтернатива должна быть.

[a_shats]

Как вы будете синхронизировать информацию 2х дисковых массивов через публичную сеть (причём на совсем не гарантированной полосе пропускания)?

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

А каким способом "решение" может раскидать нагрузку в географически распределённой системе?

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

[a_shats]

Я к чему ворчу то: просто Вы на многие задачи предлагаете людям какие-то громоздкие решения. В данном случае это вообще никак задачу не решает.
Шла бы речь про Oracle в 2х собственных ДЦ, соединённые своей оптикой - тогда это единственный разумный вариант.

2автор топика:
проблема синхронизации решается под конкретную задачу.
По поводу балансировки: есть удачный опыт эксплуатации следующей схемы.
В третьем месте ставится одна из реализаций DNS сервера, умеющего проверять статусы сервисов и на основании их доступности отвечать на запросы (есть как патчи к bind,  так и другие решения). TTL выставляется в 10 секунд (нагрузка конечно будет заметна, но её не так трудно побороть). Никто не спорит, что есть достаточно много кэширующих серверов, не смотрящих на TTL, но их число минимально. В каждом ДЦ по паре серверов. В пределах одного сегмента можно легко использовать миграцию IP или даже ARP балансировку.
Кроме того, у http протокола есть и другие механизмы перекидывания нагрузки (редиректы, проксирование). Вобщем вариантов много.

Это навскидку, в качестве альтернативы предложенному ранее варианту.
PS. Ничего личного =) Альтернатива должна быть.

А теперь расстреляем Ваш вариант  :D
1. Так много кэширующих DNS, не смотрящих на TTL, или таки их число минимально ?
2. Как будем обеспечивать один и тот же контент на все серверы ?

[def]

А теперь расстреляем Ваш вариант  :D
1. Так много кэширующих DNS, не смотрящих на TTL, или таки их число минимально ?
2. Как будем обеспечивать один и тот же контент на все серверы ?

1) Навскидку - менее 5%
2) Web-приложение должно знать, что у неё 2 хранилища. Транзакция (операция записи) считается удачной при записи на все нужные ноды. Возможно так же организовать некоторый пул операций записи.
Данный вариант мне видится более удачный, чем тупое зеркалирование информации, так как на уровне приложения мы можем отследить синхронность данных.

PS. Умная балансировка нагрузки (с мониторингом нод) тоже является отказоустойчивой.

Погрешность ДНС балансировки можно избежать получением собсвенной AS и балансировкой на уровне роутинга=)