Mutualisation des serveurs Retour d ’exp é rience Bruno PHILIPPE D é cembre 2009
Plan de la présentation <ul><li>Introduction </li></ul><ul><li>Objectifs </li></ul><ul><li>Etude </li></ul><ul><li>Archite...
Introduction
Introduction <ul><li>Virtualisation </li></ul><ul><ul><ul><li>Indiscutable actuellement (optimisation, réduction des  co û...
Introduction
Objectifs
Objectifs :  besoins <ul><li>Réduction des coûts </li></ul><ul><ul><ul><li>Coûts d ’infrastructure </li></ul></ul></ul><ul...
Objectifs :  besoins <ul><li>Unix </li></ul><ul><ul><ul><li>Mutualiser les ressources existantes </li></ul></ul></ul><ul><...
Etude
Etude : périmètre <ul><li>Application ciblée </li></ul><ul><ul><ul><li>Bases de données Oracle </li></ul></ul></ul><ul><ul...
Etude :  état du parc <ul><li>Scope </li></ul><ul><ul><ul><li>Architecture sparc </li></ul></ul></ul><ul><ul><ul><li>Gamme...
Etude  :  coût du parc   (valeurs prises en compte) <ul><li>Consommation électrique </li></ul><ul><li>Nombre total de rack...
Etude  :  consommation électrique <ul><li>Coût total </li></ul><ul><ul><ul><li>1,6 M€ pour 500kva (14 cents pour 1kW/h) </...
Etude :  nombre de racks <ul><li>Nombre de U pour le scope d'étude  (117 U) </li></ul><ul><li>Représente 6 racks, explicat...
Etude  :  nombre de connexions <ul><li>Coût d’une connexion non négligeable </li></ul><ul><ul><ul><li>Temps CPU sur les éq...
Etude  :  homme jour <ul><li>1 h/j système correspond à environ 500 € </li></ul><ul><li>1 serveur nécessite 5 h/j par an  ...
Etude :  coût du parc   (bilan) (1) : Puissance instantanée du scope x par le coût électrique (14 cents par kW/h) (2) : Et...
Etude :  calibrage des serveurs   (procédés) <ul><li>Recherche d'une mesure unique </li></ul><ul><ul><ul><li>Choix porté s...
Etude :  calibrage des serveurs   (exemples) Observation sur 3 semaines pour les valeurs CPU (en vert) et mémoire (en jaun...
Etude :  schéma cible <ul><li>Architecture redontante </li></ul><ul><li>Meilleur gestion des ressources </li></ul><ul><li>...
Etude :  proposition   (sécurisation (1)) <ul><li>Sécurisation des accès réseaux </li></ul><ul><ul><ul><li>Double attachem...
Etude :  proposition  (investissements) <ul><li>Achat des serveurs </li></ul><ul><ul><ul><li>2 serveurs M5000 + 2 serveurs...
Etude  : comparaison des coûts par an Connexion san ou réseau = 1k€ / an 14 cents kW/h x Puissance instantané 1h/j = 500 €...
Etude :  conclusion <ul><li>Diminution des coûts par an  (environ 100 k€ / an) </li></ul><ul><ul><ul><li>Coût matériel / r...
Architecture & Solutions techniques
Architecture :  schéma globale SITE B SITE A SITE C SITE D DEV 2 types de réplications Oracle Data Guard Recover Point
Architecture :  schéma site de dev SAN Zone1 Zone2 Zone3 Zone4 Zone5 Zone6 ZG ZG ZG ZG ZG ZG STBY – front STBY – back
Solutions techniques :  caractéristiques <ul><li>Instance/ Zone  globale </li></ul><ul><ul><ul><li>Instance/ Zone  par déf...
Solutions techniques :  caractéristiques <ul><li>Sécurisation réseau </li></ul><ul><ul><ul><li>IPMP : configuration active...
Solutions techniques :  caractéristiques <ul><li>Gestion de ressources </li></ul><ul><ul><ul><li>Choix du scheduler (FSS, ...
Solutions techniques :  Clone Baie <ul><li>Recopie des  données </li></ul><ul><ul><ul><li>Limitation pour ZFS (pool id uni...
Solutions techniques :  clones ZFS SAN /PEGS1 /PEGD1 Refresh occasionnel Mise à jour des bases STBY – front ZG
Solutions techniques :  clones ZFS <ul><li>Fonctionnalités avancées de ZFS </li></ul><ul><ul><ul><li>Utilisation des snaps...
Normalisation
Normalisation :  caractéristiques <ul><li>Nommage zone globale eqds2xglobxxx </li></ul><ul><li>Nommage des containers eqdg...
Normalisation  :   caract é ristiques <ul><li>Configuration réseau </li></ul><ul><ul><ul><li>ipmp sur la zone globale (act...
Normalisation  :   caract é ristiques <ul><li>Gestion des CPU </li></ul><ul><ul><ul><li>Utilisation de FSS </li></ul></ul>...
Normalisation :  montage lofs /oracle Vue ZG / Containers /oracle Montages chroot é s /zones/eqdg2dbdxxx/root / /data1 /zo...
Normalisation : binaires oracle <ul><li>Binaires oracle communs entre tous les containers </li></ul><ul><ul><ul><li>Versio...
Normalisations :  recopie des binaires SAN /oracle/xx /oracle/xx send / recv R é plication entre ZG ZG ZG
Normalisation :  gestionnaire ZFS <ul><li>Gestion des pools ZFS </li></ul><ul><ul><ul><li>1 Pool pour le container </li></...
Normalisation :  gestionnaire SVM <ul><li>Uniquement pour les datas </li></ul><ul><ul><ul><li>1 Meta par base </li></ul></...
Analyses
Analyse :  état actuel <ul><li>Contexte </li></ul><ul><ul><ul><li>9 serveurs d’hébergement (3 M5000 – 1 E2900 – 3 V890 – 2...
Analyse :  administration <ul><li>Création d’outils automatisation </li></ul><ul><ul><ul><li>Scripts d’installation d’une ...
Analyse :  gestion des ressources CPU <ul><li>Contraintes </li></ul><ul><ul><ul><li>Garantir le temps de traitements </li>...
Analyse :  gestion des ressources MEM <ul><li>Contraintes </li></ul><ul><ul><ul><li>Ré servation d’un espace contigu n é c...
Analyse :  gestion des ressources I/O <ul><li>Contraintes </li></ul><ul><ul><ul><li>Réduction du   te mps d’ écriture </li...
Analyse :  particularit é s des bases <ul><li>Oracle </li></ul><ul><ul><ul><li>Compte identique pour toutes les bases </li...
Analyse :  points divers <ul><li>Clone </li></ul><ul><ul><ul><li>Suppression des clones ZFS (utilisation de Rman ou outils...
Conclusion <ul><li>Changement : l’ennemi public </li></ul><ul><ul><ul><li>Peur du changement </li></ul></ul></ul><ul><ul><...
Questions
Prochain SlideShare
Chargement dans…5
×

Mutualisation sous Solaris

1 713 vues

Publié le

Retour d\'expérience sur la mutualisation des ressources bases de données Oracle dans des containers Solaris. Présentation pour le GUSES

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 713
Sur SlideShare
0
Issues des intégrations
0
Intégrations
3
Actions
Partages
0
Téléchargements
19
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Mutualisation sous Solaris

  1. 1. Mutualisation des serveurs Retour d ’exp é rience Bruno PHILIPPE D é cembre 2009
  2. 2. Plan de la présentation <ul><li>Introduction </li></ul><ul><li>Objectifs </li></ul><ul><li>Etude </li></ul><ul><li>Architecture & Solutions techniques </li></ul><ul><li>Normalisation </li></ul><ul><li>Analyses </li></ul><ul><li>Conclusion </li></ul>
  3. 3. Introduction
  4. 4. Introduction <ul><li>Virtualisation </li></ul><ul><ul><ul><li>Indiscutable actuellement (optimisation, réduction des co ûts ) </li></ul></ul></ul><ul><ul><ul><li>Pr é sence dans tous les domaines (stockage, os, r é seau, hardware) </li></ul></ul></ul><ul><li>SUN </li></ul><ul><ul><ul><li>Diff é rents types de virtualisation (ldom, xen, containers) </li></ul></ul></ul><ul><ul><ul><li>Virtualisation disponible par dé faut dans Solaris 10 (depuis 2005) </li></ul></ul></ul><ul><li>Retour d’expé rience </li></ul><ul><ul><ul><li>Mise en oeuvre dans de grands comptes (secteur industrielle, telecom, etc…) </li></ul></ul></ul><ul><ul><ul><li>Produits compatible : oracle, sybase, sap, $u, cft, mqm, etc… </li></ul></ul></ul>
  5. 5. Introduction
  6. 6. Objectifs
  7. 7. Objectifs : besoins <ul><li>Réduction des coûts </li></ul><ul><ul><ul><li>Coûts d ’infrastructure </li></ul></ul></ul><ul><ul><ul><li>Coûts d ’administration </li></ul></ul></ul><ul><li>Flexibilité </li></ul><ul><ul><ul><li>Suppression / Ajout de volumétrie </li></ul></ul></ul><ul><ul><ul><li>Déplacement aisé des environnements </li></ul></ul></ul><ul><ul><ul><li>Gestion efficace des ressources </li></ul></ul></ul><ul><ul><ul><li>Normalisation des environnements </li></ul></ul></ul><ul><li>D éploiement / Mise à jour </li></ul><ul><ul><ul><li>Installation aisée des environnements </li></ul></ul></ul><ul><ul><ul><li>Gestion optimum des clones (facilité + automatisation) </li></ul></ul></ul><ul><ul><ul><li>Mise à jour rapide des versions de produits (oracle, agent oracle, etc…) </li></ul></ul></ul>
  8. 8. Objectifs : besoins <ul><li>Unix </li></ul><ul><ul><ul><li>Mutualiser les ressources existantes </li></ul></ul></ul><ul><ul><ul><li>Harmoniser / Normaliser les environnements </li></ul></ul></ul><ul><ul><ul><li>Simplifier le travail d’administration (pour toutes les équipes) </li></ul></ul></ul><ul><ul><ul><li>Optimiser la gestion des ressources (diverses types de bases) </li></ul></ul></ul><ul><li>DBA </li></ul><ul><ul><ul><li>Reprise d’activité simplifiée (en cas de DRP/PRA) </li></ul></ul></ul><ul><ul><ul><li>Rafraîchissement des données </li></ul></ul></ul><ul><ul><ul><li>Tests de charge </li></ul></ul></ul><ul><ul><ul><li>Regroupement des bases de données par application </li></ul></ul></ul>
  9. 9. Etude
  10. 10. Etude : périmètre <ul><li>Application ciblée </li></ul><ul><ul><ul><li>Bases de données Oracle </li></ul></ul></ul><ul><ul><ul><li>Bases de données Sybase </li></ul></ul></ul><ul><li>Serveurs connectés au SAN </li></ul><ul><li>Gamme récente prise en compte (architecture) </li></ul><ul><li>Le scope représente </li></ul><ul><ul><ul><li>Moins de 30 serveurs physiques </li></ul></ul></ul><ul><ul><ul><li>Plus de 100 bases de données </li></ul></ul></ul>
  11. 11. Etude : état du parc <ul><li>Scope </li></ul><ul><ul><ul><li>Architecture sparc </li></ul></ul></ul><ul><ul><ul><li>Gamme diverse (3 V480 – 2 E450 – 21 V440 – etc…) </li></ul></ul></ul><ul><li>Vétusté du parc supérieur à 4 ans </li></ul><ul><li>Faible niveau de disponibilité par serveur </li></ul><ul><ul><ul><li>SPOF réseau (1 interface) </li></ul></ul></ul><ul><ul><ul><li>SPOF san (1 carte) </li></ul></ul></ul><ul><ul><ul><li>SPOF électrique (le plus souvent 1 alimentation) </li></ul></ul></ul>
  12. 12. Etude : coût du parc (valeurs prises en compte) <ul><li>Consommation électrique </li></ul><ul><li>Nombre total de racks utilisés (surface) </li></ul><ul><li>Nombre de connexions san et réseau </li></ul><ul><li>Coût en h/j pour différentes opérations </li></ul>
  13. 13. Etude : consommation électrique <ul><li>Coût total </li></ul><ul><ul><ul><li>1,6 M€ pour 500kva (14 cents pour 1kW/h) </li></ul></ul></ul><ul><ul><ul><li>1/3 représente les serveurs </li></ul></ul></ul><ul><ul><ul><li>2/3 représente la climatisation </li></ul></ul></ul><ul><li>Consommation en Watt du scope d'étude </li></ul><ul><ul><ul><li>Chiffres indiqués par le constructeur </li></ul></ul></ul><ul><ul><ul><li>18120 Watt consommés (uniquement les serveurs) </li></ul></ul></ul>
  14. 14. Etude : nombre de racks <ul><li>Nombre de U pour le scope d'étude (117 U) </li></ul><ul><li>Représente 6 racks, explications : </li></ul><ul><ul><ul><li>Equipements réseaux (3 U) </li></ul></ul></ul><ul><ul><ul><li>Espacement entre chaque serveur (1 U) </li></ul></ul></ul><ul><ul><ul><li>Limites électriques des racks (16 A) </li></ul></ul></ul>
  15. 15. Etude : nombre de connexions <ul><li>Coût d’une connexion non négligeable </li></ul><ul><ul><ul><li>Temps CPU sur les équipements </li></ul></ul></ul><ul><ul><ul><li>Puissance électrique supplémentaire </li></ul></ul></ul><ul><li>Chaque serveur possède </li></ul><ul><ul><ul><li>1 connexion réseau </li></ul></ul></ul><ul><ul><ul><li>1 connexion san </li></ul></ul></ul><ul><li>1 connexion coûte 1 k€ / an (étude réalisée chez constructeur) </li></ul>
  16. 16. Etude : homme jour <ul><li>1 h/j système correspond à environ 500 € </li></ul><ul><li>1 serveur nécessite 5 h/j par an (étude réalisée chez constructeur) </li></ul><ul><ul><ul><li>Mise à niveau (application des patchs) </li></ul></ul></ul><ul><ul><ul><li>Incident technique (panne, bug, etc…) </li></ul></ul></ul><ul><ul><ul><li>Interventions exeptionnelles (arrêt électrique, déménagement, etc..) </li></ul></ul></ul><ul><li>125 h/j sur le scope étudié </li></ul>
  17. 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. 18. Etude : calibrage des serveurs (procédés) <ul><li>Recherche d'une mesure unique </li></ul><ul><ul><ul><li>Choix porté sur l’organisme specs.org (1) </li></ul></ul></ul><ul><ul><ul><li>Utilisation de la mesure SPECint_rate2000 (2) </li></ul></ul></ul><ul><li>Expression des valeurs </li></ul><ul><ul><ul><li>CPU : exprimé en valeur absolue </li></ul></ul></ul><ul><ul><ul><li>Mémoire : exprimé en Gb </li></ul></ul></ul><ul><li>Chaque serveur obtient une valeur absolue </li></ul>(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. 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. 20. Etude : schéma cible <ul><li>Architecture redontante </li></ul><ul><li>Meilleur gestion des ressources </li></ul><ul><li>Simplicit é des tests de charges </li></ul><ul><li>Reprise des applications de production </li></ul>SAN Réseau Zone1 Zone2 Zone3 Zone4 Zone5 Zone6 Zone9 Zone8 Zone7 M5000 M5000 M5000
  21. 21. Etude : proposition (sécurisation (1)) <ul><li>Sécurisation des accès réseaux </li></ul><ul><ul><ul><li>Double attachements physiques </li></ul></ul></ul><ul><ul><ul><li>Configuration logicielle (ipmp) </li></ul></ul></ul><ul><li>Sécurisation des accès SAN </li></ul><ul><ul><ul><li>Double attachements physiques </li></ul></ul></ul><ul><ul><ul><li>Configuration logicielle (mpxio ou powerpath) </li></ul></ul></ul><ul><li>Sécurisation électrique (muti alimentations) </li></ul>(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. 22. Etude : proposition (investissements) <ul><li>Achat des serveurs </li></ul><ul><ul><ul><li>2 serveurs M5000 + 2 serveurs T5240 </li></ul></ul></ul><ul><ul><ul><li>450 k€ prix catalogue (sans remise) </li></ul></ul></ul><ul><ul><ul><li>Contrat de support SUN SILVER </li></ul></ul></ul><ul><li>h / j pour la mise en place (base de 500€ par h/j) </li></ul><ul><ul><ul><li>5 h/j pour l'installation </li></ul></ul></ul><ul><ul><ul><li>25 h/j pour la migration (1 h/j par serveur migré) </li></ul></ul></ul><ul><li>Total 465 k€ + contrat SUN </li></ul>
  23. 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. 24. Etude : conclusion <ul><li>Diminution des coûts par an (environ 100 k€ / an) </li></ul><ul><ul><ul><li>Coût matériel / réseaux (san et ethernet) </li></ul></ul></ul><ul><ul><ul><li>Coût humain ( 30 h/j au lieu de 125 h/j ) </li></ul></ul></ul><ul><li>Diminution du nombre de racks (2 racks au lieu de 6) </li></ul><ul><li>Administration améliorée et simplifiée </li></ul><ul><li>Meilleure disponibilité des applications (99,9) </li></ul>
  25. 25. Architecture & Solutions techniques
  26. 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. 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. 28. Solutions techniques : caractéristiques <ul><li>Instance/ Zone globale </li></ul><ul><ul><ul><li>Instance/ Zone par défaut </li></ul></ul></ul><ul><ul><ul><li>Gestion des ressources globales (IO, CPU, A llocation m émoire ) </li></ul></ul></ul><ul><ul><ul><li>Point d’entrée pour la gestion des containers </li></ul></ul></ul><ul><ul><ul><li>Aucun applicatif pr é sent </li></ul></ul></ul><ul><li>Containers </li></ul><ul><ul><ul><li>Instance autonome </li></ul></ul></ul><ul><ul><ul><li>Utilisation de ressources dédiées </li></ul></ul></ul><ul><ul><ul><li>Utilisation de produits dédiés et/ou partagés (par ex : binaires oracle) </li></ul></ul></ul><ul><ul><ul><li>Indé pendante de l’instance globale </li></ul></ul></ul>
  29. 29. Solutions techniques : caractéristiques <ul><li>Sécurisation réseau </li></ul><ul><ul><ul><li>IPMP : configuration active / passive ou active / active </li></ul></ul></ul><ul><ul><ul><li>Agré gation de liens </li></ul></ul></ul><ul><li>Type de containers </li></ul><ul><ul><ul><li>Parse ou Full </li></ul></ul></ul><ul><ul><ul><li>Zonepath local ou sur SAN </li></ul></ul></ul><ul><li>Gestionnaires LVM et Systèmes de fichiers </li></ul><ul><ul><ul><li>Gestionnaires LVM : svm, zfs, vxvm </li></ul></ul></ul><ul><ul><ul><li>Systèmes de fichiers : ufs, vxfs, zfs filesystems </li></ul></ul></ul>
  30. 30. Solutions techniques : caractéristiques <ul><li>Gestion de ressources </li></ul><ul><ul><ul><li>Choix du scheduler (FSS, TS, etc…) </li></ul></ul></ul><ul><ul><ul><li>Gestion des CPU (partagée , d é di ée ) </li></ul></ul></ul><ul><ul><ul><li>Gestion de la mé moire (restriction, projects) </li></ul></ul></ul><ul><ul><ul><li>Tuning I/O (d é pend du LVM et du syst ème de fichiers ) </li></ul></ul></ul><ul><li>Gestion du multipathing SAN </li></ul><ul><ul><ul><li>Gestionnaire inté gr é (mpxio) </li></ul></ul></ul><ul><ul><ul><li>Gestionnaire spé cifique (powerpath) </li></ul></ul></ul>
  31. 31. Solutions techniques : Clone Baie <ul><li>Recopie des données </li></ul><ul><ul><ul><li>Limitation pour ZFS (pool id unique) </li></ul></ul></ul><ul><ul><ul><li>Aucune limitation en SVM </li></ul></ul></ul><ul><li>Fonctionnement </li></ul><ul><ul><ul><li>1 ère recopie Full, puis recopie incrémentale </li></ul></ul></ul><ul><ul><ul><li>Source active lors de la synchro, arrêt de l’activité lors du « split » </li></ul></ul></ul><ul><ul><ul><li>Destination inactive (démontage au préalable d es systèmes de fichiers) </li></ul></ul></ul><ul><li>Limitations : 8 clones par source – clone de clone </li></ul><ul><li>Renommage de la base post-resynchro (DBA) </li></ul>
  32. 32. Solutions techniques : clones ZFS SAN /PEGS1 /PEGD1 Refresh occasionnel Mise à jour des bases STBY – front ZG
  33. 33. Solutions techniques : clones ZFS <ul><li>Fonctionnalités avancées de ZFS </li></ul><ul><ul><ul><li>Utilisation des snapshots </li></ul></ul></ul><ul><ul><ul><li>Envoi des données par send/receive </li></ul></ul></ul><ul><li>Fonctionnement </li></ul><ul><ul><ul><li>Recopie uniquement full </li></ul></ul></ul><ul><ul><ul><li>Source active lors de la synchro, arrêt de l’activité lors du « split » </li></ul></ul></ul><ul><ul><ul><li>Destination inactive (démontage au préalable du système de fichiers) </li></ul></ul></ul><ul><li>Limitation : temps de recopie plus long </li></ul><ul><li>Renommage de la base post-resynchro (DBA) </li></ul>
  34. 34. Normalisation
  35. 35. Normalisation : caractéristiques <ul><li>Nommage zone globale eqds2xglobxxx </li></ul><ul><li>Nommage des containers eqdg2dbdxxx </li></ul><ul><li>Containers de type partagés (parse) </li></ul><ul><li>Containers hé berg é s sur des disques SAN (flexibilit é ) </li></ul><ul><li>Systèmes de fichiers pour les containers </li></ul><ul><ul><ul><li>Montage à partir de /zones/eqdg2dbdxxx (/zones en 755, /zones/zxxx en 700) </li></ul></ul></ul><ul><ul><ul><li>1 système de fichiers pour le zonepath </li></ul></ul></ul><ul><ul><ul><li>1 système de fichiers par base oracle </li></ul></ul></ul>
  36. 36. Normalisation : caract é ristiques <ul><li>Configuration réseau </li></ul><ul><ul><ul><li>ipmp sur la zone globale (actif / actif) </li></ul></ul></ul><ul><ul><ul><li>Toutes les zones globales dans le m ême sous r é seau </li></ul></ul></ul><ul><li>Configuration multipathing san </li></ul><ul><ul><ul><li>Utilisation de mpxio </li></ul></ul></ul><ul><ul><ul><li>Tuning spé cifique (forceload ssd, fcp_offline) </li></ul></ul></ul><ul><li>Gestionnaires LVM et systèmes de fichiers </li></ul><ul><ul><ul><li>SVM + UFS (bases avec refresh quotidien) </li></ul></ul></ul><ul><ul><ul><li>ZFS (bases refresh occasionnel) </li></ul></ul></ul><ul><li>Montages de type lof s (sauf si accès en raw device) </li></ul>
  37. 37. Normalisation : caract é ristiques <ul><li>Gestion des CPU </li></ul><ul><ul><ul><li>Utilisation de FSS </li></ul></ul></ul><ul><ul><ul><li>Valeur absolue identique pour chaque container et globale </li></ul></ul></ul><ul><ul><ul><li>Réallocation dynamique possible </li></ul></ul></ul><ul><li>Gestion de la m é moire </li></ul><ul><ul><ul><li>Aucune restriction (pas de profil applicatif, uniquement des bases) </li></ul></ul></ul><ul><ul><ul><li>Limitation par les projets Solaris (un projet par container) </li></ul></ul></ul><ul><li>Gestion des I/O </li></ul><ul><ul><ul><li>UFS : larges I/O, buffer cache </li></ul></ul></ul><ul><ul><ul><li>ZFS : recordsize, cache flush, limitation arc </li></ul></ul></ul>
  38. 38. Normalisation : montage lofs /oracle Vue ZG / Containers /oracle Montages chroot é s /zones/eqdg2dbdxxx/root / /data1 /zones/eqdg2dbdxxx/data1 ZG Container
  39. 39. Normalisation : binaires oracle <ul><li>Binaires oracle communs entre tous les containers </li></ul><ul><ul><ul><li>Version d’oracle disponible sur la zone globale </li></ul></ul></ul><ul><ul><ul><li>Version identique entre toutes les zones globales </li></ul></ul></ul><ul><li>Systèmes de fichiers pour oracle </li></ul><ul><ul><ul><li>Montage depuis la zone globale en lofs </li></ul></ul></ul><ul><ul><ul><li>Montage en RO dans les containers </li></ul></ul></ul><ul><ul><ul><li>Liens dans /oracle vers /local/oracle pour les modifications locales </li></ul></ul></ul><ul><li>Avantages </li></ul><ul><ul><ul><li>Gestions de plusieurs versions d’oracle possible </li></ul></ul></ul><ul><ul><ul><li>Passage d’une version à une autre simplifiée </li></ul></ul></ul>
  40. 40. Normalisations : recopie des binaires SAN /oracle/xx /oracle/xx send / recv R é plication entre ZG ZG ZG
  41. 41. Normalisation : gestionnaire ZFS <ul><li>Gestion des pools ZFS </li></ul><ul><ul><ul><li>1 Pool pour le container </li></ul></ul></ul><ul><ul><ul><li>1 Pool pour chaque base </li></ul></ul></ul><ul><li>Nommage des pools </li></ul><ul><ul><ul><li>eqdg2dbdxxdg00 : pool pour le container </li></ul></ul></ul><ul><ul><ul><li>xxxxdg00 : pool pour la base (xxxx représente le nom de la base) </li></ul></ul></ul><ul><li>Création de zfs filesystems en montage legacy </li></ul><ul><ul><ul><li>Le pool ne doit pas être montable </li></ul></ul></ul><ul><ul><ul><li>Création de volumes dans un pool nommé eqdg2dbdxxdg00/datavol </li></ul></ul></ul>
  42. 42. Normalisation : gestionnaire SVM <ul><li>Uniquement pour les datas </li></ul><ul><ul><ul><li>1 Meta par base </li></ul></ul></ul><ul><ul><ul><li>Meta de type concat uniquement si plusieurs luns </li></ul></ul></ul><ul><li>Nommage des metas (dxxx) </li></ul><ul><ul><ul><li>Par exemple : d100, d110, d120… </li></ul></ul></ul><ul><ul><ul><li>xxxxdg00 : pool pour la base (xxxx représente le nom de la base) </li></ul></ul></ul><ul><li>Montage des metas </li></ul><ul><ul><ul><li>Montage dans la zone globale (su r veillance + supervision) </li></ul></ul></ul><ul><ul><ul><li>Montage lofs dans les containers </li></ul></ul></ul>
  43. 43. Analyses
  44. 44. Analyse : état actuel <ul><li>Contexte </li></ul><ul><ul><ul><li>9 serveurs d’hébergement (3 M5000 – 1 E2900 – 3 V890 – 2 T5240) </li></ul></ul></ul><ul><ul><ul><li>90 zones disponibles </li></ul></ul></ul><ul><ul><ul><li>110 bases Oracle + environ 30 bases Sybase </li></ul></ul></ul><ul><li>65% de l’objectif atteint pour le moment </li></ul><ul><ul><ul><li>Plusieurs bases restent à migrer </li></ul></ul></ul><ul><ul><ul><li>En attente de nouveaux serveurs d’hébergement (jeux de taquin) </li></ul></ul></ul><ul><li>Architecture étendue </li></ul><ul><ul><ul><li>Agrandissement du pé rim ètre pour d’autres projets </li></ul></ul></ul><ul><ul><ul><li>Acquisition de nouveaux serveurs d’hébergement </li></ul></ul></ul><ul><ul><ul><li>Architecture x86 en cours de construction </li></ul></ul></ul>
  45. 45. Analyse : administration <ul><li>Création d’outils automatisation </li></ul><ul><ul><ul><li>Scripts d’installation d’une zone </li></ul></ul></ul><ul><ul><ul><li>Scripts pour des profils spécifiques (Oracle, Sybase) </li></ul></ul></ul><ul><ul><ul><li>Localisation des containers (en cours) </li></ul></ul></ul><ul><li>Flexibilité </li></ul><ul><ul><ul><li>Migration d’une zone (zone attach/detach) </li></ul></ul></ul><ul><ul><ul><li>Migration d’une base spécifique </li></ul></ul></ul><ul><li>Maintenances diverses </li></ul><ul><ul><ul><li>Fort impact (une moyen ne de 20 containers par global) </li></ul></ul></ul><ul><ul><ul><li>Maintenir tous les serveurs d’hé bergements au m ême niveau (patchs) </li></ul></ul></ul>
  46. 46. Analyse : gestion des ressources CPU <ul><li>Contraintes </li></ul><ul><ul><ul><li>Garantir le temps de traitements </li></ul></ul></ul><ul><ul><ul><li>Optimiser les ressources CPU </li></ul></ul></ul><ul><li>Choix du scheduler </li></ul><ul><ul><ul><li>FSS : minimum garanti (valeur absole) </li></ul></ul></ul><ul><ul><ul><li>TS : temps partagé </li></ul></ul></ul><ul><li>Mé thode appliqu é e </li></ul><ul><ul><ul><li>FSS par dé faut ( point identique pour ZG et chaque container) </li></ul></ul></ul><ul><ul><ul><li>Pool de CPU pour les bases de bench </li></ul></ul></ul>
  47. 47. Analyse : gestion des ressources MEM <ul><li>Contraintes </li></ul><ul><ul><ul><li>Ré servation d’un espace contigu n é cessaire </li></ul></ul></ul><ul><ul><ul><li>Dé pend du nombre de connexions utilisateurs </li></ul></ul></ul><ul><li>Gestion possible </li></ul><ul><ul><ul><li>Ressources limitées lors de la dé finition du container </li></ul></ul></ul><ul><ul><ul><li>Ressources gérées pa r les bases </li></ul></ul></ul><ul><li>Mé thode appliqu é e </li></ul><ul><ul><ul><li>Pas de limitation pour les containers </li></ul></ul></ul><ul><ul><ul><li>Limitation dans la configuration des bases </li></ul></ul></ul><ul><ul><ul><li>Mise en place de projet (par groupe) pour la shm </li></ul></ul></ul>
  48. 48. Analyse : gestion des ressources I/O <ul><li>Contraintes </li></ul><ul><ul><ul><li>Réduction du te mps d’ écriture </li></ul></ul></ul><ul><ul><ul><li>Utilisation de deux gestionnaires de syst èmes de fichiers </li></ul></ul></ul><ul><li>Gestion I/O </li></ul><ul><ul><ul><li>Forte influence des systèmes de fichiers </li></ul></ul></ul><ul><ul><ul><li>Dé dier ou non l’allocation des ressources I/O aux containers </li></ul></ul></ul><ul><li>Mé thode appliqu ée </li></ul><ul><ul><ul><li>Valeur FSS identique entre la zone globale et les containers </li></ul></ul></ul><ul><ul><ul><li>Montage lof s depuis la globale (sauf pour les raw) </li></ul></ul></ul><ul><ul><ul><li>ZFS : arc, nocacheflush, prefetch, recordsize </li></ul></ul></ul><ul><ul><ul><li>UFS : maxphys </li></ul></ul></ul>
  49. 49. Analyse : particularit é s des bases <ul><li>Oracle </li></ul><ul><ul><ul><li>Compte identique pour toutes les bases </li></ul></ul></ul><ul><ul><ul><li>Paramètre setall (n é cessaire pour UFS) </li></ul></ul></ul><ul><ul><ul><li>Paramètres sga / pga positionné s (pas de dism) </li></ul></ul></ul><ul><li>Sybase </li></ul><ul><ul><ul><li>Paramètres shm positionné s dans les containers </li></ul></ul></ul><ul><ul><ul><li>Système de fichiers particulier (tempdb en tmpfs) </li></ul></ul></ul><ul><ul><ul><li>Groupe commun pour toutes les bases </li></ul></ul></ul>
  50. 50. Analyse : points divers <ul><li>Clone </li></ul><ul><ul><ul><li>Suppression des clones ZFS (utilisation de Rman ou outils Sybase) </li></ul></ul></ul><ul><ul><ul><li>Clone disponible sur les bases en UFS uniquement </li></ul></ul></ul><ul><li>Ressources </li></ul><ul><ul><ul><li>Augmentation de la swap </li></ul></ul></ul><ul><ul><ul><li>Ressource CPU peu utilisé e dans notre contexte (sauf pour Rman) </li></ul></ul></ul><ul><ul><ul><li>Ressource critique : mémoire </li></ul></ul></ul><ul><ul><ul><li>Dysfonctionnement mal vé cu par les utilisateurs </li></ul></ul></ul>
  51. 51. Conclusion <ul><li>Changement : l’ennemi public </li></ul><ul><ul><ul><li>Peur du changement </li></ul></ul></ul><ul><ul><ul><li>A priori des utilisateurs </li></ul></ul></ul><ul><li>Globalement </li></ul><ul><ul><ul><li>Projet viable et né cessaire </li></ul></ul></ul><ul><ul><ul><li>Administration simplifié e pour plusieurs équipes (Unix, DBA) </li></ul></ul></ul><ul><ul><ul><li>Financi èrement rentable </li></ul></ul></ul><ul><ul><ul><li>Projet é tendu (ouverture sur d’autres pé rim ètres et d’autres techniques) </li></ul></ul></ul>
  52. 52. Questions

×