Administración de clústeres y hosts principales (Almacenamiento en caché de AppFabric 1.1)

Un clúster de caché de Microsoft AppFabric 1.1 para Windows Server es un grupo dinámico de servidores que trabajan en combinación para ofrecer una única memoria caché lógica unificada para los datos de la aplicación. Para ello, es necesaria alguna sobrecarga para orquestar las operaciones de clúster entre los hosts de caché. El rol de administración de clústeres es responsable de administrar los hosts de caché y, en última instancia, el clúster de caché.

Hay dos opciones principales que se pueden usar para establecer cómo se desempeña el rol de administración de clústeres de caché. La primera es que este rol lo desempeñen hosts de caché especiales, conocidos como hosts principales. Esto también se conoce como "carga". La segunda opción es que este rol lo desempeñe el servidor SQL Server. Esto también se conoce como "descarga", ya que la responsabilidad se descarga al servidor SQL Server en lugar del clúster de caché en sí.

Si almacena los datos de configuración del clúster de caché en una carpeta de red compartida (XML), debe usar la carga con la administración de hosts principales. Tenga en cuenta que los hosts principales realizan las mismas funciones de almacenamiento en caché que otros hosts de caché no designados como hosts principales, pero tienen la responsabilidad adicional de trabajar con otros hosts principales para desempeñar el rol de administración de clústeres.

En Windows Server AppFabric 1.0, de manera predeterminada, un clúster de caché que almacenaba sus datos de configuración en el servidor SQL Server descargaba el rol de administración de clústeres de caché al servidor SQL Server. Esto ha cambiado en AppFabric 1.1. De manera predeterminada, los nuevos clústeres de caché siempre usan la carga donde haya hosts principales para administrar el clúster de caché. De este modo, se mejora la disponibilidad del clúster de caché, ya que este puede permanecer parcialmente funcional en el caso de que deje de estar disponible el almacén de configuración, ya sea que dicho almacén sea un archivo XML o una base de datos de SQL Server. Tenga en cuenta que las operaciones que inspeccionan o modifican la configuración del clúster de caché no estarán disponibles en esta situación.

Aún es posible descargar todas las responsabilidades de administración de clústeres de caché al servidor SQL Server. En primer lugar, debe crear manualmente el clúster de caché mediante el comando New-CacheCluster y establecer el parámetro Offloading en "true". El otro requisito es que el Provider debe ser SQL Server (System.Data.SqlClient).

En la tabla siguiente se muestra cómo se relaciona la selección en tiempo de instalación con las opciones para la administración de clústeres. Para obtener más información sobre la selección de las opciones de configuración correctas, vea Opciones de almacenamiento de la configuración de clúster.

Funciones del rol de administración de clústeres

Hay dos parámetros de configuración principales que determinan cómo funciona el clúster con respecto a la administración de clústeres:

• leadHostManagement: este parámetro de nivel de clúster determina lo que realizará el rol de administración de clústeres. Cuando se establece en true (verdadero), los hosts principales desempeñan el rol de administración de clústeres. Si seleccionó almacenar los parámetros de configuración de clúster en una carpeta de red compartida, true es el único valor válido para este parámetro. False (falso) indica que SQL Server o un proveedor personalizado desempeñarán el rol de administración de clústeres. Cuando se usa SQL Server o un proveedor personalizado para almacenar los parámetros de configuración de clúster, puede establecer este parámetro en true y dejar que los hosts principales desempeñen el rol de administración de clústeres.

• leadHost: este parámetro de nivel de host de caché determina los hosts de caché que serán los hosts principales cuando éstos desempeñen el rol de administración de clústeres. Aunque SQL Server vaya a desempeñar el rol de administración de clústeres, el programa de instalación designa los hosts principales, por si luego cambia el parámetro leadHostManagement.

Para obtener más información sobre el cambio de esta configuración, vea Establecimiento del rol de administración de clústeres y designaciones de host principal (AppFabric 1.1).

Cuando los hosts principales desempeñan el rol de administración de clústeres

Cuando los parámetros leadHostManagement y leadHost son true, el host de caché se eleva a un nivel de responsabilidad incrementada en el clúster y se designa como host principal. Además de las operaciones normales de host de caché relacionadas con el almacenamiento en caché de datos, el host principal también trabaja con otros host principales para administrar las operaciones de clúster.

Cuando se produce un error en el host principal

Para que el clúster de caché permanezca disponible, una mayoría de hosts principales debe permanecer disponible. Esto representa un riesgo mayor en pequeños clústeres que en los grandes porque se requieren menos errores del servidor para que el clúster se cierre automáticamente.

Por ejemplo, considere el clúster de caché de seis servidores que se muestra en el diagrama siguiente. En este ejemplo, los hosts principales desempeñan el rol de administración de clústeres y dos hosts de caché se designaron como hosts principales.

Si se produce un error en cualquiera de los hosts de caché normales del clúster, éste puede continuar en ejecución. Los datos de los hosts no principales se perderán (siempre que no esté habilitada la alta disponibilidad), pero el resto del clúster puede continuar sirviendo y almacenando datos. De hecho, el clúster puede continuar funcionando si se pierden los cuatro hosts de caché no designados como hosts principales.

Si únicamente se produce un error en uno de estos hosts principales, todo el clúster de caché se cerraría automáticamente porque ya no hay una mayoría de hosts principales en ejecución. Para atenuar este problema, tiene la opción de designar más hosts principales.

Designación de hosts principales adicionales

Puede designar hosts principales adicionales después de la instalación. Sin embargo, es importante tener en cuenta que si se asignan demasiados hosts principales también puede representar un problema:

• Debe haber siempre una mayoría de hosts principales disponibles para que el clúster de caché continúe en ejecución. Cuantos más hosts se designen como hosts principales, menos errores de servidor podrá sostener el clúster y seguir siendo operable.

• En clústeres pequeños en los que uno o dos errores de host principal pueden causar un error en el clúster, se recomienda designar más hosts principales.

• En clústeres grandes, de cinco a siete hosts principales son suficientes para garantizar que un clúster en el intervalo de 50 servidores de caché tenga capacidad de respuesta.

Para obtener más información sobre el cambio de designaciones de host principal, vea Establecimiento del rol de administración de clústeres y designaciones de host principal (AppFabric 1.1).

Cambios en Microsoft AppFabric 1.1 para Windows Server

Para aumentar la disponibilidad del clúster de caché, AppFabric 1.1 ha cambiado el proceso seguido para designar los hosts principales predeterminados. AppFabric 1.1 establecerá cada host de caché agregado al clúster de caché como host principal de forma automática, hasta alcanzar un máximo de siete hosts de caché. Aún se puede designar hosts principales adicionales mediante el comando Set-CacheHostConfig con el parámetro IsLeadHost establecido en "true". También se puede cambiar el rol de host principal de un host de caché estableciendo IsLeadHost como "falso".

Cuando SQL Server desempeña el rol de administración de clústeres

Cuando el clúster de caché se creó con la descarga habilitada, el valor leadHostManagement es false. En este escenario, independientemente del parámetro leadHost, cada host de caché únicamente asume sus responsabilidades de host no principal normales relacionadas con el almacenamiento en caché de datos. La instancia de SQL Server que se usa para almacenar los parámetros de configuración de clústeres también se usa para desempeñar el rol de administración de clústeres.

Cuando se produce un error en el servidor

Para que el clúster continúe disponible cuando SQL Server desempeña el rol de administración de clústeres (descarga), deben estar disponibles uno o varios hosts de caché para poder obtener acceso a la base de datos de SQL Server.

Por ejemplo, considere el clúster de caché de seis servidores que se muestra en el diagrama siguiente.

En este ejemplo, SQL Server desempeña el rol de administración de clústeres y los seis hosts de caché pueden dedicar sus recursos al acceso de datos para los clientes de caché.

Si se produce un error en cualquiera de los host de caché del clúster, los datos de esos servidores se pierden (siempre que no esté habilitada la alta disponibilidad), pero el clúster continúa en ejecución. Los datos de los demás hosts de caché continúan disponibles en los clientes de caché. De hecho, en este escenario, el clúster puede continuar funcionando si pierde cinco de los seis hosts de caché.

Si se produce un error en SQL Server, todo el clúster se cierra en unos minutos. Para atenuar el problema, se recomienda encarecidamente usar Clúster de conmutación por error de Microsoft Windows Server 2008 (https://go.microsoft.com/fwlink/?LinkId=130692) (puede estar en inglés) para hospedar un recurso de base de datos "en clúster" para la ubicación del almacenamiento de configuración del clúster de caché y el rol de administración de clústeres.

Vea también

Conceptos

Diagrama de la arquitectura física de AppFabric (Almacenamiento en caché de AppFabric 1.1)
Diagrama de la arquitectura lógica de almacenamiento en caché de AppFabric (Almacenamiento en caché de AppFabric 1.1)

  2012-03-05