Le service de données Sun Cluster HA pour Oracle 3.0 peut fonctionner sur Sun Cluster 3.1 uniquement s'il est utilisé avec les versions suivantes de l'environnement d'exploitation Solaris :
Solaris 8, version 32 bits ;
Solaris 8, version 64 bits ;
Solaris 9, version 32 bits.
le service de données Sun Cluster HA pour Oracle 3.0 ne peut pas fonctionner sur Sun Cluster 3.1 s'il est utilisé avec la version 64 bits de Solaris 9.
Conformez-vous à la documentation de l'option Oracle Parallel Fail Safe/Real Application Clusters Guard des clusters Oracle Parallel Server/Real Application car il est impossible de modifier les noms d'hôtes après l'installation du logiciel Sun Cluster.
Pour de plus amples informations sur cette restriction concernant les noms d'hôtes et les noms de noeuds, reportez-vous à la documentation Oracle Parallel Fail Safe/Real Application Clusters Guard.
Si le client NetBackup VERITAS est un cluster, un seul hôte logique peut être configuré comme client car il n'y a qu'un seul fichier bp.conf.
Si le client NetBackup est un cluster et que l'un de ses hôtes logiques est configuré comme client NetBackup, NetBackup ne peut pas sauvegarder les hôtes physiques.
Sur le cluster exécutant le serveur maître, ce dernier est le seul hôte logique pouvant être sauvegardé.
Aucun support de sauvegarde ne peut être relié au serveur maître, il faut donc installer un ou plusieurs serveur(s) de support.
Dans un environnement Sun Cluster, le contrôle robotisé n'est pris en charge que sur les serveurs de supports et non sur le serveur maître NetBackup tournant sur Sun Cluster.
Aucun noeud Sun Cluster ne peut être le client NFS d'un système de fichiers exporté Sun Cluster HA pour NFS contrôlé sur un noeud du même cluster. Un tel montage croisé de Sun Cluster HA pour NFS est interdit. Utilisez le système de fichiers de cluster pour répartir les fichiers entre les noeuds.
Les applications exécutées localement sur le cluster ne doivent pas verrouiller les fichiers sur un système de fichiers exporté via NFS. Sinon, un blocage local (par exemple, flock(3UCB) ou fcntl (2)) risque d'empêcher le gestionnaire de verrouillage (lockd) de redémarrer. Au redémarrage, il est possible qu'un processus local bloqué soit verrouillé et que seul un client distant puisse le déverrouiller. Le comportement qui s'ensuit est imprévisible.
Sun Cluster HA pour NFS requiert que tous les montages de clients NFS soient « rigides ».
Avec Sun Cluster HA pour NFS, n'utilisez pas d'alias de noms d'hôtes pour les ressources réseau. Des clients NFS montant des systèmes de fichiers de cluster à l'aide d'alias de noms d'hôtes risquent de rencontrer des problèmes de récupération en cas de verrouillage statd.
Le logiciel Sun Cluster 3.1 ne prend pas en charge l'option Secure NFS ni l'utilisation conjointe de Kerberos et de NFS, et en particulier les options secure et kerberos appliquées au sous-système share_nfs(1M). Néanmoins, le logiciel Sun Cluster 3.1prend en charge l'utilisation de ports sécurisés pour NFS en ajoutant l'entrée set nfssrv:nfs_portmon=1 au fichier /etc/system sur les noeuds du cluster.
N'utilisez pas NIS pour les services de noms d'un cluster exécutant Sun Cluster HA pour SAP liveCache car l'entrée NIS n'est utilisée que si les fichiers ne sont pas disponibles.
Pour de plus amples informations sur les exigences du mot de passe nssswitch.conf par rapport à cette restriction, reportez-vous à la rubrique “Preparing the Nodes and Disks” in Sun Cluster 3.1 Data Service for SAP liveCache Guide .