시나리오는 다음과 같습니다. @Chopper3이 이에 동참할 수 있기를 바랍니다. SAN 패브릭에는 3개의 EMC 프레임과 4개의 Cisco UCS 도메인이 직접 연결된 한 쌍의 Cisco MDS 9513 FC 스위치가 있습니다.
우리가 보고 있는 동작은 FCoE 일시 중지 프레임을 전송하는 패브릭 인터커넥트의 결과로 블레이드의 CNA가 FC 중단을 보내는 것입니다. Cisco TAC에서는 이러한 동작이 업스트림 정체 또는 지연으로 인해 발생한다고 설명합니다. 대기 시간이 100ms에서 2000ms로 급증하는 환경을 보고하는 환경에서 200개 정도의 ESXi 서버의 데이터에서 이에 상응하는 급증이 확인되었습니다. 일부 프레임과 경로는 다른 프레임과 경로보다 약간 더 세게 히트하는 것처럼 보이므로 하나 이상의 링크를 핫스팟으로 인식하고 있다고 믿게 됩니다.
블레이드는 B200M2, B200M3 및 B420M3 서버를 사용합니다. M2 시리즈는 "Palo" 어댑터인 M81KR을 사용하고, M3 시리즈는 VIC1240 어댑터를 사용합니다.
저는 FC에 대한 지식이 별로 없기 때문에 이를 찾아내는 방법에 대한 몇 가지 제안을 주시면 감사하겠습니다.
답변1
이에 대한 이야기는 다음과 같습니다.
나는 그것을 잘못된 관점에서 보고 있었습니다. 어댑터는 일부 구성 요소가 작동하지 않음을 나타내는 정상적인 증상을 중단합니다. 이 경우 어댑터 중단은 SAN 프런트엔드 포트의 사용량이 너무 많아 요청을 처리할 수 없다는 증상이었습니다. 이는 몇 가지 다른 조건으로 인해 더욱 복잡해졌습니다.
1) 잘못된 드라이버 - UCS 펌웨어 수준은 중단에서 복구하는 데 알려진 문제가 있는 ESXi의 일치하는 드라이버를 지정하여 재부팅을 통해서만 지울 수 있는 루프로 보냅니다.
2) 변수가 너무 많음 - 세 가지 뚜렷한 문제가 있는 세 개의 SAN은 모두 어댑터 중단으로 나타납니다.
3) SAN 버그 - 문제를 일으키는 EMC VNX 코드의 버그로 인해 VAAI를 비활성화해야 했습니다.
2015년 편집:
저는 이 스레드를 업데이트하고 싶었습니다. 왜냐하면 많은 새로운 정보도 밝혀졌고 탐지가 어렵기 때문입니다. 이 게시물이 일부 사람들을 올바른 방향으로 이끌기를 바랍니다.
1) 위의 모든 내용은 실제로 여전히 관련성이 있으므로 가능한 한 빨리 모든 내용을 지원 매트릭스에 포함시켜서 확인하세요.
2) 일부 UCS 2.1 버전은 실수로 (NXOS가 여전히 그렇게 하도록 구성되어 있음에도 불구하고) 우선 순위 흐름 제어를 꺼서 일부 FCoE 트래픽이 나머지 트래픽처럼 처리되어 FC 프레임의 순서가 어긋나는 경우가 있습니다.
3) UCS 2.1 코드 중간쯤에서 IO 조절 설정이 외관 필드에서 활성 필드로 변경되었습니다. 기존의 "번인" 펌웨어 설정은 IO 스로틀 수 256으로 모든 호스트에서 거의 사용되었지만 Windows 드라이버에서는 이를 조정할 수 있었습니다. 이 코드 중간쯤에 "256"을 하드웨어에 설치할 때 사용했던 원래 기본값 "16"이 잘못된 설정이 되었고, UCSM 코드는 이를 최대값인 "2048"로 해석하기 시작했습니다. 결과적으로 단일 UCS VIC 어댑터가 스토리지 어레이를 완전히 파괴하도록 구성되었습니다.
따라서 릴리스 노트를 읽어보세요. 교훈을 얻어 마침내 이 문제를 해결했습니다.