Este artículo proviene de un motor de traducción automática.

Pronóstico: nublado

Almacenamiento en caché en roles de Windows Azure

Joseph Fultz

 

La vieja noción de que la suerte favorece a los preparados pretende transmitir la idea de que no importa lo afortunado que eres, debe estar preparado para capitalizar la ocurrencia de suerte.A menudo he pensado que esta declaración describe el almacenamiento en caché con bastante precisión.Si eres lo suficientemente afortunados como para el universo alinear de tal manera que uso alto de disco de su sitio y los servicios, mejor usted estaría dispuesta a servir el contenido rápidamente.

En enero he cubierto algunos conceptos relacionados con el almacenamiento en caché que se centró más bien tácticamente en algunos enfoques de codificación (msdn.microsoft.com/magazine/hh708748).Con la adición de las funciones dedicadas y ubicarse para almacenar en caché en el Windows Azure Caching (Preview), que te remito aquí como vista previa simplemente Caching, sentí que sería útil considerar cómo utilizar estas funciones como parte de la arquitectura de la solución general.Esto no será una cobertura exhaustiva de las características de almacenamiento en caché; en cambio, está encaminada a ser vista de un diseñador de qué hacer con los bloques grandes.

Una caché con cualquier otro nombre...

... no es lo mismo.Sin duda, la aplicación de back-end es bastante similar y, como su precursor caché compartida de Windows Azure, vista previa de caché moverá los datos que obtiene el cliente de caché local.Más importante, aunque, vista previa de caché introduce algunas capacidades que faltan en la memoria caché compartida, así cambiar a role-based caché no sólo amplía el conjunto de funciones disponibles, también le da mayor control sobre la arquitectura de implementación.Para empezar, vamos a aclarar la diferencia principal entre los roles de ubicarse y dedicados: configuración.

Al configurar los nodos de caché, tienes la opción de dedicar el papel completo en la memoria caché o apartar solo un porcentaje del papel.Sólo como una forma para examinar rápidamente las consecuencias de la reserva de memoria RAM para la caché de ubicarse, echa un vistazo a figura 1, que muestra el restante RAM utilizable después de la reserva de memoria caché.(Observe que la opción de colocarse no está disponible en la instancia de X-Small).

Figura 1 restante RAM

A menudo el primer pensamiento es simplemente elegir algunos tamaño mediano o pequeño y asignar cierta cantidad de memoria.Como la cantidad de memoria asignada es suficiente para el uso previsto y dentro de los límites de la RAM disponible, este es un enfoque fino.Sin embargo, si el número de objetos es alto y hay una expectativa razonable de que el cliente de caché en cada máquina podría celebrar su número máximo de objetos, el resultado podría ser la presión de la memoria inesperado.Por otra parte, demasiado poco caché RAM podría conducir a los desalojos de caché no deseados, reduciendo la eficacia global de la memoria caché.

Figura 2 muestra el porcentaje de uso de RAM según el tamaño de la máquina virtual (VM).La tabla está basada en el msdn.microsoft.com/­biblioteca/hh914152, que muestra la cantidad de RAM disponible para el almacenamiento en caché en modo dedicado.

Figura 2 uso de caché para papel dedicado

Tamaño de la máquina virtual	Memoria disponible para almacenar en caché	% de uso de RAM según el tamaño de la máquina Virtual
Pequeño	Aproximadamente 1 GB	57%
Medio	Aproximadamente 2,5GB	57%
Grandes	Aproximadamente 5,5GB	79%
X-Large	Aproximadamente 11GB	79%

En mi red ubicarse (figura 1), no van más allá de la asignación de 40 por ciento para el tipo de ubicarse porque supuse que necesitaría una mayoría de la RAM para la aplicación.En comparación, la versión dedicada generalmente proporciona más memoria RAM, pero parece golpear la máxima eficiencia de asignación de memoria RAM en el gran tamaño de memoria virtual.En ese sentido, dos VMs medianas son menos útiles que uno grande.Por supuesto, una gran instancia no puede ayudar con opciones como alta disponibilidad (HA), lo que duplica los datos, que puede desear en su infraestructura de almacenamiento en caché.Aún así, merece la pena pesando las necesidades de espacio contra la necesidad de redundancia y elegir una configuración que no sólo satisface las necesidades técnicas, sino también optimiza el costo.

Cuando el almacenamiento en caché se hace intencionalmente, una sequía de RAM normalmente no es un problema.Sin embargo, en casos donde se utiliza la caché compartida para objetos de sesión o la caché de resultados, la situación es un poco más difícil debido a la tendencia a usar la sesión para todo y la dificultad en la predicción exacta de la carga.Por ejemplo, si está ejecutando una aplicación de Model-View-Controller que tiene modelos profundos que desea colocar en la sesión y aumentar el número máximo de objetos para el cliente de caché, puede encontrarse con resultados no deseados bajo una carga media o superior.Esto sería superficial como un rendimiento más lento sitio causado por los desalojos de la caché compartida, de presión de la memoria que no esperaba; no se olvide, el cliente de caché es probablemente la celebración de RAM más de lo previsto debido a la combinación de un conteo mayor objeto máximo y un gráfico profundo.El marco le ayude, un poco por la compresión de los objetos serializados, pero para un recurso precioso y finito como RAM, diligencia en la contabilidad es la mejor práctica, especialmente cuando se trata de compartir la memoria RAM entre aplicaciones, caché de salida, objetos de sesión, caché de datos y cliente de caché.Para ayudarle en su caché de tamaño, Microsoft ha publicado la hoja de cálculo de guía de planificación de capacidad, que puede encontrar en msdn.microsoft.com/library/hh914129.

Regiones

Regiones añadir alguna funcionalidad agradable, pero a un costo.El costo es que la región está fijada a un solo servidor obligando a todas las peticiones de objetos en la región a estar congestionado a través de ese host de caché cuando no se guardan en el cliente de caché.La parte positiva es que utilizar regiones proporciona capacidad de etiquetado.Mi favorito regiones utiliza almacenar los datos de referencia pre-fetched.Esto podría parecer locura al principio, debido al problema de cuello de botella, pero vamos a ver.

Para considerar el uso de la caché, vamos a postular que un catálogo de 10.000 productos con hasta ocho variantes para cada producto, lo que significa un catálogo de elementos potencialmente 80.000.Si cada objeto que representa un elemento promedio de 1 K, es alrededor de 82 MB shuffle alrededor de cada solicitud, así como ocupar espacio en el cliente de caché.Además, habrá un número de catálogos virtuales que son ya sea una copia completa o un subconjunto de la original, por lo que podría acabar con una explosión de datos de referencia que se barajan sobre, todo servido por el anfitrión de la misma región (ver figura 3).

Diseño de caché de la figura 3 con una sola región

Sin embargo, con un poco de trabajo puedo crear más regiones para contener subsecciones de los datos.Por ejemplo, romper mi catálogo en departamentos o segmentos.Por ejemplo, podría crear una región para los productos de consumo y de productos profesionales, resultando en algo como lo que se muestra en la figura 4.

Figura 4 Cache diseño con dos regiones

Esto proporciona un poco más granularidad en la caché, que permite el uso de papeles menores para mantener todos mis objetos de caché, facilitar versiones de caché y disminuir el tráfico reduciendo las consultas a cada rol y filtrado mediante el uso de consultas de la etiqueta.

La capacidad de contenido de la etiqueta es la principal función de conducción el uso de las regiones.Por lo tanto, puedo marcar el contenido en mis catálogos; los equipos, por ejemplo, podría incluir etiquetas tales como: "portátil," "4 GB", "8 GB", "15 pulg," "HD Audio", "Desktop" y así sucesivamente.De esta manera puedo habilitar tales elementos de interfaz de usuario como una búsqueda de producto facetado de navegación mediante una llamada a uno de los métodos de GetObjectsByTag.También significa el acceso a los datos de la reingeniería de la capa y, en algún sentido, tratar la caché más como los datos principales de origen por que se cumplan las consultas sobre las facetas (etiquetas) de datos.

