Megosztás a következőn keresztül:


Objektumreplikálás blokkblobokhoz

Az objektumreplikálás aszinkron módon másolja a blokkblobokat egy forrás storage fiók és egy célfiók között. Az objektumreplikálás által támogatott egyes forgatókönyvek a következők:

  • A késés minimalizálása. Az objektumreplikálás csökkentheti az olvasási kérelmek késését azáltal, hogy lehetővé teszi az ügyfelek számára, hogy egy közelebbi fizikai közelségben lévő régióból származó adatokat használjanak fel.
  • A számítási feladatok hatékonyságának növelése. Az objektumreplikálással a számítási feladatok különböző régiókban is feldolgozhatják ugyanazokat a blokkblobokat.
  • Az adateloszlás optimalizálása. Az adatokat egyetlen helyen dolgozhatja fel vagy elemezheti, majd csak az eredményeket replikálhatja további régiókba.
  • Költségek optimalizálása. Az adatok replikálása után csökkentheti a költségeket, ha életciklus-kezelési szabályzatok használatával áthelyezi azokat az archív szintre.

Az alábbi ábra azt mutatja be, hogyan replikálja az objektumreplikálás a blokkblobokat egy forrás storage-fiókból két különböző régióban lévő célfiókokra.

Az objektumreplikálás működését bemutató ábra.

Az objektumreplikálás konfigurálásáról az objektumreplikálás konfigurálása című témakörben olvashat.

Az objektumreplikálás előfeltételei és kikötései

Az objektumreplikáláshoz a következő Azure Storage funkciók is engedélyezve vannak:

A változási napló és a blob verziószámozásának engedélyezése további költségekkel járhat. További információ: Azure Storage díjszabási oldal.

Az objektumreplikálás általános célú v2 storage fiókokhoz és prémium szintű blokkblobfiókokhoz támogatott. A forrás- és a célfióknak általános célú v2 vagy prémium szintű blokkblobfióknak kell lennie. Az objektumreplikálás csak a blokkblobokat támogatja; a hozzáfűző blobok és lapblobok nem támogatottak.

Az objektumreplikálás olyan fiókok esetében támogatott, amelyek microsoft által felügyelt vagy ügyfél által felügyelt kulcsokkal vannak titkosítva. További információ az ügyfél által felügyelt kulcsokról: Customer által felügyelt kulcsok Azure Storage titkosításhoz.

Az objektumreplikálás nem támogatott az ügyfél által megadott kulccsal titkosított forrásfiókban lévő blobok esetében. További információ az ügyfél által megadott kulcsokról: Titkosítási kulcs megadása Blob Storage tárhelyen.

Az ügyfél által felügyelt feladatátvétel sem a forrás-, sem a célfiók esetében nem támogatott objektumreplikációs szabályzatban.

Az objektumreplikálás még nem támogatott azokban a fiókokban, amelyeken engedélyezve van a hierarchikus névtér.

Az objektumreplikálás nem támogatott az Data Lake Storage API-k használatával feltöltött blobok esetében.

Az objektumreplikálás működése

Az objektumreplikálás aszinkron módon másolja a blokkblobokat egy tárolóba a konfigurált szabályok szerint. A blob tartalma, a blobhoz társított verziók, valamint a blob metaadatai és tulajdonságai mind át lesznek másolva a forrástárolóból a céltárolóba.

Fontos

Mivel a blokkblobadatok aszinkron módon replikálódnak, a forrásfiók és a célfiók nincs azonnal szinkronizálva.

Az OR mostantól támogatja a prioritási replikációt, amely az OR-házirendben lévő összes művelet replikálását rangsorolja. Ha az OR prioritású replikáció engedélyezve van, az összes művelet replikációs teljesítménye javul. Ha egy replikációs szabályzat forrás- és célfiókja ugyanazon a kontinensen található, az OR prioritásos replikáció 15 percen belül replikálja az objektumok 99,0% a támogatott számítási feladatokhoz. A szolgáltatások teljesítménye szolgáltatásszint-szerződéssel (SLA) garantált. További információkért tekintse meg az SLA feltételeit és az objektumreplikáció prioritásáról szóló cikket.

A forrásblob replikációs állapotát is ellenőrizheti annak megállapításához, hogy a replikáció befejeződött-e. További információ: Blob replikációs állapotának ellenőrzése.

Blob verziókezelés

Az objektumreplikáláshoz engedélyezni kell a blobok verziószámozását a forrás- és célfiókokon is. A forrásfiók replikált blobjának módosításakor a blob új verziója jön létre a forrásfiókban, amely a blob előző állapotát tükrözi a módosítás előtt. A forrásfiók aktuális verziója a legújabb frissítéseket tükrözi. A rendszer az aktuális és az előző verziót is replikálja a célfiókba. Az írási műveletek blobverziókra gyakorolt hatásáról további információt az írási műveletek verziószámozása című témakörben talál.

Ha a storage-fiókjában érvényben vannak az objektumreplikációs szabályzatok, nem tilthatja le a blobok verziószámozását az adott fiókhoz. A blobok verziószámozásának letiltása előtt törölnie kell a fiók objektumreplikációs szabályzatát.

Megjegyzés

A program csak a blobokat másolja a célhelyre. A blob verzióazonosítója nem másolódik. Miután egy blobot a célhelyre helyezett, egy új verzióazonosító lesz hozzárendelve.

Blob törlése a forrásfiókban

A forrásfiókban lévő blob törlésekor a blob aktuális verziója korábbi verzióvá válik, és már nincs aktuális verzió. A blob összes meglévő korábbi verziója megmarad. Ezt az állapotot a rendszer a célfiókba replikálja. A törlési műveletek blobverziókra gyakorolt hatásáról további információt a Törlési műveletek verziószámozása című témakörben talál.

Pillanatképek

Az objektumreplikálás nem támogatja a blob pillanatképeit. A forrásfiókban lévő blobok pillanatképei nem replikálódnak a célfiókba.

Blob index címkék

Az objektumreplikálás mostantól támogatja az indexcímkék másolását a forrásblobokból a célblobokba. Ezt a képességet egy új vagy meglévő replikációs szabály részeként konfigurálhatja. További információ: Objektumreplikálás konfigurálása.

Fontos

A címkereplikációs szolgáltatás jelenleg előzetes verzióban érhető el. Az Supplemental Terms of Use for Microsoft Azure Previews című cikkben talál olyan jogi feltételeket, amelyek Azure bétaverziós, előzetes verziójú vagy egyébként általánosan még nem elérhető funkciókra vonatkoznak.

Blob rétegezés

Az objektumreplikálás akkor támogatott, ha a forrás- és célfiókok bármilyen online szinten vannak (gyakori, ritka elérésű vagy archív). A forrás- és célfiókok különböző szinteken lehetnek. Az objektumreplikálás azonban meghiúsul, ha a forrás- vagy célfiókban lévő blob átkerül az archív szintre. Az archivált blobok rehidratálása nem indítja el az objektumreplikálást. Az objektumreplikáció csak akkor aktiválódik, ha a blobadatok újra frissülnek a rehidratálás után. További információ a blob szintekről: Blob adatok hozzáférési szintjei.

Nem módosítható blobok

A Azure Blob Storage nem módosítható szabályzatai közé tartoznak az időalapú adatmegőrzési szabályzatok és a jogi visszatartások. Ha módosíthatatlansági szabályzat lép érvénybe a célfiókon, az objektumreplikáció is érintett lehet. Az immutability szabályzatokkal kapcsolatos további információkért lásd: Az üzletileg kritikus blob adatok tárolása nem módosítható tárhellyel.

Ha a céltároló tárolószintű nem módosíthatósági szabályzattal rendelkezik, a forrástároló objektumainak módosításai, például a frissítések vagy a törlések továbbra is sikeresek lehetnek. Előfordulhat azonban, hogy ezek a módosítások nem replikálódnak a céltárolóba a nem módosíthatósági korlátozás miatt. További információ arról, hogy mely műveletek tilthatók egy tárolóra hatókörrel rendelkező módosíthatatlansági szabályzattal, tekintse meg a tárolószintű hatókörrel rendelkező forgatókönyveket.

