Hoy Habr!
Pagkatapos ng mga pista opisyal ng Bagong Taon, muling inilunsad namin ang isang cloud-proof na sakuna batay sa dalawang site. Ngayon, sasabihin namin sa iyo kung paano ito gumagana at ipapakita kung ano ang nangyayari sa mga virtual machine ng kliyente kapag nabigo ang mga indibidwal na elemento ng cluster at nag-crash ang buong site (spoiler β ayos lang sa kanila ang lahat).
Disaster-resistant cloud storage system sa site ng OST.
Ano ang nasa loob
Sa ilalim ng hood, ang cluster ay may mga Cisco UCS server na may VMware ESXi hypervisor, dalawang INFINIDAT InfiniBox F2240 storage system, Cisco Nexus network equipment, pati na rin ang Brocade SAN switch. Ang cluster ay nahahati sa dalawang site - OST at NORD, ibig sabihin, ang bawat data center ay may magkaparehong hanay ng kagamitan. Sa totoo lang, ito ang dahilan kung bakit ito lumalaban sa sakuna.
Sa loob ng isang site, ang mga pangunahing elemento ay nadoble din (mga host, SAN switch, networking).
Ang dalawang site ay konektado sa pamamagitan ng nakalaang mga ruta ng fiber optic, na nakalaan din.
Ilang salita tungkol sa mga sistema ng imbakan. Binuo namin ang unang bersyon ng disaster-proof cloud sa NetApp. Dito pinili namin ang INFINIDAT, at narito kung bakit:
- Aktibong-Aktibong opsyon sa pagtitiklop. Pinapayagan nito ang virtual machine na manatiling gumagana kahit na ang isa sa mga sistema ng imbakan ay ganap na nabigo. Sasabihin ko sa iyo ang higit pa tungkol sa pagtitiklop mamaya.
- Tatlong disk controller upang mapataas ang system fault tolerance. Kadalasan mayroong dalawa.
- Handa na solusyon. Nakatanggap kami ng pre-assembled rack na kailangan lang ikonekta sa network at i-configure.
- Matulungin na teknikal na suporta. Patuloy na sinusuri ng mga inhinyero ng INFINIDAT ang mga log at kaganapan ng storage system, nag-i-install ng mga bagong bersyon ng firmware, at tumulong sa pagsasaayos.
Narito ang ilang larawan mula sa pag-unpack:
Paano ito gumagana
Fault-tolerant na ang cloud sa loob nito. Pinoprotektahan nito ang kliyente mula sa iisang hardware at software na pagkabigo. Makakatulong ang disaster-resistant na maprotektahan laban sa malalaking pagkabigo sa loob ng isang site: halimbawa, pagkabigo ng isang storage system (o isang SDS cluster, na madalas mangyari π), malalaking error sa isang storage network, atbp. Buweno, at ang pinakamahalaga: ang ganitong ulap ay nakakatipid kapag ang isang buong site ay naging hindi naa-access dahil sa sunog, blackout, raider takeover, o alien landing.
Sa lahat ng mga kasong ito, patuloy na gumagana ang mga virtual machine ng kliyente, at narito kung bakit.
Ang disenyo ng cluster ay idinisenyo upang ma-access ng sinumang ESXi host na may mga virtual machine ng kliyente ang alinman sa dalawang storage system. Kung nabigo ang storage system sa site ng OST, ang mga virtual machine ay patuloy na gagana: ang mga host kung saan sila ay tumatakbo ay maa-access ang storage system sa NORD para sa data.
Ito ang hitsura ng diagram ng koneksyon sa isang kumpol.
Ito ay posible dahil sa katotohanan na ang isang Inter-Switch Link ay na-configure sa pagitan ng SAN fabric ng dalawang site: ang Fabric A OST SAN switch ay konektado sa Fabric A NORD SAN switch, at katulad din para sa Fabric B SAN switch.
Kaya, para magkaroon ng katuturan ang lahat ng mga intricacies na ito ng mga pabrika ng SAN, ang Active-Active replication ay na-configure sa pagitan ng dalawang storage system: halos sabay-sabay na isinulat ang impormasyon sa lokal at remote na storage system, RPO = 0. Lumalabas na ang orihinal na data ay naka-imbak sa isang storage system, at ang replica nito ay naka-imbak sa isa pa. Ang data ay kinokopya sa antas ng dami ng imbakan, at ang data ng VM (mga disk nito, configuration file, swap file, atbp.) ay nakaimbak sa kanila.
Nakikita ng ESXi host ang pangunahing volume at ang replica nito bilang isang disk device (Storage Device). Mayroong 24 na landas mula sa ESXi host patungo sa bawat disk device:
Ikinonekta ito ng 12 path sa lokal na storage system (mga pinakamainam na path), at ang natitirang 12 sa remote storage system (non-optimal na mga path). Sa isang normal na sitwasyon, ina-access ng ESXi ang data sa lokal na storage system gamit ang "pinakamainam" na mga landas. Kapag nabigo ang storage system na ito, mawawalan ng pinakamainam na landas ang ESXi at lilipat sa mga "hindi pinakamainam". Ito ang hitsura sa diagram.
Scheme ng disaster-proof cluster.
Ang lahat ng mga network ng kliyente ay konektado sa parehong mga site sa pamamagitan ng isang karaniwang tela ng network. Ang bawat site ay nagpapatakbo ng isang Provider Edge (PE), kung saan ang mga network ng kliyente ay winakasan. Ang mga PE ay pinagsama sa isang karaniwang kumpol. Kung nabigo ang isang PE sa isang site, ang lahat ng trapiko ay ire-redirect sa pangalawang site. Salamat dito, ang mga virtual machine mula sa site na naiwan nang walang PE ay nananatiling naa-access sa network ng kliyente.
Tingnan natin ngayon kung ano ang mangyayari sa mga virtual machine ng kliyente sa panahon ng iba't ibang pagkabigo. Magsimula tayo sa pinakamagaan na mga opsyon at magtatapos sa pinakamalubhang - pagkabigo ng buong site. Sa mga halimbawa, ang pangunahing platform ay magiging OST, at ang backup na platform, na may mga replika ng data, ay magiging NORD.
Ano ang mangyayari sa virtual machine ng kliyente kung...
Nabigo ang Replication Link. Hihinto ang pagtitiklop sa pagitan ng mga sistema ng imbakan ng dalawang site.
Ang ESXi ay gagana lamang sa mga lokal na disk device (sa pamamagitan ng pinakamainam na mga landas).
Ang mga virtual machine ay patuloy na gumagana.
Nasira ang ISL (Inter-Switch Link). Ang kaso ay hindi malamang. Maliban na lang kung ang isang baliw na excavator ay naghuhukay ng ilang optical route nang sabay-sabay, na tumatakbo sa mga independiyenteng ruta at dinadala sa mga site sa pamamagitan ng iba't ibang input. Pero kahit na. Sa kasong ito, nawawala ang kalahati ng mga path ng mga host ng ESXi at maa-access lang ang kanilang mga lokal na storage system. Kinokolekta ang mga replika, ngunit hindi maa-access ng mga host ang mga ito.
Ang mga virtual machine ay gumagana nang normal.
Nabigo ang switch ng SAN sa isa sa mga site. Ang mga host ng ESXi ay nawawala ang ilan sa mga landas patungo sa sistema ng imbakan. Sa kasong ito, gagana lang ang mga host sa site kung saan nabigo ang switch sa pamamagitan ng isa sa kanilang mga HBA.
Ang mga virtual machine ay patuloy na gumagana nang normal.
Nabigo ang lahat ng switch ng SAN sa isa sa mga site. Sabihin nating nangyari ang ganitong sakuna sa site ng OST. Sa kasong ito, ang mga host ng ESXi sa site na ito ay mawawala ang lahat ng mga landas patungo sa kanilang mga disk device. Ang karaniwang mekanismo ng VMware vSphere HA ay naglalaro: ire-restart nito ang lahat ng virtual machine ng OST site sa NORD sa maximum na 140 segundo.
Ang mga virtual machine na tumatakbo sa NORD site host ay normal na gumagana.
Nabigo ang host ng ESXi sa isang site. Dito gumagana muli ang mekanismo ng vSphere HA: ang mga virtual machine mula sa nabigong host ay na-restart sa ibang mga host - sa pareho o malayong site. Ang oras ng pag-restart ng virtual machine ay hanggang 1 minuto.
Kung nabigo ang lahat ng host ng ESXi sa site ng OST, walang mga opsyon: ang mga VM ay magre-restart sa isa pa. Ang oras ng pag-restart ay pareho.
Nabigo ang storage system sa isang site. Sabihin nating nabigo ang storage system sa site ng OST. Pagkatapos ay lumipat ang mga host ng ESXi ng site ng OST sa pagtatrabaho sa mga replika ng imbakan sa NORD. Matapos bumalik sa serbisyo ang nabigong sistema ng imbakan, magaganap ang sapilitang pagtitiklop at muling magsisimulang i-access ang mga host ng ESXi OST sa lokal na sistema ng imbakan.
Ang mga virtual machine ay gumagana nang normal sa lahat ng oras na ito.
Nabigo ang isa sa mga site. Sa kasong ito, ang lahat ng virtual machine ay ire-restart sa backup na site sa pamamagitan ng vSphere HA na mekanismo. Ang oras ng pag-restart ng VM ay 140 segundo. Sa kasong ito, ang lahat ng mga setting ng network ng virtual machine ay mase-save, at ito ay nananatiling naa-access sa client sa network.
Upang matiyak na ang pag-restart ng mga makina sa backup na site ay magiging maayos, ang bawat site ay kalahati lamang ang puno. Ang ikalawang kalahati ay isang reserba kung sakaling lumipat ang lahat ng virtual machine mula sa pangalawa, nasira na site.
Ang isang ulap na lumalaban sa sakuna batay sa dalawang data center ay nagpoprotekta laban sa mga naturang pagkabigo.
Ang kasiyahan na ito ay hindi mura, dahil, bilang karagdagan sa mga pangunahing mapagkukunan, kinakailangan ang isang reserba sa pangalawang site. Samakatuwid, ang mga serbisyong kritikal sa negosyo ay inilalagay sa naturang cloud, ang pangmatagalang downtime na nagdudulot ng malaking pagkalugi sa pananalapi at reputasyon, o kung ang sistema ng impormasyon ay napapailalim sa mga kinakailangan sa disaster-resilience mula sa mga regulator o panloob na regulasyon ng kumpanya.
Pinagmulan:
Pinagmulan: www.habr.com