Padrões de aplicativo e estratégias de desenvolvimento para o SQL Server em Máquinas Virtuais do Azure

Aplica-se a:SQL Server na VM do Azure

Nota

O Azure tem dois modelos de implementação diferentes para criar e trabalhar com os recursos: Resource Manager e clássico. Este artigo inclui os dois modelos, mas a Microsoft recomenda que a maioria das implementações novas utilizem o modelo Resource Manager.

Descrição geral

Determinar qual padrão ou padrões de aplicativo usar para seus aplicativos baseados no SQL Server em um ambiente do Azure é uma decisão de design importante e requer uma compreensão sólida de como o SQL Server e cada componente de infraestrutura do Azure trabalham juntos. Com o SQL Server nos Serviços de Infraestrutura do Azure, você pode migrar, manter e monitorar facilmente seus aplicativos existentes do SQL Server criados no Windows Server para máquinas virtuais (VMs) no Azure.

O objetivo deste artigo é fornecer aos arquitetos e desenvolvedores de soluções uma base para uma boa arquitetura e design de aplicativos, que eles podem seguir ao migrar aplicativos existentes para o Azure, bem como desenvolver novos aplicativos no Azure.

Para cada padrão de aplicativo, você encontrará um cenário local, sua respetiva solução habilitada para nuvem e as recomendações técnicas relacionadas. Além disso, o artigo discute estratégias de desenvolvimento específicas do Azure para que você possa projetar seus aplicativos corretamente. Devido aos muitos padrões de aplicativos possíveis, recomenda-se que arquitetos e desenvolvedores escolham o padrão mais apropriado para seus aplicativos e usuários.

Colaboradores técnicos: Luis Carlos Vargas Herring, Madhan Arumugam Ramakrishnan

Revisores técnicos: Corey Sanders, Drew McDaniel, Narayan Annamalai, Nir Mashkowski, Sanjay Mishra, Silvano Coriani, Stefan Schackow, Tim Hickey, Tim Wieman, Xin Jin

Introdução

Você pode desenvolver muitos tipos de aplicativos de n camadas separando os componentes das diferentes camadas de aplicativos em máquinas diferentes, bem como em componentes separados. Por exemplo, você pode colocar o aplicativo cliente e os componentes de regras de negócios em uma máquina, a camada da Web front-end e os componentes da camada de acesso a dados em outra máquina e uma camada de banco de dados back-end em outra máquina. Esse tipo de estruturação ajuda a isolar cada camada uma da outra. Se você alterar a origem dos dados, não precisará alterar o cliente ou o aplicativo Web, mas apenas os componentes da camada de acesso a dados.

Um aplicativo típico de n camadas inclui a camada de apresentação, a camada de negócios e a camada de dados:

Escalão de serviço	Description
Apresentação	A camada de apresentação (camada da Web, camada front-end) é a camada na qual os usuários interagem com um aplicativo.
Negócio	A camada de negócios (camada intermediária) é a camada que a camada de apresentação e a camada de dados usam para se comunicar entre si e inclui a funcionalidade principal do sistema.
Dados	A camada de dados é basicamente o servidor que armazena os dados de um aplicativo (por exemplo, um servidor que executa o SQL Server).

As camadas de aplicação descrevem os agrupamentos lógicos da funcionalidade e dos componentes de uma aplicação; enquanto as camadas descrevem a distribuição física da funcionalidade e dos componentes em servidores físicos separados, computadores, redes ou locais remotos. As camadas de um aplicativo podem residir no mesmo computador físico (a mesma camada) ou podem ser distribuídas em computadores separados (n camadas), e os componentes em cada camada se comunicam com componentes em outras camadas através de interfaces bem definidas. Você pode pensar no termo camada como referindo-se a padrões de distribuição física, como duas camadas, três camadas e n camadas. Um padrão de aplicativo de 2 camadas contém duas camadas de aplicativo: servidor de aplicativos e servidor de banco de dados. A comunicação direta acontece entre o servidor de aplicativos e o servidor de banco de dados. O servidor de aplicativos contém componentes da camada da Web e da camada de negócios. No padrão de aplicativo de 3 camadas, há três camadas de aplicativo: servidor Web, servidor de aplicativos, que contém a camada de lógica de negócios e/ou componentes de acesso a dados da camada de negócios, e o servidor de banco de dados. A comunicação entre o servidor Web e o servidor de banco de dados acontece através do servidor de aplicativos. Para obter informações detalhadas sobre camadas e camadas de aplicativos, consulte Microsoft Application Architecture Guide.

Antes de começar a ler este artigo, você deve ter conhecimento sobre os conceitos fundamentais do SQL Server e do Azure. Para obter informações, consulte Manuais Online do SQL Server, SQL Server em Máquinas Virtuais do Azure e Azure.com.

Este artigo descreve vários padrões de aplicativos que podem ser adequados para seus aplicativos simples, bem como para os aplicativos corporativos altamente complexos. Antes de detalhar cada padrão, recomendamos que você se familiarize com os serviços de armazenamento de dados disponíveis no Azure, como o Armazenamento do Azure, o Banco de Dados SQL do Azure e o SQL Server em uma máquina virtual do Azure. Para tomar as melhores decisões de design para seus aplicativos, entenda quando usar qual serviço de armazenamento de dados claramente.

Escolha SQL Server em Máquinas Virtuais do Azure, quando:

• Você precisa de controle no SQL Server e no Windows. Por exemplo, isso pode incluir a versão do SQL Server, hotfixes especiais, configuração de desempenho, etc.

• Você precisa de uma compatibilidade total com o SQL Server e deseja mover aplicativos existentes para o Azure no estado em que se encontram.

