Das Forum wurde aktualisiert. Wurde höchste Zeit. Wenn etwas nicht funktioniert, bitte gerne hier jederzeit melden.
(Das "alte Design" kommt wieder, wird ne Weile brauchen!)

Shared Storage Planung

ESX(i)-taugliche Hardware, HCL .....

Moderatoren: irix, continuum, Dayworker, Tschoergez

Member
Beiträge: 22
Registriert: 01.10.2016, 22:01

Shared Storage Planung

Beitragvon josch12 » 02.11.2016, 11:59

Hallo,
für 2017 soll es ein neues Shared Storage für unsere Spielwiese mit derzeit 5 ESXI Server geben,
könnte aber einige Tipps bei der Planung gebrauchen ;)

Budget 1,5 K
Platzbedarf derzeit c.a 3 Tb

Folgende Umgebung:

5 ESXI Sever
200 - 250 kleinere Vmware Server
10-15 VDI

das ganze soll per ISCSI angebunden werden.

Wir hätten die Möglichkeit relativ günstig an ein HP ProLiant SE326M1 G6 heran zukommen,
mit folgernder Ausstattung:

1x 2.4 Ghz Hex Core Xeon ( E5645)
64 Gb DDR Ram
2x 1Gbs/s onboard
1x Dual Port 4Gb/s FC Karte
25 Platten Schächten 2,5 Zoll
für etwa 400 €

zu Beginn 5x 1TB SSD Festplatten im Raid5 , das bei Bedarf erweitert werden soll.
Als Raid Controller wird ein HP P410i mitgeliefert.


Als Software Openfiler, Starwind, Napp it ?

würde für mein Vorhaben 3 Controller benötigen ?, mit jeweils 2 Anschlüssen

Experte
Beiträge: 1233
Registriert: 30.03.2009, 17:13

Beitragvon UrsDerBär » 02.11.2016, 18:25

Also ich würde ja RAID 10 machen mit SSD's =)
Gehe mal davon aus, dass es eher günstige SSD's sind bei dem Budget. Diesind leider fast immer von ziemlich schlechter Regelmässigkeit punkto Latenz. Eine eng gestreute Latenz ist aber sehr wichtig wenn ein RAID mit SSD's wirklich die geünschte Leistung bringen soll.

Da wird dann ziemlich viel Speed verschenkt. Würde da eher auf RAID1 gehen und die Volumes z.B per Software-RAID zu einem Volume zusammenhängen/stripen. Bei RAID 5 ist bei einigen günstigen Discs fast immer irgend eine Disc grad *lahm*.

Bezüglich iSCSI:
Wenn es iSCSI sein soll, dann besser nicht Microsoft-Target sondern z.B. das von Starwind. Das sind Welten in der IO-Performance und Nutzung der Systemressourcen wie RAM, CPU und LAN-Bandbreite. Das MS-Target cached leider gar nix. Weder Read noch Write. Wobei man mittlerweile erzwingen kann, dass Disc-Cache genutzt wird (mit entsprechenden Risiken).

Starwind nutzt dagegen was man ihm geben möchte bzw. was das System kann. Wenn man so aktuelle Specs ansieht, ist die Lösung schon recht umfangreich geworden. Bis hin zu vSAN.

Mit reinen Bordmitteln würde ich NFS mit aktiviertem Dedupe verwenden. Dedupe-Blocks werden meines erachtens auch ohne Cluster in den RAM-Read-Cache des OS genommen. Andere Blocks nicht so wirklich. Oder gleich dem System beibringen, dass es sich bei den lokalen Discs um Shared Storage handelt und nen Single-Node-Cluster bauen. Habe ich physisch aber noch nicht versucht sondern nur als Storage-App mit Paravirtual-Controller unter ESXi.
Dann kann man den Volumes die gewünschte Menge RAM direkt als Read-Cache zuweisen.
Oder eben grad eines der ZFS-Linux-Derivate.

Member
Beiträge: 1
Registriert: 03.11.2016, 21:22

Beitragvon Net Runner » 05.11.2016, 11:27

RAID5 für 200-250 virtuelle Server wird zu langsam sein. Auch wenn’s nur kleinere sind. Also RAID10 wäre doch besser. Und für VDI dann bestimmt. Das kannst du ja aber immer ändern. Also ich würde dann mit RAID5 starten um Geld zu sparen, und falls es doch nicht schnell genug ist auf RAID10 springen.

iSCSI ist total OK. Block, schnell und zuverlässig. Funktioniert auch total gut mit ESXi.

Starwind ist sehr gut für den Zweck. Schnelles iSCSI mit RAM Caching. Auch wenn Du eines Tages einen zweiten Server kriegst und ein Fehler-tolerantes System schaffst dann ist es mit Starwind nur in 5 Minuten zu einrichten. Und es ist VMware zertifiziert.

Linux oder FreeBSD mit ZFS ist auch sehr gut. Da muss man aber ganz bekannt mit dem System und File System sein.

Benutzeravatar
King of the Hill
Beiträge: 12011
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 05.11.2016, 13:35

iSCSI ist okay, aber auch etwas kritisch von der Latenz. Das iSCSI-Target sollte bereits ansprechbar sein, bevor der ESXi fertig gebootet hat. Klappt das nicht, verwirft der ESXi das Blockdevice. Mit NFS dagegen verhält sich jeder ESXi wesentlich toleranter.

Willst du ZFS optimal einsetzen, empfehle ich Linux und BSD zu meiden. Auch wenn dort ZFS per ZoL als Kernelmodul realisiert ist, bei Solarish/Solaris ist es Teil des Betriebssystems und hat damit zwei entscheidende Vorteile. Punkt 1 ist die fehlende, die Performance verringernde Kompatibilitätsschicht, denn ZFS ist native für Solaris entwickelt worden und einige Calls des Subsystems müssen erst auf den Linux-Kernel umgesetzt werden. Punkt 2 ist, daß ein Kernel-SMB high performance Server mit Windows Share/File ACL direkt ins Betriebssystem integriert ist. Damit entfällt beispielsweise die gesamte Samba-Config, aber auch AFP, FTP, NFS oder WWW als dateibasierte Freigaben sind bereits Bestandteile des Betriebssystems.
Unter http://napp-it.org/features.html ist eigentlich alles aufgelistet, was ZFS so anbietet und mit "napp-it" gibts eine schicke Oberfläche dazu. "gea" hat hier im Forum im Thread ESXi 6.0/5.5/5.1 + ZFS/OmniOS/napp-it All-IN-ONE VM seine Lösung präsentiert.

Member
Beiträge: 22
Registriert: 01.10.2016, 22:01

Re: Shared Storage Planung

Beitragvon josch12 » 07.11.2016, 05:06

Danke für die Tipps,
hatten bischen Hardware "Über" und haben ein Raid10 mit 4x 4TB Platten und mit einer 250Gb SSD als Cache gebaut
und dem Raid Controller ne Battery spendiert.

Aktuell noch als Software mit Freenas, das Storage stand bereits im RZ ;)

werde die Tage einige Tests mit NFS und ISCSI durchführen, das sollte dann hoffentlich funktionieren, bis mehr Budget zur Verfügung steht :D

Member
Beiträge: 22
Registriert: 01.10.2016, 22:01

Re: Shared Storage Planung

Beitragvon josch12 » 04.01.2017, 13:35

Hallo,
muss das Thema noch einmal aufgreifen, und möchte euch vorstellen, was ich mir an Hardware zusammengestellt habe,

Anforderung ist eine gute Performance und Low Budget.

Hardware:

Server: HP ProLiant SE326M1 Storage Server 2x Xeon L5520 Quad Core 2.27 GHz
Ram: 128 GB Ram
Controller: LSI 6G SAS Dual Port Host Bus Adapter / HBA - 2x internal SFF-8087, PCI-E x8 - SAS9211-8i
10GB/S Receiver: Finisar 10 Gbit/s SFP+ Modul / Transceiver - Short Wave, 850 nm - FTLX8571D3BCL
10GB/s Karte: HP Mellanox ConnectX-2 Single Port 10 Gbit/s Server Adapter / Netzwerkkarte PCI-E - 671798-001

Festplatte:
Als Festplatten sollen Samsung 1TB SSD zum Einsatz kommen im Raid 10, die 128 GB Ram sollen dabei als Cache zum Einsatz kommen.


Software:

http://www.napp-it.de/

bin über euer Feedback gespannt.

Hardwarekosten ohne Festplatten: 750€

Benutzeravatar
King of the Hill
Beiträge: 12011
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Re: Shared Storage Planung

Beitragvon Dayworker » 04.01.2017, 15:21

Die Nehalem-Generation war Intels erste CPU mit internen Speichercontroller, ist schon deutlich älter und als 60W-Version auch stark im Basis-Takt eingeschränkt. Als reine Storage-CPU reicht dir im Grunde auch eine CPU und darüber lasen sich bis zu 144GB an DDR3-800/1066 anbinden. Ob das jedoch noch mit 1066er Frequenz möglich ist oder zwangsweise auf 800MHz runtergefahren wird, mußt du selbst nachschlagen. In dem Falle würde die zweite CPU einen Sinn machen, allerdings gibt es das nicht für Null Energie. Pro CPU würde ich dort mit 50W im Leerlauf rechnen und weitere 50W dürften für die restliche HW anfallen.

Wenn du Napp-it einsetzen willst, würde ich mich nicht auf Raid10 versteifen. ZFS hat aufgrund eines anderen internen Aufbaus kein sogenanntes Write-Hole, was auch andere Raid-Level bzw deren ZFS-Pendants ohne Einbrüche in der Performance ermöglicht. Du kannst natürlich auch ein Raid10 über ZFS nachbilden, dazu gibts unter https://calvin.me/create-zfs-raid-10-array-napp/ eine bebilderte Anleitung. Aber wozu mit Raid10 die Kapazität der teuren SSDs halbieren, wenn du auch mit weniger Verschnitt dieselbe Performance haben kannst...

Member
Beiträge: 22
Registriert: 01.10.2016, 22:01

Re: Shared Storage Planung

Beitragvon josch12 » 05.01.2017, 06:58

Hallo,
es freut mich natürlich, wenn ich beim " Raid " am Platten Platz sparen kann,
die Große Frage NFS oder ISCSI, da streiten sich ja die Geister ;), wie würdest du hier anbinden ?

Experte
Beiträge: 1727
Registriert: 23.02.2012, 12:26

Re: Shared Storage Planung

Beitragvon ~thc » 05.01.2017, 08:05

Vorteile NFS:
- toleranter bei vorübergehender Nichterreichbarkeit
- Einfach einzurichten, reine Softwarelösung
Nachteile NFS:
- Kann nur als Datastore genutzt werden, da "nur" virtuelles Dateisystem
- Alle VMDKs sind immer "thin"

Vorteile iSCSI:
- bietet als Blockdevice mehr Möglichkeiten (RDM, Datastore)
- VMDKs in allen Formen
- spezielle iSCSI-Hardware-Adapter oder VMWare-iSCSI-Software-Adapter nutzbar
Nachteile iSCSI:
- empfindlich bei Nichterreichbarkeit, insbesondere beim ESXi-Start
- Komplexere Einrichtung, iSCSI-Sprachumfang mancher Targets unzureichend

Das sind so die Dinge aus meinem Bereich. Wer noch etwas ergänzen möchte - gerne.

Experte
Beiträge: 1233
Registriert: 30.03.2009, 17:13

Re: Shared Storage Planung

Beitragvon UrsDerBär » 05.01.2017, 10:51

Ein weiterer Nachteil von NFS ist der Single-Path zum ESXi. In der Theorie ändert das wohl mit NFS 4.1 aber das gibt noch einiges an Einschränkungen in Verbindung mit ESXi. Soweit mein aktueller Stand, habe das nicht wirklich verfolgt in letzter Zeit.

Allerdings ist NFS sehr tolerant, wenn also ein Storage bzw. Pfad wegknickt und ein paar Sekunden für ein Path-Failover verloren gehen und nicht gerade extrem viele iops anstehen die ESXi nicht puffern kann, dann laufen die VM's munter weiter und die iops werden bei wiederereichbarkeit auf das Storage geschrieben.

Ein weitere Punkt von NFS sind noch die einfachen Fileoperations direkt auf Storage-Ebene. Sprich man kann Datensicherungen z.B. direkt auf Storage Ebene machen wenn das zugrunde liegende OS entsprechende Möglichkeiten bietet. --> Einer der Gründe warum ich dazu Windows mag.
Kann zugleich auch ein Sicherheitsrisiko sein, weil die Versuchung gross ist, die Kapselung des Storage-Bereiches etwas aufzubrechen. Dann hat man relativ easy Zugriff auf die kompletten VM's.

Weiterer Nachteil iSCSI: Viel intoleranter bezüglich ungeplantem wegknicken des Storage. Unter Umständen ist nachher der Datastore unbrauchbar. NFS ist da so tolerant wie das zugrunde liegende Filesystem.

Insofern gibt es bei beiden Systemen so viele Vor und Nachteile, dass man es als eigenen Geschmack oder die entsprechende Anforderung abtun kann. ;)

Member
Beiträge: 261
Registriert: 13.05.2009, 13:53
Wohnort: HH

Re: Shared Storage Planung

Beitragvon Borg-HH » 05.01.2017, 12:18

Hab mir auch zum "spielen" ein Storage aufgesetzt, nachdem ich mehrere NAS Distributionen durchprobiert hatte.
Mir war wichtig, hohe I/O und Hot-Plug für eventuell ausgefallene Festplatten. Habe RAID-5 (RaidZ) verwendet, da die Kapazität wichtig war.
Bin letztendlich bei FreeNAS hängen geblieben. Hätte auch gern Napp-It genommen, das kostet aber was. Die Free Edition ist nicht zu gebrauchen.
Hardware:
Supermicro X8DTN mit 32 GB RAM
Hardware RAID-Controller für das System mit SAS Platten RAID-1
6 x 1TB SATA HHD´s als Software RAID durch Freenas
ESXi Anbindung über iSCSI 1 GBit
Durch das Caching über den RAM (ARC) flitzt das Teil super. Macht richtig Spaß, mit den VM´s zu arbeiten und die Kosten waren gleich Null, da ich die Hardware liegen hatte.
Spendiere ihm demnächst noch eine 10Gbase-T Karte für die Backups.
Würde ich eventuell nicht unbedingt produktiv einsetzen aber als Testsystem super und LowCost.

Benutzeravatar
King of the Hill
Beiträge: 12011
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Re: Shared Storage Planung

Beitragvon Dayworker » 05.01.2017, 14:30

Kostenpflichtig ist Nappit erstmal nicht. Man kommt auch mit der Free-Version weit und zwar deutlich weiter als beim ESXi. Will man bei Nappit etwas mehr, sind die Preise für die nichtkommerzielle Privatnutzung absolut überschaubar. Davon kann sich jeder selbst unter http://napp-it.org/extensions/index_en.html überzeugen.

