Storage Analitycs – Datastore Space.

Storage Analitycs.

Es el nombre de un DECK predeterminado en CloudPhysics y como su nombre lo implica, este DECK contiene 6 Cards dedicadas a decirnos que está pasando en nuestro almacenamiento conectado a vSphere y en el cual viven nuestras preciadas máquinas virtuales.

Una de las “cartas” en este DECK es Datastore Space.

La finalidad de esta “carta” es detectar como asignamos y usamos el espacio en los datastore que están conectados a nuestros ESXi ya sean directos, NFS, FC o iSCSI.

Una de las cualidades de esta carta es que desde el mismo DECK ya podemos saber si tenemos algún problema en nuestros datastore, en mi caso existen 2 alertas.

Una vez dentro de Datastore Space lo primero que vemos es la organización de todo nuestro ambiente de vSphere, esto puede llevarnos a confundir o tener que invertir tiempo en la búsqueda de la información que necesitamos. Lo mejor es usar la opción de Filter.

El filtro usado en este ejemplo es directamente al cluster de ESXi ubicado en mi HomeLAB. Podemos seguir filtrando con la opción de Show datastores with que la tenemos más abajo.

 

Mucha información, que hacemos con ella?

Después de aplicar los filtros tenemos menos información que interpretar y esto muchas veces es bueno porque nos libra de posibles errores al consumir la información.

En la imagen anterior vemos el resultado de los filtros aplicados, este resultado está compuesto por diferentes valores de los cuales conocemos algunos que siempre están presentes en nuestro vCliente o Web Cliente. El valor que me llama la atención es el Over-Commitment, esto es por el uso abusivo de Thin Provisioning en el HomeLAB.

Reclaimable Space nos brinda más información y esta vez concerniente a Snapshots, Thin Provisioning y el espacio usado por máquinas virtuales que posiblemente no son necesarias nunca más.

Datastores at High Risk nos muestra los datastore que están en peligro de quedar sin espacio, lo interesante es la predicción que se muestra, creo que esto es en base al historial de cómo se va consumiendo el espacio en estos datastore.

Como en la entrada anterior, toda esta información nos ayudaría a evitar un problema causado por un Datastore que se quedó sin espacio. Desde esta misma carta podemos ver una lista de las VMs que residen allí, el espacio ya siendo utilizado por la VM así como el espacio que fue aprovisionado para esta al momento de crear el o los discos virtuales.

 

Nota: Si aún no tienes cuenta en CloudPhysics, puedes generar una. Es completamente gratis y podrás usar las opciones avanzadas por 30 días.

Storage Analitycs – Datastore Contention.

Storage Analitycs.

Es el nombre de un DECK predeterminado en CloudPhysics y como su nombre lo implica, este DECK contiene 6 Cards dedicadas a decirnos que está pasando en nuestro almacenamiento conectado a vSphere y en el cual viven nuestras preciadas máquinas virtuales.

Una de las “cartas” en este DECK es Datastore Contention.

La finalidad de esta “carta” es detectar quienes causan contención en nuestro almacenamiento. Y lo hace muy bien.

 

Si contamos con varios Observer reportando vCenters diferentes (por cada vCenter necesitamos un Observer Appliance!!) podemos usar la opción de filtrado, con esta opción especificaremos cual vCenter queremos, cual datacenter, en cual cluster si tenemos varios y un datastore especifico. Usando el filtro y sus opciones tendremos la información exacta de que está aconteciendo en nuestro almacenamiento por cada Datastore que estemos presentando al vCenter.

Aja! Ya podemos ver que tenemos Datastore con contención, SynoVMwareVolume1, SynoVMwareVolume2 y Data6090G-SATA-Local.

Para fines de demostración estoy seleccionando el Datastore con más maquinas afectadas debido al alto consumo que vc5 está generando en el Datastore con el nombre SynoVMwareVolume1. En realidad esta imagen la tome varias horas después de la anterior y es la razón de que eran 11 y ahora solo 3.

Tenemos el culpable y las victimas, la pregunta ahora es como resolverlo?

En realidad eso depende (la respuesta típica!) de cada ambiente y en el mío que es mi HomeLab la forma de resolver esto es moviendo vC5 a otro Datastore con mejor rendimiento ya que además de tener vCenter esa VM también tiene instalado SQL y el software de manejo de PernixData FVP.

Esto es solo un poco de todo el potencial proporcionado por CloudPhysics y la analítica que nos brinda luego de registrar el Observer con nuestro vCenter.

Configurando la Base de Datos para Eventos en View 5.3

Como a otros, no me gusta tener servicios a ciegas, me refiero a no saber que pasa dentro del aplicativo y sus componentes, VMware View tiene la opción de conectar el Connection Server a una DB, en este caso lo estaré conectando a MSSQL para salvar esos eventos y poder analizarlos en caso de problemas en el servicio de View. Si hacemos click en Monitoring > Events tendremos la siguiente pantalla donde podemos ver un mensaje que nos indica que aún no hemos configurado la DB para los eventos.  Procederemos a realizar esta configuración, ya había creado la DB para estos fines, así que solo falta decirle al Manager cual es el servidor, las credenciales y el prefijo. Realizada la configuración podemos ver que la opción de eventos nos muestra que mi usuario realizo una configuración. View Connection Server también nos brinda enviar logs a un log server el cual más adelante también configurare.

VMware DRS con DPM en el HomeLAB.

Hoy llegue a casa para encontrar el área del HomeLAB demasiado caliente, en estos momentos en mi HomeLAB creo que existen demasiados dispositivos. (no!!!! Nunca!) En fin, mi ambiente de VMware consta de 3 ESXi los cuales están encendidos la mayoría del tiempo, la habitación donde están el HomeLAB por naturaleza es caliente ya que el Sol muere en sus paredes a eso agréguenle equipos generando calor. Hace tiempo atrás intente usar DPM para conseguir lo mismo que he conseguido esta vez, que DRS & DPM se encarguen de encender los ESXi cuando vSphere los necesite sin intervención manual.

Lo primero es que ninguno de mis equipos tiene iLO/IPMI u otra variante que ayude a DPM a realizar su tarea así que he recurrido al viejo y no tan confiable WoL (Wake-on-LAN). Uno de los inconvenientes conocidos con DPM es que no puede enviar la señal de levantar el ESXi si este no cuenta con un IP de manejo en un vSwitch, normalmente no uso vSwitch y siempre despliego vDSwitch para ahorrarme cosas y simplificar la conectividad de mis ESXi, por suerte esta vez contaba con una NIC que no la agregue a los vDSwitch y solo tuve que crearle otro vmk para manejo.

Los pasos son los siguientes:

Asegurarnos de que nuestra tarjeta soporta la funcionalidad.

Habilitar DPM en el Cluster y especificar Manual en las opciones de DPM dentro de DRS.

Seleccionamos un Host para hacer la prueba antes de permitirle a DPM que tome el control y lo enviamos a Standby de forma manual.

Una vez el host este en modo Standby intetamos traerlo devuelta usando la opción de PowerOn.

Si el ESXi vuelve del modo Standby quiere decir que estamos listos para dejar que DPM tome el control, en mi caso solo quería enviar a Standby un equipo el cual agregue hace unos días y que solo cuenta con 8GB de RAM (si, necesita mas memoria.) y que será solo para correr vESXi. Para solo enviar este equipo a Standby dirigimos nuestro mouse a Cluster -> Manage -> Host Options, editamos las opciones para el ESXi en específico, yo decidí dejar la configuración principal en Manual y editar los Host asignando Disable, Manual y Automatic respectivamente a mis ESXi. Aquí una imagen de como quedo la configuración.

 

Instalando VMware Horizon View (Composer).

Composer es un componente de VMware Horizon View y se basa en el uso de la tecnología de Linked-clone la cual posiblemente ya se conoce desde hace un tiempo.

Pre-requisitos:

View Composer solo soporta ser instalado en una versión de Windows 64bit. Puede ser instalado en la misma maquina donde tenemos nuestro vCenter o podemos instalarlo de manera “stand-alone”.

Los requerimientos exactos de Composer se pueden encontrar en este link: http://pubs.vmware.com/view-52/index.jsp#com.vmware.view.installation.doc/GUID-AF050FEA-5382-4D4A-BB83-24A087FD644B.html#GUID-AF050FEA-5382-4D4A-BB83-24A087FD644B

Lo primero que debemos hacer es decidir si nos conviene instalar Composer en la misma maquina o stand-alone, la siguiente instalación es stand-alone porque ya tengo en mi vCenter el software de manejo de PernixData FVP y no quería cargar más la maquina con el servicio de vCenter.

Con relación a la Base de Datos para Composer, este soporta MSSQL & Oracle, la siguiente instalación es realizada con una DB de MSSQL que en mi caso es el mismo SQL Server que uso para vCloud Director y otras aplicaciones en aaNetworks. La forma implementada en Composer para conectar a la DB es mediante DSN (System DSN) el cual debemos crear en el servidor donde queremos instalar el servicio. Una vez que tenemos nuestra DB y usuarios creados en el SQL procedemos a crear el System DNS.

Una vez creado nuestro ODBC podemos lanzar la instalación de Composer.

Listo, ya está instalado. En mi ambiente de LAB ya tenía instalado un Connection Manager conectado al vCenter, me toca editar esa conexión para ahora decirle que existe un Composer.

A estas alturas solo faltaría crear una VM con Windows7/8 para designarla como “Parent VM” y luego crear un pool en donde usaremos esta VM y crear los linked-clones necesarios en nuestro ambiente de VMware Horizon View.

Page 1 of 12512345...102030...Last »