Guide d’approche de déploiement de Linux Enterprise … · Guide de déploiement Datacenter. Guide d’approche . de déploiement de SUSE ® Linux Enterprise Server. Novell Logo.

Guide de déploiementDatacenter

Guide d’approche de déploiement de SUSE® Linux Enterprise Server

Novell Logo1 The registered trademark, ®,

appears to the right and on thesame baseline as the Logo.

Minimum Size RequirementsThe Novell Logo should NOT beprinted smaller than 3 picas(0.5 inches or 12.5 mm) in width.

Clear-space Requirements2 Allow a clean visual separation

of the Logo from all other elements.The height of the "N" is themeasurement for the minimumclear-space requirements aroundthe Logo. This space is flat andunpatterned, free of other designelements and clear from the edgeof the page.

3 picas(0.5 in)

(12.5 mm)

21 3

3

www.novell.com

p. 1

Guide d’approche de déploiement de SUSE Linux Enterprise Server

table des matières : 2 . . . . . Résumé

3 . . . . . Best practices de déploiement

3. . . . . . Types d’applications

5 . . . . . Gestion d’un déploiement : Phase 1 - Inventaire

7. . . . . . Gestion d’un déploiement : Phase 2 - Évaluation

7. . . . . . Gestion d’un déploiement : Phase 3 - Hiérarchisation

9. . . . . . Gestion d’un déploiement : Phase 4 - Lancement

14 . . . . . Test des best practices

14 . . . . . Obstacles courants

15 . . . . . Annexes

p. 2

conseils de novell pour une migration réussie

Se focaliser sur les objectifs de

l’entreprise et entamer le process de planification suffisamment tôt

Planifier toutes les étapes

Obtenir au préalable l’accord des parties prenantes dans le cadre d’une communication claire concentrée sur les avantages

S’accorder sur les facteurs de réussite avant de lancer le projet

Mesurer les performances de base, puis recommencer après la migration pour quantifier le retour sur investissement

Faire des tests, des tests et encore des tests

Construire en parallèle (nouveaux systèmes aux côtés des systèmes ou services anciens ou préalables à la migration) et opérer la transition avec des équilibreurs de charges

Ce document s’adresse aux professionnels et responsables de l’informatique qui envisagent de déployer SUSE® Linux Enterprise Server. Un certain nombre de demandes ont été adressées à Novell par des clients désireux de migrer de Red Hat* Enterprise Linux vers SUSE Linux Enterprise Server. Outre les commentaires des clients, Novell propose quelques conseils issus de l’assistance fournie par la société à de nombreux clients lors de leur migration vers la plate-forme Linux* la plus ouverte, la plus interopérable et la plus facile à gérer. Ce document est consacré au déploiement de SUSE Linux Enterprise Server dans des environnements qui utilisaient précédemment Red Hat Enterprise Linux. Il met en évidence les principales différences entre les deux plates-formes et propose un plan de déploiement général. Après avoir lu ce document, les utilisateurs de Red Hat Enterprise Linux maîtriseront SUSE Linux Enterprise Server et sauront comment réussir une migration. Ce document n’est pas destiné à fournir des instructions détaillées sur l’administration de SUSE Linux Enterprise Server. Pour approfondir ce sujet, nous encourageons les utilisateurs à participer aux modules de formation Novell.

La transition de Red Hat Enterprise Linux vers SUSE Linux Enterprise Server ne présente aucune difficulté en soi, mais Novell a néanmoins constaté que la réussite de la migration nécessite une planification rigoureuse. Les applications qui fonctionnent sur Red Hat Enterprise Linux fonctionnent généralement sur SUSE Linux Enterprise Server sans qu’aucune modification ne soit nécessaire. Par conséquent, la portabilité des applications ne pose généralement aucun problème particulier. En revanche, pour un administrateur système habitué aux outils spécifiques de Red Hat Enterprise Linux, la transition vers les outils de SUSE Linux Enterprise Server peut s’avérer plus complexe. Mais une fois familiarisé avec les outils de SUSE Linux Enterprise, les administrateurs se féliciteront d’avoir entrepris cette transition. Pour faciliter cette transition,

Novell propose un excellent programme de formation et d’assistance. La garantie que l’application fonctionnera comme espéré une fois déployée sur SUSE Linux Enterprise Server représente un défi supplémentaire. S’il n’existe aucune méthode idéale pour y parvenir, Novell peut néanmoins proposer quelques conseils pour limiter les problèmes.

Les déploiements de SUSE Linux Enterprise Server font souvent partie d’un process de renouvellement plus large. Novell bénéficie d’une expérience certaine en termes de déploiement de SUSE Linux Enterprise Server dans les environnements les plus complexes. Aussi difficile que puisse paraître un déploiement de SUSE Linux Enterprise Server, les avantages qu’il procure en valent largement la peine. Ce document présente les connaissances acquises par Novell au fil des déploiements réalisés par la société et apporte de la transparence à un process souvent mal compris.

Les sections suivantes illustrent la méthodologie utilisée par Novell pour que le déploiement se déroule sans interruption des activités afin de permettre au datacenter d’atteindre son potentiel maximal. Pour plus de clarté, ce document présente également les différences entre Red Hat Enterprise Linux et SUSE Linux Enterprise Server. Novell sait pertinemment que le déploiement d’une nouvelle plate-forme peut s’avérer être une tâche colossale pour une entreprise équipée de milliers de serveurs exécutant une multitude de charges de travail et répartis sur différentes unités commerciales et zones géographiques. Le plus difficile lors de l’élaboration d’une stratégie de déploiement est souvent de savoir comment aborder le problème. Chaque déploiement est unique et suit des règles qui lui sont propres, en fonction des besoins de l’entreprise ainsi que des applications et matériels existants. Toutefois, des principes communs s’appliquent à toutes les situations. Un déploiement bien préparé permettra à une entreprise de transférer ses charges de travail actuelles vers SUSE Linux Enterprise

Résumé

p. 3

Guide d'approche de déploiement de SUSE Linux Enterprise Server www.novell.com

Server et facilitera le déploiement de ses futures charges de travail.

Best practices de déploiement

Avant tout projet de déploiement, l’entreprise doit impérativement comprendre pourquoi elle entreprend la migration de ses charges de travail vers SUSE Linux Enterprise Server. Cela permet en effet de convaincre encore davantage les décisionnaires en centrant la réflexion sur les objectifs de l’entreprise. Parmi les objectifs les plus courants du déploiement de SUSE Linux Enterprise Server, il convient de souligner la réduction des coûts et de la complexité de l’environnement serveur. Ce déploiement permet également d’exploiter la seule plate-forme Linux recommandée par Microsoft. Il s’agit en effet du seul système d’exploitation Linux optimisé pour un fonctionnement parfait avec votre environnement Microsoft* Windows*.

Trois grandes questions doivent être posées avant d’élaborer une stratégie de déploiement : comment convertir d’anciennes applications pour les faire fonctionner sur une nouvelle plate-forme, comment construire et déployer des serveurs, et enfin, comment gérer les nouveaux serveurs une fois ceux-ci en place ? Les best practices suivantes ont été développées pour répondre à ces questions et structurer ce process complexe.

La portée d’un déploiement dépend principalement des serveurs ou du groupe de serveurs à migrer et de la taille du datacenter. Si les charges de travail à migrer de Red Hat Enterprise Linux vers SUSE Linux Enterprise Server sont limitées en nombre, certaines des procédures appliquées ci-dessous ne seront pas forcément nécessaires. Néanmoins, même le plus modeste des déploiements doit être planifié, testé et certifié. Novell conseille une approche progressive vous permettant de mettre en oeuvre votre solution petit à petit, pièce par pièce, afin de garantir la réussite du projet et de fixer des objectifs réalistes. Les déploiements s’avèrent beaucoup plus faciles à gérer lorsque l’on commence par des charges de travail simples pour ne traiter les charges les plus complexes qu’après avoir obtenu des résultats prometteurs.

Les migrations de Red Hat Enterprise Linux vers SUSE Linux Enterprise Server se décomposent généralement en quatre étapes. Chaque étape doit être terminée avant de passer à la suivante.

Étape 1 : inventaire complet de l’ensemble du matériel et des applications logicielles ; métriques de base pour évaluer les résultats obtenus.

Étape 2 : évaluation de l’inventaire et détermination des caractéristiques des charges de travail.

Étape 3 : hiérarchisation des charges de travail identifiées à l’étape 2 et élaboration d’un plan faisant appel à la consolidation pour optimiser le retour.

Étape 4 : lancement d’initiatives en production, notamment réalisation de tests rigoureux, selon une méthodologie acceptable pour l’entreprise.

Les entreprises doivent impérativement conduire les tests adéquats avant de déployer de nouvelles solutions dans leur environnement de production. Le plus difficile lors d’un nouveau déploiement est souvent de s’accorder sur les critères permettant de considérer le nouveau environnement comme fonctionnel, et de garantir que toutes les composantes ont bien été identifiées et inventoriées. Nous allons aborder les critères de réussite d’un test dans le souci d’une transition parfaite.

Types d’applications

Novell décompose les applications devant généralement bénéficier d’un redéploiement en trois grandes catégories. La complexité de la migration d’une application dépend de son type. Vous trouverez ci-dessous une brève présentation de ces catégories et des types d’activités associés à la migration de ces applications.

Niveau 1 : les fondations

Portée : ce niveau implique un réseau standard et d’autres services communs à de nombreuses variantes d’UNIX* et Linux, notamment Apache, DHCP, sendmail, BIND (DNS), LDAP, NIS et NFS. Il englobe aussi l’intégration aux services de base existants, comme la sauvegarde, la surveillance, la sécurité, l’audit et la gestion des utilisateurs.

Trois questions déterminantes doivent être posées pour préparer une stratégie de déploiement :

Comment convertir d’anciennes appli­cations et les faire fonctionner sur une nouvelle plate­forme ?

Comment construire et déployer des serveurs ?

Comment gérer les nouveaux serveurs une fois qu’ils sont en place ?

p. 4

Activités : Installer le progiciel Appliquer la configuration existante (de

l’ancien système) à la nouvelle installation Tester le fonctionnement

Complexité : faible complexité technique. La reconfiguration nécessaire au transfert des composants Open Source standard comme Apache est insignifiante. La configu-ration d’Apache (httpd.conf et ses sous-arborescences) doit pouvoir être copiée dans la nouvelle version de SUSE Linux Enterprise Server (avec le contenu de site Web) et fonctionner sans modifications ou presque. Les services tels que DHCP et BIND (DNS) peuvent également être transférés de la même manière.

Niveau 2 : outils intermédiaires

Portée : ce niveau implique généralement de grands composants commerciaux prêts à l’emploi comme SAP, Oracle, PeopleSoft, Serviceguard et Veritas.

Activités : Vérifier que le composant prêt à l’emploi

est certifié pour SUSE Linux Enterprise Server (voir www.novell.com/partner/isv/isvcatalog)

Installer le progiciel de base prêt à l’emploi sur SUSE Linux Enterprise Server

Transférer toutes les personnalisations de l’ancien système vers le nouveau

Tester et recertifier le fonctionnement sur SUSE Linux Enterprise Server

Complexité : l’installation de base est très simple. Les process de migration de la configuration et de certification s’avèrent plus complexes. Pour ce faire, il est préférable d’avoir recours aux ressources utilisées lors des personnalisations initiales (Accenture, Deloitte & Touche, etc.).

Niveau 3 : applications sectorielles personnalisées

Portée : il s’agit ici des applications personnalisées développées par un client pour satisfaire les exigences des process

spécifiques de son entreprise et de sa proposition de valeur.

Activités : Dresser l’inventaire de tous les logiciels à

transférer Dresser l’inventaire complet des ressources

de test existantes Développer un plan de projet personnalisé Porter (en cas de migration Linux vers

Linux, cette étape est quasiment éliminée) Tester l’unité Tester l’intégration Tester le système Tester l’acceptation utilisateur

Complexité : aucune complexité technique grâce à la compatibilité inhérente à Linux. Les tests accentuent la complexité. Toutefois, il s’agit généralement de l’aspect le plus « payant ». Dans cette catégorie, les logiciels peuvent généralement être subdivisés en plusieurs sous-catégories différentes en termes de niveau de complexité :

Compilation statique interne, sans dépendances externes

Compilation statique interne, avec dépendances externes

Bibliothèques partagées internes, sans dépendances externes

Bibliothèques partagées internes, avec dépendances externes

Sous-classification selon la disponibilité ou non du code source interne ou s’il s’agit de catégories binaires uniquement

Principales différences entre Red Hat Enterprise Linux et SUSE Linux Enterprise Server

Même si la plupart des aspects de Linux sont semblables d’une distribution à l’autre, on trouve néanmoins quelques différences majeures entre Red Hat Enterprise Linux et SUSE Linux Enterprise Server. Ces domaines sont tous traités dans les modules de formation consacrés à la migration de Red Hat Enterprise Linux vers SUSE Linux Enterprise Server, fournis par Novell.

p. 5

Guide d'approche de déploiement de SUSE Linux Enterprise Server www.novell.com

AutoYaST contre KickstartRed Hat Enterprise Linux comprend un programme appelé Kickstart qui permet de sauvegarder et de déployer des configurations serveur. SUSE Linux Enterprise Server utilise un puissant outil appelé AutoYaST qui offre la même fonctionnalité. Le résultat final est identique, mais Novell recommande aux administrateurs de suivre une nouvelle formation sur l’utilisation d’AutoYaST.

AppArmor® contre SELinuxLes administrateurs de Red Hat Enterprise Linux qui connaissent SELinux seront ravis d’apprendre qu’AppArmor offre le même niveau de sécurité tout en étant bien moins complexe. Il faudra traduire les règles de SELinux pour les utiliser avec AppArmor. Toutefois, AppArmor est beaucoup plus facile à gérer et propose de nombreuses bibliothèques de règles prêtes à l’emploi pour les services les plus courants.

Structure d’annuaireCertains aspects de la structure d’annuaire de SUSE Linux Enterprise Server et de Red Hat Enterprise Linux sont différents. Des fichiers de configuration peuvent ne pas se situer exactement à l’emplacement où un administrateur de Red Hat Enterprise Linux le voudrait. La documentation relative à SUSE Linux Enterprise Server est très utile pour déterminer l’emplacement des différents fichiers de configuration. En termes de philosophie, SUSE Linux Enterprise Server est plus proche et plus conforme à la LSB/FSH tandis que Red Hat Enterprise Linux privilégie davantage la compatibilité avec les versions précédentes de Red Hat Enterprise Linux. Les administrateurs de Solaris se familiariseront facilement avec SUSE Linux Enterprise Server.

Commandes de baseCertaines commandes de configuration de base de SUSE Linux Enterprise Server sont différentes de celles de Red Hat Enterprise Linux. Au lieu d’utiliser system-config-* ou redhat-config-*, SUSE Linux Enterprise utilise yast2* pour certaines activités de configuration. Pour obtenir la liste complète de ces commandes ainsi que leur description, reportez-vous au module

de formation Red Hat vers SUSE Linux Enterprise Server, fourni gratuitement par Novell. Un autre document accompagnant le kit de déploiement et fourni par Novell traite également ce sujet en profondeur.

Mise en grappeLes deux distributions utilisent ext3 comme système de fichiers par défaut, mais les implémentations de mise en grappe varient. Pour la mise en grappe, Red Hat Enterprise Linux repose sur Red Hat Cluster Suite qui utilise GFS (Global File System), tandis que SUSE Linux Enterprise Server utilise OCFS2 avec Heartbeat. Les administrateurs habitués à Red Hat Cluster Suite devront suivre une formation sur les fonctions de mise en grappe de SUSE Linux Enterprise Server.

GestionLes administrateurs de Red Hat Enterprise Linux doivent savoir utiliser Red Hat Satellite Network pour administrer leur système UNIX. Les installations de SUSE Linux Enterprise Server sont généralement gérées via Novell® ZENworks® Linux Management ou Novell System Management Tool (SMT), ce qui nécessite une formation du personnel.

Gestion d’un déploiement : Phase 1 ­ InventaireLa phase d’inventaire constitue le point de départ de tout nouveau déploiement. Un inventaire détaillé est indispensable pour assurer le succès des étapes suivantes. La phase d’inventaire peut être décomposée en cinq étapes : matériel, OS, stockage, pile et fonctionnement. Pour chaque étape, les informations suivantes doivent être recueillies :

Matériel

Fabricant Architecture (32/64 bits) Type de processeur (ex : x86, AMD64,

EM64T, IA64, PPC, PA-RISC) Nombre de processeurs Nombre de coeurs RAM Versions des microprogrammes Date d’actualisation/de fin de cycle de

vie prévue pour le matériel Certifications/Niveaux de support

p. 6

Type et version du système d’exploitation

Type (Solaris*, Red Hat Enterprise Linux, AIX*, etc.)

Version Niveau de version (Service Pack) Architecture (32/64 bits) Certifications/Niveaux de support

Besoins en stockage

Configuration actuelle du stockage Modifications prévues pour le stockage Local/NAS/SAN Exigences HBA/Multipath Exigences de microprogrammes

Pile

La pile comprend tous les logiciels d’une construction standard, à l’exception des applications sectorielles hébergées par le serveur. Cela comprend, entre autres, les logiciels de sécurité, de sauvegarde, de gestion et de surveillance. Vous devez veiller à ce que les informations recueillies vous permettent de reconstruire la même pile sur une plate-forme SUSE Linux Enterprise. Les informations recueillies à ce stade serviront de base au lancement de l’application sur une plate-forme de test.

Informations importantes (liste non exhaustive) :

Process en cours Bibliothèques Versions des paquetages Applications

– Dépendances des paquetages (ex : autres applications, process, systèmes, noms d’utilisateurs, etc.)

– Fournisseur des logiciels – Niveau de support de l’éditeur de

logiciels (ISV, Independent Software Vendor)

– Version

Connectivité aux périphériques de stockage externes

Restrictions de sécurité Méthodes d’authentification

Fonctionnement

L’objectif est de recueillir le plus d’informations possible sur les applications à migrer. Ces informations peuvent être divisées en plusieurs sous-catégories :

Serveur de bases de données d’entrepriseDifférentes informations doivent être recueillies sur le serveur de bases de données et sur l’emplacement des données. Il est impératif de déterminer si le serveur de bases de données doit migrer ou non ; la plupart des bases de données courantes sont aujourd’hui prises en charge par SUSE Linux Enterprise Server.

Infrastructure et serveur de périmètre (edge server)Cette catégorie comprend les applications de type VPN, pare-feu et annuaire/impression. Informations pertinentes :

Type de service Nombre d’utilisateurs Besoins en données Méthode de connectivité du client Fichiers de configuration

Applications d’entreprise d’éditeurs de logicielsCette catégorie est probablement la plus importante ; elle permet de vérifier que ces applications ont été certifiées pour fonctionner sur SUSE Linux Enterprise Server. Toutes les dépendances tierces doivent être répertoriées pour veiller à ce qu’elles soient également disponibles. Les éditeurs de logiciels accepteront de certifier leurs offres sur SUSE Linux Enterprise Server si un client le leur demande ; la prise en charge actuelle n’est donc pas nécessairement un obstacle à la migration.

Applications personnaliséesLes applications personnalisées correspondent à toutes les applications développées en interne et nécessitant portage et test. Les mesures à prendre pour la migration d’applications dépendent principalement du code lui-même.

p. 7

Guide d'approche de déploiement de SUSE Linux Enterprise Server www.novell.com

De nombreux outils Open Source et commerciaux sont disponibles pour évaluer la portabilité d’une application. En général, les applications situées au sommet des intergiciels (ex : Oracle Forms d’Oracle*, WebLogic*, WebSphere*, J2EE*/Tomcat) sont les plus faciles à transférer. Le plus souvent, les applications développées via des langages de script sont également faciles à transférer, mais des tests doivent être réalisés avant le déploiement.

Lignes de base/Métriques de performances

Les métriques peuvent mettre en évidence les avantages acquis et garantir le succès du projet en mesurant les performances avant la migration. Les performances des systèmes clés (charges soutenues et de pointe, etc.) et les opérations standard (ajouts de nouveaux enregistrements, traitements par lots, sauvegardes, autres opérations habituelles) doivent impérativement être mesurées et des lignes de base doivent être établies. Sans ces bases, il est difficile de déterminer si la migration s’est bien déroulée.

Gestion d’un déploiement : Phase 2 ­ Évaluation

La phase d’évaluation nécessite une analyse minutieuse des données recueillies lors de la phase d’inventaire. Les données réunies lors de l’inventaire doivent être examinées avec soin et d’autres informations peuvent être recueillies pour déterminer les charges de travail à déployer en priorité. L’analyse peut se décomposer en plusieurs étapes :

Analyse du matériel

Il convient tout d’abord de déterminer le sort du matériel existant. Plusieurs options sont disponibles, notamment utiliser le matériel existant pour la prise en charge de SUSE Linux Enterprise Server ou remplacer le matériel actuel s’il ne répond pas aux futures exigences.

Cycle de vie des applications

Pour déterminer les applications prioritaires, chaque application doit être positionnée dans son cycle de vie. Les applications qui arrivent en fin de vie seront redéployées en priorité.

État des certifications des éditeurs de logiciels (ISV, Independent Software Vendor) sur SUSE Linux Enterprise Server

Recherchez le niveau de prise en charge actuel sur SUSE Linux Enterprise Server de chaque application propriétaires ou prête à l’emploi. Les principaux facteurs à prendre en compte sont les suivants : l’application fonctionne-t-elle sur SUSE Linux Enterprise Server, est-elle prise en charge sur SUSE Linux Enterprise Server, une version plus récente est-elle disponible pour SUSE Linux Enterprise Server, ou possède-t-elle des dépendances non disponibles ? Si l’application n’est pas prise en charge, consultez la feuille de route de l’éditeur de logiciels ou déterminez si une autre application prise en charge peut la remplacer. Pour plus d’informations sur les éditeurs de logiciels (ISV, Independent Software Vendor) et sur les constructeurs indépendants de matériel (IHV, Independent Hardware Vendor) pris en charge sur SUSE Linux Enterprise Server, visitez le site : www.novell.com/partner/isv/isvcatalog

La plupart des éditeurs de logiciels répondent aux demandes de leurs clients en termes de prise en charge de systèmes d’exploitation. Les clients doivent communiquer clairement leurs intentions auprès des éditeurs de logiciels pour obtenir la certification des applications qu’ils souhaitent transférer.

Profilage

Le profilage est essentiel pour mesurer le potentiel d’un déploiement de SUSE Linux Enterprise Server. Pour planifier la consolidation, il est impératif de comprendre les caractéristiques de chaque charge de travail. Les caractéristiques des charges de travail varient au fil du temps, aussi est-il nécessaire de profiler les charges de travail au fil des jours, des semaines et des mois précédant la migration.

Gestion d’un déploiement : Phase 3 ­ HiérarchisationLa tâche suivante consiste à désigner le matériel et/ou les applications prioritaires pour le redéploiement. Ceci doit aboutir à une feuille de route qui permettra à

p. 8

l’entreprise de planifier les déploiements en cours et le lancement futur des applications.

Critères et pondération

Trois critères s’appliquent à la création d’un plan d’activités destiné à offrir le maximum d’avantages.

Risque (élevé / intermédiaire / faible) - Risque inhérent à ce changement en dehors des stratégies de mise à niveau normales

Complexité (élevée / intermédiaire / faible) - Complexité technique inhérente à ce changement ; ex : la migration des services d’infrastructure réseau est moins complexe que la migration d’applications personnalisées basées sur le code natif. La complexité peut généralement être évaluée sur une échelle comprise entre 1 et 5, 1 représentant la complexité la plus faible et 5 la plus élevée

– L’application fonctionne sans aucune intervention

– L’application fonctionne avec une intervention minime

– L’application requiert une recompilation qui tiendra compte de toutes les dépendances

– L’application requiert une recompilation ainsi qu’une résolution des dépendances

– L’application ne fonctionne pas pour cause d’absence de support et/ou de code

Opportunité (élevée / intermédiaire / faible) - Conformément aux objectifs de migration vers SUSE Linux Enterprise Server, quelle opportunité présente ce profilage de serveur ou d’application ? L’application vaut-elle l’investissement de migration ? Ces applications peuvent être regroupées en trois catégories :

– L’application est en cours de réécriture ou une mise à jour majeure est prévue

– La dépendance envers l’éditeur de l’application n’existe plus

– Le code source de l’application n’est pas disponible

Dans certains cas, il peut être intéressant d’exécuter l’application sur une machine

virtuelle invitée sur SUSE Linux Enterprise Server.

La phase de hiérarchisation doit fournir les informations suivantes :

Applications à déployer en priorité Nombre de constructions matérielles

différentes pour le lancement Nombre de piles logicielles différentes

pour le lancement Opportunités de consolidation Opportunités de virtualisation

Une fois ces critères appliqués à la matrice, les applications pour lesquelles le redéploiement s’avère le plus avantageux sont prioritaires. Il s’agit des applications dont les performances seront accrues une fois redéployées sur SUSE Linux Enterprise Server, des applications faciles à mettre en oeuvre et des applications à fort impact sur les objectifs commerciaux.

Critères de décision simples pour choisir les cibles de la migration

Lors de l’évaluation et de l’inventaire des serveurs, posez-vous les questions suivantes :

Y a-t-il plusieurs serveurs semblables à redéployer ou s’agit-il d’un serveur unique ?

Les applications commerciales visées sont-elles prises en charge ou certifiées pour SUSE Linux Enterprise Server par l’éditeur de logiciels ? (www.novell.com/ partner/isv/isvcatalog)

La plate-forme matérielle visée est-elle prise en charge par le constructeur indépendant de matériel ?

La migration vous permet-elle de cesser toute prise en charge et de supprimer les coûts associés à l’ancienne plate-forme ?

La charge de travail peut-elle être virtualisée ?

La charge de travail peut-elle fonctionner sur une machine physique comme l’IFL (Integrated Facility pour Linux) sur un gros système zSeries* (comme un serveur d’applications WebSphere) ?

p. 9

Guide d'approche de déploiement de SUSE Linux Enterprise Server www.novell.com

La charge de travail bénéficierait-elle de la fonctionnalité SUSE Linux Enterprise Server Real Time ?

S’agit-il d’une charge de travail Windows qui pourrait être virtualisée sur SUSE Linux Enterprise Server ?

Existe-t-il des problèmes de parité entre systèmes d’exploitation pour les fonctions essentielles ?

Association du déploiement aux cycles de mise à niveau

Si possible, les déploiements de SUSE Linux Enterprise Server doivent être associés aux cycles de mise à niveau du matériel et des logiciels. Il en résulte une réduction des coûts de migration et une optimisation de l’efficacité, grâce à une synergie avec les initiatives informatiques d’entreprise ou sectorielles existantes.

Création d’une feuille de route

La phase de hiérarchisation doit également inclure la création d’une feuille de route détaillée, la planification de l’implémentation et la préparation des ressources nécessaires à la migration. Les étapes trimestrielles et mensuelles importantes du déploiement doivent être notées sur la feuille de route. Les cibles du déploiement du serveur doivent être désignées et un suivi doit être effectué dans le cadre d’un rapport mensuel. Une approche détaillée du déploiement est présentée ci-dessous.

Ateliers de déploiement et planification du déploiement

Ces brèves séances de whiteboarding, ou tableaux blancs interactifs, sont destinées à vous aider à développer l’approche et la dynamique de déploiement dans votre entre-prise. Il s’agit du principal outil de recueil d’informations lors des activités d’évaluation et de hiérarchisation. Les séances durent environ une journée et sont encadrées par un animateur ainsi qu’un spécialiste technique ou un architecte. Ces ateliers supposent la participation active des experts verticaux et techniques. L’encadrement et la durée peuvent être modifiés ou adaptés en fonction des besoins du client. Les ateliers de

déploiement, quelle que soit leur durée, se déroulent généralement comme suit :

Récapitulatif des facteurs commerciaux et techniques pour une solution basée sur SUSE Linux Enterprise Server ; justification des avantages commerciaux

Migration d’applications et inventaire de conversion avec exigences de certification de l’éditeur de logiciels initial

Découverte approfondie d’un domaine (construction de base, virtualisation, gestion des systèmes hétérogènes, besoins en interopérabilité des solutions d’identité, etc.)

Support et formation nécessitant une évaluation

Plan de déploiement détaillé des services d’habilitation, approche d’optimisation de l’usage de la certification ; et étapes suivantes

Phase d’exécution et présentation

Transfert des piles traditionnelles aux piles virtuelles

Toute migration doit être associée à une stratégie de virtualisation pour profiter pleinement du potentiel que représente le matériel moderne. En matière de virtualisation, un bon provisioning des serveurs s’avère souvent complexe ; ceci dit, il existe de nombreux outils logiciels pour vous aider dans cette tâche. Novell vous conseille de consulter un tiers ayant fait l’expérience de la virtualisation dans le cadre du process de migration. La virtualisation est également idéale pour déployer des services extrême-ment difficiles à transférer depuis les plates-formes préexistantes.

Gestion d’un déploiement : Phase 4 ­ Lancement

Pendant la phase de lancement, l’entreprise doit utiliser les résultats des phases d’évaluation et de hiérarchisation pour aborder les activités détaillées de planification et d’exécution. Ceci doit se traduire par un ensemble concret d’éléments aux objectifs quantifiables.

Les objectifs doivent refléter les besoins structurels en déploiement ainsi que les

p. 10

piles d’applications et de matériel requises ayant été identifiées.

Portée

