Устойчив на бедствия облак: как работи

Хей Хабр!

След новогодишните празници пуснахме отново защитен от бедствия облак, базиран на два сайта. Днес ще ви разкажем как работи и ще покажем какво се случва с клиентските виртуални машини, когато отделни елементи на клъстера се повредят и целият сайт се срине (спойлер – всичко е наред с тях).

Устойчива на бедствия облачна система за съхранение на сайта на OST.

Какво има вътре

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

В рамките на един сайт основните елементи също се дублират (хостове, SAN комутатори, мрежи).
Двата обекта са свързани с обособени оптични трасета, също запазени.

Няколко думи за системите за съхранение. Създадохме първата версия на устойчив на бедствия облак на NetApp. Тук избрахме INFINIDAT и ето защо:

• Active-Active опция за репликация. Това позволява на виртуалната машина да остане работеща, дори ако една от системите за съхранение напълно се повреди. Ще ви разкажа повече за репликацията по-късно.
• Три дискови контролера за повишаване на устойчивостта на системата към грешки. Обикновено са две.
• Готово решение. Получихме предварително сглобен стелаж, който просто трябва да бъде свързан към мрежата и конфигуриран.
• Внимателна техническа поддръжка. Инженерите на 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 губи оптимални пътища и превключва към „неоптимални“. Ето как изглежда на диаграмата.

Схема на устойчив на бедствия клъстер.

Всички клиентски мрежи са свързани към двата сайта чрез обща мрежова структура. Всеки сайт изпълнява Provider Edge (PE), на който са терминирани мрежите на клиента. PE са обединени в общ клъстер. Ако PE се повреди на един сайт, целият трафик се пренасочва към втория сайт. Благодарение на това виртуалните машини от сайта, останал без PE, остават достъпни през мрежата за клиента.

Нека сега да видим какво ще се случи с клиентските виртуални машини по време на различни повреди. Нека започнем с най-леките варианти и завършим с най-сериозния - отказ на целия сайт. В примерите основната платформа ще бъде OST, а резервната платформа с реплики на данни ще бъде NORD.

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

Репликационната връзка е неуспешна. Репликацията между системите за съхранение на двата сайта спира.
ESXi ще работи само с локални дискови устройства (чрез оптимални пътища).
Виртуалните машини продължават да работят.

ISL (Inter-Switch Link) прекъсва. Случаят е малко вероятен. Освен ако някой луд багер не изкопае няколко оптични трасета наведнъж, които вървят по независими трасета и се довеждат до обектите през различни входове. Но както и да е. В този случай ESXi хостовете губят половината от пътищата и имат достъп само до своите локални системи за съхранение. Репликите се събират, но хостовете няма да имат достъп до тях.

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

SAN комутаторът се проваля на един от сайтовете. ESXi хостовете губят някои от пътищата към системата за съхранение. В този случай хостовете на сайта, където превключването е неуспешно, ще работят само през един от техните HBA.

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

Всички SAN комутатори на един от сайтовете се провалят. Да кажем, че такова бедствие се случи на сайта на OST. В този случай ESXi хостовете на този сайт ще загубят всички пътища до своите дискови устройства. Стандартният VMware vSphere HA механизъм влиза в действие: той ще рестартира всички виртуални машини на OST сайта в NORD за максимум 140 секунди.

Виртуалните машини, работещи на хостове на NORD, работят нормално.

ESXi хостът се проваля на един сайт. Тук механизмът на vSphere HA работи отново: виртуалните машини от неуспешния хост се рестартират на други хостове - на същия или отдалечен сайт. Времето за рестартиране на виртуалната машина е до 1 минута.

Ако всички ESXi хостове на сайта на OST се провалят, няма опции: виртуалните машини се рестартират на друг. Времето за рестартиране е същото.

Системата за съхранение се проваля на едно място. Да кажем, че системата за съхранение се провали на сайта на 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