Analyse du caractère approprié de l'application

La première étape de création d'un service de données consiste à s'assurer que l'application répond effectivement aux conditions requises en matière de haute disponibilité et d'évolutivité. Si l'application ne satisfait pas toutes les conditions requises, vous devez être en mesure de modifier son code source pour pallier le problème.

La liste indiquée ci-après présente brièvement les exigences requises pour qu'une application soit hautement disponible ou évolutive. Pour obtenir de plus amples informations ou si vous devez modifier le code source de l'application, reportez-vous à l'Annexe B.

pour être hautement disponible, un service évolutif doit remplir toutes les conditions suivantes, ainsi que certains critères supplémentaires.

• Dans l'environnement Sun Cluster, vous pouvez rendre hautement disponibles ou évolutives des applications réseau (modèle client/serveur) et non prévues pour être utilisées en réseau (sans client). Cependant, Sun Cluster ne peut pas optimiser la disponibilité au sein d'environnements en temps partagé sous lesquels des applications sont exécutées sur un serveur accessible via telnet ou rlogin.

• L'application doit être tolérante aux pannes. Cela signifie qu'elle doit restaurer (si nécessaire) les données de disque au démarrage après qu'un noeud soit tombé en panne de façon inattendue. En outre, le temps de reprise après une panne doit être limité. La tolérance aux pannes est indispensable pour rendre une application hautement disponible car la possibilité de restaurer le disque et de redémarrer l'application est une question d'intégrité des données. Il n'est pas nécessaire que le service de données puisse restaurer les connexions.

• L'application ne doit pas dépendre du nom d'hôte physique du noeud sur lequel elle est exécutée. Reportez-vous à la rubrique Noms d'hôtes pour obtenir de plus amples informations.

• L'application doit fonctionner correctement dans les environnements sous lesquels plusieurs adresses IP sont configurées en amont, comme par exemple les environnements comportant des hôtes multihome (caractérisés par le fait que le noeud figure sur plusieurs réseaux publics) et les environnements comportant des noeuds sur lesquels plusieurs interfaces logiques sont configurées en amont sur une seule interface matérielle.

• Pour être hautement disponibles, les données de l'application doivent résider dans les systèmes de fichiers du cluster. Reportez-vous à la rubrique Données multi-hôtes.

  Si l'application utilise un nom de chemin d'accès câblé pour localiser les données, vous pouvez le modifier par un lien symbolique renvoyant à un emplacement dans le système de fichiers du cluster, sans modifier le code source de l'application. Reportez-vous à la rubrique Utilisation de liens symboliques pour déterminer l'emplacement des données multi-hôtes pour obtenir de plus amples informations.

• Les codes binaires applicatifs et les bibliothèques peuvent résider localement sur chaque noeud ou dans le système de fichiers du cluster. Avantage lorsqu'ils résident dans le système de fichiers du cluster : une seule installation suffit. Inconvénient : la mise à niveau devient problématique car les codes binaires sont en cours d'utilisation tandis que l'application est exécutée sous le contrôle du gestionnaire RGM.

• Le client doit pouvoir essayer de relancer automatiquement une requête si le délai de la première tentative est dépassé. Si l'application et le protocole prennent déjà en charge le redémarrage d'un serveur tombé en panne, ils peuvent également gérer le basculement ou la commutation du groupe de ressources. Reportez-vous à la rubrique Relance d'un client pour obtenir de plus amples informations.

• L'application ne doit comporter ni prise de domaine Unix ni pipe nommé dans le système de fichiers du cluster.

De plus, les services évolutifs doivent satisfaire les conditions suivantes :

• L'application doit pouvoir exécuter plusieurs instances fonctionnant toutes sur les mêmes données d'application dans le système de fichiers du cluster.

• L'application doit assurer la cohérence des données dans le cadre d'accès simultanés à partir de plusieurs noeuds.

• L'application doit mettre en oeuvre un verrouillage suffisant au moyen d'un mécanisme visible à l'échelle du système, comme le système de fichiers du cluster.

Dans le cadre d'un service évolutif, les caractéristiques de l'application déterminent également la règle d'équilibrage de charge. Par exemple, la règle d'équilibrage de charge équilibrage_charge_pondéré , qui permet à n'importe quelle instance de répondre aux requêtes des clients, ne fonctionne pas avec une application utilisant une mémoire cache d'entrée sur le serveur pour les connexions client. Dans ce cas, vous devez spécifier une règle d'équilibrage de charge qui restreint le trafic d'un client donné à une instance de l'application. Les règles d'équilibrage de charge équilibrage_charge_sticky et équilibrage_charge_sticky_joker transmettent à plusieurs reprises toutes les requêtes d'un client à la même instance de l'application où elles peuvent utiliser la mémoire cache d'entrée. Notez que si plusieurs requêtes client proviennent de différents clients, le gestionnaire RGM les distribue entre les instances du service. Reportez-vous à la rubrique Mise en oeuvre d'une ressource de basculement pour de plus amples informations sur le paramétrage de la règle d'équilibrage de charge des services de données évolutifs.