UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO

Transcripción

1 UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO Nombre del Proyecto Robustecimiento de Infraestructura de Respaldos Empresa PRODUBAN SERVICIOS INFORMATICOS GENERALES S.L. Memoria Que como parte de los requisitos para obtener el título de Ingeniero en Tecnologías de la Información y Comunicación Presenta Jorge Gabriel González Arias M.C.C. Manuel Uribe Saldaña Asesor de la UTEQ José Luis Velázquez Hernández Asesor de la Empresa Santiago de Querétaro, Qro., a 15 de mayo de 2012

2 RESUMEN El Proyecto de Robustecimiento de la Infraestructura de Respaldos llevado a cabo por el área de Almacenamiento y Respaldos de Produban a la par de IBM de México, fue propuesto para mejorar en tiempo y forma los respaldos de las Bases de Datos y Aplicaciones más críticas de la empresa, ya que anteriormente se estaban teniendo problemas de demasiados respaldos fallidos o a medias que al final no servían para restaurar la información, por motivos como saturamiento de servidores de respaldos (demasiados nodos cliente), falta de recursos de grabación (drives en las librerías de cintas) en horarios pico de tráfico de respaldos (fin de semana, madrugada. Ventana de servicio de la mayoría de servidores productivos), por lo que se decidió agregar más Servidores de Respaldo, más recursos de grabación a las librerías de cinta así como una VTL (fragmentos de disco que simulan como cinta física y que después se migran a cintas de verdad), para poder asegurar la información del cliente en caso de contingencia que es el principal objetivo del área. (Palabras clave: respaldo, información, contingencia) ABSTRACT The draft "Tightening of Backups Infrastructure" held by the area of Storage and Backups Produban with IBM of Mexico, was proposed to improve and timely backups of databases and critical applications company, and previously were having problems too many failed backups or half that in the end did not serve to restore the information, for reasons such as permeate backup server (too many client nodes), recording lack of resources (drives in tape libraries) at peak times traffic backs (weekend morning. window service most productive servers), so we decided to add more backup servers, more resources recording and tape libraries as a VTL (disk fragments that simulate as physical tape and then migrated to tape really), to ensure customer information in case of contingency which is the main target area. II

3 I N D I C E Página Resumen III Abstract III Índice IV I. INTRODUCCION 1 II. ANTECEDENTES 2 III. JUSTIFICACIÓN 5 IV. OBJETIVOS 6 V. ALCANCES 7 VI. FUNDAMENTACIÓN TEÓRICA 8 VII. PLAN DE ACTIVIDADES 11 VIII. RECURSOS MATERIALES Y HUMANOS 11 IX. DESARROLLO DEL PROYECTO 13 X. RESULTADOS OBTENIDOS 62 XI. ANÁLISIS DE RIESGOS 63 XII. CONCLUSIONES 64 XIII. RECOMENDACIONES 64 XIV. REFERENCIAS BIBLIOGRÁFICAS 64 III

4 I. INTRODUCCIÓN Siempre iniciar un proyecto es difícil y laborioso ya que tienes que convencer a los dueños del dinero que lo que pretendes implementar es totalmente necesario para la empresa, por lo que tienes que justificar y convencer de los recursos que vas a utilizar y de qué forma va a retornar la inversión. Como lo vengo diciendo el objetivo del área de Almacenamiento y Respaldos es asegurar la disponibilidad, seguridad e integridad de la información, ya que su valor es demasiado alto, y más tratándose de un banco, por lo que no tener en tiempo y forma ciertos datos, ó las tablas de una base de datos, etc., puede desencadenar la pérdida de cuantiosas cantidades de dinero. Para justificar los recursos a utilizar en el proyecto no es cosa del azar, hay que contestar preguntas como número de servidores productivos de la empresa, número de bases y aplicaciones más críticas, tamaño de la información más crítica, porcentaje de crecimiento de la información anual, infraestructura actual, en fin interrogantes que nos vayan guiando a escatimar los recursos necesarios tanto económico como humano. El proyecto es derivado del esfuerzo de todas las áreas de la empresa ya que cada una aporta cierto grado de especialización necesaria como soporte unix, Oracle, Intel, seguridad informática, almacenamiento y de esta forma cumplir con los tiempos del proyecto, cada participación queda documentada en la herramienta de Proyectos de la empresa. De esta forma damos inicio a un proyecto bastante interesante que involucra a bastantes áreas de la informática y que por lo tanto lo hace llamativo a los compañeros. 1

5 TB II. ANTECEDENTES Se han tenido problemas al intentar restaurar respaldos incompletos lo que repercute a pérdida de información, de dinero para la empresa. Observaciones del ambiente actual Los servidores críticos de bases de datos actualmente son respaldados en VTL a través de la SAN (ver Gráfico 1 y 2). El throughput de ingestión de la VTL EMC es muy limitado, por lo que no se utiliza el potencial de la SAN y los respaldos son muy tardados. Los respaldos semanales deben retenerse en cinta por 5 años. Recomendamos respaldar los servidores de DB conectados a SAN directamente a 6 tape drives en paralelo. Requerimientos de disco en VTL Sin dedup 39 Con dedup IBM Gráfico 1 2

6 Requerimientos de disco en VTL para cumplir con periodos de vigencia de la información TB OS (Windows y UNIX) Windows - files/apps UNIX DB diario UNIX DB semanal UNIX otros - files 33 UNIX Salidas, Auditoria 23 UNIX Web Sin dedup Gráfico 2 Con dedup IBM Se consideraron 80 servidores para ser respaldados vía LAN en el VTL (ver Gráfico 3). 55 servidores UNIX 25 servidores Wintel 32.5 TB de almacenamiento (incluye crecimiento) Se requieren 47 horas para respaldarlos en VTL EMC Se recomienda respaldarlo a VTL con deduplicación a través de LAN 3

7 Horas MB/seg Throughput por solución Actual (VTL EMC) IBM TS7650 (dedup) Grafico 3 Tiempo de respaldos por solución Actual (VTL EMC) IBM TS7650 (dedup) Grafico 4 4

8 III. JUSTIFICACIÓN Los respaldos incrementales diarios residirán en la VTL y allí mismo expirarán de acuerdo a los requerimientos de vigencia expresados por PRODUBAN en el RFP. Con lo anterior, no será necesario enviarlos a cinta logrando reducir hasta en un 40% la cantidad de cintas utilizadas en los procesos. Además, la disponibilidad de tape drives adicionales, permitirán una óptima ejecución de los procesos de reclamation representando un ahorro en cartuchos de cinta de un 30% y una reducción de tiempo de hasta un 25%. Con la nueva funcionalidad Data-Deduplication (DDD) de TSM 6, los respaldos a cinta reducirán significativamente el espacio utilizado, si consideramos 10TB iniciales, con 6 respaldos a la semana, en los primeros 2 meses se logrará un factor de DDD de 10:1, es decir, solo utilizaremos 1TB en cinta. Esto representa un ahorro sustancial en cantidad de cintas. IV.OBJETIVOS Asegurar que los equipos críticos de producción cuenten con un Reducir los tiempos de recuperación total y parcial. 5

9 Horas Tiempo de respaldos por solución Actual (VTL EMC) IBM TS7650 (dedup) Gráfico 5 Reducir el consumo de cintas al menos un 30%. Permitir que el resto de los equipos de Producción, clasificados como no críticos, puedan ser integrados al esquema de respaldo. V. ALCANCES Migración de Servers de TSM 6.1 y 5.5 * Depende de la versión del S.O del cliente para determinar cuáles equipos entrarían en los servers de TSM. Definición de Arquitectura Lan dedicada SAN Drives 3592 VTL 6

10 Pool de Disco Políticas de Backup Periodicidad Ambiente de pruebas Configuración del VTL Discos XIV (Duración de 3 días) Configuración de Drives Configuración de tipos de respaldo (TDP SQL, Oracle, Exchange, Image backup, System State, Journals y las implicaciones que tienen ) Políticas de backup por instancias (Eficientar backup y restore) Reportes Standard Archivo admserv.mib SNMP (Alertamiento) Transferencia de conocimientos Tuning (3 semanas) Mejores prácticas (basado en el tipo de archivos) Consolidación de instancias definidas en la Arquitectura ( 3 semanas) Pruebas integrales de ambiente TSM ( 2 semanas) VI. JUSTIFICACIÓN TEÓRICA Se consideró: 60 servidores UNIX (BD Oracle) 25 servidores WINTEL 42.7 TB de capacidad usada + 30% 7

11 Volumen de respaldo por tipo de dato (TB) WIN OS (C drive) WIN No OS UNIX directorios de w eb UNIX directorios w eb auditoria UNIX archivos de salida y logs UNIX OS UNIX otros DB respaldo diario LAN DB respaldo semanal LAN DB respaldo semanal SAN Actual 30% Crecimiento Grafico 7 Volumen de respaldo TB por S.O. con 30% de crecimiento UNIX WINDOWS Gráfico 8 Se consideró: 60 servidores UNIX (BD Oracle) 25 servidores WINTEL 42.7 TB de capacidad usada + 30% 8

12 Pool de respaldo por tipo de dato (TB) WIN OS (C drive) 1.38 WIN No OS 6.78 UNIX directorios de w eb UNIX directorios w eb auditoria UNIX archivos de salida y logs UNIX OS UNIX otros 6.98 DB respaldo diario LAN 3.81 DB respaldo semanal LAN DB respaldo semanal SAN Gráfico 9 Pool de respaldo (TB) VTL Tape Gráfico 10 9

13 Ventajas de respaldo a cinta Los backups y restores de bases de datos (grandes archivos) se realiza de manera más rápida con el acceso secuencial de cinta a través de la SAN. Los 12 tape drives que tienen actualmente pueden lograr un throughput más alto que cualquier solución de deduplicación de datos en el mercado. Por política de Santander, los respaldos semanales de bases de datos se deben retener en cinta por 5 años, por lo que no es factible que expiren en la VTL. Las cintas no consumen energía ni generan calor, son transportables, pueden ser encriptadas y proveen la opción WORM. VII. PLAN DE ACTIVIDADES Obtención de Servidor Consolidación de Instancias V5 Recolección de info. HealthCheck Migración de clientes a V5.5 y V6 Diseño de Arquitectura Plan de Trabajo TSM Instalación TSM V6 Direccionamiento De clientes TSM 5,5 y TSM 6 TDP for Oracle Cfg de Monitoreo Asistencia En sitio Reportes Instalación VTL TDP for MS-SQL Documentación De procesos De Respaldos Instalación 6 drives 3592E05 TDP for Exchange Gráfico 11 10

14 VIII. RECURSOS MATERIALES Y HUMANOS Propuesta Económica Licenciamiento de TSM versión 6.1 para los componentes mencionados 6 Drives 3592 TS1120 para la TS x Gateways TS7650 en cluster Software ProtectTIER Enterprise Edition Sistema de Almacenamiento XIV con 43TB utilizables Servicios de Implementación Soporte 36 meses Hardware y Software de la VTL Capacitación Precio US $

15 Gráfico 12 12

16 IX. DESARROLLO DEL PROYECTO Descripción del ambiente Instancias Listado de instancias actuales La tabla siguiente lista las instancias de TSM analizadas para su conversión a la versión 6.1 de TSM Hostname Instancia de TSM Tipos de datos srvpro22 BSMTSM01 Actuales srvpro22 BSMTSM03 Históricos srvpro22 BSMTSM05 Históricos srvpro22 BSMTSM06 Actuales srvpro22 BSMTSM07 Actuales bsmtsm12 BSMTSM02 Históricos bsmtsm12 BSMTSM04 Históricos bsmtsm12 BSMTSM12 Actuales bsmtsm12 BSMTSMNICE Históricos Diagrama Lógico de TSM Este es un diagrama lógico de TSM: 13

17 Configuración Lógica de TSM Bsmtsm01 Bsmtsm03 Bsmtsm05 Bsmtsm06 Bsmtsm07 DB: 190GB al 90% LOG: 8.6GB al 40% Max Nodos: 255 DB: 57 GB al 79% LOG: 1GB al 0.2% Max Nodos: 112 DB: 142GB al 95% LOG: 12.3GB al 0.1% Max Nodos: 6 DB: 21GB al 6% LOG: 3.1 GB al 17% Max Nodos: 120 DB: 205GB al 98% LOG: 11GB al 16% Max Nodos: 215 TSM V5.4.2 Bsmtsm02 Bsmtsm04 Bsmtsm12 BsmtsmNice DB: 32.8GB al 59% LOG: 1GB al 0.2 % Max Nodos: 79 DB: 142GB al 95% LOG: 1GB al 0.2% Max Nodos: 103 DB: 367GB al 93% LOG: 4.5GB al 89% Max Nodos:132 DB: 123GB al 95% LOG: 2GB al 2% Max Nodos: 11 TSM V LIB1 3584LIB2 Centera 3584CDL VTL 3590/3592 Drives 31-LTO3 6 drives 6 drives 3584CDL1 3592E E05 Migración C LibManager LibClient Gráfico 13 Servidores Recursos de HW Estos son los recursos de HW de los servidores de TSM actuales: Equipo srvpro22 bsmtsm12 Amount of RAM 6.25 GB 4.25 GB Number of CPU 2 2 Speed of CPU 2.1 GHz 1.9 GHz AIX level AIX ML 6 3 AIX 64 or 32 bit? Disk space available for TSM DB 14

18 Number of HBAs for Tape 3 1 Speed of HBAs for Tape 2 GB 2GB Number of HBAs for Disk 2 1 Speed of HBAs for Disk 4 GB 4GB Number of NICs for backups 3 2 Speed of NICs for Backups 1 GB 1 GB Nodos Cliente Plataformas actuales Cantidad de Nodos Plataformas de clientes de TSM 1 Plataforma Gráfico 14 ADMIN Count AIX Count C Count CONSAFORE Count DB2/SUN Count DEC UNIX Count DESACONS Count HPUX Count Linux86 Count STORAGE_CENTER Count SUN SOLARIS Count TDP MSExchg Count TDP MSSQL Count TDP MSSQL Win32 Count TDP Oracle SUN Count TDP R3 AIX Count USRADMIN Count WinNT Count Z Count 15

19 Distribución de nodos por instancia Nodos por Instancia Nodos BSMTSM01 Count BSMTSM02 Count BSMTSM03 Count BSMTSM05 Count BSMTSM06 Count BSMTSM07 Count BSMTSM12 Count BSMTSMNICE Count 0 Gráfico 15 16

20 Nodos activos e históricos Ultimos Accesos # Nodos a) < 1 dia Count b) < 5 dias Count c) < 1 mes Count d) < 3 meses Count e) < 6 meses Count f) < 1 año Count g) > 1 año Count Gráfico 16 Volumen de respaldos Estadísticas Estas es una estadística de volumen de respaldos correspondiente a la 1ª mitad del mes de diciembre del 2009 de las instancias y nodos cliente activos de TSM 17

21 APLIBSU02 APLIDESBSU APPPRO02 ATRILPROD AUDIPROD1 BDCALTEC1 BDCSOPROD1 BDCSOPROD2 BIA1 BIA5 BMGAPP01 BMGDEV01 BMGPROD01 BMGWEB01 BMGWEB02 BOFAPROD1 BUZONP03 C CHDPROD1 CHDPROD2 CITRIXBSU2 CITRIXBSU3 CITRIXBSU4 CITRIXBSU5 COLAPP001 COLAPP02 COLWEB001 COLWEB002 COLWEB01 COLWEB02 CONTROL1 CSODES11 CSOPROD01 CSOPROD05 CSOPROD09 DBBSU1 DBUYDESA1 DCBSU1 DCCORP1 DESABSM DSBIA1 DWHPRO01 ESSPRO01 EXCHBSU3 FSHAREPROD1 FSHAREPROD4 FWCOL01 FWCOL02 ICSPRO003 ICSPRO005 ICSPRO01 ICSPRO02 ICSPRO03 ICSPRO04 ICSPRO05 INTRANETBSU1 INTRAWEB01 INTRAWEB02 KMPROD01 MAILPRO1 MISCORPROD1 MXBDPRO02 MXCSODES21 MXCSOPRO24 MXFOAPRO20 MXFORPRO20 MXFSDPRO20 PASSMARK01 PDCGFSS1 PMPLTA PRODCLUSUY RDSPROD01 S_MEX_APP1 SCSERVER SETRIB01 SETRIBPLUS SIPPROD1 SIPPROD2 SNETCOL1 SPBSU SRVCAJE01 SRVCAJE02 SRVCAJE03 SRVPRO07 SRVPRO11 SRVTRAIN02 STSBSU1 SUPERNETDES SWFDBCON SWFDBDEV SWFNTDEV SWFNTPRO UYDBWPRO UYDBWPRO01 UYDBWPRO02 WEBBSU01 WEBBSU02 WEBCSPROD1 WEBLTA02 15-Dic 15-Dic Gráfico 17 LAN Topología actual El administrador de la LAN indica que la topología de la red de Produban es confidencial, sin embargo nos pide utilizar la velocidad el adaptador de red de cada equipo como medida del Ancho de Banda disponible, ya que la infraestructura garantiza esas velocidades. SAN Topología actual Este es el diagrama de conectividad SAN actual 18

22 srvpro22 Backups Schema bsmtsm12 BSMTSM01 BSMTSM03 BSMTSM05 BSMTSM06 BSMTSM07 Lan-Free Clients 3 HBA s 2Gbps 24K1 SAN 4100 Dwhpro02,Scbpro01 1 HBA 2Gbps BSMTSM02 BSMTSM04 BSMTSM12 BSMTSMNice 3590/3592 Drives 2Gbps Srvpro02, Srvpro23 Anaconda1 Anaconda2 VTL 6 drives 3592E05 6 drives 3592E05 Centera bsmtsm05 LAN Access bsmtsm01 bsmtsm01 bsmtsm06 Gráfico 18 Librerías Físicas No de Serie LibraryName en TSM Referida como A LIB1 Anaconda A LIB2 Anaconda2 Distribución de drives Library DriveName en TSM No. de Serie Anaconda1 DRV3592_ Anaconda1 DRV3592_ Anaconda1 DRV3592_ Anaconda1 DRV3592_ Anaconda1 DRV3592_ Anaconda1 DRV3592_ Anaconda2 DRV3592_ Anaconda2 DRV3592_ Anaconda2 DRV3592_

23 Anaconda2 DRV3592_ Anaconda2 DRV3592_ Anaconda2 DRV3592_ Distribución de servidores en librerías Servidor TSM BSMTSM01 BSMTSM05 BSMTSM07 BSMTSM02 BSMTSM03 BSMTSM04 BSMTSM06 BSMTSM12 BSMTSMNICE Librería Anaconda1 Anaconda1 Anaconda1 Anaconda2 Anaconda2 Anaconda2 Anaconda2 Anaconda2 Anaconda2 Nombres de dispositivos por servidor DriveID BSMTS M01 BSMTS M03 BSMTS M05 BSMTS M06 BSMTS M07 BSMTS M02 BSMTS M04 BSMTS M12 DRV3592_01 rmt51 rmt51 rmt51 rmt17 DRV3592_02 rmt53 rmt53 rmt53 rmt18 DRV3592_03 rmt50 rmt50 rmt50 rmt22 DRV3592_04 rmt54 rmt54 rmt54 rmt24 DRV3592_05 rmt55 rmt55 rmt55 rmt26 DRV3592_06 rmt16 rmt16 rmt16 rmt23 DRV3592_07 rmt52 rmt52 rmt52 rmt19 rmt19 rmt19 DRV3592_08 rmt48 rmt48 rmt48 rmt20 rmt20 rmt20 DRV3592_09 rmt49 rmt49 rmt49 rmt21 rmt21 rmt21 DRV3592_10 rmt56 rmt56 rmt56 rmt27 rmt27 rmt27 DRV3592_11 rmt57 rmt57 rmt57 rmt28 rmt28 rmt28 DRV3592_12 rmt58 rmt58 rmt58 rmt25 rmt25 rmt25 VTL Actualmente se tiene la siguiente VTL Marca/Modelo EMC 720 Number of HBAs for Tape 8 Speed of HBAs for Tape 2 GB Type of library being emulated 03584L32 20

24 ULT3580-TD3 y Type of drives being emulated 3592J1A Number of libraries emulated 2 Number of drives emulated 43 Number of slots emulated 120 Is either dedicated to Open or shared with Mainframe Open System Total storage space 32 TB Distribución por instancias Solamente la instancia BSMTSM06 está utilizando ésta VTL Distribución de Drives Library Name 3584CDL 3584CDL 1 Drive Name CDLDRIVE01 CDLDRIVE31 CDL2DRIVE0 1 CDL2DRIVE1 4 Devic e Type LTO Read Formats ULTRIUM3C,ULTR I- UM3,ULTRIUM2C, - ULTRIUM2,ULTRI- UMC,ULTRIUM Write Formats ULTRIUM3C,ULTR I- UM3,ULTRIUM2C, - ULTRIUM C, C,3592 Storage Pools Estos son lo stgpools que residen en la VTL Storage Storage Device Estimated Next Stora- Pool Name Pool Type Class Name Capacity ge Pool CDL2POOL Primary 3592CDL 903,473,5- DISKLIBRARY 40 G CDLORAPOOL Primary LTO3CDL 0.0 M 21

25 CDLPOOL Primary LTO3CDL 98,577,190 DISKLIBRARY G CDLPOOLCOL- Primary LTO3CDLCOL 881,866 G TAPEPOOLCO- OCATE LOCATE Centera Distribución por instancias La instancia BSMTSM05 tiene configurado un dispositivo secuencial tipo WORM Centera, el cual se accesa via TCPIP Storage Pools Estos son los stg poools configurados Storage Storage Device Estimated Pool Name Pool Type Class Name Capacity AFOREPOOL Primary CENTERACL- 52,120 G ASS CENTERAPOOL Primary CENTERACL- 52,120 G ASS CENTERAPOO- Primary CENTERACL- 0.0 M L1 ASS1 Bases de Datos Oracle Inventario Este es el listado de BD Oracle, incluyendo plataformas Unix y Windows, las características de los equipos, espacios utilizados, etc. 22

26 Microsoft Office Excel Worksheet Plataformas y criticidades Unix y Windows Distribución por plataforma/criticidad Criticos Muy Criticos Unix Windows Gráfico 19 23

27 Cantidad de instancias de Oracle Unix críticas y muy críticas Gráfico 20 Cantidad y tipo de versiones de Oracle muy críticas Existen múltiples versiones de Oracle siendo utilizadas, desde hasta

28 Versiones de Oracle 1 Ver. Oracle. Total 125 Gráfico Count Count Count Count Count Count Count Count Count Count Count Count Count Count SinAcceso Count Count Count Count Count Count Count Count Count NoExiste Count Count Count Count Count Count Count Count Cantidad y tipo de versiones de Oracle críticas 25

29 Gráfico 22 Cantidad y tipo de vesiones de Oracle totales Gráfico 23 Equipos prototipo sugeridos por el DBA para ser instalados desabsm y desaqa 26

30 Tipos de Respaldos Online: Ya hay bases en modo archive, sobre todos las criticas Offline: Algnas BD se respaldan offline los fines de semana Exports: Son tipo full-online RMAN Actualmente no se está utilizando RMAN en ninguna BD Estadísticas de BD Tamaño: 10 GB en promedio hasta 12TB Logs: Logs de MB en promedio generados cada 2-5 min aprox Paralelismo Actualmente no se respalda en paralelo, se respalda tablespace por tablespace hacia disco. Cluster Existen algunos sistemas en cluster y estan mayormente en SOlaris y AIX TDP Actualmente no se estan usando TDPs, solo respaldos a disco y luego con cliente BA de TSM Bit Existen BD a 32 y 64-bits Bases de Datos SQL Para bases de datos SQL aplican los mismos lineamientos que para BD Oracle y todos son respaldos a disco y luego hacia TSM con el BA client. Tipos de Respaldos Online: Ya hay bases en modo archive, sobre todos las criticas Offline: Algunas BD se respaldan offline los fines de semana 27

31 Exports: Son tipo full-online Estadísticas de BD Tamaño: 10 GB en promedio Logs: Logs de MB en promedio generados cada 2-5 min aprox Paralelismo Actualmente no se respalda en paralelo, se respalda tablespace por tablespace hacia disco. Cluster Existen algunos sistemas en cluster MSCS TDP Actualmente no se están usando TDPs, solo respaldos a disco y luego con cliente BA de TSM Bit Existen BD a 32 y 64-bits Correo Electrónico Versiones Utilizadas Exchange 2003 con SP 2 Equipos 2 servidores de correo Windows 2003 Server Equipos sugeridos por el Admor. para ser instalados Los mismos dos equipos existentes Tipos de Respaldos Storage Groups Respaldo por Storage Group full online- diario por 2 hrs con logs. Se hacen respaldos a nivel servidor de Exchange, el cual respalda todos los StorageGroups, con todos sus mailboxes, con todas las user databases. PCT 28

32 Correo por persona para usuarios críticos Estadísticas de espacio Tamaño: (Revisar en TSM ya que el Mail Admor. no tiene el dato) Logs: (Revisar en TSM ya que el Mail Admor. no tiene el dato) Paralelismo MS-Exchange permite hacer respaldos de forma paralela por cada Storage Group. Cluster El servidor de actual de Exchange está en cluster (MSCS) TDP Actualmente ya se tiene funcionando TDP for Exchange V Bit Ambos servidores están configurados a 64-bits 29

33 HealthCheck Servidores % Utilización actual de servidores Instancias Parámetros de configuración de TSM a modificar Nodos Cliente LAN SAN Librerías Físicas Estadísticas de Utilización de unidades VTL 30

34 Arquitectura Propuesta Estrategia de Migración a TSM V6 Estrategia de migración de servidores Con base en los elementos analizados en esta Arquitectura, la estrategia de migración recomendada para Produban es la siguiente: Configurar una nueva instancia de TSM V6.1 en un servidor adicional con los recursos de HW definidos en la sección Sizing de servidor de TSM V6.1 Redireccionar hacia esta nueva instancia, todos los nodos actuales que estén en versión de TSM 5.5 o superior, iniciando también la exportación de sus datos contenidos en las instancias actuales. Iniciar la migración hacia versión 5.5 o superior en los servidores críticos con base en la compatibilidad con TSM Server V6.1 Consolidar las 5 instancias históricas en solo dos: BSMTSMNICE -> BSMTSM05 BSMTSM02,BSMTSM03 -> BSMTSM04 Consolidar las instancias actuales (productivas) en solo 3: BSMTSM06 -> BSMTSM01 BSMTSM07 BSMTSM12 Actualizar las instancias actuales hacia versión TSM 5.5 Estrategias de migración de servidores alternativas A continuación se describen dos escenarios alternativos de migración indicando sus pros y contras: Estrategia Ventajas Desventajas - No se requiere un servidor adicional - Migración de instancias en los equipos originales - reubicación de nodos clientes mayores a V5.5 hacia las instancias dedicadas para migración a V6 y menores a 5.5 hacia instancias que 31 - Se requiere aumentar las capacidades de los dos servidores actuales a las recomendadas por el sizing - Se tendrían ventanas sin respaldos de 72 hrs o más - El plan de retorno

35 permaneceran en V5 - migración local de TSM ya sea con el método de media o LAN puede demorarse varias horas (3 hrs para reinstalacion de la version 5.5 y fixpack mas el tiempo que demore restaurar las BD de TSM originales) - Reubicación de todos los TSM servers V5 hacia un solo servidor fisico - Instalar TSM Server V6 en el servidor liberado - Ejecutar migración a nuevo Server con el metodo de LAN y después consolidación de instancias de Server a Server. - No se requiere un servidor adicional - Para agregar HA a los TSM servers se requerirían 2 servidores adicionales - No se realizaría actualización tecnológica a arquitecuras P de mayor rendimiento - La migración hacia versión 6.1 no puede iniciarse hasta que se haya completado la reubicación de todos los nodos clientes - Se requiere aumentar las capacidades de los dos servidores actuales, uno conforme a las recomendadas para el primer Servidor Físico" descrito en el sizing y el restante para la suma de recursos de ambos servidores actuales - Si bien la capacidad en GB del servidor consolidado es la suma de los originales, la afectación en performance es alta debido a la suma de I/O en solo servidor 32

36 - No se realizaría actualización tecnológica a arquitecturas P de mayor rendimiento - La instalación de V6.1 no puede iniciarse sino hasta completar la reubicación de todas las instancias de TSM Server Estrategia de migración de clientes Nodos que actualmente tiene V5.5 Estos nodos son los únicos que, de manera oficialmente soportada, pueden conectarse al servidor TSM V6 propuesto. Una vez instalado el TSM Server V6, estos nodos pueden registrarse en el servidor y, después de reconfigurar su archivo de opciones, pueden iniciar respaldos de manera inmediata en el mismo. La información de respaldos actuales puede mantenerse en la instancia actual V5 y tratarse como histórico, o bien puede exportarse toda la información de éstos nodos hacia las instancias V6. Esta última actividad requiere la lectura/re-escritura de toda la información del nodo, pero permite disminuir la bd de la instancia V5 fuente, además de mejorar su performance. Nodos con TSM V5.4 o menor Estos nodos no pueden conectarse al servidor de TSM V6, por lo que deben migrarse primero al menos a la versión TSM V5.5 (preferentemente a la V6). La secuencia de migración de estos nodos será la siguiente: 33

37 Gg Selección de nodo de cuerdo a su criticidad, factibilidad de modificación, urgencia de mejora, etc La información actual se accesa como histórica Obtención de niveles exactos de OS, Midleware, Apps existentes en el servidor que requieren respaldos en TSM Se inicia export de información Se migrarán datos a TSM V6? Es compatible con TSM y TDP V6 o V5.5? Se genera plan de trabajo para migración Se registran mediciones actuales de respaldos Se migra a TSM V6.1 o 5.5 Se aplican mejoras: Journal Image Lan-free Se modifica dsm.opt para conectarse a TSM V6 Se mantiene en versión actual y se analizan dependencias para su futura migración Gráfico 24 34

38 Estadística de clientes a migrar Clientes a Migrar Total Se mantiene Gráfico 25 Esta es la lista detallada por cada clientes activo de TSM: Microsoft Office Excel Worksheet Nota: Los servidores actuales versión 5.4 pueden aceptar conexiones de clientes versiones 5.4 y 5.5 pero no 6.1. Para clientes que vayan a ser migrados a versión 6.1, es necesario esperar a que la instalación del TSM server v6.1 sea completada o bien que las instancias actuales sean actualizadas a la version 5.5. Con el fin de contar con las versiones de TSM más recientes posibles, recomendamos instalar, siempre que sea posible, la versión

39 Instancias Balanceo de Instancias de TSM V6.1 La nueva versión de TSM prácticamente no tiene límite de tamaño (1 TeraByte máximo), sin embargo es necesario aplicar las mejores prácticas para optimizar el performance. Se recomienda instalar 2 instancias de TSM V6 que den servicio de manera equilibrada a los clientes de TSM V5.5 o mayores. El sizing del servidor propuesto soporta estas dos instancias y permite una administración equilibrada del sistema. La utilización de estas instancias será gradual, conforme los nodos clientes sean migrados a versión 5.5 (o mayor) y puedan ser asignados a las instancias V6 Balanceo de instancias activas V5 Actualmente se tienen 4 instancias de TSM activas. Con el fin de optimizar la administración de las mismas, se propone consolidarlas en solo tres: BSMTSM06 -> BSMTSM01 BSMTSM07 BSMTSM12 La distribución anterior está basada en la carga actual y las mejores prácticas para la administración de la bd de TSM: - son instancias activas con mucha actividad - actualmente Produban no percibe mal performance en estas instancias - tiempos de respaldo adecuados de la BD - tiempos de expiración manejables - tiempos de recuperación manejables en caso de requerir un restore Consideraciones: - Tiempo de consolidación. La consolidación de instancias de TSM se basa en el proceso de export/import de la información de los nodos clientes. Esta actividad implica la lectura de toda la información perteneciente a un nodo, su transmisión a la nueva instancia y la escritura en StgPools de la instancia destino, por lo que es una actividad que puede consumir un tiempo considerable. - Recursos de almacenamiento en la instancia destino. 36

40 Se requiere suficiente espacio en los StgPools de la instancia destino para poder almacenar la información de los nodos conforme se vayan importando. - Performance Se recomienda realizar las consolidaciones instancia por instancia, y solo después de validar que el performance es adecuado continuar con la siguiente. Balanceo de instancias históricas V5 Actualmente se tienen 5 instancias de TSM históricas. Con el fin de optimizar la administración de las mismas, se propone consolidarlas en solo dos: BSMTSMNICE -> BSMTSM05 BSMTSM02,BSMTSM03 -> BSMTSM04 La distribución anterior está basada en la carga actual y las mejores prácticas para la administración de la bd de TSM: - son instancias históricas con poca actividad exclusiva para restores - actualmente Produban no percibe mal performance en las instancias históricas actuales - tiempos de respaldo adecuados de la BD - tiempos de expiración manejables - tiempos de recuperación manejables en caso de requerir un restore Consideraciones: - Tiempo de consolidación. La consolidación de instancias de TSM se basa en el proceso de export/import de la información de los nodos clientes. Esta actividad implica la lectura de toda la información perteneciente a un nodo, su transmisión a la nueva instancia y la escrituta en StgPools de la instancia destino, por lo que es una actividad que puede consumir un tiempo considerable. - Recursos de almacenamiento en la instancia destino Se requiere suficiente espacio en los StgPools de la instancia destino para poder almacenar la información de los nodos conforme se vayan importando. - Performance Se recomienda realizar las consolidaciones instancia por instancia, y solo después de validar que el performance es adecuado continuar con la siguiente. 37

41 TSM Server V5 TSM Server V5 Actualización de instancias actuales a V5.5 Si bien no existe aún una fecha para el término de soporte de la version 5.4 de TSM, es ampliamente recomendado actualizarlas a la version 5.5, debido al mejoramiento de performance que se tiene en esta versión y tambien el mayor período de soporte restante. Diagrama Lógico de TSM V6 Este es un diagrama de la configuración recomendada para las nuevas instancias V6 y su integración con las instancias actuales V5. Esquema de ambiente de respaldos TSM Server V6 Bsmtsm02 Bsmtsm04 Bsmtsm12 BsmtsmNice Instance B Lib Client Lib Clients Instance A Lpar2 Bsmtsm01 Bsmtsm03 Bsmtsm05 Bsmtsm06 Bsmtsm07 Lib Manager Lpar1 EMC LIB1 3584LIB2 TS7650G 3590/3592 Drives 3584CDL 31-LTO3 Centera 3958DD3 LTO3 3584CDL C 9 drives 3592E05 9 drives 3592E05 LibManager LibClient Gráfico 26 38

42 Objetos de TSM BD Componentes de la BD en la V6 Componentes de BD de TSM V6 TSM Server Active Log TSM DB Log Mirror (opcional) Archive Log TSM STGPools (disk, tape) Failover Archive Log (opcional) Gráfico 27 DB Sizing Instancia Tamaño de BD (GB) % Utilización Espacio Utilizado (GB) BSMTSM BSMTSM BSMTSM BSMTSM BSMTSM BSMTSM BSMTSM BSMTSM BSMTSMNICE Total (GB) Factor para V6.1 = Crecimiento anual (30% a 3 años) Espacio de BD por instancia (2 instancias) 1.7 TB 39

43 Log Sizing Instancia Tamaño de Log (GB) % Utilización Máxima Espacio Utilizado (GB) BSMTSM BSMTSM BSMTSM BSMTSM BSMTSM BSMTSM BSMTSM BSMTSM BSMTSMNICE Total (GB) Factor para Log V6.1 = Crecimiento anual (30% a 3 años) Espacio para Log por instancia (2 instancias) 18GB Distribución de espacio para BD Base de Datos de TSM V6 Contenedores de TS Protegidos con RAID Disk 1 32GB Disk 2 32GB Disk 3 32GB Disk 4 32GB LUN TB # io threads = # directories RAID 5 db2set i <instance> db2_parallel_io Host Active Log Disk 1 32GB LUN 2 32 GB RAID 0 Host Gráfico # io threads = # directories

44 Base de Datos de TSM V6 Log Mirror Disk 1 32GB LUN 3 32 GB RAID 0 Host Archive Log Disk 1 32GB Disk 2 32GB Disk 3 32GB Disk 4 32GB LUN 4 70 GB RAID 5 * 2 días de archive logs Host Gráfico 29 Base de Datos de TSM V6 Fail Over Archive Log Disk 1 32GB Disk 2 32GB Disk 3 32GB Disk 4 32GB LUN 5 70 GB RAID 5 * uso esporádico Host Gráfico 30 41

45 Acciones de Mantenimiento Estadísticas de acceso La versión 6 TSM realiza análisis estadísticos automáticos (RUNSTATS) de la bd para mejorar su performance... Reorganizaciones La bd V6 realiza reorganizaciones de datos automáticamente para mejora el performance, ya no es necesario realizar la defragmentación manual como en la versión 5. Nota: Cuando se agrega un nuevo directorio a la BD, DB2 ejecuta una reorganización automática para balancear el uso de espacio, la cual puede impactar el performance del servidor durante la actividad. Si se aumenta el tamaño de los directorios actuales esta reorganización no es requerida. Auditorias de la BD La nueva versión 6 integra DB2 como base de datos, la cual garantiza la integridad referencial de la información que se añade a la BD. Con esta funcionalidad ya no son requeridas las auditorías de la BD como en la versión 5. Políticas de Respaldo Dominios Dominio Descripción Comentarios Windows Dominio para servidores Windows Unix Dominio para servidores Unix Debido a que las politicas para AIX, Solaris, HP-UX,Linux son idénticas, no es necesario tener un Dominio para cada plataforma. Oracle Dominio para bases de datos Oracle Sql Dominio para bases de datos MS- SQL Exchange Dominio para datos de MS- Exchange Management Classes Backup Archive Dominio MgmtClass Versions data Retai n Vers. Data Retai n Desino Dias Destin o Exist Extra deleted Only Windows semanalos WinsemanalOS 31 42

46 diariodb windiariodb 31 semanaldb winsemanaldb diarioapp windiarioapp 31 Unix semanalos unxsemanalos 31 diarioapp unxdiarioapp 11 semanalapp unxsemanalapp 31 diariologs unxdiariologs 94 diarioweb unxdiarioweb 22 semanalweb unxsemanalweb 94 diariowebau d unxdiariowebau d Oracle oracle NA SQL *Same settings for DB and Logs # DB s # Days #DB s #Days SQL NA Exchang e *Se recomienda backup incremetal absoluto para respaldos tipo Full vs Archive vs Selective #StgGrps #Days #StgGrps #Days exchange NA * Se recomienda no limit para asegurar que no se agotan las versiones disponibles Para retenciones altas, se recomienda n formatos de datos que sean legibles durante todo el período de retención * Se recomiend a no limit para asegurar que no se agotan las versiones disponibles Storage Pools de Disco Sizing Instancia Tamaño (GB) Stgpool bsmtsm diskpool bsmtsm diskpymes bsmtsm02 98 diskpool bsmtsm diskpool bsmtsm04 45 diskpool bsmtsm05 bsmtsm06 41 diskpool bsmtsm06 41 diskpool1 43

47 bsmtsm diskpool bsmtsm diskpool bsmtsmnice 200 nicepool Total 3236 StgPoolName Tamaño Descripción DiskPool1Mig 0.5 TB Disk pool para Windows temporal DiskPool1NoMig 0.5 TB Disk pool para Windows permanente DiskPool2Mig 0.5 TB Disk pool para Unix temporal DiskPool2NoMig 0.5 TB Disk pool para Unix permanente El uso de estos stgpool será gradual conforme se vaya agregando carga a las instancias de la version 6, por lo que se puede iniciar con espacios más pequeños, por ejemplo 1 TB para ambas instancias. Se recomienda evaluar el uso de active stgpools para servidores criticos. Storage Pools en VTL StgPoolName winsemanalos windiariodb windiarioapp unxsemanalos unxdiarioapp unxsemanalapp unxdiariologs unxdiarioweb unxsemanalweb Descripción VTL pool para semanalos windows VTL pool para diariodb windows VTL pool para diarioapp windows VTL pool para semanalos unix VTL pool para diarioapp unix VTL pool para semanalapp unix VTL pool para diariologs unix VTL pool para diarioweb unix VTL pool para 44

48 StgPoolName Descripción semanalweb unix Storage Pools de Cinta StgPoolName Collocate Descripción winsemanaldb By Group winsemanaldb unxdiariowebaud By Group unxdiariowebaud Oracle By FileSpace Pool para bd Oracle SQL By FileSpace Pool para bd MS-SQL Exchange By FilesSpace* Pool para bd MS- Exchange *Se utiliza el máximo de cintas con el fin de mantener la info lo más separada posible para optimizar las operaciones de restore Los StgPools listados seran creados en ambas instancias/librerías con el fin de balancear la carga en cada una Collocate El parámetro collocate se define para en storage pools de acceso secuencial (primary, copy o active-data storage pool) para indicar al servidor que mantenga los archivos pertenecientes a un nodo, grupo de nodos o un cliente de file space en el mínimo posible de volúmenes. La tabla siguiente indica las ventajas y desventajas del uso del collocate: Ventajas Collocate El servidor mantendrá los archivos de los clientes en el mínimo número de volúmenes. En el momento de hacer un restore de un solo cliente se realizarán muchos menos montajes. Se pueden restaurar clientes en paralelo ya que sus archivos se encuentran en distintas cintas (si estuvieran en una sola, tendría que Desventajas Collocate Cuando se respalden o restauren varios clientes requerirá un mayor número de volúmenes y montajes. Las cintas pueden no estar completamente llenas. El servidor tratará de usar todas las cintas disponibles antes que el espacio disponible en cada una. No se recomienda usar collocate para copy y active-data storage pools 45

49 Ventajas Collocate esperar el segundo cliente que termine de leer los datos del primero). Menor tiempo en búsquedas de entradas del la base de datos y operaciones de montaje. Desventajas Collocate ya que consume varias cintas sin llenar completamente. Se debe considerar que dichas cintas están off-site y requieren mayor esfuerzo en traslados y reclamaciones innecesarias. Revalidación de politicas de respaldo Como una buena prática, para asegurar que las politicas de respaldo configuradas en TSM continúan reflejando las necesidades del negocio, se sugiere realizar una revalidación periódica de las mismas con los usuarios, por ejemplo una revalidación anual. Servidores Sizing A continuación las recomendaciones de dimensionamiento de los BackupServers con la nueva versión IBM TSM 6.x: IBM Tivoli Storage Manager Extended Edition v6.x, AIX 5.x/6.x - (1) Para el primer Servidor Físico, se recomienda, como mínimo, 8 CPUs, 16GB RAM, 4TB DISK: (ACTUAL: 4 CPUs, 6TB RAM, 2TB DISK) - (4) Para las particiones virtuales con cada BackupServer, se sugiere la asignación de 2 CPUs con 4 instrancias. (ACTUAL: 8 instancias) - (8) 1GbE Ethernet Card IBM Tivoli Storage Manager Extended Edition v5.x, AIX 5.x/6.x - (1) Para el segundo Servidor Físico, se recomienda, como mínimo, 2 CPUs, 4GB RAM, 500GB DISK. (ACTUAL: 1 CPUs,5TB RAM, 800GB DISK) - (1) Para las particiones virtuales con cada BackupServer, se sugiere la asignación de los 2 CPUs con 1 instancia (ACTUAL: 2 instancias) - (1) Ethernet Card 1GbE IBM Tivoli Storage Manager v6.x and AIX Server Requirements and Support: 01.ibm.com/support/docview.wss?rs=663&context=SSGSG7&uid=swg &loc=en_US&cs=utf-8&lang=en 46

50 Protección del servidor (clustering) Debido a que las operaciones de respaldos y recuperaciones de datos del negocio son muy críticas para la continuidad del mismo, se recomienda ampliamente el uso de un ambiente de alta disponibilidad para maximizar la disponibilidad del sistema de respaldos. Un entorno de clúster se refiere a un ambiente que presenta las siguientes características: Los discos son compartidos entre máquinas físicas, ya sea en forma exclusiva (sólo un host tiene acceso al disco lógico en un momento determinado) o en forma concurrente. Los discos aparecen como discos locales al host y no como recursos de red. Recomendación: Montar los sistemas de archivos localmente en el sistema, no a través de un protocolo para compartir archivos por LAN, como el sistema de archivos de red (NFS). Los puntos de montaje de los discos locales deben ser idénticos en cada host físico en el entorno (si el sistema de archivos /group1_disk1 falla de NodoA a Nodo B, éste es montado en el Nodo B como /group1_disk1). Nodos Cliente Lan-free backups Debido al alto costo de una red SAN de respaldos y para que se obtenga un beneficio sustancial con el uso de respaldos tipo LAN-free, es recomendable utilizarlo para nodos cliente que transfieran objetos de gran tamaño, como por ejemplo bases de datos. Este es un esquema de cómo fluye la información de datos y metadatos en un ambiente de respaldos tipo Lan-free 47

51 Gráfico 31 La tabla siguiente muestra el tipo de cliente y el medio de transporte recomendado: Tipo de cliente Tipo de respaldo Comentarios File server Lan Lan free cuando se cuenta con infraestructura para respaldos tipo Image Se asume una distribución mayoritaria de archivos pequeños DB server Mail-Server Web-server Aplicaciones especiales Lan-free Lan-free Lan Lan-free cuando se cuenta con infraestructura para respaldos tipo Image Se recomienda examinar 48 Se asume una distribución mayoritaria de archivos pequeños

52 Tipo de cliente Tipo de respaldo Comentarios (Imaging, video, etc) la aplicación para deteminar qué tipo de objetos son los más representativos. Basado en las consideraciones anteriores, se recomienda configurar Lan-free para todos los servidores de base de datos criticos y servidores de correo. Como recomendación, Lan-free para mas de 500 GB es deseable, más de 1TB es mandatario. Journal Backups Ventajas - Reduce el tiempo de respaldo y el tráfico de la red. Los archivos elegibles para respaldo son conocidos antes del inicio de la operación de respaldo - La memoria requerida para un journaling environment inical es la misma que la de un full file space incremental, sin embargo los subsecuentes journal-based backups requieren menor memoria. - Aplica para distintos tipos de respaldo (progressive incremental backup, selective backup, adaptive subfile backup) Desventajas - Requiere la instalación y configuración del TSM journal service (Windows) ó TSM journal daemon (AIX) - Cada journal service instance es asociada solo a un nombre de nodo cliente de TSM - Disponible únicamente en clientes AIX (excepto AIX 32-bit GPFS) y Windows (excepto Windows server 2003 o 2008 Itaniumbased systems) - Cuando se usa un antivirus se tiene limitaciones. Algunos antivirus pueden generar cambios incorrectamente en el TSM journal service, causando que archivos que no han cambiado se vuelvan a respaldar - Algunos ajustes a journaled file systems no tomaran efecto hasta ser puesto offline y regresarlo online - TSM BA AIX client no puede realizar journal-based backup en datos accedidos por NFS 49

53 Image Backups Ventajas - Mejora la velocidad con la que TSM respalda y restaura file systems con muchos archivos pequeños. - Conserva los recursos en el servidor durante los respaldos ya que una sola entrada es requerida para la imagen. - Provee una imagen del sistema en el tiempo. - Los datos son restaurados al mismo estado que estaban en el momento del respaldo. - Permite restaurar un file system o un volumen lógico raw corruptos. - Un image backup offline previene que aplicaciones escriban en el volumen. - Permite respaldar un file system entero o un volumen raw como un solo objeto. - Puede ser seleccionado por BA clients en sistemas UNIX, Linux y Windows - El respaldo en línea es posible para clientes Windows usando la función TSM snapshot. - El image backup static tradicional previene que otras aplicaciones escriban en el volumen. Desventajas - No se puede restaurar un image backup al volumen en el cual el cliente esta siendo ejecutado. - Mientras se respalda el volumen se encuentra inaccesible para las demás aplicaciones. - Se requiere accesos de administrador o root, según la plataforma. - No permite restaurar un solo archivo del respaldo. - Puede ser perjudicial ya que requiere que el file system sea bloqueado. Windows - Permite respaldar volúmenes con formato FAT, FAT32, NTFS (solo aquellos bloques usados por el file system o menores que el parámetro imagegapsize serán respaldados), o RAW sin formato. - Normalmente no se puede restaurar un image backup sobre el mismo drive ya que un seguro exclusivo del system drive no lo permite. Sin embargo, cuando se usa WinPE esto es posible. - El image backup no garantiza la consistencia de los system objects, como el Active Directory. - Si se encuentran sectores de disco dañados durante un image backup, puede haber corrupción de datos. UNIX - Usando la opción de dynamicimage el volumen permanece como readonly. Sin embargo, si las 50

54 Ventajas Desventajas aplicaciones continúan escribiendo puede ocurrir un corrupción de datos; resultando en una inconsistencia en los datos y perdida de ellos después de una restauración. - TSM dynamic image backups no debe ser usado para file systems, ya que el diseño del file system puede producir inconsistencias en los datos incluso cuando no hay actividad. - No aplica a Mac OS X. - Se debe considerar antes respaldos por snapshot en AIX y Linux. - File systems administrados por TSM for space management nos son permitidos para image backups. - No se pueden incluir system files en un image backup porque los file systems estando activamente no pueden ser desmontados. Rendimiento para archivos pequeños Para este tipo de archivos es recomendable utilizar LAN como medio de transporte así como las técnicas arriba descritas para eficientar el uso de BD de TSM, como son image backup y también optimizar parámetros de comunicaciones de TSM. Se recomienda evaluar el uso de active stgpools para servidores críticos. Extensión de soporte para la version 5.3 Si por dependencias en compatibilidades de SW Produban requiere continuar utilizando SW de TSM versión 5.3 por un tiempo considerable, se recomienda contar con un contrato de soporte extendido para TSM V5.3. El representante de IBM para Produban puede proporcionar todos los detalles al respecto. 51

55 LAN La topología de Produban es confidencial, sin embargo se recomienda lo siguiente: - red gigabit dedicada para respaldos - redudancia de tarjetas o almenos tarjetas spare para servidores criticos - Etherchannel para el servidor de TSM - tunning de parámetros de sistema operativo para optimizar respaldos SAN Topología propuesta Este es el diagrama de la conectividad propuesta: srvpro22 bsmtsm12 Cluster TSM V6.1.3 BSMTSM01 BSMTSM05 BSMTSM07 3 HBA s 2Gbps BSMTSM04 BSMTSM12 6 HBA 4Gbps TSMINST1 TSMINST2 Common Storage Lan-Free Clients 24K1 1 HBA 2Gbps 4100 Dwhpro02,Scbpro /3592 Drives 2Gbps Srvpro02, Srvpro23 SAN Anaconda1 Anaconda2 VTL TS7650G LAN Access Centera 6 drives 3592E05 6 drives 3592E05 bsmtsm05 bsmtsm01 bsmtsm01 Gráfico 32 bsmtsm06 52

