Rozwiązywanie problemów z eksmisjami węzłów Oracle RAC (ponownymi uruchomieniami) [11.2 i nowsze]

  • Giles Benson
  • 0
  • 4200
  • 682

Ten wpis zawiera informacje dotyczące rozwiązywania problemów z eksmisjami węzłów Clusterware w wersjach 11.2 i nowszych.

PRZEGLĄD WYDANIA WĘZŁÓW

Oracle Clusterware jest przeznaczony do eksmisji węzłów poprzez usunięcie jednego lub więcej węzłów z klastra w przypadku wykrycia krytycznego problemu. Krytycznym problemem może być brak odpowiedzi węzła przez puls sieci, węzeł nie odpowiadający przez puls dysku, zawieszona lub poważnie zdegradowana maszyna lub zawieszony proces ocssd.bin. Celem tej eksmisji węzła jest utrzymanie ogólnej kondycji klastra poprzez usunięcie złych członków.

Począwszy od wersji 11.2.0.2 RAC lub nowszej (lub jeśli korzystasz z Exadata), eksmisja węzła może w rzeczywistości nie spowodować ponownego uruchomienia komputera. Nazywa się to ponownym uruchomieniem komputera. W takim przypadku ponownie uruchamiamy większość stosu Clusterware, aby sprawdzić, czy to naprawi węzeł w złej kondycji.

ROLE PROCESOWE DLA REBOOTÓW

OCSSD (inaczej demon CSS) - Ten proces jest uruchamiany przez proces cssdagent. Działa zarówno w środowiskach klastrowych od dostawców, jak i innych producentów. Podstawowym zadaniem OCSSD jest monitorowanie stanu między węzłami i wykrywanie punktów końcowych instancji RDBMS. Monitorowanie kondycji obejmuje tętno sieci i tętno dysku (do plików głosowania). OCSSD może również ekskalować węzeł po eskalacji zabicia członka przez klienta (na przykład proces LMON bazy danych). Jest to proces wielowątkowy, który działa z podwyższonym priorytetem i działa jako użytkownik Oracle.

Sekwencja startowa: INIT -> init.ohasd -> ohasd -> ohasd.bin -> cssdagent -> ocssd -> ocssd.bin

CSSDAGENT - Ten proces jest uruchamiany przez OHASD i jest odpowiedzialny za tworzenie procesu OCSSD, monitorowanie zawieszeń węzłów (za pomocą funkcji oprocd) i monitorowanie procesu OCSSD pod kątem zawieszeń (za pośrednictwem funkcji oclsomon) oraz monitorowanie oprogramowania klastrowego dostawcy (za pośrednictwem funkcji vmon). Jest to proces wielowątkowy, który działa z podwyższonym priorytetem i działa jako użytkownik root.

Sekwencja startowa: INIT -> init.ohasd -> ohasd -> ohasd.bin -> cssdagent

CSSDMONITOR - Ten proces monitoruje również zawieszanie się węzłów (za pomocą funkcji oprocd), monitoruje proces OCSSD pod kątem zawieszeń (za pomocą funkcji oclsomon) i monitoruje oprogramowanie klastrowe dostawcy (za pomocą funkcji vmon). Jest to proces wielowątkowy, który działa z podwyższonym priorytetem i działa jako użytkownik root.

Sekwencja startowa: INIT -> init.ohasd -> ohasd -> ohasd.bin -> cssdmonitor

Określenie, który proces jest odpowiedzialny za ponowne uruchomienie

Ważne pliki do przejrzenia:

Logowanie do ostrzeżenia Clusterware:

Dzienniki cssdagent Dzienniki cssdmonitor Logi ocssd Log (y) lastgasp w / etc / oracle / lastgasp lub / var / opt / oracle / lastgasp CHM lub OS Watcher data 'opatch lsinventory -detail 'wyjście dla plików wiadomości domowych GRID

Lokalizacje plików wiadomości:

Linux: / var / log / messages Słońce / var / adm / messages HP-UX: /var/adm/syslog/syslog.log IBM: / bin / errpt -a> messages.out

11.2 Eksmisje oprogramowania klastrowego powinny w większości przypadków zawierać jakiś znaczący błąd w dzienniku alertów oprogramowania klastrowego. Można to wykorzystać do określenia, który proces jest odpowiedzialny za ponowne uruchomienie. Przykładowy komunikat z dziennika alertów oprogramowania klastrowego:

[ohasd (11243)] CRS-8011: komunikat doradczy dotyczący ponownego uruchomienia z hosta: sta00129, składnik: cssagent, z sygnaturą czasową: L-2009-05-05-10: 03: 25.340 [ohasd (11243)] CRS-8013: komunikat doradczy dotyczący ponownego uruchomienia treść wiadomości: ponowne uruchomienie po przekroczeniu limitu 28500; przekroczenie limitu czasu dysku 27630, przekroczenie limitu czasu sieci 28500, ostatnie tętno z CSSD w sekundach epoki 1241543005.340, 4294967295 milisekund temu na podstawie niezmiennej wartości zegara 93235653

Ta szczególna eksmisja miała miejsce, gdy przekroczyliśmy limit czasu sieci. CSSD wyszedł, a agent cssdagent podjął działania w celu eksmisji. Cssdagent zna informacje zawarte w komunikacie o błędzie z lokalnych pulsu utworzonych z CSSD.

Jeśli w dzienniku alertów oprogramowania klastrowego węzła eksmitowanego nie ma żadnego komunikatu, sprawdź dzienniki lastgasp w węźle lokalnym i / lub dzienniki alertów oprogramowania klastrowego innych węzłów.

Rozwiązywanie problemów z eksmisjami OCSSD

Jeśli spotkałeś się z eksmisją OCSSD, przejrzyj typowe przyczyny w sekcji poniżej.

NAJCZĘSTSZE PRZYCZYNY WYDANIA OCSSD

  • Awaria sieci lub opóźnienie między węzłami. Doprowadzenie węzła do eksmisji wymagałoby 30 kolejnych nieudanych zameldowań (domyślnie - określonych przez błąd CSS).
  • Problemy z zapisem lub odczytem z dysku CSS do głosowania. Jeśli węzeł nie może wykonać pulsu dysku dla większości swoich plików głosowania, węzeł zostanie usunięty.
  • Eskalacja zabójstw członka. Na przykład proces LMON bazy danych może zażądać od CSS usunięcia instancji z klastra za pośrednictwem mechanizmu eksmisji instancji. Jeśli to przekroczy limit czasu, może dojść do zabicia węzła.
  • Nieoczekiwana awaria lub zawieszenie procesu OCSSD, może to być spowodowane którymkolwiek z powyższych problemów lub czymś innym.
  • Błąd Oracle.

Plik do przejrzenia i ojciec w sprawie eksmisji OCSSD

Wszystkie pliki z sekcji „Określanie, który proces jest odpowiedzialny za ponowne uruchomienie” ze wszystkich węzłów klastra. Może być wymagane więcej danych.

Przykład eksmisji z powodu „utraty dysku do głosowania”

Dziennik CSS:

2012-03-27 22: 05: 48.693: [CSSD] [1100548416] (: CSSNM00018:) clssnmvDiskCheck: Przerwanie, dostępne są 0 z 3 skonfigurowanych dysków do głosowania, potrzeba 2 2012-03-27 22: 05: 48.693: [CSSD] [1100548416] ################################### 2012-03-27 22: 05: 48.693: [ CSSD] [1100548416] clssscExit: CSSD przerywa działanie z wątku clssnmvDiskPingMonitorThread

Komunikaty systemu operacyjnego:

27 marca 22:03:58 kernel choldbr132p: Błąd: Mpx: Wszystkie ścieżki do Symm 000190104720 vol 0c71 są martwe. 27 marca 22:03:58 kernel choldbr132p: Błąd: Mpx: Symm 000190104720 vol 0c71 nie żyje. 27 marca 22:03:58 jądro choldbr132p: Błąd we / wy bufora na urządzeniu sdbig, blok logiczny 0… 

Rozwiązywanie problemów z eksmisjami CSSDAGENT lub CSSDMONITOR

Jeśli napotkałeś eksmisję CSSDAGENT lub CSSDMONITOR, przejrzyj typowe przyczyny w sekcji poniżej.

Typowe przyczyny eksmisji CSSDAGENT lub CSSDMONITOR

  • Problem z harmonogramem systemu operacyjnego. Na przykład, jeśli system operacyjny jest blokowany w sterowniku lub sprzęcie lub występuje nadmierne obciążenie maszyny (przy 100% lub prawie 100% wykorzystania procesora), co uniemożliwia rozsądne zachowanie harmonogramu.
  • Wątek (y) w demonie CSS zawiesił się.
  • Błąd Oracle.

Plik do przejrzenia i zebrania pod kątem eksmisji CSSDAGENT lub CSSDMONITOR

Wszystkie pliki z sekcji „Określanie, który proces jest odpowiedzialny za ponowne uruchomienie” ze wszystkich węzłów klastra. Może być wymagane więcej danych.




Jeszcze bez komentarzy

Zbiór przydatnych informacji o systemie operacyjnym Linux i nowych technologiach
Świeże artykuły, praktyczne wskazówki, szczegółowe recenzje i poradniki. Poczuj się jak w domu w świecie systemu operacyjnego Linux