SafeKit. Sommaire. Un livre blanc de Bull Evidian

Transcription

1 Un livre blanc de Bull Evidian SafeKit Une solution de haute disponibilité logicielle packageable avec n'importe quelle application Windows ou Unix Par Bruno Rochat Sommaire Novembre 2005 Haute disponibilité logicielle versus haute disponibilité matérielle Méthode pour construire une solution de haute disponibilité plug-and-play avec une application Architectures de haute disponibilité applicative Quelles organisations utilisent typiquement SafeKit? Points clés à retenir sur l'utilisation de SafeKit

2 2005 Evidian Les informations contenues dans ce document reflètent l'opinion d'evidian sur les questions abordées à la date de publication. En raison de l'évolution constante des conditions de marché auxquelles Evidian doit s'adapter, elles ne représentent cependant pas un engagement de la part d'evidian qui ne peut garantir l'exactitude de ces informations passé la date de publication. Ce document est fourni à des fins d'information uniquement. EVIDIAN NE FAIT AUCUNE GARANTIE IMPLICITE NI EXPLICITE DANS LE PRÉSENT DOCUMENT. Les droits des propriétaires des marques cités dans cette publication sont reconnus.

3 Table des matières Haute disponibilité logicielle versus haute disponibilité matérielle... 4 Comprendre le marché de la haute disponibilité...4 Comment SafeKit se compare t-il aux boîtiers de partage de charge?...6 Comment SafeKit se compare t-il aux solutions de type cluster?...7 Caractéristiques de SafeKit uniques sur le marché...7 Méthode pour construire une solution de haute disponibilité plug-and-play avec une application... 8 Modules applicatifs...8 Modules applicatifs multiples avec reprises sur panne indépendantes...9 Console d'administration de la haute disponibilité...10 Architectures de haute disponibilité applicative Application en 'ferme'...11 Application en 'miroir'...11 Mixte d'applications en 'ferme' et en 'miroir'...13 Reprise mutuelle entre 2 serveurs applicatifs...14 N serveurs applicatifs actifs et un seul serveur de secours...15 Quelles organisations utilisent typiquement SafeKit?.. 16 Équipes de production des systèmes d'information...16 Grand déploiement d'une solution de haute disponibilité...17 Haute disponibilité et partage de charge de serveurs en lame...18 Haute disponibilité et résistance au désastre...19 Haute disponibilité et partage de charge d'une suite applicative logicielle...20 Points clés à retenir sur l'utilisation de SafeKit F2 25LT Rev00 3

4 Haute disponibilité logicielle versus haute disponibilité matérielle Comprendre le marché de la haute disponibilité Dans de nombreuses situations critiques, le besoin de disponibilité d'une application excède ce que peut offrir une application type mis en œuvre sur un serveur et un système d'exploitation. Heureusement, des solutions de haute disponibilité existent aujourd'hui sur le marché. Ce chapitre va vous aider à choisir la bonne réponse par rapport au problème de haute disponibilité posé. Nous étudierons ensuite plus en détail chaque solution. Les besoins en haute disponibilité peuvent être divisés en trois grandes classes : Besoin n o 1: Haute disponibilité d'une application avec un déploiement très simple Besoin n o 2: Haute disponibilité d'une ferme web Besoin n o 3: Haute disponibilité d'une base de données Pour répondre à ces besoins, les solutions techniques sont de trois types : Haute disponibilité logicielle packagée avec une application. Boîtier réseau de partage de charge. Cluster matériel avec disque partagé. Comment choisir la solution la plus appropriée à votre situation? Nous examinons les forces et faiblesses de chacune des solutions. Figure 1 Haute disponibilité besoins et solutions Besoin n o 1 Déploiement d une application CDROM Haute disponibilité logicielle - N applications Besoin n o 2 Ferme web Besoin n o 3 Base de données Réseau Équilibrage de charge matériel N serveurs web Cluster matériel N disques Disques 39 F2 25LT Rev00 4

