Wymagania wstępne dotyczące systemu plików Lustre zarządzanego platformy Azure
W tym artykule opisano wymagania wstępne, które należy skonfigurować przed utworzeniem systemu plików Azure Managed Lustre.
- Wymagania wstępne dotyczące sieci
- Wymagania wstępne dotyczące integracji obiektów blob (opcjonalnie)
Wymagania wstępne dotyczące sieci
Systemy plików Azure Managed Lustre istnieją w podsieci sieci wirtualnej. Podsieć zawiera usługę zarządzania lustrem (MGS) i obsługuje wszystkie interakcje klientów z wirtualnym klastrem Lustre.
Nie można przenieść systemu plików z jednej sieci lub podsieci do innej po utworzeniu systemu plików.
Usługa Azure Managed Lustre akceptuje tylko adresy IPv4. Protokół IPv6 nie jest obsługiwany.
Wymagania dotyczące rozmiaru sieci
Rozmiar potrzebnej podsieci zależy od rozmiaru tworzonego systemu plików. W poniższej tabeli przedstawiono przybliżone oszacowanie minimalnego rozmiaru podsieci dla systemów plików Usługi Azure Managed Lustre o różnych rozmiarach.
| Pojemność magazynu | Zalecana wartość prefiksu CIDR |
|---|---|
| 4 TiB do 16 TiB | /27 lub większe |
| Od 20 TiB do 40 TiB | /26 lub większe |
| 44 TiB do 92 TiB | /25 lub większe |
| 96 TiB do 196 TiB | /24 lub większe |
| 200 TiB do 400 TiB | /23 lub większe |
Inne zagadnienia dotyczące rozmiaru sieci
Podczas planowania sieci wirtualnej i podsieci należy wziąć pod uwagę wymagania dotyczące innych usług, które chcesz zlokalizować w podsieci Azure Managed Lustre lub sieci wirtualnej.
Jeśli używasz klastra usługi Azure Kubernetes Service (AKS) z systemem plików Azure Managed Lustre, możesz zlokalizować klaster usługi AKS w tej samej podsieci co system plików. W takim przypadku należy podać wystarczające adresy IP dla węzłów i zasobników usługi AKS oprócz przestrzeni adresowej systemu plików Lustre. Jeśli używasz więcej niż jednego klastra usługi AKS w sieci wirtualnej, upewnij się, że sieć wirtualna ma wystarczającą pojemność dla wszystkich zasobów we wszystkich klastrach. Aby dowiedzieć się więcej na temat strategii sieciowych dla rozwiązań Azure Managed Lustre i AKS, zobacz Dostęp do podsieci usługi AKS.
Jeśli planujesz użyć innego zasobu do hostowania maszyn wirtualnych obliczeniowych w tej samej sieci wirtualnej, przed utworzeniem sieci wirtualnej i podsieci dla systemu Azure Managed Lustre sprawdź wymagania dotyczące tego procesu. Podczas planowania wielu klastrów w tej samej podsieci należy użyć wystarczająco dużej przestrzeni adresowej, aby uwzględnić łączne wymagania dla wszystkich klastrów.
Dostęp do podsieci i uprawnienia
Domyślnie nie trzeba wprowadzać żadnych konkretnych zmian, aby włączyć usługę Azure Managed Lustre. Jeśli środowisko zawiera zasady z ograniczeniami sieci lub zabezpieczeń, należy wziąć pod uwagę następujące wskazówki:
| Typ dostępu | Wymagane ustawienia sieciowe |
|---|---|
| Dostęp DNS | Użyj domyślnego serwera DNS opartego na platformie Azure. |
| Dostęp między hostami | Zezwalaj na dostęp przychodzący i wychodzący między hostami w podsieci Azure Managed Lustre. Na przykład dostęp do portu TCP 22 (SSH) jest niezbędny do wdrożenia klastra. |
| Dostęp do usługi w chmurze platformy Azure | Skonfiguruj sieciowa grupa zabezpieczeń, aby zezwolić systemowi plików Azure Managed Lustre na dostęp do usług w chmurze platformy Azure z podsieci systemu plików. Dodaj regułę zabezpieczeń dla ruchu wychodzącego z następującymi właściwościami: - Port: dowolny - Protokół: dowolny - Źródło: Sieć wirtualna - Miejsce docelowe: tag usługi "AzureCloud" - Akcja: Zezwalaj Uwaga: Skonfigurowanie usługi w chmurze platformy Azure umożliwia również niezbędną konfigurację usługi Azure Queue. Aby uzyskać więcej informacji, zobacz Tagi usługi dla sieci wirtualnej. |
| Dostęp do portu sieciowego lustra | Sieciowa grupa zabezpieczeń musi zezwalać na dostęp przychodzący i wychodzący na porcie 988 i portach 1019-1023. Żadne inne usługi nie mogą rezerwować ani używać tych portów na klientach Lustre. Reguły domyślne 65000 AllowVnetInBound i 65000 AllowVnetOutBound spełniają to wymaganie. |
Aby uzyskać szczegółowe wskazówki dotyczące konfigurowania sieciowej grupy zabezpieczeń dla systemów plików Azure Managed Lustre, zobacz Tworzenie i konfigurowanie sieciowej grupy zabezpieczeń.
Znane ograniczenia
Następujące znane ograniczenia dotyczą ustawień sieci wirtualnej dla systemów plików Azure Managed Lustre:
- Zasoby usługi Azure Managed Lustre i Azure NetApp Files nie mogą współużytkować podsieci. Jeśli używasz usługi Azure NetApp Files, musisz utworzyć system plików Azure Managed Lustre w oddzielnej podsieci. Wdrożenie zakończy się niepowodzeniem, jeśli spróbujesz utworzyć system plików Azure Managed Lustre w podsieci, która obecnie zawiera lub zawiera wcześniej zasoby usługi Azure NetApp Files.
- Jeśli używasz demona
ypbindna klientach do obsługi informacji o powiązaniach usług informacyjnych sieciowych (NIS), musisz upewnić się, żeypbindport 988 nie jest rezerwowy. Możesz ręcznie dostosować porty, któreypbindrezerwują, lub upewnić się, że infrastruktura uruchamiania systemu uruchamia instalację klienta Lustre przed uruchomieniem programuypbind.
Uwaga
Po utworzeniu systemu plików Azure Managed Lustre w grupie zasobów systemu plików zostanie wyświetlonych kilka nowych interfejsów sieciowych. Ich nazwy zaczynają się od amlfs- i kończą się -snic. Nie zmieniaj żadnych ustawień tych interfejsów. W szczególności pozostaw wartość domyślną włączoną dla ustawienia Przyspieszona sieć. Wyłączenie przyspieszonej sieci w tych interfejsach sieciowych obniża wydajność systemu plików.
Wymagania wstępne dotyczące integracji obiektów blob (opcjonalnie)
Jeśli planujesz zintegrować system plików Azure Managed Lustre z usługą Azure Blob Storage, przed utworzeniem systemu plików wykonaj następujące wymagania wstępne.
Aby dowiedzieć się więcej na temat integracji obiektów blob, zobacz Korzystanie z usługi Azure Blob Storage z systemem plików Azure Managed Lustre.
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.
Aby zintegrować usługę Azure Blob Storage z systemem plików Azure Managed Lustre, przed utworzeniem systemu plików należy utworzyć lub skonfigurować następujące zasoby:
Konto magazynu
Musisz utworzyć konto magazynu lub użyć istniejącego. Konto magazynu musi mieć następujące ustawienia:
- Typ konta — zgodny typ konta magazynu. Aby dowiedzieć się więcej, zobacz Obsługiwane typy kont magazynu.
- Role dostępu — przypisania ról , które umożliwiają systemowi Azure Managed Lustre modyfikowanie danych. Aby dowiedzieć się więcej, zobacz Wymagane role dostępu.
- Klucze dostępu — konto magazynu musi mieć ustawienie dostępu do klucza konta magazynu ustawione na Włączone.
Obsługiwane typy kont magazynu
Następujące typy kont magazynu mogą być używane z systemami plików Azure Managed Lustre:
| Storage account type | Nadmiarowość |
|---|---|
| Standardowa | Magazyn lokalnie nadmiarowy (LRS), magazyn geograficznie nadmiarowy (GRS) Magazyn strefowo nadmiarowy (ZRS), magazyn geograficznie nadmiarowy dostępny do odczytu (RAGRS), magazyn geograficznie nadmiarowy strefowo nadmiarowy (GZRS), magazyn geograficznie nadmiarowy dostępny do odczytu (RA-GZRS) |
| Premium — blokowe obiekty blob | LRS, ZRS |
Aby uzyskać więcej informacji na temat typów kont magazynu, zobacz Typy kont magazynu.
Role dostępu do integracji obiektów blob
Usługa Azure Managed Lustre wymaga autoryzacji w celu uzyskania dostępu do konta magazynu. Użyj kontroli dostępu opartej na rolach (RBAC) platformy Azure, aby zapewnić systemowi plików dostęp do magazynu obiektów blob.
Właściciel konta magazynu musi dodać te role przed utworzeniem systemu plików:
Ważne
Przed utworzeniem systemu plików Azure Managed Lustre należy dodać te role. Jeśli system plików nie może uzyskać dostępu do kontenera obiektów blob, tworzenie systemu plików zakończy się niepowodzeniem. Weryfikacja wykonywana przed utworzeniem systemu plików nie może wykryć problemów z uprawnieniami dostępu do kontenera. Propagacja ustawień roli za pośrednictwem środowiska platformy Azure może potrwać do pięciu minut.
Aby dodać role dostawcy zasobów usługi HPC Cache jednostki usługi, wykonaj następujące kroki:
- Przejdź do konta magazynu i wybierz pozycję Kontrola dostępu (Zarządzanie dostępem i tożsamościami) w okienku nawigacji po lewej stronie.
- Wybierz pozycję Dodaj>przypisanie roli, aby otworzyć stronę Dodawanie przypisania roli.
- Przypisz rolę.
- Dodaj dostawcę zasobów usługi HPC Cache do tej roli.
Napiwek
Jeśli nie możesz znaleźć dostawcy zasobów usługi HPC Cache, wyszukaj zamiast tego usługę storagecache . Dostawca zasobów usługi storagecache był nazwą główną usługi przed ogólną dostępnością produktu.
- Powtórz kroki 3 i 4, aby dodać każdą rolę.
Aby uzyskać szczegółowe instrukcje, zobacz Przypisywanie ról platformy Azure przy użyciu witryny Azure Portal.
Kontenery obiektów blob
Musisz mieć dwa oddzielne kontenery obiektów blob na tym samym koncie magazynu, które są używane w następujących celach:
- Kontener danych: kontener obiektów blob na koncie magazynu zawierający pliki, których chcesz użyć w systemie plików Azure Managed Lustre.
- Kontener rejestrowania: drugi kontener dzienników importu/eksportu na koncie magazynu. Dzienniki należy przechowywać w innym kontenerze niż kontener danych.
Uwaga
Pliki można dodawać do systemu plików później od klientów. Jednak pliki dodane do oryginalnego kontenera obiektów blob po utworzeniu systemu plików nie zostaną zaimportowane do systemu plików Azure Managed Lustre, chyba że zostanie utworzone zadanie importu.
Prywatne punkty końcowe (opcjonalnie)
Jeśli używasz prywatnego punktu końcowego z konfiguracją obiektu blob, aby upewnić się, że zarządzane lustro platformy Azure może rozpoznać nazwę sa, musisz włączyć ustawienie prywatnego punktu końcowego Integracja z prywatną strefą DNS podczas tworzenia nowego punktu końcowego.
- Integracja z strefą Prywatna strefa DNS: musi być ustawiona wartość Tak.
