Noções básicas sobre cenários híbridos

Concluído

Suponha que sua organização tenha um investimento significativo na infraestrutura do SQL Server local e em data centers locais. Nesse caso, é crucial estar ciente de que usar a nuvem não é uma proposta do tipo tudo ou nada. Há maneiras de usar a infraestrutura local existente em uma capacidade híbrida com o Azure para aumentar a resiliência operacional e reduzir custos.

Implementar uma infraestrutura híbrida também é um excelente primeiro passo na avaliação da computação em nuvem para organizações tradicionalmente locais e céticas com relação à nuvem. É comum que as organizações atuais tenham uma mistura de implantações físicas e virtualizadas do SQL Server no local, que podem se estender para a nuvem como parte de uma solução híbrida. A plataforma do SQL Server híbrida oferece os benefícios dos serviços locais e de nuvem, ela é um meio termo complementar entre eles. O componente de nuvem normalmente usa serviços de IaaS, como o armazenamento ou as máquinas virtuais do SQL Server, conforme indicado abaixo.

Diagrama que descreve a infraestrutura local e a infraestrutura de nuvem superada por uma solução híbrida.

Além de estender soluções locais, os mesmos padrões podem ser aplicados a soluções de nuvem alternativas existentes, permitindo assim implementações híbridas de nuvem para nuvem. Vamos examinar alguns dos cenários híbridos mais comuns para o SQL Server.

Cenários híbridos para o SQL Server

Vamos examinar algumas estratégias para implantar uma solução híbrida para o SQL Server.

Recuperação de desastre

A Recuperação de Desastre é o cenário mais comum para uma implantação híbrida do SQL Server. Recuperação de desastre significa que as organizações garantem a continuidade dos negócios mediante eventos catastróficos. As organizações podem distribuir as implantações entre vários data centers para fazer failover com uma abordagem local. Normalmente, esses data centers residem na mesma região geográfica que a organização, sendo assim suscetíveis a desastres regionais mais significativos. Data centers físicos também são caros para implantar, monitorar e manter. Sem dúvida, o custo de distribuir máquinas virtuais do SQL Server do Azure entre várias regiões geográficas é muito menor do que o de estabelecer um novo data center físico em outra geografia.

Diagrama que descreve o failover local da sede para o data center físico e um failover híbrido para o Azure da rede local.

Nessa abordagem híbrida, o Azure é usado para failover de DR (para uma ou mais regiões), enquanto o processamento cotidiano regular continua usando servidores locais para alta disponibilidade local.

Backups do SQL Server

Os Backups do SQL Server são outro cenário híbrido comum. Os backups podem ser feitos diretamente no Armazenamento do Azure por meio da URL ou do compartilhamento de arquivos do Azure (SMB). Esse cenário protege contra perda de dados quando o armazenamento de backup no local falha. Além disso, esses backups também podem ser restaurados para máquinas virtuais no Azure e testados como parte dos procedimentos de Recuperação de Desastre.

Outro cenário usa o Armazenamento do Azure para armazenar arquivos de dados do SQL Server locais para bancos de dados de usuário. Observe que esses são arquivos de usuários, e não bancos de dados do sistema. Em caso de falha no armazenamento local, os arquivos do usuário são armazenados com segurança na nuvem, evitando a perda de dados. Além disso, usando o armazenamento do Azure, há garantias de confiabilidade internas para que o armazenamento desses arquivos na nuvem seja mais resiliente. Para esse cenário híbrido, é essencial manter a comunicação de rede segura, avaliar a latência de rede da solução e garantir que a conta de armazenamento seja bloqueada usando ACLs e o Microsoft Entra ID.

SQL Servers habilitados para o Azure Arc

Ter SQL Servers habilitados para o Azure Arc estende e centraliza os serviços de gerenciamento do Azure para instâncias do SQL Server hospedadas localmente, em seus data centers, na borda e em ambientes de várias nuvens. Nesse cenário híbrido, o Azure Arc habilita o inventário de todas as implantações do SQL Server registradas e avalia suas configurações, padrões de uso e segurança para fornecer ações e recomendações com base nas melhores práticas. Usando SQL Servers habilitados para o Azure Arc, você obtém os benefícios do gerenciamento de servidores centralizado. Você também obtém alertas de segurança em tempo real do Azure Defender e relatórios de vulnerabilidades sobre SQL Servers locais e seus sistemas operacionais do host. Além disso, o Azure Sentinel pode fornecer mais introspecção com relação a ameaças à segurança, se necessário.

Um diagrama que ilustra uma arquitetura de SQL Server habilitada para Azure Arc.

Considerações de segurança

Ao implantar uma solução SQL híbrida, toda a infraestrutura principal, como o Active Directory e o DNS, precisa existir localmente e no Azure. Além disso, uma comunicação bidirecional segura deve existir entre a rede local e o Azure. Essa comunicação segura pode assumir a forma de uma VPN S2S (site a site) ou de um túnel dedicado do ExpressRoute. Ao avaliar diferentes métodos de conectividade, é vital determinar a quantidade de latência aceitável para sua organização. Independentemente da solução escolhida, a segurança de rede também deve ser um aspecto primordial da implementação.

Um diagrama de conexão que representa um Gateway de VPN site a site para o Azure.

A imagem acima mostra que o benefício de uma solução de VPN S2S é que ela tende a custar menos e sua implementação é uma tarefa comum para os engenheiros de rede. No entanto, com essa solução, toda a comunicação ocorre pela Internet pública e é limitada pela velocidade da internet da organização.

Um diagrama de conexão que representa uma conexão do ExpressRoute com o Azure.

Como podemos ver acima, embora a solução do ExpressRoute tenda a ser mais cara, ela também fornece maior segurança e a menor latência, pois toda a comunicação flui em um canal seguro direto independente da Internet pública. No entanto, detratores comuns dessa solução incluem o custo geral e a incapacidade de aplicar o ExpressRoute entre provedores de nuvem em uma solução de várias nuvens.