Omówienie modelu zakupów rdzeni wirtualnych — Azure SQL Database i Azure SQL Managed Instance

DOTYCZY: Azure SQL Managed Instance Azure SQL Database

Ten artykuł zawiera krótkie omówienie modelu zakupów rdzeni wirtualnych używanego zarówno przez Azure SQL Database, jak i Azure SQL Managed Instance. Aby dowiedzieć się więcej na temat modelu rdzeni wirtualnych dla każdego produktu, przejrzyj Azure SQL Database i Azure SQL Managed Instance.

Omówienie

Rdzeń wirtualny (rdzeń wirtualny) reprezentuje procesor logiczny i oferuje opcję wyboru cech fizycznych sprzętu (na przykład liczby rdzeni, pamięci i rozmiaru magazynu). Model zakupów oparty na rdzeniach wirtualnych zapewnia elastyczność, kontrolę, przejrzystość użycia poszczególnych zasobów oraz prosty sposób tłumaczenia wymagań dotyczących obciążeń lokalnych na chmurę. Ten model optymalizuje cenę i umożliwia wybór zasobów obliczeniowych, pamięci i magazynu na podstawie potrzeb związanych z obciążeniem.

W modelu zakupów opartym na rdzeniach wirtualnych koszty zależą od wyboru i użycia:

  • Warstwa usług
  • Konfiguracja sprzętu
  • Zasoby obliczeniowe (liczba rdzeni wirtualnych i ilość pamięci)
  • Magazyn zarezerwowanej bazy danych
  • Rzeczywisty magazyn kopii zapasowych

Ważne

W Azure SQL Database opłaty są naliczane za zasoby obliczeniowe (procesor CPU i pamięć), operacje we/wy, a dane i magazyn dzienników są naliczane za bazę danych lub pulę elastyczną. Opłata za magazyn kopii zapasowych jest naliczana za każdą bazę danych.

Model zakupów oparty na rdzeniach wirtualnych zapewnia przejrzystość alokacji zasobów bazy danych, pamięci i magazynu, konfiguracji sprzętu, wyższego stopnia szczegółowości skalowania oraz rabatów cenowych dzięki Korzyść użycia hybrydowego platformy Azure (AHB) i wystąpieniu zarezerwowanego (RI).

W przypadku Azure SQL Database model zakupów rdzeni wirtualnych zapewnia wyższe limity mocy obliczeniowej, pamięci, operacji we/wy i magazynu niż model jednostki DTU.

Warstwy usług

Dwie warstwy usługi rdzeni wirtualnych są dostępne w obu Azure SQL Database i Azure SQL Managed Instance:

  • Ogólnego przeznaczenia to przyjazna dla budżetu warstwa przeznaczona dla większości obciążeń z typowymi wymaganiami dotyczącymi wydajności i dostępności.
  • Warstwa Krytyczne dla działania firmy jest przeznaczona dla obciążeń wrażliwych na wydajność z rygorystycznymi wymaganiami dotyczącymi dostępności.

Warstwa usługi Hiperskala jest również dostępna dla pojedynczych baz danych w Azure SQL Database. Ta warstwa usługi jest przeznaczona dla większości obciążeń biznesowych, zapewniając wysoce skalowalny magazyn, skalowanie odczytu w poziomie, szybkie skalowanie i szybkie przywracanie bazy danych.

Limity zasobów

Aby uzyskać więcej informacji na temat limitów zasobów, zobacz:

Koszt obliczeń

Model zakupów oparty na rdzeniach wirtualnych ma aprowizowaną warstwę obliczeniową dla Azure SQL Database i Azure SQL Managed Instance oraz bezserwerową warstwę obliczeniową dla Azure SQL Database.

W aprowizowanej warstwie obliczeniowej koszt obliczeniowy odzwierciedla łączną pojemność obliczeniową w sposób ciągły aprowizowany dla aplikacji niezależnie od działania obciążenia. Wybierz alokację zasobów, która najlepiej odpowiada potrzebom biznesowym na podstawie wymagań dotyczących rdzeni wirtualnych i pamięci, a następnie skaluj zasoby w górę i w dół zgodnie z potrzebami obciążenia.

W bezserwerowej warstwie obliczeniowej dla Azure SQL bazy danych zasoby obliczeniowe są skalowane automatycznie w oparciu o pojemność obciążenia i rozliczane za ilość używanych zasobów obliczeniowych na sekundę.

Ponieważ trzy dodatkowe repliki są automatycznie przydzielane w warstwie usługi Krytyczne dla działania firmy, cena jest w przybliżeniu 2,7 razy wyższa niż w warstwie usługi Ogólnego przeznaczenia. Podobnie wyższa cena magazynu za GB w warstwie usługi Krytyczne dla działania firmy odzwierciedla wyższe limity operacji we/wy i mniejsze opóźnienie lokalnego magazynu SSD.

