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

Konteneró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 wspomaganego przez system plików NFS w typie docelowym magazynu ADLS-NFS. Te cele przechowywania są podobne do zwykłych obiektów docelowych magazynu NFS, ale mają również pewne pokrywające się funkcje z typowymi celami przechowywania obiektów blob w platformie Azure.

W tym artykule opisano strategie i ograniczenia, które należy zrozumieć przy korzystaniu z ADLS-NFS jako cele magazynowe.

Zapoznaj się również z dokumentacją dotyczącą blobów NFS, zwłaszcza z tymi sekcjami, które opisują zgodne i niezgodne scenariusze oraz zawierają wskazówki dotyczące rozwiązywania problemów.

• Omówienie funkcji
• Zagadnienia dotyczące wydajności
• Znane problemy i ograniczenia
• Przewodnik procedur i rozwiązywania problemów

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

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

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

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 do docelowego miejsca przechowywania.

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.

Scenariusze buforowania zapisu

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

• Więcej niż 15% operacji zapisu
• 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
• Ponad 15% zapisów, zapisuj z powrotem na serwer 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 w tych plikach mogą zostać utracone. Dzieje się tak, ponieważ pamięć podręczna nie próbuje natychmiast zapisywać zmian w plikach w kontenerze pamięci masowej.

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

1. Pamięć podręczna akceptuje edycje od klientów i zwraca potwierdzenie powodzenia dla każdej zmiany.

2. Pamięć podręczna przechowuje zmieniony plik w swojej pamięci 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 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. Zmiany od klientów zostaną utracone.

Scenariusze buforowania odczytu

Scenariusze buforowania odczytu są odpowiednie dla plików utworzonych za pomocą NFS lub interfejsu API REST 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ą
• Wielokrotne odczytywanie, sprawdzanie serwera pomocniczego 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 zakończą się natychmiastowo i zwrócą komunikat o błędzie do klienta.

Przepływ pracy buforowania odczytu może nadal obejmować zmiany plików, pod warunkiem że 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 oraz 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 proces zapisywania do kontenerów obsługujących 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 ADLS-NFS.

Jednym z ograniczeń opisanych w artykule rozważań dotyczących wydajności obiektów blob z obsługą systemu plików NFS jest to, że magazyn ADLS-NFS jest mało wydajny podczas zastępowania 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 przy zapisywaniu pliku do kontenera zaplecza jest ukrywane 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

• Dowiedz się o wymaganiach wstępnych dla miejsc docelowych magazynowania ADLS-NFS
• Tworzenie konta magazynu obiektów blob z obsługą systemu plików NFS