• Você deseja aproveitar os recursos do ambiente do Azure, mas o Banco de Dados SQL do Azure não oferece suporte a todos os recursos que seu aplicativo exige. Tal poderá incluir os seguintes domínios:

  • Tamanho do banco de dados: no momento em que este artigo foi atualizado, o Banco de dados SQL oferece suporte a um banco de dados de até 1 TB de dados. Se seu aplicativo exigir mais de 1 TB de dados e você não quiser implementar soluções de fragmentação personalizadas, é recomendável usar o SQL Server em uma máquina virtual do Azure. Para obter as informações mais recentes, consulte Dimensionamento do Banco de Dados SQL do Azure, Modelo de compra baseado em DTU e Modelo de compra baseado em vCore (visualização).
  • Conformidade com HIPAA: os clientes da área de saúde e os ISVs (Fornecedores Independentes de Software) podem escolher o SQL Server em Máquinas Virtuais do Azure em vez do Banco de Dados SQL do Azure porque o SQL Server em Máquinas Virtuais do Azure é coberto pelo BAA (Business Associate Agreement) da HIPAA. Para obter informações sobre conformidade, consulte Central de Confiabilidade do Microsoft Azure: Conformidade.
  • Recursos no nível da instância: no momento, o Banco de dados SQL não oferece suporte a recursos que vivem fora do banco de dados (como servidores vinculados, trabalhos do agente, FileStream, Service Broker, etc.). Para obter mais informações, consulte Diretrizes e limitações do Banco de Dados SQL do Azure.

1 camada (simples): Máquina virtual única

Neste padrão de aplicativo, você implanta seu aplicativo e banco de dados do SQL Server em uma máquina virtual autônoma no Azure. A mesma máquina virtual contém seu aplicativo cliente/Web, componentes de negócios, camada de acesso a dados e o servidor de banco de dados. A apresentação, os negócios e o código de acesso a dados são logicamente separados, mas estão fisicamente localizados em uma máquina de servidor único. A maioria dos clientes começa com esse padrão de aplicativo e, em seguida, expande adicionando mais funções Web ou máquinas virtuais ao sistema.

Este padrão de aplicação é útil quando:

• Você deseja executar uma migração simples para a plataforma Azure para avaliar se a plataforma atende aos requisitos do seu aplicativo ou não.
• Você deseja manter todas as camadas de aplicativo hospedadas na mesma máquina virtual no mesmo data center do Azure para reduzir a latência entre as camadas.
• Você deseja provisionar rapidamente ambientes de desenvolvimento e teste por curtos períodos de tempo.
• Você deseja realizar testes de estresse para diferentes níveis de carga de trabalho, mas, ao mesmo tempo, não quer possuir e manter muitas máquinas físicas o tempo todo.

O diagrama a seguir demonstra um cenário local simples e como você pode implantar sua solução habilitada para nuvem em uma única máquina virtual no Azure.

A implantação da camada de negócios (lógica de negócios e componentes de acesso a dados) na mesma camada física da camada de apresentação pode maximizar o desempenho do aplicativo, a menos que você precise usar uma camada separada devido a questões de escalabilidade ou segurança.

Como esse é um padrão muito comum para começar, você pode achar o seguinte artigo sobre migração útil para mover seus dados para sua VM do SQL Server: Guia de migração: SQL Server para SQL Server em Máquinas Virtuais do Azure.

3 camadas (simples): várias máquinas virtuais

Neste padrão de aplicativo, você implanta um aplicativo de 3 camadas no Azure colocando cada camada de aplicativo em uma máquina virtual diferente. Isso fornece um ambiente flexível para cenários de expansão e expansão fáceis. Quando uma máquina virtual contém seu aplicativo cliente/Web, a outra hospeda seus componentes de negócios e a outra hospeda o servidor de banco de dados.

Este padrão de aplicação é útil quando:

• Você deseja executar uma migração de aplicativos de banco de dados complexos para Máquinas Virtuais do Azure.
• Você deseja que diferentes camadas de aplicativos sejam hospedadas em regiões diferentes. Por exemplo, você pode ter bancos de dados compartilhados que são implantados em várias regiões para fins de relatório.
• Você deseja mover aplicativos corporativos de plataformas virtualizadas locais para Máquinas Virtuais do Azure. Para obter uma discussão detalhada sobre aplicativos corporativos, consulte O que é um aplicativo corporativo.
• Você deseja provisionar rapidamente ambientes de desenvolvimento e teste por curtos períodos de tempo.
• Você deseja realizar testes de estresse para diferentes níveis de carga de trabalho, mas, ao mesmo tempo, não quer possuir e manter muitas máquinas físicas o tempo todo.

O diagrama a seguir demonstra como você pode colocar um aplicativo simples de 3 camadas no Azure colocando cada camada de aplicativo em uma máquina virtual diferente.

Nesse padrão de aplicativo, há apenas uma máquina virtual em cada camada. Se você tiver várias VMs no Azure, recomendamos que configure uma rede virtual. A Rede Virtual do Azure cria um limite de segurança confiável e também permite que as VMs se comuniquem entre si através do endereço IP privado. Além disso, certifique-se sempre de que todas as ligações à Internet vão apenas para o nível de apresentação. Ao seguir esse padrão de aplicativo, gerencie as regras do grupo de segurança de rede para controlar o acesso. Para obter mais informações, consulte Permitir acesso externo à sua VM usando o portal do Azure.

No diagrama, os protocolos de Internet podem ser TCP, UDP, HTTP ou HTTPS.

Nota

A configuração de uma rede virtual no Azure é gratuita. No entanto, você será cobrado pelo gateway VPN que se conecta ao local. Essa cobrança é baseada na quantidade de tempo que a conexão está provisionada e disponível.

2 e 3 camadas com escalabilidade horizontal da camada de apresentação

