Actualización de servidores de caché

Un clúster de caché de Microsoft AppFabric 1.1 para Windows Server consta de uno o más servidores que funcionan juntos para proporcionar una caché en memoria unificada. En ocasiones, deberá actualizar uno o varios de los servidores de un clúster de caché, y estas actualizaciones requieren reiniciar. En esta sección se proporcionan instrucciones para el clúster de caché para este escenario de revisiones.

Mantenimiento programado

La solución más sencilla para este problema es programar una ventana de mantenimiento para realizar actualizaciones en todos los servidores de caché. En este escenario, detenga el clúster de caché con el comando Stop-CacheCluster, actualice los equipos y, a continuación, inicie el clúster de caché con el comando Start-CacheCluster. Este procedimiento funciona mejor para cachés que tienen períodos de tiempo de menor demanda. Si las aplicaciones cliente tienen una demanda uniforme del clúster de caché, puede considerar otras opciones en las que el clúster de caché permanece en funcionamiento durante las actualizaciones.

Actualizaciones secuenciales del servidor de caché

Se pueden actualizar servidores de caché individuales mientras el clúster de caché continúa en ejecución. Esto requiere que el clúster de caché contenga como mínimo dos hosts de caché. El proceso básico consta de los siguientes pasos:

1. Detenga uno de los servidores del clúster con el comando Stop-CacheHost. Si fuera posible, use el conmutador Graceful para mover los datos almacenados fuera de dicho host de caché ates de que se detenga.

2. Actualice y reinicie dicho servidor.

3. Inicie el servidor mediante el comando Start-CacheHost.

4. Repita estos pasos en cada servidor de caché de manera secuencial.

Aunque estos pasos son directos, hay que tener en cuenta diversos aspectos que se tratan en las secciones siguientes.

Actualización de los host principales

El rol de administración de clústeres existe para administrar correctamente los hosts de caché en un clúster de caché. Si usa el proveedor XML para almacenar los valores de configuración del clúster de caché, entonces este rol se realiza designando algunos de los hosts de caché como hosts principales. Para que el clúster de caché siga estando operativo, debe estar en ejecución la mayoría de los hosts principales. Esto afecta a la actualización secuencial de los servidores de caché. Considere el siguiente clúster de caché de dos servidores:

Nombre de host	¿Es un host principal?
CacheServer1	Sí
CacheServer2	No

En este ejemplo, CacheServer1 es el host principal en este clúster de caché de dos nodos. Dado que la mayoría de los hosts principales deben permanecer en ejecución, no se puede detener CacheServer1 sin detener el clúster de caché. En este ejemplo, no sirve definir ambos servidores como hosts principales, pues al apagar uno de los servidores dejaría de estar en funcionamiento la mayoría de los hosts principales. Para solucionar este problema, puede agregar otro servidor de host de caché y definir a todos los servidores como hosts principales con los comandos Export-CacheClusterConfig y Import-CacheClusterConfig. Para obtener más información acerca de cómo cambiar los host principales designados, vea Establecer el rol de administración de clústeres y designaciones de host principal. Considere el clúster de caché siguiendo estos cambios.

Nombre de host	¿Es un host principal?
CacheServer1	Sí
CacheServer2	Sí
CacheServer3	Sí

En esta nueva configuración, los tres servidores son hosts principales. Ahora sí se puede apagar un servidor de caché cada vez para realizar actualizaciones.

Tenga en cuenta que el proveedor de System.Data.SqlClient no sufre este problema, pues SQL Server realiza el rol de administración de clústeres en lugar de los hosts principales. Para obtener más información acerca de los hosts principales, vea Administración de clústeres y hosts principales.

Actualización de hosts de caché con cachés que usen la alta disponibilidad

La alta disponibilidad crea copias secundarias de elementos almacenados en caché en otro host de caché. Si el host de caché principal deja de estar disponible, el elemento almacenado en caché se proporciona desde el host de caché secundario. En consecuencia, los datos almacenados en caché no se pierden. Para obtener más información acerca de esta característica, vea Alta disponibilidad. Por definición, la alta disponibilidad requiere que existan al menos tres servidores en el clúster de caché. El elemento almacenado en caché puede existir en un servidor, tener una copia secundaria en otro servidor y contar con el tercer servidor para cumplir los requisitos de alta disponibilidad en caso de que dejen de funcionar el servidor primario o el secundario. Si solo están en ejecución dos hosts de caché, no podrá detener ninguno de ellos individualmente, pues el tercero no estará presente para mantener la alta disponibilidad.

Se puede usar un script de Windows PowerShell con el fin de determinar si una o más de las memorias caché usan la característica de alta disponibilidad. El siguiente script de PowerShell proporciona un ejemplo que va de una caché a otra y comprueba la propiedad Secondaries.

Import-Module DistributedCacheAdministration

Use-CacheCluster

$Caches = Get-Cache -MaxRegions 0
$HighAvailability = $false

foreach ($Cache in $Caches)
{
   $CacheConfig = Get-CacheConfig $Cache.CacheName
   if ($CacheConfig.Secondaries -eq 1)
   {
      Write-Host $CacheConfig.CacheName
      $HighAvailability = $true
   }
}

if ($HighAvailability -eq $true)
{
   Write-Host "One or more caches use high availability (Secondaries = 1)"
}
else
{
   Write-Host "No caches use high availability (Secondaries = 1)"
}

Aunque disponga de más de dos servidores en el clúster de caché, debe comprobar su estado de ejecución con Get-CacheHost antes de comenzar a actualizarlos secuencialmente.

Consideraciones sobre la aplicación cliente

Al actualizar secuencialmente los hosts de caché sin detener el clúster de caché, existen varias consideraciones importantes para las aplicaciones cliente que usan el clúster de caché.

1. Las aplicaciones hacen referencia a uno o varios hosts de caché por su nombre con el fin de conectarse inicialmente al clúster de caché. Esto se consigue en el archivo de configuración de la aplicación o bien mediante programación. Si la aplicación cliente solo señala a un host de caché, no podrá realizar nuevas conexiones con el clúster de caché siempre que dicho host esté fuera de servicio. Las aplicaciones cliente deben hacer referencia a más de un host de caché siempre que sea posible. Tenga en cuenta que las aplicaciones cliente no tienen que hacer referencia a todos los hosts de caché. Los hosts de caché a los que se hace referencia actúan como puerta de enlace a todo el clúster.

2. Cuando se detiene un host de caché, es posible que las aplicaciones no encuentren elementos que estuvieran ubicados previamente en el host de caché detenido. La aplicación es responsable de volver a rellenar estos elementos.

3. Cuando se detiene un host de caché, es posible que las aplicaciones reciban temporalmente varias excepciones DataCacheException. Estas excepciones deberían resolverse automáticamente según se adapta el clúster de caché a la pérdida de un host de caché. Las aplicaciones deben designarse para que esperen excepciones comunes. Los clientes pueden decidirse por implementar la lógica de reintentos o bien pueden usar datos de origen hasta que se resuelvan las excepciones. Para obtener más información, vea Tratamiento de errores.

4. Cuando un host de caché está detenido, es posible que las aplicaciones no puedan escribir temporalmente en una caché que use la alta disponibilidad. Una vez que se detiene el host de caché, se crean nuevas copias de los elementos guardados en caché (secundarios) en otro host de caché.

Vea también

Conceptos

Tareas habituales de administración de clústeres de caché (Almacenamiento en caché de Windows Server AppFabric)

  2012-03-05