VENDAS: 1-800-867-1389

Padrões de aplicativo e estratégias de desenvolvimento para SQL Server em máquinas virtuais do Azure

Atualizado: outubro de 2014

Artigo técnico para SQL Server e Azure

Resumo: Determinar qual padrão ou padrões de aplicativos usar para seus aplicativos baseados em SQL Server no ambiente Azure é uma decisão de design importante. Essa decisão exige uma compreensão sólida de como o SQL Server e cada componente de infraestrutura do Azure funcionam juntos. Com o SQL Server em Serviços de Infraestrutura do Azure, você pode facilmente migrar, manter e monitorar seus aplicativos SQL Server existentes integrados ao Windows Server para máquinas virtuais no Azure.

A meta deste artigo é fornecer a arquitetos e desenvolvedores de soluções uma base para uma boa arquitetura e design de aplicativos, a qual 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 respectiva solução habilitada para nuvem e as recomendações técnicas relacionadas. Somado a isso, o artigo discute estratégias de desenvolvimento específicas do Azure que permitam criar aplicativos corretamente. Devido aos inúmeros padrões diferentes de aplicativos, é recomendado que os arquitetos e desenvolvedores escolham o padrão mais apropriado para seus aplicativos e usuários.

Autor: Selcin Turkarslan

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

Você pode desenvolver vários tipos de aplicativos de N camadas, separando os componentes das diferentes camadas do aplicativo em computadores diferentes, bem como em componentes separados. Por exemplo, você pode colocar o aplicativo cliente e os componentes de regras de negócio em uma máquina, a camada da Web front-end e seus componentes da camada de acesso a dados em outra máquina, e uma camada de banco de dados back-end em outra máquina. Este tipo de estruturação ajuda a isolar uma camada da outra. Se você alterar de onde vêm os dados, não será necessário alterar o aplicativo cliente ou da Web, apenas os componentes da camada de acesso a dados.

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

  • A camada de apresentação (camada da Web, camada front-end) é a camada na qual os usuários interagem com um aplicativo.

  • A camada de negócios (camada intermediária) é a camada usada pela camada de apresentação e pela camada de dados para comunição mútua e inclui a funcionalidade central do sistema.

  • A camada de dados é basicamente o servidor que armazena os dados de um aplicativo (por exemplo, um servidor executando o SQL Server).

As camadas do aplicativo (layers) descrevem os agrupamentos lógicos da funcionalidade e dos componentes em um aplicativo; enquanto as camadas (tiers) 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 (de N camadas). Os componentes em cada camada comunicam-se com os componentes de outras camadas através de interfaces bem definidas. Você pode pensar no termo camada (tier) como se referindo a padrões de distribuição física, como duas camadas, três camadas e N camadas. Um padrão de aplicativo de duas camadas contém duas camadas de aplicativo: servidor do aplicativo e servidor do banco de dados. A comunicação direta acontece entre o servidor do aplicativo e o servidor do banco de dados. O servidor do aplicativo contém componentes da camada da Web e da camada de negócios. No padrão de aplicativo de três camadas, existem três camadas de aplicativo: servidor da Web, servidor do aplicativo, o qual contém a camada da lógica de negócios e/ou componentes de acesso a dados da camada de negócios, e o servidor do banco de dados. A comunicação entre o servidor da Web e o servidor do banco de dados acontece no servidor do aplicativo. Para obter informações detalhadas sobre camadas de aplicativos, consulte Guia de arquitetura de aplicativos da Microsoft.

Antes de começar a ler este artigo, você deve ter conhecimento dos conceitos básicos do SQL Server e do Azure. Para obter informações, consulte Livros do SQL Server OnlineSQL Server em Máquinas Virtuais do Azure e WindowsAzure.com.

Este artigo descreve vários padrões de aplicativo que podem ser adequados para seus aplicativos simples e também para os aplicativos corporativos altamente complexos. Antes de detalhar cada padrão, nós recomendamos que você familiarize-se com os serviços de armazenamento de dados disponíveis no Azure, como Armazenamento Azure, Banco de Dados SQL do Azuree Servidor SQL em uma Máquina Virtual do Azure. Para tomar as melhores decisões de design para seus aplicativos, compreenda claramente quando usar qual serviço de armazenamento de dados. O artigo Gerenciamento de Dados: Escolhendo a Tecnologia Certa fornece uma comparação detalhada de cada serviço de armazenamento de dados no Azure.

