OpenShift-on-Wavestack

Kosten

• Infrastruktur (siehe Wavestack Standardproduktkatalog)
  • min. 3 master nodes - min. SCS-4V-16-100s
  • min. 2 worker nodes - min. SCS-4V-16-100, siehe Storage weiter unten
  • 1 Jumphost - min. SCS-1V-4-50
  • S3 Bucket für Imageregistry für noris und Kundenimages, belegter Platz wird abgerechnet FIXME: Standardgröße ermitteln
  • Reservierter Platz in Dateisystemen FIXME: Klären ob reserviert oder benutzt und Standardgröße ermitteln
  • Optional: min 3 infra nodes - min. SCS-8V-16-100
  • Optional: falls aus dem Internet erreichbar - 3 öffentliche IPs
  • Optional: VPN und Proxy

• Lizenzen
  • 1 Openshift Lizenz pro Cluster
  • 1 Openshift Lizenz pro 4 Worker CPU Kerne

• Netzwerktraffic
  • Installation und Updates von Openshift
  • Download von Containerimages von externen Registries für noris und Kundenanwendungen
  • Kundentraffic

• noris Arbeitsleistung

Cluster Autoscaling

Es ist möglich und von noris empfohlen, den Cluster dynamisch bei hoher Auslastung mit zusätzlichen, temporären Workernodes hochskalieren zu lassen.

Zu Anfang könnte das Limit dafür auf zwei zusätzliche Workernodes vereinbart werden. Die benötigte Infrastruktur würde wie gewohnt dynamisch abgerechnet. Die Lizenzen wären in diesem Fall etwas teurere, stündliche Lizenzen. Bei dauerhaftem Mehrbedarf empfehlen wir insofern, eine dauerhafte Vergrößerung mit länger laufenden Lizenzen zu vereinbaren.

Storage

In Wavestack werden S3 Objektspeicher und Cinder RWO (Read-Write-Once) Dateisysteme angeboten.

noris empfiehlt die Benutzung von S3 Objektspeicher in Containern für alle unterstützten Anwendungen.

RWX (Read-Write-Many) Dateisysteme werden nicht angeboten. Wir empfehlen, Anwendungen mit diesem Usecase auf S3 umzustellen.

Cinder ist in jedem Brandabschnitt (z.b. MUC-A, B und D) jeweils getrennt als Cluster vorhanden, wird nicht in andere Brandabschnitte kopiert oder gebackuped.

S3 ist über die jeweiligen Brandabschnitte der Geolokation (z.b. MUC) synchronisiert und gebackuped (FIXME: Wavecon Dokumentation verlinken und Bild einfügen um das zu visualisieren)

Master nodes halten ihr lokales Dateisystem auf lokalen NVME-SSDs ("ephemereal") des Hypervisors. Damit sind diese deutlich schneller, aber dafür flüchtig, das heißt sie können bei einem Update/Defekt des Hypervisors verloren gehen. OpenShift/etcd kümmert sich in diesem Fall um den Rebuild seiner Daten, es hat allerdings einen Redundanzverlust zur Folge.

Workernodes können alternativ auch ihr Dateisystem in den Netzwerkspeicher Ceph in der jeweiligen Abilityzone ("Brandabschnitt") legen. Damit sind diese Daten nach Reboot/Umzug wieder einbindbar, aber genauso bei Ausfall der jeweiligen Availabilityzone nicht mehr erreichbar. Dieser Storage ist langsamer, dafür günstiger.