Если вы уже используете Oracle Standard Edition (SE) или планируете перейти на эту редакцию, чтобы сократить расходы на Oracle, вы, наверняка, знаете, что там урезаны опции HA и DR. Поскольку DataGuard недоступен для Standard Edition, RAC — единственный вариант обеспечения высокой доступности без использования сторонних решений. Так было до тех пор, пока компания Oracle не убрала его поддержку в Oracle 19c и не объявила о новой опции под названием Standard Edition High Availability (SE2HA), которая при внимательном рассмотрении оказывается даунгрейдом с RAC.
В этой статье я расскажу об отличиях технологий SE2HA и RAC, а также расскажу как тут может пригодиться инструмент для репликации Quest Shareplex. Погнали!
Oracle RAC для SE обеспечивал высокую доступность в рамках единого ЦОД с двумя работающими узлами, поддерживающими единую базу данных. Для сравнения, SE2HA — это набор сценариев, которые запускаются поверх кластеров Oracle и используют Grid Control для управления аварийным переключением. Т.к. SE2HA использует технологии Oracle Clusters и ASM, как основной, так и резервный сервер должны быть расположены в одном ЦОД и подключены к одному и тому же общему хранилищу. Как и RAC, SE2HA использует те же файлы базы данных, поэтому если они недоступны, база данных тоже становится недоступной. Выходит что SE2HA имеет те же ограничения в плане нахождения в одном ЦОД и те же точки отказа, что и RAC.
Архитектура SE2HA
Поскольку RAC представляет собой кластерную базу данных с архитектурой общего кэша, все серверы в пуле кластера активны и непрерывно обрабатывают трафик. Если сервер в кластерном пуле выходит из строя, база данных продолжает обрабатывать активность на оставшихся узлах. Другими словами, с RAC нет фактического аварийного переключения — вы получаете постоянную доступность при обработке сбоев сервера. Для сравнения, Oracle 19c SE High Availability будет отрабатывать отказ сервера следующим образом:
Ну, и нужно протестировать переключение, потому что такой тип восстановления точно займёт значительное время. В любом случае, это дольше, чем при использовании RAC. В таблице ниже я собрал ключевые особенности обоих технологий:
Важно помнить, что доступность — это не только обработка сбоев сервера, но и полное предотвращение простоев. Пользователи Oracle Standard Edition имели возможность использовать RAC для последовательного обновления. После удаления этой опции пользователи Standard Edition должны отключить базу данных для выполнения это операции. Учащение выпуска обновлений Oracle (ежеквартальные обновления, исправления и т.д.) усугубляет проблему.
Oracle почти наверняка желает клиентам обновления до Enterprise Edition. Возникает вопрос: действительно ли SE2HA полностью подойдет или можно рассмотреть и другой подход? Вместо того, чтобы оставаться на более ранней версии Oracle, предлагаю рассмотреть вариант с репликацией. Преимущества будут теми же самыми как и при использовании RAC.
В зависимости от стратегии репликации данных целевая база данных может быть такой же, как и исходная (полная репликация) или подмножеством источника (частичная репликация). Если цель — высокая доступность или аварийное восстановление, имеет смысл поддерживать полные реплики. Для анализа и отчетности можно уменьшить нагрузку на исходную базу данных, реплицируя подмножества (в соответствии с регионом или бизнес-функцией) базы данных на целевые объекты.
Пример архитектуры репликации
Shareplex поддерживает репликацию из Oracle (включая ASM, RAC, Exadata) в другой Oracle, в Kafka, PostgreSQL, SQL Server и в JSON-файлы. Один из популярных кейсов использования Shareplex — миграция из Oracle в PostgreSQL. Ключевая особенность Shareplex — контроль целостности данных при репликации и функционал онлайн-сравнения данных, который может быть задействован при подозрении на несогласованность данных. Более подробно о возможностях Shareplex можно узнать в моей предыдущей статье.
Если у вас есть задача репликации или миграции — оставьте заявку в форме обратной связи, попробуем помочь её решить.
В этой статье я расскажу об отличиях технологий SE2HA и RAC, а также расскажу как тут может пригодиться инструмент для репликации Quest Shareplex. Погнали!
Oracle RAC для SE обеспечивал высокую доступность в рамках единого ЦОД с двумя работающими узлами, поддерживающими единую базу данных. Для сравнения, SE2HA — это набор сценариев, которые запускаются поверх кластеров Oracle и используют Grid Control для управления аварийным переключением. Т.к. SE2HA использует технологии Oracle Clusters и ASM, как основной, так и резервный сервер должны быть расположены в одном ЦОД и подключены к одному и тому же общему хранилищу. Как и RAC, SE2HA использует те же файлы базы данных, поэтому если они недоступны, база данных тоже становится недоступной. Выходит что SE2HA имеет те же ограничения в плане нахождения в одном ЦОД и те же точки отказа, что и RAC.
Архитектура SE2HA
Поскольку RAC представляет собой кластерную базу данных с архитектурой общего кэша, все серверы в пуле кластера активны и непрерывно обрабатывают трафик. Если сервер в кластерном пуле выходит из строя, база данных продолжает обрабатывать активность на оставшихся узлах. Другими словами, с RAC нет фактического аварийного переключения — вы получаете постоянную доступность при обработке сбоев сервера. Для сравнения, Oracle 19c SE High Availability будет отрабатывать отказ сервера следующим образом:
- Экземпляр вышел из строя
- Grid Control идентифицировал сбой
- Grid Control подключает диски базы данных к назначенному серверу
- Grid Control запускает «спящий» экземпляр
- Экземпляр доступен для пользователей
Ну, и нужно протестировать переключение, потому что такой тип восстановления точно займёт значительное время. В любом случае, это дольше, чем при использовании RAC. В таблице ниже я собрал ключевые особенности обоих технологий:
| Характеристика | RAC | SE2HA |
| Архитектура | Oracle Grid | Oracle Grid |
| Тип кластера | Active/Active | Active/Passive |
| High Availability | Да | Да |
| Использование аппаратных ресурсов второй нодой | Да | Нет |
| Немедленное переключение на резервный экземпляр | Да | Нет |
| Ограничение в 1 сокет на экземпляр | Да | Нет |
| Количество одновременных потоков | 32 | 16 |
| Аварийное восстановление | Нет | Нет |
| Лицензирование по правилу 10 дней | Нет | Да |
Важно помнить, что доступность — это не только обработка сбоев сервера, но и полное предотвращение простоев. Пользователи Oracle Standard Edition имели возможность использовать RAC для последовательного обновления. После удаления этой опции пользователи Standard Edition должны отключить базу данных для выполнения это операции. Учащение выпуска обновлений Oracle (ежеквартальные обновления, исправления и т.д.) усугубляет проблему.
Oracle почти наверняка желает клиентам обновления до Enterprise Edition. Возникает вопрос: действительно ли SE2HA полностью подойдет или можно рассмотреть и другой подход? Вместо того, чтобы оставаться на более ранней версии Oracle, предлагаю рассмотреть вариант с репликацией. Преимущества будут теми же самыми как и при использовании RAC.
В зависимости от стратегии репликации данных целевая база данных может быть такой же, как и исходная (полная репликация) или подмножеством источника (частичная репликация). Если цель — высокая доступность или аварийное восстановление, имеет смысл поддерживать полные реплики. Для анализа и отчетности можно уменьшить нагрузку на исходную базу данных, реплицируя подмножества (в соответствии с регионом или бизнес-функцией) базы данных на целевые объекты.
Пример архитектуры репликации
Shareplex поддерживает репликацию из Oracle (включая ASM, RAC, Exadata) в другой Oracle, в Kafka, PostgreSQL, SQL Server и в JSON-файлы. Один из популярных кейсов использования Shareplex — миграция из Oracle в PostgreSQL. Ключевая особенность Shareplex — контроль целостности данных при репликации и функционал онлайн-сравнения данных, который может быть задействован при подозрении на несогласованность данных. Более подробно о возможностях Shareplex можно узнать в моей предыдущей статье.
Если у вас есть задача репликации или миграции — оставьте заявку в форме обратной связи, попробуем помочь её решить.