Ha a célfiók blobverziója aktív verziószintű megváltoztathatatlansági szabályzattal rendelkezik, a megfelelő forrástároló blobverzióján végrehajtott törlési vagy frissítési művelet sikeres lehet. A művelet célobjektumba történő replikálása azonban meghiúsul. Ha többet szeretne tudni arról, hogy mely műveletek tiltottak egy tárolóra hatókörrel rendelkező módosíthatatlansági szabályzattal, tekintse meg a verziószintű hatókörrel rendelkező forgatókönyveket.

Objektumreplikációs szabályzatok és szabályok

Az objektumreplikálás konfigurálásakor létre kell hoznia egy replikációs szabályzatot, amely meghatározza a forrás storage fiókot és a célfiókot. A replikációs szabályzatok egy vagy több olyan szabályt tartalmaznak, amelyek egy forrás- és céltárolót határoznak meg, és jelzik, hogy mely forrásblobok replikálódnak.

Az objektumreplikálás konfigurálása után Azure Storage rendszeresen ellenőrzi a forrásfiók változáscsatornáját, és aszinkron módon replikálja az írási vagy törlési műveleteket a célfiókba. A replikáció késése a replikált blokkblob méretétől függ.

Replikációs szabályzatok

Az objektumreplikálás konfigurálásakor replikációs szabályzatot hoz létre a célfiókon a Azure Storage erőforrás-szolgáltatón keresztül. A replikációs szabályzat létrehozása után Azure Storage hozzárendeli egy szabályzatazonosítóhoz. Ezt követően az azonosító használatával a replikációs szabályzatot a forrásfiókhoz kell társítania. A replikáció elvégzéséhez a forrás- és célfiókok házirend-azonosítójának meg kell egyeznie.

A forrásfiók nem replikálható kettőnél több célfiókba, és minden célfiókhoz egy szabályzat tartozik. Hasonlóképpen, egy fiók legfeljebb két replikációs házirend célfiókjaként szolgálhat.

A forrás- és célfiókok ugyanabban a régióban vagy különböző régiókban lehetnek. Előfordulhat, hogy ugyanabban az előfizetésben vagy különböző előfizetésekben is találhatók. Lehetséges, hogy a forrás- és célfiókok különböző Microsoft Entra bérlőkben találhatók. Az egyes forrásfiók-/célfiókpárokhoz csak egy replikációs szabályzat hozható létre.

Replikációs szabályok

A replikációs szabályok megadják, hogy Azure Storage hogyan replikálja a blobokat egy forrástárolóból egy céltárolóba. Az egyes replikációs szabályzatokhoz legfeljebb 1000 replikációs szabályt adhat meg. Minden replikációs szabály egyetlen forrás- és céltárolót határoz meg, és minden forrás- és céltároló csak egy szabályban használható. Ennek eredményeképpen legfeljebb 1000 forrástároló és 1000 céltároló vehet részt egyetlen replikációs szabályzatban.

A replikációs szabály létrehozása után a rendszer figyelmen kívül hagyja az előző blobokat; Alapértelmezés szerint csak a szabály létrehozása után hozzáadott új blokkblobok lesznek másolva. Megadhatja azonban, hogy az új és a meglévő blokkblobok is másolva legyenek. Megadhat egy egyéni másolási hatókört is, amely a megadott idő elteltével létrehozott blokkblobokat másolja.

Egy vagy több szűrőt is megadhat egy replikációs szabály részeként a blokkblobok előtagok szerinti szűréséhez. Előtag megadásakor a rendszer csak a forrástárolóban lévő előtaggal egyező blobokat másolja a céltárolóba.

A forrás- és céltárolóknak létezniük kell, mielőtt megadhatja őket egy szabályban. A replikációs szabályzat létrehozása után a céltárolóba történő írási műveletek nem engedélyezettek. A céltárolóba történő írásra tett kísérlet sikertelen lesz a következő hibakóddal: 409 (ütközés).

