Вероятно RAC вам не нужен
Перевод статьи Моанса Нургарда (Moans Noorgard) «You Probably Don`t Need RAC» 2003 года.
Если последний год вы проводили отпуск в Сибири или каком-то похожем месте, то, вероятно, вы еще не общались с продавцами из Oracle по поводу RAC. Но как только вы вернетесь домой и включите телефон то обязательно обнаружите ожидающее вас голосовое сообщение.
Oracle очень активно продвигает RAC. Вы получите высокий уровень доступности, невероятную масштабируемость, возможности распределения нагрузки, покупки дешевых Linux-серверов, улучшения в личной жизни и все в таком духе.
Звучит все очень здорово. Как можно ответить отказом на такое предложение?
RAC не OPS
Нет, RAC это не OPS (Oracle Parallel Server), но выглядит точно так же. Маркетологи из Oracle пытаются дистанцировать RAC от OPS, но я не понимаю зачем они это делают. Я имею ввиду следующее: если основной код используется повсеместно в течении многих лет, то это означает что он стабилен, отлажен и опробован. А если все пишется заново, то кто рискнет использовать его, например, в системах жизнеобеспечения? К счастью, утверждение о том что RAC не OPS — неверное. Основные части кода — GCS и GES — в значительной степени такие же какими и были всегда.
GES означает Global Enqueue Service, а GCS означает Global Cache Service. Позднее я коснусь их более детально.
Немного истории. OPS был создан для шестой версии Oracle. Тогда единственными кластерами были VAX/VMS кластеры, но к несчастью, VAX/VMS-овский Distributed Lock Manager (DLM) изначально создавался для управления и координации относительно небольшого количества ресурсов, таких как файлы и устройства. Он не был приспособлен к тысячам буферов в буферном кэше (у Oracle и у многих других). Он оказался слишком медленным для OPS.
Исходя из этого специалисты Oracle должны были написать собственный DML для VAX/VMS, что они и сделали. Для этого потребовалось некоторое время и DLM от Oracle появился только в версии 6.0.35. Ей даже присвоили номер «6.2» для того чтобы подчеркнуть новую возможность — OPS.
Помню одно из первых занятий по OPS (в Чикаго), сразу после моего прихода в Oracle. Тогда я думал что разработчики Oracle сошли с ума — они создали свой DML вместо того чтобы позволить сделать это ребятам из Digital (Digital Equipment Corporation) . В конце концов ведь именно они придумали кластеры и всю их концепцию.
Я ошибался. DLM от Oracle работал прекрасно и Digital адаптировали эту технологию и идеи в своем собственном DML. Таким образом, к моменту выхода седьмой версии Oracle опять использовал «родной» DML производства Digital.
После этого UNIX-вендоры стали делать кластеры (ну, например NCR занимался этим некоторое время). И они в основной своей массе использовали технологии DML от Oracle.
Когда в Microsoft начали заниматься собственными кластерами, конечно же, они не воспользовался DML технологиями от Oracle. Конечно же нет… Они использовали технологии Digital.
Веселый факт: код GES/GCS уже присутствовал в Oracle начиная с пятой версии. Бйорн Энгсиг (Bjorn Engsig), работавший с исходными кодами Oracle начиная с 1983, выяснил это и реализовал свой собственный, очень сырой, менеджер блокировок для датской кластерной unix-системы на которой впоследствии запускали пятую версю Oracle. Он заставил ее работать, но только в демонстрационных целях — его самописный менеджер блокировок в качестве основного использует уровень блокировок БД, что в общем-то не очень нужно.
PING
Системе Oracle нужно было убедиться в том что буфер не будет изменен двум различными процессами в одно и то же время. Но вставал вопрос — результаты какого процесса должны позднее записываться на диск? Таким образом, вместо «простой» сериализации доступа к одной копии блока в одном буфере (что, как мы хорошо знаем, достигается комбинацией хэш-групп, цепочек и защелок), Oracle нужно было согласовывать между узлами несколько копий блоков в нескольких буферных кэшах.
Это достигалось использованием нового вида блокировок (названного Parallel Cache Managment или PCM-блокировки). Они согласовывались между узлами/экземплярами используя DLM и различные фоновые процессы.
Когда возникал «конфликт», т.е. один и тот же блок/буфер запрашивался более чем одним экземпляром, «эксклюзивная» блокировка, присваеваемая первому «владельцу», понижалась до «разделяемой» блокировки, присваеваемой всем запрашивающим процессам. Это понижение/разделение могло быть выполнено только при условии что все «владельцы» видели одно и то же представление блока/буфера.
Таким образом, копия блока, который побывал в буферном кэше первого владельца записывалась на диск и далее эта копия блока читалась в остальные буферные кэши. Термин «пинг» был введен для описания запроса буфера другими экземплярами, когда он эксклюзивно принадлежит одному экземпляру.
Пингование через диск медленный процесс. А если у вас есть индекс на столбце, который продолжает расти в правую сторону, то крайний правый листовой блок может пинговаться между экземплярами вперед и назад. Поэтому пингование через диск может просто убить производительность вашей системы.
Решением этой проблемы является секционирование, временные табличные пространства (представлены в 7.3) в которых каждый экземпляр имеет свои собственные защелки вместо разделемого Словаря защелок (STlock — помните ora-1575?), индексы по реверсированному ключу (7.3), позволяющие случайным образом определять изменяемый блок индекса (даже при монотонном увеличении индекса) и другие трюки.
Oracle 8i: появление Cache Fusion
В Oracle 8i (это 8.1 где точка перемещена на верхнюю часть единицы) был представлен новый способ пингования через связку HSI (High-Speed Interconnect) или подобные ей, т.е. своего рода транспорт вида «память-память» вместо «память-диск-память». Это довольно трудоемкая задача, поэтому изначально новый механизм был реализован только для блоков/буферов согласованного чтения (CR).
Это работало для одних, но не работало для других. На нескольких инсталляциях OPS, здесь в Дании, они вынуждены были сознательно отключить это в версиях 8.1.6 и 8.1.7.
Кстати: в версии 8.0 Oracle презентовал их собственный, оригинальный механизм управления блокировками (Lock Manager — LM). Этим они дали понять что в скором времени они станут независимыми от DLM кода различных поставщиков.
Можно сказать что Lock Manager был эквивалентом части платформозависимых исходных кодов Oracle, которая переросла в небольшой уровень известный как OSD (Operating System Dependent). С введением интегрированного LM осталась всего лишь маленькая задача — платформозависимое управление каждого порта. Все остальное было общим кодом. Еще один подход инженеров из Oracle Development который вызывает уважение.
Oracle9i: Cache Fusion везде и с новым именем
С появлением Oracle 9i (которой называют и 9.0 и 9.2 просто для того чтобы смутить врага) все пингование осуществлялось через канал памяти, либо высокоскоростное соединение. Наконец-то!
Но я думаю что как раз когда версию 6.0.35 переименовывали в 6.2, был момент для переименования OPS в RAC.
Продавцы из Oracle начали проявлять неуважение к OPS, который они продвигали на протяжении десяти лет. По крайней мере здесь, в Дании.
Во многом RAC работает также как и OPS (который до сих пор работает на многих инсталляциях).
Конечно RAC умнее. Умнее своим подходом, значительно улучшенными технологиями и т.д. Но не забывайте что инженеры из Oracle основывались на надежном, опробованном и протестированном коде, который впоследствии они улучшили. Я говорю, например, об уровнях GES и GCS.
Итак почему же RAC лучше чем OPS?
По двум причинам:
Первая состоит в том что пингование через диск ограничивает масштабируемость, а пингование через каналы памяти увеличивает масштабируемость, потому что оно быстрее.
Насколько быстрее? Это очень, очень хороший вопрос. Oracle нужно сделать много проверок, выставить кучу защелок, и т.д. Все это для обеспечения согласованности во многих отношениях. Если вас интересует наилучший на сегодняшний день ответ посмотрите статью Кэри Милсап (Cary Milsap) на hotsos.com о том почему следует сосредоточиться на логических операциях ввода/вывода, вместо физизических. Оказывается логический ввод/вывод примерно раз в 100 быстрее физического.
Эта цифра резко контрастирует с ОЗУ операциями ввода/вывода, осуществляемыми операционными системами — они, вероятно, в 10000 раз быстрее дискового ввода/вывода. Но ведь Oracle делает множество вещей (за что мы его и любим), и эта разница — их последствия. А необходимые издержки с RAC должны быть еще выше, потому что проверок становится больше.
Во-вторых, хитрости введенные в код направлены на то чтобы сделать координацию между экземплярами быстрее, проще — а иногда и вообще ее избежать. Лучшая оптимизации координации — ее отсутствие. Если Oracle не нужно использовать буфер для отправки копии в другой экземпляр, то он и не будет этого делать.
Означает ли это что RAC улучшит вашу жизнь? Да и нет. Или как скажет любой хороший консультант: «Когда как».
Вот пункты, которые необходимо рассмотреть, прежде чем вы распространите RAC по всему миру: стоимость, доступность, масшабируемость, управление, необходимые навыки и устранение неполадок.
Стоимость
В этом разделе речь пойдет о ценах из прайс-листа Oracle. Скидки могут варьироваться.
Oracle Enterprise Edition стоит 40000$ (47500$ осенью 2010) за один процессор или 800$ (950$) за зарегистрированного пользователя (named user plus — NUP), как он теперь называется. RAC стоит на 50% дороже, т.е. 60000$ и 1200$ за процессор и NUP, соответственно.
Пока я пишу это, я понимаю что RAC был предложен с 50% скидкой, т.е. 10000$ на американском рынке с Января по Февраль. Но это никак не отражалось в глобальном прайс-листе компании.
(Кстати: Опция партиционирования стоит 25% к стоимости CPU/NUP цены. OLAP и Data Mining еще по 50% за каждый. Spatial, Advanced Security и Label Security стоят по 25% каждый. Diagnostic Pack, Tuning Pack, Change Management Pack и Management Pack для SAP R/3 стоят 3000$ и 60$ за CPU/NUP.)
Итак, давайте поиграем с видением Ларри дешевых Linux кластеров на базе Intel. Давайте купим те два дешевых,
Стоимость оборудования: примерно 15.000$.
Цена за ОС (Linux): около 0.50$ или около того (когда как!)
Цена за Oracle с RAC: $480.000$
Итого полмиллиона долларов за Oracle. Иными словами: по 1 доллару тому кто двигает ящики, на каждые 32 доллара, которые получает Oracle.
В психологическом плане клиентам сложно понять тот факт что они должны что-то что намного дороже чем оборудование, на котором оно будет работать. Разрыв очень велик, и в ближайшее время Oracle нужно что-то с этим делать.
На рынке нет ничего похожего на RAC, но это не означает что RAC нужно обязательно покупать. Обычная я шучу, что это как покупка машины за 10000$ — в ней есть все что вы хотите получить от хорошей и стабильной машины. Кстати, подушки безопасности и система ABS стоят дополнительных 500$. Конечно хорошо иметь подушки и ABS — они повышают вашу безопасность. Но они стоят много денег, особенно по сравнению с базовой стоимостью автомобиля.
Есть и другие, косвенные, расходы, связанные с переходом на RAC: вашей организации потребуются новые навыки как в отношении RAC, так и в отношении кластеров. Например, если в вашей организации нет специалистов по кластерам, то придется их качественно обучать.
Вы должны иметь ввиду, что среда разработки (и, возможно, тестовая среда) также должны состоять из кластера и RAC. Иногда, корпорация Oracle, позволяет бесплатно использовать свои продукты на таких системах, а иногда нет — когда как.
RAC очень крутая технология. Но очень дорогая.
Доступность. Часть 1: 99.X% -> 98%
Я думаю что есть два способа оценить доступность (конечно однажды будет доказано, что я ошибался).
Первый способ такой: если у вас есть отдельный Unix-сервер, то он предоставляет доступность в 99.9% в течение года (некоторые говорят 99.5%, некоторые говорят 99.9%). Он просто работает. Обычно также работает и Oracle. Но если у вас Unix-кластер из двух узлов, то годовая доступность падает до 98%.
Да, удивительно, но две основных причины состоят в том, что повышение сложности (дополнительные слои кода, дополнительное оборудование и т.д.) для RAC и кластеров, влечет за собой дополнительное время простоя — дольше происходит загрузка кластера, запуск RAC, выполнение некоторых управленческих задач.
И если вы верите Gartner Group, Oracle и всем компаниям, которые говорят что 70% (или более) простоев вызваны человеческим фактором и недостатком знаний… то что же произойдет если вы перейдете к более сложным аппаратному комплексу и программному обеспечению?
Другой взгляд на доступность. Ваша отдельная система доступна 99.9% времени. Оставшаяся 0.1% — это то для чего существуют остальные узлы кластера.
Я работал с кластерами (VMS, UNIX и в настоящее время Windows) начиная с 1988 или 1989 или, если хотите, с момента когда вышел 6.0.35. Настройка, управление и использование кластеров всегда были сложным делом. Если вам нужно использовать кластеры в вашем бизнесе (по каким-то уважительным бизнес-требованиям), то также вам понадобится дополнительный персонал, дополнительные консультанты и дополнительные навыки для вашей организации.
Как технический директор небольшой компании которая предлагает услуги узких технических консультантов я, конечно же, доволен увеличением сложности клиентских установок. Это означает что они рано или поздно позовут нас (или Oracle). Поскольку мы живем за счет катастроф, проблем и неприятностей, я смотрю в светлое будущее, и я уверен в нем.
Какие есть альтернативы? Различные standby опции базы данных. Это может быть стандартная standby БД, появившаяся в 7.3, или Data Guard, или какая-то разработка третьих сторон, типа Shareplex от Quest (у меня абсолютно нет специфических знаний по этим продуктам — я просто знаю что они существуют, поэтому не покупайте их без консультаций с более знающими людьми).
Примите во внимание тот факт, что в последнее время Oracle изменил свою ценовую политику в отношении standby опций (это отметил один из подписчиков списка рассылки Oracle-L), так что в скором времени вам придется платить полную стоимость за лицензию для standby узлов, если вы используете их дольше 10 дней в году. И вы всегда будете платить полную цену за узлы Data Guard.
Конечно также вы можете сфантазировать и создать что-то свое. Мы привыкли использовать standby БД шестой версии накатывая архивные логи самостоятельно на другую базу данных в строгом режиме восстановления. Конечно это порождает массу проблем. Но мы это сделали. Или вы можете использовать log miner для извлечения DML из архивных логов и накатывать их на standby БД. Или вы можете сделать системные триггеры которые перехватывают все DDL и DML запросы к системе и складывают их в загрузочные файлы, которые впоследствии загружались бы в режиме реального времени, или близкого к реальному или вообще загружались бы позднее в другую систему.
Все эти альтернативы требуют небольшой работы, но все они имеют одну общую черту. Все это будет работать с Oracle Standart Edition, что позволит снизить цену с 40000$ до 15000$ за процессор.
Доступность. Часть 2: 25/8/370?
Недавно, мои клиенты не работали на протяжении приблизительно пяти часов. Им нужно было обновить версию RAC с 9.2.0.1.0 на 9.2.0.3.0. Они очень хорошо подготовились, так что все было тщательно спланировано. И это заняло пять часов. Вот последовательность действий, которую они выполняли:
0. Остановили Weblogic
1. Остановили оба экземпляра.
2. Включили SW
3. Накатите патч на один узел, что автоматически пропатчило другой.
4. Запустили один экземпляр в некластерном режиме (параметр cluster_database = false).
5. Запустили миграцию (т. е. установите параметры с подчеркиванием).
6. Выполнили catpatch.sql
7. Остановили систему.
8. Запустили систему.
Я уверен что это можно было сделать быстрее, но все это время системный диск сервера был занят, выполняя действия которые он должен был выполнить. Во время обновления не было «зависаний» или «ошибок». И все было сделано в соответствии с документацией Oracle (в которой описано все что было выше). И это просто заняло пять часов.
Многие люди которым я это рассказывал были удивлены. Если вы задумаетесь об этом, то поймете что вы обновляете не узлы или экземпляры. Вы обновлете базу данных. В инсталляции RAC Oracle используется одна база данных.
Таким образом в действительности нет такого понятия как 24/7/365 (или 25/8/370, что вполне имеет право на существование в реальном мире). Есть HA (High Availability) параметры базы данных, плюс запланированное время на обслуживание.
Oracle не использует практику накатываемых обновлений. Oracle не использует «горячее обновление». Так что ваша база данных должна быть остановлена пока вы не обновите или не пропатчите ее.
Возможно вы можете продублировать базу, например, с Oracle Data Guard, так чтобы ваши пользователи работали с одной базой, пока вы обновляете вторую? Я уверен что это возможно, но я не понимаю как это сделать с тех пор как Data Guard для своей работы стал требовать патчи, установленные в Oracle и в ОС. Получается, что вы должно остановить и обновить обе базы данных в одно и то же время.
Если поддерживается вариант когда Data Guard работает пока вы обновляете основную базу до новой версии или пока вы накатываете новый патч, то мне интересны детали.
А вы заметили что что-то отсутствует в списке действий, который я привел выше? Пользователь не сделал резервную копию перед обновлением. По очень веским причинам Oracle рекомендует делать полную и корректную резервную копию перед тем как вы будете накатывать патч или обновлять систему. Этот клиент этого не сделал этого, ну а вы должны не забывать об этом. Oracle даже рекомендует (опять же по очень веским и правильным причинам) сделать новую резервную копию после того как вы закончите процесс обновления.
Так что у нас есть RAC плюс запланированные простои. Но еще есть критические патчи, которые должны быть установлены как можно быстрее. Они могут появляться из-за обнаруженных ошибок окружения или это могут быть заплатки в системе безопасности. Время, требуемое для применения критических патчей очень трудно спланировать.
Если вы используете RAC, то у вас есть два узла, два экземпляра и одна база данных. Эта база данных может сломаться из-за повреждения словаря (я уверен, мы все это наблюдали) или она может сломаться из-за необходимости обновления или установки патча. И все это — время простоя для всей вашей RAC-системы.
Масштабируемость
Конечно RAC масштабируем гораздо лучше чем OPS, и вам не нужно придумывать всякие хитрости для того чтобы удачно провести масштабировать систему.
Но! Если вы избавитесь в системе (ИТ или любой другой) от одного узкого места, то сразу обязательно появится новое. Оно может быть меньше предыдущего (я всегда надеюсь и обычно так и получается, но не всегда), но все же оно остается узким местом.
В RAC пингование производится с помощью ресурсов процессора. Они гораздо быстрее дисковых. Но если в вашей системе ограничено процессорное время, то наверное RAC не сможет получить достаточно CPU для пингования?
Голландец Марио Брудбаккер (Mario Broodbakker) из Digital/Compaq/HP провел несколько интересных тестов на RAC, которые доказали две вещи:
Очень важно иметь достаточно свободного процессорного времени для пингования в RAC.
Вы опять можете попасть в ситуацию когда для улучшения производительности необходимо прибегнуть к традиционным для OPS обходныем маневрам (партиционирование и т.д.). Временами может пригодиться даже такой удивительно сложный и мистический параметр как GC_FILES_TO_LOCK. Его описание было специально удалено из документации, т.к. он был неправильно интерпретирован отделом Oracle Marketing.
Вы можете сказать: конечно вы должны иметь необходимый запас CPU для пинговой активности RAC — Эй, ресурсы всегда нужно выделять профессионально. Да. Но что если вдруг куча фоновых задач или паетных процессов будут бороться за ресурсы CPU (PX, DMBS_JOB, резервные копии, копирование файлов, что угодно)?
Да, вы можете запланировать множество ситуаций, но рано или поздно сложиться так что ваша система будет работать при 100% загрузке процессора, и вот тут с RAC вы увидите реально плохую производительность.
Если вам интересны результаты Марио о его тестировании RAC, дайте мне знать и буду счастлив переслать вам их. RAC Development уже планируют решить несколько вопросов, которые он поднял или которые уже адресовал им. Однако отсутствие необходимых процессорных ресурсов, это не то с чем Oracle или RAC могут справиться.
Обслуживание
OPS никогда не был так ужасен в управлении как RAC. Присваивание номера экземпляра каждому экземпляру, запуск и остановка экземпляров каждый раз производится в одном и том же порядке. Создайте простые скрипты для этих действий и сразу избавитесь от большей части заморочек!
Сейчас возможно делать очень умные вещи с группами экземплярова, и OEM оборудование было серьезно улучшено для работы с RAC — но большинство клиентов продолжают использовать кластеры из двух узлов с двумя экземплярами Oracle соответственно, и в этом случае они могут спокойно жить со старыми добрыми возможностями времен OPS.
И по прежнему при работе с RAC требуется больше навыков и времени для управления, нежели чем при работе без него. Добавленная сложность подразумевает дополнительные знания и дополнительное время. Конечно вы можете выйти из пложения, назвав обычный простой «запланированным простоем», «техобслуживанием» или «сервисным временем».
Тем не менее, конечной целью является максимальная доступность базы данных (или программ, от нее зависящих).
Необходимые знания
Я уже касался этого в нескольких местах этой статьи, так что просто повторю здесь что нужны не только знания и опыт работы с RAC, но также (и вероятно обязательно) нужна квалификация для работы с кластерами. Конечно, в том случае если ваша организация собирается использовать RAC.
Есть посторонние курсы Oracle RAC (три дня) и один курс, называемый DSI (Data Server Internals) для изучения внутреннего потребления Oracle.
Так же есть курсы RAC предлагаемые различными сторонними компаниями.
И еще есть много других людей, которые знают об OPS и RAC. Внимательно слушайте озлобленных, согбенных стариков, которые работали с OPS. Когда RAC подходит к своим критическим границам, вы все равно должны делать те же самые вещи которые были необходимы для работы с OPS.
Поиск неисправностей
Ах да, поиск неисправностей. Я видел много кластеров, которые в мое время просто замирали без каких-бы то видимых причин. Но в таких случаях всегда возможно сделать трассировочный или лог-файл (через ОС или через сам кластер).
Сформированный кластером лог файл или файл трассировки будет примерно размером с Техас. Вам будет сказано что только один или два человека во всей вендорской организации смогут правильно разобраться в нем.
Затем файлы (с размерами, обычно измеряемыми в гигабайтах) будут отправлены вендору и через несколько месяцев вам придет отчет о том что невозможно определить причину полного зависания или сбоя кластера, но вот этот параметр, вероятно, немного ниже нормы, а вот этот параметр, вероятно, чуть выше.
Это то что происходит всегда. Я никогда, действительно, никогда не видел вендора, который смог бы корректно диагностировать и объяснить подвисший кластер или кластер на котором произошел сбой.
В части Oracle я не так сильно переживаю. У Oracle наверняка проблемы с производительностью, причем это легко диагностировать используя Wait Interface. Либо, если вы получаете ошибки ORA-600, их можно также легко диагностировать, даже несмотря на то что вам придется потратить требуемые 42 часа на логгирование и поддержку iTAR или SR, или как он сейчас называется.
Другими словами, узнать причину из-за которой начались проблемы (если они есть) в Oracle гораздо проще нежели чем найти причину проблем в кластере.
Заключение
Если вам нужна система, которая должна быть запущена через несколько секунд после аварии, то вероятно вам нужен RAC.
Если вы не можете купить достаточно большую систему для утоления потребностей в CPU и памяти то, вероятно, вам нужен RAC.
Если вам в вашей организации в политических целях нужно прикрыть тылы, то вы можете купить кластеры, Oracle, RAC и что там вам нужно еще, а затем спокойно сказать: «Мы купили самую дорогую систему известную человечеству. Если что-то пойдет не так или система остановится, то это просто не может быть нашей виной.»
С другой стороны, вероятно RAC вам не нужен. Альтернативы обычно дешевле, проще в управлении и более эффективны.
Теперь, пожалуйста, докажите мне обратное.
© Moans Noorgard, 2003
Источник: You Probably Don’t Need RAC
Заметка автора о своей же статье, спустя три года (2006): A Brief Intro to Marketing (or: You Need RAC!)