Estudio y propuesta de un servidor espejo redundante utilizando sofware libre para la PUCE-SD by Pontificia Universidad Católica del Ecuador sede Santo Domingo PUCE SD

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO Dirección Académica - Escuela de Sistemas

ESTUDIO

PROPUESTA

SERVIDOR

ESPEJO

REDUNDANTE UTILIZANDO SOFTWARE LIBRE Y BASE DE DATOS

ORACLE

PARA

PONTIFICIA

UNIVERSIDAD

CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO.

Disertación de Grado Previo la obtención del título de Ingenieros de Sistemas y Computación

Línea de investigación: Estudio de Mercado

Autores: PAÚL ALEXANDER PABÓN LÓPEZ DENNYS LEONARDO PEÑALOZA PURUNCAJAS Directora: Ing. MARGARETH VIVIANA HURTADO QUIROZ

Santo Domingo- Ecuador Enero, 2015

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO Dirección Académica - Escuela de Sistemas

HOJA DE APROBACIÓN ESTUDIO

PROPUESTA

SERVIDOR

ESPEJO

REDUNDANTE UTILIZANDO SOFTWARE LIBRE Y BASE DE DATOS

ORACLE

PARA

PONTIFICIA

UNIVERSIDAD

CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO. Línea de investigación: Estudio de Mercado

Autores: PAÚL ALEXANDER PABÓN LÓPEZ DENNYS LEONARDO PEÑALOZA PURUNCAJAS

Ing. MargarethViviana Hurtado Quiroz DIRECTORA DE LA DISERTACIÓN DE GRADO

Fausto Ernesto Orozco Iguasnia, Ing. CALIFICADOR

Rodolfo Sirilo Córdova Galvez, Mg. CALIFICADOR

Rodolfo Sirilo Córdova Galvez, Mg. DIRECTOR DE LA ESCUELA DE SISTEMAS

Enero, 2015

iii

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD

Paúl Alexander Pabón López portador de la cédula de ciudadanía No. 171724390-9 y Dennys Leonardo Peñaloza Puruncajas portador de la cédula de ciudadanía No. 171756194-6, declaramos que los resultados obtenidos de la investigación que presentamos como informe final, previo a la obtención del Grado de Ingenieros en Sistemas y Computación son absolutamente originales, auténticos y personales. En tal virtud, declaramos que el contenido, las conclusiones y los efectos legales y académicos que se desprenden del trabajo propuesto de investigación y luego de la redacción de este documento son y serán de nuestra sola y exclusiva responsabilidad legal y académica.

________________________ Paúl Alexander Pabón López C. I.: 171724390-9

_________________________ Dennys Leonardo Peñaloza P. C. I.: 171756194-6

DEDICATORIA

A mi madre: por ser dedicada y entregarme los mejores años de su vida. Eres un ejemplo de mujer y una madre excepcional, gracias por el apoyo que me brindas cada día y por acompañarme siempre. A mi padre: por haberme apoyado en la realización de este documento y por ser mi ejemplo a seguir. Gracias por haberme dado la oportunidad de llegar hasta donde estoy y por formarme lo suficientemente bien como para saber; Que el viaje más largo comienza con el primer paso. A mi familia: Por ser mi apoyo todos los días, enseñándome a compartir y a comprender el valor de la vida. Gracias por acompañarme en los momentos más importantes. A mi hermano: Por estar conmigo en cada momento y por el apoyo que me ha brindado. A mis amigos, compañeros y catedráticos: Por haberme enseñado a tener perseverancia y alcanzar mis metas. Por último, pero no por eso menos importante, a Dios por permitirme cerrar este ciclo de mi vida. Paúl

DEDICATORIA

El presente trabajo de investigación va dedicado en primer lugar a Dios, por darme la sabiduría y paciencia necesaria para su culminación. A mi hermosa familia, que fue el pilar esencial en mi educación. A mi esposa, por su apoyo constante y a mis hijos por ser mi mayor motivación para culminar mi carrera. A todos mis profesores en el trayecto de mi carrera que fueron mis guías frecuentes que con sus conocimientos y enseñanzas dieron respuestas a mis dudas y ayudaron en mi enriquecimiento intelectual; y, a todas las personas que de una u otra forma aportaron con un granito de arena para llegar a finalizar mi carrera. A esta noble institución, la “Pontificia Universidad Católica del Ecuador Sede Santo Domingo” por acogerme y darme la facilidad de ser un integrante más de la gran familia PUCE SD. En especial, se lo dedico a los alumnos de esta noble institución, quienes podrán aprovechar los conocimientos que se han plasmado en este trabajo; para que les sirva de guía y sepan que con perseverancia y constancia se llega a finalizar una meta.

Dennys

AGRADECIMIENTOS

El momento es propicio para rendirle las muestras de nuestra más alta y distinguida consideración, gratitud, aprecio y personal estima: A Dios, por permitirnos alcanzar nuestras metas estando con nosotros en cada paso que damos y, por fortalecer nuestro corazón e iluminar nuestra mente y habernos puesto en nuestro camino a aquellas personas que han sido soporte y compañía durante todo el periodo de estudio. A todos los profesores de la carrera de Ingeniería en Sistemas, por sus cátedras enriquecedoras e iluminadoras, asistencia y ánimo, los cuales fueron una fuente de inspiración y fortaleza para nosotros. Así que es preciso reconocer la transmisión de sus conocimientos y experiencias, los cuales nos condujeron hasta este momento de la vida. A nuestra Directora de Disertación, Ing. Margareth Hurtado Quiroz; por sus ideas, guía y todo el tiempo dedicado con nuestra persona para poder completar este documento. Un agradecimiento especial a todas las personas que cooperaron de una manera directa o indirecta con la elaboración de este proyecto. Paúl y Dennys

vii

RESUMEN

Primeramente se hace referencia a las bases teóricas que sustentan cada una de las actividades realizadas en el estudio y propuesta de un servidor espejo redundante utilizando software libre y base de datos Oracle para la Pontificia Universidad Católica del Ecuador Sede Santo Domingo, tomando como referencia varios autores. Posteriormente se detalla la metodología que se utilizó para obtener información tanto a nivel de campo como teórico y las diversas técnicas de recolección de datos. Y en el desarrollo de la propuesta se especifica el proceso del análisis y diagnostico de diferentes soluciones técnicas; siendo el Espejo Redundante con Scripts factible en lo técnico, operativo y económico. Es así, que en la presente investigación que es el estudio y propuesta de un servidor espejo redundante utilizando software libre y base de datos Oracle, la cual se acopla muy bien en infraestructuras existentes en la Pontificia Universidad Católica del Ecuador Sede Santo Domingo; esta se presenta como una de las aplicaciones más poderosas, que brindan niveles de seguridad periódica y un manejo ininterrumpido de información. Finalmente, se especifica las conclusiones y recomendaciones.

viii

ABSTRACT First of all, the present project makes reference to the theoretical bases that supports each one of the activities carried out in this study and proposal of a redundant mirror server using free software and Oracle database for Pontificia Universidad Cat贸lica del Ecuador sede Santo Domingo, taking as refernce several authors.

Subsequently, it is detailed the methodology which was used to get information as field as theoretical level and a variety of techniques for data collection.

In the progress of a proposal, the process of analysis and diagnostic of different technical solutions is specified; being the redundant mirror with Scripts technical, operational and economic feasibly.

Therefore, in the current research that is the study and the proposal of a redundant mirror server using free software and Oracle database, which fits very well in existing infraestructures at the Pontificia Universidad Cat贸lica del Ecuador sede Santo Domingo; this is showed as one of the most powerful applications that offer periodic security and uninterrupted handling of information. Finally, conclusions and recommendations are specified.

ÍNDICE DE CONTENIDOS

Portada……… ............................................................................................................. i Hoja de aprobación ..................................................................................................... ii Declaración de autenticidad y responsabilidad .......................................................... iii Dedicatoria……. ........................................................................................................ iv Agradecimiento ........................................................................................................... v Resumen…….. ......................................................................................................... vii Abstract………. ....................................................................................................... viii Índice de contenidos ................................................................................................... ix Índice de figuras ....................................................................................................... xiv Índice de tablas ........................................................................................................ xvii 1

INTRODUCCIÓN ...................................................................................... 1

PLANTEAMIENTO DEL PROBLEMA ................................................... 2

2.1.

Antecedentes ............................................................................................... 2

2.2.

OBJETIVO GENERAL ............................................................................. 3

2.2.1.

Objetivo General......................................................................................... 3

2.2.2.

Objetivos Específicos ................................................................................. 3

MARCO TEÓRICO ................................................................................... 4

3.1.

ALTA DISPONIBILIDAD ........................................................................ 4

3.1.1.

Introducción ................................................................................................ 4

3.1.2.

Definición de disponibilidad ...................................................................... 5

3.1.3.

Gestiones en la disponibilidad .................................................................... 5

3.1.4.

Planificación de la capacidad ..................................................................... 8

3.1.5.

Análisis de los Requerimientos de Alta Disponibilidad ............................. 9

3.1.6.

Análisisdel Recovery Time Objective (RTO) .......................................... 23

3.1.7.

Análisisdel Recovery Point Objective (RPO) .......................................... 24

3.2.

ARQUITECTURA DE ALTO NIVEL .................................................... 25

3.2.1.

Introducción .............................................................................................. 25

3.2.2.

Proceso de Definición ............................................................................... 26

3.2.3.

Confirmación de los Objetivos del Negocio ............................................ 27

3.2.4.

Arquitectura Oracle de base de datos de alta disponibilidad .................... 30

3.2.5.

Prácticas de alta disponibilidad ................................................................ 35

3.3.

SOFTWARE LIBRE ................................................................................ 36

3.3.1.

Definición ................................................................................................. 36

3.3.2.

Transmisión del significado por el nombre .............................................. 38

3.3.3.

Ventajas del software libre frente al open source. .................................... 38

3.3.4.

Relación entre el movimiento del software libre y el de open source ...... 39

3.3.5.

Formas de promoción del software libre .................................................. 39

3.3.6.

Documentación libre para el software libre .............................................. 40

3.3.7.

Licencia Pública General GNU ................................................................ 40

METODOLOGÍA ..................................................................................... 42

4.1.

ANÁLISIS METODOLÓGICO ............................................................... 42

4.1.1.

INTRODUCCIÓN .................................................................................... 42

4.1.2.

TIPO DE INVESTIGACIÓN ................................................................... 43

4.1.3.

MÉTODOS DE INVESTIGACIÓN ........................................................ 43

4.1.4.

TÉCNICAS DE RECOLECCIÓN DE DATOS ....................................... 44

4.1.5.

TÉCNICAS DE ANÁLISIS DE LA INFORMACIÓN ........................... 44

4.1.6.

PROCESAMIENTO DE LA INFORMACIÓN ....................................... 45

4.1.7.

ANÁLISIS TÉCNICO .............................................................................. 45

PROPUESTA ........................................................................................... 52

5.1.

ANÁLISIS Y DIAGNÓSTICO DE DIFERENTES SOLUCIONES Y TÉCNICAS ............................................................................................... 52

xii

5.1.1.

Vistas Materializadas ................................................................................ 53

5.1.2.

SharePlex .................................................................................................. 57

5.1.3.

Data Guard de Oracle ............................................................................... 67

5.1.4.

Replicación con Oracle Streams ............................................................... 75

5.1.5.

Oracle Golden Gate .................................................................................. 79

5.1.6.

Espejo Redundante con Scripts ................................................................ 84

5.1.7.

Análisis Comparativo de Factibilidad ...................................................... 87

5.2.

REQUISITOS PARA LA IMPLEMENTACIÓN DE UN SERVIDOR ESPEJO REDUNDANTE ........................................................................ 91

5.3.

Desarrollo de la Propuesta ........................................................................ 91

5.3.1.

Diseño ....................................................................................................... 91

5.3.2.

Implementación ........................................................................................ 93

5.3.3.

Guía de instalación de Oracle 10 g sobre Centos 5.5 ............................... 95

5.3.4.

Ajustando límites del Kernel .................................................................... 97

5.3.5.

Directorios y permisos .............................................................................. 99

5.3.6.

Pantallas .................................................................................................. 103

5.3.7.

Configurando archivo hosts .................................................................... 111

xiii

5.3.8.

Configuración de Scripts para intercambio de archives usando Rsyng.. 122

5.3.9.

Configurando crontab nodo primario ..................................................... 122

5.3.10.

Configurando script.sh nodo secundario ................................................ 123

5.3.11.

Configurando crontab nodo secundario para script.sh ........................... 125

CONCLUSIONES Y RECOMENDACIONES ...................................................... 128 REFERENCIAS ...................................................................................................... 130 GLOSARIO DE TÉRMINOS ................................................................................. 133

xiv

ÍNDICE DE FIGURAS

Figura 1. Descripción de la Planificación e implementación de una empresa de alta disponibilidad. ............................................................................................................ 12 Figura 2. Causas de las caídas no planeadas de los sistemas. .................................... 16 Figura 3. Causas de las caídas planeadas de los sistemas. ......................................... 17 Figura 4. Porcentaje de cada tipo de caída de los sistemas en dos diferentes escenarios ................................................................................................................... 18 Figura 5. Soluciones de Oracle a caídas planeadas y no planeadas de los sistemas a nivel de base de datos. ................................................................................................ 20 Figura 6. Jerarquía de las arquitecturas de alta disponibilidad. ................................. 33 Figura 7. Descripción de Vistas Materializadas. ........................................................ 54 Figura 8. Logotipo de SharePlex. ............................................................................... 58 Figura 9. Descripción de SharePlex para Oracle. ...................................................... 60 Figura 10. Configuración de SharePlex para Oracle. ................................................. 61 Figura 11. Arquitectura de Oracle Data Guard. ......................................................... 69 Figura 12. Arquitectura de Oracle Streams. ............................................................... 76

Figura 13. Arquitectura de Oracle Golden Gates. ...................................................... 80 Figura 14. Bienvenido. ............................................................................................. 103 Figura 15. Directorio y Credenciales. ...................................................................... 104 Figura 16. Seleccionar tipo de instalación. .............................................................. 104 Figura 17. Comprobantes de requisitos específicos del producto. ........................... 105 Figura 18. Configuración. ........................................................................................ 105 Figura 19. Selección de configuración. .................................................................... 106 Figura 20. Especificación de opciones de configuración. ........................................ 106 Figura 21. Instalar. ................................................................................................... 107 Figura 22. Opciones de almacenamiento. ................................................................ 107 Figura 23. Opciones de copia de seguridad y recuperación. .................................... 108 Figura 24. Especificar contraseñas de esquema de base de datos. ........................... 108 Figura 25. Resumen. ................................................................................................ 109 Figura 26. Asistentes de configuración. ................................................................... 109 Figura 27. Asistente de configuración de base de datos 01. .................................... 110 Figura 28. Asistente de configuración de base de datos 02. .................................... 110 Figura 29. Ejecutar archivos de comandos de configuración. ................................. 110

xvi

Figura 30. Fin de instalaci贸n. ................................................................................... 111 Figura 31. Salir. ........................................................................................................ 111 Figura 32. Root@primario: 01. ................................................................................ 111 Figura 33. Root@primario:.02. ................................................................................ 112 Figura 34. Root@primario: 03. ................................................................................ 112 Figura 35. Ethernet Device. ..................................................................................... 115 Figura 36. Network configuraci贸n. .......................................................................... 116 Figura 37. Oracle@primario: 01. ............................................................................. 125 Figura 38. Oracle@primario: 02. ............................................................................. 126 Figura 39. Oracle@primario: 03. ............................................................................. 126 Figura 40. Oracle@secundario: 01........................................................................... 126 Figura 41. Oracle@secundario: 02........................................................................... 127

xvii

ÍNDICE DE TABLAS Tabla 1. Niveles de disponibilidad de los sistemas de información en una organización. ................................................................................................................ 9 Tabla 2. Ganancias perdidas por hora de acuerdo al sector de la industria al que pertenece la empresa. ................................................................................................. 22 Tabla 3. Arquitectura Oracle de base de datos de alta disponibilidad. ...................... 30 Tabla 4. Capacidades adicionales de Alto Nivel arquitecturas de alta disponibilidad Oracle. ........................................................................................................................ 34 Tabla 5. Tiempos de recuperación alcanzables para interrupciones no planificadas. 34 Tabla 6. Tiempos de recuperación alcanzables para interrupciones planificadas. ..... 35 Tabla 7. Recursos técnicos para el análisis de factibilidad. ....................................... 56 Tabla 8. Recursos. ...................................................................................................... 57 Tabla 9. Recursos técnicos para el análisis de factibilidad. ....................................... 65 Tabla 10. Recursos. .................................................................................................... 66 Tabla 11. Recursos técnicos para el análisis de factibilidad. ..................................... 73 Tabla 12. Recursos. .................................................................................................... 74

xviii

Tabla 13. Recursos técnicos para el análisis de factibilidad. ..................................... 78 Tabla 14. Recursos. .................................................................................................... 79 Tabla 15. Recursos técnicos para el análisis de factibilidad. ..................................... 82 Tabla 16. Recursos. .................................................................................................... 83 Tabla 17. Recursos técnicos para el análisis de factibilidad. ..................................... 86 Tabla 18. Recursos. .................................................................................................... 87 Tabla 19. Matriz Comparativo de las Factibilidades. ................................................ 89 Tabla 20. Matriz Comparativa de Respuesta para Interrupciones no Planificadas. ... 89 Tabla 21. Matriz Comparativa de Respuesta para Interrupciones Planificadas. ........ 89 Tabla 22. Cuadro Comparativo. ................................................................................. 90 Tabla 23. Información del nodo primario. ................................................................. 94 Tabla 24. Tipos de nodos y herramientas utilizadas. ................................................. 95 Tabla 25. Espacio recomendado en disco. ................................................................. 97

I INTRODUCCIÓN Este proyecto es enfocado como solución de seguridad frente a posibles fallos del hardware y software del servidor principal. Toda organización debe tener un respaldo de seguridad para salvaguardar la información en su sistema informático ya que pueden producirse fallos de hardware y software en su servidor principal, más aún en una institución como la PUCE-SD, para lo cual se apoya en Software de libre distribución y herramientas GPL.

Para conseguir una alta disponibilidad en el servidor se utilizará como base de datos Oracle 10g con un sistema operativo Linux en la versión Centos 5.5. La metodología empleada para la ejecución del estudio y análisis de las distintas alternativas existentes para el servidor espejo redundante utilizando un software libre y base de datos Oracle para la PUCE-SD.

Las conclusiones y recomendaciones exhiben los beneficios del proyecto si se decidiera aplicar la propuesta de este servidor en la PUCE Sede Santo Domingo.

II PLANTEAMIENTO DEL PROBLEMA

2.1.

Antecedentes

La PUCE SD trabaja con Oracle 10 g como base de datos y Windows 2003 server como sistema operativo y un servidor IBM. Es indudable la fortaleza de la plataforma Oracle como base de datos ya que por sí sola maneja un sin número de opciones tanto para los DBA (administradores de base de datos), programadores como para los usuarios finales. Para evitar algún error se hace necesario mantener un soporte en el caso de suceder posibles fallos ocasionados por circunstancias externas como cortes de luz, desconexión de las estaciones de trabajo o falla del hardware como el daño de una fuente de poder o un disco duro. En el mercado existe una gran cantidad de servidores que son altamente redundantes. Estos son grandes equipos multiprocesadores con varios controladores duplicados como fuentes de poder altamente redundantes, controladores de discos y tarjetas Raid, para que en caso de fallo siempre exista una disponible. El precio de estas máquinas es muy alto y cuando uno de estos equipos quede obsoleto no hay otro remedio que comprar otro. Es por ello que una de las posibles soluciones está en obtener redundancia y alta disponibilidad con equipos normales, y usando programas de libre distribución como el sistema operativo Centos 5.5 y las herramientas de la base de datos Oracle con sus 2

componentes como RMAN.

2.2.

OBJETIVO GENERAL

2.2.1. Objetivo General Diseñar un servidor espejo redundante utilizando software libre y base de datos Oracle para la Pontificia Universidad Católica del Ecuador sede Santo Domingo.

2.2.2. Objetivos Específicos 

Analizar las diferentes soluciones y técnicas de redundancia utilizando software libre y base de datos Oracle para la Pontificia Universidad Católica del Ecuador sede Santo Domingo.



Determinar la mejor solución en base a su factibilidad técnica, operativa y económica, para el manejo de redundancia para un servidor en la Pontificia Universidad Católica del Ecuador sede Santo Domingo.



Proponer y describir la solución de recuperación de fallas para los servidores de la Pontificia Universidad Católica del Ecuador sede Santo Domingo.

III MARCO TEÓRICO 3.1.

ALTA DISPONIBILIDAD

3.1.1. Introducción La necesidad de operaciones que trabajen en un esquema de funcionamiento ininterrumpido las 24 horas y 7 días a la semana (esquema 24x7) han incrementado la competitividad de las organizaciones y la precisión que estos ejercen para que exista una continua disponibilidad de las soluciones de misión crítica.(Se considera como una aplicación de misión crítica a sistemas bancarios, sistemas de facturación en general con énfasis en empresas de servicios como las de telecomunicaciones, tiendas virtuales, sistemas de consulta y pago de línea a través de internet, reservas de líneas aéreas, sistemas de envío y rastreo de paquetes, etc. por mencionar algunos ejemplos, se considera como aplicación de misión crítica a toda aquella cuya parada implique pérdidas financieras y problemas para la organización). Para gran variedad de negocios, aunque se produzcan pequeñas interrupciones, sean estas, desde minutos hasta horas, en que las aplicaciones vitales, proveedores o aliados de negocio clave están fuera de servicio pueden traer serias consecuencias como resultado. Aún en ambientes donde la contínua disponibilidad no es obligatoria o frecuente, o en algunos casos en que se ocasiona la caída de los sistemas de más de una o dos horas no pueden ser toleradas. Como resultado, es preciso contar con una

arquitectura de alta disponibilidad que establezca los requerimientos básicos de implementación, configuración e integración de las mejores prácticas para prevenir, detectar y reparar las caídas planeadas y no planeadas en la organización, debido al alto costo que estas representan. 3.1.2. Definición de disponibilidad La disponibilidad es la característica, cualidad o condición de la información de encontrarse a disposición de quienes deben acceder a ella, ya sean personas, procesos o aplicaciones. A groso modo, la disponibilidad es el acceso a la información y a los sistemas por personas autorizadas en el momento que así lo requieran.(GÓMEZ, 2011) 3.1.3. Gestiones en la disponibilidad

3.1.3.1. Gestión de disponibilidad Las arquitecturas altamente disponibles continúan proveyendo servicios aún durante actividades de mantenimiento, por lo que para una gestión de disponibilidad adecuada se hace necesario recolectar información relacionada con el rendimiento de los sistemas, así como también monitorear los parámetros de configuración de las aplicaciones con la finalidad de prevenir y evitar potenciales caídas. Para llevar a cabo esto, es preciso emplear herramientas de gestión especializadas y calendarizar trabajos automáticos que permitan reducir los errores de los operadores en base a acuerdos de nivel de servicio pre-establecidos, de tal manera que se pueda mejorar la disponibilidad de las aplicaciones Batch (Una aplicación Batch o por lotes es aquella que está integrada por múltiples archivos Batch, esto es, archivos o scripts

que contienen una serie de comandos e instrucciones que tienen la característica de ser ejecutados con frecuencia en una organización muchas veces, con la finalidad de realizar carga masiva de información sobre la base de datos, razón por la cual este tipo de aplicaciones son útiles ya que permite evitar el ingreso de comandos e instrucciones de manera individual y manual por parte de los operadores o administradores de los sistemas) y de datos. 3.1.3.1.1. Gestión de recuperabilidad La gestión de recuperabilidad está orientada a la realización de un análisis de las causas que generan fallas en los sistemas de información, esto, con la finalidad de resolver, identificar y prevenir problemas rápidamente. El proceso de análisis tendría que involucrar para cada uno de los problemas: su identificación, clasificación y asignación de un nivel de severidad acorde a los riesgos y el impacto potencial que represente para el negocio, adicionalmente, se debe diseñar un documento que contenga las características de los problemas que pudieran presentarse y el procedimiento de resolución asociado. Finalmente, para asegurar el menor impacto en la organización es necesario manejar un esquema de nivel de prioridad para la resolución de tareas y llevar a cabo procesos de monitoreo con la finalidad de mantener un esquema de prevención y sobre todo un esquema de recuperación que satisfaga el tiempo promedio establecido por la organización. 3.1.3.1.2. Gestión de confiabilidad Las arquitecturas altamente disponibles raramente fallan, por lo que es crítico para su

implementación contar con componentes confiables a nivel de Hardware y Software de forma permanente. 3.1.3.1.3. Gestión del cambio El manejo del cambio en una organización, permite mejorar la calidad del servicio de la implementación de un mecanismo de planeación, pruebas, coordinación y calendarización de los cambios que se vayan a realizar a nivel de aplicaciones e infraestructuras en la misma.Esto es importante, debido a que el cambio es uno de los principales generadores de fallas humanas y de procesos. Las organizaciones que tienen claramente definidas prácticas para la gestión del cambio experimentan altos tipos de disponibilidad. 3.1.3.1.4. Gestión de configuración La gestión de configuración ayuda a comprender la relación entre la infraestructura de tecnología de información, aplicaciones y componentes de los procesos de negocio, así como también el nivel de impacto y la prioridad en la resolución de los problemas ocasionados por las caídas de los sistemas. 3.1.3.1.5. Gestión de computadoras de escritorio La gestión de computadoras de escritorio permite asegurar la confiabilidad de la configuración de software requerida para el acceso de los usuarios a los servicios de las aplicaciones de misión crítica. 3.1.3.1.6. Gestión de rendimiento La gestión de rendimiento está orientada a que se pueda diagnosticar rápidamente

problemas y reducir las caídas de los sistemas, a través de los sistemas de respuesta a nivel de toda la infraestructura tecnológica. 3.1.3.1.7. Gestión de almacenamiento La gestión de almacenamiento se encuentra orientada a garantizar la alta disponibilidad de la información mediante la utilización de procesos proactivos para evitar incidentes catastróficos o permitir la recuperación de caídas de los sistemas tan rápido como sea posible. 3.1.4. Planificación de la capacidad La planificación de la capacidad se basa en datos históricos y de carga de trabajo con la finalidad de prever la infraestructura tecnológica que se necesitará a futuro con el propósito de evitar caídas inesperadas de los sistemas.Los puntos mencionados anteriormente permiten que las organizaciones vengan a tomar conciencia de que la importancia de la alta disponibilidad generalmente varía de hecho de aplicación a aplicación. La necesidad de proporcionar niveles elevados de disponibilidad ha incrementado conforme las organizaciones hacen una reingeniería de sus soluciones para ganar ventaja competitiva en el mercado. Cuando la información no puede ser accedida se puede tener paralización de las operaciones, pérdida de productividad, de ganancias, de clientes, de reputación, problemas judiciales, etc. Las organizaciones no pueden ofrecer consistentes niveles de confiabilidad sin una administración madura de los procesos de información, mediante la investigación de dichos procesos se puede mitigar la exposición al riesgo que generan las caídas planeadas y no planeadas de los sistemas.

3.1.5. Análisis de los Requerimientos de Alta Disponibilidad Se debe tomar en consideración que el diseño e implementación de una estrategia de alta disponibilidad es costoso y complejo, por lo que es necesario que en la organización se determine el grado de disponibilidad requerido para los sistemas en funcionamiento, tomando en cuenta los costos asociados con las caídas de los sistemas y los beneficios que altos niveles de disponibilidad brindan al lograr un incremento en el tiempo promedio entre fallas (Mean Time BetweenFaitlures, MTBF). Tabla 1. Niveles de disponibilidad de los sistemas de información en una organización.

UNPLANNEDDOWNTIME TYPICAL (missioncritical) UP TIME Worsethanaverage 98% Average

HOURS DOWN PRODUCTIVITY DOWNTIME PER YEAR COST* RISK 174,72 $ 42.000 $ 7.338.240

99%

87,36

$ 42.000

$ 3.669.120

Butter the average

99,50%

43,63

$ 42.000

$ 1.832.460

Good

99,90%

8,736

$ 42.000

$ 366.912

99,999%

0,09

$ 42.000

$ 3.780

Best in class

Fuente: Source: Benchmarking Uptime for Your Business: Methodology and Best Practices, 2007. http://www.force10networks.com/whitepapers/pdf/BenchmarkingUptime.pdf

Adicionalmente, es necesario que las organizaciones tomen en cuenta que la implementación de la estrategia escogida puede resultar en la ejecución de tareas críticas como las que se cita a continuación, para lo cual es necesario realizar un análisis del impacto que se produciría en el negocio y llevar a cabo un adecuado manejo del proceso de cambio en la organización a todo nivel: 

Eliminación de los sistemas de legacy



Inversión en sistemas más sofisticados y robustos.



Rediseño completo de la arquitectura de la tecnología de información con la finalidad de que esta se adapte al nuevo modelo.



Rediseño de los procesos del negocio.



Contratación y entrenamiento de personal.



Contratación de outsoursing para la administración de la nueva arquitectura escogida.

Para determinar los requerimientos de alta disponibilidad el primer paso es realizar un análisis de la organización, el cual permita determinar: áreas y procesos críticos de la organización, principales competidores, influencia del área de tecnología, entre otros aspectos importantes los mismos que habiliten conocer detalladamente en qué procesos se requiere de un mecanismo de alta disponibilidad que garantice el acceso a la información en un esquema que involucre el funcionamiento 24 horas por 7 días a la semana. Para esto se puede utilizar el cuestionario que se muestra en el Anexo No. 1: Cuestionario del Análisis de la Organización. Una vez que se tiene una visión de a donde está orientada una organización y cuáles son los procesos críticos, se puede iniciar un estudio orientado a determinar qué proyectos de tecnología en el área de alta disponibilidad pueden implementarse en base a las necesidades y prioridades que tenga internamente la Compañía, para esto, Oracle

Corporation

publicación

High

AvalavilityArchitecture

and

BestPractices de diciembre de 2003, propone un framework de análisis que cuenta con los siguientes elementos (CORPORACIÓN ORACLE, 2011): 

Análisis de impacto en el negocio.



Análisis del costo de caída de los sistemas.



Análisis del RTO: Recovery Time Objective.



Análisisdel RPO: Recovery Point Objective.

3.1.5.1.

Análisis de impacto en el negocio

Es una técnica que permite identificar las pérdidas tangibles e intangibles que son generadas por las caídas planeadas y no planeadas de los sistemas de información, esto permite disminuir el riesgo de sobre-inversión en recursos destinados a operaciones de contingencia y prevención de catástrofes.Este debe cumplir con tres objetivos básicos: 

Definir el valor de cada unidad o recurso organizacional y su relación con la función de toda la organización.



Suministrar las bases para identificar los recursos críticos y funciones requeridas para el desarrollo de estrategias de recuperación.



Determinar el orden y prioridad de restauración de las funciones críticas ante fallas y desastres.

Se debe considerar en este tipo de sistemas varios factores como: funciones esenciales del negocio, recursos del sistema, personal, dependencias internas y externas del negocio, regulaciones gubernamentales, etc., con el propósito de proveer la información necesaria para generar una estrategia de recuperación en la cual se evalúan prioridades y ventanas de tiempo y se categorizan los procesos fundamentándose en el nivel de severidad asociado con las caídas del sistema, identificar qué y quiénes son vitales para cada uno de los procesos y estimar los

potenciales costos directos e indirectos que generaría la caída de los sistemas.

Figura 1. Descripción de la Planificación e implementación de una empresa de alta disponibilidad. Elaborado por: http://docs.oracle.com/cd/B19306_01/server. 102/b14210/architect ures.htm

Es preciso tomar en cuenta para realizar el nivel de impacto en el negocio los siguientes aspectos: 

Establecer las áreas de la organización con mayor nivel de riesgo, para ello se debe identificar limitaciones en el tiempo de recuperación, puntos de falla dentro de la infraestructura, etc.



Para cada área de la organización, es preciso definir los procesos del negocio involucrados y fijar los principales atributos que permitan reconocerlos, así como los principales requerimientos para su correcto funcionamiento, haciendo

énfasis en aquellos procesos considerados como esenciales, para lo cual se debe identificar las aplicaciones críticas las cuales pueden estar enmarcadas en el área de servicio del cliente externo, esto es, sistemas de administración de relación con los clientes (Customer Relationship Management, CRM) como: ventas, marketing y servicios; sistemas de administración de la cadena de manejo de proveedores (SupplyChain Management, SCM), como: procesamiento de órdenes, pedidos, planificación, compras, manufactura, distribución; por otro lado se puede realizar un análisis de las aplicaciones enmarcadas en el área de servicio al cliente interno como: sistemas de administración de los recursos de la organización (Enterprise ResoursePlanning, ERP), como: contratos, proyectos, recursos humanos, finanzas, mantenimiento; servicios de colaboración como: sitios de internet, correo electrónico, manejo de archivos, etc.



Para cada uno de los procesos del negocio se debe estimar los costos tangibles e intangibles que generan las caídas de los sistemas: ¿Cuál es el costo de no realizar el proceso? ¿Cuál es el costo de retrasar el proceso? ¿Cuál es el máximo período de tiempo que el proceso puede ser detenido?

Se presenta el Anexo No. 2: “Cuestionario de Análisis de Impacto del Negocio” como ejemplo a tomar como base y adaptarlo a las necesidades de la organización. Este debe aplicarse solamente para aquellos procesos considerados críticos, los que se determinan en base a la información recolectada después de aplicar el cuestionario del Anexo No. 1.

3.1.5.1.1. Análisis de costos para el negocio La utilización de Internet como el mayor canal de distribución en la actualidad y la integración de la tecnología en los procesos de negocio dentro de las organizaciones, implica que sea necesario operar en una economía altamente compleja, lo cual se ve reflejado en la susceptibilidad de las empresas a las interrupciones, sean estas de carácter directo o indirecto, por ejemplo, en las torres gemelas de New York, o el edificio Windsor en el complejo Azca de Madrid. En ambos caso hubo empresas que no sobrevivieron a la perdida de datos. Sin embargo empresas como Deloitte, con un plan de continuidad de negocio, estuvieron operativas al 100% en menos de 72 horas. (TAMINUT, 2010)

No es sencillo determinar los costos directos relacionados con las caídas de los sistemas, en función de que hay una gran cantidad de costos que no pueden ser medidos financieramente, a esto, se suma la dificultad que tiene el departamento de sistemas en la solicitud de recursos para la implementación de un plan de recuperación ante desastres, considerando que la realización de las pruebas respectivas puede ser una tarea complicada. A continuación se analizan los pasos que deben ser considerados para conocer los costos, para lo cual es preciso realizar este análisis, dentro del cual se debe considerar la caída del sistema y servicios dentro de la organización, los cuales fueron propuestos en un artículo de Kevin Roden en Computerworld de abril de 2004 previo al de impacto en el negocio puesto que muchas de las respuestas se desprenderán de dicho estudio (RODEN, 2004):



Identificación de los componentes del negocio en los cuales se pondrá foco.



Definición de qué se está protegiendo.



Priorización de las funciones del negocio.



Clasificación y valoración de los tipos de caídas de los sistemas.

3.1.5.1.2. Identificación de los componentes del negocio en los cuales se pondrá el foco Con respecto a la identificación de los componentes del negocio en los cuales se pondrá el foco, hay cuatro que son básicos en un plan de disponibilidad: 

Personas.



Propiedades.



Sistemas.



Información.

3.1.5.1.3. Definición de qué se está protegiendo Identificar la base de competencia de la organización y los elementos de tecnología de información que deben ser protegidos para soportar esa base, que es el corazón de lo que el negocio hace y es su ventaja competitiva en el mercado. 3.1.5.1.4. Priorización de las funciones del negocio Es necesario poner prioridad a las funciones que soportan la base de competencia de una organización, ya que según el estudio de Kevin Roden en Iron Mountain Inc., se

gasta el 80% de los recursos disponibles en la recuperación del 20% de los sistemas, aplicaciones y datos. De igual manera, el identificó tres tipos de sistemas que estarían enmarcados dentro de ese 20% mencionado anteriormente: los sistemas de operación primaria de la compañía, el hardware y software utilizado por los clientes internos para la consulta de información y finalmente el sistema de correo electrónico. 3.1.5.1.5. Clasificación y valoración de los tipos de caídas de los sistemas Los eventos no planeados se detallan en el siguiente gráfico:

CAÍDAS NO PLANEADAS

FALLAS DE SOFTWARE

FALLAS DE HARDWARE

ERRORES HUMANOS

DESASTRES

Sistema Operativo

Errores de Operadores

Fuego

Base de Datos

CPU

Errores de Usuarios

Inundaciones

Middleware

Memoria

Aplicaciones

Fuente de poder

Administrador de la Base de Datos

Fallas de Suministro Eléctrico

Red

Bus del sistema

Administrador del Sistema

Terremotos

Perifericos

Fallas de Operadores

Ataques Terroristas

Discos Unidades de cinta

Sabotajes

Controladores

Red

Fallas de poder

Figura 2. Causas de las caídas no planeadas de los sistemas. Elaborado por: Dennys Peñaloza y Paúl Pabón

Lograr altos niveles de disponibilidad implica también reducción en la complejidad de la recuperación, de tal manera que el acceso a las aplicaciones después de un

desastre sea rápido y eficiente, por esto, uno de los principales retos en el diseño de soluciones altamente disponibles es examinar todas las causas posibles para las caídas de los sistemas, las cuales pueden ser de dos tipos principalmente: planeadas y no planeadas. Los eventos planeados por el contrario involucran operaciones de rutina, mantenimiento periódico y actualizaciones. En este caso es indispensable diseñar un sistema que permita minimizar las caídas planeadas.

Caídas Planeadas

Operaciones de rutina

Mantenimiento periódico

Actualizaciones

Base de Datos

Administración de Base de datos

Hardware

Recuperación y respaldo

Gestión de almacenamiento

Gestión de rendimiento

Parámetros de inicialización

Gestión de seguridad

Actualización de Software

Aplicaciones

Administración de Aplicaciones

Procesamiento de Trabajos de Butch

Gestión de esquema Actualización de Software

Sistema Operativo

Base de datos

Middleware

Aplicaciones

Red

Sistema Operativo

Middleware

Aplicaciones

Red

Figura 3. Causas de las caídas planeadas de los sistemas. Elaborado por: Dennys Peñaloza y Paúl Pabón

Una vez que se han clasificado los tipos de caídas del sistema, es necesario identificar el o los problemas que se presentan con mayor frecuencia en la organización, con la finalidad de determinar las causas que los originaron y

mitigarlas, para el efecto, existen muchos estudios en el mercado que nos permiten centrarnos en los problemas más comunes y considerados como generales a nivel de todo tipo de organización. A continuación se muestra un estudio en el que se presenta el porcentaje de fallas humanas, de hardware, software y de aplicaciones en dos diferentes escenarios: La red de telefonía pública de Estados Unidos (U.S. PublicSwitchedTelephone Network, PSTN) y los tres diferentes sitios de internet.

Figura 4. Porcentaje de cada tipo de caída de los sistemas en dos diferentes escenarios Fuente: Vissión Solutions. “The One Essential Guide to Disaster Recovery: How to Ensure IT and Business Continuity”. 27 de mayo de 2010. < http://www.idgconnect.c omview_abstract/9101/the-one-essential-guide-disasterrecovery-how-ensure-it-bu sin ess-continuity >.

El estudio realizado hace énfasis en que las fallas humanas son la principal causa de las caídas de los sistemas, lo cual hace pensar que las organizaciones no han procurado el desarrollo de sistemas fáciles de operar. Gartner Research en uno de sus análisis corrobora esto, manifestando que el 80% de las caídas de aplicaciones de misión crítica son directamente causadas por personas o fallas en los procesos y el otro 20% es causado por fallas ambientales, de tecnología o desastres. (NAVARRO, 2009)

