Scénarios de stratégie QoS

Vous pouvez utiliser cette rubrique pour passer en revue les scénarios hypothétiques qui montrent comment, quand et pourquoi utiliser la stratégie QoS.

Les deux scénarios de cette rubrique sont les suivants :

1. hiérarchiser le trafic réseau pour une application de cœur de métier ;
2. hiérarchiser le trafic réseau pour une application de serveur HTTP.

Scénario 1 : hiérarchiser le trafic réseau pour une application de cœur de métier

Dans ce scénario, un service informatique peut atteindre plusieurs objectifs grâce à la stratégie QoS :

• améliorer les performances réseau des applications stratégiques ;
• améliorer les performances réseau d’un jeu clé d’utilisateurs lorsqu’ils utilisent une application spécifique ;
• garantir que l’application de sauvegarde de données à l’échelle de l’entreprise n’entrave pas les performances réseau en utilisant une bande passante trop importante.

Le service informatique décide de configurer la stratégie QoS pour hiérarchiser des applications spécifiques en utilisant des valeurs de point de code de service de différenciation (DSCP) aux fins d’une classification du trafic réseau, et de configurer ses routeurs pour exécuter un traitement préférentiel pour le trafic de priorité supérieure.

Outre les valeurs DSCP, les stratégies QoS peuvent spécifier un taux de limitation. La limitation a pour effet de limiter l’intégralité du trafic sortant qui correspond à la stratégie QoS selon un taux d’envoi spécifique.

Configuration de la stratégie QoS

L’administrateur informatique, qui doit accomplir trois objectifs distincts, décide de créer trois stratégies QoS différentes.

Stratégie QoS pour les serveurs d’applications de cœur de métier

La première application stratégique pour laquelle le service informatique crée une stratégie QoS est une application de planification des ressources d’entreprise (ERP) à l’échelle de l’entreprise. L’application ERP est hébergée sur plusieurs ordinateurs sous Windows Server 2016. Dans Active Directory Domain Services, ces ordinateurs sont membres d’une unité d’organisation (UO) créée pour les serveurs d’applications de cœur de métier (LOB). Le composant côté client de l’application ERP est installé sur les ordinateurs sous Windows 10 et Windows 8.1.

Dans la stratégie de groupe, un administrateur informatique sélectionne l’objet de stratégie de groupe (GPO) auquel la stratégie QoS sera appliquée. À l’aide de l’assistant de stratégie QoS, l’administrateur informatique crée une stratégie QoS appelée « Stratégie de cœur de métier de serveur ». Cette dernière spécifie une valeur DSCP de priorité élevée de 44 pour toutes les applications, les adresses IP, les protocoles TCP et UDP, et le numéro de port.

La stratégie QoS est appliquée uniquement aux serveurs de cœur de métier et associe l’objet de stratégie de groupe à l’unité d’organisation qui contient uniquement ces serveurs, et ce, par le biais de l’outil de la console de gestion des stratégies de groupe (GPMC). Cette stratégie de cœur de métier de serveur initiale applique la valeur DSCP de priorité élevée chaque fois que l’ordinateur envoie du trafic réseau. Cette stratégie QoS peut être modifiée ultérieurement (dans l’outil de l’éditeur d’objet de stratégie de groupe) pour inclure les numéros de port de l’application ERP. Cela garantit une application de la stratégie uniquement lorsque le numéro de port spécifié est utilisé.

Stratégie QoS pour le groupe responsable des finances

Bien que de nombreux groupes au sein de l’entreprise accèdent à l’application ERP, les activités et les rapports avec les clients du groupe responsable des finances reposent sur cette application ; cette dernière doit donc constamment garantir des performances élevées.

Pour garantir une relation optimale entre le groupe responsable des finances et ses clients, la stratégie QoS doit classer le trafic de ces utilisateurs en tant que hautement prioritaire. Toutefois, la stratégie ne doit pas s’appliquer lorsque les membres du groupe responsable des finances utilisent des applications autres que l’application ERP.

Pour cette raison, le service informatique définit une deuxième stratégie QoS appelée « Stratégie de cœur de métier de client » dans l’outil de l’éditeur d’objet de stratégie de groupe, qui applique une valeur DSCP de 60 lorsque le groupe d’utilisateurs responsables des finances exécute l’application ERP.

Stratégie QoS pour une application de sauvegarde

Une application de sauvegarde distincte s’exécute sur tous les ordinateurs. Pour s’assurer que le trafic de l’application de sauvegarde n’utilise pas toutes les ressources réseau disponibles, le service informatique crée une stratégie de données de sauvegarde. Cette stratégie de sauvegarde spécifie une valeur DSCP de 1 en fonction du nom exécutable de l’application de sauvegarde, qui est backup.exe.

Un troisième GPO est créé et déployé pour tous les ordinateurs des clients du domaine. Chaque fois que l’application de sauvegarde envoie des données, la valeur DSCP de faible priorité est appliquée, même si elle provient d’ordinateurs du service financier.

Stratégies applicables au scénario

Le tableau suivant répertorie les stratégies QoS applicables à ce scénario.

Lorsque les stratégies QoS sont définies et appliquées à l’aide de la stratégie de groupe, le trafic réseau sortant reçoit la valeur DSCP spécifiée par la stratégie. Les routeurs assurent ensuite un traitement différentiel basé sur ces valeurs DSCP grâce au processus de mise en file d’attente. Pour le service informatique, les routeurs sont configurés selon quatre files d’attente : priorité élevée, priorité moyenne, meilleur effort et priorité faible.

Lorsque le trafic arrive au niveau du routeur avec les valeurs DSCP de la « stratégie de cœur de métier de serveur » et de la « stratégie de cœur de métier de client », les données sont placées dans des files d’attente de priorité élevée. Le trafic dont la valeur DSCP est de 0 se voit attribuer un niveau de service de meilleur effort. Les paquets dont la valeur DSCP est 1 (en provenance de l’application de sauvegarde) se voient attribuer un traitement de faible priorité.

Conditions préalables à la hiérarchisation d’une application de cœur de métier

Pour effectuer cette tâche, assurez-vous de satisfaire aux exigences suivantes :

• Les ordinateurs impliqués exécutent des systèmes d’exploitation compatibles QoS.

• Les ordinateurs impliqués font partie d’un domaine Active Directory Domain Services (AD DS) afin de pouvoir être configurés à l’aide de la stratégie de groupe.

• Les réseaux TCP/IP sont configurés avec des routeurs configurés pour DSCP (RFC 2474). Pour plus d’informations, consultez RFC 2474.

• Les exigences inhérentes aux informations d’identification d’administration sont satisfaites.

Informations d’identification d’administration

Pour effectuer cette tâche, vous devez être en mesure de créer et de déployer des objets de stratégie de groupe.

Configuration de l’environnement de test pour hiérarchiser une application de cœur de métier

Pour configurer cet environnement de test, procédez comme suit :

• Créez un domaine AD DS avec des clients et des utilisateurs regroupés en unités d’organisation. Pour obtenir des instructions sur le déploiement du service AD DS, consultez le Guide de réseau central.

• Configurez les routeurs pour qu’ils assurent un processus de mise en file d’attente différentielle en fonction des valeurs DSCP. Par exemple, la valeur DSCP 44 est placée dans une file d’attente « Platinum », et toutes les autres valeurs sont placées dans une file d’attente équitable et pondérée.

Étapes de hiérarchisation d’une application de cœur de métier

Pour hiérarchiser une application de cœur de métier, procédez comme suit :

1. Créez un objet de stratégie de groupe (GPO) et associez-le à une stratégie QoS.

2. Configurez les routeurs pour qu’ils traitent de manière différentielle une application de cœur de métier (selon un processus de mise en file d’attente) en fonction des valeurs DSCP sélectionnées. Les procédures de cette tâche varient en fonction du type de routeurs dont vous disposez.

Scénario 2 : hiérarchiser le trafic réseau pour une application de serveur HTTP

Dans Windows Server 2016, la stratégie QoS basée sur une stratégie inclut les stratégies basées sur les URL de fonctionnalité. Les stratégies d’URL vous permettent de gérer la bande passante des serveurs HTTP.

De nombreuses applications d’entreprise sont développées et hébergées sur des serveurs Web Internet Information Services (IIS), et les applications Web sont accessibles depuis les navigateurs sur les ordinateurs client.

Dans ce scénario, supposons que vous gériez un jeu de serveurs IIS qui hébergent des vidéos de formation pour tous les employés de votre organisation. Votre objectif est de veiller à ce que le trafic provenant de ces serveurs vidéo ne surcharge pas votre réseau et de vous assurer que le trafic vidéo est différencié du trafic vocal et de données sur le réseau.

La tâche est semblable à celle du scénario 1. Vous allez concevoir et configurer les paramètres de gestion du trafic, tels que la valeur DSCP du trafic vidéo et le taux de limitation, de la même manière que vous le feriez pour les applications de cœur de métier. Toutefois, pour spécifier le trafic, au lieu de fournir le nom de l’application, entrez uniquement l’URL à laquelle votre application serveur HTTP répondra : par exemple, https://hrweb/training..

Règles de priorité pour les stratégies basées sur des URL

Les URL suivantes sont toutes valides ; elles peuvent donc être spécifiées dans la stratégie QoS et être appliquées simultanément à un ordinateur ou à un utilisateur :

• https://video

• https://training.hr.mycompany.com

• https://10.1.10.249:8080/tech

• https://*/ebooks

Mais laquelle sera prioritaire ? Les règles sont simples. Les stratégies basées sur des URL sont hiérarchisées selon un ordre de lecture de gauche à droite. Ainsi, de la priorité la plus élevée à la priorité la plus faible, les champs d’URL sont les suivants :

1. Modèle d’URL

2. Hôte d’URL

3. Port d’URL

4. Chemin d’URL

Les détails sont les suivants :

1. Modèle d’URL

La priorité de https:// est plus élevée que celle de https://.

2. Hôte d’URL

De la priorité la plus élevée à la plus faible :

1. Nom d’hôte

2. Adresse IPv6

3. Adresse IPv4

4. Caractère générique

Dans le cas d’un nom d’hôte, un nom d’hôte comportant plus d’éléments séparés par un point (plus de profondeur) a une priorité plus élevée qu’un nom d’hôte avec moins d’éléments séparés par un point. Par exemple, parmi les noms d’hôte suivants :

• video.internal.training.hr.mycompany.com (profondeur = 6)

• selfguide.training.mycompany.com (profondeur = 4)

• training (profondeur = 1)

• library (profondeur = 1)

  La priorité de video.internal.training.hr.mycompany.com est la plus élevée. La priorité de selfguide.training.mycompany.com est la deuxième plus élevée. Training et library ont la même priorité, qui est la plus faible.

3. Port d’URL

Un numéro de port spécifique ou implicite a une priorité plus élevée qu’un port générique.

4. Chemin d’URL

À l’instar d’un nom d’hôte, un chemin d’URL peut se composer de plusieurs éléments. Le chemin qui comporte plus d’éléments a toujours une priorité plus élevée qu’un chemin qui en comporte moins. Par exemple, les chemins suivants sont répertoriés par priorité :

1. /ebooks/tech/windows/networking/qos

2. /ebooks/tech/windows/

3. /ebooks

4. /

Si un utilisateur choisit d’inclure tous les sous-répertoires et fichiers suivant un chemin d’URL, ce chemin d’URL aura une priorité inférieure à celle qu’il aurait si l’utilisateur n’avait pas fait de choix.

Un utilisateur peut également choisir de spécifier une adresse IP de destination dans une stratégie basée sur une URL. L’adresse IP de destination présente une priorité inférieure à l’un des quatre champs d’URL décrits précédemment.

Stratégie quintuple

Une stratégie quintuple est spécifiée par l’ID de protocole, l’adresse IP source, le port source, l’adresse IP de destination et le port de destination. Une stratégie quintuple a toujours une priorité plus élevée que n’importe quelle stratégie basée sur une URL.

Si une stratégie quintuple est déjà appliquée à un utilisateur, une nouvelle stratégie basée sur une URL n’entraîne aucun conflit sur les ordinateurs client de cet utilisateur.

Pour la rubrique suivante de ce guide, consultez Gérer la stratégie QoS.

Pour la première rubrique de ce guide, consultez Stratégie de qualité de service (QoS).