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 pour pouvoir être rendue hautement disponible et évolutive. Si l’application ne satisfait pas toutes les conditions requises, vous pourrez modifier son code source pour la rendre hautement disponible et évolutive.

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 à Annexe B, Liste des exemples de codes de service de données.

Pour être hautement disponible, un service évolutif doit remplir toutes les conditions suivantes, ainsi que certains critères supplémentaires indiqués à la suite de la liste.

• Dans l'environnement Sun Cluster, vous pouvez rendre hautement disponibles ou évolutives des applications réseau (modèle client/serveur) ou 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é dans 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 nœud 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 connections.

• L'application ne doit pas dépendre du nom d'hôte physique du nœud 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 comme actives, comme par exemple les environnements comportant des hôtes multihome (caractérisés par le fait que le nœud figure sur plusieurs réseaux publics) et les environnements comportant des nœuds sur lesquels plusieurs interfaces logiques sont configurées comme actives 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 codé en dur pour localiser les données, vous pouvez le remplacer 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 nœud 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 lorsque 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 gèrent également 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 socket de domaine UNIX® ni tube 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 nœuds.

• L'application doit mettre en œuvre 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 la charge. Par exemple, la règle d'équilibrage de chargeLb_weighted, 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 la charge qui restreint le trafic d'un client donné à une instance de l'application. Les règles d'équilibrage de charge Lb_sticky et Lb_sticky_wild transmettent de manière répétée toutes les requêtes d'un client à la même instance de l'application, où elles pourront exploiter la mémoire cache d'entrée. Notez que si plusieurs requêtes client proviennent de différents clients, le RGM les distribue entre les instances du service. Reportez-vous à la rubrique Mise en œuvre d'une ressource de basculement pour obtenir de plus amples informations sur le paramétrage de la règle d'équilibrage de charge des services de données évolutifs.