O Azure oferece muitas opções para organizar seus recursos. Em uma solução multilocatário, há compensações específicas a serem consideradas ao planejar sua estratégia de organização de recursos. Neste artigo, examinamos dois elementos principais da organização de seus recursos do Azure: isolamento de locatário e expansão em vários recursos. Descrevemos algumas abordagens comuns de implantação que podem ter suporte para diferentes modelos de isolamento de locatário. Também descrevemos como trabalhar com os limites e cotas de recursos do Azure e como dimensionar sua solução além desses limites.
Considerações e requisitos
Requisitos de isolamento de locatário
Ao implantar uma solução multilocatário no Azure, você precisa decidir se dedica recursos a cada locatário ou compartilha recursos entre vários locatários. Ao longo das abordagens de multilocação e das seções de diretrizes específicas do serviço desta série, descrevemos as opções e compensações para muitas categorias de recursos. Em geral, há uma variedade de opções para isolamento de locatário. Confira Modelos de locação a serem considerados para uma solução multilocatário a fim de obter mais diretrizes sobre como tomar uma decisão em relação ao modelo de isolamento.
Escala
A maioria dos recursos do Azure, bem como grupos de recursos e assinaturas, impõem limites que podem afetar a capacidade de dimensionamento. Talvez seja necessário considerar o dimensionamento horizontal ou o empacotamento para atender ao número planejado de locatários ou à carga planejada do sistema.
Se você tiver certeza de que não haverá um aumento para um grande número de locatários ou para uma carga alta, não exagere no seu plano de expansão. Mas se há previsão de crescimento da sua solução, considere cuidadosamente seu plano de expansão. Prepare-se para expandir seguindo as diretrizes neste artigo.
Se você tiver um processo de implantação automatizado e precisar dimensionar os recursos, determine como implantará e atribuirá locatários em várias instâncias de recursos. Por exemplo, como você detectará que está se aproximando do número de locatários que podem ser atribuídos a um recurso específico? Você planeja implantar novos recursos justamente quando precisar deles? Ou implantará um pool de recursos com antecedência para estar preparado quando eles forem necessários?
Dica
Nos estágios iniciais de design e desenvolvimento, talvez você não opte por implementar processos de expansão automatizado. Você ainda deve considerar e documentar claramente os processos necessários para expandir conforme crescer. Ao documentar os processos, você facilita para si mesmo automatizá-los se houver necessidade no futuro.
Também é importante evitar fazer suposições em todo o seu código e configuração, pois isso pode limitar sua capacidade de expansão. Por exemplo, talvez você precise expandir para várias contas de armazenamento no futuro. Portanto, ao criar sua camada de aplicativo, verifique se ele pode alternar dinamicamente a conta de armazenamento à qual se conecta com base no locatário ativo.
Abordagens e padrões a serem considerados
Isolamento de locatário
Os recursos do Azure são implantados e gerenciados por meio de uma hierarquia. A maioria dos recursos é implantada em grupos de recursos, que estão contidos em assinaturas. Os grupos de gerenciamento agrupam as assinaturas logicamente. Todas essas camadas hierárquicas estão associadas a um locatário do Microsoft Entra.
Quando você determina como implantar recursos para cada locatário, você pode isolar em níveis diferentes na hierarquia. Cada opção é válida para determinados tipos de soluções multilocatário e vem com benefícios e compensações. Também é comum combinar abordagens, usando diferentes modelos de isolamento para diferentes componentes de uma solução.
Isolamento em um recurso compartilhado
Você pode optar por compartilhar um recurso do Azure entre vários locatários e executar todas as suas cargas de trabalho em uma única instância. Examine as diretrizes específicas do serviço para os serviços do Azure que você usa para entender quaisquer considerações ou opções específicas que possam ser importantes.
Ao executar instâncias únicas de um recurso, você precisa considerar quaisquer limites de serviço, limites de assinatura ou cotas que possam ser alcançados à medida que você expande. Por exemplo, há um número máximo de nós com suporte por um cluster do AKS (Serviço de Kubernetes do Azure) e há um limite superior no número de transações por segundo com suporte de uma conta de armazenamento. Considere como você irá expandir para vários recursos compartilhados à medida que se aproximar desses limites.
Você também precisa garantir que o código do aplicativo esteja totalmente ciente da multilocação e que ele restrinja o acesso aos dados a um locatário específico.
Como ilustração da abordagem de recursos compartilhados, suponha que a Contoso esteja criando um aplicativo SaaS multilocatário que inclua um aplicativo Web, um banco de dados e uma conta de armazenamento. Eles podem decidir implantar recursos compartilhados para atender a todos os clientes. No diagrama a seguir, um único conjunto de recursos é compartilhado por todos os clientes.
Recursos separados em um grupo de recursos
Você também pode implantar recursos dedicados para cada locatário. Você pode implantar uma cópia completa de sua solução para um único locatário. Ou você pode compartilhar alguns componentes entre locatários enquanto outros componentes ficam dedicados a um locatário específico. Essa abordagem é conhecida como particionamento horizontal.
Recomendamos que você use grupos de recursos para gerenciar recursos com o mesmo ciclo de vida. Em alguns sistemas multilocatários, faz sentido implantar recursos para vários locatários em um único grupo de recursos ou em um conjunto de grupos de recursos.
É importante considerar como você implanta e gerencia esses recursos, incluindo se a implantação de recursos específicos do locatário é iniciada pelo pipeline de implantação ou pelo aplicativo. Você também precisa determinar como identificará claramente que recursos específicos estão relacionados a locatários específicos. Considere usar uma estratégia de convenção de nomenclatura clara, marcas de recursos ou um banco de dados de catálogo de locatários.
É uma boa prática usar grupos de recursos separados para os recursos que você compartilha entre vários locatários e os recursos que você implanta para locatários individuais. No entanto, para alguns recursos, o Azure limita o número de recursos de um único tipo que podem ser implantados em um grupo de recursos. Esse limite significa que você pode precisar expandir para vários grupos de recursos à medida que crescer.
Suponha que a Contoso tenha três clientes (locatários): Adventure Works, Fabrikam e Tailwind. Eles podem optar por compartilhar o aplicativo Web e a conta de armazenamento entre os três locatários, e implantar bancos de dados individuais para cada locatário. O diagrama a seguir mostra um grupo de recursos que contém recursos compartilhados e outro grupo de recursos que contém o banco de dados de cada locatário.
Grupos de recursos separados em uma assinatura
Ao implantar um conjunto de recursos para cada locatário, considere usar grupos de recursos específicos de locatário dedicados. Por exemplo, quando você segue o padrão Selos de Implantação, cada carimbo deve ser implantado em seu grupo de recursos. Você pode considerar a implantação de vários grupos de recursos específicos de locatário em uma assinatura compartilhada do Azure, que permite configurar facilmente políticas e regras de controle de acesso.
Você pode optar por criar um conjunto de grupos de recursos para cada locatário e também grupos de recursos compartilhados para quaisquer recursos compartilhados.
Ao implantar grupos de recursos específicos do locatário em assinaturas compartilhadas, lembre-se do número máximo de grupos de recursos em cada assinatura e de outros limites de nível de assinatura que se aplicam aos recursos implantados. À medida que você se aproxima desses limites, talvez seja necessário expandir para várias assinaturas.
Em nosso exemplo, a Contoso pode optar por implantar um selo para cada um de seus clientes e colocar os selos em grupos de recursos dedicados em uma única assinatura. No diagrama a seguir, uma assinatura, que contém três grupos de recursos, é criada para cada cliente.
Assinaturas separadas
Ao implantar assinaturas específicas do locatário, você pode isolar completamente os recursos específicos do locatário. Além disso, como a maioria das cotas e limites se aplicam a uma assinatura, o uso de uma assinatura separada por locatário garante que cada locatário tenha uso total de quaisquer cotas aplicáveis. Para alguns tipos de conta de cobrança do Azure, você pode criar assinaturas de forma programática. Você também pode usar as reservas do Azure e o plano de economia do Azure para computação entre assinaturas.
Informe-se sobre o número de assinaturas que você pode criar. O número máximo de assinaturas pode diferir, dependendo de sua relação comercial com a Microsoft ou um parceiro da Microsoft, como no caso de ter um contrato empresarial.
No entanto, talvez seja mais difícil solicitar aumentos de cota quando você trabalha com um grande número de assinaturas. A API de Cota fornece uma interface programática para alguns tipos de recursos. No entanto, para muitos tipos de recursos, os aumentos de cota devem ser solicitados iniciando um caso de suporte. Também pode ser um desafio trabalhar com contratos de suporte e casos de suporte do Azure quando você trabalha com muitas assinaturas.
Considere agrupar suas assinaturas específicas de locatário em uma hierarquia de grupo de gerenciamento para facilitar o gerenciamento de regras e políticas de controle de acesso.
Por exemplo, suponha que a Contoso decidiu criar assinaturas separadas do Azure para cada um de seus três clientes, conforme mostrado no diagrama a seguir. Cada assinatura contém um grupo de recursos, com o conjunto completo de recursos para esse cliente.
Cada assinatura contém um grupo de recursos, com o conjunto completo de recursos para esse cliente.
Eles usam um grupo de gerenciamento para simplificar o gerenciamento de suas assinaturas. Ao incluir Produção no nome do grupo de gerenciamento, eles podem distinguir claramente quaisquer locatários de produção de locatários de não produção ou de teste. Aos locatários de não produção aplicam-se diferentes regras e políticas de controle de acesso do Azure.
Todas as suas assinaturas estão associadas a um único locatário do Microsoft Entra. Usar um único locatário do Microsoft Entra significa que as identidades da equipe da Contoso, incluindo usuários e entidades de serviço, podem ser usadas em toda a propriedade do Azure.
Assinaturas separadas em locatários separados do Microsoft Entra
Também é possível criar manualmente locatários individuais do Microsoft Entra para cada um de seus locatários ou implantar seus recursos em assinaturas nos locatários do Microsoft Entra de seus clientes. No entanto, trabalhar com vários locatários do Microsoft Entra dificulta a autenticação, o gerenciamento de atribuições de função, a aplicação de políticas globais e a execução de muitas outras operações de gerenciamento.
Aviso
Aconselhamos a criação de vários locatários do Microsoft Entra para a maioria das soluções multilocatário. Trabalhar em locatários do Microsoft Entra apresenta complexidade extra e reduz sua capacidade de expandir e gerenciar seus recursos. Normalmente, essa abordagem é usada apenas por MSPs (provedores de serviços gerenciados), que operam ambientes do Azure em nome de seus clientes.
Antes de se esforçar para implantar diversos locatários do Microsoft Entra, considere se você pode cumprir seus requisitos usando grupos de gerenciamento ou assinaturas em um único locatário.
Em situações em que você precisa gerenciar recursos do Azure em assinaturas vinculadas a vários locatários do Microsoft Entra, considere usar o Azure Lighthouse para ajudar a gerenciar seus recursos em seus locatários do Microsoft Entra.
Por exemplo, a Contoso poderia criar locatários separados do Microsoft Entra e assinaturas separadas do Azure para cada um de seus clientes, conforme mostrado no diagrama a seguir.
Um locatário do Microsoft Entra é configurado para cada um dos locatários da Contoso, que contém uma assinatura e os recursos necessários. O Azure Lighthouse está conectado a cada locatário do Microsoft Entra.
Empacotamento
Independentemente do modelo de isolamento de recursos, é importante considerar quando e como sua solução será expandida por vários recursos. Talvez seja preciso expandir seus recursos à medida que a carga em seu sistema aumentar ou à medida que o número de locatários aumentar. Considere o empacotamento a fim de implantar um número ideal de recursos para suas necessidades.
Dica
Em muitas soluções, é mais fácil expandir todo o conjunto de recursos juntos, em vez de expandir recursos individualmente. Considere seguir o padrão Marcações de Implantação.
Limites de recursos
Os recursos do Azure têm limites e cotas que devem ser considerados no planejamento da solução. Por exemplo, os recursos podem dar suporte a um número máximo de solicitações simultâneas ou configurações específicas do locatário.
A maneira como você configura e usa cada recurso também afeta a escalabilidade desse recurso. Por exemplo, suponhamos que, dada uma determinada quantidade de recursos de computação, seu aplicativo possa responder com êxito a um número definido de transações por segundo. Além desse ponto, talvez seja necessário expandir. O teste de desempenho ajuda você a identificar o ponto em que seus recursos não atendem mais aos seus requisitos.
Observação
O princípio de expansão para vários recursos se aplica mesmo quando você trabalha com serviços que dão suporte a várias instâncias.
Por exemplo, o Serviço de Aplicativo do Azure dá suporte à expansão do número de instâncias do seu plano, mas há limites para o quanto você pode expandir um único plano. Em um aplicativo multilocatário de alta escala, você pode exceder esses limites e precisar implantar mais recursos Planos do Serviço de Aplicativo para acompanhar seu crescimento.
Ao compartilhar alguns de seus recursos entre locatários, você deve primeiro determinar o número de locatários aos quais o recurso dá suporte, quando configurado de acordo com seus requisitos. Em seguida, implante quantos recursos precisar para atender ao número total de locatários.
Por exemplo, suponha que você implante um Gateway de Aplicativo do Azure como parte de uma solução SaaS multilocatário. Examine o design do aplicativo, teste o desempenho do gateway de aplicativo sob carga e verifique sua configuração. Em seguida, você determina que um único recurso de gateway de aplicativo pode ser compartilhado entre 100 clientes. De acordo com o plano de crescimento de sua organização, você espera integrar 150 clientes em seu primeiro ano, portanto, você precisará planejar a implantação de vários gateways de aplicativos para atender à carga esperada.
No diagrama anterior, há dois gateways de aplicativo. O primeiro gateway é dedicado aos clientes de 1 a 100 e o segundo é dedicado aos clientes de 101 a 200.
Limites de grupo de recursos e assinatura
Se você trabalha com recursos compartilhados ou dedicados, é importante considerar os limites. O Azure limita o número de recursos que podem ser implantados em um grupo de recursos e em uma assinatura do Azure. À medida que você se aproxima desses limites, você precisa planejar a escalabilidade em vários grupos de recursos ou assinaturas.
Por exemplo, suponha que você implante um gateway de aplicativo dedicado para cada um de seus clientes em um grupo de recursos compartilhados. Para alguns recursos, o Azure dá suporte à implantação de até 800 recursos do mesmo tipo em um único grupo de recursos. Portanto, ao atingir esse limite, você precisa implantar quaisquer novos gateways de aplicativo em outro grupo de recursos. No diagrama a seguir, há dois grupos de recursos. Cada grupo de recursos contém 800 gateways de aplicativo.
Empacotamento de locatários entre grupos de recursos e assinaturas
Você também pode aplicar o conceito de empacotamento em recursos, grupos de recursos e assinaturas. Por exemplo, quando você tem um pequeno número de locatários, pode implantar um único recurso e compartilhá-lo entre todos os seus locatários. O diagrama a seguir mostra o empacotamento em um único recurso.
À medida que cresce, você pode se aproximar do limite de capacidade para um único recurso e expandir para vários recursos (R). O diagrama a seguir mostra o empacotamento em vários recursos.
Com o tempo, você pode atingir o limite do número de recursos em um único grupo de recursos e implantar vários recursos (R) em vários grupos de recursos (G). O diagrama a seguir mostra o empacotamento em vários recursos, em vários grupos de recursos.
E à medida que cresce ainda mais, você pode implantar em várias assinaturas (S) , cada uma contendo vários grupos de recursos (G) com vários recursos (R). O diagrama a seguir mostra o empacotamento em vários recursos, em vários grupos de recursos e assinaturas.
Ao planejar sua estratégia de expansão, você pode expandir para um número extremamente grande de locatários e sustentar um alto nível de carga.
Marcações
As marcações de recursos permitem adicionar metadados personalizados aos recursos do Azure, o que pode ser útil para gerenciamento e acompanhamento de custos. Para obter mais detalhes, confira Alocar custos usando marcações de recursos.
Pilhas de implantação
As pilhas de implantação permitem agrupar recursos com base em um tempo de vida comum, mesmo que incluam vários grupos de recursos ou assinaturas. As pilhas de implantação são úteis quando você implanta recursos específicos do locatário, especialmente se você tiver uma abordagem de implantação que signifique implantar diferentes tipos de recursos em locais diferentes devido a questões de escala ou conformidade. As pilhas de implantação também lhe permitem remover facilmente todos os recursos relacionados a um único locatário em uma operação, se esse locatário estiver desativado. Para saber mais, confira Pilhas de implantação.
Antipadrões a serem evitados
- Não planejar para a expansão. Tenha uma compreensão clara dos limites dos recursos que você implantará e quais limites podem se tornar importantes, à medida que sua carga ou número de locatários aumenta. Planeje como você implantará recursos adicionais à medida que expandir, e teste o plano.
- Não planejar o empacotamento. Mesmo que você não precise crescer imediatamente, planeje expandir seus recursos do Azure para vários recursos, grupos de recursos e assinaturas ao longo do tempo. Evite fazer suposições no código de aplicativo, como a existência de um único recurso quando você pode precisar expandir para vários recursos no futuro.
- Expandir muitos recursos individuais. Se você tiver uma topologia de recursos complexa, talvez fique difícil expandir cada componente individualmente. Geralmente é mais simples expandir sua solução como uma unidade, seguindo o padrão Selos de Implantação.
- Implantar recursos isolados para cada locatário, quando não for necessário. Em muitas soluções, é mais econômico e eficiente implantar recursos compartilhados para vários locatários.
- Falha ao rastrear recursos específicos de locatário. Se você implantar recursos específicos de locatário, será preciso entender quais recursos são alocados a quais locatários. Essas informações são importantes para fins de conformidade, para acompanhar os custos e para desprovisionar recursos se um locatário estiver desativado. Considere usar marcações de recurso para acompanhar as informações do locatário sobre os recursos e considere usar pilhas de implantação para agrupar recursos específicos do locatário em uma unidade lógica, independentemente do grupo de recursos ou da assinatura em que estão.
- Usar locatários separados do Microsoft Entra. Em geral, não é aconselhável provisionar vários locatários do Microsoft Entra. O gerenciamento de recursos entre locatários do Microsoft Entra é complexo. É mais simples expandir as assinaturas vinculadas a um único locatário do Microsoft Entra.
- Exagerar na expansão quando ela não é necessária. Em algumas soluções, você sabe com certeza que nunca crescerá além de um certo nível de expansão. Nesses cenários, não há necessidade de criar uma lógica de expansão complexa. No entanto, se a sua organização planeja crescer, você precisará estar preparado para expandir – potencialmente em curto prazo.
Colaboradores
Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.
Autor principal:
- John Downs | Engenheiro de software principal
Outros colaboradores:
- Jason Beck | Engenheiro de cliente sênior, FastTrack for Azure
- Bohdan Cherchyk | Engenheiro de Cliente Sênior da FastTrack para Azure
- Laura Nicolas | Engenheira de cliente sênior, FastTrack for Azure
- Arsen Vladimirskiy | Engenheiro principal de atendimento ao cliente, FastTrack for Azure
- Joshua Waddell | Engenheiro de cliente sênior, FastTrack for Azure
Para ver perfis não públicos do LinkedIn, entre no LinkedIn.
Próximas etapas
Confira as abordagens de Gerenciamento e alocação de custos.