IBM Tivoli Storage Manager представляет хранилище данных в виде объектов, определяемых администратором, - пулов хранилища и томов в составе пулов, - на основе физических объектов хранения данных, таких как библиотеки, ленты и диски.
В следующих разделах мы поговорим о том, как IBM Tivoli Storage Manager автоматически управляет этими пулами и как вы можете определять и проверять то, что команда, которую вы выполнили, произвела те изменения, которые вы хотели.
Также мы обсудим ряд общих проблем, относящихся к пулам хранения IBM Tivoli Storage Manager: как пользоваться меньшим количеством лент (reclamation) и сократить время восстановления клиента (collocation). Кроме того, мы сделаем краткий обзор приемов защиты дискового хранилища при помощи RAID-массивов.
Устройства и носители информации представлены в IBM Tivoli Storage Manager объектами, которые хранятся в базе данных. Эти объекты содержат информацию о носителях и устройствах. Вы можете строить запросы к этим объектам, обновлять их и удалять.
На рис. 11-1 дано общее представление об объектах хранилища IBM Tivoli Storage Manager и отношениях между ними.
Рис. 11-1 Объекты хранилища IBM Tivoli Storage Manager
Пул хранилища (storage pool) - это совокупность томов пула; каждый пул представляет накопители одного типа. Например, пул хранилища для накопителей на 4-миллиметровых цифровых аудиолентах (DAT) представляет только совокупность 4-миллиметровых лент, а пул хранилища для IBM 3590 - только совокупность лент для 3590. Пул хранилища, организованный на диске, содержит файлы, прошедшие форматирование в IBM Tivoli Storage Manager как тома и объединенные в группу как пул хранилища.
Тома можно добавлять в пул и удалять их, не прерывая операций на сервере. Тем самым, можно динамически увеличить или уменьшить объем пула хранилища без приостановки службы IBM Tivoli Storage Manager.
Две основные категории накопителей, которые поддерживают пулы хранилищ, - это устройства с произвольным и последовательным доступом.
- Понятие устройства произвольного доступа указывает на магнитные диски.
- Понятие устройства последовательного доступа к данным обычно указывает на ленточные и (или) оптические накопители, которые требуют ручного конфигурирования. Диск тоже можно сконфигурировать так, чтобы доступ к нему был лишь последовательным (класс накопителя FILE).
Пулы хранилищ в IBM Tivoli Storage Manager существуют на базе широкого спектра разнообразных устройств, к которым можно локально подключиться на сервере или обратиться через сеть хранения данных (SAN).
В основе пула хранилища лежит класс накопителя (device class), определяющий тип аппаратуры хранения, используемой в данном пуле хранилища. Класс накопителя не только содержит тип устройства хранения, но и указывает на специальное устройство хранения, описанное на сервере IBM Tivoli Storage Manager.
Каждое описанное в IBM Tivoli Storage Manager устройство связано с одним классом. Этот класс определяет тип устройства и такие сведения, необходимые для управления накопителем, как формат записи, оценочная емкость и префиксы маркировки.
IBM Tivoli Storage Manager имеет набор заранее описанных типов устройств со съемными накопителями, например 8MM для 8-миллиметровых ленточных накопителей или REMOVABLEFILE для дисководов Jaz или Zip. Единственными устройствами произвольного доступа являются магнитные дисковые устройства. Все дисковые устройства имеют один и тот же тип и предопределенный класс накопителя DISK.
При пользовании накопителем с последовательным доступом класс накопителя обычно указывает на связанную с ним библиотеку, которая содержит данные из пулов хранилища, в основе которых лежит этот класс накопителя.
Как смешанные (mixed) на сервере IBM Tivoli Storage Manager описаны те накопители, в которых в одной и той же логической библиотеке использованы устройства различных типов (заданные оператором define devclass). Двумя примерами устройств, каждому из которых необходим свой класс накопителя, но которые могут совместно существовать в пределах библиотеки, являются Ultrium 1 и SDLT.
Устройства смешанных поколений на сервере IBM Tivoli Storage Manager описывают устройства, которые, несмотря на разницу в емкости, имеют один и тот же тип накопителя. Чтобы в один и тот же класс накопителей входили устройства смешанных поколений, тип накопителя должен быть различимым.
Примечание В среде, где есть устройства нескольких поколений, текущее поколение устройств, как правило, может производить считывание и запись накопителей текущего и предшествующих поколений. Устройство предыдущего поколения может читать и записывать только накопители предыдущего поколения. Примерами устройств нескольких поколений являются устройства LTO Ultrium. Дальнейшие подробности внедрения устройств LTO и IBM Tivoli Storage Manager изложены в книге (redbook) Using IBM LTO Ultrium with Open Systems, SG24-6502.
Библиотека представляет объект хранилища, который содержит приводы и ленты для хранения данных. Ее нельзя использовать без указания приводов. Заметим, что определенная в IBM Tivoli Storage Manager библиотека представляет собой только логический объект, который в данный момент никак не соотносится с реальной аппаратурой. Непосредственная связь логической и физической библиотеки будет определяться далее, объектом категории «путь».
Привод есть часть библиотеки, которая служит для записи данных на ленточные тома, расположенные в связанной с ними библиотеке, и чтения данных оттуда. Специальный аппаратный формат, используемый ленточным накопителем, представлен нужным классом накопителя данных(device class). И хотя класс не связан с объектом-накопителем напрямую, их объединяет библиотека, в которой содержатся приводы. Как сказано в разделе «Библиотека», в данный момент привод - это всего лишь логический объект. Прямая связь будет установлена позже, при помощи объекта-пути.
Путь открывает доступ к библиотекам и приводам. В его описание входят адреса источника и приемника. Таким образом, он соединяет логический уровень сервера IBM Tivoli Storage Manager с физической реальной аппаратурой. Благодаря наличию такой сущности все устройства хранения на сервере становятся разделяемыми между различными серверами IBM Tivoli Storage Manager, агентами хранения и клиентами. Все они пользуются одним и тем же логическим объектом, но описание пути к каждому из них разное, поэтому для них организуются индивидуальные подключения к связанной с ними аппаратуре.
Устройство-источник обращается к устройству-приемнику, однако данные между ними могут двигаться в любом направлении. Вот несколько примеров путей.
- При операциях в локальной сети и большинстве SAN управляющие и клиентские данные движутся по пути с сервера IBM Tivoli Storage Manager в описанную на нем автоматизированную библиотеку. В процессе восстановления поток клиентских данных направлен обратно - из библиотеки на сервер.
- При операциях по протоколу NDMP данные резервного копирования движутся по пути между источником - data mover, определенным для файл-сервера NAS, -и приемником - ленточным накопителем. При восстановлении данные проходят обратный путь: с ленточного накопителя на файл-сервер NAS. Один и тот же приемник в составе путей может принимать данные из разных источников. Например, при операциях по протоколу NDMP требуется, чтобы любой путь соединял data mover, представляющий файл-сервер NAS, и привод, на который файл-сервер передает данные для резервирования. Один и тот же ленточный накопитель может являться приемником нескольких data mover файл-серверов NAS.
Data mover - это устройство, принимающее запросы от Tivoli Storage Manager на передачу данных от имени сервера. Data mover передает данные:
- между устройствами хранения;
- без привлечения значительных ресурсов сервера или клиента IBM Tivoli Storage Manager;
- без использования существенных ресурсов сети.
При NDMP-операциях data mover - это файловые серверы NAS. Определение data mover NAS содержит сетевой адрес, информацию для авторизации, а также форматы данных, необходимые для выполнения операций NDMP. Data mover обеспечивает коммуникацию и гарантирует наличие полномочий для проведения операций между сервером IBM Tivoli Storage Manager и файл-сервером NAS.
Возможность установки прямого соединения между различными серверами IBM Tivoli Storage Manager может оказаться полезной, в том числе, для передачи и хранения данных. Таким образом, дополнительные серверы IBM Tivoli Storage Manager также представляют собой устройства хранения, которые можно использовать через особый класс накопителей.
Объект-сервер требует определения для следующих целей.
- Использование библиотеки, находящейся в сети SAN и управляемой другим сервером IBM Tivoli Storage Manager - вы должны дать определение этого сервера, а затем выбрать его как менеджер библиотеки при ее описании.
- Реализация LAN-free передачи данных - определите агент хранения как объект-сервер;
- Хранение клиентских данных в хранилище другого сервера IBM Tivoli Storage Manager.
IBM Tivoli Storage Manager имеет два типа пулов хранилища:
- первичные пулы хранилища (primary storage pools);
- пулы хранилища копий (copy storage pools).
Когда узел-клиент производит резервное копирование, архивацию или перенос данных, данные сохраняются в первичном пуле хранилища.
Когда пользователь пытается восстановить, извлечь или экспортировать данные файла, запрошенный файл, если это возможно, берется из первичного пула. Тома первичного пула хранилища всегда расположены на локальной площадке.
В первичном пуле хранилища могут использоваться устройства с произвольным (класс накопителя DISK) или последовательным доступом к данным (например, ленточные, оптические; класс накопителя FILE).
Пул хранилища копий обеспечивает дополнительный уровень защиты клиентских данных. Он создается администратором, снимающим резервную копию с первичного пула. Пул хранилища копий содержит все - активные и неактивные - текущие версии всех файлов, в точности повторяя их состояние в первичном пуле хранилища.
Пул хранилища копий позволяет восстановить данные после частичного или полного отказа первичного пула. Примером частичного отказа является потеря одной из лент первичного пула хранилища или дефект на ленте. Когда клиент предпримет попытку восстановить файл с этого тома, сервер для незаметного восстановления клиентских данных автоматически переключится на нужный том в хранилище копий. В случае если первичный пул будет разрушен полностью (например при крупной аварии), пул хранилища копий послужит для его воссоздания.
Пул хранилища копий может использовать устройства с последовательным доступом (например, ленточные, оптические; класс накопителя FILE). Также подобный пул можно построить удаленно на другом сервере IBM Tivoli Storage Manager, организуя, тем самым, распределенное хранилище информации. Подробнее об этом см. раздел 14.4 «Виртуальные тома».
Тома пула хранилища копий могут передаваться на альтернативную площадку хранения, но по-прежнему отслеживаться средствами IBM Tivoli Storage Manager. Чтобы гарантировать, что IBM Tivoli Storage Manager не потребует монтировать том, это делается при помощи режима автономного доступа (offsite). Перемещение томов хранилища копий на другую площадку дает возможность восстановления после аварии на первичной. Автоматизировать контроль за накопителями в альтернативном месте хранения и восстановление пула хранилища поможет Disaster Recovery Manager (подробности см. в главе 16 «Disaster Recovery Manager»).
Пулы копий не являются частью иерархии переноса хранилищ. Перенос файлов в пулы хранилища копий и обратно не производится. Сохранить файл в пуле хранилища копий можно двумя путями:
- скопировать первичный пул хранилища в пул хранилища копий командой BACKUP STGPOOL;
- одновременно производить запись в пул хранилища копий при передаче данных клиента.
При записи файлов клиента IBM Tivoli Storage Manager способен одновременно записывать их в каждый из пулов хранилища копий, указанных в первичном пуле хранилища. Одновременная запись в пулы хранилища имеет место лишь при резервном копировании клиента либо его архивации (другими словами, когда данные «втекают» в иерархию пулов хранилища). Она не производится ни при миграции данных с HSM-клиента, ни при LAN-free резервном копировании с участием агента хранения. Для каждого первичного пула можно задать до 10 пулов хранилища копий. Данная операция не подменяет собой BACKUP STGPOOL. Команда BACKUP STGPOOL не может производить запись в несколько пулов хранилища копий одновременно.
Рис. 11-2 Одновременная запись
При одновременной записи или организации дуплекса необходимо все тщательно взвесить. Данные заносятся в пул хранилища копий и первичный пул одновременно. При этом производительность резервного копирования окажется не выше производительности самого медленного из устройств, находящихся в каком-либо пуле. Также необходимо иметь достаточное количество точек монтирования; иначе клиент и только клиент, но не сервер, выдаст сообщение
ANS1312E: ANS1312E Server media mount not possible
Примечание Если в один и тот же первичный пул резервируются многочисленные клиенты, а пулы копий построены на базе лент, то каждый клиент, чтобы иметь возможность одновременно записывать данные в пул копий, потребует множества точек монтирования. Количество точек монтирования, доступных узлу, ограничивает параметр узла MAX NU MM P.
IBM Tivoli Storage Manager позволяет сконфигурировать пулы хранилища так, чтобы добиться лучшего сочетания производительности системы и сохранности данных. В большинстве случаев обязательным требованием является хранение данных клиентов на ленточных или оптических накопителях. Однако прямая запись резервных копий на ленту не может обеспечить наивысшей производительности, особенно при параллельном резервировании большого числа клиентов и наличии множества небольших файлов. По этой причине IBM Tivoli Storage содержит иерархию пулов хранилищ, при помощи которой клиент сначала резервирует свои данные в один из пулов, обычно на диск. Когда пул заполняется, IBM Tivoli Storage Manager автоматически перемещает файлы в следующий пул хранилища в иерархии (обычно на ленты или оптические устройства), клиент же в это время продолжает операцию резервирования. Процесс миграции подчинен заданным в пуле хранилища верхнему и нижнему пороговому значению.
Точку входа клиентских данных в иерархию хранения определяет управляющий класс (см. раздел 9.2 «Компоненты политики хранения данных»). Рис. 11-3 показывает конфигурацию с пятью пулами. Класс управления по умолчанию сначала передает резервные копии в пул хранилища A, откуда затем они пересылаются сервером в пул B, и наконец - в пул C. Другой класс управления для файлов, переносимых на сервер при освобождении пространства клиента, использует пул хранилища D; резервные копии он напрямую передает в ленточный пул. Это решение приемлемо для больших файлов клиента (например файлов баз данных приложений), допускающих возможность потоковой передачи на ленточные устройства.
Рис. 11-3 Возможное иерархическое расположение различных устройств хранения
Автоматическому контролю пространства в пулах хранения призваны помочь два средства управления системой:
- миграция (migration);
- максимальный размер (maxsize).
Миграция помогает отрегулировать объем свободного пространства в пуле хранения. Для каждого из пулов хранения в иерархии можно задать верхний и нижний миграционный порог. Эти пороги указывают IBM Tivoli Storage Manager, когда переносить данные из одного пула в другой, как это показано на рис. 11-4.
Если количество данных в пуле хранилища достигает верхнего порогового значения, IBM Tivoli Storage Manager перемещает клиентские данные в следующий пул хранения до тех пор, пока в первом из пулов не будет достигнуто нижнее пороговое значение. Цель переноса - очистить как можно больше пространства, причем как можно быстрее. Для этого IBM Tivoli Storage Manager выбирает узел-клиент, набор данных которого занимает больше всего пространства в пуле хранилища, и переносит самое крупное файловое пространство с данными выбранного клиента. Затем он выбирает следующий узел-клиент, имеющий больше всего данных, и переносит их. Миграция продолжается, пока не будет достигнут или пройдет нижний порог, и всегда осуществляется на уровне пространств файлов. Эта операция не только быстро освобождает место, но и сохраняет слитность клиентских данных в иерархии пулов. Подобный механизм, в свою очередь, сокращает число операций монтирования носителей, необходимых во время восстановления данных клиента.
Для пулов хранилищ произвольного доступа, и только для них, вы можете определить количество процессов, используемых при переносе данных из пула. Этот параметр необязателен и по умолчанию имеет значение 1. Количество процессов миграции вы можете задать равным или меньшим числа накопителей в следующем пуле хранения, в который происходит миграция; эти процессы выполняются параллельно для повышения скорости передачи данных. Однако не забывайте, что если в принимающем пуле хранения у вас есть два устройства на лентах и вы установили параметр в значение 2, работа будет пересекаться с любыми другими запросами к ленточному устройству, пока процесс миграции не завершится. Если ваш дисковый пул имеет достаточно места, а диски кешируются (см. раздел 11.6.2 «Кеширование дисков») или вы указали значение задержки миграции (migration delay), это может свести вероятность таких проблем к минимуму.
Для файлов в пуле хранилища вы можете задать количество дней задержки миграции; это станет гарантией того, что минимальное, указанное, количество дней файлы сохраняются в пуле. Из установки названного параметра может вытекать потребность в большем объеме пространства дискового пула хранилища для хранения файлов. Преимущество такого подхода состоит в том, что нужные файлы можно восстановить быстрее, если они еще не оказались перенесенными из дискового пула хранилища.
Рис. 11-4 Миграция между пулами хранилища данных
Если для пула хранилища назначить значение MAXSIZE, то файлы смогут попадать в него лишь при условии, что их размер не превышает выбранного MAXSIZE. При использовании компрессии сравнение делается с размером файла до сжатия. Если файл слишком велик для первого пула хранилища, он сразу же уходит в следующий заданный пул. Это - еще один способ повысить производительность, не тратя времени на запись объемных файлов в первый из пулов, что вызовет лишь незамедлительную миграцию при заполнении пула хранилища информации.
Этот параметр необязателен. Если вы не назначили значения MAXSIZE, а файл, оказавшийся в пуле, вызвал превышение верхнего порога миграции, перенос данных в очередной пул хранилища начнется автоматически.
Reclamation служит для полного освобождения ленточных (или оптических) накопителей в пулах хранилища с последовательным доступом к данным. Поскольку IBM Tivoli Storage Manager сохраняет определенное количество версий файлов по мере создания инкрементов, самая старая копия файла (оказавшаяся вне пределов числа хранящихся копий) помечается как устаревшая. В дальнейшем этот файл будет удален при следующем ограничении существования(expiration).
Наличие на ленточных томах файлов, устаревающих в разные дни, - явление распространенное. Поэтому по мере достижения файлами предельных сроков существования и в результате принудительного ограничения их времени жизни в ленточном томе образуются «виртуальные» пустые пространства. Фрагментация тома может проявляться и при удалении файлов на машине-клиенте, что вызывает уничтожение множества версий файла в силу определений управляющих классов, или по причине удаления всего файлового пространства. Фрагментация лент или оптических дисков нежелательна потому, что замедляет восстановление ввиду необходимости пропускать пустые пространства и увеличивает общее количество лент, требуемых для хранения данных. Вернуться и переписать новые данные на месте пустого пространства нельзя, поскольку это - накопители с последовательным доступом к данным и записать их можно лишь от начала и до конца.
Объем пространства, который можно высвободить на томе, растет по мере удаления с него файлов. Когда же доля пространства, допускающего восстановление на томе, превысит значение установленного для пула хранилища порога (reclaim threshold), том подвергают высвобождению. Активные файлы тома перезаписывают на другие тома пула хранилища, делая исходный том совершенно пустым. Обычно том возвращается в первоначальное состояние, иначе говоря, он снова доступен для повторного применения при выполнении любой функции IBM Tivoli Storage Manager, которой он будет нужен. Восстановление двух фрагментированных томов и получение пустого тома и тома, имеющего 95-процентное заполнение, показано на рис. 11-5.
Рис. 11-5 Reclamation на двух фрагментированных томах
Процесс reclamation для томов, не помеченных как находящиеся на альтернативной площадке, может происходить лишь после того, как том заполнен и начал освобождаться по причине удаления файлов. Процесс восстановления требует много ресурсов устройств, т. к. обычно ему необходимы, как минимум, два доступных привода в составе библиотеки. Это может неоправданно задержать другие критические операции IBM Tivoli Storage Manager (например восстановление клиента), если все приводы заняты в процессе reclamation. Поэтому обычно мы рекомендуем отключать reclamation для накопителей, установив reclaim threshold для пула хранения равным значению 100. В удобное время, скажем, в субботу после полудня, восстановление может быть активировано запуском административного расписания, а порог снижен до приемлемого значения, что автоматически инициирует начало восстановления. Затем порог может быть снова установлен в значение 100 для обеспечения нормальной работы на протяжении недели.
Процесс reclamation для тома на альтернативной площадке может происходить независимо от того, заполнен он или нет. Том в удаленном месте хранения может быть высвобожден, если процент незанятого пространства превысит величину параметра reclaim. Незанятое пространство включает в себя как часть тома, которая никогда не использовалось, так и объем, освободившийся из-за удаления файлов. Во избежание чрезмерно интенсивного высвобождения накопителей в пулах хранилища копий его также рекомендуется отключать на все время, кроме определенных периодов, как это описано в предыдущем параграфе. Еще одна причина регламентации высвобождения носителей в удаленных хранилищах будет рассмотрена в разделе 11.5.2 «Восстановление томов на альтернативной площадке».
Для наиболее эффективной работы процесс reclamation требует наличия двух или более приводов. Тем не менее, в IBM Tivoli Storage Manager этот процесс можно произвести и на одном приводе, задав параметр RECLAIMSTGPOOL. Этот параметр дает возможность использовать другой пул хранилища как временную зону хранения для объединяемых томов.
Пул, заданный как reclaim-пул, должен являться в системе первичным пулом хранилища с последовательным доступом к данным. Как правило, это новый первичный пул, созданный специально для этих целей. Чтобы использовать как зону перемещения дисковое устройство, тип накопителя должен иметь значение FILE: такой диск должен обеспечивать последовательный доступ.
Когда объем пространства, пригодного для высвобождения в пределах тома на накопителе, превышает reclaim threshold, IBM Tivoli Storage Manager начинает процесс reclamation автоматически. Том, подлежащий высвобождению, монтируется в приводе, и активные данные передаются в reclaim-пул хранилища. Если reclaim-пул заполнен, очищаемый том демонтируется, и вместо него монтируется новый том, взятый из того же пула хранилища. Данные из reclaim-пула переносятся на этот ленточный том. По завершении процесса действия будут повторяться, пока не будут высвобождены все нужные данные с очищаемого тома-источника.
Если же reclaim-пул хранилища не заполнился до полной очистки тома-источника, монтируется другой том-источник, и процесс reclamation продолжается. Процесс длится до заполнения reclaim-пула или удаления всех устаревших данных из пула хранилища.
При описании reclaim-пула вы должны также определить параметр NEXTSTGPOOL, который указывает обратно на пул, находящийся в процессе высвобождения. Тем самым, данные после высвобождения смогут переместиться обратно в исходный пул хранилища информации (рис. 11-6).
Рис. 11-6 Пример процесса reclamation на одном приводе
В этом примере TAPEPOOL есть пул хранилища, описанный в библиотеке с единственным приводом. Reclaim-пулом (RECLAIMSTGPOOL) для TAPEPOOL является FILEPOOL, а следующим пулом хранилища (NEXTSTGPOOL) для FILEPOOL будет TAPEPOOL. Следует отметить, что процесс reclamation на одном приводе является продолжительным по времени, поэтому во избежание такого долгого высвобождения мы настоятельно рекомендуем использовать конфигурации IBM Tivoli Storage Manager с двумя или более приводами в каждой библиотеке.
Процесс reclamation для томов в удаленных хранилищах копий требует особенной осторожности.
IBM Tivoli Storage Manager не может физически перенести данные из одного подобного тома в другой, поскольку те находятся в электронном архиве и не доступны в библиотеке. Система управляет высвобождением накопителей пула копий в альтернативном месте хранения, получая активные файлы из первичного пула хранилища или тома из пула копий, находящегося на основной площадке. Затем эти файлы будут помещены в новый том пула копий, а база данных обновлена. После этого будет выдано сообщение о том, что том на удаленной площадке высвобожден. Новый том передается в альтернативное хранилище, а том с удаленной площадки, активные данные с которого мы свели в новый, по истечении параметра задержки повторного применения возвращается в пул свободных томов на основной площадке (см. рис. 11-7).
Рис. 11-7 Процесс reclamation для томов на альтернативной площадке
Однако в случае катастрофы могут возникнуть проблемы: если высвобожденные тома уже были возвращены в пул свободных томов, а новый том еще не был отправлен в альтернативное место хранения, то мы теряем любую возможность использовать удаленную резервную копию. В этом и состоит причина введения периода задержки повторного применения для лент, возвращенных в пул свободных томов. Помните также, что для использования в случае катастрофы томов на лентах 000012 и 000013 из удаленного хранилища данных вам будет требоваться резервная копия базы данных со ссылками на файлы, расположенные на этих томах.
Достичь этого можно, контролируя время проведения процесса reclamation благодаря грамотному планированию. По сути, вы должны гарантировать, что создали резервные копии всех пулов хранилища с основной площадки и поместили их в удаленные пулы копий, а затем выполнили резервное копирование базы данных системы, с тем чтобы копия базы данных в альтернативном хранилище имела ссылку на каждый файл по его новому адресу. После этого можно заняться высвобождением накопителей. Задержка повторного применения, заданная в пулах хранилища, должна быть достаточно продолжительной, что станет гарантией того, что высвобожденные тома не возвратились в пул свободных томов до снятия новой резервной копии базы данных.
Конфигурирование пула хранилища способно сократить время восстановления данных благодаря следующим приемам.
- Совместное размещение - минимизация количества томов на лентах, используемых для хранения данных клиента.
- Кеширование диска - восстановление данных с диска даже после миграции.
- Перенос данных в пулы хранилища быстрого доступа или объединение данных перед восстановлением.
Совместное размещение (colocation) - это процесс, в ходе которого сервер пытается хранить все файлы, которыми владеет один узел-клиент, на минимальном количестве томов хранения с последовательным доступом к данным.
Для того чтобы совместно размещать данные в условиях, когда файлы с различных клиентских узлов перемешаны в одном и том же пуле хранилища, при создании или при обновлении пула хранилища с последовательным доступом установите признак совместного размещения (collocation). Используя совместное размещение, вы сократите количество операций монтирования томов, необходимых, чтобы восстановить или извлечь множество файлов из пула хранилища. Следовательно, совместное размещение снижает время доступа при таких операциях (см. рис. 11-8).
По вашему выбору сервер IBM Tivoli Storage Manager может производить совместное размещение на уровне клиента или файлового пространства. Чтобы задать совместное размещение на уровне файлового пространства, установите признак collocate для файлового пространства. Если он установлен, сервер попытается расположить данные одного узла и одного файлового пространства в пределах одного тома. Если узел имеет множество пространств файлов, то сервер попытается поместить данные каждого файлового пространства на свой последовательный том в пределах пула хранилища.
Если совместное размещение отключено, сервер будет пытаться использовать все доступное место на каждом томе, прежде чем выберет новый. Хотя такое поведение и обеспечивает лучший коэффициент использования отдельных томов, файлы одного пользователя могут оказаться разбросанными по многим томам, а значит, полное восстановление клиента может потребовать монтировать каждый из них.
Рис. 11-8 Совместное размещение в пуле хранилища на уровне клиентских узлов
Совместное размещение означает и то, что IBM Tivoli Storage Manager попытается использовать, как минимум, один ленточный том в расчете на каждого из клиентов. Если в вашем распоряжении лишь ограниченное время на резервирование, то при совместном размещении данных придется больше монтировать накопители, что может быть нежелательно. Если сначала вы снимете резервную копию в дисковый пул, а затем перенесете ее в пул с последовательным доступом, то совместное размещение с этим прекрасно справится из-за особенностей работы миграции на уровне отдельных клиентов. Совместное размещение требует больше томов и емкости для сохранения дополнительных томов в автоматизированной библиотеке.
Впрочем, время восстановления обычно очень критично, и совместное размещение может помочь значительно его сэкономить. Также оно поможет избежать ситуации, в которой два клиента пытаются восстановить файл, находящийся в одном ленточном томе.
Использование совместного размещения в пулах хранилищ копий требует нескольких замечаний. Обычно результат совместного размещения - один частично заполненный последовательный том для каждого из клиентов. Это может быть допустимым для первичных пулов хранилища, поскольку такие частично заполненные тома остаются доступными и могут быть заполнены в ходе очередного процесса миграции. Однако для пулов хранилищ копий подобное может быть неприемлемым, т. к. резервные копии пулов обычно создаются в расчете на немедленную отправку за пределы площадки восстановления. Если в пулах хранилища копий вы используете совместное размещение, то должны решить, действительно ли издержки на доставку в удаленное место хранения менее заполненных томов и увеличение объема работ по восстановлению накопителей окупятся возможностью быстро восстановить при аварии самые значимые узлы
Кеширование дисков применяется только для дисковых пулов хранилища. При включенном кешировании процесс миграции оставляет копии-дубликаты файлов на диске после того, как сервер перенесет файлы в подчиненные пулы хранения в иерархии. Копии остаются в дисковом пуле хранилища, но в статусе «кешировано», что позволяет быстро ответить на последующие запросы на извлечение. Однако если это пространство потребуется для сохранения новых данных на дисках пула хранилища, место, занятое кешированным файлом, может быть сразу повторно использовано под новые данные. Если требуется пространство, сервер высвобождает накопитель, записывая поверх кешированных файлов. Первыми затираются файлы, имеющие самую раннюю дату извлечения и занимающие наибольший объем пространства на диске.
При использовании кеширования коэффициент занятости пространства, который сервер сравнивает с порогом миграции, не включает в себя место, отведенное кешированным копиям файлов. В то же время коэффициент загрузки пула хранилища, напротив, включает в себя пространство под любыми кеш-копиями файлов в составе пула. Если вы переводите пул хранилища данных из состояния cache=yes в состояние cache=no, то ни один кешированный файл не исчезнет немедленно. Коэффициент занятости пространства останется на прежней отметке. Пространство кеш-области будет со временем высвобождаться, по мере того как серверу будет требоваться все новое место; при этом дополнительных кешированных файлов создаваться не будет.
Не применяйте кеширование, если объем места для базы данных у вас ограничен. Если вы пользуетесь кешированием, вам требуется больше пространства, поскольку сервер должен отслеживать и кеш-копию файла, и новую копию в подчиненном пуле хранилища.
Как было сказано выше, совместное размещение поддерживает слитность клиентских файлов, возможно, даже на одном томе, что может увеличить производительность процедуры восстановления. В крупномасштабной среде совместное размещение обычно требует очень большого количества лент, а потому неэкономно в использовании. Больше того, в процессе миграции и высвобождения накопителей требуется множество операций монтирования лент. Но даже в подобных средах совместное размещение может быть крайне полезным для сокращения времени восстановления данных. IBM Tivoli Storage Manager позволяет переносить данные на уровень пространств файлов клиента при помощи команды MOVE NODEDATA. Она дает возможность по требованию совместно разместить данные лишь определенных узлов, чтобы очередное восстановление завершилось быстрее.
С использованием той же команды IBM Tivoli Storage Manager реализует перенос данных между одним пулом хранилища и другим. При этом в отличие от миграции возможен перенос не только пула хранилища в целом, но и конкретных данных клиента. Это открывает возможность переносить данные в пул хранилища с быстрым и параллельным доступом, такой, как пул на дисковых накопителях. В результате, используя мультисессионный режим, свои данные сможет быстрее восстановить целый ряд станций-клиентов.
Технологии дисковых систем хранения продолжают развиваться, наращивая емкость, скорость, надежность, возможности совместного доступа и коэффициент готовности аппаратуры. Во многих организациях используются корпоративные серверы хранения данных с непосредственным подключением к ним через локальную сеть или через SAN. IBM Tivoli Storage Manager использует достижения дисковых технологий, чтобы обеспечить более надежную защиту для себя и данных клиентов. Ведь диски используются IBM Tivoli Storage Manager для размещения собственной базы данных, журнала восстановления и пулов хранения с произвольным доступом.
Защита данных, хранящихся на диске, - это тема отдельного разговора, и ниже мы лишь затронем ряд тех возможностей, с которыми вы, может быть, захотите познакомиться ближе. Решение, которое для вас может стать лучшим, будет определяться множеством факторов:
- доступные вам серверные решения и аппаратные RAID-решения;
- тип операционной системы и доступные программные RAID-решения;
- цена, производительность и уровень избыточности решения.
Аппаратное RAID-решение может быть выгодно тем, что вам удастся избежать падения производительности сервера при реализации RAID. Также в аппаратном решении могут быть предусмотрены диски и контроллеры, допускающие замену «на лету» при сбое (также известную как «горячая» замена(hot-swapping), или «горячее» подключение (hot-plugging)). Другие преимущества - подключение по двум путям, избыточное электропитание и «горячее» резервирование(hot spare). Также вы можете подумать о реализации управляемого серверного хранилища, которое совместно использует ряд серверов с динамическим выделением разделяемого пространства хранения.
Программное RAID-решение способно предложить возможности избыточного хранения с гораздо меньшими - при аккуратной реализации - начальными издержками, используя для этого набор физических дисков.
Помимо этого, есть много различных способов передать данные на физический диск, таких как технологии SCSI, SSA и оптоволоконный канал, - каждый со своими достоинствами и недостатками.
- RAID 1 - зеркальные копии;
- RAID 1 + 0 - зеркальные копии с чередованием;
- RAID 5 - распределенная четность.
RAID 1, или зеркалирование, использует два физических диска и записывает одни и те же данные на каждый из них. Если один из дисков даст сбой, второй будет его точной копией, и данные не потеряются (рис. 11-9.)
Рис. 11-9 RAID 1 (зеркалирование). Доступный пользователю объем диска = 1/2 общего дискового пространства
Это значит, используемый объем равен половине суммарной емкости дисков. Если у вас есть два зеркальных привода по 4 Гб, логическое устройство будет иметь емкость именно 4 Гб. Есть и потери в производительности, поскольку каждая запись на диск теперь влечет две операции записи. Однако при считывании диска можно получить выигрыш, поскольку запрошенные данные можно получить с любого из дисков, который ответит на запрос первым.
При сбое диска потерь в производительности практически нет, за исключением периода восстановления накопителя. Оно может выполняться автоматически (если доступна аппаратура «горячей» замены) или требовать установки нового диска и ресинхронизации зеркальных копий.
Заметим, что IBM Tivoli Storage Manager имеет собственную программную функцию зеркального копирования, созданную специально для томов базы данных и журнала восстановления. Каждый том может быть зеркалирован вплоть до трех раз. Если вам требуется повышенная степень доступности базы данных и журнала восстановления, рекомендуем вам использовать эту встроенную функцию создания зеркальных копий, а не возможности аппаратуры или операционной системы.
Технология RAID 1 + 0, или зеркалирование с чередованием, является новой фазой развития зеркального копирования, данные размещаются с чередованием на множестве зеркальных устройств (рис. 11-10). RAID 1 + 0 требует четного количества физических дисков (как минимум, четырех; максимум обычно зависит от имеющейся аппаратуры). Все диски изначально отзеркалированы, поэтому если один из дисков в паре даст сбой, данные при этом не пострадают. RAID 1 + 0 способен выдержать сбой одного диска в каждой из пар. Однако если в какой-либо паре из строя выйдет каждый из дисков, данные будут потеряны.
Рис. 11-10 RAID 1 + 0 (зеркалирование с чередованием)
Запись на такие пары зеркальных дисков выполняет контроллер, который одновременно записывает блоки, или «порции» данных. Например при шести физических дисках есть три зеркальных набора. Контроллер записывает одну порцию данных на первую зеркальную пару, затем другую - на вторую зеркальную пару, затем -на третью; четвертую порцию данных он снова пишет на первую зеркальную пару (рис. 11-10).
Подобный способ записи данных на диски именуют чередованием, и он имеет преимущества в плане производительности. Физические диски имеют небольшой объем памяти, именуемой кешем, где они могут сохранить данные быстрее, чем более медленный процесс реальной записи на дисковую пластину. Чередование использует эту особенность; записывая порции данных то на один, то на другой диск, чередование гарантирует, что первый диск имеет достаточно времени на завершение цикла записи и очистку своего кеша. Затем четвертую порцию данных можно снова напрямую занести в дисковый кеш без ожидания окончания цикла записи диска.
Ваш логический диск или пригодное к использованию пространство составит половину совокупной дисковой емкости, однако производительность такого решения, возможно, окажется выше, чем в случае RAID 1 или RAID 5.
RAID 5, или распределенная четность, требует трех или более физических дисков, объединенных в набор томов с чередованием (stripeset) (рис. 11-11).
Рис. 11-11 Слой RAID 5 и демонстрация распределения четности
Такой набор отличен от набора в RAID 1 + 0, поскольку на один диск заносится контроль четности, а данные заносятся на все остальные.
Четность - это тот признак, который RAID 5 использует, чтобы восстановить данные, если один из дисков даст сбой. В простейшем виде RAID складывает значения, записанные на каждый из дисков данных, и замечает, был результат четным или нечетным числом; этот признак и помещается на диск четности. Если один из дисков данных даст сбой, RAID 5 сможет определить, какие данные должны быть на поврежденном носителе. Подробности приведены в табл. 11-1.
Табл. 11-1 Восстановление поврежденного диска данных по диску четностиСлойДиск данных 1Диск данных 2Диск данных 3Результат сложенияДиск четностиДля сохранения четностиДиск 2 должен содержать11012ЧЕТ1 + ? + 1 = ЧЕТ021102ЧЕТ1 + ? + 0 = ЧЕТ131113НЕЧЕТ1 + ? + 1 = НЕЧЕТ1Сбой дискаДанные после сбояРасчет по диску контроля четности
RAID 5 распределяет признак контроля четности по разным дискам в каждом из слоев так, чтобы при каждом обновлении четности запись не велась постоянно на один диск. Это способно повысить производительность технологии в сравнении с RAID уровня 3 или 4.
Чередование данных дает выигрыш в производительности из-за наличия у физического диска кеш-памяти, о чем шла речь в разделе о RAID 1 + 0. Впрочем, сама производительность уступает производительности RAID 1 + 0 ввиду издержек, связанных с вычислением четности. Решение на аппаратной основе способно освободить от них сервер, возложив расчет четности на контроллер. Это особенно важно в случае, если диск выйдет из строя или поврежденный диск будет заменен, и набор RAID 5 придется восстанавливать заново. Для повышения производительности в большинство дисковых подсистем масштаба организации входит независимая кеш-память большой емкости.
Полезное пространство в массиве RAID можно найти вычитанием из совокупного дискового пространства емкости одного физического диска. На рис. 11-11 показаны 3 диска по 4 Гб общей емкостью 12 Гб; вычтя из нее емкость одного диска, получим доступное нам пространство размером 8 Гб. Если бы в нашем распоряжении было 8 дисков по 4 Гб общей емкостью 32 Гб, то, определяя пригодное к использованию пространство, мы следовали бы тому же самому правилу. Вычтя емкость одного диска (4 Гб), получим доступное пространство размером 28 Гб. Это и объясняет широкое использование RAID 5; данная технология способна быть более эффективной экономически, чем другие решения.
В этом разделе мы обсудим основы сетей хранения данных (SAN) и их использование в рамках внедрения IBM Tivoli Storage Manager.
Сети хранения данных(SAN) являются новой архитектурой, выносящей хранение данных в особую сеть передачи и позволяющей компаниям любого размера получать доступ к важнейшим данным независимо от операционных систем, что является значительным шагом на пути решения стоящей перед ними проблемы взрывного роста объема информационных потоков в эпоху электронного бизнеса.
SAN - особая сеть, которая служит для организации движения данных и доступа к ним. Сеть подобного рода резко отличается от обычной, которая помимо доступа к данным (услуги файловых серверов) используется для таких видов коммуникации, как электронная почта, терминальные подключения и связь приложений.
Значение сети хранения данных - изолировать функции совместного доступа к данным от других функций для получения выигрыша в производительности, при этом допуская коллективное использование хранилища и обеспечивая достаточно большие расстояния между элементами сети, аналогичным локальным сетям, в которых организован общий файловый доступ.
Топология SAN допускает подключения «каждого к каждому» и консолидацию серверов и систем хранения в сетевом окружении. SAN позволяет избежать непосредственного владения сервером ресурсом хранения.
Архитектурные решения SAN облегчают консолидацию, кластеризацию, поддержку высокой доступности, отказоустойчивости, удаленное управление и гибкие топологии и могут помочь в устранении ограничений масштабируемости и пропускной способности, присущих существующим средам.
Архитектурой, на базе которой будет развернуто большинство сетей хранения данных, представители отрасли считают сети Fibre Channel.
Fibre Channel - технологический стандарт, позволяющий передавать данные от одного узла в составе сети другому с очень высокими скоростями. Существующие решения передают данные со скоростью 100 Мб/с; каналы на 200 и 400 Мб/с уже прошли испытания. Этот стандарт поддерживает консорциум компаний-производителей, его признал Национальный институт стандартизации США (ANSI). На рынке уже имеется немало продуктов, использующих такие преимущества Fibre Channel, как высокая скорость и высокая степень доступности.
Архитектуру Fibre Channel часто называют «волоконной версией» SCSI. Fibre Channel служит для передачи IPI-, IP-, FICON™-, SCSI-трафика, а также, возможно, трафика иных протоколов, каждый из которых находится на одном уровне стандартного FC-транспорта. FICON, как ожидается, станет стандартным протоколом системы S/390, а FCP - стандартным протоколом для остальных систем, при этом для передачи трафика оба будут использовать Fibre Channel.
В составе IBM Tivoli Storage Manager имеется ряд важных решений в области SAN, в которых сети хранения данных уже активно используются. Немало других решений находится в стадии разработки, они будут представлены по мере развития технологии. Роль каждого из них - удовлетворение потребности в эффективной и надежной защите данных.
- Разделяемые ленточные библиотеки.
Функция Tape Resource Sharing в составе IBM Tivoli Storage Manager позволяет администратору сформировать пул ресурсов на лентах, который может совместно использоваться множеством серверов Storage Manager, работающих на гетерогенных платформах. Разделяемые ленточные ресурсы способны повысить производительность резервного копирования и восстановления данных и коэффициент загрузки аппаратуры обслуживания ленточных накопителей. Эта функция описана в разделе 14.6 «Общий доступ к библиотекам на магнитной ленте».
- LAN-free передача данных клиента.
По указанию сервера TSM пулы хранилищ на лентах динамически подключаются к клиентам IBM Tivoli Storage Manager. Это позволяет напрямую пересылать резервную информацию по SAN с клиента в пулы серверного хранилища. Тем самым, маршрут движения данных полностью исключает локальную сеть и сервер IBM Tivoli Storage Manager. Полоса пропускания IP-трафика используется гораздо меньше, а уровень обслуживания конечных пользователей возрастает. Этот метод описан в разделе 5.3 «Топология (LAN-free) SAN-резервирования».
Данный раздел будет посвящен преимуществам, которые в процессе внедрения IBM Tivoli Storage Manager может дать применение ленточных библиотек, подключенных к сети хранения данных, а возможно, и дискового хранилища. Эти преимущества можно объединить в три основных группы
- Доступность;
- производительность;
- эффективность.
Говоря о готовности, или доступности, IBM Tivoli Storage Manager, мы должны осветить работу всех его компонентов. Сервер продукта включает в себя три главные составляющие:
- сервер IBM Tivoli Storage Manager как таковой со своей базой данных и томами в пулах хранилища;
- ленточные хранилища и структуру сети хранения данных;
- доступность системы, объединяющую все функции, связанные с защитой серверной операционной системы и прикладных программ.
Каждое из решений, которое мы обсудим в следующих разделах, относится к одной из перечисленных составляющих.
Одна из самых важных проблем при развертывании решения IBM Tivoli Storage Manager - это защита сервера. База данных и тома пулов хранилища на сервере должны быть защищены от повреждения и утраты. Для этого и база данных, и пулы хранилища периодически резервируются на ленточные тома, которые затем передаются в альтернативное место хранения. Подобный вывоз томов и требуемый время от времени их возврат могут привести к росту уровня сложности и стоимости внедрения IBM Tivoli Storage Manager.
Используя возможности одномодовых или длинноволновых оптоволоконных соединений, вы можете разместить ленточную библиотеку с подключением к SAN за пределами площадки восстановления и при этом не потерять ее соединение с сервером IBM Tivoli Storage Manager. Другими словами, реальное, физическое изъятие томов на удаленное хранение больше не требуется, что сокращает стоимость и сложность решения. Еще одно преимущество этого состоит в том, что в случае если первичный том окажется недоступен, тома в пуле копий будут доступны незамедлительно.
Возможная схема такого решения продемонстрирована на рис. 11-12.
Рис. 11-12 Ленточная библиотека с удаленным подключением к ней
Хранилища с локальным подключением - и ленточные, и дисковые - служат первичным хранилищем сервера. Резервные копии базы данных и пулов перенаправляются в библиотеку, подключенную к SAN. Пользуясь коммутатором или концентратором, каждый из которых оборудован одномодовым оптическим трансмиттером GBIC, можно достичь расстояния, равного 10 километрам. Это значит, что подключенная к сети хранения данных библиотека может располагаться в другом здании или ином безопасном месте.
Структуру сети хранения данных (SAN fabric) часто описывают как решение с высоким коэффициентом доступности. В основе этого утверждения лежит тот факт, что при создании коммутируемой структуры с большим количеством избыточных маршрутов движения со сбоем одного коммутатора справятся остальные, аналогичные коммутаторы.
Такая meshed-топология представлена на рис. 11-13. В этой конфигурации при повреждении линии или аварии на коммутаторе найдутся другие связи, а работу поврежденного коммутатора смогут взять на себя другие устройства. Больше того, такое восстановление будет выполнено автоматически.
Рис. 11-13 Meshed-топология коммутаторов
Следствием применения meshed-топологии и наличия множественных маршрутов, ведущих к каждому из подключенных устройств, является дублирование описаний устройств на подключенной системе. Просматривая свое окружение, операционная система, с некоторой вероятностью, найдет многочисленные устройства, которые на деле являются одним и тем же устройством, хотя и доступным в SAN по разным маршрутам. По этой причине операционная система или производитель подключаемого устройства хранения должны поддерживать функцию альтернативных путей доступа так, чтобы первая опознавала только одно виртуальное устройство, объединяющее различные ведущие к связанному устройству пути доступа.
Среди основных преимуществ и целей внедрения сети хранения данных - выигрыш в производительности, достигаемый в сравнении с решениями на базе традиционных сетей. Причинами такого роста производительности являются повышенная пропускная способность структуры SAN и ограниченный доступ к каналам (меньше пользователей, чем в обычной сети). Идея заключается в том, что данные передаются исключительно по SAN, в то время как локальная сеть служит только для передачи метаданных или управляющей информации между клиентом и сервером. В настоящее время в наборе продуктов Tivoli Storage Management имеются две реализации этой идеи. Это решения для LAN-free работы (описано в разделе 5.3 «Топология (LAN-free) SAN-резервирования») и serverless или server-free (описана в разделе 5.4 «Server-free резервирование»).
Организуя совместный доступ к библиотекам нескольких серверов IBM Tivoli Storage Manager, мы ясно видим, что добиваемся более высокой загрузки ленточных приводов по сравнению с ситуацией, в которой каждый сервер имеет собственную б