Ha replikációs szabályt tartalmazó céltárolóba szeretne írni, először le kell tiltania a replikációt. Letilthatja a szabályt a tároló törlésével vagy a teljes replikációs szabályzat eltávolításával.

A céltároló olvasási és törlési műveletei akkor engedélyezettek, ha a replikációs házirend aktív.

Meghívhatja a Blobréteg beállítása műveletet a céltároló egyik blobján, hogy áthelyezhesse az archív szintre. Az archív szinttel kapcsolatos további információkért lásd a blobadatok hozzáférési szintjeit.

Megjegyzés

A forrásfiókban lévő blob access szintjének módosítása nem módosítja a blob access szintjét a célfiókban.

Szabályzatdefiníciós fájl

Egy JSON-fájllal definiálhatók az objektumreplikációs szabályzatok. A szabályzatdefiníciós fájlt lekérheti egy meglévő objektumreplikációs szabályzatból, vagy létrehozhat egy objektumreplikációs szabályzatot egy szabályzatdefiníciós fájl feltöltésével.

Minta szabályzatdefiníciós fájl

Az alábbi példa egy replikációs szabályzatot állít be a célfiókon egy szabmánnyal. A szabály az előtaggal b rendelkező blobokat célozza meg, és meghatározza a replikáció minimális létrehozási idejét. Ne felejtse el lecserélni a szögletes zárójelben lévő értékeket a saját értékeire:

{
  "properties": {
    "policyId": "default",
    "sourceAccount": "/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
    "destinationAccount": "/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
    "metrics": {
		  "enabled": false
    },
    "priorityReplication": "false",
    "rules": [
      {
        "ruleId": "",
        "sourceContainer": "<source-container>",
        "destinationContainer": "<destination-container>",
        "filters": {
          "prefixMatch": [
            "b"
          ],
          "minCreationTime": "2021-08-28T00:00:00Z"
        }
      }
    ]
  }
}

Egyéni szűrők

A JSON-fájlban különböző beállításokkal rendelkező szűrők testre szabhatók

  1. A replikációhoz használt előtag blob, az összes blob b betűvel kezdődik:
"filters": {
          "prefixMatch": [
            "b"
          ],
        }
  1. Blob létrehozási ideje
"filters": {
  "minCreationTime": "2021-08-28T00:00:00Z"
}
  1. Az ÖSSZES BLOB esetén
"filters": {
  "minCreationTime": "1601-01-01T00:00:00Z"
}

Forrás- és célfiókok teljes erőforrásazonosítóinak megadása

A szabályzatdefiníciós fájl létrehozásakor adja meg a sourceAccount és destinationAccount bejegyzés teljes Azure Resource Manager erőforrásazonosítóit, ahogyan az az előző szakaszban bemutatott példában is látható. Az storage-fiók erőforrás-azonosítójának megkereséséről a A storage-fiók erőforrás-azonosítójának létrehozása című témakörben olvashat.

A teljes erőforrás-azonosító formátuma a következő:

/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>

A szabályzatdefiníciós fájlnak korábban csak a fiók nevét kellett megadnia a storage fiók teljes erőforrás-azonosítója helyett. A AllowCrossTenantReplication biztonsági tulajdonság a REST API Azure Storage erőforrás-szolgáltató 2021-02-01-es verziójában való bevezetésével meg kell adnia a teljes erőforrás-azonosítót minden olyan objektumreplikációs szabályzathoz, amely akkor jön létre, ha a bérlők közötti replikáció nem engedélyezett a replikációs házirendben részt vevő tárfiók számára. Azure Storage a teljes erőforrás-azonosítót használja annak ellenőrzésére, hogy a forrás- és célfiókok ugyanabban a bérlőben találhatók-e. A bérlők közötti replikációs szabályzatok letiltásának megakadályozásáról további információt a Replikáció megakadályozása Microsoft Entra bérlők között című témakörben talál.

