El repositorio reforzado de Veeam es la solución nativa de Veeam para proporcionar inmutabilidad confiable para los backups de Veeam Backup & Replication en un servidor Linux. Al admitir servidores Linux genéricos, Veeam garantiza que los clientes siempre tengan la opción de elegir su hardware sin dependencia del proveedor. Veeam también permite a los clientes utilizar su distribución Linux de confianza (Ubuntu, Red Hat, SUSE) en lugar de verse obligados a utilizar un “Veeam Linux personalizado”.
Los repositorios reforzados ayudan a garantizar la inmutabilidad de los backups de Veeam conforme a la regla 3-2-1 y combinan los repositorios reforzados con otras opciones inmutables, como el bloqueo en el almacenamiento de objetos o las cintas WORM. Este post del blog mostrará cómo seleccionar y preparar el entorno para un servidor físico que posteriormente se utilizará como repositorio reforzado. En futuras entradas del blog se abordarán otros temas como la preparación y la planificación, la seguridad de un sistema Linux y la integración en Veeam Backup & Replication.
Los impacientes pueden utilizar servidores (de alta densidad) con discos internos. Este enfoque se escala linealmente, porque con cada nuevo nodo de repositorio reforzado, hay más CPU, RAM, RAID, red, espacio en disco y rendimiento de E/S. Un rack lleno de servidores de alta densidad proporciona alrededor de 8 PB de capacidad nativa. Con la reducción de datos nativa de Veeam más el ahorro de espacio XFS (clonación de bloques), que puede ser de hasta 100 PB de datos lógicos en un rack con una velocidad de backup de hasta 420 TiB/h.
Si tienes un entorno pequeño, no te preocupes. Comience con dos unidades de rack, 12 discos de datos y dos discos para el sistema operativo.
La red
La red es un factor clave para garantizar que el repositorio reforzado pueda ayudar a alcanzar los objetivos de punto de recuperación (RPO, la cantidad máxima de datos que se puede perder) y los objetivos de tiempo de recuperación (RTO, cuánto tiempo tomaría una restauración). En un mundo de backups “incrementales para siempre”, la red a veces se olvida, debido a los requisitos de bajo ancho de banda del enfoque “incremental para siempre”. La recomendación es diseñar para un escenario de “restauración completa”. Tome su herramienta de cálculo preferida para estimar el ancho de banda haciéndolo coincidir con sus requisitos de restauración.
A continuación se muestran algunos ejemplos de lo que se tarda en copiar 10 TB de datos a diferentes velocidades de red:
1 Gbit/s 22h 45 min
10 Gbit/s 2h 15 min
20 Gbit/s 1h 8 min
40 Gbit/s 34 min
100 Gbit/s menos de 14 min
100 Gbit/s es, siendo realistas, lo más rápido que los clientes ponen hoy en un servidor de repositorio. HPE ha demostrado en 2021 con su servidor Apollo 4510 que tales velocidades se pueden lograr con un solo servidor.
Pero no es solo ancho de banda. También tiene que ver con la redundancia. Si solo hay un cable de red a la infraestructura de conmutación, significa que hay un único punto de fallo. Se recomienda tener una conexión de red redundante para el repositorio reforzado. Dependiendo de las funcionalidades de red que tenga, podría tratarse de enlaces activos/activos con balanceo de carga (por ejemplo, LACP/802.3ad) o un simple escenario activo/pasivo.
Aunque Linux se puede configurar fácilmente con etiquetas VLAN, el principio KISS requiere el uso de puertos de switch sin etiquetar. Es decir, se configuran las direcciones IP directamente sin ninguna VLAN en Linux. En la actualidad, la configuración redundante más pequeña sería 2 conexiones de 10 Gbit/s a dos conmutadores o una pila de conmutadores (en función de nuestro entorno de red).
Para recibir actualizaciones de seguridad de Linux, es necesario tener acceso a los servidores de actualizaciones de seguridad de la distribución Linux.
Para simplificar, permitimos el acceso a Internet HTTP saliente en el firewall para obtener actualizaciones de seguridad. Solo permitimos conexiones a los servidores de actualización de la distribución Linux de su elección, no a todo Internet. La alternativa sería configurar un espejo de su distribución Linux preferida para obtener actualizaciones y software desde allí.
Encontrar el proveedor y el modelo de servidor adecuados
Desde el punto de vista de Veeam, la recomendación es utilizar un servidor con discos internos a modo de repositorio reforzado. Se recomiendan los discos internos porque así se elimina el riesgo de que un atacante pueda obtener acceso y eliminar todo en el sistema de almacenamiento. Los proveedores de servidores a veces tienen modelos de “servidor de backup de Veeam”. Estos modelos de servidor están optimizados para los requisitos de rendimiento de backup y es una buena idea atenerse a las recomendaciones del proveedor.
Si tiene una distribución de Linux preferida, entonces tiene sentido elegir un modelo que esté certificado para esa distribución de Linux. Las configuraciones probadas previamente ahorran mucho tiempo cuando se trabaja con Linux. Las grandes marcas suelen tener servidores, que son compatibles con las principales distribuciones de Linux como Ubuntu, Red Hat (RHEL) y SUSE (SLES).
Como ya he mencionado HPE antes, Cisco tiene diseños validados por Cisco para Veeam para las series S3260 y C240. Técnicamente, desde el punto de vista de Veeam, cualquier proveedor de servidores es válido, siempre que se cumplan estos requisitos esenciales:
Controlador RAID con caché de reescritura alimentado por batería (o tecnología similar)
Se recomienda encarecidamente el uso de controladores RAID con análisis predictivo de fallos
Con muchos discos (50+), los múltiples controladores RAID suelen tener sentido, debido a los límites de velocidad del controlador RAID (a menudo limitados a 2 GByte/s)
Discos separados para el sistema operativo y los datos
Se recomiendan encarecidamente los SSD para el sistema operativo
Fuente de alimentación redundante
Red redundante con la velocidad de enlace requerida (ver arriba)
La velocidad de CPU es relativamente irrelevante, ya que Veeam usa por defecto la compresión muy rápida LZ4. Tomar lo que ofrece el proveedor de servidores funciona bien. Muchos núcleos de CPU ayudan a ejecutar muchas tareas en paralelo. 4 GB de RAM por núcleo de CPU es la mejor práctica recomendada. Si se decide por 2X 16 núcleos de CPU, entonces 128 GB de RAM sería la combinación perfecta. Si bien ese tipo de dimensionamiento puede sonar “demasiado simplificado”, ha funcionado bien durante años en nuestras pruebas y en entornos de producción.
Configuración básica del servidor
Antes de instalar el sistema operativo Linux, hay algunos ajustes que deben configurarse. Como se mencionó anteriormente, los sistemas operativos y los datos están separados en diferentes discos. En diferentes conjuntos RAID, para ser precisos.
Para el sistema operativo Linux, se utiliza un RAID 1 dedicado. 100 GB son más que suficientes. Para los discos de datos, la mayoría de los clientes optan por RAID 6/60 por su mejor relación calidad/precio en comparación con RAID 10. RAID 5/50 o cualquier otra opción de paridad única se prohíbe por razones de seguridad. El RAID 6/60 debe configurarse con al menos un disco de repuesto en “configuración de itinerancia”. Esto significa que el disco de repuesto puede reemplazar cualquier disco que haya fallado y convertirse en un disco de producción.
Como el servidor está equipado con un controlador RAID adecuado con caché de reescritura, las cachés de disco internas deben configurarse como “deshabilitadas”. A veces, el proveedor del servidor documenta el tamaño de sector RAID recomendado. Si no hay información disponible, 128 o 256 KB son buenos valores.
Habilite el arranque seguro UEFI para evitar que se carguen módulos del kernel de Linux sin firmar.
¿Cómo puedo recibir notificaciones sobre discos con fallos?
Uno de los mayores retos a la hora de reforzar un servidor/sistema Linux es cómo recibir notificaciones sobre los discos que fallan. Todos los servidores modernos tienen una gestión “fuera de banda” (HPE iLO, Cisco CIMC, Dell iDRAC, Lenovo XCC, etc.). Muestran el estado del disco y del RAID y pueden notificar por correo electrónico sobre discos fallidos. Este tipo de notificación tiene la ventaja de que no es necesario configurar nada en Linux más adelante. Si la interfaz de administración permite configurar la autenticación multifactor, eso es bueno y se debe usar.
Tenga en cuenta que la autenticación multifactor no protege contra los muchos problemas de seguridad que los sistemas de administración fuera de banda tuvieron en el pasado. Los clientes a menudo evitan usarlos por razones de seguridad. Si un atacante se convierte en administrador en la gestión fuera de banda, puede borrar todo el repositorio reforzado sin tocar el sistema operativo. Una solución de compromiso podría ser poner un firewall delante del puerto de gestión y permitir únicamente la comunicación saliente. Eso permitirá enviar notificaciones por correo electrónico si falla un disco. Pero un atacante no puede atacar/iniciar sesión en la interfaz de administración porque el firewall bloquea todas las conexiones entrantes.
El diseño podría parecerse al siguiente ejemplo:
Si decide desconectar por completo el puerto de administración fuera de banda, las notificaciones sobre discos fallidos se pueden configurar con software que se ejecute sobre el sistema operativo Linux. Los proveedores de servidores suelen proporcionar paquetes para ver el estado o incluso configurar RAID desde dentro del sistema operativo (p. ej., http://downloads.linux.hpe.com/). Por lo general, estas herramientas pueden enviar correos electrónicos directamente, o se puede configurar con un script. La creación de scripts y la configuración de herramientas específicas del proveedor están fuera del ámbito de este artículo.
Otra opción es la vigilancia física o por cámara. Si va a cambiar cintas todos los días y puede comprobar físicamente los LEDs de estado del servidor de repositorio reforzado, entonces esto puede ser una solución alternativa. También he oído hablar de clientes que instalaron cámaras que apuntan al servidor de repositorio reforzado. A continuación, el cliente comprueba periódicamente los LED de los discos a través de la cámara.
Conclusión
Almacenar backups de Veeam en un almacenamiento inmutable o compatible con WORM con Veeam es sencillo. Seleccionar el hardware del servidor puede ser un desafío porque hay muchos proveedores y opciones. Se pueden limitar las opciones y acelerar la decisión siguiendo estos pasos:
- Calcule el espacio en disco que necesita en el repositorio
- Seleccione su distribución de Linux preferida (y compatible con Veeam) (Ubuntu y RHEL son las más populares entre los clientes de Veeam)
- Consulte la lista de compatibilidad de hardware de la distribución Linux para encontrar algunos fabricantes/modelos de servidor
- Hable con el proveedor del servidor para que le proporcione una solución que se adapte a sus necesidades
Si no hay asesoramiento del lado del proveedor del servidor, siga los siguientes puntos:
- Si utiliza SSD, las IOPS no son un problema. Si utiliza discos rotatorios, tenga en cuenta los límites de E/S y no solo el espacio en disco. No hay una regla estricta para calcular cuánta velocidad puede ofrecer un disco, porque depende del patrón de acceso (secuencial frente a aleatorio). Los cálculos conservadores se sitúan entre 10 y 50 MByte/s por disco en un RAID 60. Con lecturas secuenciales, un disco NL-SAS de 7k puede ofrecer 80 MByte/s o incluso más (esto incluye toda la sobrecarga RAID).
- Tarjeta de red 2X con la velocidad de enlace calculada anteriormente
- Para la CPU y la RAM, puede consultar las fórmulas disponibles en la guía de mejores prácticas. En la mayoría de los casos, se puede ahorrar tiempo simplemente con dos CPU de entre 16 y 24 núcleos cada una y 128 GB de RAM. Para los servidores de alta densidad, con unos 60 discos o más, la mayoría de los proveedores instalan entre 192 y 256 GB de RAM.
No se complique: utilice servidores con discos internos. Este enfoque se escala linealmente, porque con cada nuevo nodo de repositorio reforzado, hay más CPU, RAM, RAID, red, espacio en disco y rendimiento de E/S. Es un diseño simple y probado.