Ob man nun FreeNAS, beruht auf FreeBSD, oder Nappit rein als grafische Oberfläche für ZFS unter Unix (eingeschränkt unter Linux) bzw die Nappit-AiO-Appliance, beruht auf OmniOS 151020 stable, verwendet, muß jeder mit sich ausmachen. Die Appliance ist jedenfalls schnell eingerichtet und bei Problemen gibt der Entwickler schnelle Hilfe im ZFS-Stammtisch auf Hardwareluxx oder unregelmäßig auch hier im Thread ESXi 6.0u2/6.5 + ZFS/OmniOS/napp-it All-IN-ONE VM. Weshalb man zum wirklichen "Rumspielen" nicht einfach mal beim Entwickler anfragt und eine zeitlich begrenzte Vollversion erhält, erschließt sich mir nicht. Soweit jedenfalls zum nicht zu gebrauchen...

Member
Beiträge: 261
Registriert: 13.05.2009, 13:53
Wohnort: HH

Re: Shared Storage Planung

Beitragvon Borg-HH » 05.01.2017, 14:45

Hab ja nicht gesagt, das napp-it schlecht ist, im Gegenteil. Aber wenn z.B. eine Platte ausfällt und das System reagiert nicht darauf,
finde ich das schon etwas ungünstig. Hab es live getestet. Dann muß man Extensions kaufen. Die Preise sind human, hab aber für diesen Server gar kein Budget.

Benutzeravatar
King of the Hill
Beiträge: 12011
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Re: Shared Storage Planung

Beitragvon Dayworker » 05.01.2017, 15:26

OT:
Auch wenn wir uns vom Thema immer weiter entfernen, kann ich den ignorierten Plattenausfall mit meinen per WWN eingeloggten Platten nicht bestättigen. Ansonsten würden auch deutlich mehr Meldungen im ZFS Stammtisch eingehen und damit sollten wir es an dieser Stelle auch belassen oder aus Fainessgründen gegenüber dem TO einen separaten Thread aufmachen.

Member
Beiträge: 22
Registriert: 01.10.2016, 22:01

Re: Shared Storage Planung

Beitragvon josch12 » 06.01.2017, 14:36

Hi,
ich würde an dem Punkt RAID-Z anknüpfen
welche Erfahrungen gibt es mit der Erweiterung ?

mein Vorhaben ist es Später mit 4 Festplatten je 1TB SSD zu beginnen, und sobald der Platz langsam zu neige geht mit weiteren 4 Platten erweitern ....

Hat natürlich auch einen Finanziellen Hintergrund.

Benutzeravatar
King of the Hill
Beiträge: 12011
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Re: Shared Storage Planung

Beitragvon Dayworker » 06.01.2017, 20:31

Wie in meiner Signatur zu sehen, setze ich die Nappit-Appliance ein und die läuft einfach.

Benutzeravatar
King of the Hill
Beiträge: 12011
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Re: Shared Storage Planung

Beitragvon Dayworker » 07.01.2017, 14:43

Nachtrag zu ZFS und der Entscheidung FreeNAS oder Nappit.
Wenn man in einer gemischten OS-Umgebung unterwegs ist und auch Windows-Client auf den ZFS-Speicher zugreifen sollen, bietet Solarish gegenüber FreeNAS & Co einen weiteren Vorteil:
http://www.hardwareluxx.de/community/f101/zfs-stammtisch-570052-292.html#post25146977 hat geschrieben:Von den Dateieigenschaften her, benutzt Windows für die Zuordnung der User und Gruppen eine Windows Security ID (SID) in der auch die Domäne oder eine Serverkennung enthalten ist. Als Dateiystem kommt NTFS zum Einsatz das zu diesen SID Rechte in Form von Windows ACLs verwaltet. Die können sehr fein eingestellt werden. Neben Rechten auf Dateien und Ordnern gibt es Rechte die von darüberliegenden Ordnern vererbt werden. Gruppen können Gruppen und User enthalten. Das ist momentan State of the Art.

ZFS ist ein Solaris/Unix Dateisystem. Unter Unix werden User und Gruppen über eine User und Group -ID (uid/gid) verwaltet. Das ist eine einfache Zahl ohne Referenz zum Server. Auch können Gruppen keine Gruppen enthalten und es gibt keine Vererbung von Rechten. Sun hat deshalb einen eigenen SMB Server entwickelt, der Windows SID als Referenz nutzt und Windows kompatible ACLs mit Vererbung kann. Bei einem Kopiervorgang können damit Windows ACLs mit der Einschränkung übertragen werden, dass Deny Regeln und der Owner anders gehandhabt werden. Windows SMB Gruppen bleiben erhalten da Solaris neben den Unix Gruppen auch Windows Gruppen kennt.

Nutzt man dagegen SAMBA (unter Solaris eine Option, unter BSD/ Linux die alleinige Möglichkeit, OSX nutzt zwar kein SAMBA verhält sich aber wie Unix) dann gehen die SID verloren und werden auf eine UID gemappt. Auch können die ACL und die Rechte Vererbung nicht übertragen werden. Zudem ist die Unix Gruppenverwaltung nicht Windows Kompatibel.

Vorausgegangen war die Frage:
Ich habe FreeNAS mit zfs im Einsatz. Als Clients nur Windows. Ich bekomme beim Dateien kopieren oft eine Meldung, das irgendwelche Eigenschaften nicht übernommen werden können. Was hat das zu bedeuten? Welche Eigenschaften sind das und warum werden die nicht übernommen? Kann zfs das nicht oder woran liegt das? Kann man das ggf konfigurieren? Hier geht es hauptsächlich um mp3 und jpg Dateien.

Member
Beiträge: 85
Registriert: 23.05.2013, 22:14

Re: Shared Storage Planung

Beitragvon vl13 » 07.01.2017, 19:33

Dayworker hat geschrieben:Nachtrag zu ZFS und der Entscheidung FreeNAS oder Nappit.
Wenn man in einer gemischten OS-Umgebung unterwegs ist und auch Windows-Client auf den ZFS-Speicher zugreifen sollen, bietet Solarish gegenüber FreeNAS & Co einen weiteren Vorteil: Vorausgegangen war die Frage:
Ich habe FreeNAS mit zfs im Einsatz. Als Clients nur Windows. Ich bekomme beim Dateien kopieren oft eine Meldung, das irgendwelche Eigenschaften nicht übernommen werden können. ...

Koennten aber auch Alternate Data Streams sein, bei mp3's laesst sich darueber zumindest der Titel und der Kommentar aendern

Benutzeravatar
King of the Hill
Beiträge: 12011
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Re: Shared Storage Planung

Beitragvon Dayworker » 07.01.2017, 20:34

NTFS-ADS machen hier absolut keine Probleme mit ZFS unter Solarish. Hab spasseshalber einfach bei Microsoft das Tool Streams geladen und lokal gestartet, auf ein ZFS-Volume verschoben und von dort gestartet, wieder zurück auf lokal und gestartet. Ändert alles nix, in jedem Fall bekomme ich über den ADS die erwartete Sicherheitswarnung und die wandert auch immer schön mit. Selbst die von dir genannten Änderungen an MP3 werden klaglos übernommen und lassen sich auch von anderer Stelle verändern.
Aber genau das war auch zu erwarten gewesen, da der in ZFS integrierte SMB-Server nur Deny Regeln und den Owner anders handhabt.

Klar kann man jetzt argumentieren, daß man kein SMB braucht, weil man nur Linux und somit NFS einsetzt. Aber wie wahrscheinlich ist das, wenn man sich auf ESXi eingelassen hat. Unter Linux gibts schließlich mit ProxmoxVE und XEN noch ganz andere VT-Lösungen und auch Docker sollte man immer im Hinterkopf behalten. Wozu unbedingt ein ganzes OS virtualisieren, wenn man nur einzelne Bestandteile nutzen und sicher voneinander abschotten will.


Zurück zu „Hardware“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste