fehlersuche

A 8-post collection


RSS feed of posts tagged fehlersuche

Neuer Fileserver Teil 11 - neuer SAS Controller, ESXi 6.5U1 Update

Heute habe ich einen IBM M1215 (LSI 3008) eingebaut, der musste auch auf IT Mode umgeflasht werden, aber IBM legt da zum Glück keine Stolpersteine in den Weg.
Die Performance scheint mir etwas besser zu sein. Derzeit läuft ein Scrub mit 600MB/s auf den drei Platten. Einen Fehler gabs bisher nicht, aber beim alten Controller auch erst nach Wochen gemerkt.
Falls das Problem mit dem Controller hier nicht mehr auftritt, liegt das Problem sehr wahrscheinlich am FreeBSD Treiber oder an der Firmware des Controllers selbst.

Man könnte es sehr wahrscheinlich auch in der Firmware der Festplatten fixen aber da müsste man erstmal einen Fehler nachweisen. Mit Seagate hatte ich zwar Kontakt, aber da kommt man wohl nur weiter, wenn das Problem bei wirklich vielen Leuten auftritt. Bisher konnte ich nur einen Leidensgenossen finden.

Da ich den Server zum Einbau des Controllers eh herunterfahren musste, habe ich gleich noch ein ESXi Update gemacht. VMWare macht einem das auch nicht ganz einfach, aber ich habe diese Anleitung gefunden. Die Command-Line-Methode funktioniert auch mit dem kostenlosen ESXi.

Update:

Beim ersten Scrub wurden ein paar kaputte Checksummen auf einer der Platten gefunden, sie konnten aber alle repariert werden. Ich habe dann noch einen zweiten Scrub durchlaufen lassen, bei dem dann alles ok war. Bisher keine SATA/SAS Errors.

Greenshot-2017-10-30-01.18.37

Hier sieht man schön, dass das System bei so einem Scrub wirklich etwas tut. Die CPU Temperatur stieg von 36°C auf 40°C (dunkelgrün).

»

Neuer Fileserver Teil 10 - noch ein Problem

Es hat mir jetzt schon zweimal eine Platte aus dem raidz1 geschossen. Im Kernel Log war immer sowas hier zu finden:

mps0:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred)

Die Platte ist ok, man kann den Fehler auch mit einem zpool clear wieder zurücksetzen und der Pool läuft nach einem Reboot wieder normal ohne Fehler weiter.

Ich dachte erst, dass evtl. das SAS Kabel defekt sei, aber das hab ich heute getauscht und hatte kurz danach nochmal das gleiche Problem mit einer anderen Platte.

Nach kurzer Suche habe ich dann einen weiteren freenas User gefunden, der einen ähnlichen SAS Controller mit den gleichen Platten einsetzt. Er hat eine etwas ältere Firmware und heute auf meine Version upgedated. Vorher lief sein Controller mit anderen Platten ohne Probleme.

Das könnte nun ein Bug im FreeBSD Treiber für den Controller sein, evtl. liegt es auch an der Firmware der Platten. Ich überlege gerade Seagate mal zu kontaktieren.

»

Neuer Fileserver Teil 8 - neues Ram neues Glück

So das neue RAM ist da, Micron/Crucial 16GB reg. ECC Riegel (MTA36ASF2G72PZ-2G1A2). Die finden sich auch auf der HCL von Supermicro. Ich bin zuversichtlich. Diesmal konnte ich auch große Dateien kopieren und derzeit läuft einen Memtest.

Der Server steht gerade unter meinem Schreibtisch und ist schon sehr leise. Das lauteste sind die Seagate Platten.

...ein paar Stunden später...

Memtest lief auch durch ohne Probleme, diesmal ohne Failsafe-Mode.
Habe auch gerade Geekbench4 laufen lassen, hier das Ergebnis:
https://browser.geekbench.com/v4/cpu/4022145

Etwas langsamer als der Spielerechner mit i7-7700K aber schneller als der Mac Pro mit Xeon x5670. Demnächst werde ich auch mal den alten Server benchmarken.

ICjkzdC

»

Warum Ubuntu immer schlechter wird

Ich habe hier IPv6 auf Vodafone zum laufen gebracht und wollte mal schnell was in einer Lubuntu 16.04.3 VM testen (noch nicht auf dem neuen Server, da fehlt immernoch das RAM). Dabei fiel mir auf, dass folgendes Kommando funktioniert:

dig -6 heise.de a @2a02:810c:c83f:d6f0:20d:b9ff:fe45:ce7a

aber dieses nicht:

dig -6 heise.de a

Das war sehr verwunderlich, da "2a02:810c:c83f:d6f0:20d:b9ff:fe45:ce7a" mein lokaler Nameserver ist und dieser Ubuntu auch bekannt ist.

Das Kommando versucht den A Record für heise.de zu resolven. "-6" gibt an, dass es dazu nur IPv6 benutzen soll. "@IP" gibt an, dass eben dieser Nameserver gefragt werden soll.

Dass der Nameserver dem System wirklich bekannt ist, weiß ich durch folgendes Kommando:

nmcli -t device show enp0s3 | grep IP6.DNS

Die Ausgabe davon ist:

IP6.DNS[1]:2a02:810c:c83f:d6f0:20d:b9ff:fe45:ce7a

Das passt also.

Warum funktioniert es dann nicht?

Ganz einfach, die Spezialexperten von Ubuntu konnten natürlich nicht einfach die ermittelten Nameserver nach /etc/resolv.conf schreiben, sondern mussten das abstrahieren. In /etc/resolv.conf steht jetzt nur noch "nameserver 127.0.1.1" was eine Localhost Addresse ist. Und auf Localhost lauscht dieser Prozess hier:

cbubel@lubuntu-vm:~$ sudo netstat -tulpn | grep 53
tcp        0      0 127.0.1.1:53            0.0.0.0:*               LISTEN      919/dnsmasq     
udp        0      0 127.0.1.1:53            0.0.0.0:*                           919/dnsmasq

Und damit hätten wir auch schon das Problem gefunden.

Natürlich kann dig nicht IPv6 benutzen, wenn der verdammte dnsmasq nur auf dem IPv4 Localhost lauscht. Damit das funktioniert müsste noch ein ::1/128 in die resolv.conf und dnsmasq müsste natürlich auch darauf hören. Einfach mal ne Config ändern reicht hier nicht, da muss man erstmal die Config anlegen, da das alles hard gecoded ist. Wers nicht glaubt, möge mal die Stelle suchen, an der dnsmasq gesagt wird, dass er auf localhost hören soll.

Ob das Problem auch in 17.04 besteht, weiß ich nicht. Aber schlimm genug, dass es keinem im LTS aufgefallen ist.

Update: Ja auch 17.04 ist kaputt, etwas anders zwar, aber kaputt. Dnsmasq scheint durch systemd ersetzt worden zu sein, aber da bin ich mir nicht absolut sicher.

»

Neuer Fileserver Teil 7 - Instabil

Habe nun einige VMs installiert und angefangen alles ausgiebiger zu testen. Als ich größere Files vom alten Fileserver in die neue FreeNAS VM kopiert habe blieb das ganze System nach ein paar GB stehen. Auch beim Import einer großen VM ist mir der Server abgesürzt. Zum Ram hatte ich zwar vertrauen, da der Memtest diesmal tatsächlich lief, aber das könnte immernoch die Ursache der Probleme sein.

Ich muss mal schauen, ob ich anderes RAM zum testen besorgen kann, am besten welches, das auch in der Kompatibilitätsliste von Supermicro auftaucht.

»