За прошедшие годы требования предприятий к доступности приложений на основе баз данных сильно возросли. Для соответствия этим требованиям предлагается использовать специализированные решения высокой доступности.
Сегодня почти не осталось таких деловых процессов, которые осуществлялись бы без поддержки ИТ. Удлиненный рабочий день сервисной службы, приложения в сети Internet или глобальный доступ к ним предполагают высокую доступность ресурсов — вплоть до 24 часов в сутки и семи дней в неделю. Теперь это условие распространяется не только на системы, непосредственно задействованные в ключевых деловых процессах, но также и на периферийные области.
Одновременно увеличилось количество потенциальных причин возникновения сбоев. Поскольку приложения содержат все большее число компонентов (к примеру, соединения через виртуальные частные сети (Virtual Private Network, VPN) или серверы Web), то в результате появляется множество потенциальных точек общесистемного отказа (Single Point of Failure, SPOF), когда в случае сбоя парализуется работа приложения. Кроме того, объединение различных программ в сеть, как это происходит, к примеру, в рамках сервис-ориентированной архитектуры (Service-Oriented Architecture, SOA), приводит к тому, что при сбое приложение доступно в ограниченной степени. Поскольку многие программные решения часто используют базы данных в качестве основы для хранения информации, очень важно обеспечить доступность баз данных (см. Рисунок 1).
ШЕСТЬ КАТЕГОРИЙ ВЫСОКОЙ ДОСТУПНОСТИ
Доступность чаще всего выражается в виде процентного соотношения между рабочим временем и периодом простоя. Доступность в 99,95% означает, что перерывы в работе составляют не более 5 ч за год. Такие данные полезны для сетевого маршрутизатора, но для приложений функциональное распределение часто оказывается содержательнее. Исследовательская группа Harvard Research Group (HRG) в своей классификации доступности (Availability Environment Classification, AEC) выделяет шесть классов (AEC 0-5). При AEC 0 прерывания допустимы и целостность данных не требуется, в то время как при AEC 5 функции должны быть неизменно доступными.
Знание о том, к какому классу готовности следует отнести различные применяемые на предприятии системы, играет определяющую роль при выборе решений высокой доступности (ВД). Чтобы сделать это, необходимо сначала выяснить последствия возможного сбоя и подсчитать их стоимость. Особенно сложно оценить косвенные или отложенные по времени последствия. Соотношение между продолжительностью простоя и нанесенным ущербом не всегда постоянно, при длительных перерывах в работе убытки могут расти экспоненциально. Решения высокой доступности хоть и ограничивают время простоя, но одновременно приводят к дополнительным инвестициям и эксплуатационным расходам, которые следует сопоставлять с ущербом, возникающим при простое. Нужно также учитывать затраты на администрирование решения высокой доступности.
На случай сбоя отдельных аппаратных компонентов защита реализуется довольно просто с помощью, например, систем RAID или избыточных блоков питания. Чтобы противостоять полному сбою сервера, требуется уже более сложная система кластеров. Однако при аварии даже оптимально функционирующий кластер не будет работать непрерывно. Если после замены сервера администратору придется сначала выполнить проверку целостности информации и провести мероприятия по восстановлению баз данных, то время простоя может достигнуть нескольких минут или даже часов. Кроме того, в кластерах имеется только одна логическая копия каждой базы данных, в случае ее повреждения база данных больше не пригодна к использованию.
СМЕНА БАЗЫ ДАННЫХ
Специальные решения высокой доступности для баз данных, к примеру, решение горячего резерва (Hot Standby) системы баз данных Conzept 16, обходят эту проблему. Помимо преодоления неожиданных сбоев, возникающих в результате ошибок аппаратного или программного обеспечения, они предусматривают плановые перерывы, к примеру, для проведения профилактических работ, заботятся о целостности данных (AEC-1) и о сокращении простоев до нескольких секунд (AEC-2).
Для этого в помощь первичному серверу базы данных выделяется еще один компьютер, на который осуществляется постоянное зеркалирование баз данных. Как и ранее, пользователи работают с информацией, хранящейся на первичном сервере. При любых изменениях на первичном компьютере система управления базой данных (Database Management System, DBMS) сравнивает их с содержимым вторичного сервера. Перенос данных осуществляется либо одновременно (синхронно), либо с задержкой во времени (асинхронно). Таким образом, на каждом сервере есть собственная полная копия базы данных.
Преимущество этого решения заключается в том, что серверы можно разнести в пространстве: например, установить вторичный сервер в защищенной от пожара зоне ЦОД или даже в резервном ЦОД. Кроме того, по сравнению с кластерными системами, такое решение оказывается более гибким в отношении аппаратного обеспечения. Так, обычно не возникает проблем при использовании серверов различной производительности и конфигурации, что ведет к немалой экономической выгоде.
Сравнение данных осуществляется на двух разных уровнях. В физической резервной базе данных изменения переносятся на уровне механизма хранения (Storage Engine). Такой метод слабо загружает вторичную систему, однако при определенных обстоятельствах может понадобиться перенос больших объемов данных. Кроме того, он чувствителен к ошибкам в подсистеме хранения. В логической резервной базе данных изменения регистрируются на уровне транзакций и должны заново обрабатываться вторичным сервером. Перемещаемые объемы данных меньше, но резервная система загружается сильнее. В логическом варианте резервную базу данных можно использовать и для других целей (в зависимости от системы базы данных). Так, ее можно открыть в режиме чтения, к примеру, для оценки или сохранения данных.
При сбое первичного сервера вторичная система распознает это состояние и переходит из резервного режима в активный (режим оперативного восстановления, или преодоления отказа — Failover). Все завершенные и переданные транзакции становятся снова доступными. Клиентские системы, определив сбой, переключаются на вторичный сервер. Это происходит полностью автоматически или инициируется пользователем. Таким образом, работа практически не прерывается.
При проведении плановых сервисных работ системный администратор заменяет активную систему вручную (Switch-over). Благодаря этому даже обширные ремонтные работы не ограничивают ее доступность, поскольку все это время можно, как прежде, полноценно использовать ресурсы вторичного сервера.
ОДНОГО КЛАСТЕРНОГО РЕШЕНИЯ НЕДОСТАТОЧНО
Чтобы обеспечить требуемый уровень доступности приложений на основе баз данных, одного кластерного решения мало. Производительной альтернативой служат резервные решения для баз данных, когда программное обеспечение предоставляет все необходимые функции для высокой доступности, независимо от используемого аппаратного обеспечения (см. врезку «Преимущества резервных решений для баз данных»).
Андрей Мюкке — руководитель развития баз данных Conzept 16 компании Vectorsoft.
© AWi Verlag
Преимущества резервных решений для баз данных
-
Сохранение целостности данных
-
Защита от потери данных
-
Минимизация периода простоя
-
Независимость от аппаратного обеспечения