Considerações para planos de controle multilocatário

Uma solução multilocatário 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 desenvolver um plano de controle que atenda às suas necessidades.

Por exemplo, considere um sistema de escrituração para gerenciar registros financeiros. Vários locatários armazenam seus registros financeiros no sistema. Quando os usuários finais acessam o sistema para exibir e inserir seus registros financeiros, eles usam o plano de dados. O plano de dados é provavelmente o principal componente de aplicativo para a sua solução. É bem provável que seus locatários pensem nele como a maneira de usar o sistema para a finalidade pretendida. O plano de controle, por sua vez, é o componente que integra novos locatários, cria bancos de dados para cada um deles 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 então, 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, o Azure Resource Manager, é um conjunto de APIs, ferramentas e componentes de back-end responsáveis por implantar e configurar os recursos do Azure. O plano de controle do Kubernetes gerencia muitas tarefas, como o posicionamento 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 desenvolver 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 desenvolver um plano de controle.

Responsabilidades de um plano de controle

Não há um modelo único para um plano de controle ou suas responsabilidades. Os requisitos e a arquitetura da solução ditam o que o 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 controle pode ter muitas das seguintes responsabilidades principais:

• Gerenciamento de recursos: provisionar e gerenciar os recursos de que o sistema precisa para atender à carga de trabalho, incluindo os recursos específicos do locatário. Seu plano de controle pode invocar e orquestrar um pipeline de implantação que seja responsável pelas implantações ou pode executar as próprias operações de implantação.
• Configuração de recursos: reconfigurar os recursos compartilhados para conhecer os 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.
• Configuração do locatário: armazenar e gerenciar a configuração de cada locatário.
• Gerenciamento do ciclo de vida do locatário: lidar com eventos do ciclo de vida do locatário, incluindo a integração, movimentação e remoção de locatários.
• Telemetria: acompanhar o uso de recursos de cada locatário, bem como o desempenho do sistema.
• Rastreamento de consumo: medir o consumo de recursos do sistema de cada locatário. 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 nenhum recurso específico do locatário, um plano de controle básico poderá apenas rastrear os locatários e seus metadados associados. Por exemplo, sempre que um novo locatário se inscreve em 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 requeira uma infraestrutura específica do locatário, como o modelo de locatário único automatizado. Nesse cenário, seu plano de controle poderá ter mais responsabilidades, como implantar ou reconfigurar a infraestrutura do Azure sempre que você integrar um novo locatário. Nesse tipo de solução, o plano de controle provavelmente precisa interagir com os planos de controle para os serviços e as tecnologias que você usa, como o Azure Resource Manager ou o plano de controle do Kubernetes.

Os planos de controle mais avançados também podem assumir mais responsabilidades:

• Executar operações de manutenção automatizadas: as operações de manutenção comuns incluem excluir ou arquivar dados antigos, criar e gerenciar índices de banco de dados e fazer a rotação de segredos e certificados criptográficos.
• Posicionamento do locatário: aloque locatários para implantações ou selos existentes, que podem ser baseados em vários critérios, incluindo metas de utilização de selo, requisitos de locatário e estratégias de empacotamento de compartimento.
• Rebalanceamento de locatário: reequilibre os locatários existentes entre os selos de implantação à medida que sua utilização muda.
• Rastreamento de atividades do cliente: integre a soluções de gerenciamento de clientes externos, como o Microsoft Dynamics 365, para acompanhar a atividade do cliente.

Definir o escopo de um plano de controle

Você precisa considerar com cautela quanto esforço empregar na criação de um plano de controle para sua solução. Os planos de controle por si só não fornecem valor imediato ao cliente, então pode não ser fácil justificar o esforço de engenharia empregado no projeto e na criação de 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 automatizadas para poder acompanhar seu crescimento.

Em determinadas situações, talvez você não precise de um plano de controle total. Essa situação poderá se aplicar se o sistema tiver menos de 5 a 10 locatários. Em vez disso, sua equipe pode assumir as responsabilidades de um plano de controle e 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ê crescer além de alguns locatários, provavelmente se beneficiará de ter uma maneira de rastrear cada locatário e aplicar o monitoramento em toda a sua frota de recursos e locatários. Você talvez observe que sua equipe gasta cada vez mais tempo e se esforça cada vez mais no gerenciamento de locatários. Ou você talvez observe bugs ou problemas operacionais devido a inconsistências nas maneiras que os membros da equipe executam tarefas de gerenciamento. Se essas situações ocorrerem, valerá a pena considerar a criaçã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ê precisará projetá-lo e arquitetá-lo. Um plano de controle é um componente importante. Você precisa planejá-lo com cautela, assim como 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 concentrar.

Confiabilidade

Os planos de controle geralmente são componentes críticos. É essencial que você planeje o nível de resiliência e confiabilidade que seu plano de controle precisa.

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

• Seu sistema não será capaz de integrar novos locatários, podendo afetar suas vendas e o crescimento dos negócios.
• Seu sistema não poderá gerenciar locatários existentes, resultando em mais chamadas para sua equipe de suporte.
• Não será possível avaliar o consumo de locatários nem cobrá-los pelo uso, resultando em perda de receita.
• Você não poderá responder a um incidente de segurança desabilitando ou reconfigurando um locatário.
• O déficit de manutenção se acumulará, resultando em danos de longo prazo ao sistema. Por exemplo, se sua solução requerer limpeza noturna de dados antigos, os discos poderão ficar cheios ou seu desempenho poderá ser prejudicado.

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

Siga as diretrizes do Azure Well-Architected Framework para criar soluções confiáveis em todo o sistema, incluindo o plano de controle.

Segurança

Os planos de controle geralmente são sistemas altamente privilegiados. Problemas de segurança em um plano de controle podem ter consequências catastróficas. Dependendo de seu design e funcionalidade, um plano de controle pode estar vulnerável a muitos tipos diferentes de ataques, incluindo o seguinte:

• Um plano de controle pode ter acesso a chaves e segredos para todos os locatários. Um invasor que tem acesso ao seu plano de controle pode obter acesso aos dados ou recursos de um locatário.
• Um plano de controle geralmente pode implantar novos recursos no Azure. Os invasores podem explorar seu plano de controle para implantar os próprios recursos em suas assinaturas, o que pode incorrer em cobranças extensivas.
• Se um invasor conseguir colocar seu plano de controle offline, poderá haver danos imediatos e de longo prazo ao seu sistema e à sua empresa. Consulte Confiabilidade, por exemplo, consequências de um plano de controle se tornar indisponível.

Quando você projetar e implementar um plano de controle, será essencial seguir as práticas recomendadas de segurança e criar um modelo abrangente de ameaças 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 com cautela 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 plano de controle para que possa testar integralmente 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 interagirão com seu ambiente do Azure e em qual assinatura do Azure você implantará recursos que não são de produção. Além disso, planeje como você limpa os recursos de teste rapidamente para que eles não gerem encargos acidentalmente.

Você também deve planejar como controlar o acesso da sua equipe ao seu plano de controle. Siga as práticas recomendadas para conceder apenas as permissões que os membros da equipe precisam para executar suas obrigaçõ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 cria dependem de suas necessidades. Normalmente, 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, que sua equipe ou até mesmo seus clientes podem usar.

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

Uma prática recomendada é separar os recursos do seu plano de controle daqueles usados para atender aos planos de dados de seus locatários. Por exemplo, você deve considerar o uso de servidores de banco de dados separados, servidores de aplicativos e outros componentes. Muitas vezes, é uma boa ideia manter os recursos do plano de controle em um grupo separado de recursos do Azure 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:

• É possível 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á um bulkhead entre seus planos de controle e de dados, o que ajuda a evitar que problemas de vizinho barulhento se espalhem entre os planos de sua solução.
• Em geral, os planos de controle são sistemas altamente privilegiados que têm altos 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 separadas de rede e firewall. Planos de dados e planos de controle geralmente requerem diferentes tipos de acesso à rede.

Orquestrar sequências de operações de execução prolongada

As operações que um plano de controle executa geralmente são de execução prolongada e envolvem a coordenação entre vários sistemas. As operações também podem ter modos de falha complexos. Quando você projetar seu plano de controle, será importante usar uma tecnologia adequada para coordenar operações ou fluxos de trabalho de execução prolongada.

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

