Cette annexe fournit une méthode pour utiliser la réplication basée sur les hôtes sans recourir à Oracle Solaris Cluster Geographic Edition. Utilisez Oracle Solaris Cluster Geographic Edition pour la réplication basée sur les hôtes pour simplifier la configuration et le fonctionnement de la réplication basée sur les hôtes entre des clusters. Reportez-vous à la section Présentation de la réplication de données.
L'exemple de cette annexe montre la procédure de configuration de la réplication de données basée sur les hôtes entre des clusters utilisant le logiciel Fonction Availability Suite d'Oracle Solaris. L'exemple illustre une configuration en cluster complète pour une application NFS qui fournit des informations détaillées à propos de la réalisation des tâches individuelles. Toutes les tâches doivent être exécutées dans le cluster global. L'exemple n'inclut pas toutes les étapes requises par d'autres applications ou d'autres configurations en cluster.
Si vous utilisez le contrôle d'accès basé sur les rôles (RBAC) pour accéder aux noeuds du cluster, assurez-vous de disposer des droits RBAC fournissant l'autorisation pour toutes les commandes d'Oracle Solaris Cluster. Cette série de procédures de réplication de données nécessite les autorisations RBAC Oracle Solaris Cluster suivantes :
solaris.cluster.modify
solaris.cluster.admin
solaris.cluster.read
Reportez-vous au manuel Sécurisation des utilisateurs et des processus dans Oracle Solaris 11.3 pour plus d'informations sur l'utilisation des rôles RBAC. Reportez-vous aux pages de manuel d'Oracle Solaris Cluster pour connaître les autorisations RBAC requises par chaque sous-commande d'Oracle Solaris Cluster.
Cette section présente la tolérance de sinistre et décrit les méthodes de réplication des données qu'utilise le logiciel Availability Suite.
La tolérance de sinistre correspond à l'aptitude à restaurer une application sur un cluster alternatif en cas de défaillance du cluster principal. La tolérance de sinistre se base sur la réplication de données et la reprise. Une reprise déplace un service d'application vers un cluster secondaire en mettant en ligne un ou plusieurs groupes de ressources et de périphériques.
Si les données sont répliquées de manière synchrone entre le cluster principal et le cluster secondaire, aucune donnée validée n'est perdue en cas de défaillance du site principal. Cependant, si les données sont répliquées de manière asynchrone, il peut arriver que des données ne soient pas répliquées vers le cluster secondaire avant la défaillance du site principal et soient donc perdues.