NetApp Tech OnTap
     

NetApp Kilo-Client 3G

Seit 2006 zeichnet Tech OnTap die Weiterentwicklung des NetApp Kilo-Client auf, NetApps große Entwicklungstestumgebung. Tech OnTap bat Brad Flanary vom NetApp RTP Engineering Support Systems Team, für diesen Artikel die Ziele und Technologien hinter der nächsten geplanten Version dieser wichtigen und innovativen Einrichtung zu beschreiben.

Beim NetApp Kilo-Client handelt es sich um eine Testumgebung, über die NetApp eine große Anzahl an physischen und/oder virtuellen Clients schnell konfigurieren und booten kann, um Tests der NetApp Storage-Hardware und -Software durchzuführen. Die erste Version des Kilo-Client wurde 2005 entwickelt (dies wurde in einem früheren TOT-Artikel beschrieben). Diese Version bot anfänglich 1.120 physische Clients, die über iSCSI anstatt von der lokalen Festplatte aus gebootet wurden.

Mitte 2007 umfasste der Kilo-Client bereits 1.700 physische Clients, die über iSCSI, FC oder NFS gebootet wurden und als physische Clients mit Windows oder Linux oder in virtualisierten VMware Umgebungen implementiert werden konnten. Ein zu dieser Zeit erschienener Tech OnTap Artikel konzentrierte sich auf die Techniken, die wir zum Implementieren physischer Server und virtueller Umgebungen mittels NetApp FlexClone und anderer Technologien von NetApp einsetzten.

Diese Konfiguration bewährte sich für NetApp, für eine größer angelegte Virtualisierung kamen seit dem letzten Artikel einige Server hinzu. Fast drei Jahre später wird es jetzt mit Ablauf des Leasingzeitraums für die ursprüngliche Server-Ausrüstung Zeit zur Erweiterung der Konfiguration, um mit der neuesten Technologie und den Entwicklungen im Bereich Cloud Computing Schritt zu halten.

Dieser Artikel konzentriert sich auf das Kilo-Client-Design der dritten Generation, das Folgendes unterstützen wird:

  • Durchführung von Tests mit bis zu 75.000 virtuellen Clients gleichzeitig (wodurch der Name Kilo-Client immer unpassender wird
  • Überprüfen einer breiteren Palette an Netzwerkkonfigurationen, einschließlich 10-Gigabit-Ethernet und Fibre Channel over Ethernet (FCoE),
  • Implementierung Hunderter oder Tausender von Clients innerhalb weniger Stunden.

Wir beginnen mit der Beschreibung unserer neuen Anforderungen, sprechen über die Hardware-Bewertung und beschreiben dann das Design des Kilo-Client 3D, der in der ersten Hälfte dieses Jahres auf den Markt kommen wird. Darüber hinaus werden wir das einzigartige Design des NetApp Datacenter besprechen, in dem der Kilo-Client untergebracht ist.

Anforderungskatalog

Nach Besprechungen mit unseren internen Kunden und unter Berücksichtigung von Anfragen, welche die aktuelle Konfiguration nicht erfüllen konnte, begannen wir mit dem Sammeln der Anforderungen für den Kilo-Client der nächsten Generation. Um sicher zu gehen, begannen wir die Überarbeitung jedoch mit einer detaillierten Umfrage unter unseren bestehenden internen Kunden und anderen potenziellen Kilo-Client-Nutzern bei NetApp. Die Umfrage können Sie einsehen, indem Sie durch das in Abbildung 1 dargestellte vollständige Dokument klicken. (Sie werden feststellen, dass einige Fragen auf Virtualisierung abzielen, da wir erfahren wollten, ob die Anforderungen unserer Kunden eher durch virtuelle als durch physische Clients erfüllt werden konnten.)

Kilo-Client-Umfrage und -Auswertungen.

Abbildung 1) Kilo-Client-Umfrage          
und -Auswertungen.

Zu den wesentlichen Ergebnissen gehören:

  • Den meisten unserer Kunden wäre mit virtueller Hardware eher gedient als mit physischer
  • Es gab einen großen Bedarf an 10-Gigabit-Ethernet
  • Es gab Bedarf nach FCoE für die nahe Zukunft (seit Durchführung der Umfrage vor ein paar Monaten gehen nun die Nachfragen ein)

Diese Umfrage war für uns sehr wertvoll. Sie bestätigte unseren Verdacht, dass den meisten unserer Kunden eher mit virtueller statt mit physischer Hardware gedient wäre. Dies deckt sich offensichtlich mit der in der IT-Branche aktuell vorherrschenden Verschiebung zu mehr Virtualisierung und Cloud Computing. Darüber hinaus decken sich diese Ergebnisse mit einem seit Kurzem spürbaren Trend zu mehr Server-Virtualisierung bei NetApp. (In einem Tech OnTap Artikel von April 2009 wurde die Migration von physischer zu virtueller Umgebung in einem Entwicklungslabor von NetApp in Bangalore, Indien, beschrieben.)

Hardware-Bewertung

Da wir nun die Anforderungen an unseren neuen Kilo-Client besser kannten, lag ein nächster Schritt in der Bewertung der Server-Hardware. Wir schickten ein RFP an diverse Server-Anbieter, um zu testende Produkte zu erhalten. Unser Testverfahren konzentrierte sich auf mehrere Dinge:

  • die Möglichkeit der Unterstützung konvergierter Netzwerkadapter (CNAs), die sowohl FCoE als auch 10GbE unterstützen (weitere Informationen über CNAs erhalten Sie in diesem kürzlich erschienenen Tech OnTap Artikel)
  • Unterstützung von Virtualisierung
  • Performance
  • bedarfsgerechte Skalierbarkeit

Wir bewerteten alle Server hinsichtlich der Performance, die sie vom CNA erreichen konnten, inwieweit sie Virtual Machines unterstützten und wie gut sie branchenspezifische Standards erfüllten.

Wir stellten schnell fest, dass für unsere Anforderungen auf Intel Nehalem-Mikroarchitektur-Prozessoren basierende Server weit besser abschnitten als die älteren Intel Core-Mikroarchitektur-Prozessoren (Dunnington). Beide von uns gewählten Server-Modelle verfügen über Nehalem-Prozessoren.

Für das Netzwerk implementierten wir eine Cisco Nexus-Infrastruktur in unserem neuen Global Dynamic Laboratory (GDL). Diese Netzwerkinfrastruktur wird zur Erfüllung der FCoE- und IP-Anforderungen des Kilo-Client weiter zum Einsatz kommen. Für Fibre Channel kommt Brocade Switching zum Einsatz.

Die geplante Implementierung des Kilo-Client 3G

Server:

  • 468 Fujitsu RX200 S5, 48 GB, 2 CPUs: 2,26-GHZ-Intel-Xeon-E5520-Prozessor (Nehalem); (dies sind 4-Core-, 8-Thread-Prozessoren mit 8 Cores und 16 Threads pro System)
  • 160-Cisco-UCS-Server (die gleiche Prozessorkonfiguration wie Fujitsu):
    • 48 mit 48-GB-Speicher
    • 112 mit 24-GB-Speicher

Insgesamt ergibt dies 628 Clients mit 5.024 Cores. Dies ersetzt drei Behälter des ursprünglichen Kilo-Client oder 728 physische Clients mit 1.456 Cores. Alle diese Clients können primär als virtuelle Server ausgeführt oder als physische Clients implementiert werden. Bei einer möglichen Dichte von 120 VMs pro physischem Server werden wir bis zu 75.360 VMs über den Kilo-Client bieten können.

Die verbleibenden circa 1.000 Clients der vorherigen Generation des Kilo-Client bleiben und kommen weiterhin für Tests zum Einsatz. Sie werden allmählich ausgemustert und bei Leasingende zurückgesandt.

Netzwerk:

  • Core: Nexus 7018 (16 I/O-Module, Backplane skalierbar auf 15 TBit/s)
  • Aggregation: Nexus 5010 und 5020
  • Zugriff: Nexus 2148T (FEX)
  • Fibre Channel: Brocade DCX Director und 5320 Edge Switches

Storage:

  • FC-Boot: 4 NetApp FAS 3170 Storage-Systeme
  • NFS-Boot: 16 NetApp FAS 3170 Storage-Systeme
  • Weitere Storage: vollständige Auswahl aus den aktuellen NetApp Storage-Plattformen und -Festplatten

Wir booten üblicherweise 500 VMs pro NFS-Datenspeicher. Wir nutzen SnapMirror für die bedarfsgerechte Replizierung der Golden Images aus einer zentralen Ablage zu jedem einzelnen Boot Storage-System.

Booten von physischer Hardware und Virtual Machines

Das wesentliche Merkmal des Kilo-Client ist sein schnelles, flexibles und speicherplatzeffizientes Booten. Wie bei jeder Cloud-Infrastruktur müssen wir jede Anzahl an Clients für jede Aufgabe – ob physisch oder virtuell – schnell umkonfigurieren können. Der Kilo-Client nutzt eine Kombination aus FC- und FCoE-Boot für das Booten eines jeden physischen Servers und NFS-Boot zur Unterstützung des Bootens von Virtual Machines auf Servern, die für die Ausführung von Virtualisierung konfiguriert sind.

Wir haben uns für FC-Boot für das physische Booten entschieden, da sich dieses bei der vorhandenen Kilo-Client-Infrastruktur als sehr zuverlässig erwiesen hat. Bei den meisten großen Server-Installationen bootet ein physischer Server jedes Mal das gleiche Boot Image. Er bootet eventuell Linux oder Windows in einer physischen Umgebung oder VMware ESX in einer virtuellen Umgebung, dies macht jedoch keinen Unterschied. Dies gilt nicht für den Kilo-Client. Einer unserer Server bootet beispielsweise heute Linux, morgen VMware und übermorgen Windows. Wir nutzen FC-Boot in Kombination mit der Funktion des dynamischen LUN-Klonens, um unsere physischen und virtuellen Server schnell und effizient zu booten.

Wie bereits in vorherigen Artikeln beschrieben, pflegen wir einen Satz an „Golden“ Boot Images (wie Fibre Channel LUNs) für alle Betriebssysteme und Applikations-Stacks, die wir nutzen. Unter Einsatz von NetApp SnapMirror und FlexClone sind wir in der Lage, schnell Hunderte von Klonen für jeden physischen Server, der für einen Test konfiguriert wurde, zu reproduzieren. Es muss lediglich eine hostspezifische „Personalisierung“ zum Core Image des bereitgestellten Servers ergänzt werden. Dieser einzigartige Ansatz sorgt für eine echtzeitnahe Image-Bereitstellung nahezu ohne Platzbedarf.

Der Vorgang des Bootens von Virtual Machines baut auf den gleichen Schritten auf:

  • Booten von VMware ESX auf jedem Host für den Test
  • dynamisches Registrieren dieser Hosts im VMware Virtual Center (vCenter)
  • Vorbereiten der richtigen Netzwerkeinstellungen und Datenspeicher für Virtual Machines
  • Verwenden von NetApp Rapid Cloning Utility (RCU) zum Klonen der geeigneten Anzahl und Typen von Virtual Machines automatische Registrierung der VMs im vCenter durch RCU
  • dynamische Registrierung der Server in DNS und DHCP und Booten der Virtual Machines
  • Überprüfen, ob alles korrekt ist.

Vollständige Automatisierung. In den letzten Jahren haben wir Perl-Skripte erstellt, über die in Kombination mit den Tools von NetApp und VMware die oben genannten Schritte automatisiert werden können, damit in zwei bis drei Stunden 500 bis 1.000 Virtual Machines implementiert werden können. (Hierzu gehören sowohl das Booten der physischen Hardware als auch das Booten der VMs.) Dies unterscheidet sich von anderen, in Tech OnTap beschriebenen Implementierungen, bei denen die Zeit bis zur Implementierung auf Servern basiert, auf denen bereits VMware ausgeführt wird.)

Maximale Speicherplatzeffizienz. Der andere einzigartige Vorteil ist der besonders niedrige Speicherplatzbedarf, da wir FlexClone für das Klonen von „Golden Images“ verwenden, anstatt Kopien zu erstellen. Wir implementieren routinemäßig 500 Virtual Machines, wobei lediglich ein Speicherplatz von 500 GB (1 GB pro Client) genutzt wird. Falls notwendig ist auch ein noch geringerer Speicherplatzbedarf möglich.

Mit der neuen Infrastruktur werden wir bis zu 75.000 Virtual Machines bei sehr großen Tests konfigurieren können. Sobald die gesamte Hardware vorhanden ist, können wir darüber informieren, wie schnell dies vonstatten gehen kann. Hinweis: Die Clients, aus denen der Kilo-Client besteht, sind üblicherweise in mehrere kleine Gruppen aufgeteilt, die alle parallel Tests durchführen.

Physisches Layout. Das Design des Kilo-Client der vorherigen Generation basierte auf „Behältern“, in denen sich Server, Netzwerke und Boot Storage befanden. Dieser Ansatz war für ein Design sinnvoll, bei dem sich die Hardware in unmittelbarer Nähe befand und für das ein manuelles Einrichten und manuelles Abbauen notwendig sein konnte.

Für den neuen Kilo-Client wurde der Behälteransatz überdacht und optimiert. Das neue Design konzentriert alle Boot-Infrastrukturen an einem Ort. Server und Storage-Systeme werden nun in Behälter gruppiert, die über gerade die Switching-Fähigkeiten (IP und FC) verfügen, die für die Erfüllung der Anforderungen des Behälters notwendig sind. So sind die Behälter leicht zu replizieren und der Kilo-Client kann durch bloßes Hinzufügen eines anderen Behälters des entsprechenden Typs erweitert und skaliert werden. (Wir können mit anderen Worten einen Behälter mit Servern oder einen Behälter mit Storage usw. hinzufügen.) Da manuelles Einrichten und manueller Abbau nicht mehr notwendig (oder gewünscht) sind, können neue Behälter überall im Datacenter implementiert werden, wenn mehr Speicherplatz erforderlich ist. So wird das Datacenter selbst mit maximaler Effizienz betrieben.

Unser Global Dynamic Laboratory

Der Kilo-Client befindet sich physisch im NetApp Global Dynamic Laboratory, einem innovativen neuen Datacenter in der NetApp Anlage im Research Triangle Park, North Carolina, USA. Der Kilo-Client wird Teil der Shared Test Initiative (STI) von NetApp Engineering sein, die mehrere Prüfstände bietet und sich auf die Automatisierung von Implementierung, Testdurchführung und das Sammeln von Ergebnissen konzentrieren wird. Die STI wird eine Vernetzung dieser Ressourcen unterstützen, damit wir alle Ressourcen in unseren Labors übergreifend nutzen können.

Bei der Gestaltung des GDL wurde auf Effizienz und Automatisierungsfähigkeit Wert gelegt. Es verfügt über 36 Kühlräume mit insgesamt 2.136 Racks und jeweils etwa 60 Schränken.

Zu den wichtigsten Design-Elementen eines modernen Datacenters wie dem GDL gehören:

  • Wie viel Leistung kann pro Rack bereitgestellt werden? Die heutige Hardware verbraucht mehr Leistung bei geringerem Platzbedarf.
  • Wie viel Platz ist pro Rack notwendig, um eine ausreichende Kühlung zu gewährleisten?
  • Wie effizient kann die Leistung genutzt werden? Das aktuelle Maß für die Energieeffizienz liegt bei einem PUE-Wert (Power Usage Effectiveness) von 2,0.

Für das GDL basiert die Energie- und Kühlverteilung auf durchschnittlich 12 kW pro Rack mit insgesamt 720 kW pro Kühlraum. Die Energieverteilung innerhalb eines Racks liegt bei 42 kW. Unter Zuhilfenahme unserer firmeneigenen Druckregelungstechnologie erreichen wir eine Kühlung für 42 kW in einem Schrank oder können eine Kombination von Lasten kühlen, solange die gesamte Kühllast in einem Kühlraum nicht 720 kW übersteigt.

Für das GDL kommt eine Kombination aus Technologien zum Einsatz, um einen Betrieb bei maximaler Energieeffizienz erreichen zu können. Zu diesen Technologien gehören:

  • Wann immer möglich wird Außenluft zur Kühlung eingesetzt.
  • Druckgeregelte Kühlung begrenzt die Energie, die von Lüftern und Pumpen verbraucht wird.
  • Höhere Lufttemperaturen (21 °C bis 26,7 °C im Gegensatz zu den üblichen 10 °C bis 15,6 °C) und gekühltes Wasser.
  • Rückgewinnung der Abwärme für Büros usw.

Diese und andere Techniken ermöglichen es, dass für das GDL ein auf das Jahr bezogener PUE-Wert von geschätzt 1,2 erreicht werden kann. Dies ergibt Betriebseinsparungen von 7 Millionen US-Dollar pro Jahr im Vergleich zu einem Betrieb bei einem PUE-Wert von 2,0. Weiterhin ergibt dies eine Verringerung der CO2-Emissionen um 93.000 Tonnen. Weitere Informationen über den NetApp Ansatz zu Effizienz im Datacenter finden Sie in einem kürzlich herausgegebenen White Paper.

Schlussfolgerung

Der NetApp Kilo-Client der nächsten Generation wird sämtliche Vorteile der neuesten Server-Hardware- und Netzwerktechnologie und der NetApp Storage-Hardware und -Software nutzen, um einen flexiblen, automatisierten Prüfstand für Tests zu erstellen, die eine große Anzahl an virtuellen oder physischen Clients benötigen. Nach Fertigstellung wird der Kilo-Client 75.000 und mehr virtuelle Clients bieten können und in der Lage sein, Gigabit-Ethernet, 10-Gigabit-Ethernet, Fibre Channel oder FCoE nutzen zu können – und das End-to-End.

Der Kilo-Client wird nicht nur die Funktionen der vorhandenen Version enorm erweitern, sondern auch die Anzahl physischer Server verringern.

 Ihre Meinung zum NetApp Kilo-Client?

Stellen Sie Fragen, tauschen Sie Ideen aus und teilen Sie Ihre Meinung mit der NetApp Community!

Brad Flanary

Brad Flanary
Engineering Systems Manager
NetApp

Brad Flanary kam 2006 zu NetApp. Aktuell leitet er ein Team aus sechs Ingenieuren, die für das NetApp Dynamic Data Center, das RTP Engineering Data Center und die weltweiten technischen Labornetzwerke von NetApp verantwortlich sind. Bevor er zu NetApp kam, war Brad Flanary sieben Jahre LAN Switching Specialist bei Cisco Systems. Er verfügt über insgesamt 13 Jahre Erfahrung auf dem Gebiet LAN- und Datacenter-Design großer Ausmaße.

Das Kilo-Client Team

Das Kilo-Client Team
NetApp

Das Engineering Support Systems Team besteht aus Brandon Agee, John Haas, Aaron Carter, Greg Cox, Eric Johnston und Jonathan Davis.

 
Weitere Infos hier