리눅스 미러서버 & 로그 백업 서버 구축기

이원찬·2025년 7월 13일

리눅스 미러서버란?

리눅스 미러서버는 일종의 CDN(Content Delivery Network)이라고 볼 수 있다.
원본 서버에서 제공하는 주요 파일들을 각국에 분산된 미러 서버에 복제해두고, 사용자들은 지리적으로 가까운 서버에서 해당 파일을 다운로드하게 된다.
이 방식은 다운로드 속도를 개선하고, 동시에 원본 서버의 부하를 분산시켜 안정성과 효율성을 높일 수 있다.

운영 현황

현재 대한민국에서도 카이스트, 카카오 등 여러 대학 및 기업이 미러 서버를 운영하고 있으며, 다양한 리눅스 배포판의 안정적인 다운로드를 지원하고 있다.

구축 과정

Step 1. 계획 수립

먼저 어떤 배포판들을 미러링할 것인지 결정하는 작업부터 시작했다.
현재 인기 있고 널리 사용되는 리눅스 배포판을 기준으로 총 21개 배포판을 선정하여 미러링 서비스를 제공하기로 하였다.

Ubuntu, Ubuntu-cd, Termux, Rocky-sigs, ArchLinux, Rocky, Fedora,
Fedora-Epel, Raspbian, Debian, Debian-cd, Debian-security, FreeBSD,
Kali, Kali-images, Zorin, MXLinux, MXLinux-iso, Linuxmint, Linuxmint-iso, AlmaLinux

총 21개의 리눅스 배포판 미러링 서비스 계획했다.

미러링 서비스에 필요한 용량을 계산해본 결과, 다음과 같았다.

2,900GB + 40GB + 30GB + 30GB + 500GB + 800GB + 4,000GB + 500GB + 600GB + 1,800GB + 200GB + 300GB + 900GB + 700GB + 200GB + 200GB + 300GB + 40GB + 40GB + 100GB + 500GB = 14,600GB = 14.6TB
(위 배포판 제시 순으로)

필요한 용량을 계산해보니, 데이터 저장할 수 있는 하드디스크가 필요하였다.
각 배포판별 필요한 용량을 계산한 결과, 총 14,600GB 즉. 14.6TB의 저장공간이 필요했다.

이를 위해 전남대학교 차세대통신혁신융합대학사업단의 예산 지원을 받아
• 8TB HDD 2개
• 4TB HDD 1개
• 2TB HDD 1개
를 약 90만 원에 구입할 수 있었다.

Step 2. 저장소 구성

저장소 구성은 미러서버를 운영 중인 임시우님의 자문을 받아 설계하였다.
디스크는 다음과 같이 용량과 성격에 따라 분산 저장하였다.

결론부터 말하자면, 위 사진과 같이 구성하였다.

우분투 관련 패키지는 /ubuntu 디렉토리에 약 2.9TB, 설치 ISO 이미지는 /ubuntu-cd에 40GB를 차지하도록 설정하여 총 4TB HDD의 대부분을 사용하게 하였고, 남는 공간은 /termux와 /rocky-sigs에 각각 30GB씩 할당하였다.

추가적인 배포판은 8TB HDD 두 개에 분산 저장하였다.

첫 번째 8TB 디스크는 주로 Arch 계열 및 Red Hat 계열 배포판으로 구성하였으며, 각 디렉토리와 용량은 다음과 같다:
• /archlinux (ArchLinux / 500GB)
• /rocky (Rocky / 800GB)
• /fedora (Fedora / 4TB)
• /fedora-epel (Fedora-Epel / 500GB)
• /raspbian (Raspbian / 600GB)

두 번째 8TB 디스크는 주로 Debian 계열 및 기타 배포판을 저장하는 데 사용되었다:
• /debian (Debian / 1.8TB)
• /debian-cd (Debian-cd / 200GB)
• /debian-security (Debian-security / 300GB)
• /freebsd (FreeBSD / 900GB)
• /kali (Kali / 700GB)
• /kali-images (Kali-images / 200GB)
• /zorinos (Zorin / 200GB)
• /mxlinux (MXLinux / 300GB)
• /mxlinux-iso (MXLinux-iso / 40GB)
• /linuxmint (Linuxmint / 40GB)
• /linuxmint-iso (Linuxmint-iso / 100GB)
• /almalinux (AlmaLinux / 500GB)

이러한 구성은 저장공간 효율성과 유지보수 편하게 하기위해 구성하였다. 각 디렉토리는 rsync를 이용한 주기적 동기화를 통해 최신 상태를 유지하며, 충분한 여유공간 확보를 통해 향후 확장도 고려하였다.

특히 /ubuntu는 사용량이 많고 업데이트 주기가 빠르기 때문에 가장 빠르고 접근성이 좋은 디스크에 할당하였고, /fedora, /debian, /kali처럼 데이터량이 많은 리포지터리는 8TB HDD에 집중적으로 배치해 디스크 병목 현상을 방지하였다.