56 Numero de HBA recomendadas TSM Server Para el TSM Server se recomienda asignar 3 drives 3592E05 por HBA, por lo que se requieren 6 HBAs en el servidor de TSM V6. Estas HBA s son exclusivas para acceso a cintas, se requeriran ademas HBAs para acceso a disco según la cantidad de disco disponible. Este número de HBAs es considerando que el TSM Server puede accesar a todos los drives de manera simultánea. Como se realizará una integración gradual del ambiente a TSM V6, es posible iniciar con menos tarjetas, un buen inicio son 4 HBAs para soportar las dos terceras partes de los drives totales. Para el diseño de la infraestructua de SAN es necesario considerar que siempre habrá un elemento con menos troughput que los demas, sin embargo éste debe ser identificado para conocer el rendimiento real Constraining Variable Disk SAN HBA PCI BUS CPU Memory LAN Server HBA SAN Tape Constraining variable Client Nodes Copyright IBM Corporation Gráfico 33 Para los nodos clientes se recomienda asignar 3 drives 3592E05 por HBA. La cantidad específica de HBA s para cada nodo se determina en base al nivel de paralelismo permitido en cada uno. 53

57 Un buen punto de inicio es una HBA para cada cliente SAN y, en base al análisis de cada uno durante su migración a TSM V6, agregar las HBA adicionales requeridas. Librerías Fisicas Distribución por Instancia de TSM Con el fin de balancear el acceso a las librerías, se asignará las dos librería a las dos instancias V6 pero se recomienda una instancia de libmanager adicional para ambas. Distribución por clientes LAN-Free La distribución de instancias será realizada considerando tambien la cantidad de clientes de LAN-free, es decir que se asignaran equitativamente clientes de Lan-free a cada una. VTL Referirse al documento de instalación de VTL Respaldos de BD Oracle - RMAN Consideraciones de backups de Oracle RMAN es una herramienta de backup y restore provista por la base de datos Oracle y es un paquete integrado al Oracle Server. RMAN maneja los procesos de backup, restauración y recovery de instancias de base de datos Oracle. RMAN puede automaticamente backup, restore, and recover de los siguientes objetos: Database Tablespaces Data files Control files Archived redo logs Además de las operaciones de backup y restore, RMAN puede: Generar los registros de todas las operaciones de backup, restore y recovery 54

58 Ejecutar operaciones de backup y restore en paralelo para mejorar la performance. El catálogo de rman se puede utilizar para hacer backups de varias bases de datos. Por recomendación de Oracle es conveniente que el catálogo se encuentre en un servidor diferente, a la base de datos a cual se realiza el backup y que este en modo archivelog. Es fundamental hacer backup del catálogo. Uso del comando Export para hacer backups adicionales del catálogo. Un export del catálogo permite la mejor flexibilidad cuando el catálogo debe ser restaurado, porque éste puede ser restaurado en cualquier base de datos oracle existente. Gráfico 33 La operación comienza cuando se invoca un comando de rman o un script (1). RMAN conecta al recovery catalog (2) y a la base de datos a hacer el backup (3). Las operaciones de backup o restore pueden ser ejecutadas, RMAN abre canales al TSM, usando la SBT API (4). RMAN entonces crea un proceso entre la instancia a la cual se va hacer backup, ejecutando la operación (5). Para una operación de restore, RMAN hace una consulta al recovery catalog para determinar cuales archivos restaurará del servidor TSM. Para una operación de backup, RMAN hace backups de los objetos especificados en el comando al servidor TSM. En ambos casos, los datos son transferidos sonre el canal previamente definido. 55

59 Recomendaciones de uso de RMAN para respaldos con TDP Tipos de backups que podemos utilizar con RMAN Las técnicas que podemos considerar: Offline backup Este es un backup simple para el administrador, ya que la base de datos solo se utiliza para el backup Es problema es el tiempo que tomará el backup y la base no esta productiva. Este tipo de backup conviene hacerlo para versiones mensuales o anuales, en los momentos que la base de datos no esta en producción. Si es necesario hacer este tipo de backup, y la base de datos debería estar un corto tiempo sin trabajar. Deberíamos hacer un backup en parelelo (utilizar varios drives al mismo tiempo), para reducir el tiempo en que la base de datos no esta productiva. Online backup Este tipo de backup se utiliza con la base de datos en producción. La base de datos es utilizada mientras se ejecuta el backup. Mientras se realiza el backup la base de datos utiliza los logs files para almacenar las transacciones. Cuando se realiza la restauración utilizamos los logs files. Este tipo de backups se utilizan en base de datos de producción, que no pueden ser paradas para la ejecución del backup Database export Este tipo de backup se utiliza cuando hacemos backups a nivel tablas. Por ejemplo podemos hacer una copia de una tabla a un filesystem. De esta forma hacemos un restore de la tabla con el comando import. Incremental backup El backup incremental solo hace un backup de los cambios de el último offline u online backup. De esta manera se reduce el tiempo del backup. Cuando un recovery es necesario, deberemos hacer el restore del full backup y los siguientes incrementales. Esto demora el restore. No conviene ser utilizado en los casos que necesitamos un restore rápido de la base de datos 56

60 Log file backup Los logs backups nos permiten realizar el restore a un punto en el tiempo entre fulls backups. Backup of RDBMS supporting files Se deberán hacer backups de los binarios de la base de datos y archivos de configuración a tráves de backups de archivos de TSM. Cátalogo de la base de datos RMAN El recovery catalog es el repositorio para información de los objetos creados por RMAN El recovery catalog debe ser creado separado de la base de datos a la cual se le hará backup. Este catálogo puede contener información de backup de varias base de datos de Oracle El catálogo guarda información del esquema físico de la base de datos Historia de los backups y restores de la base de datos Las versiones activas y las versiones borradas, La historia de las operaciones de backups. El backup del catálogo de la base de datos es importante por lo tanto se debe realizar un backup con rman a través de otro catálogo o hacer un backup a disco y luego hacer backups de los files con el TSM. Respaldos con TDP for MS-SQL / Exchange 57

61 Resapaldos con TDP for MS-SQL / MS-Exchange App. (Exchange/SQL) Storage Medio de Transporte LAN/SAN TSM Server TSM TDP TSM API Gráfico 34 58

62 Reportes Ejemplos de reportes Reporte de respaldos Gráfico 35 Utilizacion de BD de TSM 59

63 Gráfico 36 Ejemplo de listado de reportes disponibles 60

64 Gráfico 37 Monitoreo TSM soporta el protocolo SNMP junto con el registro de eventos para proporcionar: - configurar un heartbeat para monitorear regularmente que el TSM server está activo - enviar mensajes (traps) a un SNMP Manager (por ejemplo Tivoli Enterprise Console) - ejecutar TSM scripts - TSM ya incluye un archivo MIB 61

65 Gráfico 38 Nota: El TSM reporting and monitoring feature contiene también varias funciones de monitoreo para TSM server IV. RESULTADOS OBTENIDOS Asegurar que los equipos críticos de producción cuenten con un esquema de respaldo que permita la integridad de los mismos. Este objetivo era primordial para el Banco ya que con esto se garantiza al 100% la producción y caso de alguna catástrofe. Reducir los tiempos de recuperación total y parcial. Este objetivo también era de los más importantes ya que con esto se afecta el menor tiempo posible a la Producción en caso de pérdida de datos. 62