Merencanakan dan meluncurkan ketersediaan tinggi dan rencana pemulihan bencana yang memenuhi semua perjanjian tingkat layanan adalah pekerjaan yang tidak sepele dan memerlukan pemahaman yang sangat jelas tentang kekuatan dan kelemahan asli SQL Server. Saat mencocokkan persyaratan dengan kombinasi fitur, beberapa detail penting mungkin diabaikan, dan dalam posting ini saya akan membahas beberapa distorsi umum dan asumsi buruk yang dapat menyusup ke dalam solusi – yang pada akhirnya menyebabkan kita kehilangan sasaran pada titik pemulihan dan tujuan waktu pemulihan kami. Beberapa contoh distorsi atau delusi diri yang saya jelaskan di sini dapat digeneralisasikan di berbagai fitur dan beberapa di antaranya khusus fitur.
"Kami menguji rencana pemulihan bencana kami saat pertama kali meluncurkan proyek kami dan kami tahu itu akan berhasil"
Saya telah bekerja dengan klien yang memang mendapatkan pendekatan pemulihan bencana mereka “benar” – satu kali. Tetapi begitu semua orang merasa yakin dengan kemanjuran solusi tersebut, tidak ada latihan pemulihan bencana lainnya yang dilakukan lagi. Tentu saja – sementara itu tingkat data dan aplikasi terus berubah seiring waktu. Perubahan tersebut memperkenalkan objek dan proses baru yang penting untuk aplikasi. Dan bahkan jika semuanya tetap statis setelah peluncuran, Anda masih harus memperhitungkan pergantian personel dan berbagai keahlian. Bisakah staf hari ini berhasil melakukan latihan pemulihan bencana? Dan bahkan staf terbaik pun membutuhkan latihan terus-menerus.
"Kami tidak akan kehilangan data karena kami menggunakan pencerminan database sinkron"
Katakanlah Anda menggunakan pencerminan database sinkron antara dua instance SQL Server, dengan setiap instance di pusat data terpisah. Dalam contoh ini, asumsikan bahwa latensi transaksi dapat diterima meskipun ini merupakan sesi pencerminan database sinkron dengan beberapa mil di antara pusat data. Anda tidak memiliki saksi dalam campuran karena Anda ingin mengontrol failover mirror database secara manual.
Sekarang katakanlah pusat data pemulihan bencana Anda hilang – tetapi pusat data utama Anda masih tersedia. Database utama Anda terputus dari database cermin, tetapi masih menerima koneksi dan modifikasi data. Bagaimana dengan persyaratan "tidak ada kehilangan data" sekarang? Jika transaksi berjalan melawan prinsipal yang terputus selama satu jam lagi, apa rencana Anda jika pusat data utama juga hilang?
"Pemilik bisnis kami mengatakan bahwa kami dapat kehilangan data hingga 12 jam"
Adalah penting untuk mengajukan beberapa pertanyaan lebih dari sekali dan kepada lebih dari satu individu dalam suatu organisasi. Jika seseorang memberi tahu Anda bahwa “12 jam kehilangan data dapat diterima” – tanyakan lagi, atau tanyakan apa konsekuensi dari kehilangan data tersebut. Tanya orang lain juga. Mereka mungkin memberi Anda persyaratan yang jauh lebih ketat. Saya menemukan bahwa tujuan titik pemulihan memerlukan beberapa negosiasi dan lebih dari beberapa diskusi yang bijaksana dan disengaja.
"Kami menggunakan [pencerminan basis data atau grup ketersediaan] sehingga kami dapat memenuhi kebutuhan kami jika terjadi bencana"
Pencerminan basis data dan grup ketersediaan tentu dapat digunakan untuk melindungi Anda di tingkat basis data, tetapi bagaimana dengan yang lainnya? Bagaimana dengan login Anda? Paket SSIS? Pekerjaan? Basis data model pemulihan yang tidak LENGKAP? Server tertaut?
"Kami menggunakan fitur SQL Server XYZ, jadi kami tidak akan kehilangan transaksi dalam penerbangan"
Tidak maaf. Meskipun beberapa fitur memungkinkan pengalihan transparan, ini tidak sama dengan mempertahankan dan mempertahankan transaksi terbuka pada saat failover. Tidak ada fitur SQL Server yang menyediakan fungsionalitas ini hari ini.
"Tim yang mendukung tingkat data untuk aplikasi ini membenci fitur SQL Server XYZ, tetapi kami terus melakukannya karena itulah yang direkomendasikan kepada kami oleh konsultan luar"
Meskipun akan lebih baik jika orang tidak mengembangkan bias spesifik seputar fitur di SQL Server, hal ini sering tidak terjadi. Jika Anda mencoba memaksakan solusi pada staf yang tidak setuju dengan mereka, Anda menghadapi risiko kegagalan yang telah ditentukan sebelumnya. Sebagai bagian dari latihan HA/DR yang telah saya bantu di masa lalu, saya selalu tertarik untuk mendengar tentang pengalaman masa lalu orang-orang dengan fitur tertentu. Misalnya, beberapa perusahaan memanfaatkan ratusan Instans Failover Cluster dengan sangat baik – sementara yang lain menghindarinya karena pengalaman buruk dari versi sebelumnya. Saat merencanakan solusi, Anda tidak dapat mengabaikan riwayat atau kecenderungan staf yang pada akhirnya akan bertanggung jawab untuk menerapkan dan mendukung solusi yang direkomendasikan.
"Sebagai DBA, saya memutuskan teknologi HA/DR mana yang akan digunakan untuk tingkat data, jadi selanjutnya kami akan menggunakan grup ketersediaan"
Seorang administrator database berpotensi mengatur mirroring database dengan sedikit atau tanpa keterlibatan dengan tim lain. Sekarang dengan grup ketersediaan, bahkan jika administrator database dapat melakukan semuanya sendiri, mereka mungkin tidak bijaksana untuk melakukannya. Lagi pula – jika Anda menggunakan grup ketersediaan untuk tujuan pemulihan bencana, Anda ingin semua orang yang terlibat dalam operasi pemulihan bencana mengetahui solusi Anda dan persyaratan yang diperlukan untuk berhasil kembali online dan memulihkan data. Dengan grup ketersediaan, Anda harus memikirkan Cluster Failover Server Windows, konfigurasi kuorum, pemilihan node, pendengar grup ketersediaan, dan banyak lagi. Jika Anda membutuhkan orang lain untuk memfasilitasi solusi, pastikan mereka terlibat dengan rekomendasi awal.
"Kami menggunakan grup ketersediaan sehingga kami dapat memiliki ketersediaan hanya-baca jika terjadi gangguan pada replika baca-tulis kami"
Ini hanyalah salah satu contoh skenario "bagaimana jika". Dengan implementasi fungsionalitas apa pun, Anda pasti ingin membayangkan berbagai cara kegagalan dapat terjadi – dan kemudian pastikan untuk mengujinya untuk memastikan persyaratan Anda masih terpenuhi. Misalnya – jika Anda berpikir bahwa replika baca-saja asinkron grup ketersediaan SQL Server 2012 Anda akan tersedia saat replika baca-tulis tidak tersedia, Anda akan terkejut melihat Unable to access database 'XYZ' because its replica role is RESOLVING which does not allow connections pesan dalam produksi.
"Kami menguji fitur SQL Server XYZ, dan failover cepat, jadi kami telah menetapkan bahwa kami dapat memenuhi tujuan waktu pemulihan kami dengan mudah"
Katakanlah Anda memutuskan untuk menggunakan pencerminan basis data untuk ketersediaan tingkat basis data pengguna yang tinggi. Anda ingin failover cepat (diukur dalam detik), dan Anda memang melihat failover cepat selama pengujian. Tapi apakah itu ujian yang realistis? Apakah Anda mendorong beban kerja yang signifikan? Dalam contoh pencerminan basis data, bagian terpanjang dari operasi failover Anda bisa untuk operasi redo. Jika Anda tidak mendorong beban kerja yang realistis, maka Anda tidak dapat benar-benar mengatakan bahwa failover Anda sebenarnya akan "cepat".
"Jika kami mengalami bencana dan perlu menyelamatkan dan merekonsiliasi data, kami akan mencari tahu ketika saatnya tiba"
Ini adalah hal yang sulit. Katakanlah Anda mengalami bencana dan perlu membuat pusat data sekunder Anda beroperasi. Anda memutuskan untuk memaksa layanan untuk database paling penting di pusat data sekunder dan sekarang Anda memiliki pemisahan dalam garis keturunan modifikasi data (beberapa baris yang tidak direkonsiliasi di pusat data primer, dan sekarang modifikasi baru di pusat data sekunder). Akhirnya pusat data utama Anda dibawa online – tetapi sekarang Anda memiliki data yang perlu diselamatkan dan direkonsiliasi sebelum Anda dapat membangun kembali solusi HA/DR secara keseluruhan. Apa pekerjaanmu? Apa yang bisa kau lakukan? Diskusi ini jarang dilakukan dan mungkin bergantung pada beberapa faktor seperti paket perangkat lunak yang Anda beli, kompleksitas tingkat data, dan alat konvergensi data yang Anda inginkan. Bahkan, diskusi biasanya sangat sulit sehingga orang tidak memilikinya sama sekali. Tetapi jika data cukup penting bagi Anda untuk mendirikan pusat data sekunder, maka bagian penting dari diskusi harus mencakup cara terbaik untuk menyelamatkan data dan juga merekonsiliasinya setelah bencana terjadi.
Ringkasan
Artikel ini hanya menyertakan beberapa contoh bagaimana kita dapat menipu diri kita sendiri dengan berpikir bahwa sebuah solusi sepenuhnya memenuhi persyaratan mereka. Meskipun sudah menjadi sifat manusia untuk melakukan hal ini – dalam hal kehilangan data dan kelangsungan bisnis, pekerjaan kita akan bergantung pada kita untuk lebih agresif dalam menguji keyakinan dan asumsi kita sendiri.
