Proyectos de Ingenieria de Sistemas I: Wilmer Perfecto

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

Información 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 Información Mediante Alta Disponibilidad y
Performance en Caso de Desastre en Servidores
PLAN DE TESIS UTP

Proyecto de Ingeniería de Sistemas I
INTRODUCCIÓN………………………………………………………………………………….…………….. 5
CAPÍTULO 1: Formulación del Problema

1.1. Planteamiento del Problema…………………………………………………………………………… 6
1.2. Antecedentes de solución
1.2.1. Caso de Éxito……………………………………………………………………………………. 7
1.3. Propuesta de solución…………………………………………………………………………………. 8
1.4. Alcance de la propuesta………………………………………………………………………………. 8
1.5. Justificación
1.5.1. Por qué………………………………………………………………………………………….. 9
1.5.2. Para qué…………………..…………………………………………………………………….. 9
1.6. Objetivos
1.6.1. Objetivo General………………………………………………………………………………… 10
1.6.2. Objetivos Específicos………………………….………………………………………………. 10
CAPÍTULO 2: Marco Teórico

2.1. Antecedentes de la Investigación
2.1.1. Caso de Éxito……………………………………………………………………………………. 11
2.2. Alta Disponibilidad…………………………………………………………………………………....... 12
2.3. Medición de la Disponibilidad…………………………………………………………………………. 12
2.4. Niveles de Disponibilidad …………………..…………………………………………..……………. 14
2.5. Tiempo Fuera de Servicio
2.5.1. Tiempo Fuera de Servicio Planeado………………………………………………………… 15
2.5.2. Tiempo Fuera de Servicio No Planeado……………………………………………………. 16
2.5.3. Estrategias…………………………………………………………………………………….. 17
2.6. Clasificación de desastres …………………………………………………………………………. 18
2.7. Tipos de desastres
2.7.1. Fallas de Hardware……………………………………………………………………………. 18
2.7.2. Fallas de Software……………………………………………………………………………… 19
2.7.3. Fallas Ambientales…………………………………………………………………………….. 20
2.7.4. Errores Humanos………………………………………………………………………………. 22
2.8. Beneficios de alta disponibilidad de acuerdo a la problemática de AJEGROUP
2.8.1. Mirroring………………………………………………………………………………………… 23
2.8.2. Replicación Transaccional…………………………………………………………………… 24
2.8.3. Log Shipping…………………………………………………………………………………… 24
Página 2
2.9. Planificación de una arquitectura de alta disponibilidad……………………………………….. 25 UTP

2.10. Limitaciones y Evaluación de la tecnología…………………………………………..…………. 26
2.11. SQL Server 2008 R2 y sus arquitecturas tecnológicas de Alta Disponibilidad
2.11.1. Mirroring
2.11.1.1. Definición……………………………………………………………………… 28
2.11.1.2. Estados………………………………………………………………………… 29
2.11.1.3. Modos de operación…………………………………………………………. 29
2.11.1.4. Servidores…………………………………………………………………….. 30
2.11.2. Replicación Transaccional
2.11.2.1. Tipos…………………………………………………………………………… 31
2.11.3. Log Shipping……………………………………………………………………………… 33
2.12. Conceptos Relacionados …………………………………………………………………………. 35
2.13. Herramientas de Desarrollo de Proyecto
2.13.1. Base de Datos…………………………………………………………………………… 35
2.13.2. Microsoft SQL Server
2.13.2.1. Características……………………………………………………………….. 36
2.13.2.2. Ediciones……………………………………………………………………… 37
2.14. Metodologías de Desarrollo de Proyecto
2.14.1. UML……………………………………………………………………………………….. 38
2.14.2. Modelado de Objetos…………………………………………………………………… 38
2.14.3. Artefactos………………………………………………………………………………… 39
2.14.4. Características…………………………………………………………………………… 42
2.15. Sistema de Hipótesis………………………………………………………………………………. 42
2.16. Sistema de Variables………………………………………………………………………………. 42
CAPÍTULO 3: Marco Metodológico

3.1. Nivel Análisis de la Investigación……………………….………………………………………… 43
3.2. Diseño de la Investigación……………………………….………………………………………… 43
3.2.1. Métodos
3.2.1.1. Método Experimental………………………………………………………….. 43
3.2.1.2. Método de Observación………………………………………………………. 43
3.2.1.3. Método de Medición……………………………………………………………. 44
3.2.2. Recopilación de Información
3.2.2.1. Técnicas………………………………………………………………………… 44
3.2.2.2. Instrumentos……………………………………………………………………. 45
3.2.3. Actividades…………………………………………………………………………………. 46
Página 3
3.3. Metodología para el estudio de factibilidad de la Solución UTP

3.3.1. Casos de Éxito…………………………………………………………………………….. 47
3.3.2. Costos de Hardware y Software………………………………………………………… 49
3.3.3. Técnicas……………………………………………………………………………………. 50
CAPÍTULO 4: Aspectos Administrativos

4.1. Índice Preliminar de la Tesis…….……………………….……………………………………….. 51
4.2. Presupuesto y Cronograma de Actividades………….…………………………………………. 54
Referencias……………………………………………………………………………………….……….. 57
Anexos………………………………………………………………………………………………………. 58
Página 4
UTP
INTRODUCCIÓN
Tradicionalmente se ha entendido por desastre un incendio o inundación, porque este tipo de

eventualidades destruía recursos físicos de la empresa como archivos, máquinas 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 información.
En cualquier momento, la información de una empresa se puede quebrar total o parcialmente como
consecuencia de un siniestro fortuito. Es incalculable medir como afectaría al negocio y a la reputación, si
las operaciones más importantes de su compañía se suspendieran repentinamente, nos preguntamos
¿Cuánto tiempo puede aguantar una compañía sin acceder a sus activos básicos de información? Y, no
menos importante, ¿cuánto tiempo necesitarían las aplicaciones que proporcionan dicha información para
volver a estar disponibles? Además, 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 más mínima interrupción informática?
“El impacto que provoca un desastre informático, según datos de la consultora internacional
ContingencyPlanningResearch, es mayor sobre las empresas financieras, mercados bursátiles, etcétera,
que sobre cualquier otro tipo de negocio. Se situarían en segundo lugar los negocios basados en los
sistemas de autorización de pagos como los cajeros automáticos y validación de tarjetas de crédito entre
otros. Es razonable, pues, prepararse para lo peor. La empresa debe prever posibles pérdidas de
información irreparables en sus instalaciones, que pueden llegar desde distintos frentes: virus, caídas
eléctricas, desastres naturales o medioambientales. Del tiempo que tarde en reaccionar, restaurando,
recuperando y periódicamente aumentando la performance de la información crítica que contienen,
dependerá la gravedad de las consecuencias económicas para su negocio” 1.
Por esta razón, aplicaremos un plan de alta disponibilidad de la información en la empresa AJEGROUP
S.A. en caso ocurra un desastre, evitando el detenimiento de sus procesos. Actualmente con la aplicación
de herramientas tecnológicas es posible implementar estas metodologías para salvaguardar la información
y así evitar pérdidas incalculables e irreparables a la empresa.
1
Desastres Informáticos: previsión y prevención - http://www.idg.es/computerworld/Desastres-informaticos-prevision-y-
prevencion.La-p/seccion-ti/articulo-130035
Página 5
UTP
CAPÍTULO 1: FORMULACIÓN DEL PROBLEMA
1.1. Planteamiento del Problema

Disponibilidad de la información en los servidores de base de datos de AJEGROUP S.A. mediante
la implementación de tecnologías de alta disponibilidad en caso de desastres y optimización de
tiempos de respuesta aumentando la performance de procesos, que nos permita tener acceso a la
información las 24 horas del día con tiempos de respuesta mínimos.
Parámetros
Carrera Ingeniería de Sistemas
Área Tecnología
Asignatura /
Disponibilidad e Integridad de la Información.
Especialidad
Frecuencia de información y optimización de tiempos de respuesta
Temas
aplicando tecnologías de alta disponibilidad.
Temas
Acceso y alta performance de la información las 24 horas del día.
Específicos
Gestión de aplicaciones de misión crítica más exigentes, reduciendo el
tiempo y el coste de desarrollo mediante tecnologías de alta disponibilidad
Situación y performance, debido a la caída parcial o total de servidores como
Problemática consecuencia de un siniestro fortuito afectando incalculablemente a la
compañía, facilitando así a toda la empresa la información necesaria para
toma de decisiones.
1.2. Antecedentes de Solución

RedITes una compañía internacional que ofrece a sus clientes una variada gama de soluciones y
servicios integrados de Tecnología de Información, asistiéndolos para MAXIMIZAR, el valor de su
negocio.
Estas soluciones satisfacen los requerimientos de los clientes en las áreas de continuidad de
negocios y recuperación ante desastres, administración y operación de servicios administrados de
TI y servicios profesionales.
Página 6
1.2.1. Caso de éxito

UTP
“Perfil del Cliente

Compañía de BBVA Bancomer encargada de realizar, recibir y controlar pagos por Internet.
Situación
"Al ofrecer servicios de tipo bancario, los equipos que manejan dichas transacciones son
críticos 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 más elevados
estándares de seguridad para realizar las transacciones en horarios de 7X24".
Reto del negocio

BBVA busca una solución en términos de servicio que le ayude a mantener la disponibilidad
de los servidores a través de un servicio de monitoreo continuo y soporte técnico.
Solución
"A través de las tecnologías de recuperación instantánea de información Mirroring y
Replicación, 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 prácticas 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 cuál nos ahorra
trabajo y se convierten en un punto de referencia de que están haciendo las cosas bien.
Además 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 Producción y Soporte” 2
2
redIT Resultados Inteligentes - http://www.redit.com/mx/html/solutions/connectivity.php
Página 7
1.3. Propuesta de Solución UTP

Implementar tecnologías como Log Shipping, Replicación 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 más de 330.000 visitas mensuales (10.000 diarias). A
través de esta implementación podremos gestionar las aplicaciones de misión crítica más exigentes,
reducir el tiempo y el coste de desarrollo, facilitando así a toda la empresa la información necesaria
para toma de decisiones.
1.4. Alcance de la Propuesta

 Se aplicará las tecnologías de alta disponibilidad solo a los servidores de base de datos críticos,
midiéndolos por número de caídas mensuales, cantidad diaria de transacciones.
 Estableceremos independientemente de la tecnología los servidores principales y secundarios.
 Aplicaremos la tecnología Log shipping solo para usuarios de bases de datos, no sistemas de
bases de datos y que estén dentro del Active Directory. Esto significa que debe tener un régimen
estricto de backup las bases de datos master y msdben el servidor primario y restaurarlos en el
secundario. Sin este régimen, 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 tecnología no sature el ancho de banda.
Escogeremos el servidor como servidor secundario al que tenga más de 250 GB de espacio
disponible para almacenar los backups generados.
 Aplicaremos replicación transaccional a los servidores de alto rendimiento en el almacenamiento
de datos, creación de informes y que contengas la integración de datos procedentes de varios
sitios.
 Aplicaremos replicación de mezcla a las tablas de las aplicaciones móviles o de servidores
distribuidos que pueden encontrarse con conflictos de datos.
 Aplicaremos Mirroring a los servidores donde las conexiones estén estables y certificadas. Para
esto necesitamos establecer 3 servidores (Principal, Espejo y Testigo).
 Reindexación o Defragmentación de todos los índices de la base de datos.
 Análisis pormenorizado de las 30 sentencias que insumen más tiempo de ejecución de modo de
identificar la posibilidad de creación de índices que contribuyan al mejor desempeño de las
mismas.
 Redefinición de la estrategia de respaldo así como también configuración de todos los planes de
mantenimiento necesarios para un correcto mantenimiento preventivo de las diferentes bases de
datos que residen en el servidor.
Página 8
1.5. Justificación UTP

1.5.1. ¿Por qué?
Hoy en día muchas empresas requieren algunos o todos sus datos críticos a ser altamente
disponible. Por ejemplo, una empresa que requiere "24x7" disponibilidad es un comerciante
en línea, cuyo producto bases de datos y aplicaciones de ventas en línea 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 podría perder. En el mundo real, sin
embargo, hay numerosos problemas que pueden causar que los datos no estén
disponibles. Estas estrategias siempre exigen la aplicación de múltiples tecnologías que
ayudan a mantener la disponibilidad de datos, no existe una única tecnología 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 día, manteniéndolos 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 aplicación de las tecnologías que nos ofrece Microsoft SQL Server 2008 R2, las
cuales podremos utilizar para aumentar y / o mantener una alta disponibilidad de los datos
críticos. La alta disponibilidad se trata de implementar un conjunto de tecnologías en los
servidores antes de que se produzca un fallo para evitar el fracaso de afectar a la
disponibilidad de datos. La recuperación de desastres es acerca de tomar
acción después de un fallo se ha producido la recuperación de datos perdidos y hacer que
los datos estén disponibles de nuevo. Esta investigación describe las tecnologías
disponibles en SQL Server 2008 R2 que se puede utilizar como parte de una estrategia de
alta disponibilidad para proteger datos críticos. Además de describir las tecnologías en
detalle, la investigación también se analizan las diversas causas del tiempo de inactividad y
la pérdida de datos, y la forma de evaluar y equilibrar los requisitos y limitaciones en la
planificación de una estrategia de alta disponibilidad que implica SQL Server 2008 R2.
3
DataDec Online - http://www.ddol.es/alta_disponibilidad.htm
Página 9
1.6. Objetivos UTP

1.6.1. Objetivo General
Determinar el nivel de rentabilidad económica, mediante la continuidad de los Sistemas de
Información aplicando tecnologías de alta disponibilidad y performance, haciendo continúo las
operaciones de la compañía.
1.6.2. Objetivos Específicos

 Análisis 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 caídas de los servidores de base de datos en un lapso de
tiempo determinado.
 Análisis de la arquitectura de red.
 Maximizar el grado de protección de un sistema o aplicación ante un evento de falla del
sistema, permitiéndole continuar disponible cuando se presenta la falla.
 Minimizar el impacto en los sistemas de información al momento de alguna caída en los
servidores y cuando recuperan su disponibilidad.
 Continuar ofreciendo disponibilidad en los sistemas de información, en el caso de que los
servidores principales estén irrecuperables.
 Prevenir y anticiparse a que ocurran fallas en los servidores.
Página
10
UTP
CAPÍTULO 2: MARCO TEÓRICO
2.1.1. Caso de éxito

“Perfil del Cliente
Mercadotecnia Ideas y Tecnología, (MIT) es una compañía especializada en el desarrollo de
modelos y soluciones sustentadas en herramientas de tecnología y mercadotecnia, para
medios de pago electrónicos.
Situación
MIT desarrolla y opera soluciones para: aseguradoras, aerolíneas, TV por cable, ventas
telefónicas y hotelería. 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 optimización de sus tiempos de respuesta de
procesos.
Solución
Al principio solo buscaba optimización de sus procesos; sin embargo la mejor solución fue
implementar las arquitecturas de alta disponibilidad Mirroring en sus servidores críticos y Log
Shipping en sus servidores de diferente plataforma. "A través de los servicios que hemos
contratado con redIT tenemos alta disponibilidad y tiempos de respuesta mínimos 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 tecnológico que comprende los objetivos de MIT” 4.
4
redIT Resultados Inteligentes - http://www.redit.com/mx/html/solutions/connectivity.php
Página
11
2.2. Alta Disponibilidad UTP

“La disponibilidad es una de las características de las arquitecturas empresariales que mide el grado
con el que los recursos del sistema están disponibles para su uso por el usuario final a lo largo de
un tiempo dado. Ésta no sólo se relaciona con la prevención de caídas del sistema (también
llamadas tiempos fuera de línea, downtime u offline), sino incluso con la percepción de "caída"
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, aplicación 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. Medición de la Disponibilidad

De primera instancia, todo sistema debe tener establecido un Acuerdo de Nivel de Servicio (Service
Level Agreement – SLA) que defina cuánto tiempo y en qué horarios debe estar en línea. En el caso
de aplicaciones de baja criticidad, dicho SLA puede ser de 8×5 horas a la semana excluyendo días
festivos; para sistemas con mayor criticidad como una red de cajeros automáticos se tienen niveles
de servicio que alcanzan las 24 horas al día, los 365 días del año.
Así entonces, suponiendo un sistema con un SLA de 24×365 podríamos 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/año.
B = Número de horas fuera de línea (Horas de "caída 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” 5:
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/
Página
12
“Cuando se realicen negociaciones para definir objetivos de disponibilidad con los usuarios, es UTP
necesario conocer de las implicaciones técnicas y económicas, como se muestra en la siguiente
tabla:
TIEMPO TIEMPO
DISPONIBILIDAD (%) TIEMPO OFFLINE/AÑO
OFFLINE/MES OFFLINE/DÍA
90% 36.5 días 73 hrs 2.4 hrs
95% 18.3 días 36.5 hrs 1.2 hrs
98% 7.3 días 14.6 hrs 28.8 min
99% 3.7 días 7.3 hrs 14.4 min
99.5% 1.8 días 3.66 hrs 7.22 min
99.9% 8.8 hrs 43.8 min 1.46 min
99.95% 4.4 hrs 21.9 min 43.8 s
99.99% 52.6 min 4.4 min 8.6 s
99.999% 5.26 min 26.3 s 0.86 s
99.9999% 31.5 s 2.62 s 0.08 s
Tabla 1: Disponibilidad para un sistema 24×7 y tiempos de caída permitidos

Fuente: Alta Disponibilidad - http://everac99.wordpress.com/2008/08/19/alta-disponibilidad-que-es-y-como-se-logra/
Estos números (especialmente aquellos que pasan de la marca del 99.5% de disponibilidad) son
difíciles de alcanzar, ya que es necesario poder recuperarse ante caídas 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 administración del sistema y sus operaciones.
 Otros factores técnicos o de gestión: falta de refacciones, fallas en la cadena de escalamiento,
etc.” 6
6
Alta Disponibilidad - http://everac99.wordpress.com/2008/08/19/alta-disponibilidad-que-es-y-como-se-logra/
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 (técnicas de
recuperación y copia de seguridad).
Página
13
UTP
Media (High Reliable): las funciones de negocios pueden verse interrumpidas pero se debe
mantener la integridad de datos.
Disponibilidad de servicio: 95%
Mecanismos: bitácoras de operaciones.
Alta Disponibilidad: las funciones de negocios aceptan pequeñas interrupciones y al retomar se

reprocesan transacciones.
Disponibilidad: 99%
Mecanismos: bitácoras de operaciones, recuperación automática.
Resistencia a fallas: requiere de operación ininterrumpida en horario laboral, se retoma en caso de

falla automáticamente.
Disponibilidad: 99.9%
Mecanismos: clustering, mirroring.
Tolerancia a fallas: capacidad de procesamiento continuo y cualquier falla debe ser transparente
para el usuario.
Mecanismos: duplicidad del sitio y redundancia.
Tolerancia a Desastres: disponibilidad en todo momento, capacidad para soportar desastres

naturales y humanos.
Mecanismos: Los anteriores más dos sitios y mecanismos de recuperación.” 7.
7
Solución de Alta Disponibilidad de Base de Datos – Facultad de Ingeniería de la Universidad San Carlos de Guatemala

“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
diseñadas para minimizar el tiempo fuera de servicio. El Tiempo fuera de servicio puede ser
planeado o no planeado.
Página
14
UTP
Figura 1: Causas del Tiempo Fuera de Servicio

Fuente: Solución de Alta Disponibilidad de Base de Datos – Facultad de Ingeniería 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. El método usado para minimizar el tiempo fuera de
servicio planeado debe ser:
 Proveer copias de seguridad (backups), mantenimiento, actualizaciones mientras el
sistema está arriba y corriendo.
 Reducir el tiempo para desempeñar esas tareas que pueden ser únicamente cuando el
sistema está bajo” 8.
8
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 método usado para minimizar el tiempo fuera de servicio no planeado es para:
Página
15
 Minimizar el número de defectos y el efecto / recuperación en el tiempo de los defectos

en un sistema. UTP
 Evitar un punto singular de falla por la utilización redundante de partes (failover).
 Reducir el impacto de los defectos del medio ambiente usando UPS y copia idéntica de
los datos fuera del sitio y/o replicación en caliente de componentes omitidos.
Para mencionar el porcentaje de las causas no planeadas que provocan un paro se debe
revisar la gráfica que se presenta a continuación.
Figura 2: Causas desconocidas no planeadas

Fuente: Solución de Alta Disponibilidad de Base de Datos – Facultad de Ingeniería de la Universidad San Carlos de Guatemala
La solución lógica para incrementar la disponibilidad es mantener los datos en más de un

lugar (recuperación de desastre), evitar que el usuario perciba las fallas en el servicio
(recuperación de fallas) y mejorar el tiempo de respuesta (rendimiento).
El criterio para una la alta disponibilidad y alto desempeño incluye una solución:
 Mínimo impacto sobre la disponibilidad y desempeño 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 actualización de la base de
datos primaria”9.
9
2.5.3. Estrategias para maximizar la disponibilidad sin quebrar económicamente a la

empresa:
“Redundancia
Los fabricantes han estado diseñando redundancia en sus productos en forma de fuentes
Página
16
de poder redundantes, múltiples procesadores, memoria segmentada y discos redundantes.

Esto también se puede referir a sistemas de servidores corriendo en modo de alerta en UTP
caliente en otra ubicación. Se puede también configurar de la misma manera los
controladores de discos y de cintas con rutas paralelas, repartiendo la carga de la red en
dos líneas y proporcionando consolas alternas de control
Reputación
La reputación de los proveedores clave como servidores, almacenamiento, bases de datos y
equipos de redes juegan un papel principal en la búsqueda de la alta disponibilidad. Hay
varias maneras para verificar la reputación como porcentaje de participación en el mercado,
comportamiento histórico en clientes, y reportes de analistas de industria.
Confiabilidad
La confiabilidad de los equipos y de los programas también se puede verificar por
referencias de clientes y analistas de industria. Además se recomienda establecer un
monitoreo permanente a través de la gente de operaciones, soporte y técnicos del
proveedor, además de comparar con otros departamentos de TI.
Facilidad de Reparación
Este factor califica la facilidad relativa con la cual los responsables del servicio técnico
pueden arreglar la falla. Dos métricas comunes para medir esto es cuanto se demora en
hacer el trabajo de reparación, y cada cuanto se debe repetir.
Restablecimiento
Se refiere a la habilidad para sobreponerse a una falla momentánea, de tal manera que no
haya impacto en la disponibilidad para el usuario final. Puede ser tan pequeño como una
pequeña porción de la memoria recuperándose de un error insignificante, o algo tan grande
como un sistema de servidores que decida invernar sin razón alguna, sin perdida de
información transaccional” 10.
10
2.6. Clasificación de desastres

“Desastres naturales: Un desastre natural es muy difícil, pero es posible tomar las precauciones
necesarias para evitar pérdidas. Estos desastres son inundaciones, incendios, terremotos,
huracanes, etc.
Página
17
Desastres producidos por el hombre: Estos desastres son los principales motivos de fracaso. El UTP
error humano y la intervención puede ser intencional o no intencional, la cual puede causar enormes
fracasos como la pérdida de la comunicación y utilidad. Estos desastres incluyen accidentes,
huelgas, sabotaje, robo, virus, intrusiones, etc.

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 fáciles de entender - el hardware falla y el trabajo se detiene. Lo
que es más difícil de entender es la naturaleza de las fallas y cómo se puede minimizar su
exposición a ellas. He aquí algunos enfoques que puede utilizar:
Mantener partes adicionales de hardware

En su forma más 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 más. 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 - Introducción a la administración de sistemas Cap. 8: Planificación para Desastres
“He aquí algunas cosas que debería considerar cuando esté revisando contratos de
servicios:
 Horas de cobertura
 Tiempo de respuesta
 Partes disponibles
Página
18
 Presupuesto disponible
 Hardware cubierto UTP
2.7.2. Fallas de Software

Algunas fallas de software pueden resultar en largos tiempos fuera de servicio. Por ejemplo,
los dueños de cierta marca de computadores conocidos por sus funcionalidades de alta
disponibilidad, descubren esto a primeras. Un error en el código de manejo de tiempo del
sistema operativo del computador resultó en que los sistemas fallen a cierta hora de cierto
día.
Las fallas del software pueden golpear en dos áreas:
 Sistema operativo
 Aplicaciones
Cada tipo de falla tiene su impacto específico y se exploran en más detalles en las secciones
siguientes.
Fallas del sistema operativo

En este tipo de falla, el sistema operativo es responsable por la interrupción del servicio. Las
fallas del sistema operativo vienen de dos áreas:
 Caídas del sistema
 Colgarse o bloquearse
Fallas de las aplicaciones

A diferencia de las fallas del sistema, las fallas de las aplicaciones pueden ser más limitadas
en el ámbito de lo que dañan. Por otro lado, si se trata de una aplicación de servidor que está
sirviendo a una gran población de aplicaciones clientes, las consecuencias de la falla serían
mucho más extensas. Las fallas de las aplicaciones, igual que otras fallas del sistema,
pueden ser causadas por caídas o bloqueos; la única diferencia es que aquí es la aplicación
la que se está fallando” 12.
12
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.
Página
19
Excepto por las diferencias obvias (no se requieren repuestos y la mayoría del trabajo lo
puede hacer el personal de soporte a través del teléfono), los contratos de soporte de UTP
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 más comunes empleadas hoy día:
 Documentación
 auto-asistencia
 Soporte de Web o de correo electrónico
 Soporte telefónico
 Soporte in situ
2.7.3. Fallas Ambientales

Los problemas pueden ocurrir aún cuando el hardware se está ejecutando perfectamente y
aunque el software esté configurado de la forma adecuada. Los problemas más importantes
que ocurren fuera del sistema mismo tienen que ver con el ambiente físico en el cual reside el
sistema.
Los problemas ambientales se pueden desglosar en cuatro categorías:
 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 climático adecuado para
los contenidos del edificio. Tiene mecanismos para proporcionar energía y protección 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
“He aquí algunas de las posibilidades a considerar:

 Los techos pueden tener goteras, dejando pasar agua hasta los centros de datos.
Página
20
 Varios sistemas del edificio (tales como agua, desagües, o manejo del aire) pueden fallar,
dejando el edificio inhabitable. UTP
 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 energía son de suprema importancia en la mente de un
administrador de sistemas. Hay muchos aspectos diferentes sobre la electricidad; estos se
cubren con más detalles en las secciones siguientes.
Lo principal a verificar son los métodos a través de los cuales la energía es traída a las
instalaciones de su organización y dentro del edificio. ¿Las líneas de transmisión están por
debajo o sobre la tierra? Las líneas sobre el suelo son susceptibles a:
 Daños por condiciones ambientales extremas (hielo, viento, relámpagos)
 Accidentes de tránsito que dañan los postes y/o transformadores
 Animales perdidos en el lugar incorrecto y cortando las líneas
Sin embargo, las líneas bajo tierra tienen sus limitaciones únicas:
 Daños de trabajadores de construcción cavando en los lugares incorrectos
 Inundaciones
 Relámpagos (sin embargo, mucho menos que con las líneas sobre la tierra)
Calefacción, Ventilación y Aire Acondicionado

Los sistemas de Calefacción, Ventilación y Aire Acondicionado (Heating, Ventilation, and Air
Conditioning, HVAC) utilizados en los edificios de oficinas de hoy día, son increíblemente
sofisticados. A menudo controlado por computadoras, el sistema HVAC es vital para
proporcionar un ambiente laboral cómodo. 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 electromagnética, las posibilidades de una falla son muchas y variadas” 14.
14
He aquí algunos ejemplos:
Página
21
 Las unidades de manejo de aire acondicionado (esencialmente grandes ventiladores

eléctricos) pueden fallar debido a la sobrecarga eléctrica, una falla, falla de la correa/polea, UTP
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 energía y las comunicaciones, con vientos
extremadamente fuertes dañando inclusive el edificio mismo.
Hay otros tipos de tiempo que también pueden provocar problemas, aún 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 eléctrico se sobrecarga.
2.7.4. Errores Humanos

Se ha dicho que las computadoras son realmente perfectas. La razón detrás de esta
afirmación es que si usted profundiza lo suficiente, detrás de cada error computacional
encontrará el error humano que lo causó.
Errores humanos del usuario final

Los usuarios pueden cometer errores que podrían 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 mayoría de los usuarios interactúan exclusivamente
con una computadora por una o más aplicaciones, usualmente es dentro de las aplicaciones
que ocurren la mayoría de los errores” 15.
15
Página
22
Errores del personal de operaciones

Los operadores tienen una relación más profunda con las computadoras de una organización UTP
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 más 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 daños más
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 organización. También a diferencia de los operadores,
las tareas que los administradores de sistemas llevan a cabo a menudo no están 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 están haciendo. Durante el curso de llevar a
cabo las responsabilidades diarias, los administradores de sistemas tienen acceso más 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

problemática de AJEGROUP.
2.8.1. Mirrorring
 Aumenta la protección 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 conmutación automática
por error, failover rápidamente trae la copia de reserva de la base de datos en línea (sin
pérdida de datos). En los otros modos de operación, el administrador de base de datos
tiene la alternativa del servicio forzado (con posible pérdida de datos) a la espera de
copia de la base de datos.
Página
23
 Mejora la disponibilidad de la base de datos de producción durante las actualizaciones.

Para minimizar el tiempo de inactividad de una base de datos reflejada, de forma UTP
secuencial puede actualizar las instancias de SQL Server que están participando en una
sesión de creación de reflejo de base de datos.

 Las consultas del catálogo 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 aplicación 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 actualización,
cada nodo se puede tomar sin conexión y agregar de nuevo al sistema sin que se vea
afectada la disponibilidad de la aplicación.
2.8.3. Log Shipping

 Basado en entorno desconectado.
 Totalmente transparente para aplicaciones.
 Fácil configuración.
 Soporta configuración Heterogéneas
 Fácilmente supervisable, resincronizable y reconfigurable
De acuerdo al análisis 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 características del servidor de Distribución de Perú:
 Nombre de Servidor: SRVPELIDB3\SQLINST02 (172.16.0.40\SQLINST02).
 Motor de BD: SQL 2005 Enterprise Edition
 Nombre de la BD: DATA
 Tamaño total: 465 GB
 Collation: Modern_Spanish_CI_AS
 Recovery Model: Simple
Aplicaremos la arquitectura Mirroring, por ser uno de los servidores críticos y por ende necesitamos
proteger la información y ala vez aumentar la disponibilidad de base de datos.
Página
24
Detallamos las características del servidor de Distribución de Colombia:

 Nombre de Servidor: SRVCOBODB1 (172.17.52.8). UTP
 Motor de BD: SQL 2005 Enterprise Edition (64 Bits).
 Nombre de la BD: BDCOLOMBIA
 Tamaño 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. Planificación de una arquitectura de alta disponibilidad

“Una exitosa estrategia de alta disponibilidad no puede planificarse únicamente desde el punto de
vista técnico, ya que los costos y los riesgos para el negocio de los tiempos de inactividad y / o
pérdida de datos debe ser entendido. Del mismo modo, la estrategia no se puede conducir
únicamente a partir de los requerimientos del negocio sin una comprensión de las implicaciones
técnicas de estos requisitos. La primera respuesta de muchas personas en la planificación de una
estrategia de alta disponibilidad es algo así como "implementar un mirroring!" Sin ninguna
consideración de lo que la estrategia está tratando de lograr. A pesar de que mirroring es una
tecnología excelente, no es apropiada en todas las situaciones, por lo que es importante elegir las
tecnologías adecuadas y no sólo el primero que me viene a la mente. Ser capaz de elegir las
tecnologías adecuadas significa comprender no sólo las características de las tecnologías, sino
también la lista de prioridades de las necesidades, teniendo en cuenta las limitaciones que existen.
Requisitos
Los requisitos son una parte importante del diseño y de las fases de prueba. Como parte del
proceso de diseño general, se identifican los requisitos. A continuación, el diseño debe ser validado
en contra de los requisitos previos para la aplicación y, por último, que debe ser utilizado para poner
a prueba el diseño después de que se aplica.
El objetivo de la recopilación 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 organización 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 protección de los
recursos múltiples con diferentes requisitos y en contra de las diferentes causas de la pérdida de
tiempo de inactividad y de datos.
Página
25
“Los dos requisitos principales alrededor de alta disponibilidad son comúnmente conocidos como
RTO y RPO. RTO representa Objetivo de Tiempo de Recuperación y es el tiempo de inactividad UTP
máximo permitido cuando se produce un error. RPO significa Objetivo de Punto de Recuperación y
es el máximo permisible de pérdida de datos en caso de avería. Aparte de la especificación de un
número, también es necesario contextualizar el número. 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
tecnologías 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 pérdida de
datos puede ser tolerada. Base de datos X también 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 días de semana, sin
pérdida de datos puede ser tolerada, y todos ellos deben estar disponibles
juntos. Después de una conmutación por error, el rendimiento de carga de trabajo no
puede caer.
2.10. Limitaciones y Evaluación de la tecnología

Limitación de análisis es crucial para evitar la pérdida de tiempo (y dinero) de diseñar una estrategia
que no se puedan aplicar (por ejemplo, la estrategia implica la adición de un centro de datos, pero el
presupuesto total es de 10.000 dólares EE.UU. al año). Las limitaciones no son sólo en términos de
presupuesto (aunque eso suele ser la principal limitación)-hay otras limitaciones no técnicos, y una
serie de limitaciones técnicas a considerar.
Las limitaciones no técnicos incluyen:
 Alimentación (para más servidores, discos y acondicionamiento de aire asociada)
 Espacio (para más servidores y equipos auxiliares)
 Aire acondicionado (para hacer frente a toda la producción de calor extra de equipo original)
 Manpower (para instalar y mantener cualquier sistema agregado y equipos)
 Política y / o problemas de gestión (si los equipos están implicados múltiples) ” 16
16
Alta Disponibilidad con SQL Server 2008 R2 - http://technet.microsoft.com/es-es/library/ff658546(v=sql.100).aspx
Página
26
“Después de que los requisitos de compromiso post-son conocidos entonces, y sólo entonces, es el
momento de evaluar las diversas tecnologías. No tiene sentido evaluar y elegir las tecnologías UTP
basadas en un conjunto de requisitos defectuoso y luego tener que repetir el proceso después de
que los requisitos se entienden mejor. Del mismo modo, el éxito no viene de recoger una tecnología
inadecuada y luego tratar de hacer que funcione una función para la cual no fue diseñado.
Por ejemplo:
 El trasvase de registros no es adecuado para un diseño que requiere cero pérdida de datos.
 Mirroring de base de datos no es adecuado para un diseño que requiere múltiples bases de
datos de conmutación por error de forma simultánea.
Al evaluar las tecnologías, es importante considerar todos los aspectos de las tecnologías,
incluyendo:
 El costo monetario de la aplicación de la tecnología.
 La complejidad de la implementación, configuración y gestión de la tecnología.
 La tecnología de impacto en el rendimiento de carga de trabajo (si lo hay).
 El riesgo de pérdida de datos si se utiliza la tecnología.
 El potencial de tiempo de inactividad si la tecnología se utiliza.

En el campo de la alta disponibilidad la visión de SQL Server es la de brindar un conjunto de
soluciones integradas que funcionen tanto en entornos de empresas grandes cuya definición de alta
disponibilidad sea muy exigente como en pequeñas empresas cuya necesidad de alta disponibilidad
no sea tan exigente como la de las grandes empresas pero que también necesitan de soluciones
que se adapten a sus necesidades y capacidad de inversión en tecnología.
Es así que el conjunto de soluciones que presenta SQL Server R2 permitirá proveer de la tecnología
necesaria para satisfacer las necesidades de las PYME con una buena relación de costo beneficio y
manteniendo la calidad de servicio necesaria para ayudar al consolida miento de las Pequeñas y
Medianas Empresas haciendo así de la tecnología 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 opción aislada. Puede combinar dos o más técnicas dentro del mismo sistema para cubrir todas
las eventualidades” 17.
17
Página
27
2.11.1. Mirroring UTP

“Mirroring de base de datos puede proveer una solución failover casi instantánea para las
bases de datos SQL Server 2008 R2. En esta edición, 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 sección le enseña 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. Definición
Mirroring de base de datos funciones manteniendo un servidor en standby que
tiene una copia de la base de datos. Si el servidor de producción falla, las
aplicaciones pueden ser redireccionadas al servidor en standby. El failover puede
ser la mas instantánea, típicamente necesita de menos de tres segundos si es
realizada automáticamente. 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 términos 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
Página
28
2.11.1.2. Estados UTP

Hacer un mirror de una base de datos envuelve algunos pasos, durante los
cuales la base de datos pasa por algunos estados:
“Estado de sincronización: Para permitir hacer el mirror, la base de datos

mirror debe ser creada, y todos los cambios realizados a la base de datos
principal también deben ser aplicados a la base de datos mirror. Mientras que
esto sucede, la base de datos principal y la mirror están en estado de
sincronización.
Estado de sincronización: Una vez que la base de datos mirror se actualizo

con la base de datos principal, ambas están en estado de sincronización. Todos
los cambios hechos a la base de datos principal serán automáticamente hechos
en la base de datos mirror para asegurarse que permanecen sincronizadas.
Estado desconectado: Si un servidor pierde conexión 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 Operación

Los mirror de las bases de datos pueden operar en dos modos, que determinan
el grado de exposición 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 transacción. Este modo soporta failover manual y
automático” 19.
19
Página
29
“Modo desincronizado: las transacciones son hechas primero en el servidor UTP

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 comunicación con el servidor mirror se produce. Esto
incrementa el trabajo al peligro de perder la sincronización 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 estén 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 configuración en curso de set de mirrors, son descriptas mas
tarde en esta sección” 20.
20
Página
30
2.11.2. Replicación UTP

La replicación es un conjunto de tecnologías destinadas a la copia y distribución 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 replicación permite distribuir datos entre
diferentes ubicaciones y entre usuarios remotos o móviles mediante redes locales y de área
extensa, conexiones de acceso telefónico, conexiones inalámbricas e Internet. La replicación
es un amplio conjunto de tecnologías 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
Replicación Transaccional
“La replicación transaccional implica la creación de una publicación (datos de una
o varias tablas de una base de datos) en una base de datos de publicación en una
instancia de Publisher. El estado inicial de la publicación se copia en una o más
instancias de abonado donde se convierte en la suscripción en una base de datos
de suscripción.
Este proceso de inicialización se puede realizar utilizando una copia de seguridad
de base de datos o utilizar una instantánea” 21.
Figura 3: Replicación Transaccional

21
Página
31
Si el publicador va replicación offline, transaccional se reinicia automáticamente UTP

cuando vuelva a conectarse. Además, si un abonado se desconecta, las
operaciones que deben propagarse a ella se llevan a cabo en la base de datos de
distribución 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 publicación. Lo ideal sería 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
distribución desde el publicador o suscriptor casos. Al igual que con el trasvase de
registros, la replicación no proporciona detección automática de fallo de Publisher
o failover automático a un suscriptor, por lo que es también una solución de
reserva activo. Además, hay una latencia entre una transacción que ocurre en el
publicador y se propaga a los suscriptores, por lo que la pérdida de datos es
posible en el momento de una falla.
Replicación Peer to Peer

Peer-to-peer replicación 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 topología peer-to-peer se propaga a
todos los demás nodos, con todos los nodos que actúan como publicador,
suscriptor y, Distribuidor (por lo general). En la replicación peer-to-peer, los datos
de alta disponibilidad y soluciones son fácilmente escalables para cargas de
trabajo fuera de la consulta.

Página
32
“La figura anterior muestra tres bases de datos participantes que proporcionan UTP
Proyecto en
datos para una organización de soporte de software de Ingeniería
todo el de Sistemas
mundo, I
con
oficinas en Los Angeles, Londres y Taipei. Los ingenieros de soporte técnico de
cada oficina reciben llamadas de clientes e introducir y actualizar la información 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 día. 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 replicación
transaccional no tiene detección automática o conmutación automática por error,
por lo que los distintos nodos de la topología de proporcionar abrigo copias de
reserva de los datos publicados. Además, peer-to-peer replicación transaccional
tiene los mismos problemas de latencia de la replicación transaccional
2.11.3. Log Shipping

El trasvase de registros es la forma más sencilla de proporcionar una o más 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 más 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 través 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
están tomando y restaurado regularmente. Hay varias opciones de configuración, 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 envío de registro secundario también
se puede configurar para tener un retardo de carga (es decir, un período de tiempo de
espera antes de la restauración 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 período, la tabla sigue existiendo en el servidor secundario y se
puede recuperar”22.
22
Página
33
UTP

“Un trasvase de registros secundario también puede ser configurado para permitir acceso
de sólo lectura a la base de datos de registro de transacciones entre las operaciones de
restauración. Esto permite que la base de datos que se utilizarán a efectos de notificación,
lo que maximiza el uso del servidor redundante, aunque con alguna configuración 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 pérdida de datos cero, y no tiene ningún mecanismo integrado
para automatizar la conmutación por error del servidor principal al servidor secundario, se
denomina una solución de reserva activo. La inactividad inherente a traer una línea de
trasvase de registros del servidor secundario varía en función de si hay más 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. Además, ni la detección de fallo del
servidor primario ni la conmutación por error a un servidor secundario son detectadas
automáticamente por las aplicaciones de cliente, lógica de manera adicional debe ser
añadido al cliente o, posiblemente, en un nivel intermedio.
El proceso de envío de registro se controla a través 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 configuración de trasvase de registros con la instancia del servidor
principal, tres instancias del servidor secundario, y una instancia de servidor de
supervisión”23.
23
Página
34
2.12. Conceptos Relacionados UTP

“Tiempo de recuperación esta cercanamente relacionado con la disponibilidad, que es el tiempo
total requerido para un apagón planificado o el tiempo requerido para la recuperación completa de
un apagón no planificado. Tiempo de recuperación puede ser infinito con ciertos diseños y fallos del
sistema, recuperación total es imposible. Uno de tales ejemplos es un incendio o inundación que
destruye un centro de datos y sus sistemas cuando no hay un centro de datos secundario para
recuperación 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 información que
registran y reportan fielmente transacciones del sistema. Especialistas de gestión de la información
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 aplicación pero no perdida de datos

2.13.1. Base de Datos
Una base de datos es una colección de información organizada de forma que un programa
de ordenador pueda seleccionar rápidamente los fragmentos de datos que necesite. Una
base de datos es un sistema de archivos electrónico. 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 información. De allí el término base. "Sistema de información" es
el término 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
Página
35
“Una base de datos proporciona a los usuarios el acceso a datos, que pueden visualizar, UTP
ingresar o actualizar, en concordancia con los derechosProyecto de Ingeniería
de acceso que se de Sistemas
les hayanI
otorgado. Se convierte más útil a medida que la cantidad de datos almacenados crece.
Una base de datos puede ser local, es decir que puede utilizarla sólo un usuario en un
equipo, o puede ser distribuida, es decir que la información se almacena en equipos
remotos y se puede acceder a ella a través de una red.

Es un sistema para la gestión 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. Características:
 Soporte de transacciones.
 Soporta procedimientos almacenados.
 Incluye también un entorno gráfico de administración, que permite el uso
de comandos DDL y DML gráficamente.
 Permite trabajar en modo cliente-servidor, donde la información y datos se
alojan en el servidor y los terminales o clientes de la red sólo acceden a la
información.
Este sistema incluye una versión reducida, llamada MSDE con el mismo motor

de base de datos pero orientado a proyectos más pequeños, que en sus versiones
2005 y 2008 pasa a ser el SQL Express Edition, que se distribuye en
forma gratuita. Es común desarrollar completos proyectos
complementando Microsoft SQL Server y Microsoft Access a través 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 través
de la implementación de aplicaciones de dos capas mediante el uso de
formularios Windows” 25.
25
Bases de Datos - http://es.kioskea.net/contents/bdd/bddintro.php3
Página
36
2.13.2.2. Ediciones UTP

 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 tamaño ni usuarios, ideados
para grupos de trabajos pequeños. Restringida en memoria.
 SQL Server Standard Edition: sin ningún tipo de restricciones. Permite
ejecución hasta en 4 CPUs.
 SQL Server Enterprise Edition: completa, permite particionamiento.
 SQL Server Developer Edition: para desarrolladores
Historia de versiones
Versión Año Nombre de la versión Nombre clave
1.0 (OS/2) 1989 SQL Server 1-0 SQL
4.21 (WinNT) 1993 SQL Server 4.21 SEQUEL
6.0 1995 SQL Server 6.0 SQL95
6.5 1996 SQL Server 6.5 Hydra
7.0 1998 SQL Server 7.0 Sphinx
- 1999 SQL Server 7.0 OLAP Tools Plato
8.0 2000 SQL Server 2000 Shiloh
8.0 2003 SQL Server 2000 64-bit Edition Liberty
9.0 2005 SQL Server 2005 Yukon
10.0 2008 SQL Server 2008 Katmai
10.50 2010 SQL Server 2008 R2 Kilimanjaro
11.0 2012 SQL Server 2012 Denali
Tabla 2: Versiones SQL Server

Fuente: http://www.monografias.com/trabajos81/conceptos-sql-server/conceptos-sql-server.shtml

2.14.1. UML
Página
37
“Es un lenguaje para especificar, construir, visualizar y documentar los artefactos de

un sistema de software orientado a objetos (OO). Un artefacto es una información que es UTP
utilizada o producida mediante un proceso de desarrollo de software.
UML se quiere convertir en un lenguaje estándar 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 estándar de
desarrollo, sino únicamente un lenguaje de modelado. Otros métodos de modelaje como
OMT (Object Modeling Technique) sí definen procesos
En UML los procesos de desarrollo son diferentes según los distintos dominios de trabajo;
no puede ser el mismo el proceso para crear una aplicación en tiempo real, que el proceso
de desarrollo de una aplicación orientada a gestión, por poner un ejemplo. Las diferencias
son muy marcadas y afectan a todas las faces del proceso. El método del UML recomienda
utilizar los procesos que otras metodologías tienen definidos.
2.14.2. Modelado de objetos

En la especificación 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 abstracción cerrada semánticamente de
un sistema y un sistema es una colección de unidades conectadas que son organizadas
para realizar un propósito específico. Un sistema puede ser descripto por uno o más
modelos, posiblemente desde distintos puntos de vista. El UML es una técnica de modelado
de objetos y como tal supone una abstracción de un sistema para llegar a construirlo en
términos concretos. El modelado no es más que la construcción de un modelo a partir de
una especificación. Un modelo es una abstracción de algo, que se elabora para comprender
ese algo antes de construirlo. El modelo omite detalles que no resultan esenciales para la
comprensión del original y por lo tanto facilita dicha comprensión.
Los modelos se utilizan en muchas actividades de la vida humana: antes de construir una
casa el arquitecto utiliza un plano, los músicos representan la música 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
Ingeniería de Software UML - http://www.monografias.com/trabajos5/insof/insof.shtml
“Se consigue un modelo completo de la realidad cuando el modelo captura los aspectos
importantes del problema y omite el resto. Los lenguajes de programación que estamos
acostumbrados a utilizar no son adecuados para realizar modelos completos de sistemas
Página
38
reales porque necesitan una especificación total con detalles que no son importantes para
el algoritmo que están implementando. En OMT se modela un sistema desde tres puntos de UTP
vista diferentes donde cada uno representa una parte del sistema y una unión lo describe de
forma completa. En esta técnica de modelado se utilizó una aproximación al proceso de
implementación 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 dinámico) y se realiza una transformación 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 creación del UML
se persigue obtener un lenguaje que sea capaz de abstraer cualquier tipo de sistema, sea
informático o no, mediante los diagramas, es decir, mediante representaciones gráficas que
contienen toda la información relevante del sistema. Un diagrama es una representación
gráfica de una colección de elementos del modelo, que habitualmente toma forma de grafo
donde los arcos que conectan sus vértices son las relaciones entre los objetos y los vértices
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 información que es utilizada o producida mediante un proceso de
desarrollo de software. Pueden ser artefactos un modelo, una descripción o un software.
Los artefactos de UML se especifican en forma de diagramas, éstos, junto con
la documentación sobre el sistema constituyen los artefactos principales que el modelador
puede observar.
Se necesita más de un punto de vista para llegar a representar un sistema. UML utiliza los
diagramas gráficos para obtener estos distintos puntos de vista de un sistema” 27:
 Diagramas de Implementación.
 Diagramas de Comportamiento o Interacción.
 Diagramas de Casos de uso.
 Diagramas de Clases.
.
27
Diagramas de Implementación
“Se derivan de los diagramas de proceso, aunque presentan algunas modificaciones. Los
diagramas de implementación muestran los aspectos físicos del sistema. Incluyen la
Página
39
estructura del código fuente y la implementación, en tiempo de implementación. Existen dos

tipos Diagramas de componentes y Diagrama de plataformas despliegue. UTP
Diagramas de Componentes
Muestra la dependencia entre los distintos componentes de software, incluyendo
componentes de código fuente, binario y ejecutable. Un componente es un fragmento de
código software (un fuente, binario o ejecutable) que se utiliza para mostrar dependencias
en tiempo de compilación.
Diagrama de Plataformas o Despliegue

Muestra la configuración de los componentes hardware, los procesos, los elementos de
procesamiento en tiempo de ejecución y los objetos que existen en tiempo de ejecución. En
este tipo de diagramas intervienen nodos, asociaciones de comunicación, componentes
dentro de los nodos y objetos que se encuentran a su vez dentro de los componentes. Un
nodo es un objeto físico en tiempo de ejecución, es decir una máquina que se compone
habitualmente de, por lo menos, memoria y capacidad de procesamiento, a su vez puede
estar formada por otros componentes.
Diagramas de Interacción o Comportamiento

Muestran las interacciones entre objetos ocurridas en un escenario (parte) del sistema. Hay
varios tipos:
 Diagrama de Secuencia.
 Diagrama de Colaboración.
 Diagrama de Estado.
 Diagrama de Actividad.
Diagrama de Secuencia.
Muestran las interacciones entre un conjunto de objetos, ordenadas según 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 colaboración, es decir son
instancias concretas de una clase que participa en la interacción”28.
28
Diagrama de Colaboración
Página
40
“Muestra la interacción entre varios objetos y los enlaces que existen entre ellos.
Representa las interacciones entre objetos organizadas alrededor de los objetos y sus UTP
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
información similar, pero en una forma diferente.
Diagramas de Actividad
Son similares a los diagramas de flujo de otras metodologías OO. En realidad se
corresponden con un caso especial de los diagramas de estado donde los estados son
estados de acción y las transiciones vienen provocadas por la finalización de
las acciones que tienen lugar en los estados de origen. Siempre van unidos a una clase o a
la implementación de un caso de uso o de un método.
Diagramas de Estado
“Representan la secuencia de estados por los que un objeto o una interacción entre objetos
pasa durante su tiempo de vida en respuesta a estímulos (eventos) recibidos. Representa lo
que podemos denominar en conjunto una máquina de estados. Un estado en UML es
cuando un objeto o una interacción satisfacen una condición, desarrolla alguna acción o se
encuentra esperando un evento. Como en todas las metodologías OO se envían mensajes,
en este caso es la acción 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 interacción 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
2.14.4. Características:
Página
41
“Además de los conceptos extraídos de métodos anteriores, se han añadido otros nuevos
que vienen a suplir carencias antiguas de la metodología de modelado. Estos nuevos UTP
conceptos son los siguientes:
 Definición 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 extensión del modelo.
 Responsabilidades.
 Mecanismos de extensibilidad: estereotipos, valores etiquetados y restricciones.
 Tareas y procesos.
 Distribución y concurrencia (para modelar por ejemplo ActiveX/DCOM y CORBA).

 Patrones/Colaboraciones.
 Diagramas de actividad (para reingeniería de proceso de negocios)

 Clara separación de tipo, clase e instancia.
 Refinamiento (para manejar relaciones entre niveles de abstracción).
 Interfaces y componentes” 30.
2.15. Sistema de Hipótesis

Con la implantación de metodologías de Alta Disponibilidad de servidores de base de datos
podemos incrementar el nivel de rentabilidad en un 80%; por consiguiente también 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 caídas de servidores de base de datos.
30
Página
42
CAPÍTULO 3: MARCO METODOLÓGICO UTP

3.1. Nivel Análisis de la Investigación

El proyecto se basa en un nivel de investigación exploratoria, descriptiva y explicativa, ya que se
expondrá las características, beneficios y/o limitaciones de las diferentes metodologías de alta
disponibilidad aplicadas a los servidores de base datos.
Descriptiva: Tiene como objetivo medir las características del impacto de las metodologías de alta
disponibilidad en los servidores de base de datos críticos, estas características pueden ser cantidad
de servidores, tamaño de base de datos, distribución de aplicaciones, caídas en un determinado
tiempo, complejidad de la arquitectura de red, tipos de tecnología. A partir del levantamiento de la
información de las variables, las expresaremos cuantitativamente para poder calcular y medir:
cantidad de caídas de servidores de base de datos (conectividad) y el costo asociado a la
indisponibilidad de datos (S/.).
3.2. Diseño de la Investigación

3.2.1. Métodos
Para el desarrollo de la investigación se empleara los siguientes métodos:
3.2.1.1. Método Experimental
Dado que se llevara a cabo un estudio de todos los historiales (logs) de caídas de
los servidores de base de datos para recopilar información y posterior análisis y
comprobación.
Primero: se recogerá información de problemas de acceso a la información por
caídas 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 metodologías de alta disponibilidad de
servidores de base de datos se determinará el nuevo tiempo diario que no se tiene
acceso a la información. Esta información se analizará y evaluará para determinar
el nivel de disponibilidad que se llegó a obtener en base a comparación de
resultados.
3.2.1.2. Método de Observación

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.
Página
43
3.2.1.3. Método de Medición UTP

Para la obtención y comparación de datos numéricos y relacionados a la
disponibilidad de la información, es decir la cantidad de caídas o indisponibilidad
de la información por caídas eventuales de los servidores de base de datos.
3.2.2. Recopilación de Información:

Según la información recolectada mediante el análisis de datos de información en un Data
Center se cuenta con los siguientes servidores:
 Servidores de Base de Datos:
 7 Servidores (Perú, Brasil, Venezuela, Centro América, Colombia, Asia, Ecuador)
 10 Base de Datos
 7 Servidores de Reporting Services
 3 Servidores de Business Intelligence
De acuerdo al método de observación y medición, se llegó a determinar el siguiente cuadro

de disponibilidad:
AÑ
TIEMPO OFFLINE/AÑO TIEMPO OFFLINE/MES TIEMPO OFFLINE/DÍA
O
200
36 días 72 hrs 2 hrs
9
201
24 días 48 hrs 1.5 hrs
0
201
1
3.2.2.1. Técnicas
Para lograr la obtención de información, conocimiento y llevar el control de los
datos se hacer uso de las siguientes técnicas:
Entrevista
Página
44
Dirigidas al administrador de base de datos para obtener información específica de

caídas de los servidores de base datos, como datos de tiempo que se encuentran UTP
detenidos los procesos de pagos y cobros.
Observación Directa
Utilizado para que mediante la observación de los factores que influyen en el
comportamiento de la variable se haga una recolección de datos.
Análisis de Datos
Técnica 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 análisis me
permitirá tener una bitácora de información y así poder tener una mejor
organización en el manejo de la información.
3.2.2.2. Instrumentos
Dentro de los instrumentos a usaremos para recolectar y registrar información son
los siguientes:
Listas de chequeos: que nos permitirán 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 información tanto de los servidores de base

de datos como los sistemas que interactúan con estos, así podremos clasificarlos
por su criticidad. Estos formularios nos permitirán calcular el costo/tiempo de
inactividad y determinar las tasas de disponibilidad y objetivos de recuperación.
Test de conexión: 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 información mediante los métodos, técnicas e instrumentos mencionados

anteriormente, aplicaremos la metodología RUP para el análisis y diseño de la solución.
El RUP nos permitirá adaptarnos al nuevo proceso de alta disponibilidad, equilibrando prioridades
de disponibilidad de las aplicaciones, elevar el nivel de abstracción, para poder satisfacer de la
mejor manera los requisitos, un alto nivel de abstracción nos permitirá escoger mejor la solución
Página
45
arquitectónica de alta disponibilidad a utilizar. Por último enfocarnos en el control de calidad no solo
al final cada iteración del proyecto, sino en todos los aspectos de la implementación. UTP
3.2.3. Actividades:
Modelado del Negocio:
 Entender la estructura de distribución, conexión de los servidores de base de datos de la
organización, para las cuales la arquitectura de alta disponibilidad será implementada.
 Entender a la perfección el problema de las caídas 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 podría hacer.
 Mediante la recolección de información detallada anteriormente podremos tener una
base para estimar costos y tiempo de desarrollo.
Análisis y Diseño:
 Trasformar los requisitos al diseño de la solución.
 Desarrollar la nueva arquitectura de alta disponibilidad.
Implementación:
 Planificar que arquitecturas deberán ser implementadas dependiendo de la criticidad de
los servidores y en que orden ser integrados.
 Si se encuentra algunos errores de diseño, se notificará.
Pruebas:
 Encontrar y documentar defectos en la calidad de la arquitectura de alta disponibilidad.
 Proveeremos la validación de los supuestos realizados en el diseño y especificación de
requisitos por medio de demostraciones concretas.
 Verificar las funciones de la arquitectura de alta disponibilidad según lo diseñado, al
mismo tiempo que los requisitos tengan una apropiada implementación.
Página
46
Despliegue:
 Probar la arquitectura de alta disponibilidad en su entorno de ejecución final. UTP
 Distribuir la arquitectura.
 Implementar la arquitectura.
 Migrar bases de datos.
Gestión del proyecto:

 Contratar personal, ejecutar y monitorear el proyecto.
 Proveer un marco de trabajo para gestionar riesgos.
Entorno:
 Selección y adquisición de herramientas.
 Configuración del proceso.
 Mejora del proceso.
 Servicios técnicos.
Los instrumentos a utilizar para desarrollar nuestra metodología son:

 Documento Visión
 Especificación de Requisitos
 Diagramas de caso de uso
 Diagrama de Secuencia
 Diagrama de estados
 Diagrama de Colaboración
 Mapa de comportamiento a nivel de hardware.
3.3. METODOLOGÍA PARA EL ESTUDIO DE FACTIBILIDAD DE LA SOLUCIÓN

Para medir la factibilidad o viabilidad de la implementación 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.
Página
47
Esta empresa al igual que la nuestra, retornaba la disponibilidad de sus servidores

manualmente lo que ocasionaba el detenimiento de las transacciones bancarias que UTP
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.
Caso de éxito 2:
Empresa: Mercadotecnia Ideas y Tecnología.
Esta empresa tenía implementada la arquitectura de alta disponibilidad Mirroring solo a las
bases de datos donde se almacenaban la información de las empresas proveedoras.
Después de un estudio de disponibilidad de sus servidores, se decidió aplicar la arquitectura
de alta disponibilidad Mirroring las bases de datos críticas 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 años:

AÑ
TIEMPO OFFLINE/AÑO TIEMPO OFFLINE/MES TIEMPO OFFLINE/DÍA
O
200
36 días 72 hrs 2 hrs
9
201
0
201
El 24 días 48 hrs 1.2 hrs
1
siguiente cuadro muestra las ventas anuales de los últimos 3 años:
AÑ
Ventas Mensuales ($) Ventas Anuales ($)
O
200
18 000 216 000
9
201
22 000 264 000
0
201
24 000 288 000
1
Página
48
Mediante la siguiente fórmula podremos calcular la pérdida de ventas al no contar con una
arquitectura de alta disponibilidad: UTP
% Pérdida (Mensual) = (Horas OFFLINE Mensual x 100 por ciento) / 720 hrs
Para calcular la disponibilidad, lo realizamos con la siguiente fórmula:
Disponibilidad = ((A – B)/A) x 100 por ciento)

Donde:
A = Horas comprometidas de disponibilidad: 24 x 365 = 8,760 Horas/año.
B = Número de horas fuera de línea (Horas de "caída del sistema" durante el tiempo de
disponibilidad comprometido).
Al aplicar las arquitecturas de Alta Disponibilidad podremos medir el aumento de rentabilidad

mediante:
Rentabilidad Actual = Rentabilidad del ultimo año – (Rentabilidad del ultimo año x %Pérdida)
3.3.2. Costos de Hardware y Software
Hardware
Dispositivos Cantidad Precio Subtotal
Servidor (RX 6600) 2 S/. 6,000.00 S/. 12,000.00
UPS Interactivo 2 S/. 300.00 S/. 600.00
Cableado (por metro) 70 S/. 7.00 S/. 490.00
Total S/. 13,090.00
Software
Software/ Licencia Cantidad Precio Subtotal
Windows Server 2008 R2 2 S/. 1,500.00 S/. 3,000.00
SQL Server 2008 R2 2 S/. 350.00 S/. 700.00
Total S/. 3,700.00
Total = Total Hardware + Total Software

Total = 13,090.00 + 3,700.00
Total = S/. 16,790.00
Página
49
Teniendo la información del tiempo fuera de línea de las aplicaciones, las ventas anuales de la
organización, costos de hardware/ software y las fórmulas de medición de pérdidas y alta UTP
disponibilidad, aplicaremos para medir y validar el impacto cuantitativo de nuestra solución, el
método de Simulación estadística: Método de Montecarlo
Este método nos permitirá aproximar y evaluar con exactitud nuestras expresiones matemáticas
mencionadas anteriormente. Las pruebas a realizar mediante este método se podrán realizar
simplemente en una hoja de cálculo 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
medición un +/- 5%.
La clave de la simulación de Montecarlo, consiste en crear un modelo matemático 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 solución.
3.3.3. Técnicas:
 Establecer distribuciones de probabilidad. La idea inicial es la generación 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 pérdidas en ventas diarias, el tiempo deservicio de aplicaciones. Y una
manera fácil de establecer una distribución de probabilidad de una variable es a través
de examen histórico. La frecuencia relativa para cada resultado de una variable se
encuentra al dividir la frecuencia de la observación entre el número total de
observaciones
 Interpretar la frecuencia relativa como la probabilidad de que ocurra una caída en los
servidores de base de datos.
 Recolección de datos y determinación de frecuencias relativas
 Asignación de números aleatorios
 Formulación del modelo
 Solución
 Análisis
Página
50
CAPÍTULO 4: ASPECTOS ADMINISTRATIVOS UTP

4.1. ÍNDICE PRELIMINAR DE LA TESIS
INTRODUCCIÓN
1. Formulación del Problema

1.1. Planteamiento del Problema
1.2. Antecedentes de solución
1.2.1. Caso de Éxito
1.3. Propuesta de solución
1.4. Alcance de la propuesta
1.5. Justificación
1.5.1. Por qué
1.5.2. Para qué
1.6. Objetivos
1.6.1. Objetivo General
1.6.2. Objetivos Específicos
2. Marco Teórico
2.1.1. Caso de Éxito
2.2. Alta Disponibilidad
2.3. Medición de la Disponibilidad
2.4. Niveles de Disponibilidad
2.5.1. Tiempo Fuera de Servicio Planeado
2.5.2. Tiempo Fuera de Servicio No Planeado
2.5.3. Estrategias
2.6. Clasificación de desastres
2.7.1. Fallas de Hardware
2.7.2. Fallas de Software
2.7.3. Fallas Ambientales
2.7.4. Errores Humanos
Página
51
2.8. Beneficios de alta disponibilidad de acuerdo a la problemática de AJEGROUP UTP

2.8.1. Mirroring
2.8.3. Log Shipping
2.9. Planificación de una arquitectura de alta disponibilidad
2.10. Limitaciones y Evaluación de la arquitectura
2.11.1. Mirroring
2.11.1.1. Definición
2.11.1.2. Estados
2.11.1.3. Modos de operación
2.11.1.4. Servidores
2.11.2.1. Tipos
2.11.3. Log Shipping
2.12. Conceptos Relacionados
2.13.1. Base de Datos
2.13.2.1. Características
2.13.2.2. Ediciones
2.14.1. UML
2.14.2. Modelado de Objetos
2.14.3. Artefactos
2.14.4. Características
2.15. Sistema de Hipótesis
2.16. Sistema de Variables
3. Marco Metodológico
3.1. Nivel de Análisis de la Investigación
3.2. Diseño de la Investigación
3.2.1. Métodos
3.2.1.1. Método Experimental
3.2.1.2. Método de Observación
3.2.1.3. Método de Medición
Página
52
3.2.2. Recopilación de Información

3.2.2.1. Técnicas UTP
3.2.2.2. Instrumentos
3.2.3. Actividades
3.3. Metodología para el estudio de factibilidad de la Solución

3.3.1. Casos de Éxito
3.3.2. Costos de Hardware y Software
3.3.3. Técnicas
4. Solución Propuesta
4.1. Análisis de las arquitecturas de Alta Disponibilidad propuestas
4.1.1. Análisis Estratégico
4.1.2. Análisis Funcional
4.2. Fuentes de Financiamiento
4.3. Propuesta del Proyecto
4.4. Definir los procesos de las arquitecturas de Alta Disponibilidad
5. Diseño de la solución
5.1. Diagrama de Procesos
5.2. Diagrama de Actividades
5.3. Diagrama de Secuencia
5.4. Diagrama de Estados
6. Desarrollo de prototipo
6.1. Arquitectura Mirroring
6.2. Arquitectura Replicación
6.3. Arquitectura Log Shipping
6.4. Pruebas
7. Impacto esperado
7.1. Descripción
7.2. Validación del modelo
7.3. Sustentación de hipótesis
8. Conclusiones
9. Recomendaciones
10. Referencias
11. Anexo
Página
53
4.2 PRESUPUESTO DE INVESTIGACIÓN UTP

Mes: Setiembre
Costo
Horas Costo
Descripción Días Unitari
Diarias Total
o
Alquiler Cabinas Internet 3 10 1.5 45
Investigación en domicilio 4 10 1.00 40
Asesoría 2 3 50 300
Impresiones 12
Luz 15
Útiles de Oficina 8
Pasajes 18
Total 438
Mes: Octubre
Costo
Horas Costo
Diarias Total
o
Alquiler Cabinas Internet 1 7 1.5 10.5
Impresiones 12
Luz 17
Pasajes 10
Total 289.5
Mes: Noviembre
Horas Día Costo Costo
Descripción
Diarias s Unitario Total
Alquiler Cabinas Internet 2 14 1.5 42
Impresiones 20
Pasajes 15
Total 265
Mes: Diciembre
Costo
Horas Costo
Diarias Total
o
Página
54
Impresiones 20 UTP
Luz 18 de Ingeniería de Sistemas I
Proyecto
Pasajes 9
Total 253
Total
Mes Costo
Setiembre 438
Octubre 289.5
Noviembr
265
e
Diciembre 253
Total 1245.5
Página
55
CRONOGRAMA DE ACTIVIDADES UTP

Página
56
UTP
REFERENCIAS
1. Desastres Informáticos: previsión y prevención

http://www.idg.es/computerworld/Desastres-informaticos-prevision-y-prevencion.La-p/seccion-ti/articulo-
130035
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. Solución de Alta Disponibilidad de Base de Datos

Facultad de Ingeniería de la Universidad San Carlos de Guatemala
6. Red Hat Enterprise Linux 4

Introducción a la administración de sistemas Cap. 8: Planificación 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. Ingeniería de Software UML

http://www.monografias.com/trabajos5/insof/insof.shtml
Página
57
UTP
ANEXOS
Página
58

Proyectos de Ingenieria de Sistemas I: Wilmer Perfecto

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

Proyectos de Ingenieria de Sistemas I: Wilmer Perfecto

Caricato da

Copyright:

Formati disponibili

PROYECTOS DE INGENIERIA DE SISTEMAS I

ASESOR: Wilmer Perfecto

Eduardo Aldo Navarro Yataco

Incrementar el Nivel de Rentabilidad Mediante la Continuidad de los Sistemas de

INGENIERIA INDUSTRIAL Y DE SISTEMAS

PLAN DE TESIS UTP

CAPÍTULO 1: Formulación del Problema

CAPÍTULO 2: Marco Teórico

2.9. Planificación de una arquitectura de alta disponibilidad……………………………………….. 25 UTP

CAPÍTULO 3: Marco Metodológico

3.3. Metodología para el estudio de factibilidad de la Solución UTP

CAPÍTULO 4: Aspectos Administrativos

Tradicionalmente se ha entendido por desastre un incendio o inundación, porque este tipo de

1.1. Planteamiento del Problema

1.2. Antecedentes de Solución

1.2.1. Caso de éxito

“Perfil del Cliente

Reto del negocio

1.3. Propuesta de Solución UTP

1.4. Alcance de la Propuesta

1.5. Justificación UTP

1.5.2. ¿Para qué?

1.6. Objetivos UTP

1.6.2. Objetivos Específicos

2.1. Antecedentes de la Investigación

2.1.1. Caso de éxito

Reto del negocio

2.2. Alta Disponibilidad UTP

2.3. Medición de la Disponibilidad

Disponibilidad = ((A – B)/A) x 100 por ciento)

Disponibilidad = ((8,760 – 24)/8,760) x 100 por ciento) = 99.726%

Tabla 1: Disponibilidad para un sistema 24×7 y tiempos de caída permitidos

2.4. Niveles de disponibilidad

Alta Disponibilidad: las funciones de negocios aceptan pequeñas interrupciones y al retomar se

Resistencia a fallas: requiere de operación ininterrumpida en horario laboral, se retoma en caso de

Tolerancia a Desastres: disponibilidad en todo momento, capacidad para soportar desastres

2.5. Tiempo Fuera de Servicio

Figura 1: Causas del Tiempo Fuera de Servicio

2.5.1. Tiempo fuera de servicio planeado

2.5.2. Tiempo fuera de servicio no planeado

 Minimizar el número de defectos y el efecto / recuperación en el tiempo de los defectos

Figura 2: Causas desconocidas no planeadas

La solución lógica para incrementar la disponibilidad es mantener los datos en más de un

2.5.3. Estrategias para maximizar la disponibilidad sin quebrar económicamente a la

de poder redundantes, múltiples procesadores, memoria segmentada y discos redundantes.

2.6. Clasificación de desastres

2.7. Tipos de desastres

2.7.1. Fallas de hardware

Mantener partes adicionales de hardware

2.7.2. Fallas de Software

Fallas del sistema operativo

Fallas de las aplicaciones

2.7.3. Fallas Ambientales

Integridad del edificio

“He aquí algunas de las posibilidades a considerar:

Calefacción, Ventilación y Aire Acondicionado

He aquí algunos ejemplos:

 Las unidades de manejo de aire acondicionado (esencialmente grandes ventiladores

El tiempo y el mundo externo

2.7.4. Errores Humanos

Errores humanos del usuario final

Errores del personal de operaciones

Errores del Administrador del Sistema