Hintergrund: Neue Linux-Container ab 2.5.

[Daniel Baumann]

Hallo zusammen

Im Nachgang zu unserer News-Meldung dass wir wieder Anfragen fuer
Linux-Container ab 2.5. entgegen nehmen koennen, gab es ein paar Rueckfragen
ueber das wie und warum, die wir gerne beantworten moechten.


1. Standardisierte, automatisierte Container-Erstellung
=======================================================

Obwohl wir nachwievor was Engineering angeht voellig ausgelastet
sind mit Netzwerk und Linux-Infrastruktur Arbeiten, koennen wir wieder
neue Linux Container erstellen.

Bzgl. "neu" unterschieden wir dabei grundsaetzlich zwischen:

  A) *neue* Linux Anforderungen umsetzen: d.h. Linux-Engineering fuer
     Dinge, die wir bisher noch nie gemacht haben oder groessere
     Anpassungen an bestehender Infrastruktur benoetigen.

  B) *bestehendes* Linux-Angebote: d.h. neue
     Container-Instanzen von in unserem "Standard-Katalog"
     enthaltenen, vordefinierten Linux-Containern die wir
     vollstaendig automatisiert generieren,
     siehe https://bfh.science/services/compute/

Fuer A) gilt:

  * koennen wir fruehestens nach Abbarbeitung des Backlogs
    und nach Einfuehrung von OpenStack (d.h. fruehestens beginnend
    ab Mitte/Ende 2023), weil vorher keine Linux-Engineering-Ressourcen
    frei sind.

  * sind eine Frage des Demandmanagements und koennen jederzeit via
    Ticket eingereicht werden.

Fuer B) gilt:

  * koennen wir jederzeit machen (= "Betriebs-Task"), *sofern*
    wir genuegend freie Hardware-Ressourcen haben. Diese haben wir seit
    September 2021 nicht mehr (weil "alte" Science DMZ voll und Cage-A
    noch nicht fertig), siehe
https://lists.bfh.science/pipermail/bfh-linux-announce/2021-October/000146.html


2. Neue Hardware-Ressourcen in neuem Rechenzentrumsteil (Cage-A)
================================================================

Da Cage-A jetzt bereit ist, koennen wir fuer B) wieder Standard-Anfragen
fuer Standard-Container entgegennehmen, diese machen uns dank
Automatisierung wenig/kein Aufwand und koennen wir problemlos neben den
bestehenden Arbeiten erledigen.

Wir haben in den letzten Wochen die fertige, neue Netzwerk-Infrastruktur
in Cage-A durchgeprueft und einige Dienste laufen bereits produktiv
darauf.

Bevor wir die Konfiguration der neuen Netzwerk-Komponenten im "alten"
Rechenzentrumsteil (Cage-B) mit allen Server und Diensten der Teams MSC
und DML noch abschliessen koennen, muessen wir produktive Dienste in den
Cage-A verschieben, dies aus folgenden Gruenden:

  * wir brauchen mehr Bandbreiten-Nutzung der Server-Systemen um das
    Load-Verhalten der Netzwerk-Systeme beobachen zu koennen.

  * wir brauchen mehr Nutzer auf den Server-Systemen um das Connection-
    Verhalten der Netzwerk-Systeme beobachten zu koennen.

  * wir wollen die ueberall implementierte Redundanz kontrolliert und
    unsere neuen Basis-Infrastrukturdienste abschliessend verifizieren,
    an Hand von echten Workload/Failover mit echten Systemen.

Alles das ist eine Vorbedingung fuer den naechsten grossen Meilenstein -
das Zusammenfassen der beiden Cages. Letzteres ist wiederum die
Vorbedingung, um danach dann Standorte mit neuem Netz erschliessen resp.
lifecyclen zu koennen.


3. Science DMZ und Ceph Migration
=================================

Nun da Cage-A bereit ist, muessen wir zeitnah die "alte" Science DMZ
zurueckbauen durch Migration aller Container in Cage-A, die "neue"
Science DMZ. Im Unterschied zu vorher sind die Systeme in Cage-A aus dem
internen Netz direkt erreichbar.

Die zuvor beschafften zusaetzlichen Server fuer den Kapazitaetsausbau
der Science DMZ haben wir letztes Wochenende aufgesetzt, so dass wir
Container um Container von alt nach neu verschieben koennen. Danach
werden die "alten" Server in den Cage-A verschoben, neu aufgesetzt und
stehen in der neuen Science DMZ zur Verfuegung.

Die gleiche Prozedur werden wir auch fuer Ceph machen:

  * im Herbst (vorher geht aus Engineering-Ressourcen Gruenden nicht)
    werden wir die Haelfte der Ceph Hardware die sich bereits in Cage-A
    befindet als neuen Ceph Cluster aufsetzen. Danach koennen wir
    wiederum alle Daten nacheinander von alt nach neu verschieben.

  * sobald alle Daten verschoben sind, verschieben wir den Rest der
   "alte" Ceph Hardware in Cage-A, setzen diese neu auf und fuegen sie
    zum neuen Ceph Cluster hinzu.

Damit dies funktioniert, darf auf dem bestehenden Ceph Cluster nur max.
<50% belegt sein, sonst koennen wir nicht im Parallel-Betrieb
verschieben und es braeuchte ein paar Wochen Ceph-Downtime um den neuen
Cluster machen zu koennen.

Weil wir nicht mehr als 50% belegen duerfen, koennen wir seit September
2021 keine Anfragen im groesseren Terrabyte-Umfang mehr erfuellen.
Sobald der Ceph Cluster im Herbst wieder die gesamte Hardware zur
Verfuegung hat, werden wir wieder grosse Storage-Anfragen erfuellen koennen.

Gruesse,
Daniel

-- 
Berner Fachhochschule / Bern University of Applied Sciences
Services / IT-Services
Daniel Baumann
Teamleiter Linux & Infrastructure Services
___________________________________________________________
Dammweg 3, CH-3013 Bern
Telefon direkt +41 31 848 48 22
Telefon Servicedesk +41 31 848 48 48
daniel.baumann at bfh.ch
https://bfh.ch
https://bfh.science