mise en œuvre d’un call center - xcally.com · la valeur recommandée pour la gigue en voip doit...

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


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

sip:[email protected]


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


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.


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.


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


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.


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 »



N'intègre aucun emplacement de station dans sa MAC table (il n'y pas d'apprentissage)


Envoie les BPDUs reçus de son système

Répond à SNMP

Etat « Learning »




Intègre les emplacements de station dans sa MAC table (apprentissage)



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)



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.


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 :


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.


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.


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


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


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


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 à


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


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


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


Figure 4: Graphique de la bande passante d'une interface réseau de serveur

mise en œuvre d’un call center - xcally.com · la valeur recommandée pour la gigue en voip doit...

Documents