Dela via

Gränser för Azure Data Box

  • Artikel

Tänk på de här gränserna när du distribuerar och använder Din Microsoft Azure Data Box. I följande tabell beskrivs dessa gränser för Data Box.

Data Box-tjänstbegränsningar

  • Om du använder flera lagringskonton med Data Box-tjänsten ska alla lagringskonton tillhöra samma Azure-region.
  • Vi rekommenderar att du inte använder fler än tre lagringskonton. Att använda fler lagringskonton kan potentiellt påverka prestandan.

Data Box-gränser

  • Data Box kan lagra högst 500 miljoner filer för både import och export.
  • Data Box stöder högst 512 containrar eller resurser i molnet. De översta katalogerna i användarresursen blir containrar eller Azure-filresurser i molnet.
  • Data Box-användningskapaciteten kan vara mindre än 80 TiB på grund av förbrukning av ReFS-metadatautrymme.
  • Data Box stöder högst 10 klientanslutningar åt gången på en NFS-resurs (Network File System).

Azure Storage-gränser

I det här avsnittet beskrivs gränserna för Azure Storage-tjänsten och de namngivningskonventioner som krävs för Azure Files, Azure-blockblobar och Azure-sidblobar, i tillämpliga fall för Data Box-tjänsten. Granska lagringsgränserna noggrant och följ alla rekommendationer.

Den senaste informationen om begränsningar och metodtips för namngivning av resurser, containrar och filer i Azure-lagringstjänsten finns i:

Viktigt!

Om det finns filer eller kataloger som överskrider Azure Storage-tjänstens gränser eller inte följer namngivningskonventionerna för Azure Files/Blob matas inte dessa filer eller kataloger in i Azure Storage via Data Box-tjänsten.

Varningar för datakopiering och uppladdning

För importorder

Data Box-varningar för en importorder inkluderar:

  • Containrar, resurser och mappar:
    • Kopiera inte filer direkt till någon av de förskapade resurserna. Du måste skapa en mapp under resursen och sedan kopiera filer till den mappen.
    • En mapp under StorageAccount_BlockBlob och StorageAccount_PageBlob är en container. Containrar skapas till exempel som StorageAccount_BlockBlob/container och StorageAccount_PageBlob/container.
    • Varje mapp som skapas direkt under StorageAccount_AzFile översätts till en Azure-filresurs.
    • Azure Blob Storage stöder inte kataloger. Om du skapar en mapp under mappen StorageAccount_BlockBlob skapas virtuella mappar i blobnamnet. För Azure Files underhålls den faktiska katalogstrukturen.
  • Sammanfoga mappinnehåll:
    • Varje fil som skrivs till StorageAccount_BlockBlob och StorageAccount_PageBlob resurser laddas upp som en blockblob respektive sidblob.
    • Om en mapp har samma namn som en befintlig container sammanfogas mappens innehåll med containerns innehåll. Filer eller blobar som inte redan finns i molnet läggs till i containern. Om en fil eller blob har samma namn som en fil eller blob som redan finns i containern skrivs den befintliga filen eller bloben över.
    • En uppladdning till en blob på arkivnivån misslyckas om containern har en befintlig arkiverad blob med samma namn. När en blob finns på arkivnivån kan den inte läsas eller ändras. Om du behöver skriva över en blob kontrollerar du att bloben inte är inställd på arkivering. Mer information finns i Arkivåtkomstnivå.
    • Alla tomma kataloghierarkier (utan filer) som skapats under StorageAccount_BlockBlob och StorageAccount_PageBlob mappar laddas inte upp.
  • Import av data till NFS Azure-filresurser stöds inte av Azure Data Box. Att kopiera data från Data Box till en befintlig NFS Azure-filresurs med ett identiskt namn eftersom källmappen skapar en konflikt. För att lösa den här konflikten byter Data Box namn på källresursen till databox-<GUID> och laddar upp den till mållagringskontot som en SMB Azure-filresurs.
  • Om du använder både SMB- och NFS-protokollen för datakopior rekommenderar vi att du:
    • Använd olika lagringskonton för SMB och NFS.
    • Kopiera inte samma data till samma slutmål i Azure med både SMB och NFS. I sådana fall kan slutresultatet inte fastställas.
    • Även om kopiering via både SMB och NFS parallellt kan fungera rekommenderar vi inte att du gör det eftersom det är utsatt för mänskliga fel. Vänta tills SMB-datakopian är klar innan du startar en NFS-datakopia.
  • Hantering av uppladdning:
    • Om det uppstår fel vid uppladdning av data till Azure skapas en fellogg i mållagringskontot. Sökvägen till den här felloggen är tillgänglig när uppladdningen är klar och du kan granska loggen för att vidta korrigerande åtgärder. Ta inte bort data från källan utan att verifiera de uppladdade data.
    • Filmetadata och NTFS-behörigheter kan bevaras när data laddas upp till Azure Files med hjälp av vägledning i Bevara fil-ACL:er, attribut och tidsstämplar med Azure Data Box.
    • Hierarkin för filerna underhålls vid uppladdning till molnet för både blobar och Azure Files. Du kopierade till exempel en fil på den här sökvägen: <container folder>\A\B\C.txt. Den här filen laddas upp till samma sökväg i molnet.
    • Om fältet CreateTime eller LastWriteTime för en fil överskrider den tillåtna storleken under en uppladdning ersätter "Fre, 31 dec 9999 23:59:59" det ursprungliga datumet i Azure-filegenskapen. Filuppladdningen lyckas och inget fel utlöses.

För exportordning

Data Box-varningar för en exportorder inkluderar:

  • Data Box är en Windows-baserad enhet och stöder inte skiftlägeskänsliga filnamn. Du kan till exempel ha två olika filer i Azure med namn som bara skiljer sig åt i höljet. Använd inte Data Box för att exportera filer som filerna skrivs över på enheten.
  • Om du har duplicerade taggar i indatafiler eller taggar som refererar till samma data kan Data Box-exporten hoppa över eller skriva över filerna. Antalet filer och storleken på data som visas i Azure-portalen kan skilja sig från den faktiska storleken på data på enheten.
  • Data Box exporterar data till Windows-baserat system via SMB-protokollet (Server Message Block) och begränsas av SMB-begränsningar för filer och mappar. Filer och mappar med namn som inte stöds exporteras inte.
  • Det finns en 1:1-mappning från prefix till container.
  • Maximal filnamnsstorlek är 1 024 tecken. Filnamn som överskrider den här längden exporteras inte.
  • Duplicerade prefix i XML-filen (som laddades upp när ordern skapades) exporteras. Duplicerade prefix ignoreras inte.
  • Sidblobar och containernamn är skiftlägeskänsliga. Om höljet inte matchar hittas inte bloben och/eller containern.

Storleksbegränsningar för Azure Storage-konton

Här är gränserna för storleken på de data som kopieras till ett lagringskonto. Kontrollera att de data du laddar upp överensstämmer med dessa gränser. Den senaste informationen om dessa gränser finns i Skalbarhets- och prestandamål för Blob Storage och Skalbarhets- och prestandamål för Azure Files.

Storleken på data som kopieras till Azure Storage-kontot Standardgräns
Blockblob och sidblob Maxgränsen är densamma som den lagringsgräns som definierats för Azure-prenumerationen och innehåller data från alla källor, inklusive Data Box.
Azure Files Data Box stöder Azure Premium-filresurser, vilket tillåter totalt 100 TiB för alla resurser i lagringskontot. Maximal användbar kapacitet är något mindre på grund av det utrymme som kopieringsloggar och granskningsloggar använder. Minst 100 GiB är reserverat för kopieringsloggen och granskningsloggen. Mer information finns i Granskningsloggar för Azure Data Box, Azure Data Box Heavy. Alla mappar under StorageAccount_AzFile måste följa den här gränsen. Mer information finns i Skapa en Azure-filresurs.

Storleksbegränsningar för Azure-objekt

Här är storleken på de Azure-objekt som kan skrivas. Kontrollera att alla filer som laddas upp överensstämmer med dessa gränser.

Azure-objekttyp Standardgräns
Blockblob 14 TiB
Sidblob 4 TiB
Varje fil som laddas upp i sidblobformat måste vara 512 byte justerad (en integrerad multipel), annars misslyckas uppladdningen.
VHD och VHDX är 512 byte justerade.
Azure Files 4 TiB
Hanterade diskar 4 TiB
Mer information om storlek och gränser finns i:
  • Skalbarhetsmål för Standard SSD
  • Skalbarhetsmål för Premium SSD
  • Skalbarhetsmål för standard-HDD:ar
  • Priser och fakturering för hanterade diskar
    		•

    Namngivningskonventioner för Azure-blockblob, sidblob och fil

    Enhet Praxis
    Containernamn för blockblob och sidblob Måste vara ett giltigt DNS-namn som är mellan 3 och 63 tecken långt.
    Måste börja med en bokstav eller en siffra.
    Får endast innehålla gemener, siffror och bindestreck (-).
    Varje bindestreck (-) måste föregås och följas av en bokstav eller siffra.
    På varandra följande bindestreck tillåts inte i namn.
    Dela namn för Azure-filer Samma som ovan
    Katalog- och filnamn för Azure-filer
  • Skiftlägesbevarande, skiftlägeskänsligt och får inte överstiga 255 tecken.
  • Det går inte att avsluta med snedstrecket (/).
  • Om den tillhandahålls tas den bort automatiskt.
  • Följande tecken tillåts inte: " \ / : | < > * ?
  • Reserverade URL-tecken måste undantas korrekt.
  • Ogiltiga URL-sökvägstecken tillåts inte. Kodpunkter som \uE000 är inte giltiga Unicode-tecken. Vissa ASCII- eller Unicode-tecken, till exempel kontrolltecken (0x00 till 0x1F, \u0081 osv.), tillåts inte heller. Regler för Unicode-strängar i HTTP/1.1 finns i RFC 2616, avsnitt 2.2: Grundläggande regler och RFC 3987.
  • Följande filnamn tillåts inte: LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, PRN, AUX, NUL, CON, CLOCK$, punkttecken (.) och två punkttecken (..).
    		•
    Blobnamn för blockblobar och sidblobar
  • Blobnamn är skiftlägeskänsliga och kan innehålla valfri kombination av tecken.
  • Ett blobnamn måste vara mellan 1 och 1 024 tecken långt.
  • Reserverade URL-tecken måste undantas korrekt.
  • Antalet sökvägssegment som blobnamnet består av får inte överskrida 254. Ett segment är strängen mellan avgränsningstecken (till exempel snedstreck ”/”) som motsvarar namnet på en virtuell katalog.
    		•