Incrementar El Nivel de Rentabilidad Mediante La Continuidad de Los Sistemas de Información Mediante Alta Disponibilidad y Performance en Caso de Desastres en Servidores

PROYECTOS DE INGENIERIA DE SISTEMAS I
ASESOR: Wilmer Perfecto
2012-III
INTEGRANTE: Eduardo Aldo Navarro Yataco
PROYECTO:
Incrementar el Nivel de Rentabilidad Mediante la Continuidad de los Sistemas de Informacin Mediante Alta Disponibilidad y Performance en Caso de Desastres en Servidores
FACULTAD: INGENIERIA INDUSTRIAL Y DE SISTEMAS
2012
Incrementar el Nivel de Rentabilidad Mediante la Continuidad de los Sistemas de Informacin Mediante Alta Disponibilidad y Performance en Caso de Desastre en Servidores
Proyecto de Ingeniera de Sistemas I
UTP
PLAN DE TESIS
INTRODUCCIN... 5
CAPTULO 1: Formulacin del Problema 1.1. 1.2. Planteamiento del Problema Antecedentes de solucin 1.2.1. Caso de xito. 1.3. 1.4. 1.5. Propuesta de solucin. Alcance de la propuesta. Justificacin 1.5.1. Por qu.. 1.5.2. Para qu.... 1.6. Objetivos 1.6.1. Objetivo General 1.6.2. Objetivos Especficos.. 10 10 9 9 7 8 8 6
CAPTULO 2: Marco Terico 2.1. Antecedentes de la Investigacin 2.1.1. Caso de xito. 2.2. 2.3. 2.4. 2.5. Alta Disponibilidad....... Medicin de la Disponibilidad. Niveles de Disponibilidad ..... Tiempo Fuera de Servicio 2.5.1. Tiempo Fuera de Servicio Planeado 2.5.2. Tiempo Fuera de Servicio No Planeado. 2.5.3. Estrategias.. 2.6. 2.7. Clasificacin de desastres . Tipos de desastres 2.7.1. Fallas de Hardware. 2.7.2. Fallas de Software 2.7.3. Fallas Ambientales.. 2.7.4. Errores Humanos. 2.8. Beneficios de alta disponibilidad de acuerdo a la problemtica de AJEGROUP 2.8.1. Mirroring 2.8.2. Replicacin Transaccional 2.8.3. Log Shipping 23 24 24 18 19 20 22 15 16 17 18 11 12 12 14
Pgina 2
UTP
2.9.
Planificacin de una arquitectura de alta disponibilidad..
25 26
2.10. Limitaciones y Evaluacin de la tecnologa... 2.11. SQL Server 2008 R2 y sus arquitecturas tecnolgicas de Alta Disponibilidad 2.11.1. Mirroring 2.11.1.1. Definicin 2.11.1.2. Estados 2.11.1.3. Modos de operacin. 2.11.1.4. Servidores.. 2.11.2. Replicacin Transaccional 2.11.2.1. Tipos 2.11.3. Log Shipping 2.12. Conceptos Relacionados . 2.13. Herramientas de Desarrollo de Proyecto 2.13.1. 2.13.2. Base de Datos Microsoft SQL Server 2.13.2.1. Caractersticas.. 2.13.2.2. Ediciones 2.14. Metodologas de Desarrollo de Proyecto 2.14.1. 2.14.2. 2.14.3. 2.14.4. UML.. Modelado de Objetos Artefactos Caractersticas
28 29 29 30
31 33 35
35
36 37
38 38 39 42 42 42
2.15. Sistema de Hiptesis. 2.16. Sistema de Variables.
CAPTULO 3: Marco Metodolgico 3.1. 3.2. Nivel Anlisis de la Investigacin. Diseo de la Investigacin. 3.2.1. Mtodos 3.2.1.1. Mtodo Experimental.. 3.2.1.2. Mtodo de Observacin. 3.2.1.3. Mtodo de Medicin. 3.2.2. Recopilacin de Informacin 3.2.2.1. Tcnicas 3.2.2.2. Instrumentos. 3.2.3. Actividades. 44 45 46 43 43 44 43 43
Pgina 3
UTP
3.3.
Metodologa para el estudio de factibilidad de la Solucin 3.3.1. 3.3.2. 3.3.3. Casos de xito.. Costos de Hardware y Software Tcnicas. 47 49 50
CAPTULO 4: Aspectos Administrativos 4.1. 4.2. ndice Preliminar de la Tesis.... Presupuesto y Cronograma de Actividades.. 51 54 57 58
Referencias... Anexos.
Pgina 4
UTP
INTRODUCCIN
Tradicionalmente se ha entendido por desastre un incendio o inundacin, porque este tipo de eventualidades destrua recursos fsicos de la empresa como archivos, mquinas o listados. En la actualidad, eliminados en gran medida estos riesgos, los directivos se enfrentan a una nueva forma de desastre, que afecta directamente a su activo esencial: su informacin. En cualquier momento, la informacin de una empresa se puede quebrar total o parcialmente como consecuencia de un siniestro fortuito. Es incalculable medir como afectara al negocio y a la reputacin, si las operaciones ms importantes de su compaa se suspendieran repentinamente, nos preguntamos Cunto tiempo puede aguantar una compaa sin acceder a sus activos bsicos de informacin? Y, no menos importante, cunto tiempo necesitaran las aplicaciones que proporcionan dicha informacin para volver a estar disponibles? Adems, a medida que la empresa opera en un entorno en el que las expectativas de sus clientes son cada vez mayores, los tiempos de respuesta se reducen y la competencia aumenta. Puede permitirse la ms mnima interrupcin informtica? El impacto que provoca un desastre informtico, segn datos de la consultora internacional ContingencyPlanningResearch, es mayor sobre las empresas financieras, mercados burstiles, etctera, que sobre cualquier otro tipo de negocio. Se situaran en segundo lugar los negocios basados en los sistemas de autorizacin de pagos como los cajeros automticos y validacin de tarjetas de crdito entre otros. Es razonable, pues, prepararse para lo peor. La empresa debe prever posibles prdidas de informacin irreparables en sus instalaciones, que pueden llegar desde distintos frentes: virus, cadas elctricas, desastres naturales o medioambientales. Del tiempo que tarde en reaccionar, restaurando, recuperando y peridicamente aumentando la performance de la informacin crtica que contienen, depender la gravedad de las consecuencias econmicas para su negocio . Por esta razn, aplicaremos un plan de alta disponibilidad de la informacin en la empresa AJEGROUP S.A. en caso ocurra un desastre, evitando el detenimiento de sus procesos. Actualmente con la aplicacin de herramientas tecnolgicas es posible implementar estas metodologas para salvaguardar la informacin y as evitar prdidas incalculables e irreparables a la empresa.
1
Desastres Informticos: previsin y prevencion.La-p/seccion-ti/articulo-130035
prevencin
http://www.idg.es/computerworld/Desastres-informaticos-prevision-y-
Pgina 5
UTP
CAPTULO 1: FORMULACIN DEL PROBLEMA
1.1. Planteamiento del Problema

Disponibilidad de la informacin en los servidores de base de datos de AJEGROUP S.A. mediante la implementacin de tecnologas de alta disponibilidad en caso de desastres y optimizacin de tiempos de respuesta aumentando la performance de procesos, que nos permita tener acceso a la informacin las 24 horas del da con tiempos de respuesta mnimos.
Parmetros Carrera rea Asignatura / Especialidad Temas Temas Especficos Ingeniera de Sistemas Tecnologa Disponibilidad e Integridad de la Informacin. Frecuencia de informacin y optimizacin de tiempos de respuesta aplicando tecnologas de alta disponibilidad. Acceso y alta performance de la informacin las 24 horas del da. Gestin de aplicaciones de misin crtica ms exigentes, reduciendo el tiempo y el coste de desarrollo mediante tecnologas de alta disponibilidad y Situacin Problemtica performance, debido a la cada parcial o total de servidores como
consecuencia de un siniestro fortuito afectando incalculablemente a la compaa, facilitando as a toda la empresa la informacin necesaria para toma de decisiones.
1.2. Antecedentes de Solucin

RedITes una compaa internacional que ofrece a sus clientes una variada gama de soluciones y servicios integrados de Tecnologa de Informacin, asistindolos para MAXIMIZAR, el valor de su negocio. Estas soluciones satisfacen los requerimientos de los clientes en las reas de continuidad de negocios y recuperacin ante desastres, administracin y operacin de servicios administrados de TI y servicios profesionales.
Pgina 6
UTP
1.2.1.
Caso de xito Perfil del Cliente Compaa de BBVA Bancomer encargada de realizar, recibir y controlar pagos por Internet.
Situacin "Al ofrecer servicios de tipo bancario, los equipos que manejan dichas transacciones son crticos y cada vez se incrementan por lo que mantenerlos siempre disponible es vital para el negocio. De igual forma, en nuestro ambiente se requiere cumplir con los ms elevados estndares de seguridad para realizar las transacciones en horarios de 7X24".
Reto del negocio BBVA busca una solucin en trminos de servicio que le ayude a mantener la disponibilidad de los servidores a travs de un servicio de monitoreo continuo y soporte tcnico.
Solucin "A travs de las tecnologas de recuperacin instantnea de informacin Mirroring y Replicacin, que ha implementado redIT, tenemos alta disponibilidad y redundancia; el servicio de outsourcing nos brinda el costo-beneficio requerido al contar con un solo proveedor, quien al tener infraestructura propia aumenta la productividad de nuestro presupuesto". "Gracias a su servicio de soporte y monitoreo de servidores con herramientas automatizadas y personal especializado nos ayudan a mantener disponible el mayor tiempo posible los servicios que brindamos a nuestros clientes y las mejores prcticas de trabajo necesarias para prevenir y reaccionar en caso de fallas".
Beneficios "Uno de los grandes beneficios de redIT es contar con sus certificaciones, lo cul nos ahorra trabajo y se convierten en un punto de referencia de que estn haciendo las cosas bien. Adems que son extensiones de los servicios que ahora mismo ofrecemos y en muchos casos se traduce en tranquilidad para nuestros clientes". Jos Luis Garibay, Gerente de Produccin y Soporte
2
redIT Resultados Inteligentes - http://www.redit.com/mx/html/solutions/connectivity.php
Pgina 7
UTP
1.3. Propuesta de Solucin

Implementar tecnologas como Log Shipping, Replicacin y Mirroring que nos brinda el SQL Server 2008 R2 que nos permitir obtener unaalta disponibilidad en todos los sistemas y servicio 24x7 con muy pocas incidencias, especialmente destacable el caso delos portales web en los que soporte aplicaciones de tramitaciones que recibe ms de 330.000 visitas mensuales (10.000 diarias). A travs de esta implementacin podremos gestionar las aplicaciones de misin crtica ms exigentes, reducir el tiempo y el coste de desarrollo, facilitando as a toda la empresa la informacin necesaria para toma de decisiones.
1.4. Alcance de la Propuesta

