Backup Konzept mit T20 (Hauptsystem) und HP Microserver (Backup) + Datenbereinigung?

[besterino]

Überlege, mir den kleinsten HP Microserver als Backup-Storage zu meinem Dell T20 (Xeon, 32GB RAM) zuzulegen. Habe hier noch 2x 4GB unbuffered ECC Ram aus dem Dell-Server liegen (die hoffentlich in dem HP funktionieren?) und 4x 1TB Platten aus meiner alten Linux-Box, die alle nicht untätig vergammeln sollen.

Achtung: alles Heim-Einsatz, keine produktive Umgebung, keine spezifischen Rechte/Nutzer im Spiel.

Ausgangslage: der T20 betreibt verschiedene VMs unter Hyper-V und läuft 24/7. Einziger kritischer "Dienst" auf dem T20 ist eine Ubuntu-Hyper-V-VM als Storage-Server. Als Dateisystem nutzt die Ubuntu-VM ein ZFS-RaidZ. Diese VM stellt im Netz auch die SMB-Freigaben bereit mit den "wichtigen" Daten der Familie. ZFS-Snaps habe ich auf der Ubuntu-VM (noch) nicht eingerichtet, insb. da ich ZFSonLinux noch nicht so recht über den Weg traue und eben noch kein Backup habe. =) Auch funzt (bei mir) die ZFS-Administration mit napp-it unter Linux noch nicht so 100%ig, so dass ich mich da noch nicht rangetraut habe.

Die Grund-Idee des Backup-Konzepts ist daher zurzeit:
Zu bestimmten Zeiten weckt der T20 den HP über WOL auf (z.B. 1x die Woche sonntags). Dann macht der HP sein (rsync?) Backup bestimmter SMB-Verzeichnisse auf dem T20 und legt sich im Anschluss selbst wieder schlafen bis zum nächsten Weckruf.

Als OS wollte ich nativ (also "auf'm Metal") Omni-OS mit Napp-it/ZFS einsetzen mit einem RaidZ über die 4 1TB HDDs in einem Pool.

Nun habe ich mir gedacht, dass doch der HP einfach vor jedem Backup-Vorgang nur einen ZFS-Snapshot anlegen müsste, damit ich quasi darüber mein "inkrementelles" Backup auf dem HP habe.

Die wirklich kritischen Daten dürften <2TB sein, der Rest "darf" zur Not verloren gehen.

Wichtig ist mir, dass sich der Backup-Vorgang idealerweise 100% automatisieren lässt.

Nun meine Fragen dazu:

1.
Ich hätte gern 4 Daten-HDD (3,5") und 1 OS-HDD (2,5") im HP, alles intern. Bekomm' ich das von Haus aus unter, oder brauche ich Zubehör? Wenn ja, welches?

2.
Eventuell werden der HP und der T20 direkt über 10Gbase-T verbunden... Ich gehe mal davon aus, dass die Hardware des HP "leistungsstark" genug ist (der HP soll ja eigentlich nur von einer externen Quelle auf HDDs lesen und nur zu Backup-Zwecken auf die HDDs schreiben. Verschlüsselung brauch' ich nicht und Speed ist dabei insgesamt wohl eher zweitrangig.

3.
Konzeptionell habe ich ja quasi das Problem, dass das "echte" Backup (also insb. auf dem T20 zukünftig gelöschte Daten) ja nur 1x auf dem HP vorhanden ist.

Steigen im HP also z.B. 2 Platten aus, ist die "Historie" der Daten dahin und ich habe auf dem T20 nur noch den aktuellen Stand.

Das war allerdings bisher jahrelang auch so und ich habe daher auf dem NAS (heute T20) de facto eigentlich nie etwas kritisches (Bilder) gelöscht oder überschrieben, sondern immer neue Verzeichnisse angelegt (und das Ganze in unregelmäßigen Abständen komplett auf eine andere Platte kopiert). Daher habe ich aber im Zweifel Stand heute einen Haufen Daten doppelt und dreifach... (insb. weil man eine SD-Karte aus einer Kamera vorsichtshalber immer komplett überspielt, anstatt einmal zu schauen, von wann der letzte Stand war).

Um dem Ganzen zu begegnen, könnte ich ja den ZFS-pool auf dem HP z.B. noch einmal auf eine einzige große USB-Platte wegsichern. Haltet Ihr das für geboten und einfach (automatisiert) umsetzbar? Wie sollte ich das machen, z.B. mit einem weiteren ZFS-Pool auf der USB-Platte?

4.
Das schwierigste zum Schluss: wie säubere ich meinen Datenbestand möglichst automatisiert von Doubletten? Könnte ich das z.B. erreichen, indem ich auf dem HP zusätzlich zu den Snapshots auch die ZFS-Deduplizierung aktiviere? Die Performance für das Backupsystem ist ja grds. eher zweitrangig, insbesondere bei Erstellen des 1. Backups darf der ja ruhig etwas länger rödeln.

Was gäbe es für Alternativen? Aus - wahrscheinlich nachvollziehbaren Gründen ;-) - würde ich es gerne vermeiden, das manuell angehen zu müssen...

So, das war's fürs erste... :-D

 

[gea]

1.
geht, siehe Startpost HP thread

2.
10G ist schnell wie die schnellsten SSD.
Ideal zu Arbeiten wenn man das Storage als Primärstorage nimmt. Nur für incrementelles Backup nicht nötig

3.
Backup ist wie Brot. Wenn mans braucht immer mindestens von gestern und wenn man genauer hinschaut oft schon schimmelig.

Wichtig ist ein möglichst gutes Primärstorage mit Versionierung (readonly snaps, Windows vorherige Version). Also unbedingt Snapshots auf dem Dell nachen (manuell oder als Job), z.B. täglich bzw wöchentlich. @Work kann ich ein Jahr zurückgehen.

