Menggunakan Azure Blob Storage dengan Azure Managed Lustre

Azure Managed Lustre terintegrasi dengan Azure Blob Storage untuk menyederhanakan proses impor data dari kontainer blob ke sistem file. Anda juga dapat mengekspor data dari sistem file ke kontainer blob untuk penyimpanan jangka panjang. Artikel ini menjelaskan konsep untuk menggunakan integrasi blob dengan sistem file Azure Managed Lustre.

Untuk memahami persyaratan dan konfigurasi yang diperlukan untuk kontainer blob yang kompatibel, lihat Prasyarat integrasi Blob.

Gambaran umum integrasi blob

Anda dapat mengonfigurasi integrasi blob selama pembuatan kluster, dan Anda dapat membuat pekerjaan impor kapan saja setelah kluster dibuat. Setelah data diimpor, Anda dapat bekerja dengan data seperti yang Anda lakukan dengan data sistem file lainnya. Saat file baru dibuat atau file yang sudah ada dimodifikasi dalam sistem file, Anda dapat mengekspor file ini kembali ke akun penyimpanan dengan menjalankan perintah Lustre CLI pada klien, atau dengan mengekspor data menggunakan pekerjaan ekspor.

Saat Anda mengimpor data dari kontainer blob ke sistem file Azure Managed Lustre, hanya nama file (namespace) dan metadata yang diimpor ke namespace Lustre. Konten aktual blob diimpor saat pertama kali diakses oleh klien. Ada sedikit penundaan saat pertama kali mengakses data sementara fitur Lustre Hierarchical Storage Management (HSM) menarik konten blob ke file yang sesuai dalam sistem file.

Anda dapat mengambil konten blob menggunakan perintah Lustre lfs hsm_restore dari klien yang dipasang dengan kemampuan sudo. Untuk mempelajari selengkapnya, lihat Memulihkan data dari Blob Storage.

Azure Managed Lustre berfungsi dengan akun penyimpanan yang mengaktifkan namespace hierarkis dan akun penyimpanan dengan namespace layanan non-hierarkis, atau datar. Perbedaan kecil berikut berlaku:

• Untuk akun penyimpanan dengan namespace hierarkis diaktifkan, Azure Managed Lustre membaca atribut POSIX dari header blob.
• Untuk akun penyimpanan yang tidak mengaktifkan namespace hierarkis, Azure Managed Lustre membaca atribut POSIX dari metadata blob. File kosong terpisah dengan nama yang sama dengan konten kontainer blob Anda dibuat untuk menyimpan metadata. File ini adalah saudara kandung dari direktori data aktual dalam sistem file Azure Managed Lustre.

Impor dari Blob Storage

Anda dapat mengonfigurasi integrasi dengan Blob Storage selama pembuatan kluster, dan Anda dapat membuat pekerjaan impor kapan saja setelah kluster dibuat.

Persyaratan kontainer blob

Saat mengonfigurasi integrasi blob selama pembuatan kluster, Anda harus mengidentifikasi dua kontainer blob terpisah: kontainer untuk diimpor dan kontainer pengelogan. Kontainer yang akan diimpor berisi data yang ingin Anda impor ke dalam sistem file Azure Managed Lustre. Kontainer pengelogan digunakan untuk menyimpan log untuk pekerjaan impor. Kedua kontainer ini harus berada di akun penyimpanan yang sama. Untuk mempelajari selengkapnya tentang persyaratan untuk kontainer blob, lihat Prasyarat integrasi Blob.

Impor awalan

Saat mengimpor data dari kontainer blob, Anda dapat secara opsional menentukan satu atau beberapa awalan untuk memfilter data yang diimpor ke dalam sistem file Azure Managed Lustre. Nama file dalam kontainer blob yang cocok dengan salah satu awalan ditambahkan ke rekaman metadata dalam sistem file. Ketika klien pertama kali mengakses file, kontennya diambil dari kontainer blob dan disimpan dalam sistem file.

Di portal Azure, gunakan bidang Impor awalan pada tab Tingkat Lanjut selama pembuatan kluster untuk menentukan data yang akan diimpor dari kontainer blob Anda. Bidang-bidang ini hanya berlaku untuk pekerjaan impor awal. Anda tidak dapat mengubah awalan impor setelah kluster dibuat.

Untuk pekerjaan impor, Anda dapat menentukan awalan impor saat membuat pekerjaan. Dari portal Azure, Anda dapat menentukan awalan impor di bidang Impor awalan. Anda juga dapat menentukan awalan impor saat menggunakan REST API untuk membuat pekerjaan impor.

Ingatlah pertimbangan berikut saat menentukan awalan impor:

• Awalan impor default adalah /. Perilaku default ini mengimpor konten seluruh kontainer blob.
• Jika Anda menentukan beberapa awalan, awalan harus tidak tumpang tindih. Misalnya, jika Anda menentukan /data dan /data2, pekerjaan impor gagal karena awalan tumpang tindih.
• Jika kontainer blob berada di akun penyimpanan dengan namespace hierarki diaktifkan, Anda dapat menganggap awalan sebagai jalur file. Item di bawah jalur disertakan dalam sistem file Azure Managed Lustre.
• Jika kontainer blob berada di akun penyimpanan dengan namespace layanan non-hierarkis (atau datar), Anda dapat menganggap awalan impor sebagai string pencarian yang dibandingkan dengan awal nama blob. Jika nama blob dalam kontainer dimulai dengan string yang Anda tentukan sebagai awalan impor, file tersebut dapat diakses dalam sistem file. Lustre adalah sistem file hierarkis, dan / karakter dalam nama blob menjadi pemisah direktori saat disimpan di Lustre.

Mode resolusi konflik

Saat mengimpor data dari kontainer blob, Anda dapat menentukan cara menangani konflik antara kontainer blob dan sistem file. Opsi ini hanya berlaku untuk pekerjaan impor yang dijalankan untuk kluster yang ada. Tabel berikut ini memperlihatkan mode resolusi konflik yang tersedia dan deskripsinya:

Mode	Deskripsi
fail	Pekerjaan impor gagal segera dengan kesalahan jika konflik terdeteksi.
skip	Pekerjaan impor melewati file jika konflik terdeteksi.
overwrite-dirty	Pekerjaan impor mengevaluasi jalur yang bertentangan untuk melihat apakah harus dihapus dan diimpor ulang. Untuk mempelajari lebih lanjut, lihat mode overwrite-dirty.
overwrite-always	Pekerjaan impor mengevaluasi jalur yang bertentangan dan selalu menghapus/mengimpor ulang jika kotor, atau merilis jika bersih. Untuk mempelajari lebih lanjut, lihat mode overwrite-always.

Mode timpa-kotor

Mode overwrite-dirty mengevaluasi jalur yang bertentangan untuk melihat apakah jalur tersebut harus dihapus dan diimpor ulang. Pada tingkat tinggi, overwrite-dirty mode memeriksa status HSM. Jika status HSM Bersih dan Diarsipkan, artinya datanya sinkron dengan kontainer blob sejauh yang dapat diketahui Lustre, maka hanya atribut yang diperbarui, jika diperlukan. Jika tidak, file dihapus dan dilaporkan kembali dari kontainer blob.

Memeriksa status HSM tidak menjamin bahwa file di Lustre cocok dengan file dalam kontainer blob. Jika Anda harus memastikan bahwa file di Lustre cocok dengan file dalam kontainer blob sedekat mungkin, gunakan overwrite-always mode .

Menimpa mode overwrite-always

overwrite-always Mode mengevaluasi jalur yang bertentangan dan selalu menghapus/mengimpor ulang jika kotor, atau melepaskan jika bersih. Mode ini berguna ketika Anda ingin memastikan bahwa sistem file selalu sinkron dengan kontainer blob. Ini juga merupakan opsi paling mahal, karena setiap file yang dipulihkan sebelumnya dirilis atau dihapus/diimpor ulang pada akses pertama.

Toleransi kesalahan

Saat mengimpor data dari kontainer blob, Anda dapat menentukan toleransi kesalahan. Tingkat toleransi kesalahan menentukan bagaimana pekerjaan impor menangani kesalahan sementara yang terjadi selama proses impor, misalnya, kesalahan sistem operasi atau gangguan jaringan. Penting untuk dicatat bahwa kesalahan dalam konteks ini tidak merujuk ke konflik file, yang ditangani oleh mode resolusi konflik.

Opsi toleransi kesalahan berikut tersedia untuk pekerjaan impor:

• Jangan izinkan kesalahan (default): Pekerjaan impor gagal segera jika terjadi kesalahan selama impor. Ini adalah perilaku default.
• Perbolehkan kesalahan: Pekerjaan impor berlanjut jika terjadi kesalahan, dan kesalahan dicatat. Setelah pekerjaan impor selesai, Anda dapat melihat kesalahan dalam kontainer pengelogan.

Pertimbangan untuk pekerjaan impor blob

Item berikut ini penting untuk dipertimbangkan saat mengimpor data dari kontainer blob:

• Hanya satu tindakan impor atau ekspor yang dapat berjalan pada satu waktu. Misalnya, jika pekerjaan impor sedang berlangsung, mencoba memulai pekerjaan impor lain mengembalikan kesalahan.
• Impor pekerjaan dapat dibatalkan. Anda dapat membatalkan pekerjaan impor yang dimulai pada kluster yang ada, atau pekerjaan impor yang dimulai selama pembuatan kluster.
• Penyebaran kluster dapat berhasil dikembalikan sebelum pekerjaan impor yang sesuai selesai. Pekerjaan impor terus berjalan di latar belakang. Anda dapat memantau kemajuan pekerjaan impor dengan cara berikut:
  • portal Azure: Portal Azure menampilkan status pekerjaan impor. Navigasi ke sistem file dan pilih Integrasi Blob untuk melihat status pekerjaan impor.
  • File Lustre di direktori akar: File bernama yang mirip /lustre/IMPORT_<state>.<timestamp_start> dengan dibuat di direktori akar Lustre selama impor. Tempat <state> penampung berubah saat impor berlangsung. File dihapus ketika pekerjaan impor berhasil diselesaikan.
• Untuk melihat detail tentang pekerjaan impor yang telah selesai, Anda dapat memeriksa kontainer pengelogan. Kontainer pengelogan berisi log untuk pekerjaan impor, termasuk kesalahan atau konflik yang terjadi selama impor.
• Jika pekerjaan impor gagal karena alasan apa pun, Anda mungkin tidak memiliki statistik lengkap tentang pekerjaan impor, seperti jumlah file yang diimpor atau jumlah konflik.

Memulihkan data dari Blob Storage

Secara default, konten blob diimpor ke sistem file saat pertama kali file yang sesuai diakses oleh klien. Untuk beban kerja dan skenario tertentu, Anda mungkin lebih suka memulihkan data dari kontainer blob sebelum pertama kali diakses. Anda dapat memilih untuk melakukan prefetch konten blob untuk menghindari penundaan awal saat blob diakses untuk pertama kalinya setelah impor. Untuk mengambil konten blob sebelumnya, Anda dapat menggunakan perintah Lustre lfs hsm_restore dari klien yang dipasang dengan kemampuan sudo. Perintah berikut akan mengambil konten blob ke dalam sistem file:

nohup find local/directory -type f -print0 | xargs -0 -n 1 sudo lfs hsm_restore &

Perintah ini memberi tahu server metadata untuk memproses permintaan pemulihan secara asinkron. Baris perintah tidak menunggu pemulihan selesai, yang berarti bahwa baris perintah berpotensi mengantre sejumlah besar entri untuk pemulihan di server metadata. Pendekatan ini dapat membangi server metadata dan menurunkan performa untuk pemulihan.

Untuk menghindari potensi masalah performa ini, Anda dapat membuat skrip dasar yang mencoba berjalan di jalur dan mengeluarkan permintaan pemulihan dalam batch dengan ukuran tertentu. Untuk mencapai performa yang wajar dan menghindari kewalahan server metadata, disarankan untuk menggunakan ukuran batch di mana saja dari 1.000 hingga 5.000 permintaan.

Contoh: Membuat skrip pemulihan batch

Contoh berikut menunjukkan cara membuat skrip untuk memulihkan data dari kontainer blob dalam batch. Buat file bernama file_restorer.bash dengan konten berikut:

#!/bin/bash
set -feu
set -o pipefail
main()
{
    if [ $# -lt 2 ]; then
        echo "$0 <path_to_fully_restore> <max_restores_at_a_time>"
        echo "Missing parameters"
        exit 1
    fi
    local RESTORE_PATH=$1
    local MAX_RESTORES=$2
    local FILES_LIST="/tmp/files_to_restore"
    find "$RESTORE_PATH" -type f > "$FILES_LIST"
    local TOTAL_FILES
    TOTAL_FILES=$(wc -l "$FILES_LIST")
    local RESTORE_TOTAL=0
    local RESTORE_COUNT=0
    while IFS="" read -r p || [ -n "$p" ]; do
        printf '%s\n' "$p"
        lfs hsm_restore "$p"
        ((RESTORE_COUNT++)) || true
        ((RESTORE_TOTAL++)) || true
        if (( RESTORE_COUNT >= MAX_RESTORES )); then
            while true; do
                local STATE
                STATE=$(lfs hsm_state "$p")
                RELEASED=') released exists archived'
                if ! [[ $STATE =~ $RELEASED ]]; then
                    echo "Restored $RESTORE_TOTAL / $TOTAL_FILES"
                    break
                fi
                sleep 0.2
            done
            RESTORE_COUNT=0
        fi
    done < "$FILES_LIST"
}
main "$@"

Contoh berikut menunjukkan cara menjalankan skrip bersama dengan output sampel:

root@vm:~# time ~azureuser/file_restorer.bash /lustre/client/ 5000
Finding all files to restore beneath: /lustre/client/
Found 78100 to restore
Initiating restores in batches of 5000...
Restored 5000 / 78100
Restored 10000 / 78100
Restored 15000 / 78100
Restored 20000 / 78100
Restored 25000 / 78100
Restored 30000 / 78100
Restored 35000 / 78100
Restored 40000 / 78100
Restored 45000 / 78100
Restored 50000 / 78100
Restored 55000 / 78100
Restored 60000 / 78100
Restored 65000 / 78100
Restored 70000 / 78100
Restored 75000 / 78100
Restored 78100 / 78100
real	6m59.633s
user	1m20.273s
sys	0m37.960s

Catatan

Saat ini, Azure Managed Lustre memulihkan data dari Blob Storage pada tingkat throughput maksimum ~7.5GiB/detik.

Mengekspor data ke Blob Storage menggunakan pekerjaan ekspor

Anda dapat menyalin data dari sistem file Azure Managed Lustre ke penyimpanan jangka panjang di Azure Blob Storage dengan membuat pekerjaan ekspor.

File mana yang diekspor selama pekerjaan ekspor?

Saat Anda mengekspor file dari sistem Azure Managed Lustre, tidak semua file disalin ke kontainer blob yang Anda tentukan saat membuat sistem file. Aturan berikut berlaku untuk mengekspor pekerjaan:

• Ekspor pekerjaan hanya menyalin file yang baru atau yang isinya dimodifikasi. Jika file yang Anda impor dari kontainer blob selama pembuatan sistem file tidak berubah, pekerjaan ekspor tidak mengekspor file.
• File dengan perubahan metadata hanya tidak diekspor. Perubahan metadata meliputi: pemilik, izin, atribut yang diperluas, dan perubahan nama (diganti namanya).
• File yang dihapus dalam sistem file Azure Managed Lustre tidak dihapus dalam kontainer blob asli selama pekerjaan ekspor. Pekerjaan ekspor tidak menghapus file dalam kontainer blob.

Menjalankan pekerjaan ekspor dalam sistem file aktif

Dalam sistem file aktif, perubahan pada file selama pekerjaan ekspor dapat mengakibatkan status kegagalan. Status kegagalan ini memberi tahu Anda bahwa tidak semua data dalam sistem file dapat diekspor ke Blob Storage. Dalam situasi ini, Anda dapat mencoba kembali ekspor dengan membuat pekerjaan ekspor baru. Pekerjaan baru hanya menyalin file yang tidak disalin di pekerjaan sebelumnya.

Dalam sistem file dengan banyak aktivitas, percobaan ulang mungkin gagal beberapa kali karena file sering berubah. Untuk memverifikasi bahwa file telah berhasil diekspor ke Blob Storage, periksa tanda waktu pada blob yang sesuai. Setelah pekerjaan selesai, Anda juga dapat melihat kontainer pengelogan yang dikonfigurasi pada waktu penyebaran untuk melihat informasi terperinci tentang pekerjaan ekspor. Kontainer pengelogan menyediakan informasi diagnostik tentang file mana yang gagal, dan mengapa gagal.

Jika Anda bersiap untuk menonaktifkan kluster dan ingin melakukan ekspor akhir ke Blob Storage, Anda harus memastikan bahwa semua aktivitas I/O dihentikan sebelum memulai pekerjaan ekspor. Pendekatan ini membantu menjamin bahwa semua data diekspor dengan menghindari kesalahan karena aktivitas sistem file.

Metadata untuk file yang diekspor

Ketika file diekspor dari sistem file Azure Managed Lustre ke kontainer blob, metadata tambahan disimpan untuk menyederhanakan reimportasi konten ke sistem file.

Tabel berikut mencantumkan atribut POSIX dari sistem file Lustre yang disimpan dalam metadata blob sebagai pasangan kunci-nilai:

Atribut POSIX	Jenis
owner	int
group	int
permissions	format oktal atau rwxrwxrwx; bit lengket didukung

Atribut direktori disimpan dalam blob kosong. Blob ini memiliki nama yang sama dengan jalur direktori dan berisi pasangan kunci-nilai berikut dalam metadata blob: hdi_isfolder : true.

Anda dapat memodifikasi atribut POSIX secara manual sebelum menggunakan kontainer untuk menghidrasi kluster Lustre baru. Edit atau tambahkan metadata blob dengan menggunakan pasangan kunci-nilai yang dijelaskan sebelumnya.

Pertimbangan untuk pekerjaan ekspor

Item berikut penting untuk dipertimbangkan saat mengekspor data dengan pekerjaan ekspor:

• Hanya satu tindakan impor atau ekspor yang dapat berjalan pada satu waktu. Misalnya, jika pekerjaan ekspor sedang berlangsung, mencoba memulai pekerjaan ekspor lain mengembalikan kesalahan.

Menyalin kontainer blob Lustre dengan AzCopy atau Storage Explorer

Anda dapat memindahkan atau menyalin kontainer blob yang digunakan Lustre dengan menggunakan AzCopy atau Storage Explorer.

Untuk AzCopy, Anda dapat menyertakan atribut direktori dengan menambahkan bendera berikut:

--include-directory-stub

Termasuk bendera ini mempertahankan atribut POSIX direktori selama transfer, misalnya, owner, group, dan permissions. Jika Anda menggunakan azcopy pada kontainer penyimpanan tanpa bendera ini, atau dengan bendera diatur ke false, maka data dan direktori disertakan dalam transfer, tetapi direktori tidak mempertahankan atribut POSIX mereka.

Di Storage Explorer, Anda dapat mengaktifkan bendera ini di Pengaturan dengan memilih Transfer dan mencentang kotak untuk Sertakan Stub Direktori.

Langkah berikutnya

• Prasyarat untuk integrasi penyimpanan blob
• Membuat pekerjaan impor dari Blob Storage ke Azure Managed Lustre
• Membuat pekerjaan ekspor untuk mengekspor data dari Azure Managed Lustre