Se você pretende usar o Amazon FSx for OpenZFS, vale a pena conhecer os Deployment Types e entender como eles funcionam nos bastidores. Hoje existem 3 tipos de implantação suportados: Single-AZ (non-HA), Single-AZ (HA) e Multi-AZ (HA).
Ao configurar um novo file system, você se depara com dois métodos de criação: Quick Create e Standard Create. O Quick Create entrega um processo de configuração simplificado, enquanto o Standard Create traz opções de configuração mais completas.
Na prática, o Standard Create não é só recomendado — ele é obrigatório em dois dos três deployment types. Por isso, acaba sendo a melhor escolha na maioria das implementações, já que dá muito mais controle sobre a configuração do file system desde o início.
Deployment Type Single-AZ (non-HA)
Para usar o Single-AZ (non-HA), é preciso seguir pelo Standard Create, porque esse deployment type não está disponível no Quick Create (veja a figura 1). Você fica com um único file system e, em caso de falha, ele deve se recuperar automaticamente substituindo o componente de infraestrutura com problema. Ainda assim, haverá indisponibilidade durante a falha e perda de dados. Em casos raros, o file system pode ficar irrecuperável e você perderá todos os dados que não tiver feito backup.
Atenção: é preciso garantir que o security group correto esteja anexado e que a regra de security group adequada esteja criada para liberar o tráfego (no Quick Create, o security group padrão da VPC é anexado automaticamente). Isso vale para todos os deployment types.
Figura 1 — a interface de criação do FSx no Quick Create.
Deployment Type Single-AZ (HA)
No Single-AZ (HA), você pode optar tanto pelo Quick Create quanto pelo Standard Create, mas o Standard Create é a melhor opção, já que permite escolher a sub-rede e o security group desejados.
Esse deployment type cria 2 file systems dentro da mesma sub-rede e também um Endpoint IP address (vamos nos aprofundar nesse ponto quando chegarmos ao setup Multi-AZ). Esse Endpoint IP address é o que o FSx usa para tratar um evento de failover nesse deployment type. O FSx tem um nome DNS que aponta para o Endpoint IP address, e esse Endpoint IP address fica anexado à ENI do file system atualmente ativo, como endereço IP secundário. Quando ocorre um failover, o Endpoint IP address é desanexado da ENI do file system ativo e anexado à ENI do file system standby. Assim, o DNS continua apontando para o mesmo IP, só que agora ligado à ENI standby, até que o file system principal se recupere por completo.
Os dois deployment types acima permitem montar o file system nas suas instâncias EC2 com configuração mínima, mas há uma etapa extra ao usar o deployment type Multi-AZ.
Deployment Type Multi-AZ
No deployment type Multi-AZ, é fundamental sempre escolher o Standard Create em vez do Quick Create, porque o Quick Create não permite selecionar as sub-redes nem associar route tables. A associação de route tables ao file system FSx só está disponível no setup Multi-AZ.
Quando o setup Multi-AZ é criado pelo Quick Create, ele usa apenas a route table padrão na associação, ainda que suas sub-redes provavelmente tenham suas próprias route tables. Por que isso importa? Porque, se você criar o setup desse jeito, não vai ter conectividade de rede de cara e a conexão vai dar timeout. Foi exatamente o que aconteceu com um cliente meu que tentou usar o Quick Create — e foi aí que precisamos ir mais a fundo para entender como tudo isso funciona.
Você até pode imaginar que recursos dentro da mesma VPC se conectariam automaticamente ao seu file system FSx pela rota "local" — afinal, é assim que se acessa outros serviços da AWS, como RDS, ElastiCache e instâncias EC2 na sua VPC; até mesmo file systems FSx single-AZ ficam acessíveis dessa forma. Mas aqui vem a surpresa: essa premissa não se aplica neste caso. A rota "local" sozinha não é suficiente para estabelecer conectividade com o seu file system FSx nessas condições.
Como habilitar a conectividade nesse cenário? A resposta rápida: você precisa associar as route tables das sub-redes onde estão suas instâncias EC2 ao file system FSx. Para isso, clique em "manage" ao lado de "route tables" e associe ou desassocie as route tables (veja a figura 2).
Figura 2 — Alteração da associação de route tables do FSx.
Depois de habilitar a conectividade, você vai notar uma entrada de uma ENI dentro da sua route table (veja a figura 3). Essa rota da ENI é o caminho que liga sua instância ao file system FSx. A entrada é composta por um Endpoint IP address e pela ENI do file system atualmente ativo.
Figura 3 — Entrada da ENI dentro das route tables associadas.
Essa configuração existe justamente para viabilizar o failover. Como no Single-AZ (HA), usamos um Endpoint IP address, só que esse IP não pode ser movido entre ENIs quando elas estão em AZs diferentes. Além disso, no Single-AZ (HA) esse Endpoint IP Address é criado dentro de uma sub-rede existente, o que não acontece na implantação Multi-AZ.
Setup Multi-AZ
Quando você configura o FSx no modo Multi-AZ, ele cria dois file systems separados em duas sub-redes de AZs distintas para garantir redundância. Cada file system tem sua própria Elastic Network Interface (ENI). Durante o setup, o FSx precisa de um endereço IP especial (um IP "flutuante") que será usado para failover. Esse será um endereço único (/32).
Você pode definir a faixa de endereços IP pelo parâmetro "EndpointIpAddressRange" ou deixar o FSx escolher automaticamente uma faixa CIDR /28 livre dentro da sua VPC.
Um detalhe importante sobre esse IP flutuante: embora ele esteja dentro da faixa de IPs da sua VPC, é colocado, propositalmente, fora de qualquer faixa de sub-rede existente. Ou seja, do ponto de vista de rede do Amazon EC2, esse IP não está vinculado a nenhum recurso de rede ou sub-rede específica.
Seus file systems e suas ENIs continuam dentro das suas sub-redes, mas o endpoint IP address — o IP flutuante — não está dentro de nenhum CIDR de sub-rede da sua VPC. A entrada na route table é necessária para rotear o tráfego destinado ao IP flutuante até a ENI correta do file system atualmente ativo. Sem essa rota, o tráfego é descartado, já que o IP flutuante não faz parte de nenhuma sub-rede (veja a figura 4).
O motivo dessa configuração é que o FSx não faz failover baseado em DNS por limitações do próprio cliente NFS. As buscas de DNS acontecem apenas uma vez, no momento da montagem. Por isso, o FSx precisa usar um mecanismo de failover diferente do que costuma ser usado em outros serviços Multi-AZ da AWS, como o RDS; caso contrário, os clientes NFS precisariam remontar o file system depois de cada failover.
Resumindo: para habilitar um failover sem interrupções entre os file systems Multi-AZ Primary e Standby, você precisa da entrada da ENI nas route tables das sub-redes onde seus clientes estão implantados. Durante eventos de failover, o FSx atualiza todas as Route Tables de cliente associadas ao FSx, de modo que o IP flutuante (Destination) continue o mesmo, mas o target passe a ser o do file system standby enquanto durar o failover.
Figura 4 — Setup do FSx.
Resumo
Este post mostrou como implementar o Amazon FSx for OpenZFS, as opções de criação, como o networking funciona e por que as implementações se comportam de formas diferentes entre os deployment types.
Tem dúvidas sobre como fazer o FSx for OpenZFS funcionar na sua organização?
Se você ainda está pensando em como aplicar o setup Multi-AZ do OpenZFS — ou qualquer outra solução de infraestrutura no GCP ou na AWS — com sucesso na sua organização, conte com a gente.
Na DoiT International, nosso time é formado exclusivamente por engenheiros sêniores. Somos especialistas em consultoria avançada em nuvem, design de arquitetura e debugging. Seja para dar os primeiros passos com bancos de dados distribuídos, otimizar um sistema existente ou resolver problemas complexos, oferecemos orientação especializada e sob medida para o seu cenário.
Fale com a gente hoje mesmo e descubra como extrair todo o potencial da sua infraestrutura na nuvem.