Alta disponibilidad (Almacenamiento en caché de AppFabric 1.1)
Cuando está habilitada la alta disponibilidad, se conserva una copia de cada región u objeto almacenado en caché, en un host de caché aparte. El clúster de caché administra el mantenimiento de esas copias y las suministra a la aplicación si las copias principales no están disponibles. No se requieren cambios de código para hacer que las aplicaciones que admiten el almacenamiento en caché tengan una gran disponibilidad. En la imagen siguiente se muestra cómo las copias de objetos y regiones se almacenan en hosts independientes, cuando la característica de alta disponibilidad está habilitada.
.gif "Información general de la alta disponibilidad de \"Velocity\"")
Configuración de la alta disponibilidad
La alta disponibilidad se configura a nivel de caché en los valores de configuración del clúster. Como propiedad de la memoria caché, se puede habilitar si primero se crea la memoria caché mediante el comando New-Cache, con el parámetro Secondaries igual a 1. Esto indica a los cmdlets de Windows PowerShell para la administración de caché que desea realizar una copia de todos los objetos y regiones almacenados en caché. Si establece el parámetro Secondaries como 0, se deshabilita la característica de alta disponibilidad. De forma predeterminada, la opción de alta disponibilidad está deshabilitada cuando se crea una memoria caché nueva. Para obtener más información acerca de la edición de las opciones de configuración de la memoria caché, vea Edición de valores de configuración de caché con Windows PowerShell.
La característica de alta disponibilidad de las características de Microsoft AppFabric 1.1 para el almacenamiento en caché de Windows Server requiere que todos los nodos del clúster de caché ejecuten la Enterprise Edition (o superior) de Windows Server 2008 o Windows Server 2008 R2. Confirme que todos los nodos de caché de alta disponibilidad se ejecutan en un sistema operativo compatible. Para obtener más información acerca de los sistemas operativos compatibles, vea la sección "Software Requirements" (Requisitos de software) de Guía de instalación de AppFabric (https://go.microsoft.com/fwlink/?LinkId=169172) (en inglés).
Almacenamiento de copias secundarias
El clúster de caché elige dónde se almacenan las copias secundarias de los objetos y regiones. Del mismo modo que AppFabric distribuye objetos almacenados en caché por todos los hosts de caché del clúster, también distribuye las copias secundarias de estos objetos por todos los hosts de caché del clúster.
Mantenimiento de la consistencia
Independientemente de si está habilitada o no la alta disponibilidad, las aplicaciones que admiten el almacenamiento en caché funcionan como si sólo existiera la copia principal del objeto almacenado en caché. Todas las llamadas de métodos Add, Put y Remove se inician primero en el objeto principal del host de caché en el que resida. Una vez iniciada la llamada al host de caché que actualiza el objeto o la región principal, la acción resultante varía en función de si la alta disponibilidad está habilitada.
Si está habilitada la alta disponibilidad, hay un paso adicional para notificar al host que mantiene la copia secundaria de que está apunto de realizarse un cambio. A continuación, el host de caché con la copia principal del objeto espera la confirmación del otro host, antes de confirmar al cliente que la operación se ha completado.
Como ejemplo, vea los hosts A y B del siguiente diagrama. Tan pronto el host de caché A recibe una solicitud, empieza a procesarla y notifica al host de caché B acerca del cambio. A continuación, el host de caché B envía una confirmación al host de caché A. Cuando el host de caché A la recibe, finaliza el cambio y envía una confirmación a la aplicación que admite el almacenamiento en caché. Este proceso garantiza que la copia secundaria del objeto o región siempre se encuentra en el mismo estado que la COPIA principal. Este proceso se denomina coherencia fuerte.
.gif "Coherencia en la alta disponibilidad de \"Velocity\"")
Consideraciones de rendimiento
Puesto que el host de caché que mantiene la copia secundaria del objeto o región debe confirmar todos los cambios que pertenecen a la copia principal, hay un pequeño coste de rendimiento en el tiempo de respuesta, al escribir desde la aplicación que admite el almacenamiento en caché. Tenga en cuenta que este impacto en el rendimiento no afecta a las lecturas ni a los elementos que ya están en caché. También debe tener en cuenta el tiempo requerido para volver a cargar en caché los objetos, en el caso de que se pierda el host de caché que mantiene las copias principales de estos objetos.
Qué ocurre cuando se producen errores en un host de caché
Si se producen errores en un host de caché (suponiendo que todavía haya un número suficiente de hosts de caché disponibles para mantener el clúster en ejecución), nada cambia para la aplicación que admite el almacenamiento en caché. El clúster de caché redistribuye las solicitudes del objeto en el host de caché que mantenía la copia secundaria del objeto. Entonces, dentro del clúster, las copias secundarias de todos los objetos principales se elevan para convertirlas en nuevos objetos principales. A continuación, las copias secundarias de esos nuevos objetos principales se distribuyen en otros hosts de caché del clúster. Los objetos secundarios del host de caché que ha fallado se reemplazan con los nuevos objetos secundarios y se distribuyen por el clúster. Este proceso también se aplica a las regiones.
Para que la función de alta disponibilidad proteja a su aplicación del fallo de un host de caché, es necesario que al menos tres hosts de caché sean miembros del clúster de caché. Esto se debe a un estricto requisito de coherencia según el cual siempre debe haber dos copias de un objeto o región en caché en una memoria caché habilitada para alta disponibilidad. Para mantener dos copias de una memoria caché o región, la memoria caché habilitada para alta disponibilidad requiere el funcionamiento de dos hosts de caché como mínimo.
Por ejemplo, suponga que ha creado un HACache almacenado en caché habilitado para alta disponibilidad, en un clúster de caché de tres servidores, tal como se muestra en la tabla siguiente. Suponga que SQL Server se ha configurado para realizar la función de administración de clústeres (por lo que para este ejemplo no es necesario tener en cuenta la posible pérdida de hosts principales).
| Hora | Host de caché 1 | Host de caché 2 | Host de caché 3 | HACache (caché con nombre habilitado para la alta disponibilidad) |
|---|---|---|---|---|
T1 |
en ejecución |
en ejecución |
en ejecución |
disponible |
T2 |
en ejecución |
en ejecución |
detenido |
disponible |
T3 |
en ejecución |
detenido |
detenido |
no disponible |
En T1, cuando hay tres hosts de caché disponibles, se pueden almacenar dos copias de objetos o regiones en caché, en uno de los tres servidores disponibles. En T2, cuando un servidor de caché falla, HACache sigue disponible porque todavía hay dos hosts de caché disponibles para almacenar las dos copias de los objetos o regiones en caché. En T3, cuando el segundo host de caché falla, HACache deja de estar disponible. Esto sucede porque no hay ningún otro host de caché disponible para almacenar la segunda copia de los objetos o regiones en caché.
Otras recomendaciones de alta disponibilidad
Para optimizar la disponibilidad de los datos en caché, tenga en cuenta las siguientes recomendaciones:
Utilice una gran cantidad de hosts de caché.
Implemente el sistema de caché distribuido dentro del perímetro de un firewall, con todos los miembros del servidor en el mismo dominio, incluidos los clientes de caché, los hosts de caché, el servidor del origen de datos principal y el servidor que hospeda la ubicación de almacenamiento de la configuración de clúster.
Use SQL Server o un proveedor personalizado para almacenar los valores de configuración del clúster de caché.
Use SQL Server o un proveedor personalizado para realizar la función de administración de clústeres. Para obtener más información, vea Administración de clústeres y hosts principales (Almacenamiento en caché de AppFabric 1.1).
Siempre que sea posible, use el clúster de conmutación por error de Microsoft Windows Server 2008 (https://go.microsoft.com/fwlink/?LinkId=130692) para hospedar un recurso de base de datos agrupado, para la ubicación de almacenamiento de la configuración del clúster de caché.
Minimice los costosos cambios en la configuración que requieran detener el clúster. Siempre que sea posible, recree las memorias caché con nombre, en lugar de detener todo el clúster de caché para realizar cambios en la configuración de caché, en los valores de configuración del clúster.
Use siempre el comando
Stop-CacheHostpara detener el servicio de caché antes de reiniciar un servidor. Si los hosts principales realizan la función de administración de clústeres, el cmdletStop-CacheHostno podrá ejecutarse si la acción de detener el servicio de caché causa la detención de todo el clúster de caché (porque no habrá una mayoría de hosts principales en ejecución).
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