"openSUSE ist nur bedingt als Server geeignet."
auf was möchtest Du da hinaus?
Wenn ich mich "kluch" mache, so lese ich, ist der Unterschied Leap vs. Enterprise längst nicht mehr so gros (sprich 99% identisch) wie es zu früheren Zeiten war
Ich kann Dir schon (m-)eines verraten: im Universitären Umfeld ist das Geld nicht in rauen Mengen vorhanden und wird da eingesetzt, wo es unabdingbar ist - in die HW ,-)
Ob es auf Dauer sich bestätigt, wird sich zeigen;
Der VM-Ware-Support war der Ansicht, dass der Raid-Controller-Treiber (lsi-mr3) die Ursache des Debakels ist.
Zuvor => Version: 6.910.18.00-1vmw.650.0.0.4564106
Danach => Version: 7.700.50.00-1OEM.650.0.0.4598673
Warum das aber im Update "U1" dieser nicht mitenthalten ist, wissen wohl die Götter.
Vorerst zusammengefasst: ich bin die Kopier-Orgie schlicht hin "falsch" angegangen? (Die Zeit ist nicht das Entscheidende - da scheiden sich die Geister was "das bessere", sprich schnellere, ist.)
Aber:
-der Kopier-Prozess (Anfänger Krücke "mc") läuft auf dem Quell-Host
-das einfrierende System ist der Ziel-Host (hat bis auf den nfs-service und schreiben des empfangenen nichts zu tun und ist um längen "stärker" als der Quell-Host)
-das "Protokoll" ist nfs4 (!)
desto trotz: ist ein solches verhalten des Ziel-Systems normal? (Das kann doch nicht wahr sein. Pardon, aber da kann ich gleich ein Win-Server benutzen und mich mit AD/cifs/samba rumquälen)
...bis jetzt ist der Ziel-Host NICHT (mehr) in die Knie :-/ - es fehlen "nur" noch 70GB oder 1'600'000 files....dann ist die "Origie" zu Ende (mit schlechtem Gewissen da der Ziel-Host für die 8.5TB ca 10x eingefroren war)
mc=midnight commander => F5, mit "Attribute sichern"
...aber der arbeitet ja auf dem Quell-System - ¿?
Soweit so gut - die Ausgabe läuft nun auf ein sshfs-mount
Mehr Licht ins Dunkle (ich versuche so gut es geht - ich weiss ja nicht wie/was ich "ausleuchten" soll um möglichst viel an Infos bereit zu stellen):
Quell-System (vmware 6.5.0):
openSuSE 12.2 (64bit)
nfs-client-1.2.6-2.16.1.x86_64 (nfs4)
Ziel-System (vmware 6.5.0, U1):
openSuSE Leap 42.3
nfs-kernel-server-1.3.0-28.1.x86_64 (nfs4)
(/data liegt als 1x15TB vm-File, Thin provisioned), ext4 auf echten Raid, in eigener Partition, 21TB)
/etc/export ==> /data *(rw,no_root_squash,sync,no_subtree_check)
Ein nfs-mount (mount ziel:/data /mnt/data) habe ich auf dem Quell-System gemacht, wo folglich auch der copy-job läuft
(mc, so sehe ich beim kontrollieren ob noch und wieviel wie schnell kopiert wird - was ich +/- auch im vmware-monitoring sehen kann/könnte)
Das Quell-System läuft non-stop ohne Fehler weiter - auch wenn das Ziel-System sich verabschiedet hat
Entschuldigt bitte meine etwas "naive" Art - gerne werde ich mich bemühen möglichst rasch und umfassend Informationen bereit zustellen - doch ist mir das "einkreisen" meines Problems absolut nicht geläufig
BTW: u.a. habe ich auch versucht die Daten per netcat rüber zu bekommen. Da war das Resultat noch ernüchternder (von scp ganz zu schweigen) - zumal viele kleine Dateien vorhanden sind (langsam) - das Ziel-System ging noch rascher in die Knie - sprich frierte ein.
Beim Verzeichnis "/data" handelt es sich um 8.5TB an Daten die vom alten zum neuen System gelangen müssen - die Anzahl Files habe ich bis dato noch nicht erruiert...werden aber zig Milionen sein (z.T. sind in einzelnen Verzeichnissen +/- 40'000 Dateien). Die Dateien sind meist wenige kB gros, z.T. 20-40 MB - wenige sind im GB Bereich)
zur Zeit wird dies nicht möglich sein - das Leap hat nur diesen Storage (/, /home, /data in separaten hd-images auf dem externen RAID-Speicher angelegt) und der interne RAID-0 ist exclusiv für die vmware.
ein nfs-mount wird, so denke ich, früher nicht mehr ansprechbar sein - ergo lasse ich dies mal bleiben. ich bin gespannt;
zur aktuellen Zeit sind wieder die >120gb ram in benutzung (>160gb kopiert, 800'000 dateien). es gibt mit dem jetzigen copy-job noch weitere 160gb zu kopieren - oder anderst gesagt 3'500'000 dateien....
Guten Morgen
@Sauerland: was die CPU im Zielsystem dann derart belastet kann ich nicht mehr herausfinden da das System nicht mehr ansprechbar ist - auch nicht per vmware-konsole
Berichtigung: verzeih mir meine fehlerhafte Formulierung. Der Controller ist natürlich kein SCSI (Asche auf mein Haupt) => 8 Port SASIII Dual Core Raid Kontroller mit 2 externen SASIII Ports (wovon 1 verwendet wird)
Was ich derweilen feststellen konnte:
Wärend dem kopieren wird 1:1 zum kopierten auch der Arbeitsspeicher des Zielsystems aufgebraucht. Warte ich zu bis dieser "aufgebraucht" ist, System arbeitet noch, lässt sich kein reboot/halt durchführen - das system friert darauf hin ein.
Unterbreche ich den kopier Vorgang vorzeitig, (20-60gb speicher werden verwendet), lässt sich das Leap wohl neu starten. Innerhalb diesem wird nach dem Reboot der gesamte zugeteilte Speicher als frei angezeigt - jedoch seitens vmware bleibt die Speicherauslastung (gesamt, wie auch der Instanz) unverändert (¿?).
Bei beiden Scenarios, wenn das System noch läuft und nicht abgeschmiert ist, wird der Speicher erst freigegeben wenn ich die Instanz "power off" mache.
Ein "power off" der Instanz funktioniert auch nur, wenn diese noch ansprechbar war. Wie im ersten Betrag erwähnt, wenn die Instanz "tot" ist, lässt sich auch kein "power off" mehr durchführen - der ESXi selbst lässt sich dann auch nicht mehr rebooten - ein brutaler "hard reset" ist dann nötig um die komplete Kiste neu hochzufahren.
Add:
Berichtigung: werde beide iotop laufen lassen - hoffe dass das System nochmals in die Knie geht um Sachdienliches rückmelden zu können
Im Gebiet Serveradministration bin ich auf Neuland - daher meine Hoffnung zur Lösungsfindung hier;
Habe das Problem das eine Leap 42.3 Installation regelmässig spätestens nach 2 Tagen einfriert. Das System hat zur Zeit nur dieAufgabe ein Ordner per NFS freizugegeben. Auf diesen werden non-stop Daten kopiert - der Kopier-Prozess läuft auf der Gegenseite. Das Share ist ein externer Datenspeicher (RAID) per SCSI angeschlossen
Meine erste, naive, Feststellung ist, dass ab dem Zeitpunkt wie Daten kopiert werden, der Arbeitsspeicher zunehmend "aufgefressen" wird - der Swap wird nicht beansprucht. Wie das System einfriert, wird ab diesem Zeitpunkt rapid die CPU beansprucht - bis zur Volllast obwohl nichts mehr geht. Der Host gibt auch kein Ping mehr zurück - "tot"
Wie kann ich die Herkunft dieses Fehlers eingrenzen? Wo/Wie soll ich "an die Sache" rann gehen das ich die "Kiste zum fliegen bekomme"?
Ich bin da wirklich auf fremde Hilfe angewiesen da wie bereits erwähnt, ich ein Newbee i.s. Serveradministration bin.
Die Installation läuft auf einem (und einzige Instanz) ESXi 6.5.0 mit U1 Update (build 5969303)
Hardware ist ein Intel S2600CWR, 128GB Ram, 2 CPU (XEON E5-2683 v4)
Herzlichen Dank um jeden Hinweis wie ich das angehen muss/soll
Marc
