EXAMEN PROFESSIONNEL DE TECHNICIEN DE CLASSE SUPERIEURE DES SYSTEMES D’INFORMATION ET DE

COMMUNICATION DU MINISTERE DE L’INTERIEUR

- SESSION 2016 -

Epreuve écrite du jeudi 11 février 2016

L’épreuve écrite unique d’admission consiste à partir d’un dossier à caractère technique, en une étude de cas faisant appel à des connaissances relatives à l’environnement et à la technique des systèmes d’information et de communication et permettant de vérifier les capacités d’analyse et de synthèse du candidat ainsi que son aptitude à dégager des solutions appropriées.

L’épreuve porte sur l’un des deux thèmes suivants soumis au choix du candidat le jour de l’épreuve écrite :

- Les réseaux de télécommunications et équipements associés ; - La gestion des systèmes d’information

LA GESTION DES SYSTEMES D’INFORMATION

Durée 3h00

Le dossier documentaire comporte 16 pages.

IMPORTANT

IL EST RAPPELE AUX CANDIDATS QU’AUCUN SIGNE DISTINCTIF NE DOIT APPARAITRE NI SUR LA COPIE NI SUR LES INTERCALAIRES.

ECRIRE EN NOIR ET EN BLEU - PAS D’AUTRES COULEURS

LA CALCULATRICE N’EST PAS AUTORISEE

2

Étude de cas : Architecture & Systèmes

Contexte :

Vous êtes affecté(e) à la Direction des Systèmes d'Information et de Communication (DSIC) du Ministère de l'Intérieur, dans une équipe d'administrateurs de base de données.

Votre service souhaite mettre en place un programme de rationalisation et de sécurisation des systèmes de gestion de base données. Plusieurs applications fonctionnent, en effet, avec un logiciel de base de données obsolète et doivent migrer vers un socle technique à l'état de l'art.

Travail demandé :

Votre chef de service vous demande de rédiger une note argumentée à son attention détaillant

votre approche méthodologique dans le cadre de la mise en place de ce projet.

Vous devrez prendre en considération les problématiques d'exploitation et de sécurité.

DOSSIER DOCUMENTAIRE :

DOCUMENT 1 Exemples d’applications concernées par le projet Page 3

DOCUMENT 2 Pages 4 à 5

DOCUMENT 3 Pages 6 à 9

DOCUMENT 4 Extrait du cadre de cohérence technique du ministère de l’intérieur

Pages 10 à 12

DOCUMENT 5 Extrait du guide de transition à PostgreSQL : aide à la décision

Pages 13 à 18

Comment protéger ses bases de donnéessource : site http://www.itespresso.fr/blog/comment-proteger-ses-bases-de-donnees du 11 mai 2015, par HiscoxLa migration de données dans la gestion de données source : site http://www.decideo.fr/La-migration-de-donnees-dans-la-gestion-de-donnees a6008.html

Auteur : Patrick COFFRE, Talend, le 21 mars 2013

3Document 1

Exemples d'applications concernées par le projet

Le tableau ci-dessous reprend quelques paramètres d'applications qui sont concernées par le projet qui vous est confié.

Il s'agit d'applications-types, sachant que votre étude doit adresser l'ensemble des applications qui fontionnent avec des briques logicielles de base de données obsolètes.

Application Alpha Application Beta Application Gamma

Type d'application Réglementaire Sécurité Budgétaire

Sensibilité Elevée Elevée Moyenne

Haute disponibilité Non Non Non

Nombre d'utilisateurs

400 3000 1200

Plage de service 8h - 18h 24h/24 8h - 18h

Système d'exploitation

AIX 5.3 RHEL 4 AIX 5.2

Serveur de base dedonnées

Oracle 10gR2 MySQL 5.0 Oracle 10gR2

Serveur applicatif Tomcat 5.5 PHP 5.0 Tomcat 5.5

Volumétrie de labase de données

3 To 300 Mo 250 Go

Nombre de tables 120 40 200

4

Document 2

Comment protéger ses bases de données source : http://www.itespresso.fr/blog/comment-proteger-ses-bases-de-donnees du 11 mai 2015 par Hiscox

Vitales pour les entreprises, les bases de données stratégiques doivent faire l’objet du plus grand soin. L’attention doit à la fois se porter sur la protection des accès et sur le respect des règles qui visent à protéger les données personnelles qu’elles contiennent.

