Socle ENT Université Nancy 2 Journées du CSIESR 31 janvier / 1er février 2005

Architecture logique ESUP SGBD Portail Répartiteur de charge http(s) LDAP ldap Accès réseau CAS https Architecture logique ESUP Les portails sont hébergés sur une ferme de machines identiques. Les utilisateurs accède au portail au travers d’un répartiteur de charge qui rend transparent la délégation du traitement de la requête à une des machines de la ferme Le portail utilise des services tiers : SGBD : une base spécifique au fonctionnement du portail, commune à l’ensemble des machines de la ferme LDAP : utilisé pour la récupération d’attributs utilisateurs qui serviront entre autres à lier l’utilisateur à un groupe uPortal CAS : utilisé pour l’authentification. CAS utilise l’annuaire LDAP comme backend d’authentification WebDAV : utilisé pour le stockage des documents des utilisateurs (espace de stockage personnel) WebDAV http + dav CRI Université Nancy 2 Journées du CSIER : 31/01/2005

Architecture logique ESUP Contenu statique (images, pages HTML, scripts) Apache HTTP(S) 80/443 mod_jk Tomcat AJP13 8009 Architecture logique ESUP Détail du fonctionnement interne d’une des machines de la ferme : Apache en frontal : Meilleures performances pour délivrer des contenus statiques Meilleure sécurité (Tomcat n’est pas capable de fonctionner avec un compte utilisateur restreint si il doit ouvrir des ports < 1024) Meilleure maîtrise et finesse de la configuration Tomcat : Délivre le contenu dynamique Communique avec Apache à l’aide du protocole AJP13 Contenu dynamique CRI Université Nancy 2 Journées du CSIER : 31/01/2005

Architecture recherchée Serveurs : Blade Center ou Pizza Box Load balancing : solution hardware Solution de stockage SAN Infrastructure évolutive Architecture recherchée Récapitulatif des besoins exprimés aux différents constructeurs : Serveurs : Blade Center + lames ou serveurs rackables traditionnels Solution de load balancing hard (switch niveau 7) Solution de stockage rationalisée à la fois pour l’espace de stockage personnel (WebDAV) et des boîtes de messagerie IMAP  SAN Infrastructure évolutive : Déploiement de nouvelles machines pour faire face à la montée en charge, possibilité d’étendre facilement la capacité de stockage CRI Université Nancy 2 Journées du CSIER : 31/01/2005

Solution IBM Blade Center : SAN IBM évolutif Aucune intelligence dans le fond de panier Choix des modules pour les interfaces externes Incorpore jusqu’à 14 lames éventuellement différentes Redondance complète au niveau de la connectivité électrique, réseau et SAN SAN IBM évolutif Solution IBM Blade Center : Fond de panier passif sans intelligence Choix des différents modules d’interconnexion (réseau, SAN) Alimentation électrique entièrement redondante secteur / ondulée Jusqu’à 14 lames dans le blade elles-mêmes modulables pour coller aux besoins spécifiques SAN IBM : Une baie principale équipée de deux contrôleurs Fiber Channel 20 disques durs SCSI Possibilité d’ajouter jusqu’à deux baies esclaves SCSI ou SATA CRI Université Nancy 2 Journées du CSIER : 31/01/2005

Solution Nancy 2 Blade Center : Lames : 1 seul module de management (non critique) Double alimentation secteur / ondulée 2 contrôleurs Fiber Channel Lames : Bi-processeurs Pentium Xeon 3Ghz 2 Go de mémoire 2 disques durs internes SCSI 36 Go en RAID 1 2 interfaces ethernet (optionnel) 2 contrôleurs Fiber Channel Solution Nancy 2 Caractéristiques techniques des éléments choisis par Nancy 2 CRI Université Nancy 2 Journées du CSIER : 31/01/2005

Solution Nancy 2 Réseau : SAN : 2 switchs Nortel Alteon configurables jusqu’à la couche 7 du modèle OSI (load balancing) SAN : IBM Fast T 600 2 contrôleurs Fiber Channel 20 emplacements pour des disques SCSI (10 occupés par des disques 140 Go soit 1 To en ligne en RAID 5) Possibilité d’ajouter deux baies supplémentaires pouvant contenir soit des disques SCSI (performances) soit des disques SATA (prix, volume) Solution Nancy 2 Caractéristiques techniques des éléments choisis par Nancy 2 CRI Université Nancy 2 Journées du CSIER : 31/01/2005

Solution Nancy 2 Switch 220V 1Gb 220V ondulés BLADE SAN Lame Switch Architecture interne des différents éléments (Blade Center, Lames, SAN) Switch CRI Université Nancy 2 Journées du CSIER : 31/01/2005

Installation logicielle Red Hat Enterprise Server Boot PXE (KVM) Serveur DHCP 1 IP 1 nom DNS 1 serveur TFTP (fichier d’amorçage + fichiers de configuration kickstart) Installation automatisée via FTP 1h sans intervention humaine Installation logicielle Installation automatisée d’une Red Hat Enterprise Server sur les lames : Prise en main d’une lame au boot via la console de management pour choisir le boot PXE Au boot, le serveur DHCP fourni les informations suivantes : Nom DNS Adresse IP Serveurs DNS Passerelle Serveur TFTP Le serveur TFTP fourni les informations suivantes : Fichier d’amorçage Fichier d’installation automatisée kickstart Fichier de post-installation L’installation d’une lame prend environ 1h sans qu’à aucun moment une intervention humaine soit nécessaire L’installation simultanée de plusieurs lames est possible CRI Université Nancy 2 Journées du CSIER : 31/01/2005

Installation logicielle Fichier de post-installation : IP et nom DNS fixe (copie des valeurs affectées par DHCP) Bonding Ethernet eth1 bond0 TCP/IP Installation logicielle Le fichier de post-installation réalise les opérations suivantes : Passage en adressage IP fixe. Les informations sont une copies des informations fournies par le premier boot DHCP Installation du pilote de bonding Bonding : Le bonding consiste à mutualiser plusieurs interfaces réseaux sous une interface virtuelle. Le routage entre l’interface et les interfaces réelles permet plusieurs modes de fonctionnement : Fonctionnement agrégé : les deux interfaces fonctionnent simultanément ce qui permet de doubler la bande passante (ce mode nécessite une configuration particulière du commutateur car c’est la même adresse IP qui est exposée avec deux adresses MAC différentes). Fonctionnement en mode esclave : l’adresse IP est exposée sur une seule des deux interfaces. Si celle-ci vient à tomber, alors elle passe en mode NOARP et c’est la deuxième interface qui prend le relais. Dès que la première redevient disponible, elle reprend le travail et l’autre repasse en secours. eth0 CRI Université Nancy 2 Journées du CSIER : 31/01/2005

Configuration SAN Utilisation d’un client tiers 3 étapes : Création d’arrays Création de devices Affectation d’un ou plusieurs devices aux LUN SCSI des lames Installation de RDAC sur les lames Configuration SAN La configuration du SAN s’effectue via un client graphique à installer sur un poste distant. La création d’espaces de stockage passe par 3 étapes : Création d’arrays : ce sont des blocs au sens RAID du terme. Pour du RAID 5, il est nécessaire de disposer d’au minimum 3 disques identiques Création de devices : ils représentent des disques durs virtuels. Ils conservent les propriétés RAID de l’array à laquelle ils appartiennent Affectation des devices aux LUN des lames : le contrôleur Fiber Channel est considéré comme une interface SCSI standard possédant 8 ou 15 LUN SCSI. Il est nécessaire d’associer les devices aux LUN des lames pour qu’ils soient vus comme des disques SCSI locaux. CRI Université Nancy 2 Journées du CSIER : 31/01/2005

Configuration SAN LUN 0 LUN 1 LUN 7 Configuration SAN Explication des 3 étapes CRI Université Nancy 2 Journées du CSIER : 31/01/2005

Configuration SAN BLADE SAN Lame Configuration SAN Utilité du driver RDAC à installer sur les lames. La redondance de connectivité entre les lames et les disques du SAN provoque certains phénomènes particuliers : Chaque device est vu en quadruple par les lames puisqu’il existe 4 chemins différents pour y accéder. RDAC permet de résoudre ce problème en ‘masquant’ 3 des 4 chemins Par défaut les disques du SAN ont la priorité par rapport aux disques internes d’une lame. Si on a installé 4 partitions sur les disques internes pour le système d’exploitation, elles sont nommées sda, sdb, sdc, et sdd. Dès qu’on affecte un device à une lame, les partitions qu’il contient viennent prendre la place des partitions locales qui sont décalées. RDAC résout ce problème en forçant les partitions provenant de devices SAN après les partitions locales. CRI Université Nancy 2 Journées du CSIER : 31/01/2005

Configuration réseau 3 niveaux de configuration : Configuration niveau 2 : VLAN Configuration niveau 3 :adresses IP, trunking, VRRP, internal failover Configuration load-balancing : groupes, vIP, rIP, test de vie, algorithme de répartition de charge Configuration réseau Il est nécessaire de configurer chaque ‘couche’ des switchs Nortel : Couche 2 : configuration des différents VLAN internes au blade Couche 3 : configuration des différentes options propres à IP (VRRP, failover, trunking) Couche 7 : load-balancing CRI Université Nancy 2 Journées du CSIER : 31/01/2005

Configuration réseau l2 int14 eth1 eth0 210 SW2 212 int13 eth1 eth0 4095 MM Configuration réseau couche 2 Chacun des ports internes des switchs doit se voir affecter un VLAN : 210 pour les lames ENT 212 pour la lame serveur IMAP des personnels 4095 pour le VLAN interne exclusivement réservé au module de management (non transporté à l’extérieur du Blade) int1 eth1 eth0 SW1 CRI Université Nancy 2 Journées du CSIER : 31/01/2005

Configuration réseau l3 802.1q int14 eth1 eth0 .20 SW2 int13 eth1 eth0 VRRP 192.168.19.23 MM Configuration réseau couche 3 Les switchs sont configurés de façon à ce que si leur lien externe (noté 802.1q) tombe, leurs ports internes soient désactivés. Ceci permet aux lames via le bonding de changer de switch le temps de la coupure. Les services load-balancés sont associés à une adresse IP virtuelle qui est exposée par un des deux switchs, celui ayant le niveau de priorité le plus élevé. Le switch maître envoie des packets au switch esclave en passant par son interface externe. Si le switch esclave ne reçoit plus ces paquets, il considère que le réseau est rompu entre les deux et expose alors également cette IP virtuelle. A Nancy 2 les deux switchs du blade sont directement connectés au switch d’entrée de site. vIP vIP int1 eth1 eth0 .19 SW1 802.1q CRI Université Nancy 2 Journées du CSIER : 31/01/2005

Configuration réseau lb Définition des ressources réelles dans un groupe : int12, int13 et int14 sont les serveurs réels du groupe 1 Définition d’un test de vie Définition d’un service virtuel Groupe 1 + service HTTP + vIP Client processing, Server processing Configuration réseau couche 7 : load-balancing La création d’une ressource load-balancée passe par plusieurs étapes : Définition des machines réelles qui feront partie du groupe de load-balancing Définition d’un test de vie pour ces machines permettant au switch de savoir si une machine fait toujours partie de celles disponibles. Dans notre cas il s’agit d’un test de vie HTTP qui demande une page spécifique délivrée par Tomcat. Il existe des tests de vie pour les principaux protocoles mais il est également possible d’en écrire de nouveaux sous forme de scripts. Définition d’un service virtuel : il s’agit d’associer un groupe de machines réelles à un service (dans notre cas HTTP mais il pourrait aussi bien s’agir du service IP complet) et à une adresse virtuelle (vIP par opposition aux adresses réelles des machines rIP) Mise en place du server processing (traduction des requêtes vers l’adresse virtuelle en requêtes vers une adresse réelle). Mise en place du client processing (traduction des réponses de l’adresse réelle en réponses de l’adresse virtuelle). CRI Université Nancy 2 Journées du CSIER : 31/01/2005

Configuration réseau lb Méthode de load balancing Minmisses, hash Leastconns Round-robin Response Bandwidth Choix de la persistance Insert cookie Passive cookie Rewrite cookie Configuration réseau couche 7 : load-balancing Deux choses restent à configurer, l’algorithme permettant de décider quelle machine réelle doit traiter une requête s’il s’agit de la première fois que l’utilisateur se connecte au portail et le méthode de persistence par laquelle une fois sa session commencée un utilisateur est maintenu sur la même machine réelle. Algorithmes : Minmisses, hash : calcul en fonction de l’adresse IP source, inutile dans un environnement où sont mis en jeux des proxies. Leastconns : en fonction du nombre de connexions ouvertes par machine, inutile dans le cas de HTTP qui utilise une nouvelle connexion TCP à chaque requête (mode pseudo-connecté) Round-robin : une machine après l’autre Response : machine ayant répondu le plus rapidement au test de vie Bandwitch : machine ayant la bande passante la moins occupée Choix de la persistance : Avec HTTP, la persistance est gérée à l’aide de cookies. Il est possible de définir 3 comportements différents : Insert : le switch ajoute son propre cookie contenant un hachage de la machine réelle utilisée Passive : le switch traque un cookie existant (SESSIONID par exemple). Nécessite le maintien d’une table de correspondance limitée à 300000 entrées Rewrite : le switch écrase les n premiers octets d’un cookie existant avec un hachage de la machine réelle utilisée CRI Université Nancy 2 Journées du CSIER : 31/01/2005

Bilan 3 lames ESUP-Portail (montée en charge progressive) 1 lame SGBD dédié ESUP 1 lame CAS (VIP pour de la tolérance aux pannes) 1 lame FC serveur Slide WebDAV 1 lame FC messagerie du personnel 1 lame FC préinstallée en spare Bilan Récapitulatif de l’architecture complète CRI Université Nancy 2 Journées du CSIER : 31/01/2005

Bilan Installation automatique des lames Administration à distance très efficace Automatisation de la synchronisation des serveurs ESUP à partir d’une lame maître Quelques bugs graphiques au niveau de la prise en main à distance via le KVM Bilan Aspects positifs et négatifs induits par le choix technique effectué CRI Université Nancy 2 Journées du CSIER : 31/01/2005

Evolutions futures Messagerie étudiante : Comme pour la messagerie des personnels, une lame FC dédiée Synchronisation externe du SAN : Projet de sauvegarde mutuelle du SAN entre Nancy 2 et l’UHP Nancy 1 Nécessite une étude technique préalable et l’achat de matériel spécifique (switchs Fiber Channel) Evolutions futures Projets en relation avec cette nouvelle infrastructure CRI Université Nancy 2 Journées du CSIER : 31/01/2005