Disiplin penyimpanan untuk SQL Managed Instance dengan dukungan Azure Arc

  • Artikel

Penyimpanan adalah komponen penting dalam penyebaran SQL Managed Instance dengan dukungan Azure Arc (SQL Managed Instance berkemampuan Arc). Memahami bagaimana konsep terkait penyimpanan yang dijelaskan dalam dokumen ini memengaruhi fungsi kluster Kubernetes adalah aspek penting dari pilihan dan manajemen desain penyimpanan.

Daripada berinteraksi langsung dengan penyimpanan yang mendasar, Kubernetes menyediakan lapisan abstraksi ke berbagai teknologi penyimpanan melalui kelas penyimpanan. Penyedia cloud, vendor perangkat keras, dan platform terkelola Kubernetes lainnya menawarkan berbagai opsi StorageClass agar sesuai dengan lingkungan dan skenario implementasi tertentu.

SQL Managed Instance berkemampuan Arc tidak membatasi atau memberlakukan menggunakan kelas penyimpanan apa pun, jadi penting untuk memilih desain dan konfigurasi penyimpanan yang benar. Desain penyimpanan untuk SQL Managed Instance berkemampuan Arc sama pentingnya dengan memilih perangkat penyimpanan cadangan untuk SQL Server saat berjalan pada bare metal atau komputer virtual. Pilihan ini pada akhirnya mewakili kebutuhan Anda seputar RPO, RTO, kapasitas, dan performa.

Untuk penyebaran SQL Managed Instance berkemampuan Arc, merencanakan kemampuan dan konfigurasi penyimpanan secara efektif sangat penting untuk beroperasi dengan sukses. Baca terus untuk mempelajari tentang faktor terkait penyimpanan yang perlu dipertimbangkan, diikuti dengan rekomendasi untuk mengonfigurasi SQL Managed Instance berkemampuan Arc.

Arsitektur

Diagram arsitektur berikut menunjukkan desain logis komponen layanan data dengan dukungan Azure Arc. Komponen-komponen ini mencakup Pengontrol Data Azure Arc yang diperlukan dan satu atau beberapa SQL Managed Instance berkemampuan Arc yang berisi database yang disediakan untuk referensi. Pengontrol Data Azure Arc dan SQL Managed Instance berkemampuan Arc menyediakan opsi untuk mendukung perangkat penyimpanan, yang bergantung pada penyedia infrastruktur distribusi dan penyimpanan Kubernetes.

Cuplikan layar memperlihatkan diagram arsitektur logis layanan data dengan dukungan Azure Arc.

Mempertimbangkan rancangan

Berikut ini adalah pertimbangan untuk desain dan konfigurasi penyimpanan Anda.

Kelas Penyimpanan

Memilih Kubernetes StorageClass dan konfigurasi yang tepat untuk komponen layanan data dengan dukungan Azure Arc penting untuk performa, ketahanan, dan kapasitas penyimpanan data Anda.

StorageClass, PersistentVolume (PV), dan PersistentVolumeClaim (PVC) adalah objek sumber daya Kubernetes yang dibuat sistem di kluster Kubernetes saat menyediakan komponen layanan data dengan dukungan Azure Arc.

Opsi StorageClass bervariasi tergantung pada apa yang ditawarkan penyedia cloud, vendor perangkat keras, dan apa yang telah dikonfigurasi administrator Kubernetes. PersistentVolumeClaim meminta PersistentVolume dibuat untuk StorageClass dan ukuran yang diminta. Diagram berikut adalah referensi hubungan antara sumber daya Kube ini dan opsi potensial untuk kelas penyimpanan.

Cuplikan layar yang menunjukkan konsep penyimpanan Kubernetes dengan opsi kelas penyimpanan.

Sumber daya PV dan PVC Kubernetes dikonfigurasi saat memprovisikan Pengontrol Data Azure Arc dan SQL Managed Instance yang diaktifkan Arc.

Ada dua jenis penyimpanan yang berbeda untuk dipilih:

  • Lokal: Volume yang dipasang pada perangkat penyimpanan lokal yang terpasang pada simpul Kubernetes tempat pod berjalan. Jenis penyimpanan ini biasanya memberikan latensi yang lebih rendah bersama dengan operasi input/output yang lebih tinggi per detik (IOPS) dan throughput dibandingkan dengan penyimpanan Jarak Jauh/Bersama.
  • Penyimpanan jarak jauh/bersama: Perangkat penyimpanan yang terpasang pada jaringan yang cenderung dilengkapi dengan redundansi bawaan. Opsi penyimpanan umum adalah perangkat NAS dan SAN.

Pertimbangkan standar berikut saat memilih StorageClass. Kriteria ini juga akan berlaku untuk server database apa pun yang akan Anda bangun:

  • Kinerja: Throughput input/output perangkat penyimpanan (I/O) dan IOPS harus memenuhi kebutuhan database Anda.
  • Rasio Baca/Tulis: Memahami beban kerja dapat membantu Anda memilih perangkat keras yang mendukung untuk memenuhi kebutuhan Anda dengan biaya yang sesuai. Beban kerja tulis berat dapat memanfaatkan konfigurasi RAID 0, sedangkan data yang jarang diakses mungkin paling baik disajikan menggunakan penyimpanan perangkat SAN.
  • Isolasi database dan lokasi bersama: Semua database pada instans PV berbagi SQL Managed Instance berkemampuan Arc, sehingga Anda dapat memilih untuk memindahkan database ke instans SQL Managed Instance berkemampuan Arc dan menghindari ketidakcocokan sumber daya penyimpanan.
  • Kapasitas: Ukuran penyimpanan yang ditentukan harus memenuhi kapasitas pengontrol data dan instans database Anda di masa mendatang untuk menghindari perubahan ukuran PVC. Pertimbangkan batasan penyimpanan apa pun yang mungkin dimiliki StorageClass pilihan Anda.
  • Mode akses: Penyedia Kelas Penyimpanan memiliki mode akses yang berbeda, mendukung kemampuan yang berbeda tentang bagaimana penyimpanan dapat dipasang dan dibaca atau ditulis oleh pod. RWX (Baca Tulis Banyak) diperlukan untuk volume Cadangan SQL.
  • Redundansi: Replikasi data di lapisan penyimpanan fisik (RAID) untuk mendukung failover yang mulus jika kegagalan disk perangkat keras terjadi, yang terpisah dari redundansi tingkat database yang dilakukan oleh Grup Ketersediaan (AG).

Baik Pengontrol Data Azure Arc maupun layanan data Arc SQL Managed Instance yang diaktifkan Arc menyediakan opsi terperinci untuk mengonfigurasi kelas penyimpanan yang berbeda untuk data database. Layanan data ini juga menyediakan log, yang memungkinkan fleksibilitas dalam memilih kelas penyimpanan untuk memenuhi kebutuhan.

Pengontrol Data

Pengontrol Data Azure Arc tunggal diperlukan untuk Kluster Kubernetes sebagai prasyarat untuk membuat instans SQL Managed Instance berkemampuan Arc. Lebih dari satu pengontrol data yang berjalan dalam kluster tidak didukung.

Pengontrol Data Azure Arc akan memiliki empat pod stateful berbeda yang berjalan di kluster Kubernetes: Controller SQL, Controller API, Logs DB, dan Metrics DB. Setiap pod memerlukan dua Volume Persisten untuk volume data dan log. Semua komponen pengontrol data memerlukan StorageClass jarak jauh untuk memastikan durabilitas data, karena komponen pengontrol data itu sendiri tidak secara asli memberikan durabilitas data.

Pastikan untuk mempertimbangkan sumber daya komputasi dan memori yang diperlukan Pengontrol Data Azure Arc. Diagram berikut mewakili penyimpanan pengontrol data, PV, dan sumber daya PVC Kubernetes.

Cuplikan layar memperlihatkan penyimpanan Pengontrol Data Azure Arc.

Ukuran volume default pengontrol data adalah minimum yang disarankan. Penyimpanan yang Anda gunakan bergantung pada jumlah database, cara Anda menggunakan database, dan jumlah log yang dihasilkan. StorageClass Pengontrol Data Azure Arc tidak sensitif terhadap latensi rendah. Meskipun demikian, pengguna mungkin melihat manfaat di antarmuka Grafana dan Kibana dengan penyimpanan berkinerja lebih cepat jika Anda memiliki banyak penyebaran SQL Managed Instance yang diaktifkan Arc dalam kluster. Grafana dan Kibana adalah alat visualisasi pemantauan sumber terbuka yang disebarkan dengan pengontrol data dan disediakan dengan dasbor untuk melihat metrik dan log untuk SQL Managed Instance yang diaktifkan Arc.

Provisi pengontrol data

Saat Anda menyediakan Pengontrol Data Azure Arc, konfigurasikan StorageClass dan kapasitas penyimpanan untuk log dan data. Mengonfigurasi penyimpanan untuk log dan data kemudian berlaku untuk kedelapan PV yang Anda buat untuk pod pengontrol data. Selama provisi, Anda dapat menentukan templat penyebaran kustom yang mengambil alih parameter default seperti kapasitas, retensi log, dan item yang terkait dengan keamanan seperti Jenis Layanan Kubernetes. Setelah provisi selesai, objek PV dan PVC Kubernetes dibuat.

Penting untuk dipahami bahwa StorageClass untuk pengontrol data tidak dapat diubah setelah disediakan. Jika Anda tidak menentukan StorageClass, pengontrol data menggunakan StorageClass default Kubernetes, yang dapat bervariasi tergantung pada instans atau penyedia Kubernetes Anda.

Saat Anda menghapus pengontrol Data Azure Arc, semua Volume Persisten yang terkait dengannya akan dihapus. Arsipkan log tingkat sarana kontrol layanan data dengan dukungan Azure Arc yang perlu disimpan organisasi Anda sebelum menghapus pengontrol data.

SQL Managed Instance dengan dukungan Azure Arc

SQL Managed Instance dengan dukungan Arc menawarkan dua tingkatan yang berbeda tergantung pada persyaratan bisnis: Tujuan Umum dan Kritis Bisnis. Untuk kedua tingkatan, penting untuk meninjau batas SQL Managed Instance minimum dan maksimum yang diaktifkan Arc, yang dapat dikonfigurasi, dan memastikan bahwa kluster Kubernetes yang disebarkan memiliki kapasitas komputasi dan memori yang sesuai.

Dalam skenario dengan beberapa database pada instans database tertentu, semua database menggunakan StorageClass, PVC, dan PV yang sama yang ditentukan untuk SQL Managed Instance berkemampuan Arc. Dimungkinkan untuk memiliki beberapa instans SQL Managed Instance berkemampuan Arc dalam satu kluster Kubernetes. Konfigurasi ini memungkinkan Volume Persisten independen dan dapat membantu memisahkan ketidakcocokan IO dari database yang berbeda dengan menyebarkan database ke berbagai instans SQL Managed Instance berkemampuan Arc.

Tabel berikut menjelaskan berbagai Volume Persisten yang digunakan oleh setiap pod SQL Managed Instance berkemampuan Arc dan tujuannya.

Volume Persisten Deskripsi Persyaratan Kelas Penyimpanan
Data SQL Database file data (file.mdf) Tergantung pada tingkatan
DataLogs SQL Database file log (file.ldf) Tergantung pada tingkatan
Log Agen SQL, log kesalahan, file pelacakan, log kesehatan Tergantung pada tingkatan
Pencadangan SQL Server file Backup termasuk Full, Diff, Transactional Log Mode Akses Remote, ReadWriteMany

Tingkat layanan Tujuan Umum

Tingkat Tujuan Umum SQL Managed Instance berkemampuan Arc harus menggunakan penyimpanan jarak jauh untuk instans database sehingga, setelah kegagalan pod, data tetap tersedia untuk pod yang baru dibuat. Failover dikelola oleh pod Kubernetes dan orkestrasi simpul. Konfigurasi ini kurang kompleks dibandingkan dengan Business Critical, yang menggunakan Grup Ketersediaan SQL dan beberapa replika SQL Managed Instance berkemampuan Arc. Konfigurasi pod tunggal dari tingkat Tujuan Umum berarti Anda dapat meminimalkan jumlah penyimpanan karena Anda tidak perlu menduplikasi kapasitas penyimpanan untuk replika lain.

Cuplikan layar yang menunjukkan penyimpanan Tujuan Umum SQL Managed Instance dengan dukungan Arc.

Tingkat layanan Penting Bisnis

Tingkat Bisnis Kritis menggunakan beberapa model pod di mana data dan volume log dapat disimpan di kelas penyimpanan lokal atau jarak jauh. Kelas penyimpanan lokal biasanya berkinerja lebih baik dalam hal latensi dan throughput karena perangkat penyimpanan langsung terpasang pada simpul. Penyimpanan jarak jauh biasanya menawarkan redundansi bawaan tetapi sering memiliki latensi dan throughput yang lebih rendah dibandingkan dengan penyimpanan lokal. Perlu diingat bahwa menggunakan lebih banyak replika database Penting Bisnis memerlukan Volume Persisten ekstra untuk Data, Log, dan DataLog. Total kapasitas penyimpanan yang diperlukan jauh lebih tinggi.

Diagram berikut menunjukkan konfigurasi penyimpanan Business Critical untuk Arc-Enabled SQL Managed Instance dengan dua replika.

Cuplikan layar yang menunjukkan penyimpanan SQL Managed Instance Business Critical dengan dukungan Arc.

Business Critical memungkinkan Anda mengonfigurasi dua atau tiga replika sekunder. Failover dikelola oleh Grup Ketersediaan AlwaysOn SQL, yang memberikan lebih sedikit waktu henti untuk peningkatan dan kegagalan daripada tingkat Tujuan Umum.

Mengonfigurasi beberapa replika dengan replikasi data mode penerapan sinkron memastikan perlindungan yang lebih baik terhadap kegagalan, seperti pod, simpul, atau perangkat keras penyimpanan yang gagal. Ini melindungi dari kegagalan karena ada beberapa salinan data pada replika. Pertimbangkan untuk mengonfigurasi replika sekunder sebagai instans peluasan skala baca, yang dapat disambungkan klien saat menggunakan titik akhir pendengar sekunder.

Azure Arc SQL Managed Instance provisi dan penghapusan instalasi

Saat menyediakan SQL Managed Instance berkemampuan Arc, Anda memiliki fleksibilitas untuk menetapkan kelas penyimpanan yang berbeda ke masing-masing Volume Persisten SQL Managed Instance berkemampuan Arc yang diperlukan. Anda mungkin menginginkan opsi penyimpanan berkinerja lebih tinggi untuk Data dan DataLogs, tetapi volume Log dan Cadangan dapat menggunakan opsi StorageClass yang lebih hemat biaya untuk menghemat biaya. Dalam skenario di mana Anda menggunakan penyimpanan lokal, pastikan bahwa volume dapat mendarat di simpul dan perangkat penyimpanan fisik yang berbeda untuk menghindari pertikaian pada I/O disk. Menempatkan Data dan DataLogs pada drive fisik yang sama dapat menyebabkan ketidakcocokan untuk drive penyimpanan tersebut, mengakibatkan performa yang buruk. Sebagai gantinya, pertimbangkan untuk menempatkan Data dan DataLogs pada drive penyimpanan terpisah untuk menyejajarkan I/O untuk data database dan log.

Saat Anda menghapus SQL Managed Instance yang diaktifkan Arc, PV dan PVC terkait tidak dihapus. Perilaku ini memastikan bahwa Anda dapat mengakses file database jika penghapusan tidak disengaja.

Rekomendasi desain

Berikut ini adalah rekomendasi untuk desain dan konfigurasi penyimpanan Anda.

Kelas Penyimpanan untuk beban kerja produksi

Untuk cloud publik tertentu, kelas penyimpanan yang direkomendasikan untuk beban kerja produksi ditampilkan dalam tabel berikut.

Penyedia Penyimpanan yang divalidasi dan direkomendasikan
Azure Kubernetes Service (AKS) Disk Terkelola Azure (tingkat Premium)
Amazon Elastic Kubernetes Service (EKS) Driver penyimpanan CSI EBS
Google (GKE) Disk Persisten GCE

Saat memilih StorageClass produksi dalam skenario lokal atau multicloud, pastikan storageClass dalam skenario lokal atau multicloud mampu memenuhi kebutuhan kapasitas penyimpanan, IOPS, redundansi, dan throughput yang Anda maksudkan. Bagian berikut ini memberikan lebih banyak rekomendasi untuk skenario ini.

Desain pengontrol data

Pilih StorageClass bersama jarak jauh untuk memastikan durabilitas data. Jika pod atau simpul dihapus, Anda dapat membawa pod kembali dan terhubung lagi ke Volume Persisten. Garis bawah StorageClass harus memberikan redundansi dan ketersediaan tinggi.

Sebaiknya gunakan templat penyebaran kustom saat Anda membuat pengontrol data layanan data dengan dukungan Arc. Templat kustom memungkinkan Anda menyempurnakan kelas penyimpanan, ukuran penyimpanan untuk data dan log, keamanan, dan Jenis Layanan Kubernetes. Anda dapat menyesuaikannya untuk kebutuhan lingkungan dan perusahaan Anda. Pengontrol Data Azure Arc memerlukan total delapan Volume Persisten. Konfigurasi minimum default memungkinkan 15Gi untuk data dan 10Gi untuk log pada PV. Mengonfigurasi kapasitas yang tidak hanya memenuhi rekomendasi minimum tetapi mendukung pertumbuhan yang lebih tinggi dari memiliki banyak implementasi SQL Managed Instance berkemampuan Arc yang berjalan dalam kluster. Konfigurasi ini akan mencegah kebutuhan untuk mengubah ukuran PVC di masa mendatang.

Kami sarankan Anda memilih StorageClass latensi yang lebih rendah jika kluster Anda memiliki banyak database dan penyebaran SQL Managed Instance dengan dukungan Arc. Latensi yang lebih rendah meningkatkan pengalaman pengguna di antarmuka Grafana dan Kibana.

Migrasi SQL Managed Instance dengan dukungan Azure Arc

Kami menyarankan Anda merencanakan dan mempertanyakan semua database baru dan yang sudah ada yang terlibat dalam migrasi dan penyebaran SQL Managed Instance berkemampuan Arc Anda. Perencanaan mencegah kebutuhan untuk memindahkan database antar instans di lain waktu.

Bergantung pada organisasi kluster Kubernetes Anda, provisikan penyebaran SQL Managed Instance dengan dukungan Arc ke kluster Kubernetes yang berbeda berdasarkan kebutuhan untuk memisahkan lingkungan (non-prod, prod), wilayah, dan faktor bisnis lainnya. Tinjau area Desain organisasi sumber daya untuk rekomendasi selengkapnya. Saat mengonfigurasi beberapa instans database pada kluster, pastikan untuk memisahkan database sibuk ke dalam instans mereka sendiri untuk menghindari pertikaian I/O.

Gunakan label simpul untuk memastikan bahwa instans database dimasukkan ke simpul terpisah untuk mendistribusikan lalu lintas I/O secara keseluruhan di beberapa simpul, lihat Label Simpul Kube bersama dengan afinitas Node Kube dan label anti-afinitas untuk mengonfigurasi label. Jika beroperasi di lingkungan virtual, pastikan bahwa I/O didistribusikan dengan tepat di tingkat host fisik.

Rencanakan kapasitas untuk SQL Managed Instance berkemampuan Arc untuk menyertakan ukuran penyimpanan yang memadai untuk Data, Log, DataLog, dan Cadangan. Ketika Anda merencanakan kapasitas untuk mengakomodasi kebutuhan saat ini dan proyeksi pertumbuhan untuk semua database yang akan hidup pada instans SQL Managed Instance berkemampuan Arc, itu mencegah harus mengubah ukuran PVC di masa depan. Pilih drive fisik terpisah untuk Data dan DataLogs untuk memungkinkan aktivitas I/O paralel terjadi. Aktivitas I/O paralel menghasilkan peningkatan performa dengan menghindari kemungkinan ketidakcocokan yang disebabkan saat menggunakan drive bersama.

Meskipun ada beberapa faktor yang mungkin menentukan penyebaran tingkat Business Critical atau General Purpose dari SQL Managed Instance berkemampuan Arc, Business Critical menggunakan penyimpanan lokal memberikan latensi terendah dan ketersediaan tertinggi. Tinjau area desain kelangsungan bisnis SQL Managed Instance dengan dukungan Arc untuk rekomendasi seputar pemulihan titik waktu, ketersediaan tinggi, dan pemulihan bencana. Selain itu, tinjau area desain tata kelola biaya SQL Managed Instance yang diaktifkan Arc untuk mempelajari selengkapnya tentang implikasi biaya antar tingkatan.

Sub bagian berikut memberikan rekomendasi yang lebih spesifik untuk setiap tingkatan:

Rekomendasi tingkat layanan Tujuan Umum

Disarankan untuk memilih StorageClass jarak jauh latensi rendah untuk Volume Persisten Data dan DataLogs untuk performa optimal. Hindari menggunakan StorageClass yang memperkenalkan partisi jaringan, seperti memiliki kluster lokal yang dikonfigurasi untuk menggunakan StorageClass yang disediakan internet untuk Volume Persisten Cadangan dan Log .

Rekomendasi tingkat layanan Business Critical

Disarankan untuk meninjau perbedaan mode Ketersediaan, yang akan memerlukan konfigurasi yang berbeda untuk setiap mode yang dipilih.

Untuk skenario persyaratan latensi seendah mungkin, pilih penyimpanan lokal jika merupakan opsi untuk infrastruktur Kubernetes Anda. Volume penyimpanan lokal harus mendarat di perangkat penyimpanan yang mendasari yang berbeda untuk menghindari pertikaian pada I/O disk dan memaksimalkan performa. Perangkat penyimpanan tidak boleh memiliki beberapa fungsi, seperti menghosting partisi Sistem Operasi.

Untuk beban kerja baca intensif dan ketersediaan tinggi, konfigurasikan beberapa replika dan konfigurasikan aplikasi atau klien Anda untuk menggunakan replika sekunder sebagai instans Read Scale-Out. Replika sekunder tidak dapat dibaca secara default; Anda dapat mengonfigurasi pengaturan.

Pemantauan

Disarankan untuk memantau semua PVC yang dibuat oleh layanan data berkemampuan Arc, termasuk Pengontrol Data Azure Arc dan semua instans SQL Managed Instance berkemampuan Arc dalam kluster. Atur pemberitahuan untuk memberi tahu Anda saat PVC mendekati kapasitas. Pemberitahuan memungkinkan Anda mengubah ukuran PVC sebelum mencapai kapasitas. Untuk kluster yang Terhubung Langsung, pemantauan PVC dan pemberitahuan dilakukan oleh Azure Monitor dan Container Insights. Saat Anda menggunakan kluster Terhubung Tidak Langsung, lakukan pemantauan dan pemberitahuan di Grafana dan Kibana. Penginstalan Grafana mencakup dasbor untuk metrik SQL Managed Instance dengan dukungan Arc dan sumber daya Kubernetes.

Tinjau disiplin tata kelola SQL Managed Instance berkemampuan Arc untuk rekomendasi lebih lanjut tentang pemantauan SQL Managed Instance berkemampuan Arc.

Langkah berikutnya

Untuk informasi selengkapnya tentang perjalanan cloud hibrid dan multicloud Anda, lihat artikel berikut ini: