Necessidades de rendimento da fonte de gravação de fita LTO-4

Question

Estou pensando em iniciar um regime de backup em fita e procurando manter o fluxo de dados para a unidade de fita de maneira suficiente (alvo de mais de 120 MBs sustentado), mas não consigo descobrir como fazer isso sem uma unidade/matriz de origem dedicada que fica ociosa quando não escrevendo fitas. A documentação de nossa unidade específica não menciona nenhuma taxa de transferência mínima necessária.

Meio Ambiente

• Linux Debian gravando em fita usando mt e tar fazendo backup de arquivos RAR com registro de recuperação, cada um com tamanho de aproximadamente 1 GB a 300 GB
• Fitas LTO-4 na unidade de fita Quantum TC-42BN via SAS sobre cabo SFF externo
• O servidor é usado apenas para backups de arquivos, sem serviços de rede ou serviço de arquivos.
• Matrizes MD RAID com dados sendo lidos/gravados intermitentemente em surtos durante o dia/noite.

Se a matriz de origem tiver leituras/gravações significativas (de backups agendados) durante uma gravação em fita, o rendimento da fita cairia drasticamente, mesmo que temporariamente. Portanto, algumas questões giram em torno da taxa de transferência de gravação de matriz/fita de origem:

1. Presumo que uma queda sustentada na taxa de transferência abaixo de 10-20 MB/s (ou menos) na fonte durante uma gravação em fita seria um problema.
2. Preciso ter uma fonte garantida para não ter backups agendados? Essencialmente 2 matrizes no mínimo; um para backups e outro para arquivos e gravação em fita?
3. Existe um QOS para unidades/matrizes que possam priorizar a gravação em fita sobre todo o resto?
4. As unidades de fita LTO-4 aceleram, então existe um limite de rendimento inferior comum a ser mantido para LTO-4 ou ele varia amplamente por unidade? Novamente, a documentação menciona a velocidade máxima projetada e "transferências de velocidade variável", mas nenhuma menção de quão variável.
5. Estou faltando alguma coisa nesta equação de rendimento de origem ou tenho preocupações infundadas?

Atualizar:

Decidi tributar minimamente as coisas com um único fluxo de E/S por meio de um trabalho de arquivo de 600 GB lendo do array a cerca de 30 MB/s sustentado enquanto um tar estava sendo gravado na fita de um RAID 6 de 4 unidades com SATA de consumidor. A fita definitivamente desacelerou ao ouvir a unidade, mas NÃO parecia ficar sem dados ou engraxar os sapatos. Isso me diz para NÃO esperar que as coisas continuem durante um backup completo agendado paranossa configuração de hardwaremas ele pode lidar com um trabalho de E/S menos exigente ao gravar em fita.

Observe que as fitas LOT4 devem fazer 56 passagens de ponta a ponta com tanta eficiência que gravam em pedaços de aproximadamente 14 GB antes de parar por alguns segundos para desacelerar e depois "ir" na outra direção. Acho que isso ajudou a manter a unidade "alimentada" com dados com menor rendimento, como fizLeia adianteegravações assíncronasdefinido nostinit.def.

Outra observação é que uma leitura de "dd if=/dev/st0 of=/dev/null" produziu apenas um resultado de 107 MB/s. Este, eu diria, é o rendimento máximo efetivo do mundo real deessea unidade e NÃO 120 MB/s. A unidade está atualmente em um HBA SAS PCIe dedicado sem outras placas PCIe instaladas

Enquanto isso, configurei um RAID0 de 1 TB como buffer Disk2Tape e tive que adicionar outro disco ao servidor para tornar isso viável.

Eu ainda adoraria descobrir como fazer algum tipo de QOS para a unidade de fita e definir a gravação em fita como prioridade máxima para que possamos simplificar nossos arrays e reduzir custos de hardware parasitas, mas, enquanto isso, não estou vendo uma maneira de NÃO ter um buffer disk2tape dedicado se quiser garantir gravações contínuas, independentemente de quais trabalhos agendados atingirem o array.

Answer 1

Oamortecedoré uma ferramenta pequena e prática que pode ajudá-lo maintain sustained data flow to the tape drive. Está disponível na maioria das distribuições Linux.

mbuffer - armazena em buffer as operações de E/S e exibe a taxa de transferência. É multithread, suporta conexões de rede e oferece mais opções do que o buffer padrão.

---

Exemplo de uso com compactação multithread on-the-fly:

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

1. comece a adicionar arquivos ao arquivo tar
2. (opcional) compacte-o com lbzip2 para usar todos os núcleos da CPU
3. comece a preencher o buffer de memória
4. uma vez preenchido em 80%, comece a enviar dados para a unidade de fita

amortecedorparâmetros explicados:

• -m 4 Tamanho do buffer de memória de 4 GB. Se necessário ou disponível, use um buffer maior.
• -L bloqueado na memória (opcional)
• -P 80comece a gravar na fita depois que 80% do buffer estiver preenchido. Não há necessidade de colocar 100, pois levará algum tempo para uma unidade de fita começar a gravar e provavelmente já estará 100% preenchida até então.

Neste exemplo, quando o buffer preencher até 80% da capacidade, ele começará a enviar dados para a fita e o mbuffer continuará a receber o fluxo de arquivo.

Se o processo de arquivamento for lento e o mbuffer não tiver recebido os dados rápido o suficiente para acompanhar a unidade de fita, ele irá parar de enviar dados para a unidade de fita quando atingir 0%. Assim que o buffer de memória estiver cheio até 80%, ele começará a enviar dados para a unidade de fita e a gravação continuará em velocidade máxima.

Dessa forma, o "engraxamento" da fita é reduzido ao mínimo e a unidade de fita sempre obterá os dados na velocidade máxima necessária para sustentar o fluxo.

Você também pode usar o mbuffer na direção reversa para ler dados de backup de uma unidade de fita e armazenar o fluxo em alguma mídia mais lenta ou enviá-lo pela rede.

Answer 2

Omanual que encontreilista velocidades variáveis ​​de 30,5 a 120 MB/s em incrementos de aproximadamente 7 MB/s.

Além disso, as unidades LTO usam buffers de tamanho razoável para equalizar o fluxo de dados e fornecer um indicador para ajuste de velocidade; portanto, a menos que a velocidade de leitura varie muito ou seja muito baixa, o retrocesso deve ser mínimo.

Com dados em um array decente e arquivos grandes, 120 MB/s não deve ser um grande problema (a menos que o sistema de arquivos seja altamente fragmentado). Nosso buffer de fita usa duas unidades (lentas) de 4 TB em RAID 0 que podem sustentar aprox. 270 MB/s, mas não gravamos no buffer enquanto as fitas são gravadas.