GuilleSQL :: Microsoft SQL Server, SSIS, y más !!

Cluster NLB: Propiedades de cada Host

Volver a: [Instalar y Configurar Microsoft Cluster NLB (Network Load Balancing) en Windows Server 2003]


Este capítulo detalla la configuración propia de cada Nodo (Host) del Cluster NLB. Del mismo modo que existen configuraciones propias del Cluster NLB como conjunto, existen propiedades propias de cada Nodo. Aquí se explica principalmente el concepto de Prioridad de los Nodos del Cluster NLB, así como el concepto del Nodo por Defect (Default Host) del Cluster NLB. Del mismo modo, se explican otras propiedades de menor importancia.

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

Volver a: [Instalar y Configurar Microsoft Cluster NLB (Network Load Balancing) en Windows Server 2003]


Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  771 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160

Social Networks
Sigue a Portal GuilleSQL en Linkedin !!
Sigue a Portal GuilleSQL en Twitter !!



Archivo

Marzo de 2017 (3)
Enero de 2017 (4)
Junio de 2016 (1)
Mayo de 2016 (2)
Abril de 2016 (2)
Septiembre de 2015 (2)
Agosto de 2015 (2)
Junio de 2015 (10)
Mayo de 2015 (4)
Abril de 2015 (8)
Marzo de 2015 (11)
Octubre de 2014 (3)
Septiembre de 2014 (7)
Agosto de 2014 (5)
Julio de 2014 (2)
Mayo de 2014 (4)
Abril de 2014 (4)
Marzo de 2014 (4)
Febrero de 2014 (1)
Enero de 2014 (5)
Diciembre de 2013 (8)
Noviembre de 2013 (2)
Octubre de 2013 (7)
Septiembre de 2013 (6)
Agosto de 2013 (1)
Julio de 2013 (6)
Junio de 2013 (11)
Mayo de 2013 (7)
Abril de 2013 (6)
Febrero de 2013 (5)
Enero de 2013 (7)
Diciembre de 2012 (12)
Noviembre de 2012 (13)
Octubre de 2012 (5)
Septiembre de 2012 (3)
Agosto de 2012 (6)
Julio de 2012 (4)
Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Copyright © 2007 GuilleSQL, todos los derechos reservados.