Persistensi data di Kubernetes dengan SQL Server Kluster Big Data

  • Artikel

Berlaku untuk: SQL Server 2019 (15.x)

Penting

Add-on Kluster Big Data Microsoft SQL Server 2019 akan dihentikan. Dukungan untuk SQL Server 2019 Kluster Big Data akan berakhir pada 28 Februari 2025. Semua pengguna SQL Server 2019 yang ada dengan Jaminan Perangkat Lunak akan didukung sepenuhnya pada platform dan perangkat lunak akan terus dipertahankan melalui pembaruan kumulatif SQL Server hingga saat itu. Untuk informasi selengkapnya, lihat posting blog pengumuman dan Opsi big data di platform Microsoft SQL Server.

Volume persisten menyediakan model plug-in untuk penyimpanan di Kubernetes. Dalam model ini, cara penyimpanan disediakan diabstraksi dari cara penyimpanan dikonsumsi. Oleh karena itu, Anda dapat membawa penyimpanan Anda sendiri yang sangat tersedia dan menyambungkannya ke kluster big data SQL Server. Meskipun Kubernetes mendukung berbagai jenis solusi penyimpanan, termasuk disk dan file Azure, Network File System (NFS), dan penyimpanan lokal, Kluster Big Data hanya didukung pada konfigurasi yang diuji. Untuk informasi selengkapnya tentang konfigurasi yang didukung, lihat Catatan rilis platform Kluster Big Data SQL Server 2019.

Penting

Jika Anda menyebarkan kluster big data di Azure menggunakan salah satu layanan Kubernetes terkelola (AKS atau ARO), perlu diingat ada batasan yang mungkin perlu Anda akomodasi, tergantung pada persyaratan beban kerja aplikasi Anda. Misalnya, volume yang menggunakan disk terkelola Azure saat ini bukan sumber daya zona-redundan. Volume tidak dapat dilampirkan di seluruh zona dan harus berlokasi bersama di zona yang sama dengan simpul terkait yang menghosting pod target. Dalam kasus spesifik ini, Anda mungkin ingin menggunakan solusi ketersediaan tinggi tambahan yang tersedia dengan SQL Server Kluster Big Data. Lihat di sini untuk detail selengkapnya tentang layanan Azure Kubernetes dan zona ketersediaan.

Mengonfigurasi volume persisten

Kluster big data SQL Server menggunakan volume persisten ini dengan menggunakan kelas penyimpanan. Anda dapat membuat kelas penyimpanan yang berbeda untuk berbagai jenis penyimpanan dan menentukannya pada saat penyebaran kluster big data. Anda dapat mengonfigurasi kelas penyimpanan dan ukuran klaim volume persisten yang akan digunakan untuk tujuan tertentu di tingkat kumpulan. Kluster big data SQL Server membuat klaim volume persisten dengan menggunakan nama kelas penyimpanan yang ditentukan untuk setiap komponen yang memerlukan volume persisten. Kemudian memasang volume persisten (atau volume) yang sesuai di pod.

Berikut adalah beberapa aspek penting yang perlu dipertimbangkan saat Anda merencanakan konfigurasi penyimpanan untuk kluster big data Anda:

  • Untuk penyebaran kluster big data yang berhasil, pastikan Anda memiliki jumlah volume persisten yang diperlukan yang tersedia. Jika Anda menyebarkan pada kluster Azure Kubernetes Service (AKS) dan Anda menggunakan kelas penyimpanan bawaan (default atau managed-premium), kelas ini mendukung provisi dinamis untuk volume persisten. Oleh karena itu, Anda tidak perlu membuat volume persisten sebelumnya, tetapi Anda harus memastikan simpul pekerja yang tersedia di kluster AKS dapat melampirkan disk sebanyak jumlah volume persisten yang diperlukan untuk penyebaran. Bergantung pada ukuran VM yang ditentukan untuk simpul pekerja, setiap simpul dapat melampirkan sejumlah disk tertentu. Untuk kluster ukuran default (tanpa ketersediaan tinggi), diperlukan minimal 24 disk. Jika Anda mengaktifkan ketersediaan tinggi atau meningkatkan kumpulan apa pun, pastikan Anda memiliki setidaknya dua volume yang bertahan per setiap replika tambahan, terlepas dari sumber daya yang Anda tingkatkan.

  • Jika penyedia penyimpanan untuk kelas penyimpanan yang Anda sediakan dalam konfigurasi tidak mendukung provisi dinamis, Anda harus membuat volume yang dipertahankan sebelumnya. Misalnya, provisi local-storage tidak mengaktifkan provisi dinamis. Lihat contoh skrip ini untuk panduan tentang cara melanjutkan di kluster Kubernetes yang disebarkan dengan kubeadm.

  • Saat Anda menyebarkan kluster big data, Anda dapat mengonfigurasi kelas penyimpanan yang sama untuk digunakan oleh semua komponen dalam kluster. Tetapi sebagai praktik terbaik untuk penyebaran produksi, berbagai komponen akan memerlukan konfigurasi penyimpanan yang berbeda untuk mengakomodasi berbagai beban kerja dalam hal ukuran atau throughput. Anda dapat menimpa konfigurasi penyimpanan default yang ditentukan dalam pengontrol untuk setiap instans master, himpunan data, dan kumpulan penyimpanan SQL Server. Artikel ini menyediakan contoh cara melakukan ini.

  • Saat menghitung persyaratan ukuran kumpulan penyimpanan, Anda harus mempertimbangkan faktor replikasi yang dikonfigurasi HDFS. Faktor replikasi dapat dikonfigurasi pada waktu penyebaran dalam file konfigurasi penyebaran kluster. Nilai default untuk profil dev-test (yaitu aks-dev-test atau kubeadm-dev-test) adalah 2, dan untuk profil yang kami rekomendasikan untuk penyebaran produksi (yaitu kubeadm-prod) nilai defaultnya adalah 3. Sebagai praktik terbaik, kami sarankan Anda mengonfigurasi penyebaran produksi kluster big data dengan faktor replikasi untuk HDFS setidaknya 3. Nilai faktor replikasi akan memengaruhi jumlah instans di kumpulan penyimpanan: minimal, Anda harus menyebarkan setidaknya sebanyak mungkin instans kumpulan penyimpanan sebagai nilai faktor replikasi. Selain itu, Anda harus mengukur penyimpanan yang sesuai, dan tante untuk data yang direplikasi dalam HDFS sebanyak nilai faktor replikasi. Anda dapat menemukan lebih lanjut tentang replikasi data di HDFS di sini.

  • Pada rilis CU1 SQL Server 2019, BDC tidak mengaktifkan pengalaman untuk memperbarui pengaturan konfigurasi penyimpanan pasca-penyebaran. Batasan ini mencegah Anda menggunakan operasi BDC untuk memodifikasi ukuran klaim volume persisten untuk setiap instans atau menskalakan kumpulan apa pun pasca-penyebaran. Oleh karena itu, sangat penting bahwa Anda merencanakan tata letak penyimpanan sebelum Anda menyebarkan kluster big data. Namun, Anda dapat memperluas ukuran volume persisten menggunakan API Kubernetes secara langsung. Dalam hal ini, metadata BDC tidak akan diperbarui dan Anda akan melihat inkonsistensi mengenai ukuran volume dalam metadata kluster konfigurasi.

  • Dengan menyebarkan pada Kubernetes sebagai aplikasi dalam kontainer, dan dengan menggunakan fitur seperti set stateful dan penyimpanan persisten, Kubernetes memastikan bahwa pod dimulai ulang jika terjadi masalah kesehatan dan terpasang pada penyimpanan persisten yang sama. Tetapi jika ada kegagalan node dan pod harus dimulai ulang pada node lain, ada peningkatan risiko tidak tersedia jika penyimpanan lokal ke node yang gagal. Untuk mengurangi risiko ini, Anda harus mengonfigurasi redundansi tambahan dan mengaktifkan fitur ketersediaan tinggi atau menggunakan penyimpanan redundan jarak jauh. Berikut adalah gambaran umum opsi penyimpanan untuk berbagai komponen dalam kluster big data:

