UNIVERSIDAD ALFONSO X EL SABIO
ESCUELA POLITÉCNICA SUPERIOR
INGENIERÍA INFORMÁTICA
PROYECTO FIN DE CARRERA
SISTEMA DE ALTA DISPONIBILIDAD EXTREMA EN ENTORNOS FÍSICO A VIRTUAL SOBRE VMWARE ESX 3.5
Samuel Martínez Fernández
3 – Julio ‐ 2009
UNIVERSIDAD ALFONSO X EL SABIO
ESCUELA POLITÉCNICA SUPERIOR INGENIERÍA INFORMÁTICA
SISTEMA DE ALTA DISPONIBILIDAD EXTREMA EN ENTORNOS FÍSICO A VIRTUAL SOBRE VMWARE ESX 3.5
ALUMNO: SAMUEL MARTÍNEZ FERNÁNDEZ N.P.: 42715
TUTOR ACADÉMICO: ALBERTO JAVIER GARCÍA FECHA DE PRESENTACIÓN: 3 – JULIO - 09 BREVE DESCRIPCIÓN:
El proyecto trata de la implantación de un sistema de monitorización en tiempo real sobre un servidor que en caso de detectar problemas activa una copia virtual de dicha máquina dentro de un entorno de virtualización basado en Vmware ESX 3.5 configurado para alta disponibilidad.
Para la implantación de este sistema se ha de contar con una granja de virtualización basada en Vmware ESX 3.5 con licencias para al menos dos servidores, así como licencias para HA y Vmotion (migración de máquinas virtuales en caliente entre servidores) y DRS (Balanceo de carga en función de recursos).
Toda la infraestructura balancea su carga de red con el balanceador de Microsoft, llamado Network Load Balancing (NLB). Lo que obliga a que el sistema monitorizado sea un Windows, pudiendo ser de la familia de Servers (2003 o 2008).
El proyecto tiene como objetivo la reducción de costes, tanto de
equipamiento, como de consumo energético, como de espacio, en los CPDs de las empresas. Permitiendo la configuración de Alta Disponibilidad Extrema para aplicaciones que permitan replicación de servidores con independencia de los datos procesados (Frontal Web, etc.).
FIRMA DEL DIRECTOR FIRMA DEL
DEL PROYECTO ALUMNO
Índice
Balanceo de carga de Red ... 5
Networking Load Balancing (NLB) ... 5
Funcionamiento ... 10
Granjas de Servidores Web y Network Load Balancing ... 13
Configuración y Administración de un Cluster NLB. ... 15
Modo de operación NLB (Cluster operation mode): Unicast o Multicast ... 17
Propiedades de cada Host ... 21
Las Reglas de Puerto (Port Rules) ... 23
Afinidad en Cluster NLB ... 28
Recomendaciones ... 32
Virtualización ... 36
Vmware ESX ... 38
Instalaciones ... 39
Instalación ESX ... 39
Balanceo de carga de Red
Balanceo de carga es una tecnología empleada para prevenir o solucionar las grandes cargas en los servidores destinados a dar servicios. Por ejemplo en los servidores de páginas web podemos encontrarnos con sobrecargas en el número de conexiones, para solucionarlo podemos instalar un balanceador de carga que oculte la dirección del servidor detrás de una dirección virtual, y enlazar por software a esta dirección virtual otros servidores con las mismas aplicaciones y configuraciones con el objetivo de repartir el número de conexiones.
De entre los diferentes balanceadores de carga presentes en el mercado me centraré en el NBL disponible en los sistemas operativos Windows 2003.
Networking Load Balancing (NLB)
NLB (Network Load Balancing) es una aplicación de alta disponibilidad para aplicaciones de servidor basadas en TCP/IP, capaz de ofrecer escalabilidad y alto rendimiento. NLB es especialmente apropiado para aplicaciones sin estado (statless applications), de tal modo, que cada petición que reciba el Clúster NLB pueda ser atendida indistintamente por cualquiera de los Nodos del Clúster NLB, al poder tratarse como operaciones totalmente independientes.
Sin embargo, Network Load Balancing también es capaz de ofrecer alta disponibilidad a las aplicaciones que mantienen el estado, pero teniendo en cuanta que en estos casos el reparto de carga puede no ser tan equitativo.
Network Load Balancing es una tecnología de Microsoft disponible desde Microsoft Windows NT 4, disponiendo actualmente de muchos años de funcionamiento en entornos de producción en todo tipo de empresas.
Es importante tener en cosnideración que NLB :
• No ofrece ninguna funcionalidad para replicar los datos de aplicación entre distintos nodos del Cluster NLB. Por ejemplo, en el caso de una aplicación Web que se esté ejecutando sobre el cluster NLB, será necesario instalar dicha aplicación en todos los nodos del Cluster.
• No es capaz de balancear carga ante una caída o error de la aplicación en alguno de los nodos( no monitoriza el funcionamiento de las aplicaciones). Si la aplicación deja de responder en uno de los nodos del Cluster NLB, pero dicho nodo sigue vivo, el cluster NLB seguirá contando con dicho nodo al repartir la carga de trabajo.
• No monitoriza los servicios de Windows para su inicio y/o parada.
• No ofrece un Nombre de Equipo NetBIOS al conectarse. En su lugar muestra una dirección IP virtual (denominada por Microsoft como VIP:
Virtual IP address), suficiente para servir conexiones TCP y/o UDP.
• El balanceo se realiza en función de la carga de red(sólo y exclusivamente), y no en función de la carga de CPU, consumo de memoria, etc.
NLB permite crear agrupaciones de hasta 32 Nodos (Hosts) en un Cluster NLB, sobre los que distribuir las conexiones entrantes TCP y/o UDP. Así, es posible
crear varios Cluster NLB (siendo cada uno de hasta 32 nodos), de igual modo que es posible que un nodo pertenezca a dos Clusters NLB (aunque cada uno posea distintos miembros). Si se necesita superar el límite de 32 nodos del Cluster NLB, es posible utilizar varios cluster NLB, y balancear entre ellos la carga utilizando la funcionalidad Round Robin de DNS (RRDND).
Desde el punto de vista del cliente, el Cluster NLB se muestra como un único servidor que responde a las peticiones del cliente. Conforme se incrementa el tráfico de red ( o la carga de trabajo), es posible añadir nuevos Nodos al Cluster NLB para así conseguir cubrir las necesidades del servicio.
NLB permite mejorar el rendimiento, la escalabilidad (agregando más nodos al Cluster NLB) y la disponibilidad. Si un Nodo se car, el servicio se continúa ofreciendo, repartiendo la carga entre el resto de los nodos vivos del Cluster NLB, gracias al proceso de Convergencia.
Existen multitud de aplicaciones que se pueden aprovechar del NLB, como las aplicaciones Web y otras soluciones basadas en HTTP, FTP, Firewalls y Proxys (como RRAS e ISA Server), servidores de túneles (VPNs, etc.), Terminal Services, Windows Media Services, Mobile Information Server, etc.
NLB es preferible a otras soluciones software como el DNS Round Robin (RRDNS), debido a que Round Robin distribuye las peticiones de red entre varios servidores, pero sin ofrecer ningún mecanismo que garantize que el servidor al que se direcciona el tráfico de red está vivo.
NLB si garantiza que el servidor al que se direcciona una solicitud está vivo, ofreciendo un mejor resultado (RRDNS podría enviar las peticiones incluso a un servidor apagado.
NLB está disponible en todas las ediciones de Windows Server 2003, incluidas la más pequeña, Web Server Edition. Así como en las versiones de 32 bits (x86), x64 e Itanium (IA64).
NLB ha sido diseñado para ser utilizado en redes Ethernet, y probado sobre diferente hardware y electrónica de red (está probado por Microsoft sobre redes 10 Mbps, 100 Mbps y 1 Gbps), incluyendo también sobre adaptadores de red en Team (teaming network adapters) compatibles con Windows Server 2003. NLB no es compatible con redes ATM, ATM LAN ó Token Ring.
También es posible encontrar soluciones hardware capaces de realizar el balanceo de carga de red, en vez de utilizar soluciones software como la ofrecida por Microsoft (NBL). Suelen ser administrables a través de Web, y la principal ventaja de estas alternativas por hardware, es que permiten liberar a los servidores de aplicaciones de la carga de trabajo propia del balanceo de carga de red, y además limitan el tráfico de red de los conmutadores (es decir, evitan el switch port flooding) maximizando el rendimiento y el ancho de banda. Algunoas de las soluciones hardware de balanceo de carga de red son:
- WebMux Load Balancing, de CAI Networks.
- Big IP Local Traffic Manager, de F5. Principal alternative.
- Barracuda Load Balancer, de Barracuda Networks.
- Cisco Arrowpoint.
Del mismo modo, existen otras alternativas software. El principal motivo de plantearse utilizar alternativas software a NLB es superar su límite de 32 nodos (hosts), aunque siempre es posible crear múltiples Cluster NLB, cada uno con 32 nodos. Así, existen multitud de alternativas software como Citrix, WTS Gateway Pro, etc. Recordar que también existe la posibilidad de jugar con varios Clusters NLB, balanceados entre sí por DNS Round Robin.
Funcionamiento
Microsoft Network Load Balancing funciona como un controlador de dispositivos (driver) que es posible vincular y configurar sobre las tarjetas de red que se desee, y que en particular es el wlbs.exe(es un driver NDIS).
NLB utiliza un algoritmo distribuido para realizar el mapeo de las conexiones entrantes( es decir, el balanceo de carga de red), capaz de permitir que cada nodo del Cluster NLB pueda realizar rápida e independientemente la decisión de balanceo de carga para cada paquete entrante. Resulta especialmente eficaz cuando los clientes realizan muchas peticiones, cada una pequeña, con es el caso de las aplicaciones Web.
La forma de realizar el balanceo de carga de red depende de la configuración de Afinidad. Es importante recordar, que el balanceo se realiza solo y exclusivamente en función de la carga de red, y no en función de otros factores, como la carga de la CPU o el uso de la memoria. Este comportamiento, puede provocar que la efectividad de NLB pueda variar en función de la aplicación, protocolo y Afinidad que se esté utilizando en cada caso.
Siempre que se recibe un paquete entrante en el Cluster NLB, todos los nodos del Cluster NLB simultáneamente examinarán dicho paquete. La decisión de qué nodo debe despachar el paquete, se realiza mediante un procedimiento aleatorio que toma como entrada distintas variables en función de la Afinidad utilizada. Realizado el mapeo, las sucesivas peticiones similares (dependiendo de la Afinidad) serán despachadas por el mismo nodo, y rechazadas por el resto del Cluster NLB. Es decir, todos los paquetes enviados al Cluster NLB son examinados por todos los nodos, sin embargo, solo un nodo procesará el paquete (pasándolo por todas las capas de la pila de protocolos TCP/IP), y el resto de los nodos lo rechazarán (aunque previamente, tendrán que examinar al menos la cabecera del paquete).
Este proceso de filtrado de paquetes no deseados resulta más rápido que tener que enrutar los paquetes (que implica recibirlos, examinarlos, re-escribirlos y re- enviarlos). Del mismo modo, este comportamiento implica que toda la información enviada al Cluster NLB es enviada a cada nodo del Cluster NLB, luego en el caso habitual de redes conmutadas, se estará enviando los mismos paquetes a través de varios puertos del conmutador (switch), consumiendo ancho de banda (los paquetes se envían a todos los nodos, y los nodos aceptan o rechazan cada paquete durante el proceso de filtrado). Este comportamiento de enviar la misma información a través de varios puertos del conmutador, es conocido como switch port flooding o también switch flooding.
Conceptualmente podemos decir, que cada nodo del Cluster mantiene una tabla interna de mapeos por la que sabe qué peticiones debe atender y que peticiones no debe atender (al ser atendidas por otro nodo del Cluster NLB). Esta tabla conceptual se mantiene de forma indefinida hasta que se produce un cambio en la pertenencia al Cluster NLB, en cuyo caso se produce el proceso de Convergencia.
El proceso de Convergencia implica la creación de una lista de nodos miembros de Cluster NLB, así como volver a crear la tabla conceptual de mapeos para asociar qué solicitudes de cliente son atendidas por qué nodo del Cluster NLB. Es decir, el proceso de Convergencia permite recontruir el estado del Cluster NLB, designando el nuevo nodo por Defecto (Default Host) en función de la prioridad de los nodos vivos, y reajustando la distribución de tráfico de red entrante entre los nodos vivos. Durante el proceso de Convergencia, los nodos vivos siguen gestionando el tráfico entrante. El proceso de Convergencia puede durar varios segundos (hasta 10 segundos). El proceso de Convergencia puede ser iniciado tanto por un cambio en la pertenencia de nodos al Cluster NLB, como por otros eventos, como cambiar el peso de un Host del Cluster, o cambios en las reglas de puerto.
Para el funcionamiento del Cluster NLB se envían paquetes de Heratbeat, con el fin de conocer el estado de los nodos que pertenecen al Cluster NLB(es decir, con el
fin de confirmar qué nodos están vivos). Se supone que un nodo está en perfecto estado, siempre y cuando se reciben sus paquetes de Heartbeat. Si el resto de los nodos del Cluster NLB dejan de recibir los paquetes de Heartbeat de un nodo en particular, supondrán que dicho nodo se ha caído, y se iniciará la Convergencia.
Por defecto se envía un paquete de Heartbeat cada segundo, de un tamaño de 1500 bytes. Del mismo modo, por defecto, se iniciará el proceso de convergencia son la pérdida de 5 paquetes de Heartbeat consecutivos. Estos valores son configurables, pero por defecto ofrecen un buen comportamiento.
Los paquetes de Heartbeat son paquetes Broadcast a nivel Ethernet, motivo que explica porque los nodos del Cluster NLB deben pertenecer al mismo segmento de red (o misma VLAN).
Granjas de Servidores Web y Network Load Balancing
El término de Granjas de Servidores consiste en una colección de servidores que actúan como un único servidor para los usuarios, cuyo funcionamiento se basa en utilizar una misma dirección IP (Virtual IP) en todos los servidores de la Granja (al margen, de que puedan disponer direcciones IP adicionales). Desde hace varios años, están bastante de moda, debido a que son una solución de escalabilidad cuando alcanzamos el límite de rendimiento de un único servidor, pudiendo añadir un servidor adicional para así repartir la carga (o bien, si tenemos una granja de n servidores, agregando nuevos para disponer así de n + m servidores).
Del mismo modo, las Granjas de Servidores son una solución de alta disponibilidad, ya que ante la caída de un servidor, el servicio se puede seguir ofreciendo. Esto implica, que aunque en ocasiones sería suficiente con utilizar una única máquina para ofrecer los servicios Web de nuestra empresa, quizás no resulte más interesante utilizar dos máquinas de bajo coste formando una Granja de Servidores, y así poder afrontar la misma carga y además ofrecer alta disponibilidad. De hecho, aún con el coste de las licencias de software, suele resultar mucho más rentable.
Cada servidor de la granja, debe contener su propia copia de todo aquello lo que necesite (ej: ficheros HTML, XML, páginas ASP, páginas ASP.Net), librerías DLL, objetos COM, assemblies, etc., de tal modo, que puedan funcionar como servidores independientes. Por ello, resulta de gran utilidad disponer de Scripts o de alguna herramienta que facilite automatizar la distribución de cambios en las aplicaciones sobre todos los servidores de la granja (en algunas empresas, se realizan pequeñas herramientas basadas en Visual Source Safe).
En escenarios de alta carga de trabajo, es importante tener en cuenta que la base de datos puede presentarse como un cuello de botella en nuestra infraestructura, cuando todos los servidores de nuestra granja estén con una alta carga de trabajo, y en
consecuencia, estén cargando al servidor de base de datos. Para solucionar este problema, se puede dividir la base de datos en varias bases de datos más pequeñas, y éstas a su vez, distribuirlas entre distintos servidores (ej: construir un Cluster MSCS con varios nodos, y distribuir las distintas bases de datos entre los distintos nodos).
Network Load Balancing (NLB) es una solución ideal, tanto para balancear la carga de red, como para favorecer una solución 24x7, de vital importancia en los negocios de nuestros días. En un entorno empresarial, es posible:
- Construir uno o varios Cluster NLB de hasta 32 Nodos (Hosts) cada uno para los servidores Web Frontales, aquellos que recibirán las peticiones de los usuarios a través de los navegadores.
- Construir uno o varios Cluster NLB de hasta 32 Nodos (Hosts) cada uno para los servidores de la Lógica de Negocio (ej: los COM+), aquellos que recibirán las peticiones de los usuarios a través de los navegadores.
- Utilizar Microsoft Cluster (MSCS) para dar soporte a los servidores de Base de Datos (ej: SQL Server) de nuestro software corporativo.
Microsoft Cluster (MSCS) es capaz también de dar soporte a otros muchos servicios de empresa, como DHCP, Servidor de Ficheros, etc.
Configuración y Administración de un Cluster NLB.
Para poder configurar un Cluster NLB, es necesario ser miembro del grupo de administradores (Administrators) de cada uno de los Nodos (Host) del Cluster NLB.
Principalmente será necesario utilizar la herramienta administrativa Network Load Balancing Manager (NLBMgr.exe), o en su defecto, la herramienta de línea de comandos nlb.exe. Network Load Balancing Manager (NLBMgr.exe), utiliza a su vez, DCOM y WMI. Es interesante recordar, que existe un bug por el cual el proveedor WMI del NLB Manager no se puede conectar a un Nodo de un Cluster NLB si su nombre de equipo empieza por un número. En la herramienta Network Load Balancing Manager (NLBMgr.exe), sólo se mostrarán los Nodos (Hosts) para los cuales se disponga de permisos administrativos (es decir, se disponga pertenencia al grupo de Administradores Locales).
Además de la herramienta administrativa Network Load Balancing Manager (NLBMgr.exe) y de la herramienta de línea de comandos nlb.exe, también se dispone del diálogo de propiedades de cada tarjeta de red, desde la ventana de Conexiones de Red (Network Connections) del Panel de Control, para realizar las configuraciones de TCP/IP y otras configuraciones de red adicionales y del propio Cluster NLB. Sin embargo, Microsoft recomienda utilizar sólo y exclusivamente la herramienta administrativa Network Load Balancing Manager (NLBMgr.exe), y también avisa que la utilización de ambas herramientas para la configuración del Cluster NLB, puede generar resultados impredecibles.
Una vez habilitado NLB en un Host, se crean las entradas de registro correspondientes sobre la rama HKLM\System\CurrentControlSet\Services\WLBS.
Con Microsoft Network Load Balancing (NLB), al igual que ocurre con Microsoft Cluster (MSCS),ya viene instalado por defecto en Windows Server 2003 (así nos ahorramos re-inicios).Funciona como un controlador de dispositivo (driver) que es
posible vincular y configurar sobre las tarjetas de red que se desee, y que en particular es el wlbs.exe (es un driver NDIS). Así, se ha conseguido simplificar al máximo la configuración de un Cluster NLB desde cero, ya que es suficiente con iniciar la herramienta administrativa Network Load Balancing Manager (NLBMgr.exe), y ejecutar la opción New Cluster para iniciar así el asistente para la creación de un nuevo Cluster NLB.
Son dos los valores de configuración que suelen causar duda a los administradores de un Cluster NLB: El Modo de operación del Cluster NLB (Cluster operation mode, que puede serUnicast ó Multicast) y la Afinidad (None, Single y Class C).
Modo de operación NLB (Cluster operation mode): Unicast o Multicast
El modo de operación del Cluster NLB, es una propiedad del Cluster NLB (no es una propiedad de regla de puertos) que permite especificar cómo se desea que se gestione la dirección MAC de las tarjetas de red pertenecientes al Cluster NLB.
A fin de cuentas, la base del funcionamiento del Cluster NLB está en el falseo de MAC (MAC spoofing) de las respuestas ARP, es decir, en sobrescribir los paquetes salientes del Cluster NLB con la MAC Virtual y la dirección IP Virtual del Cluster NLB, y recibir los paquetes que son enviados a dicha MAC e IP.
Microsoft Network Load Balancing nos ofrece dos alternativas para el modo de operación del Cluster NLB (Cluster operation mode):
A.- Unicast. Esta es la opción por defecto y es la opción recomendada. La dirección MAC del Cluster, es asignada a todas las tarjetas de red asignadas al Cluster NLB, y la dirección MAC de cada tarjeta de red NO es utilizada. Es decir, cada tarjeta de red asignada al Cluster NLB mantiene una única dirección MAC, en particular, la MAC del Cluster. Así, tanto la dirección IP del Cluster como la dirección IP propia de la tarjeta de Red, se resuelven a la dirección MAC del Cluster, ya que se sobrescribe la dirección MAC real de las tarjetas de red del Cluster NLB con la dirección MAC del Cluster.
Esta configuración, implica que NO es posible la comunicación desde un Host del Cluster NLB a otro Host del Cluster NLB a través de la tarjeta de red utilizada en el Cluster, debido a que al compartir la dirección MAC (es decir, utilizar la misma dirección MAC en el equipo de origen y en la tarjeta de red del equipo destino), se produce una confusión, es decir, en el nivel de enlace OSI (Ethernet y direcciones MAC) no es posible diferenciar al destinatario del emisor, y por ello, la comunicación host-to-host (también conocida como intra-host) NO es posible.
B.- Multicast. La dirección MAC del Cluster, es asignada a todas las tarjetas de red asignadas al Cluster NLB, pero de forma adicional, cada tarjeta de red mantiene su dirección MAC. Es decir, cada tarjeta de red asignada al Cluster NLB mantiene dos direcciones MAC, pero sólo la dirección MAC del Cluster es utilizada para la comunicación con los equipos clientes. Así, la dirección IP del Cluster se resuelve a la dirección MAC del Cluster, y la dirección IP propia de la tarjeta de Red se resuelve a la dirección MAC propia de dicha tarjeta.
Este comportamiento implica que una tarjeta de Red de un Cluster NLB configurado en modo de operación Multicast, es capaz de manejar tanto el tráfico de los
clientes (paquetes destinados a la dirección IP/MAC del Cluster) como el tráfico propio del Host (paquetes destinados a la dirección IP/MAC de la tarjeta de Red del Cluster NLB).
En algunos casos la utilización de direcciones MAC multicast, no es soportada por la implementación ARP de algunos enrutadores (routers), como es el caso de Cisco (en cuyo caso, el Cluster NLB no será visible fuera del segmento Ethernet al que pertenece. Para evitar este tipo de problemas, debe garantizarse que el enrutador (Router) acepta respuestas ARP que incluyan una dirección MAC en el payload de la trama Ethernet, pero que parecen proceder de un dispositivo con una dirección MAC distinta, conforme se muestra en la cabecera Ethernet. Si el enrutador (router) o el conmutador multi-capa (multi-layer switch) correspondiente no soporta esta funcionalidad,es posible crear una entrada ARP estática en el router como solución al problema, para que así sea capaz de resolver la dirección IP Unicast a la dirección MAC Multicast correspondiente.
Multicast puede ofrecer un rendimiento inferior a Unicast, debido a que utiliza una única tarjeta de red tanto para el tráfico de los equipos clientes como para el tráfico host-to-host.
Al utilizar Multicast es posible activar la opción IGMP Multicast. La principal razón por la que activar o desactivar la opción IGMP Multicast, es en caso de descubrir algún tipo de problema de funcionamiento, como por ejemplo, problemas de convergencia.
La recomendación de Microsoft es utilizar el modo de operación Unicast, excepto que se disponga de una única tarjeta de red (tanto para el Cluster NLB como para el resto de comunicaciones) y además sea necesaria la comunicación entre los distintos Nodos del Cluster. Como hablamos, es recomendado para evitar problemas con enrutadores (routers).
Es importante tener en cuenta, que la dirección MAC del Cluster NLB, se genera de forma automática, es decir, no podemos especificar de forma explícita que dirección MAC deseamos utilizar para utilizar como MAC del Cluster.
También es interesante recordar que, independientemente del modo de operación del Cluster NLB (es decir, sea Unicast o sea Multicast), las tarjetas de red utilizadas en un Cluster NLB dispondrán al menos de dos direcciones IP: la dirección IP propia de la tarjeta más la dirección IP del Cluster NLB.
Propiedades de cada Host
Las propiedades de cada Host suelen quedar configuradas durante la instalación y configuración inicial del Cluster NLB, y habitualmente, no suele ser necesario tocarlas más. Sin embargo, resulta útil conocerlas, principalmente la propiedad Priority, para evitar algunos malos entendidos del funcionamiento de Network Load Balancing. A continuación se explican dichas propiedades.
- Priority. Se trata de un valor numérico, que debe ser único para cada Nodo del Cluster NLB, entre 1 y 32 (recordar que el número máximo de Nodos de un Cluster NLB es 32). Este valor numérico indicar la prioridad de cada Nodo del Cluster, de tal modo, que el Host con el valor de prioridad más bajo es el Host con mayor prioridad del Cluster NLB. A este Nodo se le denomina Nodo por Defecto (Default Host). Así, el Host con mayor prioridad es el que gestionará el tráfico de las peticiones entrantes a la IP Virtual para protocolos NO configurados para balanceo de carga. De este modo, los puertos no cubiertos por las reglas de puerto, serán servidos por un único equipo (al fin de cuenta, son puertos existentes pero SIN alta disponibilidad). El concepto de Prioridad de Host NO tiene nada que ver con la asignación de mayor peso a un Host (no confundir con la prioridad y/o peso de las reglas de puerto). Por poner un ejemplo gráfico, si tenemos un Cluster NLB con dos Nodos, y sobre el mismo creamos sólo una regla de puerto para el puerto 443 (HTTPS), entonces, ¿Qué ocurrirá con las peticiones que no estén incluidas en las reglas de puerto del Cluster NLB? Pues si por ejemplo llega una o varias peticiones para el puerto 80 (HTTP), esas peticiones serán servidas por el Nodo por Defecto (Default Host). Este comportamiento es muy interesante, ya que algunos administradores piensan que por seguridad es necesario incluir reglas de puerto sólo para los puertos necesarios, con el fin de que las peticiones a puertos diferentes NO alcancen a
nuestros servidores del Cluster NLB. Esto no es así, de tal modo, que en caso de desear proteger nuestro Cluster NLB, lo primero será situarlo detrás de un Firewall (ej: Microsoft ISA Server o Checkpoint Firewall-1) configurado para dejar pasar las peticiones sólo para los puertos deseados, y además, si nos sentimos así más seguro, podemos crear una o varias reglas de puerto configuradas con la opción de filtrado Disable this port range, para que así dichas peticiones sean detenidas por el NLB y no alcancen a la aplicación correspondiente (ej: que no alcancen al IIS).
- Dedicated IP. Esta es la dirección IP y máscara de red propia del Nodo, por lo cual, en cada Nodo del Cluster NLB podremos observar una dirección IP distinta. En la práctica, éste valor no suele tocarse.
- Initial host state. Permite especificar el estado por defecto del Nodo, a elegir entre Started, Stopped y Suspended. En la práctica, este parámetro no suele tocarse, quedando en su valor por defecto (Started).
Las Reglas de Puerto (Port Rules)
Las reglas de puerto (port rules) en un Cluster NLB, definen qué puertos van a ser gestionados por el Cluster NLB y cómo van ser balanceados. La configuración por defecto de las reglas de puerto incluye todos los puertos (desde el 0 al 65535), lo cual se trata de una configuración demasiado amplia. La recomendación es crear múltiples reglas de puerto, con puertos o rangos de puertos excluyentes (es decir, un puerto sólo puede estar incluido en una regla de puerto, y no se pueden solapar entre distintas reglas de puertos). Además, cada regla de puerto puede tener una configuración de Afinidad distinta, si así se desea.
En cualquier caso, se debe tener en cuenta que sólo pueden crearse hasta 32 reglas de puerto. Una vez que hemos creado 32 reglas de puerto, el botón Add queda deshabilitado, y ya no es posible crear más reglas de puerto.
Es importante recordar que un Cluster NLB puede utilizar una o varias direcciones IP virtuales, de tal modo, que las reglas de puerto pueden afectar a una dirección IP virtual o a todas las direcciones IP virtuales del Cluster NLB.
Del mismo modo, también es importante recordar que los puertos no definidos por las reglas de puerto, serán servidos por el Nodo por Defecto (Default Host). En ocasiones, se puede caer en el error de pensar que si no definimos un puerto en ninguna regla de puerto, estaremos consiguiendo que las conexiones a dicho puerto sean rechazas. Este es un error de concepto, ya que serán despachadas por el Nodo por Defecto (Default Host), de tal modo, que si en dicha máquina el puerto está a la escucha, será posible el acceso. Si se desea que las conexiones a algún puerto sean rechazadas, es necesario crear una regla de puertos con la opción de filtrado Disable this port range.
Las propiedades a configurar en las reglas de puerto son:
- Cluster IP Address. Dirección IP virtual (Virtual IP) utilizada para la regla de puertos. Es decir, en un Cluster NLB, podemos utilizar una dirección IP virtual (compartida por todos los Nodos del Cluster NLB – caso habitual), o bien utilizar varias direcciones IP.
En caso de utilizar varias direcciones IP, podemos configurar cada regla de puertos para una dirección IP virtual en particular, o bien, para todas la direcciones IP del Cluster NLB.
- Port Range. Rango de puertos a los que se desea aplicar la regla de puertos. Si se desea especificar un único puerto, es suficiente con especificar el mismo puerto en los campos From y To. Si queremos cubrir varios puertos no consecutivos, deberemos crear varias reglas de puerto.
- Protocols. Permite especificar si se desea cubrir puertos TCP, UDP, o ambos.
- Filtering Mode. Determina la Afinidad, es decir, cómo las peticiones (el tráfico de red) son balanceadas hacia un Nodo (Host) u otro del Cluster NLB.
- Multiple Host. Esta es la opción por defecto. Las peticiones entrantes de los clientes, se distribuirán entre los distintos Nodos del Cluster NLB, pudiendo personalizarse el peso deseado para cada Nodo, para aquellos casos en que NO se desee un reparto equitativo entre todos los Nodos del Cluster (ej: 80% - 20%), por ejemplo, porque existan Nodos con capacidad hardware sensiblemente superior. En cualquier caso, la configuración más importante es la configuración de Afinidad (None, Single, Class C).
- Single Host. Todas las peticiones entrantes son dirigidas a un único Nodo (Host) del Cluster NLB. El Nodo utilizado se eligirá en función del valor de la propiedad Handling Priority. Es interesante recordar que la propiedad Handling Priority, sólo se puede especificar editando la regla de puerto a nivel de cada Host, y no a
nivel del Cluster. En consecuencia, esta configuración sólo ofrece tolerancia a fallos, y no permite distribuir la carga.
- Disable this port range. Permite denegar el acceso al rango de puertos especificado, por ejemplo, por motivos de seguridad, ya que los rangos de puertos que NO estén cubierto por ninguna regla de puerto, serán despachados por el Nodo por Defecto (Default Host).
Otra propiedad de gran importancia es la Prioridad en las Reglas de Puerto, ya sea la propiedad Load weight del filtrado Multiple host, o bien, la propiedad Handling priority del filtrado Single Host. Es decir, por un lado está la prioridad de cada Nodo (Host) del Cluster (Host Priority), que se trata de una propiedad de cada Host, y NO de una propiedad de las reglas de puerto, y cuyo fin es definir cuál es el Nodo por Defecto (Default Host) para servir las peticiones que no estén definidas por ninguna regla de
puertos. Aclarado éste aspecto, es importante también recordar que la Prioridad en las Reglas de Puerto, NO se puede ver/configurar a través de las reglas de puertos del diálogo de propiedades del Cluster, pues al visualizar las Reglas de Puerto a través de las Propiedades de Cluster, esta información NO aparece (como se muestra en la anterior pantalla capturada). Por el contrario, es posible ver/configurar la Prioridad de las Reglas de Puerto, a través de las propiedades de cada Host, en cuyo caso, al editar las reglas de puerto SI se muestra ésta información y es posible su modificación, como se muestra en la siguiente pantalla capturada.
De éste modo, en un Cluster NLB formado por varios Nodos (Hosts) podemos definir múltiples reglas de puerto, y en cada regla de puerto asignar mayor prioridad a un Nodo o a otro (ej: con dos Nodos en un Cluster NLB con modo de filtrado Multiple Host, asignar el 80% de carga a un Nodo y el 20% restante al otro Nodo).
Por defecto en el modo de filtrado Multiple Host, todos los Nodos tienen la misma prioridad, con el fin de repartir por igual la carga. La configuración recomendada y habitual, suele ser esta, en conjunto con la utilización de máquinas gemelas (ej:
montar un Cluster NLB de cuatro nodos formado por cuatro servidores HP Blade 35p con las mismas características hardware y software).
Es importante recordar que al realizar cambios en las reglas de puerto, se produce la Convergencia del Cluster NLB.
Afinidad en Cluster NLB
El concepto de Afinidad en un Cluster NLB se refiere al modo en que se balancea la carga de tráfico de red entre los Nodos del Cluster NLB. Esta propiedad NO es una propiedad del Cluster NLB, sino que por el contrario es una propiedad de la Regla de Puertos (port rule) del Cluster NLB en el modo de filtrado Multiple Host (que es el modo de filtrado habitual).
Es necesario estudiar el tipo de solicitudes que va a recibir nuestro Cluster NLB, para poder decidir correctamente el tipo de Afinidad que necesita nuestra instalación. Es decir, nos interesa conocer:
- Si las sesiones que van a establecer nuestros clientes con nuestro Cluster NLB van a ser o no a través de múltiples puertos.
- Si nuestros clientes atraviesan algún Array de Proxys, y en caso de que sea así, si dichos Proxys realizan NAT (lo cual es habitual) y/o si utilizan una o varias direcciones IP externas (lo habitual, una única dirección, pero nos podemos encontrar de todo).
- Si nuestros clientes pueden acceder a través de distintas direcciones IP. Por ejemplo, que un usuario que se conecta a través de una dirección IP (ya sea obtenida por el DHCP de su ISP, por el Proxy/NAT de turno, por el DHCP de un segmento particular de nuestra LAN, etc.) se pueda desconectar y se vuelve a conectar con una dirección IP distinta.
- En caso de aplicaciones Web (o de otras similares), si es necesario mantener la sesión a través del Cluster NLB, o es la aplicación capaz de mantener una información de sesión compartida entre todos los Nodos.
Con todo esto claro, podemos empezar a evaluar las diferencias existentes entre las distintas opciones de configuración:
- None. El balanceo se realiza en función de la dirección IP y puerto (TCP/UDP) de la conexión entrante. Generalmente es el modo preferido para aplicaciones que no mantienen estado (ej: la sesión de las aplicaciones Web), es decir, que cada petición puede ser resuelta por cualquiera de los Nodos (Host) del Cluster NLB. En dicho caso, se produce menos sobrecarga en el NLB, debido a que el proceso de enrutamiento o balaceado es más ligero. Esta opción realiza un rebalanceo mucho más eficiente que el resto de las opciones de Afinidad, sin embargo, no todas las aplicaciones pueden aprovecharse el tipo de Afininidad None, en cuyo caso, será necesario resignarse y utilizar un tipo de Afinidad menos eficiente para poder conseguir los beneficios del NLB (alta disponibilidad y balanceo de carga – aunque sea un poquitín menos eficiente)
- Single. El balanceo se realiza en función de la dirección IP del cliente, redireccionándose todas las conexiones de la misma dirección IP al mismo Nodo (Host) del Cluster NLB.
La configuración de Afinidad Single es recomendable si los servicios que ofrecemos a través del Cluster NLB utilizan sesiones a través de múltiples puertos. Así, resulta recomendable para ofrecer servicios de conexión VPN (tanto L2TP/IPSec como PPTP), para garantizar que todas las conexiones del mismo cliente son dirigidas al mismo Nodo del Cluster NLB. La Afinidad Single es también recomendable para aplicaciones que requieren estado (ej:
la sesión de las aplicaciones Web), como ocurre con las conexiones SSL utilizadas por HTTPS.
En el caso de que un gran conjunto de clientes accedan a nuestro Cluster NLB a través de un único Proxys (haciendo NAT), serán
re-direccionados todos éstos clientes al mismo Nodo (Host) del Cluster NLB, comportamiento que puede implicar tener un Nodo más sobrecargado que el resto, es decir, puede implicar que el balanceo de carga de red no distribuya correctamente la carga de red (es decir, funciona pero con riesgo de que el balanceo no sea equitativo). En esta situación, probablemente no estemos consiguiendo el comportamiento deseado.
En el caso de que los clientes accedan a nuestro Cluster NLB a través de un Array de Proxys (haciendo NAT) con distintas direcciones IP, podrían ser re-direccionados a distintos Nodos (Host) del Cluster NLB en función de la dirección IP del Proxy a través el cual salen, lo cual en función del protocolo y aplicación que estemos configurando en nuestro Cluster NLB, podría resultar en una configuración errónea (en este caso, es preferible la Afinidad Class C).
- Class C. El balanceo se realiza en función de los 24 bits más significativos de la dirección IP del cliente, redireccionándose todas las conexiones de la misma subred al mismo Nodo (Host) del Cluster NLB.
En el caso de que los clientes accedan a nuestro Cluster NLB a través de un Array de Proxys (haciendo NAT) con varias direcciones IP externas, serán re-direccionados al mismo Nodo (Host) del Cluster NLB.
Otro detalle a considerar con la Afinidad Single y Class C, es el impacto del proceso de Convergencia. Por poner un ejemplo gráfico, si disponemos de una aplicación con estado, y un cliente está accediendo a través del Nodo A, en caso de que se ejecute el proceso de Convergencia, podría ocurrir que después de la Convergencia,
dicho cliente empiece a acceder al Cluster NLB a través del Nodo B. En este caso, el usuario notará (por poner un ejemplo) que tiene que volver a hacer logon en la aplicación, dado que la sesión no se mantiene entre los distintos Nodos del Cluster NLB, y está empezando a ser despachado por un Nodo del Cluster distinto al de sus anteriores conexiones.
La opción de Afinidad más óptima, siempre será la Afinidad None. Sin embargo, no siempre será la mejor opción, dependiendo de la aplicación y protocolo que deseamos balancear. Así, sabemos que L2TP/IPSec, PPTP, SSL ó HTTPS, las aplicaciones ASP con estado, etc., se deben configurar con Afinidad. Recordar que ASP (al contrario que ASP.Net) no dispone de ningún mecanismo para gestionar la sesión a través de múltiples servidores. En caso de una aplicación ASP que no utilice estado será posible utilizar Afinidad None, pero en caso contrario, o se utiliza Afinidad Single, o se desarrolla un mecanismo para almacenar la sesión entre múltiples servidores (ej:
utilizando una base de datos como SQL Server). Por suerte, ASP.Net ofrece varios mecanismos para gestionar el estado entre múltiples servidores: utilizar el servicio de estado (State Service) en un servidor separado, o bien, utilizar SQL Server para almacenar la información de estado. De hecho, siempre se deben utilizar estos mecanismos de gestión del estado en ASP.Net, debido a que permiten sobrevivir de reinicios de las aplicaciones Web (ej: cambios en el Web.Config, reciclaje del Pool de Aplicaciones - Application Pool -, etc).
En el caso de Terminal Server, si se está utilizando Session Directory es posible utilizar Afinidad None. En caso contrario, si NO se está utilizando Session Directory se debe utilizar Afinidad Single. Con esta configuración, funcionará correctamente Terminal Server, incluso los usuarios podrán reconectarse a sus sesiones desconectadas.
Recomendaciones
1. Es recomendable utilizar dos o más tarjetas de Red en cada Cluster HOST, cada una con su propia dirección IP. Este tipo de configuraciones aporta dos tipos de ventajas:
a. Permitir la creación de múltiples Clusters NLB (ej: una tarjeta de red para la gestión del servidor, y cada una de las tarjetas de red adicionales para la creación de un Cluster NLB adicional).
b. Utilizar varias tarjetas en cada Nodo para manejar el tráfico del mismo Cluster NLB. Es decir, del mismo modo que es posible formar un Cluster NLB con dos Nodos, utilizando una tarjeta de red de cada uno de los nodos, evaluar la posibilidad de utilizar dos o más tarjetas de red en cada Nodo (Host) para forma el Cluster NLB, y así poder ofrecer un mejor tiempo de respuesta.
Si decidimos utilizar múltiples tarjetas de Red, es muy recomendable utilizar una tarjeta de red dedicada para la gestión del servidor (muy recomendable, pero NO es un requisito). Este adaptador de red será utilizado para la comunicación con los equipos Host del Cluster NLB, como por ejemplo, conexión por Terminal Server, administración del Cluster NLB a través de la herramienta administrativa Network Load Balancing Manager (NLBMgr.exe), etc. Así, podemos utilizar el resto de tarjetas de red para formar uno o varios Clusters NLB, cada uno con la configuración más apropiada para su fin.
La utilización de una tarjeta de red dedicada para la gestión del servidor es especialmente útil si se está utilizando el modo de operación del Cluster NLB en Unicast, ya que si los Host del Cluster sólo disponen de una única tarjeta NLB y ésta se configura en modo Unicast, éstos no se podrán ver entre ellos (no es posible la comunicación entre los miembros del Cluster NLB, debido a que ambos tendrán la misma dirección MAC) y adicionalmente, el tráfico dirigido a un Host particular del Cluster NLB
genera una sobrecarga adicional de tráfico de red sobre todos los equipos miembros del Cluster NLB (por el mismo motivo, es decir, por compartir la misma MAC). Por ello, es muy recomendable disponer de múltiples tarjetas de red, aunque NO es un requisito.
En caso de utilizar dos tarjetas de red (una dedicada para la gestión del servidor y otra para formar el Cluster NLB), se debe configurar en la tarjeta de red utilizada para formar el Cluster NLB, y sólo en ésta tarjeta (en las demás se debe dejar sin configurar):
a- El/los servidores DNS utilizado. No configurar servidores DNS en el resto de tarjetas de red.
b- Habilitar la opción de registro en DNS (Register this connection’s addresses in DNS). Mantener esta opción deshabilitada en el resto de tarjetas de red.
c- La puerta de enlace (Gateway). No configurar la puerta de enlace (Gateway) en el resto de tarjetas de red.
Especialmente interesante, la configuración de la puerta de enlace, como se muestra en elArtículo de Soporte de Microsoft KB 193602.
Adicionalmente, se recomienda que la tarjeta de red dedicada para la gestión, y la tarjeta de red utilizada para formar el Cluster NLB, deben pertenecer a distintos segmentos de red.
En caso de utilizar una única tarjeta de red y configurar el Cluster NLB en modo de operación Unicast, es recomendable utilizar la herramienta administrativa NLB Manager desde un equipo independiente al Cluster NLB, para evitar así los problemas derivados de sobrescribir la MAC.
Además, en caso de utilizar una única tarjeta de red en cada Nodo del Cluster NLB, utilizar afinidad Unicast, y necesitar que los Nodos del
Cluster NLB se comuniquen entre sí (intra-host communication), es posible establecer la entrada del registro UnicastInterHostCommSupport a 1 para cada una de las tarjetas de red en cada Nodo del Cluster NLB, es decir, en las ramas HKLM\ System\ CurrentControlSet\ Services\ WLBS\
Parameters\ Interface\ {GUID}.
2. No habilitar el Control Remoto del NLB (Network Load Balancing remote control). Esta opción de control remoto, presenta riesgos de seguridad, siendo muy recomendable mantener dicha opción deshabilitada.
3. Habilitar el Log del Cluster NLB, en cada Nodo (Host) del Cluster NLB.
Esta es un recomendación de Microsoft. Con esto, se permite registrar cada evento del Cluster NLB sobre un fichero de texto, resultando de gran utilidad en la resolución de problemas. Esta opción de configuración está disponible abriendo la herramienta administrativa Network Load Balancing Manager (NLBMgr.exe), a través del menú Options -> Log Settings, como se muestra en el siguiente cuadro de diálogo (es necesario habilitar el logging – Enable logging - y especificar el nombre completo del fichero de log deseado):
4. Garantizar y comprobar que todos los Nodos (Host) del mismo Cluster NLB pertenecen a la misma subred (mismo segmento Ethernet) y que todos los clientes del Cluster NLB son capaces de acceder a dicha subred.
5. No habilitar un Cluster NLB en un equipo miembro de un Cluster MSCS.
Esta configuración no está soportada por Microsoft. Es decir, en caso de utilizar dicha configuración, no será posible disfrutar del servicio de Soporte de Microsoft. Uno de los motivos, es que el uso de la red realizado por Microsoft NLB y Microsoft Cluster MSCS, puede producir interferencias entre ambos productos.
6. No habilitar DNS, DHCP ni WINS sobre un Cluster NLB.
Virtualización
La virtualización es un término muy amplio, que actualmente se emplea para referirse a una tecnología reciente, pero si nos remontamos hasta su definición nos daremos cuenta de que es un término que se adapta a muchos de los grandes esfuerzos dentro de la informática.
“La virtualización es la abstracción de recursos en un sistema informático”.
1Para aclarar un poco este término tan genérico podemos reflejar que podemos estar hablando tanto de virtualización de recursos como de servidores o PCs.
Virtualización de Recursos:
Durante mucho tiempo, sobre todo en los inicios de la informática, los recursos de los que disponía una máquina eran escasos, por lo que la virtualización nació para intentar suplir dichas carencias, emulando componentes mediante software, como por ejemplo las tarjetas de red de una máquina, que se pueden emular por software aunque realmente solo poseamos una, pero hacer creer al sistema, que tenemos el número deseado de ellas.
Virtualización de Servidores:
También llamadas máquinas virtuales, que son la encapsulación completa de los recursos de una máquina, y que permiten su funcionamiento autónomo como una pieza de software. Hay que tener en cuenta que esta tecnología está avanzando a gran velocidad en los últimos años, por lo que lo aquí expuesto puede no reflejar las últimas actualizaciones en cuanto a sistemas de virtualización y soporte de máquinas virtuales.
1 Definición de Virtualización: Wikipedia: http://es.wikipedia.org/wiki/Virtualización
Como punto fuerte de la virtualización de servidores podemos destacar la completa estanqueidad de la pieza de software, que nos permite la instalación de un sistema operativo, con todas sus aplicaciones y recursos completamente independizados de la máquina base.
Por último dentro de la introducción a la virtualización aclarar que la virtualización es un esfuerzo orientado al aprovechamiento de los recursos de la máquina base con el fin del ahorro de costes, espacio y energía. En los capítulos siguientes se mostrará como este tipo de tecnologías en el mundo actual ayudan al ahorro de grandes cantidades de energía en los CPDs y rentabilizan las grandes inversiones en equipamiento que realizan las empresas.
Vmware ESX
“Esta versión es un sistema complejo de virtualización, pues corre como sistema operativo dedicado al manejo y administración de máquinas virtuales dado que no necesita un sistema operativo host sobre el cual sea necesario instalarlo. Pensado para la centralización y virtualización de servidores, esta versión no es compatible con una gran lista de hardware doméstico, por ejemplo no reconoce los disco IDE como unidades de almacenamiento y seria inútil instalarlo en este tipo de discos (en la versión 3.5 ya esta soportado sata). Es realmente útil, ya que solamente ocupa 10 Mb de Ram y 55 de Disco Duro, aproximadamente... Para su administración, hay que instalar un software en una máquina remota, que se conecta por entorno web.”2
VmWare ESX es un sistema operativo basado en Linux Red Hat, lo que le proporciona gran estabilidad, modificado para ocupar lo mínimo posible, así como utilizar el mínimo imprescindible para sostener las máquinas virtuales, por ello han eliminado todo lo que no es necesario para las máquinas virtuales. Además incluye un conjunto de utilidades que actúan como capa de acceso a todo el hardware que proporcionan la virtualización. Utiliza un sistema de ficheros propio, VMFS en el que se almacenan los discos virtuales de cada máquina virtual y que se puede compartir entre varios
servidores ESX.
2 Definición de Virtualización: Wikipedia: http://es.wikipedia.org/wiki/VMware
Instalaciones
Instalación ESX
Antes de comenzar la instalación se ha de tener en cuenta que este Sistema Operativo está diseñado para servidores, por lo que no es compatible con la mayoría del Hardware de los PCs caseros. En la Web de Vmware se puede encontrar la lista completa del Hardware compatible con ESX (http://www.vmware.com/pdf/vi3_systems_guide.pdf.)
La instalación que se va a realizar es de un sistema Vmware ESX 3.5, para lo cual se requiere descargarse el CD de la página Web de Vmware ( www.vmware.com).
Una vez grabado en un CD, se procede a arrancar desde el mismo, siendo necesario en algunas ocasiones la modificación de la configuración de la Bios del Servidor para que arranque en primer lugar desde el CD-ROM.
Instalación Gráfica
En la pantalla aparece un menú para seleccionar el tipo de instalación, se selecciona “Graphical Mode” para simplificar las configuraciones.
El primer procedimiento es la verificación del Disco de la instalación, paso que puede ser omitido para ahorrar tiempo.
Pasados unos segundos aparece la primera de las ventanas de la instalación gráfica, y que nos presenta el producto que se va a instalar. “Next” para continuar con la instalación.
Se selecciona el idioma, es este caso “Spanish” y “Next” para continuar.
La selección del ratón no es crítica, por lo que si desconocemos el tipo de ratón que usará el servidor no se cambia nada. “Next” para continuar.
Aparecerá una ventana de confirmación en la que se pide autorización para borrar todo el disco donde se va a proceder a la instalación del Sistema Operativo.
“Yes” si se desea crear una única partición para el Sistema Operativo.
El acuerdo de Licencia debe ser leído atentamente antes de aceptarlo. “Next”
para continuar.
Si se desea una única partición de disco se selecciona “Recomended”, de lo contrario se puede editar la tabla de particiones seleccionando “Advanced”. Se debe tener cuidado con los discos que se selecciona para formatear, ya que el servidor puede tener conectadas unidades iSCSI, SAN, etc. Y es posible que sean detectadas en este punto, pudiendo perderse datos, modificar el sector de arranque u otros problemas.
“Next” para continuar.
Establecida la configuración de las particiones, solicita confirmación para aplicar los cambios a través de esta ventana de confirmación. “Yes” para continuar.
Se muestra un resumen de cómo quedará la tabla de particiones de los discos, permitiéndose modificar las particiones, opción no recomendada, pues ya ha creado la estructura óptima de particiones. “Next” para continuar.
Si se desea modificar el Grub de arranque se puede marcar la casilla ”Edit Default Bootloader Configuration” y permitirá editar tanto el disco como la partición desde la que se iniciará el MBR. No se recomienda modificar nada en este punto.
“Next” para continuar.
Como se está tratando con servidores de una cierta importancia dentro de la estructura empresarial, no es recomendable el uso de IPs dinámicas, por lo que en este punto es el momento de configurar cada una de las tarjetas de Red del servidor, se han
de configurar todos los parámetros de la configuración IP, y en caso de que fuera necesario también la VLAN a la que pertenece ese puerto. Se puede seleccionar también si deseamos que esta tarjeta de red sea la seleccionada por defecto para el tráfico de red de las máquinas virtuales.
Se selecciona la localización geográfica del servidor para poder establecer las configuraciones de horario necesarios. “Next” para continuar.
La cuenta creada por defecto es la de “root”, es este sistema operativo, dicha cuenta, no puede no tener contraseña, por lo que debemos establecerla llegados a este punto. “Next” para continuar.
Se muestra una ventana de comprobación de todos los datos establecidos durante este procedimiento de instalación. Una vez revisado “Next” para comenzar con la instalación.
Terminada la instalación informa de la dirección en la cual se puede realizar el mantenimiento de este servidor. “Finish” para termiar.
A través de un navegador se puede acceder a la dirección antes mencionada, y realizar la instalación del software de gestión. Lo primero es aceptar el certificado de seguridad de la máquina.
Instalación del Infraestructure Client
Para la instalación del Infraestructure Client, o cliente de Administración, se pude optar por dos opciones, ejecutar el instalador que se descargar de la página web de VMware, u optar por la instalación desde la interface Web del servidor ESX que se desea administrar. La única diferencia en las dos instalaciones es el punto de inicio, pues el resto de la instalación depende del instalador ejecutado.
Para el acceso Web, solamente se debe escribir en el navegador la dirección IP del servidor ESX puesto que por defecto en el puerto 80, el servidor tiene un frontal para la instalación tanto del Infraestructure Client como para la instalación del Virtual Center, ambas herramientas para la gestión de servidores ESX.
Para descargar el instalador solamente se ha de descargar el enlace “Download VMware Infraestructure Client”, comenzando así el asistente de instalación.
Tras aceptar la licencia marcando la opción de “I accept the terms in the license agreement”, “Next” para continuar.
La instalación requiere un nombre de usuario y un nombre de organización para poder continuar con la instalación. “Next” para continuar.
No es necesario cambiar la ruta de instalación salvo que los requerimientos del sistema donde se está instalando lo requieran. “Next” para continuar.
Presionando “Install “ se inicia la instalación.
Para terminar la instalación presionar “Finish” que cierra el instalador.
En el escritorio la aplicación deja un acceso directo para iniciar la aplicación.
Al iniciar el programa se abre una ventana para introducir los datos del servidor, su IP, el nombre del usuario que tiene permisos de conexión y la conexión.
