Hei Habr!
Setelah liburan Tahun Baru, kami meluncurkan kembali cloud tahan bencana yang berbasis di dua lokasi. Hari ini kami akan memberi tahu Anda cara kerjanya dan menunjukkan apa yang terjadi pada mesin virtual klien ketika elemen individual dari cluster gagal dan seluruh situs mogok (spoiler – semuanya baik-baik saja).
Sistem penyimpanan cloud tahan bencana di situs OST.
Apa yang ada di dalamnya
Di bagian dalamnya, cluster ini memiliki server Cisco UCS dengan hypervisor VMware ESXi, dua sistem penyimpanan INFINIDAT InfiniBox F2240, peralatan jaringan Cisco Nexus, serta switch Brocade SAN. Cluster ini dibagi menjadi dua lokasi - OST dan NORD, yaitu setiap pusat data memiliki seperangkat peralatan yang identik. Sebenarnya inilah yang membuatnya tahan bencana.
Dalam satu situs, elemen utama juga diduplikasi (host, switch SAN, jaringan).
Kedua lokasi tersebut dihubungkan melalui rute serat optik khusus, yang juga dicadangkan.
Beberapa kata tentang sistem penyimpanan. Kami membangun versi pertama cloud tahan bencana di NetApp. Di sini kami memilih INFINIDAT, dan inilah alasannya:
- Opsi replikasi aktif-aktif. Hal ini memungkinkan mesin virtual untuk tetap beroperasi meskipun salah satu sistem penyimpanan gagal total. Saya akan memberi tahu Anda lebih banyak tentang replikasi nanti.
- Tiga pengontrol disk untuk meningkatkan toleransi kesalahan sistem. Biasanya ada dua.
- Solusi siap pakai. Kami menerima rak yang sudah dirakit sebelumnya yang hanya perlu dihubungkan ke jaringan dan dikonfigurasi.
- Dukungan teknis yang penuh perhatian. Insinyur INFINIDAT terus-menerus menganalisis log dan peristiwa sistem penyimpanan, menginstal versi firmware baru, dan membantu konfigurasi.
Berikut beberapa foto saat membongkar:
Cara kerjanya
Cloud itu sendiri sudah toleran terhadap kesalahan. Ini melindungi klien dari kegagalan perangkat keras dan perangkat lunak tunggal. Tahan bencana akan membantu melindungi dari kegagalan besar dalam satu situs: misalnya, kegagalan sistem penyimpanan (atau cluster SDS, yang cukup sering terjadi 🙂), kesalahan besar dalam jaringan penyimpanan, dll. Dan yang paling penting: cloud seperti itu menyelamatkan ketika seluruh situs menjadi tidak dapat diakses karena kebakaran, pemadaman listrik, pengambilalihan perampok, atau pendaratan alien.
Dalam semua kasus ini, mesin virtual klien terus bekerja, dan inilah alasannya.
Desain cluster dirancang agar setiap host ESXi dengan mesin virtual klien dapat mengakses salah satu dari dua sistem penyimpanan. Jika sistem penyimpanan di situs OST gagal, mesin virtual akan terus bekerja: host yang menjalankannya akan mengakses sistem penyimpanan di NORD untuk mendapatkan data.
Seperti inilah diagram koneksi dalam sebuah cluster.
Hal ini dimungkinkan karena Tautan Antar-Switch dikonfigurasi antara fabric SAN di dua lokasi: sakelar Fabric A OST SAN terhubung ke sakelar Fabric A NORD SAN, dan demikian pula untuk sakelar Fabric B SAN.
Nah, agar semua seluk-beluk pabrik SAN ini masuk akal, replikasi Aktif-Aktif dikonfigurasikan antara dua sistem penyimpanan: informasi ditulis hampir secara bersamaan ke sistem penyimpanan lokal dan jarak jauh, RPO = 0. Ternyata data asli disimpan di satu sistem penyimpanan, dan replikanya disimpan di sistem penyimpanan lainnya. Data direplikasi pada tingkat volume penyimpanan, dan data VM (disknya, file konfigurasi, file swap, dll.) disimpan di dalamnya.
Host ESXi melihat volume utama dan replikanya sebagai satu perangkat disk (Perangkat Penyimpanan). Ada 24 jalur dari host ESXi ke setiap perangkat disk:
12 jalur menghubungkannya ke sistem penyimpanan lokal (jalur optimal), dan 12 jalur sisanya ke sistem penyimpanan jarak jauh (jalur non-optimal). Dalam situasi normal, ESXi mengakses data pada sistem penyimpanan lokal menggunakan jalur “optimal”. Ketika sistem penyimpanan ini gagal, ESXi kehilangan jalur optimal dan beralih ke jalur “tidak optimal”. Ini adalah apa yang terlihat pada diagram.
Skema cluster tahan bencana.
Semua jaringan klien terhubung ke kedua situs melalui struktur jaringan yang sama. Setiap situs menjalankan Provider Edge (PE), di mana jaringan klien dihentikan. PE disatukan menjadi satu cluster yang sama. Jika PE gagal di satu situs, semua lalu lintas dialihkan ke situs kedua. Berkat ini, mesin virtual dari situs yang dibiarkan tanpa PE tetap dapat diakses melalui jaringan ke klien.
Sekarang mari kita lihat apa yang akan terjadi pada mesin virtual klien jika terjadi berbagai kegagalan. Mari kita mulai dengan opsi yang paling ringan dan diakhiri dengan yang paling serius - kegagalan seluruh situs. Dalam contoh, platform utama adalah OST, dan platform cadangan, dengan replika data, adalah NORD.
Apa yang terjadi pada mesin virtual klien jika...
Tautan Replikasi gagal. Replikasi antara sistem penyimpanan kedua situs berhenti.
ESXi hanya akan bekerja dengan perangkat disk lokal (melalui jalur optimal).
Mesin virtual terus bekerja.
ISL (Inter-Switch Link) rusak. Kemungkinannya kecil. Kecuali jika beberapa ekskavator gila menggali beberapa rute optik sekaligus, yang berjalan pada rute independen dan dibawa ke lokasi melalui masukan yang berbeda. Tapi bagaimanapun juga. Dalam kasus ini, host ESXi kehilangan separuh jalur dan hanya dapat mengakses sistem penyimpanan lokalnya. Replika dikumpulkan, tetapi host tidak dapat mengaksesnya.
Mesin virtual bekerja normal.
Sakelar SAN gagal di salah satu situs. Host ESXi kehilangan sebagian jalur ke sistem penyimpanan. Dalam hal ini, host di situs di mana peralihan gagal hanya akan bekerja melalui salah satu HBA mereka.
Mesin virtual terus beroperasi secara normal.
Semua sakelar SAN di salah satu situs gagal. Katakanlah bencana seperti itu terjadi di situs OST. Dalam hal ini, host ESXi di situs ini akan kehilangan semua jalur ke perangkat disk mereka. Mekanisme standar VMware vSphere HA mulai berlaku: mekanisme ini akan memulai ulang semua mesin virtual situs OST di NORD dalam waktu maksimum 140 detik.
Mesin virtual yang berjalan pada host situs NORD beroperasi secara normal.
Host ESXi gagal di satu situs. Di sini mekanisme vSphere HA berfungsi kembali: mesin virtual dari host yang gagal di-restart di host lain - di situs yang sama atau jauh. Waktu restart mesin virtual hingga 1 menit.
Jika semua host ESXi di situs OST gagal, tidak ada pilihan: VM akan dimulai ulang di situs lain. Waktu mulai ulang sama.
Sistem penyimpanan gagal di satu situs. Katakanlah sistem penyimpanan gagal di situs OST. Kemudian host ESXi dari situs OST beralih untuk bekerja dengan replika penyimpanan di NORD. Setelah sistem penyimpanan yang gagal kembali berfungsi, replikasi paksa akan terjadi dan host OST ESXi akan mulai mengakses sistem penyimpanan lokal lagi.
Mesin virtual telah bekerja normal selama ini.
Salah satu situs gagal. Dalam hal ini, semua mesin virtual akan dimulai ulang di situs pencadangan melalui mekanisme vSphere HA. Waktu mulai ulang VM adalah 140 detik. Dalam hal ini, semua pengaturan jaringan mesin virtual akan disimpan, dan tetap dapat diakses oleh klien melalui jaringan.
Untuk memastikan restart mesin di situs pencadangan berjalan lancar, setiap situs hanya terisi setengahnya. Babak kedua adalah cadangan jika semua mesin virtual berpindah dari situs kedua yang rusak.
Cloud tahan bencana yang berbasis pada dua pusat data melindungi dari kegagalan tersebut.
Kenikmatan ini tidak murah, karena selain sumber daya utama, diperlukan cadangan di lokasi kedua. Oleh karena itu, layanan-layanan penting bagi bisnis ditempatkan di cloud tersebut, yang downtime jangka panjangnya menyebabkan kerugian finansial dan reputasi yang besar, atau jika sistem informasi tunduk pada persyaratan ketahanan bencana dari regulator atau peraturan internal perusahaan.
Sumber:
Sumber: www.habr.com