D3 Reference Manual

Index | Help

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

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

tape socket

Восстановление по сети

Описывается система работы с лентой в сети. Данный раздел представляет собой введение в данную функциональность.

Структура документации Документация по работе с лентой в сети делится на три раздела, представленных в Pick Systems Reference Manual: - "tape socket, General" (данный раздел) - общие сведения по системе работы с лентой в сети, возможности и основные понятия. - "network save/restore, General" - описывает, как выполнять сохранение-восстановление системы по сети. - "tape-socket, TCL" - детальное описание команды TCL tape-socket.
Обзор

Цель - создать программный канал (pipe) для перекачки пакетов данных между двумя системами: ленточный процесс на стороне отправителя (например, T-DUMP) пишет ленточные блоки в канал, а соответствующий процесс на стороне получателя (например, T-LOAD) читает и обрабатывает блоки, как показано на следующей иллюстрации:

    ПОЛУЧАТЕЛЬ                 ОТПРАВИТЕЛЬ
+---------------+          +---------------+ - - - -
| +---+         |          |         +---+ |
| | T |         |          |         | T | |   D3
| +---+         |          |         +---+ |   VM
|   |           |          |           |   |
+---|-----------+          +-----------|---+ - - - -
|   |           |          |           |   |
|   +-<-========|<-[netw]<-|========-<-+   |  Unix
|      pipe     |          |      pipe     |
+---------------+          +---------------+ - - - - 

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

    ПОЛУЧАТЕЛЬ                    ОТПРАВИТЕЛЬ
+---------------+          +---------------+ - - - -
| +---+   +---+ |          | +---+   +---+ |
| | T |   | P |-|<-[netw]<-|-| P |   | T | |  D3
| +---+   +---+ |          | +---+   +---+ |   VM
|   |       |   |          |   |       |   |
+---|-------|---+          +---|-------|---+ - - - -
|   |       |   |          |   |       |   |
|   +-<-=-<-+   |          |   +-<-=-<-+   |  Unix
|      pipe     |          |      pipe     |
+---------------+          +---------------+ - - - - 

Принцип состоит в том, чтобы и в системе отправителя, и в системе получателя выполнялись фантомные процессы, которые устанавливают сетевую связь и обмениваются данными с процессорами лент через программный канал Unix. На стороне получателя T - это процесс, считывающий ленту (например, T-LOAD), а P - фантомный процесс, принимающий данные из сети. На стороне отправителя T - это процесс, осуществляющий запись на ленту (T-DUMP), а P - фантомный процесс, отправляющий данные в сеть.

На каждой машине создается канал Unix, через который фантомный процесс и ленточный процесс обмениваются данными. Этот канал должен быть создан в конфигурационном файле D3 на каждой машине как "сетевое" устройство (type "c").

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

Доступ в сеть осуществляется через библиотеку сокетов BSD.

Серверы : Фантомы на каждой стороне работают как серверы для другой стороны. Далее фантомный процесс на стороне получателя будет называться "сервером ввода" (input server), а на стороне отправителя - сервером вывода (output server). В каждой системе сервер идентифицируется по имени. Рабочие параметры, а также должны ли серверы автоматически подключаться к регистратору транзакций, задает системный администратор при инсталляции. В большинстве конфигураций достаточно одного сервера на систему. Поэтому, удобно оставить имя сервера по умолчанию "default", которое используется во всех меню.

Возможности :

  • автоматический запуск серверов
  • автоматическое восстановление соединения при сбоях в сети
  • - синхронизация часов при запуске серверов. Отправляющая сторона выполняет команды set-date и set-time
  • на удаленной системе со своими значениями. Это действие может быть отменено опцией "s" команды TCL tape-socket.
  • отслеживание сетевого трафика (опционально)
  • автоматическое подключение к регистратору транзакций для автоматического старта обеих систем (опционально)
  • интерфейс к регистратору транзакций для регулярной проверки его работы (опционально)
  • уведомление заданных пользователей D3 о различных инцидентах в сети и в регистраторе транзакций.
  • сервер вывода может удаленно выполнять команды на сервере ввода. Таким образом, предоставляются некоторые возможности удаленного администрирования сервера ввода.
  • автоматическая инсталляция программ при первом запросе.
  • простой интерфейс в виде меню для администрирования сервера по умолчанию и TCL-интерфейс для использования в макросах.
  • короткий, перезаписываемый лог-файл для наиболее частых сообщений об ошибках и отдельный постоянный лог-файл для длительного мониторинга.
Автоматический запуск

Как только сервер сконфигурирован (см. раздел "Настройка сервера" ниже), он запускается простой TCL-командой. Эта команда может быть прописана в стартовом макросе user-coldstart. Если сервер подключен к регистратору транзакций (см. ниже), или если это сервер вывода, регистратор транзакций также запускается, или перезапускается автоматически как фантомный процесс. Если сервер ввода подключен к регистратору транзакций, восстановление транзакций стартуется автоматически командой start; в этом случае эта команда должна быть указана последней в макросе "user-coldstart".

