Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Problemas de restore con multiples drives direccionados a Storage SUN STK 6180

Created: 30 Jul 2013

Problemas de performance (restore)  QA.

Antes que nada les hago una breve reseña de la configuracion y de como se trabaja, objetivos y problemas.

Se tienen 2 sites, QA = Chacarita y Produccion = Tucuman

Los dos con Similares caracteristicas en la plataforma, que es la siguiente:

==============================

Site Tucuman:

==============================

------------------------------
Servidor de Backup:

T4-2 con 64 GB de RAM y 2 discos unternos de 600Gb 6 placas Pci-e de Fibra dual Port de 8GB cada una.

SN: 1234BDY***

Hostname: aasrvbkp

Version de SO Solaris 10 8/11 - Setup estandar y Full parches EIS Marzo 2013

Version de Vxvm (Storage Foundation) 6

Version de NBU 7.5

------------------------------

Storage:

Hitachi 9985V (productivo)

6140 FC  - 4GB con Disco de 150GB (solo para testeos)

Los storages estan conectados en Direct Attach al servidor de Backup, el hitachi usa los shadows y el 6140 3 volumenes armados para pruebas.

------------------------------

SAN y Libreria los drives se conectan al servidor a traves de SAN, 2 drives maximo por puerto de placa FC en el server.

2 Switch Brocade 300 de 8GB cada unos con 16 puertos licenciados cada uno

Libreria Oracle STK SL3000

FRS 4.0

6 LTO5 FC IBM y 1 LTO4 FC IBM (este solo para restore de los LTO2 provenientes de la vieja plataforma)

------------------------------

==============================

Site Chacarita:

==============================

------------------------------
Servidor de Backup:

T4-2 con 64 GB de RAM y 2 discos unternos de 600Gb 6 placas Pci-e de Fibra dual Port de 8GB cada una.

SN: 1234BD****

Hostname: qasrvbkp

Version de SO Solaris 10 8/11 - Setup estandar y Full parches EIS NOV 2012

Version de Vxvm (Storage Foundation) 6

Version de NBU 7.5

------------------------------

Storage:

6180 FC  - 8GB con cabeza mas 2 Jbods.

El storage esta conectado en Direct Attach al servidor de Backup

------------------------------

SAN y Libreria los drives se conectan al servidor a traves de SAN 2, drives maximo por puerto de placa FC en el server.

2 Switch Brocade 300 de 8GB cada unos con 16 puertos licenciados cada uno

Libreria Oracle STK SL3000

FRS 4.0

4 LTO5 FC IBM y 1 LTO4 FC IBM (este solo para restore de los LTO2 provenientes de la vieja plataforma)

------------------------------

La operatoria principal en la siguiente:

Se toma backup luego de una sincronizacion de los shadows que se montan en el servidor de backup de manera local y se realiza un full backup lanzado por linea de comando.

El backup se toma del Hitachi (High end de alta velocidad)

Una vez que se tiene el juego de cintas correspondiente se lleva a Chacarita, junto con el catalogo y se realiza el restore tambien por linea de comando del backup de la base de datos de SAP
la misma pesa entre 4.5 y 5 TB.

El objetivo es que el backup sea menor a 4,5 horas y el restore menor a 6 horas.

Se realizo un tunning de la plataforma a nivel NBU y SO para optimizar el rendimeinto del HW.

Se realizo un rediseño de politicas optimizando redistribuendo los datos de los diferentes streams de la Politica Sap-full para minimizar el tiempo y el uso de cantidad de cintas.

Se realizo exitosamente el backup de la base en 2.5 Horas con utilizando 3 drives y 3 cintas en el proceso. Multiplex 3.

Se probaron funcionamientos de Backup y restore de politicas de LAN sin problemas en los equipos chicos.

El restore se probo en QA (antes de la optimizacion de los streams, que tardaba unas 4.5 a 5 horas con 4 drives y cuatro cintas Multiplex 4).

El mismo presento problemas al utilizar varios drives el paralelo en el restore.

Al utilizar 2 o mas cintas el NBU cancelaba el restore con errores de Socket:

Error bpbrm (pid=9959) socket read failed: errno = 62 - Timer expired

Luego de analizar el problema se modificaron los tiempos de espera del NBU para que el restore no falle.

LEER: http://www.symantec.com/business/support/index?page=content&id=TECH71821

Mas:

http://www.symantec.com/business/support/index?page=content&id=TECH168384

http://www.symantec.com/business/support/index?page=content&id=TECH177248

http://www.symantec.com/business/support/index?page=content&id=TECH141299

El resultado fue similar ya que toleraba mas cantidad de datos pero luego el mismo problema.

Es importante en este punto observar que la velocidad de escritura de una unidad se establecia para el restore entorno a los 270 MB/sec en promedio y cuando se utilizaban mas de una unidad esa velocidad bajaba paulatinamente a menos de la mitad por cada drive, provocando que el restore con 2 unidades sea mas lento o falle con el error anterior.

Se logro estabilizar el problema utilizando una sola unidad y logrando realizar el restore en una 4.5 horas (tener en cuenta que esto se probo antes del rediseño de la politica y sus streams).

Luego se probo en chacarita un restore desde 3 unidades (no de la base completa sino solo de partes debido a la capacidad limitada del 6140 en espacio) confirmando tambien un error similar de socket cuando se utilizaban varios drives en paralelo.

Se extrajeron Supports Data, explorers y algunos screen shot de las diferentes situaciones que se fueron presentando para analizarlas

Un dato importante a tener en cuenta es que no se conto nuevamente con disponibilidad sobre el 6180 para realizar las pruebas de restore y solo se pudo usar el 6140.

Incluso tampoco se pudo probar el restore luego del rediseño de la politica y optimizacion de los streams

Un detalle a tener en cuenta es que tambien el 6180 estaba alarmado por baterias cerca a la expiracion cuando se relaizaron las pruebas y se le paso al cliente el procedimiento para resetear el battery age ya que son baterias smart, se chequeo el cache y al parecer estaba OK igualmente.

Se deberia analizar si hay algun problema en el storage, un cuello de botella alli o algo faltante en las plataformas a corregir optimizar ya que la falla fue consistente en ambos sites con diferentes storage pero el mismo error y el mismo sintoma bajada progresiva de la tranferencia y errores por timer/socket a medida que se utilizan mas unidades ya que las pruebas apuntarian alli.

------------------------------

Saludos

Javi

Operating Systems: