freshidea - Fotolia

F

Wie viele SDN-Controller sind für die Kontrolle von Richtlinien notwendig?

Unternehmen sollten für die Steuerung von Richtlinien und das Netzwerk-Management mindestens einen SDN-Controller als Backup vorhalten.

Ein SDN-Controller verwaltet als Herzstück von Software-defined Networking (SDN) den Datenfluss zwischen den Netzwerkgeräten und den Applikationen. Mit Hilfe von Protokollen wie OpenFlow konfiguriert der Controller die Netzwerkgeräte und wählt den optimalen Weg für den Anwendungs-Traffic durch das Netzwerk. Wie viele SDN-Controller benötigt ein Unternehmen?

Für die Antwort gilt es verschiedene Punkte zu beachten. Der SDN-Controller soll grundsätzlich das Management und die Steuerung des Datenflusses im Netzwerk vereinfachen. Daher können Unternehmen den Controller auch für die Steuerung und Kontrolle von Richtlinien einsetzen. Auch wenn nicht jedes SDN-fähige Gerät (Node) einen Controller benötigt – mit Hilfe eines Controllers erhöhen Administratoren die Transparenz und können das gesamte Netzwerk besser steuern und kontrollieren.

Als Faustregel empfiehlt es sich, mindestens einen zusätzlichen SDN-Controller als Backup vorzuhalten, der aber nicht unbedingt für die Steuerung des Netzwerks erforderlich ist. Unabhängig von der Art des Netzwerks (LAN, WLAN, Netzwerk für Sprachübertragung etc.) rät der gesunde Menschenverstand, einen weiteren Controller als Sicherung für den Notfall bereitzuhalten.

Die meisten Anbieter empfehlen übereinstimmend den Einsatz von mindestens drei SDN-Controllern. Cisco beispielsweise rät Unternehmen, drei seiner Application Policy Infrastructure Controller (APIC) einzusetzen, die in einem Cluster zur Kontrolle der Richtlinien und für das Netzwerk-Management miteinander kommunizieren. Die APICs von Cisco können bis zu eine Million Netzwerkgeräte steuern.

VMware empfiehlt für eine NSX-Implementierung eine ungerade Anzahl von SDN-Controllern, sprich Minimum drei. Auch OpenDaylight und ONOS, Anbieter von Open-Source-Controllern, nennen die magische Zahl Drei. Ein Grund dafür ist die Teilung des SDN in separate Ebenen für Netzwerkdatenanalyse und -steuerung (Control Plane) sowie den Netzwerkdatentransport (Data Plane). Da auf der Steuerungsebene meist viele Workloads verarbeitet werden, ist die Arbeitslast für den Controller enorm. Daher geht es darum, mit Split Brain verbundene Probleme zu vermeiden, die beim Verarbeiten von zwei bis drei Datensätzen entstehen können. Beim Split Brain versuchen Cluster gleichzeitig auf die gleichen Anwendungsdaten oder Festplatten zuzugreifen, was zu Datenverlust führen kann.

Das Netzwerk arbeitet offensichtlich weiter, wenn die Verbindung zum Controller verloren geht, da die Data Plane weiter funktioniert. Unternehmen verlieren aber solange die Transparenz und die Funktion der Policy-Kontrolle, bis der Controller wieder online ist. Daher gilt: Redundanz ist hier das richtige Konzept.

Folgen Sie SearchNetworking.de auch auf Twitter, Google+, Xing und Facebook!

Nächste Schritte

Software-defined Networking: Sind spezialisierte SDN-Controller wirklich notwendig?

Fünf kommerzielle SDN-Controller, die Sie kennen sollten

Fünf Open-Source SDN-Controller, die Sie kennen sollten

OpenDaylight bekommt durch Open Source SDN-Controller ONOS Konkurrenz

 

Erfahren Sie mehr über Software-defined Networking

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close