Dell Unity: SP mogą przejść w tryb serwisowy z powodu rozdęcia dziennika (partycja /nbsnas zostaje zapełniona w 100%)
Summary: Macierz może przejść w tryb serwisowy (dane niedostępne) z powodu rozdęcia dzienników (z możliwością naprawienia przez firmę Dell)
Symptoms
W przypadku macierzy z dwoma macierzami SP jeden SP systemu pamięci masowej przechodzi w tryb serwisowy, a cały system nie może być obsługiwany za pośrednictwem interfejsów zarządzania, w tym CLI, UI, REST API i SMI-S. Może się to również objawiać naprzemiennym ponownym uruchamianiem SP do momentu przejścia w tryb serwisowy.
Macierz Unity z obydwoma SP w trybie serwisowym nie będzie obsługiwać operacji we/wy, więc możemy mówić o niedostępności danych (DU).
W przypadku VSA pojedynczy SP może uruchomić się ponownie w trybie serwisowym lub pozostać w trybie normalnym, tracąc zarządzanie w obu przypadkach.
Cały system nie może być obsługiwany poprzez interfejsy zarządzania, w tym CLI, UI, REST API i SMI-S.
SSH lub IPMI powinny działać. IPMI działa zawsze, SSH może działać tylko po ustabilizowaniu macierzy.
Ten problem występuje w wersji OE 4.0.0.x i został rozwiązany w wersji OE 4.0.1.x.
Cause
Plik dziennika /nbsnas/http/logs/mod_jk.log, który rejestruje każde żądanie z interfejsu użytkownika i REST, znajduje się w systemie plików zamontowanym w /nbsnas głównego SP. Bez mechanizmu rotacji dziennika rozdęcie tego pliku nadal zajmuje dostępne miejsce w systemie plików. Inni odbiorniki wewnętrzni zaczynają ulegać awarii, gdy w systemie plików nie ma już miejsca. Jeden z SP przechodzi w tryb serwisowy po wykryciu powtarzających się awarii tych elementów.
W laboratorium zaobserwowano, że gdy tak się dzieje, a usługi próbują przełączyć się w tryb failover do dodatkowego SP, on również doświadcza tych samych objawów. SP uruchamiają się ponownie kilka razy na przemian, aż w końcu oba przechodzą w tryb serwisowy.
Klienci widzą ten problem, jeśli: zawsze używaj interfejsu użytkownika lub REST API do konfigurowania systemu pamięci masowej lub otwórz interfejs użytkownika w przeglądarce i pozostaw go tam bez zamykania. W przypadku dostępu tylko do interfejsu użytkownika zwykle problem pojawia się dopiero po kilku miesiącach. Jeśli klienci często używają interfejsu API REST do wysyłania zapytań o dane z systemu pamięci masowej, ten problem występuje szybciej.
Znaleziono drugi problem, w którym aktualizacja do wersji Unity OE 4.0.1.8320161 może zaostrzyć problem, ponieważ może duplikować dany plik dziennika podczas NDU, przyspieszając w ten sposób proces.
Jeśli tak jest, można to sprawdzić, sprawdzając wykorzystanie miejsca w katalogu /nbsbas. Jeśli zużycie miejsca jest minimalne lub niskie, NIE wystąpił ten problem podczas NDU i dlatego nic więcej nie jest wymagane.
Kody 4.0.1.x zawierają już poprawkę głównego problemu, więc sama rotacja dziennika działa poprawnie.
Jeśli partycja wykazuje bardzo wysoki procent wykorzystania, konieczne może być usunięcie odpowiedzialnych plików dziennika (wymaga pomocy technicznej firmy Dell).
Przykład sprawdzania wykorzystania miejsca i dzienników do usunięcia można znaleźć w sekcji uwag.
Firma Dell podjęła decyzję o usunięciu z support.emc.com Unity OE 4.0.1.8320161 dla Unity i UnityVSA. Poprawiona wersja Unity OE (4.0.1.8404134) została opublikowana we wrześniu 2016 r.
Resolution
Aby rozwiązać ten problem, konieczne jest uzyskanie przez dział pomocy technicznej uprawnień użytkownika root do macierzy.
Skontaktuj się z pomocą techniczną Unity i wspomnij o tym artykule z bazy wiedzy: 489057
Additional Information
Przykład sprawdzania wykorzystania miejsca:
spX:~> df -h /nbsnas Filesystem Size Used Avail Use% Mounted on /dev/c4nasdba1 1013M 55M 908M 6% /nbsnas
Dziennik lub dzienniki, które to powodują, można znaleźć w katalogu /nbsnas/http/logs:
spx:~> cd /nbsnas/http/logs spx:/nbsnas/http/logs> ll -h total 975M -rw-r--r-- 1 root root 12K Sep 8 13:32 access_log -rw-r--r-- 1 root root 165K Sep 8 08:45 access_log.1.gz -rw-r--r-- 1 root root 239K Sep 8 06:59 access_log.2.gz -rw-r--r-- 1 root root 1.6M Sep 8 13:32 error_log -rw-r--r-- 1 root root 167K Sep 3 04:56 error_log.1.gz -rw-r--r-- 1 root root 495M Sep 8 13:32 mod_jk.log <<<<<<<<<< -rw-r--r-- 1 root root 475M Sep 8 08:45 mod_jk.log.1 <<<<<<<<<<
svc_dc -lcd (lista zrzutów rdzenia) może również pokazać kilka zrzutów z sufiksem "_mgmtd".
Zostały one utworzone, gdy SP wpadają w panikę, ponieważ niektóre usługi nie mogą się uruchomić (z powodu zapełnienia /nbsnas).
spx:/> svc_dc -lcd ======================== [DC copier]: Available on backend: CP_dump_spb_CKM00161701xxx_2016-09-08_13_29_47_17275_ECOM core-dump_dump_spb_CKM00161701xxx_2016-09-08_08_46_23_778_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_09_18_19_11994_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_09_18_53_21524_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_09_41_05_11446_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_09_41_45_24620_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_13_28_30_3067_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_13_29_08_15086_mgmtd