Отказоустойчивый серверный комплекс.
Появилась задача сделать максимально отказоустойчивый серверный комлекс.
На данный момент есть н-ое кол-во серверов, на них крутятся нужные сервисы и т.п., делается бэкап бакулой, восстановить на голое железо- дело пары часов, но теперь это стало неприемлимо.
Задача: сделать так чтобы при сбое 1-й или нескольких машин сервисы продолжали быть доступны юзерам.
Первое что пришло на ум - это сделать кластер на openmosix, поставить на него XEN и все текущие сервера сделать виртуальными машинами.
Но возникает вопрос: как с распараллеливанием у XEN?
Про ксен читал, что у него есть возможность живой миграции на новую физическую машину, но проблема в том, что это делается вроде как только по специальной команде...
Вообщем помогайте, может, кто решал такие проблемы...
- Для комментирования войдите или зарегистрируйтесь
1 юзанье
1 юзанье мозикса и ксен здесь не адекватно
2 тут те нужен актив актив ha класетер => курим про drbd heartbeat и прочие вещи не забывая про кластерные параллельные фс
___________________________________________
Gentoo GNU/Linux 2.6.26 GCC 4.3.1
Working on Gentoo for iPAQ hx4700 :-)
Если у вас компьютер с Windows, есть два выхода: выбросить компьютер в форточку или выбросить форточки с компьютера
Спасибо, пока
Первичную инфу покурил... Понял, что мне нужна обоюдная поглощающая конфигурация, где все узлы выполняют (перемещаемую) работу повышенной готовности. Возник вопрос, от недостатка информации, наверное, при отказе 1 узла, процессы будут перемещены с сохранением айпишеков? Просто у меня и ДМЗ есть и сервисы чисто внутренние...
эм...ну это как
эм...ну это как настроишь есть такая штука называется cluster ip
курить ее =)
___________________________________________
Gentoo GNU/Linux 2.6.26 GCC 4.3.1
Working on Gentoo for iPAQ hx4700 :-)
Если у вас компьютер с Windows, есть два выхода: выбросить компьютер в форточку или выбросить форточки с компьютера
Кстати, почему
Кстати, почему юзанье мосикса неадекватно?
openmosix уже давно
openmosix уже давно мертв
mosix не для этого =)
___________________________________________
Gentoo GNU/Linux 2.6.26 GCC 4.3.1
Working on Gentoo for iPAQ hx4700 :-)
Если у вас компьютер с Windows, есть два выхода: выбросить компьютер в форточку или выбросить форточки с компьютера
Пнятненько... А
Пнятненько...
А почему XEN не покатит, т.е. чтобы heartbeat перезапускал не сервис на резервной тачке, а XEN-домен?
ну =) а чем это
ну =) а чем это тогда от обычного HA отличаться будет =)
вобщем то ничем. xen мона за уши притянуть но не нужно. мона еще openvz
___________________________________________
Gentoo GNU/Linux 2.6.26 GCC 4.3.1
Working on Gentoo for iPAQ hx4700 :-)
Если у вас компьютер с Windows, есть два выхода: выбросить компьютер в форточку или выбросить форточки с компьютера
Возможно,
Возможно, просто не очень понятно... Объясни если нетрудно. Смотри у мя 7 серваков, на каждом свои сервисы, часть серверов в дмз, часть в локалке. Возможно ли при использовании heartbeat обойтись без резервных машин, чтобы при падении 1-го или нескольких(в идеале всех кроме последнего) серверов, вся функциональность системы сохранялась?
Спасибо
Спасибо alexxy.
Может у кого есть иные соображения?
А что за
А что за сервисы? Хочется совсем универсальное решение или все-таки решения для каких-то конкретных сервисов? На мой взгляд, если есть возможность использовать зашитые в протокол средства повышения устойчивости, то нужно использовать их.
1
Сервисы- апач, почтарь(постфигс+довекот), бд, лдап, SVN, и т.п....
Хочется конечно универсальное решение....
Ну ldap и вообще
Ну ldap и вообще любые СУБД замечательно разливаются на несколько хостов с помощью встроенных средств репликакции и никак иначе. Что бы тут не говорили, никакая СУБД не сможет жить на сетевой файловой системе. Вернее жить будет, но не две СУБД работающие с одним и тем же файлом базы данных, они же на него блокировки делают, жестко рассчитывают, что никто ег менять не будет. Так что исключительно несколько серверов баз данных с репликацией, а клиентской ПО должно само уметь опредеять, что сервер ёкнулся и переключаться на другой. В ldap По это повсюду применяется, а вот с SQL хуже, ленятся программисты. Исключение - примитивные СУБД типа SQLite, но они моментально задохнутся порд нагрузкой.
А про остальное я скажу только одно, сделать действительно нормальную безотказную систему насного труднее и очень дорого. У всех вариантов, которые здесь приводились есть точка отказа, которая порушит все, как правило это либо свич, либо роутер, либо перераспределяющий нагрузку прокси. Насколько я понял, система будет висеть в интернете, а тогда для надежности надо иметь как минимум два аплинка, причем зарегистрироваться как автономная система, чтобы трафик при падении одного канала шел через другой. МГУ, например, себе автономную систему выбить не смог.
И нормального универсального решения не найдется. Тут все описывают, как ФС синхронизовать, а ведь еще и содержимое оперативки надо.
:. как обычно
Курим http://ru.gentoo-wiki.com/Создание_кластера_для_биллинговой_системы
__
:. Поделись опытом на ru.gentoo-wiki.com или на www.gentoo-wiki.com
Курил.... Немного
Курил....
Немного не то, что мне нужно мне надо бы "mutual takeover configuration", а не cold standby.
Нашёл
Нашёл интересную статью(может кому будет интересно) в конце:
http://linuxforum.ru/index.php?act=Print&client=printer&f=11&t=18331
Однозначно поможет, но к сожалению опять конфигурация cold standby.
А вот как сделать mutual takeover пока не нашёл...
Для начала
Для начала нужна рабочая кластерная распределенная система. Так чтоб при отвале узла, что ее частично держит, файлы были доступны. Ну к примеру gfs от редхата. Затем не нее заливаем данные "кластеризуемых" сервисов. После этого бекап бакулой при аппаратном сбое теряет свою значимость прямо пропорционально количеству узлов кластера. Ессно бекапить по-любому надо, но уже не от аппаратуры , а от дураков.
Затем на каждом узле поднимаем аналогичные сервисы, соответсвенно при падении одного из узлов количество сервисов вроде как не меняется. Суть в том что конфиги и данные у этих сервисов одинаковы, и лежат на любимой кластерной фс.
Далее нужно следилко-управлялку. Это либо hertbeat либо что нить от редхата.
Решения существуют на базе дебиан, редхат, асп (лайфкеепер).
Это ссцылко на английский кластер хавту от редхата.
http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Cluster_Administration/
ИМХО ксен этож виртуализация. Оно по любому медленнее чем на живой машинке.
ИМХО Я хочу
ИМХО Я хочу сделать через ксен ибо это будет удобнее для меня, т.е. вместо сервисов будут ксеновские домены(мне кажется что так проще будет, чем перетаскивать туеву хучу сервисов да ещё на каждый узел, + виртульно все серваки сохранятся), текущую систему перенести так будет быстрее, да и нагрузка не слишком большая, поэтому с ксен проблем нету...
Спасибо за пояснение, буду пробовать вообщем, а там посмотрим....
Посмотри в
Посмотри в сторону OpenVZ вместо XEN.
+: Если все сервера на Линуксе, то затраты на паразитную виртуальность - единицы %% от производительности сервера. Почитай на wiki.openvz.org (на память точно не помню) про Heartbeat+DRBD.