วิธีที่รวดเร็วในการคัดลอกไฟล์ขนาดใหญ่บน LAN

ฉันมีปัญหากับ NFS และฉันต้องการลองใช้ TCP แบบเก่าธรรมดา

ฉันไม่รู้ว่าจะเริ่มจากตรงไหน

ฉลาดหลักแหลมฉันใช้สายเคเบิลอีเธอร์เน็ตข้ามเครือข่ายสองเน็ตบุ๊ค

เพื่อเครือข่ายพวกเขาฉันพิมพ์

$ sudo ifconfig eth0 192.168.1.1 up && ping -c 10 -s 10 192.168.1.2 && sudo /etc/init.d/nfs-kernel-server start

ในเน็ตบุ๊กแรกและ

$ sudo ifconfig eth0 192.168.1.2 up
$ ping -c 10 -s 10 192.168.1.1
$ mount /mnt/network1

ในวินาที

โดยที่/mnt/network1ระบุไว้ใน / etc / fstab เป็น

192.168.1.1:/home /mnt/network1 nfs noauto,user,exec,soft,nfsvers=2 0 0

เช่นเดียวกับใน/etc/exports(ใช้ไวยากรณ์ของไฟล์นั้น) ในเน็ตบุ๊กแรก

ข้างต้นใช้งานได้ดี แต่ไฟล์และไดเรกทอรีมีขนาดใหญ่มาก ไฟล์เฉลี่ยประมาณครึ่งกิกะไบต์และชิ้นส่วนทั้งหมดจะอยู่ระหว่าง 15 ถึง 50 กิกะไบต์

ฉันใช้rsyncเพื่อถ่ายโอนและคำสั่ง (เปิด192.168.1.2) คือ

$ rsync -avxS /mnt/network1 ~/somedir

ฉันไม่แน่ใจว่ามีวิธีปรับแต่งการตั้งค่า NFS ของฉันให้จัดการกับไฟล์ขนาดใหญ่ได้ดีขึ้นหรือไม่ แต่ฉันต้องการดูว่าการใช้rsyncdaemon ผ่าน TCP แบบเก่าธรรมดานั้นทำงานได้ดีกว่าrsyncNFS หรือไม่

ดังนั้นเพื่อย้ำอีกครั้งฉันจะตั้งค่าเครือข่ายที่คล้ายกันกับ TCP ได้อย่างไร

UPDATE:

ดังนั้นหลังจากเวลาผ่านไปสองสามชั่วโมงหลังจากพยายามดึงตัวเองออกจากความไม่รู้ของตัวเอง (หรืออย่างที่ฉันคิดจะดึงตัวเองขึ้นมาจากรองเท้าบู๊ตของตัวเอง) ฉันจึงได้รับข้อเท็จจริงที่มีประโยชน์

แต่ก่อนอื่นสิ่งที่ทำให้ฉันบนเส้นทางกระต่ายนี้แทนที่จะเพียงแค่ยอมรับคำตอบที่ดีที่สุดในปัจจุบันคือ: ncนี่เป็นโปรแกรมที่ยอดเยี่ยมที่ไม่น่าเชื่อที่ไม่สามารถทำงานให้ฉันได้ ฉันได้ลองnetcat-openbsdและnetcat-traditionalแพ็คเกจโดยไม่มีโชค แต่อย่างใด

ข้อผิดพลาดที่ฉันได้รับจากเครื่องรับ ( 192.168.1.2) คือ:

me@netbook:~$ nc -q 1 -l -p 32934 | tar xv
Can't grab 0.0.0.0:32934 with bind
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors

route ให้:

me@netbook:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         dir-615         0.0.0.0         UG    0      0        0 wlan0
link-local      *               255.255.0.0     U     1000   0        0 eth0
192.168.0.0     *               255.255.255.0   U     2      0        0 wlan0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0

แต่นี่คือข่าวดี: การตั้งค่าที่อยู่ IP แบบคงที่/etc/network/interfacesซึ่งฉันเริ่มทำในขณะที่พยายามncทำงานแก้ไขปัญหา NFS ทั้งหมดของฉันและทำให้ฉันรัก NFS อีกครั้ง

การกำหนดค่าที่แน่นอนที่ฉันใช้ ( 192.168.1.1สำหรับเน็ตบุ๊กแรกแน่นอน) คือ:

auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0

ด้วยการตั้งค่าเหล่านั้นทั้งสองเน็ตบุ๊กจะสามารถ ping ifupกันโดยตรงหลังจากที่ถูกเด้งขึ้นโดยไม่ต้องแม้แต่

อย่างไรก็ตามฉันยังอยากเห็นncการปฏิบัติจริง ๆ ดังนั้นฉันหวังว่าจะมีคนช่วยฉันแก้ปัญหากระบวนการนี้

— ixtmixilix
แหล่งที่มา

หากทั้งสองไดเรกทอรีเป็นแบบโลคอลคุณควรใช้แบบเก่าแบบธรรมดา/bin/cpหรือไม่ใช้ NFS เลย

— Karlson

การรัน rsync กับไฟล์ที่เข้าถึงผ่าน NFS หมายความว่าเนื้อหาทั้งหมดของไฟล์ต้องคัดลอกผ่านเครือข่ายอย่างน้อยหนึ่งครั้ง คุณไม่จำเป็นต้องมีดีมอนเพื่อเรียกใช้ไคลเอ็นต์ / เซิร์ฟเวอร์ rsync - เพียงแค่เรียกใช้ผ่าน ssh (ในทางทฤษฎีมีความเป็นไปได้ที่จะเรียกใช้รีโมทปลายทางผ่าน telnet / rsh - แต่ค่อนข้างโง่ที่จะเรียกใช้บริการดังกล่าวในทางปฏิบัติ - ssh ไม่ได้เพิ่มค่าใช้จ่ายจำนวนมาก)

— symcbean

NFSv2 ค่อนข้างเก่า คุณใช้ระบบปฏิบัติการอะไร?

— นิลส์

Debian ล่าสุดและ Ubuntu ล่าสุดตามลำดับ ฉันได้รับคำสั่งทั้งหมด (รวมถึงnfsvers=2) จากบทช่วยสอนนี้ ( michaelminn.com/linux/home_network )

— ixtmixilix

ในความเป็นจริง ssh เพิ่มค่าใช้จ่ายจำนวนมากสวย crypto ไม่ถูก ด้วยความเร็วอินเทอร์เน็ตปกติไม่สำคัญ แต่ผ่าน LAN (หรือการเชื่อมต่อข้ามโดยตรงในกรณีนี้) คุณอาจสังเกตเห็น มากกว่ากิกะบิตยกเว้นเครื่องที่เร็วที่สุด (หรือเครื่องที่มีคำแนะนำ AES-NI หากใช้ SSH) ฉันค่อนข้างแน่ใจว่ามันจะเห็นได้ชัดเจน

— Derobert

คำตอบ:

วิธีที่รวดเร็ว

เร็วที่สุดวิธีการถ่ายโอนไฟล์ผ่านระบบ LAN มีแนวโน้มที่จะไม่ rsync เว้นแต่มีการเปลี่ยนแปลงเล็กน้อย rsync ใช้เวลาพอสมควรในการทำ checksums การคำนวณความแตกต่าง ฯลฯ หากคุณรู้ว่าคุณกำลังจะถ่ายโอนข้อมูลส่วนใหญ่อยู่ดีเพียงแค่ทำสิ่งนี้ (หมายเหตุ: มีการใช้งานหลายอย่างnetcatตรวจสอบคู่มือสำหรับ ตัวเลือกที่ถูกต้องโดยเฉพาะอย่างยิ่งคุณอาจไม่ต้องการ-p):

user@dest:/target$ nc -q 1 -l -p 1234 | tar xv

user@source:/source$ tar cv . | nc -q 1 dest-ip 1234

ที่ใช้ netcat ( nc) เพื่อส่ง tar ผ่านการเชื่อมต่อ TCP แบบดิบบนพอร์ต 1234 ไม่มีการเข้ารหัสการตรวจสอบความถูกต้อง ฯลฯ ดังนั้นจึงรวดเร็วมาก หากการเชื่อมต่อไขว้ของคุณทำงานที่กิกะบิตหรือน้อยกว่าคุณจะตรึงเครือข่าย หากมีมากกว่านั้นคุณจะตรึงดิสก์ (ยกเว้นว่าคุณมีอาร์เรย์หน่วยเก็บข้อมูลหรือดิสก์แบบเร็ว) การตั้งvค่าสถานะเพื่อ tar ทำให้มันพิมพ์ชื่อไฟล์ตามที่ไป (โหมด verbose) ด้วยไฟล์ขนาดใหญ่มันไม่มีค่าใช้จ่ายเลย หากคุณกำลังทำไฟล์ขนาดเล็กจำนวนมากคุณจะต้องปิดการใช้งาน นอกจากนี้คุณสามารถแทรกสิ่งที่ต้องการpvเข้าไปในไปป์ไลน์เพื่อรับตัวบ่งชี้ความคืบหน้า:

user@dest:/target$ nc -q 1 -l -p 1234 | pv -pterb -s 100G | tar xv

คุณสามารถแทรกสิ่งอื่น ๆ ได้เช่นกันgzip -1(และเพิ่มการzตั้งค่าสถานะที่จุดรับ - การzตั้งค่าที่จุดสิ้นสุดการส่งจะใช้ระดับการบีบอัดที่สูงกว่า 1 เว้นแต่ว่าคุณจะตั้งค่าตัวแปรสภาพแวดล้อม GZIP) แม้ว่า gzip จะช้าลงจริงเว้นแต่ข้อมูลของคุณจะถูกบีบอัด

หากคุณต้องการ rsync

หากคุณถ่ายโอนข้อมูลเพียงเล็กน้อยเท่านั้นที่มีการเปลี่ยนแปลง rsync อาจเร็วขึ้น คุณอาจต้องการดูตัวเลือก-W/ --whole-fileเช่นเดียวกับเครือข่ายที่รวดเร็วมาก (เช่น cross-connect) ที่สามารถเร็วขึ้น

วิธีที่ง่ายที่สุดในการเรียกใช้ rsync คือ over ssh คุณจะต้องการทดสอบกับ ssh ciphers เพื่อดูว่าเร็วที่สุดมันจะเป็น AES, ChaCha20 หรือ Blowfish (แม้ว่าจะมีข้อกังวลด้านความปลอดภัยเกี่ยวกับขนาดบล็อก 64 บิตของ Blowfish) ขึ้นอยู่กับว่าชิปของคุณมี AES ของ Intel หรือไม่ คำแนะนำ -NI (และ OpenSSL ของคุณใช้งาน) ใน ssh ใหม่ที่เพียงพอ rsync-over-ssh จะเป็นดังนี้:

user@source:~$ rsync -e 'ssh -c aes128-gcm@openssh.com' -avP /source/ user@dest-ip:/target

สำหรับเก่า SSH / sshd ลองaes128-ctrหรือในสถานที่ของaes128-cbcaes128-gcm@openssh.com

ChaCha20 จะเป็นchacha20-poly1305@openssh.com(ยังต้องการ ssh ใหม่พอ / sshd) และปักเป้าจะปักเป้า -cbc OpenSSH ไม่อนุญาตให้เรียกใช้โดยไม่มีรหัส คุณสามารถในการใช้หลักสูตรแล้วแต่จำนวนใดตัวเลือก rsync -avPที่คุณต้องการในสถานที่ของ และแน่นอนคุณสามารถไปในทิศทางอื่นและเรียกใช้ rsync จากเครื่องปลายทาง (ดึง) แทนเครื่องต้นทาง (พุช)

ทำให้ rsync เร็วขึ้น

หากคุณใช้ rsync daemon คุณสามารถกำจัด crypto overhead ขั้นแรกคุณจะต้องสร้างไฟล์การกำหนดค่า daemon ( /etc/rsyncd.conf) ตัวอย่างเช่นบนเครื่องต้นทาง (อ่านรายละเอียด rsyncd.conf manpage):

[big-archive]
    path = /source
    read only = yes
    uid = someuser
    gid = somegroup

จากนั้นบนเครื่องปลายทางคุณจะเรียกใช้:

user@dest:~$ rsync -avP source-ip::big-archive/ /target

คุณสามารถทำสิ่งนี้ด้วยวิธีอื่นเช่นกัน (แต่แน่นอนว่าคุณจะต้องตั้งค่าการอ่านเป็นไม่เท่านั้น) มีตัวเลือกสำหรับการรับรองความถูกต้อง ฯลฯ ตรวจสอบ manpage เพื่อดูรายละเอียด

— derobert
แหล่งที่มา

นี่คือคำตอบที่ยอดเยี่ยม อีกอันหนึ่งก็ยอดเยี่ยมเช่นกัน ไม่มีคำตอบที่ยอมรับได้เพียงเพราะผู้ถามไม่สามารถเลือกระหว่างพวกเขาได้หรือไม่?

— sudo

วิธีการที่แข็งแกร่งเป็นnetcatอย่างไร หากเครือข่ายลดลงแพ็คเก็ตดูเหมือนว่ามันจะสูญเสียบางส่วนของไฟล์แบบสุ่ม

— sudo

@sudo กำลังใช้ TCP ซึ่งจะส่งสัญญาณซ้ำตามที่ต้องการ ดังนั้นมันควรจะดีกับการสูญหายของแพ็กเก็ตความเสียหายแบบสุ่ม (เท่าที่ TCP และ Ethernet จะตรวจจับ) และอื่น ๆ แน่นอนว่ามันไม่ปลอดภัยจากการโจมตีเช่นการขุดอุโมงค์เหนือ ssh

— Derobert

@sudo คุณสามารถทำมันทั้งหมดในครั้งเดียวแทรกteeคำสั่งบางอย่างลงในไพพ์ทั้งสองด้านเพื่อคำนวณ checksums

— Derobert

@TheStoryCoder จุดในtarส่วนบอกให้ทำไดเรกทอรีปัจจุบัน นั่นไม่ใช่ส่วนหนึ่งของncคำสั่ง tar ถูกใช้เพื่อสร้างไฟล์เก็บถาวร tar ซึ่งถูกไพพ์ไปยัง netcat (และอีกด้านหนึ่ง netcat กำลังถูกไพพ์ใน tar เพื่อแยกไฟล์เก็บถาวร) ฉันเกรงว่าความคิดเห็นจะไม่เพียงพอที่จะอธิบายไปป์ไลน์ แต่หวังว่าจะเพียงพอสำหรับคุณในการเริ่มต้น ...

— derobert

อย่างไร? หรือ TL; DR

วิธีที่เร็วที่สุดที่ฉันได้พบคือการรวมกันของtar, และmbufferssh

เช่น:

tar zcf - bigfile.m4p | mbuffer -s 1K -m 512 | ssh otherhost "tar zxf -"

การใช้สิ่งนี้ฉันได้ประสบความสำเร็จในการถ่ายโอนเครือข่ายท้องถิ่นมากกว่า 950 Mb / s ในลิงค์ 1Gb แทนที่พา ธ ในแต่ละคำสั่ง tar เพื่อให้เหมาะสมกับสิ่งที่คุณกำลังถ่ายโอน

ทำไม? mbuffer!

คอขวดที่ใหญ่ที่สุดในการถ่ายโอนไฟล์ขนาดใหญ่ผ่านเครือข่ายก็คือดิสก์ I / O คำตอบที่เป็นหรือmbuffer bufferพวกเขาส่วนใหญ่คล้ายกัน แต่mbufferมีข้อได้เปรียบบางอย่าง ขนาดบัฟเฟอร์เริ่มต้นเป็น 2MB สำหรับmbufferและ 1MB bufferสำหรับ บัฟเฟอร์ที่ใหญ่กว่ามักจะไม่มีวันว่างเปล่า การเลือกขนาดบล็อกซึ่งเป็นขนาดที่เล็กที่สุดของขนาดบล็อกดั้งเดิมบนทั้งระบบไฟล์เป้าหมายและปลายทางจะให้ประสิทธิภาพที่ดีที่สุด

บัฟเฟอร์เป็นสิ่งที่ทำให้ทุกความแตกต่าง! ใช้มันหากคุณมีมัน! หากคุณไม่ได้รับมัน! การใช้(m}?bufferสิ่งใด ๆ ย่อมดีกว่าสิ่งใด มันเกือบจะเป็นยาครอบจักรวาลสำหรับการถ่ายโอนไฟล์เครือข่ายที่ช้า

หากคุณถ่ายโอนไฟล์หลายไฟล์tarให้ใช้"ก้อน" เข้าด้วยกันในสตรีมข้อมูล หากเป็นไฟล์เดียวคุณสามารถใช้catหรือเปลี่ยนเส้นทาง I / O ค่าใช้จ่ายของtarvs. catไม่มีนัยสำคัญทางสถิติดังนั้นฉันมักจะใช้tar(หรือzfs -sendที่ฉันสามารถทำได้) เว้นแต่ว่ามันจะเป็นtarballแล้ว ไม่มีของเหล่านี้มีการประกันเพื่อให้คุณเมตาดาต้า (และโดยเฉพาะอย่างยิ่งcatจะไม่ได้) หากคุณต้องการข้อมูลเมตาฉันจะปล่อยให้มันเป็นแบบฝึกหัดให้คุณ

ในที่สุดการใช้sshกลไกการขนส่งก็มีความปลอดภัยและมีค่าใช้จ่ายน้อยมาก อีกครั้งค่าใช้จ่ายของsshvs. ncไม่มีนัยสำคัญทางสถิติ

— bahamat
แหล่งที่มา

openssl speedบน i7-3770 ให้ ~ 126–146 MB / วินาทีสำหรับปักเป้า CBC และ ~ 138–157 MB / วินาทีสำหรับ AES CBC (ชิปนี้มีคำแนะนำ AES-NI) จากนั้น ~ 200–300 MB / วินาทีสำหรับ sha256 ดังนั้นมันสามารถกด 1 กิกะบิตแทบไม่ได้เลย ด้วย OpenSSH 6.1+ คุณสามารถใช้ AES GCM ซึ่งสามารถทำได้ในอัตราที่ทำให้ไม่เห็น (370–1320 MB / วินาทีขึ้นอยู่กับขนาดของข้อความ) ดังนั้นฉันคิดว่ามันเป็นความจริงเพียงอย่างเดียวที่ OpenSSH มีค่าใช้จ่ายเล็กน้อยหากคุณใช้ 6.1+ บนชิปที่มี AES-NI และใช้ AES-GCM

— Derobert

ใช่ฉันเปลี่ยนไปเป็น 6.1+ แทน 6.2+ ในนาทีสุดท้ายโดยตรวจสอบใหม่อย่างรวดเร็ว แน่นอนว่ามันเป็นความผิดพลาดมันมีการเปลี่ยนแปลงตั้งแต่ 6.1 ดังนั้น OpenSSH 6.2+ จึงเป็นรุ่นที่ถูกต้อง และจะไม่ให้ฉันแก้ไขความคิดเห็นอีกต่อไป ความคิดเห็นที่เก่ากว่า 5 นาทีจะต้องไม่ถูกต้อง แน่นอนถ้าน้อยกว่า OpenSSH 6.4 ให้ดูopenssh.com/txt/gcmrekey.advหากไม่มีโปรแกรมปะแก้มีข้อบกพร่องที่เป็นประโยชน์ในการใช้งาน AES-GCM ของ OpenSSH

— Derobert

ค่าใช้จ่ายสำหรับssh(หรือ rsync บน ssh) นั้นสำคัญมากๆ ฉันมี NAS ที่ใช้ Intel Atom CPU การเข้ารหัส SSH จะเปลี่ยนความเร็วในการถ่ายโอน ฉันได้รับอย่างต่อเนื่อง <400 Mbit / วินาทีสำหรับ RSA การเอาชนะ RC4 ด้วยตนเองทำให้ฉัน ~ 600 Mbits / วินาทีและถ้าฉันใช้ rsync เป็น daemon มันจะทำงานที่ลิงค์ความเร็วดั้งเดิม (> 900 MBit / วินาทีบนกิกะบิต การเชื่อมต่อ)

— ชื่อปลอม

ในขณะที่มันเป็นจริงที่สำหรับหลาย ๆ สถานการณ์การขนส่งไม่สำคัญมันเป็นสิ่งสำคัญอย่างยิ่งที่จะต้องพิจารณาโดยเฉพาะอย่างยิ่งถ้าคุณไม่ได้ทำงานบนฮาร์ดแวร์ระดับสูงมาก ในกรณีของฉัน Atom (มันคือ D525, dual core 1.8 Ghz) สร้างขึ้นมาเพื่อ NAS ที่ดีพร้อมด้วยความเร็วมากมายสำหรับ SMB แต่การเข้ารหัสนั้นฆ่ามันอย่างแน่นอน

— ชื่อปลอม

ฉันได้รับข้อผิดพลาดร้ายแรงเนื่องจากการแก้ไขของ mbuffer: 'mbuffer: ร้ายแรง: หน่วยความจำทั้งหมดจะต้องมีขนาดใหญ่กว่าขนาดบล็อก \ n สิ้นสุดแล้ว' เพื่อแก้ไขให้ถูกต้องฉันสงสัยว่าควรอ่านบางอย่างเช่น 'mbuffer -s 1K -m 512M' ที่มีสัญลักษณ์ 'M' สุดท้ายสำหรับ MByte (ที่มา: man mbuffer)

— Peter Lustig

คุณไม่จำเป็นต้องใช้ TCP AoE เป็นการใช้งาน ATA ผ่านอีเธอร์เน็ตเนื่องจากเลเยอร์ 2 เป็นวิธีลดค่าใช้จ่ายที่ต่ำกว่าโดยไม่มีความรู้เกี่ยวกับสแต็ก TCP / IP มันจะช่วยให้คุณถ่ายโอนได้เร็วที่สุดด้วยค่าใช้จ่ายน้อยที่สุด ***

https://en.wikipedia.org/wiki/ATA_over_Ethernet

*** หากเครือข่ายเป็นคอขวดต้องแน่ใจว่าคุณกำลังส่งข้อมูลที่ถูกบีบอัด

— วิลเลียมดีน
แหล่งที่มา

ว้าวนั่นเป็นฮาร์ดคอร์! :) สงสัยว่ามีมาตรฐานใด ๆ ...

— rogerdpack