RAC ЧАВО

Ниже я постараюсь ответить на несколько вопросов по технологии Oracle RAC, которые задаются на мой взгляд наиболее часто - RAC ЧАВО (Часто задаваемые Вопросы и Ответы). Хочу также поблагодарить Игоря Мельникова (Igor.Melnikov) за участие в сборе материалов. Данный пост обновлен 18.07 2007

Прежде всего мне хочется упомянуть малоизвестный факт об истории технологии RAC. Эта технологий появилась еще в версии Oracle 6, в 1985 году, до появления в СУБД Oracle pl/sql и знаменитого row locking механизма http://www.oracle.com/corporate/home2.html). Работала она правда только под VAX машинами. Уже в следующей версии, 7-ой Oracle Parallel Server работал на нескольких платформах.

Мне кажется, в IT очень важно понимать, сколько лет развивается та или иная технология. Потому что, часто они быстро появляются, и также быстро пропадают. В последние несколько лет тема Grid является заглавной для новых выпусков БД Oracle. Так 9i была выпущена со слоганом Unbreakable, подразумевая что ее "неубиваемость" основвывается на технологии Oracle RAC, версии 10g и 11g просто несут в себе индекс [G]rid. Итак, мы говорим о технологии, которой более 20 (!) лет.

Итак, вопросы которые часто задают:

1. Назовите где эта технология используется в России ?

Очень хороший вопрос. Примерно такой же хороший, как спросить "а имеют ли Ваши электроны Российское гражданство ?".
RAC - прежде всего технология, не зависящая от установленного в стране законодательства. Когда спрашивают про примеры использования бухгалтерской программы, то хотят уточнить, поддерживает ли она Росссийское законодательство. Это понятно, без этого использовать бухгалтерскую программу невозможно.
Но RAC - это технология. И законы физики работают, извините, вне границ государств.

Более правильный вопрос - "приведите пожалуйста примеры индустрий, которые используют данную технологию ?". OK, пожалуйста, познакомьтесь со специальным N страничным документом RAC customers book. Мне кажется там можно найти примеры по всем индустриям.

И все-таки почему так мало именно российских примеров внедрения RAС ?

a) Одна их причин в том, что ORACLE CIS работает только через партнеров. Т.е. все проекты проходят только через парнеров. Вот почему они не собирают/не публикуют references (а они есть, и очень большие ) - не могу сказать.

б) Наверно работает и наш Россиский менталитет - лучше ничего не говорить соседу, чтобы он не дай бог не позавидовал (?). Недаром есть даже анекдоты на эту тему. У нас вообще крайне неохотно говорят об используемых технологиях. Думаю, что увы, это наша Российская специфика. Вот Ваша организация готова выступить как reference использования технологий ?


2. Но ведь приложения в RAC не масштабируются и на одной большой машине работают лучше ? ( http://blogs.sun.com/dcb/entry/oracle_rac_s_secret)

Ответ очень прост: - если приложение не масштабируется, оно будет работать плохо даже на очень большой "железке". С примерами, я думаю, встречались очень многие.

Однако, действительно, до некоторой степени, RAC обнажает "узкие" места приложения. Думаю, что именно это и вызывает массовые слухи, о приложениях, которые не работают под RAC.

Я думаю, что лучшим ответом о масштабировании является, тот факт, что в RAC конфигурации работают SAP R/3 и Oracle E-Business Suite (последний в том числе в Россси :) ) Если приложение написано хорошо (а невозможно написать такого монстра плохо) - оно работает в RAC.

Из моего опыта следует, что приложения не всегда написаны хорошо. При переносе в RAC это становится видно. Но в этом случае, как правило, удается партиционировать приложение (т.е. разделить части приложения по узлам), что оставляет производительность как минимум на том же уровне, давай запас по процессорной мощности. Появляется время, для спокойного исправления ошибок.

Также в России (!) уже есть примеры, когда приложения "сжирало" самые большие имеющиеся на данный момент компьютеры (HP Superdom, SUN Fire 25K). Реальность таких IT - это непрерывно выспрашивать у вендора, когда будет более мощная машина. Я знаю примеры, когда откладывали внедрения новой бизнес функциональности из-за ожидания поставки очередного монстра.


3. Но ведь RAC это очень дорого ?

OK, давайте посчитаем. Прайс-лист Oracle доступен по адресу http://www.oracle.com/corporate/pricing/pricelists.html


Я выделяю 3 сегмента серверного оборудования:

- серверы начального уровня (2-4 процессора)
- серверы уровня предприятия (8 процессоров)
- high-end серверы (12 и более процессоров)


Серверы начального уровня

В большей своей массе в этом сегменте лидируют серверы с Intel архитектурой

Возьмем открытый прайс-лист компании Kraftway (www.kraftway.ru) от 09.07.2007

Увидим, что

Express 400 EM11 (4CPU Xeon 3Gz, 4Gb RAM) стоит 425,331 р

Express ISP ES24 (2CPU Xeon 3,2Gz, 2Gb RAM) стоит 94, 547 р

Для построения кластера нам понадобится 2 сервера Express ISP ES24 с общей стоимостью 189, 094 р

По лицензионным ограничениям на 2 2-х процессорных сервера можно установить Standard Edition, куда опция RAC уже включена бесплатно.

Итак, мы имеет разницу в цене между одним Express 400 EM11 и кластерным вариантом

425,331 - 189, 094 = 236,237 р ~ $9,000

( процессорные лицензии oracle стоят одинаково для обоих вариантов: 4 Socket * $15,000 )



Сервера уровня предприятия и high-end сервера


Я попробую посчитать на примере железа Sun Microsystems.
Нет, это не месть за пост Sun'овского инженера :) из предыдущего ответа. Я выбрал SUN, в первую очередь потому, что имеют многолетний опыт работы с техникой SUN, очень ее уважаю. Считаю, что Solaris - вообще одна из лучших ОС для Oracle (прошу это не обсуждать - это аксиома :)). Тот факт, что SUN испытывает (ывал) затруднения никак не связан с высочайшим уровнем ее технических разработок. Насколько я знаю, только в Sun Fire можно одновременно использовать процессоры нескольких поколений (!). Даже IBM не смогли (или не посчитали нужным) это реализовать.


Итак, я буду использовать открытый прайс-листы SUN по адресу
http://ru.sun.com/products/configurations/index.html


Давайте также учтем, что несмотря на размеры основного сервера, во всех серьезных организация принято устанавливать Standby DB или HA Cluster. С целью упрощения расчета стоимости я рассматриваю вариант Standby DB (см. также комментарии к посту ниже). Для варианта 1 сервера она нам нужна для отказоустойчивости и средства восстановления от логических ошибок, для варианта кластера - отказоустойчивость у нас уже есть, нужно только средство восстановления от логических ошибок.

Также в варианте 1 сервера бессмысленно ставить Standby DB на машину не равную основной - в противном случае она не сможет нести всю нагрузку промышленной системы.

Итак, Я взял несколько машин, все с процессорами UltraSPARC IV+, в каждой машине на процессор приходится 4Gb памяти.


Sun Fire V490 Server (4 CPU) - $65,000
Sun Fire V890 Server (8 CPU) - $131,000
Sun Fire E4900 (12 CPU) - $701,000
Sun Fire E6900 Server (24 CPU) - $1,409,000

Более полные спецификации с ценами


Серверы уровня предприятия
-------------
В качестве сервера уровня предприятия будем используется SF 890, в качестве равного ему кластерного варианта 2 сервера 2 SF490

Рассчитаем стоимость для SF 890

$131,000 (железо) + 8*$40,000 (процессорные лицензии Oracle) = $451,000

Рассчитаем стоимость для 2-х SF 490:

2*$65,000 (железо) + 8*$40,000 (процессорные лицензии Oracle) + 8*$20,000 (RAC option) = $610,000

$451,000 < $610,000 Как мы видим вариант RAC проигрывает на ~$160,000. Но давайте вспомним про Standby. Получим для SF 890 удвоение суммы, поскольку у нас две машины и Standby DB нужно полностью лицензировать. В кластерном варианте в качестве Standby достаточно поставить еще один SF 490 $902,000 ~ $610,000 + $65,0000 (железо) + 8*$40,000 (лицензия на standby) $902,000 < $995,000 Итак, мы видим, что RAC вариант проиграл грубо говоря ~$100,000 при общей стоимости системы ~$1,000,000. Теперь продумаем, что делать, когда нам потребуются еще скажем 2 CPU ? В случае SF 890 нам придется купить новое "железо", потратив $700,000 а в случае кластера - всего лишь докупить SF 490 - 65,000 (железо) + 4*$40,000 (Oracle) + 4*$20,000 (RAC options) = $305,000

High-end серверы
--------------------

