Fiabilidade no Funções do Azure

Funções do Azure é um serviço de computação orientado a eventos que executa pequenos blocos de código, ou funções, sem provisão ou gestão explícita de infraestrutura. As funções podem responder a eventos como pedidos HTTP, temporizadores, mensagens de fila e alterações noutros serviços do Azure. Esta capacidade torna as Funções bem adequadas para processamento de dados, integração de sistemas e tarefas em segundo plano.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para oferecer suporte à resiliência e à 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 como tornar as Funções resilientes a vários potenciais cortes e problemas, incluindo falhas transitórias, falhas em zonas de disponibilidade e falhas regionais. Também destaca informações essenciais sobre o acordo de nível de serviço (SLA) das Funções.

Recomendações de implantação de produção

O Azure Well-Architected Framework fornece recomendações sobre fiabilidade, segurança, custo, operações e desempenho. Para saber como estas áreas se influenciam mutuamente e contribuem para uma solução fiável de Funções, consulte as melhores práticas de arquitetura para Funções.

Visão geral da arquitetura de confiabilidade

Quando implementa Funções, é importante familiarizar-se com estes conceitos:

  • Planos de alojamento: Os planos representam o ambiente de alojamento das suas aplicações de funções. O plano determina os recursos computacionais disponíveis, o modelo de preços e o comportamento de escalabilidade.

  • Contas de armazenamento: Ao criar uma aplicação funcional, deve especificar uma conta de armazenamento anfitrião. A conta de armazenamento gere aspetos das operações internas da aplicação de funções, incluindo armazenamento de código de função, registos de atividades e gestão de concorrência (como arrendamentos de blob para tipos específicos de disparadores).

    Também pode usar uma conta de armazenamento para a implementação. Esta conta de armazenamento pode ser igual à conta de armazenamento do seu anfitrião ou uma conta de armazenamento diferente.

    Importante

    As contas de armazenamento são uma parte crítica da sua arquitetura de fiabilidade Functions. Configure-os para satisfazer os requisitos de resiliência da sua aplicação funcional.

  • Gatilhos e vinculações: Gatilhos e vinculações permitem que a sua função responda a eventos, receba dados de outros serviços e escreva dados em outros serviços.

  • Funções duradouras: Funções duráveis são uma característica das Funções. Fornece funções com estado, como orquestrações de longa duração e entidades com estado.

    Quando usas funções duradouras, configuras um fornecedor de armazenamento que armazena o estado. Avalie as características de fiabilidade da loja estatal que escolheu e configure-a para satisfazer os seus requisitos de resiliência.

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.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes de tratamento de falhas transitórias do Azure quando se comunicam com quaisquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, consulte Recomendações para o tratamento de falhas transitórias.

Considere as seguintes recomendações para lidar com falhas transitórias nas suas aplicações de funções:

  • Gatilhos e fixações: A plataforma Funções inclui o tratamento integrado de falhas transitórias para gatilhos e fixações. Quando ocorre uma falha transitória enquanto um gatilho suportado é ativado ou uma ligação suportada lê ou escreve dados, a plataforma pode tentar automaticamente a operação. Este comportamento de tentativa incorporado garante que problemas temporários de conectividade ou interrupções de serviço não impeçam a execução da sua função. Para mais informações, veja Funções gestão de erros e tentativas.

    Esta proteção cobre apenas falhas transitórias. A plataforma não tenta novamente falhas persistentes, como uma cadeia de ligação mal configurada ou um recurso eliminado.

    A plataforma trata falhas persistentes e falhas transitórias repetidas como erros. Configure o registo para captar informação sobre erros de execução de funções. Para mais informações, consulte Configurar monitorização para Funções.

  • O seu código de função: No seu código de função, é responsável por tratar falhas transitórias quando a sua função chama serviços externos. Implemente lógica de tentativas de reexecução, timeouts e padrões de disjuntores conforme apropriado para chamadas de serviço externas realizadas pelo seu código de função. Projete as suas funções para que sejam idempotentes sempre que possível, para evitar que repetições criem efeitos secundários duplicados.

  • Clientes: Aplicações cliente que se ligam a funções de forma síncrona, como através de uma ligação HTTP, devem ser resilientes a falhas transitórias.