5 Boîtiers réseau de partage de charge (Cisco Context Switch, Nortel Alteon ) NON ADAPTÉ au besoin n o 1 et à la haute disponibilité d'une application avec un déploiement très simple, car cette solution matérielle ne peut pas être packagée avec une application quelconque (notamment, pas de script de redémarrage automatique de l'application, pas de réplication des données critiques de l'application). ADAPTÉ au besoin n o 2 et au partage de charge d'une ferme web. NON ADAPTÉ au besoin n o 3 et à la haute disponibilité d'une base de données car cette solution ne répond pas techniquement au problème. Cluster matériel avec disque partagé (Bull ARF, IBM HA-CMP, Microsoft MSCS, Red Hat Cluster, NEC ExpressCluster ) NON ADAPTÉ au besoin n o 1 et à la haute disponibilité d'une application avec un déploiement très simple, car cette solution nécessite à chaque déploiement de configurer du matériel spécifique avec des disques partagés, et de reconfigurer l'application pour qu'elle stocke ses données sur disque partagé. NON ADAPTÉ au besoin n o 2 et au partage de charge d'une ferme web car cette solution ne répond pas techniquement au problème. ADAPTÉ au besoin n o 3 et à la haute disponibilité d'une base de données. Haute disponibilité logicielle packagée avec une application (SafeKit) ADAPTÉ au besoin n o 1 et à la haute disponibilité d'une application avec un déploiement très simple, car les mécanismes de haute de disponibilité sont packagés avec l'application et déployés par une simple installation logicielle. NON ADAPTÉ au besoin n o 2 dans le cas d'une grande ferme web (> 10 serveurs web) car chaque serveur web doit avoir le logiciel de partage de charge installé, au lieu d'un boîtier centralisé pour réaliser l'ensemble du partage de charge. NON ADAPTÉ au besoin n o 3 dans le cas d'une grosse base de données (>100 Giga-octets) car la réplication des fichiers par logiciel au dessus d'un réseau standard est limité par la bande passante réseau et la latence (nécessite une base de données <100 Giga-octets). Une solution de haute disponibilité logicielle, telle que SafeKit, est par conséquent la meilleure réponse, si vous souhaitez réaliser le déploiement très simple d'une solution de haute disponibilité packagée avec une application. SafeKit est suffisamment flexible pour vous offrir à la fois le partage de charge et la disponibilité des données. Comme ces caractéristiques sont fournies habituellement par des solutions matérielles différentes, nous allons expliquer maintenant comment SafeKit se compare au boîtier de partage de charge et au solution de type cluster. 39 F2 25LT Rev00 5

6 Comment SafeKit se compare t-il aux boîtiers de partage de charge? SafeKit fournit le partage de charge à travers son architecture 'ferme'. Partage de charge avec des boîtiers réseau Boîtiers de partage de charge réseau Grande ferme web (> 10 serveurs web) Principe Positif/Négatif Ajouter un boîtier dédié (la boîte rouge) devant vos serveurs applicatifs (les 3 boîtes bleues) pour réaliser un partage de charge du flux réseau. Ajouter un second boîtier pour la reprise sur panne du premier boîtier. Les fabricants d équipements réseau délivrent ce type de solution avec des boîtiers dédiés au partage de charge (Cisco Context Switch, Nortel Alteon...). Ce type de solution est adapté aux grosses fermes de serveurs web avec des besoins de partage de charge avancés sur les entêtes HTTP (niveau 7) ou avec un besoin d accélérateur HTTPS. Ce type de solution n est pas adapté aux pare-feux ou aux chaînes d applications à cause de la multiplication des boîtiers de partage de charge dans chaque réseau et DMZ. Partage de charge avec l'architecture 'ferme' de SafeKit filtre de partage de charge logiciel réseau ET redémarrage automatique des applications Principe Ajouter un morceau de logiciel (la boîte rouge à l intérieur de la boîte bleue) sur chaque serveur applicatif (les 3 boîtes bleues). Le partage de charge est mis en œuvre sans système centralisé de répartition mais avec un mécanisme de diffusion des paquets réseau et un filtre de partage de charge dans le noyau du système d exploitation de chaque serveur. L'architecture 'ferme' de SafeKit met en œuvre le partage de charge et la reprise automatique sur des serveurs Windows, Linux, AIX et Solaris. Positif/Négatif Ce type de solution est adapté aux pare-feux et à n importe quelle application qui nécessite non seulement le partage de charge mais aussi la surveillance des processus applicatif et le redémarrage automatique de l'application après panne. Ce type de solution n est pas adapté au grande ferme web (plus de 10 serveurs web) à cause de la multiplication des installations logicielles sur chaque serveur web. 39 F2 25LT Rev00 6

7 Comment SafeKit se compare t-il aux solutions de type cluster? SafeKit fournit la réplication de fichiers à travers son architecture 'miroir'. Cluster matériel avec disponibilité des données Disque partagé ou miroir ou Application avec une grosse base (> 100 Goctets) Principe Mettre les données critiques sur un disque partagé ou miroir (les disques rouges) et en cas de défaillance, récupérer le disque partagé entre les nœuds (les boîtes bleues). Redémarrer l'application en cas de panne. Ce type de solution est livré par les constructeurs de plate-forme avec leurs serveurs. Exemple: Bull ARF, IBM HA-CMP, Windows MSCS, Red Hat Linux Cluster, NEC ExpressCluster... Positif/Négatif Ce type de solution est adapté aux grosses bases de donnée (Oracle, SAP R/3 ). Ce type de solution n est pas adapté aux applications avec des bases de données de taille petite ou moyenne à cause de la configuration disque spécifique et de la réorganisation de l'application pour positionner ses données sur le disque partagé ou miroir. Disponibilité des données avec l'architecture miroir de SafeKit Fichiers miroirs à travers le réseau Fichier Fichier Application avec une petite base (<100 Goctets) Principe Ajouter un morceau de logiciel sur les serveurs de base de données (les 2 boîtes bleues) qui réalise une réplication temps réel des fichiers à travers le réseau IP standard (la flèche noire). Les fichiers répliqués sont stockés sur les disques internes de chaque serveur (les 2 répertoires de fichiers rouges). L'architecture miroir de SafeKit met en œuvre la réplication de fichiers et la reprise automatique sur des serveurs Windows, Linux, AIX et Solaris. Positif/Négatif Ce type de solution est très facile à déployer. La technologie est la réplication de fichiers (et non la réplication des disques) sans pré requis sur l organisation des disques au moment de l installation : il suffit de définir les fichiers à répliquer. Cette solution n est pas adaptée aux grosses bases de données : elles doivent être inférieures à 100 Gigaoctets et la bande passante du réseau doit être au moins de 10 Mega bits/seconde. Caractéristiques de SafeKit uniques sur le marché SafeKit est unique sur le marché sur deux points : SafeKit est le seul produit qui apporte à la fois le partage de charge, la réplication de fichiers et la reprise automatique. La concurrence apporte soit une architecture de type 'ferme', soit une architecture de type 'miroir' mais JAMAIS les deux architectures 'ferme' et 'miroir' dans un seul produit. SafeKit est le seul produit à mettre en œuvre la réplication temps réel de fichiers sur Unix. La concurrence est sur Windows seulement (notez que SafeKit met en œuvre aussi la réplication de fichiers sur Windows). Sur Unix, les solutions concurrentes mettent en œuvre des disques miroirs mais pas des fichiers miroirs. La configuration par fichier est indispensable pour un déploiement aisé d'une application en haute disponibilité sans réorganisation disque. 39 F2 25LT Rev00 7

8 Méthode pour construire une solution de haute disponibilité plug-and-play avec une application Modules applicatifs SafeKit permet de déployer une solution de haute disponibilité de manière plug-andplay et de la maintenir facilement dans le temps. Pour cela, SafeKit offre la notion de module applicatif. Un module applicatif est un packaging de SafeKit avec une application donnée (i.e. : "Appli.Safe"). Figure 2 Comment construire une solution de haute disponibilité plug-and-play avec SafeKit 1. Définir les applications critiques Front-office ou Back-office hormis les applications avec grosse base de données (>100 Goctets) SafeKit: toolkit de haute disponibilité, multi plateforme, purement logiciel serveurs standard ou plus architecture ferme ou miroir 2. Pré intégration de SafeKit avec l application: Appli.Safe Écrivez votre propre module applicatif ferme ou miroir Appli.Safe Prenez pour exemple les modules.safe livrés avec SafeKit 3. Déploiement une application hautement disponible plug&play Seuls les paramètres basiques sont à configurer : adresses IP des serveurs SafeKit est livré avec des modules applicatifs prêts à l'emploi : Sur Unix: Apache.Safe, Oracle.Safe, Netfilter.Safe (Linux), MySQL.Safe (Linux). Sur Windows: Microsoft IIS.Safe, Microsoft SQL Server.Safe, Oracle.Safe. SafeKit est également ouvert à n'importe quelle application : vous construisez alors votre propre module ".Safe" pour votre application. Vous pouvez démarrer votre intégration à partir de Mirror.Safe, une configuration générique pour la réplication de fichiers et la reprise automatique. Vous aurez à écrire les scripts de redémarrage de votre application et à définir les fichiers de l'application à répliquer. Ou vous pouvez démarrer votre intégration à partir de Farm.Safe, une configuration générique pour le partage de charge et la reprise automatique. Vous aurez à écrire les scripts de redémarrage de votre application et à définir les règles de partage de charge. 39 F2 25LT Rev00 8

9 Une fois l'intégration réalisée, vous pourrez packager votre propre module ".Safe" et bénéficier du déploiement très simple de votre solution de haute disponibilité applicative dans la console d'administration de SafeKit. Modules applicatifs multiples avec reprises sur panne indépendantes La plupart des serveurs exécutent plusieurs applications et dans ce cas, SafeKit protège indépendamment les unes des autres, chaque application. Pour cela, SafeKit sait exécuter concurremment plusieurs modules applicatifs sur les mêmes serveurs physiques avec un système de reprise indépendant pour chaque module applicatif. Sur l'exemple de la figure, avec une technologie mettant en œuvre des scripts de redémarrage par serveur et non par application, la défaillance d'une application sur un serveur génère systématiquement le redémarrage de toutes les applications. Avec la fonction multi modules de SafeKit, chaque application est intégrée dans un module ".Safe" différent (Appli1.Safe, Appli2.Safe, Appli3.Safe). Chaque module contient des scripts de démarrage et d'arrêt pour une seule application. Et si un processus applicatif appartenant à Appli1 meurt, seule Appli1 est redémarrée. Les autres applications restent dans leur état (pas de reprise pour elles). Figure 3 Bénéfices des modules applicatifs multiples Avec une technologie mettant en oeuvre des scripts de reprise par serveur Avec la technologie multi modules de SafeKit, scripts de redémarrage par application Appli1, Appli2, Appli3 SafeKit multi modules Appli1.Safe Appli2.Safe Appli3.Safe Si une application est défaillante, redémarrage de toutes les applications sur le serveur backup Si une application est défaillante, seule cette application est redémarrée sur le serveur backup 39 F2 25LT Rev00 9

