Aproveche MinIO al máximo con configuraciones de red óptimas: así es como se hace

MinIO se puede implementar de una manera distribuida que haga un uso eficiente de los recursos de cómputo y almacenamiento de más de una máquina física o virtual. Puede ser MinIO ejecutándose en un entorno de nube pública o privada, como con Amazon Web Services, Google Cloud Platform, la plataforma Azure de Microsoft y muchos otros. MinIO se puede implementar en varios tipos de topologías; en producción, recomendamos la implementación Multi-Node Multi-Drive (MNMD). MinIO recomienda la replicación de sitios para brindar soporte de recuperación y conmutación por error de grado BC/DR para su implementación de sitio único, que puede diseñar y optimizar para su caso de uso.

En una publicación de blog anterior, ya analizamos algunas de las mejores prácticas a utilizar al seleccionar hardware para su implementación MinIO . Tocamos varios aspectos del hardware, desde elegir la mejor región, la unidad correcta, las configuraciones de CPU y memoria, e incluso algunas de las configuraciones de red recomendadas. Si bien abordamos una variedad de mejores prácticas diferentes para el diseño de sistemas, siempre podemos profundizar más y hoy profundizaremos en algunos de los puntos clave sobre el diseño de MinIO para obtener el mejor rendimiento de las unidades y redes.

En esta publicación de blog, profundizaremos en las configuraciones de red con las que puede configurar MinIO para las diferentes estrategias de replicación y topologías de red que se pueden usar para garantizar que sus datos se almacenen y se acceda a ellos de manera eficiente en múltiples implementaciones de MinIO. No necesita realizar ninguna configuración compleja, como configurar NIC vinculadas/duales (lo que agrega una sobrecarga adicional).

Estrategias simples de networking

MinIO es un backend de almacenamiento compatible con S3 para servicios nativos de la nube. En general, pensamos que el tráfico de red se produce entre aplicaciones y el clúster o entre nodos del clúster. Debido al tráfico entre nodos, es fundamental que la conexión en red entre los nodos sea lo más rápida posible. Cada grupo consta de un grupo independiente de nodos con sus propios conjuntos de borrado. MinIO debe consultar cada grupo para determinar el conjunto de borrado correcto al que dirige las operaciones de lectura y escritura, de modo que cada grupo adicional agregue un tráfico internodo mínimo, pero mayor, por llamada. El grupo que contiene el conjunto de borrado correcto responde a la operación y permanece completamente transparente para la aplicación.

Atrás quedaron los días en que las empresas podían arreglárselas con NIC de 1 GbE o 10 GbE. Lo ideal es que la carga de trabajo empresarial moderna utilice NIC de 100 GbE. Dadas las limitaciones físicas y la sobrecarga del protocolo TCP, se esperaría que estas NIC entregaran entre el 80 y el 90 % del ancho de banda disponible, generalmente alrededor de 10 GB/s para NIC de 100 Gbps, hasta 12 GB/s en redes realmente bien equipadas. MinIO no necesita ninguna configuración de red adicional lista para usar para aprovechar todo el ancho de banda mientras escucha en todas las interfaces. MinIO listo para usar admite la escucha en múltiples interfaces de red (NIC).

No necesita ninguna otra configuración especial para la red MinIO, pero opcionalmente, utilizando algunos de los conceptos básicos de red que analizamos anteriormente, puede enrutar el tráfico MinIO a través de una interfaz específica.

En este ejemplo, usaremos un sistema operativo Linux para demostrarlo, pero los conceptos básicos de redes son los mismos sin importar qué sistema operativo uses. La implementación puede variar ligeramente según la configuración de la red, pero esto debería darle una idea.

Primero comenzaremos enumerando la tabla de rutas.

 $ ip route 10.56.98.0/24 dev eth0 proto kernel scope link src 10.56.98.18

Si ha configurado sus servidores MinIO para que estén dentro del rango CIDR 10.56.98.16/28, digamos que una de las direcciones IP del nodo MinIO es 10.56.98.21 que se enrutará a través de la interfaz eth0 porque /28 coincide con la entrada de la tabla de rutas para 10.56 .98.0/24.

Pero si desea enrutar el tráfico MinIO a través de eth1 en lugar de eth0, debemos agregar una ruta específica para el CIDR MinIO para que cualquier tráfico que coincida con esa subred se enrute a través de esa interfaz de red específica.

 $ ip route add 10.56.98.16/28 dev eth1

Una vez agregada la ruta, enumeremos la tabla de enrutamiento nuevamente para ver cómo se ve.

 $ ip route 10.56.98.0/24 dev eth0 proto kernel scope link src 10.56.98.33.18 10.56.98.16/28 dev eth1 scope link

Ahora vemos una ruta para el CIDR /28. Si hace ping al nodo MinIO 10.56.98.21, ahora se enrutará a través de la interfaz eth1. Esto se debe a que cuando hay dos rutas en las que /24 se superpone con /28, generalmente se da preferencia a la ruta con el prefijo más largo (en este caso /28) y tendrá prioridad sobre cualquier otra ruta con prefijo más corto al enrutar el tráfico. Esto se denomina regla de prefijo de coincidencia más larga.

Puede verificar que el tráfico de 10.56.98.16/28 se esté enrutando correctamente si hace ping a 10.56.98.21 y luego verifica el tcpdump como se muestra a continuación. Notará que el tráfico desde la fuente 10.56.98.18 se enruta a través de eth1 a 10.56.98.21.

 $ tcpdump -n -i eth1 icmp … 15:55:44.410450 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 123, length 64 15:55:44.410471 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 123, length 64 15:55:45.434489 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 124, length 64 15:55:45.434518 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 124, length 64 15:55:46.458490 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 125, length 64 15:55:46.458520 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 125, length 64

Como puede ver con MinIO, no se necesitan puertos ni servicios especiales adicionales para lograr la separación del tráfico. MinIO está diseñado teniendo en cuenta la simplicidad y siempre estamos pensando en construir versus comprar. En este caso, en lugar de diseñar algo complejo como un servicio de puerta de enlace, MinIO aprovecha los conceptos básicos de red que ya están disponibles en la capa del sistema operativo para lograr el mismo resultado con tan poca sobrecarga como posible.

Podemos llevar esta idea un paso más allá. Hoy en día los servidores tienen al menos 2 interfaces con la opción de agregar más. Entonces, en lugar de que el tráfico de la aplicación pase por las mismas interfaces que MinIO, puede hacer que su aplicación también se ejecute en un bloque CIDR separado (elija un bloque que sea apropiado para el tamaño de su aplicación). Esta separación garantiza que el tráfico MinIO para replicación y reequilibrio no afecte el rendimiento de la aplicación y viceversa. También le brinda la capacidad de monitorear y rastrear el tráfico para garantizar que MinIO siempre tenga la capacidad y el ancho de banda que necesita para realizar sus operaciones sin afectar su rendimiento.

Pero ¿qué pasa si tienes MinIO en diferentes sitios o regiones? ¿Cómo se puede configurar de forma eficaz para garantizar que no haya cuellos de botella en el rendimiento? Bueno, existen varios tipos diferentes de configuraciones de replicación que MinIO ofrece para algunos de los casos de uso más estrictos que existen.

Una de las estrategias de replicación más prolíficas es la replicación de sitio a sitio. Esto le permite iniciar MinIO con un solo clúster y expandirlo a un número N a medida que aumenta la necesidad. Suponga que tiene una aplicación ETL/ELT que se ejecuta en 3 sitios diferentes. Generalmente, los datos solo están disponibles en una de las regiones y las otras regiones necesitan extraer enormes volúmenes de datos entre regiones para ejecutar su proceso. No hace falta decir que esto no sólo es muy ineficiente sino que ejerce una enorme presión sobre la infraestructura de red y potencialmente causa cuellos de botella para otras aplicaciones que comparten la WAN.

En una configuración de replicación de sitio a sitio, los datos se escriben solo en el clúster MinIO del primer sitio. El proceso de replicación copiará los datos a los otros sitios automáticamente. No es necesario realizar cambios adicionales en la aplicación ETL/ELT. Simplemente apunte los trabajos en cada sitio a su respectivo clúster MinIO respaldado por un proxy inverso como Nginx y las lecturas serán mucho más rápidas de lo que serían a través de WAN en todas las regiones, como se muestra a continuación.

Pero eso plantea la pregunta: ¿es posible ajustar aún más el tráfico? Digamos que agrega el archivo de datos al sitio 1, lo replicará inmediatamente en otros sitios sin importar la hora del día. Podría ser durante el pico cuando quizás se estén ejecutando otros trabajos ETL/ELT y simultáneamente se estén utilizando recursos de red para replicar datos que podrían no usarse hasta el día siguiente, cuando se supone que se ejecutará el siguiente lote. ¿Qué se puede hacer en ese caso? Aquí es donde la replicación por lotes de MinIO resulta útil. La replicación por lotes le permite elegir el tipo de datos que desea replicar en un momento específico, es completamente configurable. En este caso, se puede configurar un trabajo de replicación por lotes para que se ejecute fuera del horario laboral, cuando el tráfico es mínimo. Como los tiempos de acceso a las aplicaciones pueden variar a lo largo del día, la semana e incluso el mes, aquí es donde resulta útil monitorear el tráfico de la red MinIO para que pueda configurar su trabajo por lotes para que se ejecute exactamente en el momento adecuado. Puede implementar sitios pares en diferentes racks, centros de datos o regiones geográficas para admitir funciones como BC/DR o rendimiento de lectura/escritura geolocal en un almacén de objetos MinIO distribuido globalmente.

Pensamientos finales

En resumen, la arquitectura de red de MinIO es una de las más simples y directas que existen. En lugar de reinventar la rueda, MinIO utiliza conceptos básicos de redes para lograr la paridad con algunos de los otros almacenes de datos con una configuración compleja de red y puerta de enlace que es casi imposible de depurar. No importa cuántas veces depures el mismo problema, sentirás que es la primera vez que lo encuentras debido a la naturaleza ofuscada de la arquitectura. Más bien, MinIO se centra en abstracciones de nivel superior que le quitan al desarrollador de la aplicación la carga de tener que mantener la replicación de datos y, más bien, centrarse en almacenar y procesar los datos.

Como de costumbre, si tiene alguna pregunta sobre la configuración de la red MinIO o cómo configurarla, asegúrese de comunicarse con nosotros en Slack o, mejor aún, regístrese para obtener la suscripción SUBNET .