Reliable Server Pooling ( RSerPool ) es un marco de protocolo informático para la gestión y el acceso a múltiples servidores coordinados (agrupados) . RSerPool es un estándar de la IETF desarrollado por el grupo de trabajo RSerPool de la IETF [1] y documentado en RFC 5351, RFC 5352, RFC 5353, RFC 5354, RFC 5355 y RFC 5356.
En la terminología de RSerPool, un servidor se denomina Elemento de Pool (PE). En su Pool, se identifica por su Identificador de Elemento de Pool (ID de PE), un número de 32 bits. El ID de PE se elige aleatoriamente al momento del registro de un PE en su pool. El conjunto de todos los pools se denomina Espacio de Identificación. En la literatura más antigua, se lo denominaba Espacio de Nombres. Esta denominación se ha eliminado para evitar confusiones con el Sistema de Nombres de Dominio (DNS). Cada pool en un espacio de identificador se identifica por un Identificador de Pool (PH) único, que se representa por un vector de bytes arbitrario. Generalmente, se trata de un nombre ASCII o Unicode del pool, por ejemplo, "Pool de Descargas" o "Pool de Servidores Web".
Cada espacio de nombres de dominio tiene un alcance determinado (por ejemplo, una organización o empresa), denominado Ámbito de operación. No es un objetivo explícito de RSerPool gestionar los grupos de Internet globales dentro de un único espacio de nombres de dominio. Debido a la localización de los Ámbitos de operación, es posible mantener el espacio de nombres de dominio "plano". Es decir, los PH no tienen ninguna jerarquía en contraste con el Sistema de nombres de dominio con su nivel superior y sus subdominios. Esta restricción da como resultado una simplificación significativa de la gestión del espacio de nombres de dominio.
Dentro de un ámbito de operación, el espacio de control es administrado por registradores de pool redundantes (PR), también denominados servidores ENRP o servidores de nombres (NS). Los PR deben ser redundantes para evitar que se conviertan en un punto único de falla (SPoF). Cada PR de un ámbito de operación se identifica por su ID de registrador (ID de PR), que es un número aleatorio de 32 bits. No es necesario garantizar la unicidad de las ID de PR. Un PR contiene una copia completa del espacio de control del ámbito de operación. Los PR de un ámbito de operación sincronizan su vista del espacio de control mediante el protocolo de redundancia de espacio de control de punto final (ENRP). Las versiones anteriores de este protocolo utilizan el término protocolo de redundancia de espacio de nombres de punto final; este nombre se ha reemplazado para evitar confusiones con el sistema de nombres de dominio (DNS), pero se ha mantenido la abreviatura. Debido a la sincronización del espacio de control por parte de ENRP, los PR de un ámbito de operación son funcionalmente iguales. Es decir, si alguno de los PR falla, cada uno de los demás PR puede reemplazarlo sin problemas.
Utilizando el Protocolo de acceso al servidor agregado (ASAP), un PE puede agregarse a un grupo o eliminarlo solicitando un registro o desregistro de un PR arbitrario del ámbito de operación. En caso de registro exitoso, el PR elegido para el registro se convierte en el PR local del PE (PR-H). Un PR-H no solo informa a los otros PR del ámbito de operación sobre el registro o desregistro de sus PE, sino que también monitorea la disponibilidad de sus PE mediante mensajes ASAP Keep-Alive. Un mensaje keep-alive de un PR-H debe ser reconocido por el PE dentro de un intervalo de tiempo determinado. Si el PE no responde dentro de un tiempo de espera determinado, se asume que está inactivo y se lo elimina inmediatamente del espacio de control. Además, se espera que un PE se vuelva a registrar regularmente. En un nuevo registro, también es posible que el PE cambie su lista de direcciones de transporte o su información de política.
Para utilizar el servicio de un pool, un cliente, llamado Pool User (PU) en la terminología de RSerPool, primero debe solicitar la resolución del PH del pool a una lista de identidades de PE en una PR arbitraria del alcance de la operación. Este procedimiento de selección se denomina Handle Resolution (Resolución de manejo). En el caso de que el pool solicitado ya exista, la PR seleccionará una lista de identidades de PE de acuerdo con la Pool Member Selection Policy (Pool Member Selection Policy) del pool, también denominada simplemente Pool Policy (Política del pool).
Las posibles políticas de pool son, por ejemplo, una selección aleatoria (Random) o el PE menos cargado (Least Used). Mientras que en el primer caso no es necesario tener ninguna información de selección (los PE se seleccionan aleatoriamente), es necesario mantener información de carga actualizada en el segundo caso de selección del PE menos cargado. Usando una política de selección apropiada, por ejemplo, es posible distribuir equitativamente la carga de solicitudes entre los PE del pool.
Después de recibir una lista de identidades de PE de un PR, una PU escribirá la información de PE en su caché local. Esta caché se denomina caché del lado de la PU. De su caché, la PU seleccionará exactamente un PE (nuevamente utilizando la política de selección del grupo) y establecerá una conexión con él utilizando el protocolo de la aplicación, por ejemplo, HTTP sobre SCTP o TCP en el caso de un servidor web. Al utilizar esta conexión, se utiliza el servicio proporcionado por el servidor. En caso de que falle el establecimiento de la conexión o la conexión se interrumpa durante el uso del servicio, se puede seleccionar un nuevo PE repitiendo el procedimiento de selección descrito. Si la información en la caché del lado de la PU no está desactualizada, se puede seleccionar directamente una identidad de PE de la caché, evitando el esfuerzo de solicitar a un PR la resolución del identificador. Después de restablecer una conexión con un nuevo PE, el estado de la sesión de la aplicación debe volver a instanciarse en el nuevo PE. El procedimiento necesario para la reanudación de la sesión se denomina procedimiento de conmutación por error y, por supuesto, es específico de la aplicación. Por ejemplo, en el caso de una descarga FTP , el procedimiento de conmutación por error podría consistir en indicar al nuevo servidor FTP el nombre del archivo y la posición de los últimos datos recibidos. De esta forma, el servidor FTP podrá reanudar la sesión de descarga. Dado que el procedimiento de conmutación por error depende en gran medida de la aplicación, no forma parte de RSerPool en sí, aunque RSerPool proporciona un amplio soporte para la implementación de esquemas de conmutación por error arbitrarios mediante sus mecanismos de capa de sesión.
Para que los componentes de RSerPool puedan configurarse automáticamente, los PR pueden anunciarse a sí mismos mediante multidifusión UDP sobre IP . Estos anuncios pueden ser recibidos por PE, PU y otros PR, lo que les permite conocer la lista de PR disponibles actualmente en el ámbito de operación. La ventaja de utilizar multidifusión IP en lugar de difusión es que este mecanismo también funcionará a través de enrutadores (por ejemplo, redes LAN interconectadas a través de una VPN ) y los anuncios, en el caso de, por ejemplo, una Ethernet conmutada, solo serán escuchados y procesados por estaciones realmente interesadas en esta información. En el caso de que la multidifusión IP no esté disponible, por supuesto es posible configurar estáticamente las direcciones de PR.
Se conocen las siguientes implementaciones: