Kürzlich habe ich einen 4-Knoten-Cluster für eine Webanwendung entworfen und konfiguriert, die viele Dateien verarbeitet. Der Cluster wurde in zwei Hauptrollen aufgeteilt: Webserver und Speicher. Jede Rolle wird mithilfe von drbd im Aktiv-/Passivmodus auf einen zweiten Server repliziert. Der Webserver führt eine NFS-Einbindung des Datenverzeichnisses des Speicherservers durch und auf letzterem läuft auch ein Webserver, der Dateien an Browser-Clients ausliefert.
Auf den Speicherservern habe ich ein GFS2-FS erstellt, um die Daten zu speichern, die mit drbd verbunden sind. Ich habe mich hauptsächlich wegen der angekündigten Leistung für GFS2 entschieden, aber auch wegen der Volumegröße, die ziemlich hoch sein muss.
Seit wir in Produktion sind, habe ich mit zwei Problemen zu kämpfen, die meiner Meinung nach eng miteinander verbunden sind. Erstens bleibt die NFS-Einbindung auf den Webservern etwa eine Minute lang hängen und nimmt dann den normalen Betrieb wieder auf. Durch die Analyse der Protokolle habe ich herausgefunden, dass NFS für eine Weile nicht mehr antwortet und die folgenden Protokollzeilen ausgibt:
Oct 15 18:15:42 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:44 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:46 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:47 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:47 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:47 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:48 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:48 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:51 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:52 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:52 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:55 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:55 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:58 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
In diesem Fall dauerte das Hängen 16 Sekunden, manchmal dauert es jedoch 1 oder 2 Minuten, bis der normale Betrieb wieder aufgenommen wird.
Meine erste Vermutung war, dass dies aufgrund der hohen Belastung des NFS-Mounts passierte und dass eine Erhöhung RPCNFSDCOUNTauf einen höheren Wert die Stabilität verbessern würde. Ich habe den Wert mehrmals erhöht und anscheinend wurden die Protokolle nach einer Weile seltener angezeigt. Der Wert liegt jetzt bei 32.
Nach weiterer Untersuchung des Problems bin ich auf ein anderes Problem gestoßen, obwohl die NFS-Meldungen immer noch in den Protokollen erscheinen. Manchmal bleibt das GFS2-FS einfach hängen, was dazu führt, dass sowohl das NFS als auch der Speicher-Webserver Dateien bereitstellen. Beide bleiben eine Weile hängen und nehmen dann den normalen Betrieb wieder auf. Dieses Hängenbleiben hinterlässt keine Spuren auf der Clientseite (hinterlässt auch keine NFS ... not respondingMeldungen) und auf der Speicherseite scheint das Protokollsystem leer zu sein, obwohl es rsyslogdausgeführt wird.
Die Knoten verbinden sich selbst über eine nicht dedizierte 10-Gbit/s-Verbindung, aber ich glaube nicht, dass das ein Problem darstellt, da das Hängenbleiben von GFS2 bestätigt ist, aber eine direkte Verbindung zum aktiven Speicherserver besteht.
Ich versuche schon seit einiger Zeit, dieses Problem zu lösen und habe verschiedene NFS-Konfigurationsoptionen ausprobiert, bevor ich herausgefunden habe, dass das GFS2 FS auch hängt.
Der NFS-Mount wird wie folgt exportiert:
/srv/data/ <ip_address>(rw,async,no_root_squash,no_all_squash,fsid=25)
Und der NFS-Client wird mit folgendem gemountet:
mount -o "async,hard,intr,wsize=8192,rsize=8192" active.storage.vlan:/srv/data /srv/data
Nach einigen Tests waren dies die Konfigurationen, die dem Cluster mehr Leistung brachten.
Ich suche verzweifelt nach einer Lösung dafür, da der Cluster bereits im Produktionsmodus ist und ich das beheben muss, damit diese Hänger in Zukunft nicht mehr auftreten. Ich weiß nicht genau, was und wie ich Benchmarking durchführen soll. Ich kann nur sagen, dass dies aufgrund hoher Belastungen passiert, da ich den Cluster früher getestet habe und diese Probleme überhaupt nicht auftraten.
Bitte sagen Sie mir, ob ich Konfigurationsdetails für den Cluster bereitstellen soll und welche ich veröffentlichen soll.
Als letzten Ausweg kann ich die Dateien auf ein anderes FS migrieren, aber ich brauche einige konkrete Hinweise, ob dies die Probleme lösen wird, da die Datenträgergröße an diesem Punkt extrem groß ist.
Die Server werden von einem Drittunternehmen gehostet und ich habe keinen physischen Zugriff darauf.
Beste grüße.
BEARBEITEN 1: Bei den Servern handelt es sich um physische Server und ihre Spezifikationen sind:
Webserver:
- Intel Bi Xeon E5606 2x4 2,13 GHz
- 24 GB DDR3
- Intel SSD 320 2 x 120 GB Raid 1
Lagerung:
- Intel i5 3550 3,3 GHz
- 16 GB DDR3
- 12 x 2 TB SATA
Ursprünglich gab es ein VRack-Setup zwischen den Servern, aber wir haben einen der Speicherserver aufgerüstet, um mehr RAM zu haben, und er befand sich nicht im VRack. Sie sind über eine gemeinsame 10-Gbit/s-Verbindung miteinander verbunden. Bitte beachten Sie, dass es sich um dieselbe Verbindung handelt, die für den öffentlichen Zugriff verwendet wird. Sie verwenden eine einzelne IP (mit IP-Failover), um die Verbindung zwischen ihnen herzustellen und ein reibungsloses Failover zu ermöglichen.
NFS erfolgt daher über eine öffentliche Verbindung und nicht über ein privates Netzwerk (das war vor dem Upgrade der Fall, als das Problem noch bestand).
Die Firewall wurde konfiguriert und gründlich getestet, aber ich habe sie eine Zeit lang deaktiviert, um zu sehen, ob das Problem weiterhin auftritt, und das tat es. Meines Wissens nach blockiert oder begrenzt der Hosting-Anbieter die Verbindung zwischen den Servern und der öffentlichen Domäne nicht (zumindest unter einer bestimmten Bandbreitenverbrauchsschwelle, die noch nicht erreicht wurde).
Ich hoffe, dies hilft bei der Ermittlung des Problems.
BEARBEITEN 2:
Relevante Softwareversionen:
CentOS 2.6.32-279.9.1.el6.x86_64
nfs-utils-1.2.3-26.el6.x86_64
nfs-utils-lib-1.1.5-4.el6.x86_64
gfs2-utils-3.0.12.1-32.el6_3.1.x86_64
kmod-drbd84-8.4.2-1.el6_3.elrepo.x86_64
drbd84-utils-8.4.2-1.el6.elrepo.x86_64
DRBD-Konfiguration auf Speicherservern:
#/etc/drbd.d/storage.res
resource storage {
protocol C;
on <server1 fqdn> {
device /dev/drbd0;
disk /dev/vg_storage/LV_replicated;
address <server1 ip>:7788;
meta-disk internal;
}
on <server2 fqdn> {
device /dev/drbd0;
disk /dev/vg_storage/LV_replicated;
address <server2 ip>:7788;
meta-disk internal;
}
}
NFS-Konfiguration in Speicherservern:
#/etc/sysconfig/nfs
RPCNFSDCOUNT=32
STATD_PORT=10002
STATD_OUTGOING_PORT=10003
MOUNTD_PORT=10004
RQUOTAD_PORT=10005
LOCKD_UDPPORT=30001
LOCKD_TCPPORT=30001
LOCKD_UDPPORT(Kann es zu Konflikten kommen, wenn für und derselbe Port verwendet wird LOCKD_TCPPORT?)
GFS2-Konfiguration:
# gfs2_tool gettune <mountpoint>
incore_log_blocks = 1024
log_flush_secs = 60
quota_warn_period = 10
quota_quantum = 60
max_readahead = 262144
complain_secs = 10
statfs_slow = 0
quota_simul_sync = 64
statfs_quantum = 30
quota_scale = 1.0000 (1, 1)
new_files_jdata = 0
Speichernetzwerkumgebung:
eth0 Link encap:Ethernet HWaddr <mac address>
inet addr:<ip address> Bcast:<bcast address> Mask:<ip mask>
inet6 addr: <ip address> Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:957025127 errors:0 dropped:0 overruns:0 frame:0
TX packets:1473338731 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2630984979622 (2.3 TiB) TX bytes:1648430431523 (1.4 TiB)
eth0:0 Link encap:Ethernet HWaddr <mac address>
inet addr:<ip failover address> Bcast:<bcast address> Mask:<ip mask>
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Die IP-Adressen werden bei den gegebenen Netzwerkkonfigurationen statisch vergeben:
DEVICE="eth0"
BOOTPROTO="static"
HWADDR=<mac address>
ONBOOT="yes"
TYPE="Ethernet"
IPADDR=<ip address>
NETMASK=<net mask>
Und
DEVICE="eth0:0"
BOOTPROTO="static"
HWADDR=<mac address>
IPADDR=<ip failover>
NETMASK=<net mask>
ONBOOT="yes"
BROADCAST=<bcast address>
fsid=25Hosts-Datei, um ein ordnungsgemäßes NFS-Failover in Verbindung mit der auf beiden Speicherservern festgelegten NFS-Option zu ermöglichen :
#/etc/hosts
<storage ip failover address> active.storage.vlan
<webserver ip failover address> active.service.vlan
Wie Sie sehen, sind die Paketfehler auf 0 gesunken. Ich habe auch lange Zeit Ping ausgeführt, ohne dass ein Paketverlust aufgetreten ist. Die MTU-Größe beträgt die normalen 1500. Da es derzeit kein VLAN gibt, ist dies die MTU, die für die Kommunikation zwischen Servern verwendet wird.
Die Netzwerkumgebung der Webserver ist ähnlich.
Eine Sache, die ich vergessen habe zu erwähnen, ist, dass die Speicherserver über die NFS-Verbindung täglich ca. 200 GB an neuen Dateien verarbeiten. Das ist für mich ein wichtiger Punkt, der mich vermuten lässt, dass es sich hier um eine Art Hochlastproblem bei NFS oder GFS2 handelt.
Wenn Sie weitere Konfigurationsdetails benötigen, sagen Sie mir bitte Bescheid.
BEARBEITEN 3:
Heute Morgen hatten wir einen schweren Dateisystemabsturz auf dem Speicherserver. Ich konnte die Details des Absturzes nicht sofort abrufen, da der Server nicht mehr reagierte. Nach dem Neustart bemerkte ich, dass das Dateisystem extrem langsam war und ich keine einzige Datei über NFS oder httpd bereitstellen konnte, möglicherweise aufgrund von Cache-Warming oder so. Trotzdem habe ich den Server genau überwacht und der folgende Fehler ist aufgetreten dmesg. Die Ursache des Problems ist eindeutig GFS, das auf einen wartet lockund nach einer Weile verhungert.
INFO: task nfsd:3029 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
nfsd D 0000000000000000 0 3029 2 0x00000080
ffff8803814f79e0 0000000000000046 0000000000000000 ffffffff8109213f
ffff880434c5e148 ffff880624508d88 ffff8803814f7960 ffffffffa037253f
ffff8803815c1098 ffff8803814f7fd8 000000000000fb88 ffff8803815c1098
Call Trace:
[<ffffffff8109213f>] ? wake_up_bit+0x2f/0x40
[<ffffffffa037253f>] ? gfs2_holder_wake+0x1f/0x30 [gfs2]
[<ffffffff814ff42e>] __mutex_lock_slowpath+0x13e/0x180
[<ffffffff814ff2cb>] mutex_lock+0x2b/0x50
[<ffffffffa0379f21>] gfs2_log_reserve+0x51/0x190 [gfs2]
[<ffffffffa0390da2>] gfs2_trans_begin+0x112/0x1d0 [gfs2]
[<ffffffffa0369b05>] ? gfs2_dir_check+0x35/0xe0 [gfs2]
[<ffffffffa0377943>] gfs2_createi+0x1a3/0xaa0 [gfs2]
[<ffffffff8121aab1>] ? avc_has_perm+0x71/0x90
[<ffffffffa0383d1e>] gfs2_create+0x7e/0x1a0 [gfs2]
[<ffffffffa037783f>] ? gfs2_createi+0x9f/0xaa0 [gfs2]
[<ffffffff81188cf4>] vfs_create+0xb4/0xe0
[<ffffffffa04217d6>] nfsd_create_v3+0x366/0x4c0 [nfsd]
[<ffffffffa0429703>] nfsd3_proc_create+0x123/0x1b0 [nfsd]
[<ffffffffa041a43e>] nfsd_dispatch+0xfe/0x240 [nfsd]
[<ffffffffa025a5d4>] svc_process_common+0x344/0x640 [sunrpc]
[<ffffffff810602a0>] ? default_wake_function+0x0/0x20
[<ffffffffa025ac10>] svc_process+0x110/0x160 [sunrpc]
[<ffffffffa041ab62>] nfsd+0xc2/0x160 [nfsd]
[<ffffffffa041aaa0>] ? nfsd+0x0/0x160 [nfsd]
[<ffffffff81091de6>] kthread+0x96/0xa0
[<ffffffff8100c14a>] child_rip+0xa/0x20
[<ffffffff81091d50>] ? kthread+0x0/0xa0
[<ffffffff8100c140>] ? child_rip+0x0/0x20
BEARBEITEN 4:
Ich habe Munin installiert und bekomme einige neue Daten. Heute gab es einen weiteren Hänger und Munin zeigt mir Folgendes: Die Größe der Inode-Tabelle beträgt kurz vor dem Hänger 80 KB und fällt dann plötzlich auf 10 KB. Wie beim Speicher sinken auch die zwischengespeicherten Daten plötzlich von 7 GB auf 500 MB. Die durchschnittliche Auslastung steigt während des Hängers ebenfalls stark an und die Gerätenutzung des drbdGeräts steigt ebenfalls auf Werte um 90 %.
Im Vergleich zu einem früheren Hängen verhalten sich diese beiden Indikatoren identisch. Kann dies an einer schlechten Dateiverwaltung auf der Anwendungsseite liegen, die keine Dateihandler freigibt, oder vielleicht an Speicherverwaltungsproblemen, die von GFS2 oder NFS herrühren (was ich bezweifle)?
Danke für eventuelle Rückmeldungen.
BEARBEITEN 5:
Inode-Tabellennutzung von Munin:
Speichernutzung von Munin:
Antwort1
Ich kann nur einige allgemeine Hinweise geben.
Zuerst würde ich einige einfache Benchmark-Metriken einrichten und ausführen. Dann wissen Sie zumindest, ob die von Ihnen vorgenommenen Änderungen die besten sind.
- Munin
- Kakteen
Nagios
sind einige gute Möglichkeiten.
Handelt es sich bei diesen Knoten um virtuelle oder physische Server und wie sind ihre Spezifikationen?
Welche Art von Netzwerkverbindung besteht zwischen den einzelnen Knoten?
Ist NFS über das private Netzwerk Ihres Hosting-Anbieters eingerichtet?
Sie beschränken Pakete/Ports nicht mit Firewalls. Tut Ihr Hosting-Anbieter dies?
Antwort2
Ich denke, Sie haben zwei Probleme. Ein Engpass, der das Problem überhaupt erst verursacht, und, was noch wichtiger ist, eine schlechte Fehlerbehandlung durch GFS. GFS sollte die Übertragung wirklich verlangsamen, bis sie funktioniert, aber ich kann dabei nicht helfen.
Sie sagen, dass der Cluster ca. 200 GB neue Dateien in das NFS verarbeitet. Wie viele Daten werden aus dem Cluster gelesen?
Ich wäre immer nervös, wenn es für das Frontend und das Backend nur eine Netzwerkverbindung gäbe, da das Frontend das Backend „direkt“ beschädigen könnte (durch Überlastung der Datenverbindung).
Wenn Sie iperf auf jeder der Boxen installieren, können Sie den verfügbaren Netzwerkdurchsatz zu jedem beliebigen Zeitpunkt testen. Auf diese Weise können Sie schnell feststellen, ob bei Ihnen ein Netzwerkengpass vorliegt.
Wie stark ist das Netzwerk ausgelastet? Wie schnell sind die Festplatten auf dem Speicherserver und welches RAID-Setup verwenden Sie? Welchen Durchsatz erzielen Sie damit? Vorausgesetzt, es läuft *nix und Sie haben einen ruhigen Moment zum Testen, können Sie hdparm verwenden.
$ hdpard -tT /dev/<device>
Wenn Sie eine starke Netzwerkauslastung feststellen, würde ich vorschlagen, GFS auf einer sekundären und dedizierten Netzwerkverbindung zu installieren.
Je nachdem, wie Sie die 12 Festplatten raiden, kann die Leistung unterschiedlich ausfallen, und das könnte der zweite Engpass sein. Es hängt auch davon ab, ob Sie Hardware- oder Software-RAID verwenden.
Der große Speicher, den Sie auf der Box haben, ist möglicherweise von geringem Nutzen, wenn die angeforderten Daten über mehr als Ihren gesamten Speicher verteilt sind, was anscheinend der Fall ist. Außerdem kann der Speicher nur beim Lesen helfen, und das auch nur, wenn viele der Lesevorgänge für dieselbe Datei erfolgen (sonst würde sie aus dem Cache geworfen).
Achten Sie beim Ausführen von top / htop auf iowait. Ein hoher Wert ist hier ein ausgezeichneter Indikator dafür, dass die CPU nur Däumchen dreht und auf etwas wartet (Netzwerk, Festplatte usw.).
Meiner Meinung nach ist NFS weniger wahrscheinlich der Übeltäter. Wir haben ziemlich viel Erfahrung mit NFS und obwohl es angepasst/optimiert werden kann,neigtziemlich zuverlässig zu funktionieren.
Ich würde dazu neigen, die GFS-Komponente stabil zu machen und dann zu sehen, ob die Probleme mit NFS verschwinden.
Schließlich könnte OCFS2 eine Option sein, die als Ersatz für GFS in Betracht gezogen werden könnte. Während meiner Recherchen zu verteilten Dateisystemen habe ich ziemlich viel recherchiert und kann mich nicht mehr an die Gründe erinnern, warum ich mich für OCFS2 entschieden habe – aber ich habe es getan. Vielleicht hatte es etwas damit zu tun, dass OCFS2 von Oracle für seine Datenbank-Backends verwendet wird, was ziemlich hohe Stabilitätsanforderungen mit sich bringen würde.
Munin ist dein Freund. Aber viel wichtiger ist top / htop. vmstat kann dir auch einige wichtige Zahlen geben
$ vmstat 1
und Sie erhalten jede Sekunde ein Update darüber, womit das System seine Zeit genau verbringt.
Viel Glück!
Antwort3
Versehen Sie die Webserver zunächst mit einem HA-Proxy, entweder mit Varnish oder Nginx.
Dann zum Webdateisystem: Warum verwenden Sie nicht MooseFS anstelle von NFS, GFS2? Es ist fehlertolerant und schnell beim Lesen. Was Sie bei NFS, GFS2 verlieren, sind lokale Sperren. Brauchen Sie die für Ihre Anwendung? Wenn nicht, würde ich zu MooseFS wechseln und die NFS-, GFS2-Probleme überspringen. Sie müssen Ucarp verwenden, um die MFS-Metadatenserver hochzuladen.
In MFS Replikationsziel auf 3 setzen
# mfssetgoal 3 /Ordner
//Christian
Antwort4
Basierend auf Ihren Munin-Diagrammen löscht das System Caches. Dies entspricht der Ausführung eines der folgenden Vorgänge:
echo 2 > /proc/sys/vm/drop_caches- freie Dentries und Inodes
echo 3 > /proc/sys/vm/drop_caches- kostenloser Pagecache, Dentires und Inodes
Die Frage ist nun: Warum? Gibt es vielleicht eine noch offene Cron-Aufgabe?
Abgesehen von 01:00 -> 12:00 scheinen sie in regelmäßigen Abständen zu erfolgen.
Es wäre auch sinnvoll, etwa nach der Hälfte eines Peaks zu prüfen, ob das Ausführen eines der oben genannten Befehle Ihr Problem reproduziert.stetsStellen Sie sicher, dass Sie syncvorher rechts abbiegen.
Das Scheitern dieser Maßnahme stracekönnte Licht ins Dunkel bringen, wenn Ihr DRBD-Prozess (auch hier wieder vorausgesetzt, dass dieser der Übeltäter ist) etwa zum Zeitpunkt einer erwarteten Bereinigung und bis zu dieser Bereinigung ausgeführt wird.