Post on 03-Jul-2015
description
Mutualisation des serveurs
Retour d’expérience
Bruno PHILIPPE Décembre 2009
Plan de la présentation
Introduction Objectifs Etude Architecture & Solutions techniques Normalisation Analyses Conclusion
Introduction
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…
Introduction
Objectifs
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…)
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
Etude
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
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)
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
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)
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)
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)
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é
Etude : coût du parc (bilan)
Coût par an
18120 22 k€
50 50 k€
125 63 k€
+3 k€ /an 25 k€
Nombre de U 117 6 racks
Puissance totale (W) (1)
Connexion réseau et san (2)
Coût homme / jour (3)
Maintenance parc (4) (5)
(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)
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...)
Etude : calibrage des serveurs (exemples)
orasrv-dev19 (v440) orasrv-dev21 (v440) mxtback-dev02 (E450)
0
5
10
15
20
25
30
35
40
45
CPU théorique (1)CPU réel (2)Mémoire totale (3)Mémoire consommée (4)
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-rateGb
Gb
Gb
Gb GbGb
(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)
Etude : schéma cible
M5000
SAN
Réseau
Zone1 Zone2 Zone3
Zone4 Zone5 Zone6
M5000
Architecture redontante Meilleur gestion des
ressources Simplicité des tests de
charges Reprise des applications
de production
M5000
Zone9 Zone8 Zone7
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 %
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
Etude : comparaison des coûts par an
Coût de la consommation électrique Coût des connexions réseau/san Coût en h/j0
10
20
30
40
50
60
70
Coût solution actuelle en k€Coût solution future en k€Gain en k€
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
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)
Architecture & Solutions techniques
Architecture : schéma globale
SITE B
SITE A
SITE CSITE 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
Instance/Zone globale Instance/Zone par défaut Gestion des ressources globales (IO, CPU, Allocation 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
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
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)
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 des systèmes de fichiers)
Limitations : 8 clones par source – clone de clone Renommage de la base post-resynchro (DBA)
Solutions techniques : clones ZFS
SAN
/PEGS1
/PEGD1
Refresh occasionnel
ZG
Mise à jour des bases
STBY – front
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)
Normalisation
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
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 lofs (sauf si accès en raw device)
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
Normalisation : montage lofs
/oracle
ZG Container
Vue ZG / Containers
/oracle
Montages chrootés
/zones/eqdg2dbdxxx/root /
/data1/zones/eqdg2dbdxxx/data1
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
Normalisations : recopie des binaires
SAN
/oracle/xx
ZG
/oracle/xx
send / recv
ZG
Réplication entre ZG
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
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 (surveillance + supervision) Montage lofs dans les containers
Analyses
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
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 moyenne de 20 containers par global) Maintenir tous les serveurs d’hébergements au même niveau (patchs)
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
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 par 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
Analyse : gestion des ressources I/O
Contraintes Réduction du temps 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 lofs depuis la globale (sauf pour les raw) ZFS : arc, nocacheflush, prefetch, recordsize UFS : maxphys
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
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
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)
Questions