Dela via

Begränsningar för Azure Data Box Heavy

  • Artikel

Tänk på dessa gränser när du distribuerar och använder din Azure Data Box Heavy-enhet. I följande tabell beskrivs dessa gränser för Data Box.

Begränsningar för Data Box Heavy-tjänsten

  • 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 Heavy-gränser

  • Data Box Heavy kan lagra högst 1 miljard filer per nod.
  • Data Box Heavy stöder högst 512 containrar eller resurser per nod i molnet. De översta katalogerna i användarresursen blir containrar eller Azure-filresurser i molnet.

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 datauppladdning

  • 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.

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.
    		•