VMware Hands-on Labs - HOL-1708-SDC-1-ES


Descripción general del laboratorio: HOL-1708-SDC-1. Introducción a Virtual SAN

Orientación sobre el laboratorio


Nota: Le llevará más de 90 minutos completar este laboratorio. Su expectativa debe ser solo la finalización de entre 2 y 3 módulos durante el tiempo del que disponga.  Los módulos son independientes unos de otros, por lo que puede empezar por el comienzo de cualquiera de los módulos y continuar desde allí. Puede utilizar el Índice para acceder a cualquier módulo que desee.

Se puede acceder al Índice en la esquina superior derecha del manual de laboratorio.

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.

Lista de los módulos del laboratorio:

Directores del laboratorio:  

 

Este manual práctico se puede descargar desde el sitio de documentos de laboratorios prácticos que se encuentra en la siguiente página:

[http://docs.hol.vmware.com]

Este laboratorio puede estar disponible en otros idiomas.  Para configurar la preferencia de idioma y obtener un manual localizado con el laboratorio, puede usar este documento como ayuda para orientarse en el proceso:

http://docs.hol.vmware.com/announcements/nee-default-language.pdf


 

Ubicación de la consola principal

 

  1. El área en el recuadro ROJO contiene la consola principal.  El manual de laboratorio se encuentra en la pestaña ubicada a la derecha de la consola principal.
  2. 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.
  3. El laboratorio comienza con 90 minutos en el temporizador.  El laboratorio no se puede guardar.  Todo el trabajo debe llevarse a cabo durante la sesión del laboratorio.  Sin embargo, puede hacer clic en el botón EXTEND para prolongar el tiempo.  Si se encuentra en un evento de VMware, puede prolongar el tiempo del laboratorio dos veces, hasta 30 minutos.  Con cada clic, obtiene 15 minutos adicionales.  Fuera de los eventos de VMware, puede prolongar el tiempo del laboratorio hasta 9 horas y 30 minutos. Con cada clic, obtiene una hora adicional.

 

 

Marca de agua o petición de activación

 

Cuando inicie el laboratorio por primera vez, es probable que aparezca una marca de agua en el escritorio que indique que Windows no se activó.  

Una de las ventajas más importantes de la virtualización es que las máquinas virtuales pueden moverse y ejecutarse en cualquier plataforma.  Los laboratorios prácticos utilizan esta ventaja, por lo que podemos ejecutar los laboratorios en múltiples centros de datos.  Sin embargo, estos centros de datos pueden no tener procesadores idénticos, lo que genera una verificación de activación de Microsoft mediante Internet.

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.

Este problema superficial no afecta el laboratorio.  

 

 

Métodos alternativos para el ingreso de datos por teclado

Durante este módulo, ingresará texto en la consola principal. Además de escribir directamente en la consola, hay dos métodos muy útiles para ingresar datos que facilitan el ingreso de datos complejos.

 

 

Haga clic y arrastre el contenido del manual práctico hacia la ventana activa de la consola

También puede hacer clic y arrastrar el texto y los comandos de la interfaz de línea de comando (Command Line Interface, CLI) directamente desde el manual práctico hacia la ventana activa de la consola principal.  

 

 

Acceso al teclado internacional en línea

 

También puede utilizar el teclado internacional en línea que se encuentra en la consola principal.

  1. Haga clic en el ícono del teclado que se encuentra en la barra de tareas del inicio rápido de Windows.

 

 

Haga clic una vez en la ventana activa de la consola.

 

En este ejemplo, usará el teclado en línea para ingresar el símbolo "@" que se utiliza en las direcciones de correo electrónico. En los diseños de teclados de EE. UU., el símbolo "@" se ingresa mediante Shift-2.

  1. Haga clic una vez en la ventana activa de la consola.
  2. Haga clic en la tecla Shift.

 

 

Haga clic en la tecla @

 

  1. Haga clic en la tecla "@".

Observe que se ha ingresado el símbolo @ en la ventana activa de la consola.

 

 

Observe el sector inferior derecho de la pantalla.

 

Asegúrese de que se hayan completado todas las rutinas de inicio del laboratorio y esté listo para comenzar. Si ve otro mensaje que no sea "Ready", aguarde unos minutos.  Si el laboratorio no ha cambiado a "Ready" luego de 5 minutos, solicite asistencia.

 

Module Switcher


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

 

  1. Abra la carpeta denominada "Module Switchers" en el escritorio.
  2. Haga doble clic en el módulo denominado "1 HOL-1708-SDC-1 - VSAN A to Z".

 

 

Funcionamiento de Module Switcher

 

 

Módulo 1: Instalación y habilitación de Virtual SAN 6.2 (15 minutos. Principiante)

Introducción


¿Qué es Virtual SAN?

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.

En este módulo, se incluyen las siguientes lecciones:


Lección 1: Descripción general de Virtual SAN



 

¿Qué es Virtual SAN?

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.

Los administradores definen políticas de almacenamiento y las asignan a las VM. Una política de almacenamiento definirá los requisitos de disponibilidad, rendimiento y aprovisionamiento (p. ej., ligero). Cuando se aprovisione una VM, VSAN interpretará la política de almacenamiento y configurará los dispositivos de almacenamiento subyacente para cumplir con la política de manera automática (p. ej., RAID 1). Cuando se modifique una política de almacenamiento, VSAN reconfigurará automáticamente los recursos para cumplir con la nueva política.

Puntos clave:

Características técnicas:

 

 

 

Ventajas para el cliente

Simple

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.

Alto rendimiento

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.

TCO más bajo

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.

 

 

 

 

Casos de uso principales

 

 

Lección 2: Requisitos de Virtual SAN



 

vCenter Server

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.

 

 

vSphere ESXi

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.

Cada host de vSphere en el clúster que contribuye al almacenamiento local a Virtual SAN debe tener al menos una unidad de disco duro (Hard Disk Drive, HDD) y una unidad de disco en estado sólido (Solid State Disk, SSD).

 

 

Disco y red

 

IMPORTANTE: Todos los componentes (hardware, drivers, firmware) deben figurar en la Guía de compatibilidad de vSphere para VSAN. Las demás configuraciones no son compatibles.

El puerto VMkernel está etiquetado como Virtual SAN. Este puerto se utiliza para la comunicación de nodos entre clústeres. Además, se utiliza para lecturas y escrituras cuando uno de los hosts de vSphere en el clúster tiene una máquina virtual particular, pero los bloques de datos reales que componen los archivos de la máquina virtual se encuentran en un host de vSphere diferente en el clúster. En este caso, la E/S deberá atravesar la red configurada entre los hosts del clúster.

 

Lección 3: Preparación de un clúster de Virtual SAN


Para utilizar Virtual SAN, debe crear un clúster de hosts y habilitar Virtual SAN en el clúster.

Un clúster de Virtual SAN puede incluir hosts con discos de almacenamiento y hosts sin discos de almacenamiento.

Siga estas pautas cuando cree un clúster de Virtual SAN.

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.


 

Apertura del navegador Chrome desde la barra de tareas del inicio rápido de Windows

 

  1. Haga clic en el ícono de Chrome, que se encuentra en la barra de tareas del inicio rápido de Windows.

 

 

Inicio de sesión en vSphere Web Client

 

En la pantalla de inicio de sesión de vSphere Web Client, seleccione "Use Windows session authentication".

Haga clic en Login.

 

 

vSphere Web Client

 

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.

Seleccione Hosts and Clusters.

 

 

Habilitación de Virtual SAN

 

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.

Haga clic en Next.

 

 

 

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.

Haga clic en Next.

 

 

Reclamo de discos

 

Seleccione qué discos se deben reclamar para el caché y cuáles para la capacidad en el clúster de VSAN.

Los discos están agrupados por modelo y tamaño o por host. La selección recomendada está basada en los dispositivos disponibles en su entorno.

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.

 

 

Reclamo de discos

 

En la lista desplegable Group by:, seleccione Host.

Esta es una vista del almacenamiento desde la perspectiva del host.

Haga clic en Next.

 

 

Ready to complete

 

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).

Haga clic en Finish.

 

 

Actualización de la vista

 

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).

Los dispositivos flash que se usan como caché no se tienen en cuenta cuando se calcula la capacidad.

 

 

Verificación del estado del proveedor de almacenamiento

 

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.

Los proveedores de almacenamiento se registrarán automáticamente con Storage Management Service (SMS) de vCenter. Sin embargo, es mejor verificar que los proveedores de almacenamiento de uno de los hosts de ESXi estén registrados correctamente y activos, y que los otros proveedores de almacenamiento del resto de los hosts de ESXi en el clúster estén registrados y en modo de espera.

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.

Si el proveedor activo falla por algún motivo, uno de los proveedores de almacenamiento en espera tomará su lugar.

 

Lección 4: Deduplicación y compresión de VSAN


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.

Haga clic en Edit.

 

 

Habilitación de la deduplicación y compresión de VSAN

 

Verifique que la opción Add disks to storage esté configurada en Manual.

Cambie la opción Deduplication and compression a Enabled.

También tiene la opción Allow Reduced Redundancy.

La habilitación de la deduplicación y compresión requiere un cambio de formato en disco. VSAN evacuará el grupo de discos, lo eliminará y recreará un nuevo formato en disco que sea compatible con estas funciones nuevas.

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.

Haga clic en OK.

 

 

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.

 

 

Habilitación de la deduplicación y compresión de VSAN

 

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.

 

 

Habilitación de la deduplicación y compresión de VSAN

 

La deduplicación y compresión ahora están completamente habilitadas y se han eliminado y recreado todos los grupos de discos.

 

Lección 5: Escalabilidad horizontal de la capacidad del clúster de VSAN


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.

Seleccione el clúster llamado RegionA01-COMP01.

Haga clic en Summary.

La capacidad actual del datastore de VSAN es ~112 GB.

 

 

Verificación de la configuración del clúster de Virtual SAN

 

  1. Seleccione el clúster llamado RegionA01-COMP01.
  2. Seleccione la pestaña Manage.
  3. Seleccione el botón Settings.
  4. Seleccione General en la sección Virtual SAN.
  5. Verifique que la opción Add disks to storage esté configurada en Manual.

 

 

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."

Haga clic en OK.

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.

 

 

 

Configuración de la red

 

Hemos generado algunas alertas. Esto nos indica que debemos configurar la red de Virtual SAN correctamente.

 

 

Configuración de la red

 

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).

 

 

Configuración de la red

 

Marque la casilla para habilitar el servicio Virtual SAN traffic.

Haga clic en OK.

 

 

Configuración de la red

 

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 RegionA01-COMP01.

Seleccione Manage.

Seleccione Settings.

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

 

  1. Seleccione RegionA01-COMP01.
  2. Seleccione Manage.
  3. Seleccione Settings.
  4. Seleccione Virtual SAN ->Disk Management.
  5. 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.

Haga clic en OK.

 

 

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.

 

 

Capacidad de Virtual SAN

 

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.

 

Conclusión



 

Ha finalizado el módulo 1.

Felicitaciones por completar el módulo 1.

Continúe con cualquiera de los siguientes módulos que sea de su interés. [Add any custom/optional information for your lab manual.]

 

 

Funcionamiento de Module Switcher

 

 

 

Finalización del laboratorio

 

Para finalizar el laboratorio, haga clic en el botón END.  

 

Módulo 2: Capacidades de Virtual SAN basado solo en flash (30 minutos. Principiante)

Introducción


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).


Preparación del laboratorio


Para preparar el entorno, usaremos Module Switcher, la aplicación de PowerCLI.


 

Module Switchers

 

 

 

Module Switcher: laboratorio de VSAN de la A a la Z

 

  1. Haga doble clic en el atajo '1 VSAN A to Z HOL-SDC-1708-1'.

 

 

Inicio del módulo 2

 

  1. Haga clic en el botón Module 2 Start .

Esta rutina de inicio puede tardar 5 minutos en completarse. Agradecemos su paciencia.

 

 

Monitoreo del avance

 

Monitoree el avance hasta que se complete el proceso.

 

 

Finalización de la preparación del laboratorio

 

¡El laboratorio se preparó correctamente para el módulo 2!

  1. Haga clic en Close para detener la aplicación Module Switcher de manera segura.

 

Lección 1: Administración de políticas basadas en el almacenamiento: Raid 5 / 6


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.

 

 

Administración de políticas basadas en el almacenamiento: Raid 5 o 6 (Erasure Coding)

 

Seleccione Home -> Policies and Profiles -> VM Storage Policies.

Seleccione Create a New VM Storage policy.

 

 

Administración de políticas basadas en el almacenamiento: Raid 5 o 6 (Erasure Coding)

 

Cree una nueva política de almacenamiento de VM usando la siguiente información:

Name : FTT=1-Raid5

Haga clic en Next.

Haga clic en Next en la página de información Rule-Sets.

 

 

Administración de políticas basadas en el almacenamiento: Raid 5 o 6 (Erasure Coding)

 

Cree un nuevo conjunto de reglas usando la siguiente información:

Rules based on data services : VSAN
		Rule 1 : Number of failures to tolerate = 1
		Rule 2 : Failure tolerance method = Raid-5/6 (Erasure Coding)-Capacity

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.

Haga clic en Next.

 

 

Administración de políticas basadas en el almacenamiento

 

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.

Haga clic en Next.

 

 

Administración de políticas basadas en el almacenamiento: Raid 5 o 6 (Erasure Coding)

 

Revise la configuración de la política de almacenamiento de VM.

Haga clic en Finish.

 

 

 

Administración de políticas basadas en el almacenamiento: Raid 5 o 6 (Erasure Coding)

 

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.

 

 

Clonación de una VM al datastore de VSAN: Raid 5 o 6 (Erasure Coding)

 

Asigne a la máquina virtual el siguiente nombre: FTT=1-Raid5.

Haga clic en Next.

 

 

Clonación de una VM al datastore de VSAN: Raid 5 o 6 (Erasure Coding)

 

En Select a compute resource, seleccione RegionA01-COMP01.

Haga clic en Next.

 

 

Clonación de una VM al datastore de VSAN: Raid 5 o 6 (Erasure Coding)

 

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.

