우리는 수십 개의 Proxmox 서버 (Proxmox가 데비안에서 실행 됨)를 가지고 있으며, 한 달에 한 번, 그중 하나가 커널 패닉 상태가되어 잠 깁니다. 이러한 잠금에 대한 최악의 부분은 클러스터 마스터와 별도의 스위치에있는 서버 인 경우 실제로 충돌 한 서버를 찾아 재부팅 할 때까지 해당 스위치의 다른 모든 Proxmox 서버가 응답을 중지한다는 것입니다.
Proxmox 포럼에서이 문제를보고했을 때 Proxmox 3.1로 업그레이드하라는 권고를 받았으며 지난 몇 달 동안이 작업을 수행하고있었습니다. 불행히도, 우리가 Proxmox 3.1로 마이그레이션 한 서버 중 하나가 금요일에 커널 패닉으로 잠겼으며, 동일한 스위치에 있던 모든 Proxmox 서버는 충돌 한 서버를 찾아 재부팅 할 때까지 네트워크를 통해 연결할 수 없었습니다.
글쎄, 스위치의 거의 모든 Proxmox 서버 … 나는 여전히 Proxmox 버전 1.9에있는 동일한 스위치의 Proxmox 서버가 영향을받지 않았다는 것이 흥미로웠다.
충돌 서버의 콘솔 스크린 샷은 다음과 같습니다.
서버가 잠기면 Proxmox 3.1도 실행중인 동일한 스위치의 나머지 서버에 연결할 수 없어 다음과 같은 결과가 발생했습니다.
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
...etc...
uname-잠긴 서버의 출력 :
Linux ------ 2.6.32-23-pve #1 SMP Tue Aug 6 07:04:06 CEST 2013 x86_64 GNU/Linux
pveversion -v 출력 (약어) :
proxmox-ve-2.6.32: 3.1-109 (running kernel: 2.6.32-23-pve)
pve-manager: 3.1-3 (running version: 3.1-3/dc0e9b0e)
pve-kernel-2.6.32-23-pve: 2.6.32-109
두 가지 질문 :
-
커널 패닉을 유발하는 원인은 무엇입니까 (위 이미지 참조)?
-
잠긴 서버가 재부팅 될 때까지 동일한 스위치 및 Proxmox 버전의 다른 서버가 네트워크에서 차단되는 이유는 무엇입니까? (참고 : 동일한 스위치에는 이전 1.9 버전의 Proxmox를 실행하는 다른 서버가 영향을받지 않았으며 동일한 3.1 클러스터의 다른 Proxmox 서버는 동일한 스위치에 있지 않은 영향을받지 않았습니다.)
조언에 미리 감사드립니다.
답변
나는 당신의 문제가 단지 하나의 단일 요인이 아니라 여러 요인의 조합에 의한 것이라고 확신합니다. 이러한 개별 요소는 확실하지 않지만 네트워크 인터페이스 나 드라이버 중 하나이며 스위치 자체에 다른 요소가 있습니다. 따라서이 특정 브랜드의 네트워크 인터페이스와 결합 된이 특정 브랜드의 스위치로만 문제를 재현 할 수 있습니다.
문제의 트리거는 하나의 개별 서버에서 발생하는 것으로 보이지만 커널 패닉이 발생하여 스위치를 통해 전파되는 데 영향을 미칩니다. 이것은 아마도 들리지만, 방아쇠가 다른 곳일 가능성이 높습니다.
스위치 또는 네트워크 인터페이스에 문제가 발생하여 스위치에서 커널 패닉 및 링크 문제가 동시에 발생할 수 있습니다. 다시 말해, 커널에 커널 패닉이없는 경우에도 트리거가 스위치의 연결을 매우 낮출 수 있습니다.
개별 서버에서 발생할 수있는 일을 물어봐야하며, 이는 다른 서버에 영향을 줄 수 있습니다. 가능하지 않아야하므로 설명은 시스템 어딘가에 결함이 있어야합니다.
다운 된 서버와 다운되거나 불안정한 스위치 간의 링크 인 경우 다른 서버의 링크 상태에는 영향을 미치지 않습니다. 그렇다면 스위치의 결함으로 간주됩니다. 그리고 트래픽 측면에서 충돌이 발생한 서버의 연결이 끊어지면 다른 서버의 트래픽이 약간 줄어들게되므로 문제가 발생하는 이유를 설명 할 수 없습니다.
이로 인해 스위치의 설계 결함이있을 가능성이 있다고 생각합니다.
그러나 링크 문제는 한 서버의 문제가 스위치의 다른 서버에 문제를 일으킬 수있는 방법을 설명하려고 할 때 가장 먼저 설명하는 설명이 아닙니다. 방송 폭풍이 더 분명한 설명이 될 것입니다. 그러나 커널 패닉이있는 서버와 브로드 캐스트 스톰간에 링크가있을 수 있습니까?
알려지지 않은 MAC 주소로 향하는 멀티 캐스트 및 패킷은 브로드 캐스트와 거의 동일하게 취급되므로 이러한 패킷의 스톰도 계산됩니다. 패닉 된 서버가 네트워크를 통해 충돌 덤프를 스위치가 인식하지 못하는 MAC 주소로 보내려고 시도 할 수 있습니까?
이것이 트리거 인 경우 다른 서버에서 문제가 발생합니다. 패킷 스톰은 네트워크 인터페이스에서 이러한 종류의 오류를 발생시키지 않아야합니다. Reset adapter unexpectedly패킷 스톰처럼 들리지 않아 (성능 저하 만 발생하지만 오류는 발생하지 않아야 함) 링크 문제처럼 보이지 않습니다 (링크 다운에 대한 메시지가 발생했지만 오류는 아닙니다) 봄).
따라서 네트워크 인터페이스 하드웨어 나 드라이버에 결함이있을 수 있으며 스위치에 의해 트리거됩니다.
추가 힌트를 줄 수있는 몇 가지 제안 :
- 다른 장비를 스위치에 연결하고 문제가 표시 될 때 스위치에 어떤 트래픽이 나타나는지 확인할 수 있습니까?
- 다른 드라이버를 사용하여 서버 중 하나의 네트워크 인터페이스를 다른 브랜드로 교체하여 결과가 어떻게 다른지 확인할 수 있습니까?
- 스위치 중 하나를 다른 브랜드로 교체 할 수 있습니까? 스위치를 교체하면 문제가 더 이상 여러 서버에 영향을 미치지 않습니다. 더 흥미로운 것은 커널 패닉이 발생하지 않도록 막는 것입니다.
답변
이더넷 드라이버 또는 하드웨어 / 펌웨어의 버그처럼 들립니다.
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
나는 이것을 전에 보았고 서버를 오프라인으로 만들 수 있습니다. 인텔 이더넷 카드에 있는지 정확히 기억하지 못하지만 그렇게 생각합니다. 이더넷 카드 자체의 버그와 관련이있을 수도 있습니다. 그런 문제가있는 특정 인텔 이더넷 카드에 대해 읽은 것을 기억합니다. 그러나 기사의 링크를 잃어 버렸습니다.
나는 이것에 대한 트리거가 사용중인 드라이버 (버전)에 부분적으로 달려 있다고 생각할 것입니다. 이전 버전의 소프트웨어가 정상적으로 작동한다는 사실은 그것을 확인하는 것 같습니다. 벤더가 자체 사용자 정의 커널을 사용한다고 말하면 특정 이더넷 하드웨어에 사용되는 이더넷 드라이버 모듈을 업데이트하십시오. 공급 업체 또는 공식 커널 소스 트리 중 하나입니다.
또한 이더넷 하드웨어 본딩을 살펴보십시오. 일반적으로 서버에는 두 개의 이더넷 포트가 있으며 내장 및 / 또는 카드에 추가합니다. 이렇게하면 한 이더넷 카드에이 문제가 발생하면 다른 이더넷 카드가 선택됩니다. “카드”라는 단어를 사용하지만 물론 모든 이더넷 하드웨어에 적용됩니다.
또한 이더넷 하드웨어를 교체하면 문제를 해결할 수 있습니다. 최신 (인텔) 이더넷 카드를 교체하거나 추가 한 후 대신 사용하십시오. 문제가 하드웨어 / 펌웨어에있는 경우 최신 카드에 수정 (또는 이전 버전)이있을 수 있습니다.
