Under Construction

Virtualizierung mit PowerVM > Fortgeschrittene Administration > Nest Accelerator (NX) > Verwenden des NX Accelerators unter AIX

Verwenden des NX (gzip) Accelerator mit OpenSSH

Neuere Versionen von OpenSSH und OpenSSL unterstützen den NX (gzip) Accelerator. Werden größere Mengen an Daten mit OpenSSH (ssh, scp oder sftp) über das Netzwerk übertragen, kann die Verwendung von Compression (Option „-C“) und die Verwendung des Hardware Beschleunigers einen großen Unterschied ausmachen.

Um den NX (gzip) Accelerator mit  OpenSSH verwenden zu können, werden neben dem Fileset zlibNX.rte mindestens die folgenden Versionen von OpenSSH und OpenSSL benötigt:

    • OpenSSH: 8.1.102.2102 oder neuer
    • OpenSSL: 1.0.2.2100 oder neuer

Die Verwendung des NX (gzip) Accelerator muss dann sowohl auf der Client-Seite, also auch auf der Server-Seite erlaubt sein.

Auf der Server-Seite (sshd), müssen dazu die folgenden Optionen über die Konfigurations-Datei /etc/ssh/sshd_config gesetzt werden:

Compression yes
EnableHwCompression yes

Hinweis: Der Default-Wert für Compression ist „yes“!

Ob diese Optionen gesetzt sind, kann leicht mit Hilfe von „sshd -T“ geprüft werden:

# sshd -T | grep -i compression
compression yes
enablehwcompression no
#

Wird die /etc/ssh/sshd_config geändert, muss der sshd-Dienst gestoppt und neu gestartet werden:

# stopsrc -s sshd
0513-044 The sshd Subsystem was requested to stop.
# startsrc -s sshd
0513-059 The sshd Subsystem has been started. Subsystem PID is 7012608.
#

Auf der Client-Seite gibt es mehrere Möglichkeiten:

    1. Verwenden von „-o EnableHwCompression=yes“ beim Kommando-Aufruf.
    2. Setzen von „EnableHwCompression yes“ in ~/.ssh/config.
    3. Setzen von „EnableHwCompression yes“ in /etc/ssh/ssh_config.

Die Hardware-Beschleunigung sollte auf beiden Seiten, Client und Server, verwendet werden!

Als erstes Kopieren wir eine ca. 1.5 GB große Test-Datei mit Software-Compression:

$ time scp -C -v file1.tar aix12:
Executing: program /usr//bin/ssh host aix12, user (unspecified), command scp -v -t .
OpenSSH_8.1p1, OpenSSL 1.0.2u  20 Dec 2019
debug1: Reading configuration data /home/user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: using libz from /usr/opt/rpm/lib/libz.a(libz.so.1)
…
debug1: Sending command: scp -v -t .
Sending file modes: C0644 1535078400 file1.tar
Sink: C0644 1535078400 file1.tar
file1.tar                                                                             100% 1464MB  17.8MB/s   01:22   
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 1157736604, received 271372 bytes, in 82.6 seconds
Bytes per second: sent 14015292.0, received 3285.2
debug1: Exit status 0
debug1: compress outgoing: raw data 1535920994, compressed 1156169864, factor 0.75
debug1: compress incoming: raw data 121705, compressed 58364, factor 0.48

real    1m23.515s
user    0m25.425s
sys     0m1.063s
$

In Zeile 5 der Ausgabe wird angezeigt das die „normale“ libz verwendet wird (/usr/opt/rpm/lib/libz.a). Die Übertragung der Datei dauert mit Software-Compression ca. 1m24s und es wird ein Durchsatz von ca. 18 MB/s erzielt.

Als nächstes wiederholen wir den Test-Transfer, aktivieren aber auf beiden Seiten die Hardware-Beschleunigung durch den NX (gzip) Accelerator:

$ time scp -C -v file1.tar aix12:
Executing: program /usr//bin/ssh host aix12, user (unspecified), command scp -v -t .
OpenSSH_8.1p1, OpenSSL 1.0.2u  20 Dec 2019
debug1: Reading configuration data /home/user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: oslevel : 7.2.0.0

debug1: using libzNX from /opt/freeware/ssh/libzNX_c.a(libz.so.1)
…
debug1: Sending command: scp -v -t .
Sending file modes: C0644 1535078400 file1.tar
Sink: C0644 1535078400 file1.tar
file1.tar                                                                             100% 1464MB  80.0MB/s   00:18   
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 1205350716, received 280788 bytes, in 18.4 seconds
Bytes per second: sent 65570992.2, received 15274.8
debug1: Exit status 0
debug1: compress outgoing: raw data 1535921498, compressed 1203806319, factor 0.78
debug1: compress incoming: raw data 123307, compressed 60913, factor 0.49

real    0m18.754s
user    0m4.370s
sys     0m1.944s
$

Der Transfer der Test-Datei hat sich von 1m24s auf 19s reduziert! Der Durchsatz ist dabei von 18 MB/s auf 80 MB/s gestiegen.

Aber Vorsicht, bevor man Komprimierung bei der Datenübertragung verwendet, sollte man vorher überprüfen ob dies die Übertragung auch tatsächlich beschleunigt! Schließlich kostet die Komprimierung der Daten auf dem Quell-System und die Entkomprimierung auf dem Ziel-System ebenfalls Zeit. Bei einem schnellen Netzwerk lohnt sich unter Umständen dieser Aufwand nicht und die Übertragung ohne Komprimierung ist schneller. Wir haben auf den beiden Test-Systemen, welche auf der gleichen Hardware laufen, und der Datentransfer bei Virtual Ethernet damit über den Hypervisor läuft einen Test ohne Komprimierung gemacht. Mit folgendem Resultat:

$ time scp -v file1.tar aix12:
Executing: program /usr//bin/ssh host aix12, user (unspecified), command scp -v -t .
OpenSSH_8.1p1, OpenSSL 1.0.2u  20 Dec 2019
debug1: Reading configuration data /home/user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
…
debug1: Sending command: scp -v -t .
Sending file modes: C0644 1535078400 file1.tar
Sink: C0644 1535078400 file1.tar
file1.tar                                                                             100% 1464MB 144.6MB/s   00:10   
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 1536194108, received 254512 bytes, in 10.3 seconds
Bytes per second: sent 148609323.7, received 24621.1
debug1: Exit status 0

real    0m10.668s
user    0m2.908s
sys     0m0.604s
$

Der Transfer dauert jetzt nur noch 11s und ist damit fast doppelt so schnell wie mit der Hardware-Komprimierung! Der Durchsatz ist auf ca. 145 MB/s gestiegen. In diesem Falle ist also die Verwendung einer Komprimierung, selbst wenn ein Hardware-Beschleuniger verwendet wird, nicht sinnvoll!