Les modèles d’applications et de matériel à cibler lors du déploiement doivent être déterminés en fonction des résultats de la phase de hiérarchisation :

Définir la portée de la première phase de déploiement et harmoniser avec les objectifs

Veiller à ce que la portée soit approuvée par le sponsor du projet et par les principaux décisionnaires

Déterminer s’il existe d’autres exigences Déterminer les paquetages et applications

à inclure dans la construction standard Déterminer le nombre de constructions

requises pour prendre en charge les variantes des piles de logiciels et du matériel requis

Préparer un plan de projet des tâches requises pour atteindre chaque objectif

Prévoir le personnel nécessaire pour les tâches de lancement

Déterminer les exigences du serveur et de l’infrastructure de prise en charge pour l’environnement pilote et l’environnement de production

Entamer le process d’acquisition du matériel et des logiciels

Plan

Préparer un plan des principales structures d’applications et de matériel, détaillant les éléments suivants :

Marque / Modèle / Architecture du matériel cible

Paquetages SUSE Linux Enterprise Server essentiels à inclure dans la construction

Sources de construction de base requises Autres sources d’applications requises Sources des dépendances d’applications

requises Besoins en correctifs Besoins en sécurité/renforcement Préparation de scénarios d’utilisation pour

la phase de test Besoins en documentation Réfléchir à la façon dont le cycle de

lancement pourrait être intégré aux cycles de vie du matériel et des logiciels existants dans l’entreprise pour les correctifs, la mise à niveau et l’acquisition

Configuration

L’étape de configuration consiste à préparer les environnements de test et de production, ainsi que les activités de construction de base et de migration d’applications. Après la phase de configuration, l’entreprise disposera d’un environnement de laboratoire dédié d’où émanera le reste des activités. La phase de configuration se décompose en trois étapes principales (pour chaque étape, une documentation complète est fournie par Novell) :

Préparer le matériel pour le laboratoire

– Acquérir et configurer le matériel pour le serveur d’installation

– Acquérir et configurer le matériel pour l’environnement de développement

– Acquérir et configurer le matériel pour tester les constructions

Préparer les logiciels pour le laboratoire

– Créer les sources d’installation de SUSE Linux Enterprise Server pour chaque architecture (ex : i386, x86-64)

– Si nécessaire, créer les packs RPM pour les logiciels

– Créer des référentiels complémentaires signés pour les paquetages et dépen-dances d’applications non disponibles dans le cadre de la distribution de base de SUSE Linux Enterprise Server

p. 11

Guide d'approche de déploiement de SUSE Linux Enterprise Server www.novell.com

– Créer les sources d’installation des applications et paquetages complémentaires

Préparer le mécanisme de lancement des constructions

– Identifier les types de constructions requis (ex : réseau, DVD, USB)

– Choisir le process de démarrage pour la connexion aux constructions (ex : PXE, CD, DVD)

– Choisir les protocoles à utiliser pour le lancement de la construction (ex : HTTP, FTP)

– Préparer les services du serveur d’installation pour les méthodes de lancement

– Créer plusieurs méthodes de lancement à partir de la même source

Novell recommande de configurer l’environnement de manière à permettre un démarrage de PXE avec déclenchement d’un fichier de contrôle XML à partir d’un référentiel NFS. Les entreprises qui ne souhaitent pas modifier leur serveur DHCP peuvent utiliser HTTP ou FTP. Les entreprises sont vivement encouragées à utiliser SSH pour le lancement des images, car celles-ci peuvent contenir des données sensibles.

Les entreprises doivent tout mettre en oeuvre pour que leurs environnements de laboratoire soient aussi proches que possible de l’environnement de production, car des différences trop marquantes risqueraient de provoquer des problèmes. L’environnement de laboratoire doit être conservé après le projet de migration afin de transférer de nouvelles applications dans l’environnement de production.

Mise en oeuvre

La phase de mise en oeuvre comprend la création des constructions de base pour la pile requise et les activités de développe ment associées à la migration des applications.

Création de la construction de baseAutoYaST est un outil intégré à SUSE Linux Enterprise Server qui permet à un administrateur système de recueillir les paramètres de construction du matériel et des applications d’un serveur et de les stocker dans un profil XML. Le profil créé peut ensuite être utilisé pour récréer des serveurs avec la même configuration

matérielle et la même pile de logiciels. Le profil XML peut servir de base et être ensuite mis à jour.

Pour créer la construction de base, commencez par créer une construction de référence sur le matériel cible, puis créez une copie du fichier XML AutoYaST. Si nécessaire, modifiez ce fichier XML pour chacune des autres constructions souhaitées. La construction de référence doit impérativement être testée avant d’être utilisée pour créer d’autres constructions. Pour en savoir plus sur la personnalisation du fichier XML, reportez-vous à la documentation d’AutoYaST.

Sécurité Configurer les règles de pare-feu réseau

requises avec le module de filtrage de paquets de la iptable du kernel

Suivre les best practices pour sécuriser SUSE Linux Enterprise Server

Créer des profils AppArmor pour les applications hébergées

Envisager l’utilisation d’un système de détection des intrusions (IDS)

S’il n’est pas déjà inclus dans la pile d’applications, penser à installer un logiciel de surveillance du type Nagios ou BMC PATROL

Test de la constructionDans le cadre du test, vérifier que :

les serveurs sont exempts d’erreurs ; les serveurs répondent à toutes les

exigences ; la sécurité du système répond aux besoins

de l’entreprise ; les performances sont conformes aux

attentes ; les charges des serveurs sont facilement

traitées.

En présence d’une équipe de sécurité interne, il convient de vérifier qu’elle approuve la construction et de tenir compte de ses éventuelles propositions. Tout bogue détecté doit être corrigé et le test de l’unité doit avoir été effectué avant de déployer une nouvelle construction dans l’environnement de production.

Novell encourage les entreprises à développer un process formel pour la création de nouvelles constructions.

p. 12

L’environnement de production doit être exempt de toute construction malveillante. Les entreprises sont encouragées à suivre systématiquement un cycle formel « créer, construire, tester, déployer » lors du déploie-ment de nouveaux matériels ou logiciels.

Description du process de construction d’image de baseToutes les mesures prises pour créer l’image de base doivent être soigneusement décrites pour être reproduites. Les points suivants doivent être documentés :

Construction du serveur d’installation Utilisation et maintenance du serveur

d’installation maître Création et utilisation des fichiers de

contrôle Configuration du démarrage du réseau Déploiement de la construction dans un

environnement de test

Pilote de productionUne fois la construction déployée et testée avec succès au laboratoire, elle peut être introduite dans un environnement de production. Novell recommande vivement aux entreprises de limiter le déploiement initial à un groupe restreint d’utilisateurs. Les tests système de bout en bout et les évaluations des charges de travail doivent être réalisés par le pilote.

DéploiementUne fois le pilote terminé, le déploiement complet peut commencer. Il est impératif de communiquer avec les utilisateurs ainsi que d’identifier et de résoudre rapidement les problèmes qui surviennent. L’environnement de laboratoire ne peut jamais complètement simuler l’environnement de test, mais une planification rigoureuse permettra de limiter les interruptions.

Maintenance

Dans le cadre de la phase de maintenance, vous devez déterminer la méthode de gestion des serveurs une fois ceux-ci déployés. Novell prend en charge trois méthodes de gestion des correctifs et de la distribution :

Novell ZENworks Linux Management permet une gestion complète des correctifs et une parfaite distribution des logiciels Linux ;

l’outil de gestion des abonnements peut en toute sécurité déclencher les correctifs Novell situés derrière un pare-feu et être utilisé comme fonctionnalité de correction de base lorsqu’il est associé à yum ou à AutoYaST ;

dans certains cas, une intégration aux outils de gestion des correctifs existants est possible. Un connecteur spécial est alors requis pour permettre aux outils tiers de communiquer avec le Novell Customer Center.

p. 13

Guide d'approche de déploiement de SUSE Linux Enterprise Server www.novell.com

Migration linux

Les applications n’ont généralement pas à être transférées depuis Red Hat Enterprise Linux pour fonctionner sur SUSE Linux Enterprise Server. Il peut, tout au plus, être nécessaire de changer l’emplacement de certains paramètres. Le plus important consiste à tenir compte de l’ensemble de bibliothèques qui était installé sur l’ancien système et à veiller à ce que les bibliothèques utilisées sur la construction de SUSE Linux Enterprise Server soient compatibles. Consultez l’éditeur de logiciels qui prend en charge l’application pour déterminer si des mesures spécifiques doivent être prises.

Pour les applications développées en interne, il peut être possible de procéder à une migration standard d’une ancienne

distribution de Linux vers SUSE Linux Enterprise Server. Novell et d’autres sociétés comme IBM, Hewlett Packard et Intel ont produit de nombreux documents, guides et logiciels d’assistance pour permettre la migration d’une application, directement ou via une étape intermédiaire.

Les applications examinées pour la migration doivent être évaluées selon leur conformité avec Linux Standards Base (LSB). LSB est une norme développée par Linux Foundation (www.linux-foundation.org/en/LSB) et qui mappe les bibliothèques, les commandes et utilitaires, la structure du système de fichiers et autres caractéristiques système requises pour qu’une distribution Linux compatible puisse assurer la prise en charge des applications.

Process de migration des applications

Novell recommande de suivre le process présenté ci-dessous :

Il s’agit de l’approche recommandée par Novell, mais même un sous-ensemble permettrait d’éviter les problèmes ; l’absence d’approche formelle limite les opportunités de réduction de coûts.

p. 14

SUSE Linux Enterprise Server 10 prend en charge LSB 3 (LSB 1.3). Les applications qui ont été développées pour prendre en charge une version antérieure de LSB doivent être prioritaires pour la migration vers SUSE Linux Enterprise Server afin d’accélérer le délai de migration et de réduire les mesures requises. Les applications conçues pour être conformes aux normes LSB 2 (LSB 1.2), comme celles déployées sur les serveurs Red Hat Enterprise 5, doivent être prioritaires sur les applications non conformes aux normes LSB. Une partie du process d’inven-taire des applications doit consister à identifier les applications qui dépendent du progiciel LSB ; ceci peut être effectué grâce aux outils standard du système de gestion de paquetage Linux. L’application peut être analysée grâce aux outils et utilitaires fournis avec le kit de développement LSB (LDK). Ces utilitaires peuvent confirmer au développeur les étapes requises pour mettre l’application en conformité avec LSB.

Gestion des abonnements

Des process doivent mis en place pour gérer les éléments suivants :

Droits d’abonnement attribués ou destinés à certains secteurs

Utilisateurs disposant de droits d’accès au Novell Customer Center

Installation du serveur d’abonnement pour l’utilisation

Test des best practicesComme a pu le constater Novell, l’un des points les plus délicats d’un déploiement est de déterminer les conditions de la réussite. Un accord doit être conclu entre les différentes parties quant aux fonctionnalités à respecter par le nouveau système. Les exigences relatives aux tests varient énormément d’une entreprise à une autre. Dans le cadre de la stratégie de déploiement, il convient de déterminer les ressources existantes pour les tests et d’élaborer un plan pour créer de nouvelles ressources de test afin de satisfaire toutes les exigences. Points à retenir lors d’un test :

Dresser l’inventaire des ressources de test existantes lors de la phase de découverte et de planification

Définir les ressources de test complémen-taires requises pour le déploiement

Consulter les parties prenantes lors du process d’acceptation et définir les critères avant le déploiement

Un test est une activité continue du début jusqu’à l’acceptation finale du système redéployé ; il associe toutes les tâches de déploiement

Obstacles courantsLes grands datacenters ne disposent généralement d’aucun inventaire fiable sur les matériels et logiciels en production. Il leur est donc difficile de répondre à la question suivante : que faut-il transférer exactement et sur quelles machines ? Ce risque peut être atténué en consacrant beaucoup de temps à la phase d’inventaire. Il ne suffit pas de dresser la liste de tous les serveurs ; des informations relatives aux applications exécutées et à toutes leurs dépendances doivent être recueillies. Avant de conclure la phase d’inventaire, l’entreprise doit non seulement savoir ce qu’exécute son datacenter, mais aussi comment les différentes composantes interagissent. Pour dresser un inventaire complet, il est préférable de suivre le protocole décrit à la section sur l’inventaire de ce document.

La plupart des entreprises informatiques ne disposent d’aucun critère formel de test, de validation et de certification, ni d’aucun système de test pour leurs piles. Elles sont donc incapables de répondre précisément à la question suivante : comment savoir si la pile migrée fonctionne correctement ? Avant d’entamer la migration, il est impératif de déterminer avec soin les critères de réussite. Si ces critères ne sont pas encore en place, ils doivent être définis. Ce problème, tout comme les problèmes liés à l’inventaire, doivent être identifiés et réglés dès le début du process. Novell recommande aux entreprises qui ne disposent d’aucune procédure d’inventaire ou de test de contacter une entreprise tierce justifiant d’une expérience sur ce type d’environnements.

p. 15

Guide d'approche de déploiement de SUSE Linux Enterprise Server www.novell.com

Beaucoup d’entreprises possèdent des services informatiques dont la croissance interne a été irrégulière. Les applications exécutées dans le datacenter ont été ajoutées conformément aux besoins, sans qu’aucune gestion de projet formelle et réutilisable ne soit en place. Il en résulte un mélange de systèmes, de plates-formes et d’applications variables en termes de complexité. Le paysage informatique est mal compris à tous les niveaux. Autrement dit, personne n’est en mesure de répondre facilement à la question suivante : comment se déroule ma migration ? Si nécessaire, Novell recommande d’établir formellement un bureau de gestion de programme pour toute la durée du projet de migration et même au-delà. Ce bureau peut être composé d’un seul intervenant, mais il faut au moins qu’une personne soit responsable du suivi de la migration en l’associant à des objectifs spécifiques.

Les projets de déploiement touchent souvent un aspect essentiel de l’activité d’une entre-prise. Par conséquent, la devise des équipes opérationnelles est souvent « tant que ça marche, on ne touche à rien » et elles tendent à résister au changement. Il est donc essentiel qu’un projet de migration soit soutenu par un haut responsable de l’entreprise. Une communication répétée des avantages du déploiement permettra de surmonter les objections. D’autre part, un employé influent en interne est nécessaire pour garantir le succès du projet. L’un des principaux arguments en faveur du déploiement concerne souvent la réduction des frais de licences matérielles et logicielles obtenue en réduisant la dépendance vis-à-vis d’un seul fournisseur. De plus, des avantages spécifiques peuvent généralement être trouvés pour rassurer les personnes qui ont encore des objections.

AnnexesAutres références

Ce document est destiné à présenter les best practices associées au lancement d’un

projet de migration de Red Hat Enterprise Linux vers SUSE Linux Enterprise Server. Les liens ci-dessous permettront aux lecteurs d’explorer plus en détail les process de migration mentionnés.

Compatibilité des applicationsCatalogue de logiciels SUSE Linux Enterprisewww.novell.com/partner/isv/isvcatalog

Migration vers SUSE Linux EnterpriseCours Novell 3068 - Migration de Red Hat vers SUSE Linux Enterprise Server 10 http://download.novell.com/protected/ Summary.jsp?buildid=ReHgN8b1qhU~

Construction de baseDocumentation AutoYaSTwww.suse.com/~ug/autoyast_doc/index.html

FAQ AutoYaSTwww.suse.com/~ug/AutoYaST_FAQ.html

Liste de diffusion AutoYaSThttp://lists.opensuse.org/opensuse-autoinstall/

SUSE Linux Enterprise 10 AutoYaSThttp://forgeftp.novell.com/yast/doc/SL10,0/autoinstall/index.html

Novell Forge : Importation de profils Kickstart de Red Hat dans AutoYaSThttp://forgeftp.novell.com/yast/doc/SL10.0/autoinstall/importkickstart.html

Sécurité Novell : Sécurité de Linuxwww.novell.com/linux/security/

Novell : Sécurité des applications avec AppArmorwww.novell.com/documentation/apparmor/

Sécurisez vos applications en déployant Novell AppArmor en parallèle à ZENworks Linux Managementwww.novell.com/connectionmagazine/2006/q3/pdf/techtalk4_q306.pdf

p. 16

Centre sur la sécurité Internet : SUSE Linux Enterprise Server - Test comparatif sur la sécuritéwww.cisecurity.org/tools2/linux/CIS_SUSE_ Linux_Benchmark_v1.0.pdf

Automatisation du datacenterNovell ZENworks Orchestrator www.novell.com/products/zenworks/

www.novell.com

Veuillez contacter votre revendeur Novell agréé ou contactez Novell directement aux adresses ci-dessous :

Novell FranceTour FranklinLa Défense 892042 Paris la Défense CédexFranceTél : (33) 1 55 62 50 00Fax : (33) 1 55 62 51 99

Novell Luxembourg S.à r.l.Route de Longwy, 57L-8080 BertrangeLuxembourgTél : +352 26923755Fax : +352 26923762

novell, Inc.404 Wyman Street Waltham, MA 02451 États-Unis

464-FR1037-001 | 01/09 | © 2009 Novell, Inc. Tous droits réservés. Novell, le logo Novell, le logo N, AppArmor, SUSE et ZENworks sont des marques déposées de Novell, Inc. aux États-Unis et dans d’autres pays.

*Toutes les marques commerciales de fabricants tiers appartiennent à leur propriétaire respectif.

Novell Logo1 The registered trademark, ®,

appears to the right and on thesame baseline as the Logo.

Minimum Size RequirementsThe Novell Logo should NOT beprinted smaller than 3 picas(0.5 inches or 12.5 mm) in width.

Clear-space Requirements2 Allow a clean visual separation

of the Logo from all other elements.The height of the "N" is themeasurement for the minimumclear-space requirements aroundthe Logo. This space is flat andunpatterned, free of other designelements and clear from the edgeof the page.

3 picas(0.5 in)

(12.5 mm)

21 3

3