Jakiś czas temu miałem problem z serwerem, na którym Apache i Snort zajmowali 100% procesora, przez co sshd nie reagował na dostęp zdalny. Musiałem udać się fizycznie na serwer, aby zalogować się do lokalnego TTY, a następnie zatrzymać apache / snort.
Zastanawiam się, czy istnieje sposób na zagwarantowanie łączności ssh w przypadku 100% obciążenia procesora / pamięci. Czy wystarczyłoby ustawić „miły” priorytet?
Dziękuję Ci!
Odpowiedzi:
Poza wykorzystaniem metody pozapasmowej nie ma możliwości zagwarantowania, że SSH będzie dostępny na w pełni załadowanym serwerze. Jeśli twoja usługa jest tak załadowana, że nie może ci nawet obsługiwać podstawowego terminala SSH, masz inne problemy.
Tak, renicea nadanie jej niższej nicewartości poprawi wydajność przy dużych obciążeniach, ale zamiast tego użycie czegoś takiego jak pam_security (przykład pokazany tutaj ) zapobiegnie niemożności zarządzania Apache / cokolwiek na początku.
nicewinowajca zostanie uruchomiony z procesora wystarczająco szybko, aby zapewnić dostęp do SSH (lub w tym przypadku każdy dostęp do konsoli byłby użyteczny). Należy rozwiązać zasadniczy problem (wieprz zasobów). Gaszenie pożarów to złe zarządzanie systemem.
Rozwiązaniem tego ogólnego zastosowania jest pozapasmowe narzędzie do zarządzania, takie jak Dell iDRAC, IBM Remote Supervisor lub HP iLO. Zawsze może prezentować konsolę (czy system operacyjny może na nią zareagować, zależy od konkretnej sytuacji) i zastosować pożądane stany zasilania w razie potrzeby.
Odniosłem pewien sukces, nadając sshd przywilej w czasie rzeczywistym, jednak wiąże się to z koniecznością ponownego uruchomienia komputera, jeśli jeden z procesów w czasie rzeczywistym ucieka.
Jeśli więc chcesz zejść tą drogą, uruchom drugiego demona ssh, który jest przeznaczony tylko na wypadek awarii. :)
realtimeing sshd wydaje mi się niebezpieczny, szczególnie na porcie 22 (skan SSH może stać się atakiem DoS - uruchomienie na alternatywnym porcie może to złagodzić, ale nadal bym się bał ...)