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

Cluster NLB: ¿Qué son las reglas de puerto (port rules)? ¿Cómo configurar las reglas de puerto?

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


En este capítulo se explican las Reglas de Puerto del Cluster NLB, sus conceptos y sus consideraciones cara a su configuración. ¿Cuántas reglas de puerto podemos configurar en un Cluster NLB? ¿Cuántas direcciones IP podemos utilizar en nuestras Reglas de Puerto? ¿Qué ocurre con las peticiones no cubiertas por ninguna Regla de Puerto? ¿Qué es el modo de filtrado (filtering mode) de una Regla de Puerto en un Cluster NLB? ¿Es posible configurar varias Reglas de Puerto con distinta Afinidad? ¿Es posible dar más peso a un Nodo que a otro en un Cluster NLB para repartir de forma no equitativa la carga de trabajo?

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 servidor 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), a la cual está reservado un apartado completa del presente Artículo (ver más adelante).
    • 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.

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



Comentarios

jeancc - 04/08/2011 (UTC)
Hola guille,

después de leer este artículo, no me queda claro de dónde sale la ventana primera (la que no lleva 'load weigth' y 'handling priority'), y tampoco veo dónde se le da más peso a un nodo que a otro, ya que sólo tenemos una casilla para indicar un porcentaje en la segunda ventana.

Por cierto, ¿qué es el check 'Equal'?

Gracias.


GuilleSQL - 04/08/2011 (UTC)
Hola Jeancc,

La primera ventana, se muestra al añadir o editar una regla de puerto (Port Rule) a nivel del Cluster NLB, por ejemplo, tras mostrar las propiedades de un Cluster NLB, en la pestaña Port Rules.

La segunda ventana, se muestra al añadir o editar una regla de puerto (Port Rule) a nivel de Host, por ejemplo, tras mostrar las propiedades de un Host, en la pestaña Port Rules.

Saludos,
Guille



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.