RAC и Active Data Guard

Все время RAC сравнивали с Data Guard. Оба решения используются в том числе и для защиты от сбоя одного компьютера. Иногда пользователи считают, что могут и подождать активации Standby, не стоит платить денег за лицензии RAC. Даже аргумент, что после активации Standby требуется разогрев кеша БД, иногда не принимается в расчет. Пожалуй, основным аргументом в пользу RAC всегда было то, что машина, стоящая под Standby, не несет полезной нагрузки - т.е. простаивала.

И тут появляется опция Enterprise Edition Active Data Guard (ADG). Пожалуйста, открывайте на чтение Standby, в этот же момент продолжают накатываться изменения с primary. На семинаре DBOD я показывал, что в режиме Maximum Availbility задержка буквально несколько секунд. И теперь Вы можете запускать свои отчеты на Active Data Guard, Ваша Standby машина не простаивает !

Давайте рассмотрим в этой связи два вопроса - что нам делать с приложением, и сколько стоят лицензии Oracle в этих двух вариантах.

Про приложение

И для RAC и для ADG приложение должно быть разбито на сервисы. Вы конечно знаете, что сервисы, с одной стороны представляют собой логическую абстракцию общей нагрузки, с другой стороны сервисы заводятся в БД и OCR.

В конфигурации RAC сервисы используются для балансировки нагрузки, в ADG - с тем, чтобы поднять в триггере on startup database в зависимости от роли (primary, standby) либо RW сервисы, либо RO.

Про стоимость

RAC традиционно стоит 50% от стоимости Enterprise Edition. ADG значительно скромнее ~ 12%

Вместо заключения

Несомненно, ADG позволяет Вам масштабировать Ваше приложение. Но, только в том случае, если Ваша нагрузка RO составляет значимую часть от вашей общей нагрузки. Если нагрузка RO увеличится...Вы конечно можете поставить еще один Standby, но тут придется заплатить и за лицензии EE и за лицензии ADG. А если увеличится нагрузка RW ? Упс. Не очень гибко получается. К тому же, Вы же помните, что ADG это опция только EE. А что, если Ваш заказчик захочет приобрести Standart Edition (SE) ? На SE нет Data Guard. Т.е. Вы можете создать standby но логи Вам придется передавать вручную. И тут, (surprise, surprise !) хочется вспомнить, что RAC для Standart Edition - бесплатен. По моим представлениям, из-за этого, стоит сейчас весь код сразу разрабатывать с учетом особенностей RAC.

Тогда путь развития ИС заказчиков видится мне так:

  • Поставлем Standart Edition. Хочется надежности - пожалуйста RAC. Пока лицензируется только SE.
  • Не помещаемся в ограничения SE - Пожалуйста EE. Хочется надежности - лицензируем Standby
  • Не хватает производительности - покупаем Active Data Guard.
  • Опять не хватает - покупаем RAC.
Каждая инвестиция приносит значительное увеличение производительности. Но только ссли в системе сразу были заложены сервисы.

Более того, чтобы "научить" приложения отрабатывать потерю узла в RAC или primary в конфигурации с data guard нужно сделать одно и тоже. И тоже самое, для HA кластера. Напишу отдельно, как именно научить приложение отрабатывать потери текущего экземпляра.

2 комментария:

  1. >>Каждая инвестиция приносит значительное увеличение производительности. Но только ссли в системе сразу были заложены сервисы.
    Ну-ну :-) Все эти опции _могут_ принести пользу только "нормальным" приложениям, а всем остальным, что убивают большие шкафы - что мертвому припарка.

    ОтветитьУдалить
  2. Timur, конечно, Вы правы. Конечно, я старался описать, как правильно проектировать приложения с точки зрения HA.
    Но даже в тех приложениях, что убивают шкафы при желании можно что-то сделать. Было бы желание.

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