Accueil > SCCM > SCCM – Comment gérer et optimiser l’utilisation de la bande passante avec Microsoft SCCM 2007 (Bandwidth)

SCCM – Comment gérer et optimiser l’utilisation de la bande passante avec Microsoft SCCM 2007 (Bandwidth)

logo-sccm-200722

Bandwidth Management

Il peut s’avérer indispensable de maitriser les flux de réplication entre sites SCCM. Et notamment en journée… Ceci afin d’impacter le moins possible la production d’une entreprise. Ce post vous fournira les vecteurs ou pointeurs qui vous aideront à minimiser les flux SCCM. Ou du moins à les canaliser !

Donc l’objectif ici, est de proposer une solution de gestion des bandes passantes (Bandwidth) SCCM en fonction de leur lien respectif. Ceci afin de préserver les flux métiers de l’entreprise…

Pour cela, il est nécessaire de répondre aux questions suivantes :
– Quel est le minima réseau nécessaire pour le fonctionnement de SCCM ?
– Quelles solutions sont à retenir pour la gestion des bandes passantes dans SCCM ?

Eléments à considérer
– Volumétrie des packages SCCM à répliquer ?
– Nombre d’objets à répilquer dans SCCM ?
– Bande passantes utilisées entre les sites ?
– Quel type instantanéïté voulez-vous dans SCCM ?

Quels sont les outils ou pointeurs disponibles dans SCCM ?

Petit rappel, deux sites SCCM (2 primaires) parent-enfant l’un de l’autre, sont liés par ce qu’on appelle un “Sender” (Adresse). C’est ni plus, ni moins qu’un lien “ombilical” uni-directionnel, qui réunit deux site entre-eux ! En l’occurence ici, un site A répliquant vers un Site B. (Fig. 1). A l’image de Microsoft Active Directory, un lien SCCM est uni-directionnel, ce qui nécessite de créer une adresse du site B vers A afin de faire du bi-directionnel. (Fig. 2)

imageimage

Sender, vue logique et vue physique, mon coeur balance !

Dans SCCM, deux vues s’opposent : une vue “Logique” et une vue “Physique” !
Par ex. dans la figure de gauche, si nous ajoutons un Site C, comme site enfant du Site B. Cela nous fait une architecture SCCM à 3 niveaux. Par conséquent, nous allons tout naturellement créer les adresses (Senders) dans les 2 sens, afin que le Site B puisse répliquer avec son site enfant (le Site C), et vice et versa, logique ! Mais qu’est ce qui nous empêches de faire un lien direct du Site A vers le Site C (Figure de droite) ? Rien !

imageimage

En effet, nous pourrions très bien trouver pertinent de faire un tel lien dans le cas où la bande passante entre les Sites A et C est plus rapide, avec un débit plus important, qu’entre les Sites B et C, surtout dans ce sens pour la descente des packages dans SCCM, par exemple… Pourtant, sur le plan “Logique” le Site C est bien enfant du Site B

Je ne vous le conseille pas !! Eviter ! Seule la figure de gauche convient !

Donc 1ère régle, le lien physique (Vue Physique) doit refléter le lien qui existe entre le parent et l’enfant, et inversement (vue Logique).

imageimage

On pourrait aussi imaginer faire un “pontage” suppl. du Site A vers C en plus de celui de B vers C. (Figure de droite). Mais là encore, il n’existe pas de notion de “poids” (Cost) dans SCCM, afin de privilégier le meilleure chemin de réplication à prendre.

Donc 2ème régle, faite simple. Gérer plutôt le flux réseau au niveau matériel d’abord et choisissiez la topologie (mode étoile, etc.) avant de vouloir le faire par SCCM. SCCM doit être la dernière option ou permettre d’affirmer votre volonté topologique réseau !

Idem concernant les protocoles de communication (SMB, HTTP, SIP, etc.). Faite de la QoS (Quality of Services). Concernant les clients SCCM, vous pouvez utiliser la fonction Branch Cache dans Windows 2008 R2. Je vous orienterais donc vers cette article.

Gestion des packages

Si on imagine une volumétrie totale de 128 Go de packages dans SCCM, stockés et déployés à partir du site SCCM Root. Ceci afin de “pousser” les applications et Masters 7 (ou autres) de type Corporate. Combien de temps vais-je mettre pour que les packages arrive sur mon site enfant de 2ème ou de 3ème niveau ? Et comment éviter de saturer mes liens WAN ?

Binary Differential Replication
Pour les gros packages de type masters OS, il est possible d’utiliser l’option, “Enable binary Differential replication” dans les propriétés d’un package (Figure de gauche). Cette fonction, permet de ne répliquer que le delta d’un package, suite à une modification de celui-ci. Faut-il encore qu’il soit déjà là…

Copie compressée des packages
Il est aussi possible de compresser le package, en choisissant l’option, “Use a compressed copy of the source directory”. Alors SCCM fabriquera donc un fichier .PCK de la source spécifiée dans cette même fenêtre et le répliquera sur les points de distribution SCCM (Figure de droite).

imageimage

Cependant, si les fichiers sources, disponibles depuis un SAS de livraison (Serveur de fichiers), ont été modifiés, les points de distribution ne seront pas mis à jour. Cette dernière option convient donc plus pour de la copie de CD-ROM, ou dans l’hypothèse où les packages ne seront plus disponibles et/ou modifiés par la suite sur la source.

Fichiers PCK dans SCCM

Comparaison entre l’option, compressée ou depuis la source
Comparaison entre les deux options pour les 2 modes

image

Scenario 1: Use a compressed copy of the sources directory
Lors de réplication d’un point de distribution distant ([SERVER2] à [SERVER4]), un fichier PKG est généré, et les binaires du même package sont copiés dans un répertoire sur le serveur de site local [SERVER2]

La copie du package sur un site distant enfant se fait en PCK – Pas de PCK localement présent sur [SERVER2] (Root). Dans cette méthode un répertoire JUP0000E est bien créé, afin d’y accueillir les binaires, mais à ce stade il est vide !

Ils ne seront décompressés et copiés que lorsque l’application sera utilisée par SCCM
(Par ex. publication de l’application pour les postes du site primaire [SERVER4] enfant de Root). Le fichier PCK est conservé afin d’être répliqué sur le autre site enfant de [SERVER4]

Dés lorsqu’on active une publication locale à [SERVER4] (Site primaire enfant), le package est immédiatement décompressé et copié dans le répertoire local JUP0000E du primaire

image

Important : Dans cette méthode, le PCK est conservé parce que [SERVER4], en plus d’être server primaire SCCM, celui-ci est « Distribution Point ». Dans le cas où celui ne le serait pas, le PCK peut disparaitre ! Dans ce cas, les PCK ne sont générés sur [SERVER4] uniquement pour que celui-ci se charge de les copier sur l’un de ses fils (Primaire ou Secondaire)

Scenario 2: Option: Always obtain files from the source directory
Lors de réplication d’un point de distribution distant ([SERVER2] à [SERVER4]). Aucun PKG n’est généré à ce stade et les binaires du package sont copiés dans un répertoire sur le serveur de site local [SERVER2]

La copie sur un site distant enfant provoque la génération d’un PCK local [SERVER2] celui-ci est ensuite envoyé sur le site distant [SERVER4]. De plus, les binaires (stockés dans le répertoire) sont aussi copiés sur le site distants [SERVER4]

Ce qui représente deux sessions de copies, une copie pour le PCK et une copie pour les binaires. Seule dans cette méthode le PCK est généré en local sur [SERVER2]

image

Gestion de bande passante dans SCCM

Alors déjà il faut savoir que le flux descendant au sein d’une hiérarchie SCCM est plus importante de par la descente des packages, que la remonté des informations d’état. A contrario, le flux montant SCCM de fonctionnement (hors packages) est plus important que le flux descendant.

Le flux descendant avec gestion des packages étant le cœur du problème le plus souvent, nous nous y tiendrons pour ce qui suit, prenant en compte les données citées plus haut et la répartition en cours pour les packages « Toutes Filiales ».

SCCM offre la possibilité de positionner des priorités sur les packages et d’en filtrer la réplication vers un autre site partenaire (enfant). Cependant, cela concerne aussi bien les packages SCCM que le fonctionnement même de SCCM. Il n’est pas possible de définir les priorités sur les autres objets touchant au fonctionnement même de SCCM. (Par exemple. Ajout d’une machine dans une collection).

Par défaut, les packages SCCM sont considérés comme une information de type normale et sont configurés en priorité Medium. Cette configuration est modifiable dans les propriétés d’un package même.

image

Gestion des priorités pour un package
Gestion des objets en fonction de leur priorité respective : Medium, Low, High

Cas d’un déploiement d’urgence
Les patchs de sécurité dits critiques peuvent être « tagués » en High et être autorisé à être répliqué en journée sur les sites enfants, en n’utilisant qu’un certain % de bande passante, ceci afin d’y être déployés.

A contrario, les images WIM représentant ainsi plusieurs Go et peut être « taguées » en Low et n’être autorisées qu’à être répliquées que pendant la nuit en n’utilisant qu’un certain % de bande passante.

Note : Il est possible de répliquer les packages SCCM par l’utilisation de disques durs externes en utilisant l’outil : « Preload package on Site »

Gestion des réplications des priorités
Une fois les priorités définies, il est possible de gérer la réplication des priorités spécifiées dans SCCM par le biais de l’utilisation d’un calendrier. Cette gestion est accessible dans les propriétés de l’adresse de site ciblant un site (enfant) partenaire.

Gestion des Sender inter-sites (Adresses)
Gestion des Calendriers de réplication inter-sites des objets

image

Gestion par l’expression de % d’utilisation de bande passante
image

Gestion des flux SCCM
Toujours dans les propriétés des adresses et dans la gestion des réplications, il possible de gérer le taux d’occupation de la bande passante détectée par SCCM. Seuls les packages et publications sont gérables sur le plan priorités via la console.

Tous les Packages sont par défaut en priorité Medium :

– Drivers Packages
– Package software
– Master WIM
– Package de déploiement (WSUS)

La combinaison de ces 2 méthodes citées plus haut, permet de gérer les réplications SCCM tout en prenant en compte les priorités d’urgence en sens SCCM du terme et de la bande passante disponible et détectée entre deux sites.

Application concréte

Exemple de hiérarchie

image

Exemple de définition de règles
Considérons 75Mo comme étant la barrière volumétrique de packages.
– Considérons maintenant que nous voulons préserver la bande passante WAN entre 8 à 18 heures, n’autorisant SCCM que 25% d’utilisation de la bande passante détectée, puis 50% entre 4h et 8h du matin et 19h et 22h.

A ceci, vous voulez que seuls les packages en priorité High ou inférieurs à 75Mo en medium, soient autorisés à être répliqués à travers la hiérarchie SCCM, en journée.

Voici que nous devrions faire…

1 – Faire l’inventaire et la cartographie de tous vos packages présents dans SCCM et mettre les priorités correspondantes : Low pour les packages se trouvant au-dessus de 75Mo, ainsi que les drivers et les Masters OS (WIM)…

Type de packages (Vol.)

Nombre de PKG

Priorités

Packages en dessous (<) de 75 Mo

597

Medium

Packages en dessus (>) de 75 Mo

132

Low

Packages Masters WIM

17

Low

Packages Drivers

58

Low

Pour configurer des propriétés des packages et des publications (Advertisements) …

image image

2 – Définir une règle de réplication (Sender) descendante pour tous vos sites SCCM

Gestion des priorités Gestion des flux SCCM

Pour tous les sites SCCM
Parents –> Enfant

Option:
Allow medium & high priority only

De 08 h à 19 h
Du Monday au Friday

image

Le filtrage pourrait avoir un impact important sur les mécanismes SCCM pour des objets dont la priorité est Medium

Pour tous les sites SCCM
Parents –> Enfant

Option :
25% de bande passante
08h à 19h

Option :
50% de bande passante
04h à 07h
19h à 22h

Option :
100% de bande passante
22h à 04h

image

Note : Par défaut, les packages sont en priorité Medium, il ne sera donc pas possible pour eux de se répliquer en journée A savoir entre 08h et 19h

Conséquences

Si on consulte le fichier de log, Sender.log, nous pouvons observer les évaluations SCCM pour le transfert du site à l’autre :

Pour la règle High Only
1. Evaluation des objets et de leur priorité
2. Acceptation ou refus après évaluation pour les objets non conformes
3. Abandon de l’envoi par Sender ou réplication des informations respectant les critères

image

Capacité % de flux en fonction de la planification horaire

En fonction des horaires d’ouverture de flux et du % de bande passante autorisé, il est possible de connaitre la capacité de volume de réplication sur 24 heures en fonction de la bande passante définie, disponible selon la formule suivante :

Volume répliqué = (Débit en kbps x Hours x 3600) x (% Bandwidth réservée / 100) / (8 x 1024)

Par exemple sur une ligne de 512 kbps : Selon les tranches horaires suivantes et le % de Bandwidth de chaque tranche, voici la volumétrie consommée pour tranche horaire sur 24 heures.

0h00 – 04h00

4h00 – 08h00

8h00 – 19h00

19h – 22h

22h00 – 0h00

4h

4h

11h

3h

2h

100%

50%

25%

50%

100%

900Mo

450Mo

618,75Mo

337,50Mo

450,00Mo

Total répliqué d’information : 2756,25 Mo

Temps (en H)

Débit du lien réseau

% Réseau disponible

Volume transféré (Mo)

Volume (Mo)

11
7
6

512Kbps

25%
50%
100%

618,75
787,50
1350,00

2756,25

Répartition des packages

Répartition

Volumétrie totale (Go)

Temps (Days)

Packages < 75 Mo

5

1,9

Packages > 75 Mo

75,3

36,1

Packages WIM

45

21,6

Packages Drivers

2,7

1,3

TOTAL

128

61,3

Ce qui donne le graph suivant :

image

Communication inter-sites

Il faut savoir qu’il n’est pas recommandé de mettre un point de distribution d’un site SCCM sur un site distant. Car dans cette configuration, il y a pas de maitrise des flux SMB de réplication (copies de packages, etc.). Seule la notion de site (primaire ou secondaire) met à disposition un calendrier de réplication, et le % de consommation du lien WAN à utiliser.

– Figure de gauche : Pas de contrôle de flux (SMB)
– Figure de droite : Maitrise de la bande passante via le Sender SCCM (SMB)

image  image

Note : Pour savoir quand mettre un site SCCM enfant, ou non, je vous renvoie vers cet article

Clients SCCM

Le rôle de point de distribution de branche (BDP), permet de transformer un PC comme dépositaires des packages SCCM. La copie se fait dans cette configuration en utilisant BITS (Figure de gauche).

Dans la figure de droite, il est possible de publier des applications (Packages) sur des postes (clients) distants. Mais dans ce cas là, attention à bien activer le protocole BITS sur les DP (Distribution Point) et de bien spécifier que le clients distants doivent télécharger les packages en local avant de les exécuter !

image    image

Note 1 : Lorsque le téléchargement en BITS d’un package depuis un client est en échec, le client peut basculer en SMB. Vous pouvez le voir en consultant le fichier de log, FileBITS.log sur le client en question…

Note 2 : Le téléchargement entre les clients et le BDP (Point de distribution de branche) d’un même site (distant) se fait en utilisant le protocole SMB (Fig. Gauche)

Note 3 : Pour les clients distants en publication directe, vous pouvez définir la limite de site distante en Slow… Ceci afin de “dire” à SCCM que cette limite (Boundary) est distante et de faible débit. Ceci pourra vous servir dans les conditions de publications (Advertisements) (Fig. droite).

Fonctionnement des clients et inventaires SCCM

Dans un Site SCCM, les clients SCCM remontent 4 Mo d’inventaires et 5 Ko par delta. Si nous considérons un site primaire de 1000 clients cela représente un volume de 3,90 Go de données et 4,88 Mo de delta tous les 7 jours par défaut.

Une fois les données compilées dans la base de données du primaire, ces informations sont compressées est envoyées au site parent sous formes compressées (ou delta).

Note : Il est à noter que le déploiement des clients SCCM se fait par vague, la remonté des inventaires sont donc glissés dans le temps. Le polling des clients est donc dans leur fonctionnement (Interrogation MP (33Ko toutes les 60 minutes (par défaut)), est également glissé dans le temps

Flux ou trafic entre les clients et une infrastructure SCCM

Le tableau suivant recense la taille des paquets échangés entre un client et l’infrastructure SCCM. Il s’agit d’une estimation. Les chiffres pourront donc être amenés à évoluer.

Rôle

Evènements

Fréquence

Taille

Client SCCM

Recherche MP au démarrage de l’agent SMS

Logon User ou toutes les 25 heures

Changement IP

33 Ko

Client SCCM

Requête de Politique Ordinateur

1h

3,4 Ko

Client SCCM

Requête de Politique Utilisateur

1h

7 Ko

Point de Gestion

Réponse à la Requête de politique (si aucune nouvelle « Policy »)

1h

4 Ko

Point de Gestion

Découverte par Pulsation d’Inventaire

7j

5 Ko

Inventaire Matériel

Delta moyen sans changement majeur

7j

5 Ko (*)

(dépend de la configuration du MOF)

Inventaire Logiciel

Delta moyen sans changement majeur

7j

5 Ko

(dépend du nombre de fichiers inventoriés)

(*) Ces chiffres dépendent de la configuration SCCM (Extension d’inventaire, complexité des règles d’inventaire…)

Gestion du Sender dans SCCM

Dans SCCM, il est possible de gérer le nombre de connexions concourantes maximum par site SCCM parent ou Enfants. Il est donc important de configurer le Sender en fonction du nombre de sites connectés au site concerné en fonction du volume de données à répliquer. Il est conseillé d’adapter la valeur « All Sites » à chaque niveau en fonction du nombre de sites connectés

image

ANNEXES – Configuration des adresses et options (Sender)

Les propriétés des limites du taux de transfert de l’adresse permettent de définir les taux maximum de transfert des données, par heure, du site actif au site de destination.

Illimité lors de l’expédition de données à cette adresse

La sélection de cette option autorise un taux de transfert illimité des données lorsque le site actif envoie des données à cette adresse.

Mode impulsion

Lorsque le mode impulsion est sélectionné, vous pouvez limiter la quantité de données envoyées entre des sites, ce qui vous permet de préciser la taille des blocs de données envoyés (en kilo-octets) dans lesquels les données sont subdivisées, ainsi qu’un délai à respecter entre chaque envoi de bloc de données (en secondes).

Taille des blocs de données (Ko) : Spécifiez la taille du bloc de données que Configuration Manager 2007 envoie à l’adresse
Délai entre les blocs de données (secondes) : Délai entre l’envoi des données par Configuration Manager 2007 à l’adresse et l’envoi du bloc de données suivant

Limité aux taux de transfert maximaux indiqués par heure

Il s’agit des heures de la journée et du pourcentage du taux de transfert maximal autorisé pour chaque heure. Si aucun chiffre n’apparaît sous une heure, 100 % du taux de transfert maximal est autorisé pour cette heure. Cliquez et faites glisser pour sélectionner plusieurs heures.

Lorsque cette option est sélectionnée, vous pouvez également préciser le taux de transfert maximal pour la période sélectionnée :

Période : Période sélectionnée dans le graphique du jour ci-dessus.
Limite (% de largeur de bande de connexion) : Il s’agit du pourcentage du taux de transfert maximal autorisé pour la période sélectionnée. Vous pouvez choisir un pourcentage ou Illimité.

Enjoy !

Michel PICOLLET | EXAKIS Paris
Consultant Senior Microsoft [System Center]
mpicollet@event-horizon.emea.microsoftonline.com

  1. Aucun commentaire pour l’instant.
  1. No trackbacks yet.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :