Система Хранения Оригиналов Документов

Система хранения оригиналов документов
(“СХОД”)
Архитектурное описание
Автор: Власов Григорий
Дата создания: 2014/11/26
Время последнего редактирования: 2014/12/20 18:12:02 +03’00’
Версия: 1.6
Статус: Черновик

“СХОД” Черновик
Аннотация
В данном документе рассматривается реализация системы хранения оригиналов
документов (далее “СХОД”) с использованием встроенных возможностей System z и
z/OS. Для реализации системы используются следующие возможности:
• наборы данных z/OS, что подразумевает использование VTOC, VVDS, ICF;
• семейство подсистем DFSMS в составе DFSMSdss для управления дисковым про-
странством и наборами данных и DFSMShsm для организации иерархической
системы хранения наборов данных на разных носителях.
Документ предназначен не только для специалистов z/OS, поэтому основные исполь-
зуемые понятия и программные продукты, уникальные для z/OS, описываются в до-
статочной для понимания архитектурной концепции степени в разделе 1, предваряя
архитектурное описание. Специалисты в z/OS могут сразу переходить к разделу 3.
Содержание
1 Базовые возможности z/OS 3
2 Расширенные возможности z/OS 5
3 Архитектурное решение “СХОД” 7
4 Риски 9
5 Вывод 10
1

Введение
В условиях постоянного увеличения количества оригиналов хранимых документов
важное место занимает вопрос организации их хранения. Это важная проблема как для
коммерческих организаций, так и для государственных органов. Для последних, пожалуй,
даже в большей степени, так как регламентируется законом.
Хранение оригиналов документов может быть организовано рядом способов, включая
хранение их в СУБД в виде BLOB1
, как в настоящее время реализовано. Это не является
самым эффективным способом в условиях работы с z/OS.
Целью проекта является повышение эффективности хранения оригиналов документов
и снижения затрат на систему (сопровождение) при повышении качества работы (умень-
шение времени отклика) пользователей. Для достижения этой цели предлагается создать
отдельную систему хранения оригиналов документов (“СХОД”). Основные цели, опреде-
ляемые для новой системы, это:
• организация надёжного долговременного хранения документов;
• недопущение утраты или искажения документов;
• обеспечение высокой масштабируемости;
• обеспечение высокой эффективности;
Надёжность и недопустимость утраты достигается отсутствием единой точки от-
каза и избыточностью хранимых данных.
Масштабируемость означает отсутствие снижения скорости доступа к документам
при значительном росте их численности и обеспечивается высокой степенью параллелиз-
ма при доступе к документам, что требует использования всех возможностей канальной
архитектуры System z.
Эффективность, как отношение количества выполненной работы к количеству затра-
ченных ресурсов, достигается использованием в максимальной возможностей степени ка-
нальной архитектуры, для освобождения процессоров общего назначения.
В целом вопрос эффективности напрямую связан с вопросом стоимости. Для умень-
шения использования лицензируемых ресурсов процессоров общего назначения требуется
максимально использовать встроенные базовые возможности z/OS, использующие нели-
цензируемые ресурсы процессоров специального назначения.
Построение “СХОД” согласно описываемому принципу позволяет экономить дисковое
пространство и снизить загрузку процессоров общего назначения при сохранении требу-
емых надёжности, масштабируемости и времени доступа к документам. Неправильный
подход к организации хранения оригиналов документов на System z приводит к чрез-
мерно завышенной стоимости и в итоге отказу от платформы, как это было сделано в
Администрации Президента.
Одной из основных задач “СХОД” это демонстрация эффективности выше, чем в те-
кущей ситуации.
В данной работе описывается принцип построения системы хранения используя только
возможности z/OS, без использования СУБД, при котором достигаются поставленные
цели.
1
Binary large object.
2

