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

Question

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

Окружающая среда

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

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

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

Answer 1

Theмбаффернебольшой и удобный инструмент, который может помочь вам 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% начните отправлять данные на ленточный накопитель

мбафферпояснённые параметры:

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

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

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

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

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

Answer 2

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

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

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