Oracle: пример организации отказоустойчивой системы

В сегодняшней статье я хочу немного поговорить про организацию отказоустойчивой системы СУБД Oracle на конкретном примере. Исходные данные примерно такие: работа системы – 24 часа, 7 дней в неделю, нагрузка – до 1500 одновременно работающих пользователей внутри организации, размер базы данных порядка 10Тб. Нагрузка на базу данных смешанная: база используется как для онлайн-транзакций, так и для аналитики (не очень хорошее решение, на самом деле, но такова архитектура прикладного ПО, от которого пока нет возможности отказаться). База используется для онлайн финансовых транзакций. Периодически нужно разворачивать тестовый контур для тестирования обновлений и решения текущих проблем. И, конечно же, строго лимитированный бюджет.

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

Итак, исходные данные есть. С чего начинается обычно построение отказоустойчивой системы? Конечно же, со сбора, формализации и анализа требований к доступности системы, сведений по требованиям ко времени восстановления в случае сбоя (времени простоя, RTO) и времени, за какой период возможна потеря данных (точке возврата, RPO). Эти требования обычно ИТ-подразделение запрашивает либо согласует с бизнес-подразделениями. Вторым шагом идет сбор, формализация и анализ требований к качеству функционирования системы (набор достаточно легко измеряемых параметров качества работы системы, как то пропускная способность, время отклика, максимальное количество одновременных соединений и тп., SLO (service level objective)). При сборе сведений крайне важно собрать раздельно требования по функционированию системы в обычном режиме и в аварийном режиме (в случае сбоя, в случае перехода на резерв). Обеспечить такой же уровень качества сервиса при переходе на резерв на короткий отрезок времени (до суток) может оказаться не так просто по факту, как кажется на первый взгляд. К примеру, один из ранее описанных мной метод повышения быстродействия СУБД Oracle, Oracle SmartFlashCache, архитектурно имеет достаточно большое время “прогрева” и в случае, если нужно будет перейти на резерв, скажем, на время восстановления основного вычислительного центра, на 8 часов, может просто не дать вообще никакого заметного прироста в производительности. Те же самые нюансы необходимо учитывать и для гибридных массивов, использующих технологию миграции на твердотельные жесткие диски горячих блоков данных (tiering) или технологии кэширования горячих блоков данных на твердотельных дисках(flashcache), особенно если эта миграция делается по расписанию в моменты наименьшей нагрузки на массив.

В моем конкретном примере требования выглядят примерно так: допустимое время простоя до 60 минут в случае сбоя, регламентное время обслуживания – до 8 часов в строго отведенное время, не чаще 4 раз в год, потеря данных не допускается, допустимо снижение качества сервиса при сбоях. Требования по сути явились неким компромиссом между качеством работы системы, в том числе в случае сбоя, и количеством затраченных средств. Требования формализованы в виде некоего локального документа, который согласован с бизнес-подразделениями организации и подписан ее руководителем.

Какие технологии Oracle доступны, если мы ведем речь про построение отказоустойчивой системы? Этот вопрос достаточно хорошо и подробно описан в документации Oracle, Oracle MAA Reference Architectures и более подробном документе High Availability Architectures and Solutions. У меня же получился некий гибрид, не упомянутый явно в документации Oracle.

От кластера RAC пришлось отказаться из-за стоимости лицензирования решения. Поэтому в основном ЦОДе – один вычислительный узел и одна СХД. На резервном вычислительном центре – точно такой же по производительности вычислительный узел и точно такая же СХД. Репликация – physical standby database, режим maximum availability. К этой связке серверов настроен каскадный standby, расположенный в альтернативном месте, который применяет журналы транзакций с задержкой 24 часа. Каскадный standby расположен на отдельной СХД, тестовой. Таким образом, схема предполагает тройное резервирование по хранению актуальных наборов файлов базы данных и дополнительно резервная копия.

cascad

Типичные сценарии.

  1. Выход из строя основного вычислительного центра либо узлов системы (сервер, коммутатор, система хранения данных) в основном вычислительном центре. В этом случае работа переключается на систему в резервном вычислительном центре, у которой есть standby со своим вычислительным узлом и системой хранения данных.
  2. Выход из строя резервного вычислительного центра либо узлов системы (сервер, коммутатор, система хранения данных) в резервном вычислительном центре. В этом случае в качестве standby используется каскадный standby.
  3. В основной базе данных произошло удаление таблицы/данных с таблицы в 9:00. В этом случае мы делаем snapshot с каскадного standby средствами СХД и открываем каскадную базу данных на время, максимально близкое к моменту удаления данных (8:59) либо до нужного SCN. Данные из открытой БД восстанавливаются в продуктивную базу данных. Процесс создания snapshot и открытия базы – не более 15 минут. Интервал, за который утеряны данные, минимален.
  4. В основной базе данных в 9:00 обнаружена ошибка, необходим тестовый контур для анализа ситуации. Опять же, мы делаем snapshot с каскадного standby средствами СХД и открываем каскадную базу данных на время, максимально близкое к моменту возникновения проблемы (8:59). Разработчики получают возможность анализировать проблему на реальных данных уже через 15 минут после запроса на создание тестового контура.

Минус у данной схемы, очевидно, в несколько выросшей стоимости решения в целом из-за наличия каскадного standby. Плюс, опять же, тройное резервирование по хранению файлов данных, что значительно уменьшает вероятность потери данных в случае сбоев (технических, логических, в следствие человеческого фактора) и значительно снижает время восстановления, повышает % доступности услуги.

Высказать свое мнение вы можете в комментариях.

Всем добра 🙂

Опубликовано в oracle

Оставить комментарий