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


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

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 nem hierarchikus 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 lehetnek átfedésben. 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ó nem hierarchikus (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 az alapértelmezett viselkedés.
  • 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 elérése és a metaadat-kiszolgáló túlterhelésének elkerülése érdekében ajánlott 1000-től 5000 kérésig bárhol kötegelt méretet használni.

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.

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 falsenélkül használjaazcopy, 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.

Képernyőkép a címtár-csonkok átvitel közbeni hozzáadásáról a Storage Explorerben.

Következő lépések