D3 Reference Manual

Index | Help

Поиск по страницам

Разделы / Общие сведения / hot backup

hot backup

Горячее резервирование системы

Описывается конфигурация hot backup, где одна машина находится в режиме ожидания, готовая заменить вышедшую из строя систему.

Введение

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

Обзор решения на основе Hot Backup

Конфигурация hot backup включает две системы: одна master-система - это рабочая система, и slave-система, находящаяся в режиме ожидания. Машины соединены быстрым TCP/IP каналом. Пользователи обычно подключены к основной системе. Резервная система также загружена и имеет копию рабочей базы данных. Машины не обязательно должны быть абсолютно идентичны: резервная машина просто должна иметь все необходимые ресурсы (диск, память, коммуникации, Е) для запуска приложений.

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

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

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

Преимущества
  • Если абсолютная отказоустойчивость не требуется, стоимость данного решения ниже стандартной отказоустойчивой системы. Резервная машина быть менее мощной, чем основная. Более слабая машина может использоваться в качестве резервной, если она обеспечивает приемлемый уровень сервиса, при выходе из строя главной машины.
  • Резервная система не обязательно бездействует. Пока база данных на резервной машине не обновляется, она может использоваться для создания отчетов, резервных копий, снижая нагрузку на основную систему, для разработки и т.д.
  • Машины могут иметь различные аппаратные ресурсы. Компьютеры могут быть установлены в разных помещениях, что повышает защиту от форс-мажора.
  • Поскольку обновления происходят на логическом уровне, в противоположность зеркалированию данных на дисках, выполняются системным процессом, в отличие от основной системы, где это делает приложение, вероятность повреждения резервной системы в результате сбоя операционной системы уменьшается.
  • Slave-система может резервировать более одной master-системы. Slave-система с большим объемом диска может работать как горячий (on-line) архив нескольких приложений.
Недостатки

Администрирование и процедуры восстановления требуют некоторых ручных операций. Настроить систему в среде Unix достаточно сложно, системный администратор должен понимать, что делает.

Восстановление основной системы после сбоя

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

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

Если предположить, что база данных на основной машине полностью потеряна, вследствие поломки дисков, ресинхронизация машин производится посредством простого копирования резервной машины и восстановления копии на основной машине с последующим переключением пользователей обратно на основную машину. Проблема в том, что операции сохранения-восстановления могут занять очень много времени, например, несколько дней. Очевидно, остановка работы на такой период времени неприемлема. Следовательно, пока производится сохранение-восстановление, изменения базы данных должны запоминаться. Изменения могут сбрасываться на ленту, поскольку система поддерживает многотомность архива. Как только восстановление данных на основной машине завершиться, накопленные транзакции применяются к базе данных. Во время загрузки журнала транзакций вероятнее всего будут сделаны новые обновления резервной машины и, соответственно, созданы новые ленты транзакций. В зависимости от объема данных может понадобиться несколько повторений процесса: загрузка лент с журналами транзакций на основной системе, в то время как на резервной машине создаются новые ленты транзакций. В конце концов, обе машины будут почти синхронизированы. Затем пользователи отсоединяются от резервной машины, последние изменения записываются на ленту, которая загружается на основную систему. Во время выполнения этого небольшого этапа все операции должны быть остановлены. Теперь обе системы синхронизированы. Пользователи теперь могут подключиться к основной системе, а резервирование транзакций через сеть с основной машины на резервную запущено снова, система снова полностью работоспособна.

Если на резервной машине достаточно дискового пространства, а время простоя основной системы (включая сохранение/восстановление системы) ожидается небольшим, можно оставить все обновления на диске. Синхронизация обеих машин упрощается: после восстановления запустите процесс резервирования через сеть с РЕЗЕРВНОЙ машины, которая в данный момент работает как главная (master), НА ОСНОВНУЮ, функционирующую как подчиненная (slave). Все обновления резервной машины будут перенесены на основную. Когда очередь очистится, пользователи могут переключиться на на основную машину. Это исключает операции с лентами, но предполагает больший риск в случае возникновения серьезных проблем на резервной машине.

Восстановление резервной машины после сбоя

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

Проверка работоспособности

Система применяется обычно для больших баз данных, и проверка ее работоспособности, отсутствие потерь данных, - очень важный момент. Очевидно, что первостепенное значение имеет надежность сетевого соединения. Участвующие в работе системы процессы постоянно выполняют взаимные проверки, присваивая сетевым сообщениям номера. Кроме того, контролируют функционирование механизма регистрации транзакций, время от времени записывая тестовые данные и проверяя распространение обновлений. Системный администратор может выполнять проверку целостности данных периодическим выводом отчетов в приложениях, сравнивая результаты. Обо всех проблемах в сети извещаются заранее указанные пользователи, поэтому неполадки не останутся незамеченными на долгий срок. В разделе "hot-backup, TCL" описаны основные проблемы и способы их решения.

Установка системы

Для установки hot backup системный администратор должен выполнить следующие шаги. Каждая операция подробно разобрана в разделе "hot-backup, TCL".

  • Установить сетевое соединение между системами. Сеть должна поддерживать протоколы TCP/IP (это может быть Ethernet, Token Ring и др.). Системный администратор должен присвоить сетевые имена обеим системам, даже если используется только имя принимающей машины. Для установления соединения hot backup необходим доступ только к TCP. Другие протоколы, NFS, FTP и т.д., не требуются.
  • Найти свободный TCP/IP порт. Используйте команду Unix "netstat -a" для просмотра занятых портов. Порты с номерами 2000 или 3000 обычно свободны.
  • Установить СУБД на основной машине, включая приложения, пользовательские файлы и т.д.
  • На основной машине определить, какие файлы должны резервироваться и пометить их кодом DL. Не рекомендуется резервировать все файлы. В этом случае зеркалируются также системные файлы. Целесообразно исключить счет dm из процесса. Используйте TCL команду "set-dptr" для изменения атрибутов файлов и счетов.
  • Сделать копию основной машины и восстановить ее на резервной. Это можно сделать по сети, что детально изложено в разделе "network save/restore, General". Сохранение-восстановление может также выполняться через магнитную ленту.
  • Настроить сервера на обеих системах (см. раздел "hot-backup, TCL").
  • Запустить master и slave сервера.