La plateforme Devolutions suit certaines directives de conception pour préserver l'historique complet des versions de vos données, qu’il s’agisse de modifications ou de suppressions. Elle possède également une couche de journalisation étendue pour fournir une visibilité complète sur l'activité effectuée pendant l'utilisation du système. Ces choix de conception affectent les options à votre disposition pour assurer une tolérance aux pannes au niveau de la base de données.
Impact sur les choix technologiques
En raison de toutes les opérations d'écriture se produisant en arrière-plan, vous ne pouvez pas avoir une topologie autre qu'active-passive. La réplique de secours doit être maintenue synchronisée à tout moment mais ne doit pas être touchée. Il ne peut y avoir qu'une seule base de données en cours d'utilisation à tout moment. Vous pouvez utiliser les technologies Microsoft de mise en miroir ou de clustering, mais il est essentiel que le contenu répliqué ne soit accessible que lorsque le contenu maître est indisponible.
Mise en miroir comme moyen de partager avec des équipes éloignées
La conséquence de garder les données répliquées inchangées signifie que la réplication n'est PAS la solution appropriée à utiliser chaque fois que vous avez plusieurs équipes et que vous souhaitez partager un ensemble de données maîtres parmi elles. Pour ce scénario, il est préférable d’utiliser un mélange de :
- Synchroniseurs, en particulier celui pour les données de Remote Desktop Manager ; et
- Scripts PowerShell (pour exporter une branche spécifique de votre arborescence).
Donnez-nous vos commentaires