Cách nhanh nhất để gửi lượng dữ liệu khổng lồ giữa hai máy tính là gì? [đóng cửa]

Đây là một tình huống tôi thường xuyên gặp phải:

• Tôi có một máy chủ nguồn với ổ cứng 320 GB bên trong và 16GB ram ( thông số chính xác có sẵn ở đây , nhưng vì đây là vấn đề tôi thường xuyên gặp phải trên các máy khác, tôi thích câu trả lời hơn để làm việc Máy Linux "hợp lý")
• Tôi có một máy chủ dự phòng với vài terabyte dung lượng ổ cứng ( thông số kỹ thuật chính xác ở đây , xem phần từ chối ở trên)

Tôi muốn chuyển 320GB dữ liệu từ máy chủ nguồn sang máy chủ đích (cụ thể là dữ liệu từ /dev/sda).

1. Hai máy tính nằm cạnh nhau về mặt vật lý, vì vậy tôi có thể chạy dây cáp giữa chúng.
2. Tôi đang sử dụng mạng LAN và tôi đang sử dụng bộ định tuyến mới , điều đó có nghĩa là tốc độ mạng của tôi sẽ "lý tưởng" là 1000Mbit, phải không?
3. Bảo mật không phải là một vấn đề. Tôi đang sử dụng mạng cục bộ và tôi tin tưởng tất cả các máy trên mạng, bao gồm cả bộ định tuyến.
4. (tùy chọn) Tôi không nhất thiết cần phải kiểm tra dữ liệu đã ký, nhưng kiểm tra lỗi cơ bản (chẳng hạn như các gói bị rơi hoặc ổ đĩa không thể đọc được) nên được phát hiện thay vì chỉ biến mất trong đầu ra.

Tôi đã tìm kiếm câu hỏi này trực tuyến, và đã thử nghiệm một số lệnh. Thứ xuất hiện thường xuyên nhất là đây:

ssh user@192.168.1.100 'dd bs=16M if=/dev/sda | gzip' > backup_sda.gz

Lệnh này đã được chứng minh là quá chậm (nó chạy trong một giờ, chỉ nhận được khoảng 80 GB thông qua dữ liệu). Mất khoảng 1 phút 22 giây cho gói thử nghiệm 1GB và kết thúc là nhanh gấp đôi khi không được nén. Các kết quả cũng có thể bị sai lệch bởi thực tế là tệp được truyền ít hơn dung lượng RAM trên hệ thống nguồn.

Hơn nữa (và điều này đã được thử nghiệm trên các mẫu thử nghiệm 1GB), tôi gặp vấn đề nếu tôi sử dụng gziplệnh và dd; tệp kết quả có một tổng kiểm tra khác nhau khi được trích xuất trên mục tiêu, hơn là nếu nó được dẫn trực tiếp. Tôi vẫn đang cố gắng tìm hiểu tại sao điều này xảy ra.

Vì các máy chủ nằm cạnh nhau và bạn đã đề cập trong các nhận xét mà bạn có quyền truy cập vật lý vào chúng, cách nhanh nhất là lấy ổ cứng ra khỏi máy tính đầu tiên, đặt nó vào máy tính thứ hai và chuyển các tệp qua kết nối SATA.

netcat là tuyệt vời cho các tình huống như thế này, nơi bảo mật không phải là một vấn đề:

# on destination machine, create listener on port 9999
nc -l 9999 > /path/to/outfile

# on source machine, send to destination:9999
nc destination_host_or_ip 9999 < /dev/sda
# or dd if=/dev/sda | nc destination_host_or_ip 9999

Lưu ý, nếu bạn đang sử dụng ddtừ GNU coreutils, bạn có thể gửi SIGUSR1đến quy trình và nó sẽ phát ra tiến trình tới thiết bị lỗi chuẩn. Đối với BSD dd, sử dụng SIGINFO.

pv thậm chí còn hữu ích hơn trong báo cáo tiến trình trong quá trình sao chép:

# on destination
nc -l 9999 | pv > /path/to/outfile

# on source
pv /dev/sda | nc destination_host_or_ip 9999
# or dd if=/dev/sda | pv | nc destination_host_or_ip 9999

1. Đừng sử dụng nhanh chóng nén.

   • Bất kể phương tiện truyền tải nào của bạn - đặc biệt là cho mạng hoặc usb - bạn sẽ làm việc với các cụm dữ liệu để đọc, lưu trữ và ghi và những thứ này sẽ không chính xác đồng bộ hóa.
   • Bên cạnh phần sụn đĩa, bộ đệm đĩa và bộ đệm kernel / ram, nếu bạn cũng có thể sử dụng CPU của hệ thống theo một cách nào đó để tập trung lượng dữ liệu trao đổi trên mỗi cụm thì bạn nên làm như vậy .
   • Bất kỳ thuật toán nén nào cũng sẽ tự động xử lý các đầu vào thưa thớt càng nhanh càng tốt, nhưng có rất ít thuật toán sẽ xử lý phần còn lại ở thông lượng mạng.
   • lz4 là lựa chọn tốt nhất của bạn ở đây:

     LZ4 là một thuật toán nén không mất dữ liệu rất nhanh, cung cấp tốc độ nén với tốc độ 400 MB / s trên mỗi lõi, có thể mở rộng với CPU đa lõi. Nó cũng có bộ giải mã cực nhanh, tốc độ nhiều GB / giây trên mỗi lõi, thường đạt đến giới hạn tốc độ RAM trên các hệ thống đa lõi.

2. Tốt nhất là không cần thiết tìm kiếm.

   • Điều này có thể khó đánh giá.

   • Nếu có nhiều không gian trống trên thiết bị mà bạn sao chép và thiết bị gần đây không bị xóa, nhưng tất cả (các) hệ thống tệp nguồn nên được sao chép, thì có lẽ bạn nên làm trước tiên cái gì đó như:

     </dev/zero tee >empty empty1 empty2; sync; rm empty*

   • Nhưng điều đó phụ thuộc vào mức độ bạn nên đọc nguồn. Thông thường nên đọc thiết bị từ đầu đến cuối từ /dev/some_disktệp thiết bị của nó , bởi vì đọc ở cấp hệ thống tệp thường sẽ liên quan đến việc tìm kiếm qua lại và xung quanh đĩa không tuần tự. Và vì vậy, lệnh đọc của bạn phải giống như:

     </dev/source_device lz4 | ...

   • Tuy nhiên, nếu hệ thống tệp nguồn của bạn không được chuyển toàn bộ, thì việc đọc ở cấp hệ thống tệp là không thể tránh khỏi, và vì vậy bạn nên kết hợp nội dung đầu vào của mình thành một luồng. paxnói chung là giải pháp tốt nhất và đơn giản nhất trong trường hợp đó, nhưng bạn cũng có thể cân nhắc mksquashfsnhư vậy.

     pax -r /source/tree[12] | lz4 | ...
     mksquashfs /source/tree[12] /dev/fd/1 -comp lz4 | ...

3. Đừng không mã hóa với ssh.

   • Việc thêm chi phí mã hóa vào một phương tiện đáng tin cậy là không cần thiết và có thể gây bất lợi nghiêm trọng cho tốc độ chuyển giao bền vững trong đó dữ liệu đọc cần đọc hai lần .
   • Các PRNG cần các dữ liệu đọc, hoặc ít nhất là một số của nó, để duy trì tính ngẫu nhiên.
   • Và tất nhiên bạn cần phải chuyển dữ liệu là tốt.
   • Bạn cũng cần chuyển chính chi phí mã hóa - có nghĩa là nhiều công việc hơn với ít dữ liệu được truyền hơn mỗi lần phát .

   • Và vì vậy, thay vào đó, bạn nên sử dụng netcat( hoặc, như tôi thích, nmapkhả năng cao hơn của dự ánncat ) cho một bản sao mạng đơn giản, như đã được đề xuất ở nơi khác:

     ###  on tgt machine...
     nc -l 9999 > out.lz4
     ###  then on src machine...
     ... lz4 | nc tgt.local 9999

Có một số hạn chế có thể làm hạn chế tốc độ truyền.

1. Có chi phí mạng cố hữu trên đường ống 1Gbps. Thông thường, điều này làm giảm thông lượng THỰC TẾ xuống 900Mbps hoặc ít hơn. Sau đó, bạn phải nhớ rằng đây là lưu lượng truy cập hai chiều và bạn sẽ mong đợi giảm đáng kể dưới 900Mbps.

2. Mặc dù bạn đang sử dụng "bộ định tuyến mới", bạn có chắc chắn rằng bộ định tuyến hỗ trợ 1Gbps không? Không phải tất cả các bộ định tuyến mới đều hỗ trợ 1Gbps. Ngoài ra, trừ khi nó là một bộ định tuyến cấp doanh nghiệp, bạn có thể sẽ mất băng thông truyền bổ sung cho bộ định tuyến không hiệu quả. Mặc dù dựa trên những gì tôi tìm thấy bên dưới, có vẻ như bạn đang nhận được trên 100Mbps.

3. Có thể có tắc nghẽn mạng từ các thiết bị khác chia sẻ mạng của bạn. Bạn đã thử sử dụng cáp gắn trực tiếp như bạn nói bạn có thể làm chưa?

4. Lượng IO đĩa của bạn đang sử dụng là bao nhiêu? Có khả năng, bạn đang bị giới hạn, không phải bởi mạng, mà bởi ổ đĩa. Hầu hết các ổ cứng 7200 vòng / phút sẽ chỉ nhận được khoảng 40 MB / s. Bạn có đang sử dụng đột kích không? Bạn đang sử dụng SSD? Bạn đang sử dụng gì ở đầu xa?

Tôi đề nghị sử dụng rsync nếu điều này dự kiến ​​sẽ được chạy lại để sao lưu. Bạn cũng có thể scp, ftp (s) hoặc http bằng cách sử dụng trình tải xuống như filezilla ở đầu bên kia vì nó sẽ song song hóa các kết nối ssh / http / https / ftp. Điều này có thể tăng băng thông vì các giải pháp khác nằm trên một đường ống. Một ống / luồng đơn vẫn bị giới hạn bởi thực tế là nó là luồng đơn, điều đó có nghĩa là nó thậm chí có thể bị ràng buộc CPU.

Với rsync, bạn lấy ra một lượng lớn độ phức tạp của giải pháp cũng như cho phép nén, bảo toàn quyền và cho phép chuyển một phần. Có một số lý do khác, nhưng nó thường là phương pháp sao lưu ưa thích (hoặc chạy các hệ thống sao lưu) của các doanh nghiệp lớn. Commvault thực sự sử dụng rsync bên dưới phần mềm của họ làm cơ chế phân phối để sao lưu.

Dựa trên ví dụ 80GB / h đã cho của bạn, bạn sẽ nhận được khoảng 177Mbps (22.2MB / s). Tôi cảm thấy bạn có thể dễ dàng nhân đôi điều này với rsync trên một dòng ethernet chuyên dụng giữa hai hộp vì tôi đã quản lý để có được điều này trong các thử nghiệm của riêng tôi với rsync qua gigabit.

Chúng tôi đối phó với điều này thường xuyên.

Hai phương pháp chính chúng ta có xu hướng sử dụng là:

1. SATA / eSATA / sneakernet
2. Gắn kết NFS trực tiếp, sau đó cục bộ cphoặcrsync

Đầu tiên là tùy thuộc vào việc ổ đĩa có thể được di dời vật lý hay không. Đây không phải là luôn luôn như vậy.

Thứ hai hoạt động tốt đáng ngạc nhiên. Nói chung, chúng tôi tối đa hóa kết nối 1gbps khá dễ dàng với các kết nối NFS trực tiếp. Bạn sẽ không nhận được bất cứ nơi nào gần với điều này với scp, dd qua ssh hoặc bất cứ điều gì tương tự (bạn sẽ thường nhận được tốc độ tối đa đáng ngờ gần 100mpbs). Ngay cả trên các bộ xử lý đa lõi rất nhanh, bạn sẽ gặp phải một nút cổ chai về thông lượng tiền điện tử tối đa của một trong số các lõi chậm nhất trong hai máy, tốc độ chậm so với cp hoặc rsync đầy đủ trên một mạng không được mã hóa. Đôi khi bạn sẽ đánh một bức tường IOPS cho một thời gian ngắn và bị mắc kẹt vào khoảng ~ 53MB / s thay vì các điển hình hơn ~ 110MB / s, nhưng đó là thường ngắn sống trừ khi nguồn hoặc đích là thực sựmột ổ đĩa duy nhất, sau đó bạn có thể sẽ bị giới hạn bởi tốc độ duy trì của chính ổ đĩa (nó đủ thay đổi vì những lý do ngẫu nhiên mà bạn sẽ không biết cho đến khi bạn thực sự thử nó) - meh.

