Model kosztów usługi Azure NetApp Files

Zrozumienie modelu kosztów dla usługi Azure NetApp Files ułatwia zarządzanie wydatkami z usługi.

Aby zapoznać się z modelem kosztów specyficznym dla replikacji między regionami, zobacz Model kosztów na potrzeby replikacji między regionami.

Obliczanie zużycia pojemności

Opłaty za aprowizowaną pojemność magazynu są naliczane za usługę Azure NetApp Files, która jest przydzielana przez tworzenie pul pojemności. Pule pojemności są rozliczane co miesiąc na podstawie ustalonego kosztu przydzielonego GiB na godzinę. Alokacja puli pojemności jest mierzona co godzinę.

Pule pojemności muszą być co najmniej 2 TiB i można je zwiększyć lub zmniejszyć w odstępach 1-TiB. Pule pojemności zawierają woluminy o rozmiarze od co najmniej 100 GiB do maksymalnie 100 TiB. Przydziały woluminów są przypisywane, które są odejmowane z aprowizowanego rozmiaru puli pojemności. W przypadku aktywnego woluminu użycie pojemności względem limitu przydziału jest oparte na pojemności logicznej (efektywnej), będąc aktywnymi danymi systemu plików lub danymi migawek. Aby uzyskać szczegółowe informacje, zobacz Jak działają migawki usługi Azure NetApp Files.

Przykłady cen

W tej sekcji przedstawiono przykłady ułatwiające zrozumienie modelu kosztów usługi Azure NetApp Files.

Przykład 1: Koszt miesięczny ze statyczną a dynamiczną aprowizowaniem puli pojemności

Jeśli wymagania dotyczące rozmiaru puli pojemności wahają się (na przykład ze względu na zmienną pojemność lub zapotrzebowanie na wydajność), rozważ dynamiczne zmienianie rozmiaru woluminów i pul pojemności w celu zrównoważenia kosztów z potrzebami dotyczącymi pojemności i wydajności.

Na przykład używasz pojemności Premium 24 godzin (1 dzień) w 10 TiB, 96 godzin (4 dni) w 24 TiB, cztery razy w 6 godzin (1 dzień) przy 5 TiB, 480 godzin (20 dni) w 6 TiB, a pozostałe godziny miesiąca o 0 TiB. Profil wdrożenia dynamicznego użycia chmury różni się od tradycyjnego statycznego profilu użycia lokalnego:

Bar chart that shows dynamic versus static capacity pool provisioning.

Gdy koszty są rozliczane na poziomie 0,000403 USD za giB/godzinę (ceny w zależności od regionu), miesięczny podział kosztów wygląda następująco:

Statyczna aprowizacja w warstwie Premium (szczytowa pojemność/wydajność)

  • 24 TiB x 720 godzin x $0.000403 za GiB/godzinę = $7,130,97 miesięcznie ($237.70 dziennie)

Dynamiczna aprowizacja przy użyciu rozmiaru woluminu i puli pojemności

  • 10 TiB x 24 godziny x $0.000403 za GiB/godzinę = $99.04
  • 24 TiB x 96 godzin x $0.000403 za GiB/godzinę = $950.80
  • 6 TiB x 480 godzin x $0.000403 za GiB/godzinę = $1,188,50
  • Suma = 2238,33 USD

Bar chart that shows static versus dynamic service level cost model.

Ten scenariusz stanowi miesięczne oszczędności w wysokości 4892,64 USD w porównaniu ze statyczną aprowizowaniem.

Przykład 2. Miesięczny koszt z dynamiczną zmianą poziomu usług i bez nich

Jeśli wymagania dotyczące rozmiaru puli pojemności pozostają takie same, ale wymagania dotyczące wydajności wahają się, rozważ dynamiczne zmienianie poziomu usługi woluminu. Pule pojemności różnych typów można aprowizować i co jakiś czas, zapewniając wydajność just in time i obniżać koszty w okresach, w których wydajność nie jest potrzebna.

Rozważmy scenariusz, w którym wymaganie dotyczące pojemności jest stałą 24 TiB. Jednak wymagania dotyczące wydajności wahają się między 384 godzinami (16 dni) poziomu usługi w warstwie Standardowa, 120 godzin (5 dni) poziomu usługi Premium, 168 godzin (7 dni) poziomu usługi Ultra, a następnie z powrotem do 48 godzin (2 dni) standardowej wydajności poziomu usług. W tym scenariuszu profil dynamicznego wdrożenia użycia chmury wygląda inaczej niż w przypadku tradycyjnego statycznego profilu użycia lokalnego:

Bar chart that shows provisioning with and without dynamic service level change.

W takim przypadku, gdy koszty są rozliczane na poziomie 0,000202 USD za GiB/godzinę (Standardowa), 0,000403 USD za GiB/godzinę (Premium) i 0,000538 USD za GiB/godzinę (ultra) (ceny w zależności od regionu), miesięczny podział kosztów wygląda następująco:

Statyczna aprowizacja na poziomie usługi Ultra (szczytowa wydajność)

  • 24 TiB x 720 godzin x 0,000538 USD za GiB/godzinę = 9519,76 USD miesięcznie (317,33 USD dziennie)

Dynamiczna aprowizacja przy użyciu dynamicznej zmiany poziomu usługi

  • 24 TiB x 384 godziny x $0.000202 za GiB/godzinę = $1,901.31
  • 24 TiB x 120 godzin x $0.000403 za GiB/godzinę = $1,188,50
  • 24 TiB x 168 godzin x $0.000538 za GiB/godzinę = $2,221,28
  • 24 TiB x 48 godzin x $0.000202 za GiB/godzinę = $238.29
  • Suma = 5554,37 USD

Bar chart that shows static versus dynamic service level change cost model.

Ten scenariusz stanowi miesięczne oszczędności w wysokości 3965,39 USD w porównaniu ze statyczną aprowizowaniem.

Zużycie pojemności migawek

Użycie pojemności migawek w usłudze Azure NetApp Files jest naliczane względem limitu przydziału woluminu nadrzędnego. W związku z tym współudzieli taką samą stawkę rozliczeniową jak pula pojemności, do której należy wolumin. Jednak w przeciwieństwie do aktywnego woluminu użycie migawki jest mierzone na podstawie pojemności przyrostowej zużywanej. Migawki usługi Azure NetApp Files mają charakter różnicowy. W zależności od współczynnika zmian danych migawki często zużywają znacznie mniejszą pojemność niż pojemność logiczna aktywnego woluminu. Załóżmy na przykład, że masz migawkę woluminu 500 GiB, który zawiera tylko 10 GiB danych różnicowych.

Zużycie pojemności, które jest liczone do limitu przydziału woluminu dla aktywnego systemu plików i migawki wynosi 510 GiB, a nie 1000 GiB. Ogólnie rzecz biorąc, zalecane 20% pojemności można założyć, aby zachować tygodniową wartość danych migawki (w zależności od częstotliwości migawek i dziennego współczynnika zmian na poziomie bloku aplikacji).

Na poniższym diagramie przedstawiono koncepcje.

  • Załóżmy, że pula pojemności ma 10 TiB aprowizowanej pojemności. Pula zawiera trzy woluminy:
    • Wolumin 1 ma przydział 5 TiB i ma 3,5 TiB (3 TiB aktywne, 500 migawek GiB) zużycia.
    • Wolumin 2 jest przypisany limit przydziału 900 GiB i ma 400 GiB zużycia.
    • Wolumin 3 jest przypisany przydział 4 TiB, ale jest pełny, z 4 TiB (3,5 TiB aktywne, 500 GiB migawek) zużycia.
  • Pula pojemności jest mierzona (i rozliczana) za 10 TiB pojemności ( aprowizowana kwota):
    • 9.9 TiB pojemności jest przydzielona (5 TiB, 900 GiB i 4 TiB przydziału z woluminów 1, 2 i 3).
    • 7.9 TiB pojemności jest używany (3,5 TiB, 400 GiB, 4 TiB w woluminach 1, 2 i 3).
  • Pula pojemności ma 100 GiB pozostałej nieprowizowanej pojemności.

Diagram showing capacity pool with three volumes.

Następne kroki