Archives de catégorie : QoS

Un peu de magie avec la QoS Windows

A la base, la fonctionnalité des « Offline Files » est une bonne idée. Le problème, c’est quand on tente de dépasser les limites de nos tuyaux réseau. La volonté de centraliser les données des utilisateurs va rapidement saturer le réseau WAN, c’est ce qui est arrivé à un de mes clients. La situation était telle que les applications métiers devenaient difficile à utiliser à cause de la bande passante consommée pour la synchronisation des données. Un vrai casse-tête, qui a conduit ce client à bloquer le trafic SMB à destination des partages contenant les « Offline Files » en central.

Problématiques posées

Voilà un challenge intéressant. On a beau retourner le problème dans tous les sens, il faudra bien réintroduire le service. C’est pas sans poser quelques problèmes :

  • Réintroduire la fonctionnalité c’est assurément atomiser le réseau. Plus on va attendre, plus les utilisateurs auront accumuler des données à synchroniser
  • Plus on tarde, plus on prend le risque de la perte de données en cas de perte du poste de travail.
  • Les performances du réseau WAN ne sont pas extensibles, rien n’interdit un utilisateur de vouloir synchroniser des Go de données.
  • La dispersion géographique des utilisateurs était pour mon client un véritable problème. Plus de 200 implémentations géographiques avec des utilisateurs essentiellement nomades

 

La solution ne pouvant pas venir de la fonctionnalité « Offline Files », on a donc commencé à chercher ailleurs. Mon premier réflexe a été d’aller faire un tour dans mon éditeur local de stratégies de groupes pour voir si une des nombreuses fonctionnalités natives de Windows ne pourrait pas nous aider. Effectivement, Windows sait faire de la QoS réseau.

clip_image001

 

Si on regarde la fonctionnalité de plus près, c’est pas mal du tout. A la base, cela permet de tagger les flux réseau qui sortent du poste de travail pour que les équipements réseau puissent y associer une politique de QoS. Moins connu, il est aussi possible de maitriser le bande passante consommée directement depuis le poste de travail. En voilà une bonne idée. Techniquement oui mais au final, c’est une fausse bonne idée. Avec plus de 200 implémentations géographiques, c’est autant de situations différentes. Avec les GPO, cela reviendrait à mettre en place autant de stratégie de groupe que d’implémentations géographiques. Après, la fonctionnalité de QoS ne traite réellement que les flux sortants du poste de travail, pas les flux entrants. Lorsqu’on regarde dans la configuration avancée, on constate qu’on ne dispose pas du même niveau de finesse.

clip_image002

 

C’est une politique est globale, pour tous les flux entrants. Le tableau ci-dessous documente la QoS :

Niveau

QoS

0 64Kb
1 256Kb
2 1Mb
3 16Mb

 

La QoS de Windows a aussi ses limites. Si en face le serveur de fichiers avait été un serveur Windows, on aurait pu aussi utiliser la QoS de la même manière. Vu que ce n’était qu’un simple NAS, il ne disposait pas de la fonctionnalité. Dans la pratique, cela va nous poser quelques problèmes :

  • Si un utilisateur ouvre une session sur un poste de travail qui n’est pas le sien, on ne pourra pas maitriser la copie des fichiers
  • Si un utilisateur se voit doté d’un nouveau poste de travail, même punition

 

Malgré ces limitations, j’ai continué mon exploration de la QoS. Certes elle a ses limites mais on peut déjà l’utiliser pour maitriser le flux sortant à destination du NAS. Fallait juste trouver un moyen d’industrialiser un peu tout cela. Quand on pense, industrialisation, on pense rapidement à Powershell. Bingo, je me souviens maintenant qu’il existe un module Powershell introduit avec Windows 8 et Windows 2012. Un peu de recherche et effectivement, le module NetQoS existe bien. Plus important, il existe bien sur le socle Windows 8 de mon client.

clip_image003

 

Une idée commence à germer. Et si on pouvait industrialiser la mise en place d’une politique de QoS au niveau des postes en fonction de sa situation réseau. En voilà un beau challenge. Faisons quelques expériences :

New-NetQosPolicy « Synchro NAS » -NetworkProfile Domain -DSCPAction 40 -DestinationIpAddress <Adresse du mon NAS> -IPProtocol TCP -IPSrcPort 445 -ThrottleRateActionBitsPerSecond 1Mb

clip_image004

Globalement, on dit à Windows de mettre en place une politique de QoS pour limiter le trafic SMB à destination du NAS uniquement pour le cas où la connectivité réseau est de type domaine (pare-feu). Pour vérifier si cela fonctionne, faut des gros fichiers. J’ai créé le script PowerShell suivant :

$Path = « c:\testFile.Txt »

$File = [IO.File]::Create($path)

$File.Setlength(1Gb)

$File.Close

Get-Item $Path

clip_image005

 

OK, 1Mbits, c’est juste un peu trop hardcore, on va passer à 2Mbits en reconfigurant la policy avec la commande PowerShell suivante :

Set-NetQosPolicy -name « Synchro NAS » -ThrottleRateActionBitsPerSecond 2Mb

clip_image006

 

Maintenant, faut des chiffres et prouver que cela fonctionne. Par expérience, l’explorateur Windows, c’est pas fiable. Le petit script PowerShell ci-dessous devrait nous aider :

cls

$startdate = get-date

Write-host « Début de test de copie d’un fichier de 1Go sur un share SMB $(Get-date) »

Copy « C:\Temp\TESTFILE.TXT » « \\<Adresse IP destination>\partage$\Datas\\TESTFILE.TXT » -Force

Write-host « Fin de test de copie d’un fichier de 1Go sur un share SMB $(Get-date) »

$enddate = get-date

Write-Host (New-TimeSpan -Start $startdate -End $enddate).TotalSeconds

clip_image007

 

A quand même, 1217 secondes pour copier mon fichier de 1Go. Au passage, je suis sur un portable en config « Full patate » avec connexion réseau Gigabit et SSD. Sceptique? Peut-être que le gestionnaire de tâche sera plus parlant alors.

clip_image008

 

Oui, il y a des pics de consommation mais ils sont régulés automatiquement. Tentons la même expérience avec une QoS à 5Mb.

clip_image009

 

Déjà, ça va mieux, que 503 secondes. Logiquement avec une QoS à 10Mb, on devrait être deux fois plus rapide, bingo.

clip_image010

 

Avec une QoS à 25Mb, on arrive à 103 secondes. Pour information, sans aucune QoS, le temps de copie de référence est de 42 secondes.

clip_image011

 

Donc, c’est industrialisable. Maintenant, les derniers détails :

  • Comment industrialiser la configuration?
  • Comment centraliser le paramétrage?

 

Comment industrialiser la configuration?

La y a pas 36 solutions. On a vu que les GPO, c’était pas possible. Il faut donc travailler au plus proche du poste. Un script de démarrage exécuté par GPO? Oui mais il ne s’applique que lorsqu’on démarre le système d’exploitation, pas quand l’ordinateur sort de veille. Très logiquement, ce sont les tâches planifiées qui se sont imposées, surtout quand on sait qu’on peut les déclencher quand on en a besoin :

  • A l’ouverture de session
  • Au déverrouillage de session
  • Après période d’activité
  • Sur détection d’un évènement dans les journaux d’évènements

OK pour exécuter un script PowerShell via tâche planifiée mais sous quel contexte? Faudra bien un compte de service, qu’il faudra maintenir. Oui mais c’est pas moi qui vais maintenir ce compte de service. Mon client utilisant Windows 8 sur ses postes de travail, l’utilisation de Group Managed Services Accounts alias GMSA s’impose. Avec Windows 8, ce qui est cool, c’est qu’on peut utiliser ce type de compte pour les tâches planifiées : Windows Server 2012: Group Managed Service Accounts.

 

Comment centraliser le paramétrage?

On sait comment configurer, reste le paramétrage. Un rapide cahier des charges s’impose :

  • Faut que ce soit facile à maintenir et faire évoluer (Que celui qui a proposé une base SQL lève la main, …)
  • Faut que ce soit léger sur le réseau
  • Faut qu’on puisse le faire évoluer rapidement pendant le développement
  • Enfin, toujours respecter la règle de base : Simple by Design

 

OK, on aurait pu développer un Web Service qui délivre la configuration mais c’est un peu too much. On va se contenter d’un simple fichier XML.

clip_image012

 

Effectivement, un fichier XML, c’est simple à maintenir, facile à faire évoluer et ça pèse pas trop lourd sur le réseau. En plus, c’est super simple à utiliser dans le script Powershell que nous exécutons dans notre tâche planifiée.

 

Le tour de magie

Le tour de magie, c’est donc un script Powershell, exécuté dans le contexte d’un compte de service dont nous n’avons pas à maintenir le mot de passe. Ce script va récupérer sa configuration en central dans un partage SMB pour conserver une copie locale en cas d’impossibilité d’accéder au partage. Le script va exploiter le fichier XML pour mettre en place des politiques de QoS pour tous les cas d’usage (interne, externe, VPN …).

clip_image013

 

Au final, ça donne cela.

clip_image014

 

A chaque ouverture de session, déverrouillage de session ou même changement d’état de la connectivité réseau, la politique de QoS est automatiquement adaptée. Donc même en sortie de veille, on s’adapte.

Et maintenant?

Maintenant, le client est en mesure de proposer une politique de QoS pour chaque implémentation géographique. Au début, il va positionner la QoS à une valeur très basse, (genre 1Mb) pour augmenter progressivement jusqu’à trouver le point d’équilibre entre la synchronisation des fichiers des utilisateurs et les applications métiers.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)