Se aplicar las tecnologas de alta disponibilidad solo a los servidores de base de datos crticos, midindolos por nmero de cadas mensuales, cantidad diaria de transacciones. Estableceremos independientemente de la tecnologa los servidores principales y secundarios. Aplicaremos la tecnologa Log shipping solo para usuarios de bases de datos, no sistemas de bases de datos y que estn dentro del Active Directory. Esto significa que debe tener un rgimen estricto de backup las bases de datos master y msdben el servidor primario y restaurarlos en el secundario. Sin este rgimen, cualquier metadato cambiado ser perdido en la falla del sistema, resultando potencialmente en logins, trabajos y alertas perdidos. Configuraremos Log Shipping en las horas donde exista menos carga de trabajo, para que al momento de ejecutarse los jobs generados por esta tecnologa no sature el ancho de banda. Escogeremos el servidor como servidor secundario al que tenga ms de 250 GB de espacio disponible para almacenar los backups generados. Aplicaremos replicacin transaccional a los servidores de alto rendimiento en el almacenamiento de datos, creacin de informes y que contengas la integracin de datos procedentes de varios sitios. Aplicaremos replicacin de mezcla a las tablas de las aplicaciones mviles o de servidores distribuidos que pueden encontrarse con conflictos de datos. Aplicaremos Mirroring a los servidores donde las conexiones estn estables y certificadas. Para esto necesitamos establecer 3 servidores (Principal, Espejo y Testigo). Reindexacin o Defragmentacin de todos los ndices de la base de datos. Anlisis pormenorizado de las 30 sentencias que insumen ms tiempo de ejecucin de modo de identificar la posibilidad de creacin de ndices que contribuyan al mejor desempeo de las mismas. Redefinicin de la estrategia de respaldo as como tambin configuracin de todos los planes de mantenimiento necesarios para un correcto mantenimiento preventivo de las diferentes bases de datos que residen en el servidor.
Pgina 8
UTP
1.5. Justificacin
1.5.1. Por qu? Hoy en da muchas empresas requieren algunos o todos sus datos crticos a ser altamente disponible. Por ejemplo, una empresa que requiere "24x7" disponibilidad es un comerciante en lnea, cuyo producto bases de datos y aplicaciones de ventas en lnea debe estar disponible en todo momento, de lo contrario las ventas (y los ingresos) se pierden. Otro ejemplo es un hospital, donde los registros computarizados de pacientes deben estar disponibles en todo momento o una vida humana se podra perder. En el mundo real, sin embargo, hay numerosos problemas que pueden causar que los datos no estn disponibles. Estas estrategias siempre exigen la aplicacin de mltiples tecnologas que ayudan a mantener la disponibilidad de datos, no existe una nica tecnologa de alta disponibilidad que puede satisfacer todas las necesidades. Se trata de poner en marcha todos los recursos necesarios para permitir que los sistemas funcionen las 24 horas del da, mantenindolos a salvo de interrupciones y con los niveles apropiados de dimensionamiento para garantizar tiempos de respuesta adecuados. Ofrecer alta disponibilidad y por tanto Disponibilidad Continuada de las aplicaciones significa realizar grandes inversiones para que todos los elementos que forman parte de los recursos de infraestructura sean Redundantes, Escalables y Seguros con planes de Contingencias y de mejora continuos .
3
1.5.2.
Para qu? Con la aplicacin de las tecnologas que nos ofrece Microsoft SQL Server 2008 R2, las cuales podremos utilizar para aumentar y / o mantener una alta disponibilidad de los datos crticos. La alta disponibilidad se trata de implementar un conjunto de tecnologas en los servidores antes de que se produzca un fallo para evitar el fracaso de afectar a la disponibilidad de datos. La recuperacin de desastres es acerca de tomar
accin despus de un fallo se ha producido la recuperacin de datos perdidos y hacer que los datos estn disponibles de nuevo. Esta investigacin describe las tecnologas disponibles en SQL Server 2008 R2 que se puede utilizar como parte de una estrategia de alta disponibilidad para proteger datos crticos. Adems de describir las tecnologas en detalle, la investigacin tambin se analizan las diversas causas del tiempo de inactividad y la prdida de datos, y la forma de evaluar y equilibrar los requisitos y limitaciones en la planificacin de una estrategia de alta disponibilidad que implica SQL Server 2008 R2.
DataDec Online - http://www.ddol.es/alta_disponibilidad.htm
Pgina 9
UTP
1.6. Objetivos
1.6.1. Objetivo General Determinar el nivel de rentabilidad econmica, mediante la continuidad de los Sistemas de Informacin aplicando tecnologas de alta disponibilidad y performance, haciendo contino las operaciones de la compaa.
1.6.2. Objetivos Especficos Anlisis de servidores de base de datos para determinar criticidad tanto en el motor como en los objetos de base de datos. Determinar la cantidad de cadas de los servidores de base de datos en un lapso de tiempo determinado. Anlisis de la arquitectura de red.
Maximizar el grado de proteccin de un sistema o aplicacin ante un evento de falla del

sistema, permitindole continuar disponible cuando se presenta la falla. Minimizar el impacto en los sistemas de informacin al momento de alguna cada en los servidores y cuando recuperan su disponibilidad. Continuar ofreciendo disponibilidad en los sistemas de informacin, en el caso de que los servidores principales estn irrecuperables. Prevenir y anticiparse a que ocurran fallas en los servidores.
Pgina 10
UTP
CAPTULO 2: MARCO TERICO 2.1. Antecedentes de la Investigacin

2.1.1. Caso de xito Perfil del Cliente Mercadotecnia Ideas y Tecnologa, (MIT) es una compaa especializada en el desarrollo de modelos y soluciones sustentadas en herramientas de tecnologa y mercadotecnia, para medios de pago electrnicos.
Situacin MIT desarrolla y opera soluciones para: aseguradoras, aerolneas, TV por cable, ventas telefnicas y hotelera. Actualmente MIT da servicio a 13,000 puntos de venta, realiza 120,000 transacciones diarias, cuenta con 2500 empresas medianas y 500 grandes empresas que dan servicio a su vez a otras empresas.
Reto del negocio Implementar una arquitectura de alta disponibilidad para evitar el detenimiento de sus soluciones y/o aplicaciones, as como la optimizacin de sus tiempos de respuesta de procesos.
Solucin Al principio solo buscaba optimizacin de sus procesos; sin embargo la mejor solucin fue implementar las arquitecturas de alta disponibilidad Mirroring en sus servidores crticos y Log Shipping en sus servidores de diferente plataforma. "A travs de los servicios que hemos contratado con redIT tenemos alta disponibilidad y tiempos de respuesta mnimos de los procesos que se ejecutan en la base de datos". "Gracias a su servicio de soporte y monitoreo de servidores con herramientas automatizadas y personal especializado nos ayudan a mantener disponible el mayor tiempo posible los servicios que brindamos a nuestros clientes para prevenir y reaccionar en caso de fallas, as como las mejoras en tiempo de respuesta".
Beneficios Incremento de la disponibilidad de servicios de TI que soportan las transacciones de su negocio y confianza en un socio tecnolgico que comprende los objetivos de MIT .
4 4
redIT Resultados Inteligentes - http://www.redit.com/mx/html/solutions/connectivity.php
Pgina 11
UTP
2.2. Alta Disponibilidad

La disponibilidad es una de las caractersticas de las arquitecturas empresariales que mide el grado con el que los recursos del sistema estn disponibles para su uso por el usuario final a lo largo de un tiempo dado. sta no slo se relaciona con la prevencin de cadas del sistema (tambin llamadas tiempos fuera de lnea, downtime u offline), sino incluso con la percepcin de "cada" desde el punto de vista del usuario: cualquier circunstancia que nos impida trabajar productivamente con el sistema es considerada como un factor de baja disponibilidad. Por esto disponibilidad se refiere al grado de continuidad con el que un sistema, aplicacin o servicio es operativo y satisface las necesidades de los usuarios, es decir es el tiempo en el que los usuarios tienen acceso y pueden ejecutar operaciones sobre un recurso o en un sistema.
2.3. Medicin de la Disponibilidad

De primera instancia, todo sistema debe tener establecido un Acuerdo de Nivel de Servicio (Service Level Agreement SLA) que defina cunto tiempo y en qu horarios debe estar en lnea. En el caso de aplicaciones de baja criticidad, dicho SLA puede ser de 85 horas a la semana excluyendo das festivos; para sistemas con mayor criticidad como una red de cajeros automticos se tienen niveles de servicio que alcanzan las 24 horas al da, los 365 das del ao. As entonces, suponiendo un sistema con un SLA de 24365 podramos calcular su disponibilidad de la siguiente manera: Disponibilidad = ((A B)/A) x 100 por ciento)
Donde: A = Horas comprometidas de disponibilidad: 24 x 365 = 8,760 Horas/ao. B = Nmero de horas fuera de lnea (Horas de "cada del sistema" durante el tiempo de disponibilidad comprometido).
Por ejemplo: 15 horas por falla en un disco; 9 horas por mantenimiento preventivo no planeado. As entonces : Disponibilidad = ((8,760 24)/8,760) x 100 por ciento) = 99.726%
5
Alta Disponibilidad - http://everac99.wordpress.com/2008/08/19/alta-disponibilidad-que-es-y-como-se-logra/
Pgina 12
UTP
Cuando se realicen negociaciones para definir objetivos de disponibilidad con los usuarios, es necesario conocer de las implicaciones tcnicas y econmicas, como se muestra en la siguiente tabla: TIEMPO DISPONIBILIDAD (%) TIEMPO OFFLINE/AO OFFLINE/MES 90% 95% 98% 99% 99.5% 99.9% 99.95% 99.99% 99.999% 99.9999% 36.5 das 18.3 das 7.3 das 3.7 das 1.8 das 8.8 hrs 4.4 hrs 52.6 min 5.26 min 31.5 s 73 hrs 36.5 hrs 14.6 hrs 7.3 hrs 3.66 hrs 43.8 min 21.9 min 4.4 min 26.3 s 2.62 s OFFLINE/DA 2.4 hrs 1.2 hrs 28.8 min 14.4 min 7.22 min 1.46 min 43.8 s 8.6 s 0.86 s 0.08 s TIEMPO
Tabla 1: Disponibilidad para un sistema 247 y tiempos de cada permitidos Fuente: Alta Disponibilidad - http://everac99.wordpress.com/2008/08/19/alta-disponibilidad-que-es-y-como-se-logra/
Estos nmeros (especialmente aquellos que pasan de la marca del 99.5% de disponibilidad) son difciles de alcanzar, ya que es necesario poder recuperarse ante cadas del sistema de manera transparente. La capacidad e intervalo de tiempo necesarios para recuperarse ante tal eventualidad son directamente dependientes de: La complejidad del sistema. La severidad del problema. La disponibilidad del personal de soporte. La madurez en materia de administracin del sistema y sus operaciones. Otros factores tcnicos o de gestin: falta de refacciones, fallas en la cadena de escalamiento, etc.
6
Alta Disponibilidad - http://everac99.wordpress.com/2008/08/19/alta-disponibilidad-que-es-y-como-se-logra/
Pgina 13
UTP
2.4. Niveles de disponibilidad

Convencional: las funciones de negocios pueden verse interrumpidas y la integridad de los datos no es esencial. Disponibilidad: 90% Mecanismos: servidor de base de datos regular con respaldo tradicional (tcnicas de recuperacin y copia de seguridad).
Media (High Reliable): las funciones de negocios pueden verse interrumpidas pero se debe mantener la integridad de datos. Disponibilidad de servicio: 95% Mecanismos: bitcoras de operaciones.
Alta Disponibilidad: las funciones de negocios aceptan pequeas interrupciones y al retomar se reprocesan transacciones. Disponibilidad: 99% Mecanismos: bitcoras de operaciones, recuperacin automtica.
Resistencia a fallas: requiere de operacin ininterrumpida en horario laboral, se retoma en caso de falla automticamente. Disponibilidad: 99.9% Mecanismos: clustering, mirroring.
Tolerancia a fallas: capacidad de procesamiento continuo y cualquier falla debe ser transparente para el usuario. Disponibilidad: 99.99% Mecanismos: duplicidad del sitio y redundancia.
Tolerancia a Desastres: disponibilidad en todo momento, capacidad para soportar desastres naturales y humanos. Disponibilidad: 99.999% Mecanismos: Los anteriores ms dos sitios y mecanismos de recuperacin.
7.
Solucin de Alta Disponibilidad de Base de Datos Facultad de Ingeniera de la Universidad San Carlos de Guatemala
Pgina 14
UTP
2.5. Tiempo Fuera de Servicio

La meta de la alta disponibilidad es cuidar cualquier rompimiento en el servicio. Los sistemas de alta disponibilidad tienen representaciones, capacidades y empleo de estrategias especialmente diseadas para minimizar el tiempo fuera de servicio. planeado o no planeado. El Tiempo fuera de servicio puede ser
Figura 1: Causas del Tiempo Fuera de Servicio Fuente: Solucin de Alta Disponibilidad de Base de Datos Facultad de Ingeniera de la Universidad San Carlos de Guatemala
2.5.1.
Tiempo fuera de servicio planeado El tiempo fuera de servicio planeado es el cuando el sistema no est disponible debido al programa de mantenimiento con actualizaciones de software / hardware y cuando se hace copias de seguridad del sistema. servicio planeado debe ser: Proveer copias de seguridad (backups), mantenimiento, actualizaciones mientras el sistema est arriba y corriendo. Reducir el tiempo para desempear esas tareas que pueden ser nicamente cuando el sistema est bajo .
8
El mtodo usado para minimizar el tiempo fuera de
Pgina 15
UTP
2.5.2.
Tiempo fuera de servicio no planeado El tiempo fuera de servicio no planeado es el tiempo que el sistema no est disponible debido a fallas de componentes defectuosos del computador o defectos del medio ambiente. Errores humanos y desastres naturales son ejemplos de defectos del medio ambiente. El mtodo usado para minimizar el tiempo fuera de servicio no planeado es para: Minimizar el nmero de defectos y el efecto / recuperacin en el tiempo de los defectos en un sistema. Evitar un punto singular de falla por la utilizacin redundante de partes (failover). Reducir el impacto de los defectos del medio ambiente usando UPS y copia idntica de los datos fuera del sitio y/o replicacin en caliente de componentes omitidos. Para mencionar el porcentaje de las causas no planeadas que provocan un paro se debe revisar la grfica que se presenta a continuacin.
Figura 2: Causas desconocidas no planeadas Fuente: Solucin de Alta Disponibilidad de Base de Datos Facultad de Ingeniera de la Universidad San Carlos de Guatemala
La solucin lgica para incrementar la disponibilidad es mantener los datos en ms de un lugar (recuperacin de desastre), evitar que el usuario perciba las fallas en el servicio (recuperacin de fallas) y mejorar el tiempo de respuesta (rendimiento). El criterio para una la alta disponibilidad y alto desempeo incluye una solucin: Mnimo impacto sobre la disponibilidad y desempeo de un sistema primario. Una copia completa de la base de datos primaria para reportar y extraer, que siempre es accesible donde no hay emergencia. La copia de la base de datos deber ser una imagen de la actualizacin de la base de datos primaria .
9
Pgina 16
UTP
2.5.3.
Estrategias para maximizar la disponibilidad sin quebrar econmicamente a la empresa: Redundancia Los fabricantes han estado diseando redundancia en sus productos en forma de fuentes de poder redundantes, mltiples procesadores, memoria segmentada y discos redundantes. Esto tambin se puede referir a sistemas de servidores corriendo en modo de alerta en caliente en otra ubicacin. Se puede tambin configurar de la misma manera los controladores de discos y de cintas con rutas paralelas, repartiendo la carga de la red en dos lneas y proporcionando consolas alternas de control
Reputacin La reputacin de los proveedores clave como servidores, almacenamiento, bases de datos y equipos de redes juegan un papel principal en la bsqueda de la alta disponibilidad. Hay varias maneras para verificar la reputacin como porcentaje de participacin en el mercado, comportamiento histrico en clientes, y reportes de analistas de industria.
Confiabilidad La confiabilidad de los equipos y de los programas tambin se puede verificar por referencias de clientes y analistas de industria. Adems se recomienda establecer un monitoreo permanente a travs de la gente de operaciones, soporte y tcnicos del proveedor, adems de comparar con otros departamentos de TI.
Facilidad de Reparacin Este factor califica la facilidad relativa con la cual los responsables del servicio tcnico pueden arreglar la falla. Dos mtricas comunes para medir esto es cuanto se demora en hacer el trabajo de reparacin, y cada cuanto se debe repetir.
Restablecimiento Se refiere a la habilidad para sobreponerse a una falla momentnea, de tal manera que no haya impacto en la disponibilidad para el usuario final. Puede ser tan pequeo como una pequea porcin de la memoria recuperndose de un error insignificante, o algo tan grande como un sistema de servidores que decida invernar sin razn alguna, sin perdida de informacin transaccional .
10
10
Pgina 17
UTP
2.6. Clasificacin de desastres

Desastres naturales: Un desastre natural es muy difcil, pero es posible tomar las precauciones necesarias para evitar prdidas. Estos desastres son inundaciones, incendios, terremotos, huracanes, etc.
Desastres producidos por el hombre: Estos desastres son los principales motivos de fracaso. El error humano y la intervencin puede ser intencional o no intencional, la cual puede causar enormes fracasos como la prdida de la comunicacin y utilidad. Estos desastres incluyen accidentes, huelgas, sabotaje, robo, virus, intrusiones, etc.
2.7. Tipos de desastres

En general, hay cuatro tipos de factores diferentes que pueden disparar un desastre: Fallas del hardware Fallas del software Fallas ambientales Errores humanos
2.7.1. Fallas de hardware Las fallas de hardware son fciles de entender - el hardware falla y el trabajo se detiene. Lo que es ms difcil de entender es la naturaleza de las fallas y cmo se puede minimizar su exposicin a ellas. He aqu algunos enfoques que puede utilizar:
Mantener partes adicionales de hardware En su forma ms simple, las exposiciones debidas a fallas del hardware se pueden reducir manteniendo repuestos de hardware adicionales. Este enfoque asume dos cosas: Alguien est en el sitio con suficientes habilidades para diagnosticar el problema, identificar la parte defectuosa y reemplazarla. Est disponible un repuesto para el hardware defectuoso.
Contratos de servicios Los contratos de servicios pasan el problema de las fallas de hardware a alguien ms. Lo nico que necesita hacer es confirmar que ha ocurrido una falla y que no parece estar relacionado a un problema de software .
11
11
Red Hat Enterprise Linux 4 - Introduccin a la administracin de sistemas Cap. 8: Planificacin para Desastres
Pgina 18
UTP
He aqu algunas cosas que debera considerar cuando est revisando contratos de servicios: Horas de cobertura Tiempo de respuesta Partes disponibles Presupuesto disponible Hardware cubierto
2.7.2. Fallas de Software Algunas fallas de software pueden resultar en largos tiempos fuera de servicio. Por ejemplo, los dueos de cierta marca de computadores conocidos por sus funcionalidades de alta disponibilidad, descubren esto a primeras. Un error en el cdigo de manejo de tiempo del sistema operativo del computador result en que los sistemas fallen a cierta hora de cierto da. Las fallas del software pueden golpear en dos reas: Sistema operativo Aplicaciones
Cada tipo de falla tiene su impacto especfico y se exploran en ms detalles en las secciones siguientes.
Fallas del sistema operativo En este tipo de falla, el sistema operativo es responsable por la interrupcin del servicio. Las fallas del sistema operativo vienen de dos reas: Cadas del sistema Colgarse o bloquearse
Fallas de las aplicaciones A diferencia de las fallas del sistema, las fallas de las aplicaciones pueden ser ms limitadas en el mbito de lo que daan. Por otro lado, si se trata de una aplicacin de servidor que est sirviendo a una gran poblacin de aplicaciones clientes, las consecuencias de la falla seran mucho ms extensas. Las fallas de las aplicaciones, igual que otras fallas del sistema, pueden ser causadas por cadas o bloqueos; la nica diferencia es que aqu es la aplicacin la que se est fallando .
12
12
Pgina 19
UTP
Asistencia de software De la misma forma que los fabricantes de hardware ofrecen soporte para sus productos, muchos proveedores de software colocan paquetes de soporte disponibles a sus clientes. Excepto por las diferencias obvias (no se requieren repuestos y la mayora del trabajo lo puede hacer el personal de soporte a travs del telfono), los contratos de soporte de software pueden ser bastante similares a los contratos de hardware. El nivel de soporte suministrado por un fabricante de software puede variar. He aqu algunas de las estrategias de soporte ms comunes empleadas hoy da: Documentacin auto-asistencia Soporte de Web o de correo electrnico Soporte telefnico Soporte in situ
2.7.3. Fallas Ambientales Los problemas pueden ocurrir an cuando el hardware se est ejecutando perfectamente y aunque el software est configurado de la forma adecuada. Los problemas ms importantes que ocurren fuera del sistema mismo tienen que ver con el ambiente fsico en el cual reside el sistema. Los problemas ambientales se pueden desglosar en cuatro categoras: Integridad del edificio Electricidad Aire acondicionado Tiempo y el mundo exterior
Integridad del edificio Para ser una estructura tan simple, un edificio realiza una gran cantidad de funciones. Proporciona un refugio contra los elementos. Suministra el ambiente climtico adecuado para los contenidos del edificio. Tiene mecanismos para proporcionar energa y proteccin contra fuegos, robos y vandalismo. Para realizar todas estas funciones, no es una sorpresa que hayan muchas cosas que pueden salir mal con un edificio .
13
13
Pgina 20
UTP
He aqu algunas de las posibilidades a considerar: Los techos pueden tener goteras, dejando pasar agua hasta los centros de datos. Varios sistemas del edificio (tales como agua, desages, o manejo del aire) pueden fallar, dejando el edificio inhabitable. Los pisos puede que no tengan suficiente capacidad para soportar el equipo que desea colocar en su centro de datos.
Electricidad Debido a que la electricidad es como la sangre de cualquier sistema computacional, los problemas relacionados a la energa son de suprema importancia en la mente de un administrador de sistemas. Hay muchos aspectos diferentes sobre la electricidad; estos se cubren con ms detalles en las secciones siguientes. Lo principal a verificar son los mtodos a travs de los cuales la energa es trada a las instalaciones de su organizacin y dentro del edificio. Las lneas de transmisin estn por debajo o sobre la tierra? Las lneas sobre el suelo son susceptibles a: Daos por condiciones ambientales extremas (hielo, viento, relmpagos) Accidentes de trnsito que daan los postes y/o transformadores Animales perdidos en el lugar incorrecto y cortando las lneas
Sin embargo, las lneas bajo tierra tienen sus limitaciones nicas: Daos de trabajadores de construccin cavando en los lugares incorrectos Inundaciones Relmpagos (sin embargo, mucho menos que con las lneas sobre la tierra)
Calefaccin, Ventilacin y Aire Acondicionado Los sistemas de Calefaccin, Ventilacin y Aire Acondicionado (Heating, Ventilation, and Air Conditioning, HVAC) utilizados en los edificios de oficinas de hoy da, son increblemente sofisticados. A menudo controlado por computadoras, el sistema HVAC es vital para proporcionar un ambiente laboral cmodo. Los centros de datos tienen equipos adicionales de manejo de aire acondicionado, principalmente para eliminar el calor generado por muchas computadoras y el resto del equipo asociado. Las fallas en el sistema HVAC pueden ser devastadoras para el funcionamiento continuo de su centro de datos. Dada su complejidad y la naturaleza electromagntica, las posibilidades de una falla son muchas y variadas .
14
14
Pgina 21
UTP
He aqu algunos ejemplos: Las unidades de manejo de aire acondicionado (esencialmente grandes ventiladores elctricos) pueden fallar debido a la sobrecarga elctrica, una falla, falla de la correa/polea, etc. Las unidades de enfriamiento (a menudo llamadas chillers) pueden perder su refrigerante debido a filtraciones o tomar sus compresores y/o motores.
El tiempo y el mundo externo Hay algunos tipos de tiempo que pueden causar problemas a un administrador de sistemas: Las nevadas fuertes y el hielo puede impedir que el personal llegue hasta el centro de datos y hasta puede tapar los condensadores de aire acondicionado, provocando que se eleven las temperaturas de los centros de datos justamente cuando no hay nadie que pueda acercarse al centro de datos para llevar a cabo las acciones correctivas. Vientos fuertes que pueden interrumpir la energa y las comunicaciones, con vientos extremadamente fuertes daando inclusive el edificio mismo.
Hay otros tipos de tiempo que tambin pueden provocar problemas, an cuando no sean tan conocidos. Por ejemplo, las temperaturas muy altas pueden ocasionar que se sobrecarguen los sistemas de enfriamiento, generando apagones parciales o totales cuando el panel elctrico se sobrecarga.
2.7.4. Errores Humanos Se ha dicho que las computadoras son realmente perfectas. La razn detrs de esta afirmacin es que si usted profundiza lo suficiente, detrs de cada error computacional encontrar el error humano que lo caus.
Errores humanos del usuario final Los usuarios pueden cometer errores que podran tener un impacto muy serio. Sin embargo, debido a que su ambiente normalmente no tiene muchos privilegios, los errores tienden a ser de naturaleza localizada. Puesto que la mayora de los usuarios interactan exclusivamente con una computadora por una o ms aplicaciones, usualmente es dentro de las aplicaciones que ocurren la mayora de los errores .
15
15
Pgina 22
UTP
Errores del personal de operaciones Los operadores tienen una relacin ms profunda con las computadoras de una organizacin que los usuarios finales. Mientras que los errores de un usuario tienden a ser orientados a aplicaciones, los de los operadores tienden a llevar a cabo un rango ms amplio de tareas. Aunque la naturaleza de las tareas haya sido dictada por otros, algunas de estas tareas pueden incluir el uso de utilidades a nivel del sistema, donde el potencial para daos ms amplios debido a errores es mayor. Por lo tanto, los tipos de errores que un operador puede hacer se centran en la habilidad de un operador de seguir procedimientos que hayan sido desarrollados para su uso.
Errores del Administrador del Sistema A diferencia de los operadores, los administradores de sistemas realizan una variedad de tareas usando las computadoras de la organizacin. Tambin a diferencia de los operadores, las tareas que los administradores de sistemas llevan a cabo a menudo no estn basadas en procedimientos documentados. En consecuencia, los administradores de sistemas a veces crean trabajo adicional para s mismos cuando no tienen cuidado en lo que estn haciendo. Durante el curso de llevar a cabo las responsabilidades diarias, los administradores de sistemas tienen acceso ms que suficiente a los sistemas computacionales como para afectar accidentalmente los sistemas.
2.8. Beneficios de las arquitecturas de alta disponibilidad de acuerdo a la problemtica de AJEGROUP.

2.8.1. Mirrorring Aumenta la proteccin de datos. Reflejo de base proporciona una redundancia completa o casi completa de los datos, dependiendo de si el modo de funcionamiento es de alta seguridad o de alto rendimiento. Aumenta la disponibilidad de una base de datos. En el caso de un desastre, en el modo de alta seguridad con conmutacin automtica por error, failover rpidamente trae la copia de reserva de la base de datos en lnea (sin prdida de datos). En los otros modos de operacin, el administrador de base de datos tiene la alternativa del servicio forzado (con posible prdida de datos) a la espera de copia de la base de datos.
Pgina 23
UTP
Mejora la disponibilidad de la base de datos de produccin durante las actualizaciones. Para minimizar el tiempo de inactividad de una base de datos reflejada, de forma secuencial puede actualizar las instancias de SQL Server que estn participando en una sesin de creacin de reflejo de base de datos.
2.8.2.
Replicacin Transaccional Las consultas del catlogo y otras lecturas se expanden por varios nodos. Esto permite que el rendimiento permanezca coherente conforme aumentan las lecturas. Si se produce un error en uno de los nodos del sistema, un nivel de aplicacin puede redirigir las escrituras para dicho nodo a otro. As se mantiene la disponibilidad. Si un nodo requiere el mantenimiento o el sistema completo requiere una actualizacin, cada nodo se puede tomar sin conexin y agregar de nuevo al sistema sin que se vea afectada la disponibilidad de la aplicacin.
2.8.3.
Log Shipping Basado en entorno desconectado. Totalmente transparente para aplicaciones. Fcil configuracin. Soporta configuracin Heterogneas Fcilmente supervisable, resincronizable y reconfigurable
De acuerdo al anlisis de servidores y beneficios de las arquitecturas de alta disponibilidad a aplicar, podemos tomar como por ejemplo los siguientes servidores de la empresa: Detallamos las caractersticas del servidor de Distribucin de Per: Nombre de Servidor: SRVPELIDB3\SQLINST02 (172.16.0.40\SQLINST02). Motor de BD: SQL 2005 Enterprise Edition Nombre de la BD: DATA Tamao total: 465 GB Collation: Modern_Spanish_CI_AS Recovery Model: Simple Aplicaremos la arquitectura Mirroring, por ser uno de los servidores crticos y por ende necesitamos proteger la informacin y ala vez aumentar la disponibilidad de base de datos.
Pgina 24
UTP
Detallamos las caractersticas del servidor de Distribucin de Colombia: Nombre de Servidor: SRVCOBODB1 (172.17.52.8). Motor de BD: SQL 2005 Enterprise Edition (64 Bits). Nombre de la BD: BDCOLOMBIA Tamao total: 186 GB Collation: Modern_Spanish_CI_AS Aplicaremos la arquitectura Log Shipping a este servidor debido a su mediana criticidad y por poseer un sistema operativo de 32 bits, que hace poco factible poder aplicar otra arquitectura de alta disponibilidad.
2.9. Planificacin de una arquitectura de alta disponibilidad

Una exitosa estrategia de alta disponibilidad no puede planificarse nicamente desde el punto de vista tcnico, ya que los costos y los riesgos para el negocio de los tiempos de inactividad y / o prdida de datos debe ser entendido. Del mismo modo, la estrategia no se puede conducir nicamente a partir de los requerimientos del negocio sin una comprensin de las implicaciones tcnicas de estos requisitos. La primera respuesta de muchas personas en la planificacin de una estrategia de alta disponibilidad es algo as como "implementar un mirroring!" Sin ninguna consideracin de lo que la estrategia est tratando de lograr. A pesar de que mirroring es una tecnologa excelente, no es apropiada en todas las situaciones, por lo que es importante elegir las tecnologas adecuadas y no slo el primero que me viene a la mente. Ser capaz de elegir las tecnologas adecuadas significa comprender no slo las caractersticas de las tecnologas, sino tambin la lista de prioridades de las necesidades, teniendo en cuenta las limitaciones que existen.
Requisitos Los requisitos son una parte importante del diseo y de las fases de prueba. Como parte del proceso de diseo general, se identifican los requisitos. A continuacin, el diseo debe ser validado en contra de los requisitos previos para la aplicacin y, por ltimo, que debe ser utilizado para poner a prueba el diseo despus de que se aplica. El objetivo de la recopilacin de requisitos proceso es generar una lista priorizada de los datos que necesita ser protegido y en qu nivel. Por ejemplo, el proceso debe tener en cuenta los componentes del sistema, la cantidad de tiempo y los datos de la organizacin puede darse el lujo de perder, y el rendimiento. Es importante tener en cuenta el "ecosistema de aplicaciones" - los componentes de datos del sistema que debe ser protegido. Por supuesto, es probable que el general de alta disponibilidad estrategia abarque proteccin de los recursos mltiples con diferentes requisitos y en contra de las diferentes causas de la prdida de tiempo de inactividad y de datos.
Pgina 25
UTP
Los dos requisitos principales alrededor de alta disponibilidad son comnmente conocidos como RTO y RPO. RTO representa Objetivo de Tiempo de Recuperacin y es el tiempo de inactividad mximo permitido cuando se produce un error. RPO significa Objetivo de Punto de Recuperacin y es el mximo permisible de prdida de datos en caso de avera. Aparte de la especificacin de un nmero, tambin es necesario contextualizar el nmero. Por ejemplo, al especificar que una base de datos debe estar disponible en el 99,99% de las veces, es que el 99,99% de 24x7 o hay una ventana de mantenimiento permitida? El requisito de que a menudo se pasa por alto es el rendimiento de carga de trabajo. Algunas tecnologas de alta disponibilidad puede afectar al rendimiento de carga de trabajo cuando se implementa (ya sea directamente o cuando se configura incorrectamente). Algunos ejemplos de requisitos son:
X base de datos debe estar disponible tan cerca como sea posible 24x7 y sin prdida de datos puede ser tolerada. Base de datos X tambin se basa en procedimientos almacenados en la base de datos principal y debe estar alojado en una instancia de SQL Server 2008 en un servidor de seguridad de dominio Y. Tablas A, B y C en la base de datos Z debe ser de 8 am a 6 pm los das de semana, sin prdida de datos puede ser tolerada, y todos ellos deben estar disponibles juntos. Despus de una conmutacin por error, el rendimiento de carga de trabajo no puede caer.
2.10. Limitaciones y Evaluacin de la tecnologa

Limitacin de anlisis es crucial para evitar la prdida de tiempo (y dinero) de disear una estrategia que no se puedan aplicar (por ejemplo, la estrategia implica la adicin de un centro de datos, pero el presupuesto total es de 10.000 dlares EE.UU. al ao). Las limitaciones no son slo en trminos de presupuesto (aunque eso suele ser la principal limitacin)-hay otras limitaciones no tcnicos, y una serie de limitaciones tcnicas a considerar. Las limitaciones no tcnicos incluyen: Alimentacin (para ms servidores, discos y acondicionamiento de aire asociada) Espacio (para ms servidores y equipos auxiliares) Aire acondicionado (para hacer frente a toda la produccin de calor extra de equipo original) Manpower (para instalar y mantener cualquier sistema agregado y equipos) Poltica y / o problemas de gestin (si los equipos estn implicados mltiples)
16
16
Alta Disponibilidad con SQL Server 2008 R2 - http://technet.microsoft.com/es-es/library/ff658546(v=sql.100).aspx
Pgina 26
UTP
Despus de que los requisitos de compromiso post-son conocidos entonces, y slo entonces, es el momento de evaluar las diversas tecnologas. No tiene sentido evaluar y elegir las tecnologas basadas en un conjunto de requisitos defectuoso y luego tener que repetir el proceso despus de que los requisitos se entienden mejor. Del mismo modo, el xito no viene de recoger una tecnologa inadecuada y luego tratar de hacer que funcione una funcin para la cual no fue diseado. Por ejemplo: El trasvase de registros no es adecuado para un diseo que requiere cero prdida de datos. Mirroring de base de datos no es adecuado para un diseo que requiere mltiples bases de datos de conmutacin por error de forma simultnea.
Al evaluar las tecnologas, es importante considerar todos los aspectos de las tecnologas, incluyendo: El costo monetario de la aplicacin de la tecnologa. La complejidad de la implementacin, configuracin y gestin de la tecnologa. La tecnologa de impacto en el rendimiento de carga de trabajo (si lo hay). El riesgo de prdida de datos si se utiliza la tecnologa. El potencial de tiempo de inactividad si la tecnologa se utiliza.
2.11. SQL Server 2008 R2 y sus arquitecturas tecnolgicas de Alta Disponibilidad

En el campo de la alta disponibilidad la visin de SQL Server es la de brindar un conjunto de soluciones integradas que funcionen tanto en entornos de empresas grandes cuya definicin de alta disponibilidad sea muy exigente como en pequeas empresas cuya necesidad de alta disponibilidad no sea tan exigente como la de las grandes empresas pero que tambin necesitan de soluciones que se adapten a sus necesidades y capacidad de inversin en tecnologa. Es as que el conjunto de soluciones que presenta SQL Server R2 permitir proveer de la tecnologa necesaria para satisfacer las necesidades de las PYME con una buena relacin de costo beneficio y manteniendo la calidad de servicio necesaria para ayudar al consolida miento de las Pequeas y Medianas Empresas haciendo as de la tecnologa un puente que permita el desarrollo y progreso. Es importante entender que ninguna de las soluciones de alta disponibilidad en SQL Server 2005 es una opcin aislada. Puede combinar dos o ms tcnicas dentro del mismo sistema para cubrir todas las eventualidades .
17
17
Pgina 27
UTP
2.11.1. Mirroring Mirroring de base de datos puede proveer una solucin failover casi instantnea para las bases de datos SQL Server 2008 R2. En esta edicin, mirroring de base de datos le permite mantener una copia actualizada de su base de datos en un servidor aparte para eventos de failover durante una falla del servidor. Esta seccin le ensea el concepto de mirroring una base de datos .
18
Figura 2: Mirroring Fuente: Microsoft - Alta Disponibilidad con SQL Server 2008 R2
2.11.1.1. Definicin Mirroring de base de datos funciones manteniendo un servidor en standby que tiene una copia de la base de datos. Si el servidor de produccin falla, las aplicaciones pueden ser redireccionadas al servidor en standby. El failover puede ser la mas instantnea, tpicamente necesita de menos de tres segundos si es realizada automticamente. La base de datos sobre la cual se hace el mirror es usualmente referida como la base de datos principal; el mirror es llamado la base de datos mirror. (Debe entender que estos trminos son puramente relativo, ya que es posible para las bases de datos cambiar los roles como resultados de failover.) Los servidores que tienen estas bases de datos se los llama partner servers .
18
18
Pgina 28
UTP
2.11.1.2. Estados Hacer un mirror de una base de datos envuelve algunos pasos, durante los cuales la base de datos pasa por algunos estados: Estado de sincronizacin: Para permitir hacer el mirror, la base de datos mirror debe ser creada, y todos los cambios realizados a la base de datos principal tambin deben ser aplicados a la base de datos mirror. Mientras que esto sucede, la base de datos principal y la mirror estn en estado de sincronizacin.
Estado de sincronizacin: Una vez que la base de datos mirror se actualizo con la base de datos principal, ambas estn en estado de sincronizacin. Todos los cambios hechos a la base de datos principal sern automticamente hechos en la base de datos mirror para asegurarse que permanecen sincronizadas.
Estado desconectado: Si un servidor pierde conexin con su servidor/es partner como una falla de la red, la base de datos pasa a estado desconectado.
Estado Suspendido: El mirror puede ser detenido temporalmente, usualmente como resultado de acciones hechas por administrador de la base de datos. Una vez que la base de datos no esta siendo espejada, entra en estado suspendido.
2.11.1.3. Modos de Operacin Los mirror de las bases de datos pueden operar en dos modos, que determinan el grado de exposicin a la perdida de datos y la naturaleza del failover que pueda realizarse:
Modo sincronizado: los registros de transaction log son transmitidos de la base de datos principal a la base de datos mirror, y aplicados a la base de datos mirror antes de ser hechos en la base de datos principal. Este mecanismo garantiza que no habr transacciones perdidas, a expensas del tiempo adicional que requiere completar una transaccin. Este modo soporta failover manual y automtico .
19
19
Pgina 29
UTP
Modo desincronizado: las transacciones son hechas primero en el servidor principal antes de enviar registros log a la base de datos mirror. La base de datos mirror esta en estado de desincronizacion perpetuo. Las aplicaciones no son demoradas mientras la comunicacin con el servidor mirror se produce. Esto incrementa el trabajo al peligro de perder la sincronizacin con la base de datos mirror si la comunicaron falla. El modo desincronizado no soporta failover, aunque un administrador de base de datos puede realizar pasos para forzar el uso de una base de datos mirror en caso que la base de datos principal este no disponible.
2.11.1.4. Servidores Servidor de Base de Datos Principal El servidor de base de datos principal tiene la base de datos principal. Este es el servidor al cual los usuarios y aplicaciones se conectan normalmente para realizar sus tareas.
Servidor de la Base de Datos Mirror El servidor de la base de datos mirror tiene la base de datos mirror. Los usuarios y aplicaciones no se conectan a este usualmente a menos que ocurra un failover y este servidor es hecho el servidor de base de datos principal. En este caso, luego que la comunicaron ha sido establecida con el servidor principal, el servidor principal original puede tomar el rol de servidor mirror.
Servidor Testigo Un Servidor Testigo monitorea los servidores de base de datos principal y mirror y verifica que ambos servidores estn disponibles. Como esto no es un trabajo intensivo, una computadora corriendo SQL Server puede actuar como servidor testigo para cualquier set de mirrors. Si el servidor de la base de datos principal o mirror fallan, el servidor testigo puede trabajar con el servidor que sobreviva para reconectarse o reaccionar apropiadamente. Las acciones que se realizan, que dependen de la configuracin en curso de set de mirrors, son descriptas mas tarde en esta seccin .
20
20
Pgina 30
UTP
2.11.2. Replicacin La replicacin es un conjunto de tecnologas destinadas a la copia y distribucin de datos y objetos de base de datos desde una base de datos a otra, para luego sincronizar ambas bases de datos y mantener su coherencia. La replicacin permite distribuir datos entre diferentes ubicaciones y entre usuarios remotos o mviles mediante redes locales y de rea extensa, conexiones de acceso telefnico, conexiones inalmbricas e Internet. La replicacin es un amplio conjunto de tecnologas que permiten que los datos se copien y se distribuyan entre los servidores y luego sincronicen para mantener la consistencia.
2.11.2.1. Tipos Replicacin Transaccional La replicacin transaccional implica la creacin de una publicacin (datos de una o varias tablas de una base de datos) en una base de datos de publicacin en una instancia de Publisher. El estado inicial de la publicacin se copia en una o ms instancias de abonado donde se convierte en la suscripcin en una base de datos de suscripcin. Este proceso de inicializacin se puede realizar utilizando una copia de seguridad de base de datos o utilizar una instantnea .
21
Figura 3: Replicacin Transaccional Fuente: Microsoft - Alta Disponibilidad con SQL Server 2008 R2
21
Pgina 31
UTP
Si el publicador va replicacin offline, transaccional se reinicia automticamente cuando vuelva a conectarse. Adems, si un abonado se desconecta, las operaciones que deben propagarse a ella se llevan a cabo en la base de datos de distribucin hasta que el suscriptor se conecte de nuevo. El almacenamiento intermedio de las operaciones es necesario para que las operaciones no tengan que ser almacenadas en el registro de transacciones de la base de datos de publicacin. Lo ideal sera que el distribuidor es una instancia independiente de SQL Server que se ejecuta en un servidor independiente, ya que esto proporciona redundancia adicional y descargas de la carga de trabajo de distribucin desde el publicador o suscriptor casos. Al igual que con el trasvase de registros, la replicacin no proporciona deteccin automtica de fallo de Publisher o failover automtico a un suscriptor, por lo que es tambin una solucin de reserva activo. Adems, hay una latencia entre una transaccin que ocurre en el publicador y se propaga a los suscriptores, por lo que la prdida de datos es posible en el momento de una falla.
Replicacin Peer to Peer Peer-to-peer replicacin transaccional permite que varios servidores
(llamados nodos) para actuar como publicadores y suscriptores para los mismos datos. Un cambio realizado en un nodo en la topologa peer-to-peer se propaga a todos los dems nodos, con todos los nodos que actan como publicador, suscriptor y, Distribuidor (por lo general). En la replicacin peer-to-peer, los datos de alta disponibilidad y soluciones son fcilmente escalables para cargas de trabajo fuera de la consulta.
Pgina 32
UTP
La figura anterior muestra tres bases de datos participantes que proporcionan datos para una organizacin de soporte de software en todo el mundo, con oficinas en Los Angeles, Londres y Taipei. Los ingenieros de soporte tcnico de cada oficina reciben llamadas de clientes e introducir y actualizar la informacin de cada llamada al cliente. Las zonas horarias de los tres oficios son ocho horas de diferencia, por lo que no hay solapamiento en la jornada laboral. A medida que la oficina de Taipei se cierra, la oficina de Londres se est abriendo para el da. Si hay una llamada en curso cuando se cierra una oficina, la llamada se transfiere a un representante en la oficina de al lado para abrir. Peer-to-peer replicacin transaccional no tiene deteccin automtica o conmutacin automtica por error, por lo que los distintos nodos de la topologa de proporcionar abrigo copias de reserva de los datos publicados. Adems, peer-to-peer replicacin transaccional tiene los mismos problemas de latencia de la replicacin transaccional
2.11.3. Log Shipping El trasvase de registros es la forma ms sencilla de proporcionar una o ms copias redundantes de una sola base de datos. La base de datos principal en el servidor principal est respaldada y luego se restaura a uno o ms servidores secundarios. Copias de seguridad del registro de transacciones son entonces repetidas veces tomadas de la base de datos principal, enviada al servidor secundario (s), y luego se restablece. De esta manera, las bases de datos secundarias se actualiza continuamente con los cambios de la base de datos principal a travs del registro de transacciones restaura. Un opcional de tercera instancia de SQL Server se puede utilizar para supervisar los servidores primario y secundario para asegurar que las copias de seguridad del registro de transacciones se estn tomando y restaurado regularmente. Hay varias opciones de configuracin, como la frecuencia con una copia de seguridad del registro de transacciones se toma en el servidor principal y con qu frecuencia las copias de seguridad del registro de transacciones se restauran en el servidor secundario (s). Un servidor de envo de registro secundario tambin se puede configurar para tener un retardo de carga (es decir, un perodo de tiempo de espera antes de la restauracin de una copia de seguridad de registro de transacciones). Por ejemplo, si un servidor secundario de trasvase de registros se ha configurado con un retardo de carga de 8 horas y alguien elimina accidentalmente una tabla de la base de datos principal dentro de este perodo, la tabla sigue existiendo en el servidor secundario y se puede recuperar .
22
22
Pgina 33
UTP
Un trasvase de registros secundario tambin puede ser configurado para permitir acceso de slo lectura a la base de datos de registro de transacciones entre las operaciones de restauracin. Esto permite que la base de datos que se utilizarn a efectos de notificacin, lo que maximiza el uso del servidor redundante, aunque con alguna configuracin adicional. El trasvase de registros se puede considerar simplemente como copia de seguridad, copiar, restaurar, repite. Debido a que el trasvase de registros implica un proceso de varias etapas que no puede garantizar la prdida de datos cero, y no tiene ningn mecanismo integrado para automatizar la conmutacin por error del servidor principal al servidor secundario, se denomina una solucin de reserva activo. La inactividad inherente a traer una lnea de trasvase de registros del servidor secundario vara en funcin de si hay ms copias de seguridad del registro de transacciones para restaurar la base de datos y si deben ser llevados a un punto tan reciente como sea posible. Adems, ni la deteccin de fallo del servidor primario ni la conmutacin por error a un servidor secundario son detectadas automticamente por las aplicaciones de cliente, lgica de manera adicional debe ser aadido al cliente o, posiblemente, en un nivel intermedio. El proceso de envo de registro se controla a travs de una serie de trabajos del Agente SQL Server que se realizan las copias de seguridad, copias, restauraciones y monitoreo. La figura 4 muestra una configuracin de trasvase de registros con la instancia del servidor principal, tres instancias del servidor secundario, y una instancia de servidor de supervisin .
23
23
Pgina 34
UTP
2.12. Conceptos Relacionados

Tiempo de recuperacin esta cercanamente relacionado con la disponibilidad, que es el tiempo total requerido para un apagn planificado o el tiempo requerido para la recuperacin completa de un apagn no planificado. Tiempo de recuperacin puede ser infinito con ciertos diseos y fallos del sistema, recuperacin total es imposible. Uno de tales ejemplos es un incendio o inundacin que destruye un centro de datos y sus sistemas cuando no hay un centro de datos secundario para recuperacin frente a desastres. Otro concepto relacionado es disponibilidad de datos, que es el grado para el cual las bases de datos y otros sistemas de almacenamiento de la informacin que registran y reportan fielmente transacciones del sistema. Especialistas de gestin de la informacin frecuentemente enfocan separadamente la disponibilidad de datos para determinar perdida de datos aceptable o actual con varios eventos de fracasos. Algunos usuarios pueden tolerar interrupciones en el servicio de aplicacin pero no perdida de datos
2.13. Herramientas de Desarrollo de Proyecto

2.13.1. Base de Datos Una base de datos es una coleccin de informacin organizada de forma que un programa de ordenador pueda seleccionar rpidamente los fragmentos de datos que necesite. Una base de datos es un sistema de archivos electrnico. Una base de datos es una entidad en la cual se pueden almacenar datos de manera estructurada, con la menor redundancia posible. Diferentes programas y diferentes usuarios deben poder utilizar estos datos. Por lo tanto, el concepto de base de datos generalmente est relacionado con el de red ya que se debe poder compartir esta informacin. De all el trmino base. "Sistema de informacin" es el trmino general utilizado para la estructura global que incluye todos los mecanismos para compartir datos que se han instalado .
24
Figura 6: Base de Datos Fuente: Bases de Datos - http://es.kioskea.net/contents/bdd/bddintro.php3
24
Bases de Datos - http://es.kioskea.net/contents/bdd/bddintro.php3
Pgina 35
UTP
Una base de datos proporciona a los usuarios el acceso a datos, que pueden visualizar, ingresar o actualizar, en concordancia con los derechos de acceso que se les hayan otorgado. Se convierte ms til a medida que la cantidad de datos almacenados crece. Una base de datos puede ser local, es decir que puede utilizarla slo un usuario en un equipo, o puede ser distribuida, es decir que la informacin se almacena en equipos remotos y se puede acceder a ella a travs de una red. 2.13.2. Microsoft SQL Server Es un sistema para la gestin de bases de datos producido por Microsoft basado en el modelo relacional. Sus lenguajes para consultas son T-SQL y ANSI SQL. Microsoft SQL Server constituye la alternativa de Microsoft a otros potentes sistemas gestores de bases de datos como son Oracle, PostgreSQL o MySQL.
2.13.2.1. Caractersticas: Soporte de transacciones. Soporta procedimientos almacenados. Incluye tambin un entorno grfico de administracin, que permite el uso de comandos DDL y DML grficamente. Permite trabajar en modo cliente-servidor, donde la informacin y datos se alojan en el servidor y los terminales o clientes de la red slo acceden a la informacin.
Este sistema incluye una versin reducida, llamada MSDE con el mismo motor de base de datos pero orientado a proyectos ms pequeos, que en sus versiones 2005 y 2008 pasa a ser el SQL Express Edition, que se distribuye en forma gratuita. Es comn desarrollar completos proyectos
complementando Microsoft SQL Server y Microsoft Access a travs de los llamados ADP (Access Data Project). De esta forma se completa la base de datos (Microsoft SQL Server), con el entorno de desarrollo (VBA Access), a travs de la implementacin de aplicaciones de dos capas mediante el uso de formularios Windows .
25
25
Bases de Datos - http://es.kioskea.net/contents/bdd/bddintro.php3
Pgina 36
UTP
2.13.2.2. Ediciones SQL Server Express Edition: gratis, limitada en espacio (hasta 5 GB) y memoria. Incluye menos funcionalidades. SQL Server WorkGroup Edition): no tiene funcionalidades avanzadas como integration services. Sin restricciones de tamao ni usuarios, ideados para grupos de trabajos pequeos. Restringida en memoria. SQL Server Standard Edition: sin ningn tipo de restricciones. Permite ejecucin hasta en 4 CPUs. SQL Server Enterprise Edition: completa, permite particionamiento. SQL Server Developer Edition: para desarrolladores
Historia de versiones Versin 1.0 (OS/2) 4.21 (WinNT) 6.0 6.5 7.0 8.0 8.0 9.0 10.0 10.50 11.0 Ao 1989 1993 1995 1996 1998 1999 2000 2003 2005 2008 2010 2012 Nombre de la versin SQL Server 1-0 SQL Server 4.21 SQL Server 6.0 SQL Server 6.5 SQL Server 7.0 SQL Server 7.0 OLAP Tools SQL Server 2000 SQL Server 2000 64-bit Edition SQL Server 2005 SQL Server 2008 SQL Server 2008 R2 SQL Server 2012 Nombre clave SQL SEQUEL SQL95 Hydra Sphinx Plato Shiloh Liberty Yukon Katmai Kilimanjaro Denali
Tabla 2: Versiones SQL Server Fuente: http://www.monografias.com/trabajos81/conceptos-sql-server/conceptos-sql-server.shtml
Pgina 37
UTP
2.14. Metodologas de Desarrollo de Proyecto

2.14.1. UML Es un lenguaje para especificar, construir, visualizar y documentar los artefactos de un sistema de software orientado a objetos (OO). Un artefacto es una informacin que es utilizada o producida mediante un proceso de desarrollo de software. UML se quiere convertir en un lenguaje estndar con el que sea posible modelar todos los componentes del proceso de desarrollo de aplicaciones. Sin embargo, hay que tener en cuenta un aspecto importante del modelo: no pretende definir un modelo estndar de desarrollo, sino nicamente un lenguaje de modelado. Otros mtodos de modelaje como OMT (Object Modeling Technique) s definen procesos En UML los procesos de desarrollo son diferentes segn los distintos dominios de trabajo; no puede ser el mismo el proceso para crear una aplicacin en tiempo real, que el proceso de desarrollo de una aplicacin orientada a gestin, por poner un ejemplo. Las diferencias son muy marcadas y afectan a todas las faces del proceso. El mtodo del UML recomienda utilizar los procesos que otras metodologas tienen definidos.
2.14.2. Modelado de objetos En la especificacin del UML podemos comprobar que una de las partes que lo componen es un metamodelo formal. Un metamodelo es un modelo que define el lenguaje para expresar otros modelos. Un modelo en OO es una abstraccin cerrada semnticamente de un sistema y un sistema es una coleccin de unidades conectadas que son organizadas para realizar un propsito especfico. Un sistema puede ser descripto por uno o ms modelos, posiblemente desde distintos puntos de vista. El UML es una tcnica de modelado de objetos y como tal supone una abstraccin de un sistema para llegar a construirlo en trminos concretos. El modelado no es ms que la construccin de un modelo a partir de una especificacin. Un modelo es una abstraccin de algo, que se elabora para comprender ese algo antes de construirlo. El modelo omite detalles que no resultan esenciales para la comprensin del original y por lo tanto facilita dicha comprensin. Los modelos se utilizan en muchas actividades de la vida humana: antes de construir una casa el arquitecto utiliza un plano, los msicos representan la msica en forma de notas musicales, los artistas pintan sobre el lienzo con carboncillos antes de empezar a utilizar los leos, etc. Unos y otros abstraen una realidad compleja sobre unos bocetos, modelos al fin y al cabo .
26
26
Ingeniera de Software UML - http://www.monografias.com/trabajos5/insof/insof.shtml
Pgina 38
UTP
Se consigue un modelo completo de la realidad cuando el modelo captura los aspectos importantes del problema y omite el resto. Los lenguajes de programacin que estamos acostumbrados a utilizar no son adecuados para realizar modelos completos de sistemas reales porque necesitan una especificacin total con detalles que no son importantes para el algoritmo que estn implementando. En OMT se modela un sistema desde tres puntos de vista diferentes donde cada uno representa una parte del sistema y una unin lo describe de forma completa. En esta tcnica de modelado se utiliz una aproximacin al proceso de implementacin de software habitual donde se utilizan estructuras de datos (modelo de objetos), las operaciones que se realizan con ellos tienen una secuencia en el tiempo (modelo dinmico) y se realiza una transformacin sobre sus valores (modelo funcional). UML utiliza parte de este planteamiento obteniendo distintos puntos de vista de la realidad que modela mediante los distintos tipos de diagramas que posee. Con la creacin del UML se persigue obtener un lenguaje que sea capaz de abstraer cualquier tipo de sistema, sea informtico o no, mediante los diagramas, es decir, mediante representaciones grficas que contienen toda la informacin relevante del sistema. Un diagrama es una representacin grfica de una coleccin de elementos del modelo, que habitualmente toma forma de grafo donde los arcos que conectan sus vrtices son las relaciones entre los objetos y los vrtices se corresponden con los elementos del modelo. Los distintos puntos de vista de un sistema real que se quieren representar para obtener el modelo se dibuja d forma que se resaltan los detalles necesarios para entender el sistema.
2.14.3. Artefactos Un artefacto es una informacin que es utilizada o producida mediante un proceso de desarrollo de software. Pueden ser artefactos un modelo, una descripcin o un software. Los artefactos de UML se especifican en forma de diagramas, stos, junto con la documentacin sobre el sistema constituyen los artefactos principales que el modelador puede observar. Se necesita ms de un punto de vista para llegar a representar un sistema. UML utiliza los diagramas grficos para obtener estos distintos puntos de vista de un sistema : Diagramas de Implementacin. Diagramas de Comportamiento o Interaccin. Diagramas de Casos de uso. Diagramas de Clases. .
27 27
Pgina 39
UTP
Diagramas de Implementacin Se derivan de los diagramas de proceso, aunque presentan algunas modificaciones. Los diagramas de implementacin muestran los aspectos fsicos del sistema. Incluyen la estructura del cdigo fuente y la implementacin, en tiempo de implementacin. Existen dos tipos Diagramas de componentes y Diagrama de plataformas despliegue.
Diagramas de Componentes Muestra la dependencia entre los distintos componentes de software, incluyendo componentes de cdigo fuente, binario y ejecutable. Un componente es un fragmento de cdigo software (un fuente, binario o ejecutable) que se utiliza para mostrar dependencias en tiempo de compilacin.
Diagrama de Plataformas o Despliegue Muestra la configuracin de los componentes hardware, los procesos, los elementos de procesamiento en tiempo de ejecucin y los objetos que existen en tiempo de ejecucin. En este tipo de diagramas intervienen nodos, asociaciones de comunicacin, componentes dentro de los nodos y objetos que se encuentran a su vez dentro de los componentes. Un nodo es un objeto fsico en tiempo de ejecucin, es decir una mquina que se compone habitualmente de, por lo menos, memoria y capacidad de procesamiento, a su vez puede estar formada por otros componentes.
Diagramas de Interaccin o Comportamiento Muestran las interacciones entre objetos ocurridas en un escenario (parte) del sistema. Hay varios tipos: Diagrama de Secuencia. Diagrama de Colaboracin. Diagrama de Estado. Diagrama de Actividad.
Diagrama de Secuencia. Muestran las interacciones entre un conjunto de objetos, ordenadas segn el tiempo en que tienen lugar. En los diagramas de este tipo intervienen objetos, que tienen un significado parecido al de los objetos representados en los diagramas de colaboracin, es decir son instancias concretas de una clase que participa en la interaccin .
28 28
Pgina 40
UTP
Diagrama de Colaboracin Muestra la interaccin entre varios objetos y los enlaces que existen entre ellos. Representa las interacciones entre objetos organizadas alrededor de los objetos y sus vinculaciones. A diferencia de un diagrama de secuencias, un diagrama de colaboraciones muestra las relaciones entre los objetos, no la secuencia en el tiempo en que se producen los mensajes. Los diagramas de secuencias y los diagramas de colaboraciones expresan informacin similar, pero en una forma diferente.
Diagramas de Actividad Son similares a los diagramas de flujo de otras metodologas OO. En realidad se corresponden con un caso especial de los diagramas de estado donde los estados son estados de accin y las transiciones vienen provocadas por la finalizacin de
las acciones que tienen lugar en los estados de origen. Siempre van unidos a una clase o a la implementacin de un caso de uso o de un mtodo.
Diagramas de Estado Representan la secuencia de estados por los que un objeto o una interaccin entre objetos pasa durante su tiempo de vida en respuesta a estmulos (eventos) recibidos. Representa lo que podemos denominar en conjunto una mquina de estados. Un estado en UML es cuando un objeto o una interaccin satisfacen una condicin, desarrolla alguna accin o se encuentra esperando un evento. Como en todas las metodologas OO se envan mensajes, en este caso es la accin de la que puede enviar mensajes a uno o varios objetos destino.
Diagramas de Casos de Uso Unos casos de uso es una secuencia de transacciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interaccin con los usuarios y/o otros sistemas. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar como reacciona una respuesta a eventos que se producen en el mismo .
29
29
Pgina 41
UTP
2.14.4. Caractersticas: Adems de los conceptos extrados de mtodos anteriores, se han aadido otros nuevos que vienen a suplir carencias antiguas de la metodologa de modelado. Estos nuevos conceptos son los siguientes: Definicin de estereotipos: un estereotipo es una nueva clase de elemento de modelado que debe basarse en ciertas clases ya existentes en el metamodelo y constituye un mecanismo de extensin del modelo. Responsabilidades. Mecanismos de extensibilidad: estereotipos, valores etiquetados y restricciones. Tareas y procesos. Distribucin y concurrencia (para modelar por ejemplo ActiveX/DCOM y CORBA). Patrones/Colaboraciones. Diagramas de actividad (para reingeniera de proceso de negocios) Clara separacin de tipo, clase e instancia. Refinamiento (para manejar relaciones entre niveles de abstraccin). Interfaces y componentes .
30
2.15. Sistema de Hiptesis

Con la implantacin de metodologas de Alta Disponibilidad de servidores de base de datos podemos incrementar el nivel de rentabilidad en un 80%; por consiguiente tambin se lograr mantener la disponibilidad en un 97% en los servidores de base de datos.
2.16. Sistemas de Variables

a. Costo asociado a la indisponibilidad de datos. b. Cantidad de cadas de servidores de base de datos.
30
Pgina 42
UTP
CAPTULO 3: MARCO METODOLGICO
3.1. Nivel Anlisis de la Investigacin

El proyecto se basa en un nivel de investigacin exploratoria, descriptiva y explicativa, ya que se expondr las caractersticas, beneficios y/o limitaciones de las diferentes metodologas de alta disponibilidad aplicadas a los servidores de base datos.
Descriptiva: Tiene como objetivo medir las caractersticas del impacto de las metodologas de alta disponibilidad en los servidores de base de datos crticos, estas caractersticas pueden ser cantidad de servidores, tamao de base de datos, distribucin de aplicaciones, cadas en un determinado tiempo, complejidad de la arquitectura de red, tipos de tecnologa. A partir del levantamiento de la informacin de las variables, las expresaremos cuantitativamente para poder calcular y medir: cantidad de cadas de servidores de base de datos (conectividad) y el costo asociado a la indisponibilidad de datos (S/.).
3.2. Diseo de la Investigacin

3.2.1. Mtodos Para el desarrollo de la investigacin se empleara los siguientes mtodos: 3.2.1.1. Mtodo Experimental Dado que se llevara a cabo un estudio de todos los historiales (logs) de cadas de los servidores de base de datos para recopilar informacin y posterior anlisis y comprobacin. Primero: se recoger informacin de problemas de acceso a la informacin por cadas del servidor de base de datos y se determinar la cantidad total de tiempo (horas) mensuales y anuales en que no se tiene acceso. Segundo: una vez implantado las metodologas de alta disponibilidad de servidores de base de datos se determinar el nuevo tiempo diario que no se tiene acceso a la informacin. Esta informacin se analizar y evaluar para determinar el nivel de disponibilidad que se lleg a obtener en base a comparacin de resultados.
3.2.1.2. Mtodo de Observacin Mediante la cual se va a poder interactuar directa y claramente con los servidores de base de datos y poder medir la magnitud del problema y la variable relacionada.
Pgina 43
UTP
3.2.1.3. Mtodo de Medicin Para la obtencin y comparacin de datos numricos y relacionados a la disponibilidad de la informacin, es decir la cantidad de cadas o indisponibilidad de la informacin por cadas eventuales de los servidores de base de datos.
3.2.2.
Recopilacin de Informacin: Segn la informacin recolectada mediante el anlisis de datos de informacin en un Data Center se cuenta con los siguientes servidores: Servidores de Base de Datos: 7 Servidores (Per, Brasil, Venezuela, Centro Amrica, Colombia, Asia, Ecuador) 10 Base de Datos 7 Servidores de Reporting Services 3 Servidores de Business Intelligence
De acuerdo al mtodo de observacin y medicin, se lleg a determinar el siguiente cuadro de disponibilidad:
AO 2009 2010 2011
TIEMPO OFFLINE/AO 36 das 24 das 24 das
TIEMPO OFFLINE/MES 72 hrs 48 hrs 48 hrs
TIEMPO OFFLINE/DA 2 hrs 1.5 hrs 1.2 hrs
3.2.2.1. Tcnicas Para lograr la obtencin de informacin, conocimiento y llevar el control de los datos se hacer uso de las siguientes tcnicas: Entrevista Dirigidas al administrador de base de datos para obtener informacin especfica de cadas de los servidores de base datos, como datos de tiempo que se encuentran detenidos los procesos de pagos y cobros.
Observacin Directa Utilizado para que mediante la observacin de los factores que influyen en el comportamiento de la variable se haga una recoleccin de datos.
Pgina 44
UTP
Anlisis de Datos Tcnica mediante la cual se va a organizar, describir y analizar los logs recogidos tanto del sistema operativo con del motor de base de datos. Este anlisis me permitir tener una bitcora de informacin y as poder tener una mejor organizacin en el manejo de la informacin.
3.2.2.2. Instrumentos Dentro de los instrumentos a usaremos para recolectar y registrar informacin son los siguientes: Listas de chequeos: que nos permitirn registrar a groso modo si la arquitectura de alta disponibilidad a implementar se adapta a los requisitos de disponibilidad que requiere la empresa.
Formularios: donde contenga toda la informacin tanto de los servidores de base de datos como los sistemas que interactan con estos, as podremos clasificarlos por su criticidad. Estos formularios nos permitirn calcular el costo/tiempo de inactividad y determinar las tasas de disponibilidad y objetivos de recuperacin.
Test de conexin: me permitir medir el tiempo de inactividad no planificado y previsto. Se debe tener en cuenta el momento de el tiempo de inactividad (por ejemplo, a fin de mes, cierre trimestral, y del pico de los periodos de rebajas), y se debe medir el tiempo de inactividad desde la perspectiva del usuario.
Recolectada la informacin mediante los mtodos, tcnicas e instrumentos mencionados anteriormente, aplicaremos la metodologa RUP para el anlisis y diseo de la solucin. El RUP nos permitir adaptarnos al nuevo proceso de alta disponibilidad, equilibrando prioridades de disponibilidad de las aplicaciones, elevar el nivel de abstraccin, para poder satisfacer de la mejor manera los requisitos, un alto nivel de abstraccin nos permitir escoger mejor la solucin arquitectnica de alta disponibilidad a utilizar. Por ltimo enfocarnos en el control de calidad no solo al final cada iteracin del proyecto, sino en todos los aspectos de la implementacin.
Pgina 45
UTP
3.2.3.
Actividades: Modelado del Negocio: Entender la estructura de distribucin, conexin de los servidores de base de datos de la organizacin, para las cuales la arquitectura de alta disponibilidad ser implementada. Entender a la perfeccin el problema de las cadas de servidores e identificar las potenciales mejoras.
Requisitos: Establecer y mantener un acuerdo entre los stakeholders lo que la arquitectura de alta disponibilidad a implementar podra hacer. Mediante la recoleccin de informacin detallada anteriormente podremos tener una base para estimar costos y tiempo de desarrollo.
Anlisis y Diseo: Trasformar los requisitos al diseo de la solucin. Desarrollar la nueva arquitectura de alta disponibilidad.
Implementacin: Planificar que arquitecturas debern ser implementadas dependiendo de la criticidad de los servidores y en que orden ser integrados. Si se encuentra algunos errores de diseo, se notificar.
Pruebas: Encontrar y documentar defectos en la calidad de la arquitectura de alta disponibilidad. Proveeremos la validacin de los supuestos realizados en el diseo y especificacin de requisitos por medio de demostraciones concretas. Verificar las funciones de la arquitectura de alta disponibilidad segn lo diseado, al mismo tiempo que los requisitos tengan una apropiada implementacin.
Despliegue: Probar la arquitectura de alta disponibilidad en su entorno de ejecucin final. Distribuir la arquitectura. Implementar la arquitectura. Migrar bases de datos.
Pgina 46
UTP
Gestin del proyecto: Contratar personal, ejecutar y monitorear el proyecto. Proveer un marco de trabajo para gestionar riesgos.
Entorno: Seleccin y adquisicin de herramientas. Configuracin del proceso. Mejora del proceso. Servicios tcnicos.
Los instrumentos a utilizar para desarrollar nuestra metodologa son: Documento Visin Especificacin de Requisitos Diagramas de caso de uso Diagrama de Secuencia Diagrama de estados Diagrama de Colaboracin Mapa de comportamiento a nivel de hardware.
3.3. METODOLOGA PARA EL ESTUDIO DE FACTIBILIDAD DE LA SOLUCIN

Para medir la factibilidad o viabilidad de la implementacin de alta disponibilidad a los servidores de base de datos, tomaremos como referencia el porcentaje de alta disponibilidad obtenido en nuestros casos de xito (ver pag 5 y 9).
3.3.1.
Casos de xito: Empresa: BBVA Bancomer. Esta empresa al igual que la nuestra, retornaba la disponibilidad de sus servidores manualmente lo que ocasionaba el detenimiento de las transacciones bancarias que realizaban por internet. BBVA Bancomer aplic la arquitectura de alta disponibilidad Mirroring, mejorando su nivel de disponibilidad en sus servidores de base de datos en un 55%, mejorando as sus servicios de transacciones bancarias.
Pgina 47
UTP
Caso de xito 2: Empresa: Mercadotecnia Ideas y Tecnologa. Esta empresa tena implementada la arquitectura de alta disponibilidad Mirroring solo a las bases de datos donde se almacenaban la informacin de las empresas proveedoras. Despus de un estudio de disponibilidad de sus servidores, se decidi aplicar la arquitectura de alta disponibilidad Mirroring las bases de datos crticas y Log Shipping a los servidores multiplataforma, mejorando su nivel de disponibilidad en sus servidores de base de datos en un 45%.
Teniendo como porcentaje de tiempo OFFLINE de los ltimos 3 aos: AO 2009 2010 2011 TIEMPO OFFLINE/AO 36 das 24 das 24 das TIEMPO OFFLINE/MES 72 hrs 48 hrs 48 hrs TIEMPO OFFLINE/DA 2 hrs 1.5 hrs 1.2 hrs
El siguiente cuadro muestra las ventas anuales de los ltimos 3 aos: AO 2009 2010 2011 Ventas Mensuales ($) 18 000 22 000 24 000 Ventas Anuales ($) 216 000 264 000 288 000
Mediante la siguiente frmula podremos calcular la prdida de ventas al no contar con una arquitectura de alta disponibilidad:
% Prdida (Mensual) = (Horas OFFLINE Mensual x 100 por ciento) / 720 hrs
Para calcular la disponibilidad, lo realizamos con la siguiente frmula: Disponibilidad = ((A B)/A) x 100 por ciento) Donde: A = Horas comprometidas de disponibilidad: 24 x 365 = 8,760 Horas/ao. B = Nmero de horas fuera de lnea (Horas de "cada del sistema" durante el tiempo de disponibilidad comprometido).
Pgina 48
UTP
Al aplicar las arquitecturas de Alta Disponibilidad podremos medir el aumento de rentabilidad mediante: Rentabilidad Actual = Rentabilidad del ultimo ao (Rentabilidad del ultimo ao x %Prdida)
3.3.2.
Costos de Hardware y Software
Hardware
Dispositivos Servidor (RX 6600) UPS Interactivo Cableado (por metro) Total Cantidad 2 2 70 Precio S/. 6,000.00 S/. 300.00 S/. 7.00 Subtotal S/. 12,000.00 S/. 600.00 S/. 490.00 S/. 13,090.00
Software
Software/ Licencia Windows Server 2008 R2 SQL Server 2008 R2 Total Cantidad 2 2 Precio S/. 1,500.00 S/. 350.00 Subtotal S/. 3,000.00 S/. 700.00 S/. 3,700.00
Total = Total Hardware + Total Software Total = 13,090.00 + 3,700.00 Total = S/. 16,790.00
Teniendo la informacin del tiempo fuera de lnea de las aplicaciones, las ventas anuales de la organizacin, costos de hardware/ software y las frmulas de medicin de prdidas y alta disponibilidad, aplicaremos para medir y validar el impacto cuantitativo de nuestra solucin, el mtodo de Simulacin estadstica: Mtodo de Montecarlo Este mtodo nos permitir aproximar y evaluar con exactitud nuestras expresiones matemticas mencionadas anteriormente. Las pruebas a realizar mediante este mtodo se podrn realizar simplemente en una hoja de clculo como Microsoft Excel. Teniendo como premisas los dos casos de xito mencionados anteriormente, donde las arquitecturas han mejorado el porcentaje de alta disponibilidad, y teniendo como porcentaje entre 45 y 55 por ciento, tomaremos como base de medicin un +/- 5%.
Pgina 49
UTP
La clave de la simulacin de Montecarlo, consiste en crear un modelo matemtico de nuestra arquitectura de alta disponibilidad con sus respectivos, procesos y/o actividades que se quiere analizar, identificando aquellas variables (inputs del modelo) cuyo comportamiento aleatorio determina el comportamiento global de la solucin.
3.3.3.
Tcnicas:
Establecer distribuciones de probabilidad. La idea inicial es la generacin de valores para las variables que componen el modelo a efectuar. Tenemos una gran variabilidad de punto, algunos de ellos son: el tiempo de inactividad de los servidores de base datos, porcentaje de prdidas en ventas diarias, el tiempo deservicio de aplicaciones. Y una manera fcil de establecer una distribucin de probabilidad de una variable es a travs de examen histrico. La frecuencia relativa para cada resultado de una variable se encuentra al dividir la frecuencia de la observacin entre el nmero total de observaciones Interpretar la frecuencia relativa como la probabilidad de que ocurra una cada en los servidores de base de datos. Recoleccin de datos y determinacin de frecuencias relativas Asignacin de nmeros aleatorios Formulacin del modelo Solucin Anlisis
Pgina 50
UTP
CAPTULO 4: ASPECTOS ADMINISTRATIVOS
4.1. NDICE PRELIMINAR DE LA TESIS

INTRODUCCIN
1.
Formulacin del Problema 1.1. Planteamiento del Problema 1.2. Antecedentes de solucin 1.2.1. Caso de xito 1.3. Propuesta de solucin 1.4. Alcance de la propuesta 1.5. Justificacin 1.5.1. Por qu 1.5.2. Para qu 1.6. Objetivos 1.6.1. Objetivo General 1.6.2. Objetivos Especficos
2.
Marco Terico 2.1. Antecedentes de la Investigacin 2.1.1. Caso de xito 2.2. Alta Disponibilidad 2.3. Medicin de la Disponibilidad 2.4. Niveles de Disponibilidad 2.5. Tiempo Fuera de Servicio 2.5.1. Tiempo Fuera de Servicio Planeado 2.5.2. Tiempo Fuera de Servicio No Planeado 2.5.3. Estrategias 2.6. Clasificacin de desastres 2.7. Tipos de desastres 2.7.1. Fallas de Hardware 2.7.2. Fallas de Software 2.7.3. Fallas Ambientales 2.7.4. Errores Humanos
Pgina 51
UTP
2.8. Beneficios de alta disponibilidad de acuerdo a la problemtica de AJEGROUP 2.8.1. Mirroring 2.8.2. Replicacin Transaccional 2.8.3. Log Shipping 2.9. Planificacin de una arquitectura de alta disponibilidad 2.10. Limitaciones y Evaluacin de la arquitectura 2.11. SQL Server 2008 R2 y sus arquitecturas tecnolgicas de Alta Disponibilidad 2.11.1. Mirroring 2.11.1.1. Definicin 2.11.1.2. Estados 2.11.1.3. Modos de operacin 2.11.1.4. Servidores 2.11.2. Replicacin Transaccional 2.11.2.1. Tipos 2.11.3. Log Shipping 2.12. Conceptos Relacionados 2.13. Herramientas de Desarrollo de Proyecto 2.13.1. Base de Datos 2.13.2. Microsoft SQL Server 2.13.2.1. Caractersticas 2.13.2.2. Ediciones 2.14. Metodologas de Desarrollo de Proyecto 2.14.1. UML 2.14.2. Modelado de Objetos 2.14.3. Artefactos 2.14.4. Caractersticas 2.15. Sistema de Hiptesis 2.16. Sistema de Variables
3. Marco Metodolgico 3.1. 3.2. Nivel de Anlisis de la Investigacin Diseo de la Investigacin 3.2.1. Mtodos 3.2.1.1. Mtodo Experimental 3.2.1.2. Mtodo de Observacin 3.2.1.3. Mtodo de Medicin
Pgina 52
UTP
3.2.2.
Recopilacin de Informacin 3.2.2.1. Tcnicas 3.2.2.2. Instrumentos
3.2.3.
Actividades
3.3.
Metodologa para el estudio de factibilidad de la Solucin 3.3.1. 3.3.2. 3.3.3. Casos de xito Costos de Hardware y Software Tcnicas
4. Solucin Propuesta 4.1. Anlisis de las arquitecturas de Alta Disponibilidad propuestas 4.1.1. 4.1.2. 4.2. 4.3. 4.4. Anlisis Estratgico Anlisis Funcional
Fuentes de Financiamiento Propuesta del Proyecto Definir los procesos de las arquitecturas de Alta Disponibilidad
5. Diseo de la solucin 5.1. 5.2. 5.3. 5.4. Diagrama de Procesos Diagrama de Actividades Diagrama de Secuencia Diagrama de Estados
6. Desarrollo de prototipo 6.1. 6.2. 6.3. 6.4. Arquitectura Mirroring Arquitectura Replicacin Arquitectura Log Shipping Pruebas
7. Impacto esperado 7.1. 7.2. 7.3. Descripcin Validacin del modelo Sustentacin de hiptesis
8. Conclusiones 9. Recomendaciones 10. Referencias 11. Anexo
Pgina 53
UTP
4.2 PRESUPUESTO DE INVESTIGACIN

Mes: Setiembre Descripcin Alquiler Cabinas Internet Investigacin en domicilio Asesora Impresiones Luz tiles de Oficina Pasajes Total Horas Diarias 3 4 2 Das 10 10 3 Costo Unitario 1.5 1.00 50 Costo Total 45 40 300 12 15 8 18 438
Mes: Octubre Descripcin Alquiler Cabinas Internet Investigacin en domicilio Asesora Impresiones Luz tiles de Oficina Pasajes Total Horas Diarias 1 4 2 Das 7 8 2 Costo Unitario 1.5 1.00 50 Costo Total 10.5 32 200 12 17 8 10 289.5
Mes: Noviembre Descripcin Alquiler Cabinas Internet Asesora Impresiones tiles de Oficina Pasajes Total Horas Diarias 2 2 Das 14 2 Costo Unitario 1.5 50 Costo Total 42 200 20 8 15 265
Pgina 54
UTP
Mes: Diciembre Descripcin Investigacin en domicilio Asesora Impresiones Luz tiles de Oficina Pasajes Total Horas Diarias 4 3 Das 12 1 Costo Unitario 1.00 50 Costo Total 48 150 20 18 8 9 253
Total Mes Setiembre Octubre Noviembre Diciembre Total Costo 438 289.5 265 253 1245.5
Pgina 55
UTP
CRONOGRAMA DE ACTIVIDADES
Pgina 56
UTP
REFERENCIAS
1. Desastres Informticos: previsin y prevencin http://www.idg.es/computerworld/Desastres-informaticos-prevision-y-prevencion.La-p/seccion-ti/articulo130035
2. redIT Resultados Inteligentes http://www.redit.com/mx/html/solutions/connectivity.php
3. DataDec Online http://www.ddol.es/alta_disponibilidad.htm
4. Alta Disponibilidad http://everac99.wordpress.com/2008/08/19/alta-disponibilidad-que-es-y-como-se-logra/
5. Solucin de Alta Disponibilidad de Base de Datos Facultad de Ingeniera de la Universidad San Carlos de Guatemala
6. Red Hat Enterprise Linux 4 Introduccin a la administracin de sistemas Cap. 8: Planificacin para Desastres
7. Alta Disponibilidad con SQL Server 2008 R2 http://technet.microsoft.com/es-es/library/ff658546(v=sql.100).aspx
8. Bases de Datos http://es.kioskea.net/contents/bdd/bddintro.php3
9. Ingeniera de Software UML http://www.monografias.com/trabajos5/insof/insof.shtml
Pgina 57
UTP
ANEXOS
Pgina 58

Incrementar El Nivel de Rentabilidad Mediante La Continuidad de Los Sistemas de Información Mediante Alta Disponibilidad y Performance en Caso de Desastres en Servidores

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Incrementar El Nivel de Rentabilidad Mediante La Continuidad de Los Sistemas de Información Mediante Alta Disponibilidad y Performance en Caso de Desastres en Servidores

Caricato da

Copyright:

Formati disponibili

PROYECTOS DE INGENIERIA DE SISTEMAS I

ASESOR: Wilmer Perfecto

INTEGRANTE: Eduardo Aldo Navarro Yataco

FACULTAD: INGENIERIA INDUSTRIAL Y DE SISTEMAS

Proyecto de Ingeniera de Sistemas I

Proyecto de Ingeniera de Sistemas I

Planificacin de una arquitectura de alta disponibilidad..

2.15. Sistema de Hiptesis. 2.16. Sistema de Variables.

Proyecto de Ingeniera de Sistemas I

Proyecto de Ingeniera de Sistemas I

Desastres Informticos: previsin y prevencion.La-p/seccion-ti/articulo-130035

Proyecto de Ingeniera de Sistemas I

CAPTULO 1: FORMULACIN DEL PROBLEMA

1.1. Planteamiento del Problema

1.2. Antecedentes de Solucin

Proyecto de Ingeniera de Sistemas I

redIT Resultados Inteligentes - http://www.redit.com/mx/html/solutions/connectivity.php

Proyecto de Ingeniera de Sistemas I

1.3. Propuesta de Solucin

1.4. Alcance de la Propuesta

Proyecto de Ingeniera de Sistemas I

DataDec Online - http://www.ddol.es/alta_disponibilidad.htm

Proyecto de Ingeniera de Sistemas I

Maximizar el grado de proteccin de un sistema o aplicacin ante un evento de falla del

Proyecto de Ingeniera de Sistemas I

CAPTULO 2: MARCO TERICO 2.1. Antecedentes de la Investigacin

redIT Resultados Inteligentes - http://www.redit.com/mx/html/solutions/connectivity.php

Proyecto de Ingeniera de Sistemas I

2.2. Alta Disponibilidad

2.3. Medicin de la Disponibilidad

Alta Disponibilidad - http://everac99.wordpress.com/2008/08/19/alta-disponibilidad-que-es-y-como-se-logra/

Proyecto de Ingeniera de Sistemas I

Alta Disponibilidad - http://everac99.wordpress.com/2008/08/19/alta-disponibilidad-que-es-y-como-se-logra/

Proyecto de Ingeniera de Sistemas I

2.4. Niveles de disponibilidad

Proyecto de Ingeniera de Sistemas I

2.5. Tiempo Fuera de Servicio

El mtodo usado para minimizar el tiempo fuera de

Proyecto de Ingeniera de Sistemas I

Proyecto de Ingeniera de Sistemas I

Proyecto de Ingeniera de Sistemas I

2.6. Clasificacin de desastres

2.7. Tipos de desastres

Proyecto de Ingeniera de Sistemas I

Proyecto de Ingeniera de Sistemas I

Proyecto de Ingeniera de Sistemas I

Proyecto de Ingeniera de Sistemas I

Proyecto de Ingeniera de Sistemas I

2.8. Beneficios de las arquitecturas de alta disponibilidad de acuerdo a la problemtica de AJEGROUP.

Proyecto de Ingeniera de Sistemas I

Proyecto de Ingeniera de Sistemas I

2.9. Planificacin de una arquitectura de alta disponibilidad

Proyecto de Ingeniera de Sistemas I

2.10. Limitaciones y Evaluacin de la tecnologa

Alta Disponibilidad con SQL Server 2008 R2 - http://technet.microsoft.com/es-es/library/ff658546(v=sql.100).aspx

Proyecto de Ingeniera de Sistemas I

2.11. SQL Server 2008 R2 y sus arquitecturas tecnolgicas de Alta Disponibilidad

Alta Disponibilidad con SQL Server 2008 R2 - http://technet.microsoft.com/es-es/library/ff658546(v=sql.100).aspx

Proyecto de Ingeniera de Sistemas I

Alta Disponibilidad con SQL Server 2008 R2 - http://technet.microsoft.com/es-es/library/ff658546(v=sql.100).aspx

Proyecto de Ingeniera de Sistemas I

Alta Disponibilidad con SQL Server 2008 R2 - http://technet.microsoft.com/es-es/library/ff658546(v=sql.100).aspx

Proyecto de Ingeniera de Sistemas I