NFS Storage - timeout

    Hallo zusammen,


    gibt es neben mir noch jemanden der nach dem Storageausfall das Problem hat sein "Laufwerk" anzuziehen ?
    Laut dem Mailverkehr mit dem Support muss das Problem an meinen Servern liegen - obwohl das bis zum Ausfall problemlos funktioniert hat :(


    Das selbe Problem trat hier wohl auch schon einmal auf: Storage Space lässt sich nicht mounten
    Leider wurde da keine Lösung beschrieben.


    Folgende Maßnamen wurde bereits durchgeführt:


    - der Storagespace wurde vollständig gelöscht und unter anderem Namen neu angelgt
    - der Support kann das neue (aber auch das alte) Laufwerk problemlos anziehen - ich bekomme mit keinem Server eine Verbindung
    - die IP Adressen aller beteiligten Systeme wurden im ccp hinterlegt
    - eine temporäe Löschung aller iptables chains bringt keine Änderung
    - der Versuch endet immer mit: mount.nfs: Connection timed out
    - das Paket nfs-common wurde gepurged und neu installiert
    - mtr liefert keine Antwort vom NFS-Storage - auf keinem VS


    alle drei KVMs sind Wheezy Maschinen.
    Ich kann mir nicht wirklich vorstellen das das an mir liegen soll, denn bis zum Ausfall lief das System problemlos.


    Hat jemand noch eine Idee ?

    Funktioniert es denn im Recovery-System? Ich weiß, die Frage nervt! Aber manchmal ist das ein guter Ansatzpunkt… :D



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Probier es einfach mal aus, dann dürfte eindeutig klar sein, wo der Fehler liegt – das erspart lange Diskussionen! :)



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Ach schön :(
    Ich lerne hier immer wieder was neues ....
    Ich kann meine Maschine nicht in den Rettungsmodus bringen - zumindest zeigen das die Tatsachen.


    Laut VCP ist die Maschine im Rettungsmodus - der Faktenlage nach ist sie es nicht.
    Ich habe mehrmals die Vorgehensweise überprüft, irgendwann dann auch mal nach Anleitung weil ich mit blöde vor kam *G


    VCP sagt: ja du bist im Rettungsmodus.
    KVM sagt: VCP erzählt mist - ich bin im Normal Modus.


    Da kommt man sich schon ein bissel blöde vor wenn man mit den genannten "root" Daten nicht einloggen kann, bzw. nicht mal der Port stimmt.
    Login geht in meinem "Rettungssystem" nur mit meinen persönlichen Daten. Root kann sich nicht einloggen - Port 22 gibts nicht für SSH usw.


    Hat das schon mal jemand erlebt ?


    Hier steigt gerade um so mehr das Verlangen ein Backup anlegen zu wollen *grml

    re,


    irgendwas läuft hier falsch ... gerade die Hotline angerufen und das Problem geschildert.


    klick - klick - geht ... Komentar: Wenn man es denn richtig gemacht hätte...


    Langsam glaube ich ich bin im falschen Film.
    Wenn ich Neukunde wäre würde ich sagen, ok da bist wohl zu blöde aber ich mache den Kram hier jetzt seit mehr als 5 Jahren.
    Da ist es mir schon etwas befremdlich das an der Hotline "alles geht" und bei mir eben nicht.
    Ich besorg mir jetzt erst mal einen Screenrecorder - das kann es ja nicht sein....

    Die häufigste Fehlerquelle dürfte eine falsche Bootreihenfolge sein. Dann kann das Rettungssystem nämlich nicht gestartet werden. Und wenn ich das richtig im Kopf habe, wird die neue Bootreihenfolge manchmal nicht übernommen, wenn man das System danach nicht explizit ausschaltet (Poweroff) und/oder einen Reset durchführt. Das OS sollte natürlich vorher entsprechend heruntergefahren werden. Zur Not kann man Poweroff/Reset einfach ausführen, während die Maschine im Grub hängt. Das ist zumindestens meine persönliche Erfahrung, ich kann das erst später verifizieren.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    • Offizieller Beitrag

    Guten Tag,

    Zitat von ramstein

    Rettungssystem – netcup Wiki


    Ist zwar ein wenig veraltet, aber geht noch :)

    "Die Reihenfolge muss so definiert werden, dass links in der Box Ausgewählt der Start über das Netzwerk an erster Stelle steht."


    Sie hatten bei Ihrem Anruf CDROM an erster Stelle. Somit ist erklärt, wieso der Start ins Rettungssystem nicht funktioniert hat. Ich hatte während unserem Telefonat lediglich Network an die erste Stelle geschoben.

    Zitat von [netcup] Brian

    Sie hatten bei Ihrem Anruf CDROM an erster Stelle. Somit ist erklärt, wieso der Start ins Rettungssystem nicht funktioniert hat. Ich hatte während unserem Telefonat lediglich Network an die erste Stelle geschoben.

    Natürlich, das war das System längst wieder im Produktivbetrieb, sprich alle Einstellungen für den "normalen" Bootvorgang.
    Daher war ich auch wenig begeisterst als das System während meines Anrufs in den Rettungsmodus versetzt wurde :(

    • Offizieller Beitrag

    Guten Tag,


    hier muss natürlich vorher die Erlaubnis des Kunden eingeholt werden, das war eindeutig mein Versäumnis. Um dieses Thema abzuschließen skizziere ich nochmal die (auf einem Testsystem soeben nochmals erfolgreich getestete) Vorgehensweise:


    Network in der Bootreihenfolge an erste Stelle -> Power Off -> Rettungssystem aktivieren -> Server starten


    Bitte berichten Sie in dem Thread, ob die Problematik mit dem NFS Storage im Rettungssystem reproduzierbar ist.


    Vielen Dank.

    moin moin ...


    Gerade ging der Rescuemode problemlos - muss wohl an der Aufzeichnung gelegen haben :)
    Aber auch dort kann ich das Laufwerk nicht mounten, es erscheint folgende FM:


    mount: wrong fs type, bad option, bad superblock on 46.38.248.196:/vol-33669-2,
    missing codepage or helper program, or other error
    (for several filesystems (e.g. nfs, cifs) you might
    need a /sbin/mount.<type> helper program)
    In some cases useful info is found in syslog - try
    dmesg | tail or so


    und jetzt ?

    Guten Morgen,



    das von Ihnen genannte Volume liegt auf einem anderen Storage. Verwenden Sie für den Mount die Ziele, die Ihnen auch im CCP angezeigt werden. 46.38.248.196 ist nicht für das Volume vol-33669-2 zuständig. So kann das nicht funktionieren...


    Mit freundlichen Grüßen


    Felix Preuß

    Öhm ... ok :)


    Kann es denn sein das "46.38.248.196:/vol-33669-1" die korrekte Daten gewesen wären ? (Das war mein "alter, defekter" Share)
    Ich frage mich ja wie ich an diese Daten gekommen bin ...


    Nachdem das nun gelöst ist möchte ich mich bei allen Beteiligten entschuldigen das ich hier so eine Welle ausgelöst habe.
    Ich überlege mir was passendes ....