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
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...
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?
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.
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
Vielleicht auch was mit ceph. Bringt dir auch Ausfallsicherheit mit.
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.
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
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.
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?
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.
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.
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
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.
> 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
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.
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 ...
> 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
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.
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.
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.
1N 4. schrieb: > GlusterFS wäre auch noch erwähnenswert .. und GFS2 fehlt noch! modprobe gfs2 apt install gfs2-utils ..
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
Angehängte Dateien:
-
Net.png
54 KB
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 :) )
> 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.
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!
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,-€
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.