Oracle Clusterware + HP Service Guard
Если Oracle Clusterware используется с вендорским clusterware (в данном случае HP Service Guard), то параметр css misscount автоматически устанавливается в 600 сек, давая возможность разрешить конфликт вендорскому clusterware.
В связи с этим, может возникнуть ситуация, когда скажем в качестве интерконнекта используется 2 физических интерфейса. Потеря одного динка для вендорского clusterware не является критическим событием - второй линк работает. Но, если по вышедшему из строя линку передавался траффик cache fusion то (я так думаю) что весь кластер встает (больше блоки не передаются между узлами). Если передавался траффик css - то все "встает" на 600 сек. В В последнем случае узел отправляется в перезагрузку.
HP предлагает решение этой проблемы: Cluster Communication Network
Monitoring. Коротко, насколько я его понял - следует создать отдельную пару интерфейсов для траффика RAC + clusterware. В случае выхода из строя одной платы, все будет продолжать работать для RAC прозрачно. Также даются рекомендации по изменению параметров css, чтобы не ждать пресловутые 600 сек. Я думаю, что наверно можно настроить также триггер, чтобы разрешать ситуацию с RAC в случае потери обоих линков.
Несмотря на то, что в параметре cluster_interconnects можно указать несколько интерфейсов, кажется это не работает. Это даже указывается в Note:151051.1.
Сообщения
Мне кажется, сетевые интерфейсы для интерконнекта проще объединять средствами операционной системы под одним IP-адресом. О том, что их несколько, Ораклу лучше не знать.
ОтветитьУдалитьВасилий.
Note:151051.1 настолько стара, что ей уже страшно доверять,
ОтветитьУдалитьособенно в отношении 10-ке - о которой там ни слова
постараюсь в ближайшее время проверить данной поведение.
До сих пор не могу понять почему Оракл не
хочет реализовать нормальные фейловер и лоадбалансинг по несколькоим
интерконнектам прописанным в OCRе ?
а так же встроенную поддержку малтипаса для ASM...
все это было бы очень востребованным дополнением к RAC 11.2
Александр
Василий, я тоже так думаю.
ОтветитьУдалитьАлександр, кажется файловер интерконнекта и public сети должен быть, но также скорее всего не работает. Поддержки мультипасинга в ASM не будет очень долго (если вообще будет) - это надо поддерживать разные карточки производителей. Здесь мне кажется нормально полагаться на OC.
зачем опускаться до поддержки разных производителей карточек ?
ОтветитьУдалитькогда реально нужно только выяснить какие устройства являются алтернативными путями доступа к требуему устройству
и использовать данную информацию как для балансировки нагрузки, так и для фейловера.
девайс маппер в линуксе работает же без привязки/специфики/ к конкретным карточкам.
Если бы Oracle работал только на Linux - наверно сделали бы поддержку. Но вот нету device mapper под Windows. С другой стороны, если Вы используете EMC powerpath - никакой device mapper тут не играет. Т.е. очень уж получается аппратно и ОС зависимая реализация. Я думаю, что у разработчиков ASM и без этого проблем хватает :)
ОтветитьУдалить