Step 3. 로그 & 백업 서버 구축

전남고 LMS는 전교생의 개인정보를 저장하고 있기 때문에, 정보통신망법 제5조에 따라 접속 기록 보관 및 주기적 백업이 필수이다.
이를 위해 별도의 로그 및 백업 서버를 구축하였다.

CPU: Intel Core i3-2120 @ 3.30GHz
RAM: DDR3 4GB (2GB * 2)
스토리지: HDD 2TB + HDD 1TB
2TB 디스크: 접속 로그 1년 보관용
1TB 디스크: 정기 백업 저장용

부품 조립 후 성공적으로 서버를 구축하였다.

Step 4. 서버들 간의 통신 구축

위 완성된 서버 사진을 보면 밑에서부터 UPS, 패치 패널, L3 네트워크 스위치, 로그 & 백업서버, 미러서버, LMS 서버, 라우터이다.
LMS 서버와 미러서버에 접속을 하면 그 접속 기록을 로그 서버에 전송해야한다.

"어떻게 전송해야할까?"

각 서버는 발생한 로그를 로그서버에 저장해야 했고, 이를 위해 NFS(Network File System) 기술을 도입하였다.
NFS를 통해 네트워크상에서 디스크를 공유하여, 각 서버에서 로그를 직접 저장하지 않고 로그 서버의 디스크에 저장하도록 구성하였다.

이 방식은 일종의 스토리지 클러스터 구성으로, 관리 효율성과 안정성을 동시에 확보할 수 있었다.

NFS라는 기술을 이용하여 위 사진과 같이 서버들간의 디스크 공유를 하였다. 사진에 있는 서버들 간에 화살표로 연결된 것이 서버들 간의 네트워크로 저장공간을 공유하고 있는 것이다.
즉. 스토리지 클러스터를 구축하였다.

공식 미러 인증

이렇게 성공적으로 구축하고 Ubuntu 재단과 Linux 재단으로부터 서버 안정성을 인정을 받아서 공식 미러로 선정이 되었다.
보다 많은 사용자에게 안정적으로 미러링 서비스를 제공하게 되었다.

Cloudflare 스폰서 유치

운영 중이던 미러서버를 통해 ELIV라는 기업에서 연락이 왔다.
전남고의 다양한 IT 인프라를 보고, 무상으로 Cloudflare CDN Enterprise 요금제 (시가 약 1000만 원 이상)를 스폰서 형태로 제공해주셨다.

이로 인해 전남고 LMS 등 교내 주요 서비스는 보안성과 안정성이 크게 향상되었다.

운영 중 문제 발생

CPU 전력 관리와 리눅스 커널의 버그

로그 & 백업 서버를 구축을 한 후, 운영 중 예기치 못한 장애가 연속적으로 발생하였다.

▣ 1차 장애 발생 (11월 1주차)

첫 번째 장애는 로그 서버의 네트워크 연결이 끊기면서 시작되었다.
시스템 로그를 확인해 본 결과, SSD 드라이브에서 에러 로그가 5건 발견되었고, 이는 결국 디스크의 하드웨어 결함으로 판단되었다.
→ 조치: SSD를 즉시 교체하며 문제를 해결했다고 판단하였다.

▣ 2차 장애 발생 (11월 2주차)
하지만 며칠 안되어 장애가 발생하였다.
11월 2주차에는 짧은 시간 동안 세 번의 장애가 연속으로 발생했다. 이때는 네트워크 문제라고 확신했다. 점검 결과, enps40 랜카드가 IP 주소를 제대로 받지 못해 패킷 손실이 생기고 있었고, netplan으로 고정 IP 설정을 적용하면서 문제를 해결하였다고 판단하였다.

▣ 3차 장애 발생 (11월 2주차)
그러나, 또 장애가 발생하였다.
이번엔 원격으로도 서버 접속이 되지 않아, 서비스 다운타임이 길었다. 심지어 이때 수업시간에 선생님 말씀을 잘 들어서 쿠폰을 받아 LMS에 받은 쿠폰을 등록하여 가장 많은 반에 상금을 지급하는 이벤트가 있었다. 최대한 빠르게 복구해야했지만 서버 원격 접속도 안되어 이벤트 기간을 연장한 기억이 난다.
서버를 복구하려 학교 서버룸에 가서 직접 서버에 키보드와 모니터를 연결해 확인한 결과, 시스템이 완전히 멈춘 상태, 즉 커널 프리징(Kernel Freezing) 현상이 발생하고 있었다.

로그 분석을 시도해도, 커널 프리징으로 인해 장애가 발생한 시점의 로그는 아예 남아있지 않았고, 그제서야 지금까지 해결한 방법인 네트워크, SSD 문제가 아니라는 것을 깨달았다.

