Geschichte/Server/top4
top4.uugrn.org ist der aktuelle (neue) Vereinsserver von UUGRN e.V. Es handelt sich um einen Mietserver.
[ Verein: Server:
• top4
• higgsBeta
]
[ Vereinsjails: mail
• mx1
• mysql
• lists
• wiki
• blogs
• pad
• proxy
• uugrn
• shell
• irc
• bnc
• news
• ftp
• fbsd9
• gitAlpha
• calendarAlpha
]
[ Mitglieder-Jails: shell
• mile
• rabe
• trickster
• che
• friedel
• shl
• hdi
• ltrn
]
Server Forschung nach Rabe
2018-10-21 (~sdk) Wir haben aktuell das Problem, dass auf top immer mal wieder die Platte voll läuft und viele Dienste und Jails dann nicht mehr ordnungsgemäß arbeiten.
Täglich läuft ein cronjob, der das script /root/bin/zfs_backup3.sh ausführt. Dieses Script erzeugt Snapshots und sichert diese zusätzlich in /data/backup/uugrn.org/.
Ich verstehe nicht, warum Snapshots zusätzlich nach /data/backup/uugrn.org gesichert werden, da dieses Verzeichnis auf dem selben Festplattenverbund liegt.
Mein Vorschlag wäre dieses selbstgebastelte Konzept gegen zfs-auto-snapshot auszutauschen.
Vorschlag für einen crontab Eintrag für zfs-auto-snapshot:
15,30,45 * * * * root /usr/local/sbin/zfs-auto-snapshot frequent 3 0 * * * * root /usr/local/sbin/zfs-auto-snapshot hourly 24 7 0 * * * root /usr/local/sbin/zfs-auto-snapshot daily 7 14 0 * * 7 root /usr/local/sbin/zfs-auto-snapshot weekly 4 28 0 1 * * root /usr/local/sbin/zfs-auto-snapshot monthly 12
`zfs-auto-snapshot` managed darufhin die snapshots auf dataset ebene und kann pro dataset an und abgeschaltet werden (über ein zfs attribut). Die Zahl rechts neben hourly/daily/weekly etc. gibt an wie viele des entsprechdenen Snapshot-Typs erhalten bleiben sollen.
Auf eine zusätzliche, zweite Sicherung der Snapshots würde ich verzichten.
Mit diesem Konzept steigt die Speicherlast nicht sprungartig an, sondern lediglich Speicher gelöschter Dateien wird erst 12 Monate später frei gegeben. Ggf. können wir das auf 6 Monate reduzieren.
Wissen die Mitglieder eigentlich, dass sie Zugriff auf die Snapshots über das versteckte Verzeichnis /.zfs haben?
--------------
Hardware
- CPU
- Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz (3300.12-MHz K8-class CPU)
- RAM
- 16GB
- HDD
- ada0: <WDC WD10JFCX-68N6GN0 82.00A82> ATA-9 SATA 3.x device / Serial Number WD-WXN1EC4CK0LC
- ada1: <WDC WD10JFCX-68N6GN0 82.00A82> ATA-9 SATA 3.x device / Serial Number WD-WXN1EC4E8PPE
- ada2: <KINGSTON SH103S3120G 580ABBF0> ATA-8 SATA 3.x device / Serial Number 50026B725206BAE7
- ada3: <TOSHIBA THNSNJ128GCSU JURA0101> ATA-9 SATA 3.x device / Serial Number 45PS10BQTB3W
- Die Storage-Devices sind Eigentum von UUGRN e.V., der Server drumherum ein Mietserver von TWX
OS
- FreeBSD 10.2
- mit ZFS pool version 28
Jails
Es werden Jails gehostet Details unter /Jailkonzept.
Storage Konzept
Der Server verfügt über 2x2.5" Platten zu je 1TB (953869MB), die als bootfähiger zpool (mirror) namens "zroot" betrieben werden. Zusätzlich existieren 2 unterschiedliche SSDs, die für SWAP, ZIL(mirror) und L2ARC verwendet werden.
Mehr unter /Storagekonzept.
Ausblick
Aufgrund der Verfügbarkeit der erforderlichen CPU-Features für Virtualisierung soll bhyve[1] getestet werden. Die erforderlichen Komponenten werden durch das OS bereits mitgeliefert[2]. Mit Hilfe von bhyve können alternative Betriebssysteme betrieben werden, z.B. OpenBSD oder Linux[3]
Details
Geschichte
- 2015-07-01
- Nachdem die Mitgliederversammlung die Server-Modernisierung beschlossen hat, wurde für den Migrationszeitrraum ein 2. Mietserver beauftragt. Dieser befindet sich im gleichen VLAN wie der vorige Vereinsserver und ermöglichst so die sukzessive Übernahme der Jails. Nach der Migration der Jails und Services von top3offline auf top4 werden die Platten aus top4 wieder in die HW von top3 übernommen, der zusätzliche Mietserver besteht also nur zum Zwecke der Migration. Der Server wird dann als "top4.uugrn.org" weiter betrieben.
Administratives
Quellen, Weblinks
- ↑ Offizielle Webpräsenz „bhyve”
- ↑ FreeBSD Handbook: 22.4. FreeBSD as a Host with bhyve
- ↑ bhyve FAQ: Q: What VM operating systems does bhyve support?
