Tsung Distributed Client Load Testing - Einfache HTTP-Anfragen

Question

Ich versuche, ein verteiltes Client-Netzwerk mit Tsung zu erstellen. Ich habe einen Cluster mit 14 verschiedenen Rechnern. Ich möchte m01 als Server und die Maschinen m02 und m03 als Clients (oder simulierte Benutzer) verwenden.

Hier ist, was ich geschrieben habe:

<!-- Client side setup -->
<clients>
    <client host="localhost" maxusers="400" cpu="1"><ip value="192.168.1.2"/></client>
    <client host="m03" maxusers="400" cpu="1"><ip value="192.168.1.3"/></client>
</clients>

Der Server, auf den ich ziele, ist hier definiert:

<!-- Server side setup -->
<servers>
    <server host="192.168.1.1" port="5000" type="tcp"></server>
</servers>

Immer wenn ich versuche, dies auszuführen, erhalte ich die folgende Fehlermeldung:

Host key verification failed.

Für Notizen ist m02 ein lokaler Host, auf dem ich tsung ausführe.

Ich habe tsung und erlan auf allen Rechnern installiert und verschiedene Tests durchgeführt, um sicherzustellen, dass ich nicht verteilte Tests durchführen kann.

Ich bin mir nicht sicher, wie es jetzt weitergehen soll.

Answer 1

Die verteilten Lasttests von Tsung basieren auf der SSH-Shell-Verteilung. Stellen Sie sicher, dass Sie Ihr SSH-System so einrichten, dass Sie ssh ohne Passwortabfrage (mit Schlüssel) vom Master zu allen Slave-Knoten durchführen können.

En Tsung-Dokumentation :

für verteilte Tests benötigen Sie einen ssh-Zugang zu entfernten Rechnern ohne Passwort (verwenden Sie einen RSA/DSA-Schlüssel ohne Passphrase oder ssh-Agent) (rsh wird ebenfalls unterstützt)

Answer 2

Tsung Cluster-Konfiguration.

Für die Konfiguration eines Tsung-Clusters benötigen Sie Nodes (verschiedene Computer mit demselben Betriebssystem und derselben Tsung-Version).

Alle Knoten sollten die Möglichkeit haben, auf den Master-Knoten zuzugreifen, ohne ein Passwort einzugeben. Für diesen Vorgang müssen Sie SSL-Zertifikate im Master-Knoten generieren und dann den öffentlichen Schlüssel in allen Slave-Knoten hinzufügen. Folgen Sie den nachstehenden Befehlen:

Erzeugen Sie das Zertifikat im Masterknoten:

ssh-keygen -t rsa Kopieren Sie die Dateien in die Home-Verzeichnisse aller Knoten (in unserem Beispiel gibt es 3 Knoten):

scp ./id_rsa.pub USERNAME@NODE_1_IP_ADDRESS:~
scp ./id_rsa.pub USERNAME@NODE_2_IP_ADDRESS:~  
scp ./id_rsa.pub USERNAME@NODE_3_IP_ADDRESS:~

Fügen Sie den öffentlichen Schlüssel in allen Knoten hinzu:

cat id_rsa.pub >> .ssh/authorized_keys

Nach erfolgreicher Keygenerierung und Installation auf allen Knoten sollten Sie per ssh-Befehl den Zugang zu allen Knoten überprüfen. Die erstmalige Anmeldung über ssh ist erforderlich, oder Sie erhalten die Meldung Host key verification failed. Beispiel: Bitte tun Sie dies: ssh [derselbeBenutzername,derimUnterrichtsplan steht]@IhrHostname

HINWEIS: Die /etc/hosts aller Knoten sollte die Anmeldeinformationen des Clusters und des Test-Servers enthalten.

Answer 3

Haben Sie schon einmal von Ihrem Rechner aus per SSH auf den Rechner zugegriffen, den Sie benutzen wollen?

ubuntu@ip-10-168-221-101:~/sessions$ tsung -f project.xml -l logs/tsung.log start
Starting Tsung
"Log directory is: /home/ubuntu/sessions/logs/20120830-1008"
Host key verification failed.
Host key verification failed.
Host key verification failed.
Host key verification failed.
^C
BREAK: (a)bort (c)ontinue (p)roc info (i)nfo (l)oaded
       (v)ersion (k)ill (D)b-tables (d)istribution
^Cubuntu@ip-10-168-221-101:~/sessions$ grep client project.xml 
  <clients>
    <client host="localhost"/>
    <client host="ip-10-161-74-53"/>
    <client host="ip-10-168-154-136"/>
    <client host="ip-10-168-15-66"/>
    <client host="ip-10-168-86-249"/>
  </clients>
  the mean inter-arrival time between new clients and the phase

ubuntu@ip-10-168-221-101:~/sessions$ ssh ip-10-161-74-53 erl
The authenticity of host 'ip-10-161-74-53 (10.161.74.53)' can't be established.
ECDSA key fingerprint is d0:92:3c:f1:56:99:c8:34:8b:0f:99:e8:10:7e:69:a6.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'ip-10-161-74-53,10.161.74.53' (ECDSA) to the list of known hosts.
Eshell V5.8.5  (abort with ^G)
1> ^C

ubuntu@ip-10-168-221-101:~/sessions$ for d in $(grep client project.xml | grep ip | sed 's/<client host="\([^"]\+\)"\/>/\1/'); do ssh $d cat /etc/hosts; done
127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
[...]

ubuntu@ip-10-168-221-101:~/sessions$ tsung -f project.xml -l logs/tsung.log start
Starting Tsung
"Log directory is: /home/ubuntu/sessions/logs/20120830-1013"

Profit!"

Answer 4

1 Verwenden Sie dies auf dem Server (Master), um zu prüfen, ob die SSH-Anmeldung ohne Passwort in Ordnung ist:

ssh client-002 erl 

2 Wenn das nicht in Ordnung ist, tun Sie dies, damit Ihre öffentliche Schlüsseldatei immer die neueste ist:

ssh-copy-id your-hostname

PS: Wenn Sie Ihr SSH-Login ohne Passwort OK einrichten, dann verwenden Sie NICHT ssh-keygen, um einen neuen öffentlichen Schlüssel zu erzeugen.

Answer 5

Schritte 1. die VMs/Maschinen neu starten und eine neue Sitzung beginnen

Entfernen Sie die Zeilen von /home/user/.ssh/known_hosts, die sich auf die Rechner m01, m02 und m03 beziehen, von jedem der Rechner.

3. Ändern Sie die /etc/hosts-Dateien aller Dateien so, dass sie die IP-Adresse und den Hostnamen/fqdn/shortname von m01, m02 und m03 enthalten.

Kopieren Sie den Inhalt der Datei publickey in den Ordner /home/user/.ssh/authorized_keys und kopieren Sie die Datei private key in den Ordner /home/user/.ssh/. Erzeugen Sie neue private und öffentliche Schlüssel mit keygen, falls noch nicht erzeugt.

5.(wichtiger Schritt)Führen Sie nun den Befehl:" ssh m03 " von m01 und m02 aus.Es ist wichtig, denselben Namen (oder Hostnamen) in ...(in Ihrer .xml-Datei), in der Datei /etc/hosts und beim Ausführen von ssh zu verwenden (der Hostname, den Sie für ssh verwenden, wird in der Datei known_hosts hinzugefügt). Machen Sie das Gleiche mit den anderen beiden Rechnern.

Referenz: http://cryolite.iteye.com/blog/378758 (bitte übersetzen)

Die Fehlermeldung "Host Key Verification failed" wird nie wieder erscheinen :)