Tất cả các phiên ssh qua máy chủ chuyển sang vm đều chậm lại hoặc thậm chí hết thời gian chờ nếu ping một máy chủ đã chết từ bên trong một trong các phiên

xu wang

13:25, 19/12/2022

Env: vm1 và vm2 (cả redhat8.2) đều nằm sau cùng một cổng (Ubuntu 20.04.2) và cổng này cũng đóng vai trò là máy chủ nhảy cho macbook của tôi để ssh sang vm1 và vm2. Cổng này là cổng mặc định cho cả vm1 và vm2.

Tình huống: Tôi ssh tới vm1 với 2 phiên thông qua máy chủ nhảy và tôi cũng ssh tới vm2 qua máy chủ nhảy.

Vấn đề: Nếu tôi "ping" bất kỳ máy chủ chết nào hoặc "arping" bất kỳ máy chủ nào không thể truy cập được từ bên trong một trong các phiên ssh của tôi tới vm1, thì cả 2 phiên tới vm1 đều trở nên rất chậm thậm chí hết thời gian chờ. Và nó trở nên cực kỳ chậm khi tôi cố gắng ssh lại vm1 qua máy chủ nhảy.

Quan sát: Và điều thú vị là nếu tôi ssh từ vm2 sang vm1 thì mọi thứ đều hoạt động tốt, phiên làm việc mới này khá nhanh và tôi có thể thực hiện mọi thao tác bình thường như bình thường mà không hề bị chậm. Và nếu tôi tắt quá trình ping hoặc arping ở đây trước khi 2 phiên ssh đến vm1 hết thời gian, thì sau vài phút, cả 2 phiên ssh đến vm1 sẽ trở lại bình thường.

Bất cứ ý tưởng tại sao điều này xảy ra? cảm ơn rất nhiều!

macbook -> cổng (nhảy máy chủ x.x.0.1) -> vm1,vm2 (x.x.3.101, x.x.3.102)

0 + 3

xu wang

01:26, 20/12/2022

Và tôi nhận thấy rằng sự chậm lại xảy ra giữa máy chủ nhảy và vm1, bởi vì nếu tôi ssh đến vm1 trực tiếp từ máy chủ nhảy, nó cũng cực kỳ chậm. vì vậy có vẻ như hoạt động như cả cổng mặc định và máy chủ nhảy cho vm1 đã gây ra một số loại xung đột có thể liên quan đến arp ...

Hồi đáp

xu wang

02:24, 20/12/2022

Có vẻ như tôi đã tìm ra nguyên nhân gốc rễ có thể xảy ra, bởi vì máy chủ nhảy được sử dụng làm cổng mặc định cho số lượng lớn vms, vì vậy trên thực tế, nó không có địa chỉ mac của vm1 trong bộ đệm vì nó luôn gửi hàng tấn yêu cầu arp yêu cầu mac của tất cả các vms đằng sau nó, vì vậy nó luôn phải gửi một quảng bá arp để hỏi địa chỉ mac của vm1, nhưng bằng cách nào đó, lũ lụt các tin nhắn arp boradcast yêu cầu địa chỉ mac của máy chủ chết làm chậm quá trình cho cổng để lấy địa chỉ mac từ vm1.

Hồi đáp

xu wang

02:25, 20/12/2022

đây là lý do tại sao tất cả các phiên vm1 trở nên rất chậm. và vì vm2 đã có địa chỉ mac của vm1 trong bộ đệm của nó nên không có bất kỳ sự chậm lại nào khi tôi ssh từ vm2 sang vm1. Tôi đang nghĩ đến việc thêm kích thước bộ đệm arp cho cổng để giảm thiểu sự cố này...

Hồi đáp

Phan Văn Trường

Câu hỏi này là trong các ngôn ngữ khác:

EN: All ssh sessions via jump server to a vm slow down or even time out if ping a dead server from inside one of the session

TH: เซสชัน ssh ทั้งหมดผ่านเซิร์ฟเวอร์กระโดดไปยัง vm ช้าลงหรือแม้กระทั่งหมดเวลาหาก ping เซิร์ฟเวอร์ที่ไม่ทำงานจากภายในเซสชันใดเซสชันหนึ่ง

RO: Toate sesiunile ssh prin serverul de salt la un vm încetinesc sau chiar expiră dacă dați ping la un server mort din interiorul uneia dintre sesiuni

RU: Все сеансы ssh через сервер перехода на виртуальную машину замедляются или даже истекают по тайм-ауту, если пинговать мертвый сервер изнутри одного из сеансов.

VI: Tất cả các phiên ssh qua máy chủ chuyển sang vm đều chậm lại hoặc thậm chí hết thời gian chờ nếu ping một máy chủ đã chết từ bên trong một trong các phiên

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.