Federico Cinalli

50 Preguntas y Respuestas sobre vSAN - Parte 3

Seguimos con la serie de Preguntas y Respuestas de vSAN y ya estamos en la tercera parte! Hoy toca avanzar con los niveles de Protección y algo de Diseño. 

 

21-Qué diferencia existe al trabajar con un RAID Controller en modo RAID y en modo Pass-through?
Un requerimiento extremadamente importante en vSAN es el RAID Controller. La controladora deberá estar en la HCL y tener la versión de Firmware soportado según la versión de vSphere/vSAN correspondiente.
Las controladores RAID (que en vSAN no se utilizar para configurar RAID) pueden trabajar en dos modos en un entorno vSAN: RAID o Pass-through (también llamado HBA mode).
Un RAID Controller en modo Pass-through presenta los discos de forma independiente como si se tratase de una LUN, aunque sin ningún nivel de protección. Ésta opción es la recomendada.
Si nuestra controladora no soporta el modo Pass-through (aunque esté en la vSAN HCL) es posible trabajar en modo RAID creando un RAID 0 por cada disco físico conectado, incluyendo los discos de Caché.
La diferencia es importante ya que en modo Pass-through el ESXi será capaz de supervisar el estado físico del disco y en caso de fallo solamente hay que reemplazar uno por otro en caliente.
En el caso de fallo de disco en una Controladora en modo RAID será necesario reiniciar el Host y acceder al BIOS de la RAID para eliminar el RAID 0 del disco que falló y crear un nuevo RAID 0 con el disco reemplazado. Como vemos esto impacta no solamente en los tiempos de Mantenimiento, posiblemente también en el SLA a la vez que no es para nada dinámico.
Por último merece la pena destacar que para cualquier Controladora que trabaje en vSAN, con independencia del modo de funcionamiento, se recomienda deshabilitar el Caché de escritura debido a que esa tarea la realizan los discos de Caché del propio vSAN dejando el 100% de Caché de la Controladora en modo Lectura.

 

22-Qué és un Fault Domain o Dominio de fallo?
vSAN Fault Domain nos permite incrementar la disponibilidad definiendo zonas de réplica. Éste sistema de protección está orientado a reducir el impacto en caso de fallo general a nivel de Rack (Alimentación, Cableado, Switching). Se define un mínimo de 3 Fault Domains y se agrega, al menos, un Host por cada Fault Domain. Una vez definidos y configurados los Fault Domains se comenzarán a distribuir las diferentes Réplicas entre los Hosts de los diferentes Racks, de igual forma con los Witness como si se tratase de una regla de Anti-Afinidad en DRS.
Las Réplicas se distribuirán de tal forma que, en caso de fallo de un Rack o Fault Domain, será posible continuar trabajando con las VMs utilizando las Réplicas existentes.

 

23-Puedo utilizar FT con vSAN?
Una VM que trabaje sobre un vSAN Datastore puede estar protegida con Fault Tolerance siempre y cuando el ámbito de trabajo sea el mismo Site (Site Local).
Esto significa que, al menos de momento, no está soportado Fault Tolerante en un entorno de vSAN Stretched Cluster debido a que los 5 ms de Latencia máxima soportada para Stretched Cluster son demasiados para una VM con SMP (Symetric Multi-Processor).
La buena noticia es que por más que tengamos configurado un entorno vSAN Stretched Cluster es posible, mediante las Políticas, configurar el nivel de Protección Local de la VM evitando que se replique entre los diferentes Sites. Esto lo hacemos definiendo la regla PFTT en 0 y SFTT en 1 o 2 dependiendo de los Hosts. Esto crea Réplicas de los Objetos de la VM solo en el Site Local.

 

24-Como se incrementa la capacidad en vSAN?
Los discos de Capacidad que forman parte de los Disks Groups son los que aportan capacidad al vSAN Datastore. Es posible agregar (y también quitar) en caliente discos de Capacidad a un Disk Group siempre y cuando no superemos el límite de 7.
Siempre que sea posible vamos a considerar disponer la misma cantidad, de la misma capacidad y la misma tecnología de discos en todos los Disks Groups de todos los Hosts del Cluster de vSAN aunque es posible tener configuraciones diferentes.
Una vez que agregamos un nuevo disco de Capacidad de forma automática se incrementará el espacio disponible en nuestro vSAN Datastore.

 

25-Qué requerimientos de Red exige vSAN para un correcto funcionamiento?
Depende del tipo de Cluster que vayamos a configurar.
Un Cluster de vSAN Híbrido puede trabajar con interfaces de 1GbE aunque se recomiendan interfaces de 10GbE.
En el caso del Cluster vSAN All-Flash se requieren interfaces de 10GbE.
La configuración de red para el Port Group de VMKernel de vSAN se define aprovisionando dos VMNics y estableciendo una configuración Active-StandBy. Esto quiere decir que la alta disponibilidad de los servicios de red de vSAN están gestionados por los Virtual Switches. Se recomienda el uso de vDS con NIOC definiendo valores de Shares y evitando establecer Reservas y Límites para gestionar la prioridad de cada Port Group en caso de contención de recursos de red.
La última versión de vSAN eliminó el requerimiento de configurar Multicast para las redes de vSAN.

 

