Ubuntu Server Cluster mit Parallels (Teil 2/2)

Diese Anleitung setzt die Ausführung der beschriebenen Schritte in der Anleitung Teil 1/2 voraus.

Bevor wir mit den Konfigurationen beginnen, sollten wir nochmal kurz zusammenfassen, was eigentlich die Ziele sind:

• SSH-Verbindung von MacBook Terminal via SSH-Key auf die verschiedenen Nodes
  • Gleicher SSH-Key für die Verbindung vom MacBook auf alle Nodes (big_data_host_key)
  • Verhindern von SSH-Verbindungen mit Username & Passwort (weil unsicher)
• SSH-Verbindungen zwischen den einzelnen Nodes innerhalb des “bigdata” Netzwerkes
  • Ein SSH-Key pro Node (big_data_node_key_bdX)
  • Pro Node eine statische IP Adresse im “bigdata” Netzwerk
  • Pro Node eine dynamschie IP Adresse (DHCP) im “Shared” Netzwerk

Die folgende Grafik zeigt die Zielarchitektur des Big Data Clusters.

SSH Verbindung vom MacBook zu den VMs (mit SSH-Key)

Nach dem ersten Teil der Anleitung waren wir fähig, mit Nutzername (“ubuntu”) und Passwort per ssh auf die einzelnen Nodes zu verbinden. Dies wollen wir nun sicherer gestalten und die Verbindung nur noch über SSH-Key-Paare erlauben.

SSH-Key erstellen

Als Zusatzsicherheit werden wir für den erstellten Key auch noch eine Passphrase miteinbauen. So reicht es nicht für einen Login-Versuch, wenn man nur den Private Key besitzt, man braucht zusätzlich auch noch die Passphrase des Keys.

# Ordner erstellten, wo wir den Key speichern wollen
mkdir ~/.ssh/id_rsa/
# Ordner-Berechtigungen anpassen
chmod 700 ~/.ssh/id_rsa
# Erstellung eines 4096-bit RSA Keys
ssh-keygen -t rsa -b 4096
# als Speicherort und Namen des Files wählen wir ~/.ssh/id_rsa/big_data_host_key

Hinzufügen des Public Keys (authorized_keys) in den Nodes

Damit wir uns später mit dem erstellten SSH-Key auf die Nodes verbinden können, muss auf jedem Node der öffentliche Schlüssel im File ~/.ssh/authorized_keys hinzugefügt werden. Falls das .ssh Verzeichnis auf dem Node noch nicht existiert, kann man es mit den folgenden Befehlen erstellen:

# Verzeichnis erstellen
mkdir ~/.ssh/
# Ordnerberechtigungen setzen
chmod 700 ~/.ssh

Es muss sichergestellt werden, dass dieses Verzeichnis auf allen Nodes existiert.

Nun muss der Inhalt des öffentlichen Schlüssels big_data_host_key.pub in ein File authorized_keys im eben erstellten Verzeichnis kopiert werden. Es gibt mehrere Möglichkeiten wie man das tun kann. Im Folgenden werden wir es über unsere im Teil 1/2 erstellte SSH-Verbindung machen:

# Inhalt des öffentlichen Schlüssels kontrollieren
cat ~/.ssh/id_rsa/big_data_host_key.pub
# Inhalt des öffentlichen Schlüssels kopieren auf bd-1
cat ~/.ssh/id_rsa/big_data_host_key.pub | ssh -p 14201 ubuntu@127.0.0.1 'cat >> ~/.ssh/authorized_keys'
# Inhalt des öffentlichen Schlüssels kopieren auf bd-2
cat ~/.ssh/id_rsa/big_data_host_key.pub | ssh -p 14202 ubuntu@127.0.0.1 'sudo cat >> ~/.ssh/authorized_keys'
# Inhalt des öffentlichen Schlüssels kopieren auf bd-3
cat ~/.ssh/id_rsa/big_data_host_key.pub | ssh -p 14203 ubuntu@127.0.0.1 'cat >> ~/.ssh/authorized_keys'
# Inhalt des öffentlichen Schlüssels kopieren auf bd-4
cat ~/.ssh/id_rsa/big_data_host_key.pub | ssh -p 14204 ubuntu@127.0.0.1 'cat >> ~/.ssh/authorized_keys'
# Inhalt des öffentlichen Schlüssels kopieren auf bd-5
cat ~/.ssh/id_rsa/big_data_host_key.pub | ssh -p 14205 ubuntu@127.0.0.1 'cat >> ~/.ssh/authorized_keys'

