Le document présente une étude de mutualisation des serveurs visant à optimiser les coûts d'infrastructure et d'administration grâce à la virtualisation et à des solutions techniques adaptées. Une analyse approfondie des besoins, des architectures et des coûts a été réalisée, mettant en avant des gains significatifs sur les ressources et une amélioration de la disponibilité des applications. La conclusion souligne la viabilité du projet et les bénéfices d'une administration simplifiée pour plusieurs équipes.

1. Mutualisation des serveurs Retour d ’exp é rience Bruno PHILIPPE D é cembre 2009

2. Plan de la présentation Introduction Objectifs Etude Architecture & Solutions techniques Normalisation Analyses Conclusion

3. Introduction

4. Introduction Virtualisation Indiscutable actuellement (optimisation, réduction des co ûts ) Pr é sence dans tous les domaines (stockage, os, r é seau, hardware) SUN Diff é rents types de virtualisation (ldom, xen, containers) Virtualisation disponible par dé faut dans Solaris 10 (depuis 2005) Retour d’expé rience Mise en oeuvre dans de grands comptes (secteur industrielle, telecom, etc…) Produits compatible : oracle, sybase, sap, $u, cft, mqm, etc…

5. Introduction

6. Objectifs

7. Objectifs : besoins Réduction des coûts Coûts d ’infrastructure Coûts d ’administration Flexibilité Suppression / Ajout de volumétrie Déplacement aisé des environnements Gestion efficace des ressources Normalisation des environnements D éploiement / Mise à jour Installation aisée des environnements Gestion optimum des clones (facilité + automatisation) Mise à jour rapide des versions de produits (oracle, agent oracle, etc…)

8. Objectifs : besoins Unix Mutualiser les ressources existantes Harmoniser / Normaliser les environnements Simplifier le travail d’administration (pour toutes les équipes) Optimiser la gestion des ressources (diverses types de bases) DBA Reprise d’activité simplifiée (en cas de DRP/PRA) Rafraîchissement des données Tests de charge Regroupement des bases de données par application

9. Etude

10. Etude : périmètre Application ciblée Bases de données Oracle Bases de données Sybase Serveurs connectés au SAN Gamme récente prise en compte (architecture) Le scope représente Moins de 30 serveurs physiques Plus de 100 bases de données

11. Etude : état du parc Scope Architecture sparc Gamme diverse (3 V480 – 2 E450 – 21 V440 – etc…) Vétusté du parc supérieur à 4 ans Faible niveau de disponibilité par serveur SPOF réseau (1 interface) SPOF san (1 carte) SPOF électrique (le plus souvent 1 alimentation)

12. Etude : coût du parc (valeurs prises en compte) Consommation électrique Nombre total de racks utilisés (surface) Nombre de connexions san et réseau Coût en h/j pour différentes opérations

13. Etude : consommation électrique Coût total 1,6 M€ pour 500kva (14 cents pour 1kW/h) 1/3 représente les serveurs 2/3 représente la climatisation Consommation en Watt du scope d'étude Chiffres indiqués par le constructeur 18120 Watt consommés (uniquement les serveurs)

14. Etude : nombre de racks Nombre de U pour le scope d'étude (117 U) Représente 6 racks, explications : Equipements réseaux (3 U) Espacement entre chaque serveur (1 U) Limites électriques des racks (16 A)

15. Etude : nombre de connexions Coût d’une connexion non négligeable Temps CPU sur les équipements Puissance électrique supplémentaire Chaque serveur possède 1 connexion réseau 1 connexion san 1 connexion coûte 1 k€ / an (étude réalisée chez constructeur)

16. Etude : homme jour 1 h/j système correspond à environ 500 € 1 serveur nécessite 5 h/j par an (étude réalisée chez constructeur) Mise à niveau (application des patchs) Incident technique (panne, bug, etc…) Interventions exeptionnelles (arrêt électrique, déménagement, etc..) 125 h/j sur le scope étudié

