Mirroring_cache - writeimagejournal.com

INTERSYSTEMS CACHÉ® DATABASE MIRRORING
Технология зеркалирования баз данных для построения надежной инфраструктуры с функцией быстрого
автоматического аварийного переключения в случае сбоя
СОДЕРЖАНИЕ
Краткое описание
Вступление
Обзор функциональности
Система зеркалирования
Асинхронные узлы
Аварийное переключение на системном уровне
Аварийное переключение на уровне приложений
Информация о технологии Caché
Информация о компании InterSystems
Автор: Вик Нагджи (Vik Nagjee), Product Manager
[email protected]
КРАТКОЕ ОПИСАНИЕ
Внедрение традиционных решений, предназначенных для обеспечения высокой доступности и
репликации информационных систем и данных, часто требует вложения значительных денежных
средств в инфраструктуру, развертывание решения, конфигурирование, лицензирование
программного обеспечения и планирование аварийно-восстановительных работ. Технология
зеркалирования Caché Database Mirroring спроектирована как экономичное решение для
быстрого и надежного автоматического аварийного переключения (failover) между двумя
системами Caché и является идеальным способом обеспечения высокой доступности для
предприятий и организаций.
Помимо обеспечения высокой доступности в случае незапланированных простоев технология
зеркалирования возможность гибко включать в программу эксплуатации системы Caché плановые
регламентные работы, требующие останова системы (например, при изменениях настройки
Caché, модернизации оборудования или программных средств и т.д.) без негативного
воздействия на выполнение соглашений об уровнях обслуживания (SLA), принятых в организации.
Совместное использование предлагаемой технологии зеркалирования и серверов приложений,
поддерживающих разработанный компанией InterSystems протокол Enterprise Caché Protocol
(ECP), позволяет добиться еще более высокого уровня доступности. Благодаря использованию
этого протокола сервер приложений воспринимает аварийное переключение просто как
перезапуск сервера данных, и беспрепятственно продолжает обработку данных на новой системе
после завершения выполнения аварийного переключения на нее, тем самым сводя к минимуму
нарушение выполнения бизнес-процессов и работы пользователей. Возможность размещения и
настройки узлов зеркальной конфигурации в разных центрах обработки данных обеспечивает
дополнительную избыточность резервирования и защиту от серьезных аварий.
Традиционные решения по обеспечению высокой доступности, полагающиеся на совместно
используемые ресурсы (например, на совместно используемую дисковую систему), часто
характеризуются тем, что компоненты такого решения одновременно подвержены риску сбоя
коллективно используемого ресурса). Технология зеркалирования уменьшает этот риск за счет
того, что в основной и в резервной системах зеркалирования используются независимые
компоненты. Кроме того, благодаря применению логической репликации данных технология
зеркалирования позволяет снизить риски, присущие физической репликации данных, включая
возможные ошибки в порядке обновления данных и распространение ошибок, связанных с
физическими сбоями носителей, что вполне возможно в случае применения других технологий
репликации, таких как репликация на базе сети хранения данных (SAN).
Наконец, технология зеркалирования предусматривает применение особого компонента –
асинхронного узла (Async Member), которая может быть сконфигурирована для получения
обновлений из многочисленных систем зеркалирования, развернутых в организации. Это
позволяет единой системе функционировать в качестве полноценного многоцелевого
корпоративного хранилища данных для решения задач поиска полезной информации (data
mining) и бизнес-аналитики с использованием системы InterSystems DeepSee™. Применение
асинхронного узла также возможно в модели аварийного восстановления. В этом случае одна
система зеркалирования может быть использована для обновления данных на шести
географически распределенных асинхронных узлах. Эта модель является надежной основой для
создания среды распределенной репликации данных, позволяющей организации реализовать все
выгоды от гарантированного обеспечения непрерывности своей деятельности.
ОСНОВНЫЕ СВОЙСТВА И ПРЕИМУЩЕСТВА:

Экономичное решение для обеспечения высокой доступности систем на основе баз
данных с функцией автоматического аварийного переключения

