Что лучше загрузка с локальных дисков или по SAN

[mishanya_f]

Добрый день! Хочу узнать мненение как лучше спалнировать SQL сервера (локальные диски 2х36Гб 10000rpn, контроллер 200i). организовать загрузку ОС (Windows 2003) по SAN (EVA) и не морочиться с кластером SQL (n+1), т е при выходе из строя сервера просто загрузиться с резервного сервера (такой имеется), предварительно изменив настройки LAN и WWN (делается в течении 2 минут)используется у нас virtual connect (HP). Или при такой конфигурации (загрузка по SAN) есть какие то свои скрытые ньюансы? Я так понимаю, что при кластеризации средствами SQL один сервер будет стоять в стендбае, что само по себе нехорошо в плане простаивания ресурсов, да и будет медленнее работать (надо же как то сообщать служебную инфу между серврами о кластере да и данный передавать надо в два места...). В качестве удалленного дискового массива будет использоваться EVA. Подскажите как лучше настроить, исходя из личного опыта. Серверов SQL планируется ~5шт. Заранее спасибо!

[a_shats]

Лучше - заморочьтесь с кластером. Best Practice - не делать загрузку с SAN.
Далее - сколько каких и как нагруженных у Вас баз ? Какая потребна отказоустойчивость для каждой из них ? Какой клиентский софт - в смысле, не 1С ли ? Если да - то какая ?
Суть - на разных нодах вполне можно запустить разные инстансы MSSQL с разными базами. Но вот с 1С8 и SQL2000 такое как-то сделать не удалось.

[mishanya_f]

Итак по-порядку:
Клиентский софт: 1С 8.1 УПП
Количество баз:от 3(УПП)+1(УТ)
Почему в Best Practice не стоит использовать загрузку по SAN?
Все базы SQL планируем держать на EVA. На первоначальном этапе будет одна база SQL и 20 винтов (15000rpn). После результатов тестирования в боевой готовности будут докупаться винты и добавляться базы. Планируем под каждый из SQL серверов для загрузки создать на EVA Vdisk для загрузки с него. При выходе из сторя сервера, настройками Virtual Connect-а (SAN и Ethernet) поднимаем на резервном загрузку сервера с Vdisk, с которого загружался вышедший из строя сервер. И всё. Да, автоматом все не переключишь, нужно время от поступления жалоб, что сервер вышел из стороя и до перенастройки и запуска с резервного. Планируется, что если будет 4 базы то будет 4 SQL сервера с HBA (каждому серверу своя база). SQL2005.
Все таки что плохого в загрузке по SAN??? и как будет чувствовать себя винда если и полка будет загружена, базами и не скажеться ли это на LUN где стоит ОС. Хотя не стоит забывать что это EVA и в ней работают ВСЕ винты (можно создать достаточно много винтом в одной дисковой группе)...

[gs]

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

[mishanya_f]

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

[gs]

Ну это из области общих рассуждений. Можно всякое нарулить...

[mishanya_f]

Но в штатной работе данной конфигурации при правильной настройке всего оборудования, могут возникнуть сложности с эксплуатацией? Что то не работает, каких то драйверов нет, что то ещё...Одним словом есть ли какие то подводный камни? Как я описал, то данная конфигурация довольно хороша в плане перенастроек при железном выходе из строя чего то, я не беру проблем с выходом из стороя самой винды...для этого же есть снепклон например, которым заменим ОС...

[Oleg2]

Но в штатной работе данной конфигурации при правильной настройке всего оборудования, могут возникнуть сложности с эксплуатацией? Что то не работает, каких то драйверов нет, что то ещё...Одним словом есть ли какие то подводный камни? Как я описал, то данная конфигурация довольно хороша в плане перенастроек при железном выходе из строя чего то, я не беру проблем с выходом из стороя самой винды...для этого же есть снепклон например, которым заменим ОС...

ИМХО, загрузка сервера с SAN позволяет избежать останова работы конторы в случае изъятия сервера приходящими маски-шоу.
Особливо если массив заныкать далеко и кинуть к нему длинную оптику...

[gs]

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

[mishanya_f]

А проста ли будет система, если настраивать кластер SQL N+1 даже если грузиться с локальных винтов? И будет ли он производительным в том плане что будут уходить ресурсы оборудования на обеспечение кластерезации?

[gs]

Система будет сложна, но при должной настройке не потребует судорожный действий персонала в условиях цейтнота.

На кластеризацию в стендбайном варианте ресурсов никаких не нужно.

[mishanya_f]

А вообще есть конторы, которые таким образом строят свои подсистемы:загрузка ОС с SAN? Хотелось бы услышать восхищения или наоборот нелесные отзовы от данной концепции? Может кто поделиться опытом проблем...

[gs]

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

[mishanya_f]

И интересно, как довольны иммено такой конфигурацией? Нет ли проблем с эксплуатацией?

[gs]

Ну я вообще-то не в Питере сижу