Richard Semik, 123rf.com

Immer wieder erscheinen Berichte, dass die Ära des ARM-Servers beginne. Beispielsweise stehe der Einzug ins Rechenzentrum unmittelbar bevor. Ist das wirklich wahr? Der Artikel trägt den Status quo zusammen.

Per Design besteht ein ARM-Prozessor [1] aus deutlich weniger Bauteilen als beispielsweise eine Intel-CPU, was die Herstellungskosten senkt. Quasi als Bonus entwickeln sie weniger Wärme und benötigen weniger Strom. So ist es auch nicht verwunderlich, dass Hersteller mobiler Kleingeräte wie Smartphones bevorzugt auf diese Architektur zurückgreifen. Mit Android ist auch ein Linux immer noch mit von der Partie – damit ist aber noch lange nicht Schluss.

Im Rechenzentrum

Dass Linux mit der ARM-Architektur (Abbildung 1) zusammenarbeitet, versteht sich von selbst. Aber warum sollte man die CPUs im Rechenzentrum einsetzen? Mit HP [2] und Dell [3] glauben zumindest gleich zwei große Hardwarehersteller an ARM-Server im großen Stil. Tabelle 1 zeigt die Server von HP und Dell im Vergleich. Bei Dell ist eine Festplatte pro Server fest verbaut. Bei HP wählt der Admin zwischen Server und Storage. Die normierte Anzahl der Server sieht analog zu Dell einen Datenträger pro Server vor.

Abbildung 1: Ob NAS oder Rasbperry Pi – ARM ist aus dem Haushalt nicht mehr wegzudenken.

Die Gründe für den Einsatz dieser Architektur: geringere Herstellungs- und Betriebskosten. Spätestens mit dem Siegeszug der Smartphones ist die ARM-Technologie Massenware, was die Chips auch preislich interessant macht.

Was fehlt noch für die Rechenzentrums-Tauglichkeit? Genau genommen sind das mehrere Fragen: Gibt es Verwaltungsschnittstellen wie IPMI (Intelligent Platform Management Interface), um Hunderte oder Tausende von ARM-Servern zentral zu verwalten? Existieren Portierungen der entsprechenden Software für die neue Architektur? Erst seit reichlich einem Jahr verfügt ARM über einen 64-Bit-Befehlssatz [4] – ist 32 Bit überhaupt noch zeitgemäß? Ersetzt diese Architektur die Virtualisierung oder erweitert sie das Anwendungsfeld? Zu diskutieren ist auch, ob versteckte Kosten die Vorteile des geringeren Stromverbrauchs und bei der Abwärme wieder auffressen.

Die harte Tour

Der Ansatz, dass nicht der Designer die Chips produziert, ist zweischneidig. Man könnte argumentieren, dass es so deutlich mehr mögliche Hersteller gibt, was der Verbreitung an sich hilft und dem Erfolg nicht wirklich schadet. Allerdings sieht sich der Einkäufer mit einer Vielzahl von Implementierungen konfrontiert und muss in mühevoller Kleinarbeit die richtige aussuchen.

In diesem Zusammenhang fällt häufig der Begriff System-on-Chip (SoC). Typischerweise statten die Hersteller den Prozessor mit weiteren Komponenten aus, die normalerweise einen Computer ausmachen. Dazu gehören der Hauptspeicher, Peripheriegeräte wie USB oder Ethernet und eine Art Netzteil. Es ist schwer zu glauben, dass dies der Hardware-Standardisierung hilft. Der hohe Grad an Hardware-Vielfalt hat signifikante Auswirkungen auf die Verwaltung von Linux, das darauf laufen soll. Im ungünstigsten Fall benötigt das System pro Hardware einen eigenen Kernel.

Zum Vergleich: Auf x86-Servern laufen die gängigen Enterprise-Kernel fast unabhängig vom eigentlichen Hardwarelieferanten. Wenn sich das Modell von HP und Dell durchsetzt, bereitet die bunte Vielfalt der ARM-Hardware keine Probleme mehr, da beide Hersteller signifikant in den Rechenzentren vertreten sind. Die eventuell schon vorhandenen Prozesse sind dann einfach wiederverwendbar oder leicht anzupassen. Auch ist die verwendete Hardware homogen und die Notwendigkeit, einen ganzen Strauß an Linux-Kerneln zu verwalten, entfällt.

Ein weiteres Merkmal für die Praxistauglichkeit im Rechenzentrum ist das Verwalten der Server aus Hardware-Sicht à la IPMI. Die Integration eines entsprechenden Chips auf der SoC-Platine ist wohl eher unwahrscheinlich. HP (Abbildung 2) beispielsweise versieht das Gehäuse mit einer entsprechenden Schnittstelle und der Möglichkeit, die einzelnen Einschübe zu verwalten. Dieser Ansatz bewährte sich schon bei den Blade-Servern und hat damit gute Erfolgsaussichten.

Abbildung 2: HPs ARM-Server besteht aus vier Einschüben, die wahlweise Festplatten oder SoCs enthalten.

Bitte ein Bit

Erst Ende 2011 erweiterte ARM Holdings das Design der Version 8 mit einer 64-Bit-Architektur. Der größte Nachteil der 32-Bit-Version ist, wie hinlänglich bekannt, die Speicherverwaltung, die ohne Hilfsmittel nur 4 GByte RAM ansteuert. Damit schloss sich ARM selbst für den Betrieb von speicherintensiven Anwendungen aus. Die Vorgängerversion bot eine Art Workaround mit der so genannten Large Physical Address Extension (LPAE, [5]), die zumindest 40 Bit zur Adressierung von Hauptspeichern erlaubt. Dennoch: Wer jetzt auf ARM setzt, sollte zumindest für den Anfang mit 32 Bit rechnen und das für seine Anwendungsfälle entsprechend beachten.

Bezogen auf die Rechenleistung kann ARM sich nicht mit der Konkurrenz von Intel und AMD messen. Vielleicht ändert sich das mit künftigen ARM-Versionen – doch ist der Vergleich für sich nicht ausreichend für eine professionelle Gesamtbewertung, da sie nur eine Dimension der Kostenbetrachtung darstellt.

Bei der Kosteneffizienz schlägt ARM die Xeon-bestückten Server aber deutlich. So kostet der HP Redstone mit 1600 Serverknoten etwa 1,2 Millionen US-Dollar und begnügt sich mit einer Leistungsaufnahme von 9,9 Kilowatt. Ein in der Leistung vergleichbarer Xeon-Server mit 400 Knoten kostet dagegen etwa 3,2 Millionen US-Dollar und benötigt 91 Kilowatt.

Auch wenn der große Hype um die Virtualisierung abflacht, ist diese Technik nach wie vor eine gute Option, um die vorhandenen Rechnerkapazitäten möglichst effizient zu nutzen. Zieht man den Vergleich mit der x86-Welt, stellt sich die Frage, wie es bei ARM im Hinblick auf Virtualisierung aussieht. Wegen der eingeschränkten Rechenpower ist nur der Hardware-basierte Ansatz von Belang.

Optionaler Bestandteil des ARM-Designs ist seit Version 7 die so genannte Virtualisierungserweiterung, die die Prozessoren Cortex-A7 und -A15 bereits mitbringen. Auf der Hypervisor-Seite gibt es ebenfalls erste Erfolge zu verzeichnen ([6] bis [9]). Doch macht sich die jahrelange Beschränkung auf 32 Bit bemerkbar – gegenwärtig ist es nicht möglich, 64-Bit-Gäste über die ARM-Virtualisierungserweiterung zu betreiben.

Braucht man aber überhaupt Virtualisierung auf ARM? Prinzipiell könnte man die einzelnen Server mit den Gästen unter KVM und Xen vergleichen. Chassis-Firmware entspricht dann dem Hypervisor. Rechenjob-Verteiler und Hochverfügbarkeits-Werkzeuge runden das Bild der “Virtualisierung zum Anfassen” ab.

Die Software

Zentral ist zudem, welche Betriebssysteme und Anwendungen die ARM-Server unterstützen. Linux erfüllt hier wieder einmal die Erwartung, dass es quasi auf jeder Hardware läuft. Aus dem Feld der bekanntesten Vertreter im x86-Umfeld warten Ubuntu, Debian, Fedora, Arch Linux und Open Suse mit ARM-Varianten ihrer Distribution auf. Im professionellen Einsatz kommt aber der Anspruch der Enterprise-Tauglichkeit dazu, sodass zurzeit nur Ubuntu LTS in Frage kommt. Eine Sonderrolle spielt das auf Open-Source-Software für ARM spezialisierte Linaro [10]. Interessanter ist aber die Frage: Welche Anwendungen gibt es aktuell für diese Architektur?

Das einfache Heranziehen der Liste der x86-Anwendungen für den Abgleich wäre nicht sehr geschickt, da die Hardware nicht in diesem Sinne vergleichbar ist. Für welche Art von Diensten eignen sich die ARM-Server? Allgemein müssen die geeigneten Anwendungen gewisse Eigenschaften erfüllen: keine x86-Abhängigkeit, leicht parallelisierbar und Ressourcen-schonend. Derzeit fällt eventuell noch die 32-Bit-Beschränkung ins Gewicht.

In Anbetracht dieser Einschränkungen prädestiniert sich ARM für den Einsatz als Webserver (Abbildung 3). Entsprechend bietet Apache seine Software auch für diese Plattform an. Das Hadoop-Umfeld, das auf Scale-out ausgelegt ist, reiht sich ebenfalls ein. Sowohl die Apache-Distribution des Map-Reduce-Frameworks [11] als auch die Datenbank Cassandra [12] sind für ARM erhältlich. Openstack [13] ist ebenfalls mit von der Partie. Die Anhänger der verteilten Dateisysteme finden im Netz Softwarerepositories für CEPH [14] und Gluster-FS.

Abbildung 3: Der Apache-Benchmark spricht eine deutliche Sprache: Im Einsatz als Webserver verbraucht die ARM-CPU bei vergleichbarer Leistung signifikant weniger Strom.

Genau genommen stehen fast alle bekannten Vertreter der Open-Source-Szene auch für ARM zum Einsatz bereit. Firmen wie Oracle fahren hier zweigleisig. Während sie Java auch für die Niedrig-Energie-Plattform anbieten [15], sucht man nach anderen kompatiblen Oracle-Produkten vergeblich. Auch der HPC-Markt hat die Architektur jenseits von x86 entdeckt. MPI-Software (Message Parsing Interface) wie MPICH [16] oder Open MPI [17] sind ebenso verfügbar wie Bibliotheken für BLAS (Basic Linear Algebra Subprograms, [18]) oder die schnelle Fourier-Transformation.

Beim Thema Sicherheit sind für ARM-Server eigentlich keine neuen Paradigmen zu beachten. Die physikalische Zugriffsbeschränkung ist analog zu den x86-Kollegen vorzunehmen. Die höhere Server-pro-Quadratmeter-Dichte lässt eventuell zu noch mehr Vorsicht raten. Auf der Betriebssystem-Seite ändert sich ebenfalls nichts. Es ist anzunehmen, dass die Anzahl der lokalen Cracker-Werkzeuge für ARM übersichtlicher ist als in der x86-Welt. Gleichzeitig funktionieren sehr wahrscheinlich nicht-lokale Exploits für diese Plattform ebenso.

Durch Secure Boot ist der Bios-Nachfolger UEFI vor allem bei Linux-Anwendern verstärkt in den Fokus gerückt. Da ARM schon seit 2008 dem UEFI-Forum angehört, wundert es nicht, dass Boards von Arndale diese neuen Schnittstellen bereits mitbringen. Das Thema Sicherheit und sicheres Booten steckt hier noch in den Kinderschuhen. Die Linux Foundation, die sich im x86-Umfeld stark für eine Secure-Boot-Lösung für Linux engagiert hat [19], sieht deutlich weniger Handlungsbedarf für die ARM-Architektur.

Fazit

Die Zeichen für ARM-Server stehen auf Erfolg. Große Hardwarehersteller bieten schon entsprechende Produkte an, das Software-Angebot kann sich sehen lassen und mögliche Anwendungsfelder gibt es ebenfalls. Maßgeblich für den Erfolg wird die Antwort auf die Frage sein, ob Leistung-pro-Watt über Leistung-pro-Zoll Bauhöhe siegt. Da auch große Rechenzentren erwägen, Rechner mit ARM-Prozessoren anzuschaffen, zeigen die Daumen für diese Architektur auch im Business-Umfeld tendenziell nach oben.