4 Server + 1 SAN

QuakeNoob

QuakeNoob

Experte
Thread Starter
Mitglied seit
19.01.2012
Beiträge
111
Ort
AC
Moin,
ich weiß zwar nicht, ob mir hier jemand wirklich weiter helfen kann, aber Fragen kostet ja nix.^^
Erstmal zum Setup:
Server:
2xPrimergy RX300 S7 (von Fujitsu)
2xPrimergy RX600 S6 (von Fujitsu)
SAN:
Eternus DX90S2 + 2xExtensions

Diese sind mittels Fibre-Channel verbunden. Dabei sind bei den Servern identische FC-Karten von Emulex verbaut. Die genaue Bezeichnung könnte ich bei Bedarf nachreichen. Da die Server, die alle openSuse 13.1 installiert haben, die LUN-Laufwerke, die ich im SAN eingerichtet habe, alle im /dev als sdx etc. erscheinen, würde ich tippen, dass der Switch, SAN und FC-Karten richtig konfiguriert sind.
Habe alle LUN-Laufwerke mit ext4 formatiert. Kann diese auch ohne Probleme mit mount mounten.

Jetzt zu meinem Problem. Wenn ich mit z.B. Server1 auf LUN-Laufwerk1 etwas schreibe, sehen es die anderen Server2-4 nicht. Erst nach einem Neustart des Servers (z.B 2), sieht er das geschriebene von Server1 auch (dabei reicht kein einfachen unmounten und wieder mounten). Wobei Server 3-4 immer noch nichts sehen. Es ist egal, mit welchem Server ich etwas schreibe, während die anderen Server Online sind, sehen die das geschriebene nicht.
Vllt hat jemand eine Idee und/oder kann mir weiter helfen. Falls ihr mehr Informationen benötigt bezüglich der Konfigurationen, werde ich euch gerne mehr liefern. Ich freue mich auf jede/n konstruktive Idee/Vorschlag.

MfG
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Danke, werde ich demnächst mal einrichten, kann aber etwas dauern, da ich nur ne 15h-Stelle habe und vorrangig an der Cloud arbeite. Werde dann berichten, wenn es erledigt ist.
 
Was willst du denn an daten teilen? Irgendwie klingt das als wärst du mit einem NFS share besser dran als mit deiner FC Lösung.
 
Es sollen dort ca 70TB an Daten gespeichert werden. Die im Moment auf ca 20 Rechner verteilt liegen. Zur Zeit läuft alles über NFS. Alles 1Gbit Lan und man kann mit den Servern oder am lokalen PC Daten auswerten etc.. Falls jemand alle 4 Server benutzt, um Daten zu analysieren, ist der Flaschenhals das 1Gbit Lan. Falls dann noch wer Daten von gleichen PC bearbeiten etc möchte, wird es natürlich noch schlimmer. Ein Fullbackup dauert dann auch seine Zeit.
In der Zukunft, sollen die Berechnungen hauptsächlich auf den Servern verrichtet werden. Muss mir in Zukunft noch Gedanken über diese Realisierung machen (MPI und OpenMP fähig). Dafür ist die FC-Lösung gedacht, damit jeder einzelne Server schnell die Daten einlesen kann.
 
Wäre da 10G Ethernet oder link aggregation nicht einfacher gewesen, wenn es nur darum geht fix an die Daten zu kommen?
Oder wenn du schon über den Einsatz von MPI nachdenkst evtl. Infiniband. Ist nicht gerade billig, aber FC ja auch nicht.
FC ist nett für failover konfigurationen aber für ein shared storage ist man mit ethernet doch ein bisschen flexibler oder nicht?
Einfach mal nen Rechner mehr dranstöpseln, die Daten für clients zur Analyse freigeben ist mit Ethernet+NFS so schön einfach. Oder mal bei defekter Netzwerk Hardware einfach auf GBit onboard Kartte stöpseln bis Ersatz da ist. Sowas hat mir mehr als einmal das Leben erleichtert.

Wie machst du denn bisher Backup wenn die Daten auf 20 Rechnern liegen?
Wie groß ist denn die Änderungsrate deiner Daten? Ich kann mir vorstellen bei 70TB Volumen muss man sich über die Backup Lösung schon ein paar Gedanken machen. Kannst du Snapshots machen um die dann zu sichern?

Ein paar Infos über die bisherige Nutzung wären Hilfreich. Warum habt ihr da ein SAN mit FC stehen? Warum LUNs für shared Storage?
Wie macht ihr denn bisher Backups und in welchem Interval/wie ist das mal geplant? Klingt ja ein bisschen so als würdet ihr Fullbackups über GBit ziehen.

Wie sehen die Daten aus? Viele kleine oder wenige große Files? Ändern sich Dateien die einmal erzeugt wurden? Wenn ja wie oft?
Was macht ihr da genau? Ihr analysiert auf 4 Kisten 70TB an Daten. Greift dabei jede Kiste auf alles zu oder ist immer nur ein Teil interessant? Was für Software setzt ihr ein? Wie skaliert die unter OpenMP/MPI.
Und wie kommt es das du als "15h die Woche vorrangig an der Cloud arbeitender" das nebenbei betreust?

Das klingt alles irgendwie nach Uni
 
Fr@ddy schrieb:
Oder wenn du schon über den Einsatz von MPI nachdenkst evtl. Infiniband. Ist nicht gerade billig, aber FC ja auch nicht.
FC ist nett für failover konfigurationen aber für ein shared storage ist man mit ethernet doch ein bisschen flexibler oder nicht?
Zum Vergrößern anklicken....

Neja, bei Ethernet und 10G ist die Flexibilität ja auch "nur" dann gegeben, wenn A) deine Clients entsprechende Ports haben und B) du entsprechende Switchports über hast...
Ist doch auch nicht viel anders als FC... Zumal, wenn die Infrastruktur einmal steht, doch dort Jeder mit Jedem reden kann (potentiell).
FC bietet dabei ja nicht nur ausschließlich Failover Möglichkeiten, sondern geht auch gut im Active/Active Mode... Kommt halt auf die SAN Lösung an, was die kann. Hatte jüngst erst eine 3par in der Hand, die mit 4x8G Links im Active/Active Mode gesprochen hat. Geht schon gut ab und es waren eher die Platten der Flaschenhals als die Anbindung ansich.

So ne FC Lösung, warscheinlich doppelt Redundand angebunden, also über 2x FC Switches mit 2x2 Ports am SAN und minimum 2x Ports pro Server (jeweils über einen SAN Switch) kommt man bei 8G Verbindungen schonmal gut hin. Im Active/Active Mode geht auch 2x8G gleichzeitig. Kann es das SAN, auch 4x -> die DX90 kann es allerdings nicht :fresse: Zumindest ist dort soweit ich weis, pro Raid Gruppe immer nur eine Controller Unit zuständig. Mit genügend Raidgruppen und gleichzeitigen Zugriffen bekommt man aber ebenso eine Lastverteilung hin.



Zum eigentlichen Problem, also wie schon gesagt wurde, hier muss eigentlich ein Clusterfähiges Filesystem zum Einsatz kommen. Ext4 kann das so erstmal nicht... In der Tat hätte allerdings eine NAS Lösung via NFS oder anderen Freigabemöglichkeiten hier wirklich den Vorteil, dass man sich nicht um das Filesystem ansich hätte kümmern müssen. Auf das NFS Share könnten sich primär auch mehrere Server connecten und auch lesend auf die Files gleichzeitig zugreifen.
Ich hab zwar noch keine DX90 gehabt, aber schon mehrere DX80 Modelle -> wenn mich nicht alles täuscht, dann gibts dort doch aber wohl Unterscheidungen. So ne (Dual) FC Controller DX kann halt nur FC? Bin mir gerade nicht ganz sicher, ob man da NFS via Lizenz nachschießen kann... Ich glaubt das kann der Kasten nicht!
 
Ich arbeite 15h-Woche als HiWi in einer Einrichtung im Krankenhaus. Dort werden Forschungsdaten von MRT-Experimenten etc. gespeichert. Das bedeutet, dass es in der Regel viele kleine Dateien sind. Ein Projekt hat alleine 100-500GB (grobe Schätzung 100.000 Dateien pro 10GB). Die meisten arbeiten mit Linux.
Die 20 Rechner haben ein Raid5-System aus genau 4 Platten. Dabei wird wöchentlich ein Fullbackup durchgeführt (2 Backupserver, jeweils 10Backups). Wenn dann der SAN einsatzbereit ist, werde ich an eine neue Backup-Lösung arbeiten.
Ein Problem ist, dass das Ethernet von der Klinik-IT bereit gestellt wird. Die können max. 1Gbit. Link Aggregation hab ich dort angefragt, aber noch keine Antwort. Und die Hardware (SAN + 2 FC-Switches) war schon dort als ich angefangen habe (aber noch nicht konfiguriert/benutzt). Also wieso nicht nutzen.
Im Moment warte ich nur, dass ich die Cloud bei der Klinik-IT hinstellen darf. Während ich warte, arbeite ich am SAN, damit der irgendwann einsatzbereit ist. Vor der Cloud habe ich auch etwas Zeit investiert, wenn gerade nichts zu tun gab. Nach der Cloud werde ich die Infrastruktur überarbeiten.

Zur Zeit hat jeder Server 2xFC-ports. Der DX90 hat 2xController-Units mit jeweils 2xFC-ports. Von einer NFS-Lizenz habe ich bisher bei dem Produkt nichts gelesen.
Aber wie schon ersichtlich ist, gibt es viel Arbeit zu tun. Das kommt sicherlich auch daher, dass es recht klein angefangen hat und der damalige Administrator (keine echte Ausbildung) die Infrastruktur nicht angepasst hat als die diese größer wurde.
Es hatte zu Anfangszeiten die Idee und Struktur wie z.B. ein CIP-Pool. Da hat eine Person gereicht, die sich etwas mit Netzwerk, Linux, Windows etc. auskannte, um das zu verwalten. Aber erstmal genug gelabert fürs erste.

MfG
 
Es tut mir ein bisschen leid das du dich mit so einer Situation auseinandersetzen darfst, aber das ist irgendwie mal wieder typisch. Wer einen 15h/woche hiwi die IT machen lässt hat es eigentlich auch nicht besser verdient.

Zentrales Storage das alle Daten per NFS exportiert, per GBit an die 20 Rechner per 10Gig an deine 4 Server (eigener Switch evtl. redundant mit GBit ans Netz der internen IT wenns anders nicht geht). Dann müsste man nur das Zentrale Storage anständig sichern und man hat eine Lösung ohne viel Wartungsaufwand die sauber dokumentiert auch jeder wieder übernehmen kann. Das erfordert ein paar Minuten Planung von jemandem der das schonmal gemacht hat.
Tut mir leid aber es geht mir schon irgendwie auf die nerven, dass es scheinbar verbreitete Praxis ist "das bisschen IT" von jemandem machen zu lassen der "sich mit Computern auskennt"
Und am Ende finden sie mit dir sogar jemanden der sich mühe gibt und das ganze irgendwie umsetzt ... für ein Hiwi Gehalt.

Ich arbeite selber in einer Forschungseinrichtung und sehe das es bei einigen befreundeten Instituten ähnlich zugeht. Vor allem natürlich bei den kleineren.
Da macht dann jemand der eigentlich seine Doktorarbeit schreiben soll nebenbei die IT, macht sich doppelt stress gibt sich Mühe und hinterlässt dann doch nur chaos wenn er wieder weg ist. Weil ja derjenige, der ihn ersetzen soll sich auch erst wieder einarbeiten muss...
Wenn ich allein daran denke was 70TB backup kosten oder so ein MRT aus dem die Daten ja kommen, aber um verfügbarkeit und sicherheit der Daten kümmert sich der Hiwi nebenbei.
 
Danke für die Ganze Hilfe. Ich denke damit werde ich es schon irgendwie hin bekommen. Normal sollte es auch irgendwie mit openSuse klappen, wenn es mit der Server-Version klappt. Manchmal muss man etwas manuell konfigurieren oder/und etwas zusammensuchen, wenn es für SLES ein einfaches Installationspaket gibt, damit das selbe rauskommt.

Bei solchen Sachen habe ich Spaß dran und bring dann auch eine große Ausdauer mit. Sprich ich muss mich selbst beherrschen, nicht dass ich gleich 24h am Stück am Problem arbeite. Aber ich mache es auch, damit die Wartung viel angenehmer wird. Ich glaub die ersten 2 Wochen habe ich nur defekte HDDs getauscht und dabei eine zentrales Monitoring der ganzen Raid-Controller installiert.Und glaub ja nicht, dass der HDD wechsel nicht HiWi tauglich ist. Haben zwar HotPlug fähige Hardware, aber verbauen es so, dass man den PC ausschalten und halb auseinander bauen muss^^
Seit ca. 1 Monat haben wir einen neuen Administrator auf Probe, ist leider seit ein paar Jahren aus der Übung. Im Moment muss ich ihn quasi anlernen :fresse2: der Arbeite im Moment an der Homepage.
Die Klinik-IT hat davon die Finger gelassen, da es für sie zu viel Arbeitsaufwand wäre. Zum größten Teil Linux Rechner und man muss flexibel bei der Software sein. Es kommt dann schon öfters vor, dass die Benutzer neue Software testen und dann dort benutzen wollen.

Bei uns werden alle Forschungsdaten der MRTs gesichert und Forschende können bei uns Plattenplatz und einen Account zum Arbeiten beantragen. Ein großer Teil arbeitet zur Zeit im eigenem Büro. Es gab mal eine Zeit, da war der Büro Rechner schneller als unsere. :wut: Eigentlich ist unser Netzwerk genau dafür dar, dass nicht jemand noch mit der IT rumjonglieren muss.

Falls ich auf ungooglebare Probleme stoßen sollte, werde ich nicht davor zurückschrecken euch ein weiteres mal zu belästigen :d
 
Was passiert, wenn du ungooglebare Probleme bekommst und du auf Daten nicht mehr zugreifen kannst?
Für solche Fälle würde ich definitiv auf ein Linux mit Support zurückgreifen. RedHat, SLES, für Ubuntu Server gibts das denke ich mittlerweile auch.
Ohne so eine Absicherung würde ich das nicht betreiben.

Klappt das eigentlich von der Performance? Wieviele Disken sind in den 20 Rechnern eingebaut und wieviele in deinem Block Storage?
Verbindest du das Storage eigentlich Back2Back mit den Servern, oder hängen da noch 2 SAN Switches dazwischen.

Ein bisschen Consulting von einem guten Systemhaus, das bei der Planung hilft, würde denke ich nicht schaden.
 
Ich werde dann mit Vorsicht an die Sache ran gehen. Sprich ich habe ein Testrechner, auf dem ich dann alles vorher probieren kann, bevor ich es auf die Server anwenden werde. Wenn das System erstmal läuft, sollte es auch recht stabil laufen. Bei neuer Software, Pakete, Update, Upgrade etc. könnte es dann mal vorkommen, das etwas, was vorher lief, dann nicht mehr laufen könnte. Also da bin ich schon recht optimistisch, wenn man es vorsichtig angeht. openSuse ist für mich SLES in der Testphase.
Ich hab es ja noch nicht als shared konfigurieren können, aber ich würde sagen, dass es auf jedenfall ein Performance+ ist. Vorher konnte man grade so mit 1Gbit einen Server recht gut auslasten. Bei mehr Threads müssen Prozesse längere Zeit auf Daten warten. Jeder Server hat 2 CPUs mit jeweils 6 Kernen + HT. Da sollte die 8Gbit Anbindung schon ordentlich was bringen. Ohne neue Hardware kaufen zu müssen, könnte ich auch Link Aggregation anwenden, dann wären es schon 16Gbit.
Im moment hat jeder der 20 Rechner ein Raid5 mit jeweils 4 1TB Platten + eine Systemplatte. Im Storage sind 12x3x3TB verbaut.
Da sind noch zwei FC-Switche zwischen.
 
OpenSuse war mal was für leute die Zeit haben. Ich meine die haben ihre support Zeiten aber mitlerweile etwas verlängert.
Habe ich früher selber mal eingesetzt bis mich die damals recht knappen support zeiten extrem genervt haben. Das sah in etwa so aus... Ah neues release mal ein Quartal warten bis die härsten Bugs raus sind... probleme gefunden.. nochmal 2-3 monate auf fix warten ... neues image aufsetzen... testen... software anpassen ... verteilen ... halbes jahr reift das ganze nach und läuft ordentlich...halbes jahr ist alles super... oh mist bald ist der support abgelaufen, mal schnell ein neues image bauen...
Das hab ich 2 mal so mitgemacht, dann haben wir uns was gesucht was 5 Jahre betrieben werden kann.

Wie sind denn die 36x3TB konfiguriert? Raid5/6 könnte bei parallelen Zugriffen auch ganzschön einknicken. Gerade bei vielen kleinen Dateien, daher hatte ich auch gefragt, was für Daten ihr speichert. Caches können da helfen, je nach größe der am Stück zu bearbeitenden Daten.
Ist wirklich großartig wenn so ein gesammter Datensatz cached über eine Flotte Verbindung zur Verfügung steht.
Wir haben hier fürs postprocessing an einer Stelle ein ZFS storage mit 256GB Cache über 10GBit angebunden. An einer Kiste die per NFS auf diese Daten zugreift visualisieren wir remote bis zu 100GB große Ergebnisse. Da passsen 2-3 Zeitschritte dann komplett in den cache. Da kann man dann selbst mit größeren Datenmengen halbwegs flüssig arbeiten. Selbst bei kleineren Szenen ist das ca. um Faktor 3-5 flotter als Workstations mit lokal liegenden Daten.
 
Ich hatte mir überlegt, dass ich identische 3x(Raid6 + HotSpare) einrichte genau 1 Partition pro Rack-Gehäuse. Vllt reichen auch 2 identische Partitionen, da ich diese auf die 2 Controller-Units aufteilen kann.
Muss ich dann mal testen, wenn ich soweit bin. Hätten noch eine 512GB SSD rumliegen, die man sicherlich als Cache verwenden könnte. Wenn ich mich nicht täusche müsste das eine Samsung 840 bla sein.
 
Das blöde an Raid6 ist die I/O performance. Pro Raid set kommt man in etwa auf die IOPs einer Platte sobald caches keinen Effekt mehr haben weil die Datenmenge zu groß wird.
Bei 100.000 Files/10GB wird dann vermutlich nicht unbedingt dein FC Interface bremsen.
Ich gehe mal davon aus das deine Dateisysteme die zeitgleichen Zugriff auf allen 4 Servern erlauben synchrone Schreibzugriffe erfordern um Konsistent zu bleiben.

8GB Cache entnehme ich dem Datenblatt der DX90S2. Bei 100-500GB und 1-5mio dateien pro Projekt halte ich besonders große hit-rates nicht für warscheinlich.
Und du willst mit mehreren Rechnern ja vermutlich in der Lage sein mehrere Projekte zeitgleich zu bearbeiten oder?
 
Moin,
Ich wollte mal meine Fortschritte zur Cluster-Bildung mit einem GFS2 Filesystem mitteilen. Ich benutzte corosync+pacemaker. Die Kommunikation läuft zur Zeit Unicast. Mein Cluster besteht zur zeit aus 2 Servern.
Um beiden ein gemeinsamen shared-storage zu geben, habe ich mich an link gehalten. Danach habe ich Creating GFS2 Volumes und dann Mounting GFS2 Volumes befolgt. Lief auch alles so wie erwartet, dass nun ein shared-storage bei beiden Knoten gemounted wurde.
Dabei sind irgendwo die ganzen Informationen, die ich mit "sbd -d /dev/SBD create" erstellt habe verloren gegangen. Deswegen meckert sbd, dass /dev/SBD keinen gültigen Header hat. Wenn der Cluster Offline war, ist das Filesystem GFS2 nachem Neustart Korrupt bzw. es wird mit blkid kein Filesystem mehr angezeigt. Ich hoffe, dass mir vllt jemand weiterhelfen kann, auch wenn es nur bei der Fehlereinschränkung zu tun hat. Ich würde im Moment alles auf den verlorenen Header zurückführen.

MfG
 
Wir haben in einem Projekt mal GFS Beruflich eingesetzt. Die Performance ist unter aller Sau vor 2 Jahren gewesen. Wieso nutzt du nicht OCFS ? Ist vom Aufbau ähnlich.
 
Das werde ich auch gleich ausprobieren.
Leider wird ocfs2 nicht mit den corosyn + pacemaker Version-Kombination nicht so einfach unterstützt. Dann bräuchte ich noch ein extra packet, das die Kommunikation zwischen o2bs und pacemaker ermöglicht oder so ähnlich.
Bin deswegen wieder bei gfs2 gelandet und ich konnte es auch erfolgreich konfigurieren. Der Cluster, der aus 4 Servern besteht, mounted automatisch jetzt schon 2/3 vom SAN.
Als nächstes wird noch eine Cluster-NFS-Freigabe eingerichtet, inklusive virtueller IP. Dann wird erst ein mal der Cluster auf Stabilität und Schreib-/Leseleistung getestet.
 
Zuletzt bearbeitet:
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh