Actualizar a vROps 8.0 con vRSLCM

Aunque éste puede considerarse un post independiente, realmente es continuación del anterior donde actualizaba vRealize Suite Life Cycle Manager 2.1 a 8.0. Paso obligatorio para poder actualizar vROps 7.5 a 8.0 con este producto. Si queréis realizar la instalación desde la VAMI tendréis que hacerlo desde la version 6.6.1 o superior usando el mismo .PAK que menciono mas adelante previos Snapshots del entorno, por supuesto.

Mi vROps 7.5 está formado por un cluster con dos nodos; Master y Master Réplica. Como podéis observar tengo activado SSH ya que de experiencias anteriores cualquier proceso de upgrade con vRSLCM necesitará acceso por SSH.

En primer lugar, recordar que ya tengo importado el entorno actual de vROps 7.5, por lo que solo tengo que pulsar en View Details.

Seguidamente debo descargar el paquete de actualización de vROps y añadirlo al repositorio. Yo habitualmente, utilizo el repositorio local, usando un cliente SFTP me conecto a vRSLCM creo una carpeta y dentro copio los ficheros de actualización. Para vROps me descargo el siguiente fichero:

Para posteriormente añadirlo al repositorio desde aqui, es un proceso que ya describo en otro post.

Una vez añadido, procedemos de nuevo a entrar en nuestro entorno dónde una vez hecho click en los tres puntos seleccionaremos la opción Snapshots para poder revertir los dos nodos a su estado operativo anterior en caso de que algo falle.

Una vez terminados los Snapshots, dentro de las propiendas seleccionamos la opción Upgrade. Observamos 4 pasos en la barra superior, comenzamos con la confirmación de la version y validación del bundle de actualizacion. Next.

Entramos en la sección de validación de nuestro entorno, es la propia herramienta Pre-Upgrade Assessment Tool, aquí denominada APUAT. Pulsamos Run Assesment.

Tras la ejecución, podemos comprobar el informe con los resultados pulsando View Report.

Este sería el aspecto del informe. En mi caso no hay mucho que verificar ya que apenas tenia contenido out-of-the-box.

Damos el visto bueno a nuestra validación marcando la casilla de verificación y pulsando Next.

Observamos el resultado del pre-check y procedemos con la siguiente fase.

Aquí podrían existir Warnings por motivos de capacidad, servicios o configuración. Tenemos luz verdad para finalmente lanzar el proceso con Sumbit.

Podemos ir a las opciones de tareas para seguir la monitorización del proceso.

Una vez completado satisfactoriamente, solo queda entrar a nuestro entorno.

Verificar la correcta actualización de versiones y proceder a revisar el contenido.

Algunas de las novedades (Que son muchas) a destacar un poco serían las siguientes:

El concepto de Cloud Account. vRealize Automation y vRealize Operations llegan en esta versión 8 mucho más interrelacionados. Una Cloud Account en vROps es exactamente lo mismo que en vRA. De forma sencilla podríamos decir que gestiona de manera diferente las Soluciones agrupando Adaptadores de forma más intuitiva. Una Cloud Account contiene información sobre nuestro vCenter, AWS, o Azure accounts. No Recordar que, por ejemplo, VMware Cloud en AWS es simplemente otro vCenter a los ojos de vRealize Operations.

Por ejemplo, si seleccionamos crear un nuevo Cloud Account para vCenter, observamos la que la primera pestaña refleja los valores necesarios para configurar la recolección, que la recolección de vSAN ya está incluida en la segunda pestaña y en una tercera nos encontramos la mayoría de las cuentas necesarias para la recolección a nivel de OS.

Para nuevos despliegues será una experiencia de Onboarding mucho más agradable con unos procesos guiados muy detallados como muestra la pantalla inferior.

Observamos que el repositorio se mantiene en su sitio observando los packs que están activos.

Y cuales de los activos ya están asociados a alguna Cloud Account.

Retomando las mejoras existentes en esta versión, destacar los análisis What-If con la inclusión de dos nuevos escenarios. Algo en lo que merece la pena dedicar bastante tiempo si tenemos ocasión mas adelante, sobre todo porque ahora podremos contar con parámetros de vSAN a la hora de afinar en el coste del crecimiento.

Otra nueva funcionalidad es la Intelligent Remediation, principalmente centrada en un nuevo Dashboard denominado Troubleshooting Workbench.

Desde aquí se pueden identificar métricas anómalas y potenciales riesgos de cualquier objeto de cualquier management pack. Promete ser interesante.

Discover Services viene de forma nativa con soporte para mas de 40 aplicativos sin necesidad de agentes, simplemente las VMware Tools.

Y mucho más, ahora a ponerse las pilas para sacar partido a toda la suite.

Hasta pronto.

Instalar vRealize Suite Life Cycle Manager 8

Tras hacerse pública la release de vRealize Suite 8 ya tocaba tener alguna toma de contacto más cercana. Concretamente una actualización de mi versión actual a 8.0. Por motivos de capacidad y recursos me voy a limitar solamente al vROps  ya que vRA es, sencillamente todo un nuevo universo que hoy por hoy requiere más tiempo.

Lo primero que tenemos que hacer es, por supuesto, comprobar la  VMware Product Interoperability Matrix y si observamos en la Release Note, hay algunas cosas a tener en cuenta:

  • Lógicamente, siempre exportar todo lo exportable, es decir Dashboards, Supermétricas, Custom Groups, Reports, etc.
  • Indicar que la versión 8 deshabilita TLS 10 y TLS1.1 dejando solo el TLS 1.2 soportado por defecto, tal como hace vSphere 6.7 U2 también.

A menos que nuestro vROps actual sea la version 6.7 o superior, un vistazo detallado a éste KB nos muestra cómo debemos usar la vRealize Operations Upgrade Assessment Tool para poder comprobar que métricas, properties, dashboards, etc han sido discontinuados y poder obrar en consecuencia. Aquí un extracto muy importante:

Upgrading to vRealize Operations Manager 8.0, resets out-of-the-box content as part of the software upgrade process even if the Reset Default Content button is unchecked during the upgrade. This implies that the user modifications made to default content such as alert definitions, symptom definitions, recommendations, policies, views, dashboards, widgets, and reports are overwritten. You need to clone or backup the content before you upgrade to vRealize Operations Manager 8.0.

Si partimos de una 6.7 o superior, como es mi caso, el procedimiento lo voy a delegar en el Life Cycle Manager. Pero cuidado, mi vRSLCM es la 2.1 que aun después de subirlo a la ultima versión solamente me sube a la 7.5, que es la que tengo.

Por mi perfecto, es momento ideal para subirlo también a la version 8 de la que he leído maravillas.

De modo que, éste va a ser un primer post exclusivo de migracion de vRSLCM 1.2 a vRSLCM 8 y existirá otro post adicional con la Migración de vROps 7.5 a 8.0. Comenzamos.

Descargamos la ISO de nuestro vRealize Suite Life Cycle Manager 8.0

Atención al tamaño de la criatura, porque dentro de esa ISO se encuentran dos appliances adicionales, vRealize Automation y VMware Identity Manager (Si, ha vuelto)


Montamos la ISO y ejecutamos el Instalador de nuestro vRSLCM. Que emoción 🙂

Pantalla principal. Nosotros vamos a Migrar. Pulsamos Migrate.



Aqui observamos algo nuevo, además de migrar desde vRSLCM 1.3 o superior, en esta version 8 a la que llevaremos nuestra suite de vRealize vuelve a ser necesario el VMware Identity Manager, por tanto, reservad unos pocos recuros y otra IP adicionales. Pulsamos Next.



Aceptamos EULA como animal de compañía. Next.

Indicamos datos de nuestro vCenter donde desplegar. Next.

Aceptamos Certificado. Accept.

Ahora el DataCenter o Contenedor donde Instalarlo. Next.



El Cluster. No os molestéis en expandirlo buscando un host, va al cluster. Next.

Momento de elegir Datastore. Si quieres un host, elige un datastore local. Next.

Configuración de red.

Password para vRSLCM y vIDM.

Momento para definir el nombre de nuestro futuro y flamante vRSLCM.

Este apartado es el que indica los datos de nuestro actual vRLCM, credenciales y nombre para poder acceder a él durante la migración. Next.

Momento para el vIDM. Tenemos posibilidad de importar contenido de uno existente o crearlo nuevo. En mi caso, lo creo nuevo.

Resumen del pedido. Ahora a Submit.

Comienza el proceso de despliegue… que tensión.

Me preocupaba el tamaño por defecto del vIDM, tampoco es demasiado grande.

Y finalmente, termina el proceso.

Muy bien. Que tenemos ahora?. Pues tenemos ambos LCM operativos, una URL para poder acceder a nuestra flamante versión 8.0 y otra URL que nos lleva directamente al job de migración de datos que está corriendo en este momento. Yo quiero verlo desde el principio y hago click en el primer link.


Ohhhhhhhhhhhh…….

Interesante, esto es nuevo y mas simplificado. Entrar por primera vez al LCM 2.x era algo desconcertante. Que es eso del Locker?. Pues es la zona donde gestionar certificados, generar CSR, etc.

Bueno, de momento voy a Lifecycle Operations porque quiero ver si me ha importado mi entorno correctamente.

Impresionante Dashboard donde observo que todo ha ido bien y lo confirmo revisando del job de importación.


Mas o menos mismo aspecto aunque esta vez es sinuoso. Ahora voy a consultar si ha importado el Environment de vROps 7.5 que tenía definido en la versión anterior.

Perfecto. Ahi lo tengo listo para realizar el Upgrade.

Todo el proceso ha ido bien, aunque no penséis que ha sido a la primera, realmente lo hice dos veces ya que la tarea de migración de datos me dio problemas inicialmente. 🙂 Sabéis cual fue el problema?. El acceso SSH en el vLCM de legacy. Aseguraos que está habilitado y las credenciales son correctas.

Os dejo un enlace completo donde conocer las novedades de ésta nueva versión.

Nos vemos en el próximo post: Actualizando a vRealize Operations Manager 8.0

Matemáticas y vSAN Stretched Cluster

En varias ocasiones ha surgido una pregunta acerca de las limitaciones que tendría un vSAN Stretched Cluster. Cuántas máquinas virtuales es capaz de soportar?. Sabía que no era una pregunta con una simple respuesta, de hecho convergen limitaciones a nivel de Host, vCenter, número de componentes, etc. Desde ésta perspectiva, me di cuenta de que había que realizar un poco de investigación y revisar documentación para tratar de tener clara una respuesta. Lo que inicialmente me imaginé como una tabla de valores, ha resultado ser un post bastante más extenso con en el que espero poder contemplar todos los factores a tener en cuenta y del que espero también comentarios por vuestra parte, incluso correcciones, porque no pretendo más que plasmar lo que considero puede ser de mucha utilidad ya que no he encontrado esta información junta en ningún sitio.

Algo que tenemos todos muy claro es la documentación oficial, en dónde podemos localizar los Maximums por producto. En www.configmax.vmware.com destacaría las siguientes limitaciones para vSphere 6.7:

  • Máximo número de Componentes por Host (CxHost) = 9000
  • Máximo número de Hosts por Cluster (HxCluster) = 30 (15+15+1)
  • Máximo número de VMs por Host (VMxH) = 200  (Si señor, ESXi 6.7 soporta hasta 1024 VMs por host, pero un vSAN Host no)

Recordemos aqui, que vSAN es un almacenamiento basado en objetos, que éstos a su vez tienen sus propios componentes que son los que realmente se reparten entre los nodos que forman el vSAN Cluster. Bien, dicho esto, ahora vamos a descomponer una Máquina Virtual en sus respectivos componentes dentro de vSAN. Vamos a considerar los siguientes escenarios en base a la política de almacenamiento existente (SBP):

RAID-1 / FTT=1 (3 Hosts)

  • 3 Componentes para SWAP (Replica+Replica+Witness)
  • 3 Componentes para HOME (Replica+Replica+Witness)
  • 3 Componentes por cada VMDK de hasta 255 GB (Replica+Replica+Witness)
  • Más 3 Componentes adicionales si la VM tiene algún Snapshot.

