Scaleway schaltet ARM-Instanzen ab, ich migrierte

Am 14. April schickte mir Scaleway diese Email:

C2 & ARM64 Instances end-of-life — Migrate now to Virtual Instances & Bare Metal cloud servers

Dear customer,

As of December 1 st, 2020, our C2 and ARM64 Instances will reach their end-of-life. The physical servers hosting them are indeed randomly affected by several stability issues, which prevent us from fully guaranteeing the overall quality of service. Rest assured, however, that we are committed to guiding you in your migration and provide you with the best matching resources for improved stability, performance and reliability.

Starting from April 14th, 2020, it is no longer possible to create new C2 and ARM64 Instances. In addition, their support will end on July 1st, 2020. As a result, our technical assistance will no longer address issues related to those instances. A price increase is also to be expected on July 1st, 2020. Lastly, C2 and ARM64 Instances will be completely deprovisioned as of December 1st, 2020.

Das betraf direkt alle drei meiner Scaleway-Instance. Ich hatte zwei kleine ARM64-Instanzen, von denen eine diesen Blog und die andere einen Microservice für pc-kombo betrieb. Die dritte war eine C2-Instanz, auf der pc-kombo selbst lief. Diese Email bedeutete für mich also vor allem Arbeit. Aber ich war gar nicht arg verärgert: Hosterwechsel oder zumindest Serverwechsel sind ja immer auch eine Chance, etwas schnelleres zu erwischen. Beides war richtig: Es war eine Menge Arbeit, und alle drei Projekte dürften jetzt schneller sein.

Blog: Scaleway zu Vultr

Den Anfang machte die unkritischste Seite, dieser Blog. Ich wollte wieder eine möglichst günstige Lösung haben. Spart Geld, aber nicht nur das: Ein Serverchen sollte für die Besucheranzahl dieser Seite auch wirklich ausreichen, zudem kann es für Serendipity nur gut sein, wenn ein weiterer Entwickler Performance auf schwächeren Servern durch den eigenen Blog im Blick hat.

Ich bin dann bei Vultr gelandet. Das waren die möglichen Angebote:

Als ich dann nach etwas Recherche feststellte, dass dank Cloudflare auch IPv4-Besucher die Seite erreichen würden, wählte ich das günstigste Angebot, das nur mit IPv6 auskommt.

Was ich da noch nicht wusste: Github kann kein IPv6. Serendipity will aber mit Github kommunizieren, um Plugins und sich selbst zu aktualisieren. Da hilft dann auch Cloudflare nicht. Aber so entstehen eben neue Serendipity-Entwicklungen: Es gibt jetzt einen Mirror auf Gitlab, der Pluginupdates ausliefern kann und der Code dafür ist im aktuellen Master. Jetzt fehlt nur noch, die Versionsprüfung und das Autoupdate-Plugin ebenfalls auf Gitlab zurückfallen zu lassen.

Wie schlug sich vultr selbst? Ziemlich gut. Die Verwaltungsoberfläche ist simpel und funktioniert, auch beim Server gab es keine Überraschungen. Der einzelne Prozessorkern war im Benchmark stärker als ein ARM64-Kern von Scaleway:

Scaleway:

root@onli-blogging-armv8:~# sysbench --test=cpu --cpu-max-prime=10000 run
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
sysbench 1.0.20 (using bundled LuaJIT 2.1.0-beta2)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time


Prime numbers limit: 10000

Initializing worker threads...

Threads started!

CPU speed:
    events per second:   619.61

General statistics:
    total time:                          10.0017s
    total number of events:              6202

Latency (ms):
         min:                                    1.55
         avg:                                    1.61
         max:                                   16.27
         95th percentile:                        1.70
         sum:                                 9977.69

Threads fairness:
    events (avg/stddev):           6202.0000/0.00
    execution time (avg/stddev):   9.9777/0.00

vultr:

root@onli-blogging:/var/www/html# sysbench --test=cpu --cpu-max-prime=10000 run
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
sysbench 1.0.18 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time


Prime numbers limit: 10000

Initializing worker threads...

Threads started!

CPU speed:
    events per second:   752.41

General statistics:
    total time:                          10.0013s
    total number of events:              7528

Latency (ms):
         min:                                    1.19
         avg:                                    1.33
         max:                                    8.34
         95th percentile:                        1.47
         sum:                                 9984.29

Threads fairness:
    events (avg/stddev):           7528.0000/0.00
    execution time (avg/stddev):   9.9843/0.00

Andererseits hatte die Scaleway-Instanz 4 dieser Kerne, war also insgesamt deutlich stärker. Im Betrieb aber fühlt sich die Seite seit dem Wechsel schneller an. Entweder, weil bei einzelnen Besuchern immer nur der eine stärkere Kern zählt, vielleicht ist die SSD schneller angebunden, oder es ist einfach die neuere Linuxversion.

Es gibt sogar ein affiliate-Programm, wer über diesen Link einen Account macht und selbst $10 ausgibt schenkt mir $10. Und derzeit läuft eine Sonderaktion, die dem sich darüber anmeldenden Nutzer für 30 Tage $100 gibt, der erste Monat also umsonst wäre. Nett.

Der Wechsel zu vultr war also gut, es war aber einiges an Arbeit weil die Emails nicht funktionieren wollten. Sie gingen einfach nicht raus, auch wenn ich mein Bestes versuchte die Konfiguration der Scaleway-Installation zu kopieren. Wahrscheinlich war der Port blockiert? Ich musste das neu einrichten, mit uberspace als Relay. Das herauszufinden kostete mich Stunden.

PC-Kombo: Scaleway zu Scaleway

Für pc-kombo bin ich nach einiger Recherche bei Scaleway geblieben. Ich brauchte folgendes:

1. Mehrere Kerne, damit problemlos mehrere Dienste parallel laufen können und auch Besucherspitzen abgefangen werden können.
2. Genug Ram, um weiterhin die Seite mit LRU-Cache und Memoization zu beschleunigen.

Natürlich kriegt man das auch anderswo, im Zweifel für viel Geld. Hetzner zum Beispiel hätte ohne hohen Preis gepasst, da liegt allerdings schon Pipes, zu riskant. Am Ende waren die Angebote bei Scaleway für mich die attraktivsten. Großer Pluspunkt: Die Migration innerhalb Scaleways sollte einfach sein, oder?

Falsch: Ich lief da ins offene Messer. Als ich die C2-Instanz herunterfuhr um mit dem Management-Interface ein Backup zu machen und dann komfortabel mit Scaleways Bordmitteln auf einer neuen DEV-Instanz die Seite wieder einzurichten, dieser Anleitung folgend, fuhr sie nicht mehr hoch. Scaleway hatte meine Instanz weggegeben oder ganz abgeschaltet und keine Reserven mehr über. Es gab eine üble und hektische Downtime, in der ich mittels meiner eigenen Backups (Gott sie dank hatte ich die!) die Seite wieder einzurichten versuchte und parallel den Migrationsanweisungen von Scaleway folgte, die dann nur mit Supporthilfe funktionierten. Zusammenschrieb hier.

Das war also Mist. Immerhin: Seitdem funktioniert die Seite auf der neuen DEV-Instanz ohne weitere Probleme.

Mikroservice: Scaleway zu Heimserver

Ich habe hier daheim zwei kleine ARM-Miniserver: Einen Pogo und einen CHIP. Erst wollte ich damit die Scaleway-Instanz mit dem Mikroservice ersetzen. Stellte sich aber raus, dass der CHIP nicht stabil läuft und der Pogo keine Kapazitäten mehr frei hat, dass der Speicher und Prozessorbedarf meines Services (Preisaktualisierungen laufen darüber, XML, JSON und CSV muss geparst werden) für die beiden auch etwas zu hoch ist. Aber worüber ich noch gar nicht geschrieben habe: Für die Wissenschaftlerin im Haus lag hier auch noch ein alter Dual-Xeon-Server rum, ein HP Proliant G6, mit 48GB Ram. Der wäre definitiv stark genug.

Für den Test mit dem CHIP hatte ich den Service schon so umgebaut, dass eine ausfallende Internetverbindung kein Problem ist, er wartet dann einfach. Schnelles Internet wird auch nicht benötigt. Kritisch war der Lärm. Ich verwandte etwas Zeit darauf, den Server so leise wie möglich zu machen: Stromsparmodus (sowieso eine gute Idee), die Xeons sind auch untertaktet stark genug, keine Redundanz der Netzteile. Dann brauchte ich noch einen Platz, der etwas Lärm frisst und sich nicht zu stark aufheizt. Es wurde ein Wandschrank mit jetzt nur noch angelehnter Tür.

Das ist vielleicht auf Dauer nicht die günstigste Lösung aufgrund des Stromverbrauchs. Andererseits ist es nett, mal etwas mehr (und ansonsten richtig teure) Rechenleistung zur Hand zu haben. Ich habe direkt noch weitere Aufgaben für ihn im Blick. Was die kleine Scaleway-Instanz noch überforderte ist für den alten Server ein Kinderspiel, er langweilt sich.

Die Migration ist beendet. Keine meiner Seiten/Projekte liegt noch bei Scaleways ARM-Instanzen, die sie abschalten. Für Scaleway nicht ganz so toll: Obwohl ich ihnen als Kunde erhalten bleibe ist meine Monatsrechnung dort jetzt geringer, zudem kommt mit vultr ein weiterer günstiger und solider Hoster zu den von mir getesteten und positiv befundenen (Scaleway, Digital Ocean, Hetzner Cloud, vultr). Trotzdem ist die Abschaltung sicher richtig: Auch ich sah vorher Instabilitäten, gerade der Mikroservice lief nicht sauber. Sowas zu bereinigen vermeidet Enttäuschungen. Andererseits schade, dass jetzt keine günstige Bare-Metal-Lösung mehr angeboten wird. Damit war Scaleway gestartet und Probleme durch lastverursachende Nachbarn zu vermeiden hat einen gewissen Wert.