Apa cara tercepat untuk mengirim data dalam jumlah besar di antara dua komputer? [Tutup]

111

Ini adalah situasi yang sering saya alami:

  • Saya memiliki server sumber dengan 320GB hard-drive di dalamnya, dan 16GB ram ( spesifikasi tepat tersedia di sini , tetapi karena ini adalah masalah yang sering saya temui di mesin lain, saya lebih suka jawaban untuk bekerja pada setiap Mesin Linux "masuk akal")
  • Saya memiliki server cadangan dengan beberapa terabyte ruang hard-drive ( spesifikasi spesifik di sini , lihat penafian di atas)

Saya ingin mentransfer 320GB data dari server sumber ke server target (khususnya, data dari /dev/sda).

  1. Kedua komputer secara fisik bersebelahan, jadi saya bisa menjalankan kabel di antara mereka.
  2. Saya menggunakan LAN, dan saya menggunakan router baru-ish , yang berarti kecepatan jaringan saya "idealnya" adalah 1000Mbit, bukan?
  3. Keamanan bukan masalah. Saya di jaringan lokal, dan saya percaya semua mesin di jaringan, termasuk router.
  4. (opsional) Saya tidak perlu memerlukan checksum yang ditandatangani dari data, tetapi pemeriksaan kesalahan dasar (seperti paket yang jatuh, atau drive menjadi tidak dapat dibaca) harus dideteksi daripada menghilang begitu saja ke dalam output.

Saya mencari pertanyaan ini secara online, dan telah menguji beberapa perintah. Salah satu yang paling sering muncul adalah ini:

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

Perintah ini telah terbukti terlalu lambat (itu berjalan selama satu jam, hanya mendapat sekitar 80GB melalui data). Butuh sekitar 1 menit dan 22 detik untuk paket tes 1GB, dan akhirnya menjadi dua kali lebih cepat ketika tidak dikompresi. Hasil mungkin juga condong oleh fakta bahwa file yang ditransfer kurang dari jumlah RAM pada sistem sumber.

Selain itu (dan ini diuji pada potongan uji 1GB), saya mendapatkan masalah jika saya menggunakan gzipperintah dan dd; file yang dihasilkan memiliki checksum yang berbeda ketika diekstraksi pada target, daripada jika disalurkan secara langsung. Saya masih mencoba mencari tahu mengapa ini terjadi.

networking  backup  dd  file-transfer 
— IQAndreas
sumber
54
Jangan lupa sneakernet
— gwillie
4
Apakah Anda ingin mentransfer /dev/sdasebagai gambar atau hanya file. Mengapa rsync tidak ada pilihan? Sudah /dev/sdaterpasang saat Anda ddmengedit?
— Jodka Lemon
15
Data kinerja Anda (1GB / 80sec, 80GB / 1h) sangat cocok dengan apa yang seharusnya kita harapkan pada 100MBit. Periksa perangkat keras Anda. ... dan gerrit benar, 320GB mungkin besar, tetapi "sejumlah besar data" menimbulkan harapan yang salah.
— blafasel
8
"Jangan pernah meremehkan bandwidth kereta barang yang penuh dengan disk." .. Apakah Anda bertanya tentang throughput, latensi, atau campuran keduanya?
— keshlam
8
Seorang teman saya selalu berkata: "Jangan pernah meremehkan bandwidth tumpukan hard drive di truk".
— AMADANON Inc.

Jawaban:

139

Karena server secara fisik bersebelahan, dan Anda menyebutkan dalam komentar Anda memiliki akses fisik kepada mereka, cara tercepat adalah dengan mengeluarkan hard drive dari komputer pertama, letakkan di tempat kedua, dan transfer file melalui koneksi SATA.

— BlueRaja - Danny Pflughoeft
sumber
15
+1: Mentransfer melalui fisik tampaknya menjadi rute tercepat, bahkan jika itu berarti mendapatkan hard drive eksternal yang besar dari suatu tempat. Ini sekitar £ 40, dan Anda mungkin sudah menghabiskan banyak waktu,
— deworde
3
Saya sepenuhnya tidak setuju dengan ide ini jika seseorang mendapatkan kecepatan penuh di jaringan gigabit. Pengujian melalui NFS / SMB melalui sakelar Zyxel Gigabit antara microserver HP Gen 7, dan mesin Pentium G630 memberi saya transfer ~ 100MB / s. (Sampai saya meninggalkan tepi luar pelat drive.) Jadi saya pikir itu akan dilakukan secara realistis dalam waktu kurang dari 3 jam. Kecuali jika Anda menggunakan SSD / drive / penyimpanan berkinerja sangat tinggi, saya tidak berpikir 2 salinan dapat menghasilkan throughput 100MB / s, yang akan membutuhkan setiap operasi salinan menjadi 200MB / s hanya untuk mencapai titik impas.
— Phizes
3
@Figure: jelas Anda tidak menyalin ke sementara. Itu adalah ide buruk deword, bukan apa yang orang lain bicarakan. Titik menghubungkan drive sumber ke mesin target adalah pergi SATA-> SATA dengan dd(atau salinan pohon sistem file).
— Peter Cordes
10
"Jangan pernah meremehkan bandwidth truk yang penuh dengan hard drive. Satu neraka latensi sekalipun"
— Kevin
3
@ Kevin: ya, maksud saya adalah bahwa salinan langsung antara disk di komputer yang sama setidaknya secepat metode lain yang mungkin. Saya mengangkat nomor bandwidth kehidupan nyata untuk mengakui poin Phize bahwa pergi gigE adalah baik untuk drive lama OPs, tetapi hambatan untuk drive baru. (Satu kasus di mana kedua drive dalam satu komputer bukan pilihan terbaik adalah ketika memiliki komputer yang terpisah menggunakan RAM mereka untuk menyimpan metadata dari sumber dan dest adalah penting, misalnya untuk rsync dari milyaran file.)
— Peter Cordes
69

netcat sangat bagus untuk situasi seperti ini di mana keamanan tidak menjadi masalah:

# 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

Catatan, jika Anda menggunakan dddari GNU coreutils, Anda dapat mengirim SIGUSR1ke proses dan itu akan memancarkan kemajuan ke stderr. Untuk BSD dd, gunakan SIGINFO.

pv bahkan lebih membantu dalam melaporkan kemajuan selama salinan:

# 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
— Zackse
sumber
2
Untuk contoh kedua, apakah ddbahkan diperlukan, atau bisakah pv/ ncmemperlakukan dengan /dev/sdabaik sendiri? (Saya perhatikan beberapa perintah "muntah" ketika mencoba membaca file khusus seperti itu, atau file dengan 0x00byte)
— IQAndreas
5
@ user1794469 Akankah kompresi membantu? Saya pikir jaringannya tidak di mana hambatannya.
— IQAndreas
17
Jangan lupa bahwa di bashsatu dapat menggunakan > /dev/tcp/ IP  / pelabuhan dan < /dev/tcp/ IP  / pelabuhan pengalihan bukan pipa ke dan dari netcat masing-masing.
— Incnis Mrsi
5
Jawaban yang bagus. Gigabit Ethernet seringkali lebih cepat daripada kecepatan hard drive, jadi kompresi tidak berguna. Untuk mentransfer beberapa file, pertimbangkan tar cv sourcedir | pv | nc dest_host_or_ip 9999dan cd destdir ; nc -l 9999 | pv | tar xv. Banyak variasi yang mungkin, misalnya Anda ingin tetap .tar.gzpada sisi tujuan daripada salinan. Jika Anda menyalin direktori ke direktori, untuk keamanan ekstra Anda dapat melakukan rsync sesudahnya, misalnya dari dest rsync --inplace -avP user@192.168.1.100:/path/to/source/. /path/to/destination/.akan menjamin bahwa semua file memang salinan yang tepat.
— Stéphane Gourichon
3
Alih-alih menggunakan IPv4 Anda dapat mencapai throughput yang lebih baik dengan menggunakan IPv6 karena memiliki muatan yang lebih besar. Anda bahkan tidak mengkonfigurasinya, jika mesin-mesin tersebut mampu IPv6, mereka mungkin sudah memiliki alamat tautan-lokal IPv6
— David Costa
33

  1. Jangan gunakan kompresi cepat .

    • Apa pun media transfer Anda - terutama untuk jaringan atau usb - Anda akan bekerja dengan semburan data untuk dibaca, cache, dan ditulis, dan ini tidak akan persis sinkron.
    • Selain firmware disk, cache disk, dan cache kernel / ram, jika Anda juga dapat menggunakan CPU sistem dengan beberapa cara untuk memusatkan jumlah data yang dipertukarkan per burst maka Anda harus melakukannya .
    • Algoritma kompresi apa pun akan secara otomatis menangani input yang jarang berjalan secepat mungkin, tetapi ada sangat sedikit yang akan menangani sisanya pada throughput jaringan.
    • lz4 adalah pilihan terbaik Anda di sini:

      LZ4 adalah algoritma kompresi lossless yang sangat cepat, memberikan kecepatan kompresi pada 400 MB / s per inti, dapat diukur dengan multi-core CPU. Ini juga menampilkan decoder yang sangat cepat, dengan kecepatan dalam beberapa GB / s per core, biasanya mencapai batas kecepatan RAM pada sistem multi-core.

  2. Lebih disukai tidak usah mencari yang tidak perlu.

    • Ini bisa sulit untuk diukur.

    • Jika ada banyak ruang kosong pada perangkat dari mana Anda menyalin, dan perangkat belum baru-baru ini memusatkan perhatian, tetapi semua sistem file sumber (s) harus disalin, maka mungkin bernilai saat Anda pertama kali melakukan sesuatu seperti:

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

    • Tetapi itu tergantung pada level apa Anda seharusnya membaca sumbernya. Biasanya diinginkan untuk membaca perangkat dari awal hingga selesai dari /dev/some_diskfile perangkatnya, karena membaca pada level sistem file umumnya akan melibatkan pencarian bolak-balik dan di sekitar disk secara tidak berurutan. Dan jadi perintah baca Anda harus seperti:

      </dev/source_device lz4 | ...

    • Namun, jika sistem file sumber Anda tidak boleh ditransfer secara keseluruhan, maka membaca di tingkat sistem file tidak dapat dihindari, dan karenanya Anda harus menambahkan konten input Anda ke dalam aliran. paxumumnya merupakan solusi terbaik dan paling sederhana dalam kasus itu, tetapi Anda mungkin juga mempertimbangkannya mksquashfs.

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

  3. Jangan tidak mengenkripsi dengan ssh.

    • Menambahkan overhead enkripsi ke media tepercaya tidak perlu, dan dapat sangat merusak kecepatan transfer yang berkelanjutan karena data yang dibaca perlu dibaca dua kali .
    • The PRNG perlu membaca data, atau setidaknya beberapa dari itu, untuk mempertahankan keacakan.
    • Dan tentu saja Anda perlu mentransfer data juga.
    • Anda juga perlu mentransfer overhead enkripsi itu sendiri - yang berarti lebih banyak pekerjaan untuk lebih sedikit data yang ditransfer per burst .

    • Jadi Anda harus menggunakan netcat( atau, seperti yang saya inginkan, nmapproyek lebih mampuncat ) untuk salinan jaringan sederhana, seperti yang telah disarankan di tempat lain:

      ###  on tgt machine...
