Saya menemukan bahwa ketika orang merancang arsitektur Oracle RAC, mereka sering tidak memikirkan redundansi N+1 dalam rencana implementasi mereka. Ada dua alasan untuk mengimplementasikan Oracle RAC, ketersediaan dan skalabilitas. Untuk keperluan diskusi ini, saya hanya berfokus pada sisi ketersediaan. Jika penerapan RAC Anda hanya untuk alasan skalabilitas, topik ini mungkin tidak berlaku untuk Anda.
Jadi apa itu Redundansi N+1? Sederhananya, jika Anda membutuhkan N unit sesuatu, maka untuk tujuan redundansi, Anda harus memiliki N+1 item itu. Mari kita lihat server database. Itu harus memiliki catu daya. Itu adalah persyaratan. Tanpa catu daya yang berfungsi, server tidak akan berfungsi sama sekali. Jumlah catu daya minimum adalah 1. Jika kami ingin server ini memiliki tingkat ketersediaan yang tinggi, kami akan memastikan bahwa ia memiliki catu daya N+1, atau dalam hal ini, catu daya ganda. Jika hanya ada satu catu daya dan gagal, dibutuhkan server bersamanya. Jika kita memiliki catu daya ekstra, unit cadangan, hilangnya satu catu daya tidak akan menurunkan server bersamanya. Redundansi adalah hal yang bagus untuk dimiliki dan merupakan komponen penting untuk infrastruktur ketersediaan tinggi.
Saat merancang sistem Oracle RAC, DBA perlu menentukan berapa banyak node yang diperlukan untuk mendukung permintaan pengguna akhir. Jika DBA menentukan 4 node diperlukan, dan cluster RAC ini harus menunjukkan sifat ketersediaan tinggi, maka penting bagi DBA untuk membuat cluster 5 node (4+1). Jika permintaan sumber daya cukup untuk membuat 4 node sibuk dan satu node hilang, 3 node lainnya tidak akan mampu mengimbangi beban kerja. Jika DBA membangun sistem RAC dengan mempertimbangkan kemampuan N+1, maka hilangnya satu node tidak akan terlihat oleh pengguna akhir. Jika DBA membangun cluster RAC tanpa redundansi N+1, maka hilangnya satu node mungkin sangat buruk bagi kinerja pengguna akhir, sehingga seluruh cluster mungkin juga down. Saat merancang implementasi RAC Anda, usahakan untuk redundansi N+1.
Saya ingat dua tahun lalu, saya memiliki cluster RAC yang kehilangan node. Tidak masalah, kami masih memiliki dua node yang tersedia. Saat saya melihat kinerja dua node yang tersisa, mereka tampak sangat kewalahan. Pusat panggilan kami mulai menerima keluhan. Saya bekerja dengan administrator lain di tim TI untuk membuat simpul itu kembali dan berjalan secepat mungkin, tetapi ini mungkin tidak selalu terjadi jika alasan pemadaman terkait perangkat keras dan suku cadang perlu diganti. Setelah node kembali beroperasi, saya memantau kinerja cluster selama berminggu-minggu kemudian. Penggunaan kami telah berkembang sejak sistem ini awalnya dirancang. Kami awalnya merancang sistem ini dengan mempertimbangkan redundansi N+1, tetapi penggunaan kami meningkat dan N berubah dari 2 menjadi 3. Cluster 3-node kami saat ini tidak lagi N+1 redundan. Jadi saya bekerja dengan manajemen untuk memasukkan dana yang cukup ke anggaran tahun depan untuk pengadaan node baru dan memastikan Oracle dilisensikan untuk itu. Saya tidur lebih nyenyak di malam hari mengetahui bahwa saya kembali ke redundansi N+1.
Seperti banyak implementasi di luar sana, sistem RAC saya bukan satu-satunya fitur Ketersediaan Tinggi yang ada dalam infrastruktur kami. Basis data RAC ini adalah basis data utama untuk basis data siaga fisik dengan Oracle's Data Guard. Saya terkejut ketika mendiskusikan database standby RAC dengan Oracle DBA lainnya, berapa banyak dari mereka yang tidak memikirkan kemampuan N+1 untuk standby mereka. Basis data siaga fisik adalah jaring pengaman saya jika pusat data utama tidak tersedia karena alasan tertentu. Saya telah melihat begitu banyak Oracle DBA yang mengimplementasikan satu instans siaga untuk primer RAC multi-node. Aduh! Saya harap mereka tidak pernah gagal. Seluruh beban kerja cluster RAC multi-node mereka akan berjuang mati-matian pada siaga instans tunggal itu. Jadi saat Anda mendesain implementasi RAC untuk primer dan standby, pertimbangkan implikasi redundansi N+1 Anda pada desain arsitektur.
Di mana saya mungkin berbeda dari banyak orang adalah bahwa implementasi siaga fisik saya tidak mampu N+1, melainkan N. Saya melewatkan simpul tambahan yang berlebihan untuk siaga fisik saya. Mengapa demikian? Murni dari perspektif biaya. Siaga fisik saya hanyalah jaring pengaman. Saya ingin itu bekerja untuk saya pada hari saya membutuhkannya. Tapi saya harap saya tidak pernah membutuhkannya. Siaga fisik adalah polis asuransi saya jika risiko menjadi kenyataan. Bagi saya, ekstra "+1" di situs siaga adalah asuransi yang berlebihan. Saya dapat menghemat perangkat keras fisik dan lisensi Oracle.
Jadi katakanlah saatnya tiba dan saya melakukan failover ke standby. Saya telah kehilangan redundansi N+1 saya. Tapi apa kemungkinan saya akan kehilangan data center utama *dan* kehilangan salah satu node di standby cluster saya? Peluang yang cukup tipis. Kemungkinan kegagalan di dua situs pada saat yang sama cukup kecil. Pada titik ini, tim TI kami sedang mengevaluasi mengapa pusat data utama kami hilang dan kapan kami kemungkinan besar dapat mengembalikan operasi kami ke fasilitas itu. Jika pusat data primer kehilangan semua dayanya dan perusahaan utilitas mengatakan layanan akan dipulihkan besok, maka kami hanya akan menjalankannya di pusat data siaga meskipun kami hanya memiliki N node untuk database RAC di sana. Namun, jika pusat data utama dimusnahkan oleh kebakaran, akan membutuhkan waktu berbulan-bulan sebelum pusat data tersebut aktif dan berjalan kembali. Pada titik inilah saya perlu merencanakan untuk mendapatkan siaga fisik itu hingga redundansi N+1 karena waktu kita menggunakan siaga itu sebagai yang utama akan menjadi periode yang jauh lebih lama. Jadi kami buru-buru memesan server lain dan menambahkannya ke cluster sesegera mungkin. Jadi saya mendesain database RAC standby saya sebagai N, bukan N+1 dengan tujuan untuk meningkatkannya menjadi N+1 dalam waktu singkat jika kami memutuskan bahwa kami akan menggunakan standby secara nyata untuk jangka waktu yang lebih lama.
Jadi ada satu kasus khusus lainnya yang ingin saya diskusikan. Di situlah DBA menentukan bahwa N=1. Untuk kebutuhan beban kerja saat ini, satu node sudah cukup. Tetapi kami ingin memiliki ketersediaan tinggi, jadi kami merancang cluster RAC dua node untuk database utama. Kami sekarang memiliki N+1 redundansi yang dibangun ke dalam primer. Mengikuti paragraf terakhir saya, database standby saya hanya membutuhkan 1 node. Kesalahan yang saya lihat dilakukan beberapa orang adalah membuat standby sebagai database instance tunggal. Sejauh ini, logika mereka masuk akal. Yang utama adalah N+1 dan siaga adalah N. Sejauh ini bagus. Di mana saya berbeda adalah bahwa saya menjadikan standby sebagai cluster RAC satu node, bukan implementasi instance tunggal murni. Alasannya adalah untuk pertumbuhan di masa depan. Pada titik tertentu, DBA mungkin menemukan bahwa N tidak lagi sama dengan 1 di primer. Penggunaan telah berkembang dan N perlu menjadi 2 sekarang. DBA ingin menumbuhkan primer menjadi 3 node (2+1). Ini dengan mudah turun tanpa downtime untuk menambahkan node baru ke cluster dan memperluas database RAC ke node baru itu. Tapi itu tidak begitu mudah dilakukan di standby untuk membuat standby cluster 2-node jika 1 node yang ada tidak diaktifkan RAC. Jika hanya ada satu instance standby murni, DBA perlu menghapusnya dan memindahkannya ke cluster dua node. Jika DBA memiliki pandangan ke depan dan menginstal Infrastruktur Grid seolah-olah fisik standby adalah cluster node tunggal, maka yang harus dilakukan DBA adalah menambahkan node baru, seperti yang mereka lakukan di sisi utama.
Saat Anda merancang implementasi RAC Anda, pertimbangkan untuk memastikan Anda memiliki kemampuan N+1 di primer dan setidaknya N di standby. Jika sebuah perusahaan menentukan bahwa standby terlalu kritis, mereka mungkin ingin menerapkan N+1 pada standby juga. Jika DBA menentukan bahwa N=1, pertimbangkan untuk membuat standby setidaknya satu node RAC cluster.
