GWDG Cloud Server

Der „GWDG Cloud Server“ ist ein Dienst ähnlich zu bekannten kommerziellen Cloud-Server-Diensten, wobei die GWDG besonderen Wert auf die Bedürfnisse aus der Wissenschaft legt. Über die durch die GWDG entwickelte, webbasierte Oberfläche können Nutzer des Dienstes „GWDG Cloud Server“ eigenständig Server erstellen und verwalten. Hierfür stehen mehrere weit verbreitete Linux-Distributionen in einer Basis-Installation zur direkten Nutzung zur Verfügung. Beim Erstellen kann aus verschiedenen Größen in Hinblick auf verfügbare Prozessoren und Speicher gewählt werden. Die GWDG setzt zur Realisierung des Dienstes „GWDG Cloud Server“ durchgängig auf Open-Source-Produkte wie OpenStack, KVM und Linux.

Der Zugriff auf die graphische Oberfläche der Server erfolgt direkt aus dem Webbrowser des Nutzers. Hierüber können die Server konfiguriert und weitere Dienste installiert und verwaltet werden. Um eine Erreichbarkeit der Server über das Internet zu ermöglichen, stehen öffentliche IP-Adressen bereit, welche den Servern flexibel zugewiesen werden können. Sicherheitseinstellungen ermöglichen es dem Nutzer zudem, die Rechte (Firewall) für den Zugriff auf seine Server selbst festzulegen. Alle Server werden im Rechenzentrum der GWDG auf moderner Hardware unter Einhaltung aktueller Datenschutzanforderungen betrieben.

In einer ersten Testphase können die IT-Beauftragten der Max-Planck-Institute sowie der Universität Göttingen die Funktionen derzeit evaluieren und Vorschläge zur Optimierung des Angebots einbringen. Die gewonnenen Erkenntnisse fließen in die derzeit laufenden Vorbereitungen für eine öffentliche Testphase ein, in der der Dienst „GWDG Cloud Server“ allen Angehörigen der Max-Planck-Gesellschaft und der Universität Göttingen zur Verfügung stehen wird. Nach erfolgreichem Abschluss der Testphase wird der Dienst „GWDG Cloud Server“ zeitnah in einen Produktionsbetrieb überführt.

Benutzerhandbuch von cloud.gwdg.de Dashboard

Wenn Sie eine VM ohne eine Floating (public) IP haben, jedoch keinen Zugriff auf das öffentliche Netz/Internet haben, könnte dies daran liegen, dass der Router in Ihrem Projekt einen Fehlerzustand aufweist.

Loggen Sie sich zunächst auf cloud.gwdg.de ein und wählen Sie ihr Projekt (Dropdown links oben).

Gehen Sie nun zum Menü “Netzwerk” > “Router” und öffnen Sie die Detailansicht des Routers, indem Sie auf seinen Namen klicken. Wählen Sie anschließend das Tab “Interfaces” aus und notieren Sie sich die beiden IPs (10.254.1.1 ist das Gateway, 10.254.1.X ist der Router).

Sie können nun in Ihrer VM folgendes prüfen:

ping 8.8.8.8 # sollte nicht gehen
ping 10.254.1.1 # Ping zum Gateway sollte gehen
ping <router ip> # sollte gehen

Ist die Prüfung wie oben beschrieben ausgefallen, können Sie das Problem durch Neustart des Routers beheben.

Gehen Sie auf cloud.gwdg.de und öffnen Sie das Menü “Netzwerk” > “Routers”.

1. Klicken Sie auf das Dropdown-Menü in der Zeile des Routers auf der rechten Seite und wählen Sie “Edit Router” aus.
2. Deaktivieren Sie die Option “Enable Admin State” und speichern Sie die Änderung ab.
3. Warten Sie einige Sekunden.
4. Wählen Sie erneut “Router bearbeiten” aus, um “Enable Admin State” wieder zu aktivieren, und speichern Sie diese Änderung erneut.

Nachdem Sie “Enable Admin State” einmal deaktiviert und wieder aktiviert haben, wurde der Router neu gestartet. Nach kurzer Zeit können Sie den in der Problembeschreibung beschriebenen Test erneut durchführen. Der Befehl “ping 8.8.8.8” sollte nun erfolgreich sein, und damit sollte das Problem behoben sein.

Sollten Sie weiterhin Probleme mit der Netzwerkverbindung haben, wenden Sie sich bitte an cloud-support@gwdg.de

Sie suchen nach Informationen darüber, wie Sie RAM oder CPU von virtuellen Maschinen (VMs), vergrößern können.

Öffnen Sie https://cloud.gwdg.de und loggen Sie sich ein. Gehen Sie anschließend zum Menü für Ihre Instanzen/VMs. Auf der rechten Seite finden Sie für jede Instanz ein Dropdown-Menü. Klicken Sie darauf und wählen Sie “resize” aus. Hier können Sie einen neuen Flavor auswählen und die gewünschten Anpassungen an RAM und CPU vornehmen. Beachten Sie, dass Sie nur Flavors verwenden können, die Ihrer Quota entsprechen. Sobald Sie die Anpassungen bestätigt haben, wird die Maschine angepasst und neu gestartet. Testen Sie anschließend kurz Ihre Maschine und bestätigen Sie die Anpassung im selben Dropdown-Menü mit “Confirm resize”.

Hinweis: Der Server startet dabei durch.

Sie suchen nach Informationen darüber, wie sie die Größe der Root-Disk von virtuellen Maschinen (VMs), die auf einem Volume laufen, vergrößern können.

Bitte senden Sie eine E-Mail an cloud-support@gwdg.de mit der UUID des Servers und der UUID des Volumes, die Sie unter https://cloud.gwdg.de finden. Geben Sie außerdem die gewünschte Größe an, auf die das Volume erweitert werden soll.

Hinweis: Der Server muss dafür kurz von uns gestoppt werden.

Möchte man unter cloud.gwdg.de eine neue VM erstellen kann man diese auch mit einen SSD Volume machen welches aus einem vorhanden Image erstell wird.

Dabei wählt man beim erstellen einer neuen VM unter dem Menupunkt Sources als Boot Source “Image” aus und setz die Option “Create New Volume” auf “Yes”.

Nun wählt man aus den Möglichen Images ein Images aus welches mit .. (SSD) endet. Diese Images sind von uns so markiert das sie als SSD Volume erstellt werden können.

Alles andere macht nun die Cloud automatisch sobald man die VM erstellt.

Ein häufiges Problem von Dockern innerhalb einer Virtualisierungsinfrastruktur ist, dass das den virtuellen Maschinen zur Verfügung gestellte Netzwerk nicht die Standard-MTU von 1500 hat. Dies ist beispielsweise häufig der Fall, wenn in einer Cloud-Infrastruktur (z. B. OpenStack) mit einem Software Defined Network gearbeitet wird. Der Docker Daemon überprüft beim Start nicht die MTU der ausgehenden Verbindung. Daher wird der Wert der Docker-MTU auf den Standard 1500 gesetzt.

Mehr auf https://mlohr.com/docker-mtu/

Man kann in seiner Virtuellen Maschine prüfen welche MTU Size verwendet wird durch “ip link”.

1. lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 
1000 link/
loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2. ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc fq_codel state UP mode DEFAULT group default
 qlen 1000 link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
3. docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group
 default link/ether uu:vv:ww:xx:yy:zz brd ff:ff:ff:ff:ff

Wenn die ausgehende Schnittstelle (in diesem Fall ens3) eine MTU kleiner als 1500 hat, sind einige Maßnahmen erforderlich. Wenn es größer oder gleich 1500 ist, trifft dieses Problem nicht auf Sie zu.

1. Lösung des Problems (Docker-Daemon) Durch anpassen der MTU Size in /etc/docker/daemon.json (Datei erstellen wenn nicht vorhanden) kann das Problem für alle Container auf der VM behoben werden.

vim /etc/docker/daemon.json
{ 
   "mtu": 1450 
}
systemctl restart docker.service 
systemctl restart docker.socket 

2. Lösung des Problems (docker-compose) Durch Anpassung der MTU Size im docker compose file kann das Problem für eine Anwendung auf allen VMs gelöst werden.

...
networks:
  default: 
    driver: bridge 
    driver_opts:  
      com.docker.network.driver.mtu: 1450 
... 
docker-compose down; docker-compose up

docker run --rm -it ubuntu:18.04 /bin/bash 
apt update 
... hangs 
exit 

vim /etc/docker/daemon.json 
{ 
  "mtu": 1450 
} 
systemctl restart docker.service 
systemctl restart docker.socket 

docker run --rm -it ubuntu:18.04 /bin/bash 
apt update 
... runs