Имеется система, функционирующая на Windows 2003 Server и MS SQL Server 2000. Для упрощения - имеем одну базу данных размером 150 Гб с приростом около 10-20 Гб в год. 100 одновременных пользователей в дневное время, в вечернее 30 одновременных пользователей. Остановка сервера позволяется только один раз в году на новый год на пару дней. Во все остальное время даже трехчасовой простой - это нонсенс. Двухчасовой простой раз в месяц впринципе не критичен.
Система крутится на двухпроцессорном HP DL380. В него воткнуто 32 Гб памяти и 10 дисков SAS15K. Плюс подключена полка HP D2700 с 24-мя дисками SAS 15K, подключенная через контроллер P421.
Т.е. по сути просто двухпроцессорная система с 34-мя дисками.
Есть резервный сервер-собрат, но без полки. На него каждые 15 минут идут разностные бэкапы, ну и плюс сложная система контроля их корректности.

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

Сейчас начинается пора формирования бюджета на следующий год. Хотел бы посоветоваться в какую сторону рыть чтобы организовать отказоустойчивый сервер.
1. Я не должен бояться выхода из строя материнской платы основного сервера
2. Я не должен бояться выхода из строя полки
3. Я не должен бояться выхода из строя контроллера, которым подключена полка
4. Операционная система только Windows 2003 и изменена быть не может. Т.е. возможно это будут виртуалки, но я хотел бы чтобы если виртуализация и будет идти через (например) Hyper-V, но кластеризация должна обеспечиваться средствами железки, а не операционной системы. Я больше доверяю софту HP, Dell, IBM, чем софту Microsoft.

rahzerВзять СХД, забить нужным кол-вом дисков, докупить еще сервак, сделать SAN фабрику, и у тебя нет единой точки отказа. Играйся машинами как хочешь, вплоть до живой миграции виртуалок. Ляма в полтора уложиться можно. Ну и для успокоения еще сервисный контракт расширенный взять.

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

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

rahzerВ СХД нет единой точки отказа, там два контроллера со своей начинкой, я много раз демонстрировал заказчикам, которые не верили, достаешь на живую один контроллер, все работает, ничего не падает. С виртуализацией так же, отрубал один сервак, все продолжало крутиться.
Если есть желание, контакты в профиле, подробнее напишу или спеки прикинем.
P.S И вообще, железо можно и в тест взять, погонять пару недель, сам посмотришь как оно работает на практике)

Спасибо, подумаю, а что это вообще за технологии? Просто никогда не сталкивался с такой виртуализацией. Она обеспечена на уровне софта производителей железа? Просто не хотелось бы делать какой-то отказоустойчивый кластер на базе Microsoftовских продуктов. Хотя может быть я и необосновано не доверяю Microsoft.