Geschichte/Server/top4

Aus UUGRN

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-22 (~sdk) - Admin ML

Es gibt nun eine admin Mailing Liste: http://mailman.uugrn.org/mailman/listinfo/admin

2018-10-22 (~sdk) - Offsite Backup? Wanted? Traffic?

Weiß jemand ob es für Top ein Offsite Backup gibt? Ich bin mir ziemlich sicher, dass top seine Daten nirgends hin pusht. Ob eine andere Maschine die Backups pullt kann ich nicht nachvollziehen.

2018-10-21 (~sdk) - Platte voll wegen Backup... was tun?

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

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

  1. ↑ Offizielle Webpräsenz „bhyve”
  2. ↑ FreeBSD Handbook: 22.4. FreeBSD as a Host with bhyve
  3. ↑ bhyve FAQ: Q: What VM operating systems does bhyve support?
Abgerufen von „https://wiki.uugrn.org/index.php?title=Geschichte/Server/top4&oldid=12375“