일단은 임시적으로 각 서버에 발생된 로그를 로그서버에 저장하지않고 자신의 서버에 저장하도록 수정하고 서비스를 복구하였다.
그리고 로그서버 문제점을 해결하기위해 인터넷 검색을 하였다.

인터넷 검색 결과, 어느 한 외국인 개발자가 작성한 아티클에서 원인과 해결방법이 제시되어있었다.
원인은 "리눅스 커널과 특정 CPU 모델 간의 전력관리 상태(C-State) 호환성 문제였다."

▣ C-State란?

상태	설명
C0	CPU가 완전히 활성화되어 작업 수행
C3~C6	CPU 일부 또는 전체 비활성화로 에너지 절약
C6	가장 깊은 절전 모드로 CPU가 거의 완전히 꺼짐

자세한 원인은 다음과 같았다. 로그서버에 장착된 CPU는 Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz 인데 이 CPU가 Bay Trail 계열 CPU라서 문제가 발생한 것 같았다.

• 인텔의 Bay Trail 계열 CPU는 C6 상태에서 제대로 깨어나지 못하는 하드웨어적 결함이 존재함.
• 리눅스 커널은 CPU를 더 깊은 절전 상태로 진입하도록 설계되어 있어 이 하드웨어 문제를 직접 유발함.
• 결과적으로, 시스템이 깊은 절전 모드(C6)로 진입하면 커널 프리징이 발생함.

해결방법

리눅스 시스템 부팅 옵셥을 설정 할 수 있는 Grub Boot Loader의 설정파일에 intel_idle.max_cstate=1 커널 파라미터를 추가해 최대 절전 상태를 C1로 제한함으로 CPU가 제대로 깨어날 수 있도록 하여 해결하였다.

마치며

리눅스 미러 서버를 구축하는 과정에서 가장 먼저 직면한 과제는 14.6TB에 달하는 대용량 저장소를 어떻게 효율적으로 설계할 것인가였다. 인터넷에서 얻은 지식만으로는 최적의 구성과 안정성을 확보하기 어렵다고 판단했고, 현재 미러 서버를 운영 중인 임시우 님께 자문을 구하게 되었다.

자문을 받으며 각 배포판의 업데이트 주기, 사용 빈도, 트래픽 양 등을 고려한 디스크 분산 배치 전략을 배웠고, 이 과정에서 단순한 구축을 넘어 서비스 운영 전반에 대한 새로운 지식도 얻게 되었다. 이를 통해, 혼자만의 지식으로 모든 것을 해결하려 하기보다는 경험 있는 이들의 조언을 듣고 협업하는 것이 얼마나 중요한지를 깨닫게 되었다.

전교생의 개인정보를 담고 있는 LMS 시스템 특성상 로그 보관이 필수였기에 로그 서버를 구축했지만, 안정적으로 운영되던 로그 및 백업 서버에서 반복적으로 원인 모를 장애가 발생하기 시작했다. 처음에는 단순한 SSD 결함으로 판단해 교체했고, 이후엔 네트워크 문제를 의심해 IP 설정을 수정하는 등, 겉으로 드러나는 문제에만 집중하여 임시방편식 해결을 반복했다.

그러나 장애는 계속되었고, 결국 시스템 전체가 멈추는 ‘커널 프리징(Kernel Freezing)’ 문제가 발생하였다. 가장 큰 문제는 문제 발생 당시의 로그조차 남지 않는다는 점이었다. 그럼에도 포기하지 않고 문제의 근원을 찾기 위해 국내를 넘어 해외 기술 문서와 개발자 커뮤니티까지 찾아다닌 끝에, 한 외국 개발자의 아티클을 통해 원인을 정확히 파악할 수 있었다.

문제의 핵심은 로그 서버에 사용된 Intel Bay Trail 계열 CPU와 리눅스 커널의 전력 관리 기능(C-State) 사이의 호환성 문제였다. 이는 단순한 설정이나 소프트웨어 이슈가 아닌, CPU의 하드웨어적 특성과 운영체제 커널의 구조까지 이해해야만 해결할 수 있는 복합적인 문제였다. 이 경험을 통해 지금껏 소프트웨어만 공부하면 된다고 생각했던 나의 시야가 좁았음을 깨달았다.

Grub 부트로더의 커널 파라미터에 intel_idle.max_cstate=1 옵션을 추가하여 CPU의 최대 절전 상태 진입을 차단하고 문제를 해결한 뒤, 나는 다시금 느꼈다. 시스템을 안정적으로 구축하고 운영하기 위해선 단순한 프로그래밍 지식뿐 아니라, 컴퓨터 구조와 운영체제, 네트워크 등 CS(Computer Science의 약자) 전반에 대한 깊은 이해가 필요하다는 것을 깨닫게 되었다.

결국 이번 프로젝트는 단순한 리눅스 미러 서버와 로그 & 백업서버 구축이 아니라, 문제 해결을 통해 컴퓨터의 로우레벨까지 접근하여 문제를 해결하고 배운 과정이었다.