Halo, pembaca Habr! Pada artikel terakhir, kita berbicara tentang cara sederhana pemulihan bencana dalam sistem penyimpanan AERODISK ENGINE - replikasi. Pada artikel ini, kita akan mendalami topik yang lebih kompleks dan menarik - metrocluster, yaitu sarana perlindungan bencana otomatis untuk dua pusat data, yang memungkinkan pusat data beroperasi dalam mode aktif-aktif. Kami akan memberitahu Anda, menunjukkannya, memecahkannya dan memperbaikinya.
Seperti biasa, teori dulu
Metrocluster adalah cluster yang tersebar di beberapa lokasi dalam suatu kota atau wilayah. Kata "cluster" dengan jelas mengisyaratkan kepada kita bahwa kompleks tersebut bersifat otomatis, yaitu peralihan node cluster jika terjadi kegagalan terjadi secara otomatis.
Di sinilah letak perbedaan utama antara metrocluster dan replikasi reguler. Otomatisasi operasi. Artinya, jika terjadi insiden tertentu (kegagalan pusat data, saluran rusak, dll.), sistem penyimpanan akan secara mandiri melakukan tindakan yang diperlukan untuk menjaga ketersediaan data. Saat menggunakan replika biasa, tindakan ini dilakukan seluruhnya atau sebagian secara manual oleh administrator.
Apa fungsinya?
Tujuan utama yang dikejar pelanggan saat menggunakan implementasi metrocluster tertentu adalah meminimalkan RTO (Recovery Time Objective). Artinya, untuk meminimalkan waktu pemulihan layanan TI setelah terjadi kegagalan. Jika Anda menggunakan replikasi reguler, waktu pemulihan akan selalu lebih lama dibandingkan waktu pemulihan dengan metrocluster. Mengapa? Sangat sederhana. Administrator harus berada di mejanya dan mengalihkan replikasi secara manual, dan metrocluster melakukannya secara otomatis.
Jika Anda tidak memiliki administrator khusus yang bertugas yang tidak tidur, tidak makan, tidak merokok atau sakit, dan mengawasi keadaan sistem penyimpanan 24 jam sehari, maka tidak ada cara untuk menjamin bahwa administrator akan melakukannya. tersedia untuk peralihan manual jika terjadi kegagalan.
Oleh karena itu, RTO dengan tidak adanya metrocluster atau admin abadi dari layanan tugas administrator tingkat 99 akan sama dengan jumlah waktu peralihan semua sistem dan periode waktu maksimum setelah administrator dijamin untuk mulai bekerja dengan sistem penyimpanan dan sistem terkait.
Oleh karena itu, kami sampai pada kesimpulan yang jelas bahwa metrocluster harus digunakan jika persyaratan RTO adalah menit, bukan jam atau hari. Artinya, ketika terjadi kegagalan pusat data terburuk, departemen TI harus menyediakan waktu bagi bisnis. untuk memulihkan akses ke layanan TI dalam hitungan menit, atau bahkan detik.
Bagaimana cara kerjanya?
Di tingkat bawah, metrocluster menggunakan mekanisme replikasi data sinkron, yang telah kami jelaskan di artikel sebelumnya (lihat. ). Karena replikasi bersifat sinkron, persyaratannya sesuai, atau lebih tepatnya:
- serat optik sebagai fisika, 10 gigabit Ethernet (atau lebih tinggi);
- jarak antar pusat data tidak lebih dari 40 kilometer;
- penundaan saluran optik antar pusat data (antar sistem penyimpanan) hingga 5 milidetik (optimal 2).
Semua persyaratan ini bersifat nasihat, yaitu metrocluster akan tetap berfungsi meskipun persyaratan ini tidak dipenuhi, namun kita harus memahami bahwa konsekuensi dari ketidakpatuhan terhadap persyaratan ini sama dengan perlambatan pengoperasian kedua sistem penyimpanan di metrokluster tersebut.
Jadi, replika sinkron digunakan untuk mentransfer data antar sistem penyimpanan, dan bagaimana replika beralih secara otomatis dan, yang paling penting, bagaimana menghindari perpecahan otak? Untuk melakukan ini, di tingkat yang lebih tinggi, entitas tambahan digunakan - seorang arbiter.
Bagaimana cara kerja seorang arbiter dan apa tugasnya?
Arbiter adalah mesin virtual kecil atau cluster perangkat keras yang harus diluncurkan di situs ketiga (misalnya, di kantor) dan menyediakan akses ke sistem penyimpanan melalui ICMP dan SSH. Setelah peluncuran, arbiter harus mengatur IP, dan kemudian dari sisi penyimpanan menunjukkan alamatnya, ditambah alamat pengontrol jarak jauh yang berpartisipasi dalam metrocluster. Setelah itu, wasit siap bekerja.
Arbiter terus-menerus memonitor semua sistem penyimpanan di metrocluster dan jika sistem penyimpanan tertentu tidak tersedia, setelah mengkonfirmasi ketidaktersediaan dari anggota cluster lain (salah satu sistem penyimpanan "langsung"), ia memutuskan untuk meluncurkan prosedur peralihan aturan replikasi dan pemetaan.
Poin yang sangat penting. Arbiter harus selalu berlokasi di lokasi yang berbeda dari tempat sistem penyimpanan berada, yaitu, baik di pusat data 1, tempat sistem penyimpanan 1 dipasang, maupun di pusat data 2, tempat sistem penyimpanan 2 dipasang.
Mengapa? Karena ini adalah satu-satunya cara seorang arbiter, dengan bantuan salah satu sistem penyimpanan yang masih ada, dapat dengan jelas dan akurat menentukan jatuhnya salah satu dari dua lokasi tempat sistem penyimpanan dipasang. Metode penempatan wasit lainnya dapat mengakibatkan otak terbelah.
Sekarang mari selami detail pekerjaan arbiter.
Arbiter menjalankan beberapa layanan yang terus-menerus melakukan polling terhadap semua pengontrol penyimpanan. Jika hasil polling berbeda dengan hasil sebelumnya (tersedia/tidak tersedia), maka dicatat dalam database kecil, yang juga berfungsi pada arbiter.
Mari kita lihat logika kerja arbiter lebih detail.
Langkah 1: Tentukan ketidaktersediaan. Peristiwa kegagalan sistem penyimpanan adalah tidak adanya ping dari kedua pengontrol sistem penyimpanan yang sama dalam waktu 5 detik.
Langkah 2. Mulai prosedur peralihan. Setelah arbiter menyadari bahwa salah satu sistem penyimpanan tidak tersedia, ia mengirimkan permintaan ke sistem penyimpanan “hidup” untuk memastikan bahwa sistem penyimpanan “mati” tersebut benar-benar mati.
Setelah menerima perintah seperti itu dari wasit, sistem penyimpanan kedua (langsung) juga memeriksa ketersediaan sistem penyimpanan pertama yang jatuh dan, jika tidak ada, mengirimkan konfirmasi tebakannya kepada wasit. Sistem penyimpanan memang tidak tersedia.
Setelah menerima konfirmasi tersebut, arbiter meluncurkan prosedur jarak jauh untuk mengalihkan replikasi dan meningkatkan pemetaan pada replika yang aktif (primer) pada sistem penyimpanan yang rusak, dan mengirimkan perintah ke sistem penyimpanan kedua untuk mengubah replika ini dari sekunder ke primer dan meningkatkan pemetaan. Oleh karena itu, sistem penyimpanan kedua melakukan prosedur ini, dan kemudian menyediakan akses ke LUN yang hilang dari dirinya sendiri.
Mengapa diperlukan verifikasi tambahan? Untuk kuorum. Artinya, mayoritas dari jumlah ganjil (3) anggota cluster harus mengkonfirmasi jatuhnya salah satu node cluster. Hanya dengan demikian keputusan ini akan benar-benar tepat. Hal ini diperlukan untuk menghindari peralihan yang salah dan, karenanya, perpecahan otak.
Langkah waktu 2 memakan waktu sekitar 5 - 10 detik, dengan demikian, dengan mempertimbangkan waktu yang diperlukan untuk menentukan ketidaktersediaan (5 detik), dalam waktu 10 - 15 detik setelah kecelakaan, LUN dari sistem penyimpanan yang jatuh akan secara otomatis tersedia untuk bekerja dengan siaran langsung. sistem penyimpanan.
Jelas bahwa untuk menghindari kehilangan koneksi dengan host, Anda juga perlu berhati-hati dalam mengonfigurasi batas waktu pada host dengan benar. Batas waktu yang disarankan adalah setidaknya 30 detik. Hal ini akan mencegah host memutuskan koneksi ke sistem penyimpanan selama peralihan beban jika terjadi bencana dan dapat memastikan bahwa tidak ada gangguan I/O.
Tunggu sebentar, ternyata jika metrocluster semuanya baik-baik saja, mengapa kita perlu replikasi secara teratur?
Kenyataannya, semuanya tidak sesederhana itu.
Mari kita pertimbangkan pro dan kontra dari metrocluster
Jadi, kami menyadari bahwa keuntungan nyata dari metrocluster dibandingkan replikasi konvensional adalah:
- Otomatisasi penuh, memastikan waktu pemulihan minimal jika terjadi bencana;
- Itu saja :-).
Dan sekarang, perhatian, kekurangannya:
- Biaya solusi. Meskipun metrocluster dalam sistem Aerodisk tidak memerlukan lisensi tambahan (lisensi yang sama digunakan untuk replika), biaya solusinya masih akan lebih tinggi daripada menggunakan replikasi sinkron. Anda harus menerapkan semua persyaratan untuk replika sinkron, ditambah persyaratan untuk metrocluster yang terkait dengan peralihan tambahan dan situs tambahan (lihat perencanaan metrocluster);
- Kompleksitas solusi. Metrocluster jauh lebih kompleks daripada replika biasa, dan memerlukan lebih banyak perhatian dan upaya untuk perencanaan, konfigurasi, dan dokumentasi.
Pada akhirnya. Metrocluster tentunya merupakan solusi yang sangat berteknologi maju dan baik ketika Anda benar-benar perlu menyediakan RTO dalam hitungan detik atau menit. Tetapi jika tidak ada tugas seperti itu, dan RTO dalam hitungan jam baik-baik saja untuk bisnis, maka tidak ada gunanya menembakkan burung pipit dari meriam. Replikasi pekerja-petani biasa saja sudah cukup, karena klaster metro akan menimbulkan biaya tambahan dan kerumitan infrastruktur TI.
Perencanaan metrokluster
Bagian ini tidak mengklaim sebagai panduan komprehensif untuk desain metrocluster, namun hanya menunjukkan arahan utama yang harus dikerjakan jika Anda memutuskan untuk membangun sistem seperti itu. Oleh karena itu, ketika benar-benar mengimplementasikan metrocluster, pastikan untuk melibatkan produsen sistem penyimpanan (yaitu kami) dan sistem terkait lainnya untuk berkonsultasi.
Taman bermain
Sebagaimana dinyatakan di atas, sebuah metrocluster memerlukan minimal tiga lokasi. Dua pusat data tempat sistem penyimpanan dan sistem terkait akan beroperasi, serta situs ketiga tempat arbiter akan bekerja.
Jarak antar pusat data yang disarankan tidak lebih dari 40 kilometer. Jarak yang lebih jauh kemungkinan besar akan menyebabkan penundaan tambahan, yang dalam kasus metrokluster sangat tidak diinginkan. Izinkan kami mengingatkan Anda bahwa penundaan harus mencapai 5 milidetik, meskipun disarankan untuk menjaganya dalam waktu 2.
Disarankan juga untuk memeriksa penundaan selama proses perencanaan. Penyedia mana pun yang kurang lebih matang yang menyediakan serat optik antar pusat data dapat mengatur pemeriksaan kualitas dengan cukup cepat.
Sedangkan untuk penundaan sebelum arbiter (yaitu, antara situs ketiga dan dua situs pertama), ambang penundaan yang disarankan adalah hingga 200 milidetik, yaitu koneksi VPN perusahaan biasa melalui Internet sudah sesuai.
Switching dan Jaringan
Berbeda dengan skema replikasi yang cukup menghubungkan sistem penyimpanan dari situs berbeda, skema metrocluster memerlukan koneksi host dengan kedua sistem penyimpanan di situs berbeda. Untuk lebih jelasnya apa perbedaannya, kedua skema tersebut disajikan di bawah ini.
Seperti dapat dilihat dari diagram, host situs 1 kita melihat sistem penyimpanan 1 dan sistem penyimpanan 2. Sebaliknya, host situs 2 melihat sistem penyimpanan 2 dan sistem penyimpanan 1. Artinya, setiap host melihat kedua sistem penyimpanan. Ini merupakan prasyarat untuk pengoperasian metrocluster.
Tentu saja, tidak perlu menghubungkan setiap host dengan kabel optik ke pusat data lain; port atau kabel saja sudah cukup. Semua koneksi ini harus dilakukan melalui switch Ethernet 10G+ atau FibreChannel 8G+ (FC hanya untuk menghubungkan host dan sistem penyimpanan untuk IO, saluran replikasi saat ini hanya tersedia melalui IP (Ethernet 10G+).
Sekarang beberapa kata tentang topologi jaringan. Poin penting adalah konfigurasi subnet yang benar. Penting untuk segera menentukan beberapa subnet untuk jenis lalu lintas berikut:
- Subnet replikasi tempat data akan disinkronkan antar sistem penyimpanan. Mungkin ada beberapa, dalam hal ini tidak masalah, semua tergantung topologi jaringan saat ini (sudah diimplementasikan). Jika ada dua di antaranya, maka perutean jelas harus dikonfigurasi di antara keduanya;
- Subnet penyimpanan yang digunakan host untuk mengakses sumber daya penyimpanan (jika iSCSI). Harus ada satu subnet di setiap pusat data;
- Subnet kontrol, yaitu tiga subnet yang dapat dirutekan di tiga situs tempat sistem penyimpanan dikelola, dan arbiter juga berlokasi di sana.
Kami tidak mempertimbangkan subnet untuk mengakses sumber daya host di sini, karena subnet sangat bergantung pada tugas.
Memisahkan lalu lintas yang berbeda ke dalam subnet yang berbeda sangatlah penting (sangat penting untuk memisahkan replika dari I/O), karena jika Anda menggabungkan semua lalu lintas menjadi satu subnet yang “tebal”, lalu lintas ini tidak mungkin dikelola, dan di kondisi dua pusat data ini masih dapat menyebabkan pilihan tabrakan jaringan yang berbeda. Kami tidak akan mempelajari masalah ini secara mendalam dalam kerangka artikel ini, karena Anda dapat membaca tentang perencanaan jaringan yang terbentang antara pusat data pada sumber daya produsen peralatan jaringan, yang menjelaskan hal ini dengan sangat rinci.
Konfigurasi arbiter
Arbiter harus menyediakan akses ke semua antarmuka manajemen sistem penyimpanan melalui protokol ICMP dan SSH. Anda juga harus memikirkan tentang kegagalan wasit. Ada nuansa di sini.
Kegagalan arbiter sangat diinginkan, tetapi tidak wajib. Apa jadinya jika wasit terjatuh di waktu yang salah?
- Pengoperasian metrocluster dalam mode normal tidak akan berubah, karena arbtir sama sekali tidak berpengaruh pada pengoperasian metrocluster dalam mode normal (tugasnya adalah mengalihkan beban antar pusat data secara tepat waktu)
- Terlebih lagi, jika arbiter karena satu dan lain hal terjatuh dan “tertidur” karena kecelakaan di pusat data, maka peralihan tidak akan terjadi, karena tidak akan ada orang yang memberikan perintah peralihan yang diperlukan dan mengatur kuorum. Dalam hal ini, metrocluster akan berubah menjadi skema reguler dengan replikasi, yang harus dialihkan secara manual jika terjadi bencana, yang akan mempengaruhi RTO.
Apa yang berikut ini? Jika Anda benar-benar perlu memastikan RTO minimum, Anda perlu memastikan arbiternya toleran terhadap kesalahan. Ada dua opsi untuk ini:
- Luncurkan mesin virtual dengan arbiter pada hypervisor yang toleran terhadap kesalahan, untungnya semua hypervisor dewasa mendukung toleransi kesalahan;
- Jika di situs ketiga (di kantor konvensional) Anda terlalu malas untuk menginstal cluster normal dan tidak ada cluster hypervozor yang ada, maka kami telah menyediakan arbiter versi hardware, yang dibuat dalam kotak 2U di mana dua biasa server x-86 berfungsi dan dapat bertahan dari kegagalan lokal.
Kami sangat menyarankan untuk memastikan toleransi kesalahan arbiter, meskipun metrocluster tidak memerlukannya dalam mode normal. Namun seperti yang ditunjukkan oleh teori dan praktik, jika Anda membangun infrastruktur tahan bencana yang benar-benar andal, lebih baik Anda bermain aman. Lebih baik lindungi diri Anda dan bisnis Anda dari “hukum kekejaman”, yaitu kegagalan arbiter dan salah satu situs tempat sistem penyimpanan berada.
Arsitektur solusi
Mempertimbangkan persyaratan di atas, kami memperoleh arsitektur solusi umum berikut.
LUN harus didistribusikan secara merata di dua lokasi untuk menghindari kelebihan beban yang parah. Pada saat yang sama, ketika melakukan pengukuran di kedua pusat data, Anda harus menyertakan tidak hanya volume ganda (yang diperlukan untuk menyimpan data secara bersamaan di dua sistem penyimpanan), namun juga kinerja ganda dalam IOPS dan MB/s untuk mencegah degradasi aplikasi di jika terjadi kegagalan pada salah satu pusat data.ov.
Secara terpisah, kami mencatat bahwa dengan pendekatan ukuran yang tepat (yaitu, asalkan kami telah memberikan batas atas IOPS dan MB/s yang sesuai, serta sumber daya CPU dan RAM yang diperlukan), jika salah satu sistem penyimpanan di cluster metro gagal, tidak akan ada penurunan kinerja yang serius dalam kondisi pekerjaan sementara pada satu sistem penyimpanan.
Hal ini dijelaskan oleh fakta bahwa ketika dua situs beroperasi secara bersamaan, replikasi sinkron “memakan” setengah dari kinerja penulisan, karena setiap transaksi harus ditulis ke dua sistem penyimpanan (mirip dengan RAID-1/10). Jadi, jika salah satu sistem penyimpanan gagal, pengaruh replikasi untuk sementara (sampai sistem penyimpanan yang gagal pulih) hilang, dan kami mendapatkan peningkatan kinerja penulisan dua kali lipat. Setelah LUN dari sistem penyimpanan yang gagal dihidupkan ulang pada sistem penyimpanan yang berfungsi, peningkatan dua kali lipat ini hilang karena fakta bahwa beban muncul dari LUN dari sistem penyimpanan lain, dan kami kembali ke tingkat kinerja yang sama seperti sebelumnya. “jatuh”, tetapi hanya dalam satu situs.
Dengan bantuan pengukuran yang kompeten, Anda dapat memastikan kondisi di mana pengguna tidak akan merasakan kegagalan seluruh sistem penyimpanan sama sekali. Namun kami ulangi sekali lagi, ini memerlukan pengukuran yang sangat hati-hati, untuk itu, Anda dapat menghubungi kami secara gratis :-).
Menyiapkan metrokluster
Menyiapkan metrocluster sangat mirip dengan menyiapkan replikasi reguler, yang telah kami jelaskan di . Oleh karena itu, mari kita fokus pada perbedaannya saja. Kami menyiapkan bangku di laboratorium berdasarkan arsitektur di atas, hanya dalam versi minimal: dua sistem penyimpanan yang terhubung melalui Ethernet 10G, dua sakelar 10G, dan satu host yang melihat melalui sakelar di kedua sistem penyimpanan dengan port 10G. Wasit berjalan pada mesin virtual.
Saat mengonfigurasi IP virtual (VIP) untuk replika, Anda harus memilih jenis VIP - untuk metrocluster.
Kami membuat dua tautan replikasi untuk dua LUN dan mendistribusikannya ke dua sistem penyimpanan: LUN TEST Primer pada sistem penyimpanan 1 (link METRO), LUN TEST2 Primer untuk sistem penyimpanan 2 (link METRO2).
Bagi mereka, kami mengonfigurasi dua target yang identik (dalam kasus kami iSCSI, tetapi FC juga didukung, logika pengaturannya sama).
Sistem penyimpanan1:
Sistem penyimpanan2:
Untuk koneksi replikasi, pemetaan dilakukan pada setiap sistem penyimpanan.
Sistem penyimpanan1:
Sistem penyimpanan2:
Kami menyiapkan multipath dan mempresentasikannya ke host.
Menyiapkan arbiter
Anda tidak perlu melakukan sesuatu yang khusus dengan arbiter itu sendiri; Anda hanya perlu mengaktifkannya di situs ketiga, memberinya IP dan mengkonfigurasi akses ke sana melalui ICMP dan SSH. Pengaturannya sendiri dilakukan dari sistem penyimpanan itu sendiri. Dalam hal ini, cukup mengkonfigurasi arbiter satu kali pada salah satu pengontrol penyimpanan di metrocluster; pengaturan ini akan didistribusikan ke semua pengontrol secara otomatis.
Di bagian Replikasi jarak jauh>> Metrocluster (pada pengontrol apa pun)>> tombol "Konfigurasi".
Kami memasukkan IP arbiter, serta antarmuka kontrol dari dua pengontrol penyimpanan jarak jauh.
Setelah ini, Anda perlu mengaktifkan semua layanan (tombol “Restart Everything”). Jika dikonfigurasi ulang di masa mendatang, layanan harus dimulai ulang agar pengaturan dapat diterapkan.
Kami memeriksa apakah semua layanan berjalan.
Ini menyelesaikan pengaturan metrocluster.
Tes menghancurkan
Uji tabrakan dalam kasus kami akan cukup sederhana dan cepat, karena fungsi replikasi (peralihan, konsistensi, dll.) telah dibahas di . Oleh karena itu, untuk menguji keandalan metrocluster, cukup kita memeriksa otomatisasi deteksi kegagalan, switching dan tidak adanya rekaman kerugian (I/O berhenti).
Untuk melakukan hal ini, kami meniru kegagalan total salah satu sistem penyimpanan dengan mematikan kedua pengontrolnya secara fisik, setelah terlebih dahulu mulai menyalin file besar ke LUN, yang harus diaktifkan di sistem penyimpanan lainnya.
Nonaktifkan satu sistem penyimpanan. Pada sistem penyimpanan kedua kita melihat peringatan dan pesan di log bahwa koneksi dengan sistem tetangga telah terputus. Jika notifikasi melalui pemantauan SMTP atau SNMP dikonfigurasi, administrator akan menerima notifikasi terkait.
Tepat 10 detik kemudian (terlihat di kedua tangkapan layar), koneksi replikasi METRO (yang tadinya Utama pada sistem penyimpanan yang gagal) secara otomatis menjadi Utama pada sistem penyimpanan yang berfungsi. Dengan menggunakan pemetaan yang ada, LUN TEST tetap tersedia untuk host, rekamannya sedikit menurun (dalam 10 persen yang dijanjikan), namun tidak terganggu.
Tes berhasil diselesaikan.
Menyimpulkan
Penerapan metrocluster saat ini dalam sistem penyimpanan AERODISK Engine N-series sepenuhnya memungkinkan pemecahan masalah yang diperlukan untuk menghilangkan atau meminimalkan waktu henti layanan TI dan memastikan pengoperasiannya 24/7/365 dengan biaya tenaga kerja minimal.
Tentu saja kita dapat mengatakan bahwa semua ini hanyalah teori, kondisi laboratorium yang ideal, dan sebagainya... TETAPI kami memiliki sejumlah proyek yang telah dilaksanakan dimana kami telah menerapkan fungsi ketahanan bencana, dan sistemnya bekerja dengan sempurna. Salah satu pelanggan kami yang cukup terkenal, yang hanya menggunakan dua sistem penyimpanan dalam konfigurasi tahan bencana, telah setuju untuk mempublikasikan informasi tentang proyek tersebut, jadi di bagian selanjutnya kita akan membahas tentang implementasi tempur.
Terima kasih, kami menantikan diskusi yang produktif.
Sumber: www.habr.com