PoT Tivoli Storage Manager Octubre

Transcripción

1 PoT Tivoli Storage Manager Octubre

2 Agenda Deduplicación Coffe Break (15 ) Node Replication Blueprints

3 Deduplicación

4 Deduplicación Incluido en la licencia Disponible a partir de la versión 6.1 (2009) Capacidades de deduplicación en origen y destino Deduplicación basada en chunk variable Comprobaciones de integridad: Hash bit MD5* Hash bit SHA-1 Elapsed Time (hours) Tamaño del chunk 24.0 Server-side dedup, Linux x86, 10TB ingest, 128MB object size Deduplicación por SW (vs Deduplicación appliance) A B C A B reclamation dedup deref ingest + identify TSM 7.1 : 10X Scalability Improvement on TSM server deduplication performance

5 TSM Server Side Data Deduplication 1. Data sent from clients to server and stored in primary storage pool Deduplication- Enabled Disk Storage Pool 4. Duplicate data chunks removed from primary storage pool during Reclaim operation A A B File 1 File 2 C B File 3 E C A D C 3. Backup Stgpool operation copies data to non-deduplicated copy storage pool Copy Storage Pool (non-deduplicated) File 3 2. Identify Duplicates process creates chunks and pointers to hash index in server database to relate files to chunks hash Index File 1 File 2 File 3

6 TSM Client Side Data Deduplication TSM Client TSM 6.x client B File 4 F E 1. Client creates chunks 2. Client and server identify which chunks need to be sent Deduplication- Enabled Disk Storage Pool A File B1 C D 4. Entire file is reconstructed during Backup Stgpool operation to non-deduplicated stg. pool F E TSM Client Copy Storage Pool (non-deduplicated) 3. Client sends chunks and hashes to server so that it can represent object in database File 4 File 1 File 2 File 3 hash Index File 4

7 Deduplicación: Client Side Descarga al servidor del proceso de deduplicación Requiere capacidad de proceso en el cliente: Recomendado: 1 CPU 2.2GHz por cada proceso de deduplicación Ejemplo: Quad Core 2.2GHz, durante la ventana de backup que tenga menos del 75% de utilización de CPU. No tiene requerimientos de memoria Se puede combinar con la compresión Client deduplication cache: Cache en el cliente para acelerar la búsqueda de hashes Tamaño por defecto 2GB ENABLEDEDUPCACHE [yes no] 7

8 Deduplicación: Server Side La deduplicación tiene requerimientos de CPU/Mem en el servidor. A configurar: 1. Sizing&Tuning DB2 2. Sizing Storage Pool Deduplicado 3. HW/SW TSM Server 8

9 Sizing&Tuning DB2 DB2 contiene los metadatos del backup Ubicación de los ficheros Tabla de chunks Puede convertirse en cuello de botella Requiere discos rápidos: SAS/NL o SSD Blueprints Para el sizing se necesita el volumen de datos prededuplicación Rule of thumb: 100GB por 10TB de datos pre-deduplicados 400TB pre-deduplicados 4TB BBDD DB2 Habría que añadir los requerimientos de ficheros ~ 0,8KB por fichero 9

10 Sizing&Tuning Dedup Disk pool Tecnología almacenamiento SAS/NFS/iSCSI Storage pool de tipo FILE (FDC) Información requerida: Volumen total FE (V) Tamaño de backup diario (d) Retención (r) Ratio de deduplicación (1:N) Qué hacer: Calcular el volumen total de datos respaldar: V1=V+d*r Aplicamos el ratio de deduplicación: V2=V1/N Agregamos un espacio temporal (%) Vstgpool=V2+V2*0,3 10

11 Ejemplo 1 Volumen FrontEnd 40TB Ratio de cambio diario 5% Retención(días) 30 Ratio deduplicación 3:1 Espacio temporal 30% Backup diario = 40 TB *0.05 = 2TB Volumen de cambios = 30 * 2 TB = 60TB Volumen total retenido = 40 TB + 60 TB = 100 TB Volumen total despues de dedup = 100 TB / 3 = 33.3TB Volumen + espacio temporal = 33.3TB + 30% = 43.3TB Añadimos el backup diario = 43.3 TB + 2 TB = 45.3 TB Tamaño del storage pool = 46TB Tamaño de la BBDD DB2 (100/10) = 1TB 11

12 Ejemplo 2 Volumen FrontEnd 150TB Ratio de cambio diario 8% Retención(días) 30 Ratio deduplicación 4:1 Espacio temporal 30% Backup diario = 150 TB * 0.08 = 12TB Volumen de cambios = 30 * 12 TB = 360TB Volumen total retenido = 360 TB TB = 510 TB Volumen total despues de dedup = 510 TB / 4 = 125.5TB Volumen + espacio temporal = 125.5TB + 30% = 165,75TB Añadimos el backup diario TB = TB + 12 TB = Tamaño del storage pool = 178TB Tamaño de la BBDD DB2 (100/10) = 5.1 TB 12

13 Deduplicación: TSM Server HW/SW Blueprints 13

14 Deduplicación: Nativa vs Appliance Nativa Protect Tier Escalabilidad 400TB/server 1PB/appliance hasta 25PB Alcance deduplicación Servidor Global Coste HW TSM Server HW + Licencias appliance Otros Deduplicación en origen LAN-Free a disco 14

15 Referencias TSM Performance Manual: TSM Deduplication FAQ: TSM Deduplication WhitePaper: 15

16 COFFEE BREAK 16

17 Node Replication

18 Node Replication Incluida en la licencia Replicación de backups entre servidores de TSM Deduplicada e incremental Granularidad a nivel de filesystem/unidad Replicación IP Servicio Activo-Activo Failover/failback del servicio Los clientes de backup conmutan automáticamente Políticas dismilares: Permite aplicar distintas políticas de retención de datos en los TSM Servers Recuperación de ficheros corruptos. Configuración Many to 1 Beneficios: Continuidad del servicio en caso de contingencia. Cumplimiento de procesos legales de externalización/lopd de datos de backup sin requerir operación manual Site A Database DB2 TSM EE Server A Client C Client B Client A Metadata and deduplicated data TSM EE Server B DB2 Site B Database Client X Client Y Storage Hierarchy Hot Standby for better D/R SLAs Storage Hierarchy

19 Automated Failover TSM Server A Database DB2 3 2 Node X TSM Server B Database DB2 Storage Hierarchy Storage Hierarchy Client Node X Pre-failure 1. Server A envía la información de failover al cliente (moficica dsm.opt/.sys) 2. Server A replica la información de backup y los metadatos al Server B Failover 3. Server A deja de responder 4. El cliente basándose en la información de failover que le ha proporcionado Server A, redirije las comunicaciones al Server B, únicamente para operaciones de Restore Failback 5. Cuando el Server A vuelve a estar disponible las operaciones del cliente se redirigen nuevamente al Server A 19 19

20 Dissimilar Policies Caso de Uso: Branch office con almacenamiento reducido para recuperación rápida Server A (Branch Office) Server B (Data Center) Replication Server A stores 2 versions Server B stores 5 versions Caso de Uso: Ubicación remota con un SLA de recuperación y copia en el datacenter para archivado Server A Server A stores 4 versions for operational recovery Replication Server B (Data Center) Server B stores 2 versions for long term What s New: Se pueden definer diferentes políticas (retención y copias) en el Source y Target TSM servers. La Expiración se ejecuta independientemente en cada servidor, basándose en las políticas activas de cada servidor. Beneficios Gestión flexible de la información replicada en las distintas ubicaciones Optimiza el uso de los recursos Puede eliminar el uso de la cinta 20

21 Dissimilar Policies VALIDATE REPLPOLICY <SERVER> Ejecutar previo a la activación Muestra las diferencia de políticas de todos los nodos replicados SET DISSIMILARPOLICIES <target_server> [on off] Si DISSIMILARPOLICIES está a: ON: La replicación es equivalente a un backup. OFF: Se replica el estado de los ficheros del source server. 21

22 Recuperación de ficheros dañados Descripción: Recuperar fichero dañados en el source server desde el target server Beneficios: Assist with local recovery of files that have been damaged on the source server Replaces damaged files with good copies that have been replicated Includes files on volumes that have been updated as destroyed Escenario: 1) Server A replica información al Server B 2) Se pierde información en el Server A: un volumen del storage pool o un fichero 3) El volumen o el fichero son recuperados desde el Server B al Server B 22

23 Recuperación de ficheros dañados SET REPLRECOVERDAMAGED [on off] 23

24 Configuración Many-to-1 Branch Office Dedup pool TSM Backup Server Node Replication Main DataCenter Branch Office Dedup pool Node Replication TSM Server Backup Server PHYSICAL TAPE LONG TERM DATA/DR TSM Backup Server Node Replication Dedup pool Branch Office Dedup pool TSM Backup Server Nota.- Los servidores de las Branch Office pueden ser máquina virtual, con un Pool de disco deduplicado para albergar los backups operacionales 24

25 TSM Node Replication: Compatibilidad La replicación permite estos niveles de 25

26 Entorno de Demo DEMO ENVIRONMENT TSM TSM2 Dedup pool Node Replication Dedup pool TSM Server Linux TSM Server Windows BACKUP CLIENTWIN TSM Operations Center TSM Client

27 Calculo de la Ancho de Banda Hay que asegurar que el ancho de banda disponible es suficiente para realizar la replicación Pasos: 1. Estimar el volumen total a replicar en GB (TD) Volumen de backup diario pre-deduplicado 2. Longitud de la ventana de replicación en horas (RWT) 3. Calcular el ratio de deduplicación (DR) QUERY STGPOOL F=D Required Network Bandwidth (Mbits/second) = (TD * ( 100 / DR ) * 8192) / ( RWT * 3600 ) Ejemplo: 2048GB, 7horas y 80% RNB = (2.048*(100/80)*8.192)/(7*3.600) = 832Mbits/s 27

28 Referencias Knowledge Center: Node Replication Technote: 28

29 Blueprints

30 Blueprints Nuevas funcionalidades añaden más parametros a tener en cuenta para realizar el sizing de la solución de TSM Node replication Deduplicación Guías de configuración Disponibles: Blueprint for Windows Blueprint for Linux Blueprint for pseries

31 Ejemplo 1 Volumen FrontEnd 40TB Ratio de cambio diario 5% Retención(días) 30 Ratio deduplicación 3:1 Espacio temporal 30% Backup diario = 40 TB *0.05 = 2TB Volumen de cambios = 30 * 2 TB = 60TB Volumen total retenido = 40 TB + 60 TB = 100 TB Volumen total despues de dedup = 100 TB / 3 = 33.3TB Volumen + espacio temporal = 33.3TB + 30% = 43.3TB Añadimos el backup diario = 43.3 TB + 2 TB = 45.3 TB Tamaño del storage pool = 46TB Tamaño de la BBDD DB2 = 1TB 31

32 Ejemplo 1 Sizing Volumen backup diario: 2TB Volumen total gestionado: 100TB 32

33 Ejemplo 2 Volumen FrontEnd 150TB Ratio de cambio diario 8% Retención(días) 30 Ratio deduplicación 4:1 Espacio temporal 30% Backup diario = 150 TB * 0.08 = 12TB Volumen de cambios = 30 * 12 TB = 360TB Volumen total retenido = 360 TB TB = 510 TB Volumen total despues de dedup = 510 TB / 4 = 125.5TB Volumen + espacio temporal = 125.5TB + 30% = 165,75TB Añadimos el backup diario TB = TB + 12 TB = Tamaño del storage pool = 178TB Tamaño de la BBDD DB2 (100/10) = 5.1 TB 33

34 Ejemplo 2 Sizing Volumen backup diario: 12TB Volumen total gestionado: 510TB > 400TB!! 34

35 35