Développement de nouveaux services de données

Sun propose des fichiers de configuration et des modèles de méthodes de gestion vous permettant de faire fonctionner différentes applications comme service évolutif ou de basculement au sein d'un cluster. Si l'application que vous voulez faire fonctionner comme service évolutif ou de basculement ne fait pas partie de celles proposées par Sun, vous pouvez utiliser une API ou l'API DSET pour la configurer comme service évolutif ou de basculement.

Un ensemble de critères permet de déterminer si une application peut ou non devenir un service de basculement. Les critères spécifiques sont présentés dans la documentation SunPlex décrivant les API susceptibles d'être utilisées pour votre application.

Nous présentons ici quelques directives pour vous aider à déterminer si votre service peut ou non tirer profit d'une architecture de services de données évolutifs. Reportez-vous à la rubrique Services de données évolutifs pour de plus amples informations sur les services évolutifs.

Les nouveaux services remplissant les critères présentés ci-après peuvent utiliser les services évolutifs. Si un service existant ne correspond pas exactement à ces critères, certaines parties risquent de devoir être récrites.

Un service de données évolutifs a les caractéristiques suivantes : Premièrement, il est composé d'une ou plusieurs instances de serveur. Chaque instance tourne sur un nœud différent du cluster et plusieurs instances du même service ne peuvent pas fonctionner sur le même nœud.

Deuxièmement, si le service procure un stockage de données logique externe, l'accès simultané de plusieurs instances de serveur à ce stockage doit être synchronisé pour éviter de perdre des mises à jour ou de lire des données tandis qu'il est modifié. Notez que nous utilisons le terme « externe » pour distinguer le dispositif de stockage de la mémoire interne et le terme « logique » parce que le dispositif de stockage apparaît comme une entité unique, bien qu'il puisse lui-même être répliqué. En outre, ce stockage de données logique possède une propriété grâce à laquelle chaque fois qu'une instance de serveur met à jour les données stockées, la mise à jour est immédiatement vue par les autres instances.

Le système SunPlex fournit ce stockage externe à travers son système de fichiers de cluster et ses partitions de données brutes globales. Supposons par exemple qu'un service écrive des données sur un fichier journal externe ou qu'il modifie les données en place. Lorsque plusieurs instances de ce service fonctionnent, chacune d'elles a accès à ce journal externe et elles peuvent y accéder simultanément. Les instances doivent alors synchroniser leur accès pour éviter toute interférence entre elles. Le service peut utiliser le système de verrouillage de fichiers ordinaire de Solaris via fcntl(2) et lockf(3C) pour effectuer cette synchronisation.

Les bases de données back-end, telles qu'Oracle grande disponibilité ou Oracle Real Application Clusters pour les clusters basés sur SPARC constituent un autre exemple de ce type de stockage. Notez que ce type de serveur de base de données back-end possède un dispositif de synchronisation muni d'un système de requêtes à la base de données ou de transactions de mises à jour ; ainsi les instances de serveur n'ont pas besoin d'implémenter leur propre synchronisation.

Le serveur Sun IMAP tel qu'il se présente à l'heure actuelle est un exemple de service non évolutif. Le service met à jour une mémoire, mais cette mémoire est privée et lorsque les instances IMAP écrivent dans cette mémoire, elles s'écrasent mutuellement parce que les mises à jour ne sont pas synchronisées. Le serveur IMAP doit être récrit pour synchroniser les accès simultanés.

Enfin, notez que les instances peuvent avoir des données privées se détachant des données d'autres instances. Dans ce cas, le service n'a pas à se préoccuper de la synchronisation des accès, car les données sont privées et seule cette instance peut les manipuler. Vous devez alors prendre garde à ne pas stocker ces données privées sous le système de fichiers du cluster car elles ont la capacité de devenir globalement accessibles.

API de services de données et de bibliothèque de développement de services de données

Le système SunPlex intègre les éléments suivants permettant de rendre les applications hautement disponibles :

• des services de données intégrés au système SunPlex ;

• une API (interface de programme d'application) de services de données ;

• une API de bibliothèque de développement de services de données ;

• un service de données « générique ».

Le manuel Sun Cluster Data Services Planning and Administration Guide for Solaris OS explique comment installer et configurer les services de données fournis avec le système SunPlex. Le manuel Sun Cluster 3.1 9/04 Software Collection for Solaris OS (SPARC Platform Edition) explique comment paramétrer d'autres applications pour les rendre hautement disponibles dans le cadre de la structure Sun Cluster.

Les API Sun Cluster permettent aux programmeurs de développer des détecteurs de pannes et des scripts démarrant et arrêtant les instances des services de données. Grâce à ces outils, une application peut devenir un service de données évolutif ou de basculement. En outre, le système SunPlex intègre un service de données « générique » pouvant être utilisé pour générer rapidement les méthodes de démarrage et d'arrêt d'une application afin de la faire fonctionner comme service évolutif ou de basculement.