Cisco UCS M5 서버를 비롯한 최신 서버는 보다 향상된 메모리 용량을 제공하고 더 높은 대역폭과 더 낮은 전압에서 운영됩니다.
이러한 추세는 응용 프로그램 메모리 수요 증가 및 고급 멀티코어 프로세서와 함께 더 높은 메모리 오류가 발생할 확률을 초래합니다.
이 문서에서는 1세대 및 2세대 Intel Xeon Scalable 프로세서가 장착된 Cisco UCS M5 서버의 메모리 오류 분류 및 처리에 대해 설명합니다.
Cisco에서는 ADDDC(Adaptive Double Device Data Correction) Sparing 및 PPR(Post Package Repair)을 활성화하는 것을 권장합니다.
메모리 오류를 허용할 수 없는 미션 크리티컬 애플리케이션의 경우 메모리 미러링을 고려해야 합니다.
메모리 오류는 최신 서버에서 가장 일반적인 오류 중 하나입니다. 메모리 위치를 읽으려고 시도하고 읽은 값이 마지막으로 쓴 값과 일치하지 않으면 오류가 발생합니다.
메모리 오류에는 soft error 와 hard error가 있습니다. 일부 오류는 수정할 수 있지만, 단일 메모리 액세스에서 동시에 발생하는 여러 soft error 또는 hard error는 수정할 수 없습니다.
전체 오류율은 개별 메모리 용량과 총 메모리 수에 따라 확장됩니다. Soft 및 hard 오류의 impact은 이 문서에 설명된 대로 하드웨어 및 펌웨어 기능을 통해 완화 가능합니다.
Soft errors
DRAM 내부 또는 외부 인터페이스에서 일시적인 전류 장애로 인해 발생하는 오류를 "soft" 오류라고 합니다.
Soft 오류는 종종 일시적이며 항상 반복되지는 않습니다. 오류가 읽기 작업 중 어긋난 결과인 경우 읽기를 다시 시도하면 올바른 데이터가 생성될 수 있습니다. 오류가 메모리 내용을 뒤엎는 교란으로 인해 발생한 경우 메모리 위치를 다시 쓰면 오류가 수정됩니다.
Soft 오류율은 온도, 고도 및 메모리 액세스 패턴 등의 워크로드에 영향을 받을 수 있습니다. 워크로드는 애플리케이션과 직접적인 관련이 없습니다.
한 서버의 DIMM(Dual In-Line Memory Module)에서 오류를 유발할 수 있는 응용 프로그램이 다른 data set으로 오류를 유발하지 않을 수도 있습니다.
메모리 테스트 알고리즘은 최대의 워크로드 동작을 나타내도록 조정되어 이전에는 감지되지 않은 오류가 런타임 중에 발생할 수 있습니다. Cisco는 테스트 알고리즘을 검토하고 수정하여 결함 감지를 개선하고 있습니다.
Hard Errors
물리적 결함으로 인해 지속적으로 발생하는 오류는 일반적으로 "hard" 오류라고 합니다.
Hard 오류는 solder bridge 또는 cracked solder join와 같은 assembly결함으로 인해 발생하거나 메모리 칩의 결함으로 인해 발생할 수 있습니다. 영향을 받는 메모리 내용을 다시 쓰고 읽기 액세스를 다시 시도해도 하드 오류가 제거되지 않고 지속됩니다.
Correctable errors
오류가 감지되고 수정되면 수정 가능한 것으로 간주됩니다. 이는 읽기를 재시도하거나 ECC 데이터를 사용하여 올바른 메모리 내용을 계산하고 올바른 데이터를 다시 메모리에 기록하여 수행할 수 있습니다.
오류가 감지되어 수정된 후 Cisco IMC(Integrated Management Controller)는 시스템 이벤트 로그에 이벤트를 기록합니다.
다수의 수정 가능한 오류는 soft 오류의 결과입니다. 오랜 기간 동안 동일한 메모리 위치 내에서 수정 가능한 오류가 지속되면 잠재적인 hard 오류를 나타낼 수 있습니다.
Uncorrectable errors
오류가 프로세서의 ECC 엔진의 수정 기능을 초과하면 오류를 수정할 수 없는 것으로 간주합니다.
런타임 중에 수정 불가능한 오류가 발생하면 치명적인 프로세서 충돌 또는 중단이 발생하여 서버 중단이 발생합니다.
이를 위해서는 영향을 받는 서버를 재부팅하고 오류의 원인이 되는 구성 요소를 교체해야 합니다. 일반적으로 이는 메모리 모듈이지만 근본 원인은 프로세서, 프로세서 소켓 또는 DIMM 소켓에 연결될 수도 있습니다.
수정할 수 없는 오류가 발생하고 서버를 재부팅하면 Cisco UCS가 영향을 받는 DIMM을 자동으로 비활성화 합니다. 이를 통해 동일한 모듈에서 두 번째 오류가 발생하는 것을 방지하면서 서버가 서비스 상태로 돌아갈 수 있습니다.
시스템 전원 켜기 테스트 중에 메모리 오류가 감지되면 수정할 수 없는 것으로 간주되어 모듈이 비활성화 됩니다. 이것은 종종 심각한 오류를 나타내며 모듈을 교체해야 합니다.
Handling memory errors
- Scrub protocol -
Cisco UCS M5 서버는 demand및 patrol scrubbing을 활용하여 수정 가능한 오류를 해결하고 멀티비트 오류 가능성을 줄입니다. 이러한 기능은 모든 UCS M5 서버에서 기본적으로 활성화됩니다.
읽기 transaction중에 수정 가능한 오류가 감지되면 demand scrub이 수정된 데이터를 다시 메모리에 씁니다.
Patrol scrub은 24시간마다 모든 메모리를 능동적으로 스캔합니다. Demand scrub을 사용하여 메모리 위치를 읽고 감지된 오류를 수정합니다. 이를 통해 오류를 사전 예방적으로 수정할 수 있으므로 향후 읽기 이벤트 중에 영향을 받을 가능성이 줄어듭니다.
- Advanced RAS policies -
기본적인 ECC 기능과 scrub 프로토콜은 역사적으로 메모리 오류를 처리하고 완화하는 데 성공했습니다. 메모리 및 프로세서 기술이 발전함에 따라 RAS 기능은 새로운 문제를 해결하기 위해 진화해야 합니다.
결과적으로 Cisco UCS M5 서버는 서버 복원력을 개선하고 추가 메모리 redundancy 옵션을 제공하며 유지 관리를 간소화하는 몇 가지 고급 메모리 RAS 정책을 제공합니다.
- Adaptive Double Device Data Correction (ADDDC Sparing) -
ADDDC Sparing은 동일한 지역에 상주하는 두 개의 연속적인 DRAM 오류를 수정할 수 있습니다.
이 기능은 수정 가능한 오류를 추적하고 콘텐츠를 "buddy" 캐시 라인에 여분으로 복사하여 실패한 비트를 동적으로 매핑합니다. 이 메커니즘은 수정할 수 없게 될 수 있는 수정 가능한 오류를 완화할 수 있습니다.
이 기능은 virtual lockstep (VLS)을 사용하여 bank VLS를 사용하는 DRAM bank level 또는 rank VLS를 사용하는 DRAM device level에서 동일한 메모리 채널 내에 캐시 라인 buddy 쌍을 할당합니다. Platinum및 Gold CPU는 bank 및 rank VLS를 모두 지원합니다. Silver및 Bronze CPU는 bank VLS만 지원합니다.
Sparing 이벤트 후에도 오류가 지속되면 모든 spare bit가 소모될 때까지 프로세스가 필요에 따라 반복됩니다.
Lockstep 프로세스에서 생성된 중복 ECC bit를 재사용하여 buddy 캐시 라인 쌍에서 예비 bit를 얻습니다.
ADDDC Sparing은 예비 주 메모리 영역을 할당하거나 사용할 필요가 없으며 운영 체제에서 사용할 수 있는 전체 메모리를 줄이지 않습니다.
ADDDC Sparing 이벤트가 발생하면 UCSM(Cisco UCS Manager)은 F1706 Fault를 생성하여 관리자에게 서버 상태 이벤트를 안내하고 서버 펌웨어는 SEL 이벤트를 생성합니다. 펌웨어 버전별 이벤트 세부 정보는 아래의 "RAS 이벤트 처리"를 참조하십시오.
이 기능을 활성화하면 조금의 메모리 대기 시간과 대역폭 패널티가 발생합니다.
다음 표는 ADDDC 스페어링이 활성화된 경우 메모리 집약적 벤치마크 도구 및 다양한 워크로드에 대한 측정된 영향을 보여줍니다.
여분의 뱅크 또는 순위 영역이 활용됨에 따라 잠재적인 성능 영향이 증가합니다. 결과는 실제 워크로드에 따라 다릅니다.
ADDDC Sparing은 Table 1에 나열된 모든 필수 및 권장 펌웨어 릴리즈에서 default로 지원되고 활성화됩니다.
RAS 구성에 대한 BIOS 정책이 "Platform Default"로 설정된 UCSM 관리 서버의 경우 ADDDC Sparing을 적용하기 위해 변경할 필요가 없습니다.
RAS 구성에 대한 BIOS 정책이 "Platform Default"로 설정되지 않은 UCSM 관리 서버의 경우 ADDDC를 활용하려면 정책을 ADDDC Sparing(또는 Plartform Default)으로 변경해야 합니다.
설치된 UCSM 버전의 Cisco UCS Manager 서버 관리 가이드에서 "Server-related policies, RAS memory BIOS settings" 장을 참조하십시오.
E.g:
https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ucs-manager/GUI-User-Guides/Server-Mgmt/4-1/b_Cisco_UCS_Manager_Server_Mgmt_Guide_4_1/4-1-trial_chapter_01100.html#reference_08F63A1A00F1470387C604B11CA9A5BF
- Post Package Repair (PPR)
PPR(Post Package Repair)은 중복 DRAM 행을 활용하여 DIMM 내에서 불량이 발생한 메모리 영역을 영구적으로 복구할 수 있습니다.
이 영구적인 복구를 통해 DIMM을 교체할 필요 없이 심각한 오류로부터 신속하게 복구할 수 있습니다. 복구를 수행하려면 시스템에 ADDDC 이벤트가 발생하고 최소 한 번의 재부팅 주기를 거쳐야 합니다. 이 복구 작업은 성능이나 OS에서 사용할 수 있는 총 메모리에 영향을 주지 않습니다.
Cisco는 DIMM에 대한 정기적인 오류 분석을 수행하여 특정한 근본 원인을 이해하고 지속적인 품질 개선을 추진합니다.
273개의 현장 반환 DDR4 DIMM에 대한 분석을 기반으로 PPR은 ADDDC에서 감지한 DIMM 오류의 70%를 복구합니다. 수정할 수 없는 ECC 오류가 발생한 DIMM에서는 PPR이 동작되지 않습니다.
Software configuration
PPR을 지원하는 필수 및 권장 펌웨어 릴리즈는 Table1을 참조하십시오. PPR을 적용하려면 ADDDC Sparing이 활성화되어 있는지 확인이 필요합니다. PPR 유형의 플랫폼 기본값은 Hard PPR입니다. PPR 비활성화는 권장되지 않습니다. PPR이 활성화되어도 성능이나 기타 영향은 없습니다.
참고 문서 - https://www.cisco.com/c/en/us/products/collateral/servers-unified-computing/technical-overview-c17-743902.html#HandlingRAS
관련 문서 - Cisco UCS C220/C240/
B200 M5 Memory Guide