Les bases de données sont à la fois le cœur et le cerveau numériques des entreprises. C’est en elles et autour d’elles que se constitue leur richesse intellectuelle. Les protéger est donc essentiel. Mais, les protéger de qui ou de quoi au juste ? Il faut à la fois les défendre des agressions externes mais également internes à l’entreprise qui les détient. Si l’idée d’un vol de données vient tout de suite à l’esprit, il ne faut pas oublier les questions relatives à la violation des droits des personnes dont les données personnelles sont enregistrées dans une base. En plus d’une amende, la Cnil peut sanctionner l’entreprise victime d’une cyber-attaque, et qui n’aurait pas déclaré la détention de bases de données personnelles, en lui imposant une publication de la sanction dans la presse…

Une base de données au sens juridique du terme, c’est avant tout un investissement. Celui-ci doit être documenté. Autrement dit, il convient de garder une trace de la mise en place des outils de traitement et de collecte des données ainsi que de leur maintien en bon état opérationnel (mises à jour, upgrade, etc.).

L’ennemi, c’est la passivité

Le b.a.-ba de la sécurisation des bases des données porte bien sûr sur le contrôle et la limitation de leur consultation. Les codes d’accès sont la clé de voûte de ces mesures. L’heure n’est plus au « mot de passe », mais à la « phrase de passe » dont seule la taille permet de résister à une attaque en force brute, lorsqu’un ordinateur hostile bombarde la cible de plusieurs milliers de combinaisons à la seconde. Mais, au quotidien, cette saisie est fastidieuse. Une fois mis en place, les systèmes à double identification cumulent l’avantage de la fiabilité sans l’inconvénient de la lourdeur de la procédure.

Face aux attaques, le point faible d’une défense est toujours sa passivité. En matière de gestion des droits d’accès, il convient donc d’instiller le plus de dynamisme possible. Cela revient à démultiplier les paramètres pour les autorisations : instaurer des accès uniques ou à durée limitée, identifier individuellement les utilisateurs, qu’ils soient ou non membres de l’entreprise, et circonscrire leurs droits d’utilisation à leurs

5

stricts usages. Enfin, une gestion précise des plages horaires d’accès à la base permet aussi d’éviter les intrusions à des moments improbables, comme au milieu de la nuit ou durant les jours fériés.

Qui dit bases de données stratégiques, dit données personnelles. Dès lors que les données enregistrées permettent d’identifier des personnes physiques, l’existence et la gestion des bases sont soumises à des règles légales. La plus importante réside dans la déclaration auprès de la Cnil (Commission informatique et libertés). Manquer à cette obligation expose à des amendes qui peuvent dépasser allègrement la centaine de milliers d’euros. Depuis juillet 2014, les inspecteurs de la Cnil et ceux de la DGCCRF (Direction générale de la consommation et de la répression des fraudes) peuvent procéder à des contrôles inopinés.

Édictées dans le souci de protéger les personnes, les règles en vigueur imposent aux producteurs de bases de données un devoir d’information auprès de ceux dont ils collectent et traitent les données personnelles. Dans certains cas, leur consentement express est même requis (opt-in). La loi Informatique et libertés précise aussi que la collecte des données doit correspondre à un but précis et légitime. Une fois enregistrées, elles doivent être tenues à jour et ne peuvent être conservées pour une durée illimitée.

Les astuces pour tracer les pirates

Contrairement à celles du monde concret, les effractions numériques ne laissent que

rarement des traces. Voici deux astuces simples pour être alerté si des données

subtilisées ressurgissent. Glisser quelques coquilles ou des données fictives dans

ses bases permet d’identifier l’origine d’une fuite. De même que l’ajout d’adresses

mail factices créées pour surveiller l’envoi de mailing à partir d’une base.

Les textes en vigueur

La base de données est définie par l’article L.112-3 du Code de la propriété

intellectuelle comme un “recueil d’œuvres, de données ou d’autres éléments

indépendants, disposés de manière systématique ou méthodique, et individuellement

accessibles par des moyens électroniques ou par tout autre moyen”.

Le producteur de base de données est celui qui “prend l’initiative et le risque des

investissements correspondants”. Il bénéficie d’une protection du contenu de sa base

“lorsque la constitution, la vérification ou la présentation de celle-ci atteste d’un

investissement financier, matériel et humain substantiel” (article L.341-1 du Code de

la propriété intellectuelle).

6

Document 3

La migration de données dans la gestion de donnéesSource : http://www.decideo.fr/La-migration-de-donnees-dans-la-gestion-de-donnees a6008.html

Auteur : Patrick COFFRE, Talend, le 21 mars 2013.

En matière de technologie d’entreprise, « remplacer du vieux par du neuf » est plus facile à dire qu’à faire. À partir du moment où une entreprise décide de mettre à jour ses logiciels, systèmes d’exploitation, serveurs, méthodes de stockage ou plates- formes, les données existantes doivent être déplacées. La migration des données est également nécessaire lors de fusions ou acquisitions. Or, lors de la migration et la consolidation des données, plusieurs points importants sont à prendre en compte, notamment en termes de coûts, de conformité juridique, de conservation et d’accessibilité. L’objectif final d’une migration des données peut inclure la consolidation des systèmes, la création de sauvegardes plus rapides ou plus simples, l’optimisation des fonctionnalités, la modernisation du matériel et/ou une plus grande continuité des services de support.Les données existent dans de nombreux formats et, par conséquent, la migration des données peut englober de nombreux types de transitions. Elle peut ainsi impliquer de transférer les données de supports de stockage vieillissants vers un modèle plus récent, comme la mise à niveau des cartouches à 9 pistes ou DLT archaïques vers des cartouches LTO-4 ou LTO-5 plus modernes. Elle peut aussi entraîner le transfert du contenu d’une archive ou d’un référentiel de documents vers une nouvelle plate-forme, telle que Microsoft® Sharepoint®, le déplacement des données vers une plate-forme de stockage hébergée, ou encore la transition vers une version plus récente d’une application. Une entreprise peut décider d’effectuer une mise à niveau vers une version plus récente de Microsoft® Exchange, voire de consolider de multiples banques d’informations Exchange. La consolidation des données peut avoir pour objectif de réaligner les données sur un serveur centralisé et peut aussi inclure la diminution des redondances (c’est-à-dire, la dé-duplication).

La proactivité, ou comment planifier l’inévitable

Quel que soit le type de migration, il est possible de réduire les coûts et d’améliorer l’efficacité en prenant des mesures pour se préparer convenablement à un tel événement ; l’entreprise peut alors rester dans les limites de son budget, préserver la qualité et l’intégrité des données, satisfaire les impératifs de conformité et empêcher la perturbation de ses activités qu’entraîne l’échec des efforts de migration des données. Pourtant, dans beaucoup d’entreprises, la migration des données est traitée de manière réactive, plutôt que proactive. Or, il est important de planifier l’inévitable pour prévenir le risque associé aux décisions ad hoc quand arrive le moment de la transition.

7

La création et la mise en place d’une approche structurée, répétable et rigoureuse est donc le meilleur moyen de se préparer à la migration des données, un événement aussi inéluctable que la prochaine mise à niveau technologique.

Qu’implique précisément la planification préalable de la migration des données ? Pour une planification efficace, deux stratégies importantes sont la mise en place d’un fonds dès maintenant pour offrir plus d’options ultérieurement à l’entreprise et l’anticipation des difficultés. La facilité du projet dépendra de facteurs tels que la complexité et le nombre de sources à partir desquelles les données devront être migrées, le volume de données, les délais à respecter tels que dictés par les besoins de l’entreprise et la qualité des données ou supports à proprement parler. Durant la planification, l’entreprise doit également analyser tous les aspects du problème afin d’accroître ses chances de réussite.

Un autre point à prendre en compte est le processus en soi. La migration des données ne se limite généralement pas au transfert des fichiers d’un support de stockage à un autre. Outre le transfert physique des données d’un support à un autre (par exemple, d’une cartouche magnétique ou d’un disque vers une clé mémoire USB ou un CD), le résultat final doit également être rendu accessible et exploitable. Par exemple, les données au format EBCDIC (Extended Binary Coded Decimal Interchange Code) doivent être converties en ASCII (American Standard Code for Information Interchange) pour pouvoir être lues. Les bases de données anciennes doivent être reformatées pour être adaptées à la nouvelle base de données de sorte que les données soient exploitables. Si bon nombre de grandes entreprises disposent à la fois des ressources techniques et financières et des moyens d’effectuer des migrations de données efficaces en interne, beaucoup peuvent également gagner à s’appuyer sur une expertise extérieure pour gérer les migrations de données.

Toute tentative de consolidation ou de migration recèle des difficultés potentielles. Par exemple, un support physiquement endommagé peut signifier que les données sont en train de s’altérer et de devenir inutilisable ; il est également possible que les tentatives de migration passées aient été incomplètes faute d’avoir validé les anciennes sauvegardes. Les fichiers ou systèmes peuvent être altérés, l’accès peut être restreint ou la migration peut inclure des informations redondantes qui ont été sauvegardées plusieurs fois à plusieurs endroits.

Une expertise indispensable

Les experts possèdent les ressources, les outils, la formation et les méthodes nécessaires pour surmonter la plupart des difficultés qui entravent la réussite des migrations, éviter les risques et les échecs caractéristiques des approches « maison » et, point très important, préserver la sécurité et l’intégrité des données. Ils peuvent également collaborer avec l’entreprise pour que l’interruption des activitéssoit la plus faible possible.

