Alexander Ryndin1) У них 3 сервера, которые они объединяют в кластер. А, если я правильно понимаю, pureScale требует выделить как минимум 2 узла под блокировки. Т.е. в их ситуации получился бы 1 рабочий узел и 2 надсмотрщика. Я так понимаю, они вышли из ситуации, отпилив на каждом физическом узле виртуальную машины на 2 ядра и там подняли управление блокировками. 1/3 ядер в кластере у них занимается исключительно блокировками.Судя по той ссылке, которую я привёл, там 2 8-ядерных сервера под db2. Т.к. виртуализация на intel пока не поддерживается, как рекомендуется и как возможно на power, то там на каждом сервере одна ОС и внутри запущено по 1-му узлу (member) DB2 и по 1-му CF - на одном первичный, на другом - вторичный. CF привязан к 2-м ядрам, чтоб узлу не мешался.
Alexander Ryndin2) Что-то я ничего у них не услышал про standby. Они так гордятся отказоустойчивостью своего кластера, что даже не думают создавать резерв в другом датацентре, что наводит на мысль, что от нас что-то скрывают. Как там с поддержкой HADR? Можно какую-нибудь ссылку на официальную документацию?Поддержка HADR в pureScale планируется в следующей версии.
Пока либо репликация, либо geographically dispersed DB2® pureScale™ cluster (GDPC)
Alexander Ryndin3) Кстати, как там у pureScale c intra-query parallelism? Можно SELECT сделать, чтобы он по узлам расползся? Ну или индекс в параллели перестроить? Или backup в параллели одновременно на всех узлах запустить?Если "intra-query parallelism" - это возможность выполнять 1 запрос на нескольких узлах одновременно, то нет. Да и не нужно это в oltp системах.
Про индексы и backup - не уверен, но по-моему нет.

Alexander RyndinА правильно ли я понимаю, что DB2 осуществляет блокировки на уровне страницы? Или это свойство только pureScale? Или я вообще ошибаюсь?На уровне строк.
В pureScale есть дополнительная т.н. P-блокировка страницы, которая никак на транзакции не влияет, и введённа только для того, чтоб в страницу одновременно более одного узла не производило физической записи. Блокировка освобождается, как только физическое изменение страницы узлом завершилось.

softwarerузлы RAC разносим по филлиаламЯ как потенциальный покупатель хочу понять где эта узкая ниша RAC в которой действительно будут видны её плюсы,
По сравнению с чем?

Если сравнивать с shared none кластером, то самый очевидный плюс, пожалуй, в том, что при вылетании одного из узлов другие могут подхватить его нагрузку.В shared-nothing кластерах можно сконфигурировать standby машины, которые тоже могут подхватывать нагрузку отказавших узлов.
У IBM в хранилищах так и сделано, когда все серверы разбиваются на группы по 5 или более машин, и в каждой группе по 1-му standby, готовому подхватить нагрузку любого из отказавших в группе серверов.
Кроме того, и mutual takeover тоже можно сконфигурировать.

Yo.!на счет RDMA - в 11g появился протокол RDS v2 (OFED 1.2.5) под Linux который прямо с IB уровнем работает. как я понимаю полный аналог тому, что в pureScale.Ничего подобного.
RDS - сокетный протокол, требующий прерываний.
uDAPL - не требует.
См. дискуссию тут .

softwarerMark BarinsteinКроме того, и mutual takeover тоже можно сконфигурировать.
Вот этого уже не совсем представляю.Это когда, например, есть 2 сервера, 1-й обслуживает ноды 0-3, 2-й: 4-7.
Вместо того, чтоб держать 3-й standby сервер, готовый подхватить ноды любого из первых 2-х, эти 2 сервера настраиваются так, чтобы подхватить нагрузку друг друга.
Минус тут в том, что производительность кластера падает при отказе одного из серверов, поэтому такая конфигурация редко используется.

Yo.!какие сокеты на IB access layer ? сокты двумя уровнями вышеВы это ... свои ссылки-то сами читаете?

Стр. 7-9:

What is RDS?

Vision Statement
• A low overhead, low latency, high bandwidth, ultra reliable, supportable, IPC protocol and transport system
• Which matches Oracle’s existing IPC models for RAC communication
• Optimized for transfers from 200 bytes to 8 MB

Goals and Objectives
• Support for a reliable datagram IPC
• Based on Socket API
• Minimal code change / testing for Oracle
• Runs over InfiniBand, 10 Gig Ethernet, and iWARP

softwarerMark Barinsteinэти 2 сервера настраиваются так, чтобы подхватить нагрузку друг друга.
Я не очень представляю себе, как "горячей" базе можно сказать подхватить заодно другую базу. Но хорошо, если так.
Это одна база.
Ноды - части этой базы.
В shared nothing, грубо говоря, каждая нода имеет свою дисковую подсистему и обслуживается своим набором процессов.
Нет ничего особо сложного в том, чтоб, скажем, к 2-м севрерам физически подключить дисковые подсистемы обоих серверов, соотв. образом настроить кластерное ПО, чтоб при обнаружении отказа управление ресурсами отказавшего сервера переключалось на другой (монтировались файловые стистемы, поднимались виртуальные IP, запускались соотв. процессы и т.д.).
softwarerMark BarinsteinМинус тут в том, что производительность кластера падает при отказе одного из серверов, поэтому такая конфигурация редко используется.
Ну, если грубо, то она падает до того значения, которое в случае конфигурации "со стендбаем" имеет постоянно.Нет.
В случае со standby производительность не падает, ведь в норме standby не обслуживает запросы.
Ну, если, конечно, в HA группе будет более одного одновременного отказа.