Wiele aplikacji oraz systemów wirtualizacji klasy enterprise ma własne mechanizmy tworzenia rozwiązań odpornych na awarie. Przykładem jest Oracle RAC (Oracle Real Application Cluster), który składa się z dwóch lub więcej serwerów baz danych Oracle współpracujących w celu równoważenia obciążenia i zapewnienia odporności na awarie na poziomie serwera/aplikacji. Aby funkcjonować w tym trybie, potrzebne jest wspólne przechowywanie danych, którym zazwyczaj jest macierz dyskowa.
Jak już omówiliśmy w jednej z naszych , sama macierz dyskowa, mimo posiadania zduplikowanych komponentów (w tym kontrolerów), nadal ma punkty awarii – głównie w postaci pojedynczego zestawu danych. Dlatego, aby zbudować rozwiązanie Oracle o podwyższonej niezawodności, schemat „N serwerów – jedna macierz dyskowa” należy skomplikować.
Przede wszystkim należy określić, przed jakimi ryzykami się zabezpieczamy. W ramach tego artykułu nie będziemy omawiać ochrony przed zagrożeniami typu 'przyleciał meteoryt'. Tak więc budowa geograficznie rozproszonego rozwiązania disaster recovery pozostanie tematem jednego z kolejnych artykułów. Tutaj rozważymy tzw. rozwiązanie Cross-Rack disaster recovery, gdzie ochrona budowana jest na poziomie szaf serwerowych. Same szafy mogą znajdować się zarówno w jednym pomieszczeniu, jak i w różnych, ale zazwyczaj w obrębie jednego budynku.
Te szafy powinny zawierać cały niezbędny zestaw sprzętu i oprogramowania, który pozwoli na działanie baz danych Oracle niezależnie od stanu 'sąsiada'. Innymi słowy, korzystając z rozwiązania Cross-Rack disaster recovery, eliminujemy ryzyko w przypadku awarii:
- Serwery aplikacji Oracle
- Systemy przechowywania
- Systemy komunikacyjne
- Pełne usunięcie całego sprzętu w szafie:
- Zerwanie zasilania
- Zerwanie systemu chłodzenia
- Czynniki zewnętrzne (ludzie, natura i inne)
Duplikacja serwerów Oracle polega na podstawowej zasadzie działania Oracle RAC i jest realizowana za pomocą aplikacji. Duplikacja środków komunikacyjnych również nie stanowi problemu. Jednak duplikacja systemu przechowywania jest znacznie bardziej skomplikowana.
Najprostsza opcja to replikacja danych z głównej macierzy na zapasową. Może być synchroniczna lub asynchroniczna, w zależności od możliwości macierzy. W przypadku replikacji asynchronicznej pojawia się od razu problem zapewnienia spójności danych względem Oracle. Ale nawet jeśli istnieje programowa integracja z aplikacją, w każdym razie, w przypadku awarii głównej macierzy, wymagane będzie ręczne zaangażowanie administratorów, aby przełączyć klaster na zapasowe przechowywanie.
Bardziej skomplikowaną opcją są programowe i/lub sprzętowe „wirtualizatory” macierzy, które eliminują problemy ze spójnością i ręcznym zaangażowaniem. Jednak złożoność wdrożenia i późniejszego administrowania, a także dość wysokie koszty takich rozwiązań odstraszają wielu.
Dla takich scenariuszy, jak Cross-Rack disaster recovery, doskonale nadaje się rozwiązanie All Flash AccelStor NeoSapphire™. z wykorzystaniem architektury Shared-Nothing. Ten model stanowi dwuwęzłowy system przechowywania, który wykorzystuje własną technologię FlexiRemap® do pracy z pamięcią flash. Dzięki NeoSapphire™ H710 jest w stanie zapewniać wydajność do 600K IOPS@4K losowe zapisy i 1M+ IOPS@4K losowe odczyty, co jest niedostępne przy użyciu klasycznych macierzy opartych na RAID.
Jednak główną cechą NeoSapphire™ H710 jest wykonanie dwóch węzłów w postaci oddzielnych obudów, z których każda ma własną kopię danych. Synchronizacja węzłów odbywa się przez zewnętrzny interfejs InfiniBand. Dzięki takiej architekturze możliwe jest rozmieszczenie węzłów w różnych lokalizacjach w odległości do 100m, zapewniając tym samym rozwiązanie Cross-Rack disaster recovery. Oba węzły działają całkowicie w trybie synchronicznym. Z perspektywy hostów H710 wygląda jak zwykła macierz z dwoma kontrolerami. Dlatego nie trzeba wykonywać żadnych dodatkowych opcji programowych i sprzętowych ani szczególnie skomplikowanych ustawień.
Porównując wszystkie powyższe rozwiązania Cross-Rack disaster recovery, opcja AccelStor wyraźnie wyróżnia się na tle innych:
AccelStor NeoSapphire™ Shared Nothing Architecture
Programowy lub sprzętowy „wirtualizator” macierzy
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
Awaria całej szafy
Brak przestojów
Brak przestojów
Przestoje
Koszt i złożoność
Koszt rozwiązania
Niski*
Wysokie
Wysokie
Złożoność wdrożenia
Niski
Wysokie
Wysokie
*AccelStor NeoSapphire™ to wciąż macierz All Flash, która z definicji nie kosztuje «3 grosze», tym bardziej mając dwukrotny zapas pojemności. Jednak porównując końcowy koszt rozwiązania opartego na tej technologii z podobnymi oferowanymi przez innych dostawców, można uznać tę cenę za niską.
Topologia połączenia serwerów aplikacji i węzłów macierzy All Flash będzie wyglądać następująco:
Podczas planowania topologii zdecydowanie zaleca się również wykonanie duplikacji przełączników zarządzających i interkonekcji serwerów.
Od tego miejsca będziemy rozmawiać o połączeniach przez Fibre Channel. W przypadku użycia iSCSI wszystko będzie wyglądać podobnie, z uwzględnieniem używanych typów przełączników i nieco innych ustawień macierzy.
Przygotowanie do pracy na macierzy
Używane sprzęt i oprogramowanie
Specyfikacje serwerów i przełączników
Składniki
Opis
Serwery Oracle Database 11g
Dwa
System operacyjny serwera
Oracle Linux
Wersja bazy danych Oracle
11g (RAC)
Procesory na serwer
Dwa procesory Intel® Xeon® CPU E5-2667 v2 @ 3.30GHz z 16 rdzeniami
Fizyczna pamięć na serwer
128 GB
Sieć FC
16 Gb/s FC z wieloma ścieżkami
FC HBA
Emulex Lpe-16002B
Dedykowane publiczne porty 1GbE do zarządzania klastrem
Karta sieciowa Intel RJ45
Przełącznik FC 16Gb/s
Brocade 6505
Dedykowane prywatne porty 10GbE do synchronizacji danych
Intel X520
Specyfikacja macierzy AccelStor NeoSapphire™ All Flash
Składniki
Opis
System pamięci masowej
Model wysokiej dostępności NeoSapphire™: H710
Wersja obrazu
4.0.1
Łączna liczba dysków
48
Rozmiar dysku
1.92 TB
Typ dysku
SSD
Porty docelowe FC
16 x 16Gb portów (8 na węzeł)
Porty zarządzania
Kabel ethernetowy 1GbE łączący hosty poprzez przełącznik ethernetowy
Port heartbeat
Kabel ethernetowy 1GbE łączący dwa węzły pamięci masowej
Port synchronizacji danych
Kabel InfiniBand 56Gb/s
Przed rozpoczęciem korzystania z macierzy należy ją zainicjować. Domyślnie adres zarządzania obu węzłów jest taki sam (192.168.1.1). Należy kolejno połączyć się z nimi i ustawić nowe (już różne) adresy zarządzania oraz skonfigurować synchronizację czasu, po czym porty zarządzania można podłączyć do jednej sieci. Następnie należy połączyć węzły w parę HA, przypisując podsieci dla połączeń interlink.
Po zakończeniu inicjalizacji macierzą można zarządzać z dowolnego węzła.
Następnie tworzymy potrzebne wolumeny i publikujemy je dla serwerów aplikacji.
Zdecydowanie zaleca się utworzenie kilku wolumenó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 miejscu). ).
Konfiguracja testowa
Nazwa wolumenu pamięci
Rozmiar wolumenu
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
Redo01
100GB
Redo02
100GB
Redo03
100GB
Redo04
100GB
Redo05
100GB
Redo06
100GB
Redo07
100GB
Redo08
100GB
Redo09
100GB
Redo10
100GB
Kilka wyjaśnień dotyczących trybów pracy macierzy oraz procesów zachodzących w sytuacjach awaryjnych
Każdy zestaw danych w węźle ma parametr „numer wersji”. Po wstępnym zainicjowaniu jest on taki sam i wynosi 1. Jeśli z jakiegoś powodu numer wersji jest różny, zawsze zachodzi synchronizacja danych z wersji starszej do nowszej, po czym numer wersji w wersji starszej zostaje wyrównany, co oznacza, że kopie są identyczne. Powody, dla których wersje mogą być różne:
- Zaplanowane ponowne uruchomienie jednego z węzłów
- Awaria jednego z węzłów spowodowana nagłym wyłączeniem (zasilanie, przegrzanie itd.).
- Przerwanie połączenia InfiniBand z brakiem możliwości synchronizacji
- Awaria jednego z węzłów spowodowana uszkodzeniem danych. W tym przypadku będzie wymagana utworzenie nowej grupy HA i pełna synchronizacja zestawu danych.
W każdym przypadku węzeł, który pozostaje online, zwiększa swój numer wersji o jeden, aby po przywróceniu połączenia z parą zsynchronizować jej zestaw danych.
Jeśli dochodzi do przerwania połączenia przez link Ethernet, to Heartbeat tymczasowo przełącza się na InfiniBand i wraca z powrotem w ciągu 10 sekund po jego przywróceniu.
Konfiguracja hostów
Aby zapewnić odporność na awarie i zwiększyć wydajność, konieczne jest włączenie wsparcia MPIO dla macierzy. W tym celu należy dodać do pliku /etc/multipath.conf odpowiednie linie, a następnie ponownie uruchomić usługę multipath
Ukryty tekstdevices {
urządzenie {
dostawca „AStor”
polityka_grupowania_ścieżek „grupa_na_prio”
selekcjoner_ścieżek „kolejność-0”
sprawdzanie_ścieżki „tur”
funkcje „0”
obsługa_sprzętowa „0”
priorytet „stały”
natychmiastowe_przywracanie
czas_ulegania_awarii_io 5
czas_ulegania_awarii_urządzenia 60
przyjazne_nazwy_użytkownika tak
wykrywanie_prio tak
rr_min_io_rq 1
brak_retry_ścieżki 0
}
}
Następnie, aby ASM działał z MPIO za pośrednictwem ASMLib, należy zmienić plik /etc/sysconfig/oracleasm i następnie wykonać /etc/init.d/oracleasm scandisks
Ukryty tekst
# ORACLEASM_SCANORDER: Matching patterns to order disk scanning
ORACLEASM_SCANORDER=„dm”
# ORACLEASM_SCANEXCLUDE: Matching patterns to exclude disks from scan
ORACLEASM_SCANEXCLUDE=„sd”
Uwaga
Jeśli nie ma chęci korzystać z ASMLib, można zastosować zasady UDEV, które są podstawą ASMLib.
Od wersji 12.1.0.2 opcja Oracle Database jest dostępna do zainstalowania jako część oprogramowania ASMFD.
Należy upewnić się, że tworzone dyski dla Oracle ASM są wyrównane względem rozmiaru bloku, z którym fizycznie pracuje macierz (4K). W przeciwnym razie mogą wystąpić problemy z wydajnością. Dlatego należy tworzyć wolumeny z odpowiednimi parametrami:
parted /dev/mapper/nazwa-urządzenia mklabel gpt mkpart primary 2048s 100% align-check optimal 1
Przydział baz danych według utworzonych wolumenów dla naszej testowej konfiguracji
Nazwa wolumenu pamięci
Rozmiar wolumenu
Mapowanie wolumenów LUN
Szczegóły urządzenia wolumenu ASM
Rozmiar jednostki alokacji
Data01
200GB
Przypisz wszystkie wolumeny pamięci do systemu pamięci po wszystkich portach danych
Niezawodność: 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
Niezawodność: Normalna
Nazwa: DGGRID1
Cel: Grid: CRS i głosowanie
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Niezawodność: Normalna
Nazwa: DGGRID2
Cel: Grid: CRS i głosowanie
4MB
Grid05
1GB
Grid06
1GB
Redo01
100GB
Niezawodność: Normalna
Nazwa: DGREDO1
Cel: Dziennik redo wątku 1
4MB
Redo02
100GB
Redo03
100GB
Redo04
100GB
Redo05
100GB
Redo06
100GB
Niezawodność: Normalna
Nazwa: DGREDO2
Cel: Dziennik redo wątku 2
4MB
Redo07
100GB
Redo08
100GB
Redo09
100GB
Redo10
100GB
Ustawienia bazy danych
- Rozmiar bloku = 8K
- Przestrzeń wymiany = 16GB
- 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
✓ kernel.shmall 31457280
✓ kernel.shmmn 4096
✓ kernel.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.swappiness=10
✓ vm.min_free_kbytes=524288 # nie ustawiaj tego, jeśli używasz Linux x86
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ grid soft nproc 2047
✓ grid hard nproc 16384
✓ grid soft nofile 1024
✓ grid hard nofile 65536
✓ grid soft stack 10240
✓ grid hard stack 32768
✓ oracle soft nproc 2047
✓ oracle hard nproc 16384
✓ oracle soft nofile 1024
✓ oracle hard nofile 65536
✓ oracle soft stack 10240
✓ oracle hard stack 32768
✓ soft memlock 120795954
✓ hard memlock 120795954
sqlplus “/as sysdba”
alter system set processes=2000 scope=spfile;
alter system set open_cursors=2000 scope=spfile;
alter system set session_cached_cursors=300 scope=spfile;
alter system set db_files=8192 scope=spfile;
Test odporności na awarie
W celu demonstracji użyto HammerDB do emulacji obciążenia OLTP. Konfiguracja HammerDB:
Liczba magazynów
256
Całkowita liczba transakcji na użytkownika
1000000000000
Wirtualni użytkownicy
256
W wyniku uzyskano wskaźnik 2.1M TPM, co daleko odbiega od możliwości wydajnościowych macierzy , ale jest „sufitem” dla aktualnej konfiguracji sprzętowej serwerów (przede wszystkim z powodu procesorów) i ich liczby. Celem tego testu jest jednak demonstracja odporności rozwiązania w całości, a nie osiągnięcie maksymalnych wydajności. Dlatego będziemy po prostu opierać się na tej liczbie.
Test na awarię jednej z węzłów
Hosty straciły część ścieżek do pamięci masowej, kontynuując pracę przez pozostałe z drugim węzłem. Wydajność spadła na kilka sekund z powodu rekonstrukcji ścieżek, a następnie wróciła do normalnych wartości. Nie było przerwy w świadczeniu usług.
Test na awarię szafy z całym sprzętem
W tym przypadku wydajność również spadła na kilka sekund z powodu rekonstrukcji ścieżek, a następnie wróciła do połowy wartości od początkowego wskaźnika. Wynik zmniejszył się o połowę w stosunku do pierwotnego z powodu wyłączenia jednego serwera aplikacji. Przerwy w świadczeniu usług również nie było.
Jeśli istnieje potrzeba wdrożenia odpornego na awarie rozwiązania typu Cross-Rack disaster recovery dla Oracle w rozsądnej cenie i przy niewielkim wysiłku w zakresie wdrażania/administrowania, to współpraca Oracle RAC z architekturą będzie jednym z najlepszych wyborów. Zamiast Oracle RAC może to być każde inne oprogramowanie obsługujące klasteryzację, te same DBMS lub systemy wirtualizacji, na przykład. Zasada budowy rozwiązania pozostanie taka sama, a końcowy wskaźnik – to zerowa wartość dla RTO i RPO.
Źródło: habr.com