Resiliência a falhas na zona de disponibilidade

As 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.

Os planos de consumo não suportam zonas de disponibilidade. Se a redundância de zonas for um requisito para a sua carga de trabalho, considere usar os planos Flex Consumption, Premium ou Dedicated (Serviço de Aplicações do Azure).

Os planos Flex Consumption suportam implantações redundantes em zonas.

Os planos premium suportam implantações redundantes por zonas.

Quando a redundância de zonas está ativada, a plataforma distribui automaticamente as instâncias do seu plano por todas as zonas de disponibilidade na região selecionada. Se alguma zona de disponibilidade na região tiver um problema, as suas funções continuam a funcionar usando instâncias em zonas saudáveis.

Deve ativar o armazenamento redundante por zonas (ZRS) na conta de armazenamento do anfitrião, garantindo assim resiliência a falhas de zona.

Diagrama que mostra um plano de Funções redundante por zonas que tem três instâncias distribuídas por três zonas e uma conta ZRS.

O plano Dedicado (App Service) suporta implementações redundantes por zona. Quando a redundância de zonas está ativada, a plataforma distribui automaticamente as suas instâncias por todas as zonas de disponibilidade na região selecionada. Configuras redundância de zonas no plano. Para mais informações sobre como Serviço de Aplicações do Azure lida com a redundância de zonas, consulte Fiabilidade em Serviços de Aplicações.

O seu plano é não zonal ou regional quando não ativa a redundância de zonas. A plataforma pode colocar instâncias de planos em qualquer zona de disponibilidade da região ou na mesma zona. As instâncias do plano não são resistentes a falhas em zonas de disponibilidade. O seu plano pode sofrer indisponibilidade durante uma interrupção em qualquer zona da região.

Requisitos

  • Suporte de região: Pode desdobrar planos Flex Consumption redundantes por zonas num conjunto específico de regiões. Pode obter a lista atual de regiões suportadas usando a CLI do Azure. Para mais informações, consulte Ver regiões que suportam zonas de disponibilidade.

  • Apoio regional: Pode implementar planos Premium redundantes de zona nas seguintes regiões.

    Américas Europa Médio Oriente Africa Ásia-Pacífico
    Sul do Brasil Centro de França Israel Central Norte da África do Sul Leste da Austrália
    Canadá Central Alemanha Centro-Oeste Catar Central Índia Central
    E.U.A. Central Norte de Itália Norte dos E.A.U. Norte da China 3
    E.U.A. Leste Europa do Norte Ásia Leste
    E.U.A. Leste 2 Leste da Noruega Leste do Japão
    E.U.A. Centro-Sul Suécia Central Sudeste Asiático
    E.U.A. Oeste 2 Norte da Suíça
    E.U.A. Oeste 3 Sul do Reino Unido
    Europa Ocidental

  • Sistemas operativos: A plataforma suporta a implementação de planos de Windows e Linux redundantes por zona.

  • Número mínimo de instâncias: A redundância de zonas para planos Premium requer um mínimo de duas instâncias sempre prontas.

  • Conta de armazenamento do host: Tem de configurar a conta de armazenamento padrão da sua aplicação de funções para usar ZRS. Se usar uma conta de armazenamento de host que não está configurada para ZRS, a sua aplicação pode comportar-se de forma inesperada durante uma falha de zona.
  • Conta de armazenamento de contentores de implantação: Se usares uma conta de armazenamento separada para o contentor de implementação da aplicação, atualiza-a também para ser redundante em zona.

Considerações

Comportamentos fora do tempo de execução: A redundância de zonas apenas garante o tempo de funcionamento contínuo para aplicações implementadas. Uma falha na zona de disponibilidade pode afetar aspetos das Funções, mesmo que a aplicação continue a servir o tráfego. Estes comportamentos incluem escalabilidade de planos, criação de aplicações, configuração de aplicações e publicação de aplicações.

Distribuição de instâncias entre zonas

Quando configura as aplicações do plano Flex Consumption como redundantes de zona, a plataforma distribui automaticamente as instâncias do plano por várias zonas na região selecionada, com regras diferentes para instâncias sempre prontas versus on-demand:

  • As instâncias sempre prontas são distribuídas por pelo menos duas zonas utilizando a distribuição round-robin.

    Para garantir a resiliência das zonas, a plataforma mantém automaticamente pelo menos duas instâncias sempre prontas para cada função ou grupo de escalabilidade por função, independentemente da configuração sempre pronta para a aplicação. As instâncias que a plataforma cria são geridas pela plataforma, apresentadas como instâncias sempre prontas e não alteram as definições de configuração sempre prontas.

  • As instâncias sob demanda resultam dos volumes de origem de eventos, à medida que a aplicação escala para além do número de instâncias sempre prontas. As instâncias on-demand são distribuídas entre zonas de disponibilidade com base no melhor esforço. A plataforma prioriza uma escalabilidade mais rápida em vez de uma distribuição uniforme entre zonas. A plataforma tenta equilibrar a distribuição ao longo do tempo.

Quando configura os planos da aplicação de funções Elastic Premium como redundantes de zona, a plataforma distribui automaticamente as instâncias dos planos por várias zonas na região selecionada. A propagação de instâncias segue estas regras, mesmo enquanto o aplicativo aumenta e diminui:

  • A contagem mínima de instâncias da aplicação de função é duas.

  • Quando se especifica uma capacidade maior do que o número de zonas, as instâncias são distribuídas de forma uniforme apenas quando a capacidade é múltiplo do número de zonas.

  • Para um valor de capacidade superior ao número de zonas multiplicado pelo número de instâncias, as instâncias adicionais são distribuídas pelas zonas restantes.

Quando Functions aloca instâncias a um plano Premium com redundância por zona, utiliza o balanceamento de zonas melhor-esforço, que é fornecido pelos Conjuntos de Escala de Máquinas Virtuais subjacentes do Azure. Azure considera um plano Premium balanceado quando cada zona tem o mesmo número de máquinas virtuais (VMs) que as outras zonas do plano, mais ou menos uma VM.

Custo

Não tens custos adicionais ao ativar a redundância de zonas. A tarifação de um plano redundante por zona é a mesma que para um plano de zona única. No entanto, ativar a redundância de zonas afeta o número mínimo de instâncias no seu plano.

Quando ativa zonas de disponibilidade numa aplicação com uma configuração de instâncias de tipo sempre pronto com menos de duas instâncias para cada função ou grupo de escalabilidade, a plataforma cria automaticamente duas instâncias do tipo sempre pronto para cada uma dessas funções ou grupos. Estas novas instâncias também são faturadas como instâncias sempre disponíveis.

Se ativares zonas de disponibilidade num plano com menos de duas instâncias, a plataforma impõe um número mínimo de duas instâncias para esse plano, e é cobrado por ambas as instâncias.

Para detalhes completos sobre preços, consulte Preços de Funções.

Configurar o suporte à zona de disponibilidade

  • Criar um novo plano de Funções redundante por zonas. Podes ativar a redundância de zonas quando criares um novo plano. Para mais informações, consulte Criar uma aplicação de função redundante por zona.

  • Ative a redundância de zonas num plano existente. Pode ativar ou desativar as zonas de disponibilidade para os planos Elastic Premium existentes. Os planos Elastic Premium têm um comportamento de capacidade específico que difere dos planos dedicados (App Service) e requerem passos adicionais de configuração. Para passos detalhados, consulte Permitir redundância de zona num plano existente.

  • Criar um novo plano de Funções redundante por zonas. Podes ativar a redundância de zonas quando criares um novo plano. Para mais informações, consulte Criar uma aplicação de função redundante por zona.

  • Ative a redundância de zonas num plano existente. Para os planos Premium, só pode ativar a redundância de zonas durante a criação do plano. Não podes converter um plano Premium existente para ser redundante por zona. Em vez disso, migre a sua aplicação criando uma implementação lado a lado numa nova aplicação do plano Premium. Para mais informações, consulte Permitir redundância de zona num plano existente.

Planejamento e gerenciamento de capacidade

Aplicações funcionais redundantes de zona continuam a funcionar mesmo quando zonas da região sofrem uma falha.

Durante uma interrupção de zona, o Functions deteta instâncias perdidas e tenta automaticamente localizar ou criar instâncias de substituição nas zonas saudáveis. A plataforma realiza este processo com base no melhor esforço e não garante sucesso. Se a sua carga de trabalho requer um número específico de instâncias para manter o nível de serviço esperado, considere sobreabastecer o número de instâncias sempre prontas. O sobreprovisionamento permite que a solução tolere a perda de capacidade e continue a funcionar sem redução de desempenho. Para obter mais informações, consulte Gerenciar a capacidade por excesso de provisionamento.

Comportamento quando todas as zonas estão íntegras

Esta secção descreve o que esperar quando um plano é redundante por zona, a conta de armazenamento anfitriã usa ZRS e todas as zonas de disponibilidade estão operacionais.

  • Operação entre zonas: Quando configura redundância de zona nas Funções, os pedidos são automaticamente distribuídos entre as instâncias em cada zona de disponibilidade. Um pedido pode ir para qualquer instância em qualquer zona de disponibilidade.

  • Replicação de dados entre zonas: Functions é um serviço de computação sem estado, por isso não há dados para replicar entre zonas. A plataforma replica automaticamente a configuração entre zonas.

    Se a sua conta de armazenamento anfitrião usar ZRS, o Armazenamento do Azure replica sincronizadamente os seus dados em várias zonas de disponibilidade.

    Para funções duradouras, consulte o seu fornecedor de armazenamento para saber como replica dados entre zonas.

Comportamento durante uma falha de zona

Esta secção descreve o que esperar quando um plano é redundante por zona, a conta de armazenamento do anfitrião usa ZRS e há uma falha na zona de disponibilidade.

  • Deteção e resposta: A plataforma Functions é responsável por detetar uma falha numa zona de disponibilidade. Não é necessário iniciar um failover de zona.
  • Notificação: a Microsoft não o notifica automaticamente quando uma zona está inativa. No entanto, pode utilizar o Azure Resource Health para monitorizar a integridade de um recurso individual, e pode configurar alertas de integridade de recursos para notificá-lo 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.

  • Pedidos ativos: Quando uma zona de disponibilidade não está disponível, os pedidos em curso que se ligam a uma instância na zona de disponibilidade defeituosa terminam e devem ser tentados novamente. Certifique-se de que os seus pedidos estão preparados seguindo as orientações de tratamento de falhas transitórias.

  • Perda de dados esperada: Não se espera que falhas de zona causem perda de dados porque o Functions é um serviço sem estado.

    Se a sua conta de armazenamento de anfitrião usar ZRS, o armazenamento garante que não há perda de dados devido a uma falha de zona.

    Para funções duradouras, reveja o seu fornecedor de armazenamento para saber se a perda de dados é possível durante uma falha de zona.

  • Tempo de inatividade previsto: Durante as interrupções de zona, as ligações podem sofrer interrupções breves que normalmente duram alguns segundos enquanto o tráfego é redistribuído. Certifique-se de que os seus pedidos estão preparados seguindo as orientações de tratamento de falhas transitórias.

  • Redirecionamento de tráfego: O Functions deteta as instâncias perdidas dessa zona e tenta encontrar novas instâncias de substituição. Depois de o Functions encontrar substitutos, distribui o tráfego entre as novas instâncias conforme necessário.

    Importante

    O Azure não garante que as solicitações para mais instâncias sejam bem-sucedidas em um cenário de zone-down. A plataforma tenta preencher instâncias perdidas com base no melhor esforço. Se precisar de capacidade garantida durante uma falha na zona de disponibilidade, crie e configure os seus planos para ter em conta a perda da zona, sobreabastecendo a capacidade.

  • Comportamentos fora do tempo de execução: As aplicações num plano de aplicação de função redundante por zona continuam a funcionar e a servir o tráfego mesmo que uma zona de disponibilidade sofra uma falha. No entanto, comportamentos não de execução podem ser afetados durante uma interrupção numa zona de disponibilidade. Estes comportamentos incluem escalabilidade de aplicações funcionais, criação de aplicações, configuração de aplicações e publicação de aplicações.

Recuperação de zona

Quando a zona de disponibilidade recupera, o Functions restaura automaticamente as instâncias na zona de disponibilidade, remove instâncias temporárias criadas nas outras zonas de disponibilidade e redireciona o tráfego entre as suas instâncias normalmente.

Teste de falhas de zona

A plataforma Functions gere o encaminhamento do tráfego, o failover e a recuperação de zonas para recursos redundantes de zona. Você não precisa iniciar nada. O Azure gere totalmente esta funcionalidade, por isso não precisa de validar processos de falha de zona de disponibilidade.

Resiliência a falhas em toda a região

Functions é um serviço de região única. Se a região ficar indisponível, o seu recurso de Funções também fica indisponível.

Soluções personalizadas de várias regiões para resiliência

Para evitar interrupções no seu serviço durante interrupções regionais, pode implementar redundantemente as mesmas funções para operar aplicações em várias regiões.

És responsável por:

  • Implementar aplicações funcionais para múltiplas regiões.

  • Gerir a distribuição de tráfego entre regiões.

  • Implementação de mecanismos de failover.

  • Garantir a consistência dos dados entre regiões (se aplicável).

  • Monitorização e gestão de implementações entre regiões.

Quando executa o mesmo código de função em várias regiões, considere os padrões ativo-ativo e ativo-passivo . As secções seguintes apresentam estes padrões, mas não fornecem orientações detalhadas ou passos de configuração.

Padrão ativo-ativo para funções de gatilho HTTP

Num padrão ativo-ativo, funções em ambas as regiões executam e processam eventos ativamente, seja de forma duplicada ou em rotação. Use um padrão ativo-ativo em combinação com Azure Front Door para as suas funções críticas ativadas por HTTP, que podem encaminhar e fazer round-robin de pedidos HTTP entre funções que correm em múltiplas regiões. O Azure Front Door também pode verificar periodicamente a saúde de cada endpoint. Se uma função numa região deixar de responder a verificações de saúde, o Azure Front Door remove-a da rotação e apenas encaminha o tráfego para as funções saudáveis restantes.

Diagrama que mostra um exemplo de arquitetura ativo-ativo. Azure Front Door encaminha entre aplicações de Funções em diferentes regiões, cada uma com a sua própria base de dados.

Padrão ativo-passivo para funções de disparo não HTTP

Para funções orientadas a eventos, não ativadas por HTTP (como Azure Service Bus e Hubs de Eventos do Azure), utilize um padrão ativo-passivo. Num padrão ativo-passivo, as instâncias funcionais correm na região que recebe eventos, enquanto as instâncias na região secundária permanecem inativas. Este padrão garante que apenas uma função processa cada mensagem, o que ajuda a manter a consistência dos dados. Também oferece uma forma de fazer failover para a região secundária durante um desastre, como uma interrupção regional.

Considere o failover da function app juntamente com os comportamentos de failover de outros serviços que utiliza, tais como:

Considere uma topologia de exemplo que utiliza um disparador do Event Hubs, onde o seu espaço de nomes do Event Hubs está configurado para recuperação geo-desastre. Neste caso, o padrão ativo-passivo requer os seguintes componentes:

  • Os espaços de nomes dos Centros de Eventos foram implementados tanto para uma região primária como para a secundária.

  • Recuperação de Geo-desastres ativada para emparelhar os hubs primários e secundários de eventos. Esta configuração também cria um alias que pode usar para se ligar ao namespace dos Event Hubs e alternar o alias do principal para o secundário sem alterações na informação de ligação.

  • Aplicações funcionais implementadas tanto na região primária como na secundária. A aplicação na região secundária mantém-se inativa porque não recebe mensagens.

  • Os gatilhos de cada função utilizam a direct (não-alias) cadeia de ligação para o respetivo espaço de nomes dos Centros de Eventos.

  • Os publicadores do espaço de nomes Event Hubs publicam na cadeia de conexão de alias.

Diagrama que mostra um exemplo de arquitetura ativo-passiva. A recuperação geo-desastre dos Event Hubs abrange múltiplas regiões e aplicações funcionais e bases de dados separadas em cada região.

Antes do failover, os editores que enviam eventos para o alias partilhado encaminham o tráfego para o hub principal de eventos. A aplicação de funções primárias ouve exclusivamente o hub principal de eventos. A aplicação de função secundária permanece inativa.

Quando o failover começa, os publicadores que enviam eventos para o alias partilhado são encaminhados para o hub de eventos secundário. A aplicação de função secundária é ativada e dispara automaticamente. O hub de eventos pode gerir todo o processo de failover, e cada aplicação de funções só corre quando o seu hub de eventos correspondente está ativo.

Funções duráveis

Para recuperação de desastres multi-região para funções duradouras, ver Recuperação de desastres e geo-distribuição em funções duradouras do Azure.

Resiliência à manutenção de serviços

A Functions realiza atualizações regulares de serviço e outras tarefas de manutenção.

  • Resiliência a falhas transitórias: Durante a manutenção do serviço, as instâncias que executam a sua aplicação de funções podem reiniciar ou sofrer interrupções temporárias. Assegure que as aplicações cliente que interagem com a sua aplicação de funções são resilientes a falhas transitórias.
  • Ativar redundância de zona: Ao ativar a redundância de zonas no seu plano, também melhora a resiliência durante as atualizações da plataforma. Implementar múltiplas instâncias no seu plano e ativar a redundância de zonas adiciona uma camada extra de resiliência se uma instância ou zona se tornar insalubre durante uma atualização.

  • Casos extra temporários: Para manter a sua capacidade esperada durante uma atualização, a plataforma adiciona automaticamente instâncias extra do plano durante o processo de atualização.

  • Ativar redundância de zona: Ao ativar a redundância de zonas no seu plano, 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 múltiplas instâncias no seu plano e ativar a redundância de zonas adiciona uma camada extra de resiliência se uma instância ou zona se tornar insalubre durante uma atualização.

  • Ambiente de Serviços de Aplicação: Se hospedar a sua aplicação de funções num Ambiente de Serviços de Aplicações, pode personalizar o ciclo de atualização. Se tiver de validar o efeito das atualizações na sua carga de trabalho, ative as atualizações manuais. Use esta abordagem para validar e testar uma instância não produtiva antes de aplicar as atualizações à sua instância de produção.

    Para obter mais informações sobre preferências de manutenção, consulte Preferências de atualização para manutenção planejada do Ambiente do Serviço de Aplicativo.

Resiliência às implementações de aplicações

As implementações de aplicações introduzem o risco de problemas num ambiente de produção. Esteja pronto para reverter uma atualização caso esta cause problemas. Controlar como as atualizações são implementadas para reduzir as perturbações causadas pelos reinícios das aplicações.

Os planos Flex Consumption suportam estratégias de atualização do site, que oferecem múltiplas formas de implementar as atualizações da sua aplicação. Estas estratégias incluem atualizações contínuas para implementações sem tempo de inatividade.

Os espaços de implementação de funções permitem implementações sem tempo de inatividade das suas aplicações funcionais. 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. Os reinícios de aplicações causam falhas transitórias.

Contrato de nível de serviço

O contrato de nível de serviço (SLA) para serviços do Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para obter mais informações, consulte Acordos de Nível de Serviço (SLAs) para serviços online.

A funcionalidade de Funções oferece SLAs de disponibilidade distintos consoante o Modelo de Consumo e outros tipos de planos.

Conteúdo relacionado

  • Last updated on