Backup ist eher Disaster Backup, sollte aber auch eine Versionierung haben. Die muss aber nicht so umfangreich sein. Ob man Primärstorage -> Backup manuell, als job, per zfs send, rsync oder robocopy aktuell hält, ist zweitrangig.

4.
Das Dubletten Problem (datei.doc, datei-1.1.doc, datei final.doc etc) löst man mit einem Dateisystem mit Versionierung. Es gibt nur das aktuelle Originaldokument. Frühere Versionen gibts mit "vorheriger Version".

Deduplizierung löst das Chaos Problem nicht. Ganz im Gegenteil. Mit wenig RAM kann das böse ins Auge gehen. Manuell aufräumen und künftig auf Versionierung setzen.

 

[besterino]

Dankeschön! Ich werde da wohl mal ein bisserl testen müssen. Vor allem mit der Einrichtung der regelmäßigen snapshots muss ich mich mal beschäftigen.

Zu den Doubletten: es ist nicht so, dass ich echte Versionen hätte, sondern eher Verzeichnisse z.B. August14 und September14, wo September14 eben auch den August enthält... Aber eben nicht zwingend vollständig. Jaja, ich weiss, hat man Müll, hat man Müll...

Werde wohl mal ein Tool laufenlassen müssen, dass Dateien auf Checksummenbasis vergleicht und dann manuell aufräumen müssen. Hatte halt gehofft, dass ZFS deduplication mir das irgendwie abnehmen könnte. Ich hätte 8GB RAM in der Kiste für 4TB Speicherplatz.

 

[besterino]

Ich glaub', wenn ich darf mach ich hier mal ein kleines Tagebuch draus. Schon damit ich irgendwann mal zurückblättern kann, was ich denn auf meinem Weg eigentlich so alles konfigurieren musste...

Wo bin ich jetzt im Vergleich zum Ausgangsposting:

Der kleine HP ist mit OmniOS und Napp-it nun funktionsfähig konfiguriert. Bis ich allerdings die 10Gbit Intel X540-T2 richtig laufen hatte, war es für mich (als nicht Solaris-Kenner) ein etwas steinigerer Weg. Wichtig war dabei am Ende, dass ich die default mtu in der Datei "/kernel/drv/ixgbe.conf" von 1500 auf 9000 setzen musste, um die Jumbo Frames überhaupt aktivieren zu können. Ansonsten läuft die Kiste mit Napp-it quasi wirklich "out-of-the-box" mit der Anleitung auf napp-it.org. Sehr schön!

Ebenfalls etwas Zeit hat es in Anspruch genommen, mein Hauptsystem (mit ZFS on Linux) dazu zu bringen, a) regelmäßig snap-shots zu erzeugen und b) den Windows-Clients die Snapshots auch unter "Vorherige Versionen" anzuzeigen.

Zu a): ohne den napp-it autoservice geht nüschts. =) Für viele wohl selbstverständlich, für mich war's das nicht. Um den zu aktivieren, musste ich zunächst über die console für root eine crontab erzeugen ("crontab -e"), danach lässt sich der autoservice über Napp-it konfigurieren. Zu Testzwecken habe ich jetzt erst einmal einen täglichen snap und einen wöchentlichen scrub eingerichtet.

Zu b): Das ist mir nun auch endlich gelungen, indem man die SMB-Freigabe nicht über napp-it konfiguriert (dort ist smb=off konfiguriert), sondern eben wie alle sonstigen Samba-Freigaben auch über die smb.conf. In der smb.conf müssen folgende Zeilen eingetragen und entsprechend den eigenen Gegebenheiten angepasst werden:

global]
...
unix extensions = off #keine Ahnung was das macht, aber stand so in der Anleitung

[Server] # Name der Freigabe, wie er unter Windows erscheinen soll
comment = ZFS on Linux Server
inherit acls = Yes
path = /ZFSdata/Raid10 # Das freizugebende ZFS-Verzeichnis
read only = No
follow symlinks = yes
wide links = yes
vfs objects = shadow_copy2
shadow: snapdir = .zfs/snapshot
shadow: sort = desc
shadow: format = daily-1435708946_%Y.%m.%d.%H.%M.%S # der Teil "daily-1435..." ist das Präfix bei meinen Snaps, das offenbar von Napp-it angelegt wird (vermutlich eindeutige ID für jeden Job?).

Wichtig ist wohl "shadow: format", das ich an die Napp-it Nomenklatur angepasst habe. Der Teil hinter "daily" ist nach meinem Verständnis job-spezifisch, interessanterweise tauchen aber auch die Snaps von anderen Jobs auf. Ist wohl tatsächlich nur eine "Format"-Angabe, und die Details sind unwichtig (?). Muss ich aber noch mit ein paar mehr Jobs mal testen.

Todos:
1. Main-Backup Ubuntu-VM auf OmniOS einrichten
Da ich jetzt 2x ZFS auf unterschiedlichen Kisten in Betrieb habe, müsste das doch eigentlich irgendwie über ZFS-send / receive gehen. Logisch wäre es aus meiner Sicht am einfachsten, wenn der T20/die VM den HP z.B. 1x die Woche aufweckt, dann der HP bei jedem Booten sich ein Backup zieht und sich dann im Anschluss wieder schlafen legt bis zum nächsten Weckruf.

2. Zusätzliches Backup auf weitere (ggf. externe) HDD einrichten.
Hierzu bin ich noch unentschlossen. Am liebsten wäre mir zurzeit eine Lösung, die sich möglichst unproblematisch auch unter Windows auslesen lässt. Das wäre dann wohl mit NTFS als Dateisystem (zum Beispiel über rsync?).
Frei nach dem Motto: wenn ich mit meiner ZFS-Herumspielerei irgendwas grob verbockt habe /verbocken werde und mit den ZFS-Systemen nichts mehr hilft... Da bräuchte ich dann auch nicht die ganzen Unter-Versionen sondern eben nur den letzten Stand als "last resort".

 

[besterino]

Nach vielem Lesen bin ich wieder etwas schlauer:

In guter alter Windows/Linux-Manier habe ich natürlich zunächst auf dem Hauptfiler nur ein Filesystem auf dem Pool eingerichtet und darauf dann stumpf meine Daten - geordnet nach Verzeichnissen - kopiert. Entsprechend habe ich bisher dort auch nur Snapshots auf diesem einen Filesystem.

Dummerweise interessiert sich ja offenbar ZFS eher so wenig für Verzeichnisse, sondern ist nach Datasets bzw. eben Filesystems aufgebaut. Wenn ich das richtig verstanden habe, lassen sich mit send/receive als "kleinste logische Einheit" eben nur Datasets verarbeiten.

Um also über ZFS send/receive eine sinnvollere Auswahl treffen zu können, welche Daten (und wie oft) gesichert werden sollen, muss ich also meine Daten jetzt erst einmal in Datasets (neu) organisieren.

Macht aber nix, hatte eh vor mich mit der Organisation zu beschäftigen, da meine alte Verzeichnisstruktur inzwischen etwas in die Jahre gekommen ist und eine konsequente Stringenz mittlerweile wohl in Teilen vermissen lässt...

Bei der Gelegenheit kann ich dann auch einmal das Thema Doubletten angehen. Als nettes Tool habe ich dafür übrigens "fdupes" für mich entdeckt, dummerweise ist das txt-file mit den gelisteten Treffern nun nicht gerade klein... Nun hoffe ich noch, für gewisse Kategorien (z.B. Je nach Datentyp wie Music, Bilder usw) "batchfähige" Strukturen ausmachen zu können, welches File ich denn jeweils wo behalten will. Das würde dann das Aufräumen deutlich beschleunigen. Ein ersetzen der Doubletten durch (Hard)links hilft zwar, das Datenvolumen zu reduzieren, schafft aber eben keine bessere Ordnung (und außerdem habe ich noch keine Ahnung, ob/wie das mit den links dann ggf. später über unterschiedliche ZFS Filesystems hinweg funktioniert).

 

[fax668]

Warum bastelt sich eigentlich jeder irgendwelche Software zurecht anstatt eines der vielen gut funktionierenden Backupsysteme zu nehmen? Ich würde empfehlen, dass du dir Burp mal genauer anschaust. Ich persönlich benutze BackupPC, das wird allerdings nicht mehr aktiv weiter entwickelt. Ich hatte bisher nur noch nicht genug Gründe, auf Burp zu wechseln.

Zum Aufräumen benutze ich FSlint, das bedient sich ein bisschen komfortabler als fdupes.

 

[besterino]

Naja, "gut funktionierend" ist relativ. Tendenziell präferiere ich, die Anzahl der eingesetzten Tools und Programme möglichst gering zu halten. Daher will ich es eben mit den ZFS Bordmitteln mal probieren. Was Sun/Oracle da hingebastelt haben, finde ich jedenfalls zurzeit sehr beeindruckend / überzeugend.

Werde mir Burp aber trotzdem mal anschauen.

 

[besterino]

So, bin etwas weiter mit meinen Doubletten. Geht bestimmt auch einfacher, aber so konnte ich mich Stück-für-Stück vorarbeiten:

Eingesetztes Tool: "fdupes" (Kommandozeile). Vorab: ich wollte aus organisatorischen Gründen keine Links setzen.

1. Doppelte Dateien finden
Liste aller Doubletten in einem bestimmten Verzeichnis (einschließlich Unterverzeichnisse in Datei "dupes.txt" schreiben:

# fdupes -r VERZEICHNIS > dupes.txt

fdupes schreibt jeweils gleiche Dateien direkt untereinander. Blöcke werden durch Leerzeilen getrennt. Anmerkung: der Windows-Editor bekommt das mit den Zeilen aber nicht richtig hin - Wordpad klappt.

2. Doppelte Dateien kategorisieren
fdupes.txt sichten und nach Möglichkeit Kategorien identifizieren, welche Dateien behalten / gelöscht werden sollen.

2a) Auf jeden Fall beizubehaltene Dateien
Als erstes habe ich die Zeilen in der dupes.txt mit den Dateien gelöscht, die ich auf jeden Fall behalten will:

# sed -i '/.*VERZEICHNIS(TEIL).*DATEINAME(TEIL).*/d' dupes.txt

Es bleiben also logischerweise grds. die zu löschenden Doppel in der dupes.txt übrig/stehen.

2b) Auf jeden Fall zu löschende Dateien
Schwieriger war es, wenn es mehrere Treffer gab und dann auch noch mit völlig unterschiedlichen Verzeichnissen und mir daher nicht von vornherein völlig klar war, welche von 5 Dateien ich behalten möchte. Wenn man aber (so wie ich) z.B. so klassische "Sammel-Auffang-Verzeichnisse" hatte, kann man zunächst diese Sammel-Verzeichnisse entmüllen:

Dazu habe ich die entsprechenden Zeilen mit den "Sammel-Verzeichnissen" aus der dupes.txt zunächst in eine neue Datei "remove_BESCHREIBUNG.txt" verschoben.

# sed -i -e '/.*SAMMEL-VERZEICHNIS(TEIL).*/{w remove_BESCHREIBUNG.txt' -e 'd} dupes.txt

Anmerkungen:
In dem "sed-Befehl" ist .* ist ein Platzhalter, mit dem man auch mehrere Verzeichnis-/Dateibestandteile zwecks eindeutiger Identifikation kombinieren kann.

In dem "xargs-Befehl" gibt -d '\n' an, dass das Zeilenende das maßgebende "Trennzeichen" ist. Lässt man das weg, gab es bei mir mit Datei- bzw. Verzeichnisnamen Probleme, die Leerstellen oder Sonderzeichen enthalten.

2c) Ggf. Wiederholung 2a)
Nach einigen 2b)-Durchgängen konnte ich immer wieder bessere Entscheidungen treffen, welche Dateien ich denn wo behalten wollte.

3. Finales Aufräumen
Nach einigen Durchgängen blieb bei mir nur noch recht wenig in der dupes.txt übrig, was ich dann in der dupes.txt von Hand anpassen konnte (also Zeilen mit zu behaltenen Dateien rausgelöscht).

Jetzt hatte ich also mehrere "remove_XYZ.txt" Dateien und eine dupes.txt mit den insgesamt zu löschenden Dateien.

4. Löschen
Das Löschen selbst habe ich auch in zwei Schritten gemacht. Zunächst habe ich die Dateien in ein temporäres Verzeichnis verschoben (um das Ergebnis meiner Taten noch einmal anschauen zu können) und dann in einem zweiten Schritt gelöscht.

Verschoben habe ich mit:

# xargs -d '\n' -a remove_BESCHREIBUNG.txt mv -t /TEMPDIR
# xargs -d '\n' -a dupes.txt mv -t /TEMPDIR

Wie gesagt, schöner/besser/schneller geht bestimmt. Aber so konnte ich mit den verschiedenen angelegten Dateien und dem Temp-Verzeichnis immer stichprobenartig prüfen, ob das Ergebnis passt.

 

[besterino]

Mal was neues: Mein HP MS Gen8 läuft wieder, so dass ich hier mal wieder weiter frickeln kann.

Mit OmniOS bin ich aus folgenden Gründen nicht so wirklich happy: nur SMB1, HDD-Detection gerne mal daneben (512/4k Sektoren), Treiber-Support (meine USB3 Ports sind nur USB2) und Verwaltbarkeit außerhalb Napp-it. Da ich also eh neu installieren muss, insbesondere den Pool nicht weiter verwenden kann (habe natürlich den ZFS-Pool mit OmniOS-spezifischen Settings angelegt), kann ich also wieder etwas umfangreicher was Neues testen.

Wie der ein oder andere gemerkt hat, bin ich ja inzwischen doch ein gewisser Fan von Hyper-V (ich komm' mit ESXi einfach nicht klar). Meine Begeisterung dafür wurde aber zuletzt auf eine harte Probe gestellt: ich habe eine ganze Nacht versucht, mit einem "Server 2016 Technical Preview 2" einen guten alten 2012R2 Hyper-V Core remote zu administrieren (über ServerManager bzw. Hyper-V-Manager). Mein Fazit nach diversen Stunden: GEHT NICHT.

Warum soll's an dieser Kombi liegen? Habe heute einen "2016 Hyper-V Core Technical Preview 3" aufgesetzt und der lässt sich von der Technical Preview 2 administrieren ... was für ein Scheiß, aber naja - Lehrgeld halt.

Immerhin habe ich bei der Gelegenheit herausgefunden, dass sich die Technical Preview 3 (im Gegensatz zur "2") wieder wie die Vorgänger auf einem USB-Stick installieren lässt.

Derzeitiger Zwischenstand also: Hyper-V Core "2016 Technical Preview" läuft erfolgreich auf einem USB-Stick. Jetzt will ich aber doch noch einmal probieren, ob man nicht doch irgendwas Solariodes unter Hyper-V zum Laufen bekommt...

UPDATE: höhö... Solaris 11.3 Beta "erfolgreich" unter Hyper-V installiert.
Aber 1: Maximum 4 HDDs, da nur 2xIDE-Kontroller mit je 2 Anschlüssen (also nur 3 Datenplatten nutzbar wegen OS-Platte)
Aber 2: Nur legacy Network Controller, d.h...
Aber 3: ...Schreibperformance über die Gigabit-Anschlüsse bei ~12MB/s (3x1TB im RaidZ). Iperf kommt selbst auf der 10Gbe-Strecke auch nur auf magere ~90Mbit/s - passt also und "Legacy Network Controller" entspricht offenbar einem 100Mbit-Netz. Das macht keinen Spaß...

 

[affabanana]

Schau unter der Windows die Netzwerkkarte an. Dort gibts einen Punkt broadcom q... Diesen mal Ausschalten.
Das Problem hatte ich schon häufig.
Wird beim Hyper-v core vieleicht schwierig, da keine GUI

 

[besterino]

Ich habe in der letzten Zeit mal wieder gefrickelt. Ich hatte nach dem Umbau bzw. Upgrade meines kleinen HP Microserver G8 einen Celeron G1610T übrig, den wollte ich nicht so liegen lassen. Also flugs günstig ein Intel S1200BTLR geschossen (teilweise Fehlkauf: VIEL ZU LAUT ohne Intel-Gehäuse/Lüfter), ein Inter-Tech 2U (ganz ok, mal abgesehen davon, dass sie das USB-Header-Kabel irgendwie verfummelt haben) angeschafft und mit RAM und ein paar NICs & Co. bestückt. Soweit so gut.

Außerdem bin/war ich mit der Situation unzufrieden, dass ich meine leistungsfähigste Maschine (T20) allein als Fileserver vergeude und ich doch eigentlich noch einen Hypervisor zum Rumspielen und einen Backup-Filer "brauche".

Dummerweise spielt mein Mein Lieblings-hypervisor (Hyper-V) nicht gut mit Solaris-Gästen. Mit ESXi werde ich persönlich nicht warm. Also musste eine Alternative her...

...und da habe ich mal mit Solaris+Openstack herumgespielt. Puh, das ist mir zurzeit noch zu kompliziert.

...also mal Oracle VM Server angedacht, aber 1. lädt der immer noch runter und ist 2. offenbar XEN-basiert, also kein ZFS nativ...

...und dann kam die Idee: warum denn eigentlich nicht VirtualBox? Hatte ich unter Windows doch gute Erfahrungen mit gemacht! Also, flugs Solaris 11.3 + Napp-it + Virtualbox installiert und... ach da war ja was. Kein GUI. Dann ist Virtualbox konfigurieren ja eher nicht so toll. Die Idee, einfach einen solaris desktop nachzuinstallieren, fand ich zunächst ganz pfiffig. Bis ich dann feststellte, dass der Grafik-Chipsatz des Intelboards wohl nicht von Solaris unterstützt wird... (ein Gegentest mit einer Nvidia-Karte funktionierte). Also doch mit der Konsole. Dank diesem netten Kollegen mit seinem HowTo habe ich aber den "proof of concept" hinbekommen: meine alte LinuxVPN-VM habe ich erfolgreich vom Hyper-V auf virtualbox@Solaris11.3 migriert.

Jetzt muss es mir noch gelingen, irgendwie ein GUI von Virtualbox zum Laufen zu bekommen. Mal schauen, vielleicht klappt's ja auf Basis dieser Anleitung... Dann probier ich vielleicht auch noch mal, wie ich Virtualbox in einer eigenen Solaris-Zone laufen lasse, von wegen Funktionen sauber trennen und so. Naja, das war jedenfalls 'ne steile Lernkurve in den letzten Tagen. Von Solaris bin ich jedenfalls immer noch ziemlich angetan.

Nachtrag: das Intel S1200BTRL wird mit 'nem Intel-Boxed Kühler auf dem Celeron und 3x Noctua NF-A8 PWM im 2U-2098-SL quasi wohnzimmertauglich. Nice.

 

[besterino]

Yeah Baby!



Gut, die Kiste ist jetzt wahrscheinlich offen wie ein Scheunentor und verwundbar ohne Ende, aber hey...

Weiterführende Links:
http://b0zmeister.x10host.com/virtualbox-in-a-solaris-zone-the-tried-tested-reliable-way/
https://www.virtualbox.org/manual/ch09.html#vboxwebsrv-solaris
http://xmodulo.com/how-to-manage-virtualbox-vms-on-remote-headless-server.html

 

[besterino]

Für den Fall, dass einmal jemand Solaris 11.3+ZFS+Napp-IT+Virtualbox nachprobieren will: Gute Basis ist die Solaris 11.3 Live CD mit dem Solaris Desktop, weil man sich damit die Frickelei der "Headless"-Konfiguration sparen kann. Außerdem kann man sich das Ganze so mal anschauen, ohne das Hauptsystem zu gefährden.

Viele hier haben ja den HP Proliant Microserver Gen8 hier, mit dem funktioniert die Solaris 11.3 Live CD wunderbar.

Kleine Installationsanweisung für VirtualBox 5.0.10 unter der Annahme, das Solaris 11.3 von der Live-CD installiert wurde (Napp-it schadet natürlich auch nicht, allerdings lüppt der Websocket / Monitor wohl bei der Live-CD nicht out-of-the-box):

1. Terminal öffnen und darin:

# wget http://download.virtualbox.org/virtualbox/5.0.10/VirtualBox-5.0.10-104061-SunOS.tar.gz
# gunzip -cd VirtualBox-5.0.10-104061-SunOS.tar.gz | tar xvf -
# sudo pkgadd -d VirtualBox-5.0.10-SunOS-amd64-r104061.pkg 

//mit Enter für "all" bestätigen
//Wenn das Installations-Skript fragt, mit "y" bestätigen

# sudo usermod -G vboxuser DEIN_USERNAME // nicht zwingend, aber wohl für bestimmte USB-Funktionen nötig

// Optional, aber wo wir gerade dabei sind, installieren wir auch das Extension Pack:

# wget http://download.virtualbox.org/virtualbox/5.0.10/Oracle_VM_VirtualBox_Extension_Pack-5.0.10-104061.vbox-extpack
# sudo VBoxManage extpack install ./Oracle_VM_VirtualBox_Extension_Pack-5.0.10-104061.vbox-extpack

2. VirtualBox starten
GUI-->Applications-->Run Application-->"VirtualBox" (ohne "") eintippen. / Alternativ im Terminal: "VirtualBox" (ohne "") eintippen


3. Weiterführende Links:
VirtualBox Downloads
VirtualBox Manual

 

[besterino]

Da man bei dem kleinen HP ja sehr schön sein OS (sprich: den USB-Stick) auswechseln kann, fehlte mir nach Hyper-V, ESXi, Solaris/Virtualbox noch... genau (neben Proxmox): u.a. der aktuelle Oracle VM Server als Hypervisor in meinem Testparcour. Dieser Hypervisor basiert auf Linux/Xen und ist damit noch einmal ganz was anderes als das, was ich bisher ausprobiert habe.

Im Gegensatz zu ESXi, wo man - zum Beispiel - den Hypervisor über den vSphere-Client unter Windows administrieren kann, braucht man beim Oracle VM Server einen ganz speziellen Client als "Komplettinstallation": vorzugsweise aus Basis der hauseigenen Linux-Distribution "Oracle Linux". Und da darf man auch nicht die aktuellste Fassung (Version 7) nehmen, sondern muss eine 6er-Version installieren...

... nur damit dann darauf ein Web-backend läuft, auf das ich dann über einen Webbrowser (im Zweifel von einer 3. Maschine aus) zugreife - bei eine empfohlenen Mindest-RAM-Größe von schlappen 8GB nur für Hypervisor-Management. (Tipp: Login ist "admin" und PW das beim Aufruf des VM Managers "für alles" vergebene Passwort.)

Für den Heimgebrauch ist die Oracle Hypervisor-Management-Interpretation also recht sportlich, man merkt die Ausrichtung auf größere IT-Landschaften. Das Webfront-end zeigt sehr übersichtlich diverseste Details der einzelnen Server und ist auf die Verwaltung mehrerer Server ausgelegt. Mein ZFS-Filer mit einer NFS-Freigabe wurde auch sofort gefunden und eingebunden.

Da man @home ja nicht permanent an den virtuellen Maschinen herumdoktort, bietet sich aus meiner Sicht die Installation der "Management-Maschine" als VM an - nur doof, dass man ja gerade (regelmäßig) erstmalig einen Hypervisor einrichtet... Zum Glück habe ich noch meinen 2. Server mit Hyper-V und mein Erstaunen war groß: Oracle Linux 6.7 läuft out-of-the-box auf dem Hyper-V (Preview 4) als Gen2-VM inklusive Networking. Nice.

Dummerweise ist es damit noch nicht getan, sondern man muss die Landschaft insgesamt wohl konfigurieren. Mal eben schnell eine VM anlegen "is nich". Ich muss mich jetzt noch mit den Repositories (nach meinem Verständnis Datenstrukturen für die Server/Hypervisoren und auch die darauf laufende VMs) beschäftigen, Server-Pools und die Zuweisung "unassigned Servers" verstehen, weiteren (lokalen?) Speicherplatz auf meinem Hypervisor einrichten und dann kann's vielleicht irgendwann mal mit VMs losgehen...

Ach, Windows 10 Gäste werden offiziell wohl auch noch nicht unterstützt... :-D

Update: ich habe Orcale VM Server wieder runtergeschmissen... für meine Zwecke zu viel Aufwand für 0 Mehrwert. Nutze zurzeit wieder ESXi als Basis für die Backup-Box...

 

[besterino]

Vorläufiger Zwischenstand des Fileserverkonzepts:

Kann es mir gar nicht so richtig erklären, irgendwie sind es jetzt doch drei Kisten geworden.

Server 1 ist der Haupt-Filer auf Basis eines Intel S1200BTLR mit dem Celeron G1610T (aus dem Microserver unten als Server 2), mit 16GB ECC RAM und 4x4TB WD Red (RaidZ) plus 4x256GB Consumer SSD (ADATA) an onboard SATA und 'nem LSI 9207 4e4i mit Solaris 11.3 plus napp-it und x540-T2 für die Anbindung. Hab mir dafür auch noch so'n Intel RMM4 Kit mit 3. RJ45-Port für die Fernwartung gegönnt, damit kann ich die Kiste zur Not ähnlich wie über HPs ILO steuern.

Server 2 ist der Back-up Filer auf Basis des HP Microserver Gen8, allerdings umgerüstet auf Xeon 1220L (v1), auch 16GB ECC RAM und mit ESXi 6 plus 'nem alten Supermicro HBA für die StorageVM, diese wiederum mit Solaris 11.3 mit napp-it und einer durchgereichten 8TB Seagate Archive (solo) als primär Backup (mittels dank napp-it automatisierte regelmäßige ZFS send/receive replikation) und ner Seagate Enterprise 3TB (auch solo) als sporadisches Sekundärbackup nach Lust und Laune.

Server 3 ist der Haupt-Hypervisor auf Basis des Dell T20, Xeon E3-1225v3, 32GB ECC RAM mit Hyper-V 2016 TechPreview4, inzwischen gefleddert was HDDs angeht bis auf seine Boot SSD (auf der nur noch die kritische/wichtige VPN Linux VM liegt, mit 4GB Platzbedarf verschmerzbar) und zwei alten 2TB HDDs im offline-modus als "NTFS old school last line of back-up-defense" sollte ich mal irgend etwas auf den ZFS Pools so richtig verfummeln.

Jetzt lass ich das mal so ein paar Wochen laufen.

Zuletzt war ich etwas skeptisch geworden, da ich wohl nicht der einzige war, bei dem ZFS Pools Speicherplatz "gefressen" haben (also verbraucht bzw. nicht wieder freigegeben je nach Verwendung, immerhin nichts "weg" oder kaputt). Das war bei mir wahrscheinlich die Kombination aus ZFSonLinux plus Replikation über OmniOS hin zu Solaris (erst 11.3 beta dann final), will ich aber mal im Auge behalten.

Damit ist aber die ToDoListe noch nicht abgearbeitet. Server 2 (inkl. VM) soll eigentlich weitgehend "aus" sein und nur 1x pro Woche von Server 1 für die Replikation automatisch (oder nach Bedarf manuell) geweckt werden und sich nach der Replikation wieder schlafen legen.

Außerdem könnte ich nochmal überprüfen, ob ich wirklich einen Hyper-V Host brauche. Denn wenn nicht und ich werde mit ESXi dauerhaft happy, könnte ich die VMs von Server 2 und 3 ja auf einem Metall (T20) zusammen führen und den schwächeren Server 2 abbauen. Der hat zurzeit nur eine Kopie der VPN VM als einzige weitere VM, für den Fall dass der T20 mit seiner Technical Preview rumzickt (oder von mir versehentlich verfummelt wird)...

Jetzt juckt noch die VM Replikation in den Tester-Frickler-Fingern und AD wollte ich mir evtl auch nochmal anschauen, aber das hat mit dem Topic bzw. der Hauptproblemstellung eher nichts mehr zu tun... ;-)