8

Par exemple, au cours d’une migration Microsoft Exchange, ils peuvent garantir le flux de communication, la continuité et la connectivité des clients même durant le processus de migration.

En outre, en collaborant avec un expert qui propose des offres de services étendues, une entreprise gagne à optimiser la continuité (et donc réduire les coûts) de l’ensemble de ses processus de données. Par exemple, la réduction des entrepôts de données redondants et massifs en un unique jeu de données via le processus de déduplication fait baisser le volume de données global (et les coûts) et donne naissance à un jeu de données interrogeable et prêt pour la production de documents dans le cadre de litiges qui sera plus rapide et moins onéreux à passer en revue en cas de besoin.

Enfin, la mise à niveau vers de nouveaux systèmes et logiciels offre une opportunité naturelle pour gérer le cycle de vie des informations. Ce faisant, l’entreprise doit faire attention à trouver le juste équilibre entre conservation excessive et conservation insuffisante. L’accessibilité continue aux données doit être garantie à des fins internes, de conformité réglementaire et de conservation à des fins juridiques, et les risques envers la sécurité doivent être atténués pour protéger les ressources en informations. Parallèlement, la conservation excessive peut inutilement ponctionner les budgets, élever les risques durant le processus d’e-discovery et augmenter le coût d’une investigation, d’un litige ou d’une fusion-acquisition. Pour parvenir au juste équilibre, le conseil d’un expert en données, ainsi que des experts techniques et des départements juridique et informatique de l’entreprise, peut aider à établir quelles données doivent être conservées et pendant combien de temps, ainsi que les meilleures méthodes pour conserver les données nécessaires dans un format accessible, efficace et exploitable.

Une migration peut se définir comme étant le passage d'un état existant d'un système d'information ou d'une application vers une cible déterminée dans un projet ou un programme. La migration d’application, de version de bases de données ou de nouveau système ne sont pas les seuls types de migration. Les données doivent être transposées : le but d’une migration de données est de transférer les données existantes, sous un format approprié, dans le nouvel environnement.

Lors d’une migration de données, on peut rencontrer certaines difficultés, notamment parce que les migrations concernent souvent des volumes importants de données. La migration peut concerner des listes de clients, toute la comptabilité ou même l’historique de l’entreprise. Puis, après avoir effectué la migration, une cohérence doit être maintenue entre les systèmes. Quand plusieurs bases de données ne sont pas migrées en même temps ou quand un système est implémenté de manière progressive, il faudra effectuer des synchronisations au sein de celui-ci.

9

La gestion de données volumineuses (qui peut faire partie d’une problématique Big Data) ou le Cloud sont des sujets d’actualité, que l’on retrouve souvent dans la presse et les médias. L’émergence de données complexes émanant des réseaux sociaux, de logs de sites web, d’archives photographiques ou vidéos, données astronomiques ou biologiques et bien d’autres ont conduit à l’essor du Big Data dans l’actualité ; l’apparition du Cloud Computing a amené un flot nouveau d’information dont on parle dans la presse spécialisée et généraliste. Même si la migration de données est un sujet moins actuel, elle n’en reste pas moins essentielle dans la gestion de données et devrait être considérée comme un élément clé dans la gestion d’une base de données.

Suite à la migration de données, des administrateurs peuvent se retrouver avec des diminutions ou des erreurs de qualité de données : dû à l’entrée de nouvelles données dans une base, la détérioration à cause de manipulations de données, ou les changements par processus interne (traitement, nettoyage ou purge des données). Ces diminutions de qualité peuvent entraîner des erreurs de données : la qualité de données permet de corriger les problèmes éventuels.

Surtout, il s’avère important d’obtenir des données de qualité pour assurer la cohérence de l’information et avoir une base de données sure pour pouvoir effectuer des analyses fiables. La migration de données parait essentielle pour une gestion des données réussie, même si des sujets plus en vogue ont davantage la faveur des médias. C’est pourquoi des logiciels de gestion de données comme ceux d’éditeurs open source comme Talend, qui simplifie cette étape de la gestion de données, sont particulièrement appréciés des départements informatiques de nombreuses sociétés. Avantage de ces solutions, les logiciels rendent possible par la suite de travailler sur la synchronisation, qualité ou gouvernance de données.

Document 4 Extrait du cadre de cohérence technique du ministère de l'intérieur

10

11

12

13

Direction Interministérielle des Systèmes d'Information et de Communication Socle Interministériel du Logiciel Libre 19 Mars 2015

Document n°5

Extrait du guide de transition à PostgreSQL : aide à la décision - Version 1.0

Introduction

Ce guide a été réalisé dans le cadre de la mise en œuvre de la circulaire « Ayrault » du 19 septembre 2012 relative à l'usage du logiciel libre dans l'administration, qui a induit la constitution d'un Socle Interministériel du Logiciel Libre (SILL). Comparativement aux solutions commerciales, ce guide présente la mise en œuvre de PostgreSQL. Il a pour objectif de répondre aux interrogations des maîtres d'ouvrage et maîtres d’œuvre pour la mise en œuvre de PostgreSQL en remplacement d'une solution commerciale. Ce guide a pour objectif, sans entrer dans le détail de l'implémentation technique, de démontrer l'intérêt de PostgreSQL en décrivant les mécanismes d'intégration, de sécurité et de robustesse.

1 - Satisfaire les besoins des maîtres d'ouvrage

1.1 - Les types d'usage PostgreSQL est un système de gestion de bases de données au standard SQL utilisé classiquement dans les applications transactionnelles pour assurer la persistance des données comme tout produit commercial du même type (Oracle, DB2, Informix, MS SQL,Sybase,...). PostgreSQL a déjà été mis en œuvre pour répondre aux besoins des maîtrises d'ouvrage. PostgreSQL propose une extension pour la géomatique (PostGIS) conforme aux standards de l'Open Geospatial Consortium (OGC). PostgreSQL est également utilisable dans le domaine de l'informatique décisionnelle comme entrepôt de données en liaison avec les outils de reporting (BusinessObjects, Pentaho,...). De nombreux progiciels libres s'appuient nativement sur PostgreSQL (Gestion Électronique de Documents (GED), Moteurs de règles, GroupWare, Supervision,...). PostgreSQL supporte également les traitements d'arrière plan comme les traitements par lots ou différés (batch,...).

1.2 - Accès aux données PostgreSQL est conforme à la norme SQL 2011, le langage de requête commun à de nombreux SGBD. La migration est ainsi facilitée entre SGBDs respectant les standards.

1.3 - Les besoins de sécurité PostgreSQL répond aux besoins de sécurité exprimé en terme de disponibilité, d'intégrité, de confidentialité et de traçabilité (DICT1). Les besoins de cryptographie et d'authentification forte sont couverts par des modules complémentaires. PostgreSQL dispose d'une communauté très réactive qui fournit les patchs correctifs de sécurité et assure la gestion de l'obsolescence des composants. Une version majeure est supportée pendant 5 ans. PostgreSQL garantit l'intégrité des données manipulées même en cas d'incident par ses propriétés d'atomicité, de cohérence, d'isolation et de durabilité (ACID2). PostgreSQL offre nativement les mécanismes permettant de répondre aux besoins de confidentialité, de gestion des droits. Les propriétés ACID sont également garanties par des mécanismes assurant la gestion des transactions.

14

1.4 - Scénarios de migration des SI vers PostgreSQL La migration d'un SI représente un coût non négligeable constitué principalement:

• de la migration des données, même s'il existe de nombreux outils permettant de réaliser cettemigration en fonction des SGBD source ;

• des corrections à faire dans le code source de l'application. L'importance des adaptationsest liée à l'usage des fonctionnalités spécifiques au produit existant (procédures stockées, triggers, fonctions non standards) et l'utilisation d'une couche d'abstraction (Hibernate) ;

• de la recette permettant de garantir à iso-fonctionnalités, qu'aucune erreur n'a été induite lors dela migration (tests de non régression).

De ce fait, les migrations vers PostgreSQL ne s'effectuent que lors d'une évolution fonctionnelle de l'application. Le coût de migration est intégré au projet dans son ensemble notamment en terme de recette technique et fonctionnelle. (Cas des MEDDEMLET et DGFiP). Cependant un plan ambitieux de migration globale des SI peut être programmé (cas du ministère des affaires sociales qui a entrepris une migration programmée de ses SI de Informix vers PostgreSQL).

2 - Intégration de PostgreSQL sur les plateformes techniques

2.1 - Plateformes techniques 2.1.1 - Architecture processeur PostgreSQL fonctionne sur les architectures processeur suivantes : x86, x86_64, IA64, PowerPC, PowerPC 64, S/390, S/390x, Sparc, Sparc 64, Alpha, ARM, MIPS, MIPSEL, M68K et PA-RISC.

2.1.2 - Système d'exploitation PostgreSQL fonctionne sur la plupart des systèmes d'exploitation. Il existe des versions binaires pour la famille Red Hat (incluant CentOS/Fedora/Scientific), la famille Debian GNU/Linux et ses dérivées, la famille Ubuntu Linux et ses dérivées, SuSE, OpenSuSE, Solaris, Windows, MacOSX, FreeBSD, OpenBSD. Les codes sources sont disponibles.

2.1.3 - Compatibilité avec les technologies de virtualisation PostgreSQL est compatible avec notamment VMWare et KVM. Cependant la pertinence de la virtualisation des bases de données est à vérifier. La virtualisation apporte des avantages en matière de résilience. Les éditeurs d'outils de virtualisation et la communauté PostgreSQL fournissent des recommandations pour optimiser la configuration de PostgreSQL sur ces environnements. De manière générale, PostgreSQL a les mêmes limites que les autres SGBD en matière de virtualisation.

2.1.4 - Compatibilité avec les technologies de stockage PostgreSQL fonctionne sur les baies de stockage (SAN, NAS,...) mais comme pour tout SGBD, l'attachement doit être permanent en mode blocs. La virtualisation du stockage est totalement transparente pour le SGBD. Les communautés fournissent des recommandations sur les types de système de fichiers à utiliser (EXT4, …). Ne pas utiliser NFS.

2.1.5 - Compatibilité avec les technologies de sauvegarde PostgreSQL supporte les modes de sauvegarde habituels :

• sauvegarde à froid : sauvegarde de niveau système de fichier – la base doit être arrêtée ;• sauvegarde à chaud : sauvegarde SQL. Pas de possibilité de réaliser une sauvegarde

incrémentale de manière native. L'outil barman le permet depuis la dernière version ;• sauvegarde permanente : Point In Time Recovery (PITR). PostgreSQL est compatible avec

les outils de sauvegarde (TINA, TSM,...)

15

2.2 – Sécurité

2.2.1 - Gestion de l'identification des utilisateurs PostgreSQL fournit les mécanismes d'authentification et gère l'attribution des privilèges (GRANT,...). Il permet également la séparation des schémas de base de données.

2.2.2 – Garantir la confidentialité et utilisation du chiffrement Le chiffrement est possible via le module complémentaire pgCrypto permettant le chiffrement de colonnes par clé publique et clé privée (Le ministère des affaires sociales a testé ce module).

2.2.3 - Assurer la traçabilité et la journalisation La traçabilité des actions dans PostgreSQL est assurée par des journaux : • Journalisation du fonctionnement du moteur (démarrage, arrêt,...)• Journalisation d'accès à PostgreSQL (requêtes, accès utilisateurs, erreurs,...)

3 - Scalabilité et résilience

3.1 - Mécanismes de clustering et de réplication Définitions Scalabilité et Elasticité La scalabilité désigne la capacité de PostgreSQL à s'adapter à un changement d'ordre de grandeur de la demande (montée en charge ou diminution). L'élasticité d'un système est la faculté d'un système à étendre ou réduire automatiquement ses ressources en fonction des besoins. Résilience et Robustesse (ou stabilité) La résilience est la capacité d'un système ou d'une architecture réseau à continuer de fonctionner en cas de panne. La robustesse est la qualité d'un système qui ne plante pas, qui fonctionne bien même dans un environnement hostile (pénétration, DoS...) ou anormal (entrées incorrectes...)

Cluster Un cluster est une grappe de serveurs (ou « ferme de calcul ») partageant un stockage commun. Un cluster fournit des fonctions de haute disponibilité et de répartition de charge.

Réplication La réplication est un processus de partage d'informations pour assurer la cohérence de données entre plusieurs sources de données redondantes, pour améliorer la fiabilité, la tolérance aux pannes, ou la disponibilité. Plusieurs modes de clustering et de réplication sont supportés par PostgreSQL avec les avantages et les inconvénients propres à chacun. Ces considérations sont indépendantes du choix du SGBD ; tous les produits sont concernés :

• mode « Actif-Passif » : une base principale est en lecture/écriture, l'autre base, dite « miroir » estsynchronisée en arrière plan. La réplication peut être asynchrone (meilleures performances) ou synchrone (meilleure sécurité). • mode « Actif-Actif partiel » ou «Read/Write - Read »: une base principale est en lecture/écriture,les bases « miroir » sont accessibles en lecture seule. Tout comme d'autres SGBD, PostgreSQL ne permet pas d'assurer la continuité des transactions sur plusieurs serveurs en mode « Actif-Actif » ou « Read/Write – Read/Write ». Le projet BDR (Bidirectionnal Replication) de 2nd Quadrant propose cette fonctionnalité. Il s'agit toutefois d'une version modifiée de PostgreSQL. Le passage en clustering est généralement irréversible. Il existe cependant des contributions permettant cette réversibilité.

3.2 - Résilience portée par le moteur PostgreSQL PostgreSQL fournit les mécanismes de réplication pour la mise en place d'un cluster « actif-passif » ou « actif-actif partiel ».

3.3 - Résilience portée par les infrastructures de stockage

PostgreSQL est compatible avec le clustering, porté par la plateforme indépendamment du SGBD. L'écriture sur un nœud est réalisée par PostgreSQL et la réplication sur un second nœud est assurée par la baie de stockage. Pour relancer le moteur sur le second nœud il y a obligatoirement une interruption de service.

[...]

Les MEDDE-MLET utilise PostgreSQL sur un seul nœud.

5 – Administration

[...] 5.2 - Outils de supervision de PostgreSQL et d'analyse des logs Les outils de supervision (Nagios, Munin,...) proposent des modules complémentaires (plugins) pour PostgreSQL, permettant la surveillance des logs et tables systèmes. Le script perl check_postgres de Bucardo est le principal plugin pour ces outils. Il est utilisé au MAE. D'autres modules permettent de suivre des statistiques d’évolution de la base (pg_stat_statements, pgtop,...) ou d'analyser les logs (pgbadger). Ce dernier est utilisé au MAE. A noter que de nombreux modules (pgfouine, pgstatpack, …) ne sont pas maintenus sur la durée.

5.3 - Outils de migration des données vers PostgreSQL L'outil « Ora2pg » permet d'analyser une base de données Oracle. L'extension Ora2pg de la DGFiP permet une évaluation des coûts de migration. L'outil permet également de réaliser la migration. Pour le transfert des données, l'utilisation d’un outil ETL (Talend Open Studio,...) permet de réaliser des transformations sur les données au moment du transfert (adaptation des types de données,…). Il est fortement recommandé d’expérimenter la migration dans des conditions les plus proches de la production (base de production, logs des sessions applicatives,…).

6 - Conduite du changement

6.1 - Formation des acteurs La formation ciblera trois publics : • les développeurs initiés : prise en main et migration vers PostgreSQL (2 à 3 jours) ;• les exploitants et architectes : installation, maintenance, sauvegarde, supervision,... (3 jours) ;• les administrateurs (DBA) : (formation exploitants + 3 jours).

6.2 – Support Le support est assuré de plusieurs manières : • par le marché interministériel porté par le ministère de l’intérieur ;• en s'appuyant sur le réseau interministériel (MimPROD,...) ;• par la communauté PostgreSQL. Un support professionnel français est aussi possible:http://www.postgresql.org/support/professional_support/europe/

6.3 - Plan de migration La migration nécessite des adaptations plus ou moins importantes des applications pour lesquelles une recette visant à garantir la non régression doit être menée. Son coût est significatif. Ce coût pourra être minimisé si la migration s'effectue à l'occasion d'une évolution fonctionnelle significative, qui nécessitera des recettes fonctionnelles et techniques indépendamment du changement de SGDB. L'accompagnement des MOA et MOE voire de la production, pour une montée en compétences dans les meilleures conditions, devra également être planifié.

7 - Retour sur investissement

7.1 - Coût de migration de la base La migration vers un nouveau SGDB doit tenir compte : • du coût d'entrée (formation des acteurs, montée en compétences,...)• des adaptations des applicatifs incluant les coûts de recettes (technique, fonctionnelle et tests denon régression)

7.2 - Coût de possession PostgreSQL est sous une licence open source similaire aux licences BSD ou MIT. Il n'y a donc pas de politique tarifaire subie de la part d'un éditeur.

16

17

7.3 - Maîtrise des trajectoires PostgreSQL est un produit dont la feuille de route (roadmap) est bien connue et maîtrisée. L’écosystème de PostgreSQL s'enrichit constamment de nouveaux modules complémentaires et d'outils. Les progiciels commerciaux proposent de plus en plus d'interfaces nécessaires pour utiliser PostgreSQL.

8 – Annexes

8.1 - Points d'attention lors de la migration depuis certains SGBD. 8.1.1 – Oracle Contribution du ministère de l'intérieur Il faut prendre connaissance des éléments des serveurs sources pour pouvoir définir les serveurs cibles adéquats en matière d’environnement technique, de piles logicielles, de système de stockage, de données, de criticité de l’application et du suivi de ses performances.

8.1.1.1 - Environnement technique Les caractéristiques des serveurs Oracle : Vérifier le type de serveurs : dédiés, mutualisés ou virtualisés ? S’assurer des éléments techniques suivants : • Types de processeurs• Nombre de processeurs• Fréquences horloge des processeurs• Taille des registres• Taille de la RAM

8.1.1.2 - Les piles logicielles Relever les différentes piles logicielles composant l’application. L’OS actuel pour quelle distribution de LINUX et quelle version ? La version Oracle vers quelle version Postgres ? Quels sont les serveurs d’application source ? Le type de JVM Le système de virtualisation.

8.1.1.3 - Espace de stockage Quel est le système de stockage ? en général les SGBD sont hébergés sur du SAN (Storage Area Network ) ; des solutions alternatives ne manquent pas. Quel est le mode d’accès ? le plus souvent VMDK (Virtual Machine Disk).

8.1.1.4 - Migration de la base de données Les outils de Migration. Ils sont divers Ora2Pg, les ETL ou ELT, le développement des Programmes spécifiques, etc... Traiter d’abord les métadonnées avant le chargement des données.

MIGRATION DES STRUCTURES ORACLE vers POSTGRESQL : sont regroupés sous ce vocable les structures des tables et des vues avec leurs annexes, les différentes procédures, les fonctions, les triggers. Procéder à la vérification de la présence éventuelle du partitionnement et des vues matérialisées. Le partitionnement est basique sous PostgreSQL

9.1, ce fut avant tout une solution decontournement et depuis la 9.2 il est une fonctionnalité à part entière. Les vues matérialisées De la 9.0 à 9.2 , elles passaient par des artifices et depuis la 9.3 c’est une fonctionnalité intégrée. Le langage des procédures SQL Oracle utilise le langage PL/ SQL et PostgreSQL le PL/PGSQL ; ils sont assez proches mais une adaptation est requise.

Modèle de correspondance des types de données :

Les chaînes de caractères peuvent être remplacées par VARCHAR et TEXT.

Les dates Oracle sur 7 octets par TIMESTAMP en 8 octets. Les longues chaînes de caractères CLOB sont remplacées par TEXT. Les valeurs numériques entières NUMBER selon la précision ascendante par SMALLINT, INTEGER, BIGINT, NUMERIC.

18

Les valeurs numériques décimales par NUMERIC Les données binaires BLOB par BYTEA (attention au caractère d’échappement avec Ora2Pg). Migration des procédures normales et stockées.Recenser toutes les procédures et fonctions PL/SQL et les transformer en PL/PgSQL. Génération des SCRIPTS DE MIGRATION DE LA BASE DE DONNEES Le script de migration des structures doit être séparé des données ; il servira à initialiser la base PostgreSQL. Création du script d’initialisation de la base PostgreSQL Il est créé à partir des structures des données, des procédures et fonctions réadaptées pour PostgreSQL. La migration des données. Elle peut se faire par un script SQL de données à insérer dans la nouvelle base PostgreSQL. Il est aussi possible d’opter pour un chargement direct de la base Oracle vers la base PostgreSQL. Le code applicatif La modification du code est nécessaire pour intégrer le driver PostgreSQL pour la gestion des transactions, de l’ouverture et fermeture des connexions, des mots clés Oracle à remplacer par les mots clés PostgreSQL, des jointures externes, de la pagination, etc...

8.1.1.5 - Criticité et sauvegardes Prise en compte des notions de PRA/PCA, RTO, RPO, et REPLICATIONS. Quelle solution technique est utilisée pour assurer la haute disponibilité : Oracle RAC, Oracle DATAGUARD ou autre ? Il n’y a pas d’équivalent Oracle RAC sous PostgreSQL ; par contre la fonction DATAGUARD est assurée sous PostgreSQL par la réplication. Le PRA (Plan de Reprise d’Activité) nous impose un délai de reprise d’activité de l’application. Il prend en compte le RTO (Recovery Time Objective ou la durée maximale d'interruption admissible) et le RPO (Recovery Point Objective ou la durée maximum d'enregistrement des données qu'il serait tolérable de perdre lors d'une panne). Cela conditionnera aussi en fonction de la volumétrie la technologie, la fréquence et le type de sauvegarde à mettre en place. RMAN sous Oracle gère les sauvegardes et restaurations ; il n’y a pas d’équivalent de base sous PostgreSQL. Par contre, un outil tiers nommé Barman est en cours d'installation au MAE pour automatiser les sauvegardes et restaurations. Par contre le mode Archivelog est bien pourvu dans les deux SGBD de façon quasiment identique. Les restaurations physiques n’ont pas une granularité plus fine sous PostgreSQL (on restaure tout).

8.1.1.6 - Suivi, amélioration des performances, et supervision Il n’existe pas de monitoring global comme le Grid Control sous Oracle. Cependant il est possible d'utiliser Nagios avec le plugin check_postgres. D'autres outils sont également disponibles (powa, PGObserver, …). Il faut mener une réflexion sur les différents outils disponibles.