Source: https://docs.hol.vmware.com/HOL-2017/Localization/manuals/hol-1708-sdc-1-html_es/index.html
Timestamp: 2020-06-07 08:24:44+00:00

Document:
VMware Hands-on Labs - HOL-1708-SDC-1-ES
HOL-1708-SDC-1-ES
Descripción general del laboratorio: HOL-1708-SDC-1. Introducción a Virtual SAN
Módulo 1: Instalación y habilitación de Virtual SAN 6.2 (15 minutos. Principiante)
Lección 1: Descripción general de Virtual SAN
Lección 2: Requisitos de Virtual SAN
Lección 3: Preparación de un clúster de Virtual SAN
Lección 4: Deduplicación y compresión de VSAN
Lección 5: Escalabilidad horizontal de la capacidad del clúster de VSAN
Módulo 2: Capacidades de Virtual SAN basado solo en flash (30 minutos. Principiante)
Lección 1: Administración de políticas basadas en el almacenamiento: Raid 5 / 6
Lección 2: Nuevo VM Swap Object disperso
Módulo 3: Disponibilidad y continuidad del negocio (30 minutos. Avanzado)
Lección 1: Clúster extendido de Virtual SAN
Lección 2: Virtual SAN con vSphere HA y DRS
Módulo 4: Monitoreo y resolución de problemas (30 minutos. Principiante)
Lección 1: Comprobación del estado de VSAN
Lección 2: Tablas de rendimiento
Lección 3: ESXCLI
Módulo 5: Automatización de Virtual SAN (30 minutos. Avanzado)
Lección 1: PowerCLI/ESXCLI
Lección 2: Ruby vSphere Console (RVC)
Resumen del laboratorio:
El objetivo de este laboratorio es ayudarlo a entender los aspectos básicos de VMware Virtual SAN. Este laboratorio autodidáctico se divide en 5 módulos. Cada módulo destaca pasos importantes relacionados con la configuración, la habilitación de funciones y la solución de problemas de VMware Virtual SAN. Cada módulo contiene múltiples lecciones que desarrollan temas específicos. Los módulos son independientes unos de otros y pueden realizarse en el orden que el estudiante prefiera.
Módulo 1: Instalación y habilitación de Virtual SAN 6.2 (15 minutos. Básico). El primer módulo implica el entendimiento de los requisitos de un clúster de Virtual SAN, la creación de un clúster de Virtual SAN, la escalabilidad horizontal y las funciones avanzadas que ofrece Virtual SAN.
Módulo 2: Capacidades de Virtual SAN basado solo en flash (30 minutos. Principiante)En el módulo 2, se exploran las capacidades de los arreglos de discos basados solo en flash junto con la integración de la administración basada en políticas de almacenamiento con Virtual SAN.
Módulo 3: Disponibilidad y continuidad del negocio (30 minutos. Avanzado)En el módulo 3, se presentará una descripción general de los clústeres extendidos, su creación y la forma en la que Virtual SAN está estrechamente integrado con High Availability (HA) y Distributed Resource Scheduling (DRS).
Módulo 4: Monitoreo y resolución de problemas (30 minutos. Principiante)En el módulo 4, se presenta una de las funciones esenciales de Virtual SAN. En este módulo, se desarrollará la comprobación del estado y los gráficos de rendimiento de Virtual SAN.
Módulo 5: Automatización de Virtual SAN (30 minutos. Avanzado) En el módulo 5, se presentan los comandos de PowerCLI, esxcli y RVC para administrar y automatizar un clúster de Virtual SAN.
John Browne, Staff Technical Support Training Specialist, Irlanda
Ken Osborn, Sr. Systems Engineer, EE. UU.
Mousumi Mullick, Sr. MTS, EE. UU.
Jitender Rohilla, Staff QE, EE. UU.
Mark Plaza, Sr. Systems Engineer, EE. UU.
En algunos laboratorios en particular, pueden haber consolas adicionales en diferentes pestañas, en la esquina superior izquierda. Se le indicará que abra otra consola específica si es necesario.
Tenga la seguridad de que VMware y los laboratorios prácticos se encuentran en cumplimiento normativo absoluto con los requisitos de licencia de Microsoft. El laboratorio que utiliza es un pod autónomo y no posee acceso total a Internet, que es lo que Windows requiere a fin de verificar la activación. Sin acceso total a Internet, este proceso automatizado falla y se muestra esta marca de agua.
Observe el sector inferior derecho de la pantalla.
La aplicación Module Switcher lo ayuda a acceder a los múltiples módulos de un laboratorio y a moverse de uno a otro.
Inicio de Module Switcher
Abra la carpeta denominada "Module Switchers" en el escritorio.
Haga doble clic en el módulo denominado "1 HOL-1708-SDC-1 - VSAN A to Z".
Funcionamiento de Module Switcher
Module Switcher se diseñó con el objetivo de permitir que los estudiantes accedan al laboratorio y comiencen cualquier módulo que sea de su interés.
Observe que no puede "volver atrás" y realizar módulos anteriores al módulo en el que se encuentra actualmente, a menos que finalice el laboratorio y vuelva a iniciarlo (por ejemplo, si comienza con el módulo 4, no puede utilizar Module Switcher para empezar los laboratorios 1, 2 o 3).
Virtual SAN es una solución de almacenamiento de VMware, que se lanzó como versión beta en 2013, estuvo disponible para el público en marzo de 2014 y alcanzó la versión 6.2 en marzo de 2016. VSAN está completamente integrado en vSphere. Se trata de un sistema de almacenamiento basado en objetos y de una plataforma para políticas de almacenamiento de máquinas virtuales (Virtual Machines, VM) que busca simplificar las decisiones de ubicación del almacenamiento de VM para los administradores de vSphere. Es totalmente compatible y está completamente integrado con las principales funcionalidades de vSphere, como vSphere High Availability (HA), vSphere Distributed Resource Scheduler (DRS) y vMotion.
Lección 4: Desduplicación y compresión de VSAN
Como componente de vSphere, VSAN extiende el hipervisor para agrupar y separar los recursos de almacenamiento basado en el servidor de un modo muy similar al que vSphere agrupa y abstrae los recursos de procesamiento. Está diseñado para ser mucho más simple y rentable que los arreglos de discos de almacenamiento externo tradicionales. Los usuarios de vSphere podrán aprender sobre Virtual SAN y volverse productivos rápidamente.
VSAN está totalmente integrado con vSphere y es compatible con casi todas las funcionalidades más populares de vSphere, incluidas DRS, HA, vMotion y más. VSAN también está integrado con vRealize Suite para entornos automatizados más grandes.
Almacenamiento definido por software totalmente integrado con vSphere.
Uso de componentes internos del servidor para crear un depósito de almacenamiento compartido en un único clúster.
Uso de políticas de almacenamiento para proporcionar servicios de almacenamiento por VM.
Hasta 7 millones de solo lectura de 4.000 E/S por segundo en un único clúster de 64 nodos (¡eso es muchísimo!)
En comparación con las soluciones de almacenamiento tradicionales, Virtual SAN es increíblemente fácil de instalar y operar a diario. El almacenamiento se presenta como una extensión natural de la experiencia de administración de vSphere. La administración basada en políticas simplifica de manera significativa el aprovisionamiento de los servicios de almacenamiento para las VM.
La integración profunda de VSAN en el kernel de vSphere y el uso de flash mejora de manera significativa el rendimiento de la aplicación en comparación con las soluciones de almacenamiento tradicionales. Las aplicaciones que requieren niveles aún mayores de rendimiento previsible pueden usar las configuraciones all-flash.
VSAN puede disminuir el costo total de propiedad (Total Cost of Ownership, TCO) hasta en un 50 % mediante el uso de un modelo de administración optimizado, así como componentes de almacenamiento de servidor rentables. Ampliar ya sea la capacidad o el rendimiento implica simplemente añadir más recursos al clúster: flash, discos o servidores.
Virtual SAN 6.0 requiere ESXi 6.0 y vCenter Server 6.0. Virtual SAN puede administrarse mediante la versión de vCenter Server para Windows y vCenter Server Appliance (VCSA).
VSAN se configura y monitorea mediante vSphere Web Client, que también debe ser la versión 6.0.
Virtual SAN requiere al menos 3 hosts de vSphere (cada host cuenta con almacenamiento local) para formar un clúster de Virtual SAN. Esto permite que el clúster cumpla con los requisitos mínimos de disponibilidad de tolerar la falla de un host. Los hosts de vSphere deben ejecutar vSphere 6.0. Con menos hosts, se pone en riesgo la disponibilidad de las máquinas virtuales si un solo host deja de funcionar. El número máximo de hosts admitido es de 64.
Disco y red
En VSAN 6.0, el SSD de clúster híbrido proporcionará un búfer de escritura (30 %) y una caché de lectura (70 %). Cuanto mayor sea la capacidad del SSD en el host, mejor será el rendimiento, ya que se podrán almacenar más datos de E/S en caché.
Se debe configurar un puerto VMkernel de Virtual SAN para cada host. Con un Distributed Switch, también se puede habilitar NIOC para dedicar ancho de banda a la red de VSAN.
Multicast a nivel de Capa 2 debe ser habilitado en el switch físico que maneja el tráfico de Virtual SAN.
La red de Virtual SAN debe ser solo IPv4. Virtual SAN no es compatible con IPv6.
Para utilizar Virtual SAN, debe crear un clúster de hosts y habilitar Virtual SAN en el clúster.
Siga estas pautas cuando cree un clúster de Virtual SAN.
Un clúster de Virtual SAN debe incluir un mínimo de 3 hosts ESXi que contribuyan al almacenamiento.
Para que el clúster de Virtual SAN tolere fallas en los hosts y los discos, al menos tres de los hosts que integran el clúster de Virtual SAN deben tener capacidad de caché y de almacenamiento.
Solo hosts de ESXi 6.0 o más recientes pueden ingresar a un clúster de Virtual SAN 6.0.
Para poder acceder al datastore de Virtual SAN, un host de ESXi debe ser miembro del clúster de Virtual SAN 6.0.
Una vez que habilita Virtual SAN, el proveedor de almacenamiento de Virtual SAN se registra automáticamente en vCenter Server y se crea el datastore de Virtual SAN.
En la pantalla de inicio de sesión de vSphere Web Client, seleccione "Use Windows session authentication".
Aparecerá la página de inicio de vSphere Web Client.
Para minimizar o maximizar los paneles Recent Tasks o Alarms to Work In Progress, haga clic en el alfiler.
Virtual SAN está desactivado en este momento. En esta lección, le mostraremos cómo habilitar o activar Virtual SAN en unos pocos pasos sencillos.
Una breve observación sobre el entorno del laboratorio: actualmente, el clúster denominado RegionA01-COMP01 contiene 3 hosts de ESXi que agregarán almacenamiento en la forma de caché y capacidad para formar el datastore de VSAN.
Seleccione RegionA01-COMP01 y navegue hacia Manage > Settings > Virtual SAN > General > Configure
Activación de Virtual SAN
Verifique que la opción Add disks to storage esté configurada en Manual.
Esta selección nos permite configurar manualmente los grupos de discos de VSAN. Con este método, podemos seleccionar el disco de caché y los discos de capacidad que formarán el grupo de discos de VSAN.
En esta pantalla, tenemos otras opciones, como la habilitación de Deduplication and Compression en el datastore de VSAN y la creación de Fault Domains and Stretched Cluster. En las próximas secciones del laboratorio, abordaremos estos temas. Para obtener una descripción general breve de estas funciones, haga clic en la información (i) que aparece al lado de la función.
En la sección Fault Domains and Stretched Cluster, verifique que la opción Do not configure esté seleccionada.
Validación de redes
Se incorporaron signos de verificación para comprobar que hay adaptadores de VMKernel configurados y que el servicio de red de VSAN está habilitado.
Reclamo de discos
Seleccione qué discos se deben reclamar para el caché y cuáles para la capacidad en el clúster de VSAN.
Puede expandir las listas de los discos para una selección individual de discos.
El número de discos de capacidad debe ser mayor o igual que el número de discos de caché reclamados por host.
No haga clic en Next aún.
En la lista desplegable Group by:, seleccione Host.
Esta es una vista del almacenamiento desde la perspectiva del host.
Revise y verifique las selecciones realizadas.
Aquí podemos determinar que crearemos un datastore de VSAN con una capacidad de 120 GB. El datastore de VSAN utiliza los discos de capacidad para la capacidad del datastore de VSAN. Los discos de caché no se tienen en cuenta.
Hasta el momento, no hemos habilitado la opción Deduplication and Compression. Este es un clúster de VSAN basado all-flash, donde los discos de caché y de capacidad son discos en estado sólido (Solid State Disk, SSD).
Virtual SAN está ahora habilitado.
Haga clic en el ícono Refresh para ver los cambios. (Si ve el mensaje Misconfiguration detected, quizás deba presionar Refresh un par de veces).
Luego de actualizar, debería ver los 3 hosts en el clúster de Virtual SAN.
Opción Recent Tasks
Puede revisar las tareas que se llevaron a cabo haciendo clic en Recent Tasks, que aparece en la parte inferior de vSphere Web Client.
Estas tareas incluyen la creación del clúster de VSAN, la creación de grupos de discos y la adición de discos a los grupos de discos.
Administración de discos de Virtual SAN
Seleccione Virtual SAN ->Disk Management.
Aparecen los grupos de discos de Virtual SAN de cada host de ESXi.
Es posible que deba desplazarse hacia abajo por la lista para ver todos los grupos de discos.
En la parte inferior de la pantalla, puede ver los tipos de unidades y el nivel de disco que forman estos grupos de discos.
Propiedades del datastore de VSAN
Una vez que haya formado el clúster de VSAN, también se crea un VSANDatastore.
Para ver la capacidad, navegue hacia Datastores > RegionA01-VSAN-COmp01 > Manage > Settings > General.
La capacidad que se muestra es la suma de los dispositivos de capacidad de cada uno de los hosts de ESXi en el clúster (restándole cierta sobrecarga de VSAN).
Se crea un proveedor de almacenamiento para que cada host de ESXi reconozca las capacidades de Virtual SAN y para comunicarse entre vCenter y la capa de almacenamiento. Una vez que se forma el clúster de Virtual SAN, cada host de ESXi tiene un proveedor de almacenamiento.
Navegue hacia vCenter server > Manage > Storage Providers para verificar el estado.
En este clúster de tres nodos, uno de los proveedores de Virtual SAN está en línea y activo, mientras los otros tres están en espera. Cada host de ESXi que participa en el clúster de Virtual SAN tendrá un proveedor, pero solo uno debe estar activo para proporcionar información de capacidad del datastore de Virtual SAN.
VSAN 6.2 presenta dos funciones nuevas de reducción de datos: deduplicación y compresión. Cuando se habilita a nivel de clúster, Virtual SAN buscará deduplicar cada bloque y comprimir el resultado antes de transferir el bloque a la capa de capacidad. Estas funciones están disponibles solo para VSAN basado all-flash.
No se puede habilitar la deduplicación y la compresión por separado; se deshabilitan o habilitan juntas. La deduplicación y compresión funcionan en el nivel de grupos de discos. En otras palabras, solo los objetos en el mismo grupo de discos pueden contribuir con el ahorro de espacio. Si se implementan componentes de VM diferentes, pero idénticas, en diferentes grupos de discos, no se deduplicarán bloques idénticos de datos. Sin embargo, la deduplicación y la compresión son funciones de todo el clúster; o están activas o no lo están.
No puede elegir en qué máquina virtual o grupo de disco habilitarlas. En componentes implementados en el mismo grupo de discos con deduplicación y compresión habilitadas, la deduplicación se llevará a cabo en el nivel de bloque de 4 KB. Un grupo de disco utilizará solo una copia de ese bloque de 4 KB y se eliminarán todos los bloques duplicados.
Deduplicación y compresión de VSAN
El proceso de deduplicación se lleva a cabo cuando el bloque se transfiere desde el nivel de caché al nivel de capacidad. Para hacer un seguimiento de los bloques deduplicados, se utilizan tablas de hash. Los datos deduplicados y los metadatos de las tablas de hash se distribuyen en los dispositivos de capacidad que conforman el grupo de discos. La deduplicación no distingue entre los componentes del grupo de discos. Puede deduplicar bloques en el directorio de la VM (namespace), VM swap, VMDK Object o en el objeto delta de snapshots.
Una vez que se deduplica el bloque, VSAN comprime el bloque de 4 KB a 2 KB o menos. Si VSAN puede comprimir un bloque hasta < = 2 KB, se conserva la copia comprimida. De lo contrario, se conserva el bloque descomprimido.
Este proceso es relativamente sencillo. Como primer paso, la VM escribe datos en VSAN que llegan al nivel de caché. Cuando los datos se enfrían y deben dividirse, Virtual SAN hace una lectura del bloque en la memoria (paso 2). Procesará los hashes, eliminará los duplicados y comprimirá los bloques restantes antes de escribirlo en el nivel de capacidad (paso 3).
Actualmente, VSAN utiliza SHA1 para el hash de deduplicación y utiliza LZ4 para la compresión.
Habilitación de la deduplicación y compresión de VSAN
Seleccione el clúster llamado RegionA01-COMP01.
Seleccione Manage -> Settings -> Virtual SAN -> General.
En Deduplication and compression, vemos que se encuentra Disabled.
Cambie la opción Deduplication and compression a Enabled.
También tiene la opción Allow Reduced Redundancy.
Puede que no tenga recursos suficientes en el clúster para permitir que el grupo de discos se evacúe completamente. Quizás este sea un clúster de tres nodos y no haya lugar para evacuar la réplica o testigo mientras se mantiene una protección total. También puede ser un clúster de 4 nodos con objetos RAID-5 ya implementados. En este caso, no hay lugar para mover parte de la banda RAID-5 (ya que los objetos RAID-5 requieren 4 nodos). O, simplemente, puede que haya consumido una cantidad considerable de capacidad de disco y no haya espacio para almacenar todos los datos en menos grupos de discos.
De cualquier modo, aún tiene la opción de habilitar la deduplicación y compresión, pero sabiendo que pueden existir riesgos durante el proceso ya que no hay espacio para mover los componentes. Esta opción permitirá que las VM sigan funcionando.
Habilitación de la desduplicación y compresión de VSAN
Espere a que se complete la tarea. En On-disk Format Version, podemos ver el mensaje update in progress.
Como se mencionó anteriormente, VSAN evacuará el grupo de discos, lo eliminará y recreará un nuevo formato en disco que sea compatible con estas funciones nuevas.
Puede hacer un seguimiento de la tarea en el panel Recent Tasks.
Aquí puede ver los procesos de eliminación de discos o grupos de discos, conversión del formato de disco y adición de discos o grupos de discos nuevamente, en un host por vez.
La deduplicación y compresión ahora están completamente habilitadas y se han eliminado y recreado todos los grupos de discos.
VMware VSAN es una arquitectura de almacenamiento de escalabilidad horizontal y vertical. Esto quiere decir que es posible añadir recursos de almacenamiento adicionales a su clúster de VSAN sin problemas. Estos recursos de almacenamiento pueden ser discos magnéticos (híbridos) o dispositivos flash (all-flash) para una capacidad adicional y grupos de discos completos, incluidos dispositivos de caché y de capacidad, pero también pueden ser hosts adicionales con capacidad de almacenamiento.
Comenzamos con un clúster de VSAN de 3 nodos. En esta lección, le mostraremos cómo escalar horizontalmente el datastore de VSAN mediante la incorporación de un host de ESXi adicional que agregará almacenamiento en el datastore de VSAN.
Verificación de la capacidad actual de Virtual SAN
Agregar hosts en el clúster de VSAN es bastante sencillo. Por supuesto, debe asegurarse de que el host cumpla con los requisitos o las recomendaciones de VSAN como, por ejemplo, un puerto dedicado de 1 Gb con tarjeta de interfaz de red (Network Interface Card, NIC) (se recomiendan 10 GbE) y, al menos, un dispositivo en el nivel de caché, y uno o más dispositivos en el nivel de capacidad si el host proporcionará capacidad de almacenamiento adicional. También se deben tener en cuenta los pasos de preconfiguración, como un puerto VMkernel para la comunicación con Virtual SAN, aunque estos pasos pueden realizarse después de agregar el host al clúster.
La capacidad actual del datastore de VSAN es ~112 GB.
Verificación de la configuración del clúster de Virtual SAN
Seleccione General en la sección Virtual SAN.
Verificación de dispositivos de almacenamiento
Si ESXi no reconoce de manera automática sus dispositivos como flash/SSD, puede marcarlos como dispositivos flash/SSD.
ESXi no reconoce ciertos dispositivos como flash cuando los proveedores no admiten la detección automática de discos flash. En la columna Drive Type de los dispositivos, aparece HDD como tipo.
Nota: Marcar discos HDD como discos flash puede perjudicar el rendimiento de los datastores y de los servicios que los utilizan. Marque discos como discos flash solo si está seguro de que esos discos son discos flash.
Seleccione esx-04a.corp.local -> Manage -> Storage -> Storage Devices.
En la lista Storage Devices, puede ver los 2 discos que se utilizarán para agregar almacenamiento en el datastore de VSAN. Uno de los discos es de 5 GB y se utilizará como el disco de caché. El otro es de 40 GB y se utilizará para el nivel de capacidad.
A pesar de que este es un clúster de VSAN all-flash, aún necesitamos un disco SSD para el caché y, al menos, un disco SSD para la capacidad.
Adición de nodos adicionales al clúster
Ahora, agregaremos esx-04a.corp.local al clúster de VSAN.
Arrastre esx-04a.corp.local y suéltelo en el clúster RegionA01-COMP01.
Si arrastrar y soltar no funciona, haga clic con el botón derecho en el host ESXi llamado esx-04a.corp.local y seleccione Move to .... Seleccione el clúster llamado RegionA01-COMP01.
Movimiento del host al clúster
Seleccione la opción predeterminada "Put all of this host's virtual machines in the cluster's root resource pool. Resource pools currently present on the hosts will be deleted."
Puede que vea mensajes de advertencia sobre los hosts de ESXi que ya están en el clúster, pero estos dejarán de aparecer después de un tiempo.
Opción Exit maintenance mode
Ahora, sacaremos el host de ESXi del modo de mantenimiento.
Haga clic con el botón derecho en esx-04a.corp.local y seleccione Maintenance Mode> Exit Maintenance Mode.
Hemos generado algunas alertas. Esto nos indica que debemos configurar la red de Virtual SAN correctamente.
Seleccione esx-04a.corp.local.
Seleccione Manage -> Networking -> VMkernel adapters.
Seleccione vmk2.
Aquí, podemos ver que el servicio Virtual SAN Traffic está desactivado o deshabilitado en este puerto VMkernel.
Haga clic en el botón Edit (ícono de lápiz).
Marque la casilla para habilitar el servicio Virtual SAN traffic.
Aquí podemos ver que el servicio Virtual SAN Traffic está activado/habilitado en este puerto VMkernel.
Capacidad de Virtual SAN
Seleccione RegionA01-COMP01 -> Summary.
La capacidad de Virtual SAN sigue siendo ~112 GB. Hasta ahora, todo lo que hemos hecho es agregar un host de ESXi adicional en el clúster de VSAN. Debido a que la opción Add disks to storage está configurada como Manual, tendremos que crear manualmente el grupo de discos de VSAN en este host para que pueda agregar almacenamiento en el datastore de VSAN.
Verificación de nodos adicionales
Seleccione Manage.
Seleccione Virtual SAN -> Disk MAnagement.
El host de ESXi denominado esx-04a.corp.local es parte del clúster de VSAN, pero aún no contribuye con almacenamiento.
Reclamo de discos disponibles para capacidad
Haga clic en el botón Claim Disks.
Selección de discos disponibles
Aquí podemos ver los discos disponibles en este host. Están agrupados por modelo/tamaño de disco. También puede agruparlos por Host.
Haga doble clic en el cuadro de diálogo para cambiar el tamaño de modo que estén disponibles los botones OK/Cancel.
Verificación del clúster de VSAN
Espere a que las tareas terminen de reclamar los discos y se expanda la capacidad del clúster.
Es posible que tenga que actualizar la sección Disk Groups para que también se actualicen los recursos.
Aquí podemos ver el grupo de discos que se creó en el host esx-04a.corp.local.
Seleccione la vista Datastores.
Seleccione el datastore RegionA01-VSAN-COMP01.
Seleccione Summary.
En Virtual SAN Capacity, vemos que la capacidad aumentó a ~149 GB aproximadamente. Estos son los 40 GB adicionales que agregamos desde la sección Disk Group en el host de ESXi llamado esx-04a.corp.local.
Módulo 2: Capacidades de Virtual SAN basadas solo en flash (30 minutos. Principiante)En el módulo 2, se exploran las capacidades de los arreglos de discos basados solo en flash junto con la integración de la administración basada en políticas de almacenamiento con Virtual SAN.
Module Switcher se diseñó para que el estudiante pueda ir a cualquier módulo de su preferencia y regresar a un módulo anterior, excepto al módulo 1.
Recomendamos al estudiante que realice el módulo 1 al comienzo y luego vaya a cualquier módulo en el orden que desee.
Para cambiar a un módulo específico, solo tiene que hacer clic en el botón "Start" de ese módulo.
En este módulo, se analizarán algunas funciones de Virtual SAN all-flash que se habilitan mediante la administración basada en políticas de almacenamiento.
Este módulo se concentrará más específicamente en los métodos de tolerancia a fallas, con los cuales, se especifica si el método de replicación de datos optimiza el rendimiento o la capacidad. El número de fallas que pueden tolerarse tiene un rol importante en el momento de planificar y dimensionar la capacidad de almacenamiento para Virtual SAN.
Mediante la codificación de borrado RAID 5 o RAID 6, Virtual SAN puede tolerar la falla de hasta dos dispositivos de capacidad en el datastore. Usted puede configurar RAID 5 en clústeres all-flash con cuatro dominios de fallas o más. También puede configurar RAID 5 o RAID 6 en clústeres all-flash con seis dominios de fallas o más. La codificación de borrado RAID 5 o RAID 6 requiere menos capacidad adicional para proteger sus datos que la configuración RAID 1 en espejo. Por ejemplo, en una máquina virtual (Virtual Machine, VM) protegida por un número de fallas que pueden tolerar el valor de 1 con RAID 1, se requiere el doble de tamaño de disco virtual, mientras que, con RAID 5, se requiere 1,33 veces el tamaño del disco virtual. En la siguiente tabla, se muestra una comparación general entre RAID 1 y RAID 5 o RAID 6.
En este módulo, también se analizan los objetos de intercambio de VM. En VSAN 6.2, se creó una nueva opción avanzada de host, SwapThickProvisionDisabled. Esta permite aprovisionar la opción de intercambio de VM como un objeto ligero. Si esta configuración avanzada está establecida en True, los objetos de intercambio de VM se aprovisionarán de manera ligera (Thin Provisioned).
Para preparar el entorno, usaremos Module Switcher, la aplicación de PowerCLI.
Haga doble clic en la carpeta Module Switchers que se encuentra en el escritorio.
Module Switcher: laboratorio de VSAN de la A a la Z
Haga doble clic en el atajo '1 VSAN A to Z HOL-SDC-1708-1'.
Haga clic en el botón Module 2 Start .
Esta rutina de inicio puede tardar 5 minutos en completarse. Agradecemos su paciencia.
Monitoree el avance hasta que se complete el proceso.
Presione Intro para continuar (y cierre la ventana de PowerCLI).
Finalización de la preparación del laboratorio
¡El laboratorio se preparó correctamente para el módulo 2!
Haga clic en Close para detener la aplicación Module Switcher de manera segura.
Failure Tolerance Method es una nueva capacidad introducida en VSAN 6.2 y consiste en la manera en la que los administradores pueden elegir entre las configuraciones RAID-1 o RAID-5 / 6 para los objetos de máquinas virtuales. Esta capacidad se usa en combinación con la configuración de la cantidad de fallas que se pueden tolerar. El objetivo de dicha configuración es permitirles a los administradores elegir entre rendimiento y capacidad. Si la meta final absoluta es el rendimiento, entonces el método de tolerancia que debe usarse es RAID-1 (que aún es el predeterminado). Si, por el contrario, los administradores no necesitan obtener máximo rendimiento y están más interesados en la utilización de la capacidad, entonces el método de tolerancia que debe usarse es RAID-5 o 6. La forma más fácil de explicar el comportamiento es mostrar las diversas configuraciones de políticas y la configuración del objeto que se obtiene como resultado.
Administración de políticas basadas en el almacenamiento
Virtual SAN 6.2 incorpora una serie de nuevas políticas de almacenamiento, a saber: Disable object checksum, Failure Tolerance Method y IOPs limit for object.
Aquí daremos una breve descripción de cada una de las políticas de almacenamiento.
Number of disk stripes per object: la cantidad de dispositivos de capacidad en los que se réplica un objeto de una máquina virtual. Un valor superior a 1 puede generar mejor rendimiento, pero también generará un uso mayor de los recursos del sistema.
Flash read cache reservation : capacidad flash reservada como caché de lectura para el objeto de máquina virtual. Se especifica como un porcentaje del tamaño lógico del objeto en disco de una máquina virtual (vmdk). La capacidad flash reservada no puede ser usada por otros objetos. La capacidad flash no reservada se comparte entre todos los objetos. Esta opción debe usarse solamente para abordar problemas de rendimiento específicos.
Number of failures to tolerate: define la cantidad de fallas en host y en dispositivos que puede tolerar un objeto de máquina virtual. Para n fallas toleradas, se crean n+1 copias del objeto de máquina virtual y se requieren 2*n+1 hosts que agreguen almacenamiento.
Force provisioning: si esta opción está definida en Yes, el objeto se aprovisionará incluso si el datastore no cumple con la política especificada en la política de almacenamiento. Use este parámetro en escenarios de arranque y durante una interrupción cuando el aprovisionamiento estándar ya no es posible.
Object space reservation: porcentaje del tamaño lógico del objeto en disco de la máquina virtual (virtual machine disk, vmdk) que debe reservarse, o aprovisionarse de manera pesada (thick provisioning), cuando se despliegan máquinas virtuales.
Disable object checksum: si la opción se define en No, el objeto calcula la información sobre la suma de comprobación para garantizar la integridad de sus datos. Si esta opción está establecida en Yes, el objeto no calculará la información sobre la suma de comprobación. Con esta política, se garantiza la integridad de los datos, ya que se confirma que cada copia de un archivo es exactamente igual al archivo de origen. Si se detecta una falta de concordancia en la suma de comprobación, Virtual SAN repara automáticamente los datos sobrescribiendo los datos incorrectos con los datos correctos.
Failure tolerance method: por medio de esta política, se especifica si el método de replicación de datos optimiza el rendimiento o la capacidad. Si elige la opción Performance, Virtual SAN usa más espacio en disco para ubicar los componentes de los objetos, pero proporciona mejor rendimiento para acceder a los objetos. Si selecciona Capacity, Virtual SAN usa menos espacio en disco, pero reduce el rendimiento.
IOPS limit for object: define el límite de E/S por segundo para un disco. Las E/S por segundo se calculan como el número de operaciones de E/S, usando un tamaño ponderado. Si el sistema usa el tamaño base predeterminado, que es de 32 KB, una E/S de 64 KB representa dos operaciones de E/S. Cuando se calculan las E/S por segundo, las operaciones de lectura y escritura se consideran equivalentes, mientras que no se toma en cuenta la frecuencia de coincidencias de caché y en forma secuencial. Si las E/S por segundo de un disco exceden el límite, se acelerarán las operaciones de E/S. Si el límite de E/S por segundo para un objeto se establece en 0, no se exigen los límites de E/S por segundo.
Administración de políticas basadas en el almacenamiento: Raid 5 / 6 (Erasure Coding)
Tenga en cuenta que existen requisitos sobre la cantidad de hosts que se necesitan para implementar configuraciones RAID-5 o RAID-6 en VSAN.
Para RAID-5, se requiere un mínimo de 4 hosts; para RAID-6, se requiere un mínimo de 6 hosts.
Los objetos se implementan luego en el almacenamiento de cada uno de estos hosts, junto con un cálculo de paridad. En la configuración, se usa la paridad distribuida, por lo que no hay un disco de paridad dedicado. Cuando se produce una falla en el clúster y esta afecta los objetos implementados mediante RAID-5 o RAID-6, los datos continúan estando disponibles y pueden calcularse usando los datos restantes y la paridad, si es necesario.
Se incorporó una nueva configuración de políticas con el fin de adaptarse a las nuevas configuraciones RAID-5 y RAID-6.
Esta nueva configuración de políticas se denomina Failure Tolerance Method. En esta configuración de políticas, se consideran dos valores: Performance y Capacity. Cuando se deja el valor predeterminado en Performance, los objetos continúan implementándose con una configuración RAID-1 o espejo para obtener el mejor rendimiento. Cuando esta configuración se cambia en Capacity, los objetos se implementan con la configuración RAID-5 o RAID-6.
La configuración RAID-5 o RAID-6 está determinada por la configuración de Number of failures to tolerate . Si está establecida en 1, la configuración es RAID-5. Si está establecida en 2, la configuración es RAID-6.
Administración de políticas basadas en el almacenamiento: Raid 5 o 6 (Erasure Coding)
En primer lugar, debemos crear una política de almacenamiento de VM, que definirá el método de tolerancia a fallas de Raid 5/6.
Desde la página Home, seleccione Policies and Profiles.
Seleccione Home -> Policies and Profiles -> VM Storage Policies.
Seleccione Create a New VM Storage policy.
Cree una nueva política de almacenamiento de VM usando la siguiente información:
Haga clic en Next en la página de información Rule-Sets.
Cree un nuevo conjunto de reglas usando la siguiente información:
Antes de que haga clic en Next, revise lo siguiente:
Cambie Failure tolerance method = RAID-1 (Mirroring) - Performance.
Revise Storage Consumption Model en la parte derecha de la pantalla. Tenga en cuenta que el espacio de almacenamiento en Storage space que se usaría sería de 200 GB basado en un disco virtual de 100 GB.
Ahora, cambie Failure tolerance method = Raid-5/6 (Erasure Coding)-Capacity y verá que el espacio de almacenamiento en Storage space se reducirá a 133 GB.
La compatibilidad del almacenamiento en la opción Storage compatibility se determinará conforme a la política de almacenamiento de VM.
Aquí podemos ver que el Datastore de VSAN es compatible con la política de almacenamiento de VM que estamos a punto de crear.
Revise la configuración de la política de almacenamiento de VM.
Seleccione FTT=1-Raid5 -> Manage -> Rule-Set-1:VSAN.
Aquí podemos ver las reglas que conforman nuestra política de almacenamiento de VM.
Capacidad de Virtual SAN: Raid 5 o 6 (Erasure Coding)
Seleccione Home -> Hosts and Clusters.
Seleccione RegionA01-COMP01 -> Monitor -> Virtual SAN -> Capacity.
Tome nota de las cifras de capacidad que figuran aquí. (Gran parte del datastore de VSAN está vacío).
Clonación de una VM al datastore de VSAN: Raid 5 o 6 (Erasure Coding)
Clonaremos la VM llamada Photon-Temp (que, en este momento, se encuentra en un datastore de NFS) al datastore de VSAN y aplicaremos la política de almacenamiento de VM ( FTT=1-Raid5 ) que acabamos de crear.
Haga clic con el botón secundario del mouse en la VM llamada Photon-Temp y seleccione Clone -> Clone to Virtual Machine.
Asigne a la máquina virtual el siguiente nombre: FTT=1-Raid5.
En Select a compute resource, seleccione RegionA01-COMP01.
Para VM Storage Policy, seleccione FTT=1-Raid5.
Se presentará la lista de datastores compatibles resultante, que, en nuestro caso, es el datastore de VSAN llamado RegionA01-VSAN-COMP01.
En la sección inferior de la pantalla, podemos ver que el consumo de almacenamiento de Virtual SAN sería de 666,67 de espacio de disco y 0,00 B de espacio flash reservado.
Dado que tenemos una VM con un disco de 256 MB y una política de almacenamiento de VM de Raid 5, el consumo en el disco de Virtual SAN será de 666,67 MB en disco.
Haga clic en Next, en la opción Select clone options.
Espere a que se complete la operación de clonación.
Revise la opción Recent Tasks para obtener una actualización del estado de la tarea Clone virtual machine.
Clonación de una VM al datastore de VSAN: Raid 5 o 6 (codificación de borrado)
Una vez finalizada la clonación, seleccione la VM llamada FTT=1-Raid5.
Seleccione Summary -> VM Storage Policies .
Aquí podemos ver que la política de almacenamiento para esta VM está establecida en FTT=1-Raid5 y que la política es compliant.
Seleccione Summary -> Related Objects.
La VM ahora se encuentra en el datastore de VSAN.
Políticas de disco: FTT=1 Raid 5
Seleccione la VM FTT=1-Raid5 -> Monitor -> Policies -> Hard Disk 1 -> Physical Disk Placement.
Tenga en cuenta que con esta política de almacenamiento de VM, tenemos una ubicación del disco de Raid 5, formada por 4 componentes.
Un componente reside en cada host del clúster.
Si desea permitir que los administradores realicen un seguimiento de dónde se produce el consumo de almacenamiento, se incorporó una nueva vista de capacidad con VSAN 6.2.
Si, en primer lugar, nos concentramos en Capacity Overview, podemos ver el tamaño completo del datastore de VSAN. Esto, en tamaño, equivale a unos 160 GB. También podemos ver la información en Deduplication and compression overhead.
La cantidad de espacio en Used - Total en el datastore de VSAN se refiere a la magnitud de espacio físicamente escrito (en contraste con el tamaño lógico). Esta es una combinación de discos virtuales, objetos principales de VM, objetos de intercambio, objetos de administración del rendimiento y otros elementos que pueden residir en el datastore. Otros elementos podrían ser imágenes ISO, VM no registradas o plantillas, por ejemplo.
En la sección Deduplication and Compression Overview, que se encuentra en la parte superior derecha, se da a los administradores una idea del ahorro de espacio y del índice de deduplicación alcanzado, así como la cantidad de espacio que podría requerirse si un administrador decidiera que desea deshabilitar las funciones de eficiencia del espacio en VSAN e inflar de nuevo cualquier objeto desduplicado y comprimido.
El índice de ahorro de espacio aumenta cuanto más VMs similares se implementen.
Esto nos indica que, sin los procesos de deduplicación y compresión, se hubiera necesitado ~ 3,48 GB de capacidad para implementar las cargas de trabajo actuales. Gracias a la deduplicación y compresión, solo necesitamos ~ 2,02 GB para hacerlo.
En la parte inferior de la pantalla Capacity, obtendremos un desglose de los objetos.
Sección Group by Object Types:
Performance management objects: capacidad consumida por los objetos creados para almacenar métricas de rendimiento cuando se encuentra habilitado el servicio de rendimiento.
File system overhead: cualquier sobrecarga utilizada por el sistema de archivos en disco (VirstoFS) en las unidades de capacidad, que no se atribuye a la sobrecarga de deduplicación, de compresión ni de suma de comprobación. Cuando se habilita el proceso de deduplicación y compresión, se produce un aumento 10 veces mayor en la sobrecarga del sistema de archivos, lo cual refleja el incremento en el tamaño lógico del datastore de VSAN.
Deduplication and compression overhead: sobrecarga producida para obtener las ventajas de los procesos de desduplicación y compresión. Esto incluye la tabla de mapeo asociada, tablas de hash y otros mecanismos necesarios para la desduplicación y compresión.
Checksum overhead: sobrecarga para almacenar todas las sumas de comprobación. Cuando se encuentran habilitados los procesos de desduplicación y compresión, se produce un aumento 10 veces mayor en la sobrecarga de la suma de comprobación, lo cual refleja el incremento en el tamaño lógico del datastore de VSAN.
Cuando se implementan una VM y una plantilla en el datastore de VSAN, aparecen más objetos:
Virtual disks: capacidad consumida por los objetos de disco de máquina virtual (VMDK) que residen en el datastore de VSAN.
VM home objects: capacidad consumida por los objetos del espacio de nombres principal de la VM (que contiene archivos de la máquina virtual) que residen en el datastore de VSAN.
Swap objects: capacidad consumida por el espacio de intercambio de la VM que reside en el datastore de VSAN cuando una máquina virtual está encendida.
Vmem: capacidad consumida por los objetos de la memoria, la cual se crea como resultado de tomar una snapshot de la VM, en la que se incluye la memoria de la VM, o bien, desde máquinas virtuales suspendidas. Tenga en cuenta que esto solo será visible en las VM que utilizan, como mínimo, la versión 10 del hardware virtual.
Other: capacidad consumida por plantillas de VM, VM no registradas, VMDK independientes no asociados con VM, objetos de VSAN creados manualmente, directorios creados manualmente donde se almacenan ISO, por ejemplo.
Implementación de Raid 6: políticas de disco
En este momento, en su entorno de laboratorio se está ejecutando un clúster de VSAN de 4 nodos. Para implementar la configuración Raid 6, se necesitaría un mínimo de 6 hosts en el clúster de VSAN.
En VM Storage Policy, se mostrará lo siguiente: Failure Tolerance Method : Raid 5/6 - ( Erasure Coding ) - Capacity y Number of failures to tolerate : 2.
En un Raid-6 , usted consumirá 1,5 veces más el almacenamiento asignado a la VM.
Este es un ejemplo de una VM con una configuración de políticas de almacenamiento de VM Raid 6.
En la configuración Raid 6, hay 6 componentes que están distribuidos en los 6 hosts de ESXi que hay en el clúster.
Esto es solo con fines ilustrativos.
Nuevo VM Swap Object disperso
El VM Swap Object tiene su propia configuración especial de políticas. Para el objeto de intercambio de la VM, el número de fallas que pueden tolerarse siempre está establecido en 1, según lo definido por la política. Esto se debe a que el intercambio no debe continuar cuando se reinicia una máquina virtual. Por lo tanto, si HA reinicia la máquina virtual en otro host en otro lugar del clúster, se crea un nuevo objeto de intercambio. De esta manera, no es necesario agregar protección adicional más allá de la tolerancia a una falla.
De manera predeterminada, los objetos de intercambio se aprovisionan 100 % desde el principio, sin la necesidad de configurar la reserva del espacio del objeto en 100 % en la política. Esto significa, en términos de control de admisión, que VSAN no implementará la VM a menos que haya suficiente espacio en disco para adaptarse al tamaño completo del objeto de intercambio de la VM. En VSAN 6.2, se creó una nueva opción avanzada de host, SwapThickProvisionDisabled. Esta permite aprovisionar la opción de intercambio de VM como un objeto ligero (thin). Si esta configuración avanzada está establecida en True, los objetos de intercambio de VM se aprovisionarán de manera ligera (Thin Provisioning).
Para mostrar este ejemplo, la única VM que necesitamos encendida en nuestro entorno es la llamada FTT=1-Raid5 que creamos antes.
Si tiene otras VM que se están ejecutando en el clúster RegionA01-COMP01, apáguelas ahora.
En la VM llamada FTT=1-Raid5, podemos ver que tenemos 512 MB de memoria asignada.
Tenga en cuenta que el host de ESXi en el que se está ejecutando la VM puede ser diferente del que se muestra aquí.
Nuevo objeto de intercambio de la VM dispersa
Ahora, vaya a CapacityView.
Desplácese a la parte inferior de la vista de Capacity hasta la sección Used Capacity Breakdown .
Aquí podemos ver que Swap Objects ocupa alrededor de 1,01 GB.
Apagado de la VM
Haga clic con el botón secundario del mouse en la VM llamada FTT=1-Raid5.
Seleccione Power -> Power Off.
Ahora regrese a la vista de Capacity.
Según lo previsto, no hay objetos de intercambio de la VM que consuman espacio en el datastore de VSAN.
Seleccione la máquina virtual llamada FTT=1-Raid5.
Tome nota de los hosts de ESXi con los que está registrada la VM.
Abra una sesión puTTY en el host de ESXi en el que se encuentra registrada la VM FTT=1-Raid5.
Lo primero que hay que tener en cuenta es que esta configuración avanzada debe definirse en cada host de ESXi presente en el clúster de VSAN. En nuestro entorno, solo lo haremos en el host de ESXi en el que se ejecutará la VM.
Nota: Puede arrastrar y soltar el comando desde el manual o usar la opción "send text" del menú principal.
La configuración se llama SwapThickProvisionDisabled y está deshabilitada de manera predeterminada:
Encienda de nuevo la VM llamada FTT=1-Raid5 .
Regrese a la pantalla de vista de Capacity.
Podemos ver que Swap objects ahora solo consume 12 MB de disco en vez de los 524 MB originales.
Con esta nueva función, se puede alcanzar un considerable ahorro de espacio en el espacio de capacidad consumido.
Esto dependerá de cuántas VM haya implementado, la magnitud del espacio de intercambio de la VM (básicamente, el tamaño de la memoria no reservada asignado a la VM).
En este módulo, presentamos algunas de las nuevas políticas de almacenamiento de VM que forman parte de la liberación de versión de Virtual SAN 6.2.
Comenzamos mostrando la configuración de Failure tolerance method, donde pudimos especificar si el método de replicación de datos optimiza el rendimiento o la capacidad. Si elige la opción Performance, Virtual SAN usa más espacio en disco para ubicar los componentes de los objetos, pero proporciona mejor rendimiento para acceder a los objetos. Si selecciona Capacity, Virtual SAN usa menos espacio en disco, pero reduce el rendimiento.
Luego, analizamos el objeto de intercambio de la VM dispersa. Con esta nueva función, se puede alcanzar un considerable ahorro de espacio en el espacio de capacidad consumido, lo que significa que los objetos de intercambio de la VM tendrán un aprovisionamiento ligero.
Este módulo se centra principalmente en el clúster extendido de Virtual SAN, sus requisitos y configuraciones. Se desarrolla la configuración de vSphere High Availability (HA) y Distributed Resource Scheduler (DRS) para el clúster extendido de VSAN y se incluyen ejemplos.
La función de clúster extendido de Virtual SAN se basa en los mismos conceptos arquitectónicos que se aplican en la creación de un clúster tradicional de Virtual SAN y se requiere un mínimo de tres dominios de fallas para formar correctamente un clúster de Virtual SAN.
El clúster extendido de Virtual SAN está diseñado sobre la base de los dominios de fallas, donde las tres zonas de fallas requeridas se basan en tres sitios (dos sitios activo-activo y un sitio testigo). El sitio testigo es un concepto único, ya que este sitio solo se utiliza para alojar virtual appliances (dispositivos virtuales) testigos en los que se almacena información sobre metadatos de clústeres y objetos testigos y, además, proporciona servicios de quórum al clúster durante fallas.
Requisitos de red entre sitios activo-activo (dominios de fallas de datos)
Conectividad de 10 Gbps o superior
Tiempo de ida y vuelta (Round Trip Time, RTT) con latencia inferior a 5 milisegundos
Conectividad de red de capa 2 o 3 con multicast
Requisitos de red desde sitio activo-activo (dominios de fallas de datos) a sitio testigo
Conectividad de 100 Mbps
Latencia de 100 milisegundos (RTT de 200 ms)
Conectividad de red de capa 3 sin multicast
Haga doble clic en el atajo '1 HOL-1708-SDC-1 - VSAN A to Z'.
Inicio del módulo 3
Haga clic en el botón Module 3 Start .
¡El laboratorio se preparó correctamente para el módulo 3!
Las configuraciones del clúster extendido ofrecen la posibilidad de equilibrar máquinas virtuales (VM) entre centros de datos. Cualquiera podría ser la razón para esto, ya sea prevención de desastres o mantenimiento del sitio, todo esto sin tiempo fuera de servicio desde la perspectiva de la VM, dado que el procesamiento, el almacenamiento y la red se encuentran disponibles en ambos sitios. Lo más importante es que un clúster extendido también ofrece la posibilidad de activar recursos para balancear las cargas entre ubicaciones sin limitaciones.
Configuración del clúster extendido de Virtual SAN
El clúster extendido de Virtual SAN está diseñado sobre la base de los dominios de fallas, donde, en este caso, las zonas de fallas requeridas se basan en nodos físicos y en un virtual appliance testigo. El virtual appliance testigo tiene un diseño exclusivo, cuyo único objetivo es proporcionar servicios de quórum al clúster durante fallas y almacenar información sobre metadatos de clústeres y objetos testigos. Para unirse al clúster, el testigo debe tener conexión con el nodo principal de VSAN y con el nodo de respaldo de VSAN.
En vSphere Web Client, el dispositivo testigo también tiene un ícono diferente (celeste) de un host de ESXi regular, lo que permite identificarlo rápidamente.
Algunas cuestiones acerca del virtual appliance testigo de Virtual SAN:
Se requiere un virtual appliance testigo por clúster de Virtual SAN Remote and Branch Office.
El dispositivo no proporciona recursos de procesamiento ni almacenamiento al clúster y no puede alojar máquinas virtuales.
El virtual appliance testigo se encuentra exclusivamente disponible para clústeres extendidos de Virtual SAN y la edición Virtual SAN Remote and Branch Office, y es compatible ÚNICAMENTE con estos.
Al igual que sucede con el clúster extendido de Virtual SAN, la edición Virtual SAN Remote and Branch Office solo puede respaldar una única falla dentro del clúster (FTT=1), ya que únicamente cuenta con el respaldo de tres dominios de fallas.
Ya implementamos el host testigo de Virtual SAN por usted en este entorno. El host de ESXi está registrado como esx-07a.corp.local en un clúster llamado VSAN-Witness-Cluster.
Nota: El host testigo es de color celeste. Esto lo ayudará a identificarlo en el entorno de vSphere.
Seleccione el host de ESXi llamado esx-07a.corp.local.
Seleccione Storage.
Seleccione Storage Devices.
El host testigo de VSAN tiene un dispositivo flash de 10 GB ( caché ) y una unidad de disco duro (HDD, Hard Disk Drive) de 15 GB ( capacidad ).
Los usaremos para crear el grupo de discos para el host testigo de VSAN.
Seleccione Manage -> Settings -> Virtual SAN -> Fault Domains & Stretched Cluster.
Verá que el estado de Stretched Cluster en este momento es Disabled.
Para el nombre de Preferred fault domain y Secondary fault domain, hemos elegido las siguientes opciones predeterminadas: Preferred y Secondary.
Deje los hosts de ESXi esx-01a.corp.local y esx-02a.corp.local en el dominio de fallas Preferred.
Mueva los hosts de ESXi esx-03a.corp.local y esx-04a.corp.local al dominio de fallas Secondary.
Expanda el clúster llamado VSAN-Witness-Cluster.
Seleccione esx-07a.corp.local como host testigo de VSAN.
En Requirements for witness hosts se enumeran los requisitos para los hosts testigos.
Seleccione los discos de 10 GB para el nivel Cache.
Seleccione el disco de 15 GB para el nivel Capacity.
Revise la configuración y haga clic en Finish.
Revise el panel Recent Tasks.
Una vez que se hayan completado las tareas, estará formado el clúster extendido de VSAN.
Podemos ver que en Status, en la sección Stretched Cluster, figura Enabled; en el campo Preferred fault domain, el nombre del dominio de fallas preferido es Preferred; y que el host testigo de VSAN es esx-07a.corp.local.
En la parte inferior de la pantalla, podemos ver los 2 dominios de falla que se crearon, cada uno con dos hosts de ESXi.
Estado del objeto de Virtual SAN
Seleccione Virtual SAN .
Seleccione Health.
Tenemos una nueva región en la comprobación del estado de Stretched Cluster.
Verificación del estado del clúster extendido
Expanda la comprobación del estado de Stretched Cluster.
Aquí verá las comprobaciones del estado relacionadas con el clúster extendido de VSAN.
Si se muestran errores o advertencias en la comprobación del estado de VSAN, puede hacer clic en el botón Retest para confirmar que no hay errores transitorios.
Resolución de problemas de la política de almacenamiento de VM
Puede que haya notado que se produjo una falla en la comprobación del estado de los datos de Virtual SAN.
Investiguemos lo que sucedió aquí.
Primero, veamos las políticas de almacenamiento de VM que se aplicaron a la VM.
Seleccione la máquina virtual llamada FTT-1-Raid5.
Seleccione Monitor -> Policies -> Hard Disk 1 -> Physical Disk Placement.
Podemos ver que en Compliance Status el estado es Noncompliant.
Seleccione Monitor -> Policies -> Hard Disk 1 -> Compliance Failures.
Lo que sucedió aquí es que la política de almacenamiento de VM que aplicamos a esta VM se trata de una configuración Raid 5, lo que significa que necesita 4 hosts de ESXi, pero también 4 dominios de fallas (un ESXi es un dominio de falla en sí mismo). Cuando creamos el clúster extendido de VSAN, redujimos la cantidad de dominios de fallas a 2, con lo que la política de almacenamiento de VM queda invalidada.
Seleccione Manage -> Policies -> Edit VM Storage Policies.
Para la política de almacenamiento de VM, seleccione Virtual SAN Default Storage Policy.
Haga clic en Apply to all.
Por lo tanto, el estado en Compliance Status sigue siendo Noncompliant.
Investiguemos un poco más...
Seleccione Monitor -> Virtual SAN -> Resyncing Components .
Aquí podemos ver los componentes que se están sincronizando de nuevo. Espere a que se complete el proceso.
Este es un tiempo inicial estimado, que se irá reduciendo, y se reducirá también el número en Bytes left to resync.
Una vez que se completó la resincronización, regrese a la pantalla Monitor -> Policies.
Seleccione Monitor -> Policies -> VM Home -> Physical Disk Placement.
Podemos ver que el estado de Compliance Status es Compliant.
También podemos observar que después de aplicar la política de almacenamiento de la VM llamada Virtual SAN Default Storage Policy, los componentes de la VM se ubicaron de la siguiente manera. Un componente en cada Fault Domain y, además, el quórum que proporciona el host testigo de VSAN.
La sección Data de la comprobación del estado de VSAN ahora pasó todas las pruebas.
Configuración de vSphere High Availability (HA) y Distributed Resource Scheduler (DRS) para el clúster extendido de VSAN
Para proporcionar disponibilidad para las máquinas virtuales en un clúster extendido de Virtual SAN, es necesario configurar vSphere High Availability (HA).
Con esto, cuando se produce una falla en el host, las VM pueden reiniciarse en el mismo sitio (con reglas de afinidad) o reiniciarse en un sitio remoto cuando hay una falla total del sitio. Sin embargo, existen ciertas opciones que deben configurarse de una manera específica, las cuales son fundamentales para lograr alta disponibilidad en un clúster extendido de VSAN.
En esta tarea, destacaremos la configuración recomendada de VMware y también explicaremos por qué aconsejamos que vSphere HA se configure de esta manera en un clúster extendido de VSAN.
Siguiendo esta guía, usted puede estar seguro de que sus máquinas virtuales se reinician en el mismo sitio (manteniendo la ubicación de lectura) cuando hay una falla en el host o en un componente en un sitio. También se asegurará de que las máquinas virtuales realicen la conmutación de recuperación y se reinicien en el sitio restante en caso de una falla total del sitio.
Reasignación de un nombre a la VM
Una vez que tenemos formado el clúster extendido de VSAN, comenzaremos implementando algunas máquinas virtuales en el clúster de VSAN. Para esto, le reasignaremos el nombre FTT=1-Raid5 a la máquina virtual.
Haga clic con el botón secundario del mouse en FTT=1-Raid5 VM y seleccione Rename.
Esto lo hacemos solo con fines ilustrativos.
Cambie el nombre de la VM a VM-Primary.
Tenemos disponible nuestra primera VM. Por ahora, la apagaremos y la usaremos más adelante en esta lección.
Haga clic con el botón secundario del mouse en VM-Primary.
Seleccione Power > Power Off.
Haga clic en Yes (no se muestra).
Ahora, crearemos una segunda VM llamada VM-Secondary.
Clonación de una VM a un sitio secundario
Esta vez, clonaremos la VM Photon-Temp.
Haga clic con el botón secundario del mouse en la VM Photon-Temp, seleccione Clone y, luego, seleccione Clone to Virtual Machine.
Asigne un nombre a la máquina virtual. La llamaremos VM-Secondary. Esta VM residirá en el sitio secundario.
VM Name : VM-Secondary
Seleccione el clúster RegionA01-COMP01. Aquí es donde ubicamos la VM por primera vez.
A continuación, aplicaremos una política de almacenamiento de VM para la VM. Ubicaremos la VM en el datastore de VSAN.
En VM Storage Policy, seleccione la siguiente política de almacenamiento:
Haga clic en Next en Select Clone options.
Configuración de vSphere HA y DRS para el clúster extendido de VSAN
Ahora, tenemos implementadas dos máquinas virtuales en nuestro entorno.
Ya configuramos la mayoría de las opciones de configuración de HA y DRS requeridas para un clúster extendido de VSAN, pero las mencionaremos aquí solo para mostrar lo que se debe configurar.
DRS puede configurarse en modo fully automated o partially automated.
Para obtener más información sobre la configuración de un clúster de VSAN, consulte el siguiente enlace: http://www.vmware.com/files/pdf/products/vsan/VMware-Virtual-SAN-6.2-Stretched-Cluster-Guide.pdf
Seleccione el clúster RegionA01-COMP01 .
Seleccione vSphere DRS.
vSphere DRS is Turned on (vSphere DRS está activado) y en modo Partially Automated.
Sección VM/Host Groups
Ahora, analicemos DRS en el clúster extendido de VSAN.
Lo primero que se debe tener en cuenta de DRS es la relación con las reglas de afinidad del host o de la VM.
Para que funcionen las reglas de afinidad del host o de la VM, se necesita DRS. Si DRS no está habilitado, se ignoran las reglas "recomendadas". Por lo tanto, si desea usar las reglas "recomendadas" de afinidad del host o de la VM, necesitará DRS.
Seleccione VM/Host Groups.
Asigne al grupo de hosts o VM el nombre Primary.
En Type, seleccione Host Group.
Agregue los dos hosts de ESXi llamados esx-01a.corp.local y esx-02a.corp.local al grupo de hosts o VM.
Seleccione Primary.
En Primary Host Group, se encuentran los hosts de ESXi llamados esx-01a.corp.local y esx-02a.corp.local.
Haga clic en Add para crear otro grupo de hosts o VM.
Asigne al grupo de hosts o VM el nombre Secondary.
Agregue los dos hosts de ESXi llamados esx-03a.corp.local y esx-04a.corp.local al grupo de hosts o VM.
Seleccione Secondary.
En Secondary Host Group, se encuentran los hosts de ESXi llamados esx-03a.corp.local y esx-04a.corp.local.
Asigne al grupo de hosts o VM el nombre Primary-VM.
En Type, seleccione VMGroup.
Agregue la VM llamada VM-Primary al grupo de VM.
Seleccione Primary-VM.
En Primary-VM VM Group, se encuentra la VM llamada VM-Primary.
Asigne al grupo de hosts o VM el nombre Secondary-VM.
Agregue la VM llamada VM-Secondary al grupo de VM.
Seleccione Secondary-VM.
En Secondary-VM VM Group se encuentra la VM llamada VM-Secondary.
Sección VM-Host Rules
Seleccione VM/Host Rules.
Haga clic en Add en VM/Host Rules.
Asigne a VM/Host Rule el nombre PrimaryVMHosts.
En Type, seleccione Virtual Machines to Hosts.
En VM Group, seleccione Primary-VM y Should run on hosts in group.
En Host Group, seleccione Primary.
Se creó nuestra primera regla de host o VM.
Las máquinas virtuales que son miembros del Grupo de VM deben ejecutarse en hosts que sean miembros del Grupo de hosts.
Asigne a VM/Host Rule el nombre SecondaryVMHosts.
En VM Group, seleccione Secondary-VM y Should run on hosts in group.
En Host Group, seleccione Secondary.
Está creada nuestra segunda regla de host o VM.
Habilitación de HA en un clúster extendido de VSAN
Para proporcionar disponibilidad para las máquinas virtuales en un clúster extendido de VSAN, es necesario configurar vSphere HA. Con esto, cuando se produce una falla en el host, las VM pueden reiniciarse en el mismo sitio (con reglas de afinidad) o reiniciarse en un sitio remoto cuando hay una falla total del sitio. Sin embargo, existen ciertas opciones que deben configurarse de una manera específica, las cuales son fundamentales para lograr alta disponibilidad en un clúster extendido de VSAN.
Seleccione vSphere HA.
vSphere HA está desactivado en este momento. Haga clic en Edit.
Hemos preconfigurado algunas opciones de vSphere HA para usted. Para que sirvan de referencia, las llamaremos "nuestras".
Seleccione Turn On vSphere HA.
Expanda Failure conditions and VM response.
Para VM restart priority, seleccione High desde la lista desplegable.
Para Response for Host Isolation, verifique que esté seleccionada la opción Power off and restart VMs .
Desplácese hacia abajo y expanda Admission Control.
Si se produce una falla en el sitio, es posible que todas las VM deban ejecutarse en un solo sitio, que es, en realidad, la mitad del clúster total. Para asegurarse de que se suplan las reservas, debemos configurar HA para que reserve el 50 % de los recursos (es decir, un solo sitio).
En la sección Admission Control, verifique lo siguiente:
Define failover capacity by reserving a percentage of the cluster resources.
Reserved failover CPU capacity: 50 %
Reserved failover Memory capacity: 50 %
Expanda Datastore for Heartbeating.
Seleccione Use datastores only from the specified list.
Expanda la opción Advanced Options.
Explicaremos la configuración de la siguiente manera:
das.ignoreInsufficientHbDatastore : HA informará un problema de configuración del host si no pudo seleccionar el número de datastores requerido para un host dado mediante das.heartbeatDsPerHost. Configure esta opción en "true" para suprimir esta advertencia y en "false" para habilitarla.
das.ignoreRedundantNetWarning : HA informará un problema de configuración en un host si el host no está configurado con redes redundantes para las redes que usa HA. En versiones anteriores a la 5.5, HA solo usa redes de administración, mientras que en la versión 5.5, si vSAN está habilitado, HA usará las redes configuradas para vSAN.
das.isolationAddressX : se usan direcciones IP y un agente FDM para verificar el aislamiento cuando no se observa tráfico de red de agentes en la red(*) que usa HA. Para la verificación, HA usará la puerta de enlace de la red de administración predeterminada como una dirección aislada de forma predeterminada más aquellas que se especifiquen en esta opción avanzada como direcciones adicionales. Recomendamos agregar una dirección aislada para cada red de administración que use HA.(*) En versiones anteriores a la 5.5, HA usa solo la red de administración, pero en la versión 5.5, cuando vSAN también está habilitado en el clúster, HA usará la red de vSAN para la comunicación entre agentes.
das.respectVmVmAntiAffinityRules : respeta las reglas de no afinidad vm-vm cuando se reinician las máquinas virtuales después de una falla. Los valores válidos son "false" (predeterminado) y "true".
das.useDefaultIsolationAddress : establece si la dirección de aislamiento predeterminada (puerta de enlace de la red de administración) debe usarse cuando se define si un host está aislado de la red. De manera predeterminada, se usa la puerta de enlace predeterminada para la red de administración. Si la puerta de enlace predeterminada es una dirección que no permite hacer ping, configure "das.isolationaddressX" en una dirección que permite hacer ping y deshabilite el uso de la puerta de enlace predeterminada mediante la configuración de esta opción en "false".
Haga clic en OK para habilitar vSphere HA.
El estado de vSphere será enabled o Turned On.
Si vSphere HA no se habilita en un host ESXi, haga clic con el botón secundario del mouse en el host y seleccione Reconfigure for HA.
Verificación del estado del host de vSphere HA
En algunos casos, en este entorno de laboratorio, podemos tener problemas de instalación del agente de vSphere HA en uno o más hosts ESX.
Navegue hasta Cluster -> RegionA01-COMP01.
Se indicará aquí el nombre del host o de los hosts donde se encuentra el problema.
A continuación, solucione el problema en cada uno de los hosts que se mencionan.
Haga clic en el host esx-01a.corp.local. (En este ejemplo, es el host esx-01a.corp.local. En su entorno de laboratorio podría ser esx-02a.corp.local o esx-03a.corp.local o esx-04a.corp.local).
Haga clic en la pestaña Summary para confirmar que el problema es el siguiente: "vSphere HA agent for this host has an error".
Haga clic con el botón secundario del mouse en el host.
Haga clic en "Reconfigure for vSphere HA".
Actualice vSphere Web Client para asegurarse de que está solucionado el error de HA y que se muestra en la pestaña Summary de cada host.
Configuración de HA para que se respeten las reglas de afinidad de VM a host
En esta configuración, se define una vez más cómo se comportará vSphere HA cuando se produzca una falla total del sitio.
Dicha configuración puede interpretarse de la siguiente manera:
Si hay varios hosts en ambos sitios y uno de los hosts falla, vSphere HA intentará reiniciar la VM en los hosts restantes en ese sitio, manteniendo la afinidad de la lectura.
Si hay una falla total del sitio, vSphere HA intentará reiniciar las máquinas virtuales en los hosts en el otro sitio. Si se selecciona la opción "mustrespect", que se muestra arriba, entonces vSphere HA no podría reiniciar las máquinas virtuales en el otro sitio, ya que se rompería la regla. Si se usa la regla "should respect", es posible hacerlo.
Encendido de las VM
Encienda las dos VMs llamadas VM-Primary y VM-Secondary.
Debe observar que VM-Primary se esté ejecutando en esx-01a.corp.local o esx-02a.corp.local y VM-Secondary se esté ejecutando en esx-03a.corp.local o esx-04a.corp.local.
Las reglas de host o VM que creamos lo determinaron de esta manera.
Importante: Tome nota del host de ESXi en el que se está ejecutando la VM-Primary , ya que necesitaremos este dato más adelante.
Verificación de la asignación de componentes para VM-01
Seleccione VM-Primary.
Seleccione Policies.
Seleccione Hard disk 1.
Seleccione Physical Disk Placement.
En el diseño, se muestra que la VM se implementó correctamente, con un componente por dominio de fallas (sitio) y con el componente testigo en el host testigo (esx-07a.corp.local ).
Como podemos ver claramente, una copia de los datos reside en el almacenamiento en Preferred Fault Domain, una segunda copia de los datos reside en Secondary Fault Domain, el componente testigo reside en el host testigo y el almacenamiento en el sitio testigo.
Comprobación del estado de VSAN
Antes de que apliquemos cualquier escenario de falla, confirme que se hayan aprobado todas las comprobaciones del estado.
Ignore cualquier advertencia del estado de compatibilidad del hardware, ya que estamos realizando la ejecución en un entorno virtualizado y no tenemos habilitado el servicio de rendimiento de VSAN en este clúster.
Escenario de fallas: reinicio de un solo host
En este paso, simularemos un escenario de falla de un solo host de ESXi y reiniciaremos un solo host que tiene uno de los componentes de la VM.
Seleccione el host de ESXi que se está ejecutando en la VM VM-Primary y reinícielo. (El host ESX en su entorno puede ser diferente).
Seleccione esx-02a.corp.local, haga clic con el botón secundario del mouse y seleccione Power -> Reboot.
Seleccione OK para reiniciar el host de ESXi.
Espere unos minutos mientras se reinicia el host de ESXi (no responde) y hasta que pueda acceder de nuevo a la VM VM-Primary.
Seleccione la VM llamada VM-Primary.
Después de unos minutos, debido a que el host de ESXi se reinicia y a que se produjo una falla en la VM VM-Primary como parte del evento de HA, verá que el objeto de Virtual SAN en ese host aparecerá como Absent.
En este paso, debe ser paciente. Es posible que deba actualizar vSphere Web Client.
Ubicación de la VM
Aquí, podemos ver que se produjo un evento de vSphere HA y que la VM VM-Primary se encendió en otro host (esx-01a.corp.local ) en el mismo dominio de fallas de VSAN.
Reinicio de VM-Primary en otro host
Vuelva atrás a la vista Summary de la VM para la VM llamada VM-Primary.
Tenga en cuenta que se inició la VM en el otro host de ESXi llamado esx-01a.corp.local .
Host de ESXi completamente encendido
Espere a que se enciendan completamente los hosts de ESXi y vuelva a conectarse a vCenter Server.
Vuelva a ejecutar la Comprobación del estado . El estado de las pruebas ahora debería ser Passed.
Situación de falla: pérdida de todo el sitio
En este escenario, simularemos la pérdida de todo el sitio. Al hablar de todo el sitio, nos referimos al dominio de fallas preferido (esx-01a.corp.local y esx-02a.corp.local).
Seleccione Related Objects.
Seleccione Hosts.
Seleccione esx-01a.corp.local y esx-02a.corp.local. (Haga clic en esx-01a.corp.local, mantenga presionada la tecla Ctrl y haga clic en click esx-02a.corp.local).
Haga clic con el botón secundario del mouse en la selección y seleccione Power -> Reboot.
Escenario de falla: pérdida del sitio
Haga clic en Yes para ejecutar esta acción en los 2 hosts de ESXi.
Seleccione All Hosts y haga clic en OK.
Espere unos minutos mientras se reinician los hosts de ESXi (no responden) y hasta que pueda acceder de nuevo a la VM VM-Primary.
Después de unos minutos, debido a que el host de ESXi se está reiniciando y a que se produjo un error en VM-Primary como parte de un evento de HA, verá que el objeto de VSAN en ese host aparecerá como Absent.
Aquí, podemos ver que se produjo un evento de vSphere HA y que la VM VM-Primary se encendió en un host (esx-04a.corp.local) en el dominio de fallas Secondary de VSAN.
Hosts de ESXi completamente encendidos
DRS: automatización parcial
Seleccione Monitor -> vSphere DRS -> Recommendations.
Dado que tenemos DRS en modo parcialmente automatizado, DRS manejará la ubicación inicial de las máquinas virtuales.
Sin embargo, surgirán más recomendaciones en cuanto a la migración orientadas al administrador para que decida si mover la máquina virtual o no.
El administrador puede revisar la recomendación y decidir no realizar la migración de la máquina virtual.
Si no se muestran recomendaciones de DRS, haga clic en Run DRS Now.
Haga clic en Apply Recommendations.
Migración de VM-Primary a otro host
Una vez que se ha completado la tarea de migración, la VM llamada VM-Primary se ejecuta en el host de ESXi llamado esxi-02a.corp.local.
Tareas de vSphere
Seleccione Recent Tasks.
Aquí, podemos ver los resultados de la tarea Migrate virtual machine, con la que se realizó la migración de la VM llamada VM-Primary de esx-04a.corp.local nuevamente a esx-02a.corp.local.
En este módulo, se analiza la serie completa de herramientas disponible para que pueda monitorear y resolver problemas en un entorno de VSAN, además de cómo usarlas para investigar y solucionar rápidamente los problemas en VSAN. Con VSAN, se pueden aprovechar las herramientas existentes de vSphere, así como algunas herramientas incorporadas específicas de VSAN. En este capítulo, se presentan las siguientes herramientas:
Comprobación del estado: una función incorporada con la que se ejecuta una serie de pruebas en el clúster de VSAN y se informa cualquier vulnerabilidad.
ESXCLI: la interfaz de línea de comando (CLI) del host de ESXi.
Ruby vSphere Console (RVC): una herramienta genérica para administrar instancias de vCenter Server, pero que también se extendió para hacerla compatible con VSAN.
Performance service: una nueva función disponible en VSAN 6.2 que proporciona métricas de rendimiento detalladas sobre todos los aspectos de VSAN.
VSAN Observer: una herramienta de rendimiento web mediante la cual se aprovechan las ventajas de RVC.
ESXTOP: herramienta de monitoreo del rendimiento del host de ESXi.
Inicio del módulo 4
Haga clic en el botón Module 4 Start.
¡El laboratorio se preparó correctamente para el módulo 4!
Comprobación del estado de Virtual SAN
En Virtual SAN 6.2, existe de manera predeterminada un total de siete categorías de pruebas de comprobación del estado. Estas son las siguientes:
Estado de la HCL de Virtual SAN
Estado de los límites
Estado de los discos físicos
Si VSAN se implementa como un clúster extendido, hay un conjunto adicional de comprobaciones del estado asociado con dicha configuración. Analicemos estas comprobaciones del estado de manera más detallada.
Estado de Virtual SAN
Seleccione Monitor -> Virtual SAN -> Health.
Ahora, verá la lista de alto nivel de las comprobaciones del estado en Virtual SAN 6.2.
Puede expandir cada una de las pruebas para ver las pruebas individuales que pueden evaluarse.
Comprobación del estado de VSAN: Ask VMware
Otro aspecto muy útil de la comprobación del estado es que, en cada prueba, se muestra el enlace "Ask VMware". Para aquellos de ustedes que no están familiarizados con Ask VMware, estos enlaces dirigen a los administradores directamente a un artículo de la Knowledge Base de VMware, en el que se detalla el objetivo de la prueba, los motivos por los que podría fallar y lo que se puede hacer para remediar la situación. Si una de las pruebas falla, los administradores deben siempre hacer clic en el botón Ask VMware y leer el artículo de la KB asociado. En muchos casos, se ofrecen pasos para encontrar una resolución. En otros casos, los administradores deben comunicarse con el soporte VMware para obtener más ayuda.
Expanda la comprobación del estado Data.
Seleccione Virtual SAN object health.
Observe la ubicación del botón Ask VMware .
Cuando haga clic en Ask VMware, se lo dirigirá a un artículo de la Knowledge Base de VMware, donde encontrará una explicación de la comprobación del estado de VSAN y cómo resolver cualquier estado de error.
Dentro de este entorno de laboratorio, no tenemos acceso a Internet, por lo que no podemos acceder al sistema de la Knowledge Base de VMware, pero, en el paso siguiente, hemos tomado un ejemplo de uno de los artículos de la KB para que sirva como referencia.
Ejemplo de la Knowledge Base de Virtual SAN
Este es un ejemplo de uno de los artículos de la Knowledge Base de Ask VMware sobre la comprobación del estado de Virtual SAN.
Mediante el estado de la lista de compatibilidad de hardware (Hardware Compatibility List, HCL) de Virtual SAN se verifica que el hardware del controlador de almacenamiento y la versión del controlador estén incluidas en la HCL y sean compatibles con esta versión de VSAN. Si alguno de estos no está en la HCL o no son compatibles con esta versión de VSAN (concretamente, para la versión de ESXi en la que se está ejecutando VSAN), se mostrará una advertencia en la comprobación del estado.
Otro punto es verificar que el estado de Virtual SAN HCL DB sea up-to-date. En otras palabras, las evaluaciones se realizan sobre una versión válida y actualizada de la base de datos de la HCL.
Expanda la opción Hardware Compatibility.
Las pruebas Controller Driver y SCSI Controller se muestran con error en nuestro entorno de laboratorio porque estamos ejecutando estos laboratorios en un entorno de laboratorio anidado y no en un hardware físico.
Dado que la HCL se actualiza de forma regular y frecuente, los administradores deben actualizar la versión local de la base de datos de estas evaluaciones. Esto puede hacerse en línea (si su vCenter Server tiene acceso a VMware.com) o, de manera alternativa, si su vCenter Server no está en línea, puede descargar un archivo de la DB de la HCL y actualizarlo. Para actualizar la versión de la DB de la HCL en línea, simplemente haga clic en "Upload from file" o en "Get latest version online", como se muestra en la prueba de la comprobación del estado.
Una alternativa es navegar hacia el objeto del clúster de VSAN en el inventario de vCenter Server, seleccionar Manage, seleccionar Health and Performance y, luego, hacer clic en el botón "Get latest version online", que se encuentra en la sección HCL Database. En el campo "Last updated", ahora debería decir "Today".
Existe un número de diferentes pruebas asociadas con el estado del clúster. En primer lugar, se evalúa para asegurarse de que el servicio de comprobación del estado esté instalado en todos los hosts del clúster. En segundo lugar, se verifica que todos los hosts se estén ejecutando en una versión actualizada y, por último, que el servicio de comprobación del estado funcione correctamente.
También hay una comprobación del estado que sirve para garantizar que una serie de parámetros avanzados relacionados con Virtual SAN esté configurada de manera coherente en todos los hosts del clúster de VSAN. Con esto, se evitará cualquier problema que surja de tener un subconjunto de hosts con un cierto valor y otro conjunto de hosts con otro valor para una configuración avanzada en particular. Tenga en cuenta que, con esta prueba, no se valida si el valor es "bueno" o, incluso, si es el valor "predeterminado". Solo se verifica que todos los hosts de ESXi en el clúster de VSAN tengan el mismo valor.
Una evaluación final que vale la pena destacar es la prueba CLOMD live-ness. Mediante el administrador de objetos en el nivel del clúster (cluster level object manager, CLOM), se ejecuta un daemon llamado clomd en cada host de ESXi en el clúster. CLOM es responsable de crear, reparar y migrar objetos, además de ser fundamental para el manejo de diversos flujos de trabajo y fallas en VSAN. Si, en un host, el clomd no responde por algún motivo, esta prueba no tendrá éxito.
Con VSAN 6.2, se incorporó una serie de evaluaciones del clúster adicionales con el fin de manejar la eficiencia del espacio. Entre las nuevas evaluaciones, la eficiencia del espacio se refiere a las funciones de desduplicación y compresión que son nuevas en VSAN 6.2. Con estas evaluaciones, se garantiza básicamente que todos los hosts y todos los grupos de discos en el clúster estén configurados de manera correcta en cuanto a la eficiencia del espacio y se destaca cualquier error que se descubra en el clúster.
En la sección salud de Network se encuentra la mayoría de las pruebas. Se observan todos los aspectos de la configuración de la red, como, por ejemplo, garantizar que cada host en el clúster de VSAN tenga una interfaz VMkernel configurada para el tráfico de VSAN, que se pueda enviar ping correctamente entre todos los hosts de la interfaz de red de VSAN y que todas las interfaces tengan configuraciones multicast coincidentes.
Existen también evaluaciones de red con las que se garantiza que todos los hosts de ESXi en el clúster de VSAN se añadan a vCenter Server, que ningún host tenga problemas de conectividad y que todos los hosts del clúster participen en el clúster de VSAN. Asimismo, esta es la primera comprobación del estado que se debe visitar si hay una partición en la red.
Aquí, se informarán cuáles son los hosts que están en cada partición o si hay una partición total en la red y cada host se encuentra aislado de los demás (esto último suele ser una indicación de que existe un problema multicast en la red).
Expanda Network.
La sección Data tiene la prueba Virtual SAN object health. Mediante esta prueba, se evalúa que todos los objetos implementados en el datastore de VSAN se encuentren en buen estado. Además, se destacarán los objetos en mal estado. Hay distintas razones que explican la presencia de un objeto en mal estado, que van desde un objeto con disponibilidad reducida dado que se están reconstruyendo componentes o que está a la espera de que se reconstruyan. Otra razón podría ser que es imposible acceder a un objeto, probablemente, como resultado de varias fallas en el clúster. Esta prueba proporciona una descripción general del estado del objeto en la que se muestran los distintos estados de los objetos. Si, para reconstruir los componentes ausentes, VSAN está esperando a que se complete el temporizador de CLOMD de 60 minutos, el administrador puede anular esta operación e iniciar una reconstrucción inmediata (p. ej., en un caso en el que se pudo haber producido una falla en un host y este no se recupera pronto). Además, con esta prueba, se informa a los administradores si la reconstrucción de componentes ya está en progreso.
Expanda Data.
Mediante la comprobación del estado de los límites se evalúan diversos límites del clúster de VSAN. En la prueba "current cluster situation", se evalúa el límite del componente, que, en este momento, es 9.000 por host. También se evalúa la utilización del espacio del disco y, por último, se evalúa la reserva en caché de lectura. Si alguno de estos valores supera el umbral límite, aparecerá una advertencia. Por medio de una evaluación de límites adicional, se analiza el impacto que tendrá una falla del host en los límites del clúster. Si, cuando se considera una falla del host, se supera alguno de los límites, aparece otra advertencia. Esto es, en cierta forma, similar a lo que sucede con el control de admisión en vSphere HA, en el que se brinda asistencia a los administradores en términos de monitoreo, independientemente de que haya o no recursos suficientes para que VSAN se ajuste de manera automática en caso de una falla.
Expanda Limits.
Estado del disco físico
En el estado del disco físico, se encuentran diversas evaluaciones con las que se analizan distintos aspectos del almacenamiento de VSAN. Mediante la comprobación del estado de los discos en general, se observan varios problemas en las unidades de discos físicos, incluidos problemas superficiales, problemas con los controladores, problemas con el driver y problemas con la pila de E/S. Esta prueba tampoco tendrá éxito si se encuentran errores, como problemas con el estado de los metadatos, problemas de congestión, problemas con el estado del software o problemas con la capacidad del disco. Si esto ocurre, los administradores deben buscar qué otras pruebas no tuvieron éxito para determinar la causa principal.
En la prueba Component limit health, se verifica que no se haya excedido el límite superior del número de componentes por disco. En la región de 50.000, la cifra es bastante grande, pero con esta prueba de comprobación del estado se sabrá si algún disco está alcanzando el límite de saturación desde la perspectiva del conteo de componentes. Otra prueba interesante para los administradores es la de congestión (Congestion). Esta puede ser un indicador de que, tal vez, VSAN se está ejecutando con menos rendimiento. Existen diversas razones para esto y, por lo general, se requiere una investigación más profunda. Algunos ejemplos son los siguientes: un clúster subdimensionado de VSAN para la carga de trabajo que se ejecuta en él, hardware, controlador y firmware en mal estado en el controlador de almacenamiento o, incluso, problemas de software.
La prueba de capacidad de discos arrojará advertencias si la utilización del disco físico empieza a convertirse en un problema. Si el espacio en el disco físico está por debajo del 80 %, el informe de la prueba será positivo (en verde). Si la utilización del disco está entre 80 % y 95 %, en el estado se mostrará una advertencia (en amarillo). Si la utilización supera el 95 %, en la comprobación del estado se arrojará una alerta (en rojo). El umbral es 80 % y allí es donde comienza el rebalanceo automático.
El último conjunto de pruebas que se mencionará en el estado del disco físico es la prueba de los depósitos de memoria (Memory pools). Aunque es poco probable que suceda, estas evaluaciones tienen como objetivo garantizar que las pilas y los bloques que se utilizan en Virtual SAN no se estén ejecutando lentamente. Si se muestran advertencias, aconsejamos comunicarse con el soporte VMware para determinar el motivo. Si los depósitos de memoria se ejecutan lentamente, pueden surgir problemas de rendimiento o, incluso, fallas operacionales.
Expanda Physical Disk.
Mediante la función Performance Service de la liberación de versión de Virtual SAN 6.2, VMware proporciona informes de rendimiento básico de Virtual SAN desde vSphere Web Client. El objetivo es que esta función esté "siempre activada" y completamente integrada con la interfaz de usuario (User Interface, UI) de vSphere Web Client, que sea fácil acceder a ella y consumirla, y que se mantengan los datos históricos del rendimiento de VSAN.
Para almacenar una base de datos de estadísticas (DB de estadísticas), se utiliza un objeto del espacio de nombres de Virtual SAN. Se trata de un objeto regular (objeto de estadísticas), el cual se asocia con una política. La política se elige cuando el administrador habilita la función Performance service. Si no se elige una política específica, se usa la política predeterminada del datastore de VSAN. En la política predeterminada, el atributo NumberOfFailuresToTolerate está configurado en 1, lo que implica que si hay una falla en el clúster de VSAN, la función Performance service no se verá afectada y continuará ejecutándose. Por lo tanto, Performance service no tiene un único punto de falla.
En cada host de ESXi en el clúster de VSAN, Performance service ejecuta un daemon para recopilar métricas de rendimiento. Estas métricas se calculan como un promedio de intervalos de más de 5 minutos. La recolección de datos siempre está activada. Estas estadísticas se almacenan en la DB de estadísticas en el objeto de estadísticas. Esto implica que vCenter Server no es un elemento necesario para ningún aspecto de la infraestructura de estadísticas, como configuración, recopilación, almacenamiento y consulta.
Habilitación de Performance service
Cuando se crea un nuevo clúster de Virtual SAN, el estado de la función Performance service es disabled. Active la función Performance service de Virtual SAN para monitorear el rendimiento de los clústeres, los hosts, los discos y las VM de Virtual SAN. Cuando se activa la función Performance service, Virtual SAN coloca un objeto de la base de datos de estadísticas en el datastore para recopilar datos estadísticos. La base de datos de estadísticas es un objeto de espacio de nombres que reside en el datastore del clúster de Virtual SAN.
Antes de habilitar la función Performance service de Virtual SAN, asegúrese de que el clúster esté configurado de manera apropiada y que no haya problemas de estado pendientes.
Seleccione Manage -> Settings -> Health and Performance.
Para habilitar Performance service, haga clic en Edit.
Seleccione la casilla de verificación de Turn On Virtual SAN performance service .
Seleccione una Storage Policy para el objeto de la base de datos de estadísticas.
Seleccione Virtual SAN Default Policy.
La opción Virtual SAN Default Storage Policy está seleccionada de manera predeterminada. Aquí, se incluye el atributo de la política NumberOfFailuresToTolerate set to 1, lo que hace que la función Performance service esté altamente disponible.
Seleccione RegionA01-COMP01 -> Manage -> Settings -> Health and Performance.
Si analizamos el estado de la función Performance service después de que se habilitó, debería ver un estado similar al siguiente.
A partir de aquí, usted también puede usar las opciones Turn off o Edit the Storage policy que utilizaPerformance service.
Clúster: Virtual SAN - Virtual Machine Consumption
Seleccione RegionA01-COMP01 -> Monitor -> Performance -> Virtual SAN - Virtual Machine Consumption .
Puede usar la función Performance service de Virtual SAN para monitorear el rendimiento del entorno de Virtual SAN e investigar posibles problemas.
Mediante dicha función, se recopilan y se analizan estadísticas de rendimiento y los datos se muestran en un formato gráfico para que pueda determinar las causas principales de los problemas. Puede ver las tablas de rendimiento para el clúster, así como para cada host, grupo de discos y disco en el clúster de Virtual SAN. También puede ver las tablas de rendimiento para máquinas virtuales y discos virtuales.
Mediante la función Performance service de Virtual SAN, se muestran las tablas de rendimiento, las cuales pueden ser útiles para monitorear la carga de trabajo y ayudar a determinar las causas principales de los problemas.
Cuando la función Performance service está activada, en la pestaña Summary del clúster, se muestra una descripción general de las estadísticas de rendimiento de Virtual SAN, incluida la capacidad, la tasa de transferencia, la E/S por segundo y la latencia de Virtual SAN. En el nivel del clúster, puede ver tablas de estadísticas detalladas para el consumo de la máquina virtual y el back-end de Virtual SAN.
Clúster: Virtual SAN - Backend
Seleccione RegionA01-COMP01 -> Monitor -> Performance -> Virtual SAN - Backend.
En Virtual SAN, se muestran tablas de rendimiento para las operaciones de back-end de los hosts, incluidas la E/S por segundo, la tasa de transferencia, la latencia, la congestión y las E/S pendientes. En cada host de ESXi en el clúster de VSAN, Performance service ejecuta un daemon para recopilar métricas de rendimiento.
Estas métricas se calculan como un promedio de intervalos de más de 5 minutos.
En ESXi 5.5 U1, se incorporó un nuevo espacio de nombres de ESXi CLI (ESXCLI): esxcli vsan. Aquí, encontramos una selección de espacios de nombres adicionales que pueden usarse para analizar, monitorear y configurar el clúster de Virtual SAN.
Conexión con ESXi
En el espacio de nombres esxcli vsan datastore, se proporcionan comandos para la configuración del datastore de VSAN. En este paso, es muy poco lo que se puede hacer sino acceder y configurar el nombre del datastore de VSAN. De manera predeterminada, el nombre del datastore de VSAN es vsanDatastore. Si planea cambiar el nombre vsanDatastore, debe hacerlo en el nivel del clúster mediante vSphere Web Client. Es muy recomendable que si usted administra varios clústeres de VSAN desde el mismo vCenter Server, debe asignar nombres únicos y fáciles de identificar a los datastore de VSAN.
En este espacio de nombres, se ofrecen comandos para la configuración de la red de VSAN. Este es, en cierta medida, más útil que el espacio de nombres del datastore anterior, ya que, con él, usted puede enumerar la configuración actual o borrarla, restaurar la configuración de la red de VSAN (esto lo usa ESXi durante el proceso de arranque y no está diseñado para la invocación del cliente), así como eliminar una interfaz desde la configuración de la red de VSAN.
Aquí, es interesante observar la información multicast: hay un requisito para permitir el tráfico multicast entre los hosts de ESXi que participan en el clúster de VSAN. Otro punto que resulta interesante tener en cuenta es que la liberación de versión inicial de VSAN solo era compatible con IPv4. En VSAN 6.2, se incorpora la compatibilidad con IPv6. Sin embargo, lo más interesante es la información detallada sobre multicast. Agent Group Multicast Port corresponde al puerto de cmds que se abre en ESXi firewall cuando se habilita VSAN. La primera dirección IP, 224.2.3.4, se usa para la comunicación principal o de respaldo, mientras que la segunda dirección, 224.1.2.3, se usa para los agentes.
esxcli vsan network list es un comando útil para ver el estado y la configuración de la red en caso de que se produzca una partición de la red.
Este espacio de nombres se usa para la configuración de almacenamiento y se incluyen opciones sobre la manera en la que VSAN debe reclamar discos, así como la posibilidad de agregar y eliminar discos físicos en VSAN. Con el comando esxcli vsan storage automode, se puede obtener o configurar la opción de reclamo automático. Si esta está deshabilitada, el clúster está en modo manual.
Para mostrar los dispositivos de caché y de capacidad que se reclamaron y que VSAN tiene en uso desde un determinado host de ESXi, puede usar la opción de la lista. En esta configuración en particular, que es una configuración all-flash, se usan SDD para dispositivos en el nivel de capacidad y el nivel de caché. Todos los dispositivos tienen la marca "true" en el campo Used by this host, lo que significa que fueron reclamados por VSAN y, en el campo Is SDD, se indica el tipo de dispositivo ("true" para dispositivos flash).
Con el comando esxcli vsan cluster, el host de ESXi, donde se encuentra el comando, puede ejecutarse para obtener información del clúster de VSAN y también puede abandonar o unirse a un clúster de VSAN. Esto puede resultar muy útil en un escenario en el que vCenter Server no está disponible y se debe eliminar un determinado host del clúster de VSAN. La funcionalidad de restauración no está diseñada para la invocación del cliente; ESXi la utiliza durante el proceso de arranque para restaurar la configuración del clúster activo desde el archivo de configuración.
Para este comando, resulta útil la opción "get" para recopilar información sobre el estado de los hosts locales de ESXi (nodos), así como sobre el rol en el clúster. Puede ver que este host de ESXi es MASTER y que el estado es HEALTHY. Otros estados son agent y backup. Estos estados se relacionan con el rol que cumple el host para el servicio de disposición en clústeres (CMMDS).
Otra información útil adicional de este resultado es el campo Subcluster member UUIDs. En total, hay cuatro entradas en este campo, lo que indica que se trata de un clúster de 4 nodos. Siempre es útil mostrar cuántos nodos considera cada host que participan en el clúster cuando se trata de solucionar problemas de particiones. Si desea mostrar qué host corresponde a qué UUID, puede usar el comando esxcli system uuid get < uuid > command.
De esta manera, sabrá el UUID del nodo en el que ya inició sesión.
Los dominios de fallas se incorporaron en VSAN 6.0 y, con ellos, VSAN puede reconocer la presencia de racks. Esto significa que los componentes de los objetos que forman parte de la misma máquina virtual pueden ubicarse no solo en diferentes hosts, sino también en diferentes racks. De esta manera, en caso de una falla total en el rack (por ejemplo, falla eléctrica), existe aún un conjunto completo de componentes de la máquina virtual disponibles para mantener el acceso a la VM.
Los dominios de fallas también se usan para el clúster extendido de VSAN y configuraciones de 2 nodos. Esto se trató anteriormente en el libro. Es poco probable que necesite usar este espacio de nombres esxcli vsan faultdomain para una configuración de esas características. VMware recomienda que se use la UI de vSphere Web Client para todas las configuraciones de dominio de fallas, clúster extendido y de 2 nodos (oficinas remotas y sucursales).
VSAN asocia una política de almacenamiento predeterminada con los objetos de almacenamiento de la VM. El espacio de nombres esxcli vsan policy es una forma de analizar y modificar esta política de almacenamiento predeterminada.
Aquí, podemos ver los diferentes objetos de almacenamiento de la VM que forman una VM implementada en un datastore de VSAN. Asimismo, se pueden ver los valores predeterminados de esta política.
La clase vdisk se refiere a los objetos de disco de la VM (VMDK). También abarca snapshot deltas. La clase vmnamespace es el espacio de nombres principal de la VM donde se almacenan archivos de configuración, archivos de metadatos y archivos de registros que pertenecen a la VM. La clase vmswap policy se refiere, por supuesto, al intercambio de VM. Una nota final para vmswap es que también tiene un valor forceProvisioning. Esto significa que, si bien no hay suficientes recursos en el clúster de VSAN para cumplir con el requisito de aprovisionar ambas replicas del intercambio de VM y, de esta manera, cumplir con el requisito de fallas que pueden tolerarse, VSAN aprovisionará la VM con una única instancia de intercambio de VM.
esxcli vsan trace es una herramienta de diagnóstico y resolución de problemas y no debe usarse sin la orientación necesaria de los servicios de soporte global de VMware (global support services, GSS). Se diseñó con el fin de capturar diagnósticos internos de VSAN para llevar a cabo análisis detallados.
El comando vdq tiene dos objetivos y es una excelente herramienta de resolución de problemas que debe tener en el host de ESXi. La primera opción para este comando indica si los discos en el host de ESXi son elegibles para VSAN y, de no serlo, el motivo por el cual no lo son. La segunda opción para este comando indica que, una vez que se habilitó VSAN, usted puede usarlo para mostrar información sobre el mapeo de discos, que, básicamente, se refiere a los dispositivos SSD o flash y discos magnéticos que están agrupados juntos en un grupo de discos. Ejecutemos la primera opción para consultar si los discos son elegibles para su uso en VSAN.
Como puede ver, VSAN reclamó varios dispositivos, mientras que otro disco no es elegible porque ya tiene particiones. En este ejemplo, el disco no elegible es el disco de arranque del host de ESXi. También se destaca qué disco es SSD (IsSSD), si se está usando un dispositivo flash como dispositivo de capacidad en una configuración de VSAN basado solo en flash (IsCapacityFlash) y si el disco está en un estado de pérdida de dispositivos permanente (IsPDL).
La segunda opción útil para este comando es volcar los mapeos de discos de VSAN. En otras palabras, qué dispositivos flash y qué discos magnéticos se encuentran en un grupo de discos.
Este es el resultado de la muestra (en el que se incluye la opción -H para facilitar la lectura):
En este comando, se muestra la relación de SSD con los dispositivos de capacidad, ya sean dispositivos flash, en el caso de configuraciones basadas solo en flash, o discos magnéticos, en el caso de configuraciones híbridas. En este resultado, tenga en cuenta que, aunque sean dispositivos flash, se muestran como MD (discos magnéticos). Se necesitará analizar el campo IsCapacityFlash para ver si se trata de dispositivos flash (p. ej., SSD) o no. Esto resulta muy útil si desea descubrir el diseño del grupo de discos en un determinado host desde la línea de comando. Con este comando, usted sabrá rápidamente con qué discos magnéticos se enfrentan los SSD, en especial, cuando tiene varios grupos de discos definidos en un host de ESXi.
Módulo 3: Disponibilidad y continuidad del negocio (30 minutos. Avanzado)En el modulo 3, se presentará una descripción general de los clústeres extendidos, su creación y la forma en la que Virtual SAN está estrechamente integrado con High Availability (HA) y Distributed Resource Scheduling (DRS).
Existen varias estrategias relacionadas con el desarrollo de scripts y la habilitación de la automatización en los entornos de VMware Virtual SAN.
En este módulo ilustraremos tres métodos diferentes:
Haga doble clic en el atajo 1 HOL-1708-SDC-1 - VSAN A to Z'.
Inicio del módulo 5
Haga clic en el botón Module 5 Start .
¡El laboratorio se preparó correctamente para el módulo 5!
Análisis del clúster de VSAN
Conectémonos con la instancia de Virtual Center y comencemos a explorar PowerCLI de Virtual SAN.
Pista: Los comandos de PowerCLI en este laboratorio no distinguen entre mayúsculas y minúsculas. Si prefiere copiar y pegar estos comandos, encontrará una lista completa de ellos en la carpeta 'README HOL-SDC-1708-1.txt' en el escritorio. Otra alternativa es resaltar el comando en el manual (y copiarlo al portapapeles) y luego usar la función "Send Text" del laboratorio práctico disponible en la esquina superior izquierda del laboratorio.
Cree una variable para el primer host de vSphere en el clúster de Virtual SAN. De esta manera, será más fácil administrar los comandos de PowerCLI.
Verificación de la configuración del clúster
Analice el estado enabled de VSAN y la opción VSAN Disk Claim Mode mediante este comando:
Tenemos 2 clústeres de vSphere en nuestro entorno. El clúster de VSAN se llama RegionA01-COMP01. Podemos observar que el estado de Virtual SAN es enabled y que, en Disk Claim Mode, se muestra el modo Manual.
Verificación de la configuración de la red
La comunicación de red de Virtual SAN entre los hosts presentes en el clúster de Virtual SAN se habilita mediante puertos de VMkernel redundantes que se configuran dentro de un único vSphere Distributed Switch.
Analicemos esta configuración:
A continuación, analice la opción Port Groups (presione la tecla de la flecha hacia arriba una vez para repetir el comando anterior y canalice el comando cmdlet debajo):
Verifique si Virtual SAN Traffic está habilitado en los puertos de VMkernel dedicados a Virtual SAN:
Verificación de la configuración de los discos
Analice los datastores disponibles en el host de vSphere. Para esto, use el comando Get-Datastore cmdlet. Filtraremos los resultados en cualquier datastore que tenga en su nombre la palabra "VSAN".
Get-Datastore -VMHost $vmhost | where-object {$_.Type -like "vsan"}
Cree una variable en la que se incluyan los grupos de discos de Virtual SAN. Usaremos la misma variable $vmhost (esx-01a.corp.local) que utilizamos anteriormente.
Analice el contenido de la variable creada recientemente.
Identifiquemos los discos que forman parte de estos grupos de discos de Virtual SAN (tenga en cuenta la combinación entre SSD y unidades magnéticas mediante la columna 'IsSsd'):
Políticas de almacenamiento de VSAN
Analice las políticas de almacenamiento de Virtual SAN disponibles en nuestro entorno:
Observe que limitamos la lista usando [-namespace "VSAN"]. "VVol No Requirements Policy" no está relacionada con VSAN y, por lo tanto, no aparece en el conjunto de resultados.
VM Photon-Temp
Vamos a encender una máquina virtual y a migrarla con vMotion al datastore de VSAN para poder crear y aplicar nuevas políticas de almacenamiento de manera programática.
Ejecutaremos una máquina virtual en la que se usa el sistema operativo de código fuente abierto basado en Linux más reciente de VMware: "Photon".
Primero, configuremos las variables para la máquina virtual y el datastore de VSAN:
Encienda la máquina virtual:
Realice la migración de la máquina virtual al clúster y al datastore de VSAN (esto tardará algunos minutos):
Escenario de la nueva política
En esta sección, crearemos una política basada en el almacenamiento mediante la cual se aumenta el ancho de la banda de"1" a "2".
Esta nueva política podría aprovecharse para mejorar el rendimiento, ya que, con ella, se crea una banda RAID-0 configurada en dos discos y, de esta manera, se aumenta la cantidad de Storage I/O disponible. Por medio de esta política, también se heredará la configuración "Failures to Tolerate = 1", que indica que cualquier VM que aprovecha esta política puede sobrevivir, como mínimo, a una falla de los componentes de VSAN en el entorno.
Preparación de variables
Recordatorio: Los comandos de PowerCLI se encuentran disponibles para copiar o pegar mediante el archivo README.txt en el escritorio.
Verifique que la variable $VM esté configurada en "Photon-Temp":
Cree una nueva variable con la que se capturen los discos duros para la VM Photon-Temp:
Verifique la política de almacenamiento actual aplicada a la máquina virtual Photon y a los discos duros virtuales:
Creación de una nueva política
Cree la nueva política de almacenamiento (usando Stripe-Width=2):
Presione varias veces la tecla de la flecha hacia arriba para repetir este comando o escríbala de nuevo para confirmar la creación de esta política:
Aplicación de la nueva política
Aplique la política de almacenamiento creada recientemente a la máquina virtual Photon usando las variables que se crearon antes:
Nota: En la opción Hard Disk de la máquina virtual, el estado que se verá inicialmente será 'nonCompliant'. Virtual SAN está configurando bandas adicionales para la política recientemente aplicada, y esta resincronización puede tardar varios minutos en completarse.
Cumplimiento de la política de almacenamiento de VM
Nota: Si desea verificar de nuevo el estado de cumplimiento para la VM Photon y la nueva política de almacenamiento aplicada, use este comando:
Comandos de ESXCLI a PowerCLI
Históricamente, los administradores de vSphere han tenido la posibilidad de acceder desde SSH de manera directa a un host individual de vSphere y usar comandos ESXCLI directamente.
Con Virtual SAN 6, hay nuevas opciones de comandos ESXCLI que pueden ejecutarse en el espacio de nombres ESXCLI de Virtual SAN. En esta sección, "ajustaremos" estos comandos remotos ESXCLI mediante PowerCLI (usando el cmdlet Powershell "Get-ESXCLI"). Esto puede hacerse en la ventana actual del comando PowerCLI que tenemos abierta y, de esta manera, no habrá necesidad de acceder desde SSH a un host remoto.
Creación de un objeto Get-EsxCli
Definamos una variable con la que podamos ejecutar futuros comandos:
Introduzca la nueva variable y presione Intro o Return para ver todos los espacios de nombres disponibles:
Anexe el elemento vsan a la variable para ver los espacios de nombres específicos de vsan. De esta manera, tendremos como resultado una lista de todos los posibles comandos esxcli relacionados con Virtual SAN.
Métodos expuestos: clúster
Analice de manera más detallada. Para esto, examine el elemento "cluster":
Tenga en cuenta que ahora se encuentran disponibles métodos que podemos utilizar ("get","join", "leave","new" y "restore"). Utilicemos el método get, que está configurado con un parámetro vacío, para analizar más detalles sobre el clúster de Virtual SAN, incluida la opción vSphere Host Health State:
Métodos expuestos: red
Analice la configuración de la red:
Métodos expuestos: datastore
Recupere el nombre del datastore de Virtual SAN:
De este modo, se concluye la lección sobre PowerCLI y ESXCLI.
Ruby vSphere Console (RVC) es una interfaz de usuario de consola de línea de comando interactiva para VMware vSphere y Virtual Center. Ruby vSphere Console se basa en la popular interfaz RbVmomi Ruby hacia vSphere API. Este ha sido un proyecto de código fuente abierto durante los últimos 2 a 3 años. RbVmomi se creó con el objetivo de disminuir de manera considerable la cantidad de codificación necesaria para realizar tareas de rutina, así como aumentar la eficiencia de la ejecución de tareas, todo mientras se aprovecha toda la potencia de la interfaz de programación de aplicaciones (Application Programming Interface, API) cuando es necesario.
Ruby vSphere Console viene equipado con vCenter Server Appliance (VCSA) y la versión para Windows de vCenter Server. RVC se está convirtiendo rápidamente en una de las herramientas principales para la administración y resolución de problemas de los entornos de Virtual SAN.
RVC tiene muchas de las capacidades que se pueden esperar de una interfaz de línea de comando moderna.
Modo de lenguaje Ruby
Modo de lenguaje Python
Información más detallada sobre Virtual SAN en comparación con vSphere Web Client
Visualización de clústeres de Virtual SAN mientras que en ESXCLI solo se ofrece una perspectiva del host de vSphere
Operaciones masivas mediante caracteres comodín
Funciona directamente con un host de vSphere, incluso si vCenter se encuentra sin conexión
Ruby vSphere Console es gratis y viene equipado con vCenter Server Appliance (VCSA) y vCenter Server para Windows. En este laboratorio, nos conectaremos con la instancia de VCSA y exploraremos algunas capacidades de RVC relacionadas con Virtual SAN.
Inicie Putty mediante el atajo en la barra de herramientas.
Desplácese hacia abajo y haga doble clic en vcsa-01a.corp.local.
Inicie RVC mediante el siguiente comando:
Ingrese 'Y' si aparece "Are you sure you want to continue connecting?"
Cuando se le indique, ingrese la contraseña: VMware1!
La infraestructura de vSphere y Virtual SAN se presenta al usuario como un sistema de archivos virtual que puede navegarse con los comandos tradicionales para enumerar directorios (ls) y cambiar directorios (cd). El sistema de archivos virtual refleja la jerarquía de la infraestructura de vSphere y permite que los comandos de RVC se usen en cada una de las entidades manejables y en sus componentes individuales (por ejemplo, vCenter, centro de datos, clúster, almacenamiento, hosts, redes, datastores, VM).
Navegue por la estructura del directorio mediante los comandos "cd" y "ls". El texto entre paréntesis debajo sirve solo como referencia y no debe escribirse. El comando "cd" utiliza los numerales "1" y "0":
Vea una lista de los centros de datos que se encuentran disponibles mediante el comando "ls":
Cambie al directorio del centro de datos y vea una lista de los recursos que se encuentran disponibles:
Cambie al directorio de computadoras y enumere los clústeres de vSphere y los hosts independientes de vSphere que se encuentran disponibles:
Cambie al directorio de clústeres de vSphere y enumere los hosts y los depósitos de recursos en este clúster:
Cambie al directorio de hosts y enumere los hosts individuales de vSphere en este clúster, junto con los detalles de CPU y memoria:
Información sobre el host de VSAN
Analice la información de los hosts para el host esx-04a.corp.local en el clúster de VSAN. Para esto, ingrese lo siguiente:
Información en el nivel del clúster de VSAN
Como se mencionó en la sección "Ventajas" anterior, RVC no se limita a trabajar con un único host de vSphere por vez. Por ejemplo, usted puede recopilar estadísticas de discos para todos los hosts del clúster cambiando dos directorios al directorio de computadoras y, luego, usar de nuevo el comando de estadísticas de disco:
Nota: Puede que necesite aumentar el tamaño de la ventana Putty. Para esto, arrastre el controlador de la esquina para que se vea la sección Table Result Set de manera adecuada.
Existen más de 40 comandos de espacios de nombres de Virtual SAN diferentes que pueden usarse para administrar el entorno mediante Ruby vSphere Console. Puede ver los comandos de espacios de nombres de Virtual SAN si usa este comando (y desplazarse hacia arriba para ver los resultados):
Para ver todos los espacios de nombres disponibles para administrar mediante Ruby vSphere Console, simplemente use este comando:
Cuando haya terminado de explorar, escriba "exit" para cerrar la sesión de Ruby vSphere Console y, luego, escriba "exit" de nuevo para cerrar la sesión SSH de Putty.
Como se ilustra en este módulo, se encuentran disponibles diversas herramientas CLI para interactuar de manera programática con Virtual SAN.
Al elegir la herramienta más adecuada para usted, podrá habilitar un punto clave del centro de datos definido por software: la automatización.
Si desea obtener más información sobre la automatización de VSAN, pruebe una de estas opciones:
Implementaciones automatizadas del clúster extendido de Virtual SAN
Verifique los controladores de discos de VSAN con la HCL
Modifique el comportamiento de los archivos de intercambio virtual disperso
Blog oficial de PowerCLI
Blog de Alan Renouf
Blog de vSphere ESXCLI
Referencia de los comandos de RVC
Continúe con cualquiera de estos módulos debajo si todavía no los completó o si desea visitarlos de nuevo.
Lab SKU: HOL-1708-SDC-1-ES
Version: 20161012-073958

References: resolución 
 resolución 

Resolución 
 resolución 
 resolución 
 resolución