Sumber Jenis penyimpanan untuk data Jenis penyimpanan untuk log Catatan
Instans master SQL Server Penyimpanan lokal (replika>=3) atau redundan jarak jauh (replika=1) Penyimpanan lokal Implementasi berbasis set stateful di mana pod yang menempel pada simpul akan memastikan restart, dan kegagalan sementara tidak akan menyebabkan kehilangan data.
Kumpulan komputasi Penyimpanan lokal Penyimpanan lokal Tidak ada data pengguna yang disimpan.
Kumpulan data Penyimpanan redundan lokal/jarak jauh Penyimpanan lokal Gunakan penyimpanan redundan jarak jauh jika kumpulan data tidak dapat dibangun kembali dari sumber data lain.
Kumpulan penyimpanan (HDFS) Penyimpanan redundan lokal/jarak jauh Penyimpanan lokal Replikasi HDFS diaktifkan.
Kumpulan Spark Penyimpanan lokal Penyimpanan lokal Tidak ada data pengguna yang disimpan.
Kontrol (controldb, metricsdb, logsdb) Penyimpanan redundan jarak jauh Penyimpanan lokal Penting untuk menggunakan redundansi tingkat penyimpanan untuk metadata kluster big data.

Penting

Pastikan komponen terkait kontrol berada di perangkat penyimpanan redundan jarak jauh. Pod controldb-0 menghosting instans SQL Server dengan database yang menyimpan semua metadata yang terkait dengan status layanan kluster, berbagai pengaturan, dan info relevan lainnya. Jika instans ini menjadi tidak tersedia, instans ini akan menyebabkan masalah kesehatan dengan layanan dependen lainnya dalam kluster.

Mengonfigurasi pengaturan penyimpanan kluster big data

Seperti dalam penyesuaian lain, Anda dapat menentukan pengaturan penyimpanan dalam file konfigurasi kluster pada waktu penyebaran untuk setiap kumpulan dalam bdc.json file konfigurasi dan untuk layanan kontrol dalam control.json file. Jika tidak ada pengaturan konfigurasi penyimpanan dalam spesifikasi kumpulan, pengaturan penyimpanan kontrol akan digunakan untuk semua komponen lain, termasuk master SQL Server (master sumber daya), HDFS (storage-0 sumber daya), dan komponen kumpulan data. Sampel kode berikut mewakili bagian konfigurasi penyimpanan yang dapat Anda sertakan dalam spesifikasi:

    "storage": 
    {
      "data": {
        "className": "default",
        "accessMode": "ReadWriteOnce",
        "size": "15Gi"
      },
      "logs": {
        "className": "default",
        "accessMode": "ReadWriteOnce",
        "size": "10Gi"
    }

Penyebaran kluster big data menggunakan penyimpanan persisten untuk menyimpan data, metadata, dan log untuk berbagai komponen. Anda dapat menyesuaikan ukuran klaim volume persisten yang dibuat sebagai bagian dari penyebaran. Sebagai praktik terbaik, kami sarankan Anda menggunakan kelas penyimpanan dengan kebijakan Retainreclaim.

Peringatan

Berjalan tanpa penyimpanan persisten dapat berfungsi di lingkungan pengujian, tetapi dapat mengakibatkan kluster yang tidak berfungsi. Ketika pod dimulai ulang, metadata kluster dan/atau data pengguna hilang secara permanen. Kami tidak menyarankan Agar Anda berjalan di bawah konfigurasi ini.

Bagian Konfigurasikan penyimpanan menyediakan lebih banyak contoh cara mengonfigurasi pengaturan penyimpanan untuk penyebaran kluster big data SQL Server Anda.

Kelas penyimpanan AKS

AKS dilengkapi dengan dua kelas penyimpanan bawaan, default dan managed-premium, bersama dengan provisi dinamis untuk mereka. Anda dapat menentukan salah satu dari mereka atau membuat kelas penyimpanan Anda sendiri untuk menyebarkan kluster big data dengan penyimpanan persisten diaktifkan. Secara default, file konfigurasi kluster bawaan untuk AKS, aks-dev-test, dilengkapi dengan konfigurasi penyimpanan persisten untuk menggunakan default kelas penyimpanan.

Peringatan

Volume persisten yang dibuat dengan kelas default penyimpanan bawaan dan managed-premium memiliki kebijakan reklamasi Hapus. Jadi, ketika Anda menghapus kluster big data SQL Server, klaim volume persisten dihapus seperti volume persisten. Anda dapat membuat kelas penyimpanan kustom dengan menggunakan azure-disk provisioner dengan kebijakan klaim ulang, seperti yang Retain dijelaskan dalam penyimpanan Konsep.

Kelas penyimpanan untuk kubeadm kluster

Kluster Kubernetes yang disebarkan dengan menggunakan kubeadm tidak memiliki kelas penyimpanan bawaan. Anda harus membuat kelas penyimpanan dan volume persisten Anda sendiri dengan menggunakan penyimpanan lokal atau penyedia penyimpanan pilihan Anda. Dalam situasi tersebut, Anda mengatur className ke kelas penyimpanan yang Anda konfigurasikan.

Penting

Dalam file konfigurasi penyebaran bawaan untuk kubeadm (kubeadm-dev-test dan kubeadm-prod), tidak ada nama kelas penyimpanan yang ditentukan untuk penyimpanan data dan log. Sebelum penyebaran, Anda harus menyesuaikan file konfigurasi dan mengatur nilai untuk className. Jika tidak, validasi pra-penyebaran akan gagal. Penyebaran juga memiliki langkah validasi yang memeriksa keberadaan kelas penyimpanan, tetapi tidak untuk volume persisten yang diperlukan. Pastikan Anda membuat volume yang cukup, tergantung pada skala kluster Anda. Untuk ukuran kluster minimum default (skala default, tidak ada ketersediaan tinggi) Anda harus membuat setidaknya 24 volume persisten. Untuk contoh cara membuat volume persisten dengan menggunakan provisi lokal, lihat Membuat kluster Kubernetes menggunakan Kubeadm.

Menyesuaikan konfigurasi penyimpanan untuk setiap kumpulan

Untuk semua kustomisasi, Anda harus terlebih dahulu membuat salinan file konfigurasi bawaan yang ingin Anda gunakan. Misalnya, perintah berikut membuat salinan aks-dev-test file konfigurasi penyebaran di subdirektori bernama custom:

azdata bdc config init --source aks-dev-test --target custom

Proses ini membuat dua file, bdc.json dan control.json, yang dapat Anda sesuaikan baik dengan mengeditnya secara manual atau dengan menggunakan azdata bdc config perintah . Anda dapat menggunakan kombinasi pustaka jsonpath dan jsonpatch untuk menyediakan cara mengedit file konfigurasi Anda.

Mengonfigurasi nama kelas penyimpanan dan/atau ukuran klaim

Secara default, ukuran klaim volume persisten yang disediakan untuk setiap pod yang disediakan dalam kluster adalah 10 gigabyte (GB). Anda dapat memperbarui nilai ini untuk mengakomodasi beban kerja yang Anda jalankan dalam file konfigurasi kustom sebelum penyebaran kluster.

Dalam contoh berikut, ukuran klaim volume persisten diperbarui menjadi 32 GB di control.json. Jika tidak ditimpa pada tingkat kumpulan, pengaturan ini akan diterapkan ke semua kumpulan.

azdata bdc config replace --config-file custom/control.json --json-values "$.spec.storage.data.size=100Gi"

Contoh berikut menunjukkan cara mengubah kelas penyimpanan untuk control.json file:

azdata bdc config replace --config-file custom/control.json --json-values "$.spec.storage.data.className=<yourStorageClassName>"

Anda juga memiliki opsi untuk mengedit file konfigurasi kustom secara manual atau menggunakan patch .json yang mengubah kelas penyimpanan untuk kumpulan Penyimpanan, seperti dalam contoh berikut:

{
  "patch": [
    {
      "op": "replace",
      "path": "$.spec.resources.storage-0.spec",
      "value": {
        "type":"Storage",
        "replicas":2,
        "storage":{
            "data":{
                    "size": "100Gi",
                    "className": "myStorageClass",
                    "accessMode":"ReadWriteOnce"
                    },
            "logs":{
                    "size":"32Gi",
                    "className":"myStorageClass",
                    "accessMode":"ReadWriteOnce"
                    }
                }
            }
        }
    ]
}

Terapkan file patch. azdata bdc config patch Gunakan perintah untuk menerapkan perubahan dalam file patch .json. Contoh berikut menerapkan file ke patch.json file konfigurasi penyebaran target, custom.json:

azdata bdc config patch --config-file custom/bdc.json --patch-file ./patch.json

Langkah berikutnya