Menggambarkan pertukaran yang berguna bagi aplikasi Anda
Untuk setiap aliran, catat titik awal, tujuannya, dan orang yang membutuhkannya. Tambahkan protokol yang dipilih, arah pembukaan koneksi, frekuensi, dan volume yang diharapkan. Impor awal, koneksi administrasi, dan layanan yang dipanggil secara terus-menerus tidak disiapkan dengan kriteria yang sama. Tujuan yang tidak diketahui tetap menjadi hal yang harus diselesaikan, bukan izin umum untuk dibuka.
Daftar ini membantu tim Anda memutuskan apa yang harus dapat diakses dan apa yang dapat tetap tertutup. Daftar ini juga menetapkan siapa yang memvalidasi suatu perubahan. Karakteristik konektivitas tidak dapat disimpulkan dari model GPU: throughput, alamat, port, dan tata cara akses harus dicatat untuk lingkungan yang benar-benar disediakan. Matriks di bawah ini merupakan proyek fiktif, bukan layanan yang dinyatakan termasuk.
| Alur | Kriteria yang harus ditetapkan | Penanggung jawab |
|---|---|---|
| Workstation administrasi ke lingkungan | Protokol, tujuan, dan akses yang diizinkan | Penanggung jawab akses |
| Unggah data ke pekerjaan GPU | Volume awal, frekuensi, kelanjutan | Pemilik data |
| Aplikasi ke dependensi eksternal | Tujuan, metode autentikasi, batas waktu yang dapat diterima | Penanggung jawab aplikasi |
| Hasil ke tujuan penyimpanan | Volume akhir dan pemeriksaan penerimaan | Penanggung jawab hasil akhir |
Ukur transfer yang penting untuk jadwal Anda
Ambil sampel yang representatif, dengan jumlah dan ukuran file yang mendekati pekerjaan yang direncanakan. Satu arsip tunggal dan ribuan file kecil membebani prosedur secara berbeda. Ukur impor dan ekspor secara terpisah, ke tujuan yang benar-benar dipilih. Simpan volume berguna, waktu yang berlalu, alat, parameter, dan kondisi pengujian agar dapat membandingkan proses kedua.
Alat seperti iperf3 mengukur aliran jaringan antara klien dan server pengujian. Dokumentasinya membedakan antara arah normal dan arah terbalik. Pengujian semacam itu memerlukan dua ujung yang diizinkan; pengujian ini tidak dengan sendirinya membuktikan kecepatan penyalinan file, yang juga bergantung pada penyimpanan, pemrosesan, dan protokol. Mulailah dengan transfer aplikatif yang benar-benar menjadi sandaran jadwal Anda.
Mengubah pengukuran menjadi jendela transfer
Contoh sepenuhnya fiktif: 600 GB harus diekspor. Di sini, 1 GB sama dengan 1.000 MB dan throughput dinyatakan dalam MB per detik. Pada 120 MB/s berguna, pembagian 600.000 ÷ 120 menghasilkan 5.000 detik, yaitu 1 jam 23 menit 20 detik. Dengan asumsi yang lebih hati-hati yaitu 70 MB/s, hasilnya sekitar 8.571 detik, yaitu 2 jam 22 menit 51 detik. Tidak satu pun dari throughput ini menggambarkan penawaran Capordia.
Jika tim menambahkan 45 menit untuk menyelesaikan paket dan memeriksa penerimaannya, asumsi kedua memakan waktu sekitar 3 jam 08 menit. Tim dapat menetapkan slot 3 jam 10 menit, lalu menambahkan secara terpisah cadangan yang dianggap perlu. Jendela ini tetap bersyarat: perubahan volume, jumlah file, atau kondisi transfer mengharuskan perhitungan diulang. Jangan ganti estimasi ini dengan throughput teoretis suatu antarmuka.
| Asumsi | Durasi transfer saja | Dengan 45 menit persiapan dan pemeriksaan |
|---|---|---|
| 120 MB/s berguna | 1 jam 23 menit 20 detik | 2 jam 08 menit 20 detik |
| 70 MB/s berguna | Sekitar 2 jam 22 menit 51 detik | Sekitar 3 jam 07 menit 51 detik |
Siapkan akses dan kelanjutan tanpa membuka lebih dari yang diperlukan
Validasi terlebih dahulu tujuan dan identitas host dengan informasi yang diharapkan, lalu izin dan jalur kerja. Penolakan akses tidak diselesaikan dengan membagikan kata sandi akun perintah dalam dokumen bersama. Akses ke lingkungan dan koneksi ke akun Capordia memiliki fungsi yang berbeda; catat penanggung jawabnya tanpa menyalin rahasianya.
Jika prosedur Anda menggunakan OpenSSH SFTP, transfer dilakukan melalui SSH. Dokumentasinya juga menyatakan bahwa kelanjutan sebagian mengandaikan bahwa fragmen yang sudah ada sesuai dengan file sumber. Jika file sumber telah berubah, melanjutkan secara buta dapat menghasilkan salinan yang salah. Karena itu, tetapkan versi yang akan ditransfer, identifikasi file yang tidak lengkap, dan periksa hasilnya sebelum menyatakan pengiriman selesai.
Mendiagnosis penantian melalui tahapan yang dapat diamati
Jika file tiba tetapi aplikasi tidak merespons, periksa alur aplikatif alih-alih mengubah seluruh konfigurasi. Bedakan resolusi nama, pembukaan koneksi, autentikasi, pembacaan data pertama, dan transfer penuh. Catat waktu, arah, dan pesan persis yang berguna. Jauhkan kredensial, token, dan data konten dari yang dibagikan dengan dukungan.
Jika penyalinan mulai lalu melambat, bandingkan lintasan kedua dalam kondisi yang sama dan amati tahap-tahap di sekitarnya: pembacaan di sumber, penyiapan arsip, penulisan di tujuan. Temuan "GPU kurang terpakai" tidak cukup untuk menyimpulkan bahwa jaringan bertanggung jawab. Berkas diagnostik harus menunjukkan apa yang menunggu apa, dan pengamatan apa yang dapat memisahkan kemungkinan penyebabnya.
Memisahkan akses eksternal dan pertukaran antar-GPU
Jaringan yang digunakan untuk menjangkau aplikasi dan komunikasi internal suatu komputasi multi-kartu memenuhi kebutuhan yang berbeda. Panduan CUDA menjelaskan pembagian data dan komputasi yang eksplisit antar perangkat, dengan kemungkinan akses yang bergantung pada sistem. Baik jumlah kartu maupun penyalinan berkas yang baik dari workstation Anda tidak membuktikan berjalannya pemrosesan terdistribusi.
Jelaskanlah skenario yang diharapkan: tugas independen yang ditugaskan ke setiap kartu, atau pemrosesan yang mempertukarkan data di antara kartunya. Lalu periksa jalur yang benar-benar digunakan oleh perangkat lunak Anda. Penerimaan selesai ketika aliran yang diperlukan berfungsi, pemeriksaan tercatat, dan ada seseorang yang tahu cara melanjutkan transfer yang terputus. Kondisi yang ditetapkan kemudian masuk ke berkas penerapan.
Pertanyaan untuk memutuskan
Mengapa membedakan MB/s dan Mb/s dalam penjadwalan?
Satu byte berisi delapan bit. Dengan satuan desimal pada contoh, 70 MB/dtk setara dengan 560 Mb/dtk. Mencampur keduanya akan mengalikan atau membagi estimasi dengan delapan. Cantumkan satuan pada setiap pengukuran dan hitunglah dari laju transfer yang berguna.
Apakah kedua arah transfer perlu diuji?
Ya, jika proyek mengimpor data lalu mengekspor hasil. Jalur, tujuan, dan kondisinya bisa berbeda. Pengukuran impor yang baik tidak menjamin bahwa pengambilan hasil akhir akan muat dalam jendela waktu yang sama; ujilah arah yang menjadi dasar setiap tenggat.
Apakah transfer terenkripsi membebaskan dari pemeriksaan berkas?
Tidak. Transportasi dan validasi paket menjawab pertanyaan yang berbeda. Periksa juga berkas yang diharapkan, integritasnya, dan pembukaannya dari tujuan. Pemilihan berkas yang salah dapat tertransfer dengan benar namun tetap tidak dapat digunakan.