1 Базовые возможности z/OS
Базовые возможности — те, которые являются неотъемлемой составной частью опера-
ционной системы z/OS и используются всем без исключения программнем обеспечением,
работающем в z/OS. В интерес ах построения “СХОД” могут быть использованы следую-
щие базовые возможности:
• наборы данных;
• методы доступа;
• VTOC;
• индекс VTOC;
• ICF;
• VLF.
1.1 Концепция наборов данных
z/OS работает с томами (volume), которые представляют собой образ диска, имеющую
какую-то геометрию (некоторое количество дорожек и цилиндров). Тома эмулируются
для z/OS нижележащими программно-аппаратными средствами, непосредственно рабо-
тающими с физическими дисками.
z/OS не имеет файловой системы2
. Данные в z/OS хранятся в наборах данных. На-
бор данных это именованная совокупность данных, имеющая логическую организацию и
физическую структуру, и доступная посредством специфического метода доступа z/OS.
Метод доступа это специальная программа, исполняющаяся “канальным” процессором
(процессором, предназначенным выполнять канальные программы, реализующие методы
доступа). Можно провести аналогию между драйвером устройства в других ОС и методом
доступа к определённому типу набора данных в z/OS.
“Канал” это специализированный процессор, канальные программы, и пути доступа к
данным.
Таким образом при работе с наборами данных z/OS ресурсы процессоров общего на-
значения используются в минимальной степени.
Длинна имени набора данных не может превышать 44 символов. Имя может состо-
ять из групп символов, разделённых точкой. Максимальная длинна группы символов не
может превышать 8 символов. Первая группа символов называется High Level Qualifier
(HLQ).
Dataset name sample
A1234567.BCDEFG78.H0987654.K01LMNOP.RSTUVXZQ
В примере выше A1234567 является HLQ. Надо понимать, что объекта A1234567 аналогич-
ного директории файловой системы не существует. Например, между следующими двумя
наборами данных нет ничего общего. Эти наборы данных полностью независимы, могут
находиться на разных томах.
Two different datasets
AAAAAAAA.BBBBBBBB.H0987654.K01LMNOP.RSTUVXZQ
AAAAAAAA.BBBBBBBB.H0987654.K01LMNOP.QZXVUXZQ
Не существует сущностей (директорий) AAAAAAAA и AAAAAAAA.BBBBBBBB. Такой подход поз-
воляет увеличить степень параллелизма при работе с наборами данных с одинаковыми
2
Это не относится к Unix SubSystem, USS.
3

HLQ, по сравнению со степенью параллелизма, доступной в файловых системах, при ра-
боте с файлами одной директории.
Существенное значение имеет тот факт, что минимальное дисковое пространство, вы-
деляемое для набора данных, является одна дорожка тома, что составляет порядка 55KB.
Если размер пользовательских данных меньше, то часть пространства, выделенного на-
бору данных, не будет использовано, но будет зарезервировано за набором данных, и не
будет доступно для использования другими наборами данных.
1.2 Volume Table of Content (VTOC)
Для работы с наборами данных, расположенными на томе, используется VTOC,
представляющий собой набор данных, организованный в виде Базы Данных (БД),
размещённой в определённом месте на томе. VTOC содержит все имена наборов данных,
которые хранятся на этом томе, с указанием их характеристик, прав доступа, и другой
необходимой информации. Для ускорения доступа к характеристикам наборов данных
используется структура, хранящая индекс VTOC. Поскольку VTOC разных томов абсо-
лютно независимы, то на разных томах могут храниться наборы данных с одинаковыми
именами.
The same names on different volumes
AAAAAAAA.BBBBBBBB.H0987654.K01LMNOP.RSTUVXZQ VOL001
AAAAAAAA.BBBBBBBB.H0987654.K01LMNOP.RSTUVXZQ VOL002
Таким образом, в общем случае программам для работы с наборами данных достаточно
указать имя набора данных и имя тома, на котором он находится. В случае наличия в
системе большого количества томов этих минимальных возможностей может оказаться
недостаточно — приходится запоминать имя тома, на котором расположен нужный набор
данных.
1.3 Integrated Catalog Facility (ICF)
Для упрощения работы большим количеством томов используется иерархическая
структура каталогов, которая хранит имена наборов данных с указанием томов, на кото-
рых они расположены (и ряд другой важной информации). Структура ICF представляет
собой набор данных VSAM, который является файл-ориентированной базой данных, име-
ющей структуру данных, индексные структуры, пулы памяти для работы с данными, и
методы доступа, которые являются канальными программами, и в минимальной степени
используют ресурсы процессоров общего назначения. Кроме этого ICF содержит важную
информацию, без которой невозможна работа с самими VSAM наборами данных, и невоз-
можна работа системы управления дисковым пространством (DFSMS, рассмотрена ниже
в разделе 2)
В z/OS присутствует один мастер-каталог, который содержит информацию о наборах
данных, необходимых для загрузки z/OS, и некоторое количество пользовательских ка-
талогов, содержащих информацию о других наборах данных. Мастер-каталог содержит в
себе ссылки на пользовательские каталоги.
То в каком каталоге будет содержаться информация о наборе данных, определяется на
основе HLQ — все наборы данных с одним HLQ будут каталогизированы в одном каталоге.
Это означает то, что с использованием ICF становится невозможно дублирование имён
наборов данных, даже если наборы данных расположены на разных томах.
4

1.4 Virtual Lookaside Facility (VLF)
VLF является важным компонентом ускорения доступа к данным ICF каталога, пред-
ставляет собой кеширование объектов каталога в памяти в особом хешированном списке.
VLF тесно интегрирована с ICF и все изменения в каталоге отображаются в VLF. Связь
между адресными пространствами ICF и VLF (как и между другими адресными про-
странствами, составляющими z/OS) осуществляется посредством cross-memory services,
которые функциональны схожи с POSIX InterProcess Communiction (IPC), но реализова-
ны на очень низком уровне, включая аппаратный, и в минимальной степени задействуют
ресурсы процессора общего назначения. Можно привести грубую аналогию и сказать, что
cross-memory services это IPC, реализованный аппаратно.
VLF позволяет обеспечить низкое время доступа к огромному количеству объектов
каталога.
1.5 Заключение
Базовые возможности z/OS предоставляют всё необходимое для организации парал-
лельной работы большого количества пользователей с большим количеством наборов дан-
ных при минимальном задействовании ресурсов процессоров общего назначения, что озна-
чает низкие лицензионные отчисления и высокую эффективность системы.
Эти базовые возможности используются всеми без исключения программами в z/OS,
включая СУБД. Можно сказать, что СУБД являются надстройкой над базовыми механиз-
мами доступа к наборам данных. Это означает, что если оригиналы документов хранить
в СУБД в виде BLOB, то это неизбежно добавит накладные расходы, особенно в загрузке
процессоров общего назнения. В частности СУБД DB2 большую часть работы выполняет
на процессорах общего назначения.
При организации хранения очень большого количества документов требуется исполь-
зование значительного количество томов, управление которыми вручную может быть тру-
доёмким. Расширенные возможности z/OS предоставляют удобные инструменты для ав-
томатизации управления большим количеством томов.
2 Расширенные возможности z/OS
Расширенные возможности это те, которые реализованы отдельными необязательны-
ми к применению продуктами и могут не присутствовать в конкретном экземпляре z/OS.
Для реализации “СХОД” основной интерес представляют продукты семейства Data Facility
Sotrage Management Subsystem (DFSMS). DFSMS позволяет автоматизировать задачи по
управлению большим количеством наборов данных и дисковым пространством. Управ-
ление осуществляется на основе политик. Политики определяют параметры создаваемых
наборов данных, тома, на которых они должны создаваться, порядок выполнения резерв-
ных копий, и множество других параметров.
Если профиль использования исторических документов в системе показывает, что ис-
торические документы могут быть затребованы в чрезвычайно редких случаях, и время
доступа к историческим документам в архиве довольно значительно, можно предполо-
жить, что продукт DFSMShsm из семейства DFSMS может оказаться очень полезным для
экономии дискового пространства.
5

2.1 DFSMShsm
Предназначен для управления дисковым пространством с целью его экономии, повы-
шения доступности системы, для создания резервных копий в интересах приложений и
восстановления из них. Это достигается построением иерархической трёхуровневой систе-
мы хранения наборов данных, и автоматизации перемещения документов с одного уровня
на другой.
Level 0 содержит обычные пользовательские наборы данных, непосредственно доступ-
ные для работы, размещённые предпочтительно на “быстрых” дисках.
Level 1 также размещает наборы данных на дисках, которые могут быть менее быстрые,
чем диски для Level 0, но основное отличие в том, что на этом уровне наборы дан-
ных имеют специальный внутренний формат, и недоступны для непосредственного
использования пользователями. На этом уровне может достигаться существенная
экономия дискового пространства в случае наличия большого количества наборов
данных, фактический размер которых существенно меньше одной дорожки. При пе-
ремещении таких наборов с Level 0 на Level 1 они могут объединяться в один набор
данных, что позволяет более экономно расходовать дисковое пространство за счёт
устранения неиспользуемого, но распределённого пространства.
Level 2 также хранит данные в наборах внутреннего формата, но наряду с дисковым про-
странством может использовать магнитные ленты, освобождая дисковое простран-
ство от перемещённых наборов данных.
Перемещение может происходить автоматически, согласно заданных политик. Перемеще-
ние может осуществляться с Level 0 на Level 1 и 2, с Level 1 на Level 2, и с Level 1 и 2 на
Level 0.
DFSMShsm тесно интегрирован с остальными компонентами z/OS, в частности с ICF.
В каталоге ICF том, мигрировавший с Level 0 на Level 1 или 2 помечается как мигриро-
вавший. При обращении любого приложения к такому набору данных DFSMShsm авто-
матически перемещает его на Level 0 и предоставляет приложению.
При этом надо учитывать, что если на уровне Level 2 используются магнитные ленты,
то на перемещение набора данных на Level 0 потребует существенных затрат времени. Па-
раллелизм доступа множества пользователей к наборам данных на Level 2 на магнитных
лентах сильно зависит от количества устройств работы с лентами в ленточной библиоте-
ке. Если все доступные устройства заняты, то все последующие запросы пользователей
на доступ к наборам данных будут накапливаться в очереди. Это требует тщательного
планирования конфигурации ленточной библиотеки исходя из количества работающих
пользователей, частоты доступа к архивным наборам данных, и допустимого времени
ожидания пользователей.
Минимальная единица данных, с которой работает DFSMShsm, является набор дан-
ных. Это позволяет помещать в архив на магнитную ленту и извлекать из архива набо-
ры данных индивидуально, что является несомненным преимуществом продукта, так как
аналогичные продукты организации иерархической системы хранения данных для СУБД
работают не с отдельными документами, с крупными наборами документов, что увеличи-
вает загруженность системы ввода-вывода.
2.2 Заключение
При построении систем архивного хранения большого количества документов в сре-
де z/OS необходимо использовать расширенные возможности z/OS в виде семейста про-
6

дуктов DFSMS, что позволит значительно снизить затраты на управление большим ко-
личеством документов, большим дисковым пространством, позволит автоматизировать
большинство процессов и позволит экономить дисковое пространство за счёт организации
иерархической системы хранения.
3 Архитектурное решение “СХОД”
3.1 Контекстная диаграмма
“СХОД”
Серверы
приложений
клиентская часть
Администраторы
СУБД кар-
точек до-
кументов
соответствие по имени набора данных
3.2 Компонентная диаграмма “СХОД”
набор данных
IDXVTOC VTOC
ICF
VLF
DFSMShsm
tape
Метод
доступа
Серверная
часть
клиентского
доступа
volume
клиентская часть
7

