Si vas a usar Amazon FSx for OpenZFS, conviene que conozcas los Deployment Types y cómo funcionan por dentro. Hoy se admiten 3 tipos de implementación: Single-AZ (non-HA), Single-AZ (HA) y Multi-AZ (HA).
Al configurar tu nuevo file system te vas a encontrar con dos métodos de creación: Quick Create y Standard Create. Quick Create ofrece un proceso ágil y simplificado, mientras que Standard Create entrega opciones de configuración mucho más completas.
De hecho, Standard Create no solo es lo recomendable: es obligatorio en dos de los tres tipos de implementación. Por eso es la opción preferida en la mayoría de los casos, ya que te da un mayor control sobre la configuración del file system desde el inicio.
Tipo de implementación Single-AZ (non-HA)
Con Single-AZ (non-HA) tienes que usar el procedimiento standard create, ya que este tipo de implementación no aparece al elegir quick create (ver figura 1). Obtienes un único file system y, ante una falla, debería recuperarse automáticamente reemplazando el componente de infraestructura afectado. Sin embargo, habrá downtime durante la falla y se perderán datos. En casos excepcionales, el file system podría quedar irrecuperable y perderías toda la información que no hayas respaldado.
Ten en cuenta que debes adjuntar el security group correcto y crear la regla adecuada para permitir el tráfico (si usas quick create, se adjunta por defecto el security group predeterminado de la VPC). Esto aplica a todos los tipos de implementación.
Figura 1 — interfaz de creación de FSx con Quick create.
Tipo de implementación Single-AZ (HA)
Con Single-AZ (HA) puedes optar por quick create o standard create, pero conviene elegir standard create, porque te permite seleccionar la subnet y el security group que prefieras.
Este tipo de implementación crea 2 file systems dentro de la misma subnet y también una Endpoint IP address (entraremos más en detalle cuando lleguemos a la configuración Multi-AZ). FSx usa esa Endpoint IP address para gestionar un evento de failover en este tipo de implementación. El FSx tiene un nombre DNS que apunta a la Endpoint IP address, y esa Endpoint IP address se adjunta al ENI del file system actualmente activo, como dirección IP secundaria. Cuando ocurre un failover, la Endpoint IP address se desvincula del ENI del file system activo y se adjunta al ENI del file system en standby. Ahora el DNS apunta a la misma IP, pero está vinculada al ENI en standby, hasta que el file system principal se recupere por completo.
Ambos tipos de implementación anteriores te permiten montar el file system en tus instancias EC2 con una configuración mínima, pero al usar Multi-AZ se requiere un paso adicional.
Tipo de implementación Multi-AZ
Con el tipo de implementación Multi-AZ es importante elegir siempre standard create en lugar de quick create, ya que quick create no permite seleccionar las subnets ni asociar route tables. La asociación de route tables al file system de FSx solo está disponible en la configuración Multi-AZ.
Una configuración Multi-AZ creada con quick create solo usará la route table predeterminada para la asociación, mientras que tus subnets probablemente usen sus propias route tables. ¿Por qué importa? Porque si lo configuras así, no vas a tener conectividad de red de entrada y la conexión va a expirar. Eso fue justo lo que le pasó a un cliente que intentó usar quick create, y ahí fue donde tuvimos que profundizar para entender cómo funciona realmente.
Podrías esperar que los recursos dentro de la misma VPC se conecten automáticamente al file system de FSx a través de la ruta 'local'; al fin y al cabo, así llegas a otros servicios de AWS como RDS, ElastiCache e instancias EC2 en tu VPC, e incluso a los file systems FSx Single-AZ. Sin embargo, aquí viene el giro inesperado: ese supuesto no se cumple en este caso. La ruta 'local' por sí sola no basta para establecer conectividad con el file system de FSx en estas condiciones.
¿Cómo se habilita la conectividad en este escenario? La respuesta corta: necesitas asociar las route tables de las subnets donde residen tus instancias EC2 con el file system de FSx. Para hacerlo, haz clic en "manage" junto a "route tables" y asocia o desasocia las route tables (ver figura 2).
Figura 2 — Cambio de asociación de route tables en FSx.
Una vez habilitada la conectividad, vas a notar una entrada de un ENI dentro de tu route table (ver figura 3). Esa ruta del ENI es la forma en que llegas desde tu instancia hasta el file system de FSx. La entrada se compone de una Endpoint IP address y el ENI del file system actualmente activo.
Figura 3 — Entrada del ENI dentro de tus route tables asociadas.
Esto se configura así para habilitar el procedimiento de failover. Al igual que en Single-AZ (HA), se usa una Endpoint IP address; sin embargo, esa IP no se puede mover entre ENIs cuando están en distintas AZs. Además, en Single-AZ (HA) esa Endpoint IP Address se crea dentro de una subnet existente, cosa que no ocurre en la implementación Multi-AZ.
Configuración Multi-AZ
Cuando configuras FSx en modo Multi-AZ, se crean dos file systems independientes en dos subnets de AZs distintas para dar redundancia. Cada file system tiene su propia Elastic Network Interface (ENI). Durante la configuración, FSx necesita una dirección IP especial (una IP "flotante") que se utilizará para el failover. Esta IP es una única dirección (/32).
Puedes definir el rango de IPs tú mismo con el parámetro 'EndpointIpAddressRange', o dejar que FSx elija automáticamente un rango CIDR /28 sin usar dentro de tu VPC.
Un detalle importante sobre esta IP flotante: aunque pertenece al rango de IPs de tu VPC, se ubica intencionalmente fuera de cualquier rango de subnet existente. Esto quiere decir que, desde la perspectiva de red de Amazon EC2, esta IP no está vinculada a ningún recurso de red ni subnet específica.
Tus file systems y sus ENIs siguen estando dentro de tus subnets, pero la endpoint IP address —la IP flotante— no se encuentra dentro de ningún CIDR de subnet de tu VPC. La entrada en la route table es necesaria para enrutar el tráfico dirigido a la IP flotante hacia el ENI correcto del file system actualmente activo. Sin esa ruta, el tráfico se descarta, ya que la IP flotante no forma parte de ninguna subnet (ver figura 4).
Se configura así porque FSx no hace failover basado en DNS, debido a las limitaciones de failover del cliente NFS. Las búsquedas DNS se hacen una sola vez, en el momento del mount. Por eso FSx debe usar un mecanismo de failover distinto al que emplean otros servicios Multi-AZ de AWS como RDS; de lo contrario, los clientes NFS tendrían que volver a montar el sistema después de cada failover.
En resumen, para lograr un failover sin interrupciones entre los file systems Primary y Standby de Multi-AZ, necesitas la entrada del ENI en las route tables de las subnets donde estén desplegados tus clientes. Durante un failover, FSx actualizará todas las Route Tables del cliente asociadas a FSx, de modo que la IP flotante (Destination) se mantenga igual, pero el target pase a ser el del file system en standby mientras dure el evento.
Figura 4 — Configuración de FSx.
Resumen
En este artículo revisamos la implementación de Amazon FSx for OpenZFS, las opciones de creación, cómo funciona el networking y por qué cada tipo de implementación opera de forma distinta.
¿Tienes dudas sobre cómo aprovechar FSx for OpenZFS en tu organización?
Si aún te preguntas cómo aplicar la configuración Multi-AZ de OpenZFS —o cualquier otra solución de infraestructura en GCP o AWS— para que tu organización tenga éxito, estamos para ayudarte.
En DoiT International, nuestro equipo está integrado exclusivamente por talento senior de Engineering. Nos especializamos en consultoría avanzada en la nube, diseño arquitectónico y servicios de debugging. Ya sea que estés dando tus primeros pasos con bases de datos distribuidas, optimizando un sistema existente o resolviendo problemas complejos, ofrecemos asesoría experta y a la medida.
Contáctanos hoy y déjanos ayudarte a sacar el máximo provecho de tu infraestructura en la nube.