K8s-Cluster bei cloudscale in YAML deklarieren

Dank Cluster API (CAPI) können ganze Cluster komplett mittels YAML-Files beschrieben und automatisiert verwaltet werden. CAPI führt hierzu eine Reihe zusätzlicher Architektur-Komponenten ein, die es erlauben, die heterogenen Cloud-APIs hinter einer gemeinsamen Abstraktion zu verstecken.

Der "Cluster API Provider for cloudscale.ch" (CAPCS) ist dabei das Bindeglied, damit aus einer blossen YAML-Konfiguration ein voll funktionsfähiger Kubernetes-Cluster auf unserer Infrastruktur entstehen kann. CAPCS erlaubt dir etwa die Spezifikation, welchen Compute-Flavor deine Control-Plane- und Worker-Nodes erhalten sollen, und fungiert als Schnittstelle zwischen den Kubernetes-internen Funktionen und der cloudscale API.

Weniger Fehler, mehr Effizienz

Indem du deine Cluster mittels CAPI verwaltest, stellst du sicher, dass jeder Cluster genau seiner Spezifikation entspricht, und schliesst mögliche Fehler aufgrund manueller Aktionen weitestgehend aus. Die Infrastruktur für deine Workloads ist vorherseh- und reproduzierbar; Differenzen etwa zwischen Umgebungen (z.B. Entwicklung, Test, Staging, Produktion) oder Teams werden minimiert. Auch ein temporärer Test-Cluster kann schnell und exakt gemäss deinem Standard aufgebaut werden – und ist im Anschluss auch genauso schnell wieder gelöscht.

CAPI unterstützt dich jedoch nicht nur bei kurzlebigen Clustern – im Gegenteil: steht ein Upgrade der Kubernetes-Version an, werden deine Nodes in einem "rolling Upgrade" nacheinander aktualisiert. Dies reduziert das Risiko bei einem Upgrade und minimiert die damit verbundene Downtime. Und auch zwischen den geplanten Anpassungen wird durch die laufende Überprüfung sichergestellt, dass deine Infrastruktur jederzeit ihrer Definition entspricht.

Direkt ausprobieren

CAPCS ist auf GitHub verfügbar und ergänzt die schon zuvor bestehenden Integrationen (CSI und CCM) von Kubernetes mit cloudscale. Nebst dem Code von CAPCS findest du auf GitHub auch einen übersichtlichen "Getting Started Guide".

Noch konkreter wird es in unserem Engineering Blog: Ausgehend von einem "Seed-Cluster" zeigt dir Michael Schritt für Schritt, wie du einen Management-Cluster initialisierst, deinen ersten Workload-Cluster erstellst und ein Kubernetes-Upgrade durchführst – komplett mit Config-Ausschnitten, konkreten Commands und vielen weiterführenden Links.

Viele unserer Kunden nutzen bereits Kubernetes, um ihre Workloads zu managen. Mit dem Cluster API Provider for cloudscale.ch (CAPCS) können nun – direkt aus Kubernetes heraus – auch ganze Kubernetes-Cluster gemanagt werden. Ob für kurze Tests oder konsistente "Day 2 Operations": Spezifiziere ganze Cluster in YAML-Files und lass Kubernetes sicherstellen, dass jederzeit die richtige Infrastruktur provisioniert wird.

Etwas zu deklarieren? Und ob!
Dein cloudscale-Team

Neue Speicherdauer von 90 Tagen

Nach europäischem Verständnis dürfen Personendaten nicht grundlos gesammelt werden; fehlt ein Zweck oder fällt dieser später weg, sind die Daten zu löschen. Bei cloudscale waren wir schon immer datensparsam unterwegs und verzichten bewusst auf gewisse Datenhalden, die anderswo (leider) Usus sind. Aufgrund der über die Zeit gesammelten Erfahrungen kamen wir nun zum Schluss, dass ein Teil der bei uns vorhandenen Logs weniger lang benötigt wird als bisher angenommen, weshalb wir deren Aufbewahrungsfrist verkürzen.

Für dich bedeutet das, dass in den Audit-Logs für deine Projekte, deinen Account und ggf. deine Organizations nur noch die Einträge der letzten 90 Tage verfügbar sein werden. Diese Logs sollten in den allermeisten Fällen ausreichen, wenn du rund um deine Cloud-Setups vergangene Aktionen nachvollziehen musst. Zusätzlich hast du jedoch auch die Möglichkeit, deine Audit-Logs zu exportieren und sie nach deinen eigenen Vorgaben zu archivieren.

Exports für eine längere Aufbewahrung

Audit-Logs von all deinen Projekten sowie dein "User Log" kannst du jederzeit im Cloud Control Panel herunterladen – der Button hierzu findet sich direkt oben rechts beim entsprechenden Log. Audit-Logs deiner Projekte stehen dir zudem auch weiterhin via unsere API zur Verfügung; so kannst du sie zum Beispiel in deinem Monitoring automatisiert abrufen und auswerten.

Für Organizations ist neu auch ein periodischer Export in unseren Object Storage verfügbar; dieser Export umfasst sowohl das Log für deine Organization als auch die Logs all ihrer Projekte. Immer kurz nach Mitternacht werden dabei die am Vortag neu hinzugekommenen Audit-Log-Einträge in einen Bucket deiner Wahl gespeichert. Wenn du nebst den Logs des laufenden Tags und der Zukunft auch die bisherigen, noch vorhandenen Einträge in den Bucket exportieren möchtest, wähle im Control Panel einfach zusätzlich die entsprechende Checkbox an.

Wenn du bisher nicht mit Organizations arbeitest, kannst du den periodischen Export natürlich trotzdem nutzen: Lege im Control Panel einfach eine neue Organization an und gib unserem Support Bescheid, dass wir deine bestehenden Projekte in diese Organization verschieben sollen – das Verschieben eines Projekts führt übrigens zu keinerlei Unterbruch.

Optimaler Schutz deiner Audit-Logs

Als Ziel für den periodischen Export kannst du einen beliebigen Bucket in unserem S3-kompatiblen Object Storage am Standort deiner Wahl nutzen. Die exportierten Logs kannst du anschliessend dort belassen oder sie mit einem Tool deiner Wahl an einen anderen Ort umziehen. Der Bucket muss dabei übrigens nicht zu einem Projekt der gleichen Organization gehören: Für zusätzlichen Schutz deiner Logs bietet sich etwa ein Bucket in einer separaten "CISO-Organization" an.

Der Exportvorgang an sich benötigt lediglich das Recht, neue Objects in dem Bucket zu erstellen (PutObject) und die Bucket-Location abzufragen (GetBucketLocation). Für die Konfiguration des Exports musst du also nicht den Objects User angeben, dem der Bucket gehört. Stattdessen kannst du auch einen separaten Objects User anlegen, dem du dann mittels Bucket Policy nur selektiv Berechtigungen erteilst, und im Control Panel den Access und Secret Key dieses zusätzlichen Users hinterlegen.

So könnte eine Policy für den exportierenden Objects User aussehen:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam:::user/EXAMPLE1111111122222222333333334444444455555555666666667777777788888888"},
    "Action": ["s3:PutObject", "s3:GetBucketLocation"],
    "Resource": [
      "arn:aws:s3:::my-bucket",
      "arn:aws:s3:::my-bucket/*"
    ]
  }]
}

Logs erfüllen die verschiedensten Zwecke: Sie helfen beim Lösen technischer Probleme genauso wie beim Einhalten von Compliance-Anforderungen. Meist muss man nur wenig in die Vergangenheit zurückschauen, und eine kurze Speicherfrist reicht aus. Wenn das in deinem Anwendungsfall anders ist, nutze die verschiedenen Exportmöglichkeiten in unserem Control Panel und der API. Achtung: Seitens cloudscale halten wir ab dem 15.07.2026 nur noch die Audit-Logs der letzten 90 Tage vor. Benötigst du ältere Logs auch später noch, dann exportiere sie vor dem 15.07.2026 auf einem der beschriebenen Wege.

Korrekt dokumentiert,
Dein cloudscale-Team

Ein Feature, viele Anwendungsfälle

In vielen Fällen ist es vorteilhaft, wenn du einen Teil deiner virtuellen Server gänzlich vom Internet getrennt hältst und damit zahlreiche Angriffe von vornherein ins Leere laufen lässt. So brauchen etwa deine Webserver keinen direkten Internet-Anschluss, wenn die HTTPS-Requests sowieso über unseren Load-Balancer-as-a-Service hereinkommen. Das Gleiche gilt für ein Datenbank-Backend, das ausschliesslich von deiner Web-Applikation aus erreichbar sein soll, oder für einen zentralen Log-Server in deiner Infrastruktur.

Um dich für Wartungsarbeiten an solchen Servern ins private Netz einzuwählen, hast du dir möglicherweise einen VPN-Zugang eingerichtet. Kommt nun ein neues Projekt hinzu, musst du dein VPN-Setup nicht duplizieren: "verlängere" einfach dein bestehendes, privates "Management-Netz" in das neue Projekt hinein; dito für das DB-Netz, das Logging-Netz und so weiter. Auf diese Weise kannst du zentrale Services einmal aufsetzen und mehrfach nutzen, ohne auf die Vorteile getrennter Projekte zu verzichten – so etwa verschiedene Teams und Berechtigungen, separat ausgewiesene Kosten oder die Begrenzung der Reichweite von API-Tokens.

Netze schnell und einfach teilen

Deine privaten Netze verwaltest du im Control Panel einfach und übersichtlich unter "Networking > Networks". Auf der Detail-Ansicht eines Netzes findest du das Tab "Sharing" – hier siehst du, mit welchen anderen Projekten das Netz bereits geteilt wird (bzw. welches andere Projekt es mit deinem teilt), und kannst für deine eigenen Netze direkt Änderungen vornehmen.

Um ein Netz mit einem anderen Projekt zu teilen, wähle "Share with Project". Im Folgenden siehst du sämtliche Projekte, auf die du Zugriff hast, und kannst das gesuchte auswählen. Bitte beachte: Um selbständig ein neues Sharing einzurichten, brauchst du Schreibrecht auf beiden beteiligten Projekten. Erscheint das gewünschte Projekt in der Auswahl gar nicht oder als "read-only", benutze zum Teilen den Link "create a ticket" im Hilfetext nebenan – unser Support wird dann die nötige Bestätigung einholen und das Sharing für dich aktivieren.

Beachte auch, dass du ein bestehendes Sharing nur entfernen kannst, wenn im anderen Projekt keine Server mehr an dein Netz angeschlossen sind. Zudem können die Eigenschaften des Netzes wie Name und MTU nur im ursprünglichen Projekt verändert werden und nicht in Projekten, mit denen das Netz geteilt wird. Wäge für ein neues, zusätzliches Netz daher ab, welches der Projekte idealerweise der "Owner" sein soll bzw. in welche Richtung du das Netz teilen möchtest.

Besonders dann, wenn nicht alle Server von den gleichen Mitarbeitern verantwortet werden, kann es sinnvoll sein, separate Projekte und Berechtigungen einzurichten. Private Netze teilst du dann zwischen den Projekten gezielt dort, wo es nötig ist – schnell und einfach mit wenigen Klicks im Control Panel.

Sharing is...
Dein cloudscale-Team

Snapshots für Persistent Volumes in Kubernetes

Sogenannte Persistent Volumes sind essentiell in vielen Kubernetes-Setups: Darauf speicherst du die Daten, die dauerhaft behalten werden und nicht an die Lebensdauer eines Pods gebunden sein sollen. Über unseren CSI-Driver ist es möglich, ausgehend von "Persistent Volume Claims" automatisch Volumes in unserer Cloud-Infrastruktur zu provisionieren und immer an dem virtuellen Server anzuschliessen, wo sie gerade vom entsprechenden Pod benötigt werden.

Mit dem kürzlich veröffentlichten CSI-Driver 4.0.0 (mit einer zusätzlichen Sidecar-Komponente) kannst du nun nicht nur manuell via unser webbasiertes Cloud Control Panel oder via API Snapshots deiner Volumes verwalten, sondern auch aus deinem Kubernetes-Setup heraus. Der CSI-Driver knüpft hierzu an die standardmässige Kubernetes VolumeSnapshot API an und interagiert mit der cloudscale API, um deine Snapshots exakt so zu verwalten, wie dein Setup es benötigt.

Velero: einer von unzähligen Anwendungsfällen

Die Snapshot-Unterstützung in unserem CSI-Driver macht es dir nun noch einfacher, auch bei Persistent Volumes in einem Kubernetes-Cluster Point-in-Time-Kopien zu erstellen und diese – sollte eine nachfolgende Operation fehlschlagen – wiederherzustellen. Auch können basierend auf Snapshots neue Volumes erstellt werden; so kannst du etwa einen produktiven Datenstand für ein Testsystem klonen oder das neue Volume mounten, um selektiv auf einzelne frühere Datenpunkte zuzugreifen.

In unserem Engineering Blog zeigt dir Julian Schritt für Schritt und mit allen nötigen Configs, wie du mit Velero und unserem Snapshot-Feature den Zustand eines Persistent Volumes sicherst und später wiederherstellst. Selbstverständlich kannst du das Beispiel beliebig ausbauen und an deinen Use Case anpassen.

Nicht bloss Details – bitte beachten

Bitte behalte – gerade bei Velero – im Hinterkopf, dass der Begriff "Backup" unterschiedlich verwendet werden kann. Wir bei cloudscale betrachten Volume Snapshots als perfekt, um als Sicherheitsnetz etwa bei Datenbankmigrationen oder System-Upgrades eine schnelle und einfache Rückkehr zum vorherigen Zustand zu ermöglichen. Da Snapshots jedoch auf "Copy-on-Write" basieren und im gleichen Storage-Cluster wie ihr ursprüngliches Volume gespeichert sind, stellen sie aus unserer Sicht kein "Backup" dar. Für optimale Sicherheit empfehlen wir dir, immer auch eine Kopie deiner Daten an einem anderen geographischen Standort – und idealerweise auf Infrastruktur eines Drittanbieters – vorzuhalten.

Benötigt werden Kubernetes ab Version 1.28, der Kubernetes Snapshot Controller und die zugehörigen CRDs (was in vielen Setups bereits vorhanden ist). Im Übrigen sind die Rahmenbedingungen die gleichen, die du von Snapshots bei cloudscale schon bisher kennst: Pro Volume können bis zu 10 Snapshots gleichzeitig bestehen, und verrechnet werden sie – sekundengenau für die Zeit, während der sie existieren – nach der Grösse des Volumes im Zeitpunkt, als der Snapshot erstellt wurde (zum halben Gigabyte-Preis eines normalen NVMe-SSD- bzw. Bulk-Volumes).

Bei cloudscale unterstützen wir dich beim Betrieb von Kubernetes-Setups mit den passenden Tools und Schnittstellen. Auch unser CSI-Driver mit Snapshot-Unterstützung stand bereits eine Weile als "Beta-Version" zur Verfügung, und die Rückmeldungen waren durchwegs positiv. Mit der Freigabe von Version 4.0.0 empfehlen wir nun allen Kunden ein Upgrade; so kannst auch du direkt aus deinem Kubernetes-Setup heraus – z.B. mit Velero – die Vorteile unserer Volume-Snapshots voll ausschöpfen.

Mach Snapshots mit dem Selbstauslöser!
Dein cloudscale-Team

Von Matthias Gysi, Presales Engineer, Squirro

Squirro: Die KI-Plattform für regulierte Industrien

Ein Prompt, eine Antwort – die simple Nutzung von KI im Browser weckt oft falsche Erwartungen. Spätestens wenn Unternehmen versuchen, ihre Pilotprojekte (PoCs) in den produktiven Betrieb zu skalieren, stossen sie auf eine harte Grenze. Der Grund dafür ist simpel: Herkömmliche KI-Architekturen sind den strengen Anforderungen an Genauigkeit, Datensicherheit und Compliance im regulierten Geschäftsalltag schlichtweg nicht gewachsen.

Genau hier setzt Squirro an und liefert ein sicheres Fundament für generative KI im Enterprise-Umfeld. Unternehmen können anspruchsvolle, aber zeitintensive Wissensarbeit – sei es das Verfassen markenkonformer Texte, die Analyse von Rechtsdokumenten oder der Compliance-Abgleich – endlich sicher delegieren. Das gefürchtete Risiko von KI-Halluzinationen wird dabei durch ein striktes, faktenbasiertes Grounding konsequent minimiert. Indem Squirro isolierte Datensilos aufbricht und zu einer zentralen Wissensbasis verbindet, decken Teams neue Zusammenhänge auf und können ganze Workflows durch autonome Agenten steuern lassen. So wird die KI vom Experiment zum echten strategischen Werkzeug.

Mit Advanced RAG gegen die Schatten-IT

Die Effizienzvorteile von GenAI liegen auf der Hand. Kein Wunder also, dass Mitarbeitende diese Werkzeuge längst für ihre tägliche Arbeit nutzen möchten. Doch wenn dies unkontrolliert geschieht, entsteht rasch eine gefährliche Schatten-IT. Dies vergrössert die digitale Angriffsfläche massiv. Datenlecks, Compliance-Verstösse oder der ungewollte Abfluss von geistigem Eigentum in die Trainingsdaten externer Modellanbieter sind reale Risiken, die langfristige Reputationsschäden nach sich ziehen können.

Genau für diese Herausforderung wurde Squirro konzipiert: Die Plattform holt GenAI sicher und mit strikten Zugriffskontrollen aus der Schatten-IT direkt in Ihre Kernprozesse. Anstatt sich auf das allgemeine Wissen von Standard-Sprachmodellen zu verlassen, nutzt Squirro Retrieval Augmented Generation (RAG), um jeden Prompt in Echtzeit mit Ihren internen Unternehmensdaten zu bereichern – was die Präzision und Relevanz der Antworten massiv steigert.

Während Standard-RAG-Ansätze lediglich Daten zur Ergebnisfindung heranziehen, geht der erweiterte Stack von Squirro entscheidende Schritte weiter, um sowohl die Genauigkeit zu verbessern als auch den Datenschutz sicherzustellen:

• Knowledge Graphs: Ermöglichen eine tiefere, deterministische Fundierung, damit die KI echte logische Beziehungen versteht, statt nur statistische Wortwahrscheinlichkeiten zu berechnen.
• Daten-Virtualisierung: Erlaubt die Integration in Echtzeit, ohne dass sich schnell ändernde Datensätze zeitaufwendig neu indiziert werden müssen.
• AI Guardrails: Stellen sicher, dass sämtliche KI-Outputs strikt den internen Richtlinien und regulatorischen Vorgaben entsprechen.
• Privacy Layer: Personenbezogene Daten (PII) werden automatisch maskiert oder entfernt, noch bevor sie das LLM erreichen. So lassen sich modernste Modelle US-basierter Hoster nutzen, ohne gegen die DSGVO zu verstossen.
• Agentic Framework: Befähigt Nutzer dazu, komplexe End-to-End-Workflows auf Basis eigener Daten autonom auszuführen.

So entsteht eine sichere Alternative zur Schatten-IT, die es Teams erlaubt, Generative AI in einem geschützten Unternehmensumfeld einzusetzen.

Datensouveränität als Standortvorteil

In Gesprächen mit Führungskräften über KI dominiert oft ein Thema: die ungelöste Datenschutzfrage. Dabei steht nicht die IT-Sicherheit im Fokus, sondern die rechtliche Grauzone des US Cloud Acts. Dieses Gesetz gewährt US-Behörden weitreichende Zugriffsrechte auf Daten amerikanischer Provider, egal wo die Server physisch stehen. Für Banken, Behörden oder Spitäler bedeutet dies den potenziellen Verlust ihrer digitalen Souveränität.

Squirro löst diesen Konflikt durch kompromisslose Datenkontrolle. Die Plattform überlässt Unternehmen die volle Entscheidungsgewalt über den Speicherort, wahlweise in einer VPC oder vollständig On-Premises. Durch die Kombination mit cloudscale können Schweizer Unternehmen ihre KI-Strategie skalieren, ohne auf Anbieter angewiesen zu sein, die dem US Cloud Act unterliegen.

Präzise Zugriffskontrolle ohne Kompromisse

Ein oft unterschätzter Aspekt bei Enterprise AI ist das Berechtigungsmanagement. Wie verhindert man, dass eine KI-Anwendung, die auf den gesamten Datenschatz zugreift, einem Junior-Analysten vertrauliche Management-Memos oder Gehaltslisten offenbart?

Klassische Zugriffskontrolllisten (ACLs) stossen bei wachsender Unternehmensgrösse oft an ihre Grenzen. Squirro löst dieses Problem durch eine Metadaten-basierte Zugriffskontrolle direkt auf Ebene der kleinsten Informationseinheit (Chunking). Die Berechtigungen (ACLs) werden bereits beim Einlesen der Daten fest verankert.

Besitzt ein Nutzer keine Zugriffsrechte, bleiben die entsprechenden Dokumente für das LLM unsichtbar, was den unbefugten Zugriff durch Dritte verhindert. Dass dies auch im grossen Massstab funktioniert, haben wir bei einer bedeutenden Zentralbank bewiesen: Dort verwalten wir über 10 TB Indexdaten für mehr als 10.000 Nutzergruppen – bei maximaler Performance.

Zukunftssichere Enterprise AI

Die Kombination aus Squirro und cloudscale liefert eine schlüsselfertige, souveräne Plattform, die völlig unabhängig von den grossen US-Technologiekonzernen operieren kann. Dabei geht es um weit mehr als nur die reine IT-Infrastruktur. Das eigentliche Ziel ist es, genau jene regulatorischen und sicherheitstechnischen Bedenken auszuräumen, die vielversprechende KI-Initiativen oft schon in der Planungsphase blockieren.

Der angebliche Widerspruch zwischen technologischer Innovation und strengem Datenschutz ist letztlich ein falscher Gegensatz. Die gemeinsame Lösung beweist, dass sich eine souveräne KI-Strategie effizient realisieren lässt – aufgebaut auf einem digitalen Fundament, das zu 100 Prozent im eigenen Einflussbereich bleibt.

Die nahtlose Integration beider Systeme ist bereits erfolgreich in der Praxis validiert. Wenn Sie die Lösung live erleben oder eine Testumgebung evaluieren möchten, steht Ihnen unser Sales Team gerne zur Verfügung.

Die nächste Generation

Die NVIDIA L40S in unseren bisherigen GPU-Servern brachte 48 GB VRAM mit, und bis zu vier der GPUs liessen sich in einem virtuellen Server parallel nutzen. Die neue NVIDIA RTX PRO 6000 Max-Q trumpft gleich mit dem Doppelten auf: 96 GB VRAM pro GPU, und auch hier kannst du in einem einzelnen Server die Power von bis zu vier GPUs anzapfen. Die physischen GPUs werden dir dabei ungeteilt in den virtuellen Server durchgereicht, so dass dir die volle Leistung dediziert zur Verfügung steht.

Apropos Leistung: Die RTX PRO 6000 bietet nicht nur mehr VRAM, sondern auch deutlich mehr Rechenpower als die L40S, und bei der "Max-Q"-Variante hat uns zudem das Verhältnis von Performance zu Energieverbrauch überzeugt. Passend zum grösseren VRAM statten wir unsere neuen GPU2 Flavors auch mit mehr Memory aus, welches du in verschiedenen Verhältnissen mit 16 bis 96 dedizierten CPU-Cores kombinieren kannst. Nichts geändert hat sich bei der Scratch Disk: Bis zu 1'600 GB blitzschneller NVMe-SSD-Speicher stehen dir lokal zur Verfügung, um die Latenz zu minimieren.

Kontrollierter Wechsel

Um von einem GPU1-Server mit L40S zu einem GPU2-Server mit RTX PRO 6000 Max-Q zu wechseln, reicht es im Prinzip aus, den Server via Cloud Control Panel oder API auf einen der neuen Flavors zu skalieren. Das Skalieren von GPU-Servern kann einen Moment dauern, da bei einem Umzug auf andere physische Hardware auch der Inhalt deiner Scratch Disk übertragen werden muss.

Wir empfehlen dir jedoch, vorsichtshalber einen zweiten, neuen Server zu erstellen und zuerst sicherzugehen, dass alles wie gewünscht funktioniert (inkl. dem Open-Source GPU Kernel Module, das für die Blackwell-Architektur benötigt wird, bei Debian/Ubuntu etwa das Paket nvidia-open). Danach kannst du die Workload auf den neuen Server migrieren – mit einer Floating IP und/oder einem Load-Balancer bleibt dabei für deine Nutzer auch die IP-Adresse gleich.

Die neuen, teils deutlich günstigeren GPU2 Flavors mit NVIDIA RTX PRO 6000 Max-Q GPUs sind seit einigen Tagen verfügbar, und gemäss erstem Kundenfeedback zu "echten" Workloads ist eine markant bessere Performance messbar. Wir sind überzeugt, dass auch deine Applikation von unseren GPU-Servern profitiert – probiere es am besten gleich selbst aus!

Legt einen drauf,
Dein cloudscale-Team

Zusammenzug von verstreuten Kostenangaben

Ein virtueller Server bei cloudscale kann bis zu 128 Volumes haben – so können etwa die PVs in einem Kubernetes-Setup via CSI immer genau dort bereitgestellt werden, wo die Pods sie benötigen. Die entsprechenden Storage-Kosten wurden im Cloud Control Panel bisher jeweils bei demjenigen Server mit angezeigt, an den die Volumes gerade attached waren. Gerade bei grossen Setups erschien jedoch eine solche "Kopplung" nicht immer hilfreich. Weitere Kosten – etwa für Snapshots, Floating IPs oder Load-Balancer – wurden dagegen ausschliesslich "dezentral" bei den jeweiligen Cloud-Ressourcen ausgewiesen.

Für Projekte in deinem persönlichen Account oder in einer Organization, in welcher du Superuser bist, gab es schon bisher eine übersichtlichere Zusammenstellung: Im "Billing"-Bereich des Control Panels werden alle Kosten eines Projekts auf einer einzigen Seite zusammengefasst. Die Gesamtkosten werden dabei nach Compute-, Storage- und Networking-Kosten gegliedert und bis hinunter zu den individuellen Cloud-Ressourcen einzeln aufgeführt. Diese Übersicht ist neu auch für alle anderen Projekt-Beteiligten verfügbar, also z.B. für External Collaborators oder Members einer Partner Organization; du findest sie direkt im "Services"-Bereich unter dem Navigationspunkt "Project Costs".

Übersichtliche Momentaufnahme

Die Übersicht unter "Project Costs" ist nicht nur nützlich, wenn du entsprechende Fragen von der Buchhaltung oder einem Kunden beantworten musst. Schau zum Beispiel nach einem automatisierten Deployment mittels Ansible oder Terraform in diese Zusammenstellung; so siehst du auf einen Blick, ob die erstellten Cloud-Ressourcen dem entsprechen, was du beabsichtigt hattest. Als "Sanity Check" siehst du an den Kosten auch schnell, wenn etwa deutlich zu kleine oder zu grosse Compute-Flavors in eine "Infrastructure-as-Code" Config gerutscht sind.

Wie bei cloudscale üblich werden die Kosten "per Day" ausgewiesen, du siehst also, was die momentan vorhandenen Cloud-Ressourcen kosten (würden), wenn sie volle 24 Stunden in dieser Form bestehen. Selbstverständlich rechnen wir jedoch weiterhin sekundengenau ab: Ressourcen, die du eben erst erstellt hast oder noch am gleichen Tag löschst, werden nur anteilig verrechnet. Einer separaten Logik folgt hier weiterhin der Object Storage: Weil sich diese Kosten aus der laufenden Nutzung ableiten, ist eine "Momentaufnahme" nicht möglich; stattdessen werden dir die durchschnittlichen Kosten der letzten 7 Tage angezeigt.

Mehr nützliche Informationen für dich

Mit dem Zusammenziehen aller Kostenangaben unter "Project Costs" haben wir uns auch neu damit auseinandergesetzt, mit welchen anderen Informationen wir unsere Nutzer bei ihrer Arbeit im Control Panel am besten unterstützen. So findest du nun etwa oben über der Ansicht deiner Server und Volumes je ein separates Total für NVMe-SSD- und Bulk-Storage, oder beim Object Storage die Gesamtzahl deiner Objects.

Ebenfalls vor Kurzem eingeführt haben wir zudem die "Balance History" im "Billing"-Bereich. Für deinen eigenen Account sowie für Organizations, in denen du Superuser bist, kannst du hier die Entwicklung des Guthabens tagesgenau nachvollziehen und siehst den belasteten Betrag für jedes Projekt. Für mehr Informationen führt dich ein simpler Klick zum Billing Report des betreffenden Projekts und Tags, wo du alle verrechneten Cloud-Ressourcen mit ihren Einzelbeträgen aufgeführt findest.

Bei cloudscale bezahlst du nur, was du brauchst – und was das im Einzelnen ist, kannst du jederzeit und übersichtlich nachvollziehen. So hast du nicht nur selbst den optimalen Überblick, sondern auch für die Kommunikation mit internen und externen Stakeholdern immer die richtigen Antworten.

Klare Sache.
Dein cloudscale-Team

Das richtige Protokoll für jeden Use Case

UDP spart sich im Vergleich zu TCP einen gewissen Overhead; in einer Datenübertragung mittels UDP können zum Beispiel Datenpakete verloren gehen, ohne dass diese noch einmal übermittelt würden. In einem Videostream etwa kann dies durchaus erwünscht sein; lieber fehlen mal ein paar Pixel, als dass alles stoppen und auf die fehlenden Datenpakete warten müsste. In einem VPN-Tunnel wiederum kann die "innere", eingekapselte Verbindung auf Übertragungsfehler reagieren und wenn nötig ein nochmaliges Senden von Daten anfordern.

Dabei wird klar, dass UDP-basierte Services ganz unterschiedliche Anwendungsfälle abdecken, die bezüglich Verfügbarkeit und Serverkapazität keineswegs weniger anspruchsvoll sein müssen. Wenn du solche Services bei cloudscale betreibst, nutze darum auch für sie unseren "LBaaS". Mit zwei oder mehr Backend-Servern – idealerweise in "Anti-Affinity" –, die parallel Requests verarbeiten, steigerst du nicht nur die Gesamtkapazität, sondern auch die Verfügbarkeit deines Service als Ganzes.

Besonderheiten des LBaaS mit UDP

Im Fall von TCP verteilt unser Load-Balancer einzelne Connections auf die verfügbaren Backend-Server ("Pool Members"). UDP kennt keine solchen Connections; hier unterscheidet der Load-Balancer stattdessen einzelne Datenströme, die sich durch ihre jeweilige Kombination von Quell- und Ziel-IPs sowie -Ports auszeichnen. Pakete mit den passenden Werten werden über mehrere Minuten hinweg dem gleichen Datenstrom (und damit dem gleichen Backend) zugeordnet, was bereits standardmässig zu einer gewissen "Session Stickiness" führt.

In unserer umfangreichen API-Dokumentation findest du unter anderem Tabellen, die dir die unterstützten Protokoll-Kombinationen aufzeigen. So ist es zum Beispiel möglich, dass die einzelnen Pool Members gegenüber dem Health Monitor mittels (TCP) HTTP-Status-Code signalisieren, ob sie bereit zum Verarbeiten von Requests sind, selbst wenn die eigentlichen Requests dann via UDP übermittelt werden.

Bitte beachte, dass der Load-Balancer UDP derzeit nur für IPv4-Traffic unterstützt. Wenn dein Load-Balancer aus dem Internet erreichbar ist, erhält er standardmässig sowohl eine IPv4- als auch eine IPv6-Adresse zugeteilt; erfasse in diesem Fall einfach keine AAAA DNS-Records für diejenigen Hostnamen, unter denen du (auch) UDP-Services betreibst.

UDP ist allgegenwärtig, dies gilt nicht nur mit Blick auf DNS. Nutze unseren Load-Balancer jetzt auch für deine UDP-basierten Services, um dein Setup noch robuster zu machen und etwa Wartungsarbeiten elegant zu überbrücken. Und falls du bisher noch keine Erfahrung mit unserem LBaaS hast, findest du für den Einstieg einen guten Überblick im Beitrag zu den Komponenten eines Load-Balancers.

Zuverlässig,
Dein cloudscale-Team

Hast du dich schon einmal gefragt, welches Team-Mitglied diesen Server namens "test" erstellt hat? Oder wann du ein bestimmtes System zum letzten Mal hart rebooten musstest? Im Audit-Log findest du die Antwort: Die Änderungen an deinen Cloud-Ressourcen – egal, ob sie im Cloud Control Panel oder via API vorgenommen wurden – sind fein säuberlich aufgeführt und nachvollziehbar.

Wer diese Logs nicht nur im Control Panel einsehen, sondern etwa auf einem eigenen Logserver aufbewahren oder mit einem bestimmten Tool durchsuchen möchte, kann das Audit-Log neu auch über unsere API abrufen. Optional kannst du dabei einen Start- und/oder Endzeitpunkt mit angeben, um umfangreiche Logs auf den relevanten Zeitraum einzugrenzen. Mit einer speziellen poll_more URL kannst du dir zudem periodisch genau jene Logs ausgeben lassen, die seit dem letzten Abruf neu hinzugekommen sind. So kannst du die Logs auch in einem Monitoring-System auswerten und etwa bei bestimmten Aktionen ein zusätzliches Augenpaar für ein manuelles Review aufbieten.

Blick unter die Haube

Im Audit-Log, das du via API abrufst, findest du nebst dem exakten Timestamp für jede Änderung die zwei Felder action und message. Die Action benennt dabei, um was für eine Änderung es sich handelt (z.B. "server_volume_attach"), während die Message den ganzen Vorgang beschreibt – also auch angibt, welches Volume an welchen Server angehängt wurde. Daneben siehst du, wer die Änderung veranlasst hat (in der Regel die Mail-Adresse eines Accounts im Control Panel bzw. das benutzte API-Token), und von welcher IP-Adresse aus dies geschah. Alle Details dazu findest du wie immer in unserer API-Dokumentation.

Nicht jede Änderung via Control Panel oder API dauert gleich lang, und Aktionen können parallel laufen. Sobald die Aktion erfolgreich durchgeführt wurde, wird der Logeintrag vorbereitet – dies bestimmt den Timestamp des Logs. Kurz darauf (im Bereich von Millisekunden) wird das Resultat der Aktion und der Logeintrag sichtbar gemacht. In dieser kurzen Zeit ist es möglich, dass Logeinträge sich "überholen", also ein Log mit dem früheren Timestamp erst später sichtbar wird. Beim Abruf von Folgeseiten und beim "Pollen" stellt der cursor sicher, dass dir kein Logeintrag entgeht. Einen umfassenden Einblick in diesen Mechanismus gibt dir Michi in unserem Engineering Blog.

Vorbereitetes Code-Beispiel: sofort loslegen

Zum schnellen Einstieg haben wir für dich ein fixfertiges, kommentiertes Python-Script vorbereitet. Damit kannst du das Abrufen des Audit-Logs via API ausprobieren und dich mit dem verwendeten Ansatz vertraut machen. Auch wenn du in deiner Praxis andere Tools und Sprachen nutzt, hast du damit einen guten Überblick und eine Basis für eigene Implementierungen.

Bereite als erstes ein Python Virtual Environment mit der benötigten Dependency vor:

mkdir project-log-api-client
cd project-log-api-client/
python3 -m venv venv
source venv/bin/activate
pip install aiohttp

Erstelle dann das eigentliche Script api-log-client.py mit folgendem Inhalt:

import asyncio
import json
from collections.abc import AsyncIterator
from datetime import UTC
from datetime import datetime
from datetime import timedelta
from typing import Any
from urllib.parse import quote

from aiohttp import ClientSession

API_TOKEN = "INSERT_PROJECT_API_TOKEN"
POLL_INTERVAL_SECONDS = 120


async def stream_logs(session: ClientSession, start: datetime) -> AsyncIterator[Any]:
    poll_url = f"https://api.cloudscale.ch/v1/project-logs?start={quote(start.isoformat())}"

    # The outer loop fetches all logs available at the time,
    # then waits for a defined interval.
    while True:
        current_page = poll_url

        # The inner loop fetches individual pages of available logs
        # until the `next` field in the response is `null`.
        while current_page is not None:
            async with session.get(current_page) as response:
                if not response.ok:
                    # The API did not return with status code 200.
                    raise Exception(f"Error {response.status} from API: {await response.text()}")

                obj = await response.json()

            # Return all fetched logs to the caller.
            for log in obj["results"]:
                yield log

            current_page = obj["next"]
            poll_url = obj["poll_more"]

        # Wait for a defined interval before polling for new logs.
        await asyncio.sleep(POLL_INTERVAL_SECONDS)


async def main() -> None:
    # Header to authenticate the API access.
    headers = {"Authorization": f"Bearer {API_TOKEN}"}

    # Retrieve logs from the past hour before streaming new logs.
    start = datetime.now(UTC).astimezone() - timedelta(hours=1)

    print(f"Streaming logs, starting from {start:%F %H:%M:%S}. Use ctrl-C to stop.")

    async with ClientSession(headers=headers) as session:
        # Iterate over logs returned by the API and print them to the console.
        async for log in stream_logs(session, start):
            print(json.dumps(log, indent=4))


if __name__ == "__main__":
    asyncio.run(main())

Starte nun das Script. Es gibt dir das Audit-Log der letzten 60 Minuten auf der Kommandozeile aus und ergänzt dann periodisch Logeinträge, die in der Zwischenzeit neu hinzugekommen sind:

$ python3 api-log-client.py 
Streaming logs, starting from 2025-12-11 12:21:48. Use ctrl-C to stop.
{
    "ip_address": "172.30.244.1",
    "action": "server_create",
    "message": "Server 'hello' has been created",
    "timestamp": "2025-12-11T12:23:17.460366Z",
    "actor": {
        "user": {
            "email": "johanna@example.com"
        }
    }
}
[...]

Mit den Audit-Logs deiner Projekte bei cloudscale weisst du jederzeit, wann, was und von wem gemacht wurde – so kannst du schnell die richtigen Zusammenhänge herstellen oder bei Nachfragen auf die geeigneten Personen zugehen. Nutze diese Logs nun auch via API für maximale Flexibilität bei Archivierung und Auswertungen.

Verbindlich,
Dein cloudscale-Team

Rescue Mode als zusätzliche Boot-Möglichkeit

Über die VNC Console kannst du deine Server auch von einem anderen als dem root-Volume starten und so fast beliebige Betriebssysteme booten und ggf. installieren. Zuerst musst du dafür jedoch ein zusätzliches Volume an deinen Server anhängen, das den nötigen Inhalt zum Booten (etwa ein USB- oder ISO-Image) enthält. Während dir dieses Vorgehen die volle Flexibilität bietet, kann es in einem Notfall wertvolle Zeit kosten.

Mit dem "Rescue Mode" hast du nun ein Multifunktions-Tool für solche Fälle jederzeit in Griffnähe: Mit nur zwei Klicks startet dein Server ein "Grml" Image. Diese Debian-basierte Distribution darf man vermutlich als den Standard unter den Live-Images für knifflige Situationen bezeichnen.

Ein Live-System ist insbesondere dann hilfreich, wenn der normale Zugriff auf deinen Server aus irgendeinem Grund nicht klappt. Sei es, dass der Server gar nicht erst bootet (der Grund dafür ist oft noch im "Console Log" ersichtlich), nicht richtig ins Netzwerk kommt, eine zu restriktive Firewall-Einstellung hat oder du schlicht die Zugangsdaten verloren hast: Grml bietet dir – wie anno dazumal die Boot-Diskette – das Werkzeug, um an eine fehlerhafte Konfiguration heranzukommen und das Problem zu lösen.

Den Rescue Mode aktivieren

Den Rescue Mode aktivierst du mit dem blauen "Notfallkoffer"-Button im Cloud Control Panel. Beim Aktivieren des Rescue Mode wird dein Server automatisch neu gestartet bzw. eingeschaltet und bootet dann das Grml Live-Image. Mittels VNC Console kannst du nun auf deinen Server zugreifen und bei Bedarf z.B. einen Netzwerk-Zugang öffnen oder das root-Volume mounten.

Grml bietet dir vom Start weg viele Möglichkeiten. Lässt du den 30-Sekunden-Countdown des Bootloaders verstreichen, dann startet es mit den Default-Einstellungen und bietet dir via VNC Console ein Auswahlmenü, in dem du etwa das Tastaturlayout oder die Netzwerk-Konfiguration anpassen kannst. Mit Drücken von "q" landest du in der zsh Shell und entscheidest selber, was du als Nächstes tust.

Mehr Features für schnelleres Arbeiten

Noch zielgerichteter – und bequemer – arbeitest du, wenn du bereits dem Bootloader einige Infos mitgibst: Drücke während dem Countdown die Tabulator-Taste und hänge beim angezeigten String noch Optionen an, etwa services=networking,cloud-init-main,cloud-config,ssh, gefolgt von der Enter-Taste. Damit aktiviert Grml gleich beim Booten das Netzwerk (die Einstellungen erhält es mittels DHCP) und lädt den SSH-Daemon.

Vor allem aber startet es auch "cloud-init"; dieses holt sich von unserem Metadaten-Server u.a. die SSH Public-Keys, die du beim Erstellen des Servers angegeben hattest, und hinterlegt sie für den Live-User "grml". So kannst du gleich mit ssh grml@<IP-Adresse> auf den Server zugreifen und hast alle von SSH gewohnten Möglichkeiten, inklusive Copy/Paste von deinem lokalen System sowie File-Transfers.

Grml bietet dir viele Hilfen und Abkürzungen. Um einen Überblick zu gewinnen, nutze grml-tips <suchbegriff> direkt in der Grml zsh auf deinem Server, und wirf einen Blick in die Cheatcodes auf der Grml-Website.

Zurück zum Normalbetrieb

Nach getaner Arbeit deaktivierst du den Rescue Mode wieder via Control Panel. Der Server wird erneut neu gestartet und bootet wieder wie gewohnt von seinem root-Volume. War die Fehlerbehebung erfolgreich, erreichst du deinen Server danach wieder auf dem gewohnten Weg, etwa via SSH mit deinem üblichen Username und SSH-Key.

Solange der Rescue Mode aktiv ist, kannst du den Server auch rebooten oder ausschalten, etwa mit dem Kommando shutdown. Sei dir zuvor jedoch bewusst: Ein ausgeschalteter Server im Rescue Mode kann nur wieder eingeschaltet werden, indem der Rescue Mode deaktiviert wird (Grund dafür ist eine Eigenheit von OpenStack, auf dem unsere Cloud-Infrastruktur basiert). Der Server wird danach wieder von seinem root-Volume zu booten versuchen, wobei es dir jedoch freisteht, den Rescue Mode erneut zu aktivieren.

Dass es in der IT auch mal hakt, kennen wir alle. Mit dem neuen Rescue Mode für deine Server bei cloudscale bist du nun noch schneller dort, wo es zählt: etwa bei der entscheidenden Config, die alles wieder zum Laufen bringt.

Das richtige Werkzeug, wenn's drauf ankommt!
Dein cloudscale-Team

Den Snapshot von einem Volume erstellst du blitzschnell, etwa vor einem grösseren Upgrade oder sonstigen Change an deinem Server. Läuft etwas schief, setzt du den Server ebenso blitzschnell auf den Snapshot und damit auf den früheren, funktionsfähigen Zustand zurück. Aber was, wenn du lediglich den Inhalt eines Snapshots prüfen willst oder nur ein einzelnes File daraus benötigst, etwa die vorherige Version einer wichtigen Config?

Seit Kurzem kannst du aus deinen Volume Snapshots auch neue Volumes erstellen – das neue Volume enthält dann exakt die Daten, die im Snapshot "eingefroren" worden waren. Im obigen Beispiel könntest du das neue Volume dann an den betreffenden Server anschliessen, mounten und so gezielt auf das benötigte Config-File zugreifen.

Selbstverständlich sind Updates und ihre möglichen Fallstricke nicht der einzige Anwendungsfall für dieses neue Feature. Naheliegend ist etwa eine 1:1-Kopie von einem root-Volume: Bisher hättest du deinen Server mit einem Live-System gestartet und dann – z.B. mit dd – das Volume blockweise kopiert. Neu erstellst du einfach einen Snapshot und verwandelst dann diesen in ein separates, neues Volume. Damit kannst du anschliessend flexibel weiterarbeiten, etwa indem du den Inhalt des Volumes in ein lokales Archiv herunterlädst. Oder du erstellst daraus eine Abbild-Datei für ein "Custom Image" im "raw" Format (die direkte Verwendung als root-Volume für einen neuen Server ist derzeit hingegen nicht möglich).

Nutzung über bestehenden API-Endpoint

Um aus einem Snapshot ein neues Volume zu erstellen, benutzt du den gleichen API-Endpoint wie schon bisher zum Erstellen eines Volumes. Gib dabei als Parameter die volume_snapshot_uuid an, um den gewünschten Snapshot als Basis für das neue Volume zu identifizieren. Zudem nimmt die API einen name und optional tags für das neue Volume entgegen; die übrigen Eigenschaften (wie etwa die Grösse oder der Cloud-Standort) richten sich nach dem angegebenen Snapshot.

Der Request an die API könnte bspw. folgendermassen aussehen:

curl -i -H "Authorization: Bearer DeinApiTokenHierhin" \
  -F name="my-volume-name" \
  -F volume_snapshot_uuid="351d461c-2333-455f-b788-db11bf0b4aa2" \
  https://api.cloudscale.ch/v1/volumes

Wie gewohnt findest du alle nötigen Details im erweiterten Abschnitt zu "Create a Volume" in unserer API-Dokumentation.

Beachte auch beim Erstellen von Volumes aus Snapshots, dass die Snapshots "crash-consistent" sind. Sie enthalten also ein Abbild des ursprünglichen Volumes exakt zu dem Zeitpunkt, als der Snapshot angelegt wurde – etwa so, als ob der Server in diesem Moment gecrasht wäre. Je nach den konkreten Umständen kann es sinnvoll sein, vor dem Erstellen eines Snapshots heikle Services zu stoppen oder den Server ganz herunterzufahren, sodass auch Write-Caches etc. auf dem Volume und damit im Snapshot enthalten sind. Beim Vorbereiten eines Custom Image achte zudem darauf, dass dieses "cloud-init" enthalten und möglichst klein sein sollte – freien Platz nach Bedarf fügst du dann erst hinzu, wenn du mit dem Image einen neuen Server erstellst.

Zu beachtende Punkte

Sei dir bewusst, dass nicht nur Snapshots, sondern auch daraus erstellte Volumes kein Backup darstellen. Zum einen befinden sie sich im gleichen Storage-Cluster wie das ursprüngliche Volume und sind bei technischen Problemen potenziell ebenfalls betroffen. Zum anderen nutzen wir für eine schnelle und effiziente Bereitstellung von Snapshots und Volumes "Copy-On-Write" (COW), weshalb verschiedene Volumes und Snapshots im Hintergrund von den gleichen, gemeinsamen Datenfragmenten abhängig sein können. Für ein robustes Backup nutze Snapshots und darauf basierende Volumes als Zwischenschritt und kopiere die Daten anschliessend an einen separaten Ort wie etwa ein Archiv, welches du bei dir lokal behältst.

Für das Handling deiner Volumes und Snapshots ergeben sich durch den im Hintergrund benutzten COW-Mechanismus allerdings keine Einschränkungen. Auch wenn du einen Snapshot als Basis für ein neues Volume benutzt hast, kannst du den Snapshot – oder auch das ursprüngliche Volume als Ganzes – später löschen, ohne dass dies das neue Volume beeinflusst.

Als Basis eines neuen Volumes unterstützen dich Snapshots auch dann, wenn es nicht ums "Reverten" eines ganzen Servers geht. Behalte etwa den Inhalt deiner root-Volumes, wenn du virtuelle Server löschst, erstelle eine konsistente 1:1-Kopie als Basis für einen Download oder ein Custom Image, oder greife auf frühere Dateiversionen zurück, während du alles andere auf dem neuen Stand belässt. Beginne einfach mit einem Snapshot und halte dir damit alle Türen offen.

Für Momente zum Festhalten,
Dein cloudscale-Team

Separate Projekte, gemeinsames Netz

Mit privaten Netzen kannst du virtuelle Server an einem Cloud-Standort sozusagen intern "verkabeln", so etwa einen Webserver, der Anfragen von Clients entgegennimmt, mit dem zugehörigen Datenbank-Backend. Wenn einzelne Server gar nicht aus dem Internet erreichbar sein müssen, minimierst du damit nicht zuletzt die Angriffsfläche. Verbinde deine Server und Load-Balancer nun auch dann mittels privatem Netz, wenn sie sich nicht im gleichen Projekt befinden.

Projekte bringen nämlich nicht nur Übersicht und Ordnung in deine Cloud-Ressourcen: Sind in deiner Organization unterschiedliche Teams mit der Wartung bspw. von Web-Workern und DB-Clustern betraut, legst du deren Zugriffsrechte im Control Panel für jedes Projekt separat fest. Mit getrennten Projekten und einem geteilten privaten Netz kannst du dann sowohl die Zuständigkeiten sauber abbilden als auch die Datenbanken vom Internet abschotten, während sie gleichzeitig von den Web-Workern aus erreichbar bleiben.

Ein weiteres Beispiel für eine solche Trennung könnte etwa sein, wenn du das Management deiner Firewall an einen externen Dienstleister ausgelagert (und dieser "Partner Organization" im Control Panel Berechtigungen im "Firewall-Projekt" gewährt) hast; der gefilterte Traffic kann dann im privaten Netz zu den Servern in deinen anderen Projekten fliessen. Oder vielleicht hast du einen zentralisierten Log-Server, den du – Stichwort: "Segregation of Duties" – in einem eigenen Projekt betreibst. Schliesslich kannst du so auch die Reichweite eines API-Tokens begrenzen, das du zur Automatisierung in einem Tool hinterlegt hast.

Geteilte Netze nutzen

Wenn sich zwei Projekte ein privates Netz teilen sollen, lege vorab fest, welches der Projekte der "Owner" des Netzes sein soll. Nur aus diesem Projekt heraus können später Details wie der Name oder die MTU des Netzes geändert werden. Zum eigentlichen Teilen (oder um später den Kreis der teilnehmenden Projekte zu ändern) gib kurz unserem Support Bescheid, den Link dazu findest du im Control Panel unter "Network > Sharing".

Die Eigenschaften des privaten Netzes sind für alle beteiligten Projekte sichtbar, insbesondere etwa der Name des Netzes, um es beim Anschliessen eines Servers sicher zu identifizieren. Unter "Network > Ports" ebenfalls sichtbar sind die MAC-Adressen und – sofern via DHCP verwaltet – die IP-Adressen aller Geräte an diesem Netz: einerseits sind diese technischen Details sowieso für alle im Netz zugänglich (etwa mittels ARP-Requests), andererseits helfen sie dir, Kollisionen und ihre Folgefehler zu vermeiden. Nicht sichtbar sind hingegen die Namen von Servern und Load-Balancern in fremden Projekten; solche Geräte erscheinen einfach als "Other Device".

Apropos IP-Adressen: Du kannst in dem privaten Netz beliebige IPs nutzen und so auch darauf Rücksicht nehmen, wenn ein beteiligtes Projekt bereits einem bestimmten Adressschema folgt. Mehr Informationen zur Konfiguration des gewünschten Subnets und weiteren DHCP-Features findest du in unserem Beitrag zum Managed DHCP.

Geteilte private Netze erlauben dir, den internen Datenfluss zwischen den richtigen Systemen zu gewährleisten, ohne dass diese alle im gleichen Projekt (und damit von den gleichen Personen verwaltet) sein müssen. So kannst du Berechtigungen präziser gliedern oder auch Services zentralisieren, die von mehreren Projekten genutzt werden – innerhalb deiner Organization genauso wie mit Partner Organizations.

Network? Go!
Dein cloudscale-Team

Der Load-Balancer "als Ganzes"

Ein cloudscale Load-Balancer besteht im Hintergrund aus einem redundanten Paar von virtuellen Servern, die wir für dich managen. Nach aussen hin teilen sie sich eine IP-Adresse (die sog. VIP, kurz für "virtuelle IP-Adresse"), die auf einem der beiden Systeme aktiv ist und – ähnlich einer Floating IP – bei einem erkannten Problem automatisch und praktisch nahtlos auf das andere System umgezogen wird. So verhindern wir, dass der Load-Balancer selbst zum Single Point of Failure wird, während du dir den Aufwand sparst, ein solches Setup in Eigenregie aufbauen und pflegen zu müssen.

Aus logischer Perspektive ist der Load-Balancer (bzw. das Load Balancer Object in der API) eine Art Klammer, die hinter der erwähnten VIP die nachfolgend beschriebenen Bestandteile "zusammenhält".

Zusätzliche Parameter sowie Beispiele für API-Requests und -Responses zu allen genannten Objects findest du wie immer in unserer umfassenden API-Dokumentation, so dass du alles gleich in der Praxis ausprobieren kannst.

Die Listeners

Ein Listener ist sozusagen das Ohr, mit dem dein Load-Balancer auf eingehende Verbindungen hört. Wenn du deinen Load-Balancer bspw. für HTTPS-Traffic einsetzen willst, wirst du typischerweise einen Listener auf TCP-Port 443 einrichten. Besonders praktisch: An dieser Stelle kannst du bereits definieren, welche Clients überhaupt eine Verbindung aufbauen dürfen. Erfasst du in allowed_cidrs eine oder mehrere IP-Adressen bzw. -Ranges, dann können sich nur diese, aber keine anderen Adressen zu deinem Listener verbinden.

Wie es mit dem einmal eingegangenen Traffic weitergeht, bestimmt sich nach dem konfigurierten Pool. Meist wirst du zu jedem Listener einen separaten Pool angeben, es ist aber auch möglich, mehrere Listeners auf den gleichen Pool zeigen zu lassen.

Die Pools und ihre Pool Members

Ein Pool fasst gewissermassen alle eingehenden Connections zusammen, die auf die gleiche Weise gehandhabt werden können. In erster Linie bedeutet das, die Connections an einen oder mehrere Backend-Server – die sog. Pool Members – zu verteilen, welche die Requests dann bearbeiten. Für jeden Pool Member kannst du separat konfigurieren, unter welcher IP-Adresse und Port er bereit ist, die Connections aus diesem Pool anzunehmen. In unserem Beispiel müsste da also ein HTTPS-Server laufen, der aber nicht zwingend auf Port 443, sondern pro Pool Member separat auf einen beliebigen Port konfiguriert sein kann.

Direkt auf dem Pool selber konfigurierst du, nach welchem Schema die Connections bei zwei oder mehr Pool Members verteilt werden. Statt simplem round_robin kannst du mit least_connections neue Connections zu dem Pool Member leiten, der gerade die wenigsten aktiven Connections hat, oder mit source_ip alle Connections von einem bestimmten Client zum immer gleichen Pool Member – etwa für persistente Sessions bei einer Website.

Wähle zudem das protocol für deinen Pool: Mit tcp "sehen" bzw. loggen die Pool Members die IP-Adresse des Load-Balancers als vermeintlichen Client, da vom Load-Balancer zum Backend zwar die Nutzdaten weitergereicht werden, hierfür aber eine neue TCP-Verbindung aufgebaut wird. Mit proxy bzw. proxyv2 kannst du das umgehen, wenn deine Serversoftware es unterstützt (wie etwa nginx): Der Load-Balancer kann mit diesem Protokoll nicht nur die Nutzdaten der ursprünglichen Connection an den Backend-Server weitergeben, sondern auch die Information über die ursprüngliche Client-IP hinzupacken.

Die Health Monitors

Optional kannst du für jeden Pool einen Health Monitor konfigurieren. Damit legst du fest, wann die Pool Members als "gesund" gelten – etwa wenn sie auf Pings antworten oder auf einen konfigurierbaren HTTP-Request den erwarteten HTTP-Status-Code zurückliefern. Anhand des Health Monitors kann der Load-Balancer die einzelnen Pool Members periodisch überprüfen und das Balancing laufend so anpassen, dass eingehende Connections nur an funktionsfähige Backend-Server weitergereicht werden.

Zu guter Letzt möchten wir noch darauf hinweisen, dass ein Load-Balancer wahlweise aus dem Internet erreichbar sein kann oder nur aus einem deiner privaten Netze, etwa für Services innerhalb eines Kubernetes-Clusters. Öffentlich erreichbare Load-Balancer können zudem mit Floating IPs kombiniert werden. Ein einzelner Load-Balancer kann übrigens für eine Vielzahl von Services/Pools genutzt werden mit ihrem je separaten Set an Pool Members. Unser Load-Balancer "as a Service" ist aber nicht nur enorm flexibel, sondern mit CHF 1.50 pro Tag auch ausgesprochen günstig – und damit das ideale Upgrade für Setups, bei denen dir Availability wichtig ist.

Servers: Healthy.
Dein cloudscale-Team

Von ETH Network Security

Das Produktionsnetzwerk von SCION ist in den letzten Jahren stark gewachsen. Zu den bemerkenswerten Beispielen für den Einsatz gehören das Secure Swiss Finance Network (SSFN) und das Secure Swiss Health Network (SSHN), die beide kritische Infrastrukturen unterstützen und auf die Mitglieder ihres jeweiligen Ökosystems zugeschnitten sind.

Hier führen wir dich durch die Schritte, die wir befolgt haben, um ein SCION Autonomous System (AS) in der Cloud bereitzustellen, unterstützt von Cyberlink und cloudscale – genau so, wie es jeder Kunde tun könnte.

Der erste Schritt besteht darin, sich mit cloudscale und Cyberlink in Verbindung zu setzen, die uns detaillierte Informationen über ihr SCION-Angebot zur Verfügung gestellt haben. Zum Zeitpunkt der Erstellung dieses Artikels unterstützen sie zwei Arten von SCION-Konnektivität.

Unmanaged SCION-Zugriff

Diese Option bietet einen direkten SCION-Link zum Cyberlink SCION Border Router bei cloudscale innerhalb der benötigten SCION ISolation Domain (ISD). Kunden, die sich für diesen Ansatz entscheiden, sind für die Bereitstellung und Verwaltung ihrer eigenen SCION AS-Dienste in ihrem Virtual Data Center (VDC) verantwortlich.

Lies das ganze Walk-through für unmanaged SCION-Zugriff auf www.scion.org.

Managed SCION-Zugriff

In diesem Setup übernimmt Cyberlink die Bereitstellung und Verwaltung von SCION-Services im Auftrag des Kunden und bietet so eine komfortablere Erfahrung. Der gemanagte Zugriff verwendet die Anapaya EDGE-Appliance.

Lies das ganze Walk-through für managed SCION-Zugriff auf www.scion.org.

GitLab Fleeting: Flexible Ressourcen für deine Tests

GitLab bietet dir eine umfassende Plattform für die Software-Entwicklung, die weit über die reine Sourcecode-Verwaltung hinausgeht und die du – im Unterschied zu ähnlichen Produkten – selbst hosten kannst. GitLab Runners führen dabei deine automatisierten Tests aus und können dynamisch die dazu benötigte Rechenleistung anfordern, z.B. von cloudscale. Früher hatte GitLab hierzu auf Docker Machine zurückgegriffen, das jedoch seit Längerem "deprecated" war. Als moderner Ersatz wurde deshalb GitLab "Fleeting" entwickelt und passend dazu unser cloudscale-Plugin. Damit hast du jederzeit die nötigen Cloud-Ressourcen für deine Tests zur Verfügung.

Die Vorteile liegen auf der Hand: Mit ausreichend Rechenpower wartest du weniger lange, bis deine Pipelines durchgelaufen sind (oder überhaupt erst an die Reihe kommen), und hast schneller das Feedback, das du zum Weiterarbeiten brauchst. Gibt es gerade nichts zum Testen, so können die Ressourcen automatisch abgebaut und die Kosten damit minimiert werden. Indem die GitLab Runners regelmässig durch neue Instanzen ersetzt werden, senkst du zudem das Risiko, dass deine Tests durch angesammelte Artefakte, Configs und ähnliches verfälscht werden.

Autoscaling einfach selbst ausprobieren

Geschrieben wurde das cloudscale-Plugin für GitLab Fleeting in Zusammenarbeit mit Puzzle ITC AG und zu einem wesentlichen Teil von Yannik Dällenbach. In seinem Blogbeitrag bei Puzzle kannst du Yannik sozusagen Schritt für Schritt bei der Entwicklung zusehen. Einblicke ins Packaging des Plugins gibt dir zudem Denis Krienbühl in unserem Engineering Blog. Wenn du gleich zum Ausprobieren übergehen möchtest, kannst du mit einem Ansible Playbook inklusive kurzer Anleitung einfach und in wenigen Schritten einen GitLab Server mitsamt Runner und Plugin aufsetzen und das Autoscaling gefahrlos "hands-on" testen.

Am besten erstellst du dazu im Cloud Control Panel ein neues Projekt – so ist jederzeit klar, was zu deinem Test gehört –, und in diesem Projekt ein API-Token mit "Write access". Zudem benötigst du eine Python-Umgebung, aus der heraus du das Aufsetzen des Setups anstösst. Abhängig von deinem System musst du möglicherweise noch einzelne Software-Pakete ergänzen; bei einem virtuellen Server mit frischem Ubuntu 24.04 LTS etwa fehlt noch python3.12-venv. Nicht vorausgesetzt wird hingegen, dass du bereits mit Ansible arbeitest: Das Repository bringt alles Nötige mit, damit du deinen GitLab Server mit Autoscaling automatisiert einrichten kannst.

Beginne mit dem Klonen des Repositories "gitlab-runner", und folge den wenigen nötigen Schritten im Readme. Nach dem Ausführen des Playbooks, das eine Weile in Anspruch nehmen kann, findest du in deinem cloudscale-Projekt zwei neue virtuelle Server. Auf dem Server "gitlab" läuft – wie der Name vermuten lässt – deine GitLab-Installation. Diese erreichst du über ein HTTPS-geschütztes Web-Interface; die Zugangsdaten werden dir gegen Ende des Playbook-Outputs angezeigt. Ebenfalls auf diesem Server läuft eine Instanz von "GitLab Runner", die für das Dispatching von CI-Jobs und den Auf-/Abbau der dafür nötigen virtuellen Server zuständig ist. Daneben findest du einen virtuellen Server "fleeting-*", der schon für deine ersten CI-Jobs bereitsteht – weitere solche Server werden nach Bedarf automatisch erstellt und wieder entfernt.

Im Readme findest du auch einen Beispiel-CI-Job, um deine Runners gleich in Aktion zu sehen. Dieser Job prüft, ob er auf Artefakte im gemeinsamen CI Cache zugreifen kann; hast du beim Setup den s3_cache aktiviert und die Zugangsdaten zu einem Bucket in unserem Object Storage angegeben, sollte der Job ab dem zweiten Durchlauf melden, den Cache gefunden zu haben. Schau auch mal in die Konfiguration hinter den Kulissen: So ist es etwa dir überlassen, welchen Flavor und damit wieviel Performance die Server für deine CI-Jobs mitbringen. Auch kannst du bestimmen, wieviel "spare" Kapazität jederzeit zur sofortigen Nutzung bereitstehen soll – sogar abhängig von Wochentag und Uhrzeit.

Wenn du noch kein selbstgehostetes GitLab hast, richtest du dir mit unserem Ansible Playbook im Handumdrehen ein voll funktionsfähiges Setup ein, mit dem du gleich loslegen kannst. Wenn du ein manuelles Setup bevorzugst oder sogar bereits mit GitLab arbeitest, dann wirf einen Blick in den Code unseres Fleeting-Plugins und des Playbooks und übernimm einfach, was zu deinem Use-Case passt. Hol dir die volle Performance dann, wenn deine CI-Jobs sie brauchen – und spar dir die Kosten für den Rest der Zeit.

Immer genau das, was du brauchst.
Dein cloudscale-Team

Sicher und flexibel mit Snapshots

Hinterher ist man immer klüger. Deshalb entscheidest du bei cloudscale erst im Nachhinein, ob ein Change überhaupt stattgefunden hat: Ging alles gut und dein Server läuft wie erwartet, dann belässt du es dabei; stellt sich jedoch heraus, dass der vorherige Zustand besser war, stellst du diesen aus dem Snapshot wieder her und lässt den misslungenen Change sozusagen aus der Timeline verschwinden. Mit bis zu 10 Snapshots pro Volume kannst du bei einer umfangreichen Umstellung auch mehrere Zwischenstände "einfrieren" und erst später entscheiden, ob und zu welchem Punkt du zurückkehren möchtest.

Snapshots unterstützen die Sicherheit deiner Server in mehrerer Hinsicht: Zum einen reduzierst du das Restrisiko, das mit Changes einhergeht, praktisch auf Null – den funktionsfähigen Ausgangszustand hast du in jedem Fall auf sicher. Das senkt auch die Hürden, verfügbare (Sicherheits-)Updates zu installieren und deine Systeme aktuell zu halten. Und auch um einen Updateprozess an sich gezielt mehrfach oder in Varianten durchzuspielen, helfen dir Snapshots: Setze dein Lab-System beliebig oft zurück und finde den besten Approach für deinen Change, noch bevor du das produktive Setup anfasst.

Hinweise zur Nutzung

Deine Volumes mit ihren Snapshots findest du im Control Panel unter "Services > Storage > Volumes"; zudem sind auf dem "Storage"-Tab deiner virtuellen Server die daran angeschlossenen Volumes ebenfalls verlinkt.

Jeder Snapshot hat einen Namen, den du beim Erstellen festlegen und auch später noch ändern kannst. Nenne deinen Snapshot z.B. "Nach Schritt 3 DB-Konvertierung", damit du im Bedarfsfall zielsicher den Zustand wiederfindest, zu dem du zurückkehren möchtest, und dich nicht ausschliesslich auf Datum und Uhrzeit des Snapshots stützen musst.

Volume Snapshots sind "crash-consistent", sie frieren also exakt denjenigen Inhalt deiner virtuellen Festplatte ein, der beim Erstellen des Snapshots vorhanden ist (so wie wenn der Server in diesem Moment "gecrasht" wäre). Kläre allenfalls ab, wie sich deine Applikation verhalten wird, wenn du das Volume auf so einen Zustand zurücksetzt. Unter Umständen ist es sinnvoll, Services oder den ganzen Server zum Erstellen von Snapshots herunterzufahren, damit etwa Caches sicher auf das Volume geschrieben werden und damit im Snapshot enthalten sind.

Sind mehrere Snapshots eines Volumes vorhanden, so kannst du nur zum neusten davon zurückkehren. Für einen früheren Zustand lösche einfach die Snapshots, die du überspringen möchtest – sobald der gewünschte Snapshot der neuste ist, steht er zum Revert zur Verfügung. Zum Zurücksetzen muss zudem ein non-root-Volume vom Server getrennt bzw. bei einem root-Volume der virtuelle Server ausgeschaltet sein.

Das Kleingedruckte: bitte beachten

Sei dir auch weiterhin bewusst, dass Snapshots ein richtiges Backup nicht ersetzen. Volumes und die zugehörigen Snapshots werden bei uns im gleichen Storage-Cluster gespeichert, und bei einem allfälligen Ausfall sind potenziell auch die Snapshots mitbetroffen. Snapshots können zudem nur zum Zurücksetzen ganzer Volumes benutzt werden; ein selektives Auslesen/Wiederherstellen von Daten ist nicht möglich.

Wir möchten dir die Nutzung von Volume Snapshots wärmstens ans Herz legen. Sei es via unsere API – etwa als Teil deines automatisierten Servermanagements – oder jetzt auch via webbasiertes Control Panel: Halte dir die Möglichkeit offen, deine Changes bei Bedarf nochmals neu (und vielleicht anders) zu versuchen oder sie komplett ungeschehen zu machen.

Hält dir Optionen offen:
Dein cloudscale-Team

Für weitere drei Jahre zertifiziert

Das Informationssicherheits-Managementsystem der cloudscale.ch AG ist seit 2019 zertifiziert. Geprüft werden wir jeweils nach der Norm ISO/IEC 27001, die sich mit "Informationssicherheit" ganz allgemein befasst und die von Organisationen praktisch aller Grössen und Branchen umgesetzt werden kann, sowie nach den Normen ISO/IEC 27017 und ISO/IEC 27018, die ergänzende Controls zu Cloud Services bzw. personenbezogenen Daten in Public Clouds enthalten.

Die Zertifizierung ist jeweils auf 3 Jahre befristet und verlangt zudem sogenannte Überwachungsaudits in jährlichem Abstand. Nach der Erstzertifizierung im Jahr 2019 hatten wir 2022 die erste Rezertifizierung erfolgreich bestanden, plus jeweils ein Überwachungsaudit in den anderen Jahren. 2025 war nun erneut eine Rezertifizierung fällig und wir freuen uns, dass wir unseren Status nahtlos aufrechterhalten konnten. Das neue Zertifikat mit Gültigkeit bis 2028 ist auch zum Download verfügbar.

Die neue Norm ISO/IEC 27001:2022

Das Rezertifizierungs-Audit fiel diesmal noch etwas umfangreicher aus als sonst: Wir wurden erstmals nach der neuen Norm ISO/IEC 27001:2022 geprüft, die "Informationssicherheit" noch umfassender betrachtet als die zuvor gültige ISO/IEC 27001:2013. Die neue Norm gibt 93 sogenannte Controls vor, die in Betracht gezogen und – sofern keine wirklich guten Gründe dagegen sprechen – auch umgesetzt werden müssen. Dies sind zwar weniger als früher, jedoch sind keine Controls weggefallen, sondern sie wurden zum Teil einfach in einer neuen Formulierung zusammengefasst und in den Kategorien "Organisatorische Massnahmen", "Personenbezogene Massnahmen", "Physische Massnahmen" und "Technologische Massnahmen" neu geordnet.

Zu den bisherigen, teils neu formulierten Controls kamen auch gänzlich neue hinzu, so etwa in Bezug auf "Business-Continuity" und "Konfigurationsmanagement". Hier zahlte es sich einmal mehr aus, dass Informationssicherheit schon immer zur DNA von cloudscale gehört hat: Viele der von der Norm neu gestellten Anforderungen hatten wir in unserer täglichen Arbeit schon bisher mit abgedeckt. Nicht geändert haben sich die beiden anderen, Cloud-spezifischen Normen (ISO/IEC 27017:2015 und ISO/IEC 27018:2019), deren Controls im Audit ebenfalls mit geprüft wurden.

Kontinuierliche Verbesserung inklusive

Auch in der neuen Norm-Version unverändert zentral – und bei cloudscale eine Selbstverständlichkeit – ist die kontinuierliche Verbesserung. Die Prozesse des ISMS müssen dahingehend ausgestaltet sein, dass Schwachstellen und Potenziale entdeckt und Verbesserungsmassnahmen umgesetzt werden. Dies passt perfekt zu der Art, wie wir bei cloudscale arbeiten und (z.B. mit Automatisierung, Monitoring und Redundanzen) auch die Informationssicherheit laufend weiter stärken. Entsprechend zuversichtlich sehen wir folglich den Überwachungsaudits entgegen, die während der Laufzeit des Zertifikats bis 2028 auf uns zukommen werden.

Ebenfalls jährlich, aber von "ISO" komplett unabhängig, werden wir übrigens für unseren ISAE-3000-Bericht auditiert. Dabei handelt es sich nicht um eine Zertifizierung, sondern um die Prüfung von spezifischen Controls, die einige Kunden – insbesondere in regulierten Branchen – bei ausgelagerten Prozessen für ihr internes Reporting benötigen. Bei Bedarf stellen wir diesen Kunden den Bericht auf Anfrage gerne zur Verfügung.

Audits sind eine Prüfung und als solche eher Pflicht als Vergnügen. Ein Dank gilt hier auch unserer Zertifizierungsstelle Swiss Safety Center AG, die uns seit unserer Erstzertifizierung in konstruktiver Zusammenarbeit begleitet. Und natürlich freuen wir uns, dass wir mit der nahtlosen Erneuerung unserer ISO-27001-Zertifizierung nach aussen zeigen können, was uns das ganze Jahr über am Herzen liegt: Die Sicherheit – umfassend verstanden als Vertraulichkeit, Integrität und Verfügbarkeit – deiner Daten.

Internationale Standards, Schweizer Sorgfalt.
Dein cloudscale-Team

Die neuen GPU-Flavors bei cloudscale

Nutze bei cloudscale ab sofort auch virtuelle Server mit GPUs! Wähle dazu beim Launch eines neuen Servers einen unserer GPU-Flavors aus. Genau wie bei den bisherigen Flex- und Plus-Flavors hast du die Wahl zwischen verschiedenen CPU- und RAM-Ausstattungen, zusätzlich erhält dein Server je nach Flavor eine bis vier physische GPUs zugeteilt. Ebenfalls in den GPU-Flavors enthalten ist eine lokale "Scratch Disk" – dazu gleich mehr.

Die neuen GPU-Flavors sind für maximale Performance ausgelegt. Dementsprechend basieren sie auf den bewährten Plus-Flavors: Die gewählte Anzahl CPU-Cores steht deinem virtuellen Server exklusiv zur Verfügung, und du darfst sie 24/7 voll auslasten. Das Gleiche gilt für die GPUs: Eine oder mehrere NVIDIA L40S GPUs liefern geballte Rechenpower für deine Workloads – die GPUs werden "als Ganzes" direkt als PCI-Devices an deinen virtuellen Server durchgereicht.

Ein neues Element: Die Scratch Disk

Seit Beginn wurden bei cloudscale die virtuellen Festplatten deiner Server in unseren Ceph-basierten Storage-Clustern gespeichert. So stehen sie immer sofort zur Verfügung, unabhängig davon, auf welcher physischen Maschine dein virtueller Server gerade läuft, und diese Volumes (ausser das root-Volume) können zwischen virtuellen Servern verschoben werden. Der Preis dafür ist eine gewisse Latenz; Lese- und Schreiboperationen gehen über Netzwerkverbindungen und sind damit – trotz 100-Gbps-Links – deutlich länger unterwegs als bei lokal verbauten NVMe-Disks.

Im Alltag konzentrieren sich oft die meisten Zugriffe auf einen kleinen Ausschnitt des Datenbestands, der nötigenfalls in einem Cache gehalten werden kann. Weil sich LLMs und ähnliche Workloads hier unterscheiden können, verfügen unsere GPU-Server über eine lokale sogenannte "Scratch Disk". Dieser Speicher liegt auf NVMe-Disks direkt in der physischen Maschine, auf der der virtuelle Server läuft, und bietet so minimale Latenz. Zum Schutz vor Ausfällen werden die Daten zudem in einem RAID-1-Verbund doppelt abgelegt.

Für den Betrieb bringt dieses Setup ein paar Besonderheiten. Beim Verschieben von GPU-Servern auf eine andere physische Maschine (was wegen der GPUs auch nicht "live", sondern nur in ausgeschaltetem Zustand möglich ist) muss der Inhalt der Scratch Disk ebenfalls mit übertragen werden, was eine gewisse Zeit in Anspruch nimmt. Ein Verschieben deines GPU-Servers kann z.B. beim Skalieren ausgelöst werden oder nötig sein, wenn Wartungsarbeiten durch uns anstehen.

Im Fall von (Hardware-)Problemen werden GPU-Server je nach Verfügbarkeit auf einer anderen physischen Maschine neu gestartet. Gehe jedoch davon aus, dass du dabei eine neue, leere Scratch Disk erhältst. Bitte nutze die Scratch Disk daher nur für Daten, deren vollständiger Verlust jederzeit tolerierbar ist, und kopiere allfällige Zwischenergebnisse regelmässig an einen anderen Speicherort.

Ein Blick in die Entwicklung

Unsere GPU-Server stehen seit Ende Februar ausgewählten Kunden zur Verfügung, und das Feedback ist überaus positiv. Parallel zum Sammeln erster Praxiserfahrungen haben wir noch verschiedene Verbesserungen vorgenommen – teils auch an OpenStack, dem Open-Source-Projekt auf welchem unser Setup basiert. Soweit möglich und sinnvoll werden wir unsere Erweiterungen natürlich auch "upstream" an die jeweiligen Projekte zurückgeben.

Zu diesen Verbesserungen gehört, dass die Scratch Disk auch nachträglich vergrössert werden kann – bis zu 1'600 GB stehen dir lokal zur Verfügung, zusätzlich zu den gewohnten Volumes in unseren Storage-Clustern. Beim Verschieben der Scratch Disk zwischen physischen Maschinen haben wir zudem die Datenkompression deaktiviert; mit unserem internen 100-Gbps-Netzwerk lohnt es sich, auf diesen Overhead zu verzichten. Und bei der SSH-Verbindung, die für das Verschieben geöffnet wird, haben wir sichergestellt, dass die eingesetzten Ciphers von der AES-Unterstützung der CPUs profitieren.

Jetzt bist du dran

Beim Erstellen eines neuen virtuellen Servers in unserem Cloud Control Panel findest du die GPU-Flavors im Tab "Dedicated GPUs". Bitte benutze einmalig den Link "please contact support" und gib uns die Eckpunkte deiner geplanten Nutzung an; als Attachment benötigen wir den unterschriebenen "Vertragszusatz für GPU-Server". Nach einer manuellen Prüfung schalten wir die GPU-Flavors für dein gewünschtes Projekt frei.

Update: Den "Vertragszusatz für GPU-Server" kannst du für deinen Account bzw. Organization jetzt ganz einfach selbst im Control Panel unter Contracts > GPU Addendum unterzeichnen und sofort loslegen – ganz ohne Support-Anfrage.

Falls du noch keinen spezifischen Use Case hast, aber dennoch einmal mit deinem eigenen Chatbot sprechen möchtest, macht Lukas dir den Einstieg leicht. In unserem Engineering Blog zeigt er dir Schritt für Schritt, wie du Ollama und DeepSeek-R1 70B bei cloudscale installierst und übers Web zugänglich machst. Als Tipp: Unsere NVIDIA L40S haben 48 GB Memory pro GPU; damit die Performance nicht einbricht, nimm so viele GPUs, dass dein gewähltes Model vollständig im Memory der GPUs Platz findet.

Unsere neuen GPU-Server mit aktuellen NVIDIA L40S GPUs und lokaler Scratch Disk bieten maximale Performance für deine LLM- und KI-Workloads. Nach einmaliger Freischaltung kannst du GPU-Server via Control Panel oder API jederzeit in Self-Service starten, skalieren und löschen. Und natürlich profitierst du dabei – wie bei cloudscale üblich – von sekundengenauer Abrechnung ohne Fixkosten und dem Datenstandort Schweiz. Momentan ist das Angebot jedoch begrenzt: first come, first served.

Weiterhin persönlich für dich da,
Dein cloudscale-Team

Die Besten in deinem Team

Wer zu den Besten gehören will, braucht einen klaren Fokus. Für uns bei cloudscale beispielsweise ist es die Infrastruktur: durchdacht bis ins Detail, rock-solid und mit einem top Support für unsere Kunden, die sich 24/7 auf uns verlassen können. Für andere kann es die Entwicklung von spezialisierten Apps sein, die Analyse von Daten, das Optimieren von Geschäftsprozessen – oder etwas ganz anderes, für das sie auf Cloud-Services angewiesen sind.

Weil man nicht in jedem Gebiet gleichermassen zu den Besten gehören kann, gibt es unseren Marktplatz. Hier findest du Managed Services von unseren Partnern – für diejenigen Komponenten, die dir zwar wichtig sind, aber nicht zu deinem Kerngeschäft gehören. Allen Services gemeinsam ist, dass sie von unseren Partnern auf der Infrastruktur von cloudscale betrieben werden. So kannst du dir sicher sein, dass du auf jeder Ebene den Anbieter mit dem passenden Know-How an deiner Seite hast.

Vom Passwort-Manager bis zur kompletten Container-Infrastruktur

Die Anbieter auf unserem Marktplatz decken ein breites Spektrum ab: So findest du z.B. Lösungen rund um den persönlichen Arbeitsplatz für dich und dein Team, die Kollaboration an gemeinsamen Dokumenten oder einen geteilten Passwort-Manager. Ebenso fündig wirst du, wenn du einfach deine containerisierten Anwendungen deployen möchtest und dafür eine passende Kubernetes-Umgebung (z.B. auf Basis von OpenShift oder Rancher) brauchst.

Natürlich kannst du auch gezielt einzelne Softwarekomponenten als Managed Service beziehen. So ist etwa ein Managed GitLab das perfekte Zuhause für den Source-Code deiner Anwendung; dein Online-Shop kann sich im Backend auf eine gemanagte Datenbank mit PostgreSQL oder MariaDB verlassen, und mit der Benutzerverwaltung in einem Managed Keycloak profitierst du von Single Sign-On in kompatiblen Anwendungen (z.B. auch in unserem Cloud Control Panel).

Passt zu dir

So verschieden wie die verfügbaren Managed Services, so verschieden sind auch die Anbieter dahinter. Wähle aus, wer zu dir und deinem Team passt. Ob du nun besonderen Wert auf Beratung legst oder doch eher auf einen hohen Automatisierungsgrad, ob auf ein breites Anwendungsspektrum "aus einer Hand" oder mehr auf einen Provider in deiner geographischen Nähe – auf unserem Marktplatz wartet der "perfect match" auf dich.

Falls es bisher so aussah, als müsstest du bei cloudscale alles selber machen: der Eindruck täuscht! Schon seit Jahren pflegen wir enge und konstruktive Partnerschaften, und mit dem neuen Marktplatz wird nun besser sichtbar, dass du auch bei cloudscale auf viele professionell gemanagte Services zurückgreifen kannst. Aktuell findest du bereits eine grosse Vielfalt an verschiedensten Angeboten. Mit weiteren Providern sind wir schon im Gespräch und werden diese fortlaufend auf unserer Website ergänzen.

Hol dir die Besten ins Team! Mit der Infrastruktur von cloudscale hast du die volle Kontrolle. Du musst dich deshalb aber nicht um alles selbst kümmern: Mit den Managed Services auf unserem Marktplatz findest du Unterstützung genau dort, wo du sie brauchst, und von einem Partner, der zu dir passt.

Gemeinsam erfolgreich!
Dein cloudscale-Team

Erstelle einen Snapshot von deinem Volume, bevor du einen – möglicherweise riskanten – Change vornimmst. Funktioniert nach dem Change nicht alles wie gewünscht (und scheidet eine gezielte Reparatur aus), kannst du das Volume auf den Snapshot zurücksetzen, d.h. den Inhalt des Volumes so wiederherstellen, als hätte der Change gar nie stattgefunden. Ein Volume Snapshot ist eine Momentaufnahme von einem Volume als Ganzes, also inklusive aller Programme und Daten, aber auch Bootloader, Partitionierung etc. – eben genau so, wie die Bytes auf der virtuellen Festplatte liegen.

Selbstverständlich sind Snapshots nicht erst dann hilfreich, wenn das Kind bereits in den Brunnen gefallen ist: Wenn du Changes vor dem produktiven Deployment auf einem Lab-Setup testest, kannst du mithilfe von Snapshots den Prozess beliebig oft durchspielen, um z.B. Scripts oder sonstige Parameter zu optimieren.

Zum Erstellen eines Snapshots reicht ein einfacher HTTPS-Request an unsere API, z.B.:

curl -i -H "Authorization: Bearer DeinApiTokenHierhin" -F name="pre-dist-upgrade" -F source_volume="2db69ba3-1864-4608-853a-0771b6885a3a" https://api.cloudscale.ch/v1/volume-snapshots

Alle unterstützten Requests und Attribute findest du wie üblich in unserer ausführlichen API-Dokumentation.

Technische Details und Tipps

Snapshots sind "crash-consistent": Hast du zum Zeitpunkt X einen Snapshot erstellt und das Volume jetzt (z.B. nach einem fehlgeschlagenen Software-Upgrade) wieder auf den Snapshot zurückgesetzt, verhält sich der Server so, als hätte man dem Volume zum Zeitpunkt X den Stecker gezogen und es erst jetzt wieder angeschlossen. Write Caches und sonstige Daten, die im Zeitpunkt X nicht auf dem Volume lagen, können so nicht wiederhergestellt werden. Kläre gegebenenfalls ab, ob und wie dein Setup mit so einem Zustand umgehen kann. Je nachdem kann es sich empfehlen, vor dem Erstellen eines Snapshots heikle Services zu stoppen, einen sync auszuführen oder den Server ganz herunterzufahren.

Bei mehr als einem Volume beachte zudem, dass Volume Snapshots zwar einzeln genommen crash-consistent sind, dass sich aber die Datenstände nicht auf den exakt gleichen Zeitpunkt beziehen, wenn zwei oder mehr Volumes im laufenden Betrieb snapshotted werden. Erstelle die Snapshots bei heruntergefahrenem Server, wenn du hier Differenzen vermeiden willst.

Übrigens: Wenn du das Volume seit dem Erstellen eines Snapshots hochskaliert hast und dann zu dem Snapshot zurückkehrst, wird das Volume automatisch wieder auf die Grösse verkleinert, die es beim Erstellen des Snapshots hatte.

Das Löschen von Volumes schliesslich ist nur möglich, wenn keine Snapshots mehr davon existieren. Ist bei einem Root-Volume noch ein Snapshot vorhanden, kann auch der zugehörige Server nicht gelöscht werden. Entferne also bei Bedarf zuerst allfällige Snapshots, bevor du Volumes oder Server löschst.

Zwei zusätzliche Bemerkungen

Wie bei cloudscale üblich werden Snapshots sekundengenau verrechnet. Der Speicherplatz kostet dabei nur die Hälfte des regulären Preises für NVMe-SSD bzw. Bulk Volumes (abhängig davon, auf was für ein Volume sich der Snapshot bezieht). Die Kosten für deine Snapshots findest du im Cloud Control Panel im Bereich "Billing" separat ausgewiesen.

Snapshots ermöglichen es, bei Bedarf ein oder mehrere Volumes eines Servers in einen früheren Zustand zurückzuversetzen. Sei dir aber bewusst, dass sie ein richtiges Backup nicht ersetzen: Einerseits befinden sich die Snapshots bei uns im gleichen Storage-Cluster wie die ursprünglichen Volumes und sind von einem allfälligen Ausfall potenziell mitbetroffen; für maximale Sicherheit und Unabhängigkeit empfehlen wir, von deinen wichtigen Daten immer auch eine Kopie ausserhalb unserer Infrastruktur zu pflegen. Andererseits sind Snapshots dafür ausgelegt, das zugehörige Volume als Ganzes zurückzusetzen; es ist nicht möglich, aus dem Snapshot nur selektiv Daten wiederherzustellen.

Volume Snapshots sind die perfekte Lösung, damit du nach Änderungen innert kürzester Frist auf einen früheren Zustand zurückkehren kannst – sei es für Tests und Schulungen oder als Sicherheitsnetz beim Upgrade kritischer Server. Schnell erstellt und kostengünstig, erspart dir ein Snapshot potenziell jede Menge Kopfschmerzen. Die "Rückgängig-Taste", wo es wirklich drauf ankommt!

Game over? Bonus Life!
Dein cloudscale-Team

Günstigerer Speicherplatz ab 01.02.2025

Die Kosten für den Object Storage werden einmal täglich kurz nach Mitternacht (Zeitzone von Zürich) deinem Guthaben belastet. Dabei setzen sie sich aus drei Komponenten zusammen, nämlich der Anzahl der API-Requests (CHF 0.005 pro 1000 Requests), dem ausgehenden Datenverkehr (CHF 0.02 pro GB, eingehender Traffic ist kostenlos) sowie dem belegten Speicherplatz, wobei hier über den Tag hinweg ein Durchschnittswert ermittelt wird.

Die Komponente für den Speicherplatz macht in den meisten Fällen den grössten Anteil an den Gesamtkosten aus. Der belegte Speicherplatz kostet ab dem 01.02.2025 nur noch CHF 0.001 pro GB und Tag und damit 66% weniger als bisher. Damit wird unser Object Storage noch attraktiver, z.B. für Offsite Backups deiner wichtigen Daten. Wie bisher werden übrigens die drei Kostenkomponenten präzise einzeln berechnet, dann addiert und erst zuletzt auf ganze Rappen aufgerundet, bevor sie deinem Guthaben belastet werden.

Einblicke in die technischen Details

Für unsere Storage-Cluster setzen wir bei cloudscale auf Ceph, dessen S3-kompatible HTTPS-API du direkt unter *.objects.rma|lpg.cloudscale.ch erreichst – z.B. für den Up- und Download von Objects. Für die Abrechnung konnten wir hingegen nicht auf Ceph-Features zurückgreifen, weshalb wir hier einen eigenen Microservice namens "rgw-metrics" entwickelt haben. rgw-metrics sammelt die Nutzungsdaten unserer Ceph Storage-Cluster und ermöglicht so einerseits die exakte, nutzungsabhängige Abrechnung und andererseits die Anzeige von aktuellen und vergangenen Nutzungsdaten in unserem Cloud Control Panel und via die API.

rgw-metrics läuft unabhängig von der Software, die das Control Panel und die API bereitstellt, und speichert die gesammelten Nutzungsdaten als einen Zeitreihendatensatz. Vor Kurzem haben wir rgw-metrics einem Rewrite unterzogen: Neben einem Wechsel von Flask zu Django, das wir auch anderweitig einsetzen, setzen wir neu auf ein containerisiertes Setup. Ziel der Umstellung ist zudem nicht zuletzt mehr Effizienz. Mehr Einblicke rund um rgw-metrics gibt dir Julian in unserem Engineering Blog.

Nützliche Features des Object Storage

Im einfachsten Fall erstellst du einen Bucket und benutzt dann eines der zahlreichen S3-fähigen Tools, um Objects hoch- und herunterzuladen und am Ende wieder zu löschen. Unser Object Storage eignet sich aber auch für anspruchsvolle Setups, denn Ceph unterstützt eine Vielzahl an S3-Features wie ACLs, Versioning und Policies für individuelle Zugriffsrechte.

Beispiel 1: Zusätzlicher "read-only" Zugang zu deinem Bucket

Um für eine Person oder Anwendung Lesezugriff auf deinen Bucket (z.B. "my-bucket") einzurichten, erstelle via Control Panel oder API einen zusätzlichen Objects User und achte auf die angezeigte "User ID" (z.B. "11111111...88888888"). Erstelle dann eine Datei wie folgt und speichere sie lokal ab, z.B. unter policy.json:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam:::user/1111111122222222333333334444444455555555666666667777777788888888"},
    "Action": ["s3:ListBucket","s3:GetObject"],
    "Resource": [
      "arn:aws:s3:::my-bucket",
      "arn:aws:s3:::my-bucket/*"
    ]
  }]
}

Füge nun diese Policy zu deinem Bucket hinzu, z.B. mithilfe des Tools s3cmd:

s3cmd setpolicy policy.json s3://my-bucket

Der zusätzliche Objects User kann jetzt mit seinen eigenen Credentials (Access Key und Secret Key) die Objects in "my-bucket" auflisten und lesen, nicht jedoch ändern und löschen.

Beispiel 2: CORS-Header konfigurieren

Du kannst Objects öffentlich zugänglich machen, z.B. mittels:

s3cmd --acl-public setacl s3://my-bucket/my-font.woff2

Das Object ist danach – ohne Authentifizierung mit Access Key und Secret Key – direkt abrufbar unter https://my-bucket.objects.lpg.cloudscale.ch/my-font.woff2.

Beim Einbinden in eine Website – z.B. unter https://www.example.com – kann es aber sein, dass der Browser die Datei aufgrund der "Same-Origin-Policy" nicht lädt. In diesem Fall helfen CORS-Header ("Cross-Origin Resource Sharing"), die du auf deinem Bucket konfigurierst. Erstelle dazu eine Datei wie folgt und speichere sie lokal ab, z.B. unter cors.xml:

<CORSConfiguration>
  <CORSRule>
    <AllowedOrigin>https://www.example.com</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
  </CORSRule>
</CORSConfiguration>

Übertrage diese Konfiguration dann z.B. mittels s3cmd auf deinen Bucket:

s3cmd setcors cors.xml s3://my-bucket

Bei einem Besuch auf https://www.example.com wird der Browser "testweise" auf https://my-bucket.objects.lpg.cloudscale.ch/my-font.woff2 zugreifen und dabei den HTTP-Header

Origin: https://www.example.com

mitschicken. Stimmt die mitgeschickte URL mit der auf dem Bucket konfigurierten überein, dann fügt der Object Storage in seiner Antwort die Header

access-control-allow-origin: https://www.example.com
access-control-allow-methods: GET

hinzu und signalisiert dem Browser damit, dass das Laden der Datei im Kontext dieser Website erlaubt ist.

Unser Object Storage deckt die unterschiedlichsten Anwendungsfälle ab, als Ablage für deine Offsite Backups genauso wie als Storage-Backend deiner Applikationen oder zum Teilen von Dateien. Ab 01.02.2025 profitierst du zudem von deutlich günstigerem Speicherplatz. Was will man mehr?

"Objekt-orientiert" im besten Sinne,
Dein cloudscale-Team

Die Cyberlink AG, ein führender Schweizer Managed Service Provider für Cloud- und Connectivity-Lösungen, übernimmt 40 Prozent der cloudscale.ch AG. Mit dieser strategischen Beteiligung stärkt Cyberlink seine Position im Schweizer Cloud-Markt und erweitert gemeinsam mit cloudscale das Angebot um innovative, lokal verankerte Cloud-Lösungen.

"Die Zusammenarbeit mit cloudscale ermöglicht es uns, unsere Cloud-Dienstleistungen gezielt zu erweitern und Unternehmen mit höchsten Ansprüchen an Datensicherheit und Flexibilität noch umfassender zu unterstützen", erklärt Thomas Knüsel, CEO der Cyberlink AG. "Durch die Speicherung von Daten in Schweizer Rechenzentren und die Nutzung individuell anpassbarer Lösungen erfüllen wir die hohen Compliance-Standards von Branchen wie dem Finanz- und Gesundheitssektor."

Die Partnerschaft erlaubt es Cyberlink, auf die cloud-native Technologien von cloudscale zuzugreifen. Die Cloud-Infrastrukturen von cloudscale basieren auf leistungsstarker Open-Source-Software und bieten virtuelle Server, Load Balancer und Object Storage für anspruchsvolle Projekte. Kunden profitieren zudem von nahtlosen Integrationen in DevOps-Tools wie Ansible und Terraform oder der Möglichkeit, Cloud-Dienste direkt über ein benutzerfreundliches Control Panel oder APIs zu verwalten.

Ein Beispiel für die technologische Innovation ist die gemeinsam entwickelte SCION Cloud, eine revolutionäre Lösung, die speziell für Branchen mit höchsten Anforderungen an Sicherheit, Verfügbarkeit und Compliance entwickelt wurde. Die SCION Cloud kombiniert die hochmoderne und top zertifizierte Cloudplattform von cloudscale mit dem hochverfügbaren SCION Internet von Cyberlink für den schnellsten und einfachsten Zugang zu jeder gängigen Isolation Domain schweizweit.

Für cloudscale bedeutet die Partnerschaft neue Wachstumsmöglichkeiten. "Mit Cyberlink als starkem Partner können wir unsere Marktpräsenz weiter ausbauen und die Weiterentwicklung unserer Services beschleunigen", betont Manuel Schweizer, CEO der cloudscale.ch AG. "Gemeinsam schaffen wir Lösungen, die speziell auf die Bedürfnisse des Schweizer Marktes zugeschnitten sind."

Die Partnerschaft markiert einen wichtigen Schritt für die Zukunft der Schweizer IT-Branche. Durch die Kombination von technologischem Know-how und lokalem Service stärken beide Unternehmen die digitale Infrastruktur der Schweiz und schaffen Mehrwert für Unternehmen, die auf leistungsstarke und rechtskonforme Cloud-Lösungen angewiesen sind.

Informationen für jeden Bedarf

Kommunikation und Transparenz sind uns bei cloudscale wichtig. Schon bisher findest du deshalb im "News"-Bereich unserer Website – und optional in deiner Mail-Inbox – alle paar Wochen frische Informationen, beispielsweise die Vorstellung neuer Features oder Hinweise zur optimalen Nutzung unserer Services. Auf unserer Statusseite unter https://www.cloudscale-status.net publizieren wir zudem anstehende Wartungsarbeiten sowie Informationen zu allfälligen Incidents; direkt dort kannst du die Statusmeldungen auch auf dem Kanal deiner Wahl abonnieren.

Als Ergänzung zu diesen Mitteilungen aus "Firmensicht" lancieren wir nun den Engineering Blog: Hier erfährst du aus erster Hand, mit was sich unsere Mitarbeitenden befassen und was ihnen wichtig ist. Von Techies für Techies geschrieben, findest du in ihren Beiträgen interessante Details aus unserem "Stack", persönliche Einschätzungen rund um ihre Arbeit und bestimmt auch wertvolle Anregungen für deine eigenen Projekte. Die Posts sind in der Regel entweder auf Deutsch oder auf Englisch verfügbar – eben genau so, wie sie von unseren Engineers verfasst wurden.

Breit gefächerter Lesestoff

Natürlich startet unser Engineering Blog nicht mit einer leeren Liste. Zum Beginn findest du bereits drei ganz unterschiedliche Artikel:

Die eigentliche Datenspeicherung in unseren Ceph Storage-Clustern erfolgt durch eine grosse Zahl von OSDs, die – z.B. bei Wartungsarbeiten – gelegentlich neu gestartet werden müssen. Erfahre von Denis, wie wir den Performance-Impact solcher Restarts mit einem "staggered" Ansatz minimiert haben – komplett mit Latenz-Graphen und dem eingesetzten Python-Script (auf Englisch).

Einen Einblick ganz anderer Art gewährt dir Lukas: Erst seit ein paar Wochen dabei, ist er das neuste Mitglied im cloudscale-Team. In einer ungewöhnlichen Analogie zu einem kürzlich vollendeten "Kühlschrank-Projekt" umschreibt er, wie er den Einstieg bei uns erlebt hat, und welche Herausforderungen und Erfolge er bereits verbuchen konnte (auf Englisch).

Unsere Cloud basiert auf etablierten Open-Source-Projekten wie OpenStack und Ceph. Wir schreiben und pflegen aber auch eigene Software in einem Umfang, bei dem es wichtig ist, den Überblick zu behalten. Das effektive Durchforsten von Code und präzise Finden von bestimmten Codestellen ist dabei eine wichtige Fähigkeit. In seinem Post erklärt dir Michi, wie er mit pyastgrep weitermacht, wo Regular Expressions nicht mehr zum Ziel führen (auf Deutsch).

Hast du Fragen oder Inputs zu einem der Beiträge? Schreib an engineering-blog@cloudscale.ch – die Engineers hinter den Posts freuen sich auf dein Feedback!

Entdecke, wie vielfältig die Menschen und Aufgaben hinter unseren Cloud-Services sind. Erfahre, wie unsere Engineers ihre Arbeit erleben, was sie bewegt und welche Lösungen sie finden. Auch wenn du selbst keine Cloud betreibst: Finde spannende neue Perspektiven in unserem Engineering Blog – von Techies für Techies!

Bereit für den Deep Dive?
Dein cloudscale-Team

Von der Idee zur Realität

Die Geschichte unseres cloudscale Hoodies begann zufällig: Einige Computergrafiken sollten veranschaulichen, wie vielseitig unser neues Logo eingesetzt werden kann. Eines der Bilder zeigte einen fiktiven Hoodie, der sofort Begeisterung auslöste – so sehr, dass wir ihn unbedingt auch in der Realität haben wollten.

Wenn schon "cloudscale" draufsteht, sollte natürlich auch unser üblicher Qualitätsanspruch dahinter stehen. Zusammen mit dem Hersteller schafften wir es, dass Ösen und Kordelabschlüsse – passend zu unserem Logo – in Grün und Blau daherkommen. Beim Reissverschluss bestanden wir auf YKK, der Marke welche gemeinhin als Goldstandard gilt, schliesslich soll das Anziehen auch auf lange Sicht Freude bereiten. Und auch bei der Kapuze waren wir erst in der zweiten Iteration glücklich mit dem Schnitt.

Jetzt bist du dran

Trag auch du stolz ein Stück cloudscale bei dir, mit unserem "Circle"-Logo auf der Brust und einem dezenten Schriftzug auf dem linken Oberarm. Schreib uns an die Adresse merchandise@cloudscale.ch und gib Anzahl und Grösse (S, M, L, XL) deiner gewünschten Hoodies sowie die Lieferadresse an.

Bis Ende Dezember 2024 profitierst du vom Spezialpreis von CHF 50 statt 80 pro Hoodie (zzgl. Porto und Verpackung, pauschal CHF 10 für bis zu 3 Hoodies). Versand nur in der Schweiz, auf Rechnung zahlbar innert 10 Tagen, und solange der Vorrat reicht. Die angegebenen Preise verstehen sich inklusive Mehrwertsteuer.

Für unsere Fans: Durchdachte Features, on- und offline. Bestelle jetzt deinen cloudscale Zip Hoodie und schlüpf schon in wenigen Tagen rein – wir vermuten, du wirst ihn gar nicht mehr ausziehen wollen.

Immer gut angezogen,
Dein cloudscale-Team

In Compliance-sensitiven Branchen sind die Systemlandschaften oft hochkomplex und in der Schweiz erwarten wir von ICT-Integratoren nicht nur die Erfüllung formeller Regulatorien, sondern deren konsequente Umsetzung. Um den Anforderungen in Branchen wie dem Finanzsektor, dem Gesundheitswesen und der Versicherungsbranche gerecht zu werden, holen sich viele Unternehmen internationales Beratungs-Know-How ins Haus. Häufig kommen so grosse ausländische Hyperscaler ins Spiel, deren Lösungen auf dem Papier überzeugen, aber deren Datenverarbeitung oft an Standorten ausserhalb der Schweiz erfolgt.

cloudscale.ch und Cyberlink bieten eine Schweizer Alternative. Mit der SCION Cloud haben sie gemeinsam eine Lösung entwickelt, die alle Daten und Workloads vollständig in der Schweiz hält und dabei höchsten Sicherheits- und Compliance-Ansprüchen gerecht wird. Die Architektur ist speziell für die Anforderungen von Finanzdienstleistern, Gesundheitsanbietern und Versicherungen konzipiert und wird ausschliesslich von Schweizer Infrastruktur gestützt.

Mit der SCION Cloud können Entwickler und DevOps-Teams ihre Workloads in der Schweiz betreiben, ohne Abstriche bei der Technologie oder Bedenken bezüglich des Datentransports. Die Regulatorien hierzulande existieren aus gutem Grund – mit der SCION Cloud können Unternehmen diese effizient und zuverlässig erfüllen.

Zwei Schweizer Pioniere nehmen die Herausforderung an

Die cloudscale.ch AG (cloudscale.ch) ist eine Infrastructure-as-a-Service-Anbieterin mit starkem Fokus auf Open-Source-Technologien und einer Self-Service-Plattform, die es Kunden unter Anderem ermöglicht, Data-Center-Services via API zu konfigurieren. Die Nähe zur DevOps- und Cloud-Native-Community ist dabei kein Zufall. Viele Mitarbeitende von cloudscale.ch waren früher selbst Konsumenten solcher Services. "Wir orientieren uns stark am Nutzer, anstatt einfach Produkte zu entwickeln, die wir selbst für gut halten", betont Manuel Schweizer, CEO. Ursprünglich aus der Netzwerktechnik kommend, beschäftigte er sich schon früh in seiner Karriere intensiv mit Netzwerken und deren Optimierung. Als Vorstandsmitglied beim Swiss Internet Exchange (SwissIX) sammelte er wertvolle Erfahrungen in der Schweizer Vernetzungsszene. cloudscale.ch hat sich von Anfang an auf die Bedürfnisse von Kunden mit hohen Anforderungen an Verfügbarkeit und Informationssicherheit fokussiert. Dabei setzt das Unternehmen konsequent auf Open-Source-Technologien.

Cyberlink AG (cyberlink.ch), seit fast drei Jahrzehnten innovativer Service Provider im Schweizer ICT-Markt, hat sich als führender Anbieter von Connectivity- und Cloud-Diensten etabliert. Unter der Leitung von Thomas Knüsel, CEO, der seit 2012 Teil des Unternehmens ist, hat Cyberlink seinen Fokus auf Geschäftskunden und hochsichere Netzwerklösungen verstärkt. Besonders durch die Implementierung von SCION konnte Cyberlink ihre Rolle als Vorreiterin für sichere Netzwerke weiter festigen. "Wir sind als Pionier im Bereich Internet entstanden und haben uns auf Infrastruktur-Dienstleistungen im Bereich Cloud und Connectivity spezialisiert. Unser Ziel ist es, als Managed Service Provider einen Mehrwert zu bieten, indem wir uns kontinuierlich um die Infrastruktur kümmern, damit sich unsere Kunden auf ihr Kerngeschäft fokussieren können", so Knüsel. "Zudem haben wir immer daran geglaubt, dass Synergien sehr relevant sind, und so sind wir über SCION auf cloudscale.ch aufmerksam geworden. Manuel und unser Lead Engineer im Connectivity-Bereich, Matthias Schwarzenbach, haben gemeinsam eine Lösung entwickelt, die SCION in eine moderne Cloud-Umgebung integriert. Wir waren von Anfang an von den Möglichkeiten von SCION überzeugt. Es bietet genau die Sicherheitsmerkmale, die viele unserer Kunden benötigen, und durch unsere Partnerschaft mit cloudscale.ch können wir diese Technologie auch in der Cloud anbieten."

Beide Unternehmen teilen den Anspruch, stets am Puls der Zeit zu bleiben und innovative Technologien einzusetzen, die es Schweizer Unternehmen ermöglicht, den steigenden Anforderungen an Schutz und Compliance gerecht zu werden. Die Entdeckung von SCION als nächste Generation des Internets war der gemeinsame Nenner, der diese Partnerschaft ins Rollen brachte.

Die Entdeckung von SCION: Technische Neugier und die SIX

SCION (Scalability, Control, and Isolation On Next-Generation Networks) stellt eine fundamentale Weiterentwicklung bestehender Netzwerktechnologien dar. Ursprünglich an der ETH Zürich entwickelt, bietet SCION wesentliche Vorteile gegenüber herkömmlichen Netzwerkarchitekturen: SCION ist eine revolutionäre Internet-Architektur, die Pfadkontrolle, erhöhten Schutz und verbesserte Verfügbarkeit bietet.

Unter dem Dach der SCION Association wird die neue Internet-Architektur als offener Standard weiter konzipiert und vorangetrieben. Eingesetzt in der Praxis wird insbesondere die Software-Implementierung der Anapaya Systems AG – ebenfalls ein innovatives Schweizer KMU.

Für Schweizer war es zunächst persönliche Neugier: "Was macht das Ding jetzt eigentlich? Wer braucht das? Als Techniker wollte ich zunächst selbst Berührungspunkte mit der Technologie haben." Der entscheidende Impuls kam, als Fritz Steinmann von der SIX die Ablösung des alten Finance IPNet durch ein SCION-basiertes Netz ankündigte. "Für uns war das eine grosse Chance, da die Zielgruppe für diese Technologie sehr gut zu der Zielgruppe von cloudscale.ch passt", erläutert Schweizer. Mit bestehender ISO-Zertifizierung und ISAE-Reports hatte man die ersten Schritte auf dem Weg in die Finanz- und Gesundheitsbranche bereits getan. Schweizer: "Ich sah das Potenzial, SCION in unsere Cloud zu integrieren und damit einen echten Mehrwert für unsere Kunden zu schaffen."

Für Unternehmen, die hohe Anforderungen an Sicherheit und Compliance haben, ist SCION mit seinen Vorteilen ein absoluter Gamechanger.

Technische Herausforderungen und die Partnerschaft mit Cyberlink

Die Implementierung von SCION in eine Cloud-Umgebung war keine triviale Aufgabe. "Mir wurde schnell klar, dass wir das alleine nicht stemmen können", gesteht Schweizer. Zudem hatten Kunden oft Standorte bei verschiedenen Anbietern, was eine einheitliche Lösung erforderte.

"Gemeinsam mit Matthias, dem Network Engineering Lead bei Cyberlink, konnten wir über sechs Monate hinweg alles engineeren und durchtesten", berichtet Schweizer begeistert.

Die Technische Umsetzung im Detail

Manuel Schweizer beschreibt die Herausforderung bei der Integration von SCION in die cloudscale.ch-Plattform klar und pragmatisch: "Wir wollten nicht für jeden einzelnen Kunden individuelle Hardware verbauen müssen, geschweige denn Hardware auf Vorrat halten, die möglicherweise nie eingesetzt wird." Dies bedeutete, dass anstelle von dedizierter Hardware eine effiziente und skalierbare virtuelle Lösung geschaffen werden musste. In regulatorisch sensiblen Bereichen, wie dem Secure Swiss Finance Network (SSFN), war die Erfüllung der Anforderung an Provider-Redundanz eine der grössten Herausforderungen. "Es wäre nicht damit getan, einfach zwei ISPs an einen redundanten SCION-Core-Cluster anzuschliessen", so Schweizer. Um zur Teilnahme an SIC/euroSIC zugelassen zu werden, bedarf es Edge-Providerredundanz. In einer physischen Welt wäre das mit separaten Anschlüssen an zwei verschiedene ISPs umgesetzt worden. In einer virtuellen Welt wird diese Redundanz aber auf der letzten Meile vom jeweiligen Cloud-Provider des Vertrauens zur Verfügung gestellt. In unserem Fall garantieren Cyberlink und cloudscale.ch gemeinsam die georedundante Anbindung jeder virtuellen Edge an die beiden SCION-Cores. Da diese wiederum an verschiedene ISPs angeschlossen sind, ist das gesamte Setup hochverfügbar und erfüllt so die Anforderung an die Provider-Redundanz auch auf virtueller Ebene. Diese Verbindung bleibt vollständig innerhalb der cloudscale.ch-Infrastruktur, bevor der Traffic den Core verlässt. "Mit dieser klaren Kommunikation und Präferenz sind wir dann zur SIX und haben gepitcht", erklärt Schweizer.

Die Diskussionen mit der SIX und letztendlich auch mit der Schweizerischen Nationalbank (SNB) führten zu einem entscheidenden Punkt: Die SNB, als Aufsicht über den Finanzsektor, hatte das letzte Wort zur endgültigen Architektur. Das Team erkannte schnell, dass eine Core-Cluster-Redundanz allein nicht ausreichend war. "Wir schaffen Provider-Redundanz ab Core", beschreibt Schweizer. Die beiden SCION-Cores sind auf verschiedene Rechenzentren verteilt und über unterschiedliche Upstream-Anbindungen sowie über den SwissIX Internet Exchange mit anderen SCION-Teilnehmern verbunden. Diese Architektur entspricht dem Best-Practice-Setup, das die Anforderungen der SNB erfüllt und höchste Compliance-Standards gewährleistet.

Matthias Schwarzenbach war begeistert von der Zusammenarbeit mit Manuel Schweizer: "Es gab keine Berührungsängste. Manuel und ich haben tagelang zusammen im Sitzungszimmer gesessen, Ideen ausgetauscht und Lösungen entwickelt. Es war diese kreative, fast familiäre Atmosphäre, die uns immer weiter angetrieben hat." Thomas Knüsel erinnert sich ebenfalls: "Die beiden haben sich gegenseitig mit Ideen geradezu überboten und so kam die Lösung auf ein Niveau, das weder von Manuel noch von Matthias alleine hätte erreicht werden können."

Heute ist cloudscale.ch in der Lage, beliebige Isolation Domains (ISDs) wie das SSFN oder das SSHN (Secure Swiss Health Network) mit seiner Cloud zu verbinden. Neue SCION-Edges können in weniger als 24 Stunden – und bald schon in unter 2 Stunden – provisioniert werden. Eine virtuelle Maschine mit dem Anapaya-Image wird gestartet und mit zwei separaten VLANs an die SCION-Cores angebunden. Zusätzliche Glasfaser-Verbindungen oder Layer-2-Services sind nicht erforderlich. Die Lösung ist vollständig Multitenant-fähig und so nah an einer Cloud-native-Lösung, wie es derzeit technisch möglich ist.

Im Rahmen der Konzeption mit SIX und SNB kam die Frage auf, ob die beiden Cores im Cluster-Verbund betrieben werden sollten. "Die Vorteile waren klar", so Schweizer. Im Cluster-Verbund teilen sich die beiden Cores die Pfadinformationen. Diese Verbindung untereinander erhöht die Redundanz und gewährleistet, dass Wartungsarbeiten ohne Verbindungsunterbrüche der Edge durchgeführt werden können. Diese Lösung wurde schlussendlich genehmigt und hat sich bereits jetzt in der Praxis bewährt.

Schweizer resümiert: "Wir haben es geschafft, die SNB von unserer Lösung zu überzeugen. Die SCION Cloud von cloudscale.ch und Cyberlink erfüllt die höchsten Compliance-Anforderungen und bietet eine vollständig konforme und hochperformante Cloud-Infrastruktur."

Vorteile für Entwickler und DevOps Engineers

Für die technische Community bietet die SCION Cloud klare Vorteile: Engineers können die beliebten Features von cloudscale.ch nutzen, gleichzeitig haben sie alle Vorteile von SCION und müssen sich nicht um die Netzwerkanbindung kümmern.

• Pfadkontrolle und Traffic Engineering: Entwickler können den Datenpfad durch das Netzwerk explizit kontrollieren, was neue Möglichkeiten für Optimierungen und Sicherheitsstrategien eröffnet.
• Integration mit DevOps-Tools: Die SCION Cloud ist vollständig API-gesteuert und lässt sich nahtlos in Tools wie Terraform oder Ansible integrieren.
• Sicherheit und Compliance: Höchste Sicherheitsstandards werden erfüllt, was insbesondere für Anwendungen in regulierten Branchen entscheidend ist.

Ein konkretes Beispiel ist die Integration von Kubernetes-Clustern in eine SCION-umspannte Umgebung. "Aus meiner Sicht können wir unseren Kunden die aktuell technisch beste Lösung auf dem Markt anbieten.", ist Schweizer überzeugt.

Kompatibel mit jeder Isolation Domain

Die SCION Cloud ist bereits jetzt mit jeder ISD kompatibel, nativ Multitenant-fähig, flexibel skalierbar und kann bedarfsgerecht angebunden werden. Die elegante Kombination mit den Connectivity-Services von Cyberlink ermöglicht es Nutzern, physisch wie virtuell auf Applikationen, die bei cloudscale.ch betrieben werden, via der passenden ISD zuzugreifen.

Finanzsektor: Secure Swiss Finance Network (SSFN)

Seit der Ankündigung, das Finance IPNet per September 2024 durch ein SCION-basiertes Netz abzulösen, war klar, wohin die Entwicklung im Finanzsektor gehen würde. In diesem jungen, aber aktuell etabliertesten Markt, zeichnet sich die SCION Cloud nicht zuletzt durch das Approval durch die SNB aus. Banken und Finanzdienstleister müssen sicherstellen, dass ihre Netzwerke höchste Standards erfüllen und gleichzeitig flexibel genug bleiben, um neuen Anforderungen gerecht zu werden. Die SCION Cloud bietet eine umfassende Lösung: Sie erlaubt die Kontrolle über den Datenpfad und ermöglicht es Nutzern, eine Any-to-Any-Architektur zu nutzen. Das bedeutet, dass sie nicht länger auf Punkt-zu-Punkt-Verbindungen wie MPLS angewiesen sind. Mit SCION können Finanzdienstleister Verbindungen aufbauen, die nicht nur sicher, sondern auch flexibel sind – sie können entscheiden, mit welchen Partnern sie sich verbinden und welche Pfade sie für die Datenübertragung nutzen möchten. Sobald die neue Technologie nicht nur dazu genutzt wird, alte Systeme zu ersetzen, sondern um Legacy-Meshes zu optimieren und überflüssige Leased Lines konsequent abzubauen, birgt diese Flexibilität ein enormes Potenzial zur Kostenersparnis und vereinfacht die Verwaltung der Netzwerkinfrastruktur erheblich. Besonders für FinTechs und Banken, die auf Cloud-Dienste zugreifen oder ihre eigenen Anwendungen in die Cloud bringen möchten, ist die SCION Cloud die optimale Wahl.

Gesundheitswesen: Secure Swiss Health Network (SSHN)

Speziell im Gesundheitswesen sehen Cyberlink und cloudscale.ch ebenfalls grosses Potenzial: Anbieter von Krankenkassensoftware und andere Akteure im Gesundheitssektor könnten in das SSHN integriert werden, um den gesamten Infrastruktur-Stack zu schützen. Die SCION Cloud ermöglicht es, Gesundheitsanwendungen sicher, vollständig konform und skalierbar zu hosten. Die so geschützte und zuverlässige Vernetzung von Arztpraxen, Apotheken und Spitälern steht dabei im Vordergrund. Ein zentrales Problem für das Secure Swiss Health Network (SSHN) war allerdings der Zugang der Nutzer zur SCION Cloud. Wie bringt man Gesundheitsdienstleister in einer nützlichen Frist auf dieses Netzwerk? Wie stattet man alle Praxen und Kliniken in der Schweiz mit der erforderlichen Hardware aus, die eine Anbindung an das SSHN ermöglicht? Als Kombination aus dem Besten, was cloudscale.ch und Cyberlink zu bieten haben, eröffnet die SCION Cloud hier zwei Optionen: Für grössere Einrichtungen wie Spitäler kommt die Managed SCION Edge von Cyberlink zum Einsatz, die lokal installiert wird und höchste Sicherheitsstandards gewährleistet. Für kleinere Praxen, die möglicherweise nicht die gleiche Infrastruktur benötigen, gibt es eine alternative Lösung mit dem "Anapaya Gate". Dieses Gate ermöglicht den Einstieg in die SCION-Welt über bestehende Heimnetzwerke. Während es ein niedrigeres Sicherheitsniveau bietet, bleibt es eine praktikable Option für weniger kritische Anwendungen. Dieses umfassende Connectivity-Portfolio bietet allen Teilnehmern des Ökosystems geschützten Zugang zu sensiblen Daten und einer Vielzahl an Applikationen im Gesundheitswesen.

Weitere Compliance-sensitive Branchen und ihre ISDs

Weitere Branchen werden mit dedizierten ISDs folgen. Und auch für die strengen regulatorischen Anforderungen dieser GRC-sensitiven Branchen, wie dem Energie- oder Paymentsektor sowie weiterer kritischer Bereiche, ist die SCION Cloud mit ihrer akkreditierten und konformen IT-Infrastruktur bereit. Die SCION Cloud stellt sicher, dass Compliance-Anforderungen zuverlässig erfüllt werden und bietet gleichzeitig die Skalierbarkeit, die Unternehmen benötigen, um am Markt zu wachsen.

SCION ist das Internet der Zukunft

Cyberlink und cloudscale.ch haben eine klare Vision: "SCION ist das Internet der Zukunft. Mit cloudscale.ch als Top-Schweizer Cloud-Provider und Cyberlink mit 30 Jahren Erfahrung in der Schweizer Connectivity haben wir die besten Voraussetzungen, um diese Zukunft mitzugestalten." Dieses Gespann konnte mit einer neuen Technologie vor einem der härtesten Auditoren der Schweiz bestehen und das termingerecht. Ohne den richtigen Partner wäre das niemals möglich gewesen. Eine Partnerschaft zweier Schweizer Top Anbieter, auf die man sich auch in anspruchsvollsten Krisen zu 100% verlassen kann.

2015: In den ersten Wochen nach der Gründung war es darum gegangen, die wichtigsten Werkzeuge für unsere Arbeit bereitzulegen. Dann begann die Entwicklung des eigentlichen Produkts: Auf Basis von OpenStack und Ceph (Open-Source war uns von Anfang an wichtig) bauten wir ein Cloud-Setup, in dem voll automatisiert und innert Sekunden virtuelle Server erstellt und gelöscht werden konnten. Das Control Panel dazu programmierten wir selbst, um die Benutzung wirklich so einfach und intuitiv zu halten, wie wir uns das vorgestellt hatten – die User unserer Beta-Phase waren begeistert.

2016: Der grosse Moment kam gleich Anfang Januar – wir feierten "General availability" aka Eröffnung. Endlich konnte jedermann in Self-service einen Account bei cloudscale anlegen und sofort unsere virtuellen Server nutzen. Dabei liessen wir es natürlich nicht bewenden; mit wachsender Belegschaft rüsteten wir die technische Basis unseres Control Panels für die kommende Weiterentwicklung und fügten unserer Cloud Features wie IPv6, private Netze und Bulk Storage hinzu.

2017: "Storage" und "Tooling" waren zwei der wichtigen Themen in 2017. In mehreren Schritten ergänzten wir unser Cloud-Angebot um einen S3-kompatiblen Object Storage, um einem wachsenden Bedürfnis nach skalierbarem Speicherplatz mit rein nutzungsbasierten Kosten gerecht zu werden. Die Umstellung auf NVMe-Disks sorgte zudem für mehr Performance unserer SSD-Volumes. Und Nutzer verbreiteter DevOps-Tools wie Ansible und Terraform konnten ihre Infrastruktur nun "as Code" verwalten und so ganze Serverlandschaften automatisch und reproduzierbar provisionieren.

2018: Mit "Meltdown" und "Spectre" wurde einer breiten Öffentlichkeit bewusst, dass Sicherheitslücken nicht nur in Software, sondern auch in Hardware stecken können. Weitere sogenannte CPU-Vulnerabilities sollten folgen, und bei cloudscale haben wir speziell darauf geachtet, jeweils schnell die nötigen Gegenmassnahmen zu treffen. Seit 2019 ist deshalb z.B. SMT bzw. "Hyper-Threading" auf all unseren Compute-Hosts deaktiviert, um darauf basierende Angriffe von vornherein zu stoppen. Ein echtes Highlight war 2018 natürlich unser Umzug an einen neuen, deutlich geräumigeren Bürostandort.

2019: Mit Highlights ging es auch 2019 weiter, und viele von ihnen lassen sich dem Bereich "Informationssicherheit" zuordnen: So haben wir unter anderem die Zertifizierung nach ISO/IEC 27001, 27017 und 27018 erreicht und mit der Eröffnung unseres zweiten Cloud-Standorts in Lupfig/AG die Grundlage für geo-redundante Setups geschaffen. Für ordentlich Power sorgte zudem die Einführung einer neuen Generation von Compute-Hosts auf AMD-Basis sowie die Lancierung unserer "Plus"-Flavors, mit denen pro virtuellem Server die Rechenleistung von bis zu 112 physischen CPU-Cores dediziert und permanent zur Verfügung steht.

2020: Wir waren zwar schon zuvor für mobiles Arbeiten ausgerüstet, die Pandemie-bedingte permanente Arbeit aus dem Homeoffice musste sich aber erst einpendeln. Heute sind wir sehr glücklich mit dem hybriden Modell, das wir entwickelt haben: montags treffen sich alle physisch im Büro, ansonsten entscheidet jeder für sich selber. "Off-/Nearshoring" ist für uns dennoch kein Thema: Bei cloudscale als rein schweizerischem Cloud-Anbieter kannst du dich darauf verlassen, dass sich die Infrastruktur nicht nur hier befindet, sondern auch von hier aus administriert wird. Passend dazu sind wir Partner des Labels "swiss hosting" – und dies schon seit es in 2020 lanciert wurde.

2021: Für alle, die ihre Cloud-Ressourcen gemeinschaftlich nutzen, war die umfassende Überarbeitung unseres Control Panels ein langersehnter Meilenstein: Organizations, Projekte, Teams und verschiedene Features zur Zusammenarbeit unterstützen die Arbeit in der Cloud – egal in welcher Form von "organisiert". Single Sign-On mit GitHub oder einem eigenen IDP macht das Login einfacher und sicherer. Die Collaboration-Features machten cloudscale auch für grössere Organisationen zum idealen Partner – und ebenso für alle, die in der Cloud Projekte für ihre eigenen Kunden betreuen.

2022: Noch zentraler geht fast nicht: Wir bezogen – inzwischen mit einem Team von mehr als zehn Leuten – unser heutiges Büro direkt beim Zürcher Hauptbahnhof. Auch bei unserem Cloud-Angebot tat sich einiges, z.B. mit der Erweiterung der Collaboration-Features, einer flexibleren Verwaltung von Custom Images oder mit vielen neuen Compute Flavors – so hast du auch für besonders CPU- oder RAM-lastige Workloads immer die passende Infrastruktur. Mit dem neuen, komplett linearen Preismodell ist der Preis für eine bestimmte Menge an CPU- und Memory-Ressourcen unabhängig davon, ob es sich um einen einzelnen grossen oder mehrere kleine virtuelle Server handelt. Und bei Bedarf steht seit 2022 jährlich ein ISAE-3000-Bericht zur Verfügung.

2023: Passend zu unserem Fokus auf Verfügbarkeit stellten wir unseren Kunden mit "Load-Balancer as a Service" ein weiteres Feature zum Aufbau resilienter Setups bereit. Die Abrechnung unserer Services erfolgt weiterhin auf die Sekunde genau, den Mechanismus dahinter vereinfachten wir jedoch grundlegend. Neu akzeptieren wir zudem Zahlungen mit der beliebten Schweizer Payment-Lösung TWINT. Und wir rüsteten uns für SCION: Die Netzwerk-Architektur der nächsten Generation verspricht mehr Zuverlässigkeit, Vertraulichkeit und Kontrolle bei der Kommunikation in kritischen Bereichen wie z.B. der Finanz- und Gesundheitsbranche.

2024: Mehr Übermittlungskapazität zwischen unseren Cloud-Standorten, mehr Flexibilität bei der Nutzung von Kubernetes-Setups dank CCM, mehr Überblick bei Kosten und privaten Netzen: Auch im laufenden Jahr verbessern und erweitern wir die Cloud-Services für unsere Kunden kontinuierlich. Besonders ins Auge springt natürlich unser neuer, frischer Auftritt. Nicht nur unsere Website wurde komplett überarbeitet und erweitert, sondern auch das Control Panel und die API-Dokumentation sanft auf das neue Design ausgerichtet. Zu den klaren Formen passt unser klarer Anspruch: bei cloudscale bist du in besten Händen.

Zu welchen weiteren Highlights die Reise uns führen wird? Lass es uns herausfinden – zusammen mit einem starken Team und natürlich mit unseren Kunden, die auch in Zukunft auf uns als nahen und nahbaren Partner zählen können. Apropos Team: Wenn du findest, du passt zu uns, dann gib uns Bescheid!

Mit dir unterwegs,
Dein cloudscale-Team

Bei cloudscale stehen dir mit OPNsense und pfSense CE zwei dedizierte Firewall-Distributionen zur Verfügung: Wähle eines dieser Images, um einen virtuellen Server als Firewall zwischen dem offenen Internet und einem privaten Netz einzurichten. Diese Firewall kannst du anschliessend bequem in einer webbasierten Verwaltungsoberfläche konfigurieren und deinen Anforderungen anpassen.

Damit die Firewall auch Traffic verarbeitet, der über eine Floating IP ankommt, muss die Floating IP in der Verwaltungsoberfläche erfasst werden. Du findest die Einstellung bei OPNsense unter "Interfaces -> Virtual IPs", bei pfSense CE unter "Firewall -> Virtual IPs". Erfasse hier die Floating IP und die Prefix-Länge (/32). In den meisten Fällen sollte "Type: IP Alias" und die Zuweisung zum "WAN"-Interface die passende Einstellung sein; mehr Details zu den einzelnen Optionen findest du in der Dokumentation zu OPNsense und pfSense CE. Übrigens: Standardmässig antworten OPNsense und pfSense CE nicht auf Pings; erfasse "ICMP Echo request" falls gewünscht in den Firewall-Rules, um dies zu ändern.

Willst du einen bestehenden Server hinter deine Firewall migrieren, der bereits einen Service unter einer Floating IP anbietet, kannst du – nachdem alles vorbereitet ist – einfach als letzten Schritt die Floating IP vom Server zur Firewall verschieben. Nutzt du bisher keine Floating IP, empfehlen wir, diese zuerst zum bestehenden Server hinzuzufügen und dann die DNS-Einträge anzupassen: So bleibt dein Service parallel unter der alten und neuen IP-Adresse verfügbar, während die neuen DNS-Einträge nach und nach aufgegriffen werden.

Tipps zur Umstellung bestehender Setups

Soll dein bestehender Server nach erfolgter Umstellung gar nicht mehr direkt aus dem Internet erreichbar sein, kannst du das "public" Interface vom Server entfernen. Hierzu benötigst du ein API-Token mit "Write access" sowie die UUID des Servers und des privaten Netzes, an das er angeschlossen sein soll. Den nötigen API-Call kannst du dann wie folgt via Kommandozeile absetzen:

curl -i -H "Authorization: Bearer 11112222333344445555666677778888" -H "Content-Type: application/json" -X PATCH --data '{"interfaces": [{"network": "11111111-2222-3333-4444-555555555555"}]}' https://api.cloudscale.ch/v1/servers/11111111-3333-5555-7777-999999999999

Beachte: Es ist auch möglich, später wieder ein public Interface zum Server hinzuzufügen; der Server wird in diesem Fall eine neue öffentliche IP-Adresse zugewiesen erhalten. Mehr Infos zu unserer API findest du in der API-Dokumentation.

Nach einer Änderung an den Interfaces empfiehlt sich, kurz die Namen der Interfaces zu prüfen. Falls diese nicht fest zugeordnet sind, könnten sie sich nach einem Reboot ändern (z.B. das private Netz von ens4 zu ens3) und zu Connectivity-Problemen führen. Die Linux-Distributionen setzen hier auf unterschiedliche Tools; Stichworte dazu sind z.B. "netplan" und "udev-Rules".

Wenn ein Server nicht mehr direkt aus dem Internet erreichbar ist, benötigst du zudem einen neuen Weg, um darauf zuzugreifen. Wähle die Lösung, die dir am besten zusagt, z.B. ein VPN oder ein Port-Forwarding – je nach deiner Firewall-Strategie. Ebenfalls möglich ist es, zuerst via SSH zur Firewall zu verbinden, und dann von deren Kommandozeile aus weiter zum jeweiligen Server.

Für alle Fälle empfehlen wir schliesslich, auf deinem Server ein root-Passwort zu setzen, mit dem du dich "lokal", jedoch nicht via SSH einloggen kannst. Bei Boot- oder Verbindungsproblemen kannst du dich dann in unserem Control Panel via VNC-Konsole auf dem Server anmelden und das Problem beheben. Alternativ (und etwas umständlicher) kannst du den Server zur Fehlerbehebung auch mit einem temporär angeschlossenen Live-Linux starten.

cloudscale bietet eine Reihe an Features rund um die Sicherheit und Verfügbarkeit deiner Setups. Nutze und kombiniere diese je nach deinen Anforderungen und Vorlieben. Auch bei bestehenden Setups bleibst du flexibel und kannst z.B. die direkte Internet-Anbindung deiner Server durch eine dedizierte Firewall mitsamt Floating IP ablösen.

Sicherheit nach deinem Geschmack!
Dein cloudscale-Team

Für neue Server steht bei cloudscale eine Reihe von beliebten Linux-Distributionen zur Auswahl. Noch individuellere Setups sind möglich dank sogenannten Custom Images: Als Kunde lädst du ein Festplatten-Abbild hoch, mit dem dann das root-Volume deiner neuen virtuellen Server initial befüllt werden kann – inklusive all den Tools und Settings, die du brauchst. An dieser Stelle gab es eine Sicherheitslücke in OpenStack – dem Open-Source-Projekt, auf welchem unser Cloud-Angebot basiert: Mit dem Hochladen von speziell präparierten Images im QCOW2-Format war es möglich, auf Dateien von Systemen zuzugreifen, die bei uns am Import-Prozess von Custom Images beteiligt sind.

Als Sofortmassnahme hatten wir den Import von QCOW2-Images vorübergehend deaktiviert. Konkret wurden alle Images als "Raw" behandelt; wo es sich tatsächlich um QCOW2 handelte, booteten virtuelle Server damit deshalb nicht. Uns war klar, dass dies für einige Kunden einen Zusatzaufwand bedeutet, da sie Images vor dem Import manuell ins Raw-Format konvertieren müssen. Im Interesse der Sicherheit für uns und unsere Kunden haben wir uns aber dennoch kurzfristig für diesen temporären Schritt entschieden.

Timeline:

• Dezember 2020: Einführung von Custom Images, Unterstützung für Raw-Format
• Mai 2022: Zusätzlich Unterstützung für Images im QCOW2-Format
• Februar 2023: Spezifizieren des Image-Formats beim Import nicht mehr nötig
• 02.07.2024: Veröffentlichung der Sicherheitslücke OSSA-2024-001 / CVE-2024-32498
• 03.07.2024: Import von Images im QCOW2-Format als Sofortmassnahme blockiert
• 31.07.2024: Import von Images im QCOW2-Format wieder möglich, Anpassung der API

Hintergrund zur Lücke

Image-Dateien im QCOW2-Format haben einige besondere Features, z.B. den tendenziell geringeren Platzbedarf. Zudem können sie nicht nur die eigentlichen Daten eines Datenträgers enthalten, sondern auch Verweise auf ausserhalb liegende Dateien. Kern der Sicherheitslücke in OpenStack war eine mangelhafte Prüfung in einigen OpenStack-Komponenten, die solche Verweise bzw. deren Zieldateien während der Verarbeitung von QCOW2-Images mit-verarbeitet haben. Da Custom Images im Fall von cloudscale immer im Raw-Format gespeichert werden, betraf die Lücke insbesondere das automatische Erkennen des zu importierenden Formats sowie die Konvertierung von QCOW2 zu Raw. Gemäss unserer Analyse gibt es jedoch keine Hinweise darauf, dass die Lücke bei cloudscale tatsächlich ausgenutzt worden wäre.

Die Konvertierung von Images, für die OpenStack auf qemu-img convert zurückgreift, wurde mittlerweile dahingehend gepatcht, dass auch mit speziell präparierten Images kein Ausnutzen mehr möglich ist. Somit können wir bei cloudscale das Importieren von QCOW2-Images wieder freigeben. Für die automatische Erkennung des Formats mit qemu-img info gibt es in der Entwickler-Community von OpenStack jedoch (noch) keine verlässliche Lösung. Deshalb werden auch wir bei cloudscale künftig nicht mehr versuchen, das Image-Format automatisch zu erkennen.

Nutzung von QCOW2-Images bei cloudscale

Das Importieren von QCOW2-Images ist bei cloudscale ab sofort wieder möglich, allerdings muss das Format beim Import mit angegeben werden. Beim Import via API wird hierzu das Attribut source_format verwendet: Nachdem dieses seit Februar 2023 als "deprecated" deklariert war, wird es aus gegebenem Anlass wieder offiziell genutzt. Bei Images im Raw-Format kann das Attribut weggelassen werden, für QCOW2-Images wird source_format hingegen zwingend benötigt. Wir sind uns bewusst, dass diese Änderung des API-Verhaltens nicht vollständig "non-breaking" ist; mit der gewählten Lösung versuchen wir jedoch, den Anpassungsaufwand so klein als möglich zu halten.

Die aktuellen Versionen unserer Module/Plug-ins unterstützen das Attribut source_format und können somit benutzt werden, um QCOW2-Images zu importieren. Antworten auf alle wichtigen Fragen dazu findest du in den untenstehenden FAQ.

Wir freuen uns, dass wir nach dem kurzfristig nötig gewordenen Ausschluss von QCOW2 den Import von Custom Images in diesem Format wieder freigeben können. Das Wiedereinführen eines alten Attributs im entsprechenden API-Call liess sich dabei leider nicht vermeiden. Uns war wichtig, keine bekannten Schwachstellen offen zu lassen, und gleichzeitig möglichst wenig Anpassungsaufwand zu verursachen. Wo trotz allem Anpassungen nötig werden, bitten wir um dein Verständnis.

Umsichtig und pragmatisch.
Dein cloudscale-Team

FAQ

Was passiert mit existierenden Custom Images?
Nichts. Die Änderung betrifft nur den Import-Vorgang. Existierende Images sind nicht betroffen.

Was ändert sich beim Import via webbasiertes Control-Panel (control.cloudscale.ch)?
Du musst neu im Drop-Down "Source Format" das Format des Images spezifizieren.

Mein Import zeigt die Error-Message "Import could not be processed", was muss ich tun?
Wahrscheinlich hast du versucht, eine Datei als "QCOW2" zu importieren, welche aber keine solche ist. Überprüfe das Format und die URL.

Ich importiere ausschliesslich Raw-Images. Bin ich betroffen?
Nein. Stelle jedoch sicher, dass das source_format Feld entweder nicht übergeben wird oder "raw" enthält. Bei anderen Werten tritt ein Fehler auf.

Ich verwende Terraform, was muss ich tun?
Um QCOW2-Images importieren zu können, musst du den Provider "cloudscale" ab Version v4.4.0 verwenden und das import_source_format für neue Images spezifizieren. Bestehende Images können unverändert weiter verwendet werden; das Format sollte nicht nachträglich spezifiziert werden.

Ich verwende cloudscale_ch.cloud für Ansible, was muss ich tun?
Stelle sicher, dass das korrekte source_format übergeben wird. Du musst die Ansible Collection nicht aktualisieren.

Ich verwende cloudscale-go-sdk in meiner Go Applikation, was muss ich tun?
Wenn du damit Custom Images importierst, musst du sicherstellen, dass das korrekte source_format übergeben wird. Die Dependency muss nicht aktualisiert werden.

Ich verwende cloudscale-python-sdk in meiner Python Applikation, was muss ich tun?
Wenn du damit Custom Images importierst, musst du sicherstellen, dass das korrekte source_format übergeben wird. Die Dependency muss nicht aktualisiert werden.

Im Open-Source-Umfeld sind Plain-Text-Dateien, z.B. im YAML- oder JSON-Format, eine häufig gewählte Form für (Software-)Konfigurationen und andere Daten, die von einem automatisierten Prozess ausgewertet werden. Auch unsere Ansible-Setups, mit denen wir einen Grossteil unserer Installations- und Wartungsprozesse automatisiert haben, bezogen ihre Daten über unser Inventar lange Zeit aus einer Vielzahl solcher YAML-Files.

Mit der kürzlichen Umstellung auf NetBox werden nun Zusammenhänge, die sich mehr oder weniger offensichtlich in diesen YAML-Configs fanden, explizit in der NetBox Datenbank abgebildet, was nicht zuletzt einen zusätzlichen Schutz vor Fehlern bietet. Über die webbasierte Oberfläche von NetBox kann man durch das Inventar navigieren und sich z.B. die Belegung von Server-Racks anzeigen lassen oder nachschauen, welche Geräte sich ein Chassis teilen.

Umfangreich und flexibel

NetBox unterstützt eine Vielzahl von Angaben zu jedem Gerät. Neben Standort, Position im Rack, Gerätetyp und Netzwerk-Details kann beispielsweise auch erfasst werden, ob die Kühlluft von der Gerätefront zur -rückseite fliesst oder umgekehrt. Zu den relevantesten erfassten Angaben gehört bei cloudscale insbesondere die Rolle, die ein Gerät erfüllt – also ob es sich z.B. um einen Storage-Server, einen Switch oder ein Monitoring-System handelt.

Unsere in Ansible automatisierten Tasks holen dann die Hosts, auf die sie angewendet werden sollen, via API aus NetBox; ebenso Host-spezifische Configs wie z.B. MAC-Adressen. Die dazu nötige Schnittstelle stellt das in der NetBox Ansible Collection enthaltene Inventory Plugin bereit. Um die Performance auch bei komplexeren Playbooks zu verbessern, nutzen wir Caching: Die benötigten Daten werden zu Beginn des Playbook-Runs einmalig geholt, für den ganzen Run behalten und anschliessend verworfen, so dass ein nächster Run wieder mit den aktuellsten Daten starten wird.

In unseren fein gegliederten Ansible-Setups sind (physische und virtuelle) Hosts häufig mehr als nur einer Ansible-Gruppe zugewiesen, allerdings ist NetBox auf maximal eine Rolle pro Gerät limitiert. Um die bestehende Struktur in NetBox abbilden zu können, haben wir uns deshalb entschieden, nur die jeweils primäre Kind-Gruppe (unterste Gruppe im Vererbungs-Baum) dem Gerät als Rolle zuzuweisen. Eventuelle weitere Kind-Gruppen vergeben wir in NetBox mittels "Tags". Diese speziellen Tags wandeln wir dann in einem intern entwickelten Ansible Plugin zu Gruppen um und fügen diese zur Playbook-Laufzeit als Variable dem entsprechenden Host hinzu.

Mehr als Netzwerk

Offiziell richtet sich NetBox an Network Engineers. Der Anspruch, "a cohesive, extensive, and accessible data model for all things networked" zu bieten, macht aber deutlich, dass der Anwendungsbereich viel breiter ist. So können auch unsere Kunden ihre virtuellen Server in NetBox abbilden, zusammen mit deren Eigenschaften wie dem jeweiligen Cloud-Standort, IP-Adressen, privaten Netzen etc. Im Zusammenspiel mit unserer Ansible Collection ist es sogar möglich, bestehende Cloud-Setups in NetBox zu importieren.

Als Source of Truth kann NetBox schliesslich auch die Führung übernehmen: Neue virtuelle Server werden dann zuerst in NetBox erfasst und basierend auf diesen Daten dann von Ansible automatisiert erstellt und konfiguriert.

Mit NetBox steht ein mächtiges Tool zur Verfügung, um die Tasks rund um das Inventar weiter zu automatisieren. Zudem können wir dank Open-Source auch eigene Verbesserungen an die Community zurückgeben. Mit NetBox als Source of Truth stützen sich alle Beteiligten auf korrekte Infos zum Inventar – via Ansible Playbooks genauso wie im webbasierten GUI.

Eine verlässliche Basis.
Dein cloudscale-Team

Private Netze für jeden Bedarf

Der erste Schritt zur Nutzung eines privaten Netzes ist bei cloudscale bewusst einfach gehalten: Direkt beim Launch können virtuelle Server mit wenigen Klicks an ein bestehendes oder neues privates Netz angeschlossen werden. Die Verbindung zum privaten Netz kann entweder zusätzlich zum direkten Anschluss an das Internet erfolgen oder diesen ersetzen. Das private Netz steht dir ab Layer 2 exklusiv zur Verfügung, so dass du z.B. die IP-Adressen auf den beteiligten Servern frei konfigurieren kannst. Für mehr Effizienz sind im privaten Netz "Jumbo-Frames" möglich, die Default-MTU von 9000 Bytes kannst du bei Bedarf aber natürlich anpassen.

Standardmässig steht in einem privaten Netz ein DHCP-Service zur Verfügung, der anfragenden Servern IP-Adressen aus einem zufällig gewählten /24 innerhalb von 172.16.0.0/12 zuweist. Daneben stehen viele weitere Konfigurationsmöglichkeiten zur Verfügung. So kannst du z.B. private Netze ohne DHCP-Service erstellen bzw. für den DHCP-Service einen beliebigen anderen IP-Range (mindestens ein /24) vorsehen. Auch für einzelne Server lässt sich die DHCP-Funktionalität deaktivieren oder die IP-Adresse im privaten Netz fix vergeben, statt dass sie der DHCP-Service zufällig auswählt. Zusammen mit der IP-Adresse kann den Servern via DHCP ausserdem ein Gateway und/oder eine Liste von DNS-Resolvern mitgegeben werden, womit sich eine lokale Konfiguration dieser Angaben erübrigt.

Immer klare Verhältnisse

Damit auch bei mehreren privaten Netzen der Überblick nicht verloren geht, gibt es in unserem Cloud Control Panel den Bereich "Networks". Diesen haben wir in den letzten Monaten schrittweise erweitert, so dass alle relevanten Details zu deinen privaten Netzen übersichtlich zusammengefasst sind und zum Teil direkt angepasst werden können.

Unter "Settings" finden sich nebst der frei wählbaren Netz-Bezeichnung diejenigen Angaben, die sich direkt auf das Layer-2-Netzwerk beziehen, insbesondere die MTU. Diese Einstellung bestimmt einerseits die tatsächlich mögliche Paketgrösse im privaten Netz, und sie wird – bei aktiviertem DHCP-Service – andererseits auch in der DHCP-Antwort an die Server mitgeteilt.

Im Tab "Subnets" sind die Angaben zusammengefasst, die im Zusammenhang mit dem DHCP-Service stehen. Dazu gehört der für das Netz gewählte IP-Adressbereich in CIDR-Notation sowie der Range, aus welchem der DHCP-Service die Adressen wählt, soweit du keine spezifischen Adressen angibst. Die Werte für "Gateway" und "DNS Servers" beeinflussen das Verhalten des DHCP-Service nicht direkt, sondern dienen als Teil der DHCP-Antwort zum Konfigurieren deiner Server.

Unter "Ports" schliesslich siehst du sämtliche Geräte, die an deinem privaten Netz teilnehmen, inklusive ihrer MAC-Adresse sowie der IP-Adresse, die der DHCP-Service allenfalls für das Gerät reserviert hat. Daneben bist du natürlich frei, auf deinen virtuellen Servern auch andere IPv4- oder IPv6-Adressen zu nutzen. Zusätzlich zu deinen virtuellen Servern werden auch die zwei DHCP-Server aufgeführt, die dein Subnet verwalten.

Ebenfalls in der Liste sind allfällige Load-Balancer: Aufgrund des Designs für Hochverfügbarkeit besteht ein Load-Balancer aus zwei einzelnen Servern und taucht in deinem privaten Netz deshalb mit zwei Ports auf. Die hier sichtbaren IP-Adressen sind übrigens die gleichen, die auf deinem Backend auch in den Logs erscheinen – es sei denn, du benutzt in dem betreffenden Load-Balancer-Pool das proxy(v2)-Protokoll, das die eigentliche Source-IP des Clients zusammen mit den reinen TCP-Paketen an dein Backend übergibt. Befindet sich zudem auch die "VIP Address" des Load-Balancers in dem privaten Netz, wird auch sie bei den Ports aufgelistet.

Aus Sicherheitsüberlegungen macht es oft Sinn, wenn nur diejenigen Systeme miteinander verbunden sind, die tatsächlich miteinander kommunizieren sollen. Und auch wenn dein Setup sich über die Zeit weiterentwickelt: In unserem Cloud Control Panel siehst du unter "Networks" jederzeit, welche Netze es gibt und welche Geräte wo teilnehmen. So reduzierst du das Risiko von Fehlern und vereinfachst dir das Leben mit den zentral verwalteten DHCP-Optionen zusätzlich.

Netzwerk "made easy".
Dein cloudscale-Team

Volle Kontrolle über die Kosten

Möchtest du die Kosten für bestimmte Cloud-Projekte an deine Kunden weiterverrechnen, sie für die Buchhaltung zusammenstellen oder einfach den Überblick behalten? Nutze den neuen "Billing Report" in unserem Cloud Control Panel und lass dir die Kosten für den gewünschten Zeitraum zusammenstellen. Du kannst das Start- und Enddatum tagesgenau wählen.

Dabei werden in einer ersten Übersicht die Gesamtkosten pro Projekt dargestellt. Auf einer separaten Seite pro Projekt siehst du dann das Total für die einzelnen Ressourcen-Typen (z.B. alle Server, alle Volumes etc.) sowie die genauen Kosten der konkreten Cloud-Ressourcen (also einzelne virtuelle Server, Volumes etc.). Auch Projekte und Ressourcen, die inzwischen nicht mehr existieren, werden dabei ausgewiesen.

Auf die Sekunde genau

Die aufgelisteten Cloud-Ressourcen können "aufgeklappt" werden: Gab es innerhalb des gewählten Zeitraums eine Veränderung, siehst du die einzelnen, sekundengenauen Zeitabschnitte und die jeweiligen Kosten. Häufigster Grund für eine Änderung ist das Skalieren von Servern und Volumes, abgebildet werden aber auch die Preisanpassungen vorletztes und dieses Jahr. Einen "Schnitt" gibt es technisch bedingt zudem, wenn ein Projekt von einem persönlichen Account in eine Organization verschoben wurde. Blau-grün dargestellte Zeitangaben stehen für Beginn bzw. Ende des angezeigten Zeitraums und bedeuten keine Änderung bzgl. Service oder Preis.

Alle Zeitangaben im Billing Report beziehen sich auf die Zeitzone Europe/Zurich, unabhängig von deiner Einstellung unter "Settings". Dies ist bedingt durch die Abrechnung pro Kalendertag, auf die wir im letzten August umgestellt hatten: Dabei werden die Kosten über den Tag hinweg gesammelt und kurz nach Mitternacht (gemäss Zeitzone von Zürich) gesamthaft vom Guthaben des Accounts oder der Organization abgebucht. Natürlich kannst du im Billing Report auch länger zurückliegende Zeiträume wählen; für virtuelle Server kann jedoch der damals aktive Compute Flavor nicht in allen Fällen angezeigt werden.

Zwei Bemerkungen

Im Billing Report werden alle Projekte und Cloud Ressourcen mit dem Namen angezeigt, den sie aktuell haben bzw. zuletzt hatten, falls sie zwischenzeitlich gelöscht wurden. Überprüfe im Zweifel anhand der ebenfalls dargestellten UUID, um welche Ressourcen es sich im Einzelnen handelt.

Bei den "BGP Announcements" ganz unten im Billing Report handelt es sich übrigens um ein wenig bekanntes Profi-Feature: Wenn du bereits eigenen IP-Space hast, dafür jedoch keine eigene Infrastruktur betreiben möchtest, kannst du den Space als "Floating Networks" bei cloudscale konfigurieren lassen und virtuelle Server so unter deinen eigenen IPs erreichbar machen. Unser Support berät dich bei Bedarf gerne.

Egal, wie klein oder gross dein Cloud-Projekt ist: bei cloudscale soll nicht nur die technische Verwaltung einfach sein, sondern auch das Pricing. Mit dem neuen Billing Report kannst du nun auch im Nachhinein die Entwicklung und Kosten deines Projekts im Detail nachvollziehen – genau für den benötigten Zeitraum und auf der "Flughöhe" deiner Wahl.

Mit uns kannst du rechnen.
Dein cloudscale-Team

Mit unserem CCM weiss dein K8s-Cluster jetzt noch besser über die beteiligten Nodes Bescheid. Ganz automatisch werden Metadaten zu den Nodes von unserer Cloud-API geholt, z.B. die IP-Adresse(n) des jeweiligen virtuellen Servers oder seine geographische Region/Zone. Auch lässt sich unterscheiden, ob ein Node gelöscht oder bloss ausgeschaltet worden ist. Ebenfalls verfügbar ist der Compute-Flavor; dies ermöglicht es etwa, gewisse Workloads gezielt auf Nodes zu platzieren, die einen "Plus"-Flavor verwenden und damit permanent die gewählte Anzahl CPU-Cores exklusiv zur Verfügung haben.

Unser CCM ist auf GitHub verfügbar und unterstützt die drei jeweils aktuellsten Minor-Releases von Kubernetes. Ebenfalls auf GitHub zu finden ist die entsprechende Dokumentation mit Beispielen sowie ein Helper, um den CCM in einem Test-Cluster auszuprobieren.

K8s-Services mit unserem LBaaS-Feature

Nebst detaillierteren Informationen zur unterliegenden Infrastruktur ermöglicht der CCM auch die automatisierte Verwaltung unseres LBaaS-Features. Wähle hierzu den type: LoadBalancer für einen Service in Kubernetes. Der Load Balancer kann deinen Service wahlweise aus dem Internet erreichbar machen oder nur in einem deiner privaten Netze.

Eingehende Requests verteilt der Load Balancer im privaten Netz auf die Nodes des K8s-Clusters, die dazu kein eigenes "public" Interface benötigen. Dabei können die zulässigen Clients bereits auf Ebene des Load Balancers auf die gewünschten IPs bzw. IP-Ranges eingeschränkt werden. Um im Backend trotz NAT die IP-Adressen der Clients erkennen oder loggen zu können, nutze das "proxy" bzw. "proxyv2" Protokoll, das u.a. von nginx unterstützt wird.

Unser Load-Balancer-Service soll den Betrieb hochverfügbarer Services unterstützen und vereinfachen. Beachte jedoch, dass das Anwenden von Konfigurationsänderungen via CCM eine gewisse Downtime bedingen kann – ungefähre Angaben zu den verschiedenen unterstützten Fällen findest du ebenfalls in der Dokumentation.

Dank unserem CCM lassen sich Tasks automatisieren, weil dein K8s-Cluster auf zusätzliche Angaben über die Infrastruktur und auf unseren Load-Balancer-Service zurückgreifen kann. So erhöhst du nicht nur die Effizienz deines Setups, sondern auch die Verfügbarkeit für deine User.

Alles unter Kontrolle.
Dein cloudscale-Team

Blau und grün. Ein einprägsamer Schriftzug statt weit hergeholte Grafiken. So kannte man uns bisher – und so soll es bleiben. Der Unterschied ist trotzdem frappant: die neuen Farbtöne wirken deutlich frischer, und die Schrift mit ihrer klaren Formensprache passt zu unserer Identität.

Ein besonderer Eyecatcher ist das "o": Es wurde vom Tacho-Logo zu einem Farbverlauf vereinfacht und drückt damit nicht bloss "Performance" aus, sondern steht genauso für Einfachheit, Skalierbarkeit und Dynamik. Mit seinem hohen Wiedererkennungswert bildet es ein Designelement, das auch an anderen Stellen vielseitig wieder aufgegriffen werden kann. (Für diejenigen, die gern genau hinsehen: die Berührung zwischen Blau und Grün nimmt den Winkel des Buchstabens "c" wieder auf.)

Aus einem Guss

Die komplett neu gestaltete Website lehnt sich an Farben und Formen des Schriftzugs an und sorgt so für einen unverwechselbaren Auftritt. cloudscale soll sich immer gleich anfühlen, beim ersten Eindruck genau wie bei der laufenden Zusammenarbeit.

Das gleiche gilt natürlich auch für die tägliche Nutzung und das Engineering anspruchsvoller Setups. Da ist es nur folgerichtig, dass wir auch unser Cloud Control Panel und die API-Dokumentation an das neue Design angepasst haben. Die Übersichtlichkeit haben wir selbstverständlich beibehalten; im Detail haben wir nebst dem neuen Design aber auch die Usability weiter optimiert.

Nahbar wie immer

Transparenz ist uns seit jeher wichtig. Mit unserer neu gestalteten Website sollen die relevanten Informationen noch zugänglicher sein – und natürlich werden wir dich auch weiterhin regelmässig mit Neuigkeiten zu uns und unserem Angebot auf dem Laufenden halten. Gleich bleiben auch die Kontaktmöglichkeiten: sollten noch irgendwelche Fragen offen geblieben sein, helfen wir gerne persönlich weiter. Und weil die Cloud bei uns so unkompliziert ist, schreiben wir im Alltag künftig nur noch "cloudscale" – ohne das ".ch".

cloudscale steht für Professionalität. Mit unserem neuen, durchgängigen Look tragen wir diesen Anspruch nun noch besser nach aussen. Damit schon auf den ersten Blick klar wird, dass dein Projekt bei cloudscale nicht einfach nur in der Cloud ist. Sondern: In besten Händen.

Jetzt noch mehr wir selbst:
Dein cloudscale-Team

Vor gut vier Jahren haben wir unseren zweiten Cloud-Standort in Lupfig (Kanton Aargau) in Betrieb genommen, um unseren Kunden geo-redundante Setups zu ermöglichen. Damit virtuelle Server zwischen den beiden Standorten direkt miteinander kommunizieren können und der Datenverkehr dabei unser eigenes Netzwerk nicht verlässt, haben wir die Standorte mittels Dark Fiber verbunden. Dies bedeutet, dass wir nicht einfach Übertragungskapazitäten von einem Drittanbieter einkaufen, sondern die nackten, "dunklen" Glasfasern mieten und an den Endpunkten mit unseren eigenen Transceivern selber "beleuchten".

Für eine höhere Gesamtkapazität nutzen wir dabei Coarse Wavelength Division Multiplexing (CWDM): über ein und dieselbe Glasfaser wird Laserlicht mit verschiedenen Wellenlängen (umgangssprachlich auch "Farben" genannt) übermittelt. Auf einem dieser Kanäle haben wir die Core-Router unserer beiden Standorte mit 10 Gbps miteinander verbunden; zwei weitere – gebündelt zu 20 Gbps – verbanden die Standorte bisher auf Ebene der Switching Fabrics.

Für maximale Verfügbarkeit haben wir die physische Verbindung doppelt ausgelegt. Separate Dark Fibers verbinden die Standorte in Rümlang und Lupfig auf unterschiedlichen, kreuzungsfreien Strecken. So bleibt die Verbindung verfügbar, selbst wenn – z.B. bei Strassenbauarbeiten – eine der Fasern verletzt werden sollte. Auch innerhalb der Rechenzentren achteten wir auf die Details: die Leitungen erreichen die Gebäude über separate Hauseinführungen, kreuzen sich auch danach nicht und enden in unterschiedlichen Racks. Dank dieser Redundanz verdoppelte sich die im Normalfall verfügbare Kapazität zudem auf 2x 10 Gbps zwischen den Core-Routern bzw. 4x 10 Gbps zwischen den Switching Fabrics.

Upgrade auf 2x 100 Gbps

Vor Kurzem haben wir die Verbindung zwischen den Switching Fabrics nochmals deutlich ausgebaut: statt 2x 10 Gbps stehen auf den beiden separaten Strecken neu jeweils 100 Gbps zur Verfügung. Mit der Angleichung der Datenrate an diejenige, die auch Standort-intern genutzt wird, ist zudem weniger Buffering nötig, was die Latenz bei der Datenübermittlung weiter reduziert.

Die Verbindungen zwischen den Standorten auf Ebene der Switching Fabrics werden unter anderem für den Datenverkehr zwischen Ihren virtuellen Servern genutzt. Das bedeutet, dass Sie bereits automatisch von diesem Upgrade profitieren, wenn Sie z.B. periodisch eine Archiv-Kopie Ihrer Daten "off-site" speichern.

Ausblick

Das Upgrade der Verbindungen auf insgesamt 2x 100 Gbps kommt allgemein all jenen Anwendungen zugute, bei denen relativ grosse Datenmengen zwischen unseren Cloud-Standorten ausgetauscht werden. Nebst mehr "Luft" für bestehende Setups legt die erweiterte Kapazität natürlich auch die Basis für künftige Features wie z.B. das Off-Site-Backup von Daten unserer Kunden.

Bei cloudscale.ch nutzen wir Redundanz auf allen Ebenen, um Ausfälle wenn immer möglich zu vermeiden. Dennoch empfehlen wir unseren Kunden, das volle Potenzial unserer beiden Standorte zu nutzen und ihre Setups geo-redundant aufzubauen. Die kürzlich massiv erweiterte, direkte Verbindung zwischen unseren Standorten bildet dabei auch die Grundlage für eine schnelle und zuverlässige Replikation Ihrer Datenbestände.

Einer geläufigen Definition zufolge basiert "Cloud" auf den drei Säulen Compute, Storage und Network. Obwohl oft der unscheinbarste Teil von den dreien, ist das Netzwerk entscheidend – nicht nur im regulären Betrieb, sondern ganz besonders im Hinblick auf Geo-Redundanz. Mit unserem Upgrade auf 2x 100 Gbps zwischen den Cloud-Regions Rümlang und Lupfig bauen Sie hier auf einer soliden Basis – heute und auch morgen.

Schaut voraus,
Ihr cloudscale.ch Team

Das Internet ist heute allgegenwärtig und aus kaum einem Bereich mehr wegzudenken. Wie zentral diese Infrastruktur für unser Leben geworden ist, wird besonders bei Cyber-Attacken und grösseren Ausfällen deutlich. Ein Teil dieser Probleme wird begünstigt durch die grundlegende Architektur des Internets, die es aus den frühen Tagen seiner rund 50-jährigen Geschichte geerbt hat.

Einige Bereiche haben höhere Ansprüche an die Zuverlässigkeit und Sicherheit ihrer zentralen Kommunikations-Infrastruktur, insbesondere z.B. die Finanz- und Gesundheitsbranche. Für sie wurde an der ETH Zürich SCION entwickelt: Das Routing-Protokoll trägt mit "Scalability, Control, and Isolation On Next-generation networks" schon im Namen, wie es sich vom herkömmlichen Internet abhebt.

Kontrolle und Isolation mit SCION

Das Internet – ein "Zusammenschluss" vieler einzelner Netzwerke – ist tatsächlich ein Netz: zwischen zwei Kommunikationspartnern A und B gibt es unzählige mögliche Pfade für den Datentransport. Welchen Weg die Daten tatsächlich nehmen, ergibt sich aus einer Vielzahl von Einflussfaktoren und Entscheidungen der beteiligten Provider; A und B können darauf nur wenig Einfluss nehmen.

Ganz anders bei SCION: Auf Basis verschiedener Parameter wie z.B. Latenz, Jitter, Packet Loss oder verfügbarer Bandbreite können Netzteilnehmer Pfade bevorzugen bzw. ausschliessen. Dank laufend aktualisierter Metriken kann so ein optimales Routing sichergestellt werden. Die vollständige Pfadkontrolle erlaubt zudem den Ausschluss bestimmter Pfadsegmente oder spezifischer Provider.

Beim Ausfall eines Netzknotens findet der Datenverkehr im Internet automatisch einen neuen Weg. Diese Anpassung benötigt jedoch Zeit – in Ausnahmefällen kann es mehrere Minuten dauern, bis die betroffenen Daten wieder fliessen. SCION setzt konsequent auf moderne Konzepte, um solche Unterbrüche praktisch zu vermeiden. Fällt die aktuell bevorzugte Route aus, wird umgehend auf eine andere, den festgelegten Vorgaben entsprechende Route ausgewichen.

Die Authentifizierung der Netzwerkteilnehmer ist ein weiteres, wichtiges Feature von SCION. In voneinander getrennten "Isolation Domains" (ISDs) können sich die Teilnehmer darauf verlassen, dass sie nur Datenverkehr von legitimen, überprüften Quellen erhalten.

SCION bei cloudscale.ch

Dank dem Fokus auf Zuverlässigkeit und Vertraulichkeit eignet sich SCION ideal für die Finanzbranche. So löst etwa SIX derzeit ihr "Finance IPNet" durch das SCION-basierte "Secure Swiss Finance Network" (SSFN) ab. Daneben ist SCION auch im Gesundheits- und Energiesektor bereits im Einsatz.

Bei cloudscale.ch sind wir aktuell daran, zwei SCION Core Router in Betrieb zu nehmen. So können unsere Kunden künftig direkt mit ihren Cloud-Setups an diesen sicheren Netzen teilnehmen. Falls Sie sich für einen SCION-Zugang interessieren, nehmen Sie bitte mit uns Kontakt auf, um die weiteren Schritte zu besprechen.

SCION wurde für Anwendungen entwickelt, deren Anforderungen durch das heutige Internet nur noch bedingt erfüllt werden. Durch die vollständige Pfadkontrolle und die zur Verfügung stehenden Metriken gewinnen die Netzteilnehmer die Hoheit über den Datenfluss zurück. Zudem profitieren sie von minimalen Ausfallzeiten und der Authentifizierung sämtlicher Kommunikationspartner. Deshalb ermöglichen auch wir unseren Kunden demnächst die Teilnahme an verschiedenen SCION-basierten Netzwerken bzw. ISDs.

Bestens verbunden,
Ihr cloudscale.ch-Team

Anpassung nur bei Compute Flavors

Selbst wenn eine Preiserhöhung unumgänglich ist, möchten wir sie auf das Nötige beschränken und am Prinzip von Einfachheit und Transparenz – auch in Bezug auf die Preisgestaltung – festhalten. Konkret erhöhen sich daher die Preise unserer Compute Flavors um einheitlich 10%; ein virtueller Server mit Flavor "Flex-8-2" beispielsweise wird statt CHF 2.00 neu CHF 2.20 pro 24 Stunden kosten.

Die rein lineare Preisstruktur bleibt dabei erhalten. Damit hängen die Kosten für Memory und CPU-Ressourcen einzig vom Gesamtbedarf ab und nicht davon, ob Sie Ihre Workloads auf einem grossen Server kombinieren oder lieber auf mehrere kleinere Server verteilen. Auch die übrigen Preise, z.B. für Volumes, Object Storage und Load Balancer bleiben unverändert, und es werden keine neuen Preiskomponenten eingeführt.

Die Hintergründe

Dank günstiger Einkaufskonditionen konnten wir unsere Preise im Juli 2022 um bis zu 33% senken. In der Zwischenzeit hat sich das Umfeld jedoch verändert, insbesondere die Energiepreise sind – nicht nur in der Schweiz – massiv gestiegen. Diese wirken sich auf den Betrieb einer Cloud-Infrastruktur gleich doppelt aus: einerseits verbraucht der Betrieb von physischen Servern direkt Strom, andererseits ist Strom auch ein wesentlicher Faktor bei der nötigen Kühlung. Deutlich verteuert hat sich daneben aber auch der Einkauf von Hardware.

Die neuen Preise gelten ab dem 01.01.2024 um 0:00 Uhr (Schweizer Zeit) für den Betrieb von bestehenden sowie neu erstellten virtuellen Servern und werden kurz nach Mitternacht auch in unserem Cloud Control Panel sichtbar sein. Entsprechend erfolgt die erste Belastung des Konto-Guthabens zu den neuen Konditionen in der Nacht auf den 02.01.2024 für die am 01.01.2024 bezogenen Services.

Bei cloudscale.ch bezahlen Sie nur, was Sie tatsächlich brauchen, selbstverständlich auch weiterhin auf die Sekunde genau. Auch mit der aktuellen Preiserhöhung bei Compute Flavors sind wir deshalb überzeugt, dass sich diese Flexibilität lohnt – in einem Umfeld allgemein steigender Preise erst recht.

Gewohnt transparent,
Ihr cloudscale.ch-Team

Terraform erlaubt es, die benötigte Cloud-Infrastruktur in Form von Konfigurationsdateien zu definieren. Auf Basis dieser Konfiguration erstellt Terraform anschliessend via API die tatsächlichen Cloud-Ressourcen. Im täglichen Betrieb kann Terraform dann den Zustand gemäss Konfiguration wieder herstellen, wenn sich in der Praxis Abweichungen ergeben haben, und Änderungen an der Konfiguration auf das reale Setup applizieren. Oft werden Terraform-Configs zudem in einem Versionsverwaltungssystem wie Git verwaltet und als Teil einer CI/CD Pipeline angewendet.

Projekte: Ordnung, Sicherheit und Transparenz

Bei cloudscale.ch werden Cloud-Ressourcen wie Server und Volumes in Projekten erstellt. Projekte ermöglichen die Gruppierung von Ressourcen, z.B. pro Endkunde oder zur Trennung von Dev- und Prod-Umgebungen. Wenn mehrere Beteiligte gemeinsam mit Cloud-Ressourcen arbeiten, können zudem die Berechtigungen von Personen und Teams für jedes Projekt einzeln festgelegt werden. Schliesslich werden auch die Kosten für jedes Projekt separat ausgewiesen und lassen sich anschliessend weiter nach den Ressourcen aufschlüsseln.

Auch API-Tokens für die cloudscale.ch API sind an ein Projekt gebunden und erlauben nur Zugriff auf Ressourcen innerhalb dieses Projekts. Als Praxisbeispiel könnte es daher gewünscht sein, etwa einen Backupserver in einem eigenen, separaten Projekt zu erstellen. Ein im Alltag häufig benutztes API-Token im primären Projekt (z.B. zum Verschieben einer Floating IP zwischen Servern) kann dann nicht benutzt werden, um Änderungen am Backupserver vorzunehmen.

Zentrale Verwaltung in Terraform

Möchte man nun alle Ressourcen zusammen in einem Zug mit Terraform erstellen, steht man vor der Frage, wie man den cloudscale-ch Provider mit mehreren API-Tokens verwenden kann. Die Lösung besteht darin, zwei provider Blöcke zu erstellen, also den Provider zweimal zu instanziieren und einer Instanz einen alias hinzuzufügen. Jeder Instanz kann man dann ihr eigenes API-Token zuweisen.

Das sieht dann etwa so aus:

terraform {
  required_providers {
    cloudscale = {
      source = "cloudscale-ch/cloudscale"
    }
  }
}

# Define variables for the API tokens
variable "cloudscale_api_token" {}
variable "cloudscale_backup_api_token" {}

# Define the provider for the default project
provider "cloudscale" {
  token = var.cloudscale_api_token
}

# Define the provider for the second project with an alias
provider "cloudscale" {
  alias = "backup"
  token = var.cloudscale_backup_api_token
}

Die Ressourcen im ersten Projekt kann man wie gewohnt deklarieren:

# Create servers using the default provider
# in the first project
resource "cloudscale_server" "demo-server" {
  name               = "demo-server-${count.index + 1}"
  flavor_slug        = "plus-8-4"
  image_slug         = "ubuntu-22.04"
  ssh_keys           = [file("~/.ssh/id_ed25519.pub")]
  zone_slug          = "lpg1"
  count              = 3
}

Die Ressourcen, welche ins zweite Projekt gehören, werden zusätzlich um das provider Keyword erweitert.

# Create a backup server using the aliased provider
# in the second project
resource "cloudscale_server" "backup-server" {
  # Use the aliased provider
  provider           = cloudscale.backup

  name               = "backup-server"
  flavor_slug        = "flex-4-2"
  image_slug         = "ubuntu-22.04"
  ssh_keys           = [file("~/.ssh/id_ed25519.pub")]
  zone_slug          = "rma1"
}

Nun lassen sich alle Ressourcen in beiden Projekten auf einmal erstellen:

terraform apply -var="cloudscale_api_token=$TOKEN1" \
                -var="cloudscale_backup_api_token=$TOKEN2"

Übrigens: als Feature von Terraform können Sie das alias Keyword nicht nur bei cloudscale.ch nutzen, um mehrere API-Tokens anzugeben, sondern allgemein immer dann, wenn Sie einen ansonsten identischen provider Block mit unterschiedlichen Parametern verwenden möchten.

Wählen Sie zur Verwaltung Ihrer Ressourcen bei cloudscale.ch den für Sie passenden Ansatz, je nach konkretem Setup, beteiligten Personen und der jeweils bevorzugten Arbeitsweise. Auch wenn Sie Ihre Cloud-Ressourcen dabei in mehrere Projekte aufteilen: Mit alias Instanzen des cloudscale-ch Providers können Sie die Fäden in einem einzelnen, konsolidierten Terraform-Repository zusammenlaufen lassen.

Ein Ziel, viele Namen:
Ihr cloudscale.ch-Team

Das neue Schweizer DSG

Transparenz, Kontrollmöglichkeiten und Verantwortungsbewusstsein im Zusammenhang mit der Bearbeitung von Personendaten – dies sind drei der Ziele, die gemäss Botschaft des schweizerischen Bundesrats mit der Revision des Datenschutzgesetzes (DSG) verfolgt wurden. Zudem sollte das Schweizer DSG an die Datenschutz-Grundverordnung (DSGVO) der EU angenähert werden, damit die Europäische Kommission der Schweiz weiterhin ein angemessenes Datenschutzniveau attestiert.

Tatsächlich kannte man viele Datenschutzvorschriften in den letzten Jahren vor allem aus der DSGVO, obwohl bereits das alte DSG ebenfalls ähnliche Regelungen enthielt. Mit der DSG-Revision ist nun auch der Schweizer Datenschutz in aller Munde. Dies liegt wohl nicht zuletzt an den Bussgeldern in Höhe von bis zu CHF 250'000, die fehlbaren Entscheidungsträgern neu drohen. Nachfolgend sollen jedoch nicht die Bussen im Zentrum stehen, sondern die zwei wichtigsten Konstellationen bzgl. Datenschutz im Alltag und die Frage, wie cloudscale.ch dabei involviert ist.

Betroffene Personen und Verantwortliche

Das neue Schweizer DSG schützt natürliche Personen (d.h. Menschen, nicht juristische Personen wie Firmen oder Vereine), wenn Daten über sie verarbeitet werden. Diese betroffenen Personen müssen dabei nicht namentlich bekannt sein; es reicht aus, wenn die Personen anhand der Daten bestimmbar sind, damit die Daten "personenbezogene Daten" darstellen. Wer als Unternehmen solche personenbezogene Daten verarbeitet und dabei über die Zwecke und Mittel der Verarbeitung bestimmt, ist der "Verantwortliche". Im Rahmen eines Online-Shops beispielsweise ist der Shop-Betreiber der Verantwortliche, der u.a. die Kontaktinformationen und Bestellungen seiner Kunden (betroffene Personen) verarbeitet.

Zwischen der betroffenen Person und dem Verantwortlichen bestehen gewisse Rechte und Pflichten. So hat die betroffene Person ggf. einen Anspruch darauf, dass falsche Daten, die über sie verarbeitet werden, berichtigt werden, oder dass Daten allenfalls ganz gelöscht werden. Ausgangspunkt ist dabei, dass die betroffene Person über die Verarbeitung der Daten überhaupt Bescheid weiss – den Verantwortlichen trifft deshalb eine Informations- und Auskunftspflicht, die oft mit einer sog. Datenschutzerklärung auf der eigenen Website erfüllt wird.

Bei cloudscale.ch sind wir seit jeher sparsam unterwegs und erheben in der Rolle als Verantwortlicher nicht "auf Vorrat" unnötige Daten. Ein gewisses Minimum ist jedoch nötig, um Verträge abwickeln und unsere Services erbringen zu können, darunter z.B. Kontaktinformationen unserer Kunden oder Daten zur Zahlungsabwicklung. Über unsere Datenverarbeitungen als Verantwortlicher informieren auch wir in Form einer Datenschutzerklärung, die wir auf unserer Website publizieren.

Auftragsverarbeitung

Oft verarbeiten Verantwortliche die personenbezogenen Daten nicht nur selbst, sondern ziehen Dienstleister dazu bei. Beim beispielhaft genannten Online-Shop könnte etwa eine Bonitätsauskunft eingeholt werden, bevor der Kunde auf Rechnung beliefert wird. Der Shop-Betreiber ist auch für diesen Schritt der Verantwortliche und bleibt – wie die Bezeichnung schon sagt – verantwortlich für die ganze Datenverarbeitung; die Auskunftei ist ein "Auftragsverarbeiter", weil sie die Daten im Auftrag des Verantwortlichen verarbeitet. Eine solche Auftragsverarbeitung ist grundsätzlich zulässig, muss aber in einem Vertrag zwischen dem Verantwortlichen und dem Auftragsverarbeiter geregelt werden.

Als Cloud-Anbieter sind wir bei cloudscale.ch ein Auftragsverarbeiter, sobald unsere Kunden unsere Services nutzen, um personenbezogene Daten zu verarbeiten – zum Beispiel indem der besagte Online-Shop auf unserer Infrastruktur betrieben wird. Schon lange bieten wir deshalb auch den nötigen Vertrag zur Auftragsverarbeitung bzw. AV-Vertrag (AVV) an, der mit zwei Mausklicks direkt in unserem Cloud Control Panel abgeschlossen werden kann.

Anders als die DSGVO mit ihren detaillierten Regelungen macht das Schweizer DSG auch in seiner revidierten Fassung kaum Vorgaben zum Inhalt des AV-Vertrags. Wir haben dennoch die Gelegenheit genutzt und unseren AVV per 01.09.2023 überarbeitet. Während sich in der Sache kaum Änderungen aufgedrängt haben, haben wir die Struktur und viele Formulierungen überarbeitet, um die Klarheit und Verständlichkeit zu verbessern, z.B. an den folgenden Stellen:

• Die Bezeichnung des Dokuments lautet neu "Vertrag zur Auftragsverarbeitung" bzw. AV-Vertrag oder AVV, einer der heute geläufigen Begriffe (zuvor: "Vereinbarung zur Auftragsdatenverarbeitung" bzw. ADV-Vereinbarung).
• Wir erwähnen nicht mehr explizit die DSGVO, sondern "anwendbares Datenschutzrecht". Damit wird deutlicher, dass auch andere Regelungen anwendbar sein können, z.B. das schweizerische Datenschutzgesetz (DSG).
• Wir verwenden weiterhin die Begriffe "verarbeiten" und "personenbezogene Daten" wie im Kontext der DSGVO üblich, während das Schweizer DSG von "bearbeiten" und "Personendaten" spricht. Die konsistente Wortwahl soll der Lesbarkeit dienen und steht einer Auslegung des AVV im Sinne des Schweizer Rechts natürlich nicht entgegen.
• Neu präzisieren wir "dokumentierte Weisungen" (ein Begriff aus der DSGVO). Damit soll klarer werden, dass der Kunde oder ggf. Dritte selbst und direkt (und nicht etwa via Korrespondenz mit uns) über die Nutzung unserer IaaS-Services und damit über die Verarbeitung von Daten bestimmen.
• Bisher hatten wir für die "technischen und organisatorischen Massnahmen" bzw. TOM auf andere Dokumente verwiesen; insbesondere auf unserer Website hatten wir immer wieder über Verbesserungen unserer Sicherheitsfeatures berichtet. Neu ist ein Set an TOM explizit im Anhang des AVV zusammengefasst. Wichtig: Die beschriebenen TOM stellen eine Momentaufnahme dar. Während das so beschriebene Schutzniveau verbindlich ist und nicht unterschritten werden darf, können wir die tatsächlich getroffenen Massnahmen auch in Zukunft ändern und weiterentwickeln. Ob dieses Niveau für eine konkret geplante Verarbeitung passt, muss dabei durch den Auftraggeber beurteilt werden – seitens cloudscale.ch stellen wir standardisierte Services zur Verfügung, ohne im Einzelfall involviert zu sein.
• Zusätzlich zu den TOM, die wir auf unserer Seite treffen, haben wir eine Liste mit sicherheitsrelevanten Funktionen unserer Services angefügt, die unsere Kunden nutzen können, um ihrerseits die Sicherheit der Daten und deren Verarbeitung zu unterstützen.
• Die Bestimmung bzgl. Löschung der Daten am Ende der Vertragsdauer wurde präzisiert, insbesondere um den Hinweis, dass der Auftraggeber seine Daten in Eigenregie an einen neuen Ort umziehen kann.

Datenschutz und -sicherheit waren für uns bei cloudscale.ch von Beginn weg zentral. Dazu pflegen wir nicht nur selbst einen verantwortungsbewussten Umgang mit personenbezogenen Daten, sondern unterstützen auch unsere Kunden bei der Einhaltung der relevanten Vorgaben – z.B. mithilfe des AV-Vertrags, den sie direkt in unserem Cloud Control Panel abschliessen können.

Engagiert für Datenschutz,
Ihr cloudscale.ch-Team

Bisher: Cloud-Ressourcen konnten "umgetauscht" werden

Wenn Sie bisher einen virtuellen Server oder andere Cloud-Ressourcen erstellt haben, wurden die entsprechenden Kosten für 24 Stunden sofort von Ihrem Account-Guthaben abgebucht. Nach Ablauf dieser vorausbezahlten Periode erfolgte eine erneute Abbuchung für die nächsten 24 Stunden – so lange, wie Sie die Ressourcen behalten haben.

Beim Löschen von Cloud-Ressourcen erfolgte umgekehrt eine Gutschrift für die unbenutzte, aber bereits vorausbezahlte Restdauer dieser 24-Stunden-Periode. Beim Skalieren von Servern und Volumes wurde die Gutschrift zum alten Preis gewährt und anschliessend der neue Preis – wieder für 24 Stunden – belastet. Die Cloud-Ressourcen wurden somit einzeln über den Tag verteilt verrechnet, je nach Uhrzeit, zu der sie erstellt oder letztmals skaliert worden waren.

Neu: Nur tatsächlich entstandene Kosten werden belastet

Neu werden die Kosten im Hintergrund gesammelt und kurz nach Mitternacht (gemäss Zeitzone von Zürich) Ihrem Account-Guthaben belastet. Für Cloud-Ressourcen, die Sie bereits wieder gelöscht haben, werden somit direkt die tatsächlichen Kosten verrechnet, statt eine "Akonto-Belastung" durch eine Gutschrift zu korrigieren.

Auch wenn beide Wege letztendlich zu den gleichen Kosten führen: Der neue Mechanismus bildet nun das ab, was man bei sekundengenauer Abrechnung intuitiv erwarten würde. Und in gewissen Konstellationen werden damit eine Vielzahl unnötiger Belastungen und Rückbuchungen vermieden, z.B. wenn Sie Integration-Tests mit dynamisch erstellten GitLab-Runners nutzen, oder wenn Sie einfach verschiedene Flavors ausprobieren, um den für Sie passenden zu finden.

Auf einer neuen Übersichtsseite pro Projekt werden die Kosten weiter aufgeschlüsselt.

Übersicht über Gesamtkosten und Zusammensetzung

Im "Billing"-Bereich unseres Cloud Control Panels sehen Sie wie bisher die täglichen Gesamtkosten Ihrer einzelnen Projekte. Auf einer neuen Übersichtsseite pro Projekt werden diese Kosten nun weiter aufgeschlüsselt; so sehen Sie nun auf einen Blick, wie sich diese Kosten auf die einzelnen Ressourcen-Typen (z.B. Compute, Storage etc.) sowie auf die konkreten Ressourcen (einzelne virtuelle Server, Volumes etc.) verteilen. Aufgeführt werden dabei die Kosten pro Tag für alle Ressourcen, die zum jeweiligen Zeitpunkt im Projekt existieren.

Eine Ausnahme stellt unser Object Storage dar: dieser wird nicht pro Tag, sondern nach tatsächlicher Nutzung verrechnet. Schon bisher wurden diese Kosten deshalb erst im Nachhinein, kurz nach Mitternacht, dem Account-Guthaben belastet. Weil hier der Preis pro Tag nicht feststeht, sondern eben von der Nutzung abhängt, werden in der Übersicht die durchschnittlichen Kosten der letzten 7 Tage angezeigt.

Einer der vielen Vorteile der Cloud ist ihre Flexibilität: Sie buchen und bezahlen immer genau das, was Sie benötigen. Mit der Abrechnung pro Kalendertag (statt für jede Cloud-Ressource einzeln) wird nun auch die "Buchhaltung" dahinter massiv vereinfacht. Und wir arbeiten bereits an weiteren Tools, um Sie bei der Kostenkontrolle noch besser zu unterstützen.

Kein Taschenrechner nötig.
Ihr cloudscale.ch-Team

In einem nächsten Schritt wurden drei mögliche Mitigations-Ansätze (BIOS Update, "Chicken Bit" und Microcode Update) besprochen und die beiden Letzteren in unserer Lab-Umgebung getestet. Diese beiden Lösungsansätze haben den Vorteil, dass sie im laufenden Betrieb angewendet werden können, wobei jedoch die Variante "Chicken Bit" voraussichtlich mit einer erheblichen Performance-Einbusse einhergegangen wäre. Aus diesem Grund entschieden wir uns für die Mitigation mittels Microcode Update.

Nach erfolgreicher Anwendung des Microcode Update im Lab konnten wir verifizieren, dass ein Exploit der Lücke mittels Proof-of-Concept-Code nicht mehr möglich war, während der stabile Betrieb weiterhin gewährleistet werden konnte.

Nachdem unsere Test Suite erfolgreich durchlief, haben wir uns entschieden, das Update gestaffelt in der produktiven Umgebung einzuspielen. Aufgrund der Dringlichkeit setzten wir das Wartungsfenster nicht mit zwei Wochen Vorlauf wie üblich, sondern per sofort an – und zwar gleich für beide Cloud-Standorte, auch wenn wir Wartungen sonst normalerweise auf zwei separate Tage legen. Zuerst auf einzelnen Compute-Hosts und danach in Batches haben wir so das Microcode Update angewendet.

Am Dienstag, 25.07.2023, um 01:33 Uhr (CEST) schliesslich war der letzte Compute-Host gepatcht.

Setzt Prioritäten:
Ihr cloudscale.ch-Team

PS: Um über Incidents und geplante Wartungsarbeiten laufend informiert zu werden, abonnieren Sie die Updates über den gewünschten Kanal auf unserer Statusseite.

Der Code, welchen wir für die Beispiele in diesem Beitrag verwenden, ist eine etwas vereinfachte Version von tatsächlichem Code, welcher die Daten für folgende React Komponente berechnet (unseren Usern dürfte diese View bekannt vorkommen):

Aus den von der API gelesenen Daten wird sowohl die Server-Liste als auch die Zusammenfassung generiert.

Es geht also darum, für eine gegebene Liste von Servern folgende Information zu ermitteln:

• Anzahl Server
• Summe des Memory der Server
• Summe der Grösse aller Volumes der Server
• Summe der täglichen Kosten der Server

Verschaffen wir uns als Erstes einen Überblick über den entsprechenden TypeScript Code:

export interface Server {
    name: string
    daily: number
    memory: number
    volumes: Volume[]
}

export interface Volume {
    type: 'ssd' | 'bulk'
    size: number
}

export interface ServerSummary {
    count: number
    totalMemory: number
    totalStorage: number
    totalCost: number
}

export const getServerSummary = (servers: Server[]): ServerSummary => {
    const count = servers.length;
    const totalCost = servers.reduce((accu, s) => accu + s.daily, 0);
    const totalMemory = servers.reduce((accu, s) => accu + s.memory, 0);
    const volumes = servers.reduce<Volume[]>((accu, s) => accu.concat(s.volumes), []);
    const totalStorage = volumes.reduce((accu, v) => accu + v.size, 0);
    return {count, totalCost, totalMemory, totalStorage};
}

Die beiden ersten Interfaces Server und Volume sind die Datentypen für den Input. Als Nächstes folgt das Interface ServerSummary, welches die vier zu berechnenden Werte enthält. Als Letztes sehen wir die Funktion getServerSummary, unser Testsubjekt. Für die Berechnung der Summen verwenden wir hier Array.reduce().

Im nächsten Schritt schauen wir uns den dazugehörigen Unit-Test an, welcher ebenfalls in TypeScript implementiert wurde:

test('test getServerSummary', () => {
    // arrange
    const servers: Server[] = [
        {name: 'server1', daily: 1, memory: 4, volumes: [{size: 50, type: 'ssd'}]},
        {name: 'server2', daily: 2, memory: 8, volumes: [{size: 10, type: 'ssd'}, {size: 200, type: 'bulk'}]},
    ]

    // act
    const actual = getServerSummary(servers)

    // assert
    const expected: ServerSummary = {
        count: 2,
        totalCost: 3,
        totalMemory: 12,
        totalStorage: 260,
    };
    expect(actual).toEqual(expected)
});

Dies ist ein klassischer Unit-Test gemäss dem Arrange, Act and Assert (AAA) Pattern:

• Arrange: wir definieren zwei Server Instanzen mit Testdaten.
• Act: wir rufen die Funktion getServerSummary auf.
• Assert: wir vergleichen das effektive mit dem erwarteten Resultat.

Dieser Test funktioniert einwandfrei. Aber bei genauer Betrachtung fällt uns Folgendes auf: Da wir TypeScript verwenden und die Properties Server.name und Volume.type nicht optional sind, müssen wir sie in den Testdaten (siehe Arrange) auch befüllen, obwohl sie für den Test-Case nicht relevant sind. Wir können name und type zwar entfernen und der Unit-Test läuft weiterhin durch, aber der TypeScript Compiler gibt uns in diesem Fall eine Fehlermeldung.

In diesem kleinen Beispiel mag es noch okay sein, wenn man diese nicht benötigten Testdaten spezifizieren muss, aber bei komplizierteren, geschachtelten Strukturen kann dies sehr schnell unangenehm werden.

Ein erster naiver Versuch um das Problem zu lösen waren TypeScript Type Assertions:

const servers: Server[] = [
    {daily: 1, memory: 4, volumes: [{size: 50}]} as unknown as Server,
    {daily: 2, memory: 8, volumes: [{size: 10, type: 'ssd'}, {size: 200,}]} as unknown as Server,
]

Nun müssen wir die überflüssigen Attribute nicht mehr angeben, aber wir haben auch die Type-safety eingebüsst. Denn wenn wir jetzt fälschlicherweise bei {size: 50} einen falschen Namen oder Typen verwenden wie z.B. {sizeGb: 'x'}, erhalten wir keinen Kompilierfehler und ein unintuitives Test-Resultat.

Nach einigem Experimentieren und mehreren Verbesserungen sind wir bei folgendem Test-Helper angelangt:

function mockPartially<T extends object>(mockedProperties: Partial<T> = {}): T {
  const handler = {
    get(target: T, prop: keyof T & string) {
      if (prop in mockedProperties) {
        return mockedProperties[prop];
      }
      throw new Error(`Mock does not implement property: ${prop}, but it was accessed.`);
    },
  };
  return new Proxy<T>({} as T, handler);
}

mockPartially() erstellt für einen beliebigen Typen T ein Proxy-Objekt. Als mockedProperties kann ein Objekt mit einem beliebigen Subset von Properties von T übergeben werden. Dies geschieht mithilfe des Typen-Konstruktors Partial. Partial<T> erstellt einen neuen Typ, bei welchem alle Properties von T auf optional gesetzt werden. Mithilfe des Proxy-Objekts können wir ein beliebiges Verhalten beim Zugriff auf Properties des Objekts implementieren. In unserem Fall geben wir eine Fehlermeldung zurück, wenn die fragliche Property in mockedProperties nicht angegeben wurde. Wurde die Property angegeben, dann wird ihr Wert unverändert zurückgegeben.

mockPartially importieren wir jeweils als mP und können damit die Testdaten wie folgt definieren:

const servers: Server[] = [
    mP<Server>({daily: 1, memory: 4, volumes: [mP<Volume>({size: 50})]}),
    mP<Server>({daily: 2, memory: 8, volumes: [mP<Volume>({size: 10}), mP<Volume>({size: 200})]}),
]

Diese Lösung hat für uns folgende Vorteile:

• Die unnötigen Input-Daten können wir weglassen.
• Wenn wir benötigte Daten vergessen, erhalten wir eine einfach verständliche Fehlermeldung, wie z.B.: Mock does not implement property: volumes, but it was accessed.
• Bei falschen Testdaten wie {sizeGb: 50} oder {size: 'x'} erhalten wir einfach verständliche Fehler vom TypeScript Compiler.

Wir hoffen, dieser etwas detailliertere Einblick in den Alltag unserer Software-Entwickler hat dich interessiert, und vielleicht kannst du unseren mockPartially Helper ja sogar selber brauchen.

(Not) mocking!
Dein cloudscale.ch-Team

Django – ein solides Fundament

Unser Cloud Control Panel hat im Laufe der Jahre eine umfassende Entwicklung durchgemacht. Ursprünglich wurde es als "Minimum Viable Product" in Lua geschrieben. Für bessere Wartbarkeit wollten wir jedoch ein Framework nutzen und entschieden uns deshalb, das Control Panel in Python und Django neu zu implementieren.

Django bezeichnet sich selbst als "The web framework for perfectionists with deadlines". Es hat sich als zuverlässig, gut getestet und leistungsstark erwiesen. Mit Django konnten wir schnell neue Features hinzufügen, genauso wie bestehenden Code weiter verbessern.

Schrittweise Einführung von React

Im damaligen Stadium umfasste das Control Panel nur wenige dynamische Komponenten. Diese erlauben dem Nutzer unseres Control Panels, laufend aktuelle Informationen – z.B. den Power-Status von Servern – zu erhalten, ohne die Seite neu zu laden. Hier wollten wir die Usability mit einem direkteren Handling der Cloud-Ressourcen weiter verbessern. Nach gründlicher Überlegung entschieden wir uns daher, React einzuführen. Um einen reibungslosen Übergang zu gewährleisten, haben wir eine schrittweise Umsetzung gewählt.

Wir begannen damit, neue Features oder die Anpassung existierender Funktionalität mit React umzusetzen, und priorisierten dabei diejenigen Fälle, bei denen der Nutzen für unsere Kunden am grössten erschien. Diese schrittweise Integration ermöglichte es uns, die Fehleranfälligkeit niedrig zu halten und gleichzeitig schrittweise die ganzen Vorteile von dynamischen Webkomponenten zu erschliessen.

Die angezeigten Informationen – z.B. der Power-Status von Servern – sind aktuell, auch ohne die Seite neu zu laden.

Umstellung auf Single-Page-Anwendung

Als logische Fortsetzung des zunehmenden Einsatzes dynamischer Webkomponenten folgte die Umstellung auf eine Single-Page-Anwendung (SPA). Damit erübrigt sich innerhalb des Control Panels ein Reload der Seite komplett, was eine ansprechende und interaktive Webanwendung ermöglicht.

Hand in Hand mit dieser Umstellung lösten wir auch das Generieren von HTML-Elementen mittels Django-Templates weitestgehend ab. Stattdessen läuft nun serverseitig eine (interne) API, die dem Browser alle nötigen Inhalte bereitstellt. Diese klarere Trennung von Browser- und Servertechnologien erleichtert auch die Zusammenarbeit in unserem Softwareentwicklungs-Team.

End-to-end Typechecking

Vor allem beim Überarbeiten von bestehendem Software-Code kann es in untypisierten Sprachen wie JavaScript oft dazu kommen, dass Fehler eingeführt werden, wenn nicht durchgehend klar ist, von welchem Typ die verwendeten Variablen zur Laufzeit sein werden. Schon länger verwenden wir deshalb TypeScript. Diese Sprache erlaubt es, JavaScript-Code mit Datentypen zu ergänzen und durch den TypeScript-Compiler testen zu lassen.

Zentral in unserem Control Panel ist die Kommunikation zwischen browser- und serverseitigem Code via unsere REST-API. Deshalb wollen wir auch sicherstellen, dass beide Seiten die gleichen Datentypen verwenden. Hierzu haben wir einen speziellen Code-Generator entwickelt, der automatisch TypeScript-Code auf Basis der Definitionen unserer Django REST-API generiert. Der so generierte Code wird dann im Rahmen unserer kontinuierlichen Integration (CI) auf Korrektheit überprüft. Dieser "end-to-end"-Ansatz des Typechecking hilft uns, die Code-Qualität zu verbessern und potenzielle Fehler zu reduzieren.

Wir arbeiten kontinuierlich daran, unsere Webanwendung basierend auf Feedback und iterativen Schritten weiter zu verbessern. Unser Ziel ist es, eine benutzerfreundliche Anwendung zu entwickeln, die den Anforderungen unserer Nutzer gerecht wird und uns gleichzeitig bei der weiteren Entwicklung unterstützt.

On the same page!
Ihr cloudscale.ch-Team

Periodische Peaks durch Integration-Tests

Automatisierte Software-Tests machen Sinn und sind vielerorts nicht mehr wegzudenken. Zu definierten Zeiten oder Events – z.B. beim Pushen von Code-Änderungen – werden Testsuites gestartet, die im Idealfall bestätigen, dass alle Testfälle erfolgreich durchlaufen, und die womöglich direkt mit einem produktiven Deployment abgeschlossen werden. Gefundene Fehler dienen als frühes und aussagekräftiges Feedback, wo noch Korrekturen nötig sind.

Komplexere Testkonfigurationen können dabei ziemlich ressourcenintensiv sein und hochperformante Infrastruktur nötig machen, insbesondere wenn Engineers für ihre Weiterarbeit auf die Testergebnisse angewiesen sind. Zwischen zwei Test-Runs liegt die Testinfrastruktur hingegen brach. Um hier unnötige Kosten zu vermeiden, bietet sich die Cloud an: Bei Bedarf werden innert kürzester Frist Ressourcen bereitgestellt; nach abgeschlossenen Tests können die Infrastruktur und mit ihr die Kosten sofort wieder reduziert werden.

Ihr eigenes, dynamisches Test-Setup

Unser Ansible Playbook unterstützt Sie beim Aufbau Ihres eigenen Test-Setups, das im Alltag nur sehr wenig Ressourcen braucht und bei Test-Runs automatisch auf Ressourcen aus unserer Cloud zurückgreift. Selbst wenn Ihre Tests sehr anspruchsvoll sind und entsprechend gross dimensionierte Runners benötigen: nach dem Test-Run werden die Ressourcen wieder gelöscht, und dank sekundengenauer Abrechnung fallen so nur geringe Kosten an.

Das Ansible Playbook geht davon aus, dass Sie das ganze Setup inklusive aller Komponenten neu installieren möchten. Wenn Sie z.B. bereits eine GitLab-Instanz oder einen Runner haben oder andere Details der Installation individuell anpassen möchten, hilft Ihnen die parallel angebotene Anleitung zum manuellen Setup beim Einrichten der gewünschten Komponenten.

Dank automatischem Skalieren und Verrechnung auf Sekundenbasis holen Sie das Maximum aus der Cloud heraus: Ressourcen, die genau dann zur Verfügung stehen, wenn Sie sie benötigen, und für die Sie auch nur dann bezahlen. Test-Setups mit GitLab-Runners und ihren typischerweise kurzen, hohen Belastungen profitieren hier besonders, und mit unserem Ansible Playbook samt passender Anleitung sind sie jetzt auch im Nu fertig eingerichtet.

Testen Sie uns!
Ihr cloudscale.ch-Team

Von Fail-Over zu Load-Balancing

Bei cloudscale.ch sind wir seit jeher bestrebt, die Verfügbarkeit unserer Infrastruktur zu maximieren und so den unterbruchsfreien Betrieb Ihrer virtuellen Server zu gewährleisten. Dennoch bleiben Ausfälle möglich; hinzu kommen geplante Unterbrüche, z.B. wenn Sie Ihre eingesetzte Software aktualisieren. Mit Floating IPs steht Ihnen schon bisher ein Mechanismus zur Verfügung, um den Service aus Sicht Ihrer Nutzer verfügbar zu halten: automatisiert oder manuell kann die IP-Adresse, zu welcher die Nutzer sich verbinden, von einem auf einen anderen virtuellen Server umgezogen werden, der die Verarbeitung der Anfragen sicherstellt, während der ursprüngliche Server offline ist.

Unser neues Load-Balancer-Angebot geht hier noch einen Schritt weiter: Anders als mit einer blossen IP-Adresse ist nicht nur das Umschwenken des eingehenden Traffics von einem auf den anderen Server möglich, sondern der Load-Balancer kann ankommende Connections – und damit die Rechenlast – kontinuierlich auf zwei oder mehr virtuelle Server verteilen. Zusätzliche Health-Checks prüfen periodisch den Zustand der virtuellen Server; reagiert einer nicht mehr wie erwartet, wird er aus der Rotation genommen und der eingehende Traffic unter den verbliebenen, korrekt funktionierenden Servern verteilt. Anders als mit einer Floating IP ist es zudem möglich, für unterschiedliche TCP-Ports jeweils ein separates Set von Servern zu konfigurieren, welche die Requests verarbeiten.

Redundanz auch beim Load-Balancer selbst

Damit der Load-Balancer nicht selbst zum Single Point of Failure wird, handelt es sich in Wirklichkeit um ein Paar von Load-Balancern, die auf unterschiedlicher Hardware laufen. Von aussen sichtbar ist die "virtuelle IP-Adresse", die – ähnlich einer Floating IP – jeweils einem der beiden Load-Balancer zugewiesen ist und automatisch zum anderen Load-Balancer wechselt, wenn beim ersten ein Problem erkannt wird. Während es schon bisher möglich war, ein solches Setup mit zwei zusätzlichen virtuellen Servern und einer Floating IP in Eigenregie aufzubauen, reduziert sich der Aufwand mit unserem Load-Balancer-Service enorm: einmal konfiguriert, verrichtet der Load-Balancer seinen Dienst, ohne dass Sie sich um das Scripten von Checks und Fail-Overs oder um die Wartung von zusätzlichen Servern kümmern müssen.

Bitte beachten Sie, dass die virtuelle IP-Adresse (VIP) an den jeweiligen Load-Balancer gebunden ist und beim Löschen des Load-Balancers ebenfalls gelöscht wird. Um Ihren Service für die Nutzer unter einer gleichbleibenden IP-Adresse anzubieten, empfehlen wir Ihnen, auch bei Load-Balancern zusätzlich eine Floating IP zu verwenden. Floating IPs (nicht jedoch Floating Networks) können übrigens auch zwischen virtuellen Servern und Load-Balancern umgezogen werden – so lösen Sie einen einzelnen Server nahtlos durch ein Load-Balancer-Setup ab.

Einige Hinweise

Das Erstellen und Konfigurieren von Load-Balancern ist derzeit nur via API möglich. Die Erweiterungen unseres Go SDK, des Terraform-Providers und der Ansible Collection, die auf unserer API aufbauen, werden in den nächsten Tagen veröffentlicht. Bestehende Load-Balancer werden zudem in unserem webbasierten Cloud Control Panel angezeigt; die Konfiguration auf diesem Weg ist für einen späteren Zeitpunkt eingeplant. Die nötigen API-Calls zur Verwendung unseres Load-Balancer-Service sind selbstverständlich in unserer API-Dokumentation ausführlich beschrieben, zudem finden Sie dort Beispiel-Requests und -Responses zu jedem unterstützten Call. Beachten Sie bitte, dass die API-Spezifikation aktuell noch als "Beta" gekennzeichnet ist; wir behalten uns vor, hier noch Anpassungen vorzunehmen, die zum momentanen Stand nicht vollständig kompatibel sind.

Die virtuellen Server, zu denen eingehende Connections verteilt werden sollen, müssen vom Load-Balancer aus zwingend über ein privates, gemanagtes Netz erreichbar sein. Für den Load-Balancer selber werden zwei verschiedene Use-Cases unterstützt: Er kann mit einer öffentlichen IP-Adresse (VIP) erstellt werden und so Requests aus dem Internet entgegennehmen, oder aber die VIP befindet sich selbst bereits in einem privaten Netz, so dass der Load-Balancer z.B. für Services innerhalb eines Kubernetes-Clusters genutzt werden kann.

Mit Load-Balancern "as a Service" können Sie ab sofort auf ein bewährtes Konzept setzen, ohne sich selbst um dessen Einzelteile zu kümmern. Indem eingehender Traffic ganz automatisch immer zu einem funktionierenden System geleitet wird, optimieren Sie ganz einfach die Verfügbarkeit Ihrer Online-Services für Ihre Nutzer. Zuverlässigkeit – as a Service.

Unser Engineering für Ihre VIP.
Ihr cloudscale.ch-Team

Ein neues Zuhause für unsere Statusseite

Seit rund fünf Jahren finden Sie unter https://www.cloudscale-status.net Informationen über unsere geplanten Wartungsarbeiten und allfällige Incidents. Neue Einträge können Sie zudem per E-Mail oder RSS- bzw. Atom-Feed abonnieren, um jederzeit auf dem aktuellen Stand zu sein. Selbstverständlich soll dieser Kommunikationskanal bei Störungen unserer normalen Cloud-Infrastruktur nicht gleichzeitig betroffen sein. Deshalb betreiben wir die Statusseite in einem separaten Rechenzentrum und nutzen eine eigene Domain ausserhalb unserer üblichen TLD ".ch".

Während sich die Statusseite gut bewährt hat, wurde es Zeit, das Setup neu zu evaluieren. Wir haben uns entschieden, unsere Statusseite künftig bei einem spezialisierten Anbieter zu hosten, um den Service für Sie nicht nur aufrechterhalten, sondern weiter verbessern zu können. Dabei fiel unsere Wahl auf den deutschen Dienstleister Statuspal. Die Umstellung, die innerhalb der kommenden zwei Wochen eingeplant ist, bedingt eine Downtime der Statusseite von rund einer Stunde; unsere Cloud-Services werden davon selbstverständlich nicht tangiert.

Subscription erneuern und anpassen

Die Historie mit den bisherigen Statusmeldungen pflegen wir auch auf der neuen Statusseite wieder ein, so dass Sie zu vergangenen Events weiterhin alle Einträge einsehen können. Da wir das bisherige System selbst betrieben haben und neu auf einen externen Dienstleister setzen, migrieren wir die Abonnentenliste für E-Mail-Benachrichtigungen hingegen bewusst nicht auf das neue System. Falls Sie auch in Zukunft sofort über neue Einträge informiert werden möchten, abonnieren Sie die gewünschten Kategorien nach der Umstellung einfach neu.

Mit der neuen Statusseite haben Sie zudem die Möglichkeit, Benachrichtigungen direkt in einem der unterstützten Chat-Systeme zu erhalten. Dazu gehören z.B. Slack und Teams; zudem lassen sich via Webhook weitere Tools wie Mattermost, Rocket.Chat oder – mit etwas Engineering – auch andere Tools mit Webhook-Integration anbinden. Wenn Sie für die Koordination rund um Ihre Cloud-Ressourcen bereits einen Chat-Channel benutzen, erscheinen unsere aktuellen Serviceinformationen damit direkt dort, wo sie gebraucht werden.

Gleiche URL, frisches Design

Die Adresse unserer Statusseite lautet unverändert https://www.cloudscale-status.net und bleibt weiterhin auf unserer Website https://www.cloudscale.ch verlinkt. Trotzdem empfehlen wir Ihnen, die Statusseite separat in Ihren Bookmarks zu speichern – so finden Sie sie auch, falls unsere Website selbst einmal von einem Ausfall betroffen sein sollte.

Auch die Service-Kategorien, aus denen Sie die für Sie relevanten Informationen wählen können, bleiben gleich. Die Darstellung hingegen wird noch übersichtlicher und es ist intuitiv ersichtlich, welche Einträge und Updates zusammengehören.

Verpassen Sie auch in Zukunft keine aktuellen Wartungs- und Serviceinformationen. Fügen Sie "https://www.cloudscale-status.net" zu Ihren Bookmarks hinzu, und erneuern Sie nach der Umstellung Ihre Subscription der gewünschten Benachrichtigungen und Kommunikationskanäle.

Status: Operational.
Ihr cloudscale.ch-Team

Die Technik im Zentrum

Unsere Engineers geniessen bei der Auswahl ihrer Arbeitsinstrumente grosse Freiheit, dies sowohl punkto Hard- wie auch Software. Das eigene Arbeitsgerät wählen die Mitarbeiter selbstverständlich selbst aus. Typischerweise ist das ein Notebook – neben MacBooks sind auch Linux-Setups gern gesehen – und ein grosser Bildschirm. Als IDE beispielsweise kommen JetBrains-Produkte genauso in Frage wie etwa vim oder Visual Studio Code. Zu den gemeinsam genutzten Tools gehören derzeit GitLab und Confluence.

Breite und tiefgehende Skills werden bei cloudscale.ch nicht nur gefordert, sondern auch gefördert: Für jeden Mitarbeiter steht ein Weiterbildungsbudget bereit, das sowohl eine gewisse Anzahl Arbeitstage als auch einen finanziellen Teil umfasst. Weil die Interessen ganz unterschiedlich sind, wählt jeder Mitarbeiter selbst, ob und wofür er sein Budget einsetzen will – "no questions asked". Das können zum Beispiel Bücher sein, um sich individuell in ein Thema zu vertiefen, aber auch Konferenzen oder Kurse bei spezialisierten Anbietern. Natürlich ist auch bei Weiterbildungen, die über dieses Budget hinausgehen, eine Beteiligung möglich; die konkreten Details richten sich nach dem Einzelfall. Hinzu kommt der Wissensaustausch im Team, von intern geschulten Themen über gegenseitige Code-Reviews bis zu spontanen Diskussionen im Alltag.

Open Source mit dem gewissen Etwas

Bei cloudscale.ch setzen wir sowohl auf bestehende Tools und Frameworks wie auch auf Eigenentwicklungen. So bilden OpenStack und Ceph, zwei führende Open-Source-Projekte in ihrem jeweiligen Bereich, die Basis unserer Cloud. Das webbasierte Cloud Control Panel und die API, die unsere Kunden benutzen, haben wir hingegen von Grund auf selbst entwickelt, greifen aber dabei ebenfalls wieder auf Bestehendes zurück, z.B. das Django REST Framework. Wo es uns sinnvoll erscheint, tragen wir auch selber zu Open-Source-Projekten bei, z.B. in Form von Erweiterungen und Bugfixes.

Wir legen Wert auf Qualität, und zwar in ihren verschiedensten Facetten. Dazu gehört neben der Performance und Verfügbarkeit unserer Cloud-Services auch das Benutzererlebnis. Die Berührungspunkte der Kunden mit unserer Cloud – vom Control Panel über die API bis zur Dokumentation – sind sorgfältig ausgearbeitet, so dass Stolperfallen nach Möglichkeit gar nicht erst entstehen. Dazu tragen auch Tests auf allen Ebenen bei – von Unit- über Integration- bis zu den Acceptance-Tests, die wir auch veröffentlicht haben. Zu den weiteren Massnahmen gehören Code-Reviews und manuelle Tests. Wir nehmen uns die Zeit, die es braucht, um solide Arbeit abzuliefern – und gehen die sprichwörtliche Extra-Meile, wenn dies nötig ist. Releases machen wir darum nicht in einem festen Rhythmus, sondern dann, wenn sie bereit sind und unserem Qualitätsanspruch genügen.

Autonomie bei Arbeitszeit und -ort

Bei cloudscale.ch arbeiten viele Mitarbeiter – Eltern wie auch Nicht-Eltern – in Teilzeit, um mehr Raum für ihre privaten Verpflichtungen und Engagements zu haben. Auch bei den Arbeitszeiten sind wir flexibel und lassen den Mitarbeitern möglichst viel Freiheit. Mit Ausnahme vom Montag, an dem wir uns alle im Büro treffen, ist zudem Home-Office eine beliebte Option und erleichtert es zusätzlich, verschiedene Lebensbereiche unter einen Hut zu bringen. Mit Notebooks und den nötigen Tools haben wir alles was es braucht, und wir geniessen die Flexibilität, die dieses gut eingespielte Modell uns ermöglicht.

Jeweils montags, wenn alle vor Ort im Büro sind, halten wir ein All-Hands-Meeting für Koordination und Informationen, die potenziell alle betreffen. Daran schliesst sich abwechslungsweise das Sprint-Planning bzw. ein bi-weekly Meeting für technische Traktanden an. Hinzu kommen Retrospektiven in längeren Abständen sowie kurze Dailies. Ansonsten setzen wir Meetings oder Calls dann an, wenn konkreter Bedarf besteht, z.B. um Details zu einem geplanten Feature zu besprechen – so viel wie nötig, so wenig wie möglich.

Für unser System Engineering und Software Engineering bei cloudscale.ch suchen wir immer wieder Verstärkung. Wenn du sowohl Deutsch als auch Englisch sprichst und unser Team ergänzen möchtest, schreib uns doch an jobs@cloudscale.ch. Der Bewerbungsprozess kann situativ variieren; in der Regel gehören ein persönliches Kennenlernen via Online-Meeting und ein technisches Interview bei uns in Zürich dazu. Den Rest des Teams lernst du bei einem Getränk deiner Wahl in ungezwungenem Rahmen kennen um zu merken, ob auch die "Chemie" stimmt. Und wenn alles passt, heisst es schon bald...

Willkommen an Bord!
Dein cloudscale.ch-Team

Alles klar mit Prepaid

Prepaid-Angebote sind beliebt. Wir alle kennen sie von Handy-SIM-Karten oder von prepaid "Kredit"-Karten. Die Vorteile liegen auf der Hand: Man hat jederzeit klare Verhältnisse, und mit einem im Voraus gesteckten Budget-Rahmen gibt es auch keine Überraschungen am Monatsende. Besonders gut passt der Prepaid-Modus zu Dienstleistungen ohne Grundgebühren – wie z.B. bei cloudscale.ch.

Um unsere Cloud-Services zu nutzen, laden Sie in Ihrem Account oder Ihrer Organization einen Betrag Ihrer Wahl auf. Das Minimum für eine Zahlung liegt bei lediglich CHF 10 – so können Sie auch als neuer Nutzer gefahrlos testen, ob unsere Services zu Ihrem Use Case passen. Solange Sie Services nutzen, werden diese täglich von Ihrem Guthaben abgebucht; andernfalls bleibt das Guthaben in Ihrem Account bzw. Organization für eine spätere Nutzung verfügbar.

Mehr Flexibilität, bessere Usability

Zum Aufladen Ihres Guthabens können Sie ab sofort auch TWINT wählen. Dieses Zahlungssystem, das von vielen Schweizer Banken unterstützt wird, ist sowohl online wie auch offline vielseitig einsetzbar und fand in kurzer Zeit weite Verbreitung. Wir freuen uns, mit TWINT einem grossen Bedürfnis unserer Schweizer Kunden zu entsprechen.

Selbstverständlich stehen Ihnen auch die bisherigen Zahlungsmethoden weiterhin zur Verfügung, neben Mastercard, Visa und American Express auch PostFinance Card und E-Finance sowie PayPal. Als Payment-Service-Provider nutzen wir neu die Datatrans AG, wodurch sich der Zahlungsprozess in unserem Cloud Control Panel im neuen Kleid präsentiert. Uns gefällt dabei vor allem die klare Benutzerführung und die Gestaltung als Overlay, das sich praktisch nahtlos ins Control Panel einfügt. So gelingt das Aufladen Ihres Guthabens nun noch eleganter.

Unveränderte Rahmenbedingungen

An den Rahmenbedingungen rund um Ihr Guthaben ändert sich nichts. Wie schon bisher kann Ihr Guthaben bis zu CHF 3000 betragen – so bestimmen Sie selbst, wie weit Ihr Guthaben reichen soll. Auch die sekundengenaue Verrechnung bleibt gleich: Beim Löschen eines Service werden die Kosten, die für eine 24-stündige Nutzung abgebucht worden waren, anteilig wieder Ihrem Guthaben gutgeschrieben. Und selbstverständlich erhalten Sie für jede Zahlung eine E-Mail mit einer MWST-konformen Rechnung, welche Sie zudem auch im Control Panel herunterladen können.

Wir legen viel Wert auf Usability. Die aktuelle Umstellung bringt aber nicht nur kosmetische Verbesserungen. Wir freuen uns, mit TWINT ein neues und beliebtes Schweizer Zahlungsmittel anzubieten, welches die international gängigen Zahlungslösungen sowie PostFinance ideal ergänzt.

Let's twint!
Ihr cloudscale.ch-Team

Die DevOpsDays Zurich sind inzwischen ein Fixpunkt in unserem Jahresablauf, und cloudscale.ch war auch im 2022 als Sponsor mit an Bord. In ganz unterschiedlichen Formaten – neben klassischen Talks z.B. auch in Open Spaces – wurden vorbereitete und spontane Themen aus dem breiten Einsatzgebiet von DevOps aufgenommen und vertieft. Aus heutiger Sicht besonders aktuell wirkt der Talk von Oliver Goetz: Er berichtete aus der (Weiter-)Entwicklung eines Cloud-basierten Smart-Metering-Systems zur Koordination von Stromlieferanten und -verbrauchern, mitsamt MVPs und kleinem, physisch nachgebautem Modell.

OpenInfra Summit

Mit dem Nachtzug ging es für einen unserer Engineers an den OpenInfra Summit. Dieser fand Anfang Juni im Berliner Congress Center am Alexanderplatz statt, wo auch schon der Chaos Communication Congress gastierte. Unter letzten Corona-Restriktionen beschäftigten sich rund 1000 Teilnehmer aus aller Welt unter anderem mit OpenStack, Kubernetes, Containerisierung und Entwicklungen rund um CSI. Zu entdecken gab es aber auch Einblicke zu Confidential Computing und verschlüsselten Workloads. Natürlich kamen an der dreitägigen Konferenz auch die zwischenmenschlichen Kontakte nicht zu kurz, und es gab reichlich Gelegenheit, Bekanntschaften zu knüpfen und zu pflegen.

OpenStack Ops Meetup

Im Anschluss an den OpenInfra Summit fand, ebenfalls in Berlin, das eintägige OpenStack Ops Meetup statt. In moderierten Sessions stand hier der Austausch mit anderen Operators von "private" und "public" OpenStack-Clouds im Vordergrund. Diskutiert wurden z.B. ganz praktische Dinge, die überall ein Thema sind, vom Einspielen der regelmässig erscheinenden Upgrades über Herausforderungen beim Wachstum bis hin zu verschiedenen Deployment-Ansätzen. Auch hier gab es beim abschliessenden Dinner nochmals Gelegenheit zum persönlichen Austausch – so kommt man schon mal mit einem schwedischen Cloud-Anbieter ins Gespräch.

Swiss Python Summit

Python spielt bei cloudscale.ch eine zentrale Rolle: in dieser Sprache ist nicht nur ein Grossteil unserer eigenen Software geschrieben, sondern beispielsweise auch OpenStack. Entsprechend waren wir mit einer grossen Delegation am Swiss Python Summit mit dabei, der mit einem breitgefächerten Programm auf den OST-Campus in Rapperswil-Jona lockte. In Erinnerung blieb uns unter anderem "Automating teaching about automation in Python" von Florian Bruhin und natürlich "Rust for Python Developers" von unserem Dave Halter. Bei wunderschönem Wetter trafen wir daneben auch viele bekannte Gesichter, unter anderem vom Coredump Hacker- und Makerspace in Rapperswil-Jona.

Cloud Native Day

An einem schönen Herbsttag lud der Cloud Native Day auf den Berner Gurten, und cloudscale.ch war auch diesmal als Sponsor mit an Bord. Am Event mit zwei Tracks waren unter anderem Kubernetes und Cluster-APIs ein grosses Thema. Einen Schritt über reine Container hinaus machte Florian Forster in seinem Talk: Am Beispiel von ZITADEL, einem Open-Source Identity-Provider, der auch für Single Sign-on mit unserem Cloud Control Panel eingesetzt werden kann, berichtete er von seinen ganz praktischen Erfahrungen beim Wechsel zu "serverless". Mit der After-Party ging der Cloud Native Day zu Ende; dass es inzwischen zu regnen begonnen hatte, tat dem Anlass keinen Abbruch.

Dataspace Switzerland

Neben diesen eher technisch orientierten Anlässen war cloudscale.ch in diesem Jahr auch Partner von Dataspace Switzerland, der Event-Reihe von swiss made software. Im Juni ging es schwergewichtig um das Nationale Zentrum für Cybersicherheit NCSC des Bundes, aktuelle Bedrohungen wie Ransomware, IoT oder den amerikanischen CLOUD Act, und nicht zuletzt um den "Faktor Mensch". Im November stand das neue Datenschutzgesetz im Zentrum. Es wurde deutlich, dass so gut wie alle Unternehmen bis zum Inkrafttreten am 01.09.2023 noch Handlungsbedarf haben, und in praxisorientierten Vorträgen wurde aufgezeigt, wie die nächsten Schritte auf diesem Weg gelingen können.

Ansible Zürich Meetup

Nach über einem Jahr Pause war es Ende November wieder soweit, und die Zürcher Ansible-Gemeinde traf sich zum Meetup unweit von unserem Büro. In ihren Präsentationen gewährten drei Referenten Einblick in Best Practices und gaben Tipps zum Einsatz von Ansible für versierte und weniger versierte Nutzer. Bei amerikanischen Hotdogs, Waffeln und Drinks konnte anschliessend weiter gefachsimpelt werden – nicht zuletzt auch mit einigen Mitarbeitern von Red Hat, das seit Längerem hinter dem beliebten Automatisierungswerkzeug steht.

Das breite Spektrum von Anlässen und die rege Beteiligung zeigen, dass IT und Cloud keineswegs nur technische Angelegenheiten sind. Sei es als Nutzer eines komplexen Systems oder als Engineer: der persönliche Austausch hilft, am Ball zu bleiben und gemeinsam die Technologie voranzutreiben. Kennen Sie einen Event, den wir nicht verpassen sollten? Lassen Sie es uns wissen – wir freuen uns schon jetzt auf spannende Diskussionen im 2023!

Bis bald,
Ihr cloudscale.ch-Team

Breite und praxisorientierte Einarbeitung

Nicht alle Engineers bei cloudscale.ch sind selbst typische Cloud-Nutzer, und das ist auch gut so: Unsere Teams kümmern sich unter anderem um Hardware, Virtualisierung sowie die laufende Pflege und Weiterentwicklung unserer gesamten Infrastruktur. Sie ermöglichen es dadurch erst, dass Sie als Benutzer die benötigten Ressourcen auf Knopfdruck – oder auch komplett automatisiert – in Sekundenschnelle beziehen können.

Die Nähe zu unseren Kunden und ihren Anliegen ist uns bei cloudscale.ch ein grosses Bedürfnis. Für Engineers, die neu zu uns stossen, haben wir deshalb eine Sammlung von kleinen Übungen zusammengestellt, um unser Angebot mit seinen Features auch aus der Kundenperspektive kennenzulernen. Das so gewonnene Verständnis hilft in vielerlei Hinsicht – nicht zuletzt wenn es darum geht, Anliegen unserer Kunden nachzustellen und kompetent zu beantworten.

Learning by doing – auch für unsere Benutzer

Für uns war klar, dass solche geführten, aber eigenständig absolvierbaren Übungen zu den Features und Tools nicht nur für unsere eigenen Engineers nützlich sind, sondern dass auch Anwender bei unseren Kunden und Partnern davon profitieren können. Deshalb haben wir diesen kleinen Parcours quer durch unsere Services bei GitHub publiziert.

Nebst einer kurzen Einleitung finden sich bei den Cloud Exercises pro Bereich auch thematisch passende Beiträge aus unserem Blog verlinkt. Eine eigentliche Anleitung oder gar eine Musterlösung gibt es jedoch nicht: Der Weg ist das Ziel. Indem man sich mit einem bisher unbekannten Feature oder Tool beschäftigt, fügt sich das Verständnis Stück für Stück zusammen. Falls alles Knobeln nicht hilft, geben wir bei cloudscale.ch aber gerne ein paar Tipps – das gilt für unsere neuen Kollegen natürlich genauso wie für unsere Kunden.

Bei den Cloud Exercises wird auch deutlich, dass oft mehrere Wege zum Ziel führen. Nehmen Sie die Übungsbeispiele zum Anlass, um verschiedene Ansätze selber auszuprobieren. Und wer weiss, vielleicht stossen Sie quasi "im Vorbeigehen" auf Lösungen, die Sie schon bald nicht mehr missen möchten.

Übung macht den Meister!
Ihr cloudscale.ch-Team

Default Project

Viele unserer Benutzer arbeiten in mehreren Cloud-Projekten mit – oft aber in ganz unterschiedlichem Umfang. Stellen Sie in den "Settings" Ihres Accounts Ihr am häufigsten benutztes Projekt als "Default Project" ein, damit Sie nach dem Einloggen direkt loslegen können. Ihre anderen Projekte erreichen Sie natürlich weiterhin mit nur zwei Mausklicks.

Suchen im Dropdown

Zwischen Ihren Projekten wechseln Sie ganz intuitiv, indem Sie sie aus dem Dropdown-Feld auswählen. Doch es geht noch schneller: Tippen Sie einige Buchstaben des gesuchten Projektnamens (auch aus der Wortmitte) in das offene Feld und bestätigen Sie mit Enter. Das Gleiche funktioniert übrigens auch bei den meisten anderen Dropdowns in unserem Control Panel.

Zeitzone und -format

An verschiedenen Stellen finden Sie im Control Panel Daten und Uhrzeiten – so wissen Sie z.B. sofort, wann ein Server erstellt oder ein API-Token zuletzt verwendet wurde. Zentral sind Zeitstempel natürlich auch in den verschiedenen Logs. Wählen Sie in den "Settings" Ihres Accounts die Zeitzone und das Darstellungsformat, die Sie bei Ihrer Arbeit am besten unterstützen.

Zwei-Faktor-Authentifizierung

Schützen Sie Ihren Account bei cloudscale.ch mittels Zwei-Faktor-Authentifizierung (2FA). Damit wird zum Einloggen zusätzlich zum normalen Passwort ein Token abgefragt (auch "One-Time Password" bzw. OTP genannt), das Sie z.B. mit Ihrem Smartphone generieren. Bewahren Sie auch den zugehörigen "Recovery Code" an einem sicheren Ort auf für den Fall, dass Ihr Smartphone einmal nicht zur Verfügung stehen sollte.

Login-Benachrichtigung

Unter dem Menüpunkt "Sessions" können Sie angeben, dass Sie über erfolgte Logins in Ihren cloudscale.ch-Account benachrichtigt werden möchten. Insbesondere wenn Sie zum Einloggen in unser Control Panel von SSO mit eigenem Identity Provider profitieren, empfiehlt sich als Backup ein zusätzlicher, passwortbasierter "Break Glass Account" mit aktivierter Benachrichtigung im Fall, dass dieser Account tatsächlich benutzt wird.

Default SSH-Keys

Laden Sie in unserem Control Panel auch die öffentlichen SSH-Keys Ihrer Kollegen und Mitarbeiter hoch, um sie beim Erstellen von neuen Servern von Anfang an zu berechtigen. Über das "Stern"-Icon legen Sie fest, welche der Keys dabei vorselektiert werden sollen – selbstverständlich können Sie Ihre Auswahl beim Launch jedes einzelnen Servers noch anpassen.

Server Groups

Mit "Anti-Affinity" erreichen Sie, dass entsprechend gruppierte Server (z.B. drei Webserver in einem Load-Balancing-Cluster) jederzeit auf unterschiedlichen physischen Systemen laufen. So können Sie den Einfluss eines potenziellen Hardware-Problems auf Ihr Gesamt-Setup minimieren. Unter "Server Groups" finden Sie einen Überblick über Ihre bestehenden Gruppen, können diese bei Bedarf umbenennen oder neue Gruppen vorab anlegen – z.B. wenn Sie diese anschliessend in einem automatisierten Setup referenzieren möchten.

Default Zone

Zur Vorbereitung auf gewisse unwahrscheinliche, aber potenziell schwerwiegende Ereignisse wie Feuer oder Erdbeben empfehlen wir geo-redundante Setups an unseren zwei Cloud-Standorten. Wählen Sie den Standort, an welchem Sie häufiger Änderungen vornehmen, im jeweiligen Projekt als "Default Zone" aus: Beim Erstellen von neuen Servern im webbasierten Control Panel wird diese Zone vorselektiert; beim Launch via API kommt sie zum Zug, wenn im API-Call nicht explizit eine Zone angegeben wird.

Reverse DNS automatisch setzen

Falls Sie im DNS zur IP-Adresse eines Servers einen bestimmten Reverse-Eintrag setzen möchten, können Sie diese Anpassung jederzeit via Control Panel vornehmen. Wenn Sie gleich beim Erstellen eines Servers einen vollständigen Domain-Namen (sog. "Fully Qualified Domain Name" bzw. FQDN) als Hostname angeben, wird dieser sogar automatisch für den Reverse DNS verwendet. Selbstverständlich können Sie ihn aber auch in diesem Fall jederzeit wieder ändern.

Console Log

Nichts ist perfekt – dies gilt in der IT mindestens genauso wie sonst. Reagiert ein Server nicht mehr, hilft meist ein Reboot, den Sie notfalls via Control Panel auslösen können. Werfen Sie zuvor noch einen Blick ins "Console Log": Oft finden Sie dort Informationen, die der Server im Zusammenhang mit dem Absturz auf die serielle Konsole ausgegeben hat und die Ihnen bei der weiteren Fehlerbehebung behilflich sein können.

Host Keys

Ebenfalls ins Console Log ausgegeben werden die öffentlichen SSH-Keys des Servers, wenn cloud-init diese beim erstmaligen Booten generiert. Unser System holt sie dort ab und zeigt die zugehörigen Fingerprints im Control Panel an. So können Sie schon bei der allerersten SSH-Verbindung verifizieren, dass Sie direkt mit dem richtigen Server kommunizieren – noch bevor eine Prüfung anhand Ihrer known_hosts-Datei möglich ist.

Jeder hat seinen eigenen Arbeitsstil, und oft führen verschiedene Ansätze zum Ziel. Nutzen Sie Defaults und Features daher so, wie sie zu Ihnen und Ihren Projekten passen. Zur gemeinschaftlichen Arbeit an Cloud-Ressourcen finden Sie noch weitere Hinweise in Kollaboration – die zentralen Begriffe; einige Tipps für Ihr optimales Cloud-Setup haben wir zudem in So nutzen Sie unsere Infrastruktur optimal zusammengestellt.

Rundum durchdacht,
Ihr cloudscale.ch-Team

Bei cloudscale.ch bieten wir unseren Kunden IT-Infrastruktur "as a Service": Im Handumdrehen können virtuelle Server von ganz klein bis ganz gross erstellt werden, die sich auch danach jederzeit skalieren und wieder löschen lassen. So sparen sich unsere Kunden die Beschaffung und Wartung von Hardware, den Betrieb von Datacenter-Infrastruktur sowie die Sicherstellung der Konnektivität. Rechenleistung, Speicherplatz und Netzwerkanbindung basieren dabei natürlich trotzdem auf entsprechend dimensionierten physischen Ressourcen, die sich nicht auf Zuruf umziehen lassen, wenn der Strom ausfällt.

Datacenter haben vorgesorgt

Umso wichtiger ist eine möglichst zuverlässige Stromversorgung. cloudscale.ch hat die genutzten Datacenter, von denen wir auch den Strom beziehen, deshalb von Anfang an sehr bewusst ausgewählt. Die Datacenter verfügen an beiden Cloud-Standorten über zwei separate Stromzuführungen zum Gebäude, zwei dedizierte Stromzuführungen bis hin zu unserer Hardware, sowie USV-Anlagen und Diesel-Generatoren, die bei einem Stromausfall sofort einspringen. "Auch bei einem Blackout würde unser Rechenzentrum weiter funktionieren", lässt sich etwa Franz Grüter im Tagesanzeiger zitieren – er ist Verwaltungsratspräsident bei der Green Datacenter AG, die unsere Kunden als Standort "LPG" kennen.

An beiden Cloud-Standorten verfolgen die jeweiligen Datacenter-Betreiber zudem laufend die Lage und setzen wo möglich weitere Optimierungen um, z.B. mit einer erhöhten Diesel-Reserve oder Lieferverträgen. Nach unserem Kenntnisstand wurden auch beide Standorte bereits offiziell als "kritische Infrastruktur" eingestuft. Zusätzlich engagiert sich die Branche, um die Bedeutung der IT-Infrastruktur für sämtliche Lebensbereiche ins Bewusstsein der Entscheidungsträger zu rufen.

Risiko-Minimierung durch Redundanz

Schon bisher sind wir natürlich auch bei cloudscale.ch selbst bestrebt, die Auswirkungen von isolierten Incidents – die sich nie ganz ausschliessen lassen – möglichst gering zu halten. So ist auch unsere Internet-Anbindung redundant ausgelegt mit mehreren direkten Verbindungen zu verschiedenen IP-Transit-Anbietern, deren Equipment auf der Gegenseite ebenfalls durch zwei Stromkreise, USV und Diesel-Generatoren geschützt ist.

Mit zwei Cloud-Standorten, die weitestgehend unabhängig voneinander funktionieren, ermöglichen wir unseren Kunden zudem geo-redundante Setups. So können Sie sich für den Worst Case zusätzlich absichern – selbst wenn wir überzeugt sind, dass dank der getroffenen Massnahmen auch im Winter keine Ausfälle zu befürchten sind.

Wie sich die Lage im kommenden Winter präsentieren wird, weiss aktuell niemand; die Einflussfaktoren reichen von den internationalen Energiemärkten buchstäblich bis hin zum Wetter. Die Datacenter-Betreiber an unseren beiden Cloud-Standorten haben jedoch seit jeher vorgesorgt: Mit USV-Anlagen und Diesel-Generatoren können sie auch längere Unterbrüche überbrücken und so den durchgehenden Betrieb unserer Server sicherstellen.

Langfristige Vorbereitung lohnt sich!
Ihr cloudscale.ch-Team

Übergangsphase für alte Compute Flavors – jetzt wechseln

Die neuen Flavors bieten unterschiedliche Memory/CPU-Verhältnisse und passen so noch genauer für verschiedenste Workloads; zudem sind die meisten neuen Flavors deutlich günstiger als die bisherigen mit vergleichbarer Ausstattung. In unserem webbasierten Cloud Control Panel können seit dem 01.07.2022 nur noch die neuen Flavors ausgewählt werden. In reduziertem Rahmen existieren die alten Flavors während einer Übergangsphase jedoch weiterhin: Bestehende virtuelle Server laufen unverändert, und für automatisierte Setups sind die alten Flavors via API weiterhin verfügbar.

Diese Übergangsphase dauert noch bis zum 31.08.2022. Skalieren Sie bis zu diesem Datum Ihre bestehenden Server auf einen unserer neuen Flavors. Dies braucht nur wenige Sekunden und lässt sich zum Zeitpunkt Ihrer Wahl durchführen, z.B. wenn Sie Ihre Server zum Einspielen von Security-Patches ohnehin neu starten. Ihre Server, die noch einen der alten Flavors nutzen, sind im Cloud Control Panel mit einem gelben Icon markiert.

Passen Sie bis zum 31.08.2022 auch automatisierte Setups an, so dass diese nur noch unsere neuen Flavors verwenden. Im Falle des Docker Machine Driver können Sie entweder explizit einen neuen Flavor spezifizieren oder das neuste Release verwenden, bei welchem ein neuer Default-Wert hinterlegt ist. Beim Rancher UI Driver stellen Sie bitte sicher, dass alle Node-Templates unter "GLOBAL APPS > Cluster Management > RKE1 Configuration > Node Templates" einen der neuen Flavors verwenden. Dasselbe gilt für Terraform-Konfigurationen und Ansible Playbooks.

Aktuelle Hardware als Basis

Ein bedeutender Vorteil bei der Nutzung von Cloud-Services besteht darin, dass sich der Cloud-Anbieter um die Hardware kümmert. Neben der Wartung und Fehlerbehebung gehört dazu auch die laufende Evaluation und Beschaffung neuer Hardware. Bei cloudscale.ch setzen wir hier schon länger auf AMD-basierte Hardware, aufgrund der hohen Zahl von PCIe-Lanes z.B. bei unseren Storage-Hosts mit NVMe-SSDs.

Im Hinblick auf die Lancierung unserer "Plus"-Flavors mit dedizierten Cores hatten wir auch bei unseren Compute-Hosts AMD-CPUs eingeführt, und ihr Anteil stieg seither kontinuierlich an. Die bisherigen Intel-basierten Compute-Hosts nehmen wir nun ausser Betrieb. Virtuelle Server, die noch mit Intel-CPUs laufen (erkennbar z.B. in /proc/cpuinfo), werden daher automatisch auf einen unserer aktuellen und leistungsfähigen AMD-Compute-Hosts migriert, sobald Sie sie auf einen der neuen Flavors skalieren.

Weitere Vorteile

In Bezug auf den Preis profitieren Sie schon jetzt ganz automatisch: Wo die neuen Flavors günstiger sind als die alten Flavors mit vergleichbarer Ausstattung waren, wenden wir den tieferen Preis seit dem 01.07.2022 auch auf bestehende Server mit alten Flavors an. Dennoch gibt es noch mehr Gründe, jetzt zu skalieren: Der neue Flex-4-1 beispielsweise bietet bei gleichem Preis doppelt so viel Memory wie der alte Flex-2, und der neue Flex-16-8 kommt mit 8 statt den 6 vCPUs des alten Flex-16.

Bei vielen Workloads ergibt sich ein zusätzliches Sparpotenzial, denn dank den neuen "Memory-optimized" und "CPU-optimized" Flavors können Sie Ihre Server nun noch passgenauer auf Ihren spezifischen Bedarf anpassen, ohne für brachliegende Ressourcen zu bezahlen. Oder nutzen Sie die Gelegenheit um zu testen, wie Ihre Applikation bei einem Wechsel von "Flex" zu "Plus" (oder umgekehrt) performt.

Bitte beachten Sie, dass wir die alten Flavors (mit lediglich einer Zahl im Namen) nur noch bis zum 31.08.2022 weiter betreiben. Skalieren Sie bestehende Server bis zu diesem Termin auf einen beliebigen unserer neuen Flavors (mit zwei Zahlen im Namen) – so stellen Sie nicht bloss den reibungslosen Weiterbetrieb sicher, sondern profitieren auch von möglichen Verbesserungen bei Performance und Kosteneffizienz Ihrer Server. Die gleichen Vorteile geniessen Sie natürlich auch mit automatisierten Setups; passen Sie hierzu Ihr Tooling bis am 31.08.2022 auf die neuen Compute Flavors an.

Bereit, wenn Sie es sind!
Ihr cloudscale.ch-Team

Die Anwendungsfälle von Cloud-Servern sind so individuell wie unsere Kunden. Von Beginn weg hatten wir bei cloudscale.ch deshalb Flavors in den verschiedensten Grössen im Angebot. Und anders als bei eigenen, physischen Servern können Sie Ihre virtuellen Server bei uns jederzeit im Handumdrehen skalieren – je nach aktuellem Bedarf.

Ab sofort stehen Ihnen zusätzliche Compute Flavors mit unterschiedlichen Memory/CPU-Verhältnissen zur Verfügung. So können Sie für rechenintensive Workloads (wie z.B. Batch-Verarbeitungen) viel CPU-Leistung buchen, ohne gleichzeitig für ungenutztes Memory zu bezahlen. Für andere Anwendungen wiederum, wie gewisse Datenbank-Setups oder das Ausliefern von statischen Files, kann es sich lohnen, wenn alle benötigten Daten im Memory gehalten werden; wählen Sie in einem solchen Fall einen Flavor mit relativ viel Memory im Verhältnis zur Anzahl vCPUs bzw. dedicated Cores.

Details zu den neuen Compute Flavors

Das Beste vorweg: Unsere neuen Compute Flavors sind in den meisten Fällen deutlich günstiger als die bisherigen Flavors mit vergleichbarer Ausstattung. Und dank der breiteren Auswahl an Compute Flavors, welche den Bedarf verschiedenster Use-Cases noch besser abdeckt, lassen sich die Kosten für Ihre virtuellen Server weiter optimieren.

Die gewohnten Flavor-Bezeichnungen "Flex" (shared vCPUs) und "Plus" (dedicated Cores) bleiben erhalten. Sie setzen sich neu einheitlich nach dem Schema Flex-<Memory>-<vCPUs> bzw. Plus-<Memory>-<Cores> zusammen, was bereits auf den ersten Blick Klarheit bzgl. Spezifikation des jeweiligen Compute Flavors schafft. Wir sind aber noch einen Schritt weitergegangen und haben uns für ein rein lineares Preismodell entschieden:

• Unabhängig ob Flex oder Plus kosten 4 GB Memory neu CHF 0.5 pro Tag.
• Für die Rechenleistung kommen bei Flex-Flavors pro vCPU CHF 0.5 pro Tag dazu, bei Plus-Flavors pro dedicated Core CHF 1 pro Tag.

Ein "Flex-4-2" mit 4 GB Memory (CHF 0.5) und 2 vCPUs (CHF 1) kostet demzufolge CHF 1.5 pro Tag, ein "Plus-32-4" mit 32 GB Memory (CHF 4) und 4 dedicated Cores (CHF 4) entsprechend CHF 8 pro Tag. Zur besseren Verständlichkeit weisen wir die Preise wie bisher pro Tag bzw. 24 Stunden aus. Selbstverständlich profitieren Sie jedoch weiterhin von sekundengenauer Abrechnung Ihrer Cloud-Services.

Skalieren Sie ganz einfach auf die neuen Flavors

Unsere neuen Compute Flavors stehen Ihnen ab sofort im Cloud Control Panel und via API zur Verfügung. Bitte beachten Sie beim Skalieren bestehender Server, dass für unsere neuen Flavors nur noch CPUs von AMD zum Einsatz kommen; dadurch können sich im Server sichtbare Details (z.B. in /proc/cpuinfo) ändern.

Wo die neuen Flavors günstiger sind als der entsprechende alte Flavor mit vergleichbarer Ausstattung, wenden wir den tieferen Preis bereits auf den alten Flavor an – so profitieren Sie auch dann, wenn Sie bestehende Server nicht sogleich auf einen neuen Flavor skalieren können.

Via unsere API können während einer Übergangsphase bis zum 31.08.2022 auch noch Server mit alten Flavors gestartet werden. So funktionieren automatisierte Setups, z.B. in Ansible und Terraform, vorläufig unverändert weiter und Sie können diese in Ruhe anpassen. Ein reines "Umbenennen" der Flavors ist hingegen bewusst nicht vorgesehen – würde unsere API für einen bestehenden Server statt "Flex-4" plötzlich "Flex-4-2" zurückliefern, könnten Tools wie Terraform unerwartet einen Handlungsbedarf erkennen. Für Nutzer unseres Docker Machine Driver und Rancher UI Driver werden wir in den nächsten Tagen ein Update publizieren, das an unsere neuen Flavors angepasst ist.

Egal, was für einen Anwendungsfall Sie haben: ein Cloud-Server eignet sich immer, denn er lässt sich jederzeit an Ihren aktuellen Bedarf anpassen. Neu geniessen Sie diese Flexibilität bei cloudscale.ch auch dann, wenn Ihre Anwendung besonders Memory- oder CPU-lastig ist – mit unseren neuen Flavors buchen Sie exakt, was Sie benötigen, und profitieren erst noch von unserer neuen und besseren Preisstruktur.

Der richtige Flavor für jeden Geschmack!
Ihr cloudscale.ch-Team

Aussensicht auf unsere DNS-Server

Die autoritativen Nameserver von cloudscale.ch sind für unsere Kunden in verschiedenen Situationen wichtig. Sie ermöglichen es zum Beispiel, dass unsere eigenen Services gefunden und genutzt werden können. Dazu gehört das Aufrufen unserer Website und des Cloud Control Panels via Browser, aber auch das Senden von Requests an unsere API aus kundenseitigen Tools heraus. Zudem müssen die Domain-Namen unserer Object Storages zu IP-Adressen aufgelöst werden, nicht zuletzt auch für Besucher von Dritt-Websites, wenn dort statische Inhalte aus unseren Object Storages eingebunden sind. Darüber hinaus beantworten unsere Nameserver sog. "Reverse-Lookups": für ihre virtuellen Server und Floating IPs können unsere Kunden einen Reverse-DNS-Namen (PTR-Record) festlegen, der dann via DNS publiziert wird und bei unseren Nameservern angefragt werden kann.

Wird eine DNS-Anfrage zu einer unserer IP-Adressen oder Domains gemacht, so bringt der DNS-Client (ausgehend von der sog. "Root-Zone" und entlang der DNS-Hierarchie) zuerst unsere Nameserver in Erfahrung, und fragt diese dann nach der benötigten Information. Derzeit haben wir drei öffentliche Nameserver: Den ns1.cloudscale.ch betreiben wir an unserem Cloud-Standort "RMA" in Rümlang/ZH und den ns2.cloudscale.ch am Standort "LPG" in Lupfig/AG. Zum Schutz unserer Cloud-Standorte vor Ausfällen haben wir eine Vielzahl von Massnahmen getroffen, unter anderem Redundanz bei Internet-Anbindungen und Hardware. Trotzdem betreiben wir zusätzlich noch einen ns3.cloudscale.ch ausserhalb unserer eigenen Infrastruktur. Die drei Nameserver sind komplett unabhängig voneinander und können DNS-Anfragen selbständig beantworten, ohne auf eine zentrale Komponente wie eine gemeinsame Datenbank zuzugreifen.

Versteckte Kontroll-Infrastruktur

Massgebende Datenquelle für unsere öffentlichen Nameserver ist ein internes, aus dem Internet nicht erreichbares DNS-Setup. Auch dieses ist geo-redundant aufgebaut und repliziert laufend seinen Datenstand zwischen unseren beiden Cloud-Standorten. Änderungen an DNS-Einträgen werden in einem ersten Schritt in dieses interne DNS-Setup eingespeist. Ein spezieller Kontroll-Service prüft dann mehrmals pro Minute, ob neue oder geänderte Einträge vorhanden sind, und stösst wo nötig Zonen-Transfers an, woraufhin die öffentlichen Nameserver ihre Kopie der Daten auf den neusten Stand bringen. Änderungen von DNS-Einträgen – der häufigste Fall sind neue Reverse-DNS-Einträge aus dem Cloud Control Panel – werden so in der Regel innert lediglich 10 Sekunden aus dem Internet sichtbar.

Bewährte Technik

Das DNS-Protokoll an sich ist bereits in gewissem Mass auf Fehlertoleranz hin ausgelegt; so ist es üblich (und in gewissen Fällen zwingend), für eine Zone wie z.B. eine Domain zwei oder mehr autoritative Nameserver zu bestimmen. Erhält ein DNS-Client auf eine Anfrage keine Antwort, versucht er es kurz darauf automatisch bei einem anderen dieser Nameserver nochmals. Dennoch kann eine solche Verzögerung unerwünschte Effekte haben. Für unser DNS-Setup bei cloudscale.ch setzen wir daher nicht nur auf redundant ausgelegte physische Infrastruktur, sondern auch auf bewährte Software-Komponenten und Konfigurationen, um Ausfälle wenn immer möglich zu vermeiden. Und nicht zuletzt werden bei uns auch die am DNS beteiligten Systeme genauestens überwacht, damit wir bei Bedarf zeitnah eingreifen können.

Übrigens: Wenn Sie beim Erstellen eines virtuellen Servers für den Namen dieses Servers einen vollständigen Domain-Namen (sog. "Fully Qualified Domain Name" bzw. FQDN) angeben, wird dieser automatisch in unserem DNS-Setup als Reverse-DNS-Eintrag zu den IP-Adressen dieses Servers (IPv4 und ggf. IPv6) erfasst; Floating IPs übernehmen den Reverse DNS des virtuellen Servers, welchem sie initial zugewiesen werden. Den Reverse DNS von Servern und Floating IPs können Sie jederzeit anpassen, damit diese "spiegelbildlich" zu den DNS-Einträgen in Ihrer eigenen Domain passen.

Auch über Web- und Mail-Adressen hinaus ist das Domain Name System praktisch überall involviert. Für uns bei cloudscale.ch ist es wichtig, dass die DNS-Auflösung unserer Domains und IP-Adressen zuverlässig funktioniert, denn nur so können unsere Kunden via Cloud Control Panel und API ihre Cloud-Ressourcen verwalten sowie auf die Object Storages zugreifen. Mit einem sorgfältig erarbeiteten, geo-redundanten DNS-Setup ohne "Single Point of Failure" tragen wir dazu bei, dass die Nutzung unserer Services nicht nur leicht, sondern auch problemlos gelingt.

Dafür stehen wir mit unserem (Domain-)Namen!
Ihr cloudscale.ch-Team

Informationen sind heute wichtiger denn je. Parallel dazu erhält auch der Schutz von Informationen immer mehr Aufmerksamkeit. Damit steigt die Bedeutung von Normen wie der ISO 27001, die verschiedene Aspekte rund um Informationssicherheit abdeckt. Vielen unserer Kunden ist eine Zertifizierung nach ISO 27001 wichtig, und zwar nicht nur für ausgewählte Dienstleister oder Rechenzentren, sondern für die ganze Lieferkette, die in die Verarbeitung von Daten involviert ist.

cloudscale.ch hat sich deshalb bereits im Jahr 2019 nach ISO 27001 zertifizieren lassen und sich damit zu regelmässig wiederkehrenden Audits verpflichtet. Indem wir kürzlich das "Rezertifizierungs-Audit" erfolgreich bestanden haben, konnte unser Zertifikat nahtlos erneuert werden. Das aktuelle, bis 2025 gültige Zertifikat können Sie auf unserer Website einsehen und für Ihre Unterlagen herunterladen.

Zusätzlich zur universell anwendbaren Norm ISO/IEC 27001:2013 haben wir uns wiederum auch nach den Normen ISO/IEC 27017:2015 und 27018:2019 auditieren lassen. Diese zwei Normen sind als Erweiterung von ISO 27001 aufgebaut und definieren ergänzende Controls, die speziell bei Cloud-Services und bei der Verarbeitung personenbezogener Daten in Public Clouds relevant sind.

Kontinuierliche Verbesserung als integraler Bestandteil

Erst vor Kurzem konnten wir bekannt geben, dass bei Bedarf ein ISAE-3000-Bericht verfügbar ist, welcher sich ebenfalls mit Informationssicherheit befasst. Diese zeitliche Nähe ist zufällig entstanden. Dass das Thema bei uns stets präsent ist, ist jedoch keineswegs ein Zufall: Obwohl ISO-27001-Zertifikate für 3 Jahre gültig sind, fordert die Norm jährliche Audits durch die akkreditierte Zertifizierungsstelle. Auf die Erteilung des Zertifikats folgen dabei zwei sog. "Überwachungs-Audits" und anschliessend ein umfassenderes "Rezertifizierungs-Audit" für die Erneuerung des Zertifikats.

Hinzu kommen die internen Audits, die ebenfalls jährlich durchgeführt werden müssen. Für eine Zertifizierung reicht es jedoch nicht, wenn die geprüften Prozesse im Zeitpunkt der Audits den Anforderungen der Norm entsprechen; vielmehr müssen auch die Prozesse selbst auf eine kontinuierliche, weitere Verbesserung hin ausgerichtet sein.

Nützliche Features für erhöhte Sicherheit

Mit cloudscale.ch wählen Sie einen Cloud-Anbieter, der Datenschutz und Informationssicherheit sehr ernst nimmt und dies auch mittels unabhängiger Audits überprüfen lässt. Wie einleitend erwähnt muss Informationssicherheit jedoch auf allen Stufen umgesetzt werden. Mit einer Reihe von Features unterstützen wir unsere Kunden dabei, auch in ihrem eigenen Verantwortungsbereich die Sicherheit ihrer Daten zu erhöhen.

Dazu gehören die verschiedenen Möglichkeiten zur Zusammenarbeit in unserem Cloud Control Panel – so nutzen Sie auch in einem Unternehmenskontext Cloud-Services, ohne dabei Accounts und Passwörter teilen zu müssen. Mit abgestuften Berechtigungen pro Projekt und der Nutzung von 2-Faktor-Authentifizierung (2FA) erhöhen Sie den Schutz zusätzlich. Und falls Sie bereits einen "OpenID Connect"-kompatiblen Identity Provider wie Keycloak oder ZITADEL einsetzen, können Sie zudem beim Login in unser Cloud Control Panel von Single Sign-On profitieren. Damit haben Sie nicht nur den Login-Prozess unter Ihrer eigenen Kontrolle, sondern erhöhen gleichzeitig auch den Komfort für Ihre Mitarbeitenden.

Normen, Prozesse und Audits werden gelegentlich als "trocken" empfunden. Informationssicherheit entsteht jedoch nicht auf dem Papier – sie muss im Alltag gelebt werden. Dass wir bei cloudscale.ch am Ball bleiben, durften wir beim kürzlichen Rezertifizierungs-Audit nach ISO 27001, 27017 und 27018 einmal mehr unter Beweis stellen.

Vertrauen verpflichtet!
Ihr cloudscale.ch-Team

Images als Basis für neue Cloud-Server

Damit neue Cloud-Server sofort bereitstehen, wird das Betriebssystem nicht manuell (z.B. ab DVD) installiert; vielmehr wird das root-Volume beim Launch eines neuen Cloud-Servers mit einem Image vorbefüllt und diese "Musterinstallation" dann beim ersten Bootvorgang weiter konfiguriert.

Schon seit längerem können Sie bei cloudscale.ch auch eigene Images importieren und nutzen. Damit erstellen Sie im Handumdrehen virtuelle Server mit einem anderen als den von uns bereitgestellten Betriebssystemen oder mit Software und Konfigurationen, die ganz auf Ihre Bedürfnisse abgestimmt sind. Wenn bei Images von Distributions- oder Drittanbietern mehrere Dateien zur Auswahl stehen, wurde oft eine davon speziell für OpenStack-Umgebungen wie bei cloudscale.ch optimiert.

Verwaltung von Custom Images im Cloud Control Panel

Ab sofort ist das Management solcher "Custom Images" auch in unserem webbasierten Cloud Control Panel möglich. Selbst wenn Sie unsere API, das cloudscale.ch CLI oder die von uns unterstützten DevOps-Tools wie Terraform und Ansible bisher nicht benutzen, können Sie nun Ihre eigenen Images bei cloudscale.ch importieren, um auf dieser Basis einen oder mehrere virtuelle Server zu starten. Neu können Sie zudem Images direkt im QCOW2-Format importieren – ein vorgängiges Umwandeln zu RAW ist nicht nötig. Von dieser Vereinfachung profitieren Sie natürlich auch, wenn Sie Images wie bisher via API importieren.

Wir empfehlen Ihnen, auch bei Ihren eigenen Images cloud-init zu benutzen. Damit werden beim Bootvorgang von virtuellen Servern viele Einstellungen automatisiert vorgenommen, z.B. in Bezug auf Name und IP-Adresse des Servers. Als "User Data" können Sie auch viele weitere Optionen direkt beim Erstellen des Servers an cloud-init übergeben. Pro Custom Image können Sie zudem individuell festlegen, wie unser System mit den "User Data" umgehen soll – das ist insbesondere dann von Bedeutung, wenn Ihr Image nicht auf cloud-init, sondern auf Ignition setzt, welches einen ähnlichen Zweck verfolgt. Weitere Details hierzu finden Sie in der Dokumentation.

Ob Sie sich ein massgeschneidertes Image mit Ihren bevorzugten Tools und Settings zusammenstellen oder ein fertiges Gesamtpaket von einem Drittanbieter einsetzen möchten: Die Verwaltung und Nutzung Ihrer Custom Images bei cloudscale.ch ist jetzt noch einfacher.

Für die richtige Basis,
Ihr cloudscale.ch-Team

Wer den Begriff "Revision" hört, denkt vermutlich zuerst an Buchhaltung. Eine korrekte Bilanz allein reicht jedoch oft nicht; auch andere Prozesse – z.B. rund um die IT – können für ein Unternehmen überlebenswichtig sein und deshalb in die Revision bzw. betriebswirtschaftliche Berichterstattung mit eingeschlossen werden. Hier bietet sich ein Bericht nach ISAE 3000 an.

Die Abkürzung "ISAE 3000" steht für "International Standard on Assurance Engagements 3000", ein von der International Federation of Accountants (IFAC) veröffentlichter internationaler Prüfungsstandard. Der Standard schafft einen einheitlichen Rahmen für "betriebswirtschaftliche Prüfungen, die keine Prüfungen oder prüferische Durchsichten vergangenheitsorientierter Finanzinformationen sind". Dabei prüft ein unabhängiger Wirtschaftsprüfer das interne Kontrollsystem eines Unternehmens bzw. bestimmten Bereichs und erstellt einen entsprechenden Bericht.

Während sich ISO 27001 spezifisch mit Informationssicherheit befasst und über 100 damit zusammenhängende Controls vorgibt, macht ISAE 3000 grundsätzlich keine Vorgaben in Bezug auf die Controls bzw. das interne Kontrollsystem. Was tatsächlich Gegenstand einer Prüfung nach ISAE 3000 war, wird im resultierenden Prüfungsbericht aber detailliert ausgewiesen – dies erlaubt dem Leser somit auch eine Beurteilung, ob die geprüften Controls den eigenen Anforderungen genügen. Im Vergleich dazu bescheinigt ein Zertifikat nach ISO 27001 zwar die Einhaltung der Norm in ihrer ganzen Breite, geht jedoch nicht weiter auf die Details der Implementierung ein.

Vorgehen bei einem Audit nach ISAE 3000

Gedanklicher Ausgangspunkt ist ein Worst-Case-Szenario, z.B. "Ein Einbrecher veröffentlicht geheime Daten". Bis hin zum guten Gefühl, dass dieser Worst Case aller Wahrscheinlichkeit nach nicht eintreten kann, sind dann mehrere Schritte zu gehen. Ist das Risiko erst identifiziert, wird zuerst ein Ziel zu dessen Verhinderung formuliert ("Unbefugte haben keinen Zugriff zu geheimen Daten"). Zum Erreichen des Ziels wiederum werden spezifische "Controls" definiert ("Der Serverraum ist immer abgeschlossen", "Die Daten werden verschlüsselt").

Bei einem Audit nach ISAE 3000 beurteilt ein Auditor drei Stufen: Scheinen die Controls angemessen, so dass das Ziel damit erreicht wird? Waren die Controls tatsächlich implementiert? Waren sie auch wirksam?

Indem der Auditor diese Fragen für alle wichtigen Prozesse und Ziele eines Unternehmens beantwortet, kann er zuhanden der Unternehmensspitze eine Aussage treffen, ob die Ziele erreicht wurden. Natürlich ist auch er nicht allwissend; mit einer rationalen Beurteilung und einer Prüfung von genügend Stichproben wird dennoch eine ausreichend hohe Sicherheit erreicht, dass das Urteil tatsächlich der (im Endeffekt immer unbekannten) Wirklichkeit entspricht.

Berichterstattung über Unternehmensgrenzen hinweg

Lücken bei der Prüfung des eigenen Unternehmens entstehen zwangsläufig dort, wo ein Prozess ausgelagert wurde, z.B. wenn Cloud-Services von cloudscale.ch genutzt werden, statt eigene Server und Rechenzentren zu betreiben. In diesem Fall liegt es nahe, dass sich der Outsourcing-Partner separat auditieren lässt. Mit dessen Prüfungsbericht kann der Auditor dann die Lücken in seiner eigenen Prüfung schliessen und erhält so wieder ein Gesamtbild über die Prozesse des Unternehmens.

Bei cloudscale.ch steht für unsere Kunden ab sofort ein solcher Prüfungsbericht nach dem Standard ISAE 3000 bereit. Gegen einen Beitrag an die Kosten für die Erstellung des Berichts stellen wir auf Anfrage gerne eine Kopie zur Verfügung. Aufgrund der speziellen Natur solcher Berichte ist dies vor allem für jene Kunden relevant, die selbst nach einem Standard wie ISAE 3000 auditiert werden und die erwähnten Lücken einer rein internen Betrachtung schliessen möchten oder müssen.

Keine Überraschungen beim Inhalt

Während ein Unternehmen für seine internen Prozesse die Ziele und Controls selbst definieren kann, muss ein Dienstleister wie cloudscale.ch hier eine Auswahl treffen. Diese Auswahl soll die typischen Bedürfnisse von vielen Kunden abdecken, kann aber nicht auf jeden Einzelfall eingehen. Während das Format eines ISAE-3000-Berichts für uns bei cloudscale.ch völlig neu war, fiel die Wahl bei Zielen und Controls entsprechend auf Altbekanntes: Seit jeher orientieren wir uns an den Bedürfnissen unserer Kunden und treffen diejenigen Massnahmen, von denen wir überzeugt sind, dass sie für unsere Kunden relevant sind.

Dazu gehört so Selbstverständliches wie Zutrittsbeschränkungen zu unseren Serversystemen oder die kontinuierliche Schulung unserer Mitarbeiter. Dazu gehören aber auch Features wie die Datenverschlüsselung "at rest" oder die Möglichkeit von voneinander getrennten privaten Netzen, über die wir bereits berichtet haben. Neu ist die unabhängige, externe Prüfung und die formelle Berichterstattung; bewährt sind die konkreten Massnahmen, mit denen wir zur Sicherheit und Zuverlässigkeit Ihrer Cloud-Ressourcen beitragen.

Unsere Kunden kennen und schätzen den technischen Fokus, den wir bei cloudscale.ch schon immer hatten und uns bis heute erhalten konnten. Die erstmalige Erarbeitung eines eigenen ISAE-3000-Berichts war für uns eine ganz neue Erfahrung. Nachdem wir uns darauf eingelassen haben, ist es ein doppelt gutes Gefühl: Das kontinuierlich aufgebaute, technische Fundament hält auch einem Audit aus betriebswirtschaftlicher Sicht stand. Und – noch viel wichtiger – wir können unsere Kunden bei Bedarf mit dem Bericht eines unabhängigen Prüfers bei der Einhaltung ihrer eigenen Vorgaben unterstützen.

Ziel erreicht!
Ihr cloudscale.ch-Team

cloudscale.ch nutzen – allein oder zusammen

Andrea ist überzeugte Open-Source-Nutzerin. Regelmässig findet und testet sie neue Tools für alle möglichen Aufgaben. Um immer ein frisches System zu haben, das sie wenn nötig auch "verbasteln" und anschliessend wieder löschen kann, nutzt sie cloudscale.ch. So kann sie mit wenigen Klicks virtuelle Server starten und aus einer Auswahl der beliebtesten Linux-Distributionen wählen – je nach Tool, das sie gerade anschauen möchte.

Beruflich leitet Andrea die IT der Enjoy AG, die eine Online-Plattform für Restaurants und Lieferdienste betreibt. Die Plattform lief bisher auf einem physischen Server, den die Enjoy AG bei einem Housing-Anbieter eingestellt hat. Hinzu kommt noch ein Server vor Ort im Büro unter anderem für das CRM. Beide Server sind von der Leistung her eigentlich überdimensioniert, sind aber in die Jahre gekommen und Andrea befürchtet, dass ein Hardware-Defekt zu einem längeren Geschäftsstillstand führen könnte. Einfach neue Geräte zu kaufen ist für Andrea jedoch keine Option, denn damit würde die Sorge um die fehlende Redundanz nicht gelöst.

Vielmehr möchte Andrea die Vorteile der Cloud nutzen und statt einem einzelnen, zu grossen Server ein geo-redundantes Failover-Setup aufbauen, das mit dem Wachstum ihrer Plattform skaliert. Damit sie und ihre Mitarbeiter gemeinsam mit dem neuen Cloud-Setup arbeiten können, erstellt Andrea im Cloud Control Panel von cloudscale.ch eine neue Organization "Enjoy AG". Mit nur einem Login hat sie so zwei komplett voneinander getrennte Bereiche – einen privat, einen geschäftlich.

Organization Members einladen und verwalten

Anschliessend erstellt Andrea für ihre Kollegen Invite-Links, so dass diese mit ihren eigenen, persönlichen Accounts der Organization "Enjoy AG" beitreten können. Von ihren Mitarbeitern sind – nicht ganz überraschend – Jeremy und Patricia ebenfalls schon Kunden bei cloudscale.ch; die anderen legen via "Signup" schnell und kostenlos einen neuen Account an. Unter "Members" sieht Andrea laufend, welche Kollegen den Invite-Link eingelöst haben und der Organization beigetreten sind. Ganz besonders achtet sie auf den 2FA-Status und bittet diejenigen, die das Feature noch nicht aktiviert haben, dies noch zu tun.

Unter "Projects" erstellt Andrea vorerst drei Projekte namens "CRM", "Test" und "Prod", um die neuen Cloud-Server sinnvoll zu gruppieren. Sollten irgendwann weitere Projekte hinzukommen, kann sie diese jederzeit ergänzen. Nun könnte sie für jedes Projekt die passenden Mitarbeiter als "Project Members" hinzufügen und festlegen, ob diese Person im Projekt nur lesen oder auch Änderungen vornehmen darf, also z.B. Cloud-Server erstellen oder löschen. Um sich das Leben leichter zu machen, entscheidet sich Andrea jedoch für die Nutzung von "Teams". In Anlehnung an die etablierte Struktur der Enjoy AG erstellt sie die Teams mit ihren "Team Members" und fügt anschliessend die Teams als Ganzes zu den Projekten hinzu. Im Team "IntOps" macht sie zudem Patricia zum "Team Leader": So kann Patricia die Team Members zukünftig selber verwalten und z.B. Kollegen aufnehmen, die in ihr Team wechseln.

Spezialisten als External Collaborators einbinden

Auf Wunsch der Marketing-Abteilung kommt bald das Projekt "Landing Pages" hinzu: Susanna ist Freelancerin und soll für die Enjoy AG auf einem separaten Cloud-Server Webseiten für verschiedene Marketing-Kampagnen pflegen. Für Andrea ist klar, dass Susanna hierzu vollen Zugriff auf die entsprechenden Cloud-Ressourcen braucht, gleichzeitig möchte sie aber nicht, dass Susanna all die anderen Projekte und Beteiligten im Cloud Control Panel sieht. Sie erstellt daher einen Invite-Link für einen "External Collaborator", den sie Susanna zukommen lässt. Wie zuvor könnte Andrea nun ein separates Team erstellen mit Susanna und den internen Kollegen als Team Members; in diesem Fall scheint es ihr jedoch übersichtlicher, wenn sie dem Projekt "Landing Pages" einfach das bestehende "Platform"-Team sowie zusätzlich Susanna als Project Members zuweist.

Partnerschaft zweier Organizations für klare Zuständigkeiten

Sven ist Andreas Ansprechpartner bei der Coders GmbH. Er und sein Team haben die Online-Plattform für die Enjoy AG entwickelt und helfen auch bei der Wartung und Fehlersuche im laufenden Betrieb. Schon auf dem alten Server hatten die Entwickler von Coders einen SSH-Zugang, aber ohne die Sicht "von aussen" auf den Server konnten sie manchmal nur eingeschränkt helfen. Mit dem neuen Cloud-Setup soll das nun anders werden. Auch die Coders GmbH nutzt intern bereits cloudscale.ch, und alle Mitarbeiter haben persönliche Accounts. Andrea möchte jedoch nicht jeden einzelnen von ihnen als External Collaborator einladen, und vereinbart deshalb mit Sven eine "Partnership" der beiden Organizations. So kann sie ihr Projekt "Prod" für die Coders GmbH freigeben, und Sven als Superuser in der Organization "Coders GmbH" kann selbständig deren Teams und Members zu diesem Projekt hinzufügen.

Leider verlässt kurz darauf Oliver die Coders GmbH: Er möchte sich eine Auszeit in einem Bergdorf nehmen und in Ruhe ein paar private Projekte vorantreiben, die ihm wichtig sind. Seinen cloudscale.ch-Account hatte er – nebst der Arbeit bei Coders – auch für diese Projekte genutzt, und möchte ihn deshalb behalten. Indem Sven Oliver's Account einfach aus der Organization und damit auch aus dem "Prod"-Projekt der Enjoy AG entfernt, lässt sich der Wunsch erfüllen.

Dank etwas Glück findet Sven mit Christina fast nahtlos einen Ersatz. Gleichzeitig möchte er Thomas, der bei Coders seine Ausbildung absolviert, schrittweise in die Zusammenarbeit mit der Enjoy AG einbinden. Für den Moment reicht für Thomas – anders als bei den übrigen Mitarbeitern – ein reiner Lesezugriff. Sven ist froh, dass er all diese administrativen Anpassungen selbständig umsetzen kann, ohne Andrea damit zu belästigen.

Inzwischen ist das neue Release der Online-Plattform fast fertig, und sowohl bei der Enjoy AG wie auch bei der Coders GmbH ist die Freude gross, den Restaurants und Lieferdiensten viele neue Features zu präsentieren. Auch die Landing Pages der neuen Kampagne stehen bereit. Indem jeder den Zugriff hat, den er für seinen Beitrag braucht, steht einem erfolgreichen Deployment nichts mehr im Weg. Und nach getaner Arbeit von ganz unterschiedlichen Arbeitsplätzen aus trifft man sich dann vielleicht noch, um gemeinsam auf die gute Zusammenarbeit anzustossen.

Auf gute Zusammenarbeit!
Ihr cloudscale.ch-Team

PS: Damit die Administration der Organization nicht alleine von ihr abhängt, plant Andrea, ihren Kollegen Jeremy ebenfalls zum Superuser zu machen – so können sie einander z.B. bei Abwesenheiten vertreten. Im Blog von cloudscale.ch hat sie die folgende Übersicht gefunden, die sie Jeremy für den schnellen Einstieg weiterleitet:

Kollaboration – die zentralen Begriffe

Projekte: In Projekten lassen sich Cloud-Ressourcen gruppieren, z.B. für separate Test- und Produktions-Umgebungen. Zugriffsrechte – entweder nur lesend oder auch für Änderungen – können für jedes Projekt separat definiert werden.

Organization: Eine Organization repräsentiert ein Unternehmen, eine Abteilung oder eine sonstige Gruppierung von Personen zur Zusammenarbeit an Cloud-Ressourcen. Organizations haben einen separaten Rahmenvertrag und ein separates Guthaben, damit eignen sie sich auch zur vertraglichen Abgrenzung der Cloud-Ressourcen von anderen Accounts bzw. Organizations.

Organization Member: Organization Members können in Projekten der Organization mitarbeiten. Unabhängig von der Berechtigung in den einzelnen Projekten können Organization Members – in Analogie zu Mitarbeitern einer Firma – sehen, welche Projekte, Teams und anderen Members in der Organization existieren.

External Collaborator: Accounts, die in einem oder mehreren Projekten mitarbeiten, aber darüber hinaus keinen Einblick in die Organization erhalten sollen, können als External Collaborators eingeladen werden. Sie sehen nur diese Projekte, nicht aber die übrigen Projekte, Teams und Members der Organization.

Team: Um das Berechtigungs-Management zu vereinfachen, können Accounts – Organization Members und External Collaborators – in Teams zusammengefasst werden. Berechtigungen des Teams gelten automatisch für alle Team Members.

Team Leader: Team Leaders können Organization Members und External Collaborators selbständig als Team Members zum betreffenden Team hinzufügen und daraus entfernen. Team Leaders können im Team zudem weitere Organization Members (nicht jedoch External Collaborators) zu Team Leaders machen und diese Rolle wieder entfernen.

Superuser: Ein Superuser kann alle Aspekte der Organization verwalten. Dazu gehört das Management von Projekten, Teams und Berechtigungen sowie das Einladen und Entfernen von Organization Members und External Collaborators.

Partner Organization: Die Superuser zweier Organizations können eine Partnerschaft vereinbaren und Projekte für die jeweils andere Organization freigeben. Die Superuser in jeder der Partner Organizations verwalten die Zugriffsrechte ihrer jeweils eigenen Organization Members und External Collaborators auf die gemeinsamen Projekte. Wie bei External Collaborators sind nur die freigegebenen Projekte sichtbar, nicht aber die übrigen Projekte, Teams und Members der jeweils anderen Organization.

Projekte mit internen und externen Personen

In Cloud-Projekten arbeiten oft mehrere Personen zusammen. Das Teilen von Benutzer-Accounts birgt jedoch diverse Risiken und Gefahren. Viele Nutzer von cloudscale.ch arbeiten deshalb in sog. "Organizations" zusammen, die z.B. eine Firma oder Abteilung repräsentieren. Alle Organization Members verfügen über persönliche Zugangsdaten und können für ihr Benutzer-Konto die Zwei-Faktor-Authentifizierung (2FA) aktivieren. Die Superuser der Organization bestimmen dabei, welche Organization Members und External Collaborators auf welche Projekte der Organization zugreifen dürfen.

Sobald externe Personen an einem Projekt beteiligt sind, ist oft auch eine zweite Firma oder sonstige Organisation involviert. Hier bietet sich die Nutzung der neuen "Partner Organizations" an: Erteilen Sie einer Partner Organization das Recht, selbständig die passenden Mitarbeiter auf dieses Projekt anzusetzen – ohne dass Sie dabei im Detail wissen müssen, wer dort das benötigte Know-how oder die gewünschte Verfügbarkeit hat. Sie entscheiden bei jeder Freigabe eines Projektes selbst, ob die Partner Organization nur lesend oder auch mit Änderungsrecht Zugriff haben soll.

Partner Organizations: Administration delegieren

Die Verwaltung von Partner Organizations finden Sie im Bereich "Organizations" in unserem Cloud Control Panel. Hier können Sie neue Partnerschaften initiieren sowie bestehende prüfen und ggf. beenden. Eine Partnerschaft bildet ab, dass zwei Organizations sich kennen; sie ist beidseitig und bedeutet für sich genommen noch keinerlei Berechtigung auf Projekte oder Cloud-Ressourcen des jeweils anderen Partners.

Genau so einfach, wie Sie Organization Members, Teams oder External Collaborators zu Ihren Projekten hinzufügen können, können Sie Ihren Projekten jetzt auch Partner Organizations hinzufügen. Damit erlauben Sie den Superusern der jeweiligen Partner Organization, ihrerseits ihren eigenen Organization Members und External Collaborators Zugriffsrechte auf diese Projekte zu vergeben. Diese Zugriffsrechte sind begrenzt auf die Berechtigungsstufe, welche Sie dem Partner auf dem entsprechenden Projekt gewähren. An den Berechtigungen Ihrer Organization Members und External Collaborators können aussenstehende Superuser hingegen nichts verändern (und diese auch nicht einsehen); diese Kontrolle verbleibt ausschliesslich bei Ihnen selbst.

Im umgekehrten Fall, wenn eine Partner Organization eines ihrer Projekte mit Ihrer Organization geteilt hat, können Sie diesem Projekt wie gewohnt eigene Organization Members, Teams und External Collaborators hinzufügen. Gut zu wissen: Eine Weiter-Delegation ist nicht möglich; nur diejenige Organization, welcher das Projekt gehört, kann Partner Organizations zum Projekt hinzufügen.

Durchdachte Details für alle Fälle

Wie auch bei External Collaborators bleiben die Interna Ihrer Organization vor den Personen in Ihren Partner Organizations verborgen: diese sehen nur diejenigen Projekte, die Sie mit ihnen teilen, nicht jedoch andere interne Strukturen wie Projekte, Teams oder potenzielle weitere Partner Organizations. Lediglich bei Änderungen ist im entsprechenden Project Log auch der jeweils handelnde Account sichtbar – so ist die Einhaltung allfälliger Compliance-Vorgaben sichergestellt. Selbstverständlich können Sie Partner Organizations jederzeit wieder von Ihren Projekten entfernen; alle darauf basierenden Zugriffsrechte verfallen dann mit sofortiger Wirkung. Prüfen Sie nach dem Widerrufen einer Berechtigung auch allfällige API-Tokens in den betreffenden Projekten; möglicherweise werden einige davon nicht länger benötigt.

"Partner Organizations" bieten sich typischerweise an, wenn Sie die aktive Mitarbeit von Partnern (wie z.B. Kunden oder Dienstleistern) in Ihren Projekten in Anspruch nehmen, oder falls Sie Ihren Endkunden Lesezugriff gewähren und so die Transparenz erhöhen möchten. Ein Unternehmens-Kontext ist jedoch keine Bedingung: Nutzen Sie Organizations und Partnerschaften auch für Vereine, im Freundeskreis oder überall sonst, wo Sie gemeinsam mit anderen Gruppierungen an einem Cloud-Projekt arbeiten.

Übrigens: Zum Login in unser Cloud Control Panel unterstützen wir nebst E-Mail/Passwort und GitHub auch Ihren eigenen, OpenID-Connect-kompatiblen Identity Provider wie z.B. Keycloak oder ZITADEL. Die Wahl liegt ganz bei Ihnen: Für die erfolgreiche Zusammenarbeit mit Partner Organizations ist es nicht nötig, dass alle Benutzer den gleichen Login-Mechanismus einsetzen.

Mit den Partner Organizations runden wir das Feature-Set rund um die Zusammenarbeit ab: Nebst eigenen Organization Members und einzelnen External Collaborators können Sie nun auch Partnerschaften auf institutioneller Ebene in unserem Cloud Control Panel abbilden. Indem jeder Partner selbst bestimmt, welche seiner Organization Members in der aktuellen Phase der "beste Match" sind, profitiert Ihr Projekt maximal von der Expertise und Verfügbarkeit aller Beteiligten. Und ganz nebenbei minimieren Sie so auch noch den administrativen Overhead.

Auf jeden Fall Ihr Partner,
Ihr cloudscale.ch-Team

In der IT starten Projekte häufig klein. Oft wird dieser Ansatz bewusst gewählt, um mit einem möglichst schlanken Vorgehen bestimmte Hypothesen rasch zu validieren und das Projekt in kurzen Iterationen immer wieder anzupassen. Manchmal sind es aber auch vermeintlich kurzlebige Experimente, die sich gut bewähren und über die Zeit zu einem wichtigen Produkt oder Werkzeug wachsen. Bei cloudscale.ch machen wir es Ihnen besonders leicht: Innert kürzester Zeit und mit wenigen Mausklicks stehen Ihre ersten Cloud-Server bereit, und genauso schnell und einfach lassen sie sich bei Bedarf auch ändern.

Die Erstellung und Verwaltung Ihrer Cloud-Infrastruktur mit Terraform unterstützen wir natürlich ebenso. Doch was bei einem etablierten Projekt für Einheitlichkeit und Effizienz sorgt, würde in der Anfangsphase oft nur unnötigen Overhead bedeuten. Wenn das Projekt dann wächst, wird man irgendwann feststellen, dass sich ein Tool wie Terraform doch gelohnt hätte. Oft genug wird man aber nicht von vorn beginnen wollen, und mit der Import-Funktion für bestehende Ressourcen ist das zum Glück auch nicht nötig.

Bestehende Ressourcen in Terraform importieren

Ausgangspunkt für Terraform ist Ihre Konfiguration: hier definieren Sie alle Ressourcen wie z.B. Cloud-Server, die Sie für Ihr Projekt benötigen, sowie deren Eigenschaften. Nach dem Erstellen dieser Ressourcen merkt sich Terraform im sog. "State", welche der Ressourcen in der realen Welt zu welchen Definitionen gehören. Ändern sich Ihre Vorgaben oder die Wirklichkeit, kann Terraform die Abweichung erkennen und bei einem nächsten terraform apply wieder den gewünschten Zustand herstellen.

Um eine bestehende Ressource bei cloudscale.ch in Ihr Terraform-Setup aufzunehmen, definieren Sie sie zunächst ganz normal in Ihrer Terraform-Config. Anstatt sie dann mit terraform apply neu erstellen zu lassen, verknüpfen Sie Ihre Definition mittels terraform import mit der bereits bestehenden Ressource, die Sie über ihre eindeutige ID spezifizieren. Die nötigen Details für jede Ressource finden Sie in der Dokumentation zu unserem Terraform-Provider. Mit einem anschliessenden terraform plan können Sie prüfen, ob Terraform noch Differenzen zwischen der Definition und der tatsächlichen Ressource erkennt. Passen Sie die Definition ggf. weiter an, bis Terraform keinen Änderungsbedarf mehr feststellt.

Eine Besonderheit gibt es bei SSH-Keys: diese werden einem neu erstellten Cloud-Server via Metadata-Server und Config-Drive bereitgestellt und beim ersten Booten durch cloud-init übernommen. Da sich das Handling von SSH-Keys auf diese Erstkonfiguration beschränkt, kann Terraform sie später nicht von unserer API auslesen und in seinem State ablegen. Für das Importieren von Servern bedeutet dies, dass Sie keine SSH-Keys spezifizieren dürfen – ansonsten würde Terraform in jedem Fall einen Änderungsbedarf feststellen, der zum Löschen und Neuerstellen des Servers führt.

Zusätzliche Werte mit Data Sources

Bei cloudscale.ch können Sie fast alle bestehenden Ressourcen wie oben beschrieben in Ihr Terraform-Setup importieren, die derzeit einzige Ausnahme bilden "Custom Images". Es kann jedoch sein, dass ein Import gar nicht gewünscht ist, z.B. wenn die betreffenden Ressourcen bereits Teil eines anderen Terraform-Setups sind. Um trotzdem auf die Attribute solcher Ressourcen zuzugreifen und sie z.B. in der Definition von weiteren Ressourcen zu verwenden, nutzen Sie "Data Sources".

Über Data Sources stehen Ihnen alle wichtigen Eigenschaften Ihrer Cloud-Ressourcen in Terraform zur Verfügung. So können sich via Terraform verwaltete Server beispielsweise am Flavor eines Servers ausserhalb Ihres Terraform-Setups orientieren, oder für Server in Ihrem Terraform-Setup kann definiert werden, dass sie ein Interface in einem manuell verwalteten privaten Netz haben sollen.

Um auf Data Sources zuzugreifen, stehen Ihnen verschiedene "Arguments" zur Verfügung. Nutzen Sie eines oder mehrere davon, um nach Ihrer gesuchten Ressource zu filtern. Die als Argument nutzbaren Werte sowie weitere "Attributes" der Ressource stehen Ihnen dann zur weiteren Verwendung in Ihrem Terraform-Setup zur Verfügung. Auch für die Nutzung von Data Sources finden Sie alle wichtigen Angaben in unserer Dokumentation.

Anders als herkömmliche Konfigurationsmanagement-Systeme erlaubt Terraform ein automatisiertes Setup Ihrer Infrastruktur ausgehend von der sprichwörtlichen grünen Wiese – ohne dass Sie Dinge wie Server oder Netze bereits vorbereiten müssten. In der Praxis entstehen und wachsen jedoch viele Projekte nicht so, wie man das im Rückblick am besten angepackt hätte. Mit Hilfe von Imports und Data Sources können Sie solche "Legacy"-Ressourcen bei cloudscale.ch nun so in Ihr Terraform-Setup integrieren, als wäre es nie anders gewesen. Vermeiden Sie, beim "Aufräumen" von gewachsenen Setups nochmals von vorn zu beginnen, und nutzen Sie Ihre Energie, um Ihr Projekt weiter voran zu bringen!

Für Ordnung ohne Leerlauf,
Ihr cloudscale.ch-Team

Container-Setups bieten eine Reihe von Vorteilen. Über eine Container-Orchestrierung wie Kubernetes kann dabei u.a. sichergestellt werden, dass zu jeder Zeit die erforderlichen Container gestartet sind. Verlässt dann ein Node den Verbund (sei es für Wartungsarbeiten oder aus einem anderen Grund), kann Kubernetes die betroffenen Container anderswo im Cluster neu starten und so den Soll-Zustand wiederherstellen. Dank dem CSI stehen in so einem Fall auch die persistenten Volumes (PVs) sofort wieder zur Verfügung: via passenden CSI-Treiber werden die benötigten Volumes nicht nur initial auf der darunterliegenden Cloud-Infrastruktur bereitgestellt, sondern auch danach immer am richtigen Node angeschlossen, so dass der Container auf das Volume und dessen Daten zugreifen kann.

Damit ein Container den Speicherplatz eines PV überhaupt nutzen kann, formatiert unser CSI-Treiber das Volume beim Erstellen normalerweise mit ext4 und mountet es dann im Dateisystem des Nodes, von wo aus es dem Container zur Verfügung gestellt wird. Einige Workloads können ihre Daten jedoch nicht in einem Dateisystem speichern, sondern nur auf ganzen Block Devices. Ein solches Beispiel ist Rook: Das Projekt der Cloud Native Computing Foundation kann in einer Kubernetes-Umgebung u.a. einen Storage-Cluster mit Ceph installieren und so einen Speicher-Service für andere Anwendungen bereitstellen. Bei einem Betrieb auf physischer Hardware würde Ceph für die eigentliche Datenablage direkt auf die Festplatten schreiben und statt Partitionen und Dateisystemen sein eigenes, optimiertes Format namens "BlueStore" benutzen. In einer Kubernetes-Umgebung werden die physischen Disks durch PVs ersetzt, die als Raw Block Volumes zur Verfügung stehen müssen.

CSI mit Raw Block Volumes nutzen

Offiziell unterstützt werden Raw Block Volumes in Kubernetes ab Version 1.18; in unserem CSI-Treiber haben wir diese Möglichkeit mit Version 3.1.0 eingeführt. Um ein Raw Block Volume zu erstellen, ergänzen Sie im Persistent Volume Claim (PVC) einfach volumeMode: Block (ansonsten greift der Default von Filesystem) wie im folgenden Beispiel:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: csi-pod-pvc-raw-block
spec:
  volumeMode: Block
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: cloudscale-volume-ssd

In der Pod-Definition wiederum geben Sie mittels volumeDevices den gewünschten Device Path an (anstelle des Mountpoints mit volumeMounts):

apiVersion: v1
kind: Pod
metadata:
  name: my-csi-app-raw-block
spec:
  containers:
    - name: my-frontend
      image: busybox
      volumeDevices:
        - devicePath: /dev/xvda
          name: my-cloudscale-volume
      command: [ "sleep", "1000000" ]
  volumes:
    - name: my-cloudscale-volume
      persistentVolumeClaim:
        claimName: csi-pod-pvc-raw-block

Das Volume, das so auf unserer Cloud-Infrastruktur erstellt wird und auch in unserem Cloud Control Panel oder via API sichtbar ist, wird "eins zu eins" an den jeweiligen Pod durchgereicht und steht diesem vom ersten bis zum letzten Byte zur Verfügung. Damit ist es selbstverständlich auch möglich, innerhalb des Pods eine Verschlüsselung solcher Volumes zu realisieren, z.B. mit LUKS.

Wie alle Volumes bei cloudscale.ch können auch Raw Block Volumes entweder auf NVMe SSDs oder auf unserem Bulk Storage angelegt werden. Und wie gewohnt können Sie auch solche Volumes im laufenden Betrieb vergrössern. Beachten Sie dabei jedoch, dass via CSI-Treiber lediglich die Grösse des Block Device erhöht wird; die Anpassung allfälliger Partitionen und Dateisysteme muss durch den jeweiligen Pod vorgenommen werden.

Verschiedene Use Cases, verschiedene Ansätze

Mit der Unterstützung von Raw Block Volumes eignet sich ein Kubernetes-/CSI-Setup nun auch für Anwendungsfälle, die nicht mit einem rein Datei-basierten persistenten Speicher auskommen. Falls Sie sich für Ceph interessieren und erste Gehversuche damit machen möchten, ist das oben erwähnte Rook ein solches Beispiel. Selbstverständlich gibt es aber auch Gründe, Rook mit Ceph produktiv einzusetzen, z.B. wenn Sie für eine andere Anwendung ein CephFS-Backend benötigen. Achten Sie in diesem Fall darauf, mögliche Single Points of Failure zu vermeiden: Dort wo mehrere Pods (bei Ceph z.B. "mon" oder "osd") eine Redundanz sicherstellen, platzieren Sie diese auf Kubernetes-Nodes, die zueinander in Anti-Affinity stehen – so sind im Fall eines isolierten Hardware-Issues auf einem der physischen Compute-Server nicht mehrere dieser Pods gleichzeitig betroffen.

Ceph wird oft mit einem Replikations-Faktor von 3 eingesetzt, so auch bei unseren eigenen Ceph-Clustern, auf denen die NVMe-SSD- und Bulk-Volumes sowie unser Object Storage basieren. Betreiben Sie auf dieser Infrastruktur Ihr eigenes Ceph-Setup, so bedeutet dies typischerweise, dass jedes darin abgelegte Datenfragment physisch 9-fach gespeichert wird. Wägen Sie für Ihren Use Case individuell ab, wieviel (zusätzliche) Redundanz Sie benötigen bzw. wieviel Overhead Sie in Kauf nehmen möchten. Allenfalls könnte sich z.B. auch ein eigener NFS- oder Datenbank-Server oder alternativ unser Object Storage als zentrale Datenablage für Ihre Applikationen eignen.

Cloud-Infrastruktur und Container-Setups sind das Mittel der Wahl für immer mehr Anwendungsfälle, bieten sie doch ein Maximum an Flexibilität und Skalierbarkeit. Sei es für einen kurzen Test oder für ein produktives HA-Setup: dank der Unterstützung für Raw Block Volumes in unserem CSI-Treiber können Sie diese Vorteile nun noch vielseitiger nutzen. Haben Sie Feedback oder Verbesserungsvorschläge? Wir freuen uns auf Ihre Anregungen via GitHub oder direkt an uns!

Fixfertig formatiert oder roh: Volumes nach Ihrem Geschmack!
Ihr cloudscale.ch-Team

Dank Redundanz auf allen Ebenen merken unsere Kunden von den meisten isolierten Problemen nichts: Ob Kabel, Harddisk oder Load-Balancer, bei einem Ausfall läuft das Gesamtsystem unbeirrt weiter. Selbstverständlich müssen wir solchen Fällen jedoch nachgehen und z.B. die Redundanz wieder herstellen, damit unsere Cloud so zuverlässig bleibt, wie sie ist. Über das Detektieren und Melden defekter Komponenten hinaus erfasst unser Monitoring aber auch Leistungsdaten und das korrekte Funktionieren ganzer Abläufe "end to end", so dass wir einen allfälligen Handlungsbedarf frühzeitig erkennen.

Von Beginn weg setzten wir bei cloudscale.ch auf Zabbix als Dreh- und Angelpunkt für unser Monitoring und Alerting. Dank seiner Vielseitigkeit und Anpassbarkeit konnten wir damit die meisten Monitoring-Bedürfnisse – die im Laufe der Zeit immer zahlreicher und komplexer wurden – abdecken. In Ergänzung zu unserem internen Zabbix nahmen wir schon früh auch ein externes Monitoring hinzu. Damit konnten wir einerseits zusätzliche Use-Cases abbilden und auch die Nutzerperspektive besser einbeziehen. Andererseits decken wir so Fälle ab, in denen unser eigenes Monitoring von einem Problem mitbetroffen ist und/oder die generierten Alerts aus irgendeinem Grund nicht versendet werden können.

Vielfältige Optimierungen

Neben unserem internen Zabbix prüfen heute zwei externe Monitoring-Dienste die verschiedensten von aussen "sichtbaren" Aspekte unserer Cloud, vom Object Storage bis zu API-Calls. Die sprichwörtlichen Fäden laufen schliesslich bei Opsgenie zusammen. Dieser Service ermöglicht es, die festgelegte Pikett-Einteilung zu hinterlegen und Alerts an die jeweils richtige Person weiterzuleiten. Kann der zuständige Engineer auf eine Meldung einmal nicht umgehend reagieren, erfolgt automatisch eine Eskalation an definierte weitere Personen. Mit der Anzahl involvierter Services steigt natürlich die Komplexität. Mittels automatisierter "Dummy-Alerts" testen wir daher auch immer wieder, ob die Alert-Verarbeitung an sich korrekt funktioniert und ob das Setup bis hin zum Mobiltelefon des eingeplanten Pikett-Mitarbeiters einsatzbereit ist.

Ein erkanntes Problem richtig zu eskalieren ist aber nur der eine Teil. Daneben haben wir auch viel Aufwand in die Optimierung der Datenbasis gesteckt, aus der die Anomalien herausdestilliert werden. Ausgehend von einem bereits breiten Set an Werten, die Monitoring-Systeme typischerweise aus einem laufenden Zielsystem auslesen, haben wir weitere, teils noch Hardware-nähere Checks hinzugefügt. So erkennt unser Monitoring beispielsweise, wenn eine NVMe-Disk am PCIe-Bus nicht die übliche Datenrate ausgehandelt hat. Zur anderen Seite hin – losgelöst von der Hardware – verfügen wir über immer mehr Checks, die den Zustand von ganzen Clustern überwachen, ohne von einem spezifischen Host abhängig zu sein, welcher hierzu abgefragt werden kann. Dank einer soliden Baseline von Messwerten können wir dann die Schwellenwerte so festlegen, dass Probleme zuverlässig erkannt werden, ohne dabei viel Lärm zu generieren.

Weshalb wir ruhig schlafen

Bei cloudscale.ch schläft der diensthabende Pikett-Engineer in der Regel durch. Die erwähnte Redundanz und wohlüberlegte Schwellenwerte erklären dies jedoch nur zum Teil. Wo eine Analyse zu Bürozeiten ausreicht, haben wir den Checks eine niedrige "Severity" zugewiesen und Opsgenie so eingestellt, dass deswegen niemand geweckt wird. Wichtig ist dann die konsequente Nachbearbeitung: Auch niedrige Severities und Anomalien, die tagsüber auffallen, werden zeitnah untersucht, bevor daraus ein Problem wird, für das man nachts aufstehen müsste. Das Gleiche gilt, falls trotzdem mal etwas durchschlägt; fast immer finden wir einen Weg, um künftige, ähnliche Fälle früher zu entdecken oder ganz zu vermeiden.

Zu alledem kommt eine weitere, eher untechnische Ebene: Dank einem separaten Monitoring für unser Lab können sich neue Engineers ganz ohne Druck eingewöhnen und kennen nach kurzer Zeit die Punkte, die es zu beachten gilt. Zudem sorgen beim Beheben von Problemen, die sich trotz ständiger Verbesserung nicht gänzlich vermeiden lassen, direkt verknüpfte Runbooks für die nötige Rückendeckung. Wer als Pikett-Engineer ausnahmsweise doch mal geweckt wird, kann sich so kurz darauf mit einem guten Gefühl wieder hinlegen.

Der zuverlässige Betrieb unserer Cloud-Infrastruktur ist für viele unserer Kunden zentral. Grundlage dafür ist, dass wir Anomalien möglichst frühzeitig erkennen und so die meisten Probleme vermeiden können, bevor sie sich für Kunden auswirken. Unser über die Jahre gewachsenes und laufend verbessertes Monitoring dient uns sozusagen als Augen und Ohren bis in die hintersten Winkel unserer Systeme; es enthält aber auch die Intelligenz, um unsere Engineers bei ihrer Arbeit zu unterstützen und zu entlasten.

Schlafen (auch) Sie gut!
Ihr cloudscale.ch-Team

Seit der vollständigen Überarbeitung unseres Cloud Control Panels lassen sich Cloud-Ressourcen für mehrere verschiedene Projekte verwalten. Für diese Projekte wiederum können – entweder für ganze Teams oder für einzelne Organization Members – Berechtigungen vergeben werden. Wie in Unternehmen üblich besteht gegenüber den Mitarbeitern jedoch eine gewisse Transparenz: Jeder Organization Member sieht, welche anderen Members, Teams und Projects in seiner Organization existieren, auch wenn er selber nicht Teil des jeweiligen Teams oder Projekts ist.

Bei der Zusammenarbeit mit unternehmensfremden Personen kann dieser Einblick unerwünscht sein. Ab sofort können Sie daher aussenstehende Personen als "External Collaborators" in Ihre Organization einladen und stellen damit sicher, dass die interne Struktur Ihrer Organization für diese verborgen bleibt. Das Management Ihrer Projekte bleibt unverändert einfach: auch External Collaborators können Sie zu Ihren Teams hinzufügen oder ihnen direkt Lese- bzw. Änderungsrechte in den gewünschten Projekten gewähren. Der External Collaborator sieht dann einzig die Projekte, für die er tatsächlich berechtigt ist, aber keine Details, die auf andere Tätigkeiten oder Beziehungen hindeuten. Egal, ob Sie enger mit Kunden oder Dienstleistern zusammenarbeiten möchten, dank External Collaborators schaffen Sie in jedem Szenario das richtige Mass an Transparenz.

Bewährte Konzepte nutzen

Für maximale Sicherheit empfehlen wir, mit persönlichen Accounts zu arbeiten und keine Zugangsdaten zwischen mehreren Personen zu teilen. Zugleich stellen Sie so sicher, dass Sie bei Bedarf in den Project Logs nachvollziehen können, von wem eine bestimmte Aktion ausgeführt wurde. Laden Sie nun auch externe Partner ein, einen persönlichen Account bei cloudscale.ch zu erstellen, und schicken Sie ihnen einen Invite-Link, der den Beitritt zu Ihrer Organization als External Collaborator ermöglicht. Falls Ihr externer Partner einen "OpenID Connect"-kompatiblen Identity Provider nutzt und auch bei cloudscale.ch von Single Sign-On profitieren möchte, hilft unser Support-Team gerne weiter.

Das Zuweisen von Lese- bzw. Änderungsrechten auf Ihre Projekte sowie das Hinzufügen von External Collaborators zu Teams funktioniert gleich, wie Sie es von Organization Members bereits kennen. Auf Projekte, bei denen Sie "Grant access to all members of the organization" gewählt haben, haben External Collaborators hingegen keinen Zugriff; nutzen Sie stattdessen die Möglichkeit von Teams oder individuellen Berechtigungen, um ausgewählten External Collaborators den Zugriff auf ein Projekt zu erlauben.

Übrigens: Genau wie für Ihre Organization Members ist der persönliche Account selbstverständlich auch für External Collaborators kostenlos. Es steht diesen jedoch frei, losgelöst von Ihrer Organization auch Cloud-Services auf eigene Rechnung zu beziehen.

Einige Hinweise

Viele Unternehmen haben interne Sicherheitsrichtlinien, und oft wird darin die Nutzung von Zwei-Faktor-Authentifizierung (2FA) ausdrücklich gefordert. In unserem Control Panel sehen Sie daher nicht nur für die Members, sondern auch für die External Collaborators Ihrer Organization den 2FA-Status; Änderungen daran werden zudem im Organization Log dokumentiert. Im Unterschied zu Organization Members fliessen alle übrigen Account-bezogenen Aktionen eines External Collaborators (z.B. Ein-/Ausloggen oder das Ändern des Account-Passworts) nicht ins Organization Log ein.

Die Details Ihrer Organization sind für External Collaborators grundsätzlich nicht sichtbar. Sobald Sie Zugriff auf ein Projekt erteilen, ermöglicht dies jedoch auch den Zugriff auf das entsprechende Project Log, d.h. Angaben über Änderungen im Projekt sowie deren Urheber. Auf diese Weise ist sichergestellt, dass der External Collaborator seine jeweilige Aufgabe (z.B. die Projekt-Überwachung oder das Nachvollziehen eines technischen Problems) tatsächlich wahrnehmen kann. Zudem sieht ein External Collaborator die hinterlegten E-Mail-Adressen Ihrer Organization (Haupt- und ggf. Rechnungsadresse) und kann diese auch als Absenderadresse von Supportanfragen auswählen.

Vom Konzept her folgen External Collaborators weitestgehend den Organization Members und lassen sich damit mühelos in Ihr bestehendes Berechtigungsschema integrieren. Der kleine Unterschied im Detail eröffnet Ihnen jedoch völlig neue Anwendungsbereiche: Beziehen Sie nun auch Ihre Kunden oder externe Spezialisten in das Management Ihrer Cloud-Ressourcen mit ein, ohne dass diese voneinander oder von Ihren Interna Kenntnis erhalten. So gelingt die vertrauensvolle Zusammenarbeit an Ihren Cloud-Projekten effizienter als je zuvor.

Zusammen besser,
Ihr cloudscale.ch-Team

cloudscale.ch setzte von Beginn weg auf separate Storage-Cluster auf Basis von Ceph. Diese speichern die Daten unabhängig von der Compute-Hardware auf dedizierten Storage-Servern, wobei die Daten über mehrere Storage-Server verteilt und dreifach repliziert abgelegt werden. Im Rahmen der Erweiterung unserer Bulk und Object Storages haben wir uns entschieden, auch die bestehenden Server zu ersetzen und bei den Disks neu ausschliesslich auf schnelle SSDs zu setzen.

Die neuen Storage-Server haben aber nicht nur schnellere Disks, sondern auch deutlich leistungsfähigere AMD CPUs und mehr RAM als die vorherige Generation. So kann Ceph, das sich um die Verteilung und Replikation Ihrer Daten in diesem Verbund kümmert, seine Fähigkeiten voll ausspielen. Unsere System Engineers haben zudem den Cache der Object Storages massiv vergrössert. Davon profitieren Schreibzugriffe und oft gelesene Objekte nochmals zusätzlich, denn für diese Caches setzen wir weiterhin besonders performante NVMe-SSDs ein.

Welche Vorteile dies bringt

Einer der grössten Nachteile von herkömmlichen Festplatten ist ihre mechanische Funktionsweise: Um Daten an eine bestimmte Stelle der Platte zu schreiben oder von dort zu lesen, muss der Schreib-/Lesekopf physisch an die richtige Position bewegt werden, und die Magnetscheibe sich drehen, bis die gewünschte Stelle sich unter dem Schreib-/Lesekopf befindet. Bei vielen Festplatten benötigt dieser Vorgang durchschnittlich ca. 8.5 ms – bei gleichzeitigen Diskzugriffen kann die Wartezeit für einen Prozess weiter hinten in der Warteschlange aber auch deutlich länger sein. Dank der Umstellung auf "All-Flash-Speicher" auch bei unseren Bulk und Object Storages entfällt die mechanisch bedingte Latenz, und der gegenseitige Einfluss von gleichzeitigen Zugriffen durch mehrere Kunden auf die Performance wird minimiert.

Ein typischer Vorteil von Ceph-Clustern, die Daten über mehrere Storage-Server und Disks verteilt speichern, zeigt sich bei simultanen Daten-Zugriffen: diese müssen nicht in eine Reihe gebracht und hintereinander bearbeitet, sondern können parallel ausgeführt werden. Mussten dennoch zwei Operationen auf die gleiche physische Festplatte zugreifen, galt dies jedoch nicht: Bedingt durch die Mechanik konnte immer nur eine Lese- oder Schreiboperation gleichzeitig erfolgen. Dank den SSDs sind nun auch auf Disk-Ebene parallele Zugriffe möglich – von dieser höheren Gesamt-Performance unserer Bulk und Objects Cluster profitieren unsere Kunden ganz automatisch.

Einige Hinweise

Um von unseren All-Flash-Clustern für Bulk und Object Storage zu profitieren, müssen Sie nichts weiter unternehmen: Die Umstellung erfolgte im Mai am Standort Rümlang (RMA) und Mitte August am Standort Lupfig (LPG) und umfasste auch sämtliche bestehenden Volumes bzw. Buckets. Beachten Sie jedoch, dass bei Bulk-Volumes das Rate-Limiting auf 500 IOPS bestehen bleibt. Damit wollen wir verhindern, dass einzelne Kunden mit besonders Disk-intensiven Anwendungen unsere Cluster auf Kosten von anderen Kunden übermässig beanspruchen. Insbesondere für Datenbank-Anwendungen empfehlen wir weiterhin unsere NVMe-SSD-Volumes, die kein solches Limit haben und gezielt auf höchste Performance ausgelegt sind.

Während die typische Zugriffszeit von rotierenden Festplatten mit dem neuen Setup entfällt, bleibt dennoch eine gewisse Latenz bestehen: Da unsere Storage-Cluster getrennt von den Compute-Servern auf separater Hardware betrieben werden, erfolgen alle Disk-Zugriffe via Netzwerk. Wir empfehlen Ihnen daher, allfällige Caching-Optionen Ihrer eingesetzten Software zu aktivieren und einen Flavor mit genügend RAM zu wählen, das von Linux automatisch als Disk-Cache genutzt werden kann.

Auch wenn Sie gewisse Daten nur selten benötigen, soll der Zugriff darauf möglichst schnell sein. Mit der Umstellung unserer Bulk und Object Storages auf "all Flash" schaffen wir den Spagat: bei unverändert günstigen Kosten profitieren Sie dank SSDs von deutlich mehr Leistung, auch und besonders dann, wenn gleich mehrere Zugriffe parallel erfolgen sollen. Überzeugen Sie sich selbst!

Adieu, Mechanik – willkommen, All-Flash!
Ihr cloudscale.ch-Team

Anders als von herkömmlichen Servern gewohnt, setzen wir bei cloudscale.ch auf separate Storage-Cluster auf Basis von Ceph: was für einen virtuellen Server aussieht wie eine einzelne, lokale Harddisk, ist in Wirklichkeit Speicherplatz, der über eine Vielzahl von Disks und Servern verteilt ist und die Daten mehrfach redundant vorhält. Einer der vielen Vorteile: bei einem Hardware-Defekt auf einem physischen Compute-Host können die betroffenen virtuellen Server innert kürzester Frist auf einer Ersatzmaschine neu gestartet werden; alle Daten sind sofort wieder verfügbar, ohne dass zuerst ein Techniker im Rechenzentrum die jeweiligen Harddisks von einem Server in den anderen umbauen müsste. Da in diesem Setup jedoch jeder Diskzugriff übers Netzwerk erfolgt, liegt die Latenz – trotz dedizierter Verbindungen von bis zu 100 Gbit/s – deutlich über dem Wert, der mit lokalen Disks erreichbar ist. Nutzen Sie daher die Caching-Funktionen, wenn Ihre eingesetzte Software (z.B. ein Datenbank-Server) diese Möglichkeit bietet.

Unser Tipp: Es kann sich lohnen jeweils einen etwas grösseren Flavor zu wählen, denn Linux nutzt RAM, das nicht anderweitig benötigt wird, ganz automatisch als Disk-Cache.

Performance: Workloads parallelisieren

Wenn die Daten erstmal von oder zu unserem Storage-Cluster fliessen, kommt ein weiterer Vorteil dieses Setups zum Tragen: weil im Cluster viele Storage-Server und noch mehr Disks zusammenarbeiten und parallel angesprochen werden können, liegt die erreichbare Datentransferrate deutlich über dem, was mit einer einzelnen, lokalen SSD möglich wäre. Das bedeutet: Je mehr sich die Datenzugriffe Ihrer Applikation parallelisieren lassen, umso mehr können Sie die nutzbare Gesamtleistung unseres Storage-Clusters ausschöpfen.

Unser Tipp: Parallelisieren Sie Ihre Workloads, wo dies möglich ist, denn verglichen mit einer rein sequenziellen Verarbeitung können Sie so die Storage-Leistung deutlich erhöhen.

Performance: Flavor je nach Anwendungsfall wählen

Nebst dem RAM-Bedarf (inklusive einer sinnvollen Reserve als Disk-Cache) spielt insbesondere der Bedarf an Rechenleistung eine zentrale Rolle bei der Wahl des passenden Flavors. Zusätzlich zur wählbaren Anzahl vCPUs/Cores stehen mit "Flex" und "Plus" zwei Modelle zur Verfügung, die für verschiedene Anwendungsfälle optimiert wurden. Bei den Flex-Flavors teilen Sie sich die Rechenleistung mit anderen Kunden und halten im Sinne der Fair-Use-Regelung eine moderate durchschnittliche Auslastung ein. Nebst einem günstigen Preis profitieren Sie dabei von genügend Leistungsreserven, um auch für Lastspitzen jederzeit gerüstet zu sein. Bei den Plus-Flavors steht Ihnen demgegenüber die gebuchte Anzahl physischer CPU-Cores jederzeit exklusiv zur Verfügung. Diese Leistung können und dürfen Sie konstant nutzen; Engpässe durch eine Überbuchung der verfügbaren Rechenleistung sind hier ausgeschlossen.

Unser Tipp: Ihre virtuellen Server lassen sich jederzeit skalieren, auch von Flex zu Plus und umgekehrt. Nutzen Sie diese Möglichkeit z.B. für initiale Tests mit unterschiedlichen Flavors oder immer dann, wenn sich Ihre Anforderungen ändern.

Kosten: Passender Storage für jede Anwendung

Bei jedem virtuellen Server sind die ersten 10 GB NVMe-SSD-Speicher des Root-Volumes inklusive. Darin befindet sich beim Launch des Servers das Basis-Image, und oft genügt diese Menge an Speicherplatz bereits für seinen Live-Einsatz. Zudem können zusätzliche Volumes jederzeit an den Server angehängt und wieder gelöscht werden. Wählen Sie hier NVMe-SSD-Speicher, wenn Sie maximale Performance benötigen, z.B. für den Betrieb einer Datenbank. Für grössere, weniger intensiv genutzte Datenbestände eignen sich dagegen die kostengünstigen und auf maximal 500 IOPS limitierten Bulk-Volumes. Testen Sie im Zweifel beide Varianten selbst: während Bulk-Volumes für einen DB-Einsatz definitiv ausser Betracht fallen, können sie in vielen anderen Szenarien bereits vollauf genügen und so einen kosteneffizienten Server-Betrieb unterstützen.

Unser Tipp: Als Alternative zu NVMe-SSD- und Bulk-Volumes, die Sie in Ihrem Server als sdX-Devices sehen, steht Ihnen zudem unser S3-kompatibler Object Storage zur Verfügung. Besonders interessant daran ist, dass Sie – nebst einem nutzungsabhängigen Betrag für Requests und ausgehenden Datentransfer – nicht für den verfügbaren, sondern immer nur für den tatsächlich belegten Speicherplatz bezahlen.

Kosten: Volumes skalieren nach Bedarf

Sowohl das Root-Volume als auch zusätzliche NVMe-SSD- und Bulk-Volumes können Sie jederzeit im laufenden Betrieb vergrössern. Tooling und passende Partitionierung innerhalb des Servers vorausgesetzt, funktioniert dies bis hin zur Ebene des Dateisystems. Bemessen Sie Ihre Volumes daher nach Ihrem tatsächlichen Platzbedarf; das vorzeitige Einplanen von zukünftigen Anforderungen ist nicht nötig. Beachten Sie jedoch, dass das Verkleinern von Volumes nicht unterstützt wird. Falls Sie nur vorübergehend zusätzlichen Platz benötigen, empfehlen wir Ihnen deshalb, ein zusätzliches Volume zu erstellen – dieses können Sie später jederzeit wieder löschen.

Unser Tipp: Falls Sie mehrere zusätzliche Volumes nicht als separate Mountpoints nutzen möchten, koppeln Sie diese z.B. mittels LVM zu einem zusammenhängenden Ganzen; so behalten Sie dennoch die Option, später einzelne PVs wieder aus der Volume Group auszuklinken und die entsprechenden Volumes zu löschen.

Resilienz: Kopien an unterschiedlichen Standorten

Bei cloudscale.ch gehen wir davon aus, dass unsere Kunden in ihrem eigenen Interesse aktuelle Backups ihrer Daten auf Drittinfrastruktur vorhalten, im einfachsten Fall z.B. lokal auf dem eigenen Arbeitsgerät. Falls Sie auch innerhalb unserer Cloud-Infrastruktur Kopien mit Backup-Charakter pflegen, empfehlen wir Ihnen, diese am jeweils anderen Cloud-Standort zu speichern als deren Quelldaten. Dank unserer zwei geographisch getrennten Cloud-Regionen in Rümlang/ZH (RMA) und Lupfig/AG (LPG) sind Ihre Daten damit auch für den Fall von unwahrscheinlichen, aber potenziell schwerwiegenden Ereignissen wie Feuer oder Erdbeben bestmöglich geschützt. Über unseren Dark-Fiber-Ring zwischen den zwei Regionen nehmen Ihre Daten übrigens automatisch den direktest möglichen Weg.

Unser Tipp: Alternativ steht Ihnen an beiden Cloud-Standorten je ein S3-kompatibler Object Storage zur Verfügung. Achten Sie in diesem Fall jedoch darauf, das Bucket tatsächlich am jeweils anderen Standort zu erstellen.

Resilienz: Anti-Affinity nutzen

Bei wachsendem Ressourcenbedarf "vertikal" zu skalieren, also einem bestehenden Server mehr Ressourcen zuzuweisen, vermeidet Komplexität und somit mögliche Fehlerquellen. Dennoch kann es sinnvoll sein, stattdessen "horizontal" zu skalieren und die Last hinter einem (redundant aufgebauten) Load-Balancer auf mehrere Server zu verteilen. Damit von einem potenziellen, isolierten Hardware-Problem nicht mehrere dieser Server gleichzeitig betroffen sind, nutzen Sie unser Anti-Affinity-Feature: Indem Sie beim Erstellen bis zu vier virtuelle Server in Anti-Affinity zueinander setzen, stellen Sie sicher, dass diese Server auch tatsächlich auf separaten physischen Hosts laufen.

Unser Tipp: Fassen Sie jeweils diejenigen Server zusammen, die gleichartige Aufgaben erfüllen und einander bei einem Ausfall "vertreten" können.

Resilienz: Einsatz von Floating IPs

Praktisch alles läuft heute über Domainnamen, und mit einer genügend niedrigen TTL (Time to live) Ihrer DNS-Einträge können Sie auf diesem Weg steuern, zu welcher IP-Adresse und damit zu welchem Server entsprechende Requests gelangen. Dennoch bleibt eine gewisse Verzögerung, und das Verhalten verschiedener Clients ist nicht immer ganz konsistent. Dank Floating IPs sparen Sie sich den Wechsel der IP-Adresse: verschieben Sie Ihre Floating IPs innerhalb einer Region oder sogar Regions-übergreifend zwischen Ihren Servern, um den Traffic innert Sekunden zum jeweils gewünschten Server zu leiten. Für ein Failover-Setup können Sie diesen Vorgang auch via unsere API automatisieren: zwei Server – z.B. zwei Load-Balancer – überwachen einander laufend gegenseitig, um bei einem Problem des Gegenübers den Live-Traffic praktisch nahtlos zu sich selber umzulenken.

Unser Tipp: Auch bei einfachen Setups bieten Ihnen Floating IPs einen entscheidenden Mehrwert, denn im Gegensatz zu IP-Adressen eines Servers bleiben Floating IPs beim Löschen von Servern erhalten. So lassen sich Services aus Nutzersicht unverändert wieder aufnehmen, selbst wenn Sie im Hintergrund den betreffenden Server komplett austauschen.

Sicherheit: Backend-Server schützen

In Setups mit mehreren Servern, z.B. mit getrenntem Web- und Datenbank-Server, muss oft ein Teil der Systeme nicht direkt aus dem Internet erreichbar sein. Für einen optimalen Schutz dieser Backend-Systeme gilt es vielmehr, direkte Zugriffe bewusst zu verhindern. Bei cloudscale.ch können Sie solche Backend-Systeme über ein separates, privates Netz mit den Frontend-Servern verbinden und dabei auf eine direkte Verbindung zwischen Backend-Systemen und Internet komplett verzichten. Für komplexere Setups können Sie auch mehrere voneinander getrennte private Netze erstellen oder Vorgaben zu den Settings machen, die der DHCP-Service im privaten Netz zuweisen soll.

Unser Tipp: Mit OPNsense und pfSense CE stehen zwei dedizierte Firewall-Distributionen zur Verfügung – damit verwalten Sie einen Firewall-Server an der Schnittstelle zwischen öffentlichem und privatem Netz bequem via Web-Interface.

Sicherheit: Verschlüsselung

Hier handelt es sich zuerst einmal nicht um einen Tipp im eigentlichen Sinne: Bei cloudscale.ch werden alle Daten, die unsere Kunden auf unseren Storage-Clustern speichern (d.h. sämtliche Daten auf NVMe-SSD- und Bulk-Volumes sowie in unseren Object Storages), automatisch "at rest" verschlüsselt. Diese Verschlüsselung dient als zusätzliche Sicherheitsschicht z.B. für den Fall, dass eine defekte Disk bei der Ausserbetriebnahme nicht mehr komplett gelöscht werden kann. Entsprechend versierte Benutzer können selbstverständlich noch einen Schritt weiter gehen: Unser Object Storage unterstützt Server-side Encryption mittels SSE-C. Natürlich steht es Ihnen frei, auch für Volumes oder einzelne Partitionen eine zusätzliche Verschlüsselung, z.B. mit LUKS, innerhalb Ihrer virtuellen Server und unter Ihrer alleinigen Kontrolle einzurichten. Beachten Sie dabei jedoch, dass nach einem (ungeplanten) Reboot normalerweise eine manuelle Intervention nötig sein wird. Zudem werden Einrichtung und Debugging solcher Setups durch unseren Support nicht abgedeckt.

Unser Tipp: Auch unser CSI (Container Storage Interface) Driver unterstützt Festplattenverschlüsselung (Full Disk Encryption). In Kubernetes-Setups lassen sich damit selbst persistente Volumes von Containern mit minimalem Aufwand mittels LUKS verschlüsseln.

Sicherheit: Zertifizierung und Compliance

Nebst der Datenverschlüsselung profitieren Sie bei cloudscale.ch auch davon, dass wir nach ISO 27001, 27017 und 27018 zertifiziert sind. Ebenso sind die von uns genutzten Rechenzentren nach ISO 27001 und weiteren internationalen Standards zertifiziert. cloudscale.ch ist zudem Hosting-Partner des Labels "swiss hosting"; wir bieten Ihnen die Gewissheit, dass sämtliche Daten ausschliesslich in der Schweiz gespeichert und verarbeitet werden. Dadurch unterstützen wir Sie dabei, die Compliance-Anforderungen Ihrer eigenen Kunden bestmöglich zu erfüllen.

Unser Tipp: Falls Sie in unserer Cloud Daten von EU-Personen verarbeiten, bieten wir Ihnen zusätzlich die Möglichkeit zum Abschluss einer ADV-Vereinbarung gemäss EU-DSGVO an – Sie finden diese Vereinbarung in unserem Cloud Control Panel und können sie dort mit nur zwei Mausklicks direkt abschliessen.

Diese Tipps erheben keinen Anspruch auf Vollständigkeit. Je nach Anforderungen kann einer der erwähnten Aspekte besonders wichtig sein – oder aber ganz andere, wie zum Beispiel effiziente Abläufe mithilfe der von uns unterstützten DevOps Tools. Selbstverständlich entwickeln wir unser Angebot zudem stetig weiter. Im direkten Kontakt beantworten wir natürlich auch gerne die Fragen, die in Ihrem Alltag auftauchen, und lassen Ihre Rückmeldungen in unsere Roadmap einfliessen.

Einfach ausgeklügelt,
Ihr cloudscale.ch-Team

Dieser Beitrag wurde am 10.8.2021 erweitert.

Mit den kürzlich eingeführten "Organizations" können Firmen und andere Gruppierungen die Zusammenarbeit rund um ihre Cloud-Ressourcen organisieren. Als Superuser können Sie dabei beliebige cloudscale.ch-Accounts in Ihre Organization einladen und diesen auf Projekt-Basis Lese- oder Vollzugriff erteilen. Personen, die – z.B. für sich privat – bereits einen Account bei cloudscale.ch haben, können diesen weiternutzen und sehen dann zusätzlich die Ressourcen Ihrer Organization.

Vielleicht ziehen Sie als Unternehmen jedoch vor, dass Ihre Mitarbeiter einen separaten Account benutzen, der auf die geschäftliche E-Mail-Adresse lautet. In diesem Fall können Sie zusätzlich Ihren eigenen, "OpenID Connect"-kompatiblen Identity Provider ("IDP"), wie z.B. Keycloak oder ZITADEL, mit unserem Cloud Control Panel verknüpfen lassen. Beim Signup- oder Login-Versuch mit einer Adresse aus Ihrer E-Mail-Domain wird der Benutzer dann zu Ihrem IDP weitergeleitet. Hat er sich gemäss den Vorgaben Ihres IDPs authentifiziert, gelangt er zurück zu unserem Control Panel und ist auch hier eingeloggt.

Tipps zum Einsatz Ihres IDPs bei cloudscale.ch

• Zwei-Faktor-Authentifizierung ("2FA") ist ein wichtiges Sicherheits-Feature. In unserem Control Panel sehen Sie für jeden "Member" Ihrer Organization, ob 2"fa fa-solid für den jeweiligen Account aktiviert ist oder nicht. Indem sich Ihre Members über Ihren eigenen IDP in unser Control Panel einloggen, können Sie 2"fa fa-solid falls gewünscht auch technisch erzwingen – damit sparen Sie sich periodische Kontrollen und haben die Gewissheit, dass dieser Zusatz-Schutz jederzeit greift.
• Um das Onboarding zu vereinfachen, lässt sich auf Wunsch für jede Organization ein E-Mail-Pattern hinterlegen. Neu angelegte Accounts, welche diesem Pattern entsprechen, werden dann automatisch als Member der jeweiligen Organization hinzugefügt.
• Ob sich eine bestimmte Person überhaupt in unser Control Panel einloggen darf, legen Sie bequem direkt in Ihrem IDP fest – so behalten Sie bei Ein- und Austritten von Mitarbeitern jederzeit die Kontrolle.
• Falls Sie Ihren IDP ebenfalls in unserer Cloud betreiben, stellen Sie bitte sicher, dass Sie auch bei dessen Ausfall noch die nötigen Reparaturmassnahmen treffen können. Wir empfehlen Ihnen daher, in Ihre Organization einen zusätzlichen Superuser aufzunehmen, der nicht vom gleichen IDP abhängig ist. Eine weitere Möglichkeit wäre ein IDP-Setup mit automatischem Failover.

Falls Sie die Anbindung Ihres IDPs in Angriff nehmen möchten oder noch Fragen dazu haben, steht Ihnen unser Support gerne zur Verfügung.

Komfort auch ohne eigenen IDP: Login mit GitHub

Auch ohne eigenen IDP steht neu eine weitere Login-Möglichkeit zur Verfügung: Wenn Sie sich mit GitHub statt einem Passwort in unser Control Panel einloggen möchten, klicken Sie zum Signup und bei künftigen Logins einfach auf "Continue with GitHub". Die bei GitHub hinterlegte primäre E-Mail-Adresse wird Ihrem cloudscale.ch-Account zugeordnet und dient uns als Kontaktadresse für die Kommunikation mit Ihnen. Bitte beachten Sie, dass das Einloggen in unser Control Panel damit von der Verfügbarkeit von GitHub sowie Ihrem dortigen Account abhängt.

Ein Umschalten zwischen GitHub- und Passwort-basiertem Login ist bei bestehenden Accounts derzeit nicht möglich. Falls Sie bereits einen Account haben und bestehende Projekte in einen neuen Account mit anderem Login-Verfahren übernehmen möchten, hilft Ihnen unser Support gerne weiter.

Single-Sign-On-Lösungen helfen dabei, dass die Benutzer weniger verschiedene Passwörter benötigen und diese weniger oft eintippen müssen. Damit sinkt auch der Anreiz, schwache Passwörter zu wählen und dadurch ein Risiko einzugehen. Indem Sie unser Cloud Control Panel an Ihren bestehenden IDP anbinden, erleichtern Sie Ihren Mitarbeitern die Arbeit und erhöhen gleichzeitig die Sicherheit für Ihr Unternehmen und Ihre Kunden.

Schafft Vertrauen,
Ihr cloudscale.ch-Team

Projekte: Mehr Ordnung für alle

Um den Überblick zu behalten, gibt es eine Reihe bewährter Ansätze – vom passenden Namensschema über Tags bis zum Einsatz verbreiteter DevOps-Tools. Mit unseren neuen "Projects" gehen Sie noch einen Schritt weiter: Ihre Cloud-Ressourcen sind nicht nur optisch gruppiert und vor Verwechslungen geschützt, sondern auch technisch voneinander getrennt. So wird verhindert, dass Sie einen Testserver versehentlich ins private Netz Ihrer produktiven Infrastruktur einklinken oder mit dem API-Token des einen Clusters in einem anderen Unfug getrieben wird. Sämtliche Cloud-Ressourcen, wie z.B. virtuelle Server, Volumes, private Netze, Floating IPs und Objects User, sind dabei jeweils Teil genau eines Projekts.

Wechseln Sie dank Projekten ganz einfach zwischen Ihren verschiedenen "Hüten": Die Cluster Ihrer Endkunden A und B, Ihr persönliches Experimentier-Setup und der ehrenamtlich betriebene Webserver – alles ist sauber voneinander getrennt und dennoch mit nur zwei Klicks erreichbar. Wo Sie bisher vielleicht mit mehreren Accounts gearbeitet hätten, sind die neuen Projekte das Mittel der Wahl.

Arbeiten Sie zusammen – in Organizations

Ob geschäftlich oder privat: an vielen Projekten arbeitet man nicht alleine. Mit den ebenfalls neu eingeführten "Organizations" bilden Sie eine solche Zusammenarbeit ab. Erstellen Sie Organizations für Ihre Firma, Ihren Verein oder für sich selbst, wenn Sie zusammen mit anderen Personen an Ihren Cloud-Ressourcen arbeiten möchten. Als "Superuser" in einer Organization können Sie deren Projekte verwalten, "Members" einladen und Berechtigungen vergeben. Da den Organizations jeweils ein separater Rahmenvertrag zugrunde liegt, eignen sie sich auch für Konstellationen, in denen Cloud-Ressourcen buchhalterisch getrennt behandelt werden sollen.

Die Vorteile einer Organization liegen auf der Hand: Jeder Organization Member verfügt über eigene Zugangsdaten und kann für zusätzlichen Schutz die 2-Faktor-Authentifizierung aktivieren. Dank der Nachvollziehbarkeit von Änderungen in Organization- und Project-Logs erfüllen Sie auch die Compliance-Anforderungen Ihrer Endkunden. Für jedes Projekt Ihrer Organization können Sie zudem individuell festlegen, welche Members und/oder Teams read-only bzw. Vollzugriff haben sollen.

Einfache Benutzung, reibungsloser Übergang

Usability liegt in der DNA von cloudscale.ch, und auch bei diesem Evolutionsschritt haben wir besonderen Wert auf einfache Benutzung gelegt. Im komplett überarbeiteten Cloud Control Panel, das neu auf einer "Single Page Application"-Architektur basiert, finden Sie fast alles am gewohnten Ort und die bisherige Funktionalität bleibt unverändert. Auch die API-Spezifikation bleibt gleich; automatisierte Prozesse und Tools müssen also nicht angepasst werden.

Ihre bestehenden Cloud-Ressourcen sind von der Umstellung unberührt, und allfällige API-Tokens funktionieren selbstverständlich weiterhin. Falls Sie bisher einen Account mit anderen Personen geteilt haben und diesen künftig als Organization führen möchten, geben Sie uns einfach Bescheid – gerne migrieren wir den Account für Sie. Und natürlich freuen wir uns ebenso über sonstiges Feedback.

Mit der grössten Überarbeitung des Cloud Control Panels in der Geschichte von cloudscale.ch schaffen wir den Spagat: Auch in Zukunft ist "die Cloud" bei uns einfach, schnell und intuitiv. Neu haben Sie zudem die passenden Werkzeuge in der Hand, um selbst im grösseren Kontext jederzeit den Überblick und die Kontrolle zu behalten – sowohl alleine wie auch in Teams.

Erleben Sie die Cloud aus einer neuen Perspektive!
Ihr cloudscale.ch-Team

Was getestet wird

Wir haben die Acceptance Test Suite entwickelt, um ein möglichst vollständiges Bild unserer Cloud-Infrastruktur aus Kundensicht zu haben. Diese End-to-End-Tests berühren daher praktisch jeden Winkel unseres Cloud-Angebots: Dass ein einzelner Server tatsächlich bis zu 128 Volumes haben kann wird genauso geprüft wie das Skalieren von Servern zwischen Flex- und Plus-Flavors, das Verschieben einer Floating IP zwischen zwei Servern oder die Nutzung von Jumbo Frames in einem privaten Netz. Die Acceptance Tests simulieren dabei einen Power-User, der alle Features unseres Angebots nutzt. So haben wir die Gewissheit, dass unsere Infrastruktur auch im täglichen, vielseitigen Einsatz durch unsere Kunden einwandfrei funktioniert.

Die Acceptance Tests nutzen unsere öffentliche API und damit die gleiche technische Schnittstelle, auf die auch unser CLI und DevOps-Tools wie Ansible und Terraform zugreifen. Da die Acceptance Tests somit vollständig automatisiert werden können, eignen sie sich für die regelmässige Ausführung: wir lassen sie von GitHub aus täglich gegen unsere beiden Cloud-Standorte laufen, um permanent die "Aussensicht" unserer Kunden im Blick zu behalten. Ebenfalls täglich testen wir damit auch unsere Lab-Setups; dazu kommen gezielte Test-Runs vor und nach grösseren Updates. Als Ergänzung zu unseren manuellen Verifikationsschritten im Lab geben uns die Acceptance Tests damit eine zusätzliche Gewissheit, dass geplante Arbeiten an produktiven Systemen keine negativen Auswirkungen für unsere Kunden haben werden.

Komplett ausgeklammert aus unseren eigens entwickelten Acceptance Tests ist einzig der S3-kompatible Object Storage, der auf Ceph basiert. Dort nutzen wir die entsprechenden automatisierten Tests, die im Umfeld dieses Open-Source-Projekts bereits öffentlich zur Verfügung stehen.

Was die Acceptance Tests für unsere Kunden bedeuten

Um negative Auswirkungen von Einzelereignissen wie z.B. Hardware-Defekten auf unsere Kunden zu minimieren, setzen wir auf Redundanz und ein feinmaschiges Monitoring. Mit den Acceptance Tests, die von aussen eine Vielzahl von Nutzungsszenarien simulieren, erweitern wir dieses Monitoring und decken so auch Fälle ab, in denen zwar alle "Rädchen" für sich genommen funktionieren, aber dennoch aus irgendeinem Grund nicht korrekt ineinandergreifen. Typisch sind hier Konfigurationsfehler oder Versions-Updates, die ein leicht verändertes Verhalten von Systemen mit sich bringen. Dank der umfassenden Acceptance Tests bemerken wir auch Edge-Cases oft bereits im Lab; die regelmässigen Tests der produktiven Systeme bestätigen uns dann, dass unseren Kunden auch über die Zeit hinweg alle Features wie gewohnt zur Verfügung stehen.

Trotz allem kommt es vor, dass Probleme an unerwarteten Stellen auftauchen – ein vormals korrektes Verhalten eines Systems ist plötzlich nicht mehr gegeben. Einer der Wege, um solche "Regressions" in Zukunft zu verhindern, ist die Erweiterung unserer Acceptance Test Suite. Als Projekt, das gewachsen ist und weiter wächst, entwickeln sich die Acceptance Tests zusammen mit unserem Cloud-Angebot weiter. Von diesem institutionalisierten Lernprozess profitieren selbstverständlich alle Kunden – ganz automatisch.

Wie Sie sich Ihr eigenes Bild machen

Das Hauptziel unserer Acceptance Tests ist natürlich, dass Sie sich in Ihrem Alltag auf die dokumentierten Features unserer Infrastruktur verlassen können. Wir gehen aber noch einen Schritt weiter: Auf GitHub können Sie die Test-Runs gegen unsere produktiven Cloud-Infrastrukturen inklusive der Resultate einsehen. Dabei gilt es zu beachten, dass im Internet immer mal etwas dazwischen kommen kann; Tests werden daher ggf. einmal wiederholt, bevor sie als "failed" ausgewiesen werden.

Für alle, die noch etwas genauer hinschauen möchten, haben wir den Quellcode unserer Acceptance Tests auf GitHub veröffentlicht. So können Sie im Detail nachvollziehen, was und wie wir testen. Falls gewünscht können Sie die Tests auch selbst gegen unsere Infrastruktur laufen lassen. Sie benötigen dafür lediglich ein Linux- oder macOS-System mit Python ab Version 3.6 sowie einen Account bei cloudscale.ch (wir empfehlen zur Sicherheit die Nutzung eines separaten Accounts, in welchem Sie keine produktiven Ressourcen betreiben).

Unsere Kunden zählen darauf, dass ihre Infrastruktur bei cloudscale.ch zuverlässig funktioniert. Regelmässige Tests sowohl in unserem Lab als auch auf der produktiven Infrastruktur sind dabei ein fixer Bestandteil unserer Qualitätssicherung. Indem wir unsere Acceptance Tests nun auf GitHub offenlegen, erhalten Sie einen direkten Einblick in dieses zentrale Werkzeug, an dem wir uns Tag für Tag messen.

Testet auf Herz und Nieren,
Ihr cloudscale.ch-Team

Infrastructure-as-a-Service, kurz "IaaS", war bei cloudscale.ch schon immer bewusst einfach gehalten: zu einem Account gehört eine E-Mail-Adresse und ein Passwort, etwas Guthaben und so viele oder wenige virtuelle Server wie gerade benötigt. Für ein Unternehmen, welches unsere Services nutzt, ist dies jedoch nicht immer ideal, und so mancher Nutzer würde seine Cloud-Ressourcen gerne gruppieren, z.B. je nach Einsatzzweck der einzelnen Server. Mit unserem neuen Cloud Control Panel werden künftig alle Szenarien optimal abgedeckt:

• Das Kundenkonto bzw. der "Account" entspricht dem bisherigen Ansatz, ergänzt um zusätzliche Möglichkeiten wie z.B. die Separierung von Cloud-Ressourcen in verschiedene Projekte. Damit lassen sich beispielsweise Test- und Produktivumgebungen sauber voneinander trennen.
• Die neuen "Organizations" wiederum stehen für einen separaten Rahmenvertrag und können ebenfalls Cloud-Ressourcen buchen; statt eines Passworts zum Einloggen haben diese jedoch ein oder mehrere "Members", die innerhalb der Organization unterschiedliche Rollen und Berechtigungen haben können.

Falls Sie mehr über die neuen Möglichkeiten erfahren möchten, stellen Sie bitte sicher, dass Sie unseren Newsletter abonniert haben, oder schauen Sie demnächst in den News auf unserer Website vorbei.

Wir werden das neue Cloud Control Panel im Laufe des zweiten Quartals 2021 live schalten. Für eine transparente Regelung der neuen technischen Möglichkeiten publizieren wir bereits heute unsere aktualisierten AGB, welche diese Neuerungen abdecken. Ab sofort gelten für neu erstellte Kundenkonten diese neuen AGB. Für bestehende Kunden treten die neuen AGB mit einer Frist von 30 Tagen per 26.04.2021 in Kraft, in Übereinstimmung mit der bisherigen Regelung. Auf die Bestimmung, dass AGB-Änderungen bei Bezug zusätzlicher Services sofort als genehmigt gelten, berufen wir uns nicht, und mit den neuen AGB entfällt diese Bestimmung dann ersatzlos – ein automatisiertes Cloud-Setup hat somit keinen Einfluss auf die Vorlaufzeit, die Ihnen zur Verfügung steht.

Eine Aktion Ihrerseits ist nicht nötig; allfällig bestehende Services laufen auch nach Inkrafttreten der neuen AGB unverändert weiter.

Die wichtigsten Neuerungen

Die neuen AGB decken mit Accounts und Organizations explizit die beiden Möglichkeiten für eine Kundenbeziehung und damit für einen Rahmenvertrag ab. Ein "Account" bzw. Kundenkonto ist der typische Ansatz für eine einzelne Person, die Services von cloudscale.ch nutzen möchte, und wird benötigt, um sich in unser Cloud Control Panel einzuloggen. Einmal eingeloggt, lassen sich mittels "Organizations" zusätzliche Rahmenverträge abschliessen, z.B. lautend auf den Namen des eigenen Unternehmens.

Unter den Titeln "Einleitung" und "Nutzung" halten die neuen AGB fest, unter welchen Vertrag und damit in wessen Verantwortung die einzelnen Aktionen – z.B. das Erstellen eines neuen Servers – fallen: massgebend ist immer der Account bzw. die Organization, in dessen/deren Kontext eine Aktion ausgeführt wird. Damit folgt die neu mögliche Vergabe von Berechtigungen den gleichen Grundsätzen, die man sich z.B. auch von Arbeitsverträgen und Stellvertretungen gewohnt ist.

Bedingt durch die Möglichkeit der Zusammenarbeit sind Accounts nicht mehr in jedem Fall komplett unabhängig voneinander. Der Abschnitt "Weitergabe von Kundendaten" enthält neu den Hinweis, dass bei Annehmen oder Gewähren von Berechtigungen gewisse Daten für andere Personen sichtbar sind oder sichtbar werden können, z.B. in den Logs einer Organization, in welcher man Member ist.

Für eine verbesserte Klarheit, dass beim Lesen der AGB nicht zwingend der Leser persönlich gemeint ist, haben wir alle Formulierungen von "Sie" in "Kunde" geändert. Es versteht sich von selbst, dass diese Formulierung keinerlei Gender implizieren soll – bei cloudscale.ch sind selbstverständlich alle willkommen!

Nebst einigen kleineren Anpassungen haben wir die Gelegenheit genutzt, um einen weiteren Kundenwunsch zu erfüllen: Schon bisher kündigten wir geplante Wartungsarbeiten wenn immer möglich im Voraus an; neu haben wir einen entsprechenden Abschnitt "Wartungsarbeiten" in unsere AGB aufgenommen. Im Interesse unserer Kunden behalten wir uns jedoch auch in Zukunft vor, in dringenden Fällen, wie z.B. bei Sicherheitsupdates, kurzfristig Wartungsarbeiten durchzuführen.

Das Meiste bleibt gleich

Die Grundhaltung hinter unseren AGB bleibt unverändert. Auch im "Kleingedruckten" wollen wir für Sie ein naher und nahbarer Partner sein. Dies beginnt bereits beim Datenstandort: Nach wie vor betreiben wir unsere gesamte Infrastruktur ausschliesslich in Rechenzentren in der Schweiz. Bei technischen Anliegen leisten wir individuellen Support. Unsere Services und deren Preise ändern sich mit den neuen AGB nicht. Und weil wir überzeugt sind, dass unser "Gesamtpaket" für sich selbst spricht, müssen Sie bei cloudscale.ch auch weiterhin keine Mindestvertragslaufzeiten oder Kündigungsfristen beachten.

Wir freuen uns darauf, Ihnen schon bald unser rundum erneuertes Cloud Control Panel vorstellen zu dürfen, und sind überzeugt, mit den aktualisierten AGB eine ausgewogene Basis für die neuen Möglichkeiten gefunden zu haben. Sollten Sie dennoch Vorbehalte haben, klären wir Ihre Fragen natürlich gerne im direkten Kontakt.

Volle Flexibilität bei voller Transparenz,
Ihr cloudscale.ch-Team

Container-Orchestrierung: Worum geht es eigentlich?

Viele unserer Kunden nutzen bereits Container in der einen oder anderen Form. Ein aktuell weit verbreiteter Ansatz zur gegenseitigen Isolierung von Containern ist die Verwendung von Linux-Namespaces in Kombination mit cgroups. Definitiv zum Mainstream gehört dieser Ansatz seit ca. 2013 mit dem Durchbruch von Docker und der darauf folgenden Standardisierung in der Open Container Initiative (OCI). In Containern können Anwendungen besonders ressourcen-effizient voneinander separiert werden, denn dieser Ansatz kommt ohne Hardware-Virtualisierung aus, und anders als bei "Full Virtualization" läuft auch das Betriebssystem nicht in mehreren, parallelen Instanzen.

Einige Container verteilt auf wenige Nodes lassen sich zwar noch problemlos von Hand verwalten. Spätestens bei Fragen zum Hochskalieren sowie zum Lifecycle-Management von Containern kommen jedoch Container-Orchestrators wie Kubernetes bzw. "K8s" ins Spiel: Kubernetes sorgt unter anderem dafür, dass von jedem Container die gewünschte Anzahl Instanzen läuft, und bestimmt hierzu selbständig die passenden Nodes. Beim Deployment von neuen Container-Versionen ersetzt es alte Instanzen nach definierten Deployment-Strategies, z.B. um einen Service als Ganzes durchgehend verfügbar zu halten. Und wenn für bestimmte Container persistenter Storage benötigt wird, kann Kubernetes diesen via CSI automatisch für den passenden Node provisionieren.

Kubernetes existiert in verschiedenen "Flavors"

Bei cloudscale.ch haben Kunden die Wahl, wie sie Kubernetes installieren und betreiben möchten. Wer direkt mit dem "Upstream" Kubernetes arbeiten möchte, kann seinen K8s-Cluster z.B. mit Kubespray aufsetzen: dieses Tool basiert auf Ansible und kann Hand in Hand mit unserer Ansible Collection eingesetzt werden – so erstellen Sie die für den Cluster benötigte Cloud-Infrastruktur bequem via unsere API.

Einen Schritt weiter geht Rancher, das sich als Verwaltungs-Tool noch eine Ebene höher positioniert. Rancher läuft selbst auf Container-Basis und stellt ein grafisches Web-Frontend sowie APIs bereit, mit denen sich komplette Kubernetes-Cluster in wenigen Schritten erstellen und verwalten lassen. Rancher stellt die für einen Cluster benötigten Cloud-Ressourcen automatisch bereit; der "cloudscale.ch Node Driver" ist bei aktuellen Rancher-Versionen bereits vorinstalliert.

Ein weiteres, mächtiges Werkzeug ist OKD, das hier etwas genauer betrachtet werden soll. Dieses Open-Source-Projekt bildet zudem die Grundlage für OpenShift, das von Red Hat als Gesamtpaket aus Software, Services und Support vertrieben wird. Analog zum Linux-Kernel und darauf aufbauenden Linux-Distributionen kann man OKD als "Kubernetes-Distribution" bezeichnen: Über das reine Managen von Containern hinaus integriert OKD eine Reihe von Tools, die sich z.B. auch um die Überwachung des Clusters, das Logging oder das Routing von Netzwerk-Traffic zu den richtigen Containern kümmern. Die Installation von OKD profitiert bei cloudscale.ch von verschiedenen Features, über die wir bereits berichten konnten, wie z.B. private Netze mit Managed DHCP. Für die sogenannten Master- und Worker-Nodes setzt OKD auf Fedora CoreOS, welches aus dem früheren Core OS hervorgegangen ist und das auch bei cloudscale.ch zur Installation auf neuen Servern zur Auswahl steht (genauso wie übrigens Flatcar Container Linux, ein beliebter Core-OS-Fork).

Schritt für Schritt zum eigenen OKD-Cluster

Falls Sie neugierig auf OKD sind, starten Sie Ihren eigenen OKD-Cluster mit Hilfe des detaillierten How-Tos, welches wir auf GitHub publiziert haben. Dieses Tutorial nutzt mit Ansible ein verbreitetes DevOps-Tool zur Automatisierung der einzelnen Schritte; zusätzlich hilft das im OpenShift-Umfeld entwickelte "ocp4-helpernode" in unserem How-To zur weiteren Vereinfachung des Vorgehens, insbesondere beim Provisioning von HAProxy und DNS. Der Ablauf besteht im Wesentlichen aus den folgenden vier Schritten:

Schritt 1: Auf dem persönlichen Arbeitsgerät, z.B. dem eigenen Laptop oder einem alternativ benutzten Cloud-Server, werden die benötigten Tools installiert sowie einige grundlegende Werte bzw. Variablen definiert.

Schritt 2: Der sogenannte Helper-Node wird installiert und die Services darauf konfiguriert, die im Cluster eine Reihe von zentralen Funktionen übernehmen. So laufen z.B. API-Verbindungen über den HAProxy, welcher später zudem ermöglicht, dass Ihre Applikationen auf den Worker-Nodes aus dem Internet erreichbar sind. Der DNS-Server wiederum erlaubt es, im Cluster interne Domains bzw. IP-Adressen aufzulösen, und ein Apache HTTP Server liefert statische Files aus. Auf dem Apache hinterlegen Sie insbesondere die Ignition-Configs: Ähnlich zu "cloud-init" bietet Ignition einen Weg, um auf neu erstellten Servern gleich beim ersten Starten individuelle Einstellungen zu setzen.

Schritt 3: Nun werden die Master- und Worker-Nodes erstellt. Wie bereits beim Helper-Node erfolgt das Starten der virtuellen Server bei cloudscale.ch automatisiert mit Hilfe unserer Ansible Collection. Die neuen Nodes holen ihre vorbereiteten Ignition-Configs und somit ihre spezifischen Konfigurations-Einstellungen vom Apache-Server aus dem vorherigen Schritt und richten sich auf diese Weise selbständig fertig ein.

Schritt 4: Um die neuen Nodes im Cluster zu akzeptieren, müssen in einem letzten Schritt noch die jeweiligen CSRs signiert werden. Damit ist die Installation des OKD-Clusters abgeschlossen.

Die Beliebtheit von Container-Setups ist ungebrochen, nicht zuletzt durch die Vielzahl von Vorteilen wie z.B. der sauberen Trennung von einzelnen Services bei gleichzeitig effizienter Ressourcen-Nutzung. Beim Management von Containern gibt es dabei viele richtige Lösungen – je nach den konkreten Anforderungen und Vorlieben. Ob OKD, Rancher oder ein besonders schlanker Ansatz: bei cloudscale.ch finden Sie die Bausteine dafür, dass alles zusammenspielt.

Für Ihre Lieblings-Tools,
Ihr cloudscale.ch-Team

Der wohl meist genannte Vorteil von "Infrastructure as a Service" (IaaS) darf natürlich nicht fehlen: Werden IT-Ressourcen nicht in Form von Hardware gekauft, sondern als Cloud-Service bezogen, entfällt die anfängliche Investition. Stattdessen verteilen sich die Ausgaben relativ gleichmässig über den gesamten Nutzungszeitraum, und im Unterschied zur starren Dimensionierung eines physischen Systems lassen sich Cloud-Ressourcen – und damit die Kosten – oft gut an den tatsächlichen Bedarf anpassen, sollte sich dieser später ändern.

Nebst "geglätteten" Kosten sind je nach Konstellation auch echte Einsparungen möglich. Bei den meisten Workloads schwankt die Auslastung im Tages-, Wochen- oder Jahresverlauf stark. Muss ein neues System zum Beispiel für die Lastspitzen am Quartalsende ausgelegt werden, liegt bei eigener Hardware die teuer bezahlte Kapazität den Rest des Jahres brach. Im Unterschied dazu kann Cloud-Infrastruktur nach Bedarf hinzugebucht werden und verursacht nur so lange Kosten, wie sie auch tatsächlich benötigt wird.

Kein Hardware-Management – reduzierter Overhead

Nebst der rein finanziellen Betrachtung sind es jedoch vor allem die praktischen Aspekte, mit denen die Cloud punktet. So verursacht das Handling von Hardware über den gesamten Lebenszyklus hinweg immer wieder Aufwand, von der Evaluation über die Inbetriebnahme und den Ersatz von defekten Komponenten bis hin zur Ablösung durch ein nächstes System. Hinzu kommt der Betrieb eines eigenen Serverraums oder der Anfahrtsweg zu einem externen Server-Housing und natürlich die Netzwerk-Anbindung am jeweiligen Standort.

Demgegenüber bietet eine Cloud-Infrastruktur das sprichwörtliche Rundum-Sorglos-Paket. Der Betrieb in professionellen, sorgfältig ausgewählten und zertifizierten Rechenzentren gewährleistet die physische Sicherheit der Daten. Dank rollendem Lifecycle-Management im Hintergrund haben Kunden jederzeit Zugriff auf aktuelle Hardware, während die Spezialisten des Cloud-Anbieters für deren Überwachung und Pflege sorgen. Und durch Redundanz sowie Kapazitätsreserven wird der Impact von Hardware-Problemen auf die Workloads der Kunden minimiert. Anders als es bei eigenen Servern oft der Fall ist, sind Cloud-Systeme auch über mehrere Pfade im Internet vernetzt. Dies schützt nicht nur die Erreichbarkeit des eigenen Service vor Downtimes durch eine ausgefallene Leitung, sondern verkürzt oft auch die Latenz zu den eigenen Besuchern bzw. Kunden und hilft so, die Kundenzufriedenheit zu verbessern.

Agiler und sicherer Tag für Tag

Ist der erste Schritt in die Cloud getan, eröffnen sich eine Vielzahl weiterer Optimierungsmöglichkeiten. Indem neue Server nicht aufwändig und teuer beschafft werden müssen, sondern auf Knopfdruck bereitstehen, werden z.B. Upgrades und Migrationen fast ohne Downtime möglich: ein neues System wird im Hintergrund eingerichtet, und der produktive Traffic zum Zeitpunkt X einfach umgeschwenkt. Mit mehreren parallel betriebenen Servern sind Load-Balancing- und Failover-Setups möglich, welche die Ausfallsicherheit weiter erhöhen. Dank "Anti-Affinity" kann zudem sichergestellt werden, dass diese Server beim Cloud-Anbieter tatsächlich auf verschiedenen physischen Maschinen laufen. Besonders hohe Anforderungen können durch geo-redundante Setups mit räumlich getrennten Server- bzw. Cloud-Standorten erfüllt werden.

Genauso wichtig wie der stabile Betrieb von produktiven Systemen ist auch die Flexibilität im Alltag. Indem sich neue Server nach Bedarf erstellen und wieder löschen lassen, können Techniker schnell und ohne Risiko neue Tools testen, ein Problem nachstellen oder einen heiklen Vorgang "trocken" üben. Auch im Verkauf von technischen Lösungen sowie bei Schulungen hilft es, wenn Kunden sich gefahrlos auf einem eigenständigen Demo-System austoben können. Dabei lässt sich das Bereitstellen und Aufräumen solcher kurzlebigen Instanzen dank Integration der Cloud-APIs in die gängigen DevOps-Tools (wie z.B. Ansible und Terraform) weitestgehend automatisieren.

Vor fünf Jahren ging das IaaS-Angebot von cloudscale.ch live, und seither freuen wir uns über ein kontinuierliches Wachstum. Auch unsere Benutzer bestätigen uns die Vorteile einer Cloud-Lösung gegenüber einem traditionellen Setup immer wieder – nicht nur als Beitrag zu einem besseren Gesamtprodukt für ihre Endkunden, sondern auch zur Erleichterung ihrer eigenen Arbeitsabläufe. Mit den vielseitigen Gründen, die für Cloud-Infrastruktur sprechen, wird aber auch deutlich: das Potenzial ist noch lange nicht ausgeschöpft, und künftig werden noch viele weitere, vielleicht weniger offensichtliche Anwendungsfälle von der Flexibilität einer Cloud-Infrastruktur profitieren.

Hält Ihnen alle Optionen offen,
Ihr cloudscale.ch-Team

PS: Obwohl wir bei cloudscale.ch die Serverpreise für jeweils 24 Stunden ausweisen, profitieren Sie von sekundengenauer Abrechnung: Die unbenutzte Zeit schreiben wir Ihrem Konto-Guthaben wieder gut, sobald Sie einen Server löschen. So haben Sie auch für sehr kurze Einsätze immer die passenden Ressourcen zur Hand.

Nebst Terraform ist Ansible eines der beliebtesten IT-Orchestrierungs-Werkzeuge. Bei cloudscale.ch verwenden wir Ansible intern z.B. zum Verwalten unserer Netzwerkkomponenten und praktisch der gesamten Cloud-Infrastruktur. Und natürlich sind wir bestrebt, auch unseren Kunden das Konfigurieren und Betreiben von Cloud-Ressourcen so einfach wie möglich zu gestalten.

Mit Ansible 2.10 wurde die Entwicklung und Pflege von Community-Plugins in sogenannte "Collections" ausgelagert. Viele Plugins fanden in der Collection "community.general" ein neues Zuhause, bei anderen, wie z.B. der cloudscale.ch-Integration, wurde die Entwicklung in eigene Quellcode-Repositories und Organisationen abgespalten, um eine schnellere Entwicklung und eigene Releasezyklen zu ermöglichen. So gibt es heute bereits rund 75 selbstorganisierende Collections für Ansible 2.10.

Mit unserer eigenen Ansible Collection "cloudscale_ch.cloud" erreichen wir gleich mehrere Vorteile: Zum einen können wir Erweiterungen unserer API zeitnah in unseren Plugins abbilden, zum anderen lassen sich unsere Plugins einfacher und unabhängig vom restlichen Ansible-Projekt automatisiert testen.

Die passende Version für jeden Bedarf

Die 3-wöchentlich bereitgestellten Releases von Ansible 2.10 beinhalten auch die neusten Releases der Collections, d.h. die jeweils neuste Version von "cloudscale_ch.cloud" wird automatisch im offiziellen Ansible-Paket ausgeliefert und mitinstalliert. Wer ausserhalb dieses Releasezyklus einen bestimmten Feature-Umfang nutzen möchte, kann mittels ansible-galaxy selbst Hand anlegen und die gewünschte Version unserer Collection auch mit seiner vorhandenen Ansible-Version verwenden.

Der Nachvollziehbarkeit wegen empfehlen wir, eine Datei requirements.yml zu erstellen, um über alle externen Collections wie auch Rollen die Übersicht zu behalten:

collections:
  - name: cloudscale_ch.cloud
    version: 1.3.0

Danach kann die Collection wie gewohnt über ansible-galaxy installiert werden:

ansible-galaxy collection install -r requirements.yml

Zu beachten ist, dass bisherige Playbooks ohne Anpassungen weiter funktionieren. Nur bei Plugins, welche seit Ansible 2.10 neu dazugekommen sind, muss zwingend der "Fully Qualified Collection Name" (FQCN) verwendet werden. Es spricht aber nichts dagegen, auch in bestehenden Playbooks generell auf FQCN umzustellen.

Wie gehabt ohne FQCN:

- cloudscale_server:
    name: web1.example.com
    ...

Oder entsprechend mit FQCN:

- cloudscale_ch.cloud.server:
    name: web1.example.com
    ...

Beispiel 1: Netzwerk-Management mit Subnets

In Version 1.2.0 unserer Collection wurde die Network-API integriert. Mit der aktuellsten Version 1.3.0 lassen sich nun zusätzlich auch Subnets verwalten. Dabei können Subnets angelegt und bei bestehenden Subnets die Gateway-IP sowie die DNS-Server angepasst werden:

- name: Ensure network exists
  cloudscale_ch.cloud.network:
    name: Private in LPG1
    zone: lpg1
    auto_create_ipv4_subnet: false

- name: Ensure subnet exists
  cloudscale_ch.cloud.subnet:
    cidr: 10.11.0.0/16
    gateway_address: 10.11.0.1
    dns_servers:
      - 10.11.0.2
      - 10.11.0.3
    network:
      name: Private in LPG1
      zone: lpg1

Beispiel 2: Objects Users

Bereits mit Version 1.1.0 unserer Collection – und somit gleich in Ansible 2.10.0 – hinzugekommen ist das Modul zum Verwalten von Objects Users. Dieses erlaubt zum Beispiel das automatisierte Erstellen einer Backup-Konfiguration mit Verwendung unseres Object Storage:

- name: Create a backup user
  cloudscale_ch.cloud.objects_user:
    display_name: backup for ACME
    tags:
      customer: ACME Inc.
  register: res_object_user

- name: Configure S3cfg
  template:
    src: s3cfg.j2
    dest: ~/.s3cfg

Im Template s3cfg.j2 verwenden wir die vom Modul zurückgelieferten Keys:

# {{ ansible_managed }}
[default]
access_key = {{ res_object_user.keys.access_key }}
secret_key = {{ res_object_user.keys.secret_key }}
check_ssl_certificate = True
guess_mime_type = True
host_base = objects.lpg.cloudscale.ch
host_bucket = objects.lpg.cloudscale.ch
use_https = True

Beispiel 3: Floating IPs

Auch bestehende Module haben Verbesserungen erfahren; so ist es nun möglich, Floating IPs idempotent zu erstellen. Dies wurde durch einen zusätzlichen name Parameter realisiert. Um die Rückwärtskompatibilität zu gewährleisten, ist dieser Parameter zurzeit noch optional. Erst ab der nächsten Majorversion unserer Collection wird dieser Parameter zwingend mit angegeben werden müssen.

- name: Start cloudscale.ch server
  cloudscale_ch.cloud.server:
    name: mx1.example.com
    image: debian-10
    flavor: flex-2
    ssh_keys: ssh-rsa XXXXXXXXXX...XXXX ansible@cloudscale-ch
    zone: lpg1
  register: server

- name: Request Floating IPs for my server
  cloudscale_ch.cloud.floating_ip:
    name: mx1.example.com
    ip_version: "{{ item }}"
    reverse_ptr: mx1.example.com
    server: "{{ server.uuid }}"
  with_items:
    - 4
    - 6

Mit Ansible und unserer "cloudscale_ch.cloud" Collection steht Ihnen ein mächtiges und dennoch einfaches Werkzeug zur Verfügung, um selbst eine grössere Cloud-Infrastruktur sowohl schnell als auch nachvollziehbar zu erstellen und zu betreiben. Und für alle, die sich (wie wir) für Open-Source engagieren: Der Quellcode unserer Collection steht unter der GPLv3 und ist auf GitHub verfügbar.

Stolzer Teil des Ansible-Universums,
Ihr cloudscale.ch-Team

Bereits heute sind Ihre Server bei cloudscale.ch dank einer breiten Palette an vorgefertigten Images beliebter Linux-Distributionen und Security-Appliances blitzschnell betriebsbereit. Weitere Betriebssysteme lassen sich zudem manuell via ISO-/USB-Images installieren. Neu können Sie das Beste aus beiden Welten kombinieren: Dank Ihren eigenen, individuellen Images erstellen Sie neue Server schnell und einfach – bei voller Flexibilität in Bezug auf vorinstallierte Software und Konfiguration.

Mit eigenen Images decken Sie jetzt viele Anwendungsfälle noch eleganter ab. So können Sie Tools, die Sie auf Ihren Servern sowieso installieren würden, nun direkt in Ihr eigenes Image integrieren – denkbar sind z.B. Pakete für Monitoring und Konfigurations-Management sowie Utilities, die Ihnen die tägliche Arbeit erleichtern. Oder benötigen Sie Ihren Server für einen bestimmten Zweck, für den es bereits eine spezialisierte Distribution oder Appliance gibt? Importieren Sie diese dazu einfach als Custom Image und legen Sie los.

Image-Management via API

Eigene Images importieren Sie in Ihren cloudscale.ch-Account über einen simplen API-Call. Schon kurz darauf können Sie auf dieser Basis neue Server erstellen; Ihr eigenes Image referenzieren Sie dabei zum Beispiel über seine eindeutige UUID, die ihre Gültigkeit behält, solange das Image in Ihrem Account existiert. Alternativ geben Sie den "Slug" an, den Sie beim Hinzufügen des Image festgelegt haben, ergänzt um das Präfix custom:. Dies ist insbesondere dann praktisch, wenn Sie künftig möglichst nahtlos neuere Image-Versionen aufnehmen möchten: von mehreren Versionen, denen Sie bspw. den Slug "voip-pbx" gegeben haben, wird beim Start eines neuen Servers unter Angabe von custom:voip-pbx automatisch das jeweils neuste Image verwendet.

Um ein Image in Ihren Account zu importieren, geben Sie im API-Call einfach die HTTP(S)-Adresse an, unter der das Image verfügbar ist. Unser System lädt dann das Image direkt von dieser URL und stellt es an den gewünschten Cloud-Standorten für Sie bereit. Falls Sie Ihr Image lokal erstellen/bearbeiten und keinen Webserver zur Hand haben, bietet sich unser Object Storage an: nach dem Hochladen des Image (z.B. mit s3cmd --acl-public put ...) in einen Bucket Ihrer Wahl geben Sie im API-Call nur noch die resultierende URL https://BUCKET.objects.LOCATION.cloudscale.ch/IMAGE an.

Tipps zur Vorbereitung

Im einfachsten Fall stellt Ihre Wunsch-Distribution eine Image-Datei zur Verfügung, die Sie "eins zu eins" bei cloudscale.ch importieren können. Stehen mehrere Image-Dateien zur Auswahl, deutet oft ein "OpenStack" oder "cloud" im Namen auf die passende Version hin. Beachten Sie hier einzig, dass die Image-Datei im "raw"-Format vorliegen muss; bei Bedarf konvertieren Sie das Image z.B. mittels qemu-img (meist im Paket qemu-utils oder qemu-img-2):

qemu-img convert -f qcow2 -O raw my-image.qcow2 my-image.raw

Den maximalen Nutzen erzielen Sie jedoch, indem Sie Ihr Image spezifisch auf Ihre Bedürfnisse anpassen und häufig benutzte Tools gleich vorinstallieren. Ein möglicher Weg dafür wäre ein virtueller Server, den Sie z.B. auf Basis von QEMU/KVM bei sich lokal installieren und darin Ihre Muster-Installation zusammenstellen. Die Datei, welche als virtuelle Festplatte dient, können Sie dann (ggf. nach Konvertierung zu "raw") gleich als Custom Image für Ihre künftigen Cloud-Server importieren und verwenden. Falls Sie eine Vielzahl von Images pflegen oder diese häufig aktualisieren, lässt sich der Prozess mit spezialisierten Werkzeugen wie "Packer" zudem automatisieren.

Achten Sie beim Erstellen Ihrer Images darauf, dass diese auch in einem leicht veränderten Umfeld booten – so wird z.B. jeder Cloud-Server, den Sie auf Basis Ihres Image erstellen, eine eigene IP- und MAC-Adresse erhalten. Falls nicht ohnehin bereits in Ihrem Setup enthalten, empfiehlt sich hier cloud-init: Dieses nützliche Paket ist im Cloud-Umfeld der De-facto-Standard und kann beim ersten Booten eines Servers viele Parameter automatisch einstellen. Zudem wertet es die "User Data" aus, die Sie beim Starten eines Servers angeben können, und erlaubt damit die weitere automatisierte Einrichtung Ihrer Server gleich beim ersten Bootvorgang.

Hinterlegen Sie pro Cloud-Standort diejenigen Images, die für Ihre künftigen Server bereits perfekt vorbereitet sind – verrechnet wird nur der effektiv dafür benötigte Speicherplatz auf unserem SSD-Storage. Anpassungen, die Sie einmalig in Ihre Images einpflegen, sind eine Investition, von der Sie bei jedem zusätzlichen Server erneut profitieren.

Vorbereitung ist alles!
Ihr cloudscale.ch-Team

Jeder Server bei cloudscale.ch verfügt über ein "root-Volume" auf NVMe-SSDs, das nach dem erstmaligen Starten das gewählte Betriebssystem enthält. Bei fast allen Images lässt sich die Grösse dieses Volumes beim Erstellen des Servers festlegen, so dass auch Ihre Daten auf diesem Volume Platz finden. Sollte Ihr Projekt und damit der Platzbedarf später wachsen, lässt sich das root-Volume einfach und im laufenden Betrieb weiter hochskalieren.

Daneben kann es sinnvoll sein, einen Teil der Daten auf separaten Volumes zu speichern. So bieten sich Bulk-Volumes an, wenn günstiger Speicherplatz benötigt wird und die Performance eine untergeordnete Rolle spielt, z.B. bei Archiv-Daten. Für eine Datenbank wiederum, die Sie logisch vom Rest des Systems separieren möchten, wäre ein zusätzliches SSD-Volume das Mittel der Wahl. Solche zusätzlichen Volumes können Sie ebenfalls gleich beim Erstellen eines Servers mit anlegen, oder sie später dem Server hinzufügen und bei Bedarf vergrössern. Darüber hinaus können zusätzliche Volumes jederzeit an einen anderen Server "umgehängt" oder gelöscht werden.

Persistent Volumes in Container-Setups

Eine besondere Bedeutung haben zusätzliche Volumes für moderne Container-Setups. Container bzw. Pods sind standardmässig flüchtig; werden sie durch eine neue Instanz oder eine neue Version ersetzt, sind die Daten normalerweise weg. Sollen die Daten jedoch erhalten bleiben, kann dem Pod ein "Persistent Volume" zugewiesen werden – ein zusätzliches Volume, um Daten dauerhaft zu speichern. Dank dem "Container Storage Interface" (CSI) lassen sich solche Persistent Volumes durch einen Container-Orchestrator wie Kubernetes automatisiert anlegen und direkt an den richtigen Node anhängen, so dass der dort laufende Pod darauf zugreifen kann.

cloudscale.ch unterstützt neu bis zu 128 Volumes pro virtuellem Server und bietet damit auch dichtgepackten Container-Setups genügend Spielraum. Skalieren Sie Ihren Cluster hoch und migrieren Sie Workloads zwischen den Nodes; via CSI werden die definierten "Persistent Volume Claims" (PVC) automatisch erfüllt und der Speicher steht am richtigen Ort zur Verfügung. Falls Sie unseren CSI-Treiber bereits verwenden, achten Sie darauf, diesen auf die neuste Version zu aktualisieren.

Technischer Hintergrund

Die Unterstützung von bis zu 128 Volumes pro virtuellem Server wurde möglich, indem wir die Technik im Hintergrund umgestellt haben: neu erstellte virtuelle Server verwenden für die Volumes virtio-scsi statt virtio-blk. Damit ist die Anzahl Volumes nicht mehr durch die Anzahl der unterstützten PCI-Devices limitiert. Zudem haben wir in OpenStack, auf dem unsere Cloud aufbaut, einen Bug gepatcht. Dieser bewirkte, dass – zusätzlich zur Limitierung der PCI-Devices – höchstens Volumes von vda bis vdz verwendet werden konnten, also maximal 26 an der Zahl.

Für Sie als Nutzer ändert sich nur die Benennung der Volumes: statt vda, vdb etc. finden Sie in Ihrem virtuellen Server neu das Volume sda und ggf. weitere sdX. Damit entfällt auch einer der Hauptunterschiede, die es beim Umstieg von einem physischen Computer auf einen Linux Cloud-Server zu beachten galt. Wird tatsächlich eine Vielzahl an Volumes genutzt, setzt sich die Nummerierung nach sdz mit sdaa fort, bis hin zu sddx beim aktuellen Maximum von 128 Volumes. Bitte prüfen Sie ggf. in Ihren Tools oder Scripts, dass bei Operationen auf Volumes und Partitionen die neuen Bezeichnungen verwendet werden.

Beispiel mit zwei Volumes in einem Ubuntu-Server:

ubuntu@my-server:~$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
[...]
sda       8:0    0   50G  0 disk
├─sda1    8:1    0 49.9G  0 part /
├─sda14   8:14   0    4M  0 part
└─sda15   8:15   0  106M  0 part /boot/efi
sdb       8:16   0  100G  0 disk
└─sdb1    8:17   0  100G  0 part
sr0      11:0    1  478K  0 rom

Mit bis zu 128 Volumes pro virtuellem Server sind Sie nun auch für grosse Container-Setups gerüstet. Die Nutzung von Kubernetes und CSI ist aber keine Voraussetzung; selbstverständlich kommt die zusätzliche Flexibilität auch anderen Anwendungsfällen zugute – von ausgefeilten LVM-Konfigurationen bis zur sauberen Trennung verschiedener Datenbestände.

Das richtige Volume für jeden Zweck!
Ihr cloudscale.ch-Team

Daten-Standort und anwendbares Recht

Der Begriff "Cloud" kommt ursprünglich aus Netzwerk-Diagrammen: Dort steht das Wolkensymbol für Netzwerke, deren Details nicht weiter relevant sind, wie zum Beispiel das Internet. Seit in dieser Wolke immer mehr und immer wichtigere Daten verarbeitet werden, rücken die Details jedoch zunehmend in den Fokus. In Gesetzen und Compliance-Vorgaben finden sich immer mehr Bestimmungen zur Cloud-Nutzung. Und nicht zuletzt schärfen Medienberichte sowie die täglichen Tracking- und Beeinflussungsversuche die Wachsamkeit im Hinblick darauf, wo die eigenen Daten landen und potenziell ausgewertet werden.

Gerade dem geographischen Ort, wo Daten verarbeitet werden, kommt dabei eine zentrale Bedeutung zu. Denn er bestimmt zu einem Grossteil, welche gesetzlichen Regelungen anwendbar sind – zusätzlich zu denen, die für den Besitzer der Daten an seinem Standort ohnehin gelten. Für Schweizer Unternehmen ist es entsprechend am einfachsten, wenn sich auch ihre Daten in der Schweiz befinden. Genauso wichtig ist aber, wem die Daten anvertraut werden, denn ausländische Dienstleister unterstehen auch Gesetzen in ihrem jeweiligen Heimatland. Jurist Simon Schlauri nennt in einem Interview als Beispiel den CLOUD Act in den USA: Amerikanische Cloud-Anbieter müssen auf Anordnung ihrer Behörden unter Umständen auch Daten herausrücken, die in einem fremden Hoheitsgebiet gespeichert sind.

"swiss hosting" bietet Orientierungshilfe

Das neue Label "swiss hosting" schafft hier mehr Klarheit. Träger dieses Labels sind SaaS- und Cloud-Anbieter, die schweizerischem Recht unterstehen und Gewähr bieten, dass keine ausländischen Organisationen auf die Daten ihrer Kunden zugreifen können. Sollte das eigentliche Hosting dieser Daten ausgelagert sein, so muss auch der jeweilige Hosting-Anbieter die gleichen Regeln einhalten. Gerade für Firmen, die mit ihren eigenen Kundendaten sorgsam umgehen müssen, bietet "swiss hosting" eine wichtige Orientierung bei der Wahl eines SaaS- oder Cloud-Anbieters und hilft, den Aufwand für Compliance-Abklärungen klein zu halten.

[…] dass die Daten weiterhin vollständig in der Schweiz bleiben und weder direkt noch indirekt von einer ausländischen Organisation oder Regierung eingesehen oder eingefordert werden können. Dies gilt auch für ausländische Konzerngesellschaften.

Ausschnitt zum Zugriffsschutz aus dem "swiss hosting" Vertrag

cloudscale.ch ist als Launch-Partner von Anfang an bei "swiss hosting" dabei. Als rein schweizerischer Cloud-Anbieter, der ausschliesslich auf Rechenzentren mit Standort Schweiz setzt, tragen wir dieses Label in Bezug auf all unsere Services. Mit dieser klaren Positionierung sind wir auch der ideale Hosting-Partner für SaaS-Anbieter und Managed Service Provider, die mit dem Label "swiss hosting" ihren eigenen Kunden die Sicherheit geben wollen, dass die Daten in der Schweiz gehostet werden.

Swissness als Leitidee

Auch über die Wahl der Rechenzentren hinaus setzte cloudscale.ch von Beginn an konsequent auf den Standort Schweiz, denn "Swissness" bedeutet für uns noch viel mehr. So schätzen unsere Kunden, dass sie mit uns einen Partner in der Nähe haben, der ihre Sprache spricht und ihre Anliegen ernst nimmt. Hinzu kommen handfeste technische Vorteile: so ist cloudscale.ch nicht nur international, sondern auch mit Schweizer Netzwerk-Betreibern hervorragend vernetzt und ermöglicht damit tiefe Latenz-Zeiten von bzw. zu den lokalen Internet-Benutzern.

"Schweizer Qualität" bedeutet für uns auch, sich Zeit zu nehmen und auf Details zu achten. In unserem selbst entwickelten Cloud-Control-Panel steckt viel Liebe, um die Nutzung unserer Cloud so einfach wie möglich zu machen. Und nicht zuletzt – ebenfalls typisch schweizerisch – pflegen wir die Zusammenarbeit mit unseren Partnern: basierend auf unserer Infrastruktur realisieren diese ausgefeilte Setups mit dem "Swiss Finish" nach individuellen Kundenvorgaben.

Während die internationale Rechtslage schwierig zu durchschauen sein kann und noch eine Reihe offener Fragen bereithält, bietet "swiss hosting" einen pragmatischen Weg. Indem die Daten in der Schweiz bleiben, machen Sie sich und Ihren Kunden das Leben leichter. Über die reinen Compliance-Fragen hinaus bedeutet "Swissness" bei cloudscale.ch aber auch: wir sind für unsere Kunden ein lokaler und nahbarer Partner.

Auf gute Zusammenarbeit,
Ihr cloudscale.ch-Team

Die cloudscale.ch CLI-Anwendung ist in Python geschrieben und lässt sich mittels pip install cloudscale-cli im Handumdrehen installieren. Nach der Installation finden Sie neu den Befehl cloudscale, mit dem Sie Ihre Cloud-Ressourcen ansehen, ändern, neue erstellen und auch wieder entfernen können.

Die CLI-Anwendung eignet sich zudem zur Verwendung in Scripts, insbesondere bei Angabe der Option --output json. So decken Sie jetzt elegant auch Anwendungsfälle ab, die Sie schon lange automatisieren wollten, für die aber der Einsatz eines mächtigen Werkzeugs wie Rancher oder Terraform nicht wirklich passte.

Eine Liste aller Parameter und der unterstützten Cloud-Ressourcen finden Sie durch Ausführen von cloudscale --help. Informationen über Installation, Konfiguration sowie Anleitungen finden Sie zudem online in der Projektdokumentation auf GitHub.

Anwendungsbeispiele

Die folgenden Beispiele zeigen, wie einfach und intuitiv die Verwaltung Ihrer Cloud-Ressourcen mit unserer CLI-Anwendung gelingt. Ihre bestehenden Server listen Sie beispielsweise wie folgt auf – mittels optionalem --filter-tag zusätzlich eingegrenzt auf Server, denen Sie ein bestimmtes Tag zugewiesen haben:

$ cloudscale server list --filter-tag project=beta

NAME    STATUS    ZONE    TAGS            UUID
------  --------  ------  --------------  ------------------------------------
app1    running   lpg1    project=beta    09d385c8-1e91-4775-a133-b4bbe860436f
app2    running   lpg1    project=beta    89813aa1-2a6a-42da-80f6-713feb785ca9

Ein einzelner Server wie auch mehrere identische Server können mit dem Befehl cloudscale create erstellt werden, durch die Option --count geben Sie die gewünschte Anzahl der Server an:

$ cloudscale server create --flavor flex-2 --image debian-10 --ssh-key "$(cat ~/.ssh/id_ed25519.pub)" --tag project=gemini --count 3 --name 'web{counter}' --wait

Beachten Sie, dass der Name mit {counter} ergänzt wurde. Dies ermöglicht es, alle drei Server unterschiedlich zu benennen: web1, web2 sowie web3.

Mit der Option --wait wird erreicht, dass der Befehl erst abgeschlossen wird, wenn der Endzustand status=running aller zu erstellenden Server erreicht ist.

Ergänzen Sie die Funktion list mit --action bzw. --delete, können Sie auch mehrere Server in einem Durchgang stoppen, starten und neustarten bzw. löschen:

$ cloudscale server list --filter-tag project=gemini --delete
NAME    STATUS    ZONE    TAGS            UUID
------  --------  ------  --------------  ------------------------------------
web4    running   lpg1    project=gemini  5d461dfa-a92a-4c7b-9199-c02ed7b6b570
web3    running   lpg1    project=gemini  54071101-8586-4af7-a5d1-25649fd6b2b2
Do you want to delete? [y/N]

Mit der Option --verbose erweitert sich die Ausgabe um zusätzliche Informationen.

Gut zu wissen

Als "Komfortfunktion" erlaubt es unsere CLI-Anwendung zudem, direkt eine SSH-Verbindung zu Ihren Servern aufzubauen: cloudscale server ssh web1. Damit ersparen Sie sich den Umweg, zuerst die IP-Adresse auflisten zu lassen, um danach umständlich mittels Kopieren und Einfügen in die Konsole Ihren SSH-Befehl zusammenzustellen.

Haben Sie Anregungen oder Änderungswünsche? Der Quellcode unserer CLI-Anwendung ist Open-Source und steht unter der MIT-Lizenz. Wir freuen uns auf Ihr Feedback.

Bei cloudscale.ch belegte "Usability" von Anfang an einen der Spitzenplätze unserer Prioritätenliste: Während unser Cloud-Control-Panel möglichst einfach und intuitiv zu benutzen sein sollte, erlaubten die API und die Integration in verschiedene DevOps-Tools maximale Effizienz. Mit der neuen CLI-Anwendung erstellen Sie nun auch einzelne Server genauso schlank, wie Sie sie anschliessend managen: auf der Kommandozeile.

Konzentriert auf das Wesentliche,
Ihr cloudscale.ch-Team

Die TLS-Versionen 1.0 und 1.1 werden auf allen aus dem Internet erreichbaren Systemen von cloudscale.ch deaktiviert. Dazu gehören insbesondere auch die folgenden Systeme, die Sie bzw. Ihre Endkunden potenziell nutzen:

• Cloud-Control-Panel und API zur Verwaltung Ihrer Cloud-Ressourcen
• S3-kompatibler Object Storage

Die Umstellung erfolgt in zwei Schritten: am 11.08.2020 deaktivieren wir diese TLS-Versionen auf unserem Object Storage am Standort "LPG". In der darauffolgenden Woche, am 18.08.2020, erfolgt die gleiche Umstellung auf dem Object Storage am Standort "RMA" sowie für unser Cloud-Control-Panel und die API. Die Umstellungen können ohne Unterbruch unserer Services vorgenommen werden.

Keine Beeinträchtigung erwartet

TLS (Transport Layer Security) wurde 1999 als Nachfolger der SSL-Verschlüsselung spezifiziert und wird im Alltag bis heute gelegentlich noch als "SSL" bezeichnet. Obwohl mit der TLS-Version 1.1 aus dem Jahr 2006 einige Verbesserungen eingeführt wurden, blieben dennoch grundlegende Einschränkungen bestehen, die man aus heutiger Security-Sicht als überholt bezeichnen muss.

Bereits 2008 wurde TLS 1.2 veröffentlicht, das inzwischen von allen modernen Applikationen unterstützt wird – sowohl seitens Server-Software als auch von den entsprechenden Clients wie z.B. Webbrowsern. Daher rechnen wir mit keinerlei Problemen für unsere Kunden; der Zugriff auf unsere Systeme wird mit TLS 1.2 oder dem noch neueren TLS 1.3 auch in Zukunft wie erwartet funktionieren.

Im Zweifelsfall empfehlen wir Ihnen trotz der breiten Unterstützung von TLS 1.2, Ihre eingesetzten Tools zu prüfen, insbesondere bei älteren oder wenig verbreiteten Clients, die – z.B. in einem Failover-Szenario – auf unsere API zugreifen müssen.

Alte TLS-Versionen kaum noch relevant

Gemäss einer Auswertung auf unseren Systemen finden kaum noch Zugriffe unter Verwendung von TLS 1.0 oder 1.1 statt; soweit sie überhaupt noch vorkommen, sind sie im Promille-Bereich. Angesichts der durchgängigen Unterstützung von TLS 1.2 und teils bereits 1.3 in allen modernen Client-Applikationen sind diese Zahlen nicht weiter erstaunlich. Die verbreitetsten Internet-Browser verzichten ab diesem Jahr sogar ganz auf die Unterstützung der alten TLS-Versionen.

Die Deaktivierung von veralteten Sicherheitsprotokollen, die in der Praxis sowieso keine Rolle mehr spielen, ist für uns ein unspektakulärer, selbstverständlicher Schritt im Interesse der allgemeinen IT-Sicherheit. Sollten Sie in diesem Zusammenhang wider Erwarten Probleme feststellen, steht Ihnen unser Support-Team natürlich gerne zur Verfügung.

Freundliche Grüsse,
Ihr cloudscale.ch-Team

Cumulus Linux, das Netzwerk-Betriebssystem auf Debian-Basis, macht erfahrenen Network Engineers den Einstieg leicht: Die wichtigen Einstellungen sind via CLI erreichbar, wobei sich das Interface an CLIs verbreiteter Hersteller orientiert. Dadurch finden sich Netzwerk-Spezialisten in der neuen Umgebung schnell zurecht und können auf dem Wissen aufbauen, welches sie sich bereits anderswo angeeignet haben. Auch nützliche Features, die sich in der Branche erst nach und nach durchsetzen, stehen auf Netzwerk-Geräten mit Cumulus Linux standardmässig zur Verfügung; so ist es z.B. möglich, einen Block von Kommandos in einem Rutsch anzuwenden – und auch wieder rückgängig zu machen.

Dass Cumulus Linux auf Debian basiert, eröffnet jedoch zusätzliche, entscheidende Möglichkeiten. Ein Login führt nicht in das vertraute, aber eingeschränkte CLI, sondern direkt in eine Linux-übliche Shell. Dabei ist das CLI zwar nur ein Kommando entfernt, vor allem aber kann man dank vollem root-Zugriff auch all die anderen Tools nutzen, die sich im Alltag eines System Engineers als unverzichtbar erweisen: von Utilities wie htop und watch über ein Config-Management (z.B. Ansible) bis hin zum Monitoring mittels Zabbix-Agent.

Effizienz durch Config-Management

Insbesondere die Möglichkeit, Netzwerk-Geräte mittels Config-Management zu verwalten, werden viele Cumulus-Anwender nicht mehr missen wollen. Während wir bei cloudscale.ch für das Server-Management schon länger auf Ansible setzen, ist dank Cumulus Linux nun auch die Verwaltung von Netzwerk-Geräten mittels Ansible möglich. In der einfachsten Form übernimmt Ansible die Bedienung des "NCLU" (Network Command Line Utility) genannten CLI: Mit vertrauten Kommandos lassen sich zahlreiche Switches und Router ohne manuelles Zutun einheitlich konfigurieren.

Das volle Potenzial lässt sich jedoch erst mit Jinja-Templates ausschöpfen: Statt langer Abfolgen einzelner Kommandos, bei denen man leicht die entscheidenden Variationen übersieht, pflegt man Templates in relativ kurzen und übersichtlichen Files. Dank dem Einsatz von Loops und Conditionals lassen sich lange und komplexe Konfigurationen übersichtlicher darstellen. Das Risiko von Flüchtigkeitsfehlern (z.B. inkonsistente MTU- oder VLAN-Konfigurationen) verringert sich dadurch massiv.

Die folgenden Ausschnitte illustrieren, wie wir mit dem Ansible Template-Modul /etc/network/interfaces auf unseren Switches populieren.

Ansible Inventory Variablen:

vrfs:
  mgmt:
    description: VRF Mgmt
    ipv4_address: 127.0.0.1/8
  quarantine:
    description: VRF Quarantine (for test purposes)
    ipv4_address: '{{ "10.0.0.0/24" | ipaddr(device_id) | ipaddr("address") }}/32'
  private:
    description: VRF Private (networks without a default gateway)
  public:
    description: VRF Public (networks with a default gateway)
    ipv4_address: '{{ "203.0.113.0/24" | ipaddr(device_id) | ipaddr("address") }}/32'
    ipv6_address: '{{ "2001:db8:bb::/64" | ipaddr(device_id) | ipaddr("address") }}/128'
  dci:
    description: VRF DCI (networks on data center interconnect)
    ipv4_address: '{{ "172.16.16.0/24" | ipaddr(device_id) | ipaddr("address") }}/32'

Jinja2 Template:

{% for name, vrf in vrfs.items() if name != "default" -%}
# {{ vrf.description }}
auto {{ name }}
iface {{ name }}
    {% if vrf.ipv6_address is defined -%}
    address {{ vrf.ipv6_address }}
    {% endif -%}
    {% if vrf.ipv4_address is defined -%}
    address {{ vrf.ipv4_address }}
    {% endif -%}
    vrf-table auto

{% endfor -%}

Komplett automatisiertes Provisioning

Die laufende Pflege der Konfiguration ist aber nur die halbe Miete. Wir haben uns entschieden, grössere Upgrades unserer Switches jeweils in Form einer kompletten Neuinstallation durchzuführen. Dadurch wird ein reproduzierbarer Zustand sichergestellt, und wir können den Upgrade-Prozess sowie andere Änderungen im Lab vorgängig beliebig oft testen. Für diesen Zweck hat Cumulus Networks "ONIE" (Open Network Install Environment) entwickelt: Ähnlich dem von Servern bekannten PXE-Environment ermöglicht dieses offene System das Booten und die anschliessende Installation des Betriebssystems via Netzwerk. Mit "ZTP" (Zero-Touch Provisioning) lassen sich beliebige Settings bereits vorab festlegen, so dass das neu installierte System ohne manuellen Zwischenschritt direkt mit Ansible fertig provisioniert werden kann.

Der nachfolgende Ausschnitt aus unserer ZTP-Konfiguration automatisiert Schritte, die nach der Neuinstallation eines Switches typischerweise nötig sind.

Ausschnitt aus unserem ztp.sh:

[...]

# In order to start switchd, you need to install a valid license
echo 'user@example.com|3DSpMBACDihILepwdy4/5Ecd34jlAg4h+FiE/9zZawtujnk3Fw' > /home/cumulus/license.txt
/usr/cumulus/bin/cl-license -i /home/cumulus/license.txt
systemctl restart switchd.service

# Move the eth0 (management) interface to a separate management VRF
/usr/bin/net add vrf mgmt && /usr/bin/net commit

# Drop SSH keys in order to log in without using a password
{% for key in ssh_keys %}
echo "{{ key }}" >> /home/cumulus/.ssh/authorized_keys
{% endfor %}

# The following line is required somewhere in the script file for execution to occur
# CUMULUS-AUTOPROVISIONING

[...]

Bei uns dauert die Neuinstallation eines Switches mit Cumulus Linux weniger als 10 Minuten. Dies erlaubt es uns, Anpassungen an der Konfiguration, neue Versionen oder den Upgrade-Pfad dahin praktisch beliebig oft durchzuspielen. Steht dann das Upgrade der produktiven Geräte an, wenden wir bloss noch den mehrfach getesteten Prozess an; Vertipper und Verwechslungen sind damit praktisch ausgeschlossen. Übrigens: ONIE muss von der jeweiligen Hardware unterstützt werden – Cumulus Networks selbst stellt aber keine solche her. Dass innert kürzester Zeit praktisch alle grossen Netzwerk-Hersteller ONIE integriert haben, verdeutlicht, wie sehr diese elegante Lösung zuvor gefehlt hatte.

Dass Cumulus Linux seine Wurzeln in Debian und Open-Source hat, passt natürlich gut zu unserer Philosophie. Die "Open-Source-DNA" zeigt sich aber auch in umgekehrter Richtung: Cumulus Networks hat beispielsweise die Implementation von VRF (Virtual Routing and Forwarding) im Linux-Kernel beigesteuert. Dadurch sind die Bereiche "Server" und "Netzwerk" noch näher zusammengerückt.

Offen und effizient,
Ihr cloudscale.ch-Team

Jeder Server sollte auf einem aktuellen Stand gehalten werden – das gilt auch für unsere DNS-Systeme. Zudem möchten wir unser Nameserver-Setup am Standort Rümlang robuster machen und es damit an den neuen Standort Lupfig angleichen, den wir gleich von Anfang an mit diesen Optimierungen aufbauen konnten. Zu diesem Zweck richten wir die betreffenden Server am Standort "RMA" von Grund auf neu ein, wobei wir Schritt für Schritt vorgehen und so einen Unterbruch des Service für unsere Kunden vermeiden.

Für Ihre Server in der Region "RMA" steht künftig das folgende Set von IPv4- und IPv6-Adressen als DNS-Resolver zur Verfügung:

• IPv4: 5.102.144.101 und 5.102.144.102
• IPv6: 2a06:c01:f::101 und 2a06:c01:f::102

Diese DNS-Resolver sind ab sofort verfügbar und können ohne Einschränkung genutzt werden. Diese DNS-Konfiguration wird auch bereits via DHCP an Server zugewiesen, die von unseren DHCP-Servern eine IP-Adresse anfragen bzw. erneuern (ausgenommen hiervon sind private Netze, für die Sie via unsere API explizit ein abweichendes Set von DNS-Resolvern konfiguriert haben).

Bitte beachten Sie: Die IP-Adresse 5.102.148.102 wird per 15.08.2020 als DNS-Resolver ausser Betrieb genommen. Bitte stellen Sie sicher, dass Ihre Server diese IP nicht mehr für die Namensauflösung verwenden.

Die erwähnte Umstellung auf das neue Set von DNS-Resolvern gilt nur für Server in der Region "RMA" (Rümlang). Server in der Region "LPG" (Lupfig) verwenden ein separates Set von DNS-Resolvern, das von dieser Umstellung nicht betroffen ist.

Was Sie auf Ihren Servern prüfen sollten

Standardmässig benutzen neue Server bei cloudscale.ch DHCP für ihre jeweilige Netzwerk-Konfiguration. Server, bei denen Sie diese Einstellung unverändert gelassen haben, benötigen daher keine manuelle Änderung der Konfiguration. Prüfen Sie gegebenenfalls, dass Ihre Server mindestens zwei der genannten IPs tatsächlich in ihre DNS-Konfiguration übernommen haben.

Falls Sie die DNS-Einstellungen Ihrer Server manuell gesetzt haben, ändern Sie sie bitte auf das oben angegebene Set von DNS-Resolvern. Stellen Sie dabei sicher, dass die IP 5.102.148.102 nicht mehr als Resolver benutzt wird, da wir diese IP zum 15.08.2020 ausser Betrieb nehmen. Selbstverständlich steht es Ihnen auch frei, anstelle von unseren Systemen eigene DNS-Resolver oder einen externen DNS-Service zu benutzen.

Für Server, auf denen selbst ein recursing Resolver läuft (z.B. bei Firewall-Systemen auf Basis von OPNSense), ist keine Anpassung nötig.

Weitere Hinweise

In gewissen Firewall-Konfigurationen müssen zusätzlich die entsprechenden Firewall-Regeln angepasst werden, z.B. falls DNS-Antworten nicht automatisch akzeptiert werden, nachdem eine DNS-Anfrage verschickt wurde ("stateless" Firewalls).

Da die IP-Adresse 5.102.144.102 sowohl bisher als auch in Zukunft als DNS-Resolver zur Verfügung steht, rechnen wir im Standardfall selbst ohne die nötigen Anpassungen nicht mit einem Unterbruch der Namensauflösung. Beachten Sie jedoch, dass DNS-Lookups in diesem Fall erst mit einer Verzögerung funktionieren, falls zuerst ein falscher DNS-Server angefragt und erst nach einem Timeout auf einen weiteren Server ausgewichen wird. Von solchen Verzögerungen betroffen sein können auch SSH (typisches Symptom: längerer Login-Vorgang) und andere Services, wenn sie für Sicherheits- oder Logging-Zwecke IP-Adressen zu Hostnamen auflösen.

Wie erwähnt stehen Ihnen unsere redundant ausgelegten DNS-Resolver ab sofort unter dem neuen Set von IP-Adressen zur Verfügung. Für ein optimales Funktionieren der Namensauflösung ändern Sie bis zum 15.08.2020 die DNS-Einstellung Ihrer Server in der Region "RMA" wie oben beschrieben, bzw. überprüfen Sie, dass diese Änderung automatisch übernommen wurde. Server in der Region "LPG" sind von dieser Umstellung nicht betroffen und erfordern keine Aktion. Bei Bedarf steht Ihnen unser Support natürlich gerne zur Seite.

Freundliche Grüsse,
Ihr cloudscale.ch-Team

Sofort startklar dank cloud-init

Um einen neuen Cloud-Server innert Sekunden starten zu können, stellen die grossen Linux-Distributionen Images bereit, die im Wesentlichen ein Festplatten-Abbild des fertig installierten Betriebssystems enthalten. Ein neuer Server, als Klon von einem solchen Image erstellt, ist damit schon fast einsatzbereit; einige Details wie der Hostname oder die autorisierten SSH-Keys fehlen in diesem generischen Image jedoch und müssen noch individuell gesetzt werden.

Das in vielen Images enthaltene Paket cloud-init wird beim Systemstart aktiv und erledigt diese Einstellungen vollautomatisch. Wird erkannt, dass der spezifische Server zum ersten Mal startet, läuft das volle Programm; nebst dem Namen des Servers und den Zugangsdaten kümmert sich cloud-init z.B. auch um das Erstellen neuer SSH-Host-Keys. Deren öffentlicher Teil wird bei cloudscale.ch zudem auf die serielle Konsole ausgegeben – so können wir im Cloud-Control-Panel die Fingerprints anzeigen, damit Sie bereits beim ersten Einloggen überprüfen können, dass die Verbindung vertrauenswürdig ist. Bei nachfolgenden Systemstarts kann cloud-init für Sie beispielsweise das Filesystem vergrössern, falls Sie das virtuelle Volume Ihres Servers zwischenzeitlich skaliert haben.

Drehscheibe für die Config: Der Metadaten-Server

Daten wie Hostname und SSH-Key, die Sie beim Server-Launch angeben, speichern wir auf unserem Metadaten-Server. Hier kann cloud-init diese Daten abholen, um Ihren Server passend zu konfigurieren. Einer der Wege, um an die Daten zu kommen, ist die sog. "Magic IP": via DHCP erhält der Server eine spezielle Route zugewiesen, und cloud-init kann anschliessend seine Config von der URL http://169.254.169.254 abrufen. Neu stellen wir die Config zudem auch via "Config-Drive" zur Verfügung. Dabei sieht jeder neue Server ein virtuelles CD-ROM-Laufwerk (z.B. /dev/sr0), das seine individuelle Konfiguration enthält.

Den maximalen Nutzen mit cloud-init erzielen Sie, wenn Sie dieses Tool auch für Ihre eigenen Einrichtungsaufgaben nutzen. Als "User Data" können Sie beim Server-Launch eine Vielzahl von Settings angeben bis hin zu beliebigen Kommandos, die auf dem neuen Server ohne weiteres Zutun ausgeführt werden (siehe auch die cloud-init Dokumentation). So installiert Ihr Server selbständig die von Ihnen gwünschten Pakete und Patches und integriert sich in Ihr Config-Management oder Monitoring – noch bevor Sie sich das erste Mal einloggen.

Selbstverständlich können Sie die Daten vom Metadaten-Server auch mit Ihren eigenen Tools auslesen und nutzen, so z.B. die UUID Ihres Servers, um via unsere API automatisiert Aktionen auszulösen. Insbesondere falls Sie Netzwerk-Optionen statisch konfigurieren, haben Sie dank dem neuen Config-Drive in jedem Fall die Daten zu Ihrem Server lokal zur Verfügung. Alternativ finden Sie die Angaben auch unter /run/cloud-init/instance-data.json, wo cloud-init eine Kopie der gelesenen Config ablegt.

Gut zu wissen

Die Version und Möglichkeiten des cloud-init Pakets unterscheidet sich zwischen den verschiedenen Linux-Distributionen zum Teil stark. Prüfen Sie falls nötig, welche der zahlreichen Optionen im Einzelfall unterstützt werden oder durch das Aktivieren bestimmter Module zusätzlich benutzt werden können. Denken Sie beim Hinzufügen von User Data zudem daran, dass die Metadaten potenziell von jedem Benutzer oder Tool auf Ihrem Server eingesehen werden können.

Übrigens: Obwohl weit verbreitet, ist cloud-init nicht das einzige Projekt, um die Einrichtung neuer Server zu automatisieren; eine Alternative ist hier Ignition, das z.B. bei Flatcar Container Linux zum Einsatz kommt. Ignition erwartet seine Config im JSON-Format, beim Start eines Servers mit Flatcar bei cloudscale.ch können Sie als User Data aber auch eine YAML-formatierte "cloud-config" wie für cloud-init angeben.

Egal, ob Sie eine Copy/Paste-Vorlage für den Launch im Control-Panel bereithalten oder Server via API starten: Dank cloud-init und Ignition automatisieren Sie über das reine Erstellen von Servern hinaus viele Einrichtungsschritte, die Sie bisher manuell ausgeführt haben. Und auch im laufenden Betrieb haben Sie – z.B. in Scripts – jederzeit Zugriff auf die wesentlichen Metadaten Ihrer Server.

Für einen guten Start,
Ihr cloudscale.ch-Team

Die Switching-Infrastruktur als zentraler Faktor

Im normalen IT-Alltag findet das Netzwerk oft wenig Beachtung: Sind die Systeme erst einmal verkabelt, rückt für die nächsten Jahre oft die Rechenleistung und der Speicherplatz in den Vordergrund. Bei cloudscale.ch hingegen ist das Thema ständig präsent: Vom Netzwerk hängt nicht nur die Anbindung unserer Cloud-Server ans Internet und damit die externe Verfügbarkeit Ihrer Services ab; mit dem Trend zu Microservices und Cluster-Setups ist auch die interne Vernetzung zwischen Cloud-Servern matchentscheidend für die Performance und Zuverlässigkeit des Gesamtsystems. Und schliesslich kann unser Storage-Cluster auf Basis von Ceph seine Vorteile nur mit einer Top-Netzwerkinfrastruktur voll ausspielen.

Nebst unserem allgemeinen Wachstum und entsprechend steigendem Bedarf an Switchports beeinflusste auch die Inbetriebnahme unseres zweiten Cloud-Standorts in Lupfig unsere Wahl. Die zwei Standorte sollten einerseits unabhängig voneinander operieren können und damit geo-redundante Setups ermöglichen, andererseits sollte aber auch eine möglichst direkte Verbindung zwischen Services an beiden Standorten sichergestellt werden. An Cumulus Linux gefiel uns nicht zuletzt die Tatsache, dass sich die meisten unserer Anforderungen mit offenen Standards und ohne die Verwendung von proprietären Protokollen eines bestimmten Herstellers umsetzen liessen.

Besonderheiten der Lösung mit Cumulus Linux

Die von Cumulus Networks gepflegte Distribution "Cumulus Linux" ist ein Novum unter den Netzwerk-Betriebssystemen. Anders als die Systeme der traditionellen Netzwerk-Hersteller ist sie zum grössten Teil Open-Source und basiert auf Debian GNU/Linux. Um im Enterprise-Umfeld die geforderte Stabilität und Sicherheit zu bieten, werden einzelne Versionen als sog. "ESR"-Releases (Extended Support Release) über einen langen Zeitraum hinweg mit Sicherheits-Updates versorgt – eine Strategie, die von Ubuntu's LTS-Versionen her bekannt ist und auch in immer mehr anderen Software-Projekten Einzug hält. Ein Bestandteil von Cumulus Linux ist zudem FRRouting, das unter dem Dach der Linux Foundation weiterentwickelt wird und das wir bereits auf unseren Border-Routern mit Erfolg einsetzen.

Mit der Einführung unserer neuen Switching-Infrastruktur liessen wir uns deutlich mehr Zeit als ursprünglich geplant. Über mehrere Versionen hinweg sammelten wir in unserem Lab Erfahrung mit Cumulus Linux, und in zahlreichen Iterationen flossen gewonnene Erkenntnisse in das Netzwerk-Design zurück. Profitiert haben wir dabei nicht zuletzt von der Community, die sich rund um Cumulus Linux gebildet hat. So erhält man in einem dedizierten Slack-Channel umkompliziert Tipps und Tricks von anderen Cumulus-Anwendern; wenn sich auf diese Weise mal ein Anliegen nicht zeitnah lösen lässt, schalten sich oft Cumulus-eigene Engineers in die Diskussion ein und bieten aktiv Hilfe an. Aber auch die direkte Zusammenarbeit mit Cumulus Networks erwies sich als offen und fruchtbar. Wo wir tatsächlich auf Bugs stiessen, wurden diese gewissenhaft analysiert und behoben – inkl. Patches, die oft auch "upstream" in die jeweiligen Open-Source-Projekte zurückflossen.

Technische Eckdaten und handfeste Vorteile

Cumulus Linux ist ein Netzwerk-Betriebssystem, das auf Geräten verschiedenster Hersteller eingesetzt werden kann. Die "Cumulus Express" genannte Kombination, für die wir uns entschieden haben, enthält Hardware von Edgecore. In unseren Switches steckt ein Trident 3 ASIC von Broadcom, das "line-rate"-Switching für alle 32 100-Gbps-Ports unterstützt – in der Summe also volle 3.2 Tbps. Jeder der 100-Gbps-Ports lässt sich zudem mittels "Breakout"-Funktion in 4 "logical" Ports mit je 10 oder 25 Gbps aufteilen, was die Flexibilität bzgl. der anschliessbaren Systeme zusätzlich erhöht.

Unser Netzwerk haben wir nach dem Leaf-Spine-Prinzip aufgebaut, wobei jeder Switch redundant ausgelegt ist. Auch sämtliche Verbindungen sind redundant: Ein Leaf-Paar (zwei "Top-of-Rack" Switches) ist mit insgesamt 800 Gbps mit den beiden Spines verbunden. Zusätzlich zur Multi-100-Gbps-Vernetzung unseres Backbones ermöglicht die eingesetzte Hardware auch den schrittweisen Umstieg auf eine Multi-25-Gbps-Anbindung einzelner physischer Server. Davon profitieren nicht nur die privaten Netze zwischen den virtuellen Servern unserer Kunden, sondern auch die Anbindung an den Storage-Cluster. Die dedizierte Verbindung zwischen unseren beiden Cloud-Standorten schliesslich ist mit Multi-10-Gbps über CWDM auf trassenredundanten Dark-Fibers ebenfalls grosszügig dimensioniert.

Bei cloudscale.ch sind wir uns bewusst, dass das Netzwerk die Basis für alle anderen Features der Cloud bildet. Entsprechend hoch gewichten wir daher Leistung, Zuverlässigkeit und Support aller eingesetzten Komponenten. Der untypische Ansatz von Cumulus Linux bietet aber noch weitere Vorteile. In einem separaten Beitrag möchten wir daher auch einen Einblick geben, wie wir bei cloudscale.ch z.B. von Synergien zwischen Network Engineering und System Engineering profitieren können.

Schnell wie der Blitz,
Ihr cloudscale.ch-Team

Ordnung ist das halbe Leben – so haben viele System Engineers nicht nur ein Namens-, sondern auch ein Adressschema definiert, das sie bei der täglichen Arbeit mit ihren Systemen optimal unterstützt. Schon bisher ist es dabei hilfreich, dass bei cloudscale.ch in privaten Netzen beliebige IP-Adressen benutzt werden können. Neu können Sie unsere DHCP-Systeme auch dazu verwenden, um Ihren Servern Adressen aus Ihrem selbstgewählten Subnet zuzuweisen.

Um ein eigenes Subnet zu definieren, legen Sie via API zuerst ein privates Netz mit "auto_create_ipv4_subnet": false an; so erhalten Sie ein bereits voll funktionsfähiges privates Layer-2-Netzwerk. Erstellen Sie darin anschliessend Ihr Subnet, und geben Sie als Wert von cidr den IP-Range Ihrer Wahl an, mindestens aber ein /24. Für jedes Subnet können Sie zusätzlich den Gateway sowie die DNS-Server definieren, die unsere DHCP-Systeme Ihren Servern zuweisen sollen. Ein Beispiel:

$ curl -i -X POST -H "$AUTH_HEADER" -H "Content-Type: application/json" --data '{"cidr": "192.168.1.0/24", "network": "61fa...10ed", "gateway_address": "192.168.1.1", "dns_servers": ["192.168.1.1", "192.168.1.2"]}' https://api.cloudscale.ch/v1/subnets

Mit oder ohne DHCP – IPs nach Bedarf

Beim Launch eines neuen Servers mit privatem Netz stehen Ihnen nun alle Optionen offen: Ist im privaten Netz ein Subnet definiert, erhält der Server nebst dem Gateway (optional) und den DNS-Servern per Default eine zufällig gewählte Adresse aus dem DHCP-Range des Subnets zugewiesen; je nach Wunsch können Sie aber auch eine fix vorgegebene IP-Adresse angeben. Falls Sie DHCP für einen Server komplett deaktivieren möchten, geht dies natürlich ebenfalls.

Als Beispiel wird mit dem folgenden API-Aufruf ein Server erstellt, der ein public Interface hat sowie eines im privaten Netz, wobei der Server dort via DHCP eine fix vorgegebene IP-Adresse erhalten soll:

$ curl -i -X POST -H "$AUTH_HEADER" -H "Content-Type: application/json" --data '{"name": "firewall", ..., "interfaces": [{"network": "public"}, {"addresses": [{"subnet": "5b71...2912", "address": "192.168.1.21"}]}]}' https://api.cloudscale.ch/v1/servers

Die gleichen Optionen haben Sie natürlich auch beim nachträglichen Hinzufügen von Interfaces zu einem bestehenden Server. Eine komplette Übersicht über die möglichen Interface-Definitionen finden Sie in unserer API-Dokumentation.

Auf dem public Interface (sofern vorhanden) ist DHCP immer aktiv und kann nicht weiter konfiguriert werden. Selbstverständlich steht es Ihnen aber weiterhin frei, alle entsprechenden Settings auf Ihrem Server statisch zu konfigurieren.

Bitte beachten Sie, dass DHCP auf mindestens einem Interface (public oder in mindestens einem privaten Netz) aktiviert sein muss. Damit erhält der Server eine Route zu unserem Metadaten-Server, um seine Konfiguration für cloud-init abzurufen.

Einheitlichkeit und Effizienz

Der Vorteil liegt auf der Hand: Gleich beim Erstellen von Servern können Sie auch das private Netz passend gliedern. Für eine zentrale Firewall mit OPNsense beispielsweise legen Sie direkt eine fixe IP-Adresse fest. Die weiteren Server, die hinter dieser Firewall sein sollen, erhalten dann via DHCP sowohl als Gateway wie auch als DNS-Resolver die Firewall-IP zugewiesen.

Ebenfalls einfacher wird die Pflege eines eigenen DNS-Resolvers, da Sie nun die internen IP-Adressen Ihrer Server von Anfang an kennen und diese direkt im DNS erfassen können. Und falls Sie mit aktuellen Kubernetes-Distributionen experimentieren, können sich neue Nodes dank einem Reverse-DNS-Lookup auf die eigene interne IP-Adresse automatisch im Cluster integrieren.

Mit privaten Netzen können Sie Ihre virtuellen Server bei cloudscale.ch schon seit Längerem so miteinander "verdrahten", wie Sie dies auch von physischen Servern her kennen. Dank definierbaren IP-Adressen und Subnets sowie DHCP-Optionen bilden Sie nun auch die logische Ebene ab, so dass sich Ihre Cloud-Setups ideal in Ihre Gesamtinfrastruktur integrieren.

Von Anfang an die richtige Adresse,
Ihr cloudscale.ch-Team

cloudscale.ch ist Anbieterin von Infrastructure-as-a-Service (IaaS) im Selbstbedienungs-Modell, d.h. der Kunde startet, skaliert, erweitert und löscht virtuelle Server und bezieht Services in Eigenregie, während wir die dafür benötigte Infrastruktur zur Verfügung stellen. Auf Grund der Art unserer Dienstleistungen ist damit nur in den wenigsten Fällen physische Präsenz nötig.

Unseren Bürostandort betrachten wir zudem schon seit Längerem – nicht zuletzt aus Überlegungen zu "Business Continuity" – lediglich als eine Art Internet-Cafe, auf welches wir im Notfall auch verzichten können. Unsere Mitarbeiter konnten deshalb in den vergangenen Tagen bereits vermehrt zu Hause bleiben und aus dem Homeoffice arbeiten.

Nicht zuletzt ist unsere gesamte Infrastruktur dank Redundanz darauf ausgelegt, dass Ihre Services stets verfügbar sind. Auch steht für ein weiteres Wachstum des Kundenbedarfs genügend Reserve-Kapazität zur Verfügung. Damit vermeiden wir auch in diesem Bereich Hektik und können allfällig nötige Arbeiten sorgfältig planen.

Wie wir unseren Teil zur Verzögerung beitragen wollen

Höchste Priorität in Bezug auf SARS-CoV-2 hat derzeit die Verzögerung der Verbreitung und damit die Entlastung des Gesundheitswesens weltweit. Aus diesem Grund haben wir ab sofort folgende Regeln eingeführt:

1. Alle unsere Mitarbeiter arbeiten soweit möglich im Homeoffice. Wie bereits erwähnt erfordert die Art unserer Dienstleistung nicht, dass wir in unseren Geschäftsräumlichkeiten arbeiten.
2. Wir bitten unsere Mitarbeiter und Kunden, auf persönliche Treffen zu verzichten und Sitzungen stattdessen online oder telefonisch abzuhalten.
3. Unsere Mitarbeiter werden ermutigt, wenn immer möglich zu Hause zu bleiben und das Selbst-Quarantäne Manifest gemäss staythefuckhome.com zu befolgen.

Bitte zögern Sie nicht, uns bei Rückfragen oder Unklarheiten zu kontaktieren. Wir bedanken uns an dieser Stelle bei allen, welche im Kampf um Menschenleben und gegen die Verbreitung des Virus im Einsatz stehen und sind in Gedanken bei den Betroffenen und deren Angehörigen.

Bleiben Sie gesund!
Ihr cloudscale.ch-Team

Viele Computerspiele erhalten ihren Reiz dadurch, dass der nächste Zug des Computers nicht vorhersehbar, sondern scheinbar zufällig ist. Nebst diesem unterhaltsamen Aspekt von "Zufall" hängt jedoch auch die Sicherheit Ihrer Daten und Systeme davon ab: Datenverschlüsselung – z.B. bei HTTPS oder SSH – basiert auf mathematischen Verfahren; diese sind aber darauf angewiesen, dass ein potenzieller Angreifer den benutzten Schlüssel nicht erraten oder aus anderen Daten herleiten kann.

Dazu nötige Zufallswerte/-zahlen errechnet ein sog. "Pseudo Random Number Generator" (PRNG) mithilfe von speziellen Algorithmen aus möglichst unvorhersehbaren Input-Werten. Der PRNG im Linux-Kernel bezieht diese Entropie ("Unordnung") aus verschiedenen Quellen wie z.B. Mausbewegungen und Netzwerk-Traffic. Ausgegeben werden die Zufallszahlen bspw. über /dev/urandom und /dev/random.

Zusätzliche Entropie-Quellen

Eine Reihe von möglichen Entropie-Quellen (wie z.B. Mausbewegungen) fällt bei virtualisierten Cloud-Servern naturgemäss weg. Insbesondere beim ersten Start kann es eine Weile dauern, bis aus den wenigen vorhandenen Quellen genügend Entropie gesammelt wurde, um den PRNG zu initialisieren. Server von cloudscale.ch können daher seit Kurzem auch die rdrand-Funktion nutzen, über welche viele moderne CPUs Zufallszahlen generieren können. Ebenfalls neu verfügbar ist das Virtio-Device /dev/hwrng, das Zufallszahlen bereitstellt, die auf unseren physischen Compute-Hosts generiert wurden.

Beide dieser neuen Entropie-Quellen sind unabhängig davon, dass Ihr Server selber bereits genügend Entropie sammeln konnte, und können helfen, den PRNG des Servers schneller zu initialisieren. Ob der Server rdrand und /dev/hwrng tatsächlich erkennt und nutzt, hängt im Einzelfall jedoch von der verwendeten Linux-Distribution und deren Kernel ab; prüfen Sie bei Bedarf die Optionen CONFIG_RANDOM_TRUST_CPU und CONFIG_HW_RANDOM_VIRTIO Ihres Kernels – je nach Distribution bspw. in der Datei /boot/config-*.

Profitieren Sie automatisch von mehr Entropie

Immer mehr Linux-Distributionen enthalten Software, die den Systemaufruf getrandom() nutzt. Dieser Aufruf und davon abhängige Dienste wie SSH warten nach dem Systemstart, bis der PRNG des Servers initialisiert wurde, was teilweise zu langen Verzögerungen führen kann. Server bei cloudscale.ch sind von solchen Wartezeiten jedoch nicht betroffen: Dank rdrand und /dev/hwrng steht die nötige Entropie innert kürzester Zeit bereit, so dass auch Dienste, die Zufallszahlen benötigen, sofort gestartet werden können.

Auch mit bestehenden Servern können Sie bei cloudscale.ch die neuen Entropie-Quellen anzapfen. Schalten Sie Ihren Server dazu einfach einmal komplett aus, und starten Sie ihn anschliessend wieder. Nach dem Neustart steht Ihnen die rdrand-Funktion der CPU zur Verfügung, was Sie mit folgendem Kommando überprüfen können:

$ grep rdrand /proc/cpuinfo
flags		: [...] rdrand [...]

Unterstützt Ihr konkretes Betriebssystem auch das hwrng Virtio-Device, wird es Ihnen mit folgendem Kommando angezeigt:

$ cat /sys/devices/virtual/misc/hw_random/rng_available
virtio_rng.0

Obwohl im IT-Alltag kaum je ein Thema, ist "Zufall" ein unentbehrlicher Bestandteil für unzählige Vorgänge – insbesondere im Kontext der Sicherheit. Bei cloudscale.ch sorgen wir dafür, dass Ihre Server gleich vom Start weg immer genug Zufall generieren können.

Gute Server sind kein Zufall!
Ihr cloudscale.ch-Team

Eine Überprüfung unserer Infrastruktur hat ergeben, dass Ihre bei cloudscale.ch betriebenen virtuellen Server von den aktuellen Sicherheitslücken nicht betroffen sind: die exakten CPU-Modelle unserer Intel-basierten Compute-Hosts weisen diese Lücken nicht auf. Überhaupt nicht betroffen sind CPUs von AMD wie diejenigen in unseren AMD-basierten Compute-Hosts, die wir im Rahmen unserer neuen Flavors mit dedizierten CPU-Cores eingeführt haben. Auch in unseren Storage-Clustern und den Umsystemen unserer Cloud-Infrastruktur stecken ausschliesslich CPUs, die nach aktuellem Kenntnisstand nicht betroffen sind.

Bereits seit Mai 2019 verzichten wir zu Gunsten der Sicherheit bei allen Compute-Hosts auf "Simultaneous multithreading", das ein Ausnutzen der aktuellen Lücken erleichtern könnte. Zwar sind unsere CPUs von den zwei aktuellen Lücken von vornherein nicht betroffen; dennoch zeigen die neuen Erkenntnisse, dass sich unser defensiver Ansatz bewährt, um das Risiko für unsere Kunden zu minimieren.

Derzeit besteht somit für unsere Kunden im Zusammenhang mit den zwei neu publizierten Sicherheitslücken kein Handlungsbedarf. Selbstverständlich verfolgen wir die Situation aufmerksam und treffen je nach Erkenntnisstand angemessene Massnahmen.

Sollten Sie Fragen im Zusammenhang mit unseren Sicherheitsmassnahmen haben, stehen wir Ihnen natürlich gerne zur Verfügung.

Freundliche Grüsse,
Ihr cloudscale.ch-Team

1. Um Buckets in der neuen Region LPG zu erstellen und zu nutzen, benutzen Sie bitte ausschliesslich die URLs:

• https://objects.**lpg**.cloudscale.ch bzw.
• https://BUCKETNAME.objects.**lpg**.cloudscale.ch oder
• https://objects.**lpg**.cloudscale.ch/BUCKETNAME

2. Um Buckets in der bisherigen Region RMA zu erstellen und zu nutzen, benutzen Sie bitte ab sofort die URLs:

• https://objects.**rma**.cloudscale.ch bzw.
• https://BUCKETNAME.objects.**rma**.cloudscale.ch oder
• https://objects.**rma**.cloudscale.ch/BUCKETNAME

3. Die bisherigen URLs:

• https://objects.cloudscale.ch bzw.
• https://BUCKETNAME.objects.cloudscale.ch oder
• https://objects.cloudscale.ch/BUCKETNAME

funktionieren für Buckets/Objects in der Region RMA übergangsweise synonym zu den URLs gemäss Punkt 2.
ACHTUNG: Die Übergangsfrist endet am 31.12.2020; bitte passen Sie Links auf diese Buckets/Objects rechtzeitig an auf die URLs mit spezifischer Angabe der Region RMA (siehe Punkt 2).

4. Zugriffe auf bestehende Buckets unter Verwendung der URL einer anderen Region werden von unserem System mit einem HTTP-Statuscode 301 Moved Permanently beantwortet, dem einige Tools automatisch folgen. Solche Requests werden in der Kostenberechnung wie reguläre Requests gezählt. Wir empfehlen Ihnen jedoch, sich nicht auf diese Weiterleitung zu verlassen, sondern immer die korrekten URLs zu benutzen.

Sollten Sie zu unserem S3-kompatiblen Object Storage noch Rückfragen haben, stehen wir Ihnen natürlich gerne zur Verfügung.

Freundliche Grüsse,
Ihr cloudscale.ch-Team

Gründe für Ihr eigenes Image

Beim Start eines neuen Servers stehen bei cloudscale.ch nebst vielen beliebten Linux-Distributionen auch zwei Firewall-Distributionen zur Auswahl. Dennoch ist es möglich, dass Sie eine andere Distribution bevorzugen – z.B. aus persönlichen Erwägungen, oder um Ihr neues System möglichst ähnlich zu bestehenden zu halten. Indem Sie Ihr individuelles ISO- bzw. USB-Image nutzen, können Sie bei cloudscale.ch fast beliebige Betriebssysteme installieren.

Mit Ihrem eigenen Image können Sie aber noch mehr: Selbst wenn Sie auf Ubuntu, Debian oder ein anderes der von uns angebotenen Betriebssysteme setzen, haben Sie so die vollständige Kontrolle über das Initial-Setup. Bestimmen Sie die Partitionierung, nutzen Sie Ihr bevorzugtes Dateisystem oder richten Sie (zusätzlich zur Massnahme auf unserer Seite) Ihre eigene Disk-Verschlüsselung ein. Auch nach einem Missgeschick kann ein Live-Image helfen, wieder Zugriff auf ein zerschossenes System zu erhalten. Und bei Bedarf erstellen Sie eine konsistente, Sektor-weise Kopie Ihrer Server auf einem zusätzlichen Volume.

So nutzen Sie eigene Images

Als Ausgangslage benötigen Sie einen funktionsfähigen Server im gewünschten cloudscale.ch-Account, an den Sie ein zusätzliches SSD-Volume mit genügend Platz für Ihr ISO-/USB-Image anhängen. Dies kann der Server sein, den Sie anschliessend mit Ihrem Wunsch-System neu installieren, oder einfach ein temporärer Server für den nächsten Schritt. Laden Sie dann (z.B. mit curl oder wget) Ihr Image auf diesen Server herunter und kopieren Sie das Image anschliessend blockweise auf das zusätzliche Volume:

sudo dd if=my-own-image.iso of=/dev/vdb bs=1M && sync

Achtung: Stellen Sie unbedingt sicher, dass of (output file) dabei auf Ihr zusätzliches Volume zeigt – dieser Pfad wird ohne Rückfrage überschrieben!

Falls Sie mit dem Image einen anderen als den aktuellen Server booten möchten, hängen Sie das Volume jetzt an den entsprechenden Server um. Öffnen Sie anschliessend die VNC-Konsole des Zielservers, und starten Sie diesen neu. Durch Drücken von "Esc" in der VNC-Konsole gelangen Sie ins Boot-Menü, wo das zusätzliche Volume mit Ihrem Image als weitere "Virtio disk" erscheint. Wählen Sie diese aus, um das Booten von Ihrem Image anzustossen. Nutzen Sie nun Ihr Image, wie Sie es mit einem physischen Server und DVD tun würden.

Als Hinweis: Wenn Tastenanschläge in der VNC-Konsole mehrfach erscheinen, ändern Sie in der Adresszeile Ihres Browsers einfach "vnc_lite.html" zu "vnc.html" (und klicken "Connect").

Einige zusätzliche Hinweise

Nachdem der Zielserver installiert oder repariert wurde, booten Sie ihn wieder ganz normal von seinem root-Volume. Das zusätzliche Volume mit Ihrem Image können Sie wahlweise löschen oder für einen nächsten Einsatz behalten.

Das in diesem Beitrag beschriebene Vorgehen klappt mit vielen Images, die von den jeweiligen Distributionen für CDs/DVDs (.iso-Datei) oder für USB-Sticks bereitgestellt werden – z.B. mit Ubuntu und CentOS. cloudscale.ch kann jedoch keine Garantie für das Funktionieren mit einem konkret gewünschten Image übernehmen.

Beachten Sie, dass die von uns beim Server-Launch bereitgestellten Images das Paket "cloud-init" enthalten. Dieses sorgt für eine korrekte Konfiguration Ihrer Server, indem es z.B. den gewählten Servernamen und die berechtigten SSH-Keys in die Konfiguration des Servers überträgt. Wenn Sie Ihren Server via eigenem Image (neu) installieren, müssen Sie diese Einstellungen manuell vornehmen. Für die Netzwerk-Details können Sie je nach Wunsch DHCP verwenden oder die Angaben aus dem Control Panel statisch konfigurieren.

Egal, ob Sie nur ein kleines Missgeschick beheben müssen oder eine individuelle Server-Landschaft "from Scratch" aufbauen: Indem Sie Ihre eigenen ISO-/USB-Images nutzen, haben Sie in jeder Situation die volle Kontrolle über die Software und Konfiguration Ihrer Server.

Wir haben die richtigen Werkzeuge!
Ihr cloudscale.ch-Team

Terraform bietet "Infrastructure as Code"

Wo ein Konfigurationsmanagement-System oft von bestehender Infrastruktur ausgeht, auf welcher es die Software zu konfigurieren gilt, setzt Terraform einen Schritt früher an: Sie definieren Ihre benötigte Infrastruktur in Form von Textfiles; Änderungen im Verlaufe der Zeit verfolgen Sie einfach in Ihrem gewohnten Versionierungs-System. Aus dem aktuellen Ist- sowie dem definierten Soll-Zustand leitet Terraform die nötigen Aktionen ab und erstellt Ihre Systeme über unsere API – aus Code wird Infrastruktur.

Terraform ist Open-Source und arbeitet mit einer Vielzahl von Cloud-Anbietern zusammen; die jeweilige Schnittstelle wird über ein Provider-Plugin realisiert. Das "cloudscale.ch Provider" Plugin entwickeln wir ständig weiter und haben es bereits mehrmals in diesem Jahr erweitert, damit Sie die neusten Funktionen unserer Cloud optimal nutzen können.

Unterstützung der neusten Features

Seit einer Weile unterstützen unsere Server nicht mehr nur je ein SSD- und Bulk-Volume, sondern praktisch beliebig viele Volumes. Bereits im Frühjahr folgte die Unterstützung in Terraform: zusätzliche Volumes werden neu als separate Ressourcen definiert und können dynamisch an Server angehängt sowie im Live-Betrieb vergrössert werden. Immer noch einen Restart benötigt das Skalieren von Servern – damit Sie dies nicht auf dem falschen Fuss erwischt, verlangt Terraform hier eine explizite Erlaubnis für den Restart mittels speziellem Config-Argument.

Neu ist auch das Verwalten von mehreren privaten Netzen und damit von "tiered" Infrastrukturen in Terraform möglich. Private Netze werden ebenfalls als separate Ressourcen definiert; bei einem Server werden dann über interfaces alle Netze angegeben, zu denen eine Verbindung bestehen soll. Einen Überblick über alle verfügbaren Ressourcen und Argumente inklusive Beispiele finden Sie in der Dokumentation für den "cloudscale.ch Provider".

Auf Zuverlässigkeit ausgelegt

Selbstverständlich unterstützt unser Terraform-Plugin auch unseren neuen Rechenzentrums-Standort in Lupfig. Für jede Ressource können Sie mit dem Argument zone_slug den gewünschten Standort wählen. So definieren Sie auch für Ihre geo-redundanten Setups die komplette benötigte Infrastruktur "as Code".

Nebst der Redundanz ist auch das schnelle Erkennen von allfälligen Problemen wichtig. Dank einer Test-Suite, die täglich von Terraform-Entwickler HashiCorp gegen unsere Produktiv-Infrastruktur ausgeführt wird, haben wir hier ein zeitnahes Feedback aus Benutzer-Perspektive. So können wir potenziell auftretenden Auffälligkeiten nachgehen, bevor sporadische Fehler zu einem tatsächlichen Problem für unsere Kunden werden.

Übrigens: Das Terraform-Plugin basiert auf unserem Go SDK, das ebenfalls als Open-Source verfügbar ist und es auch anderen in Go geschriebenen Tools erleichtert, auf unsere Infrastruktur zuzugreifen.

Terraform ermöglicht die automatisierte – und somit reproduzierbare – Bereitstellung von Infrastruktur und passt damit hervorragend zur Arbeitsweise vieler unserer Kunden. Nutzen Sie auch in Terraform unsere neusten Features und bereiten Sie den Boden für Ihre nächsten anspruchsvollen Projekte!

Frohe Festtage!
Ihr cloudscale.ch-Team

Was unsere neuen "Plus"-Flavors auszeichnet

Der bislang wohl häufigste Anwendungsfall für Cloud-Server waren kleine VMs, die höchstens kurze Last-Peaks aufweisen. Durch das Teilen der physischen Ressourcen helfen Cloud-Angebote, hohe Hardware-Investitionen und den Overhead für die Infrastruktur zu vermeiden. Zum Mehrwert der Cloud gegenüber eigener Hardware gehört aber auch, dass Sie jederzeit flexibel sind und für die laufende Hardware-Wartung gesorgt ist – dies selbst dort, wo das Teilen der verfügbaren Rechenleistung nicht im Vordergrund steht.

Unsere neuen "Plus"-Flavors eignen sich perfekt für Server mit hohen Performance-Anforderungen. Anders als bei den bisherigen "Flex"-Flavors wird die physisch vorhandene Rechenleistung nicht überbucht: Jedem virtuellen Server steht die zugeteilte Anzahl CPU-Cores dediziert zur Verfügung. Diese Leistung können und dürfen Sie jederzeit voll nutzen, denn bei unseren "Plus"-Angeboten fällt die Rechenleistung nicht unter die sog. Fair-Use-Regelung. Gleichzeitig sichern Sie sich damit ab – "Nachbarn" mit rechenintensiven Workloads auf der gleichen Hardware haben keinen Einfluss auf die für Ihren Server verfügbare Anzahl Cores.

Basierend auf der neusten Hardware-Generation

Möglich wird dieses Angebot durch den Einsatz topaktueller Hardware: Als einer der ersten IaaS-Provider überhaupt setzt cloudscale.ch auf Compute-Nodes mit den kürzlich lancierten AMD EPYC "Rome" Prozessoren, die bis zu 64 physische Cores pro Socket bieten. Das schafft die Kapazität, um die ganzen Vorteile eines Cloud-Servers zu kombinieren mit der Rechenleistung eines dedizierten Servers – sozusagen das Beste aus beiden Welten.

Bei cloudscale.ch setzten wir übrigens bereits in der Vergangenheit erfolgreich auf AMD-Systeme, und zwar bei unserem Ceph-basierten Storage-Cluster. Dabei gab insbesondere die hohe Zahl von PCIe-Lanes den Ausschlag und ermöglichte uns, von herkömmlichen SSDs komplett auf noch leistungsfähigere NVMe-SSDs umzustellen.

Gut zu wissen: Nachdem in den vergangenen zwei Jahren immer wieder Seitenkanalangriffe auf Design-Schwachstellen von Prozessoren beschrieben wurden, haben wir auch bei unseren Compute-Nodes der neusten Generation das "Simultaneous Multithreading" (SMT) deaktiviert. Damit stellen wir sicher, dass auf SMT basierende Angriffe von Vornherein nicht möglich sind.

Profitieren Sie sofort von zusätzlicher Leistung

Wir empfehlen unsere neuen "Plus"-Flavors insbesondere für virtuelle Server, die dauerhaft eine mittlere bis hohe Rechenleistung benötigen. Mit 2 bis 112 dedizierten CPU-Cores steht geballte Power zu Ihrer exklusiven Verfügung – und das 24/7. So können Sie z.B. die Effizienz von Kubernetes-Clustern oder anderen Container-Setups weiter steigern. Daneben profitieren aber auch Workloads, die vor allem auf eine vorhersagbare Performance angewiesen sind: ohne Konkurrenz durch benachbarte Server stehen die CPU-Cycles Ihren Realtime-Anwendungen zuverlässig dann zur Verfügung, wenn sie benötigt werden.

Wählen Sie den gewünschten "Plus"-Flavor ganz einfach beim Erstellen eines neuen Servers, oder skalieren Sie bestehende Server wie gewohnt. Selbstverständlich können Sie jederzeit wieder auf einen beliebigen anderen unserer "Flex"- und "Plus"-Flavors wechseln. Gehen Sie auf Nummer sicher und decken Sie dank dieser Flexibilität auch kurzfristige Lastspitzen elegant ab, z.B. während Ihrer Black-Friday-Promotion.

Machen Sie sich Ihr eigenes Bild: cloudscale.ch offeriert Ihnen bis Ende 2019 alle "Plus"-Flavors mit 25% Rabatt, d.h. zum Preis des entsprechenden "Flex"-Angebots mit gleich viel RAM. Falls wir Sie von "Plus" überzeugen konnten, wird ab Januar 2020 der reguläre Preis verrechnet – wenn nicht, skalieren Sie einfach auf einen beliebigen anderen Flavor.

Mit dedizierter CPU-Leistung deckt cloudscale.ch jetzt auch den Bedarf Ihrer anspruchsvollsten Workloads ab. Selbstverständlich sind unsere neuen "Plus"-Flavors ab sofort an beiden Cloud-Standorten verfügbar und eignen sich damit auch für geo-redundante Setups. So sind Sie für jeden Ansturm gewappnet.

Hat Power,
Ihr cloudscale.ch-Team

Wie Sie von unserem neuen Standort profitieren

Einer der Vorteile von Cloud-Services ist es, dass Sie sich nicht um Beschaffung und Wartung von Hardware und Infrastruktur kümmern müssen. Wo sich "die Cloud" physisch befindet, spielt oft dennoch eine Rolle, z.B. in Bezug auf den Datenschutz und die entsprechende Gesetzeslage. Und trotz aller Vorkehrungen sind auch Cloud-Rechenzentren gewissen Restrisiken ausgesetzt, wie z.B. Bauarbeiten in der Nähe oder Hochwasser. Mit einem zweiten Standort, der dank räumlicher Distanz ein anderes Risikoprofil aufweist, schützen Sie den Betrieb Ihrer Applikationen selbst vor den Folgen eines solchen Worst-Case-Szenarios.

Getreu der alten Weisheit "nicht alle Eier in den gleichen Korb" empfehlen wir Ihnen, Ihre wichtigsten Daten und Systeme zusätzlich an einem zweiten Ort vorzuhalten. Damit können Sie im Fall der Fälle innert kurzer Zeit den Produktiv-Betrieb wieder aufnehmen. Sei es ein Hot-Standby-System oder ein Active/Active-Setup mit Load-Balancing: idealerweise müssen Sie höchstens noch den DNS-Eintrag auf den Zweitstandort zeigen lassen, um sofort wieder online zu sein. Auch wer "nur" eine reine Datenreplikation einrichtet (in Ergänzung zum regulären Backup), spart sich unter Umständen viel Kopfzerbrechen – nicht nur für den unwahrscheinlichen Desaster-Fall.

Technische Hintergrund-Informationen

Als Ergänzung zum bewährten Standort in Rümlang (Kanton Zürich) bieten wir unsere Services neu auch am Standort Lupfig (Kanton Aargau) an – unsere dafür eingeführten Kürzel "RMA" und "LPG" orientieren sich übrigens am UN/LOCODE-Schema. Beim Aufbau des neuen Standorts haben wir darauf geachtet, dass selbst bei einem Totalausfall des einen Rechenzentrums alle Services am anderen Standort weiterlaufen können. Entsprechend haben wir an die Infrastruktur die gleichen Massstäbe angelegt und setzen z.B. ebenfalls auf komplett redundante Stromversorgung, einen unabhängigen Storage-Cluster (auch hier mit NVMe-SSDs und dreifacher Replikation) sowie eigene Anbindungen ins Internet und zu Peering-Partnern.

Für Ihren Traffic betreiben wir an beiden Standorten eine durchgängig redundant ausgelegte Netzwerkinfrastruktur mit mindestens 10 Gbps pro Link. Und obwohl beide Standorte so unabhängig wie möglich funktionieren sollen, sind sie miteinander verbunden: Für eine optimale und ausfallsichere Vernetzung zwischen Ihren Systemen in Rümlang und Lupfig nutzen wir zwei direkte Glasfaserleitungen, die kreuzungsfrei auf separaten Trassen die beiden Standorte miteinander verbinden.

Mehrere Zonen im Praxis-Einsatz

Auch am neuen Standort Lupfig bieten wir von Anfang an sämtliche Services an. Wählen Sie z.B. beim Erstellen eines neuen Servers im Cloud-Control-Panel einfach den gewünschten Standort, oder geben Sie in Ihrem API-Call den Parameter zone mit. Die API ist selbstverständlich rückwärtskompatibel; ohne Angabe einer Zone greift der Default-Standort, den Sie im Control-Panel individuell einstellen können. Einmal erstellt, sind die Ressourcen an ihre jeweilige Zone gebunden. Beachten Sie daher, dass Sie z.B. bestehende Volumes oder private Netze nur an Server anschliessen können, die sich am gleichen Standort befinden.

Wie erwähnt haben wir am neuen Standort auch einen separaten Object Storage aufgebaut. Ihre Objects User gelten automatisch für beide Standorte, Buckets befinden sich an demjenigen Standort, an welchem sie angelegt wurden. Um gezielt auf den gewünschten Object Storage bzw. Bucket zugreifen zu können, verfügen diese über separate DNS-Namen und IPs; die bisherige URL objects.cloudscale.ch steht nun synonym für die URL objects.rma.cloudscale.ch des bestehenden Standorts Rümlang. Zugriffe "über Kreuz" werden mit einem Status-Code 301 Moved Permanently beantwortet, dem einige Tools automatisch folgen. Für beste Effizienz und Ausfallsicherheit empfehlen wir Ihnen jedoch, nach Möglichkeit immer die korrekten URLs zu nutzen.

Der Aufwand hat sich gelohnt: Mit dem neuen Standort Lupfig bieten wir Ihnen jetzt auch für geo-redundante Setups die ideale Infrastuktur. Und unabhängig davon, welchen Standort Sie für sich als "primär" wählen, profitieren Sie von durchdachter Redundanz, optimaler Performance und ausschliesslichem Datenstandort in der Schweiz.

Alles Gute aus Zürich und dem Aargau,
Ihr cloudscale.ch-Team

Anwendungsbeispiele mit mehreren privaten Netzen

Private Netze kommen z.B. zum Einsatz, wenn Web-Worker direkt aus dem Internet erreichbar sein sollen, jedoch nicht deren Datenbank-Backends. Auch um Server in der Cloud hinter einer Firewall wie OPNsense zu schützen, sind sie das Mittel der Wahl. Mit der Unterstützung von mehreren privaten Netzen können Sie diese bewährten Konzepte jetzt auch kombinieren: ein Firewall-/Load-Balancer-Setup bildet die Schnittstelle zum Internet und leitet legitime Requests über das erste private Netz zu den Web-Workern. Diese wiederum erreichen die Datenbank-Backends über ein zweites, separates privates Netz, um eine saubere Trennung der verschiedenen Sicherheitszonen zu gewährleisten.

Möglicherweise möchten Sie zusätzlich zu Ihrer öffentlichen Web-Applikation auch interne Dienste in der Cloud betreiben, diese aber zuverlässig vor Zugriffen aus weniger vertrauenswürdigen Zonen schützen. Mit separaten privaten Netzen lässt sich auch dieses Szenario abbilden: Traffic Ihrer Web-Applikation wird von der Firewall über das eine private Netz zu Ihrem Webserver geleitet, während Ihre internen Tools via separates privates Netz mit Ihrem VPN-Endpunkt verbunden sind. So sind Ihre öffentlichen und internen Server in zwei unabhängigen privaten Netzen sicher voneinander getrennt.

Wie Sie private Netze einrichten

Als zentrale Schaltstelle für Ihre privaten Netze steht der neue API-Endpunkt networks zur Verfügung. Mit dem Request:

$ curl -i -H "$AUTH_HEADER" https://api.cloudscale.ch/v1/networks

erhalten Sie einen Überblick über Ihre bestehenden privaten Netze:

HTTP/1.0 200 OK
Allow: GET, POST, HEAD, OPTIONS
Content-Type: application/json

[
  {
    "href": "https://api.cloudscale.ch/v1/networks/2db69ba3-1864-4608-853a-0771b6885a3a",
    "created_at": "2019-05-29T13:18:42.511407Z",
    "uuid": "2db69ba3-1864-4608-853a-0771b6885a3a",
    "name": "my-network-name",
    "mtu": 9000,
    "subnets": [
      {
        "href": "https://api.cloudscale.ch/v1/subnets/33333333-1864-4608-853a-0771b6885a3a",
        "uuid": "33333333-1864-4608-853a-0771b6885a3a",
        "cidr": "172.16.0.0/24"
      }
    ],
    "tags": {}
  }
]

Mit einem POST-Request an den Endpunkt networks erstellen Sie ganz einfach weitere private Netze, als einzigen erforderlichen Parameter müssen Sie nur einen Namen vergeben, um das Netz später wiederzuerkennen. Über den bestehenden API-Endpunkt servers können Sie nun bestimmen, ob und in welchen privaten Netzen ein Server Interfaces haben soll. Dies klappt sowohl direkt beim Erstellen eines neuen Servers wie auch nachträglich.

Standardmässig weist unser System dem neuen Netz einen zufällig gewählten, privaten IPv4-Range ("Subnet") zu und vergibt später Ihren Servern in diesem Netz via DHCP IP-Adressen aus diesem Range. Beides können Sie bei Bedarf natürlich deaktivieren. Und wie bisher können Sie auf Servern in Ihren privaten Netzen beliebige IPv4- und IPv6-Adressen statisch konfigurieren. Falls es sich um ein Netz mit Subnet handelt, vermeiden Sie jedoch Adress-Konflikte mit unseren DHCP-Servern. Mehr Informationen zu den verfügbaren Optionen finden Sie auch in unserer API-Dokumentation.

Einige praktische Hinweise

Für optimale Performance im privaten Netz beträgt die MTU standardmässig 9000 Bytes ("Jumbo Frames"). Selbstverständlich können Sie die MTU jederzeit ändern, z.B. wenn Ihr konkretes Setup die vom klassischen Ethernet bekannten 1500 Bytes verlangt.

Beachten Sie, dass ein Server in mindestens einem seiner Netze via unseren DHCP-Server eine IPv4-Adresse zugewiesen erhalten muss. Grund dafür ist, dass via DHCP gleichzeitig die benötigte Route gesetzt wird, damit cloud-init auf Ihrem Server unseren Metadaten-Server erreichen kann.

In Kürze werden wir zudem unser Cloud-Control-Panel erweitern, so dass Sie auch beim Erstellen eines neuen Servers via Browser direkt bestehende oder neue private Netze anwählen können.

Last but not least können Sie auch für Ihre privaten Netze eigene Tags festlegen und nach diesen filtern.

In vielen Fällen kann eine feinere Segmentierung der genutzten Server Sinn ergeben, sei es, um die logische Struktur Ihres Setups abzubilden, oder um Ihr Sicherheitskonzept um eine weitere Stufe zu ergänzen. Die aktuelle Erweiterung unserer privaten Netze macht es möglich: Bauen Sie Ihre Serverlandschaft so auf, wie es am besten zu Ihnen und Ihrem konkreten Anwendungsfall passt.

Vernetzt auf allen Ebenen,
Ihr cloudscale.ch-Team

Mit Tags wird auf den ersten Blick klar, was es mit einer bestimmten Ressource auf sich hat oder wo sie dazugehört. Solche "Etiketten" mit Key/Value-Paaren lassen sich auf die meisten Ihrer Ressourcen kleben: Servers und Server Groups, Volumes, Floating IPs und Objects Users. Damit unterscheiden Sie z.B. Prod- von Development-Umgebungen, ordnen Ressourcen dem jeweiligen Endkunden zu, oder halten eine Bemerkung fest.

Beim Abfragen von Ressourcen können Sie diese direkt anhand der Tags filtern, um nur die relevanten Objekte auszugeben. Filtern lässt sich dabei nach einem konkreten Tag-Inhalt (z.B. "tag:Env=Prod" für alle produktiven Server) oder nach dem Vorhandensein eines bestimmten Tags unabhängig von dessen Inhalt (z.B. "tag:Customer" für alle Server, die irgend einem Endkunden zugeordnet sind).

Wie Tags festgelegt und ausgewertet werden

Tags sind aktuell für unsere API implementiert. Die schon bisher bestehenden Endpunkte der unterstützten Ressourcen kennen neu ein Element "tags", das als JSON-Objekt frei definierbare Key/Value-Paare aufnimmt. Diese werden bei einem GET-Request automatisch mit ausgegeben wie im folgenden, gekürzten Beispiel:

[
  {
    "href": "https://api.cloudscale.ch/v1/servers/c10...",
    "name": "WebWorker1",
    "created_at": "2019-09-18T17:48:21.547057Z",
    "status": "running",
    "flavor": {
      "slug": "flex-32",
      "name": "Flex-32",
      "vcpu_count": 8,
      "memory_gb": 32
    },
    "server_groups": [],
    "anti_affinity_with": [],
    "tags": {
      "Env": "Prod",
      "Customer": "Cloud Corp.",
      "Lifecycle": "Installing",
      "Comment": "Don't forget the monitoring! (Remove comment when done.)"
    }
  }
]

Das Setzen und Ändern von Tags erfolgt mit einem PATCH-Request an die URL der jeweiligen Ressource:

$ curl -H "$AUTH_HEADER" -H "Content-Type: application/json" -X PATCH --data '{ "tags": { "Env": "Prod", "Customer": "Cloud Corp.", "Lifecycle": "Live" }}' https://api.cloudscale.ch/v1/servers/c10...

Sollen nur Ressourcen mit einem bestimmten Tag abgefragt werden, wird das gewünschte Kriterium einfach als URL-Parameter angehängt:

$ curl -H "$AUTH_HEADER" https://api.cloudscale.ch/v1/servers?tag:Env=Prod

Mehr Informationen und Beispiele finden sich natürlich auch in unserer API-Dokumentation. Ab der demnächst erscheinenden Ansible-Version 2.9 unterstützt zudem auch unser Ansible Cloud Module neu Tags auf den wichtigsten Ressourcen.

Mit den Tags entsprechen wir einem Wunsch, den mehrere Power-User unter unseren Kunden geäussert haben. Wir freuen uns, dass alle unsere Nutzer von diesem praktischen Feature profitieren können – damit finden Sie sich auch in grösseren Deployments jederzeit zurecht.

Hält alles in Ordnung mit Tags,
Ihr cloudscale.ch-Team

Docker-Container werden meist auf Linux-Servern gestartet. Um einen solchen Linux-Server bei cloudscale.ch einzurichten und die Docker-Umgebung darauf zu installieren, reicht jetzt ein einziges Kommando: docker-machine. Mit dem "cloudscale"-Treiber kann Docker-Machine unsere API ansprechen und alle nötigen Einstellungen setzen. So steht der neue Docker-Host in kürzester Zeit bereit, um den ersten Container darauf zu starten.

Docker-Machine ist ein Kommandozeilen-Tool, das Sie entweder auf Ihrem lokalen Computer oder auf einem Management-Server/Jump-Host installieren können. Laden Sie zusätzlich unseren quelloffenen "cloudscale"-Treiber von GitHub in ein Verzeichnis im Suchpfad, und generieren Sie ein API-Token über unser Cloud-Control-Panel. Ein Kommando wie im folgenden Beispiel erstellt dann einen fixfertigen Docker-Host für Ihre Container:

$ docker-machine create -d cloudscale --cloudscale-token=<API_TOKEN> my-docker-host

Ein docker-machine env my-docker-host liefert anschliessend die nötigen Angaben, um den neuen Docker-Host gleich zu nutzen.

Wie Sie K8s-Cluster bei cloudscale.ch mit Rancher verwalten

Nicht nur einzelne Docker-Hosts, sondern ganze Kubernetes-Cluster können Sie bequem mit Rancher verwalten. Rancher, das selbst in einem Docker-Container läuft, stellt ein Webinterface zur Verfügung, mit dem Sie Ihren Cluster nach Wunsch konfigurieren können. Anschliessend werden alle nötigen virtuellen Server automatisch erstellt und komplett eingerichtet. Auch das Deployment von Apps und das kontinuierliche Management des Clusters nehmen Sie über das gleiche GUI vor.

Rancher kann eine Vielzahl von Cloud-Providern ansteuern – so auch cloudscale.ch. Tragen Sie unter "Node Drivers" einfach die Angaben gemäss GitHub ein, und schon können Sie beim Erstellen eines neuen Clusters "Cloudscale" als Infrastruktur-Provider auswählen. Übrigens: Rancher ist komplett Open-Source, und wir sind in Kontakt mit Rancher Labs, um unseren Treiber in künftigen Versionen von Rancher direkt mit aufzunehmen.

Mit Docker-Machine und Rancher unterstützt cloudscale.ch zwei zentrale Tools, um Container-Umgebungen noch einfacher zu verwalten. Ob via CLI oder grafisches Webinterface: Sie erstellen in kürzester Zeit die passenden Nodes für Ihre Workloads.

Bestens integriert,
Ihr cloudscale.ch-Team

Solid-State-Drives (SSDs) sind massiv schneller als herkömmliche Festplatten, da sie ausschliesslich auf Speicherchips basieren statt auf beweglichen Magnetscheiben und Schreib-/Leseköpfen. Damit verschiebt sich auch der Flaschenhals: aktuelle SSDs können Daten schneller aufnehmen und liefern, als der verbreitete S-ATA-Anschluss es ermöglicht. Dank dem NVMe-Standard können SSDs stattdessen direkt an die schnellen PCIe-Anschlüsse eines PCs oder Servers angeschlossen werden, um ihre volle Leistungsfähigkeit auszuspielen.

Bei cloudscale.ch haben wir unsere SSDs sukzessive durch Modelle mit NVMe-Schnittstelle ersetzt, sodass heute alle Ihre SSD-Volumes komplett auf NVMe-SSDs gespeichert sind und so die bestmögliche Performance liefern. Möglich wurde dies durch die Beschaffung neuer Storage-Systeme auf Basis von AMD Epyc CPUs, welche die nötige Anzahl an PCIe-Lanes bieten. Übrigens: auch bei unserem Bulk- und Object-Storage liegt die Ceph-DB sowie der Object-Cache für optimale Leistung auf NVMe-SSDs.

Warum wir unseren Ceph-Cluster auf BlueStore migriert haben

BlueStore, seit dem Luminous-Release das empfohlene Storage-Backend, wurde speziell für Ceph-Cluster entwickelt und vor rund drei Jahren in einer ersten Version veröffentlicht. Statt die Daten im Hintergrund auf einem XFS-Dateisystem zu speichern, verwaltet Ceph mit BlueStore das Blockdevice komplett selbst und hat damit die Hoheit über Journal, Caches etc. Im Zuge des Ugrades unserer Storage-Systeme auf Ubuntu 18.04 LTS haben wir unseren Ceph-Cluster von XFS auf BlueStore umgestellt – nicht zuletzt natürlich wegen des markanten Performance-Gewinns, den BlueStore im Vergleich zu XFS ermöglicht.

Ein zusätzlicher Vorteil von BlueStore sind die integrierten Prüfsummen: diese werden für sämtliche Daten und Metadaten automatisch angelegt und bei jedem Lesen vom Speichermedium überprüft. Damit bietet BlueStore einen zusätzlichen Mechanismus zur Wahrung der Integrität Ihrer Daten – neben der Verfügbarkeit und der Vertraulichkeit eine der drei zentralen Komponenten von Informationssicherheit.

Was Disk-Verschlüsselung seitens Cloud-Provider bringt

Zeitgleich mit der Umstellung auf BlueStore haben wir die Verschlüsselung aller Daten-Disks in unseren Storage-Systemen eingeführt. Damit sind ab sofort alle Ihre Volumes und Objects "at rest" automatisch verschlüsselt. Zusätzlich zum bereits etablierten Prozess, dass Disks bei Ausserbetriebnahme von unseren Mitarbeitern jeweils "secure-erased" werden, stellt die Verschlüsselung eine weitere Schutzschicht dar und ergänzt so unsere bestehenden Massnahmen zur Erhöhung der Informationssicherheit.

Das Ziel dieser Verschlüsselung ist hauptsächlich der Schutz Ihrer Daten vor Aussenstehenden, z.B. für den Fall, dass wir eine defekte SSD entsorgen müssen. Es liegt in der Natur der Sache, dass wir trotzdem im Besitz der nötigen Schlüssel sein müssen, um Ihre Server und Volumes wie gewohnt betreiben zu können. Die Disk-Verschlüsselung seitens Cloud-Provider ergänzt somit Ihre eigenen Vorkehrungen zum Schutz Ihrer Daten, wie z.B. die verschlüsselte Übertragung übers Internet oder die Verschlüsselung Ihrer Volumes mit LUKS.

Seit jeher liegt uns die Sicherheit Ihrer Daten am Herzen (siehe auch Zertifiziert nach ISO 27001, 27017 und 27018). Ebenso wollen wir Ihnen auch immer die bestmögliche Performance bieten. Umso mehr freuen wir uns, dass unser Storage gleich in beiden Belangen nochmals einen Zahn zulegen konnte.

Unsere Volumes drehen auf!
Ihr cloudscale.ch-Team

Wie sich die Kosten für den Object Storage zusammensetzen

Egal, ob Sie unseren Object Storage für die Ablage von Backups nutzen, als Repository für Ihre Container-Images oder als Webserver für Ihre statischen Assets: der genutzte Speicherplatz wird über den Tag gemittelt und um Mitternacht (Zürcher Lokalzeit) Ihrem Konto belastet. Die täglichen Kosten enthalten zudem eine Komponente für ausgehenden Netzwerk-Traffic (eingehender Traffic ist kostenlos) sowie einen Betrag für die erfolgten HTTPS-Requests auf Ihre Buckets und Objects (siehe auch unsere Preise).

Vergangene Nutzung Ihrer Buckets im Blick

Schon bisher wurde die aktuelle Nutzung in unserem Cloud-Control-Panel ausgewiesen – so konnten Sie die Belegungs- und Zugriffszahlen nahezu in Echtzeit verfolgen. Neu können Sie auch vergangene Nutzungsdaten Ihrer Buckets anzeigen lassen. Stellen Sie statt der "Live"-Ansicht einen frei wählbaren Zeitraum ein, um das Gesamttotal von ausgehendem Traffic und Requests sowie die über diese Periode gemittelte Speicherbelegung zu sehen.

Mit dem Punkt "Hide Deleted" bestimmen Sie, ob für die angezeigten Objects Users auch solche Buckets eingeblendet werden sollen, die zwischenzeitlich gelöscht wurden. Übrigens: Um eine bestmögliche Nachvollziehbarkeit von Nutzung und Kosten zu gewährleisten beziehen sich die Datumsangaben der Objects Metrics immer auf die Lokalzeit in Zürich, unabhängig davon, welche Zeitzone Sie für die Anzeige von Uhrzeiten in Ihrem Benutzerkonto eingestellt haben.

Noch mehr Daten verfügbar in unserer API

Selbstverständlich lassen sich die Objects Metrics auch via unsere API abfragen. Via API wird zusätzlich auch der eingehende Traffic ausgewiesen sowie die Anzahl der Objects, die – über den gewählten Zeitraum gemittelt – im entsprechenden Bucket gespeichert war. Diese beiden Werte haben keinen Einfluss auf die Kosten unseres Object Storage, können aber dennoch für Ihre Nutzungsauswertung hilfreich sein. Im Übrigen ist via API auch die Nutzung durch Objects Users sichtbar, die nicht mehr existieren.

Falls Sie die Metrics nur für einen bestimmten Bucket oder Objects User benötigen, geben Sie den gewünschten Filter direkt im API-Aufruf mit:

$ curl -H "$AUTH_HEADER" 'https://api.cloudscale.ch/v1/metrics/buckets?start=2019-06-09&end=2019-06-11&bucket_name=mytestbucket'

{
  "start": "2019-06-08T22:00:00Z",
  "end": "2019-06-11T22:00:00Z",
  "data": [
    {
      "subject": {
        "name": "mytestbucket",
        "objects_user_id": "62c2...ab53"
      },
      "time_series": [
        {
          "start": "2019-06-08T22:00:00Z",
          "end": "2019-06-11T22:00:00Z",
          "usage": {
            "requests": 136,
            "object_count": 157,
            "storage_bytes": 18036937,
            "received_bytes": 10855616,
            "sent_bytes": 14278972
          }
        }
      ]
    }
  ]
}

Damit erreichen Sie, dass nur die tatsächlich für Sie relevanten Daten ausgegeben werden. Selbstverständlich finden Sie alle Details zum API-Aufruf auch in unserer API-Dokumentation.

Mit den Objects Metrics steht Ihnen ein neues Werkzeug zur Verfügung, um spontan oder automatisiert die Nutzung unseres Object Storage tagesgenau aufzuschlüsseln – sei es für Ihr Buchhaltungs-Team oder für das Profiling eines bestimmten Setups. So oder so: mit unserem Object Storage bezahlen Sie nur, was Sie tatsächlich nutzen.

Für beste Transparenz,
Ihr cloudscale.ch-Team

Seien es Papierformate, Glühbirnen oder Lebensmittelsicherheit: Oft unbemerkt sorgen Normen im Hintergrund für ein reibungsloses Funktionieren in allen Lebensbereichen. Die Normen der ISO-27000er-Reihe sind die bekanntesten im Bereich der Informationssicherheit, welche nebst Vertraulichkeit von Informationen auch deren Integrität und Verfügbarkeit umfasst. Nach ISO zertifiziert wird dabei nicht ein konkretes Produkt, sondern ein Unternehmen bzw. dessen Managementsystem, das die Informationssicherheit gewährleisten soll.

ISO/IEC 27001:2013 definiert ein Set von 114 sogenannten Controls und damit eine Liste mit Anforderungen zu allen möglichen Aspekten der Informationssicherheit, die es umzusetzen gilt. Wie dies konkret geschieht, entscheidet dabei jedes Unternehmen individuell – die Norm ist bewusst offen gehalten, so dass Organisationen aller Grössen und Branchen sie umsetzen können. Bei uns als Public-Cloud-Anbieter haben wir die Norm daher mit dem entsprechenden Fokus auf Infrastructure-as-a-Service (IaaS) implementiert.

In unserem Fall war es naheliegend, gleichzeitig zwei weitere Normen umzusetzen: Im Unterschied zur universell anwendbaren ISO 27001 befasst sich ISO 27017 spezifisch mit Cloud-Diensten und definiert eine Reihe von zusätzlichen Controls, die für Cloud-Anbieter und -Anwender relevant sind. ISO 27018 wiederum widmet sich dem Schutz personenbezogener Daten (PII: Personally Identifiable Information) in Public Clouds – ein Thema, das vor allem durch die EU-DSGVO verstärkte Aufmerksamkeit erhalten hat. Die cloudscale.ch AG hat sich auch nach diesen beiden Normen (ISO/IEC 27017:2015 und ISO/IEC 27018:2019) erfolgreich auditieren lassen.

Sie finden alle Zertifikate auf unserer Website oder direkt unter:

• https://www.cloudscale.ch/de/iso-27001-zertifikat.pdf
• https://www.cloudscale.ch/de/iso-27017-27018-zertifikat.pdf

Wie sich unser Weg zur Zertifizierung gestaltete

Rückblickend können wir sagen, dass sich unser Alltag durch die Einführung eines Informationssicherheits-Managementsystems (ISMS) und dessen Zertifizierung nicht stark verändert hat. Der Sicherheitsgedanke war schon immer Teil unserer DNA und die meisten Massnahmen zur Wahrung der Informationssicherheit sind bei uns bereits seit Jahren gelebte Praxis. Schon länger wurde jedoch deutlich, dass unseren Kunden die durchgehende Zertifizierung der gesamten Lieferkette wichtig ist. Der Entscheid für die offizielle Zertifizierung nach ISO 27001 fiel dann vor rund 1.5 Jahren. In der Folge holten wir uns externes Know-how für diesen Prozess.

Das eigentliche "ISO-Projekt" startete im Frühling 2018 mit einer Reihe von Workshops zusammen mit unserem Berater, Dieter Roth, und einem Satz an Vorlagen für das ISMS. Die harte Arbeit folgte dann, als es darum ging, die generischen Dokumente an unsere Realität anzupassen (und, zugegebenermassen, ein kleines bisschen auch in umgekehrter Richtung). Unser dokumentiertes ISMS sollte ja Vorgaben und Prozesse so widerspiegeln, wie wir sie für unsere tägliche Arbeit als angemessen erachten. Von Vorteil war natürlich, dass unsere Datacenter bereits ISO-27001-zertifiziert waren, wodurch wir uns in diesem Bereich eigene Regelungen sparen konnten.

Der Zertifizierungs-Audit schliesslich – eine Art Prüfungssituation – verlief überraschend angenehm. Es galt dabei, an drei Tagen einem unabhängigen Experten Red' und Antwort zu stehen sowie diverse Nachweise zu erbringen. Wir spürten, dass der Auditor von Swiss Safety Center unser Geschäft versteht, und für ihn war schnell klar, weshalb wir die Dinge so tun, wie wir sie tun. Dass dann im ganzen Audit keine einzige Abweichung festgestellt wurde, hatten wir natürlich nicht zu hoffen gewagt. Umso mehr bestärkt uns dieses Ergebnis in unserer Sicherheitskultur, die unsere Arbeit von Anfang an prägte.

Welche nächsten Schritte nun vor uns liegen

Die Erstzertifizierung ist ein langersehnter Meilenstein und für viele unserer Kunden eine Bestätigung für das Vertrauen, das sie von Anfang an in uns gesetzt haben. Eine zentrale Anforderung der ISO/IEC 27000er-Normen ist aber auch die kontinuierliche Verbesserung, die fest im ISMS verankert sein muss. Nicht nur die Sicherheitsvorkehrungen, sondern auch sämtliche Prozesse müssen immer wieder geprüft und weiterentwickelt werden. Eine regelmässige Kontrolle erfolgt in jährlichen, intern durchgeführten Audits und in ebenfalls jährlichen, externen Überwachungs- bzw. Rezertifizierungs-Audits durch die Zertifizierungsstelle.

Natürlich fliesst der Sicherheitsgedanke auch in all unsere künftigen Projekte ein. Als Beispiele erwähnt seien hier die Inbetriebnahme eines weiteren Schweizer Datacenter-Standorts, der unseren Kunden geo-redundante Setups ermöglicht ( Verfügbarkeit), die Umstellung unseres Ceph-Clusters auf BlueStore, welches über integrierte Prüfsummen verfügt ( Integrität) sowie die Festplatten-Verschlüsselung unserer Storage-Server ( Vertraulichkeit).

Informationssicherheit war von Anfang an ein zentrales Anliegen von cloudscale.ch, und Gespräche mit unseren Kunden bestätigen uns deren Stellenwert immer wieder aufs Neue. Nicht ohne Stolz sehen wir die erfolgreiche Zertifizierung nach ISO 27001, ISO 27017 und ISO 27018 als Anerkennung für unseren Einsatz und als Motivation, den eingeschlagenen Weg weiter zu gehen.

Mit Brief und Siegel,
Ihr cloudscale.ch-Team

Die aktuellsten CPU-Lücken betreffen alle Prozessor-Modelle von Intel der letzten Jahre. Prozessoren anderer Hersteller wie AMD und ARM sind nach derzeitigem Kenntnisstand nicht betroffen. Die Schwachstellen im Chip-Design ermöglichen es, dass ein Prozess über sogenannte Seitenkanalangriffe auf Daten zugreifen kann, die von einem anderen Prozess auf dem gleichen CPU-Kern verarbeitet werden. Ursache sind verschiedene Pufferbereiche innerhalb der CPU, in denen Datenfragmente liegen bleiben, welche dann von einem anderen Prozess ausgelesen werden können. Aktiviertes Hyper-Threading erleichtert ein Ausnutzen dieser Schwachstellen zusätzlich.

Dies ist insbesondere dann relevant, wenn Programmcode ausgeführt wird, der – aus Sicht eines konkreten Prozesses oder Benutzers – nicht vertrauenswürdig ist. Seien dies aktive Inhalte auf Websites, die man besucht, oder Software in einem "benachbarten" virtuellen Server in der Cloud: potenziell kann Schadcode auf Teile der eigenen Daten zugreifen, die kurz zuvor auf dem gleichen physischen Prozessorkern verarbeitet wurden.

Wie cloudscale.ch gegen diese Lücken vorgeht

Bei einem Public-Cloud-Anbieter läuft naturgemäss "nicht vertrauenswürdiger Code" auf den Compute-Nodes. Auch bei cloudscale.ch kommen Intel-CPUs aus den betroffenen Modellreihen zum Einsatz. Entsprechend ernst nehmen wir das Thema und arbeiten daran, die bekanntgewordenen Angriffswege vollständig zu beseitigen. In einem ersten Schritt haben wir unter anderem alle verfügbaren Sicherheitsupdates in unserem Lab installiert. Dazu gehören Microcode-Updates, die Intel für die betroffenen Prozessoren bereitgestellt hat, genauso wie das Deaktivieren von Hyper-Threading, ein aktualisierter Linux-Kernel sowie Patches für den Virtualisierungs- und Storage-Layer. Wie bei jedem Update laufen aktuell Tests um sicherzustellen, dass die Sicherheitsupdates keine unerwünschten Auswirkungen auf die gewohnte Stabilität unserer Infrastruktur haben.

Sobald wir in den Tests das einwandfreie Funktionieren der gepatchten Versionen bestätigen können, werden wir die produktiven Systeme im gleichen Verfahren aktualisieren. Um trotz laufendem Betrieb möglichst rasch alle betroffenen Systeme absichern zu können, setzen wir ein ausserordentliches Wartungsfenster an, das ab sofort bis zum nächsten Dienstag, 21.05.2019 um 24:00 Uhr dauert. Wir setzen alles daran, Ihre virtuellen Server möglichst wenig zu beeinträchtigen: bevor wir mit den Arbeiten an einem Compute-Node beginnen, verschieben wir die virtuellen Server mittels Live-Migration auf einen anderen, bereits aktualisierten Node. Dennoch ist es möglich, dass Sie vorübergehend eine verringerte Leistung Ihrer Server und/oder kurze Unterbrüche bei den Netzwerkverbindungen feststellen. Für allfällige Unannehmlichkeiten bitten wir Sie bereits jetzt um Verständnis.

Was Sie zur Absicherung Ihrer Server unternehmen sollten

Die Massnahmen, die wir auf unserer Seite treffen können, schützen Ihre virtuellen Server davor, dass aus anderen virtuellen Servern auf Daten zugegriffen werden kann. Um Ihre Daten auch vor Zugriffen aus anderen Prozessen innerhalb des gleichen virtuellen Servers zu schützen, installieren Sie bitte die Sicherheits-Updates, die von den jeweiligen Linux-Distributionen und anderen Software-Herstellern publiziert werden.

Um die Sicherheitslücken zu schliessen empfiehlt Intel, jeweils die betroffenen Pufferbereiche in den CPUs zu löschen, wenn zwischen der Ausführung von Prozessen mit unterschiedlichen Berechtigungen gewechselt wird. Mit den Microcode-Updates von Intel für die betroffenen CPUs stehen dafür angepasste Routinen zur Verfügung. Wenn Sie nach unserem Wartungsfenster, d.h. ab Mittwoch, 22.05.2019, Ihre virtuellen Server einmal komplett aus- und wieder einschalten (ein Reboot genügt nicht), ist innerhalb Ihrer Server das neue CPU-Flag "md_clear" sichtbar. Entsprechend aktualisierte Versionen Ihres Betriebssystems sowie anderer Software können daran erkennen, dass und wie sie die CPU-Puffer löschen sollen, um Ihre Daten bestmöglich vor anderen, möglicherweise weniger vertrauenswürdigen Prozessen innerhalb des gleichen virtuellen Servers zu schützen.

Obwohl die neuen Angriffsszenarien nach aktuellem Kenntnisstand relativ schwierig auszunutzen sind und ein potenzieller Zugriff auf Daten nicht gezielt möglich ist, setzen wir alles daran, diese Lücken schnell und vollständig zu schliessen. Für einen bestmöglichen Schutz empfehlen wir Ihnen, auch innerhalb Ihres Servers zeitnah alle verfügbaren Sicherheitsupdates einzuspielen. Sollten Sie Fragen im Zusammenhang mit unseren aktuellen Massnahmen haben, stehen wir Ihnen natürlich gerne zur Verfügung.

Für sichere Server,
Ihr cloudscale.ch-Team

Es gibt verschiedene Gründe, Anwendungen oder Microservices in Container wie z.B. Docker zu packen. Beispiele dafür sind die saubere Trennung oder unabhängige Deployments einzelner Services. Da die Container-Virtualisierung im Unterschied zu vollvirtualisierten Maschinen kaum Overhead verursacht, verbraucht selbst eine feingranulare Separierung von Services in Containern nur unwesentlich mehr Ressourcen.

Bei der Verwaltung solcher Container hilft Kubernetes (oder "K8s") als Orchestrierungs-Lösung. So startet es alle benötigten Container in der gewünschten Anzahl und verteilt sie auf die verfügbaren Nodes. Fällt ein Container aus, wird er automatisch auf einem geeigneten Node neu gestartet. Nicht zuletzt lässt sich Kubernetes über Config-Files und Scripts steuern und dadurch optimal in Konfigurationsmanagement-Systeme integrieren.

Wie CSI den "Self-Service" für Storage ermöglicht

Standardmässig haben solche Container einen flüchtigen Speicher, d.h. Änderungen im Dateisystem eines Containers gehen bei einem Neustart verloren. Selbstverständlich können auch sogenannte "Persistent Volumes" erstellt und an einen Container durchgereicht werden. Bisher war dies jedoch typischerweise mit manuellem Aufwand sowie der Kopplung an einen bestimmten Node verbunden und passte deshalb nicht so recht in ein dynamisches Container-Konzept.

Mit dem kürzlich verabschiedeten "Container Storage Interface" (CSI) gibt es nun einen definierten Standard, um aus einem "Persistent Volume Claim" automatisch ein passendes Volume erstellen zu lassen. Dieses wird dann gleich im richtigen Container gemountet – egal, auf welchem Node der Container läuft. Selbstverständlich kann das Volume auch an einen anderen Container umgehängt und bei Bedarf direkt aus Kubernetes heraus wieder gelöscht werden.

Welche Vorteile CSI bei cloudscale.ch sonst noch bietet

Wie von unseren Volumes für Cloud-Server gewohnt basieren auch Persistent Volumes für Kubernetes auf blitzschnellem SSD-only Speicher und können praktisch beliebig gross sein. Bei einem Platzbedarf ab 100 GB steht zudem günstiger Massenspeicher zur Verfügung. Die Auswahl erfolgt direkt im Persistent Volume Claim mit dem Parameter "storageClassName" (cloudscale-volume-ssd bzw. cloudscale-volume-bulk).

Als Zusatz-Funktion bieten wir zudem die Festplattenverschlüsselung (Full Disk Encryption) mit LUKS an. Verschlüsselte Volumes werden ganz einfach mit einem speziellen storageClassName angelegt und können nur verwendet werden, wenn in Kubernetes ein Abschnitt mit dem passenden Verschlüsselungs-Key konfiguriert wird – ein potenzieller Angreifer ohne diesen Key sieht nur Datenmüll. Ob zusätzlich verschlüsselt oder nicht: auch Persistent Volumes für Kubernetes werden bei cloudscale.ch ausschliesslich in Rechenzentren mit Standort Schweiz gespeichert.

Für Ihre ersten eigenen Schritte empfehlen wir Ihnen Rancher zur einfachen Installation eines Basis-Setups mit Kubernetes. Anschliessend installieren Sie nur noch den cloudscale.ch CSI-Treiber von GitHub und hinterlegen einmalig ein API-Token aus dem Cloud Control Panel. Diverse Konfigurations-Beispiele für Container und Volumes finden Sie selbstverständlich ebenfalls auf GitHub.

Leinen los!
Ihr cloudscale.ch-Team

OPNsense ist eine beliebte Distribution, um z.B. Router, Firewalls, NAT- oder VPN-Gateways zu betreiben. Benutzerfreundlichkeit wird dabei grossgeschrieben: Die Firewall wird mit Hilfe eines Wizards eingerichtet und auch danach komplett über ein grafisches Web-Frontend konfiguriert. Das Hantieren mit Konfigurationsdateien erübrigt sich. Wer sich nicht auf das Web-Frontend beschränken möchte, geniesst natürlich trotzdem vollen SSH-Zugriff auf seine Firewall.

Der Funktionsumfang deckt all Ihre Bedürfnisse ab: nebst der Funktionalität als NAT-Gateway für Ihr privates Netz fungiert die Firewall beispielsweise auch als VPN-Endpunkt oder als Load-Balancer für redundant ausgelegte Webserver. Plug-ins für praktisch jeden Anwendungsfall runden das Paket ab. OPNsense basiert auf FreeBSD und wird als Open-Source-Projekt von einer starken Community getragen. Es ist sehr haushälterisch im Umgang mit RAM und CPU-Leistung und ermöglicht damit einen kostengünstigen Betrieb.

Wie ein einfaches Setup mit Firewall aussehen kann

Private Netze sind bei cloudscale.ch schon seit Längerem verfügbar und eignen sich ideal für Server, die zwar in einem professionellen Rechenzentrum laufen müssen, aber aus dem Internet nicht direkt erreichbar sein dürfen. Statt Server bei sich im Büro ans LAN anzuschliessen, können Sie diese bei cloudscale.ch einrichten und mit Ihrem "Private Network" verbinden, das aus dem Internet und für andere Kunden komplett unsichtbar ist. Als Firewall zwischen privatem Netz und Internet erstellen Sie einen virtuellen Server mit OPNsense: damit haben Sie die volle Kontrolle, wo welche Daten fliessen sollen, und wo nicht.

Für Sie bleibt der Zugriff auf Ihre Daten denkbar einfach: Konfigurieren Sie auf OPNsense über das Web-Frontend ein VPN und erstellen Sie für jede berechtigte Person ein Benutzerkonto. Sobald diese sich mit diesem VPN verbinden, können sie wie gewohnt auf Ihre Server zugreifen – sogar unabhängig vom eigenen Standort. Der Datenverkehr im VPN erfolgt natürlich verschlüsselt, um Ihre Daten vor Ausspähung zu schützen. Auf diese Weise ermöglichen Sie auch Mitarbeitern im Home-Office oder Aussendienst optimalen Zugriff auf Ihre internen IT-Tools.

Auch für öffentlich zugängliche Systeme wie Ihre Website bietet eine OPNsense-Firewall zusätzlichen Schutz. Stellen Sie für Angreifer eine weitere Hürde auf und verhindern Sie viele Angriffe von vornherein, indem Dienste wie Datenbank-Backends aus dem Internet gar nicht erreichbar sind. Ein Reverse-Proxy auf Ihrer OPNsense-Firewall (z.B. mit dem HAProxy-Plugin) leitet die HTTP(S)-Zugriffe Ihrer Besucher weiter an den Webserver in Ihrem privaten Netz, und liefert die entsprechenden Webseiten über das Internet aus. Ein weiterer Vorteil: HAProxy unterstützt auch Setups mit mehreren Webservern und erlaubt es so, die Last zu verteilen und sogar bei Ausfall oder Wartung eines Webservers Ihre Website verfügbar zu halten.

Weitere Tipps für Sie

Für optimale Sicherheit empfehlen wir Ihnen die Wahl von starken Passwörtern sowie die zeitnahe Installation von auf der Firewall verfügbaren Sicherheitsupdates. Falls Sie für den SSH-Zugriff lieber mit Keys arbeiten, können Sie diese in der Benutzer-Verwaltung von OPNsense hinterlegen. Und wie unser Cloud-Control-Panel unterstützt auch OPNsense eine Zwei-Faktor-Authentifizierung via TOTP.

Ein VPN oder Reverse-Proxy wie in den obigen Beispielen sind natürlich nur einzelne von vielen nützlichen Anwendungsfällen. Ebenso ist es möglich, Floating IPs direkt zu internen Servern zu routen und gleichzeitig von den Vorteilen eines dedizierten Firewall-Systems zu profitieren.

Neben der OPNsense- bieten wir Ihnen übrigens auch die pfSense CE-Distribution zur Auswahl für Ihre virtuellen Server an. Aus den gleichen Ursprüngen entstanden, orientieren sich die beiden Distributionen im Detail an den Bedürfnissen der jeweiligen Community. In den meisten Szenarien ist der Entscheid für eine der beiden Lösungen aber vor allem "Geschmackssache".

Die OPNsense- und pfSense CE-Distributionen bieten noch viel mehr, als wir an dieser Stelle ausführen können. Erkunden Sie die zahlreichen Features in den übersichtlichen Web-Frontends, und erfahren Sie mehr über die verfügbaren Funktionen in den umfangreichen Dokumentationen der OPNsense- und pfSense CE-Distribution.

Schotten dicht!
Ihr cloudscale.ch-Team

Auch wenn Ceph viele Dinge automatisch erledigt, bleiben einige Administrationsaufgaben zu tun. Mimic unterstützt unsere Sysadmins mit einem neuen Dashboard, welches auf einen Blick alle wichtigen Infos zum aktuellen Cluster-Status zusammenfasst. Die Kommandozeilen-Tools von Ceph formatieren ihre Ausgabe nun einheitlich in JSON, so dass diese Daten einfacher in Scripts weiterverarbeitet werden können.

Verbesserungen erhielt auch der upmap-Mechanismus. Dieses mit der Vorversion "Luminous" neu eingeführte Feature erlaubt es, die Datenmenge gleichmässig auf alle OSDs zu verteilen, wenn durch die laufende Storage-Nutzung ein Ungleichgewicht entstanden ist. So lassen sich punktuelle Platz- und Performance-Engpässe vermeiden. Schliesslich erhält Mimic zeitnah (Sicherheits-)Updates und wird von den aktuellsten Ceph-Ansible-Playbooks unterstützt, in denen bereits viel Know-how der Ceph-Community steckt.

Drei hilfreiche Features für Objects, die Sie kennen sollten

Eines der jüngsten Features unseres S3-kompatiblen Object Storage ist "Bucket Lifecycle": Legen Sie fest, wann Objects verfallen sollen, z.B. damit im Object Storage abgelegte Backups nach einer gewissen Zeit automatisch aufgeräumt werden. Mittels eines frei definierbaren Prefix können Sie das Set von Objects definieren, für welche ein bestimmter Lifecycle gelten soll. Das System arbeitet die definierten Lifecycles dann täglich zwischen Mitternacht und 6:00 Uhr (CET/CEST) ab.

Mit der "Server-side Encryption" stellen Sie sicher, dass Ihre Daten im Object Storage verschlüsselt abgelegt werden. Beim von cloudscale.ch unterstützten Modus "SSE-C" bleibt die Schlüsselverwaltung komplett in Ihrer Hand: Sie entscheiden selbst, welche Objects mit welchem Schlüssel geschützt werden. Das spätere Lesen dieser Objects ist dann nur noch mit dem jeweiligen Schlüssel möglich.

"Bucket Policies" schliesslich ermöglichen Ihnen das Setzen von detaillierten Berechtigungen für Ihre Buckets und Objects. Legen Sie fest, welche anderen Benutzer Zugriff erhalten sollen, und welche Aktionen dabei erlaubt sind. Wenn Sie z.B. jemandem Objects zum Download bereitstellen möchten, legen Sie einfach einen zusätzlichen Objects User an und erteilen diesem in einer Bucket Policy ausschliesslich die benötigten Lese-Rechte.

Welche Verbesserungen wir auf Basis von Mimic noch planen

Unser Ceph Storage-Cluster verteilt im Hintergrund alle Daten dreifach repliziert über eine Reihe von Storage-Systemen. Die einzelnen Datenfragmente werden dabei in einem XFS-Dateisystem auf den physischen Disks abgelegt. Nach dem Upgrade auf Ceph Mimic planen wir nun die Umstellung auf das neue "BlueStore" Storage-Backend, welches mit Luminous offiziell eingeführt wurde. Dabei entfällt das POSIX-Dateisystem als Zwischenschicht, da BlueStore die Daten direkt als Objekte auf dem Blockdevice ablegt. Ein weiterer Vorteil von BlueStore sind die integrierten Prüfsummen für alle Daten und Metadaten. Damit wird bei jedem Lesevorgang sichergestellt, dass die gelesenen Daten tatsächlich korrekt sind.

Das sukzessive Neu-Anlegen der Ceph OSDs bei der Umstellung auf BlueStore werden wir gleichzeitig für eine weitere Verbesserung nutzen: die Verschlüsselung aller Daten-Disks in unserem Storage-Cluster. Damit führen wir eine zusätzliche Sicherheitsschicht zum Schutz Ihrer Daten ein, z.B. für den Fall, dass wir eine defekte Disk entsorgen müssen.

Bei cloudscale.ch kommen Sie in den vollen Genuss der Vorteile eines verteilten und replizierten Storage-Clusters. Und dank der laufenden Weiterentwicklung von Ceph durch die aktive Open-Source-Community profitieren Sie bei jedem Upgrade von neuen Features sowie von Verbesserungen der Leistung und Zuverlässigkeit. Ganz automatisch.

Mit Ceph Mimic auf dem neuesten Stand,
Ihr cloudscale.ch-Team

Unserem hohen Anspruch in Bezug auf "Simplicity" folgend, bleibt der Start eines neuen Servers praktisch unverändert. Für optimale Performance ist das Betriebssystem auf einem SSD-only-Volume installiert, wobei die ersten 10 GB wie bisher kostenlos sind. Mit einem Klick auf "Show more options" können Sie neu jedoch praktisch beliebig viele zusätzliche Volumes an Ihren neuen Server anhängen. Legen Sie so zum Beispiel ein separates Volume für /var an – ganz ohne Änderung an der bestehenden Partitionierung des Root-Volumes. Auch nachträglich können je nach Bedarf zusätzliche SSD- und Bulk-Volumes hinzugefügt oder entfernt werden.

Mit den meisten verfügbaren Betriebssystem-Images ist (bedingt u.a. durch Partitionsschema und Dateisystem) eine maximale Grösse des Root-Volumes von 2 TB praktikabel. Mit zusätzlichen Volumes können Sie diese Grenze nun überwinden und auch grössere Datenmengen auf unserem hochperformanten SSD-only Storage-Cluster verwalten. Und falls Sie erstmal klein starten möchten, klappt eine spätere Vergrösserung jetzt sogar im laufenden Betrieb: nachdem OpenStack dieses Feature in Kombination mit Ceph bisher nicht unterstützt hatte, haben Engineers von cloudscale.ch eine entsprechende Lösung entwickelt, welche auch an das offizielle OpenStack-Projekt zurückgegeben wird.

Welche weiteren Möglichkeiten via API zur Verfügung stehen

Über die cloudscale.ch API stehen Ihnen die oben erwähnten Möglichkeiten natürlich ebenfalls zur Verfügung. Zudem ist es auch möglich, zusätzliche Volumes von den jeweiligen virtuellen Servern zu trennen und später an andere Server anzuschliessen. Damit können Sie solche Volumes dazu verwenden, Daten von einem virtuellen Server auf einen anderen zu übernehmen. Bitte beachten Sie, dass das Root-Volume eines virtuellen Servers nicht vom Server getrennt und/oder separat gelöscht werden kann.

Auf die gleiche Weise können Sie bestehende Daten "zur Seite legen", z.B. während der betreffende virtuelle Server gelöscht und neu aufgesetzt wird. Übergeben Sie dem API-Call in diesem Fall eine leere Liste als neue Server-UUID – das Volume mit den Daten bleibt in Ihrem Account erhalten und kann zu einem späteren Zeitpunkt wieder an einen anderen virtuellen Server angeschlossen werden. Mehr Informationen über die neu verfügbaren API-Calls finden Sie natürlich in unserer API-Dokumentation.

Worauf sich Kubernetes-Anwender zusätzlich freuen dürfen

Bereits in der Pipeline ist die Unterstützung für "CSI": Das "Container Storage Interface", dessen Spezifikation derzeit finalisiert wird, ist eine definierte Schnittstelle zum automatischen Bereitstellen von "Persistent Volumes" in Kubernetes. Ohne manuellen Eingriff können damit Persistent Volumes vom gewünschten Typ und der gewünschten Grösse erstellt werden, sobald ein Container einen entsprechenden "Persistent Volume Claim" verwendet. So erstellte Persistent Volumes sind nicht an einen bestimmten Node gebunden, sondern immer dort verfügbar, wo sie von einem Container gerade benötigt werden.

Mit der Unterstützung für zusätzliche Volumes sowie der Erweiterung unserer API haben wir die Grundlagen geschaffen, auf denen der cloudscale.ch CSI-Treiber aufbauen wird. Selbstverständlich werden die Neuerungen aber auch allen anderen Orchestrierungs-Lösungen zugute kommen, u.a. unserem Ansible Cloud Module sowie dem Terraform-Plugin für den Provider "cloudscale".

Wenn Sie sich in der Vergangenheit manchmal die Flexibilität einer externen Festplatte gewünscht haben, so bieten Ihnen zusätzliche Volumes nun genau das. Zudem sind sie die ideale Lösung, wenn Sie z.B. nur vorübergehend mehr Speicherplatz benötigen – sobald Sie den Platz nicht mehr brauchen, löschen Sie das Volume einfach wieder. Oder Sie überlassen dank der neuen API-Calls die Arbeit einfach dem Orchestrierungs-Tool Ihrer Wahl.

Für alle Daten das passende Volume,
Ihr cloudscale.ch-Team

Erster Kontaktpunkt beim Benutzen von cloudscale.ch ist unser selbst entwickeltes Cloud-Control-Panel. Diese in Python geschriebene Software stellt Ihnen das Webinterface sowie die API zur Verwaltung Ihrer Server zur Verfügung und verarbeitet die Abrechnung bezogener Services. Im Hintergrund stützt sich unser Control-Panel stark auf OpenStack: als eines der führenden Open-Source-Projekte in diesem Bereich verwaltet die Cloud-Plattform unter anderem die physisch vorhandene Rechenpower, teilt IP-Adressen zu und konfiguriert interne Netze zwischen Ihren Servern.

Genauso zentral ist Ceph: die verteilte Storage-Lösung wird ebenfalls als Open-Source gepflegt und sorgt für die replizierte und performante Speicherung Ihrer Volumes und Objects. Aber auch die "kleineren" Bausteine in unserem Setup sind essenziell, z.B. unser DNS-System, ExaBGP für die dynamische Zuweisung von Floating IPs, oder RabbitMQ, das eine Art Bindeglied zwischen unserem Control-Panel und anderen involvierten Systemen darstellt.

Beispiele von potenziellen Fehlerquellen

Vieles, was aus User-Perspektive als eine zusammenhängende Aktion erscheint, bedingt im Hintergrund mehrere separate Schritte. Nebst dem eigentlichen Anlegen eines neuen virtuellen Servers wird für diesen bspw. ein Netzwerk-Port erstellt, eine IP-Adresse zugewiesen, ein Volume mit dem gewählten Betriebssystem eingerichtet und ein Reverse-DNS-Eintrag gesetzt. Egal, wie gut alles getestet ist: dass man in irgend einer beteiligten Softwarekomponente auf einen unerwarteten Fehler stösst, lässt sich nie ganz ausschliessen.

Eine weitere mögliche Fehlerquelle sind sog. Race-Conditions. Um Inkonsistenzen zu vermeiden können bestimmte (Teil-)Aktionen nur ein Mal zur gleichen Zeit ausgeführt werden; wird der selbe Schritt durch eine parallele Aktion ebenfalls benötigt, schlägt eine der beiden Aktionen fehl. Darüber hinaus sind einige Schritte von zusätzlichen Bedingungen abhängig, z.B. dass bestimmte Sicherheitslimiten ("Quotas") eingehalten werden.

Säulen des Error-Handlings bei cloudscale.ch

Im Rahmen des Error-Handlings bei cloudscale.ch ist es unser vorrangiges Ziel, dass am Ende jeder Aktion ein nutzbarer Zustand resultiert. Wo sinnvoll haben wir daher vorbereitete Rollbacks mit eingebaut: Würde ein Fehler in einem Teilschritt z.B. zu einem Server führen, der nicht funktioniert und durch einen Folgefehler möglicherweise auch nicht mehr gelöscht werden kann, kommt die Rollback-Funktion zum Zug. Sie stellt sicher, dass bereits abgeschlossene Teilschritte rückgängig gemacht werden, so dass – trotz Fehler – am Ende wieder ein sauberer Zustand vorliegt.

Noch besser ist es natürlich, Fehler soweit als möglich zu vermeiden. Dazu überwachen wir unsere Systeme permanent auf Fehlermeldungen und prüfen in jedem Einzelfall, ob sich dieser in Zukunft durch einen bestimmten Patch oder andere Verbesserungen vermeiden lässt. Zudem haben wir Transaktionen, die zu Race-Conditions führen können, nach Möglichkeit so optimiert, dass die Wahrscheinlichkeit einer tatsächlichen parallelen Ausführung minimiert wird. Sollte dennoch einmal eine Transaktion abgebrochen werden müssen, weil sie mit einer anderen parallelen Operation zeitlich zusammenfällt, wird dieser Fall abgefangen und die Transaktion bis zu einer definierten Anzahl Versuche wiederholt. So kann die Aktion, die der Benutzer gewählt hat, unter Umständen doch noch erfolgreich abgeschlossen werden.

Seit jeher ist die Benutzerfreundlichkeit eines der zentralen Anliegen bei cloudscale.ch. Auch wenn die Systeme hinter den Kulissen komplex sind und immer etwas schiefgehen kann, sollen Aktionen in unserem Cloud-Control-Panel und der API wann immer möglich zum gewünschten Ergebnis führen. Und selbst wenn nicht: Ihren weiteren/anderen Aktionen steht nichts im Wege.

Gut vorbereitet,
Ihr cloudscale.ch-Team

Heutzutage erwarten Benutzer schnell reagierende Websites; je schneller eine Seite lädt, umso weniger Besucher klicken weg. Was sich bei einem Online-Shop direkt im Umsatz niederschlagen kann, ist auch bei unserem Cloud-Control-Panel ein wichtiger Faktor für den Arbeitsfluss unserer Kunden. An immer mehr Stellen in unserem Control-Panel verzichten wir daher darauf, die komplette Seite neu zu laden; einzelne Elemente wie der Status Ihrer Server werden stattdessen im Hintergrund abgerufen und auf der bereits angezeigten Seite einfach aktualisiert.

Diesen "Ajax" genannten Ansatz unterstützen verschiedene Libraries und Frameworks. Wir haben uns für React (in Kombination mit Redux) entschieden, weil diese Open-Source-Library von einer grossen Community eingesetzt wird und eine Vielzahl kompatibler Libraries für weitere Funktionalität zur Verfügung steht. Mit React werden die Komponenten der einzelnen Seiten im Browser mittels JavaScript generiert. Während eine Komponente eine asynchrone Operation ausführt (z.b. Daten lädt), kann der Nutzer einfach weiterarbeiten – ein Reload der ganzen Seite hingegen würde alles blockieren.

Vorteile für unsere Software-Entwicklung

Dass unser Cloud-Control-Panel nicht mehr als komplett fertige HTML-Seite von unseren Systemen ausgeliefert wird, vereinfacht auch die Arbeit unserer Software-Entwickler. Indem viele Informationen ganz ohne Formatierung von unseren Servern abgerufen und erst durch React im Browser dargestellt werden, kann die Ajax-API praktisch identisch zur sowieso vorhandenen öffentlichen API gehalten werden – eine zweimalige Implementierung der gleichen Funktionalität erübrigt sich. So bleibt mehr Zeit, um neue Features zügig umzusetzen.

Ein weiterer Vorteil dieses Ansatzes ist, dass auch für das grafische Frontend Unit-Tests eingesetzt werden können. Dies im Gegensatz zu serverseitig erstellten HTML-Seiten mit nachgeladenem JavaScript, welche kaum automatisiert testbar sind. React eignet sich zudem ideal für eine schrittweise Einführung: überall wo React-Komponenten die Benutzbarkeit merklich verbessern, haben wir sie inzwischen bereits im Einsatz. Dort wo die Vorteile etwas subtiler sind, werden wir die Umstellung auf React mit anderen Verbesserungen kombinieren – so sparen wir uns den Aufwand, die gleiche Stelle mehrfach anzufassen.

Wohin sich unser Control-Panel mit React entwickelt

Je mehr Komponenten mit React umgesetzt sind, desto näher kommt unser Cloud-Control-Panel einer Single-Page-App. Bereits heute können die Tabs in der Server-Detailansicht mit jeweils eigenen URLs direkt adressiert werden, beim Wechsel zwischen den Tabs ist jedoch kein Reload der Seite nötig. Dieser Ansatz soll – wo hilfreich – auch an weiteren Stellen zum Einsatz kommen.

Beim Entwickeln neuer Features setzen wir die Implementierung in der Regel zuerst in unserer öffentlichen API um, womit viele Tools aus dem DevOps-Umfeld die neuen Features bereits nutzen können. Von hier ist es dann nur noch ein kleiner Schritt, um das Feature auch im Webinterface verfügbar zu machen: Der benötigte Ajax-API-Endpunkt ergibt sich weitestgehend aus dem zuvor bereits erstellten Endpunkt der öffentlichen API, und React kümmert sich mit Hilfe von JavaScript optimal um die Darstellung der Funktionalität im Browser.

Während wir die Integration von cloudscale.ch in immer mehr Orchestrierungs- und Management-Tools unterstützen, hat die Benutzerfreundlichkeit unseres eigenen Cloud-Control-Panels für uns weiterhin eine besondere Bedeutung. Dank React können Sie Ihre Server in logischen und flüssigen Abläufen verwalten – fast so, als wäre unser Cloud-Control-Panel eine lokale App auf Ihrem Computer.

Für Server-Management mit Flow,
Ihr cloudscale.ch-Team

Bei Upgrades kommt uns die Auslegung unserer Systeme auf Hochverfügbarkeit entgegen, wobei sämtliche Komponenten in mindestens zweifacher Ausführung vorhanden sind bzw. mindestens dreifach, wenn ein Quorum erforderlich ist. Dieses Setup schützt uns und unsere Kunden nicht nur vor ungeplanten Downtimes beim Ausfall einzelner Systeme, sondern erlaubt es uns auch, bei Wartungsarbeiten die Systeme sequenziell zu bearbeiten, so dass der produktive Betrieb des Gesamtsystems ohne Unterbruch gewährleistet bleibt.

Die OpenStack-Komponenten, die für die Erstellung und Verwaltung der virtuellen Server zuständig sind, konnten wir so System für System aktualisieren. Und weil von jeder Komponente immer mindestens zwei Instanzen in Betrieb waren, blieb auch die Verwaltung der virtuellen Server via Cloud-Control-Panel und API für unsere Kunden verfügbar. Im Fall der Compute-Nodes, auf denen die virtuellen Server laufen, wäre ein OpenStack-Upgrade sogar im laufenden Produktiv-Betrieb möglich. Gleichzeitig anstehende Upgrades des darunterliegenden Linux-Systems erfordern oft trotzdem einen Reboot. Ihre virtuellen Server bleiben jedoch dank vorgängiger Live-Migration auf einen anderen Compute-Node selbst in einem solchen Fall ohne Unterbrechung online.

Wie OpenStack unterbrechungsfreie Upgrades unterstützt

OpenStack ist ein komplexes System aus verschiedenen Komponenten, die miteinander interagieren. Dass es möglich ist, diese Komponenten (bzw. im Falle eines redundanten Aufbaus nur einzelne Instanzen davon) nacheinander zu aktualisieren, ist dabei nicht ganz selbstverständlich: im Laufe dieses Prozesses befindet sich ja ein Teil des OpenStack Gesamtsystems noch auf dem alten, der andere Teil aber schon auf dem neuen Stand. Das OpenStack-Projekt achtet deshalb bewusst darauf, dass die einzelnen Komponenten auch mit solchen Komponenten zusammen funktionieren, die noch auf der Vorversion laufen. Erst dadurch ist es möglich, das Gesamtsystem während des ganzen Upgrade-Prozesses funktionsfähig zu halten.

Beim kürzlichen Upgrade auf OpenStack "Pike" starteten wir wie immer mit umfassenden Tests in unserer Lab-Umgebung. Dabei optimierten wir unsere Ansible-Playbooks, so dass jederzeit von jeder OpenStack-Komponente immer mindestens zwei Instanzen verfügbar bleiben. Um sicherzugehen, dass das Zusammenspiel der Komponenten auch über Versionsgrenzen hinweg wie erwartet funktioniert, liessen wir geskriptet via API permanent neue virtuelle Server erstellen – ein potenzielles Problem wäre an dieser Stelle schon im Lab aufgefallen.

Was wir tun, um Auswirkungen weiter zu reduzieren

In einigen Fällen liessen sich kurze Unterbrüche (in der Regel unter 5 Minuten) des Cloud-Control-Panels und der API dennoch nicht vermeiden, z.B. wenn die Konfiguration eines Loadbalancers zeitgleich an die neue Version der dahinterliegenden OpenStack-Komponente angeglichen werden musste. Während laufende virtuelle Server davon unbeeinflusst bleiben, sind Änderungen in so einem Moment nicht möglich – insbesondere auch nicht das Verschieben einer Floating IP zu einem anderen virtuellen Server, welches viele unserer Kunden als Failover-Mechanismus für hochverfügbare Setups nutzen.

Wir arbeiten deshalb daran, nötige Downtimes noch enger begrenzen zu können, indem wir z.B. betroffene Operationen sperren, während Control-Panel und API als Ganzes verfügbar bleiben. Beim Upgrade auf "Pike" konnten wir bereits einen solchen Mechanismus nutzen: als durch grössere Änderungen in der OpenStack-eigenen API das Skalieren von Volumes vorübergehend nicht möglich war, konnten wir dies gezielt in unseren Interfaces abbilden und alle anderen Aktionen weiterhin zulassen.

Das Upgrade eines so komplexen Systems wie OpenStack ist eine Sache von mehreren Stunden. Es ist nicht ganz trivial, auch während dieses Prozesses durchgängig die bestmögliche Verfügbarkeit sicherzustellen. Mit redundanten Systemen auf jeder Stufe sind wir hier schon gut gerüstet. Wo dennoch Unterbrechungen zwingend sind, versuchen wir, diese möglichst gering zu halten – im Idealfall muss nur eine einzelne Operation kurzzeitig blockiert werden. Und wie immer gilt: testen, testen und nochmals testen.

Seriös vorbereitet,
Ihr cloudscale.ch-Team

Obwohl wir natürlich ein "Infrastruktur-Unternehmen" sind, schreiben wir auch eigene Software, z.B. für unser Cloud-Control-Panel. So wie viele unserer Kunden verwenden auch wir Git zur Verwaltung des Quellcodes, der den Grundstein für unser einzigartiges Benutzererlebnis legt. Hier kommt nun GitLab CI ins Spiel: GitLab CI erkennt, wenn neue Commits gepusht werden. Bei jedem neuen Commit startet es eine "Pipeline" aus mehreren Test-Jobs.

Im Falle unseres Cloud-Control-Panels haben wir zwei verschiedene Typen von Tests: Unit-Tests und Integration-Tests. Unit-Tests werden isoliert gegen ein kleines Stück Code ausgeführt und erfordern keine Interaktion mit anderen Services. Integration-Tests hingegen testen wirklich die Gesamt-Infrastruktur. So haben wir beispielsweise Tests, die effektiv Server in unserer OpenStack-basierten Cloud starten, oder Buckets im Object Storage erstellen, welcher auf unserem Ceph-Cluster aufbaut. Ein positives Testergebnis ist für uns ein starkes Indiz, dass der geänderte Code weiterhin alle Anwendungsfälle abdeckt, auf welche sich unsere Kunden verlassen.

Wo Continuous Integration bei unserer Qualitätssicherung hilft

Um sicherzugehen, dass alle unsere Dienste nach wie vor funktionieren, führen wir neben der permanenten Überwachung aller Systeme und Einzelkomponenten auch jede Nacht unsere Tests aus. Auf diese Weise können wir potenzielle Probleme in unserer Infrastruktur frühzeitig erkennen und Massnahmen treffen, um den bestmöglichen Service zu gewährleisten.

Darüber hinaus wird unsere Terraform-Implementierung ebenfalls täglich mit einem speziellen Set von Akzeptanztests getestet. Auf diese Weise stellen wir sicher, dass unser Terraform-Provider problemlos mit unserer API interagiert.

Eine gute Testsuite ist das Herzstück jeder guten Software und sollte sich über die Zeit weiterentwickeln und verbessern. Während wir unsere Software ständig optimieren und erweitern, können wir uns darauf verlassen, dass unsere umfangreiche und wachsende Reihe von Tests uns dabei hilft, nichts kaputt zu machen. Automatisiertes Testen ermöglicht es uns nicht nur, Code schneller zu entwickeln, sondern erlaubt auch eine breitere Testabdeckung und damit eine höhere Produktqualität.

Warum wir weitergehen in Richtung Continuous Delivery (CD)

Während uns automatisierte Integration-Tests eine grosse Menge mühsamer, manueller Arbeit abnehmen, besteht weiteres Verbesserungspotenzial: Wir planen auch den Einsatz von Continuous Delivery mit GitLab CI. Continuous Delivery wird es uns ermöglichen, in den Produktions-Branch zu pushen und einfach dabei zuzuschauen, wie der Commit ausgerollt wird.

Wir wissen, dass Sie die neusten Funktionen und Optimierungen so schnell wie möglich nutzen möchten – wer schon nicht? Deshalb bieten wir unseren Entwicklern die nötigen Werkzeuge, um Wiederholung zu vermeiden. Schliesslich sind es nicht die repetitiven Hintergrundaufgaben, welche einen Mehrwert für unsere Nutzer schaffen, sondern die Entwicklung konkreter Lösungen – und, natürlich, deren Lieferung.

Wir testen und liefern,
Ihr cloudscale.ch-Team

Immer mehr Firmen bieten ihren Kunden aktuelle Angaben über den Zustand ihrer Systeme. Allerdings gibt es einen guten Grund, diese Informationen nicht direkt (oder zumindest nicht ausschliesslich) auf der Firmenwebsite, z.B. unter example.com/status oder status.example.com zu platzieren: Solche Informationen werden genau dann benötigt, wenn zentrale Komponenten – und damit potenziell auch die Firmenwebsite – ausgefallen sind.

Bei cloudscale.ch legen wir besonderen Wert darauf, mögliche Ausfälle durch Redundanz auf allen Stufen soweit wie möglich zu verhindern. Wir gehen aber gedanklich auch jene Szenarien durch, in denen dennoch etwas ausfällt, und prüfen sorgfältig, wie sich die Auswirkungen davon bestmöglich begrenzen lassen. Gerade bei Betriebsstörungen möchten wir unbedingt vermeiden, dass Informationen dazu ebenfalls von der Störung betroffen sind – unabhängig davon, wo das konkrete Problem liegt.

Entsprechend betreiben wir unsere Statusseite nicht nur auf separater Hardware, sondern auch in einem anderen Rechenzentrum als unsere Cloud-Infrastruktur, mit separater Internetanbindung. Mit gleicher Konsequenz haben wir auch den Domain-Namen ausgewählt: Wir haben uns für die Adresse https://www.cloudscale-status.net und entsprechende DNS-Server entschieden, um Sie selbst bei einem Ausfall der ".ch"-Nameserver weiterhin informieren zu können.

Welche Tools und Technologien wir einsetzen

Für den Betrieb unserer Statusseite setzen wir auf Cachet. Dieses Tool ist einfach zu benutzen und anzupassen und hat sich bereits bei einigen unserer Partner bewährt. Als Webserver kommt Nginx zum Einsatz und für die TLS-geschützte Datenübertragung ein Zertifikat von "Let's Encrypt".

Nebst dem Anzeigen von aktuellen Wartungsankündigungen und Statusinformationen via Browser unterstützt Cachet natürlich auch die Abfrage der entsprechenden Angaben via RSS- und Atom-Feeds. Wer über neue Meldungen lieber per E-Mail informiert werden möchte, kann diese direkt auf der Statusseite abonnieren. Selbstverständlich erfolgt der Versand dieser E-Mails ebenfalls unabhängig von unserer Cloud-Infrastruktur.

Wie wir die verschiedenen Kommunikationskanäle nutzen

Informationen über den aktuellen Zustand unserer Systeme sowie zu geplanten Wartungsarbeiten finden Sie ab sofort rund um die Uhr auf unserer neuen Statusseite unter https://www.cloudscale-status.net. Selbstverständlich haben wir die Statusseite auch auf unserer Website verlinkt. Dennoch empfehlen wir Ihnen, die Statusseite direkt in Ihre Bookmarks aufzunehmen, um auch während unerwarteten Problemen jederzeit Zugriff auf die aktuellsten Informationen zu haben.

Sollten Wartungsarbeiten eine Aktion Ihrerseits erfordern (z.B. den Neustart eines Servers), senden wir Ihnen die jeweiligen Informationen wie gewohnt direkt an die E-Mailadresse Ihres Benutzerkontos. Bitte achten Sie daher auch in Zukunft darauf, dass diese Adresse korrekt ist, und teilen Sie uns allfällige Änderungen mit.

Alles im grünen Bereich!
Ihr cloudscale.ch-Team

Detaillierte Informationen zu Meltdown (CVE-2017-5754)

Kurz nach Veröffentlichung der Meltdown-Sicherheitslücke waren bereits Patches dafür verfügbar. Wir haben das Linux Kernel-Update, welches die Meltdown-Sicherheitslücke schliesst, am 10.01.2018 auf all unseren Compute Nodes installiert. Um sich vor Angriffen von innerhalb Ihres Servers zu schützen, müssen auch Sie die entsprechenden Sicherheitsupdates Ihrer Linux-Distribution auf Ihren Cloud-Servern installieren.

Detaillierte Informationen zu Spectre (CVE-2017-5715, CVE-2017-5753)

Die Spectre-Sicherheitslücke existiert in zwei verschiedenen Varianten:

Spectre Variante 1 kann mit einem Software-Update vollständig geschlossen werden. Allerdings mussten dafür zuerst alle kritischen Teile im Code identifiziert werden.

Spectre Variante 2 zu schliessen ist aufwändiger: Der ursprünglich vorgeschlagene Ansatz setzte ein CPU Microcode-Update voraus. Da dieses Update zu Instabilitäten der Systeme geführt hat, wurde es später von Intel zurückgezogen. Dank umfangreicher Tests in unserem Lab wurde das fehlerhafte Microcode-Update nie auf unsere Compute Nodes ausgerollt.

Ein alternativer Ansatz zur Behebung von Spectre Variante 2 wurde dann von Google-Ingenieuren und der Linux Kernel-Community entwickelt. Dieser Ansatz verwendet eine Technik namens retpoline (return trampoline) und bietet zwei Hauptvorteile: Es wird kein CPU Microcode-Update benötigt und die daraus resultierenden Leistungseinbussen fallen wesentlich geringer aus.

Am 26.02.2018 haben wir das Linux Kernel-Update installiert, welches mit der retpoline-Technik erstellt wurde. Mit diesem Update wurden alle bekannten Varianten der Spectre-Sicherheitslücke auf all unseren Compute Nodes geschlossen. Wir gehen davon aus, dass zusätzliche Updates notwendig sein werden, falls weitere kritische Teile im Linux Kernel identifiziert werden. Wir werden solche Updates installieren, sobald sie verfügbar sind.

Sicherheitshinweise für unsere Kunden

Bitte beachten Sie, dass Sie die entsprechenden Sicherheitsupdates auch auf Ihren Cloud-Servern installieren müssen, um die beiden Sicherheitslücken zu schliessen. Andernfalls bleiben Ihre Cloud-Server weiterhin anfällig für Angriffe von innerhalb Ihres Servers. Wir empfehlen, das von Stéphane Lesimple veröffentlichte Skript zu verwenden, um zu überprüfen, ob Ihre Server noch verwundbar sind oder nicht.

Die Veröffentlichung von CPU Microcode-Updates werden wir weiterhin verfolgen, allerdings mit einer tieferen Priorität, da für die meisten Linux-Distributionen alternative Ansätze zur Behebung der Variante 2 der Spectre-Schwachstelle zur Verfügung stehen.

Wir empfehlen allen unseren Kunden, wenn immer möglich die von ihrer Linux-Distribution bereitgestellten retpoline-fähigen Kernel zu installieren. Wir werden Sie informieren, wenn weitere Massnahmen erforderlich sind.

Bitte zögern Sie nicht, uns bei Fragen zu kontaktieren.

Freundliche Grüsse
Ihr cloudscale.ch-Team

Bisher getroffene Massnahmen

Um sicherzustellen, dass diese Sicherheitslücken bei cloudscale.ch nicht ausgenützt werden können, haben wir bereits ein Linux Kernel-Update installiert, welches die gravierendste Sicherheitslücke (Meltdown) schliesst. Weitere Sicherheitsupdates werden wir in unserem Lab testen, sobald sie verfügbar sind. Falls dabei keine Probleme auftreten, werden wir die Updates auf unserer Infrastruktur installieren. Wir werden Sie über geplante Wartungsarbeiten laufend informieren und sind bestrebt, die Auswirkungen auf den produktiven Betrieb möglichst gering zu halten.

Bitte beachten Sie, dass Sie die relevanten Sicherheitsupdates auch auf Ihren Cloud-Servern installieren müssen, um diese Sicherheitslücken zu schliessen.

Detaillierte Informationen zu Meltdown (CVE-2017-5754)

Wir haben das Linux Kernel-Update, welches die Meltdown-Sicherheitslücke schliesst, bereits am 10.01.2018 auf all unseren Compute Nodes installiert. Sie müssen die entsprechenden Sicherheitsupdates Ihrer Linux-Distribution auch auf Ihren Cloud-Servern installieren, um sich vor Angriffen von innerhalb Ihres Servers zu schützen.

Detaillierte Informationen zu Spectre (CVE-2017-5715, CVE-2017-5753)

Die Bestrebungen, die Spectre Sicherheitslücke im Linux Kernel zu schliessen, sind derzeit noch im Gange. Im Moment gibt es weder im Linux Kernel upstream noch in der von uns auf unseren Compute Nodes eingesetzten Linux Distribution eine definitive Lösung. Verschiedene Lösungsvorschläge werden zur Zeit in der Linux Kernel-Community diskutiert und wir erwarten in Kürze erste Sicherheitsupdates. Um die Sicherheitslücke auf unseren Compute Nodes zu schliessen, wird zusätzlich zum Kernel eine Aktualisierung des CPU Microcodes notwendig sein. Darüber hinaus braucht es Änderungen an der Virtualisierungsschicht, um den Typ der virtuellen CPUs Ihrer Cloud-Server anzupassen.

Sobald die relevanten Aktualisierungen verfügbar sind, muss auf unseren Compute Nodes ein weiteres Linux Kernel-Update installiert werden. Anschliessend müssen all Ihre Cloud-Server heruntergefahren und neu gestartet werden. Nachdem der Typ der virtuellen CPU aktualisiert wurde, werden wir unsere Kunden erneut informieren. Erst ab diesem Zeitpunkt kann die Spectre-Sicherheitslücke im Kernel Ihrer Cloud-Server geschlossen werden.

Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.

Freundliche Grüsse
Ihr cloudscale.ch-Team

Geht es um performante Router für grosse Netze, fallen schnell einmal die Namen von Branchengrössen wie Brocade, Cisco oder Juniper. Routing und Forwarding geschieht üblicherweise in speziell dafür ausgelegter Hardware in Kombination mit proprietärer Software des jeweiligen Herstellers. Als Cloud-Provider, der Open-Source in seiner DNA verankert hat, wollten wir jedoch das Feld der potenziellen Lösungen etwas weiter stecken.

Die Hauptanforderung an unsere neuen Border-Router war, 6-8 Ports mit einem Durchsatz von mindestens 10 Gbps zu haben – hier stiessen wir an die Grenzen der Möglichkeiten mit unserer bestehenden Lösung, was mit einer der Hauptgründe für einen Ersatz war. Ausserdem benötigten wir mehrere 1-Gbps-Ports für die Anbindung der Management-Infrastruktur und weiterer Netzwerkkomponenten. Redundante Netzteile und die Möglichkeit von Out-of-Band-Management setzten wir natürlich voraus. In Bezug auf die Software waren die üblichen Protokolle in unserem Anforderungskatalog: OSPF und BGP.

Dank der etwas früher gestarteten Evaluation eines neuen Leaf-Spine-Setups sind wir auf Free Range Routing (FRRouting) aufmerksam geworden: Dieses Open-Source-Projekt wird von verschiedenen Herstellern (darunter Cumulus Networks) mit dem Ziel getragen, einen stabilen und skalierbaren Routing Daemon zu entwickeln. Seit Frühjahr 2017 steht FRRouting zudem unter dem Dach der Linux Foundation.

Mit der passenden Hardware könnte FRRouting also auch für unsere Border-Router ein vielversprechender Kandidat sein. In Betracht zogen wir dafür Hardware von Intel (unserem Partner für Compute- und Storage-Nodes) sowie von Lanner, deren x86-basierte Appliances mit einer hohen Dichte an modularen Netzwerk-Ports punkten.

PoC und Migration in zwei Schritten

Nach einem "Proof of Concept" mit FRRouting (zuerst virtualisiert mit Linux KVM und dann physisch auf Lanner-Hardware) waren wir überzeugt: Dieses Setup deckt nicht nur unsere Bedürfnisse an Performance und Zuverlässigkeit ab, sondern integriert sich dank dem Einsatz von Ubuntu auch bestens in unsere übrige Architektur. Ubuntu, das Betriebssystem unserer Wahl für die Infrastruktur bei cloudscale.ch, ist zugleich die Referenz-Testplattform von FRRouting unter Linux.

Ein wichtiger Vorteil des neuen Setups ist, dass wir unsere ganze Netzwerktopologie und damit insbesondere die neuen Border-Router virtualisiert in unserem Lab abbilden können. Dies hat uns bei der Planung der anstehenden Migration geholfen, da wir so in einem ersten Schritt alle Installationsabläufe und die erarbeitete Konfiguration beliebig oft testen konnten, ohne dabei den produktiven Betrieb zu stören.

In einem zweiten Schritt wurden die bestehenden Router im Rahmen eines Wartungsfensters durch die neuen Geräte ersetzt und die Migration damit erfolgreich abgeschlossen.

Vorteile und Möglichkeiten der neuen Architektur

Dank solider Performance, der möglichen Erweiterung um zusätzliche Interface-Module sowie der aktiven Weiterentwicklung von FRRouting durch eine breit abgestützte Community sind unsere neuen Router für die Zukunft gerüstet. Zudem fügen sie sich nahtlos in das erwähnte Leaf-Spine-Setup von Cumulus Networks ein, welches wir im Sommer 2018 in Betrieb nehmen werden. Die identische Software-Basis garantiert nicht nur beste Kompatibilität, sondern auch Effizienz bei der Wartung. Schliesslich erlaubte uns der attraktive Einkaufspreis der neuen Hardware, zusätzlich zum vollständig redundanten Aufbau, die Beschaffung eines komplett bestückten Ersatzgerätes.

Mit der erfolgreichen Migration haben wir gleichzeitig auch die Grundlagen dafür geschaffen, unsere Border-Router noch enger in unser Konfigurations-Management miteinzubinden – künftig werden wir sämtliche Änderungen an der Netzwerk-Konfiguration über dieses zentrale Werkzeug vornehmen. Sobald alle Netzwerk-Komponenten auf FRRouting laufen, sind wir auch bereit für den nächsten Meilenstein: die Umstellung unseres Netzwerks auf BGP unnumbered zur Reduktion der Komplexität und des Verbrauchs an IPv4-Adressen.

Offen und bestens vernetzt.
Ihr cloudscale.ch-Team

PS: Unser CEO, Manuel Schweizer, hat am SwiNOG-Meeting vom 9.11.2017 in Bern eine Präsentation zum Thema FRRouting und BGP unnumbered gehalten.

Terraform ist ein prominenter Vertreter des Begriffs "Infrastructure as Code" und passt bestens in die DevOps-Philosophie heutiger Projekte. Wo Server bisher manuell in Betrieb genommen, nur selten identisch konfiguriert und oft gar nicht dokumentiert wurden, sorgt jetzt der umgekehrte Ansatz für Effizienz und Ordnung: Eine Konfigurations-Datei, die sowohl für Mensch als auch Computer gut lesbar ist, beschreibt die benötigte Infrastruktur – und Terraform erledigt den Rest.

Terraform arbeitet deklarativ: Sie beschreiben den gewünschten Zustand Ihres Setups, und Terraform leitet daraus die nötigen Aktionen ab. Sobald Sie die von Ihnen definierte Konfiguration anwenden, nimmt Terraform über unsere API die entsprechenden Anpassungen vor, bis der beschriebene Zustand erreicht ist. Und weil sich Ihre Infrastruktur – genau wie Code – im Laufe der Zeit ändert, werden Terraform-Konfigurationen am besten in Versionierungssystemen wie z.B. Git verwaltet.

Terraform ist ein Open-Source-Projekt. Die Software ist kostenlos erhältlich.

Wie Sie cloudscale.ch mit Terraform nutzen

Wenn Sie Terraform nutzen und damit auch Ihre Server bei cloudscale.ch verwalten möchten, binden Sie einfach das Plugin für den Provider "cloudscale" ein. Dieses läuft dann als separater Prozess und kommuniziert mit dem Terraform-Hauptprozess über eine RPC-Schnittstelle. Zusätzlich benötigen Sie ein API-Token mit "read/write access", welches Sie einmalig in unserem Cloud-Control-Panel erstellen müssen. Damit authentifiziert sich Terraform gegenüber unserer API bei jeder Änderung an Ihrer Infrastruktur.

Das Starten eines Servers mit Terraform ist denkbar einfach, wie der folgende Abschnitt zeigt:

# Create a new Server
resource "cloudscale_server" "web-worker01" {
  name           = "web-worker01"
  flavor_slug    = "flex-4"
  image_slug     = "debian-9"
  volume_size_gb = 50
  ssh_keys       = ["ssh-ed25519 XXXXXXXXXX...XXXX user@example.com"]
}

Dies ist natürlich nur ein einfaches Beispiel für einen einzelnen Server; alle verfügbaren Optionen für komplexere Setups finden Sie in unserer Terraform Provider-Dokumentation.

Zwei Tipps aus der Praxis

Dinge zu automatisieren spart viel Zeit. Doch was, wenn sich der Automatismus nicht so verhält wie beabsichtigt? Terraform kommt Ihnen hier entgegen: mit dem Kommando terraform plan sehen Sie detailliert, was Terraform auf dem Weg von der aktuellen zur gewünschten Konfiguration alles ändern würde. Bei Bedarf können Sie die Einstellungen in Ruhe nochmals überarbeiten – solange, bis der "Execution Plan" exakt Ihren Erwartungen entspricht. Erst dann nimmt ein terraform apply tatsächlich Änderungen an Ihrer Server-Infrastruktur vor.

Möglicherweise soll nicht jeder, der Zugriff auf Ihr Code- bzw. Konfigurations-Repository hat, auch Zugriff auf Ihre Services bei cloudscale.ch erhalten. Wir empfehlen Ihnen daher, Ihr API-Token innerhalb von Terraform als Variable zu übergeben und die entsprechende Quell-Datei von der Versionierung auszunehmen. Alternativ setzen Sie eine Shell-Umgebungsvariable namens "CLOUDSCALE_TOKEN", welche von Terraform automatisch verwendet wird.

Bei cloudscale.ch konnten Sie Ihre Infrastruktur schon immer nach Ihren Wünschen anpassen. Terraform nimmt Ihnen jetzt einen Schritt ab: Sie definieren Ihre Wunschkonfiguration, Terraform nimmt für Sie die nötigen Anpassungen vor.

Wir haben die Infrastruktur für Ihren Code!
Ihr cloudscale.ch-Team

PS: Terraform ist eine in Go geschriebene Software und setzt für jeden Provider ein entsprechendes Go SDK voraus. Unser Go SDK wurde unter MIT-Lizenz veröffentlicht und ermöglicht es Go-Entwicklern (unabhängig von Terraform), HTTPS-Requests nativ aus einer beliebigen Go Applikation heraus an unsere API zu schicken.

Was ist OpenShift und warum sollte ich es nutzen?

OpenShift selbst wird als "die sicherste und umfassendste Enterprise-Grade Container-Plattform basierend auf den Industrie-Standards Docker und Kubernetes" beschrieben. Es ist aber noch weit mehr! OpenShift ist ein kompletter Kubernetes-Cluster mit vielen Features, die das Produkt abrunden: Integrierte Build-Pipelines, Docker Registry, Applikationsrouter (Load-Balancer), höchste Sicherheit basierend auf SELinux und einem RBAC-System (Role-Based Access Control System), eine webbasierte Konsole für einfachen Zugang zur Plattform, zentrales Logging-System, Metriken jedes einzelnen PoDs, Konfigurationsmanagement mit Ansible, Source-to-Image-Builds und vieles mehr.

Ein Vergleich lässt sich mit dem Linux Kernel anstellen: Wie Linux-Distributionen zusammen mit dem Linux Kernel ein Gesamtpaket schnüren, so bündelt OpenShift Kubernetes zu einer umfänglichen Lösung. Somit ist OpenShift eine Kubernetes-Distribution – eine der ersten überhaupt.

OpenShift gibt es in zwei verschiedenen Varianten:

• OpenShift Container Platform: Die kommerzielle Version von Red Hat zur Installation im eigenen Datacenter oder in der Cloud.
• OpenShift Origin: Das Open-Source-Projekt und gleichzeitig die Upstream-Version der kommerziellen Variante. Das Projekt ist sehr aktiv auf GitHub: https://github.com/openshift/origin

Mit OpenShift erhalten Software-Entwickler die Möglichkeit, in kürzeren Iterationen zu entwickeln und zu testen. Jeder Commit in Git kann den ganzen Prozess von der Entwicklung bis zum produktiven Betrieb automatisiert anstossen. Dafür bietet OpenShift automatische Image-Builds, Speicherverwaltung, Deployment, Skalierung, Monitoring, Logging und vieles mehr. Mit diesem System kann die sogenannte "Time-to-Market" stark verkürzt werden – so sind zum Beispiel stündliche oder noch häufigere Deployments problemlos möglich.

Wie beginne ich mit OpenShift?

Es gibt viele Wege mit OpenShift zu starten. Ein paar Hinweise und Beispiele zum Einstieg:

• Mit den offiziellen Ansible Playbooks kann ein OpenShift-Cluster, z.B. bei cloudscale.ch, installiert und konfiguriert werden. Mit diesen Playbooks sind alle Aspekte bis ins kleinste Detail konfigurierbar. Des Weiteren helfen die Playbooks dabei, den Cluster zu pflegen und auf den neusten Stand zu bringen. Dokumentiert sind diese Playbooks sowohl direkt im Git Repository als auch auf der Dokumentationsseite.

• Ein lokaler OpenShift-Cluster auf der eigenen Workstation kann z.B. mit Minishift (basierend auf Minikube) oder mit dem simplen Kommando "oc cluster up" gestartet werden. Dafür muss nur der OpenShift Client "oc" von GitHub heruntergeladen, ausgepackt und ausführbar gemacht werden. So wird ein kompletter OpenShift-Cluster auf dem lokalen Docker Daemon gestartet:
  

  
  

  % oc cluster up
  Starting OpenShift using openshift/origin:v3.6.0 ...
  Pulling image openshift/origin:v3.6.0
  Pulled 1/4 layers, 28% complete
  Pulled 2/4 layers, 83% complete
  Pulled 3/4 layers, 88% complete
  Pulled 4/4 layers, 100% complete
  Extracting
  Image pull complete
  OpenShift server started.
  
  The server is accessible via web console at:
      https://127.0.0.1:8443
  
  You are logged in as:
      User:     developer
      Password: <any value>
  
  To login as administrator:
      oc login -u system:admin
  
  % oc new-app https://github.com/appuio/example-php-sti-helloworld.git
  [...]
  % oc expose svc example-php-sti-helloworld
  [...]
  % curl -s
  http://example-php-sti-helloworld-myproject.127.0.0.1.nip.io/ | grep title
      <title>APPUiO PHP Demo</title>
  

• Das APPUiO Techlab auf GitHub bietet eine Schritt-für-Schritt Anleitung, welche erklärt, wie Applikationen auf OpenShift betrieben werden können. Wer soziale Interaktion bevorzugt, dem wird durch APPUiO ein kostenloser halbtägiger Hands-On-Workshop angeboten (siehe https://appuio.ch/techlabs.html für weitere Informationen sowie die Anmeldung).

• Eine umfangreiche Dokumentation zum Thema Microservices-Architektur bringt Licht in die Entwicklung und das Betreiben von Cloud-Native Applikationen, welche perfekt auf OpenShift laufen: APPUiO Microservices Example

Die verfügbare Dokumentation zu OpenShift ist bereits sehr umfangreich und wird laufend ausgebaut. Zu finden ist sie unter https://docs.openshift.com für die OpenShift Container Platform und unter https://docs.openshift.org für OpenShift Origin. APPUiO bietet unter http://docs.appuio.ch/ eine eigene spezifische Dokumentation, welche vom APPUiO-Team und der Community auf GitHub gepflegt wird.

Warum soll ich OpenShift auf cloudscale.ch betreiben?

Nach ersten Gehversuchen mit OpenShift auf eigener Hardware vor über zwei Jahren haben wir uns auf die Suche nach einem Schweizer Infrastruktur-Partner für den Betrieb der APPUiO Public Plattform gemacht. Mit cloudscale.ch haben wir den perfekten Partner dafür gefunden. Gemeinsam mit den Engineers von cloudscale.ch konnte eine passend zugeschnitte Umgebung für die Anforderungen von OpenShift geschaffen werden.

Einige wichtige Features, die cloudscale.ch unter anderem bietet, sind: ein privates Netzwerk zwischen virtuellen Servern für die Cluster-Kommunikation, einen S3-kompatiblen Object Storage z.B. für die Docker Registry Daten, Floating IPs für die Hochverfügbarkeit, zusätzliche SSD Disks für eine passende Node Partitionierung, natives IPv6 und vieles mehr.

Heute ist cloudscale.ch für APPUiO ein wichtiger Pfeiler für den stabilen Betrieb der Public Plattform.

Über APPUiO

APPUiO – die Swiss Container Platform – ist ein managed OpenShift Service von Puzzle und VSHN. Wir betreiben OpenShift auf jeder Cloud nach Kundenwunsch – insbesondere auf cloudscale.ch.

Mit über zwei Jahren Erfahrung mit OpenShift v3 sind wir der führende Provider in der Schweiz mit einem umfassenden Wissen zum Betrieb von OpenShift. Wir betreiben nicht nur dutzende private OpenShift-Cluster, sondern auch eine Public Shared Plattform. Die Public Plattform betreiben wir seit Beginn auf der Infrastruktur von cloudscale.ch und haben hier einen zuverlässigen Partner gefunden, der uns bei spezifischen Implementationswünschen stets entgegengekommen ist.

Der Betrieb einer komplexen Plattform wie OpenShift ist nicht einfach – es gibt sehr viele Komponenten in einem grossen Gesamtsystem. Aus diesem Grund haben wir über 120 Cluster-Checks und über 50 Checks pro Server entwickelt, welche den korrekten Betrieb der Plattform überwachen. Darin enthalten sind Checks, welche einen kompletten End-to-End Test (vom Builden des Source Codes bis hin zum Test der Applikation über HTTPS) durchführen, um die komplette Funktionalität eines Clusters überprüfen zu können. Viele unserer Tools und Skripte sind auf GitHub unter der APPUiO Organisation zu finden. Für Fragen sind wir im APPUiO Forum oder im APPUiO Community Chat erreichbar.

Um OpenShift noch heute kostenlos zu testen nehmen Sie bitte Kontakt mit cloudscale.ch oder APPUiO auf.

Voraussetzung zur Nutzung unseres Object Storage ist ein entsprechender Benutzerzugang, den Sie sich in unserem Cloud-Control-Panel mit wenigen Klicks erstellen können. Übertragen Sie den angezeigten "Access Key" und "Secret Key" zusammen mit dem Hostnamen objects.cloudscale.ch in eine S3-kompatible Anwendung Ihrer Wahl wie z.B. einen Dateimanager, ein Backup-Programm oder Ihr CMS – fertig.

Via unsere S3-kompatible API können Sie nun Buckets (Analogie: Verzeichnisse) erstellen und Objects (Analogie: Dateien) hochladen. Je nach Anwendungsfall empfiehlt es sich, unterschiedliche Zugriffsrechte festzulegen: auf Backups und private Daten wenden Sie die "private" ACL an; öffentliche Objekte hingegen, wie z.B. die Bilder Ihrer Website, können Sie als "public" markieren und direkt mittels

src="https://BUCKETNAME.objects.cloudscale.ch/OBJECTNAME"

einbinden und ausliefern.

Update: Die URL wurde mittlerweile angepasst. Mehr dazu unter: S3-kompatibler Object Storage: Neue URLs.

Welche Konzepte beim Strukturieren Ihrer Objects helfen

Selbstverständlich können Sie in unserem Cloud-Control-Panel mehrere Benutzerzugänge für Ihren Object Storage einrichten. Damit lassen sich auf einfache Weise z.B. Test- von Produktiv-Daten trennen oder verschiedene Kundenprojekte separieren. Alle Ihre Objects User sowie deren Buckets werden in unserem Cloud-Control-Panel übersichtlich aufgelistet, jeweils mit Speicherbelegung, Traffic und Requests.

Noch einen Schritt weiter gehen die Access Control Lists (ACLs): Über die S3-kompatible API können Sie einzelne Buckets und Objects für andere Objects User freigeben, wahlweise mit Leserecht oder mit Schreibzugriff – so lassen sich auch komplexere Setups abbilden. Mittels ACLs können Sie beispielsweise sicherstellen, dass auf gewisse Objects nur Scripts, auf andere wiederum nur bestimmte Personen zugreifen dürfen.

Welches Preismodell zur Anwendung kommt

Der Object Storage von cloudscale.ch wird einzig nach effektiver Nutzung abgerechnet und verursacht keine fixen Kosten. Die angefallenen Kosten werden täglich um Mitternacht Ihrem Benutzerkonto belastet – so gibt es keine Überraschungen am Ende des Monats.

Nach der kostenlosen Einführungsphase fliessen ab Anfang September 2017 die folgenden drei Komponenten in die tägliche Preisberechnung ein:

• Belegter Speicherplatz zu CHF 0.003 pro GB
  Der Speicherplatz wird stündlich gemessen und über den Tag gemittelt.
• Ausgehender Traffic zu CHF 0.02 pro GB
  Dies entspricht dem Ansatz für zusätzlichen Traffic bei den virtuellen Servern.
• Requests zu CHF 0.005 pro 1'000 Requests

Eingehender Traffic ist kostenlos.

Update: Der Preis für belegten Speicherplatz wurde mittlerweile um 66% auf CHF 0.001 pro GB gesenkt.

Egal, ob Sie einen sicheren Speicherort für Ihr Off-Site-Backup suchen, Ihre Daten zentral ablegen wollen oder hochverfügbaren Storage für Ihre clusterfähige Applikation benötigen: unser Object Storage bietet genau das – zu fairen Preisen und exklusiv in Schweizer Rechenzentren betrieben.

Für Ihre kleinen und grossen Objekte,
Ihr cloudscale.ch-Team

Einer der Vorteile von IPv6 ist, dass für jeden erdenklichen Anwendungsfall mehr als genug IPv6-Adressen zur Verfügung stehen. Warum also nicht für jeden Dienst, jeden Kunden oder jedes Projekt eine separate IPv6-Adresse verwenden? Mit unseren neuen Floating Networks können Sie Ihren Servern nun einen eigenen "/56" Adressbereich zuweisen. Die neuen IPv6 Floating Networks sind für Sie kostenlos – genauso wie die bereits verfügbaren einzelnen IPv6-Adressen.

Analog zu Floating IPs können auch Floating Networks jederzeit einem anderen Server zugewiesen werden. Egal ob Sie Wartungsarbeiten planen oder ein Hot-Standby-System für alle Fälle bereithalten: Per Mausklick oder API-Call weisen Sie in wenigen Sekunden den gesamten Adressbereich einem anderen Server zu, welcher für den Benutzer transparent alle Requests übernehmen kann.

Zentrale stateful Firewall ohne NAT

NAT (Network Address Translation), häufig verwendet für das Verstecken vieler privater IP-Adressen hinter einer öffentlichen IP, hat insbesondere durch die Knappheit von IPv4-Adressen eine enorme Verbreitung gefunden – trotz einer Reihe von Nachteilen. IPv6 verspricht hier die Rückkehr zur "End-to-End Connectivity": Quell- und Zielsystem können einander wieder direkt und eindeutig adressieren.

Gerade deshalb bleibt eine zentrale Firewall, die eingehende Verbindungen filtert, ein wichtiger Baustein der meisten Sicherheits-Architekturen. Mit cloudscale.ch ist ein solches Setup jetzt problemlos umsetzbar:
Erstellen Sie einen Server mit einem "Public" und einem "Private Network Interface" und weisen Sie ihm in einem zweiten Schritt ein Floating Network zu – dieser Server ist Ihre zentrale Firewall. Der von der Firewall gefilterte Datenverkehr wird später über das Private Network Interface an damit verbundene Server weitergeleitet. Anschliessend konfigurieren Sie auf all diesen Private Network Interfaces einzelne, eindeutige IPv6-Adressen aus dem Floating Network. Damit sind Ihre Server über diese IPv6-Adressen erreichbar, während Sie den Datenverkehr einfach und zentral auf Ihrer Firewall kontrollieren können.

Folgende Skizze veranschaulicht das Setup:

                             +-------------+
                             |  Internet   |
                             +------+------+
                                    |
                             +------+------+
                             |  Server 1   |
                             |  "Firewall" |
                             +------+------+
                                    |
       +-----------------+----------+------+---------------------+
       |                 |                 |                     |
+------+------+   +------+------+   +------+------+       +------+------+
|  Server 2   |   |  Server 3   |   |  Server 4   |  ...  |  Server N   |
+-------------+   +-------------+   +-------------+       +-------------+

Migration Ihrer IP-Adressen zu cloudscale.ch

Viele Firmen verwenden bereits ihre eigenen IP-Adressen, welche ihnen in Form von "Provider Independent Space" (PI Space) oder in ihrer Rolle als "Local Internet Registry" (LIR) zugewiesen wurden. Dank Floating Networks ist es nun zudem möglich, solche IP-Adressen (sowohl IPv4 wie auch IPv6) zu cloudscale.ch umzuziehen. Behalten Sie Ihre etablierten IP-Adressen, aber sparen Sie sich den Aufwand einer eigenen physischen Infrastruktur und nutzen Sie stattdessen die Flexibilität unserer Schweizer Cloud. Kontaktieren Sie uns unverbindlich, um mehr über die Möglichkeiten eines solchen Setups zu erfahren.

Schöpfen Sie mit unseren neuen Floating Networks noch heute das ganze Potential von IPv6 aus und profitieren Sie dabei von der gleichen Flexibilität, die wir bereits mit Floating IPs eingeführt haben. Mit unseren neuen Floating Networks passen Sie das Netzwerk Ihren individuellen Wünschen an – wahlweise nutzen Sie dabei sogar Ihre eigenen, bestehenden IP-Adressen.

Bereit für Ihren "Next Hop",
Ihr cloudscale.ch-Team

Bei cloudscale.ch spielt Hochverfügbarkeit bereits in der Design-Phase neuer Features eine zentrale Rolle, und das ist bei unserem Object Storage nicht anders. So werden Requests an den Object Storage mittels "DNS Round-Robin" auf zwei Load-Balancer verteilt. Diese wiederum können bei Ausfällen oder Wartungsarbeiten die jeweils andere IP – und damit die ganze Last – übernehmen. Das gilt selbstverständlich nicht nur für IPv4: Immer mehr Systeme weltweit nutzen IPv6 und können darüber nativ auf unseren Object Storage zugreifen.

Hinter den beiden Load-Balancern arbeiten redundant ausgelegte RADOS Gateways, welche die Daten auf einem Ceph Storage-Cluster speichern. Wie bei unserem SSD-only- und Massenspeicher setzen wir auch beim Object Storage auf einen Replikations-Faktor von 3, um einen maximalen Schutz Ihrer Daten zu gewährleisten.

Maximale Geschwindigkeit für typische Anwendungsfälle

Neben höchster Verfügbarkeit haben wir natürlich auch die Leistung unseres Object Storage optimiert. Dazu gehört der sogenannte Cache Tier: Häufig benutzte Objekte werden automatisch in einem speziellen Cache gehalten und können so blitzschnell abgerufen werden. Davon profitieren beispielsweise Ihre Kunden, wenn Sie die statischen Dateien auf Ihrer Webseite oder Bilder in einem Newsletter direkt von unserem Object Storage ausliefern.

Mit grosser Sorgfalt wählen wir auch unsere Hardware aus: Für unseren Object Storage haben wir uns für eine Kombination aus Festplatten für optimale Speicherdichte und NVMe SSDs für maximale Geschwindigkeit entschieden. Zusammen mit einem ausgeklügelten Setup von Ceph erreichten wir damit auch für selten benutzte Objekte eine zusätzliche Steigerung der Geschwindigkeit.

Kostenlose Einführungsphase

Anlässlich der offiziellen Einführung unseres Object Storage möchten wir allen Benutzern die Gelegenheit geben, dieses neue Feature bis Ende August 2017 kostenlos zu testen. Evaluieren Sie verschiedene Tools und entdecken Sie neue Einsatzbereiche, um herauszufinden, wie Sie Ihren Anwendungsfall mit unserem Object Storage optimieren können.

Ab September 2017 kommt ein moderater Preisplan für den Object Storage zur Anwendung, bei dem der tatsächlich belegte Speicherplatz, der Datenverkehr und die Anzahl Requests verrechnet werden. Über den genauen Abrechnungsmodus werden wir Sie natürlich rechtzeitig informieren.

Bestimmt verwenden auch Sie bereits Applikationen, die von einem Object Storage profitieren können. Nutzen Sie die Gelegenheit und testen Sie kostenlos, welches Potenzial sich Ihnen damit erschliesst!

Für Buckets voller Objekte,
Ihr cloudscale.ch-Team

Ansible ist eine Plattform für die Orchestrierung und das Konfigurationsmanagement von Applikationen, Servern (insbesondere Unix/Linux) und ganzer Serverumgebungen. Neben zahlreichen anderen Modulen ermöglicht Ansible mit den Cloud Modules die Anbindung an verschiedene Cloud-Anbieter – seit der Version 2.3.0 ist damit auch die Verwaltung von Servern bei cloudscale.ch möglich.

Das Erstellen eines neuen Servers wird so zum Kinderspiel:

- name: Start cloudscale.ch server
  cloudscale_server:
    name: my-shiny-cloudscale-server
    flavor: flex-4
    image: debian-8
    ssh_keys: ssh-rsa XXXXXXXXXX...XXXX ansible@cloudscale.ch

Apache Libcloud

Apache Libcloud ist eine Python-Bibliothek, welche die APIs verschiedener IaaS-Provider abstrahiert. Libcloud erlaubt es, über eine einheitliche Python-Syntax auf die Ressourcen diverser Cloud-Anbieter zuzugreifen. Seit der Version 1.5.0 enthält Libcloud auch einen Treiber für die cloudscale.ch API, um damit direkt aus Ihrem Code heraus Server auf unserer Infrastruktur zu verwalten.

Mit Python und Libcloud erstellen Sie neue Server mit nur ein paar Zeilen Code:

from libcloud.compute.types import Provider
from libcloud.compute.providers import get_driver

cls = get_driver('cloudscale')
driver = cls(key='XXXXX')

name = 'my-shiny-cloudscale-server'
size = [ s for s in driver.list_sizes() if s.id == 'flex-4' ][0]
image = [ i for i in driver.list_images() if i.id == 'debian-8' ][0]
ssh_keys = [ open('id_rsa.pub').read().strip() ]

node = driver.create_node(name=name,
                          size=size,
                          image=image,
                          ex_create_attr={'ssh_keys':ssh_keys})

Zwei Tools, unterschiedliche Einsatzgebiete

Ansible und seine sogenannten Playbooks dienen dazu, eine Abfolge von Tasks zum Systemmanagement zu definieren und auszuführen. Ansible hat damit klar definierte Einsatzbereiche: Orchestrierung von IT-Abläufen, Deployment von Applikationen oder Verwaltung der Systemkonfiguration.

Mit Ansible und dem Cloud Module ist es beispielsweise möglich, den gesamten Vorgang zum Aufbau und Betrieb hochverfügbarer Webservices bei cloudscale.ch zu automatisieren – vom Erstellen der virtuellen Server über das Deployment der Applikationen bis hin zur unterbrechungsfreien Wartung bei System- oder Applikationsupdates.

Im Gegensatz dazu ist Libcloud eine Python-Bibliothek. Mit Python als universeller Programmiersprache lassen sich unterschiedlichste Applikationen implementieren. Libcloud kommt also überall dort zum Zug, wo aus Python-Code heraus auf Cloud-Angebote zugegriffen werden soll. Alle darin integrierten Cloud-Provider werden automatisch unterstützt, ohne dass der Entwickler eigens Code für deren spezifische Anbindung schreiben muss.

Libcloud eignet sich also überall dort, wo Sie bereits Python einsetzen, z.B. direkt integriert in Ihre (Web-)Applikation für mehr Skalierbarkeit, oder zur Erweiterung bestehender Deployment- und Monitoring-Tools.

Was bringt die Zukunft

Wir arbeiten permanent an neuen Features für unsere Cloud-Infrastruktur und unsere API. Um diese auch laufend in Libcloud und Ansible zu integrieren arbeiten wir mit den jeweiligen Open-Source-Communities zusammen. So ist zum Beispiel für das kürzlich eingeführte "Floating IP" Feature eine Integration in Ansible geplant.

Ein häufig genannter Vorteil von Cloud-Servern ist, dass sie mit wenigen Mausklicks bereitgestellt werden können. Gehen Sie einen Schritt weiter: Automatisieren Sie Ihr Server-Deployment mit Ansible oder Libcloud – ganz ohne Mausklick.

Server-Setup leicht gemacht!
Ihr cloudscale.ch-Team

PS: Wir denken, dass eine Integration der cloudscale.ch API in Terraform ebenfalls sinnvoll wäre. Was halten Sie davon?

Früher oder später ist es soweit: ein Prozess stürzt ab, ein Limit wird erreicht oder Wartungsarbeiten stehen an. Viele Systemadministratoren betreiben daher den gleichen Dienst auf mehreren Servern und ändern bei Bedarf die DNS-Einträge, um Benutzer-Anfragen vom einen auf den anderen Server zu verschieben. Auch bei kurzer TTL bedeutet das jedoch häufig Zusatzaufwand oder gar Service-Unterbrüche – und eine weitere Quelle für Fehler und Folgeprobleme.

Unsere neuen Floating IPs können Sie beliebig zwischen Ihren virtuellen Servern verschieben; ein neuer Server kann für den Benutzer transparent alle Requests übernehmen, während Sie den bisher aktiven Server in Ruhe auf den neusten Stand bringen, neu starten, skalieren oder allfällige Probleme beheben.

Am Beispiel von keepalived lässt sich zeigen, wie einfach Hochverfügbarkeit erreicht werden kann: zwei Server prüfen in regelmässigen Abständen den Zustand des jeweiligen Gegenübers. Bei einem Problem des aktiven Servers übernimmt der Standby-Server automatisch, indem er sich mittels unserer API die Floating IP zuweist. Selbstverständlich können Sie Floating IPs mit unserem Control-Panel auch manuell einem anderen Server zuweisen.

Update: Falls Sie Ihre Server mit Ubuntu 18.04 oder 20.04 betreiben, beachten Sie bitte auch das überarbeitete Beispiel von keepalived.

Um höchstmögliche Verfügbarkeit zu gewährleisten, kombinieren Sie Floating IPs am besten mit unserer Anti-Affinity-Funktion. Damit ist sichergestellt, dass zwei Server, die sich gegenseitig vertreten können, stets auf separaten physischen Maschinen laufen. Auch wenn wir bereits auf den verschiedensten Ebenen für Redundanz gesorgt haben, können Sie so das Restrisiko eines Hardware-Ausfalls noch weiter reduzieren.

Welche weiteren Vorteile Floating IPs bieten

Auch wenn Sie nicht planen, IP-Adressen dynamisch zwischen Servern zu verschieben, können Sie von den neuen Floating IPs profitieren: sie bieten Ihnen zum Beispiel die Möglichkeit, bei Bedarf weitere IP-Adressen zu Ihren Servern hinzuzufügen. Mit jeweils bis zu fünf zusätzlichen IPv4- und IPv6-Adressen können Sie Services oder Kunden voneinander trennen, ohne dafür separate Server erstellen und unterhalten zu müssen.

Update: Das Limit wurde mittlerweile von fünf auf insgesamt fünfzehn Floating IPs oder Floating Networks pro Server erhöht.

Da Floating IPs nicht fix an einen virtuellen Server gebunden sind, bleiben diese beim Löschen des Servers in Ihrem Benutzerkonto erhalten. Damit lässt sich unter anderem vermeiden, dass Ihre "Service IP" beim Ersetzen von Servern verloren geht – vorausgesetzt natürlich, dass Ihre Kunden ausschliesslich mit dieser Floating IP kommunizieren.

Was im Hintergrund geschieht

Aus technischer Sicht ist jede Floating IP ein eigener, kleiner IP-Bereich – daher auch die Netzmaske "/128" oder "/32" bzw. "255.255.255.255". Wenn Sie eine Floating IP erstellen oder sie einem neuen Server zuweisen, erhalten unsere Router eine entsprechende Anweisung: An die Floating IP gerichteter Datenverkehr soll umgehend ebendiesem Server geschickt werden. Diese Konfiguration erfolgt über ein separates, redundantes Setup aus zwei ExaBGP-Speakern, die über redundante BGP-Sessions mit unseren Routern kommunizieren.

Detailliertere Hintergrundinformationen zu diesem besonderen Ansatz haben André Keller von der VSHN AG und unser CEO Manuel Schweizer am SwiNOG Meeting in Bern präsentiert; die Slides dazu finden Sie unter http://www.swinog.ch/meetings/swinog30/. Für unser Cloud-Control-Panel haben wir die technischen Details natürlich wie gewohnt hinter einer selbsterklärenden Benutzeroberfläche versteckt, und für die Nutzung via API finden Sie alle Informationen in der API-Dokumentation unter https://www.cloudscale.ch/en/api/v1.

Stets im Fluss,
Ihr cloudscale.ch-Team

Ceph bildet die Basis unseres verteilten Storage-Clusters. Die Open-Source Lösung sorgt dafür, dass Ihre Daten mehrfach redundant gespeichert werden und damit stets verfügbar sind. Lese- und Schreiboperationen werden dabei auf eine Vielzahl von Storage-Nodes verteilt, was die Geschwindigkeit merklich erhöht. Die physische Separierung von Compute- und Storage-Nodes ermöglicht hochverfügbare Setups und erlaubt es, den Speicherplatz praktisch beliebig zu skalieren.

Um einen reibungslosen Betrieb zu gewährleisten, setzen wir bei Ceph auf sogenannte "LTS"-Versionen ("Long Term Stable"-Versionen). Der Einsatz einer breit abgestützten Version erhöht die Zuverlässigkeit und verkürzt im Falle eines Fehlers die Reaktionszeit. Nach ausführlichen Tests in unserem Lab haben wir den Storage-Cluster von "Hammer" auf den neusten LTS-Release "Jewel" aktualisiert. Beeindruckend ist dabei nicht zuletzt die höhere Performance: Im Vergleich zu Hammer wurde bei Jewel eine Leistungssteigerung von bis zu 35% gemessen.

Neuinstallation der Storage-Nodes mit Ubuntu 16.04 LTS

Auf den meisten unserer Server kommt Ubuntu zum Einsatz, und auch hier setzen wir auf Versionen mit langfristiger Unterstützung. Während die produktiven Systeme zuverlässig mit Version 14.04 LTS liefen, haben wir in unserem Lab das neuere Ubuntu 16.04 LTS sowie den Umstellungsprozess eingehend getestet. In den letzten Tagen haben wir sämtliche Storage-Nodes mit 16.04 neu installiert und profitieren so weiterhin von aktueller Software und langfristigem Support.

Erweiterung mit superschnellen NVMe SSDs

Ceph speichert sämtliche Daten zuerst im sogenannten Journal. In einem zweiten Schritt werden die Daten in den eigentlichen Speicher übertragen. Oftmals werden für das Journal SSDs eingesetzt, um die Schreibvorgänge zu beschleunigen, während die Daten anschliessend auf magnetischen Harddisks abgelegt werden.

Bei cloudscale.ch hingegen verwenden wir ausschliesslich SSDs (Ausnahme: Bulk-Storage), damit auch lesende Zugriffe blitzschnell erfolgen können. Um unser Setup weiter zu optimieren, haben wir unsere Storage-Nodes mit NVMe SSDs erweitert. Diese dienen als superschnelles Journal und beschleunigen Schreibzugriffe gegenüber den bisherigen SSDs nochmals deutlich. Mit der neuen Konfiguration entfällt auch die "double-write penalty": Daten werden dank separatem NVMe Journal nur noch einmal auf die SSDs geschrieben, was den Datendurchsatz annähernd verdoppelt.

Dank sorgfältiger Planung konnten wir alle Anpassungen im laufenden Betrieb umsetzen – vermutlich haben Sie davon gar nichts bemerkt. Selbstverständlich profitieren alle Kunden automatisch von der höheren Leistung, d.h. ein Ändern oder Ersetzen bisheriger Server ist nicht nötig.

Blitzschnell unterwegs,
Ihr cloudscale.ch-Team

Object Storage (oder auch object-based Storage) ist ein moderner Ansatz zum Speichern und Abrufen von Daten, welcher immer häufiger von aktuellen Applikationen genutzt wird. Ein typischer Anwendungsfall ist die Sicherung von Backups: So können Backups zum Beispiel mit Duplicity (wahlweise verschlüsselt) erstellt und ausserhalb des jeweiligen Systems abgelegt werden. Dadurch bleiben diese unabhängig vom ursprünglichen System verfügbar.

Da der Object Storage über HTTP/HTTPS-Aufrufe angesprochen wird, ergibt sich daraus ein weiterer Einsatzzweck fast automatisch: Als "public" markierte Dateien (z.B. Bilder oder Videos) lassen sich über eine fixe URL direkt adressieren und können so beispielsweise in Websites oder HTML-Newsletter eingebunden werden, ohne dabei den Webserver zu belasten.

Falls Sie auf Ihren Servern bereits Docker einsetzen, wird Ihr Deployment nun noch einfacher: Ganze Docker-Images können mittels Docker Registry direkt auf unserem neuen Object Storage abgelegt werden.

Unterstützte Tools

Die im Object Storage gespeicherten "Objects" sind häufig Dateien, gruppiert in "Buckets". Diese wiederum können als vereinfachte Version von Verzeichnissen verstanden werden. Entsprechend simpel gestaltet sich die Nutzung via Shell oder Scripts: Das Open-Source-Tool s3cmd zum Beispiel folgt bei der Verwaltung von Objekten vertrauten Konzepten wie jenen von SCP oder FTP.

Neben dem bereits erwähnten Duplicity können immer mehr moderne Applikationen direkt mit Object Storage umgehen, so zum Beispiel Apache Hadoop oder verschiedene Content Management Systeme wie Drupal und Wordpress.

Teilnahme an der geschlossenen Beta-Phase

Bevor wir dieses neue Feature für jedermann zugänglich machen, möchten wir eine beschränkte Anzahl an Benutzern einladen, unseren Object Storage ausführlich zu testen. Selbstverständlich fliesst das Feedback laufend in die weitere Entwicklung mit ein.

Möchten auch Sie zu den Ersten gehören, die unseren Object Storage testen? Wir sind auf Ihre Erfahrungsberichte gespannt und schalten gerne Ihren cloudscale.ch-Account für den Beta-Test frei – ein kurzes E-Mail genügt.

Immer ein offenes Ohr,
Ihr cloudscale.ch-Team

Über unser Vorgehen bezüglich OpenStack-Upgrades haben wir bereits früher berichtet: Wir betreiben eine separate Testumgebung mit den gleichen Hardware-Komponenten, die auch im produktiven Betrieb zum Einsatz kommen. Dort testen wir geplante Änderungen so lange, bis wir überzeugt sind, dass diese gefahrlos in die Produktivumgebung übernommen werden können.

Vor einigen Wochen stand wieder ein Upgrade von OpenStack an: "Mitaka" durfte "Liberty" ablösen. Eine heikle Angelegenheit, wenn man sich vor Augen führt, dass OpenStack die Grundlage unserer Cloud-Infrastruktur bildet. Dank umfassenden vorgängigen Tests konnten wir alle Systeme reibungslos aktualisieren und dies, ohne die virtuellen Server unserer Kunden zu beeinträchtigen. Einzig Änderungen in unserem Cloud-Control-Panel waren kurzzeitig nicht möglich – die entsprechende Ankündigung an unsere Kunden erfolgte natürlich bereits im Rahmen der Vorbereitungsarbeiten.

Schnellere Live-Migration

Nebst grösseren Upgrades gehören auch regelmässige Wartungsarbeiten und Optimierungen an den Systemen zu unseren täglichen Aufgaben. Davon merken unsere Kunden in der Regel nichts: Wir können sämtliche virtuellen Server im laufenden Betrieb auf andere Compute Hosts verschieben und damit Unterbrüche für Kundensysteme gänzlich vermeiden. Diesen Prozess konnten wir kürzlich sogar um den Faktor 5 beschleunigen, indem wir von "libvirt tunnelled migration" auf "QEMU direct migration" umgestellt haben. Dadurch können Wartungsarbeiten wie zum Beispiel Kernel-Upgrades, welche einen Neustart sämtlicher Compute Hosts erfordern, nun noch schneller abgeschlossen werden.

OpenStack Summit in Barcelona

Für uns als aktives Mitglied der OpenStack-Community war der OpenStack Summit Ende Oktober 2016 in Barcelona natürlich mehr als nur ein Pflichttermin. In einem inspirierenden Umfeld aus tausenden Entwicklern und Anwendern aus aller Welt drehte sich alles um OpenStack und sein umfassendes Ökosystem. Eine breite Palette an Präsentationen vermittelte Einblicke in alle möglichen Aspekte: Vom Management riesiger Setups über die Pflege des OpenStack-eigenen, offenen Quellcodes bis hin zum Ausblick auf weitere Leistungsoptimierungen von Ceph war alles dabei. Ceph bildet bereits seit 2014 das Rückgrat unseres verteilten Storage-Clusters und wird inzwischen immer häufiger zusammen mit OpenStack eingesetzt.

Ebenso wertvoll war natürlich der persönliche Austausch mit neuen und bekannten Gesichtern, sei es bei zahlreichen Sessions mit Core-Entwicklern oder bei spontanen Diskussionen zwischen den offiziellen Programmpunkten. Und soviel Statistik sei erlaubt: Dank unseren regelmässigen Upgrades auf neue OpenStack-Versionen gehören wir zu den modernsten OpenStack Cloud Service Providern weltweit.

Unsere eigenen bisherigen Erfahrungen wie auch die Community mit ihrer Kombination aus Drive und Professionalität bestärken uns in unserer Meinung: OpenStack als technologische Basis für unsere Self-Service-Cloud war die richtige Wahl.

Mit dieser Überzeugung tragen wir deshalb auch in Zukunft zur Weiterentwicklung des OpenStack Quellcodes bei und arbeiten natürlich bereits an den nächsten Funktionen für unsere eigene Cloud.

Zuvorderst mit dabei,
Ihr cloudscale.ch-Team

Um unsere API nutzen zu können, benötigen Sie lediglich ein API-Token: Eine geheime Zeichenfolge, die Sie in all Ihren API-Aufrufen mitschicken müssen.

In den Account-Settings unseres Cloud-Control-Panels können Sie beliebig viele API-Tokens erstellen. Um ausschliesslich Informationen auszulesen ist "read access" eine sichere Wahl. Wenn Sie über die API auch Änderungen vornehmen möchten (z.B. Server erstellen oder neu starten), aktivieren Sie zusätzlich "write access".

Wählen Sie einen aussagekräftigen Namen, um Ihre Tokens voneinander unterscheiden zu können. Sollten Sie später ein Token widerrufen wollen, lässt es sich darüber einfach identifizieren. Da wir Ihre Tokens nur als Hash in unserer Datenbank ablegen, können diese später nicht erneut angezeigt werden.

So benutzen Sie unsere API

Unsere API ist als HTTPS API nach dem REST-Paradigma konzipiert und deshalb mit grosser Wahrscheinlichkeit auch mit Ihren bevorzugten Tools kompatibel. Ein einfaches Beispiel: Mit folgendem Befehl können Sie sich direkt von Ihrer lokalen Kommandozeile aus eine Liste Ihrer aktuellen Server anzeigen lassen:

curl -H 'Authorization: Bearer IhrCloudscaleApiToken' https://api.cloudscale.ch/v1/servers

Benötigte Parameter können Sie in JSON- oder URL-codierter Form übergeben. Die von der API ausgegebenen Informationen sind als JSON formatiert, um sie einfach auswerten und weiterverarbeiten zu können. Die Dokumentation aller verfügbaren Funktionen finden Sie unter https://www.cloudscale.ch/en/api, inklusive jeweiliger HTTP-Methode, Parameter und eines Beispiels.

Einige Anwendungsfälle und Hinweise

Die möglichen Anwendungsfälle für unsere API sind endlos: Wenn Ihre Mitarbeiter immer wieder dieselben, standardisierten Infrastrukturen aufsetzen müssen, können Sie sie nun mit einem Script unterstützen und dabei unsere API sowie die cloud-config Funktion nutzen. Vielleicht möchten Sie auch Informationsabfragen automatisieren – für Ihre Projektmitarbeiter, zur Dokumentation oder für ein Live-Dashboard.

Beachten Sie, dass alle API-Aufrufe ohne Rückfrage ausgeführt werden, um sie auch in automatisierter Form zuverlässig benutzen zu können. Da Ihre API-Tokens mit einem Passwort vergleichbar sind, sollten Sie vorsichtig sein, wo Sie sie abspeichern (z.B. offene Repositories) und wer darauf Zugriff hat (z.B. Script-Pfade oder Kommando-Historie). Sollte es dennoch nötig sein, können Sie Tokens jederzeit widerrufen.

Neu erhalten Sie beim Löschen eines Servers eine Pro-Rata-Gutschrift für die verbleibende Dauer unserer 24-stündigen Abrechnungsperiode. Testen Sie unbesorgt verschiedene Setups und Funktionen und ersetzen Sie ältere Server kostenneutral durch eine frische Installation. Wenn Sie für periodische Lastspitzen jeweils kurzfristig mehr Server in Betrieb nehmen, profitieren Sie von dieser Neuerung selbstverständlich gleichermassen.

Wir entwickeln unser Cloud-Control-Panel ständig weiter, damit die Nutzung für unsere Mitmenschen möglichst einfach ist. Umso mehr freut es uns, dass cloudscale.ch jetzt sogar von Computern einfach benutzt werden kann.

Viel Spass beim Automatisieren!
Ihr cloudscale.ch-Team

PS: Falls Sie wie wir auf Python setzen: Wir arbeiten daran, in eine der nächsten Versionen von Libcloud aufgenommen zu werden, um so den Zugriff auf unsere API weiter zu vereinfachen. Weitere Infos folgen.

Dass bei einem Ausfall eines physischen Compute Hosts alle darauf laufenden Server abstürzen, ist mit den gängigsten Virtualisierungstechnologien nicht zu verhindern. Gut möglich, dass Sie deshalb bereits auf "N+1 Redundanz" setzen, indem Sie mehrere virtuelle Server im Verbund betreiben (z.B. mehrere Web Worker oder einen DB Cluster), um damit die Verfügbarkeit Ihrer Lösung zu erhöhen. Nichtsdestotrotz besteht die Möglichkeit, dass einige dieser Server per Zufall auf dem gleichen physischen Host landen.

Mit unserer neuen Anti-Affinity Funktion können Sie sicherstellen, dass Server mit identischen Aufgaben immer auf separaten physischen Maschinen laufen. Damit schützen Sie sich zuverlässig vor den Folgen eines Hardwaredefekts eines einzelnen Compute Hosts.

Mit welchen Massnahmen wir die Verfügbarkeit maximieren

Dennoch ist der Ausfall eines Servers natürlich stets ein Ärgernis. Bei cloudscale.ch setzen wir deshalb nur auf Systeme, die dafür ausgelegt sind, immer zu laufen und ständig erreichbar zu sein:

Alle unsere Systeme sind mit redundanten Hot-Swap-Netzteilen ausgestattet. Alle physischen Server sind mit mehreren Switches gleichzeitig verbunden und können out-of-band über ein separates Management-Netzwerk verwaltet werden.

Im Falle eines defekten Compute Hosts starten alle betroffenen virtuellen Server umgehend auf separaten, betriebsbereiten Compute Hosts neu. Dank unserem verteilten Storage-Cluster auf Basis von Ceph bleibt dabei der Inhalt der Festplatte erhalten. Mit einem Replikationsfaktor von 3 sind Ihre Daten zudem gut geschützt vor einem Hardwaredefekt – ein Risiko, welches durch den konsequenten Einsatz von Enterprise SSDs weiter reduziert wird.

Auch die Versorgungs-Ebene ist mit Blick auf höchste Verfügbarkeit redundant ausgelegt: Einerseits indem wir uns im Datacenter auf redundante Kühlsysteme verlassen können sowie auf zwei Strom-Zuführungen, die beide mit USV und Diesel-Generatoren abgesichert sind. Andererseits verfügen wir über mehrere Internet-Anbindungen mit verschiedenen Upstream-Providern und einer Verbindung am SwissIX Internet Exchange.
Schliesslich betreiben wir auch selber kritische Software (z.B. OpenStack-Komponenten) nach dem Prinzip N+1, um einen allfälligen Ausfall nahtlos zu überbrücken.

Warum Hochverfügbarkeit mehr ist als nur ein zuverlässiger Server

Für uns bedeutet Verfügbarkeit, dass Ihre virtuellen Server laufen und erreichbar sind. Überlegen Sie sich, was Verfügbarkeit für Sie bedeutet - und nicht zuletzt für Ihre Kunden. Was könnte schief gehen und wie können negative Auswirkungen verhindert oder zumindest minimiert werden? Wählen Sie den Ansatz und die Mittel, welche Ihnen und Ihrem Anwendungsfall am besten entsprechen. Schlussendlich geht es darum, für den Ernstfall gewappnet zu sein.

Für Server, die laufen!
Ihr cloudscale.ch-Team

PS: Passend zum Thema wird André Keller von der VSHN AG gemeinsam mit unserem CEO Manuel Schweizer eine Präsentation zur Frage "How to increase availability using ExaBGP?" halten. Die Anmeldung und weitere Informationen zum Anlass vom 4. November 2016 in Bern finden Sie unter: http://www.swinog.ch/meetings/swinog30/

Verwenden Sie komplizierte Passwörter? Und beim Eintippen schaut Ihnen auch sicher niemand über die Schulter? Die Zwei-Faktor-Authentifizierung (2FA) geht punkto Sicherheit noch einen Schritt weiter: Zum Einloggen wird ein zusätzliches Token benötigt (auch "One-Time Password" bzw. OTP genannt), welches alle 30 Sekunden ändert und nur für kurze Zeit gültig ist.

Schützen Sie Ihr cloudscale.ch-Konto jetzt mit 2FA, indem Sie diese neue Funktion in den Security-Einstellungen aktivieren. Mit dem populären "Google Authenticator" oder einer beliebigen anderen TOTP-App verwandeln Sie Ihr Smartphone in einen Schlüssel, der Ihre Cloud zusätzlich schützt. Token werden übrigens komplett offline erzeugt.

Session-Verwaltung

Wenn Sie in unserem Cloud-Control-Panel eingeloggt sind und Ihren Browser schliessen, wird Ihr Session-Cookie im Normalfall automatisch gelöscht. Beim nächsten Mal müssen Sie sich dann erneut einloggen. Neu können Sie sich dafür entscheiden angemeldet zu bleiben, indem Sie beim Login "stay signed in" anwählen. Selbstverständlich können Sie auch mit mehreren Geräten gleichzeitig angemeldet sein.

Was, wenn Sie vergessen haben, sich auf einem fremden Computer auszuloggen? Die neue Session-Übersicht zeigt Ihnen alle Geräte an, die derzeit angemeldet sind, inklusive IP-Adresse und verwendetem Browser. Sie können hier beliebige Sessions sofort beenden und damit sicherstellen, dass sich niemand an Ihrem Konto zu schaffen macht.

Verifizieren von Host-Keys

SSH Host-Keys sind sozusagen der Personalausweis eines Servers: Damit können Sie sicherstellen, dass Sie sich mit der korrekten Maschine verbinden und kein Man-in-the-Middle Ihren Datenverkehr manipuliert. Wenn sich ein Server mit einem anderen Host-Key ausweist als dem in Ihrer known_hosts-Datei hinterlegten, werden Sie umgehend gewarnt und sollten der Sache vermutlich auf den Grund gehen.

Viele Leute vertrauen zwangsläufig dem Host-Key-Fingerprint, der bei der ersten Verbindung angezeigt wird. Jetzt können Sie diesen bei neuen Servern auch tatsächlich überprüfen: Virtuelle Server erzeugen ihre eindeutigen Host-Keys während dem ersten Bootvorgang und schreiben den öffentlichen Teil davon auf ihre serielle Konsole. Dort holen wir sie ab und zeigen deren Fingerprints in unserem Cloud-Control-Panel an. Überzeugen Sie sich selbst!

Vertrauen ist gut, Kontrolle ist besser. Mit den neusten Sicherheitsfunktionen machen wir es Ihnen nun noch einfacher, die Kontrolle zu behalten. Schliesslich ist für uns Cloud-Computing das, was für andere Online-Banking ist.

Signiert, nicht gehashed.
Ihr cloudscale.ch-Team

Wann Massenspeicher am besten genutzt wird

Es muss nicht "Big Data" sein: Massenspeicher ist ideal, um archivierte Versionen Ihrer Arbeit oder eine externe Datensicherung Ihrer lokalen Festplatte aufzubewahren. Nutzen Sie kostenlose Software wie "Seafile" oder "ownCloud", damit die Daten auf all Ihren Geräten synchronisiert bleiben – der neue Massenspeicher bietet einen kostengünstigen Ort, um Ihre Dateien in der Cloud aufzubewahren.

Sie können ausserdem profitieren, wenn Sie Massenspeicher zu einer traditionellen Server-Umgebung hinzufügen: Nutzen Sie ihn, um die statischen Inhalte Ihrer Website wie Bilder und Videos zu speichern, für Ihre Datenbank-Backups und die ständig wachsenden Logdateien. Es ist zudem der einfachste Weg, um bestimmte Dateien getrennt von Ihrem Root-Dateisystem aufzubewahren.

Wie er in der Praxis verwendet wird

In unserem Cloud-Control-Panel können Sie Massenspeicher jederzeit zu Ihren virtuellen Servern hinzufügen. Wenn Sie einen neuen Server starten, dann wird das zusätzliche Volume automatisch mit ext4 formatiert und unter /mnt/bulk gemountet, damit Sie dessen Platz sofort nutzen können.

Zu Ihren vorhandenen Servern können Sie Massenspeicher im Tab "Storage" hinzufügen. Wir bieten für sämtliche der von uns unterstützten Betriebssysteme Anleitungen, wie Sie das zusätzliche Volume manuell partitionieren und mounten. Und ähnlich wie beim SSD-only-Speicher können Sie bei zusätzlichem Platzbedarf den Massenspeicher jederzeit vergrössern.

Die Technologie unter der Haube

Während wir klassische Festplatten verwenden, um die Kosten für Massenspeicher möglichst tief zu halten, haben wir einige Anstrengungen unternommen, um den besten Platz für Ihre grossen Datenmengen anzubieten. Zur Sicherstellung einer hohen Verfügbarkeit nutzen wir Ceph mit einem Replikationsfaktor von 3, was mit der Konfiguration unseres SSD-only-Storage-Clusters identisch ist. Für eine optimale Leistung wird der Massenspeicher auf dedizierten Storage-Servern gehalten, getrennt von den bestehenden Systemen. Darüber hinaus ist es uns durch die Verwendung von SSDs für die Ceph-Journals gelungen, die Schreibvorgänge drastisch zu beschleunigen.

Selbstverständlich werden sämtliche Ihrer Daten auf unserem Massenspeicher-Cluster ausschliesslich in Schweizer Rechenzentren verwahrt – dies gilt für alle unsere Systeme.

Viele wertvolle Daten erfordern keine topaktuellen IOPS-Werte. Nutzen Sie unser neues Massenspeicher-Angebot, um diese Dateien kostengünstig an einem sicheren Ort zu speichern und verfügbar zu haben, wann immer Sie sie benötigen.

Verschieben Sie Ihr Archiv in die Cloud!
Ihr cloudscale.ch-Team

Wenn das Einrichten neuer Cloud-Server eine wiederkehrende Aufgabe ist, warum automatisiert man sie dann nicht? Bei sämtlichen Betriebssystemen, die wir zurzeit anbieten, ist das Software-Paket "cloud-init" bereits integriert. Durch die Angabe sogenannter "User Data" können Sie nun Ihre eigenen Einstellungen an cloud-init übergeben: Ihre massgeschneiderte cloud-config. Die Möglichkeiten sind grenzenlos – wir haben von Kunden gehört, die sich nicht einmal mehr per SSH auf ihre neuen Server einloggen müssen.

Sie können es selber ausprobieren, indem Sie zum Beispiel die Parameter "timezone" oder "fqdn" (Fully Qualified Domain Name) verwenden, um Ihren neuen Server direkt beim Erstellen zu konfigurieren. Für komplexere Operationen empfiehlt sich die Nutzung des Parameters "runcmd", welcher Ihre Befehle entgegennimmt und sie beim ersten Start ausführt. Dies ist eine Funktion für versierte Benutzer: Bitte lesen Sie die Beispiele durch und verfahren Sie vorsichtig.

Benennen Sie Ihre Server um, wenn sich deren Zweck ändert

Während Sie Ihre Konfiguration optimieren, können sich die Anzahl der Maschinen oder gar die verwendete Software ändern: Wenn Sie erkennen, dass Ihre DB-Replikation hauptsächlich zur Erstellung von Berichten genutzt wird, werden Sie die Maschine vermutlich mit den Linux-eigenen Tools umbenennen. Für eine einheitliche Erscheinung können Sie nun auch in unserem Cloud-Control-Panel die Servernamen anpassen.

Wenn Sie an mehreren Projekten gleichzeitig oder für verschiedene Kunden arbeiten, dann können beschreibende Servernamen Sie dabei unterstützen, den Überblick über Ihren Server-Bestand zu behalten. Darüber hinaus helfen sie Ihnen, spätere Verwechslungen zu vermeiden.

Ändern Sie die PTR-Einträge für ein stimmiges Erscheinungsbild

Sie können nun unser Cloud-Control-Panel nutzen, um die PTR-Einträge der IP-Adressen Ihres Servers festzulegen und anzupassen. Sollten Sie den FQDN des Servers (wie oben beschrieben) mittels cloud-config festlegen, werden wir automatisch die PTR-Einträge Ihrer IP-Adressen entsprechend setzen. Natürlich können Sie diese Einträge jederzeit ändern, sollte dies jemals erforderlich sein. Beachten Sie, dass cachende DNS-Server Änderungen mit etwas Verzögerung übernehmen könnten.

Bei einigen Anwendungen, insbesondere E-Mail, ist es wichtig, übereinstimmende "forward"- und "reverse"-DNS-Einträge (sog. "Forward-confirmed reverse DNS") zu haben: Wenn Sie für eine bestimmte IP-Adresse einen neuen PTR-Eintrag erstellen, achten Sie darauf, dass Sie über einen entsprechenden A/AAAA-Eintrag verfügen, der wiederum auf die gleiche IP zeigt. Darüber hinaus sollten sich Ihre Dienste mit ebendieser Zeichenfolge identifizieren.

Wer sagt, dass kleine Verbesserungen nicht grosse Auswirkungen haben können? Dank den neuesten Erweiterungen können Sie Ihre Cloud mit einem Lächeln im Gesicht verwalten.

Optimieren Sie weiter!
Ihr cloudscale.ch-Team

Ein bekannter Anwendungsfall für private Netzwerke sind mehrstufige Architekturen, sog. "tiered architectures": Erstellen Sie eine Reihe von Frontend-Servern (z.B. Web Worker), mit denen Ihre Benutzer über das Internet direkt kommunizieren. Diese Server verbinden sich dann über ein zweites, privates Netzwerk-Interface mit ihren Backend-Servern (z.B. DB- oder Applikationsserver), die nicht öffentlich zugänglich sind. Dieses Design minimiert die Anzahl exponierter Dienste und erhöht so die Sicherheit Ihres gesamten Setups.

Über gewöhnliche Webdienste hinaus weitergedacht: Sie können unsere Cloud nun für praktisch jede Anwendung nutzen, die Sie bisher vor Ort betrieben haben. Ob es sich um E-Mails handelt, Datenspeicher, Ihr Wiki oder um Ihre virtuelle Telefonanlage: Verwenden Sie einfach unsere Funktion "private network". Mit einer VM, die als Gateway, zentrale Firewall und/oder VPN-Endpunkt fungiert, haben Sie die volle Kontrolle darüber, wer Zugriff auf Ihre (privaten) Maschinen hat.

Wie private Netzwerke eingerichtet werden

Private Netzwerke funktionieren bei cloudscale.ch "out of the box": Jeder Server Ihres privaten Netzwerks erhält per DHCP eine IP-Adresse; diese Adresse wird auch in unserem Cloud-Control-Panel angezeigt. Natürlich können Sie jede IPv4- und/oder IPv6-Adresse Ihrer Wahl statisch konfigurieren - schliesslich ist es Ihr eigenes Netzwerk.

Im Falle eines bereits laufenden Servers, der noch kein privates Netzwerk-Interface hat, können Sie jederzeit eines hinzufügen. Config-Snippets helfen Ihnen, das zusätzliche Interface im von Ihnen gewählten Betriebssystem einzurichten.

Ein Blick hinter die Kulissen

Wir weisen Ihnen ein eigenes VXLAN zu, um Ihren privaten Netzwerkverkehr zwischen unseren Compute-Nodes zu tunneln und ihn damit vollständig vom Verkehr anderer Kunden getrennt zu halten. Mit diesem Setup stellen wir auch sicher, dass Datenpakete innerhalb Ihres privaten Netzwerks unseren Backbone nie verlassen.

Wir wählen für Sie ein zufälliges /24-Subnetz aus dem privaten Adressbereich 172.16.0.0/12 aus. Dadurch versuchen wir Verwechslungen mit anderen privaten Adressen, welche Sie womöglich an anderen Orten verwenden, zu vermeiden. Falls Sie möchten, dass die DHCP-Server Ihren Maschinen Adressen aus einem anderen Subnetz zuweisen, nehmen Sie bitte mit unserem Support-Team Kontakt auf.

Unsere Self-Service-Cloud-Plattform bietet nun, dank der Unterstützung von mehrstufigen Architekturen, eine solide Basis für eine noch breitere Palette von Anwendungen. Nutzen Sie das private Netzwerk, um Ihre wertvollen Daten zu schützen und exponieren Sie nur jene Dienste, die Sie tatsächlich von aussen zugänglich machen wollen.

Happy (private) networking!
Ihr cloudscale.ch-Team

Warum Sie IPv6 jetzt nutzen sollten

Eine wachsende Anzahl von Internet-Nutzern und Geräten verwendet bereits IPv6, manche sogar ganz ohne eine "alte" IPv4-Adresse zu haben. Sobald Sie IPv6 auf einem Server aktivieren, können diese Nutzer effizienter auf Ihre Dienste zugreifen: weniger DNS-Anfragen, kein NAT mehr, und keine Engpässe durch Tunneldienste, welche für die Verbindung beider Welten nötig waren. Wussten Sie, dass verschiedene Content-Provider bei der Nutzung von IPv6 von Verbesserungen der Anwendungsleistung um bis zu 25 % berichten?

Seien wir ehrlich: IPv6 gehört die Zukunft.

Wie Sie IPv6 auf Ihren virtuellen Servern aktivieren können

IPv6 kann sowohl für bestehende als auch neue virtuelle Maschinen aktiviert werden: Wenn Sie eine neue VM erstellen, klicken Sie einfach auf "Enable IPv6" und vergessen Sie nicht, Ihren DNS-Zonen eintsprechende AAAA-Records hinzuzufügen – das war's! Für bestehende VMs klicken Sie in unserem Cloud-Control-Panel im Tab "Network" auf "Enable IPv6". Sie finden dort ausserdem Anweisungen, um DHCPv6 im Betriebssystem Ihres virtuellen Servers zum Laufen zu bringen.

Standardmässig weisen wir jeder VM eine einzelne IPv6-Adresse zu. Sie benötigen mehr? Unser Support-Team routet auf Anfrage gerne bis zu einem /48 auf die IPv6-Adresse Ihrer VM.

Ein kurzer Hinweis zum Thema Sicherheit

Wenn Sie IPv6 auf Ihren Servern aktivieren, möchten Sie vermutlich entsprechende Firewall-Regeln hinzufügen. Bitte denken Sie daran, den DHCPv6-Verkehr zu erlauben, wenn Sie bei unserer Standardmethode zur Zuweisung von IPv6-Adressen bleiben wollen.

Die Schweiz gehört zu den führenden Ländern, wenn es um die Einführung von IPv6 geht. Mit cloudscale.ch gehören Sie auch dazu.

Happy networking!
Ihr cloudscale.ch-Team

PS: Unser Geschäftsführer, Manuel Schweizer, hat letzte Woche auf der IPv6 Business Conference in Zürich einen Vortrag gehalten. Sie können die Folien sämtlicher Vorträge unter www.ipv6conference.ch/sessions/ ansehen und herunterladen.

Zugriff auf Sicherheitsupdates zu haben, ist von entscheidender Bedeutung – was für Ihre eigenen Geräte gilt, trifft für Anbieter von Cloud-Diensten in noch höherem Masse zu. Während sich der Support von OpenStack Kilo dem Ende zuneigte, erwogen wir die Aktualisierung auf eine neue Version noch aus einem weiteren Grund: neue und verbesserte Möglichkeiten in OpenStack Liberty ermöglichen es uns, Ihnen noch zügiger als zuvor neue Funktionen zur Verfügung zu stellen.

Wir sind uns bewusst, dass vor Kurzem das noch neuere OpenStack "Mitaka" veröffentlicht worden ist. Warum also haben wir uns trotzdem für Liberty entschieden? Uns ist es wirklich wichtig, Ihnen eine stabile Cloud-Infrastruktur zu bieten. Deshalb wollten wir zuerst weitere Erfahrungen in unserem Lab sammeln, ehe wir Mitaka die Orchestrierung Ihrer Server anvertrauen.

Wie wir uns auf das Upgrade vorbereitet haben

Das Vorgehen in der Theorie zu kennen ist eine Sache, das Verfahren auch getestet zu haben eine andere. Aus diesem Grund haben wir eine Lab-Umgebung geschaffen, in welcher Hardware-Komponenten zum Einsatz kommen, die mit unserer produktiven Cloud-Infrastruktur identisch sind. Dies ermöglichte es uns, die dann aktuelle Konfiguration zu replizieren und den gesamten Upgrade-Prozess mehrfach zu durchlaufen, um potenzielle Probleme zu lösen und Tücken zu beseitigen.

Als Vorbereitung für künftige Funktionen unseres Cloud-Control-Panels haben wir diese Gelegenheit ausserdem genutzt, um unsere OpenStack-Einstellungen anzupassen und zu erweitern. Wir werden diese Funktionen in separaten Beiträgen behandeln.

Was dies für die Zukunft bedeutet

OpenStack Liberty ist ein grosser Schritt nach vorn. Angesichts der Tatsache, dass es bewährt ist und noch für eine längere Zeit unterstützt wird, bietet es Kontinuität und Zuverlässigkeit. Aber noch wichtiger ist, dass es sich dabei um die Grundlage für die zukünftige Entwicklung unserer Cloud-Infrastruktur handelt und eine Vielzahl an weiteren Funktionen ermöglicht, die wir über die nächsten Wochen und Monate veröffentlichen werden.

Mit einer dedizierten und unabhängigen Lab-Umgebung können wir unsere Tests nun noch effizienter durchführen. Sei es eine neue Funktion, eine optimierte Konfiguration oder das nächste grosse Upgrade – wir verfügen nun über die Möglichkeit, so viele Testläufe zu machen wie wir wollen, bevor wir dann tatsächlich ein produktives System anfassen.

Nach diesem Upgrade verfügen wir über eine noch bessere technologische Basis, auf der wir aufbauen können. Und obendrein haben wir ein weiteres, leistungsfähiges Werkzeug dazugewonnen, um die Qualitätsstandards, denen wir uns verpflichtet fühlen, erfüllen zu können.

Auf die Plätze, testen, los!
Ihr cloudscale.ch-Team

Bei der Verwirklichung eines neuen Produktes dreht sich alles um Prioritäten. In unserem Fall: Die verfügbare Technologie nutzen und sie in ein Self-Service-Cloud-Angebot umwandeln, das leistungsfähig, aber zugleich einfach zu benutzen ist. Mit einem kleinen Team und einer klaren Vision im Hinblick auf das Endergebnis konzentrierten wir uns darauf, unser Versprechen so schnell wie möglich einzulösen.

Während unsere wichtigsten Bausteine, OpenStack und Ceph, schnell bestimmt waren, mussten wir bei der Entwicklung unseres einzigartigen Cloud-Control-Panels einen pragmatischen Ansatz verfolgen. Die Nutzung des im Team vorhandenen Wissens war dabei entscheidend, und so kam es, dass der im Januar veröffentlichte Software-Release in Lua geschrieben war.

Warum wir uns für einen Wechsel entschieden haben

Nach der Eröffnung – einer der wichtigsten Meilensteine in der Geschichte eines Start-ups – war es nun an der Zeit für eine Standortbestimmung. Uns wurde schnell klar, dass wir all die Vorteile von OpenStack und seinem wachsenden Ökosystem nur dann optimal nutzen können, wenn wir selbst auf Python wechseln.

Weil immer mehr Software-Entwickler an unserem Cloud-Control-Panel arbeiteten, haben wir uns entschieden, neue Prozesse einzuführen: Test-driven Development hilft uns, schnell voranzukommen und eine hohe Qualität gewährleisten zu können. Continuous Delivery mit mehreren Deployments pro Tag ermöglicht es, dass Sie laufend die Vorteile von Verbesserungen und neuen Funktionen nutzen können. Mit Python und seinen bestehenden Frameworks konnten wir die Möglichkeiten agiler Software-Entwicklung voll ausschöpfen.

Welche Vorteile Sie erwarten können

Mit unseren verbesserten Prozessen gelang es uns, die gesamte Code-Basis zu ersetzen, ohne dass es unsere Kunden überhaupt bemerkten – ein nahtloser Rollout. Durch Nutzung der neu gewonnenen Synergien kommen wir mit neuen Funktionen noch schneller voran. In etwa einem Monat werden wir für all Ihre virtuellen Maschinen volle IPv6-Unterstützung anbieten können, und private Netzwerke lassen auch nicht mehr lange auf sich warten. Weitere spannende Funktionen sind für diesen Sommer geplant.

Im Rückblick war die Re-Implementierung unserer Code-Basis in diesem Stadium die richtige Entscheidung. Nach der Veröffentlichung unseres Produktes und den vielen positiven Rückmeldungen von unseren Kunden sind wir nun bereit für die nächste Stufe.

Halten Sie sich bereit für (viel) mehr!
Ihr cloudscale.ch-Team

Mit unserer kürzlich veröffentlichten Self-Service-Plattform und einer wachsenden Kundenbasis schien plötzlich alles dringend zu sein: Kunden-Support, zusätzliche Funktionen, die Wartung und Erweiterung unserer technischen Infrastruktur – und zahlreiche Aufgaben im Hintergrund, die Sie vermutlich kaum erahnen würden.

Es schien sinnvoll, hauptsächlich nach System-Ingenieuren mit Programmierkenntnissen zu suchen, in der Hoffnung, diese können jeweils dort die Lücken füllen, wo gerade die dringendsten Probleme auftreten. Kenntnisse in Python waren eine harte Anforderung (da wir OpenStack nutzen), genauso wie Offenheit für Ungewohntes, da unser Cloud-Control-Panel in Lua implementiert ist.

Wie wir es geschafft haben, die richtigen Leute zu finden

Angesichts unserer aktuellen Lage hatten wir einfach nicht die Zeit und Mittel, Stellenanzeigen aufzugeben und Hunderte von Bewerbungen durchzugehen. Eine Eintrag in HNs "Who is hiring?" ergab einige interessante Kontakte, führte aber letztlich auch nicht zu erfolgreichen Anstellungen.

Es war eine altbewährte, klassische Methode, die uns zu unseren neuen Teammitgliedern geführt hat: man kennt jemanden, der wiederum jemanden kennt. Wir hatten das Glück, zwei Software-Ingenieure zu finden, die über einen beachtlichen Leistungsausweis in Python sowie hervorragende Linux-Kenntnisse verfügen. Darüber hinaus leisten beide auf ihrem Fachgebiet wesentliche Beiträge und sind stark in die Open-Source-Community eingebunden.

Warum es sich gelohnt hat, in die Offensive zu gehen

Unabhängig von der Vergrösserung unseres Teams suchten wir den Kontakt mit anderen OpenStack-Nutzern (schliesslich gehören wir nach wie vor zu "den Neuen"). Es stellte sich heraus, dass einer dieser Spezialisten sehr daran interessiert war, sich unserem Team anzuschliessen. Mit seinen Kenntnissen in OpenStack und Linux-Systemtechnik war er die ideale Ergänzung des wachsenden cloudscale.ch-Teams.

Wir möchten die neuen Gesichter hinter cloudscale.ch willkommen heissen! Und auf unserem derzeitigen Weg des Wachstums freuen wir uns jetzt schon darauf, weitere grossartige Menschen wie sie kennenzulernen.

Herzlich,
das (wachsende) cloudscale.ch-Team

Die kostenlose, sofortige Registrierung steht nun für jedermann zur Verfügung. Nach mehr als einem Jahr harter Arbeit (und wir sind längst noch nicht am Ziel), die der Erstellung einer einfachen Self-Service-Cloud-Plattform galt, können wir mit Stolz verkünden: Hier ist sie! Willkommen bei https://www.cloudscale.ch

Wie wir uns darauf vorbereitet haben

Wir haben vor Kurzem zusätzliche Hardware zu unserem Cloud-Setup hinzugefügt, um sicherzustellen, dass Sie stets die Kapazität und Leistung erhalten, die Sie benötigen. Zudem haben wir intern verschiedene Dinge optimiert, um eine wachsende Kundenbasis bewältigen zu können, sowohl in technologischer Hinsicht als auch als Unternehmen. Und wir sind dabei das Team zu vergrössern, um unser Tempo halten zu können.

Was sich für Sie verändert hat

Wir haben unsere Preispläne angepasst, damit diese noch besser zu Ihrer Projektgrösse und Ihrem Budget passen, indem wir die Preise gesenkt und das "Flex-1"-Angebot mit dem attraktiveren "Flex-2" ersetzt haben. Skalieren Sie einfach und ohne Aufpreis Ihre vorhandenen Flex-1-Server auf Flex-2.

Warum dies erst der Anfang ist

Wir freuen uns darauf, eine Vielzahl neuer Anhänger aus der ganzen Welt begrüssen zu dürfen, und sind gespannt zu erfahren, was Sie durch die Nutzung unserer Plattform erreicht haben – wir freuen uns über alle Rückmeldungen!
Eine voll funktionsfähige Cloud-Infrastruktur zu haben ist erst der Anfang. Wir arbeiten bereits an weiteren Funktionen wie zum Beispiel Backups und Snapshots sowie an der IPv6-Unterstützung.

Womöglich möchten auch Ihre Freunde uns einmal testen! Oder haben diese jemals einen Server innerhalb von 10 Sekunden erstellt? Wenn Sie unseren Link an Ihre Freunde weitergeben, können sich diese umgehend registrieren und profitieren erst noch von kostenlosen Credits, um ihren ersten Server bei cloudscale.ch zu starten. Vielen Dank für Ihre Unterstützung!

Freundliche Grüsse aus Zürich,
Ihr cloudscale.ch-Team