PubkeyAuthentication Enablen

Damit die Verbindung mit einem Key überhaupt erlaubt wird, muss die sshd Konfiguration angepasst werden. Zuerst kann man es ja mal auf einem der 5 Nodes (z.B. bd-1) versuchen.

# sshd config öffnen und PubkeyAuthentication yes auskommentieren - also das "#" entfernen
sudo nano /etc/ssh/sshd_config
# File speichern und sshd Service neustarten
sudo systemctl restart sshd

In der Folge kann man die verschiedenen Verbindungsarten auf dem persönlichen MacBook testen.

# PasswordAuthentication - wird noch funktionieren
ssh -v -p 14201 ubuntu@127.0.0.1
# PubkeyAuthentication - wird jetzt neu funktionieren
ssh -i ~/.ssh/id_rsa/big_data_host_key -p 14201 ubuntu@127.0.0.1

PasswordAuthentication Disablen

Nun da wir wissen, dass die Verbindung mit dem SSH-Key funktioniert, können wir die PasswordAuthentication disablen.

# sshd config öffnen und "PasswordAuthentication yes" ändern zu "PasswordAuthentication no"
sudo nano /etc/ssh/sshd_config
# File speichern und sshd Service neustarten
sudo systemctl restart sshd

Wenn wir nun wieder dieselben Verbindungsversuche machen wie oben, dann stellen wir fest, dass man sich nun nur noch mit dem SSH-Key verbinden kann.

# PasswordAuthentication - wird nicht mehr funktionieren
ssh -v -p 14201 ubuntu@127.0.0.1
# PubkeyAuthentication - wird noch funktionieren
ssh -i ~/.ssh/id_rsa/big_data_host_key -p 14201 ubuntu@127.0.0.1

Die gleiche Konfiguration soll nun auf den anderen 4 Nodes wiederholt und getestet werden.

IP / Host Konfiguration

Hostname und Hosts

Damit die 5 Nodes untereinander im “bigdata” Netzwerk kommunizieren können, braucht es statische IP Adressen und sie müssen sich gegenseitig “vorgestellt” werden. Zuerst prüfen wir auf jedem Node, ob der hostname auch wirklich stimmt (z.B. bei bd-1 müsste “bd-1” drinstehen).

sudo nano /etc/hostname

Danach stellen wir die verschiedenen Nodes einander vor:

sudo nano /etc/hosts

Der Inhalt des Files muss auf jedem Node wie folgt ergänzt/angepasst werden:

IP Konfiguration

Die folgenden Schritte müssen wieder auf jedem der 5 Nodes durchgeführt werden.

Zuerst schalten wir das automatische Neugenerieren der Konfiguration aus mit:

sudo touch /etc/cloud/cloud-init.disabled

Nun müssen wir mal schauen, wie unser Netzwerkadapter des “bigdata” Netzwerkes heisst, damit wir diesen Adapter so konfigurieren können, dass er feste IP Adressen vergibt (dhcp4: false).

ip a

Der Netzwerkadapter vom “bigdata” Netzwerk heisst also enp0s6.

Im Verzeichnis /etc/netplan finden wir ein File namens “00-installer-config.yaml” und editieren dieses:

sudo nano /etc/netplan/00-installer-config.yaml

Der Inhalt sieht dann wie folgt aus (IP natürlich pro Node anpassen – 201 für bd-1, 202 für bd-2, etc.):

Wichtig ist hier, dass für enp0s6 (Adapter des bigdata Netzwerkes) dhcp4 auf false gesetzt wird, und die feste IP Adresse definiert wird. Die IP Adressen des Shared Netzwerkes können weiterhin dynamisch verteilt werden (dhcp4 true).

Vernetzung im internen “bigdata” Netzwerk

Nun folgt der letzte Schritt. Wir erstellen pro Node einen SSH Key ohne Passphrase, mit dem wir uns über SSH mit jedem der anderen vier Nodes im “bigdata” Netzwerk verbinden können.

Alle Schritte müssen auf allen Nodes durchgeführt werden.

Key Erstellung

# Berechtigungen des authorized_keys Files anpassen
chmod 0600 ~/.ssh/authorized_keys
# Ordner für den Key erstellen
mkdir ~/.ssh/id_rsa/
# rwx Rechte für den Owner des Ordners (ubuntu User) erteilen
chmod 700 ~/.ssh/id_rsa
# Key generieren (ACHTUNG: *_bd1 anpassen auf *_bd2, *_bd3, etc.)
ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa/big_data_node_key_bd1

Ergänzung authorized_keys

Damit man die Keys später verwenden kann, müssen die Inhalte der öffentlichen Schlüssel der 4 anderen Nodes jeweils auf dem fünften Node in das ~/.ssh/authorized_keys hinzugefügt werden.

Im Folgenden ein Beispiel für das Hinzufügen der Inhalte der öffentlichen Schlüssel von bd-2, bd-3, bd-4 und bd-5 auf bd-1.

# Inhalte lesen (zum Kopieren)
# auf bd-2
cat ~/.ssh/id_rsa/big_data_node_key_bd2.pub
# auf bd-3
cat ~/.ssh/id_rsa/big_data_node_key_bd3.pub
# auf bd-4
cat ~/.ssh/id_rsa/big_data_node_key_bd4.pub
# auf bd-5
cat ~/.ssh/id_rsa/big_data_node_key_bd5.pub

# Die vier Inhalte jeweils mit neuen Zeilen hinzufügen zu ~/.ssh/authorized_keys
sudo nano ~/.ssh/authorized_keys

SSH Konfiguration

Auf jedem Node die folgenden Schritte ausführen:

# Erstellung des ssh config Files
touch ~/.ssh/config
# Editieren
sudo nano ~/.ssh/config

Folgende Informationen müssen hinzugefügt werden (ACHTUNG: *_bd1 anpassen auf *_bd2, *_bd3, etc.):

Host *
    User ubuntu
    IdentityFile ~/.ssh/id_rsa/big_data_node_key_bd1

…und dann ein letztes Mal den sshd Service neustarten:

sudo systemctl restart sshd

Testing

Nun sollte alles soweit eingerichtet sein, dass wir die Verbindungen im “bigdata” Netzwerk testen können. Angenommen man befindet sich auf dem Node bd-1 und möchte sich auf bd-2 verbinden, so kann man dies jetzt ganz einfach mit dem folgenden Befehl machen:

ssh bd-2

Die Verbindung lässt sich auch ganz einfach wieder beenden:

exit

Bei Verbindungsproblemen oder allgemein für mehr Hintergrundinformationen zum Verbindungsaufbau, kann man noch die Funktion “-v” (verbose) verwenden:

ssh -v bd-2

Schlusswort

Nun ist alles final eingerichtet und getestet. Der Big Data Cluster kann nun die Basis sein für viele interessante Proof-of-Concepts mit den verschiedenen Big Data Tools (Apache Spark, Apache Kafka, Hadoop HDFS, etc.).

Für diejenigen die nicht gerne 1000-Mal klicken bis sie zur Tat schreiten können, habe ich noch eine Anleitung erstellt, für die Automatisierung von Parallels Funktionen mit Hilfe von Bash Skripten.