Hello, pembaca Habr! Topik artikel ini ialah pelaksanaan alat pemulihan bencana dalam sistem storan Enjin AERODISK. Pada mulanya, kami ingin menulis dalam satu artikel tentang kedua-dua alat: replikasi dan metrocluster, tetapi, malangnya, artikel itu ternyata terlalu panjang, jadi kami membahagikan artikel itu kepada dua bahagian. Mari kita beralih daripada mudah kepada kompleks. Dalam artikel ini, kami akan menyediakan dan menguji replikasi segerak - kami akan menggugurkan satu pusat data, dan juga memecahkan saluran komunikasi antara pusat data dan melihat apa yang berlaku.
Pelanggan kami sering bertanya kepada kami pelbagai soalan tentang replikasi, jadi sebelum meneruskan untuk menyediakan dan menguji pelaksanaan replika, kami akan memberitahu anda sedikit tentang replikasi dalam storan.
Sedikit teori
Replikasi dalam sistem storan ialah proses berterusan untuk memastikan identiti data pada beberapa sistem storan secara serentak. Secara teknikal, replikasi dilakukan dalam dua cara.
Replikasi segerak – ini menyalin data daripada sistem storan utama kepada sistem sandaran, diikuti dengan pengesahan mandatori daripada kedua-dua sistem storan bahawa data telah direkodkan dan disahkan. Ia adalah selepas pengesahan pada kedua-dua belah pihak (kedua-dua sistem storan) bahawa data itu dianggap direkodkan dan boleh digunakan. Ini memastikan identiti data terjamin pada semua sistem storan yang mengambil bahagian dalam replika.
Kelebihan kaedah ini:
- Data sentiasa sama pada semua sistem storan
Cons:
- Kos penyelesaian yang tinggi (saluran komunikasi pantas, gentian optik mahal, transceiver gelombang panjang, dsb.)
- Sekatan jarak (dalam beberapa puluh kilometer)
- Tiada perlindungan terhadap rasuah data logik (jika data rosak (sengaja atau tidak sengaja) pada sistem storan utama, ia akan secara automatik dan serta-merta menjadi rosak pada sandaran, kerana data sentiasa sama (itulah paradoksnya)
Replikasi tak segerak – ini juga menyalin data daripada sistem storan utama kepada sistem sandaran, tetapi dengan kelewatan tertentu dan tanpa perlu mengesahkan penulisan di sisi lain. Anda boleh bekerja dengan data serta-merta selepas merakamnya ke sistem storan utama, dan pada sistem storan sandaran data akan tersedia selepas beberapa ketika. Identiti data dalam kes ini, sudah tentu, tidak dipastikan sama sekali. Data pada sistem storan sandaran sentiasa sedikit "pada masa lalu."
Kelebihan replikasi tak segerak:
- Penyelesaian kos rendah (sebarang saluran komunikasi, optik pilihan)
- Tiada sekatan jarak
- Pada sistem storan sandaran, data tidak merosot jika ia rosak pada yang utama (sekurang-kurangnya untuk beberapa waktu); jika data menjadi rosak, anda sentiasa boleh menghentikan replika untuk mengelakkan rasuah data pada sistem storan sandaran
Cons:
- Data dalam pusat data yang berbeza sentiasa tidak sama
Oleh itu, pilihan mod replikasi bergantung pada objektif perniagaan. Jika penting bagi anda bahawa pusat data sandaran mengandungi data yang sama persis dengan pusat data utama (iaitu, keperluan perniagaan untuk RPO = 0), maka anda perlu mengeluarkan wang tunai dan bersabar dengan had segerak. replika. Dan jika kelewatan dalam keadaan data boleh diterima atau tidak ada wang, maka anda pasti perlu menggunakan kaedah tak segerak.
Marilah kita juga menyerlahkan mod sedemikian secara berasingan (lebih tepat, topologi) sebagai metrocluster. Dalam mod metrocluster, replikasi segerak digunakan, tetapi, tidak seperti replika biasa, metrocluster membenarkan kedua-dua sistem storan beroperasi dalam mod aktif. Itu. anda tidak mempunyai pemisahan antara pusat data aktif dan siap sedia. Aplikasi berfungsi serentak dengan dua sistem storan, yang terletak secara fizikal di pusat data yang berbeza. Masa henti semasa kemalangan dalam topologi sedemikian adalah sangat kecil (RTO, biasanya minit). Dalam artikel ini kami tidak akan mempertimbangkan pelaksanaan metrocluster kami, kerana ini adalah topik yang sangat besar dan luas, jadi kami akan menumpukan artikel yang berasingan, seterusnya, sebagai kesinambungan yang ini.
Juga, selalunya, apabila kita bercakap tentang replikasi menggunakan sistem storan, ramai orang mempunyai soalan yang munasabah: > “Banyak aplikasi mempunyai alat replikasi mereka sendiri, mengapa menggunakan replikasi pada sistem storan? Adakah ia lebih baik atau lebih teruk?
Tiada jawapan yang jelas di sini, jadi inilah hujah UNTUK dan KEBURUKAN:
Argumen UNTUK replikasi storan:
- Kesederhanaan penyelesaian. Dengan satu alat, anda boleh meniru keseluruhan set data anda, tanpa mengira jenis beban dan aplikasi. Jika anda menggunakan replika daripada aplikasi, anda perlu mengkonfigurasi setiap aplikasi secara berasingan. Jika terdapat lebih daripada 2 daripadanya, maka ini adalah sangat intensif buruh dan mahal (replikasi permohonan biasanya memerlukan lesen yang berasingan dan bukan percuma untuk setiap permohonan. Tetapi lebih lanjut mengenai perkara di bawah).
- Anda boleh meniru apa sahaja - sebarang aplikasi, sebarang data - dan ia akan sentiasa konsisten. Banyak (kebanyakan) aplikasi tidak mempunyai keupayaan replikasi, dan replika daripada sistem storan adalah satu-satunya cara untuk memberikan perlindungan daripada bencana.
- Tidak perlu membayar lebih untuk fungsi replikasi aplikasi. Sebagai peraturan, ia tidak murah, sama seperti lesen untuk replika sistem storan. Tetapi anda perlu membayar untuk lesen untuk replikasi storan sekali, dan lesen untuk replika aplikasi perlu dibeli untuk setiap aplikasi secara berasingan. Sekiranya terdapat banyak aplikasi sedemikian, maka kosnya cukup besar dan kos lesen untuk replikasi penyimpanan menjadi penurunan dalam baldi.
Argumen TERHADAP replikasi storan:
- Replika melalui aplikasi mempunyai lebih banyak fungsi dari sudut pandangan aplikasi itu sendiri, aplikasi mengetahui datanya dengan lebih baik (jelas), jadi terdapat lebih banyak pilihan untuk bekerja dengan mereka.
- Pengilang sesetengah aplikasi tidak menjamin ketekalan data mereka jika replikasi dilakukan menggunakan alat pihak ketiga. *
* - tesis kontroversi. Sebagai contoh, pengeluar DBMS yang terkenal telah secara rasmi mengisytiharkan untuk masa yang sangat lama bahawa DBMS mereka hanya boleh direplikasi secara normal menggunakan cara mereka, dan replikasi yang lain (termasuk sistem storan) adalah "tidak benar." Tetapi kehidupan telah menunjukkan bahawa ini tidak begitu. Kemungkinan besar (tetapi ini tidak pasti) ini bukanlah percubaan paling jujur untuk menjual lebih banyak lesen kepada pelanggan.
Akibatnya, dalam kebanyakan kes, replikasi dari sistem storan adalah lebih baik, kerana Ini adalah pilihan yang lebih mudah dan lebih murah, tetapi terdapat kes yang rumit apabila fungsi aplikasi tertentu diperlukan, dan ia perlu untuk berfungsi dengan replikasi peringkat aplikasi.
Selesai dengan teori, sekarang amalkan
Kami akan mengkonfigurasi replika dalam makmal kami. Dalam keadaan makmal, kami mencontohi dua pusat data (sebenarnya, dua rak bersebelahan yang nampaknya berada di dalam bangunan yang berbeza). Pendirian terdiri daripada dua sistem storan Enjin N2, yang disambungkan antara satu sama lain dengan kabel optik. Pelayan fizikal yang menjalankan Windows Server 2016 disambungkan kepada kedua-dua sistem storan menggunakan Ethernet 10Gb. Pendiriannya agak mudah, tetapi ini tidak mengubah intipati.
Secara skema ia kelihatan seperti ini:
Secara logiknya, replikasi disusun seperti berikut:
Sekarang mari kita lihat fungsi replikasi yang kita ada sekarang.
Dua mod disokong: tak segerak dan segerak. Adalah logik bahawa mod segerak dihadkan oleh jarak dan saluran komunikasi. Khususnya, mod segerak memerlukan penggunaan gentian sebagai fizik dan 10 Gigabit Ethernet (atau lebih tinggi).
Jarak yang disokong untuk replikasi segerak ialah 40 kilometer, nilai kelewatan saluran optik antara pusat data adalah sehingga 2 milisaat. Secara umum, ia akan berfungsi dengan kelewatan yang besar, tetapi kemudian akan berlaku kelembapan yang kuat semasa rakaman (yang juga logik), jadi jika anda merancang replikasi segerak antara pusat data, anda harus menyemak kualiti optik dan kelewatan.
Keperluan untuk replikasi tak segerak tidak begitu serius. Lebih tepat lagi, mereka tidak ada sama sekali. Sebarang sambungan Ethernet yang berfungsi akan berfungsi.
Pada masa ini, sistem storan AERODISK ENGINE menyokong replikasi untuk peranti blok (LUN) melalui protokol Ethernet (melalui tembaga atau optik). Untuk projek yang memerlukan replikasi melalui fabrik SAN melalui Fiber Channel, kami sedang menambah penyelesaian yang sesuai, tetapi ia belum siap lagi, jadi dalam kes kami, hanya Ethernet.
Replikasi boleh berfungsi antara mana-mana sistem storan siri ENGINE (N1, N2, N4) daripada sistem junior kepada yang lebih lama dan sebaliknya.
Kefungsian kedua-dua mod replikasi adalah sama sepenuhnya. Di bawah adalah butiran lanjut tentang apa yang tersedia:
- Replikasi "satu kepada satu" atau "satu kepada satu", iaitu versi klasik dengan dua pusat data, utama dan sandaran
- Replikasi ialah "satu kepada banyak" atau "satu kepada banyak", i.e. satu LUN boleh direplikasi kepada beberapa sistem storan sekaligus
- Aktifkan, nyahaktifkan dan replikasi "terbalikkan", masing-masing, untuk mendayakan, melumpuhkan atau menukar arah replikasi
- Replikasi tersedia untuk kedua-dua kumpulan RDG (Raid Distributed Group) dan DDP (Dynamic Disk Pool). Walau bagaimanapun, LUN kumpulan RDG hanya boleh direplikasi kepada RDG lain. Begitu juga dengan DDP.
Terdapat banyak lagi ciri-ciri kecil, tetapi tiada tujuan tertentu dalam menyenaraikannya; kami akan menyebutnya semasa kami menyediakannya.
Menyediakan replikasi
Proses persediaan agak mudah dan terdiri daripada tiga peringkat.
- Konfigurasi rangkaian
- Persediaan storan
- Menyediakan peraturan (sambungan) dan pemetaan
Perkara penting dalam menyediakan replikasi ialah dua peringkat pertama harus diulang pada sistem storan jauh, peringkat ketiga - hanya pada yang utama.
Menyediakan sumber rangkaian
Langkah pertama ialah mengkonfigurasi port rangkaian yang melaluinya trafik replikasi akan dihantar. Untuk melakukan ini, anda perlu mendayakan port dan menetapkan alamat IP mereka dalam bahagian Penyesuai bahagian hadapan.
Selepas ini, kita perlu mencipta kolam (dalam kes kami RDG) dan IP maya untuk replikasi (VIP). VIP ialah alamat IP terapung yang terikat dengan dua alamat "fizikal" pengawal storan (port yang baru kami konfigurasikan). Ini akan menjadi antara muka replikasi utama. Anda juga boleh beroperasi bukan dengan VIP, tetapi dengan VLAN, jika anda perlu bekerja dengan trafik yang ditag.
Proses mencipta VIP untuk replika tidak jauh berbeza dengan mencipta VIP untuk I/O (NFS, SMB, iSCSI). Dalam kes ini, kami mencipta VIP biasa (tanpa VLAN), tetapi pastikan anda menunjukkan bahawa ia adalah untuk replikasi (tanpa penunjuk ini kami tidak akan dapat menambah VIP pada peraturan dalam langkah seterusnya).
VIP mesti berada dalam subnet yang sama dengan port IP yang mana ia terapung.
Kami mengulangi tetapan ini pada sistem storan jauh, dengan IP yang berbeza, sudah tentu.
VIP dari sistem storan yang berbeza boleh berada dalam subnet yang berbeza, perkara utama ialah terdapat penghalaan di antara mereka. Dalam kes kami, contoh ini ditunjukkan dengan tepat (192.168.3.XX dan 192.168.2.XX)
Ini melengkapkan penyediaan bahagian rangkaian.
Menyediakan storan
Menyediakan storan untuk replika berbeza daripada biasa hanya kerana kami melakukan pemetaan melalui menu khas "Pemetaan Replikasi". Jika tidak semuanya adalah sama seperti persediaan biasa. Sekarang, mengikut urutan.
Dalam kumpulan R02 yang dibuat sebelum ini, anda perlu mencipta LUN. Mari kita cipta dan panggil ia LUN1.
Kita juga perlu mencipta LUN yang sama pada sistem storan jauh dengan saiz yang sama. Kami cipta. Untuk mengelakkan kekeliruan, mari kita hubungi remote LUN LUN1R
Jika kita perlu mengambil LUN yang sudah wujud, maka semasa menyediakan replika, kita perlu menyahlekap LUN produktif ini daripada hos, dan hanya mencipta LUN kosong dengan saiz yang sama pada sistem storan jauh.
Persediaan storan selesai, mari kita teruskan untuk membuat peraturan replikasi.
Menyediakan peraturan replikasi atau pautan replikasi
Selepas mencipta LUN pada sistem storan, yang akan menjadi yang utama pada masa ini, kami mengkonfigurasi peraturan replikasi LUN1 pada sistem storan 1 kepada LUN1R pada sistem storan 2.
Tetapan dibuat dalam menu "Replikasi jauh".
Mari buat peraturan. Untuk melakukan ini, anda perlu menentukan penerima replika. Di sana kami juga menetapkan nama sambungan dan jenis replikasi (synchronous atau asynchronous).
Dalam medan "sistem jauh" kami menambah sistem storan kami2. Untuk menambah, anda perlu menggunakan sistem penyimpanan IP pengurusan (MGR) dan nama LUN jauh yang akan kami lakukan replikasi (dalam kes kami, LUN1R). IP Kawalan diperlukan hanya pada peringkat menambah sambungan; trafik replikasi tidak akan dihantar melaluinya; VIP yang telah dikonfigurasikan sebelum ini akan digunakan untuk ini.
Sudah pada peringkat ini kita boleh menambah lebih daripada satu sistem jauh untuk topologi "satu kepada banyak": klik butang "tambah nod", seperti dalam rajah di bawah.
Dalam kes kami, hanya terdapat satu sistem jauh, jadi kami mengehadkan diri kami untuk ini.
Peraturan sudah sedia. Sila ambil perhatian bahawa ia ditambahkan secara automatik pada semua peserta replikasi (dalam kes kami terdapat dua daripada mereka). Anda boleh membuat seberapa banyak peraturan sedemikian yang anda suka, untuk sebarang bilangan LUN dan dalam sebarang arah. Sebagai contoh, untuk mengimbangi beban, kita boleh meniru sebahagian daripada LUN daripada sistem storan 1 kepada sistem storan 2, dan bahagian lain, sebaliknya, daripada sistem storan 2 kepada sistem storan 1.
Sistem storan1. Sejurus selepas penciptaan, penyegerakan bermula.
Sistem storan2. Kami melihat peraturan yang sama, tetapi penyegerakan telah pun tamat.
LUN1 pada sistem storan 1 adalah dalam peranan Utama, iaitu, ia aktif. LUN1R pada sistem storan 2 berperanan sebagai Sekunder, iaitu, ia dalam keadaan siap sedia sekiranya sistem storan 1 gagal.
Sekarang kita boleh menyambungkan LUN kita kepada hos.
Kami akan menyambung melalui iSCSI, walaupun ia juga boleh dilakukan melalui FC. Menyediakan pemetaan melalui iSCSI LUN dalam replika boleh dikatakan tidak berbeza daripada senario biasa, jadi kami tidak akan mempertimbangkan perkara ini secara terperinci di sini. Jika ada, proses ini diterangkan dalam artikel "'.
Satu-satunya perbezaan ialah kami membuat pemetaan dalam menu "Pemetaan Replikasi".
Kami menyediakan pemetaan dan memberikan LUN kepada hos. Tuan rumah melihat LUN.
Kami memformatkannya ke dalam sistem fail tempatan.
Itu sahaja, persediaan telah selesai. Ujian akan datang seterusnya.
Ujian
Kami akan menguji tiga senario utama.
- Penukaran peranan biasa Menengah > Utama. Penukaran peranan tetap diperlukan sekiranya, sebagai contoh, kami perlu melakukan beberapa operasi pencegahan di pusat data utama dan pada masa ini, agar data tersedia, kami memindahkan beban ke pusat data sandaran.
- Penukaran peranan kecemasan Menengah > Utama (kegagalan pusat data). Ini ialah senario utama yang wujudnya replikasi, yang boleh membantu mengatasi kegagalan pusat data yang lengkap tanpa menghentikan syarikat untuk tempoh yang panjang.
- Pecahan saluran komunikasi antara pusat data. Menyemak kelakuan betul dua sistem storan dalam keadaan di mana atas sebab tertentu saluran komunikasi antara pusat data tidak tersedia (contohnya, jengkaut digali di tempat yang salah dan memecahkan optik gelap).
Pertama, kami akan mula menulis data ke LUN kami (menulis fail dengan data rawak). Kami segera melihat bahawa saluran komunikasi antara sistem storan sedang digunakan. Ini mudah difahami jika anda membuka pemantauan beban port yang bertanggungjawab untuk replikasi.
Kedua-dua sistem storan kini mempunyai data "berguna", kami boleh memulakan ujian.
Untuk berjaga-jaga, mari kita lihat jumlah cincang salah satu fail dan tuliskannya.
Pertukaran peranan tetap
Operasi menukar peranan (mengubah arah replikasi) boleh dilakukan dengan mana-mana sistem storan, tetapi anda masih perlu pergi ke kedua-duanya, kerana anda perlu melumpuhkan pemetaan pada Utama dan mendayakannya pada Menengah (yang akan menjadi Utama ).
Mungkin persoalan yang munasabah kini timbul: mengapa tidak mengautomasikan ini? Jawapannya ialah: ia mudah, replikasi ialah cara mudah untuk berdaya tahan bencana, berdasarkan operasi manual semata-mata. Untuk mengautomasikan operasi ini, terdapat mod metrocluster; ia automatik sepenuhnya, tetapi konfigurasinya jauh lebih rumit. Kami akan menulis tentang penyediaan metrocluster dalam artikel seterusnya.
Pada sistem storan utama, kami melumpuhkan pemetaan untuk memastikan rakaman berhenti.
Kemudian pada salah satu sistem storan (tidak kira, pada utama atau sandaran) dalam menu "Replikasi jauh", pilih sambungan REPL1 kami dan klik "Tukar peranan".
Selepas beberapa saat, LUN1R (sistem storan sandaran) menjadi Utama.
Kami memetakan LUN1R dengan sistem storan2.
Selepas ini, pemacu E: kami dilampirkan secara automatik pada hos, hanya kali ini ia "tiba" dari LUN1R.
Untuk berjaga-jaga, kami membandingkan jumlah cincangan.
Secara identik. Ujian lulus.
Failover. Kegagalan pusat data
Pada masa ini, sistem storan utama selepas penukaran biasa ialah sistem storan 2 dan LUN1R, masing-masing. Untuk meniru kemalangan, kami akan mematikan kuasa pada kedua-dua pengawal storan2.
Tiada lagi akses kepadanya.
Mari lihat apa yang berlaku pada sistem storan 1 (yang sandaran pada masa ini).
Kami melihat bahawa LUN Utama (LUN1R) tidak tersedia. Mesej ralat muncul dalam log, dalam panel maklumat, dan juga dalam peraturan replikasi itu sendiri. Sehubungan itu, data daripada hos tidak tersedia pada masa ini.
Tukar peranan LUN1 kepada Utama.
Saya sedang membuat pemetaan kepada hos.
Pastikan pemacu E muncul pada hos.
Kami menyemak cincang.
Semuanya baik-baik sahaja. Sistem storan berjaya bertahan daripada kejatuhan pusat data, yang aktif. Anggaran masa yang kami habiskan untuk menyambungkan "pembalikan" replikasi dan menyambungkan LUN dari pusat data sandaran ialah kira-kira 3 minit. Adalah jelas bahawa dalam pengeluaran sebenar semuanya jauh lebih rumit, dan sebagai tambahan kepada tindakan dengan sistem storan, anda perlu melakukan lebih banyak operasi pada rangkaian, pada hos, dalam aplikasi. Dan dalam kehidupan tempoh masa ini akan lebih lama.
Di sini saya ingin menulis bahawa segala-galanya, ujian telah berjaya diselesaikan, tetapi jangan tergesa-gesa. Sistem storan utama ialah "berbohong", kita tahu bahawa apabila ia "jatuh", ia berada dalam peranan Utama. Apa yang berlaku jika ia tiba-tiba dihidupkan? Akan ada dua peranan Utama, yang sama dengan rasuah data? Jom semak sekarang.
Mari tiba-tiba hidupkan sistem storan asas.
Ia dimuatkan selama beberapa minit dan kemudian kembali ke perkhidmatan selepas penyegerakan singkat, tetapi dalam peranan Menengah.
Semuanya baik. Split-brain tidak berlaku. Kami memikirkan perkara ini, dan sentiasa selepas kejatuhan sistem storan meningkat kepada peranan Menengah, tidak kira apa peranannya dalam "semasa hidup." Sekarang kita boleh mengatakan dengan pasti bahawa ujian kegagalan pusat data berjaya.
Kegagalan saluran komunikasi antara pusat data
Tugas utama ujian ini adalah untuk memastikan bahawa sistem storan tidak mula bertindak pelik jika ia kehilangan saluran komunikasi antara dua sistem storan buat sementara waktu dan kemudian muncul semula.
Jadi. Kami mencabut wayar antara sistem penyimpanan (mari bayangkan bahawa ia digali oleh jengkaut).
Pada Sekolah Rendah kita melihat bahawa tiada kaitan dengan Menengah.
Pada Menengah kita melihat bahawa tiada kaitan dengan Sekolah Rendah.
Semuanya berfungsi dengan baik, dan kami terus menulis data ke sistem storan utama, iaitu, mereka dijamin berbeza daripada sandaran, iaitu, mereka telah "berpisah".
Dalam beberapa minit kami "membaiki" saluran komunikasi. Sebaik sahaja sistem storan melihat antara satu sama lain, penyegerakan data diaktifkan secara automatik. Tiada apa-apa yang diperlukan daripada pentadbir di sini.
Selepas beberapa lama, penyegerakan selesai.
Sambungan telah dipulihkan, kehilangan saluran komunikasi tidak menyebabkan sebarang situasi kecemasan, dan selepas menghidupkan, penyegerakan berlaku secara automatik.
Penemuan
Kami menganalisis teori - apa yang diperlukan dan mengapa, di mana kebaikan dan di mana keburukannya. Kemudian kami menyediakan replikasi segerak antara dua sistem storan.
Seterusnya, ujian asas telah dijalankan untuk pensuisan biasa, kegagalan pusat data dan kegagalan saluran komunikasi. Dalam semua kes, sistem storan berfungsi dengan baik. Tiada kehilangan data dan operasi pentadbiran disimpan pada tahap minimum untuk senario manual.
Lain kali kami akan merumitkan keadaan dan menunjukkan cara semua logik ini berfungsi dalam metrocluster automatik dalam mod aktif-aktif, iaitu, apabila kedua-dua sistem storan adalah utama, dan tingkah laku sekiranya berlaku kegagalan sistem storan adalah automatik sepenuhnya.
Sila tulis komen, kami akan gembira menerima kritikan yang baik dan nasihat praktikal.
Sehingga lain kali.
Sumber: www.habr.com