Ambientes híbridos, onde uma parte da infraestrutura de banco de dados está localizada no local e parte dela está localizada em uma nuvem pública, não são incomuns. Pode haver diferentes razões para usar essa configuração - escalabilidade, flexibilidade, alta disponibilidade, recuperação de desastres. Como implementar essa configuração de maneira adequada? Isso pode ser desafiador, pois você precisa considerar várias peças de um quebra-cabeça que precisam se encaixar. Este blog destina-se a fornecer algumas informações sobre como essa configuração pode ser.
Conectividade
Não entraremos em detalhes aqui porque há muitas maneiras de configurar a conectividade entre sua configuração local e a nuvem pública. Dependerá da infraestrutura que você possui, da nuvem pública que deseja usar e de muitos outros fatores. A gama de opções pode começar com roteadores habilitados para BGP, por meio de VPN de hardware, VPN de software terminando em túneis SSH como forma de conectar temporariamente sua rede às instâncias em uma nuvem pública. O que é importante, não importa o que você vá fazer, o resultado final deve ser uma conectividade completa e transparente da sua rede local para as instâncias localizadas na nuvem pública.
Considerações de alta disponibilidade
A replicação do MySQL é uma ótima maneira de construir sistemas altamente disponíveis, mas vem com limitações significativas. A principal coisa a considerar é o escritor - você pode ter apenas um lugar para enviar suas gravações - o mestre. Não importa como você deseja projetar todo o ambiente, você deve considerar cuidadosamente o posicionamento do mestre. Muito provavelmente você deseja que ele faça parte do ambiente, que contém os hosts do aplicativo. Vamos considerar a seguinte configuração:
Temos uma configuração local com três nós MySQL e dois escravos adicionais localizado na nuvem pública, atuando como um meio de recuperação de desastres para a empresa, fica bastante claro que o nó gravável deve ser colocado com os hosts do aplicativo na parte privada da nuvem. Queremos manter a latência o mais baixa possível para as conexões mais importantes.
Esse tipo de design se concentra na disponibilidade dos bancos de dados - se os nós localizados no local não estiverem disponíveis, os hosts de aplicativos poderão se conectar à parte remota da configuração - nós de banco de dados localizados na nuvem pública. Idealmente, você usaria algum tipo de proxy para isso - ProxySQL é uma das soluções que podem rastrear a topologia e reconfigurar conforme necessário com base na cadeia de replicação existente.
Se você quiser considerar mais uma configuração ativa-ativa onde você tem nós de aplicativos em público e privado, você precisa fazer alguns compromissos, pois as gravações terão que ser transferidas pela WAN, da nuvem pública para a nuvem privada (ou vice-versa, se seu local principal onde você opera na nuvem pública).
Novamente, ProxySQL é o proxy de escolha. O que é ótimo, o ProxySQL pode ser configurado como um cluster ProxySQL, garantindo que as alterações de configuração introduzidas em um nó sejam replicadas nos nós ProxySQL restantes.
Tratamento de falhas
Vamos considerar alguns cenários de falha. Antes de mais nada, temos que ter em mente que a replicação assíncrona do MySQL não tem reconhecimento de cluster, portanto, a divisão da rede é algo que deve ser tratado manualmente - caberá ao usuário tomar a decisão e puxar o switch para promover um dos os escravos no ambiente que está disponível. Cabe também ao usuário garantir que o ambiente, que perdeu a conectividade de rede, se comportará como deveria e não continuará operando.
Se a parte privada da nuvem ficar indisponível, como mencionamos anteriormente, será necessária uma ação manual para promover um dos escravos a se tornar um novo mestre. Em seguida, todos os servidores de aplicação web restantes localizados na nuvem pública, utilizando ProxySQL local, terão seu tráfego redirecionado para o novo master e todos os slaves restantes. Por outro lado, como perdemos três dos cinco nós MySQL, queremos expandir a configuração da nuvem pública - o ClusterControl pode ajudá-lo a adicionar nós adicionais ao seu cluster com eficiência.
Outro cenário pode ser que o gravador tenha travado enquanto a conectividade entre nossa configuração local e a nuvem pública funciona bem.
Em tal cenário, queremos promover um dos escravos para se tornar um novo mestre. Dependendo dos requisitos, também podemos querer que o novo mestre seja promovido entre nós em uma determinada parte do ambiente. O ClusterControl tem a capacidade de colocar na lista branca ou negra os nós para o failover, garantindo que você tenha controle total sobre o processo de failover e que possa escolher quais nós devem ser considerados como candidatos para um novo mestre e em qual ordem.
Esperamos que este blog tenha lhe dado uma ideia sobre como funciona a configuração de nuvem híbrida para replicação do MySQL e como ela pode protegê-lo em caso de falhas no banco de dados ou na rede.