Автоматическое соединение серверов

По умолчанию, сервера пытаются установить соединение автоматически. При возникновении проблем с сетью, сервер вывода пытается восстановить соединение каждые 5 сек. Если соединение не восстанавливается в течение 5 сек, системному администратору отправляется уведомление. Когда соединение восстанавливается, - посылается еще одно сообщение. Вообще, нет необходимости останавливать сервер ввода. Сервер вывода может быть перезапущен.

Подключение к подсистеме регистрации транзакций

Эта функция позволяет через серверы ленточных сокетов полностью контролировать регистрацию транзакций (отправитель) и их восстановление (получатель) в конфигурации с hot-backup. Как только на резервной системе запущен сервер ввода, все операции могут выполняться из основной системы: при запуске сервера вывода стартуется регистратор транзакций; остановка сервера вывода отключает ленту от регистратора транзакций с отправкой сообщения на сервер ввода и восстановление транзакций может быть перезапущено автоматически. Функция тестирования регистратора транзакций позволяет отслеживать различные инциденты, при этом системному администратору отправляется сообщение о том, что тестовая запись получена резервной системой вовремя (см. подробности ниже). Перед запуском и остановкой регистратора транзакций, сервер вывода выполняет несколько проверок на предмет готовности регистратора. Если нет, процесс удаляется, и, если требуется, порождается новый процесс Unix.

Отметим важный момент, после того как серверы подключены к подсистеме регистрации транзакций, необходимо выполнить start/stop для процесса регистрации транзакций и/или для процесса восстановления транзакций исключительно через ленточный сокет-сервер. Можно это сделать через меню. При возникновении сбоев, системному администратору отправляется уведомление, на что он должен ответить некоторыми действиями по исправлению ситуации. Транзакционное меню txlog может быть использовано для просмотра статуса регистратора транзакций, но не может быть использовано для запуска, останова и отсоединения ленты. Если необходимо очистить очередь транзакций, используя txlog меню, остановите первым делом сервер вывода, иначе не только данные могут потеряться, но и механизм восстановления транзакций выйдет из синхронного режима, что потребует его ручного перезапуска.

Тестирование механизма транзакций

Периодически, например каждые 10 минут, запись 'test' записывается в автоматически создаваемый тестовый файл "dm,ts.log,test". Этот файл содержит уникальную информацию и штампы время/дата. Если регистрация и восстановление работают нормально, эта тестовая запись передается в такой же файл в резервной системе, при этом фиксируется время прибытия. Как правило, перед обновлением записи сервер вывода отправляет сообщение серверу ввода для проверки правильности сохранения предыдущей тестовой записи. Если все нормально, сервер вывода может подсчитать приблизительное время передачи транзакции (которое включает не только время передачи, но и время, которое тестовая запись провела в очереди). Если запись не дошла до адресата, системному администратору отправляется соответствующее уведомление. Отметим, что если тестовый период короткий, может получиться, что тестовая запись все еще стоит в очереди, и не была отправлена. При большом размере очереди тестовая запись может находиться там довольно долго.

Команда TCL

Команда TCL "tape-socket" используется для создания серверов ввода-вывода и для контроля их работы. Подробности см. в разделе "tape-socket, TCL".

Настройка системы

Настройка системы может различаться в зависимости от приложения (горячее резервирование, восстановление по сети и пр.). Далее приведены основные шаги этого процесса.

  1. Настроить сетевое соединение между двумя системами. Сеть должна поддерживать протоколы TCP/IP (это может быть Ethernet, Token Ring и т.д.). Системный администратор должен присвоить имена обеим системам, даже если используется только имя принимающего хоста.
  2. Выбрать свободный TCP/IP порт. С помощью команды Unix "netstat -a" можно посмотреть занятые порты. Порты с номерами 2000 или 3000, как правило, свободны.
  3. Создать каналы Unix на обеих системах командой mknod. Убедитесь, что они имеют соответствующие права доступа. Пропишите эти каналы как псевдо-ленты в конфигурационных файлах обеих систем.
  4. Настроить сервера на обеих системах (см. раздел "Настройка сервера" ниже).
  5. Запустить сервер ввода и сервер вывода.
Настройка сервера

Меню "tape-socket" есть пункт "Настройка сервера" (Server Setup), где можно задать необходимые для запуска параметры. Ряд основных настроек должны быть определены администратором. Данный пункт меню запрашивает следующие параметры (если значения определены по умолчанию, они выводятся в скобках, чтобы их выбрать, достаточно нажать <enter>)

Server Name С помощью подменю "другой сервер" (other server) можно управляться с несколькими серверами. Имя сервера - это строка из алфавитных символов и чисел ("." запрещена) длиной до 8 символов. Имя сервера по умолчанию - "tserver".
Server Type Введите "in" для сервера ввода или "out" для сервера вывода. Этот параметр обязателен.
Remote Host Name Введите сетевое имя машины, на которой запускается сервер ввода. Этот параметр требуется при настройке сервера вывода. Имя хоста должно быть объявлено в файле /etc/hosts.
TCP/IP port number Задайте разрешенный (>1024, <32767) свободный номер порта TCP. Используйте команду Unix netstat -a для просмотра уже задействованных портов. Указанный порт должны принять оба сервера, иначе коммуникации невозможны. Этот параметр обязателен.
Protocol В настоящее время поддерживается только inet (Internet Protocol). Этот параметр обязателен.
Unix pipe name Выберите разрешенный канал (например, /dev/tape). Если он не существует, то должен быть создан и добавлен в конфигурационный файл D3. Воспользуйтесь командой TCL config tape, например. Этот параметр обязателен. См. пример в разделе "tape-socket, TCL".
Number of trace messages to keep Лог-сообщения сохраняются в маленьком перезаписываемом буфере, который может быть просмотрен командой status. Выберите число от 4 до 16, например. Все сообщения (кроме периодических OK-сообщений) также сохраняются в постоянном лог-файле.
D3 user to notify in case of errors Введите один или несколько идентификаторов пользователя D3 через запятую. При возникновении ошибки, эти пользователи получат сообщение. Если оставить поле пустым, извещаться будет только dm или sysprog. В случае повторяющихся ошибок эти сообщения мешают работе и позже подавляются. Для большинства случаев настоятельно рекомендуется ввести хотя бы одного постоянно работающего пользователя, чтобы ошибки не остались незамеченными. В целом, система функционирует без вмешательства человека, и, если уведомления отменены или указанных пользователей нет в системе, соединение может быть потеряно на долгий срок, пока ошибка не будет обнаружена и исправлена. Ошибки также регистрируются в лог-файле. Для выбора всех пользователей системы введите звездочку "*". Чтобы сообщения отправлялись на конкретную линию, подключена она или нет, введите восклицательный знак и следующий за ним десятичный номер линии (например, !0). Для отмены отправки уведомлений введите "off".
Transaction Log test polling period Введите период времени в секундах или в формате ЧЧ:ММ:СС, с которым сервер вывода будет опрашивать механизм регистрации транзакций. Если регистратор транзакций не используется, - введите 0 для отмены тестирования. Подробную информацию см. выше в разделе "Тестирование механизма транзакций". Приемлемое значение находится в диапазоне от 00:01:00 (1 мин) до 01:00:00 (1 час). Более короткий период может вызвать ложные сигналы об ошибке при задержках в очереди. Более длительный период может привести к тому, что ошибки не будут замечены вовремя. Есть простое правило - если нормальный период обновления данных мал, период тестирования должен быть тоже мал. В случае больших потоков данных, например, при выполнении touch (см. команду TCL touch) для текущей базы данных, рекомендуется временно увеличивать период опроса (например, до 1 часа), чтобы сервер вывода не "паниковал", что тестовые обновления не выполняются вовремя.
Start Transaction logger Этот параметр определяет, будет ли сервер подключен к подсистеме регистрации транзакций для "горячего" резервирования. Введите 'on' для включения регистрации или 'off' для отключения данной функции. Если включено, сервер пытается установить контроль над регистрацией и восстановлением транзакций. Перед включением этой опции необходимо ознакомиться с механизмом взаимодействия двух подсистем в разделе "Подключение к подсистеме регистрации транзакций", изложенном выше. Важно соблюдать правило: управлять регистратором транзакций исключительно через меню или команды tape-socket, чтобы серверы знали состояние подсистемы регистрации транзакций.
Log (DL) files or ALL Этот параметр задается только для сервера вывода, если он подключен к регистратору транзакций. Он определяет опции, с которыми будет стартован регистратор транзакций при запуске сервера вывода. Введите DL для регистрации транзакций только для файлов с кодом L, добавленным в атрибут 1 d-указателя (см. как это делать в описании команды TCL set-dptr). Введите ALL для регистрации всех обновлений всех файлов. Эту опцию надо использовать с осторожностью, поскольку обновления системных файлов, таких как abs, users и др., также будут регистрироваться.
Transaction Log queue period Этот параметр задается только для сервера вывода, если он подключен к регистратору транзакций. Он задает время в секундах, по истечении которого обновления передаются на удаленную систему. Введите 0 для выбора значения по умолчанию (30 сек). Для быстрых сетей подойдет значение 2 или 3 сек. Это означает, что транзакции будут оставаться в главной системе в течение 2 или 3 сек, перед тем как отправиться на удаленную систему. В случае сбоя, только эти обновления будут утеряны.