Buenas! Hoy vengo con un post rápido acerca de un fallo que me ocurrió cuando quise pasar un clúster de vSAN de usar» Compresión» a ninguna ninguna característica de ahorro de espacio. Para realizar este cambio es necesario una recreación de todos los diskgroup del clúster. Al realizarla me dio un fallo, casi a mitad del proceso. Si quieres saber lo que me ocurrió, aquí te lo dejo.
Introducción
Como sabemos vSAN nos ofrece la posibilidad de ahorro espacio en nuestro datastore utilizando ya sea «Compresión» o » Reduplicación y Compresión». El cambio de cualquiera de ellas, necesita de una recreación de todos los «diskgroups» del clúster. Estos se pueden hacer de forma segura, es decir evacuando todo el dato, borrando el diskgroup y creándolo otra vez(Es un proceso automático). Otra de las formas es marcando el checkbox «Allowed reduced redudancy«, el cual básicamente eliminara el diskgroup(No data migration) e inmediatamente comenzara la resincronización de todo el dato en los otros diskgroups.
Esto es muy peligroso, ya que si durante la resincronización se nos rompe algún «Diskgroup», perderíamos la única copia del muchos de los objetos y por tanto seguramente sea imposible recuperarlo, por lo tanto si lo hacemos que sepamos las consecuencias.
En mi caso y continuando, tenia activado la «Compresión» y quería dejarlo sin ninguna característica de ahorro de espacio, por ello maque la opción «None» y pulse «Apply».
Cual fue mi sorpresa cuando me doy cuenta que el proceso ha fallado, rápidamente me dirigí al «Skyline Health», y bajo la opcion «vSAN cluster configuration consistency», me encontré que concretamente habían fallado en 2 Diskgroups.
Investigando los logs del esxi, y concretamente el log «clomd.log»( En este log podemos encontrar mucha información referente a vSAN, y todas sus operaciones.) Se puede observar que no es capaz de hacer un «decomisioned» del objecto 4542a463-2edd-ed99-09d0-6805caf2d2fa.
Si nos fijamos tiene asignada la siguiente política.
Si volvemos al CLI del esxi y lanzamos el siguiente comando:
" esxcli vsan debug object list | grep -i 4542a463-2edd-ed99-09d0-6805caf2d2fa"
Podemos observar como el objeto tiene aplicado dentro del la «Storage Policy» el parámetro datastoreSpaceEfficiency con el valor «CompressionOnly«.
Solución
Para solucionar este problema acudí a la Storage Policy «vSAN_STORAGE_PROFILE_X», y si nos fijamos en la parte de «Space efficency» estaba activado la parte de «Compresion Only», esto que quiere decir.
Básicamente es como una regla «must» en la cual le hace indicar que los objetos que tengan asignados esta Storage Policy tiene que residir en un datastore vSAN donde la compresión este activada. Esto hace, que si tu quieres cambiar a otras de las opciones de ahorro de espacio, si encuentra algún objeto en el diskgroup que tenga esa Storage policy te fallara a la hora de la recreación del mismo.
Esto que acabamos de comentar me valió para ciertos objetos que residían en el clúster, pero por otro lado tenia objetos «Unknown», los cuales sino están vinculados a ningún elemento tales como un VM, Hard Disk, VM Name Space, etc no va a realizar el cambio de política. Entonces, ¿Cómo lo cambiamos?
Para poder cambiar la politica a los objetos «Unknown» basta con lanzar el siguente comando via CLI:
# /usr/lib/vmware/osfs/bin/objtool setPolicy -u "Objeto_vsan" -p "((\"hostFailuresToTolerate\" i1))"
Una vez lanzado el comando, vemos como ya no tiene asignada ninguna política como «tal». Basicamente le aplicado que tenga una tolerancia a un fallo.
Si nos vamos a la parte del CLI, veremos que ya ha desaparecido la parte «datastoreSpaceEfficiency«. Por lo tanto si pulsamos «Remediate Inconsistent Configuration» desde el «Skyline Health», ahora si la recreación de los 2 ultimos diskgroups sera satisfactoria.
Hasta aquí hemos llegado, espero que os sirva de ayuda y no os tires como yo buscando el problema unos cuantos días. Nos vemos en los siguentes post:)