forum.lissyara.su

вообще - это редкость, когда досят магистральное оборудование, потому, что ему, как правило пох на эти атаки (если это оборудование верно настроено)

ребята, отказоустойчивость - это дорогое в приямом смысле понятие.
понятие хостинг - растяжимое. Если топик стартер имеет ввиду какой-нибудь шаред, то я его разочарую
В общем случае хостинг - это набор услуг, таких как web,db,mail,ftp,dns etc.

Итак, некоторые постулаты (на мой вгляд)

понятие "отказоустойчивость" применимо к крупным и дорогим проектам. Очень часто сдесь отказоустойчивость складуется из многих звеньев (отказоуйсточивая база данных, отказоустойчивый веб сервис).
Кроме того, отказоустойчивость сама по себе не предполагает распределение разгрузки, не путать с loadbalansing.
Отказоусточивость означает что в любой момент времени одна из нод кластера может сдохнуть на неопределенное время. (Для любителей вариантов ДНС, при днс-лоад-балансинг N посетителей обслуживаются 2мя серверами, т.е. на каждый сервер приходится N/2 посетителей. Если 1ый сервер сдох, то на второй сервер вместо N/2 повалит N посетителей. Вопрос для смекалистых, что с ним произойдет? ответ: тоже что и с первым сервером. Часто так бывает. Для возразившых, что днс будет тупо отдавать умерший хост людям: пишутся сторонние скрипты, которые мониторят оба хоста, и в случае выпадания одного, правят зону, оставляя в ней только рабочей. зонерефреш с минимальными интервалами. Да есть такой вариант, иногда помогает, для своих задач.)

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

Основные спосробы решения проблемы синхронизации:
общие файловые системы, общие сетевые диски. В идеальном варианте часто - NAS,SAN.
Весьма популярны системы по типу drbd+heartbeat, drbd - общая файловая система между двумя серверами, увы только под линукс
nfs - ненадежно. Говорят еще есть кода - не пробовал.

Отсюда, варианты создания отказоустойчивой базы данных - это либо drbd + heartbeat on linux, либо репликация средствами WAL (write ahead log). (в контексте имеем в виду шардинг при росте обьемов базы данных, мультимастер и мастер-слев не в счет.) + скприты для поддержания этого в рабочем состоянии.
еще один вариант - rsync. Конечно, хуже чем drbd но кроссплатформенно - это плюс.

Веб сервисы синхронизируются напорядки проще, одними из вышеописанных средств.

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

Итоги:
топикстартеру определиться, какие цели он преследует и что он хочет сделать отказоустойчивым, и какие ресурсы для этого он планирует задействовать\потратить. Если вы не знаете, сколько 9ок после запятой вам нужно - то за отказоустойчивость говорить еще рано.

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

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

paix писал(а): еще один вариант - rsync. Конечно, хуже чем drbd но кроссплатформенно - это плюс.

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

_kirill_ писал(а):

paix писал(а): еще один вариант - rsync. Конечно, хуже чем drbd но кроссплатформенно - это плюс.

помоему рсинк работает как мастер-слэйв.. т.е. контент модифицироваццо может только на мастере,

не обязательно. Решается прикладными скриптами.
High aviability (postgresql) решение на базе heartbeat + rsync: http://www.taygeta.com/ha-postgresql.html
Правда до drbd это связке очень далеко. Слишком большие интервалы синхронизации...для базы данных 5 минут это очень много!

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

lissyara писал(а):по 4-му пункту - лучше разориться и купить HP со встроенным IP-KVM
ну и за доп порт доплатить хостеру. будет надёжней всего.

или IPMI

Я вернулся с отдыха. Щас все вдумичиво прочитаю и напишу ответ.

Возвращаюсь к теме.
Вобщем нужно сделать так, чтобы хостинг по возможности был доступен в режиме 27х7. Т.е. чтобы при падении основного веб сервера, работать продолжал второй.
Пока речь о балансировании нагрузки не ведется, т.к. посещаемость не будет огромной, но в будущем может понадобится.
Исходя из вышесказанных соображений склоняюсь к варианту с правкой ДНС зоны, т.к. в моем случае бюджет к тому же скромный. По поводу синхронизации нужно еще подумать и почитать. В общем-то может и устроит синхронизация раз в сутки подручными средствами.

правка DNS зон не пойдет
они долго расходяться
и каждый раз менять IDнтификатор это занадто

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

Планируется 2 машины. Далеко или близко они должны быть это как раз сейчас и нужно решить.
Вообще есть некоторая уверенность что резервный будет вообще не востребован при условии нормально сделанного основного. Но вот тем не менее говорят что нада

нужен условный кластер

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

а вот когда они будут рядом
в одном свитче
тогда можно что то думать

если принципиально нужно что бы они были далеко

тогда можно в DNS прописать два хоста
но тогда другая проблема может возникнуть
точная синхронизация данных(если это критично)

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

По сути дела данный метод включает в себя во первых практически удвоение существующего парка техники в минимальном случае плюс программное обеспечение которое позволяет централизованно управлять снапшотами различных уровней(полный и динамический.) и синхронный мирроринг при этом работая на основе виртуализации(не той о которой сча все говорят типа Xen итд.. а о виртуализации хранилищ информации).
Никакой синхрон баз и репликация стандартными их инструментами не даст эффекта 7x24.... Просто поверьте... видел как загибаются все эти репликации и синхронизации если сервис под большой нагрузкой....
Ну и конечно... никуда в таком случае от SAN-а не уйти....
Из того о чем я слышал на семинарах - технология FalconStor. Это не просто софт.. а программно аппаратный комплекс....

Если честно я не совсем понимаю в данном случае их объединять в кластер. По прикидкам там нагрука будет ниже средней и один более-менее нормальный сервер с ней справиться. Да и про второй сервер вопрос для меня спорный. По собственному опыту аптайм у мелких хостингов (во свяком случае которые приходится обслуживать) зачастую больше 30-50 дней. Ну а если и есть простой, то не более 1-2 часов за это время. Поэтому правильно комрад заметил, что оно дороже выйдет еще сервак держать.
Но дело в том что ну очень хочет поставить чел резервный И поэтому, имхо, он будет для удаленных бэкапов скорее всего использоваться и при необходимости его нужно задействовать вместо основного.

что скажут гуру о Xen на основе DRBD+LVM+Heartbeat. теоретически - гибко и красиво, практически еще не пробывал.
есть кто глубоко копал эту тему?

Если можно, хотелось бы слышать какие плюсы и минусы различных предлагаемых схем. Или иными словами, чего конкретно мы добиваемся (хотим добится) их применением? Т.к. отказоустойчивость понятие растяжимое и складывается из различных параметров.

Сколько должно быть девяток отказоустойчивости?

Если нужно поэкономить предлагаю такой вариант:

Ставится два сервера, на них nginx+apache+php-fastcgi или просто nginx-php-fastcgi - как удобнее.
Конфигурации серверов совершенно одинаковые, общее веб пространство синхронизируется вашим любимым инструментом... собственно чем угодно, хоть rsync раз в минуту в кроне.

Сервера имеют по две сетевухи, вторыми сетевухами они соеденины серой адресацией.

mysql реплицируется в master-mastrer на обоих серверах.

Оба сервероа будет играть роль "себя как Frontend, второй как бэкап и бэкенд".

nginx на Фронте балансирует нагрузку между локальной генерацией контента и бэкендом.

Пакет /usr/ports/net/wackamole занимается распределением обращения к адресам серверов и отказоустойчивостью.

Так на базе двух серверов получается кластер с 4 девятками точно + распределение нагрузки. Такой кластер убить нагрузкой будет сложно при наличии прямых рук. Единственная проблема это как всегда электропитание.

ЗЫ а DRBD на бсд работает кстати?

LMik писал(а):Сколько должно быть девяток отказоустойчивости?

Допустим аптайм 99,99% . Получается, грубо говоря, не более 5 мин в месяц простоя.

serge писал(а):

LMik писал(а):Сколько должно быть девяток отказоустойчивости?

Допустим аптайм 99,99% . Получается, грубо говоря, не более 5 мин в месяц простоя.

Смотри пост выше написал.

LMik писал(а):Если нужно поэкономить предлагаю такой вариант:
...

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

LMik писал(а): общее веб пространство синхронизируется вашим любимым инструментом... собственно чем угодно, хоть rsync раз в минуту в кроне.

А если синхронизация будет происходить больше минуты ??? Можно в этом случае налететь на некоторые кочки.
А если первый сервер просто был вырублен ? Чего и куда синхронизировать будем ?

mysql реплицируется в master-mastrer на обоих серверах.

Та же ситуация.

Вы в данном случае делаете одну и ту же ошибку. Вы не обеспечиваете отказоустоичивость и неубиваемость сервиса. Вы его просто дублируете. Но дублирование таким способом не предполагает 99.9999% доступности данных и сервисов.

Так на базе двух серверов получается кластер с 4 девятками точно + распределение нагрузки.

Тут математику надо вспомнить немного и понять что даже чисто теоретически 4 девятки не получается

Поправьте меня если я перегнул где то

1. Простой скрипт с лок файлом от дольшей синхронизации вас спасет элементрано... Если сервер вырублен ничего синхронизироваться не будет. Как включется получит порцию изменений.

2. Мускул аналогично. Просто каждый из серверов будет иметь свой мускул локальный для работы, а они будут иметь синхронизированную базу.

3. А как ещё достигается HA как не дублированием? Ну посчитайте если есть опыт и знания.

ПС: 4 девятки это 99.9900%

LMik писал(а):ЗЫ а DRBD на бсд работает кстати?

на сколько знаю - нет

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

2. Мускул аналогично. Просто каждый из серверов будет иметь свой мускул локальный для работы, а они будут иметь синхронизированную базу.

3. А как ещё достигается HA как не дублированием? Ну посчитайте если есть опыт и знания.

ПС: 4 девятки это 99.9900%

1. Во время синхронизации - лок. В это время сервак ложиться. Новый ессно работает но данные не имеют актуальной свежести.
2. Аналогично
3. Дублирование критично важных узлов - одна из мер достижения того чего вы хотите.

Ваши 4 девятки достижимы только в случае построения на основе общего хранилища данных + снапшоты и бэкап.
Что мы в этом случае получаем:
1. Не надо в общем случае синхронизитровать ни базы ни контент.. он общий для 2-х серверов..отваливается один - второй работает.
2. Всегда актуальный снапшот..если вдруг косяк пошел.
3. Бэкап еще никому не вредил
4. Централизованное управление и масштабирование системы !

Вот примерная схема(я не стал разрисовывать все подробно.. но суть ясна должна быть.)