26-Cuál es el número mínimo de Hosts para VSAN?
El número mínimo de Hosts para un Cluster de vSAN es 3. Desde vSAN 6.5 existe la posibilidad de desplegar lo que se conoce como un 2-Node vSAN Cluster, naturalmente configurado con 2 Hosts mas un Witness.
No obstante una cosa es el número mínimo de Hosts para configurar el Cluster y otra diferente el número mínimo de Hosts que se requieren según las Políticas a aplicar, incluyendo además la tecnología de protección requerida.
Aquí tenemos un ejemplo simple aunque no cubre todos los casos posibles:
RAID 1: 3 Hosts requeridos tolerando 1 Fallo (2 Hosts en un 2-Node Cluster + 1 Host Witness)
RAID 5: 4 Hosts requeridos tolerando 1 Fallo
RAID 6: 6 Hosts requeridos tolerando 2 Fallos

Existen más combinaciones entre números de fallos a tolerar, nivel de protección y las políticas PFTT y SFTT pero lo expuesto anteriormente es un ejemplo que nos servirá de introducción a la cantidad de recursos mínimos necesarios.

 

27-Qué es y cómo funciona el concepto de Object Ownership?
Por cada Objeto en vSAN se define un Owner o Propietario para tal objeto. El Owner de tal Objeto define quién ejecuta las operaciones de I/O del mismo para asegurar la consistencia.
El Owner a la vez es el encargado de comunicar al Component Manager cómo se puede acceder a tal Objeto (normalmente desde un cliente que es el ESXi).

 

28-Qué es Stretched Cluster?
Un vSAN Stretched Cluster es un sistema que permite replicar Objetos (y sus Componentes) entre dos Datacenters. Es como si tuviésemos un RAID 1 entre dos Datacenters activos pudiendo definir, a través de las políticas, cuál es el Datacenter en el que trabajará de forma “local” cada VM.
Para poder desplegar un vSAN Stretched Cluster necesitaremos 3 Datacenters. 2 Datacenters para Datos y 1 Datacenter para hostear el Witness que puede ser tanto físico como virtual. El Witness de Stretched Cluster funcionará de forma similar al componente Witness de las Réplicas como si fuera un Tie-Breaker.
Los requerimientos de vSAN Stretched Cluster, además de contar con 3 Sites, son los siguientes:
-Conectividad 10GbE entre los dos Datacenters de Datos. En un 2-Node Cluster es posible utilizar 1GbE con cable directo entre los Hosts.
-Latencia no superior a 5ms entre los dos Datacenters de Datos. Latencia de hasta 200ms entre los Hosts y el Witness.
-Mínimo de Hosts 1+1+1 (2 para Datos + 1 de Witness que puede ser virtual y además no consume licencia)
-Máximo de Hosts 15+15+1 (Hasta 15 Hosts de Datos en cada Site mas 1 de Witness)
-Instancia única de vCenter para gestionar todos los Hosts (puede estar protegido con vCenter HA entre los Sites)
-Comunicación L2 entre los Datacenters de Datos. Comunicación L2 o L3 entre los Hosts y el Witness.
-Licencia vSAN Enterprise o vSAN Enterprise for ROBO (para 2 Nodos + Witness)

 

29-Que diferencia hay entre SRM y vSAN Stretched Cluster?
VMware Site Recovery Manager es un sistema de Réplica y Orquestación orientado principalmente a Recuperación ante Desastres. También es posible utilizarlo para migrar Datacenters.
Como se explicó en la pregunta anterior vSAN Stretched Cluster está orientado a incrementar la disponibilidad de dos Datacenters activos gestionados por el mismo vCenter y replicando en modo RAID 1 utilizando la tecnología de vSAN.
La principal diferencia es que SRM puede trabajar tanto con vSphere Replication como motor de réplicas como también con sistemas de Réplicas propietarias de sistemas de almacenamiento como EMC, Netapp y similares. No tenemos la limitación de 5ms entre los Datacenters ni un ancho de banda específico aunque naturalmente los valores de RPO dependerán de los recursos existentes.
Para trabajar con SRM necesitamos un vCenter en cada Site y es posible definir procedimientos (orquestación) para la recuperación (cambios de IP, Scripts, prioridades, etc) así como también realizar simulaciones y aplicar un Failback si fuera necesario. No existe el concepto de Witness en SRM aunque el proceso de Failover es manual.
vSAN Stretched Cluster es principalmente el motor de Réplica entre los 2 Datacenters de Datos y la herramienta de recuperación a nivel de VMs entre los Hosts es un viejo conocido: vSphere HA.

 

