Použití služby Azure Blob Storage se spravovaným lustrem Azure

Článek
06/06/2024

Azure Managed Lustre se integruje se službou Azure Blob Storage, která zjednodušuje proces importu dat z kontejneru objektů blob do systému souborů. Data ze systému souborů můžete také exportovat do kontejneru objektů blob pro dlouhodobé úložiště. Tento článek vysvětluje koncepty použití integrace objektů blob se systémy souborů Azure Managed Lustre.

Informace o požadavcích a konfiguraci potřebných pro kompatibilní kontejner objektů blob najdete v požadavcích na integraci objektů blob.

Přehled integrace objektů blob

Integraci objektů blob můžete nakonfigurovat při vytváření clusteru a po vytvoření clusteru můžete kdykoli vytvořit úlohu importu. Po importu dat můžete s daty pracovat stejně jako s jinými daty systému souborů. Při vytváření nových souborů nebo úpravách existujících souborů v systému souborů můžete tyto soubory exportovat zpět do účtu úložiště spuštěním příkazů Rozhraní příkazového řádku Lustre na klientovi nebo exportem dat pomocí úloh exportu.

Při importu dat z kontejneru objektů blob do systému souborů Azure Managed Lustre se do oboru názvů Lustre naimportují jenom názvy souborů (obor názvů) a metadata. Skutečný obsah objektu blob se naimportuje při prvním přístupu klienta. Při prvním přístupu k datům dojde k mírnému zpoždění při prvním přístupu k datům, zatímco funkce Lustre Hierarchical Storage Management (HSM) načítá obsah objektů blob do odpovídajícího souboru v systému souborů.

Obsah objektů blob můžete předem načíst pomocí příkazu Lustre lfs hsm_restore z připojeného klienta s možnostmi sudo. Další informace najdete v tématu Obnovení dat ze služby Blob Storage.

Spravovaná lustre Azure funguje s účty úložiště s povoleným hierarchickým oborem názvů a účty úložiště s ne hierarchickým nebo plochým oborem názvů. Platí následující menší rozdíly:

Pro účet úložiště s povoleným hierarchickým oborem názvů služba Azure Managed Lustre čte atributy POSIX z hlavičky objektu blob.
Pro účet úložiště, který nemá povolený hierarchický obor názvů, služba Azure Managed Lustre čte atributy POSIX z metadat objektů blob. Vytvoří se samostatný prázdný soubor se stejným názvem jako obsah kontejneru objektů blob, který bude obsahovat metadata. Tento soubor je na stejné straně jako skutečný datový adresář v systému souborů Azure Managed Lustre.

Import ze služby Blob Storage

Integraci se službou Blob Storage můžete nakonfigurovat během vytváření clusteru a po vytvoření clusteru můžete vytvořit úlohu importu.

Požadavky na kontejner objektů blob

Při konfiguraci integrace objektů blob během vytváření clusteru musíte identifikovat dva samostatné kontejnery objektů blob: kontejner pro import a kontejner protokolování. Kontejner, který chcete importovat, obsahuje data, která chcete importovat do systému souborů Azure Managed Lustre. Kontejner protokolování se používá k ukládání protokolů pro úlohu importu. Tyto dva kontejnery musí být ve stejném účtu úložiště. Další informace opožadavch

Předpona importu

Při importu dat z kontejneru objektů blob můžete volitelně zadat jednu nebo více předpon pro filtrování dat importovaných do systému souborů Azure Managed Lustre. Názvy souborů v kontejneru objektů blob, které odpovídají jedné z předpon, se přidají do záznamu metadat v systému souborů. Když klient poprvé přistupuje k souboru, jeho obsah se načte z kontejneru objektů blob a uloží se do systému souborů.

Na webu Azure Portal použijte pole Předpona importu na kartě Upřesnit během vytváření clusteru a určete data, která se mají importovat z kontejneru objektů blob. Tato pole platí jenom pro počáteční úlohu importu. Po vytvoření clusteru nemůžete změnit předponu importu.

Pro úlohu importu můžete při vytváření úlohy zadat předpony importu. Na webu Azure Portal můžete v polích Import předpon zadat předpony importu. Předponu importu můžete také zadat při vytvoření úlohy importu pomocí rozhraní REST API.

