Высокая доступность (Oracle High Availability)
Википедия определяет высокую доступность как «характеристику системы, которая направлена на обеспечение согласованного уровня эксплуатационных характеристик, обычно времени безотказной работы в течение более длительного периода, чем обычно». Давайте немного это разберем.Во-первых, мы говорим о системе в целом, а не только о базе данных, веб-сервере или диске. Если организация обрабатывает заказы от клиентов, пользователи не будут считать систему «доступной», если база данных работает; но веб-сервер, отображающий страницы заказов, — нет. Мы также говорим о «…времени безотказной работы в течение более длительного периода, чем обычно». Нужно дать определение «нормальному».
"Нормальный" может варьироваться в зависимости от приложения и подхода к использованию. Например, если используется система для бухгалтерского учета, а все бухгалтеры работают с 8:00 до 17:00 с понедельника по пятницу, то «нормально» доступной система будет считаться с 8:00 до 17:00 с понедельника по пятницу. С другой стороны, если вы система, которая поддерживает экстренные службы, работает 24/7.
В определении также говорится об «эксплуатационных характеристиках». Это означает, что нужно будет определить это и для вашей организации. Есть ли у организации документированные соглашения об уровне обслуживания (SLA)? Они имеют решающее значение для измерения высокой доступности и аварийного восстановления.
Требования к доступности влияют на архитектуру системы, и на то, сколько будет стоить разработка и поддержка такой системы.
Аварийное восстановление (Oracle Disaster Recovery)
Википедия определяет аварийное восстановление как «набор политик, инструментов и процедур, обеспечивающих восстановление или продолжение жизненно важной технологической инфраструктуры и систем после стихийных бедствий или антропогенных катастроф». Далее говорится, что «аварийное восстановление сосредоточено на ИТ или технологических системах, поддерживающих критически важные бизнес-функции».Чтобы разобраться в этом, вот что Википедия говорит о катастрофе: «Бедствие — это серьезное нарушение, происходящее в течение относительно короткого времени, в функционировании сообщества или общества, влекущее за собой широкомасштабные человеческие, материальные, экономические или экологические потери и воздействия, которые превышают способность пострадавшего сообщества или общества справиться при использовании собственных ресурсов».
Нужно отметить, что катастрофа должна быть серьезной. Пожар в центре обработки данных может быть серьезным, но также может быть просто попкорн в микроволновой печи, а не сбой источника питания, который заполняет всю комнату дымом и вызывает срабатывание спринклерной системы? А как насчет отключения электроэнергии, если у вас есть резервный генератор, который запускается, и топлива достаточно на неделю?
Далее, что наиболее важно, бедствие должно быть широко распространенным и «превышать способность пострадавшего сообщества… справиться, используя свои собственные ресурсы». Опять же, потеря одного сервера, вероятно, не является катастрофой, хотя при отсутствии планирования он может быть вообще один.
High Availability vs Disaster Recovery
Теперь, когда дали определения высокой доступности и аварийному восстановлению, давайте посмотрим на некоторые различия и сходства.Сходства
И HA, и DR можно рассматривать как подмножества обеспечения непрерывности бизнеса или того, как мы обеспечиваем непрерывность бизнес-операций в случае, если произойдет что-то плохое.Ключевым компонентом успешных программ HA и DR является избыточность или устранение единых точек отказа. Для компонента базы данных систем и HA, и DR обычно включают создание копий базы данных; но по разным причинам (различия см. ниже).
Другой ключевой элемент HA и DR — оценка риска; что приводит к сопоставлению затрат и затрат. Риск землетрясения достаточно высок в некоторых районах Земли и практически отсутствует в других. Стоимость восстановления после отказа одного сервера значительно меньше, чем стоимость восстановления центра обработки данных после пожара. Оценка затрат и рисков позволяет создавать соответствующие программы управления персоналом и аварийного восстановления без больших затрат.
Обе системы HA и DR должны согласовать цели и меры; такие как доступность для систем высокой доступности, а также целевые точки восстановления и время восстановления для аварийного восстановления. Определим некоторые из этих мер в следующем разделе.
Отличия
Просто взглянув на определения, HA — о системах и о том, как они устроены, а DR — о политиках, инструментах и процедурах. При создании систем для обеспечения высокой доступности мы стараемся предотвратить отказ всей системы, устраняя единые точки отказа и автоматизируя процедуры переключения или восстановления.Однако, при построении систем аварийного восстановления; предполагается, что основная система вышла из строя и восстановление этой системы займет некоторое время.
Это связано с целями и мерами. Для систем высокой доступности они обычно определяются доступностью, которая выражается в процентах от ожидаемого времени доступности системы. Например, если есть система, которая должна быть доступна с 8:00 до 17:00, 5 дней в неделю; это 9 часов в день или 45 часов в неделю. Доступность 99,99% (четыре девятки) для такой системы обеспечит около 16 секунд простоя в неделю. Для системы 24×7 разрешенный период недоступности чуть более 6 секунд в неделю.
С другой стороны, системы аварийного восстановления обычно характеризуются определенным временем восстановления и точками отката. Например, мы можем восстановить системы после пожара в центре обработки данных за час и потерять всего 5 минут транзакций.
Определив условия и поставив цели и измерения, можно приступить к проектированию систем, отвечающих этим целям.
HA
Для систем высокой доступности нужно роектировать аварийное переключение или переключение между системами, которое соответствует целям доступности. Если есть цель достичь «четырех девяток», то даже в системе с доступностью 8/5, это почти наверняка означает устранение всех единичных точек отказа и автоматизацию аварийного переключения.DR
Что касается аварийного восстановления, необходимо убедиться, что системы могут пережить катастрофу, что обычно означает создание второй системы в месте, удаленном от основной, чтобы местные события, такие как погода, землетрясения или метеоритный дождь, не уничтожили обе системы. Аварийное восстановление после сбоя будет отличаться от аварийного переключения с высокой доступностью, отчасти из-за расстояния между двумя системами.Спасибо за внимание! В следующих статьях мы разберемся как Quest Shareplex может обеспечить High Availability и Disaster Recovery для СУБД Oracle.
Читайте продолжение:
Disaster Recovery для Oracle при помощи инструмента для репликации Shareplex (часть 2)
High Availability для Oracle при помощи инструмента для репликации Shareplex (часть 3)
Пишем на Хабре:
Сравнение Shareplex с Oracle GoldenGate в нашей статье на Хабре
Дополнительные вопросы относительно Shareplex вы можете задать через форму обратной связи на нашем сайте или другим удобным способом. Решение доступно в триальной версии, вы можете его попробовать, оценить возможности или сравнить с вашим текущим средством для репликации Oracle. Пилотные проекты и референсные встречи мы также проводим, пожалуйста, обращайтесь.