NFS có thể hơi khó chịu khi thiết lập nếu trên một bản phân phối không quen thuộc, nhưng nói chung, đó là cách nhanh nhất để lấp đầy các đường ống một cách đầy đủ nhất có thể. Lần cuối cùng tôi thực hiện điều này trên 10gb / giây, tôi chưa bao giờ thực sự phát hiện ra nếu nó kết nối tối đa, bởi vì việc chuyển tiền đã kết thúc trước khi tôi quay lại lấy một ít cà phê - vì vậy có thể có một số giới hạn tự nhiên mà bạn đạt được ở đó. Nếu bạn có một vài thiết bị mạng giữa nguồn và đích, bạn có thể gặp một số chậm trễ hoặc trục trặc nhỏ từ hiệu ứng trượt mạng, nhưng nói chung, điều này sẽ hoạt động trên toàn văn phòng (thay đổi lưu lượng truy cập khác) hoặc từ một đầu của trung tâm dữ liệu khác (trừ khi bạn có một số loại lọc / kiểm tra xảy ra trong nội bộ, trong trường hợp đó tất cả các cược đã tắt ).

BIÊN TẬP

Tôi nhận thấy một số trò chuyện về nén ... không nén kết nối. Nó sẽ làm chậm bạn giống như cách một lớp tiền điện tử sẽ làm. Nút cổ chai sẽ luôn là một lõi nếu bạn nén kết nối (và thậm chí bạn sẽ không được sử dụng đặc biệt tốt cho xe buýt của lõi đó). Điều chậm nhất bạn có thể làm trong tình huống của mình là sử dụng kênh được mã hóa, nén giữa hai máy tính ngồi cạnh nhau trên kết nối 1gbps trở lên.

CHỨNG MINH TRONG TƯƠNG LAI

Lời khuyên này là vào giữa năm 2015. Điều này gần như chắc chắn sẽ không xảy ra trong quá nhiều năm nữa. Vì vậy, hãy dùng mọi thứ với một hạt muối và nếu bạn thường xuyên phải đối mặt với nhiệm vụ này, hãy thử nhiều phương pháp khác nhau trên tải thực tế thay vì tưởng tượng bạn sẽ đạt được bất cứ điều gì gần với tối ưu lý thuyết, hoặc thậm chí quan sát tỷ lệ thông lượng nén / tiền điện tử điển hình cho những thứ như web lưu lượng truy cập, phần lớn là văn bản (protip: chuyển số lượng lớn thường bao gồm chủ yếu là hình ảnh, âm thanh, video, tệp cơ sở dữ liệu, mã nhị phân, định dạng tệp văn phòng, vv đã được néntheo cách riêng của họ và được hưởng lợi rất ít từ việc chạy qua một thói quen nén khác, kích thước khối nén gần như được đảm bảo không phù hợp với dữ liệu nhị phân đã nén của bạn ...).

Tôi tưởng tượng rằng trong các khái niệm tương lai như SCTP sẽ được đưa đến một nơi thú vị hơn, nơi các kết nối ngoại quan (hoặc kết nối sợi quang được liên kết nội bộ) là điển hình và mỗi kênh có thể nhận được một luồng độc lập với các kênh khác và mỗi kênh luồng có thể được nén / mã hóa song song, v.v ... Điều đó thật tuyệt vời! Nhưng đó không phải là trường hợp ngày hôm nay năm 2015, và mặc dù tưởng tượng và lý thuyết hóa là tốt, hầu hết chúng ta không có các cụm lưu trữ tùy chỉnh chạy trong dữ liệu cung cấp buồng lạnh trực tiếp đến các bộ phận của Blue Gene / Q tạo ra câu trả lời cho Watson. Đó không phải là thực tế. Chúng tôi cũng không có thời gian để phân tích toàn bộ trọng tải dữ liệu của mình để tìm hiểu xem liệu nén có phải là ý tưởng tốt hay không - việc chuyển giao sẽ kết thúc trước khi chúng tôi hoàn thành phân tích,

Nhưng...

Thời gian thay đổi và khuyến nghị của tôi chống lại nén và mã hóa sẽ không đứng vững. Tôi thực sự rất thích lời khuyên này sẽ được lật lại trong trường hợp điển hình rất sớm. Nó sẽ làm cho cuộc sống của tôi dễ dàng hơn.

Một công cụ tiện lợi mà tôi đã sử dụng trong quá khứ là bbcp. Như đã thấy ở đây: https://www.slac.stanford.edu/~abh/bbcp/ .

Xem thêm http://pcbunn.cithep.caltech.edu/bbcp/USE_bbcp.htm

Tôi đã có tốc độ truyền rất nhanh với công cụ này.

Nếu bạn nhận được một lượt đi đầu tiên bằng cách nào đó (qua dây / sneakernet / bất cứ điều gì), bạn có thể xem xét rsyncvới một số tùy chọn có thể tăng tốc đáng kể các lần chuyển tiếp theo. Một cách rất tốt để đi là:

rsync -varzP sourceFiles destination

Các tùy chọn là: dài dòng, chế độ lưu trữ, đệ quy, nén, Tiến trình từng phần

Đã thêm vào sự nhấn mạnh của poster gốc trong các bình luận cho câu trả lời của zackse, mặc dù tôi không chắc nó là nhanh nhất trong các trường hợp điển hình.

bashcó một cú pháp đặc biệt chuyển hướng:
Đối với đầu ra:      > /dev/tcp/ IP  / cổng
Đối với đầu vào:       < /dev/tcp/ IP  / cổng
IP ban be hoặc IP chấm thập phân hoặc một hostname; lệnh cấm cổng là số thập phân hoặc tên cổng từ /etc/services.

Không có /dev/tcp/thư mục thực tế . Đó là một cú pháp cú pháp đặc biệt ra lệnh bashtạo một ổ cắm TCP, kết nối nó với đích được chỉ định và sau đó thực hiện tương tự như chuyển hướng tệp thông thường (cụ thể là thay thế luồng tiêu chuẩn tương ứng bằng ổ cắm bằng dup2 (2)).

Do đó, người ta có thể truyền dữ liệu từ ddhoặc tartại máy nguồn trực tiếp qua TCP. Hoặc, ngược lại, để truyền dữ liệu đến tarhoặc một cái gì đó tương tự trực tiếp thông qua TCP. Trong mọi trường hợp, một netcat không cần thiết được loại bỏ.

Ghi chú về netcat

Có sự không nhất quán về cú pháp giữa netcat cổ điển và GNU netcat . Tôi sẽ sử dụng cú pháp cổ điển mà tôi đã quen. Thay thế -lpbằng -lcho netcat GNU.

Ngoài ra, tôi không chắc liệu GNU netcat có chấp nhận -qchuyển đổi hay không.

Truyền ảnh đĩa

(Dọc theo dòng câu trả lời của zackse.)
Về đích:

nc -lp 9999 >disk_image

Về nguồn:

dd if=/dev/sda >/dev/tcp/destination/9999
 

Tạo một kho lưu trữ tar.gz, với tar

Về đích:

nc -lp 9999 >backup.tgz

Về nguồn:

tar cz files or directories to be transferred >/dev/tcp/destination/9999

Thay thế .tgzbằng .tbzvà czvới cjđể có được một bzip2kho lưu trữ nén.

Chuyển với mở rộng ngay lập tức vào hệ thống tập tin

Ngoài ra với tar.
Về đích:

cd backups
tar x </dev/tcp/destination/9999

Về nguồn:

tar c files or directories to be transferred |nc -q 1 -lp 9999

Nó sẽ hoạt động mà không có -q 1, nhưng netcat sẽ bị kẹt khi dữ liệu kết thúc. Xem tar (1) để được giải thích về cú pháp và cảnh báo của tar. Nếu có nhiều tệp có độ dự phòng cao (entropy thấp), thì có thể thử nén (ví dụ czvà xzthay vì cvà x), nhưng nếu các tệp là điển hình và mạng đủ nhanh, nó sẽ chỉ làm chậm quá trình. Xem câu trả lời của mikeerv để biết chi tiết về nén.

Kiểu thay thế (cổng nghe)

Về đích:

cd backups
nc -lp 9999 |tar x

Về nguồn:

tar c files or directories to be transferred >/dev/tcp/destination/9999

Hãy thử các đề xuất liên quan đến các kết nối trực tiếp và tránh các giao thức được mã hóa như ssh. Sau đó, nếu bạn vẫn muốn tìm hiểu từng chút về hiệu suất, hãy đọc trang web này: https://fasterdata.es.net/host-tuning/linux/ để được tư vấn về cách tối ưu hóa các cửa sổ TCP của bạn.

tôi sẽ dùng kịch bản này tôi đã viết cần socatgói.

Trên máy nguồn:

tarnet -d wherefilesaretosend pass=none 12345 .

Trên máy đích:

tarnet -d wherefilesaretogo pass=none sourceip/12345

Nếu vbuf gói (Debian, Ubuntu) ở đó thì người gửi tệp sẽ hiển thị tiến trình dữ liệu. Người nhận tập tin sẽ hiển thị những tập tin được nhận. Tùy chọn pass = có thể được sử dụng khi dữ liệu có thể bị lộ (chậm hơn).

Biên tập:

Sử dụng -ntùy chọn để tắt tính năng nén, nếu CPU là cổ chai.

Nếu ngân sách không phải là mối quan tâm chính, bạn có thể thử kết nối các ổ đĩa với "đầu nối ổ đĩa" 12 lõi Intel Xeon E5. Trình kết nối này thường mạnh đến mức bạn thậm chí có thể chạy phần mềm máy chủ hiện tại của mình trên nó. Từ cả hai máy chủ!

Điều này có thể trông giống như một câu trả lời thú vị, nhưng bạn thực sự nên xem xét lý do tại sao bạn di chuyển dữ liệu giữa các máy chủ và nếu một cái lớn với bộ nhớ và lưu trữ được chia sẻ có thể có ý nghĩa hơn.

Không chắc chắn về thông số kỹ thuật hiện tại, nhưng việc truyền chậm có thể bị giới hạn bởi tốc độ đĩa chứ không phải mạng?

Nếu bạn chỉ quan tâm đến các bản sao lưu, và không phải là một byte cho bản sao byte của ổ cứng, thì tôi khuyên bạn nên sao lưu. http://backuppc.sourceforge.net/faq/BackupPC.html Hơi khó cài đặt nhưng nó chuyển rất nhanh.

Thời gian chuyển ban đầu của tôi cho khoảng 500G dữ liệu là khoảng 3 giờ. Sao lưu sau đó xảy ra trong khoảng 20 giây.

Nếu bạn không quan tâm đến các bản sao lưu, nhưng đang cố gắng đồng bộ hóa mọi thứ thì rsync hoặc unison sẽ phù hợp hơn với nhu cầu của bạn.

Một byte cho bản sao byte của đĩa cứng thường là một ý tưởng tồi tệ cho mục đích sao lưu (không tăng, không tiết kiệm dung lượng, không thể sử dụng ổ đĩa, bạn phải sao lưu "không gian trống" và bạn phải sao lưu rác (như tệp hoán đổi 16 G hoặc 200G lõi hoặc một số thứ khác). Sử dụng rsync (hoặc backuppc hoặc các loại khác), bạn có thể tạo "ảnh chụp nhanh" kịp thời để bạn có thể đi đến "hệ thống tệp của bạn trông như thế nào 30 phút trước" với rất ít chi phí

Điều đó nói rằng, nếu bạn thực sự muốn chuyển một byte cho bản sao byte thì vấn đề của bạn sẽ nằm ở việc chuyển chứ không phải trong việc lấy dữ liệu từ ổ đĩa. Với 400G RAM, việc truyền tệp 320G sẽ mất rất nhiều thời gian. Sử dụng các giao thức không được mã hóa là một tùy chọn, nhưng không có vấn đề gì, bạn sẽ phải ngồi đó và chờ trong vài giờ (qua mạng).

Bất kể chương trình nào, tôi thường thấy rằng các tệp "kéo" qua mạng nhanh hơn "đẩy". Nghĩa là, đăng nhập vào máy tính đích và thực hiện đọc nhanh hơn đăng nhập vào máy tính nguồn và thực hiện ghi.

Ngoài ra, nếu bạn định sử dụng ổ đĩa trung gian, hãy xem xét điều này: Lấy ổ đĩa ngoài (dưới dạng gói hoặc ổ riêng được cắm vào trạm nối) sử dụng eSATA thay vì USB. Sau đó, trên mỗi hai máy tính đều cài đặt thẻ có cổng eSATA hoặc nhận cáp bộ điều hợp đơn giản mang một trong các cổng SATA bên trong đến đầu nối eSATA bên ngoài. Sau đó cắm ổ đĩa vào máy tính nguồn, cấp nguồn cho ổ đĩa và đợi cho nó tự động gắn kết (bạn có thể lắp manaully, nhưng nếu bạn làm điều này nhiều lần, bạn cũng có thể đặt nó vào tệp fstab của mình). Sau đó sao chép; bạn sẽ ghi cùng tốc độ với ổ đĩa trong. Sau đó ngắt kết nối ổ đĩa, tắt nguồn, cắm vào máy tính khác, bật nguồn, chờ tự động gắn kết và đọc.

Tôi sẽ khuyên bạn nên xem xét việc hợp tác với NIC. Điều này liên quan đến việc sử dụng nhiều kết nối mạng chạy song song. Giả sử rằng bạn thực sự cần nhiều hơn 1Gb chuyển khoản và 10Gb là chi phí cấm, 2Gbs được cung cấp bởi nhóm hợp tác với nhau sẽ là một chi phí nhỏ và máy tính của bạn có thể đã có thêm cổng.

FWIW, tôi đã luôn sử dụng cái này:

tar -cpf - <source path> | ssh user@destserver "cd /; tar xf -"

Điều quan trọng về phương pháp này là nó sẽ duy trì quyền truy cập tệp / thư mục giữa các máy (giả sử có cùng một nhóm / người dùng tồn tại trên cả hai) (Ngoài ra tôi thường làm điều này để sao chép hình ảnh đĩa ảo vì tôi có thể sử dụng tham số -S để xử lý các tệp thưa thớt. )

Chỉ cần thử nghiệm điều này giữa hai máy chủ bận rộn và được quản lý ~ 14GB trong 216 giây (khoảng 64 MB / giây) - có thể sẽ làm tốt hơn giữa các máy chuyên dụng và / hoặc nén ... YMMV

$ date; tar -cpf - Installers | ssh elvis "cd /home/elvis/tst; tar xf -"; date
Wed Sep  9 15:23:37 EDT 2015
Wed Sep  9 15:27:13 EDT 2015

$ du -s Installers
14211072   Installers

Trừ khi bạn muốn thực hiện pháp y hệ thống tập tin, hãy sử dụng chương trình kết xuất / khôi phục cho hệ thống tập tin của bạn để tránh sao chép không gian trống mà FS không sử dụng. Tùy thuộc vào hệ thống tập tin bạn có, điều này thường sẽ bảo toàn tất cả siêu dữ liệu, bao gồm ctime. Tuy nhiên, số inode có thể thay đổi tùy thuộc vào hệ thống tập tin nào (xfs, ext4, ufs ...).

Mục tiêu khôi phục có thể là một tệp trên hệ thống đích.

Nếu bạn muốn có một hình ảnh toàn đĩa với bảng phân vùng, bạn có thể dd1M đầu tiên của đĩa để lấy bảng phân vùng / bộ nạp khởi động / công cụ, nhưng sau đó xfsdumplà các phân vùng.

Tôi không thể nói từ thông tin của bạn về loại hệ thống tập tin mà bạn thực sự có. Nếu đó là BSD ufs, thì tôi nghĩ rằng nó có chương trình kết xuất / khôi phục. Nếu đó là ZFS, IDK, có thể có một cái gì đó.

Nói chung, các đĩa sao chép toàn bộ xung quanh quá chậm đối với mọi thứ trừ các tình huống khôi phục. Bạn cũng không thể thực hiện sao lưu gia tăng theo cách đó.

Bạn cũng có thể thiết lập các hệ thống để có một bộ lưu trữ được chia sẻ!

Tôi đang xem xét rằng những cái này nằm cạnh nhau, và bạn có thể sẽ làm điều này một lần nữa & một lần nữa ....

Làm thế nào về một cáp chéo ethernet? Thay vì dựa vào tốc độ không dây, bạn giới hạn ở tốc độ có dây của NIC.

Đây là một câu hỏi tương tự với một số ví dụ về loại giải pháp đó.

Rõ ràng chỉ cần một cáp ethernet điển hình sẽ đủ ngày nay. Rõ ràng là NIC của bạn càng tốt thì việc chuyển tiền càng nhanh.

Tóm lại, nếu cần thiết lập mạng, thì chỉ nên giới hạn cài đặt IP tĩnh cho máy chủ và máy tính dự phòng của bạn bằng mặt nạ mạng con 255.255.255.0

Chúc may mắn!

Biên tập:

@Khstalloph đã chạm vào điều này trong câu trả lời của anh ấy

Một số người khuyên bạn nên bỏ qua ssh vì mã hóa sẽ làm bạn chậm lại. Các CPU hiện đại thực sự có thể đủ nhanh ở mức 1Gb, nhưng OpenSSH có vấn đề với việc triển khai cửa sổ bên trong của nó có thể làm bạn chậm lại đáng kể.

Nếu bạn muốn làm điều này với ssh, hãy xem HPN SSH . Nó giải quyết các vấn đề cửa sổ và thêm mã hóa đa luồng. Thật không may, bạn sẽ cần phải xây dựng lại ssh trên cả máy khách và máy chủ.

OK Tôi đã cố gắng trả lời câu hỏi này cho hai máy tính có "ống rất lớn" (10Gbe) "gần nhau".

Vấn đề bạn gặp phải ở đây là: hầu hết việc nén sẽ tắc nghẽn tại cpu, vì các đường ống quá lớn.

hiệu suất để chuyển tệp 10GB (kết nối mạng 6 Gb [linode], dữ liệu không nén được):

$  time bbcp 10G root@$dest_ip:/dev/null
0m16.5s 

iperf:

server: $ iperf3 -s -F /dev/null
client:
$ time iperf3 -c $dest_ip -F 10G -t 20 # -t needs to be greater than time to transfer complete file
0m13.44s
(30% cpu)

netcat (1.187 openbsd):

server: $ nc -l 1234 > /dev/null
client: $ time nc $dest_ip 1234 -q 0 < 10G 
0m13.311s
(58% cpu)

scp:

$ time /usr/local/bin/scp 10G root@$dest_ip:/dev/null
1m31.616s
scp with hpn ssh patch (scp -- hpn patch on client only, so not a good test possibly): 
1m32.707s

socat:

server:
$ socat -u TCP-LISTEN:9876,reuseaddr OPEN:/dev/null,creat,trunc
client:
$ time socat -u FILE:10G TCP:$dest_ip:9876
0m15.989s

Và hai hộp trên 10 Gbe, phiên bản cũ hơn một chút của netcat (CentOs 6.7), tệp 10GB:

nc: 0m18.706s (100% cpu, v1.84, no -q option
iperf3: 0m10.013s (100% cpu, but can go up to at least 20Gbe with 100% cpu so not sure it matters)
socat: 0m10.293s (88% cpu, possibly maxed out)

Vì vậy, trên một ví dụ, netcat sử dụng ít cpu hơn, trên socat khác, vì vậy YMMV.

Với netcat, nếu nó không có tùy chọn "-N -q 0", nó có thể chuyển các tệp bị cắt bớt, hãy cẩn thận ... các tùy chọn khác như "-w 10" cũng có thể dẫn đến các tệp bị cắt bớt.

Điều đang xảy ra trong hầu hết các trường hợp này là cpu đang được tối đa hóa chứ không phải mạng. scpđạt tối đa khoảng 230 MB / s, chốt một lõi với mức sử dụng 100%.

Iperf3 không may tạo các tập tin bị hỏng . Một số phiên bản của netcat dường như không chuyển toàn bộ tập tin, rất kỳ lạ. Đặc biệt là các phiên bản cũ hơn của nó.

Các câu thần chú khác nhau của "gzip as a pipe to netcat" hoặc "mbuffer" dường như cũng tối đa hóa cpu với gzip hoặc mbuffer, do đó không dẫn đến việc chuyển nhanh hơn với các ống lớn như vậy. lz4 có thể giúp đỡ. Ngoài ra, một số công cụ đường ống gzip mà tôi đã thử dẫn đến việc chuyển bị hỏng đối với các tệp rất lớn (> 4 GB), vì vậy hãy cẩn thận :)

Một điều khác có thể hoạt động đặc biệt đối với độ trễ cao hơn (?) Là điều chỉnh cài đặt tcp. Dưới đây là hướng dẫn đề cập đến các giá trị được đề xuất:

http://pcbunn.cithep.caltech.edu/bbcp/USE_bbcp.htm và https://fasterdata.es.net/host-tuning/linux/ (từ một câu trả lời khác) có thể là cài đặt IRQ: https://fasterdata.es .net / máy chủ điều chỉnh / điều chỉnh 100g /

đề xuất từ ​​linode, thêm vào /etc/sysctl.conf:

net.core.rmem_max = 268435456 
net.core.wmem_max = 268435456 
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.core.netdev_max_backlog = 250000
net.ipv4.tcp_no_metrics_save = 1
net.core.default_qdisc = fq 

Ngoài ra, họ muốn bạn chạy:

 /sbin/ifconfig eth0 txqueuelen 10000 

đáng để kiểm tra lại sau khi điều chỉnh để đảm bảo các thay đổi cũng không gây hại.

Cũng có thể đáng để điều chỉnh kích thước cửa sổ: https://iperf.fr/iperf-doc.php#tuningtcp

Với nén kết nối chậm (er) chắc chắn có thể giúp đỡ mặc dù. Nếu bạn có đường ống lớn, nén rất nhanh có thể giúp với dữ liệu dễ nén, bạn đã không thử.

Câu trả lời tiêu chuẩn cho "đồng bộ hóa ổ đĩa cứng" là rsync các tập tin, tránh việc truyền tải nếu có thể.

Một tùy chọn khác: sử dụng "scp song song" (bằng cách này hay cách khác), sau đó nó sẽ sử dụng nhiều lõi hơn ...