Von Urs Pfister2 am Do, 1. Dezember 2016 um 16:42 #
Scp bringt für die bei der Virtualisierung typischen Sparse-Dateien nichts, weil SCP (auch wenn es mit dem Flag -C aufgerufen wird), am Ende die Datei zur maximalen Grösse aufbläst.
Von Urs Pfister2 am Do, 1. Dezember 2016 um 16:44 #
Scp bringt für die bei der Virtualisierung typischen Sparse-Dateien nichts, weil SCP (auch wenn es mit dem Flag -C aufgerufen wird), am Ende die Datei zur maximalen Grösse aufbläst.
Mich würde mal der Vergleich mit NetCat und das mit und ohne Kombination mit PipeViewer interessieren. Das nutze ich nämlich ab und an ganz gerne mal.
In der Vergangenheit hat sich die Kombination auch für viele kleine Dateien als sehr performant erwiesen. Als Beispiel:
PC1: tar c . | pv -s [größe] | nc -l -p 2002 PC2: nc [PC1] 2002 | tar x
Bisher konnte ich damit bessere Ergebnisse erzielen als mit SCP, NFS +co.
Da ich aber bisher nicht über Gigabit Ethernet hinaus gekommen bin und es sich zumeist auch um Rotationsplatten handelte... ich mein, es könnte ja bei 10G und SSD anders aussehen...
Insbesondere weiß ich nicht, in wie weit die involvierten Programme effiziente Pipes unterstützen. Wenn alle Daten zwischen den Prozessen im Speicher hin und her kopiert werden müssen, dann wird das mit 10G schon recht rechenintensiv.
Von Urs Pfister2 am Fr, 2. Dezember 2016 um 09:22 #
Soweit ich es beobachten kann, arbeitet nc im Grundsatz nicht schlecht, wenn auch der Aufruf nicht ganz so elegant ist.
Schneller ist nc aber nicht, weder bei NFS noch bei der DRBD-Variante. Bei 40 GBit-Karten z.B. hätte ich ca. 3 Minuten (DRBD-Variante) gegenüber ca. 5 Minuten bei netcat bei einer Datei von ca. 150 GByte. Verwendete Hardware:
Wenn alles glatt läuft, ist Kopieren von einer lokal gemounteten Offline-DRBD-Platte auf einen anderen lokalen Datenträger naturgemäß die beste Variante, da ja der Netzwerk-Overhead wegfällt. Meiner Erfahrung nach gibt es allerdings ein Problem, wenn beide Platten am selben Controller hängen. Da bricht recht schnell die Datenrate ein, sobald der Cache voll ist. Darauf war meine Aussage mit dem Bottleneck bezogen. In diesem Szenario geht es bei mir schneller mit netcat.
Das Praktische an netcat ist für mich, dass es sofort zur Hand ist und man nicht erst einen NFS-Server installieren und konfigurieren muss, um mal eben schnell ein Backup zu machen.
Optionen bezüglich Blockgrösse kenne ich keine, macht aber m.E. auch keinen Sinn, da sich nc rein aufs Pipen übers Netz beschränkt und den Rest den vorigen und nächsten Prozessen in der Pipe überlässt.
Dass nc+tar mehr CPU-Power benötigen als NFS+cp, wundert mich insofern, als dass im Fall von NFS ein Server involviert ist, der ja einen gewissen Overhead mitbringt. NFS läuft im Kernel - hast du dir in htop die Kernel-Threads eingeblendet bzw. in top auf die Angabe bei "sy" geachtet?
Von Urs Pfister2 am Fr, 2. Dezember 2016 um 20:23 #
Ich werde nochmals (aber frühestens nächste Woche) Tests mit 10 und 40 GBit fahren, und dabei nc gerne auch berücksichtigen, auch wenn ich heute eher das Gefühl hatte, nc wäre langsamer.
Und sicher ist nc recht praktisch, da überall verfügbar, auch wenn ich die Syntax jetzt nicht wahnsinnig berauschend finde. Zugegeben, dies NFS und DRDB konfiguriert sind, das dürfte länger dauern, in dieser Hinsicht ist nc dann gerade wieder einfach.
Es ist mittlerweile Best Practice, in einem cloudbasierten globalen Agileworkflow, die Appliances zu den Daten zu bringen, nicht die Daten zu Appliances. Das geht viel schneller und ist wichtig im Wettbewerb.
Von Urs Pfister2 am Fr, 2. Dezember 2016 um 10:28 #
Best Practice => Was verstehst Du darunter?
Cloudbasierten globalen Agileworkflow => Häh?
Applicances zu Daten Daten zu Applicanes?
Und was um Himmels willen hat dies mit dem Artikel zu tun, wo es um die Frage geht, wie sich grosse Datenmengen zwischen zwei Rechnern übertragen lassen?
hEAdr00m ist ein Troll, der sich bei Pro-Linux fürs Bullshit-Bingo zuständig fühlt.
Ich kann mir oft ein Grinsen nicht verkneifen, wenn ich das lese. Erinnert mich immer an die Microsoft-Manager, mit denen ich berufsbedingt zusammenarbeiten muss...
Ich dachte, ich haette mich klar ausgedrueckt. Schlaue Leute wie ich haben mittlerweile herausgefunden (=Best Practice), dass es besser ist, die Rechner zu den grossen Datenmengen zu bringen. Nicht umgekehrt. Hoffe, geholfen zu haben.
Noch schlauere Leute als du haben mittlerweile auch herausgefunden, dass rein zentralistische Storage Architekturen nicht immer die geilste Lösung sind.
- Single Point of Failure - Vendor Lockin - Auch bei redundanten Lösungen kann ein Amok laufender Patch alles still legen (schon bei uns im RZ gehabt, wo die Webseite gehostet wird).
Aus meiner Sicht geht der Trend eher in die andere Richtung als Mischform. Halt Objekt-based Storage verteilt über viele Knoten mit Commodity Hardware.
Von Urs Pfister2 am So, 4. Dezember 2016 um 00:37 #
Ich sehe jetzt kein Vendor Lock bei Open Source, ich sehe bei DRBD auch kein Single Point of Failure.
Die 'grossen' Daten liegen bei mir, also möchte ich die Rechner ganz bestimmt nicht in der Cloud haben. An der Leitung mit öffentlicher IP kanns nicht liegen, das kostet heute sehr sehr wenig, die Open Source Firewall hilft wohl besser abzuschotten, als eine jede Cloud, wo ich noch nicht mal weiss, was die Anbieter da mixen (dies alleine ist doch Single Point of Failure, ich kann es grad gar nicht beeinflussen). Ich möchte auch nicht mit 99 Prozent Verfügbarkeit extern leben müssen, sondern entscheide gerne selber, wann wo und wie es läuft, und übernehme dafür auch gerne die Verantwortung.
Und sag mir mal bitte, wie ich Betriebssysteme, die wir bauen, als Objekt-based Storage führen soll? Ich bau die Betriebssystem nun sehr schlank (ArchivistaMini braucht keine 80 MByte), aber die anderen Produkte mit all den gewünschten Applikationen (LibreOffice alleine 'frisst' 500 MByte), das geht unter ein paar GByte leider nicht. Und da ist es doch praktisch zu wissen, dass ich die Daten mit nfs/drbd im Nu auf andere Rechner kiege.
Ich spiele auch keine Patches ein, sondern die neu gebauten ISO wandern in die Testumgebung, und erst wenn es dort ok ist, geht es auf die Produktivmaschinen. Dabei könnte es vor und zurückgehen (letzteres war bisher nicht wirklich notwendig). Ich könnte es aber, da meine Debian-Linuxe im RAM laufen. Booten ab alter ISO, und ich bin wieder zurück. Mit all diesen Features habe ich in der Cloud keine Chancen.
Commodity-Hardware verwenden wir noch so gerne, alle Messungen erfolgten genau mit solcher Hardware. Die Messungen sind/waren Bestandteil meines Vortrages:
Du aber meinst noch immer, ich würde rein zentralistische Storage-Architekturen aufbauen, dabei mach ich gerade das nicht. Allerdings, ein Image einer Distro ist und bleibt ein Image. Und die Kundeninstallation z.B. in der Form eines ERP-Systems liegt auch in einem Image, da ist es doch verdammt praktisch, wenn ich solche Gäste in ein paar Sekunden zügle, anstatt mit rsync viele Minuten bis Stunden zu warten.
Und ja, offen gestanden interessieren mich Trends nicht mehr wahnsinnig. Da ist in den letzten 20 Jahren schon so viel gekommen und gegangen. Die Wolke wird weiterziehen, da bleib ich gerne auf dem Boden -- und messe dann auch immer mal wieder.
Für das Backup solchen Images kann ich Borg Backup empfehlen.
Durch die eingebaute Blockbasierte Deduplizierung kann man mehrere Generationen von Images sichern aber trotzdem verbraucht man nur wenig mehr Platz als das Image selbst einnimmt. Oft sogar weniger. Und bei der Wiederherstellung kann man die Option --sparse angeben so das das Image als Sparse Datei angelegt wird.
In einem Versuch hat gerade ein cp für ein 1T sparse file von NFS-Mount zu lokalem Dateisystem den Dateiinhalt zu übertragen versucht, sprich war langsam. Jedoch von lokalem Dateisystem zum NFS-Mount hat der cp "keine" Zeit gebraucht.
für die Verteilung von VMs in einem Schulungsraum mit 30 PCs, die nur mit 100MBit angebunden sind, verwenden wir Bittorrent. Die Zeit, die benötigt wird, um die VMs per Bittorrent auf alle Clients zu verteilen, entspricht der Zeit, die es vorher gedauert hat, die VM vom Server auf einen Client zu kopieren.
Als BT-Tracker nehmen wir opentracker (http://erdgeist.org/arts/software/opentracker/) und als BT-Client aria2c (https://aria2.github.io/). Die Clients tauschen bekannte Teile der VM untereinander aus.
Das sollte auch bei deutlich größeren Schulungsräumen funktionieren.
Wieso kopieren die Leute immer offline hin und her? Schlauerweise nimmt man ein dezentrales Cluster-Filesystem mit Geo-Replication. Dann klappt es auch mit dem Online in Sekundenschnelle von Node zu Node kopieren.
Der Betreff sagt es: was bringt scp mit eingeschalteter Kompression vergleichsweise.
Scp bringt für die bei der Virtualisierung typischen Sparse-Dateien nichts, weil SCP (auch wenn es mit dem Flag -C aufgerufen wird), am Ende die Datei zur maximalen Grösse aufbläst.
Scp bringt für die bei der Virtualisierung typischen Sparse-Dateien nichts, weil SCP (auch wenn es mit dem Flag -C aufgerufen wird), am Ende die Datei zur maximalen Grösse aufbläst.
Mich würde mal der Vergleich mit NetCat und das mit und ohne Kombination mit PipeViewer interessieren. Das nutze ich nämlich ab und an ganz gerne mal.
In der Vergangenheit hat sich die Kombination auch für viele kleine Dateien als sehr performant erwiesen. Als Beispiel:
Bisher konnte ich damit bessere Ergebnisse erzielen als mit SCP, NFS +co.
Da ich aber bisher nicht über Gigabit Ethernet hinaus gekommen bin und es sich zumeist auch um Rotationsplatten handelte... ich mein, es könnte ja bei 10G und SSD anders aussehen...
Insbesondere weiß ich nicht, in wie weit die involvierten Programme effiziente Pipes unterstützen. Wenn alle Daten zwischen den Prozessen im Speicher hin und her kopiert werden müssen, dann wird das mit 10G schon recht rechenintensiv.
Bingo. nc ist übers Netzwerk immer am schnellsten. Auch bei 10GBit.
Tipp: sparse-Dateien effizient übertragen: 'tar cS'.
Das Bottleneck ist letztlich immer der Durchsatz dar langsamsten der beteiligten Komponenten.
Soweit ich es beobachten kann, arbeitet nc im Grundsatz nicht schlecht, wenn auch der Aufruf nicht ganz so elegant ist.
Schneller ist nc aber nicht, weder bei NFS noch bei der DRBD-Variante. Bei 40 GBit-Karten z.B. hätte ich ca. 3 Minuten (DRBD-Variante) gegenüber ca. 5 Minuten bei netcat bei einer Datei von ca. 150 GByte. Verwendete Hardware:
http://archivista.ch/cms/language/de/aktuell-blog/bigfoot-mit-40gbit
Nachfrage: Gibt es bei netcat Optionen, um die Blockgrösse festzulegen?
Sowohl bei nc als auch mit tar cS (auch kombiniert) benötige ich deutlich mehr CPU-Power als dies der Fall mit 'cp' und NFS/DRBD der Fall ist.
Wenn alles glatt läuft, ist Kopieren von einer lokal gemounteten Offline-DRBD-Platte auf einen anderen lokalen Datenträger naturgemäß die beste Variante, da ja der Netzwerk-Overhead wegfällt. Meiner Erfahrung nach gibt es allerdings ein Problem, wenn beide Platten am selben Controller hängen. Da bricht recht schnell die Datenrate ein, sobald der Cache voll ist. Darauf war meine Aussage mit dem Bottleneck bezogen. In diesem Szenario geht es bei mir schneller mit netcat.
Das Praktische an netcat ist für mich, dass es sofort zur Hand ist und man nicht erst einen NFS-Server installieren und konfigurieren muss, um mal eben schnell ein Backup zu machen.
Optionen bezüglich Blockgrösse kenne ich keine, macht aber m.E. auch keinen Sinn, da sich nc rein aufs Pipen übers Netz beschränkt und den Rest den vorigen und nächsten Prozessen in der Pipe überlässt.
Dass nc+tar mehr CPU-Power benötigen als NFS+cp, wundert mich insofern, als dass im Fall von NFS ein Server involviert ist, der ja einen gewissen Overhead mitbringt. NFS läuft im Kernel - hast du dir in htop die Kernel-Threads eingeblendet bzw. in top auf die Angabe bei "sy" geachtet?
Ich werde nochmals (aber frühestens nächste Woche) Tests mit 10 und 40 GBit fahren, und dabei nc gerne auch berücksichtigen, auch wenn ich heute eher das Gefühl hatte, nc wäre langsamer.
Und sicher ist nc recht praktisch, da überall verfügbar, auch wenn ich die Syntax jetzt nicht wahnsinnig berauschend finde. Zugegeben, dies NFS und DRDB konfiguriert sind, das dürfte länger dauern, in dieser Hinsicht ist nc dann gerade wieder einfach.
Je nach CPU- und Netzwerkgeschwindigkeit könnte es sich noch lohnen, mit einem schnellen Kompressor wie z.B. lzop zu arbeiten.
Es ist mittlerweile Best Practice, in einem cloudbasierten globalen Agileworkflow, die Appliances zu den Daten zu bringen, nicht die Daten zu Appliances. Das geht viel schneller und ist wichtig im Wettbewerb.
hEAdr00m (Profi)
BINGO, BINGO, BINGO !
yes - ging mir auch so, allerdings sah ich 5x {$BINGO}...
Best Practice => Was verstehst Du darunter?
Cloudbasierten globalen Agileworkflow => Häh?
Applicances zu Daten Daten zu Applicanes?
Und was um Himmels willen hat dies mit dem Artikel zu tun, wo es um die Frage geht, wie sich grosse Datenmengen zwischen zwei Rechnern übertragen lassen?
hEAdr00m ist ein Troll, der sich bei Pro-Linux fürs Bullshit-Bingo zuständig fühlt.
Ich kann mir oft ein Grinsen nicht verkneifen, wenn ich das lese. Erinnert mich immer an die Microsoft-Manager, mit denen ich berufsbedingt zusammenarbeiten muss...
Hatte ja auch dieses Gefühl, danke für die Bestätigung.
Ich dachte, ich haette mich klar ausgedrueckt. Schlaue Leute wie ich haben mittlerweile herausgefunden (=Best Practice), dass es besser ist, die Rechner zu den grossen Datenmengen zu bringen. Nicht umgekehrt. Hoffe, geholfen zu haben.
Noch schlauere Leute als du haben mittlerweile auch herausgefunden, dass rein zentralistische Storage Architekturen nicht immer die geilste Lösung sind.
- Single Point of Failure
- Vendor Lockin
- Auch bei redundanten Lösungen kann ein Amok laufender Patch alles still legen (schon bei uns im RZ gehabt, wo die Webseite gehostet wird).
Aus meiner Sicht geht der Trend eher in die andere Richtung als Mischform. Halt Objekt-based Storage verteilt über viele Knoten mit Commodity Hardware.
Ich sehe jetzt kein Vendor Lock bei Open Source, ich sehe bei DRBD auch kein Single Point of Failure.
Die 'grossen' Daten liegen bei mir, also möchte ich die Rechner ganz bestimmt nicht in der Cloud haben. An der Leitung mit öffentlicher IP kanns nicht liegen, das kostet heute sehr sehr wenig, die Open Source Firewall hilft wohl besser abzuschotten, als eine jede Cloud, wo ich noch nicht mal weiss, was die Anbieter da mixen (dies alleine ist doch Single Point of Failure, ich kann es grad gar nicht beeinflussen). Ich möchte auch nicht mit 99 Prozent Verfügbarkeit extern leben müssen, sondern entscheide gerne selber, wann wo und wie es läuft, und übernehme dafür auch gerne die Verantwortung.
Und sag mir mal bitte, wie ich Betriebssysteme, die wir bauen, als Objekt-based Storage führen soll? Ich bau die Betriebssystem nun sehr schlank (ArchivistaMini braucht keine 80 MByte), aber die anderen Produkte mit all den gewünschten Applikationen (LibreOffice alleine 'frisst' 500 MByte), das geht unter ein paar GByte leider nicht. Und da ist es doch praktisch zu wissen, dass ich die Daten mit nfs/drbd im Nu auf andere Rechner kiege.
Ich spiele auch keine Patches ein, sondern die neu gebauten ISO wandern in die Testumgebung, und erst wenn es dort ok ist, geht es auf die Produktivmaschinen. Dabei könnte es vor und zurückgehen (letzteres war bisher nicht wirklich notwendig). Ich könnte es aber, da meine Debian-Linuxe im RAM laufen. Booten ab alter ISO, und ich bin wieder zurück. Mit all diesen Features habe ich in der Cloud keine Chancen.
Commodity-Hardware verwenden wir noch so gerne, alle Messungen erfolgten genau mit solcher Hardware. Die Messungen sind/waren Bestandteil meines Vortrages:
https://fileshare.lugv.at/public/LinuxDay_2016/raum_104/archivistavm-cloud.pdf
Du aber meinst noch immer, ich würde rein zentralistische Storage-Architekturen aufbauen, dabei mach ich gerade das nicht. Allerdings, ein Image einer Distro ist und bleibt ein Image. Und die Kundeninstallation z.B. in der Form eines ERP-Systems liegt auch in einem Image, da ist es doch verdammt praktisch, wenn ich solche Gäste in ein paar Sekunden zügle, anstatt mit rsync viele Minuten bis Stunden zu warten.
Und ja, offen gestanden interessieren mich Trends nicht mehr wahnsinnig. Da ist in den letzten 20 Jahren schon so viel gekommen und gegangen. Die Wolke wird weiterziehen, da bleib ich gerne auf dem Boden -- und messe dann auch immer mal wieder.
Für das Backup solchen Images kann ich Borg Backup empfehlen.
Durch die eingebaute Blockbasierte Deduplizierung kann man mehrere Generationen von Images sichern aber trotzdem verbraucht man nur wenig mehr Platz als das Image selbst einnimmt. Oft sogar weniger. Und bei der Wiederherstellung kann man die Option --sparse angeben so das das Image als Sparse Datei angelegt wird.
In einem Versuch hat gerade ein cp für ein 1T sparse file von NFS-Mount zu lokalem Dateisystem den Dateiinhalt zu übertragen versucht, sprich war langsam.
Jedoch von lokalem Dateisystem zum NFS-Mount hat der cp "keine" Zeit gebraucht.
Danke für den Hinweis, ich werde dies gerne testen, klingt spannend. Haben andere die gleiche Erfahrung gemacht?
Hallo,
für die Verteilung von VMs in einem Schulungsraum mit 30 PCs, die nur mit 100MBit angebunden sind, verwenden wir Bittorrent. Die Zeit, die benötigt wird, um die VMs per Bittorrent auf alle Clients zu verteilen, entspricht der Zeit, die es vorher gedauert hat, die VM vom Server auf einen Client zu kopieren.
Als BT-Tracker nehmen wir opentracker (http://erdgeist.org/arts/software/opentracker/) und als BT-Client aria2c (https://aria2.github.io/). Die Clients tauschen bekannte Teile der VM untereinander aus.
Das sollte auch bei deutlich größeren Schulungsräumen funktionieren.
Wieso kopieren die Leute immer offline hin und her? Schlauerweise nimmt man ein dezentrales Cluster-Filesystem mit Geo-Replication. Dann klappt es auch mit dem Online in Sekundenschnelle von Node zu Node kopieren.