Der IRB Clus­ter für Vir­tu­el­le Ma­schi­nen

Um eine VM anzufordern, schreiben Sie bitte eine E-Mail an irb-linux-support[at]uni-paderborn.de

Da der IRB einen ständigen Ansprechpartner haben muss, können VMs bei uns nur von fest-angestellten Mitarbeitern der Informatik angefordert werden und müssen während derer gesamten Lebenszeit einen solchen Ansprechpartner haben. Um als Studierender eine VM nutzen zu können, für z. B. eine Bachelorarbeit, bitten wir Sie, die Anfrage von Ihrem Betreuer an den IRB weiterleiten zu lassen.

Formular mit empfohlenen Standardwerten zum Ausfüllen

Die fett gedr­­uckten Felder sind notwendig.

• Hostname:
• Verwendungszweck:
• CPUs: 2
• RAM: 4 GB
• Zusätzlicher Speicher (zzgl. Basisspeicher): 0 GB
• Betriebssystem: IRB Debian
• AdminC UPB Username:
• TechC UPB Username:
• TechC Telefonnummer: keine
• Dauer: 15 Monate
• Firewall Whitelist: keine
• Firewall Begründung: keine
• Backups: nein
• Docker: nein
• Weitere Anforderungen: keine

Erläuterungen und Details

• Verwendungszweck der Maschine
  • Wofür wird die VM verwendet?
  • Muss ein spezifischer Grund sein
• Hostname
  • Bitte wählen Sie einen geeigneten Namen für die VM.
  • Die VM wird unter <VM-Name>.cs.uni-paderborn.de erreichbar sein.
• Benötigte Ressourcen
  • Standardressourcen sind:
    • 2 CPU
    • 4 GB RAM
    • 64 GB Platte (Basisspeicher)
  • In vielen Fällen reicht der Basis-Plattenplatz aus. Sollten Sie mehr Speicherplatz benötigen, können wir Ihnen gerne eine weitere Festplatte zur Verfügung stellen, welche wir standardmäßig unter /data einhängen.
  • Darüber hinaus gehende Ressourcen nur, wenn der Verwendungszweck diese erfordert.
• Betriebssystem
  • Standardmäßig verwenden die VMs eine aktuelle Version von Debian, welche wir automatisiert aktualisieren und administrieren.
  • Bei VMs mit unserer Debian-Version erinnern wir an benötigte Neustarts nach Updates und führen diese automatisiert durch, wenn der Server nicht in Verwendung ist. Falls der Server nicht mit anderen Servern zusammen oder gar nicht mit automatisch neu gestartet werden darf, muss das mitgeteilt werden. Tipp: Um einen Server vorübergehend am Neustart zu hindern, empfehlen wir systemd-inhibit, was bereits vorinstalliert ist.
  • Unsere Debian-Version hat TLS-Zertifikaten mitgeliefert.
  • Für andere Betriebssysteme können wir die Installation gerne anstoßen, diese aber nicht administrieren. Insbesondere bieten wir hier keine Dienste wie Backups oder Zertifikate an und können keinen Support leisten.
• Ansprechpartner
  • Administrativ (AdminC) — trägt Verantwortung für die VM; muss ein fest angestellter Mitarbeiter sein.
    • UPB-Account (notwendig)
    • gewünschte UPB-E-Mail (optional)
    • Fachgruppe (optional)
  • Technisch (TechC) — technisch betreuender Kontakt der VM (Betriebssystem, Dienste, etc.), falls dieser vom AdminC abweicht; kann ein Student sein.
    • UPB-Account (notwendig)
    • gewünschte UPB-E-Mail (optional)
    • Telefonnummer (nur für Notfälle; z. B. gehackte VM; empfohlen, aber nicht notwendig)
  • Technischer Missbrauch (AbuseC) — Kontakt, welcher auf E-Mails bezüglich potenziellen Missbrauchs einer VM reagiert, falls dieser vom TechC abweicht; kann ein Student sein.
    • UPB-Account (notwendig)
    • gewünschte UPB-E-Mail (optional)
    • Telefonnummer (nur für Notfälle; z. B. gehackte VM; empfohlen, aber nicht notwendig)
• Laufzeit
  • Standardlaufzeit: 15 Monate
  • Jeweils drei Monate vor Ablauf wird der AdminC informiert und hat die Option, die VM für jeweils bis zu einem Jahr zu verlängern.
• Optional: Firewallfreigaben
  • Protokoll(e) (TCP/UDP) und Port(s)
  • Standardmäßig ist kein Zugriff von außerhalb der Uni auf VMs erlaubt. Jede globale Portöffnung muss dem IRB gegenüber begründet werden.
• Optional: Backups
  • Bitte schreiben Sie, ob von der VM Backups erstellt werden sollen. Falls ja, beachten Sie bitte, dass Dateien, die sich kontinuierlich ändern, nicht konsistent gesichert werden können. Sichern Sie diese bitte per Dump/Snapshot innerhalb der VM und geben Sie uns die Verzeichnisse an, in denen sich die sich ändernden Daten befinden, diese Verzeichnisse werden wir dann vom Backup ausnehmen.
  • Backups werden täglich verschlüsselt bei der RWTH hinterlegt.
• Optional: Docker
  • Wenn Sie Docker nutzen wollen, können wir für Ihre VM eine optimierte Konfiguration anbieten, welches einige häufig auftretende Probleme vermeidet.
• Optional: Sonstige Anforderungen

Wir beraten Sie gerne individuell, um die optimale VM-Konfiguration für Ihren Bedarf zu finden.

Falls Sie planen, mit der VM Netzwerkscans des Internets durchzuführen, sind dabei, unbedingt die Hinweise vom IMT zu beachten und dies bei der Beantragung zu nennen. Bitte benennen Sie auch einen AbuseC (siehe oben).

Wir richten für den TechC (und weitere User, sofern angefordert) Zugriff in unserem vSphere Center ein, welcher direkten Zugriff auf eine graphische Konsole der VM  so wie Funktionen wie Reboot, An-/Ausschalten, etc. ermöglicht.

Der Virtual Center-Server ist erreichbar unter https://vmc.cs.uni-paderborn.de. Die Anmeldung erfolgt mit Ihrem IMT-Login.

Backup

Die Virtuelle Maschine selbst wird in einem SAN gespeichert. Alle SAN-Komponenten sind redundant vorhanden, so dass ein Datenverlust aufgrund eines Hardware-Fehlers unwahrscheinlich ist. Wir können diesen oder andere Fehlerquellen jedoch nicht vollkommen ausschließen, was zu Datenverlust führen könnte.

Achtung: Es findet kein zentrales Backup der Virtuellen Maschinen statt!

Sollte eine VM produktiv, und nicht nur zu Testzwecken verwendet werden, sollte Sie auf jeden Fall für automatisierte Backups der Daten Ihrer VM sorgen. Hier bietet sich der IBM Spectrum Protect Service (Tivoli) an, den die RWTH Aachen zentral für die Universität Paderborn betreibt. Informationen hierzu finden Sie beim IMT, welches diesen Backupservice betreut.

Archivierung

Alle Daten Ihrer VMs werden spätestens 1 Jahr nach Ablauf der Laufzeit Ihrer VM, oder auf Anfrage, vollständig gelöscht.

Bitte nehmen Sie zur Kenntnis, dass unsere Virtuelle Maschinen kein geeignetes Mittel zur archivierung Ihrer Daten sind. Die RWTH Aachen bietet hier geeignete Archivserver an.

Virtuellen Maschine absichern

Bitte beachten Sie, dass Ihre VM mit einer öffentlichen IP-Adresse ausgestattet ist und sich im Internet befindet.

Es sind zwar alle Ports nach außen hin defaultmäßig gesperrt, aber es ist dennoch absolut unerlässlich, dass Sie das Betriebssystem der Virtuellen Maschine selbst kontinuierlich aktuell halten und absichern. Automatisierte Updates, Firewalls, konservative Vergabe von Zugriffsrechten, kein Passwortzugang (sondern nur mit public key), und Ähnliches, empfehlen sich. Gerne beraten wir Sie hierbei.

Sie tragen die volle administrative Verantwortung Ihrer Virtuellen Maschine!

VMware Tools installieren

Um die Stabilität des VMware-Clusters zu gewährleisten, ist es erforderlich, dass innerhalb der VM ein Systemdienst über den vSphere mit dem Betriebssystem der VM interagieren kann, die VMware Tools, installiert und aktuell gehalten wird.

Dies kann entweder über die VMware Tools, die von VMware selbst zur Verfügung gestellt werden, geschehen, oder über entsprechende Tools, die direkt vom Betriebssystem-Anbieter angeboten werden. Ein Bespiel dafür wären die Open VM Tools, die in diversen Linux-Distributionen enthalten sind.

Eine Anleitung zur Installation der Tools finden Sie direkt bei VMware unter

http://www.vmware.com/files/de/pdf/support/vmware-tools-installation-configuration_DE.pdf

Fehlen VMware-Tools bzw. gibt es Probleme aufgrund einer nicht mehr aktuellen Virtuellen Hardware, kann es vorkommen, dass VMs bei Wartungsarbeiten ausgeschaltet werden müssen.

Virtuelle ISOs/CDs/DVDs/etc. & Snapshots

Virtuell eingelegte ISOs verursachen interne Komplikationen beim automatischen Verschieben der VMs zwischen den Servern des  Clusters, was die Performanz Ihrer VMs deutlich beinträchtigen kann.

Auch wird beim Anlegen von Snapshots, welche die ISOs eingelegt haben, eine harte Abhängigkeit auf diese ISOs erstellt die nicht ohne löschen des Snapshots wieder aufgelößt werden können. Das schränkt Operationen die sie auf Snapshots ausführen können und die Verwaltung der betroffenen ISOs stark ein.

ISOs sollten möglichst kurzfristig eingelegt werden, und von VMs mit diesen sollten keine snapshots gemacht werden.

Sollten solche ISOs oder Snapshots notwendige Administrative Aktionen behindern so behalten wir es uns vor diese hart zu unmounten oder betroffene snapshots zu entfernen.