Tôi đã gặp sự cố một thời gian trước với một máy chủ trong đó Apache và Snort đang chiếm 100% bộ xử lý, khiến sshd không phản hồi thông qua truy cập từ xa. Tôi đã phải đi đến máy chủ để đăng nhập vào một TTY cục bộ và sau đó dừng apache / khịt mũi.
Tôi tự hỏi liệu có cách nào đảm bảo kết nối ssh trong tình huống CPU / bộ nhớ được tải 100% không. Đặt mức độ ưu tiên "tốt đẹp" là đủ?
Cảm ơn bạn!
Câu trả lời:
Ngoài việc sử dụng phương pháp ngoài băng tần, không có cách nào để đảm bảo rằng SSH sẽ có sẵn trên một máy chủ được tải đầy đủ. Nếu dịch vụ của bạn được tải đến mức nó thậm chí không thể phục vụ thiết bị đầu cuối SSH cơ bản cho bạn, thì bạn có vấn đề khác.
Đúng, renicevà cung cấp cho nó một nicegiá trị thấp hơn sẽ cải thiện hiệu suất trong các tải nặng, nhưng thay vào đó, việc sử dụng thứ gì đó như pam_security (ví dụ được hiển thị ở đây ) sẽ ngăn Apache / bất cứ thứ gì trở nên không thể quản lý được.
nicethủ phạm sẽ được khởi động khỏi CPU đủ nhanh để đảm bảo bạn có quyền truy cập SSH (hoặc cho vấn đề đó bất kỳ quyền truy cập bàn điều khiển nào bạn có thể sử dụng được). Các vấn đề cơ bản (tài nguyên con heo) cần phải được giải quyết. Chữa cháy là quản lý hệ thống kém.
Giải pháp cho mục đích chung của bạn cho việc này là một công cụ quản lý ngoài băng, như Dell iDRAC, Trình giám sát từ xa của IBM hoặc HP iLO. Nó luôn có thể hiển thị bảng điều khiển (hệ điều hành có thể đáp ứng với nó hay không tùy thuộc vào tình huống cụ thể của bạn) và áp dụng trạng thái năng lượng mong muốn khi cần.
Tôi đã có một số thành công khi trao đặc quyền thời gian thực cho sshd, tuy nhiên điều đó phải trả giá khi phải khởi động lại máy nếu một trong các quy trình thời gian thực chạy đi.
Vì vậy, nếu bạn muốn đi xuống tuyến đường này, hãy bắt đầu một daemon ssh thứ hai chỉ dành cho trường hợp khẩn cấp. :)
realtimeing sshd có vẻ nguy hiểm đối với tôi, đặc biệt là trên cổng 22 (quét SSH có thể trở thành một cuộc tấn công DoS - chạy trên một cổng thay thế có thể giảm thiểu điều đó, nhưng tôi vẫn sợ ...)