Extended RAC Clusters

В распределенном ( для конкретики, 2-х узловом RAC) на каждом сайте располагается своя дисковая группа ASM & voting disk. Для построения такой системы мы вполне можем использовать решения только от Oracle и осуществлять зеркалирование между массивами с помощью ASM. На небольших дистанциях, пока задержки невелики, можно строить такие системы начиная с 10g. Дальше следует смотреть в сторону 11g.



Хорошо, с зеркалированием данных разобрались, теперь посмотрим, что происходит в случае аварии связи между узлами. На всякий случай напомню, что если пропал interconnect или disk heartbeat между узлами - oracle clusterware вызывает панику одного из узлов, в случае даже обычного кластера. Но в нашем случае, в момент разрыва SAN между сайтами, оба сайта получает доступ к недостаточному числу voting дисков и оба паникуют. Так по крайней мере считает документация:

"A node must be able to access more than half of the voting disks at any time.
If a node cannot access the minimum required number of voting disks it is evicted, or removed, from the cluster"

Таким образом нам для двух сайтов, нам нужно 2n+1 = 3 voting диска. Причем 3-ий voting диск необходимо разместить не на тех же сайтах, где узлы нашего кластера, иначе, есть опять риск потерять весь кластер. Действительно, если авария случиться на том сайте, где мы разместили 3 voting диск, то другой сайт опять получит только к 1 voting диску и также запаникует.

Итак, наша примерная схема построения кластера должна выглядеть следующим образом:


Конечно, она немного упрощена - все оборудование должно быть задублировано.

Осталось решить, где же разместить наш 3 voting disk ? Решение для *nix систем - разместить 3 voting диск на NFS. Для платформы windows самый простой путь создания 3 voting disk - использовать certified iSCSI.



Полезные улучшения в 11g RAC