No momento, nossa configuração é CloudFlare > 1x HAProxy (Dallas,TX), 3x servidores de aplicativos (Dallas,TX), 3x nós MariaDB em um cluster multimestre Galera (Dallas,TX). Os servidores de aplicativos são dimensionados automaticamente horizontalmente para lidar com qualquer tráfego que seja lançado neles. Os servidores HAProxy e DB são dimensionados quando necessário. Os servidores de aplicativos também mantêm caches de leitura SQL individuais para facilitar a carga no banco de dados.
Nosso principal ponto de venda é manter nosso produto online não importa o que aconteça, pois nossa solução atende a serviços de emergência do governo e, como somos uma start-up, nosso orçamento é muito apertado.
Foi inesperado que nosso provedor de nuvem atual (que não podemos alterar nos meses seguintes) esteja enfrentando DDOS por cerca de 30 minutos por mês. Para a nossa situação, nem mesmo um minuto de inatividade é aceitável.
Então, estou pensando em usar algo como CloudFlare > 3x HAProxy (Dallas,TX; Freemont,CA; Newark,NJ) > 6x servidores de aplicativos (Dallas,TX; Freemont,CA; Newark,NJ) > 3 Galera Multi-master + 2 Árbitro Galera (Dallas,TX; Freemont,CA; Newark,NJ; Atlanta,GA; San Francisco,SF).
Isso vai aumentar um pouco nossos custos, e é por isso que eu quero dois Árbitros Galera se eu puder economizar custos e ao mesmo tempo aumentar a estabilidade.
Minha principal pergunta é: quais são os requisitos de recursos para o Galera Arbitrator e valeria a pena ter três nós MariaDB e dois nós do Galera Arbitrator, em vez de apenas três nós MariaDB no cluster? Outra maneira de colocar isso é: vale a pena usar garbd em configurações com mais de três nós de tamanho?
Desde que, em termos de rota, nossos servidores HAProxy escolherão os servidores de aplicativos na mesma região, que posteriormente escolherão o servidor de banco de dados na mesma região. As escolhas são baseadas em uma combinação de tempo de conexão e carga do servidor.
No geral, eu diria que é melhor ampliar o controle de fluxo e as janelas de envio/recebimento e os tempos limite entre os nós.
Se você chegar a um nó, poderá usar set global wsrep_provider_options="pc.bootstrap=TRUE" para transformá-lo em um nó ativo sem garbs. Falta automação, no entanto, é mais durável em geral.
A natureza do DoS pode ter um impacto no design. Se o servidor de aplicativos do site estiver inativo, há uma redução suficiente da carga no nó galera? Ou a taxa de transferência/latência da rede está comprometida?
Recomendando manter um cluster de 3 nós inicialmente. É um grande passo a partir de um site.