Die Architektur der Fabrik

In einer Datacenter-Fabric entstehen durch die Virtualisierung und der Dynamik privater Cloud-Infrastrukturen, durch die IT-Applikationsarchitekturen selbst mit Präsentations-, Applikations- und Storage-Systemen und deren verwobene Kommunikationsstrukturen und durch die Konsolidierung von Server und die Konvergenz von Daten- und Storage-Datenströme, die sehr hohe Bandbreiten erfordern und sich laufend ändern, zahlreiche in den Griff zu bekommene dynamische Kommunikationsbeziehungen. Sowohl im Server-Access  als auch zwischen den Switch-Elementen.

Insbesondere 10-GBit/s-Server-Systeme und als auch Storage-Verkehr im Allgemeinen reagiert sehr sensitiv auf höheren Delay und Paketverluste durch – temporäre – Überbuchungssituationen. Fibre-Channel over Ethernet (FCoE) macht sogar eine neue Art des Ethernets erforderlich – Datacenter-Bridging und die entsprechenden IEEE-Protokolle – was im Rahmen der One-Fabric-Architektur in einem Zwei-Stufen-Plan unterstützt wird. Jedoch sind heute gerade im gehobenen Mittelstand andere Protokolle wie iSCSI und NFS auf dem Vormarsch und viele Kunden setzen auf diese Protokolle und bleiben Fibre-Channel treu, da sich gezeigt hat, dass es – mangels etablierter Standards und Erfahrungen im Betrieb – für großflächige Multi-Hop-FCoE-Installationen noch zu früh ist. Die Buffering-Architektur der Enterasys-S-Serie ermöglicht es zusammen mit den Quality-of-Service-Funktionen im Policy-Provisioning heute, eine konvergente Daten-/Storage-Infrastruktur auch im großen Stil auf Basis von iSCSI und NFS zu realisieren. Im Rahmen der Multipathing-Anforderung setzt die One-Fabric-Architektur insbesondere im Server-Access auf Virtual-Switch-Bonding. Dieses ermöglicht es, Switches miteinander zu clustern und somit eine Active-/Active-Verbindung zu Servern via LACP sowie zu anderen Switches zu realisieren. Im Datacenter-Core wird diese Lösung aber bald von IEEE-802.1aq-Shortest-Path-Bridging (SPB) abgelöst (sobald dieser ratifiziert ist), was durch einen einfachen Software-Upgrade erreicht wird und damit eine sanfte Migration mit Rückwärtskompatibilität zu RSTP/MSTP ermöglicht. Im Rahmen der One-Fabric-Architektur wird dieser Standard dann auch über den Core- und Distributionsbereich in den Access unterstützt werden und somit dem Anspruch der One-Fabric-Architektur gerecht, auf Standards und gleiche Technologiebausteine in allen Ebenen des Netzes beziehungsweise der Fabric zu setzen. Damit wird es auch einfacher, Netz-ebenen zusammenzufassen und zu reduzieren, was wiederum zu einer Performance, Latenz und Kostenoptimierung führt.

Zusätzlich sorgt Fabric-Routing dafür, dass nicht nur alle und die kürzesten Pfade für Verkehr innerhalb eines virtuellen LANs genutzt werden, sondern jeder Switch zu einem aktiven Router wird, der zwischen VLANs im Datacenter auch jeweils den kürzesten Weg nutzt und damit die Latenz minimiert. Traditionelle Ansätze erfordern Router am Edge der Datacenter-Fabric, so dass ineffiziente Verkehrsflüsse entstehen können.

Last but not least werden in der Datacenter-Fabric die gleichen Switches und eigenentwickelten, Flow-basierten „CoreFlow2 ASICs“ von Enterasys genutzt, die auch im Campus-Core und Distribution sowie abgewandelt auch im Access zum Einsatz kommen. Diese ermöglichen es zum Beispiel, alle Datenströme (Flows) über Netflow v9 zu erfassen und zentral im One-Fabric-Control-Center (oder anderen Netflow-Analyser-Tools) darzustellen. Dies erfolgt im so genannten „Non-sampled-Modus“ und ohne Performance-Verlust. Dies ist wichtig zur Analyse von Verkehrsströmen in der Fabric, die sich ja laufend ändern, wenn man entsprechend über die reine Serverkonsolidierung hinaus geht. Die extrem skalierbare Policy-Implementierung auf diesen Systemen wird über die Zeit bis auf Layer 7 ausgedehnt, so dass die Applikationserkennung und entsprechenden Policies den Anforderungen von Cloud-Applikationen (Nutzung des Web-Browsers als das Frontend für alle Applikationen) folgen können.