Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Ambiente do Serviço de Aplicações é uma funcionalidade Serviço de Aplicações do Azure que proporciona um ambiente totalmente isolado e dedicado para executar aplicações de Serviços de Aplicações de forma segura e em grande escala. Como serviço Azure, o Ambiente do Serviço de Aplicações oferece uma variedade de funcionalidades para suportar os seus requisitos de fiabilidade.
Quando se usa Azure, fiabilidade é uma responsabilidade partilhada. A Microsoft disponibiliza uma variedade de capacidades para apoiar a resiliência e a recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.
Este artigo descreve o suporte de fiabilidade no Ambiente do Serviço de Aplicações, incluindo resiliência a falhas transitórias, falhas em zonas de disponibilidade e interrupções regionais. Descreve também estratégias de backup e resiliência à manutenção do serviço, destacando algumas informações chave sobre o acordo de nível de serviço (SLA) do Ambiente do Serviço de Aplicações.
Observação
Ao contrário da oferta pública multitenant App Service, que partilha a infraestrutura de suporte, um Ambiente do Serviço de Aplicações fornece recursos de computação dedicados e isolamento de rede melhorado para um único cliente.
Um ambiente oferece os seguintes benefícios principais de confiabilidade:
- Recursos de computação dedicados que não são compartilhados com outros clientes
- Isolamento de rede melhorado para maior segurança e estabilidade
- A capacidade de implantar em sua própria rede virtual para maior controle sobre o roteamento de tráfego e políticas de segurança
Para obter mais informações sobre suporte à confiabilidade no Serviço de Aplicativo, consulte Confiabilidade no Serviço de Aplicativo.
Recomendações de implantação de produção para confiabilidade
Recomendamos que ative a redundância de zona no seu ambiente e nos planos do App Service, o que requer que os seus planos utilizem um mínimo de duas instâncias.
Visão geral da arquitetura de confiabilidade
Quando implementas um Ambiente do Serviço de Aplicações, implementas o ambiente como contentor para os teus planos de Serviços de Aplicações e aplicações web. Durante a instalação, defina as configurações de rede principal e o isolamento de hardware opcional. Escolha se deseja oferecer suporte à redundância de zona no ambiente se a região oferecer suporte a zonas de disponibilidade.
Depois de criar seu ambiente, você pode criar um ou mais planos do Serviço de Aplicativo.
Um plano do Serviço de Aplicativo define um conjunto de recursos de computação que executam seus aplicativos Web. Todos os aplicativos Web devem ser executados dentro de um plano. Você pode dimensionar um plano para ser executado em várias instâncias de VM, também conhecidos como processos. Essas instâncias fornecem os recursos de computação que executam o código do aplicativo. Um único plano do Serviço de Aplicativo pode hospedar vários aplicativos. Todos os aplicativos são executados no mesmo conjunto compartilhado de instâncias de VM.
Para usar um Ambiente do Serviço de Aplicações, os seus planos devem usar o escalão de preços Isolado v2. Essa camada suporta redundância de zona e aplicativos de missão crítica de alta escala.
O Serviço de Aplicativo fornece os seguintes recursos de redundância:
Distribuição entre domínios de falha: Ao nível da plataforma, Azure distribui automaticamente as instâncias VM do seu plano de Serviços de Aplicações por domínios falha dentro da região Azure. Essa distribuição minimiza o risco de falhas de hardware localizadas agrupando VMs que compartilham uma fonte de alimentação comum e um switch de rede.
Distribuição entre zonas de disponibilidade: Se ativar a redundância de zonas num plano de App Service suportado, Azure distribui as suas instâncias entre zonas de disponibilidade dentro da região. Essa configuração fornece maior resiliência se ocorrer uma interrupção de zona. Para obter mais informações sobre redundância de zona, consulte Suporte à zona de disponibilidade.
Dimensionamento de aplicativos: Quando você configura seu plano do Serviço de Aplicativo para executar várias instâncias de VM, todos os aplicativos do plano são executados em todas as instâncias por padrão. Se você configurar seu plano para dimensionamento automático, todos os aplicativos serão dimensionados juntos com base nas configurações de dimensionamento automático. No entanto, você pode personalizar quantas instâncias de plano executam um aplicativo específico usando o dimensionamento por aplicativo.
Unidades de escala: Internamente, o Serviço de Aplicativo é executado em uma infraestrutura de plataforma chamada unidades de escala, também conhecidas como selos ou webspaces. Uma unidade de escala inclui todos os componentes necessários para hospedar e executar o Serviço de Aplicativo, incluindo computação, armazenamento, rede e balanceamento de carga. O Azure gere unidades de escala para garantir uma distribuição equilibrada da carga de trabalho, realizar manutenção rotineira e manter a fiabilidade global da plataforma.
Alguns recursos podem ser aplicados apenas a unidades de escala específicas. Por exemplo, algumas unidades de escala do Serviço de Aplicativo podem oferecer suporte à redundância de zona, enquanto outras unidades de escala na mesma região não.
Resiliência a falhas transitórias
Falhas transitórias são falhas curtas e intermitentes em componentes. Eles ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. As falhas transitórias corrigem-se após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente tentando novamente as solicitações afetadas.
Todas as aplicações alojadas na cloud devem seguir as orientações de tratamento de falhas transitórias do Azure quando comunicarem com quaisquer APIs, bases de dados e outros componentes alojados na cloud. Para obter mais informações, consulte Recomendações para o tratamento de falhas transitórias.
Os SDKs fornecidos pela Microsoft normalmente tratam falhas transitórias. Como você hospeda seus próprios aplicativos no Serviço de Aplicativo, tome medidas para reduzir a chance de falhas transitórias:
Implante várias instâncias em seu plano. O Serviço de Aplicativo executa atualizações automatizadas e outras formas de manutenção em instâncias do seu plano. Se uma entidade estiver com problemas, o serviço irá substituí-la automaticamente por uma nova entidade funcional. Durante o processo de substituição, pode haver um curto período em que a instância anterior não está disponível e uma nova instância não está pronta para atender ao tráfego. Para atenuar esses efeitos, implante várias instâncias do seu plano do Serviço de Aplicativo.
Utilize slots de implantação. Os slots de implantação do Serviço de Aplicativo permitem implantações sem tempo de inatividade de seus aplicativos. Use slots de implantação para minimizar o efeito de implantações e alterações de configuração para seus usuários. Os slots de implantação também reduzem a probabilidade de reinicialização do aplicativo. Reiniciar o aplicativo causa uma falha transitória.
Evite aumentar ou diminuir a escala. Essas operações alteram a CPU, a memória e outros recursos atribuídos a cada instância e podem disparar uma reinicialização do aplicativo. Em vez disso, selecione uma camada e um tamanho de instância que atendam aos seus requisitos de desempenho sob carga típica. Para expandir e dimensionar, adicione e remova instâncias dinamicamente para lidar com alterações no volume de tráfego.
Resiliência a falhas na zona de disponibilidade
Zonas de disponibilidade são grupos fisicamente separados de centros de dados dentro de uma região Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.
Podes configurar o teu Ambiente do Serviço de Aplicações como zona redundante. Depois, podes configurar os planos do App Service no ambiente para serem redundantes por zona, o que distribui as instâncias desse plano por várias zonas de disponibilidade. Podes escolher ativar ou desativar a redundância de zonas em cada plano, o que significa que podes ter alguns planos no teu ambiente que são redundantes por zona e outros que não são.
Quando você cria um plano do Serviço de Aplicativo com redundância de zona em seu ambiente, as instâncias do plano do Serviço de Aplicativo são distribuídas pelas zonas de disponibilidade na região. Para obter mais informações, consulte Distribuição de instâncias entre zonas.
Se o seu Ambiente do Serviço de Aplicações e planos não estiverem configurados como redundantes de zona, serão considerados não zonais, e as instâncias subjacentes da máquina virtual (VM) não são resilientes a falhas nas zonas de disponibilidade. Eles podem experienciar um período de inatividade durante uma falha em qualquer zona dessa região.
Requerimentos
Para ativar a redundância de zonas para o seu Ambiente do Serviço de Aplicações, deve cumprir os seguintes requisitos:
Region support: Para ver quais as regiões que suportam zonas de disponibilidade para Ambiente do Serviço de Aplicações v3, veja Regions.
Tipo de plano: Use os tipos de plano v2 isolados.
Número mínimo de instâncias: Implemente pelo menos duas instâncias no seu plano para que seja redundante em zona.
Planos não zonais no seu ambiente podem ser implementados com uma única instância.
Unidade de escala: Seu ambiente deve ser implantado em uma unidade de escala que ofereça suporte a zonas de disponibilidade. Você não controla diretamente a unidade de escala que seu ambiente usa. Em vez disso, quando você cria um ambiente do Serviço de Aplicativo, o ambiente é atribuído a uma unidade de escala com base no grupo de recursos do ambiente. Para determinar se a unidade de escala do seu Ambiente do Serviço de Aplicações suporta redundância de zona, Verifique se há suporte de redundância de zona para um Ambiente do Serviço de Aplicações.
Se o seu ambiente estiver em uma unidade de escala que não ofereça suporte a zonas de disponibilidade, você não poderá habilitar a redundância de zona em seu ambiente ou planos. Em vez disso, você precisa criar um novo ambiente em um novo grupo de recursos e reimplantar seus aplicativos em novos planos dentro desse ambiente.
Requisitos de configuração: Configure tanto o seu Ambiente do Serviço de Aplicações como os seus planos para suportar redundância de zonas. Você pode habilitar a redundância de zona durante a criação do ambiente ou atualizando um ambiente existente.
Distribuição de instâncias entre zonas
Quando cria um plano de App Service redundante por zona, o Azure distribui as instâncias do plano entre as zonas de disponibilidade da região. Essa distribuição garante que seus aplicativos permaneçam disponíveis mesmo se uma zona sofrer uma interrupção.
A distribuição de instâncias numa implantação com redundância de zona segue regras específicas. Estas regras também se aplicam à medida que a aplicação escala para dentro e para fora.
Instâncias mínimas: Seu plano do Serviço de Aplicativo deve ter no mínimo duas instâncias para redundância de zona.
Zonas de disponibilidade máxima suportadas pelo seu plano: Azure determina o número de zonas de disponibilidade que o seu plano pode utilizar, que é referido como máximoNúmeroDeZonas. Para exibir o número de zonas de disponibilidade que seu plano específico pode usar, consulte Verificar o suporte de redundância de zona para um plano do Serviço de Aplicativo.
Observação
O número de zonas de disponibilidade disponíveis para o seu plano (máximoNúmeroDeZonas) varia consoante a escala e a região. Uma implementação com redundância de zona usa sempre pelo menos duas zonas de disponibilidade e pode usar mais zonas, dependendo da sua unidade de escala. Independentemente do número de zonas, uma implementação redundante de zona proporciona resiliência a uma única falha de zona e oferece o mesmo SLA.
Instance distribution: Quando a redundância de zona está ativada, Azure distribui automaticamente as instâncias do plano por várias zonas de disponibilidade. A distribuição baseia-se nas seguintes regras:
Se o número de instâncias exceder máximoNúmeroDeZonas e se dividir igualmente, Azure distribui as instâncias de forma uniforme entre as zonas.
Se o número de instâncias não se dividir igualmente, o Azure distribui as restantes instâncias pelas zonas restantes.
Quando a plataforma de Serviços de Aplicações aloca instâncias para um plano de Serviços de Aplicação redundante por zona, utiliza o balanceamento de zonas de melhor esforço que os conjuntos de escala de máquinas virtuais subjacentes do Azure fornecem. Um plano está equilibrado se cada zona tiver o mesmo número de VMs ou diferir por uma única instância em relação a todas as outras zonas. Para obter mais informações, consulte Balanceamento de zona.
Colocação da zona física: Você pode exibir a zona de disponibilidade física usada para cada uma das instâncias do plano do Serviço de Aplicativo. Para obter mais informações, consulte Exibir zonas físicas para um plano do Serviço de Aplicativo.
Considerações
Comportamentos fora do tempo de execução: Uma falha na zona de disponibilidade pode afetar alguns aspetos do App Service, mesmo que a aplicação continue a servir o tráfego. Esses comportamentos incluem o dimensionamento do plano do Serviço de Aplicativo, a criação de aplicativos, a configuração do aplicativo e a publicação do aplicativo.
Atualizações da plataforma: Ao ativar a redundância de zonas no seu plano de Serviços de Aplicações, também melhora a resiliência durante as atualizações da plataforma. Para obter mais informações, consulte Resiliência à manutenção de serviços.
Custo
Pode ativar a redundância de zonas num Ambiente do Serviço de Aplicações ou nos seus planos sem custos adicionais. No entanto, a redundância de zona para um plano requer que ele tenha duas ou mais instâncias. Você é cobrado com base na SKU do plano App Service, na capacidade que você especifica e em quaisquer instâncias para as quais você dimensiona com base nos seus critérios de dimensionamento automático.
Se habilitares zonas de disponibilidade mas especificares uma capacidade de menos de duas instâncias, a plataforma impõe um mínimo de duas instâncias. A plataforma cobra por essas duas instâncias.
Importante
Quando ativas zonas de disponibilidade para um Ambiente do Serviço de Aplicações, todos os planos de App Service com menos de 3 instâncias são escalados para 3 instâncias. Qualquer plano com 3 ou mais instâncias permanece inalterado. Quando a operação para habilitar as zonas de disponibilidade for concluída, você poderá dimensionar seus planos do Serviço de Aplicativo conforme necessário, inclusive para menos de 3 instâncias.
Configurar o suporte à zona de disponibilidade
Para aprender a criar, ativar ou desativar um novo Ambiente de Serviço de Aplicação redundante de zona e novos Planos de Serviço de Aplicação redundantes de zona, consulte Configurar Ambientes de Serviço de Aplicação e Planos de Serviço de Aplicação Isolados v2 para redundância de zona.
Observação
Uma alteração no estado de redundância de zonas no ambiente de serviço de aplicação demora entre 12 e 24 horas para ser concluída. Durante o processo de atualização, não ocorrem problemas de tempo de inatividade ou desempenho.
Planejamento e gerenciamento de capacidade
Para se preparar para falhas na zona de disponibilidade, considere sobreprovisionar a capacidade do seu plano do Serviço de Aplicativo. Esta abordagem permite que a solução tolere alguma perda de capacidade e continue a funcionar sem um desempenho degradado. Para obter mais informações, consulte Gerenciar a capacidade usando o provisionamento excessivo.
Comportamento quando todas as zonas estão íntegras
A lista a seguir descreve o que esperar quando os planos do Serviço de Aplicativo são configurados para redundância de zona e todas as zonas de disponibilidade estão operacionais:
Roteamento de tráfego entre zonas: Durante as operações normais, o tráfego é roteado entre todas as instâncias disponíveis do plano do Serviço de Aplicativo em todas as zonas de disponibilidade.
Replicação de dados entre zonas: Durante as operações normais, qualquer estado armazenado no sistema de arquivos do aplicativo é armazenado em armazenamento com redundância de zona e replicado de forma síncrona entre zonas de disponibilidade.
Comportamento durante uma falha de zona
Uma interrupção da zona de disponibilidade pode afetar alguns aspetos do Serviço de Aplicativo, mesmo que o aplicativo continue a servir tráfego. Esses comportamentos incluem o dimensionamento do plano do Serviço de Aplicativo, a criação de aplicativos, a configuração do aplicativo e a publicação do aplicativo.
A lista a seguir descreve o que esperar quando os planos do Serviço de Aplicativo são configurados para redundância de zona e uma ou mais zonas de disponibilidade não estão disponíveis:
- Deteção e resposta: A plataforma do Serviço de Aplicativo deteta automaticamente falhas em uma zona de disponibilidade e inicia uma resposta. Nenhuma intervenção manual é necessária para iniciar um failover de zona.
- Notificação: A Microsoft não te informa automaticamente quando uma zona está inativa. No entanto, pode usar Azure Resource Health para monitorizar a saúde de um recurso individual, e pode configurar alertas Resource Health para o notificar de problemas. Também pode usar Azure Service Health para compreender o estado geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas Saúde do Serviço para o notificar de problemas.
Solicitações ativas: Todas as solicitações em andamento que se conectam a uma instância do plano do Serviço de Aplicativo na zona de disponibilidade defeituosa são encerradas. Repita essas solicitações.
Reencaminhamento do tráfego: O Serviço de Aplicativo deteta as instâncias perdidas dessa zona e tenta encontrar novas instâncias de substituição. Depois que o Serviço de Aplicativo encontra substitutos, ele distribui o tráfego entre as novas instâncias conforme necessário.
Se o dimensionamento automático estiver configurado e determinar que mais instâncias são necessárias, ele solicitará instâncias do Serviço de Aplicativo. O comportamento de dimensionamento automático opera independentemente do comportamento da plataforma do Serviço de Aplicativo. Portanto, sua especificação de contagem de instâncias não precisa ser um múltiplo de dois. Para obter mais informações, consulte Dimensionar um aplicativo no Serviço de Aplicativo e Visão geral do dimensionamento automático.
Importante
O Azure não garante que os pedidos para mais instâncias tenham sucesso num cenário de zona para baixo. A plataforma tenta preencher instâncias perdidas com base no melhor esforço. Se você precisar de capacidade garantida durante uma falha de zona de disponibilidade, crie e configure seus planos do Serviço de Aplicativo para contabilizar a perda de zona ao provisionar excessivamente a capacidade.
Comportamentos fora de execução: As aplicações num plano do App Service com redundância de zona continuam a funcionar e a servir tráfego, mesmo que uma zona de disponibilidade sofra uma interrupção. No entanto, comportamentos não de execução podem ser afetados durante uma interrupção numa zona de disponibilidade. Esses comportamentos incluem o dimensionamento do plano do Serviço de Aplicativo, a criação de aplicativos, a configuração do aplicativo e a publicação do aplicativo.
Recuperação de zona
Quando a zona de disponibilidade se recupera, o Serviço de Aplicativo cria automaticamente instâncias na zona de disponibilidade recuperada, remove todas as instâncias temporárias criadas nas outras zonas de disponibilidade e roteia o tráfego entre suas instâncias como de costume.
Teste de falhas de zona
A plataforma do Serviço de Aplicativo gerencia o roteamento de tráfego, failover e failback para planos do Serviço de Aplicativo com redundância de zona. Esse recurso é totalmente gerenciado, portanto, você não precisa iniciar ou validar processos de falha na zona de disponibilidade.
Resiliência a falhas em toda a região
O Serviço de Aplicativo é um serviço de região única. Se a região ficar indisponível, seu ambiente e seus planos e aplicativos também ficarão indisponíveis.
Soluções personalizadas de várias regiões para resiliência
Para reduzir o risco de uma falha de uma única região afetar seu aplicativo, implante vários ambientes do Serviço de Aplicativo em várias regiões. As seguintes medidas ajudam a reforçar a resiliência:
- Implante seu aplicativo nos Ambientes do Serviço de Aplicativo em cada região.
- Configure políticas de balanceamento de carga e tolerância a falhas.
- Replique seus dados entre regiões para que você possa recuperar o estado do último aplicativo.
Para um exemplo de abordagem que ilustra esta arquitetura, veja Implementação empresarial de alta disponibilidade usando Ambiente do Serviço de Aplicações.
Backup e restauração
Para fazer backup de seus aplicativos do Serviço de Aplicativo em um arquivo, use os recursos de backup e restauração do Serviço de Aplicativo.
Esses recursos ajudam quando é difícil reimplantar o código ou quando você armazena o estado no disco. A maioria das soluções não deve depender exclusivamente de backups. Em vez disso, use os outros recursos deste guia para dar suporte aos seus requisitos de resiliência. No entanto, os backups protegem contra alguns riscos que outras abordagens não oferecem.
Importante
A partir de 31 de março de 2028, Serviço de Aplicações do Azure backups personalizados deixarão de suportar backups de bases de dados ligadas. Consulte Descontinuação de backups de banco de dados vinculados para obter mais informações.
Em vez disso, use as ferramentas nativas de backup e restauração do banco de dados vinculado. Para obter mais informações, consulte Fazer backup e restaurar seu aplicativo no Serviço de Aplicativo.
Resiliência à manutenção de serviços
O Serviço de Aplicativo executa atualizações regulares de serviço e outras tarefas de manutenção. Para manter a capacidade esperada durante uma atualização, a plataforma adiciona automaticamente instâncias extras do plano do Serviço de Aplicativo durante o processo de atualização.
Habilite a redundância de zona. Ao habilitar a redundância de zona em seu plano do Serviço de Aplicativo, você também melhora a resiliência durante as atualizações da plataforma. Os domínios de atualização consistem em coleções de VMs que ficam offline durante uma atualização e são mapeadas para zonas de disponibilidade. Implementar várias instâncias no seu plano do App Service e ativar a redundância de zona para o seu plano adiciona uma camada extra de resiliência se uma instância ou zona ficar comprometida durante uma atualização.
Personalize o ciclo de atualização. Pode personalizar o ciclo de atualização para um Ambiente do Serviço de Aplicações. Se você precisar validar o efeito das atualizações em sua carga de trabalho, habilite as atualizações manuais. Essa abordagem permite que você execute validação e teste em uma instância que não seja de produção antes de aplicá-los à sua instância de produção.
Para mais informações sobre preferências de manutenção, consulte Preferências de atualização para manutenção planeada do Ambiente do Serviço de Aplicações.
Contrato de nível de serviço
O acordo de nível de serviço (SLA) para serviços Azure descreve a disponibilidade esperada de cada serviço e as condições que a sua solução deve cumprir para atingir essa expectativa de disponibilidade. Para mais informações, consulte Acordos de Nível de Serviço (SLA) para serviços online.
Quando se implementa um plano de Serviço de Aplicações com redundância de zona, a percentagem de tempo de atividade definida no SLA aumenta. O mesmo SLA aplica-se independentemente do número de zonas disponíveis na unidade de escala subjacente.