3.3 Архитектурное описание
Принцип системы хранения оригиналов документов чрезвычайно прост. Входящий
оригинал документа сохраняется в виде набора данных z/OS. Атрибуты для поиска кон-
кретного документа сохраняются в СУБД, отдельно от оригинала документа, в виде на-
бора сущностей, совокупность которых можно назвать “Карточка документа”. Вместе с
“карточкой документа” сохраняется имя набора данных, в котором сохранён оригинал
документа. Управление размещением, архивированием, созданием резервных копий реа-
лизуется штатными средствами z/OS.
При необходимости извлечения оригинала документа выполняется поиск по “карточ-
кам документов” для определения соответствующего имени набора данных, после чего он
извлекается.
Для загрузки и выгрузки оригиналов документов в наборы данных можно исполь-
зовать разные средства. Но надо учитывать одну важную особенность. Если набор дан-
ных будет архивирован DFSMShsm на Level 2 на магнитную ленту, то время извлечения
оригинала документа может быт значительным, и составлять десятки минут, что может
превышать время ожидания сессии сеанса TCP/IP.
Самым простым средством загрузки и извлечения наборов данных является использо-
вание FTP. Такое решение будет масштабируемо и эффективно. Но в случае, если набор
данных мигрировал на магнитную ленту, времени ожидания FTP сессии может не хва-
тить, и может потребоваться другое решение. Но для загрузки документов возможностей
FTP вполне достаточно.
Универсальным решением для извлечения документов могло бы стать применение MQ,
как средства, использующего асинхронный протокол работы в отличии от FTP, исполь-
зующего синхронный протокол. Но продукт MQ лицензируется отдельно.
Как промежуточный этап можно реализовать асинхронный протокол при использова-
нии транспорта FTP. В этом случае необходимо создание серверного приложения в z/OS
которое будет принимать клиентские запросы с именами наборов данных на извлечение, и
с указанием на какой FTP сервер и в какую директорию их положить, затем будет извле-
кать указанный набор данных и отправлять по FTP в указанное место. Но такой подход
требует дополнительной разработки с последующим сопровождением как на стороне z/OS,
так и на стороне клиентского ПО.
3.4 Этапы создания “СХОД”
Для создания системы требуется набор простых процедур, знакомых каждому адми-
нистратору z/OS. Достаточно:
1. инициализировать набор томов с указанием необходимых размеров VTOC и его ин-
декса;
2. создать необходимый набор политик (классов, группу хранения и правила их назна-
чения) в DFSMS;
3. создать пользовательский каталог ICF, и связать его с мастер-каталогом посред-
ством альяса.
После этого система готова принимать входящие документы. Требуемое время для вы-
полнения этих шагов чрезвычайно мало, буквально минуты. Но для выполнения этих
процедур необходимо определить ряд ключевых параметров.
3.4.1 Определение медианного размера набора данных
Эта информация служит входной для определения количества наборов данных, кото-
рые поместятся на том определённого размера. Исходя их количества наборов данных на
8

томе определяется необходимый размер VTOC.
3.4.2 Создания конвенции имён наборов данных
Разработка способа наименования является важным моментом. Имя набора данных
определяет в каком пользовательском каталоге ICF будет каталогизирован набор. Так-
же длина имени набора данных служит входной информацией для определения размера
индекса VTOC.
На этом этапе будет готовая информация для создания задания на инициализацию
томов и известен HLQ для создания каталога который и является именем альяса для
связывания мастер-каталога и пользовательского каталога.
3.4.3 Определение размера VSAM для каталога ICF
Ожидаемое совокупное количество наборов данных для хранения служит входной ин-
формацией для определения размера пользовательского каталога ICF. Остальные для
создания пользовательского каталога уже известны.
3.4.4 Конфигурация DFSMS
Необходимо создать политики, согласно которым будут определятся параметры набо-
ров данных на протяжении их жизненного цикла а также их жизненный цикл — архиви-
рование, создание резервных копий, миграция на магнитную ленту. Политики создаются
в виде определения классов data class, management class. Для выделения дискового про-
странства под наборы данных создаётся storage group с перечислением входящих в неё
томов. С течением времени при росте размера архива новые тома в storage group добав-
ляются динамически, без приостановки работы системы.
Для автоматизации назначения классов и группы создаются программы автоматиче-
ского выбора классов, ACS routines.
Система готова принимать входящие наборы данных, содержащие оригиналы доку-
ментов.
3.5 Очерёдность создания “СХОД”
В виду того, что часть оригиналов документов уже загружены в СУБД в виде BLOB,
создание “СХОД” можно начать с загрузки ретроспективных (исторических) документов.
После отработки технологии следующим этапом необходимо предусмотреть выгрузку ори-
гиналов документов из СУБД и загрузку в “СХОД”.
На переходный период, в течении которого документы будут хранится старым методом
и новым, пользовательские приложения должны быть адаптированы для использования
двух способов работы с документами.
4 Риски
Так как одной из основных целей системы является надёжное хранение документов с
недопустимостью их утраты, важным является определение и оценка рисков и способов
устранения связанных с ними опасностей. В основном риски касаются наличия единой
точки отказа и единственной копии существующих данных. Для устранения этих рисков
необходимо зафиксировать места, в которых может быть единая точка отказа или может
9

существовать единственная копия данных, и принять меры для устранения этой ситуации
— для дублирования единственного элемента, который может отказать, и для создания
дополнительной (резервной) копии данных.
4.1 Устранение единой точки отказа
В целом платформа System z имеет дублирование всех компонент. Но при организации
“СХОД” могут возникнуть следующие единые точки отказа:
• единственная дисковая стойка;
• единственная ленточная библиотека.
При выходе из строя любого из этих компонент доступ к данным может быть невозможен
длительное время, а сами данные могут быть утеряны. Идеальным случаем избегания
риска было бы наличие двух дисковых стоек и двух ленточных библиотек, дублирующих
друг друга. В случае с дисковыми стойками они могут быть настроены в полное зеркали-
рование данных. Полностью зеркалировать ленты в ленточных библиотеках смысла нет,
достаточно иметь свободную ленточную библиотеку, в которую можно загрузить катри-
джи из вышедшей из строя библиотеки, если это допускается регламентным временем по
доступу к архивным данным.
4.2 Создание избыточности по данным
Сразу после загрузки документа в набор данных существует единственная копия это-
го документа. В случае отсутствия зеркалирования дисков и дисковой стойки это может
оказаться критичным. Для устранения этого риска необходимо предусмотреть создание
резервной копии набора данных на магнитной ленте. Для этого можно использовать ути-
литу, которая, будучи периодически запущена, проверяет VTOC на наличие новых (или
изменённых) наборов данных и составляет их список для резервного копирования, после
чего резервное копирование списка наборов данных осуществляется штатными средства-
ми.
По мере заполнения томов необходимо предусмотреть полное физическое резервное
копирование заполненных томов на магнитную ленту, что позволит выполнить резервное
копирование VTOC и его индекса.
В целом катриджи магнитных лент являются надёжным устройством и допускают
многократное использование, выдерживают множество циклов чтения и записи. Но так
как они являются сложными механическими устройствами, необходимо предусмотреть
создание избыточных копий магнитных лент штатными средствами.
4.3 Контроль логической целостности
Так как имена наборов данных хранятся в разных местах — во VTOC и в ICF, то
периодически для профилактики и после каждого программного или аппаратного сбоя
целесообразно контролировать соответствие записей VTOC записям ICF с использованием
специальной утилиты.
5 Вывод
Использование возможностей z/OS позволяет построить высоконадёжную и высокоэф-
фективную систему хранения оригиналов документов. Надёжность системы приводит к
высокой доступности данных для приложений и пользователей, а высокая эффективность
10

приводит к низкой стоимости создания системы, и что более важно, к низкой стоимости
сопровождения системы на протяжении всего периода эксплуатации. Любые другие про-
дукты и платформы приведут или к более низким качествам системы (в плане надёжно-
сти, производительности, времени отклика) или к более высокой стоимости (в основном на
лицензирование ПО по процессорным ядрам) за период эксплуатации системы. Встроен-
ные средства z/OS позволяют автоматизировать значительную часть административных
задач по регулярному управлению системой, при чём эти средства уже в наличии и до-
ступны к применению.
Предлагаемый подход может быть необычным для мира Unix и Winows, но является
довольно распространённым в мире z/OS. Существующие в России системы хранения ори-
гиналов документов показывают неплохие результаты на протяжении многих лет, обслу-
живая 2300 одновременно работающих пользователей, имея 1200 одновременно открытых
FTP сессий, перемещая 10000 документов за рабочий день, имея время отклика меньше
секунды (для наборов данных на дисках) и имея загрузку процессоров общего назначения
на уровне статистической погрешности.
11

Система Хранения Оригиналов Документов

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (9)

Similar to Система Хранения Оригиналов Документов

Similar to Система Хранения Оригиналов Документов (20)

Система Хранения Оригиналов Документов