Model pembelian vCore - Azure SQL Managed Instance

  • Artikel

Berlaku untuk:Azure SQL Managed Instance

Artikel ini meninjau model pembelian vCore untuk Azure SQL Managed Instance.

Gambaran Umum

Virtual core (vCore) mewakili CPU logis dan menawarkan opsi untuk memilih karakteristik fisik perangkat keras (misalnya, jumlah core, memori, dan ukuran penyimpanan). Model pembelian berbasis vCore memberi Anda fleksibilitas, kontrol, transparansi penggunaan sumber daya individu, dan cara mudah untuk menerjemahkan persyaratan beban kerja lokal ke cloud. Model ini mengoptimalkan harga, dan memungkinkan Anda memilih sumber daya komputasi, memori, dan penyimpanan berdasarkan kebutuhan beban kerja Anda.

Dalam model pembelian berbasis vCore, biaya Anda bergantung pada pilihan dan penggunaan:

  • Tingkat layanan
  • Konfigurasi perangkat keras
  • Sumber daya komputasi (jumlah vCores dan jumlah memori)
  • Penyimpanan database yang dicadangkan
  • Penyimpanan cadangan aktual

Model pembelian virtual core (vCore) yang digunakan oleh Azure SQL Managed Instance menyediakan keuntungan berikut:

  • Kontrol atas konfigurasi perangkat keras agar lebih sesuai dengan persyaratan komputasi dan memori beban kerja.
  • Diskon harga untuk Azure Hybrid Benefit (AHB) dan Reserved Instance (RI).
  • Transparansi yang lebih besar dalam detail perangkat keras yang mendukung komputasi, membantu memfasilitasi perencanaan migrasi dari penyebaran lokal.
  • Skala granularitas yang lebih tinggi dengan beberapa ukuran komputasi tersedia.

Compute

SQL Managed Instance menyediakan sejumlah sumber daya komputasi tertentu yang terus-menerus disediakan terlepas dari aktivitas beban kerja, dan penagihan jumlah komputasi yang disediakan dengan harga tetap per jam.

Karena tiga replika tambahan dialokasikan secara otomatis di tingkat layanan Business Critical, harganya akan menjadi sekitar 2,7 kali lebih tinggi dari yang menggunakan tingkat layanan General Purpose. Selain itu, harga penyimpanan per GB yang lebih tinggi di tingkat layanan Business Critical menunjukkan batas IO yang lebih tinggi dan latensi penyimpanan SSD lokal yang lebih rendah.

Misalnya di tingkat layanan Tujuan Umum, dimungkinkan untuk menghemat biaya komputasi dan lisensi dengan menghentikan instans Anda saat Anda tidak menggunakannya. Tinjau Hentikan dan mulai instans untuk mempelajari lebih lanjut.

Penyimpanan data dan log

Faktor-faktor berikut memengaruhi jumlah penyimpanan yang digunakan untuk data dan file log, dan berlaku untuk Tujuan Umum dan Kritis Bisnis.

  • Di tingkat layanan Tujuan Umum, tempdb menggunakan penyimpanan SSD lokal, dan biaya penyimpanan ini sudah termasuk dalam harga vCore.
  • Di tingkat layanan Kritis Bisnis, tempdb berbagi penyimpanan SSD lokal dengan data dan file log, dan biaya penyimpanan tempdb sudah termasuk dalam harga vCore.
  • Ukuran penyimpanan untuk SQL Managed Instance harus ditentukan dalam kelipatan 32 GB.

Penting

Di kedua tingkat layanan, Anda dikenakan biaya untuk ukuran penyimpanan maksimum yang dikonfigurasi untuk instans terkelola.

Untuk memantau total ukuran penyimpanan instans yang digunakan untuk SQL Managed Instance, gunakan metrikstorage_space_used_mb. Untuk memantau ukuran penyimpanan data individual dan file log yang dialokasikan dan digunakan saat ini dalam database menggunakan T-SQL, gunakan tampilan sys.database_files dan fungsi FILEPROPERTY(... , 'SpaceUsed').

Penyimpanan cadangan

Penyimpanan untuk cadangan database dialokasikan untuk mendukung kemampuan SQL Managed Instance. Penyimpanan ini terpisah dari penyimpanan data dan file log, dan ditagih secara terpisah.

  • Pemulihan point-in-time (PITR): Konsumsi penyimpanan tergantung pada tingkat perubahan database dan periode retensi yang dikonfigurasi untuk cadangan. Anda dapat mengonfigurasi periode retensi terpisah untuk setiap database antara 1 hingga 35 hari untuk SQL Managed Instance. Jumlah penyimpanan cadangan yang sama dengan ukuran data maksimum yang dikonfigurasi disediakan tanpa biaya tambahan.
  • Retensi jangka panjang (LTR): Anda memiliki opsi untuk mengonfigurasi retensi jangka panjang pencadangan penuh hingga 10 tahun. Konfigurasi yang Anda pilih menentukan berapa banyak penyimpanan yang akan digunakan untuk pencadangan LTR.

Tingkat layanan

Tingkat layanan umumnya mendefinisikan arsitektur penyimpanan, ruang dan batas I/O, dan opsi kelangsungan bisnis yang terkait dengan ketersediaan dan pemulihan bencana.

Azure SQL Managed Instance memiliki dua tingkat layanan:

  • Tujuan Umum. Anda dapat memilih untuk menggunakan tingkat layanan Tujuan Umum Next-gen yang ditingkatkan (pratinjau).
  • Bisnis Kritis.

Untuk perbandingan terperinci antara tingkat layanan, tinjau batas sumber daya, tetapi gunakan tabel berikut untuk gambaran umum singkat:

Golongan Tujuan Umum Tujuan Umum generasi berikutnya Kritis Bisnis
Terbaik untuk Sebagian besar beban kerja bisnis. Menawarkan opsi komputasi dan penyimpanan yang berorientasi anggaran, seimbang, dan dapat diskalakan. Beban kerja bisnis berorientasi anggaran yang membutuhkan kapasitas lebih besar, throughput yang ditingkatkan, dan fleksibilitas sumber daya. Menawarkan aplikasi bisnis ketahanan tertinggi terhadap kegagalan dengan menggunakan beberapa replika terisolasi, dan menyediakan performa I/O tertinggi.
Jumlah maksimum vCore 80 128 128
Ukuran penyimpanan instans maks 16 TB 32 TB 16 TB
Database maks per instans 100 500 100
Replika Baca-saja 0 0 1
Replika untuk ketersediaan Simpul siaga untuk ketersediaan tinggi Simpul siaga untuk ketersediaan tinggi Tiga replika ketersediaan tinggi, 1 juga merupakan replika skala baca
Harga/tagihan vCore, penyimpanan khusus, dan penyimpanan cadangan dikenai biaya.
IOPS tidak dikenai biaya		 vCore, penyimpanan yang dipesan, penyimpanan cadangan, dan IOPS (melalui kuota gratis) dikenakan biaya. vCore, penyimpanan khusus, dan penyimpanan cadangan dikenai biaya.
IOPS tidak dikenai biaya.

Catatan

Untuk informasi lebih lanjut tentang Perjanjian SLA, lihat SLA untuk Azure SQL Managed Instance.

Tujuan Umum

Model arsitektur untuk tingkat layanan Tujuan Umum didasarkan pada pemisahan komputasi dan penyimpanan. Model arsitektur ini bergantung pada ketersediaan tinggi dan keandalan penyimpanan Azure Blob yang secara transparan mereplikasi file database dan menjamin tidak ada kehilangan data jika kegagalan infrastruktur yang mendasar terjadi.

Gambar berikut menunjukkan empat node dalam model arsitektur standar dengan lapisan komputasi dan penyimpanan yang dipisahkan.

Pemisahan komputasi dan penyimpanan

Dalam model arsitektur untuk tingkat layanan Tujuan Umum, ada dua lapisan:

  • Lapisan komputasi stateless yang menjalankan sqlservr.exe proses dan hanya berisi data sementara dan cache (misalnya – cache paket, kumpulan buffer, kumpulan penyimpan kolom). Stateless node ini dioperasikan oleh Microsoft Azure Service Fabric yang menginisialisasi proses, mengontrol kondisi node, dan melakukan failover ke tempat lain jika perlu.
  • Lapisan stateful data dengan file database (.mdf/.ldf) yang disimpan dalam penyimpanan Azure Blob. Penyimpanan Azure Blob menjamin bahwa tidak akan ada kehilangan data dari catatan apa pun yang ditempatkan dalam file database apa pun. Azure Storage memiliki ketersediaan/redundansi data bawaan yang memastikan bahwa setiap rekaman dalam file log atau halaman dalam file data akan dipertahankan meskipun prosesnya macet.

Setiap kali mesin database atau sistem operasi ditingkatkan, beberapa bagian dari infrastruktur yang mendasarinya gagal, atau jika beberapa masalah penting terdeteksi dalam sqlservr.exe proses, Azure Service Fabric akan memindahkan proses stateless ke node komputasi stateless lainnya. Ada satu set node cadangan yang menunggu untuk menjalankan layanan komputasi baru jika kegagalan node utama terjadi untuk meminimalkan waktu failover. Data di lapisan penyimpanan Azure tidak terpengaruh, dan file data/log dilampirkan ke proses yang baru diinisialisasi. Proses ini menjamin ketersediaan 99,99% secara default. Mungkin ada beberapa dampak performa pada beban kerja berat yang sedang dalam penerbangan karena waktu transisi dan fakta bahwa simpul baru dimulai dengan cache dingin.

Kapan memilih tingkat layanan ini

Tingkat layanan Tujuan Umum adalah tingkat layanan default di Azure SQL Managed Instance yang dirancang untuk sebagian besar beban kerja generik. Jika Anda memerlukan mesin database yang terkelola penuh dengan SLA default dan latensi penyimpanan antara 5 hingga 10 md, tingkat General Purpose adalah opsi untuk Anda.

Tujuan Umum generasi berikutnya

Catatan

Peningkatan tingkat layanan Tujuan Umum Next-gen saat ini dalam pratinjau. Untuk memulai, gunakan peningkatan tingkat layanan Tujuan Umum Next-gen untuk instans baru dan yang sudah ada yang memenuhi syarat.

Tingkat layanan Tujuan Umum Next-gen adalah peningkatan arsitektur dari tingkat layanan Tujuan Umum yang ada yang menawarkan karakteristik utama berikut:

  • Dirancang untuk bisnis dengan persyaratan performa yang lebih tinggi sambil menawarkan biaya dasar yang sama dengan tingkat layanan Tujuan Umum
  • Peningkatan signifikan pada performa, skalabilitas, dan fleksibilitas sumber daya melalui tingkat layanan Tujuan Umum
  • Menggunakan disk terkelola alih-alih blob halaman, yang secara drastis meningkatkan metrik performa penyimpanan
  • 3 IOPS gratis untuk setiap GB penyimpanan cadangan
  • Dukungan hingga 500 database per instans, dan ukuran penyimpanan maksimum 32 TB

Karena tingkat layanan Tujuan Umum Next-gen adalah peningkatan ke tingkat layanan Tujuan Umum yang ada, terlepas dari tingkat layanan mana yang digunakan instans Anda, pernyataan penagihan Anda mencerminkan tingkat layanan Tujuan Umum.

Model arsitektur

Tingkat layanan Tujuan Umum Next-gen adalah peningkatan ke tingkat layanan Tujuan Umum yang ada yang menggunakan lapisan penyimpanan jarak jauh yang ditingkatkan untuk menyimpan data instans dan file log pada disk terkelola alih-alih blob halaman. Ini berarti peningkatan tingkat layanan Tujuan Umum Next-gen menawarkan latensi penyimpanan, IOPS, dan throughput yang lebih cepat daripada tingkat layanan Tujuan Umum yang ada, dengan peningkatan batas penyimpanan, jumlah vCore, dan jumlah maksimum database. Selain itu, karena kuota performa dibagikan oleh seluruh instans, Anda tidak perlu lagi mengubah ukuran file individual untuk meningkatkan performanya. Biaya dasar tingkat layanan Tujuan Umum Next-gen sama dengan tingkat layanan Tujuan Umum, tetapi Anda dapat menggunakan penggeser untuk meningkatkan performa IO Anda, yang kemudian ditagih secara terpisah.

Tingkat layanan Tujuan Umum Next-gen membantu mengurangi biaya dengan menawarkan IOPS gratis pada tiga IOPS untuk setiap GB penyimpanan yang dipesan. Harga penyimpanan mencakup IOPS minimum. Jika Anda melampaui minimum, Anda dikenakan biaya sebagai berikut: 1 IOPS = harga penyimpanan (menurut wilayah) dibagi tiga.

Contohnya:

  • Jika 1 GB biaya penyimpanan 0,115, maka 1 IOPS = 0,115/3 = 0,038 per IOPS.
  • Instans 1.024 GB menerima 3072 IOPS secara gratis. Anda dapat memilih untuk meningkatkan IOPS Hingga batas VM dengan biaya tambahan.

Kapan memilih tingkat layanan ini

Pilih tingkat layanan ini jika bisnis Anda berorientasi anggaran tetapi metrik performa dan batas tingkat layanan Tujuan Umum tidak mencukupi.

