Archives par mot-clé : commutation

Divers

Standards IEEE pour gérer la commutation des PC virtuels

Laisser un commentaire

pc-virtuel L’IEEE travaille sur les standards 802.1Qbg et 802.1Qbh afin d’adresser les problèmes liés à la gestion de machines virtuelles dans les centres de données.

Un serveur n’est pas un switch

La virtualisation a pour effet pervers de placer une lourde responsabilité sur les switchs virtuels qui utilisent les ressources des cartes réseaux et des serveurs lames qui doivent maintenant gérer, entre autres, la sécurité du système, les stratégies et droits de chaque groupe et utilisateur et tout ce qui est associé au switching. Le but du standard 802.1Qbg et 802.1Qbh est de replacer cette charge de travail sur un switch Ethernet physique connectant les unités de stockage et les diverses ressources du réseau.
Pour cela, l’IEEE est en train de développer une fonctionnalité appelée VEPA (Virtual Ethernet Port Aggregation), une extension aux switching physiques et virtuels qui permet de réduire le nombre d’éléments ayant besoin d’être géré par un centre de données (configurations, adresses, sécurité, stratégies, etc.)

L’IEEE 802.1Qbg et 802.1Qbh seront nécessaires dans quelques années

Selon ESG Research, une majorité d’entreprises utilisent entre 5 et 10 machines virtuelles par serveur. Néanmoins, d’ici quelques années ce chiffre devrait grimper à 30, ce qui placera une charge de travail énorme sur le switch virtuel qui devra s’occuper des VLAN, des tags QoS, des zones de sécurités, etc. En permettant à l’hyperviseur de déléguer les tâches de switching à un switch physique, on déplace le problème et on permet aux serveurs de réaliser leur travail de base, offrir de la puissance de calcul pour les applications. Si ces deux standards ne sont donc pas très utiles pour le moment, on imagine que le 802.1Qbg et 802.1Qbh vont être indispensables dans les entreprises d’ici quelques années.

Lire l’article sur : Présence PC…

Ethernet, Industriel

Harting met en avant la solution fast track switching

Laisser un commentaire

switch En fait, cette solution est un retour à une fonctionnalité qui existait il y a 10 ans sur les switchs. Elle présente l’avantage de proposer un temps de traversée identique quelque soit la taille de la trame à l’inverse de la commutation “Store & Forward” qui doit stocker la trame en totalité avant de la rediriger. Cette ancienne solution est mise au gout du jour en intégrant la gestion de la qualité de service (802.1Q / 802.1p)et donc des VLANs.

L’inconvénient majeur de cette solution est de ne proposer qu’une solution mono-débit de bout en bout (ici du 100Mb/s) car il est impossible avec cette solution de passer à un débit moindre (10Mbit/s) ou plus important (gigabit). Or le temps de latence du switch “store & forward” annoncé comme problématique en 100Mb/s (ici de 120µs) est divisé par 10 en gigabit minimisant ainsi l’impact du transport sur le réseau automatisme et garantissant l’interopérabilité entre switchs de différents constructeurs respectant le standard. Par ailleurs, en intégrant le standard IEEE1588, le PTP : Precision Time Protocol, le temps de parcours de tout le réseau peut être mesuré précisément de bout en bout et permettre ainsi de déterminer les critères Temps Réel du réseau traversé.

Pour diminuer encore plus le temps de traversé du réseau, on peut aussi remplacer les switchs par des hubs (répéteurs) 100Mb/s (quitte a les “bidouiller” un peu pour éviter les collisions que la méthode CSMA/CD classique amène sur ce type de produit – ce que n’hésite pas à proposer certains constructeurs automatismes). En résumé, le choix sera de savoir si l’on souhaite une solution ouverte et pérenne ou une solution propriétaire… 

Store and forward, cut-through Ethernet switching

The performance of switching technology is greatly enhanced by use of cut-through switching technology rather than store-and-forward technology. (See figure 1.)
Neither will guarantee determinism, however, making both insufficient for many automation applications. Protocol prioritization for IEEE 802.1q also is ineffective because automation protocols compete with other protocols of the same and higher priority. The delays that can result are unacceptable for automation.

Two delay mechanisms are:

– Delays in the input port: If an input port’s queue (memory) is saturated with traffic from other protocols of the same or higher priority than the automation protocols, then the automation messages are delayed. (See figure 2.) This leads to unpredictable delays for automation protocols.

Continuer la lecture de Harting met en avant la solution fast track switching →