Облак отпорен на катастрофи: како функционира

Еј Хабр!

По новогодишните празници, повторно лансиравме облак отпорен на катастрофи базиран на две локации. Денес ќе ви кажеме како функционира и ќе покажеме што се случува со клиентските виртуелни машини кога поединечни елементи од кластерот не успеат и целата страница ќе се сруши (спојлер - сè е во ред со нив).

Систем за складирање облак отпорен на катастрофи на страницата OST.

Што е внатре

Под хаубата, кластерот има Cisco UCS сервери со VMware ESXi хипервизор, два системи за складирање INFINIDAT InfiniBox F2240, мрежна опрема Cisco Nexus, како и прекинувачи Brocade SAN. Кластерот е поделен на две локации - OST и NORD, односно секој центар за податоци има идентичен сет на опрема. Всушност, тоа е она што го прави отпорен на катастрофи.

Во рамките на една локација, главните елементи се исто така дуплирани (домаќини, SAN прекинувачи, вмрежување).
Двете локации се поврзани со наменски рути со оптички влакна, исто така резервирани.

Неколку зборови за системите за складирање. Ја изградивме првата верзија на облак отпорен на катастрофи на NetApp. Овде го избравме INFINIDAT, и еве зошто:

• Активно-активна опција за репликација. Овозможува виртуелната машина да остане оперативна дури и ако еден од системите за складирање целосно пропадне. Ќе ви кажам повеќе за репликацијата подоцна.
• Три контролери на дискот за зголемување на толеранцијата на грешки во системот. Обично има два.
• Подготвено решение. Добивме претходно склопена решетка што само треба да се поврзе на мрежата и да се конфигурира.
• Внимателна техничка поддршка. Инженерите на INFINIDAT постојано ги анализираат дневниците и настаните на системот за складирање, инсталираат нови верзии на фирмверот и помагаат во конфигурацијата.

Еве неколку фотографии од распакувањето:

Како работи

Облакот е веќе толерантен на грешки во себе. Го штити клиентот од единечни дефекти на хардверот и софтверот. Отпорноста на катастрофи ќе помогне да се заштитите од огромни дефекти на една локација: на пример, дефект на систем за складирање (или кластер SDS, што се случува доста често 🙂), масивни грешки во мрежата за складирање итн. Па, и што е најважно: таков облак заштедува кога цела локација станува недостапна поради пожар, затемнување, преземање напаѓачи или слетување на вонземјани.

Во сите овие случаи, клиентските виртуелни машини продолжуваат да работат, а еве зошто.

Кластер-шемата е дизајнирана така што секој ESXi-домаќин со клиентски виртуелни машини може да пристапи до кој било од двата системи за складирање. Ако системот за складирање на страницата OST не успее, виртуелните машини ќе продолжат да работат: хостовите на кои работат ќе пристапат до системот за складирање на NORD за податоци.

Вака изгледа дијаграмот за поврзување во кластер.

Ова е можно поради фактот што е конфигуриран интер-прекинувач врска помеѓу ткаенините SAN на двете локации: прекинувачот Fabric A OST SAN е поврзан со прекинувачот Fabric A NORD SAN и слично за прекинувачите Fabric B SAN.

Па, за да имаат смисла сите овие сложености на фабриките SAN, Active-Active репликацијата е конфигурирана помеѓу двата системи за складирање: информациите речиси истовремено се запишуваат во локалниот и далечинскиот систем за складирање, RPO = 0. Излегува дека оригиналните податоци се зачувани на еден систем за складирање, а неговата реплика е зачувана на другиот. Податоците се реплицираат на ниво на волумени за складирање, а податоците на VM (неговите дискови, конфигурациската датотека, датотеката за размена итн.) се складираат на нив.

Домаќинот ESXi го гледа примарниот волумен и неговата реплика како еден уред со диск (Уред за складирање). Има 24 патеки од домаќинот ESXi до секој уред на дискот:

12 патеки го поврзуваат со локалниот систем за складирање (оптимални патеки), а останатите 12 со далечинскиот систем за складирање (неоптимални патеки). Во нормална ситуација, ESXi пристапува до податоците на локалниот систем за складирање користејќи „оптимални“ патеки. Кога овој систем за складирање не успее, ESXi ги губи оптималните патеки и се префрла на „неоптимални“. Вака изгледа на дијаграмот.

Шема на кластер отпорен на катастрофи.