Schon nett, was so alles geht und man in recht kurzer Zeit dabei so lernen kann. Danke auch an dieser Stelle natürlich an alle, die in den verschiedenen Sammlern so viel Zeit reinstecken und Hilfestellung/Anregungen geben!

 

[besterino]

Sorry, ich mal wieder:

Habe soeben (scheinbar, s.u.) erfolgreich eine Replikation von meinem "T20/Haupt-Hyper-V" auf einen testweise eingerichteten "ESXi nested Backup-Hyper-V" auf dem HP Microserver Gen8 eingerichtet.



Beste Anleitung dazu für Nicht-AD sondern Workgroup-Server

Was nämlich üblicherweise in den HowTos vergessen wird: bei (nur) Workgroups muss man die zertifikatbasierte Authentifizierung einrichten, sonst klappt es nicht.

Konzeptionell schon geil. Allerdings steht der Desaster-Test noch aus - traue mich nicht remote die VM abzuschießen, da es sich um meine VPN-VM handelt!

Haha... EDIT/Nachtrag/Ergänzung da mal wieder nicht sorgfältig recherchiert: Replikation beinhaltet mitnichten den automatischen Failover-switch einer VM von einem Hyper-V Host zum anderen. Replikation stellt nur sicher, dass ein (halbwegs) aktuelles Image von der VM auf beiden Hyper-V Hosts liegt, damit man die Kopie-VM im Desaster-Fall manuell starten kann. Das hilft natürlich bei der VPN-VM mal so gar nicht, wenn man gerade nicht im Heimnetz sitzt...

Wahrscheinlich wäre wohl ein Cluster die richtige Wahl dafür gewesen... Mal schauen, ob ich das auch noch ausprobiere, denn im Gegensatz zu Server 2012R2 kann Windows Server 2016 ein Cluster nicht nur in der Domäne sondern auch in der Workgroup (!) aufsetzen:

In Windows Server 2012 R2 and previous versions, a cluster could only be created between member nodes joined to the same domain. Windows Server 2016 breaks down these barriers and introduces the ability to create a Failover Cluster without Active Directory dependencies. Failover Clusters can now therefore be created in the following configurations:

Single-domain Clusters: Clusters with all nodes joined to the same domain
Multi-domain Clusters: Clusters with nodes which are members of different domains
Workgroup Clusters: Clusters with nodes which are member servers / workgroup (not domain joined)

Coolio.

Folgeüberlegung:
Da meine Kisten allerdings von Power sehr unterschiedlich sind, hätte ich eigentlich lieber einen Schwenk nur für den Fall, dass die VPN-VM down ist. Kann man das bei einem Cluster einstellen? Anstatt eines Clusters würde doch eigentlich auch ein Skript reichen, dass z.B. alle 5 Minuten den Status der VPN-VM checkt (z.B. mit einem Ping an die VPN-VM?) und im Falle des Time-outs die Failover-VM startet. Wichtig wäre dann allerdings auch, dass die Failover-VM dann wieder down geht, sollte die Primäre VM wiederkommen. Warum? Die VMs müssen zwingend eine identische IP haben und wenn beide laufen gibt das ja Ärger... Also müsste man wahrscheinlich das über ein Powershell query auf dem primären Hyper-V abfragen, der trotz zwei identischer IPs ja noch erreichbar sein müsste... Oder hab' ich da einen Denkfehler? Geht das überhaupt? Wie läuft das sonst?

 

[besterino]

Merkposten: damit Hyper-V im ESXi läuft, muss man

1. in der vmx-Datei der Hyper-V VM am Ende folgenden Code eintragen:

hypervisor.cpuid.v0 = "FALSE"
vhv.enable= "TRUE"

2. wenn man den Hyper-VMs auch eine Anbindung nach "draußen" gönnen will und das über einen oder mehrere virtuelle ESXi-Switches (und nicht durchgereichte NICs) macht, dem ESXi-vSwitch den promiscious mode erlauben:

Im vSphere Client zu finden unter Host-->Konfiguration-->Netzwerk-->Eigenschaften beim entspr. vSwitch


3. natürlich in Hyper-V noch den virtuellen (Hyper-V) Switch noch über die entsprechende virtuelle NIC an den virtuellen ESXi-Switch anbinden, z.B.:


4. Wenn die VM dann immer noch keinen Zugang nach draußen hat, hilft wohl manchmal noch in den Einstellungen der Hyper-V Gast-VM bei der Netzwerkkarte MAC Spoofing aktivieren:


Um meine ESXi--Hyper-V--Ubuntu-VM anzubinden, musste ich aber nur Schritte 1-3 vornehmen.

 

[besterino]

Ok... Hyper-V Failover-Cluster läuft.

Da ich (immer noch) keine Domäne hab, ist für mich die besondere Herausforderung beim Einrichten des Clusters der Umstand, dass die GUI des Failover Cluster Managers leider noch nicht vollständig für einen Workgroup-basierten Cluster funktioniert. Also muss man vieles - was sonst in einer Domänenumgebung über charmante Clicks ratzfatz erledigt ist - mit Powershell Befehlen bauen. Das gilt jedenfalls für die ersten Cluster-spezifischen Schritte. Wenn man den Cluster einmal aufgesetzt hat, funktioniert aber die GUI in großen Teilen, komischerweise.



Inzwischen ist es mir gelungen, zwei (lokale) VM's in "High Availability Cluster VMs" umzuwandeln. Lassen sich auch prima per quick-migration von Host A <--> Host B herumschubsen. Nur live migration funktioniert leider wirklich noch nicht (s. Fehlermeldung bei der Windows-VW im Screenshot oben).

Hilfreiche Links:
Workgroup Clusters in Windows Server 2016 (Workgroup Cluster-Installation)
Deploy a Hyper-V Cluster (enthält die wichtigen Powershell-Befehle für Hyper-V Management im Cluster)

i-Tüpfelchen: die clustered VMs liegen alle auf einem ZFS-iSCSI-Storage, dass seinerseits nochmal mit ZFS send/receive repliziert wird (allerdings ohne automatische failover-Funktionalität).

 

[besterino]

Nachtrag: offenbar führt der Altersunterschied zwischen dem Xeon E3-1220L der ersten Generation im Microserver im Vergleich zu dem E3-1225v3 im T20 schon dazu, dass die VM so nicht den Host wechseln will.

Also muss ich in den VM-Einstellungen im Failover Cluster Manager unter "Processor" den Haken bei "Migrate to a processor with a different processor version" setzen. Dann läuft es. Heureka!

Finally mission accomplished:

1. Storage-Konzept:
ZFS-Mainstorage mit Backup über ZFS send/receive Replikation auf ESXi "hosted" ZFS-Backup-Storage: inkrementelles Datenbackup 1x pro Woche "über alles"

2. Hochverfügbarer Fernzugang:
Hyper-V Hosted VPN-VM mit "Backup" (bzw. high availability) im Failover-Cluster mit ESXi "hosted" Hyper-V Backup: automatischer Schwenk der VM von Host A <--> Host B bei Ausfall des aktiven Hosts.

Zurzeit realisiert mit ESXi 6 (mit der freien Lizenz) und Server 2016 Technical Preview 4.

Schöne neue Welt.

 

[besterino]

Da mir gerade an anderer Stelle aufgefallen ist, dass das hier nicht mehr ganz aktuell ist:

Inzwischen umgestellt auf Selbstbau-ESXi6U2+Solaris-NappIT-VM als Hauptfiler und Dell T130-ESXi6U2 mit 1x Solaris-NappIT-VM als Backup/Replication-VM und 1x Hyper-V-VM im Failover-Cluster mit dem T20 als Haupt-Hyper-V mit der VPN-HAVM.

 

[sp0tt]

Hallo bestrino, ich habe deine Historie nachverfolgt und fand es interessant. Deine Ausgangssituation konnte ich nachvollziehen, habe am Ende aber den Faden verloren und will nochmal kurz nachfragen:
Kannst du bitte nochmal erklären wieviel Metal jetzt rumsteht, ob und welcher hypervisor darauf läuft, ob du den fileserver und backupserver virtualisiert hast wie du deine vms auf den backupserver sicherst und wie du die Files vom fileserver auf den backupserver sicherst?

Mein szenario:
ich will Daten wie Dokumente und Fotos zentral von 4 Clients speichern können und außerdem Filme über einen Plex Media Server bereitstellen. Insgesamt sind das ca. 3TB Daten. Zusätzlich brauche ich einen Ort für das Backup dieser Daten.

Ich schrecke davor zurück fileserver zu virtualisieren. Daher müsste ich theoretisch 3mal Metal kaufen: für den fileserver, für einen Application Server mit hypervisor und den backup Server.

Vor einem Jahr hattest du ja den Filer noch als hyper v vm mit ubuntu und zfs filesystem bereitgestellt. Kann man das so machen oder kommt zfs mit virtualisiertem Speicher nicht klar?

 

[besterino]

Klar, kein Probolem.

Also... im Prinzip ist das letzte Posting noch aktuell, d.h. meine "Haupt-Fileserver-Umgebung" besteht aus dem Selbstbau-Server (Main-Filer) und dem T130 (Backup-Filer), zu Details der Hardware siehe meine Signatur. Beide laufen mit ESXi 6U2 als "OS" und darin virtualisiert ist jeweils eine Solaris Storage VM (+ Napp-it). Die "Backup-VM" repliziert über die in Solaris/ZFS bereits eingebaute Funktion in regelmäßigen Abständen die wesentlichen "Speicherorte".

Die Backup-VM frisst natürlich fast keine Ressourcen, da die nix tut außer rumidlen bis der Replikationsjob anläuft. Das einzige was die Storage-VM unter ESXi sinnvoll braucht ist ein dedizierter HBA, idealerweise von LSI, damit Du den sauber in Solaris zur Verfügung stellen kannst.

Jetzt stellt sich die Frage, was genau Du vor hast. Im Prinzip hast Du je nach Konfiguration des Backup-ESXi dort die Möglichkeit, auch die Applikations-VMs laufen zu lassen. Auf dem T130 lasse ich zum Beispiel gerne mal noch einen virtualisierten Hyper-V Host rennen, um irgendwelche Faxen auszuprobieren. Mein T20 ist ein dedizierter Hyper-V Host (fast ohne eigenes Storage) als "semi-produktiv"-Kiste und der HP Gen8 ist die Test-Kiste für größere Abenteuer. Beide (also T20 und Gen8) brauche ich eigentlich nicht wirklich. Der Gen8 ist zu 99.9% zurzeit aus.

 

[sp0tt]

Perfekt danke dir, verstanden! Ich habe am Wochenende jetzt angefangen zu konfigurieren und bin jetzt recht schnell dazu gekommen, dass ein dedizierter HBA wirklich die bessere Lösung ist.
Im HP Gen8 Thread habe ich diesbzgl. eine Frage gestellt, die ich dort weiterverfolgen will. (Kompatibilität und Passthrough).