© Hyejin Kang, 123RF
Wer skalierbare Clouds bauen möchte, braucht dafür die passende Hardware. Doch welche Server sind die richtigen für Controller, für Storage und für Compute-Knoten?
Cloud-Umgebungen sind komplexe, aufwendige Installationen mit unzähligen Einzelkomponenten. Weil sie nahtlos in die Breite skalieren sollen, gestaltet sich bereits ihre Planung deutlich komplexer als die konventioneller Setups. Verschiedene grundlegende Design-Parameter legt der Admin einer Plattform bereits fest, bevor er auch nur eine einzige Maschine im Rack verbaut.
Wer eine große skalierbare Plattform plant, muss das so tun, dass er sich für später so viele Optionen wie möglich offenlässt. Das ist auf den diversen Ebenen eines Setups unterschiedlich komplex: Compute-Knoten etwa können in ein paar Jahren problemlos leistungsfähiger werden als Systeme der aktuellen Generation. Nötigenfalls ersetzt man vorhandene Systeme durch neue, sobald die älteren aus der Wartung fallen.
Bei kritischer Infrastruktur sieht das schon schwieriger aus: Pfeifen die Netzwerk-Switches auf dem letzten Loch, hilft aller Rumms der Compute-Knoten nicht weiter. Wurde das Netzwerk nicht sinnvoll geplant, lässt sich dessen Hardware auch nicht ohne Weiteres ersetzen oder skalieren. Fehler beim Design einer Plattform sind also eine Kardinalsünde, weil sie sich später nur noch mit erheblichem Aufwand oder im schlechtesten Fall gar nicht mehr korrigieren lassen.
Dieser Artikel zeigt, welche Aspekte es bei der Planung der physischen Seite einer Cloud-Umgebung zu beachten gilt. Dabei beleuchtet er die vier unterschiedlichen Ebenen Netz, Storage, Controller und Compute.
Netzwerk: Offene Protokolle und Linux
Den Auftakt macht das Thema Netzwerk, denn dort laufen im wahrsten Sinne des Wortes sämtliche Fäden zusammen. Wer aus der konventionellen IT kommt und sich zum ersten Mal mit der Planung eines Setups beschäftigt, ist meist daran gewöhnt, dass sich um das Netz ein eigenständiges Team kümmert. In aller Regel billigt es anderen Admins auch kein Mitspracherecht in Sachen zu beschaffender Hardware zu. Regelmäßig gerieren sich solche Firmen dann als Cisco- oder Juniper-Shops, sind also auf einen zentralen Netzwerkausrüster fixiert. In großen Umgebungen stellt eben das allerdings ein Problem dar.
Das liegt nicht zuletzt daran, dass die typische Silo-Bildung konventioneller Umgebungen in Clouds so nicht mehr funktioniert. Zentralisierte Compute-Verwaltung, ganz gleich ob mit OpenStack, CloudStack, OpenNebula oder Proxmox, besteht aus etlichen Layern mit verschiedenen Protokollen. Spätestens wenn Protokolle wie EVPN zum Einsatz kommen, muss Debugging immer verschiedene Schichten der Torte im Blick haben.
Der klassische Netzwerk-Admin, der in seinem stillen Kämmerlein die Switches debuggt, existiert in Clouds so nicht, weil er den Weg von Paketen immer auch über die Grenzen von Linux-Servern hinweg nachvollziehen muss. Mittlerweile ist deshalb das Mantra verbreitet, guten Generalisten als Admins gegenüber den Netzwerk- und Storage-Spezialisten den Vorzug zu geben.
Entscheidendes Thema Zukunftssicherheit
Hinzu kommt beim Thema Netz die Frage nach der Zukunftssicherheit einer bestimmten Lösung. Zweifellos existieren am Markt mehrere leistungsfähige SDN-Ansätze, und jeder große Hersteller hat hierfür ein eigenes Portfolio. Regelmäßig machen sich diese Lösungen auf mehreren Netzwerk-Layern breit, sodass sie mit der jeweiligen Virtualisierungslösung eng integriert sein wollen.
Eine Cloud baut der Admin jedoch nicht für fünf Jahre, um sie dann durch ein anderes System zu ersetzen. Legt man ein Setup auf Jahrzehnte an, lautet eine der zentralen Fragen, ob der Anbieter der SDN-Lösung sie auch in zehn Jahren noch unterstützt. Wird etwa Cisco 2030 OpenStack noch so supporten, dass es in Ciscos SDN-Lösung ACI integriert bleibt? Und wie sieht der Plan für den Fall aus, dass der Support wegfällt? Im laufenden Betrieb lässt sich in einer Plattform das SDN kaum durch eine andere Lösung ersetzen.
Es hat sich nach der Erfahrung des Autors deshalb als sinnvoll erwiesen, in Sachen Netz auf offene Standards wie BGP und EVPN zu setzen. Switches mit Linux bieten Admins eine gewohnte Umgebung (Abbildung 1) und stehen mittlerweile mit Durchsatzraten von bis zu 400 Gbit/s pro Port zur Verfügung (Abbildung 2). Damit lässt sich hervorragend eine typische Spine-Leaf-Architektur bauen. Jedes Rack fungiert dabei als eigene L2-Domain, die Switches nutzen IBGP und routen den Traffic zwischen den Racks im Layer 3 des Netzwerks.
Abbildung 1: Open Networking erlaubt den Betrieb von Switches mit Linux, sodass dem Administrator die gewohnten Werkzeuge zur Verfügung stehen.
Abbildung 2: Netzwerk-Hardware wie diese Mellanox-Switches erreichen heute mindestens 200 Gbit/s pro Port – weniger als 25 GBit/s sollten es keinesfalls sein. Quelle: Mellanox
Anders als bei der klassischen Stern-Architektur hat in einer solchen Umgebung nicht jede tiefere Switch-Ebene weniger Bandbreite zur Verfügung. Kommt man später darauf, dass die Spine-Ebene den Anforderungen der Umgebung nicht länger gewachsen ist, lässt sich aus dem laufenden Betrieb heraus eine zusätzliche Ebene einziehen – völlig ohne Downtime.
Mit Bandbreite geizen sollte der Admin aber bereits heute nicht mehr. 25-Gbit/s-Links per LACP redundant dürfen pro Server gern zur Verfügung stehen, mehr schadet bekanntlich nie.
Offene Protokolle auch in der Cloud
Konstruiert der Admin sein Netz wie beschrieben, erhält er einen komplett agnostischen Transport-Layer für den Overlay-Traffic innerhalb der Cloud. EVPN und IBGP lassen sich aktuell mit den SDN-Lösungen der gängigen Plattformen nur schwer verheiraten. Letztlich ist das aber auch nicht mehr nötig, denn gerade bei Open vSwitch hat sich in den vergangenen Jahren einiges getan: In Form von OVN steht nun ein zentraler Steuermechanismus für Open vSwitch zur Verfügung, der deutlich besser funktioniert als Open vSwitch selbst. Support für OVN findet sich mittlerweile schon in vielen Cloud-Lösungen, allen voran OpenStack. Dort avanciert es zwischenzeitlich sogar zum Standard, sodass ein Ende des OVN-Supports kaum zu befürchten steht.
Speicherfrage: NAS, SAN und SDS
Hat der Admin das Netzwerk geplant und die passende Hardware besorgt, geht es mit dem nächsten wichtigen Thema weiter: Speicher. Auch hier heißt es oft, sich von liebgewonnenen Konventionen zu verabschieden. Zweifelsfrei liegt der Gedanke nah, ein klassisches NAS oder SAN eines Herstellers zu kaufen und per Ethernet an die Cloud anzubinden. Mittlerweile sind solche Geräte auch deutlich günstiger als noch vor ein paar Jahren, weil mehrere Hersteller über eine aggressive Preispolitik versuchen, Fuß in diesem Markt zu fassen. Trotz aller Fortschritte haben zentrale Netzwerkspeicher aber noch immer enorme Design-Probleme. Wie redundant sie intern auch sein mögen, sie bilden stets einen Single Point of Failure. Das wird spätestens dann zum Problem, wenn wegen eines Feuers oder einer ähnlichen Katastrophe der Strom im Rechenzentrum abgeschaltet wird.
Fast noch schlimmer ist bei diesen Geräten allerdings, dass sie ein Skalieren in die Breite kaum sinnvoll erlauben. Wenn eine Plattform in die Breite skaliert, muss ihre zentrale Infrastruktur mitwachsen. Für OpenStack & Co. sind NAS- und SAN-Systeme deshalb kaum eine sinnvolle Option. Obendrein setzt man sich durch den Kauf eines entsprechenden Geräts dem verhassten Vendor-Lock-in aus. Mit Storage aber verhält es sich beinahe so wie mit Software Defined Networking: Ist ein Konstrukt einmal in produktiver Nutzung, lässt sich eine Komponente wie das unter ihr liegende Storage kaum im laufenden Betrieb herauslösen und durch ein anderes Produkt ersetzen. Immerhin ist es in den meisten Clouds möglich, mehrere Storage-Lösungen parallel zu betreiben. Den Aufwand, im laufenden Betrieb Daten von einem auf einen anderen Storage zu kopieren, sollte der Admin sich im eigenen Interesse aber dennoch ersparen.
Zudem gibt es durchaus Lösungen für Software Defined Storage, auch in der Open-Source-Welt. Spricht man von Objektspeichern, ist Ceph mit weitem Abstand der Branchenprimus. Es existieren jedoch auch andere Ansätze, etwa DRBD des Wiener Unternehmens Linbit. Es begann seine Karriere zwar als Replikationslösung für zwei Systeme, versteht sich mittlerweile aber auch auf das Skalieren in die Breite. Dazu legt DRBD in einem Verbund von Servern mit Speichergeräten dynamisch lokal Volumes in der gewünschten Größe an und konfiguriert anschließend automatisch eine Replikation zwischen diesen Ressourcen.
Flash oder nicht, das ist die Frage
Egal, für welche Art von Lösung der Admin sich in Sachen Storage entscheidet, eine zentrale Frage stellt sich dieser Tage fast immer: Setzt man auf langsame Festplatten, auf schnelle SSDs oder auf eine Mischung aus beiden Konzepten? Diese Debatte lässt sich überhaupt erst deshalb sinnvoll führen, weil Flash-basierter Speicher, im Wesentlichen also SSDs und NVMe-Geräte, in den vergangenen Jahren einerseits signifikant billiger wurde und andererseits heute in akzeptablen Größen zur Verfügung steht.
Eine flotte 8-TByte-SSD etwa kostet im freien Handel aktuell knapp 2000 Euro brutto. Der Preis lässt sich zweifellos deutlich drücken, wenn man bei seinem Hardware-Händler des Vertrauens gleich 30 oder 40 Stück davon kauft. In jedem Fall lohnt es sich, die Preisdifferenz zwischen Platten und SSDs zu errechnen.
Exemplarisch sei ein Ceph-Setup angenommen, das anfangs aus sechs Servern bestehen und eine Brutto-Kapazität von 450 TByte haben soll. Die effektiv nutzbare Speicherkapazität liegt also bei 150 TByte. Jeder einzelne Knoten muss insofern 75 TByte zum Gesamtspeicher beisteuern. Eine gute Server-Festplatte von Western Digital kostet etwa 250 Euro, pro Server sind davon zehn notwendig. Stellt man den Festplatten noch SSDs als schnellen Cache für das eigene WAL und die Metadatendatenbank von Ceph zur Verfügung, schlagen die Speichergeräte pro Server mit rund 3500 Euro brutto zu Buche. Hinzu kommt ein 2-HE-Server für etwa 6000 Euro. Pi mal Daumen kostet ein solcher Ceph-Server also ungefähr 10 000 Euro, der gesamte Cluster ist für 80 000 Euro zu bekommen.
Derselbe Cluster mit SSDs kommt auf dem Papier signifikant teurer. Hier kosten die Speichergeräte pro System 18 000 Euro, sodass zuzüglich des Servers selbst rund 24 000 Euro pro Maschine und insgesamt 192 000 Euro brutto auf der Rechnung stehen. Im Gegenzug arbeitet der SSD-basierte Ceph-Cluster aber pfeilschnell, kommt ohne Caching-Tricks aus und bietet zudem alle weiteren Vorteile von SSDs (Abbildung 3). Der Mehraufwand von ungefähr 110 000 Euro rechnet sich außerdem schnell, hält man sich den Gesamterlös eines Racks über die Dauer seiner Lebenszeit vor Augen. Bei mehreren Millionen Euro Umsatz, die ein Rack bei guter Auslastung erreicht, wirken die gut 100 000 Euro zusätzlich schon gar nicht mehr so monströs.
Abbildung 3: SSDs aus Intels “Optane”-Serie kosten zwar deutlich mehr als herkömmliche Festplatten, liefern aber auch eine viel bessere Performance. Quelle: Intel
Storage-Hardware ist oft heikel
Wer sich für eine skalierbare Storage-Lösung der Marke Eigenbau entscheidet, kauft die Komponenten freilich in Abhängigkeit von den spezifischen Bedürfnissen. Anhand der Beispiele Ceph und DRBD lässt sich das gut nachzeichnen.
Wie die Hardware eines Ceph-CLusters grundsätzlich aussehen kann, hat der Artikel bereits beschrieben. Die Zahl der OSDs pro Host sollte zehn nicht überschreiten, sonst würde bei Ausfalls eines Ceph-Knotens erheblicher Resynchronisations-Traffic den regulären Betrieb stören oder sich ewig hinziehen, falls der Admin ihn entsprechend einbremst. Der Trick mit SSDs, die in Ceph den OSDs als schneller Cache zur Seite stehen, ist altbekannt und funktioniert nach wie vor.
Ceph und RAID-Controller spielen nicht besonders gut im Team. Deshalb sollte man RAID-Controller, falls man sie nicht durch einfache HBAs ersetzen kann, im HBA-Modus betreiben. Batteriegestützte Pufferspeicher erweisen sich im schlimmsten Fall eher als hinderlich, weil sie zu unvorhergesehenen Problemen in Ceph führen und es ausbremsen können.
Im Hinblick auf CPU und RAM gilt bis heute die Faustregel, dass Ceph pro OSD einen CPU-Kern und pro angebotenem Terabyte Speicherplatz ein Gigabyte Arbeitsspeicher für sich beansprucht. Für einen Knoten mit zehn OSDs genügt entsprechend eine mittelgroße Mehrkern-CPU in Verbindung mit 128 GByte RAM. Das sind Werte, die bei den meisten Hardware-Herstellern heute eher die untere Grenze der Skala markieren.
DRBD mit höheren Performance-Anforderungen
Wer als Alternative zu Ceph DRBD ins Auge fasst, der braucht dafür fundamental andere Hardware. DRBD ist im Kern deutlich weniger komplex als Ceph; der Fokus liegt hier klar darauf, Daten auf der Blockebene des Linux-Kernels zwischen zwei Blockspeichergeräten hin und her zu kopieren.
Sowohl in Sachen CPU als auch beim RAM sind DRBD-Systeme deshalb ungleich genügsamer als die entsprechenden Server für Ceph. In Sachen Storage-Performance haben sie jedoch deutlich höhere Anforderungen an die einzelnen Geräte als Ceph, da DRBD anders als Ceph seine Writes nicht auf viele Spindeln überall im System verteilt.
Der Admin kann leistungsfördernd eingreifen, indem er das Activity Log von DRBD auf schnellen Speicher legt. Dieses Journal erhält jeden Write, um ihn auf das Storage-Backend zu schreiben. Kommt hier NVMe zum Einsatz, nutzt das merklich. Auch batteriegestützte Pufferspeicher bringen DRBD nicht aus dem Tritt.
Compute: Die Kunst der Kalkulation
Hat der Administrator es bis hierher geschafft, steht er vor dem letzten Teil des Hardware-Puzzles, der Hardware für die Compute-Knoten. Zwar ist Compute nur einer der beiden Dienste, den Cloud-Umgebungen üblicherweise zu erbringen haben (der andere ist Storage). Ein S3-kompatibles Interface gehört bei den gängigen Objektspeichern jedoch mittlerweile fast immer zum Lieferumfang, sodass beispielsweise ein Ceph den Storage-Teil einfach selbst übernimmt. Ohnehin ist Compute aber die häufiger nachgefragte Dienstleistung.
Eine einfache Antwort auf die Frage, welche Hardware für Compute infrage kommt, gibt es nicht. Hier spielen mehrere Faktoren eine wichtige Rolle. Zumindest im Public-Cloud-Kontext gilt: Bigger is better. Plattformen dieser Art lassen sich nur dann gewinnbringend betreiben, wenn sie schnell wachsen. Die Marge liegt aber nicht in der Kombination aus Storage und Compute, wie viele Admins vermuten.
In großen Ceph-Clustern kostet ein einzelnes Gigabyte in der Herstellung deutlich unter einem Cent, und selbst mit einer Datennutzung im Terabyte-Bereich und hoher Deckung zahlt der Kunde für Storage in Summe recht wenig. Ausschlaggebend ist für den Admin stattdessen der Preis einer einzelnen virtuellen CPU im Verkauf abzüglich der dafür aufgewendeten Herstellungskosten. Über diesen Faktor skaliert die Firma ihren Umsatz mit der Plattform, und damit letztlich auch den eigenen Gewinn.
Die Frage, welche Hardware für Compute infrage kommt, ist also unmittelbar an den Preis einer einzelnen vCPU gekoppelt. Der wiederum ergibt sich aus der Anzahl der verfügbaren CPUs pro Vergleichseinheit. Was theoretisch kompliziert klingt, ist in Wahrheit recht simpel zu kalkulieren. Der Admin bewaffnet sich dazu mit einer Tabellenkalkulation seiner Wahl.
Gegeben sei ein vollständiges Rack mit 42 Höheneinheiten, von denen jedoch mindestens zwei HE für die notwendige Netzwerk-Hardware reserviert bleiben. In den meisten Rechenzentren gibt es zudem eine maximale Menge an Strom pro Rack, sodass man im Regelfall 16 bis 18 Server mit jeweils zwei Höheneinheiten in einem solchen Rack unterbringen kann.
Zunächst hat der Admin die Aufgabe, sämtliche Kosten pro Monat zu erfassen, idealerweise für einen Zeitraum von fünf Jahren. Dazu gehören Strom, Klimatisierung und normale Maintenance ebenso wie der Aufwand für die Installation des Racks, überschlagener Aufwand für Hardware-Reparaturen und eventuell anfallende Kosten für Support. Am Ende steht eine Liste aller Kosten, aufgeschlüsselt pro Monat. Daraus wiederum lassen sich die monatlichen Gesamtkosten für zwei HEs im Rack herleiten (Abbildung 4).
Abbildung 4: Server wie Dells R740 eignen sich als 2-HE-Gerät sowohl für Storage- als auch für Compute-Server. Quelle: Dell
Klare Sache: Overcommit ist Standard
Im nächsten Schritt gilt es herauszufinden, wie viel Geld eine einzelne vCPU einspielen muss, um die Unkosten zu decken und Gewinn zu machen. Dafür multipliziert der Admin ganz banal die tatsächlich zur Verfügung stehenden Cores des Server mit einem Overcommit-Faktor (zum Beispiel 4) und erhält so die Anzahl der verkaufbaren vCPUs pro zwei Höheneinheiten. Im letzten Schritt legt er eine adäquate Deckungssumme pro vCPU fest und erhält letztlich den Verkaufspreis.
Wichtig: Pro Rack sollte der Admin über die gesamte Plattform hinweg stets eine Sicherheitsreserve von 20 Prozent einplanen, die auch den typischen Verschnitt einbezieht. Obendrein verdient ein Rack nicht ab dem ersten Tag Geld; die Kosten pro vCPU muss man also so berechnen, dass am Ende der Lebensdauer des Racks dieses seinen geplanten Gewinn gemacht hat.
Apropos Overcommit: Was vielen Admins Bauchschmerzen bereitet, ist in großen Virtualisierungsumgebungen de facto die Standardherangehensweise. Dass ein spezifischer Workload tatsächlich die eigenen vCPUs permanent zu 100 Prozent nutzt, kommt praktisch nie vor, und wenn doch, dann nicht für alle VMs pro physischem Server gleichzeitig. Ohne einen Overcommit-Faktor würde sich ein großer Teil der Hardware pro Rack folglich langweilen.
Die beschriebene Kalkulation macht eines übrigens sehr deutlich: Je mehr vCPUs pro zwei Höheneinheiten zur Verfügung stehen, desto größer der Gewinn, den der Admin mit dem Rack auf dessen Lebensdauer gerechnet macht. Anders ausgedrückt: Je mehr vCPUs sich auf dieselbe Fläche pressen lassen, desto besser ist das aus kommerzieller Perspektive.
Zwingende Folgerung: AMD statt Intel
Die konkreten Hardware-Empfehlungen für Compute-Hardware sind deshalb klar. Aktuelle AMD-Epyc-CPUs liefern nicht nur mehr Kerne für weniger Geld, sie performen auch in praktisch allen aktuellen Benchmarks besser als ihre Intel-Pendants. 2-HE-Systeme sind Standard, und der einzige Storage in den Compute-Knoten sollten zwei kleine SSDs sein, auf denen das System landet.
Den Speicher für virtuelle Maschinen realisieren alle gängigen Clouds heute über per Netzwerk angebundenen Speicher, sodass weiterer lokaler Storage überflüssig ist – zumindest dann, wenn man sich an die Empfehlung des Artikels hält und sein Software Defined Storage nicht hyperkonvergent nutzt.
Das Verhältnis von RAM und vCPUs
Viele Admins neigen dazu, ihre Server mit extremen Mengen RAM ins Rennen zu schicken und unter 512 GByte pro Maschine gar nicht erst anzufangen. Ob das sinnvoll und notwendig ist, hängt von der Anzahl der vCPUs pro Server ab und von der Stückelung, die der Admin annimmt.
Angenommen, pro zwei HE seien zwei CPUs mit jeweils 64 physischen Kernen verfügbar. Zieht man acht Kerne ab, bleiben 120 physische Kerne übrig, die durch Hyperthreading zu 240 Kernen werden. Geht man von einem Overcommit-Faktor von 4 aus, wären in diesen zwei HE also insgesamt 1000 vCPUs verfügbar. Bei 512 GByte RAM entspricht das Pi mal Daumen 2 GByte RAM pro vCPU – das geht noch in Ordnung, kratzt jedoch eher an der unteren Grenze. Ein Terabyte RAM wäre in solchen Systemen folglich die bessere Variante. Das Verhältnis 1:4 ist typisch.
Das bedeutet freilich nicht, dass Kunden nicht auch regelmäßig nach anderen Stückelungen fragen. Hier sollte der Admin achtsam sein: Wünscht ein Kunde sich für besonders speicherintensive Aufgaben Systeme mit wenigen vCPUs und viel RAM, lassen sich die verbliebenen vCPUs des Systems, auf dem diese VMs laufen, nicht mehr nutzen – ihnen steht kein RAM mehr zur Verfügung.
Das im Fachjargon als Verschnitt bezeichnete Problem kann zur echten Gefahr für den gesamten Business Case werden. Regelmäßig versuchen Unternehmen, sich solchen Sonderwünschen durch die Preisgestaltung zu entziehen, indem sie also die speicherlastigen Hardware-Profile merklich teurer vermarkten als jene mit dem gewünschten Verhältnis von vCPUs und RAM.
Sinnvoller (Um-)Weg: Cluster-Workstations
Beinahe jede Virtualisierungslösung benötigt etliche Dienste, damit sie reibungslos funktioniert. Am Beispiel von OpenStack lässt sich das gut zeigen, ganz gleich, ob man eine Distribution von Canonical oder Red Hat kauft: DNS, NTP und andere Dienste sind zwingende Voraussetzung.
Es hat sich nach Erfahrung des Autors als sinnvoller Weg herausgestellt, diese Dienste auf einem eigenen HA-Cluster zu betreiben. Der sollte mit dualen Mehrkern-CPUs ausgestattet sein und mindestens über 256 GByte RAM sowie mehrere Terabyte Plattenplatz verfügen, um nötigenfalls mehrere VMs für die unterschiedlichen Dienste zu betreiben.
Hier spielt meist auch noch das Thema Compliance hinein, weil für externe Verbindungen andere Regeln gelten als für interne. VMs müssen dann, je nach Ziel, doppelt betrieben werden.
Spezial-Hardware für den Fernzugriff
Abschließend sei auf einen Faktor hingewiesen, den viele Admins bei der Arbeit in Cloud-Umgebungen aus den Augen verlieren und auch in der Planung vergessen: den Remote-Zugriff. Er ist meist über die Out-of-Band-Schnittstellen der Server implementiert, die üblicherweise dafür auch eine separate Netzwerkkarte zur Verfügung stellen. Das bedeutet konkret aber, dass der Admin ein komplettes Netz für den Zugriff auf die Management-Schnittstellen bauen muss, inklusive eigener Switches. Alternativ lassen sich auch die Switches für die Server benutzen, die meistens jedoch mit SFP-Ports ausgestattet sind. Klassische Management-Schnittstellen hingegen setzen auf RJ45, sodass entsprechende Optiken benötigt werden (Abbildung 5).
Abbildung 5: Out-of-Band-Schnittstellen nutzen in der Regel RJ45, während die meisten modernen Switches SFP oder QSFP nutzen. Quelle: Dell
Fazit
Die richtige Hardware-Zusammenstellung für die eigene skalierbare Umgebung zu finden, ist letztlich keine Hexerei. Sie zu finden, erfordert aber gründliche Planung im Vorfeld, und gerade das Berechnen der letztlichen Verkaufspreise ist ein elementarer Schlüssel zum Erfolg. Wer mit einer skalierbaren Umgebung als Anbieter groß herauskommen möchte, der darf den Aufwand dafür allerdings nicht scheuen. (jcb)
