Намирам, че когато хората проектират Oracle RAC архитектура, те често не мислят за N+1 излишък в своите планове за внедряване. Има две причини за внедряване на Oracle RAC, наличност и мащабируемост. За целите на тази дискусия се фокусирам само върху наличността. Ако внедряванията ви на RAC са само от съображения за мащабируемост, тогава тази тема може да не се отнася за вас.
И така, какво е N+1 Redundancy? Просто казано, ако имате нужда от N единици от нещо, тогава за целите на излишъка трябва да имате N+1 от този елемент. Нека разгледаме сървър на база данни. Трябва да има захранване. Това е изискване. Без работещо захранване сървърът изобщо няма да функционира. Минималният брой захранвания е 1. Ако искаме този сървър да има висока степен на наличност, ще се погрижим да има N+1 захранвания или в този случай двойни захранвания. Ако има само едно захранване и то се повреди, то отнема сървъра със себе си. Ако имаме допълнително захранване, резервно устройство, загубата на едно захранване няма да свали сървъра с него. Резервирането е страхотно нещо, което трябва да имате и съществен компонент за инфраструктура с висока наличност.
Когато проектира Oracle RAC система, DBA трябва да определи колко възли са необходими, за да поддържа изискванията на крайния потребител. Ако DBA определи, че са необходими 4 възела и този RAC клъстер трябва да проявява характеристики с висока наличност, тогава е жизненоважно DBA да създаде клъстер с 5 възела (4+1). Ако нуждите от ресурси са достатъчни, за да поддържат 4 възела заети и един възел е загубен, останалите 3 няма да могат да се справят с натоварването. Ако DBA изгради RAC системата с възможност за N+1 предвид, тогава загубата на един възел няма да бъде забележима от крайните потребители. Ако DBA изгради RAC клъстер без N+1 излишък, тогава загубата на един възел може да бъде толкова ужасна за производителността на крайния потребител, че целият клъстер може също да не работи. Когато проектирате своите RAC реализации, стремете се към N+1 резервиране.
Спомням си, че преди две години имах RAC клъстер, който загуби възел. Няма проблем, все още имахме два налични възела. Докато гледах изпълнението на двата останали възела, те изглеждаха доста претоварени. Нашият кол център започна да получава оплаквания. Работих с други администратори от ИТ екипа, за да върна този възел обратно и да работи възможно най-бързо, но това може да не винаги е така, ако причината за прекъсването е свързана с хардуера и частите трябва да бъдат подменени. След като възелът беше отново в експлоатация, наблюдавах производителността на клъстера седмици по-късно. Използването ни нарасна, откакто тази система беше първоначално проектирана. Първоначално проектирахме тази система с предвид N+1 излишък, но нашето използване нарасна и N премина от 2 на 3. Сегашният ни клъстер с 3 възела вече не беше N+1 излишен. Затова работих с ръководството, за да вложа в бюджета за следващата година достатъчно средства, за да закупя нов възел и да се уверя, че Oracle е лицензиран за него. Спя много по-добре през нощта, знаейки, че се връщам към съкращаване N+1.
Подобно на много имплементации, моята RAC система не е единствената функция за висока достъпност, вградена в нашата инфраструктура. Тази база данни RAC е основна за физическа резервна база данни с Data Guard на Oracle. Изненадан съм, когато обсъждам RAC резервните бази данни с други DBA на Oracle колко от тях не мислят за възможностите N+1 за техния режим на готовност. Базата данни за физическа готовност е моята защитна мрежа, в случай че основният център за данни е недостъпен по някаква причина. Виждал съм толкова много DBA на Oracle да внедряват режим на готовност за единичен екземпляр за първичен RAC с множество възли. Оу! Надявам се никога да не им се наложи да се провалят. Цялото им работно натоварване на RAC клъстер с много възли ще се бори силно в режим на готовност на този отделен екземпляр. Така че, докато проектирате своите RAC реализации както за първичния, така и за резервния, помислете за последствията от резервирането си N+1 върху архитектурния дизайн.
Това, където вероятно се различавам от много хора, е, че моите реализации за физически готовност не са N+1 способни, а по-скоро N. Пропускам излишния допълнителен възел за моя физически режим на готовност. Защо така? Чисто от гледна точка на разходите. Моята физическа готовност е просто предпазна мрежа. Искам да ми свърши работа в деня, в който имам нужда. Но се надявам, че никога няма да имам нужда. Физическият режим на готовност е моята застрахователна полица, в случай че рискът стане реалност. За мен това допълнително „+1“ в резервния сайт е свръхзастраховка. Мога да спестя от физическия хардуер и лицензирането на Oracle.
Така че да кажем, че денят идва и аз правя отказ в режим на готовност. Загубих съкращенията си N+1. Но какви са шансовете да загубя основния център за данни * и* да загубя един от възлите в моя резервен клъстер? Доста малки шансове. Вероятността от повреди на два обекта едновременно е доста малка. В този момент нашият ИТ екип оценява защо основният ни център за данни е загубен и кога най-вероятно можем да върнем операциите си в това съоръжение. Ако основният център за данни загуби цялата си мощност и комуналната компания каже, че услугата ще бъде възстановена до утре, тогава просто ще работим в центъра за данни в готовност, въпреки че там имаме само N възли за базата данни RAC. Въпреки това, ако основният център за данни е унищожен от пожар, ще отнеме много месеци, преди да започне да работи отново. Точно в този момент трябва да планирам да накарам този физически режим на готовност до N+1 резервиране, тъй като времето, когато използваме този режим на готовност като основен, ще бъде много по-дълъг период. Затова бързаме да поръчаме друг сървър и да го добавим към клъстера възможно най-скоро. Така че проектирам моята RAC база данни в режим на готовност като N, а не N+1, с цел да я увелича до N+1 в кратък срок, ако решим, че ще използваме режима на готовност реално за по-дълъг период от време.
Така че има още един специален случай, който бих искал да обсъдя. Това е мястото, където DBA определя, че N=1. За текущите изисквания за натоварване е достатъчен един възел. Но ние искаме да имаме висока наличност, така че проектираме RAC клъстер с два възела за основната база данни. Вече имаме N+1 резервиране, вградено в първичния. След последния ми параграф моята резервна база данни се нуждае само от 1 възел. Грешката, която виждам, че някои хора правят, е да създадат режим на готовност като база данни с един екземпляр. Засега тяхната логика е смислена. Първичният е N+1, а режимът на готовност е N. Засега добре. Разликата ми е, че правя режима на готовност RAC клъстер с един възел, а не чиста реализация на един екземпляр. Причината е за бъдещ растеж. В някакъв момент DBA може да установи, че N вече не е равно на 1 на първичния. Използването нарасна и N трябва да бъде 2 сега. DBA иска да увеличи основния до 3 възела (2+1). Това лесно се намалява с нулево време на престой, за да добавите нов възел към клъстера и да разширите базата данни RAC до този нов възел. Но не е толкова лесно да се направи в режим на готовност, за да се направи резервният клъстер с 2 възела, ако този 1 възел, който съществува, не е активиран за RAC. Ако чистият режим на готовност за един екземпляр е всичко, което съществува, DBA трябва да го изхвърли и да го премести в клъстер с два възела. Ако DBA е предвидил и е инсталирал Grid Infrastructure, сякаш физическият режим на готовност е клъстер с един възел, тогава всичко, което DBA трябва да направи, е да добави нов възел, точно както направиха от основната страна.
Докато проектирате своите RAC реализации, помислете дали да сте сигурни, че имате N+1 възможности на основния и поне N в режим на готовност. Ако една компания прецени, че режимът на готовност е твърде критичен, може да иска да внедри N+1 и в режим на готовност. Ако DBA определи, че N=1, помислете за това да направите в готовност поне един RAC клъстер с един възел.