Bár továbbra is csak a fióknév használata támogatott a bérlők közötti replikációhoz, Microsoft ajánlott eljárásként a teljes erőforrás-azonosító használatát javasolja. Az Azure Storage erőforrás-szolgáltató REST API korábbi verziói támogatják az objektumreplikációs szabályzatok teljes erőforrás-azonosító elérési útjának használatát.

Az alábbi táblázat bemutatja, hogyan különbözik a replikációs házirend viselkedése, ha teljes erőforrás-azonosítót használ egy fióknév helyett. Az összehasonlítás attól függ, hogy engedélyezve van-e a bérlők közötti másolatküldés a tárfiók számára.

Storage fiókazonosító a szabályzatdefinícióban Bérlők közötti replikáció engedélyezett Bérlők közötti replikáció nem engedélyezett
Teljes erőforrás-azonosító Azonos bérlőhöz tartozó szabályzatok hozhatók létre.

Bérlők közötti szabályzatok hozhatók létre.
Azonos bérlőhöz tartozó szabályzatok hozhatók létre.

Bérlők közötti szabályzatok nem hozhatók létre.
Csak fióknév Azonos bérlőhöz tartozó szabályzatok hozhatók létre.

Bérlők közötti szabályzatok hozhatók létre.
Sem azonos bérlői, sem bérlőközi szabályzatok nem hozhatók létre. Hiba történik, mert Azure Storage nem tudja ellenőrizni, hogy a forrás- és a célfiókok ugyanabban a bérlőben vannak-e. A hiba azt jelzi, hogy meg kell adnia a sourceAccount és a destinationAccount bejegyzéseinek teljes erőforrás-azonosítóját a szabályzatdefiníciós fájlban.

A szabályzat és a szabályazonosítók megadása

Az alábbi táblázat összefoglalja, hogy mely értékek használhatók a szabályzatdefiníciós fájl policyId és ruleId bejegyzéseihez az egyes forgatókönyvekben.

Amikor létrehoz egy szabályzatdefiníciós fájlt ehhez a fiókhoz... Állítsa be a szabályzati azonosítót erre az értékre Szabályazonosítók beállítása erre az értékre
Célszámla A sztring alapértelmezett értéke. Azure Storage hozza létre a szabályzatazonosító értékét. Üres sztring. Azure Storage hozza létre a szabályazonosítók értékeit.
Forrásfiók A célfiók szabályzatdefiníciós fájljának letöltésekor visszaadott házirend-azonosító értéke. A célfiók szabályzatdefiníciós fájljának letöltésekor visszaadott szabályazonosítók értékei.

Replikáció megakadályozása Microsoft Entra bérlők között

A Microsoft Entra bérlő a Microsoft Entra ID dedikált példánya, amely egy szervezet identitás- és hozzáférés-kezelési szolgáltatását jelöli. Minden Azure-előfizetés egyetlen Microsoft Entra bérlővel rendelkezik megbízhatósági kapcsolatban. Az előfizetés összes erőforrása, beleértve a tárfiókokat is, ugyanahhoz a Microsoft Entra bérlőhöz van társítva. További információ: Mi az a Microsoft Entra ID?

Alapértelmezés szerint a bérlők közötti replikáció le van tiltva a 2023. december 15-től létrehozott új fiókok esetében. Ha a biztonsági házirendek megkövetelik, hogy az objektumreplikációt olyan tároló fiókokra korlátozza, amelyek csak ugyanabban a bérlőben találhatóak, letilthatja a bérlők közötti replikációt egy biztonsági tulajdonság, az AllowCrossTenantReplication (előzetes verzió) tulajdonság beállításával. Ha letiltja a bérlőközi objektumreplikálást egy tárfiók esetében, Azure Storage további követelményt ír elő. Minden olyan objektumreplikációs házirend esetében, amely ezt a tárfiókot használja forrásként vagy célként, mindkét fióknak ugyanahhoz a Microsoft Entra bérlőhöz kell tartoznia. További információért a bérlőközi objektumreplikáció letiltásáról, lásd: Objektumreplikáció megelőzése Microsoft Entra bérlők között.

Ha le szeretné tiltani egy storage fiók bérlőközi objektumreplikációját, állítsa a AllowCrossTenantReplication tulajdonságot false értékre. Ha a tárolófiók jelenleg nem vesz részt bérlőközi objektumreplikációs szabályzatokban, akkor ha a AllowCrossTenantReplication tulajdonságot false-re állítja, az megakadályozza, hogy a jövőben bérlők közötti objektumreplikációs szabályzatokat ezzel a tárolófiókkal forrásként vagy célként lehessen konfigurálni.

Ha a storage-fiók jelenleg egy vagy több bérlőközi objektumreplikációs házirendben vesz részt, akkor a AllowCrossTenantReplication tulajdonság beállítása false nem engedélyezett. A bérlők közötti replikáció letiltásához törölnie kell a meglévő bérlőközi házirendeket.

Alapértelmezés szerint a AllowCrossTenantReplication tulajdonság hamis értékre van állítva a 2023. december 15-től létrehozott storage-fiók esetében. A 2023. december 15. előtt létrehozott storage-fiókok esetében, amikor a storage-fiók AllowCrossTenantReplication tulajdonságának értéke null vagy true, a jogosult felhasználók konfigurálhatják a keresztenantségi objektumreplikációs szabályzatokat ezzel a fiókkal forrásként vagy célként. További információ arról, hogyan lehet konfigurálni a bérlők közötti szabályzatokat az alábbi helyen található: Objektumreplikálás konfigurálása blokkblobokhoz.

Az Azure Policy segítségével ellenőrizhet egy tárfiók-csoportot annak biztosítására, hogy a AllowCrossTenantReplication tulajdonság be legyen állítva a bérlőközi objektumok replikációjának megakadályozására. A Azure Policy is használhatja a tárfiókok egy csoportjának szabályozásának kikényszerítéséhez. Létrehozhat például egy szabályzatot a deny effektussal, hogy megakadályozza, hogy a felhasználó olyan storage fiókot hozzon létre, amelyben a AllowCrossTenantReplication tulajdonság értéke true, vagy egy meglévő storage-fiók módosításával módosítsa a tulajdonság értékét true értékre.

Replikációs metrikák

Az objektumreplikálás két metrikát támogat a replikáció előrehaladásának elemzéséhez:

  • Replikációra váró műveletek: A forrásból a célba történő replikációra váró műveletek teljes száma, időkeretenként kibocsátva a tárfiókból.
  • Bájtok függőben a replikációhoz: A forrástól a cél tárfiókokig való replikációra váró bájtok összege, a tárolási időintervallumok szerint kibocsátott példányok alapján.

A korábban felsorolt metrikák mindegyike megtekinthető az időgyűjtők dimenziójával. Ez a lebontás lehetővé teszi, hogy az időgyűjtőnkénti replikációhoz hány bájt vagy művelet van függőben az alábbiak szerint:

  • 0-5 perc
  • 5-10 perc
  • 10-15 perc
  • 15-30 perc
  • 30 perc-2 óra
  • 2-8 óra
  • 8-24 óra
  • >24 óra

Az alábbi példakép az előző hét nap függőben lévő műveletét és bájtmetrikáit mutatja be:

Az objektumreplikációs metrikák a függőben lévő műveleteket és a függőben lévő bájtokat jelenítik meg hétnapos időtartamon keresztül

Engedélyezheti a replikációs metrikákat a forrásfiókon a függőben lévő bájtok és függőben lévő műveletek figyeléséhez. További információ: Replikációs metrikák konfigurálása.

A replikálás állapota

A forrásfiókban ellenőrizheti egy blob replikációs állapotát. További információ: Blob replikációs állapotának ellenőrzése.

Megjegyzés

Amíg a replikáció folyamatban van, nem lehet meghatározni a százalékos vagy replikált adatokat.

