(Upgrade) Tags: mobile edit mobile web edit |
mNo edit summary |
||
| Line 14: | Line 14: | ||
|use=ask | |use=ask | ||
|admins=derf, byte, nomaster, uen, feuerrot, ytvwld, nik | |admins=derf, byte, nomaster, uen, feuerrot, ytvwld, nik | ||
|netbox_id= | |netbox_id=12 | ||
}} | }} | ||
Großer mächtiger VM-Host für Clubrauminfrastruktur und Projekte. Ein Teil der Dienste befindet sich auch auf dem [[Kubernetes Cluster]]. | Großer mächtiger VM-Host für Clubrauminfrastruktur und Projekte. Ein Teil der Dienste befindet sich auch auf dem [[Kubernetes Cluster]]. | ||
Revision as of 16:51, 29 March 2024
| helios.chaosdorf.space | |
|---|---|
| |
| almighty server | |
| Ort | Lounge |
| Zweck | virtualization host |
| OS | Debian 12 |
| Disks | 38TB38,000 GB <br />38,000,000 MB <br />38,000,000,000 kB <br /> |
| RAM | 32GiB32,768 MiB <br />33,554,432 kiB <br />34,359,738,368 B <br />0.0313 TiB <br />34,359.738 MB <br /> |
| Admin-Toolkit | Yes |
| PAM? | Yes |
| SSH user login? | No |
| Besitzstatus | Club-Eigentum |
| Benutzung | Nachfragen |
| Admins | derf , byte, nomaster, uen, feuerrot, ytvwld, nik
|
| NetBox ID | 12 |
Großer mächtiger VM-Host für Clubrauminfrastruktur und Projekte. Ein Teil der Dienste befindet sich auch auf dem Kubernetes Cluster.
Hardware
- Mainboard: ASRock Mini-ITX mit 12x SATA
- CPU: Intel Atom C2750 (Avoton) 8-Core
- Storage: 10 3,5" Festplatten, 20TB
- RAM: 4x 8GB DDR3 1600MHz ECC
- Gehäuse: Chenbro 19" 2HE mit 8 3,5" Festplatteneinschüben
- Netzteil: 400W EPS Green
Storage
Das Gehäuse bietet Platz für 10 SATA-Platten, davon 2 intern (2.5") und 8 in Festplattenschächten (3.5").
Layout bei Aufsicht aufs Gehäuse:
| System | System | ||
| VMs (alt) | Storage | VMs (neu) | VMs (neu) |
| VMs (alt) | Storage | leer | leer |
Systemplatten
Sind die beiden internen 2.5"-Platten. Jeweils 1TB Western Digital Red (WDC WD10JFCX-68N6GN0). Auf beiden Platten befinden sich aus historischen Gründen™ vier Partitionen á 250GB, die wie folgt genutzt werden.
- 1. Partition: RAID 1 für /
- 2. Partition: RAID 1 für backup-VG
- 3. Partition: RAID 1 für backup-VG
- 4. Partition: RAID 1 für backup-VG
VM-Platten
- VMs1: Hitachi Deskstar 7K2000 HDS722020ALA330 (wwn-0x5000cca222c96707)
- VMs2: Hitachi Deskstar 7K2000 HDS722020ALA330 (wwn-0x5000cca221c5cc76)
Jeweils 2TB Hitachi Deskstar 7K2000 (HDS722020ALA330). Darauf liegt ein RAID1 für die VG vmstorage, welche wiederum LVs für die einzelnen VMS enthält.
Storage
Zwei 16TB-Platten, auf denen sich jeweils ein LUKS-Container (/dev/mapper/storage?) befindet, die an die VM fileserver
durchgereicht werden.
Netzwerk
Von hinten betrachtet hat das Mainboard drei Netzwerkinterfaces.
- Oben links: IPMI
- Oben rechts: eth0
- Unten rechts: eth1
Das IPMI-Interface ist vom Betriebssystem aus nicht sichtbar. Die anderen beiden sind als bond0 per LACP / 802.3ad zusammengefasst. IP/IPv6 ist darauf nicht konfiguriert.
Aus bond0 fällt VLAN 1 (Management) untagged raus, die VLANs 3-5 tagged. VLAN 2 (WAN) ist nicht erreichbar. Alle weiteren Interfaces sind Bridges auf Basis von bond0.
| Interface | IP | libvirt-Name | Beschreibung |
|---|---|---|---|
| br0 | 192.168.0.9 (statisch) | management | Direkte Verbindung zu bond0, d.h. VLAN 1 |
| br1 | — | — | VLAN 1 auf bond0 |
| br3 | 172.22.26.11 (DHCP) | default | VLAN 3 auf bond0 |
| br4 | — | freifunk-mesh | VLAN 4 auf bond0 |
| br5 | — | freifunk-client | VLAN 5 auf bond0 |
| br21 | — | — | VLAN 21 auf bond0 |
Die Bridges br1, br4 und br5 werden ausschließlich für VMs verwendet. IPv6 ist dort per /etc/sysctl.d/ipv6.conf aus, IPv4 per /etc/network/interfaces. Auf br3 und br21 läuft zwar IPv6, es werden aber keine Router Advertisements akzeptiert (damit alles per br3 über das normale Access-Netz rausgeht und public IPv6 überhaupt funktioniert).
Virtuelle Maschinen
| Hostname | Operating System | Disk size | RAM size | Admins | |
|---|---|---|---|---|---|
| Dockerserver | dockerserver | Debian 12 | 250 GB250,000 MB <br />250,000,000 kB <br />0.25 TB <br /> | 16,384 MiB16,777,216 kiB <br />17,179,869,184 B <br />16 GiB <br />0.0156 TiB <br />17,179.869 MB <br /> | nomaster ytvwld marudor magluz |
| Fileserver | fileserver | NixOS 23.11 | 32,000 GB32,000,000 MB <br />32,000,000,000 kB <br />32 TB <br /> | 2,048 MiB2,097,152 kiB <br />2,147,483,648 B <br />2 GiB <br />0.00195 TiB <br />2,147.484 MB <br /> | nomaster ytvwld |
| Hassserver | hassserver | Hass OS | 40 GB40,000 MB <br />40,000,000 kB <br />0.04 TB <br /> | 4,096 MiB4,194,304 kiB <br />4,294,967,296 B <br />4 GiB <br />0.00391 TiB <br />4,294.967 MB <br /> | derf |
| Mqttserver | mqttserver.chaosdorf.space | Debian 12 amd64 | 16 GB16,000 MB <br />16,000,000 kB <br />0.016 TB <br /> | 512 MiB524,288 kiB <br />536,870,912 B <br />0.5 GiB <br />4.882813e-4 TiB <br />536.871 MB <br /> | feuerrot derf |
VM anlegen
Zum Beispiel ein Debian Stretch im Access VLAN mit 1GiB RAM und 20GB Festplatte:
virt-install --connect qemu+ssh://helios.chaosdorf.space/system -n testvm --memory 1024 --network network=default --cpu host --boot uefi --os-variant debian12 -l http://ftp.de.debian.org/debian/dists/stable/main/installer-amd64/ --disk pool=vmstorage,size=20
Falls vorhanden, kann eine preseed-Konfiguration mit --initrd-inject berücksichtigt werden.
Snapshots
Am Beispiel des Dockerserver
- VM herunterfahren (→ Konsistenter Dateisystemzustand)
- sudo lvcreate --snapshot --size 250g --name dockerserver-backup vmstorage/dockerserver (Größe anhand des erwarteten Schreibumfangs auf dem per Snapshot gesicherten Volume anpassen)
- VM starten, Dinge tun (z.B. komplexeres Dist-Upgrade)
- Wenn erfolgreich: sudo lvremove vmstorage/dockerserver-backup
- Andernfalls Rollback: VM herunterfahren, sudo lvconvert --merge vmstorage/dockerserver-backup, VM wieder starten
IPMI
Ist das Interface links und sehr seriös. Als grundlegender Alias empfiehlt sich
helios-ipmi='ipmitool -I lanplus -H helios-ipmi.chaosdorf.dn42 -U meinnick -f datei/mit/passwort'
ipmitool benutzt wenn möglich IPv6. Nach Änderungen an der VLAN-Config ist das IPMI-Interface teils nur noch per IPv4 erreichbar, dann muss helios-ipmi.chaosdorf.dn42 durch die entsprechende IPv4-Adresse ersetzt werden. Eigentlich sollte das nicht passieren, da das IPMI-Interface an einem eigenen Switchport hängt, der von den sonstigen Änderungen unabhängig ist — Irgendwas ist da aber komisch™.
Nützliche Befehle sind unter anderem:
- Watchdogstatus auslesen: helios-ipmi bmc watchdog get
- Watchdog ausschalten (falls z.B. ein neues System installiert wird): helios-ipmi bmc watchdog off
- Serielle Konsole: helios-ipmi sol activate
- System an-/ausschalten/neustarten: helios-ipmi power on/off/cycle
Serial over LAN
ttyS1 ist per IPMI nutzbar. BIOS geht darüber auch. Grub und Kernel sind vermutlich so konfiguriert, dass sie ausschließlich mit der seriellen IPMI-Konsole (und nicht mit einem angeschlossenen Monitor) reden.
Watchdog
Das Mainboard hat einen IPMI (SMS/OS) Watchdog. Der Daemon bmc-watchdog setzt diesen alle 60 Sekunden zurück. Falls er nicht läuft, wird automatisch nach 15 Minuten ein hard reset ausgelöst.