30-Cómo se calcula el Almacenamiento disponible en un Cluster de vSAN?
Depende de si hablamos de Capacidad Bruta o Capacidad Neta.
En el caso de la capacidad bruta (RAW Capacity) de un vSAN Cluster es igual a la suma de todos los discos de Capacidad de todos Disks Groups de cada Nodo del Cluster. Fácil verdad?
No obstante basándonos en ese cálculo no llegamos a obtener o estimar la capacidad Neta. Haciendo una analogía con una cabina clásica sería igual a sumar la capacidad total de todos los discos y sabemos perfectamente que eso está muy alejado de la realidad.
La Capacidad Neta es variable ya que depende de múltiples factores. Por ejemplo una vez aplicada una política que requiere RAID 1 se crearán dos Réplicas (Componentes) de los Objetos de la VM mas un Witness. También impactan los ficheros Swap de las VMs (igual a la vRAM aprovisionada menos la reserva de memoria configurada) al igual que los Snapshots y sus correspondientes estados de memoria. Esto mismo hay que considerarlo con cada Objeto de cada VM del Cluster, incluso considerando que cada Política se puede modificar en tiempo real alterando la Capacidad Neta de ese momento.
A nivel de Diseño hay que considerar un 30% de espacio disponible para el Slack lo cual nos permite absorber el impacto de un Host en modo Mantenimiento, fallos en Disks Groups, Discos, etc.
Como vemos una cosa es el Diseño (la parte Lógica) y otra la realidad. Nuevamente merece la pena destacar lo importante de un buen diseño en un Cluster de vSAN para evitar sorpresas inesperadas.

 

Hasta aquí la tercera parte de la serie de Preguntas y Respuestas sobre vSAN. Como siempre espero que te resulte de utilidad. Aquí puedes ver el siguiente Post de la serie.

 

50 Preguntas y Respuestas sobre vSAN - Parte 2

vSAN FAQ 

 

En este segundo Post de la serie de vSAN continuamos con los conceptos, dudas comunes y funcionamiento de vSAN. En el primer Post de la serie hablamos de Hardware, Compatibilidad, Diseño y Funcionalidad entre otras cosas. Hoy toca hacer algo de foco en Caché, Grupos de Discos y conceptos en general. Algunos conceptos y funcionalidades importantes los ampliaremos a través de nuevas preguntas dentro de la misma serie.

 

11-Qué diferencia existe entre un Cluster Híbrido y uno All-Flash?
Un Cluster de vSAN Híbrido está compuesto por discos SSD para Caché y discos SAS o SATA para aportar Capacidad.
El vSAN Cluster All-Flash tiene discos SSD para Caché (también pueden ser NVMe) y los discos de Capacidad también son en tecnología Flash. El Cluster All-Flash requiere una conectividad de Red de 10GbE para la comunicación entre los Hosts y además dispone de las tecnologías de Compresión y Deduplicación las cuales se aplican en conjunto.
El funcionamiento de los discos de Caché es diferente en un Cluster Híbrido respecto al Cluster All-Flash como se explicará más adelante.
En un Cluster Híbrido las Políticas de Protección únicamente ofrecen RAID 1 mientras que en un Cluster All-Flash podemos, además de RAID 1, utilizar RAID 5 y/o RAID 6 (Erasure Coding), siempre dependiendo del número de Nodos.
Vale mencionar que para habilitar las funcionalidades de Compresión-Deduplicación y Erasure Coding (RAID 5 y RAID 6) es necesario que apliquemos la licencia Advanced al Cluster de vSAN.

 

12-Qué diferencia hay entre un Objeto, un Componente y un Witness?
En vSAN una Maquina Virtual está compuesta por hasta 5 tipos de Objetos:
VM home namespace / VMDKs / VM Swap / Discos Delta de Snapshots / Memoria de Snapshot
vSphere Web Client solo muestra 2 tipos de Objetos (VM home namespace y VMDKs) pero a nivel de línea de comandos podemos ver todos los Objetos de una VM.
Los componentes son el número de Réplicas que “componen” cada Objeto, basado siempre en las Políticas aplicadas. Las Políticas se asignan a cada Objeto de una VM, de forma que todos los Objetos de una VM pueden tener la misma Política o cada Objeto una Política diferente, según consideremos. Por ejemplo puedo aplicar una política a un VMDK de SO y otra política diferente a un segundo VMDK de Datos de la misma VM.
Un Witness es un componente que funciona a modo de Tie-Break y define la validez de un componente en caso de ausencia o fallo.
Dependiendo de la Política aplicada y el número de componentes podemos tener uno, varios o ningún Witness. La existencia y número de Witness lo define el sistema.

 

13-Qué es un Disk Group o Grupo de Discos?
Cada Host que aporta Almacenamiento en un Cluster de vSAN debe contar con, al menos, dos discos. Un disco para Caché y un disco de Capacidad. Un Grupo de Discos o Disk Group es un recurso de Almacenamiento compuesto por Capacidad y Caché. El Caché aporta rendimiento y el disco de Capacidad espacio disponible en el Datastore de vSAN.
Un Host puede tener un máximo de 5 Grupos de Discos. Cada Grupo de Discos debe tener un disco SSD para Caché (solo 1) y un mínimo de 1 Disco de Capacidad con un máximo de 7 Discos de Capacidad por Grupo de Discos.
Se recomienda contar con al menos dos Grupos de Discos por Host por cuestiones de Disponibilidad y Distribución de carga.

 

14-Qué diferencia hay entre un disco de Caché y uno de Capacidad?
Evidentemente los discos de Caché aportan rendimiento y los de Capacidad incrementan el espacio disponible en el Datastore de vSAN pero veamos un poco mas en detalle las diferencias.
El funcionamiento de los discos de Caché es diferente entre los dos tipos de Clusters ya que en el caso del Híbrido los discos de Caché operan en modo lectura y escritura. El objetivo principal de los discos de Caché en un Cluster All-Flash es incrementar la vida útil de los discos SSD de Capacidad. Los discos de Caché en All-Flash únicamente funcionan para las operaciones de Escritura.
Esto supone que en vSAN todas las operaciones de escritura son gestionadas en primera instancia por los discos de Caché que enviarán el ACK al Owner. Dependiendo del número de Réplicas y su distribución (ambas definidas en la Política asignada) esos bloques nuevos o modificados se escribirán en paralelo en dos o más discos de Caché para luego hacer el “Destage” y escribir los bloques en los Discos de Capacidad.
En el caso de un Cluster All-Flash con Compresión y Deduplicación habilitada se aplica la Deduplicación, Compresión y finalmente el Destage (movimiento de los bloques desde Caché hacia los discos de Capacidad) en ese orden.
Como comentario adicional merece la pena añadir que para el caso de un Cluster de vSAN All-Flash, en la fase de Diseño, se eligen diferentes Clases de discos SSD para Caché y para Capacidad según su TBW como se explicará más adelante.

 

15-Las maquinas virtuales siempre accederán a almacenamiento local?
No necesariamente. vSAN no aplica lo que se conoce como “Data Locality” como sí hacen otros sistemas de SDS similares. VMware considera que estar moviendo los componentes de la VM (VMDKs, Swaps, Logs, Snaps, etc) entre los Hosts para que la VM siempre trabaje en modo “local” accediendo al Almacenamiento genera una sobrecarga de trabajo innecesaria incrementando además la latencia de acceso al Almacenamiento para el resto de VMs durante estos procesos. A esto hay que sumarle la tarea de reconstruir los bloques y niveles de disponibilidad según las políticas aplicadas.
En entornos con DRS y con carga de trabajo variable es muy común ver cómo las VMs migran automáticamente de un Host a otro. Esta misma situación ocurriría en caso de caída del Host en donde están trabajando las VMs.

 

16-Qué significa TBW? 
Las siglas TBW significa Terabytes written o Terabytes escritos. El TBW es un valor o propiedad que los fabricantes de discos indican en cada modelo o serie para definir la durabilidad o cantidad de operaciones / TBs de escritura que soportan los discos SSD durante el período de garantía (normalmente 5 años) antes de que comiencen a dar fallos las celdas del disco.
Este valor incluye el DWPD (Operaciones de escritura por día) o PBW (Petabytes escritos).

En términos prácticos esto define, en vSAN, el tipo de disco que debemos aprovisionar para Caché (y Capacidad en All-Flash) dependiendo del número de operaciones de escritura que debe soportar nuestro Cluster.

La ecuación para obtener el valor de TBW es la siguiente:
TWB (a 5 años) = Tamaño del Disco x DWPD x 365 x 5
TBW = 0.4TB x 10DWPD x 365 días x 5 años
TBW = 7300TBW

 

17-Necesito Switches Distribuidos?
No es un requerimiento el uso de Switches Distribuidos para vSAN pero sí muy recomendable.
Especialmente en Infraestructuras HCI en donde normalmente tenemos solo 2 interfaces de 10GbE como recurso es ideal aplicar NIOC (Network IO Control) que únicamente está disponible en Switches Distribuidos.
Con NIOC podemos establecer Shares, Reservas y Límites para gestionar los recursos de red en Port Groups de VMKernel y Virtual Machine.
La buena noticia es que no importa qué versión de vSphere estemos utilizando ya que al aplicar cualquier licencia de vSAN nos desbloqueará el uso de Switches Distribuidos.
Hay una serie de Best Practices a la hora de definir los valores de Shares y las políticas de Balanceo y Alta Disponibilidad. Las podemos encontrar en la Guía de Diseño de Red de vSAN.

 

18-Puedo agregar un Host sin Almacenamiento local al Cluster de vSAN?
Una vez que cumplimos con el requerimiento mínimo de 3 Hosts (que aportan Almacenamiento) por Cluster es posible agregar Hosts adicionales al Cluster sin necesidad que aporten Almacenamiento.
Todos los Hosts que formen parte del Cluster van a tener acceso al Datastore de vSAN.
Naturalmente que no sería lo ideal ya que tanto la idea, el concepto, el objetivo de un entorno SDS (especialmente sobre una Infraestructura HCI) es aportar Computo, Red y Almacenamiento en todos los Nodos.
Además todo hay que decirlo, todos los Hosts que forman parte del Cluster de vSAN deben tener su licencia correspondiente, tanto de vSphere como también de vSAN.

 

19-Mi solución de Backup soporta VSAN?
Cualquier solución de Backup es agnóstica a un Almacenamiento en donde trabajen las VMs a copiar. Los Softwares de Backup que trabajan con vSphere lo hacen a través del vSphere Storage API Data Protection. vSAN no es la excepción y también trabaja con el API.
Esto supone que podemos seguir utilizando nuestra actual solución de Backup cuando creamos un nuevo Cluster de vSAN o bien cuando migramos nuestras maquinas a ese vSAN Cluster existente.

 

