Seite 5 von 41 ErsteErste 12345678915 ... LetzteLetzte
Ergebnis 61 bis 75 von 609

Thema: Schnattis Server wird gewartet

  1. #61
    kräpelt herum Avatar von Schnatti
    Registriert seit
    17.02.16
    Beiträge
    1.062
    ...und heute ist es nun komplett vorhanden...
    ...allerdings mit den Daten von gestern Nacht (also Daten von vorgestern), nicht heute Nacht.
    Mundus vult decipi, ergo decipiatur.

  2. #62
    Registrierter Benutzer Avatar von drdope
    Registriert seit
    27.04.13
    Beiträge
    486
    Falls du die Tage Netzwerkprobleme mit deinen VMs bekommen solltest...
    --> https://www.heise.de/security/meldun...n-3996689.html

    Die Diagnose ist einfach -> deine VMs haben MS.

  3. #63
    kräpelt herum Avatar von Schnatti
    Registriert seit
    17.02.16
    Beiträge
    1.062
    Emoticon: huch
    Mundus vult decipi, ergo decipiatur.

  4. #64
    kräpelt herum Avatar von Schnatti
    Registriert seit
    17.02.16
    Beiträge
    1.062
    Hm, also die Haupt-VM läuft ja mit Linux, der Verwaltungs-Rechner aber mit Windows.
    Zugriff habe ich aktuell auf dort und auch von dort in's Netzwerk.

    Bin ich quasi aus irgendeinem Grund safe oder merke ich das noch "woanders"?
    Oder habe ich nur noch nicht das Update durchgeführt und merke daher nix?

    edit:
    Und muss ich mir Gedanken machen, wenn der NAS repetitiv (!) beim täglichen Virenscan 3 Dateien (Druckertreiber) als befallen mit Win.Trojan.Agent-1238979 identifiziert und in Quarantäne steckt? Daten liegen auf dem Quell-PC und natürlich wegen des neu initiierten Backups auch auf dem NAS.
    Geändert von Schnatti (17. März 2018 um 14:31 Uhr)
    Mundus vult decipi, ergo decipiatur.

  5. #65
    kräpelt herum Avatar von Schnatti
    Registriert seit
    17.02.16
    Beiträge
    1.062
    Huhu,

    da ich ja (fast) eine Woche lange keine neue traumhafte Unsicherheit in den Raum geworfen habe, ist es heute mal wieder soweit.

    Zum Zwischenstand der Dinge:

    1)
    Die "neue alte" Hot Spare-HDD im Server läuft und er gibt sich ohne bisherige Fehlermeldung zufrieden.
    Laut SAS-Bios ist sie tatsächlich als Hot Spare laufend, wenngleich ich kurz verwundert war, dass die Status-LED der HDD auf grün läuft. Ich dachte die "pennt" wirklich total inaktiv die ganze Zeit jetzt vor sich hin, bis der nächste HDD-Fehler ihre Notwendigkeit auf den Plan ruft. Korrekt soweit? Oder würdet ihr meinen, dass die HDD tatsächlich "optisch inaktiviert", sprich mit komplett erloschener LED da sein muss?

    2)
    Die neue SSD ist im Zentral-Client eingebaut, ich habe sie parallel zur bisherigen SATA laufen und eben die Datenmigration mit der von drdope angegebenen Software seitens Samsung angestoßen. Morgen dann wenn alles soweit geklappt hat mal standalone die SSD anschließen und schauen was passiert.

    3)
    Der RAM für den Zentral-Clienten ist ebenso gekommen, hier kommt jetzt die eigentliche Frage, bevor ich die versiegelte Umverpackung öffne:
    Ist es ohne jeden Zweifel per se unproblematisch, wenn die RAM-"Riegel" von der Höhe her nur halb so dimensioniert sind?
    Der neue Speicher ist https://www.cyberport.de/pc-und-zube...7-ram-kit.html, die Spezifikationen sahen für mich ok aus. In dem Moment, wo der Speicher jetzt vor mir liegt und ich ihn mit dem bisher eingebauten vergleiche, fällt halt direkt die unterschiedliche Bauhöhe auf. (ca. 1cm beim neuen, sicher das Doppelte beim alten)

    Die Frage mag nun also lächerlich sein, aber so ewig lange ich mit dem Hardware-Thema nichts zu tun gehabt habe, will ich mich da gerne rückversichern. Noch habe ich ja nichts irreversibel geöffnet.

    Bilder, falls notwendig, gerne morgen.

    Danke euch...

    P.S.:
    Die Virenfrage oben war auch tatsächlich ernstgemeint.
    Drüber hinwegschauen, weil Missinterpretation seitens des Virenscanners oder unbedingt nachverfolgen?
    Mundus vult decipi, ergo decipiatur.

  6. #66
    kräpelt herum Avatar von Schnatti
    Registriert seit
    17.02.16
    Beiträge
    1.062
    Mundus vult decipi, ergo decipiatur.

  7. #67
    Registrierter Benutzer Avatar von drdope
    Registriert seit
    27.04.13
    Beiträge
    486
    sorry aktuell ND und Streß...

    1) ist ok so; deshalb heißt sie Hotspare...
    2) und wie löppt es nun?
    3) kommt nicht auf die physikalische Größe der Module an; wenn die Specs passen, sollten sie auch laufen...

    wg der Viren:
    Auf dem NAS sind sie quasi egal und können da nichts anrichten;
    lösch die Einfach und zieh aktuelle, saubere Treiber von der Herstellerseite.

    Wenn du wirklich wissen willst, ob es ein false positiv ist
    --> die gleiche Treiberversion noch mal runter laden und und ebenfalls scannen;
    ggf. noch mal Dateigrößen und MD5/SHA256-Checksummen vergleichen...

  8. #68
    kräpelt herum Avatar von Schnatti
    Registriert seit
    17.02.16
    Beiträge
    1.062
    Danke dir noch für die Antwort, bin heute morgen erst zurückgekehrt.
    Den RAM baue ich dann später (heute Abend evtl.) noch ein.

    Schon nach dem SSD-Wechsel ist der Unterschied enorm, der Tipp war super. Da ich jetzt den Arbeitsspeicher aber einmal hier hab, würde ich auch den Tausch noch vornehmen.
    Das Migrieren der Daten war mit dem Samsung-Tool auch reibungslos, habe bis jetzt keine ersichtlichen Probleme.
    Nicht, dass ich mich schon sicher wähnen würde und so, aber die Differenz ist wirklich sehr sehr positiv ausgefallen.

    Jetzt kommt vermutlich demnächst der restliche Unfug an Fragen meinerseits, den die kommende Datenschutzverordnung so mit sich bringt...
    Mundus vult decipi, ergo decipiatur.

  9. #69
    kräpelt herum Avatar von Schnatti
    Registriert seit
    17.02.16
    Beiträge
    1.062
    RAM hat auch gepasst. Merci.
    Mundus vult decipi, ergo decipiatur.

  10. #70
    Registrierter Benutzer Avatar von drdope
    Registriert seit
    27.04.13
    Beiträge
    486


  11. #71
    kräpelt herum Avatar von Schnatti
    Registriert seit
    17.02.16
    Beiträge
    1.062
    Schei**e, es geht prompt weiter...

    Genau vor einer Woche war schon meine Kollegin im Samstagdienst plötzlich morgens mit einem nicht funktionierenden Server konfrontiert, heute genau 1 Woche später bin ich es. Unter der Woche ging alles reibungslos.

    Problembeschreibung:
    - der virtualisierte Server ist morgens gegen 8 Uhr nicht mehr erreichbar (sicher auch schon eher), kein normaler "Betrieb" für uns möglich
    - bis gestern Abend war auch alles wieder unauffällig
    - ein Login auf den Host per vSphere-Client zur Überprüfung der VM ist schon nicht möglich
    - der Host-Server läuft aber scheinbar grundsätzlich, die Bildschirmoptik ist wie immer
    - aber: der Host (VMWare ESXi) "stürzt" beim Admin-Login ab, das war letzte Woche so und auch eben bei mir selbst
    - bis hierhin ist bildschirmoberflächlich optisch alles wie immer - das Fenster friert aber im Login-Bildschirm nach Eingabe aller Daten (der Rechner reagiert bis hierhin wie gewohnt!) ein, wobei der Cursor vom Passwort auch noch weiter blinkt
    - ich muss den Host kalt neustarten, sehe zumindest immer keine anderweitige Escape-Möglichkeit
    - die beiden VM sind auch nach dem Neustart beide heruntergefahren, sind schon in der Nacht irgendwie "beendet worden"

    3 Fragen:
    - gibt's irgendeinen typischen Verdacht aus der Beschreibung?
    - ich kann mir das Host-Protokoll für den vermeintlichen Zeitraum zwar per Bildschirmausgabe anzeigen lassen, hier aber nicht ohne weiteres zur Verfügung stellen ohne es abzutippen - würde es trotzdem was nützen, wenn ich mir die Mühe mache?
    - unter der 2. VM läuft ja Windows, wie kann ich da mit Bordmitteln ggf. auch ein Log generieren? Die VM verabschiedet sich ja ebenfalls irgendwann nachts, ich weiß aber nicht ob beide gleichzeitig den Geist aufgeben

    Danke für Rückmeldungen, sofern jemand Laune hat.
    Mundus vult decipi, ergo decipiatur.

  12. #72
    Hegemon mit Eierkopf Avatar von Fonte Randa
    Registriert seit
    09.03.05
    Ort
    Forunkel am Arsch der Demokratie im Landeshauptdorf der Börde
    Beiträge
    22.405
    Statt tippen würde ich ein Foto machen. Handy.
    hier steht eine Signatur
    Die EG-Bildungsminister: Lesen gefährdet die Dummheit!
    Alle PNs mit Interviewantworten werden veröffentlicht!


  13. #73
    Registrierter Benutzer Avatar von drdope
    Registriert seit
    27.04.13
    Beiträge
    486
    Yupp... mach einen Screenshot mit dem Handy...

    Wenn der ESXi-Host reproduzierbar/regelmäßig (n=2 ist da noch nicht sonderlich aussagekräftig) in der Nacht von Freitag auf Samstag abschmiert,
    würde ich den Fehler zuerst beim ESXi selbst suchen.
    Das die beiden VMs vorab sauber herunter gefahren wurden spricht imho auch dafür, daß es kein Hardwareproblem ist (Shutdown wurde seitens des ESXi initiert).
    Wenn die Kiste ansonsten über die Woche sauber läuft, würde ich noch den nächsten Fr/Sa abwarten, bevor man in Aktionismus verfällt.
    Bei der dritten Inzidenz, spricht nur noch wenig für ein zufälliges Ereignis.

    Hängt der Server zufällig an einer USV, deren Akkus so alt sind wie der Rest der Installation?
    Macht die USV "zufällig" (idR hat das jemand so eingerichtet) in der Nacht von Freitag auf Samstag einen selbsttest, den der ESXi sogar selbst initiert?
    Geändert von drdope (07. April 2018 um 23:29 Uhr)

  14. #74
    kräpelt herum Avatar von Schnatti
    Registriert seit
    17.02.16
    Beiträge
    1.062
    Das hier ist der vKernel-Log, der Syslog geht leider nicht mehr bis zum Zeitpunkt von vor dem Ereignis zurück.
    Ausser der ist nie dafür gedacht und läuft wieder von "0", sobald der Rechner neu hochfährt, dann ist klar...

    Bild

    Die Zeitstempel sind ja bis zu einem gewissen Punkt ersichtlich, dann ist Ruhe und irgendwann danach dürfte der Neustart gelaufen sein, oder?
    Das oben drüber liest sich ja aber alles nicht sooo sauber mit diesen Performance- und Latenzmeldungen.
    Naja, ich bin da nicht zuhause, vielleicht lässt es sich damit eingrenzen?

    Laut Server-Admin führte der Server dieses Mal übrigens am Samstagmorgen gegen 5 Uhr keine Aktion mehr aus, die geloggt wurde, die Woche davor war es jedoch am Freitagmorgen, gleiche Zeit. (Freitag war da ja Feiertag, daher die falsche Zuordnung meinerseits auf den Samstag)
    Damit ist es bisher scheinbar doch eher nicht im 7-Tages-Abstand...ich freu mich trotzdem schon auf kommenden Samstag.

    Der USV-Akku wurde bereits 1x getauscht, vor fast genau 1 Jahr, das hielte ich fast für ausgeschlossen.
    Fast...
    Angehängte Grafiken Angehängte Grafiken
    Mundus vult decipi, ergo decipiatur.

  15. #75
    Registrierter Benutzer Avatar von drdope
    Registriert seit
    27.04.13
    Beiträge
    486
    Zitat Zitat von Schnatti Beitrag anzeigen
    Die Zeitstempel sind ja bis zu einem gewissen Punkt ersichtlich, dann ist Ruhe und irgendwann danach dürfte der Neustart gelaufen sein, oder?
    Das oben drüber liest sich ja aber alles nicht sooo sauber mit diesen Performance- und Latenzmeldungen.
    Naja, ich bin da nicht zuhause, vielleicht lässt es sich damit eingrenzen?
    Ich kann da auch nichts anderes heraus lesen...

    Zitat Zitat von Schnatti Beitrag anzeigen
    Server-Admin führte der Server dieses Mal übrigens am Samstagmorgen gegen 5 Uhr keine Aktion mehr aus, die geloggt wurde, die Woche davor war es jedoch am Freitagmorgen, gleiche Zeit. (Freitag war da ja Feiertag, daher die falsche Zuordnung meinerseits auf den Samstag)
    Damit ist es bisher scheinbar doch eher nicht im 7-Tages-Abstand...ich freu mich trotzdem schon auf kommenden Samstag.

    Der USV-Akku wurde bereits 1x getauscht, vor fast genau 1 Jahr, das hielte ich fast für ausgeschlossen.
    Fast...
    Was mich stutzig macht -> der Server läuft unter Woche im Alltagsbetrieb ohne Probleme und zu Zeiten wo theoretisch Null Last anliegen (wenn da keine geplanten Tasks laufen) sollte, schmiert er ab... das ist eher untypisch...

    Kannst ja aus Spaß mal:
    /var/log/hostd.log
    /var/log/syslog.log
    /var/log/vmkernel.log
    /var/log/vmkwarning.log
    /var/log/vmksummary.log
    für die jeweiligen Zeiträume posten... bin mir aber nicht sicher, ob die nicht bei einen Reboot neu angelegt werden...

    Kannst du via
    Code:
    #cat /var/log/hostd.log | grep -i 2018_04_07T04:3*
    mal schauen, ob dir der Server das Log des Tages von 04:30:01-04:39:59 ausspuckt?

    Wenn das klappt, könntest du die 2x fünf Logfiles für den Ausfallzeitraum mal in eine Datei schreiben und die hier hochladen/pasten.
    Code:
    #cat /var/log/$filename.log | grep -i 2018_$dateT$time > $filename
    Cave -> du mußt die Variablen anpassen!
    Die Files landen in dem Verzeichnis, in dem du dich gerade befindest; kannst du dann via scp runter kopieren, wenn ssh auf dem ESXi löppt (wovon ich ausgehe).


    Kannst auch mal aus Spaß in die "Crontabs" gucken, ob da evtl. Jobs angelegt sind, die mit dem Ausfallzeiten korrelieren.
    --> http://man7.org/linux/man-pages/man8/cron.8.html
    --> https://wiki.gentoo.org/wiki/Cron/de (für den ESXi hab ich auf die schnelle kein schönes "rtfm" gefunden)
    Aber Linux ist immer irgendwie Linux...
    Geändert von drdope (10. April 2018 um 09:50 Uhr)

Seite 5 von 41 ErsteErste 12345678915 ... LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •