호환성 매트릭스, 릴리스 노트, 펌웨어 변경

“지원됨”이라는 말은 세 가지 조합에 대한 진술입니다: 이 모듈이, 이 플랫폼에서, 이 소프트웨어 릴리스로 동작한다는 것입니다. 벤더는 이 조합을 호환성 매트릭스와 릴리스 노트로 공개하며, 그 내용은 계속 바뀝니다 — 새 광학 부품이 추가되고, 오래된 것은 빠지고, 검사는 더 엄격해집니다. 구매 전에 매트릭스를 읽고 업그레이드 전에 다시 읽는 것이야말로 가장 저렴한 호환성 작업입니다. 이 페이지는 이 정보가 어디에 있는지, 어떻게 읽는지, 소프트웨어 업그레이드가 광학 부품 장애로 이어지지 않도록 플릿을 운영하는 방법을 보여줍니다.

벤더가 지원 정보를 공개하는 곳

실행 중인 NOS 버전의 릴리스 노트도 함께 읽습니다: 광학 부품 관련 변경 사항은 “resolved issues”, “behaviour changes”, “new hardware support” 항목 아래 숨어 있는 경우가 많습니다.

매트릭스 항목 읽는 법

소프트웨어가 바뀌면 달라지는 것

예상치 못한 사고를 막는 플릿 운영 방식

1. 인벤토리 — 모든 모듈의 벤더, PN, 시리얼 번호, 리비전, 펌웨어를 포트별로(스위치에서든 벤치에서든) CMDB에 기록합니다.
2. 릴리스 고정 — NOS 버전을 호환성 조합의 일부로 취급합니다; 액세스와 코어를 같은 날 업그레이드하지 않습니다.
3. 릴리스 노트 확인 — 업그레이드할 때마다 광학 부품 관련 항목을 미리 읽습니다.
4. 랩 또는 카나리 스위치에서 테스트 — 운영 중인 모든 광학 부품 유형을 하나씩, 서드파티와 코딩된 모듈부터 먼저 테스트합니다.
5. 이전 이미지 보관 — 롤백 계획을 마련하고 errdisable이 잘 발생하는 포트를 파악해 둡니다.
6. DDM 기준값 확보 — 전후로 기록해 모니터링 상의 동작 변화가 드러나게 합니다(모니터링).
7. EOL 추적 — 광학 부품 PN과 후속 PN을 추적해 교체품이 매트릭스와 일치하도록 합니다.

이 그림에서 서드파티와 코딩된 광학 부품

OEM PN으로 코딩된 모듈은 원본과 동일한 매트릭스 항목으로 판정됩니다 — 코딩이 완전하다면 플랫폼은 차이를 구분하지 못합니다 — 하지만 벤더의 지원 보증은 이 모듈에는 적용되지 않으며, 새 릴리스의 더 엄격한 검사가 이를 드러낼 수 있습니다. 코딩된 모듈은 인벤토리에서 식별 가능하도록 유지하고(실제 벤더와 시리얼 번호), 업그레이드 시 가장 먼저 테스트하며, 릴리스가 문을 닫아버리는 경우에 대비합니다(서드파티 광학 부품, 벤더 락).

NIC와 서버 측

서버 어댑터에는 자체 매트릭스(어댑터 ↔ 모듈 ↔ 드라이버/펌웨어)와 자체 정책이 있습니다 — 일부 Intel 제품군은 드라이버 파라미터로 허용하지 않는 한 목록에 없는 SFP를 거부하며, Mellanox/Nvidia 어댑터는 InfiniBand용 케이블을 검증합니다. 드라이버와 펌웨어 업데이트도 NOS 업그레이드와 마찬가지로 이 규칙을 바꿉니다(포트 설정 레시피).

CodingBox에서

플릿 운영 방식의 벤치 쪽 작업입니다: 입고 검수 시 모든 모듈의 식별 정보와 펌웨어 버전을 code database에 기록하고, 의심되는 모듈의 바이트를 Check transceiver에서 매트릭스 항목과 비교하며, 코딩 여부와 원본 여부의 구분을 데이터베이스 메모에 남겨 두면 업그레이드 당일의 거부 사유를 몇 초 만에 해당 모듈까지 추적할 수 있습니다.

NIC 드라이버와 펌웨어 정책을 벤더와 운영체제별로 자세히: NIC에서의 트랜시버 호환성.

이 플릿 운영 방식을 개통 체크리스트로 정리하면 — 설정 전 업그레이드, 카나리 테스트, DDM 기준값, 인수 테스트: 스위치 선정과 개통.