Arquitetura de conectividade em Base de Dados do Azure para MySQL

APLICA-SE A: Base de Dados do Azure para MySQL - Servidor Único

Importante

Base de Dados do Azure para MySQL - O Servidor Único está no caminho da reforma. Recomendamos vivamente que faça upgrade para Base de Dados do Azure para MySQL - Servidor Flexível. Para obter mais informações sobre migração para Base de Dados do Azure para MySQL - Servidor Flexível, veja o que está a acontecer com Base de Dados do Azure para MySQL Servidor Único?

Este artigo explica a arquitetura de conectividade Base de Dados do Azure para MySQL e como o tráfego é direcionado para o seu Base de Dados do Azure para MySQL instância de clientes dentro e fora de Azure.

Arquitetura de conectividade

A ligação ao seu Base de Dados do Azure para MySQL é estabelecida através de um gateway que é responsável por encaminhar as ligações recebidas para a localização física do seu servidor nos nossos clusters. O diagrama seguinte ilustra o fluxo de tráfego.

Visão geral da arquitetura de conectividade

À medida que o cliente se conecta à base de dados, o fio de ligação ao servidor resolve-se com o endereço IP gateway. O portal ouve no endereço IP na porta 3306. Dentro do aglomerado de bases de dados, o tráfego é encaminhado para Base de Dados do Azure para MySQL apropriado. Portanto, para se conectar ao seu servidor, como a partir de redes corporativas, é necessário abrir a firewall do lado do cliente para permitir que o tráfego de saída possa chegar aos nossos gateways. Abaixo pode encontrar uma lista completa dos endereços IP utilizados pelos nossos gateways por região.

endereços IP gateway Base de Dados do Azure para MySQL

O serviço gateway é hospedado em grupo de nódoas apátridas sentadas atrás de um endereço IP, que o seu cliente alcançaria primeiro quando tentasse ligar-se a um servidor Base de Dados do Azure para MySQL.

Como parte da manutenção contínua do serviço, vamos atualizar periodicamente hardware compute hospedando os gateways para garantir que fornecemos a experiência mais segura e performante. Quando o hardware gateway é renovado, um novo anel dos nós de computação é construído primeiro. Este novo anel serve o tráfego de todos os servidores Base de Dados do Azure para MySQL recém-criados e terá um endereço IP diferente dos anéis de gateway mais antigos da mesma região para diferenciar o tráfego. Uma vez que o novo anel esteja totalmente funcional, o hardware gateway mais antigo que serve os servidores existentes está planeado para ser desativado. Antes de desativar um hardware gateway, os clientes que executam os seus servidores e que se conectam a anéis de gateway mais antigos serão notificados por e-mail e no portal do Azure, com três meses de antecedência antes do desmantelamento. O desmantelamento de gateways pode afetar a conectividade dos seus servidores se

  • Você codifica os endereços IP gateway na cadeia de ligação da sua aplicação. Não é recomendado. Deverá utilizar o nome de domínio totalmente qualificado (FQDN) do seu servidor no formato <servername>.mysql.database.azure.com, na cadeia de ligação para a sua aplicação.
  • Não atualiza os novos endereços IP gateway na firewall do lado do cliente para permitir que o tráfego de saída possa chegar aos nossos novos anéis de gateway.

A tabela que se segue lista os endereços IP gateway do Base de Dados do Azure para MySQL gateway para todas as regiões de dados. As informações mais atualizadas dos endereços IP gateway para cada região são mantidas no quadro abaixo. Na tabela abaixo, as colunas representam o seguinte:

  • Endereços IP gateway: Esta coluna lista os atuais endereços IP dos gateways alojados na última geração de hardware. Se estiver a providenciar um novo servidor, recomendamos que abra a firewall do lado do cliente para permitir o tráfego de saída para os endereços IP listados nesta coluna.
  • Endereços IP gateway (desativação): Esta coluna lista os endereços IP dos gateways alojados numa geração mais antiga de hardware que está a ser desativada neste momento. Se estiver a providenciar um novo servidor, pode ignorar estes endereços IP. Se tiver um servidor existente, continue a manter a regra de saída para a firewall para estes endereços IP, uma vez que ainda não o desativamos. Se deixar cair as regras de firewall para estes endereços IP, poderá obter erros de conectividade. Em vez disso, espera-se que adicione proactivamente os novos endereços IP listados na coluna de endereços IP gateway à regra de firewall de saída assim que receber a notificação para desmantelamento. Isto irá garantir que quando o seu servidor é migrado para o hardware gateway mais recente, não há interrupções na conectividade com o seu servidor.
  • Endereços IP gateway (desativados): Esta coluna lista os endereços IP dos anéis de gateway, que são desativados e já não estão em operações. Pode remover com segurança estes endereços IP da regra de firewall de saída.
Nome da região Endereços IP gateway Endereços IP gateway (desativação) Endereços IP gateway (desativados)
Austrália Central 20.36.105.0
Centro da Austrália 20.36.113.0
Leste da Austrália 13.75.149.87, 40.79.161.1
Sudeste da Austrália 13.73.109.251, 13.77.49.32, 13.77.48.10
Sul do Brasil 191.233.201.8, 191.233.200.16 104.41.11.5
Canadá Central 13.71.168.32 40.85.224.249, 52.228.35.221
Leste do Canadá 40.86.226.166, 52.242.30.154
E.U.A. Central 23.99.160.139, 52.182.136.37, 52.182.136.38 13.67.215.62
Leste da China 139.219.130.35
China Leste 2 40.73.82.1, 52.130.120.89
China Leste 3 52.131.155.192
Norte da China 139.219.15.17
China Norte 2 40.73.50.0
Norte da China 3 52.131.27.192
Ásia Leste 13.75.33.20, 52.175.33.150, 13.75.33.20, 13.75.33.21
E.U.A. Leste 40.71.8.203, 40.71.83.113 40.121.158.30 191.238.6.43
E.U.A. Leste 2 40.70.144.38, 52.167.105.38 52.177.185.181
França Central 40.79.137.0, 40.79.129.1
Sul de França 40.79.177.0
Alemanha Central 51.4.144.100
Norte da Alemanha 51.116.56.0
Alemanha Nordeste 51.5.144.179
Alemanha Centro-Oeste 51.116.152.0
Índia Central 104.211.96.159
Índia do Sul 104.211.224.146
Oeste da Índia 104.211.160.80
Leste do Japão 40.79.192.23, 40.79.184.8 13.78.61.196
Oeste do Japão 191.238.68.11, 40.74.96.6, 40.74.96.7 104.214.148.156
Coreia do Sul Central 52.231.17.13 52.231.32.42
Sul da Coreia do Sul 52.231.145.3, 52.231.151.97 52.231.200.86
E.U.A. Centro-Norte 52.162.104.35, 52.162.104.36 23.96.178.199
Europa do Norte 52.138.224.6, 52.138.224.7 40.113.93.91 191.235.193.75
Norte da África do Sul 102.133.152.0
Oeste da África do Sul 102.133.24.0
E.U.A. Centro-Sul 104.214.16.39, 20.45.120.0 13.66.62.124 23.98.162.75
Ásia Sudeste 40.78.233.2, 23.98.80.12 104.43.15.0
Norte da Suíça 51.107.56.0
Suíça Oeste 51.107.152.0
E.A.U. Central 20.37.72.64
Norte dos E.A.U. 65.52.248.0
Sul do Reino Unido 51.140.144.32, 51.105.64.0 51.140.184.11
Oeste do Reino Unido 51.141.8.11
E.U.A. Centro-Oeste 13.78.145.25, 52.161.100.158
Europa Ocidental 13.69.105.208, 104.40.169.187 40.68.37.158 191.237.232.75
E.U.A. Oeste 13.86.216.212, 13.86.217.212 104.42.238.205 23.99.34.75
E.U.A. Oeste 2 13.66.136.195, 13.66.136.192, 13.66.226.202
EUA Ocidental 20.150.184.2

Redirecionamento de conexão

Base de Dados do Azure para MySQL suporta uma política adicional de conexão, reorientação, que ajuda a reduzir a latência da rede entre aplicações de clientes e servidores MySQL. Com a reorientação, e após a sessão inicial de TCP ser estabelecida para o servidor Base de Dados do Azure para MySQL, o servidor devolve o endereço de backend do nó que hospeda o servidor MySQL ao cliente. Posteriormente, todos os pacotes subsequentes fluem diretamente para o servidor, contornando o gateway. À medida que os pacotes fluem diretamente para o servidor, a latência e a produção melhoraram o desempenho.

Esta funcionalidade é suportada em servidores Base de Dados do Azure para MySQL com as versões 5.6, 5.7 e 8.0.

O suporte para a reorientação está disponível na extensão php mysqlnd_azure , desenvolvida pela Microsoft, e está disponível em PECL. Consulte o artigo de reorientação configurante para obter mais informações sobre como utilizar a reorientação nas suas aplicações.

Importante

O suporte para a reorientação na extensão php mysqlnd_azure está atualmente em pré-visualização.

Perguntas mais frequentes

O que precisa de saber sobre esta manutenção planeada?

Esta é apenas uma mudança de DNS, o que a torna transparente para os clientes. Enquanto o endereço IP para FQDN é alterado no servidor DNS, a cache DE DNS local será atualizada dentro de 5 minutos, e é feita automaticamente pelos sistemas operativos. Após a atualização do DNS local, todas as novas ligações ligar-se-ão ao novo endereço IP, todas as ligações existentes permanecerão ligadas ao antigo endereço IP sem interrupção até que os antigos endereços IP estejam totalmente desativados. O antigo endereço IP demorará aproximadamente três a quatro semanas antes de ser desativado; portanto, não deve ter qualquer efeito sobre as aplicações do cliente.

O que estamos a desmantelar?

Só os nós gateway serão desativados. Quando os utilizadores se ligam aos seus servidores, a primeira paragem da ligação é para o nó gateway, antes de a ligação ser reencaminhada para o servidor. Estamos a desativar anéis de gateway antigos (não anéis de inquilinos onde o servidor está a funcionar) referem-se à arquitetura de conectividade para mais esclarecimentos.

Como pode validar se as suas ligações vão para os antigos nós de gateway ou novos nós de gateway?

Ping fQDN do seu servidor, por exemplo ping xxx.mysql.database.azure.com. Se o endereço IP devolvido for um dos IPs listados nos endereços IP gateway (desativação) no documento acima, significa que a sua ligação está a passar pelo antigo portal. Contrariamente, se o endereço IP devolvido for um dos IPs listados nos endereços IP gateway, significa que a sua ligação está a passar pelo novo portal.

Pode também testar por PSPing ou TCPPing o servidor de base de dados da sua aplicação de cliente com a porta 3306 e garantir que o endereço IP de devolução não é um dos endereços IP de desmantelamento

Como devo proceder para saber quando a manutenção acabou e receberei outra notificação quando os antigos endereços IP forem desativados?

Receberá um e-mail para informá-lo quando começarmos os trabalhos de manutenção. A manutenção pode demorar até um mês, dependendo do número de servidores que precisamos para migrar em regiões al. Prepare o seu cliente para se ligar ao servidor de base de dados utilizando o FQDN ou utilizando o novo endereço IP a partir da tabela acima.

O que faço se as aplicações do meu cliente ainda estiverem ligadas ao antigo servidor de gateway?

Isto indica que as suas aplicações se ligam ao servidor usando o endereço IP estático em vez de FQDN. Reveja as cadeias de ligação e a definição de agrupamento de ligação, a definição AKS ou mesmo no código fonte.

Há algum impacto nas minhas ligações à aplicação?

Esta manutenção é apenas uma mudança de DNS, por isso é transparente para o cliente. Uma vez que a cache DNS é atualizada no cliente (automaticamente feita por sistema operativo), toda a nova ligação irá ligar-se ao novo endereço IP e toda a conexão existente continuará a funcionar bem até que o antigo endereço IP seja totalmente desativado, o que várias semanas depois. E a lógica de retenção não é necessária para este caso, mas é bom ver que a aplicação tem a lógica de re-tória configurada. Utilize o FQDN para ligar ao servidor de base de dados ou ative a lista dos novos "endereços IP gateway" na cadeia de ligação à aplicação. Esta operação de manutenção não vai deixar cair as ligações existentes. Só faz com que os novos pedidos de ligação vão para o novo anel de gateway.

Posso pedir uma janela de tempo específica para a manutenção?

Uma vez que a migração deve ser transparente e sem impacto na conectividade do cliente, esperamos que não haja problema para a maioria dos utilizadores. Reveja a sua aplicação de forma proactiva e certifique-se de que utiliza o FQDN para ligar ao servidor de base de dados ou ativar a lista dos novos "endereços IP gateway" na sua cadeia de ligação de aplicação.

Não, trata-se de um desactivamento de hardware gateway e não tem qualquer relação com ligações privadas ou endereços IP privados, só afetará endereços IP públicos mencionados nos endereços IP de desmantelamento.

Passos seguintes