Die ITO - IT Operations der School of Computation, Information and Technology betreibt einen ESX-Cluster. Bevor Sie VMs beantragen, muss Ihr Lehrstuhl einen Administrator ausweisen , der von uns in den ESX-Betrieb eingewiesen wird.

Beantragung

Zur Beantragung neuer VMs schicken Sie bitte eine Mail an support@ito.cit.tum.de. Normalerweise schicken Sie für jede neue VM eine neue Mail (nicht als Antwort auf eine ältere Mail). Wenn mehrere VMs gleichzeitig beantragt werden, reicht auch eine Mail aus. Diese Anträge können nur von einem der uns bekannten ESX-Lehrstuhl-Admins gestellt werden.  Für die sachgemäße Bearbeitung ist folgende, ausgefüllte Box erforderlich:

Erklärung der einzelnen Punkte:

• CIT-Org / -inhaber: Wir benennen die Server nach der CIT-Org, z. B. vmorg42. Die von uns eingewiesenen VMWare-Betreuer des jeweiligen Lehrstuhls haben über VSphere Zugang zu der VM
• Kurzer Projektname: Möglichst ein bis drei Wörter, die diesen Server eindeutig bezeichnen. In VSphere wird die VM dann beispielsweise als «vmmustermann42 - Verzeichnisdienste» zu sehen sein. Das Ziel des Projektnamens ist es, dass Sie sofort bescheid wissen, wenn wir Sie anrufen und sagen „Es gibt ein Problem mit Ihrem Verzeichnisdienste-Server“. Manche Lehrstühle haben mehrere Dutzend VM-Server bei uns, sodass die Nummer allein nicht aussagekräftig genug ist
• Weitere Beschreibung des Projektes: Hier können Sie zum Beispiel schreiben, ob es sich um eine Doktorarbeit handelt oder um Infrastruktur des Lehstuhls
• Projektlaufzeit: Eine unverbindliche Angabe, die uns bei der Planung hilft. Auch «unbegrenzt» ist gültig
• Ansprechpartner: Zwei Personen, die mit dem Projekt und mit der Bedienung von VSphere vertraut sind. Wir brauchen den zweiten Ansprechpartner, falls der erste nicht erreichbar ist. Bei Ubuntu-Servern legen wir für diese beiden Personen Kennungen mit sudo-Rechten an
  • Bitte RBG-Loginnamen angeben
• Weitere Benutzer: Wir können weitere Accounts vergeben. Außerdem könnt ihr uns optional auch mitteilen, wer Eure selbst installierten Dienste in der VM benutzt (beispielsweise ein Wiki). Dann legen wir keinen Account an, aber die Angabe kann uns helfen, wenn z.B. Downtimes geplant werden müssen.
  • Bitte RBG-Loginnamen angeben
  • Für Ubuntu: Account ja/nein? Sudo ja/nein?
• Hardware: Wenn weiter nichts angegeben ist, bekommt der Server 2 CPU und 4 GB RAM für Windows beziehungsweise 2 CPU und 2 GB RAM für Ubuntu. Die Größe der Systemplatte ist immer 80 GB (mit Thin Provisioning) und kann nicht verändert werden.
  Eine Erweiterung der VM-Hardware ist wie folgt möglich:
  Festplattenkapazität: zweite Festplatte als Ceph RBD, welches separat vom ESX-Verwalter gesichert werden muss und nicht von der RBG gesichert wird.
  CPU: bis zu insg. 4 vCPU.
  RAM: bis zu insg. 8 GB RAM

Richtlinien

Das reibungslose Nebeneinander der VMs funktioniert nur deshalb so gut, weil wir sehr großen Wert darauf legen, dass bestimmte Regeln von der RBG und den Lehrstühlen eingehalten werden. Bitte beachten Sie also folgendes:

• Das Betriebssystem wird von uns mit einem Template installiert. Diese Templates wurden von der RBG für unsere Umgebung optimiert. Momentan (Stand Juli 2020) bieten wir folgende Betriebssysteme an:
  • Ubuntu Server 20.04
  • Windows Server 2019 Datacenter
• Wir (die RBG) haben für alle Server root-Zugang / Admin-Rechte. Bitte entfernen Sie nicht die Benutzer, die von der RBG angelegt wurden und ändern Sie den SSH-Port nicht. Das beschränken von SSH auf Login mit Public Keys ist ausdrücklich erlaubt.
• Um die übrigen VMs im Cluster nicht unnötig zu belasten, bitten wir um verantwortungsvollen Umgang mit den Ressourcen. Wenn alle Server gleichzeitig CPU, Netzwerk oder Disk-IO bis zum Maximum belasten würden, würde der Cluster sehr träge werden.
• Bitte achten Sie selbst darauf, dass Sicherheitpatches für Windows oder Ubuntu regelmäßig eingespielt werden.
• Führen Sie bitte kein Release-Upgrade auf eine andere Windows-Version, einen neueren Ubuntu-Release oder ein anderes Betriebsystem durch.
• In jeder VM müssen die sogenannten VMWare Tools installiert sein, damit die Ressourcen zentral besser genützt werden können und die Backups ungestört durchlaufen können. Nachdem wir Ihnen eine VM übergeben, sind die Tools installiert. Bitte entfernen Sie sie nicht. Bitte benutzen Sie nicht die open-vm-tools, sondern die vorinstallierten VMware-Tools.
• Die VMWare Tools müssen regelmäßig aktualisiert werden. Dazu muss für jede VM im vSphere-Client ein automatisches Upgrade gestartet werden.
• Für jeden VM-Server sollte jederzeit ein Ansprechpartner erreichbar sein (auch wenn Sie selbst z.B. verreist sind). Daher brauchen wir für jede VM mindestens zwei Kontaktpersonen (am besten immer beim Beantragen einer VM per Mail angeben, inkl Telefonnummer). Beide Kontaktpersonen sollten sich mit der Bedienung von vCenter auskennen. Wir sprechen die Kontaktpersonen zum Beispiel an, um geplante Reboots zu besprechen, oder wenn eine VM durch starke Ressourcenbelastung auffällt.

Wir empfehlen außerdem folgende optionale Maßnahmen:

• Die VMs sind zur Benutzung als Server vorgesehen. Bitte installieren Sie keine Desktop-Umgebung auf Linux-VMs.

• Wir beschränken sehr gerne den Zugriff auf RDP (Windows) bzw. SSH (Linux) per Firewall. Die Verwaltung der Firewall obliegt den Lehrstuhl-EDV-Betreuern, z.b. durch Auftrag an die RBG Netzwerkgruppe.
• Wir sehen es sehr gerne, wenn SSH-Zugriff auf Public Key Authentication beschränkt wird. SSH-Keys für die RBG-Benutzer sind deswegen auf allen VMs hinterlegt.

Anpassungen Windows Server 2019

Bitte macht kein In-Place-Update von Windows 2012 zu 2019. Gerne stellen wir euch hierfür frische VMs zur Verfügung.

In unserem Windows 2019-Image haben wir geändert:

• Firewall: File and Printer Sharing (Echo Request - ICMPv4-In + ICMPv6-In) Enable
• Server Manager - Add Roles and Features - Telnet Client
• NTP Config (in Admin-CMD Shell):
  • net stop w32time
  • w32tm /config /syncfromflags:manual /manualpeerlist:"ntp1.in.tum.de,ntp2.in.tum.de"
  • w32tm /config /reliable:yes
  • net start w32time
• SSH Server / Client:
     Settings → Apps → Apps and Features → Manage Optional Features → OpenSSH Server; Client ist bereits installiert
• Nochmal SSH (in einer Admin Shell):
  • Install-Module -Force OpenSSHUtils -Scope AllUsers
  • Set-Service -Name ssh-agent -StartupType ‘Automatic’
  • Set-Service -Name sshd -StartupType ‘Automatic’
  • Start-Service ssh-agent
  • Start-Service sshd
• LRZ Windows Updates (siehe https://doku.lrz.de/pages/viewpage.action?pageId=30082306 )
  Den Gruppenrichtlinieneditor ausführen: Start → gpedit.msc
  • Computer Configuration → Administrative Templates → Windows Components → Windows Update
  • "Configure Automatic Updates" → 3 - Auto download and notify for install
  • "Specify intranet Microsoft update service location" → https://sus.lrz.de als intranet update und intranet statistics server
  • "Do not connect to any Windows Update internet locations" → Enable
  • "Enable client-side targeting" → Enabled
  • Target group name: Server
• Telemetrie:
  • Group Policy Editor gpedit.msc ; wieder zu Windows Components - Data Collection and Preview Builds
  • "Allow Telemetry": Disabled
• Zusätzlich Telemetrie: Start → Settings → Privacy → Diagnostics & feedback
  • Diagnostic data: basic
  • Feedback frequency: never
• KMS Server: In einer Admin cmd-Shell
  • cscript \windows\system32\slmgr.vbs -skms kms.in.tum.de

-- Die ITO-Systemgruppe