Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Mutualisation sous Solaris

1,776 views

Published on

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

  • accessibility Books Library allowing access to top content, including thousands of title from favorite author, plus the ability to read or download a huge selection of books for your pc or smartphone within minutes DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { https://urlzs.com/UABbn } ......................................................................................................................... Download Full EPUB Ebook here { https://urlzs.com/UABbn } ......................................................................................................................... ...................................ALL FOR EBOOKS................................................. Cookbooks, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy,
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

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

×