Am Rande des Open-Stack-Summits in Atlanta hat Ubuntus Server-Team mit Open Stack 168 000 Cloud-OS-Instanzen auf AMD-Hardware laufen lassen. Dafür mussten die Admins einige Bugs umschiffen.
AMD lieferte demnach die Hardware für das Experiment, die aus zehn Seamicro SM15000-Systemen bestand. Jedes davon verfügt dabei über 64 CPUs mit je 8 logischen Kernen, 32 GByte RAM und 500 GByte Speicher, angebunden über einen Storage Fabric Controller.
Wie nicht anders zu erwarten, setzen die Canonical-Mitarbeiter beim Deployment auf Ubuntus Service Orchestration Tool Juju und den Metal-as-a-Service-Dienst Maas. Passend zum Summit kamen zudem die Open-Stack-Version Icehouse und das Cloud-OS Cirros zum Einsatz. Open Stack wurde dabei mit Hilfe von Charm Bundles aufgesetzt, die mehrere Charms miteinander kombinieren.
Im Zuge ihrer Experimente, über die James Page von Canonicals Serverteam in seinem Blog detailliert berichtet, stießen die Entwickler auf mehrere Hindernisse. Während etwa die Compute-Komponente Nova Subprozesse für jeden Core anstößt, musste die Netzwerk-Komponente Neutron dabei passen. Es kam zu Timeouts, weil die Nova Nodes vergeblich auf die virtuellen Interfaces (VIF) warteten. Neutron kann allerdings Worker Threads erzeugen, also passten die Entwickler den Nova-Cloud-Controller-Charm an.
Ein weiteres Problem: Bei 170 Instanzen pro Compute Server kam es zu Timeouts der Agents, weil das Anlegen der Iptables zu lange dauerte. Der Bug ist noch offen, die Entwickler schalteten vorübergehend die Iptables-Einstellungen auf VIF-Ebene ab, was in der Praxis sicherlich keine Option wäre. Bei 27 000 Instanzen auf 118 Compute Nodes brauchten die Instanzen schon etwas länger für die Aktivierung. Im weiteren Verlauf patzte Jujus Bootstrap-Knoten beim Knüpfen der Verbindungen zwischen den Diensten, die Load wurde zu hoch. Auch hier wurde ein Bugreport aufgesetzt und die Knoten nach und nach ergänzt, um das Problem zu umgehen.
Als nächstes stieß der Messaging-Server Rabbit MQ auf seine Limits an konkurrierenden Verbindungen. Diese ließen sich allerdings hochsetzen, der “rabbitmq-server”-Charm wurde entsprechend angepasst. Zu diesem Zeitpunkt liefen vier Seamicro-Systeme mit 55 000 Knoten. Nach Beschwerden des Monitoring-Systems Ganglia wurde ein weiterer Nova-Cloud-Controller aktiviert, der das System entlastete.
Beim Aufsetzen weiterer paralleler Instanzen kam es allerdings zu Problemen. Bei sechs eingebundenen Seamicro-Systemen wurden zu viele Nachrichten zwischen Neutron, Nova und Rabbit MQ ausgetauscht. Instanzen wurden nicht mehr ordentlich aufgebaut. An diesem Punkt entschieden die Admins, sich von Neutron zu verabschieden und das Networking über Nova zu erledigen.
Nach 11 Stunden liefen 100 000 Instanzen auf den zehn AMD-Systemen. (Quelle: http://javacruft.wordpress.com)
Nach knapp 11 Stunden waren 100 000 Instanzen online, die auf sechs Systemen und 384 Servern liefen. Beim Ergänzen der Knoten 8 und 9 kam es zu einem weiteren Problem, weil die Hardwaredaten abwichen und der Scheduler von Nova beim Aufsetzen der Instanzen die VCPU-Werte nicht berücksichtigte und zu viele Instanzen auf die Hardware der Systeme 8 und 9 verlagerte. Hier galt es, den Scheduler anzupassen und die Core-Filter zu aktivieren. Zugleich brauchte Juju nun ziemlich lange, um weitere Units zu ergänzen. Trotz dieses letzten Bugs gelang es dem Team am Ende, 168 000 Instanzen parallel auf zehn AMD-Systemen zu betreiben. Weitere Details zum Experiment liefert der anfangs erwähnte Blogeintrag.
