Upload
dinhanh
View
216
Download
0
Embed Size (px)
Citation preview
Mise en œuvre d’un Call Center Réponse à l’appel d’offre
BAILLY-MASSON Pauline
GILLERY Thomas
SIMONIN Jordan
BOULLAY Jean-Marie
ROCHETTE Mathieu
Master II IRS P18 université de Versailles 2014-2015
2 Dossier d’architecture technique
Sommaire
I. Call Center ________________________________________________________________________ 3
1. Protocole SIP _____________________________________________________________________ 3
A. Présentation ___________________________________________________________________ 3
B. Avantages de SIP _______________________________________________________________ 3
C. Appel SIP : Transaction de base ____________________________________________________ 3
D. Architecture SIP ________________________________________________________________ 5
2. Qualité de service et VOIP __________________________________________________________ 5
A. Eviter la « Perte de paquets » _____________________________________________________ 5
B. Limiter la « Latence » ____________________________________________________________ 6
C. Un paramètre essentiel : La Gigue __________________________________________________ 7
D. La Bande Passante ______________________________________________________________ 7
E. L’Echo ________________________________________________________________________ 7
3. Haute Disponibilité du Call Center ____________________________________________________ 8
II. Réseau LAN _______________________________________________________________________ 10
1. Spanning Tree ___________________________________________________________________ 10
A. Fonctionnement de STP _________________________________________________________ 10
B. Etats de STP __________________________________________________________________ 10
2. Cisco StackPower ________________________________________________________________ 12
3. VTP ___________________________________________________________________________ 15
4. Qualité de Service ________________________________________________________________ 15
A. Qualité de Service Niveau 2 ______________________________________________________ 15
B. Qualité de Service Niveau 3 - DiffServ ______________________________________________ 16
III. Sauvegarde de l’infrastructure ______________________________________________________ 18
IV. Supervision de l’infrastructure ______________________________________________________ 21
1. Les intérêts de la supervision _______________________________________________________ 21
2. Distribution solution supervision ____________________________________________________ 21
3. Vues des différentes interfaces web _________________________________________________ 22
3 Dossier d’architecture technique
I. Call Center
1. Protocole SIP
A. Présentation
Protocole de couche d’application (RFC 3261 – juin 2002)
o MMUSIC ( Multiparty Multimedia Session Control)
o Crée, modifie, termine une session
o Deux participants ou plus
o C’est une application Client-Serveur
Protocole multimédia
o On distingue la voix et le multimédia
o Jeux en réseau
o Chat Messagerie Instantanée
o Réalité virtuelle
B. Avantages de SIP
Localisation de l’utilisateur :
o L’adresse SIP est un URI de la forme (sip:utilisateur@adresse, tel@domaine).
o Ex: sip:[email protected], ou sip:[email protected], ou sip:[email protected]
Arbre de recherche:
o Pour atteindre plusieurs points simultanément ou en séquence : forking
o En fonction de l’heure, du jour, de l’interlocuteur
XML jouera un rôle de plus en plus important :
o Call processing language CPL
o Information de présence : Présence Protocol
o Configuration des équipements, annuaire
o Future version de SDP
o Services proxy
C. Appel SIP : Transaction de base
5 Dossier d’architecture technique
D. Architecture SIP
2. Qualité de service et VOIP Les paramètres de qualité de service reposent pour la plupart sur des calculs simples permettant d’obtenir
une durée cumulée exprimé en ms (millisecondes) que l’on pourra évaluer en fonction des seuils de qualité
connus.
Les trames sont stockées dans un buffer de gigue dont la taille est généralement limitée à 5-8 trames. Chaque
constructeur a le loisir de choisir son propre paramètre par défaut dans ses équipements réseaux. Il est de
coutume de ne pas dépasser la valeur de 8 trames afin d’avoir un fonctionnement optimale (pertes de
paquets limités etc).
Le Framing correspond au délai inter trame qui est généralement de 30ms par défaut.
La latence idéale pour un confort de voix sur IP optimale doit être comprit entre 150ms et 300ms.
On obtient ainsi un délai de transmission de 240ms (8*30ms) dans un cas d’utilisation standard avec un buffer
de gigue contenant 8 trames et respectivement 150ms avec 5 trames.
Il faut également prendre en considération la valeur de la gigue et la valeur de la latence induite par le choix
du codec et donc implicitement la taille de trame émise.
La valeur recommandée pour la gigue en VoIP doit être inférieur à 5ms.
La valeur recommandée pour la perte de paquet en VoIP doit être inférieur à 1%.
A. Eviter la « Perte de paquets » Indéniablement, avec l’emploi du protocole UDP qui ne garantit pas la livraison des paquets, des pertes de
paquets sont possibles.
Si aucun mécanisme performant de récupération des paquets perdus n'est mis en place (cas le plus fréquent
dans les équipements actuels), alors la perte de paquet IP se traduit par des ruptures au niveau de la
6 Dossier d’architecture technique
conversation et une impression de hachure de la parole. Cette dégradation est bien sûr accentuée si chaque
paquet contient un long temps de parole.
Au-dessus de 5 % de perte, des rafales de pertes de paquets rendent l’écoute incompréhensible. On
constate en effet une dégradation inacceptable de la qualité de service de la VoiP. Ainsi, le choix d’un codec
approprié permet de réduire considérablement cet effet indésirable.
Il est donc préférable de distribuer périodiquement dans le temps ces pertes de paquets afin de réduire cet
effet indésirable. Avec des codeurs de parole de type G.711 des pertes de paquets inférieures à 1 ou 2 %
permettraient d’obtenir une qualité de service égale à celle de la téléphonie classique. Ces valeurs
concernent des équipements en bon état et un écoulement de trafic raisonnable.
Enfin connaître le pourcentage de perte de paquets sur une liaison n'est pas suffisant pour déterminer la
qualité de la voix que l'on peut espérer, mais cela donne une bonne approximation. En effet, un autre facteur
essentiel intervient; il s'agit du modèle de répartition de cette perte de paquets, qui peut être soit «
régulièrement » répartie, soit répartie de manière corrélée, c'est à dire avec des pics de perte lors des
phases de congestion, suivies de phases moins dégradées en terme de QoS.
La plupart du temps, ces pertes de données VoiP sont dues aux congestions sur le réseau, qui entraînent des
rejets de paquets durant la transmission, ou à une gigue excessive qui va provoquer des rejets de paquet
dans les buffers de gigue des différents équipements. Une perte de données régulière mais faible est moins
gênante en VoiP que des pics de perte de paquets espacés mais élevés. En effet l’écoute humaine s’habituera
à une qualité moyenne mais constante et en revanche supportera peu de soudaines dégradations de la
qualité de communication.
B. Limiter la « Latence » Le délai de transit « Latence » est un des paramètres les plus critiques influençant fortement l’usage de la
QoS pour l’utilisation de la VoiP. Il s’agit du temps moyen de propagation d’un paquet IP contenant un
échantillon de voix entre l’émetteur et le récepteur.
Toutefois, de nombreux facteurs peuvent faire varier le taux de latence.
Ce temps de transit comporte quatre composantes :
Le délai d’échantillonnage
Le délai de propagation
Le délai de transport
Le délai des buffers de gigue
Le délai d’échantillonnage est la durée de numérisation de la voix à l’émission puis de conversion en signal
voix à la réception. Ce temps dépend du type de codec utilisé coté émetteur et récepteur. C’est une des
raisons pour laquelle le choix du codec impacte le résultat MOS d’appréciation de la clarté de la voix,
indépendamment des autres caractéristiques de l’infrastructure.
Le délai de propagation est la durée de transmission en ligne des données numérisées sur le support de
communication. Cette durée est normalement très faible par rapport aux autres composantes du délai de
transit, de l’ordre de quelques millisecondes, mais peut varier selon le type de support, interférence ou autre.
Le délai de transport est la durée passée à traverser les équipements intermédiaires tels que routeurs,
switch, etc, composant l’infrastructure de téléphonie IP. L’ordre de grandeur est de plusieurs dizaines de
millisecondes, voir centaines de millisecondes.
7 Dossier d’architecture technique
Le délai des buffers de gigue est le retard volontairement introduit par un équipement à la réception en vue
de lisser la variation de temps de transit, et donc de réduire la gigue de phase. L’ordre de grandeur est de 50
ms.
La latence idéale pour un confort optimal de la voix sur IP doit être comprise entre 150 ms et 300ms.
Un problème de latence sur un réseau VoiP est souvent perçu comme une « voix en mode tunnel ».
C. Un paramètre essentiel : La Gigue La variation de temps de transit, est la conséquence du fait que tous les paquets contenant des échantillons
de voix ne vont pas traverser le réseau à la même vitesse, c’est l’une des grandes particularités d’un réseau
IP. Cela crée par conséquent une déformation de la voix ou un hachage.
La gigue est indépendante du délai de transit. Le délai peut être court et la gigue importante ou inversement.
La gigue est une conséquence de congestions temporaires sur le réseau, celui-ci ne pouvant plus transporter
les données de manière constante dans le temps.
Pour compenser ce phénomène de gigue, nous utiliserons des mémoires tampon (buffer de gigue) qui
permettent de lisser l'irrégularité des paquets. Leurs tailles doit donc être soigneusement définie, et si
possible adaptée de manière dynamique aux conditions du réseau.
La dégradation de la qualité de service due à la présence de gigue, se traduit en fait, par une combinaison
des deux facteurs cités précédemment: le délai et la perte de paquets; puisque d'une part on introduit un
délai supplémentaire de traitement (buffer de gigue) lorsque l'on décide d'attendre les paquets qui arrivent
en retard, et que d'autre part on finit tout de même par perdre certains paquets lorsque ceux-ci ont un
retard qui dépasse le délai maximum autorisé par le buffer.
La gigue est le paramètre le plus sensible à la détérioration de la qualité de la voix dans un réseau VoiP. Elle
est généralement descellée par l’écoute des communications avec le ressenti d’une « voix
métallique/robotique ».
D. La Bande Passante La bande passante représente la quantité d’informations (en bits/s) qui peut être transmise sur une voie de
transmission. Ce critère doit être étudié et adapté lors de la mise en place d’une infrastructure réseau. C’est
sur ce paramètre que la majorité de la qualité de la transmission va se jouer. De plus, il est parfois difficile et
souvent couteux de la modifier, car elle peut entrainer toute une modification de l’architecture.
Cette bande passante sera donc dimensionnée en amont afin de répondre au mieux à vos attentes et
implémentera les mécanismes de QoS afin d’avoir un débit suffisant pour l’ensemble des communications
effectuées.
E. L’Echo Le phénomène d’écho est désagréable, car le locuteur s’entend parler avec un décalage dans le temps qui
ressemble à un écho. Ceci peut l’interrompre ou le faire bégayer. Il n’est pas facile de régler le problème
d’écho en VoIP avec des suppresseurs d’écho classiques. De plus, de nombreux équipements réseaux (borne
Wifi, DECT etc) peuvent générer des échos qui seront sensibles aux communications de type VoiP.
Afin d’améliorer le confort d’écoute à la réception, il est nécessaire de restituer « un silence de confort »
au destinataire afin de lui donner une sensation de « présence lointaine » de son interlocuteur.
8 Dossier d’architecture technique
Il sera donc nécessaire de réaliser différents tests d’implémentation de suppresseur d’échos afin de trouver
le meilleur compromis pour votre implantation car la mise en cascade de suppresseurs d’écho peut rendre
une communication inaudible à défaut de l’améliorer.
Enfin après avoir configuré l’ensemble de ces paramètres spécifiquement en fonction de votre liaison WAN,
vos équipements et vos attentes nous réaliserons avec vous une recette dans différentes conditions
simulées (sans charge réseau, avec charge constante et avec des rafales de charge) afin de valider la bonne
implémentation de la qualité de service perçue durant ces différents scenarios.
3. Haute Disponibilité du Call Center
10 Dossier d’architecture technique
II. Réseau LAN
1. Spanning Tree Le protocole Spanning Tree est un protocole de couche 2 qui a pour objectif principal de vérifier qu’il n’y a
pas de création de boucles réseaux lorsque qu’il y a création de chemins redondants dans le réseau.
Le fonctionnement de STP est basé sur la sélection d’un switch root et de calculs des chemins les plus courts
vers ce switch. Les ports des switch peuvent prendre 5 états dont le Blocking qui empêche la transmission
des trames et Forwarding qui permet le transfert des trames de données.
A. Fonctionnement de STP Une topologie physique redondante permet de fournir de multiples chemins permettant l’amélioration de la
fiabilité d’un réseau. Toutefois, elle présente le désavantage de créer des boucles dans le réseau. Pour
résoudre ce problème, STP crée au sein de cette topologie redondante un chemin sans boucle basé sur le
chemin le plus court. Ce chemin est établi en fonction de la somme des coûts de liens entre les
commutateurs. Ce coût est une valeur inverse à la vitesse d'un port, car un lien rapide aura un coût moins
élevé qu'un lien lent. Aussi, un chemin sans boucle suppose que certains ports soient bloqués et pas d'autres.
STP échange régulièrement des informations (appelées des BPDU - Bridge Protocol Data Unit) afin qu'une
éventuelle modification de topologie puisse être adaptée sans boucle.
1. Sélection d'un commutateur Root
Le commutateur Root (principal) sera le point central de l'arbre STP. Le choix de celui-ci dans l'architecture
du réseau peut avoir son importance. Toutefois, une bonne pratique consistera à limiter la taille des
domaines de diffusion et à concentrer géographiquement les VLANs.
Sur un commutateur Root, tous les ports sont des ports Designated, autrement dit, ils sont en état «
forwarding », ils envoient et reçoivent le trafic.
2. Sélection d'un port Root pour les commutateurs non-Root.
Les autres commutateurs vont sélectionner un seul port Root qui aura le chemin le plus court vers le
commutateur Root. Normalement, un port Root est en état « forwarding », également.
3. Sélection d'un port désigné pour chaque segment
Pour chaque segment physique, domaine de collision ou lien, il y a un port Designated. Le port Designated
est celui qui a le chemin le plus court vers le commutateur Root. Un port Designated est normalement en
état « forwarding », autrement dit, envoie et reçoit du trafic de données.
Tous les autres sont des ports Non-Designated en état « blocking », c'est-à-dire bloquant tout trafic de
données mais restant à l'écoute des BPDU.
B. Etats de STP Cinq états de ports peuvent être rencontrés consécutivement sur un port avant que STP ait convergé. Chaque
état comporte un délai qui varie en fonction de la version de STP utilisée sur le commutateur Cisco. En voici
les propriétés.
11 Dossier d’architecture technique
Le compteur "âge maximum" (Max Age) de 20 secondes par défaut est le temps maximal avec que STP
effectue de nouveaux calculs quand une interface ne reçoit plus de BPDUs. Le temps de "forwarding" de 15
secondes par défaut est le temps de passage d'un état "listening" à "learning" et de "learning" à "forwarding".
Bref, une topologie peut prendre jusqu'à 50 secondes avant de converger et de transférer du trafic. Aussi, la
fréquence d'envoi de BPDUs Hello est de 2 secondes par défaut.
Etat « Blocking »
Rejette toutes les trames de données venant du segment attaché
Rejette toutes les trames de données venant d'un autre port de transfert
N'intègre aucun emplacement de station dans sa MAC table (il n'y pas d'apprentissage)
Reçoit les BPDUs et les transmet à son système
N'envoie pas de BPDUs reçus de son système
Répond à SNMP
Etat « Listening »
Rejette toutes les trames de données venant du segment attaché
Rejette toutes les trames de données venant d'un autre port de transfert
N'intègre aucun emplacement de station dans sa MAC table (il n'y pas d'apprentissage)
Reçoit les BPDUs et les transmet à son système
Envoie les BPDUs reçus de son système
Répond à SNMP
Etat « Learning »
12 Dossier d’architecture technique
Rejette toutes les trames de données venant du segment attaché
Rejette toutes les trames de données venant d'un autre port de transfert
Intègre les emplacements de station dans sa MAC table (apprentissage)
Reçoit les BPDUs et les transmet à son système
Envoie les BPDUs reçus de son système
Répond à SNMP
Etat « Forwarding »
Commute toutes les trames de données venant du segment attaché
Commute toutes les trames de données venant d'un autre port de transfert
Intègre les emplacements de station dans sa MAC table (apprentissage)
Reçoit les BPDUs et les transmet à son système
Envoie les BPDUs reçus de son système
Répond à SNMP
Etat « Disabled »
Cet état est similaire à l'état « blocking » sauf que le port est considéré physiquement non
opérationnel (shut down ou problème physique).
2. Cisco StackPower La technologie Cisco StackPower est une fonctionnalité innovante qui permet de regrouper toute la puissance
électrique disponible pour une pile de switchs et la gérer de manière commune pour l’ensemble de la pile.
C’est l'une des principales fonctionnalités introduites dans les commutateurs Cisco Catalyst 3750-X Series.
Les avantages de la technologie Cisco StackPower sont immédiatement visibles ainsi que les économies
associées.
En considérant une pile de switchs avec chaque switchs nécessitant une puissance légèrement plus élevée
pour certains dispositifs (PoE par exemple) dispersés au hasard dans la pile. L’achat d’une seconde
alimentation supplémentaire pour chaque commutateur qui nécessite plus de puissance serait inefficace et
coûteux. Avec la solution Cisco StackPower, un pool commun de puissance est disponible et la puissance
supplémentaire peut être automatiquement redirigée vers le switch approprié sur la base de la puissance
disponible dans le pool d'alimentation commune.
Cisco StackPower produit immédiatement des économies en réduisant le nombre de blocs d'alimentation
requis par switchs et le nombre de prises électriques nécessaires. Cisco StackPower permet d’effectuer des
économies supplémentaires en minimisant les pertes d'énergies due à l'inefficacité du fonctionnement des
alimentations à des charges réduites ainsi qu’en réduisant les besoins en climatisation. Cisco StackPower
élimine également la nécessité de disposer d’emplacements dédiés pour les prises électriques, libérant ainsi
de l'espace et des prises électriques supplémentaires dans la baie.
13 Dossier d’architecture technique
Cisco StackPower offre les avantages supplémentaires suivants:
Abstraction des emplacements des blocs d’alimentation électrique de leurs emplacements physique
permettant une meilleure utilisation de la puissance électrique disponible
Maximise l’efficacité des alimentations, la puissance électrique disponible est agrégée et permet aux
équipements de fonctionner avec une efficacité optimale tout en réduisant considérablement le
gaspillage électrique.
Fournir ou compléter la puissance nécessaire pour le PoE à n’importe quel port de la pile
Permet de disposer d’une infrastructure PoE évolutive
Offre une architecture de pay-as-you-grow, similaire à la technologie Cisco StackWise®
Permet d’améliorer la fiabilité, la disponibilité ainsi que l’efficacité avec le module Power System
(XPS) jusqu’à 9 switchs
Offre une plus grande redondance
Permet la mise hors circuit d’alimentations électrique lorsqu’une capacité supplémentaire est
disponible dans le système
Diminue le TCO en réduisant le nombre d’alimentations électriques nécessaires, les nombres
d’équipements, la quantité de chaleur à dissipé ainsi que les nombres de prises électriques
Fonctionnement de StackPower
Les switchs faisant partie du power stack se découvre les uns les autres et échangent des messages pour
connaitre combien de puissance électrique est disponible au sein de la pile (power budget) et fixer des
priorités (ou utiliser celles par défauts) puis démarrer l’IOS Cisco sur chaque switch en fonction de la
puissance électrique disponible.
La séquence de démarrage est la suivante:
1. Les switchs sont connectés en anneau et la puissance électrique est appliquée.
2. Tous les switchs mettent sous tension leur infrastructure Stack Puissance
3. Tous les switchs membre du power stack échangent des paquets de découverte ainsi que des
messages d’informations concernant les ressources électriques et les priorités.
4. Le budget total électrique disponible pour le power stack est découvert
5. Le power stack réserve 30W en cas de nouveau membre ajouté dynamique à la pile. Cette puissance
est réservée une fois pour tout le stack et non par switch.
6. Les budgets sont répartis en fonction du power budget total, des exigences de puissance et des
priorités de chaque switch.
7. Les switchs qui ont reçus une allocation de puissance procèdent au démarrage de leur IOS
8. Les switchs qui n’ont pas reçu une allocation de puissance resteront dans la pile d'alimentation sans
démarrer jusqu'à qu’il y ait de la puissance ajouté au power budget.
Exemple d’utilisation du PowerStack :
14 Dossier d’architecture technique
Les switchs A, B, C, et D ont la configuration et les puissances suivantes :
Le switch A nécessite 946W pour fournir du PoE sur les 48 ports. Il dispose d’une seule alimentation
de 1100W. La puissance supplémentaire disponible est de 154W.
Le switch B nécessite 206W. Il dispose d’une seule alimentation de 350 W. La puissance
supplémentaire disponible est de 144W.
Le switch C nécessite 1646W pour fournir 1440W de PoE+ sur les 48 ports. Il dispose d’une
alimentation de 1100 W et d’une seconde de 715W. La puissance supplémentaire disponible est de
169W.
Le switch D nécessite 576W pour fournir du PoE sur une partie de ses ports. Il dispose d’aucune
alimentation et nécessite une puissance de 576W.
Ces switchs ont été câbles de façon à former un power stack pour profiter de la puissance électrique non
utilisée par certains switchs. Il s’agit d’un des avantages principaux de la technologie StackPower de pouvoir
utiliser les ressources disponibles de manières flexibles.
Résumons le scenario:
Exigences d'alimentation pour la pile d'alimentation
Switches A, B, C, D = 946W+206W + 1646W+ 576W =3374W
Puissance disponible dans le pool du power stack
Switches A, B, C, D = 1100W+ 350W+1100W+715W = 3265W
Puissance manquante = -109W
Bien que le power stack de l’exemple dispose de capacités supplémentaires allant dans le pool de puissance,
il n’est pas suffisant pour alimenter le switch D ainsi que les équipements PoE qui lui sont connectés. Pour
que la pile de switch fonctionne dans son ensemble et pour avoir un power budget positif, il faut ajouter de
la puissance dans le stack. Une alimentation de 350W permettrait de résoudre le problème et devra être
ajoutée dans le slot A du switch D (selon les « Best Practices »). Avec l’ajout d’une alimentation de 350W,
nous disposons maintenant d’un power budget positif et disposons de 241W supplémentaire dans le cas où
les switch B ou D demanderait plus de puissance.
15 Dossier d’architecture technique
Cisco StackPower nous permet la possibilité de partager et rediriger le surplus de puissance du switch C vers
le switch D qui ne dispose d’aucune alimentation. Notons que le Switch D pourra démarrer même sans
alimentation grâce au StackPower qui lui alloue et lui redirige de l’énergie.
Cisco StackPower permet aussi d’avoir la capacité de fournir de la redondance sans ajouter d’équipements
supplémentaires. En ajoutant une alimentation électrique de 1100W dans n’importe lequel des slots
d’alimentation disponibles du power stack, il est possible de configurer une réserve de puissance en cas de
panne d’une des alimentations de la pile. Cette technologie est appelle Zero-Footprint RPS.
3. VTP VTP est un protocole propriétaire Cisco qui permet de centraliser la gestion des VLAN au niveau d’un seul
équipement. Lorsqu’un VLAN est créé sur le switch maitre VTP, ce VLAN est propagé sur l’ensemble des
switchs clients VTP.
VTP fonctionne dans un de ces 3 modes :
Serveur
Client
Transparent
Les administrateurs peuvent changer les informations de VLAN sur les switchs fonctionnant en mode serveur
uniquement. Une fois que les modifications sont appliquées, elles sont distribuées à tout le domaine VTP au
travers des liens trunks (au sens Cisco). En mode transparent, le switch reçoit les mises à jour et les transmet
à ses voisins sans les prendre en compte. Sur les switchs en mode transparent, on peut créer, modifier ou
supprimer ses propres VLAN mais ils ne sont pas transmis. Les switchs en mode client appliquent
automatiquement les changements reçus du domaine VTP.
VTP permet de gérer les VLAN de la plage « normale » (VLAN ID compris entre 1 et 1005). La création de
VLAN dans la plage étendue (VLAN ID supérieur à 1005) n'est possible qu'en mode VTP transparent.
Les configurations VTP successives du réseau ont un numéro de révision. Si le numéro de révision reçu par
un switch client est plus grand que celui en cours, la nouvelle configuration est appliquée. Sinon, elle est
ignorée.
4. Qualité de Service
A. Qualité de Service Niveau 2 La qualité de service au niveau 2 s’implémente au niveau du champ CoS (Class Of Service – 802.1p) sur les
équipements de type switch. Avec les équipements réseau Cisco, la fonction Voice VLAN permet de
configurer ce champ avec la valeur « 5 » pour les paquets provenant d’un VLAN en particulier, le « VOICE
VLAN ». Cette fonctionnalité permet de prioriser les flux du vlan voix par rapport aux autres VLAN n’ayant
pas de trames marquées. Le Voice VLAN est particulièrement utile dans le cas où l’IP Phone dispose d’un
micro-switch pour connecter le poste utilisateur, le port du switch d’accès recevant à la fois du trafic voix et
données.
16 Dossier d’architecture technique
B. Qualité de Service Niveau 3 - DiffServ Differentiated Services est une architecture de réseau qui spécifie un mécanisme pour classer et contrôler le
trafic pour permettre de fournir de la qualité de service (QoS) en différenciant les services des données.
DiffServ doit être implémenté sur l’ensemble des routeurs du réseau géré pour garantir le fonctionnement.
La gestion des priorités du trafic est effectuée par le mécanisme appelé per-hop behaviour (PHB) qui
s'effectue selon les différents type de flux (VOIP, multimédia...).
Le PHB est déterminé par la valeur des six bits du champ Differentiated Services Code Point (DSCP) de l'en-
tête IP. Par défaut le PHB est en priorité minimum (best-effort) et peut aller jusqu'au real-time (temps réel).
La RFC 4594 met en avant douze classes d'application qui correspondent aux PHB défini par les RFC. Ces
classes d'application et PHB recommandées sont résumées dans la figure ci-dessous.
Pour l’implémentation du Call Center, nous utiliserons les classes suivantes :
VOiP Telephony pour les appels VoiP
Call Signaling pour la signalisation liée aux appels VOiP
Low Latency Data pour les flux générés par les applications métiers critiques (gestion via xCally, CRM)
Best Effort pour les flux qui ne seront pas priorisés.
Traffic Data Non taggé Traffic Data Non taggé
Traffic Voix taggé
IP Phone avec marquage VLAN 20 pour les paquets VOIX
Switch avec Voice VLAN activé pour le VLAN 20 permettant de prioriser les
trames de ce VLAN
17 Dossier d’architecture technique
Pour configurer DiffServ sur un réseau, les étapes suivantes doivent être effectuées :
Filtrage des flux : utilisation d’ACL pour identifier les flux (adresses IP sources et destinations,
protocoles, numéros de ports)
Classification des flux : création de classes (class-map) en fonction des ACL ou d’un PHB déjà présent)
Création d’une politique de service : création de politiques (policy-map) permettant de définir des
PHB pour des classes de trafic (marquage) ou pour indiquer une action (réservation de bande
passante, priorisation, type de file d’attente) pour un certain PHB
Attachement des politiques aux interfaces : application des politiques de service aux interfaces des
routeurs afin qu’elles puissent être utilisées
18 Dossier d’architecture technique
III. Sauvegarde de l’infrastructure
Les plans de sauvegarde locaux reposerons sur le modèle GPF (Grand Père – Père –Fils) pour la plupart des Backups qui consiste à avoir différents exemplaires de sauvegarde de type différents (Complete, Différentielle et Incrémentale) afin d’optimiser les temps d’exécutions des sauvegardes à des tranches horaires définies.
Notre solution VeeaM Backup sera bien entendu capable de sauvegarde l’ensemble des systèmes d’exploitation actuelles (Windows, Unix etc) qui seront héberger sur les hyperviseurs VMware.
Voici un exemple de paramétrage type GPF que nous pourrions mettre en place :
Supposez que les paramètres de GPF soient les suivants : o Démarrer la sauvegarde à : 23:00:00 o Sauvegarder sur : Jours ouvrés o Hebdomadaire/Mensuelle le : Vendredi o Conserver les sauvegardes :
Quotidienne : 2 semaines hebdomadaire : 2 mois mensuelle : 1 année
Le principal but est d'atteindre une automatisation complète de la rotation des sauvegardes pour ces paramètres.
Ces options seront à définir précisément avec vous pour chacun de vos serveurs afin d’avoir une politique de sauvegarde la plus adapté et efficace possible.
Rappelez-vous qu'une sauvegarde mensuelle est complète, qu'une sauvegarde hebdomadaire est différentielle et qu'une sauvegarde quotidienne est incrémentielle dans cette implantation du modèle GPF.
La première sauvegarde est toujours complète. Ainsi si la politique/le plan de sauvegarde commence le mercredi et si des sauvegardes complètes doivent être créées un vendredi sur quatre, le mercredi la première sauvegarde sera complète au lieu d'être une sauvegarde incrémentielle.
En plus d’une sauvegarde complète de l’ensemble de vos serveurs virtuelles nous mettrons en place une sauvegarde indépendante pour vos Bases de Données (ERP, CRM, Call Center, Reporting etc) afin d’avoir une
19 Dossier d’architecture technique
sécurité supplémentaire en cas de sinistre. Ces bases pourront être restaurées de manière indépendante de l’outil VeeaM Backup et seront également externalisé à la Défense.
Sauvegarder complète
Une sauvegarde complète stocke toutes les données sélectionnées pour la sauvegarde. Une sauvegarde complète est sous-jacente à toute archive et forme la base de toutes les sauvegardes incrémentielles et différentielles. Une archive peut contenir plusieurs sauvegardes complètes ou même n'être composée que de sauvegardes complètes. Une sauvegarde complète se suffit à elle-même - vous n'avez besoin d'accéder à aucune autre sauvegarde pour récupérer les données provenant d'une sauvegarde complète.
Il est largement accepté qu'une sauvegarde complète est la plus lente à enregistrer mais la plus rapide à restaurer. Avec les technologies Acronis, la récupération à partir d'une sauvegarde incrémentielle peut ne pas être plus lente que la récupération à partir d'une sauvegarde complète.
Une sauvegarde complète est la plus utile quand :
vous devez ramener le système dans son état initial Cet état initial ne change pas souvent, il n'y a pas besoin d'effectuer des sauvegardes régulières.
Sauvegarde incrémentielle
Une sauvegarde incrémentielle stocke les modifications de données par rapport à la dernière sauvegarde. Vous devez avoir accès aux autres sauvegardes contenues dans la même archive pour récupérer les données d'une sauvegarde incrémentielles.
Une sauvegarde incrémentielle est la plus utile quand :
vous devez avoir la possibilité de ramener votre système dans l'un des états enregistrés précédemment
les modifications de données sont souvent petites comparées à la taille totale des données.
Il est largement accepté que les sauvegardes incrémentielles sont moins fiables que les sauvegardes complètes car si l'une des sauvegardes dans la « chaîne» est corrompue, les sauvegardes suivantes ne peuvent plus être utilisées. Cependant, stocker plusieurs sauvegardes complètes n'est pas une option quand vous avez besoin de plusieurs versions précédentes de vos données car la fiabilité d'une archive trop grande est encore plus contestable.
Exemple : sauvegarder le journal de transactions d'une base de données.
Sauvegarde différentielle
Une sauvegarde différentielle stocke les modifications apportées à des données par rapport à la dernière sauvegarde complète. Vous devez avoir accès à la sauvegarde complète correspondante pour récupérer les données à partir d’une sauvegarde différentielle. Une sauvegarde différentielle est la plus utile quand :
vous ne voulez sauvegarder que l'état des données le plus récent les modifications de données sont souvent petites comparées à la taille totale des données.
La conclusion typique est : «les sauvegardes différentielles prennent plus de temps à créer et sont plus rapides à restaurer, alors que les sauvegardes incrémentielles sont plus rapides à créer mais plus longues à
20 Dossier d’architecture technique
restaurer.» En fait, il n'y a pas de différence physique entre une sauvegarde incrémentielle annexée à une sauvegarde complète et une sauvegarde différentielle annexées à la même sauvegarde complète au même point dans le temps. Les différences mentionnées ci-dessus suggèrent la création d'une sauvegarde différentielle après (ou au lieu de) la création de plusieurs sauvegardes incrémentielles.
Une sauvegarde incrémentielle ou différentielle créée après la défragmentation de disque peut être considérablement plus grande que d'habitude car la défragmentation modifie l'emplacement des fichiers sur le disque et la sauvegarde reflète ces modifications. Il est recommandé de recréer une sauvegarde complète après la défragmentation de disque.
Le tableau suivant résume les avantages et inconvénients de chaque type de sauvegarde telle qu'elles sont. En réalité, ces paramètres dépendent de nombreux facteurs tels que par exemple, la quantité, la vitesse et le modèle de modifications des données ; la nature des données, les spécifications physiques des périphériques et les options de sauvegarde/restauration que vous configurez, pour n'en citer que quelques-uns. La pratique est le meilleur moyen de sélectionner le modèle de sauvegarde optimal.
Paramètres Complète Différentielle Incrémentielle
Espace de stockage Maximal Moyen Minimal
Temps de création Maximal Moyen Minimal
Temps de récupération Minimal Moyen Maximal
21 Dossier d’architecture technique
IV. Supervision de l’infrastructure
1. Les intérêts de la supervision Votre société dépend de façon importante de son système d’informations (réseaux et systèmes). C’est
pourquoi, nous vous proposons une solution pour gagner en efficacité et en réactivité en cas panne, grâce à
un outil de supervision.
Les systèmes d’informations étant de plus en plus complexes et étendus, il est compliqué de vérifier chaque
machine manuellement. C’est pour cela, qu’il peut être précieux que les équipes techniques soient alertées
en temps réel des évènements se produisant sur votre système d’informations pour anticiper les défaillances
et/ou détecter une utilisation anormale du réseau ou des serveurs.
La supervision peut être avantageuse dans les cas suivants :
Connaître l’état de vos équipements (OK ou KO)
Connaître l’état d’utilisation CPU de vos équipements
Anticiper les défaillances
Anticiper des évolutions d’infrastructure système ou réseau
Surveiller le trafic réseau sur l’ensemble de vos sites
Diagnostiquer un trafic anormal
Visualisation cartographique efficace
Obtenir des informations particulières sur vos équipements
Augmenter la réactivité d’intervention et de diagnostic
Information disponible 24/24 et 7j/7
Envoi mails ou SMS pour alerter l’équipe informatique
Utilité pour le PCA/PRA
Obtenir des statistiques d’incidents
2. Distribution solution supervision De notre point de vue technique, il est préférable de regrouper l’ensemble des outils liés à la supervision au
sein d'un même outil, ne serait-ce que pour limiter la configuration et en faciliter l’administration.
C’est pour cette raison que nous vous proposons Eyes of Network version 4.0. Il s’agit d’une solution unifiée,
basée sur le système d’exploitation CentOS. Cette distribution inclue différents logiciels destinés à la
supervision. Cette dernière possède une interface unifiée de configuration (Lilac) utilisant une base de
données commune à l’ensemble des modules utilisés.
Eyes of Network est un outil qui permet de superviser son réseau tout en y intégrant une approche ITIL, il est
idéal pour tout administrateur souhaitant avoir une approche « management » tout en voulant superviser
ses équipements. Sa simplicité d’installation ainsi que son interface web de configuration permet de faire
gagner un temps précieux. Nous pouvons donc dire qu’EON est un produit abouti pour la supervision et la
gestion de son système d’information.
Avantages
Permet de regrouper tous les outils ITIL + Supervision dans une même distribution
22 Dossier d’architecture technique
Ajoute un gestionnaire de performances
Interface de configuration web
Permet de faciliter le déploiement des outils de supervision
SSO permettant de se loguer une seule fois et d’accéder à tous les outils d’administration
Noyau Linux solide et fiable
Auto-découverte des équipements
Possibilité d’administrer ses périphériques via SSH/Telnet… depuis son interface web
Possibilité de s’authentifier via un serveur LDAP
Inconvénients
L’interface d’administration est complexe à maîtriser sans formation.
3. Vues des différentes interfaces web
Figure 1: Tableau de bord des équipements
Figure 2: Cartographie dynamique de la bande passante
Figure 3:Vue détaillée de l'état des équipements