Mi Experiencia Como Veeam Vaguard & Veeam Legends

Les cuento un poco de mi, Soy Esteban Prieto vivo en Argentina – Buenos Aires, actualmente trabajo como System Engineer en VMware, soy Veeam Vanguard 2019/21 Class 💯 y Veeam Legend First Class 2021 👨‍🎓.

La imagen tiene un atributo ALT vacío; su nombre de archivo es img_4263.jpeg

Lo primero que descubrí siendo parte de las 2 comunidades mas importantes de tecnología, es que el éxito de cada una de ellas se debe a la pasión de quienes las componen, y ese es un gran diferencial. Personas que viven en distintas partes del mundo, otras culturas, todos apasionados y dispuestos a participar en las distintas actividades durante el año. Dos increíbles personas se encargan de unir a estos paises a pesar de la distancia fisica, Nikola Pejkova por parte de Veeam Vanguard y Kseniya Zvereva por parte de Veeam Legends, sumando a Rick Vanover como gran impulsor y a quien tuve el placer de conocer.

Voy a destacar mi experiencia en el año 2019, en el Vanguard Summit en Praga 🏰 , donde nos reunimos todos juntos: estuvo el equipo de Veeam Product Strategy acompañado también con miembros del equipo de R&D toda una semana en Praga junto con Vanguards de todo el mundo 🌎 para compartir las últimas actualizaciones del lanzamiento de la v10 VB&R, lo cual fue super divertido y ¡todos lo pasamos increíble! 🕺

Ahora desde el COVID, hacemos reuniones semanales regulares en el calendario, es la llamada “Veeam Vanguard Social” 🤓

La experencia del SWAG 🎁 es fantástica y cada año se superan. Se preocupan mucho por mantenernos contentos

Este año se lanzó la ya exitosa y nueva comunidad de Veeam Legends 🎸🏆 (https://community.veeam.com)

Aquí mantenemos conversaciones y nos brindan a los usuarios un lugar único donde podemos compartir las mejores prácticas, participar en Veeam User Groups, crecer como profesionales de Veeam, completando capacitaciónes gratuitas bajo demanda a través de Veeam University y divertirse, hay reconocimientos y recompensas. Los invito a todos a unirse, donde cada granito que aportan les suma puntos para convertirse en un nuevo Veeam Legends !!

En ambas comunidades nos tienen muy encuenta y podemos influir en el desarrollo de productos y soluciones de Veeam: ¡tenemos un impacto real dentro de la comunidad!

En cada proyecto de nuevas versiones nos hacen parte y para el lanzamiento de la gran V11 de Veeam Backup & Replication tuvimos acceso a todos los betas, dando nuestro feedback de cada feature nuevo. Esto nos motiva aún mas para dar a conocer y promover a todos los clientes de Veeam cada mejora que obtendran.

Para finalizar agrego otros beneficios que tenemos por ser parte de los programas:

  • Una invitación al grupo privado Veeam Legends / Vanguard
  • Permiso para usar el logotipo de Veeam Legends/Vanguard en tarjetas, sitio web, etc. durante un año
  • Seminarios web privados con socios de Veeam
  • Acceso a NFR, betas privadas y sesiones informativas previas al lanzamiento
  • Acceso a los equipos de productos de Veeam

Cuando hago un review de todo lo que transité estos años con Veeam no puedo dejar afuera a cada uno que aporto un poquito para impulsarme a llegar hasta aquí. Gracias a toda la oficina de Veeam Argentina, en espacial a Ailin Puy y a Sara Wilson, me hacen sentir siempre uno mas. Mi mejor experiencia es seguir conociendo personas espectaculares.

VBR v11 🔥 Como trabaja CDP con Retention Policies

CDP – Retention Policies

Una política de retención define durante cuánto tiempo Veeam Backup & Replication debe almacenar los puntos de restauración para las réplicas de VM. Veeam Backup & Replication ofrece dos esquemas de políticas de retención:

:bulbo:Retención a largo plazo

Veeam Backup & Replication conserva los puntos de restauración a largo plazo durante el número de días especificado en la configuración de la política de CDP . Cuando se excede el período de retención, Veeam Backup & Replication transforma la cadena de replicación de la siguiente manera. El ejemplo muestra cómo funciona la retención a largo plazo para una réplica de VM con un disco virtual.

  1. Veeam Backup & Replication comprueba si la cadena de replicación contiene puntos de restauración a largo plazo obsoletos.
  2. Si existe un punto de restauración desactualizado, Veeam Backup & Replication reconstruye el archivo que contiene datos para el disco base ( <disk_name> – flat.vmdk) para incluir datos del archivo que contiene datos para el disco delta ( <disk_name> <index > .vmdk). Para hacer eso, Veeam Backup & Replication se compromete en los datos del archivo del disco base desde el archivo delta disk más antiguo. De esta manera, el archivo del disco base ‘avanza’ en la cadena de replicación

3. Veeam Backup & Replication elimina el archivo de disco delta más antiguo de la cadena como redundante; estos datos ya se han incluido en el archivo de disco base.

Políticas de retención

: triangular_flag_on_post:Retención a corto plazo

Veeam Backup & Replication conserva los puntos de restauración a corto plazo durante el número de horas especificado en la configuración de la política de CDP . Cuando se excede el período de retención, Veeam Backup & Replication transforma la cadena de replicación de la siguiente manera. El ejemplo muestra cómo funciona la retención a corto plazo para una réplica de VM con un disco virtual.

  1. Veeam Backup & Replication comprueba si la cadena de replicación contiene puntos de restauración a corto plazo obsoletos.
  2. Si existe un punto de restauración desactualizado, Veeam Backup & Replication envía los datos del punto de restauración desde el archivo de registro de transacciones (.tlog) al archivo de disco base o delta más cercano ( <nombre_disco> – flat.vmdk o <nombre_disco> <índice> .vmdk).
  3. Si el archivo de registro de transacciones no contiene datos para otros puntos de restauración, Veeam Backup & Replication elimina el archivo de registro de transacciones como redundante; sus datos ya se han comprometido en el archivo de disco base o delta.
NOTA
Veeam Backup & Replication puede almacenar puntos de restauración a corto plazo durante un período más largo que el especificado en la política de retención a corto plazo.
Abiertas las nominaciones a Veeam Vanguard 2018! | Tecnologias Aplicadas

Overview Veeam Legends 🦁

Hoy tengo la felicidad que me han elegido para el programa de Veeam Legends, una gran forma de compartir ideas, dudas, y conocimiento tecnico de Veeam. Un honor seguir contribuyendo desde las dos comunidades Veeam Legends y Veeam Vanguard !!

Les doy una descripción general del programa.

Quiénes son Veeam Legends?

Veeam Legends son usuarios de Veeam y expertos en la industria de protección de datos que sienten pasión por la tecnología, la innovación y están ansiosos por desarrollar aún más su carrera, mientras comparten sus experiencias con la comunidad. Como usuarios ávidos de Veeam, participan en varios proyectos comunitarios, impulsan los locales de grupos de usuarios Veeam y también pueden influir en el desarrollo de productos y soluciones de Veeam: ¡tienen un impacto real dentro de la comunidad! Aparte de eso, Veeam Legends siempre está ansioso por ayudar a sus compañeros y conectarse con otros miembros de la comunidad.

¿Cómo me convierto en Veeam Legend?

Únase al Centro de recursos de la comunidad de Veeam y participe en los proyectos de la comunidad de Veeam: ya sea que tenga muchas ideas de productos o si es un creador de contenido fructífero , ¡nuestro sistema de recompensas lo cuenta todo! Recibirá puntos e insignias por diferentes actividades dentro del Veeam Community Resource Hub, así que observe su perfil. Veeam Legends se anunciará al final de cada año. ¿Sigues aquí? ¡Anímate y comienza tu viaje ahora!

¿Qué se necesita para ser Veeam Legend?

Apreciamos a todos los colaboradores de la comunidad y realmente creemos en el poder de la comunidad. Esperamos que Veeam Legend contribuya constantemente a la comunidad técnica y siga expresando su pasión por nuestros productos con ellos para conservar su título de Veeam Legend. Los puntos se restablecen anualmente para todos los niveles, pero las insignias y rangos permanecen.

Beneficios del programa Veeam Legends:

  • Una invitación al grupo privado Veeam Legends
  • Permiso para usar el logotipo de Veeam Legends en tarjetas, sitio web, etc. durante un año
  • Seminarios web privados con socios de Veeam
  • Acceso a NFR, betas privadas y sesiones informativas previas al lanzamiento
  • Acceso a los equipos de productos de Veeam
  • Destacado en un directorio en línea público de Veeam Legends
  • Botín de Veeam Legends

¿Cómo puedo realizar un seguimiento de mi estado y logros?

Para realizar un seguimiento de sus logros, esté atento a su perfil: verá la cantidad de puntos e insignias obtenidos. La tabla de clasificación le mostrará los miembros de la comunidad más proactivos de todos los tiempos y semanalmente.

Descripción general del sistema de recompensas

Estos son los principios clave del sistema de recompensas de Veeam Legends:

  • El sistema de recompensas consta de puntos, insignias, rangos y clasificación.
  • Veeam Legend es una designación dentro del programa
  • Veeam Legends debería ofrecer cierto nivel de contribución por mes para mantener el título
  • Los puntos se restablecen anualmente para los niveles; Quedan insignias y rangos

Código de conducta de Veeam Legends

La comunidad es lo primero: siempre hemos puesto a la comunidad de Veeam en primer lugar en todo lo que hacemos. Nos gustaría que Veeam Legends fuera una continuación de los valores y creencias de Veeam al comportarse con respeto al interactuar con cualquier persona dentro y fuera de la comunidad.

Aquí hay algunas reglas de la casa que esperamos seguir para asegurarnos de que este espacio siga siendo amigable:

  • No usar lenguaje profano, ofensivo, odioso, acosador, amenazante, violento u obsceno.
  • No se permiten comentarios discriminatorios que incluyan raza, etnia, religión, género, discapacidad, orientación sexual o creencias políticas.
  • Sin spam ni ningún tipo de publicidad comercial

vSphere with Tanzu: Kubernetes de Alta Disponibilidad 🕹️

vSphere con alta disponibilidad de Tanzu 🤓

Comencemos analizando genéricamente las soluciones de nube pública, ya que ofrecen una plantilla para proporcionar infraestructura y aislamiento de servicios críticos. Los recursos de la nube pública se alojan en regiones geográficas segmentadas en zonas de disponibilidad (AZ) que proporcionan un conjunto de servicios e infraestructura física aislados. Los recursos pueden ser regionales o basados ​​en AZ, sin embargo, la mayoría están contenidos en una única zona de disponibilidad. Por ejemplo, los nodos de máquina virtual que componen un clúster de Kubernetes podrían ser específicos de AZ y solo podrían adjuntar un volumen persistente que estuviera en la misma zona. Las direcciones IP estáticas o las imágenes de VM pueden ser regionales y estar disponibles en todas las zonas. Las AZ proporcionan una capa de abstracción sobre la infraestructura física que las respalda. Esa infraestructura está diseñada para garantizar el aislamiento de la mayoría de las fallas de infraestructura física y de software. La mayoría de las AZ están diseñadas con sus propios planos de energía, refrigeración, redes y control aislados de otras zonas.

Los recursos de vSphere se alojan en una infraestructura física que se puede aislar en vSphere Clusters y administrar mediante vCenter. A efectos de comparación con la nube pública, podemos pensar en un clúster de vSphere como una zona de disponibilidad (AZ). Los hosts ESXi se agrupan en racks de centros de datos físicos, conectados entre sí, y a otros racks, a través de una serie de conmutadores de red. Las organizaciones toman decisiones sobre si alinear los racks con los clústeres de vSphere o distribuir los hosts de un clúster entre los racks. El mapeo uno a uno entre clústeres y racks proporciona aislamiento y comunicación de baja latencia entre las aplicaciones que se ejecutan en el clúster, a expensas de la disponibilidad en el caso de una conmutación fallida.

vSphere with Tanzu actualmente admite la implementación de clústeres de Supervisor y Tanzu Kubernetes Grid (TKG) en un solo clúster de vSphere. Piense en esto como una implementación de una sola zona de disponibilidad. Una implementación de una sola zona de disponibilidad no significa que no haya alta disponibilidad. Como se describe a continuación, vSphere proporciona un conjunto de capacidades para promover la disponibilidad de los clústeres de Tanzu Kubernetes Grid (TKG) que se ejecutan en una sola AZ.

Veamos la capacidad en la plataforma que admite alta disponibilidad, luego definamos un conjunto de escenarios de falla dentro de una implementación de vSphere con Tanzu y analicemos los enfoques para aumentar la disponibilidad.

Plano de control de múltiples nodos de clúster con host Anti-Affinity y HA

Supervisor Cluster proporciona la API de Kubernetes para implementar los clústeres de vSphere Pods y TKG. Es un servicio del sistema que debe estar disponible para la operación de clústeres y servicios de TKG implementados como operadores de Kubernetes. Para garantizar la disponibilidad, hemos implementado una configuración de varios controladores. Tanto el supervisor como los controladores de clúster de TKG están configurados en una implementación apilada con el servidor Kube-API y etcd disponibles en cada máquina virtual. Cada plano de control tiene un balanceador de carga que enruta el tráfico a las API de Kube en cada nodo del controlador. La programación de los nodos del plano de control se realiza a través de vSphere 7.0 VMware vSphere® Distributed Resource Scheduler ™ (DRS). vSphere 7.0 DRS es más rápido y liviano, lo que garantiza una ubicación rápida entre los hosts, utilizando una política de computación suave de antiafinidad para separar los controladores en hosts separados cuando sea posible. La antiafinidad garantiza que una sola falla del controlador no afecte la disponibilidad del clúster.

Además, vSphere HA proporciona alta disponibilidad para los controladores fallidos al monitorear los eventos de falla y volver a encender las máquinas virtuales. En caso de falla del host, las VM, tanto los nodos Supervisor como TKG, se reinician en otro host disponible, lo que reduce drásticamente el tiempo que el clúster aún disponible se ejecuta con capacidad disminuida. Los Supervisor Controllers son administrados por el ciclo de vida de vSphere Agent Manager (EAM) y los administradores no pueden apagarlos fácilmente; sin embargo, si se apagan, se reiniciarán inmediatamente en el mismo host.

Pods y Daemons del sistema de clústeres

Systemd es el sistema de inicio para la distribución de PhotonOS linux que alimenta los nodos Supervisor y TKG Cluster. Systemd proporciona supervisión de procesos y reiniciará automáticamente cualquier daemons fallido crítico, como el kubelet de Kubernetes.

Los pods del sistema de Kubernetes, los pods de recursos personalizados de VMware y los controladores se implementan como conjuntos de réplicas (o DaemonSets en el contexto de los clústeres de TKG) supervisados ​​por otros controladores de Kubernetes y los contenedores los volverán a crear en caso de falla. Los procesos y pods que componen los clústeres Supervisor y TKG se implementan con mayor frecuencia con múltiples réplicas, por lo que continúan estando disponibles incluso durante la reconciliación de un Pod fallido. La implementación en términos del uso de DaemonSets vs ReplicaSets es diferente entre los clústeres de Supervisor y TKG, pero la disponibilidad de los pods del sistema individuales es similar

Supervisor y equilibrador de carga del controlador de clúster TKG

Como se mencionó anteriormente, los clústeres de supervisor y TKG se implementan como un conjunto de tres controladores. En el caso de los clústeres de TKG, los desarrolladores pueden elegir una implementación de un solo controlador si los recursos están limitados. El acceso a kube-api se dirige a una IP virtual de Load Balancer y se distribuye entre los puntos finales de API disponibles. La pérdida de un nodo del plano de control no afecta la disponibilidad del clúster. Los balanceadores de carga basados ​​en NSX se ejecutan en nodos perimetrales que se pueden implementar en una configuración activa / activa, lo que garantiza la disponibilidad de la IP virtual que los desarrolladores usarán para acceder a los clústeres.

Disponibilidad de almacenamiento en clúster 

Los clientes tienen la opción de habilitar VMware vSAN para proporcionar almacenamiento compartido de alta disponibilidad para los clústeres de Supervisor y TKG. vSAN combina el almacenamiento que es local para los hosts en una matriz de almacenamiento virtual que se puede configurar con las necesidades de redundancia del entorno. Los niveles de RAID se implementan en todos los hosts y brindan disponibilidad en los casos en que fallan los hosts individuales. vSAN es nativo del hipervisor ESXi y, por lo tanto, no se ejecuta como un conjunto de dispositivos de almacenamiento que podrían competir con las VM del clúster de Kubernetes por los recursos.

Disponibilidad de vSphere Pods

Los clientes que necesitan el aislamiento de una máquina virtual desde una perspectiva de seguridad y rendimiento, mientras desean orquestar la carga de trabajo a través de Kubernetes, pueden elegir vSphere Pods. Los operadores del sistema y de terceros también se pueden implementar como pods de vSphere. Se ejecutan en una máquina virtual en tiempo de ejecución de contenedor directamente en hosts ESXi y se comportan como cualquier otro pod. La disponibilidad se administra a través de objetos estándar de Kubernetes y sigue el patrón de Kubernetes para manejar fallas de pod. Cree una implementación con varias réplicas definidas y el controlador observará los pods fallidos y los volverá a crear. Las fallas de host harían que los vSphere Pods se volvieran a crear en nuevos hosts. Este patrón no usa vSphere HA, sino que aprovecha los controladores de Kubernetes para manejar fallas.

Escenarios de falla de infraestructura y software

Analizamos la capacidad central dentro de la plataforma y ahora definiremos un conjunto de escenarios de falla dentro de una implementación de vSphere con Tanzu, luego analizaremos los enfoques para aumentar la disponibilidad en cada escenario.

Fallo del componente del clúster de Kubernetes

  • Fallo del proceso del nodo de Kubernetes
  • Fallo del pod del sistema de Kubernetes
  • Máquina virtual apagada

Cuando un controlador o un nodo trabajador deja de estar disponible, los pods del sistema se volverán a crear en uno de los otros nodos disponibles. Los procesos fallidos de Linux son monitoreados y reiniciados por el sistema de inicio systemd. Esto es cierto tanto para el plano de control de TKG como para los nodos de trabajo, así como para el plano de control del supervisor. Los nodos Supervisor Worker son hosts ESXi reales, no ejecutan systemd y manejan las fallas del proceso de manera diferente. Las máquinas virtuales que se apagan se reinician automáticamente. El plano de control se implementa como un conjunto de 3 controladores, con una IP virtual de Load Balancer como el punto final de Kube-API para garantizar que durante el tiempo necesario para remediar la interrupción, el clúster todavía esté disponible. La corrección de los nodos de trabajo de TKG se maneja mediante el uso integrado de la capacidad MachineHeatlhCheck en ClusterAPI V1Alpha3.

Interrupción del host

  • Error de host
  • Reinicio del host

La falta de disponibilidad de un host ESXi puede deberse a un breve reinicio o podría estar relacionada con una falla real del hardware. Al reiniciar, todas las VM del controlador y del nodo se reinician automáticamente en el host. Si el reinicio tarda más que el umbral de tiempo de espera de latido de HA, las VM se programan para su ubicación en otros hosts disponibles y se encienden. Las reglas de antiafinidad se mantendrán si los recursos lo permiten. En cualquier caso, los clústeres todavía están disponibles porque tienen varios nodos de controlador ubicados en hosts ESXi separados y se accede a ellos a través de un equilibrador de carga y pueden sobrevivir a la pérdida de un controlador.

Interrupción del estante

  • Fallo del interruptor de la parte superior del bastidor

Los hosts están organizados en racks físicos en el centro de datos. Los hosts en un rack se conectan a través de un conmutador Top of Rack y además se conectan a conmutadores de agregación adicionales. La pérdida de un conmutador, matriz de almacenamiento o alimentación podría hacer que un rack completo no esté disponible. La disponibilidad de un supervisor o clúster TKG depende de cómo se alinean los hosts con los racks. Algunos clientes colocarán todos los hosts en un clúster de vSphere en el mismo rack, lo que esencialmente hará que ese rack físico sea una zona de disponibilidad (AZ). La falla del bastidor haría que el Supervisor Cluster y todos los clústeres TKG no estuvieran disponibles. Otra opción es crear clústeres de vSphere a partir de hosts que residen en varios racks. Esta configuración garantiza que una sola falla de bastidor no haga que todos los hosts de vSphere Cluster no estén disponibles y aumenta la probabilidad de que el plano de control permanezca disponible.

Actualmente, el Programador de recursos distribuidos (DRS) no reconoce el bastidor. Esto significa que las reglas de antiafinidad para las máquinas virtuales del plano de control garantizarían la separación de hosts, pero no necesariamente garantizarían que los hosts estuvieran en racks separados. Se está trabajando para proporcionar una programación basada en rack que mejoraría esta disponibilidad.

Fallo de la matriz de almacenamiento

Los clústeres de supervisor y TKG requieren almacenamiento compartido para permitir que los volúmenes persistentes sean accesibles a los pods que se pueden colocar en cualquier nodo, que podría residir en cualquier host. Tanto vSAN como los arreglos de almacenamiento tradicionales admiten varias configuraciones RAID que garantizan la disponibilidad de datos en caso de corrupción de discos individuales. vSAN agrega almacenamiento local adjunto a hosts físicos y también puede permanecer disponible si se produce una falla de host o incluso potencialmente de un rack.

Los clústeres extensibles de vSAN también brindarán la capacidad de dividir un único clúster de vSphere en dominios de fallas específicos de almacenamiento separados. Esto permitiría la disponibilidad de datos incluso con la pérdida de todo el dominio. Con hosts físicos distribuidos en varios racks, los volúmenes persistentes permanecerían disponibles durante las fallas tanto del host como del rack.

Falla de red

  • Fallo de NSX Edge

La redundancia física está integrada en la mayoría de los entornos de red de producción que brindan disponibilidad a través de fallas de hardware físico. Cuando se implementan con NSX-T, los clústeres Supervisor y TKG se ejecutan en redes superpuestas que son compatibles con la red física subyacente. Las VM de NSX Edge contienen los Vips de Load Balancer y enrutan el tráfico a los nodos del plano de control del clúster. NSX Edges se puede implementar en una configuración activa / activa que mantendría la red disponible en el caso de una falla del host o de la máquina virtual que afectó a un solo NSX Edge.

Interrupción de vCenter

La disponibilidad de vCenter Server es fundamental para el funcionamiento completamente funcional de los clústeres de Supervisor y TKG. En el caso de una falla de vCenter, todas las máquinas virtuales, tanto el controlador como los nodos, continuarán ejecutándose y serán accesibles aunque con funcionalidad degradada. Los módulos de aplicaciones seguirían ejecutándose, pero la implementación y la gestión del sistema serían limitadas. La autenticación requiere que el servicio de inicio de sesión único devuelva un token de autenticación al archivo de configuración de kubectl. Solo los usuarios que tengan un token no vencido podrán acceder al sistema. Objetos como Load Balancers y PersistentVolumeClaims requieren interacción con vCenter y no se pueden administrar durante el ciclo de vida.

vCenter se puede proteger con vCenter High Availability. vCenter High Availability (vCenter HA) protege no solo contra fallas de hardware y host, sino también contra  vCenter Server  fallas de aplicaciones de . Al utilizar la conmutación por error automatizada de activo a pasivo, vCenter HA admite alta disponibilidad con un tiempo de inactividad mínimo. Esto aumentaría drásticamente la disponibilidad de los grupos Supervisor y TKG.

Hay un trabajo extenso en proceso para desacoplar los servicios principales de vCenter Server y llevarlos al nivel del clúster. El objetivo es proporcionar siempre una infraestructura que continúe funcionando incluso cuando vCenter tiene una interrupción

Mi Experiencia Como Veeam Vaguard & Veeam Legends

Les cuento un poco de mi, Soy Esteban Prieto vivo en Argentina – Buenos Aires, actualmente trabajo como System Engineer en VMware, soy Veeam Vanguard 2019/21 Class 💯 y Veeam Legend First Class 2021 👨‍🎓. Lo primero que descubrí siendo parte de las 2 comunidades mas importantes de tecnología, es que el éxito de cada … Sigue leyendo Mi Experiencia Como Veeam Vaguard & Veeam Legends

VBR v11 🔥 Como trabaja CDP con Retention Policies

CDP – Retention Policies Una política de retención define durante cuánto tiempo Veeam Backup & Replication debe almacenar los puntos de restauración para las réplicas de VM. Veeam Backup & Replication ofrece dos esquemas de políticas de retención: Retención a largo plazo Retención a corto plazo Retención a largo plazo Veeam Backup & Replication conserva … Sigue leyendo VBR v11 🔥 Como trabaja CDP con Retention Policies

Overview Veeam Legends 🦁

Hoy tengo la felicidad que me han elegido para el programa de Veeam Legends, una gran forma de compartir ideas, dudas, y conocimiento tecnico de Veeam. Un honor seguir contribuyendo desde las dos comunidades Veeam Legends y Veeam Vanguard !! Les doy una descripción general del programa. Quiénes son Veeam Legends? Veeam Legends son usuarios … Sigue leyendo Overview Veeam Legends 🦁

Tape 📼 Improvements – VBR v11 🔥

Cuando pensé que la cinta se había olvidado :gritar:… Veeam nos trae estas mejoras que creo que son excelentes! : nerd:

Tape 📼 Mejoras

:circulo rojo: Tape Cloning !!!

  • Nos permite migrar de LTO antiguo a generaciones de cintas más nuevas
  • Copia adicional por razones de seguridad
  • Puede copiar de un drive a otra a través del Tape Server
  • Puede modificar la base de datos y vincular Backups antiguos con Tapes nuevos
  • Puede conservar el enlace para Tapes antiguos
  • Las partes del archivo se detectan y solicitan Tape adicional

: mano_alzada: Nota:

Veeam puede clonar todas las cintas de Veeam (B2T, F2T, NDMP), Veeam no puede hacerlo para cintas de terceros.

: diamantes: Lo que necesitas saber : escribiendo_mano:

  • Requiere al menos dos Drives
  • Si existen varias copias, Restore selecciona automáticamente la cintas necesarias
  • Sin Scheduler (use PowerShell)
  • Un Media Pool solo permite una generación LTO

Veeam Backup & Replication v11 🤓 New Linux🐧 Backup Proxy Modes

Linux Backup Proxy Mejorados

Los clientes buscan utilizar más Linux !

Antes solo podíamos utilizar el modo de transporte HotAdd

Las mejoras son en modos de transporte son:

  • Network Mode (NBD)
  • Direct SAN (NFS,iSCSI and FC)
  • Backup from storage snapshot (iSCSI, FC)

📌 Nos quedaría el siguiente escenario

🐧 Las Mejoras de HotAdd

  • Soporte de lectura Asincrónica
  • Los mismo que se hacemos para Windows con la “Busqueda de datos avanzada”

Limitaciones

  • No soporta snapshot storage para NFS
  • No soporta Veeam Agent para WINDOWS backup from Storage snapshots

Espero que este Post los tenga contando los días para la nueva v11 de Veeam !!

vSphere with Tanzu: Kubernetes de Alta Disponibilidad 🕹️

vSphere con alta disponibilidad de Tanzu 🤓 Comencemos analizando genéricamente las soluciones de nube pública, ya que ofrecen una plantilla para proporcionar infraestructura y aislamiento de servicios críticos. Los recursos de la nube pública se alojan en regiones geográficas segmentadas en zonas de disponibilidad (AZ) que proporcionan un conjunto de servicios e infraestructura física aislados. … Sigue leyendo vSphere with Tanzu: Kubernetes de Alta Disponibilidad 🕹️

Veeam Networking Port Tool para VBR v10

Continuamos explorando este poderoso  sitio    “Veeam Architects Site” En este tema, le mostraré cómo usar esta herramienta   Veeam Networking Port Tool para VBR v10 Descargo de responsabilidadEsta herramienta utiliza los datos más recientes de la Guía del usuario de Veeam. Recomendamos a los usuarios que verifiquen los resultados con la guía del usuario, consulten a un ingeniero de sistemas … Sigue leyendo Veeam Networking Port Tool para VBR v10

Veeam Networking Port Tool para VBR v10

Continuamos explorando este poderoso  :borrar:sitio  : point_right:  “Veeam Architects Site”

En este tema, le mostraré cómo usar esta herramienta  :llave inglesa: Veeam Networking Port Tool para VBR v10

:altoparlante:Descargo de responsabilidad
Esta herramienta utiliza los datos más recientes de la Guía del usuario de Veeam. Recomendamos a los usuarios que verifiquen los resultados con la guía del usuario, consulten a un ingeniero de sistemas o arquitecto de soluciones de Veeam. Los números de puertos cambian, no podemos responsabilizarnos por ningún cambio dentro del software de Veeam que se haya realizado después de la fecha que se muestra a continuación. 
Esta designación de puerto es correcta a partir de agosto de 2020

Esta herramienta fue desarrollada para simplificar la identificación de puertos requeridos por el software Veeam. Estos deben estar operativos en su firewall entre cada componente de la infraestructura de Veeam Backup and Replication cuando elija usarlos

:avance rápido:Cómo utilizar esta herramienta

Prepárate . Sepa qué servidores planea usar en el diseño y qué desea hacer con ellos, por ejemplo, tenga una lista de nombres de servidor, direcciones IP y qué roles de Veeam que le gustaría usar en cada servidor. Desde el punto de vista de la seguridad, en realidad no necesitamos conocer los nombres reales, puede crear una lista de nombres de servidor que podría ser del 1 al 100 siempre que sepa lo que representan en su diseño, lo mismo para las direcciones IP, no hay datos almacenados con esta herramienta. Todo está en la caché de su navegador únicamente.

:avance rápido: Pasos y páginas

Paso 1.  Operaciones

Seleccione las operaciones que desea realizar dentro de la infraestructura de Veeam. 

Seleccione cada operación y cree una lista de cada opción en esta página, siga cada paso a medida que se desarrolla y una vez que aparezca “Agregar a la lista”, estará completo. Puede haber muchas opciones para cada operación, así que lea cada opción con atención. Si desea agregar varias opciones similares, agregue cada una por separado, en cualquier momento puede volver a esta página y agregar operaciones adicionales, la herramienta es dinámica.

No olvide presionar  “Enviar” .

Paso 2.  Infraestructura

La página de Infraestructura ofrece los roles de componentes de infraestructura de Veeam que desea agregar, como Proxy, Repositorios, Hipervisor u opciones de almacenamiento. Agregue cada componente según sea necesario para crear las opciones necesarias para el diseño. Continúe agregando cada opción hasta que tenga una lista completa de las opciones que necesitará. En este ejemplo, elijo Hypervisor 

y agregué un vCenter como Infra del Hypervisor

y elegimos un proxy para estas operaciones.

:avance rápido: Servers

Hay dos pasos en esta página.

   Parte superior de la página “Asignación de funciones” enumera los servidores que ha agregado y las funciones asignadas que se les asignaron.

   Paso 3.  Agregar servidores 
   Paso 4.  Asignar roles a servidores

Cuando seleccionamos las operaciones, la infraestructura con sus opciones, necesitamos poder asignarlas a los servidores para que podamos comprender cómo encajan.

Paso 3 . Agregar servidores

Esta es la entrada de nuestros nombres de servidor y direcciones IP reales que planeamos usar, lo que es importante con las direcciones IP son solo los conceptos básicos de las mismas subredes. 
Con esta lista, asignaremos los roles de Veeam a cada servidor, por lo que debe ser completo. Mire hacia abajo a la sección de roles del mapa y podrá ver qué roles están disponibles. 
También será necesario acceder a un servidor de autenticación, por lo que también será necesario agregarlo para la función asignada.

Paso 4.  Asignación de roles

En este punto tenemos roles y hemos agregado servidores, ahora necesitamos agregar cada rol a un servidor designado. usando el cuadro desplegable al lado de un rol en particular, puede elegir un servidor de la lista, una vez seleccionado el  “MAPA” El botón se resaltará y puede presionarlo para asignar ese rol a ese servidor en la página, la asignación de roles en la parte superior de la página cambiará para reflejar que el servidor ahora tiene asignado el rol. Los servidores pueden tener múltiples roles y usted puede asignar el mismo servidor a otros roles para reflejar su diseño con precisión. Si ve un rol que no usará pero que se agregó automáticamente como “EM Server” (Administrador corporativo), puede presionar ignorar y el rol se eliminará por completo (esto es irreversible actualmente). Una vez que haya verificado que todos los roles están asignados correctamente a los servidores, puede enviar las opciones a la configuración.

:avance rápido: Resultado

Tienes todos los puertos que usarás en estas operaciones y puedes exportar a XLS

Veeam Backup & Replication v11 🤓 New Linux🐧 Backup Proxy Modes

Linux Backup Proxy Mejorados Los clientes buscan utilizar más Linux ! Antes solo podíamos utilizar el modo de transporte HotAdd Las mejoras son en modos de transporte son: Network Mode (NBD) Direct SAN (NFS,iSCSI and FC) Backup from storage snapshot (iSCSI, FC) 📌 Nos quedaría el siguiente escenario 🐧 Las Mejoras de HotAdd Soporte de … Sigue leyendo Veeam Backup & Replication v11 🤓 New Linux🐧 Backup Proxy Modes

Veeam Backup Repository Design 🔥

En este tema veremos sobre el diseño del repositorio. Necesitamos considerar  La recomendación clave es seguir la  regla 3 -2-1 . Calcule 1 núcleo y 4 GB de RAM por repository task slot. El mínimo recomendado para un repositorio es de 2 núcleos y 8 GB de RAM. Dimensionamiento   La cantidad recomendada de CPU para un repositorio es de 1 … Sigue leyendo Veeam Backup Repository Design 🔥

Veeam Backup Repository Design 🔥

En este tema veremos sobre el diseño del repositorio.

Necesitamos considerar 

  • La recomendación clave es seguir la  regla 3 -2-1 .
  • Calcule 1 núcleo y 4 GB de RAM por repository task slot. El mínimo recomendado para un repositorio es de 2 núcleos y 8 GB de RAM.

Dimensionamiento  : nerd:

  • La cantidad recomendada de CPU para un repositorio es de 1 núcleo por ranura de tarea configurada concurrente en un servidor de repositorio. Configure como mínimo un servidor de repositorio de 2 núcleos y 8 GB de RAM para permitir que el sistema operativo responda mejor.
  • Al dimensionar los espacios de tareas en un repositorio, debe comprender cuándo y cuántos espacios de tareas se consumen. Cualquier proceso de escritura consumirá un espacio de tarea. Por lo tanto, hacer una copia de seguridad de 10 máquinas virtuales en un trabajo utilizando cadenas de copia de seguridad por trabajo solo escribirá un archivo (VBK / VIB) al final, por lo que consume una ranura de tarea.
  • Ejecutar el mismo trabajo de respaldo con archivos de respaldo por VM creará un archivo por VM y, por lo tanto, puede aprovechar hasta 10 ranuras de tareas (cuando estén disponibles).
  • Los trabajos de copia de respaldo, los respaldos de agentes y los trabajos de complementos también consumen espacios de tareas y deben tenerse en cuenta.
:chincheta:

Una tarea en el nivel de repositorio se consume de manera diferente que las tareas en el nivel de proxy. Si los “archivos de respaldo por VM” están  habilitados  en el repositorio, cada VM procesada simultáneamente consumirá una tarea de repositorio, mientras que cada disco virtual de esta VM consumirá una tarea de proxy (la proporción típica es de 3 discos por VM)

:chincheta:

Si los “archivos de copia de seguridad por máquina virtual” están  deshabilitados , una sola tarea de copia de seguridad consumirá solo una tarea de repositorio, independientemente de la cantidad de máquinas virtuales que esté procesando la tarea. Pero la cantidad de tareas de proxy consumidas seguirá siendo la misma (una tarea por cada disco virtual).

Ejemplo :guiño:

Si el requisito principal para el proxy es 16 núcleos para el incremental, los núcleos para el repositorio serán 5 según una proporción de disco a máquina virtual de 3: 1(redondeado). Para calcular la RAM, esto se multiplica por el requisito de RAM de 4 GB por núcleo, lo que da como resultado 20 GB.

Cuando el resultado de su cálculo sea un servidor (virtual) muy pequeño, considere recursos adicionales para la sobrecarga del sistema operativo (1 Core / 4GB RAM adicional debería ser suficiente). Normalmente, los tamaños tienden a ser de un mínimo de 4 núcleos / 16 GB para servidores virtuales o servidores físicos con> 10 núcleos y 64 GB de RAM donde de todos modos hay suficientes recursos disponibles para el sistema operativo.

¿Qué pasa con ReFS? :pensando:

Al usar el sistema de archivos Windows ReFS, la recomendación es agregar 0.5 GB de RAM por TB de almacenamiento ReFS. Sin embargo, no tiene que escalar esto indefinidamente. 128 GB de RAM suelen ser suficientes para los requisitos de tareas, SO y ReFS si el tamaño total del volumen de ReFS del servidor es inferior a ~ 200 TB. Según el tamaño de ReFS o los requisitos de la tarea, es posible que desee agregar más memoria, pero no debería ser necesario superar los 256 GB.

: point_right: Espero te sea de utilidad 

Hacer diseños de Veeam online 📝

Muchas veces he tenido que hacer diseños de Veeam y este sitio en línea http://www.draw.io/  me ha ayudado más de una vez.

Tiene shapes de Veeam – VMware y muchas otros shapes que le ayudarán a hacer lo que necesite.

: triangular_flag_on_post: Podemos importar desde estas opciones

: triangular_flag_on_post: Exportar en muchos formatos

: triangular_flag_on_post: O guárdalo

Espero que que esta tool online les sea de mucha ayuda !!

Calculando 🤓 Size de Proxy Tasks 💪

En mi tema anterior, mostré cómo usar el Veeam Architects Site , pero ¿cómo nos da la cantidad de núcleos y memoria que usará el proxy? Te mostrare … 🤓 Obtener la cantidad adecuada de potencia de procesamiento es esencial para lograr el RTO / RPO definido por la empresa. En esta sección, describiremos las recomendaciones a seguir para el … Sigue leyendo Calculando 🤓 Size de Proxy Tasks 💪

Observabilidad 👀 con Prometheus y Grafana 🔥 en Clusteres de Tanzu Kubernetes Grid (TKG) VMware

La comunidad de código abierto está convergiendo en Prometheus como la solución preferida para abordar los desafíos asociados con el monitoreo de Kubernetes. Fue desarrollado previamente por SoundCloud y luego donado al CNCF. Prometheus admite aplicaciones de instrumentos en muchos idiomas. Ofrece una integración de Kubernetes incorporada y es capaz de descubrir recursos de Kubernetes como nodos, servicios … Sigue leyendo Observabilidad 👀 con Prometheus y Grafana 🔥 en Clusteres de Tanzu Kubernetes Grid (TKG) VMware

Veeam Utilities 🤓 Veeam Backup Validator

Sabías que, existe a parte de “SureBackUp” una herramienta muy útil de Veeam para validar tus respaldos ? En algunos casos, una copia de seguridad puede dañarse debido a cambios accidentales en los datos del archivo de copia de seguridad. Por ejemplo, el archivo puede dañarse después de la transferencia a través de la red o … Sigue leyendo Veeam Utilities 🤓 Veeam Backup Validator

Tendencias En La Transformación Del Network Edge 🔝

Nyansa para extender VMware SD-WAN por VeloCloud Visibilidad, análisis y resolución de problemas en la LAN Por Sanjay Uppal, vicepresidente y gerente general de VeloCloud Business Unit, VMware En enero de 2019, VMware anunció la visión para la evolución y el SD-WAN, la llamaron “Network Edge“, basándose en la creencia de que SD-WAN tiene un potencial … Sigue leyendo Tendencias En La Transformación Del Network Edge 🔝

Veeam Backup de Azure☁️Nativo! 😎

Ya lo podemos encontrar en el MarketPlace de Azure 🤪 Hablemos de Backup de Azure: Rentable, seguro y preparado para la empresa Veeam Backup para Microsoft Azure es una solución desarrollada para tareas de protección y recuperación ante desastres para entornos Microsoft Azure. Con Veeam Backup para Microsoft Azure , puede crear copias de seguridad a nivel de … Sigue leyendo Veeam Backup de Azure☁️Nativo! 😎

Calculando 🤓 Size de Proxy Tasks 💪

En mi tema anterior, mostré cómo usar el Veeam Architects Site :parte superior:, pero ¿cómo nos da la cantidad de núcleos y memoria que usará el proxy? Te mostrare … 🤓

Obtener la cantidad adecuada de potencia de procesamiento es esencial para lograr el RTO / RPO definido por la empresa. En esta sección, describiremos las recomendaciones a seguir para el tamaño adecuado.

Definimos

D = Source data in MB
W = Backup window in seconds
T = Throughput in MB/s = D/W
CR = Change rate
CF = Cores required for full backup = T/100
CI = Cores required for incremental backup = (T * CR)/25

Ejemplo:

Nuestra infraestructura de muestra tiene las siguientes características:

  • 1000 máquinas virtuales
  • 100 TB de almacenamiento consumido
  • Ventana de respaldo de 8 horas
  • Tasa de cambio del 10%

Al insertar estos números en las ecuaciones anteriores, obtenemos los siguientes resultados.

Necesitamos cambiar TB a MB / Necesitamos cambiar Horas a Segundos

D = 100 TB * 1024 * 1024 = 104,857,600 MB (Source data in MB)
W = 8 hours * 3600 seconds = 28,800 seconds (Backup window in seconds)
T = 104857600/28800 = 3,641 MB/s (Throughput)

 Usamos el rendimiento promedio para predecir cuántos núcleos se requieren para cumplir con el SLA definido.

CF = T/100 ~ 36 cores (Cores required for full backup)

La ecuación se modifica para tener en cuenta la disminución del rendimiento de las copias de seguridad incrementales en el siguiente resultado:

CI = (T * CR)/25 ~ 14 cores (Cores required for incremental backup)

Como se vio anteriormente, las copias de seguridad incrementales generalmente tienen requisitos de procesamiento más bajos en los servidores proxy.

Teniendo en cuenta que cada tarea consume hasta 2 GB de RAM , obtenemos el siguiente resultado:

36 núcleos y 72 GB de RAM  💪

  • Para un servidor físico, se recomienda instalar CPU duales con 10 núcleos cada una. Se requieren 2 servidores físicos.
  • Para los servidores proxy virtuales, se recomienda configurar varios proxies con un máximo de 8 vCPU para evitar problemas de programación conjunta. Se requieren 5 servidores proxy virtuales.

: point_right: Si, en cambio, ajustamos el tamaño solo para las copias de seguridad incrementales en lugar de las copias de seguridad completas, podemos predecir una ventana alternativa de copia de seguridad completa con menos cálculo:

WS = 104857600/(14 * 100)
W = WS/3600 ~ 21 hours

:chincheta:Nota: El  rendimiento depende en gran medida de la infraestructura de red y almacenamiento subyacente. 

:chincheta: Nota : el procesamiento en paralelo también puede estar limitado por el máximo de tareas simultáneas en el nivel del repositorio

Recuerda 

: ballot_box_with_check:Los proxies tienen múltiples ranuras de tareas para procesar datos de origen de VM. Se recomienda planificar 1 núcleo físico o 1 vCPU y 2 GB de RAM para cada una de estas tareas.

: ballot_box_with_check: Una tarea procesa 1 disco de VM a la vez y los recursos de CPU / RAM se utilizan para la deduplicación de datos en línea, la compresión, el cifrado y otras funciones que se ejecutan en el propio proxy.

: ballot_box_with_check: En la Guía del usuario se indica que los servidores proxy requieren 2 GB de RAM + 500 MB por tarea

Espero que te haya sido útil para entender lo que necesitamos saber para calcular las tareas del proxy.

VeloCloud de VMware ☁️

Habilitación de la continuidad del negocio con VMware SD-WAN Desafíos del cliente Retraso en el nuevo despliegue de oficinas remotas / domésticas como resultado del aprovisionamiento repetitivo y complejo de dispositivos domésticos / periféricos. Experiencia insatisfactoria para el usuario final debido a las operaciones manuales del día 2 que carecen de visibilidad del rendimiento y … Sigue leyendo VeloCloud de VMware ☁️

🆕 El nuevo Instant VM “Disk” Recovery !! 😎

Veremos como restaurar inmediatamente los discos virtuales desde un Backup y publicarlos en el entorno de producción!! 💡 Antes de que empieces Antes de realizar Instant VM Disk Recovery, tenga en cuenta lo siguiente: Puede restaurar un disco virtual desde una copia de seguridad que tenga al menos un punto de restauración creado con éxito. … Sigue leyendo 🆕 El nuevo Instant VM “Disk” Recovery !! 😎

Veeam Backup para Microsoft Office 365 4b (parche acumulativo KB3119) 🔧

Hoy les traigo información de Mejoras y que problemas fueron resueltos en este parche acumulativo 🛠️ Algo Muy Importante! 📢 Confirme que está ejecutando Veeam Backup para Microsoft Office 365 4b (compilación 4.0.0.2516) antes de instalar este parche acumulativo KB3119. Puede verificar esto en Ayuda> Acerca de en Veeam Backup para la consola Microsoft Office 365 . Después de actualizar, su versión de compilación … Sigue leyendo Veeam Backup para Microsoft Office 365 4b (parche acumulativo KB3119) 🔧