В качестве high-end сервера будем использовать E4900 (12 CPU) , в качестве равного ему кластерного варианта 3 сервера SF490

Рассчитаем стоимость для E4900 (12 CPU)

$700,000 (железо) + 12*$40,000 (лицензии Oracle EE ) = $1,180,000

Рассчитаем стоимость для 3-х SF490:

3 * ( $65,000 (железо) + 4*$40,000 (Oracle) + 4*$20,000 (RAC options) ) = $915, 000

$1,180,000 > $915, 000

С RAC мы выиграли почти $280,000 !

Рассмотрим добавление standby. Для E4900 это удвоит стоимость системы, для кластерного варианта добавит еще один SF 490.

$2,360,000 ~ $915, 000 + $65,000 (железо) + 4*40,000 (Oracle)

$2,360,000 > $1,140,00

теперь разрыв увеличился до $1,120,000 (!)


При больших серверах разрыв еще больше увеличивается.



Выводы:

Удивительно, но в некоторых весьма реальных случаях экономия в случае использования RAC может составить порядка 1млн $. Вот так :).
Разрыв совершенно очевиден начиная с примерно 12 процессоров. На уровне 8 процессоров, следует учеть развитие ИС, standby систему - и выгода также будет очевидна. На уровне 4-х процессоров в игру вступает Standard Edition, куда опция RAC включена бесплатно.


Понятно, что я взял цены price лист без учета скидок, локальных налогов, технической поддержки. Что у разных вендоров картина может быть разной. Но я прошу Вас об одном - посчитайте. Это не очень сложно, а выводы могут быть весьма удивительными.


4. Если Все так здорово, то почему все-таки используют эту технологию не очень многие ?

Есть как минимум несколько причин:

a) "Железные" вендоры проводят вполне успешную политику. Очень часто, когда приглашают Oracle железо уже куплено и говорить о выборе технологии поздно. Можно лишь посоветовать начинать модернизацию IT с выбора технологии, а не большой железки.

б) Бюджетные организации страдают от необходимости продемонстрировать, куда именно вложили деньги. Если потратили $1 милллион на большой красивый шкаф - это понятно. А если на несколько маленьких машинок - то не очень. Я думаю, что все кто работал с бюджетными организациями понимает, о чем я пишу.

в) Мало кто хочет посчитать убытки от простоев. Страна большая. Подумаешь, уйдут одни клиенты, придут другие. В Европе совсем не так. Там автоматизированная бесперибойная система - основа бизнеса. За нее очень держатся. Она помогает зарабатывать деньги, а значит надо в нее вкладывыть.

PS
Если Вы все же остались недовольны моей идей использовать при подсчете standby - в следующем посте смотрите информацию про Sun T2000 :)

9 комментариев:

  1. Дмитрий, при всем уважении,но не согласен с подсчетом.
    Standby, как правило, выносить на отдельную площадку со своим массивом и прочее, поэтому не понятно как в rac конфигурации ограничились только добавлением одного узла, если первый сайт накрылся никакой rac не поможет и его узлы тоже, нужен полный комплект с таким же количеством узлов.

    ОтветитьУдалить
  2. Попробую пояснить свою мысль:

    1. Я говорю о локальных площадках, без разнесенных дата-центров.

    2. В расчетах я совершенно не учитываю дисковую подсистему считая ее одинаковой для обоих вариантов.

    3. В RAC уже есть несколько узлов, это надежно, поэтому standby добавляется для резервного копирования или защиты от логических ошибок.
    В случае одного из узлов standby нужен для того, чтобы принять на себя нагрузку. Т.е. предназначение у добавляемых standby разное...

    Ответил ? :)

    ОтветитьУдалить
  3. 1. Тогда это не корректное сравнение.
    Standby в большинстве случаев используется именно, как база на отдельной площадке для катастрофоустройчивости, если говорить о серьезных организациях ;)

    2. Согласен.
    3. RAC, это мое мнение, это решения прежде всего для масштабируемости, т.е. от отказа дисковой системы, он не спасет.
    Решение, как например Standby, он не обеспечивает. Т.е. Standby как правило активируют, если нет связи с master базой, или база ваще умерла, наверно только третье решение (read only база) применимо в случае использования RAC.

    ОтветитьУдалить
  4. 1. Хорошо, я примерно понял когда добавление Standby в мои примеры может быть некорректно - если есть удаленный датацентр. Спасибо.
    Я исправлю текст поста, чтобы это отметить.

    3. Можно ставить узлы RAC в разные дата-центры, в том числе сильно разнесенные ( ~ до 100км ) Тогда, в принципе и Stanby совсем не нужен.

    ОтветитьУдалить
  5. Добрый день.

    "3. Можно ставить узлы RAC в разные дата-центры, в том числе сильно разнесенные ( ~ до 100км ) Тогда, в принципе и Stanby совсем не нужен.
    "

    Дмитрий,
    не могу согласится с вами в том, что
    RAC нам может заменить стендбай...
    сам RAC может быть причиной проблемы
    приводящей к появлению SPOF,
    для этого на отдельной площадке и делается стендба
    внимательно читаем документы по той же MAA:
    RAC и Standby защищают от разных типов сбоев

    Александр

    ОтветитьУдалить
  6. Иногда, в резервном центре ставят standby, для того, чтобы на него переходить в случае чего. А раз так, то сервер должен быть в состоянии нести рабочую нагрузку, т.е. фактически быть таким же как и продакшен система. Мы же можем поставить узел кластера, тогда он не будет простаивать. Для standby же мы можем поставить существенно (на класс ниже) более дешевое оборудование. И решать скажем восстановление от логических ошибок на нем. Не знаю, понятна ли моя идея ?

    ОтветитьУдалить
  7. Дмитрий,
    идея понятна, но речь шла о другом:
    только RAC не защитит нас от всех видов сбоев,
    поэтому в MAA и предусмотрен для него Standby
    понятно, что можно до некоторой степени съекономить на оборудовании
    под standby-сервер - что бы мог хотя бы выдержать оперативную нагрузку.

    Делали один проект, когда
    для 4-х узлового кластера Standby был 2-х узловой,
    который при необходимости можно будет умощнить за счет выживших,
    серверов первичного кластера, если уже нельзя будет реанимировать его
    Практически по MAA.

    Опять же, сам RAC вносит элемент нестабильности, как и любое ПО,
    защищая при этом фактически только от сбоя(+ плановое обслуживание) узла
    чего только стоили частенькие падения ASM в 10.2.0.1 + 10.2.0.2
    благо 10.2.0.3 стабильнее

    Александр

    ОтветитьУдалить
  8. "только RAC не защитит нас от всех видов сбоев"
    Согласен, конечно нет, от логических ошибок или ошибок записи RAC не защитит..

    "
    для 4-х узлового кластера Standby был 2-х узловой,
    который при необходимости можно будет умощнить за счет выживших,
    "
    Тут не очень понял. Если можно поподробнее, можно в почту.


    "
    Опять же, сам RAC вносит элемент нестабильности, как и любое ПО,
    "

    так, прекратите мне тут пропаганду IBM + компания.. :))

    Если серьезно, говорили сегодня об этом же с Сергем Томиным. Ответ пожалуй такой: при определнных конфигурацих и нагрузках этот процент нестабильности мал, при некоторых - велик. Задача хорошего инженера - знать эти конфигурации и предупредить заказчика.

    ОтветитьУдалить
  9. "
    для 4-х узлового кластера Standby был 2-х узловой,
    который при необходимости можно будет умощнить за счет выживших,
    "
    Тут не очень понял. Если можно поподробнее, можно в почту.
    ==================
    чего подробнее то ?,
    пошаговую процедуру переноса сервера
    из одного кластера(помершего) в другой(выживший) при
    эквивалентной конфигурации железа и софта ?

    "так, прекратите мне тут пропаганду IBM + компания.. :))"
    ====================
    да я вас ни за что и не агитирую...
    ваш сай сам по себе есть пропаганда
    далеко не дешовой(беспроблемной) технологии РАК

    Поскольку самому приходится этим заниматься - вот и почитываю :-)

    "Если серьезно, говорили сегодня об этом же с Сергем Томиным. Ответ пожалуй такой: при определнных конфигурацих и нагрузках этот процент нестабильности мал, при некоторых - велик. Задача хорошего инженера - знать эти конфигурации и предупредить заказчика.
    "
    полностью согласен с задачами хорошего инженера,
    вот только знания эти инженер в большинстве
    случаев получает на проблемах прохих(неудачных)
    конфигурациях конечного заказчика
    да еще и за его деньги,
    что тоже в общем то понятно :-)

    по поводу "хорошего инженера" - практика
    показывает, чем раньше он будет привлечен
    в проект, тем меньше у заказчика проблем!
    Одна проблема - мало "хороших" то...

    Всего!

    Улександр

    ОтветитьУдалить