Embed Size (px)
Citation preview
“AÑO DE LA INVERSIÓN PARA EL DESARROLLO RURAL Y LA SEGURIDAD ALIMENTARIA”
UNIVERSIDAD PERUANA LOS ANDES
FACULTAD DE INGENIERÍA CARRERA PROFESIONAL DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN
DESPLIEGUE DE UNA PLATAFORMA VIRTUAL DE
SERVIDORES EN SODIMAC CON RED HAT
ENTERPRISE VIRTUALIZATION (RHEV) EN LA
CUIDAD DE LIMA, SETIEMBRE 2013
INFORME TÉCNICO
PARA OPTAR EL TÍTULO DE:
INGENIERO DE SISTEMAS Y COMPUTACIÓN
PRESENTADO POR:
ROLANDO CÉSAR, PALACIOS MAYTA
HUANCAYO - PERÚ
2013
I
Dedicatoria
A Dios, por su infinito amor, su
cuidado la fuerza y voluntad que
me brinda para continuar en el
cumplimiento de mis objetivos.
A mi madre por ser la motivación
de mi vida. A mifamilia por sus
consejos y apoyo moral.
César Palacios Mayta
II
INDICE
DEDICATORIA……………………………………………………………………………………………I
INDICE ....................................................................................................................................... II
RESUMEN .............................................................................................................................. VIII
INTRODUCCIÓN ....................................................................................................................... X
1.1. DEFINICION DEL PROBLEMA ...................................................................................11
1.1.1. PROBLEMA GENERAL .......................................................................................12
1.1.2. PROBLEMA ESPECIFICO ...................................................................................12
1.2. JUSTIFICACIÓN .........................................................................................................12
1.3. HIPOTESIS .................................................................................................................13
1.4. OBJETIVOS ................................................................................................................13
1.4.1. OBJETIVO GENERAL .........................................................................................13
1.4.2. OBJETIVOS ESPECIFICOS ................................................................................13
1.5. VARIABLES ................................................................................................................14
1.5.1. VARIABLE DEPENDIENTE: ................................................................................14
1.5.2. VARIABLE INDEPENDIENTE: .............................................................................14
1.6. LIMITACIONES DE LA INVESTIGACIÓN ...................................................................14
1.7. METODOLOGÍA..........................................................................................................15
1.8. PLANTEAMIENTO DE LA SOLUCIÓN .......................................................................15
1.9. CRONOGRAMA DE TRABAJO ...................................................................................16
2.1. VIRTUALIZACIÓN .......................................................................................................17
2.1.1. VIRTUALIZACIÓN DE PLATAFORMA .................................................................18
2.1.2. VENTAJAS DE LA VIRTUALIZACIÓN .................................................................22
2.1.3. COMPATIBILIDAD ...............................................................................................24
2.1.4. ENCAPSULAMIENTO ..........................................................................................24
2.1.5. VIRTUALIZACIÓN DE SERVIDORES ..................................................................25
2.2. SERVIDORES .............................................................................................................26
2.3. RED HAT ENTERPRISE VIRTUALIZATION PARA SERVIDORES ............................28
2.3.1 MÁQUINA VIRTUAL (KVM) .................................................................................31
2.3.2 QEMU ..................................................................................................................33
2.3.3 RED HAT ENTERPRISE VIRTUALIZATION MANAGER HOST AGENT, VDSM .34
2.3.4 LIBVIRT ...............................................................................................................34
III
2.3.5 POOL STORAGE MANAGER (SPM) ...................................................................35
2.3.6 SISTEMA OPERATIVO INVITADO ......................................................................35
2.3.7 ARQUITECTURA DE RED HAT ENTERPRISE VIRTUALIZATION .....................36
2.3.8 COMPONENTES DEL SISTEMA .........................................................................38
2.3.9 RECURSOS .........................................................................................................39
2.3.10 RED HAT ENTERPRISE VIRTUALIZATION ARQUITECTURA ...........................42
2.3.11 CARACTERÍSTICAS Y BENEFICIOS ..................................................................48
2.3.12 STORAGE............................................................................................................49
2.5. STORAGE ...................................................................................................................52
2.5.1. CENTRO DE DATOS (DATA CENTER) ...............................................................52
2.5.2. DOMINIOS DE ALMACENAMIENTO (Storage Domains Overview) .....................53
2.5.3. TIPOS DE DOMINIO DE ALMACENAMIENTO ....................................................54
2.5.4. TIPOS DE DOMINIO DE STORAGE ....................................................................56
2.5.5. FORMATOS DE ALMACENAMIENTO DE MÁQUINA VIRTUAL DE IMÁGENES
DE DISCO ..........................................................................................................................58
2.5.6. IMAGEN DE DISCO POLÍTICAS DE ASIGNACIÓN DE ALMACENAMIENTO DE
MÁQUINA VIRTUAL ...........................................................................................................60
2.5.7. STORAGE DOMAIN AUTORECOVERY EN RED HAT ENTERPRISE
VIRTUALIZATION ..............................................................................................................61
2.5.8. GESTOR DE AGRUPACIONES DE ALMACENAMIENTO ...................................62
2.5.9. SNAPSHOT .........................................................................................................65
2.5.10. SNAPSHOTS EN VIVO EN RED HAT ENTERPRISE VIRTUALIZATION .........67
2.5.11. CREACIÓN DE SNAPSHOT ............................................................................69
2.5.12. SNAPSHOT PREVIAS ......................................................................................71
2.5.13. ELIMINACIÓN DE SNAPSHOTS ......................................................................72
2.6. CLUSTER ...................................................................................................................74
2.6.1. CLUSTER DE ALTA DISPONIBILIDAD ...............................................................77
2.7. METODOLOGIA DE GESTION DE PROYECTOS ......................................................89
2.7.1. FASE DE INICIO Y PLANIFICACIÓN ...................................................................89
2.7.2. FASE DE EJECUCIÓN Y CONTROL ...................................................................90
2.7.3. FASE DE CIERRE DE PROYECTO .....................................................................90
3.1. DEFINICION ...............................................................................................................91
4.1. NOMBRE DE LA EMPRESA .......................................................................................96
4.2. NOMBRE DEL PROYECTO ........................................................................................96
IV
4.3. INTRODUCCIÓN ........................................................................................................96
4.4. ACTA DE CONSTITUCION DEL PROYECTO ............................................................97
4.4.1. DESCRIPCIÓN DEL PROYECTO ........................................................................97
4.4.2. DIRECTOR DEL PROYECTO ASIGNADO Y NIVEL DE AUTORIDAD ................98
4.4.3. CASO DE NEGOCIO ...........................................................................................98
4.4.4. RECURSOS PRE-ASIGNADOS ..........................................................................99
4.4.5. INTERESADOS ...................................................................................................99
4.4.6. DESCRIPCION DEL PRODUCTO/SERVICIO ................................................... 100
4.4.7. OBJETIVOS MEDIBLES DEL PROYECTO........................................................ 101
4.4.8. REQUISITOS DE APROBACIÓN DEL PROYECTO .......................................... 104
4.5. ALCANCE ................................................................................................................. 104
4.5.1. LISTA DE REQUISITOS .................................................................................... 104
4.5.2. ESTRUCUTRA DE DESGLOSE DE TRABAJO (EDT) ....................................... 106
4.6. EJECUCION DEL PROYECTO ................................................................................. 108
4.6.1. ESPECIFICACIONES DE SERVIDORES .......................................................... 108
4.6.2. ESPECIFICACIONES DE LOS SERVICIOS ...................................................... 111
4.6.3. INSTALACION ................................................................................................... 112
4.7. INSTALACIÓN DE PRE-REQUISITOS EN EL SERVIDOR RHEL 6 PARA EL
SERVICIO RHEV-MANAGER .............................................................................................. 127
4.8. INSTALACIÓN DEL SERVICIO MANAGER SOBRE RHEL 6 ................................... 130
4.9. INSTALACIÓN DEL SERVICIO GLUSTERFS .......................................................... 132
4.10. CONFIGURACIÓN DEL STORAGE A TRAVÉS DEL SERVIDOR RHEV-MANAGER
……………………………………………………………………………………………...139
4.11. CREACIÓN DE UN DOMINIO DE EXPORTACIÓN ............................................... 146
4.12. CONTROL DE CALIDAD (HISTOGRAMA) ............................................................ 149
4.13. CIERRE DEL PROYECTO .................................................................................... 161
Bibliografía .............................................................................................................................. 163
CONCLUSIONES .................................................................................................................... 164
RECOMENDACIONES ........................................................................................................... 165
ANEXO .................................................................................................................................... 166
V
INDICE DE FIGURAS
IMÁGENES CAPITULO I
Imagen N° 1 (Arquitectura de Hypervisores y Almacenamiento)................................................16
IMÁGENES CAPITULO II
Imagen N° 2 (Arquitectura del Hypervisor) ................................................................................30
Imagen N° 3 (interfaz web de administración de Red Hat Enterprise Virtualization Manager) ...31
Imagen N° 4 (Arquitectura de virtualización en Red Hat) ...........................................................38
Imagen N° 5 (Arquitectura de Storage) ......................................................................................51
Imagen N° 6 (Tipos de almacenamiento “Storage”) ...................................................................56
Imagen N° 7 (El grupo de Storage Manager escribe exclusivamente Metadatos estructurales) 65
Imagen N° 8 (Creación de snapshot) .........................................................................................70
Imagen N° 9 (Añadir un Snapshot) ............................................................................................71
Imagen N° 10 (Snapshot) ..........................................................................................................72
Imagen N° 11 (Borrar Snashots) ...............................................................................................74
Imagen N° 12 (Arquitectura Activo / Activo) ...............................................................................80
Imagen N° 13 (Arquitectura Activo / Pasivo) ..............................................................................81
Imagen N° 14 (Recurso y grupo de recursos) ............................................................................83
Imagen N° 15 (migración de servicio) ........................................................................................86
Imagen N° 16 (Canal de comunicación) ....................................................................................89
IMÁGENES CAPITULO IV
Imagen N° 17 EDT .................................................................................................................. 107
Imagen N° 18 (Arquitectura de solución) ................................................................................. 109
Imagen N° 19 (inicio de instalación de Red hat) ...................................................................... 114
Imagen N° 20 (Test del cd de instalación) ............................................................................... 114
Imagen N° 21 (Elegir idioma) ................................................................................................... 115
Imagen N° 22 (Elegir el dispositivo de almacenamiento) ......................................................... 115
Imagen N° 23 Figura 4.7 (Nombre de host) ............................................................................. 116
Imagen N° 24 (Elegir el pais) ................................................................................................... 116
Imagen N° 25 (Añadir de password) ........................................................................................ 117
Imagen N° 26 (Partición personalizada) .................................................................................. 118
Imagen N° 27 (Crear partición) ................................................................................................ 118
Imagen N° 28 (Creando boot) .................................................................................................. 119
Imagen N° 29 (Crear Volumen lógico) ..................................................................................... 119
Imagen N° 30 (Crear Volumen físico) ...................................................................................... 120
Imagen N° 31 (Crear grupo Volumen físico) ............................................................................ 121
Imagen N° 32 Figura 4.16 (Crear Raiz) ................................................................................... 122
Imagen N° 33 (Crear swap) ..................................................................................................... 122
Imagen N° 34 (File System) ..................................................................................................... 123
Imagen N° 35 (Sector de arranque) ......................................................................................... 123
Imagen N° 36 (Seleccionar instalación Mínima) ...................................................................... 124
Imagen N° 37 (Selección de sistema Base) ............................................................................. 124
VI
Imagen N° 38 (Selección de Escritorio) ................................................................................... 125
Imagen N° 39 (Selección de paquete) ..................................................................................... 126
Imagen N° 40 (Instalación en proceso) .................................................................................... 127
Imagen N° 41 (Instalación de Pre-requisitos) .......................................................................... 128
Imagen N° 42 (Subscripción) ................................................................................................... 129
Imagen N° 43 (Creacion de Storage) ....................................................................................... 140
Imagen N° 44 (Creación de Storage) ....................................................................................... 141
Imagen N° 45 (Centro de Datos y Cluster) .............................................................................. 141
Imagen N° 46 (Agregando Hypervisores) ................................................................................ 143
Imagen N° 47 (Configuración de RHEVM) ............................................................................... 143
Imagen N° 48 (Selección de SPM) .......................................................................................... 144
Imagen N° 49 (Selección de SPM) .......................................................................................... 145
Imagen N° 50 (Almacenamiento de máquinas de virtuales) ..................................................... 146
Imagen N° 51 (Creación de dominio de exportación) ............................................................... 148
Imagen N° 52 (Histograma) ..................................................................................................... 149
Imagen N° 53 (Host Caido)...................................................................................................... 150
Imagen N° 54 (Hosts) .............................................................................................................. 151
Imagen N° 55 (Storage Domain).............................................................................................. 151
Imagen N° 56 (Hosts caido) ..................................................................................................... 152
Imagen N° 57 (Proceso de Migración) ..................................................................................... 153
Imagen N° 58 (Hosts levantado) .............................................................................................. 153
Imagen N° 59 (Host Conectado) .............................................................................................. 154
Imagen N° 60 (Hosts) .............................................................................................................. 155
Imagen N° 61 (Storage Domain).............................................................................................. 156
Imagen N° 62 (Reinicio del hosts) ........................................................................................... 156
Imagen N° 63 (Hypervisor activado) ........................................................................................ 157
Imagen N° 64 (Storage Domain).............................................................................................. 157
Imagen N° 65 (Hipervisores) ................................................................................................... 158
Imagen N° 66 (Hypervisores Apagados) .................................................................................. 159
Imagen N° 67 (Hosts Devueltos a Hyperisores A) ................................................................... 159
Imagen N° 68 (Storage Domain Desactivado) ......................................................................... 160
Imagen N° 69 (Hypervisores Activados) .................................................................................. 161
VII
INDICE DE TABLAS
TABLAS CAPITULO IV
Tabla N° 1 (Cronograma de Hitos) .......................................................................................... 103
Tabla N° 2 (Componentes) ...................................................................................................... 108
Tabla N° 3 (Especificaciones de los servidores) ...................................................................... 109
Tabla N° 4 (Particiones de servidores) .................................................................................... 110
Tabla N° 5 (distribución de Memoria) ...................................................................................... 111
Tabla N° 6 (Especificaciones) .................................................................................................. 112
Tabla N° 7 (Requisitos Mínimos) ............................................................................................. 113
Tabla N° 8 (documento de cierre de proyecto) ........................................................................ 162
VIII
RESUMEN
El Tema que se plantea en el seguimiento del informe técnico es la de desplegar una
plataforma virtual con Red Hat Enterprise Virtualization1, este sistema hará posible que
los servidores de tiendas Sodimac puedan ser administrados con la ventaja de tener
alta disponibilidad, logrando que la recuperación de los servidores creados sean
eficaces sin interrumpir el servicio, aplicativos, procesos y que sea flexible ante
cualquier daño físico del servidor principal, muestra también la facilidad de administrar
servidores gracias a una interfaz gráfica que brinda la misma aplicación virtual (RHEV)1,
dividiendo la administración a nivel de usuarios y administrador. Por parte del
Almacenamiento lleva una tecnología Storage con Cluster de Red Hat Enterprise Linux
que cumplirán la función de almacenar las máquinas virtuales.
En el capítulo I se definen las generalidades del presente informe y los objetivos que se
busca lograr.
En el capítulo II se presenta el marco teórico describiendo los temas conceptuales del
presente informe y los aspectos técnicos.
En el capítulo III Se detalla la metodología a usar para el desarrollo del proyecto.
1 RHEV Red Hat Enterprise Virtualization Sistema que hace posible la creación de máquinas (McBrien, 2012)
IX
En el capítulo IV se desarrolla la instalación y configuración de la plataforma virtual con
Red Hat Enterprise Vitualization.
X
INTRODUCCIÓN
Red Hat Enterprise Virtualization es una solución de virtualización generalizada tanto
para servidores y escritorios de centros de cómputo. Comprende dos componentes
principales.
Red Hat Enterprise Virtualization Manager para Servidores1 Un sistema de gestión
de la virtualización de servidores con múltiples características que ofrece capacidades
avanzadas para hosts y guests, inclusive alta disponibilidad, migración en vivo, gestión
de almacenamiento, programador de sistemas, y más aún.
Red Hat Enterprise Virtualization Hypervisor2 Un moderno hipervisor basado en KVM
que puede implementarse como hipervisor básico autónomo (incluido junto con Red Hat
Enterprise Virtualization para Servidores), o bien como Red Hat Enterprise Linux y
versiones posteriores (adquirido por separado) instalado como host hipervisor.
Con esta tecnología que también es compatible con un Storage que es un modo de
almacenamiento tendremos la ventaja de trasladar máquinas virtuales de un host a otro,
en este caso requerimos también de alta disponibilidad y es necesario usar dos host del
mismo hardware cada uno, También cuenta con un ahorrador de energía el cual
desactiva algunos hosts y lograr así un ahorro de energía, también cuenta con un
gestor de imágenes que genera máquinas virtuales a partir de plantillas.
2 Hypervisor host en el cual el manager usa recursos de hardware para crear virtuales.
11
CAPITULO I
GENERALIDADES
1.1. DEFINICION DEL PROBLEMA
Sodimac cuenta con una central en lima y tiene tres servidores en
producción, una que administra la caja y es la más importante en la cual
está instalado una versión 5 de RHEL (Red Hat Enterprise Linux), otra con
windows server en la cual maneja información personal solo de la Entidad
y un servidor proxmox3 que alberga servidores en kvm4 también propio de
la empresa pero no cuenta con un administrador, actualmente cuenta con
10 tiendas a nivel nacional a su cargo, todas las tiendas dependen de la
central como único centro de datos, son diferentes los acontecimientos
que producen la caída de uno de estos servidores o pueden ser los tres al
mismo tiempo ya sea por falta de energía eléctrica, desconexión de la red
y esto hace que los procesos de envío y entrega de información no sea
efectivo, por otro lado el tiempo de recuperación del sistema de los
3 Proxmox gestionador de máquinas virtuales de código abierto.
4 Kvm (Kernel based Virtual Machine), una de las tantas herramientas de virtualización. Basada en
GNU/Linux y desarrollada por la empresa Qumranet, esta herramienta de software libre permite la virtualización sobre hardware X86 y viene incluido por default a partir del Kernel 2.6.20 de Linux, permitiendo una rapida implementación.
12
servidores hacen que las transacciones se demoren por un tiempo
determinado dependiendo de la gravedad del caso.
1.1.1. PROBLEMA GENERAL
¿En qué medida el Despliegue de un ambiente virtual con
Red Hat Enterprise Virtualization garantiza el control de los
servidores de tiendas Sodimac?
1.1.2. PROBLEMA ESPECIFICO
¿Cuál es la arquitectura apropiada para desplegar un
ambiente de virtualización?
¿Qué tipo de Storage usar para el almacenamiento?
¿Qué metodología usar para poder desplegar un
ambiente de virtualización en tiendas Sodimac?
1.2. JUSTIFICACIÓN
La presente investigación se pretende desplegar una plataforma virtual
en Red Hat Enterprise Linux y se logrará lo siguiente:
Alta disponibilidad, Si falla un host, las máquinas virtuales se
reinician en otro host en forma automática.
Migración en vivo, trasladar las máquinas virtuales de un host a
otro en forma dinámica sin interrumpir el servicio.
13
Gestor de imágenes, Genera nuevas máquinas virtuales a partir de
plantillas.
Thim Provisioning, permite la creación de escritorios y servidores a
partir de plantillas almacenando únicamente las diferencias entre
las nuevas instancias y las plantillas base, ahorrando así espacio
de almacenamiento
1.3. HIPOTESIS
El Despliegue de una plataforma virtual con Red Hat Enterprise Virtual en
Tiendas Sodimac podrá controlar de una manera eficiente los servidores
de tiendas Sodimac.
1.4. OBJETIVOS
1.4.1. OBJETIVO GENERAL
Desplegar una plataforma virtual con Red Hat Enterprise
Virtualization para controlar los servidores de tiendas Sodimac.
1.4.2. OBJETIVOS ESPECIFICOS
Definir la arquitectura en la que se desplegará el software de
virtualización.
Definir un tipo de Storage para el almacenamiento.
Definir una metodología para desplegar un ambiente de
virtualización.
14
1.5. VARIABLES
1.5.1. VARIABLE DEPENDIENTE:
Plataforma virtual con Red Hat Enterprise Virtualization.
Definición Conceptual.
La plataforma Virtual con Red Hat Enterprise virtualization es una
solución diseñada para permitir una virtualización generalizada del
centro de cómputo y lograr un rendimiento del capital y una
eficiencia operativa sin precedentes. Red Hat Enterprise
Virtualization para servidores se basa en la plataforma Red Hat
Enterprise Linux en la que confían miles de organizaciones en
millones de sistemas en todo el mundo para sus cargas de trabajo
más críticas.
1.5.2. VARIABLE INDEPENDIENTE:
Controlar servidores
La Virtualizacion en general cuenta con un sistema de control de
las máquinas virtuales que hace posible manejar la cantidad de
nucleos, memoria ram, Disco Duro con que se va a crear una
maquina virtual.
1.6. LIMITACIONES DE LA INVESTIGACIÓN
El dominio de la investigación está delimitado a la Entidad Sodimac en el
área de sistemas. Y el periodo de estudio caracteriza a la investigación
como trasversal, porque se realizará en un momento determinado del
tiempo, durante los meses de Agosto a Setiembre del 2013.
15
1.7. METODOLOGÍA
Según la autora (Rita Mulcahy, 2011) menciona que la Gestión de
proyectos es una disciplina de planes para alcanzar un objetivo por lo
tanto se usará la metodología de Gestión de proyectos5.
1.8. PLANTEAMIENTO DE LA SOLUCIÓN
El despliegue de una plataforma virtual de servidores en TIENDAS
SODIMAC, permitirá brindar seguridad y confiabilidad de funcionamiento a
los servidores que se quiera instalar.
Para implementar la plataforma virtual con alta disponibilidad se trabajará
con lo siguiente:
Una computadora que administrará los hypervisores, dos servidores que
se usaran como hypervisores, estos servidores estarán en cluster para su
almacenamiento, una de ellas será el espejo para la alta disponibilidad
(activo/pasivo), en lo que respecta al almacenamiento se usará el sistema
de archivos Gluster, que estará inmerso en los dos servidores.A
continuación en la (Imagen 1) se detalla la arquitectura virtual
implementada, la cual cuenta con 2 servidores que cumplen la función de
Hypervisores y Almacenamiento, donde se levantarán las máquinas
virtuales, y un servidor virtual donde está alojada la instancia Servidor
Manager.
5 Metodología de Gestión de Proyectos se basa en el marco metodológico de idea (4 fases o estados
secuenciales en el tiempo por los que pasa un proyecto a lo largo de su existencia: INICIO, DESARROLLO,
ESTABILIZACION y APRENDIZAJE) (SUNAT, 2013)
16
1.9. CRONOGRAMA DE TRABAJO
El cronograma fue elaborado en base al EDT de la metodología (Véase
ANEXO N° 01)
Imagen 1 (Arquitectura de Hypervisores y Almacenamiento)
Fuente: Elaboración propia
17
CAPITULO II
MARCO TEORICO
2.1. VIRTUALIZACIÓN
Según César Hernandez Brito. (2011)6 , virtualización es como una estrategia
para reducir costos de operación en centros de cómputo y es una tecnología que
permite la creación de equipos, basados en software, que reproducen el
ambiente de una máquina física en sus aspectos de CPU, memoria,
almacenamiento y entrada y salida de dispositivos.
Con la virtualización de equipos físicos se logra la reducción de costos en rubros
como el mantenimiento, energía, espacio físico y personal necesario para la
administración del equipo. En su conjunto las reducciones producen ahorros muy
atractivos para las empresas o instituciones que buscan la optimización de sus
recursos, pero manteniendo, incluso incrementando el nivel de los servicios de
tecnologías de la información existentes.
6 César Hernandez Brito. (2011) “virtualización como una estrategia para reducir costos de operación en centros de cómputo”
[Tesis que para obtener el grado de maestro en ciencias en informática] instituto politécnico nacional. 2011
18
Mediante una exploración a fondo sobre las posibilidades de usar la
virtualización como estrategia de consolidación, se busca dotar a los
administradores de centros de cómputo con una valiosa herramienta para la
optimización de recursos.
De acuerdo a (Peggy Miranda Carbo, 2011), menciona el hardware que será
usado para configurar una virtualización con Hyper-V7. Se utilizará dos equipos
físicos, en el primer equipo haremos tres pruebas para poder escoger la
plataforma adecuada para nuestro diseño de un ERP. En la primera prueba
instalaremos Windows Server 2008 (Sistema Operativo) para poder trabajar con
Hyper-V6. En la segunda prueba instalaremos VMware ESXi 5.0 y en la tercera
prueba instalaremos Citrix XenServer. Una vez instaladas utilizaremos nuestro
segundo equipo para la conexión remota hasta nuestro servidor.
Un procesador x64, corriendo una versión x64 de Windows Server 2008
Standard, Windows Server 2008 Enterprise o Windows Server 2008 Datacenter.
Sin embargo, las herramientas de administración de Hyper-V6 están disponibles
para ediciones de 32 bits. Virtualización asistida por hardware. Está disponible
en procesadores que incluyen una opción de virtualización; concretamente, en
procesadores con tecnología Intel Virtualization Technology (Intel VT) o AMD
Virtualization (AMD-V). La Protección de ejecución de datos (DEP) aplicada por
hardware debe estar disponible y habilitada. Memoria mínima de 3 GB de RAM.
2.1.1. VIRTUALIZACIÓN DE PLATAFORMA
De acuerdo con (Jorge Lastras, 2009), existen muchos enfoques a la
virtualización de plataformas, aquí se listan con base en cuan
completamente es implementada una simulación de hardware.
7 Hyper-v es un programa de virtualización basado en un hipervisor para los sistemas de 64-bits con los procesadores basados
enAMD-V o Tecnología de virtualización Intel
19
Emulación o simulación: la máquina virtual simula un hardware
completo, admitiendo un sistema operativo “guest”8 sin modificar para
una CPU completamente diferente. Este enfoque fue muy utilizado
para permitir la creación de software para nuevos procesadores antes
de que estuvieran físicamente disponibles. Por ejemplo Bochs,
PearPC, Qemu sin aceleración, y el emulador Hercules. La emulación
es puesta en práctica utilizando una variedad de técnicas, desde state
machines hasta el uso de la recopilación dinámica en una completa
plataforma virtual.
Virtualización nativa y virtualización completa: la máquina virtual
simula un hardware suficiente para permitir un sistema operativo
“guest” sin modificar (uno diseñado para la misma CPU) para correr
de forma aislada. Típicamente, muchas instancias pueden correr al
mismo tiempo. Este enfoque fue el pionero en 1966 con CP-40 y CP[-
67]/CMS, predecesores de la familia de máquinas virtuales de IBM.
Algunos ejemplos: VMware Workstation, VMware Server, Parallels
Desktop, Virtual Iron, Adeos, Mac-on-Linux, Win4BSD, Win4Lin Pro y
z/VM.
8 Guest Palabra clave utilizada comúnmente para obtener archivos públicos de una computadora llamada
host (anfitrión), que es el servidor donde se encuentran los archivos.
20
Virtualización parcial (y aquí incluimos el llamado “address space
virtualization”: la máquina virtual simula múltiples instancias de
mucho (pero no de todo) del entorno subyacente del hardware,
particularmente address spaces. Este entorno admite compartir
recursos y aislar procesos, pero no permite instancias separadas de
sistemas operativos “guest”8. Aunque no es vista como dentro de la
categoría de máquina virtual, históricamente éste fue un importante
acercamiento, y fue usado en sistemas como CTSS, el experimental
IBM M44/44X, y podría decirse que en sistemas como OS/VS1,
OS/VS2 y MVS.
Paravirtualización: la máquina virtual no necesariamente simula un
hardware, en cambio ofrece un API especial que solo puede usarse
mediante la modificación del sistema operativo “guest” 8. La llamada
del sistema al hypervisor tiene el nombre de “hypercall” en Xen y
Parallels Workstation; está implementada vía el hardware instruction
DIAG (“diagnose”) en el CMS de VM en el caso de IBM (este fue el
origen del término hypervisor). Ejemplo: VMware ESX Server, Win4Lin
9x y z/VM.
Virtualización a nivel del sistema operativo: virtualizar un servidor
físico a nivel del sistema operativo permitiendo múltiples servidores
virtuales aislados y seguros correr en un solo servidor físico. El
21
entorno del sistema operativo “guest”8 comparte el mismo sistema
operativo que el del sistema “host” (el mismo kernel del sistema
operativo es usado para implementar el entorno del “guest”). Las
aplicaciones que corren en un entorno “guest” dado lo ven como un
sistema autónomo. Ejemplos: Linux-VServer, Virtuozzo, OpenVZ,
Solaris Containers y FreeBSD Jails.
Virtualización de aplicaciones: consiste en el hecho de correr una
desktop o una aplicación de server localmente, usando los recursos
locales, en una máquina virtual apropiada. Esto contrasta con correr la
aplicación como un software local convencional (software que fueron
“instalados” en el sistema). Semejantes aplicaciones virtuales corren
en un pequeño entorno virtual que contienen los componentes
necesarios para ejecutar, como entradas de registros, archivos,
entornos variables, elementos de uso de interfaces y objetos globales.
Este entorno virtual actúa como una capa entre la aplicación y el
sistema operativo, y elimina los conflictos entre aplicaciones y entre
las aplicaciones y el sistema operativo. Los ejemplos incluyen el Java
Virtual Machine de Sun, Softricity, Thinstall, Altiris y Trigence (esta
metodología de virtualización es claramente diferente a las anteriores;
solo una pequeña línea divisoria los separa de entornos de máquinas
virtuales como Smalltalk, FORTH, Tel, P-code).
22
2.1.2. VENTAJAS DE LA VIRTUALIZACIÓN
Según (Aragundi Alicia, 2012) mencionan que la virtualización en la
empresa tiene una clara aplicación práctica y la consolidación de
servidores. La consolidación de servidores consiste simplemente en la
reducción del número de servidores. Existen distintas maneras de
consolidar, y una de ellas es la virtualización. Frente a otras vías para la
consolidación, la virtualización permite reducir el número de servidores y
optimizar al mismo tiempo su utilización. Es decir, que si antes de
consolidar teníamos 100 servidores con una utilización media de CPU del
30%, después de consolidar con virtualización tendremos 50 servidores
con una utilización media de CPU del 60%. Si consolidamos sin
virtualización, podríamos tener 70 servidores con una utilización media del
40% (los números son meramente ilustrativos).
Muchas compañías se encuentran actualmente inmersas en proyectos de
consolidación de servidores, pero ¿por qué consolidar, y no seguir con el
modelo de servidores independientes?
Si preguntásemos a un empleado del departamento de informática de
cualquier compañía que nos describiera el CPD9, seguramente lo haría
basándose en los servidores existentes. Nos mencionaría, por ejemplo, el
9 CPD son unas siglas que pueden referirse a Centro de procesamiento de datos, ubicación de los
recursos necesarios para el procesamiento de información de una organización.
23
servidor de base de datos, el servidor del correo electrónico, el servidor de
CRM10 Y también nos comentaría que cada servidor es de un fabricante
diferente y cuenta con sistemas operativos diferentes. Por tanto, también
se necesitan administradores formados en las diversas tecnologías
existentes, y herramientas de gestión específicas, porque (digamos) lo
que vale para monitorizar los servidores con Windows, no vale para los
servidores con Unix.
Por tanto, como resumen, cabría destacar entre las principales ventajas
de la virtualización:
Consolidación de servidores.
Aumento de la disponibilidad, reducción de tiempos de parada.
Reducción de los costes de administración.
Mejora de las políticas de backup, recuperación ágil mediante
puntos de control de las máquinas virtuales.
Aprovechamiento óptimo de los recursos disponibles. Respuesta
rápida ante cambios bajo demanda.
Continuidad de negocio y recuperación ante desastres. En caso
de fallo de un sistema físico, los sistemas lógicos allí contenidos
pueden distribuirse dinámicamente a otros sistemas.
Escalabilidad. Crecimiento ágil con contención de costes.
10
CRM es un modelo de gestión de toda la organización, basada en la orientación al cliente (u orientación al mercado según otros autores)
24
Virtual appliance: máquinas virtuales preconfiguradas, cargar y
funcionar.
Máquinas paquetizadas y preconfiguradas para desempeñar una
función determinada (servidores de correo, bases de datos,
centralitas VoIP, aplicaciones cerradas).
Mantenimiento de aplicaciones heredadas. Aplicaciones
propietarias que no han sido adaptadas a las nuevas versiones de
sistema operativo.
Eficiencia energética.
2.1.3. COMPATIBILIDAD
Según consta el Autor (Aragundi Alicia, 2012), menciona que una
computadora física, una máquina virtual aloja su propio sistema operativo
invitado y aplicaciones, y posee los demás componentes típicos de una
computadora física (placa base, tarjeta VGA, controlador de tarjeta de red,
etc.). Por lo tanto, las máquinas virtuales son totalmente compatibles con
todos los sistemas operativos, aplicaciones y controladores de dispositivos
x86 estándar, y usted puede utilizar una máquina virtual para ejecutar el
mismo software que ejecutaría en una computadora x86 física.
2.1.4. ENCAPSULAMIENTO
EL autor (Aragundi Alicia, 2012), menciona que una máquina virtual es
básicamente un contenedor de software que empaqueta o "encapsula" un
25
conjunto entero de recursos de hardware virtual, así como un sistema
operativo y todas sus aplicaciones, dentro de un paquete de software. El
encapsulamiento permite que las máquinas virtuales sean notablemente
portátiles y fáciles de administrar. Por ejemplo, es posible mover y copiar
una máquina virtual de una ubicación a otra como si fuera un archivo de
software cualquiera, o guardar una máquina virtual en un medio de
almacenamiento de datos estándar, desde una tarjeta de memoria USB
hasta una red de área de almacenamiento (SAN)11 empresarial.
2.1.5. VIRTUALIZACIÓN DE SERVIDORES
En lo que respecta en la virtualización de servidores el autor (Aragundi
Alicia, 2012), mencionan que Para la mayoría de los empleados de TI, la
palabra “virtualización” evoca la idea de ejecutar múltiples sistemas
operativos en una única máquina física. Esto es virtualización del
hardware y aunque no es la única clase importante de virtualización, sin
dudas es la más visible en la actualidad.
La idea básica de la virtualización del hardware es simple: utilizar software
para crear una máquina virtual que emula a una computadora física. Esto
crea un entorno de sistema operativo separado que se aísla en forma
lógica del servidor host. Al ofrecer múltiples máquinas virtuales al
11
Una SAN es una red dedicada al almacenamiento que está conectada a las redes de comunicación de una compañía. Además de contar con interfaces de red tradicionales, los equipos con acceso a la SAN tienen una interfaz de red específica que se conecta a la SAN.
26
momento, este enfoque permite ejecutar varios sistemas operativos en
forma simultánea en una única máquina física.
La virtualización del servidor también facilita la restauración de los
sistemas fallidos. Las máquinas virtuales se almacenan como archivos,
por lo que la restauración de un sistema con fallas puede ser tan simple
como copiar el archivo a una nueva máquina. Como las máquinas
virtuales pueden tener diferentes configuraciones de hardware de aquellas
de la máquina física en la que se ejecutan, este enfoque también hace
posible la restauración de los sistemas fallidos en cualquier máquina
disponible. No existen requisitos para la utilización de un sistema
físicamente idéntico.
2.2. SERVIDORES
En lo que respecta a un servidor de acuerdo con (Aragundi Alicia, 2012), una
computadora que forma parte de una red, provee servicios a otras
computadoras denominadas clientes. También se suele denominar con la
palabra servidor a:
Una aplicación informática o programa que realiza algunas tareas en
beneficio de otras aplicaciones llamadas clientes. Algunos servicios
habituales son los servicios de archivos, que permiten a los usuarios
almacenar y acceder a los archivos de una computadora y los servicios de
27
aplicaciones, que realizan tareas en beneficio directo del usuario final. Este
es el significado original del término. Es posible que un ordenador cumpla
simultáneamente las funciones de cliente y de servidor.
Una computadora en la que se ejecuta un programa que realiza alguna
tarea en beneficio de otras aplicaciones llamadas clientes, tanto si se trata
de un ordenador central (mainframe), un miniordenador, una computadora
personal, un PDA 12 o un sistema embebido 13 ; sin embargo, hay
computadoras destinadas únicamente a proveer los servicios de estos
programas: estos son los servidores por antonomasia.
Un servidor no es necesariamente una máquina de última generación de
grandes proporciones, no es necesariamente un superordenador; un
servidor puede ser desde una computadora vieja, hasta una máquina
sumamente potente (ej.: servidores web, bases de datos grandes, etc.
Procesadores especiales y hasta varios terabytes de memoria). Todo esto
depende del uso que se le dé al servidor. Si usted lo desea, puede convertir
al equipo desde el cual usted está leyendo esto en un servidor instalando
un programa que trabaje por la red y a la que los usuarios de su red
ingresen a través de un programa de servidor web como Apache.
12
Un PDA (Personal Digital Assistant o Ayudante personal digital) es un dispositivo de pequeño tamaño que combina un ordenador, teléfono/fax, Internet y conexiones de red. 13
es un sistema de computación diseñado para realizar una o algunas pocas funciones dedicadas
1 2 frecuentemente en un sistema de computación en tiempo real.
28
Por lo cual podemos llegar a la conclusión de que un servidor también
puede ser un proceso que entrega información o sirve a otro proceso. El
modelo Cliente-servidor no necesariamente implica tener dos ordenadores,
ya que un proceso cliente puede solicitar algo como una impresión a un
proceso servidor en un mismo ordenador.
2.3. RED HAT ENTERPRISE VIRTUALIZATION PARA
SERVIDORES
Según (RedHat, 2013) en su página web menciona que Red Had
Enterprise Virtualization es una solución de virtualización integral con
casos de uso para servidores y escritorios, diseñada para permitir una
virtualización generalizada del centro de cómputos y lograr un rendimiento
del capital y una eficiencia operativa sin precedentes. Red Hat Enterprise
Virtualization para Servidores se basa en la plataforma Red Hat Enterprise
Linux. Comprende el siguiente par de componentes:
Red hat Enterprise Virtualization Manager
Un sistema de gestión de la virtualización de servidores con múltiples
características que ofrece capacidades avanzadas para hosts y guests,
inclusive alta disponibilidad, migración en vivo, gestión de
almacenamiento, programador de sistemas, y más aún.
Red Hat Enterprise Virtualization Hypervisor
29
Moderno hypervisor basado en la tecnología de virtualización Kernel
Virtual Machine (KVM), el cual puede ser desplegado en cualquier
escenario, ya sea en modo híbrido en un Red Hat Enterprise Linux
acompañado de los servicios que se ejecuten en el host, o dedicado,
ejecutado solo el hypervisor con un SO liviano y dedicado al lojamiento
de las Máquinas Virtuales.
Red Hat Enterprise Virtualization (RHEV) Hypervisor es un compacto,
plataforma de virtualización con todas las funciones de forma rápida y
fácil de implementar y administrar los huéspedes virtualizados. la RHEV
Hypervisor es parte de la Red Hat Enterprise Suite de virtualización. El
RHEV Hypervisor está diseñado para integración con la Red Hat
Enterprise Virtualization Administrador de servidores y el Red Hat
Enterprise Virtualization Manager para Desktops. El RHEV Hypervisor
se puede instalar desde el almacenamiento USB dispositivos, CD-
ROMs, DVDs, pre-instalado por un OEM o aprovisionado en la red
mediante PXE. El RHEV Hypervisor se basa en el Virtual basada en el
Kernel Machine (KVM). KVM es un avanzado y eficiente virtualización
de hipervisor implementa como un kernel Linux módulo. Como KVM es
un módulo del kernel, que aprovecha la existente Red Hat Enterprise
Linux kernel y se beneficia de la extensas pruebas de kernel por
defecto, soporte de dispositivos y flexibilidad.(En la Imagen 2 se
muestra la arquitectura del Hypervisor)
30
Red Hat Enterprise Virtualization tiene una interfaz web de
administración comprensible, incluyendo migraciones de máquinas
virtuales en vivo, es decir migrar las máquinas virtuales de un host a
otro, ofrece alta disponibilidad, optimiza la carga de trabajo, balanceo
dinámico de carga y otros. La Imagen N° 3 muestra la interfaz web de
administración de Red Hat Enterprise Virtualization Manager.
Imagen 2 (Arquitectura del Hypervisor)
Fuente: (RedHat, 2013)
31
Imagen N° 3 (interfaz web de administración de Red Hat Enterprise Virtualization Manager)
Fuente: (RedHat, 2013)
Red Hat Enterprise Virtualization cuenta con una única y revolucionaria
tecnología de virtualización llamada Kvm que convierte a kernel de
RHEL en una plataforma de virtualización.
2.3.1 MÁQUINA VIRTUAL (KVM)
L a Máquina Virtual basada en el Kernel (KVM) es un módulo cargable del
núcleo que proporciona virtualización completa mediante el uso de la Intel
VT o AMD-V extensiones de hardware. Unque sí KVM se ejecuta en el
espacio del núcleo, los invitados que se ejecutan en él se ejecutan como
32
QEMU procesos individuales en el espacio de usuario. KVM permite a un
host para que el hardware físico disponible para máquinas virtuales.
KVM (Kernel based Virtual Machine) [virtualización y cloud]. Una de las
tantas herramientas de virtualización. Basada en GNU/Linux y
desarrollada por la empresa Qumranet, esta herramienta de software libre
permite la virtualización sobre hardware X86 y viene incluido por default a
partir del Kernel 2.6.20 de Linux, permitiendo una rápida implementación.
KVM realiza una virtualización completa, a diferencia de otras alternativas
que hacen emulación del procesador (Virtual Box, VMWare), lo cual da
muchísima usabilidad y flexibilidad, pero no aprovecha bien los recursos
del servidor, lo cual hace un poco más lenta la ejecución del SO huésped.
Estos son algunas cualidades de KVM:
Es un módulo del kernel, luego no hace falta arrancar kernels
especiales ni aplicar parches.
No es necesario modificar el kernel del sistema operativo que vas a
ejecutar dentro de la máquina virtual.
Soporta tecnología NUMA, por lo que permite una escalabilidad muy
amplia.
Tiene muy pocas líneas de código.
Usa el scheduler y gestor de memoria propio del kernel.
33
Fácil instalación, ya que necesitas instalar solo 3 paquetes (qemu,
kvm y kvm-kmp).
La interfaz de escritorio para administrar las máquinas virtuales se llama
Virtual Machine Manager (virt-manager es el nombre del paquete). Esta
permite tener una visión del funcionamiento y utilización de los recursos
en tiempo real, actualizaciones y estadísticas de la utilización de recursos.
Permite ver los gráficos detallados de rendimiento y utilización en el
tiempo. Permite la creación de nuevos dominios, la configuración y el
ajuste de la asignación de recursos de un dominio y hardware virtual. Trae
incorporado un cliente de VNC, la cual presenta una consola gráfica
completa del dominio huésped.
No podemos omitir el gran cambio que realizo Red Hat al migrar de Xen a
KVM, brindándole un apoyo más que importante. Red Hat decidió llevar su
solución de virtualization RHEV (Red Hat Enterprise Virtualization) a KVM.
2.3.2 QEMU
QEMU es un emulador multiplataforma utilizado para proporcionar la
emulación completa del sistema. QEMU emula un sistema completo, por
ejemplo un PC, incluyendo uno o más procesadores, y periféricos. QEMU
se puede utilizar para poner en marcha diferentes sistemas operativos o
para depurar el código del sistema. QEMU, trabajando en conjunto con
34
KVM y un procesador con extensiones de virtualización adecuados,
proporciona virtualización completa asistida por hardware.
2.3.3 RED HAT ENTERPRISE VIRTUALIZATION MANAGER HOST
AGENT, VDSM
En Red Hat Enterprise Virtualization, VDSM inicia acciones en las
máquinas virtuales y de almacenamiento. Además, facilita la
comunicación entre los host. VDSM supervisa los recursos de acogida,
como la memoria, almacenamiento y redes. Además, VDSM gestiona
tareas como la creación de la máquina virtual, la acumulación de
estadísticas y recopilación de registros. Un ejemplo VDSM ejecuta en
cada host y recibe comandos de administración desde el Hat Enterprise
Virtualization Manager Red a través del puerto 54321 reconfigurable.
VDSM-REG: VDSM utiliza VDSM-REG para registrar cada host con el
Hat Enterprise Virtualization Roja. VDSM-REG suministra información
sobre sí mismo y su host utilizando el puerto 80 o el puerto 443.
2.3.4 LIBVIRT
Libvirt facilita la gestión de máquinas virtuales de sus dispositivos virtuales
asociados. Cuando Red Hat Enterprise Virtualization comandos inicia el
35
ciclo de vida de la máquina virtual (iniciar, detener, reiniciar el sistema),
VDSM invoca libvirt en las máquinas host pertinentes para su ejecución.
Pool Manager torage, SPM
2.3.5 POOL STORAGE MANAGER (SPM)
Es una función asignada a un host en un centro de datos. El anfitrión SPM
tiene la facultad exclusiva de hacer todos los cambios de estructura de
dominio de metadatos de almacenamiento del centro de datos. Esto
incluye la creación, eliminación y manipulación de imágenes de disco
virtuales, instantáneas y plantillas. También incluye la asignación de
almacenamiento para dispositivos de bloques dispersos en una red de
área de almacenamiento (SAN). El papel de SPM se puede migrar a un
sistema de un centro de datos. Como resultado, todos los hosts en un
centro de datos deben tener acceso a todos los dominios de
almacenamiento definido en el centro de datos.
Red Hat Enterprise Virtualization asegura que el SPM está siempre
disponible. En caso de errores de conectividad de almacenamiento, el
Gestor de re-asigna la función SPM a otro host.
2.3.6 SISTEMA OPERATIVO INVITADO
Los sistemas operativos invitados se pueden instalar sin modificaciones
en las máquinas virtuales en un entorno de Red Hat Enterprise
36
Virtualization. El sistema operativo invitado, y cualquier aplicación en el
cliente, no son conscientes del entorno virtualizado y se ejecutan
normalmente.
Red Hat proporciona controladores de dispositivos mejorados que
permiten un acceso rápido y eficiente a los dispositivos virtualizados.
También puede instalar el Hat Enterprise Virtualization Agente Invitado
Red de huéspedes, que ofrece una mayor información de los invitados a la
consola de administración.
2.3.7 ARQUITECTURA DE RED HAT ENTERPRISE
VIRTUALIZATION
Un entorno de virtualización de Red Hat Enterprise consiste en: (En la
Imagen N° 4 se muestra la arquitectura de RHEV)
Hosts de máquinas virtuales mediante la Máquina Virtual
basada en el Kernel (KVM)4.
Agentes y herramientas que se ejecutan en hosts como
VDSM, QEMU y libvirt. Estas herramientas proporcionan
localesla gestión de las máquinas virtuales, redes y
almacenamiento.
37
The Hat Virtualization Manager Empresa Red, una
plataforma de gestión centralizada de la Red.
Hat Enterprise Virtualization ambiente. Proporciona una
interfaz gráfica donde se puede ver, provisión y gestión de
los recursos.
Dominios de almacenamiento para guardar los recursos
virtuales como máquinas virtuales, plantillas, ISOs.
Una base de datos para realizar un seguimiento de la
situación y los cambios en el medio ambiente.
El acceso a un servidor de directorio externo para
proporcionar a los usuarios y la autenticación.
La creación de redes para vincular el medio ambiente
juntos. Esto incluye enlaces de red físicos y lógicos redes
38
Imagen N° 4 (Arquitectura de virtualización en Red Hat)
Fuente: (RedHat, 2013)
2.3.8 COMPONENTES DEL SISTEMA
El entorno de virtualización de Red Hat Enterprise se compone de uno o
más huéspedes (tanto Red Hat Enterprise Linux o hosts de plazo o Red
Hat Enterprise Virtualization Hypervisor hosts) y por lo menos una Red Hat
Enterprise Virtualization Manager.
Los Hosts ejecutan máquinas virtuales con la tecnología de virtualización
KVM4 (Máquina Virtual basada en el Kernel).
The Hat Enterprise Virtualization Red se ejecuta en un servidor de Red
Hat Enterprise Linux 6 y proporciona interfaces para el control del entorno
Red Hat Enterprise Virtualization. Gestiona virtuales máquinas y
39
aprovisionamiento de almacenamiento, protocolos de conexión, las
sesiones de usuario, imágenes de la máquina virtual, y máquinas virtuales
de alta disponibilidad.
2.3.9 RECURSOS
Los componentes del entorno según la página web de (RedHat, 2013)
RHEV se dividen en dos categorías: físicas los recursos y los recursos
lógicos. Los recursos físicos son objetos físicos, tales como anfitrión y
almacenamiento servidores. Recursos lógicos son agrupaciones y
procesos no físicos, como las redes lógicas y plantillas de máquinas
virtuales.
Redes lógicas - Una red lógica es una representación lógica
de una red física. Grupo lógico de redes de tráfico de red y la
comunicación entre la Gestora, los anfitriones, almacenamiento
y virtuales máquinas.
Hosts - Un host es un servidor físico que ejecuta una o más
máquinas virtuales. Los anfitriones se agrupan en racimos . Las
máquinas virtuales pueden migrar de un host a otro dentro de
un clúster.
Agrupación de almacenamiento - La agrupación de
almacenamiento es una entidad lógica que contiene un
repositorio de imágenes independiente de un cierto tipo, ya sea
iSCSI , Fibre Channel , NFS o POSIX . Cada agrupación de
40
almacenamiento puede contener varios dominios, para el
almacenamiento de imágenes de disco de máquinas virtuales ,
imágenes ISO , y para la importación y exportación de virtuales
imágenes de la máquina .
Máquinas Virtuales - Una máquina virtual es un escritorio
virtual o servidor virtual contiene un operativo sistema y un
conjunto de aplicaciones. Varias máquinas virtuales idénticas
se pueden crear en una pool. virtual máquinas se crean ,
gestionan , o borrados por los usuarios de energía y el acceso a
los usuarios .
Plantilla - Una plantilla es una máquina virtual modelo con
ajustes predefinidos. Una máquina virtual que es basado en
una plantilla particular, adquiere la configuración de la plantilla.
Uso de plantillas es el más rápido manera de crear un gran
número de máquinas virtuales en un solo paso.
Máquina Virtual Pool - Una agrupación de máquina virtual es
un grupo de máquinas virtuales idénticas que son disponible en
la demanda por cada miembro del grupo. Pools de máquinas
virtuales se pueden configurar para diferentes propósitos. Por
ejemplo, un grupo puede ser con el departamento de Marketing,
otro para la Investigación y Desarrollo, y así sucesivamente .
41
Snapshot - Una instantánea es una vista del sistema operativo
de una máquina virtual y todas sus aplicaciones en un punto en
el tiempo. Se puede utilizar para guardar la configuración de
una máquina virtual antes de una actualización o una
instalación nuevas aplicaciones. En caso de problemas, una
instantánea se puede utilizar para restaurar la máquina virtual a
su estado original.
Tipos de usuarios - Red Hat Enterprise Virtualization soporta
múltiples niveles de los administradores y usuarios con distintos
niveles de permisos. Los administradores de sistemas pueden
manejar objetos de la física infraestructura, como centros de
datos, hosts y almacenamiento. Los usuarios acceden a las
máquinas virtuales disponibles de un parque de máquinas
virtuales o máquinas virtuales independientes accesibles por un
administrador.
Eventos y monitores - alertas, advertencias y demás avisos
sobre actividades ayudan al administrador supervisar el
rendimiento y el estado de los recursos.
Informes - Una gama de informes ya sea desde el módulo de
informes basados en JasperReports, o del almacén de datos.
Informes preconfigurados o ad hoc pueden ser generados
42
desde el módulo de informes. Usuarios También puede generar
informes utilizando cualquier herramienta de consulta que
soporta SQL de un almacén de datos que recoge los datos de
seguimiento para hosts, máquinas virtuales y de
almacenamiento.
2.3.10 RED HAT ENTERPRISE VIRTUALIZATION ARQUITECTURA
2.4.10.1 INTERFACES PARA ACCEDER AL ADMINISTRADOR
a. User Portal
La virtualización de escritorio ofrece a los usuarios un
entorno de escritorio que es similar entorno de escritorio
de una computadora personal. E l usuario del portal es
para la entrega de infraestructura de escritorio virtual a
los usuarios. Los usuarios acceden al portal del usuario a
través de un navegador web para visualizar y acceder a
sus escritorios virtuales asignados. L a acciones
disponibles para un usuario en el portal del usuario, se
establecen por un administrador del sistema. tandard
usuarios pueden iniciar, detener, y el uso de equipos de
escritorio que están asignadas a ellos por el
administrador del sistema. Los usuarios avanzados
pueden realizar algunas acciones administrativas. Ambos
tipos de usuarios acceden al portal del usuario de la
43
misma URL, y se presentan con opciones adecuadas a
su nivel de permisos de acceso.
Estándar de cuentas de usuario
Los usuarios estándar pueden alimentar sus
escritorios virtuales dentro y fuera y conectarse a
ellos a través del portal del usuario. Conexión directa
a las máquinas virtuales se facilita con el protocolo
simple para entornos de computación independiente
(SPICE) o clientes Virtual Network Computing (VNC).
Ambos protocolos proporcionan al usuario un
entorno similar a un entorno de escritorio instalado
localmente. E l administrador especifica el protocolo
usado para conectarse a una máquina virtual en el
momento de la creación de la máquina virtual.
Más información sobre las acciones disponibles en el
portal del usuario, así como navegadores y clientes
soportados se pueden encontrar en la Guía del
usuario del portal.
Potencia de cuentas de usuario
Red Hat Enterprise Virtualization usuario del portal
proporciona a los usuarios de energía, con una
interfaz gráfica de usuario para crear, usar y
controlar los recursos virtuales. Los administradores
44
de sistemas pueden delegar algunas tareas de
administración mediante la concesión a los usuarios
acceso usuarios avanzados. Además de las tareas
que pueden realizar los usuarios estándar, los
usuarios avanzados pueden:
Crear, editar y eliminar máquinas virtuales.
Administrar discos virtuales y las interfaces de
red.
Asignar permisos de usuario para máquinas
virtuales.
Crear y utilizar plantillas para implementar
rápidamente máquinas virtuales.
Supervisar el uso de recursos y eventos de alta
gravedad.
Crear y usar instantáneas para restaurar las
máquinas virtuales con estados previos.
Los usuarios avanzados pueden realizar tareas de
administración de máquinas virtuales que deben
delegarse. Centro de datos y las tareas de
administración de nivel de clúster se guardan para el
administrador del medio ambiente.
45
b. Administración del portal
La administración Portal es la interfaz gráfica de
administración de la Empresa servidor de virtualización
de Red Hat. Uso de los administradores de TI pueden
controlar, crear y mantener todos los elementos del
entorno virtualizado utilizando los navegadores web. T
pide que se puede realizar desde el Portal de la
Administración incluyen:
Creación y gestión de la infraestructura virtual
(redes, dominios de almacenamiento).
Instalación y gestión de los ejércitos.
Creación y gestión de entidades lógicas (centros
de datos, clusters).
Creación y administración de máquinas virtuales.
Red Hat Enterprise Virtualization usuario y gestión
de permisos.
La Administración Portal se visualiza utilizando el
JavaScript.
Las funciones de administración del portal se discuten
con más detalle en el Hat Enterprise Guía de
administración de virtualización de Red. La
información sobre los navegadores y plataformas que
46
son compatibles con el Portal de la Administración se
puede encontrar en el Manual de instalación de Red
Hat Enterprise Virtualization.
2.4.10.2 COMPONENTES QUE SOPORTAN EL MANAGER
a. Jboss Plataforma de aplicación empresarial
JBoss Enterprise Application Platform es un servidor de
aplicaciones Java. Proporciona un marco para apoyar el
desarrollo eficiente y la entrega de aplicaciones Java
multiplataforma. L a Red Hat Enterprise Virtualization se
entrega utilizando JBoss EAP.
b. Recopilación de Informes y datos históricos
La Red Hat Enterprise Virtualization Manager incluye un
almacén de datos que recoge los datos de seguimiento
sobre hosts, máquinas virtuales y de almacenamiento.
Una serie de informes predefinidos disponibles. Los
clientes pueden analizar sus entornos y crear informes
con las herramientas de consulta que soportan SQL.
El proceso de instalación de Red Hat Enterprise
Virtualization Manager crea dos bases de datos.
47
Estas bases de datosse crean en una instancia de
Postgres que se selecciona durante la instalación.
E l motor de base de datos es el almacén de datos
principal utilizado por el Red Hat
EnterpriseVirtualization Manager. Información
sobre el entorno de virtualización como su estado,
la configuración y el rendimiento se almacenan en
esta base de datos.
E l ovirt_engine_history base de datos contiene
información de configuración y parámetros
estadísticos que se recopilan en el tiempo de la
base de datos de funcionamiento del motor. L os
datos de configuración en la base de datos del
motor se examina cada minuto, y los cambios se
replican en la base de datos ovirt_engine_history.
T estanterías de los cambios a la base de datos
proporciona información sobre los objetos de la
base de datos. E ste le permite analizar y mejorar
el rendimiento de su entorno de Red Hat
Enterprise Virtualization y resolver dificultades.
48
c. servicios de directorio
Los servicios de directorio proporcionan un
almacenamiento basado en red centralizada de usuarios
y de organización e información. Tipos de información
almacenada incluye la configuración de aplicaciones,
perfiles de usuario, los datos del grupo, políticas y control
de acceso. Red Hat Enterprise Virtualization Manager
soporta ActivoDirectorio, gestión de identidades (IDM), y
Red Hat Directory Server 9. H ay también a nivel local,
dominio interno sólo para fines de administración. T su
dominio interno tiene sólo un usuario: elusuario admin
2.3.11 CARACTERÍSTICAS Y BENEFICIOS
● Migración en vivo: Traslade máquinas virtuales de un host a otro
en forma dinámica sin interrumpir el servicio.
● Alta disponibilidad: Si falla un host, las máquinas virtuales se
reinician en otro host en forma automática.
● Programador de sistemas: Equilibra las cargas de trabajo en el
centro de cómputos mediante la migración dinámica en vivo de las
máquinas virtuales en función del aprovechamiento y la política de
recursos.
49
● Ahorro de energía: Durante horas de baja demanda concentra las
máquinas virtuales en un número menor de hosts para permitir
desactivar algunos y lograr así un ahorro de energía.
● Gestor de mantenimiento: Permite efectuar tareas de
mantenimiento en los hosts sin provocar tiempo improductivo en los
guests.
● Gestor de imágenes: Genera nuevas máquinas virtuales a partir
de plantillas.
● Thin provisioning: Permite la creación de escritorios y servidores
a partir de plantillas almacenando únicamente las diferencias entre
las nuevas instancias y las plantillas base, ahorrando así espacio
de almacenamiento.
2.3.12 STORAGE
Red Hat Enterprise Virtualization usa un sistema de almacenamiento
centralizado para las imágenes de disco de máquinas virtuales,
plantillas, fotos y archivos ISO. El almacenamiento se agrupa
lógicamente en grupos de almacenamiento, que se componen de
dominios de almacenamiento. Un dominio de almacenamiento es una
combinación de la capacidad de almacenamiento y metadatos que
describen la estructura interna del almacenamiento. H ay tres tipos de
dominio de almacenamiento, datos, exportación e ISO.
50
El dominio de almacenamiento de datos es el único requerido por cada
centro de datos. Un dominio de almacenamiento de datos es exclusivo
de un solo centro de datos. Dominios ISO exportación y son opcionales.
Dominios de almacenamiento son recursos compartidos y deben ser
accesibles a todos los hosts en un centro de datos.
La creación de redes de almacenamiento se puede realizar utilizando el
Sistema de archivos de red (NFS), Internet Small Computer System
Interface (iSCSI) o Fibre Channel Protocol (FCP). Red Hat Enterprise
Virtualization ofrece, además, la capacidad sin soporte para utilizar
cualquier sistema de archivos compatible con POSIX en red como un
dominio de datos.
En NFS (y otros sistemas de archivos compatibles con POSIX)
dominios, todos los discos virtuales, plantillas e instantáneas son
archivos simples.
En dominios SAN (iSCSI / FCP), los dispositivos de bloque se agregan
por el Administrador de volúmenes lógicos (LVM) en un grupo de
volúmenes (VG). Cada disco virtual, la plantilla y la instantánea es una
de volúmenes lógicos (LV) en la VG. (En la Imagen N° 5 se muestra la
arquitectura de un Storage)
51
Data storage domain
Dominios de retención de datos de las imágenes de disco duro
virtual de todas las máquinas virtuales que se ejecutan en el
entorno. Templates e instantáneas de las máquinas virtuales
también se almacenan en el dominio de datos. Un dominio de datos
no puede ser compartida a través de los centros de datos, y el
dominio de datos debe ser del mismo tipo que el centro de datos.
Por ejemplo, un centro de tipo iSCSI de datos debe tener un
dominio de datos iSCSI.
Export storage domain
Un dominio de exportación es un repositorio de almacenamiento
temporal que se utiliza para copiar y mover imágenes entre centros
de datos y entornos de Red Hat Enterprise Virtualization. La
exportar dominio se puede utilizar para realizar copias de seguridad
Imagen N° 5 (Arquitectura de Storage)
Fuente: (RedHat, 2013)
52
de máquinas virtuales y plantillas. Un dominio de exportación se
puede mover entre los centros de datos, pero sólo puede estar
activo en un centro de datos a la vez.
ISO storage domain
Almacenar archivos ISO ISO dominios, que son lógicas CD-ROM
utilizados para instalar sistemas operativos y aplicaciones de las
máquinas virtuales. Como una entidad lógica que sustituye a una
biblioteca de CD-ROMs físicas o DVD, un dominio ISO elimina la
necesidad del centro de datos para los medios físicos. Un dominio
ISO puede ser compartida a través de diferentes centros de datos.
2.5. STORAGE
En lo que respecta al almacenamiento en la página oficial de Red Hat (RedHat,
2013) recomienda usar Storage el cual tiene los siguientes conceptos.
2.5.1. CENTRO DE DATOS (DATA CENTER)
Un centro de datos es el más alto nivel de abstracción en Red Hat
Enterprise Virtualization. Un centro de datos es un recipiente que se
compone de tres tipos de sub-contenedores:
El contenedor de almacenamiento (storage container) contiene
información acerca de los tipos de almacenamiento y dominios de
almacenamiento, incluyendo la información de conectividad para
53
los dominios de almacenamiento. El almacenamiento se define
para un centro de datos, y está disponible para todos los grupos en
el centro de datos. Todos los clústeres de hosts dentro de un centro
de datos tienen acceso a los mismos dominios de almacenamiento.
El contenedor de red (network container). Contiene información
acerca de las redes lógicas del centro de datos. E ste incluye
detalles tales como direcciones de red, las etiquetas VLAN y
soporte ST P. Redes lógicas se definen para un centro de datos, y
se implementan opcionalmente al nivel del grupo.
El contenedor de grupos clusters (cluster container). Los
clusters son grupos de hosts con núcleos de procesadores
compatibles, ya sea procesadores AMD o Intel. Los clusters son
dominios de migración; máquinas virtuales pueden vivir-emigraron
a cualquier host dentro de un grupo, y no a otros grupos. Un centro
de datos puede contener varios grupos, ycada grupo puede
contener varios hosts.
2.5.2. DOMINIOS DE ALMACENAMIENTO (Storage Domains
Overview)
Un dominio de almacenamiento es un repositorio central para acceder a
imágenes de disco y los metadatos. Dominios de almacenamiento secreto
54
de los datos de máquina virtual y metadatos, imágenes ISO, fotos y otros
datos en una ubicación central que es accesible a todos los hosts en un
centro de datos. Dominios de almacenamiento también tienen metadatos
sobre sí mismos que se utiliza para mantener los datos de la máquina
virtual se corrompan.
El archivo de almacenamiento basado en bloques se pueden usar para
crear dominios de almacenamiento. Los dominios de almacenamiento se
implementan utilizando el Sistema de archivos de red (NFS) o Fibre
Channel Protocol (FCP). FCP incluye al macenamiento de acceso
mediante iSCSI, FCoE y SAS.
Hay tres tipos de dominios: Dominios de almacenamiento de
almacenamiento de datos, dominios de almacenamiento ISO y
exportación de dominios de almacenamiento.
2.5.3. TIPOS DE DOMINIO DE ALMACENAMIENTO
Dominios de almacenamiento pueden ser implementados utilizando
bloque base y el archivo de almacenamiento basado en.
Archivos basados en Storage
Presenta los tipos de almacenamiento basadas en el apoyo de Red
Hat Enterprise Virtualization son NFS y el almacenamiento local de
los hosts.
55
Bloque de almacenamiento basado en Storage
Almacenamiento Block utiliza dispositivos de bloque sin formato.
Los dispositivos de bloque se agrupan en grupos de volúmenes por
el gestor de volúmenes lógicos (LVM). Una instancia de LVM se
ejecuta en todos los equipos, tanto de las instancias que se
ejecutan en otros sistemas. VDSM añade lógica de agrupamiento
en la parte superior de LVM mediante el escaneo de los grupos de
volúmenes para los cambios. Cuando se detectan cambios,
actualizaciones VDSM hosts individuales diciéndoles que actualicen
su información de grupo de volúmenes. Los anfitriones dividen el
grupo de volumen en volúmenes lógicos, escribir metadatos
volumen lógico en el disco. Si se añade más capacidad de
almacenamiento a un dominio de almacenamiento existente, el Hat
Enterprise Virtualization Red provoca VDSM en cada host para
actualizar la información del grupo de volúmenes.
Un número de unidad lógica (LUN) es un dispositivo de bloque
individual. Uno de los protocolos de almacenamiento de bloques
soportados, iSCSI, FCoE o SAS, se utiliza para conectarse a un
LUN. Red Hat Enterprise Virtualization Manager gestiona
conexiones iSCSI de software para el LUN. Todas las demás
conexiones de almacenamiento de bloque se gestionan
externamente al entorno Red Hat Enterprise Virtualization.
56
Cualquier cambio en un entorno de almacenamiento basado en
bloques, tales como la creación de volúmenes lógicos, ampliación o
eliminación de volúmenes lógicos y la adición de un nuevo LUN son
manejadas por LVM en un host seleccionado especialmente
llamado gestor de la agrupación de almacenamiento. Cambios se
sincronizan por VDSM que actualiza los metadatos de
almacenamiento en todos los hosts del clúster
2.5.4. TIPOS DE DOMINIO DE STORAGE
Imagen 6 (Tipos de almacenamiento “Storage”)
Fuente: (RedHat, 2013)
En la Imagen N° 6, (Tipos de almacenamiento “Storage”) muestra los tres
tipos de dominios de almacenamiento y el tipo de almacenamiento de
cada dominio soportes de almacenamiento, que son:
57
El dominio de almacenamiento (Data Storage):de datos
almacena las imágenes de disco duro de todas las máquinas
virtuales en el entorno de Red Hat Enterprise Virtualization. Las
imágenes de disco pueden contener un sistema operativo instalado
o los datos almacenados o generados por una máquina virtual.
Como se muestra en la Figura 3.1, "Almacenamiento T ipos", los
datos de almacenamiento dominios soporte NFS, iSCSI y FCP, y el
almacenamiento compatible con POSIX. Un dominio de datos no
puede ser compartido entre múltiples centros de datos. Además, se
requiere que el centro de datos y el dominio de almacenamiento de
datos utilizan el mismo protocolo (por ejemplo, ambos deben estar
basada en iSCSI).
La Exportar dominio de almacenamiento (Export Storage):
proporciona almacenamiento transitorio para imágenes de disco
duro y las plantillas de máquinas virtuales que se transfieren entre
los centros de datos. Además, los dominios de almacenamiento
exportación almacenan una copia de seguridad copias de máquinas
virtuales. Como se muestra en la Figura 3.1, "T ipos de
almacenamiento", el almacenamiento dominios soporte de
almacenamiento de exportación NFS. Los centros de datos
múltiples pueden acceder a un solo dominio de almacenamiento
exportación pero sólo un centro de datos pueden utilizarlo a la vez.
58
La archivos ISO ISO Almacenamiento dominio tiendas (ISO
Storage), también llamada imágenes. Los archivos ISO son
representaciones de CDs físicos o DVD. En el entorno de Red Hat
Enterprise Virtualization los tipos comunes de archivos ISO son
discos de instalación del sistema operativo, los discos de
instalación de aplicaciones y los discos de instalación del agente
invitados. T stas imágenes se pueden conectar a las máquinas
virtuales y arrancan de la misma manera que los discos físicos se
insertan en una unidad de disco y arrancan. Como se muestra en la
Figura 3.1, "Almacenamiento T ipos", almacenamiento ISO
dominios sólo admite el almacenamiento NFS. ISO dominios de
almacenamiento permiten a todos los hosts dentro deel centro de
datos para compartir ISO, eliminando la necesidad de medios
ópticos físicos.
2.5.5. FORMATOS DE ALMACENAMIENTO DE MÁQUINA
VIRTUAL DE IMÁGENES DE DISCO
Qcow2 formato de almacenamiento de máquina virtual
Qcow2 es un formato de almacenamiento de imágenes de disco de
máquinas virtuales. Qcow significa copia QEMU en escritura. L a
formato qcow2 desacopla la capa de almacenamiento físico de la
59
capa virtual mediante la adición de un mapeo entre bloques lógicos y
físicos. Cada bloque de lógica se asigna a su desplazamiento físico,
que permite el almacenamiento de-COMPROMISO y las instantáneas
de la máquina virtual, donde cada volumen qcow sólo representa los
cambios realizados en una imagen de disco subyacente.
Los puntos de mapeo inicial todos los bloques lógicos a las
compensaciones en el fichero de respaldo o volumen. Cuando una
máquina virtual escribe datos en un volumen qcow2 después de una
instantánea, el bloque pertinente se lee desde el volumen de respaldo,
modificado con la nueva información por escrito y en una nueva
instantánea qcow2 volumen. Entonces el mapa se actualiza para que
apunte al nuevo lugar
RAW
E l formato de almacenamiento de crudo tiene una ventaja de
rendimiento sobre qcow2 en ese formato no se aplica a las imágenes
de disco de máquinas virtuales almacenadas en el formato RAW.
Operaciones de datos de máquinas virtuales sobre imágenes de disco
almacenados en formato RAW requiere ningún trabajo adicional de los
ejércitos. Cuando una máquina virtual escribe datos en un
determinado desplazamiento en su disco virtual, el I / O se escribe en
el mismo desplazamiento en el fichero de respaldo o un volumen
lógico.
60
Formato RAW requiere que todo el espacio de la imagen definida se
asigna previamente a menos que use gestionado externamente
delgada LUN provisionada de una matriz de almacenamiento.
2.5.6. IMAGEN DE DISCO POLÍTICAS DE ASIGNACIÓN DE
ALMACENAMIENTO DE MÁQUINA VIRTUAL
almacenamientos pre asignados
Todo el almacenamiento necesario una imagen de disco de máquina
virtual se asigna antes de la creación de la máquina virtual. Si se crea
una imagen de disco de 20 GB para una máquina virtual, la imagen de
disco utiliza 20 GB de capacidad de dominio de almacenamiento.
Imágenes de disco pre asignados no se pueden ampliar. La pre
asignación de almacenamiento puede significar más rápido debido a
tiempos de escritura sin asignación de almacenamiento se lleva a
cabo durante el tiempo de ejecución, a costa de la flexibilidad. La
asignación de almacenamiento de esta manera se reduce la
capacidad de la Hat Enterprise Virtualization Red de almacenamiento
a través de confirmación. Almacenamiento pre reservado se
recomienda para máquinas virtuales utilizadas para alta intensidad de
I / O tareas con menos tolerancia a la latencia en el almacenamiento.
61
En general, las máquinas virtuales del servidor ajustan a esta
descripción.
Almacenamiento Escasamente Numerado
El límite superior de tamaño una imagen de disco de máquina virtual
se configura durante la creación de la máquina virtual. Inicialmente, la
imagen de disco no utiliza ningún tipo de capacidad de dominio de
almacenamiento. Uso crece a medida que la máquina virtual escribe
datos en el disco, hasta que se alcanza el límite superior. La
capacidad no se devuelve al dominio de almacenamiento cuando se
eliminan datos en la imagen del disco. Baja densidad de
almacenamiento asignado es adecuado para máquinas virtuales con
baja o media intensidad de I / O tareas con cierta tolerancia para la
latencia en el almacenamiento. En general, las máquinas virtuales de
escritorio ajustan a esta descripción.
2.5.7. STORAGE DOMAIN AUTORECOVERY EN RED HAT
ENTERPRISE VIRTUALIZATION
Hosts en un Red Enterprise Virtualization environtment dominios de
almacenamiento del monitor Hat en sus centros de datos mediante la
lectura de los metadatos de cada dominio. Un dominio de
almacenamiento se desactiva cuando todos los hosts en un informe del
centro de datos que no pueden acceder al dominio de almacenamiento.
62
Antes de Red Hat Enterprise Virtualization 3.1, dominios de
almacenamiento que se hicieron inactivos fueron desconectados por el
Gerente. Reconexión de almacenamiento cuando los problemas de
conexión han sido resueltos necesaria la intervención manual del
administrador.
Red Hat Enterprise Virtualization 3.1 introdujo dominio de recuperación
automática de almacenamiento. En lugar de desconectar un dominio de
almacenamiento inactivo, el Manager ahora se supone que el dominio de
almacenamiento se ha convertido en inactivo temporalmente debido a
una interrupción temporal de la red, por ejemplo. Una vez cada 5
minutos, el entrenador intenta reactivar los dominios de almacenamiento
inactivos.
La intervención del administrador puede ser necesario para poner
remedio a la causa de la interrupción de la conectividad de
almacenamiento, pero el Manager maneja dominios de almacenamiento
re-activadores como se restablezca la conectividad.
2.5.8. GESTOR DE AGRUPACIONES DE ALMACENAMIENTO
En la Imagen N° 7 muestra que un Storage Manager escribe
exclusivamente Metadatos estructurales.
63
Red Hat Enterprise Virtualization utiliza los metadatos para describir la
estructura interna de los dominios de almacenamiento. Los metadatos
estructurales escriben en un segmento de cada dominio de
almacenamiento. Hosts trabajar con los metadatos dominio de
almacenamiento basado en un único escritor, y la configuración de
múltiples lectores. Almacenamiento dominio metadatos estructurales
rastrea imagen y captura creación y supresión, y el volumen y la
extensión de dominio.
La Red Hat Enterprise Virtualization host que puede realizar cambios en
la estructura del dominio de datos que se conoce como la piscina
Storage Manager (SPM). E l SPM coordina todos los cambios de
metadatos en el centro de datos, como la creación y eliminación de
imágenes de disco, crear y fusionar instantáneas, copiar imágenes entre
dominios de almacenamiento, la creación de plantillas y la asignación de
almacenamiento para dispositivos de bloque. Hay una SPM para cada
centro de datos. Todos los demás hosts sólo pueden leer de
almacenamiento de metadatos estructurales dominio.
La Red Hat Enterprise Virtualization Manager asigna el papel SPM ,
causando un posible anfitrión SPM para tratar de asumir un contrato de
almacenamiento -céntrica. E l arrendamiento permite que el anfitrión
SPM para escribir metadatos de almacenamiento. Es el almacenamiento
centrado, ya que se escribe en el dominio de almacenamiento en lugar
64
de ser seguido por el Administrador o hosts. Arrendamientos
Almacenamiento centrados se escriben en un volumen lógico especial en
el dominio de almacenamiento maestro llamado arrendamientos. Los
metadatos acerca de la estructura del dominio de los datos se escriben
en un volumen lógico especial llamado metadata. Los cambios en el
volumen lógico metadata están protegidos contra por el volumen lógico
arrendamientos.
El Manager utiliza VDSM emitir el comando spm Start a un host,
provocando VDSM en ese host para tratar de asumir el contrato de
almacenamiento -céntrica. Si el host tiene éxito, se convierte en el SPM y
conserva el contrato de almacenamiento centrada hasta que los de Red
Hat Enterprise Virtualization Manager solicita que un nuevo huésped
asumir el papel de SPM.
E l Director mueve el papel SPM a otro host si:
El anfitrión SPM no puede acceder a todos los dominios de
almacenamiento, pero se puede acceder al dominio de
almacenamiento principal.
El anfitrión SPM no puede renovar el contrato debido a una pérdida de
conectividad de almacenamiento o el contrato de arrendamiento
volumen está lleno y no hay operación de escritura se puede realizar.
los accidentes de acogida SPM.
65
2.5.9. SNAPSHOT
Los Snapshots son una función de almacenamiento que permite a un
administrador crear un punto de sistema de una máquina virtual
operativo, aplicaciones y datos en un cierto punto en el tiempo de
restauración. Instantáneas de guardar los datos actualmente presentar
una imagen del disco duro de la máquina virtual en un volumen COW y
permitir una recuperación de los datos, tal como existía en el momento
se tomó la instantánea. Una instantánea hace que una nueva capa de la
VACA de ser creado a lo largo de la capa actual. Todas las acciones de
escritura realizados después se toma una instantánea se escribe en la
nueva capa de la VACA.
Imagen N° 7 (El grupo de Storage Manager escribe exclusivamente Metadatos estructurales)
Fuente: (RedHat, 2013)
66
Es importante entender que una imagen de disco duro de la máquina
virtual es una cadena de uno o más volúmenes. Desde la perspectiva de
una máquina virtual, estos volúmenes aparecen como una imagen de
disco único. Una máquina virtual es ajeno al hecho de que su disco se
compone de varios volúmenes.
El volumen COW plazo y la capa de la VACA se utilizan indistintamente,
sin embargo, la capa se reconoce más claramente la naturaleza temporal
de las instantáneas. Cada instantánea se ha creado para permitir a un
administrador para descartar los cambios realizados en los datos poco
satisfactorios después de que se tomó la instantánea. Snapshots
proporcionan una funcionalidad similar a la función Deshacer presente
en muchos procesadores de texto.
Son tres Snapshots primarios que hay y son:
Creación, que consiste en la primera instantánea creado por una
máquina virtual.
Vista previa, que implica una vista previa instantánea para
determinar si o no para restaurar los datos del sistema en el
momento en que se tomó la instantánea.
Borrado, lo que implica borrar un punto de restauración que ya no
se requiere.
67
2.5.10. SNAPSHOTS EN VIVO EN RED HAT ENTERPRISE
VIRTUALIZATION
De acuerdo con (RedHat, 2013) En la versión 3.1, Red Hat
Enterprise Virtualization introdujo soporte para instantáneas de
máquinas virtuales en ejecución.
Las instantáneas de los discos duros de la máquina virtual
marcados compartible y aquellas que se basan en las conexiones
LUN directos no son compatibles, en directo o de otra
manera.Cualquier otra máquina virtual que no está siendo clonado
o emigraron puede tener una instantánea tomada durante su
ejecución, en pausa o detenido.
Cuando se inicia una instantánea en vivo de una máquina virtual, el
Manager solicita que el anfitrión SPM crear un nuevo volumen de la
máquina virtual para utilizar. Cuando el nuevo volumen está listo, el
Manager utiliza VDSM para comunicarse con libvirt y qemu en el
servidor que ejecuta la máquina virtual que se debe empezar a
utilizar el nuevo volumen de las operaciones de escritura de la
máquina virtual. Si la máquina virtual es capaz de escribir en el
nuevo volumen, la operación de instantánea se considera un éxito y
la máquina virtual deja de escribir en el volumen anterior. Si la
68
máquina virtual no puede escribir en el nuevo volumen, la operación
de instantánea se considera un fracaso, y el nuevo volumen se
elimina.
La máquina virtual requiere acceso tanto a su volumen actual y la
nueva desde el momento en que se inicia una instantánea en vivo
hasta después de que el nuevo volumen está listo, por lo que los
dos volúmenes se abren con la lectura y escritura.
Las máquinas virtuales con un agente de huéspedes que apoya
quiescing instalado puede garantizar la coherencia del sistema de
archivos a través de instantáneas. RHN registradas de Red Hat
Enterprise Linux, los clientes pueden instalar el QEM u- guestagent
para permitir quiescing antes de instantáneas.
Si un agente de cliente compatible quiescing está presente en una
máquina virtual cuando se toma una instantánea, VDSM libvirt
utiliza para comunicarse con el agente de prepararse para una
instantánea. Las acciones en circulación de escritura se han
completado, y luego los sistemas de archivos se congelan antes de
tomar una instantánea. Cuando haya finalizado la fotografía, y libvirt
ha desconectado la máquina virtual para el nuevo volumen de las
69
acciones de escritura de disco, el sistema de archivos se
descongela, y escribe en hoja de vida del disco.
2.5.11. CREACIÓN DE SNAPSHOT
En Red Hat Enterprise Virtualization la instantánea inicial para una
máquina virtual es diferente de instantáneas posteriores en que la
instantánea inicial conserva su formato, ya sea qcow2 o RAW. L a
primera instantánea de una máquina virtual designa volúmenes
existentes como imagen base. Instantáneas adicionales COW
adicionalcapas seguimiento de los cambios realizados en los datos
almacenados en la imagen desde la instantánea anterior.
En Red Hat Enterprise Virtualization, una máquina virtual invitada
habitualmente interactúa una imagen de disco RAW a menos que
se cree la imagen como una imagen aprovisionado o el usuario
solicitó específicamente para que sea qcow2. Como se muestra en
la Imagen N° 8, "Creación instantánea inicial", la creación de una
instantánea hace que los volúmenes que comprenden una imagen
de disco de la máquina virtual para servir como la imagen de la
base para todas las instantáneas subsiguientes.
70
Instantáneas tomadas después de que el resultado inicial de
instantáneas en la creación de nuevos volúmenes de vaca en la
que se toman los datos que se crea o modifica después de la
instantánea se almacena. Cada nueva capa de la VACA comienza
sólo contiene metadatos VACA. Los datos que se crean a través de
uso de la máquina virtual y la operación después de una
instantánea esescrita a una nueva capa de la VACA. Cuando una
máquina virtual se utiliza para modificar los datos que existe en una
capa de la VACA anterior, los datos se leen desde la capa anterior,
y se escribe en la capa más reciente. Las máquinas virtuales
localizar los datos comprobando cada capa de la VACA del más
reciente al más antiguo, de forma transparente a la máquina virtual.
(La Imagen N° 9 muestra cómo se añade un snapshot)
Imagen 8 (Creación de snapshot)
Fuente: (RedHat, 2013)
71
2.5.12. SNAPSHOT PREVIAS
Para seleccionar el snapshot una imagen de disco de máquina
virtual se volvió a, el administrador puede previsualizar todas las
instantáneas creadas previamente.
A partir de las instantáneas disponibles por huésped, el
administrador puede seleccionar un volumen de instantánea para
previsualizar su contenido. Como se muestra en la Imagen N° 10,
"Vista previa Snapshot", cada Snapshot se guarda como un
volumen VACA, y cuando se ve de antemano, una nueva capa de
vista previa se copia de la instantánea de ser visto de antemano. L
os resultados interactúa con la vista previa en lugar del volumen de
instantánea actual.
Imagen N° 9 (Añadir un Snapshot)
Fuente: (RedHat, 2013)
72
Después de las vistas previas de administrador de la instantánea
seleccionada, la vista previa se ha comprometido a restaurar los
datos de clientes para el estado capturado en la instantánea. Si el
administrador se compromete la vista previa, el huésped se une a la
capa de presentación preliminar.
Después de una instantánea es una vista previa, el administrador
puede seleccionar Deshacer para descartar la capa vista previa de
la instantánea visualizada. La capa que contiene la instantánea en
sí se conserva a pesar de la capa previa está descartado.
2.5.13. ELIMINACIÓN DE SNAPSHOTS
Si ya no se requiere una instantánea o una serie de instantáneas, el
administrador puede borrar una o más instantáneas. L a eliminación
Imagen N° 10 (Snapshot)
Fuente: (RedHat, 2013)
73
de una instantánea no causa necesariamente los datos de la
instantánea que desea eliminar. Por ejemplo, si se elimina la
tercera foto de cada cinco instantáneas, los datos sin cambios en la
tercera instantánea deben ser preservados para el cuarto y quinto
instantáneas para ser utilizable. Si se elimina el quinto instantánea
de cada cinco, y luego se descartan los datos que han sido
modificados o creados desde que se tomó la instantánea.
Eliminación instantánea no es una operación para preservar la
capacidad de almacenamiento en el entorno Red Hat Enterprise
Virtualization. Eliminación instantánea permite al administrador
eliminar un posible punto de restauración de datos cuando se hace
evidente que no será necesario volver a los datos de imágenes del
disco duro de la máquina virtual en el momento de la instantánea
conserva.
Cuando el administrador elimina una instantánea, los datos de la
instantánea borrada y la instantánea creada después de la
instantánea borrada se fusionan en un solo volumen VACA.
Después de las dos instantáneas se fusionan, el volumen resultante
contiene los datos que se crearon o modificaron antes de la
instantánea borrada y eliminada después de la instantánea. No hay
datos se ha eliminado, sólo la capacidad de restaurar un punto de
en el tiempo en la vida de la imagen del disco duro de la máquina
virtual. Como aparece en la Imagen N° 11, "borrar Snapshots", foto
74
2 se ha seleccionado para su eliminación. Como consecuencia de
ello, instantánea 2 y 3 instantánea se fusionan, el ahorro de los
cambios tanto en las instantáneas en el volumen de la vaca por
instantánea 3 (es decir, la instantánea más reciente) como el
reemplazo para la instantánea suprimido.
2.6. CLUSTER
De acuerdo a (RedHat, 2013) un clúster se un conjunto de dos o más equipos
(llamados nodos o miembros) que trabajan juntos para realizar una tarea. Hay
cuatro tipos principales de grupos:
Imagen N° 11 (Borrar Snashots)
Fuente: (RedHat, 2013)
75
Agrupaciones de almacenamiento ofrecen una imagen del
sistema de archivos consistente a través de los servidores de un
clúster, permitiendo a los servidores a leer y escribir al mismo
tiempo a un solo sistema de archivos compartidos. Un clúster de
almacenamiento simplifica la administración del almacenamiento
mediante la limitación de la instalación y parches de aplicaciones
para un sistema de archivos. Además, con un sistema de archivos
en todo el clúster, un grupo de almacenamiento elimina la
necesidad de copias redundantes de datos de la aplicación y
simplifica la copia de seguridad y recuperación de desastres. Red
Hat Cluster Suite proporciona agrupación de almacenamiento a
través de Red Hat GFS.
Grupos de alta disponibilidad proporcionan disponibilidad
continua de los servicios mediante la eliminación de los puntos de
fallo y al no haber más servicios de un nodo de clúster a otro en
caso de que un nodo deja de funcionar. Por lo general, los servicios
de un clúster de alta disponibilidad de lectura y escritura de datos (a
través de los sistemas de archivos de lectura y escritura montados)
. Por lo tanto, un clúster de alta disponibilidad debe mantener la
integridad de los datos como un nodo de clúster toma el control de
un servicio a otro nodo del clúster. Fallos de nodos de un clúster de
alta disponibilidad no es visible desde clientes fuera del clúster.
76
(Clusters de alta disponibilidad se refieren a veces como
agrupaciones de conmutación por error ) Red Hat Cluster Suite
proporciona alta disponibilidad, clustering a través de su alta
disponibilidad de los componentes de gestión de servicios.
Agrupaciones de equilibrio de carga despachar las solicitudes de
servicio de red a varios nodos del clúster para equilibrar la carga de
solicitudes entre los nodos del clúster. El equilibrio de carga
proporciona escalabilidad rentable, ya que puede coincidir con el
número de nodos de acuerdo a las necesidades de carga. Si un
nodo en un clúster de equilibrio de carga deja de funcionar, el
software de equilibrio de carga detecta el fallo y vuelve a dirigir
peticiones a otros nodos del clúster. Fallos de nodos de un clúster
de equilibrio de carga no es visible desde clientes fuera del clúster.
Red Hat Cluster Suite proporciona equilibrio de carga a través de
LVS (Linux Virtual Server )
Clusters de alto rendimiento utilizan los nodos del clúster para
realizar cálculos simultáneos. Un clúster de alto rendimiento
permite a las aplicaciones para trabajar en paralelo, por lo tanto,
mejorar el rendimiento de las aplicaciones. (Grupos de alto
rendimiento también se conocen como grupos computacionales o
informáticas rejilla)
77
2.6.1. CLUSTER DE ALTA DISPONIBILIDAD
En lo que respecta a cluster de acuerdo con (Hat, Red Hat Enterprise
Linus 6.2 RH436, 2012) Para conseguir redundancia y protección contra
fallos de un sistema, la primera de las medidas que se suelen tomar es
replicar sus componentes hardware más crítico. Por ejemplo en el caso de
un servidor se emplean configuraciones de discos en RAID, fuentes de
alimentación redundantes, varias interfaces de red en bonding, etc. Y el
mismo concepto de redundancia se aplica también para el resto de
componentes como la electrónica de red o el sistema eléctrico.
Estas medidas indudablemente aumentan el nivel de disponibilidad de un
sistema, pero para conseguir un nivel aúnmás alto, se suelen utilizar
configuraciones avanzadas de hardware y software como son los clusters
de Alta Disponibilidad.
Un Cluster de Alta Disponibilidad es un conjunto de dos o más servidores,
que se caracteriza por compartir el sistema de almacenamiento, y por qué
están constantemente monitorizándose entre sí. Si se produce un fallo del
hardware o de los servicios de alguno de las máquinas que forman el
cluster, el software de alta disponibilidad es capaz de re arrancar
automáticamente los servicios que han fallado en cualquiera de los otros
78
equipos del cluster. Y cuando el servidor que ha fallado se recupera, los
servicios se migran de nuevo a la máquina original.
Esta capacidad de los clusters de restablecer en pocos segundos un
servicio, manteniendo la integridad de los datos, permite que en muchos
casos los usuarios no tengan por qué notar que se ha producido un
problema. Cuando una avería de este tipo, en un sistema sin cluster,
podría dejarles sin servicio durante horas.
La utilización de clusters no solo es beneficiosa para caídas de servicio no
programadas, sino que también es útil en paradas de sistema
programadas como puede ser un mantenimiento hardware o una
actualización software.
En general las razones para implementar un cluster de alta disponibilidad
son:
Aumentar la disponibilidad
Mejorar el rendimiento
Escalabilidad
Tolerancia a fallos
Recuperación ante fallos en tiempo aceptable
Reducir costes
Consolidar servidores
79
Consolidar el almacenamiento
2.6.1.1. CONFIGURACIONES DE ALTA DISPONIBILIDAD
Las configuraciones más comunes en entornos de clusters
de alta disponibilidad son la configuración activo/activo y la
configuración activo/pasivo.
Configuración Activo/Activo
En una configuración activo/activo, todos los
servidores del cluster pueden ejecutar los mismos
recursos simultáneamente. Es decir, los servidores
poseen los mismos recursos y pueden acceder a
estos independientemente de los otros servidores del
cluster. Si un nodo del sistema falla y deja de estar
disponible, sus recursos siguen estando accesibles a
través de los otros servidores del cluster.
En la Imagen N° 12 se muestra como ambos
servidores están activos, proporcionando un mismo
servicio a los diferentes usuarios. Los clientes
acceden al servicio o recursos de forma transparente
y no tienen conocimiento de la existencia de varios
servidores formando un cluster.
80
Configuración Activo/Pasivo
Un cluster de alta disponibilidad, en una configuración
activo/pasivo, consiste en un servidor que posee los
recursos del cluster y otros servidores que son
capaces de acceder a esos recursos, pero no los
activan hasta que el el propietario de los recursos ya
no esté disponible.
Las ventajas de la configuración activo/pasivo son que
no hay degradación de servicio y que los servicios
solo se reinician cuando el servidor activo deja de
responder. Sin embargo, una desventaja de esta
configuración es que los servidores pasivos no
proporcionan ningún tipo de recurso mientras están en
Imagen N° 12 (Arquitectura Activo / Activo)
Fuente: (RedHat, 2013)
81
espera, haciendo que la solución sea menos eficiente
que el cluster de tipo activo/activo. Otra desventaja es
que los sistemas tardan un tiempo en migrar los
recursos (failover) al nodo en espera. En la Imagen N°
13 se muestra un ejemplo de servidores activo y
pasivo.
2.6.1.2. FUNCIONAMIENTO DE UN CLUSTER DE ALTA
DISPONIBILIDAD
En un cluster de alta disponibilidad, el software de cluster
realiza dos funciones fundamentales. Por un lado
intercomunica entre sí todos los nodos, monitorizando
continuamente su estado y detectando fallos. Y por otro lado
administra los servicios ofrecidos por el cluster, teniendo la
Imagen N° 13 (Arquitectura Activo / Pasivo)
Fuente: (RedHat, 2013)
82
capacidad de migrar dichos servicios entre diferentes
servidores físicos como respuesta a un fallo.
A continuación se describen los elementos y conceptos básicos
en el funcionamiento del cluster.
Recurso y Grupos de Recursos
Tradicionalmente se entiende como servicio a un
conjunto de procesos que se ejecutan en un momento
dado sobre un servidor y sistema operativo. Este
último provee a los procesos de los recursos
necesarios para realizar su tarea: sistema de ficheros,
interfaces de red, tiempo de cpu, memoria, etc.
En un cluster de alta disponibilidad, el software de
cluster, abstrae e independiza a los servicios de un
host concreto. Posibilitando que estos se desplacen
entre diferentes servidores de forma trasparente para
la aplicación o los usuarios.
El software de cluster permite definir grupos de
recursos, que son todos aquellos recursos necesarios
por el servicio. Estos recursos serán los scripts de
arranque del servicio, un sistema de ficheros, una
dirección IP, etc. En la Imagen N° 14 se muestra los
recursos de un cluster.
83
Intercomunicación
El software de cluster gestiona servicios y recursos en
los nodos. Pero además, tiene que mantener
continuamente entre estos una visión global de la
configuración y estado del cluster. De esta forma, ante
el fallo de un nodo, el resto conoce que servicios se
deben restablecer.
Ya que la comunicación entre los nodos del cluster es
crucial para el funcionamiento de este, es habitual
utilizar un canal específico como una red IP
independiente o una conexión serie,que no se pueda
Imagen 14 (Recurso y grupo de recursos)
Fuente: (RedHat, 2013)
84
ver afectada por problemas de seguridad o
rendimiento.
Heartbeat
El software de cluster conoce en todo momento la
disponibilidad de los equipos físicos, gracias a la
técnica de heartbeat. El funcionamiento es sencillo,
cada nodo informa periódicamente de su existencia
enviando al resto una “señal de vida”.
Escenario Split-Brain
En un escenario split-brain, más de un servidor o
aplicación pertenecientes a un mismo cluster intentan
acceder a los mismos recursos, lo que puede causar
daños a dichos recursos. Este escenario ocurre
cuando cada servidor en el cluster cree que los otros
servidores han fallado e intenta activar y utilizar dichos
recursos.
Monitorización de Recursos (Resource Monitoring)
Ciertas soluciones de clustering HA permiten no solo
monitorizar si un host físico está disponible, también
pueden realizar seguimientos a nivel de recursos o
servicios y detectar el fallo de estos.
85
El administrador puede configurar la periodicidad de
estos monitores así como las acciones a llevar a cabo
en caso de fallo.
Reiniciar Recursos
Cuando un recurso falla, la primera medida que toman
las soluciones de cluster es intentar reiniciar dicho
recurso en el mismo nodo. Lo que supone detener una
aplicación o liberar un recurso y posteriormente
volverlo a activar.
Algunas implementaciones no permiten reiniciar un
único recurso, y lo que realizan es un reinicio
completo de todo un grupo de recursos (servicio). Esto
puede llegar a demorar bastante para servicios como
las bases de datos.
Migración de Recursos (Failover)
Cuando un nodo ya no está disponible, o cuando un
recurso fallido no se puede reiniciar satisfactoriamente
en un nodo, el software de cluster reacciona migrando
el recurso o grupo de recursos a otro nodo disponible
en el cluster.
86
De este modo el tiempo de inactividad por el posible
fallo es mínimo, y el cluster seguirá proporcionando el
correspondiente servicio. (véase Imagen N° 15)
Dependencia entre recursos
Habitualmente para que el cluster proporcione un
servicio, son necesarios no solo un recurso si no
varios (ip virtual, sistema de ficheros, proceso), lo que
se conoce como grupo de recursos. Cuando se
arranca o detiene un servicio, sus recursos tienen que
activarse en el orden apropiado ya que unos
dependen de otros. El software de cluster tiene que
Imagen 15 (migración de servicio)
Fuente: (RedHat, 2013)
87
permitir definir estas dependencias entre recursos así
como entre grupos.
Preferencia de Nodos (Resource Stickiness)
En configuraciones de cluster con múltiples nodos, es
común distribuir los servicios a proporcionar entre los
diferentes servidores. Además puede que los
servidores tengan características hardware diferentes
(cpu, memoria ram) y nos interese que, para un
estado ideal del cluster, determinados servicios se
ejecuten siempre en un determinado servidor.
Este comportamiento se define mediante la
preferencia de nodo en la definición de cada recurso.
Comunicación con otros sistemas
El cluster tiene que monitorizar no solo que un
servidor y sus servicios están activos, también debe
de comprobar que, de cara a los usuarios, dicho
servidor no queda desconectado de la red por el fallo
de un latiguillo, switch, etc.
Por lo tanto el software de cluster debe comprobar
que los nodos son alcanzables. Un método simple
para conseguirlo, es verificar que cada nodo tiene
88
accesible el router o puerta de enlace de la red de
usuarios.
Fencing
En los clusters HA existe una situación donde un nodo
deja de funcionar correctamente pero todavía sigue
levantado, accediendo a ciertos recursos y
respondiendo peticiones. Para evitar que el nodo
corrompa recursos o responda con peticiones, los
clusters lo solucionan utilizando una técnica llamada
Fencing.
La función principal del Fencing es hacerle saber a
dicho nodo que está funcionando en mal estado,
retirarle sus recursos asignados para que los atiendan
otros nodos, y dejarlo en un estado inactivo.
Quorum
Para evitar que se produzca un escenario de Split-
Brain, algunas implementaciones de cluster HA
introducen un canal de comunicación adicional que se
emplea para determinar exactamente que nodos están
disponibles en el cluster y cuáles no. Tradicionalmente
se implementa utilizando los llamados quorum
devices, que habitualmente son un volumen de
almacenamiento compartido exclusivo (disk heart
beating). También existen implementaciones que
89
utilizan unas conexiones de red adicional o una
conexión serie. Esta última tiene limitaciones de
distancia y actualmente ha quedado en desuso. En la
Imagen N° 16 se muestra el canal de comunicación.
Imagen 16 (Canal de comunicación)
Fuente: (RedHat, 2013)
2.7. METODOLOGIA DE GESTION DE PROYECTOS
Dentro de la metodología utilizada en la gestión de proyectos según (Rita
Mulcahy, 2011) el desarrollo de éstos se estructura en tres fases:
2.7.1. FASE DE INICIO Y PLANIFICACIÓN
Tiene como objetivo fundamental establecer y concretar el ámbito,
calendario, presupuesto, recursos, etc. del proyecto hasta el nivel que
permita al Responsable de Proyecto gestionar eficazmente y articular las
actividades que conducen al éxito del proyecto.
90
2.7.2. FASE DE EJECUCIÓN Y CONTROL
Fase que comprende la gestión del cambio, el seguimiento y control del
proyecto, el análisis y el reporting. Se lleva a cabo el seguimiento de la
planificación asegurando el cumplimiento de todos los hitos y gestionando
los cambios mediante la actualización de la Planificación de Proyectos y la
comunicación a todos los implicados.
2.7.3. FASE DE CIERRE DE PROYECTO
El objetivo fundamental es formalizar la aceptación final del proyecto,
asegurándose una correcta transmisión del conocimiento a los usuarios
recopilando la documentación final, así como la organización de la salida
del equipo de trabajo de una manera ordenada y secuencial.
91
CAPITULO III
METODOLOGIA
3.1. DEFINICION
De acuerdo con (SUNAT, 2013) la Metodología de Gestión de proyectos
(MGP) se basa en el marco metodológico de IDEA (4 fases o estados
secuenciales en el tiempo por los que pasa un proyecto a lo largo de su
existencia: INICIO, DESARROLLO, ESTABILIZACION y APRENDIZAJE)
y prescribe conceptos aplicables a diferentes tipos de proyectos
relacionados con la optimización empresarial, expresada desde el punto
de vista de proyectos de cambio. Asimismo, establece un lenguaje común
y una base conceptual útil para los diversos proyectos de la organización y
permite organizar técnicas y conceptos provenientes de diversas fuentes.
Entiéndase por Proyecto al conjunto de actividades planificadas para
producir resultados en un tiempo mayor a 20 días hábiles.
IDEA cumple con dos requisitos básicos:
• Simplicidad, porque sólo enfoca aspectos básicos con relación a
métodos.
92
• Adaptabilidad, porque es independiente de las herramientas
metodológicas y del software a aplicar.
IDEA también cuenta con dimensiones o tipo de labores del proyecto, no
secuenciales en el tiempo, que se ejecutan en paralelo a lo largo de todas
las fases del proyecto:
• GESTIÓN: Ámbito de acción relativo al liderazgo, administración del
proyecto y manejo de aspectos psicosociales. Tiene a su vez
dos sub dimensiones:
PLANEAMIENTO: Programar y coordinar las actividades, de
manera que se realicen tal como fueron
proyectadas.
CONTROL: Supervisar y evaluar las actividades
planificadas.
• EJECUCIÓN: Ámbito relativo a la materialización de la solución. Tiene a
su vez dos sub dimensiones:
MODELAMIENTO: Representación de la solución que se espera
construir.
CONSTRUCCIÓN: Concretar físicamente la solución.
(SUNAT, 2013) Muestra las siguientes faces:
FASE DE INICIO: En el cual se aprueba la formulación de
proyectos y se convoca a una reunión de lanzamiento.
93
FASE DE DESARROLLO: Tiene 5 actividades con el que se
realiza todo tipo de proyecto las cuales son:
o Modelamiento de la solución.
o Construcción de la solución.
o Aprobación interna de la calidad de la solución.
o Certificación de la calidad por parte del usuario.
o Implementación de la solución.
FASE DE ESTABILIZACIÓN: La cual se subdivide en lo siguiente:
o Seguimiento y mejoras a la solución implantada
o Reunión de Cierre
FASE DE APRENDIZAJE: Es la fase en donde se evalúan a los
usuarios, se hace un interacción con los trabajadores y los pasos
son:
o Evaluación con usuarios finales.
o Reunión de evaluación con los Participantes del Proyecto.
o Elaboración del Informe Final del Proyecto.
Sin embargo (Rita Mulcahy, 2011) menciona 5 etapas y segun (GEDPRO,
2013) son las siguientes:
INICIACION: El proceso de Iniciación es el primer proceso en el
ciclo de vida de Gestión del Proyecto. En este proceso se define el
proyecto, necesidades del negocio, justificación del proyecto,
descripción, alcance y entregables quedan reflejados en el Acta de
Constitución del Proyecto
94
El Project Manager desarrolla el Acta de Constitución del Proyecto,
que la aprueba el Sponsor del Proyecto
El siguiente paso es Crear Acta de Constitución del Proyecto
PLANIFICACION: Durante el proceso de Planificación se
desarrolla el Plan de Gestión del Proyecto. En este proceso se
identifica y define el alcance, las actividades los costes y se
planifica el cronograma del proyecto.
El Project Manager desarrolla Plan de Gestión del
Proyecto que lo aprueba el Sponsor del Proyecto
En este proceso el Project Manager define:
Alcance
Entregables
Estructura Desagregada de Tareas (WBS/EDT)
Costes
Calidad
Recursos
Comunicaciones
Riesgos
Compras
Organización del Proyecto
El siguiente paso es crear o modificar el Plan de
Gestión del Proyecto
EJECUCION Y CONTROL: Durante el proceso de Ejecución y
Control se lleva a cabo el trabajo definido en el Plan de Gestión del
Proyecto.
95
El Project Manager dirige y gestiona la
ejecución del proyecto asegurando el nivel
de calidad exigido en los requerimientos del
proyecto.
En este proceso el Project Manager:
Adquiere el Equipo del Proyecto
Ejecuta el Plan de Compras
Elabora los Informe de Estado del
Proyecto
Recopila las Petición de Cambios
Identifica las Acciones Correctoras y
las Acciones Preventivas
GESTION DE CAMBIOS DEL PROYECTO: En el proceso de
Gestión de Cambios del Proyecto es cuando se aprueban o
rechazan las Petición de Cambios, las Acciones Correctoras y
las Acciones Preventivas.
El Project Manager propone los cambios, las acciones correctivas y
preventivas que tienen que ser aprobadas o rechazadas por
el Sponsor del Proyecto
CIERRE: El proceso de Cierre es la fase en la que se finaliza el
proyecto formalmente.
En este proceso se chequea que el Producto, Servicio, Resultado
Final cumple los objetivos del proyecto y que el Sponsor del
Proyecto está satisfecho con el resultado. Además, este proceso
también chequea que el contrato con el cliente y con los
proveedores están cerrados y conformes.
El siguiente paso es Cerrar Proyecto
96
CAPITULO IV
DESARROLLO
4.1. NOMBRE DE LA EMPRESA
“TIENDAS SODIMAC”
4.2. NOMBRE DEL PROYECTO
DESPLIEGUE DE UNA PLATAFORMA VIRTUAL DE SERVIDORES EN
SODIMAC CON RED HAT ENTERPRISE VIRTUALIZATION (RHEV).
4.3. INTRODUCCIÓN
La necesidad de mantener la información disponible en todo momento y
que ésta no corra riesgo de perderse, borrarse con cualquier caída de un
servidor es primordial para tiendas SODIMAC,ya que existe solo una
central de todas las 10 tiendas en el cual un servidor principal (caja)se
encarga de guardar toda información económica y de vital importancia.
Actualmente SODIMAC cuenta con dos servidores con diferentes
sistemas operativos, Windows server y Red Hat Enterprise Linux, en el
97
cual y también un sistema de cuentas para el manejo económico de la
entidad, por otra parte cuenta con otro servidor donde está instalado el
sistema operativo Proxmox en el cual también se están ejecutando otros
servidores propios del sistema.
El problema radica cuando el servidor de cuentas tiene una interrupción,
ya sea por fallas atmosféricas, falta de energía, accidentes de cualquier
tipo y la recuperación de datos se demora minutos pero aun así es mucho
tiempo para que el personal pueda conectarse con el servidor, esto
genera perdida de dinero y tiempo.
4.4. ACTA DE CONSTITUCION DEL PROYECTO
4.4.1. DESCRIPCIÓN DEL PROYECTO
Durante los últimos dos meses se observó que la caída de
servidores es muy frecuente debido a diferentes
acontecimientos tanto naturales como causados por el
mismo personal del área de Informática, por consecuencia
los usuarios que interactúan con la base de datos de caja
en momentos han tardado mucho tiempo en ingresar los
precios que corresponde a la base de datos. El propósito
del proyecto es mantener activo los servidores ante
cualquier eventualidad. Para lograr esto es necesario que
estos servidores se ejecuten dentro de una plataforma
virtual con Red Hat Enterprise Virtualization para que de
98
este modo puedan ser administrados y lo más importante
que tengan alta disponibilidad para que si un servidor sufre
algún accidente pueda aun estar funcionando sin
problemas, para que pueda ser factible este desarrollo se
configurarán dos hypervisores que en este caso son los
hosts de los cuales se usaran los recursos físicos,
necesitarán de un manager que se encarga de gestionar los
procesos para que los servidores puedanmantenerse en
funcionamiento, con lo que respecta a la alta disponibilidad
en necesario la presencia de un Storage en donde se
almacenará la configuración y máquinas virtuales que se
crean.
4.4.2. DIRECTOR DEL PROYECTO ASIGNADO Y
NIVEL DE AUTORIDAD
Alberto Vidal es el director de proyectos para este proyecto
y tiene la autoridad para seleccionar a los miembros del
equipo y determinar el presupuesto final del proyecto.
4.4.3. CASO DE NEGOCIO
Este proyecto está siendo realizado para prevenir a
cualquier acontecimiento que exista para que los
servidores de tiendas sodimac tengan caídas
eventualmente.
99
4.4.4. RECURSOS PRE-ASIGNADOS
César Palacios Alberto Vidal están dedicados al proyecto
debido a su experiencia en redes de computadoras,
configuración, instalación y registro de Red Hat Enterprise
Linux, así mismo a la construcción de Cluster en Storage.
Los demás recursos serán seleccionados por el director del
proyecto.
Se cuenta con dos servidores hp (servidor hp proliant dl380
g7 xeon e5640) cabe mencionar que para la virtualización
con RHEV los hipervisores deben tener el mismo hardware,
para el manager se tiene (CPU dual core. 4 GB de memoria
RAM, 50 GB de espacio en disco duro, 1 Network Interface Card
(NIC) con 1 Gbps de ancho de banda como mínimo.
4.4.5. INTERESADOS
Los interesados incluyen a:
Anthony Leguia jefe de Informática de tiendas Sodimac,
César Palacios y Alberto Vidal consultores TI, Juan
Anamaria Gerente de la Consultoria SLA14, y usuarios del
sistema.
14
SLA Software Libre Andino. Consultoria
100
4.4.6. DESCRIPCION DEL PRODUCTO/SERVICIO
Se brindará la Solución de Red Hat Enterprise virtualization
para servidores, diseñada para permitir una virtualización
generalizada del centro de cómputos y lograr un
rendimiento del capital y una eficiencia operativa sin
precedentes. Red Hat Enterprise Virtualization para
Servidores se basa en la plataforma Red Hat Enterprise
Linux en la que confían miles de organizaciones en millones
de sistemas en todo el mundo para sus cargas de trabajo
más críticas. Este producto brindará los siguientes
servicios:
Migración en vivo: Traslade máquinas virtuales de un
host a otro en forma dinámica sin interrumpir el servicio.
Alta disponibilidad: Si falla un host, las máquinas
virtuales se reinician en otro host en forma automática.
Programador de sistemas: Equilibra las cargas de
trabajo en el centro de cómputos mediante la migración
dinámica en vivo de las máquinas virtuales en función
del aprovechamiento y la política de recursos.
101
Ahorro de energía: Durante horas de baja demanda
concentra las máquinas virtuales en un número menor
de hosts para permitir desactivar algunos y lograr así un
ahorro de energía.
Gestor de mantenimiento: Permite efectuar tareas de
mantenimiento en los hosts sin provocar tiempo
improductivo en los guests.
Gestor de imágenes: Genera nuevas máquinas
virtuales a partir de plantillas.
Thin provisioning: Permite la creación de escritorios y
servidores a partir de plantillas almacenando
únicamentelas diferencias entre las nuevas instancias y
las plantillas base, ahorrando así espacio de
almacenamiento.
4.4.7. OBJETIVOS MEDIBLES DEL PROYECTO
El objetivo de este proyecto es mantener activo los
servidores de tiendas sodimac en un 80% para que los
102
usuarios (vendedores del sistema) no tengan ningún
problema con la base de datos de caja.
Cronograma de Hitos: Es el siguiente. (Tabla N°1)
103
ITEM
DESCRIPCION SETIEMBRE
DE
ACTIVIDADES SEM 1 SEM 2 SEM 3 SEM 4
Días L M M J V L M M J V L M M J V L M M J V
1 Realización de Kick off
2 Elaboración de project charter
3 Elaboración de alcance de proyecto *
4 Aprobación de documentos de inicio
5 Verificación de infraestructura
6 Elaboración de lista de requerimientos previos
7 Elaboración de diseño final de plataforma virtual
8 Aprobación de diseño final
9 Aprovisionamiento de máquina virtual para RHEVM
10 Instalación de Sistema Operativo
11 Afinamiento de Sistema Operativo
12 Instalación de Servicio Red Hat Virtualization Manager (RHEVM) *
13 Afinamiento de servicio RHEVM
14 Configuración de Red Hat Hypervisor
15 Implementación de Data center virtual
16 Creación de clúster
17 Configuración de políticas de cluster 18 Creación de máquina virtual de prueba 19 Pruebas de Funcionamiento * 20 Ejecución de plan de pruebas 21 Conformidad de ejecución de pruebas
Tabla N° 1 (Cronograma de Hitos)
Fuente: Elaboración propia
104
4.4.8. REQUISITOS DE APROBACIÓN DEL PROYECTO
El Gerente Juan Anamaria aprobará la lista de riesgo antes
de que continúen los esfuerzos de planificación.
4.5. ALCANCE
4.5.1. LISTA DE REQUISITOS
Virtualizacion: una solución de virtualización
integral con casos de uso para servidores y
escritorios, diseñada para permitir una
virtualización generalizada del centro de cómputos
y lograr un rendimiento del capital y una e_ciencia
operativa sin precedentes.
2 Hypervisores: Un moderno hipervisor basado en
KVM que puede implementarse como hipervisor
básico autónomo (incluido junto con Red Hat
Enterprise Virtualization para Servidores), o bien
como Red Hat Enterprise Linux 5.4 y versiones
posteriores (adquirido por separado) instalado
como host hipervisor.
1 Manager: Un sistema de gestión de la
virtualización de servidores con múltiples
características que ofrece capacidades avanzadas
105
para hosts y guests, inclusive alta disponibilidad,
migración en vivo, gestión de almacenamiento,
programador de sistemas, y más aún.
Alta disponibilidad: Queproporciona servicios de
recuperación bajo demanda después de fallos
entre nodos dentro de un clúster, lo que significa
una alta disponibilidad de las aplicaciones. El
complemento High Availability admite hasta 16
nodos y se puede configurar para la mayoría de
las aplicaciones que utilizan agentes
personalizables, así como para invitados virtuales.
Este complemento también soporta recuperación
después de fallos con aplicaciones fuera de la
plataforma, como Apache, MySQL y PostgreSQL.
Cuando se utiliza el complemento High
Availability, un servicio con alta disponibilidad se
puede recuperar de un nodo a otro sin aparente
interrupción para los clientes del clúster. Además,
el complemento High Availability garantiza la
integridad de los datos cuando un nodo de clúster
toma el control de un servicio de otro nodo de
106
clúster. Para ello, desahucia enseguida a los
nodos del clúster que parecen fallar mediante un
método denominado “fencing” (cercado), que
impide el deterioro de los datos.
4.5.2. ESTRUCUTRA DE DESGLOSE DE TRABAJO
(EDT)
El despliegue del proyecto es el siguiente:
107
Inicio
Realización
de Kick off
Elaboración de
project charter
Elaboración de
alcance de
proyecto
Aprobación de
documentos de
inicio
Planificación
Requerimientos
Previos
Diseño
Elaboración de lista
de requerimientos
previos
Verificación de
infraestructura
Aprobación de diseño
final
Elaboración de
diseño final de
plataforma virtual
Ejecución
Instalación de
Servidor RHEVM
Afinamiento de servicio
RHEVM
Instalación de Servicio
Red Hat Virtualization
Manager (RHEVM)
Afinamiento de Sistema
Operativo
Instalación de Sistema
Operativo
Aprovisionamiento de
máquina virtual para
RHEVM
Configuración de
políticas de cluster
Creación de clúster
Implementación de
Data center virtual
Configuración de Red
Hat Hypervisor
Instalación de Red Hat
Hypervisor
Configuración de Storage
Pruebas de
Funcionamiento
Creación de máquina
virtual de prueba
Elaboración de plan de
pruebas
Ejecución de
plan de pruebas
Conformidad de
ejecución de
pruebas
Elaboración de plan de
pruebas
Ejecución de
plan de pruebas
Conformidad de
ejecución de
pruebas
Elaboración de plan de
pruebas
Ejecución de
plan de pruebas
Conformidad de
ejecución de
pruebas
Elaboración de plan de
pruebas
Ejecución de
plan de pruebas
Elaboración de plan de
pruebas
Ejecución de
plan de pruebas
Conformidad de
ejecución de
pruebas
Elaboración de plan de
pruebas
Ejecución de
plan de pruebas
Conformidad de
ejecución de
pruebas
Elaboración de plan de pruebas
Ejecución de
plan de pruebas
Ejecución de plan
de pruebas
Conformidad de
ejecución de
pruebas
Conformidad de
ejecución de pruebas
Control y seguimiento
Control y seguimiento
Cierre
Transferenci
a de
conocimient
o
Documentación de
cierre
Elaboración de
documento de
Arquitectura final
Aprobación
de acta de
conformidad
Elaboración de documento
de implementación de la
solución
Elaboración de
documento de
implementación
de la solución
DESPLIEGUE DE UNA PLATAFORMA VIRTUAL DE SERVIDORES EN SODIMAC CON RED HAT ENTERPRISE
VIRTUALIZATION (RHEV)
Imagen N° 17 EDT
Fuente: Elaboración propia
108
4.6. EJECUCION DEL PROYECTO
4.6.1. ESPECIFICACIONES DE SERVIDORES
4.6.1.1. COMPONENTES
A continuación en la Tabla N° 2 se mencionan los
componentes de software que hará falta para la
instalación y configuración.
Nombre de Servidor
Hostname Descripción
RHEV manager
Rhevm.sodimacpe.falabella.com
Servidor principal de la solución virtual, el cual administra toda la plataforma virtual
Hypervisores sux.26x1.sodimacpe.falabella.com sux.26x1.sodimacpe.falabella.com
Hypervisores asociados al clúster del entorno virtual
Tabla N° 2 (Componentes)
Fuente: Elaboración propia
4.6.1.2. ARQUITECTURA
La arquitectura que se detalla en la Imagen N° 18
detalla el hardware en la que se instalará y
configurará la plataforma virtual
109
4.6.1.3. ESPECIFICACIONES DE LOS SERVIDORES
A continuación en la tabla N° 3 se detalla el nombre
de los hosts, las direcciones ip, el DNS con el que
trabajaremos y el Gateway
Hostname Dirección IP DNS Gateway
rhevm.sodimacpe.falabella.c om
115.1.10.200 127.0.0.1 115.1.1.1
suc26x1.sodimacpe.falabella .com
115.15.10.10
127.0.0.1 192.168.254.2 115.1.10.200
115.100.10.25 4
suc26x2.sodimacpe.falabella .com
115.15.10.20
127.0.0.1 192.168.254.1 115.1.10.200
115.100.10.25 4
Tabla N° 3 (Especificaciones de los servidores)
Fuente: Elaboración propia
Imagen N° 18 (Arquitectura de solución)
Fuente: (RedHat, 2013)
110
4.6.1.4. DISTRIBUCIÓN DE PARTICIONES POR
SERVIDOR
A continuación en la Tabla N° 4 se detalla las particiones
del manager y los hypervisores.
Nombre Punto de montaje
Tipo de partición
Tamaño Descripción
rhevm
/boot ext4 485 MiB Partición boot
/ ext4 45 GiB Partición del sistema operativo
suc26x1
/ rhev/storage-domain
xfs 251 GiB Partición de storage domain
/rhev/export-domain
xfs 251 GiB Partición de export domain
/rhev/iso-domain
ext4 35 GiB Partición de iso domain
suc26x2
/ rhev/storage-domain
xfs 251 GiB Partición de storage domain
/ rhev/export-domain
xfs 251 GiB Partición de export domain
Tabla N° 4 (Particiones de servidores)
Fuente: Elaboración propia
4.6.1.5. DISTRIBUCIÓN DE MEMORIA POR
SERVIDOR
En la Tabla N° 5 se detalla la distribución de la
memoria Ram.
111
Nombre de servidor Memoria física
asignada
Memoria de intercambio
asignada
rhevm.sodimacpe.falabella.com 2 GiB 4 GiB
suc26x1.sodimacpe.falabella.com 16 GiB 8 GiB
suc26x2.sodimacpe.falabella.com 16 GiB 8 GiB
Tabla N° 5 (distribución de Memoria)
Fuente: Elaboración propia
4.6.2. ESPECIFICACIONES DE LOS SERVICIOS
En el siguiente Tabla N° 6 se especifica las especificaciones que
se deberían tomar en cuenta para la configuración de un servidor
DNS Y un servidor NTP
Nombre de hosts rhevm.sodimacpe.falabella.com
Sistema Operativo Red Hat Enterprise Linux 6.4
Superusuario de sistema operativo
usuario: root contraseña:redhat
Versión software de virtualización instalado
Red Hat Enterprise Virtualization 3.2
Servicios instalados a nivel de Sistema Operativo
Servicio DNS mediante bind Servicio NTP mediante ntpd
Administración vía Línea de comandos
usuario: root contraseña: redhat
Administración web del sistema operativo y servicios
http://115.1.10.200:10000 usuario: root contraseña: redhat
Administración web de la plataforma virtual
http://115.1.10.200 usuario: admin dominio: internal contraseña: f7d8l7d9d
112
Nombre de Host su26x1.sodimacpe.falabella.com
Sistema Operativo Red Hat Enterprise Linux 6.4
Superusuario de sistema operativo
usuario: root contraseña:redhat
Servicios instalados a nivel de Sistema Operativo
Servicio DNS mediante bind Servicio NTP mediante ntpd Servicio Storage mediante glusterfs Servicio de Administración mediante webmin
Administración vía Línea de comandos
usuario: root contraseña: redhat
Administración web del sistema operativo y servicios
http:// 115.15.10.100:10000 usuario: root contraseña: redhat
Nombre de Host hyp2.quito.gob.ec
Sistema Operativo Red Hat Enterprise Linux 6.4
Superusuario de sistema operativo
usuario: root contraseña:redhat
Servicios instalados a nivel de Sistema Operativo
Servicio DNS mediante bind Servicio NTP mediante ntpd Servicio Storage mediante glusterfs Servicio de Administración mediante webmin
Administración vía Línea de comandos
usuario: root contraseña: redhat
Administración web del sistema operativo y servicios
http:// 115.15.10.200:10000 usuario: root contraseña: redhat
Tabla N° 6 (Especificaciones)
Fuente: Elaboración propia
4.6.3. INSTALACION
Este checklist contiene información referida a los ítems básicos
y necesarios para la instalación de software.
ITEM DESCRIPCION
Archivos de instalación de los Productos RHEV 3.2
CD de instalación del Sistema operativo seleccionado.
Lista de pre-requisitos para el sistema operativo donde será instalado el servidor
113
4.6.3.1. INSTALACIÓN DEL S.O. RED HAT 6.4 DE
64 BITS
Iniciamos el boot de la maquina desde el lector de
CD o desde la imagen del instalador para iniciar.
(Imagen N° 19)
Manager.(1)
Subscripción activa del producto RHEV.
Configuración de red IPs que serán asignadas a la arquitectura virtual, así como la información de DNS, gateway y máscara que se asignará al servidor.
Distribución física de almacenamiento Distribución de almacenamiento, luns, Raid, etc.
Requisitos mínimos para el servidor Manager CPU dual core.
4 GB de memoria RAM.
50 GB de espacio en disco duro.
1 Network Interface Card (NIC) con 1 Gbps de ancho de banda como mínimo.
Tabla N° 7 (Requisitos Mínimos)
Fuente: Elaboración propia
114
Imagen N° 19 (inicio de instalación de Red hat)
Fuente: (RedHat, 2013)
Obviamos la comprobación de medios extraíbles para la
instalación como muestra la Imagen N° 20.
Imagen 20 (Test del cd de instalación)
Fuente: (RedHat, 2013)
En la Imagen N° 21 elegimos el idioma de la instalación y el
idioma del teclado, elegís en ambos casos español.
115
Imagen N° 21 (Elegir idioma)
Fuente: (RedHat, 2013)
Elegimos la opción de dispositivos de almacenamiento básico y
le damos click en siguiente. (Imagen N° 22)
Imagen N° 22 (Elegir el dispositivo de almacenamiento)
Fuente: (RedHat, 2013)
116
Escogemos hostname y el dominio, y damos click en siguiente.
Seleccionamos la zona horaria (América/Ecuador) y damos click
en siguiente. (véase Imagen N° 24)
Imagen N° 24 (Elegir el pais)
Fuente: (RedHat, 2013)
Imagen N° 23 Figura 4.7 (Nombre de host)
Fuente: (RedHat, 2013)
117
Indicamos una contraseña para el súper usuario root, por lo
general se le coloca “changeme”, este parámetro puede ser
cambiado más adelante (pero siempre debe tener una).
(Imagen N° 25)
Imagen N° 25 (Añadir de password)
Fuente: (RedHat, 2013)
Seleccionamos la opción de crear un diseño personalizado y
damos click en siguiente. (Imagen N° 26)
118
Imagen 26 (Partición personalizada)
Fuente: (RedHat, 2013)
Se crea una partición estándar la cual albergara al punto de
montaje boot. (Imagen N° 27)
Imagen N° 27 (Crear partición)
Fuente: (RedHat, 2013)
119
Se le configura el punto de montaje, el formato y el espacio a
ocupar y damos click en aceptar. (Imagen N° 28)
Imagen N° 28 (Creando boot)
Fuente: (RedHat, 2013)
Con el espacio libre pasamos a crear los volúmenes físicos para
el LVM. (Imagen N° 29)
Imagen N° 29 (Crear Volumen lógico)
Fuente: (RedHat, 2013)
120
Como tipo de archivo seleccionamos la opción “physical
volumen (LVM)” y también seleccionamos la opción de
completar tamaño hasta máximo aceptable y damos click en
aceptar. (Imagen N° 30)
Imagen N° 30 (Crear Volumen físico)
Fuente: (RedHat, 2013)
Pasamos a crear el Grupo de Volumen LVM sobre el nuevo
Volumen físico creado anteriormente. (Imagen N° 31).
121
Imagen N° 31 (Crear grupo Volumen físico)
Fuente: (RedHat, 2013)
Escribimos el nombre del Volume Group con una extensión
física de 4 MB y seleccionamos los discos que pertenecerán a
dicho grupo. A continuación pasamos a crear los volúmenes
lógicos; les damos formato y especificamos el espacio a usar en
cada uno. (Imagen N° 32)
122
Imagen N° 32 Figura 4.16 (Crear Raiz)
Fuente: (RedHat, 2013)
Para el área de intercambio seleccionamos como sistema de
archivos swap, colocamos el nombre del logical volumen y
especificamos el espacio a usar. (Imagen N° 33)
Imagen N° 33 (Crear swap)
Fuente: (RedHat, 2013)
123
Una vez creado todo el FileSystem con configuración LVM,
damos click en siguiente. (Imagen N° 34)
Imagen N° 34 (File System)
Fuente: (RedHat, 2013)
Dejamos por default la instalación del sector de arranque y
damos Click en siguiente. (Imagen N° 35)
Imagen N° 35 (Sector de arranque)
Fuente: (RedHat, 2013)
124
Seleccionamos instalación mínima. (Imagen N° 36)
Imagen N° 36 (Seleccionar instalación Mínima)
Fuente: (RedHat, 2013)
Seleccionamos los paquetes necesarios en la instalación
mínima. (Imagen N° 37)
Imagen N° 37 (Selección de sistema Base)
Fuente: (RedHat, 2013)
125
En “”Escritorios” seleccionar “Escritorio” darle click a la opción
“Paquetes Opcionales”. (Imagen N° 38)
Imagen N° 38 (Selección de Escritorio)
Fuente: (RedHat, 2013)
En el cuadro que sale, desmarcar todas las opciones para
eliminar los paquetes no necesarios en la instalación. Una vez
hecho ello darle click a la opción cerrar y luego en siguiente.
(Imagen N° 39)
126
Imagen N° 39 (Selección de paquete)
Fuente: (RedHat, 2013)
Una vez terminada con estas opciones, darle click a siguiente
para que empiece a aplicar los cambios en la instalación.
(Imagen N° 40)
Una vez terminada la instalación inicial, darle click a la opción
reiniciar.
Cuando el equipo haya reiniciado, saldrá una pantalla de
bienvenida, se sugiere obviar cualquier configuración a través
de este medio. (Figura 4.25)
127
Imagen N° 40 (Instalación en proceso)
Fuente: (RedHat, 2013)
Ahora lo único que tenemos que hacer el logearnos con el
usuario root y poner la contraseña configurada previamente
para ese usuario.
4.7. INSTALACIÓN DE PRE-REQUISITOS EN EL
SERVIDOR RHEL 6 PARA EL SERVICIO RHEV-
MANAGER
Ingresamos al servidor mediante la línea de comandos
(de ahora en adelante CLI) y ejecutamos el siguiente
comando para registrar con la suscripción activa.
128
[root@rhevm ~]# rhn_register –nox
Seleccionamos siguiente. (Imagen N° 41)
Imagen N° 41 (Instalación de Pre-requisitos)
Fuente: (RedHat, 2013)
Ingresamos el usuario y contraseña de nuestra
subscripción activa. Finalmente pulsamos siguiente
hasta la culminación del registro. (Imagen N° 42)
129
Imagen N° 42 (Subscripción)
Fuente: (RedHat, 2013)
Suscribimos el servidor a los canales necesarios para
la instalación.
[root@rhevm ~]# rhn-channel --add --channel=rhel-x86_64-server-6-rhevm-3.2
[root@rhevm ~]# rhn-channel --add --channel=jbappplatform-6-x86_64-server-6-rpm
[root@rhevm ~]# rhn-channel --add --channel=rhel-x86_64-server-supplementary-6
[root@rhevm ~]# rhn-channel --add --channel rhel-x86_64-server-optional-6
Desactivar el servicio firewall
[root@rhevm ~]# service iptables stop
[root@rhevm ~]# chkconfig iptables off
Se debe asegurar a su vez la existencia de registros A
y registros inversos para cada uno de los servidores
que conforman la solución.
130
4.8. INSTALACIÓN DEL SERVICIO MANAGER
SOBRE RHEL 6
Ejecutamos la instalación mediante la herramienta
yum, para ello en primer lugar eliminamos el paquete
classpathx-jaf que causa conflictos con otros paquetes
del servicio manager. Posteriormente instalamos los
servicios necesarios para la plataforma ejecutando lo
siguiente:
[root@rhevm ~]# yum remove classpathx-jaf
[root@rhevm ~]# yum update
[root@rhevm ~]# yum install rhevm rhevm-reports
Ejecutamos el script de instalación, para ello
ejecutamos el siguiente comando:
[root@rhevm ~]# rhevm-setup
Y respondemos a las preguntas indicadas. Finalmente
se tendrá una pantalla de confirmación de datos
donde tendremos que confirmar todo lo ingresado.
Escribimos yes.
RHEV Manager will be installed using the following configuration:
http-port: 8080
https-port: 8443
host-fqdn: rhevm.quito.gob.ec
auth-pass: ********
131
db-pass: ********
org-name: Red Hat
default-dc-type: FC
nfs-mp: /exports
iso-domain-name: isos
override-iptables: no
Proceed with the configuration listed above? (yes|no):
A continuación se muestra un ejemplo de instalación
satisfactoria.
Installing:
Creating JBoss Profile... [ DONE ]
Creating A... [ DONE ]
Setting Database Security... [ DONE ]
Creating Database... [ DONE ]
Updating the Default Data Center Storage Type... [ DONE ]
Editing JBoss Configuration... [ DONE ]
Editing RHEV Manager Configuration... [ DONE ]
Configuring the Default ISO Domain... [ DONE ]
Configuring Firewall (iptables)... [ DONE ]
Starting JBoss Service... [ DONE ]
**** Installation completed successfully ******
(Please allow RHEV Manager a few moments to start up.....)
Additional information:
* SSL Certificate fingerprint:
4C:A4:8F:93:62:50:C1:63:C8:09:70:77:07:90:FD:65:5B:3C:E8:DD
* SSH Public key fingerprint: fa:71:38:88:58:67:ae:f0:b1:17:fe:91:31:6c:66:6e
* A default ISO share has been created on this host.
If IP based access restrictions are required, please edit /exports entry in /etc/exports
* The firewall has been updated, the old iptables configuration file was saved to
/usr/share/rhevm/conf/iptables.backup.103654-09092011_866
* The installation log file is available at: /var/log/rhevm/rhevm-
setup_2011_09_09_10_32_56.log
* Please use the user "admin" and password specified in order to login into RHEV
Manager
* To configure additional users, first configure authentication domains using the 'rhevm-
manage-domains' utility
132
* To access RHEV Manager please go to the following URL:
http://rhevm.sodimacpe.falabella.com:8080
4.9. INSTALACIÓN DEL SERVICIO GLUSTERFS
Este servicio fue instalado y configurado de manera
separada, es decir no por medio de los repositorios
oficiales de Red Hat. Para la instalación del servicio es
necesario descarga todos los paquetes que se
encuentran en la siguiente dirección (Gluster
community).
http://download.gluster.org/pub/gluster/glusterf
s/3.4/3.4.0/RHEL/epel-6.4/x86_64/
Los paquetes necesarios son:
glusterfs-3.3.1-1.el6.x86_64.rpm
glusterfs-debuginfo-3.3.1-1.el6.x86_64.rpm
glusterfs-devel-3.3.1-1.el6.x86_64.rpm
glusterfs-fuse-3.3.1-1.el6.x86_64.rpm
glusterfs-geo-replication-3.3.1-1.el6.x86_64.rpm
glusterfs-rdma-3.3.1-1.el6.x86_64.rpm
glusterfs-server-3.3.1-1.el6.x86_64.rpm
libibverbs-1.1.6-5.el6.i686.rpm
xfsprogs-3.1.1-10.el6.x86_64.rpm
Una vez descargado los paquetes se proceden a
guardar en los servidores e instalarlos. Para ello
simplemente nos dirigimos a la carpeta donde se
encuentra los paquetes y ejecutamos el siguiente
comando:
133
[root@suc26x1 Gluster]# yum install -y glusterfs-* libibverbs-1.1.6-5.el6.i686.rpm
xfsprogs-3.1.1-10.el6.x86_64.rpm
Luego empezará a instalar los paquetes y las
dependencias faltantes mediante la herramienta yum.
Una vez instalado el servicio, será necesario crear las
particiones que se usarán para alojar las máquinas
virtuales y serán administradas por el servicio glusters.
Para ello, asumiendo que el disco duro fue configurado
con LVM tal cual se indicó en la sección de instalación
del sistema operativo y se dejó espacio suficiente sin
usar, primero se debe crear un volumen lógico nuevo
en el grupo de volumen ya creado en la instalación.
Verificamos el espacio que posee el grupo de volumen.
[root@suc26x1 ~]# vgdisplay
--- Volume group ---
VG Name vg_suc26x1
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 17
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 5
Open LV 5
Max PV 0
Cur PV 1
Act PV 1
VG Size 558,24 GiB
PE Size 4,00 MiB
Total PE 142909
134
Alloc PE / Size 14807 / 50,00 GiB
Free PE / Size 128102 / 540 GiB
VG UUID aJ7Wdr-Nrxi-qEEc-MOB7-QYzG-
OvSL-zePn22
Podemos observar que quedan 540 GiB de espacio
libre, de los cuales por ejemplo usaremos 250 GiB para
que sean usado por el glusterfs. Creamos entonces el
volumen lógico:
[root@suc26x1 ~]# lvcreate -L 250G -n lv_storagedomain vg_suc26x1
Donde “lv_storagedomain” es el nombre de nuestro
volumen lógico y “vg_suc26x1” es el nombre del grupo
de volumen. Una vez ejecutado el comando, se habrá
creado un nuevo volumen lógico de 250 GiB de
tamaño. Para verificar los volúmenes lógicos creados
ejecutamos.
[root@suc26x1 ~]# lvscan
ACTIVE '/dev/vg_suc26x1/lv_root' [15,00 GiB] inherit
ACTIVE '/dev/vg_suc26x1/lv_swap' [7,84 GiB] inherit
ACTIVE '/dev/vg_suc26x1/lv_storagedomain' [250,20 GiB] inherit
Luego será necesario dar formato a la partición
creada, para ello ejecutamos el siguiente comando.
[root@suc26x1 ~]# mkfs.xfs -i size=512 /dev/vg_suc26x1/lv_storagedomain
Crear la carpeta donde se montará la partición
[root@suc26x1 ~]# mkdir –p /rhev/storage-domain
135
Procedemos a montar la partición, para ello
agregamos la última línea al archivo
/etc/fstab:
#
# /etc/fstab
# Created by anaconda on Thu Jul 25 18:06:34 2013
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/vg_suc26x1-lv_root / ext4 defaults 1 1
UUID=e953c6d3-44c4-492f-b101-8cb7078e998e /boot ext4 defaults 1 2
/dev/mapper/vg_suc26x1-lv_swap swap swap defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/vg_suc26x1/lv_storagedomain /rhev/storage-domain xfs defaults 0 1
Luego reinicializamos los puntos de montaje
[root@suc26x1 ~]# mount –a
Y verificamos que la partición fue montada
[root@suc26x1 ~]# df -h
S.ficheros Size Used Avail Use% Montado en
/dev/mapper/vg_suc26x1-lv_root
15G 2,9G 12G 21% /
tmpfs 7,8G 0 7,8G 0% /dev/shm
/dev/mapper/3600508b1001c6b493c595c0d46bf10fap1
485M 91M 370M 20% /boot
/dev/mapper/vg_suc26x1-lv_storagedomain
251G 17G 234G 7% /rhev/storage-domain
Ahora es necesario replicar este procedimiento en el
siguiente servidor.
136
Una vez listo la partición “/rhev/storage-domain” en
ambos servidores se debe proceder a crear el
almacenamiento replicado, para ello primero editamos
el archivo “/etc/glusterfs/glusterd.vol” en ambos
servidores tal que contenga lo siguiente.
[root@suc26x1 ~]# cat /etc/glusterfs/glusterd.vol
volume management
type mgmt/glusterd
option working-directory /var/lib/glusterd
option transport-type socket,rdma
option transport.socket.keepalive-time 10
option transport.socket.keepalive-interval 2
option transport.socket.read-fail-log off
option rpc-auth-allow-insecure on
end-volume
encendemos el servicio glusterfs en ambos servidores.
[root@suc26x1 ~]# /etc/init.d/glusterd start
Para crear el clúster a nivel de glusterfs en este caso
puntual, fue necesario crear una red punto punto a
través de una interfaz por cada servidor para
segmentar el tráfico de replicación de storage, se
configuro de la siguiente forma.
Hypervisor1, 192.168.254.1/30
Hypervisor2, 192.168.254.2/30
137
En base a esto se agrego las siguientes líneas a la
tabla host (archivo /etc/hosts) en ambos servidores,
esto debido a que el servicio gluster debe trabajar en
base a nombres de host y no ips.
192.168.254.1 peer1.glusterfs
192.168.254.2 peer2.glusterfs
Luego de realizado esto se debe confirmar la correcta
comunicación entre hypervisores mediante los
nombres de dominio anteriores.
Ahora procedemos a crear el cluster glusterfs. Para
ello atachamos el hypervisor 2 desde el hypervisor 1
(también puede hacerse de forma inversa).
[root@suc26x1 ~]# gluster peer probe peer2.glusterfs
Verificamos que se haya unido correctamente al
cluster, para ello la salida del comnado siguiente debe
mostrar el hypervisor 2 en estado “Connected”.
[root@suc26x1 ~]# gluster peer status
Number of Peers: 1
Hostname: peer2.glusterfs
Uuid: 83b62256-0d3b-44df-87d6-c89ad07783ac
State: Peer in Cluster (Connected)
Paso siguiente procedemos a crear el almacenamiento
replicado.
138
[root@suc26x1 ~]# gluster volume create storage-domain replica 2 transport tcp
peer1.glusterfs:/rhev/storage-domain peer2.glusterfs:/rhev/storage-domain
Encendemos el volumen glusterfs creado.
[root@suc26x1 ~]# gluster volume start storage-domain
Afinamos el almacenamiento para que trabaja con
mejor performance con entorno virtualizado.
[root@suc26x1 ~]# gluster volume set storage-domain server.allow-insecure on
[root@suc26x1 ~]# gluster volume set storage-domain quick-read off
[root@suc26x1 ~]# gluster volume set storage-domain read-ahead off
[root@suc26x1 ~]# gluster volume set storage-domain io-cache off
[root@suc26x1 ~]# gluster volume set storage-domain stat-prefetch off
[root@suc26x1 ~]# gluster volume set storage-domain eager-lock enable
[root@suc26x1 ~]# gluster volume set storage-domain remote-dio on
[root@suc26x1 ~]# gluster volume set storage-domain storage.owner-uid 36
[root@suc26x1 ~]# gluster volume set storage-domain storage.owner-gid 36
Y finalmente reiniciamos el volumen.
[root@suc26x1 ~]# gluster volume stop storage-domain
[root@suc26x1 ~]# gluster volume start storage-domain
Para verificar el estado del volumen creado.
[root@suc26x1 ~]# gluster volume info storage-domain
Volume Name: storage-domain
Type: Replicate
Volume ID: 5de60834-7a7f-4dda-a146-60a5f6923e60
Status: Started
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: peer1.glusterfs:/rhev/storage-domain
Brick2: peer2.glusterfs:/rhev/storage-domain
Options Reconfigured:
network.remote-dio: on
139
cluster.eager-lock: enable
performance.stat-prefetch: off
performance.io-cache: off
performance.read-ahead: off
performance.quick-read: off
server.allow-insecure: on
storage.owner-uid: 36
De acuerdo a las pruebas de concepto realizadas, es
mandatorio que el servicio gluster no se levantado de
forma automática al reinicio del hypervisor. Para
asegurarnos de ello ejecutamos.
[root@suc26x1 ~]# chkconfig glusterd off
4.10. CONFIGURACIÓN DEL STORAGE A
TRAVÉS DEL SERVIDOR RHEV-MANAGER
Una vez creado el storage mediante glusterfs, se
debe de configurar su uso a través de la consola de
administración.
Para ello primero creamos un “Centro de Datos”,
para ello nos dirigimos a la sección “Centros de
Datos” y creamos uno nuevo mediante el botón
“Nuevo”. Colocamos Nombre, Descripción y en Tipo
escogemos “Posix compliant FS”, dejamos lo demás
con los valores por defecto y damos “Ok” (ver en la
Imagen N° 43).
140
Imagen N° 43 (Creacion de Storage)
Fuente: (RedHat, 2013)
Una vez en la opción de creación de cluster,
llenamos la opción “General” con el Nombre,
Descripción. “En nombre de CPU” escogemos “Intel
Conroe Family” si los procesadores son Intel, caso
contrario tendremos que saber qué tipo de
procesador usa el equipo físico y dejamos lo demas
con los valores por defecto. En la opción
“Optimización” escogemos “Para la carga del
servidor - habilitar el compartir la página de memoria
en 150%” y finalmente damos ok. (véase Imagen N°
44)
141
Imagen 44 (Creación de Storage)
Fuente: (RedHat, 2013)
Luego de crear el centro de datos y el cluster,
procedemos a dar la opción “Configurar después”.
(Imagen N° 45)
Imagen N° 45 (Centro de Datos y Cluster)
Fuente: (RedHat, 2013)
En esta etapa necesitamos insertar los hypervisores
al cluster creado. Para ello es necesario asegurarnos
142
que los hypervisores tengan activas las
suscripciones de los canales base de Red Hat asi
como los canales de virtualización. En total deberían
de estar activos los siguientes canales o repositorios.
rhel-x86_64-rhev-agent-6-server
rhel-x86_64-server-6
rhel-x86_64-server-optional-6
rhel-x86_64-server-supplementary-6
También es necesario que el hostname del servidor
manager este en la tabla host de cada hypervisor.
Para ello agregar la siguiente línea al archivo
/etc/hosts
115.1.10.200 rhevm.sodimacpe.falabella.com rhevm
A través de la consola web de administración del
RHEV-M se procede a agregar los hypervisores,
para ello nos dirigimos la sección “Hosts” y damos en
la opción “Nuevo”. Llenamos la información solicitada
en la sección “General”, asegurandonos que no
estémarcada la opción “Configurar automáticamente
el cortafuegos host” (Véase N° 46)
143
Imagen 46 (Agregando Hypervisores)
Fuente: (RedHat, 2013)
Luego configuramos la sección “Gestión de energía”
habilitando esta función, escogiendo el tipo “ilo4” y
llenando de acuerdo a la información del ilo, a su vez
colocar en la parte “Opciones”
“timeout=6,power_wait=4”. (véase N° 47)
Imagen N° 47 (Configuración de RHEVM)
Fuente: (RedHat, 2013)
144
En la sección “SPM”, colocamos la prioridad de SPM
para dicho hypervisor. Tener en cuenta que la
arquitectura está construida para que el hypervisor
secundario tenga la prioirdad mas alta y el principal,
la más baja. Finalmente damos “Ok” y procedemos a
realizar lo mismopara el siguiente hypervisor.
(Imágenes N° 48)
Imagen N° 48 (Selección de SPM)
Fuente: (RedHat, 2013)
Una vez atachado ambos hypervisores, deberían
aparecer en la consola web en estado “Up”. (Véase
Imagen N° 49)
145
Imagen 49 (Selección de SPM)
Fuente: (RedHat, 2013)
Ahora procedemos a crear el almacenamiento para
las máquinas virtuales, para ello nos dirigimos a la
sección “Almacenameinto” y escogemos la opción
“Nuevo dominio”. Una vez acá llenamos el campo
“Nombre”, nos aseguramos que la opción “Función
de dominio /Tipo de almacenamiento” sea “Data /
POSIX compliant FS” y que el host a usar sea el
secundario. En ruta colocamos el hostname del
storage principal (en nuestro caso el hypervisor
secundario) seguido del volumen glusterfs (para
nuestro caso sería peer2.glusterfs:/storage-domain) y
por último en “Tipo VFS” ponemos glusterfs. (véase
Imagen N° 50)
146
Imagen N° 50 (Almacenamiento de máquinas de virtuales)
Fuente: (RedHat, 2013)
Una vez realizado este procedimiento, el storage-
domain debe figurar como hábil en la sección “Centro
de Datos”, y el SPM debe ser asumido por defecto
en el hypervisor secundario.
4.11. CREACIÓN DE UN DOMINIO DE
EXPORTACIÓN
Primero será necesario crear una partición mediante
LVM tal cual se hizo en el apartado 2.4. En el caso
puntual de la solución solo se creo la partición en el
hypervisor secundario con un peso de 250 GiB bajo el
nombre de:
/dev/VolGroup/lv_exportdomain
147
Y montado en la ruta, la cual debió ser creada:
/rhev/export-domain
Una vez creada y montada la partición, será necesario
compartirla mediante el servicio nfs, para ello será
necesario agregar la siguiente línea al archivo
/etc/exports
[root@suc15x2 ~]# cat /etc/exports
/rhev/export-domain 0.0.0.0/0.0.0.0(rw) #rhev installer
Luego darle permisos de usuario de virtualización.
[root@suc15x2 ~]# chmod 36:36 –R /rhev/export-domain
Y finalmente levantar el servicio nfs.
root@suc15x2 ~]# /etc/init.d/nfs start
Inicio de los servicios NFS: [ OK]
Iniciando cuotas NFS: [ OK]
Inicialización de NFS mountd: [ OK]
Deteniendo idmapd RPC: [ OK]
Iniciando idmapd RPC: [ OK]
Inicialización del demonio NFS: [ OK]
Lo agregamos como servicio automático.
[root@suc15x2 ~]# chkconfig nfs on
Finalmente verificamos que la carpeta está siendo
compartida.
[root@suc15x2 ~]# showmount -e localhost
Export list for localhost:
/rhev/export-domain 0.0.0.0/0.0.0.0
148
Una vez hecho esto se procede a crear el export
domain mediante la consola de Administración RHEV-
Manager.
Nos dirigimos a la consola web de administración en la
sección “Almacenamiento”, escogemos la opción
“Nuevo dominio” y empezamos con la creación del
dominio de exportación. Colocamos el Nombre, en
“Función de dominio /Tipo de almacenamiento”
escogemos “Export/NFS”, en “Usar host” escogemos
el hypervisor secundario y finalmente colocamos la
ruta de exportación y damos “Ok”. (véase imagen N°
51)
115.100.10.182:/rhev/export-domain
Imagen N° 51 (Creación de dominio de exportación)
Fuente: (RedHat, 2013)
149
Una vez creado el dominio de exportación, será
necesario activarlo, para ello nos dirigimos a la
sección “Centro de datos”, luego en la pestaña
“Almacenamiento”, señalamos en nombre del export
domain y finalmente damos click al botón “Activar”.
4.12. CONTROL DE CALIDAD (HISTOGRAMA)
En este diagrama se presentará las soluciones de los
problemas con más frecuencia junto con las pruebas
del proyecto. (Véase Imagen N° 52)
Imagen N° 52 (Histograma)
Fuente: (RedHat, 2013)
0
1
caida de nodo 1 caida de nodo 2 caida de ambosnodos
cantidad de fallas
cantidad de fallas
150
En lo que se refiere a la caída de los nodos se simulo
la caída del primero de la siguiente manera
Se generó un kernel panic y se quitó el cable de red
al (hypervisor) nodo 1.
Como podemos ver en la Imagen N° 53 el host caído
aparece de color rojo y en estado “conecting”.
Imagen N° 53 (Host Caido)
Fuente: (RedHat, 2013)
Como vemos en la Imagen N° 54 las maquinas
pierden funcionalidad, pero aún aparecen en color
verde y en estado “Up”.
151
Imagen 54 (Hosts)
Fuente: (RedHat, 2013)
En la Imagen N° 55 El “Storage Domain”permanece
activo debido a que el SPM (nodo secundario) no se
perdió.
Imagen N° 55 (Storage Domain)
Fuente: (RedHat, 2013)
152
Luego de unos minutos en la imagen N° 56 el nodo
caído es reiniciado por el nodo 2, a petición del
RHEV-M mediante el dispositivo fence (Ilo) del nodo
caído.
Imagen N° 56 (Hosts caido)
Fuente: (RedHat, 2013)
Una vez reiniciado en la Imagen N° 57, el servidor
pasa a estado “Non responsive” y se inicia el proceso
de migración de máquinas virtuales al segundo nodo.
153
Imagen N° 57 (Proceso de Migración)
Fuente: (RedHat, 2013)
Finalmente en la Imagen N° 58 se verifica que las
máquinas virtuales fueron encendidas en el segundo
nodo.
Imagen N° 58 (Hosts levantado)
Fuente: (RedHat, 2013)
154
En lo que se refiere al segundo nodo el escenario se
simuló quitando el cable de red y generando un
kernel panic.
En la Imagen N° 59 el host caído aparece en color
rojo y en estado “Conecting”.
Imagen N° 59 (Host Conectado)
Fuente: (RedHat, 2013)
En la Imagen N° 60 Las maquinas no pierden
funcionalidad, aparecen en color verde y en estado
“Up”.
155
Imagen 60 (Hosts)
Fuente: (RedHat, 2013)
En lo que se refiere al “Storage Domain” en la
Imagen N° 61 se desactiva poniéndose de color rojo
y pasando a estado “non Responsive” debido a que
el SPM (nodo secundario) fue el que falló. Debido al
estado del “Storage Domain” no es posible escribir
en él (crear máquinas virtuales, apagarlas,
pausarlas, prenderlas, etc), pero las máquinas
virtuales activas hasta ese momento siguen
funcionales.
156
Imagen N° 61 (Storage Domain)
Fuente: (RedHat, 2013)
Luego de unos minutos el nodo caído es reiniciado
por el nodo 1, a petición del RHEV-M mediante el
dispositivo fence (Ilo) del nodo caído ver Imagen N°
62
Imagen N° 62 (Reinicio del hosts)
Fuente: (RedHat, 2013)
157
Posteriormente como muestra la Imagen N° 63 y 64
el SPM es asumido por el nodo activo (nodo
secundario), con lo cual el Storage Domain vuelve a
activarse y pasa a estado “Up”, con ello ya es posible
escribir sobre él y manipular las máquinas virtuales.
Imagen N° 63 (Hypervisor activado)
Fuente: (RedHat, 2013)
Imagen N° 64 (Storage Domain)
Fuente: (RedHat, 2013)
158
En lo que se refiere a la caída de ambos nodos el
escenario se simuló apagando de manera normal los
nodos (shutdown) y de manera física (presionando
por más de 10 segundos el botón de encendido de
los servidores).
El RHEV-M detecta que ningún host este activo e
intenta reiniciar uno de ellos de manera automática a
través del Hilo, este procedimiento falla, debido a
que para realizar ello necesita de al menos un nodo
activo. Véase en la Imagen N° 65
Imagen N° 65 (Hipervisores)
Fuente: (RedHat, 2013)
159
Luego los host pasan a estado “Non Responsive”
hasta que sea reiniciado uno de ellos. (véase imagen
N° 66)
Las máquinas virtuales se quedan colgadas
aparentemente prendidas en estado “Up” según la
Imagen N° 67 (Hosts Devueltos a Hyperisores A)
Fuente: (RedHat, 2013)
Imagen N° 66 (Hypervisores Apagados)
Fuente: (RedHat, 2013)
160
En la Imagen N° 68 el “Storage Domain” pasa a
estado “Non Responsive”.
Luego de levantado uno o ambos nodos en la
Imagen N° 69 muestran que, se activa el cluster
completamente y las máquinas virtuales empiezan a
encender en el primer nodo hábil, el SPM es
adquirido por el nodo con mayor prioridad y el
“Storage Domain” se habilita.
Imagen N° 68 (Storage Domain Desactivado)
Fuente: (RedHat, 2013)
161
Imagen 69 (Hypervisores Activados)
Fuente: (RedHat, 2013)
4.13. CIERRE DEL PROYECTO
A continuación en el cierre del proyecto en la tabla se menciona
lo siguiente:
162
Acta de Conformidad
INFORMACIÓN BÁSICA
Cliente Sodimac
Servicio Implementación de virtualización con RHEV
Fecha 02/09/2013 – 01/10/2013
MOTIVO DE CONFORMIDAD
Suscripción Anual de RHEV
Servicio de soporte
ACTIVIDADES REALIZADAS
ALCANCE DEL PROYECTO
INSTALACIÓN DEL SERVICIO RHEVM
1. Instalación y Configuración de Red Hat Enterprise.
2. Instalación y Configuración de Red Hat Enterprise
Virtualization.
3. Instalación y configuración de storage.
PRUEBAS DE FUNCIONAMIENTO
Tabla 8 (documento de cierre de proyecto)
Fuente: Elaboración Propia
163
Bibliografía
Aragundi Alicia, C. I. (2012). implementación de un laboratorio para la virtualizacion de
sustemas operativos mediante la instalacion y configuracion de
ordenadores y servidores bajo plataformas gnu/linux y windows
server 2008 aplicando Scsi. Ecuador: Ecuador.
GEDPRO. (27 de Setiembre de 2013). http://gestion-de-
proyectos.gedpro.com/home/procesos/planificacion.
Recuperado el 27 de Setiembre de 2013
Hat, R. (2012). Red Hat Enterprise Linus 6.2 RH436. USA: Steven Bonneville.
Hat, R. (27 de setiembre de 2013). Red Hat. Recuperado el 27 de setiembre de 2013, de Red
Hat: www.redhat.com
Jorge Lastras, J. L. (2009). Arquitecturas de red para servicios en cloud computing.
Madrid.
McBrien, S. (2012). Red Hat Enterprise Linux 6.2. USA: Steven Bonneville.
Peggy Miranda Carbo, L. M. (2011). Diseño e Implementación de un Ambiente Virtualizado para
un Sistema Contable. Guayaquil-Ecuador.
Rita Mulcahy, L. D. (2011). pmp. Estados Unidos de Norte America.
SUNAT. (27 de 09 de 2013).
http://www.sunat.gob.pe/cuentassunat/mgpi/metodologiaGe
stionProyectosInstitucional.pdf. Recuperado el 27 de 09 de
2013, de
http://www.sunat.gob.pe/cuentassunat/mgpi/metodologiaGe
stionProyectosInstitucional.pdf
164
CONCLUSIONES
Del presente informe técnico concluimos que:
1. Se levantaron lo servidores con los servicios respectivos en Red Hat Enterprise
Virtualization.
2. Es necesaria la licencia para la actualización de Red Hat Enterprise
Virtualization.
3. Red Hat Enterprise Virtualization requiere de una arquitectura en la que pueda
funcionar de manera eficiente y así administrar las máquinas virtuales de manera
segura.
4. Es necesario que la arquitectura soporte al Storage ya que la alta disponibilidad
depende del almacenamiento que posea.
5. Es necesario Reservar un ambiente de desarrollo, para realizar algunas pruebas
y cambios antes de implementar o realizar algún cambio antes de ejecutarlo en
producción.
165
RECOMENDACIONES
1. Se recomienda tener los servidores en un Data Center y no en un ambiente
desfavorable para el hardware.
2. Contratar personal idóneo que tenga conocimiento de Linux y virtualización en
Red Hat Enterprise Virtualization.
3. Habilitar el acceso remoto, para brindar la garantía y soporte por la
implementación realizada.
4. Es necesario contemplar una capacitación en Linux, para una buena gestión y
administración de la plataforma.
5. Es necesario gestionar el backup del servidor, storage
166
ANEXO
167
ITEM
DESCRIPCION SETIEMBRE
DE
ACTIVIDADES SEM 1 SEM 2 SEM 3 SEM 4
Días L M M J V L M M J V L M M J V L M M J V
1 Realización de Kick off
2 Elaboración de project charter
3 Elaboración de alcance de proyecto *
4 Aprobación de documentos de inicio
5 Verificación de infraestructura
6 Elaboración de lista de requerimientos previos
7 Elaboración de diseño final de plataforma virtual
8 Aprobación de diseño final
9 Aprovisionamiento de máquina virtual para RHEVM
10 Instalación de Sistema Operativo
11 Afinamiento de Sistema Operativo
12 Instalación de Servicio Red Hat Virtualization Manager (RHEVM) *
13 Afinamiento de servicio RHEVM
14 Configuración de Red Hat Hypervisor
15 Implementación de Data center virtual
16 Creación de clúster
17 Configuración de políticas de cluster 18 Creación de máquina virtual de prueba 19 Pruebas de Funcionamiento * 20 Ejecución de plan de pruebas 21 Conformidad de ejecución de pruebas