Resumindo, escolha um SQL Server em uma Máquina Virtual do Azure, quando:

  • Você precisar de compatibilidade total com o SQL Server local e quiser mover os aplicativos existentes para o Azure como estão.

  • Você quiser aproveitar os recursos do ambiente Azure, mas o Banco de Dados SQL do Azure (Banco de Dados SQL) não suporta todos os recursos que seu aplicativo ou banco de dados precisa, tais como:

    • Alta disponibilidade e recuperação de desastres: Você quiser ter os recursos de disponibilidade e de recuperação de desastres tradicionais do SQL Server, como Grupos de Disponibilidade AlwaysOn ou espelhamento de banco de dados. Com o SQL Server em uma Máquina Virtual do Azure, você tem controle total sobre configuração e execução de soluções de alta disponibilidade e recuperação de desastres baseadas no SQL Server para seus aplicativos. Esse recurso protege seus bancos de dados contra qualquer tempo de inatividade devido a falhas de software ou de hardware ou atualizações do sistema operacional no Azure. Por outro lado, o Banco de Dados SQL do Azure fornece resiliência integrada contra falha no nível do nó no Azure. Em caso de falha do nó, o banco de dados faz failover automaticamente em uma das réplicas secundárias Como você não tem qualquer controle sobre como um failover pode acontecer, você precisa tratar das interrupções de conexão para aplicativos clientes em execução em Banco de Dados SQL.

    • Tamanho do banco de dados: Quando este artigo foi atualizado, o banco de dados SQL oferecia suporte a um banco de dados de até 500 GB de dados. Se o seu aplicativo precisar de mais de 500 GB de dados e você não quiser implementar soluções de fragmentação personalizadas, recomenda-se o uso do SQL Server em uma Máquina Virtual do Azure. Para obter as informações mais recentes, consulte Expandindo Bancos de dados SQL do Azure e Camadas de serviço e níveis de desempenho do Banco de Dados SQL do Azure.

    • Conformidade HIPAA: Clientes de serviços de saúde e ISVs (fornecedores de software independentes) podem escolher SQL Server em Máquinas Virtuais do Azure em vez de Banco de Dados SQL do Azure, pois o SQL Server em uma Máquina Virtual do Azure é coberto pelo Acordo de Parceiro Comercial (BAA) HIPAA. Para obter informações sobre conformidade, consulte a Central de Confiabilidade do Azure.

    • Lacunas de funcionalidade: Alguns clientes podem escolher o SQL Server em Máquinas Virtuais do Azure em vez do Banco de Dados SQL do Azure devido às lacunas de funcionalidade no Banco de Dados SQL do Azure, como compactação de dados e flexibilidade de backup e restauração. Para obter mais informações, consulte Diretrizes e limitações do Banco de dados SQL do Azure.

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

Este padrão de aplicativo é útil quando:

  • Você quer realizar uma migração simples para a plataforma Azure a fim de avaliar se a plataforma atende aos seus requisitos de aplicativo ou não.

  • Você quer manter todas as camadas de aplicativo hospedadas na mesma máquina virtual no data center do Azure a fim de reduzir a latência entre camadas.

  • Você quer provisionar rapidamente ambientes de desenvolvimento e de teste durante curtos períodos.

  • Você quer realizar testes de estresse em diversos níveis de carga de trabalho, mas não quer possuir ou 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.

Padrão de aplicativo de uma camada

Implantar a 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ê tenha que usar uma camada separada devido a questões de escalabilidade ou segurança.

Como esse é um padrão muito comum para começar, talvez você considere os seguintes links úteis para migrar arquivos de dados locais e de aplicativos para Máquinas Virtuais do Azure: Preparando-se para migrar para o SQL Server em Máquinas Virtuais do Azure e Migrando para o SQL Server em uma máquina virtual do Azure. Além disso, você pode Usar o serviço de Importação/Exportação do Azure para transferir dados para o Armazenamento de Blob. Usando o serviço de Importação/Exportação, você cria um trabalho importante para mover arquivos de dados para o Armazenamento do Azure. A Microsoft carrega os dados em disco no Armazenamento do Azure. Quando a Microsoft termina o carregamento dos arquivos de dados no armazenamento de BLOB no mesmo data center da sua máquina virtual, você pode mudar a área de trabalho remota para a máquina virtual e baixar os arquivos de dados do armazenamento de BLOB. Você também pode acessar os arquivos no Armazenamento de Blob usando os SDKs de armazenamento de Blob.

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

Este padrão de aplicativo é útil quando:

  • Você quer realizar uma migração de aplicativos de bancos de dados complexos para Máquinas Virtuais do Azure.

  • Você quer que camadas de aplicativo diferentes 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 mudar aplicativos corporativos de plataformas virtualizadas locais para Máquinas Virtuais do Azure. Para ver uma discussão detalhada sobre aplicativos corporativos, consulte O que é um aplicativo corporativo.

  • Você quer provisionar rapidamente ambientes de desenvolvimento e de teste durante curtos períodos.

  • Você quer realizar testes de estresse em diversos níveis de carga de trabalho, mas não quer possuir ou manter muitas máquinas físicas o tempo todo.

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

Padrão de aplicativo de três camadas

Neste padrão de aplicativo, há apenas uma máquina virtual (VM) em cada camada. Se você tiver várias VMs no Azure, recomendamos a configuração de uma rede virtual. A Rede virtual do Azure cria um limite de segurança confiável e também permite que VMs se comuniquem entre si no endereço IP privado. Além disso, sempre certifique-se de que todas as conexões de Internet apenas vão para a camada de apresentação. Isso significa que você deve abrir um ponto de extremidade público na camada de apresentação, mas não nas outras camadas. Ao seguir esse padrão de aplicativo, você também precisa configurar a lista de controle de acesso a rede (ACL) nessa porta pública a fim de permitir o acesso a determinados endereços IP. Para obter mais informações, consulte Sobre as listas de controle de acesso a rede.

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

Importante: a configuração de uma rede virtual no Azure é gratuita. No entanto, você é cobrado pelo gateway VPN que conecta ao local. Esta taxa tem base na quantidade de tempo que a conexão é fornecida e fica disponível.

Nesse padrão de aplicativo, você implanta um aplicativo de bando de dados de duas camadas ou de três camadas em 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 volume maior de solicitações de clientes de entrada.

Este padrão de aplicativo é útil quando:

  • Você deseja mudar aplicativos corporativos de plataformas virtualizadas locais para Máquinas Virtuais do Azure.

  • Você quer expandir a camada de apresentação devido ao volume maior de solicitações de clientes de entrada.

  • Você quer provisionar rapidamente ambientes de desenvolvimento e de teste durante curtos períodos.

  • Você quer realizar testes de estresse em diversos níveis de carga de trabalho, mas não quer possuir ou manter muitas máquinas físicas o tempo todo.

  • Você quer um ambiente de infraestrutura o qual possa aumentar e diminuir conforme a necessidade.

O diagrama a seguir demonstra como você pode colocar as camadas de aplicativo em várias máquinas virtuais no Azure por meio da expansão da camada de apresentação devido ao maior volume de solicitações de clientes de entrada. Conforme 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 da Web conectar-se. Ter várias instâncias dos servidores da Web por trás de um balanceador de carga garante a alta disponibilidade da camada de apresentação. Para obter mais informações, consulte as Práticas recomendadas para Práticas recomendadas para padrões de aplicativo de duas camadas, de três camadas ou de N camadas com várias máquinas virtuais em uma camada.

Padrão de aplicativo com camada de apresentação expandida

Recomenda-se que você coloque 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 da Web em CloudService1 e AvailabilitySet1 e um conjunto de servidores de bancos de dados em CloudService2 e AvailabilitySet2. Um conjunto de disponibilidade no Azure possibilita que você coloque os nós de alta disponibilidade em domínios de falha e domínios de atualização separados. Para obter mais informações, consulte Gerenciar a disponibilidade de máquinas virtuais e Como conectar máquinas virtuais em um serviço de nuvem.

Para aproveitar as várias instâncias de VM de uma camada, você precisa configurar o Balanceador de Carga do Azure entre camadas de aplicativo. Para configurar o Balanceador de Carga em cada camada, crie um ponto de extremidade com carga balanceada nas VMs de cada camada separadamente. Para uma camada específica, primeiro crie VMs no mesmo serviço de nuvem. Isso garantirá que todas elas tenham o mesmo endereço IP Virtual. Em seguida, crie um ponto de extremidade em uma das máquinas virtuais nessa camada. Então, atribua o mesmo ponto de extremidade às outras máquinas virtuais nessa camada para balanceamento de carga. Criando 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 a qual nó se conectar quando um nó de VM back-end falhar. Por exemplo, ter várias instâncias dos servidores da Web por trás de um balanceador de carga garante a alta disponibilidade da camada de apresentação.

Como uma prática recomendada, sempre certifique-se de que todas as conexões de Internet vão primeiro para a camada de apresentação. A camada de apresentação acessa a camada de negócios e depois a camada de negócios acessa a camada de dados. Por exemplo, abra um ponto de extremidade na camada de apresentação. Cada ponto de extremidade tem uma porta pública e uma porta privada. A porta privada é usada internamente pela máquina virtual para ouvir o tráfego nesse ponto de extremidade. A porta pública é o ponto de entrada para comunicação de fora do Azure e é usada pelo Balanceador de Carga do Azure. Recomenda-se configurar a lista de controle de acesso a rede (ACL) a fim de definir regras que ajudam a isolar e controlar o tráfego de entrada em qualquer porta pública, em qualquer ponto de extremidade público, em qualquer camada de aplicativo. Para obter mais informações, consulte Sobre as listas de controle de acesso a rede.

Observe que o Balanceador de Carga no Azure funciona de modo semelhante aos balanceadores de carga em um ambiente local. Para obter mais informações, consulte Balanceando a carga de máquinas virtuais.

Além disso, recomendamos que você configure uma rede privada para suas máquinas virtuais usando a Rede Virtual do Azure. Isso permite que elas se comuniquem entre si sobre o endereço IP privado. Para obter mais informações, consulte Rede virtual do Azure.

Nesse padrão de aplicativo, você implanta um aplicativo de bando de dados de duas camadas ou de três camadas em 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 aplicativo a várias máquinas virtuais devido à complexidade de seu aplicativo.

Este padrão de aplicativo é útil quando:

  • Você deseja mudar aplicativos corporativos de plataformas virtualizadas locais para Máquinas Virtuais do Azure.

  • Você quer distribuir os componentes do servidor de aplicativo a várias máquinas virtuais devido à complexidade do seu aplicativo.

  • Você quer mudar aplicativos de LOB (linha de negócios) locais pesados da lógica de negócios para Máquinas Virtuais do Azure. Aplicativos LOB são um conjunto de aplicativos de computador que são vitais para comandar uma empresa, como aplicativos contábeis, de recursos humanos (RH), folha de pagamento, gerenciamento da cadeia de suprimentos e de planejamento de recursos.

  • Você quer provisionar rapidamente ambientes de desenvolvimento e de teste durante curtos períodos.

  • Você quer realizar testes de estresse em diversos níveis de carga de trabalho, mas não quer possuir ou manter muitas máquinas físicas o tempo todo.

  • Você quer um ambiente de infraestrutura o qual possa aumentar e diminuir conforme a necessidade.

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 por meio da expansão da camada de negócios, a qual contém a camada lógica de negócios e componentes de acesso a dados. Conforme 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 da Web conectar-se. Ter várias instâncias dos servidores de aplicativo por trá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 aplicativo de duas camadas, de três camadas ou de N camadas com várias máquinas virtuais em uma camada.

Padrão de aplicativo com camada de negócios expandida

Nesse padrão de aplicativo, você implanta um aplicativo de banco de dados de duas camadas ou de três camadas a Máquinas Virtuais do Azure por meio da distribuição dos componentes da camada de apresentação (servidor da Web) e da camada de negócios (servidor de aplicativo) a várias máquinas virtuais. Além disso, você implementa soluções de alta disponibilidade e de recuperação de desastres para seus bancos de dados em máquinas virtuais do Azure.

Este padrão de aplicativo é útil quando:

  • Você quer mudar os aplicativos corporativos de plataformas virtualizadas locais para o Azure por meio da implementação de recursos de alta disponibilidade e de recuperação de desastres do SQL Server.

  • Você quer expandir a camada de apresentação e a camada de negócios devido ao volume maior de solicitações de clientes de entrada e à complexidade do seu aplicativo.

  • Você quer provisionar rapidamente ambientes de desenvolvimento e de teste durante curtos períodos.

  • Você quer realizar testes de estresse em diversos níveis de carga de trabalho, mas não quer possuir ou manter muitas máquinas físicas o tempo todo.

  • Você quer um ambiente de infraestrutura o qual possa aumentar e diminuir conforme a necessidade.

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

Executar várias cópias de um aplicativo em diferentes VMs garante o balanceamento da carga de solicitações entre elas. Quando você tem várias máquinas virtuais, é necessário se certificar de que todas as suas VMs estejam acessíveis e em execução em um ponto no tempo. 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 nós de VM funcionando apropriadamente de modo integral. Para obter informações como configurar o balanceamento de carga das máquinas virtuais, consulte Balanceamento de carga de máquinas virtuais. Ter várias instâncias dos servidores da Web e de aplicativo por trás de um balanceador de carga garante a alta disponibilidade das camadas de apresentação e de negócios. Para obter mais informações, consulte Práticas recomendadas para padrões de aplicativo que exigem de soluções de alta disponibilidade e de recuperação de desastres do SQL Server.

Expansão e alta disponibilidade

Quando você configura soluções de alta disponibilidade e de 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. Máquinas virtuais em uma Rede Virtual terão um endereço IP privado estável, mesmo após um tempo de inatividade de serviço, assim você pode evitar o tempo de atualização necessário para a resolução de nome 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 o seu aplicativo tiver restrições de domínio corporativo (tais como, autenticação do Windows, Active Directory), a configuração da Rede Virtual do Azure será necessária.

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

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

Nesse padrão de aplicativo, você implanta o aplicativo de duas e de três camadas usando os Serviços de Nuvem do Azure (funções da Web e de trabalho - Plataforma como Serviço (PaaS)) e 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 SQL Server em 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 proporciona gerenciamento, implantação, monitoramento e expansão facilitados.

Com os Serviços de Nuvem, o Azure mantém a infraestrutura para você, realiza manutenção de rotina, aplica os patches nos sistemas operacionais e tenta recuperar-se de falhas de serviço e de hardware. Quando seu aplicativo precisa de expansão, há opções de expansão automática e manual disponíveis para seu projeto de serviço de nuvem por meio do aumento ou diminuição do número de instâncias ou de máquinas virtuais usadas por 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.

Resumindo, se você não quiser tarefas administrativas extensas para a camada de apresentação/de negócios, e seu aplicativo não precisar de qualquer configuração complexa de software ou do sistema operacional, use os Serviços de Nuvem do Azure. Se o Banco de Dados SQL do Azure não suportar 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 uma comparação detalhada, consulte Estratégias de desenvolvimento no Azure: Comparação do desenvolvimento tradicional da Web versus Serviços de Nuvem do Azure e Sites do Azure.

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

Este padrão de aplicativo é útil quando:

  • Você quer mudar os aplicativos corporativos de plataformas virtualizadas locais para o Azure por meio da implementação de recursos de alta disponibilidade e de recuperação de desastres do SQL Server.

  • Você quer um ambiente de infraestrutura o qual possa aumentar e diminuir conforme a necessidade.

  • O Banco de Dados SQL do Azure não suporta todos os recursos que seu aplicativo ou banco de dados necessita.

  • Você quer realizar testes de estresse em diversos níveis de carga de trabalho, mas não quer possuir ou 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 nas funções da Web, a camada de negócios nas funções de trabalho, mas a camada de dados em máquinas virtuais no Azure. Executar várias cópias da camada de apresentação em diferentes funções da Web garante solicitações de balanceamento de carga entre elas. Ao combinar os Serviços de Nuvem do Azure com Máquinas Virtuais do Azure, nós recomendamos que você também configure a Rede Virtual do Azure. Com a Rede Virtual do Azure, você pode ter endereços IP privados estáveis e persistentes no mesmo serviço de nuvem na nuvem. Quando você define uma rede virtual para suas máquinas virtuais e serviços de nuvem, elas podem começar a comunicação entre si sobre o endereço IP privado. Além disso, ter máquinas virtuais e funções de Web/de trabalho do Azure na mesma Rede Virtual do Azure proporciona baixa latência e conectividade mais segura. Para obter mais informações, consulte O que é um serviço de nuvem, Modelos de Execução do Azure e Rede Virtual do Azure.

Conforme visto no diagrama, o Balanceador de Carga do Azure distribui tráfego entre várias máquinas virtuais e também determina a qual servidor da Web ou servidor de aplicativo se conectar. Ter várias instâncias dos servidores da Web e de aplicativo 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 aplicativo que exigem de soluções de alta disponibilidade e de recuperação de desastres do SQL Server.

Padrões de aplicativos com Serviços de Nuvem

Outra abordagem para implementar este padrão de aplicativo é usar uma função da Web consolidada que contém os componentes das camadas de apresentação e de negócios, conforme mostra o diagrama a seguir. Este padrão de aplicativo é útil para aplicativos que necessitam de um design com estado. Como o Azure fornece nós de computação sem estado em funções da web e de trabalho, nós recomendamos que você implemente uma lógica para armazenar o estado da sessão usando uma das tecnologias a seguir: Cache do Azure, Armazenamento de Tabelas do Azure ou Banco de Dados SQL do Azure.

Padrões de aplicativos com Serviços de Nuvem

A meta principal deste padrão de aplicativo é mostrar a você como combinar os componentes da infraestrutura do Azure como serviço (IaaS) com os componentes da plataforma como serviço (PaaS) do Azure em sua solução. Este 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, a qual é parte da infraestrutura do Azure como oferta de serviço.

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

Este padrão de aplicativo é útil quando:

  • Você já tem um servidor de Banco de Dados SQL existente configurado no Azure e quer testar seu aplicativo rapidamente.

  • Você quer testar os recursos do ambiente Azure.

  • Você quer provisionar rapidamente ambientes de desenvolvimento e de teste durante curtos períodos.

  • Sua lógica de negócios e componentes de acesso a dados podem ser autocontidos em um aplicativo da Web.

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

Padrão de aplicativo misto

Se você escolher implementar uma combinação das camadas da Web e de aplicativo usando os Sites do Azure, nós recomendamos que você mantenha a camada intermediária ou a camada de aplicativo como bibliotecas de links dinâmicos (DLLs) no contexto de um aplicativo da Web.

Além disso, analise as recomendações dadas na seção Estratégias de desenvolvimento no Azure: Comparação do desenvolvimento tradicional da Web versus Serviços de Nuvem do Azure e Sites do Azure ao final deste artigo para aprender mais sobre técnicas de programação.

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, o qual você 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 Rede Virtual do Azure.

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

  • Você quer desenvolver aplicativos que executam parcialmente na nuvem e parcialmente no local.

  • Você deseja migrar alguns ou todos os elementos de um aplicativo local existente para a nuvem.

  • Você quer mudar aplicativos corporativos de plataformas virtualizadas locais para o Azure.

  • Você quer um ambiente de infraestrutura o qual possa aumentar e diminuir conforme a necessidade.

  • Você quer provisionar rapidamente ambientes de desenvolvimento e de teste durante curtos períodos.

  • Você quer uma forma econômica de fazer backups de 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 mostra o diagrama, a infraestrutura local inclui o controlador de domínio Serviços de Domínio do Active Directory para dar suporte à autenticação e à autorização do usuário. Observe que o diagrama demonstra um cenário no qual algumas partes da camada de dados estão em um data center local, enquanto outras partes da camada de dados estão no Azure. Dependendo das necessidades de seu aplicativo, você pode implementar outros cenários híbridos diferentes. Por exemplo, você pode manter as camadas de apresentação e de negócios em um ambiente local, mas a camada de dados no Azure.

Problemas ao visualizar este tópico na Biblioteca do Azure? Tente visualiza-lo na Biblioteca MSDN.

Padrão de aplicativo de N camadas

No Azure, você pode usar o Active Directory como um diretório de nuvem autônomo para sua organização, ou você também pode integrar o Active Directory local existente ao Active Directory do Azure. Conforme observado no diagrama, os componentes da camada de negócios podem acessar várias fontes de dados, como o SQL Server no Azure por meio de um endereço IP interno privado, o SQL Server local por meio da Rede Virtual ou o Banco de Dados SQL usando as tecnologias do provedor de dados .NET Framework. Nesse diagrama, o Banco de Dados SQL do Azure (Banco de Dados SQL) é um serviço de armazenamento de dados opcional.

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

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

  2. Planeje os recursos e a configuração necessários na plataforma do Azure, como contas de armazenamento e máquinas virtuais. Para obter um plano de migração detalhado, consulte Preparando-se para migrar para o SQL Server em Máquinas Virtuais do Azure.

  3. Configure uma conexão de rede entre a rede corporativa local e a Rede Virtual do Azure. Para estabelecer 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 através de pontos de extremidade públicos em uma máquina virtual no Azure. Esse método fornece uma configuração fácil e possibilita que você use a autenticação do SQL Server em sua máquina virtual. Além disso, configure a lista de controle de acesso a rede (ACL) nas portas públicas para permitir acesso a determinados endereços IP. Para obter mais informações, consulte Sobre as listas de controle de acesso a rede

    2. Estabeleça uma conexão entre o local e o Azure por meio do túnel VPN (Rede Virtual Privada) do Azure. Esse método permite que você estenda as políticas de domínio até uma máquina virtual no Azure. Além disso, você pode definir regras de firewall e usar a autenticação do Windows em sua máquina virtual. Atualmente, o Azure suporta conexões seguras de VPN site a site e VPN ponto a site:

      • Com a conexão site a site segura, você pode estabelecer conectividade de rede entre sua rede local e sua rede virtual no Azure. Isso é recomendado para conectar seu ambiente de data center local ao Azure.

      • Com conexão ponto a site segura, você pode estabelecer conectividade de rede entre sua rede virtual no Azure e seus computadores individuais em execução em qualquer lugar. Isso é recomendado principalmente para fins de desenvolvimento e teste.

      Para obter informações sobre como se conectar ao SQL Server no Azure, consulte Considerações de conectividade para o SQL Server em máquinas virtuais do Azure.

  4. Configure trabalhos e alertas agendados que fariam o 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 o serviço de armazenamento de blob do Azure e Backup e restauração para o SQL Server em máquinas virtuais do Azure.

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

    1. Você pode manter seu servidor da Web, servidor de aplicativo e dados sem distinção em um servidor de banco de dados no Azure, enquanto mantém os dados confidenciais no local.

    2. Você pode manter seu servidor da Web e servidor de aplicativo no local, enquanto o servidor de banco de dados fica em uma máquina virtual no Azure.

    3. Você pode manter seu servidor de banco de dados, servidor da Web e servidor de aplicativo no local, enquanto mantém as réplicas de banco de dados em uma máquina virtual no Azure. Essa configuração permite que os servidores da Web ou aplicativos de relatório locais acessem as réplicas do banco de dados no Azure. Dessa forma, você pode conseguir a redução da carga de trabalho em um banco de dados local. Recomendamos a implementação desse cenário para fins de desenvolvimento e em situações de cargas de trabalho de leitura pesadas. Para obter informações sobre a criação de réplicas de banco de dados no Azure, consulte Grupos de Disponibilidade AlwaysOn em Alta disponibilidade e recuperação de desastres para o SQL Server em máquinas virtuais do Azure.

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

  • Configure um servidor da 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. Depois, certifique-se de que este serviço de nuvem possa acessar bancos de dados no SQL Server em Máquinas Virtuais do Azure. Um serviço de nuvem pode incluir várias funções da Web e de trabalho.

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

Problemas ao visualizar este tópico na Biblioteca do Azure? Tente visualiza-lo na Biblioteca MSDN.

 

Desenvolvimento tradicional da Web em Máquinas Virtuais do Azure

Serviços de Nuvem no Azure

Hospedagem na Web com Sites do Azure

Migração do Aplicativo do local

  • Aplicativos existentes como são.

  • Aplicativos necessitam de funções da Web e de trabalho.

  • Aplicativos existentes como são, mas adequados para aplicativos da Web autocontidos e serviços da Web que exigem escalabilidade rápida.

Desenvolvimento e implantação

  • Visual Studio, WebMatrix, Visual Web Developer, WebDeploy, FTP, TFS, IIS Manager, PowerShell.

  • Visual Studio, Azure SDK, TFS, PowerShell. Cada serviço de nuvem tem dois ambientes aos quais você pode implantar seu pacote e configuração de serviço: preparo e produção. Você pode implantar um serviço de nuvem ao 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 por tarefas administrativas no aplicativo e dados apenas.

Alta Disponibilidade e Recuperação de Desastres (HADR)

  • Nós 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 e domínios de atualização separados. De modo semelhante, manter suas VMs no mesmo serviço de nuvem possibilita que o balanceamento de carga e VMs possam se comunicar sobre a rede local dentro de um data center do Azure.

  • Você é responsável por implementar uma solução de alta disponibilidade e de recuperação de desastres para o SQL Server em Máquinas Virtuais do Azure a fim de evitar períodos de inatividade. Para conhecer as tecnologias HADR suportadas, consulte Alta disponibilidade e recuperação de desastres para o SQL Server em máquinas virtuais do Azure.

  • Você é responsável por fazer o backup de seus próprios dados e aplicativo.

  • 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, sua VM pode passar por período de inatividade planejado, quando a máquina host recebe 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. Para obter mais informações, consulte Orientação técnica de continuidade de negócios do Azure.

  • O Azure gerencia as falhas resultantes do hardware subjacente ou software do sistema operacional. Nós recomendamos que você implemente várias instâncias de uma função da 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 Acordo de Nível de Serviço da Rede Virtual e Recuperação de Desastres e Alta Disponibilidade para Aplicativos do Azure

  • Você é responsável por fazer o backup de seus próprios dados e aplicativo.

  • Para bancos de dados que residem em um banco de dados SQL Server em uma VM do Azure, você é responsável por implementar uma solução de alta disponibilidade e de recuperação de desastres para evitar qualquer período de inatividade. Para conhecer as tecnologias HADR suportadas, consulte Alta disponibilidade e recuperação de desastres para o SQL Server em máquinas virtuais do Azure.

  • Espelhamento de banco de dados SQL Server: Isso é suportado quando usado com Serviços de Nuvem do Azure (funções da Web/de trabalho). 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ê precisa criar um Alias do SQL Server para encaminhar 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 de funções de trabalho do Azure, armazenamento de blob do Azure e Banco de Dados SQL do Azure. Por exemplo, o Armazenamento do Azure mantém três réplicas de todos os dados blob, de tabela e de fila. A qualquer momento, o Banco de Dados SQL do Azure tem 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 e Banco de Dados SQL.

  • Ao usar o SQL Server em VM do Azure como uma fonte de dados para Sites do Azure, tenha em mente que os Sites do Azure não suportam Rede Virtual do Azure. Em outras palavras, todas as conexões de Sites do Azure para VMs do SQL Server no Azure devem passar por pontos de extremidade públicos de máquinas virtuais. Isso pode causar algumas limitações para cenários de alta disponibilidade e de recuperação de desastres. Por exemplo, o aplicativo cliente em Sites do Azure que se conectam a VM do SQL Server com espelhamento de banco de dados não seria capaz de se conectar ao novo servidor primário, pois o espelhamento de banco de dados exige a configuração da Rede Virtual do Azure entre as VMs host do SQL Server no Azure. Portanto, o uso do Espelhamento de banco de dados do SQL Server com Sites Azure não é suportado no momento.

  • Grupos de Disponibilidade AlwaysOn do SQL Server: Você pode configurar os Grupos de Disponibilidade AlwaysOn ao usar os Sites Azure com VMs do SQL Server no Azure. Mas você precisa configurar o Ouvinte do Grupo de Disponibilidade AlwaysOn para encaminhar a comunicação para a réplica primária por meio de pontos de extremidade públicos com carga balanceada.

Conectividade entre locais

  • Você pode usar Rede Virtual do Azure para se conectar a locais.

  • Você pode usar Rede Virtual do Azure para se conectar a locais.

Escalabilidade

  • A ampliação está disponível por meio do aumento do tamanho das máquinas virtuais ou da adição de mais discos. Para obter mais informações sobre o tamanho das máquinas virtuais, consulte Tamanho de máquinas virtuais e do Serviço de Nuvem 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 AlwaysOn do SQL Server.

    Para cargas pesadas de trabalho de leitura, você pode usar os Grupos de Disponibilidade AlwaysOn em vários nós secundários, bem como a Replicação do SQL Server.

    Para cargas pesadas de trabalho de gravação, você pode implementar dados de particionamento horizontal em vários servidores físicos, a fim de permitir a expansão do aplicativo.

    Além disso, você pode implementar uma expansão usando o SQL Server com Encaminhamento Dependente de Dados. Com o Encaminhamento Dependente de Dados (DDR), você precisa implementar o mecanismo de particionamento no aplicativo cliente, normalmente na camada de negócios, a fim de encaminhar solicitações de banco de dados a vários nós do SQL Server. A camada de negócios contém mapeamentos da partição dos dados e de qual nó contém os dados.


  • Você pode ampliar aplicativos que estão executando máquinas virtuais. Para obter mais informações, consulte Como dimensionar um aplicativo.

    Observação importante: O recurso Autoescala no Azure permite aumentar ou diminuir as máquinas virtuais que são usadas pelo aplicativo automaticamente. Esse recurso garante que a experiência do usuário final não seja afetada negativamente durante os períodos de pico e que as VMs sejam desligadas quando a demanda for baixa. É recomendável que você não defina a opção Autoescala para o seu serviço de nuvem se este incluir as VMs do SQL Server. O motivo para isso é que o recurso de Autoescala permite que o Azure ligue uma máquina virtual quando o uso da CPU na VM for superior ao limite e para desligar uma máquina virtual quando o uso da CPU for inferior a isso. O recurso de Autoescala é útil para aplicativos sem monitoração de estado, tais como servidores Web, onde qualquer VM pode gerenciar a carga de trabalho sem quaisquer referências para qualquer estado anterior. No entanto, o recurso Autoescala não é útil para aplicativos com monitoração de estado, como o SQL Server, onde somente uma instância permite gravar no banco de dados.

  • A ampliação está disponível usando várias funções da 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 o Cloud Services, você pode definir várias funções a fim de distribuir o processamento e também realizar o dimensionamento flexível de seu aplicativo. Cada serviço de nuvem inclui uma ou mais funções da Web e/ou funções de trabalho, cada um com seus próprios aplicativos e configuração. Você pode ampliar um serviço de nuvem aumentando o número de instâncias de funções (máquinas virtuais) implantadas para uma função, e reduzir um serviço de nuvem diminuindo o número de instâncias de funções. Para obter informações detalhadas, consulte Modelos de execução do Azure.

  • A expansão horizontal está disponível via suporte de alta disponibilidade integrado do Azure por meio de Serviços de Nuvem, Máquinas Virtuais e Acordo de Nível de Serviço de Rede Virtual e Balanceador de Carga.

  • Para um aplicativo de múltiplas camadas, nós recomendamos que você conecte o aplicativo de funções da Web/de trabalho a VMs do servidor de banco de dados por meio de uma Rede Virtual do Azure. Além disso, o Azure fornece o balanceamento de carga para VMs no mesmo serviço de nuvem, espalhando as solicitações de usuário entre elas. Máquinas virtuais conectadas dessa forma podem se comunicar diretamente umas com as outras por meio da rede local dentro de um data center do Azure.

  • Você pode configurar a Autoescala e as horas agendadas no Portal de Gerenciamento. Para obter mais informações, consulte Como dimensionar um aplicativo.

  • Ampliação e redução: Você pode aumentar/diminuir o tamanho da instância (VM) reservada para seu site.

  • Expansão: Você pode adicionar mais instâncias reservadas (VMs) ao seu site.

  • Você pode configurar a Autoescala e as horas agendadas no Portal de Gerenciamento. Para obter mais informações, consulte Como dimensionar sites.

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

Consulte também

Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
Mostrar:
© 2014 Microsoft