Nie jest tajemnicą, że dość dobrze znam rozwiązanie klastrowania baz danych Oracle. Niedawno ukończyłem tworzenie klastrów SQL Server, rozwiązania wysokiej dostępności, które zajęło dwa lata od początkowego projektu do ostatecznego wdrożenia. Proces ten obejmował dokumentowanie wymagań, określanie opcji, mapowanie wymagań do szczegółów implementacji, budżetowanie, zaopatrzenie, instalację, konfigurację i testowanie.
Teraz, gdy mój projekt jest gotowy, pomyślałem, że podam kilka rzeczy na temat klastrowania SQL Server z perspektywy pracownika Oracle RAC. Wszyscy wiemy, że SQL Server i Oracle są silnikami RDBMS i mogą mieć pewne cechy wspólne. Ale to też zupełnie inne stworzenia. Więc jeśli czujesz się komfortowo z Oracle Grid Infrastructure oraz RAC i Data Guard i chcesz wdrożyć rozwiązanie SQL Server HA, może to dostarczy ci dobrych informacji.
Nasz obecny system produkcyjny to 4-węzłowa podstawowa baza danych Oracle RAC. Zapewnia to wysoką dostępność (i wysoką wydajność) w naszym głównym centrum danych. Używamy Data Guard, aby przetransportować ponawianie do 3-węzłowej fizycznej rezerwowej bazy danych RAC. Mimo że SQL Server <> Oracle, chciałem, aby nasza konfiguracja była jak najbardziej podobna, aby ułatwić administrację. Dlatego wdrożyliśmy 2-węzłowy klaster pracy awaryjnej SQL Server w naszej głównej lokacji i 1-węzłową „wstrzymaną” bazę danych w naszej lokacji DR.
Przejdźmy teraz do moich obserwacji, w dowolnej kolejności.
- Rozwiązanie klastrowe HA w SQL Server jest aktywne/pasywne. Oracle jest aktywny/aktywny, co dla mnie jest „lepsze” i tak… to subiektywne określenie. W przypadku naszej implementacji Active/Passive nie podobał mi się pomysł dwóch fizycznych serwerów, z których jeden jest praktycznie bezczynny przez cały czas. Mamy więc jeden serwer fizyczny, który jest „preferowanym” węzłem i jeden serwer wirtualny. Jeśli fizyczny serwer ulegnie awarii, klastrowanie automatycznie przełączy instancję SQL Server na serwer wirtualny i znów będziemy działać. Ten klaster typu Active/Passive nie zajmuje się skalowalnością, tak jak robi to Oracle RAC, ale zapewnia mi wyższą dostępność w naszym podstawowym środowisku.
- Wdrożenie klastrowania jest bardzo łatwe. Włącz klastrowanie na poziomie systemu operacyjnego. Ponieważ jest to stos całkowicie Microsoft, wbudowali klastrowanie w system operacyjny. Już tam jest dla ciebie. Wystarczy go włączyć. Następnie uruchom Narzędzia administracyjne -> Menedżer klastra pracy awaryjnej, a kreatory przeprowadzą Cię przez proces konfiguracji. Jest to o wiele łatwiejsze niż instalowanie infrastruktury sieciowej. Ale Oracle musi zmagać się z różnymi platformami operacyjnymi, co sprawia, że jest to trudniejsze. Ciekawe będzie zobaczyć, jak SQL Server 2016 w systemie Linux obsługuje klaster pracy awaryjnej.
- Oracle używa modelu dysku współdzielonego, podczas gdy program SQL Server jest niczym współużytkowanym. Ale musisz użyć „dysku współdzielonego” w pewien sposób, ponieważ dysk musi być dostępny na obu węzłach. Jednak MSFailover Clustering (MSFC) montuje dysk klastrowany w węźle aktywnym. Gdy program SQL Server zostanie przeniesiony do drugiego węzła, automatycznie lub ręcznie, MSFC odmontuje dysk w jednym węźle, a następnie zamontuje go w drugim. To trochę dziwne mieć otwarte okno Eksploratora Windows i widzieć, jak dysk pojawia się lub znika podczas tego przejścia.
- Infrastruktura Grid używa dysku do głosowania do operacji kworum. W MSFC możesz mieć dysk Kworum, użyć udziału plików lub skonfigurować bez kworum. Jeśli zdecydujesz się na to drugie, utrudnisz automatyczne przełączanie awaryjne.
- Jestem przyzwyczajony do tego, że mój podstawowy ma własny klaster, a tryb gotowości ma własny klaster. W przypadku programu SQL Server węzły podstawowe i węzły rezerwowe muszą należeć do tego samego klastra. Na szczęście klaster może przechodzić przez podsieci, co różni się od Oracle GI. Dodanie węzła gotowości było bardzo łatwe, właśnie usunęliśmy jego prawa głosu i nie skonfigurowaliśmy dysku kworum dla węzła gotowości. To było dla nas w porządku, ponieważ chcemy, aby przełączanie awaryjne do trybu gotowości było operacją ręczną.
- W przypadku rezerwowej bazy danych można użyć dublowania bazy danych, przesyłania dzienników lub zawsze włączonych grup dostępności (AG). Pierwsze dwie są już w drodze, więc poszedłem z AG. Grupy AG wymagają, aby węzeł w trybie gotowości był częścią tego samego klastra co główny. Dostępny jest kreator, który przeprowadzi Cię przez proces konfigurowania baz danych do udziału w AG. Jest to znacznie łatwiejsze niż konfigurowanie fizycznego trybu gotowości Oracle.
- Dla tych, którzy nienawidzą dokumentacji Oracle, czas być wdzięczny. Wiele razy podczas tego procesu zauważyłem, że w dokumentacji MS brakuje bardzo dużych elementów. Na przykład nigdy nie dowiedziałem się, jak skonfigurować mój węzeł gotowości, aby nie miał prawa głosu. Na szczęście udało nam się przez to przejść.
Kiedy wszystko zostało powiedziane i zrobione, wdrożenie rozwiązania SQL Server nie było takie trudne. Czasami musiałem polegać na swojej wiedzy na temat klastrowania. Innym razem terminologia Microsoftu przeszkadzała. Na przykład reszta świata nazywa to „podzielonym mózgiem”, ale MS nazywa to „podzielonym skupiskiem”. Czasami przezwyciężenie różnic leksykalnych było największą przeszkodą.
