¿Cómo puede ser esto?
Ejecutar cp o rsync (con -W --inplace) tarda dos horas para 93 Gb; una restauración en cinta a través de la red de respaldo dedicada dura 41 minutos. La restauración de cinta es de 50 Mb/s; La velocidad de disco a disco se midió y se calculó en 16 Mb/s como máximo - 2 Mb/s si la CPU está ocupada.
El software de restauración es Veritas NetBackup; los discos están en una matriz EMC Symmetrix a través de fibra. La caja es una HP rx6600 (Itanium) con 16 Gb con HP-UX 11i v2. Todos los discos están en una tarjeta de fibra, enumerada como:
HP AD194-60001 PCI/PCI-X Fibre Channel 2-port 4Gb FC/2-port 1000B-T Combo Adapter (FC Port 1)
Todos los discos también utilizan Veritas Volume Manager (en lugar de HP LVM).
Actualizar:Se me ocurre que esto esnosimplemente una copia directa de disco a disco; en realidad es uninstantáneaa copia en disco. ¿Leer la instantánea podría ralentizar tanto las cosas? La instantánea es una instantánea de HP VxFS (no un vxsnap); ¿Quizás la interacción entre la instantánea y VxVM esté provocando una degradación de la velocidad?
Actualizar:Al usar fstyp -v, parece que el tamaño del bloque (f_bsize) es 8192; el tamaño de bloque predeterminado de UNIX es 512 (o 8192/16). Al probar con dd, utilicé un tamaño de bloque de 1024k (o 1048576 o 8192*128).
Realmente me pregunto si es el tamaño del bloque. Leí en PerlMonks que el módulo Perl File::Copy es más rápido que cp; Eso es intrigante: me lo pregunto.
Si NetBackup utiliza tar, entonces esnousando cp: eso también podría explicar el aumento de velocidad.
Actualizar:Parece que la lectura desde una instantánea es casi el doble de lenta que la lectura desde el dispositivo real. La ejecución de cp es lenta, al igual que la escritura tar en la línea de comando. Usar tar es un poco mejor (cuando se usa un archivo), pero está limitado a archivos de 8 Gb (el archivo en cuestión tiene aproximadamente 96 Gb). Usar File::Copy de Perl con un volumen que no sea de instantánea parece ser una de las formas más rápidas de hacerlo.
Voy a intentarlo e informaré aquí lo que obtengo.
Respuesta1
Otra pregunta es si está vinculado a IO dentro de la red FC, pídale a los chicos de SAN quedemostrar(los gráficos son buenos)actualancho de banda adicional disponible (ah, y si los conmutadores FC son los de Cisco, cómo se aseguran de evitar los problemas de ancho de banda dentro del conmutador)
Respuesta2
¿Está limitado a leer y escribir en el mismo disco de la matriz?
Respuesta3
Si su cinta también está en la SAN, entonces es posible que el xfer se transfiera y vaya directamente de la cinta al disco, mientras que se requiere pasar una copia a través del host que realiza la copia y, por lo tanto, es más lento.
Respuesta4
Si los discos están conectados a diferentes buses en su placa base, los datos pueden copiarse en 3 o más buses internos y la latencia está eliminando su IO para la copia de disco a disco. En este caso, es muy posible que la unidad de cinta de red tenga inherentemente una ruta de ancho de banda mayor hacia el disco de destino que el disco de origen.