CeBIT – Professional Data Center @ CeBIT:
Virtuelle Sicherheit

von Ralf Ladner (ralf.ladner@networkcomputing.de), Markus Nispel

Share
26.02.2010

Infrastruktur – Höhere Anforderungen bei weniger Budget und gleichzeitig mehr Agilität und Zuverlässigkeit der gebotenen Dienstleistungen – damit müssen sich die IT-Verantwortlichen heutzutage im Rechenzentrum auseinandersetzen. Das alles natürlich unter Beibehaltung oder Verbesserung aktueller Sicherheitsniveaus.

(Fortsetzung des Artikels von Seite 4)

Nach Branchenschätzungen ist mehr als 80 Prozent des IT-Budgets für das Erhalten bestehender Applikationsumgebungen innerhalb des Datacenters vorgesehen. Als Konsequenz gibt es starke Bestrebungen zur Reduzierung der Total Cost of Ownership (TCO) in diesem Bereich, indem man den Datacenter-Betrieb durch Server- und Storage-Konsolidierung optimiert und durch intelligentes Design und optimierte Ressourcenausnutzung die Investitionskosten reduziert.

Auch steigen Datacenter-Strom- und -Kühlkosten expotenziell, in vielen Umgebungen übersteigen sie die Investitionskosten für die Hardware. Steigende Energiekosten erhöhen ebenfalls die Aufmerksamkeit für »Green«-Datacenter-Aktivitäten. Aus diesen und anderen Gründen wie erhöhte Flexibilät, eine in Aussicht gestellte Vereinfachung der Administration etc. werden heute massiv Virtualisierungstechnologien eingesetzt, um die Effizienz und Effektivität der Server- und Storage-Ressourcen zu erhöhen.

Heutige Datacenter-Architekten stehen nun vor der Herausforderung, die sich zur Zeit noch sehr schnell entwickelnden Lösungen zu einem Gesamtsystem zu formen: von einzelnen Virtualisierungslösungen im Desktop-, Server- und Storage-Bereich zu einer virtuellen Infrastruktur, in der alle Komponenten optimal abgestimmt und orchestiert werden können.

Enterasys als Network-Infrastructure und Security-Division der Siemens Enterprise Communications Group stellt hier eine sichere Netzwerk-Plattform bereit, die sich technisch optimal und kostenoptimiert in diese neuen Architekturen integriert und die schnelle, effektive Bereitstellung neuer Services ermöglicht. Und dies mit einem hohen Automatisierungsgrad so dass die Betriebskosten minimiert werden können.

Datacenter-Komponenten

Vorträge Enterasys Networks

Es gibt prinzipiell vier Komponenten, die zusammen die Datacenter-Lösung von Enterasys formen:

--> Virtualization,

--> Storage,

--> Connectivity (and Topology) sowie

--> Automation (and Visibility, Security).

In jedem Bereich sind spezielle Anforderungen umzusetzen. Die Herausforderung besteht in der optimal Orchestierung der einzelnen Bausteine.

Virtualization, Automation

Insbesondere die Server- und Desktopvirtualisierung sorgen dafür, dass wesentlich mehr Dynamik ins Datacenter kommt: Redundanz-/Failovermechanismen wie »vMotion« von Vmware oder auch die dynamische Nutzung und Optimierung von Host-Ressourcen durch Verschiebung der virtuellen Maschinen (VMs) mit Funktionen wie DRS (Dynamic-Ressource-Scheduling) von Vmware sorgen dafür, dass sich die gesamte Server- und Desktop-Landschaft sehr schnell ändern und verschieben kann. Hinzu kommt das sehr einfache Einbringen neuer Server und Services unter Zuhilfenahme von Virtualisierungstechniken.

In virtuellen Umgebungen sind die Abhängigkeiten der Netzwerkkomponenten untereinander noch entscheidender.

Der Betreiber der darunter liegenden Netzinfrastruktur muss in der Lage sein, virtuelle Services (Server, Desktops, Applikationen) schnell zu lokalisieren, zuzuordnen und zu überwachen. Andernfalls steigt der Zeitaufwand für das Bereitstellen von Ressourcen und der Aufwand beim Troubleshooting deutlich an, die Verfügbarkeit nimmt deutlich ab. Aus diesem Grund muss automatisch eine dynamische Allokierung von Netzwerkressourcen und Sicherheitsparametern erfolgen. Ebenso muss eine »Null-Konfiguration«-Mobilität gewährleistet sein, die jedoch gleichzeitig ein wirkungsvolles Monitoring zulässt. Dazu müssen sich Services einfach gruppieren lassen können und das jeweilige sicherheitsrelevante Verhalten gemessen und überprüft werden.

Und dies in einer Umgebung, die durch die Virtualisierungstechniken noch mehr »moving parts« bekommen haben, so beispielsweise der so genannte »Virtual Switch« oder »vSwitch« im Hypervisor von Vmware oder Xen. Dadurch ergeben sich für den traditionellen Netzwerk- und Security-Verantwortlichen folgende Fragen:

-- Wer sorgt für die Sicherheit der neuen Software-Applikation Hypervisor, Patch-Management etc.?

-- Wer sorgt für die mit der physischen Netzwerkinfrastruktur und deren Sicherheitsmechanismen (Firewall, VLAN, Access-Listen, VRF etc) sowie abgestimmte Konfiguration der virtuellen Switches auf den Hosts so dass keine Sicherheitslücken entstehen?

-- Wer ist für das Change-Management auf der Server- und Netzseite zuständig? Wie kann man VMs überhaupt in der Infrastruktur erkennen und tracken (aus Compliance-Anforderungen heraus und für das Troubleshooting)?

-- Wer sorgt für die Kapazitätsplanung der physischen Infrastruktur um in allen Virtual-Machine/Host-Kombinationen ausreichend Bandbreite zur Verfügung zu stellen? Die Inter-VM-Kommunikation auf dem gleichen Host ist ja zunächst nicht sichtbar.

Zu beachten ist auch, dass die integrierten Vswitches der am Markt verfügbaren Virtualisierungslösungen nicht als »mature« betrachtet werden können. Sowohl was die Features als auch die Stabilität angeht. Weiterhin stellt sich dem erfahrenen Netzwerker die Frage, wie es denn mit der Performance und dessen Monitoring dieser software-basierten Komponenten bestellt ist. Und wie der entsprechende Einfluss auf den Host beim Einschalten zusätzlicher Features, soweit überhaupt vorhanden, zu quantifizieren ist. Man kann natürlich die virtuellen Switches nicht ausblenden, sondern sollte sein Betriebskonzept darauf abstimmen und sie integrieren, ohne jedoch zu viel Funktionen dort hinein zu verlagern: dies würde die Betriebskosten und die Komplexität erhöhen und zu eventuell nicht erwünschten Effekten führen.

Es gibt natürlich den Ansatz am Markt, der einfach den virtuellen Switch durch einen eigenen ersetzt, um das »CLI (command line interface)« identisch zu gestalten und so die Konfiguration zu »vereinfachen«. Aber damit bindet sich der Kunde zu 100 Prozent an die Anbieterkombination von Netzwerk- und Virtualisierungstechnologie – hier aber ist noch viele Bewegung zu sehen und ein Kunde wird in Zukunft wohl mehrere unterschiedlich Technologien nutzen. Sofern müsste man für jede Technologie von seinem Netzanbieter einen Vswitch bekommen. Und das ist aus der Erfahrung heraus nicht erstrebenswert oder praktikabel. Auch führt dies immer wieder zu »Version lock-ins«, das heißt, falls der eine Partner nicht rechtzeitig mitzieht kann eventuell eine neue Version aus Kompatibilitätsgründen nicht eingespielt und genutzt werden.

Einen grundlegend anderen Ansatz verfolgt hier Enterasys. Die Integration erfolgt über das Management-System mittels Web-Services-APIs. Dies sorgt unter anderem für eine Unabhängigkeit von der Virtualisierungstechnologie und ist schnell erweiterbar. Stand heute wird die Integration über bestehende APIs der Virtualisierungsanbieter Citrix mit »XENCenter« oder Vmware mit »ESX« oder »vCenter« unterstützt. Man nutzt hier Web-Services via XML/SOAP, um Daten und Konfigurationen zwischen VM- und Netzwerk-Management abzustimmen, auszutauschen und zu synchronisieren.

