Az Azure Blob Storage használata az Azure Managed Lustre használatával

Cikk
01/10/2025

Az Azure Managed Lustre integrálható az Azure Blob Storage-ral, hogy egyszerűbbé tegye az adatok blobtárolóból fájlrendszerbe való importálását. Az adatokat a fájlrendszerből egy blobtárolóba is exportálhatja hosszú távú tárolás céljából. Ez a cikk az Azure Managed Lustre fájlrendszerekkel való blobintegrációval kapcsolatos fogalmakat ismerteti.

A kompatibilis blobtárolókhoz szükséges követelmények és konfiguráció megismeréséhez tekintse meg a Blob-integráció előfeltételeit.

Blobintegráció áttekintése

A blobintegrációt a fürt létrehozása során konfigurálhatja, és a fürt létrehozása után bármikor létrehozhat importálási feladatot. Az adatok importálása után ugyanúgy dolgozhat az adatokkal, mint más fájlrendszerbeli adatokkal. Az új fájlok létrehozásakor vagy a meglévő fájlok a fájlrendszerben való módosításakor exportálhatja ezeket a fájlokat a tárfiókba lustre CLI-parancsok futtatásával az ügyfélen, vagy exportálhatja az adatokat exportálási feladatokkal.

Amikor adatokat importál egy blobtárolóból egy Azure Managed Lustre fájlrendszerbe, a rendszer csak a fájlneveket (névteret) és a metaadatokat importálja a Lustre névtérbe. A blob tényleges tartalma akkor lesz importálva, amikor először fér hozzá egy ügyfél. Az adatok első elérése némi késéssel jár, miközben a Lustre Hierarchical Storage Management (HSM) funkció lekéri a blob tartalmát a fájlrendszer megfelelő fájljához.

A blobok tartalmát előre leküldheti a Lustre lfs hsm_restore parancsával egy csatlakoztatott ügyfélről sudo képességekkel. További információ: Adatok visszaállítása a Blob Storage-ból.

Az Azure Managed Lustre olyan tárfiókokkal működik, amelyek hierarchikus névtérrel rendelkeznek, és a tárfiókok nemarchikus vagy lapos névtérrel rendelkeznek. A következő kisebb különbségek érvényesek:

A hierarchikus névtérrel rendelkező tárfiókok esetében az Azure Managed Lustre beolvassa a POSIX-attribútumokat a blobfejlécből.
A hierarchikus névtérrel nem rendelkező tárfiókok esetében az Azure Managed Lustre beolvassa a POSIX-attribútumokat a blob metaadataiból. A blobtároló tartalmának nevével megegyező nevű különálló, üres fájl jön létre a metaadatok tárolásához. Ez a fájl az Azure Managed Lustre fájlrendszer tényleges adatkönyvtárának testvére.

Importálás a Blob Storage-ból

A blobtárolóval való integrációt a fürt létrehozása során konfigurálhatja, és a fürt létrehozása után bármikor létrehozhat egy importálási feladatot.

Blobtárolókra vonatkozó követelmények

A blobintegráció fürtlétrehozás során történő konfigurálásakor két különálló blobtárolót kell azonosítania: az importálni kívánt tárolót és a naplózási tárolót. Az importálandó tároló tartalmazza azokat az adatokat, amelyeket az Azure Managed Lustre fájlrendszerbe szeretne importálni. A naplózási tároló az importálási feladat naplóinak tárolására szolgál. Ennek a két tárolónak ugyanabban a tárfiókban kell lennie. A blobtároló követelményeiről további információt a Blob-integráció előfeltételei című témakörben talál.

Előtag importálása

Ha blobtárolóból importál adatokat, megadhat egy vagy több előtagot az Azure Managed Lustre fájlrendszerbe importált adatok szűréséhez. A blobtároló egyik előtagjának megfelelő fájlneveket a rendszer egy metaadatrekordhoz adja hozzá a fájlrendszerben. Amikor egy ügyfél először fér hozzá egy fájlhoz, a rendszer lekéri a tartalmát a blobtárolóból, és a fájlrendszerben tárolja.

Az Azure Portalon a Speciális lap Importálás előtagmezőivel adhatja meg a blobtárolóból importálandó adatokat. Ezek a mezők csak a kezdeti importálási feladatra vonatkoznak. A fürt létrehozása után nem módosíthatja az importálási előtagot.

Importálási feladat esetén a feladat létrehozásakor megadhatja az importálási előtagokat. Az Azure Portalon az importálási előtagokat az Importálás előtag mezőkben adhatja meg. Az importálási előtagot akkor is megadhatja, ha a REST API-val hoz létre egy importálási feladatot.

Az importálási előtagok megadásakor tartsa szem előtt az alábbi szempontokat:

Az alapértelmezett importálási előtag a következő /. Ez az alapértelmezett viselkedés importálja a teljes blobtároló tartalmát.
Ha több előtagot ad meg, az előtagok nem fedheti egymást. Ha például megadja /data , és /data2az importálási feladat meghiúsul, mert az előtagok átfedésben vannak.
Ha a blobtároló egy olyan tárfiókban található, amelyen engedélyezve van a hierarchikus névtér, az előtagot fájlútvonalként tekintheti. Az elérési út alatt lévő elemeket az Azure Managed Lustre fájlrendszer tartalmazza.
Ha a blobtároló nemarchikus (vagy lapos) névtérrel rendelkező tárfiókban található, az importálási előtagot keresési sztringként tekintheti, amelyet a blobnév elejével hasonlítunk össze. Ha a tárolóban lévő blob neve az importálási előtagként megadott sztringgel kezdődik, a fájl elérhetővé válik a fájlrendszerben. A Lustre egy hierarchikus fájlrendszer, és / a blobnevekben szereplő karakterek könyvtárelválasztókká válnak, amikor a Lustre-ben tárolják őket.

Ütközésfeloldási mód

Amikor adatokat importál egy blobtárolóból, megadhatja, hogyan kezelheti a blobtároló és a fájlrendszer közötti ütközéseket. Ez a beállítás csak a meglévő fürtökhöz futtatott importálási feladatokra vonatkozik. Az alábbi táblázat az elérhető ütközésfeloldási módokat és azok leírását mutatja be:

Mód	Leírás
`fail`	Az importálási feladat azonnal meghiúsul, ha ütközést észlel.
`skip`	Az importálási feladat kihagyja a fájlt, ha ütközést észlel.
`overwrite-dirty`	Az importálási feladat egy ütköző elérési utat értékel ki annak megtekintéséhez, hogy törölni és újra kell-e importálni. További információ: felülírás-piszkos mód.
`overwrite-always`	Az importálási feladat kiértékel egy ütköző elérési utat, és mindig törli/újra importálja, ha piszkos, vagy ha tiszta. További információ: overwrite-always mode.

Felülírás-piszkos mód

A overwrite-dirty mód egy ütköző elérési utat értékel ki, amely ellenőrzi, hogy törölni kell-e és újra kell-e importálni. Magas szinten a overwrite-dirty mód ellenőrzi a HSM állapotát. Ha a HSM állapota tiszta és archivált, vagyis az adatai szinkronban vannak a blobtárolóval, amennyire a Lustre képes megállapítani, akkor csak az attribútumok frissülnek, ha szükséges. Ellenkező esetben a fájl törlődik, és újraimportálódik a blobtárolóból.

A HSM állapotának ellenőrzése nem garantálja, hogy a Lustre fájlja megegyezik a blobtárolóban lévő fájllal. Ha meg kell győződnie arról, hogy a Lustre fájlja a lehető legszorosabban egyezik a blobtárolóban lévő fájllal, használja a overwrite-always módot.

Felülírás mindig mód

A overwrite-always mód kiértékeli az ütköző útvonalat, és mindig törli/újraimportálásra kerül, ha piszkos, vagy ha tiszta. Ez a mód akkor hasznos, ha biztosítani szeretné, hogy a fájlrendszer mindig szinkronban legyen a blobtárolóval. Ez is a legdrágább lehetőség, mivel minden korábban visszaállított fájl vagy kiadásra kerül, vagy az első hozzáféréskor törlődik/újra importálódik.

Hibatűrés

Amikor adatokat importál egy blobtárolóból, megadhatja a hibatűrést. A hibatűrési szint határozza meg, hogy az importálási feladat hogyan kezeli az importálási folyamat során előforduló átmeneti hibákat, például az operációs rendszer hibáit vagy a hálózat megszakadását. Fontos megjegyezni, hogy az ebben a környezetben előforduló hibák nem hivatkoznak fájlütközésekre, amelyeket az ütközésfeloldási mód kezel.

Importálási feladatokhoz a következő hibatűrési beállítások érhetők el:

Ne engedélyezze a hibákat (alapértelmezett): Az importálási feladat azonnal meghiúsul, ha hiba történik az importálás során. Ez a viselkedés az alapértelmezett.
Hibák engedélyezése: Az importálási feladat hiba esetén folytatódik, és a hiba naplózása megtörténik. Az importálási feladat befejeződése után megtekintheti a naplózási tároló hibáit.

A blobimportálási feladatok szempontjai

A blobtárolóból származó adatok importálásakor a következő elemeket érdemes figyelembe venni:

Egyszerre csak egy importálási vagy exportálási művelet futtatható. Ha például egy importálási feladat folyamatban van, egy másik importálási feladat indításának kísérlete hibaüzenetet ad vissza.
Az importálási feladatok megszakíthatók. Megszakíthatja a meglévő fürtön elindított importálási feladatot, vagy a fürt létrehozása során kezdeményezett importálási feladatot.
A fürt üzembe helyezése sikeresen visszatérhet, mielőtt a megfelelő importálási feladat befejeződne. Az importálási feladat továbbra is a háttérben fut. Az importálási feladat előrehaladását az alábbi módokon figyelheti:
- Azure Portal: Az Azure Portal megjeleníti az importálási feladat állapotát. Lépjen a fájlrendszerre, és válassza a Blob-integráció lehetőséget az importálási feladat állapotának megtekintéséhez.
- Lustre-fájl a gyökérkönyvtárban: Az importálás során a Lustre gyökérkönyvtárban létrejön egy hasonló /lustre/IMPORT_<state>.<timestamp_start> nevű fájl. A <state> helyőrző az importálás előrehaladásával változik. A fájl az importálási feladat sikeres befejezésekor törlődik.
A befejezett importálási feladat részleteinek megtekintéséhez ellenőrizze a naplózási tárolót. A naplózási tároló naplókat tartalmaz az importálási feladathoz, beleértve az importálás során előforduló hibákat vagy ütközéseket.
Ha az importálási feladat bármilyen okból meghiúsul, előfordulhat, hogy nem rendelkezik az importálási feladat teljes statisztikáival, például az importált fájlok számával vagy az ütközések számával.

Adatok visszaállítása a Blob Storage-ból

Alapértelmezés szerint a blob tartalma a megfelelő fájl ügyfél általi első elérésekor importálódik a fájlrendszerbe. Bizonyos számítási feladatok és forgatókönyvek esetében érdemes lehet visszaállítani az adatokat egy blobtárolóból az első hozzáférés előtt. Dönthet úgy, hogy előre leküldi a blobok tartalmát, hogy elkerülje a kezdeti késést, amikor a blob első alkalommal érhető el az importálás után. A blobok tartalmának előkezeléséhez használhatja a Lustre parancsát lfs hsm_restore egy csatlakoztatott ügyfélről sudo képességekkel. A következő parancs előre leküldi a blobok tartalmát a fájlrendszerbe:

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

Ez a parancs arra utasítja a metaadat-kiszolgálót, hogy aszinkron módon dolgozza fel a visszaállítási kérést. A parancssor nem várja meg a visszaállítás befejezését, ami azt jelenti, hogy a parancssor nagy számú bejegyzést képes várólistára állítani a metaadat-kiszolgálón. Ez a megközelítés túlterhelheti a metaadat-kiszolgálót, és csökkentheti a visszaállítások teljesítményét.

A lehetséges teljesítményprobléma elkerülése érdekében létrehozhat egy alapszintű szkriptet, amely megpróbálja végigvezetni az elérési utat, és egy megadott méretű kötegekben problémákat okoz a visszaállítási kérelmekben. Az ésszerű teljesítmény és a metaadat-kiszolgáló túlterhelésének elkerülése érdekében javasoljuk, hogy 1000 és 5000 kérés között bárhol használjon kötegméreteket.

Példa: Köteg-visszaállítási szkript létrehozása

Az alábbi példa bemutatja, hogyan hozhat létre szkriptet egy blobtárolóból származó adatok kötegelt visszaállításához. Hozzon létre egy fájlt file_restorer.bash a következő tartalommal:

#!/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 "$@"

Az alábbi példa bemutatja, hogyan futtathatja a szkriptet a mintakimenettel együtt:

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

Feljegyzés

Az Azure Managed Lustre jelenleg ~7,5GiB/másodperces maximális átviteli sebességgel állítja vissza az adatokat a Blob Storage-ból.

Adatok exportálása Blob Storage-ba exportálási feladattal

Exportálási feladat létrehozásával adatokat másolhat az Azure Managed Lustre fájlrendszerből az Azure Blob Storage hosszú távú tárolóiba.

Mely fájlokat exportálja a rendszer egy exportálási feladat során?

Amikor fájlokat exportál az Azure Managed Lustre rendszerből, a rendszer nem minden fájlt másol a fájlrendszer létrehozásakor megadott blobtárolóba. Az exportálási feladatokra a következő szabályok vonatkoznak:

Az exportálási feladatok csak olyan fájlokat másolnak, amelyek újak, vagy amelyek tartalma módosul. Ha a blobtárolóból a fájlrendszer létrehozása során importált fájl nem változik, az exportálási feladat nem exportálja a fájlt.
A metaadat-módosításokat tartalmazó fájlok nem exportálhatók. A metaadatok módosításai a következők: tulajdonos, engedélyek, kiterjesztett attribútumok és névmódosítások (átnevezve).
Az Azure Managed Lustre fájlrendszerben törölt fájlok nem törlődnek az eredeti blobtárolóban az exportálási feladat során. Az exportálási feladat nem törli a blobtárolóban lévő fájlokat.
A blobneveknek meg kell felelniük bizonyos elnevezési szabályoknak, ami azt jelenti, hogy az elfogadható blobnevek kissé eltérnek az elfogadható POSIX-fájlnevektől. Az exportálási folyamat megőrzi a speciális karaktereket a fájlnevekben, miközben a blobokra történő exportálás során megfelelően kódolja őket. Ha azonban egy fájlnév megsért egy blobnév-szabályt, például egy olyan fájlnevet, amely túllépi a blobnév maximális hosszát, hiba történik a fájl exportálása során.

Exportálási feladatok futtatása aktív fájlrendszerekben

Az aktív fájlrendszerekben az exportálási feladat során a fájlok módosítása sikertelen állapotot eredményezhet. Ez a hibaállapot tudatja Önvel, hogy a fájlrendszer nem minden adata exportálható a Blob Storage-ba. Ebben az esetben egy új exportálási feladat létrehozásával próbálkozhat újra az exportálással. Az új feladat csak azokat a fájlokat másolja át, amelyeket az előző feladat nem másolt.

A sok tevékenységet tartalmazó fájlrendszerekben az újrapróbálkozások többször is meghiúsulhatnak, mert a fájlok gyakran változnak. Ha ellenőrizni szeretné, hogy egy fájl sikeresen exportálva lett-e a Blob Storage-ba, ellenőrizze a megfelelő blob időbélyegét. A feladat befejezése után az üzembe helyezéskor konfigurált naplózási tárolót is megtekintheti az exportálási feladat részletes információinak megtekintéséhez. A naplózási tároló diagnosztikai információkat nyújt arról, hogy mely fájlok és miért nem sikerültek.

Ha egy fürt leszerelésére készül, és végső exportálást szeretne végrehajtani a Blob Storage-ba, győződjön meg arról, hogy az exportálási feladat elindítása előtt minden I/O-tevékenység leáll. Ez a megközelítés segít garantálni, hogy az összes adat exportálása a fájlrendszer-tevékenységből eredő hibák elkerülésével történik.

Exportált fájlok metaadatai

Ha a fájlokat az Azure Managed Lustre fájlrendszerből a blobtárolóba exportálja, a rendszer további metaadatokat ment, hogy egyszerűbb legyen a tartalom fájlrendszerbe való újraimportálása.

Az alábbi táblázat a Lustre fájlrendszer POSIX-attribútumait sorolja fel, amelyek kulcs-érték párokként vannak mentve a blob metaadataiban:

POSIX attribútum	Típus
`owner`	egész
`group`	egész
`permissions`	oktális vagy rwxrwxrwx formátum; a ragadós bit támogatott

A címtárattribútumok egy üres blobba vannak mentve. Ez a blob neve megegyezik a címtár elérési útjának nevével, és a blob metaadataiban a következő kulcs-érték párot tartalmazza: hdi_isfolder : true.

A POSIX-attribútumokat manuálisan is módosíthatja, mielőtt a tárolóval hidratálhat egy új Lustre-fürtöt. A blob metaadatainak szerkesztése vagy hozzáadása a korábban ismertetett kulcs-érték párok használatával.

Az exportálási feladatok szempontjai

Az exportálási feladattal rendelkező adatok exportálásakor az alábbi elemeket érdemes figyelembe venni:

Egyszerre csak egy importálási vagy exportálási művelet futtatható. Ha például egy exportálási feladat folyamatban van, egy másik exportálási feladat indításának kísérlete hibaüzenetet ad vissza.

Lustre blobtároló másolása az AzCopy vagy a Storage Explorer használatával

Az AzCopy vagy a Storage Explorer használatával áthelyezheti vagy másolhatja a Lustre által használt blobtárolót.

Az AzCopy esetében a címtárattribútumokat a következő jelölő hozzáadásával vehet fel:

--include-directory-stub

Ez a jelző megőrzi a címtár POSIX attribútumait az átvitel során, ownerpéldául , groupés permissions. Ha a tárolóban a jelölő nélkül vagy a jelölő beállítása azcopynélkül használjafalse, akkor az adatok és könyvtárak szerepelnek az átvitelben, de a könyvtárak nem őrzik meg a POSIX-attribútumaikat.

A Storage Explorerben engedélyezheti ezt a jelzőt a Beállításokban az Átvitelek lehetőség kiválasztásával, majd a Címtár-csonkok belefoglalása jelölőnégyzet bejelölésével.

Megosztás a következőn keresztül: