50 Preguntas y Respuestas sobre vSAN - Parte 4

vSAN Policies

 

En este cuarto Post de la serie de vSAN nos centraremos en las Virtual Machine Storage Policies. No es posible entender cómo trabaja vSAN si no comprendemos las Políticas. Naturalmente que cada vSAN Policy merece como mínimo un Post pero no es la naturaleza de esta serie la profundización. Ahí vamos!!!

 

31-Diferencia entre FTT, PFTT y SFTT?
Hasta la versión de vSAN 6.5 existía la política FTT (Failures to Tolerate) que definía el número de fallos a tolerar, como pérdida de Host o Disk Group. A partir de vSAN 6.6 se renombró esta política para afinar aún mas la protección en entornos vSAN Stretched Cluster utilizando PFTT en lugar de FTT y agregando la nueva Política SFTT. De esta forma entendemos porqué FTT aparece en alguna documentación y también la razón de que aparezca PFTT y SFTT (nueva Política) sin que hubiera ninguna mención a FTT en el mismo documento o Post.

PFTT (Primary Failures to Tolerate) indica el número de fallos en Hosts o Disk Groups con un valor por defecto de 1 y un valor máximo de 3.
En un entorno con vSAN Stretched Cluster PFTT define la Réplica a aplicar entre los Sites con un valor de 1 -> PFTT=1 que equivale a un RAID 1 entre los Objetos protegidos entre los 2 Sites a los que se les haya aplicado esta política. En vSAN Stretched Cluster PFTT puede, únicamente, estar configurado con valores de 0 o 1 cuando 0 equivale a que no queremos proteger ese Objeto entre los Sites.

Qué ocurre entonces con PFTT cuando no tenemos Stretched Cluster configurado? En esa situación configuramos la política con valores entre 0 y 3 definiendo los fallos a tolerar en nuestro único Site.

Está muy bien pero y ahora para qué sirve SFTT? SFTT aparece disponible para configurar únicamente cuando tenemos Stretched Cluster habilitado. Como mencionamos anteriormente PFTT, con vSAN SC, definimos el nivel de Protección entre Sites y con SFTT definimos el nivel de Protección local del Objeto.

Veamoslo mejor con ejemplos.
Ejemplo 1: Quiero proteger una VM y sus Objetos con vSAN SC y tolerar 2 fallos en el Site Local: PFTT=1 SFTT=2
Ejemplo 2: Tengo una VM que no quiero protegerla con vSAN SC y necesito tolerar 1 fallo en el Site Local: PFTT=0 SFTT=1
Ejemplo 3: Disponemos de un entorno sin vSAN Stretched Cluster configurado y queremos proteger el Objeto ante 2 fallos: PFTT=2

 

 

32-Cuál es el objetivo del concepto Site Affinity?
Cuando habilitamos vSAN Stretched Cluster creamos dos Sites con Hosts: Preferred y Secondary, además del Witness. Hay infraestructuras en las cuales ambos Sites están totalmente operativos en Producción y otras en las cuales únicamente tenemos un Site en Producción (Preferred) y el Site secundario simplemente como Réplica.
A través de la Política Site Affinity tenemos la posibilidad de asignar un Site a una VM/Objetos para que trabaje de forma “local” reduciendo además la latencia y el consumo de ancho de banda.

 

33-Por qué la Política Number of Disks Stripes Per Object no tiene sentido en un Cluster de vSAN All Flash?

Esta política define el número discos de Capacidad entre los cuales estará repartida cada Réplica pudiendo establecer un valor mínimo de 1 (valor por defecto) y un máximo de 12.
En vSAN Hybrid podría llegar a tener sentido para obtener un mayor número de IOPS al utilizar múltiples discos de Capacidad de forma simultánea aunque con su correspondiente incremento de consumo de recursos. Únicamente se aplica a los Objetos de VMs criticas.

En un Cluster de vSAN All-Flash los discos SSD de Capacidad son los que responden todas las operaciones de lectura y normalmente disponen de IOPS más que suficientes como para no necesitar crear Stripes adicionales. Es por eso que esta Política tiene un valor por defecto de 1.

 

34-Cuáles son las opciones de la Política vSAN Failure Tolerance Method?
Básicamente tenemos dos opciones con diferentes parámetros disponibles para definir el método de Replicación a utilizar. Estas opciones impactan tanto en el rendimiento como también en la capacidad del Datastore de vSAN.
Los métodos de protección son RAID 1 (Mirroring) y RAID 5/6 (Erasure Coding). La opción RAID 5/6 únicamente está disponible en un Cluster de vSAN All-Flash y viene acompañada por la Política PFTT con opciones 1 y 2.
Una Política Failure Tolerance Method configurada para utilizar RAID 1 vendrá acompañada con la Política PFTT con valores 0, 1 y 2 que define el número de Fallos a Tolerar y, evidentemente, el número de Replicas a generar. Recordemos que PFTT en vSAN Stretched Cluster únicamente tendrá como opciones 0 y 1. Esta Política consumirá mas espacio aunque no penalizará tanto en Rendimiento como RAID 5 o 6.
En el caso de la misma Política configurada para utilizar RAID 5/6 puede tener como opciones en PFTT 1 o 2 siendo las Replicas RAID 5 o RAID 6 respectivamente. Esta Política consumirá menos espacio pero debido al calculo y gestión de la distribución de los bloques de disco no tendrá el mismo rendimiento que un RAID 1.

Es muy importante destacar que todas estas configuraciones estarán disponibles únicamente en el caso de disponer del número de Hosts que requiera cada combinación de Políticas y valores.

 

35-Política vSAN Flash Reservation
La Política permite definir un porcentaje del Objeto VMDK que será reservado en el Caché de vSAN. Esto se aplica únicamente en Clusters Híbridos orientado a mejorar el Rendimiento. No solamente no debemos abusar de esta Política sino que, además de utilizarla únicamente en Clusters Híbridos, está orientada solamente a VMs críticas en cuanto a rendimiento.
Esta Política no aplica en un Cluster de vSAN All-Flash por razones obvias ya que todas las operaciones de Escritura y Lectura son gestionadas por discos Flash y no tiene ningún sentido aplicar esta Política en ese tipo de Cluster.

 

36-Política vSAN Force Provisioning
Existen situaciones en que desplegamos una nueva VM y le asignamos una Política determinada. Como mencionamos varias veces las Políticas y sus opciones necesitan de ciertos recursos (requerimientos) para poder ser cumplidas. Puede darse el caso que tengamos algún Host en modo Mantenimiento, un Host o un Disk Group caído. En todos esos casos el estado de cumplimiento para aplicar esa Política en concreto será Non-Compliant.
Por defecto si estamos en un estado Non-Compliant no se desplegará la nueva VM o bien no se aplicará la Política que queremos asignar al Objeto en cuestión.
La Política Force Provisioning (con valor No por defecto) puede configurarse en Yes y nos permitirá desplegar la VM o bien asignar la Política a un Objeto por más que estemos en modo Non-Compliant.

Esta configuración únicamente se recomienda en caso que tengamos la total certeza de que recuperaremos rápidamente el Host o el Disk Group.

 

37-Qué utilidad tiene la Política IOPS limit for object?
El caso de uso dependerá siempre del administrador pero claramente está orientada a establecer un límite en las operaciones tanto de Lectura como también de Escritura.
Esta Política no considera los aciertos en Caché, únicamente contabiliza y limita las operaciones en los discos de Capacidad. vSAN por defecto no aplica ningún límite de IOPS.

 

38-Qué es y cómo funciona la Política Disable object Checksum?
El valor por defecto de esta política es NO y significa que, por defecto, todos los objetos ejecutan una validación de integridad de datos. Configurar la Política en Yes deshabilitará la validación de la integridad de datos con su consecuente ahorro de recursos y mejora en rendimiento aunque con el riesgo de que nuestros datos no tengan la integridad correspondiente. Se recomienda dejar el valor por defecto.

 

39-Cómo se aplica la Política Object Space Reservation?
Por defecto todos los Objetos en vSAN se crean en formato Thin Provisioning. Si bien es posible con la Política Object Space Reservation crear una reserva de espacio para Objetos de VMs críticas en cuanto a disponibilidad eso no supone que cambiará el formato. La política puede estar configurada en 0% (por defecto) o en 100%. Con una política configurada en 100% se creará una reserva en el Datastore de vSAN (se reducirá el espacio disponible) por el espacio aprovisionado en los Objetos afectados por la Política. Se recomienda nunca cambiar este valor en la Política por Defecto.

 

40-Cuáles son las opciones por defecto en la vSAN Default Storage Policy?
Ahora que estamos familiarizados con las Políticas de vSAN ya podemos analizar las opciones por defecto de la vSAN Default Storage Policy. Lo importante de esto es que si creamos cualquier Política adicional y no definimos alguna opción en concreto, en ese caso se utilizarán los valores de la Política por defecto cuando sea necesario.

vSAN 6.6 Default Policy

 

Podemos ver que hay un nivel de protección RAID 1 con un PFTT=1 sin forzar el aprovisionamiento en caso de estado Non-Compliant y finalmente sin reserva de Caché ni reserva de espacio en disco.

 

Como siempre espero que te haya resultado de utilidad y cualquier duda me dejas un comentario. Nos vemos en el próximo y último Post de la serie!!!

 

 

Deja un comentario

Muchas gracias por tus comentarios!!
Tras la revisión rutinaria, será publicado.

Utilizamos cookies propias y de terceros para facilitar y mejorar nuestros servicios. Al navegar por nuestra página web aceptas nuestras cookies.

Para más información, o para conocer cómo cambiar la configuración, lee nuestra Política de cookies. Saber más

Acepto

Mis Partners