Uważam, że kiedy ludzie projektują architekturę Oracle RAC, często nie myślą o nadmiarowości N+1 w swoich planach wdrożeniowych. Istnieją dwa powody wdrożenia Oracle RAC:dostępność i skalowalność. Na potrzeby tej dyskusji skupiam się tylko na stronie dostępności. Jeśli wdrożenia RAC służą wyłącznie skalowalności, ten temat może Cię nie dotyczyć.
Czym więc jest nadmiarowość N+1? Mówiąc najprościej, jeśli potrzebujesz N jednostek czegoś, to dla celów redundancji powinieneś mieć N+1 tego przedmiotu. Spójrzmy na serwer bazy danych. Musi mieć zasilanie. To jest wymóg. Bez działającego zasilacza serwer w ogóle nie będzie działał. Minimalna liczba zasilaczy to 1. Jeśli chcemy, aby ten serwer miał wysoki stopień dostępności, upewnimy się, że ma zasilacze N+1 lub w tym przypadku podwójne zasilacze. Jeśli jest tylko jeden zasilacz i awaria, to zabiera ze sobą serwer. Jeśli mamy dodatkowy zasilacz, jednostkę zapasową, to utrata jednego zasilacza nie zniszczy wraz z nim serwera. Nadmiarowość to świetna rzecz i niezbędny składnik infrastruktury o wysokiej dostępności.
Projektując system Oracle RAC, administrator baz danych musi określić, ile węzłów jest potrzebnych do obsługi wymagań użytkownika końcowego. Jeśli administrator DBA ustali, że potrzebne są 4 węzły, a ten klaster RAC musi wykazywać cechy wysokiej dostępności, ważne jest, aby administrator utworzył klaster z 5 węzłami (4+1). Jeśli zapotrzebowanie na zasoby jest wystarczające, aby 4 węzły były zajęte, a jeden węzeł został utracony, pozostałe 3 nie będą w stanie nadążyć z obciążeniem. Jeśli administrator DBA zbuduje system RAC z myślą o możliwościach N+1, to utrata jednego węzła nie będzie zauważalna przez użytkowników końcowych. Jeśli administrator DBA zbuduje klaster RAC bez nadmiarowości N+1, utrata jednego węzła może być tak straszna dla wydajności użytkownika końcowego, że cały klaster może równie dobrze przestać działać. Podczas projektowania implementacji RAC dąż do nadmiarowości N+1.
Pamiętam, że dwa lata temu miałem klaster RAC, który stracił węzeł. Nie ma problemu, wciąż mieliśmy dostępne dwa węzły. Kiedy obserwowałem wydajność dwóch pozostałych węzłów, wydawały się być dość przytłoczone. Nasze call center zaczęło otrzymywać skargi. Współpracowałem z innymi administratorami w zespole IT, aby przywrócić i uruchomić ten węzeł tak szybko, jak to możliwe, ale nie zawsze tak jest, jeśli przyczyna awarii jest związana ze sprzętem i części wymagają wymiany. Po ponownym uruchomieniu węzła przez kilka tygodni monitorowałem wydajność klastra. Nasze użycie wzrosło, odkąd ten system został pierwotnie zaprojektowany. Początkowo projektowaliśmy ten system z myślą o nadmiarowości N+1, ale nasze użycie wzrosło i N wzrosło z 2 do 3. Nasz obecny klaster z trzema węzłami nie był już nadmiarowy N+1. Dlatego współpracowałem z zarządem, aby w przyszłorocznym budżecie umieścić wystarczającą ilość środków na zakup nowego węzła i upewnienie się, że Oracle ma na niego licencję. Śpię znacznie lepiej w nocy, wiedząc, że wróciłem do redundancji N+1.
Podobnie jak wiele innych wdrożeń, mój system RAC nie jest jedyną funkcją wysokiej dostępności wbudowaną w naszą infrastrukturę. Ta baza danych RAC jest podstawową dla fizycznej rezerwowej bazy danych z Oracle Data Guard. Jestem zaskoczony, kiedy omawiam rezerwową bazę danych RAC z innymi administratorami baz danych Oracle, jak wielu z nich nie myśli o możliwościach N+1 dla ich rezerwy. Fizyczna rezerwowa baza danych jest moją siecią bezpieczeństwa na wypadek, gdyby główne centrum danych było z jakiegoś powodu niedostępne. Widziałem tak wielu administratorów baz danych Oracle wdrażających tryb gotowości na jedną instancję dla wielowęzłowego podstawowego kontrolera RAC. Auć! Mam nadzieję, że nigdy nie będą musieli przestać działać. Obciążenie całego wielowęzłowego klastra RAC będzie bardzo trudne w trybie gotowości na jedną instancję. Dlatego podczas projektowania implementacji RAC zarówno dla głównego, jak i rezerwowego, rozważ wpływ nadmiarowości N+1 na projekt architektury.
Prawdopodobnie różnię się od wielu ludzi tym, że moje implementacje fizycznego trybu gotowości nie obsługują N+1, ale raczej N. Pomijam nadmiarowy dodatkowy węzeł dla mojego fizycznego trybu gotowości. Dlaczego? Czysto z perspektywy kosztów. Mój fizyczny stan gotowości to tylko siatka bezpieczeństwa. Chcę, żeby zadziałało dla mnie w dniu, w którym tego potrzebuję. Ale mam nadzieję, że nigdy tego nie potrzebuję. Fizyczny stan gotowości to moja polisa ubezpieczeniowa na wypadek, gdyby ryzyko stało się rzeczywistością. Dla mnie to dodatkowe „+1” w miejscu gotowości to nadmierne ubezpieczenie. Mogę zaoszczędzić na fizycznym sprzęcie i licencji Oracle.
Powiedzmy, że nadchodzi dzień i przełączam się na tryb gotowości. Straciłem redundancję N+1. Ale jakie są szanse, że stracę główne centrum danych * i * jeden z węzłów w moim klastrze rezerwowym? Dość małe szanse. Prawdopodobieństwo awarii w dwóch lokalizacjach jednocześnie jest dość małe. W tym momencie nasz zespół IT ocenia, dlaczego nasze główne centrum danych zostało utracone i kiedy najprawdopodobniej możemy przywrócić nasze operacje do tego obiektu. Jeśli główne centrum danych utraci całą moc, a dostawca usług energetycznych powie, że usługa zostanie przywrócona do jutra, po prostu uruchomimy rezerwowe centrum danych, mimo że mamy tam tylko N węzłów dla bazy danych RAC. Jeśli jednak główne centrum danych zostało zniszczone przez pożar, jego ponowne uruchomienie potrwa wiele miesięcy. W tym momencie muszę zaplanować osiągnięcie nadmiarowości fizycznej gotowości do nadmiarowości N+1, ponieważ nasz czas korzystania z tego trybu gotowości jako podstawowego będzie znacznie dłuższy. Więc pospiesznie zamawiamy kolejny serwer i dodajemy go do klastra tak szybko, jak to możliwe. Dlatego projektuję moją rezerwową bazę danych RAC jako N, a nie N+1, z myślą o zwiększeniu jej do N+1 w krótkim czasie, jeśli ustalimy, że będziemy używać rezerwy w rzeczywistości przez dłuższy czas.
Jest więc jeszcze jeden szczególny przypadek, który chciałbym omówić. To tam DBA ustala, że N=1. Przy obecnych wymaganiach dotyczących obciążenia wystarczy jeden węzeł. Ale chcemy mieć wysoką dostępność, dlatego projektujemy dwuwęzłowy klaster RAC dla podstawowej bazy danych. Teraz mamy wbudowaną nadmiarowość N+1 w podstawowej. Po moim ostatnim akapicie moja rezerwowa baza danych potrzebuje tylko 1 węzła. Błędem, który popełniają niektórzy, jest tworzenie rezerwy jako bazy danych o jednym wystąpieniu. Jak dotąd ich logika ma sens. Podstawowy to N+1, a rezerwowy to N. Jak na razie dobrze. Różnice polegają na tym, że rezerwę robię jako jednowęzłowy klaster RAC, a nie czystą implementację z pojedynczą instancją. Powodem jest przyszły wzrost. W pewnym momencie administrator DBA może stwierdzić, że N nie jest już równe 1 na poziomie podstawowym. Użycie wzrosło i N musi teraz wynosić 2. Administrator DBA chce zwiększyć liczbę węzłów głównych do 3 (2+1). Można to łatwo zakończyć bez przestojów, aby dodać nowy węzeł do klastra i rozszerzyć bazę danych RAC na ten nowy węzeł. Ale nie jest tak łatwo zrobić w trybie gotowości klaster z 2 węzłami, jeśli ten 1 węzeł, który istnieje, nie obsługuje RAC. Jeśli wszystko, co istnieje tylko w trybie gotowości z pojedynczą instancją, administrator DBA musi go usunąć i przenieść do klastra z dwoma węzłami. Jeśli administrator DBA miał foresight i zainstalował infrastrukturę sieciową tak, jakby fizyczny tryb gotowości był klastrem z jednym węzłem, to wystarczy dodać nowy węzeł, tak jak zrobili to po stronie podstawowej.
Podczas projektowania implementacji RAC należy rozważyć zapewnienie możliwości N+1 w trybie podstawowym i co najmniej N w trybie gotowości. Jeśli firma uzna, że stan gotowości jest zbyt krytyczny, może chcieć wdrożyć N+1 również w gotowości. Jeśli administrator DBA ustali, że N=1, rozważ ustawienie w trybie gotowości co najmniej jednego klastra RAC z jednym węzłem.
