Budowa rozwiązania odpornego na błędy w oparciu o architekturę Oracle RAC i AccelStor Shared-Nothing

Znaczna liczba aplikacji korporacyjnych i systemów wirtualizacji posiada własne mechanizmy budowania rozwiązań odpornych na awarie. W szczególności Oracle RAC (Oracle Real Application Cluster) to klaster dwóch lub więcej serwerów baz danych Oracle współpracujących ze sobą w celu zrównoważenia obciążenia i zapewnienia odporności na awarie na poziomie serwera/aplikacji. Do pracy w tym trybie potrzebna jest pamięć współdzielona, ​​którą zwykle jest system pamięci masowej.

Jak już pisaliśmy w jednym z naszych artykułysam system przechowywania danych, pomimo obecności zdublowanych komponentów (w tym kontrolerów), nadal posiada punkty awarii – głównie w postaci pojedynczego zestawu danych. Dlatego też, aby zbudować rozwiązanie Oracle o podwyższonych wymaganiach niezawodnościowych, schemat „N serwerów – jeden system pamięci masowej” musi być skomplikowany.

Najpierw oczywiście musimy zdecydować, od jakiego ryzyka chcemy się ubezpieczyć. W tym artykule nie będziemy rozważać ochrony przed zagrożeniami typu „przybył meteoryt”. Dlatego budowanie rozproszonego geograficznie rozwiązania do odzyskiwania po awarii pozostanie tematem jednego z kolejnych artykułów. W tym miejscu przyjrzymy się tzw. rozwiązaniu typu Disaster Recovery typu Cross-Rack, gdy ochrona budowana jest na poziomie szaf serwerowych. Same szafy mogą znajdować się w tym samym pomieszczeniu lub w różnych, ale zazwyczaj w tym samym budynku.

Szafy te muszą zawierać cały niezbędny zestaw sprzętu i oprogramowania, które pozwolą na działanie baz danych Oracle niezależnie od stanu „sąsiada”. Innymi słowy, korzystając z rozwiązania Disaster Recovery Cross-Rack, eliminujemy ryzyko awarii:

• Serwery aplikacji Oracle
• Systemy pamięci masowej
• Systemy przełączające
• Całkowita awaria całego wyposażenia szafy:
  • Odmowa władzy
  • Awaria układu chłodzenia
  • Czynniki zewnętrzne (człowiek, przyroda itp.)

Powielanie serwerów Oracle implikuje samą zasadę działania Oracle RAC i jest realizowane poprzez aplikację. Powielanie urządzeń przełączających również nie stanowi problemu. Ale przy powielaniu systemu przechowywania wszystko nie jest takie proste.

Najprostszą opcją jest replikacja danych z systemu pamięci głównej do systemu zapasowego. Synchroniczne lub asynchroniczne, w zależności od możliwości systemu pamięci masowej. Przy replikacji asynchronicznej od razu pojawia się pytanie o zapewnienie spójności danych w stosunku do Oracle. Jednak nawet jeśli istnieje integracja oprogramowania z aplikacją, to i tak w przypadku awarii głównego systemu przechowywania danych konieczna będzie ręczna interwencja administratorów w celu przełączenia klastra na magazyn zapasowy.

Bardziej złożoną opcją są „wirtualizatory” oprogramowania i/lub sprzętu do przechowywania danych, które wyeliminują problemy ze spójnością i ręczną interwencję. Jednak złożoność wdrożenia i późniejszej administracji, a także bardzo nieprzyzwoity koszt takich rozwiązań odstraszają wielu.

Rozwiązanie macierzowe AccelStor NeoSapphire™ All Flash doskonale sprawdza się w scenariuszach takich jak odzyskiwanie danych po awarii typu Cross-Rack H710 przy użyciu architektury Shared-Nothing. Model ten to dwuwęzłowy system pamięci masowej wykorzystujący opatentowaną technologię FlexiRemap® do współpracy z dyskami flash. Dzięki FlexiRemap® NeoSapphire™ H710 jest w stanie zapewnić wydajność do 600 tys. IOPS przy losowym zapisie przy 4K i ponad 1 mln IOPS przy losowym odczycie przy 4K, co jest nieosiągalne w przypadku korzystania z klasycznych systemów pamięci masowej opartych na macierzy RAID.

Ale główną cechą NeoSapphire™ H710 jest wykonanie dwóch węzłów w postaci oddzielnych przypadków, z których każdy ma własną kopię danych. Synchronizacja węzłów odbywa się poprzez zewnętrzny interfejs InfiniBand. Dzięki tej architekturze możliwa jest dystrybucja węzłów w różne lokalizacje w odległości do 100 m, zapewniając w ten sposób rozwiązanie typu Disaster Recovery typu Cross-Rack. Oba węzły działają całkowicie synchronicznie. Od strony hosta H710 wygląda jak zwykły system pamięci masowej z dwoma kontrolerami. Nie ma zatem potrzeby wykonywania żadnych dodatkowych opcji programowych, sprzętowych ani szczególnie skomplikowanych ustawień.

Jeśli porównamy wszystkie opisane powyżej rozwiązania do odtwarzania po awarii Cross-Rack, to opcja AccelStor wyraźnie wyróżnia się na tle innych:

Architektura AccelStor NeoSapphire™ typu Shared Nothing
Programowy lub sprzętowy „wirtualny” system pamięci masowej
Rozwiązanie oparte na replikacji

Dostępność

Awaria serwera
Brak przestojów
Brak przestojów
Brak przestojów

Awaria przełącznika
Brak przestojów
Brak przestojów
Brak przestojów

Awaria systemu przechowywania
Brak przestojów
Brak przestojów
Przestoje

Cała awaria szafki
Brak przestojów
Brak przestojów
Przestoje

Koszt i złożoność

Koszt rozwiązania
Niski*
Wysoki
Wysoki

Złożoność wdrożenia
niski
Wysoki
Wysoki

*AccelStor NeoSapphire™ to w dalszym ciągu macierz All Flash, która z definicji nie kosztuje „3 kopiejek”, zwłaszcza że ma podwójną rezerwę pojemności. Jednak porównując ostateczny koszt rozwiązania na nim opartego z podobnymi rozwiązaniami innych dostawców, można uznać, że jest to koszt niski.

Topologia łączenia serwerów aplikacji i węzłów macierzy All Flash będzie wyglądać następująco:

Podczas planowania topologii zdecydowanie zaleca się zduplikowanie przełączników zarządzających i serwerów wzajemnych.

Tutaj i dalej będziemy rozmawiać o połączeniu przez Fibre Channel. Jeśli użyjesz iSCSI, wszystko będzie takie samo, dostosowane do rodzaju używanych przełączników i nieco innych ustawień tablicy.

Prace przygotowawcze nad tablicą

Używany sprzęt i oprogramowanie

Specyfikacje serwerów i przełączników

Components
Opis

Serwery Oracle Database 11g
Dwa

Serwerowy system operacyjny
Oracle Linux

Wersja bazy danych Oracle
11g (RAC)

Procesory na serwer
Dwa 16 rdzeni Intel® Xeon® CPU E5-2667 v2 @ 3.30 GHz

Pamięć fizyczna na serwer
128GB

Sieć FC
16 Gb/s FC z obsługą wielu ścieżek

FC HBA
Emulex Lpe-16002B

Dedykowane publiczne porty 1GbE do zarządzania klastrem
Adapter Intel Ethernet RJ45

Przełącznik FC 16 Gb/s
Brokat 6505

Dedykowane prywatne porty 10GbE do synchronizacji danych
Intel X520

Specyfikacja wszystkich macierzy Flash AccelStor NeoSapphire™

Components
Opis

System magazynowania
Model o wysokiej dostępności NeoSapphire™: H710

Wersja obrazu
4.0.1

Łączna liczba dysków
48

Rozmiar dysku
1.92TB

Typ napędu
SSD

Porty docelowe FC
16 portów 16 Gb (8 na węzeł)

Porty zarządzania
Kabel Ethernet 1GbE łączący się z hostami za pośrednictwem przełącznika Ethernet

Port bicia serca
Kabel Ethernet 1GbE łączący dwa węzły magazynowania

Port synchronizacji danych
Kabel InfiniBand 56 Gb/s

Zanim będzie można użyć tablicy, należy ją zainicjować. Domyślnie adres kontrolny obu węzłów jest taki sam (192.168.1.1). Należy się z nimi po kolei łączyć i ustawiać nowe (już różne) adresy zarządzające oraz synchronizację czasu, po czym porty Management będą mogły zostać połączone w jedną sieć. Następnie węzły są łączone w parę HA poprzez przypisanie podsieci dla połączeń Interlink.

Po zakończeniu inicjalizacji można zarządzać tablicą z dowolnego węzła.

Następnie tworzymy niezbędne woluminy i publikujemy je na serwerach aplikacji.

Zdecydowanie zaleca się utworzenie wielu woluminów dla Oracle ASM, ponieważ zwiększy to liczbę celów dla serwerów, co ostatecznie poprawi ogólną wydajność (więcej o kolejkach w innym Artykuł).

Konfiguracja testowa

Nazwa woluminu pamięci
Rozmiar woluminu

Data01
200GB

Data02
200GB

Data03
200GB

Data04
200GB

Data05
200GB

Data06
200GB

Data07
200GB

Data08
200GB

Data09
200GB

Data10
200GB

Grid01
1GB

Grid02
1GB

Grid03
1GB

Grid04
1GB

Grid05
1GB

Grid06
1GB

Powtórz01
100GB

Powtórz02
100GB

Powtórz03
100GB

Powtórz04
100GB

Powtórz05
100GB

Powtórz06
100GB

Powtórz07
100GB

Powtórz08
100GB

Powtórz09
100GB

Powtórz10
100GB

Kilka wyjaśnień dotyczących trybów pracy układu i procesów zachodzących w sytuacjach awaryjnych

Zbiór danych każdego węzła ma parametr „numer wersji”. Po wstępnej inicjalizacji jest on taki sam i równy 1. Jeśli z jakiegoś powodu numer wersji jest inny, wówczas dane są zawsze synchronizowane ze starszej wersji do młodszej, po czym dopasowywany jest numer młodszej wersji, tj. oznacza to, że kopie są identyczne. Powody, dla których wersje mogą się różnić:

• Zaplanowany restart jednego z węzłów
• Wypadek na jednym z węzłów spowodowany nagłym wyłączeniem (zasilanie, przegrzanie itp.).
• Utracono połączenie InfiniBand i nie można przeprowadzić synchronizacji
• Awaria jednego z węzłów z powodu uszkodzenia danych. Tutaj będziesz musiał utworzyć nową grupę HA i pełną synchronizację zestawu danych.

W każdym przypadku węzeł pozostający online zwiększa numer wersji o jeden, aby zsynchronizować swój zbiór danych po przywróceniu połączenia z parą.

Jeśli połączenie przez łącze Ethernet zostanie utracone, Heartbeat tymczasowo przełączy się na InfiniBand i powróci w ciągu 10 sekund po jego przywróceniu.

Konfigurowanie hostów

Aby zapewnić odporność na awarie i poprawić wydajność, należy włączyć obsługę MPIO dla macierzy. W tym celu należy dodać linie do pliku /etc/multipath.conf, a następnie zrestartować usługę wielościeżkową

Ukryty teksturządzenia {
urządzenie {
sprzedawca "AStor"
path_grouping_policy "grupa_po_prio"
path_selector "długość kolejki 0"
path_checker "tur"
cechy „0”
hardware_handler "0"
priorytet „stała”
natychmiastowy powrót po awarii
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names tak
Detect_prio tak
rr_min_io_rq 1
no_path_retry 0
}
}

Następnie, aby ASM współpracował z MPIO poprzez ASMLib, musisz zmienić plik /etc/sysconfig/oracleasm, a następnie uruchomić /etc/init.d/oracleasm scandisks

Ukryty tekst

# ORACLEASM_SCANORDER: Dopasowywanie wzorców w celu zamówienia skanowania dysku
ORACLEASM_SCANORDER="dm"

# ORACLEASM_SCANEXCLUDE: Pasujące wzorce wykluczające dyski ze skanowania
ORACLEASM_SCANEXCLUDE="sd"

Operacja

Jeśli nie chcesz używać ASMLib, możesz użyć reguł UDEV, które są podstawą ASMLib.

Począwszy od wersji 12.1.0.2 Oracle Database opcja jest dostępna do instalacji w ramach oprogramowania ASMFD.

Koniecznie należy upewnić się, że dyski utworzone dla Oracle ASM są dopasowane do rozmiaru bloku, z jakim fizycznie współpracuje macierz (4K). W przeciwnym razie mogą wystąpić problemy z wydajnością. Dlatego konieczne jest utworzenie woluminów o odpowiednich parametrach:

parted /dev/mapper/nazwa-urządzenia mklabel gpt mkpart basic 2048s 100% wyrównanie-sprawdzenie optymalne 1

Dystrybucja baz danych pomiędzy utworzonymi woluminami dla naszej konfiguracji testowej

Nazwa woluminu pamięci
Rozmiar woluminu
Mapowanie jednostek LUN woluminów
Szczegóły urządzenia woluminu ASM
Rozmiar jednostki alokacji

Data01
200GB
Zamapuj wszystkie woluminy pamięci masowej na wszystkie porty danych systemu pamięci masowej
Redundancja: Normalna
Nazwa: DGDATA
Cel:Pliki danych

4MB

Data02
200GB

Data03
200GB

Data04
200GB

Data05
200GB

Data06
200GB

Data07
200GB

Data08
200GB

Data09
200GB

Data10
200GB

Grid01
1GB
Redundancja: Normalna
Nazwa: DGGRID1
Cel:Siatka: CRS i głosowanie

4MB

Grid02
1GB

Grid03
1GB

Grid04
1GB
Redundancja: Normalna
Nazwa: DGGRID2
Cel:Siatka: CRS i głosowanie

4MB

Grid05
1GB

Grid06
1GB

Powtórz01
100GB
Redundancja: Normalna
Nazwa: DGREDO1
Cel: Ponowne wykonanie dziennika wątku 1

4MB

Powtórz02
100GB

Powtórz03
100GB

Powtórz04
100GB

Powtórz05
100GB

Powtórz06
100GB
Redundancja: Normalna
Nazwa: DGREDO2
Cel: Ponowne wykonanie dziennika wątku 2

4MB

Powtórz07
100GB

Powtórz08
100GB

Powtórz09
100GB

Powtórz10
100GB

Ustawienia bazy danych

• Rozmiar bloku = 8K
• Miejsce wymiany = 16 GB
• Wyłącz AMM (automatyczne zarządzanie pamięcią)
• Wyłącz przezroczyste ogromne strony

Inne ustawienia

# vi /etc/sysctl.conf
✓ fs.aio-max-nr = 1048576
✓ fs.file-max = 6815744
✓ kernel.shmmax 103079215104
✓ jądro.shmall 31457280
✓ jądro.shmmn 4096
✓ jądro.sem = 250 32000 100 128
✓ net.ipv4.ip_local_port_range = 9000 65500
✓ net.core.rmem_default = 262144
✓ net.core.rmem_max = 4194304
✓ net.core.wmem_default = 262144
✓ net.core.wmem_max = 1048586
✓vm.zmienność=10
✓ vm.min_free_kbytes=524288 # nie ustawiaj tej opcji, jeśli używasz Linuksa x86
✓ vm.vfs_cache_ Pressure=200
✓ vm.nr_hugepages = 57000

# vi /etc/security/limits.conf
✓ siatka miękka nproc 2047
✓ siatka twarda nproc 16384
✓ siatka miękka Nofile 1024
✓ siatka twarda Nofile 65536
✓ siatka soft stack 10240
✓ Twardy stos siatki 32768
✓ Oracle Soft Nproc 2047
✓ Oracle Hard Nproc 16384
✓ Oracle Soft Nofile 1024
✓ twardy nofile Oracle 65536
✓ Miękki stos Oracle 10240
✓ twardy stos Oracle 32768
✓ miękki memlock 120795954
✓ twardy memlock 120795954

sqlplus „/jako sysdba”
zmień zestaw systemowy procesy=2000 zakres=spfile;
zmień zestaw systemowy open_cursors=2000 zakres=spfile;
zmień zestaw systemowy session_cached_cursors=300 zakres=spfile;
zmień zestaw systemowy db_files=8192 zakres=spfile;

Test niepowodzenia

W celach demonstracyjnych do emulacji obciążenia OLTP użyto HammerDB. Konfiguracja HammerDB:

Liczba magazynów
256

Łączna liczba transakcji na użytkownika
1000000000000

Użytkownicy wirtualni
256

W rezultacie uzyskano 2.1 mln modułu TPM, co znacznie przekracza limit wydajności macierzy H710, ale stanowi „pułap” aktualnej konfiguracji sprzętowej serwerów (głównie ze względu na procesory) i ich liczby. Celem tego testu jest nadal wykazanie odporności rozwiązania na błędy jako całości, a nie osiągnięcie maksymalnej wydajności. Dlatego po prostu będziemy opierać się na tej liczbie.

Sprawdź awarię jednego z węzłów

Hosty utraciły część ścieżek do magazynu, pozostałe kontynuują pracę z drugim węzłem. Wydajność spadła na kilka sekund z powodu przebudowy ścieżek, a następnie wróciła do normy. Nie było żadnych przerw w świadczeniu usług.

Test awarii szafy z całym sprzętem

W tym przypadku wydajność również spadła na kilka sekund z powodu restrukturyzacji ścieżek, a następnie wróciła do połowy pierwotnej wartości. Wynik został zmniejszony o połowę w stosunku do początkowego ze względu na wyłączenie z pracy jednego serwera aplikacji. Nie było też żadnych przerw w działaniu.

Jeśli istnieje potrzeba wdrożenia odpornego na błędy rozwiązania do odtwarzania po awarii typu Cross-Rack dla Oracle po rozsądnych kosztach i przy niewielkim wysiłku związanym z wdrażaniem/administracją, wówczas Oracle RAC i architektura współpracują ze sobą AccelStor Shared-Nic będzie jedną z najlepszych opcji. Zamiast Oracle RAC może być dowolne inne oprogramowanie umożliwiające klastrowanie, na przykład ten sam DBMS lub systemy wirtualizacji. Zasada konstruowania rozwiązania pozostanie taka sama. Wynik końcowy wynosi zero dla RTO i RPO.

Źródło: www.habr.com