Haga clic en Next, en la opción Select clone options.

 

 

Clonación de una VM al datastore de VSAN: Raid 5 o 6 (Erasure Coding)

 

Haga clic en Finish.

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.

 

 

Capacidad de Virtual SAN: Raid 5 o 6 (Erasure Coding)

 

 

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.

Seleccione RegionA01-COMP01 -> Monitor -> Virtual SAN -> Capacity.

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.

 

 

Capacidad de Virtual SAN: Raid 5 o 6 (Erasure Coding)

 

Seleccione RegionA01-COMP01 -> Monitor -> Virtual SAN -> Capacity.

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.

 

 

 

Implementación de Raid 6: políticas de disco

 

 

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.

 

 

Lección 2: Nuevo VM Swap Object disperso



 

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).

 

 

Nuevo VM Swap Object disperso

 

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.

Seleccione RegionA01-COMP01 -> Monitor -> Virtual SAN -> Capacity.

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.

 

 

Nuevo VM Swap Object disperso

 

Ahora regrese a la vista de Capacity.

Seleccione RegionA01-COMP01 -> Monitor -> Virtual SAN -> Capacity.

Según lo previsto, no hay objetos de intercambio de la VM que consuman espacio en el datastore de VSAN.

 

 

 

Nuevo objeto de intercambio de la VM dispersa

 

Seleccione la máquina virtual llamada FTT=1-Raid5.

Seleccione Summary.

Tome nota de los hosts de ESXi con los que está registrada la VM.

 

 

Nuevo VM Swap Object disperso

 

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:

esxcfg-advcfg -g /VSAN/SwapThickProvisionDisabled

Para habilitarla:

esxcfg-advcfg -s 1 /VSAN/SwapThickProvisionDisabled

 

 

 

Encendido de la VM

 

 

 

Nuevo objeto de intercambio de la VM dispersa

 

Encienda de nuevo la VM llamada FTT=1-Raid5 .

Regrese a la pantalla de vista de Capacity.

Seleccione RegionA01-COMP01 -> Monitor -> Virtual SAN -> 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).

 

 

Conclusión


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.


 

Ha finalizado el módulo 2.

Felicitaciones por completar el módulo 2.

Continúe con cualquiera de los siguientes módulos que sea de su interés.

 

 

Finalización del laboratorio

 

Para finalizar el laboratorio, haga clic en el botón END.  

 

Módulo 3: Disponibilidad y continuidad del negocio (30 minutos. Avanzado)

Introducción


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)

Requisitos de red desde sitio activo-activo (dominios de fallas de datos) a sitio testigo


Preparación del laboratorio


Para preparar el entorno, usaremos Module Switcher, la aplicación de PowerCLI.


 

Module Switchers

 

 

 

Module Switcher: laboratorio de VSAN de la A a la Z

 

  1. Haga doble clic en el atajo '1 HOL-1708-SDC-1 - VSAN A to Z'.

 

 

Inicio del módulo 3

 

  1. Haga clic en el botón Module 3 Start .

 

 

Monitoreo del avance

 

Monitoree el avance hasta que se complete el proceso.

 

 

Finalización de la preparación del laboratorio

 

¡El laboratorio se preparó correctamente para el módulo 3!

  1. Haga clic en Close para detener la aplicación Module Switcher de manera segura.

 

Lección 1: Clúster extendido de Virtual SAN


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:

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.

 

 

Configuración del clúster extendido de Virtual SAN

 

Seleccione el host de ESXi llamado esx-07a.corp.local.

Seleccione Manage.

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.

 

 

Configuración del clúster extendido de Virtual SAN

 

Seleccione el clúster llamado RegionA01-COMP01.

Seleccione Manage -> Settings -> Virtual SAN -> Fault Domains & Stretched Cluster.

Verá que el estado de Stretched Cluster en este momento es Disabled.

Haga clic en  Configure.

 

 

Configuración del clúster extendido de Virtual SAN

 

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.

Haga clic en Next.

 

 

Configuración del clúster extendido de Virtual SAN

 

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.

Haga clic en Next.

 

 

Configuración del clúster extendido de Virtual SAN

 

Seleccione los discos de 10 GB para el nivel Cache.

Seleccione el disco de 15 GB para el nivel Capacity.

Haga clic en Next.

 

 

Configuración del clúster extendido de Virtual SAN

 

Revise la configuración y haga clic en Finish.

 

 

 

Configuración del clúster extendido de Virtual SAN

 

Revise el panel Recent Tasks.

 

 

Configuración del clúster extendido de Virtual SAN

 

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 RegionA01-COMP01.

Seleccione Monitor.

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í.

 

 

Resolución de problemas de la política de almacenamiento de VM

 

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.

 

 

Resolución de problemas de la política de almacenamiento de VM

 

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.

 

 

Resolución de problemas de la política de almacenamiento de VM

 

