ECC 대 비ECC 서버 메모리

01

메모리 선택 전에 결과 분류

프로세서 제품군보다 데이터 경로부터 시작하세요. 잘못된 메모리 내 값이 데이터베이스에 커밋되거나, 스토리지 메타데이터에 기록되거나, 서명되거나, 다른 노드에 복제되거나, 되돌릴 수 없는 결정을 내리는 데 사용될 수 있는지 질문하세요. 출력이 내구성이 있고 검증하기 어려울수록 ECC의 필요성이 커집니다. 아티팩트가 독립적으로 검증되는 일회용 빌드 러너는 데이터베이스 프라이머리 또는 스토리지 호스트와 다른 결과를 나타냅니다.

가용성과 무결성은 별개입니다. 상태 비저장 서비스를 다시 시작하는 것은 저렴할 수 있지만 잘못된 아티팩트를 조용히 내보내는 것은 그렇지 않을 수 있습니다. 반대로 ECC은(는) 한 호스트를 고가용성으로 만들지 않습니다. 최대 허용 데이터 손실, 중단 및 감지되지 않은 오류 결과를 세 가지 별개의 요구 사항으로 기록하십시오.

02

전체 메모리 경로 확인

ECC는 단독 DIMM 스티커의 속성이 아니라 구현된 경로의 속성입니다. 프로세서 메모리 컨트롤러, 마더보드, 펌웨어 설정 및 설치된 모듈이 의도한 모드를 지원해야 합니다. 운영 체제도 수정 및 수정되지 않은 이벤트가 모니터링에 도달하려면 적절한 보고 경로가 필요합니다. 서버급 프로세서 이름에서 ECC를 추론하지 말고 일반 인벤토리 필드를 수정이 활성화되었다는 증거로 취급하지 마세요.

명시적으로 ECC 라벨이 지정된 카탈로그 항목의 경우 해당 사양을 주문 기록과 함께 보관하세요. 목록에 DDR4 또는 DDR5만 표시된 경우 ECC이(가) 필수인 경우 확인을 요청하세요. 프로비저닝 후 플랫폼에 적합한 펌웨어 및 운영 체제 증거를 검사하세요. 하드웨어와 드라이버가 지원하는 경우 Linux EDAC는 수정된 메모리 컨트롤러 이벤트와 수정되지 않은 이벤트를 구분합니다. 카운터가 없다는 것만으로는 이벤트가 발생하지 않았거나 보고가 가능하다는 것을 증명하지 못합니다.

• Linux 커널 EDAC 문서 ↗

03

메모리 이벤트를 운영자 조치로 전환하세요.

경고 전에 응답을 정의하십시오. 배포 후 기준선을 캡처하고 수정된 이벤트와 수정되지 않은 이벤트 수를 유지하며 플랫폼이 노출할 때 호스트, 소켓 또는 모듈 위치를 첨부하십시오. 수정된 이벤트는 메커니즘이 오류를 감지하고 수정했음을 의미합니다. 이는 유용한 운영 증거이지만 증가하거나 반복되는 패턴을 무시할 이유가 아닙니다. 수정되지 않은 이벤트는 머신이 계속 실행되더라도 즉각적인 워크로드 및 데이터 무결성 평가가 필요합니다.

보편적인 임계값을 게시하는 대신 재발, 집중도 및 워크로드 결과에 대한 에스컬레이션을 설정하세요. 하드웨어 벤더와 플랫폼이 다르므로 단일 숫자가 모두를 포괄할 수 없습니다. 런북에는 워크로드를 드레인하는 사람, 진단 수집 시기, 데이터 확인 방법, 호스트를 서비스에 복귀시키기 전에 필요한 증거가 명시되어야 합니다.

04

ECC가 다루지 않는 것 파악

ECC는 파일 시스템 체크섬, 애플리케이션 검증, 복제본 또는 버전이 지정된 백업을 대체하지 않습니다. 소프트웨어 버그, 이미 유효한 것으로 받아들여진 잘못된 쓰기, 손상된 자격 증명, 삭제, 컨트롤러 장애 또는 섀시 손실을 자체적으로 수정할 수 없습니다. 메모리 진단은 일부 현재 결함을 찾을 수 있지만 향후 결함이 절대 발생하지 않을 것임을 보증할 수는 없습니다.

이 연습의 예상 결과는 짧은 결정 기록입니다: 결과 클래스, ECC 요구 사항, 구성 증거, 모니터링 소스 및 사고 대응. 이 기록은 모든 워크로드에 ECC가 필요하거나 비ECC 메모리가 위험하지 않다는 포괄적인 주장보다 더 유용합니다.