서버 잠금이 다른 서버를 네트워크에서 차단하는 이유는 무엇입니까?


9

우리는 수십 개의 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

두 가지 질문 :

  1. 커널 패닉을 유발하는 원인은 무엇입니까 (위 이미지 참조)?

  2. 잠긴 서버가 재부팅 될 때까지 동일한 스위치 및 Proxmox 버전의 다른 서버가 네트워크에서 차단되는 이유는 무엇입니까? (참고 : 동일한 스위치에는 이전 1.9 버전의 Proxmox를 실행하는 다른 서버가 영향을받지 않았으며 동일한 3.1 클러스터의 다른 Proxmox 서버는 동일한 스위치에 있지 않은 영향을받지 않았습니다.)

조언에 미리 감사드립니다.


전체 충돌 덤프를 줄 수 있습니까? 위의 그림은 흥미로운 부분을 잘라 냈습니다. 또한 lkml에 크래시 덤프를 게시 습니까? 그러나 다시 한 번 살펴보면 꽤 오래된 커널입니다. 데비안을 현재의 안정적인 릴리스로 업그레이드 할 계획입니까?
ckujau

불행히도 크래시 덤프는 없습니다. 직렬 콘솔 및 / 또는 kdump를 구성하기 위해 목록에 추가했습니다. 오래된 커널은 Proxmox가 주류 커널과 분리 된 OpenVZ 커널을 사용합니다. 따라서 크래시 덤프가 작동하면 OpenVZ 개발자에게 도움을 요청할 것입니다. 귀하의 의견에 감사드립니다 ... 그것은 올바른 방향으로 지적하는 데 도움이되었습니다.
커티스

어떤 종류의 스위치?
ETL

이 문제는 3 개의 다른 스위치 (하나의 dlink와 2 개의 cisco)에서 발생했습니다. 이전 두 스위치에는 모델 번호가 없지만 최신은 Cisco SG102-24입니다. 동일한 커널을 실행하는 스위치의 서버에만 영향을 미치며 세 번째 스위치를 사용하기 때문에 스위치가 비난받을 가능성이 거의 없습니다 (원래의 생각이기도했지만).
커티스

누군가가 다음과 같은 의견을 게시했다는 이메일 알림을 받았습니다. "하드 컨테이너를 사용하는 몇 개의 컨테이너로 충돌을 일으킬 수 있다는 점을 제외하고는 비슷한 문제가 있습니다 ..." 여기서 저자는 의견을 삭제하여 나머지 내용이 무엇인지 알 수 없습니다. 그러나 백업이 실행되는 경우처럼 네트워크 트래픽이 많은 경우 문제가 가장 자주 발생하는 것 같습니다. 아마도 그 의견은 "하드 코어 네트워크 전송"일까요?
커티스

답변:


2

나는 당신의 문제가 단지 하나의 단일 요인이 아니라 여러 요인의 조합에 의한 것이라고 확신합니다. 이러한 개별 요소는 확실하지 않지만 네트워크 인터페이스 나 드라이버 중 하나이며 스위치 자체에 다른 요소가 있습니다. 따라서이 특정 브랜드의 네트워크 인터페이스와 결합 된이 특정 브랜드의 스위치로만 문제를 재현 할 수 있습니다.

문제의 트리거는 하나의 개별 서버에서 발생하는 것으로 보이지만 커널 패닉이 발생하여 스위치를 통해 전파되는 데 영향을 미칩니다. 이것은 아마도 들리지만, 방아쇠가 다른 곳일 가능성이 높습니다.

스위치 또는 네트워크 인터페이스에 문제가 발생하여 스위치에서 커널 패닉 및 링크 문제가 동시에 발생할 수 있습니다. 다시 말해, 커널에 커널 패닉이없는 경우에도 트리거가 스위치의 연결을 매우 낮출 수 있습니다.

개별 서버에서 발생할 수있는 일을 물어봐야하며, 이는 다른 서버에 영향을 줄 수 있습니다. 가능하지 않아야하므로 설명은 시스템 어딘가에 결함이 있어야합니다.

다운 된 서버와 다운되거나 불안정한 스위치 간의 링크 인 경우 다른 서버의 링크 상태에는 영향을 미치지 않습니다. 그렇다면 스위치의 결함으로 간주됩니다. 그리고 트래픽 측면에서 충돌이 발생한 서버의 연결이 끊어지면 다른 서버의 트래픽이 약간 줄어들게되므로 문제가 발생하는 이유를 설명 할 수 없습니다.

이로 인해 스위치의 설계 결함이있을 가능성이 있다고 생각합니다.

그러나 링크 문제는 한 서버의 문제가 스위치의 다른 서버에 문제를 일으킬 수있는 방법을 설명하려고 할 때 가장 먼저 설명하는 설명이 아닙니다. 방송 폭풍이 더 분명한 설명이 될 것입니다. 그러나 커널 패닉이있는 서버와 브로드 캐스트 스톰간에 링크가있을 수 있습니까?

알려지지 않은 MAC 주소로 향하는 멀티 캐스트 및 패킷은 브로드 캐스트와 거의 동일하게 취급되므로 이러한 패킷의 스톰도 계산됩니다. 패닉 된 서버가 네트워크를 통해 충돌 덤프를 스위치가 인식하지 못하는 MAC 주소로 보내려고 시도 할 수 있습니까?

이것이 트리거 인 경우 다른 서버에서 문제가 발생합니다. 패킷 스톰은 네트워크 인터페이스에서 이러한 종류의 오류를 발생시키지 않아야합니다. Reset adapter unexpectedly패킷 스톰처럼 들리지 않아 (성능 저하 만 발생하지만 오류는 발생하지 않아야 함) 링크 문제처럼 보이지 않습니다 (링크 다운에 대한 메시지가 발생했지만 오류는 아닙니다) 봄).

따라서 네트워크 인터페이스 하드웨어 나 드라이버에 결함이있을 수 있으며 스위치에 의해 트리거됩니다.

추가 힌트를 줄 수있는 몇 가지 제안 :

  1. 다른 장비를 스위치에 연결하고 문제가 표시 될 때 스위치에 어떤 트래픽이 나타나는지 확인할 수 있습니까?
  2. 다른 드라이버를 사용하여 서버 중 하나의 네트워크 인터페이스를 다른 브랜드로 교체하여 결과가 어떻게 다른지 확인할 수 있습니까?
  3. 스위치 중 하나를 다른 브랜드로 교체 할 수 있습니까? 스위치를 교체하면 문제가 더 이상 여러 서버에 영향을 미치지 않습니다. 더 흥미로운 것은 커널 패닉이 발생하지 않도록 막는 것입니다.

당신의 사려 깊은 답변에 감사드립니다. 당신의 3 가지 제안과 관련하여 : 1) 어떤 유형의 장비 / 소프트웨어가 그렇게됩니까? 2) 가능하지만 많은 서버가 관련되어 있으며 다음에 어디에서 문제가 발생할지 모르겠습니다. 3) 나는 이미 3 개의 다른 스위치 (3 개의 다른 모델, 2 개의 다른 브랜드)를 시도했습니다. 흥미로운 것은 같은 버전의 Proxmox에있는 서버 만 영향을 받는다는 것입니다. Proxmox에는 클러스터 동기화 메커니즘이 있으므로 이와 관련이 있다고 생각합니다. 다행히도 문제가 발생한 지 몇 달이 지났습니다.
커티스

스위치의 트래픽을 살펴보기 위해 일반 PC를 tcpdump 및 / 또는 wireshark와 연결하려고 생각했습니다. 분명히 해당 PC에 영향을받는 소프트웨어가 설치되지 않도록하고 싶을 것입니다. 그러나 실제로 Proxmox가 커널에 설치하는 코드에 버그가 있어야하는 것처럼 들립니다. 아주 드물게 발생하여 한 달에 한 번만 표시되고 한 번에 하나의 스위치에서만 표시되는 경우 추적하는 데 시간이 오래 걸릴 수 있습니다. 더 많은 아이디어가 나오면 그것에 대해 조금 생각하고 논평 할 것입니다.
kasperd

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

나는 이것을 전에 보았고 서버를 오프라인으로 만들 수 있습니다. 인텔 이더넷 카드에 있는지 정확히 기억하지 못하지만 그렇게 생각합니다. 이더넷 카드 자체의 버그와 관련이있을 수도 있습니다. 그런 문제가있는 특정 인텔 이더넷 카드에 대해 읽은 것을 기억합니다. 그러나 기사의 링크를 잃어 버렸습니다.

나는 이것에 대한 트리거가 사용중인 드라이버 (버전)에 부분적으로 달려 있다고 생각할 것입니다. 이전 버전의 소프트웨어가 정상적으로 작동한다는 사실은 그것을 확인하는 것 같습니다. 벤더가 자체 사용자 정의 커널을 사용한다고 말하면 특정 이더넷 하드웨어에 사용되는 이더넷 드라이버 모듈을 업데이트하십시오. 공급 업체 또는 공식 커널 소스 트리 중 하나입니다.

또한 이더넷 하드웨어 본딩을 살펴보십시오. 일반적으로 서버에는 두 개의 이더넷 포트가 있으며 내장 및 / 또는 카드에 추가합니다. 이렇게하면 한 이더넷 카드에이 문제가 발생하면 다른 이더넷 카드가 선택됩니다. "카드"라는 단어를 사용하지만 물론 모든 이더넷 하드웨어에 적용됩니다.

또한 이더넷 하드웨어를 교체하면 문제를 해결할 수 있습니다. 최신 (인텔) 이더넷 카드를 교체하거나 추가 한 후 대신 사용하십시오. 문제가 하드웨어 / 펌웨어에있는 경우 최신 카드에 수정 (또는 이전 버전)이있을 수 있습니다.


시스템에는 모두 이중 이더넷 포트가 있지만이 오류는 시스템 중 하나가 잠기는 순간에 동일한 스위치에있는 여러 서버에서 동시에 발생합니다. 하나의 잠긴 서버의 전원을 껐다 켜면 영향을받는 모든 서버에 즉시 다시 액세스 할 수 있습니다. 이것은 잠긴 서버가 완전히 잠기지 않았지만 어떻게 든 같은 스위치에있는 머신의 리셋을 범람하고 있음을 나타냅니다. 드라이버 업데이트가 도움이 될 수 있는지 확인하는 것이 흥미로울 수 있지만 다른 이더넷 카드를 활성화하면 증거를 바탕으로 도움이 될 수 있다고 생각하지 않습니다.
Curtis

오래된 스레드이지만 Intel e1000e NIC 모델 82574L 및 최신 ProxMox 버전 5.0-23 / af4267bf 중 하나라도 네트워크 문제는 여전히 남아 있습니다. 동일한 스위치에 연결된 Windows 랩톱 (절전 또는 깨우기 만하면 됨)을 불러올 수 있으며 ProxMox 서버는 기본적으로 매번 재부팅됩니다. 또한 스위치에 연결하지 않으면 산발적으로 재부팅되는 것을 보았습니다. 스위치에 처음 연결하면 재부팅됩니다. 현재 드라이버는 3.3.5.3이며 3.3.5.10, 3.3.6 및 3.4.0.2가 있으므로 빌드 및 사용을 시도 할 것입니다. 내 .02c.
JGlass
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.