Das VM-Management bekommt vom Netzmanagement in Echtzeit den Status, die zugewiesene Policy und die Location (an welchem physischen Switchport befindet sich die VM) der VM geliefert und ermöglicht somit dem Serveradministrator den vollen Überblick über alle relevanten Parameter.

Auch werden die möglichen Netze und VLANs dem Server/VM-Administrator automatisch vorgegeben. Diese weist dann nur noch seine VMs einem Netz zu – diese Information wird automatisch ins Netzwerk-Management synchronisiert und hier an eine netzwerkspezifische Policy gebunden. Sobald eine VM Pakete sendet wird am Switchport für diese VM die entsprechende VLAN, Access-Listen und Quality-of-Service-Konfiguration bereitgestellt. Fehlkonfigurationen von externem Switch und Vswitch werden damit ausgeschlossen. Damit muss der Netzwerkadministrator nicht eingreifen aber er hat ebenfalls (wie auch der Serveradministrator) alle Daten einer VM direkt im Zugriff. Auch wiederum fürs Troubleshooting, für die Kapazitätsplanung und eventuelles (Compliance) Reporting unabdingbar.

Zur Zuweisung von Netzwerk- und Security-Konfiguration pro VM muss die verwendete Switch-Hardware so weit skalieren, dass Umgebungen mit potenziell mehreren 100 VMs (bei Desktopvirtualisierung) pro Host/physischem Server und mehreren 10000 Access-Listen unterstützt werden.

Das zuvor genannte Konzept kann man je nach Möglichkeiten der API noch ausbauen und vom Netzwerk-Management aus die Vswitch-Konfiguration weiter überschreiben, je nachdem, wer die Kontrolle über die Gesamtkonfiguration haben soll.

Der Kapazitätsplanung beziehungsweise dem Monitoring der aktuell und historisch genutzten Bandbreite muss in einer virtualisierten Serverumgebung ein besonderes Augenmerk gelten. Durch die potenzielle Verschiebung von Server-Ressourcen auf neue oder wenig genutzte Hosts, kann sich das gesamte Verkehrsprofil im Datacenter schlagartig ändern. Dem Netzwerkadministrator muss dies bewusst sein und er sollte sich entsprechend wappnen. Transparenz hat hier oberste Priorität – Verkehrsstatistiken pro VM sollten über präzise Technologien wie beispielsweise Netflow erhoben werden und auf Abruf bereit stehen. Hiermit kann man nicht nur Tendenzen erkennen beziehungsweise das Verhalten vorhersagen, Flowdaten eignen sich auch besonders zur Erkennung von Angriffen auf die VM-Infrastruktur. Network-Behavior-Analysis (NBA) ist hier das Stichwort. In Verbindung mit einem Security-Monitoring der aktuellen Generation kann man hiermit das gesamte Datacenter und die dort zur Verfügung gestellten Applikationen sicherheitstechnisch im Griff haben. Zusammenfassend kann der Einsatz vom Web-Services und auf SOA basierenden Management-Konzepten den Betrieb einer Virtual-Datacenter-Umgebung drastisch vereinfachen und einen hohen Automatisierungsgrad erzielen. Damit sind sowohl die in Aussicht gestellten Betriebskostensenkungen zu erreichen als auch die Sicherheit und Transparenz im Betrieb zu garantieren.

Storage

Auch die Storage-Welt befindet sich in einem Umbruch weg von der traditionellen Fibre-Channel-Technologie zu IP und auf Ethernet basierenden Techniken. Der Bedarf, die gleiche Serverschnittstelle (z.B. zumindest die gleichen Protokolle) sowohl für den Daten- als auch den Storage-Verkehr zu nutzen, steigt massiv an. Treiber hierfür sind die vereinfachte Verkabelung, geringere Betriebskosten, geringere Stromkosten und der Platzbedarf auf den Server-Komponenten. Man muss sich vor Augen halten, dass heutige Server sehr leicht sechs bis acht Interfaces benötigen, um alle erforderlichen Anschlüsse zu realisieren. Bei der heutigen Packungsdichte kommt das einiges zusammen.

Die heute konkurrierenden Protokolle sind hier NFS, iSCSI und Fibre-Channel over Ethernet (FCoE). Die beiden erstgenannten Protokolle haben den Vorteil, dass die bereits seit längerem etabliert und auf IP aufsetzen. Die Nutzung von IP erzeugt jedoch ein gewisses Maß an Overhead, was in der Vergangenheit zu geringen Durchsätzen und höheren CPU-Lasten geführt hat. Eine neue Generation an so genannten Convergend-Network-Adaptors eliminiert diese Probleme bis in den 10-GBit/s-Bereich hinein.

