Verteilte Generierung von Zufallszahlen: Unterschied zwischen den Versionen

Aus Linupedia.org
Wechseln zu: Navigation, Suche
(Initial - verschoben von Seite dd - siehe Diskussion dort)
 
K (Ergebnisse mit den erwarteten Mengen vergleichen)
 
(9 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
{{UnderConstruction}}--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 07:39, 6. Jan. 2015 (CET)
+
{{Review|Gesamter Artikel}}--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 11:39, 6. Jan. 2015 (CET)
 +
{{Box Achtung||
 +
Die Nutzung von 'dd' wird nur unter Rootkennung funktionieren und die Befehle müssen auf die Gegebenheiten des eigenen Rechners abgestimmt werden. Nur kleine Schreib- oder Denkfehler können schon zu ernsten Datenverlusten führen, deshalb '''vor dem Betätigen der Enter-Taste den Befehl genau anschauen'''.
 +
}}
 +
Für die Generierung von Zufallszahlen bietet Linux die beiden Pseudo-Devices '[[random]]' und '[[urandom]]' an. Sie unterscheiden sich in der Qualität des Ergebnisses und der Performance. So bietet 'random' eine bessere Zufälligkeit, ist aber sehr viel langsamer und blockiert bei mangelnder Entropie auch mal komplett für längere Zeit. Bei Dimensionen aktueller Datenträger im Terabyte-Bereich ist das viel zu langsam, so dass häufig 'urandom' zum Einsatz kommt.
  
Für die Generierung von Zufallszahlen bietet Linux die beiden Pseudo-Devices '[[random]]' und '[[urandom]]' an. Sie unterscheiden sich in der Qualität des Ergebnisses und der Performance. So bietet 'random' eine bessere Zufälligkeit, ist aber sehr viel langsamer und blockiert bei mangelnder Entropie auch mal komplett für längere Zeit. Bei Dimensionen aktueller Datenträger im Terabyte-Bereich ist das viel zu langsam, so dass häufig 'urandom' zum Einsatz kommt.
+
Aber selbst damit kann mit handelsüblichen Prozessoren das Beschreiben einer solchen Festplatte mehrere Tage dauern. Abhilfe kann es sein, diese Aufgabe auf mehrere Rechner zu verteilen und die Ergebnisse über das Netz auf die Festplatte zu schreiben, wodurch die '''Gesamtdauer des Prozesses verkürzt''' wird.
  
Aber selbst damit kann mit handelsüblichen Prozessoren das Beschreiben einer solchen Festplatte mehrere Tage dauern. Abhilfe kann es sein, diese Aufgabe auf mehrere Rechner zu verteilen und die Ergebnisse über das Netz auf die Festplatte zu schreiben, wodurch die '''Gesamtdauer des Prozesses verkürzt''' wird. Hierzu kann neben 'dd' das Tool [[ssh]] verwendet werden, dessen Aufgabe es ist, die Daten über das Netzwerk zu transportieren und an den dd-Prozess auf dem Zielsystem zu übergeben. Dieses Verfahren ist skalierbar, so dass mehrere Computer an der Berechnung der Zufallszahlen beteiligt werden können.
+
Hierzu können die Standard-Werkzeuge [[dd]] und [[ssh]] mittels Pipe kombiniert werden, um die auf unterschiedlichen Systemen erzeugten Zufallsdaten über das Netzwerk zu transportieren und an das Zielsystem zu übergeben, wo sie dann in bestimmte Bereiche der Festplatte geschrieben werden. Dieses Verfahren ist skalierbar, so dass mehrere Computer an der Berechnung der Zufallszahlen beteiligt werden können.
  
Beispiel:
+
=Beispiel=
  
 
In diesem Beispiel ist '/dev/sdf' die Festplatte auf dem Zielsystem 'j4', welche beschrieben werden soll. Feststellen der Festplatten-Kapazität:
 
In diesem Beispiel ist '/dev/sdf' die Festplatte auf dem Zielsystem 'j4', welche beschrieben werden soll. Feststellen der Festplatten-Kapazität:
Zeile 12: Zeile 16:
 
Platte /dev/sdf: 4000.8 GByte, 4000787030016 Byte
 
Platte /dev/sdf: 4000.8 GByte, 4000787030016 Byte
 
</pre>
 
</pre>
Bei einer gewählten Blockgröße von 8 Kilobytes bzw. 8x1024 Bytes (bs=8K) teilt sich die Gesamtkapazität in 488377323 Blöcke auf. Diese müssen auf die Anzahl der teilnehmenden Rechner verteilt werden. Je nach Leistungsstärke der beteiligten Systeme muss hierbei nicht unbedingt eine Gleichverteilung angestrebt werden. Im vorliegenden Fall sollen neben dem Server 'j4' noch 2 weitere Rechner ('j2', 'j3') für diese Aufgabe verwendet werden. In vorigen Versuchen wurde die Leistungsfähigkeit der einzelnen Systeme bestimmt und die Anteile berechnet:
+
Bei einer gewählten Blockgröße von 8 Kilobytes bzw. 8x1024 Bytes (bs=8K) teilt sich die Gesamtkapazität in 488377323 Blöcke auf. Diese müssen auf die Anzahl der teilnehmenden Rechner verteilt werden. Je nach Leistungsstärke der beteiligten Systeme muss hierbei nicht unbedingt eine Gleichverteilung angestrebt werden. Im vorliegenden Fall sollen neben dem Server 'j4' noch 2 weitere Rechner ('j2', 'j3') für diese Aufgabe verwendet werden. In zuvor durchgeführten Versuchen wurde die Leistungsfähigkeit der einzelnen Systeme bestimmt und daraus die Anteile berechnet:
 
{| border="1"
 
{| border="1"
 
! System
 
! System
Zeile 45: Zeile 49:
 
gehrke@j3:~> BS=8K; dd if=/dev/urandom bs=$BS | ssh root@j4 "dd of=/dev/sdf bs=$BS seek=217710373 count=119642637"
 
gehrke@j3:~> BS=8K; dd if=/dev/urandom bs=$BS | ssh root@j4 "dd of=/dev/sdf bs=$BS seek=217710373 count=119642637"
 
</pre>
 
</pre>
Hinweise:
+
 
*Parametrisierung: [[#Positionierung innerhalb des Datenstrom|Positionierung innerhalb des Datenstroms]]
+
Nachdem alle Prozesse abgeschlossen sind, sollte man noch die Ergebnisse mit den erwarteten Mengen vergleichen.
*[[#die Ausgaben von dd|Fortschrittsanzeige via Signal 10 (SIGUSR1)]]
+
 
 +
j2:
 +
<pre>
 +
217710357+16 Datensätze ein
 +
217710357+16 Datensätze aus
 +
1783483333204 Bytes (1,8 TB) kopiert, 251659 s, 7,1 MB/s
 +
</pre>
 +
j3:
 +
<pre>
 +
119642517+120 Datensätze ein
 +
119642517+120 Datensätze aus
 +
980112166544 Bytes (980 GB) kopiert, 180993 s, 5,4 MB/s
 +
</pre>
 +
j4:
 +
<pre>
 +
151024167+146 Datensätze ein
 +
151024167+146 Datensätze aus
 +
1237190661134 Bytes (1,2 TB) kopiert, 300172 s, 4,1 MB/s
 +
</pre>
  
  
Zeile 53: Zeile 75:
 
Für die hier vorgestellte Methode ist es notwendig, dass der ssh-Zugang für den root-User gegeben ist. Dies kann je nach Anwendungsfall ein Sicherheitsrisiko darstellen. Es sollten entsprechende Maßnahmen ergriffen werden, die daraus resultierenden Gefahren abzuwehren (beispielsweise per Firewall-Regel, [[Einrichten von public keys mit ssh|PublicKey-Authentifizierung]], IP-basierter Konfiguration oder temporärer Zulassung).
 
Für die hier vorgestellte Methode ist es notwendig, dass der ssh-Zugang für den root-User gegeben ist. Dies kann je nach Anwendungsfall ein Sicherheitsrisiko darstellen. Es sollten entsprechende Maßnahmen ergriffen werden, die daraus resultierenden Gefahren abzuwehren (beispielsweise per Firewall-Regel, [[Einrichten von public keys mit ssh|PublicKey-Authentifizierung]], IP-basierter Konfiguration oder temporärer Zulassung).
 
}}
 
}}
 +
 +
=Weiterführende Links=
 +
*Parametrisierung: [[dd#Positionierung innerhalb des Datenstrom|Positionierung innerhalb des Datenstroms]]
 +
*[[dd#die Ausgaben von dd|Fortschrittsanzeige via Signal 10 (SIGUSR1)]]
 +
*[https://linux-talk.de/viewtopic.php?f=96&t=188 Thread zum Thema (linux-talk.de)]
 +
 +
[[Kategorie:Partitionen]] [[Kategorie:Security]] [[Kategorie:Konsole]] [[Kategorie:HowTo]]

Aktuelle Version vom 7. Januar 2015, 20:04 Uhr

Höhe=24px Dieser Artikel oder Teile davon wurden mit 'Review' markiert. Das bedeutet, dass größere Arbeiten am Inhalt des Artikels abgeschlossen sind und der Autor eine Korrekturlesung durch andere User zur Qualitätssicherung für angebracht hält.

Zu sichtende Teile: Gesamter Artikel

Bitte hilf LinuxClubWiki, indem du den zu sichtenden Teil überprüfst und den Artikel gegebenenfalls überarbeitest!

--Gehrke (Diskussion) 11:39, 6. Jan. 2015 (CET)

Achtung:

Die Nutzung von 'dd' wird nur unter Rootkennung funktionieren und die Befehle müssen auf die Gegebenheiten des eigenen Rechners abgestimmt werden. Nur kleine Schreib- oder Denkfehler können schon zu ernsten Datenverlusten führen, deshalb vor dem Betätigen der Enter-Taste den Befehl genau anschauen.


Für die Generierung von Zufallszahlen bietet Linux die beiden Pseudo-Devices 'random' und 'urandom' an. Sie unterscheiden sich in der Qualität des Ergebnisses und der Performance. So bietet 'random' eine bessere Zufälligkeit, ist aber sehr viel langsamer und blockiert bei mangelnder Entropie auch mal komplett für längere Zeit. Bei Dimensionen aktueller Datenträger im Terabyte-Bereich ist das viel zu langsam, so dass häufig 'urandom' zum Einsatz kommt.

Aber selbst damit kann mit handelsüblichen Prozessoren das Beschreiben einer solchen Festplatte mehrere Tage dauern. Abhilfe kann es sein, diese Aufgabe auf mehrere Rechner zu verteilen und die Ergebnisse über das Netz auf die Festplatte zu schreiben, wodurch die Gesamtdauer des Prozesses verkürzt wird.

Hierzu können die Standard-Werkzeuge dd und ssh mittels Pipe kombiniert werden, um die auf unterschiedlichen Systemen erzeugten Zufallsdaten über das Netzwerk zu transportieren und an das Zielsystem zu übergeben, wo sie dann in bestimmte Bereiche der Festplatte geschrieben werden. Dieses Verfahren ist skalierbar, so dass mehrere Computer an der Berechnung der Zufallszahlen beteiligt werden können.

Beispiel

In diesem Beispiel ist '/dev/sdf' die Festplatte auf dem Zielsystem 'j4', welche beschrieben werden soll. Feststellen der Festplatten-Kapazität:

[root@j4 ~]# fdisk -l /dev/sdf | grep 'Platte /dev/sdf:'
Platte /dev/sdf: 4000.8 GByte, 4000787030016 Byte

Bei einer gewählten Blockgröße von 8 Kilobytes bzw. 8x1024 Bytes (bs=8K) teilt sich die Gesamtkapazität in 488377323 Blöcke auf. Diese müssen auf die Anzahl der teilnehmenden Rechner verteilt werden. Je nach Leistungsstärke der beteiligten Systeme muss hierbei nicht unbedingt eine Gleichverteilung angestrebt werden. Im vorliegenden Fall sollen neben dem Server 'j4' noch 2 weitere Rechner ('j2', 'j3') für diese Aufgabe verwendet werden. In zuvor durchgeführten Versuchen wurde die Leistungsfähigkeit der einzelnen Systeme bestimmt und daraus die Anteile berechnet:

System Durchsatz urandom [MB/sec] Anteil [%] Anzahl Blöcke Start-Block End-Block
j2 11,1 44,6 217710373 0 217710373
j3 6,1 24,5 119642637 217710373 337353010
j4 7,7 31,0 151024313 337353010 488377323
Gesamt 24,9 100 488377323

Zuerst wird auf 'j4' der Prozess ohne Netzwerk gestartet:

[root@j4 ~]# dd bs=8K seek=337353010 count=151024313 if=/dev/urandom of=/dev/sdf

Auf den anderen beiden Systemen wird der Prozess über ssh getunnelt:

gehrke@j2:~> BS=8K; dd if=/dev/urandom bs=$BS | ssh root@j4 "dd of=/dev/sdf bs=$BS seek=0 count=217710373"
gehrke@j3:~> BS=8K; dd if=/dev/urandom bs=$BS | ssh root@j4 "dd of=/dev/sdf bs=$BS seek=217710373 count=119642637"

Nachdem alle Prozesse abgeschlossen sind, sollte man noch die Ergebnisse mit den erwarteten Mengen vergleichen.

j2:

217710357+16 Datensätze ein
217710357+16 Datensätze aus
1783483333204 Bytes (1,8 TB) kopiert, 251659 s, 7,1 MB/s

j3:

119642517+120 Datensätze ein
119642517+120 Datensätze aus
980112166544 Bytes (980 GB) kopiert, 180993 s, 5,4 MB/s

j4:

151024167+146 Datensätze ein
151024167+146 Datensätze aus
1237190661134 Bytes (1,2 TB) kopiert, 300172 s, 4,1 MB/s


Achtung:

Für die hier vorgestellte Methode ist es notwendig, dass der ssh-Zugang für den root-User gegeben ist. Dies kann je nach Anwendungsfall ein Sicherheitsrisiko darstellen. Es sollten entsprechende Maßnahmen ergriffen werden, die daraus resultierenden Gefahren abzuwehren (beispielsweise per Firewall-Regel, PublicKey-Authentifizierung, IP-basierter Konfiguration oder temporärer Zulassung).


Weiterführende Links