¿Le resultó útil esta página?
Sus comentarios sobre este contenido son muy importantes. Háganos saber su opinión.
¿Tiene comentarios adicionales?
Caracteres restantes: 1500
Exportar (0) Imprimir
Expandir todo

Esquema LoadBalancerProbe

Actualizado: abril de 2015

El sondeo de equilibrador de carga es un sondeo de estado definido por el cliente de los extremos UDP y los extremos en las instancias de rol. El elemento LoadBalancerProbe no es un elemento independiente; se combina el rol web o el rol de trabajador en un archivo de definición de servicio. Un LoadBalancerProbe se puede utilizar en varios roles.

La extensión predeterminada para el archivo de definición del servicio es .csdef.

El equilibrador de carga de Azure es responsable de dirigir el tráfico de entrada a las instancias de rol. El equilibrador de carga determina qué instancias pueden recibir tráfico sondeando periódicamente cada instancia para determinar el estado de la misma. El equilibrador de carga sondea cada instancia varias veces por minuto. Hay dos opciones diferentes para proporcionar los estados de la instancia al equilibrador de carga, el sondeo del equilibrador de carga predeterminado o un sondeo personalizado del equilibrador de carga que se implementa definiendo el LoadBalancerProbe en el archivo .csdef.

El sondeo del equilibrador de carga predeterminado utiliza al agente invitado dentro de la máquina virtual, que escucha y responde con una respuesta HTTP 200 CORRECTO cuando la instancia está en estado Preparada (esto es, la instancia no está en los estados Ocupada, Reciclando, Deteniéndose, etc.). Si el agente invitado no puede responder con HTTP 200 CORRECTO, el equilibrador de carga de Azure marca la instancia como no responde y deja de enviar tráfico a esa instancia. El equilibrador de carga Azure continuará haciendo ping a la instancia y, si el agente invitado responde con un HTTP 200, el equilibrador de carga Azure enviará tráfico a la instancia de nuevo. Al utilizar un rol web, el código del sitio web normalmente se ejecuta en w3wp.exe, que ni el tejido Azure ni el agente invitado supervisan, lo que significa que los errores en w3wp.exe (por ej., respuestas HTTP 500) no se notificarán al agente invitado y el equilibrador de carga no sabrá sacar esa instancia de la rotación.

El sondeo personalizado del equilibrador de carga invalida el sondeo predeterminado del agente invitado y le permite crear su propia lógica personalizada para determinar el estado de la instancia de rol. El equilibrador de carga sondeará periódicamente el extremo (cada 15 segundos, de forma predeterminada) y la instancia se considerará en rotación si responde con una TCP ACK o HTTP 200 en el período de tiempo de espera (el valor predeterminado es de 31 segundos). Esto puede ser útil para implementar su propia lógica con el fin de eliminar instancias de la rotación del equilibrador de carga, por ejemplo devolviendo el estado non-200 si la instancia está en el 90 % de la CPU. Para los roles web que utilicen w3wp.exe también significa que se obtiene la supervisión automática del sitio web, dado que los errores en el código del sitio web devolverán un estado non-200 al sondeo del equilibrador de carga. Si no se define un LoadBalancerProbe en el archivo .csdef, se utilizará el comportamiento predeterminado del equilibrador de carga tal como se ha descrito anteriormente.

Si utiliza un sondeo personalizado del equilibrador de carga deberá asegurarse de que la lógica tiene en cuenta el método RoleEnvironment.OnStop. Al utilizar el sondeo del equilibrador de carga predeterminado la instancia se sacará de la rotación antes de que se llame al OnStop, pero un sondeo personalizado del equilibrador de carga puede seguir devolviendo un 200 CORRECTO durante el evento OnStop. Si usa el evento OnStop para limpiar caché, detener el servicio, o realizar cambios de otro modo que pueden afectar al comportamiento en tiempo de ejecución del servicio, tendrá que asegurarse de que la lógica del sondeo del equilibrador de carga personalizado quitará la instancia de la rotación.

El formato básico de un archivo de definición del servicio que contiene un sondeo del equilibrador de carga es el siguiente.

<ServiceDefinition …>
   <LoadBalancerProbes>
      <LoadBalancerProbe name="<load-balancer-probe-name>" protocol="[http|tcp]" path="<uri-for-checking-health-status-of-vm>" port=”<port-number>” intervalInSeconds="<interval-in-seconds>" timeoutInSeconds="<timeout-in-seconds>"/> 
   </LoadBalancerProbes>
</ServiceDefinition>

El elemento LoadBalancerProbes del archivo de definición del servicio incluye los elementos siguientes:

El elemento LoadBalancerProbes describe la colección de sondeos del equilibrador de carga. Este elemento es el elemento primario del Elemento LoadBalancerProbe.

El elemento LoadBalancerProbe define el sondeo de estados para un modelo. Puede definir varios sondeos del equilibrador de carga.

En la tabla siguiente se describen los atributos del elemento LoadBalancerProbe:

 

Atributo Tipo Descripción

name

string

Requerido. Nombre de un sondeo del equilibrador de carga. El nombre debe ser único.

protocol

string

Requerido. Especifica el protocolo del extremo. Los valores posibles son http o tcp. Si se especifica tcp, es necesario recibir una ACK para que el sondeo sea correcto. Si se especifica http, es necesario recibir una respuesta 200 CORRECTO desde la URI especificada para que el sondeo sea correcto.

path

string

El URI que se usa para solicitar el estado de mantenimiento de la máquina virtual. El elemento path es obligatorio si protocol se establece en http. De lo contrario, no se permite.

No existe ningún valor predeterminado.

port

integer

Opcional. Puerto para comunicar el sondeo. Esto es opcional para cualquier extremo, pues el mismo puerto se utilizará a continuación para el sondeo. También puede configurar un puerto diferente para realizar los sondeos. Los valores posibles oscilan entre 1 y 65535, ambos incluidos.

El extremo establece el valor predeterminado.

intervalInSeconds

integer

Opcional. Intervalo, en segundos, de la frecuencia con la que sondear el extremo para el estado de mantenimiento. Normalmente, el intervalo es algo menos que la mitad del tiempo de espera asignado (en segundos), lo que permite realizar dos sondeos completos antes de sacar la instancia de rotación.

El valor predeterminado es 15, el valor mínimo es 5.

timeoutInSeconds

integer

Opcional. El tiempo de espera, en segundos, que se aplica al sondeo cuando no se obtiene ninguna respuesta dará lugar a que se interrumpa el envío posterior de tráfico al extremo. Este valor permite que los extremos se saquen de rotación más rápida o más lentamente que con los tiempos utilizados en Azure (que son los valores predeterminados).

El valor predeterminado es 31, el valor mínimo es 11.

Mostrar:
© 2015 Microsoft