Presentando VMware Validated Design para Software-Defined Data Center 4.2

El 13 de febrero de 2018, VMware lanzó el diseño validado de VMware para Software-Defined Data Center versión 4.2. Esta última actualización de nuestra ruta prescriptiva detallada sobre cómo implementar, operar y mantener un Centro de Datos Definido por Software (SDDC por sus siglas en inglés) basado en VMware, incluye algunos cambios menores como actualizaciones de la Lista de Materiales (BOM por sus siglas en inglés) del software y algunas nuevas convenciones de nomenclatura, junto con con algunas capacidades nuevas bastante significativas, como soporte para zonas de disponibilidad y clústeres estirados. En esta publicación, les compartimos esta última actualización y señalar la documentación en la que se puede obtener más información.

Lista de Materiales del Software

Los Diseños Validados de VMware (VVD) son un conjunto de documentos prescriptivos que explican cómo planear, implementar y operar un SDDC. Los VVD se basan en una colección de productos individuales de VMware (vSphere, vSAN, NSX, vRealize Suite), que se combinan en un paquete de consumibles común. La colección de productos individuales y sus respectivos números de versión, componen la Lista de materiales del software de diseño validado de VMware, o Lista de Materiales (BOM por sus siglas en inglés).

La versión 4.2 incluye varias actualizaciones de versiones incrementales para la lista de materiales del software junto con pasos detallados sobre cómo actualizar cada componente. Se puede encontrar una lista completa de los componentes de software y sus versiones en las notas de la versión.

Como es siempre el caso con los VVD, la lista de materiales del software y los pasos para implementarlos y actualizarlos han sido ampliamente probados y validados frente a una arquitectura estandarizada para asegurar la compatibilidad e interoperabilidad continua en toda la pila de SDDC.

Actualizaciones de Diseño
Dominios de Carga de Trabajo

Con la versión 4.2 también hemos realizado algunos cambios menores en la forma en que nombramos las cosas. Aquellos de ustedes que ya están familiarizados con VVD recordarán el uso del término "POD" para describir los diferentes tipos de clusters que se usan en el SDDC. Por ejemplo, existe el "diseño de un solo POD", o lo que oficialmente se llama la arquitectura SDDC consolidada, en la que compartimos la administración, el cálculo y las cargas de trabajo de borde en un solo clúster de vSphere.

También existe el "diseño de dos POD", o lo que oficialmente se llama la arquitectura estándar, donde aislamos las cargas de trabajo de administración en un clúster de vSphere dedicado y co-residente, para las cargas de trabajo de cálculo y de frontera (edge) en un clúster de vSphere separado. Si bien los diseños siguen siendo fundamentalmente los mismos, los términos que estamos usando para describirlos en la documentación están cambiando con la versión 4.2.

En lugar del término "POD" ahora nos referimos a los diferentes clústeres como "Dominios de Carga de Trabajo" (Workload Domains). No es un gran cambio, pero es de esperar que este cambio ayude a alinear la convención de nomenclatura de VVD con los términos de la industria con los que está más familiarizado y quizás ya los use en su centro de datos.

Nomenclatura para vRealize Automation Tenants

También estamos presentando un nuevo esquema de nombres para las cuentas de "Inquilinos" (Guests) de vRealize Automation. Si bien los nombres utilizados en el VVD pretenden ser ejemplos, anticipamos que la mayoría de los clientes optarán por utilizar sus propias convenciones de nomenclatura. Aquí intentamos mantener la coherencia en todo el VVD para reducir la confusión y brindar claridad. Como tal, los nombres de cuenta de vRealize Automation se han actualizado para ayudar a proporcionar una mejor indicación del propósito de la cuenta.

Orden de Implementación Mejorada

También se agrega un orden mejorado de implementación con VVD 4.2. Este orden mejorado mueve la ruta prescriptiva para habilitar las capacidades de monitoreo del SDDC anteriormente en la implementación.

Esto ayuda a garantizar que la supervisión se habilita lo antes posible y como tal, las operaciones de SDDC y las herramientas de supervisión se pueden utilizar de manera más efectiva durante las etapas posteriores de la implementación.

Con este cambio, encontrará en la documentación que la capa de administración de operaciones (provista principalmente por vRealize Operations y vRealize Log Insight) ahora viene antes de la capa de la plataforma de administración de la nube (provista por vRealize Automation).

Métricas de Site Recovery Manager en vRealize Operations

Otro cambio con VVD 4.2 es que los datos de métrica relacionados con Site Recovery Manager ahora aparecen en vRealize Operations Manager y vRealize Log Insight.

Esto le permite utilizar mejor las operaciones de SDDC y las herramientas de agregación de registros para mejorar las capacidades de recuperación ante desastres proporcionadas por Site Recovery Manager al implementar su SDDC en todas las regiones.

Zonas de Disponibilidad y Compatibilidad con Clústeres vSAN Ampliados

Por último, pero no menos importante, con VVD 4.2 estamos agregando pasos sobre cómo diseñar e implementar un SDDC de doble región, que sea compatible con múltiples zonas de disponibilidad. Las zonas de disponibilidad mejoran la resiliencia de la SDDC y mejoran los Acuerdos de Nivel de Servicio (SLA por sus siglas en inglés) permitiéndole identificar dominios de fallas separados dentro de su región principal, aprovechando las capacidades de clúster de vSAN para distribuir sus cargas de trabajo, a través de las zonas de disponibilidad.

Naturalmente, las zonas de disponibilidad separadas siempre deben estar físicamente aisladas y tener energía, refrigeración, red y seguridad independientes. Esos detalles están, por supuesto, cubiertos en la documentación. La idea de las zonas de disponibilidad es garantizar que si se produce una interrupción en una zona, la zona sobreviviente tendría todo lo necesario para mantener el negocio hasta que se resuelva la interrupción o se declare un desastre y las operaciones se trasladen a la región de recuperación. .

Con el VVD 4.2, se pueden definir hasta dos zonas de disponibilidad en la región primaria. La distancia física entre estas zonas puede ser de hasta aproximadamente 30 millas (50 kilómetros) y debe estar interconectada mediante una baja latencia de un solo dígito y una conexión de fibra de ancho de banda alto.

Puede operar con cargas de trabajo a través de zonas de disponibilidad de manera activa/activa, utilizando una sola instancia de vCenter Server. Estoy seguro de que tiene muchas preguntas sobre las nuevas zonas de disponibilidad y el soporte ampliado del clúster, por lo que en lugar de intentar abordarlas en este blog, volveremos a indicarle el enlace de documentación de VVD, donde puede leer todo sobre esta nueva capacidad.

Resumen

En resumen, los Diseños Validados de VMware proporcionan una ruta prescriptiva no solo para diseñar e implementar un SDDC moderno, sino también para operar y mantener su SDDC a lo largo del tiempo.

Este último VVD, el diseño validado de VMware para Software-Defined Data Center 4.2, amplía estas capacidades al incorporar compatibilidad con las últimas versiones de software, agregar varias mejoras de usabilidad y ahora incluye pasos para implementar las zonas de disponibilidad y compatibilidad con clúster expandido. Recomendamos ampliamente dedicar un tiempo a familiarizarse con los Diseños Validados de VMware y déjenos saber lo que piensa.