Hadoop : 2 SimpleNode cluster (eins mit windows und der andere mit opensuse) zu einem zusammenfügen.

[Dimax]

Guten Tag,

Ich habe 2 SimpleNode cluster fertiggestellt.Der erste läuft unter Windows der andere unter OpenSuse. Beide habe ich getestet und alles läuft.
Der nächste Schritt für mich ist ,beide cluster zusammenfügen.Hat vielleicht jemand Ahnung wie das geht und überhaupt ob es möglich ist.

Vielen Dank im Voraus.

 

[kneitzel]

hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/ClusterSetup.html

Da findest du Informationen bezüglich aufsetzen eines Clusters. Und ja: es spielt keine Rolle, ob da Linux oder Windows als Basis drunter läuft.

 

[Dimax]

Und ja: es spielt keine Rolle, ob da Linux oder Windows als Basis drunter läuft.

Das ist nicht ganz richtig..Ich schreibe später was die Unterschiede sind.

 

[Dimax]

Der erste Unterschied ist beim speichern des ssh-Schlüssels.
ssh-keygen -t rsa -P ""-funktioniert.Der Schlüssel wird generiert.
cat $HOME/.ssh/id_rsa.pub >> $HOME/.ssh/autorized_keys -cat gibt es nicht im Windows
alternative für Windows ->scp C:\Users\user1\.ssh\id_rsa.pub user1@domain1@contoso.com:C:\Users\user1\.ssh\authorized_keys -von der Microsoft Seite.Und ssh-Client muss man nachinstallieren.
Connection reset by blabla port 22
lost connection.Beim Versuch die ssh Verbindung aufzubauen ssh localhost
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
Unter Linux dieser Schritt lief einwandfrei.

 

[kneitzel]

Also das Linux Befehle nicht unter Windows laufen, ist hoffentlich keine Überraschung. Und die Befehle, die Du da z.B. genannt hast, sind einfache SSH Befehle zum generieren eines Keypaares und dann das kopieren der id um ohne Passwort sich anmelden zu können.
==> Hat erst einmal nichts mit Haadop zu tun und wenn man Befehle nicht versteht, wäre ich auch extrem vorsichtig, diese einfach anzuwenden. Jemandem ohne Kontrolle des Passwortes nur mit einem generierten File Zugriff zu geben halte ich z.B. für wenig sinnvoll wenn es um möglicherweise produktive Systeme geht. Aber das muss man nicht diskutieren - das soll jeder so machen, wie er es für richtig hält.

Und wenn jemand Windows Systeme verwaltet, dann hat man andere, deutlich umfangreichere Möglichkeiten zur remote Administration als nur ein relativ dummes SSH.

Aber zurück zu Haadop: Die Webseite, die ich z.B. verlinkt habe, verzichtet da auf einiges, wobei die Syntax teilweise BASH ist und so unter Windows nicht funktioniert (export einer Umgebungsvariable z.B. oder das /etc/profile.d, das erwähnt wird).

 

[Dimax]

wenn es um möglicherweise produktive Systeme geht

Es geht ja um Hadoop,und es geht darum einige Informationen von einem cluster mit dem MapReduce Algorithmus zu holen.Du kanst ja nicht auf jedem cluster PC sich manuell einloggen).Wenn du dein link selbst öffnest ,da kann man lesen ,die schreiben über ssh ohne pass .

 

[kneitzel]

Also irgendwie reden wir etwas aneinander vorbei fürchte ich fast...

Also gehen wir mal die Punkte der Reihe nach an:

a) Dein SSH Problem auf Windows Seite:
Hier wäre meine Vermutung, dass Du die known_hosts Datei mit kopiert hast und daher localhost nun einen anderen private key hat als erwartet. Die Meldung von ssh solle aber so aussagekräftig sein, dass dies schnell zu beheben sein dürfte.
(Sprich: den falschen Eintrag in der known_hosts entfernen)
Es kann natürlich auch andere Gründe geben, z.B. die erneute Erzeugung von private Keys für den Server nach einem bereits erfolgten connect.

b) Mögliche Installationen unter Windows:
Man kann Hadoop direkt unter Windows installieren (ggf. mit zusätzlichen Binaries, da die *.so Dateien so erst einmal nicht unter Windows funktionieren - z.B. https://github.com/cdarlint/winutils).
Man kann aber auch das Windows Subsystem für Linux (WSL) nutzen. Dann hat man eine Installation unter Linux (Ubuntu nutzt Microsoft für das WSL wenn ich das richtig verstanden habe).

c) Zusammenarbeit bei Installationen
Generell implementiert Hadoop hier ja eigene Protokolle, sprich die Services kommunizieren miteinander. Dies ist unabhängig vom Betriebssystem, daher sollte eine Windows Installation mit Linux Installationen zusammen arbeiten ohne dass es zu großen Problemen kommt. Ich muss aber gestehen, dass ich dies noch nicht wirklich gemacht habe. Werde ich einmal bei Gelegenheit ausprobieren, in dem ich einen Windows slave bei mir hinzu füge.

d) Abhängigkeit zu SSH
Nach meinem Verständnis ist die Abhängigkeit zu SSH nur doch nur in erster Line für das Management des Clusters. Für die eigentliche Nutzung ist es später nicht notwendig, denn die Client connecten sich zu dem Master und der verteilt dann doch meines Wissens nach die Aufgaben und so. Aber ich muss gestehen, dass ich mich hier nur sehr oberflächig eingelesen habe.
Aber die Installation des Windows Nodes, den ich gerade plane, werde ich ohne irgend eine SSH Installation durchführen.

Und natürlich erfolgt dann die Verwaltung über Windows Boardmittel. Ein einfaches Powershell-Script könnte da schon ausreichen (Wobei es da im Enterprise Bereich deutlich bessere Lösungen gibt meine ich. Aber das ist jetzt erst einmal egal).

Mit den Punkten im Hinterkopf wird evtl. deutlich, wieso ich etwas differenziert habe zwischen dem reinen hadoop und den Hilfsscripten, die auf SSH aufsetzen (und die nicht zwingend notwendig sind aus meiner Sicht).

 

[Dimax]

Dein SSH Problem auf Windows Seite

Stimmt,unter Linux kein Problem damit bis Jetzt.
Das Problem :
1.Schritt: Generiere Schlüssel ssh-keygen -t rsa -P "" -ok
2.Schritt: Öffne c:\Users\user\.ssh und per copy-paste id_rsa.pub in autorized_keys speichern. -ok
3.Schritt: known_hosts ist leer. Ausführen -ssh localhost
The authenticity of host 'localhost (::1)' can't be established. ECDSA key fingerprint is blabla. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. Connection reset by ::1 port 22

Hadoop in singlemode läuft ohne Probleme in Windows und in Linux..Getestet mit MapReducde.jar
Auch einfache Textdateien in hdfs hinzufügen geht ohne Fehlern.
Ich mache dass alles nach dem Buch von Jonas Freiknecht "BigData in der Praxis" aber versuche jeden Schritt auf beiden BS
zu machen.Im Buch ist aber alles nur für Linux beschrieben.

 

[kneitzel]

Diese Meldung ist auch normal. Der Server localhost war noch nicht bekannt und das teilt er Dir mit und fragt, ob er den Key speichern soll.

Dieses Verhalten sollte unter Linux genau so gewesen sein. (Ich kenne diese Meldungen nur von Linux und co, unter Windows setze ich kein SSH ein.)

 

[Dimax]

Diese Meldung ist auch normal

Diese Meldung ist nicht normal.Das sagt zwar das localhost zu known_hosts hinzugefügt wird aber die Verbindung wird geschlossen. Normalerweise schreibt er "Have a lot of fun".Ich vermute das häng mit der Benutzerrechten zusammen.Firewall habe ich kontrolliert.

 

[kneitzel]

Natürlich ist das eine Standard Meldung von OpenSSH und unter Linux bekommst Du diese ganz genau so (Z.B. hier von meinem Linux System):

konrad@mba:~$ uname -a
Linux mba 4.15.0-30deepin-generic #31 SMP Fri Nov 30 04:29:02 UTC 2018 x86_64 GNU/Linux
konrad@mba:~$ ssh 192.168.192.241
The authenticity of host '192.168.192.241 (192.168.192.241)' can't be established.
ECDSA key fingerprint is SHA256:wiz2kw077nnbQGFM6+2LtkfEkyFuyUrh8eec7oSrB7U.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.192.241' (ECDSA) to the list of known hosts.

Nach dem yes sollte die Verbindung aber nicht geschlossen werden und bei zukünftigen Verbindungen sollte diese Meldung auch nicht mehr auftreten.

Fehlende Schreibrechte verhindern ansonsten nicht den Verbindungsaufbau. Bist Du sicher, dass Du danach nicht verbunden bist? Zeig doch bitte einmal die genaue Ausgabe von eben:
uname -a
whoami
ssh -l <user> localhost
whoami

um zu sehen, was da genau passiert.

Und zeig bitte einmal deine ssh config - sowohl von Deinem Linux System als auch von Deinem Windows/WSL System.
(Wenn Du diese Meldungen auf Deinem Linux System nicht bekommst, dann hast Du da evtl. StrictHostChecking auf no gesetzt oder so. Da wäre dann die Frage, bei welcher Distribution dies ausgeschaltet wurde .... Und evtl. ist UserKnownHostsFile umgesetzt worden... evtl. mit LogLevel Error, so dass Du so Warnungen nicht mehr siehst?)

Weiterhin wäre einmal interessant, was Du denn genau nutzt. Nutzt Du unter Windows 10 das WSL?

 

[mihe7]

Ich kenne diese Meldungen nur von Linux und co, unter Windows setze ich kein SSH ein.

Irgendwann habe ich mir mal git für Windows installiert. Darin enthalten ist die Git-Bash. Als ich die aufgerufen habe, fing ich fast an zu weinen: endlich war Windows bedienbar geworden, und ssh, scp ist auch dabei *heulsmiley*

 

[Dimax]

uname -a

Der Befehl "uname" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.

whoami

meineGruppe\username

ssh -l <user> localhost

fragt nach dem Pass den ich nicht kenne.

Nutzt Du unter Windows 10 das WSL

Nein
Die ssh_config files sind identisch,hab verglichen auf beiden PCs.
# $OpenBSD: ssh_config,v 1.33 2017/05/07 23:12:57 djm Exp $ # This is the ssh client system-wide configuration file. See # ssh_config(5) for more information. This file provides defaults for # users, and the values can be changed in per-user configuration files # or on the command line. # Configuration data is parsed as follows: # 1. command line options # 2. user-specific file # 3. system-wide file # Any configuration value is only changed the first time it is set. # Thus, host-specific definitions should be at the beginning of the # configuration file, and defaults at the end. # Site-wide defaults for some commonly used options. For a comprehensive # list of available options, their meanings and defaults, please see the # ssh_config(5) man page. # Host * # ForwardAgent no # ForwardX11 no # PasswordAuthentication yes # HostbasedAuthentication no # GSSAPIAuthentication no # GSSAPIDelegateCredentials no # BatchMode no # CheckHostIP yes # AddressFamily any # ConnectTimeout 0 # StrictHostKeyChecking ask # IdentityFile ~/.ssh/id_rsa # IdentityFile ~/.ssh/id_dsa # IdentityFile ~/.ssh/id_ecdsa # IdentityFile ~/.ssh/id_ed25519 # Port 22 # Protocol 2 # Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc # MACs hmac-md5,hmac-sha1,umac-64@openssh.com # EscapeChar ~ # Tunnel no # TunnelDevice any:any # PermitLocalCommand no # VisualHostKey no # ProxyCommand ssh -q -W %h:%p gateway.example.com # RekeyLimit 1G 1h

 

[Dimax]

also wenn ich ssh localhost -vvv eingebe,dann lese ich etwas was nicht in Ornung ist:
debug1: identity file C:\\Users\\userh/id_rsa type 0 debug3: Failed to open file:C:/Users/userh/id_rsa-cert error:2 debug3: Failed to open file:C:/Users/userh/id_rsa-cert.pub error:2 debug1: key_load_public: No such file or directory

 

[kneitzel]

Diese debug Meldungen sagen nur, dass diese Dateien nicht gefunden wurden und das ist nichts schlimmes.
Er kann halt eine ganze Reihe von Dateien lesen und nutzen und er prüft die halt ab. -vvv gibt diesbezüglich halt sehr viel aus....

Mich wundert etwas, dass da in der ssh_config alles auskommentiert ist. Ein paar Config-Werte hätte ich da schon erwartet. Ganz leer kenne ich eigentlich von keiner Distribution muss ich gestehen. (Muss aber nichts wildes sein. Es macht ja keinen Sinn, Default Werte erneut anzugeben.)

Aber evtl. fangen wir einfach mal an mit paar Basis Dingen: Wenn Du die WSL nicht nutzt (und daher auch kein uname -a ausführen konntest, das ist halt ein Linux Befehl): Was nutzt du dann? Was für ein OpenSSH hast Du installiert? Und die ssh_config war welche Datei? War es eine vom User oder die systemweite?

Und bei dem SSH Befehl ist das <user> natürlich mit dem user zu ersetzen, mit dem Du Dich verbinden willst. also z.B. ein ssh -l hadoop localhost. Du wolltest Dich doch per ssh auf localhost anmelden oder so. Ich hatte jetzt den Verdacht, dass Du evtl. lediglich geglaubt hast, dass er sich nach der Warnung nicht verbunden hätte, aber in der Regel verbindet er sich auch wenn irgendwas schief läuft. (Typisches Problem ist z.B. die Display Umleitung mit -X oder -Y. Die scheitert oft an irgendwelchen Konfigurationsproblemen....) Aber die Verbindung baut er gerne auf.
Wenn er die Verbindung nicht aufbaut, dann kann es an einem System-Problem liegen, d.h. der User kann sich generell nicht anmelden. Typische Probleme können hier z.B. die eingetragene Shell sein. So ist es unter Linux notwendig, dass die Shell, die beim User eingetragen ist, auch in /etc/shells aufgeführt sein muss, der User muss das Recht haben, das Executable auszuführen und so weiter ...

Wenn Du mir näheres zu Deiner OpenSSH Installation mitteilst und was Du da als Layer nutzt, dann versuche ich einmal, das bei mir nachzubilden. Dann kann ich Dir ggf. helfen. Was ich z.B. in der Vergangenheit schon benutzt habe, war cygwin um ein Unix-Artigen Layer zu bekommen mit den ganzen GNU Tools.

 

[Dimax]

Was nutzt du dann?

Windows 10 ..will diesen PC zum Master machen.

Was für ein OpenSSH hast Du installiert?

Bei Windows ist OpenSSH -Server vorinstalliert,ich habe nur über Einstellungen->Apps and Features OpenSSh -Client nachinstalliert.

# $OpenBSD: ssh_config,v 1.33 2017/05/07 23:12:57 djm Exp $

gehe davon aus ,dass das die Version ist.

Und die ssh_config war welche Datei?

Das ist die globale ,lag in Programm Daten/.ssh

Ich hatte jetzt den Verdacht, dass Du evtl. lediglich geglaubt hast, dass er sich nach der Warnung nicht verbunden hätte

Connection reset by ::1 port 22

Das ist immer dasselbe.Habe die ganze Woche im Netz danach gegoogelt,mehrere beschweren sich das dieses Programm unter Windows kaputt ist.Die einzige Lösung ,bitten mehrere Leute an, Reinstallation. Habe auch schon gemacht hat nicht geholfen. Ich versuche noch vom Github eine Version downloaden und testen.Ich würde ja gerne auf ssh verzichten aber alle Anleitungen,vom Hadoop Hersteller und auch vom meinem Buch führen über SSH.Ich gehe davon aus dass die Verbindung von Master zu allen Slaves im Cluster ist über SSH programmiert und deswegen führt kein Weg an SSH vorbei.