nc -l 9999 > out.lz4
###  then on src machine...
... lz4 | nc tgt.local 9999
— mikeserv
sumber
1
Jawaban yang fantastis. Satu titik kecil gramatikal - "kurangi jumlah data yang perlu ditukar per burst" - Saya pikir Anda menggunakan kompresi untuk meningkatkan kepadatan informasi karena 'semburan' adalah lebar tetap dan oleh karena itu jumlah data yang dipertukarkan tetap konstan meskipun informasi yang ditransfer per burst dapat bervariasi.
— Engineer Dollery
@ EngineerDollery - ya, itu bodoh. Saya pikir itu lebih baik,
— mikeserv
@IQAndreas - Saya serius mempertimbangkan jawaban ini. Secara pribadi saya menggunakan pigz, dan peningkatan kecepatan luar biasa . Paralelisme adalah kemenangan besar; CPU jauh lebih cepat daripada bagian lain dari pipa data jadi saya ragu kompresi paralel akan memperlambat Anda (gzip tidak bisa diparalelkan). Anda mungkin menemukan ini cukup cepat sehingga tidak ada insentif untuk menyulap hard drive; Saya tidak akan terkejut jika yang satu ini secara keseluruhan lebih cepat (termasuk waktu swap disk). Anda dapat melakukan benchmark dengan dan tanpa kompresi. Bagaimanapun, baik jawaban disk BlueRaja atau yang ini harus menjadi jawaban yang Anda terima.
— Mike S
Kompresi cepat adalah saran yang bagus. Perlu dicatat, bahwa hanya membantu jika data cukup kompresibel, yang berarti, misalnya, itu belum harus dalam format terkompresi.
— Walter Tross
@WalterTross - ini akan membantu jika ada input yang dapat dikompres, tidak peduli rasionya, selama pekerjaan kompresi mengungguli pekerjaan transfer. Pada sistem empat inti modern, sebuah lz4pekerjaan harus dengan mudah melangkah bahkan GIGe yang terbuka lebar, dan USB 2.0 tidak memiliki peluang. Selain lz4itu , dirancang hanya untuk bekerja ketika seharusnya - itu sebagian sangat cepat karena tahu kapan kompresi harus dilakukan dan kapan seharusnya tidak. Dan jika itu adalah file perangkat yang sedang ditransfer, maka bahkan input yang sudah dikompres dapat memampatkan pula jika ada fragmentasi dalam sistem file sumber.
— mikeserv
25

Ada beberapa batasan yang bisa membatasi kecepatan transfer.

  1. Ada overhead jaringan yang melekat pada pipa 1Gbps. Biasanya, ini mengurangi throughput AKTUAL ke 900Mbps atau kurang. Maka Anda harus ingat bahwa ini adalah lalu lintas dua arah dan Anda harus mengharapkan turun secara signifikan kurang dari 900Mbps.

  2. Meskipun Anda menggunakan "router new-ish", apakah Anda yakin bahwa router mendukung 1Gbps? Tidak semua router baru mendukung 1Gbps. Selain itu, kecuali router tingkat perusahaan, Anda kemungkinan akan kehilangan bandwidth transmisi tambahan karena router tidak efisien. Meskipun berdasarkan apa yang saya temukan di bawah, sepertinya Anda mendapatkan di atas 100Mbps.

  3. Mungkin ada kemacetan jaringan dari perangkat lain yang berbagi jaringan Anda. Sudahkah Anda mencoba menggunakan kabel yang terpasang langsung seperti yang Anda katakan dapat Anda lakukan?

  4. Berapa jumlah IO disk Anda yang Anda gunakan? Kemungkinan, Anda dibatasi, bukan oleh jaringan, tetapi oleh disk drive. Sebagian besar HDD 7200rpm hanya akan mendapatkan sekitar 40MB / s. Apakah Anda menggunakan serangan sama sekali? Apakah Anda menggunakan SSD? Apa yang Anda gunakan di ujung remote?

Saya sarankan menggunakan rsync jika ini diharapkan dijalankan kembali untuk backup. Anda juga bisa scp, ftp (s), atau http menggunakan pengunduh seperti filezilla di ujung yang lain karena akan memparalelkan koneksi ssh / http / https / ftp. Ini dapat meningkatkan bandwidth karena solusi lain lebih dari satu pipa. Satu pipa / utas masih dibatasi oleh fakta bahwa itu adalah single-threaded, yang berarti bahwa itu bahkan bisa diikat dengan CPU.

Dengan rsync, Anda mengambil sejumlah besar kompleksitas solusi Anda serta memungkinkan kompresi, pelestarian izin, dan memungkinkan transfer parsial. Ada beberapa alasan lain, tetapi umumnya metode cadangan yang disukai (atau menjalankan sistem cadangan) dari perusahaan besar. Commvault sebenarnya menggunakan rsync di bawah perangkat lunak mereka sebagai mekanisme pengiriman untuk cadangan.

Berdasarkan contoh Anda yang diberikan 80GB / jam, Anda mendapatkan sekitar 177Mbps (22.2MB / s). Saya merasa Anda dapat dengan mudah menggandakan ini dengan rsync pada garis ethernet khusus antara dua kotak karena saya berhasil mendapatkan ini dalam pengujian saya sendiri dengan rsync lebih dari gigabit.

— Khrystoph
sumber
12
+1 untuk rsync. Ini mungkin tidak lebih cepat saat pertama kali Anda menjalankannya, tetapi itu pasti akan untuk semua waktu berikutnya.
— Skrrp
4
> Sebagian besar HDD 7200rpm hanya akan mencapai sekitar 40MB / s. IME Anda lebih cenderung melihat lebih dari 100MB / s secara berurutan dengan drive modern (dan ini termasuk ~ 5k drive). Padahal, ini mungkin disk yang lebih lama.
— Bob
2
@ Bob: Yang modern itu masih bisa membaca hanya 5400 trek melingkar per menit. Disk ini masih cepat karena setiap lagu mengandung lebih dari satu megabyte. Itu artinya mereka juga disk yang cukup besar, disk berukuran 320 GB tidak dapat menampung terlalu banyak kilobyte per track, yang tentu membatasi kecepatannya.
— MSalters
1
40MB / s jelas sangat pesimis untuk membaca berurutan untuk semua drive yang dibuat dalam dekade terakhir. Drive 7200RPM saat ini dapat melebihi 100MB / s seperti kata Bob.
— hobbs
3
Gigabit Ethernet adalah dupleks penuh 1000 mbps . Anda mendapatkan 1000mbps (atau, seperti yang Anda katakan, sekitar 900mbps pada kenyataannya) setiap arah . Kedua ... hard drive sekarang secara rutin mendapatkan 100MB / detik. 40MB / detik lambat, kecuali jika ini drive yang sudah berumur satu dekade
— derobert
16

Kami menangani ini secara teratur.

Dua metode utama yang cenderung kita gunakan adalah:

  1. SATA / eSATA / sneakernet
  2. Langsung NFS mount, lalu lokal cpataursync

Yang pertama tergantung pada apakah drive dapat dipindahkan secara fisik. Ini tidak selalu terjadi.

Yang kedua bekerja dengan sangat baik. Secara umum kami memaksimalkan koneksi 1gbps dengan mudah menggunakan NFS mounts langsung. Anda tidak akan mendapatkan yang mendekati ini dengan scp, dd over ssh, atau yang serupa (Anda akan sering mendapatkan tingkat maks mendekati 100mpbs secara mencurigakan). Bahkan pada prosesor multicore yang sangat cepat, Anda akan mengalami hambatan pada throughput maks kripto dari salah satu core pada paling lambat kedua mesin, yang sangat lambat dibandingkan dengan cp atau rsync dengan bor penuh pada pemasangan jaringan yang tidak dienkripsi. Kadang-kadang Anda akan menabrak dinding iops untuk sementara waktu dan terjebak di sekitar ~ 53MB / s bukannya lebih khas ~ 110MB / s, tapi itu biasanya berumur pendek kecuali sumber atau tujuan sebenarnyasatu drive, maka Anda mungkin akan dibatasi oleh laju berkelanjutan dari drive itu sendiri (yang cukup bervariasi untuk alasan acak Anda tidak akan tahu sampai Anda benar-benar mencobanya) - meh.

NFS bisa sedikit menjengkelkan jika dipasang pada distro yang tidak dikenal, tetapi secara umum itu adalah cara tercepat untuk mengisi pipa selengkap mungkin. Terakhir kali saya melakukan ini lebih dari 10gbps, saya tidak pernah benar-benar mengetahui apakah itu memaksimalkan koneksi, karena transfer sudah berakhir sebelum saya kembali dari mengambil kopi - jadi mungkin ada batas alami yang Anda tekan di sana. Jika Anda memiliki beberapa perangkat jaringan antara sumber dan tujuan, Anda dapat mengalami sedikit keterlambatan atau cegukan dari efek jaringan slinky, tetapi umumnya ini akan bekerja di seluruh kantor (tidak ada lalu lintas lain yang memindahkannya) atau dari satu ujung pusat data ke yang lain (kecuali jika Anda memiliki semacam penyaringan / inspeksi yang terjadi secara internal, dalam hal ini semua taruhan dimatikan ).

SUNTING

Saya melihat beberapa obrolan tentang kompresi ... jangan tidak kompres koneksi. Ini akan memperlambat Anda dengan cara yang sama dengan layer crypto. Kemacetan akan selalu menjadi satu inti jika Anda mengompres koneksi (dan Anda bahkan tidak akan mendapatkan pemanfaatan bus inti yang sangat baik). Hal paling lambat yang dapat Anda lakukan dalam situasi Anda adalah menggunakan saluran terenkripsi dan terkompresi antara dua komputer yang duduk bersebelahan di koneksi 1gbps atau lebih tinggi.

BUKTI MASA DEPAN

Saran ini berdiri pada pertengahan 2015. Ini hampir pasti tidak akan terjadi selama bertahun-tahun lagi. Jadi, ambil semuanya dengan sebutir garam, dan jika Anda menghadapi tugas ini secara teratur maka cobalah berbagai metode pada beban aktual alih-alih membayangkan Anda akan mendapatkan apa pun yang mendekati optimal teoretis, atau bahkan mengamati laju throughput kompresi / kripto yang tipikal untuk hal-hal seperti web lalu lintas, yang sebagian besar bersifat tekstual (protip: transfer massal biasanya terdiri terutama dari gambar, audio, video, file database, kode biner, format file kantor, dll. yang sudah dikompresi)dengan cara mereka sendiri dan sangat sedikit manfaat dari dijalankan melalui rutin kompresi yang lain, ukuran blok kompresi yang hampir dijamin tidak sejajar dengan data biner Anda yang sudah dikompresi ...).

Saya membayangkan bahwa di masa depan konsep-konsep seperti SCTP akan dibawa ke tempat yang lebih menarik, di mana koneksi berikat (atau koneksi serat tersalur yang dihubungkan secara internal) khas, dan masing-masing saluran dapat menerima aliran independen dari yang lain, dan masing-masing stream dapat dikompresi / dienkripsi secara paralel, dll. Itu akan luar biasa! Tapi bukan itu yang terjadi hari ini di tahun 2015, dan meskipun berfantasi dan berteori bagus, kebanyakan dari kita tidak memiliki cluster penyimpanan khusus yang berjalan dalam data ruang cryo-chamber langsung ke jeroan Blue Gen / Q yang menghasilkan jawaban untuk Watson. Itu bukan kenyataan. Kami juga tidak punya waktu untuk menganalisis muatan data kami secara mendalam untuk mencari tahu apakah kompresi adalah ide yang baik atau tidak - transfer itu sendiri akan berakhir sebelum kami menyelesaikan analisis kami,

Tapi...

Waktu berubah dan rekomendasi saya terhadap kompresi dan enkripsi tidak akan berlaku. Saya benar-benar ingin saran ini dibatalkan dalam kasus tipikal segera. Itu akan membuat hidup saya lebih mudah.

— zxq9
sumber
1
@jofel Hanya ketika kecepatan jaringan lebih lambat dari throughput kompresi prosesor - yang tidak pernah benar untuk 1gpbs atau koneksi yang lebih tinggi. Namun dalam kasus tipikal, jaringan adalah penghambat, dan kompresi secara efektif mempercepat - tetapi ini bukan kasus yang OP jelaskan.
— zxq9
2
lz4cukup cepat untuk tidak menghambat gigEt, tetapi tergantung pada apa yang ingin Anda lakukan dengan salinan, Anda mungkin memerlukannya tidak terkompresi. lzop juga cukup cepat. Pada Sandybridge i5-2500k saya (3.8GHz), lz4 < /dev/raid0 | pv -a > /dev/nullberjalan pada ~ 180MB / s input, ~ 105MB / s output, tepat untuk gigE. Dekompresi pada sisi penerimaan bahkan lebih mudah pada CPU.
— Peter Cordes
1
Selain itu, 3,8GHz sedikit lebih cepat daripada kebanyakan prosesor server yang dijalankan (atau banyak sistem kelas bisnis dengan berbagai rasa, setidaknya yang biasa saya lihat). Lebih umum untuk melihat jumlah inti yang lebih tinggi dengan kecepatan clock yang jauh lebih rendah di pusat data. Paralelisasi beban transfer belum menjadi masalah untuk waktu yang lama , jadi kami terjebak dengan kecepatan maks dari satu inti dalam banyak kasus - tapi saya berharap ini akan berubah sekarang karena kecepatan clock umumnya diunggulkan tetapi kecepatan jaringan masih memiliki jauh untuk pergi sebelum mencapai maksimum.
— zxq9
2
Saya sepenuhnya tidak setuju dengan komentar Anda tentang kompresi. Itu sepenuhnya tergantung pada kompresibilitas data. Jika Anda bisa mendapatkan rasio kompresi 99,9%, akan bodoh jika tidak melakukannya - mengapa mentransfer 100GB saat Anda dapat mentransfer 100MB? Saya tidak menyarankan bahwa tingkat kompresi ini adalah kasus untuk pertanyaan ini, hanya menunjukkan bahwa ini harus dipertimbangkan berdasarkan kasus per kasus dan bahwa tidak ada aturan absolut.
— Engineer Dollery
1
@EngineerDollery Ini tidak berlaku dalam transfer massal sama sekali di dunia nyata. Saya melakukan ini hampir setiap hari dan telah menguji berbagai metode dan pengaturan. Dalam kasus umum, transfer data besar dalam jumlah besar yang tidak dikenal (apa pun yang Anda tidak punya waktu untuk menjalankan tes penyetelan kompresi - yang berarti dalam praktiknya hampir semua hal di pusat data, infrastruktur perusahaan, server bisnis kecil, atau jaringan rumah) jauh lebih banyak lebih cepat melintasi koneksi 1gbps atau lebih tinggi. Ayo coba. Teks biasanya merupakan huruf besar untuk kompresi. Teks terdiri dari sebagian kecil dari muatan transfer curah tipikal.
— zxq9
6

Alat bagus yang saya gunakan di masa lalu adalah bbcp. Seperti yang terlihat di sini: https://www.slac.stanford.edu/~abh/bbcp/ .

Lihat juga http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm

Saya memiliki kecepatan transfer yang sangat cepat dengan alat ini.

— Hati gelap
sumber
1
Tautan kedua dari jawaban ini menjelaskan cara menyetel parameter kernel untuk mencapai kecepatan yang lebih tinggi. Penulis di sana mendapat 800 megabyte per detik dalam tautan 10G dan beberapa hal tampaknya berlaku untuk tautan 1Gbps.
— Stéphane Gourichon
5

Jika Anda mendapatkan kartu pass pertama (entah bagaimana melalui kabel / sneakernet / apa pun), Anda dapat melihat rsyncopsi tertentu yang dapat mempercepat transfer berikutnya. Cara yang sangat baik untuk pergi adalah:

rsync -varzP sourceFiles destination

Pilihannya adalah: verbose, mode arsip, rekursif, kompres, Kemajuan parsial

— Melompat Kelinci
sumber
2
Rsync lebih dapat diandalkan daripada netcat, tetapi arsip menyiratkan rekursif, sehingga r berlebihan.
— Tanath
Juga, -zbisa sangat lambat tergantung pada CPU Anda dan data apa yang Anda proses. Saya telah mengalami transfer dari 30 MB / s ke 125 MB / s saat menonaktifkan kompresi.
— lindhe
4

Ditambahkan pada desakan poster asli dalam komentar untuk jawaban Zackse, meskipun saya tidak yakin itu adalah yang tercepat dalam keadaan khusus.

bashmemiliki sintaks redirection khusus:
Untuk output:      > /dev/tcp/ IP  / port
Untuk input:       < /dev/tcp/ IP  / port
IP larangan dapat berupa IP desimal-desimal atau nama host; larangan port dapat berupa angka desimal atau nama port dari /etc/services.

Tidak ada /dev/tcp/direktori aktual . Ini adalah sintaksis khusus yang memerintahkan bashuntuk membuat soket TCP, menghubungkannya ke tujuan yang ditentukan, dan kemudian melakukan hal yang sama seperti pengalihan file biasa (yaitu, ganti aliran standar masing-masing dengan soket menggunakan dup2 (2)).

Oleh karena itu, seseorang dapat melakukan streaming data dari ddatau tardi mesin sumber langsung melalui TCP. Atau, sebaliknya, untuk mengalirkan data ke taratau sesuatu yang serupa secara langsung melalui TCP. Bagaimanapun, satu netcat berlebihan dihilangkan.

Catatan tentang netcat

Ada ketidakkonsistenan dalam sintaksis antara netcat klasik dan GNU netcat . Saya akan menggunakan sintaksis klasik yang biasa saya gunakan. Ganti -lpdengan -luntuk GNU netcat.

Juga, saya tidak yakin apakah netcat GNU menerima -qsakelar.

Mentransfer gambar disk

(Di sepanjang garis jawaban zackse.)
Di tujuan:

nc -lp 9999 >disk_image

Sumber:

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

Membuat arsip tar.gz, dengan tar

Di tempat tujuan:

nc -lp 9999 >backup.tgz

Sumber:

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

Ganti .tgzdengan .tbzdan czdengan cjuntuk mendapatkan bzip2arsip yang dikompresi.

Mentransfer dengan ekspansi langsung ke sistem file

Juga dengan tar.
Di tempat tujuan:

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

Sumber:

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

Ini akan bekerja tanpa -q 1, tetapi netcat akan macet ketika data berakhir. Lihat tar (1) untuk penjelasan tentang sintaks dan peringatan dari tar. Jika ada banyak file dengan redundansi tinggi (entropi rendah), maka kompresi (mis. czDan xzbukannya cdan x) dapat dicoba, tetapi jika file khas dan jaringan cukup cepat, itu hanya akan memperlambat proses. Lihat jawaban mikeserv untuk perincian tentang kompresi.

Gaya alternatif (port tujuan mendengarkan)

Di tempat tujuan:

cd backups
nc -lp 9999 |tar x

Sumber:

tar c files or directories to be transferred >/dev/tcp/destination/9999
— Incnis Mrsi
sumber
bash sebenarnya tidak dapat "mendengarkan" pada soket, untuk menunggu dan menerima file: unix.stackexchange.com/questions/49936/... jadi Anda harus menggunakan sesuatu yang lain untuk setidaknya satu setengah dari koneksi ...
— rogerdpack
2

Saya akan menggunakan skrip ini yang saya tulis yang membutuhkan socatpaket.

Di mesin sumber:

tarnet -d wherefilesaretosend pass=none 12345 .

Pada mesin target:

tarnet -d wherefilesaretogo pass=none sourceip/12345

Jika vbufpaket (Debian, Ubuntu) ada di sana maka pengirim file akan menunjukkan kemajuan data. Penerima file akan menunjukkan file apa yang diterima. Opsi pass = dapat digunakan di mana data mungkin terpapar (lebih lambat).

Sunting:

Gunakan -nopsi untuk menonaktifkan kompresi, jika CPU adalah leher botol.

— Skaperen
sumber
2

Jika anggaran bukan masalah utama, Anda dapat mencoba menghubungkan drive dengan "konektor drive" inti Intel Xeon E5 12. Konektor ini biasanya sangat kuat, sehingga Anda bahkan dapat menjalankan perangkat lunak server Anda saat ini. Dari kedua server!

Ini mungkin terlihat seperti jawaban yang menyenangkan, tetapi Anda harus benar-benar mempertimbangkan mengapa Anda memindahkan data antar server dan jika yang besar dengan memori dan penyimpanan bersama mungkin lebih masuk akal.

Tidak yakin dengan spesifikasi saat ini, tetapi transfer lambat mungkin dibatasi oleh kecepatan disk, bukan jaringan?

— pengguna133111
sumber
1

Jika Anda hanya peduli tentang backup, dan bukan tentang byte untuk salinan hard drive, maka saya akan merekomendasikan backupPC. http://backuppc.sourceforge.net/faq/BackupPC.html Agak sulit untuk diatur tetapi transfer sangat cepat.

Waktu transfer awal saya untuk sekitar 500G data adalah sekitar 3 jam. Pencadangan berikutnya terjadi dalam waktu sekitar 20 detik.

Jika Anda tidak tertarik dengan cadangan, tetapi mencoba menyinkronkan, maka rsync atau serempak akan lebih sesuai dengan kebutuhan Anda.

Salinan byte untuk hard disk byte biasanya merupakan ide yang mengerikan untuk tujuan pencadangan (tanpa tambahan, tanpa menghemat ruang, drive tidak dapat digunakan, Anda harus mencadangkan "ruang kosong", dan Anda harus membuat cadangan sampah (seperti file swap 16G atau 200G core dumps atau semacamnya). Menggunakan rsync (atau backuppc atau yang lain), Anda dapat membuat "snapshots" pada waktunya sehingga Anda dapat pergi ke "seperti apa sistem file Anda terlihat 30 menit yang lalu" dengan overhead yang sangat sedikit.

Yang mengatakan, jika Anda benar-benar ingin mentransfer byte untuk salinan byte maka masalah Anda akan terletak pada transfer dan bukan dalam mendapatkan data dari drive. Tanpa 400G RAM, transfer file 320G akan memakan waktu sangat lama. Menggunakan protokol yang tidak dienkripsi adalah pilihan, tetapi tidak peduli apa, Anda hanya harus duduk di sana dan menunggu selama beberapa jam (melalui jaringan).

— coteyr
sumber
1
bagaimana cara 400G RAM mempercepat transfer data?
— Skaperen
Tidak yakin ini maksudnya, tetapi saya membacanya sebagai "media apa pun yang lebih lambat dari transfer RAM ke RAM akan memakan waktu cukup lama", daripada "beli 400 GB RAM dan transfer HDD ke HDD Anda akan lebih cepat".
— MichaelS
Yap ,, ram akan menjadi penyangga untuk Anda, dan itu akan tampak lebih cepat. Anda dapat melakukan transfer HD ke HD dengan buffering RAM sepenuhnya dan itu akan tampak sangat cepat. Ini juga akan memerlukan cukup banyak waktu untuk menyiram ke disk, tetapi HD ke RAM ke RAM ke HD lebih cepat dari HD ke HD. (Perlu diingat bahwa Anda harus melakukan HD ke RAM ke RAM ke HD, tetapi jika Anda memiliki kurang dari seluruh ukuran transfer RAM Anda, Anda harus "flush" dalam segmen.)
— coteyr
Cara lain untuk menempatkannya adalah dengan mengompres atau bahkan hanya mengirim seluruh drive sumber harus dibaca ke ram. Jika tidak cocok sekaligus, ia harus membaca segmen, mengirim, membuang segmen, mencari, membaca segmen, dll. Jika itu cocok sekaligus, maka ia hanya harus membaca semuanya sekaligus. Sama di tempat tujuan.
— coteyr
1
HD ke RAM ke RAM ke HD lebih cepat dari HD ke HD Bagaimana bisa lebih cepat?
— AL
1

Terlepas dari program, saya biasanya menemukan bahwa "menarik" file melalui jaringan lebih cepat daripada "mendorong". Artinya, masuk ke komputer tujuan dan melakukan membaca lebih cepat daripada masuk ke komputer sumber dan menulis.

Juga, jika Anda akan menggunakan drive perantara, pertimbangkan ini: Dapatkan drive eksternal (baik sebagai paket, atau drive terpisah yang dicolokkan ke stasiun dok) yang menggunakan eSATA daripada USB. Kemudian pada masing-masing dari kedua komputer baik memasang kartu dengan port eSATA, atau mendapatkan kabel adaptor sederhana yang membawa salah satu port SATA internal ke konektor eSATA eksternal. Kemudian colokkan drive ke komputer sumber, hidupkan drive, dan tunggu sampai auto-mount (Anda bisa me-mount manaully, tetapi jika Anda melakukan ini berulang kali Anda mungkin juga memasukkannya ke file fstab Anda). Kemudian salin; Anda akan menulis dengan kecepatan yang sama dengan drive internal. Kemudian lepaskan drive, matikan, pasang ke komputer lain, hidupkan, tunggu pemasangan otomatis, dan baca.

— Mike Ciaraldi
sumber
2
Bisakah Anda memberikan spesifik bagaimana Anda "menarik" file? Utilitas apa yang Anda gunakan, dan dapatkah Anda memberikan sampel yang menunjukkan efek ini?
— STW
Saya tidak yakin apakah ini akan menjadi jawaban yang lebih lengkap, tetapi pertimbangkan skenario ini: Misalkan Anda memiliki dua komputer, foo dan bar, dan Anda ingin menyalin data dari foo ke bar. (1) Anda masuk ke foo, kemudian me-mount remote drive yang secara fisik terhubung ke bar. Kemudian Anda menyalin dari disk foo ke direktori yang dipasang dari jarak jauh (yang secara fisik ada di bar). Saya menyebutnya mendorong data ke komputer lain. (2) Bandingkan ini dengan cara lain menyalin data yang sama. Masuk ke bar, pasang direktori yang dilampirkan pada foo, dan baca dari foo ke drive bar. Ini menarik.
— Mike Ciaraldi
Penyalinan ini dapat dilakukan dengan perintah Linux cp, dari file manager GUI, atau cara lain menyalin file. Saya pikir menarik ternyata lebih cepat karena menulis lebih lambat daripada membaca, dan lebih banyak keputusan tentang bagaimana menulis ke disk tujuan sedang dilakukan pada komputer yang sama dengan drive terpasang, sehingga ada lebih sedikit overhead. Tetapi mungkin ini tidak lagi terjadi dengan sistem yang lebih modern.
— Mike Ciaraldi
1

Saya akan merekomendasikan agar Anda melihat NIC-teaming. Ini melibatkan penggunaan beberapa koneksi jaringan yang berjalan secara paralel. Dengan anggapan bahwa Anda benar-benar membutuhkan transfer lebih dari 1Gb, dan bahwa 10Gb mahal, 2Gb yang disediakan oleh NIC-teaming akan menjadi biaya kecil, dan komputer Anda mungkin sudah memiliki port tambahan.

— Byron Jones
sumber
Jika Anda mengacu pada LACP (Link Aggregation Control Protocol) maka Anda tidak akan melihat peningkatan kecepatan. Ini Menyediakan redundansi dan beberapa kemampuan untuk melayani koneksi yang lebih bersamaan, tetapi itu tidak akan memberikan dorongan kecepatan untuk jenis transfer ini.
— STW
@ STW: Dibutuhkan dukungan peralihan untuk menggabungkan dua tautan ke satu mesin menjadi tautan 2gbit, tetapi itu mungkin. Hanya membantu jika kedua mesin memiliki tautan 2gbit ke sakelar. Jika Anda memiliki dua kabel yang menjalankan NIC <-> NIC, tanpa sakelar, itu akan berfungsi juga, tetapi tidak terlalu berguna (kecuali jika Anda memiliki NIC ke-3 dalam satu mesin agar tetap terhubung ke Internet).
— Peter Cordes
apakah ada nama khusus untuk fitur ini di sakelar?
— STW
Ada beberapa variasi NIC-teaming, EtherChannel, dll. STW tepat untuk konfigurasi tertentu, ini tidak akan membantu, tetapi untuk beberapa konfigurasi, itu akan membantu. Itu tergantung pada apakah atau tidak saluran terikat mempercepat kinerja untuk satu soket IP atau tidak. Anda harus meneliti spesifik untuk menentukan apakah ini solusi yang layak untuk Anda.
— Byron Jones
802.3ad adalah standar terbuka yang akan Anda cari di sakelar Anda. Sebagai peretasan cepat, Anda mungkin hanya menghubungkan NIC tambahan ke jaringan, dan memberi mereka alamat IP yang sesuai pada subnet terpisah di ruang alamat pribadi. (host 1 port a & host 2 port a dapatkan satu subnet, host 1 port b dan host 2 port b dapatkan subnet lain). Kemudian jalankan saja dua pekerjaan paralel untuk melakukan transfer. Ini akan jauh lebih sederhana daripada mempelajari seluk beluk Etherchannel, 802.3ad, dll.
— Dan Pritts
1

FWIW, saya selalu menggunakan ini:

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

Hal tentang metode ini adalah bahwa ia akan mempertahankan izin file / folder antara mesin (dengan asumsi pengguna / grup yang sama ada pada keduanya) (Juga saya biasanya melakukan ini untuk menyalin gambar disk virtual karena saya dapat menggunakan parameter -S untuk menangani file jarang. )

Hanya menguji ini di antara dua server yang sibuk dan berhasil ~ 14GB dalam 216-an (sekitar 64MB / s) - mungkin akan lebih baik di antara mesin khusus dan / atau kompresi ... 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
— ttstooge
sumber
1

Kecuali jika Anda ingin melakukan forensik sistem file, gunakan program dump / restore untuk sistem file Anda untuk menghindari menyalin ruang kosong yang FS tidak gunakan. Bergantung pada sistem file apa yang Anda miliki, ini biasanya akan mempertahankan semua metadata, termasuk ctime. nomor inode dapat berubah, sekali lagi, tergantung pada sistem file apa (xfs, ext4, ufs ...).

Target pemulihan dapat berupa file pada sistem target.

Jika Anda ingin gambar disk penuh dengan tabel partisi, Anda dapat dd1M disk pertama untuk mendapatkan tabel partisi / bootloader / barang, tetapi kemudian xfsdumppartisi.

Dari info-dump Anda, saya tidak tahu jenis sistem file yang Anda miliki. Jika ufs BSD, maka saya pikir itu memiliki program dump / restore. Jika ZFS, baik IDK, mungkin ada sesuatu.

Umumnya disk penyalinan penuh di sekitar terlalu lambat untuk apa pun kecuali situasi pemulihan. Anda juga tidak dapat melakukan backup tambahan.

— Peter Cordes
sumber
1

Anda juga dapat mengatur sistem untuk memiliki penyimpanan bersama!

Saya mempertimbangkan bahwa ini bersebelahan, dan Anda cenderung melakukan ini lagi & lagi ....

— pengguna133526
sumber
1

Bagaimana dengan kabel crossover ethernet? Alih-alih mengandalkan kecepatan nirkabel, Anda dibatasi pada kecepatan kabel NIC Anda.

Ini pertanyaan serupa dengan beberapa contoh solusi semacam itu.

Tampaknya hanya kabel ethernet yang khas akan cukup saat ini. Jelas semakin baik NIC Anda semakin cepat transfer.

Untuk meringkas, jika ada pengaturan jaringan yang diperlukan, itu harus dibatasi hanya dengan menetapkan IP statis untuk server Anda dan komputer cadangan dengan subnet mask 255.255.255.0

Semoga berhasil!

Sunting:

@Khrystoph menyentuh ini dalam jawabannya

Bagaimana cara meningkatkan kecepatan kecepatan? Bisakah Anda jelaskan jawabannya?
— AL
1
Ini berpotensi meningkatkan kecepatan karena Anda tidak perlu khawatir tentang jaringan perantara yang memperlambat Anda. Mengenai kabel ethernet "tipikal" vs "crossover" - ethernet 1Gb akan auto-crossover seperlunya. Switch ethernet HP akan melakukan ini pada 100MB. Merek lain, umumnya tidak, dan Anda akan membutuhkan crossover jika Anda terjebak pada 100Mb.
— Dan Pritts
1

Beberapa orang menyarankan Anda melewatkan ssh karena enkripsi akan memperlambat Anda. CPU modern sebenarnya cukup cepat pada 1Gb, tetapi OpenSSH memiliki masalah dengan implementasi windowing internal yang dapat memperlambat Anda secara drastis.

Jika Anda ingin melakukan ini dengan ssh, lihat HPN SSH . Ini memecahkan masalah windowing dan menambahkan enkripsi multithreaded. Sayangnya Anda harus membangun kembali ssh di kedua klien & server.

— Dan Pritts
sumber
0

OK Saya telah mencoba menjawab pertanyaan ini untuk dua komputer dengan "pipa sangat besar" (10Gbe) yang "dekat" satu sama lain.

Masalah yang Anda temui di sini adalah: sebagian besar kompresi akan macet di cpu, karena pipa-pipa itu sangat besar.

kinerja untuk mentransfer file 10GB (koneksi jaringan [Gode] 6 Gb, data yang tidak dapat dikompresi):

$  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

Dan dua kotak di 10 Gbe, versi netcat yang sedikit lebih tua (CentOs 6.7), file 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)

Jadi pada satu contoh, netcat menggunakan lebih sedikit cpu, di socat lainnya, jadi YMMV.

Dengan netcat, jika tidak memiliki opsi "-N -q 0" dapat mentransfer file terpotong, hati-hati ... pilihan lain seperti "-w 10" juga dapat mengakibatkan file terpotong.

Apa yang terjadi di hampir semua kasus ini adalah cpu sedang dimaksimalkan, bukan jaringan. scpmaksimal sekitar 230 MB / s, mematok satu inti pada pemanfaatan 100%.

Iperf3 sayangnya membuat file yang rusak . Beberapa versi netcat tampaknya tidak mentransfer seluruh file, sangat aneh. Terutama versi yang lebih lama.

Berbagai mantera "gzip sebagai pipa ke netcat" atau "mbuffer" juga tampaknya memaksimalkan CPU dengan gzip atau mbuffer, jadi tidak menghasilkan transfer yang lebih cepat dengan pipa besar seperti itu. lz4 mungkin membantu. Selain itu, beberapa hal pipa gzip yang saya coba hasilkan mengakibatkan transfer rusak untuk file yang sangat besar (> 4 GB) jadi berhati-hatilah di luar sana :)

Hal lain yang mungkin bekerja terutama untuk latensi yang lebih tinggi (?) Adalah untuk menyetel pengaturan tcp. Berikut adalah panduan yang menyebutkan nilai yang disarankan:

http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm dan https://fasterdata.es.net/host-tuning/linux/ (dari jawaban lain) mungkin pengaturan IRQ: https://fasterdata.es .net / host-tuning / 100g-tuning /

saran dari linode, tambahkan ke /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

Selain itu, mereka ingin Anda menjalankan:

 /sbin/ifconfig eth0 txqueuelen 10000

layak dicek ulang setelah tweaking untuk memastikan perubahan tidak menyebabkan kerusakan juga.

Juga mungkin layak untuk menyetel ukuran jendela: https://iperf.fr/iperf-doc.php#tuningtcp

Dengan kompresi koneksi lambat (er) pasti bisa membantu. Jika Anda memiliki pipa besar, kompresi yang sangat cepat dapat membantu dengan data yang dapat dikompresi, belum mencobanya.

Jawaban standar untuk "sinkronisasi hard drive" adalah untuk mensinkronisasi ulang file, yang menghindari transfer jika memungkinkan.

Pilihan lain: gunakan "parallel scp" (entah bagaimana atau lainnya), maka akan menggunakan lebih banyak core ...

— rogerdpack
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.