Manual Tivoli Manager_5.2

Universidad Nacional del NordesteFacultad de Ciencias Exactas, Naturales y Agrimensura

Trabajo Final de Aplicación

Aplicaciones Orientadas alAprovechamiento de las Tecnologías Tivoli

Storage

Stella Maris Gerzel - L.U.: 30.418

Prof. Coordinador: Agr. Castor HerrmannProfs. Orientadores: Mgter. David Luis la Red Martínez y

Lic. Valeria Emilce Uribe

Licenciatura en Sistemas de InformaciónCorrientes - Argentina

2007

A mi familia

Prefacio

En el contexto actual, donde la información es la esencia de una orga-nización resulta cada vez más necesario disponer de sistemas informáticos,seguros, distribuidos, multiplataformas y que además se encargen de la gestónautomática de la información con acceso desde la web para su control y admi-nistración, mejorando la gestión, dado que no hay que estar físicamente frentea los equipos para realizar las tareas pertinentes.

Todo lo señalado precedentemente sería ilusorio si no se dispusiera del soft-ware, o del conjunto de software adecuado que facilitaran la tarea de respaldarlos datos, para que la información de trabajo y la información histórica estesiempre disponible entre las distintas dependencias de las organizaciones, deforma inmediata y coherente utilizando diferentes plataformas de hardware yde software.

Este trabajo se basa en probar una aplicación web utilitaria empleandoel software Tivoli Storage Manager para asistir a los usuarios de una organi-zación, en la gestión automática e inteligente del respaldo de los datos y lainformación necesaria, gestionando globalmente los recursos de almacenamien-tos.

Las bases de datos de la aplicación web serán administradas por TivoliStorage Manager, para lo cuál se deberá asignar y asociar espacios de almace-namiento de diferentes medios de almacenamiento al entorno Storage Manager,asignando diferentes tipos de acceso a esos espacios de almacenamientos.

Los usuarios podrán realizar el backup de sus datos, de forma sencilla y pormedio de una interface gráfica de usuario, también podran recuperar fácilmentela información en caso de que por algún motivo la perdieran, eligiendo laversión de backup que desean recuperar.

Por otro lado se crearán distintos administradores del Server Tivoli Sto-rage Manager con distintos privilegios, los cuáles podrán dar de alta, vaja ymodificar clientes, medios de almacenamientos, políticas de administración yclases administradoras.

Objetivos

El objetivo inicialmente planteado fue la realización de una aplicación utili-taria empleando sofware relacionado con Tivoli Storage Manager para asistir alos usuarios en la gestión automática e inteligente del recurso almacenamiento,

vi

brindando de esta manera, posibilidades de gestión global del citado recurso.

El objetivos planteado al inicio del trabajo, fue totalmente cumplido.

Clasificación del Trabajo

Iniciación de un trabajo de investigación que implique la alicación de téc-nicas o métodos estudiados, en áreas no habituales.

Desarrollo de un entorno administrado por Tivoli Storage Manager, pormedio de una aplicación servidor y una aplicación cliente que se comunicanpara realizar todas las tareas locales en forma remota.

Etapas de Desarrollo

• Se ha efectuado una amplia recopilación bibliográfica específica de lostemas pertinentes a la tarea planificada y a los productos de softwareque se emplearon para la concreción del Trabajo Final.

• Se realizaron las traducciones de los manuales correspondientes a la he-rramienta de desarrollo Tivoli Storage Manager, versión 5.2.0 para Win-dows.

• Como consecuencia de las gestiones realizadas por el Profesor Orienta-dor ante IBM Argentina se han recibido materiales tanto en CD’s comoen libros de dicha empresa, en el marco del Scholars Program de la mis-ma, destinado a Universidades de todo el mundo; se destacan por sernecesarios para la realización del presente Trabajo Final los referentes aproductos de software tales como el WebSphere Studio Application De-veloper versión 5.0 y 5.1.2, como así también el DB2 UDB WorkGroupServer Edition versión 8.1.0 y el Tivoli Storage Manager versión 5.2.0

• Se ha realizado un detallado estudio del entorno de trabajo ScientificWorkPlace 2.5.0 para la escritura del libro correspondiente al informefinal.

• Se ha realizado un detallado estudio del software para el desarrollo delentorno aplicado, es decir el estudio del entorno Tivoli.

• Se ha realizado el desarrollo del entorno utilizando una aplicación webde otra persona, desarrollada para una aplicación de trabajo final.

• Se ha realizado el correspondiente testeo del entorno desarrollado, consituaciones distintas de backup y recuperación de datos.

vii

• Una vez finalizado el entorno administrado por Tivoli se realizó la gra-bación en DVD de todo el material correspondiente al trabajo final: unaversión de la aplicación utilizada, otra referente al libro en formato Latexy el PDF generado. También se icluyó los instaladores de los productosutilizados para el desarrollo, es decir DB2 UDB y WebSphere StudioApplication Developer y el Tivoli Storage Manager.

Objetivos Logrados

Se han alcanzado plenamente la totalidad de los objetivos planteados parael presente trabajo.

Organización del Informe Final

El informe final comprende un libro impreso y un DVD, además de unresúmen y de un resúmen extendido.

El libro impreso está organizado en tres partes, la primer parte esta com-puésta por los primeros siete capítulos, la cuál describe las tecnologías y con-ceptos más importantes relacionados con Tivoli; la segunda parte esta com-puéta por cinco capítulos desde el octavo hásta el décimo que describen lasfuncionalidades de Tivoli Storage Manager, y la tercer parte esta compuéstapor un ejemplo práctico y conclusiones.

A continuación se indica una breve descripción por capítulos:

• Capítulo 1: presenta una introducción al Tivoli Enterprise Data Ware-house y los conceptos relacionados con la inteligencia de negocio.

• Capítulo 2: describe el DB2 Data Warehouse Manager y su relación contivoli.

• Capítulo 3: presenta una descripción del Tivoli Storage Manager, losproductos que comprende y las mejoras introducidas respecto a la versiónanterior.

• Capítulo 4: describe el manejo de la infraestructura en una organizacióncompleja.

• Capítulo 5: resume los aspectos relacionados con la supervisión en tiem-po real.

• Capítulo 6: detalla el área de administación de reportes.

viii

• Capítulo 7: presenta los conseptos y tipos de patrones para e-business.

• Capítulo 8: señala los coponentes para una implementación Tivoli Sto-rage Manager.

• Capítulo 9: detalla las políticas de administración, para que sirven ycómo se las utilizan.

• Capítulo 10: describe cómo realizar la personalización de la base de datosy del log de recuperación del Storage Manager.

• Capítulo 11: detalla los comandos de configuración de los clientes TSM.

• Capítulo 12: presenta las distintas funciones de bachup y archivado delcliente.

• Capítulo 13: muestra una aplicación en el entorno Tivoli Storage Mana-ger.

• Capítulo 14: Describe las conclusiones obtenidas luego de la realizacióndel trabajo.

El DVD, adjunto al libro impreso, contiene lo siguiente:

• Instaladores del software utilizado.

• Resúmenes del trabajo realizado.

• Libro del informe final.

• Presentación para la defensa final.

• Copia de seguridad de la base de datos de la aplicación.

• Aplicación desarrollada.

Gerzel, Stella MarisLicenciatura en Sistemas de Información

Universidad Nacional del NordesteL.U.: 30418

Prof. Orientador: Mgter. La Red Martínez, David LuisProf. Orientador: Lic. Uribe, ValeriaCorrientes; 30 de Noviembre de 2007

Índice General

I Conceptos y Tecnologías 1

1 Introducción al Tivoli EDW 31.1 Contenido y Conceptos de Business Intelligence . . . . . . . . . 3

1.1.1 Business Intelligence . . . . . . . . . . . . . . . . . . . . 41.1.2 Aspectos de los Negocios Motivadores del BI . . . . . . 41.1.3 Términos Principales del B.I. . . . . . . . . . . . . . . . 61.1.4 Diferentes Implementaciones del B.I. . . . . . . . . . . . 111.1.5 Arquitectura y Procesos del Data Warehouse . . . . . . 17

1.2 DB2 Data Warehouse Manager . . . . . . . . . . . . . . . . . . 281.3 Tivoli Enterprise Data Warehouse . . . . . . . . . . . . . . . . 29

1.3.1 El Problema . . . . . . . . . . . . . . . . . . . . . . . . 291.3.2 La Solución . . . . . . . . . . . . . . . . . . . . . . . . . 321.3.3 Ventajas de Usar el Tivoli Enterprise Data Warehouse . 33

2 DB2 DW Manager 372.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.2 Componentes de Tivoli Enterprise Warehouse . . . . . . . . . . 37

2.2.1 Componentes Básicos . . . . . . . . . . . . . . . . . . . 382.2.2 Cómo se Organiza el Tivoli Enterprise Data Warehouse 40

2.3 Arquitectura del Tivoli Enterprise Data Warehouse . . . . . . . 412.3.1 Instalación en una Sola Máquina . . . . . . . . . . . . . 422.3.2 Instalación Distribuida . . . . . . . . . . . . . . . . . . . 422.3.3 Instalación Distribuida con los Agentes Remotos del Wa-

rehouse . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3 Descripción del Tivoli Storage Manager 473.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.2 Descripción del Tivoli Storage Manager V5.2. . . . . . . . . . . 47

3.2.1 Background (Segundo Plano) . . . . . . . . . . . . . . . 48

ix

x ÍNDICE GENERAL

3.2.2 Actualización del Grupo de Productos Tivoli StorageManager . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.2.3 Mejoras del LAN-free . . . . . . . . . . . . . . . . . . . 513.2.4 Mejoramiento del TSM del cliente . . . . . . . . . . . . 563.2.5 Mejoras del servidor TSM . . . . . . . . . . . . . . . . . 58

4 Manejo de la Infraestructura 614.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.2 Estructura Complejas de Capas de Servicios . . . . . . . . . . . 62

4.2.1 Administración de Aplicaciones de E-business . . . . . . 674.2.2 Arquitectura de Infraestructuras de Aplicaciones de E-

business . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.2.3 Productos Básicos Usados Para Facilitar Aplicaciones

de E-business . . . . . . . . . . . . . . . . . . . . . . . . 734.3 Administración de aplicaciones de e-business . . . . . . . . . . 774.4 Estructura del Producto Tivoli . . . . . . . . . . . . . . . . . . 794.5 Tivoli Monitoring for Web Infrastructure . . . . . . . . . . . . . 82

5 Supervisión en Tiempo Real 875.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.2 Utilización del Tivoli Business Systems Manager . . . . . . . . 87

5.2.1 Flujo de Eventos del Tivoli Business System . . . . . . . 885.2.2 Integración de la Configuración del Tivoli Business Sys-

tems Manager . . . . . . . . . . . . . . . . . . . . . . . . 905.2.3 Descubrimiento de Recursos . . . . . . . . . . . . . . . . 925.2.4 Utilización del Tivoli Business Systems Manager . . . . 93

6 Administración de Reportes 956.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956.2 Descripción del Tivoli Enterprise Data Warehouse . . . . . . . 95

6.2.1 TEDW Conceptos y Componentes . . . . . . . . . . . . 976.2.2 Monitoreo del Proceso de Flujo de Datos . . . . . . . . 101

7 Patrones Para el E-business 1057.1 Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

II Tivoli Storage Manager 111

8 Implementación del T.S.M. 1138.1 Descripción del Tivoli Storage Manager . . . . . . . . . . . . . 113

ÍNDICE GENERAL xi

8.1.1 Proteger Datos con el Tivoli Storage Manager . . . . . . 1138.1.2 Almacenamiento y Gestión de Datos . . . . . . . . . . . 1218.1.3 Licencia . . . . . . . . . . . . . . . . . . . . . . . . . . . 1258.1.4 Introducción al Escenario . . . . . . . . . . . . . . . . . 127

8.2 Instalación del Servidor y del Cliente . . . . . . . . . . . . . . . 1308.2.1 Instalación del Tivoli Storage Manager . . . . . . . . . . 1308.2.2 Archivos de Licencias . . . . . . . . . . . . . . . . . . . 1348.2.3 Instalar el Packs de Lenguaje . . . . . . . . . . . . . . . 1368.2.4 Instalación de los Drivers del Dispositivo . . . . . . . . 1368.2.5 Instalación del Cliente . . . . . . . . . . . . . . . . . . . 1378.2.6 Instalación y Configuración de una Libreria de Cinta

Adosada al Tivoli . . . . . . . . . . . . . . . . . . . . . . 1398.2.7 Trabajar con Medios . . . . . . . . . . . . . . . . . . . . 144

8.3 Manejo de Pool y Volúmenes . . . . . . . . . . . . . . . . . . . 1508.3.1 Pools de Almacenamiento, Jerarquías de Pool de Alma-

cenamiento y Volúmenes de Pool de Almacenamiento . 1508.3.2 Mover Datos . . . . . . . . . . . . . . . . . . . . . . . . 1588.3.3 Migración del Pool de Almacenamiento . . . . . . . . . 1618.3.4 Reclamación . . . . . . . . . . . . . . . . . . . . . . . . 1648.3.5 Colocación . . . . . . . . . . . . . . . . . . . . . . . . . 166

9 Políticas de Administración 1699.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1699.2 Como TSM Maneja Datos . . . . . . . . . . . . . . . . . . . . . 169

9.2.1 Políticas de Negocio Manejadas Centralmente . . . . . . 1699.3 Definir Políticas . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

9.3.1 Dominios de Políticas . . . . . . . . . . . . . . . . . . . 1719.3.2 Política por Defeto del Servidor . . . . . . . . . . . . . . 1739.3.3 Configuraiones de Polítias Por Defecto en el Dominio

STANDARD . . . . . . . . . . . . . . . . . . . . . . . . 1739.3.4 Opción Relacionada al Servidor: EXPINterval Hours . . 174

9.4 Conjunto de Políticas . . . . . . . . . . . . . . . . . . . . . . . 1759.4.1 Definición de un Nuevo Conjunto de Políticas . . . . . . 1759.4.2 Validar y Activar un Conjunto de Políticas . . . . . . . 176

9.5 Trabajar con Clases Administradoras . . . . . . . . . . . . . . . 1779.5.1 Cómo los Archivos son Destinados a la Clase Adminis-

tradora . . . . . . . . . . . . . . . . . . . . . . . . . . . 1779.5.2 Binding and Rebinding the Management Class . . . . . 1779.5.3 Clase Administradora Rebinding Para Versiones de Bac-

kup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

xii ÍNDICE GENERAL

9.5.4 Especificación de la Clase Administradora . . . . . . . . 1789.6 Trabajar con Grupos de Copia . . . . . . . . . . . . . . . . . . 179

9.6.1 Grupos de Copias . . . . . . . . . . . . . . . . . . . . . 1799.6.2 Utilización de la Línea de Comandos para Definir un

Backup del Grupo de Copia . . . . . . . . . . . . . . . . 1799.6.3 Administración del Storage Management Archive File . 181

9.7 Autoridad Administrativa . . . . . . . . . . . . . . . . . . . . . 1819.7.1 Clases de Privilegios . . . . . . . . . . . . . . . . . . . . 1819.7.2 Privilegio System . . . . . . . . . . . . . . . . . . . . . . 1819.7.3 Privilegio Storage . . . . . . . . . . . . . . . . . . . . . . 1849.7.4 Privilegio Policy . . . . . . . . . . . . . . . . . . . . . . 1869.7.5 Privilegio de Operator . . . . . . . . . . . . . . . . . . . 1879.7.6 Privilegio de Analyst . . . . . . . . . . . . . . . . . . . . 1889.7.7 Administrador de Nodo . . . . . . . . . . . . . . . . . . 188

9.8 Tipos de Interfaces Administrativas . . . . . . . . . . . . . . . . 1909.8.1 Interface Administrativa Web . . . . . . . . . . . . . . . 1909.8.2 Uso de la Linea de Comando en la Interface Adminis-

trativa Web . . . . . . . . . . . . . . . . . . . . . . . . . 1919.8.3 Interfaz Administrativa de Línea de Comando del Cliente1949.8.4 Linea de Comando del Comando Recall . . . . . . . . . 1949.8.5 Configuración de la Interfaz Administrativa Web . . . . 195

10 Personalización de la BD y del Log 19710.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19710.2 Propósito de la B.D y del Log . . . . . . . . . . . . . . . . . . . 197

10.2.1 Base de Datos y Log de Recuperación . . . . . . . . . . 19710.2.2 Transacciones . . . . . . . . . . . . . . . . . . . . . . . . 19910.2.3 Modos de Recuperación del Log de Transacción . . . . . 200

10.3 Asignación de Espacio . . . . . . . . . . . . . . . . . . . . . . . 20210.3.1 Asignación de Espacio de la Base de Datos y del Log de

Recuperación . . . . . . . . . . . . . . . . . . . . . . . . 20210.3.2 Espacio de la Base de Datos y del Log de Recuperación 203

10.4 Dimensionamiento de la Base de Datos y del Log de Recuperación20410.4.1 Estimación de Requerimientos de Espacio para la Base

de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 20410.4.2 Cached y Archivos del Pool de Almacenamiento de Copia20510.4.3 Sobrecarga . . . . . . . . . . . . . . . . . . . . . . . . . 20610.4.4 Estimación del Tamaño del Log de Recuperación . . . . 207

10.5 Agregar Espacio . . . . . . . . . . . . . . . . . . . . . . . . . . 20710.5.1 Crear Volúmenes Adicionales . . . . . . . . . . . . . . . 207

ÍNDICE GENERAL xiii

10.6 Reducir el Espacio de la Base de Datos y del Log de Recuperación20810.7 Mirroring (Espejado) . . . . . . . . . . . . . . . . . . . . . . . . 208

10.7.1 Mirroring de la Base de Datos y del Log de Recuperación20810.7.2 Ejemplos de Mirroring . . . . . . . . . . . . . . . . . . . 210

10.8 Parámetros BUFPOOLSIZE y LOGPOOLSIZE . . . . . . . . . 21110.9 Espacios Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . 212

10.9.1 DEFine SPACETrigger . . . . . . . . . . . . . . . . . . 212

11 Configuración del Cliente 21511.1 Interfaces de los Clientes . . . . . . . . . . . . . . . . . . . . . . 215

11.1.1 Identificar los Tipos de Clientes . . . . . . . . . . . . . . 21511.1.2 La Interface de Línea de Comando . . . . . . . . . . . . 21511.1.3 Utilización del Loop de la Interface de línea de Comando 21811.1.4 Interface Web del Cliente . . . . . . . . . . . . . . . . . 21811.1.5 La Interfáz GUI . . . . . . . . . . . . . . . . . . . . . . 219

11.2 Control de Acceso Administrativo . . . . . . . . . . . . . . . . 22111.2.1 Registración . . . . . . . . . . . . . . . . . . . . . . . . . 22111.2.2 Administración de Contraseñas . . . . . . . . . . . . . . 22111.2.3 Impedir a los Nodos Clientes el Acceso al Servidor . . . 22311.2.4 Opciones del Cliente . . . . . . . . . . . . . . . . . . . . 22511.2.5 El Editor Gráfico de Opciones . . . . . . . . . . . . . . 22611.2.6 Configuración del Acceso del Cliente al Servidor . . . . 22711.2.7 Identificar Preferencia de Opciones . . . . . . . . . . . . 229

11.3 Rendimiento y Opciones del Cliente . . . . . . . . . . . . . . . 23011.3.1 Opciones Disponibles del Cliente para Configurar y Pro-

porcionar Rendimiento . . . . . . . . . . . . . . . . . . . 23011.3.2 TXNGROUPMAX . . . . . . . . . . . . . . . . . . . . . 23111.3.3 Configurar las Opciones de Logging . . . . . . . . . . . 23111.3.4 Opciones del Cliente y del Servidor del TSM . . . . . . 23411.3.5 Conjunto de Opciones Cliente . . . . . . . . . . . . . . . 23611.3.6 Identificar el Valor del Conjunto de Opciones del Cliente 23611.3.7 Uso de la Opción FORCE . . . . . . . . . . . . . . . . . 23911.3.8 Identificar Archivos a Ser Incluidos o Excluido Desde el

Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . 24011.3.9 Procesamiento Incluir - Excluir . . . . . . . . . . . . . . 24011.3.10 Procesamiento Continuado del Incluir - Excluir . . . . . 24011.3.11 Excluir Directorios de Backup . . . . . . . . . . . . . . . 24211.3.12 Uso de Números de Sequencias en un Conjunto de Op-

ciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

xiv ÍNDICE GENERAL

11.3.13 Consultar, Eliminar o Actualizar un Conjunto de Op-ciones del Cliente . . . . . . . . . . . . . . . . . . . . . . 246

12 Backup y Archivado del Cliente 24912.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24912.2 Tipos de Backups Disponibles . . . . . . . . . . . . . . . . . . . 249

12.2.1 Tipos de Backups Disponibles Desde la GUI . . . . . . . 24912.2.2 Backup Incremental (Completo) y Basado en Journal . 25112.2.3 Backup Incremental por Fechas (Sólo Fechas) . . . . . . 25212.2.4 Backup Incremental (sin Journal) . . . . . . . . . . . . . 25412.2.5 Siempre Backup (Selectivo) de Backup . . . . . . . . . . 25612.2.6 Backup de Imagen Fotográfica . . . . . . . . . . . . . . 25612.2.7 Backup de Imagen (Windows 2000 y XP) . . . . . . . . 25712.2.8 Backup de Imagen Incremental (Sólo fecha) . . . . . . . 258

12.3 Realización de Backups del Cliente . . . . . . . . . . . . . . . . 25912.3.1 Uso del Backup - Archive de la GUI del TSM, Resguar-

dar Archivos Desde un Cliente . . . . . . . . . . . . . . 25912.3.2 Seleccionar Archivos y Realizar un Backup . . . . . . . 25912.3.3 Resultados de la Revisión del Backup . . . . . . . . . . 26112.3.4 Uso de la Función Find . . . . . . . . . . . . . . . . . . 26112.3.5 Resultados de un Filtro . . . . . . . . . . . . . . . . . . 26212.3.6 Función File Details . . . . . . . . . . . . . . . . . . . . 26312.3.7 Uso de la Función de Estimación . . . . . . . . . . . . . 26512.3.8 Seleccionar Siempre Backup Como Tipo de Backup . . . 265

12.4 Restaurar Archivos . . . . . . . . . . . . . . . . . . . . . . . . . 26712.4.1 Restaurar Archivos Usando la GUI . . . . . . . . . . . . 26812.4.2 Restaurar una Versión Específica de un Archivo . . . . . 26912.4.3 Modificar Opciones de Restauración . . . . . . . . . . . 26912.4.4 Mostrar Versiones Activas e Inactivas de un Archivo pa-

ra Restaurar . . . . . . . . . . . . . . . . . . . . . . . . 27112.4.5 Restauración a un Punto en el Tiempo . . . . . . . . . . 27212.4.6 Restauraciones Relanzables . . . . . . . . . . . . . . . . 272

12.5 Archivado y Recuperación . . . . . . . . . . . . . . . . . . . . . 27312.5.1 Archivar y Recuperar Usando la GUI . . . . . . . . . . 27312.5.2 Únicas Descripciones de Archivo . . . . . . . . . . . . . 27612.5.3 Paquetes de Archivado . . . . . . . . . . . . . . . . . . . 27612.5.4 Modificar Opciones de Archivado . . . . . . . . . . . . . 27612.5.5 Recuperación Usando la GUI . . . . . . . . . . . . . . . 27812.5.6 Recuperar Paquetes de Archivo Usando la GUI del Cliente279

ÍNDICE GENERAL xv

12.5.7 Opciones de Recuperación - Modificar las Opciones deRecuperación y de Colisión . . . . . . . . . . . . . . . . 279

12.6 Backups y Restauración . . . . . . . . . . . . . . . . . . . . . . 27912.6.1 Utilización de la Línea de Comandos para el Backup y

el Archivado . . . . . . . . . . . . . . . . . . . . . . . . 27912.6.2 Realizar un Backup Incremental con la Línea de Comandos27912.6.3 Ejemplos de Backup Selectivos . . . . . . . . . . . . . . 28212.6.4 Realizar Backup Incremental de Sólo un Directorio Es-

pecificado . . . . . . . . . . . . . . . . . . . . . . . . . . 28312.6.5 Uso del Comando Query Filespace . . . . . . . . . . . . 28312.6.6 Restaurar Archivos Resguardados Usando el Comando

de Restauración dsmc . . . . . . . . . . . . . . . . . . . 28412.6.7 Uso del Comando de Restauración dsmc con la Opción

PICK . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28612.6.8 Utilización del Comando dsmc restore con Superposición 28612.6.9 Uso de la Opción LATEST con el Comando dsmc restore 28612.6.10 Restaurar a una Nueva Posición Usando la Opción de

Restauración PRESERVEPATH . . . . . . . . . . . . . 29012.6.11 Uso del IFNEWER con el Comando dsmc restore . . . . 29112.6.12 Utilización de las Opciones PITDATE y PITTIME . . . 29112.6.13 Comandos de Restauración Reiniciable . . . . . . . . . . 29112.6.14 Línea de Comandos de Archivado y Recuperación . . . 29512.6.15 Archivado y Recuperación de Directorios . . . . . . . . 29712.6.16 Archivo y Recuperación de Directorios . . . . . . . . . . 29712.6.17 Línea de Comandos Retrieve . . . . . . . . . . . . . . . 297

III Ejemplo Práctico y Conclusiones 301

13 Entorno Tivoli Storage Manager 30313.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30313.2 Entornos de Administración . . . . . . . . . . . . . . . . . . . . 303

13.2.1 Consola Administrativa del Servidor del Tivoli StorageManager . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

13.2.2 Interface Administrativa Web . . . . . . . . . . . . . . . 30313.3 Manejo de Licencias . . . . . . . . . . . . . . . . . . . . . . . . 309

13.3.1 Comando Query LICense . . . . . . . . . . . . . . . . . 30913.3.2 Registración de un Archivo de Licencia . . . . . . . . . 311

13.4 Definición de Pool de Almacenamiento . . . . . . . . . . . . . . 31313.4.1 Comando Query . . . . . . . . . . . . . . . . . . . . . . 313

xvi ÍNDICE GENERAL

13.4.2 Consultas Desde la Interface Web . . . . . . . . . . . . . 31513.4.3 Definición de Volumenes de Backup . . . . . . . . . . . 31513.4.4 Comando q stg . . . . . . . . . . . . . . . . . . . . . . . 31713.4.5 Manejo de Estados de los Volúmenes de Pool de Alma-

cenamiento . . . . . . . . . . . . . . . . . . . . . . . . . 31713.4.6 Eliminación de Volúmenes . . . . . . . . . . . . . . . . . 31913.4.7 Utilización del Comando QUERY VOLUME . . . . . . 321

13.5 Políticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32413.5.1 Definición de un Dominio de Políticas Para Windows . . 32413.5.2 Definición de un Conjunto de Políticas . . . . . . . . . . 32413.5.3 Definición de una Clase Administradora . . . . . . . . . 32613.5.4 Activación de un Conjunto de Políticas . . . . . . . . . 326

13.6 Administradores . . . . . . . . . . . . . . . . . . . . . . . . . . 32913.6.1 Registración de Administradores . . . . . . . . . . . . . 32913.6.2 Consulta de Administradores Registrados . . . . . . . . 331

13.7 Listar los Detalles del Servidor . . . . . . . . . . . . . . . . . . 33113.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335

13.8.1 Vista de la Configuración de la Base de Datos y del Logde Recuperación . . . . . . . . . . . . . . . . . . . . . . 335

13.8.2 Incremento del Tamaño de la Base de Datos . . . . . . . 33913.9 Espejado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33913.10Nodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341

13.10.1 Consulta de Nodos Registrados . . . . . . . . . . . . . . 34113.10.2 Registración de Nodos . . . . . . . . . . . . . . . . . . . 341

13.11Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34513.11.1 Interface Gráfica de Usuario . . . . . . . . . . . . . . . . 34513.11.2 Backup Incremental (Complete) . . . . . . . . . . . . . 34513.11.3 Backup Selectivo . . . . . . . . . . . . . . . . . . . . . . 347

13.12Aplicación Web . . . . . . . . . . . . . . . . . . . . . . . . . . . 35313.12.1 Aplicación Web Desde el Navegador . . . . . . . . . . . 353

14 Conclusiones 35714.1 Líneas Futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . 357

Bibliografía 359

Índice de Materias 361

Índice de Figuras

1.1 Términos comunes de Business Intelligence. . . . . . . . . . . . 61.2 Drill-down. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3 Bases de datos operacionales e informativas. . . . . . . . . . . . 111.4 Implementación de Business Intelligence. . . . . . . . . . . . . 121.5 Tabla Resumen en OLTP . . . . . . . . . . . . . . . . . . . . . 131.6 Data Warehouse Limitado. . . . . . . . . . . . . . . . . . . . . 131.7 Data Mart de Dos Niveles . . . . . . . . . . . . . . . . . . . . . 151.8 Data Mart de Tres Niveles . . . . . . . . . . . . . . . . . . . . . 161.9 Componentes del Data Warehouse . . . . . . . . . . . . . . . . 171.10 Refinación de Datos. . . . . . . . . . . . . . . . . . . . . . . . . 201.11 Modelo Físico de la Base de Datos. . . . . . . . . . . . . . . . . 211.12 Modelo Lógico de la Base de Datos . . . . . . . . . . . . . . . . 221.13 Metadatos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.14 Fuentes de Datos Operacionales. . . . . . . . . . . . . . . . . . 241.15 Data Mart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261.16 Herramientas de Presentación y Análisis. . . . . . . . . . . . . . 271.17 DB2 DataWarehouse Manager. . . . . . . . . . . . . . . . . . . 301.18 Reporte sin Tivoli Enterprise Data Warehouse. . . . . . . . . . 311.19 Reporte con Tivoli Enterprise Data Warehouse. . . . . . . . . . 33

2.1 Componentes del Tivoli Enterprise Data Warehouse . . . . . . 382.2 Una Configuración Distribuida del Tivoli Data Warehouse. . . 432.3 Configuración Avanzada con Agentes Remotos del Warehouse. 46

3.1 Arquitectura de Transferecia de Datos del Cliente LAN-free . . 523.2 LAN-free to SANergy Managed Disks . . . . . . . . . . . . . . 54

4.1 Growing Infrastructural Complexity . . . . . . . . . . . . . . . 634.2 Capas de Servicios . . . . . . . . . . . . . . . . . . . . . . . . . 664.3 Infraestructura Típica de Aplicaciones de E-business . . . . . . 72

xvii

xviii ÍNDICE DE FIGURAS

4.4 Niveles de Servicios Específicos de la Solución de E-business . . 744.5 Estructura Razonable de una Solución de E-negocio . . . . . . 764.6 Infraestructura Típica de la Utilización de Aplicaciones de E-

business Administradas por Tivoli . . . . . . . . . . . . . . . . 784.7 Soluciones de Administración de Tivoli . . . . . . . . . . . . . . 804.8 Estructura del Funcionamiento de Productos de Disponibilidad

de Tivoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.1 Flujo de Eventos Para el Tivoli Business Systems Manager In-tegration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.1 Ambiente Típico de TEDW . . . . . . . . . . . . . . . . . . . . 986.2 ITM Para el Flujo de Datos de la Infraestructura Web . . . . . 102

7.1 Modelo del Patrón Activo Acordado . . . . . . . . . . . . . . . 109

8.1 Componentes de una Implementación Básica del Tivoli StorageManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

8.2 La Funcionalidad Backup-Restore Proporcionada por el TivoliStorage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

8.3 Provisión de Grandes Capacidades de Almacenamiento Median-te la Función Archive-Retrieve . . . . . . . . . . . . . . . . . . 119

8.4 Capacidades de Gestión del Administrador . . . . . . . . . . . 1208.5 Capacidades de Automatización . . . . . . . . . . . . . . . . . . 1218.6 Tipos de Medios de Almacenamiento . . . . . . . . . . . . . . . 1228.7 Licencia del Tivoli Storage Manager . . . . . . . . . . . . . . . 1268.8 Introducción al Escenario . . . . . . . . . . . . . . . . . . . . . 1278.9 Componenetes Básicos Instalados por el Tivoli Storage Manager 1338.10 Instalación y Configuración de una Libreria de Cinta . . . . . . 1398.11 Conectar la Librería . . . . . . . . . . . . . . . . . . . . . . . . 1418.12 Determinación de Números para Librerías con Múltiples Drives 1438.13 Preparación de Cartuchos de Cintas . . . . . . . . . . . . . . . 1458.14 Creación de Cintas Scratch . . . . . . . . . . . . . . . . . . . . 1488.15 Auditar una Librería . . . . . . . . . . . . . . . . . . . . . . . . 1498.16 Pools de Almacenamiento . . . . . . . . . . . . . . . . . . . . . 1508.17 Jerarquías del Pool de Almacenamiento . . . . . . . . . . . . . 1518.18 Clase de Dispositivos y Pool de Almacenamiento . . . . . . . . 1538.19 Destinación de Almacenamiento . . . . . . . . . . . . . . . . . . 1548.20 Movimiento Automático de Datos . . . . . . . . . . . . . . . . . 1608.21 Migración del Pool de Almacenamiento . . . . . . . . . . . . . 1628.22 Reclamación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

ÍNDICE DE FIGURAS xix

8.23 Colocación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

9.1 Políticas de Negocio Manejadas Centralmente . . . . . . . . . . 1709.2 Dominios de Políticas . . . . . . . . . . . . . . . . . . . . . . . 1729.3 Clases de Privilegios . . . . . . . . . . . . . . . . . . . . . . . . 1829.4 Privilegio System . . . . . . . . . . . . . . . . . . . . . . . . . . 1839.5 Privilegio Storage . . . . . . . . . . . . . . . . . . . . . . . . . . 1849.6 Privilegio Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 1869.7 Privilegio de Operator . . . . . . . . . . . . . . . . . . . . . . . 1879.8 Privilegio de Analyst . . . . . . . . . . . . . . . . . . . . . . . . 1889.9 Administrador de Nodo . . . . . . . . . . . . . . . . . . . . . . 1899.10 Formato Estándar del Resultado de la Pregunta . . . . . . . . . 1929.11 Formato Detallado del Resultado de la Pregunta . . . . . . . . 193

10.1 Base de Datos y Log de Recuperación . . . . . . . . . . . . . . 19810.2 Transacciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19910.3 Modos de Recuperación del Log de Transacción . . . . . . . . . 20110.4 Consideración del Espacio de la Base de Datos y del Log de

Recuperación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20310.5 Mirroring de la Base de Datos y del Log de Recuperación . . . 209

11.1 Tipos de Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . 21611.2 Interface de Línea de Comandos . . . . . . . . . . . . . . . . . 21711.3 Administración de Contraseñas . . . . . . . . . . . . . . . . . . 22211.4 Impedir a los Nodos Clientes el Acceso al Servidor . . . . . . . 22411.5 Opciones del Cliente . . . . . . . . . . . . . . . . . . . . . . . . 22511.6 Configuración del Acceso del Cliente al Servidor . . . . . . . . 22711.7 Opciones Disponibles del Cliente Para Generar y Proporcionar

Rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23211.8 TXNGROUPMAX . . . . . . . . . . . . . . . . . . . . . . . . . 23311.9 Opciones del Cliente y del Servidor del TSM . . . . . . . . . . 23511.10Conjunto de Opciones Cliente . . . . . . . . . . . . . . . . . . . 23711.11Identificar el Valor del Conjunto de Opciones del Cliente . . . . 23811.12Uso de la Opción FORCE . . . . . . . . . . . . . . . . . . . . . 23911.13Procesamiento Incluir - Excluir . . . . . . . . . . . . . . . . . . 24111.14Procesamiento Continuado del Incluir - Excluir . . . . . . . . . 24211.15Excluir Directorios de Backup . . . . . . . . . . . . . . . . . . . 24311.16Uso de Números de Sequencias en un Conjunto de Opciones . . 24511.17Consultar, Eliminar o Actualizar un Conjunto de Opciones del

Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

xx ÍNDICE DE FIGURAS

12.1 Tipos de Backups Disponibles Desde la GUI . . . . . . . . . . . 25012.2 Backup Incremental y Basado en Journal . . . . . . . . . . . . 25112.3 Backup Incremental por Fechas . . . . . . . . . . . . . . . . . . 25312.4 Backup Incremental (sin Journal) . . . . . . . . . . . . . . . . . 25512.5 Siempre Backup (Selectivo) de Backup . . . . . . . . . . . . . . 25612.6 Backup de Imagen Fotográfica . . . . . . . . . . . . . . . . . . . 25712.7 Uso del Backup-Archive de la GUI del TSM, Resguardar Ar-

chivos Desde un Cliente . . . . . . . . . . . . . . . . . . . . . . 25912.8 Seleccionar Archivos y Realizar un Backup . . . . . . . . . . . 26012.9 Resultados de la Revisión del Backup . . . . . . . . . . . . . . 26112.10Uso de la Función Find . . . . . . . . . . . . . . . . . . . . . . 26212.11Resultados de un Filtro . . . . . . . . . . . . . . . . . . . . . . 26312.12Función File Details . . . . . . . . . . . . . . . . . . . . . . . . 26412.13Seleccionar Siempre Backup Como Tipo de Backup . . . . . . . 26612.14Restaurar una Versión Específica de un Archivo . . . . . . . . . 26912.15Modificar Opciones de Restauración . . . . . . . . . . . . . . . 27012.16Mostrar Versiones Activas e Inactivas de un Archivo para Res-

taurar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27112.17Archivado y Recuperación . . . . . . . . . . . . . . . . . . . . . 27412.18Anular Opciones de Archivado . . . . . . . . . . . . . . . . . . 27712.19Recuperación Usando la GUI . . . . . . . . . . . . . . . . . . . 27812.20Modificar las Opciones de Recuperación y de Colisión . . . . . 28012.21Utilización de la Línea de Comandos para el Backup y el Ar-

chivado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28112.22Realizar un Backup Incremental con la Línea de Comandos . . 28212.23Realizar Backup Incremental de Sólo un Directorio Especificado 28312.24Uso del Comando Query Filespace . . . . . . . . . . . . . . . . 28412.25Restaurar Archivos Resguardados Usando el Comando de Res-

tauración dsmc . . . . . . . . . . . . . . . . . . . . . . . . . . . 28512.26Uso del Comando de Restauración dsmc con la Opción PICK . 28712.27Utilización del Comando dsmc restore con Superposición . . . . 28812.28Uso de la Opción LATEST con el Comando dsmc restore . . . 28912.29Restaurar a una Nueva Posición Usando la Opción de Restau-

ración PRESERVEPATH . . . . . . . . . . . . . . . . . . . . . 29012.30Uso del IFNEWER con el Comando dsmc restore . . . . . . . . 29212.31Utilización de las Opciones PITDATE y PITTIME . . . . . . . 29312.32Línea de Comandos de Archivado y Recuperación . . . . . . . . 296

13.1 Consola Administrativa del Servidor TSM . . . . . . . . . . . . 30413.2 Interface Administrativa Web . . . . . . . . . . . . . . . . . . . 305

ÍNDICE DE FIGURAS xxi

13.3 Acceso a la Interface Web Desde un Navegador Web . . . . . . 30613.4 Ingreso de Datos Para Acceder a la Administración Web . . . 30713.5 Comando set webauthtimeout . . . . . . . . . . . . . . . . . . 30813.6 Comando Query LICense . . . . . . . . . . . . . . . . . . . . . 30913.7 Resultado del Comando Query LICense . . . . . . . . . . . . . 31013.8 Registrar un Archivo de Licencia . . . . . . . . . . . . . . . . . 31113.9 Resultado de la Registración de un Archivo de Licencia . . . . 31213.10Comando Query . . . . . . . . . . . . . . . . . . . . . . . . . . 31313.11Configuración de Pool de Almacenamiento . . . . . . . . . . . . 31413.12Consultas Desde la Interface Web . . . . . . . . . . . . . . . . . 31513.13Definición de Volumenes de Backup . . . . . . . . . . . . . . . . 31613.14Comando q stg . . . . . . . . . . . . . . . . . . . . . . . . . . . 31713.15Resultado del Comando q stg . . . . . . . . . . . . . . . . . . . 31813.16Acceso de Sólo Lectura . . . . . . . . . . . . . . . . . . . . . . . 31913.17Acceso Completo a un Pool de Almacenamiento . . . . . . . . . 32013.18Eliminación de un volumen . . . . . . . . . . . . . . . . . . . . 32113.19Verificar si el Volumen Fue Eliminado . . . . . . . . . . . . . . 32213.20Comando QUERY VOLUME . . . . . . . . . . . . . . . . . . . 32313.21Definición de un Dominio de Políticas . . . . . . . . . . . . . . 32413.22Definición de un Conjunto de Políticas . . . . . . . . . . . . . . 32513.23Definición de una Clase Administradora . . . . . . . . . . . . . 32613.24Definición de una Clase Administradora Desde la Interface Web. 32713.25Activación de un Conjunto de Políticas . . . . . . . . . . . . . . 32813.26Registración de Administradores . . . . . . . . . . . . . . . . . 32913.27Registración de Administradores . . . . . . . . . . . . . . . . . 33013.28Consulta de Administradores . . . . . . . . . . . . . . . . . . . 33113.29Consultar Administradores Registrados . . . . . . . . . . . . . 33213.30Listado del Detalle del Servidor . . . . . . . . . . . . . . . . . . 33313.31Listado de los Detalles del Servidor . . . . . . . . . . . . . . . . 33413.32Vista de la Configuración de la Base de Datos y del Log de

Recuperación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33513.33Vista de la Configuración de la Base de Datos y del Log de

Recuperación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33613.34Vista de la Configuración de la Base de Datos . . . . . . . . . . 33713.35Vista de la Configuración del Log de Recuperación . . . . . . . 33813.36Incremento del Tamaño de la Base de Datos . . . . . . . . . . . 33913.37Definir un Volumen Espejado de la Base de Datos . . . . . . . 34013.38Consulta de Nodos Registrados . . . . . . . . . . . . . . . . . . 34113.39Consulta de Nodos Registrados . . . . . . . . . . . . . . . . . . 342

xxii ÍNDICE DE FIGURAS

13.40Registrar Nodo . . . . . . . . . . . . . . . . . . . . . . . . . . . 34313.41Registrar Nodo . . . . . . . . . . . . . . . . . . . . . . . . . . . 34413.42Interface Gráfica de Usuario . . . . . . . . . . . . . . . . . . . . 34513.43Backup Incremental Completo . . . . . . . . . . . . . . . . . . 34613.44Backup Incremental Completo . . . . . . . . . . . . . . . . . . 34713.45Bachup Incremental Completo . . . . . . . . . . . . . . . . . . 34813.46backup Incremental Completo. . . . . . . . . . . . . . . . . . . 34913.47Backup Incremental Completo . . . . . . . . . . . . . . . . . . 35013.48Backup Selectivo . . . . . . . . . . . . . . . . . . . . . . . . . . 35113.49Backup Selectivo . . . . . . . . . . . . . . . . . . . . . . . . . . 35213.50Aplicación Web . . . . . . . . . . . . . . . . . . . . . . . . . . . 35313.51Aplicación Web . . . . . . . . . . . . . . . . . . . . . . . . . . . 35413.52Aplicación Web . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

Parte I

Conceptos y Tecnologías

1

Capítulo 1

Introducción al TivoliEnterprise Data Warehouse

1.1 Contenido y Conceptos de Business Intelligence

Este capítulo proporciona una introducción a los conceptos, tecnologías, yproductos que comprenden el Tivoli Enterprise Data Warehouse. En el mismose desarrollarán aspectos tales como:

• Business Intelligence (BI ).

• Aspectos de los negocios motivadores del Business Inteligence.

• Términos principales de Business Inteligence.

• Diferentes implementaciones de Business Inteligence.

• Arquitectura y procesos del Data Warehouse.

• Data Warehouse Manager .

• Tivoli Enterprise Data Warehouse.

• Ventajas de usar el Tivoli Enterprise Data Warehouse.

3

4 CAPÍTULO 1. INTRODUCCIÓN AL TIVOLI EDW

1.1.1 Business Intelligence

La inteligencia de negocios (BI) no es un negocio como cualquiera. Se refierea tomar las mejores decisiones más rápidamente y fácilmente.

Todos los días los negocios recogen cantidades enormes de datos: Informa-ción sobre órdenes, inventarios, cuentas a pagar, transacciones de puntos deventas, y, por supuesto, clientes. Los negocios también adquieren datos, talescomo datos demográficos y listas de envíos, de fuentes exteriores. Desafortu-nadamente, basado en un examen reciente, el 93 % de los datos corporativosno se usa en el proceso de toma de decisión del negocio.

La consolidación y organización de los datos para mejores decisiones eco-nómicas pueden conducir a una ventaja competitiva, y aprender a descubriresas ventajas y apoyarse en ellas es lo que pretende el B.I.

La cantidad de datos de negocio aumenta exponencialmente. Se duplicacada dos a tres años. Más información significa más competitividad. En la erade explosión de la información, todos los ejecutivos, encargados, profesiona-les, y trabajadores necesitan poder tomar más rápido las mejores decisiones.Porque ahora, más que nunca, el tiempo es dinero.

Mucho más que una combinación de datos y tecnologías, BI ayuda a crearconocimientos desde el mundo de la información, obtener datos correctos,descubrir su potencial, y compartir el valor; BI transforma la información enconocimiento. BI es la aplicación de poner la información correcta en manosdel usuario correcto en el tiempo correcto para soportar el proceso de toma dedecisión.

1.1.2 Aspectos de los Negocios Motivadores del BI

Hay algunos aspectos motivadores del B.I ; uno es la necesidad de mejorar lafacilidad de aplicación y reducir los recursos requeridos para implementar yutilizar nuevas tecnologías de información.

Hay fuerzas motivadoras adicionales detrás de la inteligencia de negocio,por ejemplo:

i. La necesidad de aumentar ingresos, reducir costos, y compe-tir con más eficacia. Llegará el día en que los usuarios finalespodrán manejar y planear operaciones de negocio usando in-

1.1. CONTENIDO Y CONCEPTOS DE BUSINESS INTELLIGENCE 5

formes diferidos mensuales, y las organizaciones de IT tendránmeses para implementar nuevas aplicaciones. Actualmente lascompañías necesitan desplegar rápidamente sistemas de infor-mación, y proveer a los usuarios un acceso fácil y rápido ala información del negocio que refleje el ambiente rápidamen-te cambiante de los negocios. Los sistemas de inteligencia denegocio se enfocan hacia el acceso y entrega de información alusuario final, y proporcionan soluciones de negocio empaqueta-das además de soportar las tecnologías de información sofisti-cadas requeridas para el procesamiento diario de la informacióndel negocio.

ii. La necesidad de manejar y de modelar la complejidad actualdel ambiente de negocio. La fusión y desregulación corporati-vas significa que las compañías actualmente proveen y soportanuna gama más amplia de productos y de servicios a un públicomás amplio y diverso que antes. Entender el manejo del com-plejo ambiente de negocios y la maximización de la inversión,es cada vez más difícil. Los sistemas de inteligencia de nego-cios proporcionan más que mecanismos de respuestas básicas yde divulgación de la información, también ofrecen herramien-tas de análisis sofisticado de la misma y de descubrimiento dedicha información, que se diseñan para administrar y procesarla compleja información de negocios asociada actualmente conel ambiente de las empresas.

iii. La necesidad de reducir costos de IT y de propiciar el uso de in-formación de negocios corporativa. La inversión en los sistemasde IT es generalmente un porcentaje significativo de los costoscorporativos, siendo necesario no sólo reducir esta sobrecarga,sino también obtener el máximo beneficio de los sistemas deIT. Las nuevas tecnologías de información tales como las intra-nets corporativas, computación orientada al cliente, y suscrip-ción para la entrega de información ayudan a reducir los costosde despliegue de sistemas de BI al gran público, especialmen-te consumidores de información como ejecutivos y encargadosde negocios. Los sistemas de inteligencia de negocio tambiénamplían el alcance de la información que puede ser procesadapara incluir no solamente información operacional y datos delos almacenes de datos (Data Warehouse), sino también infor-mación manejada por los sistemas de oficina y los servidores


web corporativos.

1.1.3 Términos Principales del B.I.

Se explican seguidamente algunos términos principales que se relacionan conel B.I., que son fundamentales para entender los conceptos básicos del TivoliEnterprise Data Warehouse (ver fig. 1.1 de la pág. 6):

Figura 1.1: Términos comunes de Business Intelligence.

• Bases de Datos Operacionales:

Las bases de datos operacionales son bases de datos orientadas al detalledefinidas para resolver las necesidades de, ocasionalmente, los procesos muycomplejos en una compañía. Esta visión detallada se refleja en el arreglo de losdatos en la base de datos. Los datos se verifican frecuentemente para evitarredundancia y “mantenimiento doble” de datos.


Procesamiento Transaccional en Línea (OLTP):

OLTP describe la manera en que los datos son procesados por un usuariofinal o un sistema informático. Es orientado al detalle, y altamente repetitivocon cantidades masivas de actualizaciones y cambios de datos para el usuariofinal. También frecuentemente hace referencia al uso de computadoras paraprocesar las operaciones en curso de un negocio (las operaciones cotidianas).

Data Warehouse:

Un Data Warehouse es una base de datos donde se recogen los datos conel propósito de ser analizados. La característica definitoria de un Data Wa-rehouse es su propósito (para qué será utilizado). La mayoría de los datos serecogen para administrar los negocios diarios de las compañías. A este tipo dedatos se puede llamar datos operacionales. Los sistemas usados para recogerdatos operacionales se refieren como OLTP.

Un Data Warehouse recoge, organiza, y torna disponibles los datos con elpropósito de analizarlos ordenadamente para dar a la gerencia la capacidadde acceso y analizar la información sobre sus negocios. A este tipo de datosse puede llamar, datos informativos. Los sistemas que trabajaban con datosinformativos se refieren como proceso analítico en línea (OLAP).

“Un (Data) Warehouse es un conjunto de datos orientado al sujeto, varian-te en el tiempo, y no volátil, para soportar el proceso de toma de decisiones”.

Orientado al sujeto: Datos que brindan información acerca de un sujetoparticular, en vez de operaciones diarias de una compañía.

Integrado: Datos que se recopilan en el Data Warehouse desde unavariedad de fuentes y se combinan en un conjunto coherente.

Variante en el tiempo: Todos los datos en el Data Warehouse se iden-tifican con un período particular.

Data Mart:

Un Data Mart contiene un subconjunto de datos corporativos que son va-liosos para una unidad específica de negocio, un departamento, o un sistemaespecífico de los usuarios. Este subconjunto consiste de datos históricos, re-sumidos, y posiblemente detallados capturados de sistemas de tratamientotransaccional, o desde un Data Warehouse de la empresa. Es importante des-tacar que un Data Mart se define por el alcance funcional de sus usuarios, y no


por el tamaño de la base de datos del Data Mart. La mayoría de los Data Martimplican menos de 100 GB de datos; algunos son más grandes, sin embargo,se espera que como el uso de Data Mart aumenta, aumentarán rápidamentede tamaño.

Fuentes Externas de Datos:

Los datos externos son datos que no se pueden encontrar en los sistemasOLTP pero se requieren para mejorar la calidad de la información en el DataWarehouse.

Proceso Analítico en Línea (OLAP):

OLAP es una categoría de tecnología de software que permite a analistas,encargados, y ejecutivos lograr la comprensión profunda de los datos con accesorápido, constante, interactivo y a una amplia variedad de posibles vistas de lainformación que se ha transformado en información primitiva para reflejar ladimensionalidad verdadera de la empresa según lo entendido por el usuario.

La funcionalidad de OLAP es caracterizada por el soporte del análisismultidimensional dinámico consolidado de los datos de la empresa y por elanálisis y navegación del usuario final sobre los datos de la misma, incluyendo:

• Cálculos y modelación aplicado a través de dimensiones, con jerarquías,y/o a través de miembros de las jerarquías.

• Análisis de tendencias sobre series temporales.

• Separar en subconjuntos para la visión en la pantalla.

• Agrupar niveles más profundos de consolidación.

• Alcance niveles de detalle subyacentes en los datos.

• Rotación a las nuevas comparaciones dimensionales en el área de visión.

OLAP se implementa en modo cliente / servidor multiusos y ofrece consis-tentemente respuestas rápidas a las preguntas, sin importar tamaño y comple-jidad de la base de datos. OLAP ayuda al usuario a sintetizar la informaciónde la empresa mediante una visión comparativa, personalizada, así como conel análisis de datos históricos y proyectados en varios modelos de datos deltipo “qué-si”, “what-if”. Esto se alcanza con el uso de un Servidor OLAP.


Servidor OLAP:

Un servidor OLAP tiene alta capacidad, es un motor de manipulaciónde datos multiusuarios diseñado específicamente para soportar y operar enestructuras de datos multidimensionales.

Una estructura multidimensional se organiza de manera que los ítems dedatos son localizados y accedidos en base a la intersección de las dimensionesde los miembros (de las jerarquías) que definen el item. El diseño del servi-dor y la estructura de los datos se optimizan específicamente para la rápidarecuperación de la información en cualquier orientación, así como para cálcu-los rápidos y flexibles, y rápidas transformaciones de filas de datos en base arelaciones expresadas con fórmulas.

El servidor OLAP puede efectuar físicamente el almacenamiento de lainformación multidimensional procesada para brindar a los usuarios finalestiempos de respuesta consistentes y rápidos, o puede cargar sus estructuras dedatos en tiempo real desde bases de datos relacionales u otras, u ofrecer unaopción de ambas.

Dado el estado actual de la tecnología y el requerimiento del usuario finalpor tiempos de respuesta constantes y rápidos, representar los datos multidi-mensionales en el servidor OLAP es a menudo el método preferido.

Metadata:

Metadata es el tipo de información que describe los datos almacenados enuna base de datos e incluye información como:

— Una descripción de tablas y campos del Data Warehouse, incluyen-do tipos de datos y rango de valores aceptables.

— Una descripción similar de tablas y campos de las bases de datosfuente, con mapeamiento (equivalencias entre campos) de camposdesde la base de datos fuente al warehouse.

— Una descripción de cómo los datos han sido transformados, inclu-yendo fórmulas, formato, conversión del valor, y agregación deltiempo.

— Cualquier otra información que sea necesaria para soportar y ma-nejar la operación del Data Warehouse.

Drill-down:


Se puede definir al Drill-down como la capacidad para navegar a través dela información que sigue una estructura jerárquica. Un pequeño ejemplo semuestra en la fig. 1.2 de la pág. 10.

Figura 1.2: Drill-down.

Bases de Datos Operacionales Versus Informativas:

La diferencia principal entre las bases de datos operacionales e informativases la frecuencia de actualización:

• En las bases de datos operacionales un alto número de transaccionesocurre a cada hora. La base de datos es siempre actualizada, y repre-senta gráficamente la situación actual del negocio o, según lo referidocomúnmente, el punto en el tiempo.

• Las bases de datos informativas son generalmente estables durante unperiodo de tiempo y representan una situación en un punto específicoen el tiempo pasado, que se puede observar como datos históricos. Porejemplo, una carga a un Data Warehouse se hace generalmente durante lanoche. Este proceso de carga extrae todos los cambios y nuevos registrosdesde la base de datos operacional a la base de datos informativa. Esteproceso se puede considerar como una sola transacción que comienza


cuando el primer registro se extrae desde las bases de datos operacionalesy finaliza cuando se actualiza el último Data Mart en el Data Warehouse.

La fig. 1.3 de la pág. 11 muestra algunas diferencias entre las bases dedatos y los Data Warehouses.

Figura 1.3: Bases de datos operacionales e informativas.

Data Mining:

Minería de datos es el proceso de extracción de información válida, útil,previamente desconocida y comprensible, desde los datos, para usarla en latoma de decisiones de negocios.

Hay diversos enfoques que se pueden tomar para implementar una soluciónde Business Intelligence y para mostrar algunos conceptos básicos de un DataWarehouse.

1.1.4 Diferentes Implementaciones del B.I.

Diversos intentos se han hecho en el pasado para encontrar una manera con-veniente de resolver los requerimientos para el proceso analítico en línea.


La fig. 1.4 de la pág. 12 brinda una descripción de cuatros modelosimportantes para implementar un sistema de soporte de decisión.

Figura 1.4: Implementación de Business Intelligence.

Tabla Resumen:

Una tabla resumen en un sistema OLTP es la implementación más comúnque se incluye en muchos paquetes de software estándar. Generalmente estastablas resúmenes cubren solamente un cierto conjunto de requerimientos delos analistas de negocio. La fig. 1.5 de la pág. 13 muestra las ventajas y lasdesventajas de estas soluciones.

Datos de OLTP en Servidores Separados:

Los datos de OLTP se mueven a un servidor separado y no se realizancambios en la estructura de la base de datos. Esto refleja un primer paso parasacar la carga de trabajo desde el sistema OLTP a una máquina dedicadaseparada para OLAP.

Debido a que ninguna reestructuración de la base de datos ocurre, estasolución no podrá actualizar los cambios en un cierto plazo. Los cambios enel pasado no pueden ser reflejados en la base de datos porque los campos pararepresentar los cambios lentos en las dimensiones no existen. La fig. 1.6 de lapág. 13 muestra esta solución.


Figura 1.5: Tabla Resumen en OLTP

Figura 1.6: Data Warehouse Limitado.


La técnica de mover regularmente los datos originales de OLTP a un siste-ma dedicado para propósitos de reportes es un paso que se puede hacer paraevitar el impacto de consultas que demandan tiempos prolongados de proceso,en el sistema operacional.

Además de las ventajas en rendimiento, y las normas de seguridad puedenser manejadas muy fácilmente en esta arquitectura.

Las máquinas totalmente aisladas, eliminan cualquier interdependencia en-tre el análisis y la carga de trabajo operacional. El problema principal quepersistirá en esta arquitectura es el hecho de que la arquitectura de la base dedatos no se ha cambiado u optimizado para el rendimiento de las consultas,el nivel más detallado de información se copia sobre el servidor de análisisdedicado.

La carencia de tablas de resúmenes o de agregaciones dará lugar a consultasque requieren prolongados tiempos de proceso con un gran número de archivosy joins en cada requerimiento. Para construir una arquitectura de esta manera,la transferencia de archivo o FTP puede ser suficiente para algunas situaciones.

Data Mart Sencillo:

Un número creciente de usuarios están implementando Data Marts sencillospara lograr experiencia con data warehousing.

Estos Data Marts generalmente se implementan como una prueba (delconcepto) y crecen en un cierto plazo. “Un Data Warehouse tiene que serconstruido, no puede ser comprado!”. Este primer ladrillo en el Data Wa-rehouse debe mantenerse bajo control; muchos Data Marts sencillos crearíanuna pesadilla para su administración.

El modelo two-tiered (dos niveles) de crear un solo Data Mart en unamáquina dedicada incluye más preparación, planeamiento e inversión. La fig.1.7 de la pág. 15 muestra este enfoque.

Las principales ventajas de esta solución, comparada con otros modelos,está en el rendimiento, en los valores precalculados y agregados, en una mayorflexibilidad para agregar datos adicionales desde múltiples sistemas y aplica-ciones de OLTP, y en las mejores capacidades para almacenar datos históricos.

Se pueden agregar metadatos al Data Mart para incrementar la facilidad deuso y la navegación a través de la información en la base de datos informativa.


Figura 1.7: Data Mart de Dos Niveles

La implementación de un Data Mart aislado puede ser muy rápida mien-tras el alcance de la información que se incluirá en el Data Mart se limitaprecisamente a un número adecuado de elementos de datos.

El modelo three-tiered (tres niveles) del Data Warehouse, consiste en tresetapas de almacenamiento de datos en el sistema o sistemas. En la fig. 1.8 dela pág. 16 se muestra este enfoque:

1. Datos de OLTP en bases de datos operacionales.

2. Datos extraídos, detallados, desnormalizados, organizados en un Star-Join Schema para optimizar el rendimiento de las consultas.

3. Múltiples Data Marts agregados y precalculados para presentar los datosal usuario final.

Las características de este modelo son:

1. Data Marts departamentales para contener los datos en forma organiza-cional optimizada para peticiones específicas. Los nuevos requerimientos


Figura 1.8: Data Mart de Tres Niveles

generalmente precisan la creación de un nuevo Data Mart, pero no tie-nen ninguna otra influencia en los componentes ya existentes del DataWarehouse.

2. Los cambios históricos a lo largo del tiempo se pueden mantener en elData Warehouse.

3. Los metadatos son el componente principal para garantizar el éxito de es-ta arquitectura orientada a la facilidad de uso y al soporte de navegaciónpara los usuarios finales.

4. La depuración y transformación de los datos se implementa en un solopunto de la arquitectura.

5. Las tres diferentes etapas en la agregación y transformación de los datosofrecen la capacidad de realizar tareas de Data Mining en los datos ex-traídos, detallados, sin crear carga de trabajo en el sistema operacional.

6. La carga de trabajo creada por peticiones de análisis es totalmente des-cargada del sistema OLTP.

Nota 1.1 El Tivoli Enterprise Data Warehouse utiliza el enfoque three-tired(de tres niveles).


1.1.5 Arquitectura y Procesos del Data Warehouse

La fig. 1.9 de la pág. 17 muestra la arquitectura completa del Data Warehouseen una sola vista.

Figura 1.9: Componentes del Data Warehouse

Esta figura muestra las siguientes ideas:

(a) Los procesos requeridos para mantener el Data Warehouse actuali-zado como se indicó son extracción / propagación, transformación/ depuración, refinación de datos, presentación, y herramientas deanálisis.

(b) Las diferentes etapas de agregación en los datos son datos de OLTP,ODS Star-Join Schema, y Marts.

(c) Los metadatos, y cómo éstos están involucrados en cada proceso,se muestra con conectores sólidos.

La línea punteada horizontal en la figura separa las diferentes tareas endos grupos:


(a) Las tareas que se realizan en el sistema dedicado OLTP se optimizanpara el rendimiento interactivo y para manejar las tareas diarias delnegocio orientadas a la transacción.

(b) Las tareas que se realizan en la máquina dedicada al Data Ware-house requieren alto rendimiento batch para manejar las numerosastareas de agregación, precálculo y consultas.

Fuentes de Datos:

Las fuentes de datos pueden ser bases de datos operacionales, datos históri-cos (generalmente archivados en cintas), datos externos (por ejemplo, desdecompañías de estudio de mercado o desde Internet), o información desde elentorno ya existente del Data Warehouse.

Las fuentes de datos pueden ser bases de datos relacionales desde la línea deaplicaciones de negocio. Éstas también pueden residir en muchas plataformasdiferentes y pueden contener información estructurada, tal como tablas u hojasde cálculo, o información no estructurada, tal como archivos de texto plano ográficos y otra información multimedia.

Extracción / Propagación:

La extracción y propagación de los datos es el proceso de recolectar datosdesde varias fuentes y diferentes plataformas para moverlos al Data Warehouse.

La extracción de datos en un ambiente de Data Warehouse es un proce-so selectivo para importar la información relevante para la decisión al DataWarehouse.

La extracción y propagación de los datos es mucho más que reflejar o copiardatos desde un sistema de base de datos a otro. Dependiendo de la técnica,este proceso es:

1. Pulling (extracción) o.

2. Pushing (propagación).

Transformación / Depuración:

La transformación de datos implica generalmente la resolución de códigocon tablas de mapeamiento (por ejemplo, cambiando 0 al femenino y 1 al


masculino en el campo de género) y resolución de las reglas ocultas de negocioen los campos de datos, tales como números de cuenta.

También, la estructura y las relaciones entre los datos se ajustan al domi-nio del análisis. Las transformaciones ocurren a través del proceso de carga,generalmente en más de un paso. En las primeras etapas del proceso, lastransformaciones son más utilizadas para consolidar los datos desde diferentesfuentes, mientras que en las fases posteriores los datos son transformados parasatisfacer un problema y/o una herramienta específicos del análisis.

El Data Warehousing transforma datos en información; por otra parte, ladepuración asegura que el Data Warehouse tendrá información válida, útil, ysignificativa.

La depuración de datos se puede también describir como estandardizaciónde datos. Con la revisión cuidadosa del contenido de los datos, se equiparanlos siguientes criterios:

1. Nombres correctos del negocio y del cliente.

2. Direcciones correctas y válidas.

3. Números de teléfono usables e información de contacto.

4. Códigos y abreviaturas válidos de los datos.

5. Representación consistente y estándar de los datos.

6. Direcciones domésticas e internacionales.

7. Consolidación de los datos.

Refinación de los Datos:

La refinación de datos crea subconjuntos del Data Warehouse de la em-presa, que tienen un formato multidimensional o un formato de organizaciónrelacional para optimizar el rendimiento de OLAP. La fig. 1.10 de la pág. 20muestra dónde está situado este proceso dentro de la arquitectura completadel business inteligence (BI).

El nivel atómico de información desde el esquema estrella necesita ser agre-gado, resumido, y modificado para los requerimientos específicos. Este procesode refinación de datos genera los Data Marts que:


Figura 1.10: Refinación de Datos.

Crean un subconjunto de datos del esquema estrella.

Crean los campos calculados / campos virtuales.

Sumariza la información.

Agrega la información.

Esta capa en la arquitectura del Data Warehouse es necesaria para incre-mentar el rendimiento del query y reducir al mínimo la cantidad de datos quese transmitan sobre la red al usuario final del query o a la herramientas deanálisis.

Cuando se habla de transformación /ordenamiento de datos, básicamentese alcanzan los resultados de dos maneras diferentes. Éstas son:

Agregación de datos: Cambiar el nivel de granularidad en la informa-ción.

Ejemplo: Los datos originales se almacenan en una base diaria -eldata mart contiene solamente valores semanales-. Por lo tanto,la agregación de los datos resulta en menos registros.


Resumen de datos: Agregar hacia arriba los valores en un cierto grupode información.

Ejemplo: El proceso de ordenamiento de los datos genera registrosque contienen la entrada de un grupo de productos específicos,dando por resultado más registros.

Modelo Físico de la Base de Datos:

En BI, hablar sobre el modelo físico de los datos es hablar sobre modelosrelacionales o multidimensionales de datos. La fig. 1.11 de la pág. 21 muestrala diferencia entre esos dos modelos físicos de base de datos.

Figura 1.11: Modelo Físico de la Base de Datos.

Ambas arquitecturas de base de datos pueden ser seleccionadas para crearData Marts departamentales, pero la manera de tener acceso a los datos enlas bases de datos es diferente:

(a) Para tener acceso a datos desde una base de datos relacional,se pueden utilizar métodos de acceso comunes como el SQL oproductos de middleware como ODBC.

(b) Las bases de datos multidimensionales requieren APIs especia-lizados para tener acceso a la arquitectura de base de datosusualmente propietaria.


Modelo Lógico de la Base de Datos:

Además del modelo físico previamente mencionado de la base de datos,también hay cierto modelo lógico de base de datos.

Al hablar del BI, el modelo lógico más usado comúnmente de base dedatos es el Esquema de Star-Join. El Esquema de Star-Join consiste en doscomponentes, según lo mostrado en la fig. 1.12 de la pág. 22:

Figura 1.12: Modelo Lógico de la Base de Datos

1. Tablas de hechos.

2. Tablas de dimensiones.

Las siguientes son definiciones para los componentes del Esquema Star-Join:

Tablas de hechos: ¿Qué estamos midiendo?.

Las tablas de hechos contienen la información básica del nivel de tran-sacción del negocio que es de interés para una aplicación en particular. Enanálisis de marketing, por ejemplo, éstos son datos básicos de las transaccio-nes de ventas. Las tablas de hechos son grandes, frecuentemente almacenanmillones de filas, y principalmente numéricas.


Tablas de dimensión: ¿Por qué estamos midiendo?.

Las tablas de dimensión contienen información descriptiva y son pequeñasen comparación a las tablas de hechos. En una aplicación de análisis del mar-keting, por ejemplo, las tablas típicas de dimensión incluyen período, regióndel marketing, tipo de producto, etc.

Información de metadatos:

Los metadatos estructuran la información en el Data Warehouse en ca-tegorías, asuntos, grupos, jerarquías, etcétera. Se utiliza para proporcionarinformación sobre los datos dentro de un Data Warehouse, según lo dado enla siguiente lista y mostrado en la fig. 1.13 de la pág. 23:

Figura 1.13: Metadatos.

• Orientado al sujeto, basado en abstracciones de las entidades del mundoreal que interesan (proyecto, cliente, organización, etc.).

• Define la manera en la cual los datos deben ser transformados e inter-pretados, (5/9/99 = al 5 de septiembre de 1999 o 9 de mayo de 1999 -¿Británico o US?).

• Da información sobre datos relacionados en el Data Warehouse.


• Estima tiempos de repuestas, mostrando el número de los registros quese procesarán en un query.

• Almacena campos calculados y fórmulas precalculadas, para evitar inter-pretaciones equivocadas, y contiene cambios históricos de una vista.

La perspectiva del administrador del Data Warehouse del metadata es undepósito (repositorio) lleno y con documentación de todo el contenido y detodos los procesos en el Data Warehouse, mientras que, desde una perspectivade usuario final, el metadata es el roadmap (mapa de ruta) con la informaciónen el Data Warehouse.

Fuente de Datos Operacionales (ODS):

La fuente de Datos Operacionales (ver fig. 1.14 de la pág. 24), se puededefinir como un sistema actualizable de datos integrados usados para múltiplestomas de decisiones tácticas de la empresa.

Contiene los datos vivos, no “fotos”, y tiene una mínima historia que seconserva.

Figura 1.14: Fuentes de Datos Operacionales.

Algunas características del ODS:

• Es orientado al sujeto: Se diseña y organiza alrededor de los temas


principales de los datos de una compañía, tales como cliente o producto.No se organizan alrededor de aplicaciones o funciones específicas, talescomo entrada de órdenes o cuentas por cobrar.

• Es integrado: Representa una imagen colectivamente integrada de datosorientados a los sujetos, que se cargan desde potencialmente cualquiersistema operacional. Si el sujeto cliente es incluido, entonces toda lainformación del cliente en la empresa se considera como parte del ODS.

• Tiene valores actuales: Refleja el contenido actual de los sistemas fuen-te heredados. Actualmente se puede definir de diversas maneras paradiversos ODSs dependiendo de los requisitos de la implementación. UnODS no debe contener múltiples fotos de cualquier actualidad que se de-fina. Es decir, si actual significa un período de contabilización, entoncesel ODS no incluye más que un período de contabilización de datos. Lahistoria está archivada en el Data Warehouse para el análisis.

• Es volátil: Puesto que un ODS tiene valores actuales, está sujeto a cam-bios con una frecuencia que soporta la definición de actual. Es decir, esactualizado para reflejar los sistemas que lo alimentan en el verdaderosentido de OLTP. Por lo tanto, las query idénticas hechas en diferen-tes momentos arrojarán probablemente diferentes resultados porque losdatos han cambiado.

• Es detallado: La definición de detallado también depende del problemadel negocio que está solucionando el ODS. La granularidad de datos enel ODS puede o no ser igual que la de sus sistemas operacionales fuente.

Data Mart:

La fig. 1.15 de la pág. 26 muestra dónde los Data Marts se establecenlógicamente dentro de la arquitectura BI.

El propósito principal de un Data Mart puede ser definido como sigue:

1. Almacena la información pre-agregada.

2. Controla el acceso de usuarios finales a la información.

3. Provee rápido acceso a la información para necesidades analíticas espe-cíficas o grupos de usuario.


4. Representa la visión para usuarios finales y la interfaz de datos del DataWarehouse.

5. Crea una vista relacional / multidimensional de los datos.

6. Ofrece múltiple capacidades “slice-and-dice” (agrupamientos - zoom).

7. El formato de la base de datos puede ser multidimensional o relacional.

Figura 1.15: Data Mart.

Herramientas de Presentación y Análisis:

Desde la perspectiva del usuario final, la capa de presentación es el com-ponente más importante de la arquitectura BI mostrada en la fig. 1.16 de lapág. 27.

Para encontrar las herramientas adecuadas para los usuarios finales conrequerimientos de información, se puede hacer la suposición de que hay por lomenos cuatro categorías de usuario y la posibilidad de cualquier combinaciónde estas categorías:

1. Usuarios capacitados. Los usuarios que están dispuestos y capacitadospara manejar herramientas de análisis más o menos complejas para crear


Figura 1.16: Herramientas de Presentación y Análisis.

sus propios informes y análisis, tienen una comprensión de la estructuradel data warehouse y de las interdependencias de la organización de losdatos en el data warehouse.

2. Usuarios no frecuentes. Este grupo de usuario consiste en quienes noestán interesados en los detalles del data warehouse pero tienen necesi-dad de acceder a la información esporádicamente. Estos usuarios estánnormalmente implicados en el negocio cotidiano y no tienen el tiempoo la necesidad de trabajar extensivamente con la información del datawarehouse. Sus capacidades en el uso de las herramientas de análisis yreporte es limitado.

3. Usuarios que requieren información estática. Este grupo de usuario tie-ne un interés específico en la recuperación de números exacto definidosen un intervalo de tiempo dado, por ejemplo: “Se tiene que conseguir uninforme sumario todos los viernes a las 10:00 hs de la mañana como pre-paración para la reunión semanal y para propósitos de documentación”.

4. Usuarios que requieren capacidades de análisis y de consultas dinámi-cas o específicas. Típicamente, este es un analista de negocio. Toda lainformación en el Data Warehouse podría ser de importancia para esosusuarios, en algún momento dado. Su interés se relaciona con la disponi-


bilidad, funcionamiento, y capacidades de drill-down para slice-and-dicea través de los datos desde diferentes perspectivas en cualquier momento.

Diferentes tipos de usuarios necesitan diferentes herramientas front-end,pero todos pueden tener acceso a la misma arquitectura del Data Warehouse.También, los diferentes niveles de habilidad requieren diferente visualizaciónde los resultados, tal como gráficos para una presentación de alto nivel o tablaspara análisis adicional.

Nota 1.2 Tivoli Enterprise Data Warehouse trabaja en conjunto con DB2UDB y con el DB2 Warehouse Manager.

1.2 DB2 Data Warehouse Manager

La administración del Warehouse en DB2 se realiza con el DB2 UDB y el DB2DataWarehouse Manager. Proporciona una infraestructura de administracióndel Warehouse integrada, distribuida y heterogénea para, diseñar, construir,mantener, administrar, y tener acceso altamente escalable, Data Warehousesrobustos, almacenamientos de datos operacionales, y Data Marts almacenadosen bases de datos DB2 UDB.

El DB2 UDB y el DB2 DataWarehouse Manager ayudan a los administra-dores del Warehouse a:

1. Manejar grandes volúmenes de datos, para mover datos directamentedesde sus fuentes específicas (también permite el acceso empaquetadoy simplificado a los productos populares de empresas tales como SAPR/3), y para controlar los servidores en los cuales las transformacionesocurren con los agentes distribuidos del Warehouse.

2. Apresurar el despliegue del Warehouse y los Data Mart comúnmente usa-dos, realizar las transformaciones de datos previas a su carga y cálculosestadísticos.

3. Construir y administrar desde un punto central de control, integrado enDB2 UDB, utilizando la interfaz gráfica de usuario del Data WarehouseCenter.

1.3. TIVOLI ENTERPRISE DATA WAREHOUSE 29

El manejo del DB2 Warehouse consiste de:

Un cliente administrativo para definir y para manejar tareas de warehou-sing de datos y objetos, y operaciones de Warehouse o Data Mart: El DataWarehouse Center.

1. Un administrador para manejar y controlar el flujo de datos: El Ware-house server.

2. Agentes residentes en plataformas del servidor DB2 UDB (que podríaser también SUN, HP, etcétera) para realizar peticiones desde el ad-ministrador o el servidor del Warehouse: El agente Warehouse local oremoto.

3. Una base de datos de control del Warehouse que almacena los metadatosde administración del Warehouse en una base de datos DB2 UDB en unservidor UNIX o Intel.

4. Una herramienta de administración y publicación de metadatos con supropia interface gráfica de usuario (GUI): Information Catalog Managerpara manejar y presentar metadatos técnico y del negocio (organización).

Los diferentes componentes del DB2 DataWarehouse Manager se muestranen la fig. 1.17 de la pág. 30.

1.3 Tivoli Enterprise Data Warehouse

1.3.1 El Problema

Ha habido un problema inherente con la mayoría de las aplicaciones de ad-ministración. Las aplicaciones de administración recogen muchos datos de laempresa y los almacenan en bases de datos o archivos. Cada aplicación utilizasu propia base de datos, datos del balance, o archivos planos con sus propiosformatos diferentes.

Para cada aplicación se tiene que instalar un informe individual con unaherramienta de reporte. Esto da información sobre los datos recogidos por laaplicación individual, pero esto muestra solo parte de la historia. El análi-sis y correlación de datos desde diferentes aplicaciones en un informe resultaimposibles, o por lo menos difícil de lograr.


Figura 1.17: DB2 DataWarehouse Manager.

Esta discusión ha sido también en parte válida para las aplicaciones Tivoli,hasta la disponibilidad del Tivoli Data Warehouse.

Este problema se muestra en la fig. 1.18 de la pág. 31.

Tivoli primero intentó solucionar este problema introduciendo Tivoli De-cission Support pocos años atrás. Tivoli Decission Support había sido exitosopara una gran cantidad de usuarios y proporciona gran valor en ambientesde administración distribuida. Sin embargo, tiene algunas limitaciones en lassiguientes áreas:

(a) Flexibilidad: La flexibilidad en los tipos de informes y la aparienciay el significado de los informes es un requisito clave. Los datosdeberían ser “pluggable” (transferible, conectable) para cualquieraplicación de reporte (incluidas todas las herramientas OLAP).

(b) Adaptación: La habilidad de adaptar es también un factor crítico.El producto actual Tivoli Decision Support (TDS) trae gran valoragregado, pero muchos clientes desean modificar los datos y la clasede reportes que se puedan generar. Esta adaptación es un proce-so difícil con el TDS y hay una necesidad para proporcionar un


Figura 1.18: Reporte sin Tivoli Enterprise Data Warehouse.

ambiente donde la adaptación puede hacerse más fácilmente. Estoincluye el uso de datos desde múltiples aplicaciones de administra-ción, Tivoli y no Tivoli.

(c) Escalabilidad de la seguridad: El ambiente actual del TDS tam-bién tiene algunas limitaciones en el área de escabilidad (númerode usuarios capaces de revisar y modificar reportes al mismo tiem-po). Es también importante permitir a los clientes proporcionarseguridad relacionada con quién puede ver qué informes y qué da-tos relativos a qué área de la empresa. Por ejemplo, en un ambientede Service Provider, los clientes individuales deberían solamente sercapaz de ver los informes relacionados con los servicios que reciben.Esto también se aplica a empresas grandes donde los informes debenestar seguros en una división o una unidad de negocios básica.

(d) Disponibilidad Web: El interfaz actual del TDS está basada enWindows. Aunque proporciona alguna ayuda para publicar repor-tes HTML y es accesible mediante un navegador Web, esta facilidadno es todo la que podría ser. Los clientes quisieran tener acceso alos informes mediante un navegador estándar.


(e) Globalización: Hay algunas limitaciones en la capacidad del Natio-nal Language Support del TDS.

(f) Principios básicos de la administración de la aplicación: Las guíasTDS típicamente están armadas en una aplicación básica del ti-po aplicación-para-administración. Para tener capacidad de haceraplicaciones de reporte de alto valor, tales como administración delnivel de servicios o planeamiento de capacidad, es crítico podercorrelacionar datos a través de muchas aplicaciones de administra-ción.

1.3.2 La Solución

Tivoli Enterprise Data Warehouse está disponible para solucionar exactamenteeste problema y también superar las limitaciones del TDS.

El punto clave del Tivoli Enterprise Data Warehouse es que todos los datoshistóricos desde diferentes aplicaciones de administración están reunidos enuna base de datos centralizada, el Tivoli Data Warehouse. Los esquemas deesta base de datos son abiertos y publicados. Los sistemas de administración dedatos de aplicaciones de terceras partes también pueden integrarse fácilmente.

Esta nueva arquitectura se muestra en la fig. 1.19 de la pág. 33.

En el Tivoli Enterprise Data Warehouse, todos los datos son agregadosy correlacionados para el uso de reportes y herramientas de terceras partesOLAP y también para planeamiento, análisis, tendencia, contabilidad, y he-rramientas data mining.

Las aplicaciones del Tivoli Enterprise Data Warehouse también propor-cionan informes estándares estáticos usando una herramienta de reporte dela consola Web. En la versión 1 de Tivoli Enterprise Data Warehouse, sesoportan tres clases de reportes:

• Informe gráfico.

• Informe tabular.

• Medición versus tiempo.


Figura 1.19: Reporte con Tivoli Enterprise Data Warehouse.

1.3.3 Ventajas de Usar el Tivoli Enterprise Data Warehouse

Los usuarios pueden beneficiarse usando el Tivoli Enterprise Data Warehousede varias maneras, tales como:

• El Tivoli Enterprise Data Warehouse colecciona datos históricos desdemuchas aplicaciones Tivoli en un lugar central.

Tivoli Enterprise Data Warehouse colecciona los datos fundamentales so-bre los dispositivos de conexiones de red de los clientes, equipos de escritorio/ servidores, software de aplicación y los problemas y actividades que ha ge-nerado para manejar la infraestructura.

Esto le permite a los clientes construir una vista end-to-end (global) de suempresa y ver los componentes independientes de las aplicaciones específicasusadas para monitorear y controlar los recursos.

• El Tivoli Enterprise Data Warehouse agrega valor a los datos primitivos.


Tivoli Enterprise Data Warehouse realiza agregación de datos (por ej. dia-riamente o semanalmente) y permite al usuario restringir la cantidad de datosalmacenados en el depósito central de datos. Los datos son también depura-dos y consolidados para permitir modelos de datos del depósito central paracompartir dimensiones comunes.

Por ejemplo, Tivoli Enterprise Data Warehouse asegura que ahora, el nom-bre del host, y la dirección IP son las mismas dimensiones a través de todaslas aplicaciones.

• El Tivoli Enterprise Data Warehouse permite la correlación de informa-ción desde muchas aplicaciones Tivoli.

Tivoli Enterprise Data Warehouse también puede ser usado para generarvalor agregado correlacionando datos desde muchas aplicaciones Tivoli. Per-mite generar informes altamente complejos, con una total asociación de datosde distintas aplicaciones.

La primera aplicación de este tipo que utiliza el Tivoli Enterprise DataWarehouse es el Tivoli Service Level Advisor (TSLA). Usa y relaciona losdatos desde las siguientes aplicaciones para comprobar la conformidad con losniveles de servicios predefinidos:

Tivoli Enterprise Console.

Tivoli Distributed Monitoring.

Tivoli Web Services Manager.

Tivoli Application Performance Management.

Tivoli Business Systems Manager.

• El Tivoli Enterprise Data Warehouse usa interfaces probadas abiertas,para extraer, almacenar y compartir datos.

Tivoli Enterprise Data Warehouse puede extraer datos desde cualquieraplicación (Tivoli y no Tivoli) y almacenarlos en una base de datos central co-mún. La aplicación Tivoli Enterprise Data Warehouse también provee accesotransparente para soluciones de B.I. de terceras partes (el estándar CWM),


como IBM DB2 OLAP, Crystal Decisions, Cognos, Business Objects, BrioTechnology, y Microsoft OLAP Server. CWM es el estándar para CommonWarehouse Metadata, una especificación estándar de la industria para el in-tercambio de metadatos definida por el Object Management Group.

• El Tivoli Enterprise Data Warehouse provee un generador de reportesfront end (para usuario final) basado en la Web.

Llamado la Report Interface, pero la arquitectura abierta prevista por elTivoli Enterprise Data Warehouse permite otros front ends de B.I. que sonusados para acceso de los datos en el Warehouse central. El valor aquí esflexibilidad. Los clientes pueden usar la aplicación de informes a su elección,y no están limitados a cualquier aplicación.

• Todas las aplicaciones Tivoli proveerán informes estándar fuera del box.

Todas las aplicaciones Tivoli proveerán informes y planillas de informesestándar fuera del box, utilizando el warehouse central común del Tivoli En-terprise Data Warehouse. Estos informes proveerán información similar a lasuministrada por muchas guías actuales TDS. Como se mencionó anterior-mente, Tivoli también proveerá y desarrollará (como productos separados)un alto valor, aplicaciones de informes provenientes de diferentes productos oaplicaciones complejas como el Tivoli Service Level Advisor.

• El Tivoli Enterprise Data Warehouse provee un robusto mecanismo deseguridad.

Tivoli Enterprise Data Warehouse provee un robusto mecanismo de segu-ridad permitiendo construir los data marts con datos provenientes de subcon-juntos de recursos administrados.

Suministrando niveles de autorización de la base de datos para accedera esos data marts, Tivoli Enterprise Data Warehouse puede direccionar lamayoría de los requerimientos de seguridad relacionados con limitar el accesoa datos específicos a esos clientes/unidades de negocio que tienen una concretanecesidad de conocimiento.

• El Tivoli Enterprise Data Warehouse provee una arquitectura escalable.


Dado que Tivoli Enterprise Data Warehouse depende de tecnología proba-da y de estándares de la industria para sistemas de administración de basesde datos relacionales (RDBMS), provee una arquitectura escalable para alma-cenamiento y recuperación de datos.

Capítulo 2

DB2 Data WarehouseManager

2.1 Introducción

En este capítulo se desarrollará la arquitectura del Tivoli Enterprise DataWarehouse y cómo el modelo se adecua en la estructura general del DataWarehouse.

Este capítulo tiene las siguientes secciones:

1. Componentes del Tivoli Enterprise Data Warehouse.

2. Arquitectura del Tivoli Enterprise Data Warehouse.

3. Cómo las aplicaciones utilizan el Tivoli Enterprise Data Warehouse.

2.2 Componentes de Tivoli Enterprise Warehouse

En esta sección se introducirán los componentes básicos del Tivoli EnterpriseData Warehouse y se describirá brevemente su funcionalidad. Se explicarácómo la aplicación del Tivoli Enterprise Data Warehouse se estructura.

37

38 CAPÍTULO 2. DB2 DW MANAGER

2.2.1 Componentes Básicos

El Tivoli Enterprise Data Warehouse es una aplicación usada para recogery para manejar datos desde varias aplicaciones de administración de sistemaTivoli y no Tivoli. Los datos son importados desde la aplicación fuente, al-macenados centralmente, y luego procesados para adecuarse a las necesidadesde los usuarios finales. Aquí se describirán los componentes básicos del TivoliEnterprise Data Warehouse en el orden lógico del flujo de datos.

La fig. 2.1 de la pág. 38 muestra los componentes del Tivoli EnterpriseData Warehouse.

Figura 2.1: Componentes del Tivoli Enterprise Data Warehouse

El primer paso para introducir el Tivoli Enterprise Data Warehouse esdisponer de las aplicaciones fuente. Esto significa el abastecimiento de todaslas herramientas y arreglos necesarios para importar las fuentes de datos ope-racionales en el Data Warehouse central. Todos los componentes necesariospara esa tarea son recolectados en los llamados paquetes Warehouse para cadaaplicación fuente.

Las versiones futuras de todas las aplicaciones Tivoli serán “Tivoli Enter-

2.2. COMPONENTES DE TIVOLI ENTERPRISE WAREHOUSE 39

prise Data Warehouse-ready” (listas para Tivoli Enterprise Data Warehouse)y enviadas con sus paquetes del Warehouse.

Una porción importante de los paquetes del Warehouse son los programasETL. La abreviatura ETL es para extracción, transformación y carga de datos.En principio, el programa ETL procesa datos en tres pasos. Primero extraelos datos desde una fuente de datos. Después los datos son validados, trans-formados, agregados, y / o purificados de modo que cumplan con objetivo deformato y necesidades de los datos. Finalmente los datos se cargan en la basede datos específica.

En el Tivoli Enterprise Data Warehouse hay dos tipos de ETLs. El Ware-house central de los datos ETL toma los datos desde las aplicaciones fuentesy los carga en el Warehouse central de los datos (ver fig. 2.1 de la pág. 38).El Warehouse ETL central de los datos también se conoce como fuente ETLo ETL1. El segundo tipo de ETL es el data mart ETL.

El Warehouse central de los datos (CDW) es la base de datos que contienegrandes volúmenes de datos históricos de la empresa u organización (con lahora como la más baja granularidad). Este almacén de datos se optimiza parael almacenamiento eficiente de grandes cantidades de datos y tiene un formatodocumentado que hace los datos accesibles a muchas soluciones de análisis(software). La base de datos se organiza de una manera muy flexible, quepermite almacenar datos desde nuevas aplicaciones sin agregados o cambiosen las tablas.

El Data Mart ETL extrae un subconjunto de datos históricos desde el Wa-rehouse central de los datos el cual contiene los datos adaptados y optimizadospara un reporte específico o una tarea de análisis. Este subconjunto de da-tos es utilizado para crear los Data Marts. El data marts ETL es tambiénconocido como target (objetivo) ETL o ETL2.

Un Data Mart es un subconjunto de datos históricos que satisfacen lasnecesidades de un departamento, un equipo, o un cliente específico. Un DataMart es optimizado para el reporte interactivo o el análisis de datos. El for-mato de un Data Mart es específico a la herramienta de reporte o análisis quese planea utilizar. Cada aplicación que proporciona un Data Mart ETL creasus Data Marts en el formato apropiado.

Tivoli Enterprise Data Warehouse proporciona una Report Interface (RI)que crea reportes bidimensionales estáticos de los datos usando los Data Marts.El RI es una interfaz basada en una representación Web que puede ser accedida


con un simple navegador Web sin ningún software adicional instalado en elcliente. Se puede también utilizar otras herramientas para realizar análisisOLAP, reporte de inteligencia de negocio, o Data Mining.

El Control server es el sistema que contiene la base de datos de control quecontiene metadatos para el Tivoli Enterprise Data Warehouse y desde el cuálse maneja el Data Warehouse. El Control server controla las comunicacionesentre el Control server, el Data Warehouse central, el Data Marts, y la ReportInterface.

El Control server utiliza el Data Warehouse Center para definir los procesosETL y los esquemas estrella usados por los Data Marts. Se utiliza el DataWarehouse Center para programar, mantener, y monitorear estos procesos.

2.2.2 Cómo se Organiza el Tivoli Enterprise Data Warehouse

Al instalar la ayuda del Tivoli Enterprise Data Warehouse para el softwareTivoli, se recibe e instala dos porciones lógicas:

1. La aplicación principal Tivoli Enterprise Data Warehouse, que propor-ciona la infraestructura del Warehouse.

2. Uno o más paquetes Warehouse, que son aplicaciones que hacen uso dela infraestructura.

Tivoli Enterprise Data Warehouse

La aplicación principal Tivoli Enterprise Data Warehouse está empaqueta-da como un grupo de CDs que son proporcionados mediante cada producto desoftware de Tivoli que utilice su infraestructura. Se recibe un grupo diferentede CDs dependiendo del soporte que se ha ordenado para lenguajes SingleByte Carácter Set (SBCS) o lenguajes Double Byte Carácter Set (DBCS).

El grupo CD del Tivoli Enterprise Data Warehouse consiste de los siguien-tes CDs:

1. Tivoli Enterprise Data Warehouse: Los medios de instalación para laaplicación Tivoli Enterprise Data Warehouse.

2.3. ARQUITECTURA DEL TIVOLI ENTERPRISE DATA WAREHOUSE41

2. Tivoli Enterprise Data Warehouse Language Support: Los archivos ne-cesarios para utilizar el Tivoli Enterprise Data Warehouse en diferenteslenguajes. Este CD soporta los lenguajes SBCS y DBCS.

3. Tivoli Enterprise Data Warehouse Documentation: La librería de docu-mentación del Tivoli Enterprise Data Warehouse.

4. Un grupo de CDs de DB2: Éstos varían dependiendo de la versión quese solicita, la SBCS o DBCS del Tivoli Enterprise Data Warehouse.

Paquetes Warehouse

Un paquete Warehouse es la parte de un producto del software Tivolique proporciona funcionalidad de Warehouse. Puede ser proporcionado en elmedio de instalación del producto, en un CD separado, o en una colecciónde paquetes Warehouse. Cuando no se provee en un CD que contenga sólouno o más paquetes Warehouse, un paquete Warehouse está situado en unsubdirectorio llamado tedw_apps_etl.

2.3 Arquitectura del Tivoli Enterprise Data Ware-house

Los componentes básicos de la aplicación del Tivoli Enterprise Data Warehousese han introducido en las secciones anteriores. Ahora se verá las diferentes ar-quitecturas de una instalación Tivoli Enterprise Data Warehouse, por ejemplo,cómo los componentes se pueden instalar razonablemente en muchas máquinasy cómo trabajan conjuntamente.

Para consideraciones acerca de la arquitectura hay cuatro componentes delTivoli Enterprise Data Warehouse:

• Control server

• Central data warehouse

• Data marts

• Report Interface


Estos componentes pueden ser instalados en un sistema por un sistema deinstalación centralizado, o distribuirlo a través de cuatro sistemas en la empre-sa de IT. Los componentes del Tivoli Enterprise Data Warehouse pueden ser,pero no necesitan ser, instalado en los mismos sistemas como el otro softwareTivoli o en los sistemas donde residen los almacenamientos operacionales delos datos.

2.3.1 Instalación en una Sola Máquina

Se puede instalar todos los componentes del Tivoli Enterprise Data Warehouseen una sola máquina. Esta configuración es fácil para instalar y para mantener.Sin embargo, se recomienda esta configuración solamente para ambientes deprueba o demostración.

El Control server debería estar en una máquina Windows 2000 o WindowsNT. La configuración de una sóla máquina no puede ser instalada en un ser-vidor UNIX. Se pueden instalar todos los componentes del Tivoli EnterpriseData Warehouse en un solo paso. Antes de instalar el Tivoli Enterprise DataWarehouse hay que instalar primero en esa máquina el IBM DB2 UniversalDatabase Enterprise Edition.

2.3.2 Instalación Distribuida

Una instalación distribuida es recomendada para la mayoría de los sistemasde producción y para los clientes que ya ejecutan sus servidores de bases dedatos en los sistemas UNIX. Cada uno de los componentes mencionados ante-riormente del Tivoli Enterprise Data Warehouse puede estar en una máquinaseparada. Esta configuración se ilustra en el fig. 2.2 de la pág. 43.

El Control server es el sistema que contiene la base de datos de controlpara el Tivoli Enterprise Data Warehouse y desde el cuál se maneja el DataWarehouse. Los sistemas operativos soportados son Windows NT y Windows2000.

Antes de instalar el componente Tivoli Enterprise Data Warehouse en elControl server se debe instalar primero en esa máquina el IBM DB2 UniversalDatabase Enterprise Edition. El Control server utiliza el DB2 Server, el DataWarehouse Center, y el gestor del Warehouse.


Figura 2.2: Una Configuración Distribuida del Tivoli Data Warehouse.


El Data Warehouse Center en el Control server automatiza el procesamien-to del Data Warehouse. Se lo puede utilizar para definir los procesos ETL quemueven y transforman datos en el Data Warehouse central y los esquemas es-trella usados por los Data Marts. Entonces se puede utilizar Data WarehouseCenter para programar, mantener, y supervisar estos procesos. El gestor delWarehouse es una parte del DB2 Warehouse Manager. En esta configuración,el gestor del Warehouse funciona solamente en el Control server.

El sistema en el cual se instala el Control Server debe conectar a los al-macenamientos operacionales de los datos de la empresa, que potencialmenteresiden en otros sistemas y en base de datos relacionales fuera de DB2. Parapermitir al Control Server tener acceso a estas fuentes de datos, se debe ins-talar al cliente apropiado de la base de datos para cada fuente de datos en elControl server del sistema.

El servidor central del Data warehouse contiene solamente las bases dedatos DB2. En esta configuración ninguna parte del software del Tivoli Enter-prise Data Warehouse o los componentes del DB2 Warehouse son necesarios eneste servidor. Los sistemas operativos soportados son Windows NT, Windows2000, AIX, y Solaris.

Lo mismo es aplicable al servidor del Data Mart. Por esta razón, en unaconfiguración típica, el Data Warehouse central y los Data marts estarán enun servidor de base de datos.

El servidor del Report Interface (o servidor de Interface de Reporte) pro-porciona herramientas y una interfaz gráfica de usuario para crear y mostrarinformes que ayudan a analizar los datos en el Warehouse para responder alas preguntas que son importantes para el negocio. La Report Interface utilizaTivoli Presentation Services. Si ya está instalado en la organización, se debeinstalar el componente del Report Interface en el sistema que aloja al servidorpara la IBM Console.

La Report Interface requiere un cliente DB2 run-time (tiempo de ejecu-ción) para tener acceso a los datos en las instancias DB2 en el Data Warehousecentral, el Data Mart, y el Control Servers. Se debe instalar manualmente elproducto IBM DB2 antes de instalar el componente Report Interface. Cuandose instala el producto IBM DB2 desde los CDs suministrados con el Tivoli En-terprise Data Warehouse, alguno de los siguientes componentes son suficientes:

• DB2 Enterprise Edition


• DB2 Application Development Client

• DB2 Administration Client (este componente es el que utiliza el menorespacio en memoria).

Los sistemas operativos soportados para el servidor de Report son WindowsNT, Windows 2000, AIX, Solaris, y Linux. Su rendimiento es superado ensistemas Windows NT y Windows 2000.

2.3.3 Instalación Distribuida con los Agentes Remotos del Wa-rehouse

IBM DB2 Warehouse Manager proporciona los agentes del Warehouse que ma-nejan el flujo de datos entre los recursos fuentes del Warehouse y los targets(destinos de datos). Cuando se instala el Tivoli Enterprise Data WarehouseControl server, también se instala un agente del Warehouse. En algunos am-bientes, es suficiente utilizar un agente del Warehouse solamente en el Controlserver.

En otros ambientes, se podría mejorar el rendimiento del Tivoli EnterpriseData Warehouse si se coloca un agente Warehouse en el servidor del Warehousecentral de los datos y en el servidor del Data Mart. El Control server puedeutilizar estos agentes remotos del Warehouse para manejar el flujo de datos.Esta es una configuración avanzada.

La fig. 2.3 de la pág. 46 muestra el ejemplo de una configuración conagentes Warehouse remotos. En este ejemplo el Warehouse central de losdatos y los Data Marts están en un servidor.

Crear esta configuración avanzada requiere las siguientes tareas además delas que se realizan para la configuración básica:

1. Instalar el DB2 Warehouse Manager en los sistemas que transforman losservidores del Warehouse central de los datos y los servidores del DataMart.

2. Instalar los componentes del Warehouse central de los datos y del DataMart del Tivoli Enterprise Data Warehouse.

3. Configurar el daemon del agente del Warehouse en el servidor del Ware-house central de los datos y en el servidor del Data Mart.


Figura 2.3: Configuración Avanzada con Agentes Remotos del Warehouse.

Capítulo 3

Descripción del Tivoli StorageManager

3.1 Introducción

En este capítulo se dará una introducción básica del estilo de presentación a lasnuevas características proporcionadas por medio del Tivoli Storage ManagerV5.2.

3.2 Descripción del Tivoli Storage Manager V5.2.

Los tema que se desarrollarán son:

• Información de fondo que explica la estrategia del Tivoli Storage Mana-ger.

• Actualización del grupo de productos del Tivoli Storage Management.

• Tivoli Storage Manager Version 4.2 y V5.2:

— Ayuda y explotación de Windows 2000.

— Nuevas características y funciones para la explotación de latecnología SAN.

47

48 CAPÍTULO 3. DESCRIPCIÓN DEL TIVOLI STORAGE MANAGER

— Requerimientos especiales de backup y recuperación del backupbasado en journal.

— Características especiales para apoyar la reserva y la recupera-ción de datos sobre sistemas LAN-free.

— Realces de la utilidad del cliente y del servidor.

3.2.1 Background (Segundo Plano)

El grupo de productos es una solución orientada a la empresa que integra auto-máticamente backup de red, almacenamiento y recuperación, administracióndel almacenamiento y recuperación de desastres. El grupo de productos TivoliStorage Manager es ideal para los ambientes heterogéneos, y de datos inten-sivos; soportando a 35 plataformas y a 250 dispositivos de almacenamiento através de LANs, WANs y SANs, suministrando además protección para lasbases de datos y aplicaciones de e-mail.

Las mejoras de características para el servidor y el cliente explotan la tec-nología Storage Area Network (SAN) y responden a la necesidad de acelerar lasoperaciones de backup y restauración. Tivoli Storage Manager utiliza bibliote-cas compartidas SAN, dando a servidores múltiples la capacidad de compartiruna biblioteca automatizada en una configuración SAN de alto rendimien-to. La característica de transferencia de datos del cliente LAN-free reduce eltráfico de la red y mejora el ancho de banda haciendo copias de seguridad yrestaurando datos desde discos attachados SAN o cintas de almacenamiento.

Los productos utilizan el Tivoli Data Protection. Tivoli Storage Managerda soporte a la mayoría de las funciones administrativas de la empresa, de lasbase de datos, y de las aplicaciones de software de trabajo en grupo. El TivoliData Protection se comunica directamente con estas aplicaciones utilizando susinterfaces y utilidades certificadas de copias de seguridad (backup), asegurandouna solución completa para la administración del almacenamiento.

Versiones del Tivoli Storage Manager

Con el servidor del Tivoli Storage Manager Version 3.7.1, fue introducida lalibrería compartida de recursos de cintas SCSI. Los múltiples servidores TivoliStorage Manager pueden entonces compartir dinámicamente el volumen de labiblioteca y los recursos de manejo de cintas de una biblioteca de cintas física

3.2. DESCRIPCIÓN DEL TIVOLI STORAGE MANAGER V5.2. 49

conectada a un SAN. Los hosts mantienen así conexiones de alta velocidad alos mismos dispositivos en un SAN. AIX y Windows fueron agregados comonuevas plataformas de servidor del Tivoli Storage Manager que soporta lasolucion compartida de biblioteca de cintas SCSI. La biblioteca compartida decintas SCSI, está ahora soportada para IBM AIX, Microsoft Windows, y SunSolaris.

La restauración local de un grupo de backup, también llamado Rapid Re-covery, da al cliente la capacidad de restaurar todos o partes de los espacios dearchivos respaldados previamente al servidor TSM sin la transferencia de losdatos sobre la LAN. El soporte de cinta para el grupo de backup proporcionanuna solución eficiente para mover cantidades grandes de datos. Tivoli StorageManager Version 3.7.2 proporciona esta función en todas las plataformas delcliente excepto OS/390.

El Tivoli Storage Manager Version 3.7.2, provee una funcionalidad com-pleta y el soporte para backup de clientes para el S.O. Linux. El cliente Linuxes soportado para SuSE 6.3, RedHat 6.1, Caldera 2.3 y TurboLinux 6.0. LasAPI y las API multihilos también están soportadas. El método de comunica-ción soportado es TCP/IP.

El servidor del Tivoli Storage Manager Versión 3.7.3, explota muchas delas características arquitectónicas nuevas introducidas con la familia de pro-ductos del Microsoft Windows 2000 Server. El servidor Tivoli Storage Mana-ger introdujo mayor apoyo para el grupo de servidores de Microsoft, directorioactivo, servicios de terminal, manejo de almacenamiento removible, consolade administración de Microsoft e instalador de Microsoft Windows. El TivoliStorage Manager cliente tiene la habilidad de respaldar y procesar algunos deestos nuevos Windows 2000 System Objects.

Conectadas típicamente con el servidor de backup mediante un módem,las computadoras móviles y remotas pueden enviar sólamente cantidades pe-queñas de datos en un período razonable de tiempo. El Tivoli Storage Managerofrece una nueva facilidad adaptativa de backup de sub-archivos que proveesoporte a clientes móviles. Un backup del cliente que usa esta característicaenviará sólamente los octetos o los bloques cambiantes de un archivo al servi-dor, en vez del archivo entero. La característica está soportada en el clientede Windows 32-bit del Tivoli Storage Manager Version 5.2 y en todas lasversiones 5.2 para servidores. También, para mejorar la seguridad del backupde los datos sobre líneas telefónicas inseguras, el cliente Windows de la versión5.2 del Tivoli Storage Manager implementa una función de encriptación antes


de que los datos se envíen al servidor del Tivoli Storage Manager.

La transferencia LAN-free de los datos del cliente es una nueva caracte-rística del Tivoli Storage Manager Version 5.2 que permite que los clientesdel Tivoli Data Protection transfieran datos directamente a un dispositivo decinta attachado SAN. El API del cliente del Tivoli Storage Manager conjun-tamente con la mejora del Tivoli Storage Manager Server y un nuevo TivoliStorage Manager Storage Agent ha sido potenciado con la capacidad de gra-bar directamente al servidor propietario de los medios de almacenamiento decinta. El TDP para Microsoft Exchange y el TDP para R/3 tiene el soportede aplicaciones en el Tivoli Storage Manager Version 5.2.

El Tivoli Storage Manager Version 3.7.3 citado anteriormente ha sido me-jorado para proporcionar la explotación automatizada de la función de copiade EMC TimeFinder para el servidor de la base de datos Oracle. El procesode backup de una base de datos Oracle en una máquina Sun Solaris con unsubsistema del almacenamiento de EMC Symmetrix se puede ahora realizareficientemente en una copia de backup de los datos actuales de producción.Tivoli Data Protection for EMC Symmetrix realizara un backup completode una base de datos Oracle o SAP R/3 usando una base de datos Oracle.También se soportan el Veritas File System y Universal File System.

3.2.2 Actualización del Grupo de Productos Tivoli StorageManager

El producto Tivoli Storage Management cubre varios aspectos de la gestiónde la memoria dentro de una empresa. En general, el conjunto de productosse puede estructurar con las sigientes partes:

• El Tivoli Storage Manager, que proporciona la gestión troncal de la me-moria; mediante el agregado de funciones especiales de administraciónde la memoria (como la gestion de recuperación de desastres o la gestiónjerárquica de la memoria).

• Los productos Tivoli Data Production, que integran aplicaciones de ma-nejo de datos en el ambiente del Tivoli Storage Manager.

• Los productos Tivoli Ready, Productos Tivoli de socios de negocios queestán integrados y certificados para trabajar con el Tivoli Storage Ma-nager.


3.2.3 Mejoras del LAN-free

Un ejemplo de la infraestructura LAN-Free se muestra en la fig. 3.1, de lapág. 52.

Una Storage Area Network (SAN), es una red dedicada, usada para elmovimiento o el acceso de datos. Este tipo de red contrasta con la red deárea local típica (LAN), además del servicio de archivos, se utiliza para otrasfunciones de comunicación tales como e-mail, conexiones de terminales, y co-municaciones del programa de aplicación. La ventaja de una Storage AreaNetwork es aislar funciones de acceso a datos compartidos de otras funcionespara lograr rendimiento avanzado en almacenamiento compartido y extenderlas distancias disponibles como si fueran típicos archivos compartidos en red.

La topología del SAN facilita conexiones “cualquiera-a-cualquiera” y con-solidación entre los servidores y los sistemas de almacenamiento en un ambien-te de red. Las SANs disocian la propiedad de los recursos de almacenamientode los servidores. La arquitectura del SAN facilita la consolidación del alma-cenamiento, agrupamiento (clustering), alta disponibilidad, tolerancia a fallas,administración remota, y topologías flexibles. Esto puede ayudar a eliminarlas limitaciones de escalabilidad y de ancho de banda inherentes en muchos delos ambientes de hoy.

Un resumen de las facilidades soportadas por LAN-free se detallan a con-tinuación:

• El archivo de backup del cliente y el Tivoli Data Protection para aplica-ciones pueden desplegar toda la tecnología LAN-free.

• El backup de archivo de cliente de LAN-free es actualmente soportadoen AIX y Solaris. El backup a disco del LAN-free es soportado cuandose usa conjuntamente con la versión 2.2 del Tivoli SANergy.

• El LAN-free y la libreria compartida soportada por el IBM Magstar 3494comienza dasde el Tivoli Storage Manager Version 5.2.

Copia de Archivos LAN-free del Cliente

Antes de la aparición del Tivoli Storage Manager Version 5.2, el Storage Agentera el componente principal en la arquitectura LAN-free del Tivoli Storage Ma-


Figura 3.1: Arquitectura de Transferecia de Datos del Cliente LAN-free


nager. Es una versión ligera del servidor TSM se construye y se proporcionacomo un servicio local en la máquina del cliente TSM. El Storage Agent norequiere base de datos local o log de recuperación. Se comunica con el servidorTSM para obtener/guardar la información de la base de datos y coordinar vo-lumen de acceso y dispositivo usando conexion servidor-a-servidor. El clientese comunica con el Storage Agent cuando necesita tener acceso a un volumenen el camino (path) LAN-free, si hay una desconexión en las comunicacionesentre el cliente y el Storage Agent, el cliente en cambio procurará conectarsedirectamente con el servidor TSM y proceder al movimiento de los datos sobrela LAN. Fig. 3.2, de la pág. 54.

En la versión 5.2 del Tivoli Storage Manager en el backup de archivo delcliente, hay también un mejoramiento para el restore no solicitado. En lanueva sesión dual de restore no solicitado, como el nombre implica, el clientepuede tener dos sesiones de restauración - una sesión que restaura objetosdirectamente en el path de la LAN desde el servidor TSM y otra sesión querestaura objetos en el path del LAN-free a través del Storage Agent.

Explotación del SANergy

Antes de la versión 5.2 del Tivoli Storage Manager, el backup LAN-free fuesoportado solamente en los dispositivos de cinta, es decir, el Storage Agentpodría escribir solamente directamente a un dispositivo de cinta en la StorageArea Network. El soporte de LAN-free ahora se ha extendido al disco cuandoes utilizada conjuntamente con la versión 2.2 de Tivoli SANergy. SANergyprovee facilidades para compartir archivos de discos heterogéneos, es decir, elcompartir los volúmenes de disco entre los hosts de múltiples sistemas opera-tivos.

Tivoli SANergy autoriza al servidor del Tivoli Storage Manager para com-partir sus volúmenes de la biblioteca de archivos con los clientes del TivoliStorage Manager. Los clientes, por medio del Storage Agent, escriben direc-tamente al volumen de la biblioteca sobre el Storage Area Network. Sólo unarchivo de meta-datos se transfiere sobre la LAN al servidorTSM.

Los principales objetivos son explotar las tecnologías de archivos compar-tidos del SANergy en ambientes de Tivoli Storage Manager y bajar la cargade tráfico en la LAN.


Figura 3.2: LAN-free to SANergy Managed Disks


Utilización del modelo 3494

La biblioteca de cintas de la IBM Magstar 3494 es una biblioteca modular,flexible, escalable y automatizada diseñada para resolver desafíos del procesodiario de cinta.

La biblioteca de cintas de la IBM Magstar 3494 no requiere la bibliotecade cintas de soporte compartido del Tivoli Storage Manager. Tiene su propiacapacidad nativa de compartir recursos mediante la asignación de diferentescódigos de categoría de volumen a los volúmenes de las bibliotecas de losdiferentes host.

Sin embargo, esta capacidad compartida nativa no permite comparticiondinámica de los volúmenes de cinta. En la terminología de Tivoli StorageManager, significa que cada servidor TSM que comparte la biblioteca de cin-tas tendrá códigos únicos de categorías pre-asignados para sus cintas scratch(cintas no protegidas que se pueden regrabar) y privadas.

Además de esto, las características compartidas nativas no tienen ningúnservidor de control para controlar y para serializar el acceso hacia los drivers.Las alocaciones (direcciones) de las unidades (drives) trabajan cooperativa-mente en un nivel par - a - par. Como resultado de ello, se puede estar anteun problema de falla en la adquisición de una unidad (drive) si el TSM in-tenta hacer un back up desde una IBM Magstar 3494 cuando otra aplicacónestá usando dicho drive. El problema es manejado en Tivoli Storage ManagerVersión 3.7.3 con maneras mejoradas de cambiar las operaciones de direccio-namiento del punto de montaje y el volumen con el que se trabaja.

Las características compartidas de la biblioteca del Tivoli Storage Ma-nager aparecieron primero en la versión 3.7 del Tivoli Storage Manager. Laimplementación inicial solamente soportaba bibliotecas de cintas de tecnologíaSCSI que utilizan comandos de SCSI para controlar la biblioteca robótica yel manejo de las cinta. La biblioteca de cintas de la IBM Magstar 3494 no seincluye en el soporte porque tiene su propio administrador de biblioteca y noentiende los comandos de SCSI para el control de la biblioteca. Similarmente,el soporte LAN-free en la versión 4.1 del Tivoli Storage Manager no incluye labiblioteca de la IBM Magstar 3494 porque el Storage Agent no puede escribirdirectamente al dispositivo de cintas 3494 en una Storage Area Network.

Con la versión 4.2 del Tivoli Storage Manager, las características compar-tidas de la biblioteca y el soporte LAN-free ahora se ha extendido para incluir


a la IBM Magstar 3494. Con las características de la biblioteca compartidadel Tivoli Storage Manager, compartir dinámicamente los volúmnes es posibledebido a que el servidor de Tivoli Storage Manager se dedica a hacer la ges-tión de la librería incluyendo los puntos de control para el acceso serializadoa las unidades, el control de propietario de los volúmenes de la biblioteca y elseguimiento de la ubicación de los volúmenes.

3.2.4 Mejoramiento del TSM del cliente

En esta sección se detallan las nuevas características y cambios a las funcionesexistentes del cliente:

• Backup basado en Journal.

• Client Acceptor Daemon y Scheduler Service.

• Objetos del Sistema.

• Cifrado.

Backup basado en Journal

Hasta la versión 5.2 del TSM, uno de los cuellos de botella para algunosbackups era que el archivo de backup del cliente TSM debía recibir una listade todos sus archivos desde el servidor TSM. El cliente de TSM entoncesprocesaría esta lista, comparando todos los archivos que el servidor de TSMenvió, con los archivos que el archivo de backup del cliente de TSM tenía ensus sistemas de ficheros locales. El archivo de backups del cliente de TSMentonces decidiría qué archivos habían cambiado y qué archivos ya no estánen el sistema de ficheros del archivo de backups del cliente. Una vez que estalista hubiera sido procesada totalmente, enviaría una lista reducida de archivosal servidor de TSM, junto con los datos. Esta contiene todos los archivos quese han eliminado con la implementación del backup basado en journal.

Actualmente, solamente el archivo de backup del cliente en Microsoft Win-dows NT y Windows 2000 tiene la facilidad para crear y mantener una listade todos los archivos que se han cambiado o se han suprimido desde el backupincremental pasado.


Esta nueva forma de backup, en la mayoría de las circunstancias, mejorarávelocidad de backup y reducirá el tiempo requerido para el proceso completo.

Client Acceptor Daemon y Scheduler Service

Antes del TSM V5.2, algunos clientes, en particular clientes de Netware, ex-perimentaban problemas de escasez de memoria. En algunos casos, esto fueligado al Scheduler Service (servicio del planificador) que no liberaba memoriadespués de ejecutarse.

La solución al problema es utilizar al Client Acceptor Daemon (DemonioAceptador del Cliente) para iniciar el planificador de servicio para no dejarla memoria ocupada después de que se haya comenzado el planificador. Eluso del Client Acceptor Daemon para el servicio del planificador se puedeinvocar usando la opción de MANAGEDSERVICES. Se debe fijar la opcióncomo MANAGEDSERVICES=SCHEDULER en las opciones del archivo delcliente.

Objetos del Sistema

TSM soporta consultas y restauraciones de Objetos del Sistema inactivos me-diante la interface de línea de comandos. Se puede restaurar Objetos delSistema apuntándolos en tiempo de restauración.

La línea de comando se puede utilizar para restaurar los archivos indivi-duales o el System Object como un solo objeto.

En TSM V5.2, la clase de administración por defecto fue asignada duranteel backup de Windows 2000 System Objects; no había manera de asignar unaclase de administración diferente. Ahora, sin embargo, hay una manera deasignar los System Objects a una clase específica de administración.

En el registro del Windows 2000 hay una lista de los archivos de los queno se debe extraer copia de seguridad. Estos archivos se excluyen del procesode backup.


Encriptación

Hay dos nuevas características relacionadas a contraseñas para los clientes deTSM V5.2:

• Cifrado para UNIX y archivo de backup de clientes de Netware.

• Nuevo archivo de contraseña: tsm.pwd

Con el Tivoli Storage Manager V5., el soporte fue introducido para elcifrado de los datos del archivo de backup del cliente de Windows que eranenviados al servidor TSM. Ahora, con el Tivoli Storage Manager V5.2, estafunción se ha extendido a los clientes de UNIX y de Netware. El clientede UNIX requiere la autorización de TSM. Como antes, la encriptación seinvoca usando la opción de inclusión/exclusión de encriptación en el archivode opciones del cliente.

También, debido a la proliferación de las contraseñas del cliente (por ejem-plo, contraseña del servidor TSM, contraseñas de cifrado), éstas ahora se hanincorporado en un archivo en el cliente para facilitar su administración. Estaes una caracteristisa de auto- migración para moverse desde las viejas contra-señas al nuevo archivo de contraseña en TSM V5.2.

3.2.5 Mejoras del servidor TSM

El Tivoli Storage Manager Version 5.2 introduce varias mejoras del servidoren todas las plataformas del servidor Versión 5.2. Estas mejoras del servidory las mejoras específicas para TSM para HP-UX se discuten en esta sección.

Mejoras del servidor TSM

Las siguientes nuevas características están en todas las plataformas del servidorTSM Versión 5.2:

• El tamaño máximo del log de la base de datos del Tivoli Storage Ma-nager ahora es 13 GB. Este tamaño más grande mejora el escalabilidaddel servidor del Tivoli Storage Manager proporcionando más flexibilidad


para planificar los backups de la base de datos del Tivoli Storage Mana-ger. Sin embargo, el aumento significativo del tamaño de la recuperaciónpuede también aumentar el tiempo de arranque del servidor TSM, y elde copiar y restaurar la base de datos.

• El reporte del contexto del mensaje se puede facilitar con el comandoSET CONTEXTmessaging. Cuando se habilita el reporte del contexto delmensaje, los detalles adicionales del mensaje informativo se hacen dis-ponibles cuando el servidor emite el mensajes ANR9999D.

• El comando MOVE DATA se puede ahora utilizar para recuperar el espaciono utilizado para volúmenes de acceso secuencial especificados del alma-cenamiento. El espacio vacío se puede acumular dentro de los archivosagregados mientras que los archivos se suprimen de un servidor TivoliStorage Manager.

• Al operar con clientes de Tivoli Storage Manager Version 5.2 WindowsNT y Windows 2000, los servidores Tivoli Storage Manager Version 5.2soportan la página de codigo Unicode para archivo, directorio, y nombresdel espacio de archivo.

Unicode habilitado del espacio del archivo del cliente

Éstas son las características del Unicode habilitado del espaco del archivo delcliente:

• Unicode es una codificación universal estándar de caracteres que soportael intercambio, el procesamiento, y la exhibición del texto que se escribeen cualesquiera de los idiomas del mundo moderno. Los objetos copiadoso archivados con un Unicode habilitado del cliente pueden ser restauradoso recuperados con un Unicode habilitado del cliente en el mismo o enotro entorno de lenguaje soportado.

• Los clientes de TSM V5.2 Windows NT y Windows 2000 son los primerosclientes TSM con Unicode habilitado. El soporte de Unicode habilitadoen el espacio de archivos requiere que migrar el servidor TSM y el clienteTSM a TSM V5.2.

• Los nuevos clientes con Unicode habilitado que no tienen datos almace-nados en el servidor automáticamente almacenan los datos en el espacio


de archivos Unicode habilitado. Los clientes Unicode habilitados quetienen ya datos almacenados en el servidor almacenarán cualquier nuevoespacio de archivos según el Unicode habilitado.

Capítulo 4

Manejo de la Infraestructuradel E-business

4.1 Introducción

Tivoli Monitoring para la Web Infrastructure es una de una familia de solucio-nes basadas en el producto Tivoli Monitoring. Tivoli Monitoring se desarrollópara el producto Tivoli Distributed Monitoring. Con su nueva arquitecturabasada en modelo de recursos, Tivoli Monitoring proporciona una base sólidapara el desarrollo de las soluciones de administración que tratan las complejasnecesidades actuales en las infraestructuras de IT (Tecnologías de la Informa-ción). Un conjunto de componentes de análisis proactivos (PACs) construidosen la cima de Tivoli Monitoring proporciona un sistema comprensivo de so-luciones para las compañías que hacen frente a los desafíos generados por ele-business. Este PACs generalmente incluye:

• Tivoli Monitoring para las Aplicaciones.

• Tivoli Monitoring para la Integración del Negocio.

• Tivoli Monitoring para las Bases de Datos.

• Tivoli Monitoring para la Mensajería y la Colaboración.

• Tivoli Monitoring para la Infraestructura de la Web.

61

62 CAPÍTULO 4. MANEJO DE LA INFRAESTRUCTURA

Tivoli Monitoring para la Infraestructura de la Web incluye componentesproactivos del análisis para los servidores HTTP más comunes: IBM HTTPServer, Microsoft Internet Information Server (IIS), y Sun iPlanet Server, asícomo los componentes para IBM WebSphere Application Server (WAS). Com-binados, estos componentes ayudarán a asegurar la disponibilidad y la perfor-mance de las aplicaciones críticas en un ambiente de e-business.

Las capacidades del PACs incluyen:

1. Auto-descubrimiento de los recursos que se supervisarán.

2. Identificación del problema, notificación y corrección.

3. Mejores prácticas automatizadas para administración y operaciones.

4. Reporte histórico a través de un data warehouse centralizado.

Tivoli Monitoring para la Infraestructura Web proporciona capacidadesmejoradas para los productos anteriores, Tivoli Manager for WebSphere Ap-plication Server 1.1, además de las capacidades completamente nuevas rela-cionadas con el manejo de los servidores de la web.

Se comienza proporcionando una breve descripción de los desafíos del pro-visionamiento (abastecimiento) para el e-business, para identificar las nece-sidades y ediciones del manejo relacionados con el provisionamiento de lasaplicaciones del e-business.

4.2 Aplicaciones de E-business- Estructura Com-pleja de Capas de Servicios

La complejidad de una moderna solución e-bussines es mucho más alta quepara los sistemas estándar de procesamiento basados en terminal de los años70 y de los años 80, como ilustra la fig. 4.1, de la pág. 63.

Sin embargo, a pesar de revisiones importantes, especialmente durante losúltimos años del siglo pasado, muchos sistemas heredados siguen siendo elpan y la mantequilla de muchas empresas, y las soluciones e-business en estosambientes son diseñadas como interfaces front-end (hacia el usuario final) delas aplicaciones complejas orientadas a mainframe.

4.2. ESTRUCTURA COMPLEJAS DE CAPAS DE SERVICIOS 63

Figura 4.1: Growing Infrastructural Complexity


La infraestructura compleja necesaria para facilitar soluciones de e-businessha sido generalmente determinada por los requerimientos de estandarizaciónde los entornos de ejecución de los clientes para permitir el acceso mediantecualquier navegador estándar a los sitios de negocios.

Además, las tecnologías de tiempos de ejecución brindan un rol mayor, de-biendo asegurar independencia de la plataforma e integración con los sistemasback-end (centrales) heredados, ya sea directamente al mainframe o mediantela parte servidor de las viejas soluciones cliente - servidor. Además, hacenlas aplicaciones accesibles desde cualquier lugar en el mundo para cualquierpersona en el planeta brindando esquemas de seguridad (autenticación, au-torización, e integridad), que no necesitan direccionamiento en los antiguossistemas cliente - servidor, tal que todos los clientes accedan a entidades en laIntranet de la empresa.

Debido al papel fundamental que los servidores Web y de aplicación desem-peñan dentro de un negocio y del hecho de que está soportado (y desplegadotípicamente) a través de una variedad de plataformas dentro de la empresa,hay varios desafíos importantes al manejar la infraestructura del e-business.Algunos de éstos son:

1. Administración permanente de servidores Web y de aplicación en plata-formas múltiples desde una consola central.

2. Definir la infraestructura del e-negocio desde una consola central.

3. Monitoreo de los recursos Web (sitios y aplicaciones) para saber cuándotienen problemas, o están por ocurrir.

4. Tomar acciones correctivas cuando un problema es detectado en unaplataforma de manera independiente.

5. Recopilar datos a través de todos los ambientes del

e-business para analizar acontecimientos, mensajes y métricas.

El grado de complejidad del manejo de la infraestructura del sistema dele-business es directamente proporcional al tamaño de la infraestructura quese está intentando manejar. En su forma más simple, una infraestructura dele-business se compone de un solo servidor web y de sus recursos, pero puedehaber centenares o aún millares de servidores y aplicaciones Web distribuidasa través de la empresa.


Para agregar complejidad, la infraestructura del e-business puede atrave-sar muchas plataformas con diversos protocolos de redes, hardware, sistemasoperativos y aplicaciones. Cada plataforma posee sus necesidades y requisitosúnicos y específicos de administración de sistemas, para no mencionar un nivelvariable de ayuda para las herramientas e interfaces administrativas.

Cada componente en la infraestructura del e-business es un punto de fallapotencial. Cada uno de ellos proporcionan servicios especializados necesariospara facilitar el uso del sistema de aplicación de e-business. El término siste-ma de aplicación se usa deliberadamente para resaltar el punto que “ningúncomponente por sí mismo proporciona una solución total”, la aplicación esensamblada por una combinación de componentes disponibles estándares ycomponentes propios.

Los componentes estándares proporcionan servicios generales tales comocontrol de sesión, autentificación y control de acceso, la mensajería, el accesoa base de datos y los componentes propios agregan la lógica del uso de losmismos necesaria para unir los diferentes componentes para realizar funcionesespecíficas para el sistema de aplicación. A nivel de la empresa, las oportunida-des son, que muchos de los componentes propios se pueden promover al estadoestándar para asegurar estándares o políticas específicas de la compañía.

Para muchos servicios especializados de aplicaciones de e-business, se pue-de ver que son productivos, pero muy costosos de implementar. No obstantela especialización permite compartir componentes comunes, tales como web -aplicaciones, seguridad-, y servidores de base de datos, entre varios sistemasde aplicación de e-business, esto es fundamental para asegurar la disponibi-lidad y el rendimiento del sistema de aplicación en su totalidad teniendo encuenta la duplicación y la distribución de componentes seleccionados para re-solver requisitos de recursos específicos o para aumentar el rendimiento de lossistemas de aplicación en su totalidad. Además, el desagregado de la solucióntotal permite la adopción casi inconsulta de las nuevas tecnologías para lasáreas seleccionadas sin exponer el sistema total al cambio.

Si los componentes en el sistema del e-business son comerciales, estánda-res, o aplicaciones específicas, cada uno de ellos requerirá muy probablementelos servicios de otros servicios generales, tales como facilidad de comunicación,espacio de almacenamiento, poder de procesamiento, y las computadoras enlas cuales se ejecutan necesitan energía eléctrica, seguridad de acceso y posi-blemente refrigeración.


Para brindar sus servicios, las aplicaciones de e-business confían en va-rias capas de servicios que se pueden proporcionar internamente o mediantecompañías externas. Esto se ilustra en la fig. 4.2, de la pág. 66.

Figura 4.2: Capas de Servicios

En el caso de las aplicaciones de e-business de alcance global, que utili-zan diversidad de servicios, se puede apreciar que la falla en determinadoscomponentes (incluso fallas de energía o de comunicaciones) puede significaruna salida de servicio de otros componentes del sistema global de e-businesssituados geográficamente a distancias considerables.

Si bien la humanidad no puede prevenir un incremento de la actividad delsol o del viento, hay un variedad de tecnologías disponibles para permitir lacontinuidad, la supervisión centralizada y la vigilancia de los componentes dela solución de e-business.

Estas tecnologías ayudarán a manejar los recursos de IT (Information Te-chnologies: Tecnologías de la Información), que son parte de la solución dele-business. Algunas de estas tecnologías se pueden incluso aplicar para mane-jar los recursos de IT tales como energía, refrigeración y control de acceso.

Sin embargo, puesto que cada capa se especializa en cierto componente,cada capa es por su naturaleza diferente de las otras, y requiere diversos tiposde administración. Además, desde el punto de vista de la administraciónde recursos, la capa superior de cualquier componente es la más interesante,puesto que esta es la capa que proporciona el servicio único que es requerido


por ese componente particular. Para un servidor web la capa superior es elservidor HTTP en si mismo. Ésta es la capa crítica de la misión, aunquenecesita el establecimiento de una red, el sistema operativo, el hardware, y laenergía eléctrica para funcionar.

Por otra parte, en un servidor de aplicaciones de e-business, que trabajecon un servidor Web para comunicarse con la red y con otros servidores, elnivel de mission crítica está en el servidor de aplicaciones, y el servidor Web seconsidera secundario en este caso, al igual que el sistema operativo, la energíaeléctrica y la red de datos. Dicho esto, es necesario que todos los serviciossubyacentes funcionen para que la capa superior proporcione servicios a lasdemás. (Esto significa que todos los servicios subyacentes son necesarios ydeben operar correctamente para que la capa superior brinde el servicio demisión crítica.

4.2.1 Administración de Aplicaciones de E-business

Las funciones especializadas requieren gerencia especializada, y las funcionesgenerales requieren una gerencia general. De esta manera, es obvio que lagerencia del sistema operativo, del hardware, y de la capa de interconexiónde red pueden ser generales, dado que éstas son utilizadas por la mayoríade los componentes de la infraestructura del e-business. Por otra parte, unaherramienta de administración de aplicaciones de servidores web no pude sermuy apropiada para manejar el servidor de la base de datos.

Hasta este momento el término manejo se ha utilizado extensamente, perotodavía no se ha explicado o se ha definido.

El control sobre y la gerencia del sistema informático y de sus componentesvitales es crítico a la operación de continuación del sistema, y de tal modo ala disponibilidad oportuna de las funciones y servicios proporcionado por elmismo. Esto incluye controlar el acceso físico y lógico al sistema, para prevenirmodificaciones no autorizadas a los componentes básicos, y para supervisar ladisponibilidad de los sistemas en su totalidad, así como la disponibilidad yla capacidad de los recursos individuales tales como espacio de disco, equipode interconexión de redes, memoria, y uso del procesador. Por supuesto éstoscontrolan y supervisan actividades que tienen que ser realizadas de una maneraeficiente, de tal forma que el coste de controlar los recurso no sea más alto queel coste del recurso en sí mismo.


Administrar y controlar exitosamente los sistemas informáticos continuasiendo un aspecto importante que debe ser cubierto. Se ha mencionado varioscomponentes de hardware y de software que proporcionan colectivamente unservicio, pero que son parte de la infraestructura de IT, dónde están, y cómo serelacionan con otros componentes? Un requisito previo para la administraciónes el conocimiento detallado de los componentes a gestionar, cómo los compo-nentes se correlacionan, y cómo estos componentes se pueden manipular paracontrolar su comportamiento.

Además, ahora que las IT se han convertido en una parte integral de losnegocios, es igualmente importante, desde el punto de vista de la administra-ción, saber qué compromisos hemos hecho con respecto a la disponibilidad y alfuncionamiento de las soluciones del e-business, y qué compromisos han hechonuestros subcontratistas. Y para propósitos de planeamiento y priorización esvital combinar nuestro conocimiento sobre los componentes en la infraestruc-tura con los compromisos que se han hecho para determinar y administrar elimpacto de la escasez de recursos o el mal funcionamiento o de los mismos.

En resumen, en un ambiente orientado al e-business moderno, una de lastareas más importantes de la gerencia es controlar y manejar el Catálogo delServicio, en el cual todos los servicios suministrados se definen y se descri-ben, como así también los Acuerdos de Nivel de Servicio, en los cuales loscompromisos del Departamento de IT se especifican.

El objetivo primario de la disciplina de Entrega de Servicios (Service De-livery) es proactive, y cosiste principalmente en planificar y asegurar que losservicios son entregados de acuerdo a lo planificado, es decir según el Acuerdode Nivel de Servicio (Service Level Agreement).

Entrega de Servicios

• Administración de Niveles de Servicio

La Administración de Niveles de Servicios implica el manejo de las expec-tativas del cliente y negociar los Acuerdos de Nivel de Servicio. Esto implicaidentificar los requisitos del cliente y determinar cómo éstos se pueden resolverde la mejor manera posible dentro del presupuesto acordado.

Esto implica fijar los objetivos mensurables del funcionamiento, supervisarel funcionamiento, y tomar acciones cuando los objetivos no se alcanzan.


• Administración de Costos

La Administración de Costos consiste en colocar y mantener las cuentas decostos relacionadas con el uso de los servicios de IT y entregar estadísticas decostos y los informes a la Administración de Nivel de Servicio para ayudar aconseguir el equilibrio correcto entre el costo y la entrega de servicios. Tambiénsignifica contribuir a evaluar el costo de los servicios en el Catálogo de Serviciosy los acuerdos de Nivel de Servicio.

• Planificación para Emergencias

La planificación para emergencias planifica y asegura la continuación de laentrega o la entrega mínima de servicio reduciendo el impacto del desastre, deemergencias, y de incidentes importantes. Este trabajo se hace con la colabo-ración cercana con la gerencia de emergencias de la organización incluyendoal departamento de IT.

• Administración de Capacidad

La administración de la capacidad planifica y se asegura de que la capaci-dad adecuada con las características de funcionamiento previstas está dispo-nible para apoyar la entrega del servicio. Entrega capacidad de uso, funcio-namiento, y estadísticas de administración de la carga de trabajo, así comoanálisis de tendencia, a la Administración de Nivel de Servicio.

• Administración de la Disponibilidad

La gerencia de la disponibilidad significa planificar y asegurar la disponibi-lidad total de los servicios y el suministro de la información de gerencial en laforma de estadística de disponibilidad, incluyendo violaciones de la seguridad,a la Administración de Niveles de Servicio.

Esta disciplina puede también incluir la negociación defendiendo acuerdoscon los proveedores externos y la definición de las ventanas de mantenimientoy de los tiempos de recuperación.

Las disciplinas en el grupo de Soporte de Servicio son principalmente reac-tivas y tratan de poner los planes en ejecución y de proporcionar la informacióngerencial con respecto a los niveles del servicio alcanzados.


Soporte de Servicio

Las disciplinas reactivas que son consideradas parte del Grupo de Soportede Servicio son:

• Administración de Configuración

La Administración de la Configuración es responsable de registrar todoslos componentes de servicios de IT, incluyendo a clientes, contratos, SLAs(Acuerdos de Niveles de Servicio), el hardware y el software y de mantener unrepositorio de atributos configurables y relaciones entre los componentes.

• Mesa de Ayuda

La Mesa de Ayuda actúa en el punto-de-contacto principal para los usua-rios del servicio. Registran los incidentes, asignan la severidad, y coordinanlos esfuerzos de apoyo a equipos de soporte para asegurar la resolución deproblemas oportuna y correctamente.

• Administración de Problemas

La Gerencia de Administración de Problemas pone y utiliza procedimien-tos en ejecución para realizar diagnosis del problema y para identificar lassoluciones que los corrigen. Registra las soluciones en el repositorio de confi-guración.

• Administración de Cambios

La Administración de Cambios planifica y se asegura de que el impactode un cambio a cualquier componente de un servicio es bien conocido y deque las implicaciones con respecto a logros de los niveles de disponibilidadestán reducidas al mínimo. Esto incluye cambiar los documentos de SLA y elCatálogo de Servicios así como cambios organizacionales y a los componentesde hardware y de software.

• Control y Distribución del Software


La responsabilidad de la Gerencia de Control y Distribución de Softwarees manejar el repositorio principal (maestro) del software y desplegar compo-nentes de software de servicios. Despliega cambios a petición de la Gerenciade Administración de Cambios y proporciona informes gerenciales respecto aldespliegue (de software).

El resto de esta descripción se limitará a discutir la Administración deCapacidad y de Disponibilidad de las soluciones de e-business. Las solucionesde e-business proporcionan desafíos especiales a la gerencia debido a su altavisibilidad e importancia con respecto a los resultados básicos del negocio, sunivel de distribución, y las normas de seguridad especiales que caracterizan aInternet.

4.2.2 Arquitectura de Infraestructuras de Aplicaciones de E-business

En un ambiente típico de e-business, la infraestructura de aplicación consisteen tres niveles separados, y la comunicación entre éstos es precisa. Ver fig.4.3, de la pág. 72.Estos niveles son típicamente:

Zona Desmilitarizada DMZ (no segura)

Este es el nivel accesible para todos los usuarios externos de las aplicacio-nes. Este nivel funciona como la puerta de entrada al sistema, y tiene funcionestales como el control de acceso y la detección de intrusiones. La única partede la infraestructura de red corporativa con la cual puede comunicarse estenivel es el Application Tier (Nivel de Aplicación).

Nivel de Aplicación

Esto se implementa generalmente como parte dedicada de la red donderesiden los servidores de aplicación. Las peticiones del usuario final se enca-minan del DMZ a los servidores específicos en esta capa, donde los mismosresiden. En caso de que las aplicaciones necesiten utilizar recursos de, porejemplo, las bases de datos extensas de la compañía, éstos se trasladan al ni-vel back-end, donde residen los recursos de IT seguros de la compañía. Asícomo en el caso de la comunicación entre la DMZ y el nivel de aplicación, lacomunicación entre el nivel de aplicación y los sistemas back-end, del tercernivel, se establece con firewalls (cortafuegos) y usando puertos bien definidosde la conexión.


Esto ayuda a asegurarse de que solamente las transacciones conocidas delas máquinas conocidas pueden comunicarse desde “afuera” con las bases dedatos de la compañía o los sistemas de transacción heredados tales como CICSo IMS. Aparte de los servidores específicos de aplicación, esta capa tambiénaloja las funciones de balanceo de carga de los dispositivos y otros componentesde la infraestructura tales como servidores de MQ necesarios para implementaruna arquitectura dada de aplicación en ejecución.

Nivel Back-End

Aquí es donde residen todos los recursos de IT y los activos vitales de lacompañía. El acceso externo a estos recursos es solamente posible a través delDMZ y de la capa de aplicación.

Figura 4.3: Infraestructura Típica de Aplicaciones de E-business

Este modelo de arquitectura es una manera probada de proporcionar acce-so externo seguro, escalable y de alta disponibilidad a los datos de la compañíacon un mínimo de exposición a las violaciones de seguridad. Sin embargo loscomponentes actuales de los servidores de aplicación y recursos de infraestruc-


tura pueden variar dependiendo de la naturaleza de las aplicaciones, de laspolíticas de la compañía, de los requisitos de disponibilidad y de rendimiento,y de las capacidades de las tecnologías usadas.

Para ayudar a diseñar la arquitectura más adecuada para un sistema espe-cífico de un grupo de aplicaciones de e-negocio, IBM ha publicado un sistemade patrones de e-negocio que se pueden utilizar para acelerar el proceso paradesarrollar aplicaciones del e-negocio y de desplegar la infraestructura pararecibir éstas.

Teniendo en cuenta la experiencia de múltiples usuarios se ha compiladoun grupo de pautas en un sistema y se han relacionado para permitir queun arquitecto de soluciones comience con un problema y una visión para unasolución, y después encuentre un patrón en el que cabe esa visión. Entonces,usando el proceso de patrones, el arquitecto puede definir posteriormente lasporciones funcionales adicionales que la aplicación necesitará para tener éxito.Finalmente, el arquitecto puede construir la aplicación usando técnicas decodificación adecuadas a las pautas seleccionadas.

4.2.3 Productos Básicos Usados Para Facilitar Aplicaciones deE-business

Hasta ahora, podemos concluir que la construcción de una solución de e-business es como la construcción de un vehículo. Se desea proveer al usuariode un interfaz estándar, fácil de utilizar, que satisfaga sus necesidades; se de-sea utilizar tantos componentes estándares como sea posible para bajar costosy poder intercambiarlos sin modificarlos, se espera que sean confiables, y queestén siempre disponibles con un mínimo de mantenimiento; y se desea cons-truir con características únicas, diferenciadas, lo cual hace que el usuario elijaun producto de la organización y no de los competidores.

La diferencia principal entre el vehículo y la solución del e-business es quese posee y controla la solución, el comprador posee y maneja el vehículo. Eldueño del vehículo decide cuándo hacer el cambio de aceite y cuándo llenarel tanque de gasolina o ajustar la presión de los neumáticos. El dueño delvehículo también decide cuándo realizar un ajuste al vehículo, cuándo agregardefensas de cromo y ruedas de aleación para hacer más bello al vehículo, ycuándo venderlo. El usuario del sitio del e-business no tiene ningunas de esasopciones. En fin , como dueños de la solución del e-business, el personalde IT decide cuándo volver a trabajar en la interfaz utilizada para hacerla


mejor, cuándo agregar recursos para incrementar el rendimiento, y en últimainstancia, cuándo tornar anticuada la solución.

Esto nos da algunas ventajas sobre el fabricante del coche, en el senti-do de que podemos modificar el producto fácilmente agregando o quitandocomponentes mientras que sea necesario para alinear el funcionamiento conlos requisitos y ajustar la funcionalidad del producto como estrategia paraconseguir nuevos socios.

Una solución de e-business se puede caracterizar por tres capas específicasde los servicios que operan juntos para proporcionar la funcionalidad únicanecesaria para permitir que las aplicaciones sean utilizadas en un ambiente deInternet. Ver fig. 4.4, de la pág. 74.

Figura 4.4: Niveles de Servicios Específicos de la Solución de E-business

El nivel de presentación necesita ser una herramienta comúnmente dispo-nible, y está muy probablemente presente en todas las máquinas usadas porlos usuarios de la solución de e-business. Debe soportar el uso de tecnologíasmodernas de desarrollo, tales como páginas XML, del Javascript y del HTML.A esto se refiere generalmente como el Browser.

Los protocolos de comunicación estándares usados para proporcionar laconectividad que usa Internet son TCP/IP, HTTP y HTTPS. Estos protocolosdeben ser, y muy probablemente son, soportados por las máquinas cliente yservidor.


Los Transformation Service son responsables de recibir peticiones del clien-te y de transformar éstas en transacciones de negocios que alternadamente sonservidas por el Solution Server. Además, es responsabilidad del Transforma-tion Service recibir resultados del Solution Server, y transportarlos de nuevoal cliente, en un formato que pueda manejar el Browser. En las soluciones dee-business que no interactúan con los sistemas heredados, los TransformationService y los Solution Server se pueden poner en ejecución en la misma aplica-ción, pero muy frecuentemente son divididos en dos o más servicios dedicados.

Ésta es una representación muy simple de las funciones que ocurre en elservicio de transformación. Entre otras funciones que necesiten ser realizadasestán la identificación, la autentificación y el control de la autorización, elbalanceo de la carga y el control de transacción. Los servidores dedicadospara cada una de estas funciones se ponen en ejecución generalmente paraproporcionar un ambiente robusto y escalable de e-business.

Además algunos de éstos se colocan en un segmento dedicado de la red -la zona neutral o DMZ - la cuál, desde el punto de vista del propietario dele-business, está completamente controlada, y en la cual los requerimientos delcliente son recibidos por sistemas bien conocidos y seguros, y pasados a la redde la compañía, también conocida como Intranet. Esta arquitectura se utilizapara aumentar la seguridad reduciendo al mínimo la exposición de los datosde la empresa y el riesgo de hacking (ataques desde Internet).

Para facilitar la comunicación segura entre el DMZ e Intranet, un sistemade servidores Web se pone en ejecución y, generalmente la identificación, laautentificación, y la autorización son manejadas típicamente por un LDAPServer.

La infraestructura representada en la fig.4.5, de la pág.76 contiene todos loscomponentes requeridos para implementar una solución segura de e-businesspermitiendo que cualquier persona desde cualquier lugar tenga acceso y quehaga negocios con la empresa.

Tivoli e IBM proporcionan algunos de los productos más ampliamenteusados para implementar la infraestructura de e-business. Éstos son:

• IBM HTTP Server - Comunicación y control de transacciones.

• Tivoli SecureWay Policy Director - Identificación, autentificación y au-torización.


Figura 4.5: Estructura Razonable de una Solución de E-negocio

4.3. ADMINISTRACIÓN DE APLICACIONES DE E-BUSINESS 77

• IBM WebSphere Application Server - Hosting (alojamiento) de las apli-caciones web; responsable de los servicios de transformación.

• IBM WebSphere Edge Server - Realiza el firewalling (protección cortafuegos) de la web, balanceo de carga, recepción de requerimientos de laweb; hosting de los servicios de transformación.

4.3 Administración de Aplicaciones de E-businessUtilizando Tivoli

Aunque los patterns (patrones) de e-business ayudan a diseñar las aplicacionesde e-business, dividiéndolas en unidades funcionales que se pueden implemen-tar en diferentes niveles de la arquitectura utilizando distintas tecnologías dehardware y de software, los patrones proveen poca ayuda respecto de cómoadministrar esas aplicaciones complejas. Esta falencia es resuelta por las so-luciones brindadas por los Sistemas Tivoli.

Al diseñar la infraestructura de administración de sistemas, es necesariola gerencia de las aplicaciones de e-negocio, se debe tener presente que elfactor determinante para la arquitectura de la aplicación es la naturaleza de laaplicación en sí misma. Esto determina la infraestructura de la aplicación y lastecnologías usadas. Sin embargo, no perjudica, si el diseñador de la soluciónconsulta con los especialistas de la gerencia de sistemas mientras se diseña laaplicación.

La solución de administración de sistemas tiene que jugar con las reglasestablecidas para las aplicaciones, e idealmente gestionará fácilmente los dis-tintos recursos de la aplicación, sin ningún impacto sobre la aplicación de e-business, mientras que observa las políticas de la compañía establecidas parael uso de la red, seguridad, etcétera.

La administración de aplicaciones de e-business, por lo tanto, se logra de lamejor manera estableciendo otra capa del nivel de red, paralela a la capa de laaplicación, en la cual todos los componentes de la administración de sistemaspueden ser recibidos sin influenciar a las aplicaciones.

Usando el sistema de productos Tivoli, se recomienda establecer todos loscomponentes centrales en el nivel de Administración, y tener algunos proxies(control de acceso de entrada y salida) y agentes presentes en los niveles DMZy de aplicación, según lo mostrado en la fig. 4.6, de la pág. 78.


Figura 4.6: Infraestructura Típica de la Utilización de Aplicaciones de E-business Administradas por Tivoli

4.4. ESTRUCTURA DEL PRODUCTO TIVOLI 79

Poniendo la infraestructura de la gerencia a funcionar de esta manera, hayuna interferencia mínima entre la aplicación y los sistemas de gerencia, y elacceso a o desde los diferentes segmentos de la red es manejable, puesto quela comunicación fluye entre un número limitado de nodos usando puertos decomunicación bien conocidos.

Los productos de administración Tivoli se han desarrollado con una visiónglobal en mente. El producto Tivoli Monitoring proporciona la base para lasupervisión proactiva, el análisis, y la resolución automatizada del problema.

Como se podrá ver, Tivoli Monitoring for Web Infrastructure proporcionauna solución de administración empresarial para los ambientes del servidorWeb y de las aplicaciones. Los PACs (productos) hacen que hacia arriba esteproducto proporcione las soluciones que se integran con otros productos deadministración de Tivoli y proporcionan una parte importante de la meta deuna solución consistente, y una solución de administración fin a fin (extremoa extremo) para la organización.

Utilizando los productos disponibles tales como IBM Tivoli Monitoring forWeb Infrastructure, se puede instalar rápidamente una solución comprensiva ycompletamente integrada de dministración que puede proporcionar un retornomuy atractivo de la inversión.

4.4 Estructura del Producto Tivoli

Se puede observar cómo las soluciones de Tivoli proporcionan una administra-ción de sistemas comprensiva para la empresa y cómo el Tivoli Monitoring forInfraestructura Web se integra en la arquitectura total.

Las soluciones de Tivoli se organizan generalmente en categorías según lomostrado en la fig. 4.7, de la pág. 80.

Subyacentemente el conjunto de soluciones de Tivoli es un grupo de ser-vicios comunes y de infraestructura que proporcionan consistencia a través dela administración de aplicaciones hecha por Tivoli, así como integración dedisponibilidad.

Dentro de la familia de productos Tivoli, hay soluciones específicas queapuntan a cuatro disciplinas primarias de la administración de sistemas:


Figura 4.7: Soluciones de Administración de Tivoli

1. Rendimiento y Disponibilidad.

2. Configuración y Operaciones.

3. Gestión de la memoria.

4. Seguridad.

Los productos dentro de cada una de estas áreas han ido apareciendo através de los años y, aunque continúan siendo mejorados, brindan solucionesaceptables en diversas empresas alrededor del mundo. Con estas capacidadesbásicas logradas, IBM ha podido centrarse en el armado de aplicaciones queaprovechan estos pilares para proporcionar soluciones verdaderas de adminis-tración de sistemas del negocio. Una aplicación de negocio típica depende nosolamente del hardware y del establecimiento de una red, sino también delsoftware que se extiende desde el sistema operativo al middleware (lo interme-dio entre el sistema operativo y las aplicaciones), tales como, bases de datos,servidores web y de mensajería, y usos de los mismos.

Un conjunto de soluciones tales como los productos “IBM Tivoli Monito-ring for ...”, permite a los departamentos de IT proporcionar la administración

4.4. ESTRUCTURA DEL PRODUCTO TIVOLI 81

integral de los sistemas de la empresa de una manera consistente, en un sitiocentral, usando un sistema integrado de herramientas. Utilizando un sistemafin a fin de soluciones construidas con bases comunes, las empresas puedenmanejar la administración de la complejidad siempre creciente de su infraes-tructura de IT con personal reducido y eficacia creciente.

Tres áreas funcionales se utilizan para organizar y para coordinar las fun-ciones proporcionadas por los productos Tivoli. Estas áreas se muestran en lafig. 4.8, de la pág. 81.

Figura 4.8: Estructura del Funcionamiento de Productos de Disponibilidadde Tivoli

En el nivel inferior, están los productos y tecnologías de monitoreo talescomo Tivoli Monitoring y sus modelos de recursos. En esta capa, las aplica-ciones de Tivoli supervisan el hardware y software y proporcionan accionescorrectivas automatizadas siempre que sea posible.

En el siguiente nivel está la correlación y la automatización de eventos.Mientras que ocurren los problemas que no se pueden resolver en el nivel desupervisión, las notificaciones de los eventos se generan y se envían a un motorde correlación tal como el Tivoli Enterprise Console. El motor de correlaciónen este punto puede analizar las notificaciones del problema (eventos) quevienen de componentes múltiples y automatizar acciones correctivas o pro-


porcionar la información necesaria a los operadores que pueden emprenderacciones correctivas.

La tercera capa en esta estructura se llama Business Impact Management.Es importante saber que un componente o un sistema relacionado de compo-nentes ha fallado según lo reportado por los monitores en la primer capa.

Asimismo, en la segunda capa es valioso entender cómo una sola fallapuede causar problemas en componentes relacionados. Por ejemplo, un router(ruteador) caído, podría causar problemas a los clientes de una base de datos sino pueden tener acceso al servidor de la misma. Pero la tercera capa, BusinessImpact Management, es la más valiosa de todas, pues proporciona una visióninterna en cuanto a cómo una falla de un componente puede afectar el negocioen su totalidad. Cuando ocurre la falla del router mencionada arriba, esimportante entender exactamente qué grupo de aplicaciones del negocio seránafectadas y cómo reducir el impacto de esa falla en la empresa. El TivoliBusiness System Manager (TBSM) proporciona esta capacidad.

El Tivoli Monitoring for Web Infrastructure se centra actualmente sobretodo en el aspecto del Funcionamiento, de la Disponibilidad, de la Configura-ción y de las Operaciones de administración de una infraestructura web. Sinembargo, la gestión del almacenamiento de Tivoli y los productos de admi-nistración de seguridad también se pueden utilizar para ayudar a asegurar laintegridad de los servidores Web y de las aplicaciones.

4.5 Tivoli Monitoring for Web Infrastructure

En esta sección se proporciona una descripción de las funciones y capacidadesdel Tivoli Monitoring for Web Infrastructure Versión 5.1, que incluye cuatroPACs:

• Monitoring for IBM HTTP Server

• Monitoring for Microsoft Internet Information Server

• Monitoring for Sun iPlanet Server

• Monitoring for WebSphere Application Server

4.5. TIVOLI MONITORING FOR WEB INFRASTRUCTURE 83

Los cuatro PACs proporcionan funciones similares de administración pa-ra los servidores Web y de aplicaciones soportados. Sin embargo, debido alas diferencias tecnológicas entre los componentes gestionados, algunas de lasfunciones descritas aquí pueden o no ser aplicables a algún servidor específico.

Los PACs facilitan la administración de instancias de servidores Web y deaplicaciones en endpoints (puntos finales, usuarios finales) en Tivoli Manage-ment Framework.

El PACs proporciona la capacidad de colocar un sistema de servidores yaplicaciones Web, para reunir sus configuraciones y administrarlas.

Una vez que se hayan colocado los recursos, se puede utilizar los modelosde recurso y las funciones de administración correspondientes del PAC TivoliMonitoring for Web Infrastructure para:

1. Comenzar, parar, reiniciar, y recuperar el estado de los servidores, recu-perar el estado de los hosts y de las aplicaciones virtuales relacionadas.

2. Supervisar el rendimiento clave y la disponibilidad de hosts virtuales yde las aplicaciones que funcionan en cada servidor.

3. Pasar los eventos del PAC Tivoli Monitoring for Web Infrastructure alTivoli Enterprise Console.

4. Pasar los eventos del PAC Tivoli Monitoring for Web Infrastructure alTivoli Business Systems Manager.

5. Almacenar los datos históricos en el Tivoli Enterprise Data Warehouse.

Para asegurarse de que se esté administrando a todos los recursos dispo-nibles el Tivoli Monitoring for Web Infrastructure, el PACs proporciona unafunción de descubrimiento que encuentra las aplicaciones y los hosts virtualesalojados por los servidores.

Los recursos encontrados por las nuevas funciones de descubrimiento delTivoli Monitoring for Web Infrastructure, se agregan a la configuración delTivoli.

Tivoli Monitoring para Web Infrastructure proporciona funcionalidades deadministración en tres áreas importantes:

Administración del Funcionamiento


El PACs Tivoli Monitoring for Web Infrastructure provee modelos de re-cursos, o grupos de monitoreos, que periódicamente controlan el estado delos componentes del servidor Web: El servidor Web y sus hosts virtuales. Elestado puede ser activo (operacional) o inactivo (no-operacional). Se puedeadaptar el modelo de recursos para lograr los requerimientos locales.

Administración del Rendimiento

Los modelos de recursos del PACs permiten medir y reportar el rendimientode los hosts virtuales ejecutados por los recursos del servidor Web, para iden-tificar cuellos de botella y problemas potenciales en la infraestructura Web.Por ejemplo, se puede medir:

Para los servidores Web las métricas principales de funcionamiento son:

1. Tráfico,

2. Acceso,

3. Condiciones de error.

Para el WebSphere Application Server las métricas principales disponiblesde funcionamiento son:

1. Rendimiento del JavaBean de la empresa (EJB),

2. Rendimiento de la conexión de la base de datos,

3. Rendimiento del runtime de la JVM,

4. Rendimiento de los Servlets/JSP.

Operaciones

El PACs de Tivoli Monitoring for Web Infrastructure permite manejar losrecursos de la red y del servidor de aplicaciones mediante una administraciónbásica. Se puede:

1. Iniciar, detener, y reiniciar los servidores.

2. Comprobar el estado y recuperar la información acerca de las instanciasy hosts virtuales del servidor Web.

4.5. TIVOLI MONITORING FOR WEB INFRASTRUCTURE 85

3. Recuperar y borrar los archivos de rastreo diario (WebSphere solamente).

Las reglas del Tivoli Monitoring for Web Infrastructure administran lainformación presentada en la consola de eventos. Estas reglas quitan eventosduplicados y poco significativos y correlacionan eventos para cerrar los eventosque no son muy relevantes.

Las funciones de reporte de eventos del Tivoli Monitoring for Web In-frastructure soportan estándares de filtrado de eventos, que se pueden usarpara reducir el número de eventos enviados al servidor de eventos, además depasárselos también a la Tivoli Enterprise Console.

Capítulo 5

Supervisión en Tiempo Real

5.1 Introducción

Este capítulo cubre la implementación de la supervisión en tiempo real con elTivoli Monitoring for Web Infrastructure a través de la Web Health Consoley muestra cómo puede ser ampliada para incluir la correlación de evento yel análisis de impacto en el negocio (empresa, organización) usando la TivoliEnterprise Console (TEC) y el Tivoli Business Systems Manager (TBSM).

5.2 Utilización del Tivoli Business Systems Mana-ger

Tivoli Business Systems Manager provee a los ejecutivos de operaciones de laempresa una interfaz gráfica para ver y para entender rápidamente el estadode funcionamiento de la infraestructura IT que se está utilizando o que se estáadministrando. El Tivoli Business Systems Manager muestra a los ejecutivosde la empresa cómo los componentes o los recursos individuales afectan alfuncionamiento de la empresa u organización.

Tivoli Business Systems Manager también muestra al personal de ope-raciones qué funciones del negocio son afectadas por la interrupción de uncomponente en particular. En el Tivoli Business Systems Manager, la funcióndel negocio es representada por una línea de recursos del negocio.

87

88 CAPÍTULO 5. SUPERVISIÓN EN TIEMPO REAL

Tivoli Business Systems Manager recoge la información del estado de losrecursos de varias partes de la empresa. Se alimenta de datos provenientes deentornos de mainframe, de subsistemas de asignación de trabajos, del entornode Tivoli, de software de administración de red o de otras aplicaciones de ter-ceros. Procesa todos los eventos de esas fuentes y muestra una vista integradade la empresa.

Tivoli Business Systems Manager también muestra al personal de operacio-nes aquellas funciones del negocio que son afectadas por una salida de serviciode un componente individual.

En Tivoli Business Systems Manager, las funciones del negocio son repre-sentadas por recursos de una Line of Business (Línea de Negocios).

Tivoli Business Systems Manager recolecta información del estado de losrecursos desde varias partes de la organización. Se alimenta desde el entornomainframe, subsistemas de manejo de trabajos, Tivoli Framework, softwarede administración de red o aplicaciones de terceras partes. Procesa todos loseventos desde esas entradas y muestra una visión integrada de la organización.

Relacionado con el Tivoli Monitoring for Web Infrastructure, el TivoliBusiness Systems Manager puede mostrar el estado de los servidores Web y elestado de los recursos del WebSphere Application Server y cómo se relacionancon una función de negocio.

El Tivoli Monitoring for Web Infrastructure genera eventos a través delos modelos de recursos y de adaptadores TEC. Estos eventos pasan a travésdel TEC cuando las reglas especializadas del TEC se utilizan para reenviar lainformación al Tivoli Business Systems Manager. Alternadamente, el TivoliBusiness Systems Manager procesa estos eventos para mostrar los servidoresWeb y el estado de los recursos del WebSphere Application Server.

5.2.1 Flujo de Eventos del Tivoli Business System

Un flujo detallado de eventos para la integración del Tivoli Business SystemsManager se muestra en la fig. 5.1, de la pág. 89.

El flujo de procesos se puede describir como:

1. Los eventos son generados por el modelo de recurso ITM o el adapta-dor TEC. Estos eventos se envían al servidor TEC del evento para ser

5.2. UTILIZACIÓN DEL TIVOLI BUSINESS SYSTEMS MANAGER 89

Figura 5.1: Flujo de Eventos Para el Tivoli Business Systems Manager Inte-gration


procesados.

2. El servidor de eventos TEC compara el evento contra criterios en lasreglas que tiene.

3. El proceso de asignación de eventos envía el evento formateado al agenteque lo escucha que reside en el servidor de base de datos Tivoli BusinessSystems Manager. El agente que escucha (espera) evalúa al evento y loalmacena en la base de datos del Tivoli Business Systems Manager.

4. La consola Tivoli Business Systems Manager es informada del evento ydel estado de los objetos monitoreados que han cambiado concordante-mente.

5. Cuando un operador invoca una tarea operacional desde un menu con-textual de alguno de los recursos del Tivoli Monitoring for Web Infras-tructure, un requerimiento se envía a la tarea del proceso servidor.

6. La tarea del servidor ejecuta la tarea operacional usando el commandowruntask.

5.2.2 Integración de la Configuración del Tivoli Business Sys-tems Manager

En esta sección se describe cómo configurar la integración entre el ServidorTEC y el Servidor TBSM. Para permitir el envío de los eventos del TECal TBSM el Tivoli Enterprise Console Adapter 3.7.1 se debe instalar en elServidor TEC, mientras que para la visualización de los eventos se debe instalarla Consola TBSM.

Se instala el siguiente software para la configuración del ambiente TBSM:

Tivoli Business Systems Manager 1.5

The TBSM patch 1.5-BSM-0024



Tivoli Business Systems Manager Event Enablement 1.5




TBSM Console

TBSM patch 1.5-BSM-0036.

La Consola TBSM no requiere una máquina dedicada. Se puede instalaren cualquier máquina. Se utiliza un entorno TEC.

Para configurar el TBSM para manejar los eventos de Tivoli Monitoringfor Web Infrastructure y para permitir al servidor TEC remitir estos eventos,se requiere lo siguiente:

• En el TBSM Database Server ejecutar el archivo batch install.bat dis-ponible en el CD-ROM de cada módulo Tivoli Monitoring for Web In-frastructure en el directorio TBSM. Se debe observar que este procesopodría tomar un cierto tiempo. La instalación copiará el programa dedesinstalación y comenzará los scripts itm<module>_tbms_init.sh deinicialización, donde el módulo placeholder depende del módulo que seestá instalando.

• En el servidor de la base de datos TBSM, se debe conectar el AgentListener con el sistema de disponibilidad del evento, así el evento delTEC comienza a transmitirse al TBSM. Este proceso usa el comando:gemeeconfig - a < eehost >. Luego Recomenzar el servicio AgentListener. Para comprobar la conexión utilizar el comando gemeeconfigotra vez.

• En el servidor TEC, para cada módulo del servidor Web, importar laregla base específica del módulo ejecutando el siguiente comando: wrb

-imptgtrule itm<module name>_tbsm_forward EventServer <rule

base>

• Cargar y compilar la regla base a través del ícono respectivo o a través delos comandos: wcomprules < rule base > y wloadrb <rule base

>. Estos comandos tienen que ser ejecutados en el Servidor TEC.

• En el Servidor TEC, copiar los scripts que transmiten eventos al TBSMdesde el directorio, < TIVDIR>/bin/generic_unix/TME (TMEDIR deaquí en adelante) al directorio $BINDIR/<interp>/TME/TEC/scripts/


(donde el valor del < interp > placeholder depende de la arquitecturadonde el Servidor TEC está instalado.).

<TMEDIR>/Apache/tec/itmapache_tbsm_forward.sh

<TMEDIR>/IIS/tec/itmiis_tbsm_forward.sh

<TMEDIR>/IPlanet/tec/itmiplanet_tbsm_forward.sh

• En caso de que el Servidor TEC esté instalado en un sistema Windows2000, se recomienda cambiar el log de usuario para el servicio TivoliBSM Task Server del LocalSystem al Administrator. Si no se puedehacer esto, podrán ocurrir errores cuando un usuario intente invocar lastareas definidas por la Tivoli Monitoring for Web Infrastructure de laConsola TBSM.

5.2.3 Descubrimiento de Recursos

Para descubrir los recursos que están disponibles para cada módulo del TivoliMonitoring for

Web Infrastructure, se requiere hacer funcionar un script para cada módulodel servidor Web y ejecutar una tarea para el módulo WebSphere.

Descubrimiento de los Recursos del Servidor Web

Cada módulo del servidor Web instala un archivo script en el servidor TECen el subdirectorio <TIVDIR>/bin/generic_unix/TME (TMEDIR de aquí enadelante). Los scripts relevantes se deben ejecutar para descubrir los recursosdel servidor Web disponibles actualmente en la Tivoli Management Region.

Descubrimiento de los Recursos del WebSphere

Para el módulo de WebSphere el proceso de descubrimiento consiste en eje-cutar una tarea llamada Send_WebSphere_Discovery_Events_to_TBSM, quepuede ser encontrada en la biblioteca de tareas Utility Tasks del WebSphereApplication Server.


5.2.4 Utilización del Tivoli Business Systems Manager

La Consola TBSM se puede utilizar para iniciar y detener el Servidor HTTPApache, el Servidor Internet Information, los Servidores WebSphere Applica-tions y también sus servidores Administration. Además, es posible verificarel estado del servidor WebSphere del Administration Server y del ApplicationServer.

El servidor Apache Administration y el servidor Web se pueden iniciar ydetener a través de la consola TBSM.

El Internet Information Server se puede arrancar y detener a través de laconsola TBSM.

El servidor de administración iPlanet y el servidor Web se pueden iniciary detener a través de la consola TBSM.

El Servidor WebSphere Administration se puede iniciar y detener. Porotra parte, es posible comprobar el estado del Application Server y recogeruna lista de todas las aplicaciones manejadas por los servidores.

Capítulo 6

Administración de Reportes

6.1 Introducción

El Tivoli Enterprise Data Warehouse (TEDW) es usado para recoger y paramanejar datos de varias aplicaciones de administración de sistemas Tivoli yno-Tivoli. Los datos se importan en las bases de datos de TEDW medianteprogramas especializados, llamados extractores, estos transforman y cargan losprogramas (ETL), desde las bases de datos de aplicación, y son posteriormenteprocesados para realizar análisis y evaluación histórica. Esta estrategia deTivoli es para obtener la mayoría de los servicios de ETLs proporcionadospor los productos para poder cargar las bases de datos de TEDW con datossignificativos para la administración de los sistemas. El Tivoli Monitoring forWeb Infrastructure es uno de los muchos productos que utiliza completamentelas ventajas de TEDW.

6.2 Descripción del Tivoli Enterprise Data Ware-house

Tener acceso a los datos históricos con respecto al funcionamiento y la dis-ponibilidad de los recursos de IT puede ser muy útile de varias maneras, porejemplo:

95

96 CAPÍTULO 6. ADMINISTRACIÓN DE REPORTES

• TEDW recoge datos históricos de muchas aplicaciones en unlugar central.

TEDW recoge los datos subyacentes desde los dispositivos / conexiones a lared, equipos de escritorio / servidores, aplicaciones / software, y los problemasy actividades que se han generado al manejar la infraestructura. Esto permitela construcción de una vista extremo a extremo de la organización y una vistade los datos relacionados del recurso, independientemente de las aplicacionesespecíficas usadas para supervisar y controlar los recursos.

• TEDW agrega valor a los datos primitivos.

TEDW realiza la agregación de datos de usuarios en períodos específicos,tales como diariamente o semanalmente, y tiene en cuenta restringir la can-tidad de datos almacenados en el depósito central TEDW de los datos. Losdatos también se depuran y se consolidan para permitir al modelo de datosdel depósito central compartir dimensiones comunes. Por ejemplo, TEDW seasegura que el tiempo, el nombre de host, y las direcciones IP sean las mismasdimensiones a través de todas las aplicaciones.

• TEDW permite la correlación de información desde muchasaplicaciones Tivoli.

TEDW se puede también utilizar para obtener valor agregado correlacio-nando datos de muchas aplicaciones de Tivoli. Permite que los informes seanescritos, con datos correlacionados de distintas aplicaciones.

• TEDW utiliza interfaces abiertas provistas para la extracción,el almacenamiento y para poder compartir datos.

TEDW puede extraer datos desde cualquier aplicación, Tivoli y no-Tivoli,y almacenarlos en una base de datos central. TEDW también proporcionaacceso transparente para soluciones de Business Intelligence (BI) de terceraspartes usando el estándar CWM, tal como IBM DB2 OLAP, Crystal Deci-sions, Cognos, BusinessObjects, Brio Technology, Microsoft OLAP Server.CWM (Common Warehouse Metadata), es una especificación estándar parael intercambio de metadatos definida por el Object Management Group.

6.2. DESCRIPCIÓN DEL TIVOLI ENTERPRISE DATA WAREHOUSE97

TEDW provee un reporte para usuario final basado en Web, llamado Re-porting Interface, pero la arquitectura abierta proporcionada por el TEDWpermite otros productos de BI para usuario final que se utilizan para teneracceso a los datos del warehouse central. El valor aquí es flexibilidad. Losclientes pueden utilizar la aplicación de reporte de su opción; no están limita-dos a una específica en particular.

• TEDW proporciona un robusto mecanismo de seguridad.

TEDW proporciona un robusto mecanismo de seguridad permitiendo quelos data marts sean construidos con datos de los subconjuntos de recursos ma-nejados y proporcionando autorización completa de la base de datos para teneracceso a esos data marts, TEDW puede tratar la mayoría de los requisitos deseguridad relacionados con la limitación del acceso a los datos específicos aesas unidades de clientes/negocios que tienen necesidades específicas de cono-cimiento.

• TEDW proporciona una arquitectura escalable.

Puesto que TEDW depende de la tecnología RDBMS estándar probada dela industria, proporciona una arquitectura escalable para almacenar y recupe-rar los datos.

6.2.1 TEDW Conceptos y Componentes

Esta sección trata los conceptos claves y los varios componentes de TEDWen el orden lógico del flujos de datos de la dimensión: de los monitores querecogen informaciones en bruto al informe detallado final.

La fig. 6.1, de la pág. 98 representa una configuración típica del TivoliEnterprise.

Es común para las empresas tener varias aplicaciones distribuidas de mo-nitoreo de rendimiento y de disponibilidad desplegadas que recogen una ciertaclase de datos de la dimensión y proporcionan un cierto tipo de administra-ción, de administración central de eventos, y de otras funciones de supervisiónbásicas. Estas aplicaciones se refieren como aplicaciones fuente.


Figura 6.1: Ambiente Típico de TEDW


El primer paso para obtener datos de administración es permitir las apli-caciones fuente. Esto significa el abastecimiento de todas las herramientas yreprobaciones necesarias para importar los datos operacionales de la fuente aldata warehouse central de TEDW. Todos los componentes necesarios para esatarea se recogen en los módulos del warehouse para cada aplicación fuente.En el contexto de este trabajo, Tivoli Monitoring for Web infrastructure esla aplicación fuente que provee datos de administración para los módulos delservidor Web y del servidor de Aplicaciones.

Una porción importante de los módulos del warehouse (almacén de da-tos) son los programas de Extracción, Transformación y Carga de datos, osimplemente programas ETL. En general, los pasos son tres.

1. Primero extraen los datos desde una base de datos de aplicación fuente,llamada fuente de datos.

2. Después los datos se validan, se transforman, se agregan, y/o se purificande modo que se adecuen al formato y las necesidades de los datos delalmacén.

3. Finalmente los datos se cargan en la base de datos correspondiente.

En el TEDW hay dos tipos de ETLs: ETL para el warehouse central yETL para los data mart.

1. ETL para el warehouse central: El ETL para el Warehouse central extraelos datos de las aplicaciones fuente y los carga en el almacén central dedatos, según lo mostrado en la fig. 6.1, de la pág. 98. Al ETL para elwarehouse central también se lo llama, a menudo, ETL fuente o ETL1.

2. ETL para los data mart: Según lo mostrado en la fig. 6.1, de la pág.98, el ETL para los data mart extrae un subconjunto de datos históricosdel almacén central de los datos, el cual contiene los datos adaptadosy optimizados para la tarea de reporte o de análisis específico. Estesubconjunto de datos se utiliza para cargar los data mart. El ETL paralos data mart también se conoce como ETL destino o ETL2.

Como concepto genérico, un data warehouse es un ambiente de base dedatos estructurado, extensible y diseñado para el análisis consistente de datos.


Los datos que se insertan en un data warehouse se transforman lógicamente yfísicamente a partir de múltiples aplicaciones fuente, actualizados y manteni-dos durante mucho tiempo, y sumarizados para un rápido análisis.

El Tivoli Enterprise Data Warehouse Central Data Warehouse (CDW) es labase de datos que contiene todos los datos históricos relacionados a la empresa,con el nivel más bajo de granularidad. Este almacén de datos se optimiza parael almacenamiento eficiente de cantidades grandes de datos y tiene un formatodocumentado que hace los datos accesibles a muchas soluciones (aplicativas)de análisis. La base de datos se organiza de una manera muy flexible, que dejaalmacenar datos de nuevas aplicaciones sin agregar o cambiar tablas.

El servidor TEDW es un servidor DB2 Universal Database Enterprise Edi-tion que alberga las bases de datos TEDW Central Data Warehouse. Estasbases de datos se cargan con datos operacionales de Tivoli y / u otras aplica-ciones de terceras partes para los análisis históricos.

Un data mart es un subconjunto de datos históricos que satisfacen lasnecesidades de un departamento, de un equipo, o de un cliente específico.Un data mart se optimiza para análisis y reportes interactivos de datos. Elformato de un data mart es específico a la herramienta de reportes o análisisque se planea utilizar. Cada aplicación que proporciona un data mart ETLcrea sus data marts en el formato apropiado.

TEDW provee una Report Interface (RI) que crea reportes estadísticosbidimensionales de los datos utilizando los data marts. La Report Interfacees una interface con rol basado en la Web que puede ser accedida con unnavegador Web sencillo sin la necesidad de instalar software adicional en elcliente. Se puede usar otras facilidades para realizar análisis OLAP, reportesde inteligencia de negocios, o minería de datos.

El Centro de Control de TEDW es el servidor DB2 Universal DatabaseEnterprise Edition que contiene la base de datos de control de TEDW queadministra el entorno de TEDW. Desde el Centro de Control TEDW, se pue-de también administrar todas las bases de datos de aplicaciones fuentes delentorno.

El nombre interno por defecto para la base de datos de control del TEDWes TWH_MD. El Centro de Control TEDW también maneja la comunicaciónentre los varios componentes, tales como el TEDW Central Data Warehouse,los data marts, y las Report Interfaces. El Centro de Control TEDW utilizafacilidades del DB2 Data Warehouse Center para definir, mantener, programar


y supervisar los procesos ETL.

El TEDW almacena datos históricos primarios de bases de datos de apli-caciones Tivoli y de terceras partes en el TEDW Central Data Warehouse.El nombre interno de la base de datos del TEDW Central Data Warehous esTWH_CDW. Una vez que los datos se hayan insertado en la base de datosTWH_CDW, están disponibles para cualquier TEDW ETLs para ser carga-dos a la base de datos TEDW Data Mart (el nombre interno de la base dedatos TEDW Data Mart es TWH_MART) o a cualquier otra aplicación espe-cífica de ETL para procesar los datos y cargar la base de datos del data martespecífico de la aplicación.

6.2.2 Monitoreo del Proceso de Flujo de Datos

En esta sección se analiza cómo el componente warehouse del producto TivoliMonitoring for Web Infrastructure (ITM) interactúa con el Tivoli Enterpri-se Data Warehouse. También se describirán los distintos componentes queintegran a los componentes warehouse del Tivoli Monitoring for Web Infras-tructure.

Se mostrará cómo los datos se recogen desde el endpoint (punto final) ycómo alcanzan la base de datos del data werehouse según lo mostrado en lafig. 6.2, de la pág. 102.

Para permitir a TEDW recibir datos recopilados por un modelo de recurso,se debe permitir la registración de los datos del TEDW para el perfil en el cual,se utiliza el modelo de recurso. Una vez hecho esto el perfil se distribuye a losendpoints, estos comienzan a registrar los datos a la base de datos local TivoliMonitoring. Esta base de datos está disponible en cada endpoint.

El componente de carga del ITM es responsible de mover los datos desdelas bases de datos de los puntos finales a la base de datos de nivel intermedio.

El ETL1 genérico se utiliza para recoger datos de la base de datos dela capa media para cualquier Tivoli Monitoring for Web Infrastructure, paratransformar y para cargar éstos a las tablas y a las tablas dinámicas en elalmacén central de datos, TWH_CDH.

Cuando se ejecuta el comando wdmcollect, la recolección de datos comienzadesde la base de datos del endpoint a la base de datos de la capa media delITM. En el paso siguiente se ejecutan los ETLs genéricos para cargar el Central


Figura 6.2: ITM Para el Flujo de Datos de la Infraestructura Web


Data Warehouse. Finalmente, los ETLs de destino se ejecutan en los intervalosprogramados y se cargan las bases de datos de los data mart.

Ahora, la Report Interface se puede utilizar para generar y mostrar variosinformes basados en los datos del data mart recientemente cargados/actualizados.

Capítulo 7

Patrones Para el E-business

7.1 Generalidades

Los Patterns para el e-business son un grupo colectivo de arquitecturas pro-badas que se han compilado de más de 20.000 contratos exitosos basados enInternet. Este depósito de activos puede ser usado por las compañías pa-ra facilitar el desarrollo de aplicaciones basadas en la Web. Ayudan a unaorganización a entender y analizar problemas complejos de negocios y a des-componerlos en funciones más pequeñas y manejables que entonces se puedanimplementar usando patrones de diseño de bajo nivel (más sencillos).

Introducción a los Patrones Para el E-business

Mientras que las compañías compiten en el mercado e-business, detectanque deben reevaluar sus procesos de negocio y aplicaciones de modo que sutecnología no sea limitada por el tiempo, el espacio, los alcances de la orga-nización, o las fronteras territoriales. Se debe considerar el tiempo que leslleva para implementar la solución, así como los recursos (personal, dinero, ytiempo) que tienen a su disposición para ejecutar con éxito la solución. Es-tos desafíos, junto con la integración con los sistemas heredados existentes yla presión de entregar servicio constante de alta calidad, presentan una tareasignificativa al desarrollar una solución de e-business.

En un esfuerzo para aliviar las tareas implicadas en definir una solución dee-business, ha construido un depósito de patrones para simplificar el esfuerzo.En términos simples, un patrón (pattern) se puede definir como un modelo o

105

106 CAPÍTULO 7. PATRONES PARA EL E-BUSINESS

plan usado como guía en la fabricación de cosas. Como tal, los patrones sirvenpara facilitar el desarrollo y la producción de cosas.

Los patrones codifican la experiencia y el conocimiento repetibles de lagente que ha realizado tareas similares antes. Los patrones no solamentedocumentan soluciones a los problemas comunes, sino que también precisanlas trampas (dificultades) que deben ser evitadas. Los patrones de para ele-business consisten en mejores prácticas arquitecturales documentadas.

Definen un marco global de las pautas y de las técnicas que fueron utilizadasactualmente en crear arquitecturas para los contratos de los usuarios. Lospatrones para el e-business tienden un puente sobre el vacío entre los negociosy las IT, definiendo patrones arquitectónicos en varios niveles de los patronesdel negocio a los patrones de las aplicaciones y a los patrones de tiempo deejecución, permitiendo la navegación fácil a partir de un nivel al siguiente.

Cada uno de los patrones (Negocio, Integración, Aplicación, y Tiempode Ejecución) ayudan a las compañías a entender el alcance verdadero deldesarrollo de su proyecto y proporcionan las herramientas necesarias para fa-cilitar el proceso de desarrollo de aplicaciones, de tal modo de permitir que lascompañías acorten los tiempos de salida al mercado, reduzcan riesgos, y másimportante, lograr un retorno de inversión más significativo.

Los tipos de patrones para el e-business son los siguientes:

Patrones de Negocio.

Patrones de Integración.

Patrones Compuestos.

Patrones de Aplicación.

Patrones de Tiempo de Ejecución.

Cuando una compañía aprovecha estos activos documentados, puede redu-cir el tiempo y los riesgos implicados en terminar un proyecto.

Los ejecutivos técnicos de mayor categoría pueden utilizar Patrones deAplicación para tomar las decisiones críticas relacionadas con la estructura y laarquitectura de una solución propuesta. Los Patrones de Aplicación ayudan arefinar Patrones de Negocios para poder ponerlos en ejecución como solucionescomputarizadas.

7.1. GENERALIDADES 107

Los ejecutivos técnicos pueden utilizar estos patrones para identificar ydescribir los componentes lógicos de alto nivel que son necesarios para imple-mentar las funciones principales identificadas en un Patrón de Negocios. CadaPatrón de Aplicación describirá la estructura (capas de la Aplicación), la co-locación de los datos, y la integración (débilmente o fuertemente acoplados)de los sistemas implicados.

Finalmente, los arquitectos de soluciones y los diseñadores de sistemaspueden desarrollar una arquitectura técnica usando Patrones de Tiempo deEjecución para realizar los Patrones de Aplicación. Los Patrones de Tiempode Ejecución describen la arquitectura lógica que se requiere para implemen-tar un Patrón de Aplicación. Los arquitectos de soluciones pueden equipararPatrones de Tiempo de Ejecución a las necesidades de negocio y entorno exis-tentes.

El Patrón de Tiempo de Ejecución implementado establece los componen-tes necesarios para soportar el Patrón de Aplicación elegido. Define los nodosmiddleware lógicos, sus roles, y las interfaces entre estos nodos para resolver enel orden apropiado los requisitos del negocio. El Patrón Tiempo de Ejecucióndocumenta qué es necesario para completar la aplicación, pero no especificamarcas de productos. La determinación de productos actuales se hace en laetapa de los patrones referida al mapeo de productos.

En resumen, los Patrones (Patterns) para e-business capturan (aprove-chan) una solución al e-business que ha sido chequeada y probada. Haciendoque estas soluciones estén disponibles y clasificándolas en categorías útiles,los ejecutivos, los planificadores, los arquitectos, y los desarrolladores puedenrefinarlas para lograr mejoras, según directivas tangibles.

Los patrones y sus líneas directivas asociadas permiten que se comiencecon un problema y una visión, se encuentre un patrón conceptual en el quequepa esta visión, se definan las piezas funcionales necesarias que la aplicaciónprecisará para tener éxito, y después se construye realmente la aplicación.Además, los patrones para el e-business proporcionan terminología común deproyectos y aseguran que la aplicación soporta objetivos de negocio, reduciendosignificativamente costos y riesgos.

Modelo de Activos Evaluados de Patrones Para E-business

Los Patrones para e-business proporcionan arquitecturas disponibles paraimplementar exitosamente soluciones de e-business mediante la reutilizaciónde componentes y elementos de solución probados, de experiencias exitosas. La


aproximación de los Patrones se basa en un conjunto de activos (experiencias)evaluados que pueden ser utilizados por cualquier metodología de desarrolloexistente. Estos activos evaluados son estructurados de cierto modo que cadanivel de detalle es construido en último lugar.

Estos activos incluyen:

1. Patrones de Negocio que identifican la interacción entre usuarios, nego-cios, y datos.

2. Patrones de Integración que unen conjuntamente múltiple patrones deNegocio cuando una solución no puede ser suministrada por un solopatrón de Negocio.

3. Patrones Compuestos que representan comúnmente combinaciones queocurren de los patrones del Negocio y de los patrones de Integración.

4. Patrones de Aplicación que proporcionan una disposición conceptualdescribiendo cómo los componentes y los datos de aplicación interactúandentro de un patrón de Negocio o de un patrón de Integración.

5. Patrones de Tiempo de Ejecución que definen la estructura middlewarelógica que soporta un patrón de Aplicación. Los patrones Tiempo deEjecución representan los nodos middleware principales, sus roles, y lasinterfaces entre estos nodos.

6. Mapeos de Producto que identifican la implementación de software pro-bados y examinados para cada patrón de Tiempo de Ejecución.

7. Directrices de Mejores Prácticas para diseño, desarrollo, despliegue, yadministración para aplicaciones e-business.

Estos activos y sus relaciones se muestra en la fig. 7.1 de la pág. 109.

Patrones Para el Sitio Web del E-business

Los Patrones del Sitio Web proporcionan una manera fácil de navegacióndesde arriba hacia abajo a través de los patrones activos evaluados para de-terminar los activos reutilizables preferidos para un requerimiento acordado.

Cómo Utilizar los Patrones Para el E-business

7.1. GENERALIDADES 109

Figura 7.1: Modelo del Patrón Activo Acordado


Según lo descrito en la sección anterior, los patrones para el e-businessse estructuran de una manera en que cada nivel de detalle es construido enúltimo lugar. En el nivel más alto están los Patrones de Negocio que describenlas entidades implicadas en la solución de e-business. Un Patrón de Negociodescribe la relación entre los usuarios, la organización o aplicación del negocio,y los datos que se accederán.

Los Patrones Compuestos aparecen en la jerarquía mostrada en la fig. 7.1de la pág. 109 sobre los Patrones de Negocio. Sin embargo, los PatronesCompuestos se componen de un número de Patrones de Negocio individualesy por lo menos de un Patrón de Integración. En esta sección, se discute cómoutilizar la estructura evaluada de los patrones para los activos de e-business.

Selección de Patrones y Mapeo de Productos

Después que se ha identificado el patrón apropiado de Negocio, el pasosiguiente es definir los componentes lógicos de alto nivel que constituirán lasolución y cómo interactuarán estos componentes. Esto se conoce como Patrónde Aplicación. Un Patrón de Negocio tendrá generalmente múltiples Patronesde Aplicación identificados que describan los componentes lógicos posibles ysus interacciones. Por ejemplo, un Patrón de Aplicación puede tener compo-nentes lógicos que describan una capa de presentación para interactuar con losusuarios, una capa de aplicación Web, y una capa de aplicación back-end.

El Patrón de Aplicación requiere un soporte del middleware que se expresacomo uno o más Patrones de Tiempo de Ejecución. Los Patrones de Tiempode Ejecución definen los nodos funcionales que representan las funciones delmiddleware que deben ser realizadas.

Después de haber identificado un Patrón de Tiempo de Ejecución, el pasológico siguiente es determinar el producto actual y la plataforma a utilizarpor cada nodo. Los patrones para el e-business tienen mapeos de productosque correlacionan a los Patrones de Tiempo de Ejecución, describiendo losproductos actuales que se han utilizado para construir una solución del e-business para esta situación.

Finalmente, las directrices asisten (ayudan) en la creación de la aplicaciónusando las mejores prácticas que se han identificado con la experiencia.

Parte II

Tivoli Storage Manager

111

Capítulo 8

Implementación del TivoliStorage Manager

8.1 Descripción del Tivoli Storage Manager

En este apartado se proporciona una introducción al Tivoli Storage Managery se describe funciones y características principales que están actualmentedisponibles [8].

8.1.1 Proteger Datos con el Tivoli Storage Manager

Tivoli Storage Manager: Una solución Empresa-Extensa

• Tivoli Storage Manager almacena copias de backup y archivo de datosen almacenamiento off-site.

• Tivoli Storage Manager escala para proteger centenares de computadorasque funcionan en una docena de sistemas operativos.

• Tivoli Storage Manager proporciona técnicas inteligentes de movimientoy almacenamiento de los datos.

• Los módulos opcionales permiten a los negocio aplicaciones críticas quefuncionan 24x365 utilizar la protección de los datos sin la interrupcióndel servicio.

113

114 CAPÍTULO 8. IMPLEMENTACIÓN DEL T.S.M.

Tivoli Storage Manager protege los datos de la organización contra fallasy otros errores del hardware manejando backup y copias de archivos de datos,que pueden ser almacenado off-site. Diseñado para un ambiente heterogéneo,el Tivoli Storage Manager se conecta vía LAN, WAN, Internet, y el SAN paraproporcionar técnicas inteligentes de movimiento y almacenamiento de datos,automatismo y administración de datos basada en política integradas. Losmódulos opcionales permiten aplicaciones críticas de negocios que deben fun-cionar 24 horas al día, 7 días a la semana, utilizando la protección centralizadade los datos del Storage Manager sin interrupción de los servicios.

TSM no es una herramienta de backup. Es una herramienta de gerenciade datos.

Soluciones Importantes del Tivoli Storage Manager 5.2.

• Los componentes mostrados en la fig. 8.1 de la pág. 115 son componen-tes de la implementación básica del Tivoli Storage Manager. Las páginassiguientes contienen descripciones detalladas de cada uno de estos com-ponentes.

• Administradores: los administradores incorporan su identificación y con-traseña administrativas cuando se abren una sesión inicialmente en unservidor del Storage Manager. Los administradores pueden ser autori-zados a una o más de las clases de privilegio administrativas siguientes:sistema, política, almacenamiento, operador, o analista. Los adminis-tradores pueden utilizar los comandos administrativos y las preguntaspermitidas por sus privilegios.

• Storage Manager Server: en una configuración LAN tradicional, el rolde un servidor Storage Manager es almacenar los datos de backup odel archivo de los clientes que soporta a los medios de almacenamien-to. También tiene una base de datos de información para no perder devista los datos que maneja, incluyendo objetos de la política de manejo,usuarios y administradores, y nodos del cliente.

• Planificador (Scheduler): el planificador definido como administradorpermite la automatización de las operaciones del servidor y del cliente delStorage Manager. Un sistema comprensivo e integrado de planificadorespuede proporcionar la base para el manejo eficiente de datos con pocanecesidad de intervención durante operaciones normales. El planificadorde las operaciones del cliente Storage Manager consisten del planificador

8.1. DESCRIPCIÓN DEL TIVOLI STORAGE MANAGER 115

Figura 8.1: Componentes de una Implementación Básica del Tivoli StorageManager


en el servidor del Storage Manager y un componente planificador que seejecuta en la máquina del cliente del Storage Manager.

• Archivo de backup cliente: el cliente del TSM envía datos a, y recuperadatos desde, un servidor del TSM. El archivo de backup cliente del TSMdebe ser instalado en cada máquina que necesite transferir datos al alma-cenamiento manejado por el servidor llamado pools de almacenamiento.El servidor del TSM utiliza un nombre único de nodo para identificarcada instancia de archivo de backup cliente del TSM. Una contraseña sepuede utilizar para autenticar comunicaciones entre el archivo de backupcliente y servidor del TSM. Los datos se pueden recuperar en la mismamáquina cliente que transfirió inicialmente o en otro cliente con un for-mato del sistema de ficheros compatible si ese cliente ha proporcionadoel permiso.

• Base de datos del Storage Manager: el Storage Manager guarda infor-mación en la base de datos del Storage Manager sobre cada archivo,volumen lógico completo (sin discriminar), o base de datos que se res-palda, archiva, o migra. Esta información incluye el nombre del archivo,tamaño del archivo, la clase administradora, copia de grupo, localizaciónde los archivos en almacenamiento del servidor del Storage Manager, ytoda otra información excepto los datos. Los datos se almacenan en unpool de almacenamiento.

• Registro de recuperación del Storage Manager: el registro de recupera-ción no pierde de vista todos los cambios realizados a la base de datos,de modo que si ocurre una interrupción del sistema, un registro de loscambios estuviera disponible para la recuperación.

• Pools de almacenamiento: los pools de almacenamiento son coleccio-nes de medios semejantes que proporcionan almacenamiento para losarchivos resguardados, archivados, y migrados. Estos pools se puedenencadenar para crear una jerarquía de almacenamiento.

• Administración basada en Políticas: la política de negocios se utilizapara manejar centralmente los datos del cliente. Las políticas son creadaspor el administrador y almacenadas en la base de datos en el servidor.

• Librería de cintas: el Tivoli Storage Manager soporta una variedad detipos de librería, incluyendo librerías manuales, librerías SCSI, librerías349X y 358X (LTO), y librerías externas. Una librería de cintas es esen-


cialmente una caja que sostiene controladores y cartuchos, y proporcionaautomatización para la operación de cinta.

La Funcionalidad Backup-Restore Proporcionada por el TivoliStorage Manager

El Tivoli Storage Manager puede realizar backups de archivos y de vo-lúmenes lógicos completos. Al respaldar los archivos, la base de datos delservidor del Tivoli Storage Manager guarda una lista de todos los archivos yde sus atributos (hora, fecha, tamaño, listas de control de acceso, y atributosextendidos). Fig. 8.2de la pág. 117.

Figura 8.2: La Funcionalidad Backup-Restore Proporcionada por el TivoliStorage

Los volúmenes lógicos completos se tratan como entidades separadas, y seaplica la clase de política de administración a la imagen entera en su totalidad.No hay seguimiento de archivos individuales en una imagen de backup, es decir,se trata un objeto como separado.


• Backup: crea una copia de un archivo para proteger contra la pérdidaoperacional o la destrucción de ese archivo. Los clientes controlan losbackups definiendo la frecuencia de backup y el número de versiones.

• Restore: Sitúa las copias de backup de los archivos en un sistema oestación de trabajo determinado por el usuario después de la pérdida deun archivo. Por defecto, la versión más reciente de cada fichero activosolicitado es substituida.

Hay cuatro niveles de backup disponibles: a nivel de bytes (cantidadespequeñas de datos, como en las computadoras portátiles), nivel de bloque(cantidades más grandes de datos, entre 40 KB y 2 MB), nivel de archivo (ar-chivos normales), y nivel de imagen (incluye el sistema de ficheros y archivos).

Provisión de Grandes Capacidades de Almacenamiento Mediantela Función Archive-Retrieve

La función Archive del Tivoli Storage Manager almacena archivos selec-cionados incondicionalmente en el servidor, según los límites aplicables de lasclases de administración. Incondicionalmente significa que no hay límite deversión, y serán conservados por el período definido de tiempo sin importar sifueron eliminados en el cliente. Fig. 8.3de la pág. 119.

Archivar es útil cuando se deseas almacenar los datos que son infrecuente-mente accedidos pero deben mantenerse disponibles. Además no es no habitualtener un requisito legal para archivar los registros del negocio por períodos detiempo extendidos, y la función Archive es ideal para este propósito. El Ti-voli Storage Manager 5.2 introduce la capacidad de archivar por 30 años encomparación con el máximo de 9999 días por defecto en versiones anteriores.

• Archive: crea una copia de un archivo o sistema de archivos para la reten-ción de registros vitales de datos, tales como información de la patente,información financiera, o registros del cliente. Los clientes controlan elarchivo definiendo el periodo de validez. Esta característica permite alos clientes guardar copias ilimitadas de un archivo.

• Retrieve: una función que permite a los usuarios copiar un fichero alma-cenado del pool de almacenamiento a la estación de trabajo. La copiadel archivo en el pool de almacenamiento no es afectada.

Capacidades de Gestión del Administrador


Figura 8.3: Provisión de Grandes Capacidades de Almacenamiento Mediantela Función Archive-Retrieve


Tivoli Storage Manager permite a los clientes registrar a los administrado-res y otorgar a los administradores la capacidad de realizar tareas específicas.Después de que los administradores son registrados, pueden hacer preguntasy solicitar ayuda en la línea de comando. Para realizar otras funciones delservidor, deben tener cierto nivel de autoridad que les fue asignado medianteuna o más clases de administración de privilegio. Fig. 8.4de la pág. 120.

Figura 8.4: Capacidades de Gestión del Administrador

Las Capacidades de Automatización Proporcionadas por el TivoliStorage Manager

El Tivoli Storage Manager incluye un componente programable (schedule)central que permite el proceso automático de comandos de gestión y de opera-ciones del cliente durante un período de tiempo específico cuando se activa elschedule. Un administrador es responsable de crear y mantener los schedulesen cada dominio de la política. El scheduling de Tivoli Storage Manager está


divido en dos categorías: el scheduling administrador y el scheduling cliente.Fig. 8.5de la pág. 121.

Figura 8.5: Capacidades de Automatización

8.1.2 Almacenamiento y Gestión de Datos

Tipos de Medios de Almacenamiento en los Cuales TSM AlmacenaDatos

Para almacenamiento de acceso secuencial, TSM soporta muchos tipos dedispositivos y medios (fig. 8.6de la pág. 122).

Los pools de almacenamiento contienen archivos de backup, archivos alma-cenados y archivos migrados. Estos pools de almacenamientos se encadenanpara crear una jerarquía de almacenamiento. El pool de discos es usualmenteprimero en la cadena y es seguido generalmente por el de cintas. A esto sellama una jerarquía.


Figura 8.6: Tipos de Medios de Almacenamiento


Estrategia Basada en Políticas Para la Administración de los Da-tos

Los datos del cliente son manejados centralmente por la política de negocio.Las políticas son creadas por el administrador y almacenadas en la base dedatos en el servidor.

Las políticas se componen de varios elementos:

• Dominio de Políticas: un grupo de nodos manejados por el mismo con-junto de políticas de restricción según lo definido por los conjuntos depolíticas. Un nodo se puede definir solamente a un dominio de políticaspor servidor. Un nodo puede ser registrado en más de un servidor.

• Grupo de Políticas: una colección de definiciones de clases de admi-nistración (MC). Un dominio de políticas puede contener varios gruposde políticas. Sin embargo, solamente una política fijada en un dominiopuede estar activa en un momento dado.

• Clase Administradora (MC): una colección de atributos de gestión des-criben características de backup y de almacenamiento. Hay dos conjun-tos de atributos MC, uno para el backup y otro para el almacenamiento.A un conjunto de atributos se lo llama grupo de copia, y hay un grupode copia de backup y un grupo de copia de almacenamiento.

Tivoli Storage Manager Para Productos de Protección de Datos

IBM ofrece una variedad de productos para la protección de los datos(Tivoli Data Protection o TDP) que funcionan con el Tivoli Storage Managerpara proteger datos de la empresa.

El Tivoli Storage Manager for Databases es un módulo de software quefunciona con el Tivoli Storage Manager para proteger una amplia gama dedatos de aplicación a través de la protección de los sistemas de administraciónde base de datos fundamentales que sostienen los datos. El Tivoli Storage Ma-nager for Databases explotan las utilidades y las interfaces de backup-certifiedproporcionados por Oracle, Microsoft SQL Server, e Informix. Conjuntamentecon el Tivoli Storage Manager, este módulo automatiza las tareas de protecciónde datos y permite que los servidores de base de datos continúen ejecutando susaplicaciones principales mientras resguardan y restauran datos para y desdealmacenamiento fuera de línea.


El Tivoli Storage Manager ERP construye estructuras en la base de datosSAP e incluye un conjunto de funciones de administración de base de datosintegradas con R/3 para el control y administración de la base de datos.

El Tivoli Storage Manager for Hardware mejora la protección de los datosde las bases de datos de un negocio crítico y las aplicaciones ERP que requierenlas 24 horas de los 365 días de disponibilidad. Este módulo de software ayudaal Tivoli Storage Manager y a sus otros módulos de protección de datos arealizar de manera muy eficiente los backups y el archivado de datos de lamayoría de las aplicaciones críticas de negocios mientras elimina casi todo elimpacto del funcionamiento en la base de datos o servidores ERP.

El Tivoli Storage Manager for Mail es un módulo de software para el TivoliStorage Manager que automatiza la protección de los datos de los servidoresde E-mail que ejecutan cualquier Lotus Domino or Microsoft Exchange. Estemódulo utiliza las interfaces de programación de aplicaciones (APIs) propor-cionados por los vendedores de aplicaciones de E-mail para realizar backupsen caliente en línea sin cerrar el servidor de E-mail y mejora el rendimientodel restore de los datos.

El Tivoli Storage Manager for Application Servers es un módulo de soft-ware que trabaja con el Tivoli Storage Manager para proteger mejor la in-fraestructura y los datos de aplicación y para mejorar la disponibilidad delos WebSphere Application Servers. Trabaja con el WebSphere ApplicationServers para proporcionar un applet de GUI para hacer backup en línea repro-ducibles y automatizados de un ambiente de WebSphere Application Server,incluyendo al administrador de base de datos del WebSphere (DB2 UDB), losdatos de configuración, y los archivos de los programas de aplicación desple-gados.

El Tivoli Storage Manager for Space Management libera a administradoresy usuarios de las tareas de planeamiento manuales del sistema de ficheros yposponen la necesidad de comprar discos de almacenamiento adicionales emi-grando automática y transparentemente archivos con poca frecuencia de accesoal almacenamiento del Storage Manager mientras que los archivos usados conmás frecuencia permanecen en el sistema de ficheros local.

La extensión Tivoli Storage Manager for Storage Area Networks permiteque los servidores del SANconnected Storage Manager y las computadorasclientes del Storage Manager hagan uso máximo de su conexión de red directaal almacenamiento. Esta extensión de software permite a los servidores y a las


computadoras cliente hacer la mayoría de su backup-restauración y archivo-recuperación transfiriendo datos sobre el SAN en vez de la LAN, directamenteo a cinta o al pool de almacenamiento en disco del Storage Manager. Estacapacidad reduce en gran medida el impacto en el rendimiento de la protecciónde los datos en la LAN mientras que reduce la utilización de la CPU en elcliente y en el servidor.

8.1.3 Licencia

Licencia del Tivoli Storage Manager

EL Tivoli Storage Manager Extended Edition proporciona algunas funcio-nalidades adicionales mas allá de las funciones principales del Tivoli StorageManager. El Tivoli Storage Manager Extended Edition provee funciones talescomo compartición de la librería de cintas, soporte adicional de la librería decinta, recuperación de desastres, desplazamiento libre de los datos al servidory mucho más, (fig. 8.7de la pág. 126).

La licencia del Tivoli Storage Manager incluye el soporte para libreríasincluyendo hasta 3 dispositivos, y 40 slots.

• Todos los procesadores servidores en un sitio se deben licenciar por el Ti-voli Storage Manager o por el Tivoli Storage Manager Extended Edition.No debe haber mezcla de estos productos en un sitio. Todos los sistemasmanejados por el Tivoli Storage Manager Extended Edition deben tenerla licencia del Tivoli Storage Manager Extended Edition.

• Las licencias del cliente del Tivoli Storage Manager o del Tivoli StorageManager Extended Edition (computadoras de escritorio y portátiles) sonpermutables.

• Tivoli Storage Manager or Tivoli Storage Manager Extended Editionlicense entitlements are required for all systems to be licensed for offe-rings.

• Las ofertas del Tivoli Storage Manager Data Protection ( incluyendoStorage Area Network y Space Management) pueden ser agregadas alTivoli Storage Manager o al Tivoli Storage Manager Extended Edition.

• La licencia para el Tivoli Storage Manager for ERP se requiere sólo paralos servidores de base de datos.


Figura 8.7: Licencia del Tivoli Storage Manager


• La licencia para el Tivoli Storage Manager for Hardware se require sólopara los servidores de base de datos y requieren el TSM for Databasesen adición al Tivoli Storage Manager o al Tivoli Storage Manager Ex-tended Edition. Escenarios de backup en caliente requiren licencias enlos servidores de backup.

8.1.4 Introducción al Escenario

Introducción a la Compañía XYZ

La compañía XYZ está implementando una solución Tivoli Storage Mana-ger para reunir la administración y la protección necesaria de los datos. Losdesafíos descriptos en el escenario de la compañía XYZ son las clases de des-afíos que se pueden encontrar y solucionar con el Tivoli Storage Manager, (fig.8.8 de la pág. 127).

Figura 8.8: Introducción al Escenario

Instalación del Servidor y de Clientes del Tivoli Storage Manager


Los administradores de la compañía XYZ instalarán al Tivoli Storage Ma-nager como un servicio de producción, pero primero experimentarán con elTivoli Storage Manager en su ambiente de prueba. Ellos utilizarán la guíarápida Quick Star para instalar el servidor TSM, los archivos de backup delos clientes, y la línea de comando administrativa del cliente como parte delciclo de prueba. También instalarán y configurarán una librería de cintas queesta localmente unida al servidor TSM. Posteriormente, los administradoresprepararan los cartuchos de cinta para el uso en la librería de cintas.

Manejo de Volúmenes y Medios del Pool de Almacenamiento

En este ambiente, hay diversos grupos de máquinas con necesidades simi-lares de protección de los datos. Por ejemplo, los administradores de sistemaspueden determinar que los servidores del laboratorio de Windows requierenque el sistema operativo (OS) sea respaldado sólo una vez y que puedan res-paldarse los sistemas cada vez que una nueva aplicación sea instalada en lasmáquinas. Pueden no querer que algún dato de usuario sea respaldado. Parael crítico servidor del proyecto en este ambiente, el sistema entero, el OS, lasaplicaciones, y los datos del usuario se pueden respaldar diariamente, de do-mingo a viernes, los incrementales como los backup completos deben hacerseel sábado. Una copia del archivo sería tomada muy probablemente en off-sitesemanalmente para las capacidades de recuperación de desastre, y los datospueden esperar para ser almacenado off-site un año antes de que puedan sereliminados del sistema. Los usuarios en el servidor crítico del proyecto puedenesperar poder restaurar archivos rápidamente a partir de cualquier día du-rante las dos semanas previas. Los administradores deben configurar los poolde almacenamiento y jerarquías de pool de almacenamientos para resolver losrequerimientos de los clientes.

Definición de las Políticas del Tivoli Storage Manager

Los administradores definen nuevos dominios de la política, conjuntos depolíticas, clases administradora, copia de backup en grupo, y grupos de copiade archivo para trazar los acuerdos del nivel de servicio para el proyecto crítico,el laboratorio, y los sistemas de base de datos a las políticas del Tivoli StorageManager. La compañía XYZ, según muestra el diagrama, tiene dos admi-nistradores que estarían manejando el registro de administradores, otorgandoniveles de autoridad, y manejando cuentas administrativas. Un administra-dor tiene última autoridad sobre los backups para los sistemas Windows en elsitio, mientras que el otro tiene última autoridad sobre las backups para losservidores UNIX en el sitio. Hay varios operadores que serán responsables de


manejar sesiones de clientes y manejar operaciones de cinta.

Volúmenes de Configuración del Registro de la Base de Datos yde la Recuperación

Los administradores de la compañía XYZ deben configurar volúmenes dela base de datos y del registro para resolver los requerimiento de espacio endisco y los requerimiento de espacio del registro de recuperación para su sitio.

Configuración del Cliente

La compañía XYZ tiene estrechas pautas de seguridad y requiere que lascontraseñas expiren en los intervalos especificados y resuelvan ciertas pautaspara un número mínimo de caracteres.

Manejo de Datos del Cliente

Considerar un caso donde uno de los encargados en un grupo de trabajocrítico ha eliminado inadvertidamente un archivo importante y ha llamadopara solicitar que el archivo fuera restaurado. Debido a los problemas con unaestación de trabajo, varios archivos con los que el encargado trabajó al princi-pio del día se ha encontrado que están corruptos. El encargado había estadotrabajando con los archivos relacionados al proyecto X. Los miembros del equi-po que trabajan en un proyecto crítico han decidido que una versión anterior desu documento es realmente mejor que la versión actual. Desafortunadamente,nadie guardó la versión anterior. El administrador del almacenamiento es res-ponsable de ayudar a los encargados en la restauración de los archivos, segúnlo necesario, a las localizaciones deseadas.

Automatización de las Operaciones del Cliente

Los administradores del almacenamiento de la compañía XYZ desearánautomatizar sus procesos de archivo y backup de modo que sucedan consis-tentemente y que a la vez eso sea conveniente. Además, pueden desear agregaralgunas tareas de pre-processing o post-processing.

Logging de Monitoreo y Eventos

Configurando el registro de eventos, los administradores de la compañíaXYZ pueden determinar qué eventos quisieran supervisar y cómo hacerlo paraque los eventos sean manejados. Por ejemplo, los administradores pueden ele-gir seleccionar ciertos tipos de eventos para ser formateados como un informede los éxitos y las faltas de la culminación del backup.


Protección de la Base de Datos

Los administradores del almacenamiento en la compañía XYZ desearánrespaldar su información de la base de datos y de la configuración del StorageManager regularmente de modo que pueda ser restaurado su servidor del TivoliStorage Manager en caso de un desastre que resulta en la corrupción de la basede datos del Storage Manager.

8.2 Instalación del Servidor, Cliente y Dispositivosde Almacenamiento del Tivoli Storage Manager

En éste apartado se tratará del servidor Storage Manager básico, archivo debackup del cliente, y dispositivos de instalación y configuración.

8.2.1 Instalación del Tivoli Storage Manager

Los requisitos previos del curso asumen el conocimiento de instalar programassobre su servidor Storage Manager y plataforma de cliente. Para esta clase,usaremos las Ventanas 2000 o la plataforma AIX para los ejercicios.

Instalación del Tivoli Storage Manager en Windows

Después de insertar el CD del Tivoli Storage Manager Windows Server,en el browser del CD aparece un menú principal. Seleccionar Install Productsy se mostrará la ventana de Install Products. La secuencia de instalaciónes indicada por la disposición de producto proporcionada en la pantalla deProducts Install.

Aunque la pantalla Install Products muestre una secuencia diferente deinstalación, se puede considerar preferible instalar el driver del dispositivoantes de instalar el cliente TSM.

Instalación del Tivoli Storage Manager Server

Tareas de Instalación del Servidor:

• Instalar el software.

• Migrar desde una versión anterior.

8.2. INSTALACIÓN DEL SERVIDOR Y DEL CLIENTE 131

• Iniciar el servidor.

• Asignar el almacenamiento requerido por el Servidor.

• Personalizar el archivo de opciones de servidor.

• Comenzar el servidor.

Prerequisitos Para Tivoli Storage Manger Server

Las plataformas soportadas del servidor para el Storage Manager Serverson las siguientes:

• IBM AIX R© AIX 5L 5.1 or later (32 bit or 64 bit) or AIX 5.2 (32 bit or64 bit)

• HP-UX 11.0 (32 bit or 64 bit) or 11.11 (11i Version 1.0) (32 bit and 64bit)

• Windows Server 2003 - Standard Edition - 32 bit, Enterprise Edition -32 bit, Datacenter

• Edition - 32 bit, Enterprise Edition - 64 bit, Datacenter Edition - 64 bit

• Windows 2000 Professional, Server, Advanced Server, Datacenter Server

• Sun Solaris 8 (64 bit), or 9 (64 bit)

• OS/400 R© PASE V5R1 or V5R2

• OS/390 R© z/OS V1R1, or later, V2R10 or later

• Linux on pSeries: SuSE Enterprise Server 8

• Linux on xSeries: Red Hat Linux Advanced Server 2.1 or 2.4.9-e.10enterprise SMP

• SuSE Enterprise Server 7 or SuSE Enterprise Server 8/United Linux 1.0

• Linux on zSeries: SuSE Linux Enterprise Server 8

The TSM administrative Web interface, Web proxy, and Web client requireone of the following:


• Netscape Navigator 6.0 (which provides Java Swing support) or later

• Netscape Navigator 4.7 or later with the Java Plug-In (JRE 1.3.1)

• Microsoft Internet Explorer 5.0 or later with the Java Plug-In (JRE1.3.1)

• Mozilla 1.4.2 or later

Se recomienda instalar y usar el JRE 1.4 para optimizar el rendimiento delcliente Java backuparchive.

Tivoli Storage Manager soporta los siguientes protocolos de comunicación:TCP/IP y los llamados pipes.

Instalación del Storage Manager Server en Windows

Instalar el Storage Manager Server en Windows es un simple proceso deInstallShield. Permitirá elegir el idioma usado para la instalación. Esta confi-guración del lenguaje sólo se aplica para la instalación.

Componentes Basicos Instalados por Tivoli Storage Manager

La instalación básica del servidor del Tivoli Storage Manager de la fig. 8.9de la pág. 133 creará lo siguiente:

• Base de Datos del Tivoli Storage Manager: Contiene información sobrepolíticas, schedules, y log de actividades.

• Recovery Log: Contiene información sobre todos los cambios en la basede datos.

• DSMSERV.OPT: Contiene opciones de configuración del servidor.

• DSMSERV.DSK: (en la mayoría de las plataformas) Identifica el nombretotalmente calificado de la base de datos y del log de recuperación.

• BACKUPPOOL: Almacenamiento en disco para sostener datos.

• ARCHIVEPOOL: Almacenamiento en disco para datos archivados.

• SPACEMGPOOL: Almacenamiento en disco para datos. Este es ocasio-nalmente usado para ahorrar espacio.


Figura 8.9: Componenetes Básicos Instalados por el Tivoli Storage Manager


• DISKPOOL: Almacenamiento en disco sólo en Windows.

Verificar que la Instalación del Servidor Se Haya CompletadoSatisfactoriamente

Las instalaciones pueden ser verificadas en los sistemas Windows viendo elarchivo initserv.log.

8.2.2 Archivos de Licencias

Instalación de los Archivos de Licencias en Windows

Usar el acistente InstallShield para instalar la Licencia 5.2.0.0 del TivoliStorage Manager.

Licencias Básicas Soportadas por el Tivoli Storage Manager

El soporte de licencias basicas del Tivoli Storage Manager consiste en losiguiente:

• Un cliente local de backup de archivo.

• Un número ilimitado de clientes administrativos.

• Soporte de administración de la empresa.

• Soporte virtual de volumen servidor a servidor.

• Soporte de comunicación en Red.

Utilización del License Wizard Para Configurar Licencias

El License Wizard no será mostrado si no han sido instalados los paquetesde licencias del Storage Manager. El paquete de licencia es un componenterequerido por el Storage Manager.

Si la License Wizard no se muestra, se debe hacer lo siguiente:

1. Completar la secuencia de configuración del wizard.

2. Comenzar de nuevo el navegador del CD e instalar el paquete de licencia.


3. Retomar la consola del Storage Manager, expandir el árbol para el ser-vidor del Storage Manager que se está configurando, y hacer clic enWizards.

4. Seleccionar License Configuratión desde el wizards mostrado en el panelderecho y comenzar este wizard para registrar las licencias que se hancomprado.

Registrar y Consultar Licencias Desde la Línea de Comandos

Para saber qué licencias hay se puede usar el comando QueryLICense. Sepuede usar el comando REGister LICense para registrar una nueva licenciacon el servidor del Storage Manager. Las licencias son almacenadas en archivosllamados archivos certificado de inscripción. Estos certificados son archivosque contienen información de licencias para el producto del servidor. Cuandoson registradas, las licencias son almacenadas en un archivo llamado NODELOCK

en el directorio corriente desde el cual el servidor fue iniciado. Si un sistemadel Storage Manager excede los términos de su acuerdo de licencia, ocurre unode los siguientes hechos:

1. El servidor emite un mensaje de advertencia indicando que no está encumplimiento con los términos de la licencia.

2. Las operaciones fallan devido a que el servidor no es licenciado para si-tuaciones específicas. El Storage Manager requiere la licencia mgsyslan.licpara cada sistema manejado que mueve datos para, y desde el almace-namiento sobre una red de area local (LAN).

Los siguientes son ejemplos de archivos de certificado de inscripción pararegistrar a clientes adicionales:

• drm.lic para el Tivoli Disaster Recovery Manager.

• spacemgr.lic para Tivoli Space Manager.

• mgsyslan.lic para cada sistema manejado que mueve datos a través deuna LAN.

• mgsyssan.lic para cada sistema manejado que mueve datos a través deun SAN.


• oracle.lic para Tivoli Data Protection para Oracle.

• mssql.lic para Tivoli Data Protection para MS SQL.

• msexch.lic para Tivoli Data Protection para MS Exchange.

• lnotes.lic para Tivoli Data Protection para Lotus Notes.

• domino.lic para Tivoli Data Protection para Lotus Domino.

• informix.lic para Tivoli Data Protection para Informix.

• r3.lic para Tivoli Data Protection para R/3.

• ess.lic para Tivoli Data Protection para ESS.

• essr3.lic para Tivoli Data Protection para ESS R/3.

• emcsymm.lic para Tivoli Data Protection para EMC Symmetrix.

• emcsymr3.lic para Tivoli Data Protection para EMC Symmetrix R/3.

• library.lic para cada biblioteca en Extended Device Category.

• afsdfs.lic para cada sistema manejado que mueve datos usando elcliente AIX AFS/DFS.

• libshare.lic para el manejo de librerías que tienen acceso sobre unalibrería compartida.

8.2.3 Instalar el Packs de Lenguaje

Desde el Install Products, se puede seleccionar el lenguaje en el item LanguagePacks para leventar el Packs Lenguage de Window. La Language Packs deWindow permite escoger el paquete de lenguaje para la implementación delTivoli Storage Manager.

8.2.4 Instalación de los Drivers del Dispositivo

Instalación del Driver del Dispositivo en Windows

Para usar un dispositivo, se debe instalar el driver apropiado del dispositi-vo. Tivoli Storage Manager proporciona su propio driver de dispositivo para


dispositivos de no-IBM. Para plataformas Windows, un InstallShield Wizardes proporcionado para modificar, reparar, instalar, o remover el driver deldispositivo del Tivoli Storage Manager.

Tivoli Storage Manager además da soporte a los drivers de los dispositivosde vendedores de terceras partes si los dispositivos son asociado con el disposi-tivo de la clase GENERICTAPE y el vendedor de hardware también soporta estedriver de dispositivo. La utilización de otra clase de dispositivo distinta deGENERICTAPE con un driver de dispositivo de un vendedor de tercera parte noes recomendable. El driver del dispositivo del Tivoli Storage Manager es ge-neralmente el preferido para usar con el Tivoli Storage Manager. Es requeridopara usar con dispositivos de librerias automatizadas y dispositivos de discosópticos a no ser que se utilice el administrador Windows Removable Storagepara manejar los medios.

8.2.5 Instalación del Cliente

Instalación del Storage Manager Client y Lineas de Comandos deAdministración en Windows

El siguiente paso recomendado es instalar el backup-archive client. Laplataforma de Windows proporciona una InstallShield para el Tivoli StorageManager cliente. Se debe hacer una instalación Custom para obtener una ins-talación administrada del cliente. Se debe leer toda la documentación readmeproporcionada ántes de comenzar La documentación proporcionada antes decomenzar a instalar cualquier código del Storage Manager.

Identificar Los Requisitos Previos Del Cliente Web

Sistemas Operativos del Cliente Web Soportados:

• Hewlett-Packard HP-UX

• Linux for x86, Linux for IBM zSeries and S/390

• SGI IRIX UNIX

• OS/390 and Z/OS UNIX

• Sun Solaris

• Windows XP, Windows ME, Windows NT 4.0, SP5 y SP6,


• Windows 2000 Professional Server, Advanced Server, y DataCenter

• Tru64 UNIX

Requisitos Previos para Backup-Archive Client

Tivoli Storage Manager, Version 5.2 los clientes son soportados en los si-guientes sistemas operativos:

• AIX 5.1 and 5.2 (32-bit and 64-bit)

• HP/UX 11.0, 11i ( 32-bit and 64-bit)

• Linux x86 2.4 kernel (Red Hat 7.2, 7.3, 8, and Advanced Server 2.1;SuSE 7.3, 8.0, 8.1, and SLES 7 and 8; TurboLinux 7.5, and 8.0)

• Linux for pSeries 2.4 kernel (SuSE 8.0)

• Linux/390 and zSeries 2.4 kernel (SuSE Linux Enterprise Server 7 and8)

• Macintosh, X(10).x

• Novell NetWare 5.1, 6

• OS/390, zSeries USS (S/390 V2R10 with SMP/E, z/OS V1R1, V1R2,V1R3, and V1R4)

• OS/400 5.1 or 5.2 API client

• SGI IRIX UNIX, Release 6.5 with EFS or XFS File Systems (with V5.1functional client)

• Sun Solaris, 7, 8, or 9 (32-bit or 64 bit)

• Tru64 UNIX, Version 5.1A (with V5.1 functional client)

• Windows XP (32 bit and 64 bit), Windows Server 2003 (32 bit or 64bit), Windows 200

• Professional Server, Advanced Server, and Datacenter Server

• Windows NT 4.0 SP5 and SP6a (with V5.1 functional client)

• Novell NetWare 5.1, 6


Instalación de la Linea de Comandos del Cliente Administrativo

Para Windows, usar la InstallShield Wizard del Tivoli Storage ManagerClient para instalar los archivos de la linea de comandos del cliente adminis-trativo.

Esto instala un cliente administrativo con lo siguiente por defecto:

User ID: admin

Password: admin

8.2.6 Instalación y Configuración de una Libreria de CintaAdosada al Tivoli

Figura 8.10: Instalación y Configuración de una Libreria de Cinta


La combinación de la librería , el o los manipuladores, y su clase de dispositivosrepresenta el ambiente físico del dispositivo fig.8.10de la pág.139. Una libreríafísica es una colección de uno o más manipuladores que comparten similaresrequerimientos de medios de montaje. Cada mecanismo manipulador (driver)dentro de un dispositivo (que usa medios de comunicación desmontables) esrepresentado por un objeto manipulador. Para dispositivos con múltiples ma-nipuladores, incluyendo librerías automatizadas, cada manipulador es definidoseparadamente y debe ser asociado con una librería.

Un manipulador es un dispositivo de hardware capaz de realizar opera-ciones sobre un tipo específico de medios secuenciales. Las definiciones demanipulador pueden incluir información tal como la dirección del elemento(para manipuladores en librerías SCSI), cuán a menudo debe ser limpiada launidad manipuladora (para unidades de cinta magnética), y si realmente ono el manipulador está en línea. Cada dispositivo definido al Tivoli StorageManager es asociado con una clase de dispositivo. Esta clase de dispositivoespecifica un tipo de dispositivo y la información de administración del medio,como la grabación del formato, capacidad estimada, y prefijos de etiquetado.

Una clase de dispositivo para una cinta o manipulador óptico debe tambiénespecificar una librería.

Conectar la Librería

Realizar los siguientes pasos para unir un dispositivo de librería automati-zada, fig. 8.11 de la pág. 141:

1. Instalar el SCSI o tarjeta adaptadora FC en el sistema, si ya no fueinstalada.

2. Determinar el SCSI IDs disponible en la tarjeta adaptadora a la que seunirá el dispositivo. Buscar un SCSI ID no usado para cada manipula-dor, y uno para la librería o el controlador autocambiador. En algunasbibliotecas automatizadas, los manipuladores y el autocambiador com-parten un solo SCSI ID, pero tienen diferentes LUNs. Para estas libre-rías, es requerido sólo un SCSI ID. Comprobar la documentación parael dispositivo.

Seguir las instrucciones del fabricante para poner el SCSI ID para los mani-puladores y el regulador de la librería a los SCSI IDs no usado que se encontró.Por lo general esto significa configurar switches atrás del dispositivo.


Figura 8.11: Conectar la Librería


Nota: Cada dispositivo conectado en una cadena a un solo bus SCSI debeestar puesto a un único SCSI ID. Si cada dispositivo no tiene un SCSI IDúnico, el sistema puede tener serios problemas.

Nota: Apagar el sistema antes de agregar un dispositivo para prevenirdaño al hardware. También, se debe agregar un terminator al último dis-positivo en la cadena de dispositivos conectados en una tarjeta adaptadoraSCSI.

Adquisición de Información Para el Storage Manager Device Dri-ver

Usar los Wizards asociados con el servidor TSM para acceder al Devi-ce Configuration Wizard y ver información de configuración de dispositivosexistentes.

Determinación de Números para Librerías con Múltiples Drives

La dirección del elemento es un número que indica la posición física de unmanipulador dentro de una librería automatizada, fig. 8.12 de la pág. 143.El Tivoli Storage Manager necesita la dirección del elemento para conectar laposición física del manipulador a las direcciones SCSI de los manipuladores.Cuando se define un manipulador, el múmero del elemento es requerido sólopor las librerías de tipo SCSI, no para la 3494, StorageTek con ACSLS, olibrerías de tipo manuales.

Guardar las Hojas de Trabajo: La información que se registra en las ho-jas de trabajo puede ayudar cuando se tiene que realizar operaciones comola agregación de volúmenes a un autocambiador. Guardarlas para futurasreferencias.

Configurar el Modelo de Librería: Para que el Tivoli Storage Managertenga acceso a una librería SCSI, el dispositivo debe estar configurado demado apropiado. El modo que el servidor requiere es generalmente llamadomodo random; sin embargo, la terminología puede variar de un dispositivo aotro.

Dos ejemplos:

• Algunas librerías tienen paneles de menús frontales y muestran que pue-den ser usados para solicitudes explícitas de operadores. Sin embargo, siel dispositivo es configurado para responder a tal solicitud, este típica-


Figura 8.12: Determinación de Números para Librerías con Múltiples Drives


mente no responderá a solicitudes hechas por el Tivoli Storage Manager.

• Algunas librerías pueden ser puestas en modo secuencial, en el cual losvolúmenes automáticamente montados en drives usando un acceso se-cuencial. Este modo está en desacuerdo con como Tivoli Storage Mana-ger accede al dispositivo.

Una función disponible en 5.2 es la capacidad de autodescubrir un númerode elemento. Dependiendo en las capacidades de la librería, ELEMENT=AUTODETECTno puede ser soportado. En este caso se tendrá que suministrar la direccióndel elemento.

Usar el comando mttest para verificar que el dispositivo estaconectado

Es posible realizar un rastreo del driver del dispositivo sin comenzar elrastreo del driver del dispositivo con la línea de comandos. Esto puede sermuy provechoso cuando se trata de diagnosticar a un determinado driver enel Storage Agent.

Usar tsmdlst para verificar dispositivos encontrados.

Usar lbtest para testear problemas en manipuladores y librerías.

Para probar problemas en el manipulador o la librería con los manipula-dores y librerías 3490, 3570, 3575, y 3590, usar el comando tapeutil.

Para cintas de I/O en los manipuladores, usar el comando mttest.

8.2.7 Trabajar con Medios

Preparación de Cartuchos de Cintas

Primero deben ser etiquetadas las cintas y luego agregarlas al inventariode cintas disponibles en el Tivoli Storage Manager. Las cintas pueden serchequeadas en el Tivoli Storage Manager tanto como liberada o disponible(scratch) o privadas. Las cintas que son parte del scratch pool son eligiblespara ser seleccionadas para uso. Una vez que una cinta es seleccionada, losdatos permanecen sobre la cinta hasta que sea expirada o movida. La cintaentonces puede ser reclamada y devuelta al scratch pool, fig. 8.13 de la pág.145.


Figura 8.13: Preparación de Cartuchos de Cintas


Hay varios métodos para controlar una cinta. Pueden ser controladas enlínea o fuera de línea.

Etiquetar Volúmenes con el Labeling Wizard

Todos los medios requieren etiquetas. Etiquetar los medios con una libre-ría automatizada es diferente a etiquetar medios con un dispositivo manualporque una librería automatizada requiere que se compruebe los medios en lalibrería. El procesamiento extra check-in puede ser hecho al mismo tiempo queel volumen es etiquetado. Si se etiquetan volúmenes con el Labeling Wizard,se puede seleccionar el procesamiento check-in en el wizard. Una etiqueta nopuede incluir espacios en blanco o períodos y debe ser válida cuando es usadacomo un nombre de archivo en el medio.

Para etiquetar medios con una librería automatizada, inserte los mediosen las ranuras de almacenamiento o puertos de entrada/salida e invoque alLabeling Wizard.

Etiquetar Volumenes Usando DSMLABEL

Etiquetar Cintas con LABEL LIBVOLUME

Si se etiqueta volúmenes con el comando LABEL LIBVOLUME, se puede emitirel parámetro CHECKIN.

Se puede etiquetar volúmenes con el comando LABEL LIBVOLUME.

Diferencias Entre Scratch y Privados

Un volumen privado es un volumen etiquetado que está en uso u ocupadopor una aplicación y puede contener datos válidos. Se debe definir cada vo-lumen privado, y este sólo puede ser usado para satisfacer una petición paramontar el volumen llamado. Los volúmenes privados no retornan al scratchcuando estàn vacíos.

Un volumen scratch es un volumen etiquetado que es vacío o no contienedatos válidos y puede ser usado para satisfacer cualquier petición al montarun volumen scratch. Cuando los datos son escritos a un volumen scratch, suestado cambia a privado.

Se puede cambiar el estado de los volúmenes usando el comando UPDATE

LIBVOLUME. El comando permite asignar un estado privado a un volumen scrat-ch o asignar un estado scratch a un volumen privado. Los volúmenes privadosdeben ser volúmenes definidos por el administrador con ningun dato o con


datos inválidos. Ellos no pueden ser volúmenes parcialmente escritos, contie-nen datos activos. La estadística del volumen se pierde cuando el estado delvolumen es modificado.

Checking In Volumes

Después de que han sido etiquetado los volúmenes, hacer disponibles los vo-lúmenes al dispositivo del Tivoli Storage Manager para comprobar los volúme-nes en el inventario de volumenes de la librería usando el comando CHECKIN

LIBVOLUME. La comprobación de los medios en una librería automatizada im-plica la adición de ellos al inventario de volumenes de la librería.

Creación de Cintas Scratch Usando el Comando LABEL LIBVo-lume

El comando LABEL LIBVolume combina los comandos DSMLABEL y CHECKIn

LIBVolume con los que fueron usados en las versiones anteriores del TSM,fig. 8.14 de la pág. 148. La utilización de un comando LABEL LIBVolume

reduce considerablemente el tiempo y la interacción requerida durante estasdos operaciones de trabajo intensivo.

Este comando, sin embargo, no sustituye el método anterior del DSMLABELseguido del CHECKIn LIBVol para impedir etiqutar cinta en gran escala des-de los recursos del servidor. El comando LABEL LIBVol permite a todas lasfuncionalidades del comando DSMLABEL, como la búsqueda, código de barras,y sobreescribir opciones. LABEL LIBVol además comprueba los volúmenes enla librería como volúmenes privados o scratch.

Comprobar la Extracción de Volúmenes

Se puede quitar volúmenes de la librería automatizada ejecutando el co-mando CHECKOUT LIBVOLUME.

El Tivoli Storage Manager monta cada volumen y verifica su etiqueta in-terna antes de comprobarlos en el inventario de volumenes. Después de queun volumen ha sido verificado, Tivoli Storage Manager mueve los medios alpuerto de entrada/salida del dispositivo si este tiene uno, o el Tivoli StorageManager solicita que el operador quite el volumen de un manipulador dentrodel dispositivo. Para librerías automatizadas con múltiples puertos de entra-da/salida, se puede ejecutar el comando CHECKOUT LIBVOLUME con el paráme-tro SEARCH=BULK. El Tivoli Storage Manager expulsa el volumen al siguientepuerto de entrada/salida disponible.


Figura 8.14: Creación de Cintas Scratch


Auditar una Librería

Se puede ejecutar el comando AUDIT LIBRARY para revisar los inventariosde volumenes de las librerías automatizadas, fig. 8.15 de la pág. 149.

Figura 8.15: Auditar una Librería

Auditar el inventario de volumenes asegura que la información mantenidapor el servidor Tivoli Storage Manager es compatible con los medios físicos enla librería. La auditoría es útil cuando el inventario ha sido manipulado ma-nualmente. Tivoli Storage Manager elimina volúmenes que fallan y actualizalas localizaciones de los volúmenes que se han movido desde la última audito-ría. Tivoli Storage Manager no puede añadir nuevos volúmenes durante unaauditoría.


8.3 Manejo de Pools de Almacenamiento y Volúme-nes de Pool de Almacenamiento

8.3.1 Pools de Almacenamiento, Jerarquías de Pool de Alma-cenamiento y Volúmenes de Pool de Almacenamiento

Los pools de almacenamiento de datos son donde el servidor almacena losarchivos que son resguardados y archivados, fig. 8.16 de la pág. 150. La basede datos sirve como el inventario o el índice para archivos de cliente dentrodel almacenamiento de datos.

Figura 8.16: Pools de Almacenamiento

El almacenamiento de datos puede ser compuesto de medios ópticos, al-macenamiento de acceso directo, y medios de cinta secuencial. Los archivos alprincipio pueden ser colocados en diferentes pools de almacenamiento segúnla política de administración de almacenamiento deseada. Los archivos sonautomáticamente movidos a otros dispositivos para satisfacer espacio libre,

8.3. MANEJO DE POOL Y VOLÚMENES 151

utilización del espacio, rendimiento, y requerimientos de recuperación.

Un administrador con el sistema, almacenamiento, o privilegio de operadorpuede manejar el almacenamiento de los datos. Esto incluye planificación,preparación, monitorización, y eliminación de volúmenes de almacenamientoy pools de almacenamiento dependiendo del nivel de la clase de privilegio.

El almacenamiento de datos en realidad es definido como una colección depools de almacenamiento.

Jerarquías del Pool de Almacenamiento

Figura 8.17: Jerarquías del Pool de Almacenamiento

Se llama pool de almacenamiento a un conjunto de volúmenes, pertenecien-tes a la misma clase de dispositivo, que es el destino de los datos b-upeados oarchivados. Una clase de dispositivo es una agrupación de dispositivos pareci-dos, como el disco o la cinta.

El objetivo de los pools de almacenamiento es agrupar requerimientos deusuario para datos con las características físicas del dispositivos de almace-namiento. Por ejemplo, si los usuarios necesitan acceso inmediato a ciertos


datos, se puede definir un pool de almacenamiento, que consiste en volúmenesde almacenamiento que residen en un DASD ( Dispositivo de Almacenamientode Acceso Directo - un término de IBM para un disco duro) de alto rendimien-to. Entonces, los usuarios pueden asociar este pool de almacenamiento comoun destino para sus archivos buscando la clase de administración apropiada.

Los pools de almacenamientos pueden ser encadenados para crear unajerarquía de almacenamiento, fig. 8.17 de la pág. 151.

Clases de Dispositivos

Una clase de dispositivo representa un conjunto de dispositivos de almace-namiento con similar disponibilidad, rendimiento, y caracterí sticas de alma-cenamiento. Estos tipos de dispositivo son manejados por el TSM. TSM usala clase de dispositivo para determinar qué dispositivo y tipo de volumen dealmacenamiento se usará:

• Almacenar Backup, archivos a proteger, o espacio de datos administrado(pools de almacenamientos primarios).

• Almacenar copias de datos primarios del pool de almacenamiento (copiade los pools de almacenamiento).

• Almacenar backups de base de datos.

• Exportación o importación de datos del TSM.

Una clase de dispositivo puede ser asociada con múltiples pools de alma-cenamiento. Cada pool de almacenamiento es asociado con sólo una clase dedispositivo. Cada clase de dispositivo es caracterizada por su tipo de disposi-tivo, que indica el tipo de los volúmenes de almacenamiento que son usadospara almacenar datos.

Para almacenamiento de acceso random, TSM soporta sólo la clase dedispositivo DISK. La clase de dispositivo DISK es predefinida por TSM. Sinembargo, se puede definir muchos pools de almacenamiento asociados con laclase de dispositivo DISK. No se puede modificar la clase de dispositivo DISK.

Basado en el ambiente de cinta, un administrador con privilegio del sistemapuede definir tantas clases de dispositivo diferentes para pools de almacena-miento de cinta como sea necesario. Cada clase de dispositivo de cinta es


únicamente identificada por su nombre. No todas las clases de dispositivoestán disponibles en todas las plataformas.

Las clases de dispositivo de cinta permiten en la instalación el control delo siguiente:

• Si se usará cartucho (cartridge) o carrete de cinta (reel tape).

• El máximo número cintas que pueden ser montadas simultáneamente.

• Los minutos máximos antes de que la cinta ociosa sea desmontada.

• La convención para la denominación de los volúmenes.

• La capacidad de volumen estimada, ya que por default no considera eluso de compresión por el cliente o el hardware de cinta.

Clases de Dispositivos y Pool de Almacenamiento

Figura 8.18: Clase de Dispositivos y Pool de Almacenamiento


Cada dispositivo es asociado con una clase de dispositivo que especifica eltipo de dispositivo y como el dispositivo maneja sus medios.

Los pools de almacenamiento son mapeados a una clase de dispositivo. Espor este mapeamiento que, cuando los datos son escritos a o accedidos desdeun pool de almacenamiento, TSM conoce las características de dispositivo delmedio del pool de almacenamiento y como tener acceso a ello, fig. 8.18 de lapág. 153.

Destinación de Almacenamiento

Figura 8.19: Destinación de Almacenamiento

Un destino de almacenamiento identifica el pool de almacenamiento dondelos datos del cliente son enviados cuando son resguardados, archivados, o mi-grados. Es especificado en las definiciones del backup y del grupo de copia dearchivo que son incluidas en la clase de administración. La colocación de da-tos es además influenciada por la configuración de los pool de almacenamientoque pueden restringir los accesos de lectura/escritura y el límite de tamaño dearchivos colocados en el pool de almacenamiento, fig. 8.19 de la pág. 154.


Definición de los Pools de Almacenamiento

Las siguientes tareas son asociadas con la administración de los pools dealmacenamientos y sus volúmenes.

Durante la instalación, TSM provee pools de almacenamientos de accesorandom predefinidos:

• BACKUPPOOL - un destino de almacenamiento para los archivos deusuarios que son resguardados en el servidor.

• ARCHIVEPOOL - un destino de almacenamiento para los archivos deusuarios que son archivados en el servidor.

• SPACEMGPOOL - un destino de almacenamiento para archivos migra-dos desde los nodos de usuarios.

• DISKPOOL - Sólo para sistemas Windows.

• FILPOOL1 - un pool de almacenamiento por defecto de la clase de dis-positivo FILEDEV1 creando como defecto Next Storage Pool para AR-CHIVEPOOL como para BACKUPOOL.

Actualización y Preguntas en los Pools de Almacenamiento

Usar el comando UPDate STGpool para cambiar cualquier parámetro enun pool de almacenamiento existente.

Se puede usar este comando para modificar parámetros seleccionados parael pool de almacenamiento especificado. Si no se actualiza explícitamenteun parámetro, este permanece inalterado. Los parámetros de actualizaciónson los mismos que los parámetros que se utilizan para definir un pool dealmacenamiento.

Usar el comando Query STGpool para mostrar la información sobre uno omas pool de almacenamiento.

Para la sintaxis de los comandos ir al Tivoli Storage Manager Adminis-trator’s Guide o emitir el comando HELP UPDate STG o HELP Query como unadministrador.

Definición de Volumenes de Pool de Almacenamiento


Usar el comando DEFine VOLume para asignar un volumen de acceso ran-dom o secuencial para ser usado para almacenamiento dentro de un pool dealmacenamiento existente. Se puede definir un volumen para un pool de al-macenamiento primario o un pool de almacenamiento de copia.

Se debe definir cada volumen para ser usado en un pool de almacenamientoa no ser que se permitan volúmenes scratch para el pool de almacenamiento.Antes de emitir este comando para un volumen de acceso random, se debeasignar y formatear el volumen usando la utilidad DSMFMT, o el comandoDEFine VOLume del TSM con el parámetro formatsize.

Para pools de almacenamiento de acceso secuencial con un tipo u otrode dispositivo como FILE o SERVER se debe preparar los volúmenes parasu uso. Cuando el servidor tiene acceso a un volumen de acceso secuencial,este comprueba el nombre del volumen en el principal para asegurar que estasiendo accedido el volumen correcto.

Eliminar Pools y Volúmenes de Almacenamiento

MOVE DATA - Usar el comando MOVE DATA para mover todos los ar-chivos a otro volumen.

Solicitar explícitamente para desechar todos los archivos en el volumen dealmacenamiento especificando la siguiente opción:

DISCARDDATA= YES

DELETE VOLUME - Usar el comando DELete VOLume para eliminar unvolumen del pool de almacenamiento y, opcionalmente, los archivos dentro delvolumen. Este comando puede ser usado para eliminar un volumen asignado aun pool de almacenamiento primario o de copia. Si durante el procesamientode este comando para un volumen del pool de almacenamiento primario, elTSM elimina la copia principal de un archivo (no una copia cached), entoncesel TSM además elimina cualquier copia de aquel archivo que reside en los poolsde almacenamiento de copia.

Si se va a eliminar varios volúmenes, es recomendado que se elimine losvolúmenes uno por uno.

La eliminación simultánea de volúmenes puede afectar desfavorablementeel rendimiento del servidor.

QUERY CONTENT - Para determinar el contenido almacenado en un


volumen, usar el comando Query CONtent.

DELETE STGPOOL - Usar el comando DELete STGpool para eliminarun pool de almacenamiento.

Para usar este comando, primero se debe eliminar todos los volúmenesasignados al pool de almacenamiento especificado.

No se puede eliminar un pool de almacenamiento que esta definido comoun pool de almacenamiento subordinado.

No eliminar un pool de almacenamiento que esta especificado como desti-nación para una clase de administración o grupo de copia en el conjunto depolítica ACTIVE.

Desbordamiento de los Pools de Almacenamiento

• Usado cuando el volumen de la librería se llena

• Volúmenes de pool de copias o primarios

• Volúmenes movidos manualmente a la posición desbordada

Rastreo de Base de Datos

Usar el rastreo de base de datos para actualizar la posición del volumena una posición de desbordamiento especificada. Los desbordamientos de lospools de almacenamientos permiten al administrador del TSM un mejor ma-nejo de los pools de almacenamiento que crecen más allá de la capacidad dela librería. El rastreo de la base de datos es utilizada principalmente parapools de almacenamientos de archivo long-term donde los datos son manteni-dos localmente, pero raramente son recuperados para procesamiento del TivoliStorage Manager.

La primera etapa en la implementación de desbordamiento de un poolde almacenamiento debe definir la localización de los volúmenes cuando ellosse desbordan de la librería. Esto puede ser hecho con el comando DEFine

STGpool o el UPDate STGpool y el nuevo parámetro OVFLOCATION. Este pa-rámetro es una descripción de texto de donde los volúmenes pueden ser encon-trados. No hay ningún valor por defecto para este parámetro. La descripciónpuede aumentar en la longitud a 255 carácteres.


La localización de desbordamiento para un pool de almacenamiento pue-de ser mostrada usando el comando Query STGpool F=D (Format=Detail).Esto produce la salida mostrando el nombre del pool de almacenamiento, eltipo, la clase de dispositivo asociada, la capacidad estimada, y la localizaciónde desbordamiento.

8.3.2 Mover Datos

Mover Datos a Nodo

La operación MOVE NODEDATA puede aparecer incompleta por ciertas razo-nes.

Un ejemplo:

• La operación de mover datos de nodo es comenzada

MOVE NODEDATA bob FROMSTG=stgpoola

TOSTG=stgpoolb type=backup.

• El siguiente MOVE DATA estan ya en progreso.

MOVE DATA vol3 STGPOOL=stgpoola

Al principio, la operación de mover nodo determina que el VOL1, VOL2y VOL3 son los volúmenes que tienen datos para el nodo BOB y encola aque-llos volúmenes en una lista para procesarlos. Sin embargo, por el tiempo laoperación de mover datos de nodo en realidad comienza a procesar el VOL3,todos los datos de BOB en el VOL3 pueden haber sido movidos a otro volu-men, debido a la operación MOVE DATA, y así no estarían disponibles para laoperación MOVE NODEDATA.

El comando MOVE NODEDATA puede ser usado para mover datos en un poolde almacenamiento de acceso secuencial para uno o varios nodos y es útil paraconsolidar datos para un nodo específico dentro de un pool de almacenamiento.Esto es provechoso para reducir el número de montajes de volumen requeridosdurante una operación de restauración.


MOVE NODEDATA también puede ser usado mover datos de un nodo a diferen-tes pools de almacenamiento. Esto es provechoso preparando procesamientode restauración para el cliente moviendo los datos principales a un pool dealmacenamiento de acceso random.

El proceso MOVE NODEDATA hace lo siguiente:

• Crea una lista de nodos y espacios de archivo al mover basandose en loscriterios del usuario especificados en el comando MOVE NODEDATA.

• Comienza un hilo de la cola para determinar una lista de volúmenes paraprocesar.

• Los volúmenes agregados a esta lista tienen los criterios siguientes:

Acceso READWRITE o READONLY.

Tienen datos para el nodo y espacios de archivo especificados por el usuario.

• Además de la lista de volúmenes creada se hace la lista de volúmenespara excluir.

• Una vez que un hilo de la cola esta completo se comienza un hilo deproceso.

El número de hilos de proceso comenzados es determinado por el parámetroMAXPROCESS.

Cada hilo de proceso que es comenzado hace lo siguiente:

• Selecciona un volumen desde la lista de volumen.

• Procesa cada bitfile en el volumen para determinar si debería ser movido.

• Usa las funciones de mover datos para batck up el archivo y mover elbitfile.

Movimiento Automatico de Datos

El movimiento automático de datos entre pools de almacenamientos esusado para equilibrar el rendimiento y el costo de diferentes dispositivos de


Figura 8.20: Movimiento Automático de Datos


almacenamientos asegurando el espacio adecuado libre para satisfacer nuevaslocalizaciones de espacios. Estos procesos son conocidos como migración. Paracada pool de almacenamiento, se definen puertas de migración altas y bajas.La puerta baja identifica la cantidad de espacio libre necesario para satisfacerlas exigencias de requerimientos de procesamientos diarios del negocio. Lapuerta alta es usada para provocar la migración y asegurar que está disponiblebastante espacio libre mientras la migración es realizada. La diferencia entrelas puertas altas y bajas indica la cantidad aproximada de datos que seránmigrados, (fig. 8.20 de la pág. 160.

Para reducir el montado de cintas y para usar el espacio en los volúmenesde cinta más eficientemente (cuando la colocación no es usada), asegurar quela cantidad de datos que son migrados desde un pool de almacenamiento dedisco es múltiple a la capacidad de un volumen de cinta en el siguiente po-ol de almacenamiento. El movimiento de datos automáticamente es ademásusado para liberar en los volúmenes de cinta consolidando datos activos devolúmenes de cinta fragmentados en un sólo volúmen, dejando los volúmenesoriginales disponibles para la reutilización. Estos procesos son conocidos co-mo recuperación. Para cada pool de almacenamiento de cinta, se define unapuerta de recuperación, que indica la cantidad de espacio consumido por losdatos que no son válidos antes de generar la recuperación. Se recomienda noespecificar un valor menor al 50 % para evitar la recuperación de volumen decinta a múltiples volúmenes.

8.3.3 Migración del Pool de Almacenamiento

Cuando el límite superior de migración se alcanza en un pool de almacenamien-to, el TSM migra los archivos del pool al siguiente pool de almacenamientoen la cadena. Ninguna migración ocurre si no hay un siguiente pool de al-macenamiento. El TSM primero identifica cuál nodo cliente fue respaldadoo migrado y los archivos que ocupan la mayor parte de espacio. Cuando elservidor identifica el nodo cliente basado en estos criterios, el servidor migratodos los archivos de cada espacio de archivo que pertenece a aquel cliente pa-ra aquellos archivos cuyo número de días en el pool de almacenamiento excedeel valor especificado por el parámetro MIGDELAY, (fig. 8.21 de la pág. 162.

Después de que los archivos para el primer nodo cliente son migrados alsiguiente pool de almacenamiento, el servidor comprueba el límite inferiorde migración para el pool de almacenamiento al determinar si el proceso de


Figura 8.21: Migración del Pool de Almacenamiento


migración ha finalizado. Si la cantidad de espacio usado en el pool de almace-namiento está ahora por debajo del límite inferior de migración, la migraciónfinaliza. Si no, usando los mismos criterios descritos arriba, TSM escoge otronodo cliente, y el proceso de migración sigue.

Si el valor para MIGCONTINUE ha sido puesto a YES, entonces TSM sigue elproceso de migración basado en cuánto tiempo los archivos han estado en elpool de almacenamiento. Los archivos más viejos son migrados primero hastaque el límite inferior de migración sea alcanzado. Si el valor para MIGCONTINUE

ha sido puesto a NO, entonces los procesos de migración terminan, y un mensajede advertencia será emitido al administrador.

Si múltiples procesos de migración son ejecutados (controlados por el pa-rámetro MIGPROCESS del comando DEFine STGpool), los archivos para másque un nodo pueden ser escogidos para la migración al mismo tiempo.

Si la opción cache es permitida, los archivos que se migran permanecenen el almacenamiento de disco (es decir los archivos son cached) hasta que elespacio sea necesario para nuevos archivos. Se puede permitir caching espe-cificando CACHE=YES cuando se define o actualiza un pool de almacenamientode disco. Cuando se permiten caching, el proceso de migración deja copias dearchivos en disco después de que el servidor migra estos archivos a los poolsde almacenamiento subordinados en la jerarquía de almacenamiento. Las co-pias permanecen en el pool de almacenamiento de disco, pero en un estadode cached, de modo que peticiones de recuperación subsecuentes puedan sersatisfechas rápidamente. Sin embargo, si el espacio es necesario para almace-nar nuevos datos en el pool de almacenamiento de disco, archivos cached sonborrados y el espacio que ellos ocuparon es usado para los nuevos datos.

La ventaja de usar un cache para un pool de almacenamiento de disco esque el caching puede mejorar cuán rápidamente el servidor recupera algunosarchivos. Cuando se usa un cache, una copia del archivo permanece en elalmacenamiento de disco rápido después de que el servidor migra el archivoprimario a otro pool de almacenamiento. Se puede querer usar un pool dealmacenamiento de disco con caching permitido para almacenar archivos queson frecuetemente accedidos por los clientes.

Sin embargo, usar un cache tiene algunas desventajas importantes, como:

• Puede aumentar el tiempo para operaciones de backup completos delcliente.


• Puede requerir más espacio para la base de datos del TSM.

8.3.4 Reclamación

Figura 8.22: Reclamación

El espacio en un volumen secuencial se hace recuperable cuando los archivosexpiran o son eliminados del volumen.

La recuperación es el proceso de reclamar este espacio. Por ejemplo, losarchivos se hacen obsoletos debido al envejecimiento o límites en el número deversiones de un archivo, (fig. 8.22 de la pág. 164.

Cuando el porcentaje de espacio recuperable excede un nivel especificado(del límite de recuperación), el volumen es eligible para la recuperación. Elservidor comprueba si la recuperación es necesaria al menos una vez por horay comienza la recuperación del espacio para volúmenes eligibles. Se puedeconfigurar un límite de recuperación para cada pool de almacenamiento deacceso secuencial cuando se define o actualiza el pool.


Cuando múltiples volúmenes son eligibles para la recuperación, TSM re-clama los volúmenes eligibles en orden aleatorio.

El espacio dentro de archivos agregados es también reclamado duranteel proceso de recuperación. Un agregado es un archivo físico que contienemúltiples archivos lógicos resguardados o archivados de un cliente en una solatransacción. El espacio no usado de archivos lógicos expirados o eliminadoses quitado tal como el archivo agregado es copiado a otro volumen durante larecuperación.

1. Recuperación de una Sóla Unidad

Recuperación del espacio.

• Pools de almacenamiento de medio de acceso secuencial.

Parámetro RECLAIMSTGPOOL del pool de almacenamiento.

• Usado como área de organización durante la recuperación.

Requerimientos de espacios.

• Sin tamaño mínimo.

El tamaño relacionado con la puerta de recuperación o el pool de almace-namiento para ser reclamado.

RECLAIMSTGPOOL indica otro pool de almacenamiento que puede ser usadocomo el área de propiedad para los datos que están siendo consolidados.

El pool de almacenamiento especificado como el pool de almacenamientoreclamado puede ser cualquier pool de almacenamiento primario en el sistemao un nuevo pool de almacenamiento primario creado para este propósito. Elúnico pool de disco permitido es uno con DEVTYPE=FILE. Un pool de alma-cenamiento de copia no puede se definido como un pool de almacenamientoreclamado devido a que los datos sólo pueden ser copiados a o un pool dealmacenamiento de copia, no movido.

Ejemplo de Reclamación de una Sóla Unidad


• Permite a que los datos sean reclamados dentro de la jerarquía.

• Deben ser medios de accesos secuenciales.

• Tiene el pool siendo reclamado como su NEXT pool de almacenamiento.

La recuperación de la unidad es efectivamente una automatización del co-mando MOVE DATA y la migración del pool de almacenamiento. El procesoMOVE DATA mueve sólo los datos que no han expirado desde el pool de al-macenamiento para ser reclamado al RECLAIMSTGPOOL. Estos datos entoncespueden ser migrados hacia atrás en la jerarquía de almacenamiento del TSMa los volúmenes del pool de almacenamiento ahora vacíos.

La segunda mitad del proceso de recuperación de una sóla unidad implicala migración TSM. Esto significa que una reclamación del pool de almacena-miento debería tener el pool de almacenamiento que se está reclamado comosu NEXT pool de almacenamiento en la jerarquía TSM. Esto permite que losdatos movidos en el pool de almacenamiento reclamado por el proceso derecuperación sean migrados hacia atrás a través de la jerarquía TSM.

El tapepool es definido con el diskpool como su pool de almacenamientoreclamado, y el diskpool es definido con el tapepool como su NEXT pool dealmacenamiento.

8.3.5 Colocación

La colocación es un proceso en el cual el servidor intenta mantener archivosque pertenecen a un solo nodo cliente o a un solo espacio de archivo de unnodo cliente en un número mínimo de volúmenes de almacenamiento de accesosecuenciales, fig. 8.23 de la pág. 167. Se puede configurar la colocación paracada pool de almacenamiento de acceso secuencial cuando se define o actualizael pool.

Para tener datos colocados en un pool de almacenamiento TSM para el no-do cliente, se pone la colocación a YES. Para tener datos colocados en un poolde almacenamiento TSM para un espacio de archivo cliente, configurar la colo-cación a FILESPACE. Usando la colocación, se reduce el número de operacionesde montaje de volumen requerido cuando los usuarios restauran, recuperan,o consultan muchos archivos desde el pool de almacenamiento. La colocaciónmejora así el tiempo de acceso para estas operaciones.


Figura 8.23: Colocación


Si la colocación está permitida y la recuperación ocurre, el servidor tratade reclamar los archivos para cada nodo cliente o el espacio de archivo delcliente en un número mínimo de volúmenes.

Capítulo 9

Políticas de Administración

9.1 Introducción

La política de administración permite al administrador determinar un con-junto de reglas explicando cómo Tivoli Storage Manager tratará los datos.Este conjunto de reglas está compuesto de dominios de política, conjuntos depolítica, clases administradoras, y grupos de copia.

9.2 Como TSM Maneja Datos

9.2.1 Políticas de Negocio Manejadas Centralmente

Basado en acuerdos de niveles de servicios con datos de los propietarios, eladministrador del Storage Manager puede planificar lo siguiente:

• Qué datos resguardar.

• Qué datos archivar.

• Dónde almacenar los datos.

• Número de versiones a conservar.

• Período de retención.

169

170 CAPÍTULO 9. POLÍTICAS DE ADMINISTRACIÓN

• Otras especificaciones basadas en las necesidades del negocio.

Estos planes son entonces implementados a través de políticas de adminis-tración, (fig. 9.1 de la pág. 170).

Figura 9.1: Políticas de Negocio Manejadas Centralmente

Descripción de Política de Administración

Las políticas son creadas por el administrador y almacenadas en la basede datos del servidor. Varios elementos comprenden la política:

• Dominio de la Política - un grupo de nodos administrados por elmismo conjunto de política coaccionan como definidas por los conjuntosde políticas. Un nodo sólo puede estar definido a un dominio de políticapor servidor. Un nodo puede estar definido a más de un servidor StorageManager.

• Conjunto de Política - una colección de definiciones de clase de ad-ministración (MC). Un dominio de política puede contener un número

9.3. DEFINIR POLÍTICAS 171

de conjuntos de políticas, sin embargo, sólo un conjunto de política enun dominio puede ser activo a la vez.

• Clase de Administración - Una colección de atributos de administra-ción que describen backup y características de archivo. Hay dos conjun-tos de atributos CA (Clases de Administración), uno para el backup yotro para el archivo. Un conjunto de atributos es llamado un grupo decopia. Hay un grupo de copia de backup y un grupo de copia de archivo.Para clientes del Tivoli Space Manager sólo, hay parámetros que afectanla administración del espacio.

Especificación de Política

La política es definida tanto en el cliente como en el servidor. En el ser-vidor, un administrador es responsable de crear políticas que administraránlos datos del cliente y asociar clientes con un conjunto de políticas desde lascuales ellos pueden seleccionar. Como es mostrado en el diagrama, un dominiode política es usado para asociar lógicamente a clientes con un conjunto depolíticas.

El administrador es además responsable de definir una política por defecto,una que será usada a no ser que otra política sea explícitamente seleccionada.

El cliente, sin embargo, puede decidir anular la política por defecto y se-leccionar cualquier otra política que esta también en su dominio de política.Hay varias maneras para que el cliente pueda hacer esto:

• En la opción Include que está en la configuración del cliente o la opcióndel archivo.

• En el comando DSMC Archive.

• En el panel GUI del Archivo.

9.3 Definir Políticas

9.3.1 Dominios de Políticas

Un dominio de política proporciona un modo lógico de administrar backup ypolíticas de archivo para un grupo de nodos con necesidades comunes. Esto es


una colección de uno o varios nodos y una o más políticas. Cada dominio es unobjeto almacenado en la base de datos del Storage Manager con un nombreque contiene desde 1 a 30 carácteres. Los nombres de dominio de políticasdeberían ser significativos. No hay límites al número de dominios de políticasque pueden ser definidos en el servidor Storage Manager, (fig. 9.2 de la pág.172).

Figura 9.2: Dominios de Políticas

Un nodo cliente puede ser asociado con sólo un dominio de política en unservidor Storage Manager específico. Sin embargo, un cliente o nodo puedenser registrados (definidos) a más de un servidor. Cada dominio puede teneruno o más clientes o nodos asociados a él. Los clientes o nodos pueden serejeutados en la misma o en diferentes plataformas. En algunas instalacionesse puede ver que sólo requieren de un solo dominio de política.

Un dominio de política también contiene “un período de gracia” backup yun periodo de retención de archivo que actúa como una red de seguridad paraasegurar que los datos que han sido resguardados o archivados en un pool dealmacenamiento no son eliminados accidentalmente si estos pierden su backup

9.3. DEFINIR POLÍTICAS 173

o el grupo de copia del archivo.

Períodos de Retención de Gracia del Dominio De política

• El período de retención de gracia del dominio de la política es especifi-cado en comando DEFine DOmain.

• El período de gracia de retención por defecto del backup es de 30 (BACKRETention=30).

• El período de gracia de retención por defecto del Archivos es de 365(ARCHRETention=365).

• El período de retención de gracia del dominio de la política es usadocuando la MGMTCLASS por defeto no tiene ningún grupo de copia parabackup y archivo.

Cada dominio de política contiene un período de retención de gracia debackup y un período de retención de gracia de archivo. El período de retenciónde gracia es usado para proteger versiones de backup y copias de archivo deser inmediatamente eliminados cuando la clase administradora por defecto nocontiene un backup o un grupo de copia de arhivo.

9.3.2 Política por Defeto del Servidor

Tivoli Storage Manager proporciona un dominio de políticas predefinidas, con-junto de política, clase administradora, grupo de copia de backup, y grupo decopia de archivo. Cada política es almacenada en el servidor y llamada STAN-DARD. La utilización de los objetos de política proporcionados en el TivoliStorage Manager permite comenzar a usar el Tivoli Storage Manager inme-diatamente. Se puede adaptar la política estandar.

El Período de Gracia de Retención De backup - Especifica el número dedías a conservar una versión de backup cuando el servidor es incapaz de asociarde nuevo el archivo a una clase administradora apropiada. Por defecto es de30 días.

9.3.3 Configuraiones de Polítias Por Defecto en el DominioSTANDARD

Atributos del Grupo de Copia


Los atributos en el grupo de copia definen:

• El destino del pool de almacenamiento donde los datos respaldados oarchivados deben ser almacenados.

• El intervalo mínimo, en días, entre operaciones de archivo y backup.

• Si el archivo debe ser respaldado independientemente de si ha sido mo-dificado desde el último backup.

• Si el archivo puede estar en uso cuando un usuario intenta respaldar oarchivar el archivo.

• El número máximo de versiones diferentes de backup que pueden serconservadas para archivos no extensos en el sistema de arhivos del cliente.

• El período de retención, en días, para todos excepto la versión másreciente del backup, y para la última versión restante de backup que esno extensa en el sistema de arhivos del cliente.

• El número de días que una copia de archivo debe ser conservada.

El conjunto de parámetros de backup define la frecuencia, el modo (modi-ficado o absoluto), el destino, la serialización de copia, el número de versiones,el número de versiones cuando el archivo es eliminado, días de retención paratodos excepto la última versión, y días de retención para la última versióncuando el archivo es eliminado.

El conjunto de parámetros de archivo define la frecuencia (siempre Cmd),el modo (siempre ABSolute), la destinación, la serialización de copia, y díasde retención para copias de archivo.

9.3.4 Opción Relacionada al Servidor: EXPINterval Hours

La opción EXPINterval Hours:

• Especifica el número de horas entre ejecuciones de expiración de inven-tario automáticas.

• Tiene un valor mínimo de 0, donde la expiración automática no ocurrey debe ser comenzada con el comando EXPIRE INVENTORY.

9.4. CONJUNTO DE POLÍTICAS 175

• Tiene un valor máximo de 336 (14 días).

• Tiene un valor por defecto de 24 días.

Las copias de los archivos que han expirado no son eliminados del al-macenamiento del servidor hasta que el procesamiento de expiración ocurra.Se puede ejecutar el proceso de expiración automáticamente o por coman-do. Se controla automáticamente el proceso de expiración usando la op-ción (EXPINTERVAL) del intervalo de expiración en las opciones del arhivo(DSMSERV.OPT) del Storage Manager.

El proceso de expiración entonces elimina las versiones eligibles de backupy copias de archivo archivados. Las versiones de backup son eligibles basadasen la política en el grupo de copia de backup (por cuánto tiempo y cuántasversiones inactivas son guardadas). Las copias del archivo arhivado son eligi-bles basadas en la política en el grupo de copia de archivo (por cuanto tiempolas copias archivadas son guardadas).

9.4 Conjunto de Políticas

9.4.1 Definición de un Nuevo Conjunto de Políticas

Cada onjunto de política contiene una clase administradora por defecto ypuede contener cualquier número de clases administradoras adicionales. Losconjuntos de política son usados para implementar políticas diferentes basadasen requerimientos de negocios y usuarios.

Usar el comando ASSIGN DEFMGMTCLASS para especificar una clase admi-nistradora existente como la clase administradora por defecto para un conjuntoparticular de política. Se debe asignar una clase administradora por defectopara un conjunto de política antes de que se pueda activar aquel conjuntode política. Se recomienda que la clase administradora por defecto contengatanto un grupo de copia de archivo como un grupo de copia de backup.

ASsign DEFMGmtclass domainname setname classname


9.4.2 Validar y Activar un Conjunto de Políticas

El comando validate examina las definiciones de las clases administradorasy de los grupos de copia en un conjunto especificado de políticas y reportes encondiciones que necesitan ser consideradas si el conjunto de políticas debe seractivado.

Una vez que se ha hecho un cambio a un conjunto de políticas o agregadouna clase administradora, grupo de copia, etcétera, y el conjunto de políticases validado, entonces el conjunto de políticas debe ser activado para hacerloun conjunto de políticas ACTIVE.

Usar el comando VALIDATE POLICYSET para verificar que un conjunto depolíticas está completa y válida antes de su activación.

VALidate Policyset domainname setname

Cuando un conjunto de políticas es activado, su contenido es copiado a unconjunto de políticas que tiene el nombre reservado ACTIVE.

El comando VALIDATE POLICY SET fallará si cualquiera de las siguientescondiciones existen:

• Una clase administradora por defecto no esta definida para el conjuntode políticas.

• Un grupo de copia dentro del conjunto de políticas especifíca un pool dealmacenamiento de copia como un destino.

• Una clase administradora especifíca un pool de copia como destino paraarchivos space-managed.

Cuando un conjunto de políticas es activado, los contenidos del conjuntode políticas son copiados a un conjunto de políticas que tiene el nombre reser-vado ACTIVE. Una vez activado, no hay ninguna relación verdadera entre elconjunto de políticas que ha sido activado (copiado a ACTIVE) y el contenidodel conjunto de políticas ACTIVE. El conjunto original de políticas todavíapuede ser modificado, pero las definiciones copiadas en el conjunto de políticasACTIVE sólo pueden ser modificadas activando otro conjunto de políticas.

9.5. TRABAJAR CON CLASES ADMINISTRADORAS 177

9.5 Trabajar con Clases Administradoras

Definir Clases Administradoras Para Backup Policy-Driven

Una clase administradora asocia backup y grupos de archivos con archivosy especifica si y cómo los archivos del nodo cliente son migrados al pool dealmacenamiento. Una clase administradora puede contener un backup o ungrupo de copia de archivos, un backup y un grupo de copia de archivos, oningún grupo de copias. Los usuarios pueden asociar sus archivos a una claseadministradora a través de la lista incluir - excluir.

9.5.1 Cómo los Archivos son Destinados a la Clase Adminis-tradora

• Un cliente Storage Manager respalda, archiva, o migra un archivo. Elarchivo es destinado a la clase administradora por defecto o a una claseadministradora especificada en la lista incluir - excluir del cliente.

• Si, dependiendo de la clase administradora, el archivo es elegido parabackup, archivar, o administrar el espacio, el cliente envía el archivo yla información del archivo al servidor.

• El servidor comprueba la clase administradora (space management) o elgrupo de copia (backup y archivo) para determinar donde se elmacenaráinicialmente el archivo en el almacenamiento del servidor.

Si no hay bastante espacio en el pool de almacenamiento inicial, se comien-za a migrar. El servidor almacena la información sobre el archivo en la basede datos.

9.5.2 Binding and Rebinding the Management Class

El binding es el proceso de asociar un nombre de archivo con un nombrede clase administradora. Los archivos son destinados a un nombre de claseadministradora cuando:

• Un usuario asocia un archivo a un nombre de clase administradora es-pecífica usando la opción INCLUDE en una lista incluir - excluir.


• Un usuario asocia un archivo a un nombre de clase administradora usan-do la opción ARCHMC cuando archiva un archivo.

• Un usuario asocia un directorio al nombre de clase administradora usan-do la opción DIRMC cuando resguarda un archivo.

• El nodo de cliente asocia un archivo a la clase administradora por defectoen el conjunto activo de políticas, cuando un usuario no asocia a unnombre de clase administradora específica.

Rebinding es el proceso de asociar un archivo con un nuevo nombre declase administradora.

9.5.3 Clase Administradora Rebinding Para Versiones de Bac-kup

Las versiones de backup están reencuadradas a un nombre de clase adminis-tradora diferente en los siguientes casos:

• Los usuarios cambian la clase administradora asignada a un archivo es-pecificando a una clase administradora diferente en una lista incluir -excluir y luego realizar un backup incremental o selectivo.

• Un administrador activa una política que no contiene la clase adminis-tradora.

• Un administrador asigna un nodo cliente a un dominio diferente de po-líticas y el conjunto activo de políticas en aquel dominio de políticas queno tiene una clase administradora con el mismo nombre.

Si la clase administradora a la cual los archivos son asociados es eliminada,Tivoli Storage Manager usa los atributos de la clase administradora por defectopara manejar las versiones de backup.

9.5.4 Especificación de la Clase Administradora

La clase administradora especificada en el dominio de políticas define el criteriode backup y archivo para los nodos clientes en el dominio de la política.

9.6. TRABAJAR CON GRUPOS DE COPIA 179

Los usuarios clientes tienen la opción de crear una lista incluir - excluir paraidentificar los archivos que son elegidos para servicios de backup y especificarcomo Tivoli Storage Manager manejará archivos de backup o archivados.

Las opciones INCLUDE y EXCLUDE son especificadas en el archivo de opcióndel cliente.

Se debe asignar una clase administradora por defecto a un conjunto depolíticas antes de activar el conjunto de políticas. Para asegurar a los clientessiempre puede respaldar y archivar los archivos, escogiendo una clase admi-nistradora por defecto que contiene tanto grupo de copia de archivo como ungrupo de copia de backup.

• Domain_name - Especifica el dominio de política al cual la clase ad-ministradora pertenece.

• Policy_set_name - Especifica el conjunto de políticas para el cual sequiere asignar una clase administradora por defecto. Se puede asignaruna clase administradora por defecto al conjunto de políticas ACTIVE.

• Class_name - Especifica la clase administradora que debe ser la claseadministradora por defecto para el conjunto de políticas.

9.6 Trabajar con Grupos de Copia

9.6.1 Grupos de Copias

Un grupo de copia contiene los atributos de administración del almacenamien-to específico que describen cómo el servidor debe manejar archivos de backupo archivados.

Cada clase administradora puede contener hasta dos grupos de copia: unapara archivos de backup y una para archivos de archivados.

9.6.2 Utilización de la Línea de Comandos para Definir unBackup del Grupo de Copia

Usar el comando DEFine COpygroup para definir un nuevo backup o grupo decopia de archivo dentro de un dominio especificado de política, conjunto de


políticas, y clases admistradoras.

El comando DEFINE COPYGROUP tiene los siguientes parámetros:

• Domainname - Especifica el nombre del dominio de política para elcual se define el grupo de copia. Este parámetro es requerido.

• Setname - Especifica el nombre del conjunto de políticas para el cualse define el grupo de copia. Este parámetro es requerido.

• Classname - Especifica el nombre de la clase administradora para lacual se define el grupo de copia. Este parámetro es requerido.

• STANDARD - Especifica el nombre del grupo de copia como STANDARD.El nombre del grupo de copia debe ser STANDARD. Este parámetro esopcional. El valor por defecto es STANDARD.

• Type=Backup - Especifica que se quiere definir un grupo de copia debackup. El parámetro por defecto es BACKUP. Este parámetro es opcional.

• DESTination=poolname - Especifica el nombre del pool de almace-namiento primario donde los datos de backup deben ser almacenados.

• FREQuency=freqvalue - Especifica el intervalo mínimo, en días, en-tre backup sucesivos.

• VERExists=verevalue - Especifica el número máximo de versiones debackup a retener para archivos corrientes.

• VERDeleted=verdvalue - Especifica el número máximo de versionesde backup a retener para los archivos que son eliminados del sistema dearchivo del cliente.

• RETExtra=retevalue - Especifica cuántos días Tivoli Storage Mana-ger conserva una versión de backup después de que aquella versión sehacen inactivas.

• RETOnly=retovalue - Especifica el tiempo de retención, en días, parala última versión de backup de un archivo que ha sido eliminado delsistema de archivo del cliente.

• MODE=mode - Especifica si un archivo debería ser resguardado basa-do en cambios hechos al archivo desde la última vez que fue resguardado.

9.7. AUTORIDAD ADMINISTRATIVA 181

Este parámetro es opcional. El valor MODE sólo es usado para backupincrementales. Este valor es ignorado durante los backup selectivos. Elvalor por defecto es MODIFIED.

• SERialization=serialvalue - Especifica cómo los archivos o directoriosson manejados si son modificados durante el proceso de backup y loque el Storage Manager debería hacer si ocurre una modificación. Esteparámetro es opcional. El valor por defecto es SHRSTATIC.

9.6.3 Administración del Storage Management Archive File

El Retain Version que se indica en el grupo de copia de archivo especifica elnúmero de días que una copia archivada permanece en el almacenamiento dedatos. Cuando el número especificado de días transcurre para la copia archiva-da del archivo, Tivoli Storage Manager elimina el archivo del almacenamientode datos.

A diferencia de la función de backup, el archivo no permite múltiples ver-siones de archivos de datos y directorios.

9.7 Autoridad Administrativa

9.7.1 Clases de Privilegios

La fig. 9.3 de la pág. 182 muestra como se pueden dividir las tareas adminis-trativas en cinco clases de privilegios.

9.7.2 Privilegio System

Un administrador con el privilegio System tiene la autoridad para realizartareas administrativas de Storage Manager, fig. 9.4 de la pág. 183, talescomo:

• Registrar o eliminar administradores.

• Otorgar o suspender autoridad administrativa.


Figura 9.3: Clases de Privilegios


• Bloquear o desbloquear administradores desde el servidor.

• Renombrar administradores o actualizar información del administrador.

• Definir o eliminar declaraciones de políticas.

• Importa o exportar datos desde el servidor.

• Cancelar procesos administrativos de segundo plano.

• Configurar parámetros operacionales para el servidor.

• Definir o eliminar pools de almacenamientos.

Figura 9.4: Privilegio System

Un administrador con privilegios system puede revocar o conceder nuevosprivilegios al ID SERVER_CONSOLE del usuario. Sin embargo, no se puede:

• Registran o actualizar al SERVER_CONSOLE user ID.


• Cerrar o abrir al SERVER_CONSOLE user ID.

• Renombran al SERVER_CONSOLE user ID.

• Remover al SERVER_CONSOLE user ID.

• Ruta de comandos desde el SERVER_CONSOLE user ID.

9.7.3 Privilegio Storage

Las tareas que puede realizar un administrador con privilegio de storage semuestan en la fig. 9.5 de la pág. 184.

Figura 9.5: Privilegio Storage

Privilegio Storage sin Restricción

Un administrador con el privilegio storage sin restricción tiene la autoridadpara manejar la base de datos, el log de recuperación, y todos los pool de


almacenamiento. Pueden publicar comandos que afectan todos los pools dealmacenamiento existentes así como cualesquier pools de almacenamiento queserá definido en el futuro. Un administrador storage sin restricción no puededefinir o eliminar pools de almacenamientos. Un administrador con privilegiossin restricción puede publicar los siguientes comandos:

AUDit Volume

DEFine/DELete Volume

MOVE DATA

UPDate STGpool

Privilegio Storage Restringido

Los administradores con el privilegio storage restringido pueden emitirun subconjunto de los comandos del privilegio storage sólo para los poolsde almacenamientos para los cuales están autorizados. No tienen autoridadpara manejar log de recuperación o la base de datos. Un administrador conprivilegios restringidos puede emitir los siguientes comandos:

DEFine DBVolume/DEVclass/LOGVolume DBCOPY/LOGCopy

DELete DBVolume/DEVclass/LOGVolume

EXtend/REDuce DB/LOG

UPDate DEVclass

Hay dos diferencias entre lo que un administrador con privilegio restringidoy sin restricción puede hacer:

El administrador sin restricción puede emitir los comandos que afectantodos los dominios o pools, mientras que el administrador restringido sólopuede emitir los comandos que afectan el dominio o pools a los cuáles ellosestán autorizados.

El administrador sin restricción puede emitir toda la politica y coman-dos de almacenamiento, mientras que el administrador restringido sólo puedeemitir un subconjunto de aquellos comandos.


9.7.4 Privilegio Policy

Un administrador con privilegio policy sin restricción, como se muestra enla fig. 9.6 de la pág. 186, tiene la autoridad para manejar los servicios debackup y archivos de los nodos clientes que son asignados a cualquier dominiode política.

Figura 9.6: Privilegio Policy

Cuando nuevos dominios de política son definidos en el servidor, un ad-ministrador con el privilegio policy sin restricción es automáticamente autori-zado para manejar los nuevos dominios de política. Un administrador policysin restricción no puede definir, eliminar, o copiar dominios de política. Unadministrador con el privilegio policy restringido puede emitir un subconjuntode los comandos de política para los dominios de política a los cuales estanautorizados.


9.7.5 Privilegio de Operator

Los administradores con el privilegio de operator controlan la operación inme-diata del servidor TSM y la disponibilidad de los medios de almacenamiento,fig. 9.7 de la pág. 187.

Figura 9.7: Privilegio de Operator

Un operador puede realizar las siguientes tareas:

• Inutilizar al servidor para impedir a clientes tener acceso el servidor.

• Permitir el acceso al servidor a los clientes.

• Cancelar sesiones.

• Cambiar volúmenes de disco sobre o fuera de línea para el mantenimien-to.

• Realizar el reset del estado de error para volúmenes de cinta.


• Manejar montajes de cinta.

• Parar al servidor cuando sea necesario.

9.7.6 Privilegio de Analyst

Los administradores con el privilegio de analyst pueden usar comandos pararesetear los contadores de estadísticas de seguimiento del servidor. Tambiénpueden llevar a cabo operaciones TSM cuando sea necesario, fig. 9.8 de lapág. 188.

Figura 9.8: Privilegio de Analyst

9.7.7 Administrador de Nodo

Los administradores de nodo pueden usar el comando Query DB Format=Detail

para mostrar los valores estadísticos bufferpool y la estadística de máxima uti-lización de la base de datos, fig. 9.9 de la pág. 189.


Figura 9.9: Administrador de Nodo


Alguien con autoridad de administrador puede usar el comando Query LOG

Format=Detail para mostrar la máxima utilización del log de recuperacióncorriente.

Para cambiar la autoridad de un administrador, usar el comando GRant

AUTHority. El nivel system es el nivel de autoridad más alto.

9.8 Tipos de Interfaces Administrativas

9.8.1 Interface Administrativa Web

La interface administrativa Web es la primera interface GUI para administrarel TSM.

La interfaz administrativa Web permite al administrador manejar todaslas funciones del Tivoli Storage Manager a traves de una combinación de GUIy un intérprete de línea de comando. La interfaz administrativa Web tiene lassiguientes vistas:

La vista operacional consiste en funciones administrativas.

La vista red consiste en grupos de servidores, servidores, clientes, y el co-mando que encamina la función.

La vista configuración consiste en perfiles de configuración y suscripciones deperfil.

La vista objeto consiste en todos los grupos y clases en la jerarquía básica.

Marco de Detalle - Muestra información detallada sobre el item que seselecciona en el marco del árbol. Todas las operaciones que están disponiblespara manipular el item seleccionado son proporcionadas en forma de un menúdesplegable en la esquina superior derecha del marco de detalle.

Línea de Comando - una línea de comando administrativa puede sermostrada seleccionándolo desde el menú desplegable en la interfaz administra-tiva Web, como se muestra en el gráfico. Esto devuelve la salida con formatode página HTML. El uso de la línea de comando es el único modo de obtenerlos resultados en una sentencia SELECT del lenguaje de pregunta estructurado(SQL) con las utilidades TSM.

9.8. TIPOS DE INTERFACES ADMINISTRATIVAS 191

Inspector de Eventos (Local) - el Inspector de Evento (Local) está dis-ponible en el Tivoli Storage Manager Management Console. Expandir el árbolsobre el lado izquierdo de la consola para mostrar las opciones de inspecciónque incluyen Aplicación, Seguridad, Sistema, TSM Servidor, TSM Cliente, yvistas de eventos del TSM Device Driver. Se pueden personalizar los datosmostrados para cada vista pulsando en View en la barra de herraminetas enla parte de arriba de la ventana y seleccionando las opciones que se prefieran.

La seguridad para la interfaz administrativa Web está basada en loggingmejorados de sesiones basadas en Web, restricciones de contraseña, capacida-des de cierre de administrador, y comunicaciones SSL.

Para implementar una línea de comando dentro de la interfaz administra-tiva Web, simplemente seleccionar Show command line de la lista desplegadade Options, y un Java applet llamado comando es ejecutado.

9.8.2 Uso de la Linea de Comando en la Interface Adminis-trativa Web

Para ejecutar un comando administrativo, escribir el comando en la caja deServer Command (en el fondo de la ventana de administración Web) y hacerclic en el botón Submit.

Formato Estándar del Resultado de la Pregunta

Este ejemplo muestra los resultados del comando Query ADmin cuando seusa desde la línea de comando de la intrface administrativa Web. El formatode salida es llamado STANDARD, fig. 9.10 de la pág. 192.

Formato Detallado del Resultado de la Pregunta

Este ejemplo muestra los resultados del comando Query ADmin Format=Detail

cuando es usado desde la línea de comando de la interfaz administrativa Web.El formato de salida es llamado DETAIL. Este comando de pregunta se puedereducir a: Query ADmin F=D, fig. 9.11 de la pág. 193.


Figura 9.10: Formato Estándar del Resultado de la Pregunta


Figura 9.11: Formato Detallado del Resultado de la Pregunta


9.8.3 Interfaz Administrativa de Línea de Comando del Clien-te

Comenzar la interfaz administrativa de línea de comando del cliente en elprompt del sistema. La ruta puede variar, pero la ruta por defecto es ProgramFiles >> Tivoli >> TSM >> baclient.

Para comenzar la línea de comando, escribir: dsmadmc

Para finalizar sesión del cliente administrativo, escribir: quit

La interfaz administrativa del cliente deja a los administradores controlary supervisar al servidor a través de comandos administrativos.

9.8.4 Linea de Comando del Comando Recall

La línea de comando recall está disponible tanto para el cliente administrativocomo para el cliente de archivo y backup. Esto permite rellamar y corregircomandos ingresados anteriomente.

El comando recall soportado está disponible en clientes administrativosy en clientes de archivo y backup en todas las plataformas cliente.

En clientes de UNIX, el soporte para el comando recall es activado agre-gando EDITOR YES al archivo de opción cliente (DSM.OPT). En otras plata-formas cliente, ningunas opciones de configuración son requeridas para activarel comando recall.

El teclado es usado para navegar el buffer de historia del comando y corregirlos comandos ingresados antes. Las teclas del teclado son estandarizadas através de todas las plataformas de clientes de línea de comando. Las teclasdel cursor (las flechas arriba y abajo) son usadas para navegar en el buffer dehistoria del comando. Por ejemplo, un usuario puede seleccionar el comandoanterior o siguiente.

La línea de comando de clientes almacenan hasta veinte comandos ingresa-dos en una sesión en el buffer de comando recall. El comando recall operausando el principio “primero en llegar, primero en salir” (FIFO). Es decir elcomando más viejo es quitado cuando el buffer esta lleno.


9.8.5 Configuración de la Interfaz Administrativa Web

Las comunicaciones HTTP son controladas por lo siguiente:

COMMMETHOD HTTP

HTTP PORT 1580, default

En la instalación, el valor por defecto de interrupción para la interfazadministrativa Web es de diez minutos.

Cuando el período de interrupción expira, el usuario de la interfaz Web seautentica de nuevo ingresando y especificando una contraseña. El siguienteejemplo muestra como configurar el valor de interrupción a veinte minutos:

set webauthtimeout 20

Para crear las definiciones necesarias para el servidor Web, se debe eje-cutar un trabajo de configuración de definición de interfaz. Esto se realizaejecutando el archivo DSMSERV.IDL usando la opción RUNFILE en el DSM-SERV ejecutable. Esto crea las definiciones HTML para todos los objetos delservidor en la base de datos y permite la interfaz administrativa Web.

Dos opciones en el archivo DSMSERV.OPT son usadas para configurar lainterfaz administrativa Web.

El valor HTTP usado en la conjunción con otros valores de la opciónCOMMMETHOD informa al servidor Storage Manager que los administrado-res usarán este método para comunicarse con el servidor.

HTTPPORT especifica el puerto de TCP/IP que la interfaz del servidorWeb debería supervisar para conexiones entrantes. Este valor tiene un va-lor por defecto de 1580, pero puede ser configurado con otros valores de serrequeridos.

SSL proporciona conversaciones encriptadas seguras, entre navegadoresWeb y servidores Web. Con SSL, todas las transferencias de datos TCP/IPenviados y recibidos son pasados a un API SSL. Así todos los datos son en-criptados antes de que sean enviados a la red, y son descifrados cuando sonrecibidos desde la red.

El Netscape Navigator y Internet Explorer soportan SSL y pueden ser usa-dos para administrar a servidores Storage Manager que corren sobre Sistemas


Windows o AIX. El servidor z/OS actualmente no soporta SSL.

Capítulo 10

Personalización de la Base deDatos y del Log deRecuperación del StorageManager

10.1 Introducción

La base de datos del Storage Manager es usada por el servidor para manejarla información sobre archivos de clientes. El log de recuperación del StorageManager se usa para asegurar la consistencia y la disponibilidad de la base dedatos.

10.2 Propósito de la Base de Datos y del Log deRecuperación

10.2.1 Base de Datos y Log de Recuperación

La base de datos del Storage Manager contiene la información que es necesariapara operaciones del servidor e información sobre los datos del cliente quehan sido resguardados, archivados, y administrados en cuanto a su espacio de

197

198 CAPÍTULO 10. PERSONALIZACIÓN DE LA BD Y DEL LOG

almacenamiento. La base de datos no almacena datos del cliente. En cambio,la base de datos indica las ubicaciones de los archivos del cliente en el pool dealmacenamiento, (fig. 10.1 de la pág. 198).

Figura 10.1: Base de Datos y Log de Recuperación

La base de datos incluye información sobre:

• Nodos clientes y administradores

• Políticas y schedules

• Configuraciones del Servidor

• Ubicaciones de archivos del cliente en el servidor de almacenamiento

• Operaciones del servidor (por ejemplo, logs de actividades y registros deeventos)

El log de recuperación contiene información sobre las actualizaciones de labase de datos que aún no han sido realizadas.

10.2. PROPÓSITO DE LA B.D Y DEL LOG 199

Las actualizaciones pueden incluir actividades como la definición de unaclase de administración, backup de un archivo del cliente, y registros de unnodo cliente. Los cambios a la base de datos son registrados en el log derecuperación para mantener una imagen consistente de base de datos.

10.2.2 Transacciones

Para soportar múltiples transacciones desde sesiones simultáneas del cliente,el servidor mantiene registros del log de transacción en el pool de buffer dellog de recuperación hasta que ellos puedan ser escritos al log de recuperación.Estos registros permanecen en el pool del buffer hasta que el buffer activo sellene o el Tivoli Storage Manager fuerza la grabación de los registros al log derecuperación, (fig. 10.2 de la pág. 199).

Figura 10.2: Transacciones

Los resultados de los cambios de las transacciones son mantenidos en elpool del buffer temporalmente y no son grabados en la base de datos inmedia-


tamente. Por lo tanto, la base de datos y el log de recuperación no siempreson consistentes.

Cuando todos los registros para una transacción son escritos al log de recu-peración, el Tivoli Storage Manager actualiza la base de datos. La transacciónentonces es realizada en la base de datos. En algún momento, luego de queuna transacción es realizada, el servidor elimina el registro de transacción dellog de recuperación.

Cuando una transacción ocurre, el servidor realiza las siguientes acciones:

1. Lee una página de base de datos en el buffer de base de datos y loactualiza. Una página es un bloque de 4096 bytes que son transferidoscomo una unidad entre el almacenamiento de disco y la memoria.

2. Escribe un registro del Log de transacción al Log de recuperación paradescribir la acción que ocurre y asocia esto con la página de la base dedatos en caso de la página de base de datos necesite retroceder durantela recuperación.

3. Escribe la página de la base de datos a la base de datos, liberándolo delpool de buffer. Las página permanecen en el pool de buffer hasta que elespacio del pool se necesita para otra página.

10.2.3 Modos de Recuperación del Log de Transacción

El log de recuperación es usado por el servidor para mantener un registrode todos los cambios a la base de datos. Cuando un cambio ocurre, el logde recuperación es actualizado con alguna información de transacción antesde que la base de datos sea actualizada. Esto permite a transacciones nocomprometidas retroceder durante la recuperación, entonces la base de datospermanece consistente, (fig. 10.3 de la pág. 201).

El log de recuperación funciona en dos modos - modo normal y modoavanzado.

Modo Normal

Cuando el registro del log de transacción es escrito al log de recuperación,se registra un punto de recuperación, y los datos son grabados en la base dedatos. Si la base de datos tiene que ser recuperada, el servidor usará el punto

10.2. PROPÓSITO DE LA B.D Y DEL LOG 201

Figura 10.3: Modos de Recuperación del Log de Transacción


de recuperación en el log de recuperación para devolver la base de datos asu último punto de consistencia. Un punto de consistencia es un tiempo enque toda la información recuperable en la base de datos es igual a los datosmanejados por el servidor. Si un fracaso ocurre antes de que una transacciónsea grabada en la base de datos, el servidor hace retroceder cualquier cambiohecho a las páginas de la base de datos.

El log es tratado como un arreglo circular de bloques con la cabecera (losregistros del log más recientes) siempre seguida de la cola (los registros másviejos). El servidor nunca dejará alcanzar a la cabecera y superponer la cola;debe tomar alguna otra acción. Cuando las transacciones se realizan, dejanlibre el espacio del log y permiten avanzar a la cola. El log de recuperaciónguarda algunos registros de las transacciones que ya han sido realizadas, perosólo lo necesario para volver a hacer el procesamiento en la recuperación. Ellog de recuperación también puede ser usado para la recuperación avanzadade la base de datos durante la recuperación de desastres.

Modo Roll-forward

En el modo roll-forward todos los cambios hechos a la base de datos desdeel último backup son guardados en el log de recuperación.

10.3 Asignación de Espacio

10.3.1 Asignación de Espacio de la Base de Datos y del Logde Recuperación

¿Cuántos Volúmenes de Base de Datos son Necesarios?

En general, el acceso a la base de datos es predominantemente orientadoa lectura. La colocación de los volúmenes de base de datos sobre múltiplesvolúmenes físicos puede mejorar el rendimiento porque esto permite al admi-nistrador de volúmenes lógicos extender la carga de entrada - salida sobre másvolúmenes. Esto es también verdadero cuando se usa mirroring (espejado)porque el administrador del volumen lógico programa operaciones de lecturaal volumen menos ocupado en el conjunto mirror. Sin embargo, mantiene elnúmero razonable de volúmenes (menos de 12), reduce el espacio usado parael administrador superior del volumen lógico. El límite máximo del tamañode base de datos es de 530 GB.

10.3. ASIGNACIÓN DE ESPACIO 203

¿Cuántos Volúmenes de Log de Recuperación son Necesarios?

En general, el acceso al log de recuperación es predominantemente orien-tado a escritura donde muchos escriben y pocos leen, la mayoría de las vecesagrupados. Por lo tanto, se apropian menos volúmenes de log de recuperación.El mirroring tiene poco efecto sobre el rendimiento del log de recuperación.El límite máximo del tamaño del archivo del log es de 13 GB.

10.3.2 Espacio de la Base de Datos y del Log de Recuperación

Los volúmenes usados para contener la base de datos y el log de recuperacióndeben ser volúmenes de disco, (fig. 10.4 de la pág. 203).

Figura 10.4: Consideración del Espacio de la Base de Datos y del Log deRecuperación

Tivoli Storage Manager trata todos los volúmenes asociados con la base dedatos o con el log de recuperación como un solo volumen lógico. El admins-trador del volumen lógico mapean los datos entre el almacenamiento lógico y


el físico, permitiendo a los datos de la base de datos y del log de recupera-ción pasar al discos físicos. No requieren ninguna reorganización del log derecuperación o la base de datos.

La cantidad de espacio disponible para la base de datos o el log de recupe-ración iguala el espacio combinado de todos los volúmenes definidos al log derecuperación o la base de datos. Cuando los datos son agregados, el StorageManager rastrea el porcentaje de utilización, que es la cantidad de espacio usa-do en un punto específico del tiempo. Tener presente que la cantidad máximade espacio usado por el log de recuperación puede variar considerablemente alo largo del día, es proporcional a la carga de transacciones en el sistema. Lacantidad máxima de espacio usado por la base de datos es más consistente conel porcentaje de utilización, porque la cantidad de espacio de base de datosconsumido crece en proporción al número de objetos insertados en la base dedatos.

10.4 Dimensionamiento de la Base de Datos y delLog de Recuperación

10.4.1 Estimación de Requerimientos de Espacio para la Basede Datos

Estimación de Requerimientos de Espacio

El tamaño de la base de datos del Storage Manager depende del númerode archivos de cliente para ser almacenados y como el Tivoli Storage Managerlos maneja. Si se puede estimar el número máximo de archivos que podríanestar en el almacenamiento del servidor en cualquier momento, se puede usarla siguiente información para realizar una estimación útil del tamaño de basede datos:

• Cada versión de un archivo que el Tivoli Storage Manager almacenarequiere de aproximadamente 400 a 600 bytes del espacio de la base dedatos.

• Cada copia de un archivo al pool de almacenamiento de copia o cachedrequiere aproximadamente 100 a 200 bytes del espacio de la base dedatos. Caching por defecto esta apagado. Sólo es usado para moversede un pool de almacenamiento al próximo.

10.4. DIMENSIONAMIENTO DE LA BASE DE DATOS Y DEL LOG DE RECUPERACIÓN2

• La sobrecarga podría aumentar el espacio requerido hasta un 25 % adi-cional.

En el ejemplo siguiente, los cómputos son los máximos probables. Además,los números no están basados en el uso de agregación de archivo. En general,cuanto más pequeños son los archivos agregados, menos espacio de base dedatos es requerido.

Asumir los siguientes números para un sistema Tivoli Storage Manager:

• Hasta 500,000 archivos de cliente podrían ser resguardados. La políticade almacenamiento indica conservar hasta tres copias de archivos res-guardados:

500,000 archivos x 3 copias = 1,500,000 archivos.

• Archivos archivados, hasta 100.000 archivos; podrían ser archivados lascopias de archivos de cliente.

• Manejo del espacio de archivos hasta 200,000 archivos migrados de ter-minales de trabajo del cliente podrían estar en el almacenamiento delservidor.

El espacio requerido para todos los archivos resguardados, archivados, yespacio administrqdo a 600 bytes por archivo es:

( 1,500,000 + 100,000 + 200,000) x 600 = 1.0 GB

En este ejemplo, hay tres servidores de aplicación para los cuales la basede datos y el log de recuperación están siendo dimensionado.

3 x 1.0 GB = 3 GB.

10.4.2 Cached y Archivos del Pool de Almacenamiento de Co-pia

El caching es permitido en el pool de almacenamiento de disco. El pool dedisco tiene una capacidad de 5 GB y usa por defecto el umbral máximo de


migración (90 %) y el umbral bajo de migración (70 %). Así, si la migracióncomienza con el 90 % y para con el 70 %, el 20 % del pool de disco, o 1 GB,es ocupado por archivos cached.

• Caching del pool de disco:

Si el tamaño promedio del archivo es aproximadamente 10 KB, aproxima-damente 100,000 archivos están en el cache en un momento dado.

100,000 archivos x 200 bytes = 19 MB.

• Pool de almacenamiento de copia:

Todos los pool de almacenamiento primarios son resguardados al pool dealmacenamiento de copia.

( 1,500,000 + 100,000 + 200,000) x 200 bytes = 343 MB). Por lo tanto, losarchivos de pool de almacenamiento de copia y caches requieren aproximada-mente 0.4 GB de espacio de datos.

10.4.3 Sobrecarga

Comenzar con al menos 12 MB para el log de recuperación. Si se usará elbackup de la base de datos y funciones de recuperación en el modo avanzado,se debería comenzar con al menos 25 MB.

Hasta este punto aproximadamente son requeridos 1.4 GB para versionesde archivo y archivos del pool de almacenamiento de copia y caches. Hastaun espacio adicional del 50 % (o 0.7 GB) debería ser tenido en cuenta para lasobrecarga.

La base de datos, entonces, debería ser aproximadamente de 2.1 GB.

Si no es práctico estimar el número de archivos a ser cubiertos por la políti-ca de administración del almacenamiento, se puede estimar aproximadamenteel tamaño de base de datos como del 1 % al 5 % del espacio requerido dealmacenamiento del servidor. Por ejemplo, si se necesitan 100 GB del alma-cenamiento del servidor, la base de datos debería estar entre 1 GB Y 5 GB.

10.5. AGREGAR ESPACIO 207

Atención: Tener en cuenta que los resultados son estimaciones. El ta-maño real de la base de datos puede diferenciarse de la estimación debido afactores tales como el número de directorios y la longitud de la ruta de accesoy nombres del archivo. Periódicamente se debería supervisar la base de datosy el log recuperación y ajustar sus tamaños como sea necesario.

10.4.4 Estimación del Tamaño del Log de Recuperación

Tanto en el modo normal como en el modo roll-forward, el volumen de lastransacciones del Tivoli Storage Manager afectarán a cómo de grande deberíaser el log de recuperación. Cuánto más clientes son agregados y el volúmen detransacciones simultáneas se incrementa, se debería ampliar el tamaño del log.En el modo roll-forward también se debe considerar cuán frecuentemente serealizan los backup de la base de datos. En este modo, el log de recuperaciónmantiene todas las transacciones desde el último backup de la base de datos ytípicamente requiere considerablemente más espacio que en el modo normal.

En el modo roll-forward, se tiene que determinar cuánto espacio es usadoen el Log de recuperación entre backups de la base de datos. Por ejemplo, sise planifica backups incrementales diariamente, se debería comprobar su usodiario por el período del tiempo.

10.5 Agregar Espacio

10.5.1 Crear Volúmenes Adicionales

DEFINIR EL VOLÚMEN - Usar el comando DEFine DBVolume para definirun nuevo volúmen de la base de datos y usar el comando DEFine LOGVolume

para definir un nuevo volúmen del log de recuperación.

Otro método para asignar un nuevo volúmen a la base de datos del StorageManager es usando el comando DEFine DBVolume con la opción FORMATSIZE

desde la consola del Storage Manager o desde un cliente administrativo.

EXTENDER EL VOLÚMEN - Usar el comando EXTend DB para incre-mentar la cantidad de espacio que puede ser usado por la base de datos dentrode todos los volúmenes de la base de datos asignados previamente al TivoliStorage Manager. Usar el comando EXTend LOG para incrementar la cantidad


de espacio que puede ser usado por el log de recuperación dentro de todos losvolúmenes del log de recuperación asignados previamente al Storage Manager.

10.6 Reducir el Espacio de la Base de Datos y delLog de Recuperación

Hay algunos comandos adicionales que se pueden usar para reducir el espaciode la base de datos y del Log de recuperación. Sólo se debe ejecutar éstoscomandos si se quiere rediseñar las disposiciones del volúmen, o agregar nuevosvolúmenes al Tivoli Storage Manager.

• Usar el comando REDUCE DB para disminuir la cantidad de espacio quepuede ser usado por la base de datos. Para reducir la capacidad de labase de datos, se debe reducir la base de datos en incrementos de 4 MB.Si no se especifica la reducción en incrementos de a 4 MB, Tivoli StorageManager redondea el número a la siguiente partición de 4 MB.

• Usar el comando REDUCE LOG para disminuir la cantidad de espacio quepuede ser usado por el log de recuperación. Para reducir la capacidaddel log de recuperación, se debe reducir el Log de recuperación en in-crementos de 4 MB. Si no se especifica la reducción en incrementos de 4MB, Tivoli Storage Manager redondea el número a la siguiente particiónde 4 MB.

10.7 Mirroring (Espejado)

10.7.1 Mirroring de la Base de Datos y del Log de Recupera-ción

La disponibilidad de la base de datos y del log de recuperación es asegurada,proporcionando protección ante errores lógicos y ante fallas de los dispositivosy medios, (fig. 10.5 de la pág. 209).

Mirroring ofrece flexibilidad adicional al usar copia dual de hardware. Mi-rroring tiene las siguientes ventajas:

1. Se pueden soportar tres copias.

10.7. MIRRORING (ESPEJADO) 209

Figura 10.5: Mirroring de la Base de Datos y del Log de Recuperación


2. Se tiene el control preciso de lo que se espeja.

3. Las copias pueden estar sobre los volúmenes físicos que residen en dife-rentes unidades de control de almacenamiento.

4. El rendimiento en lecturas se mejora con mirroring debido a que el ser-vidor leerá desde el dispositivo con el mejor tiempo de respuesta.

Nota: no es aconsejable usar volúmenes mirror independientes para labase de datos o el log de recuperación, aunque sea permitido.

10.7.2 Ejemplos de Mirroring

Usar el comando DSMFMT para formatear el espacio. Por ejemplo, para forma-tear un volumen de base de datos llamado db1.dsm con un tamaño de 12 MB,ir al prompt del sistema y ejecutar el siguiente comando:

dsmfmt -db c:\TSMdata\server1\db1copy.dsm 12

Nota: la posición por defecto del comando DSMFMT está en C:\ProgramFiles\tivoli\TSM\console directory.

Entonces, defina el volumen mirrored ejecutando el siguiente comando des-de el prompt de comandos administrativos del Storage Manager:

define dbcopy c:\TSMdata\server1\db1.dsm

c:\TSMdata\server1\db1copy.dsm

El proceso de agregar un mirror es muy similar a la agregación de espacio labase de datos y al Log de recuperación. Sólo recordar que si se usa la interfazGUI para crear la copia mirror, todavía se debe usar el comando DSMFMT

para formatear el espacio ántes de definir el mirror. El comando del StorageManager para definir un mirror para la base de datos es DEFine DBCopy. Paradefinir un mirror del log de recuperación usar DEFine LOGCopy.

Usar el comando DEFine DBCopy para crear un volúmen de copia de unvolúmen de base de datos existente. Las copias de volúmenes deben tener almenos la misma capacidad que el volumen original y deberían estar definidasen dispositivos físicos separados. Cualquier espacio adicional en la copia delvolumen no es usado.

10.8. PARÁMETROS BUFPOOLSIZE Y LOGPOOLSIZE 211

Usar el commando DEFine LOGCopy para crear un volúmen de copia deun volumen existente del log de recuperación. Después de que un volúmen decopia es definido, el volúmen de copia se sincroniza con el volúmen original.Después de que la sincronización se haya completado, los volúmenes de copiasson las imágenes espejo el uno del otro. Se puede solicitar información sobrelos volúmenes espejados de la base de datos o del Log de recuperación usandolos comandos DBVolume y Query LOGVolume.

10.8 Parámetros BUFPOOLSIZE y LOGPOOLSI-ZE

Se puede dejar que el Tivoli Storage Manager ajuste dinámicamente el tamañodel pool del buffer de almacenamiento de base de datos o se puede ajustarmanualmente.

Las opciones que permiten la configuración automática del temaño del poolde la base de datos del buffer y de la base de datos del Log son:

• BUFPOOLSIZE

El tamaño mínimo es de 256 KB.

El tamaño máximo es limitado por la memoria virtual disponible - por defectoes de 2048 kilobyte.

Lo recomendado es de 131072 para el servidor con 1GB de memoria real.

LOGPOOLSIZE.

SELFTUNEBUFPOOLSIZE.

El procesmiento de expiración del servidor reinicia el pool del buffer de labase de datos antes de que el siguiente procesamiento comience y examina siel cache del pool del buffer de la base de datos esta por encima del 98 %. Sila proporción del cache es inferior al 98 %, el pool del buffer de la base dedatos será incrementado; si es más alto, el tamaño del pool del buffer no secambiará. El aumento del pool del buffer de la base de datos no usará másdel 10 % del almacenamiento real disponible.


Usar el comando SETOPT BUFPOOLSIZE para cambiar el tamaño del pooldel buffer.

10.9 Espacios Triggers

10.9.1 DEFine SPACETrigger

Cuando el servidor realiza una operación interna de movimiento de datos,tal como la migración, recuperación, movimiento de datos, o restauración obackup del pool de almacenamiento, ajustará los valores del rendimiento au-tomaticamente ajustando los parámetros, configurándolos, para alcanzar elrendimiento óptimo. Para prevenir quedarse sin espacio del log durante estasoperaciones, usar el comando DEFine SPACETrigger para permitir la exten-sión del log de recuperación.

El Administrator de espacios definidos para triggers avisa al Storage Ma-nager server cuándo aumentar el tamaño de la base de datos o del log. Losespacios para triggers definen un porcentaje máximo de utilización. Cuandodicho porcentaje de utilización se alcanza, el primer paso es aumentar el ta-maño de la base de datos o del log, usando el espacio antes asignado, pero nousado. Para hacer esto se usa el comando extend.

Si no hay el espacio previamente asignado, o si hay espacio insuficientepara reducir el porcentaje de utilización debajo del valor trigger, la base dedatos o el log se amplian. El primer paso para expandir la base de datoses asignar un nuevo volumen. Se deben predefinir un prefijo de nombre devolumen y la cantidad de espacio a extenderse como un porcentaje de la basede datos existente o el log.

Un límite superior forzado puede ser definido para la base de datos o elLog para prevenir la extensión más allá de un cierto punto. Cuándo finalizael formateado del volúmen de asignación, la base de datos o el log ampliaráel tamaño de los volúmenes recién asignados. Los volúmenes espejados seránasignados también si la base de datos o el log son espejados.

El comando DEFine SPACETrigger define configuraciones para la base dedatos y el log de recuperación que determina cuándo y cómo el Tivoli StorageManager trata con escasos espacios en el log de recuperación y la base dedatos.

10.9. ESPACIOS TRIGGERS 213

El primer parámetro especifica si la base de datos o el log deben ser ma-nejados por el trigger de extensión automática del espacio.

Capítulo 11

Configuración del Cliente

11.1 Interfaces de los Clientes

11.1.1 Identificar los Tipos de Clientes

Se puede usar la interfaz gráfica de usuario (GUI), la interfaz de línea decomando, o la interfaz del cliente Web para realizar tareas, (fig. 11.1 de lapág. 216).

11.1.2 La Interface de Línea de Comando

El cliente puede ser invocado usando la interfaz de línea de comando escri-biendo dsmc en el prompt de comando del sistema en la ruta del directoriodonde el cliente fue instalado, (fig. 11.2 de la pág. 217).

Por ejemplo:

c:\Program Files\Tivoli\tsm\baclient dsmc

El cliente invoca una sesión con el servidor hasta que el comando se comple-te. El comando dsmc puede estar seguido de una palabra clave. Por ejemplo,el comando incremental dsmc mostrado a continuación:

dsmc i

Cuando la autenticación está disponible, se debe ingresar una contraseña

215

216 CAPÍTULO 11. CONFIGURACIÓN DEL CLIENTE

Figura 11.1: Tipos de Clientes

11.1. INTERFACES DE LOS CLIENTES 217

Figura 11.2: Interface de Línea de Comandos


en la línea de comando, o se le solicitará al usuario que ingrese una contraseña.La contraseña está encriptada y no se mostrará cuando es tipeada.

11.1.3 Utilización del Loop de la Interface de línea de Coman-do

El comando dsmc loop es otra opción de la interfaz de línea de comando paraingresar en una serie de comandos del Storage Manager. El loop invocará unasesión del servidor hasta que el comando quit haga que la sesión se cierre.

Mientras que en el loop se pueden ingresar tantos comandos como se quierasin preceder el comando con el prefijo de la interfaz de línea de comando dsmc.El ingreso dsmc sin un parámetro invocará el loop de la interfaz de línea decomando.

11.1.4 Interface Web del Cliente

Para usar al cliente Web, especificar la URL de la máquina cliente ejecutandoel cliente Web en el navegador, y el puerto cliente 1581. Por ejemplo:

http://x.x.x.x:1581

El cliente Web se ejecuta sobre los siguientes navegadores:

• Netscape Navigator 6.0 o anteriores con la opción de soporte Java ins-talado.

• Netscape Navigator 4.7 o anteriores con Java Plug-in 1.3.1.

• Microsoft Internet Explorer 5.0 o anteriores con Java Plug-in 1.3.1. Elmínimo nivel JRE requerido para navegadores de Microsoft Internet Ex-plorer que se ejecutan en plataformas Windows es JRE 1.3.1_01.

TCP/IP es el único protocolo de comunicación soportado para esta interfazcliente.

11.1. INTERFACES DE LOS CLIENTES 219

11.1.5 La Interfáz GUI

La interfaz GUI de backup y archivado puede ser accedida desde el menú StartWindows seleccionando:

Start >> Programs >> Tivoli Storage Manager >> Backup-Archive GUI.

El comando DSM comenzará la interfáz GUI desde la línea de comando.

Comandos del Utilities Menu

Las siguientes funciones están disponibles al cliente a traves del UtilitiesMenu de la interface GUI:

• Cambio de contraseña

• Lista de acceso a nodos

• Acceso a otro nodo

• Vista de la información de políticas

• Eliminar datos de archivo

• Eliminar filespaces

• Setup wizard

Cambio de Contraseña

Una contraseña es requerida cuándo la autorización esta conectada. Lafunción cambiar de contraseña permite cambiar la contraseña en cualquiermomento.

Lista de Acceso a Nodo

Esta opción es usada en conjunción con el comando de Acceso a Otro Nodo.En esta ventana, se podrá crear o modificar las reglas que permitirán a otronodo tener acceso a los espacios de archivo resguardados en un servisor TSM.Esta función fue puesta en el Native GUI y en el cliente Web. También, lainterfáz ha sido rediseñada para ayudar a mejorar la utilidad de ésta función.

Acceso a Otro Nodo


Un usuario puede dar acceso a otro usuario a sus archivos en el servidorTSM mediante la ventana de Lista de Acceso a Nodos en la GUI del clientedel TSM o mediante el comando set access en la línea de comando. Elsegundo usuario puede usar la ventana de Acceso a Otro Nodo en la GUI delcliente TSM, o la opción fromnode en la línea de comando para restaurar orecuperar los otros objetos del nodo desde el servidor a la máquina en la que seejecuta el cliente. La funcionalidad Acceso a Otro Nodo ahora será soportadoen el cliente Web TSM, permitiendo a un nodo restaurar objetos resguardadoso archivados por otro nodo a la máquina en la que se ejecuta el agente delcliente Web del TSM del primer nodo.

Ver Información de Política

La ventana de la Vista de la Información de Política muestra las clasesadministradoras disponibles. Esta información incluye la información de grupode copia para el backup y los grupos de copia de archivado.

Eliminar Datos Archivados

Se puede eliminar el paquete de archivo entero o archivos individuales queno es necesario almacenar en el servidor TSM.

Eliminar Filespace

Usar esta utilidad si no se necesita un espacio de archivo. Cuando seselecciona el comando Delete Filespace desde el menú, una petición de con-firmación de eliminación se muestra en el prompt. También se puede eliminarun espacio de archivo utilizando el comando Delete Filespace en la línea decomando.

Setup Wizard

El wizard de configuración del cliente es accesible desde aquí. El SetupWizard guiará a travéz de todos los pasos necesarios para configurar al clienteTSM y al cliente Web.

Pregunta DiskInfo

La Pregunta DiskInfo está disponible para el cliente a travéz del UtilitiesMenu de la interfáz Web.

La pregunta DiskInfo permite a los usuarios y administradores obtener elLUNs y el serial IDs de todos los discos accesibles por la máquina cliente sinnecesidad de conectarse realmente a las máquinas clientes. Durante la confi-

11.2. CONTROL DE ACCESO ADMINISTRATIVO 221

guración del TSM para el movimiento server-free de datos, el administradordebe obtener la información para los discos en los cuáles el usuario deberáser resguardado. Esto es necesario para asegurar que sólo un nodo clienteserá capaz de realizar una operación de backup o restauración server-free paracualquier disco dado en el SAN.

11.2 Control de Acceso Administrativo

11.2.1 Registración

Ántes de que un usuario pueda solicitar servicios al Storage Manager, el nododebe ser registrado con el servidor:

• Cada nodo debe ser registrado con el servidor y requiere un archivo deopción con un indicador del servidor.

• Cuando un nodo es registrado, el Storage Manager automáticamentecrea un ID de usuario administrativo con autoridad de cliente propietariosobre el nodo.

• Se puede usar este ID de usuario administrativo para acceder al backup-archivado del cliente Web desde ubicaciones remotas a travéz de un na-vegador Web.

• Si un ID de usuario administrativo ya existe con el mismo nombre, el IDde un usuario administrativo automáticamente no es definido.

11.2.2 Administración de Contraseñas

Los administradores tienen una variedad de comandos y opciones que puedenser usados para limitar y controlar el acceso al sistema, (fig. 11.3 de la pág.222).

Expiración del Conjunto de Contraseñas

Por defecto, el servidor configura la expiración de la contraseña a 90 días.El período de expiración comienza cuando un administrador o el nodo clienteson registrados por primera ves en el servidor. Si una contraseña de usuario


Figura 11.3: Administración de Contraseñas


no es cambiada dentro de este período, el servidor obliga al usuario a cambiarla contraseña la próxima vez que el usuario trata de acceder al servidor.

set passexp 120 node=joe

Por defecto, Tivoli Storage Manager no comprueba el número de veces queun usuario intenta conectarse con una contraseña inválida. Se puede configurarun límite para el número de intentos consecutivos de contraseñas inválidas paratodos los nodos clientes. Cuándo el límite excede, el servidor cierra el nodo.El siguiente ejemplo configura el límite para todo el sistema en tres intentosconsecutivos de contraseñas inválidas:

set invalidpwlimit 3

Configuración de la Longitud Miníma de la Contraseña

Por defecto, Tivoli Storage Manager no comprueba la longitud de unacontraseña. El administrador puede especificar una longitud mínima de lacontraseña que es requerida para las contraseñas del Tivoli Storage Mana-ger. El siguiente ejemplo muestra como configurar la longitud mínima de lacontraseña a ocho carácteres:

set minpwlength 8

11.2.3 Impedir a los Nodos Clientes el Acceso al Servidor

Se puede impedir a un nodo cliente acceder al sistema usando el comandoLOCK NODE, (fig. 11.4 de la pág. 224).

No se puede cancelar a un nodo cuando éste ya tiene una sesión.

Hay varios motivos por los qué un nodo podría ser cancelados:

• Un nodo se cancela cuando hay demasiados intentos de contraseñas in-válidas.

• Un administrador puede decidir cancelar un nodo para impedirle incluir-se en un evento próximo previsto.


Figura 11.4: Impedir a los Nodos Clientes el Acceso al Servidor


11.2.4 Opciones del Cliente

Las opciones del cliente pueden ser modificadas a través de la GUI escogiendoEdit >> Preferences. La utilización de la GUI, más que trabajar directa-mente con el archivo de opciones de configuración, reduce el potencial errorhumano. Algunas opciones, sin embargo, no están disponibles en la GUI. Sedeben editarlas manualmente utilizando el editor de textos a elección, (fig.11.5 de la pág. 225).

Figura 11.5: Opciones del Cliente

Configuración del Archivo de Opciones

Hay dos archivos de opción del cliente, y cualquiera se puede usar, depen-diendo del sistema operativo:

• DSM.OPT


• DSM.SYS

En el sistema operativo Windows 2000, las opciones del cliente están en elDSM.OPT. Este es un archivo que el cliente puede editar, contiene un conjuntopor defecto de procesamiento de las opciones que identifican al servidor, elmétodo de comunicación, las opciones de backup y archivado, y las opcionesde planificación.

11.2.5 El Editor Gráfico de Opciones

El cambio de los archivos de configuración del archivo de backup del clienteusando un editor de textos es potencialmente una tarea peligrosa.

Un editor gráfico de opciones (Edit >> Preferences) está disponiblepara la GUI del backup y archivado del cliente para hacer la personalizaciónde las opciones de configuración del cliente más fácil de usar y menos propensoa errores.

Sin embargo se debería saber que los editores gráficos de opciones agreganopciones al final del archivo de opción.

• El editor gráfico de opciones actualiza los archivos de configuración delcliente DSM.OPT y DSM.SYS (clientes de UNIX solamente) si cualquieropción es cambiada.

• Los archivos de configuración del cliente todavía pueden ser actualizadosusando un editor de textos en los clientes.

• El editor gráfico de opciones usa las variables DSM_DIR y DSM_CONFIGdel Storage

Manager para localizar el archivo de configuración del cliente.

El editor gráfico de opciones preguntará al servidor por las opciones queson almacenadas centralmente en la configuración de las opciones del clienteen el servidor. Es importante notar que el editor gráfico de opciones sóloactualizará o agregará opciones del cliente a los archivos de opciones en elcliente. Las configuraciones de opciones del cliente en el servidor TSM no sonactualizadas. Las opciones almacenadas centralmente son mostradas por eleditor gráfico de opciones.


11.2.6 Configuración del Acceso del Cliente al Servidor

El Tivoli Storage Manager usa varios parámetros de comunicación que debenser configurados. Estas opciones son NODename, TCPServeraddress, COMM-Method, y TCPPORT, (fig. 11.6 de la pág. 227).

Figura 11.6: Configuración del Acceso del Cliente al Servidor

• NODENAME - Usar la opción NODENAME para identificar la esta-ción de trabajo en el servidor. El nodename puede tener un nombre de1 a 64 carácteres que será usado para identificar al nodo para el cuál sequiere solicitar servicios al Storage Manager. Para sistemas Windows,por defecto es el nombre de la máquina si no se usa ésta opción.

La opción NODENAME esta en el archivo de opciones del sistema delcliente dsm.sys.


• TCPSERVERADDRESS - Usar la opción TCPSERVERADDRESSpara especificar la dirección TCP/IP para un servidor del Storage Mana-ger. Para usar el protocolo de comunicación TCP/IP, se debe incluir laopción TCPSERVERADDRESS en el archivo de opción del cliente. Lasotras opciones del TCP/IP tienen los valores por defecto que se puedenmodificar sólo si se quiere cambiar el valor por defecto.

Proporcionar de uno a sesenta y cuatro caracteres a la dirección TCP/IPpara un servidor del Storage Manager. El valor que se especifica para éste pa-rámetro puede ser un nombre de dominio TCP/IP de Internet o una direcciónde IP.

• COMMMETHOD - Usar la opción COMMMETHOD para especificarel método de comunicación que se usa para proporcionar la conectivi-dad para la comunicación del servidor y del cliente. Algunos métodosde comunicación que se pueden usar con la opción COMMMETHODincluyen:

SHAREDMEM - método de comunicación de Memoria Compartida. Estaopción de método de comunicación es posible cuando el Storage ManagerServer y el Storage Manager Client están en la misma máquina UNIX.

TCPIP - método de comunicación, Protocolo de Control de Transmisión /Protocolo de Internet (TCP/IP).

NAMEDPIPE - la opción Named Pipe especifica el nombre de un pipe lla-mado para usar la comunicación entre un Storage Manager Server y unStorage Manager Client en la misma estación de trabajo Windows.

TCPPORT - Usar la opción TCPPORT para especificar la dirección delpuerto TCP/IP de un servidor. La dirección del puerto TCP/IP esusada para la comunicación con un servidor del Storage Manager. Elrango de valores es de 1000 a 32767. Por defecto es de 1500.

TCPPORT port_address

PASSWORDACCESS GENERATE

El soporte de generación de passwordaccess se activa para especificar unPASSWORDACCESS GENERATE en un archivo de opción del cliente.


La contraseña del cliente del Tivoli Storage Manager de archivado y backupse encripta y almacena en un archivo en el cliente. Si un cliente recibe uncódigo de retorno desde el servidor del Tivoli Storage Manager indicando quela contraseña ha expirado, el cliente genera una nueva contraseña aleatoria.

La opción PASSWORDDIR del cliente de archivado y backup es usadapara especificar la ubicación del archivo de contraseña encriptado. El clienteWin32 de archivado y backup es una excepción a esta regla de cómo el TivoliStorage Manager almacena la contraseña encriptada del cliente en el registro.

11.2.7 Identificar Preferencia de Opciones

Si se tiene una opción en el set central de opciones del cliente y en el ar-chivo de opciones del cliente (dsm.opt) el set central de opciones del clientesobreescribirá el archivo de opciones del cliente.

Anular Opciones de Configuración

Un administrador en el servidor puede anular un subconjunto de opcionesdel cliente, por ejemplo, programando el modo.

Las opciones pueden ser especificadas invocando la línea de comando o laGUI del cliente, que entonces anulan las opciones sin necesidad de hacer uncambio al archivo de opciones actual. La excepción es la sentencia DOMAINque es agregada al archivo de opción del cliente.

Cuando las opciones son cambiadas, el cliente debería ser reinicializado.

La Opción Domain

Si no se especifica controladores locales con la opción DOMAIN en el ar-chivo de opciones del cliente, por defecto son todos controladores locales.

Cuando se usa esta opción con el comando INCREMENTAL, agrega loscontroladores locales que se especifican a los que están definidos en el archivode opciones del cliente. Por ejemplo, si se ingresara:

DOMAIN C: D: E:

En el archive de opciones del cliente y se ingresara:

dsmc incremental -domain=‘‘g: h:’’ en la línea de comando, TivoliStorage Manager realiza un backup incremental para los controladores locales


c:, d:, e:, g:, y h:.

Esta descripción se aplica generalmente a todas las plataformas. Conside-rar el término “controladores locales” para indicar volúmenes o sistemas dearchivos.

Usar la opción DOMAIN para especificar los controladores que se quiereincluir en el dominio del cliente para el backup incremental. Cuando se usaesta opción en el archivo de opción del cliente, define el dominio del clientepor defecto.

Tivoli Storage Manager usa el dominio del cliente por defecto para deter-minar qué controladores locales procesar durante un backup incremental enestas situaciones:

• Se ejecuta un backup incremental usando el comando INCREMENTAL sinespecificar qué controladores locales tratar.

• El administrador del Tivoli Storage Manager define un schedule paraejecutar un backup incremental, pero no especifica qué controladoreslocales tratar.

11.3 Rendimiento y Opciones del Cliente

11.3.1 Opciones Disponibles del Cliente para Configurar y Pro-porcionar Rendimiento

• TXNBYTELIMIT - La opción TXNBYTELIMIT en el archivo deopción del cliente indica el número total de bytes que el cliente puedeenviar al servidor en una sóla transacción.

• TCPWINDOWSIZE - Usar la opción TCPWINDOWSIZE para es-pecificar, en kilobytes, el tamaño que se quiere usar para la ventanadeslizante del TCP/IP para el nodo cliente. El host emisor no puedeenviar más datos hasta que éste reciba un reconocimiento y reciba unaactualización TCP.

Cada paquete TCP contiene información de la ventana de recepción deTCP de la conexión. Una ventana más grande permite al remitente continuar

11.3. RENDIMIENTO Y OPCIONES DEL CLIENTE 231

enviando datos y puede mejorar el rendimiento de la comunicación, sobretodo sobre en redes rápidas con alta latencia. El valor recomendado es de 63kilobyte.

• TCPBUFFSIZE - La opción TCPBUFFSIZE especifica el tamaño delbuffer de comunicación interno del TCP/IP usado para transferir datosentre el nodo cliente y el servidor. Aunque esto use más memoria, unbuffer más grande puede mejorar el rendimiento de la comunicación.

• TCPNODELAY - La opción TCPNODELAY especifica si el servidorpermite a los paquetes de datos que son menores que el tamaño de la uni-dad de transmisión máxima (MTU) ser enviados inmediatamente sobrela red. La configuración recomendada es Yes.

La fig. 11.7 de la pág. 232 muestra las opciones disponibles del clientepara configurar y proporcionar rendimiento.

11.3.2 TXNGROUPMAX

TXNGROUPMAX es el número de los archivos que son transferidos comoun grupo entre un cliente y el servidor entre determinados puntos de unatransacción. Es posible afectar el rendimiento de las operaciones de backup,archivado, restauración, y de la recuperación del cliente usando un valor másgrande para la opción TXNGROUPMAX.

Se puede usar la opción TXNGROUPMAX para aumentar el rendimientocuando el Tivoli Storage Manager graba a cintas. Este rendimiento puede serconsiderable cuando un usuario transfiere múltiples archivos pequeños, (fig.11.8 de la pág. 233).

11.3.3 Configurar las Opciones de Logging

• ERRORLOGNAME - Usar la opción ERRORLOGNAME para es-pecificar la ruta y el nombre del archivo donde se quiere que el StorageManager almacene la información sobre los errores que ocurren duranteel procesamiento.

• ERRORLOGRETENTION - Usar la opción ERRORLOGRETEN-TION para especificar el número de días que se guardarán las entradas


Figura 11.7: Opciones Disponibles del Cliente Para Generar y ProporcionarRendimiento


Figura 11.8: TXNGROUPMAX


en el log de error, y si hay que guardar las entradas eliminadas. El logde error es eliminado cuando el primer error es escrito al log despuésque la sesión del Storage Manager comienza y después de que cada sche-dule se ejecuta. Si la única sesión del Storage Manager que se ejecutaes el scheduler, y se lo ejecuta las 24 horas del día, el log de error nopodrían ser eliminado según las expectativas. Se debe parar la sesióny comenzarla nuevamente para permitir al log ser eliminado cuando elsiguiente error es escrito. Se recomienda que se configure el log para sermantenido durante 7 días.

• QUIET - La opción QUIET impide que los mensajes se muestren enla pantalla durante el procesamiento del Storage Manager. Por ejem-plo, cuando se ejecuta el comando del backup incremental o selectivo,el Storage Manager muestra la información sobre cada archivo que fueresguardado. Usar la opción QUIET para reducir el número de entradasque se pueden observar. Cuando se usa la opción QUIET, cierta infor-mación de error todavía se muestran sobre la pantalla, y los mensajesson escritos al log de archivos. Si no se especifica la opción QUIET, elStorage Manager usa la opción por defecto, VERBOSE. Se recomiendaque se configure a la opción QUIET.

11.3.4 Opciones del Cliente y del Servidor del TSM

Usar las opciones descritas en la fig. 11.9 de la pág. 235, para controlar elprocesamiento del servidor y del cliente.

• COMMTIMEOUT - Este es el número de segundos que el servidorespera una respuesta desde un cliente antes de finalizar la sesión delcliente.

• IDLETIMEOUT - Este es el número de minutos que el servidor per-mite a una sesión cliente permanecer ocioso antes de finalizar la sesióndel cliente.

• MAXSESSIONS - Esto determina el número máximo de sesiones si-multáneas de clientes con el servidor.

• USELARGEBUFFERS - Esto determina si los buffers grandes sonusados para comunicaciones cliente/servidor.


Figura 11.9: Opciones del Cliente y del Servidor del TSM


11.3.5 Conjunto de Opciones Cliente

Para crear un conjunto de opciones cliente, fig. 11.10 de la pág. 237, y hacerque los clientes usen el conjunto de opciones, hacer lo siguiente:

1. Crear un conjunto de opción cliente con el comando DEFINE CLOPTSET.El comando DEFINE CLOPTSET define el nombre y la descripción del con-junto de opciones. El nombre puede tener una longitud de 64 carácteresy no debería incluir en su interior espacios en blanco. La descripción delconjunto de opciones puede tener una longitud de hasta 255 caracteres ydebería ser encerrada entre comillas si son usados espacios en blanco ensu interio. Para ejecutar este comando el administrador tiene que tenerel privilegio SYSTEM o el privilegio de POLICY sin restricción.

2. Agregar opciones de cliente al conjunto de opciones con el comandoDEFINE CLIENTOPT. El conjunto de opciones está vacío primero cuandoes definido. Una vez que el conjunto de opciones ha sido definido al TivoliStorage Manager, las opciones y sus valores deben ser definidos en elconjunto de opciones. Esto se hace con el comando DEFINE CLIENTOPT.El conjunto de opciones, el nombre de la opción y el valor de la opcióndeben ser suministrados. Opcionalmente, un número de secuencia y/oel valor forzado pueden ser suministrados también.

3. Especificar qué clientes deberían usar la opción de configuración con elcomando REGISTER NODE o UPDATE NODE. Una vez que una opción delcliente se configura y las opciones del cliente han sido definidas, los nodospueden ser asociados con aquella configuración. Esto se hace usando laopción CLOPTSET en el comando REGISTER NODE para nuevos nodos, oen el comando UPDATE NODE para nodos existentes.

11.3.6 Identificar el Valor del Conjunto de Opciones del Clien-te

Las opciones de configuración del cliente permiten al administrador especifi-car opciones adicionales que no pueden ser incluidas en el archivo (dsm.opt)de opción del cliente. Se puede especificar cuáles clientes usarán la opciónde configuración con el comando REGISTER NODE o UPDATE NODE. El cliente


Figura 11.10: Conjunto de Opciones Cliente


puede usar estas opciones definidas durante un proceso de backup, archivado,restaurarción, o recuperación.

Las opciones definidas en una opción de configuración del cliente son unsubconjunto de las opciones del cliente disponibles. Las opciones como elmétodo de comunicación todavía son almacenadas en la máquina cliente. Parapermitir al administrador controlar estas opciones centralmente, es posibleespecificar qué opciones individuales no pueden ser anuladas en la máquinacliente, (fig. 11.11 de la pág. 238).

Figura 11.11: Identificar el Valor del Conjunto de Opciones del Cliente

Definir Opciones Incluyen - Excluyen

Dos de las opciones que pueden ser definidas en una configuración de op-ciones del cliente son INCLUDE y EXCLUDE.

Cuando estos parámetros son especificados en el archivo de opción del clien-


te un parámetro adicional para la clase administradora a ser usada tambiénpuede se proporcionado.

11.3.7 Uso de la Opción FORCE

El número de secuencia asignado a una opción del cliente es usado cuando lamisma opción es definida más de una vez. Las opciones tales como INCLUDEpueden ser definidas a una opción de configuración del cliente muchas veces yla secuencia es crucial. La opción FORCE es usada para especificar opcionesque no pueden ser anuladas por el archivo de opción local del cliente. Paraparar una opción siendo anulada por el cliente, debería ser definida a la opciónde configuración con FORCE=YES. Por defecto es NO, (fig. 11.12 de la pág.239).

Figura 11.12: Uso de la Opción FORCE


11.3.8 Identificar Archivos a Ser Incluidos o Excluido Desdeel Backup

La lista incluir - excluir permite establecer los archivos que deben ser incluidoso excluidos del procesamiento de backup. La sentencia incluir es usada parados propósito. Uno es para especificar excepciones a la lista excluir. El otro espara asociar a una clase administradora con un archivo o un grupo de archivos.La sentencia incluir también es usada durante el archivado para determinar laclase administradora, mientras la sentencia excluir no es comprobada duranteel prosesamineto de archivado.

A no ser que se tenga la sentencia EXCLUDE.DIR, el tipo de directorio de losarchivos son siempre incluidos en el backup, incluso cuando todos los archivosdentro del directorio son excluidos.

La lista incluir - excluir usa metacharacters para seleccionar archivos aser incluidos o excluidos. Algún metacharacters se diferencia dependiendode la plataforma del cliente. Estos metacharacters permiten especificar elprocesamiento comodín. Los metacharacters también pueden ser usado en lalínea de comando para indicar la especificación del archivo en la mayoría delos comandos.

Los metacharacters incluyen: (Los ejemplos están en paréntesis)

? - Uno y sólo un carácter matched como un comodín (us?r.doc)

* - Match cualquier número de carácteres como un comodín (us*.doc)

\ ... - Windows: Match cualquier directorio (\ ...\user.doc)

11.3.9 Procesamiento Incluir - Excluir

Usar el diagrama de flujo de la fig. 11.13 de la pág. 241, para determinar siun archivo será incluido o excluido del procesamiento según las reglas propor-cionadas para el incluir - excluir.

11.3.10 Procesamiento Continuado del Incluir - Excluir

El proceso incluir - excluir es un proceso bottom up en el cual la últimasentencia incluir - excluir se comprueba primero. Cuando el archivo encuentra


Figura 11.13: Procesamiento Incluir - Excluir


la sentencia, finaliza el procesamiento excluir para ese archivo. La lista incluir- excluir es generada en el archivo de opciones de configuración. La lista excluiren el archivo de opciones puede ser anulada por las opciones incluir - excluiren el comando. La fig. 11.14 de la pág. 242, muestra un ejemplo.

Figura 11.14: Procesamiento Continuado del Incluir - Excluir

11.3.11 Excluir Directorios de Backup

Sentencia EXCLUDE.DIR

La sentencia EXCLUDE.DIR excluye una estructura de directorio desde elárbol de recorrido interno que el cliente del backup y archivado del TSM cons-truye internamente ántes de realizar el backup y previene que los directoriosy atributos del directorio sean copiados, fig. 11.15 de la pág. 243.


Figura 11.15: Excluir Directorios de Backup


• EXCLUDE.DIR: Excluye una estructura de directorio del backup eimpide que sea alcanzada durante el backup incremental.

• EXCLUDE.FILE: Puede ser abreviado a EXCLUDE y excluir archivosde backup. Un directorio es alcanzado incluso si todos los archivos deaquel directorio son excluidos.

Si una estructura de directorio es excluida usando EXCLUDE.DIR, los sub-directorios en el árbol excluido de directorio no son eligibles para el backup.Algunas sentencias INCLUDE que incluyen parte de una estructura de directorioexcluida son ignoradas en el momento del backup.

Backup de Directorios Excluidos

Incluso aunque una estructura de directorio sea excluida usando la nuevasentencia EXCLUDE.DIR, los subdirectorios y archivos dentro de la estructurade directorio excluida pueden ser explícitamente resguardados.

La sentencia excluir esta en el archivo de opción del usuario cliente (dsm.opt)sólo en usuarios del TSM como clientes Windows.

11.3.12 Uso de Números de Sequencias en un Conjunto deOpciones

Las opciones son procesadas comenzando con el número de secuencia más alto.Algunas sentencias incluir - excluir en el conjunto de opciones del cliente delservidor tienen prioridad sobre las sentencias incluir - excluir en el conjunto deopciones del cliente local. Las sentencias incluir - excluir del servidor siempreson forzadas y colocadas al final de la lista incluir - excluir y evaluadas ántesde las sentencias incluir - excluir del cliente, (fig. 11.16 de la pág. 245).

Si el conjunto de opción del servidor tiene varias sentencias incluir - excluir,las sentencias son procesadas comenzando con el número de secuencia más alto.El cliente puede usar el comando QUERY INCLEXCL para ver las sentenciasincluir - excluir en el orden en que son procesadas. QUERY INCLEXCL tambiénmuestra el recurso de cada sentencia incluir - excluir.


Figura 11.16: Uso de Números de Sequencias en un Conjunto de Opciones


11.3.13 Consultar, Eliminar o Actualizar un Conjunto de Op-ciones del Cliente

Los conjuntos de opciones del cliente pueden ser consultados, eliminados, o ac-tualizados usando los comandos QUERY, DELETE, y UPDATE CLOPTSET. Opcionesindividuales del cliente dentro de un conjunto de opciones pueden ser elimi-nadas usando el comando DELETE CLIENTOPT. El número de secuencia de unaopción del cliente puede ser cambiado usando el comando UPDATE CLIENTOPT,(fig. 11.17 de la pág. 247).

Es posible también crear un archivo que tenga sentencias incluir - excluir,y se señale un cliente a éste archivo. Esto es práctico cuando se quiere crearun conjunto de sentencias y señalar a múltiples clientes en él.


Figura 11.17: Consultar, Eliminar o Actualizar un Conjunto de Opciones delCliente

Capítulo 12

Funciones de Bachup yArchivado del Cliente

12.1 Introducción

El cliente se comunica con el servidor e invoca las funciones cliente del StorageManager.

El cliente es soportado sobre una variedad de las plataformas que podríanresidir en una estación de trabajo de usuario o en un servidor LAN. En estecapítulo se detallarán varios métodos disponibles para resguardar, restaurar,archivar y recuperar datos, y qué opciones están disponibles para personalizarestos procesos según las necesidades.

12.2 Tipos de Backups Disponibles

12.2.1 Tipos de Backups Disponibles Desde la GUI

La fig. 12.1 de la pág. 250, muestra los diferentes tipos de backup disponiblesdesde la interface gráfica de usuario.

249

250 CAPÍTULO 12. BACKUP Y ARCHIVADO DEL CLIENTE

Figura 12.1: Tipos de Backups Disponibles Desde la GUI

12.2. TIPOS DE BACKUPS DISPONIBLES 251

12.2.2 Backup Incremental (Completo) y Basado en Journal

La función de backup incremental (también conocido como incremental com-pleto) resguarda todos los archivos que se han modificado y todos los archivosque fueron creados desde el último backup. Esta función realiza un backupbasado en journal de aquellos sistemas de archivos previamente seleccionadospara journaling. La función de backup incremental no resguarda los archivosque son excluidos por la lista incluir - excluir (fig. 12.2 de la pág. 251).

Figura 12.2: Backup Incremental y Basado en Journal

El backup basado en journal es soportado en todos los clientes Windowsexcepto el cliente Windows Server 2003 de 64-bit. Si se instala el servicio demotor journal y éste se ejecuta, entonces por defecto el comando incrementalautomáticamente realizará un backup basado en journal en los sistemas de


archivos seleccionados que están siendo supervisados por el journal engineservice.

El Tivoli Storage Manager no usa la facilidad journaling inherente en lossistemas de archivos Windows NTFS o ningún otro sistema de archivo jour-naled.

Para realizar satisfactoriamente un backup basado en journal, varias con-diciones deben ser encontradas. Estas incluyen:

• El servicio journal debe ser configurado para supervisar el sistema dearchivo que contiene los archivos y directorios que están siendo resguar-dados.

• Un backup incremental completo tiene que haber sido ejecutado satis-factoriamente al menos una vez en el sistema de archivo que está siendoresguardado.

• La imagen del espacio de archivo del sistema de archivo en el servidorno debe haber sido modificado por un comando administrativo desde elúltimo incremental completo.

• La política de administración del almacenamiento para los archivos queestán siendo resguardados no debe haber sido actualizada desde el últimoincremental completo.

12.2.3 Backup Incremental por Fechas (Sólo Fechas)

Para un disco o volumen a ser eligible para backups incrementales por fecha,se debe haber realizado al menos un backup incremental completo de aqueldisco entero o volumen. Ejecutar un backup incremental de sólo una ramadel directorio o del archivo individual no hará que el disco o el volumen seaneligible para backups incrementales por fecha.

Para realizar un backup incremental por fecha utilizando el GUI, selec-cionar la opción Incremental (date only) desde el tipo de backup del menúdesplegable o usar la opción INCRBYDATE con el comando INCREMENTAL. Verla fig. 12.3 de la pág. 253.

El cliente respalda sólo aquellos archivos cuya fecha y hora de modificaciónson posteriores a la fecha y la hora del último backup incremental del sistema


Figura 12.3: Backup Incremental por Fechas


de archivo en el cual el archivo reside.

Los archivos agregados por el cliente después del último backup incremen-tal, pero con una fecha de modificación anterior al último backup incremental,no son resguardados.

Los archivos que fueron renombrados después del último backup incremen-tal, pero permanecen inalterados no serán resguardados.

Incremental por la fecha sin embargo, no comprobará lo siguiente:

• Frecuencia.

• Nuevos archivos.

• Archivos eliminados.

• Cambios en los atributos del archivo.

• Rebinding de archivos.

12.2.4 Backup Incremental (sin Journal)

Un backup incremental (sin journal) realiza un backup incremental sin usar eljournal del backup de la base de datos. Ver fig. 12.4 de la pág. 255.

En el proceso de ejecutar un backup incremental (sin journal) se procedecomo se indica a continuación:

1. El cliente comienza la sesión, y pide la información de backup.

2. Hay una búsqueda en la base de datos del TSM para la informaciónsobre los archivos del cliente.

3. Si no hay información, quiere decir que nunca antes hubo un backup,entonces un backup completo ocurrirá.

4. Si hay información en la base de datos, aquella información acerca decuáles archivos han sido cambiados se retransmite, y luego TSM realizaun backup incremental.


Figura 12.4: Backup Incremental (sin Journal)


12.2.5 Siempre Backup (Selectivo) de Backup

El backup selectivo siempre intenta resguardar los objetos que se seleccionó.Usar un backup selectivo cuando se quiere resguardar archivos específicos odirectorios independientemente de si una copia corriente de aquellos archivosexiste en el servidor. Ver fig. 12.5 de la pág. 256.

Figura 12.5: Siempre Backup (Selectivo) de Backup

12.2.6 Backup de Imagen Fotográfica

Un backup de imagen fotográfica realiza un backup de la imagen en línea de unvolumen en el cual el volumen permanece activo y disponible para operacionesde lectura y escritura durante el backup. Esta función está disponible sólo siel Tivoli Storage Manager Logical Volume Snapshot Agent está instalado ydisponible. Este ítem es visible sólo si la imagen plug-in esta instalada y el


cliente está conectado a un servidor que ejecuta el Tivoli Storage ManagerV5.1 o superior. Ver fig. 12.6 de la pág. 257.

Figura 12.6: Backup de Imagen Fotográfica

12.2.7 Backup de Imagen (Windows 2000 y XP)

El tipo de backup Image Backup (Windows 2000 y XP) hace lo siguiente:

• Realiza un backup de imagen en línea o fuera de línea dependiendo deltipo de imagen configurado en la sentencia Include.Image en el Include-Exclude de la página Preferences o en el archive de opciones del cliente.

• Si el tipo de imagen es configurado a Snapshot, entonces el cliente realizaun backup de imagen en línea.


• Si el tipo de imagen es configurado a Static, entonces el cliente realizaun backup de imagen fuera de línea.

• Si no hay sentencia Include.Image o no hay configuración del tipo deimagen, entonces el cliente por defecto realiza un backup de imagen enlínea si el Logical Volume Snapshot Agent (LVSA) está instalado.

• Si el LVSA no esta instalado, entonces el cliente por defecto realiza unbackup de imagen fuera de línea.

Desde la estación de trabajo local, se puede resguardar uno o más volúme-nes como un sólo objeto (backup de imagen) en el sistema. Estos volúmenespueden ser formateados a FAT, FAT32, NTFS, o volúmenes RAW no forma-teados. Si un volumen es formateado a NTFS, sólo aquellos bloques usadospor el sistema de archivo serán resguardados.

El backup de imagen está visible sólo si la imagen plug-in está instalada yel cliente está conectado a un servidor que ejecuta el Tivoli Storage ManagerV5.1 o superior.

12.2.8 Backup de Imagen Incremental (Sólo fecha)

El backup de Imagen Incremental (sólo fecha) hace lo siguiente:

• Realiza un backup incremental - por - día de la última imagen.

• Resguarda los archivos que han cambiado en el volumen desde el últimobackup de imagen.

• No marca los archivos inactivos en el servidor para archivos que han sidoeliminados de la máquina cliente.

Se puede Realizar backup incremental - por - día de la última imagenindependientemente de si la imagen completa fue resguardada usando backupde imagen en línea o fuera de línea. Se recomienda usar backup de imagen encombinación con backup incrementales regulares para que la restauración seamás fácil.

12.3. REALIZACIÓN DE BACKUPS DEL CLIENTE 259

12.3 Realización de Backups del Cliente

12.3.1 Uso del Backup - Archive de la GUI del TSM, Resguar-dar Archivos Desde un Cliente

La fig. 12.7 de la pág. 259 muestra un ejemplo.

Figura 12.7: Uso del Backup-Archive de la GUI del TSM, Resguardar ArchivosDesde un Cliente

12.3.2 Seleccionar Archivos y Realizar un Backup

Se debe tomar un momento para ver el Backup-Archive en el árbol de direc-torio de la GUI. Se verá que no sólo están representados los archivos locales


y remotos, sino que además están representados en el árbol los RAW, losremovibles, y los objetos del sistema. Ver la fig. 12.8 de la pág. 260.

Figura 12.8: Seleccionar Archivos y Realizar un Backup

La selección box next to a branch puede tener los siguientes estados:

• No seleccionado (vacío).

• Parcialmente seleccionado (parcialmente lleno).

• Implícitamente seleccionado (lleno).

• Totalmente seleccionado (comprobado).


12.3.3 Resultados de la Revisión del Backup

Mientras el backup se está ejecutando, se mostrará la ventana de la fig. 12.9de la pág. 261, la cuál muestra el progreso del backup. Cuando el backuptermina, la ventana mostrará los resultados del backup.

Figura 12.9: Resultados de la Revisión del Backup

12.3.4 Uso de la Función Find

Hacer clic en el botón de la parte de arriba de la pantalla donde aparecencampos resaltados o seleccionar Edit >> Find para hallar la función Find.Notar los nombres de los archivos en el directorio del TSM.

La función Find filtra o busca archivos almacenados localmente en el dis-


co de un cliente o archivos en el servidor TSM. Al invocar la función Findaparece una ventana para filtrar archivos o buscar archivos que correspondera ciertos criterios. Los archivos que corresponden con el filtro del criteriosde búsqueda entonces pueden ser seleccionados para realizar una acción enel Storage Manager (resguardar, archivar, recuperar, restaurar, o eliminar elfichero archivado). Ver la fig. 12.10 de la pág. 262.

Figura 12.10: Uso de la Función Find

12.3.5 Resultados de un Filtro

Cuando se seleccionan nombres que comienzan con una b y luego se hace clicken el botón Filter en lugar del botón Find, los nombres de archivos listados enel directorio del TSM serán sólo los nombres de archivos que comienzan con


la letra b.

Así, Find Files da otra ventana de la cual se pueden seleccionar archivos,y el Filter modifica los archivos mostrados en la ventana de backup. Ver fig.12.11 de la pág. 263.

Figura 12.11: Resultados de un Filtro

12.3.6 Función File Details

La función File Details muestra información detallada sobre un archivo odirectorio que es manejado por el Storage Manager o es local en un disco delcliente. Ver la fig. 12.12 de la pág. 264.

File Details muestra información detallada sobre el archivo o el directorioque está actualmente seleccionado:


Figura 12.12: Función File Details


• Nombre.

• Tamaño.

• Archivo.

• Directorio.

• Espacio del archivo.

• Fecha de Modificación.

• Fecha de Creación.

• Última Fecha de Acceso.

• Atributos (Bit de archivot, atributos extendidos, etc.).

12.3.7 Uso de la Función de Estimación

La función de estimación usa la información recolectada durante backups an-teriores (datos históricos) para estimar cuanto tiempo tomará realizar un bac-kup. Si nunca ántes se ha resguardado un ítem, no habrá ninguna informaciónde estimación disponible. La estimación es calculada usando la tasa de trans-ferencia media y la tasa de compresión media de operaciones anteriores.

La función de estimación calcula el número de bytes que los objetos se-leccionados actualmente ocupan para explorar los directorios seleccionados osolicitar información de archivo del servidor TSM.

Los datos históricos son almacenados en el disco del cliente. Si el cliente seconecta a múltiples servidores, entonces es registrado uno por uno en la basedel servidor.

12.3.8 Seleccionar Siempre Backup Como Tipo de Backup

Seleccionar archivos cuando se realiza un backup selectivo es igual que el in-cremental. Las opciones Find Files y Filter también pueden ser usadas conel Selectivo tal como el Incremental. Ver la fig. 12.13 de la pág. 266.

Modificar las Opciones de Backup

Los ejemplos de opciones de backup incluyen:


Figura 12.13: Seleccionar Siempre Backup Como Tipo de Backup

12.4. RESTAURAR ARCHIVOS 267

COMPRESSALWAYS.

MEMORYEFFICIENTBACKUP.

La opción de compresión especifica si el Storage Manager debería com-primir los archivos antes de enviarlos al servidor TSM. La compresión de losarchivos disminuye la cantidad de almacenamiento de datos requerido paraalmacenar versiones de backup y copias de archivado de los archivos. Estopuede, sin embargo, afectar el rendimiento del Storage Manager.

Un procesador rápido en una red lenta se beneficia de la compresión, peroun procesador lento sobre una línea rápida no lo hace. Esta opción controlala compresión sólo si el administrador del TSM especifica que el nodo clientedetermina la selección.

El Storage Manager continúa comprimiendo un archivo incluso si éste de-termina que el tamaño de archivo aumenta. La opción COMPRESSALWAYScontrola qué hace el Storage Manager cuando un archivo crece durante lacompresión.

Se puede especificar continuar comprimiendo, o enviar el objeto otra vezsi crece durante la compresión.

La opción MEMORYEFFICIENTBACKUP especifica un algoritmo máseficiente de memoria para procesar backup incrementales, resguardando undirectorio a la vez, y usando menos memoria. Se debe usar esta opción cuandola máquina tiene poca memoria o cuando no se tiene sistemas bien equipados.

12.4 Restaurar Archivos

Descripción del Restore

Restore es el proceso de copiar una versión de backup de un archivo delusuario desde el servidor del Storage Manager a la estación de trabajo o alservidor LAN.

• Los clientes puede solicitar restaurar sus propios archivos.

• Los usuarios puede restaurar los archivos de otros con autorización.


• El servidor del Storage Manager envía la copia del archivo al cliente,pero permanece el backup en el servidor.

• El usuario puede restaurar archivos resguardados a un punto específicoen el tiempo.

• Los usuarios pueden hacer restauraciones a través de la GUI, la línea decomando del cliente, o a través de un schedule.

Si un archivo se daña, el usuario (cliente Storage Manager) puede solicitarque el sistema restaure el mismo o una versión específica del backup sin laayuda de un administrador.

Un usuario sólo puede restaurar archivos que él ha resguardado a no serque tengan autoridad para acceder a los archivos de backup de otra persona.

Cuando un usuario restaura una versión de backup de un archivo, el Stora-ge Manager envía una copia del archivo al nodo cliente. La versión de backuppermanece en el servidor de Storage Manager. Si existe más de una versiónde backup, un usuario puede restaurar la versión activa de backup del archivoo cualquier versión inactiva de backup.

Si la política es correctamente instalada, un usuario puede restaurar ar-chivos resguardados a un punto específico en el tiempo. Un usuario puederestaurar archivos a otra ubicación diferente de la cual los backups fueron ob-tenidos. Un usuario también puede hacer restauraciones a través de la GUI,la línea de comando del cliente, o a través de un schedule.

12.4.1 Restaurar Archivos Usando la GUI

La restauración GUI pregunta al servidor TSM acerca de una lista de losarchivos que han sido resguardados y los presenta en el mismo formato queel backup GUI. Simplemente hay que seleccionar los archivos que se quiererestaurar.

También se puede usar la función Find para seleccionar los archivos. Lafunción Find da las mismas opciones que aquellas usadas para hacer un bac-kup, pero buscará archivos resguardados en el servidor TSM de los cualesseleccionar para restaurar.


12.4.2 Restaurar una Versión Específica de un Archivo

Para restaurar una versión específica de un archivo, se debe seleccionar Viewand display. Cuando se muestra la pantalla de la fig. 12.14 de la pág. 269,seleccionar la posición Original.

Figura 12.14: Restaurar una Versión Específica de un Archivo

12.4.3 Modificar Opciones de Restauración

El panel Modify Restore Options ofrece varias opciones para el proceso derestauración.

Escoger All selected files and directories recupera tanto archivos co-


mo directorios; cuando se escoge Files only se recupera sólo archivos cuandose escoge Directories only se recupera sólo directorios. También se puedeespecificar qué acciones tomar en archivos que ya existen. Se puede aún espe-cificar cómo restaurar la imagen escogiendo sólo la imagen, o la imagen másdirectorios y archivos incrementales.

La siguiente opción está disponible durante sólo el proceso de restauración:

Se selecciona la caja de comprobación Restore NTFS security informa-tion si se quiere restaurar la información de seguridad NTFS como permisosde archivo y calcular la comprobación de redundancia cíclica (CRC) de seguri-dad de Windows para los archivos. Esto es aplicable sólo a archivos Windowsen unidades NTFS. Ver fig. 12.15 de la pág. 270.

Figura 12.15: Modificar Opciones de Restauración

Nota 12.1 Escoger esta opción podría reducir la velocidad de la restauración


porque Tivoli

Storage Manager tiene que recuperar toda la información de seguridad delNTFS.

Las opciones que se especifican son efectivas durante la operación corrientedel cliente, pero no permanecen guardadas para la siguiente operación.

12.4.4 Mostrar Versiones Activas e Inactivas de un Archivopara Restaurar

La fig. 12.16 de la pág. 271 muestra un ejemplo.

Figura 12.16: Mostrar Versiones Activas e Inactivas de un Archivo para Res-taurar


12.4.5 Restauración a un Punto en el Tiempo

El Storage Manager usa la restauración a un punto en el tiempo (PIT) pararestaurar un espacio de archivado, directorio, o archivo a la versión igual oantes del punto en el tiempo. Los backup incrementales son necesarios paracapturar los archivos que han sido suprimidos.

El soporte para la restauración PIT es esencial para recuperar un espaciode archivo o el directorio a un momento para el cual se conoce que su estadoes consistente. Por ejemplo, una restauración PIT puede eliminar el efecto dedatos dañados o recuperar una configuración a una fecha u hora previa.

Cuando se realiza una restauración PIT, los nuevos archivos que se hancreado en el cliente después de la fecha PIT no son eliminados.

Las restauraciones de un punto en el tiempo que incluyen archivos elimina-dos son posible cuando los backups incrementales son ejecutados en el cliente.Esto es porque el servidor sólo es notificado de los archivos que son eliminadosde un espacio de archivo del cliente durante un backup incremental.

Los backups incrementales deberían ejecutarse frecuentemente para pro-porcionar la resolución necesaria en un punto del tiempo. Los archivos quehan sido eliminados de un espacio de archivo del cliente entre dos backupsincrementales podrían ser restaurados durante una restauración en un puntodel tiempo.

12.4.6 Restauraciones Relanzables

Si un error ocurre en medio de una restauración, el usuario puede comenzarotra restauración especificando la misma fuente y destino. Si la restauración secomienza dentro del período de reinicio permitido, la restauración comenzarádesde donde quedó.

Si una restauración es recomenzada, algunos archivos pueden ser restau-rados otra vez dependiendo cuantas transacciones del Tivoli Storage Managerfueron completadas cuando ocurrió el error.

Una restauración recomenzada comienza en un límite de transacciones de-finido por las opciones TXNGROUPMAX y TXNBYTELIMIT del cliente ydel servidor del TSM.

12.5. ARCHIVADO Y RECUPERACIÓN 273

Para realizar una restauración relanzable utilizando la GUI, se deben seguirestos pasos:

1. Click en Help de la ventana Restore.

2. Click Restoring Backup Versions.

3. Click en Work with restartable restore sessions.

12.5 Archivado y Recuperación

12.5.1 Archivar y Recuperar Usando la GUI

El archivado GUI presenta una lista de los archivos en el mismo formato queen el backup GUI. Seleccionar los archivos que se quieren archivar y pulsar elbotón de Archive.

También se puede usar la función Find para seleccionar archivos. La fun-ción Find da las mismas opciones para realizar un backup. Ver fig. 12.17 dela pág. 274.

Descripción de Archivado

• La función archivar es usada para conservar archivos para el empleoposterior o para registros.

• Archivar puede ser usado para solicitar al Storage Manager copias dearchivos, subdirectorios, y directorios para almacenamiento a largo plazoen medios controlados por el Storage Manager.

• Cuando los usuarios archivan archivos, pueden decidir hacer que el Stora-ge Manager borre los archivos originales de la estación de trabajo despuésde que los archivos son archivados.

• El Storage Manager usa paquetes de archivo para identificar los gruposde archivos archivados.

Archivar Archivos


Figura 12.17: Archivado y Recuperación


• La función archivar permite que el grupo de archivos importantes tengauna descripción asociada para archivarlos y más tarde recuperarlos.

• Se puede archivar múltiples archivos, directorios, o subdirectorios juntos.

• El archivado es procesado de manera diferente a la del backup en la cualuna copia es almacenada en el servidor independientemente del estadode cambio o la frecuencia del backup.

• Los archivos puede ser agrupados según la descripción para una fácilrecuperación.

• Se usa un grupo separado de copia para el archivado y backup de modoque cada clase administradora pueda manejar las diferencias entre elbackupy el archivado.

Descripciones del Archivo

Una descripción de archivo es un campo de texto de 255 carácteres queidentifica archivos y directorios archivados.

El Backup-Archive GUI lista todas las descripciones de archivo usadaspreviamente.

Cuando los archivos son archivados usando el backup-archive del cliente, serequiere una descripción del archivo. La descripción de archivo es un campode texto de 255 byte que puede contener información relevante a los archi-vos y directorios archivados. Si no se igresa una descripción, se asigna unadescripción de archivado por defecto.

TSM almacena las descripciones de archivado en un nuevo formato inter-namente en la base de datos del TSM. Un proceso de conversión inicial ocurrecuando un usuario comienza una función de archivado en la GUI. Este procesode conversión puede ejecutarse mucho tiempo si el usuario posee un númerogrande de archivos archivados. El proceso de conversión puede ser canceladoy recomenzado luego.

Descripción del Archivado

La descripción de archivado es una cadena de texto de 255 carácteresasociada con archivos y directorios. La descripción de archivado puede serusada para localizar e identificar archivos y directorios sin el conocimiento delos espacios físicos del archivo del cliente donde los mismos fueron archivados.


12.5.2 Únicas Descripciones de Archivo

Cuando la función archivado es seleccionada desde el backup - archivado dela GUI, se muestra una lista de todas las descripciones de archivado usadaspreviamente. Las descripciones de archivado mostradas pueden ser usadas enarchivados subsecuentes.

12.5.3 Paquetes de Archivado

Un paquete de archivado es un conjunto de archivos y directorios archivadoscon una única descripción de archivo común. Todos los archivos archivadosrequieren una descripción. La especificación de una descripción única de ar-chivo crea un nuevo paquete. La descripción por defecto es: Archive Date:mm/dd/yyyy.

12.5.4 Modificar Opciones de Archivado

En el diálogo Archive Options se puede seleccionar comprimir o comprimirsiempre, elegir que TSM elimine los archivos de la estación de trabajo despuésde que son satisfactoriamente archivados, y elegir modificar la lista incluida yseleccionar la clase de manejo que se desea para el archivo. Ver fig. 12.18 dela pág. 277.

Archivo V2

Seleccionar Archivo V2 para archivar sólo archivos seleccionados sin ar-chivar el directorio entero de los archivos (como el archivar ADSM Version2).

La acción por defecto es para el directorio entero de archivos seleccionadospara ser archivados a no ser que se especifique la opción V2archive.

Además, si se selecciona un directorio para archivar, todos los archivosy subdirectorios en su ruta son archivados. Sin embargo, haciendo click enV2archive, cualquier directorio seleccionado y sus subdirectorios no son archi-vados, sólo los archivos en su ruta.

La opción que se especifica es eficaz durante la operación corriente delcliente, pero no se retiene para la siguiente operación.


Figura 12.18: Anular Opciones de Archivado


Seleccionar Override de la lista incluir - excluir para anular las clases ad-ministradoras asociadas con los objetos por medio de la lista incluir - excluir.

12.5.5 Recuperación Usando la GUI

Cuando un usuario recupera un archivo, el Storage Manager envía una copiadel archivo al nodo cliente. El archivo archivado deja el servidor del StorageManager. La fig. 12.19 de la pág. 278, muestra la interface GUI para recuperarun archivo.

Figura 12.19: Recuperación Usando la GUI

La ventana retrieve muestra objetos que se han archivados antes en el

12.6. BACKUPS Y RESTAURACIÓN 279

servidor. Se puede usar esta ventana para seleccionar objetos que se quiererecuperar. También se puede ejecutar una estimación para recuperar o cambiarlas opciones de procesamiento.

12.5.6 Recuperar Paquetes de Archivo Usando la GUI delCliente

La GUI muestra la recuperarción de archivos archivados jerárquicamente enun árbol desplegable de directorios. Los archivos son agrupados según susdescripciones de archivado. La ampliación del árbol desplegable de descripciónmuestra los directorios y los archivos individuales de los cuales consiste elpaquete de archivado.

12.5.7 Opciones de Recuperación - Modificar las Opciones deRecuperación y de Colisión

La pantalla modify retrieve and collision options, mostrada en la fig. 12.20 dela pág. 280, permite especificar qué objetos recuperar y qué acciones tomarpara los archivos que ya existen.

12.6 Backups y Restauración con la Línea de Co-mandos

12.6.1 Utilización de la Línea de Comandos para el Backup yel Archivado

La línea de comandos de backup y de archivado ofrece más opciones pararesguardar y restaurar datos. Hay también más de un método para invocar lamisma línea de comandos. Ver la fig. 12.21 de la pág. 281.

12.6.2 Realizar un Backup Incremental con la Línea de Co-mandos

Cuando se ejecuta un backup incremental con la línea de comandos, se ve unadescripción de los resultados desde principio a fin. Ver la fig. 12.22 de la pág.


Figura 12.20: Modificar las Opciones de Recuperación y de Colisión


Figura 12.21: Utilización de la Línea de Comandos para el Backup y el Ar-chivado


282.

Figura 12.22: Realizar un Backup Incremental con la Línea de Comandos

12.6.3 Ejemplos de Backup Selectivos

El comando selectivo resguarda los archivos que se especifica. Si estos archivosson dañados o perdidos, se pueden sustituir por versiones de backup del servi-dor. Cuando se ejecuta un backup selectivo, todos los archivos son candidatospara el backup a no ser que se los excluya del backup, o si estos no encuentranrequerimientos de la clase administradora para la serialización.

Para resguardar todos los archivos en el directorio d:\proj, usar el siguientecomando:

dsmc selective d:\proj\*

Para incluir todos los subdirectorios al mismo backup:


dsmc selective d:\proj\ -subdir=yes

12.6.4 Realizar Backup Incremental de Sólo un Directorio Es-pecificado

La opción dirsonly procesa sólo directorios, y está disponible sólo en la líneade comandos. El cliente no procesa los archivos. Esta opción es válida paratodos los clientes Windows. El cliente API del Storage Manager no soportaesta opción. Ver la fig. 12.23 de la pág. 283.

Figura 12.23: Realizar Backup Incremental de Sólo un Directorio Especificado

12.6.5 Uso del Comando Query Filespace

El comando Query FILESpace muestra una lista de los espacios de archiva-do en el almacenamiento del Storage Manager. También se puede especificar


un solo nombre de espacio de archivado al hacer la pregunta. Esto tam-bién se puede hacer desde la línea de comandos del cliente sin el parámetroFormat=Detailed. Ver la fig. 12.24 de la pág. 284.

Figura 12.24: Uso del Comando Query Filespace

12.6.6 Restaurar Archivos Resguardados Usando el Comandode Restauración dsmc

La fig. 12.25 de la pág. 285 muestra un ejemplo de la restauración de archivosresguardados con el comando dsmc.


Figura 12.25: Restaurar Archivos Resguardados Usando el Comando de Res-tauración dsmc


12.6.7 Uso del Comando de Restauración dsmc con la OpciónPICK

La función restore permite restaurar archivos desde la interfaz de línea decomandos.

El comando restore es:

• Precedido por dsmc.

• Continuado por opciones y una especificación de archivado de los archi-vos a restaurar desde el servidor.

Usar la opción PICK para listar backup activos e inactivos almacenadosen el servidor. Esto puede ser usado para escoger una versión de backup quees más vieja que el backup más reciente.

Usar la opción INACTIVE para indicar al Storage Manager restaurar unbackup inactivo, si un activo no está disponible. Ver la fig. 12.26 de la pág.287.

12.6.8 Utilización del Comando dsmc restore con Superposi-ción

La fig. 12.27 de la pág. 288 muestra un ejemplo de la utilización del comandodsmc restore.

12.6.9 Uso de la Opción LATEST con el Comando dsmc res-tore

El uso de la opción LATEST restaura la versión más reciente de backup deun archivo, incluso si el backup esta inactivo. Sólo versiones activas son consi-deradas para restaurar a no ser que se usen las opciones inactive o latest. Verla fig. 12.28 de la pág. 289.


Figura 12.26: Uso del Comando de Restauración dsmc con la Opción PICK


Figura 12.27: Utilización del Comando dsmc restore con Superposición


Figura 12.28: Uso de la Opción LATEST con el Comando dsmc restore


12.6.10 Restaurar a una Nueva Posición Usando la Opción deRestauración PRESERVEPATH

La opción de restauración PRESERVEPATH ha sido agregado al backup -archivado de la línea de comandos del cliente. Esta opción permite a losusuarios especificar cómo serán manejadas las estructuras de directorio cuandose realiza la restauración a una nueva localización.

Esto crea el directorio fuente de nivel más bajo como un subdirectorio deldirectorio objetivo.

Los archivos del directorio fuente son almacenados en el nuevo subdirecto-rio. Ver fig. 12.29 de la pág. 290.

Figura 12.29: Restaurar a una Nueva Posición Usando la Opción de Restau-ración PRESERVEPATH

La opción PRESERVEPATH puede ser especificada con una de las siguien-tes opciones siguientes:


• subtree: Crea el directorio fuente del nivel más bajo como un subdirec-torio del directorio objetivo. Los archivos del directorio son almacenadosen el nuevo subdirectorio. Esto es por defecto.

• complete: Restaura la ruta completa, comenzando desde la raíz, en eldirectorio especificado.

La ruta completa incluye todos los directorios excepto el nombre de espaciodel archivo.

• nobase: Restaura el contenido del directorio fuente sin el nivel másbajo, o el directorio base, en el directorio de destino especificado.

• none - Restaura todos los archivos fuente seleccionados al directorioobjetivo. Ninguna parte de la ruta fuente en o encima del directoriofuente se reproduce en el objetivo.

Si se especifica subdir=yes, Tivoli Storage Manager restaura todos losarchivos en los directorios fuente a un sólo directorio objetivo.

12.6.11 Uso del IFNEWER con el Comando dsmc restore

Usar la opción IFNEWER para guiar al Storage Manager a sustituir un archivoexistente por el backup, si el backup es más reciente que el archivo existente.Ver fig. 12.30 de la pág. 292.

12.6.12 Utilización de las Opciones PITDATE y PITTIME

Las opciones TODATE y TOTIME o PITDATE y PITTIME especifican unafecha y un rango de tiempo para el tratamiento de restauración. Ver fig. 12.31de la pág. 293.

12.6.13 Comandos de Restauración Reiniciable

La restauración reiniciable puede ser realizada también desde la línea de co-mandos. Se puede usar el comando query restore para averiguar si el cliente


Figura 12.30: Uso del IFNEWER con el Comando dsmc restore


Figura 12.31: Utilización de las Opciones PITDATE y PITTIME


tiene algunas sesiones de restauración reiniciable en el servidor de la base dedatos.

Comandos de Restauración Reiniciable

QUERY RESTORE

Los reportes activos se restauran con el número de sesión asociado.

Las restauraciones reiniciables son reportes con números negativos de se-siones, que las hacen más fáciles de identificar.

RESTART RESTORE

Inicia una sesión de restauración reiniciable. Se presenta al usuario unalista de sesiones de rastauración reiniciables por número.

CANCEL RESTORE

Cancela una sesión de restauración reiniciable y la elimina de la lista pre-guntando al usuario que sesión cancelar.

CANCEL SESSION

Cancela sesiones de restauración.

Para asegurar una restauración consistente, el espacio de archivo del clienteque es restaurado durante una restauración reiniciable se cierra cuando unarestauración reiniciable se está ejecutando.

El Storage Manager mueve todas las operaciones hacia medios secuencialesque contienen archivos prevenidos del nodo o del espacio de archivado. Losbackups del cliente TSM que afectan datos son restaurados y también sonprevenidos.

El estado de la restauración reiniciable se quita desde la base de datosdel Storage Manager luego de una exitosa restauración, o cuando el proce-so restaurar es cancelado por el cliente o por un administrador del StorageManager.

El estado de la restauración reiniciable también es quitado por algunosprocesos del servidor TSM después de que el RESTOREINTERVAL ha trans-currido.

Las operaciones de movimiento de datos del servidor tales como migración


y recuperación y el comando MOVE DATA quitan el estado de la restauraciónreiniciable desde la base de datos del Storage Manager cuando están en ejecu-ción.

El estado de la restauración se quita también durante el procesamiento deexpiración. El proceso de expiración es cuando los archivos son identificadospara la eliminación porque su fecha de vencimiento o el período de retenciónha pasado.

12.6.14 Línea de Comandos de Archivado y Recuperación

El comando archive archiva un solo archivo, archivos seleccionados, o todoslos archivos en un directorio y sus subdirectorios en un servidor TSM. Losdirectorios son archivados.

Se puede archivar los archivos que se quiere mantener en su condiciónactual. Para liberar espacio de almacenamiento en la estación de trabajo,eliminar archivos tal como se los archivó. Se debe recuperar los archivosarchivados a la estación de trabajo siempre que se los necesite otra vez. Verfig. 12.32 de la pág. 296.

Las opciones disponibles para el comando archive son:

archmc: Usar la opción archmc para nombrar la clase de administracióndisponible en el conjunto activo de política del dominio de política.

deletefiles: Usar la opción deletefiles para eliminar archivos archivados des-de la estación de trabajo después de que son almacenados en el servidor.

description: Usar la opción description para asignar una descripción a unarchivo cuando se lo archiva. Si no se recuerda el nombre de un archivoarchivado, se puede usar la opción description para recuperar el archivo.

dirsonly: Usar la opción dirsonly para resguardar y restaurar sólo los direc-torios.

filesonly: Usar la opción filesonly para resguardar y restaurar sólo los ar-chivos.

Cuando se archiva un link simbólico, TSM archiva el archivo al cual el linksimbólico señala. Esto no archiva la información de la ruta para el directorio.


Figura 12.32: Línea de Comandos de Archivado y Recuperación


Si se archiva un link simbólico que apunta a un directorio, TSM archiva losarchivos contenidos en el directorio (y sus subdirectorios si la opción SUBDIRes configurada a yes) con el nombre del link simbólico.

12.6.15 Archivado y Recuperación de Directorios

El backup y archivado del cliente soporta archivado y recuperación de direc-torios. Los directorios con las listas de control de acceso asociadas (ACL) oderechos de accesos son archivados cuando los archivos son archivados y sonrecuperados cuando los archivos son recuperados.

12.6.16 Archivo y Recuperación de Directorios

Las opciones de línea de comandos son proporcionadas para soportar el archi-vado y recuperación de directorios.

DIRSONLY

Cuando esta opción es especificada, sólo los directorios y sus atributos sonarchivados o recuperados.

FILESONLY

Cuando esta opción de línea de comandos es especificada, sólo los archivosy sus atributos son archivados o recuperados. Por defecto archiva o recuperatanto directorios como archivos.

Los directorios que son archivados usan la misma descripción de archivadoque los archivos con los cuales son archivados.

12.6.17 Línea de Comandos Retrieve

Se puede usar el comando RETRIEVE para recuperar archivos. Se debe indicarel archivo que se quiere recuperar y un destino, si no se indica un destino, losarchivos son recuperados a su ubicación original.

Sintaxis

• Source: Identifica la ruta y el nombre del archivo en el almacenamiento


TSM que se quiere recuperar. Usar comodines para especificar un grupode archivos o todos los archivos en un directorio.

• Destination: Identifica la ruta y nombres del archivo donde se quie-re colocar los archivos recuperados. Si no especifica un destino, TSMdevuelve los archivos a su ruta fuente original.

• Options: Usar la opción fromdate para configurar una fecha desde lacual se quiere buscar archivos resguardados. TSM no incluye archivosprocesados antes de esta fecha, aunque los directorios más viejos pudie-ran ser incluidos.

Opciones de Comando

Las siguientes opciones de comando están disponibles:

FROMTIME

TODATE

FROMDATE

TOTIME

FROMNODE

FROMOWNER

PICK

• FROMTIME: Usar la opción FROMTIME con el FROMDATE y/o laopción TOTIME para especificar el tiempo de comienzo o una ventanade tiempo.

• TODATE: Usar la opción TODATE para especificar la última fechade archivado de los archivos para ser listados. TSM no lista archivosarchivados después de la fecha especificada. Usar ésta opción con laopción FROMDATE para listar archivos archivados entre la fecha y elhasta el momento.


• TOTIME: Usar el TOTIME y el TODATE con el FROMTIME y elFROMDATE para solicitar una lista de los archivos que fueron archiva-dos dentro de una ventana de tiempo. Por ejemplo, se podría solicitarlos archivos que fueron archivados entre las 6:00 a.m. del 1 de junio del2002, y las 11:59 p.m. del 30 de junio del 2002.

• FROMNODE: Usar la opción FROMNODE para ver una lista de losnombres de espacio de archivo en otro nodo en cuyo nombre se puederestaurar o recuperar archivos.

• FROMOWNER: Usar la opción FROMOWNER para especificar un pro-pietario alternativo desde el cual restaurar archivos. El propietario debeconceder el acceso para usar los archivos.

• PICK: Usar la opción PICK para mostrar una lista de los archivos ar-chivados que cumplen la especificación de archivo que se ingresa. Desdela lista, se puede seleccionar las versiones a restaurar.

Parte III

Ejemplo Práctico yConclusiones

301

Capítulo 13

Aplicación en el EntornoTivoli Storage Manager

13.1 Introducción

Este capitulo muestra las tareas y acciones realizadas con TSM como desarrollodel trabajo final de aplicación [7].

13.2 Entornos de Administración

13.2.1 Consola Administrativa del Servidor del Tivoli StorageManager

En la fig. 13.1, de la pág. 304, se muestra el entorno gráfico de administracióndel Tivoli Storage Manager; desde la cual se puede acceder a la Línea deComandos, a la Administración Web y a los Recursos Administrados por TSM.

13.2.2 Interface Administrativa Web

En la fig. 13.2, de la pág. 305 se muestra la interface administrativa webiniciada desde la consola del TSM.

303

304 CAPÍTULO 13. ENTORNO TIVOLI STORAGE MANAGER

Figura 13.1: Consola Administrativa del Servidor TSM

13.2. ENTORNOS DE ADMINISTRACIÓN 305

Figura 13.2: Interface Administrativa Web


La interface administrativa web tambien se puede iniciar desde un nave-gador web, escribiendo la URL con el nombre del host, desde el cual se quiereacceder y el puerto 1580, (fig. 13.3, de la pág. 306 ).

Figura 13.3: Acceso a la Interface Web Desde un Navegador Web

Luego de escribir la URL en el navegador web, se deberá ingresar el nombrede usuario y la contraseña del administrador, (fig. 13.4, de la pág. 307).

Para que la interface web pase a un estado inactivo luego de un determinadotiempo sin uso, se debe ingresar el comando set webauthtimeout con algúnvalor razonable, (fig. 13.5, de la pág. 308).

13.2. ENTORNOS DE ADMINISTRACIÓN 307

Figura 13.4: Ingreso de Datos Para Acceder a la Administración Web


Figura 13.5: Comando set webauthtimeout

13.3. MANEJO DE LICENCIAS 309

13.3 Manejo de Licencias

13.3.1 Comando Query LICense

Para ver que licencias se estan manejando, ingresar el comando Query LICense

como lo muestra la fig. 13.6, de la pág. 309.

Figura 13.6: Comando Query LICense

En la fig. 13.7, de la pág. 310 se muestra el resultado arrojado por elcomando Query LIcense.


Figura 13.7: Resultado del Comando Query LICense

13.3. MANEJO DE LICENCIAS 311

13.3.2 Registración de un Archivo de Licencia

Para registrar un archivo de licencia, ingresar el comando register license

file(nombre del archivo), como lo muestra la fig. 13.8, de la pág. 311.Este comando arroja el resultado que se muestra en la fig. 13.9, de la pág.312.

Figura 13.8: Registrar un Archivo de Licencia


Figura 13.9: Resultado de la Registración de un Archivo de Licencia

13.4. DEFINICIÓN DE POOL DE ALMACENAMIENTO 313

13.4 Definición de Pool de Almacenamiento

13.4.1 Comando Query

Para ver la configuración de Pool de Almacenamiento, usar el comando Query

como se muestra en la fig. 13.10, de la pág. 313.

Figura 13.10: Comando Query

Tambien se puede navegar por la interface web, como lo muestra la fig.13.11 de la pág. 314, y desde aquí ver las configuraciones de pool de almace-namiento.


Figura 13.11: Configuración de Pool de Almacenamiento


13.4.2 Consultas Desde la Interface Web

Se puede realizar distintas consultas desde la interface web, como lo muestrala fig. 13.12, de la pág. 315.

Figura 13.12: Consultas Desde la Interface Web

13.4.3 Definición de Volumenes de Backup

Para definir un volumen de backup, se lo puede hacer desde la línea de co-mandos de la consola del TSM, especificando la unidad de almacenamiento,como lo muestra la fig. 13.13, de la pág. 316.


Figura 13.13: Definición de Volumenes de Backup


13.4.4 Comando q stg

Para consultar los volúmenes creados se utiliza el comando q stg, como semuestra en la fig. 13.14, de la pág. 317, el cual arroja el resultado que semuestra en la fig. 13.15, de la pág. 318.

Figura 13.14: Comando q stg

13.4.5 Manejo de Estados de los Volúmenes de Pool de Alma-cenamiento

Se puede definir distintos estados de acceso a los volúmenes de pool de alma-cenamiento.

Acceso de Sólo Lectura


Figura 13.15: Resultado del Comando q stg


La fig. 13.16, de la pág. 319 muestra un ejemplo del comando para definirun acceso de sólo lectura en un pool de almacenamiento.

Figura 13.16: Acceso de Sólo Lectura

Acceso Completo a un Volumen del Pool de Almacenamiento

En la fig. 13.17, de la pág. 320 se muestra como definir un acceso completoal volumen DISK2.DSM del pool de almacenamiento.

13.4.6 Eliminación de Volúmenes

En la fig. 13.18, de la pág. 321 se muestra como eliminar el volumen DISK3.DSMdel pool de almacenamiento de archivado.


Figura 13.17: Acceso Completo a un Pool de Almacenamiento


Para consultar si el volumen fue eliminado se utiliza en comando , comolo muestra la fig. 13.19, de la pág. 322.

Figura 13.18: Eliminación de un volumen

13.4.7 Utilización del Comando QUERY VOLUME

Para ver todos los espacios definidos, como lo muestra la fig. 13.20, de la pág.323 se utilizó el comando QUERY VOLUME.


Figura 13.19: Verificar si el Volumen Fue Eliminado


Figura 13.20: Comando QUERY VOLUME


13.5 Políticas

13.5.1 Definición de un Dominio de Políticas Para Windows

Se puede definir distintos dominios de políticas, acorde a un criterio. La fig.13.21, de la pág. 324 muestra la definición de un dominio de políticas paraWindows.

Figura 13.21: Definición de un Dominio de Políticas

13.5.2 Definición de un Conjunto de Políticas

En la fig. 13.22, de la pág. 325 se muestra la definición de un conjunto depolíticas, desde la línea de comandos de la consola TSM.

13.5. POLÍTICAS 325

Figura 13.22: Definición de un Conjunto de Políticas


13.5.3 Definición de una Clase Administradora

La fig. 13.23, de la pág. 326 muestra la definición de una clase administradoradesde la línea de comandos de la consola del TSM.

Figura 13.23: Definición de una Clase Administradora

Tambien es posible definir una clase administradora desde la interface web,la fig. 13.24, de la pág. 327 muestra un ejemplo.

13.5.4 Activación de un Conjunto de Políticas

La fig. 13.25, de la pág. 328 muestra un ejemplo de la activación de unconjunto de políticas.

13.5. POLÍTICAS 327

Figura 13.24: Definición de una Clase Administradora Desde la Interface Web.


Figura 13.25: Activación de un Conjunto de Políticas

13.6. ADMINISTRADORES 329

13.6 Administradores

13.6.1 Registración de Administradores

La registración de administradores desde la interface web es una tarea muysencilla,la fig. 13.26, de la pág. 329 muestra un ejemplo.

Se puede crear administradores con distintas clases de privilegios, como lomuestra la fig. 13.27, de la pág. 330.

Figura 13.26: Registración de Administradores


Figura 13.27: Registración de Administradores

13.7. LISTAR LOS DETALLES DEL SERVIDOR 331

13.6.2 Consulta de Administradores Registrados

La fig. 13.28, de la pág. 331 muestra como consultar los administradoresregistrados desde la consola TSM.

La fig. 13.29, de la pág. 332 muestra como consultar los administradoresregistrados desde la caja de comandos de la interface web.

Figura 13.28: Consulta de Administradores

13.7 Listar los Detalles del Servidor

En la fig. 13.30, de la pág. 333 y el la fig. 13.30, de la pág. 334 se muestraun listado con todos los detalles delservidor TSM.


Figura 13.29: Consultar Administradores Registrados

13.7. LISTAR LOS DETALLES DEL SERVIDOR 333

Figura 13.30: Listado del Detalle del Servidor


Figura 13.31: Listado de los Detalles del Servidor

13.8. 335

13.8

13.8.1 Vista de la Configuración de la Base de Datos y del Logde Recuperación

La fig. 13.32, de la pág. 335 muestra como ingresar a través de la líneade comamandos para ver la configuración de la base de datos y del log derecuperación que se muestra en la fig. 13.33, de la pág. 336.

Figura 13.32: Vista de la Configuración de la Base de Datos y del Log deRecuperación

La misma información se puede obtener tambien desde la línea de coman-dos de la consola del TSM, como lo muestra la fig. 13.34, de la pág. 337 y lafig. 13.35, de la pág. 338.


Figura 13.33: Vista de la Configuración de la Base de Datos y del Log deRecuperación

13.8. 337

Figura 13.34: Vista de la Configuración de la Base de Datos


Figura 13.35: Vista de la Configuración del Log de Recuperación

13.9. ESPEJADO 339

13.8.2 Incremento del Tamaño de la Base de Datos

La fig. 13.36, de la pág. 339 muestra como se incrementa el tamaño de la basede datos agregando volúmenes.

Figura 13.36: Incremento del Tamaño de la Base de Datos

13.9 Espejado

Definir Volumen de la Base de Datos Espejada

La fig. 13.37, de la pág. 340 muestra un ejmplo de como se define un volumenespejado de la base de datos a través de la consola del TSM.


Figura 13.37: Definir un Volumen Espejado de la Base de Datos

13.10. NODOS 341

13.10 Nodos

13.10.1 Consulta de Nodos Registrados

En la fig. 13.38, de la pág. 341 se muestra el comando para consultar losnodos que estan registrados desde la línes de comandos y en la fig. 13.39, dela pág. 342 se muesta como consultar los nodos registrados desde la interfaceadministrativa web.

Figura 13.38: Consulta de Nodos Registrados

13.10.2 Registración de Nodos

En la fig. 13.40, de la pág. 343 se muestra como registrar un nodo desde lainterface administrativa web, y en la fig. 13.41, de la pág. 344 se muestracomo registrarlo desde la línea de comandos.


Figura 13.39: Consulta de Nodos Registrados

13.10. NODOS 343

Figura 13.40: Registrar Nodo


Figura 13.41: Registrar Nodo

13.11. BACKUP 345

13.11 Backup

13.11.1 Interface Gráfica de Usuario

La fig. 13.42, de la pág 345 muestra la interface gáfica de usuario para larealización de backup y archivado.

Figura 13.42: Interface Gráfica de Usuario

13.11.2 Backup Incremental (Complete)

La fig. 13.43 de la pág. 346 muestra un ejemplo de como realizar un backupincremental completo desde la interface gráfica de usuario.

Luego seleccionar la opción incremental desde el drop-down de la pantallaque se muestra en la fig. 13.44 de la pág. 347; una vez hecho esto selecciono


Figura 13.43: Backup Incremental Completo

13.11. BACKUP 347

el archivo crítico a resguardar, como lo muestra la fig. 13.45 de la pág. 348.


Seleccionar el ítem y luego presionar la opción Backup, como lo muestrala fig. 13.46 de la pág. 349, se tiene que observar la pantalla que se muestraen la fig. 13.47 de la pág. 350.

13.11.3 Backup Selectivo

La fig. 13.48 de la pág. 351 y la fig. 13.49 de la pág. 352 muestra como hacerun backup selectiv utilizando la función find.


Figura 13.45: Bachup Incremental Completo

13.11. BACKUP 349

Figura 13.46: backup Incremental Completo.



13.11. BACKUP 351

Figura 13.48: Backup Selectivo


Figura 13.49: Backup Selectivo

13.12. APLICACIÓN WEB 353

13.12 Aplicación Web

La fig. 13.50 de la pág. 353 muestra la aplicación web en su entorno de diseñoy desarrollo.

Figura 13.50: Aplicación Web

13.12.1 Aplicación Web Desde el Navegador

La fig. 13.51 de la pag. 354 y la fig. 13.52 de la pág. 355 muestran laaplicación web ejecutándose desde el navegador web.



13.12. APLICACIÓN WEB 355


Capítulo 14

Conclusiones

Se cumplió con los objetivos establecidos en la planificación del desrrollo deltrabajo final.

Se observó la flexibilidad de las tareas de backup, restauración y gestióndel TSM a través de la web.

Se observó la alta capacidad automática de gestionar y controlar los re-cursos de almacenamientos y la destinación de los datos en los medios dealmacenamiento.

Se observó la posibilidad de elegir distintos tipos de backup ofrecidos porel TSM de acuerdo a las necesidades actuales.

Se observó la alta integridad y complejidad de Sofware.

14.1 Líneas Futuras

Implementar un entorno Server TSM con un sistema operativo Linux.

357

Bibliografía

[1] L. Joyanes Aguilar. Cibersociedad. Mac Graw-Hill, 1997.

[2] L. Joyanes Aguilar. La Carrera Mundial por el Conocimiento. Una VisiónDesde la Nueva Economía. Universidad Pontificia de Salamanca, Madrid-España, 2000.

[3] Bart Jacob Carla Sadtler, John Ganci. WebSphere Product Family Over-view and Architecture. IBM Press, USA, 2004.

[4] E. Castillo; M. Reyes Ruiz Cobo. Preparación de Documentos con Latex.Maestría en Informática y Computación - FACENA - UNNE, Argentina,1998.

[5] IBM Corporation. IBM DB2 Connect Enterprise Edition para OS/02 yWindows Guía Rápida de Iniciación.

[6] IBM Corporation. IBM DB2 Universal Database para Windows GuíaRápida de Iniciación Versión 7. IBM Press, USA, 2000.

[7] IBM Corporation. IBM Tivoli Storage Manager 5.2 Implementation -Student’s Exercise Guide for Windows. IBM Press, USA, 2004.

[8] IBM Corporation. IBM Tivoli Storage Manager 5.2 Implementation -Student’s Training Guide. IBM Press, USA, 2004.

[9] IBM. IBM DB2 Warehouse Manager Guía de Instalación Versión 7. IBMPress, USA, 2001.

[10] Sun Microsystems. The Java Language version 1.1.4.http://java.sun.com, 1998.

[11] Rudyanto Linngar Saida Davies, Surech Amujuri. WebSphere BusinessIntegration Pub/Sub Solutions. IBM Press, USA, 2004.

359

360 BIBLIOGRAFÍA

[12] E. Castillo; A. Cobo; P. Gómez; C. Solares. JAVA - Un Lenguaje deProgramación Multiplataforma para Internet. Paraninfo, España, 1997.

[13] H. Zorrilla. La Gerencia del Conocimiento y la Gestión Tecnológica. 2000.

Índice de Materias

acceso a otro nodo, 219ACL, 297activación de un conjunto de políti-

cas, 326actualización del grupo de produc-

tos Tivoli Storage Manager,50

actualizacion y preguntas en los po-ols de almacenamiento, 155

tilde nas, 221administracion basada en politicas,

116administracion de aplicaciones de e-

business, 67administracion de aplicaciones de e-

business utilizando tivoli, 77administracion de cambios, 70administracion de capacidad, 69administracion de configuracion, 70administracion de costos, 69administracion de la disponibilidad,

69administracion de niveles de servi-

cio, 68administracion de problemas, 70administracion de reportes, 95administracion del funcionamiento,

83administracion del rendimiento, 84administracion del Storage Mana-

gement Archive File, 181

administrador de nodo, 188administradores, 114, 329agregar espacio, 207almacenamiento y gestion de datos,

121anular opciones de configuración, 229aplicación en el entorno tivoli sto-

rage manager, 303aplicación web, 353aplicación web desde el navegador,

353archivado y recuperación, 273archivado y recuperación de direc-

torios, 297archivar archivos, 273archivar y recuperar usando la GUI,

273archive, 118archivo de backup cliente, 116archivo v2, 276archivo y recuperación de directo-

rios, 297archivos de certificado de inscrip-

cion, 135archivos de licencias, 134arquitectura de infraestructuras de

aplicaciones de e-business,71

arquitectura del tivoli enterprise da-ta warehouse, 41

361

362 ÍNDICE DE MATERIAS

arquitectura y procesos del data wa-rehouse, 17

asignació de espacio, 202auditar una libreria, 149automatizacion de las operaciones,

129autoridad administrativa, 181

background, 48backup, 118, 345backup basado en Journal

backup, 56backup de directorios excluidos, 244backup de imagen (Windows 2000

y XP), 257backup de imagen fotográfica, 256backup de imagen incremental (sólo

fecha), 258backup incremental (complete), 345backup incremental (sin journal), 254backup incremental por fechas, 252backup incremental y basado en jour-

nal, 251backup selectivo, 347backups y restauración con la línea

de comandos, 279base de datos del Storage Manager,

116base de datos y log de recuperación,

197, 335bases de datos operacionales, 6bases de datos operacionales versus

informativas, 10BI, 3, 4

Business Intelligence, 3binding and rebinding, 177

cómo se organiza el tivoli enterprisedata warehouse, 40

cached y archivos del pool de alma-cenamiento de copia

cached, 205caching del pool de disco, 206tilde na, 219capacidades de automatizacion pro-

porcionadas por el Tivoli Sto-rage Manager, 120

capacidades de gestion del adminis-trador, 118

caracteristicas del ODS, 24cartuchos de cintas, 144clase administradora rebinding, 178clases administradoras, 177clases de dispositivos, 152clases de privilegios, 181client acceptor daemon y scheduler

service, 57colocacion, 166comando mttest, 144comando q stg, 317comando Query, 313comando Query LICense, 309comando recall, 194comando UPDATE LIBVOLUME,

146comandos de restauración reinicia-

ble, 291comandos del Utilities Menu, 219como utilizar los patrones para el

e-business, 108competitividad, 4componentes basicos instalados, 132componentes de tivoli enterprise wa-

rehouse, 37conclusiones, 357tilde na, 223configuración del acceso del cliente

al servidor, 227

ÍNDICE DE MATERIAS 363

configuración del archivo de opcio-nes, 225

configuración del cliente, 215configuracion de la interfaz admi-

nistrativa webinterfaz administrativa web, 195

configuracion del cliente, 129configuraiones de politias por defec-

to, 173configurar el modelo de libreria, 142configurar las opciones de logging,

231conjunto de opciones cliente, 236conjunto de politicas, 175conocimiento, 4consola administrativa del servidor

del TSM, 303consulta de administradores regis-

trados, 331consulta de nodos registrados, 341consultar, eliminar o actualizar un

conjunto de opciones del clien-te, 246

consultas desde la interface web, 315control de acceso administrativo, 221control y distribucion del software,

70crear volúmenes adicionales, 207

data mart, 7, 25data mart sencillo, 14data mining, 11data warehouse, 5, 7Data Warehouse Manager, 3data wareusing, 19datos de OLTP en servidores sepa-

rados, 12DB2 data warehouse manager, 28DB2 datawarehouse, 37

definición de pool de almacenamien-to, 313

definición de un conjunto de políti-cas, 324

definición de un dominio de políti-cas para Windows, 324

definición de una clase administra-dora, 326

definición de volumenes de backup,315

definicion de las politicas del TivoliStorage Manager, 128

definicion de los pools de almacena-miento, 155

definicion de un nuevo conjunto depoliticas, 175

definicion de volumenes de pool dealmacenamiento, 155

definir el volúmen, 207definir opciones incluyen - excluyen,

238definir politicas, 171definir volumen de la base de datos

espejada, 339desbordamiento de los pools de al-

macenamiento, 157descripción del archivado, 275descripción del restore, 267descripcion de politica de adminis-

tracion, 170descripcion del Tivoli Enterprise Da-

ta Warehouse, 95descripcion del Tivoli Storage Ma-

nager, 113descripcion del tivoli storage mana-

ger, 47descripciones del archivo, 275descubrimiento de los recursos del

servidor web, 92


descubrimiento de los recursos delWebSphere, 92

descubrimiento de recursos, 92destinacion de almacenamiento, 154diferencias entre scratch y privados,

146dimensionamiento de la B.D y del

log, 204DISK, 152dominio de politicas, 123dominios de politicas, 171drill-down, 9

editor gráfico de opciones, 226ejemplos de backup selectivos, 282ejemplos de mirroring, 210eliminación de volúmenes, 319eliminar datos archivados, 220eliminar filespace, 220eliminar pools y volumenes de al-

macenamiento, 156encriptación, 58Enterprise Data Warehouse, 3entornos de administración, 303entrega de servicios, 68escripción de archivado, 273espacio de la B.D y del log de recu-

peración, 203espacios triggers, 212especificacion de la clase adminis-

tradora, 178espejado, 339estimación de requerimientos de es-

pacio, 204tilde no del log, 207estrategia basada en politicas pa-

ra la administracion de losdatos

estrategia basada en politicas,123

estructura compleja de capas de ser-vicios, 62

estructura del producto tivoli, 79etiquetar volumenes

Labeling Wizard, 146excluir directorios de backup, 242tilde nas, 221extender el volúmen, 207extracción-propagación, 18

flujo de eventos del Tivoli BusinessSystem, 88

fuente de datos operacionalesODS, 24

fuentes de datos, 18fuentes externas de datos, 8función file details, 263funcionalidad backup-restore propor-

cionada por el Tivoli Sto-rage Manager, 117

funciones de backup y archivado delcliente, 249

generalidades, 105grupo de politicas, 123grupos de copia, 179

herramientas de presentación y análi-sis, 26

identificar archivos a ser incluidoso excluido desde el backup,240

identificar el valor del conjunto deopciones del cliente, 236

identificar los tipos de clientes, 215identificar preferencia de opciones,

229impedir a los nodos clientes el ac-

ceso al servidor, 223


implementacion del tivoli storage ma-nager, 113

implementaciones del B.I., 11tilde no de la base de datos, 339información de metadatos

metadatos, 23inspector de eventos, 191instalación distribuida, 42instalación distribuida con los agen-

tes remotos del warehouse,45

instalación en una sola máquina, 42instalacion de la linea de comandos,

139instalacion del servidor y de clien-

tes del Tivoli Storage Ma-nager, 127

instalacion del servidor, cliente y dis-positivos de almacenamien-to, 130

instalacion del Tivoli Storage Ma-nager, 130

instalacion del Tivoli Storage Ma-nager Server, 130

instalacion en Windows, 130instalacion y configuracion de una

libreria de cinta, 139integracion de la configuracion del

Tivoli Business Systems Ma-nager, 90

inteligencia de negocios, 4interfáz GUI, 219interface administrativa web, 190,

303interface de línea de comando, 215interface gráfica de usuario, 345interface web del cliente, 218interfaces de los clientes, 215introducción, 37, 303

introducción, 47, 61, 87, 95, 169,197

introduccion a los patrones para ele-business, 105

IT, 5

jerarquias de pool de almacenamien-to, 150

línea de comandos de archivado yrecuperación, 295

línea de comandos retrieve, 297líneas futuras, 357lbtest, 144libreria de cintas, 116licencia, 125licencia del Tivoli Storage Mana-

ger, 125linea de comando, 190lista de acceso a nodo, 219listar los detalles del servidor, 331logging de monitoreo y eventos, 129LVSA, 258

mado normal, 200Management Class, 123manejo de datos, 129, 169Manejo de estados de los volúmenes

de pool de almacenamien-to, 317

manejo de la infraestructura del e-business, 61

manejo de licencias, 309manejo de volumenes y medios del

pool de almacenamiento, 128marco de detalle, 190mejoramiento del TSM del cliente

TSM del cliente, 56mejoras del LAN-free

LAN-free, 51mejoras del servidor TSM, 58


mesa de ayuda, 70metadata, 9metadatos, 16migracion, 161mirroring, 208modelo 3494, 55modelo de activos evaluados de pa-

trones para e-business, 107modelo físico de la base de datos,

21modelo lógico de la base de datos,

22modificar las opciones de backup,

265modificar opciones de archivado, 276modificar opciones de restauración,

269modo roll-forward, 202modos de recuperación del log de

transacción, 200monitoreo del proceso de flujo de

datos, 101mostrar versiones activas e inacti-

vas de un archivo para res-taurar, 271

mover datos, 158movimiento automatico de datos, 159

nivel back-end, 72nivel de aplicacion, 71nodos, 341

objetos del sistema, 57OLAP, 8OLTP, 12opción domain, 229opciones de recuperación - modifi-

car las opciones de recupe-ración y de colisión, 279

opciones del cliente, 225

opciones del cliente y del servidordel TSM, 234

opciones disponibles del cliente pa-ra configurar y proporcio-nar rendimiento, 230

operaciones, 84

packs de lenguaje, 136paquetes de archivado, 276paquetes warehouse, 41parámetros BUFPOOLSIZE y LOG-

POOLSIZE, 211patrones de aplicacion, 106patrones de tiempo de ejecucion, 107patrones para el e-business, 105patrones para el sitio web del e-business,

108periodos de retencion de gracia, 173personalización de la B.D y del log

de recuperación del S.M, 197PIT, 272planificacion para emergencias, 69planificador

scheduler, 114políticas, 324politica por defeto, 173politicas de administracion, 169politicas de negocio manejadas cen-

tralmente, 169pool de almacenamiento de copia,

206pools de almacenamiento, 116, 150pregunta diskInfo, 220prerequisitos, 131privilegio de analyst, 188privilegio de operator, 187privilegio policy, 186privilegio storage, 184privilegio system, 181


procesamiento continuado del incluir- excluir, 240

procesamiento incluir - excluir, 240procesamiento transaccional en línea

OLTP, 7proceso analítico en línea

OLAP, 7proceso MOVE NODEDATA, 159productos basicos usados para faci-

litar aplicaciones de e-business,73

propósito de la base de datos y dellog, 197

proteccion de la base de datos, 130proteger datos con el Tivoli Storage

Manager, 113provision de almacenamiento median-

te la Funcion archive-retrieve,118

punto de consistencia, 202

rastreo de base de datos, 157realización de backups del cliente,

259realizar backup incremental de sólo

un directorio especificado,283

realizar un backup incremental conla línea de comandos, 279

reclamacion, 164recuperación usando la GUI, 278recuperar paquetes de archivado usan-

do la GUI del cliente, 279reducir espacio, 208refinación de los datos, 19registración, 221registración de administradores, 329registración de nodos, 341registración de un archivo de licen-

cia, 311

registrar y consultar licencias, 135registro de recuperacion del Storage

Manager, 116rendimiento y opciones del cliente,

230restauración a un punto en el tiem-

po, 272restauraciones relanzables, 272restaurar a una nueva posición usan-

do la opción de restaura-ción PRESERVEPATH, 290

restaurar archivos, 267restaurar archivos resguardados usan-

do el comando de restaura-ción dsmc, 284

restaurar archivos usando la GUI,268

restaurar una versión específica deun archivo, 269

restore, 118, 267, 286restringido, 185resultados de la revisión del bac-

kup, 261resultados de un filtro, 262retrieve, 118

SAN, 48SANergy, 53seleccion de patrones y mapeo de

productos, 110seleccionar archivos y realizar un bac-

kup, 259seleccionar siempre backup como ti-

po de backup, 265sentencia EXCLUDE.DIR, 242servidor OLAP, 9setup wizard, 220siempre backup (selectivo) de bac-

kup, 256sin restriccion, 184


sobrecarga, 206soluciones importantes del Tivoli Sto-

rage Manager 5.2., 114soporte de servicio, 70star-join, 22storage area network, 51Storage Manager Server, 114supervision en tiempo real, 87

Términos Principales del B.I, 6tabla resumen, 12TDS, 31TEDW conceptos y componentes,

97tipos de backups disponibles, 249tipos de backups disponibles desde

la GUI, 249tipos de interfaces administrativas,

190tipos de medios de almacenamien-

to, 121Tivoli

introducción, 3Tivoli Decission Support, 30Tivoli Enterprise Data Warehouse,

3tivoli enterprise data warehouse, 29,

40tivoli monitoring for web infrastruc-

ture, 82Tivoli Storage Manager for Appli-

cation Servers, 124Tivoli Storage Manager for Databa-

ses, 123Tivoli Storage Manager for Hard-

ware, 124Tivoli Storage Manager for Mail, 124Tivoli Storage Manager for Space

Management, 124

Tivoli Storage Manager for StorageArea Networks, 124

Tivoli Storage Manager para pro-ductos de proteccion de da-tos, 123

trabajar con medios, 144transacciones, 199transferencia LAN-free

LAN-free, 50transformación-depuración, 18TSM, 261, 268, 294, 295tsmdlst, 144TXNGROUPMAX, 231

unicas descripciones de archivo, 276unicode habilitado del espacio del

archivo del cliente, 59uso de la función de estimación, 265uso de la función find, 261uso de la opción FORCE, 239uso de la opción LATEST con el co-

mando dsmc restore, 286uso de números de sequencias en un

conjunto de opciones, 244uso del backup - archive de la GUI

del TSM, 259uso del comando de restauración dsmc

con la opción PICK, 286uso del comando Query Filespace,

283uso del IFNEWER con el comando

dsmc restore, 291utilización de la línea de comandos

para el backup y el archi-vado, 279

utilización de las opciones PITDA-TE y PITTIME, 291

utilización del comando dsmc resto-re con superposición, 286


utilización del comando QUERY VO-LUME, 321

utilización del loop, 218utilizacion del License Wizard, 134utilizacion del Tivoli Business Sys-

tems Manager, 87, 93

validar y activar un conjunto de po-liticas, 176

ventajas de usar el Tivoli Enterpri-se Data Warehouse, 33

ver información de política, 220vista de la configuración de la base

de datos y del log de recu-peración, 335

volumenes de configuracion, 129volumenes de pool de almacenamien-

to, 150

zona desmilitarizada, 71

Date post:	16-Jan-2016
Category:	Documents
Upload:	demetrio-villanazul-gerardo
View:	47 times
Download:	0 times

Manual Tivoli Manager_5.2

Documents