Проектируем 2-х узл. active/active кластер с хран. IBM DS400

[p rj]

Задача, наконец-то, уточнена. Необходимо обеспечить отказоустойчивый доступ клиентов MS SQL Server к базе данных предприятия, а также клиетов сети к наиболее важным общим файловим ресурсам. SQL-база транзакционная (1С:Предприятие 7.7) ок. 15Гб (прирост ~5Гб/год), ок. 100 юзв. (прирост...е), 10-15 тыс. строкодокументов/день - нужна производительность. Нагрузка при обслуживании доступа к общим файлам невелика (во всяком случае на запись).
В наличии имеются 2 сервера ~одинаковые (2*Xeon 2.66  RAM 5Гб и 2*Хеоn 2.4 RAM 4Гб). Дополнительно будет приобретено внешнее хранилище данных IBM DS400 c двумя контроллерами и всем необходимым сопутствующим оборудованием.
Идея решения такова. Мы хотим создать 2-х узловой active/active кластер серверов (ОС - W2K3). 1-й узел будет активным для MS SQL Server 2000 и пассивным для доступа к общим файлам, 2-й соответственно наоборот + будет выполнять некоторые другие задачи не требующие кластеризации. Каждый узел кластера будет связан с каждым контроллером DS400 (все 4 хост-соединения будут задействованы). Часть дискового пространства хранилища ("быстрая" - 15000 об. диски небольшого размера, предп. рейд 10) будет выделена под SQL-базу, другая ("медленная" - большие диски 10000 об., предп. один массив рейд 5) - под файлы.
Прошу одобрить/покритиковать наш подход и, по возможности, ответить на следующие вопросы.

1. Собственно по кластерам.
1.1. Не совсем понимаю по хелпам что такое "кворумный ресурс" кластера. Это один специально выделенный раздел общего дискового пространства или под этим понимается совокупность разделов с данными которые необходимо захватить узлу, чтобы стать активным для конкретной кластеризуемой задачи? Если это спец. выделенный раздел, то он просто некий уникальный для кластера объект блокировки, или туда пишутся, например, какие-либо служебные данные кластера? А в случае active/active кластера как?
1.2. К вопросу резервирования heartbeat. У серверов по два сетевых интерфейса: гигабитный и сотка. Ч/з гигабитные сервера, ессно, подключены к общей сети предприятия. Ч/з сотки - основной канал heartbeat. Т.к. heartbeat - частная сеть кластера, стало быть его для резервирования подключением к общей сети воспользоваться нельзя и надо еще по карточке в сервер, верно?
1.3. Возможны ли в кластере active/active различные для каждого узла настройки производительности? Например,  "Свойства системы - дополнительно - параметры быстродействия - дополнительно" получится ли: на 1-м узле (акт. SQL) процессор и память -оптимизировать работу программ, а на 2-м (акт. файлы) - оптимизировать работу служб, работающех в фоновом режиме и системного кеша. Аналогично свойства службы доступа к файлам ... сети - макс. проп. способность для сетевых приложений/доступа к общим файлам соответственно.

2. Вопрос по организации дисковой системы. В ds400 можно поместить 14 дисков. Пусть это будет 8 дисков 15000 об. 36Гб для SQL, 5 10000 об. 146Гб - рейд5 для файлов и 1 146Гб - общий для всех массивов hotspare. Как лучше разложить mdf и ldf SQL-базы по массивам и все массивы по контроллерам хранилища? Как бы 2 основных варианта пока:
-  mdf на рейд 10 из 6-ти винтов, массив на первый контроллер. ldf на рейд 1, этот массив совместно с массивом рейд 5 для файлов на второй контроллер
- mdf и ldf на 2 разных LUN-a рейда 10 из 8-ми винтов, массив на первый контроллер. На второй контроллер только массив рейд 5 для файлов.

3. Вопрос по кластеризации MS SQL. Обязательно и все ли системные базы данных должны быть расположены в  общедоступном хранилище? Особенно интересует база tеmpdb.

Заранее спасибо всем, кто захочет помочь.

[Stranger03]

пишутся, например, какие-либо служебные данные кластера? А в случае active/active кластера как?

Это специальный раздел на внешнем массиве, куда пишется всякая ботва, в том числе и служебная.

для резервирования подключением к общей сети воспользоваться нельзя и надо еще по карточке в сервер, верно?

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

системного кеша. Аналогично свойства службы доступа к файлам ... сети - макс. проп. способность для сетевых приложений/доступа к общим файлам соответственно.

Это возможно, никто не мешает так сделать.

Как лучше разложить mdf и ldf SQL-базы по массивам и все массивы по контроллерам хранилища? Как бы 2 основных варианта пока:

Здесь очень сложно что-то советовать. Есть МС рекомендации для размещения базы, но на практике чаще получается методом тыка. Например МС рекомендует разделят базу, индексы, а у нас с CyberDrace-ом получалось, что наивысшая произхводительность на неразделенной базе. Вот и думай, что лучше. Надо пробовать.
Я бы взял 14-ть дисков одинаковых.

3. Вопрос по кластеризации MS SQL. Обязательно и все ли системные базы данных должны быть расположены в  общедоступном хранилище? Особенно интересует база tеmpdb.

Обязательно, иначе у вас вторая нода не поднимется в случае чего.

[p rj]

То Stranger03 Спасибо.

Это специальный раздел на внешнем массиве, куда пишется всякая ботва, в том числе и служебная.

А как получается что он один для случая active/active?

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

Так я об этом и говорю - из того, что в сервера уже встроено: 1Гбит - для внешнего линка, 100Мбит - для кластерного соединения, а  по второй карточке в сервера надо для еще одного кластерного соединения.

Я бы взял 14-ть дисков одинаковых.

У меня требования разные: для БД производительность важна (15000 об. и райд 10), а размер дисков 36*8/2 - за глаза и надолго; для файлов же производительность (во всяком случае на запись) не важна (10000 об., райд 5), а вот объем нужен. Конечно, оно неплохо все 14 шт. 146Гиг 15000 об. - но дорого, не обосную.
Сам предполагаю, что более равномерно распределить нагрузку процессоров обоих контроллеров реальнее когда базы с журналом на одном, а файлы на другом (реже запись, но там райд 5 - считать надо). А кеш все равно синхронизирован, а значит его состояние одиноково (во всяком случае в части буфера записи) на обоих контроллерах.

[gs]

Кворум-том один в рамках кластера. Туда пишется конфиг кластерных ресурсов.

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

Балансировка нагрузки по контроллерам какого-то серьезного выигрыша едва ли даст - винтов немного, контроллеры и так управятся.

[p rj]

Кворум-том один в рамках кластера. Туда пишется конфиг кластерных ресурсов.

[/quote]
А каков должен быть его размер (или от чего зависит)? Это д/б быстрый раздел или не важно?

контроллеры и так управятся.

А вот тогда подумал, когда мощи контроллеров достаточно, то м/б при одинаковом количестве одинаковых винтов (зеркал, соответственно) райд5 и не особо проигрывает 10-му даже на запись?

[gs]

H'ql5 на запись проигрывает в силу его организации. Всегда. Просто на мощных контроллерах он проигрывает меньше (у рэйд5 два слабых места - нужна большая мощь считалки для контрольных сумм, которая упирается в мощь контроллера, и большее число дисковых операций, которое никуда не девается при любом раскладе).

Кворум-том может быть медленным и маленьким - туда особо ничего не пишется. Он вообще почти рид онли. Размер есть в рекомендация мелкософта, но если сделаете гиг - ну никак не ошибетесь.

[exLH]

рекомендация микрософта - 500метров. Не менее 50МБ.

[p rj]

Спасибо, многое для себя прояснил!
Спрошу тогда еще немного.
1. Если объем ОЗУ в узлах кластера разный - чревато ли это проблемами при файловере на узел с меньшим размером памяти? В особенности это волнует по части поведения MS SQL Server.
2. Вроде как всегда говорят, что объем кеша (особенно для записи) является чуть ли не определяющим с точки зрения производительности. Укомплектовать контроллеры хранилища максимальным по размеру кешем (2*1Гб) увеличит общую стоимомость решения на весьма незначительный процент. Как думаете, следует это сделать?

[gs]

2. Стоит. Прирост от кэша очень сильно зависит от задачи - от нуля до дофига - но в базы данных обычно его любят.

[exLH]

1. Чревато тем, что машина возможно не справится с возложенными на нее обязанностями (справится плохо) и пользователи будут недовольны. Работать она, при этом, все равно будет.

[Stranger03]

1. Если объем ОЗУ в узлах кластера разный - чревато ли это проблемами при файловере на узел с меньшим размером памяти? В особенности это волнует по части поведения MS SQL Server.

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

[p rj]

Спасибо за разъяснения.
Есть еще проблема
В наследство от перваначальной постановки задачи (2 узла+2хран.) осталось еще одно требование. А именно, чтобы второй узел кластера (пассивный для SQL), находился в другой серверной. Там в некластерном режиме (на внутр винтах) будет поддерживаться резервная БД (stand by).
По ходу выяснилось, что трансиверы и HBA для ds400 поддерживают только многомодовое оптоволокно, а между серверными проложено одномодовое. Есть ли конвертеры для FC многомод-одномод или проблему можно решить как-то еще?

[exLH]

Надо будет купить одномодовый GBIC, проверить его работу в DS400 (скорее всего все будет нормально).
Ну и HBA, разумеется должна быть с поддержкой одномода. (Самый простой вариант - LSI + одномодовый GBIC.

[p rj]

Т.е. правильно ли я понял, что одномодовый GBIC, это вместо SFP-трансивера? Кстати, GBIC или SFP - сами-то они куда вставляются в DS400 (т.е. без них что за интерфейсны(й/е) разъем(ы) у хранилища)?

Ну а в целях единообразия - получается 4 шт. GBIC и 4 (или 2*2 кан.) HBA. А может быть все же это есть в природе "родное" IBM-е? Вообще все хорошо, но найти на сайте IBM описания сопутствующего оборудования - ногу сломаешь, токо если код железяки знаешь, да и то одни "новости". Ну а если нет IBM-го, подскажите, пж., любую подходящую модель HBA (LSI или др.), а я по поисковику найду описание и почитаю.

[gs]

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

HBA мы любим QLogic QLA2340 за безглючность и почти абсолютную совместимость. Но у них только многомодовые. Одномодовый джибик можно воткнуть в LSI: http://www.lsilogic.com/products/fibre_ ... ndex.html/ . Но они более капризны.
Ну или смотрите у IBM - там должны быть, правда дороже.