mutualisation sous solaris

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