Здравейте, Хабр!
След края на новогодните празници, ние повторно стартирахме облако с устойчивост на катастрофи на базата на две площадки. Днес ще разкажем как е устроено и ще покажем какво се случва с клиентските виртуални машини при отказ на отделни елементи на кластер и падане на цяло място (спойлер – с тях всичко е наред).
СХД на облака с устойчивост на катастрофи на площадка OST.
Какво има вътре
Под капака на кластера стоят сървъри Cisco UCS с хипервизор VMware ESXi, две СХД INFINIDAT InfiniBox F2240, мрежово оборудване Cisco Nexus, както и SAN-свитчи Brocade. Кластерът е разнесен на две площадки – OST и NORD, т. е. в всяко дата-център има идентичен набор оборудване. Всъщност, това го прави устойчив на катастрофи.
В рамките на една площадка основните елементи също са дублирани (хостове, SAN-свитчи, мрежа).
Двете площадки са свързани с резервирани оптични влакна.
Няколко думи за СХД. Първият вариант на облака с устойчивост на катастрофи изградихме на NetApp. Тук избрахме INFINIDAT, и ето защо:
- Опцията Active-Active репликация. Тя позволява на виртуалната машина да остане в работоспособно състояние дори при пълен отказ на една от СХД. За репликацията ще разкажа по-подробно по-късно.
- Три дискови контролера за повишаване на отказоустойчивостта на системата. Обикновено има два.
- Готово решение. При нас дойде вече сглобен стелаж, който само трябва да се свърже към мрежата и да се настрои.
- Внимателна техническа поддръжка. Инженерите на INFINIDAT постоянно анализират логовете и събитията на СХД, инсталират нови версии на фърмуера, помагат с настройките.
Ето малко снимки от разопаковането:
Как работи
Облака вече е устойчив на катастрофи вътре в себе си. Той защитава клиента от единични хардуерни и софтуерни откази. Катастрофоустойчивото облако ще помогне за защита от масови злополуки в рамките на една площадка: например, отказ на СХД (или кластер SDS, което се случва не рядко 🙂), масови грешки в мрежата за съхранение и други. И най-важното: такова облако спасява, когато цяла площадка стане недостъпна поради пожар, блек-аут, рейдерски захват, нападение на извънземни.
Във всички тези случаи клиентските виртуални машини продължават да работят, и ето защо.
Кластерната схема е организирана така, че всеки ESXi хост с клиентски виртуални машини може да се свързва с която и да било от двете СХД. Ако СХД на площадката OST се повреди, виртуалните машини ще продължат да функционират: хостовете, на които работят, ще търсят данни от СХД на NORD.
Ето как изглежда схемата на свързване в клъстера.
Това е възможно благодарение на факта, че между SAN фабриките на двете площадки е настроен Inter-Switch Link: SAN суитч Fabric A OST е свързан с SAN суитча Fabric A NORD, аналогично и за SAN суитчовете Fabric B.
И за да имат смисъл всички тези сложни връзки на SAN фабриките, между двете СХД е настроена Active-Active репликация: информацията практически едновременно се записва на локалната и отдалечената СХД, RPO=0. Получава се, че на едната СХД се съхранява оригинала на данните, а на другата – тяхната реплика. Данните се репликират на ниво томове на СХД, а на тях вече се съхраняват данните на ВМ (нейните дискове, конфигурационен файл, swap файл и др.).
ESXi хостът вижда основния том и неговата реплика като едно дисково устройство (Storage Device). От ESXi хоста към всяко дисково устройство преминават 24 пътеки:
12 пътеки свързват хоста с локалната СХД (оптимални пътеки), а останалите 12 – с отдалечената (неоптимални пътеки). В нормални условия ESXi се свързва с данните на локалната СХД, използвайки "оптималните" пътеки. При повреда на тази СХД, ESXi губи оптималните пътеки и превключва на "неоптималните". Така изглежда схемата.
Схема на кластер за катастрофоустойчивост.
Всички клиентски мрежи са свързани към двете площадки чрез обща мрежова фабрика. На всяка площадка работи Provider Edge (PE), на който се терминат мрежите на клиента. PE-ата са обединени в общ клъстер. При отказ на PE на една площадка целият трафик се пренасочва към втората площадка. Благодарение на това виртуалните машини от площадката без PE остават достъпни по мрежата за клиента.
Сега да видим какво ще се случи с виртуалните машини на клиента при различни откази. Ще започнем с най-леките варианти и ще завършим с най-сериозния – отказ на цялата площадка. В примерите основната площадка ще бъде OST, а резервната с репликите на данните – NORD.
Какво се случва с виртуалната машина на клиента, ако…
Отказва Replication Link. Репликирането между СХД на двете площадки спира.
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. Времето за рестарт на ВМ е 140 секунди. При това всички мрежови настройки на виртуалната машина ще се запазят и тя остава достъпна за клиента по мрежата.
За да се извърши безпроблемно рестартиране на машините на резервната площадка, всяка площадка е запълнена само наполовина. Втората половина е резерв в случай на преместване на всички виртуални машини от втората, пострадала, площадка.
Точно от такива откази защитава облакът с катастрофоустойчивост, основан на два датацентъра.
Това удоволствие не е евтино, тъй като, в допълнение към основните ресурси, е необходим резерв на втората площадка. Затова в такъв облак се разпределят бизнес-критични услуги, чийто дълъг престой води до значителни финансови и репутационни загуби, или ако към информационната система се предявяват изисквания за катастрофоустойчивост от регулаторите или вътрешните разпоредби на компанията.
Източници:
Източник: habr.com
