Halo, pembaca Habr! Topik artikel ini adalah implementasi alat pemulihan bencana dalam sistem penyimpanan AERODISK Engine. Awalnya kami ingin menulis dalam satu artikel tentang kedua alat tersebut: replikasi dan metrocluster, namun sayangnya artikel tersebut ternyata terlalu panjang, sehingga kami membagi artikel tersebut menjadi dua bagian. Mari beralih dari yang sederhana ke yang rumit. Pada artikel ini, kami akan menyiapkan dan menguji replikasi sinkron - kami akan membuang satu pusat data, dan juga memutus saluran komunikasi antar pusat data dan melihat apa yang terjadi.
Pelanggan kami sering menanyakan berbagai pertanyaan kepada kami tentang replikasi, jadi sebelum melanjutkan ke penyiapan dan pengujian implementasi replika, kami akan memberi tahu Anda sedikit tentang apa itu replikasi dalam penyimpanan.
Sedikit teori
Replikasi dalam sistem penyimpanan merupakan proses berkelanjutan untuk memastikan identitas data pada beberapa sistem penyimpanan secara bersamaan. Secara teknis, replikasi dilakukan dengan dua cara.
Replikasi sinkron – ini menyalin data dari sistem penyimpanan utama ke sistem penyimpanan cadangan, diikuti dengan konfirmasi wajib dari kedua sistem penyimpanan bahwa data telah dicatat dan dikonfirmasi. Setelah konfirmasi dari kedua sisi (kedua sistem penyimpanan) maka data dianggap telah direkam dan dapat digunakan. Hal ini memastikan jaminan identitas data pada semua sistem penyimpanan yang berpartisipasi dalam replika.
Keuntungan dari metode ini:
- Data selalu identik di semua sistem penyimpanan
Cons:
- Tingginya biaya solusi (saluran komunikasi cepat, serat optik mahal, transceiver gelombang panjang, dll.)
- Pembatasan jarak (dalam beberapa puluh kilometer)
- Tidak ada perlindungan terhadap kerusakan data logis (jika data rusak (disengaja atau tidak sengaja) pada sistem penyimpanan utama, maka secara otomatis dan instan akan rusak pada sistem penyimpanan cadangan, karena data selalu identik (itulah paradoksnya)
Replikasi asinkron – ini juga menyalin data dari sistem penyimpanan utama ke sistem penyimpanan cadangan, tetapi dengan penundaan tertentu dan tanpa perlu konfirmasi penulisan di sisi lain. Anda dapat bekerja dengan data segera setelah merekamnya ke sistem penyimpanan utama, dan pada sistem penyimpanan cadangan, data akan tersedia setelah beberapa waktu. Identitas data dalam kasus ini tentu saja tidak terjamin sama sekali. Data pada sistem penyimpanan cadangan selalu sedikit “masa lalu”.
Kelebihan replikasi asinkron:
- Solusi berbiaya rendah (saluran komunikasi apa pun, optik opsional)
- Tidak ada batasan jarak
- Pada sistem penyimpanan cadangan, data tidak memburuk jika rusak pada sistem penyimpanan utama (setidaknya untuk beberapa waktu); jika data rusak, Anda selalu dapat menghentikan replika untuk mencegah kerusakan data pada sistem penyimpanan cadangan
Cons:
- Data di pusat data yang berbeda selalu tidak sama
Oleh karena itu, pilihan mode replikasi bergantung pada tujuan bisnis. Jika penting bagi Anda bahwa pusat data cadangan berisi data yang sama persis dengan pusat data utama (yaitu persyaratan bisnis untuk RPO = 0), maka Anda harus mengeluarkan uang tunai dan menghadapi batasan sinkron. replika. Dan jika penundaan dalam status data dapat diterima atau tidak ada uang, maka Anda pasti perlu menggunakan metode asynchronous.
Mari kita juga menyoroti mode seperti itu (lebih tepatnya, topologi) secara terpisah sebagai metrocluster. Dalam mode metrocluster, replikasi sinkron digunakan, tetapi, tidak seperti replika biasa, metrocluster memungkinkan kedua sistem penyimpanan beroperasi dalam mode aktif. Itu. Anda tidak memiliki pemisahan antara pusat data aktif dan siaga. Aplikasi bekerja secara bersamaan dengan dua sistem penyimpanan, yang secara fisik berlokasi di pusat data yang berbeda. Waktu henti jika terjadi kecelakaan pada topologi seperti itu sangat kecil (RTO, biasanya beberapa menit). Dalam artikel ini kami tidak akan mempertimbangkan implementasi metrocluster kami, karena ini adalah topik yang sangat besar dan luas, jadi kami akan menyediakan artikel terpisah berikutnya, sebagai kelanjutan dari artikel ini.
Selain itu, sering kali, ketika kita berbicara tentang replikasi menggunakan sistem penyimpanan, banyak orang memiliki pertanyaan yang masuk akal: > “Banyak aplikasi memiliki alat replikasinya sendiri, mengapa menggunakan replikasi pada sistem penyimpanan? Apakah lebih baik atau lebih buruk?
Tidak ada jawaban yang jelas di sini, jadi inilah argumen UNTUK dan KONTRA:
Argumen UNTUK replikasi penyimpanan:
- Kesederhanaan solusi. Dengan satu alat, Anda dapat mereplikasi seluruh kumpulan data, apa pun jenis beban dan aplikasinya. Jika Anda menggunakan replika dari aplikasi, Anda harus mengonfigurasi setiap aplikasi secara terpisah. Jika ada lebih dari 2, maka ini sangat memakan waktu dan mahal (replikasi aplikasi biasanya memerlukan lisensi terpisah dan tidak gratis untuk setiap aplikasi. Namun lebih lanjut tentang itu di bawah).
- Anda dapat mereplikasi apa pun – aplikasi apa pun, data apa pun – dan itu akan selalu konsisten. Banyak (sebagian besar) aplikasi tidak memiliki kemampuan replikasi, dan replika dari sistem penyimpanan adalah satu-satunya cara untuk memberikan perlindungan dari bencana.
- Tidak perlu membayar lebih untuk fungsionalitas replikasi aplikasi. Biasanya, ini tidak murah, seperti halnya lisensi untuk replika sistem penyimpanan. Namun Anda harus membayar lisensi replikasi penyimpanan satu kali, dan lisensi replika aplikasi perlu dibeli untuk setiap aplikasi secara terpisah. Jika ada banyak aplikasi seperti itu, maka biayanya cukup mahal dan biaya lisensi untuk replikasi penyimpanan menjadi sangat murah.
Argumen MELAWAN replikasi penyimpanan:
- Replika melalui aplikasi memiliki lebih banyak fungsi dalam hal aplikasi itu sendiri, aplikasi mengetahui datanya lebih baik (tentu saja), sehingga ada lebih banyak opsi untuk bekerja dengannya.
- Produsen beberapa aplikasi tidak menjamin konsistensi datanya jika replikasi dilakukan menggunakan alat pihak ketiga. *
* - tesis kontroversial. Misalnya, produsen DBMS terkenal telah lama menyatakan secara resmi bahwa DBMS mereka hanya dapat direplikasi secara normal menggunakan sarana mereka, dan replikasi lainnya (termasuk sistem penyimpanan) “tidak benar.” Namun kehidupan telah menunjukkan bahwa hal ini tidak benar. Kemungkinan besar (tetapi ini belum pasti) ini bukanlah upaya paling jujur untuk menjual lebih banyak lisensi kepada pelanggan.
Hasilnya, dalam banyak kasus, replikasi dari sistem penyimpanan lebih baik, karena Ini adalah opsi yang lebih sederhana dan lebih murah, namun ada kasus rumit ketika fungsionalitas aplikasi tertentu diperlukan, dan perlu bekerja dengan replikasi tingkat aplikasi.
Selesai teori, sekarang praktik
Kami akan mengonfigurasi replika di lab kami. Dalam kondisi laboratorium, kami meniru dua pusat data (sebenarnya, dua rak berdekatan yang tampaknya berada di gedung berbeda). Dudukannya terdiri dari dua sistem penyimpanan Engine N2, yang dihubungkan satu sama lain melalui kabel optik. Server fisik yang menjalankan Windows Server 2016 terhubung ke kedua sistem penyimpanan menggunakan Ethernet 10Gb. Standnya cukup sederhana, namun tidak mengubah esensinya.
Secara skematis tampilannya seperti ini:
Logikanya, replikasi disusun sebagai berikut:
Sekarang mari kita lihat fungsi replikasi yang kita miliki sekarang.
Dua mode yang didukung: asinkron dan sinkron. Adalah logis bahwa mode sinkron dibatasi oleh jarak dan saluran komunikasi. Secara khusus, mode sinkron memerlukan penggunaan serat sebagai fisika dan 10 Gigabit Ethernet (atau lebih tinggi).
Jarak yang didukung untuk replikasi sinkron adalah 40 kilometer, nilai penundaan saluran optik antar pusat data hingga 2 milidetik. Secara umum, ini akan bekerja dengan penundaan yang besar, tetapi kemudian akan ada perlambatan yang parah selama perekaman (yang juga logis), jadi jika Anda merencanakan replikasi sinkron antar pusat data, Anda harus memeriksa kualitas optik dan penundaannya.
Persyaratan untuk replikasi asinkron tidak terlalu serius. Lebih tepatnya, mereka tidak ada sama sekali. Koneksi Ethernet apa pun yang berfungsi bisa digunakan.
Saat ini, sistem penyimpanan AERODISK ENGINE mendukung replikasi untuk perangkat blok (LUN) melalui protokol Ethernet (melalui tembaga atau optik). Untuk proyek yang memerlukan replikasi melalui fabric SAN melalui Fibre Channel, kami saat ini menambahkan solusi yang sesuai, namun belum siap, jadi dalam kasus kami, hanya Ethernet.
Replikasi dapat bekerja antara sistem penyimpanan seri ENGINE apa pun (N1, N2, N4) dari sistem junior ke sistem lama dan sebaliknya.
Fungsionalitas kedua mode replikasi sepenuhnya identik. Di bawah ini rincian lebih lanjut tentang apa yang tersedia:
- Replikasi “satu ke satu” atau “satu ke satu”, yaitu versi klasik dengan dua pusat data, pusat data utama dan cadangan
- Replikasi adalah “satu ke banyak” atau “satu ke banyak”, yaitu. satu LUN dapat direplikasi ke beberapa sistem penyimpanan sekaligus
- Mengaktifkan, menonaktifkan, dan “membalikkan” replikasi, masing-masing, untuk mengaktifkan, menonaktifkan, atau mengubah arah replikasi
- Replikasi tersedia untuk kumpulan RDG (Raid Distributed Group) dan DDP (Dynamic Disk Pool). Namun, LUN dari kumpulan RDG hanya dapat direplikasi ke RDG lain. Begitu pula dengan DDP.
Masih banyak lagi fitur kecil lainnya, namun tidak ada gunanya mencantumkannya; kami akan menyebutkannya saat kami menyiapkannya.
Menyiapkan replikasi
Proses setupnya cukup sederhana dan terdiri dari tiga tahap.
- Pengaturan jaringan
- Pengaturan penyimpanan
- Menyiapkan aturan (koneksi) dan pemetaan
Poin penting dalam menyiapkan replikasi adalah bahwa dua tahap pertama harus diulangi pada sistem penyimpanan jarak jauh, tahap ketiga - hanya pada sistem utama.
Menyiapkan sumber daya jaringan
Langkah pertama adalah mengkonfigurasi port jaringan yang akan digunakan untuk mengirimkan lalu lintas replikasi. Untuk melakukan ini, Anda perlu mengaktifkan port dan mengatur alamat IP-nya di bagian Adaptor front-end.
Setelah ini, kita perlu membuat kumpulan (dalam kasus kita RDG) dan IP virtual untuk replikasi (VIP). VIP adalah alamat IP mengambang yang terikat pada dua alamat “fisik” pengontrol penyimpanan (port yang baru saja kita konfigurasikan). Ini akan menjadi antarmuka replikasi utama. Anda juga dapat beroperasi bukan dengan VIP, tetapi dengan VLAN, jika Anda perlu bekerja dengan lalu lintas yang diberi tag.
Proses pembuatan VIP untuk replika tidak jauh berbeda dengan pembuatan VIP untuk I/O (NFS, SMB, iSCSI). Dalam hal ini, kami membuat VIP biasa (tanpa VLAN), tetapi pastikan untuk menunjukkan bahwa itu untuk replikasi (tanpa penunjuk ini kami tidak akan dapat menambahkan VIP ke aturan pada langkah berikutnya).
VIP harus berada dalam subnet yang sama dengan port IP tempat ia berada.
Kami mengulangi pengaturan ini pada sistem penyimpanan jarak jauh, dengan IP yang berbeda tentunya.
VIP dari sistem penyimpanan yang berbeda dapat berada di subnet yang berbeda, yang utama adalah ada perutean di antara mereka. Dalam kasus kami, contoh ini persis ditampilkan (192.168.3.XX dan 192.168.2.XX)
Ini menyelesaikan persiapan bagian jaringan.
Menyiapkan penyimpanan
Menyiapkan penyimpanan untuk replika berbeda dari biasanya hanya saja kita melakukan pemetaan melalui menu khusus “Pemetaan Replikasi”. Kalau tidak, semuanya sama seperti pengaturan normal. Sekarang, secara berurutan.
Di kumpulan R02 yang dibuat sebelumnya, Anda perlu membuat LUN. Mari kita buat dan beri nama LUN1.
Kita juga perlu membuat LUN yang sama pada sistem penyimpanan jarak jauh dengan ukuran yang sama. Kami menciptakan. Untuk menghindari kebingungan, sebut saja LUN LUN1R jarak jauh
Jika kita perlu mengambil LUN yang sudah ada, maka saat menyiapkan replikanya, kita perlu melepas LUN produktif ini dari host, dan cukup membuat LUN kosong dengan ukuran yang sama pada sistem penyimpanan jarak jauh.
Penyiapan penyimpanan selesai, mari beralih ke pembuatan aturan replikasi.
Menyiapkan aturan replikasi atau tautan replikasi
Setelah membuat LUN pada sistem penyimpanan, yang akan menjadi LUN utama saat ini, kami mengonfigurasi aturan replikasi LUN1 pada sistem penyimpanan 1 ke LUN1R pada sistem penyimpanan 2.
Pengaturan dilakukan di menu “Replikasi jarak jauh”.
Mari buat aturan. Untuk melakukan ini, Anda perlu menentukan penerima replika. Di sana kami juga mengatur nama koneksi dan jenis replikasi (sinkron atau asinkron).
Di bidang "sistem jarak jauh" kami menambahkan sistem penyimpanan kami2. Untuk menambahkannya, Anda perlu menggunakan sistem penyimpanan IP manajemen (MGR) dan nama LUN jarak jauh tempat kami akan melakukan replikasi (dalam kasus kami, LUN1R). IP kontrol diperlukan hanya pada tahap penambahan koneksi; lalu lintas replikasi tidak akan ditransmisikan melaluinya; VIP yang dikonfigurasi sebelumnya akan digunakan untuk ini.
Pada tahap ini kita sudah dapat menambahkan lebih dari satu sistem jarak jauh untuk topologi “satu ke banyak”: klik tombol “tambah node”, seperti pada gambar di bawah ini.
Dalam kasus kami, hanya ada satu sistem jarak jauh, jadi kami membatasi diri pada hal ini.
Aturannya sudah siap. Harap dicatat bahwa ini ditambahkan secara otomatis pada semua peserta replikasi (dalam kasus kami ada dua di antaranya). Anda dapat membuat aturan sebanyak yang Anda suka, untuk sejumlah LUN berapa pun dan ke arah mana pun. Misalnya, untuk menyeimbangkan beban, kita dapat mereplikasi sebagian LUN dari sistem penyimpanan 1 ke sistem penyimpanan 2, dan sebaliknya, bagian lainnya dari sistem penyimpanan 2 ke sistem penyimpanan 1.
Sistem penyimpanan1. Segera setelah pembuatan, sinkronisasi dimulai.
Sistem penyimpanan2. Kami melihat aturan yang sama, tetapi sinkronisasi telah berakhir.
LUN1 pada sistem penyimpanan 1 berada pada peran Utama, yaitu aktif. LUN1R pada sistem penyimpanan 2 berperan sebagai Sekunder, yaitu siaga jika sistem penyimpanan 1 mengalami kegagalan.
Sekarang kita dapat menghubungkan LUN kita ke host.
Kami akan terhubung melalui iSCSI, meskipun bisa juga melalui FC. Menyiapkan pemetaan melalui iSCSI LUN dalam replika praktis tidak berbeda dengan skenario biasa, jadi kami tidak akan membahasnya secara detail di sini. Jika ada, proses ini dijelaskan dalam artikel “'.
Satu-satunya perbedaan adalah kita membuat pemetaan di menu “Pemetaan Replikasi”.
Kami menyiapkan pemetaan dan memberikan LUN kepada tuan rumah. Tuan rumah melihat LUN.
Kami memformatnya ke dalam sistem file lokal.
Itu saja, pengaturannya selesai. Ujian akan datang berikutnya.
Pengujian
Kami akan menguji tiga skenario utama.
- Peralihan peran reguler Sekunder > Utama. Peralihan peran secara teratur diperlukan jika, misalnya, kita perlu melakukan beberapa operasi pencegahan di pusat data utama dan selama waktu ini, agar data tersedia, kita mentransfer beban ke pusat data cadangan.
- Peralihan peran darurat Sekunder > Utama (kegagalan pusat data). Ini adalah skenario utama dimana terdapat replikasi, yang dapat membantu bertahan dari kegagalan pusat data tanpa menghentikan perusahaan untuk jangka waktu yang lama.
- Rusaknya saluran komunikasi antar pusat data. Memeriksa perilaku yang benar dari dua sistem penyimpanan dalam kondisi di mana karena alasan tertentu saluran komunikasi antara pusat data tidak tersedia (misalnya, ekskavator menggali di tempat yang salah dan merusak optik gelap).
Pertama, kita akan mulai menulis data ke LUN kita (menulis file dengan data acak). Kami segera melihat bahwa saluran komunikasi antar sistem penyimpanan sedang digunakan. Ini mudah dipahami jika Anda membuka pemantauan beban port yang bertanggung jawab untuk replikasi.
Kedua sistem penyimpanan sekarang memiliki data yang “berguna”, kita dapat memulai pengujian.
Untuk berjaga-jaga, mari kita lihat jumlah hash dari salah satu file dan menuliskannya.
Peralihan peran secara teratur
Pengoperasian peralihan peran (mengubah arah replikasi) dapat dilakukan dengan sistem penyimpanan apa pun, namun Anda tetap harus beralih ke keduanya, karena Anda harus menonaktifkan pemetaan di Primer, dan mengaktifkannya di Sekunder (yang akan menjadi Primer ).
Mungkin sekarang muncul pertanyaan yang masuk akal: mengapa tidak mengotomatiskannya? Jawabannya: sederhana saja, replikasi adalah cara sederhana untuk ketahanan bencana, hanya berdasarkan operasi manual. Untuk mengotomatiskan operasi ini, terdapat mode metrocluster; mode ini sepenuhnya otomatis, namun konfigurasinya jauh lebih rumit. Kami akan menulis tentang menyiapkan metrocluster di artikel berikutnya.
Pada sistem penyimpanan utama, kami menonaktifkan pemetaan untuk memastikan perekaman berhenti.
Kemudian pada salah satu sistem penyimpanan (tidak masalah, utama atau cadangan) di menu “Replikasi jarak jauh”, pilih koneksi REPL1 kami dan klik “Ubah peran”.
Setelah beberapa detik, LUN1R (sistem penyimpanan cadangan) menjadi Utama.
Kami memetakan LUN1R dengan sistem penyimpanan2.
Setelah ini, drive E: kami secara otomatis terpasang ke host, hanya saja kali ini “tiba” dari LUN1R.
Untuk berjaga-jaga, kami membandingkan jumlah hash.
Secara identik. Tes berlalu.
kegagalan. Kegagalan pusat data
Saat ini, sistem penyimpanan utama setelah peralihan reguler masing-masing adalah sistem penyimpanan 2 dan LUN1R. Untuk meniru kecelakaan, kami akan mematikan daya pada kedua pengontrol penyimpanan2.
Tidak ada lagi akses ke sana.
Mari kita lihat apa yang terjadi pada sistem penyimpanan 1 (yang saat ini merupakan cadangan).
Kami melihat bahwa LUN Primer (LUN1R) tidak tersedia. Pesan kesalahan muncul di log, di panel informasi, dan juga di aturan replikasi itu sendiri. Oleh karena itu, data dari host saat ini tidak tersedia.
Ubah peran LUN1 menjadi Utama.
Saya sedang melakukan pemetaan ke host.
Pastikan drive E muncul di host.
Kami memeriksa hashnya.
Semuanya baik-baik saja. Sistem penyimpanan berhasil bertahan dari jatuhnya pusat data yang aktif. Perkiraan waktu yang kami habiskan untuk menghubungkan “pembalikan” replikasi dan menghubungkan LUN dari pusat data cadangan adalah sekitar 3 menit. Jelas bahwa dalam produksi nyata semuanya jauh lebih rumit, dan selain tindakan dengan sistem penyimpanan, Anda perlu melakukan lebih banyak operasi di jaringan, di host, di aplikasi. Dan dalam hidup, periode waktu ini akan lebih lama.
Di sini saya ingin menulis bahwa semuanya, tes telah berhasil diselesaikan, tapi jangan terburu-buru. Sistem penyimpanan utama “berbohong”, kita tahu bahwa ketika “jatuh”, ia berada dalam peran Utama. Apa yang terjadi jika tiba-tiba menyala? Akan ada dua peran utama, mana yang sama dengan korupsi data? Mari kita periksa sekarang.
Mari kita tiba-tiba mengaktifkan sistem penyimpanan yang mendasarinya.
Ini memuat selama beberapa menit dan kemudian kembali ke layanan setelah sinkronisasi singkat, tetapi dalam peran Sekunder.
Semuanya baik-baik saja. Split-otak tidak terjadi. Kami memikirkan hal ini, dan setelah sistem penyimpanan terjatuh, ia selalu naik ke peran Sekunder, terlepas dari peran apa yang dimainkannya “selama masa pakainya”. Sekarang kita dapat mengatakan dengan pasti bahwa uji kegagalan pusat data berhasil.
Kegagalan saluran komunikasi antar pusat data
Tugas utama pengujian ini adalah memastikan bahwa sistem penyimpanan tidak mulai bertingkah aneh jika kehilangan saluran komunikasi untuk sementara antara dua sistem penyimpanan dan kemudian muncul kembali.
Jadi. Kami melepaskan kabel di antara sistem penyimpanan (bayangkan kabel tersebut digali oleh ekskavator).
Di Pratama kita melihat bahwa tidak ada hubungan dengan Sekunder.
Di Sekunder kita melihat bahwa tidak ada hubungan dengan Pratama.
Semuanya berfungsi dengan baik, dan kami terus menulis data ke sistem penyimpanan utama, yang dijamin berbeda dari yang cadangan, yaitu "terpisah".
Dalam beberapa menit kami “memperbaiki” saluran komunikasi. Segera setelah sistem penyimpanan saling bertemu, sinkronisasi data diaktifkan secara otomatis. Tidak ada yang diperlukan dari administrator di sini.
Setelah beberapa waktu, sinkronisasi selesai.
Koneksi dipulihkan, hilangnya saluran komunikasi tidak menyebabkan situasi darurat, dan setelah dinyalakan, sinkronisasi terjadi secara otomatis.
Temuan
Kami menganalisis teorinya - apa yang dibutuhkan dan mengapa, di mana kelebihannya dan di mana kekurangannya. Kemudian kami menyiapkan replikasi sinkron antara dua sistem penyimpanan.
Selanjutnya, pengujian dasar dilakukan untuk peralihan normal, kegagalan pusat data, dan kegagalan saluran komunikasi. Secara keseluruhan, sistem penyimpanan bekerja dengan baik. Tidak ada kehilangan data dan operasi administratif dijaga seminimal mungkin untuk skenario manual.
Lain kali kami akan memperumit situasi dan menunjukkan bagaimana semua logika ini bekerja dalam metrocluster otomatis dalam mode aktif-aktif, yaitu, ketika kedua sistem penyimpanan adalah yang utama, dan perilaku jika terjadi kegagalan sistem penyimpanan sepenuhnya otomatis.
Silakan tulis komentar, kami akan dengan senang hati menerima kritik yang masuk akal dan saran praktis.
Sampai jumpa lagi.
Sumber: www.habr.com