Estoy buscando comenzar un régimen de copia de seguridad en cinta y estoy buscando mantener el flujo de datos a la unidad de cinta de manera suficiente (objetivo sostenido de más de 120 MB), pero no puedo encontrar la manera de hacerlo sin una unidad/matriz de origen dedicada que esté inactiva cuando no cintas de escritura. La documentación de nuestra unidad específica no menciona que no se requiere un rendimiento mínimo.
Medio ambiente
- Linux Debian escribiendo en cinta usando mt y tar realizando copias de seguridad de archivos RAR con registro de recuperación, cada uno de ~1GB-300GB de tamaño
- Cintas LTO-4 en la unidad de cinta Quantum TC-42BN a través de SAS a través de un cable SFF externo
- El servidor se utiliza únicamente para copias de seguridad de archivos, no para servicios de red ni para servidores de archivos.
- Matrices MD RAID con datos que se leen/escriben de forma intermitente a lo largo del día/noche.
Si el arreglo de origen tiene lecturas/escrituras significativas (de copias de seguridad programadas) durante una escritura en cinta, el rendimiento de la cinta disminuiría drásticamente, aunque sea temporalmente. Entonces, algunas preguntas se centraron en el rendimiento de escritura de la matriz/cinta de origen:
- Supongo que una caída sostenida en el rendimiento por debajo de 10-20 MB/s (o menos) en la fuente durante una escritura en cinta sería un problema.
- ¿Necesito tener una fuente garantizada para que no tenga copias de seguridad programadas? Básicamente, 2 matrices como mínimo; ¿uno para copias de seguridad y otro para archivos y grabación en cintas?
- ¿Existe una QOS para unidades/arreglos que pueda priorizar la escritura en cinta sobre todo lo demás?
- Las unidades de cinta LTO-4 se aceleran, entonces, ¿existe un límite de rendimiento inferior común que se debe mantener para LTO-4 o varía mucho según la unidad? Nuevamente, la documentación menciona la velocidad máxima diseñada y las "transferencias de velocidad variable", pero no menciona qué tan variable.
- ¿Me estoy perdiendo algo en esta ecuación fuente-rendimiento o tengo preocupaciones infundadas?
Actualizar:
Decidí gravar las cosas mínimamente con una única secuencia de E/S a través de un trabajo de archivo de 600 GB que se leía desde la matriz a aproximadamente 30 MB/s sostenidos mientras se escribía un tar en la cinta desde un RAID 6 de 4 unidades con SATA de consumo. La cinta definitivamente se ralentizó al escuchar el disco, pero NO pareció quedarse sin datos ni sin brillo de zapatos. Esto me indica que NO espere que las cosas se mantengan al día durante una copia de seguridad completa programada paranuestra configuración de hardwarepero puede manejar un trabajo de E/S menos agotador mientras escribe en cinta.
Como cabe destacar, las cintas LOT4 deben realizar 56 pasadas de un extremo a otro de manera tan efectiva que escriben en fragmentos de ~14 GB antes de detenerse durante algunos segundos para reducir la velocidad y luego "ir" en la otra dirección. Creo que esto ayudó a mantener la unidad "alimentada" con datos con un rendimiento más bajo como lo he hecho antes.leer por adelantadoyescrituras asincrónicasambientado en elstinit.def.
Otra nota es que una lectura de "dd if=/dev/st0 of=/dev/null" solo produjo un resultado de 107 MB/s. Este, supongo, es el rendimiento máximo efectivo en el mundo real deestela unidad y NO 120 MB/s. La unidad se encuentra actualmente en un HBA PCIe SAS dedicado sin otras tarjetas PCIe instaladas.
Mientras tanto, configuré un RAID0 de 1 TB como búfer Disk2Tape y tuve que agregar otro disco al servidor para que esto fuera factible.
Todavía me encantaría encontrar una manera de hacer algún tipo de QOS para la unidad de cinta y configurar la escritura como prioridad máxima en la cinta para que podamos simplificar nuestras matrices y reducir los costos de hardware parásito., pero mientras tanto, no veo una manera de NO evitar tener un búfer disk2tape dedicado si quiero garantizar escrituras continuas sin importar qué trabajos programados lleguen a la matriz.
Respuesta1
Elamortiguadores una herramienta pequeña y práctica que puede ayudarle maintain sustained data flow to the tape drive. Está disponible en la mayoría de las distribuciones de Linux.
mbuffer: almacena en búfer las operaciones de E/S y muestra la tasa de rendimiento. Tiene múltiples subprocesos, admite conexiones de red y ofrece más opciones que el búfer estándar.
Ejemplo de uso con compresión multiproceso sobre la marcha:
tar cvf - /backupdir | lbzip2 | búfer -m 4G -L -P 80 > /dev/st0
- comience a agregar archivos al archivo tar
- (opcional) comprímalo con lbzip2 para usar todos los núcleos de la CPU
- comenzar a llenar el buffer de memoria
- una vez lleno al 80%, comience a enviar datos a la unidad de cinta
amortiguadorparámetros explicados:
-m 4Tamaño del búfer de memoria de 4 GB. Si es necesario o está disponible, utilice un búfer más grande.-Lbloqueado en la memoria (opcional)-P 80comience a escribir en la cinta después de que se haya llenado el 80% del búfer. No es necesario poner 100, ya que la unidad de cinta tardará algún tiempo en comenzar a escribir y probablemente se llenará al 100% para entonces.
En este ejemplo, una vez que el búfer llena hasta el 80% de su capacidad, comenzará a enviar datos a la cinta y el búfer continuará recibiendo el flujo de archivos.
Si el proceso de archivado es lento y el búfer no ha recibido los datos lo suficientemente rápido como para mantenerse al día con la unidad de cinta, dejará de enviar datos a la unidad de cinta una vez que alcance el 0%. Una vez que el búfer de memoria esté lleno hasta el 80%, comenzará a enviar datos a la unidad de cinta y la grabación continuará a máxima velocidad.
De esta manera, el "lustrado de zapatos" de la cinta se reduce al mínimo y la unidad de cinta siempre obtendrá los datos a la velocidad máxima que requiere para mantener la transmisión.
También puede utilizar mbuffer en dirección inversa para leer datos de respaldo desde una unidad de cinta y almacenar la transmisión en algún medio más lento o enviarla a través de la red.
Respuesta2
Elmanual que he encontradoenumera velocidades variables de 30,5 a 120 MB/s en incrementos de ~7 MB/s.
Además, las unidades LTO utilizan buffers de tamaño razonable para ecualizar el flujo de datos y proporcionar un indicador para el ajuste de la velocidad, por lo que, a menos que la velocidad de lectura varíe mucho o sea muy baja, el retroceso debe ser mínimo.
Con datos en una matriz algo decente y archivos grandes, 120 MB/s ni siquiera deberían ser un gran problema (a menos que el sistema de archivos esté muy fragmentado). Nuestro búfer de cinta utiliza dos unidades (lentas) de 4 TB en RAID 0 que pueden soportar aproximadamente. 270 MB/s pero no escribimos en el búfer mientras se escriben las cintas.