Дарова всем!
Есть желание попробовать развернуть систему резервирования "главного" сервера. Т.е. две идентичные машины зеркально тарахтят. При вылете одной из них (глюк железа ли, либо еще чего) вторая спокойно подхватывает, и тянет одна.
Админ в это время не торопясь чинит вылетевшую.
Юзеры же вообще ничего не замечяют...
Может кто уже реализовывал? Подскажите коротенько, платформы, реализация......

Что имеется ввиду под "главным" сервером? Сервер приложений? Контролер домена? Прокси? Или еще чего??

Ок.
1.Контроллер домена.
2.Сервер бухгалтерии.
Ось - Win2000Serv

Как я понимаю разговор идет об отказоустойчевом кластере, а не о вычислительном кластере. Тогда:

1.Контроллер домена - читай кластеризаци от от M$.. Но денего будет тебе это стоит ой как много именно по железу. Если мне память не изменяет там кластер делается на основе того, что 2 компа джевахарляют на один винт. В случае сбоя железо одного из компов - начинает работать другой...
Но строить отказоустойчевый кластер для контролера домена - ИМХО изврат, ибо на нем не должно быть никакой ценной иформации, за исключением AD. А для резервирования AD используется второй контролер домена.

2.Сервер бухгалтерии = сервер приложений.. На основе цитрикса можно сделать отказоустойчевый кластер. Нужно как минимум 3 сервера. 2 сервера - сервера приложений повязаные в одну ферму (понятие цитрикса). На наих кроме приложения 1С, с которым работают через термнал, ничего нет.. Все базы лежат на третьем сервере, на котором резервируется все что можно: 2 БП горячей замены, RAID, хотсвапные винты... В общем тоже не дешево получится (~6-7т. $)

По п.1 - согласен, изврат присутствует.
По п.2 - Первые две машины - понятно. Кстати, железо можно не идентичное? Что будет в случае отказа третьего сервера?
Ведь останов системы, по любому...

Железо можно не идентичное, ибо главное чтобы приложение работало.
По поводу третьего сервера: если он встанет, то да- все пропало. Но, если подумать что там может втать? Только мать процессор и память (память естественно регистровая должна быть). Это единственное что не зарезервировано, но это и реже всего выходит из строя. Но на этот случай можно поставить четвертый сервер: 2 сервера, на уотором хранатся данные синхронизируются между собой и в случае выходо одного из них из строя достаточно на втором сервере поднять на втором сетевом интерфейсе IP упавшего сервера и Вуаля! система снова работает после небольшого перерыва, равного вреремни отключения сбойного сервера активации второго сетевого интерфейса, сново в работе.
Описаная система - реальная и вполне рабочая.

Понятно. Но каким образом осуществить синхронизацию между третьим и четвертым серверами? В реальном времени???
Чесно говоря, из-за мат.платы все и беспокойство....Винты, память, источники БП, даже кулера - все это у меня есть в резерве... Но как быть с одномоментным вылетом мат.платы? Ее ведь быстро не заменить...Поэтому и затеваю всю возню...

Есть какя-то прилада для 1С, которая может синхронизировать базы... Синхранизация идет раз в 5 минут (можно сделать и чаще...)

По моей практике мать сама по себе вылетает ОЧЕНЬ редко. и в основном от плохого питальника и отсутствия стабильного напряжения.

Вот здесь и "гвоздь программы" - хорошее питание для сервера.
Можно не городить огород кучей серверов, а подобрать нормальное железо и ИБП.
И 2-х серверов может хватить при таком подходе.
На случай отказа винтов есть RAID. Хот-свап. Для резервирования на втором сервере какой-нить девайс. Пока что ленточные рулят.

Не совсем прав. Огород из трех серверов городится еще и для того, чтобы система получилась маштабируемая. При этой схеме сервера приложений не нуждаются ни в рейде ни дополнительных БП.
А про надежность питания.. Серверная у нас заитана от упса на 10кВат и при этом один БП все равно сдох. Так что если бы не 2 БП в одном корпусе, то встал бы сервер. А так - вынул дохлый БП прямо на ходу и сервак этого даже не заметил. Так что резервирование нужно и при нормальном железе (под нормальным железом я понимаю именно серверное железо)

Ну на счет 2-х БП я согласен полностью. В ответственных местах вещь нужная.
А что ты подразумеваешь под масштабируемостью?

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

Понятно.
А у нас кластеры используются для распараллеливания задач.
Вот и спросил.

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

Да. Я в курсе о таком многообразии.
Просто уточнил.