Ha a forrásfiókban lévő blob replikációs állapota hibát jelez, vizsgálja meg a következő lehetséges okokat:

  • Győződjön meg arról, hogy az objektumreplikációs szabályzat konfigurálva van a célfiókban.
  • Ellenőrizze, hogy a célfiók még létezik-e.
  • Ellenőrizze, hogy a céltároló még létezik-e.
  • Ellenőrizze, hogy a céltároló nincs-e törölve, és nincs-e folyamatban a törlés. A tároló törlése akár 30 másodpercet is igénybe vehet.
  • Ellenőrizze, hogy a céltároló továbbra is részt vesz-e az objektumreplikációs szabályzatban.
  • Ha a forrásblob egy írási művelet részeként ügyfél által megadott kulccsal van titkosítva, az objektumreplikálás meghiúsul. További információ az ügyfél által megadott kulcsokról: Titkosítási kulcs megadása Blob Storage tárhelyen.
  • Ellenőrizze, hogy a forrás- vagy célblob át van-e helyezve az archív szintre. Az archivált blobok nem replikálhatók objektumreplikálás útján. Az archív szinttel kapcsolatos további információkért lásd a blobadatok hozzáférési szintjeit.
  • Ellenőrizze, hogy a céltároló vagy blob nem módosíthatósági szabályzattal van-e védve. Ne feledje, hogy egy tároló vagy blob örökölhet egy nem módosítható házirendet a szülőtől. A változtathatatlansági házirendekről további információt a blobadatok változtathatatlan tárhelyéről szóló áttekintés témakörben talál.

Funkciók támogatása

Ennek a funkciónak a támogatását befolyásolhatja a Data Lake Storage Gen2, a Hálózati fájlrendszer (NFS) 3.0 protokoll vagy az SSH Fájlátviteli Protokoll (SFTP) engedélyezése. Ha engedélyezte ezen képességek bármelyikét, tekintse meg Blob Storage funkciótámogatást Azure Storage fiókokban a funkció támogatásának felméréséhez.

Számlázás

Az objektumreplikálás konfigurálása nem jár költséggel, beleértve a változáscsatorna engedélyezésének, a verziószámozás engedélyezésének és a replikációs szabályzatok hozzáadásának feladatát. Az objektumreplikálás azonban költségekkel jár a forrás- és célfiókok olvasási és írási tranzakcióihoz. A forrásfiókból a célfiókba történő adatreplikálás kimenő díjai szintén költségekkel járnak, ahogy az olvasási díjak is a változáscsatorna feldolgozása során.

Íme a költségek részletezése. Az egyes költségösszetevők árát a Azure Blob Storage Díjszabás című témakörben találja.

Blob frissítésének költsége a forrásfiókban A célfiókban lévő adatok replikálásának költsége
Írási művelet tranzakciós költsége A változáscsatorna-rekord olvasásának tranzakciós költsége
A blob és az egyes blobverziók tárolási költsége1 Tranzakciós költség a blob és a blob 2. verziójának olvasásához
Változáscsatornarekord hozzáadásának költsége A blob és a blob 2.verziójánakírásának tranzakciós költsége
Adatlekérések költségei a hűvös és hideg tárhelyszinteken A blob és az egyes blobverziók tárolási költsége1
Hálózati kimenő forgalom költsége: 3

1 A forrásfiókban, ha egy blob vagy verzió szintje változatlan, akkor a rendszer az adott blobban, annak verzióiban szereplő egyedi adatblokkokért számláz. Lásd a Blob verziószámozásának díjszabását és számlázását. A célfiókban egy verzió esetében a rendszer a verzió összes blokkjára kiszámláz, függetlenül attól, hogy ezek a blokkok egyediek-e.

2 Ez csak a legutóbbi replikáció befejezése óta létrehozott blobverziókat foglalja magában.

3 Az objektumreplikálás a teljes verziót a célhelyre másolja (nem csak a verzió egyedi blokkjainak). Ez az átvitel a hálózati kimenő forgalom költségét vonhatja maga után. Lásd: Bandwidth díjszabás.

Tipp.

A váratlan számla kockázatának csökkentése érdekében engedélyezze az objektumreplikálást egy olyan fiókban, amely csak néhány objektumot tartalmaz. Ezután mérje meg a költségekre gyakorolt hatást, mielőtt éles környezetben engedélyezené a funkciót.

Következő lépések