[Sumber] Ketersediaan Tinggi di SQL Server (1) ---- gambaran umum ketersediaan tinggi

Sejak SQL Server 2005, Microsoft telah menyediakan berbagai teknologi ketersediaan tinggi untuk mengurangi waktu henti dan meningkatkan perlindungan data bisnis, dan dengan rilis berkelanjutan SQL Server 2008, SQL Server 2008 R2, dan SQL Server 2012, ada banyak teknologi ketersediaan tinggi di SQL Server untuk memenuhi skenario yang berbeda.

    Sebelum saya memulai artikel ini, saya akan mulai dengan ikhtisar singkat tentang apa yang menentukan teknologi ketersediaan tinggi mana yang akan digunakan.

    Banyak perusahaan membutuhkan semua atau sebagian data mereka agar sangat tersedia, seperti situs web belanja online, database produk online harus online 24/7, jika tidak, dalam lingkungan pasar yang sangat kompetitif, waktu henti berarti kehilangan pelanggan dan pendapatan. Misalnya, di pusat panggilan yang mengandalkan SQL Server, jika database mati, semua penelepon hanya dapat duduk di sana dan membalas pelanggan "Maaf, kegagalan sistem", yang juga tidak dapat diterima.

    Tentu saja, di dunia yang ideal, semua data penting akan online setiap saat, tetapi di dunia nyata, akan ada berbagai alasan database tidak tersedia, karena tidak mungkin untuk memprediksi waktu dan bentuk bencana, perlu untuk mengambil tindakan terlebih dahulu untuk mencegah berbagai keadaan darurat, sehingga SQL Server menyediakan berbagai teknologi ketersediaan tinggi, teknologi ini terutama meliputi: pengelompokan, replikasi, pencerminan, pengiriman log, grup ketersediaan AlwaysOn dan lainnya seperti pencadangan dan pemulihan grup file, Teknologi ketersediaan tinggi instans tunggal seperti indeks pembangunan kembali online. Penggunaan teknologi ketersediaan tinggi bukan untuk memilih teknologi yang sudah dikenal untuk penggunaan langsung, tetapi untuk mempertimbangkan bisnis dan teknologi secara komprehensif. Karena tidak ada teknologi tunggal yang dapat mencapai semua fungsi. Cara mengadopsi teknologi ini berdasarkan bisnis dan anggaran spesifik Anda adalah apa yang dikenal sebagai strategi ketersediaan tinggi.

Saat merancang strategi ketersediaan tinggi, Anda harus terlebih dahulu mempertimbangkan faktor-faktor berikut:

• RTO (Tujuan Waktu Pemulihan) - yaitu, tujuan waktu pemulihan, berarti berapa banyak waktu henti yang diizinkan, biasanya dinyatakan dengan beberapa 9 detik, misalnya, ketersediaan 99,999% berarti tidak lebih dari 5 menit waktu henti per tahun, ketersediaan 99,99% berarti tidak lebih dari 52,5 menit waktu henti per tahun, dan ketersediaan 99,9% berarti tidak lebih dari 8,75 jam waktu henti per tahun. Perlu dicatat bahwa metode perhitungan RTO memperhitungkan apakah sistemnya 24*365 atau hanya pukul 6 pagi hingga 9 malam, dll. Anda juga perlu memperhatikan apakah jendela pemeliharaan dihitung sebagai waktu henti, dan lebih mudah untuk mencapai ketersediaan yang lebih tinggi jika pemeliharaan dan patching database diizinkan selama jendela pemeliharaan.
• RPO (Tujuan Titik Pemulihan) – Juga dikenal sebagai tujuan titik pemulihan, berarti berapa banyak kehilangan data yang diizinkan. Biasanya, selama Anda membuat cadangan yang baik, Anda dapat dengan mudah mencapai nol kehilangan data. Tetapi ketika bencana terjadi, tergantung pada tingkat kerusakan database, waktu yang diperlukan untuk memulihkan data dari cadangan akan menyebabkan database menjadi tidak tersedia, yang akan memengaruhi implementasi RTO. Contoh awal dan lebih terkenal adalah sistem perbankan di Eropa dan Amerika Serikat, hanya mempertimbangkan RPO, hanya ada pencadangan penuh dan pencadangan log dalam sistem, pencadangan penuh setiap 3 bulan, pencadangan log setiap 15 menit, ketika terjadi bencana, hanya melalui pencadangan penuh dan pencadangan log yang dapat memulihkan data, jadi meskipun tidak ada kehilangan data, tetapi karena butuh dua hari penuh untuk memulihkan data, sistem perbankan tidak tersedia selama 2 hari, sehingga sejumlah besar nasabah hilang. Contoh berlawanan lainnya adalah situs web video online domestik, menggunakan SQL Server sebagai database relasional back-end, front-end menggunakan No-SQL, dan secara teratur mengimpor data No-SQL ke dalam database relasional sebagai cadangan.
  

    Anggaran – RTO dan RPO secara kolektif dikenal sebagai SLA (Perjanjian Tingkat Layanan), dan saat merancang strategi ketersediaan tinggi, Anda perlu mengukur seberapa baik Anda memenuhi SLA berdasarkan bisnis Anda, tergantung pada anggaran Anda dan mengukur biaya SLA yang berbeda jika terjadi kegagalan. Secara umum, sulit untuk mencapai SLA tinggi dengan anggaran terbatas, dan bahkan jika SLA yang tinggi dicapai melalui arsitektur yang kompleks, arsitektur yang kompleks juga berarti biaya operasi dan pemeliharaan yang tinggi, sehingga perlu untuk memilih teknologi yang tepat dalam anggaran untuk memenuhi SLA.

Oleh karena itu, secara umum, kerangka kerja besar untuk ketersediaan tinggi dapat ditentukan oleh beberapa pertanyaan pengambilan pesanan:

• Apa waktu henti yang bersedia diterima oleh pemegang saham?
• Waktu henti apa yang dapat diterima oleh manajer?
• Berapa anggaran yang disediakan untuk skenario ketersediaan tinggi?
• Berapa kerugian per jam karena downtime?
  

• Pencadangan dingin: Server siaga dikonfigurasi untuk menerima data server utama, dan ketika gagal, pulihkan data secara manual ke database utama, atau konfigurasikan ulang string koneksi atau izin program untuk menghadirkan database cadangan secara online.
• Pencadangan hangat: Data server utama akan terus menerus mengirimkan log ke server cadangan (pada interval yang tidak teratur, bisa 15 menit, 30 menit, 1 menit, dll.), Dengan cara ini, server utama ke server cadangan biasanya diperbarui secara asinkron, sehingga data server utama dan server cadangan tidak dapat dijamin. Selain itu, skema ini biasanya tidak menerapkan pemantauan kesalahan otomatis dan failover.
• Pencadangan panas: Data server utama secara otomatis disinkronkan di server cadangan, dan dalam banyak kasus, pemantauan kesalahan otomatis dan failover disertakan, dan konsistensi data server utama dan server cadangan dapat dijamin.
  

    Karena cadangan dingin hingga hangat hingga panas, biaya meroket.

    Fitur ketersediaan tinggi yang didukung di SQL Server terkait erat dengan versi, dan edisi Enterprise mendukung semua fitur ketersediaan tinggi, termasuk:

• Kluster failover
• l Gambar basis data
• l Transmisi log transaksi
• l Rekam jepret database
• l Peningkatan ketersediaan tinggi
• l Memori beban panas
• l Operasi pengindeksan online
• l Database parsial online (hanya grup file master atau grup file master dan file NDF tambahan yang dipulihkan)
  

    Untuk versi tertentu yang memiliki fitur ketersediaan tinggi, lihat:http://msdn.microsoft.com/zh-cn/library/cc645993.aspxPerlu dicatat bahwa versi Express gratis dapat berfungsi sebagai server saksi untuk pencerminan basis data, menghasilkan penghematan biaya.

Kluster failover

    Kluster failover menyediakan dukungan ketersediaan tinggi untuk seluruh instans SQL Server, yang berarti bahwa instans SQL Server pada simpul pada kluster melakukan failover ke simpul lain pada kluster karena kesalahan perangkat keras, kesalahan sistem operasi, dll. Ketersediaan tinggi dicapai oleh beberapa server (node) yang berbagi satu atau beberapa disk, dan kluster failover muncul di jaringan dengan cara yang sama seperti satu komputer, tetapi dengan karakteristik ketersediaan tinggi. Penting untuk dicatat bahwa karena kluster failover didasarkan pada disk bersama, ada satu titik kegagalan disk, sehingga perlindungan tambahan seperti replikasi SAN perlu disebarkan di tingkat disk. Kluster failover yang paling umum adalah kluster failover dua simpul, termasuk master dan slave.

Transmisi log transaksi

    Pengiriman log transaksi memberikan perlindungan ketersediaan tinggi tingkat database. Pengelogan digunakan untuk memelihara satu atau beberapa database siaga (disebut "database sekunder") dari database produksi yang sesuai (disebut "database utama"). Sebelum failover terjadi, database sekunder harus diperbarui sepenuhnya dengan menerapkan semua cadangan log yang belum dipulihkan secara manual. Pengiriman log memiliki fleksibilitas untuk mendukung beberapa database siaga. Jika beberapa database alternatif diperlukan, pengiriman log dapat digunakan secara terpisah atau sebagai pelengkap pencerminan database. Ketika solusi ini digunakan bersama-sama, database utama dari konfigurasi pencerminan database saat ini juga merupakan database utama dari konfigurasi pengiriman log saat ini.

    Pengiriman log transaksi dapat digunakan untuk melakukan pencadangan dingin dan hangat.

Pencerminan basis data

    Pencerminan basis data sebenarnya adalah solusi perangkat lunak yang juga memberikan perlindungan tingkat basis data, menyediakan failover yang hampir seketika untuk meningkatkan ketersediaan basis data. Cermin database dapat digunakan untuk memelihara database siaga tunggal (atau "database cermin") untuk database produksi yang sesuai (disebut "database utama").
Karena database cermin selalu dalam status pemulihan, tetapi database tidak dipulihkan, database cermin tidak dapat diakses secara langsung. Namun, untuk pemuatan baca-saja seperti laporan, Anda dapat menggunakan database yang dicerminkan secara tidak langsung dengan membuat rekam jepret database dari database yang dicerminkan. Rekam jepret database memberi klien akses baca-saja ke data dalam database saat rekam jepret dibuat. Setiap konfigurasi pencerminan database melibatkan "server utama" yang berisi database utama, dan juga melibatkan server cermin yang berisi database cermin. Server cermin terus memperbarui database cermin dengan database utama.
    Pencerminan database berjalan dalam operasi sinkron dalam mode keamanan tinggi atau operasi asinkron dalam mode performa tinggi. Dalam mode performa tinggi, transaksi tidak perlu menunggu server cermin menulis log ke disk sebelum dapat dikirimkan, yang memaksimalkan performa. Dalam mode keamanan tinggi, transaksi yang dilakukan dilakukan oleh kedua mitra, tetapi waktu jeda transaksi diperpanjang. Konfigurasi pencerminan database yang paling sederhana hanya melibatkan server utama dan server cermin. Dalam konfigurasi ini, jika server utama hilang, server cermin dapat digunakan sebagai server siaga, tetapi dapat menyebabkan kehilangan data. Mode keamanan tinggi mendukung konfigurasi siaga, mode keamanan tinggi dengan failover otomatis. Konfigurasi ini melibatkan instans server pihak ketiga yang disebut "server saksi" yang memungkinkan server cermin digunakan sebagai server cadangan panas. Failover dari database utama ke database cermin biasanya memakan waktu beberapa detik.

    Pencerminan database dapat digunakan untuk pencadangan hangat dan panas.

menyalin

    Replikasi tidak sepenuhnya merupakan fitur yang dirancang untuk ketersediaan tinggi, tetapi dapat diterapkan pada ketersediaan tinggi. Replikasi menyediakan perlindungan tingkat objek database. Replikasi menggunakan model publikasi-langganan, di mana data diterbitkan oleh server utama, yang dikenal sebagai penerbit, ke satu atau beberapa pelanggan sekunder. Replikasi menyediakan ketersediaan dan skalabilitas real-time antara server ini. Ini mendukung pemfilteran untuk menyediakan subset data kepada pelanggan, sekaligus mendukung pembaruan partisi. Pelanggan online dan tersedia untuk pelaporan atau fungsi lain tanpa pemulihan kueri. SQL Server menawarkan empat jenis replikasi: replikasi rekam jepret, replikasi transaksional, replikasi peer-to-peer, dan replikasi gabungan.

Selalu AktifGrup kegunaan

    Grup Ketersediaan AlwaysOn adalah fitur baru yang diperkenalkan di SQL Server 2012. Perlindungan tingkat database juga disediakan. Ini juga memperluas batas bahwa pencerminan database hanya dapat 1:1, sehingga satu replika utama dapat sesuai dengan hingga 4 replika sekunder (di SQL Server 2014, batas ini diperluas menjadi 8), di mana 2 replika sekunder dapat disinkronkan sebagai cadangan panas dan replika utama secara real time, dan dua replika sekunder asinkron lainnya dapat digunakan sebagai cadangan hangat. Selain itu, replika sekunder dapat dikonfigurasi sebagai baca-saja dan dapat digunakan untuk mengambil beban cadangan.

    Karena itu, pencerminan database ditandai sebagai "usang" di SQL Server 2012.

    Setelah memahami konsep dasar ketersediaan tinggi dan teknologi ketersediaan tinggi yang disediakan di SQL Server, mari kita lihat desain strategi ketersediaan tinggi. Merencanakan strategi ketersediaan tinggi dapat dibagi menjadi empat fase:

Mengumpulkan persyaratan

    Langkah pertama dalam memutuskan strategi ketersediaan tinggi tidak diragukan lagi adalah mengumpulkan persyaratan bisnis untuk menetapkan SLA. RTO dan RPO adalah bagian yang paling penting, dan atas dasar ini, tetapkan ekspektasi yang realistis untuk persyaratan ketersediaan dan tetapkan strategi ketersediaan tinggi yang realistis berdasarkan harapan ini.

Batas Penilaian

    Batas penilaian tidak hanya terbatas pada batasan berbagai teknologi ketersediaan tinggi di SQL Server, tetapi juga pada yang non-teknis. Jika Anda hanya memiliki anggaran puluhan ribu yuan, tetapi Anda ingin melakukan solusi ketersediaan tinggi berdasarkan pusat data di luar lokasi dan replikasi SAN, tidak diragukan lagi itu adalah impian bodoh. Keterbatasan non-teknis lainnya adalah tingkat personel operasional, dan seringkali, arsitektur yang kompleks berarti personel operasi yang lebih terampil. Keterbatasan non-teknis lainnya termasuk ketersediaan ruang disk di pusat data, apakah catu daya dan AC dapat memenuhi kebutuhan, dan waktu yang diperlukan untuk menerapkan strategi ketersediaan.

    Keterbatasan teknis mencakup fungsi dan batasan ketersediaan tinggi yang berbeda, fungsi yang didukung oleh versi SQL Server yang berbeda, jumlah CPU, dan ukuran memori. Sangat disarankan agar Anda terlebih dahulu merujuk ke batasan versi dan fitur SQL Server yang berbeda di situs web Microsoft MSDN sebelum menerapkan kebijakan ketersediaan tinggi.

Pilih teknologi

    Setelah mengumpulkan persyaratan dan menilai kendala, langkah selanjutnya adalah memilih teknologi atau kombinasi teknologi yang dijelaskan sebelumnya dalam artikel ini untuk memenuhi persyaratan SLA. Jika teknologi yang dipilih gagal memenuhi SLA, mudah untuk melaporkan batasan apa yang tidak memenuhi SLA, memungkinkan Anda meminta sumber daya yang hilang atau berkompromi pada SLA.

Uji, validasi, dan dokumentasikan

    Kebijakan ketersediaan tinggi perlu diuji dan divalidasi secara ketat sejak awal untuk memastikan bahwa kebijakan ketersediaan saat ini memenuhi SLA. Namun, ketika strategi ketersediaan tinggi diluncurkan, perlu juga untuk menguji dan memvalidasinya secara teratur untuk memastikan bahwa kebijakan saat ini masih dapat memenuhi SLA meskipun ada perubahan data yang berkembang, bisnis, atau persyaratan. Pada saat yang sama, konfigurasi solusi ketersediaan, metode failover, dan rencana pemulihan bencana harus didokumentasikan pada saat yang sama sehingga dapat dilacak jika terjadi kegagalan atau penyesuaian strategi ketersediaan tinggi di masa mendatang.

Artikel ini menjelaskan konsep dasar ketersediaan tinggi, konsep SLA, berbagai jenis fitur ketersediaan tinggi yang didukung di SQL Server, dan langkah-langkah yang diperlukan untuk merancang strategi ketersediaan tinggi. Perlu dicatat bahwa meskipun artikel ini hanya berbicara tentang ketersediaan tinggi di tingkat database, ketersediaan tinggi tidak hanya masalah DBA, tetapi juga mencakup kolaborasi berbagai peran seperti personel operasi dan pemeliharaan sistem, administrator jaringan, pengembang, dan manajer untuk memenuhi SLA dengan lebih baik.