Ciclo Formativo de Grado

Superior de Administración de
Sistemas Informáticos en Red

Módulo Profesional: SAD

U.T. 9.- Configuraciones de alta
disponibilidad
Departamento de Informática y Comunicación
IES San Juan Bosco (Lorca-Murcia)
Profesor: Juan Antonio López Quesada
 Alta Disponibilidad

Determinación de requisitos en Alta

Disponibilidad
Elección de una arquitectura de alta
disponibilidad

Máxima Disponibilidad

Esquema general de la Alta Disponibilidad

Entorno HA para Linux

Soluciones HA para Linux

Referencias WEB

Enlaces a Herramientas SW

3
Analizar las distintas configuraciones de alta disponibilidad.

Valorar la importancia de realizar un buen análisis de riesgos

potenciales en sistemas críticos y adoptar medidas para paliar sus
posibles consecuencias.

Aprender las diferencias, ventajas e inconvenientes entre los

sistemas de almacenamiento redundante (RAID) y conocer sus
opciones de configuración y prueba.

Conocer las opciones de configuración y administración de

balanceo de carga entre distintas conexiones de red.

Realizar configuraciones de alta disponibilidad de servidores

mediante virtualización de sistemas operativos.

4
En la actualidad el sector de las tecnologías de la
información y la comunicación están presentes en
nuestra vida, ya sea a la hora de trabajar, a la hora de
comunicarnos, a la hora de organizar un viaje, etc. En
definitiva, por uno u otro motivo siempre las
necesitamos por lo que es necesario asegurar que estas
tecnologías se van a encontrar disponibles siempre
que las necesitemos y además van a funcionar
aportando la información de manera rápida y
eficiente.
Por ejemplo cada vez que se desea acceder al correo
electrónico, la posibilidad de que éste no se encuentre
operativo temporalmente puede ocasionarnos
molestias o cada vez que accedemos a un buscador
Web no pensamos en que tal vez la búsqueda tarde
demasiado y no sea posible consultar esa información
tan importante. Esto no sucede, en gran parte, gracias
a los dos conceptos que se introducen: alta
disponibilidad y alto rendimiento.

5
 Las bases de datos y el auge de Internet han permitido la colaboración y el intercambio de
información desde cualquier parte del mundo, ampliando el alcance de las aplicaciones de
bases de datos en todas las organizaciones y comunidades. Este alcance nos hace resaltar la
importancia de la alta disponibilidad (HA, del inglés High Availability) en soluciones de
gestión de datos. Tanto las pequeñas empresas y las empresas mundiales tienen usuarios de
todo el mundo que necesitan acceso a los datos las 24 horas del día. Sin este acceso a datos,
las operaciones pueden detenerse, y perder ciertos ingresos. Los usuarios se han vuelto más
dependientes de sus soluciones, que ahora exigen acuerdos de nivel de servicio de sus
departamentos de Tecnología de la Información (IT, del inglés Information Technology) y
proveedores.

 Cada vez más, la disponibilidad se mide en dólares y euros, y no sólo en tiempo y comodidad.
Las empresas han utilizado su infraestructura de IT para proporcionar una ventaja competitiva,
aumentar la productividad, y la autonomía de los usuarios para realizar más rápido y con
mayor información las decisiones. Sin embargo, con estos beneficios ha llegado una
dependencia cada vez mayor de la infraestructura. Si una aplicación crítica no está disponible,
entonces toda la empresa puede estar en peligro. Los ingresos y los clientes pueden perderse,
las sanciones pueden ser grandes y la publicidad negativa puede tener un efecto duradero
sobre los clientes. Es muy importante examinar los factores que determinan la forma en que
sus datos están protegidos y maximizar la disponibilidad para sus usuarios.

6
 La disponibilidad es el grado en que una aplicación o servicio está disponible cuándo y cómo
los usuarios esperan. La disponibilidad se mide por la percepción de una aplicación del
usuario final. Los usuarios finales experimentan frustración cuando sus datos no están
disponibles, y ellos no entienden o son capaces de diferenciar los complejos componentes de
una solución global. Fiabilidad, valorización, continuas operaciones y detección de errores son
características de una solución de alta disponibilidad:

 Fiabilidad: Los componentes hardware fiables de una solución de HA, el software

fiable, incluida la base de datos, servidores web y aplicaciones, es la parte crítica
de una implementación de una solución de alta disponibilidad.

 Recuperación: Puede haber muchas opciones para recuperarse de un fracaso si

ocurre alguno. Es importante determinar qué tipo de fallos pueden ocurrir en su
entorno de alta disponibilidad y la forma de recuperarse de estos fallos en el
tiempo que satisface las necesidades comerciales. Por ejemplo, si una tabla
importante es eliminada de la base de datos, ¿qué medidas adoptarías para
recuperarla? ¿Su arquitectura ofrece la capacidad de recuperarse en el tiempo
especificado en un acuerdo de nivel de servicio (SLA)?

7
 Detección de errores: Si un componente en su arquitectura falla,
entonces la rápida detección, de dicho componente es esencial en
la recuperación de un posible fracaso inesperado. Si bien es
posible que pueda recuperarse rápidamente de un corte de luz, si
se lleva a otros 90 minutos para descubrir el problema, entonces
usted no puede satisfacer su SLA. La monitorización del estado
del entorno de trabajo requiere un software fiable, para ver de
forma rápida y notificar al administrador de bases de datos (DBA
) un problema.

 Continuas operaciones: El continuo acceso a sus datos es

esencial, por muy pequeño o inexistente que sea el tiempo de
caída del sistema, para llevar a cabo las tareas de mantenimiento.
Actividades como mover una tabla de un lado a otro dentro de la
base de datos, o incluso añadir nuevas CPU’s a su hardware debe
ser transparente para el usuario final en una arquitectura HA.

8
 La importancia de la alta disponibilidad varía dependiendo de las aplicaciones. Sin
embargo, la necesidad de aumentar los niveles de disponibilidad continúa acelerándose
tanto como las empresas rediseñan sus soluciones para conseguir una ventaja más
competitiva. La mayoría de las veces estas nuevas soluciones se basan en el acceso
inmediato a datos críticos para el negocio. Cuando los datos no están disponibles, la
aplicación puede dejar de funcionar. El tiempo de inactividad o caída del sistema, puede
conducir a pérdida de productividad, pérdida de ingresos, dañando las relaciones con los
clientes, la mala publicidad, y pleitos. Si una aplicación con tarea crítica no está
disponible, entonces la empresa se encuentra en peligro. No siempre es fácil colocar un
coste directo sobre el tiempo de inactividad. El enfado con los clientes, los empleados
que han intervenido y la mala publicidad son costosos, pero no directamente se pueden
medir en dinero. Por otro lado, la pérdida de ingresos y las sanciones legales ocurridas
por no alcanzar el SLA garantizado no son fácilmente cuantificadas. El costo de la
inactividad puede crecer rápidamente en las industrias que dependen de soluciones que
prestan servicio en todo momento.

9
 Otros factores a considerar en el coste de la inactividad son los niveles máximos tolerables en
cuanto a la duración de un solo corte de luz ocurrido, y la frecuencia máxima permisible de
incidentes. Si la interrupción en cuestión dura menos de 30 segundos, entonces puede causar muy
poco daño y resulta casi imperceptible para los usuarios finales. Como la duración de la interrupción
crezca, crece el malestar, pasando de un pequeño problema a un gran problema, y posiblemente en
una acción legal. Al diseñar una solución, es importante tener en cuenta estas cuestiones y
determinar el verdadero coste de la inactividad. Una organización debe gastar una cantidad
razonable de dinero para construir soluciones que sean altamente disponibles, pero este coste está
justificado. Existen soluciones de alta disponibilidad a disposición de cada cliente
independientemente de su tamaño. Tanto pequeños grupos de trabajo como las empresas mundiales
son capaces de extender por todo el mundo el alcance de sus aplicaciones críticas de negocio. Con
la alta disponibilidad y Internet se consigue que las aplicaciones y sus datos están ahora accesibles y
fiables en todas partes, en cualquier momento.

 Uno de los retos en el diseño de una solución de HA es examinar y abordar todas las posibles causas
de una posible inactividad. Es importante considerar tanto las causas de tiempo de inactividad
planificado y no planificado. El tiempo de inactividad no planificado engloba los fallos del
ordenador y los fallos de datos. Los fallos de datos pueden ser causados por fallos en el
almacenamiento, errores humanos y fallos del sitio. Los tiempos de inactividad planificados
incluyen cambios en el sistema y los cambios de datos. Planear la inactividad, en ocasiones puede
ser muy perjudicial en las operaciones, especialmente en las empresas mundiales que soportan
usuarios en múltiples zonas horarias.

10
 La naturaleza interconectada de las empresas mundiales de hoy en día, exige la
continua disponibilidad de cada vez más componentes de la empresa. Sin embargo,
un negocio que es diseñado y implementado siguiendo una estrategia de HA debe
realizar un profundo análisis y tener una completa comprensión de los
componentes de la empresa que requieren alta disponibilidad, ya que la
implementación de alta disponibilidad es muy costosa. Puede consistir en tareas
críticas tales como:

La inversión en más sofisticados y robustos sistemas e instalaciones

Rediseñar la arquitectura de IT para adaptarse al modelo de alta
disponibilidad
Rediseñar los procesos de negocio
Contratación y capacitación de personal
Los niveles más elevados de disponibilidad reducen el tiempo de
inactividad de forma significativa, como se muestra en el cuadro
siguiente:

11
 Aproximación de tiempo en
Porcentaje de disponibilidad
inactividad por año
95% 18 días
99% 4 días
99,9% 9 horas
99,99% 1 hora
99,999% 5 minutos

 Las empresas con la más alta disponibilidad deben ser más tolerantes a fallos, sistemas
redundantes para los componentes de su negocio y tener una mayor inversión en el personal
de IT, procesos y servicios para asegurar que el riesgo de inactividad en las empresas sea
mínimo. Un análisis de los requisitos empresariales de alta disponibilidad y la comprensión
de los costes que van incluidos, permite una solución óptima que satisfaga las necesidades de
los directores de empresa estarán dispuestos a pagar, dentro de las posibilidades financieras y
de las limitaciones de recursos de la empresa. A continuación proporcionaremos un marco
simple que se puede utilizar con eficacia para evaluar los requisitos de alta disponibilidad que
una empresa necesita.

12
Análisis del impacto de negocios

 Un riguroso análisis de impacto, identifica los procesos críticos de negocio

dentro de una organización, calcula pérdida cuantificable sobre previstas e
imprevistas caídas del sistema que afectan a cada uno de estos procesos de
negocio, y se esbozan los efectos menos tangibles de estas caídas. Tiene en
cuenta las funciones esenciales de la empresa, personas y recursos del
sistema, las regulaciones gubernamentales y las dependencias
empresariales internas y externas dependencias. Este análisis se hace
usando datos objetivos y subjetivos recogidos de entrevistas con expertos y
personal experimentado, revisando historiales de prácticas de empresas,
informes financieros, los sistemas de registros, y así sucesivamente.

13
 En el análisis del impacto sobre las empresas se clasifican los procesos de
negocio basados en la importancia del impacto sufrido con las paradas del
sistema relacionadas con las IT. Por ejemplo, considere la posibilidad de
un fabricante de semiconductores, con centros de diseño de chips en todo
el mundo. Un sistema interno de la empresa da acceso a los recursos
humanos, gastos de negocio y la adquisición interna se considera
probablemente como tarea crítica como puede ser el sistema de correo
electrónico interno. Cualquier tiempo de inactividad en el sistema de
correo electrónico, puede afectar gravemente a la colaboración y
capacidades de comunicación global entre los centros de I+D, causando
retrasos inesperados en la fabricación de chips, que a su vez tienen un
impacto financiero en la empresa. Esto nos lleva al siguiente elemento en
el marco de los requerimientos de alta disponibilidad: el coste por tiempo
de inactividad.

14
Coste de inactividad

 Un bien análisis de impacto en las empresas proporciona información

detallada sobre los costes que se derivan de tiempos de parada no
planificados y planificados de los sistemas de apoyo a los diversos
procesos de negocio. La comprensión de este coste es esencial porque esta
tiene una influencia directa sobre la disponibilidad de alta tecnología que
se utiliza para reducir al mínimo el riesgo de inactividad.

 Varios informes han sido publicados, la documentación de los costes

inactividad a través de industrias importantes. Estos costes van desde
millones de dólares por hora para las operaciones de corretaje (comisión
como pago por los servicios prestados por un intermediario, en este caso
la empresa) y de ventas con tarjeta de crédito, a decenas de miles de
dólares por hora para los servicios de envíos de paquetes.
15
 Si bien estas cifras son alarmantes, las razones son bastante obvias.
Internet ha permitido a millones de clientes acceder directamente a todo
tipo de tiendas online. Los críticos y los negocios independientes se
cuestionan que las relaciones con los clientes, ventajas competitivas, las
obligaciones legales, la reputación de la industria y la confianza de los
accionistas, tiene que ser ahora mucho más importante, debido a su mayor
vulnerabilidad a las interrupciones del negocio.

16
Tiempo de recuperación Objetivo (RTO)

 Un análisis de impacto en la empresa, así como el coste calculado de

inactividad, proporciona información detallada sobre el Tiempo de
Recuperación Objetivo (RTO), un dato importante en la planificación
continua de las actividades. Se define como la cantidad máxima de tiempo
que un negocio basado en procesos de IT puede estar caído antes de que
comience a sufrir importantes pérdidas materiales. RTO indica la tolerancia
de inactividad de un proceso del negocio o de una organización en general.

 El RTO variará proporcionalmente a la naturaleza de tarea crítica del

negocio en cuestión. Por lo tanto, un sistema que esté ejecutando una bolsa
de valores, el RTO es cero o muy cercano a cero.

17
 Una organización probablemente puede tener diferentes RTO según las
necesidades de sus diversos procesos. Por lo tanto, la mayoría de e-comercios de la
web, para los cuales existen la expectativa de un rápido tiempo de respuesta y para
los cuales los costes son muy bajos, es probable que tenga un RTO cercano a cero.
Sin embargo, la RTO de los sistemas que soportan las operaciones de “almacén”,
como las operaciones de envío y de facturación puede ser mayor. Si estos sistemas
de “almacén” se caen, entonces la empresa puede recurrir al manual de
instrucciones estipulado en esos casos temporalmente sin una significativa
repercusión visible.
 Un sistema de estadística relacionado con el RTO es la Recuperación de Red
Objetiva (NRO), que indica el tiempo máximo que las operaciones en la red
pueden estar caídas en un negocio. Los componentes de las operaciones de la red
incluyen enlaces de comunicación, routers, servidores de nombres, balanceadores
de carga y los administradores de tráfico. El NRO impacta en el RTO de toda la
organización porque los servidores individuales son inútiles si no se puede acceder
a la red cuando está caída.

18
Punto de Recuperación Objetivo (RPO)

 El Punto de Recuperación Objetivo (RPO) es otro dato importante para la

continuidad de las actividades de planificación del negocio y se calcula a través de
un efectivo análisis de impacto sobre las empresas. Se define como la cantidad
máxima de datos basados en procesos de negocio de IT, que pueden ser perdidos
antes de causar un daño perjudicial para la organización. RPO indica la tolerancia
de pérdida de datos de un proceso de negocio o una organización en general. Esta
pérdida de datos a menudo se mide en términos de tiempo, por ejemplo, 5 horas o 2
días de valor de pérdida de datos.
 Una bolsa de valores, en la cual el valor de las transacciones es de millones de
dólares producidos cada minuto, no puede darse el lujo de perder ningún dato. Por
lo tanto, su RPO deberá ser cero. Refiriéndose al ejemplo del e-comercio, las
ventas basadas en páginas web, no requieren estrictamente un RPO de cero, a pesar
de que una baja RPO es esencial para la satisfacción del cliente. Sin embargo, su
comercialización y el sistema de actualización de inventario pueden tener un mayor
RPO, ya que la pérdida de datos en este caso puede ser introducida de nuevo.

19
 Utilizando el marco del análisis de alta disponibilidad, una empresa puede
completar el análisis de impacto identificando y clasificando los procesos críticos
de negocio que tienen los requisitos de alta disponibilidad, formulando el coste de
la inactividad, y estableciendo los objetivos para el RPO y el RTO de los diversos
procesos de negocio. Esto permite a la empresa definir acuerdos de nivel de
servicio (SLA’s) en términos de alta disponibilidad para éstos aspectos críticos de
su negocio. Por ejemplo, puede clasificar sus negocios en varios niveles de HA:

Nivel 1: Procesos de negocio que tengan el máximo impacto en las empresas.

Ellos tienen los más estrictos requisitos de HA, con un RPO y RTO cercano a
cero, y los sistemas de soporte deben estar disponibles continuamente. Por
ejemplo, para una empresa con un alto volumen de presencia en el e-comercio,
el nivel uno podría ser una aplicación web basada en un sistema de interacción
con los clientes.

20
 Nivel 2: Procesos de negocio que pueden tener un poco relajada la HA y los
requisitos de RTO / RPO. El segundo nivel de un negocio de e-comercio puede
ser la cadena de suministro o sistemas de merchandising. Por ejemplo, en estos
sistemas no es necesario mantener la disponibilidad de 99,999%, y pueden
tener unos valores de RTO / RPO distintos de cero. Por lo tanto, el sistema HA
y las tecnologías elegidas para soportar estos dos niveles de negocios serán
probablemente diferentes.

Nivel 3: Procesos de negocio que están relacionados con el desarrollo interno y

los procesos de garantía de calidad. Los sistemas de soporte de estos procesos
no necesitan tener unos rigurosos recursos de HA, como los demás niveles.

El siguiente paso para la empresa es evaluar las capacidades de los distintos sistemas
y tecnologías de HA y elegir los SLA que se ajusten a sus necesidades, dentro de las
directrices dictadas por problemas de rendimiento de negocio, las limitaciones
presupuestarias, y la previsión del crecimiento de los negocios.

21
Una amplia gama de soluciones de alta disponibilidad y de continuidad del negocio existen en la actualidad.
Como la complejidad y el alcance de estos sistemas se incrementan, se crea una infraestructura de IT,
compuesta por el almacenamiento de datos, servidores, la red, aplicaciones y servicios de alta
disponibilidad. Esto también reduce el RPO y RTO de días a horas o incluso minutos. Pero el aumento de la
disponibilidad viene con un incremento de los costes, y en algunas ocasiones, con un mayor impacto en los
sistemas de rendimiento.
Las organizaciones necesitan analizar cuidadosamente la capacidad de esos sistemas de HA y el mapa de
sus capacidades en los requisitos del negocio para asegurarse de que tienen una combinación óptima de
soluciones HA para mantener sus negocios funcionando. Considerando como ejemplo una empresa con una
importante presencia en el e-comercio.
Para este negocio, la infraestructura de IT que soporta el sistema que los clientes se encuentran, el núcleo
del motor del e-comercio, debe ser altamente disponible y a prueba de desastre. La empresa puede
considerar la clusterización de los servidores web, servidores de aplicaciones y los servidores de base de
datos haciendo la función de este motor del e-comercio. Con la redundancia incorporada y soluciones
agrupadas eliminamos puntos de fallo individuales. Además, las modernas soluciones de agrupamiento son
de aplicación transparente, para proporcionar la escalabilidad futura de crecimiento del negocio, y poder
proporcionar un balanceo de carga para manejar el tráfico pesado. Así, por ejemplo, las soluciones basadas
en clúster son ideales para la misión crítica de las aplicaciones con un alto nivel de transacciones. Los datos
que soportan el alto volumen de transacciones del e-comercio deben ser protegidos de manera adecuada y
estar disponible con el mínimo tiempo de caída tanto planificado como no planificado, si se producen
interrupciones.

22
Estos datos no sólo deben estar respaldados cada cierto tiempo en los centros de datos locales, sino que
también deben ser replicados a las bases de datos en un centro de datos remoto conectado a alta
velocidad a una red redundante. Este centro remoto de datos debe estar equipado con servidores
secundarios y bases de datos rápidamente disponibles, y serán sincronizados con los servidores
principales y bases de datos. Esto da a las empresas la capacidad para cambiar estos servidores en el
momento de la ocurrencia con el mínimo tiempo de inactividad si hay un fallo en el sistema, en vez de
esperar durante horas y días para reconstruir y recuperar los datos de los servidores de copia de
seguridad de cintas.
El mantenimiento sincronizado de los centros de datos remotos es un ejemplo donde la redundancia se
construye a lo largo de toda la infraestructura del sistema. Esto puede ser caro, sin embargo, la
naturaleza de la misión crítica de los sistemas y los datos que protege pueden justificar este gasto.
Teniendo en cuenta otro aspecto del negocio: por ejemplo, los requisitos de la alta disponibilidad que
son menos estrictos para los sistemas que recogen datos de clics y realizar los estudios de rendimiento
de las aplicaciones. El coste de la inactividad es baja, y los requisitos del RTO y RPO de este sistema
podría ser de unos pocos días, porque aunque este sistema esté caído y algunos datos se pierden, no
tendrá un efecto perjudicial en la empresa. Si bien la empresa puede necesitar de máquinas potentes
para realizar el estudio estadístico de rendimiento de los datos, no es necesario mostrar estos datos en
tiempo real. La protección de datos se puede obtener simplemente realizando periódicamente copias de
seguridad programadas, y archivando las cintas fuera del sitio de almacenamiento.

23
 Para este negocio de e-comercio, en la fase final de comercialización y los sistemas
de inventario se espera que tengan una mayor cantidad de requisitos de HA que los
estudios de rendimiento de datos de los sistemas, por lo que pueden utilizar técnicas
como el duplicado instantáneo o mediante espejo de los datos, además de copias de
seguridad programadas y el archivado en otro lugar.
 La empresa debe emplear una infraestructura de gestión global que realizan los
sistemas de gestión, administración y supervisión. Esta infraestructura de gestión
debe ser de alta disponibilidad y tolerante a fallos. Por último, la infraestructura de IT
para este negocio de e-comercio debería ser extremadamente segura, para proteger
contra los ataques internos y externos de piratas informáticos.

24
 Las soluciones de alta disponibilidad también deben ser elegidas teniendo en cuenta
problemas de rendimiento de negocio. Por ejemplo, una empresa puede utilizar una
solución de “cero perdidas de datos” que sincrónicamente respalde cada transacción
sobre la base de datos principal a una base de datos remota. Sin embargo,
considerando las limitaciones de la velocidad de la red y las propias limitaciones
físicas relacionadas con la red, los retrasos en la transmisión en la red serán de ida y
vuelta. Este retraso aumenta con la distancia, y varía según el ancho de banda de red,
la congestión del tráfico, las latencias del router, y así sucesivamente. Así pues, esta
copia en espejo sincrónico, si se realiza en grandes distancias de la WAN, puede
afectar el rendimiento del sitio principal. Los compradores online pueden notar estas
latencias del sistema y se pueden sentir frustrados con los largos tiempos de respuesta
del sistema, y ellos pueden ir a cualquier otro sitio a realizar sus compras. Este es un
ejemplo donde la empresa debe hacer un equilibrio entre tener una solución de cero
pérdida de datos y maximizar el rendimiento del sistema.

25
 Las soluciones de alta disponibilidad también deben ser elegidas teniendo en cuenta las
consideraciones financieras y estimaciones de crecimiento futuro. Es tentador el pensar en
aplicar la redundancia de datos en toda la infraestructura de IT y la afirmación de que la
infraestructura es completamente a prueba de fallos. Sin embargo, abordarlo con este tipo
de soluciones no sólo puede dar lugar a excesos de presupuesto, sino que puede conducir a
una incontrolable e inaplicable combinación de soluciones que son extremadamente
complejas y costosas para integrar y mantener.
 Una solución de HA que da muy buenos resultados de rendimiento puede parecer muy
buena sobre el papel. Sin embargo, si se hace una inversión en una solución de este tipo
sin un análisis cuidadoso de la forma en que la capacidad tecnológica está unida con el
negocio, entonces la empresa puede terminar con una solución que no se integre bien con
el resto de su infraestructura del sistema, teniendo integración anual y los gastos de
mantenimiento que fácilmente superan el coste previsto para las licencias, y se puede
producir un endeudamiento con los proveedores. La previsión de costes y la propia
experiencia de la empresa debe servir para invertir sólo en las soluciones que están bien
integradas, basadas en estándares, fácil de implementar, mantener y administrar, y tener
una arquitectura escalable para acoger el futuro crecimiento del negocio.

26
 La elección e implementación de la arquitectura que mejor se adapte a los
requisitos de disponibilidad que requiere un negocio puede ser una tarea bastante
compleja. Esta arquitectura debe abarcar una redundancia adecuada,
proporcionar una protección adecuada de todos los tipos de caídas, garantizar la
coherencia de alto rendimiento y una seguridad robusta, sin dejar de ser fácil de
implementar, administrar y escalar. No hace falta decir, que esta arquitectura
debe ser diseñada por una persona que comprenda y entienda correctamente
todos los requisitos del negocio.
 Para construir, implementar y mantener este tipo de arquitectura, una empresa
necesita las mejores prácticas de alta disponibilidad, que involucran los aspectos
técnicos y operativos de sus sistemas de IT y los procesos de negocio. Esta serie
de buenas prácticas elimina la complejidad de diseñar una arquitectura HA,
maximiza la disponibilidad durante el uso de recursos mínimos del sistema,
reduce la implementación y los costes de mantenimiento de los sistemas de HA,
y hace que sea fácil duplicar la arquitectura de alta disponibilidad en otras áreas
de la empresa.

27
Las arquitecturas de máxima disponibilidad (MAA) ofrecen una protección de datos y la
disponibilidad de minimizar o eliminar los riesgos planificados y no planificados de caída del
sistema en todos los niveles, incluyendo los componentes tanto software como hardware. La
protección de datos y la alta disponibilidad alcanzan cualquier tipo de fallo independientemente,
ya sea el fallo por el entorno de una aplicación, o se trate de fallos de hardware que causa la
corrupción de datos, o incluso de actos de naturaleza catastrófica que afectan a una amplia zona
del sistema.
Cuando hablamos de arquitecturas de máxima disponibilidad, nos estamos refiriendo a lo mismo
que si nos referimos al término “Disaster Recovery” (en castellano, Recuperación de Desastres),
que es el proceso, las políticas y procedimientos relacionados con la preparación para la
recuperación o el mantenimiento de la infraestructura de la tecnología esencial para una
organización después de un desastre natural o inducido por el hombre.
La planificación de la recuperación de desastres es un subconjunto de un proceso más amplio
conocido como la planificación continua de las actividades y debe incluir la planificación de la
reanudación de las aplicaciones, datos, hardware, comunicaciones (como el establecimiento de
redes) y otras infraestructuras de TI. Un plan de continuidad del negocio (BCP) incluye la
planificación de las infraestructura no-IT, tales como los aspectos relacionados con la claves
personales, los servicios, la comunicación de la crisis y la reputación de dicha protección, y se
debe referir al plan de recuperación de desastres (DRP) para la infraestructura de TI basado en
la recuperación y continuidad.

28
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.
Desastres producidos por el hombre: Estos desastres son
los principales motivos de fracaso. El 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.

29
 Identificar el alcance y límites del plan de continuidad. El primer paso es definir el alcance de
BCP. En él se ofrece una idea de las limitaciones y los límites del plan. También incluye la
auditoría y los informes de análisis de riesgos para los activos de la institución.
 Realizar un análisis del impacto de negocio (BIA, del inglés Business Impact Analysis).
Análisis del impacto de negocio es el estudio y evaluación de las pérdidas financieras de la
entidad resultante de algún problema importante como la no disponibilidad de los servicios
empresariales.
 Vender el concepto de BCP a la administración superior de la organización y obtener el
compromiso financiero y de apoyo de dicha organización. Convencer a los altos directivos a
aprobar DRP es una tarea fundamental. Es muy importante para la seguridad profesional obtener
la aprobación de un plan de la gestión superior a fin de ponerla al efecto.
 Cada departamento tendrá que comprender su función en el plan de apoyo y que se
mantenga en él. En caso de desastre, cada departamento tiene que estar preparado para la acción.
Para recuperar y proteger los sistemas críticos de cada departamento tiene que entender que el
plan sigue en consecuencia con lo acordado. También es importante mantener y ayudar en la
creación del plan individual para cada departamento.
 El equipo de proyecto de BCP debe aplicar el plan. Después de la aprobación del plan de la
gestión superior debe mantenerse y aplicarse. El equipo de implementación debe seguir las
directrices en el plan de los procedimientos.
 La herramienta NIST puede utilizarse para hacer BCP. National Institute of Standards and
Technologies ha publicado recientemente herramientas que pueden ayudar en la creación de BCP.

30
Las medidas de control son las medidas o mecanismos que puedan reducir o
eliminar las amenazas a la seguridad de ordenador. Los diferentes tipos de
medidas pueden ser incluidos en DRP. Los tipos de medidas son los siguientes:

 Medidas preventivas: Estos controles tienen por objetivo la

prevención de un acontecimiento se produzca.
 Medidas de detección: Estos controles tienen por objeto la
detección o el descubrimiento de los eventos no deseados.
 Medidas correctoras: Estos controles tienen por objetivo corregir o
restaurar el sistema después de un desastre o evento.

Estos controles deben estar siempre documentados y probados periódicamente.

31
Antes de seleccionar una estrategia de recuperación de desastres, un plan de
recuperación de desastres debe referirse a su plan de continuidad de negocio de la
empresa, el cual deberá indicar la cantidad de punto de recuperación objetivo (RPO) y
tiempo de recuperación objetivo (RTO) para los diversos procesos de negocio. La
evolución de las cifras previstas para los procesos de negocio deben ser asignados a
los sistemas de TI e infraestructuras que apoyen esos procesos.

Una vez que la medida de RTO y RPO se han asignado a la infraestructura de TI, el
proyecto de resolución puede determinar el plan más adecuado para cada estrategia de
recuperación del sistema. Una nota importante aquí es que la empresa en última
instancia, fija el presupuesto de TI y, por tanto, la medida de RTO y RPO necesita
ajustarse con el presupuesto disponible. Si bien la mayoría de los jefes de unidad de
negocio, le gustaría tener cero pérdida de datos y cero pérdida de tiempo, el coste
asociado con este nivel de protección puede hacer que en la práctica opte por otras
soluciones de alta disponibilidad. A continuación vamos a mostrar una lista de las
estrategias más comunes para la protección de datos.

32
  Copias de seguridad a cinta y enviadas a otro sitio de respaldo de forma periódica
(preferentemente a diario).
 Copias de seguridad a disco en el sitio y automáticamente copiado al disco del sitio de respaldo, o
directamente al disco del sitio de respaldo.
 Replicación de datos a una ubicación fuera de sitio, lo que supera la necesidad de restaurar los
datos (sólo los sistemas que necesiten ser restauradas o sincronizados). Esto generalmente hace
uso de la red de área de almacenamiento (SAN).
 Los sistemas de alta disponibilidad en los cuales se mantienen los mismos datos y se copian al
sistema de replicación fuera de sitio, permiten un acceso continuo a los sistemas y los datos.

 En muchos casos, una organización puede recurrir a un proveedor de contratación externa de recuperación de
desastres para proporcionar un sitio de sistema de respaldo, en lugar de utilizar sus propias instalaciones
remotas. Además de la preparación de la necesidad de recuperar los sistemas, las organizaciones también
deben implementar medidas cautelares con el objetivo de prevenir un desastre en primer lugar. A continuación
mostramos una serie de las medidas más comunes:

 Copias locales sincronizadas de los sistemas y/o datos y el uso de la tecnología de protección de
disco, como RAID
 Protectores de tensión, para reducir al mínimo el efecto de los aumentos repentinos de energía en
los equipos electrónicos delicados
 Sistema de alimentación ininterrumpida (UPS) y/o generador para mantener los sistemas en caso
de un fallo de alimentación
 Prevención de incendios - alarmas, extintores de incendios
 Software anti-virus y otras medidas de seguridad

33
 Esta imagen representa un esquema completo de un sistema de máxima disponibilidad, viendo el sitio principal en alta
disponibilidad, y el sitio de respaldo del sistema, sin alta disponibilidad, que en conjunto crea un sistema de máxima disponibilidad

34
 Las interrupciones en el transcurso normal de las
aplicaciones que soporta un sistema es lo que ha
llevado al estudio de la alta o máxima
disponibilidad. Más concretamente nos referimos al
servicio de datos, que es un determinado servicio de
un sistema y todos los recursos necesarios que
conlleva para poder dar soporte al cliente que está
reclamando la aplicación en ese momento.
 Los grupos de recursos tienen que tener claramente
implementados los algoritmos necesarios, para que
en el momento que un nodo deje de dar servicio,
sea cambiado fácilmente por cualquier otro nodo
del clúster, sin que el sistema deje de dar servicio,
que es el objetivo fundamental. Es decir, todos los
nodos del cluster tienen que estar completamente
preparados para realizar su tarea en cualquier
momento.
 El software dedicado a la alta disponibilidad, lo que
debe hacer es abstraer el clúster y trabajar como si
se tratase de una única entidad capaz de realizar
todas estas tareas.

35
El principio básico de la alta disponibilidad es la replicación de los elementos. Cuando
denominamos alguno de estos elementos como SPOF, nos estamos refiriendo a los
elementos que no están replicados y por los que un determinado fallo en ellos, puede
desencadenar un fallo del sistema completo. Para ello debemos evitar el SPOF en
cualquier subsistema, para asegurar completamente la estabilidad del sistema completo.
Vamos a verlo más claramente explicando un ejemplo. Si tenemos un clúster formado
por dos servidores, y uno de los dos falla, y el otro no es capaz de levantar el servicio
completamente y continuar con su ejecución en el tiempo que se tenga planeado, dicho
servidor se convierte en un SPOF.
En la alta disponibilidad lo primordial que tenemos que intentar evitar es la ocurrencia
de SPOF's, por lo tanto, en la alta disponibilidad se replican todos los elementos del
sistema, pero no nos referimos solo a servidores, discos de almacenamiento, etc. sino
también a los routers encargados de dar soporte de red, la propia red local, es decir
cualquier elemento que por un fallo suyo pueda detener el sistema.
Pero claro, la replicación de todos los niveles del sistema conlleva un gran desembolso
económico, por lo cual debemos encontrar el equilibrio justo en la redundancia de
elementos, adecuada con nuestros intereses del sistema.

36
 El término dinámica en la HA hace referencia a todas las posibles configuraciones del clúster para
garantizar la máxima disponibilidad en el servicio de datos. A continuación vamos a ver todas las posibles
configuraciones y la manera de trabajar de cada uno de los nodos que componen el clúster, es decir vamos a
ver las posibles dinámicas utilizadas en la alta disponibilidad:

Failover
 Failover es la capacidad de cambiar automáticamente de un nodo a otro de los que componen el
clúster. Esto es debido a un fallo, humano o no, en el nodo principal que está proporcionando servicio.
El cluster automáticamente debe cambiar todos los recursos del nodo principal hacia otro nodo
secundario y continuar dando servicio. Debemos comprender que la alta disponibilidad está diseñada
para soportar estos tipos de fallos, por lo tanto cambiará de nodo sin dejar de dar servicio al usuario,
que es el principal objetivo.
 En el caso de que hayan fallado todos los nodos del clúster y solo queda uno funcionando estaremos en
una situación de SPOF. Esta situación de SPOF se soluciona mediante la intervención del
administrador del sistema, el cual repara el nodo o nodos dañado devolviendo la alta disponibilidad al
sistema.
Takeover
 Para que nos entendamos, un takeover es un failover automático, es decir, la migración de un nodo a
otro se produce cuando se prevé que va a ocurrir un fallo en el nodo principal que está proporcionando
servicio. Por lo tanto, en el takeover no se espera a que se produzca el fallo, sino que antes de ocurra se
migra de un nodo a otro, y se procede a restaurar o eliminar el nodo que va a producir el fallo.
 Tenemos que indicar que para que sea posible el takeover debe haber en el sistema una monitorización
del servicio de los datos, ya que haciendo uso de la herramienta de monitorización es la única manera
de poder prever un fallo, mediante el aviso del propio sistema de monitorización.

37
 Splitbrain
 Primeramente, tenemos que quedar claro que lógicamente para que un clúster funcione correctamente debe
tener un sistema de comunicación entre los nodos. Es decir, todos los nodos pertenecientes al clúster
continuamente se están mandando mensajes unos a otros para saber el estado del resto de los nodos, para
proceder en cualquier momento determinado a la migración de un nodo a otro. Sin el envío de estos
mensajes la migración no sería posible ya que cuando falla el nodo principal, los demás nodos no tendrían
constancia de que el nodo principal ha caído y ninguno ocuparía su lugar.
 Los mensajes mandados entre los nodos normalmente son del tipo "estoy vivo", en un intervalo de "x"
tiempo. Como vemos no son mensajes complicados, pero simplemente con este mensaje es suficiente para
saber que si en "x" tiempo un nodo no ha recibido mensaje de otro nodo, significa que dicho nodo está
caído, y se procede a su migración.
 La situación de splitbrain se produce cuando cada uno de los nodos del clúster cree que el otro nodo está
muerto (caído, sin poder dar servicio), y proceden a hacerse cargo de los recursos como si el otro/otros
nodo/nodos no tuviesen propiedad sobre los recursos. Por lo tanto se produce un conflicto por parte de
todos los nodos en la adiquisición de los recursos y la disposición a dar servicio.
 Para solucionar esta situación se hace uso de un quorum, que no es más que un "testigo" que se incluye en
los recursos compartidos. Lo que significa que en este conflicto entre nodos, el único que podrá hacerse
cargo del recurso será el que tenga el quorum. El quorum de un recurso se consigue simplemente llegando
el primero a ese recurso compartido y comenzando a dar servicio. Por lo tanto, los demás nodos cuando
lleguen al recurso compartido, comprobarán que no pueden adjudicarse el quorum y no podrán hacerse
cargo de dicho recurso, solucionando así el conflicto entre los nodos.
 Esta situación debe ser solucionada por el administrador del sistema para evitar posibles fallos o
consecuencias peores.

38
Linux al igual que los demás sistemas operetivos no podía quedarse atrás en lo que a Alta
Disponibilidad se refiere. Por eso nació Linux-HA, que se trata de un sistema de clustering de
Alta Disponibilidad libre, es decir que no es software propietario.
Este proyecto comenzó en torno al 1998, por lo que podemos decir que no es un novato en la
Alta Disponibilidad, mas de 10 años de logros lo abalan. Durante estos diez años ha
conseguido introducir alrededor de unos 30.000 cluster en funcionamiento, por lo que está
bastante extendido. Y además cuenta con el apoyo total de una comunidad de desarrollo
abierta, dispuesta a mejorarlo cada día.
Otro de los puntos más atractivos de Linux-HA es que está disponible para la gran mayoría de
distribuciones de Linux, sin que necesitemos un Hardware especial.

Sistemas de computación
En la actualidad Linux es una plataforma consolidad tanto en computación como
en supercomputación. Si afrontásemos la idea de eliminar SPOF en los sistemas de
computación, solo se podría hacer al nivel de Linux como sistema operativo. Lo que
queremos decir con esto es que Linux es eficiente en cuanto a la computación a nivel
de nodos y superiores, pero si consideramos a nivel de procesadores y memorias se
trata de un problema cercano a una solución hardware tolerante a fallos.

39
 Sistemas de red
Una de las grandes ventajas de Linux es que cuenta con unas de las pilas de TCP/IP
mas completas y estables que existen en la actualidad. Una de las funciones que le
hacen diferente al resto es que IP Aliasing de Linux contiene la característica de
asignar varias IP's a una misma interfaz, por lo que podemos levantar una dirección
IP exclusiva en un nodo clúster. Y si algún nodo slave del cluster aparece con esa
IP puede tomar el testigo de ese nodo.
A su vez Linux está capacitado para actualizar las tablas de ruta dinámicamente,
gracias a demonios de enrutamiento como es el caso del OSPF. Estos servicios
permiten que el clúster pueda ser consciente de la topología de la red y reaccionar
ante caidas de línea o de nodos.

Sistemas de almacenamiento
Los dos grandes problemas existente en los sistemas de almacenamiento son los
siguientes:
SPOF en los elementos de almacenamiento. Se soluciona con sistemas de discos para
poder hacer redundancia en los datos, y la posibilidad de que cuando falle un disco por
cualquier motivo se cambie por otro que este reservado.

Consistencia ante un crash o caída. Para ello se comprueba la integridad de todo el

conjunto de datos. La recuperación y consistencia de los datos debe ser recuperada en el
mínimo tiempo posible, ya que la estabilidad del sistema depende de ello.

40
 Sistemas de red
Una de las grandes ventajas de Linux es que cuenta con unas de las pilas de TCP/IP
mas completas y estables que existen en la actualidad. Una de las funciones que le
hacen diferente al resto es que IP Aliasing de Linux contiene la característica de
asignar varias IP's a una misma interfaz, por lo que podemos levantar una dirección
IP exclusiva en un nodo clúster. Y si algún nodo slave del cluster aparece con esa
IP puede tomar el testigo de ese nodo.
A su vez Linux está capacitado para actualizar las tablas de ruta dinámicamente,
gracias a demonios de enrutamiento como es el caso del OSPF. Estos servicios
permiten que el clúster pueda ser consciente de la topología de la red y reaccionar
ante caidas de línea o de nodos.

Sistemas de almacenamiento
Los dos grandes problemas existente en los sistemas de almacenamiento son los
siguientes:
SPOF en los elementos de almacenamiento. Se soluciona con sistemas de discos para
poder hacer redundancia en los datos, y la posibilidad de que cuando falle un disco por
cualquier motivo se cambie por otro que este reservado.

Consistencia ante un crash o caída. Para ello se comprueba la integridad de todo el

conjunto de datos. La recuperación y consistencia de los datos debe ser recuperada en el
mínimo tiempo posible, ya que la estabilidad del sistema depende de ello.

41
Sistemas de disco

Redundant Array of Independent Disks (RAID)

El subsistema RAID es el más utilizado en la actualidad para la
consistencia de los datos almacenados en los discos. Este
método es capaz de eliminar el SPOF de los recursos de
almacenamiento. A día de hoy los RAID soportados por el
Kernel de los Linux principales son el RAID 0, RAID 1 y
RAID 5.
Por otro lado gracias a la gran colaboración de Compaq e IBM
en la creación de drivers ha permitido que también soporte
gran numero de controladoras SCSI y ATA100 que ofrecen
volúmenes de RAID por hardware.

Logical Volume Management (LVM)

IBM fue el primero en adoptar el Logical Volume Management
y mas tarde fue OSF. Este software de gestión de volúmenes
permite exportar los tamaños de grupos de discos para que el
servicio de datos pueda usarlo. El LVM continua en desarrollo
y además es capaz de cambiar el tamaño de sistemas de
ficheros tales como Ext2.

42
Sistemas de ficheros con journal o con registro por diario

Los sistemas de ficheros con journal o con registro por diario nacieron gracias a las bases
de datos. Esta técnica fue desarrollada para servidores de alto rendimiento y servidores de
archivos de altas prestaciones, asociados a e-business. Lo que el journaling consigue es que
cuando un sistema sufre una caída, los bloques lógicos que hallan sido dañados quedan
marcados, por lo que a la hora de chequear solo se comprueban las inconsistencias de
dichos bloques.
Este sistema también es muy eficiente en la administración de directorios, ya que para
ficheros pequeños es capaz de guardar la información en el mismo inodo. Y para directorios
más grandes utiliza árboles B y tablas Hash.
A continuación se enumeran los sistemas de ficheros con journal mas importantes para la
HA en Linux:
« Ext3: Es el clásico Ext2 pero con el añadido de
una partición de log, para llevar el registro por
diario. La característica más importante del Ext3
es que hace journal a distintos niveles tanto de los
datos y como de los metadatos. Es algo mas lento
que el Ext2. »
Juan Paredes. HA para Linux (2007).

43
Sistemas de ficheros con journal o con registro por diario

« Reiserfs: Es un sistema de ficheros creado desde 0 con la idea de sacar partido a arboles B, hashes y
técnicas de journal actuales. Es un sistema de ficheros realmente rápido en lo que a Linux se refiere. Sólo
hace journaling de datos. Actualmente sus creadores están desarrollando Reiser4 bajo el patrocinio de la
DARPA.» Juan Paredes. HA para Linux (2007)

« JFS: IBM lo ha puesto bajo GPL y ha sacado su primera versión con calidad de producción. De momento
desarrollan con bastante independencia, de versiones actuales del kernel, ya que sacan parches para
versiones especificas.» Juan Paredes. HA para Linux (2007)

« XFS: Silicon ha sacado releases con calidad de producción bajo GPL. Casi tan rápido como reiserfs. Esta
muy bien integrado con Linux, teniendo en consideración otros subsistemas como puede ser quota o NFS.
Sacan parches cada una o dos versiones del kernel. Una opción muy a considerar, en un futuro.» Juan
Paredes. HA para Linux (2007)

44
Linux como sistema operativo muy estable y competente ha decidido estar a la vanguardia de las
soluciones de alta disponibilidad existentes en el mercado. Han sido muchos las investigaciones
realizadas y los proyectos que se han ido creando para poder solucionar esta problemática y así hacer
frente a los sistemas comerciales.
Para terminar con la exposición de HA sobre Linux vamos a ver las soluciones más actuales y que
mejor rendimiento generan bajo este sistema operativo. Hay que recordar que todas estas soluciones
están siendo posible gracias a la colaboriación de las distintas distrubuciones existentes hoy en día,
destacando el trabajo realizado por VA , SuSE, Red Hat, Conectiva o Debian.

Heartbeat
Heartbeat es uno de los mayores impulsores del proyecto Linux-HA (Linux Hight Avialability). Sus
características fundamentales son su gran portabilidad ya que funciona sobre diferentes plataformas
UNIX y una eficiente comunicación, detección y gestión de los nodos. El funcionamiento de la
comunicación entre los nodos es por medio de un sistema de latidos para que los nodos sepan si los
demás están activos, debido a este sistema se le bautizó como heartbeat.

IPVS (IP Virtual Server)

El IPVS viene incluido de serie en las últimas versiones del kernel de Linux. Es configurable por
comandos, ya que carece de interfaz gráfica. Propone una solución de balanceo de carga a nivel de
capa dentro del Kernel. Sus principales características son el soporte tanto de protocolos UDP como
de TCP y de los múltiples algoritmos que es capaz de utilizar para calcular el balanceo de carga.

45
 Pirahna
La distribución Red Hat también aportó su granito de arena con esta solución para la HA. Este
está basado en LVS y viene con interfaz para poder configurarlo.

UltraMonkey
Al igual que Red Hat, VA lanzó una solución basada en LVS y Heartbeat para ofrecer cluster
de HA y con balanceo de carga. Incorpora una interfaz para poder configurar el cluster.

Kimberlite
Esta solución fue creada por Mission Critical Linux y se encuentra bajo GPL. Soporta un
cluster de 2 nodos. Es fácil de utilizar y configurar.

46
 Monográfico MEC sobre virtualización:
http://recursostic.educacion.es/observatorio/web/es/software/software-general/462-monografico-maquinas-virtuales
 Descripción de cluster de alta disponibilidad
http://www.lintips.com/?q=node/119
 Información práctica sobre RAID, dispone de un enlace a un emulador del funcionamiento de sistemas RAID
de Intel:
http://www.adminso.es/wiki/index.php/2.3.2._Configuraciones_RAID
 Configuración de cluster de alta disponibilidad bajo Windows Server
http://www.bujarra.com/?p=2290
 Configuración de cluster de alta disponibilidad bajo GNU/Linux:
http://www.alcancelibre.org/staticpages/index.php/como-cluster-heartbeat-centos
 Descubre e implementa alta disponibilidad y balanceo de carga en un servidor web mediante Apache y
Tomcat con la ayuda del siguiente artículo:
http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=apache_tomcat_balanceo
 Configuración de red de VirtualBox:
http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=VirtualBox
 El blog de la virtualización:
http://feeds.feedburner.com/ElBlogDeVirtualizacionEnEspanol
 Libros sobre clustering y alta disponibilidad:
http://asiermarques.com/2007/05/20/libros-sobre-clustering-y-alta-disponibilidad/
 Curso abierto de virtualización y servidores:
http://www.josedomingo.org/web/course/view.php?id=43
 Wikipedia, Alta Disponibilidad,
http://es.wikipedia.org/wiki/Alta_disponibilidad
 Alta Disponibilidad en Linux
http://www.ibiblio.org/pub/linux/docs/LuCaS/Presentaciones/200103hispalinux/paredes/pdf/LinuxHA.pdf
 Wikipedia, Cluster de Alta Disponibilidad,
http://es.wikipedia.org/wiki/Cluster_de_alta_disponibilidad
 Clustering de Alta Disponibilidad en GNU/LINUX
http://www.glisa.es/archivos/documentacion/2008/gnulinux_software_libre_para_la_comunidad_universitaria/09-clustering.pdf
 Software de virtualización VMWare:
 www.vmware.com/es/
 Software de virtualización Virtual Box de Oracle:
 http://www.virtualbox.org/
 Software de virtualización Virtual PC de Microsoft:
 http://www.microsoft.com/windows/virtual-pc/
 Kerio Winroute firewall: gestión integral bajo
Windows, con funciones de enrutamiento y
cortafuegos.
 http://www.kerio.com/
 FreeNAS: Servidor NAS de distribución libre:
 www.freenas.org