Udostępnij za pośrednictwem

Korzystanie z magazynu obiektów blob zainstalowanych w systemie plików NFS z usługą Azure HPC Cache

  • Artykuł

Kontenery obiektów blob zainstalowanych w systemie plików NFS można używać z usługą Azure HPC Cache. Przeczytaj więcej na temat obsługi protokołu NFS 3.0 w usłudze Azure Blob Storage w witrynie dokumentacji usługi Blob Storage.

Usługa Azure HPC Cache używa magazynu obiektów blob z obsługą systemu plików NFS w docelowym typie magazynu ADLS-NFS. Te cele magazynu są podobne do zwykłych obiektów docelowych magazynu NFS, ale mają również pewne nakładające się na zwykłe obiekty docelowe obiektów blob platformy Azure.

W tym artykule opisano strategie i ograniczenia, które należy zrozumieć podczas korzystania z obiektów docelowych magazynu ADLS-NFS.

Zapoznaj się również z dokumentacją obiektów blob systemu plików NFS, zwłaszcza w tych sekcjach, które opisują zgodne i niezgodne scenariusze, i podaj porady dotyczące rozwiązywania problemów:

Omówienie wymagań dotyczących spójności

Pamięć podręczna HPC Cache wymaga silnej spójności dla celów magazynu ADLS-NFS. Domyślnie magazyn obiektów blob z obsługą systemu plików NFS nie aktualizuje ściśle metadanych plików, co uniemożliwia dokładne porównywanie wersji plików w pamięci podręcznej HPC Cache.

Aby obejść tę różnicę, usługa Azure HPC Cache automatycznie wyłącza buforowanie atrybutów NFS na dowolnym kontenerze obiektów blob z obsługą systemu plików NFS używanym jako obiekt docelowy magazynu.

To ustawienie będzie utrzymywane przez okres istnienia kontenera, nawet jeśli usuniesz go z pamięci podręcznej.

Wstępne ładowanie danych za pomocą protokołu NFS

W kontenerze obiektów blob z obsługą systemu plików NFS plik może być edytowany tylko przez ten sam protokół używany podczas jego tworzenia. Oznacza to, że jeśli używasz interfejsu API REST platformy Azure do wypełniania kontenera, nie możesz użyć systemu plików NFS do zaktualizowania tych plików. Ponieważ usługa Azure HPC Cache używa tylko systemu plików NFS, nie może edytować żadnych plików utworzonych za pomocą interfejsu API REST platformy Azure. (Dowiedz się więcej o znanych problemach z interfejsami API usługi Blob Storage)

Nie jest to problem z pamięcią podręczną, jeśli kontener jest pusty lub czy pliki zostały utworzone przy użyciu systemu plików NFS.

Jeśli pliki w kontenerze zostały utworzone przy użyciu interfejsu API REST obiektów blob platformy Azure zamiast systemu plików NFS, usługa Azure HPC Cache jest ograniczona do tych akcji w oryginalnych plikach:

  • Wyświetl plik w katalogu.
  • Odczytaj plik (i przytrzymaj go w pamięci podręcznej na potrzeby kolejnych operacji odczytu).
  • Usuń plik.
  • Opróżnij plik (obcinaj go do 0).
  • Zapisz kopię pliku. Kopia jest oznaczona jako plik utworzony przez system plików NFS i można ją edytować przy użyciu systemu plików NFS.

Usługa Azure HPC Cache nie może edytować zawartości pliku utworzonego przy użyciu interfejsu REST. Oznacza to, że pamięć podręczna nie może zapisać zmienionego pliku z klienta z powrotem do miejsca docelowego magazynu.

Ważne jest, aby zrozumieć to ograniczenie, ponieważ może to spowodować problemy z integralnością danych, jeśli używasz modeli użycia buforowania odczytu/zapisu w plikach, które nie zostały utworzone z systemem plików NFS.

Napiwek

Dowiedz się więcej na temat buforowania odczytu i zapisu w temacie Omówienie modeli użycia pamięci podręcznej.

Scenariusze buforowania zapisu

Te modele użycia pamięci podręcznej obejmują buforowanie zapisu:

  • Więcej niż 15% zapisów
  • Więcej niż 15% zapisów, sprawdzanie serwera kopii zapasowej pod kątem zmian co 30 sekund
  • Więcej niż 15% zapisów, sprawdzanie serwera kopii zapasowej pod kątem zmian co 60 sekund
  • Więcej niż 15% zapisów, zapisuj z powrotem na serwerze co 30 sekund

Modele użycia buforowania zapisu powinny być używane tylko w plikach utworzonych za pomocą systemu plików NFS.

Jeśli spróbujesz użyć buforowania zapisu w plikach utworzonych przez rest, zmiany plików mogą zostać utracone. Dzieje się tak, ponieważ pamięć podręczna nie próbuje natychmiast zapisywać edycji plików w kontenerze magazynu.

Oto jak próba buforowania zapisów w plikach utworzonych przez rest naraża dane na ryzyko:

  1. Pamięć podręczna akceptuje zmiany od klientów i zwraca komunikat o powodzeniu dla każdej zmiany.

  2. Pamięć podręczna przechowuje zmieniony plik w magazynie i czeka na dodatkowe zmiany.

  3. Po pewnym czasie pamięć podręczna próbuje zapisać zmieniony plik w kontenerze zaplecza. W tym momencie zostanie wyświetlony komunikat o błędzie, ponieważ próbuje zapisać w pliku utworzonym przez rest za pomocą systemu plików NFS.

    Jest za późno, aby poinformować maszynę klienta, że jego zmiany nie zostały zaakceptowane, a pamięć podręczna nie ma możliwości zaktualizowania oryginalnego pliku. W związku z tym zmiany klientów zostaną utracone.

Scenariusze buforowania odczytu

Scenariusze buforowania odczytu są odpowiednie dla plików utworzonych za pomocą interfejsu API REST systemu plików NFS lub Azure Blob.

Te modele użycia używają tylko buforowania odczytu:

  • Odczyt ciężkich, rzadko używanych zapisów
  • Klienci zapisują do docelowego systemu plików NFS, pomijając pamięć podręczną
  • Odczytywanie dużego obciążenia, sprawdzanie serwera kopii zapasowej co 3 godziny

Można używać tych modeli użycia z plikami utworzonymi przez interfejs API REST lub NFS. Wszystkie operacje zapisu systemu plików NFS wysyłane z klienta do kontenera zaplecza nadal zakończą się niepowodzeniem, ale natychmiast zakończy się niepowodzeniem i zwróci komunikat o błędzie do klienta.

Przepływ pracy buforowania odczytu może nadal obejmować zmiany plików, o ile nie są one buforowane. Na przykład klienci mogą uzyskiwać dostęp do plików z kontenera, ale zapisywać zmiany z powrotem jako nowy plik lub zapisywać zmodyfikowane pliki w innej lokalizacji.

Rozpoznawanie ograniczeń menedżera blokad sieci (NLM)

Kontenery obiektów blob z obsługą systemu plików NFS nie obsługują menedżera blokad sieci (NLM), który jest często używanym protokołem NFS do ochrony plików przed konfliktami.

Jeśli przepływ pracy systemu plików NFS został pierwotnie napisany dla sprzętowych systemów magazynowania, aplikacje klienckie mogą obejmować żądania NLM. Aby obejść to ograniczenie podczas przenoszenia procesu do magazynu obiektów blob z obsługą systemu plików NFS, upewnij się, że klienci wyłączają funkcję NLM podczas instalowania pamięci podręcznej.

Aby wyłączyć funkcję NLM, użyj opcji -o nolock w poleceniu klienta mount . Ta opcja uniemożliwia klientom żądanie blokad nlm i odbieranie błędów w odpowiedzi. Opcja nolock jest implementowana inaczej w różnych systemach operacyjnych. Aby uzyskać szczegółowe informacje, sprawdź dokumentację systemu operacyjnego klienta (man 5 nfs).

Usprawnij zapisywanie w kontenerach z obsługą systemu plików NFS za pomocą pamięci podręcznej HPC Cache

Usługa Azure HPC Cache może pomóc zwiększyć wydajność obciążenia, które obejmuje zapisywanie zmian w docelowym magazynie usługi ADLS-NFS.

Uwaga

Aby wypełnić kontener magazynu ADLS-NFS, należy użyć systemu plików NFS, jeśli chcesz zmodyfikować jego pliki za pośrednictwem usługi Azure HPC Cache.

Jednym z ograniczeń opisanych w artykule Dotyczącym wydajności obiektów blob z obsługą systemu plików NFS jest to, że magazyn ADLS-NFS nie jest bardzo wydajny w zastępowaniu istniejących plików. Jeśli używasz usługi Azure HPC Cache z zainstalowanym magazynem obiektów blob systemu plików NFS, pamięć podręczna obsługuje sporadyczne ponowne zapisywanie, gdy klienci modyfikują aktywny plik. Opóźnienie zapisywania pliku w kontenerze zaplecza jest ukryte przed klientami.

Należy pamiętać o ograniczeniach opisanych powyżej w artykule Wstępne ładowanie danych przy użyciu protokołu NFS.

Następne kroki