Etude de cas – Optimisation applicative de Office 2013

Si vous n’avez jamais entendu parler de Riverbed et de sa truite aux oeufs d’or, je vous invite à jeter un oeil sur la page descriptive du produit disponible sur le site de Riverbed. Ou mieux encore, l’article rédigé par Christophe sur l’accélération applicative. Pour les plus pressés d’entre vous, en quelques mots : SteelHead est une solution d’optimisation réseau qui s’articule autour de deux axes majeurs : l’optimisation et la qualité de service des flux WAN.

scénario

la lecture/écriture de fichiers Office en accès distant et situé dans un serveur de fichiers au datacenter

Etape 1 : Préparons …

Voici les grandes lignes de l’architecture sur laquelle s’appuie cette étude de cas :

Comme vous pouvez le constater, il est réduit au minimum afin d’en faciliter sa visibilité :

• 2 sites : Datacenter et Site Distant ;

• 1 liaison VPN 1 Mega ;

• 1 Serveur de fichiers ;

• 1 Client ;

• 2 SteelHead situés en coupure de la sortie de chaque site ;

• Le protocole d’échange est le SMBv2 Signé (inhérent à la présence d’un domaine Active Directory).

Afin de mettre en évidence les avantages liés à l’accélération applicative, je vais donc appliquer le scénario suivant depuis le PC client :

• Ouverture d’un fichier ;

• Fermeture de ce fichier ;

• Ouverture de ce fichier ;

• Modification de ce fichier ;

• Enregistrement et fermeture de ce fichier.

Etape 2 : … Et jouons !

Le fichier test est une présentation commerciale utilisée par ISIS Performance au format .pptx et pesant 14,4 Mo. Pour mieux visualiser les échanges réseau, l’utilisateur du site distant dispose de la totalité de la bande passante du lien de 1 Mega.

Voici notre scénario vu du SteelHead côté client :

Pas forcement lisible au premier abord, analysons ensemble :

• La simple ouverture de l’explorateur de fichiers Windows a généré un petit pic de charge occupant 25% de la bande disponible pendant 2 secondes.

• Puisl’ouverture du fichier a monopolisé 100% de la bande passante WAN disponible pendant … 1 minute et 55 secondes !Rien n’est optimisé.

• La fermeture du fichier n’a engendré qu’un léger trafic côté WAN, à peine visible sur notre graphique : leSteelHead a commencé à optimiser les échanges TCP et SMBv2.

• La seconde ouverture de ce même fichier n’a quasiment généréaucun trafic sur le WAN, c’est le SteelHead qui a libéré la presque intégralité des données via son système de cache.Temps d’attente avant de visualiser les slides : 3 secondes. NB :On constate un second pic sur le LAN qui correspond au téléchargement du reste du contenu du document, poussé par le SteelHead en tâche de fond.

• Pendant la modification du fichier, rien ne se passe côté réseau.

• J’enregistre et je ferme le document. Du point de vue de l’utilisateur, j’ai compté5 secondes avant la fermeture du document: c’est le temps d’enregistrement du delta de modification. Puis, là encore, on s’aperçoit que le flux SMBv2 continue pendant une vingtaine de secondes après la fermeture du fichier, essentiellement côté LANgrâce à la réduction de données.

Sur ce scénario d’utilisation,SteelHead a réduit d’environ 87% les données, pour un total de 218,8 Mo économiséssur la bande passante du VPN !

Conclusion

Force est de constater quel’accélération applicative est très efficace sur les usages bureautiques.Cet article a ciblé Powerpoint mais l’optimisation fonctionne aussi bien avec d’autres usages tels que la consultation d’applications métiers Web ou encore la lecture de PDF !

PS :En bonus, les SteelHead embarquent la fonctionnalité SteelFlow, quioffre une superbe visibilité des flux applicatifs(Youtube et Facebook pour ne citer qu’eux) dès lors que vous posséder la suiteSteelCentral!