UNIVERSIDAD ALFONSO X EL SABIO

Transcripción

1 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

2

3 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.: 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 DEL PROYECTO FIRMA DEL ALUMNO

4 Índice Balanceo de carga de Red... 5 Networking Load Balancing (NLB)... 5 Funcionamiento Granjas de Servidores Web y Network Load Balancing Configuración y Administración de un Cluster NLB Modo de operación NLB (Cluster operation mode): Unicast o Multicast Propiedades de cada Host Las Reglas de Puerto (Port Rules) Afinidad en Cluster NLB Recomendaciones Virtualización Vmware ESX Instalaciones Instalación ESX... 39

5 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 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.

6 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

7 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.

8 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 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.

9 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.

10 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).

11 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 reenviarlos). 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

12 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).

13 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

14 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.

15 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

16 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).

17 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.

18 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

19 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).

20 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.

21 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

22 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).

23 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.

24 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