Hello, pembaca Habr! Dalam artikel lepas, kami bercakap tentang cara mudah pemulihan bencana dalam sistem storan AERODISK ENGINE - replikasi. Dalam artikel ini, kita akan menyelami topik yang lebih kompleks dan menarik - metrocluster, iaitu, satu cara perlindungan bencana automatik untuk dua pusat data, membolehkan pusat data beroperasi dalam mod aktif-aktif. Kami akan memberitahu anda, menunjukkan kepada anda, memecahkannya dan membetulkannya.
Macam biasa, teori dulu
Kluster metro ialah gugusan yang tersebar di beberapa tapak dalam bandar atau wilayah. Perkataan "kluster" jelas membayangkan kepada kita bahawa kompleks itu adalah automatik, iaitu, menukar nod kluster sekiranya kegagalan berlaku secara automatik.
Di sinilah terletaknya perbezaan utama antara kumpulan metro dan replikasi biasa. Automasi operasi. Iaitu, sekiranya berlaku insiden tertentu (kegagalan pusat data, saluran rosak, dll.), sistem storan akan melakukan tindakan yang diperlukan secara bebas untuk mengekalkan ketersediaan data. Apabila menggunakan replika biasa, tindakan ini dilakukan sepenuhnya atau sebahagiannya secara manual oleh pentadbir.
Apa yang ia buat?
Matlamat utama yang pelanggan kejar apabila menggunakan pelaksanaan metrocluster tertentu adalah untuk meminimumkan RTO (Objektif Masa Pemulihan). Iaitu, untuk meminimumkan masa pemulihan perkhidmatan IT selepas kegagalan. Jika anda menggunakan replikasi biasa, masa pemulihan akan sentiasa lebih lama daripada masa pemulihan dengan metrocluster. kenapa? Sangat ringkas. Pentadbir mesti berada di mejanya dan menukar replikasi secara manual, dan metrocluster melakukan ini secara automatik.
Jika anda tidak mempunyai pentadbir khusus yang bertugas yang tidak tidur, tidak makan, tidak merokok atau sakit, dan memantau keadaan sistem storan 24 jam sehari, maka tidak ada cara untuk menjamin bahawa pentadbir akan tersedia untuk pensuisan manual semasa kegagalan.
Sehubungan itu, RTO jika tiada kluster metro atau pentadbir abadi bagi perkhidmatan tugas pentadbir peringkat ke-99 akan sama dengan jumlah masa penukaran semua sistem dan tempoh masa maksimum selepas itu pentadbir dijamin untuk mula bekerja dengan sistem storan dan sistem yang berkaitan.
Oleh itu, kami sampai pada kesimpulan yang jelas bahawa metrocluster harus digunakan jika keperluan untuk RTO adalah beberapa minit, bukan jam atau hari. Iaitu, apabila berlaku kegagalan pusat data yang paling teruk, jabatan IT mesti menyediakan perniagaan dengan masa untuk memulihkan akses kepada perkhidmatan IT dalam beberapa minit, atau bahkan beberapa saat.
Bagaimana ia berfungsi?
Di peringkat bawah, kluster metro menggunakan mekanisme untuk replikasi data segerak, yang kami terangkan dalam artikel sebelumnya (lihat. ). Oleh kerana replikasi adalah segerak, keperluan untuknya adalah sepadan, atau sebaliknya:
- gentian optik sebagai fizik, 10 gigabit Ethernet (atau lebih tinggi);
- jarak antara pusat data tidak lebih daripada 40 kilometer;
- kelewatan saluran optik antara pusat data (antara sistem storan) adalah sehingga 5 milisaat (secara optimum 2).
Semua keperluan ini bersifat nasihat, iaitu, metrocluster akan berfungsi walaupun keperluan ini tidak dipenuhi, tetapi kita mesti memahami bahawa akibat ketidakpatuhan terhadap keperluan ini adalah sama dengan kelembapan dalam operasi kedua-dua sistem storan dalam kluster metro.
Jadi, replika segerak digunakan untuk memindahkan data antara sistem storan, dan bagaimana replika bertukar secara automatik dan, yang paling penting, bagaimana untuk mengelakkan otak berpecah? Untuk melakukan ini, pada tahap yang lebih tinggi, entiti tambahan digunakan - seorang penimbang tara.
Bagaimanakah seorang penimbang tara berfungsi dan apakah tugasnya?
Arbiter ialah mesin maya kecil atau kluster perkakasan yang mesti dilancarkan di tapak ketiga (contohnya, di pejabat) dan menyediakan akses kepada sistem storan melalui ICMP dan SSH. Selepas pelancaran, penimbang tara harus menetapkan IP, dan kemudian dari bahagian storan menunjukkan alamatnya, ditambah dengan alamat alat kawalan jauh yang mengambil bahagian dalam metrocluster. Selepas ini, pengadil bersedia untuk bekerja.
Pengadil sentiasa memantau semua sistem storan dalam metrocluster dan jika sistem storan tertentu tidak tersedia, selepas mengesahkan ketiadaan daripada ahli kluster yang lain (salah satu sistem storan "langsung"), dia memutuskan untuk melancarkan prosedur untuk menukar peraturan replikasi dan pemetaan.
Satu perkara yang sangat penting. Penimbang tara mesti sentiasa berada di tapak yang berbeza daripada tempat di mana sistem storan terletak, iaitu, tidak di pusat data 1, di mana sistem storan 1 dipasang, mahupun di pusat data 2, di mana sistem storan 2 dipasang.
kenapa? Kerana ini adalah satu-satunya cara seorang penimbang tara, dengan bantuan salah satu sistem storan yang masih hidup, boleh menentukan dengan jelas dan tepat kejatuhan mana-mana dua tapak di mana sistem storan dipasang. Sebarang kaedah lain untuk meletakkan penimbang tara boleh mengakibatkan otak berpecah.
Sekarang mari kita menyelami butiran kerja penimbang tara.
Pengadil menjalankan beberapa perkhidmatan yang sentiasa meninjau semua pengawal storan. Jika keputusan tinjauan pendapat berbeza daripada yang sebelumnya (tersedia/tidak tersedia), maka ia direkodkan dalam pangkalan data kecil, yang juga berfungsi pada penimbang tara.
Mari kita lihat logik kerja penimbang tara dengan lebih terperinci.
Langkah 1: Tentukan ketiadaan. Peristiwa kegagalan sistem storan ialah ketiadaan ping daripada kedua-dua pengawal sistem storan yang sama dalam masa 5 saat.
Langkah 2. Mulakan prosedur pensuisan. Selepas penimbang tara menyedari bahawa salah satu sistem storan tidak tersedia, dia menghantar permintaan kepada sistem storan "hidup" untuk memastikan sistem storan "mati" benar-benar mati.
Selepas menerima arahan sedemikian daripada pengadil, sistem storan kedua (langsung) juga menyemak ketersediaan sistem storan pertama yang jatuh dan, jika ia tidak ada, menghantar pengesahan kepada pengadil tekaannya. Sistem storan sememangnya tidak tersedia.
Selepas menerima pengesahan sedemikian, pengadil melancarkan prosedur jauh untuk menukar replikasi dan meningkatkan pemetaan pada replika yang aktif (utama) pada sistem storan yang jatuh, dan menghantar arahan kepada sistem storan kedua untuk menukar replika ini daripada sekunder kepada primer dan meningkatkan pemetaan. Oleh itu, sistem storan kedua, dengan itu, melaksanakan prosedur ini, dan kemudian menyediakan akses kepada LUN yang hilang dari dirinya sendiri.
Mengapa pengesahan tambahan diperlukan? Untuk korum. Iaitu, majoriti daripada jumlah ganjil (3) bilangan ahli kluster mesti mengesahkan kejatuhan salah satu nod kluster. Barulah keputusan ini pasti betul. Ini adalah perlu untuk mengelakkan pertukaran yang salah dan, oleh itu, otak berpecah.
Langkah masa 2 mengambil masa kira-kira 5 - 10 saat, oleh itu, mengambil kira masa yang diperlukan untuk menentukan ketaksediaan (5 saat), dalam masa 10 - 15 saat selepas kemalangan, LUN daripada sistem storan yang jatuh akan tersedia secara automatik untuk berfungsi dengan langsung sistem penyimpanan.
Jelas sekali bahawa untuk mengelakkan kehilangan sambungan dengan hos, anda juga perlu berhati-hati untuk mengkonfigurasi tamat masa dengan betul pada hos. Tamat masa yang disyorkan ialah sekurang-kurangnya 30 saat. Ini akan menghalang hos daripada memutuskan sambungan ke sistem storan semasa penukaran beban sekiranya berlaku bencana dan boleh memastikan tiada gangguan I/O.
Tunggu sebentar, ternyata jika semuanya begitu baik dengan metrocluster, mengapa kita memerlukan replikasi biasa sama sekali?
Pada hakikatnya, semuanya tidak begitu mudah.
Mari kita pertimbangkan kebaikan dan keburukan metrocluster
Jadi, kami menyedari bahawa kelebihan jelas metrocluster berbanding dengan replikasi konvensional ialah:
- Automasi penuh, memastikan masa pemulihan yang minimum sekiranya berlaku bencana;
- Itu sahaja :-).
Dan sekarang, perhatian, keburukan:
- Kos penyelesaian. Walaupun kluster metro dalam sistem Aerodisk tidak memerlukan pelesenan tambahan (lesen yang sama digunakan seperti untuk replika), kos penyelesaian akan tetap lebih tinggi daripada menggunakan replikasi segerak. Anda perlu melaksanakan semua keperluan untuk replika segerak, ditambah dengan keperluan untuk metrocluster yang dikaitkan dengan pensuisan tambahan dan tapak tambahan (lihat perancangan metrocluster);
- Kerumitan penyelesaian. Kluster metro jauh lebih kompleks daripada replika biasa, dan memerlukan lebih banyak perhatian dan usaha untuk perancangan, konfigurasi dan dokumentasi.
Akhirnya. Metrocluster sememangnya penyelesaian yang sangat maju dari segi teknologi dan baik apabila anda benar-benar perlu menyediakan RTO dalam beberapa saat atau minit. Tetapi jika tidak ada tugas sedemikian, dan RTO dalam beberapa jam adalah OK untuk perniagaan, maka tidak ada gunanya menembak burung pipit dari meriam. Replikasi pekerja-petani biasa adalah mencukupi, kerana kluster metro akan menyebabkan kos tambahan dan komplikasi infrastruktur IT.
Perancangan Metrocluster
Bahagian ini tidak mendakwa sebagai panduan komprehensif untuk reka bentuk metrocluster, tetapi hanya menunjukkan arah utama yang harus diusahakan jika anda memutuskan untuk membina sistem sedemikian. Oleh itu, apabila benar-benar melaksanakan metrocluster, pastikan anda melibatkan pengeluar sistem storan (iaitu, kami) dan sistem lain yang berkaitan untuk perundingan.
Tempat
Seperti yang dinyatakan di atas, kluster metro memerlukan sekurang-kurangnya tiga tapak. Dua pusat data di mana sistem storan dan sistem berkaitan akan beroperasi, serta tapak ketiga di mana penimbang tara akan berfungsi.
Jarak yang disyorkan antara pusat data tidak melebihi 40 kilometer. Jarak yang lebih besar berkemungkinan besar menyebabkan kelewatan tambahan, yang dalam kes metrocluster adalah sangat tidak diingini. Biar kami mengingatkan anda bahawa kelewatan hendaklah sehingga 5 milisaat, walaupun dinasihatkan untuk mengekalkannya dalam masa 2.
Adalah disyorkan untuk menyemak kelewatan juga semasa proses perancangan. Mana-mana pembekal yang lebih atau kurang matang yang menyediakan gentian optik antara pusat data boleh mengatur pemeriksaan kualiti dengan agak cepat.
Bagi kelewatan sebelum penimbang tara (iaitu, antara tapak ketiga dan dua yang pertama), ambang kelewatan yang disyorkan ialah sehingga 200 milisaat, iaitu sambungan VPN korporat biasa melalui Internet adalah sesuai.
Penukaran dan Rangkaian
Tidak seperti skim replikasi, di mana ia cukup untuk menyambungkan sistem storan dari tapak yang berbeza, skim metrocluster memerlukan penyambungan hos dengan kedua-dua sistem storan di tapak yang berbeza. Untuk menjelaskan dengan lebih jelas perbezaannya, kedua-dua skema ditunjukkan di bawah.
Seperti yang dapat dilihat daripada rajah, hos tapak 1 kami melihat kedua-dua sistem storan 1 dan sistem storan 2. Selain itu, sebaliknya, hos tapak 2 melihat kedua-dua sistem storan 2 dan sistem storan 1. Iaitu, setiap hos melihat kedua-dua sistem storan. Ini adalah prasyarat untuk operasi metrocluster.
Sudah tentu, tidak perlu menyambungkan setiap hos dengan kord optik ke pusat data lain; tiada port atau kord akan mencukupi. Semua sambungan ini mesti dibuat melalui suis Ethernet 10G+ atau FibreChannel 8G+ (FC hanya untuk menyambungkan hos dan sistem storan untuk IO, saluran replikasi pada masa ini hanya tersedia melalui IP (Ethernet 10G+).
Sekarang beberapa perkataan mengenai topologi rangkaian. Perkara penting ialah konfigurasi subnet yang betul. Anda perlu segera menentukan beberapa subnet untuk jenis trafik berikut:
- Subnet replikasi di mana data akan disegerakkan antara sistem storan. Mungkin terdapat beberapa daripada mereka, dalam kes ini tidak mengapa, semuanya bergantung pada topologi rangkaian semasa (sudah dilaksanakan). Jika terdapat dua daripada mereka, maka jelas penghalaan mesti dikonfigurasikan antara mereka;
- Subnet storan yang melaluinya hos akan mengakses sumber storan (jika ia adalah iSCSI). Perlu ada satu subnet sedemikian dalam setiap pusat data;
- Kawal subnet, iaitu, tiga subnet yang boleh dialihkan pada tiga tapak dari mana sistem storan diuruskan, dan penimbang tara juga terletak di sana.
Kami tidak menganggap subnet untuk mengakses sumber hos di sini, kerana ia sangat bergantung pada tugas.
Mengasingkan trafik yang berbeza kepada subnet yang berbeza adalah amat penting (terutamanya adalah penting untuk memisahkan replika daripada I/O), kerana jika anda mencampurkan semua trafik ke dalam satu subnet "tebal", maka trafik ini akan menjadi mustahil untuk diuruskan, dan dalam keadaan dua pusat data ini masih boleh menyebabkan pilihan perlanggaran rangkaian yang berbeza. Kami tidak akan menyelidiki secara mendalam isu ini dalam rangka artikel ini, kerana anda boleh membaca tentang merancang rangkaian yang terbentang antara pusat data pada sumber pengeluar peralatan rangkaian, di mana perkara ini diterangkan dengan terperinci.
Konfigurasi penimbang tara
Pengadil mesti menyediakan akses kepada semua antara muka pengurusan sistem storan melalui protokol ICMP dan SSH. Anda juga harus memikirkan tentang failsafe pengadil. Terdapat nuansa di sini.
Failover arbiter sangat diingini, tetapi tidak diperlukan. Apa yang berlaku jika pengadil terhempas pada masa yang salah?
- Pengendalian metrocluster dalam mod biasa tidak akan berubah, kerana arbtir sama sekali tidak mempunyai kesan ke atas operasi metrocluster dalam mod biasa (tugasnya adalah untuk menukar beban antara pusat data tepat pada masanya)
- Lebih-lebih lagi, jika pengadil atas satu sebab atau yang lain jatuh dan "tidur melalui" kemalangan di pusat data, maka tiada penukaran akan berlaku, kerana tidak akan ada sesiapa yang memberikan arahan penukaran yang diperlukan dan mengatur kuorum. Dalam kes ini, metrocluster akan bertukar menjadi skema biasa dengan replikasi, yang perlu ditukar secara manual semasa bencana, yang akan menjejaskan RTO.
Apa yang berikut daripada ini? Jika anda benar-benar perlu memastikan RTO minimum, anda perlu memastikan pengadil adalah toleran terhadap kesalahan. Terdapat dua pilihan untuk ini:
- Lancarkan mesin maya dengan pengadil pada hipervisor toleran kesalahan, mujurlah semua hipervisor dewasa menyokong toleransi kesalahan;
- Jika di tapak ketiga (di pejabat konvensional) anda terlalu malas untuk memasang kluster biasa dan tiada kluster hypervozor sedia ada, maka kami telah menyediakan versi perkakasan arbiter, yang dibuat dalam kotak 2U di mana dua biasa pelayan x-86 berfungsi dan yang boleh bertahan dari kegagalan setempat.
Kami amat mengesyorkan untuk memastikan toleransi kesalahan pengadil, walaupun pada hakikatnya kumpulan metro tidak memerlukannya dalam mod biasa. Tetapi seperti yang ditunjukkan oleh kedua-dua teori dan amalan, jika anda membina infrastruktur kalis bencana yang benar-benar boleh dipercayai, maka adalah lebih baik untuk memainkannya dengan selamat. Adalah lebih baik untuk melindungi diri anda dan perniagaan anda daripada "undang-undang kekejaman", iaitu, daripada kegagalan kedua-dua penimbang tara dan salah satu tapak di mana sistem storan berada.
Seni bina penyelesaian
Memandangkan keperluan di atas, kami mendapat seni bina penyelesaian umum berikut.
LUN harus diagihkan sama rata di dua tapak untuk mengelakkan beban berlebihan yang teruk. Pada masa yang sama, apabila saiz dalam kedua-dua pusat data, anda harus memasukkan bukan sahaja volum berganda (yang diperlukan untuk menyimpan data serentak pada dua sistem storan), tetapi juga prestasi berganda dalam IOPS dan MB/s untuk mengelakkan degradasi aplikasi dalam kejadian kegagalan salah satu pusat data.
Secara berasingan, kami ambil perhatian bahawa dengan pendekatan saiz yang betul (iaitu, dengan syarat kami telah menyediakan had atas IOPS dan MB/s yang betul, serta sumber CPU dan RAM yang diperlukan), jika salah satu sistem storan dalam kluster metro gagal, tidak akan ada penurunan yang serius dalam prestasi dalam keadaan kerja sementara pada satu sistem storan.
Ini dijelaskan oleh fakta bahawa apabila dua tapak beroperasi secara serentak, replikasi segerak "memakan" separuh daripada prestasi tulis, kerana setiap transaksi mesti ditulis kepada dua sistem storan (serupa dengan RAID-1/10). Jadi, jika salah satu sistem storan gagal, pengaruh replikasi buat sementara waktu (sehingga sistem storan yang gagal pulih) hilang, dan kami mendapat peningkatan dua kali ganda dalam prestasi tulis. Selepas LUN sistem storan yang gagal dimulakan semula pada sistem storan yang berfungsi, peningkatan dua kali ganda ini hilang disebabkan oleh fakta bahawa beban muncul daripada LUN sistem storan lain, dan kami kembali ke tahap prestasi yang sama seperti yang kami ada sebelum "jatuh", tetapi hanya dalam rangka satu tapak.
Dengan bantuan saiz yang cekap, anda boleh memastikan keadaan di mana pengguna tidak akan merasakan kegagalan keseluruhan sistem storan sama sekali. Tetapi kami ulangi sekali lagi, ini memerlukan saiz yang sangat berhati-hati, yang mana, dengan cara itu, anda boleh menghubungi kami secara percuma :-).
Menyediakan metrocluster
Menyediakan metrocluster adalah sangat serupa dengan menyediakan replikasi biasa, yang kami terangkan dalam . Oleh itu, mari kita fokus hanya pada perbezaan. Kami menyediakan bangku di makmal berdasarkan seni bina di atas, hanya dalam versi minimum: dua sistem storan yang disambungkan melalui 10G Ethernet, dua suis 10G dan satu hos yang melihat melalui suis pada kedua-dua sistem storan dengan port 10G. Pengadil berjalan pada mesin maya.
Apabila mengkonfigurasi IP maya (VIP) untuk replika, anda harus memilih jenis VIP - untuk metrocluster.
Kami mencipta dua pautan replikasi untuk dua LUN dan mengedarkannya merentas dua sistem storan: LUN TEST Utama pada sistem storan 1 (METRO pautan), LUN TEST2 Utama untuk sistem storan 2 (METRO2 pautan).
Bagi mereka, kami mengkonfigurasi dua sasaran yang sama (dalam kes kami iSCSI, tetapi FC juga disokong, logik persediaan adalah sama).
Sistem storan1:
Sistem storan2:
Untuk sambungan replikasi, pemetaan dibuat pada setiap sistem storan.
Sistem storan1:
Sistem storan2:
Kami menyediakan berbilang laluan dan membentangkannya kepada hos.
Menubuhkan penimbang tara
Anda tidak perlu melakukan sesuatu yang istimewa dengan penimbang tara itu sendiri; anda hanya perlu mendayakannya di tapak ketiga, berikan IP dan konfigurasikan akses kepadanya melalui ICMP dan SSH. Persediaan itu sendiri dilakukan daripada sistem storan itu sendiri. Dalam kes ini, cukup untuk mengkonfigurasi pengadil sekali pada mana-mana pengawal storan dalam metrocluster; tetapan ini akan diedarkan kepada semua pengawal secara automatik.
Dalam bahagian Replikasi jauh>> Metrocluster (pada mana-mana pengawal)>> butang "Konfigurasikan".
Kami memasukkan IP pengadil, serta antara muka kawalan dua pengawal storan jauh.
Selepas ini, anda perlu mendayakan semua perkhidmatan (butang "Mulakan semula semuanya"). Jika dikonfigurasikan semula pada masa hadapan, perkhidmatan mesti dimulakan semula untuk tetapan berkuat kuasa.
Kami menyemak bahawa semua perkhidmatan sedang berjalan.
Ini melengkapkan persediaan metrocluster.
Ujian ranap
Ujian ranap dalam kes kami akan menjadi agak mudah dan pantas, kerana fungsi replikasi (penukaran, konsistensi, dll.) telah dibincangkan dalam . Oleh itu, untuk menguji kebolehpercayaan metrocluster, sudah cukup untuk kita menyemak automasi pengesanan kegagalan, pensuisan dan ketiadaan kehilangan rakaman (I/O berhenti).
Untuk melakukan ini, kami mencontohi kegagalan sepenuhnya salah satu sistem storan dengan mematikan kedua-dua pengawalnya secara fizikal, setelah mula menyalin fail besar ke LUN, yang mesti diaktifkan pada sistem storan yang lain.
Lumpuhkan satu sistem storan. Pada sistem storan kedua kita melihat makluman dan mesej dalam log bahawa sambungan dengan sistem jiran telah hilang. Jika pemberitahuan melalui pemantauan SMTP atau SNMP dikonfigurasikan, pentadbir akan menerima pemberitahuan yang sepadan.
Tepat 10 saat kemudian (kelihatan dalam kedua-dua tangkapan skrin), sambungan replikasi METRO (yang menjadi Utama pada sistem storan yang gagal) secara automatik menjadi Utama pada sistem storan yang berfungsi. Menggunakan pemetaan sedia ada, LUN TEST kekal tersedia kepada hos, rakaman merosot sedikit (dalam 10 peratus yang dijanjikan), tetapi tidak terganggu.
Ujian selesai dengan jayanya.
Menyimpulkan
Pelaksanaan metrocluster semasa dalam sistem storan AERODISK Engine N-series sepenuhnya membolehkan menyelesaikan masalah di mana perlu untuk menghapuskan atau meminimumkan masa henti bagi perkhidmatan IT dan memastikan operasinya 24/7/365 dengan kos buruh yang minimum.
Kita boleh katakan, sudah tentu, bahawa semua ini adalah teori, keadaan makmal yang ideal, dan sebagainya... TETAPI kita mempunyai beberapa projek yang dilaksanakan di mana kita telah melaksanakan fungsi daya tahan bencana, dan sistem berfungsi dengan sempurna. Salah seorang pelanggan kami yang cukup terkenal, yang menggunakan hanya dua sistem storan dalam konfigurasi kalis bencana, telah bersetuju untuk menerbitkan maklumat tentang projek itu, jadi pada bahagian seterusnya kami akan bercakap tentang pelaksanaan pertempuran.
Terima kasih, kami menantikan perbincangan yang produktif.
Sumber: www.habr.com