RAID-5 / FTT=1 (4 Hosts)

  • 4 Componentes para SWAP (Replica+Replica+Replica+Parity)
  • 4 Componentes para HOME Replica+Replica+Replica+Parity)
  • 4 Componentes para cada VMDK de hasta 255 GB (Replica+Replica+Replica+Parity)
  • Adicionalmente 4 Components más si la VM tiene algún Snapshot

Con esas premisas, podremos estimar que una VM Tipo de 1 solo disco de 1 TB, sin Snapshots estará usando:

  • 18 Componentes (3 + 3 + 12) en RAID-1 FTT=1.
  • 24 Componentes (4 + 4 + 16) en RAID-5 FTT=1.

Y ahora replanteemos la pregunta que nos ha traido hasta aquí. Cuántas máquinas de éste tipo es capaz de manejar un vSAN Cluster?.

El factor más restrictivo aqui es la cantidad de componentes vSAN que un Host es capaz de almacenar (CxHost) además de la cantidad de VMs por Host (VMxH). Dicho ésto, hagamos los números:

(CxHost * NumberOfHosts) / VMComponents (9000 * 3) / 18 = 1500 VMs para RAID-1

(CxHost * NumberOfHosts) / VMComponents (9000 * 4) / 24 = 1500 VMs para RAID-5

Bastante curioso el resultado. No nos engañemos, en primer lugar que salga lo mismo en ambos escenarios no quiere decir que sea la misma infraestructura. La lógica y distribución de los datos es diferente y aunque se pase por la cabeza ahorrarse un host para tener el mismo numero de máquinas en el primer caso, eso implica que estás usando el doble de espacio mientras que con RAID-5 solo usarás el 33% .

Por otro lado, no nos podemos olvidar de la limitación de VMxH. Aunque tengamos margen con los componentes, no es así con la limitación de 200 VM por vSAN Host. En este caso para tener 1500 VMs necesitaríamos un mínimo de 8 nodos (1500/200=7,5). Lo que me lleva a plantearos la siguiente pregunta: ¿Que sucedería en nuestro vSAN Cluster de 8 nodos y 1500 VMs si un Host muere con un PSOD?. Obviamente tendríamos problemas. Puntualizar aquí que si hablamos de SC, deberíamos tener 16 Hosts (8+8+1) para poder garantizar capacidad suficiente ante un fallo total del site primario.

Hasta ahora, todo tiene sentido o espero que suene razonable. Pero la realidad es que no todo esto que has leido hasta ahora está respondiendo a lo que en prinicipio me planteaba. Todo esto tiene sentido cuando aplica a un Standard vSAN Cluster, pero yo he venido a hablar de un Stretched Cluster 🙂 Y eso es otra historia parcialmente distinta, y es así porque aquí falta un jugador indispensable en este partido: El Witness Host.

Si comprobamos la documentación, el Witness Host se puede desplegar en tres tamaños distintos:

Tiny (10 VMs o menos)

  • 2 vCPUs, 8 GB vRAM
  • 8 GB ESXi Boot Disk, one 10 GB SSD, one 15 GB HDD
  • Soporta un máximo de 750 witness components

Normal (hasta 500 VMs)

  • 2 vCPUs, 16 GB vRAM
  • 8 GB ESXi Boot Disk, one 10 GB SSD, one 350 GB HDD2 vCPUs, 16 GB vRAM
  • Soporta un máximo de 22,000 witness components

Large (more than 500 VMs)

  • 2 vCPUs, 32 GB vRAM
  • 8 GB ESXi Boot Disk, one 10 GB SSD, three 350 GB HDDs2 vCPUs, 32 GB vRAM
  • Soporta un máximo de 45,000 witness components

Estos valores provienen de la siguiente relación entre los componentes y su espacio en disco según recomendaciones de VMware:

Un único Witness Magnetic disk puede gestionar 21.000 componentes y cada componente requiere un almacenamiento de 16 MB. Ésto quiere decir que vamos a necesitar un mínimo de 3 discos para poder manejar el máximo numero de componentes posibles, que son 45.000 (45k/21k) = 2,1429 que lógicamente hay que redondear a 3.

También significa que un total de 350 GB son necesarias para almacenar 21.000 components (21k*16) y que, además implica tener 3 discos de 350 GB para poder ser capaz de gestionar ese número máximo de componentes (45.000).

Por otro lado, en lo que respecta al Witness Flash disk, VMware recomienda un total de 10 GB para gestionar los 45.000 objetos.

Que bien, eh?. Personalmente me tengo que tomar una cafe o al menos pegar mi espalda en el respaldo de la silla y con las manos detrás de la nuca comenzar a visualizar mentalmente todos estos números y digerir todo lo que hemos comentado hasta ahora. Realmente mi pregunta no era del todo precisa, realmente la pregunta llegados a este punto sería ¿Cuantos componentes estoy usando dentro de mi Stretched Cluster, bien a nivel de Host o bien a nivel de Witness?. Porque es aquí cuando nos damos cuenta de que la verdadera limitación de un SC es esa combinación. Podemos añadir más nodos a nuestro SC, si, hasta 30 según mencionamos antes, pero no podemos añadir ningún Witness más, nuestro Witness Host es único y posiblemente ésta sea la limitación en cuanto a crecimiento.

Pero, que es lo que realmente está guardando un Witness Host?. Sabemos que almacena componentes. A nivel de site, en un Stretched Cluster, disponemos de una especia de RAID-1, es decir, por cada objecto vSAN, se crean tres componentes, un componente en cada uno de los Fault Domain existentes.

Entonces, ¿Cómo se almacenan los componentes de una Máquina Virtual en el SC? o mejor dicho ¿Cuántos components ocupa una Máquina Virtual en un Witness Host?. Como el Witness Host es el tercer Fault Domain y el propósito de su componente es guardar el metadato que asegura más del 50% de los componentes de un objeto, cada una de las Máquinas Virtuales del SC tendrá los siguientes componentes en el Witness Host:

  • 1 Witness Component por cada VMDK de hasta 255 GB.
  • 1 Witness Component por SWAP
  • 1 Witness Component por VM Home Namespace
  • Nuevamente, 1 Witness Component adicional si la VM tiene algún Snapshot.

Y esto será independietemente del tipo de Storage Policy que tenga la máquina, ya sea RAID-1, RAID-5 o RAID-6.

CONCLUSION

Creo que los límites de un vSAN Cluster van a depender, principalmente de si es un Standard o Stretched Cluster. Si es Standard Cluster creo que los 9000 components por host (CxHost) va a tener que mirarse de cerca, al igual que el numero de máquinas por host (VMxH), pero si hablamos de Stretched Cluster, no solo lo mencionado anteriormente sino que existe el factor de los 45.000 components, realmente lo que antes aparezca, aunque si consideráis los números que hemos estado haciendo, hay bastante margen para el crecimiento, de hecho creo que VMxH sería el principal factor que obligue a seguir añadiendo nodos al clúster.

¿Y como controlar esos valores?. Si dispones de vRealize Operations deberías configurarlo para que sea el Gran Hermano en quien confiar. Con al Management Pack de vSAN, puedes dejar que vROps monitorice el entorno. Presta atención a las métricas que proporciona el Management Pack porque podrá decirte la cantidad de componentes en uso, y el límite que tiene impuesto el Witness Host por el tamaño selccionado durante su despliegue. Os dejo una imágen de muestra:

Si no disponéis de vROps, es posible contabilizar los componentes mediante PowerCLI. Las funciones de PowerCLI 11.4 me permiten ‘bucear’ por los objetos de vSAN y ver qué componentes están almacenamos en el Witness Host, aunque reconozco que mi método es poco eficiente, debido a mis limitaciones de programación, y el proceso tarda bastante. Básicamente sería recorrer todos los componentes de cada uno de los objectos del clúster,

Get-vSanObject -Cluster <Cluster> | ForEach-Object {Get-VsanComponent -vSanObject $_ }

Lo siguiente sería contabilizar los que el type = witness y además VsanDisk pertenece al dispositivo del Witness Host. Si lográis algo más preciso os agradecería comentarlo por aqui.

Hasta otra !

Novedades en HCX

Tras la release R124 de Agosto se han producido cambios considerables. El más importante es la aparición de HCX Enterprise. De este modo, ahora se dispone de dos productos con distintas funcionalidades.

HCX Advanced

