Replikacja obiektów blokowych obiektów blob
Replikacja obiektów asynchronicznie kopiuje blokowe obiekty blob między źródłowym kontem magazynu a kontem docelowym. Niektóre scenariusze obsługiwane przez replikację obiektów obejmują:
- Minimalizacja opóźnienia. Replikacja obiektów może zmniejszyć opóźnienie dla żądań odczytu, umożliwiając klientom korzystanie z danych z regionu znajdującego się bliżej fizycznej odległości.
- Zwiększ wydajność obciążeń obliczeniowych. W przypadku replikacji obiektów obciążenia obliczeniowe mogą przetwarzać te same zestawy blokowych obiektów blob w różnych regionach.
- Optymalizacja dystrybucji danych. Możesz przetwarzać lub analizować dane w jednej lokalizacji, a następnie replikować tylko wyniki do dodatkowych regionów.
- Optymalizowanie kosztów. Po zreplikowanym danych można zmniejszyć koszty, przenosząc je do warstwy Archiwum przy użyciu zasad zarządzania cyklem życia.
Na poniższym diagramie przedstawiono sposób replikacji obiektów blob blokowych z konta magazynu źródłowego w jednym regionie do kont docelowych w dwóch różnych regionach.
Aby dowiedzieć się, jak skonfigurować replikację obiektów, zobacz Konfigurowanie replikacji obiektów.
Wymagania wstępne i zastrzeżenia dotyczące replikacji obiektów
Replikacja obiektów wymaga również włączenia następujących funkcji usługi Azure Storage:
- Źródło zmian: musi być włączone na koncie źródłowym. Aby dowiedzieć się, jak włączyć zestawienie zmian, zobacz Włączanie i wyłączanie zestawienia zmian.
- Przechowywanie wersji obiektów blob: należy włączyć zarówno na kontach źródłowych, jak i docelowych. Aby dowiedzieć się, jak włączyć przechowywanie wersji, zobacz Włączanie przechowywania wersji obiektów blob i zarządzanie nimi.
Włączenie zestawienia zmian i przechowywania wersji obiektów blob może wiązać się z dodatkowymi kosztami. Aby uzyskać więcej informacji, zobacz stronę cennika usługi Azure Storage.
Replikacja obiektów jest obsługiwana w przypadku kont magazynu ogólnego przeznaczenia w wersji 2 i kont blokowych obiektów blob w warstwie Premium. Zarówno konta źródłowe, jak i docelowe muszą być kontami obiektów blob ogólnego przeznaczenia w wersji 2 lub premium. Replikacja obiektów obsługuje tylko blokowe obiekty blob; Uzupełnialne obiekty blob i stronicowe obiekty blob nie są obsługiwane.
Replikacja obiektów jest obsługiwana w przypadku kont, które są szyfrowane przy użyciu kluczy zarządzanych przez firmę Microsoft lub kluczy zarządzanych przez klienta. Aby uzyskać więcej informacji na temat kluczy zarządzanych przez klienta, zobacz Klucze zarządzane przez klienta na potrzeby szyfrowania usługi Azure Storage.
Replikacja obiektów nie jest obsługiwana w przypadku obiektów blob na koncie źródłowym, które są szyfrowane przy użyciu klucza dostarczonego przez klienta. Aby uzyskać więcej informacji na temat kluczy dostarczonych przez klienta, zobacz Zapewnianie klucza szyfrowania w żądaniu do usługi Blob Storage.
Tryb failover zarządzany przez klienta nie jest obsługiwany dla źródłowego lub docelowego konta w zasadach replikacji obiektów.
Replikacja obiektów nie jest obsługiwana w przypadku obiektów blob przekazywanych przy użyciu interfejsów API usługi Data Lake Storage .
Jak działa replikacja obiektów
Replikacja obiektów asynchronicznie kopiuje blokowe obiekty blob w kontenerze zgodnie z skonfigurowanymi regułami. Zawartość obiektu blob, wszystkie wersje skojarzone z obiektem blob oraz metadane i właściwości obiektu blob są kopiowane z kontenera źródłowego do kontenera docelowego.
Ważne
Ponieważ dane blokowych obiektów blob są replikowane asynchronicznie, konto źródłowe i konto docelowe nie są natychmiast synchronizowane. Obecnie nie ma umowy SLA dotyczącej czasu replikacji danych na konto docelowe. Możesz sprawdzić stan replikacji w źródłowym obiekcie blob, aby określić, czy replikacja została ukończona. Aby uzyskać więcej informacji, zobacz Sprawdzanie stanu replikacji obiektu blob.
Przechowywanie wersji obiektów blob
Replikacja obiektów wymaga włączenia przechowywania wersji obiektów blob zarówno na kontach źródłowych, jak i docelowych. Po zmodyfikowaniu replikowanego obiektu blob na koncie źródłowym zostanie utworzona nowa wersja obiektu blob na koncie źródłowym, który odzwierciedla poprzedni stan obiektu blob przed modyfikacją. Bieżąca wersja na koncie źródłowym odzwierciedla najnowsze aktualizacje. Zarówno bieżąca wersja, jak i wszystkie poprzednie wersje są replikowane do konta docelowego. Aby uzyskać więcej informacji na temat wpływu operacji zapisu na wersje obiektów blob, zobacz Przechowywanie wersji w operacjach zapisu.
Jeśli konto magazynu ma obowiązujące zasady replikacji obiektów, nie można wyłączyć przechowywania wersji obiektów blob dla tego konta. Przed wyłączeniem przechowywania wersji obiektów blob należy usunąć wszystkie zasady replikacji obiektów na koncie.
Uwaga
Tylko obiekty blob są kopiowane do miejsca docelowego. Identyfikator wersji obiektu blob nie jest kopiowany. Obiekt blob umieszczony w lokalizacji docelowej ma przypisany nowy identyfikator wersji.
Usuwanie obiektu blob na koncie źródłowym
Gdy obiekt blob na koncie źródłowym zostanie usunięty, bieżąca wersja obiektu blob stanie się poprzednią wersją i nie ma już bieżącej wersji. Wszystkie istniejące poprzednie wersje obiektu blob są zachowywane. Ten stan jest replikowany do konta docelowego. Aby uzyskać więcej informacji na temat sposobu usuwania operacji wpływających na wersje obiektów blob, zobacz Przechowywanie wersji operacji usuwania.
Migawki
Replikacja obiektów nie obsługuje migawek obiektów blob. Wszystkie migawki obiektu blob na koncie źródłowym nie są replikowane do konta docelowego.
Tagi indeksu obiektów blob
Replikacja obiektów nie kopiuje tagów indeksu źródłowego obiektu blob do docelowego obiektu blob.
Warstwy obiektów blob
Replikacja obiektów jest obsługiwana, gdy konta źródłowe i docelowe znajdują się w warstwie Gorąca lub Chłodna. Konta źródłowe i docelowe mogą znajdować się w różnych warstwach. Jednak replikacja obiektów zakończy się niepowodzeniem, jeśli obiekt blob na koncie źródłowym lub docelowym został przeniesiony do warstwy Archiwum. Aby uzyskać więcej informacji na temat warstw obiektów blob, zobacz Warstwy dostępu dla danych obiektów blob.
Niezmienne obiekty blob
Zasady niezmienności dla usługi Azure Blob Storage obejmują zasady przechowywania na podstawie czasu i blokady prawne. Jeśli zasady niezmienności obowiązują na koncie docelowym, może to mieć wpływ na replikację obiektów. Aby uzyskać więcej informacji na temat zasad niezmienności, zobacz Przechowywanie danych obiektów blob krytycznych dla działania firmy z niezmiennym magazynem.
Jeśli dla kontenera na koncie docelowym obowiązują zasady niezmienności na poziomie kontenera, a obiekt w kontenerze źródłowym zostanie zaktualizowany lub usunięty, operacja w kontenerze źródłowym może zakończyć się powodzeniem, ale replikacja tej operacji do kontenera docelowego zakończy się niepowodzeniem. Aby uzyskać więcej informacji o tym, które operacje są zabronione za pomocą zasad niezmienności, które są ograniczone do kontenera, zobacz Scenariusze z zakresem na poziomie kontenera.
Jeśli zasady niezmienności na poziomie wersji obowiązują dla wersji obiektu blob na koncie docelowym, a operacja usuwania lub aktualizacji jest wykonywana na wersji obiektu blob w kontenerze źródłowym, operacja na obiekcie źródłowym może zakończyć się powodzeniem, ale replikacja tej operacji do obiektu docelowego zakończy się niepowodzeniem. Aby uzyskać więcej informacji o tym, które operacje są zabronione za pomocą zasad niezmienności, które są ograniczone do kontenera, zobacz Scenariusze z zakresem na poziomie wersji.
Zasady i reguły replikacji obiektów
Podczas konfigurowania replikacji obiektów należy utworzyć zasady replikacji, które określają źródłowe konto magazynu i konto docelowe. Zasady replikacji obejmują co najmniej jedną regułę określającą kontener źródłowy i docelowy kontener oraz wskazują, które blokowe obiekty blob w kontenerze źródłowym zostaną zreplikowane.
Po skonfigurowaniu replikacji obiektów usługa Azure Storage okresowo sprawdza źródło zmian dla konta źródłowego i asynchronicznie replikuje wszystkie operacje zapisu lub usuwania na koncie docelowym. Opóźnienie replikacji zależy od rozmiaru replikowanego bloku obiektu blob.
Zasady replikacji
Podczas konfigurowania replikacji obiektów należy utworzyć zasady replikacji na koncie docelowym za pośrednictwem dostawcy zasobów usługi Azure Storage. Po utworzeniu zasad replikacji usługa Azure Storage przypisuje mu identyfikator zasad. Następnie należy skojarzyć te zasady replikacji z kontem źródłowym przy użyciu identyfikatora zasad. Identyfikator zasad na kontach źródłowych i docelowych musi być taki sam, aby replikacja odbywała się.
Konto źródłowe może być replikowane do nie więcej niż dwóch kont docelowych, z jednymi zasadami dla każdego konta docelowego. Podobnie, konto może służyć jako konto docelowe dla nie więcej niż dwóch zasad replikacji.
Konta źródłowe i docelowe mogą znajdować się w tym samym regionie lub w różnych regionach. Mogą również znajdować się w tej samej subskrypcji lub w różnych subskrypcjach. Opcjonalnie konta źródłowe i docelowe mogą znajdować się w różnych dzierżawach firmy Microsoft Entra. Dla każdej pary kont źródłowego/docelowego można utworzyć tylko jedne zasady replikacji.
Reguły replikacji
Reguły replikacji określają, w jaki sposób usługa Azure Storage będzie replikować obiekty blob z kontenera źródłowego do kontenera docelowego. Dla każdej zasady replikacji można określić maksymalnie 1000 reguł replikacji. Każda reguła replikacji definiuje pojedynczy kontener źródłowy i docelowy, a każdy kontener źródłowy i docelowy może być używany tylko w jednej regule, co oznacza, że maksymalnie 1000 kontenerów źródłowych i 1000 kontenerów docelowych może uczestniczyć w jednej zasadzie replikacji.
Podczas tworzenia reguły replikacji domyślnie kopiowane są tylko nowe blokowe obiekty blob, które są następnie dodawane do kontenera źródłowego. Można określić, że zarówno nowe, jak i istniejące blokowe obiekty blob są kopiowane lub można zdefiniować niestandardowy zakres kopiowania, który kopiuje blokowe obiekty blob utworzone od określonego czasu do wewnątrz.
Można również określić jeden lub więcej filtrów w ramach reguły replikacji, aby filtrować blokowe obiekty blob według prefiksu. Gdy określisz prefiks, do kontenera docelowego będą kopiowane tylko obiekty blob pasujące do tego prefiksu w kontenerze źródłowym.
Kontenery źródłowe i docelowe muszą istnieć przed określeniem ich w regule. Po utworzeniu zasad replikacji operacje zapisu w kontenerze docelowym nie są dozwolone. Wszystkie próby zapisu w kontenerze docelowym kończą się niepowodzeniem z kodem błędu 409 (konflikt). Aby zapisać w kontenerze docelowym, dla którego skonfigurowano regułę replikacji, należy usunąć regułę skonfigurowaną dla tego kontenera lub usunąć zasady replikacji. Operacje odczytu i usuwania w kontenerze docelowym są dozwolone, gdy zasady replikacji są aktywne.
Możesz wywołać operację Ustaw warstwę obiektu blob w obiekcie blob w kontenerze docelowym, aby przenieść ją do warstwy Archiwum. Aby uzyskać więcej informacji na temat warstwy archiwum, zobacz Warstwy dostępu dla danych obiektów blob.
Uwaga
Zmiana warstwy dostępu obiektu blob na koncie źródłowym nie spowoduje zmiany warstwy dostępu tego obiektu blob na koncie docelowym.
Plik definicji zasad
Zasady replikacji obiektów są definiowane przez plik JSON. Plik definicji zasad można pobrać z istniejących zasad replikacji obiektów. Można również utworzyć zasady replikacji obiektów, przekazując plik definicji zasad.
Przykładowy plik definicji zasad
Poniższy przykład definiuje zasady replikacji na koncie docelowym z jedną regułą zgodną z prefiksem b i ustawia minimalny czas tworzenia obiektów blob, które mają być replikowane. Pamiętaj, aby zastąpić wartości w nawiasach kątowych własnymi wartościami:
{
"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>",
"rules": [
{
"ruleId": "",
"sourceContainer": "<source-container>",
"destinationContainer": "<destination-container>",
"filters": {
"prefixMatch": [
"b"
],
"minCreationTime": "2021-08-028T00:00:00Z"
}
}
]
}
}
Określanie pełnych identyfikatorów zasobów dla kont źródłowych i docelowych
Podczas tworzenia pliku definicji zasad określ pełne identyfikatory zasobów usługi Azure Resource Manager dla wpisów sourceAccount i destinationAccount , jak pokazano w przykładzie w poprzedniej sekcji. Aby dowiedzieć się, jak zlokalizować identyfikator zasobu dla konta magazynu, zobacz Pobieranie identyfikatora zasobu dla konta magazynu.
Pełny identyfikator zasobu ma następujący format:
/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>
Plik definicji zasad wcześniej wymagał tylko nazwy konta zamiast pełnego identyfikatora zasobu dla konta magazynu. Wraz z wprowadzeniem właściwości zabezpieczeń AllowCrossTenantReplication w wersji 2021-02-02-01 interfejsu API REST dostawcy zasobów usługi Azure Storage należy teraz podać pełny identyfikator zasobu dla wszystkich zasad replikacji obiektów tworzonych podczas replikacji między dzierżawami jest niedozwolone dla konta magazynu, które uczestniczy w zasadach replikacji. Usługa Azure Storage używa pełnego identyfikatora zasobu, aby sprawdzić, czy konta źródłowe i docelowe znajdują się w tej samej dzierżawie. Aby dowiedzieć się więcej na temat wykluczania zasad replikacji między dzierżawami, zobacz Zapobieganie replikacji między dzierżawami firmy Microsoft.
Mimo że tylko nazwa konta jest nadal obsługiwana, gdy replikacja między dzierżawami jest dozwolona dla konta magazynu, firma Microsoft zaleca zawsze podanie pełnego identyfikatora zasobu jako najlepsze rozwiązanie. Wszystkie poprzednie wersje interfejsu API REST dostawcy zasobów usługi Azure Storage obsługują pełną ścieżkę identyfikatora zasobu w zasadach replikacji obiektów.
W poniższej tabeli opisano, co się stanie po utworzeniu zasad replikacji z określonym pełnym identyfikatorem zasobu w porównaniu z nazwą konta, w scenariuszach, w których replikacja między dzierżawami jest dozwolona lub niedozwolona dla konta magazynu.
| Identyfikator konta magazynu w definicji zasad | Dozwolona replikacja między dzierżawami | Replikacja między dzierżawami jest niedozwolona |
|---|---|---|
| Pełny identyfikator zasobu | Można utworzyć zasady tej samej dzierżawy. Można utworzyć zasady między dzierżawami. |
Można utworzyć zasady tej samej dzierżawy. Nie można utworzyć zasad między dzierżawami. |
| Tylko nazwa konta | Można utworzyć zasady tej samej dzierżawy. Można utworzyć zasady między dzierżawami. |
Nie można utworzyć zasad tej samej dzierżawy ani między dzierżawami. Występuje błąd, ponieważ usługa Azure Storage nie może sprawdzić, czy konta źródłowe i docelowe znajdują się w tej samej dzierżawie. Błąd wskazuje, że musisz określić pełny identyfikator zasobu dla wpisów sourceAccount i destinationAccount w pliku definicji zasad. |
Określanie identyfikatorów zasad i reguł
W poniższej tabeli podsumowano wartości, które mają być używane dla wpisów policyId i ruleId w pliku definicji zasad w każdym scenariuszu.
| Podczas tworzenia pliku definicji zasad dla tego konta... | Ustaw identyfikator zasad na tę wartość | Ustaw identyfikatory reguł na tę wartość |
|---|---|---|
| Konto docelowe | Wartość ciągu jest domyślna. Usługa Azure Storage utworzy wartość identyfikatora zasad. | Pusty ciąg. Usługa Azure Storage utworzy wartości identyfikatora reguły. |
| Konto źródłowe | Wartość identyfikatora zasad zwrócona podczas pobierania pliku definicji zasad dla konta docelowego. | Wartości identyfikatorów reguł zwracanych podczas pobierania pliku definicji zasad dla konta docelowego. |
Zapobieganie replikacji między dzierżawami firmy Microsoft Entra
Dzierżawa firmy Microsoft Entra to dedykowane wystąpienie identyfikatora Entra firmy Microsoft, które reprezentuje organizację do zarządzania tożsamościami i dostępem. Każda subskrypcja platformy Azure ma relację zaufania z jedną dzierżawą firmy Microsoft Entra. Wszystkie zasoby w subskrypcji, w tym konta magazynu, są skojarzone z tą samą dzierżawą firmy Microsoft Entra. Aby uzyskać więcej informacji, zobacz Co to jest identyfikator Entra firmy Microsoft?
Domyślnie replikacja między dzierżawami jest wyłączona dla nowych kont utworzonych od 15 grudnia 2023 r. Jeśli zasady zabezpieczeń wymagają ograniczenia replikacji obiektów do kont magazynu, które znajdują się tylko w tej samej dzierżawie, można uniemożliwić replikację między dzierżawami, ustawiając właściwość zabezpieczeń, właściwość AllowCrossTenantReplication (wersja zapoznawcza). Jeśli nie zezwalasz na replikację obiektów między dzierżawami dla konta magazynu, a następnie dla wszystkich zasad replikacji obiektów skonfigurowanych przy użyciu tego konta magazynu jako konta źródłowego lub docelowego usługa Azure Storage wymaga, aby zarówno konta źródłowe, jak i docelowe znajdowały się w tej samej dzierżawie usługi Microsoft Entra. Aby uzyskać więcej informacji na temat wykluczania replikacji obiektów między dzierżawami, zobacz Zapobieganie replikacji obiektów w dzierżawach firmy Microsoft Entra.
Aby uniemożliwić replikację obiektów między dzierżawami dla konta magazynu, ustaw właściwość AllowCrossTenantReplication na false. Jeśli konto magazynu nie uczestniczy obecnie w żadnych zasadach replikacji obiektów między dzierżawami, ustawienie właściwości AllowCrossTenantReplication na wartość false uniemożliwia przyszłą konfigurację zasad replikacji obiektów między dzierżawami przy użyciu tego konta magazynu jako źródła lub miejsca docelowego.
Jeśli konto magazynu aktualnie uczestniczy w co najmniej jednej zasadach replikacji obiektów między dzierżawami, ustawienie właściwości AllowCrossTenantReplication na false nie jest dozwolone. Aby uniemożliwić replikację między dzierżawami, należy usunąć istniejące zasady między dzierżawami.
Domyślnie właściwość AllowCrossTenantReplication ma wartość false dla konta magazynu utworzonego od 15 grudnia 2023 r. W przypadku kont magazynu utworzonych przed 15 grudnia 2023 r., gdy wartość właściwości AllowCrossTenantReplication dla konta magazynu ma wartość null lub true, autoryzowani użytkownicy mogą skonfigurować zasady replikacji obiektów między dzierżawami przy użyciu tego konta jako źródła lub miejsca docelowego. Aby uzyskać więcej informacji na temat konfigurowania zasad między dzierżawami, zobacz Konfigurowanie replikacji obiektów dla blokowych obiektów blob.
Za pomocą usługi Azure Policy można przeprowadzić inspekcję zestawu kont magazynu, aby upewnić się, że właściwość AllowCrossTenantReplication jest ustawiona, aby zapobiec replikacji obiektów między dzierżawami. Za pomocą usługi Azure Policy można również wymusić ład dla zestawu kont magazynu. Na przykład można utworzyć zasady z efektem odmowy, aby uniemożliwić użytkownikowi utworzenie konta magazynu, na którym właściwość AllowCrossTenantReplication jest ustawiona na true, lub z modyfikowania istniejącego konta magazynu w celu zmiany wartości właściwości na true.
Stan replikacji
Stan replikacji obiektu blob można sprawdzić na koncie źródłowym. Aby uzyskać więcej informacji, zobacz Sprawdzanie stanu replikacji obiektu blob.
Uwaga
Podczas gdy replikacja jest w toku, nie ma możliwości określenia procentu danych, które zostały zreplikowane.
Jeśli stan replikacji obiektu blob na koncie źródłowym wskazuje błąd, zbadaj następujące możliwe przyczyny:
- Upewnij się, że zasady replikacji obiektów są skonfigurowane na koncie docelowym.
- Sprawdź, czy konto docelowe nadal istnieje.
- Sprawdź, czy kontener docelowy nadal istnieje.
- Sprawdź, czy kontener docelowy nie jest w trakcie usuwania lub nie został usunięty. Usunięcie kontenera może potrwać do 30 sekund.
- Sprawdź, czy kontener docelowy nadal uczestniczy w zasadach replikacji obiektów.
- Jeśli źródłowy obiekt blob został zaszyfrowany przy użyciu klucza dostarczonego przez klienta w ramach operacji zapisu, replikacja obiektu zakończy się niepowodzeniem. Aby uzyskać więcej informacji na temat kluczy dostarczonych przez klienta, zobacz Zapewnianie klucza szyfrowania w żądaniu do usługi Blob Storage.
- Sprawdź, czy źródłowy lub docelowy obiekt blob został przeniesiony do warstwy Archiwum. Zarchiwizowanych obiektów blob nie można replikować za pośrednictwem replikacji obiektów. Aby uzyskać więcej informacji na temat warstwy archiwum, zobacz Warstwy dostępu dla danych obiektów blob.
- Sprawdź, czy docelowy kontener lub obiekt blob nie jest chroniony przez zasady niezmienności. Należy pamiętać, że kontener lub obiekt blob może dziedziczyć zasady niezmienności po jego obiekcie nadrzędnym. Aby uzyskać więcej informacji na temat zasad niezmienności, zobacz Omówienie niezmiennego magazynu dla danych obiektów blob.
Obsługa funkcji
Może to mieć wpływ na obsługę tej funkcji przez włączenie protokołu Data Lake Storage Gen2, sieciowego systemu plików (NFS) 3.0 lub protokołu SSH File Transfer Protocol (SFTP). Jeśli włączono dowolną z tych funkcji, zobacz Obsługa funkcji usługi Blob Storage na kontach usługi Azure Storage, aby ocenić obsługę tej funkcji.
Rozliczenia
Nie ma kosztów konfigurowania replikacji obiektów. Obejmuje to zadanie włączania zestawienia zmian, włączania przechowywania wersji, a także dodawania zasad replikacji. Jednak replikacja obiektów wiąże się z kosztami transakcji odczytu i zapisu na kontach źródłowych i docelowych, a także opłatami za ruch wychodzący za replikację danych z konta źródłowego do konta docelowego i opłaty za odczyt w celu przetworzenia zestawienia zmian.
Oto podział kosztów. Aby znaleźć cenę każdego składnika kosztów, zobacz Cennik usługi Azure Blob Storage.
| Koszt aktualizacji obiektu blob na koncie źródłowym | Koszt replikacji danych na koncie docelowym |
|---|---|
| Koszt transakcji operacji zapisu | Koszt transakcji odczytu rekordu zestawienia zmian |
| Koszt magazynowania obiektu blob i każdego obiektu blob w wersji1 | Koszt transakcji odczytu obiektu blob i obiektu blob w wersji2 |
| Koszt dodawania rekordu zestawienia zmian | Koszt transakcji zapisu obiektu blob i obiektu blob w wersji2 |
| Koszt magazynowania obiektu blob i każdego obiektu blob w wersji1 | |
| Koszt ruchu wychodzącegosieci 3 |
1 Jeśli na koncie źródłowym nie zmieniono warstwy obiektu blob lub wersji, opłaty są naliczane za unikatowe bloki danych w tym obiekcie blob, jego wersjach. Zobacz Cennik wersji obiektów blob i rozliczenia. Na koncie docelowym w przypadku wersji są naliczane opłaty za wszystkie bloki wersji, niezależnie od tego, czy te bloki są unikatowe.
2 Dotyczy to tylko wersji obiektów blob utworzonych od czasu ukończenia ostatniej replikacji.
3 Replikacja obiektu kopiuje całą wersję do miejsca docelowego (nie tylko unikatowe bloki wersji). Ten transfer wiąże się z kosztem ruchu wychodzącego sieci. Zobacz Cennik przepustowości.
Napiwek
Aby zmniejszyć ryzyko nieoczekiwanego rachunku, włącz replikację obiektów na koncie, które zawiera tylko niewielką liczbę obiektów. Następnie zmierz wpływ na koszt przed włączeniem funkcji w ustawieniu produkcyjnym.