Azure Yönetilen Lustre ile Azure Blob Depolama kullanma
Azure Managed Lustre, blob kapsayıcısından dosya sistemine veri aktarma işlemini basitleştirmek için Azure Blob Depolama ile tümleşir. Ayrıca, uzun süreli depolama için verileri dosya sisteminden blob kapsayıcısına aktarabilirsiniz. Bu makalede Azure Yönetilen Lustre dosya sistemleriyle blob tümleştirmesi kullanma kavramları açıklanmaktadır.
Uyumlu bir blob kapsayıcısı için gereken gereksinimleri ve yapılandırmayı anlamak için bkz . Blob tümleştirme önkoşulları.
Blob tümleştirmeye genel bakış
Küme oluşturma sırasında blob tümleştirmesini yapılandırabilir ve küme oluşturulduktan sonra istediğiniz zaman bir içeri aktarma işi oluşturabilirsiniz. Veriler içeri aktarıldıktan sonra, diğer dosya sistemi verileriyle olduğu gibi verilerle çalışabilirsiniz. Dosya sisteminde yeni dosyalar oluşturulduktan veya mevcut dosyalar değiştirildiğinde, istemcide Lustre CLI komutlarını çalıştırarak veya dışarı aktarma işlerini kullanarak verileri dışarı aktararak bu dosyaları depolama hesabına geri aktarabilirsiniz.
Blob kapsayıcısından Azure Yönetilen Lustre dosya sistemine veri aktardığınızda, yalnızca dosya adları (ad alanı) ve meta veriler Lustre ad alanına aktarılır. Bir blobun gerçek içeriği, bir istemci tarafından ilk kez erişildiğinde içeri aktarılır. Lustre Hiyerarşik Depolama Yönetimi (HSM) özelliği blob içeriğini dosya sistemindeki ilgili dosyaya çekerken verilere ilk erişirken küçük bir gecikme olur.
Sudo özelliklerine sahip bağlı bir istemciden Lustre'ın lfs hsm_restore komutunu kullanarak blobların içeriğini önceden oluşturabilirsiniz. Daha fazla bilgi edinmek için bkz . Blob Depolamadan verileri geri yükleme.
Azure Managed Lustre, hiyerarşik ad alanı etkinleştirilmiş depolama hesaplarıyla ve hiyerarşik olmayan veya düz ad alanına sahip depolama hesaplarıyla çalışır. Aşağıdaki küçük farklar geçerlidir:
- Hiyerarşik ad alanı etkinleştirilmiş bir depolama hesabı için Azure Yönetilen Lustre, blob üst bilgisinden POSIX özniteliklerini okur.
- Hiyerarşik ad alanı etkin olmayan bir depolama hesabı için Azure Yönetilen Lustre, blob meta verilerinden POSIX özniteliklerini okur. Meta verileri barındırmak için blob kapsayıcınızın içeriğiyle aynı ada sahip ayrı, boş bir dosya oluşturulur. Bu dosya, Azure Yönetilen Lustre dosya sistemindeki gerçek veri dizinine eşdüzeydir.
Blob Depolama'dan içeri aktarma
Küme oluşturma sırasında Blob Depolama ile tümleştirmeyi yapılandırabilir ve küme oluşturulduktan sonra istediğiniz zaman bir içeri aktarma işi oluşturabilirsiniz.
Blob kapsayıcı gereksinimleri
Küme oluşturma sırasında blob tümleştirmesini yapılandırırken iki ayrı blob kapsayıcısı tanımlamanız gerekir: içeri aktaracak kapsayıcı ve günlüğe kaydetme kapsayıcısı. İçeri aktarabileceğiniz kapsayıcı, Azure Yönetilen Lustre dosya sistemine aktarmak istediğiniz verileri içerir. Günlük kapsayıcısı, içeri aktarma işinin günlüklerini depolamak için kullanılır. Bu iki kapsayıcı aynı depolama hesabında olmalıdır. Blob kapsayıcısının gereksinimleri hakkında daha fazla bilgi edinmek için bkz . Blob tümleştirme önkoşulları.
Ön eki içeri aktarma
Blob kapsayıcısından veri içeri aktarırken, isteğe bağlı olarak Azure Yönetilen Lustre dosya sistemine aktarılan verileri filtrelemek için bir veya daha fazla ön ek belirtebilirsiniz. Blob kapsayıcısında ön eklerden biriyle eşleşen dosya adları, dosya sistemindeki bir meta veri kaydına eklenir. İstemci bir dosyaya ilk kez eriştiğinde, içeriği blob kapsayıcısından alınır ve dosya sisteminde depolanır.
Azure portalında, blob kapsayıcınızdan içeri aktarılacak verileri belirtmek için küme oluşturma sırasında Gelişmiş sekmesindeki önek içeri aktar alanlarını kullanın. Bu alanlar yalnızca ilk içeri aktarma işi için geçerlidir. Küme oluşturulduktan sonra içeri aktarma ön ekini değiştiremezsiniz.
İçeri aktarma işi için, işi oluştururken içeri aktarma ön eklerini belirtebilirsiniz. Azure portalından İçeri aktarma ön eklerini İçeri aktarma ön ekleri alanlarında belirtebilirsiniz. İçeri aktarma işi oluşturmak için REST API'sini kullanırken içeri aktarma ön ekini de belirtebilirsiniz.
İçeri aktarma ön eklerini belirtirken aşağıdaki noktaları göz önünde bulundurun:
- Varsayılan içeri aktarma ön eki şeklindedir
/. Bu varsayılan davranış blob kapsayıcısının tamamını içeri aktarır. - Birden çok ön ek belirtirseniz, ön eklerin çakışmamış olması gerekir. Örneğin, ve
/data2belirtirseniz/data, önekler çakıştığı için içeri aktarma işi başarısız olur. - Blob kapsayıcısı hiyerarşik ad alanı etkinleştirilmiş bir depolama hesabındaysa, ön eki bir dosya yolu olarak düşünebilirsiniz. Yol altındaki öğeler Azure Yönetilen Lustre dosya sistemine dahil edilir.
- Blob kapsayıcısı hiyerarşik olmayan (veya düz) bir ad alanına sahip bir depolama hesabındaysa, içeri aktarma ön ekini blob adının başlangıcıyla karşılaştırılan bir arama dizesi olarak düşünebilirsiniz. Kapsayıcıdaki bir blobun adı içeri aktarma ön eki olarak belirttiğiniz dizeyle başlıyorsa, bu dosya dosya sisteminde erişilebilir hale getirilir. Lustre hiyerarşik bir dosya sistemidir ve
/blob adlarındaki karakterler, Lustre'da depolandığında dizin sınırlayıcıları haline gelir.
Çakışma çözümleme modu
Blob kapsayıcısından verileri içeri aktarırken, blob kapsayıcısı ile dosya sistemi arasındaki çakışmaların nasıl işleneceğini belirtebilirsiniz. Bu seçenek yalnızca mevcut kümeler için çalıştırılacak içeri aktarma işleri için geçerlidir. Aşağıdaki tabloda kullanılabilir çakışma çözümleme modları ve bunların açıklamaları gösterilmektedir:
| Mod | Açıklama |
|---|---|
fail |
Çakışma algılanırsa içeri aktarma işi hemen bir hatayla başarısız olur. |
skip |
Çakışma algılanırsa içeri aktarma işi dosyayı atlar. |
overwrite-dirty |
İçeri aktarma işi, silinip yeniden içeri aktarılıp aktarılmaması gerektiğini görmek için çakışan bir yolu değerlendirir. Daha fazla bilgi edinmek için bkz . Kirli modun üzerine yazma. |
overwrite-always |
İçeri aktarma işi çakışan bir yolu değerlendirir ve kirliyse her zaman siler/yeniden içeri aktarır veya temizse serbest bırakır. Daha fazla bilgi edinmek için bkz . Her zaman modunun üzerine yazma. |
Kirli modun üzerine yazma
Mod overwrite-dirty , silinip yeniden içeri aktarılıp aktarılmaması gerektiğini görmek için çakışan bir yolu değerlendirir. Yüksek düzeyde, overwrite-dirty mod HSM durumunu denetler. HSM durumu Temiz ve Arşivlenmiş ise, yani verileri Lustre'ın anabildiği kadar blob kapsayıcısıyla eşitlenmişse, gerekirse yalnızca öznitelikler güncelleştirilir. Aksi takdirde, dosya silinir ve blob kapsayıcısından yeniden içeri aktarılır.
HSM durumunun denetlenmesi, Lustre'daki dosyanın blob kapsayıcısında dosyayla eşleştiğinden emin değildir. Lustre'daki dosyanın blob kapsayıcısında bulunan dosyayla mümkün olduğunca yakından eşleştiğinden overwrite-always emin olmanız gerekiyorsa modu kullanın.
Her zaman modunun üzerine yaz
Mod overwrite-always çakışan bir yolu değerlendirir ve kirliyse her zaman siler/yeniden içeri aktarır veya temizse serbest bırakır. Bu mod, dosya sisteminin her zaman blob kapsayıcısıyla eşitlendiğinden emin olmak istediğinizde kullanışlıdır. Ayrıca, daha önce geri yüklenen her dosya ilk erişimde serbest bırakıldığı veya silindiği/yeniden içeri aktarıldığı için en pahalı seçenektir.
Hataya dayanıklılık
Blob kapsayıcısından verileri içeri aktarırken hataya dayanıklılık belirtebilirsiniz. Hataya dayanıklılık düzeyi, içeri aktarma işinin içeri aktarma işlemi sırasında oluşan işletim sistemi hataları veya ağ kesintileri gibi geçici hataları nasıl işlediğini belirler. Bu bağlamdaki hataların, çakışma çözümleme modu tarafından işlenen dosya çakışmalarına başvurmadığını unutmayın.
İçeri aktarma işleri için aşağıdaki hataya dayanıklılık seçenekleri sağlanır:
- Hatalara izin verme (varsayılan): İçeri aktarma işlemi sırasında herhangi bir hata oluşursa içeri aktarma işi hemen başarısız olur. Bu varsayılan davranıştır.
- Hatalara izin ver: Bir hata oluşursa ve hata günlüğe kaydedilirse içeri aktarma işi devam eder. İçeri aktarma işi tamamlandıktan sonra günlük kapsayıcısında hataları görüntüleyebilirsiniz.
Blob içeri aktarma işleri için dikkat edilmesi gerekenler
Blob kapsayıcısından veri içeri aktarılırken aşağıdaki öğelerin dikkate alınması önemlidir:
- Aynı anda yalnızca bir içeri veya dışarı aktarma eylemi çalıştırılabilir. Örneğin, devam eden bir içeri aktarma işi varsa, başka bir içeri aktarma işi başlatma girişimi bir hata döndürür.
- İçeri aktarma işleri iptal edilebilir. Var olan bir kümede başlatılan bir içeri aktarma işini veya küme oluşturma sırasında başlatılan içeri aktarma işini iptal edebilirsiniz.
- Küme dağıtımı, karşılık gelen içeri aktarma işi tamamlanmadan önce başarıyla döndürülebilir. İçeri aktarma işi arka planda çalışmaya devam eder. İçeri aktarma işinin ilerleme durumunu aşağıdaki yollarla izleyebilirsiniz:
- Azure portalı: Azure portalı içeri aktarma işinin durumunu görüntüler. İçeri aktarma işinin durumunu görüntülemek için dosya sistemine gidin ve Blob tümleştirmesi'ni seçin.
- Kök dizinde Lustre dosyası: şuna benzer
/lustre/IMPORT_<state>.<timestamp_start>adlı bir dosya, içeri aktarma sırasında Lustre kök dizininde oluşturulur. İçeri<state>aktarma işlemi ilerledikçe yer tutucu değişir. İçeri aktarma işi başarıyla tamamlandığında dosya silinir.
- Tamamlanmış bir içeri aktarma işiyle ilgili ayrıntıları görüntülemek için günlük kapsayıcısını de kontrol edebilirsiniz. Günlük kapsayıcısı, içeri aktarma işlemi sırasında oluşan hatalar veya çakışmalar dahil olmak üzere içeri aktarma işinin günlüklerini içerir.
- İçeri aktarma işi herhangi bir nedenle başarısız olursa, içeri aktarılan dosya sayısı veya çakışma sayısı gibi içeri aktarma işiyle ilgili tam istatistikleriniz olmayabilir.
Blob Depolama'dan verileri geri yükleme
Varsayılan olarak, bir blobun içeriği bir istemci tarafından ilgili dosyaya ilk kez erişildiğinde dosya sistemine aktarılır. Belirli iş yükleri ve senaryolar için, blob kapsayıcısına ilk kez erişmeden önce verileri geri yüklemeyi tercih edebilirsiniz. İçeri aktarma işleminden sonra bloba ilk kez erişildiğinde ilk gecikmeyi önlemek için blobların içeriğini önceden oluşturmayı seçebilirsiniz. Blobların içeriğini önceden oluşturmak için, sudo özelliklerine sahip bağlı bir istemciden Lustre'ın lfs hsm_restore komutunu kullanabilirsiniz. Aşağıdaki komut blobların içeriğini dosya sistemine önceden ekler:
nohup find local/directory -type f -print0 | xargs -0 -n 1 sudo lfs hsm_restore &
Bu komut meta veri sunucusuna bir geri yükleme isteğini zaman uyumsuz olarak işlemesini söyler. Komut satırı geri yüklemenin tamamlanmasını beklemez; bu da komut satırının meta veri sunucusunda geri yükleme için çok sayıda girdiyi kuyruğa ekleme olasılığına sahip olduğu anlamına gelir. Bu yaklaşım meta veri sunucusunu bunaltabilir ve geri yüklemeler için performansı düşürebilir.
Bu olası performans sorununu önlemek için, yolu yürümeyi deneyen ve belirtilen boyutta toplu geri yükleme istekleri veren temel bir betik oluşturabilirsiniz. Makul bir performans elde etmek ve meta veri sunucusunu aşırıya kaçmak için 1.000 ile 5.000 arasında herhangi bir yerde toplu iş boyutlarının kullanılması önerilir.
Örnek: Toplu geri yükleme betiği oluşturma
Aşağıdaki örnekte, toplu olarak blob kapsayıcısından verileri geri yüklemek için betiğin nasıl oluşturulacağı gösterilmektedir. Aşağıdaki içeriklere sahip adlı file_restorer.bash bir dosya oluşturun:
#!/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 "$@"
Aşağıdaki örnekte betiğin örnek çıktıyla birlikte nasıl çalıştırılacakları gösterilmektedir:
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
Not
Şu anda Azure Yönetilen Lustre, Blob Depolama'dan ~7,5GiB/saniye maksimum aktarım hızıyla verileri geri yükler.
Dışarı aktarma işini kullanarak verileri Blob Depolama'ya aktarma
Dışarı aktarma işi oluşturarak Azure Yönetilen Lustre dosya sisteminizdeki verileri Azure Blob Depolama'daki uzun vadeli depolama alanına kopyalayabilirsiniz.
Dışarı aktarma işi sırasında hangi dosyalar dışarı aktarılır?
Azure Yönetilen Lustre sisteminizdeki dosyaları dışarı aktardığınızda, tüm dosyalar dosya sistemini oluştururken belirttiğiniz blob kapsayıcısına kopyalanmaz. Dışarı aktarma işleri için aşağıdaki kurallar geçerlidir:
- Dışarı aktarma işleri yalnızca yeni veya içeriği değiştirilmiş dosyaları kopyalar. Dosya sistemi oluşturma sırasında blob kapsayıcısından içeri aktardığınız dosya değişmezse, dışarı aktarma işi dosyayı dışarı aktarmaz.
- Yalnızca meta veri değişiklikleri olan dosyalar dışarı aktarılamaz. Meta veri değişiklikleri şunlardır: sahip, izinler, genişletilmiş öznitelikler ve ad değişiklikleri (yeniden adlandırıldı).
- Azure Yönetilen Lustre dosya sisteminde silinen dosyalar, dışarı aktarma işi sırasında özgün blob kapsayıcısında silinmez. Dışarı aktarma işi blob kapsayıcısında dosyaları silmez.
Etkin dosya sistemlerinde dışarı aktarma işlerini çalıştırma
Etkin dosya sistemlerinde, dışarı aktarma işi sırasında dosyalarda yapılan değişiklikler hata durumuna neden olabilir. Bu hata durumu, dosya sistemindeki tüm verilerin Blob Depolama'ya aktarılamadığını bildirir. Bu durumda, yeni bir dışarı aktarma işi oluşturarak dışarı aktarmayı yeniden deneyebilirsiniz. Yeni iş yalnızca önceki işte kopyalanmış olmayan dosyaları kopyalar.
Çok fazla etkinliği olan dosya sistemlerinde dosyalar sık sık değiştiğinden yeniden denemeler birden çok kez başarısız olabilir. Bir dosyanın Blob Depolama'ya başarıyla aktarıldığını doğrulamak için ilgili blob üzerindeki zaman damgasını denetleyin. İş tamamlandıktan sonra, dışarı aktarma işi hakkındaki ayrıntılı bilgileri görmek için dağıtım zamanında yapılandırılan günlük kapsayıcısını da görüntüleyebilirsiniz. Günlük kapsayıcısı hangi dosyaların başarısız olduğu ve neden başarısız oldukları hakkında tanılama bilgileri sağlar.
Bir kümenin yetkisini almak için hazırlanıyorsanız ve Blob Depolama'ya son dışarı aktarma işlemini gerçekleştirmek istiyorsanız, dışarı aktarma işini başlatmadan önce tüm G/Ç etkinliklerinin durduruldığından emin olmanız gerekir. Bu yaklaşım, dosya sistemi etkinliğinden kaynaklanan hatalardan kaçınarak tüm verilerin dışarı aktarıldığını garanti etmeye yardımcı olur.
Dışarı aktarılan dosyalar için meta veriler
Dosyalar Azure Yönetilen Lustre dosya sisteminden blob kapsayıcısına aktarıldığında, içeriğin bir dosya sistemine yeniden aktarılmasını kolaylaştırmak için ek meta veriler kaydedilir.
Aşağıdaki tabloda blob meta verilerine anahtar-değer çiftleri olarak kaydedilen Lustre dosya sisteminden POSIX öznitelikleri listeleniyor:
| POSIX özniteliği | Tür |
|---|---|
owner |
int |
group |
int |
permissions |
octal veya rwxrwxrwx biçimi; yapışkan bit desteklenir |
Dizin öznitelikleri boş bir bloba kaydedilir. Bu blob dizin yolu ile aynı ada sahiptir ve blob meta verilerinde aşağıdaki anahtar-değer çiftini içerir: hdi_isfolder : true.
Yeni bir Lustre kümesini nemlendirmek için kapsayıcıyı kullanmadan önce POSIX özniteliklerini el ile değiştirebilirsiniz. Daha önce açıklanan anahtar-değer çiftlerini kullanarak blob meta verilerini düzenleyin veya ekleyin.
Dışarı aktarma işleri için dikkat edilmesi gerekenler
Verileri dışarı aktarma işiyle dışarı aktarırken aşağıdaki öğelerin dikkate alınması önemlidir:
- Aynı anda yalnızca bir içeri veya dışarı aktarma eylemi çalıştırılabilir. Örneğin, bir dışarı aktarma işi devam ediyorsa, başka bir dışarı aktarma işi başlatma girişimi bir hata döndürür.
AzCopy veya Depolama Gezgini ile Bir Lustre blob kapsayıcısını kopyalama
AzCopy veya Depolama Gezgini kullanarak Lustre tarafından kullanılan blob kapsayıcısını taşıyabilir veya kopyalayabilirsiniz.
AzCopy için, aşağıdaki bayrağı ekleyerek dizin özniteliklerini ekleyebilirsiniz:
--include-directory-stub
Bu bayrağın dahil etmek, bir aktarım sırasında dizin POSIX özniteliklerini korur, örneğin, owner, groupve permissions. Depolama kapsayıcısında bu bayrak olmadan veya bayrağı olarak ayarlanmış falseolarak kullanıyorsanız azcopy veri ve dizinler aktarıma dahil edilir, ancak dizinler POSIX özniteliklerini korumaz.
Depolama Gezgini'de, Ayarlar'da Aktarımlar'ı seçip Dizin Saptamalarını Ekle kutusunu işaretleyerek bu bayrağı etkinleştirebilirsiniz.
Sonraki adımlar
Geri Bildirim
Çok yakında: 2024 boyunca, içerik için geri bildirim mekanizması olarak GitHub Sorunları’nı kullanımdan kaldıracak ve yeni bir geri bildirim sistemiyle değiştireceğiz. Daha fazla bilgi için bkz. https://aka.ms/ContentUserFeedback.
Gönderin ve geri bildirimi görüntüleyin