1. Implantar um novo banco de dados. Essa ação é uma operação de implantação do Azure. Ela pode demorar vários minutos.
2. Atualize seu 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 email de boas-vindas para o novo locatário. Essa ação invoca uma API de terceiros para enviar o email.
4. Atualize seu sistema de cobrança para se preparar para faturar o novo locatário. Essa ação invoca uma API de terceiros. Você observou que ela falha intermitentemente.
5. Atualize seu sistema de gerenciamento de relacionamento com o cliente (CRM) para rastrear o novo locatário. Essa ação invoca uma API de terceiros.

Se alguma etapa na sequência falhar, você precisará considerar o que fazer, como:

• Tentar novamente a operação que falhou. Por exemplo, se o comando SQL do Azure na etapa 2 falhar com um erro transitório, você poderá repeti-lo.
• Siga para a próxima etapa. Por exemplo, você poderá decidir que é aceitável se a atualização do sistema de cobrança falhar, porque sua equipe de vendas poderá adicionar manualmente o cliente depois.
• 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 contidos em um selo. Outros componentes podem ser compartilhados entre todos os selos em uma região, ou até mesmo compartilhados globalmente entre todas as regiões e selos. Sempre que um locatário é integrado, reconfigurado ou removido, 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 for 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, talvez seja necessário atualizar a configuração do perfil do seu plano de controle para rotear solicitações desse nome de domínio para o aplicativo correto. Da mesma forma, quando um locatário é removido, seu plano de controle pode precisar remover o nome de domínio personalizado do perfil do Azure Front Door para evitar ataques de aquisição de subdomínio.

Os componentes compartilhados podem ter regras complexas de dimensionamento que seu plano de controle precisa seguir. Por exemplo, suponha que você siga uma abordagem de empacotamento de compartimento 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 o atribui a um pool elástico do SQL do Azure. Você pode ter determinado que precisa aumentar os recursos alocados ao pool para cada décimo banco de dados que adicionar. 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. Ao atingir o número máximo de bancos de dados que você pode atribuir a um único pool elástico, você precisará criar um novo pool e começar a usá-lo para novos bancos de dados de locatário. Seu plano de controle precisa assumir a responsabilidade de gerenciar cada um desses componentes compartilhados, dimensionando-os e reconfigurando-os sempre que algo for alterado.

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 paralelamente. Por exemplo, se você integrar um novo locatário ao mesmo tempo que remover um locatário diferente, precisará garantir que seu estado final seja consistente e atenda aos requisitos de dimensionamento.

Usar 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ário seguem o padrão de Selos de Implantação e locatários compartilhados em vários selos. Ao usar esse padrão, você pode criar planos de controle separados para responsabilidades globais e de selo.

Planos de controle globais

Um plano de controle global geralmente é responsável pelo gerenciamento geral e rastreamento de locatários. Um plano de controle global pode ter as seguintes responsabilidades:

• Posicionamento do locatário. O plano de controle global determina qual selo 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.
• Gerenciamento do ciclo de vida e de integração do locatário. Essas responsabilidades incluem o rastreamento de todos os locatários em todas as implantações.

Planos de controle de selo

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

• Criar e gerenciar recursos específicos do locatário no selo, como bancos de dados e contêineres de armazenamento.
• Gerenciar recursos compartilhados, incluindo o monitoramento do consumo de recursos compartilhados e a implantação de novas instâncias quando elas estiverem se aproximando de sua capacidade máxima.
• Executar operações de manutenção no selo, como operações de limpeza e gerenciamento de índice de banco de dados.

O plano de controle de cada selo é coordenado 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 selo para os recursos do locatário. Em seguida, o plano de controle global solicita que o plano de controle do selo 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ário

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 o acesso de 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 selo e um plano de controle para cada locatário:

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

• John Downs | Engenheiro de software principal

Outros colaboradores:

• Mick Alberts | Escritor Técnico
• Bohdan Cherchyk | Engenheiro de Cliente Sênior da FastTrack para Azure
• Landon Pierce | Engenheiro do cliente, FastTrack for Azure
• Daniel Scott-Raynsford | Estrategista de Tecnologia Do Parceiro
• Arsen Vladimirskiy | Engenheiro de Cliente Principal, FastTrack for Azure

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

Próximas etapas

• Visão geral das considerações de arquitetura
• Estrutura bem arquitetada do Azure
• Abordagens de arquitetura para planos de controle em soluções multilocatário