Club des Responsables d Infrastructures et de Production LiVRE BLANC L OBSERVATOIRE des Directeurs d Infrastructures et de Production Bases de Données Mutualisation et Consolidation, Critères de décision, Bonnes Pratiques Laurent Benguigui, Frédéric Blondin, Sylvie Brunet, Marc Duterte, Romaric Mion, Assistance éditoriale : Renaud Bonnet Juin 2012
Table des matières 1. Introduction : pourquoi mutualiser et consolider? 5 1.1. La démarche de Consolidation mutualisation : quelques points essentiels 6 2. Définition des différents niveaux de consolidation 8 2.1. Quelques rappels sur les licences 11 3. Les 9 critères de décision pour la mutualisation ET CONSOLIDATION 15 3.1. Sécurité 15 3.2. Scalabilité et dimensionnement 16 3.3. Connaissance du profil d utilisation de l application 17 3.4. RTO/RPO : Plages d utilisation, de maintenance, niveaux de réactivité 17 3.5. Contraintes liées au domaine métier 18 3.6. Critères de Risques techniques liés à l infrastructure de mutualisation 19 3.7. Coûts financiers 20 3.8. Administration + Exploitation 20 3.9. Exigences techniques spécifiques 21 4. forces et faiblesses des différents modèles de consolidation et mutualisation 22 5. NOTE technique : les spécificités des différentes bases 29 6. Grille d évaluation du niveau de mutualisation 48 7. NOTEs 51 A propos du CRiP 52 PAGE 3
AUTEURS Ce Livre blanc a été écrit par le Groupe de Travail Bases de données du CRiP, à partir des réunions de ses membres. Les auteurs principaux en sont : Laurent Benguigui Frédéric Blondin Sylvie Brunet Marc Duterte Romaric Mion Ont aussi participé : Bernard Tinchant Emmanuel Bastien Pascal Dib Generali venteprivée.com GIE Prod adp total Casino Bouygues Construction BNP-Paribas Assistance éditoriale et coordination : Renaud Bonnet (CRiP) Avertissement : Ce livre blanc comporte des éléments de réflexion généralistes, qui valent pour tout projet de consolidation mutualisation de bases de données. Lorsqu il s est agi de fournir des indications plus directement techniques, nous avons concentré nos efforts sur les quatre technologies de bases de données les plus familières aux participants du Groupe de Travail : DB2 LUW (Linux, Unix, Windows) d IBM, Oracle, SQL Server de Microsoft et Sybase. Si d autres systèmes de bases de données manquent, en particulier les plates-formes Open Source, ce n est pas par ommission mais par simple conséquence de notre manque d expérience dans ce domaine. Tout membre du CRiP qui souhaiterait nous apporter ses lumières sur d autres SGBD sera le bienvenu. PAGE 4
1 Introduction : pourquoi mutualiser et consolider? On sait que l informatique bégaye. Née centralisée, elle devint distribuée, trop sans doute. Au fur et à mesure que le coût des serveurs diminuait, que les réseaux de communication se renforçaient, on vit fleurir les machines, les applications, les salles informatiques même. Dispersée en cent lieux, éparpillée, et pour tout dire incontrôlable, l informatique avait besoin de se retrouver un centre, ou à défaut des centres. La mutualisation et la consolidation des bases de données participent de ce grand mouvement de pendule, qui fait revenir les choses vers leur point d origine, mais sous une forme profondément modifiée. Personne ne sera surpris d apprendre que la première motivation pour engager ces démarches de mutualisation et consolidation soit financière. Posons quelques définitions. Les termes mutualisation et consolidation fonctionnent aujourd hui comme des synonymes. On peut cependant les différencier. La consolidation est plutôt un mouvement initial de rationalisation qui consiste souvent à effectuer une fusion physique d éléments présentant de fortes similarités : rassembler plusieurs SGBD sur un même équipement physique de fortes capacités, par exemple en virtualisant le matériel, une démarche déjà connue depuis longtemps avec l émergence des grandes plates-formes RISC-Unix. Ce terme de consolidation s applique d ailleurs aussi aux datacenters, ou aux opérations qui suivent la fusion de deux entreprises. La mutualisation possède une connotation plus directement en rapport avec nos préoccupations. Il s agit de réaliser la plus grande mise en commun possible de ressources de tout niveau afin d en tirer le meilleur parti économique et la plus grande efficacité. Là où consolidation a plutôt la connotation d une opération initiale, mutualisation désigne un travail continu, sans cesse à reprendre et à améliorer. Pourquoi mutualiser et consolider? Pour acheter moins de serveurs et optimiser leurs taux d utilisation, et désencombrer les salles informatiques des armées de machines sous-utilisées qui y résident. Pour acheter moins de licences de systèmes d exploitation. Pour payer moins de licences de bases de données. Pour mobiliser moins de personnes à effectuer des tâches à faible valeur ajoutée en réduisant la masse des plates-formes à administrer. Arguments économiques. Mais avec la mutualisation et la consolidation, il y va aussi d enjeux plus généraux de la transformation des systèmes d information, de l application de principes, de standards, de contrôle, et d unfication de l administration. La prolifération des PAGE 5 Bases de Données, Mutualisation et Consolidation, Critères de décision, Bonnes Pratiques LiVRE BLANC
bases coûte cher, elle fait aussi peser sur le système d information des risques d obsolescence, d administration insuffisante, elle complexifie la gestion du changement, elle nuit à l urbanisation du SI. Mutualiser et consolider apparaissent aussi comme des bonnes pratiques dans le cadre plus vaste d un pilotage continu du système d information, et de son exploitation sur un mode rationnel. 1.1. La démarche de Consolidation mutualisation : quelques points essentiels Toute opération de mutualisation de bases de données doit respecter quelques règles. On ne peut pas tout mutualiser. Peut-être un jour en serons-nous capable, mais pour le moment, l état des techniques comme celui des pratiques d administration fait que certaines bases ne sont pas éligibles à la mutualisation. Bases hypersensibles, hypercritiques, très grosses consommatrices de ressources, très confidentielles, ou devant pour des raisons de politique interne rester à l écart de leurs consœurs. Il faut essayer de mutualiser autant que possible, il faut aussi savoir ne pas mutualiser lorsqu une telle opération risque de provoquer plus de problèmes qu elle n apporte d avantages. On ne mutualise que ce qui est déjà connu. Il faut avoir observé une base durant un temps significatif pour connaître son comportement avant de la mutualiser. Une base dont le comportement n a pas été évalué sur une durée suffisamment importante pour détecter ses cycles d activité (quotidiens, hebdomadaires, mensuels au minimum) risque de réserver de mauvaises surprises lorsqu elle devra cohabiter avec d autres bases. La mutualisation doit s accompagner d un suivi systématique. Il faut avoir observé une base de données avant de la mutualiser, mais il faut aussi suivre cette base de données une fois mutualisée, surveiller son comportement afin d accompagner au mieux son cycle de vie qui peut nécessiter de modifier la stratégie de consolidation initiale. Une base peu active peut aussi être hyper-critique. La criticité d une base ne se définit pas uniquement par l intensité de son utilisation, mais aussi par sa position dans le système d information et par le contrat de service qui lui est attaché. Une base fortement transactionnelle, fortement sollicitée, associée à une application essentielle au métier paraîtra immédiatement critique et sera traitée comme telle. Mais il existe aussi dans toute entreprise des bases de faible activité et de faible volume dont la criticité en termes stratégiques par exemple peut s avérer énorme. Il ne faut pas réduire la criticité à l intensité de l utilisation, mais disposer d autres éléments de jugement, des éléments métier en particulier. PAGE 6 Toute entreprise a ses interdits de mutualisation. Il existe dans toute entreprise des contraintes spécifiques liées aux types de données, avec de fréquentes restrictions en ce qui concerne le mélange de ces données. La ligne de fracture la plus courante sépare les données de production et les données hors-production qui dans de nombreuses entreprises ne doivent pas être consolidées. Une autre séparation de bon sens consiste à ne jamais mélanger données transactionnelles
et données décisionnelles du fait de leurs profils d usage très différents. Mais il existe des distinctions plus subtiles. Dans certaines entreprises, la mutualisation entre branches d activités différentes est proscrite pour des raison d organisation de l activité ou en réponse à des contraintes de contrôle et de sécurité. Le coût n est pas le seul argument en faveur de la mutualisation. L importance du gain économique, du coût, ne doit pas être surestimée dans une opération de mutualisation. Dans les entreprises où l IT refacture le fonctionnement des bases de données aux utilisateurs, l argument financier peut peser pour proposer à cet utilisateur d évoluer vers une architecture mutualisée. Mais lorsque l IT fonctionne avec un budget global d exploitation, cet argument devient plus difficile à exposer aux métiers. Il faut donc que la promotion des solutions mutualisées passe par d autres arguments, et d autres bénéfices, que le seul coût utilisateur. PAGE 7 Bases de Données, Mutualisation et Consolidation, Critères de décision, Bonnes Pratiques LiVRE BLANC
2 Définition des différents niveaux de consolidation Nous distinguons ici trois grands types de mutualisation possibles pour les bases de données, étant entendu qu il arrive que ces grands modèles s hybrident les uns avec les autres puisqu ils ne sont pas exclusifs. La mutualisation de niveau physique : elle consiste à faire cohabiter plusieurs SGBD indépendants, chacun installé sur son propre système d exploitation, dans des machines virtuelles ou des partitions installées sur un même serveur physique. On reconnaît ici un modèle inauguré sur les grands systèmes IBM dès la fin des années 60 avec les premières générations d hyperviseurs VM sur S/360, puis étendu aux systèmes RISC-UNIX dans les années 90 avant de se généraliser dans le monde ouvert dans les années 2000 avec le passage en production des hyperviseurs x86 (VMware, Hyper-V, Xen, KVM, etc.) La formule : Un seul serveur physique, Plusieurs systèmes d exploitation, Plusieurs SGBD à raison de 1 par système d exploitation, Différentes versions de SGBD et d OS possibles au-dessus du même matériel. Schéma de principe : mutualisation de niveau physique vhost vhost vhost Instance 1 Instance 1 Instance 1 HYPERVISEUR Les principales caractéristiques à prendre en compte : Très forte isolation due à l emploi des hyperviseurs. Coût des licences multiples puisqu il existe de nombreux hyperviseurs, plusieurs systèmes d exploitation et plusieurs instances de bases de données. Overhead lié à la virtualisation : les hyperviseurs consomment de la ressource matérielle, l exécution de plusieurs systèmes d exploitation concurrents aussi, ce modèle est le moins économique en termes de puissance machine consommée. PAGE 8
La mutualisation de niveau système d exploitation : consiste à tirer parti des capacités de fonctionnement multitâches des systèmes d exploitation pour faire cohabiter plusieurs instances de SGBDR complètes au-dessus d un même OS. En effet, si dans le monde distribué la tendance a longtemps été de dédier un environnement de système d exploitation à l exécution d une charge précise, les systèmes d exploitation sont conçus pour exécuter plusieurs charges simultanément dans des conditions d isolation satisfaisantes. La plupart des systèmes d exploitation incluent d ailleurs des mécanismes d affectation de ressources qui permettent d attribuer des priorités aux différentes charges qu ils hébergent. La formule : Un seul serveur (physique ou virtuel), Un seul système d exploitation, Plusieurs SGBD s exécutant simultanément sur ce système d exploitation, Différentes versions de SGBD possibles, cette façon de faire ne figure cependant pas dans les bonnes pratiques du fait des adhérences avec les socles systèmes. Schéma de principe : mutualisation de niveau système Host Instance 1 Instance 2 Instance 3 Instance 4 Les principales caractéristiques à prendre en compte : Multiples licences de SGBD : en effet, dans ce modèle seul le système d exploitation se trouve mutualisé, pas la couche bases de données. Overhead lié à l exécution de plusieurs SGBD : plusieurs moteurs accèdent aux ressources en même temps, certaines fonctions sont redondantes. Isolation limitée : si l un des SGBD fait crasher le système, les autres SGBD se trouvent indisponibles eux aussi. Problème d allocation des ressources : il existe un risque de voir plusieurs SGBD entrer en conflit pour l accès aux ressources au même moment, ce qui risque de se traduire par une baisse de performances. PAGE 9 Bases de Données, Mutualisation et Consolidation, Critères de décision, Bonnes Pratiques LiVRE BLANC
La Mutualisation de niveau Bases de données (aussi appelée mutualisation d instances ou de schémas) : il s agit ici d une famille de technologies souvent propriétaires qui consistent à faire gérer plusieurs bases indépendantes par une seule instance de SGBD. De fait, plusieurs jeux de données se trouvent gérés au sein du même moteur logiciel. Selon les fournisseurs, la quantité d éléments effectivement mutualisés varie, vous trouverez plus de détails sur ces modes de fonctionnement dans le chapitre 4 de ce document. La formule : Un seul serveur (physique ou virtuel), Un seul OS, Un seul SGBD (donc une seule version), Différents jeux de données. Schéma de principe : mutualisation de bases, instances, schémas Host Instance 1 Schéma 1 Schéma 2 Schéma 3 Les principales caractéristiques à prendre en compte : Des licences mutualisées pour l ensemble des applications. Un incident sur une des bases impacte l ensemble des autres bases installées sur le même moteur. Ce modèle présente un niveau d isolation moindre que ses concurrents en règle générale. La gestion du partage de ressources est particulièrement critique et complexe à la fois. PAGE 10
2.1. Quelques rappels sur les licences Nous vous rappelons ci-dessous quelques spécificités des modes de licence des différents éditeurs, spécificités à prendre en compte pour apprécier les éventuelles conséquences financières d opérations de mutualisation. Pour DB2 Il existe quatre éditions serveur de DB2 pour Linux, Unix et Windows, que nous avons prises en compte : Express Edition, Workgroup Edition, Enterprise Edition et Advanced Enterprise edition. TYPE DE LICENCE Licence par Utilisateur Autorisé Processeur Value Unit (PVU) Server et Fixed Term Licence Socket licence (Source : site web IBM) DESCRIPTION Un Utilisateur Autorisé est un seul et unique individu doté d un identifiant (ID) spécifique. Chaque Utilisateur Autorisé doit posséder sa licence, un périphérique valant comme un utilisateur. Le Logiciel peut être utilisé par plusieurs Utilisateurs Autorisés. IBM fixe un nombre minimum d utilisateurs uniques à respecter pour avoir droit à ce mode de licence sur les différentes versions de DB2 : 5 utilisateurs uniques minimum pour DB2 Express et DB2 Workgroup, 25 utilisateurs uniques par tranche de 100 PVU (voir ci-dessous) disponibles sur le serveur qui exécute la base de données pour DB2 Enterprise. Permet l accès à la base à un nombre illimité d utilisateurs par tous moyens possibles. Le PVU est l unité de mesure qui a succédé chez IBM à la facturation par cœurs, qui succédait elle-même à la facturation par processeurs. Le PVU est une unité propre à IBM qui attribue aux différents processeurs disponibles sur le marché une quantité de PVU (la formule de calcul n est pas connue). Certaines éditions de DB2 ne sont installables que sur des serveurs dont le PVU n excède pas une valeur donnée. En raison de la généralisation de la virtualisation et de l augmentation de la puissance des plates-formes, IBM pratique le sub-capacity pricing : un modèle de facturation qui ne prend (sous conditions et selon des formules de calcul précises) en compte qu une sous-partie des processeurs d un serveur. Il existe des modes de calculs spécifiques du sub-capacity pricing pour prendre en compte les différentes possibilités des plates-formes de virtualisation (LPAR, DLPAR, micropartitionnement, etc.) Licence applicable à l ensemble d un serveur, ou à n importe quelle partition en cas de virtualisation, pour un nombre illimité d utilisateurs. La taille du serveur n est pas prise en compte dans le coût de la licence, mais il y a des limitations de puissance de plate-forme correspondant à l édition DB2 Express (pas plus de 4 cœurs et 4 Go de mémoire). Limitée à DB2 Workgroup Edition, cette licence est facturée au processeur physique, dans la limite d un système comportant au maximum 4 processeurs quadri-cœurs et 64 Go de RAM. PAGE 11 Bases de Données, Mutualisation et Consolidation, Critères de décision, Bonnes Pratiques LiVRE BLANC
Pour Oracle La licence est un droit d utilisation et n est pas protégée par des clés de licence. Elle n est pas non plus soumise à des contraintes de versions. Différents type de licences possibles : TYPE DE LICENCE DESCRIPTION A Unlimited License Agreements (ULA) Droit d usage illimité valable en général sur 2 ou 3 ans (réservé aux comptes avec de gros parcs informatiques). Processor licensing Par processeur, attention aux définitions des processeurs. Dans certain cas sont comptés les cores ou coeurs et dans d autres les Sockets ou processeurs physiques (cas de l Entreprise Edition et Standard Edition). De plus en fonction du processeur, des ratios minorants sont appliqués. Named User Plus Licensing Licence à l utilisateur: un utilisateur est défini comme point final de réception de données ou créateur de base de données Oracle. Named User Licensing (NU) La licence à l utilisateur nommé limite de nombre d utilisateurs ayant le droit d utiliser Oracle sur des serveurs. Ce type de licence n a plus cours sur les nouveaux contrats. Concurrent Device (CD) Licence qui prend en compte le nombre maximum de périphériques se connectant. Ce type de licence n est plus proposé dans les nouveaux contrats. Application Specific Full Use Licensing (ASFU) Licence liée à l utilisation des progiciels, comme par exemple SAP. Les licences ainsi acquises ne sont utilisables que dans le cadre d un progiciel spécifique. Embedded Software License Licence pour l utilisation d Oracle dans des produits logiciels en «boite noire». (source: http://www.orafaq.com/wiki/oracle_licensing#standard_edition_per-socket_licensing) PAGE 12
Pour Microsoft SQL Server Le seul type de licence envisageable pour une utilisation de SQL Server derrière un frontal Web est la licence Processeur / Cœur. TYPE DE LICENCE Licence par utilisateur Licence par périphérique Licence par processeur Licence par cœur (Source http://fr.wikipedia.org/wiki/microsoft_sql_server) DESCRIPTION SQL Server peut utiliser tous les processeurs du serveur (jusqu à la version 2008 R2, maximum 16 (édition Standard) ou 20 (édition Entreprise) coeurs dans la version 2012) mais est limité au nombre d utilisateurs spécifié. Chaque personne physique se servant d une application utilisant SQL Server est considérée comme un utilisateur de la base de données. (depuis SQL Server 2005) : SQL Server peut utiliser tous les processeurs du serveur (jusqu'à la version 2008 R2, maximum 16 (édition Standard) ou 20 (édition Entreprise) cœurs dans la version 2012) mais est limité au nombre de périphériques spécifié. Chaque périphérique physique accédant directement ou indirectement à SQL Server est considéré comme un utilisateur de la base de données. SQL Server utilise le nombre de processeurs spécifié dans la licence et peut accepter un nombre indéfini d'utilisateurs. Ce mode de licence est valable jusqu'à l'édition 2008 R2 et disparaît après. Il faut acheter autant de licences coeur qu'il y a de cœurs dans le serveur ou dans la machine virtuelle. Le nombre d'utilisateurs est illimité. Ce mode de licence n'est valable qu'à partir de l'édition 2012. PAGE 13 Bases de Données, Mutualisation et Consolidation, Critères de décision, Bonnes Pratiques LiVRE BLANC
Pour Sybase Suivant le type de licence, l allocation est contrôlée par le programme. TYPE DE LICENCE DESCRIPTION Licence d'accès Internet ou IAL Licence permettant l'accès par un nombre de Postes Internet Externes. Licence d'application ou AP Licence valable sur tout serveur installé sur le seul emplacement physique (ou site d'hébergement approuvé) spécifié pour cette licence. Licence CPU ou CP Licence applicable sur une Machine sur laquelle le nombre de CPUs n est pas supérieur au nombre de licences acquises. Licence Flottante ou FL Licence pour machines de type poste de travail, sous réserve qu à chaque instant, le nombre total de machines poste de travail sur lesquelles le Client peut utiliser le Programme simultanément n excède pas le nombre de licences acquises. Licence Groupe ou Cluster licence Licence sur plusieurs serveurs sur le seul site spécifié pour une telle licence, mais seulement si chacun de ces serveurs fait partie d'une configuration de charge équilibrée ou de tolérance aux pannes. ETC Il existe de nombreuses variantes possibles de licencing. (Source «contrat de licence Sybase») PAGE 14
3 Les 9 critères de décision pour la mutualisation ET CONSOLIDATION Dans ce chapitre, nous exposons 9 critères élaborés en commun, critères qui pourront ensuite servir à chacun de nous lorsqu il s agira de définir sa stratégie de mutualisation 1. Ces critères sont : Sécurité Scalabilité et dimensionnement Connaissance du profil d utilisation de l application RTO et RPO, plages d utilisation et de maintenance, niveaux de réactivité Contraintes liées au domaine métier Critères de risques techniques liés à la mutualisation Coût financier Administration et Exploitation Exigences techniques spécifiques En fonction de ces critères et des questions que nous y associons, il sera possible de choisir ou non de mutualiser, et de déterminer quels types de mutualisation sont envisageables. 3.1. Sécurité Nous regroupons sous ce critère les questions de sécurisation des données en fonction de leur confidentialité. Ce critère évalue donc le type de mutualisation acceptable des données en fonction de l exigence de confidentialité qui leur est attachée. Il ne porte pas sur les moteurs des bases. L exigence de confidentialité est établie : Par le métier avant tout. Il est le premier à pouvoir spécifier ses exigences en ce qui concerne la criticité des données qu il manipule et produit pour ses activités. Par l utilisation de comptes privilégiés liés aux contraintes de fonctionnement de certains logiciels. Par le niveau d ouverture vers l extérieur des données concernées, puisque cette ouverture rend ces données par définition plus vulnérables aux attaques externes. Par le niveau de confidentialité attribué en interne aux données en fonction des règles et politiques de l entreprise (il s agit ici de l architecture de sécurité IT de l entreprise qui peut exiger l isolation stricte de certaines informations par exemple, parfois pour des raisons de réglementation, d autres fois dans une optique de gouvernance interne). 1 Dans la suite de ce chapitre nous utiliserons indifféremment les termes de consolidation et de mutualisation PAGE 15 Bases de Données, Mutualisation et Consolidation, Critères de décision, Bonnes Pratiques LiVRE BLANC
Nous proposons les exemples suivants de Profils de Confidentialité des bases de données : Profil Non confidentiel : les bases ne font l objet d aucune mesure particulière. Moyen : les mécanismes standards des bases éventuellement complétés par d autres solutions sont susceptibles de garantir une étanchéité et confidentialité en concordance avec le cahier des charges. Fort : les mécanismes standards doivent être renforcés par de l isolation physique pour garantir un agrément de confidentialité et offrir un niveau de type coffre-fort (exemple : données médicales, données financières, etc.) Ce critère de confidentialité peut être également évalué d un point de vue «politique» vis-à-vis d une volonté métier qui malgré les garanties d étanchéité exige d isoler ses données : certains départements de grandes entreprises refusent par exemple de mutualiser leurs données et imposent une séparation stricte de leurs infrastructures physiques. Questions à poser pour qualifier la confidentialité des données : Les données sont-elles sur Internet, ouvertes vers l extérieur sans contraintes? Y-a-t-il des habilitations spécifiques prévues? Quel est l impact de la divulgation des informations? Quelle est dans l entreprise, l infrastructure la plus à même de répondre au besoin de sécurité? 3.2. Scalabilité et dimensionnement Ce critère évalue l impact de la stratégie de mutualisation sur l évolution et les modifications à venir de la base. Ce critère se détermine en fonction de la croissance des besoins de la base, qu il s agisse de puissance de traitement serveur ou de capacités de stockage, ainsi que de la prédictibilité de son évolution. Questions à poser pour qualifier la scalabilité et le dimensionnement : Les exigences de croissance sont-elles connues? Quel est le taux de croissance prévisible dans le temps? On voit que ce critère concerne aussi bien la base que l infrastructure qui l héberge. Le vrai problème concernant ce critère réside dans l incapacité fréquente du métier à répondre à cette question. La position par défaut consiste donc à prévoir un maximum de scalabilité, ou à placer les bases sous surveillance avec des seuils d alerte. PAGE 16
3.3. Connaissance du profil d utilisation de l application Ce critère évalue la connaissance du modèle d utilisation de l application. Il traite du nombre d accès utilisateurs, de la typologie de l usage (transactionnel ou décisionnel), de la charge batch, des périodes spécifiques de traitements (fins de mois, fins d années, événements spécifiques prédictibles, etc.) Le but de ce critère est de se donner une image des besoins de capacité de la base et de ses rythmes de consommation de ressources. Ce critère est évalué en nombre d accès concurrents, en types d accès (lecture / écriture), en périodicité des batches, et tous autres événements réguliers. Questions à poser pour déterminer le profil d utilisation de l application : Quel est le niveau d accès TP / Batch? L activité est-elle de type TP ou décisionnel? Y-a-t-il des pics de charges (traitements lourds mensuels, annuels ou autres, campagnes marketing, périodes d activité spécifiques)? Quelle est la charge moyenne? La charge maximum? Quels sont les horaires d utilisation (sur quels fuseaux horaires fonctionne l application, relève-t-elle d une utilisation 24/7)? 3.4. RTO/RPO : Plages d utilisation, de maintenance, niveaux de réactivité Ce critère évalue le besoin en termes de RTO et RPO pour vérifier l adéquation de la stratégie de mutualisation par rapport à ces contraintes. Nous rappelons ici les définitions établies par le Groupe de Travail PRA du CRiP dans son Livre Blanc PRA : Définitions, Concepts, Bonnes Pratiques & Enquête. (disponible sur le site d ITIforums, www.itiforums.com) RTO : (Recovery Time Objective) Le RTO définit le délai de reprise informatique à partir duquel les services sont restaurés. Il s agit de la traduction informatique de l expression du besoin métier. Par exemple : quatre heures, une journée. Attention à bien déterminer le point de départ du chronomètre : décision de déclenchement du PRA, moment de survenance du sinistre, moment de constat du sinistre. RPO : (Recovery Point Objective) Le RPO définit le point temporel stable antérieur au sinistre à partir duquel la reprise d activités a lieu. Il s agit de la traduction informatique de l expression du besoin métiers. Par exemple : date de la dernière sauvegarde cohérente ou date de la dernière transaction synchrone validée. Le RPO se traduit par la perte de données maximale acceptable par le métier. PAGE 17 Bases de Données, Mutualisation et Consolidation, Critères de décision, Bonnes Pratiques LiVRE BLANC
Questions à poser pour définir les exigences de RTO/RPO, plages d utilisation, de maintenance et niveaux de réactivité : Quelles sont les caractéristiques de criticité business de cette application? Quelles sont les conséquences d un arrêt? Est-il possible de mettre en place des procédures de contournement en cas d indisponibilité? Quel est le temps d indisponibilité supportable? Quelle est la tolérance de perte de données en cas d incident (tolérance exprimée en secondes, minutes, heures)? Quelle est la garantie contractuelle de RTO ou de RPO inscrite dans le SLA de l application? Attention : il faut être très vigilant sur ces critères, car la mutualisation peut exercer un impact fort sur le RTO et RPO d une application. Il est important de créer des classes de criticité et d indisponibilité acceptable. 3.5. Contraintes liées au domaine métier Ce critère évalue la logique et le besoin d une mutualisation, les gains à en attendre, par rapport à des contraintes d accès ou de partage de données entre applications Métier. Mutualiser des bases qui fonctionnent en interaction étroite peut aussi être une bonne affaire en termes de performances lors des échanges d information entre ces bases. De plus, des bases associées à une même application risquent de présenter des profils d usage et des niveaux de criticité similaire, ce qui joue en faveur de leur consolidation. Questions à poser pour déterminer les contraintes liées au domaine métier : Quel est le domaine métier? Quelles sont les interfaces? Où se trouvent les données nécessaires au fonctionnement de l application? Les données doivent-elles être partagées par plusieurs applications? Nous renverrons là encore à la notion de «plaques de cohérence» définie dans le chapitre «Architecture et cohérence applicative» du Livre Blanc PRA : Définitions, Concepts, Bonnes Pratiques & Enquête. PAGE 18
3.6. Critères de Risques techniques liés à l infrastructure de mutualisation 1 er niveau de mutualisation : Le partage de l infrastructure de l instance de Base de données Ce critère traite des impacts potentiels d un partage de ressources communes en cas de survenue d un incident sur une base dans le cadre d une mutualisation. Il s agit du risque de voir la défaillance d une des bases mutualisées entrainer la défaillance d une autre base mutualisée dans le même environnement. Il s agit aussi d apprécier les conséquences découlant du partage des espaces communs : zone de tri, journaux, mémoire partagée. Questions à poser : En cas de problème technique (stockage, performance, bug) sur une base, quels seront les impacts sur les autres bases mutualisées sur le même socle? Par rapport aux exigences de sauvegardes / restauration applicatives, les différentes bases et applications sont-elles sur le même niveau ou sur des niveaux compatibles? Exemple typique : impact sur l ensemble des bases mutualisées d un problème de volumétrie advenant sur une des bases. 2 ème niveau Le partage des ressources système : Le partage de l infrastructure serveur Ce critère évalue le risque d impact sur les performances qui découle du partage de ressources matérielles communes par plusieurs bases : CPU, Mémoire, I/O, stockage principalement. La dimension critique ou non des performances de l application guide la stratégie de mutualisation et implique d accepter un partage de ressources systèmes plus ou moins important, sachant qu un fort partage augmente toujours le risque d impact sur les performances de l ensemble. Questions à poser : Est-ce que les profils de consommation de ressources de mes bases sont compatibles? Est-ce que les cycles d activité de mes bases sont les mêmes? Quel est le cycle de vie de l application? Existe-t-il des problèmes de sécurité spécifiques côté administration de certaines de ces bases? Est-ce que le socle système a un lien fort avec la base de telle façon qu une action sur le système impacte les bases? PAGE 19 Bases de Données, Mutualisation et Consolidation, Critères de décision, Bonnes Pratiques LiVRE BLANC
3.7. Coûts financiers Ce critère évalue les coûts qui découlent des différentes options de mutualisation. Il existe un ensemble d éléments qui vont permettre de donner des chiffrages d évaluation des gains à attendre de l opération de mutualisation : Besoins en licences et en maintenance (y compris les clients de sauvegarde, ordonnanceurs et autres logiciels d exploitation). Besoins en matériels (en incluant également les coûts matériels d infrastructures transverses : équipements réseau, robotiques de sauvegarde, matériels de sécurité dédiés, etc.) Besoins humains : charges de réalisation, d administration, de monitoring et d exploitation. Besoins logistiques : salles, électricité, climatisation, gardiennage et autres. Ces critères permettront d établir des grilles comparatives des différentes stratégies. Question à poser pour établir les critères de coûts financiers : Quelles sont les dépenses à prévoir dans le cadre du choix de la stratégie de mutualisation? Le but de l opération de mutualisation est-il de parvenir à une configuration low-cost? 3.8. Administration + Exploitation Ce critère évalue l impact de la stratégie de mutualisation retenue sur les tâches d administration et d exploitation. Le type de mutualisation choisi aura aussi un impact sur le rechargement des données, la sauvegarde, la gestion du stockage. Les points suivants sont à considérer : Sauvegarde Restauration Monitoring Supervision Maintien en Condition Opérationnelle : paramétrage, gestion des patchs et correctifs Refacturation des ressources consommées Exploitation Application de procédures Suivi de production PAGE 20
Question à poser pour évaluer l importance des critères d administration et d exploitation : Le choix de la stratégie de mutualisation est-il adapté aux contraintes d administration et d exploitation? La base à consolider peut-elle s accommoder des plages d arrêt pour maintenance prévues? 3.9. Exigences techniques spécifiques Ce critère évalue les exigences techniques à respecter pour garantir le bon fonctionnement et assurer le support des applications. A ce niveau, ces spécificités des applications peuvent guider le choix de la stratégie de mutualisation. Les différentes stratégies sont évaluées en fonction de pré-requis techniques exigés par le fournisseur de l application ou du progiciel. Questions à poser pour déterminer les exigences techniques spécifiques : Quels sont les jeux de caractères utilisés? Y-a-t-il des exigences de packages à utiliser au niveau du SGBD? Y-a-t-il des exigences de version du SGBD? PAGE 21 Bases de Données, Mutualisation et Consolidation, Critères de décision, Bonnes Pratiques LiVRE BLANC
4Forces et faiblesses des différents modèles de consolidation-mutualisation Ces tableaux énumèrent les forces et faiblesses des différents modèles de virtualisation rapportés aux 9 critères définis ci-dessus. Ils ne font pas références aux spécificités de fonctionnement des divers moteurs de bases de données qui sont traités plus bas. Rappel des définitions Mutualisation physique Mutualisation système Mutualisation d'instances et de bases (variable selon le type de technologie employée) Un serveur physique avec plusieurs OS virtuels et un SGBD par serveur virtuel. Un serveur physique ou virtuel, un seul OS, plusieurs SGBD sur cet OS. Un serveur physique ou virtuel, un seul OS, un ou plusieurs SGBD sur cet OS, accueillant selon les technologies plusieurs bases, plusieurs schémas, plusieurs instances. Critère 1 : Sécurité Mutualisation physique Mutualisation système Mutualisation d'instances et de bases (variable selon le type de technologie employée) Très bon niveau d isolation, dans la mesure de l étanchéité de l hyperviseur. Le niveau de sécurité dépend des capacités de l OS. La couche système constitue le maillon faible : si quelqu un prend la main sur le système, il accède à l ensemble des bases. Le super-utilisateur accède à l ensemble des données. Une faille système se répercute sur l ensemble des bases. Solution la moins sécurisée mais aussi la plus optimisée en coût et en rapidité de déploiement. En effet, la prise de contrôle de l instance donne accès à toutes les données depuis un compte d administrateur. Fortes contraintes : En fonction du niveau de granularité des privilèges dans chaque technologie de SGBD il peut y avoir des difficultés de mise en œuvre. Une revue de sécurité est souhaitable. PAGE 22
Critère 2 : Scalabilité et dimensionnement Mutualisation physique Mutualisation système Mutualisation d'instances et de bases (variable selon le type de technologie employée) Bonne évolutivité, redimensionnement assez souple des machines virtuelles. Mais il existe des limitations à ce mode de fonctionnement du fait de la consommation de ressources additionnelles liée à la virtualisation (l hyperviseur consomme des cycles CPU). Une des limites de scalabilité tient au choix initial des machines (quantité de mémoire, de CPUs, etc.), et au choix de l architecture de la solution de virtualisation (cluster ou pas, multi-sites ou pas). Ce mode de mutualisation pose la question du choix du serveur physique de mutualisation, de son dimensionnement initial qui sera souvent un surdimensionnement (ce qui pose des problèmes d investissement et/ou de refacturation), de ses capacités d évolution (ajout de mémoire, de CPUs, etc.) Ce mode de mutualisation demande donc une connaissance par anticipation du capacity planning et des besoins des bases à mutualiser Ce type de mutualisation crée le risque de mettre en service des serveurs sous-utilisés, mais offre aussi l opportunité de mieux remplir un serveur peu actif. Dans ce type de configuration, il faut choisir entre un gros serveur monolithique ou une architecture grille ou cluster avec des nœuds qui s ajouteront selon l évolution des besoins. Attention cependant, les applications doivent être compatibles avec une architecture de SGBD grille ou cluster. Généralement ce type de mutualisation s effectue sur un gros serveur physique, ce qui constitue plutôt un atout. Il existe des profils de bases différenciés, ce qui offre des possibilités d optimisation des usages. Il faut conserver à l esprit qu avec ce modèle de mutualisation, certains paramètres sont appliqués à l ensemble des instances, ce qui signifie que le paramétrage de chaque instance sera moins fin. C est un modèle «transports en commun» vs «voiture individuelle». Le dimensionnement de ce type de configuration est assez simple car il n y a pas de machines virtuelles, un seul système d exploitation et une seule base : les couches basses restent simples. Peu d efforts à fournir en termes d architecture de la solution. Attention cependant, ce type de fonctionnement n est pas indéfiniment extensible : les discussions du Groupe de Travail indiquent que 20 bases ou instances constituent une bonne limite, même si ce n est pas une règle mais seulement un constat. PAGE 23 Bases de Données, Mutualisation et Consolidation, Critères de décision, Bonnes Pratiques LiVRE BLANC
Critère 3 : Sécurité De façon générale plus la mutualisation est poussée plus la connaissance du profil des applications devient sensible. Mutualisation physique Mutualisation système Mutualisation d'instances et de bases (variable selon le type de technologie employée) Ce mode de mutualisation permet de rassembler sur une même plate-forme des profils d application très différents, avec des comportements fortement hétérogènes. Cela impose tout de même de mieux spécifier le profil qu en mode natif. Il est nécessaire de caper l usage des ressources au niveau de l hyperviseur, opération plus simple à réaliser à ce niveau que sur des couches plus élevées (OS ou base de données). La maîtrise du profil applicatif doit être encore plus drastique que dans un scénario de mutualisation physique car la mise en commun de la plate-forme physique et de l OS risque de multiplier les goulots : ceux liés au matériel (saturation CPU par exemple) et ceux liés au système d exploitation. Si cette mutualisation système a lieu sur une plate-forme virtualisée, il faut aussi prendre en compte les possibles problèmes liés à la virtualisation. C est le cas le plus défavorable en matière de gestion de performances et de SLA du fait de l accumulation de couches mutualisées, ce qui rend la gestion des incidents et des changements plus complexe. En échange, l optimisation des ressources y est très poussée, et les tâches d exploitation se trouvent simplifiées (diminution du nombre de machines, de bases et d OS). Dans ces trois cas, il faut un outillage de métrologie pour capter les empreintes des profils d application et définir les comportements et les baselines de besoins de ressources. Cette opération s avère compliquée du fait du maillage et des interactions entre applications et bases de données dans les systèmes d information actuels. Critère 4 : Contraintes de RTO et RPO, contraintes de maintenance Mutualisation physique Mutualisation système Ce mode de fonctionnement apporte de la souplesse dans la maintenance (la machine virtuelle forme une couche d abstraction entre OS et matériel). Il n existe pas de différences concernant le RTO et le RPO d une base par rapport à une solution physique. Pour le reste, les contraintes de maintenance dépendent du choix des outils de virtualisation et de leurs options (outils de déplacement à chaud, etc.) et de l architecture générale de la solution de virtualisation. Ce type de configuration reste plus compliqué à mettre en œuvre qu une configuration non-consolidée ou qu une consolidation de niveau physique, ce qui rend aussi les RTO et RPO plus difficiles à garantir. En termes de point de reprise, il faut penser au niveau SGBD, pas seulement au niveau plate-forme de consolidation. PAGE 24
Critère 4 (suite) Mutualisation d'instances et de bases (variable selon le type de technologie employée) Critère 5 : Contraintes liées au domaine métier Ce point est toujours problématique et à traiter avec prudence. Mutualisation physique Mutualisation système Mutualisation d'instances et de bases (variable selon le type de technologie employée) Beaucoup de solutions tierces (applications) ne privilégient pas ce mode de fonctionnement, souvent par méconnaissance, et invoquent de possibles problèmes de performance. En raison de quoi, ce type de configuration n est pas supporté. Il apparaît aussi souvent difficile de faire adhérer les Métiers sur la virtualisation des bases. Fortes résistances donc. Dans ce type de configuration, il faudra établir un plan de production précis, en effet, l exécution parallélisée de batches sur des bases mutualisées de ce type peut engendrer des problèmes de performances. Plus généralement, ce type de consolidation nécessite une bonne cartographie de la part des Métiers sur les cycles de vie de leurs applications en termes de charge SQL. Dans ce type de configuration, il existe un risque de perte des plaques de cohérence et des logiques d isolation métier qui devra être prise en compte lors de l opération de consolidation. Critère 6 : Risques techniques liés à l infrastructure de mutualisation Attention au capacity planning de ces solutions! RAM et CPU devront être étroitement surveillés et il faut faire preuve de vigilance concernant les accès disques, selon leurs types et leurs segmentations, pour ces 3 niveaux de mutualisation. Mutualisation physique Dans le cas d une forte mutualisation de ce type, les impacts se montrent forcément plus importants : les contraintes de maintenance par exemple se trouvent mutualisées à tous les niveaux (matériel, OS, base), ce qui demande un planning particulièrement complet. Comme et plus encore que pour la mutualisation système, la reprise est compliquée à mettre en œuvre et à garantir car la granularité de l élément nécessaire au bon fonctionnement d une application est le schéma ou la base. Fiabilité technique aussi bonne que celle de l hyperviseur. Mode de mutualisation qui apporte des avantages pour les opérations de gestion des performances, avec des possibilités de contrôle sur la couche de virtualisation. Mais ces avantages dépendent du niveau et du type de virtualisation utilisée : firmware, Zones, hyperviseur, etc. Il existe un overhead lié à l emploi d un hyperviseur, qui peut peser sur les performances. PAGE 25 Bases de Données, Mutualisation et Consolidation, Critères de décision, Bonnes Pratiques LiVRE BLANC
Critère 6 (suite) Mutualisation système Mutualisation d'instances et de bases (variable selon le type de technologie employée) Fiabilité : sur Unix/Linux, il est rare que la défaillance d une base impacte le serveur mutualisé dans son ensemble. Généralement il reste possible d intervenir sur la base «défaillante» sans impacter le fonctionnement des autres bases. En revanche, si l OS tombe, toutes les bases tombent avec lui. Fiabilité : Les OS ne supportent pas tous aussi bien la cohabitation des instances. L isolation était historiquement mieux gérée sur les systèmes Unix. Il existe de toute façon un Single Point of Failure sur la partie serveur et OS. Fiabilité : Le fait de partager l espace de stockage fait courir le risque qu une base sature cet espace, ce qui nuirait au fonctionnement des autres. On peut choisir de créer des espaces dédiés à chaque base ou instance afin de préserver l isolation, mais au détriment de la volumétrie consommée. La gestion des performances reste le point le plus délicat dans ce type de mutualisation. Les traitements effectués sur une des bases peuvent impacter les performances de l ensemble du serveur d où la nécessité de bien dimensionner initialement le serveur et de connaitre le profil d activités des bases qui seront mutualisées. La bonne pratique consiste ensuite à caper au maximum chaque instance de base (lui attribuer une consommation maximum de ressources). Un troisième Single Point of Failure s ajoute au serveur et à l OS dans ce type de configuration : le moteur de bases de données lui-même. Nous sommes-là d un point de vue statistique dans la configuration la moins fiable. Il faut idéalement mutualiser des schémas liés au même profil d application (décisionnel, transactionnel). L utilisation d un gestionnaire de ressources (exemple : Resources Gouvernor) est recommandée pour caper l usage des ressources SQL au niveau des moteurs (et souvent au niveau du pool de connexion). Cela procure un arbitrage plus fin que le capage de niveau de mutualisation système. Critère 7 : Coûts Mutualisation physique Mutualisation système Coûts élevés car le niveau de consolidation reste faible (il reste encore plusieurs OS et plusieurs SGBD, auxquels s ajoute le coût de la virtualisation). Comme le serveur de mutualisation voit sa criticité augmenter, cela oblige à choisir une gamme de serveur/stockage plus performante et plus sécurisé (disponibilité) que ce qui pourrait être accepté pour une base isolée sur un serveur dédié. Donc généralement, il y a un ticket d entrée plus élevé pour une base candidate à la mutualisation. Normalement le coût à trois ans va en revanche se trouver optimisé du fait du meilleur taux d utilisation du serveur et du partage des coûts entre plusieurs utilisateurs. Les gains en coûts de licence sont variables selon le mode de facturation (instances, puissance de la plate-forme, utilisateurs, etc.) Il faut étudier l intérêt de changer de licence en cas de mutualisation. Mutualiser oblige à jouer le rôle de la banque puisqu on ne peut pas facturer d office la totalité de la ressource au premier utilisateur. Ce qui pose des problèmes de refacturation. PAGE 26
Critère 7 (suite) Mutualisation d'instances et de bases (variable selon le type de technologie employée) Critère 8 : Administration et exploitation Mutualisation physique Mutualisation système Mutualisation d instances et de bases (variable selon le type de technologie employée) C est la mutualisation à moindre cout (low cost), celle qui pousse le principe de mise en commun des ressources le plus loin avec une réduction du nombre de licences de bases de données. Il faut cependant que la criticité des applications associées soit moins importante que sur les autres niveaux de mutualisation. Il ne faut pas perdre de vue que, si cette solution est bon marché, une requête mal écrite peut pénaliser l ensemble de l instance mutualisée. Les bases candidates à cette mutualisation proviennent souvent du décommissionnement de serveurs obsolètes, ce qui procure des économies d espace et d énergie dans les datacenters. Gain de souplesse du fait de l utilisation des hyperviseurs, mais cela engendre une nécessité de répéter les opérations pour chaque VM. Possibilité d allocation dynamique de ressources. Attention cependant aux opérations de maintenance sur les hyperviseurs. Il est possible de mieux intégrer la notion de PRA grâce aux nouvelles infrastructures de virtualisation. En cas de passage de correctif sur les OS, un redémarrage serveur impacte toutes les bases. Si les binaires du SGBD sont utilisés par plusieurs bases mutualisées sur le serveur, les passages de correctifs impactent toutes les bases. L administration d un serveur mutualisé est plus facile que celle de plusieurs serveurs. En mutualisant, on évite la multiplication des petites bases (un schéma ou une base par instance) ce qui facilite l administration. Là encore, attention aux opérations de maintenance qui impactent l ensemble des bases. L arrêt - redémarrage d une base mutualisée devient beaucoup plus difficile surtout si la base mutualisée héberge des schémas d applications «hétérogènes». La restauration d un schéma particulier d une base mutualisée à une date précise peut se révéler compliquée. PAGE 27 Bases de Données, Mutualisation et Consolidation, Critères de décision, Bonnes Pratiques LiVRE BLANC
Critère 9 : Exigences techniques spécifiques au progiciel client de la base de données Mutualisation physique Beaucoup d éditeurs d applications ne certifient pas le fonctionnement avec une base virtualisée. Côté client, l utilisation reste transparente pour l accès à la base de données. Mutualisation système Mutualisation d instances et de bases (variable selon le type de technologie employée) N / A Il peut y avoir des incompatibilités (objets publics ayant des noms identiques). Les ERP ne se prêtent pas facilement à ce type de mutualisation. Il ne faut pas que l application attaque en direct le serveur et la base, surtout en cas de basculement. Il faut que le client progiciel sache manipuler des alias DNS et des ports sur les chaines de connexion. Chaque application doit posséder un alias DNS. PAGE 28
5 NOTE technique : les spécificités des différentes bases Bien qu elles rendent des services similaires, les bases de données possèdent des architectures techniques profondément différentes. Ces spécificités peuvent provoquer des effets de bord problématiques lors d opérations de mutualisation-consolidation. Les fiches qui suivent ne prétendent pas à l exhaustivité, mais rappellent quelques principes de base et soulignent en conséquence des points de vigilance à ne pas perdre de vue. Comme pour le reste de ce document, le périmètre des bases retenues reste Oracle, SQL Server, DB2 UDB et Sybase, les SGBD les plus répandus chez les membres actifs du Groupe de travail. 5.1. Les spécificités et le découpage logique des bases DB2 LUW et leurs possibilités de mutualisation Les notions d instance, de base et de schéma avec DB2 LUW Machine virtuelle ou physique (NT ou Unix) Variable d environnement DB2 (-g) Instance Inst1 (un nœud, un port) Variable d environnement instance (-i) Paramètres liés à l instance (dbm cfg) Database DB11 Variable d environnement base (db cfg) logs TS : syscatsp ace bufferpools TS: tempspa ce1 TS: TS1 pour l appli 1 TB1 IX1 Database DB1n TS : users pace1 Instance Inst2 (un nœud, un port) Database DB21 Database DB2x Database DB2z Instance Instn Database DBn1 Schéma : Exemple d architecture d une machine SGBD DB2 LUW mutualisée PAGE 29 Bases de Données, Mutualisation et Consolidation, Critères de décision, Bonnes Pratiques LiVRE BLANC
Associées à une machine (physique ou virtuelle), il existe des variables d environnement DB2. Elles peuvent être globales (-g) à la machine ou spécifiques selon l instance (-i). Avec DB2 LUW, une base peut-être partitionnée, c est-à-dire qu elle peut être répartie sur plusieurs serveurs. Cette notion de partionnement est utilisée pour des volumes de données importants et des applications gourmandes en CPU (exemple datawarehouse). On fait de l équilibrage de charge sur plusieurs machines. Dans ce document nous parlerons de base non partitionnée. Instance DB2 LUW (Inst) Une instance possède des variables d environnement dont la valeur peut être modifiée en ligne ou suite à un arrêt/relance. Donc si plusieurs applications partagent la même instance, il faut synchroniser l opération de mise à jour. Toutefois le nombre de paramètres associés à l instance est peu élevé. Les paramètres les plus souvent modifiés sont ceux associés à la base, notamment les paramètres mémoire. Avec les nouvelles versions de DB2 de plus en plus de paramètres deviennent modifiables en mode en ligne (online) ou de manière automatique. Exemples de paramètres d instance : Le paramètre authentification (serveur, client ou kerberos) : l analyse du droit de connexion aux bases de l instance est faite au niveau du serveur ou du client ou par kerberos. Il y a également la possibilité d utiliser un ldap. L emplacement du db2diag.log (le fichier de trace de l instance) et le niveau de trace diaglevel. Le nombre d agents maximum (maxagents) : une connexion à une base peut générer plusieurs agents DB2. Les groupes d habilitation sysadm_group, sysctrl_group, sysmaint_group, etc. On s attache à une instance et se détache d une instance. Sous une même instance, on peut avoir plusieurs bases : de 1 à n. n dépend de l utilisation et de la consommation des ressources de la base et du facteur de mutualisation des applications contenues dans ces bases. Base DB2 LUW (DB) La base en DB2 LUW est à la fois une vue logique et physique. De nombreux paramètres système sont associés à la base. Exemples de paramètres : Des paramètres mémoire comme le STAT_HEAP_ SZ (espace mémoire pour les runstats), UTIL_HEAP_SZ (espace mémoire pour PAGE 30
les utilitaires DB2), le MAXLOCKS (le pourcentage maximal de verrous qu une application peut contenir), locklist (la taille de la liste des verrous) ou locktimeout (la durée d attente d une requête pour l acquisition d un verrou). Locklist et maxlocks seront gérés de façon automatique à partir de la version 9 de DB2. Les journaux de transaction (logs) et journaux d archive sont associés à une seule base. Ils servent notamment en cas de rollback d une transaction ou restauration de la base. Les bufferpools sont des espaces mémoire tampon qui servent à faire du cache disque pour récupérer les données des requêtes. Chaque base possède son propre catalogue d objets stockés dans le tablespace dédié : le syscatspace. Le tablespace tempspace1 est un espace de travail pour la base pour les tris ou les jointures (grosses requêtes nécessitant cet espace). Le tablespace par défaut associé aux objets pour lesquels on n a pas précisé de tablespace spécifique est le userspace1. En général, chaque application, voire chaque table possède son propre tablespace. Si le tablespace de l index n est pas précisé, l index se retrouvera dans le même tablespace que la table. On se connecte à une base et une seule à un instant t. Pour qu une application connectée à une base puisse accéder à des objets d une autre base, il faut déclarer l instance en federated=yes et déclarer des nicknames (pointeurs) sur les objets de l autre base (du même serveur ou d un serveur distant). La base sert de point de référence dans une restauration logique : on sauvegarde la base et restaure la base. Bien que la restauration d un tablespace soit possible, elle est moins souvent pratiquée. Tablespace (TS) Le tablespace est un emplacement logique qui correspond à un ou plusieurs emplacements physiques du type SMS (gérés par le système) ou DMS (gérés par la base). Ces tablespaces peuvent être répartis sur des emplacements physiques distincts ou pas, que l on nomme containers. Mais bien souvent on passe par des définitions logiques comme les volumes groupes. Finalement il est très difficile de savoir sur quel disque physique se trouve la donnée. PAGE 31 Bases de Données, Mutualisation et Consolidation, Critères de décision, Bonnes Pratiques LiVRE BLANC
Les niveaux de mutualisation possibles dans DB2 LUW : instance, base et schéma Dans une machine ou sur un serveur virtuel dédié au SGBD DB2 LUW : Avec Unix, les instances peuvent partager la même version du code binaire ou être à des versions différentes. Avec Windows Server cela n est possible qu à partir de la version 9. Sur une même machine, nous pouvons avoir n instances du moteur DB2 LUW. A une instance est associé un nom de nœud logique et un numéro de port. La séparation des applications par instances est le plus haut niveau d isolation logique de ces applications sur une même machine. Il faut également qu il y ait une séparation physique des données stockées dans cette instance et des binaires associés à cette instance. Certains sites ne mutualisent les données qu au niveau des ressources de la machine, mais les applications se trouvent dans des instances séparées (exemple sur le schéma : Instn : une instance une base). La mutualisation peut-être encore plus poussée en faisant partager une instance par plusieurs applications, mais chaque application se trouve dans une base différente. C est le cas le plus courant avec DB2 LUW. Le plus bas niveau de mutualisation consiste à utiliser une base commune pour plusieurs schémas d applications différentes, cela signifie que la restauration de l application devra se faire par tablespaces et donc que la base sera forcément en mode log linéaire. (C est-à-dire que les journaux de transaction sont conservés et archivés après le commit de la transaction). Un tablespace et un schéma ne sont en général pas partagés par plusieurs applications. Il y a deux exceptions : les tablespaces syscatspace (le catalogue des objets de la base) et tempspace1 (qui sert notamment à l espace de tri de la base et pour les grosses requêtes, multi-jointures). En général, on isole les tablespaces user (c est-à-dire des applications) dans des filesystems différents, bien que cela soit une organisation logique, car sur les baies SAN, l organisation physique fait parfois que l on se trouve sur les mêmes disques physiques, notamment avec l utilisation de RAID 5. PAGE 32
5.2. Les spécificités et le découpage logique des bases SQL Server et leurs possibilités de mutualisation Les notions d instance, de base et de schéma avec SQL Server L instance Avec SQL Server le terme instance fait référence à une version du moteur SQL Server installée sur un hôte particulier (physique ou virtuel, standalone ou en cluster). Un hôte peut disposer de une à n instances SQL Server (la limite théorique étant de 50 instances sur un standalone et de 25 instances sur un cluster, limitation surtout dictée par les ressources matérielles de l hôte). Les versions d instances SQL Server qui peuvent cohabiter sur un même hôte vont de SQL Server 7 à la plus récente version SQL Server 2012. Une instance regroupe des propriétés déterminantes dont : la collation, les ports TCP/IP d écoute, la taille du buffer data, memtoleave, le nombre de CPU utilisés, les logins, les comptes de services, les caractéristiques activées (réplication, recherche fulltext, filestream, etc.), etc. La base de données Une fois l instance SQL Server installée, celle-ci peut héberger de une à n bases de données (en dehors des 4 bases systèmes nécessaires à son bon fonctionnement : master, model, msdb, tempdb). Chaque base de données est un regroupement logique d objets de base qui sont, pour les plus connus : les tables, les index, les procédures stockées, les vues, les déclencheurs, les fonctions, les permissions, etc C est à ce niveau que l on définit la structure, la logique et le stockage de l information que l on va devoir maintenir en base de données et restituer à la demande. PAGE 33 Bases de Données, Mutualisation et Consolidation, Critères de décision, Bonnes Pratiques LiVRE BLANC
Le schéma Avec SQL Server, le schéma est une notion de sécurité que l on va retrouver à une granularité plus fine au sein de la base de données afin de permettre le regroupement logique d un ensemble d objets (tables, procédures stockées, vues, etc.) accessible uniquement à une population particulière, généralement liée à des domaines fonctionnels. Typiquement, dans une base de données Comptabilité pourra être défini un schéma «Comptable» regroupant tous les objets de bases de données permettant la saisie des pièces comptables entrées tous les jours par les experts comptable d une société, et le schéma «Direction» regroupant l ensemble des objets de bases de données permettant au directeur financier d élaborer les différents tableaux de bords nécessaires au pilotage de son activité. La notion importante à retenir sur les schémas est qu ils coexistent dans la même base de données mais qu ils peuvent être auto-exclusifs et transversaux. Les experts comptables n accèdent pas aux objets du schéma «Direction» mais le schéma «Direction» peut lui accéder à tout ou partie des objets du schéma «Comptable» afin d y réaliser des checks par exemple. Les niveaux de mutualisation possibles avec SQL Server Les niveaux de mutualisation possibles avec SQL Server sont classés grâce aux notions précédemment définies. PAGE 34
La mutualisation d instance La mutualisation d instance suppose que l on installe sur le même host plusieurs moteurs SQL Server de version identique ou différente avec leurs bases de données systèmes et utilisateurs associées. En termes de mise en œuvre, le portage de l instance passe par une nouvelle installation d instance sur le nouvel host et une procédure de sauvegarde / restauration ou de copie des datafiles pour finir avec une reconfiguration des métriques ressources de la nouvelle instance (CPU, Mémoire, etc.) Les différentes instances partagent les ressources matérielles du host (Réseau, CPU, mémoires) et dans ce cadre, une configuration avancée de ces ressources sera nécessaire pour une bonne cohabitation (un profiling d instance sera nécessaire pour identifier l empreinte d activité engendrée par chaque workload). Exemple : Dans l exemple suivant notre host Windows dispose de plusieurs instances SQL Server de version 2008 et 2005 hébergeant leurs propres bases. PAGE 35 Bases de Données, Mutualisation et Consolidation, Critères de décision, Bonnes Pratiques LiVRE BLANC
La mutualisation de base de données Ici, seules les bases de données utilisateurs sont mutualisées sur une seule et même instance SQL Server déjà existante ou non, et suffisamment bien configurée pour supporter l activité de ces différentes bases de données. La mise en œuvre passe, généralement, par une procédure de sauvegarde / restauration de la base de données, suivie d une synchronisation de login/user (désormais elle n est plus nécessaire avec SQL Server 2012 grâce au contain db), jobs, SSIS, serveur liés éventuels. Une attention particulière sera apportée au sous-système disque de chaque base afin de bien repartir les I/Os. Dans la même approche que la mutualisation d instance, on pourra définir, pour chaque application et ses bases de données associées, au niveau de l instance hôte un port TCP/IP et un pool de ressources CPU/Mémoire grâce à l utilisation de l architecture NUMA et/ou l utilisation de la fonctionnalité du «Resource Gouvernor» disponible depuis la version 2008 de SQL Server. Exemple : Dans l exemple suivant, notre host Windows n héberge qu une seule instance SQL Server 2008 qui consolide plusieurs bases de données différentes (DB1, DB2, etc ) issues d applications diverses. PAGE 36
La mutualisation de schéma Ce niveau de mutualisation permet l introduction d un ensemble d objets de bases de données tables, procédures stockées, etc. associés à un schéma particulier dans une base de données existante sur une instance SQL Server. La mise en œuvre de cette mutualisation passe par l utilisation d outil d export / import de schéma. Si la création de DDL ne pose pas de problème particulier, l import de grosses volumétries de données dans les tables peut consommer beaucoup de ressources (stratégie de chargement sans index sur les tables, parallélisation, etc ). L outil historique d import/export de données SQL Server étant BCP. Une vigilance particulière est à apporter coté applications où il faut s assurer que le nom du schéma soit bien utilisé, faute de quoi le processus de résolution de noms de SQL Server peut-être très coûteux en temps. De plus, si les même noms d objets existent dans plusieurs schémas, SQL Server s arrêtant à la 1ere résolution, les résultats peuvent s avérer surprenants. Exemple : Dans l exemple qui suit, notre host Windows n héberge qu une seule instance SQL Server 2008 avec plusieurs bases de données (DB1, DBn, etc ) et dans chacune de celles-ci, nous avons consolidé différents schémas (regroupement des tables, procédures stockées, contraintes, etc. identifiés par un nom de schéma) propres à des applications particulières. PAGE 37 Bases de Données, Mutualisation et Consolidation, Critères de décision, Bonnes Pratiques LiVRE BLANC
5.3. Les spécificités et la découpe logique des bases Oracle et leurs possibilités de mutualisation Les notions d instance, de base et de schéma avec Oracle Au sens Oracle, la distinction est la suivante : Une instance est composée des différentes zones mémoire allouées ainsi que des processus (background process) nécessaires au fonctionnement de la base. Les caractéristiques principales d une instance Oracle sont définies dans un fichier d initialisation (spfile) contenant les paramètres d initialisation. une base est constituée de structures physiques et logiques utilisées pour stocker et traiter les données contenues dans la base. Un schéma est une collection d objets logiques dans la base (tables, indexes etc..). Un schéma a le même nom que le user de la database qui est le propriétaire du schéma et des objets associés. Structures Physiques d une base de données Oracle Une base de données Oracle est composée de différents types de fichiers physiques : Les fichiers de données (Datafiles) contiennent les données de la base. Les fichiers de contrôle (Control files) sont utilisés pour contrôler l intégrité physique de la base (ils contiennent en particulier le nom et l emplacement des fichiers). Les fichiers de journalisation courants et archivés (Redo log files, Archive log files) contiennent les changements effectués sur les données. Les fichiers d initialisation (spfile), d alerte (alert.log) et de trace. Structures Logiques d une base de données Oracle Les principales structures logiques sont les suivantes : Les tablespaces : Oracle stocke les données d un point de vue logique dans des unités logiques de stockage appelées tablespaces. A chaque tablespace correspond un ou plusieurs datafiles. On distingue les tablespaces SYSTEM et SYSAUX (utilisés pour les données système Oracle), le tablespace UNDO (utilisé lors des annulations de transactions) et les tablespaces USERS (utilisés pour stocker les données applicatives). Le dictionnaire de données référence les structures logiques et physiques, ce dictionnaire contient la définition des schémas et des objets de la base (parmi lesquels : tables, indexes, vues, triggers), le nom des users et les privilèges accordés. Les Schémas. Les Objets : tables, indexes, vues, synonymes, fonctions et procédures, triggers. PAGE 38
Structures mémoire d une base de données Oracle Oracle utilise de la mémoire pour stocker différentes informations (cache data, code programme, informations sur les sessions etc.) Il y a des zones mémoires partagées entre les différents background process et des zones mémoires propres à chaque process serveur. Schéma récapitulatif de l architecture d une base Oracle PAGE 39 Bases de Données, Mutualisation et Consolidation, Critères de décision, Bonnes Pratiques LiVRE BLANC
Les trois niveaux de mutualisation avec Oracle Mutualisation de niveau physique Définition Cette mutualisation consiste à faire coexister sur un même serveur physique (au moyen d un hyperviseur) plusieurs machines virtuelles (VM). Chaque VM dispose de son propre OS avec en général une seule version d Oracle installée par VM et héberge une ou plusieurs bases de cette version. Voici un exemple : PAGE 40
Particularités Oracle à prendre en compte pour ce type de mutualisation Deux aspects principaux sont à prendre en considération : La certification et le support des versions Oracle pour ce type d environnements virtualisés. Ainsi pour VMware (cf note Oracle «Support Position for Oracle Products Running on VMWare Virtualized Environments [ID 249212.1») Oracle ne certifie pas tous ses produits et versions sur les environnements virtualisés VMWare. Oracle fournit le support sur les problèmes connus sur les OS natifs ou sous réserve de démontrer que le problème rencontré n est pas la résultante de l exécution en environnement virtualisé VMWare. Pour un problème connu, Oracle recommande d appliquer la solution appropriée sur l OS natif. Si cette solution ne marche pas en environnement mutualisé VMWare, il faut s adresser au support VMWare ou apporter la démonstration à Oracle que la solution ne fonctionne pas sur l OS natif pour que le support Oracle prenne en compte le bug rencontré. Performances : Le paramétrage des VM et l administration de l hyperviseur sont essentiels. En général (tout dépend bien sûr du niveau de mutalisation atteint sur l hyperviseur), on constate que les traitements lourds qui génèrent beaucoup d I/Os présentent des performances dégradées par rapport à des serveurs physiques. Pour ces deux raisons, ce type de virtualisation pour des bases Oracle reste essentiellement limité au déploiement rapide et à moindre coût d environnements de développement et tests. PAGE 41 Bases de Données, Mutualisation et Consolidation, Critères de décision, Bonnes Pratiques LiVRE BLANC
Mutualisation de niveau système d exploitation Définition Regrouper (ou migrer) sur un même serveur physique (ou virtuel) plusieurs bases Oracle. L organisation logique de chaque instance mutualisée ne change pas (chaque instance conserve ses propres tablespaces et schémas initiaux). Pour chaque instance mutualisée, un redimensionnement de certains paramètres (en particulier les différentes zones mémoire) pourra être nécessaire en fonction des caractéristiques du serveur cible qui héberge les bases mutualisées et de la charge déjà induite par les bases mutualisées. Pour chaque base oracle à mutualiser, différentes techniques de migration (outils export / import, restauration d un backup rman, etc.) sont possibles selon les différences de stockage, de version d Oracle entre les serveurs physiques source et destination sans compter les impératifs de service (temps mis pour migrer). Voici un exemple : PAGE 42
Particularités Oracle à prendre en compte pour ce type de mutualisation Compatibilité entre les environnements sources non mutualisés et la cible mutualisé En particulier, on sera vigilant sur les points suivants : - Stockage : un changement de stockage (par exemple passage de Unix FileSystem à Oracle ASM ) est possible mais a des impacts sur le mode opératoire et les techniques de migration utilisés. - OS : la version d OS du serveur mutualisé doit supporter la version d Oracle de la base source à mutualiser (sauf bien sûr si la mutualisation de serveur s accompagne également d une migration de version d Oracle ce qui est souvent le cas dans ce type de mutualisation). L ordre dans lequel les octets sont organisés et traités (orientation big-endian et little-endian) peut différer selon les OS et processeurs et peut également impacter les techniques de migration utilisées pour mutualiser. - Versions d Oracle (RDBMS) : une installation d une nouvelle version d Oracle sur le serveur mutualisé peut dans certains cas être nécessaire si l on souhaite migrer à isopérimètre de version Oracle lors de la mutualisation - Version d Oracle (ASM) : en configuration ASM (Automatic Storage Management), il n est pas possible d héberger une base Oracle de version supérieure à celle de l instance ASM du serveur de bases de données Des choix sont à effectuer concernant la gestion des versions Oracle installées sur le serveur mutualisé en terme d installation (comptes utilisés, politique de sécurité pour isoler les versions), de politique de patches (releases majeures et patchsets supportés, fréquence d application des patchsets, impact en termes d arrêt de service). - Pour des bases de même release, une même version des binaires d Oracle (ORACLE_HOME) est le plus souvent partagée (mutualisée) entre ces bases. - Pour une même release, on maintient le plus souvent une seule version (niveau patchset) sur un serveur mutualisé et on est amené à effectuer des migrations (release mineure) lors de la mutualisation Gestion de l espace disque alloué à l ensemble des bases : une attention particulière sera portée à l espace alloué aux archives logs ainsi qu aux mécanismes de sauvegarde et purge de ces archives logs (configurée en mode archive log ce qui est, sauf exception, le cas le plus courant en production une base Oracle se fige si elle ne peut plus archiver les fichiers redo log). PAGE 43 Bases de Données, Mutualisation et Consolidation, Critères de décision, Bonnes Pratiques LiVRE BLANC
Mutualisation de niveau bases de données Définition Regrouper par migration plusieurs schémas issus de différentes bases au sein d une même base. Selon la nature des applications et le nombre d objets liés aux schémas à migrer, il peut être recommandé (mais non obligatoire) de conserver une isolation logique des schémas mutualisés (tablespaces séparés par schémas). Voici un exemple : PAGE 44
Particularités Oracle à prendre en compte pour ce type de mutualisation Dans ce type de mutualisation, les prérequis à vérifier sont d abord au niveau Oracle entre le(s) schéma(s) de la base native et la base cible qui mutualise les schémas. Parmi les principaux prérequis, on notera : Bien sûr la version d Oracle : la base mutualisée doit avoir une version au moins égale ou supérieure à la base source. Character set : il peut y avoir des incompatibilités de character set entre la base source et la base mutualisée (cf. notes Oracle sur les compatibilités). Cet aspect concerne l encodage des caractères en base, les langues qui doivent être supportées au niveau des données stockées en base imposent des character sets particuliers. Contraintes d unicité dans le nommage de certains objets de la base : les noms de schémas sont uniques, impossible donc de mutualiser dans une base deux schémas de même nom issus de 2 bases différentes. De même il peut y avoir des incompatibilités au niveau des objets publics (accessibles par tous les schémas). Fortes contraintes de sécurité : dans ce type de mutualisation, il est très souvent demandé une isolation entre les schémas (faire en sorte qu un schéma n ait pas les droits pour voir les données d un autre schéma de la base mutualisée). Cela demande une gestion rigoureuse des privilèges accordés, certains privilèges (comme le privilège SELECT ANY TABLE permettant de voir les données de chaque schéma) ne doivent absolument pas être accordés dans ce type de mutualisation. Backup / Restauration : dans une base mutualisée, la restauration d un schéma particulier (et non de l ensemble de la base) et en plus à une date précise est plus compliquée à mettre en œuvre (plusieurs techniques selon le backup utilisé : export / import, utilisation d un clone Rman, etc.) Impact sur le dictionnaire de données : en mutualisant, on augmente le nombre d objets (tables par exemple) et donc le nombre de définitions de ces objets stockées dans le dictionnaire de données. Les temps de réponse de requêtes qui interrogent les vues du dictionnaire peuvent s en trouver fortement dégradés. On évitera donc de mutualiser un trop grand nombre de schémas au sein d une même base ou de mutualiser par exemple des schémas utilisés par des ERP (milliers de tables). Outre ces spécificités purement Oracle, il conviendra de bien noter que les arrêts de service nécessaires par exemple pour patcher ou pour redémarrer la base pour prendre en compte la modifications de certains paramètres d initialisation sont beaucoup plus compliqués à mettre en œuvre pour une base fortement mutualisée. PAGE 45 Bases de Données, Mutualisation et Consolidation, Critères de décision, Bonnes Pratiques LiVRE BLANC
5.4. Les spécificités et le découpage logique des bases Sybase et leurs possibilités de mutualisation L instance Avec Sybase le terme instance fait référence à une version du moteur du SGBD installée sur un hôte particulier (physique ou virtuel, standalone ou en cluster). Un hôte peut disposer de une à n instances Sybase. Compte tenu du mode de fonctionnement Sybase, la mutualisation de plusieurs moteurs sur un même serveur physique ou virtuel n est pas conseillée et présente un risque fort d impact sur les performances de l ensemble du serveur. Une instance regroupe des propriétés déterminantes dont : les ports TCP/IP d écoute, la taille des zones mémoire, le nombre de CPU utilisés, les logins, les comptes de services, les caractéristiques activées, etc. La base de données Une fois l instance Sybase installée, celle-ci peut héberger de une à n bases de données (en dehors des bases systèmes nécessaires à son bon fonctionnement : master, model, syb, system, procs, sybtempdb tempdb, etc.) Chaque base de données est un regroupement logique d objets de base qui sont, pour les plus connus : les tables, les index, les procédures stockées, les vues, les déclencheurs, les fonctions, les permissions, etc. C est à ce niveau que l on définit la structure, la logique et le stockage de l information que l on va devoir maintenir en base de données et restituer à la demande. PAGE 46
La mutualisation de bases de données Les bases de données utilisateurs sont mutualisées sur une seule et même instance Sybase suffisamment bien configurée pour supporter l activité de ces différentes bases de données. Une attention particulière sera apportée au sous-système disque de chaque base afin de bien repartir les I/Os. Le nombre de bases théoriquement gérable par l instance est élevé (250). Dans la pratique le découpage par instance et base peut se faire de la manière suivante : Regroupement des bases liées à un domaine métier. Séparation des instances Batches, transactionnelles et décisionnelles. En cas de forte exigence de performance, il faut dédier une instance et une base sur un serveur physique ou virtuel. Une attention particulière doit aussi être apportée aux espaces de travail. (Tempdb sur le schéma). En cas de contention sur cette zone, il est possible de dédier des espaces disques séparés aux différentes bases. PAGE 47 Bases de Données, Mutualisation et Consolidation, Critères de décision, Bonnes Pratiques LiVRE BLANC