Servicios Standard disponibles ya conocidos:

  • Interconnect
  • WAN Optimization
  • Network Extension
  • Bulk Migration
  • vMotion Migration
  • Disaster Recovery.

HCX Enterprise

Con este cambio, se presentan tres nuevas e impresionantes funcionalidades de carácter Premium que solo estáran bajo licenciamiento Enterprise:

  • OS-Assisted vMotion (OSAM) es el gran salto esperado para poder migrar cargas desde entornos KVM e Hyper-V. Ahora ya no excusa tener nuestras cargas en infraestructuras que no son VMware, HCX será capaz de hacerse cargo de ellas.
  • Replication Assisted vMotion (RAV), es una tecnología que combinalo mejor de los dos mundos; Bulk Migration y vMotion. Básicamente será posible Replicar una VM sin downtime.
  • Finalmente, la integración con Site Recovery Manager (HCX + SRM) abre otro mundo interesante de posibilidades para orquestar las cargas de trabajo.

Para los que conocéis el producto de años atrás, esto supone un cambio de nomenclatura importante, ya que la referencia de HCX Enterprise ponía el foco en la infraestructura Origen mientras que cuando hablábamos de HCX Cloud nos referíamos a la infraestructura Destino. Por el momento usémos HCX Manager en origen o destino para irnos acostumbrando 🙂

Como véis, VMware está que se sale, de modo que abrocháos bien las orejas, porque todo esto podrá saber a poco cuando finalice el próximo VMWolrd 2019 en Barcelona.

Importing vRNI 4.1.1 in vRealize Suite Life Cycle Manager shows version 2.6

After a fresh installation of vRealize Network Insight 4.1.1 we wanted to import it to a new environment on vRealize Suite Life Cycle.

vRNI 4.1.1 is only supported by vRsLCM on version 2.1.0 or above, so we made sure our version was correct.

It went fine, but final version shown on vRsLCM was 3.6.

Do not spend time with this, it’s fair simple to fix after confirmation with VMware Support. This is caused by importing your vRNI environment using the FQDN platform name. Delete the product and import it again using the IP Address. You’ll finally get it correctly done.

After finishing the installation you’ll finally get the right version imported.

Hope you could save time looking for answers. Once again VMware responds quickly and efficiently 🙂

HCX Enterprise se nos independiza …

… del vCenter Server. Como novedad en la release R120 de VMware HCX del 3 de Junio, además de arreglar el fix del cmdlet Get-HCXMigration, ha venido incorporada la posibilidad de gestionar el HCX Enterprise de forma independiente, es decir, que ya no es necesario conectarse al vCenter Server del cliente para realizar migraciones, actualizarlo o modificar los componentes.

Ahora se puede acceder directamente desde el navegador a la url https://hcx-enterprise-mgr-ip-o-fqdn y podemos trabajar con HCX sin usar el plug-in de vCenter Server. Por un lado nos desligamos de las credenciales de la dependencia del plugin y por otro, mejorará la experiencia en los entornos más antiguos donde el vSphere Client resulta mucho más perezoso.

Ay, que mayor se nos está haciendo… 🙂

Cuanta RAM usa vSAN ?

Cuando estamos valorando un nuevo proyecto donde se va a desplegar un nuevo vSAN Clúster, normalmente acudimos al vSAN Ready Node Sizer y obtenemos datos precisos como muestra la captura adjunta.

Pero realmente nunca nos hemos preguntado, o al menos no solemos hacerlo, cual es realmente el tamaño de RAM que consume nuestro almacenamiento vSAN. Tal vez, cuando algún sencillo proyecto con un presupuesto ajustado provoca que esa pregunta nos la hagan durante una reunión inicial y nos quedemos un poco como: “Si, bueno, en realidad es una overhead asumible…”, que lo es, pero … ¿Y si estuviéramos hablando de una POC o de un LAB donde nuestros recursos son más bien justitos y la memoria – ese bien preciado material que cotiza a precio Bitcoin – la tenemos que costear nosotros?.

Para ese caso, os traigo la siguiente información y entramos en materia. La cantidad de memoria requerida por un Host que pertenece a un vSAN Cluster, y por pertenecer entendemos que está aportando de forma homogénea su almacenamiento interno a vSAN, depende del numero de Disk Groups, del número de Discos y también del tipo de almacenamiento que utiliza, AllFlash o Hybrid.

En términos matemáticos los requerimientos de RAM que necesita un Host está determinado por la siguiente expresión:

BaseConsumption + (NumDiskGroups * (DiskGroupBaseConsumption + (SSDMemOverheadPerGB * SSDSize))) + (NumCapacityDisks * CapacityDiskBaseConsumption)

Vaya una formulita, no?. 🙂 Tranquilos, porque es más fácil de lo que parece, en realidad solo 3 valores son variables, el resto son constantes:

BaseConsumption es una cantidad fija de memoria consumida por el Host y su valor es 5426 MB

DiskGroupBaseConsumption también es la parte fija usada por cada DiskGroup y su valor es 636 MB

SSDMemOverheadPerGB es la cantidad de memoria asignada por cada GB de el disco SSD. Para soluciones Hybrid es 8 MB y para AllFlash sería 15 MB.

CapacityDiskBaseConsumption es la cantidad de memoria asignada por cada disco de capacidad y su valor es 70 MB.

Para hacernos una idea de si hablamos de mucha o poca cantidad, calculemos cual es la RAM necesaria para un clúster de 3 Nodos con 2 Disk Groups de 5 discos cada uno + 1 Caché.

El resultado sería: 16 GB para Hybrid y 23 GB para AllFlash. Lo cual si lo ubicamos en los escenarios que menciono anteriormente (LAB, POC, etc) es una cantidad a considerar, ¿verdad?

Hay que destacar que el tamaño máximo “usable” de un disco de caché en AllFlash – para Escritura – es de 600 GB. Aunque añadamos a nuestro Disk Group un disco Caché de 1,2 TB, realmente se usarán solo 600 GB, es decir, la mitad. Aunque esos 600 GB no usarían siempre los mismos bloques físicos y por tanto, alargaremos la vida del disco.

Para poder agilizar estos cálculos os dejo una hoja excel donde solo tendréis que indicar el número de discos, el de Disk Groups y el tamaño del disco de Caché , recordad que éste último es 600 GB máximo para AllFlash.

Más detalles sobre el uso de memoria en kb oficial de VMware.

Está aquí, entre nosotros.

Nos estamos acostumbrando a ver como las empresas cuentan con Hipervisores cada vez mas potentes, no nos damos cuenta, pero están ahí, día a día creciendo en lo que respecta al tamaño y número de recursos con los que cada uno de ellos a porta a nuestro clúster.

Un clúster al que, poco a poco, pero de forma ininterrumpida vamos asumiendo que ha alcanzado de forma definitiva la madurez y se ha convertido en todo un vSAN Clúster, dejando de depender, en la mayoría de los casos, de los tradicionales sistemas de almacenamiento y de su infraestructura subyacente.

Un vSAN clúster que hoy en día se ajusta a la mayoría de las necesidades y demandas del mercado, pudiendo partir de simplemente 2 Nodos que incluso pueden usar un cable cruzado (Sin olvidarnos de un 1 Witness adicional), continuando con el Standard de 3 Nodos (Recomendado que sean 4 para disponer siempre de FTT+1 incluso en tareas de mantenimiento) hasta alcanzar el umbral de la más alta disponibilidad de nuestro almacenamiento a nivel de Datacenter como es el Stretched Clúster.

Es importante puntualizar cuando hablamos de un clúster con vSAN porque eso conlleva una serie de aceptaciones y cambios a la hora de gestionarlo. Insisto, cuando un DRS / HA Clúster tiene vSAN por debajo, se está dejando claro que, ya las cosas no son lo mismo que eran ni se hacen exactamente de la misma manera. Ni se pone un Host en Modo Mantenimiento de la misma forma, ni el HA va a tener que depender de nuestra red de gestión, ni el almacenamiento disponible puede llegar a ser el que parece…

Sin profundizar mucho en detalles, que no es el caso de este post, por ahora solo quiero dejar claras dos recomendaciones:

  • Acostumbrémonos a llamar vSAN Clúster a nuestro nuevo entorno cuyo almacenamiento es la solución VMware para Software-Defined Storage.
  • Si tenemos que gestionar un vSAN Clúster, hay que ponerse las pilas y entender que operativas hasta ahora válidas, han dejado de serlo y cuales son las novedades al respecto.

Actualizar vRealize Business mediante vLCM

Anteriormente hemos visto como importar componentes  de vRealize Suite existentes e incluso como desplegar componentes nuevos desde vLCM. En esta ocasión vamos a observar como se realiza una actualización desde esta herramienta y elegiremos nuestro vRealize Business form Cloud para actualizarlo de 7.3.1 a la 7.4.

PASO 1: Lo primero que debemos hacer es revisar la Matriz de compatibilidad, que podemos hacerlo desde nuestro entorno creado. Seleccionando los tres puntos sobre el producto deseado.

Tras una comprobación online, nos mostrará la siguiente tabla, donde podemos verificar que será compatible con nuestro actual entorno.

PASO 2: Ahora, con la seguridad de que será compatible con nuestro entorno, procedemos a realizar un snapshot de nuestros componentes.

Añadimos descripción y pulsamos Submit y verificamos en nuestro vCenter que se está realizando.

Cuidado porque en mi prueba, tras pulsar SUBMIT solo me indica que la tarea se ha lanzado pero no cierra ventana. Verificad que ha lanzado el Snapshot y pulsar Cancelar.

PASO 3:  Asegurarnos de que disponemos de los binaries adecuados en nuestro repositorio – en este caso el archivo de actualización , no la OVA – o descargada desde nuestra cuenta My Vmware.

PASO 4: Seleccionamos nuevamente nuestro producto y pulsamos en Upgrade

Muestra la primera ventana del proceso en donde seleccionamos nuestro repositorio por defecto, en donde tenemos gurardada la ISO.

Revisar el progreso desde la lista de tareas y esperar a que todas se completen de forma satisfactoria.

Desplegar Log Insight con vLCM

Life Cycle Manager, es algo realmente excepcional desde el punto de vista del control de versiones, de una forma automática nos permite:

  • Instalar un nuevo producto de vRealize Suite
  • Importar uno existente de nuestro entorno para poder gestionarlo.
  • Actualizar la versión de cualquier producto.

En este ejemplo, vamos a instalar uno nuevo, concretamente el Log Insight. Posteriormente la Importación y la Actualización nos resultarán mas sencillas.

Pulsar en el icono HOME de la izqda y hacer click en Create Environment.

Completamos los campos con la información que hemos introducido anteriormente, seleccionando nuestro Data Center y eligiendo el Tipo de Entorno.

Seleccionamos con el checkbox en la parte de arriba a la dcha de nuestro producto a instalar, en este caso Log Insight y elegimos la versión adecuada. Aquí usaré la 4.51 para poder probar el upgrade posteriormente. Pulsamos NEXT.

Aceptamos la EULA e introducimos la Licencia del producto, bien mediante MyVMware o manualmente.

Ahora indicamos los recursos de nuestro DC, como el vCenter, nombre del Cluster, PortGroup y almacenamiento.

Es el momento de la configuración de red.

Dejamos el certificado auto generado y pulsamos NEXT.

Es el momento de personalizar nuestro vRLI indicando el tamaño y configuración IP. Como podéis observar, es posible también añadir mas de un nodo y realizar instalaciones balanceadas.

Realizar el test de validación y una vez superado hacer click en NEXT..

Revisar el resumen de nuestra instalación y pulsar SUBMIT.

El proceso de instalación comienza y puede verse el progreso.

Tras la instalación tendremos la siguiente

Si pulsamos en View Details. Tendremos la ficha de nuestro vRealize Log Insight

Al pulsar en los tres puntos veremos que podemos realizar varias tareas.

El mismo procedimiento puede repetirse para el resto de productos, en mi caso, en vez de instalar, importaré los productos Operations, Automation y Business que ya tengo desplegados en mi entorno y finalmente dispondré de los cuatro productos disponibles en vLCM.

La importación de vRA es bastante similar a todas, con las excepción de que, para despliegues existentes en HA con más de un nodo, tendremos que elegir cual es el primary node.