Oracle provee soluciones para los diferentes tipos de caídas de sistemas especificados anteriormente. El siguiente cuadro, el cual ha sido desarrollado en base a la información que se presenta en la publicación Oracle Database 10g ProductFamily de enero de 2004 (ORACLE CORPORATION, 2011), se concentra en brindar soluciones a los principales problemas reportados en el análisis User managed Backup and Recovery Issue Analysis Report. La información mencionadas se obtuvo en base a una entrevista realizada a un técnico del Área de Soporte Técnico de Oracle Corporation, el cual permitió la publicación únicamente de los datos mencionados de Diciembre de 2001 el cual se basó en la revisión de 761 TARs (TechnicalAssitantRequests) (Un TAR es un requerimiento de soporte levantado por un cliente de Oracle ante la presencia de un problema el cual requiere de ayuda especializada para ser resuelto. Dicho requerimiento puede ser levantado vía telefónica o a través del Centro de Soporte Técnico en Internet en la página http://metalink.oracle.com) enmarcados en el área de recuperación. Este reporte mostró, que en el caso de los clientes de Oracle a nivel mundial 46% de los problemas reportados eran debido a fallas de datos y/o corrupciones generadas por fallas a nivel de hardware y/o software, 32% de los problemas se debían a errores de los usuarios, como por ejemplo: borrado accidental de archivos de datos o tablas, y finalmente, el 22% de los problemas requirió asistencia especial del grupo de soporte de Oracle Corporation para que pueda ser resuelto.

Caídas No Planeadas

Fallas del Sistema

Real Application Clusters (RAC), Automatic Storage Management (ASM),

Desastres y Fallas de datos

Data Guard, Recovery Manager (RMAN), ASM Cero pérdidas de datos

Errores Humanos

Flashback Tecnology, Log Miner, Data Grand Corrección de los errores de los usuarios

Mantenimiento del Sistema

Reconfiguración Dinámica, Data Guard, RAC, ASM Capacidad bajo demanda sin interrupción

Mantenimiento de Datos

Redefinición en Línea, Particionamiento de Tablas e Índices, Parallel SQL, ASM

Alta disponibilidad para todas las aplicaciones

Caídas Planeadas Adaptación a los cambios en líneas

Figura 5. Soluciones de Oracle a caídas planeadas y no planeadas de los sistemas a nivel de base de datos. Elaborado por: Dennys Peñaloza y Paúl Pabón

Una vez realizada la clasificación de los tipos de caídas de los sistemas, a continuación es necesario efectuar el cálculo de su costo, incluyendo las pérdidas potenciales de dinero en que incurren las organizaciones, reducción de productividad de los empleados, pérdida de reputación a nivel de clientes y de mercado en general. La pérdida monetaria puede calcularse utilizando la siguiente fórmula:

Pérdida Monetaria = Frecuencia (número de caídas) x Duración (horas) x Costo hora Basándose en lo anterior, se asume por ejemplo que dentro de una organización se tiene un aproximado de 45 caídas al año con un promedio de duración de 1 hora a un costo de $200 por hora podemos deducir que la pérdida es $9.000 al año.

A continuación, se detalla la fórmula que permite determinar el costo estimado promedio de una hora de caída de los sistemas debido a que el promedio de ingresos por hora puede verse afectado por valores extremos, se debe considerar realizar su cálculo entre dos desviaciones estándar.

Costo Estimado Promedio por una hora de caída = (Costo por hora de los empleados x Fracción de tiempo que duró la caída) + (Promedio de ingresos por hora x Fracción de tiempo que duró la caída)

La fórmula anterior permite llegar a la conclusión que dependiendo del tipo de organización una hora de caída del sistema no necesariamente genera una pérdida en los ingresos, lo cual se debe a que los empleados pudieron haber realizado otras actividades durante la caída del sistema, de tal manera que no se puede cuantificar como significativo el costo del tiempo perdido. A esto, hay que sumarle el hecho que la fórmula propuesta no toma en cuenta algunos otros aspectos como los costos de reparación de servicios de recuperación, la información perdida de reemplazo de infraestructura, variaciones de los ingresos, etc., por considerar que la variación que genera en la aplicación de la fórmula es mínima para la mayor parte de las organizaciones. Seguidamente, se presenta una tabla en la que se ha segmentado el estudio de los costos de las caídas de los sistemas para diferentes industrias que trabajan en línea y cuyas operaciones se ven interrumpidas cuando los sistemas están fuera de servicio.

Tabla 2. Ganancias perdidas por hora de acuerdo al sector de la industria al que pertenece la empresa.

TYPICAL HOURLY COST OF DOWNTIME BY INDUSTRY (in US Dollars) 6.48 millon Brokerage Service 2.8 millon Energy 2.0 millon Telecom 1.6 millon Manufacturing 1.1 millon Retail 636,000 Health Care 90,000 Media Elaborado por: Di Nunno, Donn. “Assessing the Financial Impact of Downtime Understand the factors that contribute to the cost of downtime and accurately calculate its total cost in your organization”. Vission Solutions. 2008: <http://www.strategiccompanies.com/pdfs/Assessing%20 the%20Financial%20Impact% 20of%20Downtime.pdf>

La siguiente tabla que se presenta, no muestra sin embargo los costos del tiempo que pierden los empleados de la organización a no poder acceder a los sistemas de información, por lo que es necesario tener en cuenta que el costo total de la caída es la suma de dicho costo con el que se producen por la falta de ingresos generada por la pérdidas de ventas. A continuación se detallan otras fórmulas útiles tomadas de un artículo publicado en Disaster Recovery Journal, las cuales pueden ser aplicadas a cualquier tipo de economía puesto que no involucran factores de cálculo específicos asociados a una región o país (HINTON & CLEMENT, 2002):

Pérdida Monetaria Bruta = Utilidad bruta x Porcentaje de clientes perdidos por la caída de los sistema

La fórmula anterior está orientada a organizaciones en que las aplicaciones son altamente transaccionales y consideran la pérdida de los clientes como primordial durante la caída de los sistemas.

Pérdida de Capacidad de Producción = Número de unidades no producidas x Precio por unidad La fórmula anterior está diseñada para empresas de manufactura, y permite determinar la pérdida de capacidad de producción debido a la caída de los sistemas.

Costo Total de Recuperación = Costo del tiempo perdida por los empleados + Costo de la información perdida + Costo de reemplazo de infraestructura + Costo de los servicios de recuperación

La fórmula anterior permite calcular el costo total de recuperación ante la caída de los sistemas, donde: Costo del tiempo perdido por los empleados = Tiempo promedio de recuperación x Salario promedio de los usuarios x Número de usuarios. Costo de la información perdida = (Utilidad bruta/Días laborables por año) x Porcentaje de información no recuperada. Con la finalidad de minimizar los riesgos que genera la interrupción de los sistemas en las organizaciones, una gran cantidad de compañías están incrementando sus inversiones y el costo en este tema. En una encuesta realizada por IDC (IDC es una compañía global de inteligencia de mercadeo y consultoría en las áreas de tecnología de información y telecomunicaciones). Ellos analizan y predicen las tendencias a nivel de tecnología, de tal manera que sus clientes puedan tomar decisiones estratégicas de negocio basadas en dichos estudios. 3.1.6. Análisisdel Recovery Time Objective (RTO) El Recovery Time Objective (RTO) se define como la máxima cantidad de tiempo

que un proceso de negocios basado en tecnología de información puede estar fuera de servicio antes de que la organización empiece a sufrir pérdidas significativas, es decir, es el grado de tolerancia ante la caída de los sistemas. Los requerimientos de RTO son proporcionales a la naturaleza de misión crítica de una organización, la cual a su vez puede tener un indicador para cada proceso, por ejemplo en la misma compañía el sitio web de manejo de compras tendrá un indicador igual a cero o próximo a este valor, mientras que para los sistemas de facturación o distribución su valor puede ser un poco más alto ya que el negocio puede funcionar sin un impacto visible significativo como ocurriría si el problema es a nivel de la tienda virtual. Un indicador que influye directamente sobre el RTO es el Network RecoveryObjective (NRO), el cual indica la cantidad máxima de tiempo que las operaciones de red como enlaces, ruteadores, balanceadores de carga, etc., pueden estar fuera de servicio. 3.1.7. Análisisdel Recovery Point Objective (RPO) El Recovery Point Objective se define como la máxima cantidad de datos que un proceso basado en tecnología de información puede perder debido a la caída de los sistemas. La pérdida de los datos que se menciona en el párrafo anterior se mide en términos de tiempo, por ejemplo, una empresa que posee una tienda virtual, que genera una gran cantidad de transacciones cada minuto, no puede perder la información, por lo que su RPO será 0.

3.2.

ARQUITECTURA DE ALTO NIVEL

3.2.1. Introducción La definición de una arquitectura de alta disponibilidad debe considerarse como un proceso que involucre desde el análisis de la organización a nivel de negocio hasta la generación de un plan de ejecución de las iniciativas generadas a nivel tecnológico. Este proceso tiene por objetivo final la definición de la arquitectura de alta disponibilidad que soporte las iniciativas de la organización a través de una solución tecnológica que puede ser puesta en producción en un intervalo de 90 a 120 días, debido a las rápidas transformaciones a nivel tecnológico así como también en los modelos de negocio que obligan a que se cuente con resultados a corto plazo. Previo a la fase de definición de la arquitectura es aconsejable que la organización realice un taller ejecutivo orientado a la generación de un documento que contenga los objetivos, iniciativas y requisitos de alto nivel del negocio, el cual debe estar acompañado por la presentación de una justificación económica que contenga el costo estimado de la implementación de las iniciativas identificadas, lo cual permitirá la priorización de actividades y verificación o asignación del presupuesto necesario. Este tipo de talleres ejecutivos muchas veces revela iniciativas adicionales y específicas cuyos requerimientos podrán ser solucionados a través de una iniciativa a nivel tecnológico. Los principales beneficios provenientes de llevar a cabo este proceso se los expone a continuación: 

El cliente toma conciencia de que toda iniciativa en el área de tecnología debe

estar soportada por objetivos de negocio y requisito de alto nivel, con la finalidad de que las implementaciones sean exitosas. 

Como resultado del proceso es posible contar con un mapa de la solución tecnológica que mejor se ajuste a los objetivos y visión de la organización.

3.2.2. Proceso de Definición Este Este proceso tiene por objetivo básico la definición y priorización de iniciativas de implementación en el área de alta disponibilidad que estén basadas en los objetivos de negocio del cliente con la finalidad de proporcionarle el mapa de la solución tecnológica que mejor se ajuste a sus necesidades. El proceso de definición puede ser ejecutado en un lapso de dos a ocho semanas de trabajo conjunto entre consultores especializados y equipo técnico y de negocios de la organización, los cuales tendrán que llevar a cabo las siguientes actividades: 

Revisar y confirmar los objetivos, iniciativas y requisitos de alto nivel del negocio a través de talleres ejecutivos.



Definir el mapa de la solución tecnológica a través de la generación de modelos de referencia a detalle e identificación de los componentes y productos necesarios para su implementación.



Definición del mapa de implementación de la arquitectura de alta disponibilidad que se haya propuesto.

La realización de estas actividades garantiza que el responsable del área de sistemas o empresa consultora encargada del proyecto puede justificarlo exitosamente, priorizar las iniciativas de implementación para que soporten los objetivos del

negocio y contar con un mapa tecnológico consistente con la visión y objetivos de la organización y que a su vez esté basado en modelos de referencia exitosos. Para utilizar el modelo se debe hacer un cronograma de tal forma que se pueda definir la Arquitectura de Alta Disponibilidad, el cual deberá expresarse en un resumen abreviado de los tiempos estimados para la implementación de cada una actividades planeadas anteriormente, dicho cronograma puede presentar variaciones dependiendo de la prioridad que la organización se asigne a este proceso y de la rapidez con que se pueda obtener la información que se solicite, sobre todo en la primera fase orientada a confirmar los objetivos, requisitos e iniciativas de alto nivel de la organización. 3.2.3. Confirmación de los Objetivos del Negocio La confirmación de los objetivos de negocio está enfocada en la realización de las siguientes actividades: 

Confirmación de los objetivos, iniciativas y requisitos de alto nivel del negocio.



Priorización de las iniciativas del negocio.



Generación de una lista MoSCow



Identificación del presupuesto para proyectos de tecnología de información.



Realización de análisis de calidad.

3.2.3.1.

Confirmación de los objetivos, iniciativas y requisitos de alto nivel del negocio

Esta actividad tiene como propósito la comprensión de los objetivos, iniciativas y

requisitos de alto nivel del negocio que serán la base para la definición y posterior implementación de la arquitectura de alta disponibilidad en la organización. El proceso está constituido por una o varias sesiones interactivas con una duración no mayor a 2 horas cada una, en la cual se ayuda al cliente a formar una tabla, tomando en cuenta las siguientes definiciones para cada uno de los componentes que serán ubicados dentro de las mismas: 

Objetivos de negocio: Es lo que el negocio desea alcanzar en los 12 a 24 meses próximos a su definición. El objetivo del negocio debe contar con factores mesurables de éxito, así, para la empresa de telefonía móvil XYZ uno de los objetivos de negocio puede ser: “Contar con 3 millones de clientes registrados en Enero de 2015”. En este caso el objetivo cuenta con una medida cuantificable que el número de clientes que tendrán registrados en una fecha específica.



Iniciativas de negocio: Las iniciativas son las acciones que la organización llevará a cabo para el cumplimiento de los objetivos propuestos. Por ejemplo, para el caso de la empresa XYZ una iniciativa válida es el lanzamiento de programas promocionales con la finalidad de captar una mayor cantidad de clientes.



Requisitos de alto nivel: Los requisitos de alto nivel dependen de las iniciativas de negocio que se hayan planteado, por ejemplo, si la iniciativa de negocio es el lanzamiento de programas promocionales, un requisito de alto nivel puede ser contar con tarifas telefónicas reducidas en relación a sus competidores.

En esta actividad la labor del consultor es muy importante puesto que el cliente pudo no haber realizado previamente un taller ejecutivo que le ayude en la generación de

un documento con los objetivos de negocio y es posible que no se tenga claro el concepto, así, para un ejecutivo de la empresa XYZ uno de los objetivos de negocio podría ser: “Implementar un esquema de clúster a nivel de base de datos”, en cuyo caso, el análisis debe ayudar a clarificar el concepto y ayudarle a encontrar que objetivo de negocio está conduciendo a la empresa a llevar a cabo la iniciativa de implementación de un clúster, el cual puede ser por ejemplo: “Contar con 2 millones de clientes registrados en Enero de 2015”, en este punto, es necesario cuantificar que no es labor del consultor en esta fase criticar el valor de las iniciativas que se planteen, pero sí, solicitar al cliente una justificación para cada una de ellas, y orientarlo para que trate de definir objetivos, iniciativas y requerimientos de alto nivel mesurables. Esta actividad no debe tomar más de 24 horas laborables, en las cuales se debe planificar las reuniones con el cliente y posteriormente generar la documentación correspondiente, la cual, en esta etapa es básicamente de referencia para el consultor. Se hace necesario por lo tanto, la realización de un esquema de trabajo que puede ser similar al que se detalla a continuación: 

Revisión con el cliente del material generado en el taller ejecutivo o previo a esta etapa, en caso de que este se hubiera realizado.



Revisión de los objetivos e iniciativas del negocio.



Revisión de los requisitos de alto nivel asociados con cada una de las iniciativas.



Generación de la documentación correspondiente.

Si el tiempo aconsejado es excedido se debe recomendar a la organización la realización de un proceso de análisis independiente en el cual se puedan identificar los objetivos de negocio y generar un documento que posteriormente debe ser entregado al equipo de definición de la arquitectura de alta disponibilidad para ser analizado en esta fase. Son muchos los objetivos de negocio que pueden establecerse al interior de una organización, pero de manera general las iniciativas relacionadas con la implementación de una arquitectura de alta disponibilidad provienen de objetivos como el desarrollo de una infraestructura robusta. 3.2.4. Arquitectura Oracle de base de datos de alta disponibilidad Oracle Database 10 g, brinda una completa gama de capacidades para resguardar a todas las causas de inactividad del sistema ya sean estas planificados y no planificados. Se expone los tipos de interrupción y de las capacidades de base de datos de Oracle y las características más eficaces de prevenir, tolerar o reparar cada tipo de parada. Tabla 3. Arquitectura Oracle de base de datos de alta disponibilidad.

Interrupción Tipo

Las capacidades de bases de datos y características No planificado

Fallas de computadoras

Las fallas almacenamiento

 las   

Oracle Database 10 g con RAC Oracle Database 10 g con Data Guard Oracle Database 10 g , con Streams Fast-Start Fault Recovery

 Automatic Storage Management de  Recovery Manager  Flash Recovery Area

Los errores humanos

 Oracle Security Features  Tecnología Oracle Flashback  LogMiner

Interrupción Tipo

Las capacidades de bases de datos y características

Corrupción de datos

     

Fallas en el sitio

 Oracle Database 10 g con Data Guard  Oracle Database 10 g , con Streams  Recovery Manager

Block Checking Bloque Chequeo Hardware Assisted Resilient Data (HARD) Oracle Database 10 g con Data Guard Oracle Database 10 g , con Streams Recovery Manager Flash Recovery Area

Planificado  Online Reorganization and Redefinition Datos de los cambios  Oracle Database 10 g con Data Guard  Oracle Database 10 g , con Streams

Cambios sistema

   el 

Automatic Storage Management Online Reorganization and Redefinition Online Reorganization and Redefinition Oracle Database 10 g con RAC. Online Reorganization and Redefinition Oracle Database 10 g con Data Guard o de Oracle Database 10 g , con Streams  Plataform Migrations and Database Upgrades with transportable Tablespace.

Elaborado por: http://docs.oracle.com/cd/B19306_01/server.102/b14210/architectures.htm

Esta sección describe las siguientes arquitecturas principales de base de datos que responden a diversas necesidades de negocios de alta disponibilidad: 3.2.4.1.

Oracle Database 10 g

Oracle Database 10 g ejecuta una sola base de datos en un ordenador independiente contiene importantes características de alta disponibilidad y capacidades. 3.2.4.2.

Oracle Database 10 g con RAC

Oracle Real ApplicationClusters (RAC) se basa en las características y capacidades de Oracle Database 10 g . RAC cuenta con varias instancias de Oracle que se ejecutan en varios equipos agrupados que acceden a una base de datos compartida

que reside en el disco compartido. RAC combina la potencia de procesamiento de estos equipos interconectados para proporcionar redundancia, escalabilidad y alta disponibilidad. Aplicación de escala en un entorno RAC para satisfacer las crecientes demandas de procesamiento de datos sin cambiar el código de la aplicación. Además, permitiendo que las operaciones de mantenimiento que se produzcan en un subconjunto de componentes en el grupo mientras la aplicación continúe funcionando en el resto del grupo puede reducir el tiempo de inactividad planificado. 3.2.4.3.

Oracle Database 10 g con Data Guard

Oracle Data Guard se basa en las características y capacidades de Oracle Database 10 g . Data Guard mantiene en espera hasta nueve bases de datos, cada una de los cuales es una copia en tiempo real de la producción de base de datos para proteger contra todas las amenazas: fallas de computadoras, fallas de almacenamiento, errores humanos, la corrupción de datos y fallas en el sitio. Si se produce un fallo en la recolección de base de datos, el procesamiento de datos puede conmutar a una de las bases de datos standby (que se convertirá en la nueva base de datos principal). Además, el tiempo de inactividad planificado para el mantenimiento se puede reducir porque el procesamiento de la producción puede ser rápida y fácilmente cambiar entre la base de datos principal actual a una base de datos standby, y luego de vuelta otra vez. 3.2.4.4.

Oracle Database 10 g con el RAC y Data Guard - MAA

Maximum Availability Architecture (MAA) combina las ventajas de escalabilidad y

disponibilidad de RAC con las capacidades de protección de lugares de Data Guard. Un entorno de MAA se compone de un sitio que contiene una base de datos RAC de producción, junto con un segundo sitio que contiene un clúster que sea sede de ambas bases de datos standby lógicas y físicas, o por lo menos una base de datos standby física o lógica. Esta arquitectura proporciona el conjunto más completo de soluciones para las interrupciones tanto planificadas y no planificadas, ya que hereda las capacidades y ventajas tanto de la base de datos Oracle10 g con RAC y Oracle Database10 g con las arquitecturas de Data Guard. 3.2.4.5.

Oracle Database 10 g, con Streams

Oracle Streams permite la propagación y el manejo de datos, transacciones y eventos en un flujo de datos ya sea dentro de una base de datos, o de una base de datos a otro. Al igual que en Oracle Database 10 g con Data Guard, con la base de datos Oracle Streams puede captar los cambios de base de datos, se propagan a los destinos, y aplicar los cambios en estos destinos. El uso de un entorno de flujos puede producir una sobrecarga administrativa adicional, pero ofrece una mayor flexibilidad que podrían ser necesarias para satisfacer las necesidades de negocio específica.

Maximum Availability Architecture (MAA)

RAC Only * Fast node / instance failover * Rolling patch upgrade

Data Guard Only * Disaster recovery * Rolling database upgrade

Streams * Replication

Core Database HA Features * Flasback technologies * Online redefinition and reorganization * Managed backup and recovery

Figura 6. Jerarquía de las arquitecturas de alta disponibilidad. Elaborado por: http://docs.oracle.com/cd/B19306_01/server.102/b14210/architectures.htm

A continuación se identifica las capacidades adicionales proporcionadas por las arquitecturas que se construyen sobre la base de datos Oracle 10 g .

Tabla 4. Capacidades adicionales de Alto Nivel arquitecturas de alta disponibilidad Oracle. Arquitectura de alta disponibilidad

Características clave y capacidades adicionales

Transparente a la aplicación de reparación de un error humano de conmutación por error en la computadora y el fracaso de almacenamiento, escalabilidad más allá de un único sistema. Transparente a la aplicación de reparación de un error humano de conmutación por error para la falla en la computadora, falla Oracle Database 10 g con Data de almacenamiento y la corrupción de datos. Guard Protección de falla en el sitio reduciendo el tiempo de inactividad para el mantenimiento de equipo. Transparente a la aplicación de reparación de un error humano de conmutación por error en la computadora y la corrupción de Oracle Database 10 g con el RAC datos en el sitio. y Data Guard - MAA Protección, escalabilidad más allá de un único sistema, reducción de tiempo de inactividad para el mantenimiento de computadoras. Reparación rápida para el error humano de réplica de bases de Oracle Database 10 g, Streams datos disponible para lectura / escritura. Proporciona soporte para plataformas heterogéneas. Oracle Database 10 g con RAC

Nota 1

requiere una planificación y los gastos generales para hacer una solución robusta

Elaborado por: http://docs.oracle.com/cd/B19306_01/server.102/b14210/architectures.htm

Tabla 5. Tiempos de recuperación alcanzables para interrupciones no planificadas. Interrupción Tipo

Fallo informático

Oracle Database 10 g Minutos a horas. El tiempo de recuperación consiste en gran parte del tiempo que se necesite para restaurar el sistema que ha fallado

Corrupción de Datos

Menos de 30 minutos HARD previene la corrupción de datos.

MAA

Streams

Sin tiempo de inactividad de base de datos aún está disponible, pero Segundos Sin tiempo Sin tiempo de parte de la a cinco de inactividad aplicación conec- minutos inactividad tada al sistema no se ve afectada temporalmente

Almacenamiento Sin tiempo de Sin tiempo / fracaso inactividad inactividad Error humano

Data Guard

RAC

Sin tiempo

de de

Menos de 30 minutos HARD previene la corrupción de datos. Potencialmente

inactividad

Menos de 30 minutos HARD previene la

Sin tiempo de Sin tiempo de inactividad inactividad

Menos de 30 Menos de 30 minutos minutos HARD HARD previene la previene la corrupción corrupción de

Potencialmente horas

horas

corrupción de datos. datos. de datos. Segundos a Segundos a Segundos cinco cinco minutos a cinco minutos minutos Segundos Segundos a Sin tiempo de Fracaso sitio Horas o días Horas o días a cinco cinco inactividad minutos minutos Elaborado por: http://docs.oracle.com/cd/B19306_01/server.102/b14210/architectures.htm

A continuación se muestra los tiempos de recuperación alcanzables para todo tipo de tiempo de inactividad planificado para cada arquitectura de la disponibilidad de Oracle. Tabla 6. Tiempos de recuperación alcanzables para interrupciones planificadas. Data MAA Guard Cambios en el sistema de Sin tiempo Sin tiempo Sin tiempo aprovisionamiento de Sin tiempo de de de de recursos dinámicos inactividad inactividad inactividad inactividad Sistema de Sin tiempo Sin tiempo Minutos u Segundos a actualización de de horas 5 minutos del nivel inactividad inactividad

Cambios del sistema: actualizaciones sucesivas

Interrupción Tipo

Actualización clúster

Oracle Database 10 g

Minutos horas

Migración de Minutos almacenamiento horas Parche de base Minutos de datos horas Parches de base de datos y Minutos actualización de horas la versión

RAC

Streams

Sin tiempo de inactividad Sin tiempo de inactividad Sin tiempo u Minutos u Segundos a Segundos a de horas 5 minutos 5 minutos inactividad Sin tiempo Sin tiempo Sin tiempo Sin tiempo u de de de de inactividad inactividad inactividad inactividad Sin tiempo Sin tiempo Sin tiempo u Segundos a de de de 5 minutos inactividad inactividad inactividad u Minutos horas

Sin tiempo u Segundos a Segundos a de 5 minutos 5 minutos inactividad

Sin tiempo de inactividad Reorganización de datos de Sin tiempo Sin tiempo Sin tiempo Sin tiempo cambios en línea y la Sin tiempo de de de de de redefinición inactividad inactividad inactividad inactividad inactividad Elaborado por: http://docs.oracle.com/cd/B19306_01/server.102/b14210/architectures.htm Migración plataforma

de Minutos horas

u Minutos horas

3.2.5. Prácticas de alta disponibilidad La elección e implementación de la arquitectura que mejor se adapte a los requisitos de disponibilidad de un negocio puede ser una tarea desalentadora. Esta arquitectura

debe abarcar la redundancia adecuada, proporcionar una protección adecuada contra todo tipo de cortes de energía, garantizar un rendimiento constante de alta y de una seguridad robusta, además de ser fácil de implementar, administrar y escalar. No hace falta mencionar, que esta arquitectura debe ser impulsada por los requerimientos del negocio bien entendido. Para construir, implementar y mantener este tipo de arquitectura, una empresa necesita una alta disponibilidad y las mejores prácticas que involucran tanto los aspectos técnicos y operativos de sus sistemas de TI y procesos empresariales. Tal conjunto de mejores prácticas elimina la complejidad de diseñar una arquitectura de alta disponibilidad, mientras que maximiza la disponibilidad de uso de los recursos mínimos del sistema, reduce los costos de implementación y mantenimiento de los sistemas de alta disponibilidad en el lugar, y hace que sea fácil duplicar la arquitectura de alta disponibilidad en otros las áreas del negocio. Una empresa con un conjunto bien articulado de las prácticas de alta disponibilidad y las mejores practicas que abarcan grandes marcos de análisis de disponibilidad, los impulsores del negocio y las capacidades del sistema, podrán disfrutar de una mayor resistencia operativa y una mayor agilidad del negocio. Oracle ofrece varios whitepapers que proporcionan detalles técnicos en sus diversas tecnologías de alta disponibilidad, junto con recomendaciones de buenas prácticas sobre la configuración y el uso de dichas tecnologías. (ORACLE, 2011)

3.3.

SOFTWARE LIBRE

3.3.1. Definición Software libre constituye cualquier programa cuyos usuarios gocen de la libertad. De

modo que debería ser libre de redistribuir copias con o sin modificaciones, de forma gratuita o cobrando por su distribución, a cualquiera y en cualquier lugar. Gozar de esta libertad significa, entre otras cosas, no tener que pedir permiso ni pagar para ello. De igual forma debería ser libre para introducir modificaciones y utilizarlas de forma privada, ya sean en el trabajo e el tiempo libre, sin siquiera tener que mencionar su existencia.(STALLMAN, 2004) Por tanto se entiende por software libre a aquel que se lo puede emplear indiscriminadamente sin tener que realizar pagos o pedir permisos, sino que sencillamente se lo utiliza en el cualquier tipo de ámbito para el que se lo requiera. Con software libre se refiere a la libertad de los usuarios para ejecutar, copiar, distribuir, estudiar, modificar y mejorar el software, específicamente a cuatro clases de libertad para los usuarios de software(STALLMAN, 2004): 

Libertad 0: libertad para ejecutar el programa sea cual sea el propósito.



Libertad 1: la libertad para estudiar el funcionamiento del programa y adaptarlo a las necesidades – el acceso al códito fuente es condición indispensable para ello.



Libertad 2: la libertad para redistribuir copias y ayudar así a tu vecino.



Libertad 3: la libertad para mejorar el programa y luego publicarlo para el bien de toda la comunidad – el acceso al código fuente es condición indispensable para ello.

Para que las libertades 1 y 3 adquieran significado es preciiso disponer del código fuente del programa, que es una condición necearia para el software libre. Todas las

libertades serán irrebicables siempre que no se cometa ningún error.(STALLMAN, 2004) 3.3.2. Transmisión del significado por el nombre El nombre determina el significado de lo que expresamos, debe ser preciso y puntual. Es relevante que quienes utilizan un sistema conozcan su origen, historia y propósito por cuanto no se volverá a cometer los mismos errores. La fuerza de la comunidad descansa sobre un compromiso con la libertad y la cooperación. Usar el nombre de GNU/Linux es una forma de que la gente lo recuerde e informe a los demás de los objetivos que engloba. (STALLMAN, 2004) Un gran reto para el futuro de software libre es la tendencia de las empresas de distribución de Linux a agregar software no libre a GNU/Linux en nombre de la convivencia y la potencia. La mayor parte de los desarrolladores de distribuciones comerciales no producen una distribución totalmente libre. Varios de ellos no identifican claramente los paquetes no libres de sus distibuciones. Muchos, incluso, desarrollan software no libre y lo añaden al sistema. Algunos se atreven a anunciar, de forma injuriosa, sistemas <Linux>, <Licenciado puesto>, lo que proporciona tanta libertad como el Windows de Microsoft.(STALLMAN, 2004) 3.3.3. Ventajas del software libre frente al open source. Dado que el software libre daría la misma libertad con cualquier otro nombre, qué nombre se usa marca una gran diferencia: plabras distintas transmiten distintas ideas.

En 1998, algunos dentro de la comunidad del software libre empezaron a usar el término <software open souce> en lugar de <software libre> para describir lo que hacían. El término open source se asoció rápidamente con enfoques distintos, una filosofía distinta e incluso diferentes criterios para decidir qué licencias son aceptable. El movimiento de software libre y el movimiento open source son hoy en día movimientos separados con diferentes puntos de vista y objetivos, aunque se pueda y trabajen juntos en algunos proyectos prácticos.(STALLMAN, 2004) La diferencia fundamental entre los dos movimientos está en sus valores, en su visión del mundo. Para el movimiento open source, la cuestión en si es que el software debe ser de fuente abierta y es una cuestión práctica, no ética. Como lo expresó alguien: <el open source es un método de desarrollo: el software libre es un movimiento social>. Para el movimiento opens source, el software no libre es una solución ineficiente. Para el movimiento de software libre, el software no libre es un problema social y el software libre es la solución. 3.3.4. Relación entre el movimiento del software libre y el de open source El movimiento del software libre y el movimiento open source son como dos campos políticos dentro de la comunidad del software libre. La relación de éstos es justo la contraria a enemigos; se encuentran en desacuerdo en los principios básicos, pero más o menos de acuerdo en las recomendaciones prácticas. 3.3.5. Formas de promoción del software libre En este movimiento se cree que los usuarios de ordenadores deberían tener libertad para cambiar y redistribuir el software que utilizan. El adjetivo <libre> en el software libre hace referencia a la libertad: libertad del usuario para ejecutar, modificar y

redistribuir el software. Este contribuye al ser humano al contrario que el software propietario. Por este motivo, las instituciones educativas deberían fomentar el software libre, para hacer una aportación al progreso del conocimiento humano, al igual que animar a científicos y académicos para publicar sus obras.(STALLMAN, 2004) 3.3.6. Documentación libre para el software libre La mayor deferencia en los sistemas operativos libres no se encuentra en el software, sino en la falta de buenos manuales libres que se puedan incluir en estos sistemas. Muchos de los programas más importantes no vienen acompañados de manuales completos. La documentación es una parte esencial de cualquier paquete de software; cuando un paquete de software libre relevante no está acompañado de un manual libre, se produce tremenda laguna. (STALLMAN, 2004) La documentación libre, como el software libre, es un asunto de libertad y no de precio. Existen restricciones que generan problemas como en el caso de que se presenten manuales impresos y no en un código fuente. 3.3.7. Licencia Pública General GNU Las licencias que cubren la mayor parte del software están diseñadas para despojarle de la libertad para compartirlo y para modificarlo. Por el contrario, la Licencia Pública General de GNU pretende garantizar la libertad de compartir y modificar software libre –para asegurar que el software sea libre para todos sus usuarios. Esta Licencia Pública General se aplica a mayor parte del software de la Free Software Foundation y a cualquier otro programa, si sus autores se comprometen a utilizarla. (STALLMAN, 2004)

Cabe reclacar que cuando se mencion software libre, se refiere a la libertad, no al precio. Esta licencia se efectúo para asegurar que se tenga la libertad de distribuir copias de software libre –cobrar por ese servicio si se quiere-, de que reciba el código fuente o que lo pueda obtener de otra forma y así se pueda modificar el software o utilizar partes de éste en otros programas libres y que se tenga conocimiento de ello.

IV 4. METODOLOGÍA 4.1.

ANÁLISIS METODOLÓGICO

4.1.1. INTRODUCCIÓN La metodología constituyen las herramientas y parámetros técnicos en los que se efectúa la labor de campo de la investigación, específicamente en la recolección de información de las fuentes primarias y los métodos y técnicas aplicadas. En vista de la necesidad de potencializar la seguridad en la PUCE SD, se empleó en el desarrollo de esta disertación de grado el método de investigación cuantitativa-cualitativa, en vista de que se expuso los requerimientos de la utilización de un espejo redundante de tal forma que se asegure la información. Luego de haber analizado las posibilidades para generar seguridad en la información, contribuyó a delimitar el problema investigado, al igual que se elaboraron las preguntas que dieron el paso a la estructuración de la propuesta mediante el empleo de métodos y técnias aplicadas por los investigadores, efectuando el análisis sobre cada uno de los aspectos que se los describe en el transcurso de este capítulo. El método cuantitativo permitió realizar el análisis de la información en valores absolutos, utilizanto las herramientas en el ámbito estadístico que exponen los factores requieren de protección según la información recolectada y que generó una propuesta coherente con el problema.

4.1.2. TIPO DE INVESTIGACIÓN 4.1.2.1.

Bibliográfica

Debido a que se encuentra sustentada en teorías científicas y a ello se debe su funcionamiento. 4.1.2.2.

Aplicada

En función a que se describe el proceso para la construcción del servidor espejo redundante, con la utilización de un software libre y base de datos Oracle que es la idea de disertación. 4.1.3. MÉTODOS DE INVESTIGACIÓN Las técnicas que se utilizaron para obtener la información tanto a nivel de campo como teórico fueron las siguientes: 4.1.3.1.

Método Experimental

Ya que los conocimientos fueron la fuente para efectuar experimentos al construir la parte física de la propuesta, se recopiló la información de fuentes bibliográficas y sobre todo de Internet para diseñar el servidor espejo redundante. 4.1.3.2.

Método de Analítico - Sintético

Proporcionó al desarrollo de esta investigación la facilidad de efectuar los análisis de todos los datos recolectadados y que constituyen los pilares de la propuesta que vendrían a solucionar los actuales problemas en estudio. Este método permitió describir las necesidades y la problemática actual que se presenta en la Pontificia Universidad Católica Sede Santo Domingo parapresentar el estudio y proponer un sistema de información que funcione las 24 horas y los 7 días.

4.1.4. TÉCNICAS DE RECOLECCIÓN DE DATOS 4.1.4.1.

Fuentes primarias

Las técnicas que se emplearon fueron las siguientes: 

Consulta a expertos Se apoyó en esta técnica para la estructuración del sistema y el monitoreo del mismo.



Encuestas Se empleó para la obtención de información sobre el sistema de seguridad de información del sistema que actualmente maneja la PUCE SD.

4.1.4.2. 

Fuentes secundarias

Libros Se empleó bibliografía actualizada en temas de sistemas y construcción de un nodo o servidor con un espejo redundante.



Internet Se utilizó el medio informático para acceder a una mayor información en forma global y sobre todo actualizada.

4.1.5. TÉCNICAS DE ANÁLISIS DE LA INFORMACIÓN Toda la información se procesó analíticamente con los respectivos cuadros, gráficos e interpretaciones y demás investigaciones realizadas en beneficio de la investigación hecha.

4.1.6. PROCESAMIENTO DE LA INFORMACIÓN Esta parte del proceso de la investigación consistió en procesar los datos obtenidos durante el las encuestas realizadas y tiene como finalidad generar resultados a partir de los cuales se efectuó el análisis según los objetivos y la hipótesis. 4.1.7. ANÁLISIS TÉCNICO 4.1.7.1. 1.

Resultados del cuestionario de análisis de impacto del negocio.

Información de la organización

Complete la información acerca de la organización y sobre la contratación de una persona en caso de requerir datos más detallados Nombre de la compañía

PUCE SD

Departamento

CITIC

Nombre del proceso de negocio

T. I.

Encargado del proceso de negocio

Nombre:Rodolfo Córdova E-mail:

citic@pucesd.edu.ec

Análisis de la organización

¿Describa brevemente en qué consiste el proceso del negocio? Gestión de T. I. Enumere en orden las funciones que abarca el proceso del negocio Función Soporte Técnico

Descripción Dar soporte técnico a los usuarios de la Universidad.

Programación

Dar soporte a los programas que posee la Universidad.

Soporte Técnico

Se encarga de la infraestructura de red.

Indique los ciclos de procesamiento crítico (hora/día/mes/trimestre/año) para las funciones más importantes Función

Ciclo (dd/mm/yyyyhh:min)

Respaldo de base de datos

Dos veces al día.

Indique el número y tipo de usuario que utiliza el proceso de negocio. Considere usuarios internos y externos

Tipo de usuario

Número

Administrativos

58.

Estudiantes

1402.

Información de impacto tangible e intangible

Describa cualquier tipo de cambio a la estructura del proceso de negocio a realizarse en los próximos 2 años y seleccione el tipo de impacto que generaría Cambio

Impacto (Alto, Medio, Bajo)

Construcción de un Data Center

Alto.

Implementación de dominios

Bajo.

Describa cualquier tipo de cambio a las aplicaciones y/o módulos que utiliza el proceso de negocio para su funcionamiento a realizarse en los próximos 2 años y seleccione el tipo de impacto que generaría Cambio

Impacto (Alto, Medio, Bajo)

Cambio de Sistemas

Alto.

Enumere el día mes y/o período del año en el que el proceso de negocios es más crítico □ Enero

□ Lunes

□ Fin de semana

□ Febrero

□ Martes

□ Fin de semana

□ Marzo

□ Miércoles

□ Fin de semana

□ Abril

□ Jueves

□ Fin de semana

□ Mayo

□ Viernes

□ Fin de semana

□ Junio

□ Sábado

□ Julio

□ Domingo

□ Agosto □ Septiembre □ Octubre □ Noviembre □ Diciembre Selecciones la ventana de tiempo que el proceso de negocio puede permanecer sin soporte técnico especializado □ Hasta 1 hora Selecciones la ventana de tiempo en el cual se tendría un impacto de alto nivel

debido a la interrupción del proceso □ 8 horas Basándose en la configuración actual de la infraestructura en su organización. ¿En cuánto tiempo se puede recuperar ante una falla de los sistemas de misión crítica? 24 horas Enumere las principales decisiones de negocio que puedan verse afectadas por la interrupción del proceso 1. Procesos contables 2. Procesos académicos Complete la siguiente información referente al impacto tangible generado por la interrupción de procesos Si/No

Impacto

Prioridad (Alta, Media, Baja)

Reducción de productividad

Media

Incremento de gastos

Baja

Pérdidas financieras

Media

Pérdidas legales

Baja

Complete la siguiente información referente al impacto intangible generado por la interrupción de procesos Si/No

Impacto

Prioridad (Alta, Media, Baja)

Pérdida de confianza

Alta

Pérdida de clientes

Media

Pérdida de competitividad

Baja

Pérdida de imagen

Alta

Seleccione un rango que explique la cantidad de dinero que la organización pierde por hora si el proceso de negocio está fuera de servicio Ninguno 4.

Información de recuperación y respaldo

Indique si se cuenta con un manual de procedimientos a ser usado si se produce la interrupción del proceso □ Si

□ No

¿Indique cuándo fue la última vez que se realizaron pruebas para verificar los procedimientos de recuperación? ____________________

□ Días

□ Semanas

□ Meses

Indique la cantidad de tiempo máxima que se puede utilizar un proceso alternativo ____________________

□ Horas

□ Días

□ Semanas

¿Indique cuántos miembros del grupo de tecnología están involucrados en proceso de respaldo y recuperación asociada al proceso de negocio regularmente? 1. Indique si se realizan respaldos de la información asociada al proceso de negocio regularmente □ Si

□ No

Para cada una de las áreas que se especifica a continuación, indique qué

procedimiento (s) utiliza para la realización de respaldos Sistema operativo

_____________________________

Base de datos

Respaldo incremental y total

Servidor de aplicaciones

Respaldo de configuración de aplicaciones y

datos Aplicaciones del negocio

Respaldo de información

Servidor de correo electrónico

Gestionada por otra unidad

Servidor de archivos

Respaldo de archivos

Seleccione la frecuencia con la que realiza los respaldos de información □ Diario (Full)

□ Diario (incremental)

□ Semanal (Full)

□ Semanal (incremental)

Indique si se realizan pruebas para verificar la correcta generación de respaldos □ Si

□ No

Si contestó si a la pregunta anterior, para cada una de las áreas que se especifica a continuación, explique qué tipo de pruebas se realizan Sistema operativo

_____________________________

Base de datos

Subir respaldos a una nueva base

Servidor de aplicaciones

Verificar su funcionamiento

Aplicaciones del negocio

Veracidad de la información

Servidor de correo electrónico

_____________________________

Servidor de archivos

Verificar la información

Identifique si la realización de respaldos afecta el rendimiento de los sistemas de producción □ Si

□ No

Indique si considera necesario reducir la complejidad y mejorar la calidad del proceso de respaldo y recuperación □ Si

□ No

Indique si los respaldos son almacenados fuera de la organización □ Si

□ No

V 5. PROPUESTA 5.1.

ANÁLISIS

DIAGNÓSTICO

DIFERENTES

SOLUCIONES Y TÉCNICAS Se ha buscado las diferentes soluciones al problema investigado y se han identificado seis opciones que son las más prácticas y adecuadas, siendo unas aplicaciones desarrolladas por empresas ajenas a Oracle y otras como soluciones integrantes de las versiones Enterprise de Oracle. A continuación se describen: 

Vistas Materializadas



SharePlex



Data Guard de Oracle



Oracle Streams



Oracle Golden Gate



Espejo redundante con Scripts

5.1.1. Vistas Materializadas 5.1.1.1.

Introducción

Es una forma de replicar de manera sencilla los datos de una base de datos oracle hacia otro servidor oracle, mediante el uso de vistas materializadas. La replicación nos permite obtener una copia exacta de una base de datos alojada en un servidor (maestro) que se guardará en otro servidor (esclavo). Todos los cambios que se hagan en la base de datos del servidor maestro se actualizarán inmediatamente en el servidor esclavo. Esto no es una copia de seguridad, ya que si deshacemos una fila en la base de datos maestra, también se deshace en la base de datos esclava. 5.1.1.2.

Descripción del sistema

Una vista es una consulta almacenada que representa un conjunto de tablas (posiblemente de diferentes esquemas) a la que se le pone un nombre y trata como si fuese una tabla más del esquema, pero sin llegar a ser realmente una tabla. Algo que tiene que quedar claro es que una vista no guarda datos, sino que solo almacena la consulta que nos va a ayudar a acceder a los datos. Se utiiza este método por seguridad, para impedir que determinados usuarios accedan a toda la información de la base de datos. Por otro lado tiene que ver con la estructura del modelo de datos, ya que si es bastante complejo o con muchas tablas puede ser muy útil crear este tipo de vistas para organizar una cierta información de modo que sea mucho más cómodo acceder a ella mediante consultas mucho más sencillas.

Una vista materializada almacena físicamente los datos resultantes de ejecutar la consulta definida. Por lo tanto, este tipo de vistas materializadas realizan una carga inicial de los datos cuando se definen y posteriormente con una frecuencia establecida se actualizan los datos de la misma .Se consigue aumentar el rendimiento de las consultas SQL con la utilización de vistas materializadas además de ser un método de optimización a nivel físico en modelos de datos muy complejos En un sistema de gestión de base de datos que persiga el modelo relacional, una vista es una tabla virtual, que representa el resultado de una consulta. Siempre que se consulta o se actualiza una vista normal, el SGBD(sistema de gestión de bases de datos) convierte estas operaciones en consultas o actualizaciones de las tablas usadas para definir la vista.

Figura 7. Descripción de Vistas Materializadas. Elaborado por: http://www.n4gash.com/2011/diferencias-vista-oracle-vistamaterializada-view/

Una vista materializada utiliza una aproximación diferente: el resultado de la consulta se almacena en una tabla cache real, que será actualizada de forma periódica a partir de las tablas originales. Esto proporciona un acceso mucho más eficiente, a

coste de un incremento en el tamaño de la base de datos y a una posible falta de sincronía, es decir, que los datos de la vista pueden estar potencialmente desfasados con respecto a los datos reales. Es una solución muy utilizada en entornos de almacenes de datos (data warehousing), donde el acceso frecuente a las tablas básicas resulta demasiado costoso. No se encuentran disponibles estás vistas materializadas para todas las bases de datos del mercado, la utilización es compatible con base de datos Oracle, DB2, Informix, Microsoft SQL Server. Esta situación evita que se realicen cálculos que exigen de mucho tiempo en su ejecución cuando se realiza la consulta. 5.1.1.3.

Factibilidad técnica

Debido a que es un procedimiento sencillo por no necesitar software adicional, sus costos son bajos y la necesidad de equipos potentes es innecesaria, motivo por el cual este método podria resultar muy útil ya que se trabaja con herramientas propias de la base de datos. En cuanto a los conocimientos son suficientes para el desarrollo y ejecución de la implementación.

Para una mejor explicación de lo que se ha descrito anteriormente, se muestra la siguiente tabla, detallando las características tanto de Hardware como de Software que se necesitan para el desarrollo y funcionamiento del sistema:

Tabla 7. Recursos técnicos para el análisis de factibilidad. RECURSOS TÉCNICOS PARA ANÁLISIS DE FACTIBILIDAD Tipo de recurso Humanos

Nombre del recurso Honorarios profesionales

Hardware

Servidor mínimos)

(Requisitos

Software

Centos Linux 5.5 Oracle 10g R2

Descripción Administrador de Base de Datos Servidor Pentium IV 2.0 GHz, 1024 de Mb de RAM 120 Gb disco duro Sistema operativo Base de Datos Edición Estándar

Cantidad 1 2

2 2

Conclusión:Según los recursos técnicos que se requieren para la instalación, estos son básicos y adsequibles, por tal razón, el proyecto es factible técnicamente. Fuente: Investigación Directa Elaborado por: Dennys Peñaloza y Paúl Pabón

5.1.1.4.

Factibilidad operativa

Tal vez por ser una forma muy sencilla de replicar trae desventajas como una implementación tediosa y que es menos funcional que trabajar con los Streams de Oracle, la convierte en un método medianamente efectivo al momento de elegir el método idóneo de replicación. Pese a que existe la viabilidad no es factible su aplicación a nivel operativo por la limitación del sistema. 5.1.1.5.

Factibilidad económica

Se establece el presupuesto de costos que aproximadamente cubrirá los recursos técnicos, humanos y materiales tanto para el desarrollo como para la implantación del Sistema. Al no existir elementos externos para la implantación de este método de replicación y siendo en su totalidad ejecutable con las mismas herramientas de Oracle, hace posible que no se requiera de un presupuesto grande para la realización del proyecto. A continuación se describe los costos del recurso necesario para el desarrollo de nuestro Sistema de Información:

Tabla 8. Recursos.

Nº 1

Cantidad 2

Recursos Humanos Costo Individual 1.200,00 Total Recursos Tecnológicos Hardware Descripción Costo 2.200,00 Total Software Descripción Costo 0,00 Total Recursos Materiales Descripción Costo 50,00 Total

Cargo Honorarios profesionales

Servidores

Cantidad 1 Centos 5.5

Cantidad 1 Varios

Flujo de Pago Recursos Pago Recursos Humanos Recursos Tecnológicos Recursos Materiales Imprevistos (10%) Total Fuente: Investigación Directa Elaborado por: Dennys Peñaloza y Paúl Pabón

Costo Total 1.200,00 1.200,00

Total 2.200,00 2.200,00 Costo Total 0,00 0,00 Total 50,00 50,00

1.200,00 2.200,00 50,00 3.45,00 3.795,00

Conclusión: Según los recursos económicos que se requieren para la adquisición e implementación, el proyecto es factible económicamente. 5.1.2. SharePlex 5.1.2.1.

Introducción

Proporciona copias en tiempo real de los datos de producción, sin afectar el rendimiento y la disponibilidad del sistema OLTP. Es una solución de replicación e integración de datos para Oracle 10g, 11g, 12g y para otras bases de datos. SharePlex ejecuta una réplica puntual de las variaciones que se han hecho en el

sistema de información hacia el sistema alterno que puede ser de manera continua para no interrumpir el proceso general, de tal forma que los datos tendrán accesibilidad.

Figura 8. Logotipo de SharePlex. Elaborado por: http://www.quest.com/tv/AllVideos/13 65770830001/Toad-for-Oracle---MonitorBackground-Processes-with-Spool-SQL/Video/

5.1.2.2.

Descripción del sistema

Cuando se activa una configuración SharePlex comienza la replicación de datos y se transportan en toda la serie de colas por medio de cinco procesos, a estos se los llaman servicios, hasta que alcanza su destino en el sistema designado. Estos procesos son automáticos y guardan relación de lo que se necesite, sin embargo pueden detenerse y reiniciarse mediante comando emitidos por un usuario de SharePlex. Estos procesos son: 

En el proceso de captura se lee uno o varios redo log y se obtiene las variaciones a los objetos seleccionados para replicar. En este se describen los datos para los

cambios a la cola de captura, allí se almacenan durante el proceso de lectura que sigue al estar listo. Se proporciona un proceso de captura por separado y se replica en cada instancia, para que funcione de forma concurrente e independiente. 

El proceso de lectura sigue en la replicación, se incluye información de direccionamiento a la transacción en base al archivo de configuración y construye una cola de exportación. Se genera un proceso aparte de lectura para cada origen de datos y así funcionan concurrente e independientes. Sin embrago, todos los procesos de lectura comparte la misma cola de exportación.



Para el proceso de exportación es preciso operar sobre el sistema de origen y se analizan los datos de la cola de exportación, luego se los envía a través de la red hacia un proceso de importación en el mismo sistema de destino.

Es irrelevante la cantidad de configuraciones activas que existan directamente replicando al sistema específico de destino. Hacia el sistema de destino el replicador crea un proceso de exportación y se comparten los datos; se registrarán la misma cantidad de sistemas de destino como de exportación. Este es la primera parte de la exportación-importación “par de servicio”, actuando como un transporte que mueve los datos entre los dos sistemas de red TCP / IP. 

En el proceso de importación que es el segundo medio del par de servicios exportación-importación. La función de este es acoger los datos del sistema de origen y formar una cola post sobre el sistema destino y se genera una cola para cada fuente de datos que se replica en ese sistema.



En el proceso post cada sistema destino lee los datos que esperan en la cola post, y van elaborando declaraciones SQL para las operaciones de replicación y aplican la misma metodología a las tablas de destino sobre el sistema destino. Se pueden operar sincronizadamente varios procesos post, siendo cada uno asignado a una combinación de instancias diferentes origen-destino sobre el sistema destino.

BDD

Figura 9. Descripción de SharePlex para Oracle. Elaborado por: http://www.dlt.como/quest/solutions-availability.asp?sol=shareplx

Al configurar los sistemas y base de datos es relevante asegurarse de que los datos de origen y destino se encuentran sincronizados, solucionando condiciones “fuera de sincronía” que podrían ser consumidas en tiempo y ser disociadores para la actividad del usuario. Para un entorno de replicación sincronizada que esté establecida y mantenida es preciso un entendimiento básico de cómo replica SharePlex y la forma en que determina la condición de fuera de sincronía. El concepto de sincronización básica es que todas las tablas correspondientes en el origen y destino en la configuración de la replicación sean iguales. Esto quiere decir:



Tengan una estructura similar al igual que los nombres de columna y tipo de datos iguales (incluyendo datos) dentro de las columnas correspondientes.



Todas las líneas emparejadas, si existe una línea en una base de datos, existe en todas las demás.



Los valores en las líneas correspondientes son idénticos.

La configuración de SharePlex se realiza para replicar sobre conexiones LAN y WAN que guarden una segunda instancia permanentemente actualizada y lista para tomar la información de la instancia cuando el sistema de origen está programado para el mantenimiento o un desastre.

Figura 10. Configuración de SharePlex para Oracle. Elaborado por: http://article.wn.com/view/2012/10/17/Polaris_inks_pact_with_Pyxis/

La instancia alternativa constituye una imagen espejo del entorno de información, para que se optimice la efectividad es esta, los objetos que han sido replicados deberán tener el mismo propietario y nombres sobre el sistema primario y secundario. Se logra refrescar el período físico al emplear para la actualización de cambios a la estructura de la base de datos, mientras SharePlex replica los cambios a

los datos. Su configuración de replicación bidireccional se lo hace con una configuración reversa, mientras el sistema primario está fuera de línea, los usuarios están trabajando sobre el sistema secundario, las colas SharePlex cambian sobre el sistema secundario. Es ahí cuando el sistema primario es restaurado, SharePlex puede actualizarse con esos cambios. Las ventajas de empleo de esta alternativa son: 

Puede mantener la accesibilidad constante a la instancia destino, no se forza a elegir entre replicación y acceso, pero puede ingresar a la instancia mientras SharePlex está actualizándose.



Se diseña para entornos OLTP de alta intensidad está elaborado para los negocios con volúmenes de datos, siendo capaz de replicar millones de transacciones por día para miles de tablas.



Se conservan los recursos del sistema SharePlex y se efectúa esta replicación sin impactos significativos a la instancia origen, el sistema origen o la red. Al estár basado en log permite replicar con muy baja sobrecarga u overhead.



La exactitud y velocidad con ambas replicación continua, SharePlex es veloz y minimiza la latencia entre las instancias origen y destino capturando las modificaciones a las tablas seleccionadas y secuencias de redo logs Oracle permanentemente, generando prioridad a la replicación de la transacción que les ha dado commit. Al cancelar la transacción, SharePlex replica el rollback tanto que la instancia destino es una representación exacta de la base de datos origen.



SharePlex es rápido, sin embargo, la velocidad no sacrifica la exactitud del dato.

SharePlex estrictamente adhiere al modelo consistencia de lectura, manteniendo ambas operaciones en orden y el contexto de la sesión toda la manera al de la instancia designada, donde usa el estándar SQL para aplicar la transacción. 

SharePlex mantiene tolerancia a fallos, puede colocar en una cola si la instancia destino está abajo, haciendo que las transacciones se acumulen en el sistema destino mientras la comunicación puede ser restablecida con la instancia destino. Al estar abajo el sistema destino en la red, SharePlex almacena las transacciones en el sistema origen mientras las operaciones sin restauradas.



Este diseño genera alto nivel de control de usuario, teniendo opciones adicionales; para controlar cuando SharePlex envíe los datos sobre el enlace de la red, se puede hacer.



Se instala rápido y fácilmente, por todo lo sofisticado y poderoso que es, sobre todo muy simple de instalar y el tiempo que dura es en promedio de una hora.



En un entorno de alta disponibilidad replica y provee una ventaja significativa en ese entorno y otras operaciones de misiones críticas, donde el acceso a los datos es crítico, y el downtime significa pérdida de oportunidad en los negocios. Este sistema hace que la sincronización inicial de replicación, como la resincronización después de una falla o cambios en la aplicación-base de datos sea facil, para lograr

una mínima interrupción de actividad del usuario.

Adicionalmente, aplicando replicación SharePlex con otras tecnologías de alta disponibilidad permite a la base de datos secundaria ser usada para consultas y reportes. 

Este sistema constituye una solución liviana en uso de recursos (CPU, ancho de

banda de comunicación, carga de memoria moderada en la base de datos, entre otros), sin un solo punto de falla y facilidad de manejar ambientes heterogéneos en versiones de base de datos Oracle y sistemas operativos distintos y diferentes versiones del mismo. La desventaja básica es el precio entre otros. Las bases de datos origen y destino tendrán que emplear la misma versión de SharePlex. No se puede replicar algunos componentes que se utilizan en Oracle, por mencionar algunos: Alter Table para borrar una columna, agregar una columna con una clave primaria o un constraint único, mover líneas, redefinir una columna, entre varias aplicaciones adicionales. 5.1.2.3.

Factibilidad técnica

SharePlex es una aplicación independiente de oracle que busca ayudar a sus usuarios, motivo por el cual esta herramienta es de pago. En cuanto al hardware los requerimientos del sistema son básicos no necesitando extremadamente grandes. Paratener los conocimientos suficientes seria necesario una capacitación para el manejo de la herramienta. Para una mejor explicación de lo que se ha descrito anteriormente, se muestra la siguiente tabla, detallando las características tanto de Hardware como de Software que se necesitan para el desarrollo y funcionamiento del sistema:

Tabla 9. Recursos técnicos para el análisis de factibilidad.

RECURSOS TÉCNICOS PARA ANÁLISIS DE FACTIBILIDAD Tipo de recurso

Nombre del recurso

Humanos

Honorarios profesionales

Hardware

Servidor mínimos)

(Requisitos

Descripción Administrador de Base de Datos (Con conocimientos en SharePlex) Servidor Pentium IV 2.0 GHz, 2 GB de RAM 120 Gb disco duro Sistema operativo Base de Datos Edición Estándar

Centos Linux 5.5 Oracle 10g R2 Software SQL * Plus SharePlex Software integrador Conclusión: Según los recursos técnicos que se requieren para la instalación, adsequibles, por tal razón, el proyecto es factible técnicamente. Fuente: Investigación Directa Elaborado por: Dennys Peñaloza y Paúl Pabón

5.1.2.4.

Cantidad 1 2

2 2

estos

serian

Factibilidad operativa

SharePlex es inmensamente funcional proporcionándo copias en tiempo real, velocidad en transmisión de datos, exactitud, tolerancia a fallos entre otras, esto la hace un herramienta indispensable para un dba, pero el costo constituye una desventaja al momento de elegir la mejor herramienta para replicación. Por tanto operativamente es factible. 5.1.2.5.

Factibilidad económica

Se determina el presupuesto de costos aproximado de los recursos técnicos, humanos y materiales tanto para el desarrollo como para la implantación del Sistema. Al existir elementos externos para la implantación de este método de replicación y no siendo funcional en su totalidad con las mismas herramientas de Oracle, hace necesaria la compra de la licencia del Software SharePlex de Quest Software.

A continuación se describe los costos del recurso necesario para el desarrollo del Sistema de Información: Tabla 10. Recursos.

Nº 1

Cantidad 2

Cantidad

Recursos Humanos Cargo Honorarios profesionales Recursos Tecnológicos Hardware Descripción Servidores Software Descripción 1 Shareplex f/oracle stded f/rac/ops PER CPU 1 Centos 5.5 Recursos Materiales Descripción

Cantidad

Costo Individual 1.200,00 Total

Costo Total 1.200,00 1.200,00

Costo 2.200,00 Total

Total 2.200,00 2.200,00

Costo 2.405,70 0,00 Total

Costo Total 2.405,70 0,00 2.405,70

Costo

1 Varios

25,00 Total

Flujo de Pago Recursos Pago Recursos Humanos Recursos Tecnológicos Recursos Materiales Imprevistos (10%) Total Fuente: Investigación Directa Elaborado por: Dennys Peñaloza y Paúl Pabón

Total 25,00 25,00

1.200,00 4.605,70 25,00 583,07 6.413,77

Conclusión: Según los recursos económicos que se requieren para la adquisición e implementación, el proyecto no es factible económicamente.

5.1.3. Data Guard de Oracle 5.1.3.1.

Introducción

Data Guard ofrece una solución que integra la configuración y gestión de bases de datos de reserva. El implementar la base de datos de reserva consiste en una o más bases de datos que son copias separadas de una base de datos en información. Varios de los usos de las bases de datos de reserva contienen el mantenimiento de bases de datos separadas para informes, una base de datos fuera de sede para recuperación de desastres o una copia de la base de datos de producción usada para el desarrollo o prueba de aseguramiento de la calidad. 5.1.3.2.

Descripción del Sistema

Lo básico es la posibilidad de desarrollar la función de la base de datos Oracle que provee la mayor y más efectiva disponibilidad, protección y recuperación ante desastres de los datos, ya que suministra la administración, monitoreo y automatización de una o más bases de datos standby para proteger a los datos ante fallas, desastres, errores o corrupción. Se presentan algunos de los varios componentes que pertenecen a la arquitectura de Oracle Data Guard: 

Base de datos primaria: Es la fuente de datos para la instancia de reserva. Una sola base de datos primaria puede tener múltiples bases de datos de reserva.



Base de datos de reserva: Esta es copia de la base de datos primarios que se produce.



Servicios de registro: La transferencia de los registros desde la base de datos primaria a la base de datos de reserva. Adicionalmente se examina la frecuencia con que los archivos de registro se aplican a las bases de datos de reserva.



Data Guard Bróker: Consiste en el componente que realiza la creación, control y gestión de la configuración de base de datos primaria/secundaria.



Sede de Data Guard: Es la colección de una base de datos primaria y hasta nueve bases de datos de reserva.

Una base de datos de reserva se crea empleando tanto el componente Data Guard Manager de Oracle Enterprise Manager como herramientas desde la línea de comandos. Crear y gestionar una sede ODB implica estos pasos: 

Configurar la base de datos primaria.



Determinación del modo de protección. o Modo de protección garantizada. o Modo de protección instantánea. o Modo de protección rápida. o Modo de protección demorada.



Determinar el modo de operación de reserva. o Modo de recuperación gestionada. o Modo de sólo lectura.

La opción Active Data Guard, que se encuentra disponible con Oracle Database 10 g, permite que una base de datos física de reserva se use para el acceso de sólo lectura a las aplicaciones. Snapshot Standby permite la apertura de una base de datos física de reserva para ejecutar actividades lectura y escritura a fin de probarlas o realizar cualquier otra actividad que requiera una replicación de lectura y escritura de los datos de información. Una base de datos lógica de reserva cuenta con la flexibilidad adicional de poder abrirse en modo de lectura y escritura. Si bien los datos que mantiene SQL Apply no pueden modificarse, es posible agregar tablas locales adicionales a la base de datos, además de crear estructuras locales de índices para optimizar la generación de informes o usar la base de reserva como almacén de datos o para transformar la información utilizada a fin de cargar almacenes de datos especializados.

Figura 11. Arquitectura de Oracle Data Guard. Elaborado por: http://www.iuma.ulpgc.es/users/lhdez/inves/pfcs/memoria-ivan/node7.html

Luego de haberse creado y configurado las bases de datos de reserva, el bróker ODG gestiona y supervisa la propagación y aplicación de registros para restaurar, en función al modo de protección seleccionado. Basado en que ODG acceda a la

creación de múltiples instancias de reserva, la mejor configuración de protección tendría un número de bases de datos de reserva, cada una de ellas con un modo de protección distinto. Al quedar inaccesible la base de datos primaria por problemas de hardware en el nodo de la base de datos primaria, puede iniciarse una recuperación del fallo con la base de datos de reserva. El número de datos que se pierden durante la operación de recuperación del fallo está en función del modo de protección elegido. Al haber producido la recuperación del fallo, la base de datos de reserva asume el papel de base de datos primaria. Cuando ya se ha solventado el problema de hardware en el nodo de la base de datos primaria, se vuelve a la configuración original para crear una instancia de la base de datos copiando de nuevo la base de datos y reconfigurando el nodo de reserva con su estado original. ODG (Oracle Data Guard) permite que se inicie el manual de un intercambio desde la base de datos primaria a la base de datos de reserva sin necesidad de re-instanciar al volver a la situación original. Siendo útil para efectuar mantenimiento en los nodos de base de datos. Cada vez que configuramos un Data Guard (StandBy mas envío de archives automáticos) siempre se va a quedar enmarcado en unos de estos tipos de disponibilidad de la standby: 

Máxima Protección (Máximum Protección)



Máxima Disponibilidad (Máximum Availability)



Máxima Performance (Máximum Performance)

Con los tres modos siempre se protege los datos, pero la gran diferencia está en cómo actúa la base de datos primaria cuando la standby tiene problemas. 

MÁXIMA PROTECCIÓN (MAXIMUM PROTECTION) Este modo garantiza que no hay pérdida de datos si la base de datos primaria falla. MÁXIMA DISPONIBILIDAD (MAXIMUM AVAILABILITY) Este modo de protección no afecta la base de datos y proporciona un alto nivel de protección de los datos, tal cual en el modo de máxima protección, las transacciones no ejecutan el commint hasta que el redo data sea aplicado en los redologs de la base de datos standby, por lo menos en una de ellas (si existe más de una). Si no se puede escribir el redo data, en por lo menos una standby, la base de datos primaria no se cae.



MÁXIMA PERFORMANCE (MAXIMUM PERFORMANCE) Este modo de protección ofrece la mayor seguridad en la base de datos sin perder nada en la performance de la base de datos primaria, acá las transacciones de la base de datos primaria se les generará commit sólo cuando la transacción llega a los redo locales. Este modo se debiese usar cuando la red hacía la standby no es lo suficientemente óptima y se producen delays al momento de traspasar paquetes a través de TCP.



Se utiliza simultáneamente con RAC.



Se produce poca o ninguna pérdida de información según el modelo de protección elegida, en el intercambio y recuperación de errores.



La configuración y administración se simplifican con Data Guard Manager.

Genera recuperación de desastres siempre y cuando la base de datos de reserva se mantiene en una localización remota. Es flexible basado en que la base de datos de reserva podrían mandarse automáticamente o de forma manual mediante entradas de usuario y/o guiones. Al comparar con otras soluciones de alta disponibilidades las necesidades de ancho de banda son menos intensivas, debido a que sólo se propagan los archivos de registro guardados desde la base primaria a la que está en reserva. Pese a que puede configurarse para que los nodos locales funciones, no brinda la misma escalabilidad de los ORACLE RAC.De igual forma la aplicación de este sistema también puede generar ciertas desventajas como: 

El intercambio y recuperación de fallos, puede requerir de una cantidad de tiempo significativa en función al modo de protección elegido.



Según el ancho de banda disponible en la red se tendrá la frecuencia de la propagación. Se podría causar un excesivo tráfico en la red al exponer un entorno con un gran volumen de cambios en la base de datos debido a la cantidad de cambios propagados.



Para volver a la maquinaria original no hay un mecanismo fácil de vuelta atrás.



Al tener la base de datos de reserva abierta en modo de sólo de lectura, deberán sincronizar con la base de datos primarias ( a estos no pueden aplicarse los archivos de reconstrucción guardados).



Los datos no presentes en los registros de reconstrucción guardados, es quiere decir que no se propagan a la reserva.



La base de datos de reserva debe estar funcionando con el mismo hardware, versión SO y versión de DBMS que la base de datos principal.



No se puede crear un ambiente de contingencia o consolidación de información entre sistemas heterogéneos

5.1.3.3.

Factibilidad técnica

Siendo la base para el análisis Oracle 10G R2 Edición Estándar, se puede acotar que esta base de datos no trae integrada la aplicación de Oracle Data Guard , motivo por el cual este método podría resultar muy costoso. Tabla 11. Recursos técnicos para el análisis de factibilidad. RECURSOS TÉCNICOS PARA ANÁLISIS DE FACTIBILIDAD Tipo de recurso Humanos

Nombre del recurso Honorarios profesionales

Descripción Administrador de Base de Datos

Cantidad 1

Servidor 2 Pentium IV 2.0 GHz, Hardware 2 GB de RAM 120 Gb disco duro Centos Linux 5.5 Sistema operativo 2 Software Oracle 10g Enterprice Base de Datos 2 Edition Conclusión:Según los recursos técnicos que se requieren para la instalación, es factible técnicamente. Fuente: Investigación Directa Elaborado por: Dennys Peñaloza y Paúl Pabón Servidor (Requisitos mínimos)

El hardware necesario se lo puede considerar como básico ya que al ser una herramienta de oracle el sistema no necesita mayores recursos, por lo que no seria un problema. En cuanto a los conocimientos son suficientes

para el desarrollo y

ejecución de la implementación. Para una mejor explicación de lo que se ha descrito anteriormente, se muestra la siguiente tabla, detallando las características tanto de Hardware como de Software que se requieren para el desarrollo y funcionamiento del sistema:

5.1.3.4.

Factibilidad operativa

El Data Guard de Oracle en este caso no viene incluido en el paquete de la base de datos que se utiliza como base de este analisis ya que solo lo trae integrado en la versión Enterprice de Oracle. El Active Data Guard tiene un costo extra. Las ventajas son muchas y sería la herramienta perfecta para lograr la redundancia de datos si no tuviera un costo adicional, es así que operativamente si es factible. 5.1.3.5.

Factibilidad económica

Se presenta el presupuesto de costos aproximado de los recursos técnicos, humanos y materiales tanto para el desarrollo como para la implantación del sistema. Al existir elementos externos para la implantación de este método de replicación y no siendo funcional en su totalidad con las mismas herramientas de Oracle, hace necesaria la compra de la licencia del Software Active Data Guard de Oracle incurriendo en un costo por la licencia del software, más un extra anual por el soporte de $2.530,00 dólares. Posteriormente se describe los costos del recurso requerido para el desarrollo del Sistema de Información: Tabla 12. Recursos. Recursos Humanos Cargo Costo Individual Honorarios profesionales 1.200,00 Total Recursos Tecnológicos Hardware Cantidad Descripción Costo 2 Servidores 2.200,00 Total Software Cantidad Descripción Costo 1 Active Data Guard 11.500,00 1 Centos 5.5 0,00 Total Nº 1

Costo Total 1.200,00 1.200,00

Total 2.200,00 2.200,00 Costo Total 11.500,00 0,00 11.500,00

Recursos Materiales Descripción

Cantidad

Costo

1 Varios

Total 25,00

Total

25,00 25,00

Flujo de Pago Recursos Pago Recursos Humanos 1.200,00 Recursos Tecnológicos 13.700,00 Recursos Materiales 25,00 Imprevistos (10%) 1.492,50 Total 16.417,50 Fuente: Investigación Directa Elaborado por: Dennys Peñaloza y Paúl Pabón

Conclusión: Según los recursos económicos que se requieren para la adquisición e implementación son sumamente honerosos por tanto el proyecto no es factible económicamente. Cabe indicar que el costo de los servidores será de $2.200,00 sin embargo se podría aplicar la propuesta con un servidor clon que su costo será inferior y con iguales ventajas a diferencia que los servidores clon tienen una durabilidad de menor tiempo, esto ocasionaría incurrir en más gastos y perdidas de tiempo. 5.1.4. Replicación con Oracle Streams 5.1.4.1.

Introducción

Oracle Streams, constituye una tecnología para compartir información. Permite la difusión y administración de datos de las transacciones y sucesos en un flujo de datos ya sea dentro de una base de datos, o desde una base de datos a otra. Se basa en tres acciones aplicadas a la información, captura almacenamiento y consumo.

5.1.4.2.

Descripción del sistema

Oracle Streams viene a ser una opción que ya existe y que está incluido en la licencia estándar por lo que no tienen que pagar extra. Oracle Streams es una solución de replicación entre dos bases de datos de Oracle. Oracle Streams se puede configurar entre dos bases de datos Oracle, no importa en qué sistema operativo se encuentre la base de datos Oracle.

Redo Data Source Database

Logical Change Records not grouped into transactions

Redo Records Reader

Preparer

ms01

ms02…

Builder

Capture

ms0n

cp01

Capture at Source, Downstream, or Target Database

LCR LCR : Streams Pool

Propagation

cs01….

Apply at Target Database Target Database Datafiles

Applier

Transactions as02…. to be applied Conflict Detection Error Handling Custom Code

Coordinator

ap01 Committed

Reader

as01

LCR LCR : Streams Pool

transactions grouped and sorted in dependency order

Figura 12. Arquitectura de Oracle Streams. Elaborado por: McElroy, Patricia & Downing, Alan: Oracle Streams Development. 2011.

Para la replicación la captura se relaciona con un mecanismo que toma los cambios del Redo Log, que son los archivos que almacena todos los cambios aplicados a la base de datos en orden cronológico. El almacenamiento se vincula cuando los cambios capturados son enviados al área de almacenamiento, y estos cambios son propagados a las áreas de almacenamiento de los equipos remotos con replicas.

El consumo es la máquina que se encarga de aplicar los cambios almacenados a la base de datos en cada equipo con replicas. Existen diferentes tipos de Streams como: 

Asincrono: Que se lleva a cabo mediante procesos, ya que esta replicacion soporta la propagación mediante redo-log. Esto puede llevarse a cabo en Oracle Enterprse Editions.



Sincrono: Que se lleva a cabo mediante colas (queues). Esto puede hacerse en Oracle Estándar Editions.. Este tipo de replicación tiene sus limitantes, principalmente debe ser utilizada para aplicaciones en las cuales se necesite un flujo pequeño de información, ya que solo soporta la replicación de 1 o pocas tablas de un esquema determinado y solo replica cambios DML; los DDL no son soportados. Utiliza queues llamadas también colas que se encargan de capturar la replicación y encolarla hacia la otra base de datos, y viceversa.

Oracle Streams proporciona la propagación de datos entre un DBLink. La operación se puede controlar mejor que con Oracle vistas materializadas, que son otra opción para la replicación de datos entre bases de datos. 5.1.4.3.

Factibilidad Técnica

Debido a que es un procedimiento sencillo por no necesitar software adicional, sus costos son bajos y la necesidad de equipos potentes es innecesaria. En cuanto a los conocimientos son suficientes para el desarrollo y ejecución de la implementación. Para una mejor explicación de lo que se ha descrito anteriormente, se muestra la siguiente tabla, detallando las características tanto de Hardware como de Software

que se necesitan para el desarrollo y funcionamiento del sistema: Tabla 13. Recursos técnicos para el análisis de factibilidad.

RECURSOS TÉCNICOS PARA ANÁLISIS DE FACTIBILIDAD Tipo de recurso

Nombre del recurso

Humanos

Honorarios profesionales

Hardware

Servidor (Requisitos mínimos)

Software

Centos Linux 5.5 Oracle 10g R2

Descripción

Cantidad

Administrador de Base de Datos Servidor Pentium IV 2.0 GHz, 2 GB de RAM 120 Gb disco duro Sistema operativo Base de Datos

1 2

2 2

SLQ * Plus Conclusión:Según los recursos técnicos que se requieren para la instalación, el proyecto es factible técnicamente. Fuente: Investigación Directa Elaborado por: Dennys Peñaloza y Paúl Pabón

5.1.4.4.

Factibilidad Operativa

Se encuentra diseñada para compartir información, al tener el limitante de la versión Estándar de oracle limita al uso de la configuración síncrona reduciendo notablemente el campo de accion, motivo por el cual este método podría resultar útil pero limitado por la base de datos existente, es mucho mas funcional que el método de vistas materializadas. No factible operativamente por que es limitada para la versión Estándar de Oracle. 5.1.4.5.

Factibilidad Económica

Debido a que es un procedimiento sencillo por no necesitar software adicional, sus costos son bajos y la necesidad de equipos potentes es innecesaria, motivo por el cual este método podría resultar útil ya que se trabaja con herramientas propias de la base de datos.

Para una mejor visualización de lo que se ha descrito con anterioridad, se expone la siguiente tabla, detallando las características tanto de Hardware como de Software que se precisan para el desarrollo y funcionamiento del sistema: Tabla 14. Recursos.

Nº 1

Cantidad 2

Cantidad

Recursos Humanos Cargo Costo Individual Honorarios profesionales 1.200,00 Total Recursos Tecnológicos Hardware Descripción Costo Servidores 2.200,00 Total Software Descripción Costo 1 Centos 5.5 0,00 Total Recursos Materiales Descripción Costo 1 Varios 25,00 Total

Costo Total 1.200,00 1.200,00

Total 2.200,00 2.200,00 Costo Total 0,00 0,00 Total 25,00 25,00

Flujo de Pago Recursos Pago Recursos Humanos 1.200,00 Recursos Tecnológicos 2.200,00 Recursos Materiales 25,00 Imprevistos (10%) 342,50 Total 3.767,50 Fuente: Investigación Directa Elaborado por: Dennys Peñaloza y Paúl Pabón

Conclusión: Según los recursos económicos que se requieren para la adquisición e implementación, el proyecto es factible económicamente. 5.1.5. Oracle Golden Gate 5.1.5.1.

Introducción

Oracle Golden Gate optimiza el trabajo permitiendo tener acceso a la información en

tiempo real. Esto requiere de una plataforma que une la información de distintos sistemas en toda la empresa sin comprometer la disponibilidad y el rendimiento. Es una aplicación de software de alto rendimiento permitiendo que sus sistemas críticos esten en funcionamiento 24/7. 5.1.5.2.

Descripción del sistema

Oracle Golden Gate, opera en modo normal, leyendo de facto, la información de las bitácoras de la base de datos ( redologs online ), pero también lo puede hacer de los archivedlogs, si la data que debe ser capturada, no se encuentra disponible en los online logs. Golden Gate, toma ventaja de la administración de memoria a nivel del sistema operativo, para trabajar sostenida y eficientemente. Dentro de su caché, utiliza técnicas modernas para el uso virtual de la memoria.

Figura 13. Arquitectura de Oracle Golden Gates. Elaborado por: Ragogna, Marco. Data integration Solutions. Introducing Oracle Data Integrator and Oracle GoldenGate. 2013.

Oracle Golden Gate es una plataforma de Administración Transaccional de Datos (TDM). 

Captura los cambios transaccionales de una base de datos fuente leyendo el log

de transacciones de dicha base de datos. 

Envía y encola los cambios en discos locales o remotos, como una serie completamente independiente de archivos binarios.



Transforma (de manera opcional) los datos fuente.



Aplica las transacciones en cola hacia un destino, dicho destino puede ser una base de datos, un proveedor JMS, algún sistema de mensajería o alguna aplicación personalizada.



Oracle GoldenGate realiza la captura/transformación/aplicación en tiempo real a través de bases de datos heterogéneas y sistemas operativos.

Golden Gate, se utiliza para cuando se requiere consolidar información o replicar información de un conjunto de objetos de un esquema, o un usuario, en bases de datos Oracle en distintas plataformas y sistemas operativos y en bases de datos no Oracle. No tiene una interfaz gráfica propiamente dicha. Utilizar Golden Gate se limita a descomprimir los binarios en un directorio (por cada una de las bases de datos involucradas en el proceso) y configurar una serie de archivos de parámetros utilizando un editor de texto. A partir de ahí se arrancan una serie de procesos o servicios. La interfaz gráfica es un producto licenciado por separado por Oracle (mucho más barato que OGG). Se trata de Oracle ManagementPackforGoldenGate que nos proporciona una interfaz web muy completa sobre todos los aspectos de esta herramienta. Desde aquí podremos realizar la configuración, acceder a informes sobre tiempos, configurar alertas.

5.1.5.3.

Factibilidad Técnica

Oracle Golden Gate es una aplicación externa de Oracle que trabaja integrando datos y a su vez replicando la información, siendo esta herramienta adaptable a muchas topologías, de la misma manera es un software propietario. En cuanto a los conocimientos son suficientes para el desarrollo y ejecución de la implementación. Para una visualización exacta, se expone en la siguiente tabla las características tanto de Hardware como de Software en el desarrollo y funcionamiento del sistema:

Tabla 15. Recursos técnicos para el análisis de factibilidad. RECURSOS TÉCNICOS PARA ANÁLISIS DE FACTIBILIDAD Tipo de recurso

Nombre del recurso

Humanos

Honorarios profesionales

Hardware

Servidor (Requisitos mínimos)

Descripción

Cantidad

Administrador de Base de Datos

Servidor Pentium IV 2.0 GHz, 2 GB de RAM 120 Gb disco duro Sistema operativo Base de Datos Edicion Estándar

Centos Linux 5.5 2 Oracle 10g R2 2 Software SLQ * Plus Oracle Golden Gate Software integrador Conclusión:Según los recursos técnicos que se requieren para la instalación,el proyecto es factible técnicamente. Fuente: Investigación Directa Elaborado por: Dennys Peñaloza y Paúl Pabón

5.1.5.4.

Factibilidad Operativa

No trae interfaz para interactuar con el sistema y la que existe hay que comprarla por separado, esta aplicación esta desarrollada para un flujo de datos bastante grande y se acopla a una gran cantidad de topologías. Es una herramienta de pago que sirve perfectamente para la replicación, es necesario efectuar una capacitación para el manejo de la herramienta. No es factible en base a que es una herramienta que tiene

múltiples aplicaciones. 5.1.5.5.

Factibilidad Económica

Se especifica el presupuesto de costos aproximados que se debe recurrir para cubrir los recursos técnicos, humanos y materiales tanto para el desarrollo como para la implantación del Sistema. Se exponen los costos de los recursos necesarios para el desarrollo de este Sistema de Información:

Tabla 16. Recursos. Recursos Humanos Cargo Costo Individual Honorarios profesionales 1.200,00 Total Recursos Tecnológicos Hardware Cantidad Descripción Costo 2 Servidores 2.200,00 Total Software Cantidad Descripción Costo 1 GoldenGatefor Oracle Applications 7.000,00 1 Management Pack for Oracle GoldenGate 3.500,00 Total Recursos Materiales Cantidad Descripción Costo 1 Varios 25,00 Total Nº 1

Costo Total 1.200,00 1.200,00

Total 2.200,00 2.200,00 Costo Total 7.000,00 3.500,00 10.500,00 Total 25,00 0,00

Flujo de Pago Recursos Pago Recursos Humanos 1.200,00 Recursos Tecnológicos 12.700,00 Recursos Materiales 25,00 Imprevistos (10%) 1.392,50 Total 15.317,50 Fuente: Investigación Directa Elaborado por: Dennys Peñaloza y Paúl Pabón

Al existir elementos externos para la implantación de este método de replicación y no siendo funcional en su totalidad con las mismas herramientas de Oracle, hace necesaria la compra de la licencia del Software Golden Gate de Oracle incurriendo

en un costo por la licencia del software más un extra por la aplicación de la interface llamada Management Pack for Oracle GoldenGate. Conclusión: Según los recursos económicos que se requieren para la adquisición e implementación, el proyecto no es factible económicamente. 5.1.6. Espejo Redundante con Scripts 5.1.6.1.

Introducción

La propuesta consiste en una base de datos Oracle en Sandy que viene a ser una copia cabal de una base de datos operativa en un servidor remoto, que se usa como backup, copia para consulta, recuperación de desastres, etc. Se considera que una base de datos en modo Sandy va más allá que un backup normal, debido a que coloca en producción en caso de catástrofe en menor tiempo que si se debiera restaurar una copia (ya sea desde RMAN o un simple export). Restablecer una copia desde fichero puede ser tardado y en ese tiempo el sistema no está disponible. Por lo que, con una base de datos adicional en modo standby no hay nada (o casi nada que restaurar) en caso de desastre, ya que en pocos minutos se hace el cambio permitiendo continuidad en el servicio. Sin embargo, esto no ofrece las ventajas de rendimiento de un clúster o la seguridad del Data Guard pero la relación entre el costo de tiempo, licencia y las ventajas que presenta son superiores. 5.1.6.2.

Descripción del sistema

Como se observó en el marco teórico, la solución de la base de datos oficial de Oracle es Oracle Data Guard, sin embargo, sólo está disponible como una opción con

la versión Enterprise Edition de Oracle. Debido a que se maneja una base de datos Standard Edition y se prefiere evitar el pago de la licencia de Enterprise Edition se ha buscado una solución. Los servidores de base de datos que se presentan se los llamará entre sí como: primario.pucesd

y secundario.pucesd. El nodo primario.pucesd es el principal,

mismo que sirve la información y archivelog repitiendo esto en la base de datos standby. De esta manera, se puede encontrar o determinar la forma para lograr esto de una forma manual. El método actual es muy similar, y sin Data Guard, la única manera de tener un resultado similar es el uso de un proceso continuo de recuperación de base de datos. 5.1.6.3.

Factibilidad Técnica

La replicación mediante scripts y herramientas de oracle y Linux surge de la necesidad de encontrar una manera de generar respaldos de la información y no tener que respaldar toda la base de datos como una práctica usual. En cuanto a los conocimientos son suficientes para el desarrollo y ejecución de la implementación. Para una mejor explicación de lo que se ha descrito anteriormente, se muestra la siguiente tabla, detallando las características tanto de Hardware como de Software que se necesitan para el desarrollo y funcionamiento del sistema:

Tabla 17. Recursos técnicos para el análisis de factibilidad. RECURSOS TÉCNICOS PARA ANÁLISIS DE FACTIBILIDAD Tipo de recurso

Nombre del recurso

Humanos

Honorarios profesionales

Hardware

Servidor (Requisitos mínimos)

Descripción Administrador de Base de Datos Servidor Pentium IV 2.0 GHz, 4 GB de RAM 120 Gb disco duro Sistema operativo Base de Datos Edicion Estándar

Cantidad 1 2

Centos Linux 5.5 2 Oracle 10g R2 2 SLQ * Plus Conclusión:Según los recursos técnicos que se requieren para la instalación por tal razón, el proyecto es factible técnicamente. Software

Fuente: Investigación Directa Elaborado por: Dennys Peñaloza y Paúl Pabón

5.1.6.4.

Factibilidad Operativa

Este sistema se encuentra desarrollada con aplicaciones incluidas tanto en la versión del sistema operativo como en la base de datos más unos scripts que emula en su mayoría a las demás aplicaciones de replicacion. Para poder manejar este sistema no existe la necesidad de tener conocimientos avanzados en el tema pudiéndose implementar la solución sin requerir de grandes máquinas multiprocesos lo que la hace una aplicación muy efectiva al momento de cumplir con el cometido de respaldar la información, por tanto operativamente si es factible. 5.1.6.5.

Factibilidad Económica

Se expone el presupuesto de costos aproximado de los recursos técnicos, humanos y materiales ya sea en el desarrollo y la implantación del sistema. Siendo una aplicación basada en herramientas incluidas en la base de datos y sistema operativo la sitúa en una posición de preferencia por su bajo costo y buenas funcionalidades. Así, se describe los costos del recurso necesario para el desarrollo

de nuestro Sistema de Información: Tabla 18. Recursos. Recursos Humanos Nº 1

Cantidad 2

Cargo

Costo Individual 1.200,00 Total

Honorarios profesionales Recursos Tecnológicos Hardware Descripción Servidores

Software Descripción

Cantidad 1 Centos 5.5

Cantidad

Recursos Materiales Descripción

Flujo de Pago Recursos Pago Recursos Humanos Recursos Tecnológicos Recursos Materiales Imprevistos (10%) Total Fuente: Investigación Directa Elaborado por: Dennys Peñaloza y Paúl Pabón

Costo Total 1.200,00 1.200,00

Costo 2.200,00 Total

Total 2.200,00 2.200,00

Costo 0,00 Total

Costo Total 0,00 0,00

Costo 25,00 Total

Total 25,00 25,00

1.200,00 2.200,00 25,00 342,50 3767,50

5.1.7. Análisis Comparativo de Factibilidad Se ha analizado las diferentes soluciones de la problemática investigada y se han identificado seis opciones que son las más prácticas y adecuadas, algunas de éstas han sido desarrolladas por empresas ajenas a Oracle, otras como soluciones integrantes de las versiones Enterprise de Oracle; y las otras propuestas encontradas en el internet. Básicamente las soluciones expuestan fueron:



SharePlex.



Data Guard de Oracle.



Espejo redundante con Scripts



Vistas materializadas



Oracle Streams



Oracle Golden Gate



Espejo Redundante con Scripts

Una vez expuestas las distintas técnicas de replicación, se presenta a continuación un análisis en forma comparativa entre los distintos métodos antes presentados. Este análisis permitirá establecer las diferencias entre los distintos programas y métodos que conduzcan a conclusiones objetivas. En el análisis comparativo se consideran las situaciones planeadas y no planeadas que pueden derivar en una catástrofe para la información. Dentro de las interrupciones no planeadas se expone para el análisis la falla de las computadoras, fallas de almacenamiento, errores humanos, corrupción de datos y fallas en el sitio; para las interrupciones planeadas, están el cambio de datos y cambios en el sistema.

Tabla 19. Matriz Comparativo de las Factibilidades.

SISTEMAS Vistas Materializadas SharePlex

TÉCNICA

OPERATIVA

ECONÓMICA

Oracle Data Guard

Oracle Streams

Oracle Golden Gate Si Replicación con Si Scripts Fuente: Investigación Directa Elaborado por: Dennys Peñaloza y Paúl Pabón

Tabla 20. Matriz Comparativa de Respuesta para Interrupciones no Planificadas. Vistas SharePle materializa x das

Tipo de interrupcion Fallas de las computadoras Fallas de almacenamiento Errores humanos Corrupción de datos Fallas en el sitio

Oracle Data Guard

Oracle Streams

Oracle Replicacion Golden Gate con Scripts x

Fuente: Investigación Directa Elaborado por: Dennys Peñaloza y Paúl Pabón

Tabla 21. Matriz Comparativa de Respuesta para Interrupciones Planificadas.

Tipo

interrupcion Operaciones de rutina Actualizaciones en el sistema

Oracle

Vistas

SharePle

materializadas

Data Guard

Oracle

Replicacion

Streams Golden Gate con Scripts

Fuente: Investigación Directa Elaborado por: Dennys Peñaloza y Paúl Pabón

A su vez que se ha sondeado y observado en distintas instituciones públicas y privadas obteniendo como resultado que la mayoría de ellas no están preparadas para

una contingencia en caso de catástrofes o pérdida de datos, el método más común de respaldar la información es efectuando un backup de toda la base de datos al terminar la jornada de trabajo, siendo vulnerables a posibles fallos en horas laborables. Tabla 22. Cuadro Comparativo. Cuadro Comparativo Sistemas Ventajas Desventajas Incremento en el tamaño de la base de Replica de manera sencilla datos Vistas Incrementan la seguridad de los datos Posible Falta de sincronia Materializadas Mejora rendimiento de consultas Necesitan de operaciones de refresco Costo Proporciona copias en tiempo real de los Las bases de datos origen y destino datos de producción tendrán que emplear la misma versión de SharePlex. Instalacionrapida y facil SharePlex Solución liviana en uso de recursos

Oracle Guard

Costo Se produce poca o ninguna pérdida de Podría causar un excesivo tráfico en la información red Las necesidades de ancho de banda son menos intensivas La base de datos de reserva debe estar funcionando con el mismo hardware, Data Puede ser utilizado conjuntamente con versión SO y versión de DBMS que la base de datos principal RAC Permite nativas

Oracle Streams

No se puede replicar algunos componentes que se utilizan en Oracle

soluciones

nativas

Está incluido en la licencia Estándar

Integracion de datos en tiempo real Oracle Golden Integridad de los datos Gate Permite encriptar y comprimir los datos cuando es necesario Costo Se produce poca o ninguna pérdida de información Replicacion con Scripts Incrementan la seguridad de los datos Solución liviana en uso de recursos Economia en el uso de la base de datos Fuente: Investigación Directa Elaborado por: Dennys Peñaloza y Paúl Pabón

Disponible con la version Enterprice Costo Necesita más trabajo de mantenimiento Existen tipo de datos que la aplicación esta utilizando que no se pueden propagar Costo No ofrece la seguridad de ODG No ofrece las ventajas de rendimiento de un RAC

Después de analizar las herramientas estudiadas para replicación se ha podido establecer el siguiente cuadro en el cual constan las ventajas y desventajas de cada sistema.

5.2.

REQUISITOS PARA LA IMPLEMENTACIÓN DE UN SERVIDOR ESPEJO REDUNDANTE

Los requerimientos mínimos para que se pueda implementar son: 

Un servidor con procesador Dual Core con memoria RAM mínima de 4 Gb, unidad de disco duro de 500 Gb, una tarjeta de red Ethernet y una unidad de DVD-ROM.



Conexión a la red de forma permanente.



Generar los permisos en el servidor de producción para una conexión SSH.



Información de la Estructura del Sistema de Backup de Base de Datos.



Procedimiento para restauración del Servidor de Base de Datos en caso de fallos.



Plataforma del Sistema Operativo y Base de Datos.

5.3.

Desarrollo de la Propuesta

5.3.1. Diseño A continuación se detalla el diseño del presente proyecto, mismo que consiste en instalar un servidor redundante a otro y la manera en cómo se ejecutara su correspondiente configuración.



Se dispone de una copia de la base de datos de forma remota, que se puede contabilizar como segundo juego de copias.



La copia se mantiene viva y los datos son actualizados con mayor frecuencia, lo que no sucede con un simple backup,.



Si se presentase una catástrofe, se puede usar de forma inmediata en minutos sin esperar siquiera a restaurar un backup entero, ya sea lógico (export) o físico (RMAN).



En la prueba de parches y estimación de tiempos sirve como entorno de pruebas más real. El volumen de datos es el mismo.

Desarrollando un análisis a nivel técnico se puede exponer lo que se expone a continuación: 

Se captura en los archivos redo log los cambios de la base de datos principal.



Los archivos de redo son transitorios, se sobrescriben de forma rotativa (en este estado aún no se copia al segundo servidor).



Se efectúa una copia del redo log. La copia permanente se llama archive log.



Los archive logs (copias de redo log) se transfieren al servidor en standby. En sistemas Linux, se lo hace por medio de rsync.



Se emplean los archive logs transferidos a la base de datos en standby y se van actualizando.

En general los pasos que se deben seguir para montar el sistema son los que se

exponen a continuación: 

Configurar la base de datos principal para que funcione en modo archivelog.



Preparar un script para hacer una copia en caliente (usando RMAN).



Crear un fichero de control standby (control file) en la base de datos principal.



Copiarlo todo (fichero de configuración, de control y copia RMAN) en el segundo servidor (donde montamos la base de datos en standby).



Reconfigurar rutas .



Iniciar la segunda base de datos en modo standby.



Restaurar datos (recover Database ).



Sincronizar de forma periódica (cron) transportando (rsync) y aplicando los archive logs.

5.3.2. Implementación La redundancia es uno de los pasos para lograr una alta disponibilidad en los servicios y tiene que ver directamente con mantener siempre un duplicado de la información en algún lugar distinto a la locación primaria para que en caso de un error humano, de software o cualquier otro tipo de problema y que el DBA tenga la facilidad de reponer la información inmediatamente. En este caso se tiene un nodo principal el cual tendrá instalado Centos versión 5.5 como sistema operativo y

Oracle 10g release 2 como base de datos, el nodo

secundario estará configurado de la misma manera y estará en Standby copiando la

información que se almacena en el nodo principal mediante una conexión SSH la cual siempre tendrá que estar disponible, el proceso lo realizara automáticamente en un periodo de tiempo determinado a conveniencia del DBA, cabe destacar que este método es similar a la función del Oracle 10g Enterprice Edition llamada Data Guard que genera copias automáticas. Se apoyará de los archivos del Oracle conocidos como Redo Log o ficheros del Registro de Rehacer los cuales registran las variaciones efectuadas y generalmente se los usa para realizar operaciones de recuperación. El nodo redundante no necesita ser una máquina con alta complejidad ya que este no realizará operaciones distintas a las de copiar la información del nodo primario, sin embargose podría definir los requisitos mínimos, estos se encuentran detallados en la siguiente tabla: Tabla 23. Información del nodo primario.

Procesador Dual core Memoria RAM mínima de 4GB Unidad de disco duro de 500 GB Tarjeta de red Ethernet Unidad de DVD-ROM (para instalación) Elaborado por: Investigación Directa

El software que va a ser utilizado en los dos nodos consta en la tabla que se expone a continuación:

Tabla 24. Tipos de nodos y herramientas utilizadas. TIPO DE NODO

HERRAMIENTAS UTILIZADAS Sistema Operativo Linux Centos 5.5.

Nodo Primario Oracle Database 10g release 2 Sistema Operativo Linux Cantos 5.5. Nodo Secundario Oracle Database 10g release 2 Elaborado por: Dennys Peñaloza y Paúl Pabón

5.3.3. Guía de instalación de Oracle 10 g sobre Centos 5.5 Esta guía está dirigida para llevar a cabo la instalación del software Oracle 10g sobre la plataforma de Centos Linux 5.5. Para la correcta instalación del Oracle 10g se deben seguir los siguientes pasos: 

Preparación del sistema.



Prerrequisitos del sistema.



Configuración del sistema.

5.3.3.1.

Preparación del sistema

Para una adecuada instalación asegúrese de tener instalados los siguientes paquetes: 

yuminstallcompat-libstdc*



yum install compat-libstdc* elfutils-libelf*



yum install compat-libstdc* glibc-devel*



yum install compat-libstdc* gcc* gcc-c*



yum install compat-libstdc* libaio*



yum install compat-libstdc* libstdc++*



yum install compat-libstdc* unixODBC*



yum install compat-libstdc* unixODBC-*



yum install compat-libstdc* sysstat*



yum install compat-libstdc* elfutils-libelf-devel*



yum install compat-libstdc* glibc-devel-2*



yum install compat-libstdc* glibc-headers-2*



yum install compat-libstdc* gcc-4*



yum install compat-libstdc* libgomp-4*



yum install compat-libstdc* gcc-c++-4*



yum install compat-libstdc* libstdc++-devel-4*



yum install compat-libstdc* install compat-libstdc++-33*



yum install compat-libstdc* libaio-devel* sysstat* unixODBC*



yum install compat-libstdc* libXp-1.0.0-8.i386.rpm jav*



yum install compat-libstdc* libX* libx*

5.3.3.2.

Prerrequisitos del sistema

La documentación de Oracle dice que el sistema debe tener 512 Mb mínimo de RAM y 1 Gb de swap o el doble de RAM. En sistemas con 2 o más GB de RAM, la partición de intercambio puede ser entre una y dos veces el tamaño de la RAM. Siendo realistas 512 MB es el mínimo para poder arrancar el sistema, no para trabajar con el Oracle. Se verifica memoria RAM. grepMemTotal/proc/meminfo

Se verifica la memoria Swap. grepSwapTotal/proc/meminfo

El espacio en disco recomendable debe ser mayor a 4 GB, repartiendo de la siguiente manera: Tabla 25. Espacio recomendado en disco. Espacio en /tmp para el Oracle Universal Installer

400 Mb

Ficheros de instalación

1,5 Gb

Productos opcionales de Oracle Database 10g que vienen en el Companion CD Ficheros de una base de datos

1 Gb 1.2 Gb Total 4.1 Gb

Elaborado por: Investigación Directa

Para verificar el espacio disponible: df – k / 5.3.4. Ajustando límites del Kernel Revisando la configuración del sistema:

/sbin/sysctl–a|grepsem Kernel.sem = 250

32.000

128

/sbin/sysctl –a|grepshm Vm.hugetlb_shm_group = 0 Kernel.shmmni = 4096 Kernel.shmall = 2097152 Kernel.shmmax = 2147483648 /sbin/sysctl –a grep file-max Fs.file-max = 65536 /sbin/sysctl –a|grepip_locl_port_range Net.ipv4.ip_local_port_range = 1024

65000

Si algún valor es diferente entonces se envía /etc/sysctl.conf Kernel.shmall=2097152 Kernel.shmmax=2147483648 Kernel.shmmni=4096 Kernel.sem= 250 Fs.file-max=65536

32000 100

128

Net.ipv4.ip_local_port_range=1024 65000 Para aplicar los cambios se reinicia el sistema en todo caso se da la siguiente orden para que se aplique directamente. /sbin/sysctl-p Luego se verifica los límites de la Shell con: Ultimi -a Se edita /etc/security/limits.confo y se le agrega los siguientes valores. soft

nproc 2047

hard

nproc 16384

soft

nofile 1024

hard

nofile 65536

Se agrega la siguiente línea a /etc/pam.d/login Sesión required /lib/security/pam.limits.so 5.3.5. Directorios y permisos Crear usuario (Oracle) y los siguientes grupos: 

oinstall: propietario de los archivos Oracle. Este grupo se usa para la instalación del software.



dba: grupo de usuarios con privilegios de SYSDBA.

100

Si se está configurando en una instalación limpia obviamente no existen dichos grupos excepto por nobody, así que es mejor comprobar si existen los grupos: 



Se verifica los grupos: o

grep oinstall /etc/group

grep dba /etc/group

grep nobody/etc/group

Se verifica los usuarios: o

id Oracle

id nobody

Si no existen es preciso que se los creen: 



Creando grupos o

groupaddoinstall

groupadddba

Creando usuarios o

useradd -c “Propietario del sw de Oracle” -g oinstall -G dba -p Oracle -d /home/Oracle -s /bin/bashoracle

Se crea los directorios base de Oracle (/u01/app/oracle/oradata) o

mkdir -p /u01/add/oracle

101

mkdir -p /u02/oradata

chown -R Oracle:oinstall /u01 /u02

chown -R 777 /u01 /u02 El parámetro mkdir p crea los directorios padre de oradata en caso de que no existan. El parámetro chown R asigna propietario a los archivos y directorios recursivamente.

Se verifica que exista el directorio /home/Oracle, de no existir se debe hacer lo siguiente: 

Crear el directorio oracle y copiar los archivos.bashc y .bash_profile.



Después asignar propietario y permisos

Crear el directorio /home/oracle o

mkdir -p /home/oracle

cp /home/otroususario/.ba*/home/oracle

chown -R oracle:oinstall /home/oracle

chmod -R 777/home/oracle

Hacer login con el usuario oracle su oracle

102

Se descomenta o agrega la siguiente lĂnea del archivo /home/oracle/.bash_profile umask 022. Posteriormente se crean los siguientes directorios: o

mkdir -p /home/Oracle/config/ 10.2.0

mkdir /var/lock/subsys

Se agrega las siguientes variables de entorno del archivo /home/oracle/.bashrc. o

exportORACLE_BASE=/U01/app/oracle

export ORACLE_HOME=/U01/app/oracle/product/10.2.0/db_1

exportORACLE_SID=orcl

export ORACLE_TERM=xterm

exportORACLE_OWNER=oracle

export NLS_LANG=SPANISH_SPAIN.WE81SO8859PI;

export CLASSPATH=${ORACLE_HOME}/jdbc/lib/classes12.zip

export LD_LIBRARY_PART=${ORACLE_HOME}/lib

exportDISABLE_HUGETLBFS=1

exportTEMP=/tmp

exportTMPDIR=/tmp

export PATH_$PATH:/U01/app/oracle/product/10.2.0/db_1/bin

103

En la variable ORACLE_SID especifica el nombre de la Base de Datos, en este caso es: orcl. En este punto se está listo para iniciar la instalación. Se debe dirigir donde se encuentra el instalador de Oracle 10 g “database” y ejecuta el runInstaller. El instalador solo se ejecuta en sistema operativos certificados, para saber cuales, puede ver el archivo/database/install/oraparam.ini (Linux=redhat2.1.UnitedLinux 1.0.redgat3). por eso es preciso que no se ignore los prerequisitos: ./runInstaller ignoreSysPrereqs Luego de unos segundos aparecerá el Wizard de instalación de Oracle 10 g.

5.3.6. Pantallas Se presentan por tanto las pantallas que aparecerán en el momento en que el sistema propuesto se pruebe para la verificacion de un correcto funcionamiento. Bienvenidos: Se presenta la pantalla que aparece dando la bienvenida:

Figura 14. Bienvenido. Elaborado por: Dennys Peñaloza y Paúl Pabón

104



Especificar directorio de inventario y credenciales

Ruta de acceso = /u01/app/oracle/oraInventory

Nombre de grupo = oinstall

Figura 15. Directorio y Credenciales. Elaborado por: Dennys Peñaloza y Paúl Pabón



Selección tipo de instalación: o

Enterprise edition (1.26 GB)

Figura 16. Seleccionar tipo de instalación. Elaborado por: Dennys Peñaloza y Paúl Pabón

105



Especificar detalles del directorio raíz o

Destino

Nombre = OraDb10g_home1

Ruta de acceso = /u01/app/oracle/product/10.2.0/db_1

Comprobación de requisitos específicos del producto

Figura 17. Comprobantes de requisitos específicos del producto. Elaborado por: Dennys Peñaloza y Paúl Pabón



Seleccionar opción de configuración o

Crear base de datos

Figura 18. Configuración. Elaborado por: Dennys Peñaloza y Paúl Pabón

106



Selección configuración de base de datos o

Uso general

Figura 19. Selección de configuración. Elaborado por: Dennys Peñaloza y Paúl Pabón



Especificar opciones de configuración de Base de Datos o

Nombre y SID = orcl

Europeo Occidental WE8ISO8859P1

Crear base de datos con esquema de ejemplo

Figura 20. Especificación de opciones de configuración. Elaborado por: Dennys Peñaloza y Paúl Pabón

107



Seleccionar opciones de gestión de Base de Datos o

Usar DataBase control para gestión de Base de Datos

Figura 21. Instalar. Elaborado por: Dennys Peñaloza y Paúl Pabón



Especificación opción de almacenamiento de Base de Datos

Sistema de archivos

Especificar ubicación de un archivo de Base de Datos = /u02/oradata

Figura 22. Opciones de almacenamiento. Elaborado por: Dennys Peñaloza y Paúl Pabón

108



Especificar opciones de copia de seguridad y recuperación

No activar copias de seguridad automáticas

Figura 23. Opciones de copia de seguridad y recuperación. Elaborado por: Dennys Peñaloza y Paúl Pabón



Especificar contraseña de esquema de Base de Datos o

Usar la misma contraseña para todas las cuentas = oracle

Figura 24. Especificar contraseñas de esquema de base de datos. Elaborado por: Dennys Peñaloza y Paúl Pabón

109



Resumen o

Instalar

Figura 25. Resumen. Elaborado por: Dennys Peñaloza y Paúl Pabón



Asistente de configuración de Base de Datos o

Aceptar

Figura 26. Asistentes de configuración. Elaborado por: Dennys Peñaloza y Paúl Pabón

110

Figura 27. Asistente de configuración de base de datos 01. Elaborado por: Dennys Peñaloza y Paúl Pabón

Figura 28. Asistente de configuración de base de datos 02. Elaborado por: Dennys Peñaloza y Paúl Pabón



Ejecutar archivos de comandos de configuración

Figura 29. Ejecutar archivos de comandos de configuración. Elaborado por: Dennys Peñaloza y Paúl Pabón

111

Figura 30. Fin de instalación. Elaborado por: Dennys Peñaloza y Paúl Pabón

Figura 31. Salir. Elaborado por: Dennys Peñaloza y Paúl Pabón

5.3.7. Configurando archivo hosts Se Verificara que el archivo hosts en la ruta /etc. debe lucir como se muestra a continuación:

Figura 32. Root@primario: 01. Elaborado por: Dennys Peñaloza y Paúl Pabón

112

Resetear la red del equipo con el comando /etc/init.d/network restart Verificar la ip y el hostname con los comandos respectivos como se muestra a continuación:

Figura 33. Root@primario:.02. Elaborado por: Dennys Peñaloza y Paúl Pabón

Añadir la ip del host secundario en el archivo /etc/host como se muestra a continuación:

Figura 34. Root@primario: 03. Elaborado por: Dennys Peñaloza y Paúl Pabón

Una vez configurado los hosts se procede a la configuración del nodo primario en modo archivelog ejecutando los siguientes comandos: Startup mount

113

alter system set log_archive_dest_1='LOCATION=/home/oracle/arch' scope=both; alter system set log_archive_format='arch%t_%s_%r.dbf' scope=spfile;

Crear la ruta a la que se direcciona los archives: cd /home/oracle/ mkdir arch

Una vez hecho eso colocar la base de datos en modo archivelog usando los pasos que se detalla a continuaci贸n:

shutdown immediate startup mount alter database archivelog; alter database open; archive log list;

114

Generar un archive para verificar la generaciĂłn de archivos: alter system switch logfile;

Como se ve se estĂĄn generando archives en la grĂĄfica se tenĂan dos, pero luego se pudieron observar 3. Posterior a esto forzar el loggin en la base primaria como se muestra: alter Database force logging

Una vez hecho esto apagar los servicios de la base de datos y duplicar la base de datos para generar el sitio standby o secundario.

115

Para apagar los servicios usar: lsnrctl stop sqlplus / as sysdba shutdown immediate; Una vez duplicada la base de datos que servirá como sistema standby cambiarle el nombre y a continuación prenderla para hacer los siguientes cambios. Verificar que la configuración de red de la nueva máquina tenga la ip y nombre de equipo correctos:

Figura 35. Ethernet Device. Elaborado por: Dennys Peñaloza y Paúl Pabón

116

Figura 36. Network configuración. Elaborado por: Dennys Peñaloza y Paúl Pabón

Verificar vía línea de comando:

Configurar el parámetro standby_archive_dest

117

sqlplus / as sysdba startup nomount alter system set standby_archive_dest='/home/oracle/arch1'; shutdown immediate;

Prender la mĂĄquina primaria y copiar el control file en la mĂĄquina secundaria previo a levantar la base de datos asĂ: startup mount; alter database create standby controlfile as '/home/oracle/controlstandby.ctl';

118

Enviar el archive de control al equipo secundario: scp controlstandby.ctl oracle@10.10.0.71:/home/oracle/

Levantar la base de datos en modo mount standby Database asĂ pero primero ubicar el control file standby: sqlplus / as sysdba create pfile from spfile; exit cd $ORACLE_HOME/dbs vi initorcl.ora

119

Luego cambiar el parรกmetro control_files como se muestra:

Una vez hecho esto recrear el spfile y montar la base de datos en modo standby como se muestra: sqlplus / as sysdba create spfile from pfile; startup nomount; alter database mount standby database

120

Ir a la ruta de generaciรณn de archives en el sitio primario para generar mรกs archives y probar el funcionamiento como se verรก a continuaciรณn se generan mรกs archives con el comando alter system switch logfile alter system switch logfile;

121

Pasar los archivos al equipo secundario: scp *.dbf oracle@10.10.0.71:/home/oracle/arch/

Una vez hecho esto verificar en el stio secundario:

Como se puede observar los archivos pasaron ahora aplicar los cambios: cp *.dbf /home/oracle/arch1/ sqlplus / as sysdba

alter database recover managed standby database disconnect from session;

Mediante el comando archive_lag_target limitamos la cantidad dedatos que pueden ser perdidos y asĂ aumentamos eficazmentela disponibilidad de la base de datos en espera al forzar un cambio de log despuĂŠs de la cantidad de tiempo especificado. alter system set archive_lag_target=120 scope=both;

122

5.3.8. Configuración de Scripts para intercambio de archives usando Rsyng Configurando script_rsyng.sh nodo primario #!/bin/bash INICIO=`date +%d/%m/%Y-%H:%M:%S` LOG=/home/oracle/archrsyng/`date +%Y-%m-%d`_rsync.txt echo " " >> $LOG echo " " >> $LOG echo "|-----------------------------------------------" >> $LOG echo " Sincronización iniciada en $INICIO" >> $LOG rsync ssh -Cravzp /home/oracle/arch/ oracle@10.10.0.71:/home/oracle/arch/ >> $LOG FINAL=`date +%d/%m/%Y-%H:%M:%S` echo " Sincronización Finalizada en $FINAL" >> $LOG echo "|-----------------------------------------------" >> $LOG echo " " >> $LOG echo " " >> $LOG

5.3.9. Configurando crontab nodo primario Una vez que la bd principal genera el archivo de recuperación es necesario pasarlos al otro servidor que estará funcionando en modo standby. Para este procedimiento se utilizará la herramienta cron de la siguiente manera para q se ejecute cada 20 veinte minutos ya q nuestra base de datos principal está configurada para que los cree cada veinte minutos. */20 * * * * /home/oracle/script_rsyng.sh

123

5.3.10. Configurando script.sh nodo secundario Inicio() { CURYEAR=`ls /home/oracle/arch -Art | tail -n 1` export CURYEAR } ForceRemoteLogSwitch() { sqlplus -s "/ as sysdba" << EOF ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; SHUTDOWN IMMEDIATE; STARTUP NOMOUNT; ALTER DATABASE MOUNT STANDBY DATABASE; ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; exit EOF } CreateSqlRecoverScript() { echo "connect target sys/oracle" > arc.rma echo "run" >> arc.rma

124

echo "catalog archivelog '/home/oracle/arch/${CURYEAR}';" >> arc.rma echo "}" >> arc.rma echo "exit;" >> arc.rma } CURYEAR=FALSE Inicio if [ ! "$CURYEAR" = "FALSE" ] then echo "-------------------------------" echo "Preparando Base de Datos" echo "-------------------------------" ForceRemoteLogSwitch echo "-------------------------------" echo "Generando Archivo" echo "-------------------------------" CreateSqlRecoverScript "${CURYEAR}" echo "-------------------------------" echo "Catalogando" echo "-------------------------------" rman @arc.rma echo "listo" fi

125

5.3.11. Configurando crontab nodo secundario para script.sh */20 * * * * /home/oracle/script.sh

5.3.11.1.

Configuración Equivalencia SSH

Se genera claves en cada nodo $ cd $ mkdir .ssh $ chmod 700 ~/.ssh $ /usr/bin/ssh-keygen -t rsa

Figura 37. Oracle@primario: 01. Elaborado por: Dennys Peñaloza y Paúl Pabón

Se crea el archivo authorized_keys desde el archivo de claves públicas

126

Figura 38. Oracle@primario: 02. Elaborado por: Dennys Peñaloza y Paúl Pabón

Como resultado se tiene la creación de tres archivos donde el archivo authorized_keys será copiado al nodo secundario asegurándose primero que existe el directorio en dicho nodo.

Figura 39. Oracle@primario: 03. Elaborado por: Dennys Peñaloza y Paúl Pabón

En la pregunta sobre aceptar las claves RSA se escribe“YES”, se agregara al nodo remoto en el archivo local known_hosts y si no existe se generara automáticamente. Se logea al nodo secundario

Figura 40. Oracle@secundario: 01. Elaborado por: Dennys Peñaloza y Paúl Pabón

127

Se agrega la clave pública local para el archivo de claves autorizadas

Figura 41. Oracle@secundario: 02. Elaborado por: Dennys Peñaloza y Paúl Pabón

128

CONCLUSIONES Y RECOMENDACIONES

CONCLUSIONES 

Mediante el análisis de diferentes herramientas se pudo determinar que el Espejo Redundante con Scripts es factible en lo técnico, operativo y económico para la implementación en la Pontificia Universidad Católica Sede Santo Domingo; debido a su bajo costo y a las diferentes ventajas que ofrece.



Existe una gran cantidad de tecnología a nivel de información que pueden emplearse en los entornos empresariales sobre todo en las aplicaciones denominadas de misión crítica que pudieran tener una disponibilidad inmediata.



La conectividad permanente es relevante para una gran cantidad de empresas y una interrupción planeada o no planeada genera pérdidas tanto de información como a nivel económico.



En la actualidad se puede contar con una inmensa variedad de software libre de tal forma que se eviten costos para las diferentes empresas y presentan la misma confiabilidad.



El empleo de técnicas de replicación se están extendiendo de manera vertiginosa tanto para una conectividad permanente como una seguridad en su base de datos.



Ninguna empresa puede garantizar una seguridad completa en sus sistemas ya que podrían presentarse de forma inesperada catástrofes que generarían la pérdida total o parcial de información.



La replicación es sólo un paso para lograr una alta disponibilidad en el sistema de

128

129

información de las organizaciones en general.

RECOMENDACIONES 

Definir las opciones más adecuadas a nivel de tecnología dependiendo del tipo de organización de forma que se presente eficiencia en la operatividad de dichos sistemas como la maximización en la información.



Diseñar un sistema que respalde la información que la Pontificia Universidad Católica Sede Santo Domingo maneja por medio de un sistema que presente las garantías que esta institución requiere.



Establecer una estructuración adecuada tanto en información como hardware, planes de contingencia entre otros para lograr una conectividad permanente de tal forma que si se presenta una interrupción planeada o no planeada se evite pérdidas de información y financieras.



Utilizar la amplia gama de software libre en los diferentes sistemas dentro de las organizaciones para generar liquidez en sus estados financieros y al mismo tiempo confiabilidad en su información.



Aprovechar las diferentes técnicas de replicación asegurando tanto una conectividad permanente como una seguridad periódica en su base de datos.



Salvaguardar la información en una locación distinta a su centro de producción para evitar que esta sufra cualquier percance por efectos de una catástrofe.



Seguir con el plan de alta disponibilidad implementando un RAC de servidores, mantenimientos planeados y otros pasos que se especifican en la disertación.

130

REFERENCIAS

BIBLIOGRÁFICAS

GÓMEZ, Á. (2011). Enciclopedia de la Seguridad Informática. Ra-Ma. Segunda Edición. Guía de Oracle GoldenGate 11g Implementador. Disponible en: dq=oracle&hl=es419&sa=X&ei=k67-U-O7JlfPggSO1lLlDw&ved=0CVEQ6AEwBQ#v=one page& q=oracle&f=false Oracle database 10g. Manual del administrador Fecha publicación: 2005 Editorial: Mc Graw Hill Interamericana S.L. Colección: 1ª Edición / 800 págs. / Rústica / Castellano/ Libro ISBN13:9788448149390 Seguridad y Alta Disponibilidad [Libro Seguridad Informatica][PDF] Edit: RAMA ISBN: 978-84-9964-10 ttp://books.google.com.ec/books?id=Y4qetmt3SXAC&printsec=frontcover&dq=soft ware+libre&hl=es-419&sa=X&ei=DLD-U5v3GJW9ggTM9oL4DQ&ved=0 CCcQ6AEwAg#v=onepage&q=softwar e%20libre&f=false

130

131

LINCOGRAFÍA

AMR Research. (01 de 01 de 2002). AMR Research. Recuperado el 25 de 08 de 2013, de Everyone is the center of the world.: http://www.amrresearch.com ANDERSON, M. (18 de 12 de 2003). System downtime could bring new meaning to the true cost of Christmas, waers Stratus. Recuperado el 22 de 08 de 2013, de StratusTechnologies18 de diciembre de 2003: http://www.itweb.co.72/office/ stratustech/031280758.htm CORPORACIÓN ORACLE. (01 de 12 de 2011). Oracle Corporation. Recuperado el 17 de 08 de 2013, de High Avalavility Architecture and Best Practices 10g Release 1 (10.1): http://download-west.oracle.com /dogs/cd/B14117_01/Sev er.101/b10726.pdf CORPORATION INTERNATIONAL DATA. (01 de 01 de 2001). IDC. Recuperado el 25 de 08 de 2013, de IDC eWord: http://www.idc.com HINTON, W., & CLEMENT, R. (01 de 01 de 2002). Are You Managing the Risks of Downtime? Recuperado el 22 de 08 de 2013, de DisasterRecoveryJournal 2002: http://www.drj.com/articles/um02/1503-12.html NAVARRO, A. (05 de 10 de 2009). Administración de servicios de TI en el mundo real: ITIL y más allá. Recuperado el 21 de 08 de 2013, de Slideshare.net: http://www.slideshare.net/RevistaSG/administracin-de-servicios-de-ti-en-elmundo-real-itil-y-ms-all ORACLE. (01 de 11 de 2010). Oracle. Recuperado el 27 de 08 de 2013, de Respaldos con RMAN, parte I: http://oracleenespanol.blogspot.com/2010/11

132

/respaldos-con-rman-parte-i.html ORACLE. (01 de 01 de 2011). ORACLE. Recuperado el 27 de 08 de 2013, de Oracle White Papers: http://www.oracle.com/technology/deploy/availability/htdoc s/maa.htm ORACLE CORPORATION, T. (01 de 01 de 2011). Oracle Database 10g Product Family. Recuperado el 22 de 08 de 2013, de OracleCorporation Enero 2004: http://www.oracle.com/technology/products/database/oracle10g/pdf/twp_gen eral_10gdb_product_ffamily_0104.pdf RODEN, K. (19 de 04 de 2004). Calculating the cost of downtime. Recuperado el 21 de 08 de 2013, de Computerworld 19 de aril de 2004: http://www.com puterworld.com/printthis/2004/0,4814,91961,00.html TAMINUT. (13 de 10 de 2010). Automakers Look To Reconstruct Supply Chains. Recuperado el 21 de 08 de 2013, de Tamainut IT: http://islaserver.com/b ackup-remoto/backup-online/copias-de-seguridad-online-backup-remoto.html

133

GLOSARIO DE TÉRMINOS

Administrador de base de datos: Persona encargada de velar por la integridad de los datos y sus asociaciones, así como de autorizar las modificaciones que se desee hacer. Archivelog: Oracle realiza un archivado del grupo de Redo log donde se puede hacer backups en caliente. BATCH: Un archivo de procesamiento por lote o lotes proporciona una forma abreviada de ejecutar uno o varios mandatos o instrucciones al Sistema Operativo, al introducir el nombre de un archivo de procesamiento por lotes, el archivo ejecuta cada línea como si se la estuvieran introduciendo desde el teclado. CRM (Customer Relationship Management): En su traducción literal, se entiende como la Gestión sobre la Relación con los clientes. CRON: Es un administrador de procesos en segundo plano que ejecuta procesos a intervalos regulares. DBMS (Data Base Management System): Son las siglas en inglés para los Sistemas de Gestión de Bases de Datos (SGBD). Bajo este nombre se conoce a productos de fabricantes como Oracle, Sybase, Informix, Ingres, Borland, Microsoft, IBM, etc. Delay: Es un timer que ofrece un retardo entre los procesos que están en cola, ofreciendo vistocidad a determinados eventos. Disco Mirroring: Es otro disco exactamente igual al primero en el que se están replicando, constantemente, cada uno de los cambios que se producen en el disco origina.

133

134

ERP: Son capaces de generar una base de datos limpia, donde se gestione la información en tiempo real y se pueda obtener los datos requeridos en el momento que se desee. GLP (General PublicLicense): Es la licencia más ampliamente usada en el mundo del software y garantiza a los usuarios finales (personas, organizaciones, compañías) la libertad de usar, estudiar, compartir (copiar) y modificar el software. MTBF (acrónimo de Mean Time Between Failures): Es la media aritmética (promedio) del tiempo entre fallos de un sistema. OLTP (OnLine Transaction Processing): Es un tipo de sistemas que facilitan y administran aplicaciones transaccionales, usualmente para entrada de datos y recuperación y procesamiento de transacciones (gestor transaccional). Recuperación: Habilidad para reiniciar el proceso, ante una falla del equipo, sin pérdida de datos o resultados. Redo log file: Ficheros de recuperación de datos. RSYNC: Aplicación libre para sistemas de tipo UNIX, que ofrece transmisión eficiente de datos incrementales, que opera también con datos comprimidos y cifrados. SSH (Secure Shell): Es un protocolo de conexión (ver login) remoto que permite la transmisión segura de cualquier tipo de datos: passwords, sesión de login, ficheros, sesión X remota, comandos de administración, etc. Su seguridad estriba en el uso de criptografía fuerte de manera que toda la comunicación es encriptada y autentificada de forma transparente para el usuario. Es un claro y sencillo sustituto de los típicos comandos "r" de BSD (rlogin, rsh, rcp), telnet, ftp e incluso de cualquier conexión TCP. Software libre: Es el que respeta la libertad del usuario, ateniéndose a las 4 libertades que plantea la Free Software Fundation: De usarlo para el fin que se quiera; De realizar copias;

135

De modificarlo para ajustarlo a nuestro gusto; De distribuir las mejoras. Adicionalmente se suele decir que la única restricción es que cada uno que reciba ese software, debe heredar esas libertades. Servidor Redundante o Servidor Espejo: Dos o más sistemas configurados de forma que uno de ellos sea el que está en funcionamiento, y en el caso en que deje de funcionar por cualquier motivo, se active otro de los sistemas que hasta ese momento estaba “en espera” o “inactivo” tan rápidamente como sea posible. Supply Chain Management (SCM): Es una solución de negocios enfocada en optimizar la planeación y las operaciones de la cadena de suministro de la empresa. TCP: Es un protocolo de nivel de transporte completo que proporciona un servicio de transferencia fiablede datos y un método para trasladar datos encapsulados con TCP a un protocolo de nivel de aplicación. TI: Es un amplio concepto que abarca todo lo relacionado a la conversión, almacenamiento, protección, procesamiento y transmisión de la información Target Data Base: Base de datos destino. WIZARD: Es una interfaz de usuario que presenta una secuencia de cuadros de diálogo que guían al usuario a través de una serie de pasos bien definidos para la instalación, desinstalación o modificación de un software.

136

ANEXO No. 1 CUESTIONARIO DE ANÁLISIS DE LA ORGANIZACIÓN

PONTIFICIA UNIVERSIDAD CATÓLICA Sede Santo Domingo

Información de la organización

Complete la información acerca de la organización y una persona que puede ser contratada en caso de requerir datos más detallados

Fecha de aplicación del cuestionario

_____________________________

Nombre de la compañía

_____________________________

Departamento

_____________________________

Nombre del proceso de negocio Encargado del proceso de negocio

_____________________________ Nombre:_____________________________ E-mail: _____________________________

Ciudad, País

_____________, ______________

(Cod. País – Cod. Área - #)

_________, _________, _________

Número de subsidiarias / oficinas

_____________________________

136

137

Análisis de la organización

¿Cuáles son los factores críticos de éxito para la organización en los próximos 3 y 12 meses?

Factores críticos de éxito en los próximos 3 meses

1. _____________________________ 2. _____________________________ 3. _____________________________ 4. _____________________________ 5. _____________________________ Factores críticos de éxito en los próximos 12 meses

1. _____________________________ 2. _____________________________ 3. _____________________________ 4. _____________________________ 5. _____________________________

¿Explique en qué difiere el estado actual de la organización con la visión que se tiene de ella para los próximos 3 años? _____________________________

¿Cuáles son los principales desafíos que la organización está enfrentando actualmente?

1. _____________________________ 2. _____________________________

138

3. _____________________________ 4. _____________________________ 5. _____________________________

Explique ¿Cómo se están manejando los desafíos? _____________________________

¿Qué factores internos y externos representan mayor riesgo para el crecimiento de la organización?

Factores externos 1. _____________________________ 2. _____________________________ 3. _____________________________ 4. _____________________________ 5. _____________________________

Factores internos 1. _____________________________ 2. _____________________________ 3. _____________________________ 4. _____________________________ 5. _____________________________

¿Cuáles son sus competidores más cercanos y qué amenaza representan para la organización?

139

Competidores

Amenaza para la organización

_____________________________

¿Existe en el mercado nuevos tipos de competencia no tradicionales que representan una amenaza contra su organización?

Competidores

Amenaza para la organización

_____________________________

¿Cómo ve la competencia a su organización? _____________________________

¿Cómo mide su organización la retención de clientes? _____________________________

Explique ¿Se ha pensado que la creación de nuevos productos o servicios con la finalidad de captar mayor cantidad de clientes? _____________________________ Si su respuesta a la pregunta anterior fue afirmativa ¿En cuánto tiempo complementarían las

140

nuevas ofertas? _____________________________ ¿Qué áreas de la organización brindan mayor ventaja competitiva? 1. _____________________________ 2. _____________________________ 3. _____________________________ 4. _____________________________ 5. _____________________________

Explique ¿Cómo ve la organización al área de tecnología de información dentro del costo, socio estratégico, soporte táctico, generador de ganancias? _____________________________

¿Cuáles son las fortalezas y debilidades de los servicios que brinda el área de tecnología de la información? Fortalezas

Debilidades

_____________________________

_____________________________ ¿Los proyectos de tecnología de información, son financiados por la secretaría de la organización?

□ Si

□ No

¿Cuáles son las métricas más importantes que utiliza la organización para medir la efectividad de los proyectos de tecnología? _____________________________

141

Explique ¿Cuán receptivos son sus clientes para utilizar internet como mecanismo de interacción con la organización?

_____________________________

Información de los participantes en la Preparación de Respuestas

Nombre/Cargo

Correo electrónico

____________ / _____________

_____________________________

____________ / _____________

_____________________________

____________ / _____________

_____________________________

____________ / _____________

_____________________________

____________ / _____________

_____________________________

142

ANEXO No. 2 CUESTIONARIO DE ANÁLISIS DE IMPACTO DEL NEGOCIO

PONTIFICIA UNIVERSIDAD CATÓLICA Sede Santo Domingo

Información de la organización

Complete la información acerca de la organización y una persona que puede ser contratada en caso de requerir datos más detallados

Fecha de aplicación del cuestionario

_____________________________

Nombre de la compañía

_____________________________

Departamento

_____________________________

Nombre del proceso de negocio

_____________________________

Encargado del proceso de negocio

Nombre:_____________________________ E-mail: _____________________________

Ciudad, País

_____________, _______________

(Cod. País – Cod. Área - #)

___________, ____________, ___________

Número de subsidiarias / oficinas

_____________________________

Análisis de la organización

¿Describa brevemente en qué consiste el proceso del negocio? _____________________________ Enumere en orden las funciones que abarca el proceso del negocio

143

Función

Descripción

_____________________________

Indique los ciclos de procesamiento crítico (hora/día/mes/trimestre/año) para las funciones más importantes

Función

Ciclo

(dd/mm/yyyyhh:min) _____________________________

_____________________________

Indique el número y tipo de usuario que utiliza el proceso de negocio. Considere usuarios internos y externos Tipo de usuario

Número

_____________________________________ _____________________________ _____________________________________ _____________________________ _____________________________________ _____________________________ _____________________________________ _____________________________ _____________________________________ _____________________________ 3.

Información de impacto tangible e intangible

Describa cualquier tipo de cambio a la estructura del proceso de negocio a realizarse en los próximos 2 años y seleccione el tipo de impacto que generaría Cambio

Impacto (Alto, Medio, Bajo)

_____________________________

________

_____________________________

________

144

_____________________________

________

_____________________________

________

_____________________________

________

Impacto (Alto, Medio, Bajo)

_____________________________

________

_____________________________

________

_____________________________

________

_____________________________

________

_____________________________

________

Enumere el día mes y/o período del año en el que el proceso de negocios es más crítico

□ Enero

□ Lunes

□ Fin de semana

□ Febrero

□ Martes

□ Fin de semana

□ Marzo

□ Miércoles

□ Fin de semana

□ Abril

□ Jueves

□ Fin de semana

□ Mayo

□ Viernes

□ Fin de semana

□ Junio

□ Sábado

□ Julio

□ Domingo

□ Agosto □ Septiembre □ Octubre □ Noviembre

145

□ Diciembre Otro (s) _______________

Explique por qué:_____________________________

Selecciones la ventana de tiempo que el proceso de negocio puede permanecer sin soporte técnico especializado

□ Hasta 1 hora

□ Hasta 1 semana

□ Hasta 8 horas

□ Hasta 1 mes

□ Hasta 1 día

□ Hasta 3 meses

□ Hasta 3 días

□ Hasta 6 meses

Selecciones la ventana de tiempo en el cual se tendría un impacto de alto nivel debido a la interrupción del proceso

□ 1 hora

□ 1 semana

□ 8 horas

□ 1 mes

□ 1 día

□ 3 meses

□ 3 días

□ 6 meses

Basándose en la configuración actual de la infraestructura en su organización. ¿En cuánto tiempo se puede recuperar ante una falla de los sistemas de misión crítica? _____________________________

Enumere las principales decisiones de negocio que puedan verse afectadas por la

146

interrupción del proceso

1. _____________________________ 2. _____________________________ 3. _____________________________ 4. _____________________________ 5. _____________________________

Complete la siguiente información referente al impacto tangible generado por la interrupción de procesos

Si/No

Impacto

Prioridad

(Alta,

Media,

Baja)

Reducción de productividad

____________

Incremento de gastos

____________

Pérdidas financieras

____________

Pérdidas legales

____________

_____________________________

____________

Complete la siguiente información referente al impacto intangible generado por la interrupción de procesos Si/No

Impacto

Prioridad

(Alta,

Media,

Baja) Si

Pérdida de confianza

____________

Pérdida de clientes

____________

Pérdida de competitividad

____________

147

Pérdida de imagen

____________

_____________________________

____________

Seleccione un rango que explique la cantidad de dinero que la organización pierde por hora si el proceso de negocio está fuera de servicio

< $5,000 > $5,000 < $10,000 > $10,000 < $25,000 > $25,000 < $50,000 > $50,000 < $100,000 > $100,000 < $250,000 > $250,000 < $500,000 > $500,000 < $1,000,000 > $1,000,000 ____________________ 4.

Información de recuperación y respaldo

Indique si se cuenta con un manual de procedimientos a ser usado si se produce la interrupción del proceso

□ Si

□ No

¿Indique cuándo fue la última vez que se realizaron pruebas para verificar los procedimientos de recuperación?

____________________

□ Días

□ Semanas

□ Meses

Indique la cantidad de tiempo máxima que se puede utilizar un proceso alternativo

148

____________________

□ Horas

□ Días

□ Semanas

¿Indique cuántos miembros del grupo de tecnología están involucrados en proceso de respaldo y recuperación asociada al proceso de negocio regularmente? _____________________________

Indique si se realizan respaldos de la información asociada al proceso de negocio regularmente

□ Si

□ No

Para cada una de las áreas que se especifica a continuación, indique qué procedimiento (s) utiliza para la realización de respaldos

Sistema operativo

_____________________________

Base de datos

_____________________________

Servidor de aplicaciones

_____________________________

Aplicaciones del negocio

_____________________________

Servidor de correo electrónico

_____________________________

Servidor de archivos

_____________________________

Seleccione la frecuencia con la que realiza los respaldos de información

□ Diario (Full)

□ Diario (incremental)

□ Semanal (Full)

□ Semanal (incremental)

□ Mensual (Full)

□ Mensual (incremental)

149

□ Mirror / Multiplexación Otro (s) _______________

Indique si se realizan pruebas para verificar la correcta generación de respaldos □ Si

□ No

Si contestó si a la pregunta anterior, para cada una de las áreas que se especifica a continuación, explique qué tipo de pruebas se realizan

Sistema operativo

_____________________________

Base de datos

_____________________________

Servidor de aplicaciones

_____________________________

Aplicaciones del negocio

_____________________________

Servidor de correo electrónico Servidor de archivos _____________________________

_____________________________ _____________________________ _____________________________

Identifique si la realización de respaldos afecta el rendimiento de los sistemas de producción □ Si

□ No

Indique si considera necesario reducir la complejidad y mejorar la calidad del proceso de respaldo y recuperación

□ Si

□ No

Indique si los respaldos son almacenados fuera de la organización

□ Si

□ No