Cómo Storage Configuration impacta el desempeño de AEM

By John Jubela

El almacenamiento y el desempeño del almacenamiento son componentes clave de Adobe Experience Manager, y, sin embargo, muchas organizaciones pasan por alto o no comprenden el aprovisionamiento adecuado para almacenamiento, lo que deriva en una experiencia de usuario pobre, una mala experiencia de autor y largos tiempos de respuesta de aplicaciones.

Actualmente, las empresas invierten mucho dinero y tiempo en implementaciones AEM, y hay buenas razones para ello: es la mejor y más poderosa plataforma de mercadotecnia y administración de contenido web en el mundo. Pero el poder conlleva complejidad, y sin las herramientas y talento adecuados, las compañías posiblemente no obtienen todo el desempeño que la plataforma ofrece.

Tomemos como ejemplo el almacenamiento y el aprovisionamiento. El almacenamiento utilizado para el repositorio AEM, ya sea su EMC SAN, AWS Elastic Block Storage o Azure Premium Storage, es fundamental para cómo la aplicación AEM se desempeñará ante usuarios finales que visitan sitios web desarrollados en AEM, así como los editores de contenido que desarrollan los sitios web en AEM.

Como arquitecto de soluciones sénior para AEM en Rackspace, diseño infraestructura AEM para nuestros clientes que utilizan Rackspace Application Services para AEM, y no puedo enfatizar suficientemente la importancia de utilizar almacenamiento de alto desempeño, y configurar el repositorio de manera adecuada cuando AEM Application se implementa inicialmente.

Es extremadamente importante realizar mantenimiento de manera regular del contenido del repositorio, pues AEM puede presentar tiempos de no disponibilidad si las revisiones y balances no se implementan en torno a capacidad de almacenamiento y desempeño. AEM utiliza mucha lectura aleatoria y escritura secuencial. Por lo general, la capa de editor tendrá mucha actividad de lectura mientras que la capa de autor utilizará mucha escritura. El desempeño de servidor de Author y Publish pueden limitarse por capacidad/IOPS de almacenamiento, CPU y asignación de memoria.

Ahora, cualquier cambio en AEM crea una gráfica de nodo inmutable, por lo que el estado completo previo sigue disponible. AEM también es append only, lo cual facilita recuperar a la vez contenido y el estado del repositorio de errores fatales pero también quiere decir que el crecimiento del disco siempre es una preocupación. Unos cuantos gigabytes de datos creados en un par de días no es algo extraño por culpa de mal código, bugs de producto o actividad de escritura legítima, y eso puede disparar tiempos de no disponibilidad sin el mantenimiento o monitoreo adecuados.

Cómo lo hacemos

En Rackspace, hemos mejorado el desempeño de almacenamiento de escritura para lidiar con cientos de autores concurrentes en el mismo servidor de escritura en múltiples regiones geográficas. Este es un caso de uso real que pueden vivir organizaciones empresariales con autores de contenido en equipos distintos alrededor del mundo.

También utilizamos opciones de almacenamiento diferentes basados en la tecnología de implementación elegida. Para implementaciones de nube privada, utilizamos arreglos EMC de clase empresarial con Brocade Enterprise Director Class Switching y tejidos. Se pueden hacer niveles en el arreglo de almacenamiento para ahorrar si es necesario, y recomendamos utilizar Fast Cache para mejor desempeño.

Rackspace tiene arreglos EMC listos para utilizarse, así como arreglos personalizados que desarrollamos para satisfacer requisitos de desempeño de aplicaciones específicas. El almacenamiento por bloques siempre es preferible en NFS para provisión de segmentos pues hay mecanismos de aseguramiento incompatibles con el aseguramiento nativo interno JCR y NFS.

Para implementaciones de nube pública en AWS, aprovisionamos volúmenes de almacenamiento Elastic Block con 3,000 o más IOPS aprovisionados para satisfacer los requisitos de desempeño de autores y editores de AEM. AWS le permite elegir el número de Provisioned IOPS que quiere a un costo adicional. Es preferible utilizar Provisioned IOPS EBS Volumes, con caché General Purpose para un S3 Data Store.

En Azure, utilizamos discos premium, que permiten una cantidad máxima de IOPS basado en el tamaño del disco. Esto es importante porque podría necesitar solo 20 GB para un almacenamiento de segmento pero puede ser necesario que utilice un disco mucho más grande para lograr el IOPS requerido. Siempre separe el almacenamiento de segmento y datos.

Separación de repositorio: almacenamientos de nodo y binario

En Rackspace, separamos la la parte de almacenamiento de segmento (almacenamiento de nodo) del repositorio del almacenamiento de datos (almacenamiento binario/blob) en los desarrollos de todos nuestros clientes. Usando la lógica, los almacenamientos de segmento y datos deben separarse por algunas razones.

Desempeño: En una configuración ideal de repositorio AEM, el almacenamiento de segmento se guardará completamente en la memoria. La mayoría de los repositorios AEM tienen almacenamiento de datos demasiado grande para permitir esto, por tanto, siempre lo separamos.

Con el almacén de segmento contenido por completo en RAM, verá una gran mejora en desempeño. El disco físico (Bare Metal), vDisk (VMware), EBS Volume (AWS) o Managed Disk (Azure) utilizados para almacenamiento de segmento también deben ser RAID10 de alto desempeño idealmente basados en SSD/Flash con una cantidad suficiente de IOPS disponible.

Cuando determine el tamaño de sus servidores de aplicaciones AEM, asegúrese de asignar suficiente RAM para un Heap del tamaño adecuado, asignación Linux y, finalmente, suficiente RAM en exceso disponible para el almacenamiento de segmento de repositorio (MaxDirectMemorySize). Esta área off-heap utilizará el caché del almacenamiento de segmento en RAM, lo que permite lecturas cientos de veces más rápidas del disco.

Mantenimiento:Al dividir el almacenamiento de segmento y el de datos, tiene opciones más flexibles para mantenimiento de repositorios. Al tener un repositorio combinado, la única manera de obtener espacio en disco es a través de una compactación tar (o RevisionGC). Esto puede ser una actividad que consuma mucho tiempo, dependiendo del número de cambios al repositorio, y en algunas versiones AEM debe completarse con la instancia AEM desconectada.

Esto quiere decir que editores específicos estarán fuera del grupo de balanceadores de carga y su autor estará desconectado durante el mantenimiento. Separar el almacén de datos del almacén de segmento le permite hacer un DatastoreGC en línea, que puede ser muy rápido y con la instancia conectada. En versiones más nuevas de AEM con repositorios por debajo de 1 TB, estos procesos de mantenimiento –que se ejecutan de manera regular (semanalmente)– pueden recuperar decenas de cientos de GB en segundos o minutos.

Asimismo, al haberse mudado a un modelo FileDataStore separado, podrá (con AEM 6.4) aprovechar una nueva tarea “compactación de cola”, que puede ejecutarse en línea con aún mayor frecuencia, y solo compacta la información que ha sido añadida desde la última compactación, lo que le da la ventaja de siempre tener una instancia AEM austera y con buen desempeño.

Flexibilidad de almacenamiento:  Separar el almacenamiento de segmento y el de datos le permite acomodar cada uno en su propio medio de guardado. Los almacenes de segmento pueden ubicarse en volúmenes SSD o capas Flash para alto desempeño, mientras que su almacén de datos puede utilizar almacenamiento de menor costo y desempeño.

Si utiliza AWS en su implementación AEM, puede utilizar S3 para el almacén de datos, lo cual es realmente económico y puede compartirse entre editores y autores, reduciendo de esta manera los costos de almacenamiento todavía más. Dividirlos y registrarse en volúmenes separados permite escritura simultánea en discos diferentes, lo que mejora aun más y evita cuellos de botella en potencia.

La labor de separar el almacén de segmentos y el almacén de datos debe completarse tras la instalación inicial cuando se desempaca AEM. No puede hacerse después y necesitaría de una reinstalación o un proceso de migración crx2oak (Slidegrade) si AEM se instala con un repositorio combinado. En Rackspace utilizamos automatización personalizada internamente para completar nuestros desarrollos AEM y la automatización por defecto para Datastore externo junto con muchas otras opciones para desempeño muy elevado.

Si prefiere no preocuparse de si su almacenamiento tiene la velocidad adecuada, deje que Rackspace Application Servicesse encargue de administrar su plataforma de aplicación por usted; aprovisionaremos y administraremos su infraestructura AEMde nube pública o privada y configuraremos la plataforma de aplicación para muy alto desempeño a la vez que brindamos seguridad y administración de nivel producción y optimizamos costos.

LEAVE A REPLY

Please enter your comment!
Please enter your name here