Considerações para planos de controle multilocatário

Uma solução multilocatária tem vários planos, e cada um tem suas próprias responsabilidades. O plano de dados permite que usuários finais e clientes interajam com o sistema. O plano de controle é o componente que gerencia tarefas de nível superior em todos os locatários, como controle de acesso, provisionamento e manutenção do sistema para dar suporte às tarefas dos administradores da plataforma.

Este artigo fornece informações sobre as responsabilidades dos planos de controle e como projetar um plano de controle que atenda às suas necessidades.

Por exemplo, considere um sistema de contabilidade para gerenciar registros financeiros. Vários locatários armazenam seus registros financeiros no sistema. Quando os usuários finais acessam o sistema para visualizar e inserir seus registros financeiros, eles usam o plano de dados. O plano de dados é provavelmente o principal componente de aplicativo para sua solução. Seus locatários provavelmente pensam nisso como a maneira de usar o sistema para o propósito pretendido. O plano de controle é o componente que integra novos locatários, cria bancos de dados para cada locatário e executa outras operações de gerenciamento e manutenção. Se o sistema não tivesse um plano de controle, os administradores precisariam executar muitos processos manuais. Ou as tarefas do plano de dados e do plano de controle seriam misturadas, complicando demais a solução.

Muitos sistemas complexos incluem planos de controle. Por exemplo, o plano de controle do Azure, Azure Resource Manager, é um conjunto de APIs, ferramentas e componentes back-end que são responsáveis pela implantação e configuração de recursos do Azure. O plano de controle do Kubernetes gerencia muitas tarefas, como a colocação de pods do Kubernetes em nós de trabalho. Quase todas as soluções de software como serviço (SaaS) têm um plano de controle para lidar com tarefas entre locatários.

Ao projetar soluções multilocatário, você precisa considerar planos de controle. As seções a seguir fornecem os detalhes necessários para definir o escopo e projetar um plano de controle.

Responsabilidades de um plano de controlo

Não há um modelo único para um plano de controle ou suas responsabilidades. Os requisitos e a arquitetura da sua solução ditam o que o seu plano de controle precisa fazer. Em algumas soluções multilocatário, o plano de controle tem uma ampla gama de responsabilidades e é um sistema complexo por si só. Em outras soluções multilocatário, o plano de controle tem apenas responsabilidades básicas.

Em geral, um plano de controlo pode ter muitas das seguintes responsabilidades principais:

• Provisione e gerencie os recursos do sistema de que o sistema precisa para atender à carga de trabalho, incluindo recursos específicos do locatário. Seu plano de controle pode invocar e orquestrar um pipeline de implantação responsável pelas implantações ou pode executar as próprias operações de implantação.
• Reconfigure os recursos compartilhados para estar ciente de novos locatários. Por exemplo, seu plano de controle pode configurar o roteamento de rede para garantir que o tráfego de entrada seja mapeado para os recursos do locatário correto ou talvez seja necessário dimensionar sua capacidade de recursos.
• Armazene e gerencie a configuração de cada locatário.
• Lide com eventos do ciclo de vida do locatário, incluindo integração, movimentação e desintegração de locatários.
• Acompanhe o uso de seus recursos por cada locatário e o desempenho do sistema.
• Meça o consumo de recursos do seu sistema por cada inquilino. As métricas de consumo podem informar seus sistemas de faturamento ou podem ser usadas para governança de recursos.

Se você usar o modelo de locação totalmente multilocatário e não implantar recursos específicos do locatário, um plano de controle básico poderá apenas rastrear locatários e seus metadados associados. Por exemplo, sempre que um novo locatário se inscreve no seu serviço, o plano de controle pode atualizar os registros apropriados em um banco de dados para que o restante do sistema possa atender às solicitações do novo locatário.

Por outro lado, suponha que sua solução use um modelo de implantação que exija infraestrutura específica do locatário, como o modelo automatizado de locatário único. Nesse cenário, seu plano de controle pode ter responsabilidades adicionais, como implantar ou reconfigurar a infraestrutura do Azure sempre que você integrar um novo locatário. O plano de controle da sua solução provavelmente precisa interagir com os planos de controle para os serviços e tecnologias que você usa, como o Azure Resource Manager ou o plano de controle do Kubernetes.

Aviões de controle mais avançados também podem assumir mais responsabilidades:

• Execute operações de manutenção automatizadas. As operações de manutenção comuns incluem a exclusão ou arquivamento de dados antigos, a criação e o gerenciamento de índices de banco de dados e a rotação de segredos e certificados criptográficos.
• Aloque locatários para implantações ou carimbos existentes, o que às vezes é chamado de posicionamento de locatário.
• Reequilibre os locatários existentes entre os carimbos de implantação.
• Integre com soluções de gerenciamento de clientes externos, como o Microsoft Dynamics 365, para rastrear a atividade do cliente.

Definir o âmbito de um plano de controlo

Você precisa considerar cuidadosamente quanto esforço gastar na construção de um plano de controle para sua solução. Os aviões de controle por si só não fornecem valor imediato para o cliente, então pode não ser fácil justificar o gasto de esforço de engenharia em projetar e construir um plano de controle de alta qualidade. No entanto, à medida que seu sistema cresce e se expande, você precisará cada vez mais de gerenciamento e operações automatizados para poder acompanhar seu crescimento.

Em determinadas situações, você pode não precisar de um plano de controle total. Esta situação pode aplicar-se se o seu sistema tiver menos de cinco inquilinos. Em vez disso, sua equipe pode assumir as responsabilidades de um plano de controle e pode usar operações e processos manuais para integrar e gerenciar locatários. No entanto, você ainda deve ter um processo e um local central para rastrear seus locatários e suas configurações.

À medida que você cresce além de alguns locatários, provavelmente se beneficiará de ter uma maneira de rastrear cada locatário e aplicar monitoramento em toda a sua frota de recursos e locatários. Você também pode notar que sua equipe gasta uma quantidade crescente de tempo e esforço no gerenciamento de locatários. Ou você pode notar bugs ou problemas operacionais devido a inconsistências nas maneiras como os membros da equipe executam tarefas de gerenciamento. Se essas situações ocorrerem, vale a pena considerar a construção de um plano de controle mais abrangente para assumir essas responsabilidades.

Projetar um plano de controle

Depois de determinar os requisitos e o escopo do seu plano de controle, você precisa projetá-lo e arquitetá-lo. Um plano de controlo é um componente importante. Você precisa planejá-lo cuidadosamente, assim como você planejaria os outros elementos do seu sistema.

Planos de controle bem arquitetados

Como um plano de controle é seu próprio sistema, é importante considerar todos os cinco pilares do Azure Well-Architected Framework ao projetar um. As seções a seguir destacam algumas áreas específicas nas quais se deve focar.

Fiabilidade

Os aviões de controlo são frequentemente componentes de missão crítica. É essencial que você planeje o nível de resiliência e confiabilidade que seu plano de controle precisa.

Considere o que acontece se o seu plano de controlo não estiver disponível. Em casos extremos, uma interrupção do plano de controle pode resultar na indisponibilidade de toda a solução. Mesmo que o plano de controle não seja um único ponto de falha, uma interrupção pode ter alguns dos seguintes efeitos:

• Seu sistema não é capaz de integrar novos locatários, o que pode afetar suas vendas e o crescimento do seu negócio.
• Seu sistema não pode gerenciar locatários existentes, o que resulta em mais chamadas para sua equipe de suporte.
• Não é possível medir o consumo dos inquilinos ou faturá-los pelo seu uso, o que resulta em perda de receita.
• Não é possível responder a um incidente de segurança desativando ou reconfigurando um locatário.
• A dívida de alimentos acumula-se, o que resulta em danos a longo prazo para o sistema. Por exemplo, se sua solução exigir limpeza noturna de dados antigos, seus discos poderão ficar cheios ou seu desempenho poderá se degradar.

Defina objetivos de nível de serviço para seu plano de controle, incluindo metas de disponibilidade, o RTO (Recovery Time Objetive, objetivo de tempo de recuperação) e o RPO (Recovery Point Objetive, objetivo de ponto de recuperação). Os objetivos que você define para seu plano de controle podem ser diferentes daqueles que você oferece aos seus clientes.

Siga as orientações do Azure Well-Architected Framework para criar soluções fiáveis em todo o seu sistema, incluindo o seu plano de controlo.

Segurança

Os planos de controlo são frequentemente sistemas altamente privilegiados. Problemas de segurança dentro de um avião de controle podem ter consequências catastróficas. Dependendo de seu design e funcionalidade, um plano de controle pode ser vulnerável a muitos tipos diferentes de ataques, incluindo os seguintes:

• Um plano de controle pode ter acesso a chaves e segredos para todos os locatários. Um invasor que tenha acesso ao seu plano de controle poderá obter acesso aos dados ou recursos de um locatário.
• Um plano de controle geralmente pode implantar novos recursos no Azure. Os atacantes podem explorar seu plano de controle para implantar seus próprios recursos em suas assinaturas, potencialmente incorrendo em cobranças extensas.
• Se um invasor colocar seu plano de controle offline com sucesso, pode haver danos imediatos e de longo prazo ao seu sistema e ao seu negócio. Consulte Confiabilidade, por exemplo, consequências da indisponibilidade de um plano de controle.

Ao projetar e implementar um plano de controle, é essencial seguir as práticas recomendadas de segurança e criar um modelo de ameaça abrangente para documentar e mitigar possíveis ameaças e problemas de segurança em sua solução. Para obter mais informações, consulte as diretrizes do Azure Well-Architected Framework para criar soluções seguras.

Excelência operacional

Como um plano de controle é um componente crítico, você deve considerar cuidadosamente como implantá-lo e operá-lo na produção.

Como outras partes da solução, você deve implantar instâncias que não sejam de produção do seu plano de controle para que possa testar completamente sua funcionalidade. Se seu plano de controle executar operações de implantação, considere como seus planos de controle que não são de produção interagem com seu ambiente do Azure e em qual assinatura do Azure você implanta recursos que não são de produção.

Você também deve planejar como você controla o acesso da sua equipe ao seu plano de controle. Siga as práticas recomendadas para conceder apenas as permissões de que os membros da equipe precisam para desempenhar suas funções. Além de ajudar a evitar incidentes de segurança, essa abordagem ajuda a reduzir o efeito de erros acidentais de configuração.

Componentes

Não há um modelo único para um plano de controle, e os componentes que você projeta e constrói dependem de suas necessidades. Geralmente, um plano de controle consiste em APIs e componentes de trabalho em segundo plano. Em algumas soluções, um plano de controle também pode incluir uma interface do usuário.

Isolar seu plano de controle das cargas de trabalho do locatário

É uma boa prática separar os recursos do seu plano de controle daqueles usados para servir os planos de dados dos seus locatários. Por exemplo, você deve considerar o uso de servidores de banco de dados separados, servidores de aplicativos e planos do Serviço de Aplicativo do Azure e outros componentes. Muitas vezes, é uma boa ideia manter os recursos do seu plano de controle em um grupo de recursos do Azure separado daqueles que contêm recursos específicos do locatário.

Ao isolar seu plano de controle das cargas de trabalho dos locatários, você obtém várias vantagens:

• Você pode configurar o dimensionamento separadamente. Por exemplo, seu plano de controle pode ter requisitos de recursos consistentes e os recursos de seus locatários podem ser dimensionados de forma elástica dependendo de suas necessidades.
• Há uma antepara entre seus planos de controle e de dados, o que ajuda a evitar que problemas barulhentos de vizinhos se espalhem entre os planos de sua solução.
• Os planos de controlo são normalmente sistemas altamente privilegiados que têm elevados níveis de acesso. Ao separar o plano de controle dos planos de dados, você reduz a probabilidade de que uma vulnerabilidade de segurança permita que invasores elevem suas permissões em todo o sistema.
• Você pode implantar configurações de rede e firewall separadas. Planos de dados e planos de controle geralmente exigem diferentes tipos de acesso à rede.

Orquestre sequências de operações de longa duração

As operações que um avião de controlo realiza são frequentemente de longa duração e envolvem a coordenação entre vários sistemas. As operações também podem ter modos de falha complexos. Ao projetar seu plano de controle, é importante usar uma tecnologia adequada para coordenar operações ou fluxos de trabalho de longa duração.

Por exemplo, suponha que, quando você embarca um novo locatário, seu plano de controle executa as seguintes ações em sequência:

1. Implante um novo banco de dados. Esta ação é uma operação de implantação do Azure. Pode levar vários minutos para ser concluído.
2. Atualize o catálogo de metadados do locatário. Essa ação pode envolver a execução de um comando em um banco de dados SQL do Azure.
3. Envie um e-mail de boas-vindas ao novo inquilino. Esta ação invoca uma API de terceiros para enviar o e-mail.
4. Atualize o seu sistema de faturação para se preparar para faturar o novo inquilino. Esta ação invoca uma API de terceiros. Você notou que ele falha intermitentemente.
5. Atualize seu sistema de gerenciamento de relacionamento com o cliente (CRM) para rastrear o novo locatário. Esta ação invoca uma API de terceiros.

Se alguma etapa da sequência falhar, você precisa considerar o que fazer, como:

• Tente novamente a operação com falha. Por exemplo, se o comando SQL do Azure na etapa 2 falhar com um erro transitório, você poderá tentar novamente.
• Continue para a próxima etapa. Por exemplo, você pode decidir que é aceitável se a atualização do seu sistema de cobrança falhar, porque sua equipe de vendas adicionará manualmente o cliente.
• Abandone o fluxo de trabalho e acione um processo de recuperação manual.

Você também precisa considerar como é a experiência do usuário para cada cenário de falha.

Gerenciar componentes compartilhados

Um plano de controle precisa estar ciente de todos os componentes que não são dedicados a locatários específicos, mas são compartilhados. Alguns componentes podem ser compartilhados entre todos os locatários dentro de um carimbo. Outros componentes podem ser compartilhados entre todos os selos em uma região, ou até mesmo compartilhados globalmente em todas as regiões e selos. Sempre que um locatário é integrado, reconfigurado ou desligado, seu plano de controle precisa saber o que fazer com esses componentes compartilhados.

Alguns componentes compartilhados podem precisar ser reconfigurados sempre que um locatário é adicionado ou removido. Por exemplo, suponha que você tenha um perfil do Azure Front Door compartilhado globalmente. Se você adicionar um locatário com um nome de domínio personalizado, seu plano de controle pode precisar atualizar a configuração do perfil para rotear solicitações para esse nome de domínio para o aplicativo correto. Da mesma forma, quando um locatário é desembarcado, seu plano de controle pode precisar remover o nome de domínio personalizado do perfil da Porta da Frente do Azure para evitar ataques de invasão de subdomínio.

Os componentes compartilhados podem ter regras de dimensionamento complexas que seu plano de controle precisa seguir. Por exemplo, suponha que você siga uma abordagem de empacotamento de compartimentos para implantar os bancos de dados de seus locatários. Quando um novo locatário é integrado, você adiciona um novo banco de dados SQL do Azure para esse locatário e, em seguida, atribui-o a um pool elástico SQL do Azure. Você pode ter determinado que precisa aumentar os recursos alocados ao seu pool para cada décimo banco de dados adicionado. Quando você adiciona ou remove um locatário, seu plano de controle precisa reavaliar a configuração do pool e decidir se deseja alterar os recursos do pool. Quando você atingir o número máximo de bancos de dados que pode atribuir a um único pool elástico, precisará criar um novo pool e começar a usar esse pool para novos bancos de dados de locatário. Seu plano de controle precisa assumir a responsabilidade de gerenciar cada um desses componentes compartilhados, dimensioná-los e reconfigurá-los sempre que algo mudar.

Quando seu plano de controle gerencia componentes compartilhados, é importante estar ciente das condições de corrida, que podem ocorrer quando várias operações acontecem em paralelo. Por exemplo, se você integrar um novo locatário ao mesmo tempo em que desintegra um locatário diferente, precisará garantir que seu estado final final seja consistente e atenda aos seus requisitos de dimensionamento.

Use vários planos de controle

Em um ambiente complexo, talvez seja necessário usar vários planos de controle, cada um com diferentes áreas de responsabilidade. Muitas soluções multilocatárias seguem o padrão Deployment Stamps e fragmentam locatários em vários carimbos. Ao usar esse padrão, você pode criar planos de controle separados para responsabilidades globais e de carimbo.

Planos de controlo globais

Um plano de controle global é normalmente responsável pelo gerenciamento geral e rastreamento de inquilinos. Um plano de controlo global pode ter as seguintes responsabilidades:

• Colocação do inquilino. O plano de controle global determina qual carimbo um locatário deve usar. Ele pode fazer essa determinação com base em fatores como a região do locatário, a utilização da capacidade de cada selo e os requisitos de nível de serviço do locatário.
• Integração de inquilinos e gestão do ciclo de vida. Essas responsabilidades incluem o acompanhamento de todos os locatários em todas as implantações.

Planos de controlo de carimbos

Um plano de controle de carimbo é implantado em cada carimbo de implantação e é responsável pelos locatários e recursos alocados para esse carimbo. Um plano de controle de carimbo pode ter estas responsabilidades:

• Criação e gerenciamento de recursos específicos do locatário dentro do carimbo, como bancos de dados e contêineres de armazenamento
• Gerenciamento de recursos compartilhados, incluindo o monitoramento do consumo de recursos compartilhados e a implantação de novas instâncias quando elas estão se aproximando de sua capacidade máxima
• Execução de operações de manutenção dentro do carimbo, como gerenciamento de índice de banco de dados e operações de limpeza

O plano de controle de cada carimbo coordena-se com o plano de controle global. Por exemplo, suponha que um novo locatário se inscreva. O plano de controle global é inicialmente responsável por selecionar um carimbo para os recursos do locatário. Em seguida, o plano de controle global solicita que o plano de controle do carimbo crie os recursos necessários para o locatário.

O diagrama a seguir mostra um exemplo de como os dois planos de controle podem coexistir em um único sistema:

Planos de controle de locatários

Os locatários podem usar um plano de controle no nível do locatário para gerenciar seus próprios recursos lógicos ou físicos. Um plano de controle de locatário pode ter as seguintes responsabilidades:

• Gerenciamento de configuração específica do locatário, como acesso do usuário
• Operações de manutenção iniciadas pelo locatário, como backup de dados ou download de um backup anterior
• Gerenciamento de atualizações, se você permitir que os locatários controlem suas próprias atualizações para seus aplicativos

O diagrama a seguir mostra um sistema complexo que tem um plano de controle global, planos de controle de carimbo e um plano de controle para cada locatário:

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

• John Downs - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure

Outros contribuidores:

• Mick Alberts - Brasil | Redator Técnico
• Bohdan Cherchyk - Brasil | Engenheiro de Clientes Sênior, FastTrack for Azure
• Landon Pierce - Brasil | Engenheiro de Clientes, FastTrack for Azure
• Daniel Scott-Raynsford - Brasil | Estrategista de Tecnologia de Parceiros
• Arsen Vladimirskiy - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos

• Visão geral das considerações arquitetônicas
• Well-Architected Framework do Azure
• Abordagens arquitetônicas para planos de controle em soluções multilocatárias