Сите мрежи на клиенти се поврзани со двете локации преку заедничка мрежна ткаенина. Секоја локација има провајдерски раб (PE), на кој се прекинуваат мрежите на клиентот. ПЕ се обединети во заеднички кластер. Ако PE не успее на една локација, целиот сообраќај се пренасочува на втората локација. Благодарение на ова, виртуелните машини од страницата оставени без PE остануваат достапни преку мрежата за клиентот.

Ајде сега да видиме што ќе се случи со виртуелните машини на клиентите при различни неуспеси. Да почнеме со најлесните опции и да завршиме со најсериозниот - неуспех на целата локација. Во примерите, главната платформа ќе биде OST, а резервната платформа, со реплики на податоци, ќе биде NORD.

Што се случува со клиентската виртуелна машина ако...

Врската за репликација не успее. Репликацијата помеѓу системите за складирање на двете локации престанува.
ESXi ќе работи само со локални уреди со диск (преку оптимални патеки).
Виртуелните машини продолжуваат да работат.

ISL (Inter-Switch Link) се прекинува. Случајот е малку веројатен. Освен ако некој луд багер не ископа неколку оптички правци одеднаш, кои се движат по независни правци и се носат до локациите преку различни влезови. Но како и да е. Во овој случај, домаќините на ESXi губат половина од патеките и можат само да пристапат до нивните локални системи за складирање. Репликите се собираат, но домаќините нема да можат да пристапат до нив.

Виртуелните машини работат нормално.

Прекинувачот SAN не успее на една од локациите. Домаќините на ESXi губат некои од патеките до системот за складирање. Во овој случај, домаќините на местото каде што прекинувачот не успеа ќе работат само преку еден од нивните HBA.

Виртуелните машини продолжуваат да работат нормално.

Сите SAN прекинувачи на една од локациите не успеваат. Да речеме, таква катастрофа се случи на страницата на ОСТ. Во овој случај, домаќините на ESXi на оваа страница ќе ги изгубат сите патеки до нивните уреди со диск. Стандардниот механизам VMware vSphere HA влегува во игра: ќе ги рестартира сите виртуелни машини на страницата OST во NORD за максимум 140 секунди.

Виртуелните машини што работат на домаќините на NORD-локациите работат нормално.

Домаќинот ESXi не успева на една локација. Овде механизмот vSphere HA работи повторно: виртуелните машини од неуспешниот домаќин се рестартираат на други хостови - на истата или оддалечена локација. Времето за рестартирање на виртуелната машина е до 1 минута.

Ако сите ESXi хостови на страницата OST не успеат, нема опции: VM-ите се рестартираат на друг. Времето за рестартирање е исто.

Системот за складирање не успева на една локација. Да речеме дека системот за складирање не успее на локацијата на OST. Потоа, ESXi-домаќините на страницата OST се префрлаат на работа со копии за складирање во NORD. Откако неуспешниот систем за складирање ќе се врати на услуга, ќе се појави принудна репликација и ESXi OST-домаќините повторно ќе почнат да пристапуваат до локалниот систем за складирање.

Виртуелните машини работат нормално цело ова време.

Еден од сајтовите не успева. Во овој случај, сите виртуелни машини ќе се рестартираат на резервната страница преку механизмот vSphere HA. Времето за рестартирање на VM е 140 секунди. Во овој случај, сите мрежни поставки на виртуелната машина ќе бидат зачувани и таа останува достапна за клиентот преку мрежата.

За да се осигура дека рестартирањето на машините на местото за резервни копии оди непречено, секоја локација е само половина полна. Втората половина е резерва во случај сите виртуелни машини да се преселат од втората, оштетена локација.

Облак отпорен на катастрофи базиран на два центри за податоци штити од такви неуспеси.

Ова задоволство не е евтино, бидејќи, покрај главните ресурси, потребна е и резерва на втората локација. Затоа, услугите кои се клучни за бизнисот се сместени во таков облак, чие долгорочно застој предизвикува големи финансиски загуби и загуби на репутацијата или ако информацискиот систем е предмет на барања за отпорност на катастрофи од регулаторите или внатрешните регулативи на компанијата.

Извори:

1. www.infinidat.com/sites/default/files/resource-pdfs/DS-INFBOX-190331-US_0.pdf
2. support.infinidat.com/hc/en-us/articles/207057109-InfiniBox-best-practices-guides

Извор: www.habr.com