Infrastructure Sitecore dans plusieurs régions

Sitecore est capable de desservir le trafic de plusieurs régions à partir du fournisseur de cloud de votre choix. Pourquoi s’embêter cependant? C’est une bonne question car Sitecore dans plusieurs régions est plus complexe, plus cher à héberger et plus de travail à entretenir. Si votre organisation utilise Sitecore XP au maximum (bien qu’il y ait autres options aujourd’hui), vous ne pouvez pas mettre en cache HTML à la périphérie à l’aide d’un CDN. Même lorsque la mise en cache de sortie Sitecore est utilisée, chaque demande est toujours servie par un serveur de diffusion de contenu pour permettre la personnalisation et les tests multivariants. Si votre infrastructure ne se trouve que dans une seule région, de nombreux utilisateurs du site Web se retrouveront loin du serveur de diffusion de contenu Sitecore, ce qui ralentira l’expérience globale.

Comment configurer plusieurs régions pour Sitecore dans Azure ?

Que signifie configurer Sitecore dans plusieurs régions ? Configurez la région principale de manière standard pour Sitecore XP : un service et une instance d’application de gestion de contenu unique, un service d’application de diffusion de contenu avec le nombre d’instances qui ont un sens pour votre trafic, puis xConnect et les services d’application associés. Bien sûr, Kubernetes peut être utilisé à la place des services d’application mais le point reste le même – dans la région principale, peu de choses seront différentes d’une configuration Sitecore standard.

Seuls les serveurs de diffusion de contenu et leurs dépendances sont nécessaires dans les clusters secondaires ou « clusters de diffusion de contenu uniquement ». xConnect est une dépendance de l’exécution de XP complet. Décidez si vous souhaitez configurer xConnect dans chaque région ou vous fier au service xConnect de la région principale. Un seul xConnect dans la région primaire entraînera une légère latence lors de la première demande. Les autres dépendances incluent SQL, Solr et Redis pour chaque cluster de diffusion de contenu. Ces services de support doivent être configurés dans la même région que vos serveurs de diffusion de contenu pour optimiser la vitesse. Envisagez également de configurer un indexeur séparé dans les régions réservées aux CD afin que les CD qui servent le trafic n’aient pas besoin d’effectuer d’opérations d’indexation.

Infrastructure Sitecore pour plusieurs régions dans Azure

Défis

Le plus grand défi de la mise en place de clusters régionaux de diffusion de contenu sera la base de données Web où vit le contenu publié. Il existe 3 configurations viables, chacune avec son propre ensemble unique d’avantages et d’inconvénients.

1. Réplication de base de données – dans cette configuration, il existe une seule configuration de cible de publication dans la région principale. La base de données Web sera ensuite répliquée dans toutes les régions. Cette configuration évite les pièges de la publication dans plusieurs régions, mais traite les événements de publication par rapport à un réplique en lecture seule est difficile et vient avec ses propres complexités de configuration. Pendant les déploiements, veillez à ne pas publier les modifications qui interrompent les fonctionnalités dans les régions où les derniers artefacts de déploiement ne sont pas déployés.
2. Cibles de publication distinctes – dans cette configuration, il existe une cible distincte pour chaque région. Étant donné que la base de données n’est pas répliquée, le traitement des événements peut se produire sur la base de données comme d’habitude. La publication entre les régions est incroyablement lente, alors pensez à utiliser le service de publication de Sitecore. Cette configuration permet également de publier différents contenus dans différentes régions s’il existe une exigence commerciale pour un contenu variable.
3. Une troisième option consisterait à utiliser une combinaison de tactiques. Utilisez des cibles de publication distinctes, mais ces bases de données résideraient dans la région principale SQL Server. Ensuite, ces bases de données seraient répliquées dans vos autres régions. Cette approche permet de séparer le contenu par région tout en conservant une publication rapide. Le principal inconvénient est la complexité de l’approche.

Des avantages supplémentaires

Les performances sont un gros avantage pour la configuration de Sitecore dans plusieurs régions. Cette approche présente d’autres avantages qui peuvent vous inciter à envisager sérieusement cette configuration.

1. Reprise après sinistre – Bien qu’il ne s’agisse pas d’un plan complet de reprise après sinistre, la desserte du trafic provenant de plusieurs régions dans une configuration active/active peut servir de reprise après sinistre. Si une région tombe en panne, les utilisateurs finaux ne seront pas affectés. Les autres régions continueront à desservir le trafic. Servir à partir de plusieurs régions atténue une grande partie du risque d’indisponibilité associé à une panne. Des plans de reprise après sinistre complets sont toujours nécessaires dans le cas où CM est en panne ou si une région est hors ligne pendant une période prolongée.
2. Déploiement bleu/vert – Azure prend en charge le bleu/vert de manière native via des emplacements de déploiement. Lorsque vous servez depuis plusieurs régions, les emplacements de déploiement ne sont pas nécessaires. Pour obtenir de la colle / du vert, désactivez complètement la région en cours de déploiement dans Porte d’entrée. Les utilisateurs finaux continuent d’être desservis par les autres régions. Les utilisateurs internes et les testeurs peuvent accéder à la région qui possède le dernier code via une URL interne. Cela permet des tests prolongés si nécessaire.

La configuration de Sitecore dans plusieurs régions présente d’énormes avantages et n’est pas trop difficile à réaliser. Du point de vue de l’infrastructure, c’est quelque chose à considérer pour augmenter les performances et la résilience de votre site. L’avenir commence à ressembler à la personnalisation et les tests multivariants seront poussés côté client. Dans ce modèle, HTML sera mis en cache à la périphérie. Toutefois, si le frontal appelle les API Sitecore sur le serveur de CD, envisagez Sitecore dans plusieurs régions pour que le temps de réponse de l’API soit le plus court possible.