Guide WAS Mars WebSphere et Haute Disponibilité

Transcription

1 Guide WAS Mars 2007 WebSphere et Haute Disponibilité Demey Consulting, Luc-Michel Demey demey-consulting.fr

2 Situation initiale WebSphere Network Deployment Fichiers de Configuration Serveur et Applications Authentification HTTPS SOAP Console d'administration Navigateur Serveur de Batch Client WebSphere Scripts WSADMIN Synchronisation Serveur Domino LDAP Authentification HTTPS Utilisateur Intranet Navigateur WebSphere Base Node Agent Fichiers de Configuration Serveur + Applications Container Web Serveur IHS Plugin WebSphere Client DB2 HTTP HTTP DMZ Reverse Proxy HTTPS SA bd01p SA bd02p Serveur MQ Clients Extranets Navigateur

3 Situation actuelle IHS, WAS, WMQ colocalisés Sur un serveur Windows WAS en version 5.02, WMQ en version 5.2/5.3 Problèmes Fin de vie WAS & WMQ Instabilité Limite JVM 2 Go (32 bits) Croissance forte à prévoir Besoin d améliorer la disponibilité

4 Mode opératoire du projet Inventaire de l existant et des besoins Etude des solutions techniques et chemins de migration Prototypage des solutions retenues (maquette) Choix des composants et des versions Validation de l architecture Déploiement Environnement recette Environnement intégration Environnement Pré-production Environnement Production Choix & mise en place d outils d administration

5 Définition de la Haute Disponibilité Haute Disponibilité : Terme à définir, dépend du contexte fonctionnel Proposition : Vu du partenaire, Persistance du service Maintien des données de session et des flux en cours de transfert

6 SLA & Objectifs Un SLA permet de justifier des investissements dans la Haute Disponibilité Objectif théorique : 24x7 24 h sur 24, 7 jours sur 7? Quelle indisponibilité (non planifiée) peut-on accepter? Disponibilité de 99 % 3,5 jours d arrêt d par an Disponibilité de 99.9 % 8,5 heures d arrêt d par an Disponibilité de % 50 minutes d arrêt d par an Disponibilité de % 5 minutes d arrêt d par an Disponibilité de % 30 secondes d arrêt d par an

7 Chronogramme Incident Décision de bascule Reprise des opérations Fonctionnement normal Indisponibilité Bascule Fonctionnement normal Bascule retour Détection

8 Postulats & Best Practices Postulats Plus il y a de composants, plus une architecture est vulnérable du point de vue HA. La fiabilité d une plate-forme est déterminée par la fiabilité du composant le moins robuste. La vulnérabilité peut provenir des logiciels comme du matériel. Plus un matériel héberge de composants plus il devient vulnérable. Les composants d'administration ne nécessitent pas d être rendus robuste. Best practices Limiter le nombre de composants. Distinguer les composants d administration des autres. Séparer les composants en compétition pour les mêmes ressources. Positionner les éléments redondés sur des serveurs physiques distincts

9 Modes d utilisation Le mode Principal / Secours (Actif / Passif) MaintienMaintien d un clone de chaque composant en sommeil.. Le «réveil» n est déclenché qu en cas de besoin. Interruption de service pendant la bascule Composant inutilisé en service normal Le mode traitement réparti (Actif /Actif) Fonctionnement avec une charge répartie sur l ensemble de l infrastructure. En En cas de défaillance, l infrastructure ne bénéficie plus que d une partie des ressources. Plus Plus complexe à installer et administrer La répartition de charge réseau entre serveurs d application peut être assurée par trois modes Répartition matérielle Répartition par adresse IP Répartition par logiciel

10 Exemple (DMZ actuelle) WebSphere Edge Components DISPATCHER (Secours) REVERSE PROXY VIP adresse IP virtuelle Répartition logicielle mode Principal/Secours mode traitement réparti DISPATCHER (Actif) REVERSE PROXY

11 Répartiteurs, Serveurs Web et Conteneur J2EE IHS & WebSphere Applicaton Server SERVEUR IHS PLUGIN WEBSHERE Container Web Container EJB Load Balancer Dispatcher répartition logicielle mode traitement réparti mode traitement réparti SERVEUR IHS PLUGIN WEBSPHERE Container Web Container EJB

12 Principes Haute Disponibilité Séparer chaque fonction Rendre hautement disponible chaque fonction Load Balancer Reverse proxy Serveur HTTP Container Web Queue Manager Bases DB2 Annuaire (ITDS) Gérer les liens croisés entre les étages

13 Load Balancer, Reverse Proxy & HTTP Load Balancer Accédé via une VIP (gérée par un Site Selector) Reverse proxy + Site Selector Actif / Passif Site Selector pour tester la disponibilité de l HTTP Serveur HTTP IHS 6.1 Actif / Actif Répartition vers les container Web avec le Plug-In LB, SS, et IHS colocalisés LB SS Linux RH 4.2 IH S Container W eb VIP LB SS Linux RH 4.2 IH S Container W eb

14 Container Web IHS IHS ND 6.1 Win WAS 6.1 Win WAS 6.1 Win

15 Le Messaging Engine WAS 6 Le Messaging Engine (ME) apporte les fonctions de Haute Disponibilité au socle de messaging Application J2EE Vu, de manière externe, comme un Queue Manager S exécute sur un node du serveur d application Bénéficie des services du HA Manager Redémarre automatiquement sur un autre node si nécessaire Stockage des messages dans un file system (comme MQ) ou via une datasource

16 Liaison WMQ - Messaging Engine Serveur Queue Manager Application Messaging Engine Xmitq Queue locale

17 Liaison WMQ - Messaging Engine Adresse IP 1 Node WAS 1 Serveur ME Partenaire Queue Manager Données ME Node WAS 2? ME Partenaire Adresse IP 2 Cluster WAS

18 Liaison WMQ - Messaging Engine Adresse IP 1 Node WAS 1 ME Partenaire Serveur Données ME Node WAS 2 MR01 Queue Manager ME Partenaire Adresse IP 2 Cluster WAS

19 Haute disponibilité WMQ Serveur 1 Messaging Engine QMA Disque partagé Données QMA Serveur 2 QMA Xmitq Queue locale

20 DB2 HADR (High( Availability Disaster Recovery) Pas d impact sur les applications J2EE existantes Nécessite une license DB2 ESE Serveur DB2 secondaire WebSphere Base 6.0.x Container Web SA me01p SA me02p... Datasources Automatic Reroute Instances DB2 HADR SAN Données Driver db2 java Connexions Serveur DB2 primaire Instances DB

21 Annuaire ITDS ITDS Master DB2 Win ITDS Slave DB2 Win

22 Aspect Matériel Augmentation du nombre d environnements Augmentation TRES importante du nombre de serveurs Certains serveurs seront très peu utilisés Gestion du Hardware Solution : Partitionnement Serveurs lames

23 Partitionnement des serveurs Applications Applications Applications Windows 2003 CPU - Mémoire - Réseau - Disque Windows 2003 Adv CPU - Mémoire - Réseau - Disque Linux CPU - Mémoire - Réseau - Disque Console OS Logiciel VmWare Virtualisation Architecture x

24 Solution matériel Architecture à lames + partitionnement VMWare ESX Tranches de lames Win pour : DM ITDS DB/2 WMQ Lames Win natives pour WAS baies de lames dans 2 salles dans 2 lieux Cluster Windows MSCS pour WMQ

25 Nouvelle architecture v1s06 VIP v1x61 v1x62 v1x66 ITDS Master DB2 Win CPU = 1 Mem = 2 DD = 70 v1x65 ITDS Slave DB2 Win LB SS Linux RH 4.2 IHS v1x68 WAS 6.1 Win CPU = 1 Mem = 2 DD = 30 CPU = 4 Mem = 16 DD = 300 LB SS Linux RH 4.2 IHS v1x69 WAS 6.1 Win v1x67 ND 6.1 Win CPU = 1 Mem = 2 DD = 30 Messaging Engine (5570) v1x6a CPU = 1 Mem = 2 DD = 70 DB2 ME ESE Actif Win v1x6b DB2 ME ESE Passif Win v1x6c MQ Gateway Actif Win CPU = 1 Mem = 2 DD = 40 VIP v1x6d MQ Gateway Passif Win Queue Manager sur MSCS IBMA1 t4fd8 QM : MA01 MQ distribué MVS

26 Documents Clustering and high availability in an enterprise service bus, white paper (G ) Redbook : WebSphere MQ V6 Fundamentals Redbook : WebSphere Application Server V6 : WebSphere Application Server V6 Scalability and Performance Handbook Understanding high availability with WebSphere MQ ibm.com/developerworks/websphere/library/techarticles/ 0505_hiscock/0505_hiscock.html