Při zadávání předpon importu mějte na paměti následující skutečnosti:

Výchozí předpona importu je /. Toto výchozí chování importuje obsah celého kontejneru objektů blob.
Pokud zadáte více předpon, musí se předpony překrývat. Pokud například zadáte /data a /data2úloha importu selže, protože se předpony překrývají.
Pokud je kontejner objektů blob v účtu úložiště s povoleným hierarchickým oborem názvů, můžete si předponu představit jako cestu k souboru. Položky pod cestou jsou součástí systému souborů Azure Managed Lustre.
Pokud je kontejner objektů blob v účtu úložiště s ne hierarchickým (nebo plochým) oborem názvů, můžete si předponu importu představit jako hledaný řetězec, který se porovná se začátkem názvu objektu blob. Pokud název objektu blob v kontejneru začíná řetězcem, který jste zadali jako předponu importu, bude tento soubor přístupný v systému souborů. Lustre je hierarchický systém souborů a / znaky v názvech objektů blob se při uložení v Lustre stanou oddělovači adresářů.

Režim řešení konfliktů

Při importu dat z kontejneru objektů blob můžete určit, jak zpracovávat konflikty mezi kontejnerem objektů blob a systémem souborů. Tato možnost platí jenom pro úlohy importu, které se spouštějí pro existující clustery. Následující tabulka uvádí dostupné režimy řešení konfliktů a jejich popisy:

Režim	Popis
`fail`	Úloha importu se okamžitě nezdaří s chybou, pokud se zjistí konflikt.
`skip`	Úloha importu přeskočí soubor, pokud se zjistí konflikt.
`overwrite-dirty`	Úloha importu vyhodnotí konfliktní cestu a zjistí, jestli se má odstranit a znovu importovat. Další informace najdete v tématu přepsání nezašpiněného režimu.
`overwrite-always`	Úloha importu vyhodnotí konfliktní cestu a vždy odstraní nebo znovu naimportuje, pokud je zašpiněná, nebo uvolní, pokud je čistá. Další informace najdete v režimu přepisování vždy.

Přepsat zašpiněný režim

Režim overwrite-dirty vyhodnotí konfliktní cestu, abyste zjistili, jestli se má odstranit a znovu importovat. Na vysoké úrovni overwrite-dirty režim kontroluje stav HSM. Pokud je stav HSM Čistý a Archivovaný, což znamená, že se její data synchronizují s kontejnerem objektů blob, pokud to lustre zjistí, aktualizují se v případě potřeby pouze atributy. V opačném případě se soubor odstraní a znovu naimportuje z kontejneru objektů blob.

Kontrola stavu HSM nezaručuje, že soubor v Lustre odpovídá souboru v kontejneru objektů blob. Pokud musíte zajistit, aby soubor v Lustre co nejblíže odpovídal souboru v kontejneru objektů blob, použijte overwrite-always režim.

Přepsat režim vždy

Režim overwrite-always vyhodnocuje konfliktní cestu a vždy odstraní/znovu importuje, pokud je zašpiněná, nebo uvolní, pokud je čistá. Tento režim je užitečný, pokud chcete zajistit, aby systém souborů byl vždy synchronizovaný s kontejnerem objektů blob. Je to také nejdražší možnost, protože při prvním přístupu se uvolní nebo znovu naimportuje každý dříve obnovený soubor.

Tolerance chyb

Při importu dat z kontejneru objektů blob můžete určit odolnost proti chybám. Úroveň tolerance chyb určuje, jak úloha importu zpracovává přechodné chyby, ke kterým dochází během procesu importu, například chyby operačního systému nebo přerušení sítě. Je důležité si uvědomit, že chyby v tomto kontextu neodkazují na konflikty souborů, které zpracovává režim řešení konfliktů.

Pro úlohy importu jsou k dispozici následující možnosti odolnosti proti chybám:

Nepovolujte chyby (výchozí): Úloha importu se okamžitě nezdaří, pokud během importu dojde k nějaké chybě. Toto je výchozí chování.
Povolit chyby: Úloha importu bude pokračovat, pokud dojde k chybě a chyba se zaprotokoluje. Po dokončení úlohy importu můžete zobrazit chyby v kontejneru protokolování.

Důležité informace o úlohách importu objektů blob

Při importu dat z kontejneru objektů blob je důležité zvážit následující položky:

Najednou může běžet jenom jedna akce importu nebo exportu. Pokud například probíhá úloha importu, pokus o spuštění jiné úlohy importu vrátí chybu.
Úlohy importu je možné zrušit. Můžete zrušit úlohu importu spuštěnou v existujícím clusteru nebo úlohu importu zahájenou během vytváření clusteru.
Nasazení clusteru se může úspěšně vrátit před dokončením odpovídající úlohy importu. Úloha importu se bude dál spouštět na pozadí. Průběh úlohy importu můžete sledovat následujícími způsoby:
- Azure Portal: Azure Portal zobrazuje stav úlohy importu. Přejděte do systému souborů a výběrem integrace objektů blob zobrazte stav úlohy importu.
- Lustre soubor v kořenovém adresáři: Během importu se vytvoří soubor podobný /lustre/IMPORT_<state>.<timestamp_start> souboru v kořenovém adresáři Lustre. Zástupný <state> symbol se při průběhu importu změní. Soubor se odstraní po úspěšném dokončení úlohy importu.
Pokud chcete zobrazit podrobnosti o dokončené úloze importu, můžete zkontrolovat kontejner protokolování. Kontejner protokolování obsahuje protokoly pro úlohu importu, včetně chyb nebo konfliktů, ke kterým došlo během importu.
Pokud se úloha importu z nějakého důvodu nezdaří, pravděpodobně nemáte úplné statistiky o úloze importu, například počet importovaných souborů nebo počet konfliktů.

Obnovení dat ze služby Blob Storage

Ve výchozím nastavení se obsah objektu blob importuje do systému souborů při prvním přístupu k odpovídajícímu souboru klientem. U některých úloh a scénářů můžete před prvním přístupem raději obnovit data z kontejneru objektů blob. Můžete se rozhodnout předem načíst obsah objektů blob, abyste se vyhnuli počátečnímu zpoždění při prvním přístupu k objektu blob po importu. K předběžnému načtení obsahu objektů blob můžete použít příkaz Lustre lfs hsm_restore z připojeného klienta s možnostmi sudo. Následující příkaz předem načte obsah objektů blob do systému souborů:

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

Tento příkaz serveru metadat říká, aby asynchronně zpracovával požadavek na obnovení. Příkazový řádek nečeká na dokončení obnovení, což znamená, že příkazový řádek může za frontu vytvořit frontu velkého počtu položek pro obnovení na serveru metadat. Tento přístup může zahltit server metadat a snížit výkon obnovení.

Abyste se tomuto potenciálnímu problému s výkonem vyhnuli, můžete vytvořit základní skript, který se pokusí projít cestu a problémy s požadavky na obnovení v dávkách zadané velikosti. Pokud chcete dosáhnout přiměřeného výkonu a vyhnout se zahlcení serveru metadat, doporučujeme použít velikosti dávek kdekoli od 1 000 do 5 000 požadavků.

Příklad: Vytvoření skriptu dávkového obnovení

Následující příklad ukazuje, jak vytvořit skript pro obnovení dat z kontejneru objektů blob v dávkách. Vytvořte soubor s názvem file_restorer.bash s následujícím obsahem:

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

Následující příklad ukazuje, jak spustit skript spolu s ukázkovým výstupem:

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

Poznámka:

V tuto chvíli služba Azure Managed Lustre obnoví data ze služby Blob Storage s maximální propustností přibližně 7,5GiB za sekundu.

Export dat do služby Blob Storage pomocí úlohy exportu

Data ze systému souborů Managed Lustre Azure můžete kopírovat do dlouhodobého úložiště ve službě Azure Blob Storage vytvořením úlohy exportu.

Které soubory se exportují během úlohy exportu?

Při exportu souborů ze systému Azure Managed Lustre se ne všechny soubory zkopírují do kontejneru objektů blob, který jste zadali při vytváření systému souborů. Pro úlohy exportu platí následující pravidla:

Úlohy exportují jenom soubory, které jsou nové nebo jejichž obsah se mění. Pokud se soubor, který jste importovali z kontejneru objektů blob během vytváření systému souborů, nezmění, úloha exportu soubor neexportuje.
Soubory se změnami metadat se neexportují. Mezi změny metadat patří: vlastník, oprávnění, rozšířené atributy a změny názvů (přejmenováno).
Soubory odstraněné v systému souborů Azure Managed Lustre se během úlohy exportu neodstraní v původním kontejneru objektů blob. Úloha exportu neodstraní soubory v kontejneru objektů blob.

Spouštění úloh exportu v aktivních systémech souborů

V aktivních systémech souborů můžou změny souborů během úlohy exportu vést ke stavu selhání. Tento stav selhání vám umožní zjistit, že ne všechna data v systému souborů se dají exportovat do služby Blob Storage. V takovém případě můžete export zopakovat vytvořením nové úlohy exportu. Nová úloha zkopíruje jenom soubory, které nebyly zkopírovány v předchozí úloze.

V systémech souborů s velkým množstvím aktivit může opakování selhat několikrát, protože se často mění soubory. Pokud chcete ověřit, že se soubor úspěšně exportoval do služby Blob Storage, zkontrolujte časové razítko odpovídajícího objektu blob. Po dokončení úlohy můžete také zobrazit kontejner protokolování nakonfigurovaný v době nasazení a zobrazit podrobné informace o úloze exportu. Kontejner protokolování poskytuje diagnostické informace o tom, které soubory selhaly a proč selhaly.

Pokud připravujete vyřazení clusteru z provozu a chcete provést konečný export do služby Blob Storage, měli byste před zahájením úlohy exportu zajistit zastavení všech vstupně-výstupních aktivit. Tento přístup pomáhá zaručit, že se všechna data exportují tím, že se vyhnete chybám způsobeným aktivitou systému souborů.

Metadata pro exportované soubory

Když se soubory exportují ze systému souborů Spravované lustre Azure do kontejneru objektů blob, uloží se další metadata, aby se zjednodušilo opětovné importování obsahu do systému souborů.

Následující tabulka uvádí atributy POSIX ze systému souborů Lustre, které jsou uloženy v metadatech objektu blob jako páry klíč-hodnota:

Atribut POSIX	Typ
`owner`	int
`group`	int
`permissions`	osmičkový formát nebo rwxrwxwx; Podporuje se bit sticky.

Atributy adresáře se ukládají do prázdného objektu blob. Tento objekt blob má stejný název jako cesta k adresáři a obsahuje následující dvojici klíč-hodnota v metadatech objektu blob: hdi_isfolder : true.

Atributy POSIX můžete upravit ručně před použitím kontejneru k hydrataci nového clusteru Lustre. Upravte nebo přidejte metadata objektů blob pomocí párů klíč-hodnota popsaných výše.

Důležité informace o úlohách exportu

Při exportu dat pomocí úlohy exportu je důležité zvážit následující položky:

Najednou může běžet jenom jedna akce importu nebo exportu. Pokud například probíhá úloha exportu, pokus o spuštění jiné úlohy exportu vrátí chybu.

Kopírování kontejneru objektů blob Lustre pomocí AzCopy nebo Průzkumník služby Storage

Kontejner objektů blob Lustre můžete přesunout nebo zkopírovat pomocí nástroje AzCopy nebo Průzkumník služby Storage.

Pro AzCopy můžete zahrnout atributy adresáře přidáním následujícího příznaku:

--include-directory-stub

Zahrnutím tohoto příznaku se během přenosu zachová atributy POSIX adresáře, ownernapříklad , groupa permissions. Pokud používáte azcopy v kontejneru úložiště bez tohoto příznaku nebo s příznakem nastaveným na false, jsou data a adresáře zahrnuty do přenosu, ale adresáře si nezachovají své atributy POSIX.

V Průzkumník služby Storage můžete tento příznak povolit v Nastavení výběrem možnosti Přenosy a zaškrtnutím políčka Zahrnout zástupné procedury adresáře.

Sdílet prostřednictvím