Pont pour la géo-réplication
Pour les applications à grande échelle, les caches distribués sont utilisés pour améliorer les performances, la fiabilité et l'évolutivité d'exécution de vos applications. Ainsi, les caches distribués peuvent constituer une partie très importante de votre plan de reprise après sinistre, qu'il s'agisse d'une catastrophe naturelle, d'une catastrophe matérielle interne ou d'une panne logicielle.
Le plan de reprise après sinistre le meilleur et le plus utilisé est la réplication en direct des données vers d’autres sites de sauvegarde. Ainsi, en cas de besoin, vous pouvez rediriger vos utilisateurs en direct vers votre site de sauvegarde sans aucune erreur. Cependant, cela nécessite de s'assurer que vos caches actif et de sauvegarde sont tous deux synchronisés à tout moment. S'ils ne sont pas synchronisés, cela peut affecter les clients de cache de vos applications.
NCache vous offre une réplication WAN via la fonctionnalité de pont. Un pont est créé entre plusieurs caches de cluster et les données sont répliquées de la source vers l'autre site via ce pont.
Si vous disposez non seulement de plans de reprise après sinistre, mais souhaitez également déployer votre application dans des régions géographiquement séparées pour des clients largement répartis, la réplication des données résout également le problème pour vous. Ici, vous pouvez avoir deux sites actifs ou plus, qui traiteront avec les utilisateurs des régions associées et pourront également être utilisés comme sauvegarde des sites d'autres régions.
La réplication des données à distance est un élément essentiel de tout plan visant à garantir une protection efficace et efficiente des données et une récupération rapide après une interruption majeure. La réplication synchrone des données est bénéfique pour le cluster en interne, mais son impact sur les performances devient un facteur important lorsque les clusters de caches sont géographiquement séparés. Le pont est conçu pour les scénarios qui impliquent la réplication de données depuis un ou plusieurs caches sur site vers d'autres caches sur site/hors site à travers le WAN pour la reprise après sinistre. En raison de la réplication asynchrone, tous les clients connectés au(x) cache(s) actif(s) ont l'impression que les opérations sont effectuées sur le cache actif tandis qu'une sauvegarde complète est effectuée de manière transparente vers le(s) autre(s) cache(s).
Lorsqu'une opération est effectuée sur le cache source, elle est transmise de manière asynchrone au pont. Cette opération est ensuite mise en file d'attente dans une file d'attente maintenue par le pont. Les opérations de la file d'attente sont transférées vers le cache cible lorsque le pont trouve le cache cible disponible et prêt à accepter les opérations. Avec le pont, on s'assure que :
- Il n'y a pas de dégradation des performances.
- Les opérations sont effectuées dans le même ordre que sur le cache d'origine.
- Les opérations ne sont pas perdues en cas d'échec de connexion.
Architecture de mise en cache enfichable : Les caches ne se connaissent pas ; ils connaissent simplement le pont et répliquent leurs données sur le pont. Grâce à ce couplage lâche, vous pouvez configurer un pont entre plusieurs caches, quelle que soit leur topologie de cache. Vous pouvez librement supprimer les caches configurés avec un pont.
Intégrité des données: Les opérations effectuées au niveau du cache source sont mises en file d'attente par le pont en conservant l'ordre réel dans lequel elles ont été effectuées au niveau du cache source. Le pont effectue des opérations sur le cache cible dans le même ordre. Les conflits sont résolus sur le cache cible. De cette façon, les caches finissent par devenir cohérents.
Service de pont dédié : Le pont est également un service autonome et dédié comme le service de cache, de sorte que vos opérations de cache ne seront pas affectées si les opérations du pont sont retardées en raison de la latence du réseau.
Configuration du pont : Vous pouvez configurer votre pont sur le même serveur où réside votre cache de cluster ou vous pouvez le créer sur le nœud de serveur distinct. Ensuite, vous pouvez ajouter n'importe lequel de vos caches de cluster dans le pont et les données seront répliquées entre eux.
Reprise après sinistre: Vous pouvez configurer un pont entre un centre de données actif et passif pour la reprise après sinistre.
Client géographiquement dispersé : Vous pouvez avoir deux sites actifs ou plus qui traitent avec les utilisateurs des régions associées et peuvent également être utilisés comme sauvegarde des sites d'autres régions.
Réplication asynchrone : Pour la réplication WAN, la réplication asynchrone est utilisée afin que les opérations de cache ne souffrent pas en cas de retards dans les opérations de pont.
Sauvegarde de la file d'attente : Le pont est une file d'attente en cluster multi-nœuds dans laquelle un nœud est actif et l'autre passif, disposant d'une sauvegarde de la file d'attente active pour éviter la perte de données sur le pont.
Nouvelles tentatives de connexion : Le pont tente également de répliquer toutes les opérations en réessayant lorsqu'un échec de connexion se produit.
File d'attente du réplicateur de pont : La taille de la file d'attente du réplicateur de pont est incluse dans la taille du cache. Si le cache ne parvient pas à se connecter au pont, les opérations seront mises en file d'attente sur le cache jusqu'à ce que le cache soit plein. Si le cache est plein, les éléments du cache seront expulsés afin de libérer de l'espace pour augmenter la file d'attente du pont.
caches: Vous pouvez utiliser n'importe quelle topologie pour les caches de cluster qui feront partie du pont. Vous pouvez également utiliser différents caches de topologie sur chaque site dans un seul pont. Cependant, il est fortement recommandé d’utiliser la même topologie des deux côtés.
Modes de synchronisation du cache pour la géoréplication
Les NCache bridge peut avoir plusieurs caches connectés, et vous pouvez fournir l'un des modes de synchronisation suivants au cache pour la reprise après sinistre :
Cache actif :
Un cache actif peut être de n'importe quelle topologie, où tous les clients se connectent et effectuent des opérations de lecture et d'écriture qui sont répliquées via un pont vers les autres caches connectés.Cache passif :
Un cache passif peut avoir n'importe quelle topologie, mais il est recommandé qu'il soit identique à un cache actif. Cependant, toutes les opérations effectuées sur le cache actif sont répliquées vers le cache passif. Les clients peuvent se connecter au cache passif et effectuer des opérations de lecture et d'écriture, mais ces opérations ne sont pas répliquées sur le cache actif. Des modifications peuvent être effectuées au niveau du cache passif si nécessaire.Si le site actif tombe en panne pour une raison quelconque, vous pouvez rediriger vos demandes vers votre site passif en le rendant actif. Votre site passif se comportera comme actif et traitera toutes les demandes sans aucun échec.
Lorsque votre ancien site actif est prêt et redémarré, vous pouvez reformer votre configuration comme avant. Rendez les deux sites actifs et cela transférera toutes les données de l’ancien site passif vers l’ancien site actif. Lorsque toutes les données sont transférées, vous pouvez effectuer des configurations sur votre site passif et rediriger toutes les demandes vers le site actif.
Dans le cas d'une communication entre deux caches actifs, les mêmes données mises en cache peuvent être mises à jour sur les deux caches presque simultanément, ce qui produit un conflit. Pour résoudre ce conflit, NCache fournit un configurable Résolveur de conflits qui résout les conflits d'opération pendant le temps de pont. Par défaut, la dernière opération « gagne » et est appliquée au cache en cas de conflit.
Si un site tombe en panne, vous pouvez rediriger toutes les demandes vers d'autres sites actifs. Lorsque le site en panne est à nouveau opérationnel, les données sont transférées du site déjà en cours d'exécution vers ce site et peuvent rediriger la demande de cette région vers ce site.
Notes
Il est recommandé que les caches aient les mêmes configurations autres que la topologie pour éviter les problèmes. Par exemple, si la source de données est configurée sur un cache, vous devez également la configurer sur l'autre cache. En effet, les mêmes spécifications d'opération d'un cache de site seront répliquées sur l'autre site.
Transfert d'État
Un transfert d'état peut être déclenché manuellement entre deux caches si vous souhaitez synchroniser l'état du cache source avec le cache cible. Cela se produit via un pont.
Les opérations de transfert d'état sont mises en file d'attente à la fin du cache et dès qu'il se connecte au pont, il commence à envoyer ses opérations au pont qui sont relayées au cache cible. Une fois que le transfert d'état entre les caches a été initié, vous ne pouvez pas initier un autre transfert d'état - pour assurer la stabilité du système.
Cas 1 : le cache lors du transfert d'état se produit :
Si le cache A et le cache B ont un transfert d'état en cours, le cache A tombe en panne et ne revient pas. Étant donné que le pont est en cours de transfert d'état, toute autre demande de transfert d'état entrante peut être rejetée pour cette raison. Pour répondre à cela, le pont détermine intelligemment s'il a cessé de recevoir les opérations du cache A après un intervalle spécifié. Ainsi, ce transfert d'état est considéré comme corrompu et le pont autorise la nouvelle demande de transfert d'état.
Cas 2 : Cache et Bridge ont un problème de réseau mais ne se déconnectent pas :
Dans le cas où la connexion du cache et du pont rencontre un problème de réseau, de sorte qu'elle soit partiellement connectée, les files d'attente d'opération et de transfert d'état sont toujours intactes. Ainsi, le transfert d’État peut reprendre puisqu’aucune opération n’a été perdue.
Files d'attente de pont
Le cache A est le cache actif tandis que le cache B est passif. Le cache A envoie des opérations au cache B via un pont, mais le cache B tombe en panne pendant un certain temps. Cela signifie que la file d'attente du pont se remplit à cause des opérations envoyées depuis le cache A, mais n'est pas retirée de la file d'attente car le cache B est en panne. Il arrivera un moment où la file d’attente du pont se remplira complètement et n’aura plus d’espace pour stocker d’autres opérations. Par conséquent, il demande au cache A de suspendre les opérations à sa fin jusqu'à ce qu'il dispose d'un peu d'espace. Les opérations sont ensuite mises en file d'attente uniquement à la fin du cache. Supposons que le cache B réapparaisse et que la file d'attente du réplicateur de pont commence à lui envoyer les opérations, étant ainsi retirée de la file d'attente. Une fois qu'une quantité configurable d'espace (20 Mo par défaut) est libérée, le pont indique au cache A qu'il peut désormais envoyer ses opérations en file d'attente.
Cependant, si la file d'attente du cache se remplit et que l'éviction est activée, le cache expulsera ses éléments mis en cache, mais pas les opérations en file d'attente. Cela évite la perte d'opérations.
Voir aussi
Topologies de cache
Cluster de cache
Cache local
Client cache
Cache Client