Не е тайна, че познавам решението на Oracle за клъстериране на бази данни доста добре. Наскоро завърших клъстеризиране на SQL Server, решение с висока наличност, което отне две години от първоначалния дизайн до окончателното внедряване. Този процес включваше документиране на изискванията, определяне на опциите, съпоставяне на изискванията с подробности за внедряването, бюджетиране, снабдяване, инсталиране, конфигуриране и тестване.
Сега, когато проектът ми е завършен, реших да дам няколко неща за клъстерирането на SQL Server от гледна точка на човек от Oracle RAC. Всички знаем, че SQL Server и Oracle са RDBMS двигатели и може да имат някои общи неща. Но те също са напълно различни същества. Така че, ако сте доволни от Grid Infrastructure на Oracle и RAC и Data Guard и търсите внедряване на SQL Server HA решение, може би това ще ви предостави добра информация.
Нашата текуща производствена система е основна база данни на Oracle RAC с 4 възела. Това осигурява висока наличност (и висока производителност) в нашия основен център за данни. Ние използваме Data Guard за транспортиране на повторение към физическа готовност на база данни на RAC с 3 възела. Въпреки че SQL Server <> Oracle, исках да запазя конфигурацията ни възможно най-сходна, за да улесня администрирането. Така че разположихме клъстер за отказване на SQL Server с 2 възела на нашия основен сайт и база данни с 1 възел в режим на готовност в нашия сайт за DR.
Сега към моите наблюдения, без определен ред.
- Решението за клъстериране на HA на SQL Server е активно/пасивно. Oracle е Active/Active, което за мен е „по-добро“ и да… това е субективен термин. За нашата активна/пасивна реализация не ми хареса идеята за два физически сървъра, които седят там с един по същество неактивен през цялото време. Така че имаме един физически сървър, който е „предпочитаният“ възел и един виртуален сървър. Ако физическият сървър се повреди, клъстерирането автоматично ще прехвърли екземпляра на SQL Server към виртуалния сървър и ние отново работим. Този активен/пасивен клъстер не се занимава с мащабируемост като Oracle RAC, но ми дава по-висока наличност в основната ни среда.
- Внедряването на клъстерирането е супер лесно. Включете клъстерирането на ниво ОС. Тъй като това е изцяло стек на Microsoft, те вградиха клъстериране в операционната система. Вече е там за вас. Просто трябва да го включите. След това стартирайте Административни инструменти –> Мениджър на клъстер за отказване и съветниците ще ви преведат през настройката. Това е много по-лесно от инсталирането на Grid Infrastructure. Но Oracle трябва да се бори с различни операционни платформи, което прави по-трудно там. Ще бъде интересно да видим как SQL Server 2016 на Linux се справя с отказоустойчив клъстер.
- Oracle използва модел на споделен диск, докато SQL Server е споделено нищо. Но трябва да използвате „споделен диск“ по някакъв начин, защото дискът трябва да е наличен и на двата възела. Въпреки това, MS Failover Clustering (MSFC) монтира клъстерирания диск на активния възел. Когато SQL Server се премести на другия възел, автоматично или ръчно, MSFC ще демонтира диска на единия възел, след което ще го монтира на другия. Някак странно е да имаш отворен прозорец на Windows Explorer и да видиш как дискът се появява или изчезва по време на този преход.
- Мрежовата инфраструктура използва диска за гласуване за кворумни операции. В MSFC можете да имате кворум диск, да използвате споделяне на файлове или да конфигурирате без кворум. Ако вземете последното, вие ще възпрепятствате възможността си за автоматично преминаване при отказ.
- Свикнал съм основният ми да има собствен клъстер, а резервният – собствен клъстер. При SQL Server основните възли и възлите в режим на готовност трябва да бъдат част от един и същ клъстер. За щастие, клъстерът може да пресича подмрежи, което е различно от Oracle GI. Добавянето на резервния възел беше супер лесно, просто премахнахме правата му на глас и не конфигурирахме кворумния диск за възела в режим на готовност. Това беше добре за нас, тъй като искаме превключването в режим на готовност да бъде ръчна операция.
- За резервна база данни можете да използвате дублиране на база данни, изпращане на журнали или групи за наличност на AlwaysOn (AG). Първите два са на излизане, така че аз отидох с AGs. AG изискват резервният възел да бъде част от същия клъстер като основния. Има съветник, който да ви преведе през настройката на базите данни за участие в AG. Това е много по-лесно, отколкото да настроите физически режим на готовност на Oracle.
- За тези от вас, които мразят документацията на Oracle, е време да бъдете благодарни. Много пъти по време на този процес открих, че в документацията на MS липсват много големи парчета. Например, никога не разбрах как да конфигурирам моя възел в режим на готовност да няма права на глас. За щастие успяхме да щракнем по него.
Когато всичко беше казано и направено, прилагането на решението на SQL Server не беше толкова трудно. Понякога трябваше да разчитам на познанията си за клъстерирането. Друг път терминологията на Microsoft пречи. Например, останалата част от света го нарича „разделен мозък“, но MS го нарича „разделен клъстер“. Понякога преодоляването на различията в лексикона беше най-голямото препятствие.
