> 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/es/configuracion-de-azure/geo-redundancy.md).

# Geo-redundancia

{% hint style="warning" %}
Solo para SCEPman Enterprise Edition
{% endhint %}

Esta arquitectura de referencia muestra cómo ejecutar una aplicación de Azure App Service en varias regiones para lograr alta disponibilidad.

{% hint style="info" %}
La redundancia geográfica / alta disponibilidad está actualmente disponible solo para el App Service principal de SCEPman. Motivo: los usuarios de Certificate Master son administradores con cargas de trabajo de certificados que normalmente no son críticas en cuanto al tiempo y con conocimiento de los procedimientos para manejar estos escenarios.
{% endhint %}

## Arquitectura

![](/files/ccdaa533cb542a37d491d97ba5c599dc93a8b750)

Como se ilustra arriba, la implementación con redundancia geográfica aprovecha un perfil de Azure Traffic Manager, que enruta las solicitudes (basadas en DNS) a la CA de SCEPman hacia un par de instancias de SCEPman desplegadas en distintas geolocalizaciones. Las instancias individuales de SCEPman se comunican con el mismo KeyVault, Storage Account y AAD, y por lo tanto comparten la misma CA raíz. Además de equilibrar la carga del tráfico basándose en un conjunto de algoritmos de enrutamiento entre los que puedes elegir, Traffic Manager también sondea constantemente ambas instancias de SCEPman. En caso de que una instancia deje de estar disponible, todo el tráfico se dirigirá automáticamente a la instancia disponible.

Microsoft analiza en [este artículo](https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/app-service-web-app/multi-region) tres estrategias diferentes de redundancia geográfica que pueden usarse para gestionar este tipo de arquitectura. Sin embargo, en nuestro caso, usaremos el **Active/Active** enfoque Active/Active. Esto significa que ambas regiones están activas y que las solicitudes se equilibran entre ellas. Si una región deja de estar disponible o tiene cierta latencia por cualquier motivo, Traffic Manager dirigirá el tráfico al segundo App Service.

{% hint style="info" %}
Asegúrate de echar un vistazo a [la lista de regiones disponibles de Microsoft](https://learn.microsoft.com/en-us/azure/reliability/regions-list#azure-regions-list-1) y su correspondiente región emparejada. El uso de regiones no emparejadas puede provocar problemas durante la configuración de esta redundancia.
{% endhint %}

## Flujo de trabajo

1. Clona el SCEPman App Service en otra geolocalización.
2. Configura Traffic Manager y conecta sus endpoints a ambos App Services de SCEPman.
3. Configura el mismo dominio personalizado para ambos App Services.
4. Configura el registro CNAME de DNS, apuntando tu dominio personalizado a Traffic Manager.

## Pasos

{% stepper %}
{% step %}

### Clonar aplicación

Para clonar un App Service, primero debes crear un nuevo **plan de App Service** en una segunda geolocalización; allí se implementará la aplicación clonada. Puedes crearlo en el mismo grupo de recursos de SCEPman o en uno nuevo. Consulta la captura de pantalla siguiente:

![Creación de un nuevo plan de App Service con Windows](/files/912162817986db127edba3489f3897c69bc74969)

{% hint style="info" %}
Requisitos para clonar App Service (mediante [módulo PowerShell de SCEPman](/es/despliegue-de-scepman/permissions/post-installation-config.md#acquire-and-run-the-scepman-installation-powershell-module)):

* SCEPman **2.2** o superior
* módulo PowerShell de SCEPman **1.6.3.0** o superior
* permisos de administrador global
  {% endhint %}

El siguiente comando CMDlet clonará tu App Service de SCEPman y configurará todos los permisos necesarios:

```
New-SCEPmanClone -SourceAppServiceName <Your SCEPman App Service Name> -TargetAppServiceName <Your cloned App Service Name> -TargetAppServicePlan <Your second App Service Plan in the second Geo Location> -SearchAllSubscriptions 6>&1
```

* **SourceAppServiceName:** El nombre del SCEPman App Service existente.
* **TargetAppServiceName:** El nombre del nuevo SCEPman App Service clonado.
* **TargetAppServicePlan:** El nombre del plan de App Service para la instancia clonada de SCEPman. El plan de App Service debe existir ya en TargetResourceGroup.
* **SourceResourceGroup:** (Opcional) El grupo de recursos de Azure que hospeda el SCEPman App Service existente. Déjalo vacío para la autodetección.
* **TargetResourceGroup:** (Opcional) El grupo de recursos de Azure que hospeda el nuevo SCEPman App Service. Déjalo vacío para detectar automáticamente el grupo de recursos del plan de App Service.
* **SourceSubscriptionId:** (Opcional) El ID de la suscripción donde está instalado SCEPman. Se puede omitir si ya está preseleccionada en az, o usa el indicador SearchAllSubscriptions para buscar en todas las suscripciones accesibles
* **TargetSubscriptionId:** (Opcional) El ID de la suscripción donde se instalará SCEPman. Se puede omitir si es el mismo que SourceSubscriptionId.
* **SearchAllSubscriptions:** (Opcional) Establece este indicador para buscar el SCEPman App Service en todas las suscripciones. De lo contrario, preselecciona la suscripción correcta en az o pasa el SubscriptionId correcto.

#### **Ejemplo**

Clona un 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/46bb851004f55b40dc8cbfa4380d980b83c0bad1)

Después de que la implementación haya finalizado correctamente, ve al App Service clonado y comprueba en la página principal de SCEPman que todos los permisos estén configurados correctamente y que todo esté en verde y conectado (esto puede tardar hasta 3 minutos después de que la implementación haya terminado).

![](/files/e436c42a10cb4dc4b7067dd94c4e24a29619351d)

{% hint style="info" %}
Para evitar un único punto de fallo, recomendamos configurar [WEBSITE\_RUN\_FROM\_PACKAGE](/es/configuracion-de-scepman/application-artifacts.md) de la aplicación clonada en el segundo host de artefactos independiente en Azure.

Canal de producción:

`https://install.scepman.com/dist/Artifacts.zip`

El App Service original debería tener por defecto el primer host de artefactos, que apunta a un repositorio de GitHub. Para más información, consulta [Artefactos de la aplicación](/es/configuracion-de-scepman/application-artifacts.md).
{% endhint %}

{% hint style="warning" %}
Clonar un App Service tiene algunas restricciones, como **escalado automático** configuración, **programación de copia de seguridad** configuración, **App Insights**, etc. Las configuraciones que no pueden clonarse deben volver a configurarse manualmente en el App Service clonado. Además, los cambios en la configuración de un AppService no se sincronizarán automáticamente con el segundo App Service si se realizan después de la operación de clonación. Para más información, visita <https://docs.microsoft.com/en-us/azure/app-service/app-service-web-app-cloning#current-restrictions>
{% endhint %}

{% endstep %}

{% step %}

### Configurar Traffic Manager

Sigue los pasos siguientes para crear y configurar Traffic Manager y equilibrar el tráfico entre ambas instancias de SCEPman:

1. Busca en Marketplace **perfil de Traffic Manager** y haz clic en **Crear**.
2. Rellena los campos y elige tu grupo de recursos de SCEPman\
   ![](/files/de6369fa83e25499050bf8897d69620cb96a1c33)
3. Luego haz clic en **Crear**.
4. Después de desplegar Traffic Manager, ábrelo y haz clic en **Configuración**
5. Cambia la configuración de la siguiente manera y **guarda**<br>

   <figure><img src="/files/cb5693b22c1e4ff29c28adda194afbafbc60f236" alt=""><figcaption></figcaption></figure>

{% endstep %}

{% step %}

### Añadir endpoints

1. Luego, en **Configuración** elige **endpoints**
2. Elige "Azure Endpoint" como **Tipo**, proporciona un nombre para el primer endpoint y "App Service" como **tipo de recurso de destino**
3. Elige tu SCEPman App Service principal como el **recurso de destino**<br>

   <figure><img src="/files/a5d29fd461f6e4279438564bf6b8a1f80254f443" alt=""><figcaption></figcaption></figure>
4. Repite los mismos pasos para el segundo endpoint y elige el segundo SCEPman App Service (clonado) como el **recurso de destino**
   {% endstep %}

{% step %}

### Configuración de dominio personalizado

Después de una implementación y configuración correctas de los endpoints de Traffic Manager, debes configurar el **mismo** dominio personalizado para **ambos** instancias de SCEPman, como se describe [aquí](/es/configuracion-de-azure/custom-domain.md).

Asegúrate de cambiar el valor de la configuración **AppConfig:BaseUrl** para **ambos** los App Services de SCEPman después de que se hayan creado los dominios personalizados.

{% endstep %}

{% step %}

### Configuración de DNS

En Traffic Manager **Información general,** encontrarás el nombre DNS que debe añadirse a tu DNS

![Información general de Traffic Manager](/files/0819113ae6f28c22c3e50f3f2b7ced6ee78d80ba)

* Navega a tu servicio de administración de DNS (p. ej., **Azure DNS Zones**)
* Elimina cualquier entrada CNAME incorrecta que pueda existir y que apunte a una de las instancias de Azure App Service, y agrega un CNAME que asigne el dominio personalizado de SCEPman creado al nombre DNS de Traffic Manager. En el ejemplo siguiente, el CNAME debería apuntar a **gk-blueprint-scepman.trafficmanager.net**.

{% hint style="info" %}
En **Azure DNS Zone**, para modificar un registro, primero tienes que quitar el bloqueo de DNS yendo a **Bloqueos**.
{% endhint %}

{% hint style="info" %}
Una vez completada la configuración, asegúrate de actualizar la URL del servidor SCEP en tus perfiles SCEP en Intune. La nueva URL debe ser el dominio personalizado que has creado, con "/certsrv/mscep/mscep.dll" al final.

Ejemplo: <https://scepman.contoso.com/certsrv/mscep/mscep.dll>
{% endhint %}

{% endstep %}

{% step %}

### Redundancia geográfica de Storage Account

La configuración predeterminada de SCEPman usa el almacenamiento con redundancia local (LRS), que utiliza solo una única región.&#x20;

Cambia la redundancia de almacenamiento con redundancia local (LRS) a almacenamiento con redundancia geográfica (GRS).

![Diálogo de redundancia de Storage Account en Azure Portal](/files/457a6158da0885a6cb8d3d2c61d106aa8ec7e975)

{% 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/es/configuracion-de-azure/geo-redundancy.md?ask=<question>&goal=<endgoal>
```

`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.