Magazyn danych i dzienników

Następujące czynniki wpływają na ilość miejsca używanego do przechowywania danych i plików dziennika oraz mają zastosowanie do warstw Ogólnego przeznaczenia i Krytyczne dla działania firmy.

  • Każdy rozmiar obliczeniowy obsługuje konfigurowalny maksymalny rozmiar danych z domyślnym rozmiarem 32 GB.
  • Podczas konfigurowania maksymalnego rozmiaru danych dodatkowe 30% rozliczanego magazynu jest automatycznie dodawane dla pliku dziennika.
  • W warstwie usługi tempdb Ogólnego przeznaczenia używa lokalnego magazynu SSD, a ten koszt magazynu jest uwzględniany w cenie rdzeni wirtualnych.
  • W warstwie usługi tempdb Krytyczne dla działania firmy udziały lokalnego magazynu SSD z plikami danych i dziennika, a tempdb koszt magazynowania jest uwzględniany w cenie rdzeni wirtualnych.
  • W warstwach Ogólnego przeznaczenia i Krytyczne dla działania firmy są naliczane opłaty za maksymalny rozmiar magazynu skonfigurowany dla bazy danych, elastycznej puli lub wystąpienia zarządzanego.
  • W przypadku SQL Database można wybrać dowolny maksymalny rozmiar danych z zakresu od 1 GB do obsługiwanego maksymalnego rozmiaru magazynu, w przyrostach 1 GB. W przypadku SQL Managed Instance wybierz rozmiary danych w wielokrotnościach 32 GB do maksymalnego obsługiwanego rozmiaru magazynu.

Aby monitorować bieżący przydzielony i używany rozmiar magazynu danych w SQL Database, użyj odpowiednio metryk usługi Azure Monitor allocated_data_storage i magazynu.

W przypadku SQL Database i SQL wystąpienia zarządzanego do monitorowania bieżącego przydzielonego i używanego rozmiaru magazynu poszczególnych plików danych i dzienników w bazie danych przy użyciu SQL T użyj widoku sys.database_files i funkcji FILEPROPERTY(... , 'SpaceUsed').

Porada

W pewnych okolicznościach może być konieczne zmniejszenie bazy danych w celu odzyskania nieużywanego miejsca. Aby uzyskać więcej informacji, zobacz Zarządzanie miejscem na pliki w Azure SQL Database.

Magazyn kopii zapasowych

Storage kopii zapasowych bazy danych jest przydzielana do obsługi funkcji przywracania do punktu w czasie (PITR) i długoterminowego przechowywania (LTR) SQL Database i SQL Managed Instance. Ten magazyn jest oddzielony od magazynu danych i plików dziennika i jest rozliczany oddzielnie.

  • Przywracanie do punktu w czasie: w warstwach Ogólnego przeznaczenia i Krytyczne dla działania firmy poszczególne kopie zapasowe bazy danych są automatycznie kopiowane do usługi Azure Storage. Rozmiar magazynu zwiększa się dynamicznie w miarę tworzenia nowych kopii zapasowych. Magazyn jest używany przez pełne, różnicowe i transakcyjne kopie zapasowe dziennika. Użycie magazynu zależy od częstotliwości zmiany bazy danych i okresu przechowywania skonfigurowanego dla kopii zapasowych. Można skonfigurować oddzielny okres przechowywania dla każdej bazy danych z zakresu od 1 do 35 dni dla SQL Database i od 0 do 35 dni dla SQL Managed Instance. Ilość magazynu kopii zapasowych równa skonfigurowanemu maksymalnemu rozmiarowi danych nie jest naliczana za dodatkową opłatą.
  • LTR: Istnieje również możliwość skonfigurowania długoterminowego przechowywania pełnych kopii zapasowych przez maksymalnie 10 lat. Jeśli skonfigurujesz zasady LTR, te kopie zapasowe są przechowywane automatycznie w usłudze Azure Blob Storage, ale możesz kontrolować częstotliwość kopiowania kopii zapasowych. Aby spełnić różne wymagania dotyczące zgodności, możesz wybrać różne okresy przechowywania dla kopii zapasowych co tydzień, co miesiąc i/lub rok. Wybrana konfiguracja określa ilość miejsca do magazynowania w przypadku kopii zapasowych LTR. Aby uzyskać więcej informacji, zobacz Długoterminowe przechowywanie kopii zapasowych.

Następne kroki

Aby rozpocząć pracę, zobacz:

Aby uzyskać szczegółowe informacje na temat określonych rozmiarów zasobów obliczeniowych i magazynu dostępnych w warstwach usług Ogólnego przeznaczenia i Krytyczne dla działania firmy, zobacz: