Limieten voor Azure Data Box Heavy

  • Artikel

Houd rekening met deze limieten wanneer u uw Azure Data Box Heavy-apparaat implementeert en gebruikt. In de volgende tabel worden deze limieten voor de Data Box beschreven.

Data Box Heavy-servicelimieten

  • Als u meerdere opslagaccounts gebruikt met de Data Box-service, moeten alle opslagaccounts deel uitmaken van dezelfde Azure-regio.
  • U wordt aangeraden niet meer dan drie opslagaccounts te gebruiken. Het gebruik van meer opslagaccounts kan mogelijk van invloed zijn op de prestaties.

Data Box Heavy-limieten

  • Data Box Heavy kan maximaal 1 miljard bestanden per knooppunt opslaan.
  • Data Box Heavy ondersteunt maximaal 512 containers of shares per knooppunt in de cloud. De mappen op het hoogste niveau binnen de gebruikersshare worden containers of Azure-bestandsshares in de cloud.

Limieten voor Azure Storage

In deze sectie worden de limieten voor de Azure Storage-service en de vereiste naamconventies voor Azure Files, Azure-blok-blobs en Azure-pagina-blobs beschreven, zoals van toepassing op de Data Box-service. Controleer de opslaglimieten zorgvuldig en volg alle aanbevelingen.

Voor de meest recente informatie over limieten en aanbevolen procedures voor azure-opslagservices voor het benoemen van shares, containers en bestanden, gaat u naar:

Belangrijk

Als er bestanden of mappen zijn die de limieten van de Azure Storage-service overschrijden of niet voldoen aan de naamconventies van Azure Files/Blob, worden deze bestanden of mappen niet opgenomen in Azure Storage via de Data Box-service.

Voorbehouden voor het uploaden van gegevens

  • Containers, shares en mappen:
    • Kopieer geen bestanden rechtstreeks naar een van de vooraf gemaakte shares. U moet een map maken onder de share en vervolgens bestanden naar die map kopiëren.
    • Een map onder de StorageAccount_BlockBlob en StorageAccount_PageBlob is een container. Containers worden bijvoorbeeld gemaakt als StorageAccount_BlockBlob/container en StorageAccount_PageBlob/container.
    • Elke map die rechtstreeks onder StorageAccount_AzFile wordt gemaakt, wordt omgezet in een Azure-bestandsshare.
    • Azure Blob Storage biedt geen ondersteuning voor directory's. Als u een map maakt onder de StorageAccount_BlockBlob map, worden virtuele mappen gemaakt in de blobnaam. Voor Azure Files wordt de werkelijke mapstructuur gehandhaafd.
  • Inhoud van de map samenvoegen:
    • Elk bestand dat in StorageAccount_BlockBlob en StorageAccount_PageBlob shares wordt geschreven, wordt geüpload als respectievelijk een blok-blob en pagina-blob.
    • Als een map dezelfde naam heeft als een bestaande container, wordt de inhoud van de map samengevoegd met de inhoud van de container. Bestanden of blobs die zich nog niet in de cloud bevinden, worden toegevoegd aan de container. Als een bestand of blob dezelfde naam heeft als een bestand of blob die zich al in de container bevindt, wordt het bestaande bestand of de bestaande blob overschreven.
    • Uploaden naar een blob in de archieflaag mislukt als de container een bestaande gearchiveerde blob met dezelfde naam heeft. Hoewel een blob zich in de archieflaag bevindt, kan deze niet worden gelezen of gewijzigd. Als u een blob wilt overschrijven, moet u ervoor zorgen dat de blob niet is ingesteld op archiveren. Zie archieftoegangslaag voor meer informatie.
    • Lege mappenhiërarchie (zonder bestanden) die zijn gemaakt onder StorageAccount_BlockBlob en StorageAccount_PageBlob mappen worden niet geüpload.
  • Het importeren van gegevens in NFS Azure-bestandsshares wordt niet ondersteund door Azure Data Box. Het kopiëren van gegevens uit Data Box naar een bestaande NFS Azure-bestandsshare met een identieke naam als uw bronmap een conflict veroorzaakt. Om dit conflict op te lossen, wijzigt Data Box de naam van de bronshare databox-<GUID> in en uploadt deze naar het doelopslagaccount als een SMB Azure-bestandsshare.
  • Als u zowel de SMB- als NFS-protocollen voor gegevenskopieën gebruikt, raden we u aan:
    • Gebruik verschillende opslagaccounts voor SMB en NFS.
    • Kopieer niet dezelfde gegevens naar dezelfde eindbestemming in Azure met zowel SMB als NFS. In dergelijke gevallen kan de definitieve uitkomst namelijk niet worden vastgesteld.
    • Hoewel kopiëren via zowel SMB als NFS parallel kan werken, raden we dit niet aan, omdat het gevoelig is voor menselijke fouten. Wacht totdat het kopiëren van SMB-gegevens is voltooid voordat u een NFS-gegevenskopie start.
  • Uploadbeheer:
    • Om de prestaties tijdens het uploaden van gegevens te verbeteren, raden we u aan grote bestandsshares in het opslagaccount in te schakelen en de capaciteit van de share te verhogen tot 100 TiB.
    • Als er fouten zijn bij het uploaden van gegevens naar Azure, wordt er een foutenlogboek gemaakt in het doelopslagaccount. Het pad naar dit foutenlogboek is beschikbaar wanneer het uploaden is voltooid en u kunt het logboek controleren om corrigerende actie te ondernemen. Verwijder geen gegevens uit de bron zonder de geüploade gegevens te verifiëren.
    • Bestandsmetagegevens en NTFS-machtigingen kunnen worden bewaard wanneer de gegevens worden geüpload naar Azure Files met behulp van richtlijnen voor het behouden van bestands-ACL's, kenmerken en tijdstempels met Azure Data Box.
    • De hiërarchie van de bestanden wordt onderhouden tijdens het uploaden naar de cloud voor zowel blobs als Azure Files. U hebt bijvoorbeeld een bestand gekopieerd op dit pad: <container folder>\A\B\C.txt. Dit bestand wordt geüpload naar hetzelfde pad in de cloud.
    • Als het veld CreateTime of LastWriteTime voor een bestand groter is dan de toegestane grootte tijdens het uploaden, vervangt 'Vr, 31 dec 9999 23:59:59' de oorspronkelijke datum in de Azure-bestandseigenschap. Het uploaden van het bestand slaagt en er wordt geen fout gegenereerd.

Groottelimieten voor Azure-opslagaccounts

Hier volgen de limieten voor de grootte van de gegevens die worden gekopieerd naar een opslagaccount. Zorg ervoor dat de gegevens die u uploadt, voldoen aan deze limieten. Zie Schaalbaarheids- en prestatiedoelen voor Blob Storage en Azure Files schaalbaarheids- en prestatiedoelen voor de meest recente informatie over deze limieten.

De grootte van de gegevens die zijn gekopieerd naar een Azure-opslagaccount Standaardlimiet
Blok-blob en pagina-blob De maximale limiet is hetzelfde als de opslaglimiet die is gedefinieerd voor het Azure-abonnement en bevat gegevens uit alle bronnen, waaronder Data Box.
Azure Files
  • Data Box ondersteunt grote bestandsshares (100 TiB) indien ingeschakeld voordat de Data Box-bestelling wordt gemaakt.
  • Data Box ondersteunt Azure Premium-bestandsshares, waardoor in totaal 100 TiB voor alle shares in het opslagaccount is toegestaan.

Azure-objectgroottelimieten

Hier volgen de grootten van de Azure-objecten die kunnen worden geschreven. Zorg ervoor dat alle bestanden die zijn geüpload, voldoen aan deze limieten.

Azure-objecttype Standaardlimiet
Blok-blob 14 TiB
Pagina-blob 4 TiB
Elk bestand dat in de pagina-blob-indeling is geüpload, moet 512 bytes zijn uitgelijnd (een integraal veelvoud), anders mislukt het uploaden.
VHD en VHDX zijn 512 bytes uitgelijnd.
Azure Files 4 TiB
Beheerde schijven 4 TiB
Zie voor meer informatie over grootte en limieten:
  • Schaalbaarheidsdoelen van Standard-SCHIJVEN
  • Schaalbaarheidsdoelen van Premium SSD's
  • Schaalbaarheidsdoelen van Standard-HDD's
  • Prijzen en facturering van beheerde schijven
    		•

    Azure-blok-blob, pagina-blob en naamconventies voor bestanden

    Entity Conventies
    Containernamen voor blok-blob en pagina-blob Moet een geldige DNS-naam zijn van 3 tot 63 tekens.
    Moet beginnen met een letter of cijfer.
    Mag alleen kleine letters, cijfers en het afbreekstreepje (-) bevatten.
    Elk koppelteken (-) moet direct worden voorafgegaan en gevolgd door een letter of cijfer.
    Opeenvolgende afbreekstreepjes zijn niet toegestaan in namen.
    Namen voor Azure-bestanden delen Hetzelfde als hierboven
    Map- en bestandsnamen voor Azure-bestanden
  • Hoofdlettergevoelig en mag niet langer zijn dan 255 tekens.
  • Kan niet eindigen met de slash (/).
  • Indien opgegeven, wordt deze automatisch verwijderd.
  • De volgende tekens zijn niet toegestaan: " \ / : | < > * ?
  • Gereserveerde tekens voor URL's moeten op de juiste wijze van een escape-teken zijn voorzien.
  • Ongeldige URL-padtekens zijn niet toegestaan. Codepunten zoals \uE000 zijn geen geldige Unicode-tekens. Sommige ASCII- of Unicode-tekens, zoals besturingstekens (0x00 tot 0x1F, \u0081, enzovoort), zijn ook niet toegestaan. Zie RFC 2616, sectie 2.2: Basisregels en RFC 3987 voor regels voor Unicode-tekenreeksen in HTTP/1.1.
  • De volgende bestandsnamen zijn niet toegestaan: LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, PRN, AUX, NUL, CON, CLOCK$, dot character (.) en twee punttekens (.).).
    		•
    Blobnamen voor blok-blob en pagina-blob
  • Blobnamen zijn hoofdlettergevoelig en kunnen elke combinatie van tekens bevatten.
  • Een blobnaam moet 1 tot 1024 tekens bevatten.
  • Gereserveerde tekens voor URL's moeten op de juiste wijze van een escape-teken zijn voorzien.
  • Het aantal padsegmenten dat de blobnaam omvat, mag niet meer dan 254 zijn. Een padsegment is de tekenreeks tussen opeenvolgende scheidingstekens (bijvoorbeeld de slash '/') die overeenkomt met de naam van een virtuele map.
    		•