FCoE auf der anderen Seite hat den Focus auf der einfacheren Integration bestehender FC-Umgebungen durch die Nutzung des FC-Protokolls über Ethernet. Die Nachteile sind hier die nicht vorhandene beziehungsweise unzureichende Standardisierung der dazu notwendigen Ethernet-Erweiterungen, auch unter dem Begriff CEE/DCE zu finden (Converged-Enhanced-Ethernet/Data-Center-Ethernet) und der daraus folgenden Anforderungen an spezielle Ethernet-Switches und Gateways, die FCoE/DCE und eine Umsetzung auf FC erlauben. Zusätzlich ist die Herausforderung, dass es sich bei FCoE um eine Ethernet-basierte Übertragung handelt – große Netze sind damit nicht ohne weiteres realisierbar.

Obwohl alle erwähnten Protokolle eine so genannte I/O-Virtualisierung/Aggregation erlauben – die Nutzung nur eines Interfaces für alle Datentypen – ist davon auszugehen, dass viele Unternehmen dennoch auf separate physikalische Netze für Storage und Access setzen werden. Betriebliche Vorteile sprechen dafür – auch bei höheren Investitionen.

Aber auch beim Einsatz von NFS und iSCSI in Highend-Storage-Netzen ist besonderes Augenmerk auf die verwendete Switch-Hardware in Bezug auf Durchsatz aber auch insbesondere auf die Paketspeicher (um die Paketverluste bei Congestion zu minimieren) zu legen. Traditionelle LAN-Access-Switches haben hier oft massive Defizitie, so dass nur entsprechende Core- und Datacenter-Switches mit Standard-Ethernet-Support, aber mit passender Ausstattung, verwendet werden sollten.

Connectivity and Topology

Der Platzierung der Netzkomponenten ist ebenfalls ein Bereich mit hohem Optimierungspotenzial. So genannte ToR- (Top of Rack) gegenüber EoR/MoR- Konzepte (End of Row/Middle of Row) haben jeweils Vor- und Nachteile. Für ToR spricht die effektive Verkabelung mit kurzen Wegen hin zum Server, Nachteil besteht in der frühen Aggregation und der potenziellen Überbuchung in Richtung Uplinks. Wenn man 20 Server per 10 GBit/s aggregiert, wie sieht dann der Uplink aus (das wird sich in den nächsten 12 Monaten durch 40-GBit/s-Ethernet etwas entspannen)? Dies spricht dann eher für EoR-Konzepte, wobei dort dann Chassis mit hohen Portdichten zum Einsatz kommen und als zentrale Fabric für alle Server dienen. Üblicherweise wird man einen Mix finden, der im ToR-Bereich 1-GBit/s-Verbindungen zu 10-GBit/s aggregiert und dann zusammen mit direkter 10-GBit/s-Serververbindung auf ein EoR-System geführt wird.

Eine weitere Herausforderung ist die Vergrösserung von Layer 2 Netzen zur Nutzung von Funktionen wie vMotion und DRS dies es einfach notwendig machen, dass ein bestimmtes Subnetz überall im Data Center und sogar Data Center übergreifend zur Verfügung steht. Hier können dann Layer 2 Provider Services auf der Basis von VPLS Virtual Private LAN Service oder einfach DWDM Dense Wave Division Multiplexing zur Data Center Kopplung genutzt werden. Im Data Center selbst kann auf standardisierte RTSP/MSTP Spanning Tree Konzepte zurückgegriffen werden, die ebenfalls Umschaltzeiten um Sub-Sekunden Bereich ermöglichen. Falls alle Verbindungen aktiv genutzt werden sollen stehen neue Standards wie 802.1aq Shortest Path Briding in naher Zukunft bereit, um Data Center Topologien noch effektiver zu gestalten. Auf proprietäre vorab Implementierungen sollte aus Gründen der Betriebssicherheit und der Integrationsmöglichkeit unterschiedlicher Hersteller verzichtet werden.

Markus Nispel, Vice President Solutions Architecture bei Enterasys Networks