Forum: PC Hard- und Software Linux - HDDs auf mehreren Servern nutzen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Rene K. (xdraconix)


Lesenswert?

Hallo,

ich habe da eine Frage :-)

Ich habe drei Server stehen, alle sind ziemlich gleich ausgestattet - 
auch was die HDDs angeht - auf denen läuft Debian.

Ich würde aber gerne gewisse Daten allen drei Servern gleichzeitig zur 
Verfügung stellen. Momentan geschieht ein Verschieben dieser Daten zur 
Nachtstunde manuell per Script - so das alle Daten auf dem gleichen 
Stand sind, aber halt eben nur Abends.

Welche Möglichkeiten habe ich diese Daten von "einem" Datenträger allen 
drei gleichzeitig zur Verfügung zu stellen ohne große Performance 
Einbußen?

Wäre iSCSI etwas für mich? Wie sieht es mit SAN aus? Problem dabei ist 
ja aber, das sie das Netzwerk arg belasten würden. Kann man ein DAS dazu 
nutzen oder kann auf ein DAS Device nur ein Rechner zugreifen?

Welche Möglichkeiten habe ich da?

P.S.: Einen weiteren Server dazuzustellen wäre nicht das Problem.

: Bearbeitet durch User
von Grummler (Gast)


Lesenswert?

Rene K. schrieb:

> Welche Möglichkeiten habe ich diese Daten von "einem"
> Datenträger allen drei gleichzeitig zur Verfügung zu
> stellen ohne große Performance Einbußen?

SMB? NFS?
Wahrscheinlich habe ich die Frage wieder nicht verstanden...

von Rene K. (xdraconix)


Lesenswert?

Grummler schrieb:
> Rene K. schrieb:
>
>> Welche Möglichkeiten habe ich diese Daten von "einem"
>> Datenträger allen drei gleichzeitig zur Verfügung zu
>> stellen ohne große Performance Einbußen?
>
> SMB? NFS?
> Wahrscheinlich habe ich die Frage wieder nicht verstanden...

Nein, schon richtig verstanden. Aber wie auch iSCSI nutzt SMB und NFS 
das Netzwerk.

Wäre das Netzwerk auslagern auf separate Adapter und Switch eventuell 
eine Möglichkeit um die Last vom Hauptnetzwerk zu nehmen?

von (prx) A. K. (prx)


Lesenswert?

Rene K. schrieb:
> Welche Möglichkeiten habe ich diese Daten von "einem" Datenträger allen
> drei gleichzeitig zur Verfügung zu stellen ohne große Performance
> Einbußen?

NAS, d.h. Fileserver, ob zu Fuss oder als Blackbox. Unterhalb dieser 
Ebene kannst du das vergessen.

von (prx) A. K. (prx)


Lesenswert?

Rene K. schrieb:
> Wäre das Netzwerk auslagern auf separate Adapter und Switch eventuell
> eine Möglichkeit um die Last vom Hauptnetzwerk zu nehmen?

Ja

von Hans (Gast)


Lesenswert?

Vielleicht auch was mit ceph. Bringt dir auch Ausfallsicherheit mit.

von 1N 4. (1n4148)


Lesenswert?

GlusterFS wäre auch noch erwähnenswert

von Cloudy (Gast)


Lesenswert?

Rene K. schrieb:
> Wäre iSCSI etwas für mich? Wie sieht es mit SAN aus? Problem dabei ist
> ja aber, das sie das Netzwerk arg belasten würden. Kann man ein DAS dazu
> nutzen oder kann auf ein DAS Device nur ein Rechner zugreifen?
>
> Welche Möglichkeiten habe ich da?

Das hängt von deinen genauen Anforderungen (die wir nicht kennen) und 
dein Budget ab.

von Boomer (Gast)


Lesenswert?

Syncthing bzw generell rsync.

von Rene K. (xdraconix)


Lesenswert?

ceph und Gluster schaue ich mir mal an. ceph klingt schonmal sehr gut.

Cloudy schrieb:
> Das hängt von deinen genauen Anforderungen (die wir nicht kennen) und
> dein Budget ab.

Das Budget ist erst einmal nebensächlich. Die Anforderungen sind 
folgendermaßen:

Speichergröße: ~50TB
Das durchschnittliche Speicherverhalten: Projektdaten liegen auf der 
Platte, die via SMB mit dem Clients (Windows) verbunden sind. Da es sich 
um CAD/CAM Anwendungen handelt, welche immer kleine Datenmengen senden / 
empfangen, ist die Auslastung der Adapter bei ca. 50% - Anwendungen 
laufen lokal auf den Clients und werden nicht vom Server bereitgestellt. 
Es kommt mitunter vor das auch große Dateien (mehrere GByte) auf die 
Server geschoben werden - einer ist mit Grid Karten ausgestattet - 
dieser wird für Renderings genutzt und speichert seine Daten / Frames 
aktuell noch lokal.

Auf den Server laufen LXC Container welche redundant eingerichtet sind. 
Im Falle eines Ausfalls eines Container, arbeiten halt die Nutzer mit 
den gestrigen Daten weiter - welche auf dem redundaten Server liegen der 
den LXC Container weiterführt - das kommt sehr selten vor - Dies gilt es 
aber zu vermeiden und das ist der Grund der umstrukturierung der Daten. 
Und die Server brauchen halt eben auch alle den gleichen Speicherplatz. 
Rüste ich Server 1 auf - so muß ich dies eben auch mit 2 und 3 tun. Das 
ist auch ein Kostenfaktor und alles andere als Zeitgemäß.

Auf den Servern läuft selbstverständlich die gesamte Infrastruktur 
(DHCP, DNS, Portal, Webserver etc...) nebenbei mit.

Die Clients sind über 1Gbit am Switch - diese hängen mit 10GBit daran.

Boomer schrieb:
> Syncthing bzw generell rsync.

Ähm, nein - davon will ich ja eben weg.

: Bearbeitet durch User
von Achim H. (anymouse)


Lesenswert?

Die Frage ist, wie groß die gewünschte Bandbreite ist.

Notfalls kann man bei geeigneten Switches auch mehrere Ports parallel 
schalten, um die Bandbreite zu erhöhen. Und das ganze in einem separaten 
Storage-Net.

Du hast aber noch andere Baustellen: Jeder Server darf auf Daten 
zugreifen, auf die ein anderer ebenfalls zugreift, oder? Das bedeutet 
eine besondere Organisation, die bei normalen Speichern (lokale 
Festplatte, SAN) nicht vorkommt. Wenn Du dagegen sicherstellst, dass auf 
einen bestimmten Bereich (Stichwort: LUN) nur jeweils ein LXC Container 
zugreift, kann man sich diesen Overhead sparen.

Das ganze klingt nach ZWEI Speicher-Orten:

Einmal ein NAS für die Daten, auf die sowohl die Windows-Clients als 
auch der Rendering-Server zugreift, und zum anderen ein SAN für die 
redundanten LXC.

von Gasheizer (Gast)


Lesenswert?

Ab einer gewissen Groesse, sollte man ein SAN einplanen.
Das kann man dann noch durch ein Enterprise-NAS ergaenzen.

Wenn man unter Debian nur Daten mit anderen Servern
sharen will: NFS. Damit muessen die Applikationen dann
natuerlich auch richtig umgehen koennen.
SMB unter Unixservern ist sicherlich nicht die beste Wahl.
Und warum sollte/wollte man da iSCSI benutzen?

von Rene K. (xdraconix)


Lesenswert?

Gasheizer schrieb:
> Und warum sollte/wollte man da iSCSI benutzen?

Weil: wenn ich nach SAN schaue / suche - ich immer irgendwie bei iSCSI 
als Protokoll für ein SAN lande.

von (prx) A. K. (prx)


Lesenswert?

Gasheizer schrieb:
> Ab einer gewissen Groesse, sollte man ein SAN einplanen.

Wobei die ursprünglich klaren Grenzen zwischen SAN und NAS längst nicht 
mehr existieren.

Einen separaten Storage-Backbone hatte er selbst schon aufgeführt. Was 
da nun für ein Protokoll drauf läuft, kann man sich dann passend 
aussuchen.

von (prx) A. K. (prx)


Lesenswert?

Rene K. schrieb:
> Weil: wenn ich nach SAN schaue / suche - ich immer irgendwie bei iSCSI
> als Protokoll für ein SAN lande.

Das ist eine Möglichkeit, Block-Devices über ein Netz deiner Wahl 
anzusprechen. Früher wärs ein nativer Fibre-Channel Backbone gewesen, 
aber das hat das Rennen gegen Ethernet klar verloren.

Wobei man den Storage von VM-Images heute gerne per NFS auf eine NAS 
legt, statt sich wie früher mit Block-Devices im SAN rumzuärgern. Ist 
effektiv einfacher und flexibler, und recht flott ist es ebenfalls.

: Bearbeitet durch User
von c-hater (Gast)


Lesenswert?

Rene K. schrieb:

> Weil: wenn ich nach SAN schaue / suche - ich immer irgendwie bei iSCSI
> als Protokoll für ein SAN lande.

Ja.Ist letztlich halt nix anderes, als ein völlig dummes Block-Device, 
was da bereitgestellt wird. Völlig ungeeignet dafür, konkurrierende 
Zugriffe auf Filesystem-Ebene abzuhandeln.

Dafür muss es EINEN Server geben, der das Filesystem anbietet. Das 
kann man zwar sehr ausfallsicher gestalten (auf iSCSI-Ebene oder auf der 
Ebenen des FS-Servers), aber nicht wirklich schneller machen.

Die Ärsche, die nicht im selben LAN sind, sondern über langsame 
WAN-Anbindungen darauf zugreifen müssen, sind und bleiben langsam. 
Dagegen hilft letztlich immer nur eins: mehr WAN-Bandbreite.

Das kostet halt Geld. Ganz besonders viel in Deutschland. Es gibt 
weltweit wohl fast kein anderes Land mit derart exorbitanten Kosten für 
WAN-Bandbreite. Hier wird ganz klar heftig abgezockt.

von foobar (Gast)


Lesenswert?

> ich immer irgendwie bei iSCSI als Protokoll für ein SAN lande.

Es gibt u.A. auch noch NBD:
   https://en.wikipedia.org/wiki/Network_block_device

von Irgend W. (Firma: egal) (irgendwer)


Lesenswert?

Rene K. schrieb:
> Die Clients sind über 1Gbit am Switch - diese hängen mit 10GBit daran.

Wenn das da wirklich größere Kapazitätsengpässe gibt (und nicht nur vom 
Gefühl her), mal darüber nachdenken die Clients mit 2,5GB an den Hub 
anbinden. 2,5GB sind mittlerweile verhältnismäßig günstig und 
funktionieren meistens mit der Vorhanden Verkablung die auch für 1GB 
benutz wurde. Je nachdem wie viele Clients es sind, den Fileserver/NAS 
mit einer zweiten 10GB Anbindung versehen. Das gesamte Netzwerk würde 
ich nur doppeln wenn wirklich soviel gleichzeitiger Verkehr auf beiden 
ist das eine einzelnen Verbindung, bei der noch dazu die Latenzen 
wichtige sind, nachweislich zu einem dauerhaften und kritischen Nadelöhr 
wird. Daher lieber mal überlegen gezielt die Bandbreite an den 
erforderlichen Stellen zu erhöhen.

"SMB 3" als Protokoll kann z.B von sich aus "Multichannel", so das mehre 
parallel vorhanden NIC auch genutzt werden können ohne das extra 
irgendwas mit "Link Aggregation" oder so eingegerichtet werden muss.

Rene K. schrieb:
> welche immer kleine Datenmengen senden /
> empfangen, ist die Auslastung der Adapter bei ca. 50%

Meinst du mit 50% das der 10GB link dauerhaft mit 5GB ausgelastet ist? 
Womit ermittelt?
Und selbst wenn, ist da immer noch recht viel Luft. Und wenn wirklich 
mal mehrere anderen Verbindungen zeitgleich riesige Datenmengen durch 
die Gegend schaufeln, wie tragisch ist es wenn in dieser Zeit die 
"erste" Anwendung mal auf 4,5BG oder zu zurückgeht?

Wie "klein" ist klein? So klein das es immer eine sie Standardgröße 
eines IP-Packetes passt, oder doch eher größer? Wenn es doch nicht ganz 
so klein ist, mal über Paketgrößen und so nachdenken um ggf. den 
Overhead zu senken.

Allgemein: messen, messen, messen und das genau analysieren und nicht 
einfach nur aus dem Bauch heraus was annehmen.

von usuru (Gast)


Lesenswert?

ich habe mir dafür bei Hetzner eine Storage Box gebucht, 1 TB kostet 
3,81 Euro/Monat, Zugriff per PublicKey und SFTP, CIFS, SSHFS, rsync per 
SSH, etc ...

von kleiner Admin (Gast)


Lesenswert?

> iSCSI

Ich weiß nicht, ob ich Dein Problem richtig verstanden habe, kann aber 
folgendes aus eigener Erfahrung berichten:

iSCSI ist eine schöne Technik. Weil sie eben das IP-Protokoll auf genau 
der Technik verwendet, die jedem Admin ohnehin vertraut ist. Zudem 
verwendet sie Standardkomponenten, die recht preiswert sind. Und - im 
Bestand nicht unwichtig - können die Netzwerkleitungen verwendet werden, 
die ohnehin schon vorhanden sind.

Zwei Server A und B greifen auf eine gemeinsame Festplatte im SAN über 
iSCSI zu. Dabei verwendet jeder Server A und B ein dediziertes Netzwerk, 
so daß nur Server und SAN jeweils ein physisches Netzwerk bilden (geht, 
weil das SAN insgesamt 8 iSCSI-Ports hat). Von der Performance merkt man 
keinen Unterschied, ob die Platten lokal oder im SAN liegen (jedenfalls 
bei üblichen Dateigrößen). Läßt sich auch so konfigurieren, das Reboots 
kein Problem sind. Das SAN ist auch gegen Stromausfälle geschützt. 
Selbst das Mainboard des SAN (mit großem Cachespeicher) wird mit einem 
Akku für 72 Stunden vor Datenverlust geschützt. Funktioniert technisch 
alles einwandfrei.

Nützt aber nichts, weil die Betriebssysteme der Server und die 
Anwendungen müssen das unterstützen, sonst gibt das "Bruch".
Die Server A und B binden die Platte auch ein und alle Dateien sind 
sichtbar/lesbar. Probleme entstehen aber, wenn geschrieben wird, denn 
üblicherweise lesen Serverbetriebssysteme das Inhaltsverzeichnis des 
Dateisystems nur einmal (oder in größeren Zeitabständen gelegentlich). 
Auch die Änderungen werden üblicherweise nicht sofort auf die Platte 
geschrieben, sondern "gesammelt" und zeitversetzt geschrieben. Und wenn 
die Änderung von A auf die gemeinsame Platte geschrieben wird, bekommt B 
davon nichts mit.

Aber selbst wenn man dieses Problem noch in den Griff bekommt (erzwingen 
von Inhaltsverzeichnis vor jedem Zugriff), hat man das Problem dann noch 
einmal auf Anwendungsebene, denn üblicherweise können Programme keinen 
Multi-User-Betrieb. Beispiel User 1 und 2 ändern die gleiche Datei - 
einen Programmcode -, User 1 fügt 200 Zeilen hinzu und User 2 öffnet 
während der Arbeit von 1 die Datei und ändert einen Tippfehler im 
Kommentar, dann quatscht er mit einer Kollegin. 1 speichert nun, dann 
speichert auch 2, wodurch die Änderungen von 1 überschrieben werden. 
OOPS.
Das Problem kann nicht auf technischer oder dateisystem Ebene gelöst 
werden, sondern muß vom Programm unterstützt werden. Autorensysteme z.B. 
können das.

Was sich aber relativ leicht umsetzen läßt ist: Server A hängt an einem 
iSCSI-SAN A, das ihm den Plattenplatz zur Verfügung stellt. Server B ist 
redundant im Standby, aber arbeitet nicht aktiv, und hat ein eigene 
iSCSI-SAN B. Das SAN kann so konfiguriert werden, daß eine Replikation 
von A -> B über eine eigene dedizierte Leitung stattfindet; die meisten 
SANs können das, ggf. gegen Aufpreis.
Fällt nun A aus, so kann B sehr schnell aktiviert werden. Das ist zwar 
nicht Hot-Swap, aber länger als einen halben Tag fällt das nichts aus

von Trööööt (Gast)


Lesenswert?

Irgend W. schrieb:
> "SMB 3" als Protokoll kann z.B von sich aus "Multichannel", so das mehre
> parallel vorhanden NIC auch genutzt werden können ohne das extra
> irgendwas mit "Link Aggregation" oder so eingegerichtet werden muss.

Falscher Layer, nimm lieber MPTCP.

von Trööööt (Gast)


Lesenswert?

foobar schrieb:
>> ich immer irgendwie bei iSCSI als Protokoll für ein SAN lande.
>
> Es gibt u.A. auch noch NBD:
>    https://en.wikipedia.org/wiki/Network_block_device

Leading Edge ist NVMEOF.

von Ralf D. (doeblitz)


Lesenswert?

Rene K. schrieb:
> Die Clients sind über 1Gbit am Switch - diese hängen mit 10GBit daran.

10Gbps zwischen den Servern reicht schon für viel Kram aus. Wenn nicht, 
dann eben mehr Interfaces (eins für die Clients, eins für Storage …).

Oder eben auf dickeres Netz aufrüsten, wir haben für unseren Cluster 
25Gbps für das Storage-Netz, da merkt man dann so schnell keine 
Einschränkungen. :-)

Fettes Netz ist in den letzten Jahren wirklich sehr erschwinglich 
geworden.

von PetaBit Schubser (Gast)


Lesenswert?

1N 4. schrieb:
> GlusterFS wäre auch noch erwähnenswert

.. und GFS2 fehlt noch!

modprobe gfs2
apt install gfs2-utils
..

von Frank K. (fchk)


Lesenswert?

nochmal eine andere Möglichkeit: SAS-Festplatten.

SAS-Festplatten haben im Gegensatz zu SATA-Festplatten ZWEI voneinander 
unabhängige SAS-Ports (Multipath IO), die auch an unterschiedliche 
Controller mit unterschiedlichen Link Speeds und an unterschiedliche 
Hosts gehen können und gleichzeitig verwendet werden können. Klar, die 
Dateisysteme müssen das mitmachen. Ein Szenario wäre beispielsweise ein 
Hot-Failover von einem iSCSI/NAS-Controller auf einen anderen, ohne dass 
man umstecken müsste.

Keine Ahnung, ob das jetzt in Deinem System relevant ist, aber ich 
wollte diese Idee nur noch mal einwerfen, weil dieses Feature nicht sehr 
bekannt ist.

fchk

PS:
https://pinoutguide.com/HD/SAS_connector_pinout.shtml

: Bearbeitet durch User
von Rene K. (xdraconix)


Angehängte Dateien:

Lesenswert?

So nach ein bisschen basteln und umstellen sieht unser Setup nun wie 
folgt aus (siehe Bild).

Ich habe ein SAS Shelf Organisiert und einen vierten Server mit 
dazugestellt, welcher die Daten an das Netz verteilt. Das hat nun noch 
um einiges mehr Vorteile wie ich mir das gedacht oder vorgestellt habe. 
:-D Da die drei Nodes ja Virtualisierungsserver sind, kann ich ja nun 
auch meine ganzen Images auf eben diesen Laufwerk ablegen - das hat den 
Hintergrund das bei einer Migration auf einen anderen Server - das 
Virtuelle Laufwerk nicht hin und her geschoben wird - sondern eben 
einfach auf dem Fileserver liegt.

Angebunden habe ich das aktuell per NFS. Läuft tadellos, war easy 
einzurichten.

Einzigst natürlich aktuell: Fällt der Fileserver aus, liegt alles brach! 
Deswegen gerade die Überlegung wie man da noch einen....

Frank K. schrieb:
> Ein Szenario wäre beispielsweise ein
> Hot-Failover von einem iSCSI/NAS-Controller auf einen anderen, ohne dass
> man umstecken müsste.

...dazubringen kann. :) An meinem SAS Shelf habe ich ja noch einen 
"Zweig" frei. (Da sind zweimal SAS IN/OUT) - das teste ich aber lieber 
erstmal zu Hause durch. :-D

(Und ja... zur Not stelle ich noch einen mit ins Rack. Da wird das 
endlich mal voll :) )

von 1N 4. (1n4148)


Lesenswert?

> Einzigst natürlich aktuell: Fällt der Fileserver aus, liegt alles brach!
> Deswegen gerade die Überlegung wie man da noch einen....

Ich wiederhole mich: GlusterFS. Zweiten Server, Daten werden über das 
Netz gespiegelt, mount wahlweise per NFS oder GlusterFS-Client. Ggf. 
noch eine kleine Büchse als Arbiter Node hinzu, das reduziert auch das 
Risiko eines Split Brains.

von Andreas D. (rackandboneman)


Lesenswert?

iSCSI ist eher etwas für einen ganz anderen Einsatzfall: Du hast zB 
einen großen Server voller Platten (oder auch mehrere redundante), und 
ausserdem eine Anzahl kleiner Server auf denen Virtuelle Maschinen oder 
Container laufen die ihre virtuellen Laufwerke über iSCSI beziehen - 
nicht als Netzwerkdateisystem sondern als Disk-Image. Der Trick ist dass 
die jeweiligen VMs zwar auf beliebigen Servern, aber immer nur auf genau 
einem laufen!

von Rene K. (xdraconix)


Lesenswert?

Andreas D. schrieb:
> iSCSI ist eher etwas für einen ganz anderen Einsatzfall: Du hast zB
> einen großen Server voller Platten (oder auch mehrere redundante), und
> ausserdem eine Anzahl kleiner Server auf denen Virtuelle Maschinen oder
> Container laufen die ihre virtuellen Laufwerke über iSCSI beziehen -
> nicht als Netzwerkdateisystem sondern als Disk-Image. Der Trick ist dass
> die jeweiligen VMs zwar auf beliebigen Servern, aber immer nur auf genau
> einem laufen!

Mein Einsatz ist genau der Einsatz wie du ihn Beschreibst.

Früher:

- Drei Server mit Virtuellen Maschinen und LXC Containern.
  Jeder Server hatte die gleichen Platten und Platz
- Es lief nur bestimmte Container ein HA
- Der SMB VM Server lief auf einem festen Server
  dieser konnte im Notfall auf einen anderen Server umgeschaltet werden
- Da Datenplatten für den SMB wurden Nachts gespiegelt auf den anderen 
Server

Das war quasi alles irgendwie von hinten durch Brust ins Auge 
geschossen. Machte alles irgendwie keinen Sinn und Redundant konnte man 
da auch nicht dazu sagen.

Aktueller Stand:

- Ein Fileserver der per NFS das Laufwerk zur Verfügung stellt
- Drei Server mit Virtuellen Maschinen und LXC Container
  die Container Images und LW liegen direkt auf dem NFS Laufwerk
  jeder Server hat zu jeder Zeit Zugriff auf das aktuelle Image
- Alle Container sowie alle VMs sind nun HA
- Das SMB Laufwerk wird über NFS eingebunden, somit kann auch der SMB 
Server HA sein
- Über den Fileserver kann ich Hot-Plug Laufwerke hinzufügen, es dem 
Pool anfügen  löschen  erweitern - ohne das der Server ausgeschaltet 
werden muss oder das Laufwerk nicht erreichbar ist.

Aktuell sind wir da sehr zufrieden damit. Gefühlt ist die ganze 
Geschichte nun auch etwas "flüssiger" obwohl die Daten ja erst noch über 
die zweite Backbone kommen muss - fühlt es dennoch flinker an. Gemessen 
wurde es noch nicht.

Der Kostenfaktor ist recht überschaubar. Ein vierter Server, relativ 
klein gehalten, ein Drive-Shelf, ein Switch und vier 10GB Nics - alles 
in allem keine 3000,-€

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.