Меню Рубрики

Установка tivoli storage manager

Настройка и использование >

Серия контента:

Этот контент является частью # из серии # статей: Informix OnBar и Tivoli Storage Manager, Часть 1

Этот контент является частью серии: Informix OnBar и Tivoli Storage Manager, Часть 1

Следите за выходом новых статей этой серии.

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

Это первая часть серии из двух статей, в которой рассматривается резервное копирование в IBM Informix Dynamic Server (IDS) с использованием IBM Tivoli Storage Manager (TSM). В статье рассказывается о том, как реализовать систему резервного копирования с использованием этих продуктов IBM, а также приводятся ценные рекомендации по этому теме.

TSM-термины

При работе с TSM вы познакомитесь с некоторыми общими терминами. Эти термины необходимы для понимания взаимоотношений с IDS.

Объекты archive и backup

TSM имеет два различных типа объектов хранения, называемых archive-объектами (архив) и backup-объектами (резервная копия). Основное отличие между ними заключается в том, что backup-объекты могут находиться в активном и неактивном состоянии, тогда как archive-объекты не имеют этой характеристики.

Активные backup-объекты никогда не превысят срок действия; только неактивные backup-объекты могут превышать срок действия в зависимости от атрибутов, установленных в их группе резервных копий.

Группы архивных и резервных копий

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

TSM Server (TSM-сервер)
Policy Domain (Домен политики)
Policy Set (Набор политики)
Management Class (Класс управления)
Backup Copy Group (Группа резервных копий) Archive Copy Group (Группа архивных копий)
VEREXISTS

Максимальное количество резервных версий для сохранения файлов, еще существующих на клиентском месте. Однако, если указанное в RETEXTRA время хранения истечет, значение VEREXISTS игнорируется.

Количество дней хранения архивной копии.

Максимальное количество резервных версий для сохранения файлов, которые были удалены на клиентском месте.

Определяет, когда начинается отсчет времени хранения, указанное либо в RETVER, либо в CREATION, либо в EVENT.

Количество дней хранения резервной версии после того, как эта версия стала неактивной.

Минимальное количество дней хранения архивной копии.

Количество дней хранения последней резервной версии объекта, который был удален из системы клиента.

Домен политик является сущностью логического группирования. TSM предлагает домен политик по умолчанию под названием standard. Администратор TSM может определить дополнительные домены.

Внутри домена политик находятся наборы политик (policy set). Набор политик является логическим группированием одного или более классов управления. Только один набор политик может быть установлен активным в данный момент времени.

Каждый набор политик содержит класс управления по умолчанию и один или более дополнительных классов управления. Классы управления состоят из групп архивных и резервных копий. Эти группы копий содержат ключевые атрибуты, управляющие сроком действия объектов данного типа (объекты archive или backup). Детальная информация о настроенных классах управления может быть извлечена при помощи команды ‘dsmc query mgmtclass -detail’ (см. раздел Запрос TSM).

Во время регистрации клиентского узла TSM он связывается с одним доменом политик (по умолчанию – с доменом standard) и, таким образом, использует активный набор политик этого домена.

Программы резервного копирования IDS

Informix поставляется с двумя независимыми программами резервного копирования:

В прошлом была и третья программа под названием onarchive. Однако она больше не поставляется с IDS V9.4 и более поздними версиями IDS.

Программа Ontape

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

Для того чтобы сохранить резервные копии, сделанные программой ontape, вы можете выполнить резервное копирование на диск, а потом использовать программу TSM dsmc для передачи копии в TSM. Есть пользователи Informix, которые делают резервное копирование подобным образом; однако здесь мы не будем рассматривать эту возможность.

Программа Onbar

Еще одна программа резервного копирования в Informix называется onbar (Online Backup Archive). Onbar использует интерфейс (X/Open Backup Services API) для взаимодействия с менеджерами хранилищ сторонних производителей. При помощи onbar вы можете распараллелить ваши процедуры резервного копирования и выполнить восстановление до заданной контрольной точки. Менеджер хранилища Informix (ISM) связан с IBM IDS, что позволяет пользователям использовать onbar без отдельного менеджера хранилища сторонних производителей.

Внешнее резервное копирование и восстановление

IDS также может работать совместно с технологиями зеркалирования, предоставляемыми современными дисковыми подсистемами. Этот метод называется EBR (External Backup Restore). Для резервирований такого типа IDS позволяет блокировать сервер базы данных при помощи команды ‘onmode -c block’, чтобы сохранить непротиворечивое состояние. Во время восстановления IDS способен комбинировать физическое восстановление с логическим. EBR-метод в данной статье не рассматривается.

Для передачи резервных копий из onbar в TSM необходим продукт IBM Tivoli, называемый Data Protection for Informix (если вы работаете с IDS V7.x или V9.x). Data Protection for Informix в настоящее время поставляется вместе с IDS V10. Мы рассмотрим этот интерфейс в следующих разделах.

Объекты сервера базы данных

Приведенные ниже примеры используют сервер базы данных Informix с именем ids10 с номером сервера 67.

IDS имеет два типа объектов сервера базы данных, которые могут быть сохранены при помощи onbar:

  • Dbspaces
  • Логические журналы (Logical logs)

Как уже упоминалось, оба типа могут быть сохранены как объекты backup TSM (см. раздел Объекты archive и backup), и нет возможности изменить это поведение. IDS всегда генерирует объекты backup.

Резервный репозиторий

IDS сохраняет информацию о каждой операции резервного копирования (dbspaces и логические журналы) в базе данных с именем sysutils. Эта база данных автоматически создается во время первой инициализации сервера базы данных и содержит несколько таблиц, заполненных информацией о выполненных процедурах резервирования. Информация из базы данных sysutils может быть получена при помощи SQL-команд.

Кроме базы данных sysutils IDS сохраняет также информацию в обычном файле, называемом аварийным загрузочным файлом (emergency boot file). Этот файл расположен в следующем каталоге:

Аварийный загрузочный файл необходим для холодного восстановления. Холодное восстановление – это такое восстановление, когда сервер базы данных не доступен и, следовательно, нельзя получить доступ к базе данных sysutils. Onbar извлекает нужную информацию из этого файла. Во время горячего восстановления сервер базы данных находится в рабочем состоянии, и onbar будет запрашивать информацию о резервной копии из базы данных sysutils.

Типы резервного копирования

IDS предоставляет возможность резервного копирования dbspaces и логических журналов с использованием программы onbar. Резервное копирование логических журналов настраивается при помощи механизма Informix ALARMPROGRAM.

Informix различает два типа резервирования dbspace:

  • Полное резервирование
  • Параллельное резервирование

Оба типа резервирования могут быть выполнены во время работы сервера базы данных, выполняющего транзакции.

Полное резервирование

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

Параллельное резервирование

Параллельное резервирование позволяет работать с несколькими dbspaces (параметр $ONCONFIG BAR_MAX_BACKUP) одновременно, уменьшая, таким образом, общее время резервирования при соответствующей инфраструктуре. Однако, в случае восстановления, параллельная резервная копия будет полагаться на логические журналы для достижения непротиворечивости.

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

Проверьте, что параметр $ONCONFIG LTAPEDEV установлен не в /dev/null, а настроенная ALARMPROGRAM способна выполнять резервирование журналов с использованием onbar. Если LTAPEDEV установлен в /dev/null, логический журнал будет отмечен как зарезервированный сразу после изменения состояния журнала. Логический журнал не будет сохранен (cм. раздел Настройка IDS/Onbar).

Уровень резервирования

Для обоих типов резервного копирования (полного и параллельного) вы можете указать уровень резервирования и вид резервирования – полное или инкрементное:

  1. Level-0-Backup
    • Выполняется резервное копирование всех используемых страниц
  2. Level-1-Backup
    • Выполняется резервное копирование только тех страниц, которые изменились со времени последнего полного резервирования Level-0-Backup
  3. Level-2-Backup
    • Выполняется резервное копирование только тех страниц, которые изменились со времени последнего резервирования Level-1-Backup. Если последнее резервное копирование выполнялось на уровне Level-0-Backup, Level-2-Backup будет таким же, как и Level-1-Backup

Операции инкрементного резервирования имеют смысл, поскольку они уменьшают время, необходимое на восстановление сервера базы данных. Применение Level-0-Backup и последующих инкрементных операций резервирования будет значительно более быстрым, чем просмотр всего большого объема логических журналов.

Типы восстановления

IDS различает следующие типы восстановления:

Холодное восстановление

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

Горячее восстановление

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

Смешанное восстановление

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

Восстановление Point-In-Time/Point-In-Log

Эти типы восстановления полагаются на информацию в логических журналах. Сервер базы данных может быть восстановлен либо до конкретной точки во времени (Point-In-Time), либо до конкретного логического журнала (Point-In-Log). Важно отметить, что в обоих случаях восстанавливается весь сервер базы данных. Индивидуальные dbspaces не могут быть восстановлены таким образом.

Настройка TDP/OnBar

Настройка TDP

Отдельная программа TDP for Informix необходима только для версий IDS до 10. Полный процесс установки и настройки TDP for Informix описан в руководствах IBM по программе (см. раздел Ресурсы). Возможно, понадобится помощь вашего системного администратора TSM для предоставления необходимых значений настроек.

Обратите внимание на то, что 32-битный экземпляры IDS должны использовать 32-битные компоненты TDP/Informix, а 64-битные версии IDS должны использовать 64-битные компоненты TDP/Informix.

32-битные версии IDS имеют идентификатор U в номере версии; например:

64-битные версии IDS имеют идентификатор F в номере версии, например:

32- и 64-битные версии TDP/Informix обычно устанавливаются в одном и том же базовом каталоге; однако 64-битная версия добавляет идентификатор 64 в конец имени пути, например:

  • 32-битная версия: /usr/tivoli/tsm/client/informix/bin
  • 64-битная версия: /usr/tivoli/tsm/client/informix/bin64

Приведем краткий обзор конкретных шагов, которые должны быть выполнены пользователем root. Шаг 2 не требуется, если вы используете IDS V10. TDP/Informix, известный также как TXBSA, уже включен в IDS 10.

  1. Установка TSM/API
    • TSM/API – это основа. TDP/Informix использует TSM/API для обмена данными с Tivoli Storage Manager. Пакет TSM/API доступен на CD ROM с программным обеспечением TDP/Informix. Установка производится стандартными для операционной системы процедурами (см. ниже).
  2. Установка TDP/Informix
    • Программное обеспечение устанавливается стандартными для операционной системы процедурами, такими как smitty (installp) на IBM AIX® или pkgadd на Sun Solaris. Каталог установки по умолчанию зависит от вашей платформы:
      • AIX (TSM API): /usr/tivoli/tsm/client/api/bin[64]
      • AIX (TDP/IFX): /usr/tivoli/tsm/client/informix/bin[64]
      • Solaris (TSM API): /opt/tivoli/tsm/client/api/bin[64]
      • Solaris (TDP/IFX): /opt/tivoli/tsm/client/informix/bin[64]

