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

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

Вот это и непонятно, как понять, упал ли сервер, либо просто упала связь?
И как не получить два "рабочих" сервера после восстановления связи. Я так понимаю, всю проверку уже сделал агент интерсистемса, а ^ZMIRROR всего лишь может "кинуть кубик", "взять отвественность на себя" и все такое, что в общем не гарантирует непротиворечивость ситуации.

Как кажется на первый взгляд, тут помог бы "внешний наблюдатель", относительно которого работает один из серверов, либо работают оба, и именно он должен принять решение. Вроде как так делает тот же MSSQL. Подозреваю, что это решение имеет свои минусы, так как разработчики каше, мне кажется, рассматривали этот вариант.

Ситуация, когда каше работает, а агент упал, считаю маловероятной по причине того, что непонятно, из-за чего агенту вообще падать :-). Если только искусственно.

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

Я правда на 2010.2 FT2 пробовал, может на релизе что-то доработали.

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

В общем, если жахнуть резко основную систему, то типа резервная начинает просто тупить, ожидая, когда поднимется основная. Руками в режим основной ее перевести не получалось. Далее, после рестарта до резервной доходит, что помощи ждать неокуда, и она принимает на себя таки роль основной. Если после этого поднять основную, то тут 50/50, она либо включается как резервная, либо просто не стает в режим зеркалирования. Может что и не совсем так, но у меня нарисовалась такая картина.

Т.е. самый просто, самый реальный и самый жесткий сценарий:
падает основная система,
резервная система включается как основная (автоматически),
через несколько часов поднимается основная система,
происходит автоматическая синхронизация,
ручное переключение на старую основную систему

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

А фича с виртуальным IP нравится :-)

Alexey MaslovБлок А.Н.ручное переключение на старую основную системуВроде бы для этого достаточно остановить Cache на новой основной - разве нет? Должно произойти автопереключение, т.к. агент остался жив и он ответит.
Да, переключение при остановке основной происходит нормально, правда иногда через 5 секунд, а иногда через 50. Видимо, большой интервал опроса агентом?

Alexey MaslovНу как и любой сложной системе, ей есть от чего заткнуться :( Можно предположить, что при серьезных проблемах с Disk I/O Cache умрёт раньше, чем агент.
Мне кашется, что если умрет системный диск, то каше даже пикнуть не успеет, как упадет вместе с операционкой. А при падения диска с СУБД технически каше будет работать. Пока у меня подозрение, что агент просто делает общий "пинг" каше, не проверяя собственно функционирование служб и состояние баз данных. Ну и опять же, рейды не зря же придумали.

Хм, про журналы это жизненное.
Недавно девелоперский сервер укладывал два дня подряд.
Надо проверить.