Este artículo le presentará cómo hacer un análisis de la carga suave de 7 capas en Windows, está interesado en la carga de esta pieza, puede venir y ver. De hecho, las llamadas cuatro capas son balanceo de carga basado en puertos IP +, la séptima capa es balanceo de carga basado en información de capa de aplicación como URLs, tiene una impresión superficial en la capa 7, y todos tienen la experiencia de hacer 7 capas de carga suave. Compartir, por supuesto, es mejor bajo la plataforma de Windows.
Performance Analysis
1. Administración de conexiones y resolución de protocolos para redes externas. Mediante el uso del mecanismo integrado http.sys (HttpApi.dll, HttpListener), http.sys realiza la administración de conexiones HTTP y el análisis de protocolos a nivel de kernel. El rendimiento debe ser Garantizado
2, el paquete interno de administración y consolidación de la conexión RealServer de la red mediante el mecanismo incorporado HttpWebRequest, pero los siguientes problemas
a) administración de la conexión: el proxy predeterminado para enviar una solicitud establecerá una nueva conexión, recibirá una respuesta La conexión se elimina, lo que significa que se establecerá una gran cantidad de conexiones entre el Proxy y el RealServer, pero debido a la limitación del puerto (65535), la conexión de salida no puede ser demasiado. Para resolver este problema, puede intentar habilitar KeepAlive para resolver RealServer.
b) Paquete: Después de que HttpListener reciba el paquete, se resolverá automáticamente con el objeto, pero también reenvasará el paquete en el formato HttpWebRequest y lo enviará a RealServer, que incluye la copia de Uri, HttpHeader, Cookies, Body, etc. La cantidad de datos es bastante grande y es seguro que perderá rendimiento en la memoria. Este problema debe ser inevitable.
3, si es una aplicación web normal (clase de acceso a recursos), la solicitud es pequeña, la respuesta es muy grande, RealServer también pasará por el proxy cuando devuelva la respuesta, pero también para copiar la memoria, esto también afecta el rendimiento. Luego, la Capa 7 no puede hacer el mecanismo DirectRoute de LVS (necesita modificar la dirección mac del paquete de red), y la transición de estado del túnel IP y TCP necesita modificar la pila de protocolos TCP /IP del sistema operativo. Dado el costo, el problema no es eludido.
4, el protocolo Http estipula que la solicitud y la respuesta deben aparecer en pares. De forma predeterminada, después de que se envía una solicitud en una conexión, la siguiente solicitud puede enviarse después de recibir la respuesta correspondiente a la solicitud. Aunque Http1.1 tiene una función de canalización, Las solicitudes pueden enviarse en lotes sin tener que esperar una respuesta, pero también hay muchas restricciones, como estipular que la POST no debe usar una canalización, la primera vez que se envía una conexión, no se puede usar el mecanismo de la tubería y no se puede realizar el número de solicitudes por lote. Bueno, después de enviar la solicitud de forma masiva, si se interrumpe la conexión, fallarán varias solicitudes, y así sucesivamente. El protocolo HTTP no coincide con la solicitud y la respuesta de CallID y Cseq como el protocolo SIP, por lo que la solicitud y la respuesta pueden enviarse y recibirse de forma asincrónica, de modo que cuando se implementa la pila del protocolo Http, la respuesta se espera de forma sincrónica y luego se puede enviar el siguiente lote de solicitudes a la conexión. Esto inevitablemente afectará el rendimiento. La solicitud de recepción y envío asíncrono de HttpListener es el modo APM ordinario (BeginXXX, formato EndXXX), este modo asíncrono generará y destruirá un gran número de objetos IAsyncRequest cuando se llama con frecuencia, lo que aumenta la presión del GC y IAsyncRequest El objeto todavía no proporciona una interfaz agrupada personalizada. Si HttpListener proporciona un nuevo modo asíncrono basado en eventos (modo XXXAsync (eventargs), consulte el método Socket.ReceiveAsync) resolverá este problema.
6, además, debido a que HttpLisenter es una clase envoltura de .net, se ejecuta en modo de usuario y HTTP.SYS se ejecuta en modo de núcleo. Al aceptar una solicitud, devolver una respuesta cambiará entre modo de usuario y modo de núcleo dos veces. Reduzca el rendimiento, si puede realizar directamente el reenvío de 7 capas en el estado del kernel, LVS (KTCPVS) puede lograr el reenvío de 7 capas basado en contenido basado en el kernel en Linux. Es posible que deba realizar el desarrollo de TDI o NDIS en Windows. Parte de la información es demasiado complicada, así que no lo pienso primero.
Análisis de confiabilidad
Para brindar tolerancia a los desastres y mejorar la confiabilidad, considere los siguientes esquemas. 1. 1. 7 capas de carga blanda deben tener 4 capas de dispositivos de carga, 7 capas de carga blanda y una estrategia de hashing compartido. El dispositivo de la 4ª capa realiza una carga aleatoria de acuerdo con la sesión, de modo que las 7 capas de las máquinas de carga suave pueden manejar correctamente cualquier solicitud, y después de que una carga suave de 7 capas está inactiva, las 7 capas restantes de la carga suave pueden continuar trabajando, debido a 4 La carga de capa tiene una función keepalive, que puede detectar qué carga suave de 7 capas está inactiva y no le envía solicitudes.
2. La carga suave de 7 capas es doble clic en espera activa, y la carga suave de 7 capas está conectada directamente a la red externa. En circunstancias normales, el servidor primario procesa la solicitud. Si el servidor primario está inactivo, el servidor de respaldo descubre y obtiene el servidor primario a través de la falsificación ARP. La IP original se usa para atraer la solicitud al servidor de respaldo (el hardware puede admitir las máquinas primarias y de respaldo para compartir una dirección MAC si es compatible), y la solicitud de tiempo corto puede fallar cuando se produce el cambio activo /en espera.
Consideración integral, el segundo programa tiene algunas cabañas y ningún seguro, dando prioridad a la primera opción.