Seleccione Manage -> Policies -> Edit VM Storage Policies.

 

 

Resolución de problemas de la política de almacenamiento de VM

 

Para la política de almacenamiento de VM, seleccione Virtual SAN Default Storage Policy.

Haga clic en Apply to all.

Haga clic en OK.

 

 

Resolución de problemas de la política de almacenamiento de VM

 

Por lo tanto, el estado en Compliance Status sigue siendo Noncompliant.

Investiguemos un poco más...

 

 

Resolución de problemas de la política de almacenamiento de VM

 

Seleccione RegionA01-COMP01.

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.

 

 

Resolución de problemas de la política de almacenamiento de VM

 

Una vez que se completó la resincronización, regrese a la pantalla Monitor -> Policies.

Seleccione la máquina virtual llamada FTT-1-Raid5.

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.

 

 

Resolución de problemas de la política de almacenamiento de VM

 

Seleccione RegionA01-COMP01.

Seleccione Monitor.

Seleccione Virtual SAN .

Seleccione Health.

La sección Data de la comprobación del estado de VSAN ahora pasó todas las pruebas.

 

Lección 2: Virtual SAN con vSphere HA y DRS



 

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.

 

 

Apagado de la VM

 

Tenemos disponible nuestra primera VM. Por ahora, la apagaremos y la usaremos más adelante en esta lección.

  1. Haga clic con el botón secundario del mouse en VM-Primary.
  2. Seleccione Power > Power Off.
  3. 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.

 

 

Clonación de una VM a un sitio secundario

 

Asigne un nombre a la máquina virtual. La llamaremos VM-Secondary. Esta VM residirá en el sitio secundario.

VM Name : VM-Secondary

Haga clic en Next.

 

 

Clonación de una VM a un sitio secundario

 

Seleccione el clúster RegionA01-COMP01. Aquí es donde ubicamos la VM por primera vez.

Haga clic en Next.

 

 

Clonación de una VM a un sitio secundario

 

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:

VM Storage Policy : Virtual SAN Default Storage Policy

Haga clic en Next.

 

 

Clonación de una VM a un sitio secundario

 

Haga clic en Next en Select Clone options.

 

 

Clonación de una VM a un sitio secundario

 

Revise la configuración y haga clic en Finish.

 

 

Configuración de vSphere HA y DRS para el clúster extendido de VSAN

 

Ahora, tenemos implementadas dos máquinas virtuales en nuestro entorno.

 

 

Configuración de vSphere DRS

 

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 Manage.

Seleccione Settings.

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 el clúster llamado RegionA01-COMP01.

Seleccione Manage.

Seleccione Settings.

Seleccione VM/Host Groups.

Haga clic en Add.

 

 

Sección 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.

Haga clic en OK.

 

 

 

Sección VM/Host Groups

 

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.

 

 

Sección VM/Host Groups

 

Asigne al grupo de hosts o VM el nombre Secondary.

En Type, seleccione Host Group.

Agregue los dos hosts de ESXi llamados esx-03a.corp.local y esx-04a.corp.local al grupo de hosts o VM.

Haga clic en OK.

 

 

Sección VM/Host Groups

 

Seleccione Secondary.

En Secondary Host Group, se encuentran los hosts de ESXi llamados esx-03a.corp.local y esx-04a.corp.local.

Haga clic en Add para crear otro grupo de hosts o VM.

 

 

Sección VM/Host Groups

 

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.

Haga clic en OK.

 

 

Sección VM/Host Groups

 

Seleccione Primary-VM.

En Primary-VM VM Group, se encuentra la VM llamada VM-Primary.

Haga clic en Add para crear otro grupo de hosts o VM.

 

 

Sección VM/Host Groups

 

Asigne al grupo de hosts o VM el nombre Secondary-VM.

En Type, seleccione VMGroup.

Agregue la VM llamada VM-Secondary al grupo de VM.

Haga clic en OK.

 

 

Sección VM/Host Groups

 

Seleccione Secondary-VM.

En Secondary-VM VM Group se encuentra la VM llamada VM-Secondary.

 

 

 

Sección VM-Host Rules

 

Seleccione el clúster llamado RegionA01-COMP01.

Seleccione Manage.

Seleccione Settings.

Seleccione VM/Host Rules.

Haga clic en Add en VM/Host Rules.

 

 

Sección 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.

Haga clic en OK.

 

 

Sección VM-Host Rules

 

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.

Haga clic en Add en VM/Host Rules.

 

 

Sección VM-Host Rules

 

Asigne a VM/Host Rule el nombre SecondaryVMHosts.

En Type, seleccione Virtual Machines to Hosts.

En VM Group, seleccione Secondary-VM y Should run on hosts in group.

En Host Group, seleccione Secondary.

Haga clic en OK.

 

 

Sección VM-Host Rules

 

Está creada nuestra segunda 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.

 

 

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 el clúster RegionA01-COMP01 .

Seleccione Manage.

Seleccione Settings.

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".

 

 

Habilitación de HA en un clúster extendido de VSAN

 

Seleccione Turn On vSphere HA.

Expanda Failure conditions and VM response.

 

 

Habilitación de HA en un clúster extendido de VSAN

 

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.

 

 

Habilitación de HA en un clúster extendido de VSAN

 

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.

 

 

Habilitación de HA en un clúster extendido de VSAN

 

Seleccione Use datastores only from the specified list.

Expanda la opción Advanced Options.

 

 

Habilitación de HA en un clúster extendido de VSAN

 

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.

 

 

Habilitación de HA en un clúster extendido de VSAN

 

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.

Para solucionar este problema, haga lo siguiente:

  1. Navegue hasta Cluster -> RegionA01-COMP01.
  2. Haga clic en la pestaña Summary.
  3. 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.

 

 

Verificación del estado del host de vSphere HA

 

  1. 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).
  2. Haga clic en la pestaña Summary para confirmar que el problema es el siguiente: "vSphere HA agent for this host has an error".

 

 

Verificación del estado del host de vSphere HA

 

  1. Haga clic con el botón secundario del mouse en el host.
  2. Haga clic en "Reconfigure for vSphere HA".

 

 

Verificación del estado del host de 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 Monitor.

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.

 

 

Escenario de fallas: reinicio de un solo host

 

Seleccione OK para reiniciar el host de ESXi.

 

 

Componentes ausentes

 

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.

Seleccione Monitor.

Seleccione Policies.

Seleccione Hard disk 1.

Seleccione Physical Disk Placement.

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.

 

 

Comprobación del estado de VSAN

 

Seleccione RegionA01-COMP01.

Seleccione Monitor.

Seleccione Virtual SAN .

Seleccione Health.

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 RegionA01-COMP01.

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.

 

 

Escenario de falla: pérdida del sitio

 

Seleccione All Hosts y haga clic en OK.

 

 

Componentes ausentes

 

Espere unos minutos mientras se reinician los hosts de ESXi (no responden) y hasta que pueda acceder de nuevo a la VM VM-Primary.

Seleccione la VM llamada VM-Primary.

Seleccione Monitor.

Seleccione Policies.

Seleccione Hard disk 1.

Seleccione Physical Disk Placement.

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.

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 un host (esx-04a.corp.local) en el dominio de fallas Secondary de VSAN.

 

 

 

Hosts de ESXi completamente encendidos

 

Espere a que se enciendan completamente los hosts de ESXi y vuelva a conectarse a vCenter Server.

 

 

DRS: automatización parcial

 

Seleccione RegionA01-COMP01.

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

 

Seleccione la VM llamada VM-Primary.

Seleccione Summary.

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.

 

 

Comprobación del estado de VSAN

 

Seleccione RegionA01-COMP01.

Seleccione Monitor.

Seleccione Virtual SAN .

Seleccione Health.

Vuelva a ejecutar la Comprobación del estado . El estado de las pruebas ahora debería ser Passed.

 

Conclusión



 

Ha finalizado el módulo 3.

Felicitaciones por completar el módulo 3.

Continúe con cualquiera de los siguientes módulos que sea de su interés. [Add any custom/optional information for your lab manual.]

 

 

Finalización del laboratorio

 

Para finalizar el laboratorio, haga clic en el botón END.  

 

Módulo 4: Monitoreo y resolución de problemas (30 minutos. Principiante)

Introducción


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.

 


Preparación del laboratorio


Para preparar el entorno, usaremos Module Switcher, la aplicación de PowerCLI.


 

Module Switchers

 

 

 

Module Switcher: laboratorio de VSAN de la A a la Z

 

  1. Haga doble clic en el atajo '1 HOL-1708-SDC-1 - VSAN A to Z'.

 

 

Inicio del módulo 4

 

  1. Haga clic en el botón Module 4 Start.

 

 

Monitoreo del avance

 

Monitoree el avance hasta que se complete el proceso.

 

 

Finalización de la preparación del laboratorio

 

¡El laboratorio se preparó correctamente para el módulo 4!

  1. Haga clic en Close para detener la aplicación Module Switcher de manera segura.

 

Lección 1: Comprobación del estado de VSAN



 

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:

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 RegionA01-COMP01.

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.

Seleccione RegionA01-COMP01.

Seleccione Monitor -> Virtual SAN -> Health.

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.

 

 

Estado de la HCL 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.

Seleccione RegionA01-COMP01.

Seleccione Monitor -> Virtual SAN -> Health.

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.

 

 

Actualización de la base de datos de la HCL

 

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".

 

 

 

Estado del clúster

 

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.

Seleccione RegionA01-COMP01.

Seleccione Monitor -> Virtual SAN -> Health.

Expanda Cluster.

 

 

 

Estado de la red

 

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).

Seleccione RegionA01-COMP01.

Seleccione Monitor -> Virtual SAN -> Health.

Expanda Network.

 

 

Estado de los datos

 

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.

Seleccione RegionA01-COMP01.

Seleccione Monitor -> Virtual SAN -> Health.

Expanda Data.

 

 

Estado de los límites

 

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.

Seleccione RegionA01-COMP01.

Seleccione Monitor -> Virtual SAN -> Health.

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.

Seleccione RegionA01-COMP01.

Seleccione Monitor -> Virtual SAN -> Health.

Expanda Physical Disk.

 

Lección 2: Tablas de rendimiento


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 RegionA01-COMP01.

Seleccione Manage -> Settings -> Health and Performance.

Para habilitar Performance service, haga clic en Edit.

 

 

Habilitación de Performance service

 

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.

Haga clic en OK.

 

 

Habilitación de Performance service

 

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.

 

 

Clúster: Virtual SAN - Virtual Machine Consumption

 

 

 

Clúster: Virtual SAN - Backend

 

 

Lección 3: ESXCLI


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

 

 

 

ESXCLI VSAN

 

 

 

ESXCLI VSAN DATASTORE

 

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.

Ejecute el siguiente comando:

esxcli vsan datastore name get

 

 

esxcli vsan network

 

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.

Ejecute el siguiente comando:

esxcli vsan network list

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.

 

 

 

 

esxcli vsan storage

 

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).

 

 

 

esxcli vsan cluster

 

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.

Ejecute el siguiente comando:

esxcli vsan cluster get

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.

Ejecute el siguiente comando:

esxcli system uuid get 

De esta manera, sabrá el UUID del nodo en el que ya inició sesión.

 

 

esxcli vsan faultdomain

 

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.

Ejecute el siguiente comando:

esxcli vsan faultdomain get

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).

 

 

 

esxcli vsan policy

 

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.

Ejecute el siguiente comando:

esxcli vsan policy getdefault

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

 

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.

Ejecute el siguiente comando:

esxcli vsan trace set -h

 

 

vdq (1)

 

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.

Ejecute el siguiente comando:

vdq -q

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).

 

 

 

vdq (2)

 

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.

Ejecute el siguiente comando:

vdq -i -H

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.

 

Conclusión



 

Ha finalizado el módulo 4.

Felicitaciones por completar el módulo 4.

Continúe con cualquiera de los siguientes módulos que sea de su interés. [Add any custom/optional information for your lab manual.]

 

 

Funcionamiento de Module Switcher

 

 

 

Finalización del laboratorio

 

Para finalizar el laboratorio, haga clic en el botón END.  

 

Módulo 5: Automatización de Virtual SAN (30 minutos. Avanzado)

Introducción


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:

  1. PowerCLI
  2. ESXCLI
  3. Ruby vSphere Console (RVC)

Preparación del laboratorio


Para preparar el entorno, usaremos Module Switcher, la aplicación de PowerCLI.


 

Module Switchers

 

 

 

Module Switcher: laboratorio de VSAN de la A a la Z

 

  1. Haga doble clic en el atajo 1 HOL-1708-SDC-1 - VSAN A to Z'.

 

 

Inicio del módulo 5

 

  1. Haga clic en el botón Module 5 Start .

 

 

Monitoreo del avance

 

Monitoree el avance hasta que se complete el proceso.

 

 

Finalización de la preparación del laboratorio

 

¡El laboratorio se preparó correctamente para el módulo 5!

  1. Haga clic en Close para detener la aplicación Module Switcher de manera segura.

 

Lección 1: PowerCLI/ESXCLI



 

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.  

Connect-VIServer -Server vcsa-01a.corp.local -User administrator@corp.local -Password VMware1!

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.

$vmhost = "esx-01a.corp.local"
$vmhost

 

 

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:

Get-Cluster | Select Name, VsanEnabled, VsanDiskClaimMode | Format-List

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:

Get-VDSwitch -VMHost $vmhost

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):

Get-VDSwitch -VMHost $vmhost | Get-VDPortgroup

Verifique si Virtual SAN Traffic está habilitado en los puertos de VMkernel dedicados a Virtual SAN:

Get-VMHostNetworkAdapter -VMhost $vmhost | select PortGroupName, name, VsanTrafficEnabled | Format-Table -autosize

 

 

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.

$dg = Get-VsanDiskGroup -VMHost $vmhost

Analice el contenido de la variable creada recientemente.

$dg

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'):

$dg | Get-VsanDisk

 

 

 

Políticas de almacenamiento de VSAN

 

Analice las políticas de almacenamiento de Virtual SAN disponibles en nuestro entorno:

Get-SpbmStoragePolicy -requirement -namespace "VSAN" | Select Name, Description

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:

$vm = "Photon-Temp"
$vsanDatastore = "RegionA01-VSAN-COMP01"

Encienda la máquina virtual:

Start-VM -VM $vm

Realice la migración de la máquina virtual al clúster y al datastore de VSAN (esto tardará algunos minutos):

Get-VM -Name $VM | Move-VM -Destination $VMhost -Datastore $vsanDatastore

 

 

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":

$vm

Cree una nueva variable con la que se capturen los discos duros para la VM Photon-Temp:

$vmHdd = Get-HardDisk $vm

Verifique la política de almacenamiento actual aplicada a la máquina virtual Photon y a los discos duros virtuales:

Get-SpbmEntityConfiguration $vm, $vmHdd

 

 

 

Creación de una nueva política

 

Cree la nueva política de almacenamiento (usando Stripe-Width=2):

New-SpbmStoragePolicy -Name Stripe-Width=2 -RuleSet (New-SpbmRuleSet -Name "Stripe-Width=2" -AllOfRules @((New-SpbmRule -Capability VSAN.stripeWidth 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:

Get-SpbmStoragePolicy -requirement -namespace "VSAN" | Select Name, Description

 

 

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:

Set-SpbmEntityConfiguration $vm, $vmHdd -StoragePolicy "Stripe-Width=2" -ErrorAction SilentlyContinue

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:

Get-SpbmEntityConfiguration $vm, $vmHdd -CheckComplianceNow  

 

 

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:

$esxcli = Get-EsxCli -VMhost $vmhost -V2

Introduzca la nueva variable y presione Intro o Return para ver todos los espacios de nombres disponibles:

$esxcli

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.

$esxcli.vsan

 

 

 

Métodos expuestos: clúster

 

Analice de manera más detallada. Para esto, examine el elemento "cluster":

$esxcli.vsan.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:

$esxcli.vsan.cluster.get.Invoke()

 

 

Métodos expuestos: red

 

Analice la configuración de la red:

$esxcli.vsan.network.list.Invoke()

 

 

Métodos expuestos: datastore

 

Recupere el nombre del datastore de Virtual SAN:

$esxcli.vsan.datastore.name.get.Invoke()

De este modo, se concluye la lección sobre PowerCLI y ESXCLI.  

 

Lección 2: Ruby vSphere Console (RVC)


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.


 

Funciones

RVC tiene muchas de las capacidades que se pueden esperar de una interfaz de línea de comando moderna.

 

 

Ventajas

 

 

Uso (1)

 

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.

  1. Inicie Putty mediante el atajo en la barra de herramientas.
  2. Desplácese hacia abajo y haga doble clic en vcsa-01a.corp.local.

 

 

 

Utilización (2)

 

Inicie RVC mediante el siguiente comando:

rvc localhost 

Ingrese 'Y' si aparece "Are you sure you want to continue connecting?"

Cuando se le indique, ingrese la contraseña:  VMware1!

 

 

Navegación

 

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":

cd 1  (localhost)

Vea una lista de los centros de datos que se encuentran disponibles mediante el comando "ls":

ls

Cambie al directorio del centro de datos y vea una lista de los recursos que se encuentran disponibles:

cd 0  (RegionA01)
ls

Cambie al directorio de computadoras y enumere los clústeres de vSphere y los hosts independientes de vSphere que se encuentran disponibles:

cd 1  (computers)
ls

Cambie al directorio de clústeres de vSphere y enumere los hosts y los depósitos de recursos en este clúster:

cd 1  (RegionA01-COMP01)
ls

Cambie al directorio de hosts y enumere los hosts individuales de vSphere en este clúster, junto con los detalles de CPU y memoria:

cd 0  (Hosts)
ls

 

 

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:

vsan.host_info 1

 

 

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:

cd ..
cd ..
ls
vsan.disks_stats 1

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.

 

 

Resumen

 

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):

help vsan

Para ver todos los espacios de nombres disponibles para administrar mediante Ruby vSphere Console, simplemente use este comando:

help

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.

 

Conclusión


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.


 

Ha finalizado el módulo 5.

Felicitaciones por completar el módulo 5.

Si desea obtener más información sobre la automatización de VSAN, pruebe una de estas opciones:

PowerCLI

ESXCLI

Ruby vSphere Console (RVC):

Continúe con cualquiera de estos módulos debajo si todavía no los completó o si desea visitarlos de nuevo.

 

 

Funcionamiento de Module Switcher

 

 

 

Finalización del laboratorio

 

Para finalizar el laboratorio, haga clic en el botón END.  

 

Conclusion

Thank you for participating in the VMware Hands-on Labs. Be sure to visit http://hol.vmware.com/ to continue your lab experience online.

Lab SKU: HOL-1708-SDC-1-ES

Version: 20161012-073958