20-Tengo varios Clusters sobre un mismo vCenter, cómo se comparte VSAN en ese caso?
No se comparte. El Datastore de vSAN está disponible únicamente en los Hosts que son miembros del propio Cluster de vSAN.
Una vez que tenemos creado el Cluster de vSAN tendremos un único vSAN Datastore por Cluster, con independencia del número de Hosts (hasta un máximo de 64) y el número de Grupos de Discos (máximo 5 por cada Host).
vSAN 6.5 trajo entre sus novedades la posibilidad de compartir Almacenamiento iSCSI a través del Cluster de vSAN. Esta funcionalidad está orientada a servidores físicos y/o aplicaciones clusterizadas. La funcionalidad iSCSI de vSAN NO permite presentar este recurso a otros Hosts de ESXi ya sean miembros del mismo vCenter o de otro vCenter.

 

Hasta aquí otras 10 Preguntas y Respuestas de la serie, aquí podrás ver el Post de la parte 3 de la serie.

Como siempre espero que te resulte útil y si lo ves interesante te agradezco lo compartas. Cualquier comentario, corrección o pregunta será bien recibida en los comentarios del Post. 

Hasta el próximo Post!!!

50 Preguntas y Respuestas sobre vSAN - Parte 1

Virtual SAN

 

Éste es el primer Post de la serie de 50 Preguntas y Respuestas sobre VMware Virtual SAN. La solución de SDS de VMware viene creciendo de forma exponencial tanto en funcionalidades como en implementaciones y hay gran cantidad de conceptos, funcionalidades y buenas prácticas que merecen ser aclaradas. Comenzamos?

 

1-Qué diferencia hay entre el Almacenamiento Tradicional y vSAN?
El Almacenamiento tradicional está orientado a Bloques y/o Ficheros mientras que vSAN es un sistema de Almacenamiento orientado a Objetos.
Aunque los niveles de protección son similares (RAIDs, Réplicas, Snapshots, Etc) lo que difiere principalmente es el ámbito de protección y la forma de aprovisionar los recursos. Un sistema tradicional presenta sus recursos a través de LUNs y/o Carpetas y todo lo que se almacene en esos repositorios tendrán el mismo nivel de protección, además de disponer y gestionar los recursos de almacenamiento de forma centralizada.
En el caso de vSAN hablamos de un Almacenamiento distribuido entre los Hosts y un sistema de políticas de Protección/Rendimiento/Espacio que se aplican de forma individual a nivel de Objeto. Entendemos como Objeto componentes de Maquinas Virtuales como VMDKs, Snapshots y ficheros Swap entre otros.

2-Puedo utilizar un disco SSD de consumo?
Es especialmente recomendable en vSAN verificar que nuestro Hardware está incluido en la VMware HCL para la versión de vSAN que vamos a utilizar, independientemente si estamos hablando de un disco SSD para Caché o Capacidad como si también hacemos referencia a un disco SATA para Capacidad.
En el caso de los discos SSD la principal diferencia, además del precio, es la cantidad de operaciones de escritura que el fabricante nos asegura que podremos realizar durante el período de garantía del disco. A esto le llamamos “Endurance”.
Incluso hasta podemos encontrar discos SSD de consumo con un mayor número de IOPS pero con menor “Endurance”. Esto es especialmente importante en los discos de Caché.
Los discos SSD están clasificados por clases según prestaciones como IOPS y su Endurance.

3-Es vSAN una solución 100% para entornos Hyperconvergentes?
No necesariamente. Justamente una de las mejores características de vSAN es la flexibilidad a la hora de utilizar Infraestructura. Si bien hablamos que vSAN y un entorno Hyperconvergente (HCI) van como anillo al dedo también hay Infraestructuras de Hosts no Hyperconvergentes totalmente soportados en vSAN. Este último caso se suele aplicar cuando buscamos un crecimiento (Scale Up) importante a nivel de Almacenamiento, especialmente en capacidad, utilizando Hosts con soporte de hasta 40 discos.
Por otra parte podemos comentar que en el caso de los sistemas Blade, si bien se pueden soportar, no es precisamente la mejor solución.

4-Cuáles serían los casos de uso de vSAN?
Personalmente no creo que haya casos de uso específicos para vSAN. Tal vez tendríamos que analizarlo a la inversa, es decir en qué entornos tal vez vSAN no sea la opción mas eficiente.
Independientemente de la comparativa de costes entre vSAN y un entorno clásico (inevitable) debemos considerar si existe algún tipo de limitación ya sea a nivel de Hardware, Soporte o incluso una carga de trabajo específico que indique que vSAN no sea la opción mas eficiente.
Por otra parte hay requerimientos que podríamos decir que son ideales para soportar con una infraestructura de vSAN como pueden ser un Cluster de Management, una solución de VDI, un entorno de Recuperación ante desastres, una Infraestructura en la Nube o hasta incluso el soporte para aplicaciones de rendimiento crítico.
Rendimiento crítico? Si, con las “nuevas” soluciones NVMe sobre Infraestructuras vSAN hablamos de otro concepto a nivel de Ancho de banda, IOPS y sobre todo Latencia.

5-Qué sería lo más importante a considerar en un Proyecto de vSAN?
El Diseño, sin lugar a dudas. Una futura implementación sin su correspondiente análisis de capacidad, rendimiento, disponibilidad, crecimiento, infraestructura, selección y validación de hardware con su correspondiente configuración puede terminar (muy probablemente) en una solución ineficiente, con importantes falencias e incluso con un sobrecosto en licenciamiento.
Una vez implementado vSAN es extremadamente fácil de gestionar pero la fase de diseño y análisis es especialmente importante en vSAN y no debe pasarse por alto.

6-Qué niveles de disponibilidad hay disponibles en vSAN?
Los diferentes ámbitos de protección en vSAN son Host, Rack y Datacenter, éstos últimos distribuidos en múltiples Sites.
Por un lado tenemos redundancia a nivel de Red en cada Host miembro del Cluster de vSAN y vale recordar que vSAN trabaja a nivel de Cluster de HA.
En cuanto a los niveles de protección de datos dependen tanto de las Políticas de vSAN como también de los recursos disponibles. El número de Discos, Hosts, Datacenters, Latencia entre Sites y Ancho de banda definen la posibilidad de aplicar las Políticas de protección.
Las políticas de protección incluyen diferentes Réplicas (RAID 1, RAID 5 y 6) dentro del mismo Datacenter y Réplicas (RAID 1) entre Datacenters. También es posible aplicar zonas de réplica entre Racks del mismo Datacenter así como también desplegar un 2-Node Cluster basado en Réplicas que aplican nivel de protección RAID 1.

7-Puedo reutilizar mi Hardware para desplegar vSAN?
La respuesta depende de qué Hardware estemos hablando. vSAN es muy estricto en cuanto al Hardware requerido, especialmente en Controladoras RAID y Discos. Si el Hardware figura en la vSAN HCL para la versión que se pretende implementar entonces no habrá ningún problema.
Debemos considerar además que en una Infraestructura Hyperconvergente es particularmente valioso un correcto análisis con su sizing correspondiente. Con esto evitamos situaciones como Host descompensados en algún recurso (CPU, RAM y/o Almacenamiento) lo cual muchas veces se torna realmente difícil solventar, y a esto hay que agregarle un posible sobrecoste en licenciamiento por un Análisis, Sizing y Diseño ineficiente sin contar límites en el crecimiento y déficit en Alta Disponibilidad.

8-Sobre qué instalamos ESXi en una Infraestructura vSAN?
Normalmente utilizamos tarjetas SD, dispositivos USB o discos SATADOM. Últimamente los fabricantes de Hardware ofrecen sistemas de alta disponibilidad para tarjetas SD.
Lo que tenemos que considerar es que independientemente del medio que utilicemos para almacenar los binarios del ESXi, una vez que termina el proceso de carga del SO se levantan todos los binarios a memoria. Esto supone que no afecta al rendimiento y no es necesario utilizar grandes recursos para permitir el boot del ESXi dejando los discos SSD/SAS únicamente para Caché y Capacidad en un entorno vSAN.
Aunque debemos considerar que para Hosts de hasta 512GB de RAM podemos utilizar dispositivos USB o SD. En Hosts con RAM superior a 512GB tenemos que utilizar discos SATADOM.

9-Cómo puede escalar en Almacenamiento?
En vSAN se puede crecer de forma Vertical (Scale Up) u Horizontal (Scale Out). Todo depende de lo que se necesite y de los recursos (Infraestructura) que se disponga.
Un Host de vSAN puede soportar hasta 5 Grupos de Discos. Cada Grupo de Discos puede aprovisionarse con hasta 7 Discos de Capacidad. Esto supone que un Host de vSAN puede llegar a tener un máximo de 35 Discos de Capacidad repartidos en 5 Grupos de Discos, cada uno con 1 Disco de Caché y hasta 7 de Capacidad.
Es posible agregar en caliente discos de Capacidad a Grupos de discos existententes así como también Hosts adicionales, que aporten Almacenamiento, a Clusters de vSAN en Producción.
Un Cluster de vSAN puede estar configurado con hasta 64 Hosts. Esto supone un número importante de recursos tanto de Computo como también de Almacenamiento.

10-Qué pasa con el Datastore de VSAN si cae el servicio de vCenter?
Las maquinas virtuales seguirán trabajando sin problemas aunque no se podrán modificar Políticas de vSAN ni cambiar configuraciones hasta que el servicio de vCenter esté operativo nuevamente.
La caída de vCenter no impacta en la disponibilidad ni continuidad de las Maquinas Virtuales pero sí a la gestión del Cluster de vSAN.

 

Hasta aquí las primeras 10 de un total de 50 preguntas sobre vSAN. Siguiente Post -> 50 preguntas y respuestas sobre vSAN - Parte 2.

Como siempre espero que te resulte de utilidad y te invito a que lo compartas y comentes o bien sugieras mas preguntas.

Hasta el próximo Post!!!

 

 

Nos vemos en el VMworld 2017

VMworld 2017

 

Para los que trabajamos con esta tecnología hay dos semanas marcadas a fuego en el calendario. El VMworld de USA y el de Europa. Este año prácticamente no vamos a tener descanso entre uno y otro, lo cual no sé hasta qué punto puede ser positivo desde el punto de vista de novedades.

Particularmente este año vengo con mucha carga de trabajo y muchísimos viajes, razón por la cual estoy escribiendo menos en este Blog, pero pude hacerme hueco para poder asistir a ambos eventos.
Agradezco a Adistec el poder asistir al VMworld de Las Vegas y al departamento de prensa de VMware España (Gracias Nacho!) la invitación al evento de Barcelona y su correspondiente conferencia de prensa.

Qué podemos esperar de un VMworld?
Personalmente creo que lo mejor, con diferencia, es el networking. La posibilidad de desvirtualizar a tanta gente con la que interactuamos a través de las redes sociales y poder ponerle cara es más que interesante.
Siempre es muy enriquecedor poder conocer gente tanto a la que uno admira como también a tantos otros que tal vez ni conocemos. Es el momento y el lugar adecuado.

Ni que hablar de que es “la semana” en la que te encontras con amigos y bloggers, en ese orden. Son los mismos, pero en mi caso tengo la suerte de haber podido conocer gente maravillosa dentro del mundo blogger que los sigo como profesionales y los aprecio como amigos.

Además del networking es el momento de los anuncios. Está claro que este año vendrá con muchas novedades en la plataforma Cloud Foundation y su integración con AWS, además de mejoras destacables en VSAN y NSX. Falta poco para conocer esas novedades.

También están las sesiones técnicas y los HOLs. Existe una gran cantidad de sesiones, para todos los gustos y niveles, que nos dan la oportunidad de escuchar de primera mano y en detalle lo ultimo en las diferentes tecnologías del stack de VMware y su ecosistema.
En mi caso me suelen gustar mucho los stands de los fabricantes ya que, a diferencia de otros eventos mas comerciales, solemos encontrar profesionales que realmente saben. Y en caso de que no conocer la respuesta siempre tienen alguien a mano a quien consultar. Es una maravilla.

Mis primeras sesiones en el VMworld

Sesion Federico Cinalli en VMworld 2017

 

Este año tuve la suerte de que me aceptaran exponer tanto en Las Vegas como también en Barcelona. Serán sesiones breves pero intensas!!!
El título de las sesiones es “Full NSX with vRA and vRO” y trata del apasionante mundo de NSX on demand.

La primera sesion en Las Vegas sera el Miercoles 30 a las 13:00hs con el código #VMTN6621U. La sesion sera en el VMVillage.

La segunda sesion sera en Barcelona, el Miercoles 13 a las 16:15 con el código de sesion #VMTN6726E.

Las sesiones seran emitidas en streaming en el canal de VMTN Homepage pero si estás en cualquiera de los dos eventos sería un gran momento para ponernos cara. Será un placer para mí poder conocernos o vernos nuevamente.

Espero disponer de tiempo durante los eventos para escribir unas líneas y compartir las novedades que nos presentarán. Especialmente los eventos nocturnos!!!

Nos vemos en el VMworld!!!

 

Lo mejor de VeeamON 2017

VeeamOn Madrid

 

El próximo 14 de Junio en Madrid llega un VeeamON 2017 repleto de novedades. Es de esos eventos que uno no puede permitir perderse. En mi caso lamentablemente no voy a poder asistir debido a un proyecto en el que estoy participando fuera de España estas dos semanas pero aquí te dejo toda la información destacada.

Los expertos de Veeam® proporcionarán las últimas novedades de las soluciones de Veeam y las tendencias de la industria de la virtualización. Será posible conversar con otros profesionales de TI mano a mano. Todo para descubrir las últimas novedades de Veeam Availability de primera mano.

 

Agenda

  • Un avance sobre el NUEVO Veeam Availability Suite v10y otras noticias exclusivas traídas del evento más importante del año VeeamON 2017 en Nueva Orleans
  • Interesantes debates con profesionales del sector y expertos en el negocio de la virtualizaciónque están detrás de las tendencias que dan forma a la industria en 2017 y en el futuro
  • Otras oportunidades de networking para que descubra y experimente Availabilitycomo nunca antes

Registro

Registro VeeamON Madrid

 

No dejes de registrarte en este link !!!

 

PROGRAMA

09:30

Café de bienvenida

10:00

Introducción: La importancia de la Disponibilidad en la Transformación Digital: 
Jorge Vázquez, Country Manager Veeam Iberia

10:15

The Next Big Thing: Veeam Availability Suite 
Alexis de Pablos, System Engineer de Veeam Iberia

11:00

La nube transforma las reglas 
Stéphane Berthaud, Regional Presales Manager SEMEA

11:30

Café

12:00

Caso Práctico: MAPFRE Re
Ramón Vallejo Díaz, Subdirector, Area de Tecnologias

12.30

HPE+VEEAM: la solución de la disponibilidad
Maribel Rodriguez, Jefe de producto de almacenamiento, HPE

13:00

