Korzystanie z usługi Azure Blob Storage z usługą Azure Managed Lustre

Artykuł
11/11/2024

Usługa Azure Managed Lustre integruje się z usługą Azure Blob Storage, aby uprościć proces importowania danych z kontenera obiektów blob do systemu plików. Możesz również wyeksportować dane z systemu plików do kontenera obiektów blob w celu przechowywania długoterminowego. W tym artykule opisano pojęcia dotyczące korzystania z integracji obiektów blob z systemami plików Azure Managed Lustre.

Aby zrozumieć wymagania i konfigurację wymaganą dla zgodnego kontenera obiektów blob, zobacz Wymagania wstępne dotyczące integracji obiektów blob.

Omówienie integracji obiektów blob

Integrację obiektów blob można skonfigurować podczas tworzenia klastra i można utworzyć zadanie importu w dowolnym momencie po utworzeniu klastra. Po zaimportowaniu danych można pracować z danymi, tak jak w przypadku innych danych systemu plików. Ponieważ nowe pliki są tworzone lub istniejące pliki są modyfikowane w systemie plików, możesz wyeksportować te pliki z powrotem do konta magazynu, uruchamiając polecenia interfejsu wiersza polecenia Lustre na kliencie lub eksportując dane przy użyciu zadań eksportu.

Podczas importowania danych z kontenera obiektów blob do systemu plików Azure Managed Lustre tylko nazwy plików (przestrzeń nazw) i metadane są importowane do przestrzeni nazw Lustre. Rzeczywista zawartość obiektu blob jest importowana po pierwszym korzystaniu z klienta. Występuje niewielkie opóźnienie podczas pierwszego uzyskiwania dostępu do danych, podczas gdy funkcja Lustre Hierarchical Storage Management (HSM) ściąga zawartość obiektu blob do odpowiedniego pliku w systemie plików.

Zawartość obiektów blob można wstępnie pobrać przy użyciu polecenia Lustre lfs hsm_restore z zainstalowanego klienta z funkcjami sudo. Aby dowiedzieć się więcej, zobacz Przywracanie danych z usługi Blob Storage.

Usługa Azure Managed Lustre współpracuje z kontami magazynu, które mają włączoną hierarchiczną przestrzeń nazw i konta magazynu z nie hierarchiczną lub płaską przestrzenią nazw. Obowiązują następujące drobne różnice:

W przypadku konta magazynu z włączoną hierarchiczną przestrzenią nazw usługa Azure Managed Lustre odczytuje atrybuty POSIX z nagłówka obiektu blob.
W przypadku konta magazynu, które nie ma włączonej hierarchicznej przestrzeni nazw, usługa Azure Managed Lustre odczytuje atrybuty POSIX z metadanych obiektu blob. Do przechowywania metadanych jest tworzony oddzielny pusty plik o takiej samej nazwie jak zawartość kontenera obiektów blob. Ten plik jest elementem równorzędnym do rzeczywistego katalogu danych w systemie plików Azure Managed Lustre.

Importowanie z usługi Blob Storage

Integrację z usługą Blob Storage można skonfigurować podczas tworzenia klastra i można utworzyć zadanie importu w dowolnym momencie po utworzeniu klastra.

Wymagania dotyczące kontenera obiektów blob

Podczas konfigurowania integracji obiektów blob podczas tworzenia klastra należy zidentyfikować dwa oddzielne kontenery obiektów blob: kontener do zaimportowania i kontenera rejestrowania. Kontener do zaimportowania zawiera dane, które chcesz zaimportować do systemu plików Azure Managed Lustre. Kontener rejestrowania służy do przechowywania dzienników dla zadania importu. Te dwa kontenery muszą znajdować się na tym samym koncie magazynu. Aby dowiedzieć się więcej o wymaganiach dotyczących kontenera obiektów blob, zobacz Wymagania wstępne dotyczące integracji obiektów blob.

Importowanie prefiksu

Podczas importowania danych z kontenera obiektów blob można opcjonalnie określić jeden lub więcej prefiksów, aby filtrować dane zaimportowane do systemu plików Azure Managed Lustre. Nazwy plików w kontenerze obiektów blob, które pasują do jednego z prefiksów, są dodawane do rekordu metadanych w systemie plików. Gdy klient po raz pierwszy uzyskuje dostęp do pliku, jego zawartość jest pobierana z kontenera obiektów blob i przechowywana w systemie plików.

W witrynie Azure Portal użyj pól Prefiks importu na karcie Zaawansowane podczas tworzenia klastra, aby określić dane do zaimportowania z kontenera obiektów blob. Te pola dotyczą tylko początkowego zadania importu. Nie można zmienić prefiksu importu po utworzeniu klastra.

