Udostępnij za pośrednictwem

Limity usługi Azure Data Box Heavy

  • Artykuł

Te limity należy wziąć pod uwagę podczas wdrażania i obsługi urządzenia Azure Data Box Heavy. W poniższej tabeli opisano te limity dla urządzenia Data Box.

Limity usługi Data Box Heavy

  • Jeśli używasz wielu kont magazynu z usługą Data Box, wszystkie konta magazynu powinny należeć do tego samego regionu świadczenia usługi Azure.
  • Zalecamy używanie nie więcej niż trzech kont magazynu. Użycie większej liczby kont magazynu może potencjalnie wpłynąć na wydajność.

Limity urządzenia Data Box Heavy

  • Urządzenie Data Box Heavy może przechowywać maksymalnie 1 miliard plików na węzeł.
  • Urządzenie Data Box Heavy obsługuje maksymalnie 512 kontenerów lub udziałów na węzeł w chmurze. Katalogi najwyższego poziomu w udziale użytkownika stają się kontenerami lub udziałami plików platformy Azure w chmurze.

Limity usługi Azure Storage

W tej sekcji opisano limity usługi Azure Storage oraz wymagane konwencje nazewnictwa dla usług Azure Files, blokowych obiektów blob platformy Azure i stronicowych obiektów blob platformy Azure, które mają zastosowanie do usługi Data Box. Uważnie przejrzyj limity magazynu i postępuj zgodnie ze wszystkimi zaleceniami.

Aby uzyskać najnowsze informacje na temat limitów usługi Azure Storage i najlepszych rozwiązań dotyczących nazewnictwa udziałów, kontenerów i plików, przejdź do:

Ważne

Jeśli istnieją pliki lub katalogi, które przekraczają limity usługi Azure Storage lub nie są zgodne z konwencjami nazewnictwa usługi Azure Files/Blob, te pliki lub katalogi nie są pozyskiwane do usługi Azure Storage za pośrednictwem usługi Data Box.

Zastrzeżenia dotyczące przekazywania danych

  • Kontenery, udziały i foldery:
    • Nie kopiuj plików bezpośrednio do żadnego ze wstępnie utworzonych udziałów. Musisz utworzyć folder w ramach udziału, a następnie skopiować pliki do tego folderu.
    • Folder w StorageAccount_BlockBlob i StorageAccount_PageBlob jest kontenerem. Na przykład kontenery są tworzone jako StorageAccount_BlockBlob/kontener i StorageAccount_PageBlob/kontener.
    • Każdy folder utworzony bezpośrednio w StorageAccount_AzFile jest tłumaczony na udział plików platformy Azure.
    • Usługa Azure Blob Storage nie obsługuje katalogów. Jeśli utworzysz folder w folderze StorageAccount_BlockBlob , foldery wirtualne zostaną utworzone w nazwie obiektu blob. W przypadku usługi Azure Files rzeczywista struktura katalogów jest utrzymywana.
  • Scalanie zawartości folderu:
    • Każdy plik zapisany w udziałach StorageAccount_BlockBlob i StorageAccount_PageBlob jest przekazywany odpowiednio jako blokowy obiekt blob i stronicowy obiekt blob.
    • Jeśli folder ma taką samą nazwę jak istniejący kontener, zawartość folderu zostanie scalona z zawartością kontenera. Pliki lub obiekty blob, które nie znajdują się jeszcze w chmurze, są dodawane do kontenera. Jeśli plik lub obiekt blob ma taką samą nazwę jak plik lub obiekt blob, który znajduje się już w kontenerze, istniejący plik lub obiekt blob zostanie zastąpiony.
    • Przekazywanie do obiektu blob w warstwie Archiwum zakończy się niepowodzeniem, jeśli kontener ma zarchiwizowany obiekt blob o tej samej nazwie. Gdy obiekt blob znajduje się w warstwie Archiwum, nie można go odczytać ani zmodyfikować. Jeśli musisz zastąpić obiekt blob, upewnij się, że obiekt blob nie jest ustawiony na archiwum. Aby uzyskać więcej informacji, zobacz Warstwa dostępu Archiwum.
    • Każda pusta hierarchia katalogów (bez żadnych plików) utworzona w StorageAccount_BlockBlob i foldery StorageAccount_PageBlob nie są przekazywane.
  • Importowanie danych do udziałów plików platformy Azure NFS nie jest obsługiwane przez usługę Azure Data Box. Kopiowanie danych z urządzenia Data Box do istniejącego udziału plików platformy Azure NFS o identycznej nazwie, ponieważ folder źródłowy powoduje konflikt. Aby rozwiązać ten konflikt, usługa Data Box zmienia nazwę udziału databox-<GUID> źródłowego na i przekazuje go na docelowe konto magazynu jako udział plików platformy Azure SMB.
  • Jeśli używasz protokołów SMB i NFS do kopiowania danych, zalecamy:
    • Użyj różnych kont magazynu dla protokołu SMB i systemu plików NFS.
    • Nie kopiuj tych samych danych do tego samego miejsca docelowego na platformie Azure przy użyciu protokołu SMB i NFS. W takich przypadkach nie można określić ostatecznego wyniku.
    • Mimo że kopiowanie za pośrednictwem protokołu SMB i NFS równolegle może działać, nie zalecamy wykonywania tego, ponieważ jest podatny na błędy człowieka. Przed rozpoczęciem kopiowania danych NFS zaczekaj na ukończenie kopiowania danych SMB.
  • Zarządzanie przekazywaniem:
    • Jeśli podczas przekazywania danych na platformę Azure występują błędy, w docelowym koncie magazynu zostanie utworzony dziennik błędów. Ścieżka do tego dziennika błędów jest dostępna po zakończeniu przekazywania i możesz przejrzeć dziennik, aby podjąć działania naprawcze. Nie usuwaj danych ze źródła bez weryfikowania przekazanych danych.
    • Metadane plików i uprawnienia systemu plików NTFS można zachować, gdy dane są przekazywane do usługi Azure Files, korzystając ze wskazówek w artykule Zachowywanie list ACL plików, atrybutów i sygnatur czasowych za pomocą usługi Azure Data Box.
    • Hierarchia plików jest utrzymywana podczas przekazywania do chmury zarówno dla obiektów blob, jak i usługi Azure Files. Na przykład skopiowano plik w tej ścieżce: <container folder>\A\B\C.txt. Ten plik jest przekazywany do tej samej ścieżki w chmurze.
    • Jeśli pole CreateTime lub LastWriteTime dla pliku przekracza dozwolony rozmiar podczas przekazywania: "Fri, 31 Dec 9999 23:59:59" zastępuje oryginalną datę we właściwości pliku platformy Azure. Przekazywanie pliku zakończy się pomyślnie i nie zostanie zgłoszony żaden błąd.

Limity rozmiaru konta usługi Azure Storage

Poniżej przedstawiono limity rozmiaru danych skopiowanych na konto magazynu. Upewnij się, że przekazane dane są zgodne z tymi limitami. Aby uzyskać najbardziej aktualne informacje na temat tych limitów, zobacz Cele dotyczące skalowalności i wydajności dla usługi Blob Storage oraz cele dotyczące skalowalności i wydajności usługi Azure Files.

Rozmiar danych skopiowanych na konto usługi Azure Storage Limit domyślny
Blokowy obiekt blob i stronicowy obiekt blob Maksymalny limit jest taki sam jak limit magazynu zdefiniowany dla subskrypcji platformy Azure i obejmuje dane ze wszystkich źródeł, w tym urządzenia Data Box.
Azure Files Usługa Data Box obsługuje udziały plików platformy Azure w warstwie Premium, które umożliwiają łącznie 100 TiB dla wszystkich udziałów na koncie magazynu. Maksymalna pojemność do wykorzystania jest nieco mniejsza ze względu na miejsce, w których są używane dzienniki kopiowania i dzienników inspekcji. Co najmniej 100 GiB każdy jest zarezerwowany dla dziennika kopiowania i dziennika inspekcji. Aby uzyskać więcej informacji, zobacz Dzienniki inspekcji dla usługi Azure Data Box, Azure Data Box Heavy. Wszystkie foldery w StorageAccount_AzFile muszą być zgodne z tym limitem. Aby uzyskać więcej informacji, zobacz Tworzenie udziału plików platformy Azure.

Limity rozmiaru obiektów platformy Azure

Poniżej przedstawiono rozmiary obiektów platformy Azure, które można zapisać. Upewnij się, że wszystkie przekazane pliki są zgodne z tymi limitami.

Typ obiektu platformy Azure Limit domyślny
Blokowy obiekt blob 14 TiB
Stronicowy obiekt blob 4 TiB
Każdy plik przekazany w formacie stronicowego obiektu blob musi mieć 512 bajtów wyrównanych (całkowita wielokrotna), a przekazywanie kończy się niepowodzeniem.
Dyski VHD i VHDX są wyrównane o 512 bajtów.
Azure Files 4 TiB
dyski zarządzane 4 TiB
Aby uzyskać więcej informacji na temat rozmiaru i limitów, zobacz:
  • Cele skalowalności dysków SSD w warstwie Standardowa
  • Cele skalowalności dysków SSD w warstwie Premium
  • Cele skalowalności dysków HDD w warstwie Standardowa
  • Cennik i rozliczenia dysków zarządzanych
    		•

    Konwencje nazewnictwa blokowych obiektów blob, stronicowych obiektów blob i plików

    Encja Konwencje
    Nazwy kontenerów dla blokowych obiektów blob i stronicowych obiektów blob Musi być prawidłową nazwą DNS o długości od 3 do 63 znaków.
    Musi zaczynać się literą lub cyfrą.
    Może zawierać tylko małe litery, cyfry i łącznik (-).
    Bezpośrednio przed łącznikiem (-) i bezpośrednio po nim musi znajdować się cyfra lub litera.
    Kolejne łączniki nie są dozwolone w nazwach.
    Nazwy udziałów dla usługi Azure Files Jak wyżej
    Nazwy katalogów i plików dla usługi Azure Files
  • Zachowanie wielkości liter, bez uwzględniania wielkości liter i nie może przekraczać 255 znaków.
  • Nie można zakończyć ukośnikiem do przodu (/).
  • Jeśli zostanie podana, zostanie ona automatycznie usunięta.
  • Następujące znaki nie są dozwolone: " \ / : | < > * ?
  • Zastrzeżone znaki adresów URL muszą być poprzedzone odpowiednim znakiem ucieczki.
  • Niedozwolone znaki ścieżki adresu URL nie są dozwolone. Punkty kodu, takie jak \uE000, nie są prawidłowymi znakami Unicode. Niektóre znaki ASCII lub Unicode, takie jak znaki sterujące (0x00 do 0x1F, \u0081 itp.), są również niedozwolone. Aby uzyskać reguły dotyczące ciągów Unicode w protokole HTTP/1.1, zobacz RFC 2616, Sekcja 2.2: Podstawowe reguły i RFC 3987.
  • Następujące nazwy plików nie są dozwolone: LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM8, COM9, PRN, AUX, NUL, CON, CLOCK$, znak kropki (.).
    		•
    Nazwy blokowych i stronicowych obiektów blob
  • W nazwach obiektów blob jest rozróżniana wielkość liter. Mogą zawierać dowolną kombinację znaków.
  • Nazwa obiektu blob musi zawierać od 1 do 1024 znaków.
  • Zastrzeżone znaki adresów URL muszą być poprzedzone odpowiednim znakiem ucieczki.
  • Liczba segmentów ścieżki w nazwie obiektu blob nie może przekraczać 254. Segment ścieżki to ciąg znajdujący się pomiędzy następującymi po sobie znakami ogranicznika (na przykład ukośnikami „/”), co odpowiada nazwie katalogu wirtualnego.
    		•