Alasan utama mengapa Anda harus memilih tingkat layanan Tujuan Umum Next-gen alih-alih tingkat Tujuan Umum adalah:

  • Performa yang lebih baik untuk biaya dasar yang sama
  • Latensi, throughput, dan IOPS yang ditingkatkan
  • Kapasitas penyimpanan yang lebih besar
  • Lebih banyak fleksibilitas untuk komputasi Anda
  • Anda memerlukan lebih dari 100 database untuk satu instans
  • Anda memerlukan lebih dari 16 TB penyimpanan yang dipesan

Kritis Bisnis

Model tingkat layanan Bisnis Kritis didasarkan pada kluster proses mesin database. Model arsitektur ini bergantung pada kuorum simpul mesin database yang selalu tersedia untuk meminimalkan dampak performa pada beban kerja Anda, bahkan selama aktivitas pemeliharaan. Azure meningkatkan dan menambal sistem operasi, driver, dan mesin database SQL Server yang mendasar secara transparan, dengan waktu henti minimal untuk pengguna akhir.

Dalam model Business Critical, komputasi dan penyimpanan terintegrasi pada setiap simpul. Replikasi data antara proses mesin database pada setiap simpul kluster empat node mencapai ketersediaan tinggi, dengan setiap simpul menggunakan SSD yang terpasang secara lokal sebagai penyimpanan data.

Kluster simpul mesin database

Proses mesin database SQL Server dan file .mdf/.ldf yang mendasarinya ditempatkan di simpul yang sama dengan penyimpanan SSD yang terpasang secara lokal yang memberikan latensi rendah ke beban kerja Anda. Ketersediaan tinggi diimplementasikan menggunakan teknologi yang mirip dengan Grup Ketersediaan AlwaysOn SQL Server.

Setiap instans adalah kluster simpul mesin database yang berisi salinan semua database pada instans, dengan database utama yang dapat diakses untuk beban kerja pelanggan, dan tiga database sekunder yang berisi salinan data, siap untuk failover. Simpul utama terus-menerus mendorong perubahan ke simpul sekunder untuk memastikan data tersedia pada replika sekunder jika simpul utama gagal karena alasan apa pun.

Kegagalan ditangani oleh mesin database SQL Server - satu replika sekunder menjadi simpul utama dan replika sekunder baru dibuat untuk memastikan ada cukup simpul dalam kluster. Beban kerja secara otomatis dialihkan ke simpul utama yang baru.

Selain itu, kluster Business Critical memiliki kemampuan Read Scale-Out bawaan yang menyediakan replika baca-saja gratis yang digunakan untuk menjalankan kueri baca-saja (seperti laporan) yang tidak akan memengaruhi performa beban kerja pada replika utama Anda.

Kapan memilih tingkat layanan ini

Tingkat layanan Business Critical dirancang untuk aplikasi yang memerlukan respons latensi rendah dari penyimpanan SSD yang mendasarinya (rata-rata 1-2 ms), pemulihan yang lebih cepat jika infrastruktur yang mendasarinya gagal, atau perlu melepas beban laporan, analitik, dan kueri baca-saja ke replika sekunder yang dapat dibaca secara gratis dari database utama.

Alasan kunci mengapa Anda harus memilih tingkat layanan Bisnis Kritis dan bukan tingkat Tujuan Umum adalah:

  • Persyaratan latensi I/O rendah - beban kerja yang membutuhkan tanggapan cepat dari lapisan penyimpanan (rata-rata 1-2 milidetik) harus menggunakan tingkat Bisnis Kritis.
  • Beban kerja dengan kueri pelaporan dan analitik yang dapat dialihkan ke replika baca-saja sekunder gratis.
  • Ketahanan yang lebih tinggi dan pemulihan yang lebih cepat atas kegagalan. Jika ada kegagalan sistem, database pada instans utama diambil offline, dan salah satu replika sekunder akan segera menjadi instans utama baca-tulis baru, siap untuk memproses kueri. Mesin database tidak perlu menganalisis dan mengulangi transaksi dari file log atau memuat data ke dalam buffer memori.
  • Perlindungan kerusakan data tingkat lanjut. Karena tingkat Bisnis Kritis menggunakan replika database di belakang layar, layanan memanfaatkan perbaikan halaman otomatis yang tersedia dengan pencerminan dan grup ketersediaan untuk membantu mengurangi kerusakan data. Jika replika tidak dapat membaca halaman karena masalah integritas data, salinan baru halaman diambil dari replika lain, menggantikan halaman yang tidak dapat dibaca tanpa kehilangan data atau waktu henti pelanggan. Fungsionalitas ini tersedia di tingkat Tujuan Umum jika instans terkelola memiliki replika geo-sekunder.
  • Ketersediaan yang lebih tinggi - Tingkat Bisnis Penting dalam konfigurasi zona multi-ketersediaan memberikan ketahanan terhadap kegagalan zonal dan SLA ketersediaan yang lebih tinggi.
  • Pemulihan geografis yang cepat - Jika grup failover dikonfigurasi, tingkat Business Critical memiliki Tujuan Titik Pemulihan (RPO) terjamin 5 detik dan Tujuan Waktu Pemulihan (RTO) 30 detik selama 100% jam yang disebarkan.

Saat menentukan tingkat layanan dalam templat atau skrip, tingkat disediakan dengan menggunakan namanya. Tabel berikut ini berlaku:

Perangkat Keras Nama
Tujuan Umum GeneralPurpose
Kritis Bisnis BusinessCritical

Konfigurasi perangkat keras

Opsi konfigurasi perangkat keras dalam model vCore termasuk seri standar (Gen5), seri premium, dan seri premium dengan memori yang dioptimalkan. Konfigurasi perangkat keras umumnya menentukan batas komputasi dan memori serta karakteristik lain yang memengaruhi performa beban kerja.

Untuk informasi selengkapnya tentang spesifikasi dan batasan konfigurasi perangkat keras, lihat Karakteristik konfigurasi perangkat keras.

Dalam tampilan manajemen dinamis sys.dm_user_db_resource_governance, pembuatan perangkat keras untuk instans yang menggunakan prosesor Intel® SP-8160 (Skylake) muncul sebagai Gen6, sedangkan pembuatan perangkat keras untuk instans yang menggunakan Intel® 8272CL (Cascade Lake) muncul sebagai Gen7. CPU Intel® 8370C (Ice Lake) yang digunakan oleh generasi perangkat keras seri premium dan memori yang dioptimalkan muncul sebagai Gen8. Batas sumber daya untuk semua instans Gen5 adalah sama, apa pun jenis prosesornya (Broadwell, Skylake, atau Cascade Lake).

Memilih konfigurasi perangkat keras

Anda dapat memilih konfigurasi perangkat keras pada saat pembuatan instans, atau Anda dapat mengubah perangkat keras instans yang ada.

Untuk memilih konfigurasi perangkat keras saat membuat SQL Managed Instance

Untuk informasi selengkapnya, lihat Membuat SQL Managed Instance.

Pada tab Dasar, pilih link Konfigurasikan database di bagian Komputasi + penyimpanan, lalu pilih perangkat keras yang diinginkan:

mengonfigurasi SQL Managed InstanceUntuk mengubah perangkat keras dari SQL Managed Instance yang sudah ada

Dari halaman SQL Managed Instance, pilih Komputasi + penyimpanan di bawah Pengaturan:

Cuplikan layar memperlihatkan halaman Komputasi + penyimpanan untuk instans terkelola SQL.

Pada halaman Komputasi + Penyimpanan , Anda dapat mengubah perangkat keras Anda di bawah Pembuatan perangkat keras dengan menggunakan penggeser untuk vCore dan Storage.

Saat menentukan parameter perangkat keras dalam templat atau skrip, perangkat keras disediakan dengan menggunakan namanya. Tabel berikut ini berlaku:

Perangkat Keras Nama
Seri Standar (Gen5) Gen5
Seri premium G8IM
Seri premium dengan memori dioptimalkans G8IH

Nama SKU

Catatan

Saat menspesifikasikan tingkat perangkat keras dan layanan dalam templat atau skrip, Anda dapat menentukannya secara independen, atau Anda dapat memberikan nama SKU. Saat menentukan nama SKU, tabel berikut ini berlaku:

SKU Tingkat Layanan Perangkat Keras
GP_Gen5 Tujuan Umum Seri standar
GP_G8IM Tujuan Umum Seri premium
GP_G8IH Tujuan Umum Memori seri premium dioptimalkan
BC_Gen5 Kritis Bisnis Seri standar
BC_G8IM Kritis Bisnis Seri premium
BC_G8IH Kritis Bisnis Memori seri premium dioptimalkan

Ketersediaan perangkat keras

Seri standar (Gen5) dan seri premium

Perangkat keras seri standar (Gen5) dan seri premium tersedia di semua wilayah publik di seluruh dunia.

Perangkat keras seri premium yang dioptimalkan memori dalam pratinjau, dan memiliki ketersediaan regional terbatas. Untuk informasi selengkapnya, lihat Batas sumber daya Azure SQL Managed Instance.

Langkah berikutnya