> 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/de/azure-konfiguration/geo-redundancy.md). # Geo-Redundanz {% hint style="warning" %} Nur SCEPman Enterprise Edition {% endhint %} Diese Referenzarchitektur zeigt, wie Sie eine Azure App Service-Anwendung in mehreren Regionen ausführen, um Hochverfügbarkeit zu erreichen. {% hint style="info" %} Geo-Redundanz / Hochverfügbarkeit ist derzeit nur für den (Haupt-)SCEPman App Service verfügbar. Begründung: Die Benutzer von Certificate Master sind Administratoren mit in der Regel nicht zeitkritischen Zertifikats-Workloads und kennen die Verfahren zum Umgang mit solchen Szenarien. {% endhint %} ## Architektur ![](/files/481a88e8290f01bfafd1a3e58b8837a0aa8b38fe) Wie oben dargestellt, nutzt die geo-redundante Bereitstellung ein Azure Traffic Manager-Profil, das (DNS-basierte) Anforderungen an die SCEPman CA an ein Paar von SCEPman-Instanzen weiterleitet, die in unterschiedlichen Geolokationen bereitgestellt werden. Die einzelnen SCEPman-Instanzen kommunizieren mit demselben KeyVault, Storage Account und AAD und teilen somit dieselbe Root CA. Neben dem Lastenausgleich des Datenverkehrs auf Grundlage eines Satzes von Routing-Algorithmen, aus dem Sie wählen können, überprüft Traffic Manager außerdem ständig beide SCEPman-Instanzen. Falls eine Instanz nicht verfügbar wird, wird der gesamte Datenverkehr automatisch an die verfügbare Instanz weitergeleitet. Microsoft erläutert in [diesem Artikel](https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/app-service-web-app/multi-region) drei verschiedene Geo-Redundanz-Strategien, die zur Verwaltung dieses Architekturtyps verwendet werden können. In unserem Fall verwenden wir jedoch den **Active/Active** Ansatz. Das bedeutet, dass beide Regionen aktiv sind und Anforderungen zwischen ihnen per Lastenausgleich verteilt werden. Wenn eine Region aus irgendeinem Grund nicht verfügbar wird oder eine gewisse Latenz aufweist, leitet Traffic Manager den Datenverkehr an den zweiten App Service weiter. {% hint style="info" %} Sehen Sie sich unbedingt [Microsofts Liste der verfügbaren Regionen](https://learn.microsoft.com/en-us/azure/reliability/regions-list#azure-regions-list-1) und die jeweilige gepaarte Region an. Die Verwendung ungepaarter Regionen kann während der Einrichtung dieser Redundanz zu Problemen führen. {% endhint %} ## Ablauf 1. Klonen Sie den SCEPman App Service in eine andere Geolokation. 2. Konfigurieren Sie den Traffic Manager und verbinden Sie seine Endpoints mit beiden SCEPman App Services. 3. Konfigurieren Sie für beide App Services dieselbe benutzerdefinierte Domäne. 4. Konfigurieren Sie den DNS-CNAME-Eintrag, der Ihre benutzerdefinierte Domäne auf den Traffic Manager verweist. ## Schritte {% stepper %} {% step %} ### App klonen Um einen App Service zu klonen, müssen Sie zunächst einen neuen **App Service Plan** in einer zweiten Geolokation erstellen; dort wird die geklonte App bereitgestellt. Sie können ihn in derselben SCEPman-Ressourcengruppe oder in einer neuen erstellen. Siehe Screenshot unten: ![Erstellung eines neuen App Service Plan mit Windows](/files/be947148412708e5a42cf5e3c39092a53c313cc8) {% hint style="info" %} Anforderungen für das Klonen eines App Service (über [SCEPman PowerShell-Modul](/de/scepman-bereitstellung/permissions/post-installation-config.md#acquire-and-run-the-scepman-installation-powershell-module)): * SCEPman **2.2** oder höher * SCEPman PowerShell-Modul **1.6.3.0** oder höher * Global-Admin-Berechtigungen {% endhint %} Der folgende CMDlet-Befehl klont Ihren SCEPman App Service und konfiguriert alle erforderlichen Berechtigungen: ``` New-SCEPmanClone -SourceAppServiceName -TargetAppServiceName -TargetAppServicePlan -SearchAllSubscriptions 6>&1 ``` * **SourceAppServiceName:** Der Name des vorhandenen SCEPman App Service. * **TargetAppServiceName:** Der Name des neu geklonten SCEPman App Service. * **TargetAppServicePlan:** Der Name des App Service Plan für die geklonte SCEPman-Instanz. Der App Service Plan muss bereits in der TargetResourceGroup vorhanden sein. * **SourceResourceGroup:** (Optional) Die Azure-Ressourcengruppe, die den vorhandenen SCEPman App Service hostet. Für die automatische Erkennung leer lassen. * **TargetResourceGroup:** (Optional) Die Azure-Ressourcengruppe, die den neuen SCEPman App Service hostet. Leer lassen, um die Ressourcengruppe des App Service Plan automatisch zu erkennen. * **SourceSubscriptionId:** (Optional) Die ID des Abonnements, in dem SCEPman installiert ist. Kann weggelassen werden, wenn es bereits in az vorab ausgewählt ist, oder verwenden Sie das Flag SearchAllSubscriptions, um alle zugänglichen Abonnements zu durchsuchen * **TargetSubscriptionId:** (Optional) Die ID des Abonnements, in dem SCEPman installiert werden soll. Kann weggelassen werden, wenn sie mit SourceSubscriptionId identisch ist. * **SearchAllSubscriptions:** (Optional) Setzen Sie dieses Flag, um alle Abonnements nach dem SCEPman App Service zu durchsuchen. Andernfalls wählen Sie das richtige Abonnement in az vorab aus oder übergeben Sie die korrekte SubscriptionId. #### **Beispiel** Einen vorhandenen SCEPman App Service „app-scepman-contoso“ klonen ``` New-SCEPmanClone -SourceAppServiceName app-scepman-contoso -TargetAppServiceName app-scepman-clone -TargetAppServicePlan asp-scepman-geo2 -SearchAllSubscriptions 6>&1 ``` ![](/files/5fad9e76288f1b446f00c7cbae2121b2c13bc5d7) Nachdem die Bereitstellung erfolgreich abgeschlossen wurde, navigieren Sie zum geklonten App Service und prüfen Sie auf der SCEPman-Startseite, ob alle Berechtigungen korrekt gesetzt sind und alles grün und verbunden ist (dies kann bis zu 3 Minuten nach Abschluss der Bereitstellung dauern). ![](/files/4099571865b8ff329a5b20805ba436383d7d1e67) {% hint style="info" %} Um einen Single Point of Failure zu vermeiden, empfehlen wir, die [WEBSITE\_RUN\_FROM\_PACKAGE](/de/scepman-konfiguration/application-artifacts.md) des geklonten App Service auf den zweiten unabhängigen Artifact-Host auf Azure zu setzen. Produktionskanal: `https://install.scepman.com/dist/Artifacts.zip` Der ursprüngliche App Service sollte standardmäßig den ersten Artifact-Host haben, der auf ein GitHub-Repository verweist. Weitere Informationen finden Sie unter [Application Artifacts](/de/scepman-konfiguration/application-artifacts.md). {% endhint %} {% hint style="warning" %} Das Klonen eines App Service hat einige Einschränkungen, wie z. B. **Autoscaling** -Einstellungen, **Sicherungszeitplan** -Einstellungen, **App Insights**, usw. Konfigurationen, die nicht geklont werden können, müssen auf dem geklonten App Service manuell erneut konfiguriert werden. Außerdem werden Änderungen an den Einstellungen eines App Service nicht automatisch mit dem zweiten App Service synchronisiert, wenn sie nach dem Klonvorgang vorgenommen werden. Weitere Informationen finden Sie unter {% endhint %} {% endstep %} {% step %} ### Traffic Manager einrichten Befolgen Sie die folgenden Schritte, um den Traffic Manager zu erstellen und zu konfigurieren sowie den Datenverkehr zwischen beiden SCEPman-Instanzen auszugleichen: 1. Suchen Sie im Marketplace nach **Traffic Manager-Profil** und klicken Sie auf **Erstellen**. 2. Füllen Sie die Felder aus und wählen Sie Ihre SCEPman-Ressourcengruppe\ ![](/files/08cb2baa76cb0c27f0cb98dcc39b879d9b1466ac) 3. Klicken Sie dann auf **Erstellen**. 4. Nachdem Ihr Traffic Manager bereitgestellt wurde, öffnen Sie ihn und klicken Sie auf **Konfiguration** 5. Ändern Sie die Einstellungen wie folgt und **speichern**
{% endstep %} {% step %} ### Endpoints hinzufügen 1. Dann unter **Einstellungen** wählen Sie **Endpoints** 2. Wählen Sie „Azure Endpoint“ als **Typ**aus, geben Sie einen Namen für den ersten Endpoint an und „App Service“ als **Zielressourcentyp** 3. Wählen Sie Ihren primären SCEPman App Service als **Zielressource**
4. Wiederholen Sie dieselben Schritte für den zweiten Endpoint und wählen Sie den zweiten (geklonten) SCEPman App Service als **Zielressource** {% endstep %} {% step %} ### Konfiguration der benutzerdefinierten Domäne Nach erfolgreicher Bereitstellung und Konfiguration der Traffic Manager-Endpoints müssen Sie die **gleiche** benutzerdefinierte Domäne für **beide** SCEPman-Instanzen wie beschrieben einrichten [hier](/de/azure-konfiguration/custom-domain.md). Achten Sie darauf, den Wert der Einstellung **AppConfig:BaseUrl** für **beide** SCEPman App Services zu ändern, nachdem die benutzerdefinierten Domänen erstellt wurden. {% endstep %} {% step %} ### DNS-Konfiguration In der Traffic Manager **Übersicht,** finden Sie den DNS-Namen, der zu Ihrem DNS hinzugefügt werden muss ![Traffic Manager-Übersicht](/files/3ef66fce0a04f205a8a095b44bda2ea6a7e1e906) * Navigieren Sie zu Ihrem DNS-Verwaltungsdienst (z. B. **Azure DNS-Zonen**) * Entfernen Sie alle möglicherweise vorhandenen falschen CNAME-Einträge, die auf eine der Azure App Service-Instanzen verweisen, und fügen Sie einen CNAME hinzu, der die erstellte SCEPman-Benutzerdomäne auf den Traffic Manager-DNS-Namen abbildet. Im folgenden Beispiel sollte der CNAME auf **gk-blueprint-scepman.trafficmanager.net**. {% hint style="info" %} In **Azure DNS-Zone**müssen Sie, um einen Datensatz zu ändern, zunächst die DNS-Sperre entfernen, indem Sie zu **Sperren**. {% endhint %} {% hint style="info" %} Stellen Sie nach Abschluss der Konfiguration sicher, dass Sie die SCEP-Server-URL in Ihren SCEP-Profil(en) in Intune aktualisieren. Die neue URL sollte die benutzerdefinierte Domäne sein, die Sie erstellt haben, mit „/certsrv/mscep/mscep.dll“ am Ende. Beispiel: {% endhint %} {% endstep %} {% step %} ### Storage Account Geo-Redundanz Die standardmäßige SCEPman-Einrichtung verwendet Locally Redundant Storage (LRS), das nur eine einzelne Region nutzt. Ändern Sie die Redundanz von Locally Redundant Storage (LRS) zu Geo-redundant storage (GRS). ![Dialog zur Redundanz des Storage Account im Azure Portal](/files/56a5fc2aa1db5b4d09437fb5210425068ee54c81) {% 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/de/azure-konfiguration/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.