vSAN activar Performance Service en politica alternativa

vSAN activar Performance Service en politica alternativa

En esta ocasión vamos a ver cómo se activa el servicio de Performance de vSAN a través de powershell para vSAN, pero , teniendo en cuenta que deseamos hacerlo para “otra” politica de almacenamiento que hayamos definido, recordemos que por defecto utiliza una, pero podemos crear mas.

En algunas versiones de vSAN, dicho servicio no está activado por defecto, por tanto, vamos a ver cómo de una manera muy sencilla se puede activar mediante comandos de powershell.

Get-VsanClusterConfiguration -Cluster “vSAN” | Set-VsanClusterConfiguration -PerformanceServiceEnabled $true

Nos apareceran varias columnas:

cluster, y pondrá vsan.

VsanEnabled, y pondrá true.

Como decia antes, eso lo activa para la “politica predeterminada de almacenamiento”, para activarlo para otra alternativa seria:

Get-VsanClusterConfiguration -Cluster “vSAN” | Set-VsanClusterConfiguration -PerformanceServiceEnabled $true -StoragePolicy (Get-SpbmStoragePolicy -Name “nombre politica”)

El resultado será el mismo que antes, aparecerá en la columna cluster, vsan, y en la columna VsanEnabld, true.

Así de sencillo, un saludo.

 

Anuncios

vSAN witness

vSAN witness

Como sabeis en vmware , integrado con vsphere vcenter, disponemos de la posibilidad de tener un sistema hyperconvergente llamado vSAN.

Esto quiere decir que de un pool de servidores que tienen discos locales, podemos conformar un único datastore con esos discos

vSAN admite las características de VMware que requieren almacenamiento compartido (como HA, vMotion y DRS) y, al mismo tiempo, elimina la necesidad de usar almacenamiento compartido externo y simplifica las actividades de aprovisionamiento de máquinas virtuales y configuración de almacenamiento.

VMware vSAN emplea un enfoque definido por software que crea almacenamiento compartido para las máquinas virtuales. Lo que hace es virtualizar esos discos locales de los esxi que conformaran el cluster vSAN, los transformara en “grupos de almacenamiento” que pueden generarse de forma automática por el propio software de vSAN o por nosotros pudiéndose dividir y asignarse a máquinas virtuales y aplicaciones basándonos en lo que necesitemos en cuanto a calidad de servicio.

Podemos configurar un cluster hibrido o basado todo en flash. En los hibridos tendremos que especificar qué discos con para “capacidad” y cuales para “caché”, cuando es todo flash se utilizan para memoria cache y de capacidad.

Witness

El motivo de este artículo precisamente es el objeto witness que podemos crear dentro de la infraestructura, y lo que hay que hacer para montarlo correctamente.

Es un componente que contendrá metadatos y no datos reales de aplicaciones. Al final su misión es tomar una decisión en relación con la disponibilidad de los componentes del almacen de datos que restan después de un error, (es decir, que falle algún disco en algún host).

Al final utiliza un sistema de quorum en donde cada componente puede tener mas de un voto para decidir la disponibilidad de los objetos, debe ser superior al 50% esa accesibilidad de los votos que componen el objeto de almacenamiento. Si por lo que sea es igual o inferior a ese %, el almacen de datos (datastore vsan) ya no puede acceder al objeto, esos objetos inaccesibles pueden lógicamente afectar a la disponibilidad de la máquina virtual.

Opciones para implementar vSAN

Cuando estamos montando el cluster de vSAN tenemos varias opciones , (no vamos a entrar en todas, solo en una de ellas motivo de este artículo en relación al witness), son las siguientes:

  • Cluster de vSAN standard , consta de un mínimo de 3 host
  • Cluster de vSAN con DOS host
  • Cluster ampliado de vSAN (este artículo)

Este artículo es para hablar del “cluster ampliado”, o mejor dicho, un cluster en donde tenemos DOS host, y un witness, es paso una imagen.:

cluster ampliado

Si nos decidimos a implementar un cluster de vSAN con DOS HOST, el problema que tenemos es “la disponibilidad”, es como si tuvieramos un RAID0 , es decir, el sistema crea un datastore único con la suma del tamaño de los discos de los dos servidores, pero, en RAID0, esto quiere decir que si hay alguna máquina en ese datastore, y por lo que sea falla un disco, tendremos un problema con la máquina virtual ya que no tenemos disponibilidad ante un número “x” de errores.

En el ejemplo de un cluster de TRES host, el tema es distinto, existe entonces una disponibilidad de 1, es decir, disponemos de la posibilidad de tener un RAID1, el inconveniente que tenemos aqui es el coste, aumentara primero lógicamente porque tenemos un servidor mas , o otro porque debemos disponer de un switch, si además lo tenemos conectado por FC, mas costoso todavia.

Asi que, como posibilidad mas económica, podemos configurar un cluster ampliado vSAN, hace años era obligatorio 3 host mínimo, pero ahora podemos tener solo dos un un witness y simular lo mismo que con tres host, todo gracias al witness o testigo.

Al grano

La idea de este artículo es disipar las dudas a la hora de implementar un vSAN cluster ampliado, (2 host y testigo).

Imaginaros una topologia de dos host, en donde están conectados via FC 10G “directamente”, es decir, sin switch (ahorro de costes).

En cada host esxi, tendremos un switch virtual , llamemoslé “vsan”, que tiene una vmnic pongamos que se llame la vmnic1, esa será la red de vSAN traffic, y habrá un puerto vmkernel (vmk1), con la red por ejemplo 10.10.10.x, aqui debemos activar la casilla “vSAN” que aparece cuando editamos el puerto vmkernel. Con esto le estamos diciendo que  por ahí vaya el tráfico de vsan,  es decir, por esa red específica. También podremos activa la casilla vmotion.

Por otra parte cada host tendrá su vmk0 para management, imaginemos 192.168.10.x

El testigo.…..

Este será una máquina virtual que debemos desplegar en la infraestructura de vsphere, dicha máquina virtual se puede descargar de la web de vmware, y , después personalizarla con los datos de ip convenientes.

Realmente, cuando arrancamos la máquina vemos que es “un esxi”, ese esxi debemos añadirlo como “un host nuevo” en nuestro vcenter, PERO, FUERA DEL CLUSTER DE VSAN.

Pero es que esta máquina virtual, además , NO DEBE ESTAR EJECUTANDOSE EN ALGUNO DE LOS HOST DE VSAN, sino en otro host que tengamos (podria ser con licencia de esxi free).

Seguimos en busca del problema…..

La máquina virtual witness, nos vendrá con dos tarjetas de red, una para conectar a su administración, y otra para la red de vsan.

El tema es que con la topologia que os comento, NO vamos a poder conectar físicamente ese tercer host que ejecuta la máquina virtual witness en ningún sitio, ya que NO tenemos switch.

Y aqui está el error !!, creer que la tarjeta del witness se tiene que conectar a la red de vSAN de los host, mas bien lo que necesita es poder comunicarse con los host, por tanto para que no tengais problemas si os surge la necesidad de implementar dos host y testigo  sin switch para vsan, es pongo los siguientes esquemas, en donde claramente vais a poder ver , cómo conectar y configurar todo.

PRIMERA OPCION: UTILIZAR EL VMK0 DE MANAGEMENT

A mi me parece la mas sencilla, os pongo la imagen y la explico:

esquema por puerto administracion

Arriba del todo veis el witness, máquina virtual que se está ejecutando en un sitio fuera de los host del cluster de vsan, podriamos tenerla ejecutándose en otro  host de otro vcenter si es que tuvieramos otra infraestructura, o simplemente pinchado en la red de “servicio” o management que se tenga.

Os he dicho que venia con dos tarjetas de red, una se anula , y como veis se utiliza solo la VMK0 , es decir, management.

Ahí en el witness, tendriamos que editar el VMK0 y marcar la opción “vSAN”, únicamente.

NOTA IMPORTANTE: No vamos a poder editar el vmk0 y marcar la opción vsan, si no lo hacemos desde el servidor vcenter.

Luego vemos en la imagen que hay un switch, ese será el switch no de vSAN, sino de red donde tenemos pinchados los vLANS para mgmt, o red de servicio.

Los esxi de vSAN.

En la imagen veis que hay pinchado cable directo entre ellos para la red de vSAN. Cada servidor tendre su vmk0 de management, su vmk1 de vSAN, su vmk2 de vmotion….

Aqui lo importante es:

Que en el vmk1 de la red de vSAN, es decir, el cable directo, en las propiedades de ese vmk1 , marquemos la opción vSAN.

Y….también, que tageemos como “witness”, el puerto vmk0 de management, esto solo lo podemos hacer via comandos, pero el comando es muy sencillo, seria tal que asi:

Entramos a cada uno de los host y hacemos:

esxcli vsan network ip add -i vmk0 -T=witness

Después comprobamos con el comando:

esxcli vsan network list

comprobacion witness tag