10 Console d'administration de la haute disponibilité La console SafeKit vous permet d'administrer de manière très simple une solution de haute disponibilité. A partir de la console, un administrateur peut déployer, configurer, surveiller et contrôler des modules applicatifs en haute disponibilité et ceci sur un nombre quelconque de serveurs. La console SafeKit est une application Java multi plateforme qui peut s'exécuter sur une station de travail distante (Windows, Linux, AIX et Solaris). Dans l'exemple suivant, un administrateur a déployé 3 modules applicatifs sur 2 serveurs. Appli1, Appli2 et Appli3 s'exécutent sur le serveur 1 et aucune application ne tourne sur le serveur 2. L'administrateur peut basculer Appli3 sur le serveur 2, juste en cliquant sur le bouton swap associé à Appli3 dans la console SafeKit. Appli3 sera arrêtée sur le serveur 1 et redémarrée sur le serveur 2. Figure 4 La console d'administration de la haute disponibilité La console SafeKit pour déployer, contrôler et surveiller des applications en haut disponibilité Appli1.Safe Appli2.Safe Appli3.Safe Appli1.Safe Appli2.Safe Appli3.Safe L administrateur décide de basculer Appli3 sur le serveur 1 Avec la console SafeKit, un administrateur gère la haute disponibilité des applications sur Windows, Linux, AIX et Solaris, sans connaissance particulière ni sur les plateformes matérielles, ni sur les systèmes d'exploitation. 39 F2 25LT Rev00 10

11 Architectures de haute disponibilité applicative Application en 'ferme' L'architecture 'ferme" permet d'assurer à fois le partage de charge réseau, à travers une distribution transparente du trafic réseau et une reprise sur panne matérielle et logicielle. Cette architecture fournit une solution simple au problème de la montée en charge. La même application s'exécute sur chacun des serveurs et la charge est distribuée dans les couches réseau de chaque système d'exploitation. L'architecture 'ferme' est adaptée aux applications frontales telles que les pare-feux ou les services web. Netfilter.Safe, Apache.Safe, Microsoft IIS.safe sont des exemples de modules applicatifs de type 'ferme'. Vous pouvez écrire votre propre module 'ferme' pour votre application à partir du module générique Farm.Safe. Figure 5 Une 'ferme' SafeKit avec partage de charge réseau et reprise sur panne Module ferme avec 2 serveurs Module ferme avec 4 serveurs (jqà 128) Adresse IP virtuelle avec partage de charge réseau Filtre réseau dans chaque serveur consommant de 3% CPU Ajout de nouveaux serveurs dans la ferme suivant la charge Poids par serveur pour prendre plus ou moins de trafic Partage de charge sur adresse IP client pour les serveurs à état Partage sur port TCP/UDP client pour les serveurs sans état Partage de charge sur les routes IP pour les pare-feux Détection des pannes de serveurs et de réseau Surveillance des processus Scripts pour redémarrer automatiquement une application Peut être personnalisé avec n importe quelle application et constitué un nouveau module «Appli.Safe» très simple à déployer Apache.Safe IIS.Safe Netfilter.Safe Generic Farm.Safe Application en 'miroir' L'architecture miroir est une solution de haute disponibilité de type primaire, secours applicable à n'importe quelle application. L'application est exécutée sur un serveur primaire et redémarrée automatiquement sur un serveur de secours si le serveur primaire est défaillant. Avec la réplication de fichiers, cette architecture est particulièrement adaptée à la haute disponibilité des applications base de données avec des données critiques à protéger contre les pannes. Microsoft SQL Server.Safe, MySQL.Safe, Oracle.Safe sont des exemples de modules applicatifs de type 'miroir'. Vous pouvez écrire votre propre module miroir pour votre application à partir du module générique Mirror.Safe. 39 F2 25LT Rev00 11

12 Figure 6 Un 'miroir' SafeKit avec réplication de fichiers et reprise p p PRIMAIRE SECONDAIRE = Défaillance PRIMAIRE = Resynchronisation PRIMAIRE SECONDAIRE PRIMAIRE = Réplication de fichiers à travers le réseau Réplication seulement des modifications à l intérieur des fichiers Écriture synchrone (= fichiers miroirs) < 100Goctets car répli à travers le réseau Option: réseau dédié à la réplication Adresse IP virtuelle primaire-backup Détection des pannes serveur et réseau Surveillance des processus Scripts pour redémarrer une application Peut être personnalisé avec n importe quelle application et constitué un nouveau module «Appli.Safe» très simple à déployer.safe.safe Generic.Safe Mirror.Safe Scénario de réplication de fichiers et de reprise Étape 1 Étape 2 Étape 3 Étape 4 Configurer les fichiers applicatifs à répliquer. Il n'y a pas de pré requis sur l'organisation disque. Le serveur 1 exécute l'application. Seules les modifications faites par l'application sont répliquées en temps réel à travers le réseau, limitant ainsi le trafic. Les écritures synchrones sur les fichiers sont respectées pour assurer l'intégrité des données (i.e. fichiers en miroir) ; lorsque le serveur 1 est défaillant, la reprise sur le serveur 2 est assurée. A la reprise après panne du serveur 1 (redémarrage du serveur après défaillance), SafeKit re-synchronise automatiquement les fichiers sans perturber l'exécution des applications sur le serveur 2. Seuls les fichiers modifiés sur le serveur 2 pendant l'inactivité du serveur 1 sont re-synchronisés. Après la re-synchronisation, les fichiers sont à nouveau en mode miroir comme à l'étape 1. L'application s'exécute sur le serveur 2. Si l'administrateur souhaite que son application s'exécute sur le serveur 1, il doit exécuter une commande "swap", soit manuellement, soit automatiquement par configuration de la variable "primaire par défaut" avec l'identité du serveur F2 25LT Rev00 12

13 Mixte d'applications en 'ferme' et en 'miroir' Des modules applicatifs 'ferme' et 'miroir' peuvent être mixés sur des serveurs physiques communs. Cette possibilité permet de mettre en œuvre une architecture applicative multi tiers telle que Apache.Safe ('ferme' avec partage de charge et reprise) et mysql.safe (miroir avec réplication de fichiers et reprise) sur seulement deux serveurs exécutant les deux applications. Ainsi, le partage de charge, la réplication de fichiers et la reprise sont mis en œuvre de manière cohérente sur les mêmes serveurs physiques. Ce type d'architecture est propre à SafeKit et unique sur le marché! Figure 7 Mixte de modules applicatifs en 'ferme' et 'miroir' avec répartition de charge, réplication de fichiers et reprise Exemple Apache.Safe (ferme) Apache a besoin d une ferme SafeKit multi modules.safe (miroir) a besoin d un miroir Mixte de manière cohérente partage de charge, répli. de fichiers et reprise. Peut être appliqué à n importe quelle application Dans l'exemple de la figure, pour supporter une montée en charge, nous avons étendu le module 'ferme' Apache.Safe sur 4 serveurs. Mais seulement 2 serveurs sont nécessaires à la mise en œuvre de cette architecture hautement disponible multi tiers. 39 F2 25LT Rev00 13

14 Reprise mutuelle entre 2 serveurs applicatifs Dans une architecture de reprise mutuelle avec 2 serveurs, chaque serveur applicatif est le secours de l'autre serveur applicatif. Figure 8 Reprise mutuelle entre deux serveurs applicatifs avec SafeKit Exemple db1.safe 1 serveur backup inactif tourne sur PRIMAIRE 1 SECONDAIRE 1 db1 a besoin d un miroir SECONDAIRE 2 PRIMAIRE 2 db2 a besoin d un miroir SafeKit multi modules 1 serveur backup inactif tourne sur db2.safe AUCUN serveur inactif : chaque serveur est backup de l autre serveur Peut être appliqué à d autres applications Dans l'exemple de la figure, le module Oracledb1.Safe a une priorité d'exécution sur le premier serveur et le module Oracledb2.Safe a une priorité d'exécution sur le second serveur. Lorsqu'un serveur applicatif est défaillant, les deux applications, Oracledb1 et Oracledb2, sont actives sur le serveur applicatif restant. Et après le redémarrage du serveur défaillant, chaque application est de nouveau active sur son serveur primaire par défaut. Notez que dans une telle architecture, en cas de défaillance d'un serveur, le serveur restant doit supporter la charge des deux applications. 39 F2 25LT Rev00 14

15 N serveurs applicatifs actifs et un seul serveur de secours Dans l'architecture N-1, vous avez N serveurs applicatifs actifs et un seul serveur de secours. Si un des N serveurs applicatifs actifs est défaillant, le serveur de secours redémarre l'application qui tournait sur le serveur défaillant. Quand le serveur défaillant redémarre, l'application bascule du serveur de secours vers son serveur d'origine. Dans le cas d'une panne, contrairement à l'architecture de reprise mutuelle, le serveur de secours n'est pas surchargé par l'exécution de plusieurs applications. Dans le cas particulier de plusieurs pannes simultanées, toutes les applications défaillantes sont redémarrées sur le serveur de secours. Figure 9 Architecture N-1 avec N serveurs applicatifs actifs et 1 seul serveur de secours PRIMAIRE 1 Appli1.Safe Appli1 a besoin d un miroir PRIMAIRE 2 SECONDAIRE 1 Appli2.Safe SECONDAIRE 2 Appli2 a besoin d un miroir SafeKit multi modules PRIMAIRE 3 SECONDAIRE 3 Appli3.Safe Appli3 a besoin d un miroir 3 serveurs backup inactifs 1 serveur backup inactif (secondaire) pour N serveurs actifs (primaire) 39 F2 25LT Rev00 15

16 Quelles organisations utilisent typiquement SafeKit? Équipes de production des systèmes d'information Les équipes de production recherchent des solutions de haute disponibilité simple à administrer dans leurs environnements de production complexes et hétérogènes. A part les grosses bases de données (>100 Goctets), SafeKit est la réponse (un petit produit simple) qui s'applique à Windows, Linux, AIX et Solaris. Un intégrateur de système peut proposer une solution clé en main (produit + service) en intégrant les applications de l'organisation à l'intérieur de SafeKit (création des modules applicatifs ".Safe"). Un de nos clients utilise typiquement SafeKit dans son environnement de production sur 15 applications tournant sur Windows, Linux et AIX. Figure 10 Un exemple SafeKit dans un environnement de production Appli1, Appli2....Safe Apache.Safe Entreprise 15 x Internet, Intranet, job scheduling, message queues, Oracle SafeKit est déployé en tant que solution uniforme de haut disponibilité (multi applications, multi OS) Système d information 39 F2 25LT Rev00 16

17 Grand déploiement d'une solution de haute disponibilité SafeKit permet de concevoir une solution de haute disponibilité avec un grand déploiement. Illustrons cette possibilité avec un exemple récent de déploiement de SafeKit. Une entreprise distribuée en Afrique a choisi SafeKit comme solution de haute disponibilité pour une application critique déployée dans 50 agences. Avec son module applicatif Microsoft SQL Server.Safe, SafeKit a parfaitement répondu au besoin de cette organisation. Aujourd'hui, la solution est déployée sur 100 serveurs Windows standard (serveurs Intel NEC Express5800) avec SafeKit et le module applicatif Microsoft SQL Server.Safe. Notez que dans cette réalisation, la consolidation des 50 bases de données est réalisée sur une base de données centralisée dans un site unique. Un cluster AIX avec disque partagé et la solution Bull ARF met en œuvre la haute disponibilité de cette grosse base de données. Figure 11. Exemple SafeKit avec un grand déploiement.safe 50 x Microsoft SQL Server Une solution miroir protège l application base de données. SafeKit déployé dans 50 agences d une entreprise en Afrique 39 F2 25LT Rev00 17

18 Haute disponibilité et partage de charge de serveurs en lame SafeKit peut être utilisé dans une configuration avec des serveurs en lame. Nous illustrons cette configuration avec l'exemple suivant. Les serveurs Bull NovaScale en lame intègre de 1 à 14 lames Intel x86 dans un même rack. Dans cette offre, SafeKit est tout simplement installé sur chaque lame (Windows ou Linux) et apporte la haute disponibilité et le partage de charge des applications s'exécutant sur les lames. Ainsi, une application en 'ferme' sur plusieurs lames, avec partage de charge réseau et reprise, ne nécessite pas de boîtier supplémentaire de partage de charge de type Nortel Alteon. Et une application 'miroir', avec réplication de fichiers et reprise peut avoir ses fichiers aussi bien localisés sur les disques internes des lames que sur des disques externes. Notez que la solution SafeKit peut s'étendre sur deux racks de lames pour supporter la défaillance d'un rack complet. Figure 12 Exemple SafeKit avec des serveurs en lame... applications en ferme applications en miroir 1 à 14 lames par rack Haute disponibilité et partage de charge des lames 39 F2 25LT Rev00 18

19 Haute disponibilité et résistance au désastre Un système d'information est souvent réparti dans des salles machines éloignées connectées par un réseau LAN étendu. Comme SafeKit se met en œuvre sur un réseau LAN standard, deux serveurs SafeKit dans un mode 'miroir' peuvent être localisés dans deux salles machines distantes. Ainsi, la solution supporte la défaillance totale d'une salle machine avec le redémarrage automatique de l'application dans la seconde salle machine. Les besoins de haute disponibilité et de résistance au désastre sont résolus en même temps. Nous illustrons cette architecture avec un cas client. Des clients dans l'industrie du transport exécutent Oracle et Postgres sur leurs serveurs AIX. SafeKit a été préféré à une solution de type SAN étendu (solution MirrorView d'emc 2 ), car il fournissait des services équivalents à un coût réduit. Les clients ont donc mis en œuvre la solution SafeKit avec des bases de données Oracle et Postgres, toutes les deux inférieures à 100 Giga-octets. Et les deux serveurs AIX sont simplement éloignés dans deux salles machines connectées à un LAN étendu par fibre optique. Figure 13 Exemple SafeKit avec haute disponibilité et résistance au désastre Salles éloignées pour la résistance au désastre LAN étendu SafeKit miroir avec réplication de fichiers et reprise pour des bases de données < 100 Goctets 39 F2 25LT Rev00 19

20 Haute disponibilité et partage de charge d'une suite applicative logicielle AccessMaster est la suite applicative d'evidian spécialisée dans la sécurité des accès et la gestion des identités. L'accès sécurisé à un système d'information est un point fondamental pour une entreprise en terme de haute disponibilité. Tous les utilisateurs de l'entreprise arrêtent leur travail si un serveur de sécurité est surchargé ou si une base de sécurité est défaillante. SafeKit apporte la haute disponibilité et le partage de charge à AccessMaster à tous les étages de son architecture applicative multi tiers, avec des modules 'miroir' et 'ferme' intégrés dans les CD-ROMS d'accessmaster. Figure 14 Exemple SafeKit avec une suite applicative logicielle AccessMaster.Safe > utilisateurs 1 maître module miroir Gestion des utilisateurs... N esclaves module ferme Authentification des utilisateurs dans l entreprise... N passerelles web - mixte de modules ferme/miroir Authentification des utilisateurs Web Toutes ces architectures logicielles SafeKit sont incluses dans les CD-ROMs d AccesMaster! La suite applicative AccessMaster est unique sur le marché pour ses fonctions de haute disponibilité et de partage de charge car : AccessMaster délivre une solution de haute disponibilité uniforme sur toutes les plateformes supportées : AIX, Windows, Linux, Solaris. AccessMaster fournit des modules 'ferme' et 'miroir', suivant le besoin, sur l'ensemble de sa suite applicative. AccessMaster valide et supporte les modules "AccessMaster.Safe" avec sa suite applicative. D'autres suites applicatives peuvent utiliser SafeKit comme un produit OEM les éditeurs logiciel peuvent contacter Evidian. 39 F2 25LT Rev00 20