Требуется пропускная способность источника записи на ленту LTO-4

Я пытаюсь начать режим резервного копирования на ленту и пытаюсь обеспечить достаточную передачу данных на ленточный накопитель (целевая нагрузка 120+ МБ), но не могу понять, как это сделать без выделенного исходного накопителя / массива, который бездействует, когда нет. написание лент. В документации для нашего конкретного привода не указывается минимальная пропускная способность.

Enviroment

  • Linux Debian записывает на ленту с использованием mt & tar резервное копирование архивов RAR с записью восстановления, каждый размером ~1ГБ-300ГБ
  • Ленты LTO-4 на ленточном накопителе Quantum TC-42BN через SAS по внешнему кабелю SFF
  • Сервер используется только для резервного копирования файлов, без сетевых служб и файловых серверов.
  • Массивы RAID RAID с прерывистым чтением / записью данных в течение дня / ночи.

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

  1. Я предполагаю, что устойчивое падение пропускной способности до уровня ниже 10-20 МБ / с (или меньше) для источника во время записи на ленту будет проблемой?
  2. Нужно ли иметь источник, гарантирующий, что на него не запланировано никаких резервных копий? По сути, минимум 2 массива; один для резервных копий и один для архивов и записи на ленту?
  3. Существует ли QOS для накопителей / массивов, которые могли бы установить приоритет записи на ленту над всеми остальными?
  4. Ленточные накопители LTO-4 работают дроссельной заслонкой, поэтому существует ли общий нижний предел пропускной способности, который необходимо поддерживать для LTO-4, или он сильно различается для каждого накопителя? Опять же, в документации упоминается максимальная расчетная скорость и "передача с переменной скоростью", но не упоминается, как переменная.
  5. Я что-то упустил в этом уравнении пропускной способности источника или у вас есть необоснованные опасения?

Обновить:

Я решил минимизировать нагрузку на один поток ввода-вывода через 600 ГБ, считывая из массива данные со скоростью примерно 30 МБ / с, пока на ленту записывался tar с 4-дискового RAID 6 с пользовательским SATA. Слушая диск, лента определенно замедлилась до ползучести, но, похоже, на ней не осталось данных или блеска обуви. Это говорит мне, что я НЕ ДОЛЖЕН ожидать, что все сохранится во время полного запланированного резервного копирования для нашей конфигурации оборудования, но это может справиться с менее обременительными операциями записи операций ввода-вывода на ленту.

Как уже отмечалось, ленты LOT4 должны выполнять 56 сквозных проходов настолько эффективно, что они записывают куски по ~14 ГБ, а затем останавливаются на несколько секунд для замедления и затем "идут" в другом направлении. Я думаю, что это помогло поддерживать накопитель "загруженным" данными с более низкой пропускной способностью, так как я читал вперед и асинхронные записи установлены в stinit.def.

Другое примечание - чтение "dd if=/dev/st0 of=/dev/null" дало результат только 107 МБ / с. Это, я бы предположил, реальная максимальная эффективная пропускная способность этого привода, а НЕ 120 МБ / с. В данный момент диск находится на выделенном SAS PCIe HBA, на котором не установлено никаких других карт PCIe.

Тем временем я установил 1 ТБ RAID0 в качестве буфера Disk2Tape и должен был добавить еще один диск на сервер, чтобы сделать это возможным.

Я все еще хотел бы отыскать что-то вроде QOS для накопителя на магнитной ленте и установить приоритет записи на ленту, чтобы мы могли упростить наши массивы и сократить паразитные затраты на аппаратное обеспечение, но пока я не вижу способа НЕ обходите стороной выделенный буфер disk2tape, если я хочу обеспечить непрерывную запись независимо от того, какие запланированные задания попадают в массив.

Источник

2 ответа

Mbuffer - это небольшой и удобный инструмент, который может помочь вам maintain sustained data flow to the tape drive, Это доступно в большинстве дистрибутивов Linux.

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

Пример использования с многопоточным сжатием на лету:

tar cvf - / backupdir | lbzip2 | mbuffer -m 4G -L -P 80> / dev / st0

  1. начать добавление файлов в архив tar
  2. (необязательно) сожмите его с помощью lbzip2, чтобы использовать все ядра процессора
  3. начать заполнение буфера памяти
  4. заполнив до 80%, начните отправку данных на стример

Параметрыmbuffer объяснили:

  • -m 4 Размер буфера памяти 4 ГБ. Если необходимо или доступно, используйте больший буфер.
  • -L заблокирован в памяти (необязательно)
  • -P 80 начать запись на ленту после заполнения 80% буфера. Нет необходимости ставить 100, поскольку для начала записи на лентопротяжное устройство потребуется некоторое время, и к тому времени оно, вероятно, заполнится до 100%.

В этом примере, как только буфер заполнит до 80% емкости, он начнет отправлять данные на ленту, и mbuffer продолжит получать поток архива.

Если процесс архивирования идет медленно и mbuffer не получил данные достаточно быстро, чтобы не отставать от ленточного накопителя, он прекратит отправку данных на ленточный накопитель, как только он достигнет 0%. Как только буфер памяти заполнится до 80%, он начнет отправлять данные на накопитель на магнитной ленте, и запись будет продолжена на полной скорости.

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

Вы также можете использовать mbuffer в обратном направлении для чтения резервных копий с ленточного накопителя и сохранения потока на более медленном носителе или отправки его по сети.

Источник

В руководстве, которое я нашел, перечислены переменные скорости от 30,5 до 120 МБ / с с шагом ~7 МБ / с.

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

С данными в довольно приличном массиве и большими файлами 120 МБ / с даже не должны быть большой проблемой (если файловая система не сильно фрагментирована). Наш ленточный буфер использует два (медленных) накопителя емкостью 4 ТБ в RAID 0, которые могут поддерживать примерно 270 МБ / с, но мы не записываем в буфер во время записи лент.

Источник
Другие вопросы по тегам