17. Etude : coût du parc (bilan) (1) : Puissance instantanée du scope x par le coût électrique (14 cents par kW/h) (2) : Etude effectuée chez un constructeur Automobile – 1 connexion réseau ou san coûte 1 k€ / an (3) : Etude effectuée chez un constructeur Automobile - Base de 500 € par h/j – 5 h/j par serveur x le nombre de serveur du scope (25) (4) : Maintenance à 0 € - cependant prise en compte des changements de pièces par an (5) : Augmentation du coût des pièces du à la vetusté du parc (Etude effectuée chez constructeur Automobile)

18. Etude : calibrage des serveurs (procédés) Recherche d'une mesure unique Choix porté sur l’organisme specs.org (1) Utilisation de la mesure SPECint_rate2000 (2) Expression des valeurs CPU : exprimé en valeur absolue Mémoire : exprimé en Gb Chaque serveur obtient une valeur absolue (1) : Organisme indépendant spécialisé dans les mesures de bench serveur (www.specs.org) (2) : Il s'agit d'un bench réservé au calcul brut (compilation, exécution batch, etc...)

19. Etude : calibrage des serveurs (exemples) Observation sur 3 semaines pour les valeurs CPU (en vert) et mémoire (en jaune) SPECint-rate SPECint-rate SPECint-rate SPECint-rate SPECint-rate SPECint-rate Gb Gb Gb Gb Gb Gb (1) : Valeur absolue SPECint_rate donnée par l'organisme specs.org : par ex un V400 obtient une valeur de 40 (2) : Valeur absolue SPECint_rate calculée par serveur (selon la base : moyenne des plus importantes valeurs observées) (3) : Mémoire physique disponible sur le serveur (4) : Mémoire réellement consommée par le serveur (selon la base : moyenne des plus importantes valeurs observées)

20. Etude : schéma cible Architecture redontante Meilleur gestion des ressources Simplicit é des tests de charges Reprise des applications de production SAN Réseau Zone1 Zone2 Zone3 Zone4 Zone5 Zone6 Zone9 Zone8 Zone7 M5000 M5000 M5000

21. Etude : proposition (sécurisation (1)) Sécurisation des accès réseaux Double attachements physiques Configuration logicielle (ipmp) Sécurisation des accès SAN Double attachements physiques Configuration logicielle (mpxio ou powerpath) Sécurisation électrique (muti alimentations) (1) : On atteint un niveau de sécurisation supérieur par rapport à l'ensemble des serveurs standalones Selon la régle de calcul des cinq 9, on obtient une disponibilité équivalente à 99,9 %

22. Etude : proposition (investissements) Achat des serveurs 2 serveurs M5000 + 2 serveurs T5240 450 k€ prix catalogue (sans remise) Contrat de support SUN SILVER h / j pour la mise en place (base de 500€ par h/j) 5 h/j pour l'installation 25 h/j pour la migration (1 h/j par serveur migré) Total 465 k€ + contrat SUN

23. Etude : comparaison des coûts par an Connexion san ou réseau = 1k€ / an 14 cents kW/h x Puissance instantané 1h/j = 500 € Gain 10 k€ Gain 42 k€ Gain 51 k€ Environ 100 k€ de Gain par an 265 h/j 30 h/j (1) (1) : 5 h/j par serveur physique + ½ h/j par zone 50 8

24. Etude : conclusion Diminution des coûts par an (environ 100 k€ / an) Coût matériel / réseaux (san et ethernet) Coût humain ( 30 h/j au lieu de 125 h/j ) Diminution du nombre de racks (2 racks au lieu de 6) Administration améliorée et simplifiée Meilleure disponibilité des applications (99,9)

25. Architecture & Solutions techniques

26. Architecture : schéma globale SITE B SITE A SITE C SITE D DEV 2 types de réplications Oracle Data Guard Recover Point

27. Architecture : schéma site de dev SAN Zone1 Zone2 Zone3 Zone4 Zone5 Zone6 ZG ZG ZG ZG ZG ZG STBY – front STBY – back

28. Solutions techniques : caractéristiques Instance/ Zone globale Instance/ Zone par défaut Gestion des ressources globales (IO, CPU, A llocation m émoire ) Point d’entrée pour la gestion des containers Aucun applicatif pr é sent Containers Instance autonome Utilisation de ressources dédiées Utilisation de produits dédiés et/ou partagés (par ex : binaires oracle) Indé pendante de l’instance globale

29. Solutions techniques : caractéristiques Sécurisation réseau IPMP : configuration active / passive ou active / active Agré gation de liens Type de containers Parse ou Full Zonepath local ou sur SAN Gestionnaires LVM et Systèmes de fichiers Gestionnaires LVM : svm, zfs, vxvm Systèmes de fichiers : ufs, vxfs, zfs filesystems

30. Solutions techniques : caractéristiques Gestion de ressources Choix du scheduler (FSS, TS, etc…) Gestion des CPU (partagée , d é di ée ) Gestion de la mé moire (restriction, projects) Tuning I/O (d é pend du LVM et du syst ème de fichiers ) Gestion du multipathing SAN Gestionnaire inté gr é (mpxio) Gestionnaire spé cifique (powerpath)

31. Solutions techniques : Clone Baie Recopie des données Limitation pour ZFS (pool id unique) Aucune limitation en SVM Fonctionnement 1 ère recopie Full, puis recopie incrémentale Source active lors de la synchro, arrêt de l’activité lors du « split » Destination inactive (démontage au préalable d es systèmes de fichiers) Limitations : 8 clones par source – clone de clone Renommage de la base post-resynchro (DBA)

32. Solutions techniques : clones ZFS SAN /PEGS1 /PEGD1 Refresh occasionnel Mise à jour des bases STBY – front ZG

33. Solutions techniques : clones ZFS Fonctionnalités avancées de ZFS Utilisation des snapshots Envoi des données par send/receive Fonctionnement Recopie uniquement full Source active lors de la synchro, arrêt de l’activité lors du « split » Destination inactive (démontage au préalable du système de fichiers) Limitation : temps de recopie plus long Renommage de la base post-resynchro (DBA)

34. Normalisation

35. Normalisation : caractéristiques Nommage zone globale eqds2xglobxxx Nommage des containers eqdg2dbdxxx Containers de type partagés (parse) Containers hé berg é s sur des disques SAN (flexibilit é ) Systèmes de fichiers pour les containers Montage à partir de /zones/eqdg2dbdxxx (/zones en 755, /zones/zxxx en 700) 1 système de fichiers pour le zonepath 1 système de fichiers par base oracle

36. Normalisation : caract é ristiques Configuration réseau ipmp sur la zone globale (actif / actif) Toutes les zones globales dans le m ême sous r é seau Configuration multipathing san Utilisation de mpxio Tuning spé cifique (forceload ssd, fcp_offline) Gestionnaires LVM et systèmes de fichiers SVM + UFS (bases avec refresh quotidien) ZFS (bases refresh occasionnel) Montages de type lof s (sauf si accès en raw device)

37. Normalisation : caract é ristiques Gestion des CPU Utilisation de FSS Valeur absolue identique pour chaque container et globale Réallocation dynamique possible Gestion de la m é moire Aucune restriction (pas de profil applicatif, uniquement des bases) Limitation par les projets Solaris (un projet par container) Gestion des I/O UFS : larges I/O, buffer cache ZFS : recordsize, cache flush, limitation arc

38. Normalisation : montage lofs /oracle Vue ZG / Containers /oracle Montages chroot é s /zones/eqdg2dbdxxx/root / /data1 /zones/eqdg2dbdxxx/data1 ZG Container

39. Normalisation : binaires oracle Binaires oracle communs entre tous les containers Version d’oracle disponible sur la zone globale Version identique entre toutes les zones globales Systèmes de fichiers pour oracle Montage depuis la zone globale en lofs Montage en RO dans les containers Liens dans /oracle vers /local/oracle pour les modifications locales Avantages Gestions de plusieurs versions d’oracle possible Passage d’une version à une autre simplifiée

40. Normalisations : recopie des binaires SAN /oracle/xx /oracle/xx send / recv R é plication entre ZG ZG ZG

41. Normalisation : gestionnaire ZFS Gestion des pools ZFS 1 Pool pour le container 1 Pool pour chaque base Nommage des pools eqdg2dbdxxdg00 : pool pour le container xxxxdg00 : pool pour la base (xxxx représente le nom de la base) Création de zfs filesystems en montage legacy Le pool ne doit pas être montable Création de volumes dans un pool nommé eqdg2dbdxxdg00/datavol

42. Normalisation : gestionnaire SVM Uniquement pour les datas 1 Meta par base Meta de type concat uniquement si plusieurs luns Nommage des metas (dxxx) Par exemple : d100, d110, d120… xxxxdg00 : pool pour la base (xxxx représente le nom de la base) Montage des metas Montage dans la zone globale (su r veillance + supervision) Montage lofs dans les containers

43. Analyses

44. Analyse : état actuel Contexte 9 serveurs d’hébergement (3 M5000 – 1 E2900 – 3 V890 – 2 T5240) 90 zones disponibles 110 bases Oracle + environ 30 bases Sybase 65% de l’objectif atteint pour le moment Plusieurs bases restent à migrer En attente de nouveaux serveurs d’hébergement (jeux de taquin) Architecture étendue Agrandissement du pé rim ètre pour d’autres projets Acquisition de nouveaux serveurs d’hébergement Architecture x86 en cours de construction

45. Analyse : administration Création d’outils automatisation Scripts d’installation d’une zone Scripts pour des profils spécifiques (Oracle, Sybase) Localisation des containers (en cours) Flexibilité Migration d’une zone (zone attach/detach) Migration d’une base spécifique Maintenances diverses Fort impact (une moyen ne de 20 containers par global) Maintenir tous les serveurs d’hé bergements au m ême niveau (patchs)

46. Analyse : gestion des ressources CPU Contraintes Garantir le temps de traitements Optimiser les ressources CPU Choix du scheduler FSS : minimum garanti (valeur absole) TS : temps partagé Mé thode appliqu é e FSS par dé faut ( point identique pour ZG et chaque container) Pool de CPU pour les bases de bench

47. Analyse : gestion des ressources MEM Contraintes Ré servation d’un espace contigu n é cessaire Dé pend du nombre de connexions utilisateurs Gestion possible Ressources limitées lors de la dé finition du container Ressources gérées pa r les bases Mé thode appliqu é e Pas de limitation pour les containers Limitation dans la configuration des bases Mise en place de projet (par groupe) pour la shm

48. Analyse : gestion des ressources I/O Contraintes Réduction du te mps d’ écriture Utilisation de deux gestionnaires de syst èmes de fichiers Gestion I/O Forte influence des systèmes de fichiers Dé dier ou non l’allocation des ressources I/O aux containers Mé thode appliqu ée Valeur FSS identique entre la zone globale et les containers Montage lof s depuis la globale (sauf pour les raw) ZFS : arc, nocacheflush, prefetch, recordsize UFS : maxphys

49. Analyse : particularit é s des bases Oracle Compte identique pour toutes les bases Paramètre setall (n é cessaire pour UFS) Paramètres sga / pga positionné s (pas de dism) Sybase Paramètres shm positionné s dans les containers Système de fichiers particulier (tempdb en tmpfs) Groupe commun pour toutes les bases

50. Analyse : points divers Clone Suppression des clones ZFS (utilisation de Rman ou outils Sybase) Clone disponible sur les bases en UFS uniquement Ressources Augmentation de la swap Ressource CPU peu utilisé e dans notre contexte (sauf pour Rman) Ressource critique : mémoire Dysfonctionnement mal vé cu par les utilisateurs

51. Conclusion Changement : l’ennemi public Peur du changement A priori des utilisateurs Globalement Projet viable et né cessaire Administration simplifié e pour plusieurs équipes (Unix, DBA) Financi èrement rentable Projet é tendu (ouverture sur d’autres pé rim ètres et d’autres techniques)

52. Questions