FavnЧитая, не забываем, что в RAC/pureScale слабым местом является именно не дублируемый shared-disk, т.е. полноценной HA по надежности таки не получается.

это немного не так
shared disk это может быть вполне себе отказустойчивое (распределенное) хранилище с нужным уровнем избыточности
более того, последние версии ораклового ASM-а (кластерная файловая система + volume manager специально для RAC) позволяют строить нормальный extended distance RAC (см. фичи fast mirror resync, prefered mirror read)
там довольно жесткие требования к network latency, потому растояние между ДЦ конечно не может превышать нескольких десятков, максимум вроде в районе сотни километров
у нас например сейчас в продакшене есть несколькоузловой ED RAC размазаный по трем датацентрам с high redundancy ASM diskgroup
у нас конечно ЕЕ но не вижу почему что-то такое не может жить на SE

к нему конечно лучше все-таки стендбай, но у нас уже полгода вполне прожил без него )

Favnа распределенное хранилище на уровне SE будет стоить явно больше, чем дисковая система 2-го сервера в кластере HADR.


почему больше?
пара дисковых полок, с них все диски раздать друг другу по iscsi (бесплатно) + сверху asm (бесплатно)
ну мультипасы с бондингами на это все накрутить (бесплатно)
собственно никакого дополнительного софта докупать не нужно, только второй сервер и дисковые полки
конечно придется заморочиться, решение не коробочное, но если стоит цель сэкономить...

основная фишка в ASM-е, он пока что бесплатен

FavnЧестно говоря, я считаю, что на Oracle SE с учетом ее ограничений RAC (4 сокета на весь кластер) является просто вынужденной заменой HA, недоступного "полностью" для этой редакции.


кстати не уверен, давно не смотрел оракловый software investement guide
но вполне может быть что RAC как таковой, с двумя оракловыми инстансами поднятыми одновременно и делением сокетов между ними, в приведенном мной примере и не нужен
на втором узле достаточно держать поднятый clusterware + asm с половинкой normal redundancy группы, а второй оракловый инстанс поднимать при фейле первого

ну и вы, мне кажется, недооцениваете 4 сокета
если это например современные 5645 (6 ядер + гипертрейдинг), это получается 24 "честных" ядра или 48 с HT
с учетом тех возможностей по оптимизации которые предлагает оракл, из них можно много выжать
да, там не будет партишенинга, параллелизма и всяких вкусностей типа ASH, но опять таки, при большом желании сэкономить с этим вполне можно смириться
тем более для web/OLTP нагрузки

Favnartemgну и вы, мне кажется, недооцениваете 4 сокетаДело не в том, что 4 "куча" или "мало".
Дело в том, что при крахе одного из узлов из 4-х остаются 2, и система (если она рассчитана на 4) может с нагрузкой не справиться. В отличии от настоящего HA, где резерв м.б. не менее мощным, чем мастер. То есть при использовании RAC в качестве HA все равно надо иметь в виду необходимость избыточности мощности серверов. И дисковых систем тоже, раз уж речь зашла о зеркалировании. И все это при бОльшей сложности администрирования. Не понятно, в чем тогда декларируемое Yo! преимущество перед HADR.

я же говорю, если не хочется делить сокеты и в случае факапа лететь на половине мощности - тогда можно делать failover cluster
http://www.oracle.com/us/corporate/pricing/sig-070616.pdf
стр 20
авторFailover – In this type of recovery, nodes are arranged in a cluster and share
one disk array. A Failover cluster is a group of systems, bound together into a
common resource pool. In this type of recovery method, the Production node
acts as the primary node. When the primary node fails, one of the surviving
nodes in the cluster acts as the primary node. Solutions like Oracle Failsafe
(included with Oracle Database EE or SE, SE1), or third party vendor solutions
(e.g. Veritas, HP Service Guard, HACMP, Linux HA - Heartbeat) are used to
manage Failover environments. In this type of environment, Oracle permits
licensed Oracle customers to run some Technology Programs on an
unlicensed spare computer for up to a total of ten separate days in any given
calendar year. Once the primary node is repaired, you must switch back to the
primary node. Once the failover period has exceeded ten days, the failover
node must be licensed. In addition, only one failover node per clustered
environment is at no charge for up to ten separate days even if multiple nodes
are configured as failover.

причем это может быть extended distance кластер - второй узел может быть в другом ДЦ, под ними asm с normal redundancy и полными копиями данных в каждом ДЦ

Yo.! наверна имел в виду что там минимум 5 юзерских лицензий брать надо.


я все равно не понимаю почему отказоустойчивый shared storage для RAC (EE или SE неважно) нельзя организовать на commodity железе и бесплатном софте

но да, распределенный оракловый кластер с узлами и данными в разных ДЦ доступен только тем у кого есть свой быстрый канал между ними
лог шиппинг в этом плане гибче, можно работать в асинхронном режиме, играться с таймаутами