Stage à IBM Montpellier - Guillaume CRESTA

Transcription

Institut Supérieur d’Informatique
Modélisation et leurs Applications
Complexe des Cézeaux – BP 125
63173 AUBIERE CEDEX
International Business Machines
Rue vielle poste
34 000 MONTPELLIER
Rapport de stage
3e année F5
Intégration d’un serveur Linux sur une
plateforme « Disaster / Recovery »
Présenté par :
Guillaume CRESTA
Responsable entreprise :
Mme Christine O’SULLIVAN
Responsable ISIMA :
M. Romuald AUFRERE
Avril 2006 – Octobre 2006
Institut Supérieur d’Informatique
Modélisation et leurs Applications
Complexe des Cézeaux – BP 125
63173 AUBIERE CEDEX
International Business Machines
Rue vielle poste
34 000 MONTPELLIER
Rapport de stage
3e année F5
Intégration d’un serveur Linux sur une
plateforme « Disaster / Recovery »
Présenté par :
Guillaume CRESTA
Responsable entreprise :
Mme Christine O’SULLIVAN
Responsable ISIMA :
M. Romuald AUFRERE
Avril 2006 – Octobre 2006
Rapport de stage ISIMA 2006
Page 3
REMERCIEMENTS
J’ai eu le plaisir d’effectuer mon stage de six mois au sein de l’entreprise IBM située à
Montpellier (34).
Je tiens à remercier plus particulièrement Christine O’Sullivan ma tutrice pour son accueil, sa
sympathie, et la confiance qu’elle m’a accordée tout au long de mon stage. Grâce à son suivi
et ses conseils lors de cette expérience j’ai pu réaliser un travail efficace. Ses explications
précises sur ses attentes nous ont permis de produire un travail rapide et ciblé.
Je remercie également Romuald Aufrere mon tuteur à l’ISIMA et Christine O’Sullivan pour
leur encadrement, leur disponibilité et leurs explications claires.
Je remercie Olivier Alluis et toutes les personnes du service Storage pour m’avoir accueilli au
sein de leur structure et m’avoir consacré du temps dès mon arrivée et tout au long de mon
stage ; tous ont toujours été disponibles et j’ai passé de bons moments en leur compagnie. Un
autre remerciement ira à Emmanuel Tong-Viet pour son aide sur la plateforme, le partage de
ses connaissances sur le SAN et sur l’entreprise.
Pour finir, je tiens à remercier toutes les personnes qui m’ont aidé d’un point de vue technique
(les personnes travaillant au setup, sur le réseau, sur la technologie System x) et relationnel
(les hôtesses d’accueil, les agents de sécurité) ainsi qu’aux membres de l’équipe de rugby
pour mon intégration dans le club de l’entreprise.
CRESTA Guillaume
Page 4
GLOSSAIRE
ABLE : Agent Building Learning Environment, permet la gestion des incidents sur un
System i.
AIX : Advanced Interactive eXecutive, système d'exploitation de type UNIX d'IBM, mais
seul l'acronyme est utilisé.
AMD : Advanced Micro Devices, entreprise américaine qui fut la première à briser le
monopole de son ancien partenaire Intel, en produisant ses propres processeurs 286 et 386
pour PC. Après de longues péripéties concernant le microcode, elle produit aussi, depuis
1993, des processeurs 486. AMD réussit également très bien dans le domaine des mémoires
flash et des processeurs RISC
ANSI : American National Standards Institute, organisme privé de normalisation américain à
but non lucratif. Il est le représentant des États-Unis à l'ISO (Organisation internationale de
normalisation).
ARS : Asset Recovery Service, une des divisions d’IBM présente sur le site de Montpellier et
qui est en charge de la valorisation des produits et de la réutilisation des produits des
générations précédentes.
ATM : Asynchronous Transfer Mode : Mode de transfert asynchrone, technique de réseau de
transmission d'informations numérisées permettant de transmettre simultanément sur le même
support et à de très hauts débits, différents types de contenus (vidéo, audio, données). Cette
technique permet l'utilisation optimale des capacités des lignes.
Benchmark : Banc d’essai permettant de mesurer les performances d’un système pour le
comparer à un autre.
CRESTA Guillaume
Page 5
Bridge : Equipement effectuant une conversion de protocoles, par exemple pour raccorder des
réseaux Ethernet et Token Ring.
CLI : Command Line Interface, invite de commande qui est un mode de contrôle d'un
ordinateur fonctionnant en ligne de commande (commandes tapées au clavier). Il utilise un
interpréteur de commandes en mode interactif.
CSC : Customized Solution Center, une des divisions d’IBM présente sur le site de
Montpellier et qui est en charge d’intégrer des logiciels et du matériel pour proposer des
solutions clés en main.
CSI : Consultants and Systems integrator Interchange, événement IBM comportant des
conférences techniques pour convaincre les clients.
DB2 : est un système de gestion de base de données utilisant le langage SQL tout comme
Oracle ou bien encore Mysql. Cette base de donnée est un système propriétaire appartenant à
IBM déployé sur les Mainframe, systèmes UNIX, Windows et Linux. Il existe une version
allégée pour les ordinateurs type PALM
DHCP : Dynamic Host Configuration Protocol, est un terme anglais désignant un protocole
réseau dont le rôle est d'assurer la configuration automatique des paramètres TCP/IP d'une
station, notamment en lui assignant automatiquement une adresse IP et un masque de sousréseau. DHCP peut aussi configurer l'adresse de la passerelle par défaut, des serveurs de noms
DNS et des serveurs de noms NBNS (connus sous le nom de serveurs WINS sur les réseaux
de la société Microsoft).
DLPAR : Dynamic Logical PARtitionning, permet aux administrateurs de réattribuer des
ressources matérielles et de s'adapter en fonction des modifications de configurations
matérielles requises, sans affecter la disponibilité du système.
DOS : Disk Operating System, système d'exploitation d'un ordinateur sous forme de
commandes texte compatible PC.
CRESTA Guillaume
Page 6
DRAM : Dynamic Random Access Memory, fut le type de mémoire à accès aléatoire
Random Access Memory RAM le plus utilisé dans les ordinateurs. La DRAM ne disposait
que d'un seul canal de transfert, au contraire de la VRAM qui en avait deux.
EMEA : Europe, Middle-East and Africa, Europe Moyen-Orient Afrique est un découpage
souvent retenu par les sociétés américaines.
E-port : Extension-port, pour un switch d’un port vers un switch.
ESCON : Enterprise Systems CONnection, est une interface série pour relier les systèmes de
stockage. Son débit est de 17 Mégabit par seconde.
ESS : Enterprise Storage Server est une baie de disque qui résout les problèmes de stockage
dans un environnement « On Demand ».
EXP : EXpandable storage Plus, est une solution de stockage de coût réduit pour la
connexion directe en grappe.
FC ou Fibre Channel : Fibre Channel est un protocole permettant une connexion haut débit
entre un ordinateur et son système de stockage. Il a été conçu à l'origine pour les superordinateurs, mais il est maintenant devenu le protocole standard des SAN. Le protocole Fibre
Channel peut fonctionner sur de la paire torsadée ou de la fibre optique.
FC-AL : Fiber Channel - Arbitated Loop L'interface FC-AL est une méthode de travail
optique point à point. Elle supporte néanmoins des câblages en cuivre beaucoup moins
onéreux. Le FC-AL peut être utilisé comme interface de stockage offrant de hauts niveaux de
performance pour les systèmes de stockage en informatique.
FCP : Fibre Channel Protocol.
FC-S : Fibre Channel Switched.
CRESTA Guillaume
Page 7
FICON : FIber CONnectivity, est le même type de protocole que ESCON sauf que celui-ci
se transmet sur support Fibre Channel.
Flash Copy : Service de copie d’IBM.
Fortran : FORmula TRANslation, est un langage de programmation utilisé principalement
en mathématiques et dans les applications scientifiques.
F-port : fabric-port, est la désignation d’un port d’un switch vers un nœud.
FSPF : Fabric Shortest Path First, protocole de cheminement utilisé dans des réseaux de fibre
channel. Il calcule le meilleur chemin entre les commutateurs, établit des itinéraires à travers
le réseau et calcule les itinéraires alternatifs dans le cas d'un d'échec ou d'un changement de
topologie. FSPF peut garantir la livraison de trames, même si la topologie de cheminement a
changé pendant un échec.
Gateway : Passerelle, le plus souvent entre deux réseaux mais aussi entre deux protocoles.
GBIC : GigaBit Interface Converter, est un module qui convertit un signal électrique en
signal optique.
GUI : Graphic User Interface. En opposition à la ligne de commande, le GUI permet de
s'affranchir de taper des lignes de commandes, pour pouvoir tout effectuer à la souris, en
mode graphique souvent sous forme web.
HACMP : High Availability Cluster MultiProcessing, technique de clustering utilisée par
IBM, à base de RSCT.
HACoC : High Availability Center of Competency, équipe fondée dans le but d’être plus
efficace sur les solutions de haute disponibilité proposées aux clients et de pourvoir des
recommandations régulières afin d’améliorer les infrastructures existantes.
CRESTA Guillaume
Page 8
HMC : Hardware Management Console, est un outil d’administration qui permet de gérer les
partitions logiques d’un système.
Hub : (Français : concentrateur) Élément de connectivité qui constitue une connexion
commune entre des composants d'un réseau en étoile. Les concentrateurs actifs nécessitent
une alimentation électrique car ils régénèrent et retransmettent les signaux sur le réseau. Les
concentrateurs passifs interconnectent simplement les éléments du réseau.
IBM : International Business Machines.
IEEE : L’Institute of Electrical and Electronics Engineers (que l’on peut prononcer « i trois
e ») est une organisation à but non lucratif.
iFCP : Protocole définissant une technique de stockage en réseau IP, dans laquelle les
instructions et les données Fibre Channel sont encapsulées dans des datagrammes IP, au
moment où elles sont acheminées d'un nœud à l'autre d'un réseau de stockage.
IFL : Integrated Facility for Linux, est un processeur d'unité centrale IBM consacré à
exploiter le logiciel d'exploitation Linux, avec ou sans z/VM. IFL est l'un des deux types de
processeurs d'unité centrale expressément conçus pour réduire des coûts de logiciel. (L'autre
type est zAAP.) Le microcode limite IFL à la charge de travail de Linux.
IGS : IBM Global Services, service d’IBM qui fournit un support aux équipes de
maintenance et maintient des parcs informatiques de nos clients.
ISC : Integrated Supply Chain, service d’IBM qui a pour mission l’assemblage des grands
systèmes IBM.
iSCSI : Technique consistant à faire passer des commandes SCSI à travers une pile IP. Le
principe est de piloter des disques durs SCSI à distance via le réseau de façon transparente,
dans le cadre du SAN.
CRESTA Guillaume
Page 9
ISIMA : Institut Supérieur d’Informatique Modélisation et leurs Applications, est une école
d’ingénieur en informatique située à Clermont-Ferrand (63).
IO : Input Output, désigne un périphérique acceptant de recevoir et d’émettre des données, ou
l’ensemble des périphériques permettant d’échanger des données avec la carte mère.
LAN : Un réseau local (en abrégé RLE pour réseau local d'entreprise, en anglais LAN pour
Local Area Network) est un réseau informatique à une échelle géographique relativement
restreinte, par exemple une salle informatique, une habitation particulière, un bâtiment ou un
site d'entreprise.
LC : connecteurs mâles fibre channel pour un débit de 2 ou 4 GB.
Linux : noyau de système d’exploitation de type UNIX, inventée par Linux Torvalds.
L-port : est la désignation d’un port d’un hub.
LUN : Logical Unit Number, est employé pour identifier des dispositifs SCSI, ainsi le host
peut adresser et accéder aux données sur chaque unité de disque d’un array.
Mc Data : spécialiste dans les solutions de sécurité pour le stockage.
MFM : Modified Frequency Modulation, type de codage numérique de l’information sur
disque dur. Ce type d’encodage est limité aux disques de capacité inférieure à 20 Mo et
autorise un débit maximum de 625 Kbytes.
NAS : Network Acces Server, équipements utilisés par les opérateurs dans le cadre des
services d'accès à Internet par le réseau téléphonique commuté. Ils servent à transformer les
communications téléphoniques en flux de données IP en assurant l'interface entre le réseau
téléphonique commuté et le réseau de transport de données IP
NetFinity : est un modèle de la gamme System X d’IBM.
CRESTA Guillaume
Page 10
NL-port : est la désignation d’un port d’un nœud vers un hub.
N-port : Node-port, est la désignation d’un port d’un nœud (serveur, système de stockage)
vers un switch.
Oracle : Oracle est un système de gestion de base de données relationnelle fourni par Oracle
Corporation et couramment utilisé dans les applications sur différentes plateformes. Il a été
développé par Lawrence Ellison, accompagné d'autres personnes telles que Bob Miner et Ed
Oates.
OSI : Open Systems Interconnection, désigne le modèle de référence permettant d'assurer les
échanges d'information entre des systèmes hétérogènes. Ce modèle, dit à sept couches, définit
sept niveaux de compatibilité (physique, liaison de données, réseau, transfert, session,
présentation, application).
PC : Personal Computer, désigne un ordinateur personnel.
Pentium III Xéon : est un processeur informatique de la gamme x86 fabriqué par Intel.
PPRC : Peer to Peer Remote Copy, logiciel de la firme StorageTek permettant d'automatiser
des copies massives de sécurité en temps réel d'espaces de stockage d'un serveur vers un autre
sans en dégrader les performances générales.
PSSC : Product and Solutions Support Center, service d’IBM permettant de démontrer les
avantages des systèmes IBM.
R&D : Les activités de R&D (Recherche et Développement) servent la stratégie de
développement de l'organisation. Ses missions consistent à anticiper les révolutions
technologiques, les ruptures d'usages et à innover.
RAMAC : Random Access Method of Accounting and Control, est le premier ordinateur
équipé d’un disque dur composé de 50 plateaux de 24" pouvant stocker un volume
considérable de données, 5 millions d’octets.
CRESTA Guillaume
Page 11
RISC : Reduced Instruction-Set Computer. Le microprocesseur à jeu d'instruction réduit est
une architecture matérielle de microprocesseurs. On l'a opposé à la fin des années 1980 et au
début des années 1990 à l'architecture CISC (Complex Instruction-Set Computer).
Routeurs : Un routeur est un matériel de communication de réseau informatique. Son travail
est de déterminer le prochain nœud du réseau auquel un paquet de données doit être envoyé,
afin que ce dernier atteigne sa destination finale le plus rapidement possible. Ce processus
nommé routage intervient à la couche 3 (couche réseau) du modèle OSI. Le routage est
souvent associé au protocole de communication IP, même si d'autres protocoles routables
moins populaires existent.
RSCT : Reliable Scalable Cluster Technology. Logiciel de glu (programme permettant de
faire fonctionner ensemble d'autres programmes) utilisé par IBM pour faire tenir ses clusters
GPFS ou HACMP en un seul morceau, à l'origine pour les RS/6000 SP, puis porté sur d'autres
plateformes du groupe.
SAN : Storage Area Network, est un réseau spécialisé permettant de partager de l'espace de
stockage à une librairie de sauvegarde et à des serveurs.
SC : Connecteurs mâles d’une fibre channel pour un débit de 1 GB.
SCSI : Small Computer System Interface, est un standard définissant un bus informatique
permettant de relier un ordinateur à des périphériques ou bien même à un autre ordinateur.
SFP : Small form Factor Pluggable.
SLT : Solid Logic Technology, est une technologie de fabrication de circuits électroniques
développée par IBM dans les années 1960 pour la série d’ordinateurs S/360. Elle consistait à
assembler les divers circuits sur une plaquette de céramique puis d’interconnecter plusieurs de
ces plaquettes pour arriver au circuit logique final voulu.
CRESTA Guillaume
Page 12
SMT : Simultaneous MultiThreading, est une technologie proposée afin d’améliorer
l’efficacité globale des unités centrales de traitement. SMT permet aux multiples tâches
indépendantes d’exécution d’utiliser au mieux les ressources fournies par des architectures
modernes de processeur.
SNIA : Storage Network Industry Association, association de normalisation et de promotion
des systèmes SAN, formée en 1997 et dont le but est normalement non lucratif.
SSA : Serial Storage Architecture, interface série de disque dur à la norme SCSI.
SSPD : Solution Scénario Profile upDate, est une publication rapide d’une conception de
solution. Elle contient juste assez d’information pour nous laisser déterminer dans quel but la
solution a été utilisée et comment celle-ci fonctionne.
Switch : un switch ou commutateur est un dispositif électronique servant de commutateur
réseau et permettant de créer un réseau informatique local de type ethernet. Ce dispositif est
dit intelligent par opposition au hub car, alors que ce dernier fait transiter les données par
toutes les machines, le switch permet de diriger les données uniquement vers la machine
destinataire.
System i : serveurs ayant une base de donnée relationnelle directement intégrée au système
d’exploitation.
System p : serveur IBM permettant le calcul scientifique très rapide en précision étendue.
System x : serveurs en lames (cartes équipées de processeur Intel) pouvant être modifées et
réparés au vol sans arrêt du système.
System z : désignation des mainframes 64 bits IBM.
System/360 : est une famille de système d'ordinateur central annoncée par IBM le 7 avril
1964. C'était la première famille des ordinateurs faisant une distinction claire entre
l'architecture et l'exécution. L'architecte en chef du S/360 était Gene Amdahl.
CRESTA Guillaume
Page 13
Token-Ring : L'Anneau à jeton, plus connu internationalement sous le terme de Token-Ring,
est un protocole de réseau local qui fonctionne sur les couches Physique et Liaison du modèle
OSI. Il utilise une trame spéciale de trois octets, appelée jeton, qui circule dans une seule
direction autour d'un anneau. Les trames Token Ring parcourent l'anneau dans un sens qui est
toujours le même.
ULP : Upper Layer Protocol, application logique de couche haute employant les services
Unix : UNIX est un système d'exploitation, à usage principalement professionnel,
conceptuellement ouvert (nombreux outils qui font une chose et la font bien), multitâche et
multiutilisateur, créé en 1969.
VE : Virtualization Engine, logiciel d'IBM permettant d'exécuter plusieurs serveurs (jusqu'à
10) Unix sur un unique microprocesseur. Par exemple, une machine quadri-processeurs
pourra simuler jusqu'à 40 systèmes processeurs, ce qui autorise 40 instances d'un seul système
d'exploitation (OS), ou 40 versions d'un même OS, voire 40 OS différents. Virtualization
Engine utilisera les outils de logistique et de gestion de Tivoli, et empruntera des fonctions de
WebSphere.
WAN : Wide Area Network, réseau étendu : Réseau qui communique sur une longue
distance, comme à l’échelle d’une ville ou à travers le monde.
Windows : est une gamme de systèmes d'exploitation propriétaires pour des ordinateurs
personnels, principalement distribuée pour les plateformes x86 (Intel/AMD). Si ses versions
les plus récentes sont des systèmes d'exploitation complets 32 ou 64 bits, multi-utilisateur,
multitâches, et parfois même multi-poste, Windows a commencé par être une simple interface
graphique fonctionnant sous DOS.
WWN : World Wide Name, est un unique identifiant dans le réseau de stockage type fibre
channel. Chaque WWN est un nombre de 8 bits dérivé d’un IEEE OUI (pour les 3 premiers
bits) et d’une information de vendeur (pour le reste).
CRESTA Guillaume
Page 14
WWNN : World Wide Node Name, est le World Wide Name que possède les nœuds d’un
réseau SAN.
WWPN : World Wide Port Name, est le World Wide Name que possède le port fibre channel
du nœud d’un réseau SAN.
CRESTA Guillaume
Page 15
TABLE DES ILLUSTRATIONS
Figure 1 : Photos d’IBM Montpellier..............................................................................21
Figure 2 : Répartition du chiffre d’affaire suivant le secteur d’activité ..........................22
Figure 3 : Répartition des secteurs PSSC........................................................................25
Figure 4 : Organigramme du PSSC.................................................................................26
Figure 5 : Schématisation d’un réseau SAN ...................................................................27
Figure 6 : Architecture du SAN ......................................................................................28
Figure 7 : Technologie du SAN ......................................................................................29
Figure 8 : Différents types de stockage ...........................................................................32
Figure 9 : Photo du System x ..........................................................................................34
Figure 10 : Photo du BladeCenter ...................................................................................35
Figure 11 : Photo de la famille System p ........................................................................38
Figure 12 : Photo de l’Open Power 750 ..........................................................................39
Figure 13 : Illustration d’un partitionnement logique .....................................................40
Figure 14 : Protection LPAR dans un environnement IBM Power 5..............................41
Figure 15 : Photo de la famille System i .........................................................................41
Figure 16 : Schématisation du concept de capacité temporaire ......................................43
Figure 17 : Différentes applications intégrables sur System z ........................................43
Figure 18 : Photo du Z9...................................................................................................44
Figure 19 : Plateforme HACoC à mon arrivée................................................................46
Figure 20 : Plateforme HACoC à venir...........................................................................48
Figure 21 : Zoning, nom de la zone ................................................................................52
Figure 22 : Zoning, sélection des WWPN.......................................................................53
Figure 23 : Zoning, clôture de la zone ............................................................................53
Figure 24 : Zoning, enregistrement et application ..........................................................54
Figure 25 : Signalisation du port .....................................................................................55
Figure 26 : Information sur le port interrogé...................................................................55
Figure 27 : Schématisation du cycle Global Mirror........................................................73
Figure 28 : Planning de travail au début du stage ...........................................................78
Figure 29 : Planning de travail effectif............................................................................79
CRESTA Guillaume
Page 16
RESUME
IBM est une multinationale américaine qui est un des leaders dans le monde des
serveurs. Elle est implantée entre autre en Languedoc-Roussillon à Montpellier. Une des
principales préoccupations des clients est la continuité du business. Pour cela, IBM
développe une plateforme de disaster / recovery dans le but de prouver la haute
disponibilité de leurs produits. La solution utilisée basée sur un System x avec Linux comme
système d’exploitation en relation avec une baie de stockage correspond parfaitement aux
besoins et attentes du service Storage d’IBM Montpellier. Ma tutrice de stage Christine
O’Sullivan avait précédemment développé une plateforme de haute disponibilité contenant
un serveur AIX, une baie de stockage sur deux sites distants, un situé à Montpellier et l’autre
à Poughkeepsie. Afin d’obtenir une diversité de serveurs sur la plateforme « Disaster /
recovery » entre les Etats-Unis et la France, un serveur Linux y a été intégré. Une analyse de
compatibilité entre la baie de stockage et le serveur, a été effectuée avant la réalisation du
projet. Pour le développement de cette partie de la plateforme, je me suis servi de mes acquis
en matière de SAN, de service de copie, et de Linux.
Le projet réalisé répond entièrement aux attentes de Mme O’Sullivan. Il permet une
diversité de serveurs sur la plateforme. Ce module étant réalisé dans le cadre d’un projet de
grande envergure permet d’étoffer un peu plus la plateforme et de donner plus de poids à
celle-ci.
Mots clés : continuité du business, plateforme de disaster / recovery, Linux, baie de stockage,
haute disponibilité, diversité de serveurs.
ABSTRACT
IBM is an american firm, leader in the servers’ world leadership. It’s located in
Montpellier, Languedoc-Roussillon. One of the clients’ main preoccupations is the business
continuity. That’s why IBM is developing a disaster/recovery platform in order to prove
the high availability of their products. The used solution, based on a System X, with an
operating system Linux, in relation with a storage unit perfectly corresponds to the Storage
service of IBM Montpellier needs and attempts. My supervisor Christine O’Sullivan has
previously developed a high availability platform containing an AIX server, a storage unit
on two distant sites, one in Montpellier and the other one in Poughkeepsie. In order to obtain
a diversity of servers on the “disaster / recovery” platform between the United States of
America and France, a Linux server has been integrated. A compatibility analysis between
the storage unit and the server has even been studied before the realization of this project. In
order to develop this part of the platform, I used my own competencies in SAN, copy services
and in Linux.
This specific project fully fits to Mrs O’Sullivan’s needs. It allows a diversity of
servers on the platform. This module which is realized within the framework of a great scale
project extends the platform capacities and gives it more strategic opportunities.
Keywords: business continuity, disaster / recovery platform, Linux, storage unit, high
availability, diversity of servers.
CRESTA Guillaume
Page 17
SOMMAIRE
REMERCIEMENTS
GLOSSAIRE
TABLE DES ILLUSTRATIONS
RESUME, ABSTRACT
SOMMAIRE
INTRODUCTION ________________________________________________________ 18
I
PRESENTATION GENERALE __________________________________________ 19
I.1
Présentation de l’entreprise _________________________________________ 19
I.1.1 Historique ______________________________________________________ 19
I.1.2 Présentation des activités d’IBM ____________________________________ 21
I.1.3 Présentation des activités de Montpellier ______________________________ 22
I.1.4 Présentation du PSSC _____________________________________________ 23
I.1.5 Gamme IBM ____________________________________________________ 27
I.1.5.1 SAN_______________________________________________________ 27
I.1.5.2 Baies de stockage ____________________________________________ 29
I.1.5.3 IBM System anciennement appelé e-server ________________________ 33
I.2
Présentation de la plateforme High Availability Center of Competency
(HACoC) ______________________________________________________________ 44
I.2.1 Objectifs de la plateforme __________________________________________ 44
I.2.2 Technologies utilisées _____________________________________________ 45
I.2.3 Future plateforme ________________________________________________ 47
I.3
II
Cahier des charges ________________________________________________ 49
REALISATION DU PROJET ____________________________________________ 51
II.1 Intégration Linux _________________________________________________ 51
II.1.1
Configuration du SAN ___________________________________________ 51
II.1.2
Configuration des disques ________________________________________ 56
II.1.3
Installation de sdd outil de multipathing_____________________________ 60
II.2
III
Global Mirror ____________________________________________________ 65
RESULTATS ET DISCUSSIONS_______________________________________ 76
III.1
Travail effectué conformément au cahier des charges____________________ 76
III.2
Méthodologie et planning ___________________________________________ 77
III.3
Difficultés rencontrées _____________________________________________ 79
III.4
Améliorations possibles_____________________________________________ 84
CONCLUSION ___________________________________________________________ 86
OUVRAGES CONSULTES_________________________________________________ 87
CRESTA Guillaume
Page 18
INTRODUCTION
Dans le cadre de ma troisième année d’étude à l’Institut Supérieur d’Informatique de
Modélisation et des Applications, j’ai effectué un stage de six mois, d’avril 2006 à octobre
2006, sous la tutelle de M. Romuald AUFRERE professeur à l’ISIMA. Ce stage s’est déroulé
dans l’entreprise IBM à Montpellier (Hérault) au sein du Products and Solutions Support
Center (PSSC) sous la direction de Mme Christine O’Sullivan.
L’une des responsabilités de ce département est de déployer différentes solutions afin
de les vendre à ses clients. Il faut donc développer des solutions très pointues. La plateforme
actuelle permet de démontrer une solution de « Disaster / Recovery » entre deux sites distants
de 7000 kilomètres. Elle est dotée dans un premier temps de serveurs AIX. L’objectif est
d’intégrer un serveur Linux et Windows sur celle-ci afin de diversifier la plateforme et ainsi
fournir une meilleure offre aux clients. J’ai donc été accueilli en tant que stagiaire pour
intégrer un serveur Linux sur la plateforme afin de la varier et de tester les performances du
serveur Linux.
Tout d’abord je devais m’adapter au fonctionnement d’IBM, et appréhender les
technologies sur lesquelles j’allais travailler et que je devais utiliser par la suite, puis élaborer
des configurations par rapport aux discussions échangées avec les membres de l’équipe et
enfin réaliser le « module » de la plateforme. L’objectif principal était donc de pouvoir
intégrer un serveur System X muni d’un système d’exploitation Linux permettant de
diversifier la plateforme qui contenait déjà un serveur AIX et utiliser des services de copie
afin de sauvegarder les données sur un site distant de plus de 7000 kilomètres. Ce serveur se
devait d’être accessible à tous et d’être compatible avec la plateforme déjà en place.
Dans un premier temps, je vais présenter l’entreprise dans laquelle j’ai effectué mon
stage, puis les connaissances et technologies apprises, et enfin la plateforme sur laquelle j’ai
travaillé. Ensuite, j’expliquerai le travail effectué sur la plateforme, que ce soit le serveur
Linux, les services de copie ou les applications présentes sur le Linux, et mes choix
techniques et les différents développements pour répondre à ces attentes, ainsi que les
différentes évolutions. Enfin, je présenterai les différentes phases du stage ainsi que les
difficultés rencontrées et les possibles améliorations à apporter. Je conclurai ce rapport en
soulignant ce que m’a apporté ce stage, tant au niveau technique et professionnel qu’au niveau
humain.
CRESTA Guillaume
I
Page 19
PRESENTATION GENERALE
I.1
Présentation de l’entreprise
I.1.1
Historique
IBM est une société américaine fondée en 1911. Surnommée Big Blue, cette entreprise
est le leader mondial dans le domaine informatique avec plus de 300 000 employés à travers
le monde. IBM est à l’origine de la très grande majorité des technologies informatiques.
En 1944, IBM lance son premier ordinateur Mark 1. Il fut développé en collaboration avec
l’université d’Harvard. A cette époque, c’est l’unique machine qui est capable d’exécuter des
opérations simultanément. Il mesure 15,24 mètres de long, 2,44 mètres de haut et pèse 5
tonnes. Mark1 additionne une opération en une seconde, mais il met environ six secondes
pour une multiplication et le double pour une division. En 1952, la firme introduit l’IBM 701,
un ordinateur à lampes. Les lampes sont plus faciles à remplacer que les pièces
électromécaniques du Mark1. L’IBM 701 exécutait 17 000 instructions par secondes, et fut
utilisé par le gouvernement et la recherche. En 1956, IBM crée le Fortran, un langage de
programmation basé sur le langage de l’algèbre, de la grammaire et des règles syntaxiques. Ce
langage est utilisé pour le travail technique. L’année suivante, IBM crée l’IBM 305 RAMAC
qui fut le tout premier ordinateur possédant un disque de stockage. En une seconde, le
RAMAC retrouve les données stockées dans cinquante disques rotatifs de 61 cm et stocke 5
Mo. En 1959, les transistors remplacent les lampes. L’IBM 7090, un des premiers ordinateurs
fabriqués avec des transistors, atteint alors des performances de 229 000 calculs par seconde.
L’Air Force utilisa le 7090 pour gérer le « Balistilic Missile Early Warning System ».
Dans les années soixante, IBM devient le leader mondial de l’informatique. Il installe alors
90% des ordinateurs en Europe, son chiffre d’affaire et son personnel augmentent fortement.
Le 7 avril 1964, IBM introduit le System/360, une large « famille » d’ordinateur
interchangeable entre les logiciels et périphériques. Le S/360 offre un choix de cinq
processeurs et de 19 combinaisons de puissance, de vitesse et de mémoire. L’utilisateur peut
employer des cassettes à bandes magnétiques ou des disques combinés avec un processeur
100 fois plus rapide. Le System/360 offre des gains de performance incomparables avec le
Solid Logic Technology, des modules de céramique et contient des circuits de transistors de
plus en plus petits.
CRESTA Guillaume
Page 20
Dans les années soixante-dix, IBM réalise quelques inventions. Tout d’abord, en 1971, elle
invente la première disquette (8 pouces ¼) pour stocker les informations personnelles. Puis,
en 1973, IBM invente les lecteurs optiques pour les supermarchés. Depuis cette date, les
banques utilisent l’IBM 3614 pour faciliter les transactions. Elle invente successivement le
disque dur, le curseur, la DRAM qui constitue la mémoire vive dynamique, ainsi que les bases
de données relationnelles.
En 1980, IBM réalise des travaux sur l’architecture RISC et lance le PC. Ce n’est pas une
machine spectaculaire en technologie. Elle offre 16 ko à 256 ko et possède un ou deux
lecteurs de disquettes de 5 pouces ¼ ou un disque MFM de 10/20 Mo. Pour le PC, IBM utilise
un processeur INTEL et le système d’exploitation DOS. IBM réalise alors de nombreux
travaux sur DOS et élabore un microscope à effet tunnel (prix nobel de Physique attribué à
Gerd Binnig et Heinrich Roher, chercheurs à IBM). En 1985, IBM invente le réseau local
Token-Ring qui permet aux PC d’échanger des données dans un même immeuble. Dans les
années 80, IBM travaille également sur son Unix propre : AIX. Il est un des systèmes les plus
stables et robustes. IBM est également à l’origine de la célèbre combinaison de touches Ctrl +
Alt + Suppr.
Dans les années 90, IBM met en place le power PC et lance le serveur Net Finity comprenant
des processeurs Pentium III Xeon, ainsi que des unités de stockage pouvant atteindre 12 To de
disques.
Durant les années 90, IBM fut un des pionniers du e-business, à la pointe de l’innovation. La
firme est devenue un acteur majeur du progrès grâce à la mobilisation de toutes les actions
pour ses clients : services, technologies de l’information, matériels et logiciels. Portée par
l’anticipation du besoin du client, IBM a centré sa stratégie autour du « e-business on
Demand » modifiant ainsi sa culture et sa stratégie. L’e-business, concept lancé par IBM en
1996, est l’utilisation par l’entreprise des nouvelles technologies, par exemple Internet, pour
apporter plus de valeur ajoutée et d’efficacité à la relation qu’elle entretient avec ses clients,
partenaires, fournisseurs et employés. L’e-relation client est un facteur d’accroissement du
chiffre d’affaire et de la productivité des forces commerciales. L’e-procurement ou gestion
des achats en ligne facilite les relations avec ses fournisseurs. A l’heure actuelle, 98 % des
transactions réalisées par IBM en France sont électroniques, pour des commodités aussi
variées que les fournitures, les voyages ou les services. Au niveau mondial, IBM est présent
dans près de 170 pays, cela représente plus de 300 000 collaborateurs dans le monde dont
environ 10 000 en France. IBM a réalisé un chiffre d’affaire de près de 96,5 Milliards de
CRESTA Guillaume
Page 21
dollars en 2004 avec une croissance de plus de sept pour cent par rapport à l’année
précédente.
Figure 1 – Photos d’IBM Montpellier
I.1.2
Présentation des activités d’IBM
IBM développe plusieurs activités qui sont la recherche et le développement, les logiciels
(17,3 % du chiffre d’affaire), les serveurs (26,7 % du chiffre d’affaire), et les services (52 %
du chiffre d’affaire).
Du point de vue de la recherche et du développement, IBM représente la plus vaste entité de
recherche mondiale dans le domaine des technologies de l’information avec plus de 3000
chercheurs et ingénieurs, huit laboratoires de R&D fondamentales, basés à New-York, San
José, Austin, Zurich, Haifa, Tokyo, Beijing et Dehli ; répartis dans six pays, vingt-quatre
laboratoires logiciels et avec un investissement annuel de plus de cinq milliards de dollars.
Pour la onzième année consécutive IBM a été, en 2004, le numéro 1 aux Etats-Unis en terme
de nombre de brevets obtenus. Cela représente un écart de 1600 brevets par rapport à son
concurrent informatique le plus proche. La société dépose environ 3000 brevets par an. Elle a
à son actif 30 000 brevets dont 6000 brevets logiciels.
D’un point de vue logiciels et software, IBM se positionne sur le marché comme le numéro 2
mondial du logiciel avec un CA de 15,1 Milliards de dollars en 2004. IBM est numéro 1
mondial en part de marché dans le domaine des bases de données (Gartner/Dataquest). Ces
résultats sont dus avant tout au développement d’IBM software avec l’acquisition en 2003
CRESTA Guillaume
Page 22
d’Information Laboratory (Rational), Aptrix (DB2), Green Pastures (DB2), CrossAccess
(DB2) et ThinkDynamics (Tivoli).
En matière de serveurs, la société IBM en est le premier fournisseur mondial avec 31, 8% de
part de marché en 2003.
Avec environ 320 000 collaborateurs opérant dans 170 pays, IBM Global Services (IGS) est
la plus grande entreprise mondiale de services et de conseils dans les technologies de
l’information. Depuis sa création en 1991, IBM Global Services est devenu la plus grande
division de l’entreprise. Elle a pour mission d’aider ses clients à développer des solutions
innovantes et à forte valeur ajoutée dans différents secteurs d’activités. Cette activité
représente 52% du chiffre d’affaire d’IBM.
L’acquisition de Pricewaterhouse Coopers Consulting, en septembre 2002, permet à IBM
d’offrir aux entreprises une multitude de compétences et place l’entreprise en tête des sociétés
de conseils et de services de haute technologie. A l’issue de cette fusion, a été créée la
nouvelle entité IBM Business Consulting Services qui fournit des prestations de conseils
fondées sur l’expertise sectorielle et le savoir-faire en technologie de pointe.
Répartition du chiffre d'affaire suivant
le secteur d'activité
3%
17%
1%
52%
27%
Financement
Logiciel
Divers
Matériels
Services
Figure 2 – Répartition du chiffre d’affaire suivant le secteur d’activité
I.1.3
Présentation des activités de Montpellier
Depuis sa création en 1965, le site de Montpellier a développé une expertise unanimement
reconnue dans la fabrication et le support des grands systèmes. Historiquement basée sur la
fabrication des grands serveurs d’entreprises, IBM Montpellier se diversifie et développe des
CRESTA Guillaume
Page 23
activités de service en partageant son expertise avec ses clients de la zone Europe Moyen
Orient Afrique (EMEA). Le site d’IBM Montpellier fait partie de la zone Europe du Sud dont
le siège est à Madrid. Ce site est le premier exportateur de la région Languedoc-Roussillon,
compte 1000 employés et reçoit environ 8000 visiteurs par an. Deux divisions sont
principalement représentées sur le site : l’IGS et l’ISC (Integrated Supply Chain). Dans l’IBM
Global Services, on trouve l’European Server Support Center qui fournit un support aux
équipes de maintenance des pays d’EMEA pour les serveurs fabriqués à Montpellier. On
trouve également l’Infogérance qui a pour mission la maintenance des parcs informatiques
des clients, en garantissant la sécurité, la fiabilité, la haute disponibilité et l’industrialisation
de l’exploitation informatique de ces derniers ainsi que la formation de leurs équipes
techniques. Son objectif principal est de garantir le taux maximal de disponibilité des
solutions basées sur les IBM eServer. Les spécialistes de ce centre fournissent un support
technique de niveau 1 et 2 aux équipes de maintenance européenne. Dans l’Integrated Supply
Chain, on trouve tout d’abord la production qui a pour mission l’assemblage des grands
systèmes IBM.
On trouve sur ce site également deux autres divisions qui sont l’Asset Recovery Service
(ARS) et le Customized Solution Center (CSC). L’ARS est un centre de valorisation des
produits et est en charge de la réutilisation des produits de générations précédentes de manière
efficace. La valorisation des équipements d’occasion s’opère aux travers des activités telles
que la réutilisation des équipements qui ont encore une valeur sur le marché et le recyclage
pour tous les autres. Pour cette deuxième activité, IBM respecte scrupuleusement
l’environnement en allant très souvent au-delà des normes réglementaires. Le CSC, en
intégrant des matériels et des logiciels, IBM ou non IBM, permet aux ventes et à l’IGS de
proposer des solutions clés en main.
I.1.4
Présentation du PSSC
Le PSSC, créé en 1995, est le lieu où l’on démontre les avantages des systèmes IBM. On
s’assure que les exigences des clients sont servies au mieux par les équipes concernées. Le
PSSC est basé sur le site d’IBM Montpellier, il reçoit environ 8000 visiteurs par an
représentant 1200 compagnies provenant de 58 pays, participant à 1046 engagements
exécutés dans le centre de Montpellier. Le PSSC est composé d’une équipe de 230 ingénieurs
et architectes informatiques qui ont pour mission d’aider les forces commerciales d’IBM à
CRESTA Guillaume
Page 24
signer des affaires lorsque la décision du client repose sur la validation technique d’une
solution. Cette équipe aide ainsi les clients à mettre en oeuvre les technologies les plus
avancées et sert de support clientèle au niveau EMEA. L’objectif est de conclure des affaires
en montrant les avantages des solutions IBM et en répondant aux exigences critiques des
clients ou partenaires.
Souvent le centre est soumis à des questions de performance, d’adaptabilité, de disponibilité,
de possibilité de gestion, de fonctionnalité ; et les 230 professionnels du centre conseillent les
clients en définissant une architecture appropriée et des scénarios de tests permettant de
prouver les performances et les fonctionnalités de la solution testée, et tentent de mettre en
œuvre et de gérer un projet de benchmark pour délivrer des résultats concluants face aux
espérances du client.
L’envergure du support n’est pas limitée à l’infrastructure du système. Grâce à des années
d’expérience, les équipes du PPSC fournissent une qualité sur la configuration et la
performance du « On Demand Business », sur les applications scientifiques et techniques
disposées sur les serveurs IBM et sur les plateformes de stockage. Le noyau de l’activité est
focalisé sur le benchmarking, la performance et la validation des solutions.
Les activités du PSSC sont l’organisation de séminaires techniques personnalisés et de
conférence, la réalisation d’études de faisabilité des solutions, le « benchmarking » ou test de
validation et le transfert de compétences au travers de formation, de consulting et d’assistance
technique.
Le PSSC dispose de plusieurs services. Tout d’abord, il dispose d’un centre de briefing qui
permet d’organiser des séminaires techniques personnalisés, des conférences, des événements
pour convaincre les clients (par exemple l’événement Consultants & Systems Integrator
Interchange (CSI)) et les partenaires des avantages des différentes plateformes IBM, ainsi que
des briefings fait sur mesure et détaillés d’un point de vue technologique. Le PSSC dispose
également d’un centre de solution qui permet de fournir des solutions complètes aux clients
en partenariat avec différents éditeurs comme Oracle, Siebel, et de réaliser des études de
faisabilité de solutions applicatives ou techniques. Le centre Benchmark permet au client
d’évaluer les performances des plateformes IBM et permet également de faire des tests de
validation. Ce centre teste l’environnement de production du client simulé sur les solutions
IBM. Ce centre est également utilisé lorsqu’on désire vérifier que l’on prend le minimum de
risque avant de mettre une nouvelle solution dans l’environnement existant d’un client.
CRESTA Guillaume
Page 25
Enfin, IBM propose un transfert de compétences au travers de formations, de consulting, et
d’assistance technique proposée en partie par le centre d’éducation qui forme essentiellement
sur les technologies des eServer et du TotalStorage. Le service éducation dispose
d’équipements complets et d’ateliers avancés d’un point de vue technologique afin de
convaincre le client de la valeur des propositions IBM, et passe du temps en laboratoire sur les
configurations de systèmes adaptées aux besoins du client.
Répartition des secteurs PSSC
2%
24%
36%
15%
23%
Technical support
Education & NTC Wildfire
Briefing
Benchmark & POC
Testing services & porting
Figure 3 – Répartition des secteurs PSSC
CRESTA Guillaume
CRESTA Guillaume
Figure 4 - Organigramme du PSSC
Page 26
I.1.5
Page 27
Gamme IBM
I.1.5.1 SAN
“A network whose primary purpose is the transfer of data between computer systems and
storage elements and among storage elements. A SAN consists of a communication
infrastructure, which provides physical connections, and a management layer, which
organizes the connections, storage elements, and computer systems so that data transfer is
secure and robust” est la définition formelle du SAN donnée par la SNIA, l'un des organismes
contribuant à sa standardisation. Le SAN est un réseau à haut débit géré de façon centrale et
constitué de serveurs d'applications, d'unités de stockage et d'équipements réseaux
hétérogènes. Il permet aux entreprises de tirer le meilleur parti de leurs données au travers
d'un accès universel et d'un partage des ressources.
Figure 5 – Schématisation d’un réseau SAN
Le SAN a été conçu car il y avait non seulement une limitation du nombre de serveurs et de
stockage avec le SCSI mais aussi une limitation de distance. Avec les LANs, la distance n’est
plus un problème et l’échange ne se fait que via les serveurs.
CRESTA Guillaume
Page 28
Le SAN permet donc une communication directe, fiable et performante, "any-to-any" entre
tous les serveurs d'application et les systèmes de stockage qui leur sont connectés, ainsi que
des transferts de données directs entre systèmes de stockage. Le but de cette architecture est
de faire des réplications, des archivages, des sauvegardes et des restaurations de données. On
évite ainsi le transit de celles-ci sur le réseau local (LAN) entre les serveurs d'applications et
de sauvegarde. Le SAN ouvre les perspectives de consolidation de stockage, de partage de
données, de déport des unités de stockage et de solutions de reprise après désastre. Les
principaux avantages du SAN sont une interconnexion simple et standardisée et l'amélioration
des performances dont : la vitesse, le nombre important de serveurs et éléments de stockage
interconnectables, l’extensibilité du stockage, la consolidation et le partage des données,
l'amélioration des procédures de sauvegarde/restauration, l’administration centralisée, une
haute disponibilité du système d'information et l'indépendance des choix et des évolutions de
l’élément serveur/stockage.
Figure 6 – Architecture d’un réseau SAN
CRESTA Guillaume
Page 29
Figure 7 – Technologie du SAN
Le réseau SAN se caractérise par une transmission de type "série", bidirectionnelle ("full
duplex") sur fibre optique à 100/200/400 Méga Octet par seconde, suivant un protocole appelé
Fibre Channel. Le terme bidirectionnelle est employé pour des liaisons point à point et pour
des liaisons switchées dont nous allons parler mais pas pour des liaisons utilisant le protocole
en boucle arbitrée "FC-AL". De plus amples informations sur le SAN figure en Annexe 4.
I.1.5.2 Baies de stockage
Que les besoins en capacité de stockage soient de quelques Go ou de plusieurs To la gamme
IBM TotalStorage propose un large choix de solutions intégrables à l’infrastructure existante.
La stratégie d’IBM dans le domaine du stockage est d’unifier et de simplifier la gestion des
données dans l’entreprise. Les solutions globales et intégrées de stockage sont signe d’une
croissance maîtrisée, d’un investissement pérenne, et d’un avenir préparé.
Avec des systèmes bandes ou disques, IBM TotalStorage est une gamme complète de produits
pour des solutions de stockage sur mesure, de l’attachement direct aux serveurs et aux
technologies les plus avancées de stockage en réseau. Voici un tableau composé de certains
produits de la gamme.
CRESTA Guillaume
Page 30
Produits
DS 8100/8300 & ESS
Système d’entreprise, prêt pour les SAN, haute disponibilité,
performance et adaptation à la charge, connexion à de multiples
serveurs hétérogènes. Il comporte les services de copie pour une
sauvegarde rapide et une reprise après sinistre.
DS6800
Système pour l’entreprise sous un format réduit, adaptable,
modulaire, design haute disponibilité, utile pour rattachement aux
systèmes ouverts et sites centraux.
DS4500
&
DS4400 Système disques SAN pour serveurs UNIX et intel pour une haute
Storage Server
performance, 2 GB fibre channel, continuité des opérations,
fonction Remote Copy.
DS4300 Storage Server
Quatre ports 2 Gb Fibre Channel → basculement multivoies pour
cluster serveurs UNIX et Intel directement attachés, consolidation
de stockage en SAN, NAS et attachements directs, support de
windows, AIX, Sun Solaris, HP – UX, Novell NetWare, Linux.
DS4100 Storage Server
Stockage externe RAID souple et économique pour groupe de
travail et services, attachement Fibre Channel host avec unité
disques Fibre Channel.
SAN Integration Server
Solution intégrée d’infrastructure SAN, Fibre Channel, adaptable
en charge.
Les familles DS8000 et ESS sont des solutions SAN ultra performantes de consolidation du
stockage. Leurs grandes capacités (420 Go à 192 To), la haute disponibilité et la possibilité de
connexions hétérogènes garantissent leur pérennité dans un environnement grand système et
systèmes ouverts. Ces systèmes disposent de fonctions avancées de copie : « Flash Copy »
minimise le temps de sauvegarde et « Peer to Peer Remote Copy » permet une reprise
d’activité immédiate dans le cas de sinistre primaire. Ce sont ausssi des solutions
incontournables pour les environnements System z avec des connexions FICON 2 Gbps et des
fonctions avancées. La technologie et les fonctionnalités avancées de stockage de ses
solutions sont au service des grandes et moyennes entreprises et proposent une alternative
séduisante pour résoudre les problèmes de stockage dans un environnement « à la demande ».
L’ESS est une excellente solution pour des capacités moyenne (jusqu’à 4.6 To) qui requiert
haute disponibilité et performance, conçu pour satisfaire les besoins haute disponibilité des
CRESTA Guillaume
Page 31
sites centraux et environnements ouverts. L’ESS Modèle 750 supporte la plupart des fonctions
offertes sur l’ESS Modèle 800 avec les mêmes éventails très larges de systèmes d’exploitation
supportés. La partie hardware des unités de stockage se situe en Annexe 1 et 2.
Les EXP et SSA ont été conçus pour un stockage en connexion directe sur les serveurs. Le
2104 EXP Plus 320 est une unité de coût réduit pour la connexion directe en grappe en Ultra
320 SCSI sur p5 et System p Unix. Cette unité est idéale pour les entreprises, telles que les
fournisseurs d’accès ou de services Internet, à la recherche de stockage performant dans un
espace réduit. Flexibilité, capacités d’évolution (jusqu’à 2 To) et prix très attractif
caractérisent cette solution de stockage directe en environnement Unix. Le SSA 7133
constitue la solution de stockage direct sur serveurs Unix et NT. Dépassant les limites de la
technologie SCSI, l’architecture série SSA offre des niveaux de performances exceptionnelles
en accès aux données. Optimisation du débit (160 Mo/s sur une boucle SSA), forte capacité
d’évolution (jusqu’à 14 To), facilité de gestion, forte disponibilité des données (chemins
d’accès redondants) caractérisent cette solution.
La famille DS4000 (ex-FaStT) est une gamme d’unités de stockage pour le SAN, une famille
d’unités souples et performantes pour construire une infrastructure SAN. Les solutions
DS4100, 4300, 4400, 4500 répondent aux besoins des environnements ouverts Intel et UNIX.
Haute disponibilité, performance, souplesse (Fibre Channel), facilité d’administration, et
capacité d’évolution (108 Go à 56 To) font de cette gamme une excellente solution comme
base d’une infrastructure SAN.
DS300 et DS400 ont été introduits pour fournir des solutions économiques de stockage à la
famille des serveurs System X. Ils se connectent en direct ou sur le réseau, en étant
modulaires, faciles à installer. Ils représentent véritablement un nouveau prix d’entrée plus
bas pour un stockage adaptable et souple, idéal pour le déploiement des serveurs x336, x346,
et BladeCenter.
Les serveurs de stockage NAS sont utilisés pour le stockage intégré à un réseau IP, basé sur
un système ouvert. Les produits IBM NAS augmentent la souplesse d’une solution de
stockage en réseau IP. Ils supportent plusieurs protocoles sur IP : CIFS (Windows), NFS
(Unix), http, FTP Apple Talk et Netware. Ces unités NAS 200 et 300, optimisées pour le
CRESTA Guillaume
Page 32
partage de fichiers, sont hautement disponibles, fiables (composants redondants) et évolutives
(108 Go à 6,6 To) et constituent des systèmes de stockage aussi faciles à installer aujourd’hui
que capables d’évoluer demain.
La mise en réseau de serveurs et d’unités de stockage hétérogènes par le biais de connexion
LAN/IP ou Fibre Channel permet de répondre aux impératifs de performance, connectivité,
disponibilité, fiabilité et de distance, en apportant les avantages de la consolidation :
mutualisation d’un espace de stockage commun entre serveurs hétérogènes, administration
homogène centralisée, indépendance des choix et des évolutions serveurs/stockage, adaptation
à la charge, souplesse et rapidité d’adaptation du stockage aux situations nouvelles,
amélioration des procédures de sauvegarde et possibilité de partager des données.
IBM TotalStorage permet de disposer du choix entre les différentes technologies de stockage
en réseau SAN et iSCSI (SCSI over IP). La nouvelle technologie iSCSI permet d’obtenir des
performances voisines du SAN, avec les avantages d’économie et de simplicité du NAS en
appliquant le protocole SCSI d’accès aux données sur le réseau IP. Une solution NAS
constitue une alternative économique par l’utilisation d’une infrastructure LAN (plus
répandue) et du réseau IP. Mais les solutions NAS et SAN peuvent aussi se compléter par
l’utilisation de passerelles entre les réseaux LAN et SAN (gateway NAS).
Figure 8 – Différents types de stockage
CRESTA Guillaume
Page 33
I.1.5.3 IBM System anciennement appelé e-server
IBM est de nos jours le leader en terme de serveurs et dispose d’une palette importante :
System x, System p, Open Power, System i et System z.
System x
Les modèles System x utilisent des processeurs Intel. Le modèle e326 basé sur le processeur
Opteron d’AMD, est composé de 2 voies, supporte Windows ou Linux, et on peut le monter
en rack x 2 unités rack avec 2 emplacements PCI x 2 baies disque. IBM eServer cluster 1350
est un cluster de serveurs System x : X336, x346, e326. C’est un ensemble pré testé. Les
System x sont des serveurs économiques au standard du marché, de haute performance format
réduit pour de nombreuses options grâce au Calibrated Vectored Cooling. Ces serveurs sont
optimisés pour un déploiement rapide et sont conçus pour évoluer avec les besoins (jusqu’à
32 voies). Les X-architecture et Xtended Design Architecture apportent flexibilité, fiabilité et
sécurité pour les serveurs à base d’Intel destinés aux applications critiques de l’entreprise.
IBM étend les possibilités des serveurs à base de processeurs Intel. Avec le serveur x445,
IBM combine ce processeur, le plus puissant d’Intel, avec un nouveau chipset qui intègre la
technologie Enterprise X-Architecture et les technologies cuivre et silicium-sur-isolant
d’IBM. Le système délivre une puissance évolutive, grâce à l’intégration de concepts dérivés
des sites centraux. Le châssis du x445 peut accueillir jusqu’à 32 processeurs et offre une
adaptation à la charge inégalée. Il permet également de consolider un grand nombre de
serveurs d’application, de messagerie ou d’impression et de réduire leur coût total de
possession. Le chipset Enterprise X-Architecture permet de réduire les coûts opérationnels et
fournit un avantage en terme de délais de mise sur le marché précédemment inconnu dans le
domaine des serveurs à base d’Intel. A l’intérieur des partitions physiques, VMware peut
permettre un partitionnement virtuel pour des serveurs logiques. Le fait qu’on dispose d’un 64
bits représente un point d’inflexion dans l’évolution des serveurs Intel. Le marché adopte les
extensions 64 bits – EM64T – disponibles dans la majorité des serveurs System x, du x206 au
x346. Pour compléter l’effort d’innovation, IBM a introduit Xtended Design Architecture,
articulé autour de la technologie Calibrated Vector Cooling. Cette nouvelle technologie de
CRESTA Guillaume
Page 34
refroidissement permet de rassembler plus de fonctionnalités et d’options dans un même
boîtier sans risque de surchauffe. Le résultat est une offre de base plus riche en fonctionnalités
que le standard du marché, par exemple en terme d’emplacements PCI, mémoire et fonctions
câblées sur la carte mère.
Figure 9 – Photo d’un System x
Blade Center
L’architecture eServer BladeCenter facilite les transformations qui s’opèrent actuellement
dans l’industrie et qui banalisent les fonctions des serveurs, et tend à offrir une puissance
modulaire sans limite et une disponibilité plus forte, tout en réduisant coûts et complexité. Le
concept du BladeCenter permet de densifier les fermes des serveurs, en réduisant la
complexité de gestion et en renforçant l’intégration de l’ensemble.
CRESTA Guillaume
Page 35
Figure 10 – Photo d’un Blade Center
System p
Avec la génération de systèmes POWER 4, IBM avait introduit DLPAR, permettant de
partitionner dynamiquement un système en plusieurs serveurs logiques. Il devenait possible
d’allouer librement à ces serveurs logiques des processeurs, des zones mémoires, des
adaptateurs et un système d’exploitation AIX ou Linux.
Avec la nouvelle génération de systèmes POWER5, IBM innove de façon plus significative
encore en découplant totalement les systèmes d’exploitation et leur application des ressources
matériel : aller plus loin que la génération précédente consistait à éliminer le besoin d’allouer
des ressources I/O physiques et de dédier un nombre entier de processeurs aux partitions.
C’est ce qui est possible avec les systèmes POWER5 avec les technologies de IBM Advanced
POWER Virtualization qui introduit des avancées significatives.
Le micro partitionnement permet de créer de multiples partitions virtuelles cloisonnées en
UNIX, AIX, Linux et i5/OS. Ces partitions peuvent utiliser des fractions de processeur (avec
une granularité de 1/10ème de processeur) et des blocs de 16 Mo de mémoire. Jusqu’à 160
partitions peuvent être créées sur le 16 voies p5 570 ! Les capacités dépassent largement les
besoins de beaucoup d’applications et le micro partitionnement permet de leur allouer la juste
quantité des ressources qui leur sont nécessaires sans déployer des serveurs coûteux
faiblement utilisés. De plus, les différents serveurs logiques ont la capacité de rendre
disponible des ressources (CPU, mémoire) qui ne seraient pas utilisées temporairement.
L’hyperviseur gérant les différents serveurs logique pourra réaffecter ces ressources aux
CRESTA Guillaume
Page 36
partitions qui en ont besoin. Ce mécanisme a pour effet d’augmenter le taux d’utilisation des
ressources processeur et mémoire et d’améliorer considérablement la flexibilité du système.
Et pour alimenter ces partitions et micro partitions en toute flexibilité, l’allocation physique
d’adaptateurs peut être remplacée par une virtualisation complète des I/O : tout ou partie des
adaptateurs peuvent être regroupés dans un ou plusieurs serveurs Virtual I/O, constitués d’une
ou plusieurs partitions dédiées. Les autres partitions applicatives pourront alors exécuter leur
I/O par le biais de ces virtual I/O. Le ou les serveurs Virtual I/O assureront également les
liaisons entre partitions et tous les besoins de réseau Ethernet ou stockage à grande vitesse au
travers du bus interne de la machine. L’utilisation du serveur Virtual I/O non seulement offre
une flexibilité exceptionnelle dans l’allocation des I/O mais permet aussi le partage des
adaptateurs physiques de la machine.
Le partitionnement permet de segmenter les ressources systèmes en de multiples serveurs
indépendants, supportant chacun leur propre système d’exploitation. Ce concept, bien connu
chez IBM, est une fonction essentielle du grand système (System z) et reste inégalé sur le
marché.
Avec les systèmes POWER 4 et POWER 5, les investissements en infrastructure ne sont plus
dictés par des spécificités applicatives mais deviennent « on demand ».
Le micro partitionnement entrées/sorties virtuelles colle parfaitement aux besoins actuels. Les
charges machines difficilement prévisibles à long terme, les croissances rapides de certaines
activités, tout cela milite pour des systèmes dont le périmètre peut être rapidement et
facilement redéfini. Ils doivent à tout moment pouvoir héberger des serveurs de production,
des serveurs de développement et d’intégration et d’autres serveurs logiques avec la
possibilité de modifier ou rééquilibrer les ressources dynamiquement.
Les applications ne voient qu’un pool de ressources virtualisées. Si l’on veut augmenter la
capacité du système de production, il suffit de rééquilibrer les ressources en ajoutant une
ressource non critique à ce serveur logique.
L’investissement matériel n’est plus dicté par les applications et les serveurs p5 peuvent être
installés avec l’assurance qu’ils pourront être reconfigurés pour s’adapter à des charges
nouvelles. C’est là que se situe la principale économie au niveau du coût de possession.
Tous les serveurs System p utilisent le processeur POWER, véhicule majeur du leadership
technologique d’IBM. Power affiche une consommation électrique relativement réduite pour
d’excellentes performances, ce qui signifie moins de chaleur et de contraintes et donc une
CRESTA Guillaume
Page 37
meilleure fiabilité. Pour une performance donnée, les p5 consomment moins d’énergie, dans
un encombrement réduit et nécessitent moins d’unités de ventilation.
Avec la dernière génération POWER 5, IBM introduit le mécanisme de « simultaneous multithreading » (SMT) ou traitement de multiples threads. Ce mécanisme tire partie de
l’architecture super scalaire de POWER pour augmenter la capacité de traitement de ce
processeur. SMT est la capacité d’un processeur à envoyer à ses unités de traitement les
instructions de plusieurs codes programme simultanément. POWER 5 supporte jusqu’à deux
threads en parallèle.
Les System p et p5 apportent un nouveau sens au mot « disponibilité » : ils introduisent « le
concept de l’opérationnel 24h/24, 7j/7 » issu du monde des grands systèmes. La plupart des
constructeurs cherchent encore des solutions pour la simple reprise après incident. Le concept
de « fonctionnement en continu » fait partie du projet IBM informatique autonome. L’objectif
est de contrôler le système en marche, détecter les sous-systèmes en échec et prendre les
mesures préventives. Les System p sont les seuls systèmes à être équipés de plus de 5000
points de contrôles. Une intelligence système supplémentaire capture les premières données
générées par une anomalie, prend les mesures appropriées pour assurer la continuité du
service, trace les événements et identifie précisément la source du problème en vue de la
maintenance.
HACMP permet à un groupe de serveurs (nœuds) System p et p5 de coopérer pour offrir une
disponibilité plus forte et/ou une puissance transactionnelle consolidée. Le produit utilise une
redondance de tous les éléments critiques pour garantir une reprise automatique dans tous les
cas de panne de l’un des composants matériel et logiciel de la machine. Une configuration
HACMP type comprend deux machines partageant physiquement deux grappes de disques en
miroir, des réseaux Ethernet doublés, une ligne de veille et le logiciel HACMP installé sur
chaque machine au-dessus d’AIX. Les machines peuvent être des System p de type différent.
La grappe de systèmes fédérés dans un seul cluster peut s’étendre à 32 systèmes. Dans le cas
le plus simple de fonctionnement, avec deux nœuds, l’une des machines assure la production,
la machine de veille reprend automatiquement les opération sans intervention manuelle,
s’alloue les grappes disques, reprend les transactions en cours et restaure le service applicatif
vis-à-vis des utilisateurs. HACMP supporte aussi des configurations plus avancées dites en
CRESTA Guillaume
Page 38
cascade, avec plus de deux systèmes, où chaque machine supporte une charge applicative : si
l’un des systèmes subit une panne, un autre reprend sa charge de travail. HACMP peut
fonctionner soit en mode basculement d’une machine sur une autre, soit en mode partage de
disques avec contrôle d’accès aux bases de données par verrouillage d’enregistrement.
Figure 11 – Photo de la famille System p
Open Power
L’Open Power est un serveur puissant, solide mais économique pour Linux. Construits sur
une plateforme inspirée des grands systèmes, dérivés des lignes de produit p5 et i5 et
optimisés pour l’environnement Linux, les systèmes Open Power satisfont les besoins de
clients cherchant performance, fiabilité, haute disponibilité et puissance de calcul à un prix
abordable pour Linux. Ces serveurs power5 64 bits sont conçus pour des architectures Linux
basées sur des standards et simplifient les infrastructures en supportant les fonctions avancées
de virtualisation.
CRESTA Guillaume
Page 39
Figure 12 – Photo de l’Open Power 750
System i
Un ensemble complet de modèles à base de la nouvelle génération de processeurs POWER5 a
été introduit en 2004 sous le nouveau nom de IBM eServer i5. Power 5 délivre une
performance 2 à 3 fois supérieure à la génération précédente Power4. Cette génération de
système renforce les points communs avec la famille Unix P5. Des outils de développement
commun et le partage des technologies entre les deux familles permettent de rendre la famille
i5 plus compétitive encore sans changer les forces fondamentales de la plateforme. Les
serveurs i5 offrent un gain en prix/performance de 40% en moyenne par rapport à la
génération System i précédente. La gamme eServer i5 supporte les technologies et services de
IBM
Virtualization
Engine
en
offrant
aux
utilisateurs
les
moyens
d’améliorer
considérablement le taux d’utilisation des machines. Virtualization Engine inclut des services
systèmes tels que IBM Director Multiplatform, pour contrôler et gérer les ressources entre
systèmes hétérogènes. VE inclut aussi une implémentation du partitionnement logique à
l’image de grands systèmes, permettant un équilibrage des performances entre plusieurs
charges de travail dans un système unique, ce qui réduit les coûts d’exploitation. En parallèle
avec l’arrivée de la gamme i5, le nouveau système d’exploitation i5/OS V5R3 s’inscrit dans la
continuité de l’OS/400. i5/OS renforce les qualités d’intégration des générations précédentes
et est conçu pour faciliter le travail des éditeurs de logiciel. IBM intègre WebSphere Express
avec chaque licence i5/OS, augmentant ainsi les qualités des i5 en tant que serveur
d’application. Le support récemment annoncé d’AIX en parallèle avec i5/OS en plus de Linux
a ouvert de nouvelles voies de développement pour la gamme i5 dans le domaine de la
consolidation de serveurs. Pour faciliter cette opportunité, des changements majeurs ont été
introduits dans le modèle de tarification des systèmes i5 570 et i5 520. Ces supports procurent
aux clients une exceptionnelle flexibilité pour acheter la capacité dont ils ont besoin et ces
CRESTA Guillaume
Page 40
nouvelles options constituent véritablement une percée dans le domaine de la tarification à la
demande et une évolution vers de nouveaux modèles économiques. Cette tarification flexible
répond aux demandes de nombreux clients dans le cadre de consolidation en leur permettant
de choisir librement les systèmes d’exploitation adaptés à l’évolution de leur infrastructure.
Le partitionnement logique dynamique (DLPAR) de i5/OS V5R3 améliore la tolérance aux
pannes et réduit les coûts de gestion des partitions : la partition primaire des versions
précédentes de LPAR sur System i est remplacée par une console de gestion du matériel
(HMC).
Figure 13 – Illustration d’un partitionnement logique
CRESTA Guillaume
Page 41
Figure 14 – Protection LPAR dans un environnement IBM Power 5
Figure 15 – Photo de la famille des System i
System z
Etre un leader technologique c’est plus que simplement offrir de la technologie pour la
technologie. C’est également fournir des solutions, satisfaire les besoins de clients en
CRESTA Guillaume
Page 42
constante évolution, et leur permettre de résoudre leurs défis. C’est ce que tente de réaliser le
System z depuis 40 ans. Le System z a construit sa réputation autour d’un ensemble de
valeurs telles que l’intégration, l’automatisation, la virtualisation, et la qualité de services.
Chacune de ces valeurs peut être directement reliée aux besoins et aux challenges des
utilisateurs. Le z890 est la dernière génération de système taillé pour les entreprises moyennes
tout en offrant la technologie du z990, un potentiel de croissance très granulaire et une
importante souplesse des configurations. Le System z offre un large choix de modèles avec
différents niveaux de capacité sans trop de limite de puissance. Le « grand système », à savoir
le site central, possède de nombreuses caractéristiques telles que la capacité à traiter de grands
volumes de transactions, l’évolutivité et la croissance sans interruption du système, une
disponibilité continue (environ 99,999%), un concept de sécurité « globale » par
partitionnement logique, la virtualisation des ressources, un équilibrage dynamique de la
charge de travail, de multiples serveurs Linux virtuels en un seul système, et une préservation
des investissements à long terme « mainframe Charter ». De nouvelles fonctionnalités sont
présentes ainsi qu’une performance innovante pour satisfaire les besoins d’une activité à la
demande. Le leadership en innovation travaille pour étendre l’utilisation des System z et
supporter un nombre croissant de solutions intégrées et souples pour une activité « à la
demande ». Les System z restent la référence de la plateforme souple, productive et adaptable
pour des environnements complexes et intégrés, supportant de multiples applications critiques
tout en augmentant les fonctions automatiques et d’auto-gestion par le biais de simplification
des procédures utilisateurs et des tâches d’administration. Les objectifs sont d’améliorer la
valeur ajoutée et de réduire le coût de la transaction pour les solutions System z de façon
attractive, claire et cohérente, d’étendre les caractéristiques « on demand » des serveurs
System z, en particulier les forces dans un environnement de tarification à l’usage et
d’augmenter les moyens de comptabiliser les ressources et leur utilisation dans un
environnement « on-demand ». Le service des System z tente également de développer un
portefeuille solide d’applications et de services, de fournir les compétences et l’expertise pour
assister les clients dans la conception, le design, et le développement de solutions « à la
demande » dont le pilier central est un site central System z. Ces principes fixent les priorités
des investissements pour le service des System z et démontrent l’engagement d’IBM à fournir
plus de valeur pour ses clients à l’offre System z. IBM a introduit le concept de capacité
temporaire - on/off (figure 28) - sur les moteurs IFL du z990 pour assister les clients qui ont
CRESTA Guillaume
Page 43
besoin d’une capacité additionnelle pour faire face à un pic de demande ou pour des plans de
reprise par exemple.
Figure 16 – Schématisation du concept de capacité temporaire.
Figure 17 – Différentes applications intégrables sur les System z
CRESTA Guillaume
Page 44
Figure 18 – Photo du Z9.
I.2
Présentation de la plateforme High Availability Center of
Competency (HACoC)
I.2.1
Objectifs de la plateforme
Une équipe a été mise en place dans le but d’être plus efficace sur les solutions de haute
disponibilité proposées aux clients et de pourvoir des recommandations régulières afin
d’améliorer les infrastructures existantes. Le projet de « Disaster / Recovery » est devenue
une nécessité pour les clients, un besoin pour les banques qui, avec les nouvelles lois, doivent
sauvegarder des données à distance de leur site principal. L’équipe HACoC est un lien
priviliégié avec les clients car elle permet de les aider dans leurs attentes en haute
disponibilité et de transmettre des retours aux laboratoires d’IBM afin d’identifier les lacunes
des produits et les opportunités de solutions. Les engagements HACoC avec les clients sont
d’analyser les implémentations courantes et proposer des déploiements. L’engagement
HACoC repose sur cinq points : l’analyse et la collecte de toutes les informations sur des
projets de haute disponibilité, le rétablissement après la chute du site de Montpellier à partir
de Poughkeepsie, la conversion des engagements des clients de Montpellier en garantie pour
les clients, l’éducation et les ateliers sur les solutions et les engagements des clients.
Un des buts de cette plateforme mise en place à Montpellier et sur laquelle je travaille, est de
prouver la valeur des solutions clients d’IBM Business Continuity, démontrer les possibilités
des solutions "clé en main" aux clients. L’autre est de produire un outil pour les clients ainsi
que pour les équipes du service « Education » d’IBM fournissant les meilleures prestations.
CRESTA Guillaume
Page 45
Afin d’atteindre ses buts, le projet propose une solution intercontinentale intégrant la haute
disponibilité afin de rétablir, sur un site secondaire, le désastre subi sur un site de production.
Afin de convaincre le client, l’équipe du « High Availability Center of Competency » met en
place des démontrations de « Disaster / recovery » sur des longues distances. Montpellier et
Poughkeepsie sont distants d’environ 7000 kilomètres. On simule l’arrêt du site de
Montpellier et la reprise de l’activité sur le site de Poughkeepsie. Le but est de connecter un
utilisateur sur une application sur le site de production, de simuler un désastre sur ce site (rôle
du site de Montpellier), d’établir un processus de failover de failback (rôle du site de
Poughkeepsie) et ensuite d’évaluer l’uniformité des données et les erreurs engendrées.
Ce projet est à ma connaissance unique dans le monde informatique et fait l’objet de diverses
publications techniques dans le monde IBM et extérieur. Il est présenté à différents clients ou
partenaires dans le but de leur proposer une solution clé en main basée sur des produits IBM.
I.2.2
Technologies utilisées
A mon arrivée sur la plateforme, celle-ci contenait deux System p, deux baies de stockage, à
savoir un DS8000 et un DS6000 sur Montpellier, des switchs et des routeurs McData, et un
simulateur de distance. Lors des premiers mois, j’ai pu assister à la mise en place et à la
configuration de la baie de stockage à Poughkeepsie. Ce concept développé dans le centre de
Benchmark PSSC d’IBM Montpellier, implémente une solution de « Disaster / Recovery »
située sur deux sites dans un environnement de DS6/8000 et de System p et x. Les principaux
composants de l’architecture sont des serveurs System p IBM avec AIX 5.5, des unités de
stockage IBM DS6000 et DS8000, des switchs SAN McData 2026-224, et des routeurs iFCP
McData 2027-R16. Cette plateforme est représentée sur la figure située page suivante. Les
switchs sont utilisés afin de connecter les System p (puis x), et les routeurs afin de faire la
liaison entre les deux sites. La présentation hardware des switchs et des routeurs figure en
annexe A.3. Le site de Montpellier est considéré comme site de production où sont
rassemblées toutes les données et la sauvegarde s’effectue sur la baie de stockage sur le site
secondaire à Poughkeepsie par un système de copie appelé « Global Mirror » que
j’approfondirai dans la partie expliquant l’intégration du Linux. Le site primaire supporte une
application Oracle, un système d’exploitation AIX sur un System p.
CRESTA Guillaume
CRESTA Guillaume
Figure 19 - Plateforme HACoC à mon arrivée
Page 46
I.2.3
Page 47
Future plateforme
La plateforme à venir est donc d’intégrer à l’actuelle, dans un premier temps, des
System x avec un système d’exploitation différent. On a tout d’abord pensé à intégrer un
Linux mais la possibilité d’intégrer un Windows par la suite n’est pas à exclure. Cette
conception est basée sur la diversité des offres IBM et également sur la diversité des
entreprises touchées. Afin de toucher un maximum d’entreprise, le projet HACoC est donc
diversifié et montre la capacité d’IBM à s’adapter. Ce Linux doit dans un premier temps
pouvoir effectuer les copies entre les deux sites. Afin de ne pas encombrer la plateforme et ne
connaissant pas la performance de cette solution, les tests sont effectués à Montpellier entre
un DS8000 et un DS6000 séparés par un simulateur de distance (Spirent) qui va simuler la
distance qu’il y a entre les deux sites en réglant la latence sur le spirent.
Suivant les performances du système d’exploitation Linux, il est prévu par la suite d’y
intégrer une application Oracle dessus tout en laissant la base de donnée sur le System p. Par
cette diversité de système d’exploitation et de serveurs ainsi que ce concept exceptionnel,
IBM se place en tête pour les solutions de haute disponibilité face aux clients.
Dans l’avenir, une solution sur trois sites est prévue. Elle utilisera la notion de Metro Global
Mirror qui permet d’établir une réplication synchrone entre le site primaire et le site
secondaire distant d’une centaine de kilomètre par le biais du Metro Mirror, ainsi qu’une
réplication asynchrone entre le site secondaire et le site tertiaire situé à Poughkeepsie (7000
kilomètres) grâce au Global Mirror. Cette solution est représentée ci-après.
CRESTA Guillaume
CRESTA Guillaume
Figure 20 - Plateforme à venir
Page 48
I.3
Page 49
Cahier des charges
Dès mon arrivée, nous avons établi un planning prévisionnel. Trois phases devaient
être prises en compte durant le stage : la phase d’adaptation, l’intégration dans un projet en
cours et le développement du serveur. La phase d’adaptation comprenait un travail sur la mise
en place d’infrastructure de benchmarks afin de faciliter l’apprentissage et l’appréhension de
l’environnement IBM. La phase d’intégration permettait de comprendre le fonctionnement et
la mise en place d’une plateforme de « Disaster/Recovery » entre la France et les Etats-Unis
ainsi que de commencer à travailler en équipe. Le troisième volet, à savoir, le développement
d’un nouveau serveur, Linux, et son intégration sur la plateforme, faisait appel à ma capacité
d’autonomie. Les deux premières phases devaient durer un mois chacune et la dernière
s’étaler sur les quatre mois restants.
Les différents axes de développement ont été déterminés par :
-
la participation au câblage avec l’équipe réseau,
-
la participation à l’installation de baies de stockage avec l’équipe infrastructure,
-
la participation à la création des volumes, des volumes groupes avec l’équipe
infrastructure,
-
la participation à la mise en place de système d’exploitation avec l’équipe setup,
-
la recherche de documents expliquant le SAN, les services de copies,
-
la recherche de documents présentant les produits IBM,
-
la lecture de documents IBM : redbooks, SSPD,
-
l’assistance à différentes présentations (produits, technologies),
-
les échanges avec différentes personnes du service System x,
-
les explications sur les différents produits de stockage de la part des personnes du
service éducation,
-
les différents entretiens avec les personnes de mon service et leurs conseils face à
certaines situations.
CRESTA Guillaume
Page 50
De plus, le développement du serveur Linux devait être en conformité avec la matrice de
compatibilité de la baie de stockage. Les tests de performance du global mirror devaient être
optimisés, et les différents paramètres être réglés au mieux pour obtenir des résultats
favorables. Enfin, les documents mis à la disposition des IBMers et plus particulièrement de
l’équipe avec laquelle je travaillais devaient être clairs, précis, et révéler les problèmes
rencontrés ainsi que les moyens pour les résoudre. Pour finir, j’ai eu l’opportunité de
participer à un événement IBM afin d’observer la facette client et briefing d’IBM.
CRESTA Guillaume
II
Page 51
REALISATION DU PROJET
II.1
Intégration Linux
II.1.1
Configuration du SAN
Tout d’abord, il faut regarder la matrice de compatibilité afin de vérifier que la version du
Linux installé est en concordance avec l’unité de stockage. Pour cela, il faut connaître la
version du Linux et du noyau :
[root@halinux Desktop]# more /etc/redhat-release
Red Hat Enterprise Linux AS release 4 (Nahant Update 3)
[root@halinux Desktop]# uname -a
Linux halinux 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:54:53 EST 2006 i686 i686
i386 GNU/Linux
Pour l’intégration du serveur Linux sur la plateforme, une connexion sur le SAN existant ainsi
qu’une opération de zoning ont été nécessaire. Dans le but d’effectuer le zoning, il faut avoir
les WWPN des cartes fibres du System x :
[root@halinux Desktop]# cd /proc/scsi/qla2xxx/
[root@halinux qla2xxx]# ls
1
[root@halinux qla2xxx]# cat 1
QLogic PCI to Fibre Channel Host Adapter for QLA2310:
Firmware version 3.03.18 IPX, Driver version 8.01.02-d4
ISP: ISP2300, Serial# D76762
Request Queue = 0x1bc0000, Response Queue = 0x37a00000
Request Queue count = 2048, Response Queue count = 512
Total number of active commands = 0
Total number of interrupts = 2781
Device queue depth = 0x20
Number of free request entries = 784
Number of mailbox timeouts = 0
Number of ISP aborts = 0
Number of loop resyncs = 0
Number of retries for empty slots = 0
Number of reqs in pending_q= 0, retry_q= 0, done_q= 0, scsi_retry_q= 0
Host adapter:loop state = <READY>, flags = 0x1a03
Dpc flags = 0x4000000
MBX flags = 0x0
Link down Timeout = 000
Port down retry = 030
Login retry count = 030
Commands retried with dropped frame(s) = 0
CRESTA Guillaume
Page 52
Product ID = 4953 5020 2020 0001
SCSI Device Information:
scsi-qla0-adapter-node=200000e08b05babf;
scsi-qla0-adapter-port=210000e08b05babf;
scsi-qla0-target-0=50050763031080b7;
scsi-qla0-target-1=50050763031bc0b7;
FC Port Information:
scsi-qla0-port-0=5005076303ffc0b7:50050763031080b7:740d13:81;
scsi-qla0-port-1=5005076303ffc0b7:50050763031bc0b7:740f13:82;
SCSI LUN Information:
(Id:Lun) * - indicates lun is not registered with the OS.
( 0: 0): Total reqs 1674, Pending reqs 0, flags 0x0, 0:0:81 00
( 1: 0): Total reqs 1587, Pending reqs 0, flags 0x0, 0:0:82 00
[root@halinux qla2xxx]#
Afin d’administrer et de monitorer les switchs McData, une application web est disponible.
Grâce à EFCM Basic, on peut configurer les switchs. Pour cela on y accède par le menu
Configure > Zoning, et apparaît la page ci-dessous.
Dans la première colonne, tous les nœuds sont listés. Il faut alors inscrire le nom de la zone
dans la deuxième colonne.
Figure 21 – Zoning, nom de la zone
CRESTA Guillaume
Page 53
Il faut alors ajouter les WWPN en utilisant le bouton >.
Figure 22 – Zoning, sélection des WWPN
Voilà le résultat avec dans la zone S1_LINUX, les WWPN de la fibre optique et du DS8000.
Une fois cela effectué, il faut ajouter cette zone à la zone set. Pour cela on utilise le bouton >.
Figure 23 – Zoning, clôture de la zone
CRESTA Guillaume
Page 54
Maintenant la zone apparaît dans la colonne « Zone set ». Il faut alors sauvegarder la
modification (Update) puis l’appliquer (Activate).
Figure 24 – Zoning, enregistrement et application
On peut éditer les zones créées en utilisant les boutons <, et refaire les étapes citées
précédemment.
On peut également configurer le port qu’on utilise. Dans le cas étudié, le System x est
connecté sur le port 0 du Switch, on renseigne alors les champs associés au port 0.
CRESTA Guillaume
Page 55
Figure 25 – Signalisation du port
On peut alors par la suite, accéder à la liste des ports du switch (Product > Port List). En
cliquant sur le port 0, on obtient les informations liées à ce port dont le WWPN et le WWNN.
Figure 26 – Information sur le port interrogé
On peut effectuer le zoning et la configuration de l’unité de stockage dans l’ordre désiré.
CRESTA Guillaume
II.1.2
Page 56
Configuration des disques
Pour la configuration de l’unité de stockage, on peut le faire soit par GUI (interface web) soit
par CLI (lignes de commande). Personnellement, je préfère fonctionner par ligne de
commande. Le fonctionnement est le même que l’on utilise un DS6000 ou un DS8000. Les
extraits ci-dessous sont tirés de la création sur le DS8000.
Pour créer le host sur l’unité de stockage qui va permettre la relation entre le Linux et l’unité
de stockage, il faut spécifier le World Wide Port Name de la carte fibre du System x
(210000E08B05BABF), le type de système d’exploitation qu’on utilise (LinuxRHEL) et les
ports du DS que nous allons utiliser (all : tous ceux qui sont disponibles) :
dscli mkhostconnect -wwname 210000E08B05BABF
-hosttype LinuxRHEL -ioport
all 'HA1Linux' -cfg C:\Progra~1\IBM\dscli\profile\DS8000_HA.profile
Date/Time: 4 ao?t 2006 14:25:30 CEST IBM DSCLI Version: 5.1.600.260 DS:
IBM.2107-7506551
CMUC00012I mkhostconnect: Host connection 0013 successfully created.
Date/Time: 08 04, 2006 14:25:39
Execution time :
12 Seconds.
On peut alors vérifier la configuration que l’on vient d’effectuer :
dscli lshostconnect -l
-cfg
C:\Progra~1\IBM\dscli\profile\DS8000_HA.profile
Date/Time: 25 juillet 2006 18:42:57 CEST IBM DSCLI Version: 5.1.600.260 DS:
IBM.2107-7506551
Name
ID
WWPN
HostType LBS addrDiscovery
Profile
portgrp volgrpID atchtopo ESSIOport
===========================================================================
===========================================================================
===========================================================================
===========================================================================
==============================================================
BSBI_P53
0000 10000000C93EC6FE pSeries
512 reportLUN
IBM pSeries - AIX
1 FC-AL
all
[…]
HA1Linux
0013 210000E08B05BABF LinuxRHEL 512 LUNPolling
Intel - Linux RHEL
0 all
[…]
SVC_SpeederMan_EW
0042 50050768014003EA SVC
512 reportLUN
San Volume Controller
0 V2
all
Date/Time: 07 25, 2006 18:43:06
Execution time :
11 Seconds.
Ensuite, il faut créer les espaces de stockage que l’on appelle Volumes en précisant la capacité
(5 Gb), le nom du volume (Vol1Halinux), et le numéro que celui-ci aura (4700) ainsi que
l’extendpool sur lequel il va se créer (P3). Il faut vérifier que l’extendpool a bien un espace
alloué.
CRESTA Guillaume
Page 57
dscli lsextpool -l
-cfg C:\Progra~1\IBM\dscli\profile\DS8000_HA.profile
IBM.2107-7506551
Name
ID stgtype rankgrp status availstor (2^30B) %allocated
available reserved numvols numranks
===========================================================================
=============================
extpool_ha0
P0 fb
0 below
650
16
650
0
8
1
extpool_ha1
P1 fb
1 below
679
12
679
0
4
1
extpool_ha2
P2 fb
0 below
859
5
859
0
2
1
extpool_ha3
P3 fb
1 below
729
6
729
0
2
1
[…]
Date/Time: 08 04, 2006 14:29:51
Execution time :
17 Seconds.
dscli mkfbvol -extpool P3 -cap 5 -name 'Vol1Halinux' 4700 -cfg
IBM.2107-7506551
CMUC00025I mkfbvol: FB volume 4700 successfully created.
Date/Time: 08 04, 2006 14:30:55
Execution time :
12 Seconds.
Une fois les volumes établis (dans notre cas, on en crée un seul), on les regroupe dans un
volume groupe. Pour cela, il faut préciser le type (scsimap256 dans le cas d’un Linux Red
Hat), les numéros des volumes que regroupe le volume groupe (4700) et le nom du volume
groupe (VolGrpe1HALinux) :
dscli mkvolgrp -type scsimap256 -volume 4700 'Volgrpe1HALinux' -cfg
IBM.2107-7506551
CMUC00030I mkvolgrp: Volume group V4 successfully created.
Date/Time: 08 04, 2006 14:31:53
Execution time :
10 Seconds.
On peut vérifier l’établissement du Volume groupe par la commande :
dscli lsvolgrp -l
-cfg C:\Progra~1\IBM\dscli\profile\DS8000_HA.profile
IBM.2107-7506551
Name
ID Type
========================================
FC_OracleCode
V0 SCSI Mask
HAVG1
V1 SCSI Mask
SVCDEMO_EW
V2 SCSI Mask
MED4PC12
V3 SCSI Map 256
VolGrp1_HALINUX
V4 SCSI Map 256
sdvolume
V5 SCSI Map 256
VGPC2
V6 SCSI Map 256
blue_aix_VG
V7 SCSI Mask
Volumes_for_AIX
V8 SCSI Mask
CRESTA Guillaume
Page 58
Date/Time: 08 04, 2006 14:22:36
Execution time :
12 Seconds.
ainsi que l’établissement du volume et qu’il est bien associé au volume groupe V4:
dscli lsfbvol -l -cfg C:\Progra~1\IBM\dscli\profile\DS8000_HA.profile
Date/Time: 17 mai 2006 18:40:59 CEST IBM DSCLI Version: 5.1.600.260 DS:
IBM.2107-7506551
Name
ID
accstate datastate configstate deviceMTM datatype
extpool sam
captype cap (2^30B) cap (10^9B) cap (blocks) volgrp
===========================================================================
================================================================
03000
0300 Online
Normal
Normal
2107-900 FB 512
P7
Standard
DS
2.0
4194304 V18
[...]
Vol1Halinux
4700 Online
Normal
Normal
2107-900 FB 512
P3
Standard
DS
5.0
10485760 V4
[...]
volAIXLaurent
FB00 Online
Normal
Normal
2107-900 FB 512
P7
Standard
DS
1.0
2097152 Date/Time: 05 17, 2006 18:41:08
Execution time :
12 Seconds.
On doit alors associer le volume groupe créé à l’host établi précédemment, en précisant le
numéro du volume groupe (V4) et celui de l’host (0013) :
dscli chhostconnect -volgrp V4 0013 -cfg
IBM.2107-7506551
CMUC00013I chhostconnect: Host connection 0013 successfully modified.
Date/Time: 08 04, 2006 14:32:51
Execution time :
10 Seconds.
et vérifier que l’opération a bien été effectuée en contrôlant à nouveau la configuration du
host :
dscli lshostconnect -l
-cfg
Date/Time: 25 juillet 2006 18:42:57 CEST IBM DSCLI Version: 5.1.600.260 DS:
IBM.2107-7506551
Name
ID
WWPN
HostType LBS addrDiscovery
Profile
portgrp volgrpID atchtopo ESSIOport
===========================================================================
===========================================================================
===========================================================================
===========================================================================
==============================================================
BSBI_P53
0000 10000000C93EC6FE pSeries
512 reportLUN
IBM pSeries - AIX
1 FC-AL
all
[…]
HA1Linux
0013 210000E08B05BABF LinuxRHEL 512 LUNPolling
Intel - Linux RHEL
0 V4
all
[…]
CRESTA Guillaume
Page 59
SVC_SpeederMan_EW
0042 50050768014003EA SVC
San Volume Controller
0 V2
Date/Time: 07 25, 2006 18:43:06
Execution time :
11 Seconds.
512 reportLUN
all
Après avoir configuré la partie propre au DS6/8000 et le zoning, il faut redémarrer le Linux.
On vérifie alors si les disques sont bien en relation avec le système d’exploitation :
login as: root
Sent username "root"
[email protected]'s password:
Last login: Wed Aug 16 11:04:10 2006 from 10.8.1.1
[root@halinux ~]# fdisk -l
Disk /dev/sda: 36.4 GB, 36401479680 bytes
255 heads, 63 sectors/track, 4425 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot
/dev/sda1
*
/dev/sda2
Start
1
14
End
13
4425
Blocks
104391
35439390
Id
83
8e
System
Linux
Linux LVM
Disk /dev/sdb: 5368 MB, 5368709120 bytes
Disk /dev/sdb doesn't contain a valid partition table
Disk /dev/sdc: 5368 MB, 5368709120 bytes
Disk /dev/sdc doesn't contain a valid partition table
Si la commande fdisk -l ne fonctionne pas, on peut forcer le montage des disques à travers la
carte Fibre Channel par la ligne de commande echo "scsi-qlascan" > /proc/scsi/qla2xxx/1.
Côté DS8000, le system X ne possède qu’une seule carte, et dans le zoning, on a mis deux
liens pour l’unité de stockage. On voit alors le disque en double (/etc/sdb et /etc/sdc cidessus). Puisque sur le System x côté DS6000 on possède 2 cartes, vu qu’on a deux fibres
pour l’unité de stockage, on voit quatre disques comme indiqué ci-dessous (/etc/sdb, /etc/sdc,
/etc/sdd et /etc/sde):
login as: root
Sent username "root"
[email protected]'s password:
Last login: Wed Aug 16 11:05:28 2006 from 10.8.1.1
[root@halinux2 ~]# fdisk -l
Disk /dev/sda: 36.4 GB, 36401479680 bytes
Device Boot
/dev/sda1
*
CRESTA Guillaume
Start
1
End
13
Blocks
104391
Id
83
System
Linux
/dev/sda2
14
Page 60
4425
35439390
8e
Linux LVM
Disk /dev/sdb: 5368 MB, 5368709120 bytes
Disk /dev/sdb doesn't contain a valid partition table
Disk /dev/sdc: 5368 MB, 5368709120 bytes
Disk /dev/sdc doesn't contain a valid partition table
Disk /dev/sdd: 5368 MB, 5368709120 bytes
Disk /dev/sdd doesn't contain a valid partition table
Disk /dev/sde: 5368 MB, 5368709120 bytes
Disk /dev/sde doesn't contain a valid partition table
II.1.3
Installation de sdd outil de multipathing
On installe alors le fichier IBM.sdd-1.6.1.0-3.i686.rhel4.rpm. Il suffit de double cliquer sur le
fichier et il s’installe automatiquement. Ce fichier est la dernière version sdd pour Red Hat 4.
Une fois le fichier installé, il faut alors vérifier son statut :
[root@halinux ~]# sdd status
IBMsdd status:
You have new mail in /var/spool/mail/root
[FAILED]
Si celui-ci a comme statut : FAILED, il suffit de démarrer le service sdd :
[root@halinux ~]# sdd start
Starting IBMsdd driver load:
[ OK ]
Issuing killall sddsrv to trigger respawn...
Starting IBMsdd configuration:
[ OK ]
[root@halinux ~]# sdd status
IBMsdd status:
[ OK ]
000 vpatha ( 252,
0) 75065514700 = 6005076303ffc0b70000000000004700 =
/dev/sdb /dev/sdc
Pour faire du multipathing, sdd crée un vpath qui va prendre en compte les deux disques et
gérer le trafic sur les deux liens. J’ai été confronté à un problème avec le fichier
/etc/lvm/lvm.conf dont l’explication figure dans la partie « Difficultés rencontrées ». Une fois
ce léger problème solutionné, on a pu alors s’assurer que les path étaient créés :
CRESTA Guillaume
Page 61
[root@halinux ~]#cfgvpath query
/dev/sdb ( 8, 16) host=1 ch=0 id=0 lun=0
vid=IBM
pid=2107900
serial=75065514700
lun_id=6005076303ffc0b70000000000004700 ctlr_flag=0 ctlr_nbr=0 df_ctlr=0
/dev/sdc ( 8, 32) host=1 ch=0 id=1 lun=0
vid=IBM
pid=2107900
serial=75065514700
lun_id=6005076303ffc0b70000000000004700 ctlr_flag=0 ctlr_nbr=0 df_ctlr=0
On peut donc vérifier qu’un nouveau disque est présent lors du scan des disques qui
correspond au groupe de tous les path :
[root@halinux ~]# fdisk -l
……………………………
Disk /dev/vpatha: 5368 MB, 5368709120 bytes
Disk /dev/vpatha doesn't contain a valid partition table
Ensuite, on doit créer une partition
[root@halinux ~]# fdisk /dev/vpatha
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF
disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.
Warning: invalid flag 0x0000 of partition table 4 will be corrected by
w(rite)
Command (m for help): n
Command action
e
extended
p
primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-1018, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-1018, default 1018):
Using default value 1018
Command (m for help): t
Selected partition 1
Hex code (type L to list codes): l
0 Empty
boot
1 FAT12
CRESTA Guillaume
1e
Hidden W95 FAT1 75
PC/IX
be
Solaris
24
NEC DOS
Old Minix
bf
Solaris
80
2 XENIX root
(FAT3 XENIX usr
(FAT4 FAT16 <32M
(FAT5 Extended
6 FAT16
7 HPFS/NTFS
/ .
8 AIX
Utility
9 AIX bootable
a OS/2 Boot Manag
b W95 FAT32
c W95 FAT32 (LBA)
e W95 FAT16 (LBA)
f W95 Ext'd (LBA)
10 OPUS
12/16/
11 Hidden FAT12
RISC b
12 Compaq diagnost
14 Hidden FAT16 <3
16 Hidden FAT16
secondary
17 Hidden HPFS/NTF
auto
18 AST SmartSleep
1b Hidden W95 FAT3
1c Hidden W95 FAT3
Hex code (type L to
Changed system type
Page 62
39
Plan 9
81
Minix / old Lin c1
DRDOS/sec
3c
PartitionMagic
82
Linux swap
c4
DRDOS/sec
40
Venix 80286
83
Linux
c6
DRDOS/sec
41
42
4d
PPC PReP Boot
SFS
QNX4.x
84
85
86
OS/2 hidden C: c7
Linux extended da
NTFS volume set db
Syrinx
Non-FS data
CP/M / CTOS
4e
QNX4.x 2nd part 87
NTFS volume set de
Dell
4f
50
51
52
53
54
55
QNX4.x 3rd part
OnTrack DM
OnTrack DM6 Aux
CP/M
OnTrack DM6 Aux
OnTrackDM6
EZ-Drive
8e
93
94
9f
a0
a5
a6
Linux LVM
df
Amoeba
e1
Amoeba BBT
e3
BSD/OS
e4
IBM Thinkpad hi eb
FreeBSD
ee
OpenBSD
ef
BootIt
DOS access
DOS R/O
SpeedStor
BeOS fs
EFI GPT
EFI (FAT-
56
Golden Bow
a7
NeXTSTEP
f0
Linux/PA-
5c
61
63
Priam Edisk
a8
SpeedStor
a9
GNU HURD or Sys ab
Darwin UFS
NetBSD
Darwin boot
f1
f4
f2
SpeedStor
SpeedStor
DOS
64
Novell Netware
BSDI fs
fd
Linux raid
65
70
Novell Netware b8
DiskSecure Mult bb
b7
BSDI swap
fe
Boot Wizard hid ff
LANstep
BBT
list codes): 8e
of partition 1 to 8e (Linux LVM)
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
Avec le nouveau service sdd, on a accès à de nouvelles commandes qui permettent de voir les
LUN, les LSS en relation, les volumes entre autre.
[root@halinux ~]# datapath query essmap
Disk
Path
P Adapter
LUN SN
Type
Vol
Rank
C/A S
Connection
Port RaidMode
--------- - ------------- ----------- ----------------- ----------- ---- -------vpatha
sdb
Host1Channel0 75065514700 IBM 2107900
00
0000
17
Y
R1-B3-H1-ZC 202
RAID5
vpatha
sdc
Host1Channel0 75065514700 IBM 2107900
00
0000
17
Y
R1-B4-H3-ZD 333
RAID5
Size
----
LSS
---
1.0GB
71
1.0GB
71
Paths
2
Active
0
[root@halinux ~]# datapath query adapter
Active Adapters :1
Adpt#
0
Name
Host1Channel0
CRESTA Guillaume
State
NORMAL
Mode
ACTIVE
Select
136
Errors
0
-
Page 63
[root@halinux ~]# datapath query device
Total Devices : 1
DEV#:
0 DEVICE NAME: vpatha TYPE: 2107900 POLICY: Optimized Sequential
SERIAL: 75065514700
===========================================================================
Path#
Adapter/Hard Disk
State
Mode
Select
Errors
0
Host1Channel0/sdb
CLOSE
NORMAL
53
0
1
Host1Channel0/sdc
CLOSE
NORMAL
83
0
Ensuite une série de commande est à exécuter afin de créer les volumes physiques, les
volumes groupes, les volumes logiques, avant de monter le disque sur /halinux1.
[root@halinux ~]# pvcreate /dev/vpatha1
Physical volume "/dev/vpatha1" successfully created
[root@halinux Desktop]# pvscan
PV /dev/sda2
VG VolGroup00
lvm2 [33.78 GB / 64.00 MB free]
PV /dev/vpatha1
VG VGHALINUX1
lvm2 [4.99 GB / 4.00 MB free]
Total: 2 [38.77 GB] / in use: 2 [38.77 GB] / in no VG: 0 [0
]
[root@halinux ~]# vgcreate VGHALINUX1 /dev/vpatha1
Volume group "VGHALINUX1" successfully created
[root@halinux Desktop]# vgscan
Reading all physical volumes. This may take a while...
Found volume group "VolGroup00" using metadata type lvm2
Found volume group "VGHALINUX1" using metadata type lvm2
[root@halinux Desktop]#
--- Volume group --VG Name
System ID
Format
Metadata Areas
Metadata Sequence No
VG Access
VG Status
MAX LV
Cur LV
Open LV
Max PV
Cur PV
Act PV
VG Size
PE Size
Total PE
Alloc PE / Size
Free PE / Size
VG UUID
vgdisplay VGHALINUX1
VGHALINUX1
lvm2
1
2
read/write
resizable
0
1
1
0
1
1
4.99 GB
4.00 MB
1278
1277 / 4.99 GB
1 / 4.00 MB
5P3JKI-ztYt-eQ4p-zzAp-4tVF-jrJW-4ZK7PN
[root@halinux ~]# pvscan
PV /dev/vpatha1
VG VGHALINUX1
lvm2 [4.99 GB / 4.99 GB free]
Total: 1 [4.99 GB] / in use: 1 [4.99 GB] / in no VG: 0 [0
]
CRESTA Guillaume
Page 64
[root@halinux ~]# lvcreate VGHALINUX1 -n
Logical volume "lv_halinux1" created
lv_halinux1 -l 1277
[root@halinux Desktop]# lvscan
ACTIVE
'/dev/VolGroup00/LogVol00' [31.78 GB] inherit
ACTIVE
ACTIVE
'/dev/VGHALINUX1/lv_halinux1' [4.99 GB] inherit
[root@halinux /]# mkdir /halinux1
[root@halinux /]# ls
bin
etc
initrd
boot halinux1 lib
dev
home
lost+found
media
misc
mnt
opt
proc
root
sbin
selinux
srv
sys
tftpboot
tmp
usr
var
[root@halinux /]# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
none on /proc type proc (rw)
none on /sys type sysfs (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
usbfs on /proc/bus/usb type usbfs (rw)
/dev/sda1 on /boot type ext3 (rw)
none on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
[root@halinux ~]# lvscan
ACTIVE
ACTIVE
inactive
[root@halinux ~]# lvchange /dev/VGHALINUX1/lv_halinux1 -a y
[root@halinux ~]# lvscan
ACTIVE
ACTIVE
ACTIVE
[root@halinux ~]# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
none on /proc type proc (rw)
none on /sys type sysfs (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
usbfs on /proc/bus/usb type usbfs (rw)
/dev/sda1 on /boot type ext3 (rw)
none on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
[root@halinux ~]# mkfs.ext3 /dev/VGHALINUX1/lv_halinux1
mke2fs 1.35 (28-Feb-2004)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
654080 inodes, 1307648 blocks
65382 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1342177280
40 block groups
32768 blocks per group, 32768 fragments per group
16352 inodes per group
Superblock backups stored on blocks:
CRESTA Guillaume
Page 65
32768, 98304, 163840, 229376, 294912, 819200, 884736
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
[root@halinux ~]# mount /dev/VGHALINUX1/lv_halinux1 /halinux1/
[root@halinux ~]# cd /halinux1
[root@halinux halinux1]# ll
total 16
drwx------ 2 root root 16384 Aug 18 19:12 lost+found
Une fois cette configuration terminée, et le script de démarrage (cf. « Difficultés
rencontrées ») effectué, le linux est réellement intégré sur la plateforme, et les services de
copie peuvent être testés.
II.2
Global Mirror
Global Mirror est une technologie de sauvegarde de données créée par IBM, qui permet
d’effectuer des sauvegardes très rapides depuis des sites distants géographiquement. Cette
technologie s’appuie sur des principes de Peer to Peer asynchrone.
Le Peer to Peer Remote Copy (PPRC) est un protocole conçu pour copier un volume de
stockage sur une autre unité de stockage sur un site distant. Le PPRC synchrone ordonne à
chaque écriture sur le site primaire d’être exécutée sur le secondaire sans délai. Les I/O ne
sont considérés terminés que lorsque la mise à jour sur les deux sites a été effectuée. Le PPRC
asynchrone arrête les flux sur le site primaire pour les dupliquer sur le secondaire quand les
applications le permettent. Le PPRC peut être utilisé pour permettre une restitution très rapide
suite à une panne sur le site primaire. Sur IBM System z et System z9 qui possèdent deux
unités de contrôle Direct access storage Device (DASD) connectées à travers des connexions
dédiées, le PPRC est le protocole utilisé pour copier un volume DASD d’une unité de contrôle
(primaire) sur un volume DASD sur une autre unité de contrôle (secondaire).
Sur le IBM SAN Volume Controller (SVC), PPRC est utilisé pour copier un volume de
stockage virtualisé sur un autre (ou le même) cluster situé à distance.
CRESTA Guillaume
Page 66
Global Mirror est une technologie IBM qui permet de répliquer des données sur de longues
distances à travers deux sites afin d’assurer la continuité du business et leur récupération en
cas de catastrophe « disaster / recovery ». Il fournit un Recovery Point Objective (RPO) d’un
minimum de 3 à 5 secondes avec une bande passante adéquate entre les deux sites séparés par
de très longues distances sans pour autant affecter les performances des applications présentes
sur le site primaire. Il réplique de manière asynchrone les données et forme ensuite un
« Consistency Group » à intervalles réguliers permettant une restitution propre de
l’application.
Le RPO est le point de synchronisation où l’application redémarrée est en pause. Ce point
peut également être défini comme une mesure du temps qui établit que le travail peut être
perdu en cas de problème non prévu sur le site primaire. En réduisant les besoins de RPO, on
augmente la synchronisation de la réplication des données. RPO est un paramètre très
important dans les solutions de « disaster recovery », avec le Recovery Time Objective
(RTO). La réplication de données réfère au stockage de données et à la stratégie de
sauvegarde qui permet de copier des données d’un ordinateur hôte sur un autre ordinateur
pouvant se trouver sur un emplacement proche ou lointain. La réplication à travers un réseau
d’ordinateur peut établir une sauvegarde des données entièrement indépendamment du centre
local de stockage physique des données.
Deux réplications de données sont possibles : la réplication « en ligne » et « hors ligne ».
Dans la réplication de donnée « en ligne » à travers un réseau comme Internet, la sauvegarde
de donnée est faite en temps réel. La donnée à partir du serveur hôte est copiée sur
l’emplacement de sauvegarde aussitôt la donnée modifiée. En ce qui concerne la réplication
de données hors ligne, la sauvegarde des fichiers de données est prise sur l’emplacement de
sauvegarde sur une base hors ligne. La réplication de donnée « hors ligne » est préférée dans
des environnements où le nombre de transactions est très important et que la réplication en
temps réel peut ainsi affecter les performances du système.
Le RTO est déterminé en se basant sur le temps de panne acceptable dans le cas d’une
perturbation des opérations. Il indique le dernier point de synchronisation pour lequel les
opérations de business doivent reprendre après un désastre. RTO doit être considéré en
conjonction avec le RPO afin d’avoir une vision globale du temps que l’entreprise peut perdre
suite à un désastre. Ces deux paramètres sont des éléments très importants lorsque l’on établit
une solution de disaster recovery. Cela peut se résumer par :
CRESTA Guillaume
Page 67
RTO = Temps entre une catastrophe et le moment où le système est opérationnel.
RTO = Time UP – Time Crash.
RPO = temps entre le moment où la dernière sauvegarde a été complète (données
sauvegardées et concordantes) et le crash. RPO = Tcrash – Tbackup
Le temps perdu pour le Business peut être défini par : Tup – Tcrash – Tbackup.
Les deux sites peuvent se situer sur deux continents différents ou simplement sur deux
réseaux différents. IBM fournit également une méthode de réplication de donnée mais de
manière synchrone. Cette méthode, appelée Metro Mirror, a été conçue pour supporter une
réplication sur des distances métropolitaines d’environ 300 kilomètres.
Les fonctions Metro Mirror offrent une copie en mode synchrone sur de longues distances et
permettent de mettre à jour constamment une copie d’un volume lorsque des changements
sont effecutés sur celui-ci.
Avec les services de copie Metro Mirror, les volumes sources et cibles peuvent être sur la
même unité de stockage ou sur des unités de stockage distinctes. On peut positionner l’espace
de stockage de sauvegarde sur un site éloigné. Le mirroring synchrone signifie que chaque
mise à jour sur le site de stockage source doit aussi être mis à jour sur l’unité de stockage du
site cible avant qu’une autre mise à jour soit effectuée. Quand Metro Mirror reçoit une mise à
jour du host sur le volume source, il effectue la mise à jour correspondante sur le volume
cible. Lorsqu’une opération d’écriture est terminée, une garantie est reçue par l’application du
host après que la mise à jour est été effectuée sur l’unité de stockage cible et reconnue par les
unités de stockage sources et cibles. Les volumes cibles sont souvent sur différentes unités de
stockage. Ces résultats presque parfaits d’un point de vue concordance des données, peut être
le résultat d’un retard entre les transactions.
Avec Metro Mirror, la concordance est assurée à travers les volumes sur lesquels une
application écrit ses opérations aussi longtemps que les volumes paires sont dans un état « full
duplex ». Quand les conditions d’erreur affectent quelques uns des volumes pairs (ou
différents volumes paires à des instants différents), cette concordance peut être perdue. Par
exemple, si un des volumes cibles ne peut être mis à jour à cause de la perte de lien, le volume
source correspondant se met normalement dans un état « suspended », mais continue à
autoriser les mises à jour. Cependant, ces mises à jour ne sont pas transférées vers le volume
cible. Seulement la table des partitions modifiées est créée et maintenue. Ainsi, la
CRESTA Guillaume
Page 68
concordance des volumes est perdue, bien que l’ordre des opérations d’écriture est toujours
garanti pour les autres volumes cibles.
La copie Metro Mirror supporte une distance maximale de 300 kilomètre (186 miles). Les
délais des temps de réponse pour un Metro Mirror sont proportionnels à la distance entre les
volumes. Cependant, la totalité des données sources est disponible sur le site de sauvegarde
quand les opérations de copie sont terminées.
La procédure suivante décrit comment les données sont écrites et les procédures de copie
effectuées dans le cas d’un Remote Mirror. La copie sur une unité de stockage est synchrone
avec les opérations I/O sur les volumes de source.
1. Une application demande une écriture I/O sur l’unité de stockage source. L’écriture
I/O est écrite dans le cache.
2. Metro Mirror envoie une écriture I/O sur le cache de l’unité de stockage cible.
3. L’unité de stockage du site de sauvegarde signale que l’opération d’écriture a été
effectuée quand la donnée mise à jour figure dans le cache.
4. Quand l’unité de stockage du site de production reçoit la notification de l’unité de
stockage du site cible que l’opération d’écriture est réalisée, il retourne un statut d’I/O
« effectué » à son application
Global Mirror est basé sur des fonctions existantes de services de copies IBM : le Global
Copy et le Flash Copy.
Les fonctions Global Copy permettent de copier de manière non synchrone sur de longues
distances. Les opérations d’écriture d’une unité de stockage sur le site de production doivent
être achevées avant d’être transmises à l’unité de stockage d’un site de restitution.
Global Copy est une fonction de mirroring non synchrone et une approche alternative
mirroring aux opérations Metro Mirror. Les mises à jour des hosts sur les volumes sources ne
sont pas retardées par une attente de la mise à jour qui doit être confirmée par l’unité de
stockage du site secondaire. Le volume source envoie une copie périodique de fichiers mis à
jour au volume cible au lieu d’un flux constant de mises à jour. Il n’y a aucune garantie que
les opérations dépendant des écritures ne soient transférées dans une même séquence car les
opérations peuvent être appliquées au volume source. Cette opération non synchrone aboutit à
un « fuzzy copy » sur le site de sauvegarde. Cependant, à travers les procédures, on peut créer
CRESTA Guillaume
Page 69
une copie avec des points de synchronisation sur le site de restitution qui convient pour une
migration de données, un backup ou pour des intentions de disaster / recovery.
Pour garantir qu’une copie logique des données soit effectuée, on peut périodiquement
basculer d’un mode Global Copy à un mode Metro Mirror. Ensuite, chaque copie arrête les
applications I/O et gèlent les applications d’écriture sur les volumes sources et attend que
toutes les mises à jour en suspens soient copiées sur le site secondaire. A ce moment là, on
peut créer une opération de Flash Copy sur le site de sauvegarde pour obtenir une donnée
concordante.
La fonction Global Copy peut être utilisée sur de très longues distances, bien au-delà des 300
kilomètres que peut supporter le Metro Mirror, et avec un impact minimal sur les applications,
sur une distance qui est limitée seulement par le réseau et les technologies utilisées.
Durant un désastre, les données peuvent être restituées seulement sur le dernier incrément
concordant qui a été créé. Cela signifie que les données qui ont été écrites sur le site de
production, en attente pour être transférées sur le site secondaire, sont perdues quand les deux
sites ne peuvent plus communiquer entre eux. Il faut avoir conscience que l’utilisation des
fonctions Global Copy ne donne aucune garantie vis-à-vis de la perte de donnée. Les
fonctions Global Mirror, d’un autre côté, permettent des copies des données de production
récupérables sur un site de sauvegarde lointain en formant continuellement des ensembles de
données logiques avec aucun impact significatif sur les performances. Il autorise un
redémarrage rapide sur le site de sauvegarde en cas de désastre sur le site de production.
Les phases suivantes décrivent la séquence d’écriture du Global Copy :
1. Durant une opération Global Copy, l’unité de stockage du site de production capture
des informations sur les mises à jour des volumes sources et envoie périodiquement
ces mises à jour au volume cible du site secondaire.
2. Après la copie initiale de fichiers, l’unité de stockage démarre de manière périodique
un cycle de synchronisation où les données mises à jour, dans un ordre ascendant à
partir du plus petit nombre de donnée, sont copiées du volume source au volume cible.
L’unité de stockage met à jour les données cibles avec les informations courantes pour
cet espace, sans regarder le nombre de mises à jour effectué entre la dernière mise à
jour qu’il a établie sur son site et le temps présent ni l’ordre dans lequel les mises à
jour ont eues lieu.
CRESTA Guillaume
Page 70
3. Quand ce processus est terminé, le cycle est répété. Il y a une légère dégradation du
temps de réponse des opérations d’écriture d’une application suivant la distance
parcourue.
4. Les mises à jour d’écriture sur le volume source reçoivent un achèvement immédiat
car le cycle de synchronisation est indépendant des mises à jour sur le volume source.
Les opérations de Global Mirror assurent de manière périodique une copie avec des points de
synchronisation à intervalle régulier sur le site de sauvegarde sans endommager les I/O sur les
volumes sources. En groupant plusieurs volumes dans une session Global Mirror, de multiples
volumes peuvent être copiés sur le site secondaire de manière simultanée, en réglant le
« point-in-time consistency » pour ces volumes.
IBM dévoile Global Mirror, une technologie de mirroring (copie de données) capable de
sauvegardes ultra-rapides, depuis des sources de données géographiquement éloignées.
Techniquement, Global Mirror utilise un système de contrôle Peer-to-Peer de type asynchrone
(à l’inverse du type synchrone - Synchronous Peer-To-Peer Remote Copy - embarquée dans
Metro Mirror, autre outil de sauvegarde de la marque), pour transférer les données via la fibre
optique. Côté performance, la technologie n’affiche que 3 à 5 secondes de latence (soit un
débit de 23000 I/O par seconde) pour transiter sur 180 miles (au maximum).
Global Mirror fournit une solution de copie sur longue distance entre deux sites pour les
données des systèmes d’exploitation ou pour les z/OS (ou pour les deux) utilisant une
technologie asyncrhone. Ce processus est accompli en utilisant le DS Storage Manager ou
l’interface de ligne de commande (CLI).
Le processus Global Mirror est le plus souvent associé à un phénomène de désastre et de
restitution ou pour préparer à ce phénomène. Cependant, il peut aussi être utilisé pour des
opérations quotidiennes ou pour la migration de données.
La fonction Global Mirror est désignée pour refléter les données entre les paires de volume
d’une unité de stockage à travers de grandes distances sans affecter la performance
d’ensemble. Elle est également créée pour fournir une application permettant aux données
d’un site primaire d’être sauvegardées sur un site secondaire dans le cas d’un désastre du site
primaire. En créant un groupe de volumes à espace de temps régulier (quelques secondes),
cette fonction s’adresse au problème d’uniformité qui peut se poser quand de grosses bases de
CRESTA Guillaume
Page 71
donnée et des volumes sont répartis sur plusieurs unités de stockage. Avec Global Mirror, les
données du site secondaire sont maintenues pour être une copie logique, à chaque
synchronisation, des données du site primaire.
Global Mirror est basé sur des fonctions de services de copie existante : Global Copy et Flash
Copy. Les opérations Global Mirror invoquent un point de synchronisation Flash Copy au site
secondaire, à intervalle régulier, sans interrompre les I/O du volume source, donnant ainsi une
mise à jour continuelle, presque un backup de donnée instantanée. Puis, en groupant plusieurs
volumes dans une session, qui est gérée par une unité de stockage master, on peut copier
simultanément de multiples volumes sur le site secondaire en maintenant des points de
synchronisation à travers ces volumes.
Les raisons d’utilisation du processus Global Mirror peuvent inclure :
•
Le support pour des distances illimitées théoriquement, entre le site primaire et
secondaire, mais avec une distance limitée seulement par les capacités du réseau et de
la technologie employée. Cette distance illimitée nous permet de choisir
l’emplacement du site de sauvegarde en se basant sur les besoins de business et
permet, par la séparation des sites, d’ajouter une protection par rapport aux désastres
localisés.
•
Une copie de donnée logique et redémarrable sur le site secondaire, créée avec un
impact minimum sur les applications du site primaire
•
Une circulation des données, sur notre site secondaire avec un retard sur le site
primaire de 3 à 5 secondes, minimisant la quantité de données perdue en cas de
problème non prévu. L’actuel retard dans la circulation des données, peut dépendre
d’un bon nombre de facteurs incluant les caractéristiques spécifiques du réseau et la
bande passante entre les deux sites.
•
Un support de la session qui permet l’uniformité des données qui est gérée en interne
au travers de plusieurs unités de stockage qui sont localisés à travers le site local et le
site de copie.
•
Une synchronisation efficace entre les deux sites avec le support des modes de failover
et failback, aidant à réduire le temps qui est requis pour basculer à nouveau sur le site
primaire après un désastre prévu ou non.
Afin de mieux comprendre comment le Global Mirror fonctionne, nous devons être plus
familiarisés avec les termes suivants :
CRESTA Guillaume
Page 72
Master
L’unité de stockage master contrôle la création des « consistency groups » dans la
session Global Mirror. Le master envoie des commandes aux unités de stockage
subordonnées. Une unité de stockage est autorisée à être master d’une seule
session Global Mirror.
Subordinate
L’unité de stockage subordonnée reçoit des commandes d’une unité de stockage
master. L’unité de stockage subordonnée est identifiée quand la session Global
Mirror est démarrée. L’unité de stockage subordonnée forme un « consistency
group » et exécute d’autre processus Global Mirror. Une unité de stockage
subordonnée peut seulement être contrôlé par une unique unité de stockage master.
Session
Une session est un rassemblement de volumes à travers de multiples unités de
stockage qui sont gérées ensemble pour créer des copies logiques de données. La
session est identifiée avec un identificateur (ID) qui est unique dans l’entreprise.
Cet ID identifie les volumes qui participeront au global Mirror « consistency
group ». Une session est ouverte sur chaque LSS présent dans l’entreprise
possédant des volumes qui participeront au Global Mirror « consistency group »,
associés à cet ID spécifique de session.
Control path
Le control path est établi entre l’unité de stockage master et l’unité de stockage
subordonnée quand plus d’une unité de stockage participe à la session du Global
Mirror. S’il y a seulement une unité de stockage qui est nécessaire, on ne doit pas
créer de control path : l’unité de stockage master communique directement avec
l’unité de stockage subordonnée.
Le cycle automatique dans une session active Global Mirror fonctionne comme un suivi afin
de maintenir les données sur un site secondaire et d’être une copie concordante à certains
moments par rapport aux données présentes sur le site primaire.
CRESTA Guillaume
1.
Page 73
« Consistency groups » de volumes sont créés sur le site primaire
2. Augmentation des données consistantes envoyées sur le site secondaire
3. Opérations de Flash Copy sont effectuées sur le site secondaire
4. Des opérations de Global Copy sont effectuées entre le site primaire et le site
secondaire afin de copier entre les points de synchronisation
5. Ces étapes sont répétées en concordance avec les intervalles de temps définis.
Figure 27 – Schématisation du cycle Global Mirror
Le Global Mirror peut contrôler la formation des « consistency groups » pour des données
logiques. Global Mirror est basé sur la combinaison des fonctions Global Copy et Flash Copy.
Afin de supporter des données à travers des unités de stockage, Global Mirror utilise une
fonction appelée session afin d’établir des copies logiques. Un « consistency group » est un
groupe de volumes présent sur de multiples unités de stockage et qui sont gérées ensemble
quand l’utilisateur crée des copies de donnée. La formation de ces groupes est coordonnée
par l’unité de stockage « master » qui envoie les commandes à travers le « remote mirror » et
copie les liens aux unités de stockage subordonnées.
Avec les fonctions Global Mirror, les groupes peuvent être formés plusieurs fois par heure, au
lieu d’une à deux fois par jour. En combinant plusieurs volumes dans une session, qui sont
gérées par l’unité de stockage master, de nombreux volumes peuvent être copiés sur le site
secondaire simultanément en entretenant des points de synchronisation à travers les volumes.
Les propriétés suivantes contrôlent à quelle fréquence les « consistency groups » sont formés.
On peut modifier leurs valeurs en utilisant l’interface Web appelée IBM System Storage DS
CRESTA Guillaume
Page 74
Storage Manager. On peut accéder à la page Global Mirror et ensuite définir les propriétés à
partir des fonctionnalités du menu.
Consistency group interval time
Indique le temps (en secondes) que l’unité de stockage attend entre la formation
des différents « consistency groups ». Si l’on met cette valeur à zéro (ce qui
requiert une bande passante suffisante), les « consistency groups » se forment
continuellement, ce qui signifie que le « consistency group » commence à se
former dès que le précédent l’a réalisé
Maximum coordination interval
Indique le temps maximum (en millisecondes) que l’unité de stockage master
communique avec les unités de stockage subordonnées afin de former un point
de synchronisation (« consistent data point »). Par défaut, ce temps est de 50
millisecondes.
Parce que l’écriture I/O des hosts est retardée quand le point de synchronisation
est fait, la performance peut être affectée en autorisant un temps trop long pour
cet intervalle. Si le temps programmé pour le « maximum coordination interval »
expire avant que la formation d’un point de coordination soit terminée, le
« consistency group » échoue.
Maximum time writes
Indique le temps maximum (en secondes) durant lequel les opérations d’écriture
ne sont pas autorisées sur le site secondaire, et ceci avant que l’unité de stockage
stoppe la formation du « consistency group » courant. Si le « drain time » est
maintenu sur une longue durée, le nombre d’opérations d’écriture qui est exigé
pour le transfert de données en direction du site secondaire peut devenir assez
large pour augmenter le temps de création du « consistency group ». La perte de
données peut aussi être augmentée en situation de désastre. Si ceci est réglé sur
zéro, cela prend quatre minutes ou deux fois la valeur du « consistency group
interval » pour la reprise. Cela dépend de la valeur la plus importante. Le
premier « consistency group » est formé sans se soucier du « consistency group
drain time ». Pour le reste des « consistency groups », si le temps spécifique
CRESTA Guillaume
Page 75
expire avant que la donnée soit envoyée sur le site secondaire, la formation des
« consistency group » s’arrête. Après que la formation des « consistency group »
soit stoppée durant cinq temps consécutifs, l’horloge est mise hors service et le
prochain « consistency group » est formé sans se soucier du temps requis.
Note : Quand la distance augmente, le retard augmente en fonction du temps que
prend une donnée pour être écrite sur le site secondaire. Ce retard est référencé
comme « drain time ».
Le Global Mirror peut être combiné avec un produit permettant le clustering d’une surface
large, tels que Geographically Dispersed Parallel Sysplex (GDPS), ou l’HACMP/XD. Cela
permet d’automatiser le failover entre les sites. La solution combinée fournit le Recovery
Time Ojective le plus petit possible et permet à la plupart des applications de reprendre les
opérations de production dans les 30 à 600 secondes.
Les fonctions de Global Miror sont disponibles sur les unités de stockage incluant le DS8100,
le DS83000, le DS6800, l’ESS Model 800 et l’ESS Model 750.
Le script Global Mirror effectué durant ma période de stage figure en Annexe 8 et est en cours
de test au moment de l’écriture de ce rapport.
CRESTA Guillaume
Page 76
III RESULTATS ET DISCUSSIONS
III.1
Travail effectué conformément au cahier des charges
Les utilisateurs de la plateforme, à savoir les membres de l’équipe HACoC, ont validé
l’intégration du linux sur la plateforme car celle-ci répond à leurs attentes, aux exigences du
cahier des charges, aux besoins de l’équipe HACoC et plus particulièrement à ceux de Mme
Christine O’SULLIVAN.
Un des System x est intégré sur la plateforme sur le site 1 à Montpellier, et l’autre est en
relation avec le DS6000 présent à Montpellier afin de continuer les tests. Aucun System x n’a
pour le moment été configuré à Poughkeepsie car les tests sont en cours à Montpellier à l’aide
du simulateur de distance. Ce System x permet d’effectuer des services de copie tel que le
global mirror ou le metro mirror et pourra par la suite supporter une application Oracle. Ce
serveur dispose d’un système d’exploitation Linux Red Hat Release 4.0 avec un logiciel de
multipathing « sdd ». Des logiciels permettent également d’analyser le trafic, la perte de
trames, les erreurs et aussi d’établir les performances. Les utilisateurs sont en permanence
tenus au courant de l’état et de l’évolution des performances du système et peuvent récupérer
les statistiques à leur guise.
Toutes ces évolutions apportés par le nouveau système me permettent d’affirmer que son
emploi est d’une grande utilité pour la plateforme « Disaster / Recovery ».
La mise en place des System x étant terminée, j’ai commencé à rédiger une publication IBM
qui explique aux IBMers et aux clients toute la démarche pour procéder à l’intégration d’un
Linux en relation avec une unité de stockage ainsi que les problèmes que j’ai pu rencontrer et
comment je les ai résolus. Une fois, le System x en place, il est aisé de lancer les scripts
global mirror ; et il faut alors analyser les graphiques obtenus. Certaines vérifications voire
manipulations sont encore à effectuer. Il faut vérifier certaines informations et au besoin les
modifier.
Le System x a été progressivement mis en exploitation par les utilisateurs, avec une phase de
tests qui a duré plusieurs semaines pendant lesquelles Mme Christine O’SULLIVAN et moimême avons pu observer le fonctionnement du système et cette phase est encore en cours.
CRESTA Guillaume
Page 77
J’ai, dans le même temps, commencé à expliquer ma démarche aux personnes travaillant avec
moi sur la plateforme. A mon grand étonnement, l’accueil de celle-ci fut enthousiaste, car
l’installation du système répondait aux besoins énoncés au début du stage. Certains tests de
redémarrage permirent de mettre en évidence des anomalies auxquelles je n’avais pas pensé.
Ils permirent aussi de détecter quelques problèmes de suppression et de recréation qu’il fallait
effectuer. Ils servirent aussi à me confirmer le bon fonctionnement. Le retour des
collaborateurs m’a énormément servi pour parfaire l’intégration du serveur à la satisfaction de
ma tutrice et pour établir ma publication.
III.2
Méthodologie et planning
Une fois le cahier des charges défini, j’ai planifié les diverses tâches à accomplir pour
développer le projet qui m’était confié :
-
la configuration de la baie,
-
l’installation des linux,
-
les différents tests de copie,
-
la rédaction de la publication.
Au fur et à mesure de l’avancement du projet, j’ai pu en contrôler la progression et tester les
réalisations effectuées.
Le planning de travail que j’ai suivi durant ce stage est présenté sur la figure 32. On remarque
la nécessité d’une période d’adaptation au monde de l’entreprise et aux technologies utilisées
ainsi qu’une période de compréhension totale de la plateforme qu’il fallait faire évoluer. Le
développement propre du linux et de la plateforme ne représente qu’une infime partie, car le
travail de réflexion, de concertation, de discussion et de recherche des informations fut long
mais fructueux.
Néanmoins, j’ai réussi à respecter le planning que nous nous étions fixé avec Mme
O’SULLIVAN au début du stage, présenté sur la figure 31.
CRESTA Guillaume
Page 78
Avril
Phase d’adaptation : Travail sur la mise en place d’infrastructure de
benchmarks pour faciliter l’apprentissage et l’appréhension de
l’environnement matériel IBM.
Mai
Intégration dans un projet en cours (mise en place d’une plateforme de
« Disaster/Recovery » entre la France et les Etats-Unis) et travail en
équipe.
Juin – Septembre Nouveau développement par l’intégration d’un nouveau serveur (Linux)
dans la plateforme testée. Ce troisième volet fait appel à la capacité
d’autonomie du stagiaire.
Figure 28 - Planning de travail au début du stage
Début avril
Avril
Fin Avril – Début Mai
02 mai – 22 mai
Semaine du 22 mai
Semaine du 29 Mai
Début Juin
Mi Juin – Fin Juin
Début Juillet
Mi Juillet
CRESTA Guillaume
Prise en main de ma machine de travail et configuration de mon
ThinkPad.
Visite des différentes salles machines.
Présentation du service.
Assistance de l’équipe réseau et setup storage.
Lecture de documents sur les System IBM.
Conférence sur la gamme DS4000.
Rédaction du cahier des charges en collaboration avec ma tutrice.
Apprentissage et compréhension de la plateforme et des
technologies SAN (routeur, switch…).
Lecture de documents sur Red Hat.
Lecture des matrices de compatibilité, vérification du noyau et de
la version Red Hat utilisée.
Apprentissage de l’outil de configuration des unités de stockage
(soit par gui : web soit par cli : ligne de commandes).
Création des volumes, volumes groupes et Host.
Assistance à un Benchmark Linux pour le client IN2P3 avec Cyril
Langlais de l’équipe TotalStorage.
Problème à la création de vpath et de configuration du linux.
Recherche de documentation pour le rapport.
Lecture de la documentation sur IOZone.
Etablissement de scripts de démarrage.
Event CSI sur 3 jours : rôle de Room Manager.
Fin d’établissement des scripts de démarrage et tests.
Documentation Global Mirror.
Etablissement du script Global Mirror commenté.
Présentation à mi-stage de l’avancée du projet à mon manager et à
mes collègues.
Visite du tuteur ISIMA.
Assistance à la conférence sur les activités IBM.
Mise au vert avec l’équipe TotalStorage.
Installation du deuxième Linux.
Problème sur le DS6000 : ouverture d’incident, intervention du
support.
Fin Juillet – Mi Août
Mi Août – Fin Août
Début Septembre
Page 79
Problème sur les ports Ethernet des switchs McData.
Problème sur le spirent et plus particulièrement sur les fibres.
Mise à jour du DS8000 (montée du code).
Problème sur la configuration des linux par rapport au storage :
vérification des fibres, du zoning, réinstallation des Linux,
recréation des volumes sur les DS, vérification des System x.
Support SAN pour l’équipe SVC et aide à Eric Wong de l’équipe
TotalStorage.
Mise en place de fichiers pour le recensement d’HACoC Room et
des password des machines.
Briefing d’un nouvel arrivant sur la plateforme.
Vérification de la configuration des linux et des unités de stockage.
Débuts des tests.
Fin de rédaction du rapport et début de rédaction de la publication.
Tests.
Université des partenaires sur 2 jours : rôle de Room Manager.
Fin de rédaction de la publication.
Préparation à la soutenance.
Figure 29 - Planning de travail effectif
III.3
Difficultés rencontrées
Au cours de mon stage, les difficultés rencontrées ont été d’ordre technique et bien
souvent d’ordre matériel.
Problème de lien entre le volume groupe et le host
Lors de la création par ligne de commande du volume groupe, j’ai configuré le type en « SCSI
Mask » et je n’arrivais pas alors à créer la liaison entre le volume groupe et le host qui est
configuré comme une RedHat EL. Après une recherche approfondie sur les différentes
liaisons possibles, afin que cette liaison s’opère, il fallait configurer le type en « SCSI Map
256 ». Cette erreur m’a permis d’apprendre qu’il ne fallait pas forcément garder les valeurs
par défaut, ni établir des paramètres en fonction d’autres créations qui ne sont pas forcément
adaptées à notre solution.
CRESTA Guillaume
Page 80
Problème de filtrage des disques de l’unité de stockage
Lors de la configuration du linux et plus particulièrement de sdd, il a fallu modifier la
configuration du fichier /etc/lvm/lvm.conf. En effet, je n’arrivais pas à créer mon vpath dans
le but d’établir un multipathing ; et je ne voyais pas d’où cela pouvait provenir.
Après m’être entretenu avec des spécialistes Red Hat et suite à des recherches personnelles,
j’ai résolu le problème en modifiant deux lignes du fichier :
filter = ["a/.*/"]
types = ["fd", 16]
par les lignes :
filter = ["a|/dev/sda|", "r|/dev/sd|", "a/.*/"]
types = ["vpath", 16]
Ces nouvelles lignes permettent au serveur linux de ne pas filtrer les autres disques que sda
(disque principal sur lequel est installé Linux).
Problème du au redémarrage du système d’exploitation
Une fois, ce problème de vpath résolu et ma configuration terminée, j’ai redémarré le système
d’exploitation afin de voir ce qui était pris en compte et j’ai pu constater que le service sdd
n’était pas démarré par défaut, et qu’il fallait une intervention de l’administrateur sur le
système afin de le mettre en route. De plus, le volume logique créé sur le linux apparaissait à
chaque démarrage en statut Inactive, il fallait une autre opération de l’utilisateur afin de le
passer en statut Active et puis de faire un mount. J’ai donc pris l’initiative de faire un script de
démarrage qui permettrait de redémarrer le système d’exploitation sans avoir à reconfigurer et
sans que l’administrateur ait à intervenir. Je me suis renseigné afin d’apprendre à créer un
script de démarrage et ainsi permettre l’automatisation de la configuration au redémarrage du
système d’exploitation. Le script se situe ci-dessous :
CRESTA Guillaume
#!/bin/bash
#
# script_sdd
#
#
# description:
#
#
# processname:
Page 81
This shell script takes care of starting and stopping
sdd and configurating Linux.
sdd is a service which is the program
that permits to make multipathing ; and lvchange to change
the logical volume status.
sdd
# Stop sdd
. /etc/init.d/sdd stop
# Start sdd
. /etc/init.d/sdd start
# Source sdd configuration.
# Physical volume scan
pvscan
# Volume Groupe scan
vgscan
# Logical volume scan
lvscan
# Change logical volume lv_halinux1 to active
lvchange /dev/VGHALINUX1/lv_halinux1 -a y
# Logical volume scan
lvscan
mount /dev/VGHALINUX1/lv_halinux1 /halinux1
exit 0
Ce script est présent sur les deux sites afin d’automatiser la configuration et que l’utilisateur
n’ait pas à intervenir à chaque redémarrage. Le fait d’écrire ce script m’a permis de prendre
conscience d’un léger problème, à savoir qu’un script sous windows ne peut être retranscrit
sous Linux. En effet, j’avais confectionné mon script sur mon ordinateur de travail équipé de
Windows et lorsque je l’ai transféré sous Linux, les en-têtes étant différentes, celui-ci ne
s’exécutait pas.
Une fois, le script écrit, il a fallu configurer le Linux pour qu’il le prenne en compte à chaque
redémarrage. Pour cela, il fallait procéder comme défini ci-après.
CRESTA Guillaume
[root@halinux
[root@halinux
[root@halinux
[root@halinux
[root@halinux
[root@halinux
[root@halinux
~]#
~]#
~]#
~]#
~]#
~]#
~]#
ln
ln
ln
ln
-s
-s
-s
-s
../init.d/script_sdd
Page 82
/etc/rc2.d/S81script_sdd_site1
chmod 755 script_sdd
Le processus est le suivant : il faut tout d’abord mettre le script dans le répertoire /etc/init.d, le
passer en mode exécutable (à savoir en -rwxr-xr-x) puis créer des liens (commande ln -s) vers
les différents rc.d pour parvenir à la prise en compte au démarrage.
Incidents sur le DS6000 de Montpellier
Par la suite, au moment de l’installation du linux côté DS6000, j’ai voulu créer mes volumes
ainsi que mes volumes groupes par ligne de commande, mais il était impossible de
communiquer avec l’unité de stockage. J’ai essayé de résoudre le problème mais cela était
impossible, car on ne pouvait pas se connecter sur le port COM du DS6000. J’ai donc fait
appel aux spécialistes du « Setup Storage » qui n’ont pas réussi à le résoudre et ont ouvert un
incident pour y parvenir. L’équipe du support storage est alors intervenue mais entre la
tentative de création et la résolution du problème, quelques semaines se sont écoulées durant
lesquelles on ne pouvait pas travailler. Les IP des contrôleurs avaient été changées, et des
fichiers de configuration avaient été altérés. Quelques difficultés d’ordre matériel sont
apparues sur la plateforme. Tout d’abord la carte Ethernet du poste qui sert de HMC était
endommagée, et on ne pouvait plus alors contacter l’unité de stockage. Une fois celle-ci
changée, on a remis l’adresse IP 172.31.11.46 sur ce poste mais le lendemain, on ne pouvait
plus correspondre avec le DS6000. L’adresse IP était repassée en DHCP. On a alors rétabli
l’ancienne adresse et changé le mot de passe d’accès de ce poste par précaution. Ce problème
n’a pas été détecté depuis. Malgré toutes ses résolutions, je ne voyais toujours pas les disques
de l’unité de stockage à partir de mon Linux. Après des recherches et des vérifications, le
zoning avait mal été configuré entre le DS6000 et le Linux du site 2. En redémarrant le Linux,
je voyais mes volumes.
Problème entre le DS8000 et le System x
L’équipe du « Setup Storage » est intervenue sur le DS8000 afin de faire une mise à jour du
microcode. Une fois la partie DS8000 en place, je ne voyais toujours pas les disques de l’unité
CRESTA Guillaume
Page 83
de stockage à partir de mon Linux. J’ai testé le linux sur un autre System x en créant une
image mais cela donnait le même résultat. J’ai alors décidé de réinstaller mon système
d’exploitation. Je pense que cela a été une erreur car un simple redémarrage aurait sûrement
résolu le problème mais par manque d’expérience je n’y ai pas pensé. J’ai donc réalisé une
réinstallation du système d’exploitation mais malheureusement j’ai laissé les fibres optiques
connectées au System x. Lors de la réinstallation, le Linux a affiché Kernel Panic et ne
pouvait poursuivre l’installation. Un problème surgissait à chaque redémarrage. Je pense qu’à
la réinstallation, la Red Hat est allée écrire sur les volumes du DS8000 et de ce fait allait
scanner les volumes à chaque redémarrage. J’ai alors retiré les fibres connectées au System x
et suis parvenu à installer la Red Hat Release 4.0. Mais à son redémarrage, une fois les fibres
rebranchées le linux affichait toujours Kernel Panic. J’ai alors supprimé les volumes créés
pour les créer à nouveau. Le Linux a bien redémarré, et à cette étape il décelait bien les
volumes créés sur le DS8000.
Problème d’ordre matériel
Par la suite, quelques problèmes d’ordre matériel sont apparus sur la plateforme. Les liens
vers le spirent ne fonctionnaient plus même après l’intervention de l’équipe du réseau. On a
alors réinitialisé les ports du spirent par l’interface web de management et les liens furent
rétablis. Suite à une coupure de courant organisé par la direction du PSSC, nous avons
observé un problème avec le port Ethernet du switch McData : nous n’arrivions plus à
l’atteindre et à configurer les différents ports. L’équipe « Réseau » est alors intervenue afin de
le replacer dans le bon réseau et lui redonner la bonne adresse. Les System x se trouvant dans
les salles machines, j’ai mis en route et configuré le ssh afin d’y avoir accès depuis mon poste
ou à partir des postes de la salle de tests mise à notre disposition. Mais un matin dès mon
arrivée j’ai constaté que je n’avais plus accès à un des linux. J’ai tout d’abord pensé au souci
qu’il avait rencontré. Mais, en fait, celui-ci était démarré, et je n’arrivais pas à le joindre. Cela
provenait d’un faux contact au sein du câble. Une fois changé le ssh a pu reprendre. La
dernière difficulté rencontrée est apparue lors de mon support auprès de SVC. On ne voyait
pas les World Wide Port Name sur les switchs pour le zoning. Cela provenait du fait que les
fibres avaient été connectées à des ports non disponibles. Le port du routeur qui permet la
relation entre les deux sites était tombé. Une réinitialisation a permis l’accès aux disques.
CRESTA Guillaume
III.4
Page 84
Améliorations possibles
Sur la plateforme, de nombreuses améliorations sont possibles. Tout d’abord, si l’on souhaite
diversifier la plateforme côté hardware, on peut encore intégrer deux types de serveurs tels
que le System i et le System z. Cette diversité de serveurs permettrait d’étoffer la plateforme
et ainsi de s’adresser et de convaincre davantage de clients sur l’utilité de cette plateforme.
Une autre diversité serait, après avoir installé AIX et Linux (Red Hat), de configurer d’autres
systèmes d’exploitation tels que Windows ou OS400 (sur System z) par exemple. Cette autre
étoffe permettrait de satisfaire davantage d’utilisateurs potentiels suivant les ressources
humaines de l’entreprise qui ne possède pas forcément des employés spécialisés en Linux ou
AIX. Ces différents rajouts démontreraient aux clients que n’importe quelle configuration est
possible et que, surtout, celle-ci fonctionne sur un site réel de production.
Pour l’instant, sur la plateforme, on dispose d’un System x et d’un System p. Sur ce dernier,
on a une base de données et une application Oracle. Dans l’avenir, on pourrait laisser la base
de données sur le System p et faire tourner l’application sur le System p. Cela permettrait
d’alléger le System p et comme l’application n’est pas trop encombrante, la disposer sur le
System x. Cela permettrait très certainement de gagner en performance et surtout de libérer de
l’espace pour faire évoluer une autre application.
Dans les améliorations possibles, on pourrait penser également à automatiser davantage et à
faciliter la tâche de l’utilisateur. Lors de la création du script de démarrage et de
l’automatisation du lancement du service sdd, l’idée est venue de réaliser la même chose pour
le global mirror. En effet, l’utilisateur est obligé de lancer un script manuellement ou
d’interagir et de taper les lignes de commande afin de régler un temps ou d’arrêter une
session. On pourrait imaginer alors une interface qui faciliterait la sélection de commande
suivant le cas dans lequel on se trouve et permettrait une amélioration du facteur « perte de
temps » pour l’employé en charge de la maintenance. Ainsi, il faudrait penser à tous les
phénomènes susceptibles d’intervenir (lien tombé, perte de données, site primaire tombé…),
et faire en sorte de solutionner au mieux le problème rencontré.
CRESTA Guillaume
Page 85
Pour finir, on dispose d’un outil TPC (Totalstorage Productivity Center) qui permet de gérer
les données et d’assurer une sûreté d’un point de vue software. Il serait souhaitable de
disposer sur une plateforme comme celle d’HACoC d’un outil permettant de garantir une
sûreté côté matériel.
CRESTA Guillaume
Page 86
CONCLUSION
Afin de conclure cette étude, je dresserai en premier lieu un bilan du projet réalisé. Puis,
j’évoquerai les difficultés rencontrées, et les connaissances acquises au cours de ce stage.
Enfin, j’aborderai les possibilités d’amélioration de la plateforme.
A la vue de ce rapport et du travail effectué, je peux dire que les objectifs fixés au départ
par Mme O’SULLIVAN ont été atteints. L’intégration des deux System x sur la plateforme a
été effectuée conformément au planning de travail et sa mise en application début Juillet en
mode simulation à Montpellier a été réalisée avec succès. Cette intégration a été validée par
ma tutrice, et accueillie avec enthousiasme par l’ensemble des personnes travaillant sur la
plateforme ; ce qui, au départ, ne pouvait être une certitude. Le planning de développement
fixé par le cahier des charges a bien été respecté, même si parfois, nous étions en avance sur
celui-ci.
Les quelques difficultés rencontrées ont été d’ordre technique car je ne maîtrisais pas les
relations stockage-Linux. Je n’ai, par contre, pas rencontré de difficulté d’organisation de
temps de travail lorsqu’il fallut commencer l’intégration des différents systèmes
d’exploitation sur la plateforme. Les tests effectués devaient être précis et réalisés dans un
laps de temps très court tout en étant accomplis de manière efficace. Il en fut de même pour la
publication réalisée lors de ce stage. J’ai su mener de front les deux tâches dans les délais
impartis et l’avancement du projet n’en a pas été bouleversé.
Ce stage m’a permis d’apprendre énormément dans la gestion d’un projet étalé sur six
mois. J’ai pu aussi accroître mes connaissances techniques, d’apprendre la technologie SAN,
les espaces de stockage (baies de stockage, bande), de comprendre la mise en relation entre un
système d’exploitation (Linux) et une baie de stockage. De plus, le développement de cette
plateforme m’a associé comme membre d’une équipe sur un projet extraordinaire. Il m’a
donné la possibilité de consolider mes acquis en réseau, au programme de deuxième et
troisième année à l’ISIMA. Enfin, cela m’a ouvert à l’importance de la communauté des
clients lors du développement de ce projet ainsi qu’à la volonté et la capacité d’une entreprise
à les satisfaire.
L’intégration du Linux sur la plateforme est maintenant terminée et il est pleinement
opérationnel. Cependant, je vais continuer, durant les semaines à venir, à travailler sur la
possibilité d’établir de manière automatique le global mirror.
CRESTA Guillaume
Page 87
OUVRAGES CONSULTES
Sites Internet :
http://guide.andesi.org/html/kservices.html
http://kbase.redhat.com/faq/FAQ_85_8002.shtm
http://www.iozone.org/
http://linuxtr.ampr.org/commande/index.html
http://w3-03.ibm.com/hr/taag.nsf/Content/85256E92%3A0043500C
http://www-03.ibm.com/servers/storage/disk/ds8000/index.html
http://www-5.ibm.com/e-business/fr/glossary/index.html
http://www.int-evry.fr/s2ia/user/procacci/Doc/NFS/nfs.html#htoc48
http://www-03.ibm.com/ibm/history/history/history_intro.html
http://w3.pssc.mop.ibm.com/reps/sspd.html
http://www1.ibm.com/support/docview.wss?rs=540&context=ST52G7&dc=DA400&uid=ssg1S7001350
&loc=en_US&cs=utf-8&lang=en#LinuxSDD
Livres :
DUFRASNE B., ALLWORTH B., ARZENSEK J., HECHLER G., LIN A. - IBM
TotalStorage DS4000 Series & StorageManager
IBM TotalStorage DS8000 Series Interoperability Matrix
WARRICK C., GORDON C., GRANIER B., IMAI K., Mc CUTCHEN R., PROCTOR B.,
SEDGWICK J., USONG P., VANDERMARK M., WICKES J. - IBM TotalStorage DS4000
Series : Performance Monitoring and Tuning
CRESTA Guillaume
Page 88
IBM TotalStorage DS8000 Series datasheet
WARRICK C., ALLUIS O., BAUER W., BLASCHEK H., FOURIE A., GARAY J.A.,
KNOBLOCH T.., LAING D., O’SULLIVAN C., PREACHER S., ROTHENWALDT T.,
SANO T., TANG J.N., VANDEWERDT A., WARMUTH A., WOLF R. - IBM TotalStorage
DS6000 Concepts and architecture
WARRICK C., DUFRASNE B., KIMMEL P., KLEE P., MYYRYLAINEN J., NGUYEN L.,
SCHMIDT G., TAKATA S., VANDEWERDT A., WESSELBAUM B., WEST S. - IBM
TotalStorage DS8000 Series Implémentation
WARRICK C., DUFRASNE B., KIMMEL P., KLEE P., MYYRYLAINEN J., NGUYEN L.,
SCHMIDT G., TAKATA S., VANDEWERDT A., WESSELBAUM B., WEST S. - IBM
TotalStorage DS8000 Series : Copy services in open environnements
Montpellier PSSC Education - Asynchronous PPRC Global Mirror
TotalStorage Hands-on Workshops : DS8000, DS6000 & ESS Copy Services for Open
Workshop
Solvay Solid Standard Operating Procedure SLD137 UX Managing Filesystems and
Volumegroups V2.0
Matrice compatibilité sdd – Linux
Manu Ori - Linux RDAC v9.15 for Kernel 2.4 on xSeries
Tuning Red Hat Enterprise Linux on IBM eServer xSeries Servers
Emmanuel Tong-Viet - How to Disaster Recovery platform using McData solutions IBM
IBM Learning services - Introduction to storage networking.
CRESTA Guillaume
Page 89
System Storage and TotalStorage Product Guide (SAN, DR, disques)
Francis Courteaux, Julien Maussion, Laurent Majcher - Easy_dscli tool to learn, reuse, and
share DS Command Line Interface scripts (dscli)
Tate J., Kanth R., Telles A. - Introduction to storage area networks
Bertrand Dufrasne, Ronald Annuss, James Goodwin, Paul McWatt, Arwed Tschoeke Implémenting Linux with IBM Disk Storage
Host Systems Attachment Guide
CRESTA Guillaume
Page I
ANNEXES
CRESTA Guillaume
Page II
TABLE DES ANNEXES
A.1
Complément sur les serveurs IBM System_______________________III
A.2
Présentation hardware du DS8000_________________________________VII
A.3
Présentation hardware du DS6000_________________________________XII
A.4
Complément sur le SAN __________________________________________XVI
A.5
Présentation hardware du switch 24M-1___________________________XXV
A.6
Présentation hardware du routeur SAN16M-R___________________XXVII
A.7
Présentation du spirent__________________________________________XXIX
A.8
Script Global Mirror effectué____________________________________XXXI
CRESTA Guillaume
Page III
A.1 Complément sur les serveurs IBM System
Blade Center
Un serveur devient une simple carte appelée « serveur lame » (« blade server ») doté de
processeurs, de mémoire, d’entrées/sorties et même de disques. Dans le cas du BladeCenter
IBM, quatorze lames sont hébergées par un seul châssis de sept unités rack de hauteur. Grâce
aux serveurs lames, on double la densité atteinte avec une offre traditionnelle. L’ensemble
intégré porte le nom de BladeCenter. Deux types de lames Intel (HS20-2 processeurs et HS40
– 4 processeurs) et un type de lame POWER (JS20-2 PowerPC 970) sont proposés pour
équiper un châssis. Le châssis est disponible en version standard (BladeCenter) ou durcie
(BladeCenter T) pour des applications Telecom. Cette nouvelle dimension en densité n’est pas
obtenue au détriment de la performance puisque chaque serveur lame est doté de 2
processeurs Xéon ou Power et deux canaux Gigabit Ethernet. Le châssis d’accueil est doté en
face arrière d’un ensemble de connexion haute vitesse entre serveurs lame et de commutateurs
KVM (clavier, écran, souris) pour l’accès à chaque serveur lame si nécessaire. L’ensemble est
conçu pour éviter tout point de panne unique. IBM BladeCenter est conçu pour un
déploiement rapide et modulaire. Grâce à IBM Director 4.2, le BladeCenter offre des
fonctions d’administration globale qui aident les responsables informatiques à maximiser les
ressources, augmenter la productivité tout en réduisant les coûts opérationnels. Des fonctions
optionnelles telles que « Remote Deployment » permettent l’activation des lames en quelques
minutes. Fonctionnant sous Linux, Windows, AIX selon le type de « blade », le BladeCenter
trouvera de nombreuses applications, aussi bien en scientifique et technique, qu’en gestion.
IBM travaille avec des leaders de l’industrie comme Broadcom, Citrix, D-Link, Intel,
Microsoft, Nortel, Qlogic, ainsi que les équipes DB2, WebSpere, Lotus, Tivoli pour fournir
des solutions innovantes utilisant le BladeCenter. Plus de 50 000 applications peuvent tourner
sur le BladeCenter.
System p
Les systèmes POWER4 et POWER5, au contraire, sont très flexibles. A partir du jeu de
processeurs, de la totalité de la mémoire et de tous les adaptateurs, on configure librement des
CRESTA Guillaume
Page IV
partitions en associant logiquement des processeurs, des zones mémoire et des cartes PCI
pour les entrées/sorties. On peut ainsi créer des serveurs logiques à partir d’un ou plusieurs
processeurs. Le partitionnement logique répond parfaitement aux besoins actuels liés aux
charges dynamiques et non prévisibles. Une croissance rapide suppose des systèmes dont le
périmètre peut être rapidement redéfini. A un moment donné ils peuvent par exemple
supporter un serveur de production logique, des systèmes de développement et d’intégration
et d’autres serveurs.
Innovation IBM 1 : Micro partitionnement
Avec les serveurs POWER 5 annoncés récemment, IBM a franchi une nouvelle étape en
termes de flexibilité en introduisant la possibilité de définir des micros partitions « sub
processeur », c'est-à-dire n’utilisant que des fractions de processeurs. Avec une taille de base
de 1/10 de processeur, une partition peut être augmentée par tranches d’1/100ème de
processeur. Cette définition des différents serveurs logiques est faite par le biais de la console
de gestion du matériel.
La partition peut être limitée à une taille prédéfinie (« capped ») ou non limitée. Avec le
micro partitionnement, toutes les plus petites applications peuvent trouver place sur un system
POWER5 sans gaspiller des ressources.
Innovation IBM 2 : Virtualisation des entrées/sorties (I/O) avec le concept de serveur
d’I/O virtuel
IBM introduit avec les systèmes p5 une virtualisation des entrées/sorties qui complète la
virtualisation des partitions logiques. Tout ou partie des adaptateurs physiques du système
sont regroupés en pols et hébergés par une ou plusieurs partitions dédiées appelées serveurs
d’entrées/sorties virtuelles. Ces partitions se mettent au service des autres partitions
applicatives et assurent les entrées/sorties vers l’extérieur (réseau, stockage) mais aussi
reconstituent un environnement de réseaux virtuels internes à la machine. Le résultat est un
découplage total des partitions applicatives des entrées/sorties physiques (les adaptateurs)
avec, en complément, des réseaux locaux Ethernet virtuels. De plus, ce mécanisme permet un
partage efficace des adaptateurs et sous systèmes matériels et augmente leur taux d’utilisation.
Les serveurs d’entrées/sorties utilisent AIX 5L comme système d’exploitation mais sont
CRESTA Guillaume
Page V
encapsulées pour simplifier la gestion de l’ensemble. Le partage des adaptateurs Fibre
Channel est fait en allouant et associant les LUNs SAN aux partitions applicatives. La
fonction logicielle entrées/sorties multi voies au sein des partitions gérant les entrées/sorties
virtuelles permet de les protéger contre des pannes éventuelles des liaisons Fibre Channel
avec les contrôleurs de stockage SAN. Le concept de disques virtuels est mis en œuvre en
utilisant le gestionnaire de volumes logiques de AIX 5L dans les serveurs d’entrées/sorties
virtuelles. Les volumes deviennent des disques virtuels pour les partitions applicatives
clientes.
L’approche traditionnelle impliquait une évaluation des besoins matériels pour chaque
application avant son déploiement, avec souvent un coûteux surdimensionnement pour
couvrir les incertitudes dans le calcul des charges et parer aux éventuels pics de charge. Plus
tard en opération, une montée en charge imprévue pouvait conduire à des upgrades coûteux
ou l’achat de nouveaux serveurs. Avec les nouveaux serveurs p5, le responsable informatique
aura toute liberté pour coller aux besoins changeants de ses applications en leur allouant en
opération les ressources adéquates.
Les options de capacité « on demand » pour les systèmes p5 sont au nombre de quatre :
capacity upgrade on demand, on/off capacity on demand, reserve capacity on demand, trial
capacity on demand. La capacity upgrade on demand consiste en un upgrade en capacité
processeurs ou mémoire d’un système. Le on/off capacity on demand permet d’une part
l’utilisation temporaire d’un nombre de processeurs et d’un volume mémoire identifiés, et
d’autre part au client de choisir la capacité requise, d’activer la ressource (système enregistré),
et d’ajouter et de retirer à volonté la capacité. La reserve capacity on demand concerne les
ressources processeurs seulement et la capacité peut être activée et désactivée par le client. Le
trial capacity on demand permet au client de tester l’impact d’une action de processeurs ou de
mémoire et d’activer partiellement ou totalement des processeurs/mémoire. Si le client désire
des ressources supplémentaires, elles ne sont disponibles que pour un temps limité (30 jours).
IBM propose la dé-allocation dynamique de processeur. L’objectif n’est pas d’être capable de
remplacer un processeur défaillant sur une machine arrêtée mais d’empêcher ce processeur de
perturber les applications qui tournent sur le serveur et ainsi d’assurer la continuité du service.
La fonction de dé-allocation permet de mettre hors circuit un processeur défaillant avant que
celui-ci ne conduise à l’arrêt du serveur (valide pour les serveurs équipés de plus de deux
processeurs). Avec les systèmes p5, on pourra même compléter le schéma en prévoyant des
processeurs de rechange, prêts à prendre automatiquement la relève de processeurs défaillants
CRESTA Guillaume
Page VI
pour maintenir le niveau de service. Pour les applications d’aujourd’hui, on a besoin d’une
disponibilité de service 24h/24, 7j/7.
System i
L’autonomie se résume en quatre points : auto-protection, auto-optimisation, auto-dépannage,
et auto-configuration. L’auto-protection ou Enterprise Identity Mapping rassemble les
signatures digitales et détection d’intrusion, l’auto-optimisation le partitionnement Logique
Dynamique, l’auto-dépannage qui supporte la commutation de disques, l’Agent Building
Learning
Environnement
(ABLE)
pour
la
gestion
d’incidents,
et
l’auto-
configuration rassemble les assistants graphiques pour gérer les charges de travail multiples et
la performance, la commutation des disques en clusters, la sécurité et le réseau, la sauvegarde
des données et système.
CRESTA Guillaume
Page VII
A.2 Présentation hardware du DS8000
Cette annexe va permettre de présenter succinctement la partie hardware du DS8000. Un
DS8000 est composé d’alimentations, d’une console de management (HMC), de disques, de
serveurs pseries intégrés, de batteries et de tiroirs I/O comme représenté ci-dessous :
L’IBM TotalStorage DS8100 (2-Way) est ainsi représenté comme ceci :
CRESTA Guillaume
Page VIII
et l’IBM TotalStorage DS8300 (4-Way) :
Le DS8000 peut être décomposé en différents modules comme représenté ci-dessous :
On peut voir les différents composants du DS8000.
Tout d’abord, le processeur, ci-dessous en vue de face et arrière, dispose de ports RIO-G,
d’alimentations, d’emplacements pour carte PCI.
CRESTA Guillaume
Page IX
On peut voir plus précisément les ports RIO-G sur la figure ci-dessous.
Les « enclosures » I/O sont représentées ci-dessous, que ce soit en vue de face ou arrière. On
peut ainsi remarquer les alimentations redondantes et les ports que possèdent ces enclosures.
CRESTA Guillaume
Page X
Des ports Ethernet sont disponibles sur les unités de stockage afin de s’y connecter et de
pouvoir également les relier à un réseau privé via la HMC.
On peut donc voir les branchements effectués et les ports disponibles sur la HMC et sur les
switchs en vue arrière.
CRESTA Guillaume
CRESTA Guillaume
Page XI
Page XII
A.3 Présentation hardware du DS6000
Le DS6000 est présenté en vue de face et arrière.
Le DS6000 est composé d’alimentation, de contrôleurs, de batteries. Comparé au DS8000, il
ne contient pas de HMC. Celle-ci est un poste de travail que l’on relie au DS6000. On voit cidessous la partie arrière du DS6000.
CRESTA Guillaume
Page XIII
Ci-dessous, on peut remarquer les cartes d’expansion et les contrôleurs ainsi que les câblages
constitués avec les différents ports (host, Ethernet, expansion). On a également des indicateurs
de puissance et d’erreur sur le contrôleur.
CRESTA Guillaume
Page XIV
Afin de mettre les DS6000 en cascade, voici le câblage FC-AL (en boucle) que l’on effectue :
Ci-après, la vue arrière du DS6000 nous permet d’exposer les différents éléments (ports,
boutons, indicateurs, connecteurs…) de l’unité de stockage.
Le tableau ci-dessous permet de référencer les différentes capacités des disques suivant les
modèles :
CRESTA Guillaume
Page XV
Voici une schématisation avec un seul hôte sur le DS6800
en comparaison avec un hôte relié à deux contrôleurs permettant de faire du multipathing par
exemple :
CRESTA Guillaume
Page XVI
A.4 Complément sur le SAN
Les équipements interconnectés par le réseau SAN sont appelés "noeuds". Plusieurs
topologies de réseau peuvent être utilisées : topologie point à point, et les topologies réseaux
qui sont la topologie switchée et la topologie en boucle arbitrée.
Pour la topologie point à point, il n'y a pas réellement la mise en œuvre d'un réseau, mais on
effectue des connexions directes entre les unités de stockage et les serveurs d'applications.
Topologie point à point
Par rapport à une connexion traditionnelle SCSI, la connexion Fibre Channel apporte ici,
grâce à la fibre optique, les avantages suivants : un débit jusqu'à 400 méga octets par seconde
en mode full duplex, et une distance jusqu'à 10 km sans répéteur.
Deux topologies réseaux sont disponibles. Elles correspondent à deux variantes du protocole
Fibre Channel : le protocole FC-S pour les topologies commutées et le protocole FC-AL pour
les boucles.
La topologie "switchée" (ou commutée) utilise une infrastructure réseau appelée "switch
fabric". Celle-ci est constituée d'un ou plusieurs "switch" reliés aux serveurs d'applications,
aux serveurs de stockages ou de sauvegardes, ou encore entre eux.
CRESTA Guillaume
Page XVII
Topologie switchée
Les switchs assurent un transfert simultané au débit nominal de 100/200/400 Méga Octets par
seconde entre tous les noeuds connectés comme l’indique la figure suivante.
Fonctionnement d’un commutateur
CRESTA Guillaume
Page XVIII
Les caractéristiques de cette solution sont un débit de 400 Méga Octets par seconde dédié
pour chaque nœud offrant de hautes performances, une possibilité d'interconnecter des
switchs entre eux et de traverser plusieurs switchs sur un chemin (configuration en cascade),
une capacité d'adressage de 16 millions de nœuds, une redondance possible d'accès aux
données pour augmenter la disponibilité globale du réseau, un temps d'accès aux données
dépendant du chemin et de la charge, une connexion possible de boucles "FC-AL" aux
switchs, et une gestion de réseau nécessaire pour optimiser les performances.
L’autre topologie réseau est donc la topologie en boucle arbitrée. Avec cette topologie (FCAL) les équipements sont interconnectés au travers d'une boucle, donc, la capacité de
transmission est partagée par ces différents équipements.
Host
Host
HUB
Storage
Controle r
Storage
Controle r
Switch
Topologie en boucle arbitrée
Le câblage de la boucle est facilité par l'utilisation d'un concentrateur ("hub") qui accroît la
disponibilité de la boucle en permettant de court-circuiter un noeud défaillant comme
l’indique la figure ci-dessous.
Fonctionnement d’un concentrateur
CRESTA Guillaume
Page XIX
Les caractéristiques de cette solution sont : une boucle offrant un débit de 100, 200 ou 400
Méga Octets par seconde partagé entre les nœuds (127 au maximum), une solution
économique, un câblage autour d'un hub augmentant la disponibilité du réseau, des
performances liées au nombre de nœuds (la performance diminue avec l’augmentation des
nœuds), une reconfiguration possible à chaud et une possibilité de double boucle pour
augmenter la disponibilité globale du réseau.
L'infrastructure d'un réseau SAN est constituée de matériels d'interconnexion : hubs pour les
boucles et switchs pour les topologies commutées. D'autres équipements comme les
"gateways", "bridges" et routeurs, peuvent être utilisés pour connecter au réseau "Fibre
Channel" des équipements ou réseaux qui ne supportent pas ce protocole de façon native. Ces
équipements assurent alors les conversions de protocoles nécessaires.
C'est le cas, par exemple, pour les serveurs ou systèmes de stockage ne supportant que
l'interface SCSI. Il en est de même pour interconnecter des réseaux SAN distants au travers
d’un réseau WAN (ATM par exemple).
Les différents équipements cités précédemment comme les noeuds, les hubs, ou les switchs
sont interconnectés par des fibres optiques sur des ports dont le comportement dépend de
l'équipement auquel ils appartiennent et de celui auquel ils sont interconnectés :
Différents types de ports
Les différents types de ports dépendent de l'équipement. Pour les noeuds (serveur, système de
stockage ou gateway) on a deux types de ports : NL-port d’un port vers un hub et N-port d’un
port vers un switch. En ce qui concerne les hubs, on utilise du L-port. Enfin, pour les switchs,
deux types de ports sont utilisés à savoir F-port d’un port vers un nœud, et E-port d’un port
vers un autre switch.
CRESTA Guillaume
Page XX
Le réseau SAN se caractérise par une transmission de type "série", bidirectionnelle ("full
duplex") sur fibre optique à 100, 200 ou 400 MO/s, suivant un protocole appelé Fibre
Channel.
Le protocole Fibre Channel est défini par des standards (parmi lesquels ANSI T11), organisés
en couches conformément au modèle OSI :
FC-4
Mapping
Multimedia
Audio Video
Channels
Upper Level Protocol (ULP)
FC-3
Mapping
Common Services
FC-2
Signal
Framing Protocol / Flow Control
FC-1
Encode / Decode
Networks
P / 802.2
Protocol
Transmission
Protocol
FC-0
Interface /Media
Physical Char acteristics
Single Mode Fiber / Multimode Fiber / Copper
Couches du protocole Fibre Channel
Les trois couches basses FC-0, FC-1 et FC-2 se rapportent au transport physique Fibre
Channel (FC-PH).
La couche FC-0 définit le support et l'interface physique : bien que la fibre optique ne soit pas
exclusive pour le SAN, on ne considèrera que cette possibilité, la plus répandue aujourd'hui.
Au niveau physique FC-0, Fibre Channel spécifie la transmission à 100, 200 et 400 Méga
Octets par seconde sur fibres optiques multimodes ou monomodes.
CRESTA Guillaume
Page XXI
Fibre Optique M onomode
Gaine
125µ
Fibre
9µ
Fibre Optique M ultimode
Gaine
125µ
Fibre
50µm ou 62.2µm
Schématisation des fibres
Le tableau suivant donne la distance maximale entre deux équipements reliés en Fibre
Channel, en fonction du type de fibre optique et du type d'onde optique (ce dernier est
déterminé par le type d'adaptateur GBIC utilisé) , ou SFP (Small Form Factor Pluggable).
Type d'ondes
optiques
Diamètre
Distance
Distance
Distance
interne
maxi 1Gb/s
maxi 2Gb/s
maxi 4Gb/s
Fibre multimode
62,5µ
300 mètres
150 mètres
70 mètres
Fibre multimode
50 µ
500 mètres
300 mètres
150 mètres
Fibre monomode
9µ
10 Km
10 Km
10 Km
Type de fibre
Ondes courtes
(Shortwave-SW)
rouge 780/850 nm
Ondes courtes
(Shortwave-SW)
rouge 780-850 nm
Ondes longues
(Longwave-LW)
Infra-Rouge 1300 nm
Caractéristiques des fibres
CRESTA Guillaume
Page XXII
Chaque lien FC est constitué de deux fibres (une par sens de transmission) en général dotées
de connecteurs mâles SC (1Gb) ou LC (2/4Gb) aux extrémités. Les deux types de connecteurs
sont de dimensions différentes, ne se remplacent pas et ne s'interconnectent pas
physiquement.
Types de connecteur Fibre Channel
La couche FC-1 définit les modes de codage/décodage du protocole de transmission
(8B/10B). Un transcodage 8bits/10bits est fait de manière à garantir un équilibrage entre le
nombre de 0 et de 1 dans un flux de données quelconque (synchronisation aussi des décodeurs
HW).
La couche FC-2 définit la signalisation et le format des trames Fibre Channel.
Trame Fibre Channel
Dans un réseau SAN Fibre Channel, chaque composant est identifié par un nom unique de 16
caractères (64 bits), appelé "World Wide Name" (WWN). Celui-ci est affecté par son
constructeur, à qui une autorité (l'IEEE) attribue une plage de noms, afin de garantir l'unicité.
Le format des "WWN" est le suivant :
CRESTA Guillaume
Page XXIII
10:00
xx:xx:xx
Format N° Société
yy:yy:yy
Composent
10:00 – Standard
20:00 - Étendu
Format du World Wide Name
NAA bits
FC-PH format name
63-60
IEEE basis for
IEEE Company ID
format
bits 59-36
0001
IEEE
IEEE 803.2 48-bit ID
0010
IEEE extended
0101
IEEE registered name
IEEE
IEEE
company_id
company_id
IEEE
IEEE
company_id
company_id
0110
IEEE registered extended
Normes Fibre Channel
Chaque nœud de réseau SAN et chaque port Fibre Channel de chaque nœud sont dotés d'un
WWN : WWNN pour les nœuds et WWPN pour les ports.
Schématisation du WWNN et WWPN
Par ailleurs, chaque port d'un SAN est identifié par une adresse Fibre Channel (Port ID),
utilisée dans les en-têtes de transmissions afin d'identifier l'origine et la destination. Les
adresses sont codées sur 24 bits, ce qui autorise 16 millions de ports par réseau SAN.
CRESTA Guillaume
Page XXIV
Ces adresses sont allouées dynamiquement :
•
pour les boucles, au cours de la procédure d'initialisation de la boucle,
•
pour les switchs, au moment de la connexion d'un nœud au switch (procédure de Login),
par la fonction Name Server du switch.
Le seul paramètre d'adressage à définir est l'adresse de chaque switch constitué de 8 bits.
Dans un réseau SAN, pour un fabric (constitué de switchs), le choix du chemin entre deux
équipements est calculé automatiquement par les switchs, conformément au standard ANSI
FSPF. FSPF choisit, pour chaque communication, le meilleur chemin en fonction du nombre
de sauts. En cas de défaillance, il permet automatiquement le re-routage par un autre chemin
s'il en existe un. Le re-routage ne prend pas plus d'une seconde. FSPF répartit
automatiquement le trafic sur tous les chemins possibles entre deux équipements. Chaque
connexion emprunte un chemin et un seul pendant toute sa durée.
"Zoning" et "LUN masking" sont des fonctions permettant de restreindre les possibilités de
communication entre équipements au travers d'un SAN. Le zoning permet de découper le
réseau SAN en zones : les communications sont possibles entre équipements à l'intérieur
d'une même zone, impossibles entre zones. Les zones peuvent se chevaucher et sont définies
au niveau des switchs, soit sur la base des ports, soit sur la base des adresses (WWN). Le
LUN masking permet de restreindre la visibilité et l'accès à un volume logique (LUN) d'un
système de stockage au travers d'un SAN pour les serveurs. Il sera défini sur la baie de
disques (ESS) au niveau des IO adaptateurs (IO Bays) de l'ESS, des gateways et au niveau
des cartes IO (FC) des serveurs d'applications.
La couche FC-3 définit des services communs encore en cours de standardisation. La couche
FC-4 définit la façon dont les protocoles de haut niveau (ULP) sont transportés dans un réseau
Fibre Channel. Le mode Fibre Channel est un transport multi protocole qui permet
d'accommoder de nombreux protocoles de haut niveau (SCSI-3, IP, 802.2, ATM.). On a par
exemple les deux cas suivants :
•
Le transport des commandes SCSI-3 sur Fibre Channel : il s'agit du protocole FCP, utilisé
entre un serveur et un système de stockage avec les mêmes fonctions que l'interface SCSI.
•
IP sur Fibre Channel pourrait être utilisé pour transférer des données entre serveurs sur le
réseau SAN ou ultérieurement pour des transferts de données entre unités de stockage. Un
autre exemple est FICON qui est l'utilisation du protocole ESCON (IBM S390) sur Fibre
Channel.
CRESTA Guillaume
Page XXV
A.5 Présentation hardware du switch 24M-1
Le commutateur Sphereon4500 fournit la connectivité Fibre Channel à travers 24 ports fibre
channel ISP (GX_Ports). Les ports du commutateur fonctionnent à 1 ou 2 Gps, et peuvent être
configurer comme :
-
Fabric ports (F_Ports) pour fournir la connectivité directe jusqu’à 24 dispositifs de
fabric switché.
-
Fabric loop ports (FL_Ports) pour fournir une connectivité de boucle et un
attachement fabric pour les dispositifs FC-AL. Chaque FL-Port peut théoriquement
supporter une connexion de 126 dispositifs FC-AL.
-
Expansion ports (E_Ports) pour fournir la connectivité interswitchlink (ISL) pour
relier les routeurs et les switchs.
Voici la vue de face du switch. On peut distinguer, sur la figure, le connecteur Ethernet (1), le
bouton de reset (2), la diode électroluminescente signalant la mise sous tension de l’appareil
(3), la diode électroluminescente signalant une erreur (4), et les 24 émetteurs / récepteurs SFP
(5).
CRESTA Guillaume
Page XXVI
Voici la vue arrière du switch. On peut remarquer sur la figure, le port RS232 de maintenance
(1) et les alimentations réunies avec des ventilateurs internes.
CRESTA Guillaume
Page XXVII
A.6 Présentation hardware du routeur SAN16M-R
Dans cette section, nous allons décrire le routeur de type SAN, le TotalStorage SAN16M-R,
produit Mc Data. Le routeur SAN16M-R contient 16 ports :
-
Douze connecteurs supportent autant des connections fibre channel à 1 ou 2 Gb/sec
que des connections Gigabit Ethernet.
-
Quatre connecteurs SFP pour le support TCP / IP (ports 13-16) supportent TCP/IP
pour le protocole internet Fibre Channel (iFCP) ou des connections Internet small
computer systems interface (iSCSI).
Le routeur supporte iSCSI, iFCP et R-port pour gérer à la fois les connexions de protocole
Internet (IP) et les connexions Fibre Channel (FC). Les routeurs SAN se relient à une
multitude de technologies, incluant Fibre Channel, NAS and iSCSI. Ils supportent Ethernet et
la commutation Fibre Channel sur de longues distances.
Le routeur SAN peut être utilisé pour des applications multiples et concurrentes, incluant le
routage SAN dans les data center (mSAN routing), le routage SAN à travers la distance
(iSAN routing) comme dans le cas du projet « Disaster / Recovery », et l’accès iSCSI pour le
stockage Fibre Channel.
Les routeurs offrent :
-
La compression lorsque la bande passante est trop importante
-
Le support pour les dispositifs Fibre Channel
-
La technologie Patent-pending Fast Write pour maximiser les sorties vers de longues
distances
Deux ports de gestion sont situés sur la face avant du routeur SAN. Un port série RS-232 peut
permettre de connecter un VTA00 ou un émulateur terminal pour accéder à l’interface des
CRESTA Guillaume
Page XXVIII
lignes de commande, et un port RJ45 pour pouvoir connecter un outil de management sur un
réseau LAN à travers le SAN Router Element Manager et le SANvergence Manager.
La gestion du port peut être atteinte par n’importe quelle station du réseau LAN en utilisant
http et SNMP pour le management.
Sur la figure, on peut distinguer les ports FC/GE (1), la connexion de la console RJ-232 (2), la
diode électroluminescence pour le status des ports (3), les ports FC/GE de 1 à 8 (4), la diode
électroluminescence pour le statut du système (5), la diode électroluminescence pour le statut
du port de management (6), le connecteur LAN/ Ethernet RJ-45 (7), et les ports iFCP/ iSCSI
de 13 à 16 (8).
CRESTA Guillaume
Page XXIX
A.7 Présentation du spirent
The AX/4000 Gigabit Ethernet NetworkImpairment Emulator (GENIE) permet de simuler
une liaison d’un point de vue communication afin de tester et d’évaluer les performances de
matériel et de logiciel jusqu’à la limite que peut supporter la ligne Gigabit Ethernet.
Le GENIE peut également être utilisé pour examiner les performances de n’importe quelle
application à travers un réseau tel qu’Internet. Une autre utilisation significative du spirent
peut être de déterminer les conditions minimales Service Level Agreement (SLA) pour une
application ou un service. Ceci peut être établi par la prise en compte des délais, des erreurs,
des pertes de trame dans le but de déterminer les conditions minimales d’acceptation.
Le simulateur, SPIRENT AX/4000, est capable d’ajouter de la latence (de 30 microsecondes à
485 milliseconds) ; la vitesse de la lumière dans une fibre est d’environ 66 % de la vitesse de
la lumière dans le vide (300000 km/sec) ce qui signifie environ 200000 km/sec. Donc le délai
à l’aller pour effectuer 100 km est de 0,5 msec et à l’aller retour entre les deux sites, il est
théoriquement d’une milliseconde.
Le tableau suivant permet de connaître la latence à configurer dans le logiciel afin de simuler
la distance.
CRESTA Guillaume
Distance en kilomètres
0
5
10
20
50
100
200
300
1000
7000 (Mop – Pok)
Page XXX
Latence en milliseconde
0
0,025
0,05
0,1
0,25
0,5
1
1,5
5
35
Afin de régler la latence, on dispose d’un logiciel dont voici l’interface de management du
spirent.
CRESTA Guillaume
Page XXXI
A.8 Script Global Mirror effectué
#Site_A (Mop): IBM. WWNN-source_...: 210000e08b05babf LSS: 47 vol 4700
#Site_B (Mop): IBM. WWNN-source_...: 210000E08B0A5853 LSS: 11 vol 1100 / LSS
: 13 vol 1300
#Forme infrastructure du Global Copy(from site_A (Mop) HMC)
mkpprcpath -remotewwnn 210000E08B0A5853 -srclss 47 -tgtlss 11 –consistgrp ports_dispo
# Crée paths PPRC
lspprcpath -fullid 47 # Liste PPRC Paths sur le volume 47
mkpprc -type gcp -mode full -tgtread 4700:1100 # Crée les Global Copy pairs
lspprc 4700:1100 # Vérification du status de la relation Global Copy et vérifier l’évolution
#Etablit infrastructure du Flash Copy (du site_B (Pok) HMC)
mkflash -record -persist -nocp -seqnum D0D0 1100:1300 # Création de la relation Flash Copy
lsflash -l 1100:1300 # Permet la vérification
#Ouvre gmir session NOM_SESSION pour lss 47 (du site_A (Mop) HMC)
mksession -lss 47 -volume 4700 Nom_session # Crée une session Global Mirror sur lss 47
lssession 47 # permet de visualiser le statut des volumes
# Démarrage de la session gmir NOM_SESSION (du site_A (Mop) HMC)
mkgmir -lss 47 -session Nom_session # commence la session Global Mirror
showgmir -metrics 47 # Montre les status Global Mirror et permet de montrer les messages
d’erreur
showgmir -fullid 47 # Vérification du status de la session
#Analyze FC sequence numbers (from SITE_B (Pok) HMC)
lsflash –l 8000:1300 # Permet la verification du Flash Copy
#Pause / rédémarrage de la session gmir NOM_SESSION (à partir de la HMC du site_A
(Mop))
pausegmir -lss 47 -session Nom_session # Permet de stopper la session
resumegmir -lss 47 -cginterval 60 -session Nom_session # modification de l’Interval time et
de redémarrer la session
pausegmir -lss 47 -session Nom_session # Permet de stopper la session
#Analyse les FC sequence numbers (à partir de la HMC du site_B (Mop))
lsflash -l 1100:1300 # Permet la verification du Flash Copy
# Génération et analyse (à partir de la HMC du site_A (Mop))
resumegmir -lss 47 -session Nom_session # Redémarre la session
showgmir -metrics 47 #Montre les status Global Mirror et permet de montrer les messages
CRESTA Guillaume
Page XXXII
freezepprc 47:80 # Arret du pprc
lssession 47 #vpermet de visualiser le statut des volumes
#Analyse les status des volumes FC (à partir de la HMC du site_B (Mop))
lsflash -l 1100:1300 # Permet la verification du Flash Copy
#Failover B à A (à partir de target HMC)
failoverpprc -type gcp 1100:4700 # ??
# Etablissement des données consitantes sur le site B. Flash renversé avec une copie de
background
lsflash 1100:1300 # Permet la verification du Flash Copy
lsflash 1300:1100
reverseflash 1300:1100 # 1100:1300 plutot ; Copie de sauvegarde de C vers B
lsflash 1300:1100 # Permet de verifier que le background copy est terminé
#Réétablit les relations FC entre B et C (à partir de la HMC du site_B (Mop))
lsflash 1100:1300
mkflash -record -persist -nocp -seqnum DADA 1100:1300 # Création de la relation Flash
Copy
#Préparation au retour au site primaire (à partir de la HMC du site B)
lsavailpprcport -l -remotewwnn 210000e08b05babf 11:47 port:port # Détermination des liens
fibre disponibles
mkpprcpath -remotewwnn 210000e08b05babf -srclss 11 -tgtlss 47 port:port # Crée PPRC
paths
lspprcpath -fullid 11
# Liste PPRC Paths sur le volume 11
failbackpprc -type gcp 1100:4700 # Permet de resynchronisser les changements de B vers A
#Retour au site local (Site A (Mop))
lsavailpprcport -l -remotewwnn 210000E08B0A5853 47:11 # Détermination des liens fibre
disponibles
mkpprcpath -remotewwnn 210000E08B0A5853 -srclss 47 -tgtlss 11 -consistgrp port:port #
Crée paths PPRC
CRESTA Guillaume
Page XXXIII
failoverpprc -type gcp 4700:1100 # Permet de retourner au statut Global Copy de départ
#Analyze FlashCopy status (from site_B (Pok) HMC)
#Rédemarrage des activités Global Mirror (à partir de la HMC du site_A (Mop))
# Arrêt du Global Mirror (à partir de la HMC du site_A (Mop))
pausegmir -lss 47 -session NOM_SESSION # permet de mettre en pause précisant le LSS ID
et la session ID
chsession -lss 47 -action remove -volume 4700 NOM_SESSION # Permet de supprimer le
volume 4700 de la session Global Mirror sur ce LSS
rmsession -lss 47 Nom_session # Cloture la session Global Mirror
#Arrêt des activités de Global Copy (à partir de la HMC du site_A (Mop))
rmpprc -quiet 4700:1100 # Suppression Global Copy pairs
rmpprcpath -quiet 47:11 # Supprime les paths PPRC
#Arrêt des activités de FlashCopy (à partir de la HMC du site_B (Pok))
rmflash -quiet 1100:1300 # Suppression de la session Flash Copy
CRESTA Guillaume

Stage à IBM Montpellier - Guillaume CRESTA

Transcription

Documents pareils

ibm tivoli storage manager 7.1 mise en œuvre et administration

plaquettev2.ppt [Read-Only] - Les Documents d`Info-Com

ALSO et IBM présentent les serveurs parfaits pour les PME suisses

CV Version PDF - Na

CV - WordPress.com

Storage Manager for System Backup and Recovery (SysBack)

ITSM V5.3.2 Administration

Stage Ingénieur: Développement Logiciel Embarqué

http://www.ed-diamond.com http://www.gnulinuxmag.com http://www