Neste padrão de aplicativo, você implanta o aplicativo de banco de dados de 2 ou 3 camadas nas Máquinas Virtuais do Azure colocando cada camada de aplicativo em uma máquina virtual diferente. Além disso, você expande a camada de apresentação devido ao aumento do volume de solicitações de clientes recebidos.

Este padrão de aplicação é útil quando:

• Você deseja mover aplicativos corporativos de plataformas virtualizadas locais para Máquinas Virtuais do Azure.
• Você deseja expandir a camada de apresentação devido ao aumento do volume de solicitações de clientes recebidos.
• Você deseja provisionar rapidamente ambientes de desenvolvimento e teste por curtos períodos de tempo.
• Você deseja realizar testes de estresse para diferentes níveis de carga de trabalho, mas, ao mesmo tempo, não quer possuir e manter muitas máquinas físicas o tempo todo.
• Você deseja possuir um ambiente de infraestrutura que possa aumentar e diminuir a escala sob demanda.

O diagrama a seguir demonstra como você pode colocar as camadas de aplicativo em várias máquinas virtuais no Azure dimensionando a camada de apresentação devido ao aumento do volume de solicitações de clientes de entrada. Como visto no diagrama, o Balanceador de Carga do Azure é responsável por distribuir o tráfego entre várias máquinas virtuais e também determinar a qual servidor Web se conectar. Ter várias instâncias dos servidores Web atrás de um balanceador de carga garante a alta disponibilidade da camada de apresentação.

Práticas recomendadas para padrões de 2, 3 ou n camadas que têm várias VMs em uma camada

É recomendável colocar as máquinas virtuais que pertencem à mesma camada no mesmo serviço de nuvem e no mesmo conjunto de disponibilidade. Por exemplo, coloque um conjunto de servidores Web em CloudService1 e AvailabilitySet1 e um conjunto de servidores de banco de dados em CloudService2 e AvailabilitySet2. Um conjunto de disponibilidade no Azure permite que você coloque os nós de alta disponibilidade em domínios de falha separados e atualize domínios.

Para aproveitar várias instâncias de VM de uma camada, você precisa configurar o Balanceador de Carga do Azure entre as camadas de aplicativo. Para configurar o Balanceador de Carga em cada camada, crie um ponto de extremidade com balanceamento de carga nas VMs de cada camada separadamente. Para uma camada específica, primeiro crie VMs no mesmo serviço de nuvem. Isso garante que eles tenham o mesmo endereço IP virtual público. Em seguida, crie um ponto de extremidade em uma das máquinas virtuais nessa camada. Em seguida, atribua o mesmo ponto de extremidade às outras máquinas virtuais nessa camada para balanceamento de carga. Ao criar um conjunto com balanceamento de carga, você distribui o tráfego entre várias máquinas virtuais e também permite que o Balanceador de Carga determine qual nó se conectar quando um nó de VM de back-end falhar. Por exemplo, ter várias instâncias dos servidores Web atrás de um balanceador de carga garante a alta disponibilidade da camada de apresentação.

Como prática recomendada, certifique-se sempre de que todas as conexões com a Internet vão primeiro para a camada de apresentação. A camada de apresentação acessa a camada de negócios e, em seguida, a camada de negócios acessa a camada de dados. Para obter mais informações sobre como permitir o acesso à camada de apresentação, consulte Permitir acesso externo à sua VM usando o portal do Azure.

Observe que o Balanceador de Carga no Azure funciona de forma semelhante aos balanceadores de carga em um ambiente local. Para obter mais informações, consulte Balanceamento de carga para serviços de infraestrutura do Azure.

Além disso, recomendamos que você configure uma rede privada para suas máquinas virtuais usando a Rede Virtual do Azure. Isto permite-lhes comunicar entre si através do endereço IP privado. Para obter mais informações, consulte Rede Virtual do Azure.

2 e 3 camadas com escalabilidade horizontal da camada de negócios

Neste padrão de aplicativo, você implanta um aplicativo de banco de dados de 2 ou 3 camadas nas Máquinas Virtuais do Azure colocando cada camada de aplicativo em uma máquina virtual diferente. Além disso, talvez você queira distribuir os componentes do servidor de aplicativos para várias máquinas virtuais devido à complexidade do seu aplicativo.

Este padrão de aplicação é útil quando:

• Você deseja mover aplicativos corporativos de plataformas virtualizadas locais para Máquinas Virtuais do Azure.
• Você deseja distribuir os componentes do servidor de aplicativos para várias máquinas virtuais devido à complexidade do seu aplicativo.
• Você deseja mover aplicativos LOB (linha de negócios) locais pesados de lógica de negócios para as Máquinas Virtuais do Azure. Os aplicativos LOB são um conjunto de aplicativos de computador críticos que são vitais para a execução de uma empresa, como contabilidade, recursos humanos (RH), folha de pagamento, gerenciamento da cadeia de suprimentos e aplicativos de planejamento de recursos.
• Você deseja provisionar rapidamente ambientes de desenvolvimento e teste por curtos períodos de tempo.
• Você deseja realizar testes de estresse para diferentes níveis de carga de trabalho, mas, ao mesmo tempo, não quer possuir e manter muitas máquinas físicas o tempo todo.
• Você deseja possuir um ambiente de infraestrutura que possa aumentar e diminuir a escala sob demanda.

O diagrama a seguir demonstra um cenário local e sua solução habilitada para nuvem. Nesse cenário, você coloca as camadas de aplicativo em várias máquinas virtuais no Azure dimensionando a camada de negócios, que contém a camada de lógica de negócios e os componentes de acesso a dados. Como visto no diagrama, o Balanceador de Carga do Azure é responsável por distribuir o tráfego entre várias máquinas virtuais e também determinar a qual servidor Web se conectar. Ter várias instâncias dos servidores de aplicativos atrás de um balanceador de carga garante a alta disponibilidade da camada de negócios. Para obter mais informações, consulte Práticas recomendadas para padrões de aplicativos de 2, 3 ou n camadas que têm várias máquinas virtuais em uma camada.

2 e 3 camadas com escalabilidade horizontal de apresentação e de negócios e HADR

Neste padrão de aplicativo, você implanta um aplicativo de banco de dados de 2 ou 3 camadas nas Máquinas Virtuais do Azure distribuindo a camada de apresentação (servidor Web) e os componentes da camada de negócios (servidor de aplicativos) para várias máquinas virtuais. Além disso, você implementa soluções de alta disponibilidade e recuperação de desastres (HADR) para seus bancos de dados em Máquinas Virtuais do Azure.

Este padrão de aplicação é útil quando:

• Você deseja mover aplicativos corporativos de plataformas virtualizadas locais para o Azure implementando recursos de alta disponibilidade e recuperação de desastres do SQL Server.
• Você deseja expandir a camada de apresentação e a camada de negócios devido ao aumento do volume de solicitações de clientes de entrada e à complexidade do seu aplicativo.
• Você deseja provisionar rapidamente ambientes de desenvolvimento e teste por curtos períodos de tempo.
• Você deseja realizar testes de estresse para diferentes níveis de carga de trabalho, mas, ao mesmo tempo, não quer possuir e manter muitas máquinas físicas o tempo todo.
• Você deseja possuir um ambiente de infraestrutura que possa aumentar e diminuir a escala sob demanda.

O diagrama a seguir demonstra um cenário local e sua solução habilitada para nuvem. Nesse cenário, você dimensiona a camada de apresentação e os componentes da camada de negócios em várias máquinas virtuais no Azure. Além disso, você implementa técnicas de alta disponibilidade e recuperação de desastres (HADR) para bancos de dados do SQL Server no Azure.

A execução de várias cópias de um aplicativo em VMs diferentes garante que você esteja balanceando a carga das solicitações entre elas. Quando você tem várias máquinas virtuais, precisa certificar-se de que todas as suas VMs estão acessíveis e em execução em um determinado momento. Se você configurar o balanceamento de carga, o Balanceador de Carga do Azure rastreará a integridade das VMs e direcionará as chamadas de entrada para os nós de VM em funcionamento íntegro corretamente. Para obter informações sobre como configurar o balanceamento de carga das máquinas virtuais, consulte Balanceamento de carga para serviços de infraestrutura do Azure. Ter várias instâncias de servidores Web e de aplicativos por trás de um balanceador de carga garante a alta disponibilidade das camadas de apresentação e de negócios.

Práticas recomendadas para padrões de aplicativos que exigem SQL HADR

Quando você configura soluções de alta disponibilidade e recuperação de desastres do SQL Server em Máquinas Virtuais do Azure, a configuração de uma rede virtual para suas máquinas virtuais usando a Rede Virtual do Azure é obrigatória. As máquinas virtuais dentro de uma Rede Virtual terão um endereço IP privado estável mesmo após um tempo de inatividade do serviço, portanto, você pode evitar o tempo de atualização necessário para a resolução de nomes DNS. Além disso, a rede virtual permite que você estenda sua rede local para o Azure e cria um limite de segurança confiável. Por exemplo, se seu aplicativo tiver restrições de domínio corporativo (como autenticação do Windows, Ative Directory), a configuração da Rede Virtual do Azure será necessária.

A maioria dos clientes, que estão executando código de produção no Azure, estão mantendo réplicas primárias e secundárias no Azure.

Para obter informações abrangentes e tutoriais sobre técnicas de alta disponibilidade e recuperação de desastres, consulte Alta disponibilidade e recuperação de desastres para SQL Server em máquinas virtuais do Azure.

2 camadas e 3 camadas usando Máquinas Virtuais do Azure e Serviços de Nuvem

Neste padrão de aplicativo, você implanta um aplicativo de 2 ou 3 camadas no Azure usando os Serviços de Nuvem do Azure (funções Web e de trabalho - Plataforma como Serviço (PaaS)) e as Máquinas Virtuais do Azure (Infraestrutura como Serviço (IaaS)). Usar os Serviços de Nuvem do Azure para a camada de apresentação/camada de negócios e o SQL Server nas Máquinas Virtuais do Azure para a camada de dados é benéfico para a maioria dos aplicativos em execução no Azure. O motivo é que ter uma instância de computação em execução nos Serviços de Nuvem facilita o gerenciamento, a implantação, o monitoramento e o dimensionamento.

Com os Serviços de Nuvem, o Azure mantém a infraestrutura para você, executa manutenção de rotina, corrige os sistemas operacionais e tenta se recuperar de falhas de serviço e hardware. Quando seu aplicativo precisa de expansão, as opções de expansão automática e manual estão disponíveis para seu projeto de serviço de nuvem, aumentando ou diminuindo o número de instâncias ou máquinas virtuais usadas pelo seu aplicativo. Além disso, você pode usar o Visual Studio local para implantar seu aplicativo em um projeto de serviço de nuvem no Azure.

Em resumo, se você não quiser possuir tarefas administrativas extensas para a camada de apresentação/negócios e seu aplicativo não exigir nenhuma configuração complexa de software ou sistema operacional, use os Serviços de Nuvem do Azure. Se o Banco de Dados SQL do Azure não oferecer suporte a todos os recursos que você está procurando, use o SQL Server em uma máquina virtual do Azure para a camada de dados. Executar um aplicativo nos Serviços de Nuvem do Azure e armazenar dados em Máquinas Virtuais do Azure combina os benefícios de ambos os serviços. Para obter uma comparação detalhada, consulte a seção neste tópico sobre Comparando estratégias de desenvolvimento no Azure.

Neste padrão de aplicativo, a camada de apresentação inclui uma função Web, que é um componente de Serviços de Nuvem em execução no ambiente de execução do Azure e é personalizada para programação de aplicativos Web, conforme suportado pelo IIS e ASP.NET. A camada de negócios ou back-end inclui uma função de trabalho, que é um componente de Serviços de Nuvem em execução no ambiente de execução do Azure e é útil para desenvolvimento generalizado e pode executar processamento em segundo plano para uma função Web. A camada de banco de dados reside em uma máquina virtual do SQL Server no Azure. A comunicação entre a camada de apresentação e a camada de banco de dados acontece diretamente ou por meio da camada de negócios – componentes da função de trabalho.

Este padrão de aplicação é útil quando:

• Você deseja mover aplicativos corporativos de plataformas virtualizadas locais para o Azure implementando recursos de alta disponibilidade e recuperação de desastres do SQL Server.
• Você deseja possuir um ambiente de infraestrutura que possa aumentar e diminuir a escala sob demanda.
• O Banco de Dados SQL do Azure não dá suporte a todos os recursos de que seu aplicativo ou banco de dados precisa.
• Você deseja realizar testes de estresse para diferentes níveis de carga de trabalho, mas, ao mesmo tempo, não quer possuir e manter muitas máquinas físicas o tempo todo.

O diagrama a seguir demonstra um cenário local e sua solução habilitada para nuvem. Nesse cenário, você coloca a camada de apresentação em funções Web, a camada de negócios em funções de trabalho, mas a camada de dados em máquinas virtuais no Azure. A execução de várias cópias da camada de apresentação em diferentes funções da Web garante o balanceamento de carga das solicitações entre elas. Quando combina os Serviços de Nuvem do Azure com as Máquinas Virtuais do Azure, recomendamos que configure também a Rede Virtual do Azure. Com a Rede Virtual do Azure, você pode ter endereços IP privados estáveis e persistentes dentro do mesmo serviço de nuvem na nuvem. Depois de definir uma rede virtual para suas máquinas virtuais e serviços de nuvem, eles podem começar a se comunicar entre si pelo endereço IP privado. Além disso, ter máquinas virtuais e funções Web/de trabalho do Azure na mesma Rede Virtual do Azure fornece baixa latência e conectividade mais segura. Para obter mais informações, consulte O que é um serviço de nuvem.

Como visto no diagrama, o Balanceador de Carga do Azure distribui o tráfego entre várias máquinas virtuais e também determina a qual servidor Web ou servidor de aplicativos se conectar. Ter várias instâncias dos servidores Web e de aplicativos por trás de um balanceador de carga garante a alta disponibilidade da camada de apresentação e da camada de negócios. Para obter mais informações, consulte Práticas recomendadas para padrões de aplicativos que exigem HADR SQL.

Outra abordagem para implementar esse padrão de aplicativo é usar uma função Web consolidada que contenha componentes da camada de apresentação e da camada de negócios, conforme mostrado no diagrama a seguir. Esse padrão de aplicativo é útil para aplicativos que exigem design com monitoração de estado. Como o Azure fornece nós de computação sem estado em funções Web e de trabalho, recomendamos que você implemente uma lógica para armazenar o estado da sessão usando uma das seguintes tecnologias: Azure Caching, Armazenamento de Tabela do Azure ou Banco de Dados SQL do Azure.

Padrão com Máquinas Virtuais do Azure, Banco de Dados SQL do Azure e Serviço de Aplicativo do Azure (Aplicativos Web)

O objetivo principal desse padrão de aplicativo é mostrar como combinar componentes IaaS (infraestrutura como serviço) do Azure com componentes de plataforma como serviço (PaaS) do Azure em sua solução. Esse padrão é focado no Banco de Dados SQL do Azure para armazenamento de dados relacionais. Ele não inclui o SQL Server em uma máquina virtual do Azure, que faz parte da infraestrutura do Azure como uma oferta de serviço.

Neste padrão de aplicativo, você implanta um aplicativo de banco de dados no Azure colocando as camadas de apresentação e de negócios na mesma máquina virtual e acessando um banco de dados nos servidores do Banco de Dados SQL do Azure (Banco de Dados SQL). Você pode implementar a camada de apresentação usando soluções Web tradicionais baseadas no IIS. Ou, você pode implementar uma apresentação combinada e uma camada de negócios usando o Serviço de Aplicativo do Azure.

Este padrão de aplicação é útil quando:

• Você já tem um servidor existente do Banco de dados SQL configurado no Azure e deseja testar seu aplicativo rapidamente.
• Você deseja testar os recursos do ambiente do Azure.
• Você deseja provisionar rapidamente ambientes de desenvolvimento e teste por curtos períodos de tempo.
• Sua lógica de negócios e componentes de acesso a dados podem ser independentes em um aplicativo Web.

O diagrama a seguir demonstra um cenário local e sua solução habilitada para nuvem. Nesse cenário, você coloca as camadas de aplicativo em uma única máquina virtual no Azure e acessa dados no Banco de Dados SQL do Azure.

Se você optar por implementar uma camada combinada de Web e aplicativo usando os Aplicativos Web do Azure, recomendamos que mantenha a camada intermediária ou a camada de aplicativo como bibliotecas de vínculo dinâmico (DLLs) no contexto de um aplicativo Web.

Além disso, revise as recomendações fornecidas na seção Comparando estratégias de desenvolvimento da Web no Azure no final deste artigo para saber mais sobre técnicas de programação.

Padrão de aplicativo híbrido de N camadas

No padrão de aplicativo híbrido de n camadas, você implementa seu aplicativo em várias camadas distribuídas entre o local e o Azure. Portanto, você cria um sistema híbrido flexível e reutilizável, que pode modificar ou adicionar uma camada específica sem alterar as outras camadas. Para estender sua rede corporativa para a nuvem, use o serviço de Rede Virtual do Azure.

Esse padrão de aplicativo híbrido é útil quando:

• Você deseja criar aplicativos que são executados parcialmente na nuvem e em parte no local.
• Você deseja migrar alguns ou todos os elementos de um aplicativo local existente para a nuvem.
• Você deseja mover aplicativos corporativos de plataformas virtualizadas locais para o Azure.
• Você deseja possuir um ambiente de infraestrutura que possa aumentar e diminuir a escala sob demanda.
• Você deseja provisionar rapidamente ambientes de desenvolvimento e teste por curtos períodos de tempo.
• Você quer uma maneira econômica de fazer backups para aplicativos de banco de dados corporativos.

O diagrama a seguir demonstra um padrão de aplicativo híbrido de n camadas que abrange o local e o Azure. Conforme mostrado no diagrama, a infraestrutura local inclui o controlador de domínio dos Serviços de Domínio Ative Directory para dar suporte à autenticação e autorização do usuário. Observe que o diagrama demonstra um cenário, onde algumas partes da camada de dados vivem em um data center local, enquanto algumas partes da camada de dados vivem no Azure. Dependendo das necessidades do seu aplicativo, você pode implementar vários outros cenários híbridos. Por exemplo, você pode manter a camada de apresentação e a camada de negócios em um ambiente local, mas a camada de dados no Azure.

No Azure, você pode usar a ID do Microsoft Entra (anteriormente Azure Ative Directory) para gerenciamento de identidade e acesso ou pode integrar um Ative Directory local existente com a ID do Microsoft Entra. Como visto no diagrama, os componentes da camada de negócios podem se autenticar em várias fontes de dados, incluindo: SQL Server em VMs do Azure por meio de um endereço IP interno privado, SQL Server local por meio da Rede Virtual do Azure ou Banco de Dados SQL do Azure usando as tecnologias de provedor de dados do .NET Framework. Neste diagrama, o Banco de Dados SQL do Azure é um serviço opcional de armazenamento de dados.

No padrão de aplicativo híbrido de n camadas, você pode implementar o seguinte fluxo de trabalho na ordem especificada:

1. Identifique os aplicativos de banco de dados corporativos que precisam ser movidos para a nuvem usando o Microsoft Assessment and Planning (MAP) Toolkit. O MAP Toolkit reúne dados de inventário e desempenho de computadores que você está considerando para virtualização e fornece recomendações sobre planejamento de capacidade e avaliação.

2. Planeje os recursos e a configuração necessários na plataforma Azure, como contas de armazenamento e máquinas virtuais.

3. Configure a conectividade de rede entre a rede corporativa local e a Rede Virtual do Azure. Para configurar a conexão entre a rede corporativa local e uma máquina virtual no Azure, use um dos dois métodos a seguir:

   1. Estabeleça uma conexão entre o local e o Azure por meio de pontos finais públicos em uma máquina virtual no Azure. Esse método fornece uma configuração fácil e permite que você use a autenticação do SQL Server em sua máquina virtual. Além disso, configure as regras do grupo de segurança de rede para controlar o tráfego público para a VM. Para obter mais informações, consulte Permitir acesso externo à sua VM usando o portal do Azure.

   2. Estabeleça uma conexão entre o local e o Azure por meio do túnel da rede virtual privada (VPN) do Azure. Esse método permite estender políticas de domínio para uma máquina virtual no Azure. Além disso, você pode configurar regras de firewall e usar a autenticação do Windows em sua máquina virtual. Atualmente, o Azure dá suporte a VPN segura site a site e conexões VPN ponto a site:

      • Com a conexão segura site a site, você pode estabelecer conectividade de rede entre sua rede local e sua rede virtual no Azure. É recomendável para conectar seu ambiente de data center local ao Azure.
      • Com a conexão segura ponto a site, você pode estabelecer conectividade de rede entre sua rede virtual no Azure e seus computadores individuais em execução em qualquer lugar. É principalmente recomendado para fins de desenvolvimento e teste.

      Para obter informações sobre como se conectar ao SQL Server no Azure, consulte Conectar-se a uma máquina virtual do SQL Server no Azure.

4. Configure trabalhos agendados e alertas que fazem backup de dados locais em um disco de máquina virtual no Azure. Para obter mais informações, consulte Backup e restauração do SQL Server com armazenamento de Blob do Azure e Backup e restauração para SQL Server em máquinas virtuais do Azure.

5. Dependendo das necessidades do seu aplicativo, você pode implementar um dos três cenários comuns a seguir:

   1. Você pode manter seu servidor Web, servidor de aplicativos e dados não confidenciais em um servidor de banco de dados no Azure, enquanto mantém os dados confidenciais no local.
   2. Você pode manter seu servidor Web e o servidor de aplicativos no local, enquanto o servidor de banco de dados em uma máquina virtual no Azure.
   3. Você pode manter seu servidor de banco de dados, servidor Web e servidor de aplicativos local, enquanto mantém as réplicas de banco de dados em máquinas virtuais no Azure. Essa configuração permite que os servidores Web locais ou aplicativos de relatório acessem as réplicas de banco de dados no Azure. Portanto, você pode conseguir reduzir a carga de trabalho em um banco de dados local. Recomendamos que você implemente esse cenário para cargas de trabalho de leitura pesadas e fins de desenvolvimento. Para obter informações sobre como criar réplicas de banco de dados no Azure, consulte Grupos de disponibilidade Always On em alta disponibilidade e recuperação de desastres para SQL Server em máquinas virtuais do Azure.

Comparando estratégias de desenvolvimento da Web no Azure

Para implementar e implantar um aplicativo baseado no SQL Server de várias camadas no Azure, você pode usar um dos dois métodos de programação a seguir:

• Configure um servidor Web tradicional (IIS - Serviços de Informações da Internet) no Azure e acesse bancos de dados no SQL Server em Máquinas Virtuais do Azure.
• Implemente e implante um serviço de nuvem no Azure. Em seguida, certifique-se de que esse serviço de nuvem pode acessar bancos de dados no SQL Server em Máquinas Virtuais do Azure. Um serviço de nuvem pode incluir várias funções Web e de trabalho.

A tabela a seguir fornece uma comparação do desenvolvimento Web tradicional com os Serviços de Nuvem do Azure e os Aplicativos Web do Azure em relação ao SQL Server em Máquinas Virtuais do Azure. A tabela inclui os Aplicativos Web do Azure, pois é possível usar o SQL Server em uma VM do Azure como uma fonte de dados para os Aplicativos Web do Azure por meio de seu endereço IP virtual público ou nome DNS.

	Desenvolvimento Web tradicional em Máquinas Virtuais do Azure	Serviços de nuvem no Azure	Alojamento Web com Aplicações Web do Azure
Migração de aplicativos do local	Aplicativos existentes no estado em que se encontram.	Os aplicativos precisam de funções Web e de trabalho.	Aplicativos existentes no estado em que se encontram, mas adequados para aplicativos e serviços Web autônomos que exigem escalabilidade rápida.
Desenvolvimento e implantação	Visual Studio, WebMatrix, Visual Web Developer, WebDeploy, FTP, TFS, IIS Manager, PowerShell.	Visual Studio, SDK do Azure, TFS, PowerShell. Cada serviço de nuvem tem dois ambientes nos quais você pode implantar seu pacote de serviço e configuração: preparação e produção. Você pode implantar um serviço de nuvem no ambiente de preparo para testá-lo antes de promovê-lo para produção.	Visual Studio, WebMatrix, Visual Web Developer, FTP, GIT, BitBucket, CodePlex, DropBox, GitHub, Mercurial, TFS, Web Deploy, PowerShell.
Administração e configuração	Você é responsável por tarefas administrativas no aplicativo, dados, regras de firewall, rede virtual e sistema operacional.	Você é responsável por tarefas administrativas no aplicativo, dados, regras de firewall e rede virtual.	Você é responsável apenas por tarefas administrativas no aplicativo e nos dados.
Alta disponibilidade e recuperação de desastres (HADR)	Recomendamos que você coloque máquinas virtuais no mesmo conjunto de disponibilidade e no mesmo serviço de nuvem. Manter suas VMs no mesmo conjunto de disponibilidade permite que o Azure coloque os nós de alta disponibilidade em domínios de falha separados e atualize domínios. Da mesma forma, manter suas VMs no mesmo serviço de nuvem permite o balanceamento de carga e as VMs podem se comunicar diretamente entre si pela rede local em um data center do Azure. Você é responsável por implementar uma solução de alta disponibilidade e recuperação de desastres para o SQL Server em Máquinas Virtuais do Azure para evitar qualquer tempo de inatividade. Para tecnologias HADR com suporte, consulte Alta disponibilidade e recuperação de desastres para SQL Server em máquinas virtuais do Azure. Você é responsável por fazer backup de seus próprios dados e aplicativos. O Azure pode mover suas máquinas virtuais se a máquina host no data center falhar devido a problemas de hardware. Além disso, pode haver tempo de inatividade planejado de sua VM quando a máquina host é atualizada para atualizações de segurança ou de software. Portanto, recomendamos que você mantenha pelo menos duas VMs em cada camada de aplicativo para garantir a disponibilidade contínua. O Azure não fornece SLA para uma única máquina virtual.	O Azure gerencia as falhas resultantes do hardware subjacente ou do software do sistema operacional. Recomendamos que você implemente várias instâncias de uma função Web ou de trabalho para garantir a alta disponibilidade do seu aplicativo. Para obter informações, consulte Serviços de nuvem, máquinas virtuais e Contrato de nível de serviço de rede virtual. Você é responsável por fazer backup de seus próprios dados e aplicativos. Para bancos de dados que residem em um banco de dados do SQL Server em uma VM do Azure, você é responsável pela implementação de uma solução de alta disponibilidade e recuperação de desastres para evitar qualquer tempo de inatividade. Para tecnologias HDAR com suporte, consulte Alta disponibilidade e recuperação de desastres para SQL Server em máquinas virtuais do Azure. Espelhamento de Banco de Dados do SQL Server: use com os Serviços de Nuvem do Azure (funções Web/de trabalho). As VMs do SQL Server e um projeto de serviço de nuvem podem estar na mesma Rede Virtual do Azure. Se a VM do SQL Server não estiver na mesma Rede Virtual, você precisará criar um Alias do SQL Server para rotear a comunicação para a instância do SQL Server. Além disso, o nome do alias deve corresponder ao nome do SQL Server.	A Alta Disponibilidade é herdada das funções de trabalho do Azure, do Armazenamento de Blobs do Azure e do Banco de Dados SQL do Azure. Por exemplo, o Armazenamento do Azure mantém três réplicas de todos os dados de blob, tabela e fila. A qualquer momento, o Banco de Dados SQL do Azure mantém três réplicas de dados em execução — uma réplica primária e duas réplicas secundárias. Para obter mais informações, consulte Armazenamento do Azure e Banco de Dados SQL do Azure. Ao usar o SQL Server em uma VM do Azure como uma fonte de dados para Aplicativos Web do Azure, lembre-se de que os Aplicativos Web do Azure não oferecem suporte à Rede Virtual do Azure. Em outras palavras, todas as conexões de Aplicativos Web do Azure para VMs do SQL Server no Azure devem passar por pontos finais públicos de máquinas virtuais. Isso pode causar algumas limitações para cenários de alta disponibilidade e recuperação de desastres. Por exemplo, o aplicativo cliente nos Aplicativos Web do Azure conectando-se à VM do SQL Server com espelhamento de banco de dados não poderá se conectar ao novo servidor primário, pois o espelhamento de banco de dados exige que você configure a Rede Virtual do Azure entre VMs de host do SQL Server no Azure. Portanto, o uso do Espelhamento de Banco de Dados do SQL Server com os Aplicativos Web do Azure não é suportado atualmente. Grupos de Disponibilidade Always On do SQL Server: você pode configurar Grupos de Disponibilidade Always On ao usar os Aplicativos Web do Azure com VMs do SQL Server no Azure. Mas você precisa configurar o Always On Availability Group Listener para rotear a comunicação para a réplica primária por meio de pontos de extremidade públicos com balanceamento de carga.
Conectividade entre locais	Você pode usar a Rede Virtual do Azure para se conectar localmente.	Você pode usar a Rede Virtual do Azure para se conectar localmente.	A Rede Virtual do Azure é suportada.
Escalabilidade	A expansão está disponível aumentando os tamanhos das máquinas virtuais ou adicionando mais discos. Para obter mais informações sobre tamanhos de máquinas virtuais, consulte Tamanhos de máquinas virtuais para o Azure. Para o Servidor de Banco de Dados: a expansão está disponível por meio de técnicas de particionamento de banco de dados e grupos de Disponibilidade Always On do SQL Server. Para cargas de trabalho de leitura pesadas, você pode usar Grupos de Disponibilidade Always On em vários nós secundários, bem como a Replicação do SQL Server. Para cargas de trabalho de gravação pesadas, você pode implementar dados de particionamento horizontal em vários servidores físicos para fornecer dimensionamento de aplicativos. Além disso, você pode implementar uma expansão usando o SQL Server com Roteamento Dependente de Dados. Com o DDR (Roteamento Dependente de Dados), você precisa implementar o mecanismo de particionamento no aplicativo cliente, normalmente na camada de camada de negócios, para rotear as solicitações de banco de dados para vários nós do SQL Server. A camada de negócios contém mapeamentos para como os dados são particionados e qual nó contém os dados. Você pode dimensionar aplicativos que estão executando máquinas virtuais. Para obter mais informações, consulte Como dimensionar um aplicativo. Observação importante: o recurso AutoScale no Azure permite que você aumente ou diminua automaticamente as máquinas virtuais usadas pelo seu aplicativo. Esse recurso garante que a experiência do usuário final não seja afetada negativamente durante os períodos de pico, e as VMs são desligadas quando a demanda é baixa. É recomendável que você não defina a opção AutoScale para seu serviço de nuvem se ele incluir VMs do SQL Server. O motivo é que o recurso AutoScale permite que o Azure ative uma máquina virtual quando o uso da CPU nessa VM for maior do que algum limite e desative uma máquina virtual quando o uso da CPU for inferior a ele. O recurso AutoScale é útil para aplicativos sem monitoração de estado, como servidores Web, onde qualquer VM pode gerenciar a carga de trabalho sem referências a nenhum estado anterior. No entanto, o recurso AutoScale não é útil para aplicativos com monitoração de estado, como o SQL Server, onde apenas uma instância permite gravar no banco de dados.	A expansão está disponível usando várias funções Web e de trabalho. Para obter mais informações sobre tamanhos de máquinas virtuais para funções Web e funções de trabalho, consulte Configurar tamanhos para serviços de nuvem. Ao usar os Serviços de Nuvem, você pode definir várias funções para distribuir o processamento e também obter o dimensionamento flexível do seu aplicativo. Cada serviço de nuvem inclui uma ou mais funções Web e/ou funções de trabalho, cada uma com seus próprios arquivos de aplicativo e configuração. Você pode expandir um serviço de nuvem aumentando o número de instâncias de função (máquinas virtuais) implantadas para uma função e reduzir a escala de um serviço de nuvem diminuindo o número de instâncias de função. Para obter informações detalhadas, consulte Modelos de execução do Azure. A expansão está disponível através do suporte de alta disponibilidade incorporado do Azure através de Serviços na Nuvem, Máquinas Virtuais e Contrato de Nível de Serviço de Rede Virtual e Balanceador de Carga. Para um aplicativo de várias camadas, recomendamos que você conecte o aplicativo de funções Web/de trabalho a VMs de servidor de banco de dados por meio da Rede Virtual do Azure. Além disso, o Azure fornece balanceamento de carga para VMs no mesmo serviço de nuvem, espalhando as solicitações do usuário entre elas. As máquinas virtuais conectadas dessa maneira podem se comunicar diretamente entre si pela rede local em um data center do Azure. Você pode configurar o AutoScale no portal do Azure, bem como os horários de agendamento. Para obter mais informações, consulte Como configurar o dimensionamento automático para um serviço de nuvem no portal.	Aumentar e diminuir a escala: você pode aumentar/diminuir o tamanho da instância (VM) reservada para seu site. Dimensionamento: você pode adicionar mais instâncias reservadas (VMs) para seu site. Você pode configurar o AutoScale no portal, bem como os horários de agendamento. Para obter mais informações, consulte Como dimensionar aplicativos Web.

Para obter mais informações sobre como escolher entre esses métodos de programação, consulte Aplicativos Web do Azure, Serviços de Nuvem e VMs: Quando usar quais.

Próximo passo

Para obter mais informações sobre como executar o SQL Server em Máquinas Virtuais do Azure, consulte Visão geral do SQL Server em Máquinas Virtuais do Azure.