Ubicaciones de los LOGs en vCenter virtual appliance

Ante una situación de soporte es posible que debamos acceder a revisar los logs del virtual appliance de vCenter, la mayor parte de los logs esta en el directorio /var/log/vmware aunque existen también sub-directorios que contienen logs de algunos servicios (Ej. FirstBoot.log, ubicado en /varl/log)

La versión windows tiene los logs en C:\ProgramData\VMware\vCenterServer\logs aunque como comente en posts anteriores, la recomendacion de VMware es pasarse cuanto antes al vCenter virtual appliance.


Para mas información acceda al siguiente link https://kb.vmware.com/s/article/2110014

WS

VSAN - ¿1 Disk Group?, ¿varios Disk Groups?, ¿cuantos Disk Groups?

Una de las consultas que mas me hacen los alumnos en el curso de VSAN Deploy& Manage es, ¿al momento del  diseño del cluster VSAN cuantos disk groups debo planificar?

El diseño de los disk groups afectan la disponibilidad, performance y capacidad del cluster, cuanto mas disk groups posea, los componentes se podrán distribuir en una mayor cantidad de almacenamiento, esto lógicamente disminuye el riesgo.

Pero vamos a una  explicación mas grafica para comprender mejor estos conceptos, al visualizar el dibujo, Uds. mismos podrán sacar sus propias conclusiones

En la figura observamos dos casos de VSAN, en ambos casos de 5 nodos, en ambos casos con 20 TBytes de espacio para almacenamiento (capacidad raw).

VSAN1, posee en cada servidor un solo disk group con 2 discos de 2TB para almacenamiento y 1 disco SSD que se usa como cache/buffer, un disco SSD tradicional nos entrega unos 36.000 IOPS, podemos concluir que cada nodo nos entrega 26.000 IOPS, comparemos con VSAN2 en la parte inferior de la figura, observamos que cada nodo posee 2 disk groups (DG), es verdad, los DG son mas pequeños (2 TB), los SSD también mas pequeños 200 GB vs 400 GB en el caso anterior, estos SSD entregan un poco menos de IOPS de los anteriores, podríamos decir unos 32.000 IOPS, Peeeero, ,en este caso cada nodo nos entrega 64.000 IOPS, mejor que el anterior no?

Además tenemos otros beneficios, cada DG (el rectángulo rojo) es un dominio de fallas, por lo que si falla un disco SSD, esta falla inutiliza el DG completo, en el caso de VSAN2, la falla implica perder 2 TB de espacio de almacenamiento mientras que en VSAN1 pierdo 4 TB. (Nota: Cuando uso la palabra "perder" no significa que se perderán datos, la perdida o no de datos dependerá de la política que aplique a mis maquinas virtuales, si la misma es PFFT=1 (Cantidad de fallas primarias a tolerar = 1) no se pierden datos ya que los mismos están replicados en otro nodo.))

En VSAN2 tengo mayor cantidad de STRIPES (RAID0) que en VSAN1

El diseño ideal seria también distribuir los discos en mas de un controlador de disco, de tal forma que la falla del mismo no me deje inutilizados todos los DGs.

Conclusion? cuando mas DG posea es mejor, un nodo puede tener hasta 5 DG, los cuales pueden tener hasta 7 dispositivos de almacenamiento de datos, cada DG debe tener mínimo un disco SSD que se usa como cache/buffer (VSAN hibrido) o cache (VSAN All flash)

Tiene desventajas usar mas DGs?, como siempre digo, los temas de TI son como la "frazada corta", si me tapo la cabeza me destapo los pies y viceversa, por lo que VSAN2, tiene la desventaja que necesito mas discos SSD, incrementar los DG me obliga a adquirir mas discos SSD lo cual puede encarecer la solución respecto al esquema de VSAN1, aunque día a día bajan los precios de los discos SSD, entonces...todo ok!

Saludos!

Que discos SSD debemos usar para VSAN?

Como ustedes saben VSAN necesita discos SSD mínimamente para usar como cache aunque adicionalmente podría usar también estos discos para el nivel de almacenamiento de datos, la pregunta siguiente es ¿Como elijo un disco SSD para VSAN?

Antes de responder la pregunta repasaremos las características de un disco SSD, básicamente es una memoria, por ello su baja latencia respecto a un disco magnético, pero a diferencia de la memoria RAM, el disco SSD esta formado por transistores NAND que tienen un numero finito de ciclos de escrituras debido a que cada eliminación/escritura de datos degrada el transistor. Una vez que se cumple el ciclo de escrituras el mismo empieza a fallar, es un fallo gradual, las celdas empiezan a fallar y la performance se degrada.

Hare una breve descripción de las métricas que identifican cada tipo de disco SSD.  La calidad de un disco SSD esta representada por su "endurance" (dureza), como saben el disco SSD esta formado por memorias que en realidad son transistores que tienen una cantidad limitadas de "escrituras", es decir que cuando borre el contenido de un transistor para almacenar bits, esto se cuenta como una escritura.

Este grado de "endurance" se puede medir de diferentes formas como ser DWPD (DRIVE WRITES PER DAY), o sea la cantidad de veces que el disco SSD puede rescribirse completamente en un día durante el periodo de garantía antes de llegar a cumplir su vida útil, o sea si tengo un disco SSD 800GB con 5 años de garantía, un DWPD = 1 significa que puedo escribir 800GB cada día durante 5 años luego del cual puedo esperar que el disco falle.

Los DWPD pueden variar dependiendo del uso que le dará a los discos SSD, si el consumo es para almacenamiento enterprise obviamente necesito un disco con endurance mayor a si usare el disco para una notebook.

Otra forma de medir el endurance es mediante la métrica TBW "TERABYTES WRITEN" que es la cantidad de datos que podemos escribir/borrar antes de empezar a esperar fallos en el disco.

Ambas métricas lógicamente están relacionadas, si tengo un disco SSD con DWPD = 10 para un SSD de 800 GB podemos calcular los TBW de la siguiente manera

TBW (5 años) = Tamaño SSD x DWPD x 365 x 5 años

TBW = 0,8 TB x 10 x 365 x 5 = 14.600 TBW (5 años)

Con este dato de 14.600 TBW puedo acceder a la siguiente tabla donde podemos ver que uso podemos darle a este tipo de disco en VSAN:

Observamos que el disco cuyoTBW es de 14.600 VMWare lo clasifica como un disco clase D, es decir que puedo usar este disco para Cache o Capacidad en un VSAN All Flash.

La tabla muestra que tipo de disco corresponde para cada uso en VSAN

28 Marzo 2017 - Parche critico de seguridad para Esxi

En el día de hoy VMware lanzo parches de seguridad críticos para sus productos VMWare vSphere ESXi, VMware Fusion y VMware Workstation debido a vulnerabilidades detectadas durante la competencia de Pwn20wn 2017, según reglas de la competencia los competidores que descubren vulnerabilidades las informan en forma exclusiva a ZDI quien provee la misma solo a la compañía afectada, si bien la vulnerabilidad fue demostrada solo en VMware Workstation para Windows, podría encontrarse en las otras plataformas Al momento VMWare no detecto exploits activos de esta vulnerabilidad descubierta y ya están disponibles los parches de seguridad.

La vulnerabilidad es en controladores de SVGA y XHCI que permitirían que un guest ejecute código en el host.

Para acceder  los parches según la version del producto que utilice acceda al siguente link

http://www.vmware.com/security/advisories/VMSA-2017-0006.html

Adicionalmente recomiendo lectura de los siguientes links

vSphere Security Guide

vSphere Hardening Guide

Como apuntar un vCenter a otro PSC del mismo sitio

Cuando tenemos varios PSCs sin un balanceador de carga, el failover del vCenter debe hacerse a mano, para realizar esta tarea lea esta informacion oficial de vmware

Que es el Advanced Format (AF) que soporta ahora vSphere 6.5 / VMFS6 ?

ADVANCED FORMAT

Con el avance de la tecnología los discos fueron creciendo en tamaño cada vez mas, el Advanced Format (AF) estandardiza el formato de los discos para mejorar su performance al aumentar la longitud de los sectores de datos del disco para que sean más largos que su tamaño tradicional de 512 bytes.

El estandard fue formulado por IDEMA(International Disk Drive Equipment Association - www.idema.org) formado por los pricipales fabricantes de hardware.

IDEMA pretende garantizar que los dispositivos de almacenamiento suministrados por varias compañías sean compatibles con los sistemas de archivos y las generaciones de sistemas operativos que soportan la tecnología del sector AF.

AF mejora la eficiencia de formateo y la fiabilidad de los datos grabados aumentando la longitud de los sectores de datos y la fuerza relativa de los algoritmos de detección y corrección de errores. Los estándares de formato avanzado de la generación uno estipulan un tamaño de sector físico de 4.096 bytes e incluyen la capacidad de emular lógicamente los sectores más antiguos de 512 bytes (a veces denominados "512e") para mantener la compatibilidad con aplicaciones o hardware que demanden un sector convencional de 512 bytes tecnología. Durante la emulación, cuando el host envía los datos de la unidad de disco para ser almacenados en incrementos de 512 bytes, la unidad de disco sitúa el sector de 512 bytes emulado en una posición apropiada dentro de un sector físico más grande de 4,096 bytes y escribe el sector de 4,096 bytes en el Disco.

Algunos sistemas de archivos y generaciones de sistemas operativos ya soportan el sector físico de 4096 bytes como el tamaño del sector lógico. Dichos sistemas anfitriones se denominan "4K nativos (4Kn)" . Dado que la longitud del sector físico y lógico es 4096 bytes, la emulación de los antiguos sectores de 512 bytes ya no es necesaria, permitiendo que el host 4Kn utilice el almacenamiento de disco 4Kn disponible de manera más eficiente

Desde el punto de vista de VMware tanto vSphere 6.5 con VMFS6 y VSAN 6.5 soportan AF pero en modo 512e (emulando) ya que hoy en dia aun las aplicaciones y los sistemas operativos no soportan discos 4K. Seguramente versiones posteriores mejoraran la oferta.

Politicas incluidas en VMware vRealize Operations Manager

vRops incluye algunas políticas que podrán ser utilizadas para casos especiales, aquí pueden ver una tabla de las políticas incluidas en el producto y cual es el uso de cada una de ellas, de todas maneras el producto lógicamente permite que Ud mismo cree la política que desee según su necesidad.