Les applications d'aujourd'hui sont hautement transactionnelles et peuvent évoluer pour des transactions élevées en s'exécutant dans un déploiement multiserveur à charge équilibrée. Dans le même temps, bon nombre de ces applications doivent s'exécuter dans plusieurs centres de données. Cela pourrait être fait pour la reprise après sinistre, où un centre de données actif dispose d'une reprise après sinistre en tant que centre de données passif qui se trouve généralement dans un emplacement géographique différent. Une autre raison est que si les utilisateurs de cette application sont répartis géographiquement, ils obtiendront des temps de réponse plus rapides car ils accèdent simultanément à leur propre centre de données dans leur région.
NCache Détails Pont pour la réplication WAN NCache Docs
Le cache nécessite une réplication WAN, tout comme la base de données
Lorsque vous avez des applications exécutées dans plusieurs centres de données, le cache doit être répliqué. En effet, le cache conserve les données transitoires et, si jamais le cache tombe en panne, les données sont perdues. Les données transitoires peuvent être des sessions ASP.NET, des données arbitraires générées par votre application ou des données agrégées. Cependant, les données temporaires ne sont pas permanentes, elles ne sont donc jamais stockées dans la base de données, elles sont uniquement mises en cache.
Les autres données NCache conserve pour des raisons de performances les données de l'application. Si vous perdez ces données, elles se rechargent à partir de la base de données, ce qui nuit aux performances. De nombreuses entreprises ne veulent pas s'en occuper en raison du trafic élevé des applications. C'est pourquoi même les données d'application doivent être répliquées sur le WAN si vous avez un déploiement multi-centre de données.
NCache Détails Réplication WAN NCache Docs
Solution: NCache Réplication WAN via Bridge
Pour faire face à la situation ci-dessus, NCache fournit une fonction de réplication WAN via un pont. Cela vous permet de déployer NCache sur plusieurs centres de données dans des configurations actif-passif, actif-actif, 3+ centres de données actif-actif.
2 sites actif-passif
Dans une configuration active-passive, NCache est déployé sur les sites actifs et passifs, créant une topologie de pont sur le site actif. La figure 1 montre comment cela est disposé dans une configuration active-passive. Toutes les mises à jour d'application sont envoyées du cache du site actif au pont, qui les envoie de manière asynchrone au site passif en quelques millisecondes. Le seul retard ici est la latence entre les centres de données s'ils sont éloignés. Ainsi, une topologie de pont avec un mécanisme de mise en file d'attente asynchrone permet à toutes ces mises à jour de se produire sans rien déborder.
NCache Détails Modes de synchronisation du cache NCache Docs
2 sites actif-actif
Une autre configuration qui NCache supports est actif-actif, où les deux sites sont actifs. L'un contient la topologie du cache et du pont, et l'autre contient uniquement le cache. La figure 2 montre comment cela est fait. Semblable à actif-passif, en actif-actif, un cache envoie ses mises à jour au pont, qui à son tour les envoie à d'autres caches. Cependant, il y a maintenant une différence. Des conflits peuvent survenir lorsque le même élément est mis à jour des deux côtés en même temps. Cela signifie que le pont doit coordonner les mises à jour des deux sites et résoudre les conflits de manière asynchrone pour éviter d'avoir un impact négatif sur les performances du cache sur chaque site actif.
NCache Détails Réplication WAN multi-centres de données NCache Docs
3+ Site Actif-Actif
Dans la troisième situation, il y a 3 centres de données actifs ou plus. Ici, l'un des sites actifs a un cache et un pont, tous les autres sites n'ont que du cache. Autrement dit, le pont est local sur l'un des sites, mais les deux autres sites accèdent au pont à distance. Semblable au scénario actif-actif, dans ce scénario 3+ actif-actif, tous les caches envoient des mises à jour au pont, et le pont propage les mises à jour à tous les caches connectés. En même temps, il effectue la résolution des conflits pour s'assurer que les mêmes données mises à jour à partir du cache ne provoquent pas de violations de l'intégrité des données.
NCache Détails Topologie de pont NCache Docs
La figure 3 montre trois centres de données actifs-actifs. NCache permet une réplication de cache très transparente et asynchrone. Aucun changement de code d'application. Les applications ne savent même pas que le cache est répliqué, mais il est répliqué de manière asynchrone sur le WAN du centre de données.
Réplication WAN parallèle et asynchrone en masse
Toutes les mises à jour du cache sont asynchrones. La raison pour laquelle ils sont asynchrones est la distance entre plusieurs centres de données. Cette distance peut entraîner de mauvaises performances en raison de la latence. Les temps d'accès entre les serveurs sont très rapides lorsque les applications sont mises en cache dans le même centre de données. Mais sur un WAN, c'est généralement très lent. Ainsi, si vous n'effectuez pas de mises à jour asynchrones, la personne qui fait la demande de mise à jour doit attendre que la mise à jour soit terminée - mises à jour synchrones, ce qui ralentit votre application.
Cependant, la réplication asynchrone signifie que les applications et les caches de chaque site n'attendent pas que leurs données soient répliquées vers d'autres centres de données. Les données sont mises en file d'attente au pont. Le pont lui-même est un cluster à deux nœuds, mettant en file d'attente toutes les demandes de mise à jour de tous les caches. Pour l'actif-passif, les requêtes sont en file d'attente uniquement à partir du cache actif et appliqué de manière asynchrone au cache passif. Si vous avez trois centres de données ou plus, le pont applique les mises à jour à plusieurs sites actifs en parallèle.
De plus, le pont effectue des mises à jour en masse. Cela signifie que vous pouvez combiner plusieurs éléments de données en une seule requête et les envoyer à d'autres sites en une seule requête groupée, ce qui réduit considérablement les déplacements sur le réseau. Cette puissante combinaison de réplication parallèle, en bloc et asynchrone améliore donc les performances tout en répliquant les caches sur plusieurs centres de données.
NCache Détails Topologie de réplication WAN NCache Docs
Résolution de conflit
Si vous avez plusieurs sites actifs, chacun de ces sites peut mettre à jour les mêmes données en même temps. Assurez-vous que votre ordinateur local est synchronisé avec le fuseau horaire local. Bien sûr, il n'y a pas de problème s'il n'est pas mis à jour en même temps. Supposons que vous mettiez à jour l'élément 1 au temps T1 et que vous mettiez à jour l'élément 2 au temps T2. La mise à jour à l'instant T2 est la dernière mise à jour appliquée. Cependant, si les deux mises à jour se produisent en même temps, le pont doit résoudre le conflit de deux manières.
-
Logique par défaut "La dernière mise à jour gagne" : Le pont récupère automatiquement l'horodatage de chaque cache, et tous les caches ont leurs horloges synchronisées afin qu'ils aient la même heure. Le pont reçoit les heures de mise à jour de chaque cache et les dernières mises à jour sont appliquées à tous les caches. Encore une fois, le but de la résolution des conflits est d'appliquer la même mise à jour de version à tous les caches pour éviter les problèmes d'intégrité des données.
-
Gestionnaire de résolution de conflits : Une autre façon pour le pont de résoudre les conflits est qu'il peut fournir un gestionnaire de résolution de conflits selon sa logique d'analyse des mises à jour. Étant donné que ce résolveur est configuré avec NCache, le pont fournira les deux copies de l'objet et le résolveur analysera quelle version est la meilleure selon la logique fournie. Cela renverra la version finale au pont et appliquera cette mise à jour à tous les caches.
L'extrait de code suivant vous donne un exemple de l'implémentation du résolveur de conflits qui est déployée sur le cache :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
public class Resolver : IBridgeConflictResolver { public void Init(System.Collections.IDictionary parameters) {. . .} public ConflictResolution Resolve(ProviderBridgeItem oldEntry, ProviderBridgeItem newEntry) { var conflictResolution = new ConflictResolution(); switch (oldEntry.BridgeItemVersion) { case BridgeItemVersion.OLD: { /* Replace item with new entry */ } break; case BridgeItemVersion.LATEST: { /* Keep old entry */ } break; case BridgeItemVersion.SAME: { /* Your logic to replace entry if needed */ } break; } return conflictResolution; // Configure this implementation on cache } public void Dispose() {. . .} } |
Ainsi, en disposant d'un mécanisme de résolution des conflits dans NCache, vous êtes assuré que votre cache ne sera jamais désynchronisé. Il n'aura jamais deux versions différentes des mises à jour des données et sera toujours cohérent sur plusieurs centres de données.
NCache Détails Configurer le pont Configurer le résolveur de conflits
Gestion des sinistres lors de l'exécution
Parlons maintenant de ce qui se passe en cas de catastrophe où un site tombe en panne.
Actif Passif
Cas 1 : Le site passif tombe en panne
Une configuration active-passive agit comme un site de reprise après sinistre. Ainsi, si le côté passif tombe en panne, le côté actif fonctionnera toujours et votre application continuera à s'exécuter. Le pont ne peut pas répliquer les données sur le site passif tant que vous n'intervenez pas pour restaurer le site passif. Lorsque vous rétablissez le site passif, il se reconnecte au pont et se resynchronise, supprimant ainsi le cache existant et obtenant effectivement une copie complète du cache du site actif sur le pont. Une fois la synchronisation terminée, il passe en mode de réplication WAN normal.
NCache Détails Caches de pont de synchronisation Cache actif-passif
Cas 2 : Le site actif tombe en panne
Si le site actif tombe en panne, cela signifie que vous avez une sorte de catastrophe, car le pont est en panne et l'application est probablement en panne. Vous devez envoyer tout le trafic maintenant vers le emplacement passif qui devient maintenant actif. Toutes les données sont répliquées du site actif d'origine vers le site passif d'origine, sans interruption pour les utilisateurs. Le site passif d'origine est maintenant actif, donc toutes les mises à jour se produisent ici, mais les utilisateurs ne voient aucune interruption.
Cependant, une fois que le site actif d'origine est à nouveau opérationnel, il se connecte au nouveau site actif (le site passif d'origine) et synchronise lui-même complètement. Une fois la synchronisation effectuée, les deux sont actifs-actifs même si tout le trafic est dirigé vers le site passif d'origine. Vous avez la possibilité de décharger tout le trafic vers le site actif d'origine et de redéfinir l'état du site actif-actif sur passif sur le pont. NCache vous permet de faire tout cela au moment de l'exécution sans aucune interruption en cas de sinistre actif-passif.
Actif-Actif
Lorsque le site actif avec le pont tombe en panne, la réplication WAN s'arrête car le pont est en panne. Cependant, d'autres sites actifs continueront de fonctionner et tout le trafic leur sera acheminé. Une fois que vous avez mis le site en panne, vous pouvez démarrer le pont et connecter le site actif au pont, de sorte que les deux sites soient synchronisés. Tout cela est fait au moment de l'exécution, donc aucun temps d'arrêt n'est requis. Une fois les ponts synchronisés, les deux sites pourront se transmettre mutuellement des mises à jour. NCache offre ainsi une tolérance aux pannes.
NCache Détails Modes de synchronisation du cache NCache Docs
3+ sites actifs
La troisième situation est lorsque vous avez 3 sites actifs ou plus où un site a le pont et les autres pas. Deux scénarios peuvent avoir lieu dans ce cas comme mentionné.
Cas 1 : Le site actif sans pont tombe en panne
Dans ce cas, les autres sites continueront à se répliquer, et le trafic de ce site est redirigé vers les autres sites connectés sans perturber les utilisateurs. Une fois que le site est opérationnel, il se reconnecte au pont et se resynchronise pour obtenir la dernière copie du cache. C'est le signal pour remettre le trafic sur les rails.
NCache Détails Modifier les modes de synchronisation du cache Topologie de pont
Cas 2 : Le site actif avec le pont tombe en panne
Dans le cas où le pont tombe en panne, les deux autres sites actifs continuent de fonctionner, mais ils ne sont pas en mesure de répliquer leurs mises à jour l'un sur l'autre car il n'y a pas de pont. Donc, ce que vous pouvez faire à ce moment-là, c'est démarrer un pont dans l'un des deux autres sites actifs.
Pour démarrer le pont, vous avez besoin de deux nœuds en tant que grappe. Idéalement, vous devriez disposer d'un ensemble de serveurs dédiés pour topologie de pont sur ce site, mais vous pouvez également utiliser deux serveurs de cache en tant que cluster car il est très probablement temporaire. Cependant, cela peut avoir un impact sur les performances de ces serveurs de cache, car le pont consomme désormais également des ressources telles que le processeur et la mémoire.
Vous devez commencer le pont sur l'un des sites actifs où les deux sites actifs sont déjà en cours d'exécution. Le cache en cours d'exécution peut maintenant se connecter à un pont. Ainsi, ils se connectent tous les deux à un pont et se synchronisent en répliquant toutes les mises à jour les uns avec les autres. Les utilisateurs ne subissent aucune interruption car les deux sites sont synchronisés et propagent les mises à jour l'un avec l'autre. Par conséquent, si un site tombe en panne, vous ne perdez aucune donnée.
NCache Détails Ajouter des caches en cluster Gestion des ponts
Maintenant, une fois que le site d'origine avec le pont revient, vous pouvez simplement :
- Descendez le pont sur le site temporaire.
- Retirer le pont du cache existant.
- Amenez le pont sur le site d'origine.
- Connectez toutes les caches à ce nouveau pont.
Comme vous pouvez connecter le cache au pont lors de l'exécution, NCache vous permet d'automatiser tout ce travail grâce à des scripts afin que vous puissiez gérer de manière transparente la situation où un site de pont tombe en panne et vous devez le réactiver.
Conclusion
NCache vous offre un puissant mécanisme de réplication WAN qui vous permet de gérer de nombreux scénarios avancés différents. De plus, il effectue la réplication WAN de manière rapide et efficace et gère les centres de données actif-passif, actif-actif ou trois centres de données actifs-actifs ou plus.