Fibre Channel SAN + кластер Hyper-V + виртуальный Oracle RAC

[Archvile]

Добрый день !

У нас есть кластер Hyper-V 2.0 с общим хранилищем Fibre Channel (IBM DS), нужно сделать на нем кластер Oracle RAC+ASM 11gR2 Windows на виртуалках. По ходу возник такой вопрос. Общее хранилище для RAC-а хочется сделать не по iSCSI, а по FC. Насколько я понимаю, в гостевые машины hyper-V Fibre Channel не пробросить никак (программный iSCSI не в счет), и единственный вариант, который в данном случае возможен - пробрасывать общие диски физических узлов Hyper-V на виртуалки через pass-through на каждом гипервизоре. Но при этом, как я понимаю, для виртуалок как минимум не будет пресловутого "SCSI-3 persistent reservations" (вроде как RAC 11g сможет без него прожить), а как максимум будет невесть что. Соответственно, вопрос - встанет ли RAC, будет ли нормально работать с таким "pass-through-хранилищем" ? И как бы вы посоветовали оптимально организовать общее хранилище для такого случая (виртуальный RAC + физический FC SAN) ? Спасибо.

[Stranger03]

"Archvile"
Возможно я не прав, но с точки зрения Оракла вы ему должны предоставить общий дисковый ресурс для доступа. Как вы будете организовавыть этот доступ, по файберу, по айскази, для Оракла должно быть фиолетово. За это отвечает ОС, конкретно Винда с Гиперви.
Можете попробовать развернуть тестовую среду. Если же в какой-то момент начнутся приколы, всегда можно переделать на вмварь и выдать виртуалкам физический доступ к СХД.
P.S. поправьте пожалуйста профиль, город в профиле.

[ITER]

не будет пресловутого "SCSI-3 persistent reservations" (вроде как RAC 11g сможет без него прожить)

Oracle RAC вообще не использует scsi reservation (тем более scsi-3).

[Archvile]

Получается у него какие-то свои крутые механизмы работы с общими raw-дисками ?

PS
Я про SCSI persistent reservations читал например тут (правда там про 10g, но я думаю, к 11g это еще больше относится):
http://www.infostor.com/index/articles/ ... g-rac.html

SCSI-3 reservations and IO Fencing- The whole idea behind a 10g RAC implementation is that all nodes share access to all database objects. No matter what volume management or clustering software is used, SCSI reservation is a requirement to accomplish this.

If you are migrating from an older instance or have older storage arrays that you are planning to use for the new RAC environment, chances are that either the storage arrays are not configured to handle SCSI reservations or they do not support it at all. Most modern arrays (especially if you are using Fibre Channel) support SCSI-3 persistent reservations (SCSI-3 PR). Some clustering engines, such as Veritas’ SFRAC, use SCSI-3 persistent group reservation (SCSI-3 PGR) to implement a technique known as IO Fencing (sometimes called Disk Fencing), which is a method by which nodes can be stopped from accessing shared storage if they are not in a cluster. It allows the cluster engine to “eject a node” from the cluster, thereby protecting shared data.

SCSI-3 PGR will soon replace all other forms of SCSI reservation technologies, such as SCSI-2 reservations. It is highly advisable to choose a stack that uses SCSI-3 PGR when implementing RAC.

[ITER]

Получается у него какие-то свои крутые механизмы работы с общими raw-дисками ?

Доступ на металинк есть? Читаем 220970.1

Should the SCSI-3 reservation bit be set for our Oracle Clusterware only installation?

If you are using only Oracle Clusterware(no Veritas CM), then you don't need to have SCSI-3 PGR enabled, since Oracle Clusterware does not require it for IO fencing. If the reservation is set, then you'll get the inconsistent results. So ask your storage vendor to disable the reservation.

Veritas RAC requires that the storage array support SCSI-3 PGR, since this is how Veritas handles IO fencing. This SCSI-3 PGR is set at the array level; for example EMC hypervolume level.

Additional info:

1) If the SCSI-3 PGR bit is set on a storage array (or an a LUN, this does not matter in this case), it only enables SCSI3 PGR capabilities. If set, a cluster or application using this piece of storage may make use of SCSI3 PGR. Oracle Solaris Cluster and Veritas Cluster may use SCSI3 PGR under certain circumstances, Oracle Clusterware does not (as far as I can tell). So, whether the bit is set or not, as long as no component on the host makes use of it, nothing will change.

2) Oracle Clusterware as well as ASM do not make use of or leverage SCSI3 PGR. Only 3rd party clustering stack components will use it; eg, VCS, SFRAC, HACMP, and cluster volume managers. If you don't ever plan on installing or are using 3rd party cluster stack components, then SCSI3 PGR LUNs should be transparent to you. However, I would question why the storage team would even setup LUNs w/ PR arbitrarily. This just adds another management step and it could be confusing from storage management perspective.

Поскольку у вас речь шла про ASM забудьте об scsi reservation. Сам оракл её не использует ни при каких обстоятельствах.

[Archvile]

Однако, в RAC FAQ на металинке-то я и забыл заглянуть
Да и забыл походу, что rac у меня работал на redhat iscsi target, где вряд ли было SCSI3
Получается, описанный выше конфиг вполне подходит. Будем тестить...