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 :)