직접 답하면, 1노드 장애 복구까지 고려한 용량 계획 상한은 40.8 TB(약 37.1 TiB)입니다. 계산은 ‘장애 후 원시 용량 96 TB ÷ 2벌 복제 × nearfull 경계 85%’입니다. 다만 40.8 TB를 모두 업무 데이터로 채우면 장애 복구 후 nearfull 경계에 도달하므로, 안정적인 실제 할당량은 반드시 40.8 TB보다 낮아야 합니다. 추가 여유율에는 공통 고정값이 없으므로, 장애 후 목표 사용률을 r(<85%)로 정해 ‘48 TB × r’로 산정하십시오. 예를 들어 40.8 TB는 안전 권장값이 아니라 상한선입니다. 관련 기능은 Glue 저장소 용량 및 장애 복구 계획입니다. 제공된 근거에는 전용 용량 계획 API나 UI 계산 컴포넌트가 없으며, 상태 수집 컴포넌트 scc_status_detail.py detail이 실제 avail, used, usage_percentage, bytes_avail, bytes_total을 반환합니다.
먼저 다음 해결 방법을 적용해 보세요.
- 구매 및 할당 계획에서는 56 TB가 아니라 40.8 TB 미만을 기준으로 잡으십시오. 내부 정책으로 장애 후 목표 사용률을 85%보다 낮게 정하고, 실제 할당 상한은
48 TB × 목표 사용률로 계산하십시오.
- 구성 후 Glue 관리 콘솔(SCVM)에 SSH로 접속하십시오. Glue 상태 조회 권한이 있는 관리자 계정을 사용합니다.
ssh <관리자계정>@<SCVM>
- SCVM에서 상태 수집 컴포넌트로 실제 용량을 확인하십시오. 정상 기준은
code가 200, cluster_status가 HEALTH_OK, osd, osd_up, num_in_osds가 모두 14이며 avail과 bytes_avail이 정상 반환되는 것입니다.
python3 /제품 내부 경로 detail
- SCVM에서 풀별 가용량, OSD별 사용량 편차 및 용량 경고를 확인하십시오. 정상 기준은 nearfull·backfillfull·full 경고가 없고 모든 OSD가 up/in 상태인 것입니다.
ceph df
ceph osd df
ceph health detail
- 실측 결과가 계획보다 작으면 업무 데이터 할당량을 실측값 기준으로 다시 낮추십시오. OSD 추가나 풀 설정 변경 전에는 복제본이 서로 다른 호스트에 배치되는지 확인하십시오.
이 방법을 먼저 권장하는 이유는 다음과 같습니다.
- 1노드 장애 시 원시 용량이 112 TB에서 96 TB로 줄어듭니다. 2벌 복제 후 논리 용량은 48 TB이며, 기본 nearfull 경계 85%를 적용한 계획 상한은 40.8 TB입니다.
- 복제본의 장애 도메인(failure domain)이 호스트로 설정되지 않으면 두 복제본이 같은 호스트에 놓일 수 있어 1노드 장애 보호를 보장할 수 없습니다.
- SSD의 실제 OSD 용량, 다른 풀과 시스템 사용량, DB/WAL 공간 및 OSD별 사용량 불균형 때문에 최종 표시 용량은 40.8 TB보다 작아질 수 있습니다.
위 조치로 해결되지 않으면 아래 결과를 알려주세요. 이미 제공한 내용은 다시 보내지 않으셔도 됩니다.
- 현재 복제 풀의 failure domain이
host인지 확인되지 않았습니다.
- SSD 14개의 실제 OSD 가용 크기와 기존 풀·시스템 사용량이 없어 최종 할당 가능 용량을 아직 단일 값으로 확정할 수 없습니다.
- 구성 후 값이 필요하면
scc_status_detail.py detail, ceph df, ceph osd df, ceph health detail의 정확한 결과가 필요합니다. 공개 게시 시 BMC 암호, API 키, 토큰, 쿠키, IP, 호스트명, FSID 및 기타 인프라 식별자는 마스킹해야 합니다.