W przypadku zadania importu można określić prefiksy importu podczas tworzenia zadania. W witrynie Azure Portal można określić prefiksy importu w polach Prefiks importu. Prefiks importu można również określić podczas tworzenia zadania importu przy użyciu interfejsu API REST.

Podczas określania prefiksów importu należy pamiętać o następujących kwestiach:

Domyślny prefiks importu to /. To domyślne zachowanie importuje zawartość całego kontenera obiektów blob.
Jeśli określisz wiele prefiksów, prefiksy muszą nie nakładać się. Jeśli na przykład określisz /data polecenie i /data2, zadanie importu zakończy się niepowodzeniem, ponieważ prefiksy nakładają się na siebie.
Jeśli kontener obiektów blob znajduje się na koncie magazynu z włączoną hierarchiczną przestrzenią nazw, możesz traktować prefiks jako ścieżkę pliku. Elementy pod ścieżką znajdują się w systemie plików Azure Managed Lustre.
Jeśli kontener obiektów blob znajduje się na koncie magazynu z nie hierarchiczną (lub płaską) przestrzenią nazw, możesz traktować prefiks importu jako ciąg wyszukiwania, który jest porównywany z początkiem nazwy obiektu blob. Jeśli nazwa obiektu blob w kontenerze rozpoczyna się od ciągu określonego jako prefiks importu, ten plik jest dostępny w systemie plików. Lustre to hierarchiczny system plików, a / znaki w nazwach obiektów blob stają się ogranicznikami katalogów przechowywanymi w rozwiązaniu Lustre.

Tryb rozwiązywania konfliktów

Podczas importowania danych z kontenera obiektów blob można określić sposób obsługi konfliktów między kontenerem obiektów blob a systemem plików. Ta opcja dotyczy tylko zadań importu, które są uruchamiane dla istniejących klastrów. W poniższej tabeli przedstawiono dostępne tryby rozwiązywania konfliktów i ich opisy:

Tryb	opis
`fail`	Zadanie importowania kończy się niepowodzeniem natychmiast z powodu błędu, jeśli zostanie wykryty konflikt.
`skip`	Zadanie importowania pomija plik, jeśli zostanie wykryty konflikt.
`overwrite-dirty`	Zadanie importowania ocenia ścieżkę powodującą konflikt, aby sprawdzić, czy ma zostać usunięta i zaimportowana ponownie. Aby dowiedzieć się więcej, zobacz zastępowanie trybu brudnego.
`overwrite-always`	Zadanie importowania ocenia ścieżkę powodującą konflikt i zawsze usuwa/ponownie importuje je, jeśli jest zanieczyszczony lub zwalnia, jeśli jest czysty. Aby dowiedzieć się więcej, zobacz tryb overwrite-always.

Zastępowanie trybu brudnego

Tryb overwrite-dirty ocenia ścieżkę powodującą konflikt, aby sprawdzić, czy powinna zostać usunięta i zaimportowana ponownie. Na wysokim poziomie overwrite-dirty tryb sprawdza stan modułu HSM. Jeśli stan modułu HSM jest czysty i zarchiwowany, co oznacza, że jego dane są zsynchronizowane z kontenerem obiektów blob, o ile lustre może powiedzieć, to tylko atrybuty są aktualizowane, jeśli to konieczne. W przeciwnym razie plik zostanie usunięty i ponownie zaimportowany z kontenera obiektów blob.

Sprawdzanie stanu modułu HSM nie gwarantuje, że plik w narzędziu Lustre jest zgodny z plikiem w kontenerze obiektów blob. Jeśli musisz upewnić się, że plik w narzędziu Lustre jest zgodny z plikiem w kontenerze obiektów blob tak ściśle, jak to możliwe, użyj overwrite-always trybu .

Zastępowanie trybu zawsze

Tryb overwrite-always ocenia ścieżkę powodującą konflikt i zawsze usuwa/ponownie importuje, jeśli jest on zanieczyszczony lub zwalnia, jeśli jest czysty. Ten tryb jest przydatny, gdy chcesz upewnić się, że system plików jest zawsze zsynchronizowany z kontenerem obiektów blob. Jest to również najdroższa opcja, ponieważ każdy wcześniej przywrócony plik jest zwalniany lub usuwany/ponownie importowany po pierwszym dostępie.

Tolerancja błędów

Podczas importowania danych z kontenera obiektów blob można określić odporność na błędy. Poziom tolerancji błędów określa, w jaki sposób zadanie importu obsługuje błędy przejściowe występujące podczas procesu importowania, na przykład błędy systemu operacyjnego lub przerwy w działaniu sieci. Należy pamiętać, że błędy w tym kontekście nie odwołują się do konfliktów plików, które są obsługiwane przez tryb rozwiązywania konfliktów.

Dla zadań importu są dostępne następujące opcje tolerancji błędów:

Nie zezwalaj na błędy (ustawienie domyślne): zadanie importowania kończy się niepowodzeniem natychmiast, jeśli wystąpi jakikolwiek błąd podczas importowania. To jest zachowanie domyślne.
Zezwalaj na błędy: zadanie importowania jest kontynuowane w przypadku wystąpienia błędu, a błąd jest rejestrowany. Po zakończeniu zadania importowania można wyświetlić błędy w kontenerze rejestrowania.

Zagadnienia dotyczące zadań importowania obiektów blob

Podczas importowania danych z kontenera obiektów blob należy wziąć pod uwagę następujące elementy:

Jednocześnie można uruchomić tylko jedną akcję importu lub eksportu. Jeśli na przykład zadanie importowania jest w toku, próba uruchomienia innego zadania importu zwróci błąd.
Zadania importu można anulować. Możesz anulować zadanie importu uruchomione w istniejącym klastrze lub zadanie importu zainicjowane podczas tworzenia klastra.
Wdrożenie klastra może powrócić pomyślnie przed ukończeniem odpowiedniego zadania importu. Zadanie importowania nadal działa w tle. Postęp zadania importu można monitorować w następujący sposób:
- Witryna Azure Portal: w witrynie Azure Portal jest wyświetlany stan zadania importu. Przejdź do systemu plików i wybierz pozycję Integracja obiektów blob, aby wyświetlić stan zadania importu.
- Plik lustra w katalogu głównym: plik o nazwie podobnej do /lustre/IMPORT_<state>.<timestamp_start> jest tworzony w katalogu głównym Lustre podczas importowania. Symbol <state> zastępczy zmienia się w miarę postępu importowania. Plik zostanie usunięty po pomyślnym zakończeniu zadania importowania.
Aby wyświetlić szczegółowe informacje o ukończonym zadaniu importu, możesz sprawdzić kontener rejestrowania. Kontener rejestrowania zawiera dzienniki dla zadania importu, w tym wszelkie błędy lub konflikty, które wystąpiły podczas importowania.
Jeśli zadanie importowania zakończy się niepowodzeniem z jakiegokolwiek powodu, może nie mieć pełnych statystyk dotyczących zadania importu, takich jak liczba zaimportowanych plików lub liczba konfliktów.

Przywracanie danych z usługi Blob Storage

Domyślnie zawartość obiektu blob jest importowana do systemu plików przy pierwszym uzyskiwaniu dostępu do odpowiedniego pliku przez klienta. W przypadku niektórych obciążeń i scenariuszy możesz wolisz przywrócić dane z kontenera obiektów blob przed pierwszym uzyskaniem do niego dostępu. Możesz wstępnie pobrać zawartość obiektów blob, aby uniknąć początkowego opóźnienia podczas uzyskiwania dostępu do obiektu blob po raz pierwszy po zaimportowaniu. Aby wstępnie pobrać zawartość obiektów blob, możesz użyć polecenia Lustre lfs hsm_restore z zainstalowanego klienta z możliwościami sudo. Następujące polecenie spowoduje wstępne pobranie zawartości obiektów blob do systemu plików:

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

To polecenie nakazuje serwerowi metadanych asynchroniczne przetwarzanie żądania przywrócenia. Wiersz polecenia nie czeka na zakończenie przywracania, co oznacza, że wiersz polecenia może kolejkować dużą liczbę wpisów na potrzeby przywracania na serwerze metadanych. Takie podejście może przeciążyć serwer metadanych i obniżyć wydajność przywracania.

Aby uniknąć tego potencjalnego problemu z wydajnością, możesz utworzyć podstawowy skrypt, który próbuje przejść ścieżkę i problemy z żądaniami przywracania w partiach o określonym rozmiarze. Aby osiągnąć rozsądną wydajność i uniknąć przeciążeń serwera metadanych, zaleca się używanie rozmiarów partii w dowolnym miejscu od 1000 do 5000 żądań.

Przykład: tworzenie skryptu przywracania wsadowego

W poniższym przykładzie pokazano, jak utworzyć skrypt w celu przywrócenia danych z kontenera obiektów blob w partiach. Utwórz plik o nazwie o file_restorer.bash następującej zawartości:

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

W poniższym przykładzie pokazano, jak uruchomić skrypt wraz z przykładowymi danymi wyjściowymi:

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

Uwaga

W tej chwili usługa Azure Managed Lustre przywraca dane z usługi Blob Storage z maksymalną szybkością przepływności wynoszącą ok. 7,5GiB/sekundę.

Eksportowanie danych do usługi Blob Storage przy użyciu zadania eksportu

Dane z zarządzanego systemu plików Lustre platformy Azure można skopiować do długoterminowego magazynu w usłudze Azure Blob Storage, tworząc zadanie eksportu.

Które pliki są eksportowane podczas zadania eksportu?

Podczas eksportowania plików z systemu Azure Managed Lustre nie wszystkie pliki są kopiowane do kontenera obiektów blob określonego podczas tworzenia systemu plików. Następujące reguły mają zastosowanie do zadań eksportu:

Zadania eksportują tylko pliki, które są nowe lub których zawartość jest modyfikowana. Jeśli plik zaimportowany z kontenera obiektów blob podczas tworzenia systemu plików nie zmieni się, zadanie eksportu nie spowoduje wyeksportowania pliku.
Pliki ze zmianami metadanych nie są eksportowane. Zmiany metadanych obejmują: właściciel, uprawnienia, atrybuty rozszerzone i zmiany nazwy (zmieniono nazwę).
Pliki usunięte w zarządzanym systemie plików Lustre platformy Azure nie są usuwane w oryginalnym kontenerze obiektów blob podczas zadania eksportu. Zadanie eksportu nie usuwa plików w kontenerze obiektów blob.

Uruchamianie zadań eksportu w aktywnych systemach plików

W aktywnych systemach plików zmiany w plikach podczas zadania eksportu mogą spowodować awarię. Ten stan błędu informuje, że nie wszystkie dane w systemie plików można wyeksportować do usługi Blob Storage. W takiej sytuacji można ponowić próbę eksportu, tworząc nowe zadanie eksportu. Nowe zadanie kopiuje tylko pliki, które nie zostały skopiowane w poprzednim zadaniu.

W systemach plików z dużą ilością aktywności ponowne próby mogą wielokrotnie ulegać awarii, ponieważ pliki często się zmieniają. Aby sprawdzić, czy plik został pomyślnie wyeksportowany do usługi Blob Storage, sprawdź sygnaturę czasową odpowiedniego obiektu blob. Po zakończeniu zadania można również wyświetlić kontener rejestrowania skonfigurowany podczas wdrażania, aby wyświetlić szczegółowe informacje o zadaniu eksportu. Kontener rejestrowania zawiera informacje diagnostyczne o tym, które pliki zakończyły się niepowodzeniem i dlaczego zakończyły się niepowodzeniem.

Jeśli przygotowujesz się do zlikwidowania klastra i chcesz wykonać końcowy eksport do usługi Blob Storage, przed zainicjowaniem zadania eksportu upewnij się, że wszystkie działania we/wy zostały zatrzymane. Takie podejście pomaga zagwarantować, że wszystkie dane są eksportowane, unikając błędów spowodowanych działaniem systemu plików.

Metadane dla wyeksportowanych plików

Gdy pliki są eksportowane z systemu plików Azure Managed Lustre do kontenera obiektów blob, dodatkowe metadane są zapisywane w celu uproszczenia ponownego importowania zawartości do systemu plików.

W poniższej tabeli wymieniono atrybuty POSIX z systemu plików Lustre zapisane w metadanych obiektu blob jako pary klucz-wartość:

Atrybut POSIX	Typ
`owner`	int
`group`	int
`permissions`	format ósemkowy lub rwxrwxwx; Bit sticky jest obsługiwany

Atrybuty katalogu są zapisywane w pustym obiekcie blob. Ten obiekt blob ma taką samą nazwę jak ścieżka katalogu i zawiera następującą parę klucz-wartość w metadanych obiektu blob: hdi_isfolder : true.

Atrybuty POSIX można zmodyfikować ręcznie przed użyciem kontenera w celu nawodnienia nowego klastra Lustre. Edytuj lub dodaj metadane obiektu blob przy użyciu par klucz-wartość opisanych wcześniej.

Zagadnienia dotyczące zadań eksportu

Podczas eksportowania danych za pomocą zadania eksportu należy wziąć pod uwagę następujące elementy:

Jednocześnie można uruchomić tylko jedną akcję importu lub eksportu. Jeśli na przykład zadanie eksportu jest w toku, próba uruchomienia innego zadania eksportu zwróci błąd.

Kopiowanie kontenera obiektów blob Lustre za pomocą narzędzia AzCopy lub Eksplorator usługi Storage

Kontener obiektów blob Lustre można przenosić lub kopiować za pomocą narzędzia AzCopy lub Eksplorator usługi Storage.

W przypadku narzędzia AzCopy można uwzględnić atrybuty katalogu, dodając następującą flagę:

--include-directory-stub

Dołączenie tej flagi powoduje zachowanie atrybutów POSIX katalogu podczas transferu, na przykład owner, groupi permissions. Jeśli używasz azcopy kontenera magazynu bez tej flagi lub z flagą ustawioną na false, dane i katalogi są uwzględniane w transferze, ale katalogi nie zachowują ich atrybutów POSIX.

W Eksplorator usługi Storage możesz włączyć tę flagę w obszarze Ustawienia, wybierając pozycję Transfery i zaznaczając pole wyboru Uwzględnij wycinki katalogu.

Udostępnij za pośrednictwem