Es decir, con esto lo que hemos hecho es configurar la topologia para que la máquina witness, se pueda comunicar con los host del cluster de vSAN, sin necesidad de tener un switch adicional, y sin necesidad de tener otro host mas.

Para comprobar que todo está correcto, podremos ir a la “supervisión” de vsan, para que nos vaya recorriendo todos los componentes (red, disco, cluster….etc), y nos diga si está bien o no.

Otra manera

Tenemos otra manera de configurar lo anterior, básicamente se trata de tener una red específica para cada esxi host, es decir, un trafico separado específico, lo mismo que antes os pongo un pantallazo, y ahí se ve claramente la diferencia, en donde ya en el witness hay un vmk1 especifico para vSAN traffic, con una ruta estática, y en los host lo mismo, tenemos un vmk1 que es donde tienen que llegar el witness.

esquema por puerto vmk especifico

Eso es todo !!, yo creo que simplemente con estos esquemas, seremos capaces de configurar un cluster de vSAN con dos esxi conectados directamente, sin switch y un witness o testigo como máquina virtual, para nuestros dominios de errores (si, igual no sabeis de que va esto, pero ampliaré mas información sobre vSAN en otro artículo).

Un saludo !!

 

 

VCSA fsck failed

VCSA fsck failed

Nos encontramos en un vcenter formato VCSA, es decir appliance de linux, el siguiente error:

fsck failed. Please repair manually and reboot. The root file system is currently mounted read-only. To remount it read-write do:
bash# mount -n -o remount,rw /
Attention: Only CONTROL-D will reboot the system in this
maintanance mode. Shutdown or reboot will not work.
Give root password for maintenance
(or type Control-D to continue):

error fcsk vcenter appliance

Para solucionar el problema, el procedimiento es el siguiente:

1.- Pulsamos Control-D para acceder a grub.

2.- Habilitamos el shell (bash), para ello pulsamos “p”, con la opción VMware seleccionada.

1

Introducimos la password de la cuenta de administrador (principalmente, o normalmente “administrator@vsphere.local”.)

2

Seleccionamos VMWare vCenter Server Appliance y presionamos la tecla “e”.

3

Seleccionamos la segunda entrada (la que comienza con Kernel) y pulsamos “e”.

4

Modificamos la línea final añadiendo init=/bin/bash y pulsamos enter para habilitar el bash Shell en el arranque.

5

Presionamos “b” para arrancar desde la línea modificada.

La máquina arranca hasta llegar al command prompt:

6

Introducimos los comandos:

mount -n -o remount,rw

fsck -f -c -y

Iniciara un proceso de reparación de errores en el fylesystem.

Cuando finalice ejecutamos el comando reboot para reiniciar el VCSA.

FIN

Este problema suele ocurrir cuando hay algún tipo de apagado no deseado, como es la ocasión, la cual la he aprovechado para que si os pasa lo mismo tomeis nota.

Un saludo.

NTP ver configuracion

NTP ver configuracion

Con esta linea de powershell , podemos ver las configuraciones de NTP de  nuestros servidores esxi:

configuracion ntp powershell

Get-VMHost | Select Name, @{N=”NTPSetting”;E={$_ | Get-VMHostNtpServer}}

Para cambiar a “todos” los esxi que tenemos la configuración NTP,  podemos lanzar la siguiente línea:

$NTPServers = “es.pool.ntp.org”, “pool2.ntp.org”Get-VMHost | Add-VmHostNtpServer $NTPServers

Como vemos, con powercli nos va a permitir una rápidez mayor a la hora de hacer algunos cambios, sobre todo si tenemos  muchos servidores.

Un saludo !!

 

Registros del sistema de host

Registros del sistema de host

Vemos la siguiente advertencia en los host:

alerta

ESXi se puede configurar para almacenar archivos de registro en un sistema de archivos en memoria. Esto ocurre cuando el directorio “/ scratch” del host está vinculado a “/ tmp / scratch”.

Cuando esto se hace, solo se almacena el valor de un solo día de registros en cualquier momento. Además, los archivos de registro se reiniciarán en cada reinicio.

Esto presenta un riesgo de seguridad ya que la actividad del usuario registrada en el host solo se almacena temporalmente y no persistirá durante los reinicios. Esto también puede complicar la auditoría y dificultar el monitoreo de eventos y el diagnóstico de problemas. El registro del host de ESXi siempre se debe configurar en un almacén de datos persistente.

Recuperar información actual

Get-VMHost | Select Name, @{N=”Syslog.global.logDir”;E={$_ | Get-VMHostAdvancedConfiguration Syslog.global.logDir | Select -ExpandProperty Values}}

Con esta línea de powershell, podemos sacar el listado de nuestros host con información de configuración :

ver configuracion con powershell

En la columna de “syslog.global.logdir”, vemos la configuración actual, en el caso de la imagen todo está correcto, ya que se especifica un datastore , asi como scratch/log.

Realmente lo que estamos viendo se corresponde con la configuración que existe en las opciones avanzadas del servidor en la parte de “syslog”, global.

configuracion a realizar

Si por lo que sea esa información está incorrecta y queremos solucionar el  mensaje de alerta del principio de este documento, o si deseamos cambiar la ruta, podemos ejecutar otra sencilla linea de powershell:

Get-VMHost | Foreach { Set-VMHostAdvancedConfiguration -VMHost $_ -Name Syslog.global.logDir -Value “otrodatastore” }

En donde en la parte de -Value pondremos el nombre del datastore a cambiar.

Un saludo !!

Copy/Paste en PowerShell

Copy/Paste en PowerShell

Hay veces (tampoco muchas), y mejor por seguridad, que necesitamos hacer “copy/paste” desde nuestro equipo a la consola de una máquina virtual en el entorno de vpshere.

Como NO es recomendable por seguridad según la “hardening guide” de Vmware, vamos a ver una línea de powershell que nos sirve para listar todas las máquinas que están infringiendo esta politica, es decir, que tienen activado para poder hacer “copy/paste”.

Get-VM | Get-AdvancedSetting -Name “isolation.tools.paste.disable” | where {$_.value –eq “false”} | Select Entity, Name, Value

Lo vemos por ejemplo en la siguiente imagen:

listado las que estan activas para poder hacer copy paste

En la imagen superior vemos una máquina que incumple, ya que el valor que devuelve es “false”.

copy paste

En la imagen superior vemos como dicha máquina tiene un valor de false y agregadas las dos líneas necesarias para activar o desactivar copy/paste.

El resto de máquinas, de forma predeterminada, tienen desactivada la posibilidad, por eso no aparecen.

Cambiar a TRUE

Podriamos lanzar otra linea de comando para asegurar que todas las máquinas estan imposibilitadas para hacer copy/paste:

Get-VM | New-AdvancedSetting -Name “isolation.tools.paste.disable” -value $true

Un saludo !!

 

 

Vmware Tools Error

Vmware Tools Error

Nos aparece el siguiente error al instalar las vmware tools en una máquina nueva, y realizándolo de la manera normal, (boton derecho, guest, install/Upgrade VMware tools“).

error que da

Podriamos ir a la web de vmware y descargar las tools para instalarlas, en este caso en un sistema operativo windows, el problema es que el sistema operativo no tiene red, por tanto no las podemos descargar directamente para instalar, y no podemos hacer un \\ip-nombre en otro equipo donde esté descargado.

Las tools desde la web de vmware vienen en formato .zip ,  para poder realizar esta instalación tenemos dos opciones:

  • Conseguir una .iso de las tools
  • Configurar COPY/PASTE para pegar el fichero dentro de la máquina virtual (aunque hay un problema, luego comento).

Conseguir una .iso de las tools

https://packages.vmware.com/tools/esx/index.html

Desde aqui buscamos la versión de nuestro esxi (con el update correcto), y tenemos la descarga en formato .exe y en formato .iso

desde donde se baja iso

Subimos por ejemplo la .iso a un datastore, y luego como siempre, vamos a propiedades de la máquina virtual y buscamos el fichero .iso (en el caso de windows veremos una carpeta “windows” en formato .iso).

Permitir copy/paste para copiar dentro de la máquina virtual

Esta es una opción que tenemos como otras muchas de la HARDENING (Recomendaciones de Seguridad) , (adjunto link).

https://www.vmware.com/security/hardening-guides.html

Se trata de editar (con la máquina virtual parada), las propiedades de la máquina virtual , pestaña OPCIONES, en la parte de “avanzado” vamos a “general”, y a la derecha vemos PARAMETROS DE CONFIGURACION, ahí hay que añadir dos líneas para permitir el copy/paste, son las siguientes:

copy paste

El problema es que, aunque hagamos esta configuración, al no tener las vmware tools instaladas (que es el objetivo), ésta opción no va a funcionar. (Lo pongo por si se nos habia ocurrido, saber que no es posible).

Asi pues, la mejor opción y mas sencilla, es conseguir una .iso de las tools.

Un saludo !!