Минимизация рисков сбоя совместно используемых ресурсов за счет избыточности
компонентов

Минимизация риска распространения ошибок, вызванных физическим сбоем носителя, за
счет применения логической репликации данных

Эффективное решение для отработки как плановых, так и неплановых остановов

Обеспечение непрерывности деятельности организации благодаря возможности
применения географически распределенной схемы аварийного восстановления

Решения задач бизнес-аналитики и формирования отчетности за счет возможности
применения конфигурации с централизованным корпоративным хранилищем данных
ВСТУПЛЕНИЕ
Убытки от простоя информационной системы могут измеряться тысячами, а то и миллионами
долларов, в зависимости от вида и продолжительности перебоев в ее работе и типа ИС.
Доступность ИС – ключевой фактор успеха в бизнесе. Поэтому целью большинства организаций
является обеспечение максимальной доступности при минимальном времени простоя ИС – как в
случае запланированных остановов (в частности, на время регламентных работ), так и в случае
незапланированных простоев (как, например, в случае сбоев ПО или оборудования).
В Таблице 1 приведены примеры приемлемых значений времени простоя, соответствующих
различным плановым показателям доступности:
Доступность в %
Время простоя за год
31 секунд
Время простоя за
месяц
2,59 секунд
Время простоя за
неделю
0,605 секунд
99,9999% («шесть
девяток»)
99,999% («пять
девяток»)
99,99% («четыре
девятки»)
99.9% («три девятки»)
5,26 минут
25,9 секунд
6,05 секунд
52,6 минут
4,32 минут
1,01 минут
8,67 часов
43,2 минут
10,1 минут
99% («две девятки»)
95%
3,65 дней
18,25 дней
7,20 часов
36 часов
1,68 часов
8,4 часов
90%
36,5 дней
72 часа
16,8 часов
Таблица 1. Матрица доступности
Решения для обеспечения высокой доступности данных обычно создаются на основе соглашений
об уровнях обслуживания (SLA) применительно к каждой конкретной прикладной программной
системе, используемой в организации. На Рисунке 1 приведены оценочные данные о стоимости
решения по обеспечению доступности ИС в зависимости от желаемого уровня доступности:
Системы избыточного резервирования
«Холодный» резерв
«Теплый» резерв
Автоматическое аварийное переключение (failover)
Постоянная доступность
Более дорогостоящее решение
Менее дорогостоящее решение
Рисунок 1. Уровни доступности
В конфигурациях стандартных решений используется избыточность на аппаратном уровне и на
уровне хранения данных. Кроме того, в такие решения встраиваются средства «холодного»
резервирования (cold standby), включая средства резервного копирования на магнитную ленту
и/или сетевые устройства. По мере повышения требований к доступности данных увеличивается и
сложность поддержки соответствующих систем, и расходы на их эксплуатацию. Употребление
систем «теплого» резервирования (warm standby), как правило, сопряжено со значительными
дополнительными затратами на приобретение лицензионного аппаратного оборудования и ПО и
зачастую предусматривает применение совместно используемых ресурсов, таких как совместно
используемые дисковые и кластерные файловые системы, которые нередко могут оказаться
единой точной отказа – общей сразу для нескольких входящих в конфигурацию компонентов.
Системы автоматического аварийного переключения (failover) могут включать в себя еще больше
аппаратных и программных средств (и, следовательно, быть источником еще больших расходов).
При этом такие системы, как правило, базируются на технологиях репликации данных на основе
сети хранения данных (SAN), что может накладывать географические ограничения на решение,
предназначенное для обеспечения постоянной доступности данных. И хотя состояние постоянной
доступности информационных систем, без сомнения, является идеалом, его достижение связано
с чрезвычайно большими сложностями и затратами. Поэтому большинство организаций
останавливается на архитектурах систем «теплого» резервирования.
Технология зеркалирования базы данных Caché Database Mirroring относится к решениям
обеспечения высокой доступности за счет автоматического аварийного переключения (failover) со
значительно меньшими затратами, чем на базе других технологий, и представляет собой
экономичное, комплексное и надежное решение для корпоративных пользователей.
ОБЗОР ФУНКЦИОНАЛЬНОСТИ
СИСТЕМА ЗЕРКАЛИРОВАНИЯ
Как показано на Рис. 2, система зеркалирования (Mirror) представляет собой логическую
комбинацию двух систем Caché, которые называются «узлами аварийного переключения»
(failover members) и являются физически независимыми системами, соединенными между собой
только по сети. Одна из систем берет на себя роль основного узла (Primary), вторая автоматически
становится резервным узлом (Backup).
Рисунок 2. Система зеркалирования
Для поддержания системы в актуальном состоянии зеркалированные базы данных основного и
резервного узлов синхронизируются в реальном масштабе времени. Синхронизация
осуществляется через сеть1 таким образом, чтобы минимизировать влияние данного процесса на
производительность основного узла. Резервный узел направляет подтверждения получения
зеркалированных данных по специальному выделенному каналу – Mirror Acknowledgement
Channel; эта процедура, помимо прочего, показывает степень актуальности данных на резервном
узле системы зеркалирования. Зеркалированные базы данных редактируются только на
основном узле; все зеркалированные базы данных в системе, определенной в качестве
резервного узла, поддерживаются в режиме «только для чтения», что позволяет предотвратить
случайные обновления этих БД.
В процессе зеркалирования участвует программа-агент Mirror Agent, поставляющая информацию
о работоспособности узлов и способствущая осуществлению процесса аварийного переключения.
Каждый из узлов «зеркала» имеет доступ к агенту противоположного узла по выделенному
каналу – Agent Channel.
Внешние клиенты (обращения через язык программирования, ODBC/JDBC/SQL-клиенты,
пользователи с непосредственным подключением и т.д.) подключаются к системе
зеркалирования по ее виртуальному IP-адресу - Mirror Virtual IP (VIP), - который задается в
процессе настройки системы. Этот адрес автоматически присваивается интерфейсу узла,
назначенного системой зеркалирования в качестве основного в данный момент. Указание VIPадреса необязательно: если он не задан, все внешние клиенты должны соединяться
непосредственно с работающим основным узлом и «знать» оба узла и роли, заданные им на
данный момент в составе системы зеркалирования.
Серверы приложений, поддерживающие протокол InterSystems Enterprise Caché Protocol (ECP),
автоматически получают информацию об обоих узлах системы зеркалирования, в том числе о том,
какой из них в данный момент является основным. Другими словами, такие серверы приложений
не используют VIP-адрес, а напрямую подключаются к узлу, избранному в качестве основного.
(1) Данные передаются по TCP-каналу между основным и резервным узлами аварийного
переключения.
АСИНХРОННЫЕ УЗЛЫ
Как показано на Рис. 3, система зеркалирования также допускает применение специального
асинхронного узла (Async Member)2, который можно сконфигурировать таким образом, что он
будет получать обновления от одной или нескольких систем зеркалированния, развернутых на
предприятии. Таким образом обеспечивается возможность организовать единый узел,
действующий в качестве многоцелевого корпоративного хранилища данных. Такой асинхронный
узел обеспечивает дополнительную гибкость в работе, поскольку дает возможность выбирать,
какую из зеркалированных баз данных в системе зеркалирования следует реплицировать, а также
позволяет, при необходимости, реплицировать все зеркалированные базы данных из системы
зеркалирования.
Асинхронный узел может быть настроен как корпоративное хранилище данных. При этом одна
или более систем зеркалирования, используемых в организации, могут обновлять данные на
асинхронном узле, а тот, в свою очередь, выполнять роль централизованного репозитория. Такая
конфигурация обеспечивает широкие возможности для формирования отчетности, решения задач
бизнес-аналитики (BI) и поиска полезных данных (Data Mining) в масштабе всей организации. Так,
на асинхронном узле будет несложно развернуть систему InterSystems DeepSee, которая
позволяет встроить бизнес-аналитику в транзакционные приложения, чтобы в реальном времени
получать, например, информацию о ключевых показателях эффективности (KPI) по всей
организации для быстрого и эффективного централизованного анализа. Поскольку асинхронный
узел находится в синхронизованном состоянии с системой/системами зеркалирования, к которым
он подключен, данная архитектура является платформой для формирования операционной
отчетности, распределяемой по получателям в реальном масштабе времени.3
Наконец, как показано на Рис. 4, к одной системе зеркалирования можно подключить несколько4
асинхронных узлов и тем самым обеспечить еще более высокую степень непрерывности
деятельности организации и эффективность планов аварийно-восстановительных мероприятий
благодаря наличию среды для надежной репликации данных по всем многочисленным и –
нередко географически рассредоточенным – подразделениям организации.
(2) Асинхронные узлы не могут использоваться для аварийного переключения – они не входят в
состав системы зеркалирования.
(3) Так как данные на асинхронном узле постоянно обновляются вслед за изменениями данных в
системах зеркалирования, с которыми он соединен, синхронизация обновлений и результатов
запросов, направляемых на асинхронный узел не гарантируется. Корректность результатов
запросов к постоянно обновляемым данным должна обеспечиваться средствами приложения,
направляющего такие запросы на асинхронный узел.
(4) К одной системе зеркалирования может быть подключено до шести асинхронных узлов.
Рисунок 3: Асинхронный узел, получающий обновления из двух систем зеркалирования
Рисунок 4: Подключение нескольких (шести) асинхронных узлов к одной системе зеркалирования
АВАРИЙНОЕ ПЕРЕКЛЮЧЕНИЕ НА СИСТЕМНОМ УРОВНЕ
В подавляющем большинстве случаев технология зеркалирования дает возможность быстрого
автоматического переключения с одного узла на другой в случае аварии. Необходимость такого
аварийного переключения может быть вызвана событиями нескольких видов, например:



резервный узел не получает отклика от основного узла в течение заданного промежутка
времени, например, в случае проблем с сетевым соединением;
система Caché перестает реагировать на обращения на основном узле в результате сбоя в
приложении или хост-системе.
Переключение инициируется оператором системы или командой в составе скрипта.
Прежде, чем объявить о принятии на себя роли нового основного узла, резервный узел проводит
проверку полной актуальности данных. В процессе аварийного переключения настроенная
стандартным образом система зеркалирования защищена от возникновения таких, например,
ошибок, как, так называемый, «синдром раздвоения личности» – когда в течение какого-то
времени обе системы работают в качестве основных, что может привести к логическому
разрушению базы данных и потере ее целостности.
Процесс переключения с одного узла на другой может также быть запущен оператором системы
при запланированном останове системы, которая является на данный момент основной,
например, для выполнения регламентных работ, относящихся к аппаратному и программному
обеспечению. После завершения запланированного останова и возвращения системы в рабочий
режим автоматически осуществляется восстановление ее синхронизации в составе системы
зеркалирования.
Наконец, оператор системы может на время отключить основной узел без выполнения
переключения на резервный узел. Данный режим, к примеру, может быть полезен в том случае,
если нужно остановить основную систему на очень короткое время для регламентного
обслуживания. После возвращения основной системы в нормальный режим происходит
восстановление стандартной настройки автоматического аварийного переключения.
АВАРИЙНОЕ ПЕРЕКЛЮЧЕНИЕ НА УРОВНЕ ПРИЛОЖЕНИЙ
Если при настройке системы зеркалирования был установлен ее виртуальный IP-адрес (VIP), то
после успешного аварийного переключения на резервный узел он автоматически привязывается к
локальному интерфейсу узла, получившего роль основного. Это позволяет внешним клиентам
восстановить прежнее соединение5 с тем же VIP-адресом, что и до сбоя, что существенно
упрощает управление внешними программами-клиентами, потому что им не требуется знать о
многочисленных системах базы данных и IP-адресах. Если, однако, VIP-адрес не настроен, для
подключения внешних клиентов необходимо, чтобы на них были поддерживалась информация об
обоих узлах системы зеркалирования и о том, какой из ни является на данный момент основным.
При развертывании решения на основе протокола ECP серверы приложений воспринимают
переход на другой ресурс как состояние перезапуска сервера. Серверы приложений ECP
запрограммированы таким образом, что в таком случае они просто восстанавливают соединение
с новым основным узлом и продолжают выполнять незавершенные задачи. В ходе процесса
аварийного переключения пользователи, подключенные к серверу приложений, могут заметить
лишь мгновенную паузу, после которой работа продолжается в нормальном режиме. Такое
поведение системы возможно только в тех случаях, когда процесс аварийного переключения
между узлами укладывается в пределы заданного в ECP интервала восстановления (recovery
timeout). Если же время аварийного переключения оказывается больше (например, если данные
на резервном узле находились в неактуальном состоянии в момент переключения), инициируется
процедура ECP-восстановления (выполняется откат транзакций, снятие блокировок и т.д.) и
серверами приложений ECP устанавливаются новые соединения с новым узлом.
(5) Выполняется сброс настроек приложений и соединений, т.к. эти клиенты устанавливают
соединение с новыми системами. Все открытые транзакции возвращаются к точке
восстановления. Это не относится к ECP-соединениям (см. раздел «Система зеркалирования»).
ИНФОРМАЦИЯ О ТЕХНОЛОГИИ CACHÉ
InterSystems Caché® – сверхпроизводительная технология баз данных нового поколения. Она
сочетает в себе набор инструментов: объектную базу данных, высокопроизводительный
механизм SQL-запросов и мощные средства многомерного доступа к данным – с помощью
которых можно одновременно обращаться к одним и тем же данным. Данные определяются
только один раз в едином интегрированном словаре данных и мгновенно становятся доступными
с использованием всех названных методов доступа. Технология Caché обеспечивает создание ИТрешений, обладающих уровнем производительности, масштабируемости, быстроты
программирования и простоты применения, которого невозможно достичь с помощью
реляционных баз данных.
Caché – это больше, чем просто технология баз данных. Caché включает в себя сервер приложений
с расширенными возможностями объектного программирования, легкую интегрируемость с
широким спектром технологий и чрезвычайно производительную среду исполнения,
использующую уникальную технологию кэширования данных.
Caché предоставляется с несколькими встроенными языками: Caché ObjectScript – мощным, при
этом легко осваиваемым языком программирования; Caché Basic – расширенной версией широко
распространенного языка Basic, включая расширения для высокопроизводительного доступа к
данным и объектную технологию; и Caché MVBasic – вариантом языка Basic, используемого
приложениями MultiValue (иногда называемыми «приложениями Pick»). Другие языки
программирования, такие как Java, C# и C++, поддерживаются через call-in-интерфейсы и прочие
интерфейсы, включая ODBC, JDBC и .NET, а также через предоставляемый Caché объектный
интерфейс, который позволяет получать доступ к базе данных и другим средствам Caché как к
свойствам и методам.
Кроме того, Caché превосходит традиционные технологии баз данных, поскольку включает в себя
эффективную среду для разработки мощных приложений с доступом через web-браузер (webприложений). Технология Caché Server Pages (CSP) дает возможность быстро разрабатывать и
исполнять динамически генерируемые web-страницы. Тысячи web-пользователей – даже
применяющих недорогое аппаратное обеспечение – могут одновременно получать доступ к
приложениям базы данных.
Если применение браузера для доступа к приложению нецелесообразно, пользовательский
интерфейс обычно программируется с использованием одной из популярных технологий
разработки клиентских интерфейсов, таких как Java, .NET, Delphi, C# или C++. Наилучшие
результаты (максимальная скорость программирования, наибольшая производительность и
наименьшие эксплуатационные расходы), как правило, достигаются путем выполнения
оставшейся части процесса разработки внутри Caché. При этом технология Caché также
обеспечивает чрезвычайно высокий уровень совместимости с другими технологиями и
поддерживает все наиболее распространенные средства разработки, позволяя использовать
широкий спектр методологий разработки.