В IDS V10, библиотека TXBSA доступна в каталоге $INFOMIXDIR/lib.

  • Определение переменных окружения
    • DSMI_CONFIG
      • Полный путь к пользовательскому файлу настроек (dsm.opt)
    • DSMI_DIR
      • Полный путь к инсталляции TSM API (необходим тогда, когда установлен не в каталог по умолчанию)
    • DSMI_INF_DIR
      • Полный путь к инсталляции TDP/Informix (необходим тогда, когда установлен не в каталог по умолчанию)
    • DSMI_LOG
      • Полный путь к каталогу, в котором должен создаваться файл регистрации ошибок TSM API (dsierror.log)
  • Модифицируйте системный файл настроек клиента (dsm.sys)
    • Укажите логическое имя (секция сервера) для этой группы элементов. В файле dsm.sys может быть несколько серверных секций. Серверная секция, которая будет использоваться, определяется в следующем порядке убывания приоритета:
      1. SERVERNAME, установленный в вашем пользовательском файле настроек клиента (dsm.opt)
      2. Элемент DEFAULTSERVER в системном файле настроек (dsm.sys)
      3. Первая серверная секция в пользовательском системном файле настроек (dsm.sys)
    • Установите PASSWORDACCESS в GENERATE. Это гарантирует, что TSM не будет запрашивать пароль, поскольку onbar не может с ним работать. Зашифрованный пароль сохраняется локально (файл TSM.PWD). Если срок действия старого пароля заканчивается, автоматически генерируется и сохраняется локально новый пароль.
    • Укажите NODENAME, с которым клиент должен соединяться с TSM-сервером. Если NODENAME не указан, будет использоваться имя хоста системы.
    • Установите в параметре INCLEXL полный путь к файлу inclexcl.def.
    • Существуют несколько параметров, которые нужно установить для того, чтобы идентифицировать TSM-сервер, например, COMMETHOD, TCPSERVERADDRESS и TCPPORT. Их должен знать ваш TSM-администратор.
  • Модифицируйте пользовательские файлы настроек клиента (dsm.opt)
    • Установите SERVERNAME таким образом, чтобы он указывал на соответствующую серверную секцию системного файла настроек клиента (dsm.sys).
  • Добавьте записи в файл inclexcl.def
    • Добавьте записи для присвоения соответствующих классов управления вашим объектам IDS backup (см. раздел Присвоение класса управления). Месторасположение файла inclexcl.def настраивается в параметре INCLEXCL файла dsm.sys.
  • Зарегистрируйте узел TSM-клиента на TSM-сервере
    • Ваш TSM-администратор должен зарегистрировать ваш узел TSM-клиента на TSM-сервере под желаемым NODENAME. Если он спросит, – вам не нужны полномочия BACKDEL (удаление backup-объектов), поскольку onsmsync (программа синхронизации менеджера хранилища, поставляемая с IDS) выполняет только XBSA-вызов BSAMarkObjectInactive() для логических журналов. Это можно сделать без полномочий BACKDEL, потому что объекты только деактивируются, а не удаляются.
  • Инициализируйте TSM-пароль
    • Запустите программу tdpipswd, которая поставляется с TDP/Informix. В IDS V10, в которую уже включен TXBSA, эта программа называется:
      • $INFORMIXDIR/bin/txbsapswd
  • Настройка IDS/OnBar

    Настройка IDS для TDP/Informix довольно проста. В вашем файле $INFORMIXDIR/etc/$ONCONFIG должны быть установлены следующие параметры:

    • BAR_BSALIB_PATH
      • Установите этот параметр в полное имя пути к библиотеке XBSA, поставляемой в TDP/Informix при использовании IDS до 10-й версии:
        • AIX: /usr/tivoli/tsm/client/informix/bin[64]/bsashr10.o
        • Solaris: /opt/tivoli/tsm/client/informix/bin[64]/libTDPinf.so

        В зависимости от версии TDP/Informix, используемой на AIX, объектный файл bsashr10.o может быть напрямую недоступен. В этом случае вы должны извлечь этот файл из библиотеки libTDPinf при помощи команды ar:

        • cd /usr/tivoli/tsm/client/informix/bin[64]
        • ar x libTDPinf.a

        IDS будет также пытаться открыть библиотеку XBSA в пути по умолчанию, если BAR_BSALIB_PATH не установлен. Однако этот путь по умолчанию зависит от используемой версии IDS, поэтому определение BAR_BSALIB_PATH является неоднозначным. Если используется IDS V10, установите BAR_BSALIB_PATH в:

        • AIX: $INFORMIXDIR/lib/libtxbsa.a
        • Solaris: $INFORMIXDIR/lib/libtxbsa.so
    • BAR_ACT_LOG
      • Полный путь к журналу работы onbar. Это исходный logfile для любых сообщений, относящихся к onbar. Существуют дополнительные параметры для включения отладки, которая будет рассмотрена во второй статье данной серии.
    • Создайте файл sm_versions
      • cd $INFORMIXDIR/etc
      • cp -p sm_versions.std sm_versions

      Измените одну конфигурационную строку в файле sm_versions:

      • 1| |tsm|
    • LTAPEDEV и ALARMPROGRAM
      • Резервное копирование ваших логических журналов всегда является хорошей идеей и особенно, когда вы планируете выполнять параллельное резервирование или хотите иметь возможность выполнять восстановление до определенной контрольной точки во времени (см. раздел Типы резервного копирования). Установите LTAPEDEV в что-нибудь отличное от /dev/null и установите ALARMPROGRAM в $INFORMIXDIR/etc/log_full.sh.
    • RESTARTABLE_RESTORE
      • Вы должны установить этот $ONCONFIG-параметр в ON. Это может сохранить ваше ценное время, поскольку вы будете иметь возможность продолжить прерванное или неудачное восстановление, не начиная его с самого начала.

    После этих изменений перезапустите IDS (onmode -ky && oninit). Теперь вы должны иметь возможность выполнить резервное копирование вашего экземпляра IDS в TSM при помощи onbar.

    Проследить за текущей операцией резервного копирования можно при помощи выполнения команды tail -f с вашим журналом работы программы onbar. Кроме того, вы можете выполнить команду onstat -g arc для отображения индикатора выполнения вашего резервного копирования.

    Присваивание класса управления

    Как уже упоминалось, программа onbar всегда генерирует backup-объекты TSM. Эти объекты связаны с конкретным классом управления и сохраняются в соответствии с атрибутами соответствующей группы резервных копий (см. раздел Группы архивных и резервных копий).

    В IDS не существует конфигурационного параметра для указания явного класса управления для резервного копирования. $ONCONFIG-параметры ISM_DATA_POOL и ISM_LOG_POOL используются только менеджером хранилища ISM, интегрированного в IDS.

    Связывание backup-объектов и конкретных классов управления производится внешним образом (TSM API) путем сравнения имен backup-объектов с шаблонами, установленными в файле inclexcl.def. Расположение файла inclexl.def определено в параметре INCLEXCL вашего клиентского системного файла настроек (dsm.sys). Расположением по умолчанию является:

    • AIX: /usr/tivoli/ tsm/client/api/bin[64]/inclexcl.def
    • Solaris: /opt/tivoli/tsm/client/api/bin[64]/inclexcl.def

    Имена backup-объектов

    Все backup-объекты, хранящиеся в TSM, имеют связанное с ними имя. Клиент (onbar) управляет следующими ключевыми компонентами этого имени:

    • FileSpaceName
      • Для dbspaces и логических журналов здесь используется имя вашего экземпляра IDS (DBSERVERNAME) (см. раздел Запрос TSM). Это имя важно для TSM, так как оно группирует зависимые данные вместе. Некоторые TSM-операции работают на filespace-уровне.
    • HighLevelName
      • Для dbspaces используется комбинация имени экземпляра IDS плюс имя индивидуального dbspace. Для резервных копий логических журналов используется комбинация имени экземпляра IDS плюс номер сервера IDS (см. раздел Запрос TSM).
    • LowLevelName
      • Для dbspaces используется уровень архивирования (например, level-0, level-1 или level-2). Для резервных копий логических журналов используется идентификатор журнала (log ID) (см. раздел Запрос TSM).

    Записи inclexcl.def

    Ниже приведены две записи inclexcl.def для нашего экземпляра IDS с именем ids10, номера сервера 67 с различными классами управления для dbspaces и логических журналов:

    1. include /ids10/. /* IFX_LOG
    2. include /ids10/. /1 IFX_DB

    Сопоставление с шаблоном выполняется снизу вверх по содержимому файла inclexcl.def. Хотя первая запись соответствует всем объектам (dbspaces и логическим журналам), резервное копирование dbspace будет корректно присвоено классу управления IFX_DB, поскольку сопоставление происходит снизу вверх и останавливается, как только соответствие не будет найдено. Для dbspaces сопоставление останавливается на 2-й записи. Имена backup-объектов логических журналов не будут соответствовать этой записи. Они соответствуют 1-й записи, которая присвоит им класс IFX_LOG.

    Однако вы можете изменить 1-ю запись в вашем inclexcl.def для разъяснения этого различия:

    • include /ids10/. /67/* IFX_LOG

    Backup-объекты, для которых не найдены подходящие записи, связываются с классом управления по умолчанию в активном наборе политик (см. раздел Группы архивных и резервных копий).

    Можно также в первую строку файла inclexcl.def поместить запись exclude для предотвращения неявного связывания с классом управления по умолчанию для несовпадающих объектов. Например:

    Если в файле inclexcl.def не найдена совпадающая запись, клиенту возвращается ошибка, поскольку необходимо, чтобы каждый backup-объект был связан с классом управления. Если этого сделать нельзя, TSM будет возвращать код ошибки XBSA 96 (0x60).

    Запрос TSM

    Для управления корректным присвоением классов управления backup-объектам может быть использована TSM-программа командной строки dsmc. Вот несколько примеров извлечения имен backup-объектов для нашего экземпляра IDS, называемого ids10 с номером сервера 67:

    Команда dsmc Описание
    query backup ‘ids10/*’ Показывает имена всех активных backup-объектов (dbspace и логических журналов)
    query backup -inactive ‘ids10/*’ Показывает имена всех активных и неактивных backup-объектов (dbspace и логических журналов)
    query backup ‘ids10/ids10/67/*’ Показывает имена только тех активных backup-объектов, которые ссылаются на логические журналы
    query backup ‘ >

    Показывает имена всех активных backup-объектов для резервных копий, выполненных под указанным именем узла ifx_node
    query mgmtclass -detail Показывает подробную информацию о классах управления в активном наборе политик
    Пример отображаемой командой dsmc информации

    Рядом с назначенным классом управления вы видите также состояние (активное или неактивное) конкретных backup-объектов в столбце A/I.

    Это была первая часть статьи. В готовящейся второй части я расскажу об общих подводных камнях IDS/TSM, методах трассировки и других интересных особенностях onbar.

    источник

    Читайте также:  Установка биметаллических радиаторов требования