AsBase® DataGuard Suite

Демонстрационная версия доступна для загрузки...

Проблема сохранности данных и доступности системы

На сегодняшний день в составе практически любой информационной системы (будь то банковская система, система продажи авиабилетов или интернет-магазин) присутствует база данных (БД). Именно БД является тем «местом», в котором сохраняется и накапливается информация, необходимая для работы системы. К примеру, в случае банковской системы это информация о счетах клиентов, денежных переводах, операциях с карточками. В случае интернет-магазина это данные о товарах, их типах, наличии на складе, ценах, заказах и т.д.

Очевидно, что выход БД из строя может привести к серьезным последствиям, которые в свою очередь, приведут к значительным финансовым потерям. Очевидным является также и желание минимизировать возможность таких аварий.

Решение 1 – резервное копирование БД

Одним из возможных вариантов решения указанной задачи может быть создание и периодическое обновление резервных копий БД – специального набора файлов, содержащего всю информацию из БД по состоянию на определенный момент времени. Резервные копии можно хранить на отдельном диске и даже на отдельном сервере, существенно удаленном от основной БД. В случае выхода БД из строя вся информация может быть восстановлена из резервной копии и система может продолжить работу.

Однако данный подход содержит два существенных недостатка.

Недостаток 1 – невозможность восстановить абсолютно все данные.

Поскольку резервные копии создаются через определенные периоды времени, всегда имеется определенная порция информации, которую нельзя будет восстановить из резервной копии. Более того, во многих случаях именно эта порция является наиболее ценной, поскольку содержит данные о последних выполненных в системе операциях. Рассмотрим пример с интернет-магазином. Пусть резервная копия БД создаётся каждый понедельник. В таком случае, если авария с БД произошла в среду, восстановить можно будет лишь те данные, которые были сохранены при последнем резервном копировании – то есть по состоянию на понедельник. При этом, естественно, будет утеряна информация о заказах, оформленных в период с понедельника по среду. Клиенты, оформившие эти заказы, и не получившие товар вовремя, будут недовольны. А магазин потеряет не только деньги, но и репутацию надежной площадки продаж.

Даже если выполнять резервное копирование ежедневно, всё равно всегда будет оставаться порция данных, восстановление которой в случае аварии будет невозможным.

Недостаток 2 – восстановление БД занимает время.

Операция по восстановлению БД из резервной копии может требовать значительных временных затрат - в зависимости от масштаба аварии и объема восстанавливаемых данных может потребоваться от одного часа до суток и более. Во время операции восстановления система не может обслуживать пользователей. Вернемся к примеру с интернет-магазином. В добавок к потерянным заказам магазин в течение нескольких часов будет недоступен для покупателей, что также приведет к финансовым и репутационным потерям.

Решение 2 – синхронная репликация данных

В поисках подхода, позволяющего гарантированно восстановить все данные и обеспечивающего минимальный простой системы, инженеры пришли к следующему решению.

100%-я сохранность данных

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

Минимальный простой БД

Что же делать, когда авария на основной БД всё же возникла? Наиболее очевидный и прямолинейный путь – предоставить администратору БД возможность «подменить» вышедшую из строя основную БД одной из копий, развернутых на резервных серверах. Говоря техническим языком, предоставить администратору возможность переключения ролей узлов репликации - узел (сервер), выполнявший ранее роль резервного, по команде администратора станет основным и продолжит обслуживать запросы клиентов с того самого «места», на котором «закончил» предыдущий (вышедший из строя) узел. Такое переключение занимает не более 2-3-х минут, но с одним существенным условием – если администратор находился на рабочем месте, вовремя получил от системы уведомление об аварии и выполнил команду на переключение.

Но что делать, когда администратора по каким-то причинам нет на месте, а каждая минута простоя системы стоит немалых денег? На помощь приходит функция автоматического переключения ролей. Если данная функция активирована, система сама определит аварийную ситуацию и «подменит» базу данных. Пользователи могут даже не заметить кратковременного отключения БД.

AsBase DataGuard Suite – сохранность и доступность данных за разумные деньги

Имея значительный опыт разработки «больших» информационных систем, разработчики AsBase DataGuard Suite прекрасно понимали важность описанных проблем и необходимость их решения. В то же время очевидным было и другое обстоятельство – существующие решения мировых производителей систем управления базами данных (СУБД), таких как Oracle, обладают существенным недостатком – чрезвычайно высокой стоимостью.

Так, продукт Oracle DataGuard Broker, предоставляющий функции синхронной репликации данных и автоматического переключения ролей узлов репликации, доступен только в составе СУБД Oracle Enterprise Edition, стоимость которой исчисляется десятками тысяч долларов США.

Далеко не все заказчики могут позволить себе такие вложения в программное обеспечение. В то же время отказоустойчивость БД и сохранность данных приобретают всё большее значение, и всё больше организаций нуждается в таких решениях. При этом многие компании используют более дешевые или вовсе бесплатные решения от Oracle – соответственно СУБД Oracle Standard Edition и Oracle Express Edition.

Проанализировав вышеизложенные обстоятельства, группа компаний Corside приняла решение о разработке собственного продукта – AsBase DataGuard Suite.

Продукт AsBase DataGuard Suite является практически полноценной заменой Oracle DataGuard Broker и обеспечивает:

Применение AsBase DataGuard Suite в связке с СУБД Oracle обеспечивает практически 100%-ю сохранность информации и круглосуточную доступность БД для клиентского программного обеспечения.

В состав AsBase DataGuard Suite включены удобные и интуитивно понятные средства инсталляции и конфигурирования сети репликации, а также утилита командной строки, во многом аналогичная соответствующей утилите от Oracle. Последнее обстоятельство делает AsBase DataGuard Suite удобным в использовании администраторами БД, знакомыми с продуктом от Oracle.

Кроме перечисленных достоинств, AsBase DataGuard Suite обладает еще одним – на порядок меньшей стоимостью (в сравнении с решениями Oracle).