> For the complete documentation index, see [llms.txt](https://docs.scepman.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.scepman.com/pt/configuracao-do-azure/geo-redundancy.md). # Redundância geográfica {% hint style="warning" %} Apenas SCEPman Enterprise Edition {% endhint %} Esta arquitetura de referência mostra como executar uma aplicação no Azure App Service em várias regiões para alcançar alta disponibilidade. {% hint style="info" %} A geo-redundância / alta disponibilidade está atualmente disponível apenas para o SCEPman App Service (principal). Motivo: 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 de procedimentos para lidar com esses cenários. {% endhint %} ## Arquitetura ![](/files/2e29609a6fc26d657e436f437b1bd6ddb2d0a8bd) Como ilustrado acima, a implementação geo-redundante tira partido de um perfil do Azure Traffic Manager, que encaminha pedidos (com base em DNS) para o SCEPman CA para um par de instâncias SCEPman implementadas em geolocalizações diferentes. As instâncias individuais SCEPman comunicam com o mesmo KeyVault, Storage Account e AAD e, por isso, partilham o mesmo Root CA. Para além de equilibrar o tráfego com base num conjunto de algoritmos de encaminhamento à escolha, 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](https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/app-service-web-app/multi-region) três estratégias diferentes de Geo-Redundância que podem ser usadas para gerir este tipo de arquitetura. No entanto, no nosso caso, vamos usar a **Ativo/Ativo** abordagem. Isto significa que ambas as regiões estão ativas e os pedidos são equilibrados 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. {% hint style="info" %} Certifique-se de consultar [a lista de regiões disponíveis da Microsoft](https://learn.microsoft.com/en-us/azure/reliability/regions-list#azure-regions-list-1) e a respetiva região emparelhada. Utilizar regiões não emparelhadas pode causar problemas durante a configuração desta redundância. {% endhint %} ## Fluxo de trabalho 1. Clone o SCEPman App Service para outra geolocalização. 2. Configure o Traffic Manager e associe os seus Endpoints a ambos os SCEPman App Services. 3. Configure o mesmo Domínio Personalizado para ambos os App Services. 4. Configure o registo CNAME do DNS, apontando o seu domínio personalizado para o Traffic Manager. ## Passos {% stepper %} {% step %} ### Clonar App Para clonar um App Service, primeiro precisa de criar um novo **App Service Plan** numa segunda geolocalização; é aí que a aplicação clonada será implementada. Pode criá-lo no mesmo grupo de recursos do SCEPman ou num novo. Veja a captura de ecrã abaixo: ![Criação de um novo App Service Plan com Windows](/files/82d07ebddc2b78c36da7f00177502327df335afa) {% hint style="info" %} Requisitos para a clonagem do App Service (via [Módulo SCEPman PowerShell](/pt/implementacao-do-scepman/permissions/post-installation-config.md#acquire-and-run-the-scepman-installation-powershell-module)): * SCEPman **2.2** ou superior * Módulo SCEPman PowerShell **1.6.3.0** ou superior * permissões de Administrador global {% endhint %} O seguinte comando do CMDlet irá clonar o seu SCEPman App Service e configurar todas as permissões necessárias: ``` New-SCEPmanClone -SourceAppServiceName -TargetAppServiceName -TargetAppServicePlan -SearchAllSubscriptions 6>&1 ``` * **Nome do App Service de origem:** O nome do SCEPman App Service existente. * **Nome do App Service de destino:** O nome do SCEPman App Service recém-clonado. * **Plano do App Service de destino:** O nome do App Service Plan para a instância SCEPman clonada. O App Service Plan já tem de existir no grupo de recursos de destino. * **Grupo de recursos de origem:** (Opcional) O grupo de recursos do Azure que aloja o SCEPman App Service existente. Deixe em branco para deteção automática. * **Grupo de recursos de destino:** (Opcional) O grupo de recursos do Azure que aloja o novo SCEPman App Service. Deixe em branco para detetar automaticamente o grupo de recursos do App Service Plan. * **ID da subscrição de origem:** (Opcional) O ID da subscrição onde o SCEPman está instalado. Pode ser omitido se já estiver pré-selecionado no az ou use o sinalizador SearchAllSubscriptions para pesquisar todas as subscrições acessíveis * **ID da subscrição de destino:** (Opcional) O ID da subscrição onde o SCEPman deve ser instalado. Pode ser omitido se for igual ao ID da subscrição de origem. * **Pesquisar em todas as subscrições:** (Opcional) Defina este sinalizador para pesquisar todas as subscrições pelo SCEPman App Service. Caso contrário, pré-selecione a subscrição correta no az ou passe o ID da subscrição correto. #### **Exemplo** Clonar um SCEPman App Service existente "app-scepman-contoso" ``` New-SCEPmanClone -SourceAppServiceName app-scepman-contoso -TargetAppServiceName app-scepman-clone -TargetAppServicePlan asp-scepman-geo2 -SearchAllSubscriptions 6>&1 ``` ![](/files/29b854740d0f79c2dc01a702cbf0c6e216c2cbb3) Depois de a implementação terminar com êxito, navegue até ao App Service clonado e verifique, na página inicial do SCEPman, se todas as permissões estão definidas corretamente e se tudo está verde e conectado (isto pode demorar até 3 minutos após a conclusão da implementação). ![](/files/2bb4bfb02abf9f50a02dbda50a49d3e96a4399ec) {% hint style="info" %} Para evitar um único ponto de falha, recomendamos definir [WEBSITE\_RUN\_FROM\_PACKAGE](/pt/configuracao-do-scepman/application-artifacts.md) 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 predefinição, o primeiro host de artefactos, que aponta para um repositório do GitHub. Para mais informações, consulte [Artefactos da aplicação](/pt/configuracao-do-scepman/application-artifacts.md). {% endhint %} {% hint style="warning" %} Clonar um App Service tem algumas restrições, tais como **escala automática** 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, as alterações às definições de um App Service não serão sincronizadas automaticamente para o segundo App Service se forem efetuadas após a operação de clonagem. Para mais informações, visite {% endhint %} {% endstep %} {% step %} ### 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 SCEPman: 1. Procure no Marketplace por **perfil do Traffic Manager** e clique em **Criar**. 2. Preencha os campos e escolha o seu grupo de recursos SCEPman\ ![](/files/13d31a879c75a77487b4ed191494c9b37ba128af) 3. Depois, clique em **Criar**. 4. Depois de o Traffic Manager ser implementado, abra-o e clique em **Configuração** 5. Altere as definições da seguinte forma e **guarde**
{% endstep %} {% step %} ### Adicionar Endpoints 1. Depois, em **Definições** escolha **Endpoints** 2. Escolha "Azure Endpoint" como **Tipo**, forneça um nome para o primeiro Endpoint e "App Service" como **tipo de recurso de destino** 3. Escolha o seu SCEPman App Service principal como o **recurso de destino**
4. Repita os mesmos passos para o segundo endpoint e escolha o segundo SCEPman App Service (clonado) como o **recurso de destino** {% endstep %} {% step %} ### Configuração de Domínio Personalizado Após uma implementação e configuração bem-sucedidas dos Endpoints do Traffic Manager, tem de configurar o **mesmo** domínio personalizado para **ambas as** instâncias SCEPman conforme descrito [aqui](/pt/configuracao-do-azure/custom-domain.md). Certifique-se de alterar o valor da definição **AppConfig:BaseUrl** para **ambas as** os SCEPman App Services depois de os domínios personalizados terem sido criados. {% endstep %} {% step %} ### Configuração de DNS Na **Visão geral** encontrará o nome DNS, que precisa de ser adicionado ao seu DNS ![Visão geral do Traffic Manager](/files/3defcf275bbc4332ee8e88dbbcc6e459ac5c09fd) * Navegue até ao seu serviço de gestão de DNS (por exemplo, **Zonas DNS do Azure**) * Remova quaisquer entradas CNAME erradas possivelmente existentes que apontem para uma das instâncias do Azure App Service e adicione um CNAME que mapeie o domínio personalizado SCEPman criado para o nome DNS do Traffic Manager. No exemplo abaixo, o CNAME deve apontar para **gk-blueprint-scepman.trafficmanager.net**. {% hint style="info" %} Em **Zona DNS do Azure**, para modificar um registo, primeiro tem de remover o bloqueio de DNS navegando até **Bloqueios**. {% endhint %} {% hint style="info" %} Ao concluir a configuração, certifique-se de atualizar o URL do servidor SCEP nos seus perfil(s) SCEP no Intune. O novo URL deve ser o domínio personalizado que criou, com "/certsrv/mscep/mscep.dll" no final. Exemplo: {% endhint %} {% endstep %} {% step %} ### Geo-Redundância da Storage Account A configuração predefinida do SCEPman usa Armazenamento Localmente Redundante (LRS), que utiliza apenas uma única região. Altere a redundância de Armazenamento Localmente Redundante (LRS) para Armazenamento Geo-redundante (GRS). ![Diálogo de redundância da Storage Account no Azure Portal](/files/5378420fc121adfbebc7f6f83db0bb0270278a45) {% endstep %} {% endstepper %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.scepman.com/pt/configuracao-do-azure/geo-redundancy.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.