Caractéristiques des services évolutifs

Un ensemble de critères détermine si une application peut devenir un service évolutif. Pour déterminer si c'est le cas de la vôtre, reportez-vous à la section Analyse du caractère approprié de l’application du Guide du développeur de services de données Sun Cluster pour SE Solaris. Cet ensemble de critères est résumé ci-dessous.

• Tout d'abord, un tel service est composé d'une ou de 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.

• Si le service fournit un magasin de données logique externe, vous devez être prudent. Vous devez synchroniser les accès simultanés à ce magasin depuis plusieurs instances de serveur pour éviter de perdre des mises à jour ou de lire des données en cours de modification. Notez l'utilisation du terme « externe » pour que ce magasin ne soit pas considéré comme en mémoire. Le terme « logique » indique que ce magasin s'affiche en tant qu'entité unique, bien qu'il puisse être répliqué. En outre, à chaque fois qu'une instance de serveur met à jour ce magasin de données logique, les autres instances peuvent immédiatement « voir » cette mise à jour.

  Le système Sun Cluster propose un stockage externe de ce type par le biais de son système de fichiers de cluster et de ses partitions 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. Si plusieurs instances de ce service s'exécutent, chacune a accès à ce journal externe, auquel elles peuvent accéder simultanément. Les instances doivent alors synchroniser leur accès pour éviter toute interférence entre elles. Le service peut utiliser le verrouillage de fichier ordinaire Solaris via fcntl(2) et lockf(3C) pour obtenir la synchronisation souhaitée.

  Un autre exemple de ce type de magasin est une base de données d'arrière-plan, notamment la base de données Oracle Real Application Clusters Guard à haute disponibilité pour les clusters SPARC ou Oracle. Ce type de serveur de base de données d'arrière-plan propose une synchronisation intégrée en utilisant des requêtes de base de données ou des transactions de mise à jour. Ainsi, plusieurs instances de serveur n'ont pas besoin d'implémenter leur propre synchronisation.

  Le serveur Sun IMAP 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.

• Pour finir, notez que les instances peuvent disposer de données privées disjointes de celles des autres instances. Dans un tel cas, le service n'a pas besoin d'accès simultané synchronisé, car les données sont privées : seule l'instance en question peut les manipuler. Dans ce cas, vous devez veiller à ne pas stocker ces données privées dans le système de fichiers de cluster, car ces données seront alors globalement accessibles.