Geo-redundância
Apenas SCEPman Enterprise Edition
Esta arquitetura de referência mostra como executar uma aplicação do Azure App Service em múltiplas regiões para alcançar alta disponibilidade.
A georredudância / alta disponibilidade está atualmente disponível apenas para o App Service principal do SCEPman. Justificativa: os utilizadores do Certificate Master são administradores com cargas de trabalho de certificados normalmente não críticas em termos de tempo e com conhecimento dos procedimentos para lidar com esses cenários.
Arquitetura
Como ilustrado acima, a implementação georredundante utiliza um perfil do Azure Traffic Manager, que encaminha pedidos (baseados em DNS) para a CA do SCEPman para um par de instâncias do SCEPman que são implementadas em diferentes localizações geográficas. As instâncias individuais do SCEPman comunicam com o mesmo KeyVault, Storage Account e AAD e, assim, partilham a mesma Root CA. Para além de equilibrar o tráfego com base num conjunto de algoritmos de encaminhamento que pode escolher, o Traffic Manager também verifica continuamente ambas as instâncias do SCEPman. Caso uma instância fique indisponível, todo o tráfego será automaticamente encaminhado para a instância disponível.
A Microsoft discute em este artigo três estratégias diferentes de Geo-Redundancy que podem ser usadas para gerir este tipo de arquitetura. No entanto, no nosso caso, vamos usar a abordagem Active/Active . Isto significa que ambas as regiões estão ativas e os pedidos são balanceados entre elas. Se uma região ficar indisponível ou tiver alguma latência por qualquer motivo, o Traffic Manager encaminhará o tráfego para o segundo App Service.
Certifique-se de consultar a lista de regiões disponíveis da Microsoft e a respetiva região emparelhada. Usar regiões não emparelhadas pode levar a problemas durante a configuração desta redundância.
Fluxo de trabalho
Primeiro, o App Service do SCEPman será clonado para outra localização geográfica.
Depois, o Traffic Manager é configurado e os seus Endpoints são adicionados e ligados a ორივos App Services do SCEPman.
Depois, os domínios personalizados para ambos os App Services são configurados.
Por fim, o registo DNS CNAME é configurado, apontando o seu domínio personalizado para o Traffic Manager.
Clonar App
Para clonar um App Service, primeiro é necessário criar um novo App Service Plan numa segunda localização geográfica, é aí que a App clonada será implementada. Pode criá-lo no mesmo grupo de recursos do SCEPman ou num novo. Veja a captura de ecrã abaixo:
Requisitos de clonagem do App Service (via Módulo SCEPman PowerShell):
SCEPman 2.2 ou superior
Módulo SCEPman PowerShell 1.6.3.0 ou superior
permissões de Global Admin
O seguinte comando CMDlet irá clonar o seu App Service do SCEPman e configurar todas as permissões necessárias:
SourceAppServiceName: O nome do App Service do SCEPman existente.
TargetAppServiceName: O nome do novo App Service do SCEPman clonado.
TargetAppServicePlan: O nome do App Service Plan para a instância clonada do SCEPman. O App Service Plan já deve existir no TargetResourceGroup.
SourceResourceGroup: (Opcional) O grupo de recursos do Azure que aloja o App Service do SCEPman existente. Deixe em branco para deteção automática.
TargetResourceGroup: (Opcional) O grupo de recursos do Azure que aloja o novo App Service do SCEPman. Deixe em branco para detetar automaticamente o grupo de recursos do App Service Plan.
SourceSubscriptionId: (Opcional) O ID da Subscription onde o SCEPman está instalado. Pode ser omitido se já estiver pré-selecionado no az ou use a flag SearchAllSubscriptions para procurar em todas as subscrições acessíveis
TargetSubscriptionId: (Opcional) O ID da Subscription onde o SCEPman deverá ser instalado. Pode ser omitido se for o mesmo que SourceSubscriptionId.
SearchAllSubscriptions: (Opcional) Defina esta flag para procurar o App Service do SCEPman em todas as subscrições. Caso contrário, selecione previamente a subscrição correta no az ou passe o SubscriptionId correto.
Exemplo
Clonar um App Service existente "as-scepman-nrg5reuov63vk"
Após a implementação ter terminado com sucesso, navegue até ao App Service clonado e verifique a página inicial do SCEPman para confirmar que todas as permissões estão definidas corretamente e que tudo está verde e ligado (isto pode demorar até 3 minutos após a conclusão da implementação).
Para evitar um único ponto de falha, recomendamos definir o WEBSITE_RUN_FROM_PACKAGE do App Service clonado para o segundo host de artefactos independente no Azure.
Canal de produção:
https://install.scepman.com/dist/Artifacts.zip
O App Service original deve ter por defeito o primeiro host de artefactos, que aponta para um repositório GitHub. Para mais informações, consulte Artefatos da aplicação.
Clonar um App Service tem algumas restrições, tais como autoscale definições, agenda de cópias de segurança definições, App Insights, etc. As configurações que não podem ser clonadas têm de ser novamente configuradas manualmente no App Service clonado. Além disso, alterações às definições de um AppService não serão sincronizadas automaticamente com o segundo App Service se forem efetuadas após a operação de clonagem. Para mais informações, visite https://docs.microsoft.com/en-us/azure/app-service/app-service-web-app-cloning#current-restrictions
Configurar o Traffic Manager
Siga os passos abaixo para criar e configurar o Traffic Manager e equilibrar o tráfego entre ambas as instâncias do SCEPman:
Procure no Marketplace por perfil do Traffic Manager e clique Criar.
Preencha os campos e escolha o seu grupo de recursos do SCEPman
Depois clique em Criar.
Depois de o Traffic Manager estar implementado, abra-o e clique em Configuração
Altere as definições da seguinte forma e guarde
Adicionar Endpoints
Primeiro Endpoint
Depois, em Settings escolha Endpoints
Escolha "Azure Endpoint" como Type, indique um nome para o primeiro Endpoint e "App Service" como tipo de recurso de destino
Escolha o seu App Service principal do SCEPman como recurso de destino
Segundo Endpoint
Repita os mesmos passos para o segundo endpoint e escolha o segundo App Service do SCEPman (clonado) como recurso de destino
Configuração de Domínio Personalizado
Após uma implementação e configuração bem-sucedidas dos Endpoints do Traffic Manager, é necessário configurar o mesmo domínio personalizado para ambos os SCEPman, conforme descrito aqui.
Certifique-se de alterar o valor da definição AppConfig:BaseUrl para ambos os dos App Services do SCEPman após os domínios personalizados terem sido criados.
Configuração de DNS
No Resumo do Traffic Manager, encontrará o nome DNS que precisa de ser adicionado ao seu DNS
Navegue até ao seu serviço de gestão de DNS (por ex. Azure DNS Zones)
Remova quaisquer entradas CNAME incorretas possivelmente existentes que apontem para uma das instâncias do Azure App Service e adicione um CNAME que mapeie o domínio personalizado do SCEPman criado para o nome DNS do Traffic Manager. No exemplo abaixo, o CNAME deve apontar para gk-blueprint-scepman.trafficmanager.net.
Em Zona DNS do Azure, para modificar um registo, primeiro tem de remover o bloqueio de DNS navegando para Locks.
Ao concluir a configuração, certifique-se de atualizar o URL do SCEP Server nos seus perfil(s) SCEP no Intune. O novo URL deverá ser o domínio personalizado que criou, com "/certsrv/mscep/mscep.dll" no final.
Redundância de Geo do Storage Account
O Storage Account utilizado para o SCEPman também deve ser configurado para redundância. A configuração predefinida do SCEPman usa Locally Redundant Storage (LRS), que utiliza apenas uma única região. Por exemplo, configure Geo-redundant storage (GRS).
Última atualização
Isto foi útil?