배경
테스트 및 백업 용도로 사용할 물리 서버를 새로 세팅해야 하는 상황이었다. 서버의 용도는 다음과 같았다.
- SBI(스털링 서버) 테스트 서버
- 운영 환경의 백업 서버 (백업본 보관)
- HUB 로그 백업
- 향후 Dev 환경에서 자체 테스트할 서버
서버 사양
| 항목 | 값 |
|---|---|
| 메모리 | 128 GB |
| 디스크 | 600GB × 6개 (SAS) |
| RAID 컨트롤러 | Broadcom MegaRAID SAS-3 3108 (Invader) |
| OS | Rocky Linux release 8.10 (Green Obsidian) |
서버와 PC의 차이: 왜 물리 서버인가
일반 PC와 서버의 가장 큰 차이는 복구와 안정성이다.
- Hot Swap: 서버는 디스크가 고장나도 시스템을 끄지 않고 디스크를 교체할 수 있다
- RAID 지원: 하드웨어 RAID 컨트롤러를 통해 디스크 장애 시에도 데이터 손실 없이 운영 지속
- ECC 메모리: 메모리 오류를 자동으로 감지하고 수정
- 이중 전원: 전원 장치가 이중화되어 하나가 고장나도 서버가 꺼지지 않음
테스트 서버라 하더라도 백업 데이터를 보관하는 용도가 있었기 때문에, 디스크 장애 대응이 가능한 RAID 구성이 필수였다.
RAID 구성
Broadcom MegaRAID SAS-3 3108 Controller
서버에 탑재된 **Broadcom MegaRAID SAS-3 3108 (Invader)**는 하드웨어 RAID 컨트롤러다.
부팅 시 RAID 설정 유틸리티(WebBIOS 또는 UEFI HII)로 진입하여 RAID를 구성할 수 있고,
OS 상에서는 storcli CLI 도구를 통해 RAID 상태를 확인할 수 있다.
# RAID 컨트롤러 확인
lspci | grep -i raid
# 출력: Broadcom / LSI MegaRAID SAS-3 3108 [Invader] (rev 02)
# storcli로 RAID 구성 확인
sudo /opt/MegaRAID/storcli/storcli64 /c0 show
sudo /opt/MegaRAID/storcli/storcli64 /c0/vall show
sudo /opt/MegaRAID/storcli/storcli64 /c0/eall/sall showRAID 레벨 비교
| RAID 레벨 | 최소 디스크 | 용량 효율 | 장애 허용 | 특징 |
|---|---|---|---|---|
| RAID 0 | 2개 | 100% | 없음 | 스트라이핑, 장애 시 전체 손실 |
| RAID 1 | 2개 | 50% | 1개 | 미러링, 읽기 성능 향상 |
| RAID 5 | 3개 | (N-1)/N | 1개 | 패리티 분산, 용량 효율 + 안정성 |
최종 RAID 구성: RAID 1 + RAID 5 이중 구성
디스크 6개를 용도에 따라 두 개의 논리 디스크로 나누어 구성했다.
| 논리 디스크 | 물리 디스크 | RAID 레벨 | 용량 | 용도 |
|---|---|---|---|---|
| Logical Disk 1 | disk 0, disk 1 | RAID 1 | 558 GB | OS + 시스템 영역 |
| Logical Disk 2 | disk 2, disk 3, disk 4, disk 5 | RAID 5 | 1.63 TB | 데이터 영역 (mount) |
RAID 구성 설계: 고민 과정
디스크 6개를 어떻게 나눌지 고민이 많았다.
처음에는 전체 6개를 RAID 5로 묶는 것을 검토했다. 그러면 (6-1) × 600GB = 약 3TB의 단일 볼륨을 확보할 수 있어 용량 면에서 가장 효율적이다. 하지만 OS 영역과 데이터 영역이 하나의 논리 디스크에 섞이면, OS 장애 시 데이터까지 영향을 받을 수 있고, 반대로 데이터 영역의 I/O 부하가 OS 성능에 영향을 줄 수 있다.
그래서 OS 영역과 데이터 영역을 분리하기로 결정했다.
OS 영역에 RAID 1을 선택한 이유:
- OS는 안정성이 최우선, OS가 날아가면 서버 전체가 멈춘다. 미러링으로 디스크 1개가 고장나도 즉시 다른 디스크에서 부팅 가능
- 리빌드가 빠름, RAID 1은 단순 복사이므로 리빌드 시간이 짧고, 리빌드 중 추가 장애 리스크가 낮음
- OS 영역은 용량이 크게 필요하지 않음, 558GB면 OS + 기본 패키지에 충분
데이터 영역에 RAID 5를 선택한 이유:
- 용량 효율, 디스크 4개로 RAID 5를 구성하면 (4-1) × 600GB = 약 1.8TB(실제 1.63TB)를 확보. RAID 1로 했으면 2개씩 미러링해서 1.2TB밖에 안 됨
- 백업 데이터 보관이 주 용도, 쓰기보다 읽기 비중이 높은 워크로드라 RAID 5의 쓰기 성능 이슈가 크게 문제되지 않음
- 1개 디스크 장애 허용, 4개 중 1개가 고장나도 데이터 손실 없이 운영 가능
이렇게 RAID 1(OS) + RAID 5(데이터)로 이중 구성하면, OS 장애와 데이터 장애를 독립적으로 대응할 수 있는 구조가 된다.
RAID 구성 과정
- 서버 부팅 시 F8 → SSA(Smart Storage Administrator) 진입
- 물리 디스크 6개 확인
- Array 1 생성: disk 0, disk 1 → RAID 1 (Logical Disk 1, OS 영역)
- Array 2 생성: disk 2, disk 3, disk 4, disk 5 → RAID 5 (Logical Disk 2, 데이터 영역)
- 저장 후 재부팅
디스크 마운트
Logical Disk 1에는 OS 설치 시 자동으로 파티션이 잡히고, Logical Disk 2는 별도로 마운트해서 사용한다.
# 디스크 확인
lsblk
# 파티션 생성 (Logical Disk 2)
fdisk /dev/sdb
# 파일시스템 생성
mkfs.xfs /dev/sdb1
# 마운트 포인트 생성 및 마운트
mkdir -p /data
mount /dev/sdb1 /data
# 영구 마운트 (fstab 등록)
echo '/dev/sdb1 /data xfs defaults 0 0' >> /etc/fstabRocky Linux 설치 및 초기 세팅
OS 선택: 왜 Rocky Linux인가
CentOS 8이 2021년 말에 EOL되면서, RHEL 호환 대안으로 Rocky Linux를 선택했다. Rocky Linux는 CentOS 창립자가 만든 프로젝트로, RHEL과 1:1 바이너리 호환을 목표로 한다. 기존 CentOS 기반 운영 경험을 그대로 활용할 수 있었다.
초기 세팅 체크리스트
- Rocky Linux 8.10 설치
- 기본 IP 설정
- SSH 접속 설정 및 IP 제한 (
/etc/ssh/sshd_config) - 관리 계정 생성
- 방화벽 설정 (firewalld)
- 시간 동기화 (chrony)
SSH 접속 IP 제한
보안을 위해 /etc/ssh/sshd_config에서 접속 가능한 IP를 제한했다.
# /etc/ssh/sshd_config
AllowUsers [user]@[allowed-ip]
# 설정 적용
systemctl restart sshdRAID 상태 확인 명령어
블로그에 첨부할 스크린샷을 찍으려면 다음 명령어를 사용하면 된다.
# MegaRAID storcli - RAID 구성 확인
# 컨트롤러 개요
sudo /opt/MegaRAID/storcli/storcli64 /c0 show
# 논리 드라이브 (RAID 레벨, 크기, 상태)
sudo /opt/MegaRAID/storcli/storcli64 /c0/vall show
# 물리 디스크 (크기, 상태, 슬롯)
sudo /opt/MegaRAID/storcli/storcli64 /c0/eall/sall show
# 일반 Linux 명령어로 디스크 확인
lsblk
df -h
free -hstorcli64 /c0/vall show가 RAID 레벨, 논리 드라이브 크기, 상태를 한 화면에 보여주므로 블로그 첨부에 가장 적합하다.
마무리
물리 서버를 처음부터 세팅하는 경험은 클라우드 환경에서는 얻기 어려운 것들을 배울 수 있었다.
- RAID 컨트롤러를 직접 다루면서 디스크 장애 대응의 원리를 체감
- OS 영역과 데이터 영역을 분리하는 RAID 이중 구성의 설계 근거를 직접 고민
- Hot Swap과 RAID 리빌드의 차이를 실제로 이해
- SSH IP 제한 등 물리 서버 보안의 기본을 적용
클라우드에서는 EBS 볼륨 타입을 선택하고 스냅샷을 찍는 것으로 끝나지만, 물리 서버에서는 RAID 레벨 선택부터 디스크 분배, 마운트 구성까지 직접 고민해야 한다. 이런 기반 지식이 있어야 클라우드 인프라의 추상화된 개념도 더 깊이 이해할 수 있다고 생각한다.
배운 점
클라우드만 다루다 보면 추상화된 이름 뒤가 잘 안 보인다. EBS 볼륨을 고르는 일은 몇 번의 클릭이지만, 물리 서버에서는 RAID 레벨을 정하고 디스크를 나누고 마운트를 잡는 일이 전부 손으로 넘어온다. 그 과정을 한 번 겪고 나니 클라우드의 선택지들이 무엇을 대신해 주는지가 보였다.
특히 RAID 1과 5를 나눠 구성하면서, 가용성과 용량 효율이 맞바꿈 관계라는 걸 숫자로 확인했다. 클라우드에서 같은 판단을 내릴 때도 결국 같은 질문이다. 무엇을 잃어도 되는가.
여기서 만든 서버는 이후 테스트와 백업 용도로 쓰였고, 클라우드 쪽 백업 전략은 EC2 복원 가이드: AMI + EBS 스냅샷 조합 복원에 따로 정리했다.
이어 읽기
- EC2 복원 가이드: AMI + EBS 스냅샷 조합 복원: 클라우드에서의 복구 설계
- 물리 서버(113.11) 대역폭 충돌 문제 해결: 같은 물리 환경의 네트워크 구성