Автор: Вик Нагджи (Vik Nagjee), Product Manager icon

Автор: Вик Нагджи (Vik Nagjee), Product Manager



НазваниеАвтор: Вик Нагджи (Vik Nagjee), Product Manager
Дата17.10.2016
Размер
ТипОбзор

INTERSYSTEMS CACHÉ® DATABASE MIRRORING

Технология зеркалирования баз данных для построения надежной инфраструктуры с функцией быстрого автоматического аварийного переключения в случае сбоя


СОДЕРЖАНИЕ


Краткое описание

Вступление

Обзор функциональности

Система зеркалирования

Асинхронные узлы

Аварийное переключение на системном уровне

Аварийное переключение на уровне приложений

Информация о технологии Caché

Информация о компании InterSystems


Автор: Вик Нагджи (Vik Nagjee), Product Manager

vik.nagjee@intersystems.com


^ КРАТКОЕ ОПИСАНИЕКРАТКОЕ ОПИСАНИЕ ИТ-РЕШЕНИЯ

Внедрение традиционных решений, предназначенных для обеспечения высокой доступности и репликации информационных систем и данных, часто требует вложения значительных денежных средств в инфраструктуру, развертывание решения, конфигурирование, лицензирование программного обеспечения и планирование аварийно-восстановительных работ. Технология зеркалирования Caché Database Mirroring спроектирована как экономичное решение для быстрого и надежного автоматического аварийного переключения (failover) между двумя системами Caché и является идеальным способом обеспечения высокой доступности для предприятий и организаций.

Помимо обеспечения высокой доступности в случае незапланированных простоев технология зеркалирования возможность гибко включать в программу эксплуатации системы Caché плановые регламентные работы, требующие останова системы (например, при изменениях настройки Caché, модернизации оборудования или программных средств и т.д.) без негативного воздействия на выполнение соглашений об уровнях обслуживания (SLA), принятых в организации. Совместное использование предлагаемой технологии зеркалирования и серверов приложений, поддерживающих разработанный компанией InterSystems протокол Enterprise Caché Protocol (ECP), позволяет добиться еще более высокого уровня доступности. Благодаря использованию этого протокола сервер приложений воспринимает аварийное переключение просто как перезапуск сервера данных, и беспрепятственно продолжает обработку данных на новой системе после завершения выполнения аварийного переключения на нее, тем самым сводя к минимуму нарушение выполнения бизнес-процессов и работы пользователей. Возможность размещения и настройки узлов зеркальной конфигурации в разных центрах обработки данных обеспечивает дополнительную избыточность резервирования и защиту от серьезных аварий.

Традиционные решения по обеспечению высокой доступности, полагающиеся на совместно используемые ресурсы (например, на совместно используемую дисковую систему), часто характеризуются тем, что компоненты такого решения одновременно подвержены риску сбоя коллективно используемого ресурса). Технология зеркалирования уменьшает этот риск за счет того, что в основной и в резервной системах зеркалирования используются независимые компоненты. Кроме того, благодаря применению логической репликации данных технология зеркалирования позволяет снизить риски, присущие физической репликации данных, включая возможные ошибки в порядке обновления данных и распространение ошибок, связанных с физическими сбоями носителей, что вполне возможно в случае применения других технологий репликации, таких как репликация на базе сети хранения данных (SAN).

Наконец, технология зеркалирования предусматривает применение особого компонента – асинхронного узла (Async Member), которая может быть сконфигурирована для получения обновлений из многочисленных систем зеркалирования, развернутых в организации. Это позволяет единой системе функционировать в качестве полноценного многоцелевого корпоративного хранилища данных для решения задач поиска полезной информации (data mining) и бизнес-аналитики с использованием системы InterSystems DeepSee™. Применение асинхронного узла также возможно в модели аварийного восстановления. В этом случае одна система зеркалирования может быть использована для обновления данных на шести географически распределенных асинхронных узлах. Эта модель является надежной основой для создания среды распределенной репликации данных, позволяющей организации реализовать все выгоды от гарантированного обеспечения непрерывности своей деятельности.

^ ОСНОВНЫЕ СВОЙСТВА И ПРЕИМУЩЕСТВА:

  • Экономичное решение для обеспечения высокой доступности систем на основе баз данных с функцией автоматического аварийного переключения

  • Минимизация рисков сбоя совместно используемых ресурсов за счет избыточности компонентов

  • Минимизация риска распространения ошибок, вызванных физическим сбоем носителя, за счет применения логической репликации данных

  • Эффективное решение для отработки как плановых, так и неплановых остановов

  • Обеспечение непрерывности деятельности организации благодаря возможности применения географически распределенной схемы аварийного восстановления

  • Решения задач бизнес-аналитики и формирования отчетности за счет возможности применения конфигурации с централизованным корпоративным хранилищем данных



ВСТУПЛЕНИЕ

Убытки от простоя информационной системы могут измеряться тысячами, а то и миллионами долларов, в зависимости от вида и продолжительности перебоев в ее работе и типа ИС. Доступность ИС – ключевой фактор успеха в бизнесе. Поэтому целью большинства организаций является обеспечение максимальной доступности при минимальном времени простоя ИС – как в случае запланированных остановов (в частности, на время регламентных работ), так и в случае незапланированных простоев (как, например, в случае сбоев ПО или оборудования).

В Таблице 1 приведены примеры приемлемых значений времени простоя, соответствующих различным плановым показателям доступности:

Доступность в %

Время простоя за год

Время простоя за месяц

Время простоя за неделю

99,9999% («шесть девяток»)

31 секунд

2,59 секунд

0,605 секунд

99,999% («пять девяток»)

5,26 минут


25,9 секунд


6,05 секунд

99,99% («четыре девятки»)

52,6 минут

4,32 минут

1,01 минут

99.9% («три девятки»)


8,67 часов


43,2 минут


10,1 минут

99% («две девятки»)

3,65 дней

7,20 часов

1,68 часов

95%


18,25 дней


36 часов


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é также обеспечивает чрезвычайно высокий уровень совместимости с другими технологиями и поддерживает все наиболее распространенные средства разработки, позволяя использовать широкий спектр методологий разработки.



Похожие:

Автор: Вик Нагджи (Vik Nagjee), Product Manager iconПравила лицензирования ipi. Helpdesk™ и ipi. Manager™, включая дополнительные модули Общая информация о системах
Управление процессом общения с заказчиками и партнерами через веб-сайт с информированием автора запроса о ходе его обработки
Автор: Вик Нагджи (Vik Nagjee), Product Manager iconProduct-quality index system. Building. Adhesive polymer materials. Nomenclature of indices
Утвержден и введен в действие постановлением Государственного комитета СССР по делам строительства от 18 мая 1983 г. N101
Автор: Вик Нагджи (Vik Nagjee), Product Manager iconProduct quality ratings system. Bilding. Polymer decorative materials and facing products
Утвержден и введен в действие постановлением Государственного комитета СССР по делам строительства от 15 июня 1983 г. №119
Автор: Вик Нагджи (Vik Nagjee), Product Manager iconProduct-quality index system. Building. Concrete and reinforced concrete products and structures
Утвержден и введен в действие постановлением Государственного комитета СССР по делам строительства от 29 декабря 1978 г. №264
Автор: Вик Нагджи (Vik Nagjee), Product Manager iconThe gost r certification system requirements for product
Федерации (Главтехнормированием Минстроя России В. В. Тишенко, И. Н. Нагорняк), Государственным предприятием Центром методологии,...
Автор: Вик Нагджи (Vik Nagjee), Product Manager iconМетодичні вказівки до курсу «Психологія вищої школи» Автор Подшивалкіна В
Автор Подшивалкіна В. І., доктор соціологічних наук, професор кафедри соціальної і прикладної психології
Автор: Вик Нагджи (Vik Nagjee), Product Manager iconКоводителей
В ходе осуществления работы по вза­имодействию с последними автор обозначил для себя определенные неоднозначные (спорные) мо­менты...
Автор: Вик Нагджи (Vik Nagjee), Product Manager iconПрограмма элективного курса
За основу взяты программы «Модуль» (автор Т. И. Лазарева и «Алгебра плюс: Элементарная алгебра с точки зрения высшей математики»...
Автор: Вик Нагджи (Vik Nagjee), Product Manager iconТема опыта: «Развитие произвольной зрительной памяти у детей старшего дошкольного возраста посредством дидактической игры» Автор опыта
Автор опыта: Вокуева Галина Юрьевна, воспитатель мб оу «Детский сад п. Каратайка»
Автор: Вик Нагджи (Vik Nagjee), Product Manager iconТема опыта: «Умения не приходят сами по себе, их надо развивать» Автор опыта
Автор опыта: Краснолуцкая Надежда Леонидовна, педагог – психолог мб доу «Центр развития ребенка – детский сад п. Искателей»
Разместите ссылку на наш сайт:
Справочники, творчество


База данных защищена авторским правом ©dmee.ru 2000-2014
При копировании материала обязательно указание активной ссылки открытой для индексации.
контакты