Una interesante forma de tomar ventaja de esta característica es utilizar tablas de almacenamiento de Windows Azure como el almacén de datos de back-end, sino para recuperación de los datos, etiqueta y ponerla en caché.Esto proporciona algunos de los ausentes en la encarnación actual de tablas de almacenamiento manteniendo los costos al mínimo de filtrado.

Utilización de regiones proporciona mucha flexibilidad en la recuperación de datos almacenados en caché, pero tenga en cuenta el tipo de cepa que pone en la infraestructura de despliegue.Aún así, regiones son útiles como medio de recuperación y acceso a datos de referencia.

Alta disponibilidad

Hay una cosa divertida para considerar con cachés HA — utiliza una caché HA cuidado, pero necesita tener cuidado al usar HA.Al menos, necesita ser apropiadamente reflexivo sobre lo que realmente necesita ser altamente disponible.

Porque cada papel habilitado para la duplicación duplica la cantidad de espacio necesario para los objetos reales, agotado RAM mucho más rápido.Así, como una cuestión de diseño, es mejor utilizar HA sólo para aquellas características que realmente necesita o que mejoraría enormemente UX para conducir no arbitrariamente los costes o desencadenar artificialmente los desalojos de caché debido a la hambruna de memoria resultantes de consumo excesivo por duplicado cachés.

He visto algunas orientaciones que sugiere poner objetos de sesión en la caché de alta disponibilidad por lo que se puede consultar a través de los usuarios en sesiones activas basadas en ciertos valores de etiqueta.En la mayoría de los casos, esto no sería un enfoque útil como inequitativa distribuye la carga al recuperar los objetos de sesión de caché; ese patrón de carga debe observar más de cerca el equilibrio de carga del sitio.Además, porque bien puede tener mucho de perfiles anónimos vacíos además de usuarios registrados bajo identificado, búsqueda basados en etiquetas para entidades como perfiles de usuario son realmente más limitante que útil.

Sugiero que usted coloque objetos de usuario, sesiones, el almacenamiento en caché de salida y similares en sus propios escondites con nombre, pero no les habilita para la duplicación.En casos donde editar datos está ligados a una sesión, usted podría considerar la sesión con una caché de alta disponibilidad dependiendo de dónde usted está en el ciclo de vida de la aplicación de copia de seguridad.Si la aplicación está siendo diseñado y creado, es mejor separar los objetos de estado in-situ y colocarlos en una caché de alta disponibilidad fuera de la sesión.Esto le permite administrar los datos de edición relacionados a un usuario más allá del alcance de la sesión y mantener la sesión de forma mucho más uniformemente extendido caché.Sin embargo, si su aplicación es más adelante y tiene datos que no desea perder por razones de sólo de facilidad de uso que están íntimamente relacionados con el objeto de sesión o legales, financieros, es aceptable para cablear sólo una sesión a la caché de alta disponibilidad, solo Asegúrese específicamente recalcar que en las pruebas de carga y conoce los límites de la aplicación.Más allá de datos que es importantes debido a su contenido o su punto de un proceso­— como la interfaz de los datos de respaldo una edición — los tipos de datos que son objetivos inmediatos para alta disponibilidad son conjuntos de referencia grandes, pre-fetched de datos y datos previamente calculados.

La Comunalidad entre todos estos es el costo de recuperación datos nuevamente.En el caso de datos de referencia pre-fetched o previamente calculados, la puesta en marcha costo para cebar la caché puede ser bastante significativo y perder los datos en tiempo de ejecución puede tener un impacto severo e incluso catastrófico sobre la ejecución del sitio.Figura 5describe cómo los objetos de caché podrían asignarse con HA encendido.Ya los duplicados deben estar en un dominio diferente falla, puede ver cómo los duplicados reducen el RAM total disponible para la caché.Esto no es decir siempre es mala tan es decir es lo que es necesario.Simplemente estoy sugiriendo una conciencia del impacto potencial de HA.

Figura 5 alta disponibilidad y dominios de fallo**

Casa de LEGO

A menudo los desarrolladores gustan pensar de desarrollo como construcción con bloques de Lego; se crean los bloques básicos y acóplelos en una aplicación útil.Esta idea sigue siendo cierto incluso a medida que avanzamos más arriba de la pila de la aplicación de las funciones a objetos a los componentes de infraestructura.Para ello, quiero dejar con algunas directrices de diseño.

En primer lugar, utilice todas las herramientas para su ventaja.No se conforme sólo HA o no HA debido a que una forma es más fácil.No use sólo memorias caché basada en la región ya puede buscar en ellos; o les renunciar porque ellos Haz anclados a una instancia.Por el contrario, construir su infraestructura de almacenamiento en caché para satisfacer sus necesidades.

Figura 6 muestra los papeles dedicados utilizo mis cachés duplicadas y las regiones que se utilizo para búsquedas más ricamente cachés de la casa.Como regla general, favorecen funciones de caché dedicada para las regiones de la vivienda, porque no quiero cargar un papel que está cumpliendo el tráfico de usuarios con todo el tráfico para caché búsquedas relacionadas con una región dada.La fila inferior de figura 6 describe utilizando el estilo de ubicarse de almacenamiento en caché para celebrar sesión, salida y varios otros datos podría almacenar en caché durante la ejecución de mi aplicación.Esto no es decir estoy atascado con dedicado o papeles colocados como representan, ya depende sobre todo de los requisitos de RAM de los elementos que tengo intención de caché en los papeles.De hecho, para muchas implementaciones, la fila inferior solo hará el truco sin necesidad de alta disponibilidad, regiones o la gran cantidad de RAM que brinda el papel dedicado.

Figura 6 posibilidades de implementación de caché

Finalmente, figura 7 es una cuadrícula que identifica mi arranque punto para distintos tipos de datos cuando estoy pensando en cómo diseñar mi implementación de caché.

Preferencias de configuración de la figura 7

Tipo de datos	Usar HA	Región de uso	Dedicado	Colocarse
Período de sesiones				X
Salida				X
Datos generales			X	X
Búsqueda anticipada	X		X
Pre-calc	X		X
Datos importantes	X
Filtrables		X	X

Esto en ninguna manera pretende dictar uso o sugerir un papel o característica es útil sólo para la ranura que me he identificado.Es sólo mi punto de partida.Si tuviera un gran conjunto de datos pre-fetched que quería ser capaz de buscar por etiqueta, combino los elementos que marcó, terminando con un papel de caché dedicada que utiliza regiones y HA.Como un ejemplo de cuando podría desviarse desde mi punto de partida, si tengo una aplicación implementada que utiliza sesiones para sus modelos de caché, mientras que el usuario modifica datos, probablemente sería tirar mi tendencia a poner la sesión en una caché de ubicarse y no sólo ponerlo en un papel especial, pero permiten también HA.

Así, si eres lo suficientemente afortunados como tener un sitio ocupado, asegúrese de que su suerte seguirá preparando adecuadamente su infraestructura de almacenamiento en caché.

Joseph Fultz es un arquitecto de software en Hewlett-Packard Co., trabajando como parte del grupo de TI Global de HP.com. Anteriormente fue un arquitecto de software de Microsoft, trabajar con su empresa de primer nivel y clientes de ISV para definir soluciones de arquitectura y diseño.

Gracias a los siguientes expertos técnicos por su ayuda en la revisión de este artículo: Rohit Sharma y Hanz Zhang