1+1= 3 NetApp + Veeam. Mejor juntos

13.30

Alianza

14:00

Cierre 
Jorge Vázquez, Country Manager Veeam Iberia

14:15

Cóctel

15:15

Visita guiada al Museo Reina Sofía
(incluye exposición Picasso)

 

Speakers:

Speakers VeeamON Madrid

Jorge Vázquez - Country Manager España y Portugal, Veeam Software

Alexis de Pablos - System Engineer España y Portugal, Veeam Software

Stéphane Berthaud - Regional Presales Manager SEMEA, Veeam Software

Maribel Rodriguez - Jefe de producto de almacenamiento, HPE

 

Patrocinadores VeeamON Madrid

Extendiendo vCenter con vRealize Orchestrator 7

Probablemente vRealize Ochestrator sea uno de los productos menos conocidos y utilizados del portfolio de VMware a pesar de su tremenda versatilidad y que viene licenciado con vCenter.

En este Post veremos lo fácil que es un despliegue y configuración de vRO.
Vamos a ejecutar la configuración inicial con el nuevo asistente de vRO 7.3, y la integración con vCenter tanto para la autenticación como también para extender el vSphere Web Client con vRO. Básicamente poder ejecutar Workflows directamente desde vSphere Web Client. 

Vembu

Backup & Disaster Recovery market is huge and sophisticated than it is actually conceived to be. What really matters in case of disruption of business continuity and unprecedented disasters  is a reliable and scalable solution which has a simple interface, military grade security, hybrid deployment options, easier recovery options and many such parameters which will keep the business operations intact, no matter what. Also, small & medium businesses have a steady challenge of scaling up their IT requirements while keeping their IT costs in check. Apparently, a datacenter might have multiple backup requirements, be it virtualized, physical or legacy or needing hybrid deployment options as well. For all the aforementioned requirements, Vembu BDR Suite serves the purpose to be one of the most comprehensive, simple and affordable backup & disaster recovery solutions for the small & medium businesses. Vembu can backup VMware vSphere, Microsoft Hyper-V, Physical Servers, Workstations, Exchange Items, SharePoint Items, SQL Items, Office365, G Suite, etc. – and they can back that up on-site, off-site, or even to the cloud – not to mention that most of this is done within a single UI. Aside from the BDR Suite, Vembu offers a wide variety of products such as a monitoring solution to centralize the monitoring of all of your backups as well as some which are absolutely free such as Desktop/Laptop Image Backup and the Vembu Universal Explorer for discovering application items within Microsoft apps. It is important to note that Vembu BDR Suite is offered as a single edition software for all businesses unlike other backup vendors who provide editions with limitations based on the type of businesses. Vembu has come up with its own free edition of Vembu BDR Suite by which users can backup unlimited VMs with minimal feature restrictions.

The different products under Vembu BDR Suite are categorized on the basis of environments:

For Virtualized environments like VMware vSphere and Microsoft Hyper-V:

Vembu VMBackup, part of Vembu BDR Suite provides reliable, efficient, agentless VMware vSphere and Microsoft Hyper-V backups for small and medium businesses with enterprise level features at affordable pricing. With Round-the-clock Business Availability as its sole aim, Vembu VMBackup provides faster recovery options which ensures that the business continuity is not disrupted. With VM Replication for High Availability, Vembu CBT Driver for high performance incremental backups, VSS aware technology for application consistency, Automated Backup Verification, VembuHIVE File System, a File System of File Systems for efficient backup storage, Multiple migration options, Flexible & Configurable Retention Policies, Vembu VMBackup is tailor made for all Backup & DR requirements of a complete virtual DataCenter. Also to empower small businesses to have business continuity, Vembu provides 50% discount on Vembu VMBackup for small businesses having upto 6 CPU-Sockets

For Windows IT environments:

Vembu ImageBackup, part of Vembu BDR Suite is a complete backup and disaster recovery solution for Windows IT environments. It provides an option to do entire system level backup or specific file level backup in Windows Servers and workstations. It also ensures RTO less than 15 minutes by delivering reliable recovery options like Bare Metal Recovery, Quick VM Recovery, Instant File Recovery, Partition level Recovery etc. Furthermore, Desktops/Laptops Backup is completely free.

For Applications, File Servers, Endpoints:

Vembu NetworkBackup, part of Vembu BDR Suite is designed for small medium businesses to protect business data across file servers, application servers, workstations and other endpoints. With NetworkBackup businesses can backup all their systems to a central location which is easier to manage.

Vembu OnlineBackup, part of Vembu BDR Suite provides File Server, MS Exchange, MS SQL, MS SharePoint & MS Outlook Backups directly to Vembu’s secure cloud using enterprise-grade AES 256-bit encryption with granular restores.

For SaaS applications like Microsoft Office365 and G Suite:


Vembu SaaSBackup, part of Vembu BDR Suite is designed for backing up the Mails, Drives, Calendar and Contacts of Office 365 and Google Apps. Vembu SaaSBackup’s core system will manage all backup and restore operations as per the user request. The backup data will be sent to the Vembu Cloud storage over secured network.

Suscribirse a este canal RSS

Mis Partners