may24x
Anmeldungsdatum: 26. April 2016
Beiträge: 116
|
Hi zusammen. Ich habe folgende Konfiguration: Auf meinem Server Läuft Ubuntu und in einer virtuellen Maschine (VBox) Win7.
Diese "Teilen" sich quasi eine Festplatte (sie greifen beide auf das gleiche Dateisystem zu). Da Win bekanntlich ext4 nicht unterstützt habe ich kurzerhand einen Samba Server konfiguriert der auf das lokale Dateisystem zeigt.
Leider ist es so, das ich bis weilen massive Geschwindigkeitseinbrüche beim Zugriff auf das Netzlaufwerk von meiner Win7 VM habe.
Nach einigem rumprobieren bin ich zum Schluß gekommen das dies wohl ein Netzwerk Problem ist. Der Samba Server läuft an 192.168.0.1. Die VM benutzt NAT und hat 192.168.1.100 (Beispiel !)
Wenn die Win7 Kiste das Netzlaufwerk verbindet, so "kontaktiert" es die eth0 an 192.168.0.1.
Sollte eth0 - aus welchen Gründen auch immer (viel Traffic, Netzwerkkabel nicht gesteckt oder Switch/Router cong.) - Probleme mit der Weiterleitung von Datenpaketen haben, so betrifft das auch den Samba Dienst und die Zugriffszeiten gehen massiv in den Keller bzw. (hatte ich schon zwei Mal) brechen völlig weg !
Dabei ist es völlig egal wie die VM Netzwerkschnittstelle konfiguriert ist. Ob NAT, Bridge oder local ... spielt keine Rolle. Nun war meine Idee den Samba Server an 'localhost' laufen zu lassen und somit keinen "Umweg" über die Netzwerkkarte nehmen zu müssen.
Den Server bekomme ich an z.B. 127.0.0.1 auch an's laufen ... ABER die VM kann diese "Adresse" (localhost) nicht ansprechen, da sie ja ihren eigenen loaclhost (127.0.0.1) hat.
Mit anderen Worten: Host: localhost != VM: localhost (nein, auch im Bridged-Mode nicht!) - So wie's ausschaut bekommt jede Kiste immer ihren eigenen localhost. Zweite Idee: Ich konfiguriere eine weitere (virtuelle) Netzwerkkarte in Vbox die auf das lokale 127.0.0.1 zeigt ... Das war jedoch bisher erfolglos. Der Win7 Client findet den Server bzw. dessen Shares nicht ... Jemand 'ne Idee ?
Alternative ?
|
Thomas_Do
Moderator
Anmeldungsdatum: 24. November 2009
Beiträge: 8808
|
Wenn Du in VB einen Ordner zum "Gemeinsamen Ordner" machst, kann Windows problemlos auch auf ext-formatierte Platten zugreifen. Ob das schneller geht, weiß ich nicht. Einfacher als Samba ist es auf jeden Fall.
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
may24x schrieb: Nun war meine Idee den Samba Server an 'localhost' laufen zu lassen und somit keinen "Umweg" über die Netzwerkkarte nehmen zu müssen.
Das funktioniert nicht, da wie du richtig erkannt hast, auch die VM ihren eigenen Localhost hat.
Zweite Idee: Ich konfiguriere eine weitere (virtuelle) Netzwerkkarte in Vbox die auf das lokale 127.0.0.1 zeigt ... Das war jedoch bisher erfolglos. Der Win7 Client findet den Server bzw. dessen Shares nicht ...
Du kannst einfach einen zweiten Adapter an die VM pappen. Den klemmst du an eine Bridge, die du auf dem Hostsystem erstellst, und konfigurierst dort ein anderes Netz. Dann kannst du Samba dort lauschen lassen und damit ausschließlich mit virtuellen Netzwerkinterfaces kommunizieren.
Alternative ?
Wäre nicht das "Gemeinsame Ordner"-Feature was für dich? Das wäre noch einfacher einzurichten.
|
may24x
(Themenstarter)
Anmeldungsdatum: 26. April 2016
Beiträge: 116
|
misterunknown schrieb: Du kannst einfach einen zweiten Adapter an die VM pappen. Den klemmst du an eine Bridge, die du auf dem Hostsystem erstellst, und konfigurierst dort ein anderes Netz. Dann kannst du Samba dort lauschen lassen und damit ausschließlich mit virtuellen Netzwerkinterfaces kommunizieren.
Nein. Da müßte ich wieder den Umweg über die Netzwerkkarte machen. Nur das die jetzt noch ein weiteres Netz konfiguriert haben muss.
Man kann 'lo' auch keine weitere virtuelle IP verpassen wie z.B. eth0:1 ...
Eine weiter Idee war es vie iptables die Pakete umzuleiten ... nach 127.0.0.1 geht das auch ... aber den Weg zurück nicht.
Wäre nicht das "Gemeinsame Ordner"-Feature was für dich? Das wäre noch einfacher einzurichten.
Nein ! Davon kann ich nur dringend abraten ! Für - mal - 'n paar Files hin und her zu schieen ok, Aber ... Dieses Feature hat mich einiges dan Daten gekostet. Es kann (recht häufig sogar) vorkommen das ein Verzeichnis nicht bzw. nicht schnell genug upated wird (so das Win das mitbekommt) und die Datei entweder nicht gefunden oder überschrieben oder das veränderte config file nicht mit den Änderungen gelesen wird ... usw.
Da half nur exzessives drücken der F5 Taste. Und Geschwindigkeitszuwachs gibt's auch nicht. Und NFS ist auch keine Lösung ...
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
may24x schrieb: Nein. Da müßte ich wieder den Umweg über die Netzwerkkarte machen.
Aber über keine physische.
Nur das die jetzt noch ein weiteres Netz konfiguriert haben muss.
Nun, es ist aber ein Unterschied, ob die gleiche qdisc belastet wird oder nicht. Den Protokoll-Overhead hättest du natürlich trotzdem, aber keine Verzögerungen durch viel Traffic.
Man kann 'lo' auch keine weitere virtuelle IP verpassen wie z.B. eth0:1 ...
Doch, das geht. Es nützt dir nur nichts, weil Verkehr auf dem Interface normal nicht geroutet wird. Deshalb würde ich einfach eine Dummy-Bridge dafür nehmen:
ip link add br0 type bridge
ip address add 10.0.0.1/24 dev br0
ip link set br0 up
Damit läuft der Traffic über eine eigene Queue.
Eine weiter Idee war es vie iptables die Pakete umzuleiten ... nach 127.0.0.1 geht das auch ... aber den Weg zurück nicht.
Doch, auch das geht, wenn man das unbedingt will. Dazu einfach das Routing für lokale Netze aktivieren.
|
may24x
(Themenstarter)
Anmeldungsdatum: 26. April 2016
Beiträge: 116
|
Hallo, nur damit ich das richtig verstehe ... Man lege eine (dummy) Brücke an die "keine Netzwerke verbindet"
D.h. sie zeigt immer auf 'localhost' (?) Damit sie permanet wird/bleibt hab ich in /etc/network/interfaces folgenden Eintrag gemacht:
| auto br0
iface br0 inet static
address 192.168.10.1
netmask 255.255.255.254
bridge_ports none
|
Der lokale Samba Server läuft jetzt an 192.168.10.1 und stellt dort den share zur Verfügung. Doch mounte ich jetzt wirklich das ganze über das lo Interface ? Das wird ja einem nirgendwo angezeit ... Ich meine einen geringe Geschwindigkeitszuwachs festzustellen ... aber so flüssig wie ein "direkter" Festplattenzugriff (obwohl's ja die selbe Büchse ist) läuft es nicht. Aber so wie ich das she gibt's da keine Alternative ... oder hat sich da bei Win 10 was getan ? Soweit ich gelesen habe ist NFS auch keine Lösung ...
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11260
Wohnort: München
|
may24x schrieb: Ich meine einen geringe Geschwindigkeitszuwachs festzustellen ... aber so flüssig wie ein "direkter" Festplattenzugriff (obwohl's ja die selbe Büchse ist) läuft es nicht.
Klar - den Overhead, der mit einer Samba-Freigabe einhergeht, wirst du so nicht los. Was genau ist den der Anwendungsfall für die Freigabe? Für mich klingt das so, als ginge es da um größere Datenmengen und eventuell bremst der parallele Zugriff auf eine einzelne Platte durch die VM und das Host-System da kräftig mit (oder stammt die hohe Netzwerkauslastung von etwas anderem als Daten mit der Platte auszutauschen?).
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
may24x schrieb: nur damit ich das richtig verstehe ... Man lege eine (dummy) Brücke an die "keine Netzwerke verbindet"
D.h. sie zeigt immer auf 'localhost' (?)
Nun, localhost ist eine spezielle Bezeichnung, die normalerweise mit dem link-lokalen Interface assoziiert wird. Die Bridge ist zwar nur lokal auf dem System verfügbar, hat aber nichts mit dem Name "localhost" oder dem lo-Interface zu tun.
Doch mounte ich jetzt wirklich das ganze über das lo Interface ? Das wird ja einem nirgendwo angezeit ...
Nein, nicht über lo, sondern über br0. Ich hatte überlesen, dass du VirtualBox zur Virtualisierung benutzt. Wenn du mit libvirt virtualisieren würdest, könntest du gleich alle VMs an die Brücke hängen. Mit Virtualbox hätte man auch ein normales Dummy-Interface nehmen können.
Ich meine einen geringe Geschwindigkeitszuwachs festzustellen ... aber so flüssig wie ein "direkter" Festplattenzugriff (obwohl's ja die selbe Büchse ist) läuft es nicht.
Wie seahawk1986 schon schrieb: Zwei Overheads wirst du nicht los: Den Samba-Protokoll-Overhead und den Netzwerk-Paket-Overhead.
Soweit ich gelesen habe ist NFS auch keine Lösung ...
Meines Erachtens suchst du an der falschen Stelle. Du hast im ersten Post geschrieben, dass du durch "herumspielen" rausgekriegt hast, dass das Netzwerk "wohl" der Flaschenhals ist. Kannst du das konkretisieren? Welche Werte hast du gemessen? Was sagen iotop und iftop? Hast du mal den möglichen Netzwerk-Durchsatz mit iperf gemessen?
|
may24x
(Themenstarter)
Anmeldungsdatum: 26. April 2016
Beiträge: 116
|
Nein, konkrete Statistiken habe ich noch nicht gemacht/ausgewertet. Doch das war auch (erst mal) gar nicht notwendig. Die Urkonstellation war ja: Auf der VM multiplexe ich via MkvToolnix ein Video File. Dabei nimmt er Audio + Video vom Samba Share und schreibt den neuen File gleich wieder auf das Selbige. Selber Pfad, neue Datei. Schiebe ich (z.B.) via sftp oder smb noch eine Datei parallel auf meinen Storage-Server, so bricht die schreib/lese Geschwindigkeit auf der VM Seite massiv ein. Das kann man direkt beobachten. Daher ja die Idee mit dem Samba-Server an lo um nicht den Umweg über eth0 machen zu müssen. Das "eigentliche Problem" ist, das Windows nun mal kein ext4 unterstützt bzw. es (scheinbar) keine Alternative gibt - außer Samba und NFS - die die Win und Linux Welt auf ein gemeinsames (pysikalisches) Laufwerk zugreifen läßt. Und nein, die Cloud ist auch keine Lösung, da die ja auch nur ein Netzwerk-Service ist und somit auch alles wieder in IP kapselt und durch die Gegend schickt ... dann kann ich auch gleich Samba machen. Mich wundert nur das Samba - an br0 - nur geringe Geschwindigkeit Verbesserung bringt. Auch habe ich des öfteren den Effekt das die ersten 100mb super fix gehen, danach die schreib/lese Geschwindigkeit aber wieder einbricht. Ich schibe das mal auf ein "mögliches" Cache Problem. Allerdings hab ich noch keine SMB-Tunings gefunden die sich damit beschäftigen. Noch dazu war ja die Überlegung, das wenn die Netzwerkkarte (eth0) quasi "übergangen" wird, überhaupt eine Modifikation von SMB notwendig ist um mehr speed zu erreichen ... Nachtrag: Ich hab jetzt doch mal einige Samba-tuning Parameter gefunden .... die werde ich gleich mal testen 😀
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11260
Wohnort: München
|
Ich würde als ersten Schritt mal nicht gleichzeitig von der gleichen Platte lesen und wieder darauf schreiben, sondern eine Platte für das Rohmaterial und eine für das erzeugte Material verwenden. Festplatten sind bei konkurierenden Schreib- und Lesezugriffen immer eine ziemliche Bremse, weil die Zugriffszeiten vergleichsweise hoch sind und man mit jedem Wechsel der Kopfposition eine Zwangspause für alle anderen Programme, die gerade I/O mit der Platte machen wollen einführt.
|
may24x
(Themenstarter)
Anmeldungsdatum: 26. April 2016
Beiträge: 116
|
seahawk1986 schrieb: Ich würde als ersten Schritt mal nicht gleichzeitig von der gleichen Platte lesen und wieder darauf schreiben, sondern eine Platte für das Rohmaterial und eine für das erzeugte Material verwenden. Festplatten sind bei konkurierenden Schreib- und Lesezugriffen immer eine ziemliche Bremse, weil die Zugriffszeiten vergleichsweise hoch sind und man mit jedem Wechsel der Kopfposition eine Zwangspause für alle anderen Programme, die gerade I/O mit der Platte machen wollen einführt.
Fällt aus ! ... Gibt keine zweite Platte.
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
may24x schrieb: Nein, konkrete Statistiken habe ich noch nicht gemacht/ausgewertet.
Doch das war auch (erst mal) gar nicht notwendig.
Konkrete Messungen sind immer nötig, um den Flaschenhals zu finden.
Schiebe ich (z.B.) via sftp oder smb noch eine Datei parallel auf meinen Storage-Server, so bricht die schreib/lese Geschwindigkeit auf der VM Seite massiv ein.
Ja, aber daraus kannst du noch keine Ursache ableiten, das ist erstmal nur ein Symptom. Ob nun das Netzwerk oder die Platte oder die CPU ist, weißt du erstmal nicht.
Mich wundert nur das Samba - an br0 - nur geringe Geschwindigkeit Verbesserung bringt.
Vielleicht lag es ja nicht am Netzwerkstack.
Auch habe ich des öfteren den Effekt das die ersten 100mb super fix gehen, danach die schreib/lese Geschwindigkeit aber wieder einbricht. Ich schibe das mal auf ein "mögliches" Cache Problem.
Ja, vermutlich lädt er erstmal größere Teile der Datei in den RAM um sie weiterverarbeiten zu können. Das ist natürlich fix. Wenn er dann die ersten Daten auf die Platte schreiben will, bricht die Performance ein, weil sowohl gelesen als auch geschrieben wird.
Allerdings hab ich noch keine SMB-Tunings gefunden die sich damit beschäftigen. Noch dazu war ja die Überlegung, das wenn die Netzwerkkarte (eth0) quasi "übergangen" wird, überhaupt eine Modifikation von SMB notwendig ist um mehr speed zu erreichen ...
Wie gesagt: Samba als Protokoll halte ich hier für unschuldig. Sicherlich kann man das ein oder andere Prozent an Geschwindigkeit mit Samba-Tuning herausholen, aber das ist nicht wirklich relevant für dich.
|
may24x
(Themenstarter)
Anmeldungsdatum: 26. April 2016
Beiträge: 116
|
hm, hab jetzt folgende tunings in /etc/samba/smb.conf [global]
unix extensions = yes
workgroup = WORKGROUP
server string = Samba Server %h server
dns proxy = no
security = user
log file = /var/log/samba/log.%m
wins support = no
dns proxy = no
ntlm auth = no
lanman auth = no
client ntlmv2 auth = yes
load printers = no
printing = CUPS
printcap name = CUPS
disable spoolss = yes
hosts allow = 192.168.10.5
interfaces = br0
bind interfaces only = Yes
syslog = 0
server role = standalone server
passdb backend = tdbsam
obey pam restrictions = yes
socket options = IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536 TCP_NODELAY
min receivefile size = 2048
use sendfile = true
aio read size = 2048
aio write size = 2048
write cache size = 1024000
read raw = yes
write raw = yes
getwd cache = yes
oplocks = yes
max xmit = 32768
large readwrite = yes Funktioniert soweit ganz gut ... Nur eine Sache stört mich gewaltig. Jedes mal nach einem Reboot findet der Windows Client ein neues Interface.
Das liegt daran das br0 jedes mal (zufällig) eine neue MAC-Adresse generiert bekommt. Gibt es die Möglichkeit br0 eine feste MAC-Adresse in 'interfaces' zu konfigurieren ? auto br0
iface br0 inet static
address 192.168.10.1
netmask 255.255.255.0
bridge_ports none
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
auto br0
iface br0 inet static
...
hwaddress ether 01:02:03:04:05:06
|
may24x
(Themenstarter)
Anmeldungsdatum: 26. April 2016
Beiträge: 116
|
|