[리눅스 기초] 논리 볼륨 관리, systemd, 로그 관리

Chapter 06. 논리 볼륨 관리

1. 전통적인 파티셔닝의 한계

전통적인 디스크 파티셔닝은 하나의 디스크를 여러 영역으로 나누어 독립적으로 사용할 수 있다는 장점이 있습니다.

하지만 이미 구성된 파티션의 크기나 레이아웃을 변경하기 어렵다는 한계가 있습니다.

파티션 크기를 변경하려면 일반적으로 데이터를 백업한 뒤 파티션을 다시 구성하고, 포맷한 후 데이터를 복원해야 합니다. 따라서 추가적인 백업 공간이 필요하고 작업 과정도 복잡합니다.

이러한 파티셔닝의 한계를 보완하기 위해 LVM(Logical Volume Manager)을 사용합니다.

 

2. LVM이란?

LVM은 물리적인 디스크 공간을 논리적으로 관리하기 위한 기술입니다.

전통적인 파티션과 달리 저장 공간을 레고 블록처럼 유연하게 조합하고 분리할 수 있으며, 필요에 따라 논리 볼륨의 크기를 조정할 수 있습니다.

 

LVM의 주요 장점

• 여러 디스크를 하나의 논리적인 저장 공간으로 묶을 수 있습니다.
• 논리 볼륨의 크기를 동적으로 변경할 수 있습니다.
• 데이터를 유지하면서 디스크를 추가하거나 제거할 수 있습니다.
• 논리 볼륨의 스냅샷을 생성할 수 있습니다.
• RAID를 적용한 논리 볼륨을 구성할 수 있습니다.

즉, LVM의 핵심은 물리적인 저장 장치와 실제 사용하는 논리적인 저장 공간을 분리하여 관리하는 것입니다.

 

3. LVM의 구조

LVM은 다음과 같은 계층으로 이해하면 쉽습니다.

디스크 장치 → 물리 볼륨(PV) → 볼륨 그룹(VG) → 논리 볼륨(LV) → 파일시스템

 

• 디스크 장치
  • /dev/sdb와 같이 리눅스가 인식하는 실제 블록 디바이스입니다.
  • 디스크 전체를 사용할 수도 있고, 디스크를 파티션으로 나누어 사용할 수도 있습니다.
• 물리 볼륨(PV, Physical Volume)
  • 디스크 또는 파티션을 LVM이 관리할 수 있는 저장 공간으로 초기화한 것입니다.
  • 즉, LVM에서 사용하기 위한 준비 단계라고 볼 수 있습니다.
• 볼륨 그룹(VG, Volume Group)
  • 여러 개의 PV를 하나로 묶어 하나의 저장 공간 풀(pool)로 만든 것입니다.
  • 여러 디스크의 공간을 하나의 큰 저장 공간처럼 관리할 수 있게 해줍니다.
• 논리 볼륨(LV, Logical Volume)
  • 볼륨 그룹의 공간 중 필요한 만큼을 논리적으로 할당한 것입니다.
  • 실제 파일시스템을 생성하고 사용하는 공간이 바로 LV입니다.
  • 하나의 LV가 하나의 PV에만 존재할 수도 있고, 크기에 따라 여러 PV에 걸쳐 구성될 수도 있습니다.
• 핵심 구조
  • PV를 여러 개 묶어 VG를 만들고, VG에서 필요한 공간을 할당하여 LV를 만든다.
  • 이 구조 덕분에 VG에 사용 가능한 공간이 남아 있다면 LV의 크기를 확장할 수 있습니다.

 

4. 논리 볼륨 확장의 핵심

LVM에서 중요한 개념은 논리 볼륨의 크기와 파일시스템의 크기는 별개라는 것입니다.

예를 들어 LV를 10GB에서 15GB로 확장하더라도 파일시스템이 자동으로 15GB가 되는 것은 아닙니다.

따라서 다음 두 단계가 필요합니다.

1. LV 자체의 크기를 확장
2. 파일시스템도 확장

즉,

LV 확장 ≠ 파일시스템 확장

LV의 공간을 늘렸지만 파일시스템이 그대로라면 실제 사용 가능한 공간에서는 기존 크기만 보일 수 있습니다.

 

5. LVM의 기본 관리 흐름

LVM의 전체적인 구성 흐름은 다음과 같습니다.

디스크/파티션 준비 → PV 생성 → VG 생성 → LV 생성 → 파일시스템 생성 → 마운트

반대로 제거할 때는 일반적으로 다음과 같은 순서로 진행합니다.

마운트 해제 → LV 제거 → VG 제거 → PV 제거

즉, LVM은 물리적인 저장 공간을 추상화한 뒤 필요한 만큼 논리적으로 할당하는 구조라고 이해하면 됩니다.

 

6. 논리 볼륨의 종류와 RAID

LVM의 논리 볼륨은 기본적으로 리니어 방식으로 구성할 수 있으며, RAID를 적용할 수도 있습니다.

• Linear
  • 기본적인 논리 볼륨 방식입니다.
  • 여러 저장 공간을 순서대로 이어 붙여 하나의 논리적인 공간으로 사용하는 방식입니다.
• RAID
  • RAID는 여러 디스크를 하나의 논리적인 저장 공간으로 구성하여 성능 향상, 데이터 보호, 용량 활용 등을 목적으로 합니다.
  • RAID에서 중요한 개념은 다음 세 가지입니다.
    • 미러링(Mirroring): 동일한 데이터를 여러 디스크에 복제
    • 스트라이핑(Striping): 데이터를 여러 디스크에 분산하여 저장
    • 패리티(Parity): 장애 발생 시 데이터를 복구할 수 있도록 필요한 정보를 저장
• RAID와 클러스터의 차이
  • RAID는 기본적으로 여러 디스크를 묶어 하나의 논리적 디스크처럼 사용하는 기술입니다.
  • 반면 클러스터는 여러 서버나 노드를 하나의 시스템처럼 묶어 가용성, 성능 확장, 부하 분산 등을 구현하는 개념입니다.

즉,

RAID → 여러 디스크를 묶는 것
클러스터 → 여러 서버/노드를 묶는 것

 

• RAID 0
  • 스트라이핑 방식입니다.
  • 데이터를 여러 디스크에 분산하여 저장하기 때문에 입출력 성능을 향상시킬 수 있습니다.
  • 하지만 데이터 중복이나 패리티가 없기 때문에 디스크 하나가 손상되면 데이터 안정성이 크게 떨어집니다.
• RAID 1
  • 미러링 방식입니다.
  • 동일한 데이터를 여러 디스크에 복제하여 저장하기 때문에 내결함성과 안정성이 높습니다.
  • 한 디스크가 손상되어도 다른 디스크에 동일한 데이터가 존재합니다.
  • 대신 데이터를 복제하기 때문에 저장 공간의 효율이 낮습니다.
• RAID 5/6
  • 패리티를 사용하는 방식입니다.
  • 패리티 정보를 여러 디스크에 분산하여 저장하며, RAID 5는 하나의 디스크 장애를 복구할 수 있습니다.
  • RAID 5/6의 핵심은 데이터와 패리티를 이용하여 장애가 발생한 데이터를 복구하는 것입니다.

 

Chapter 07. systemd

1. systemd란?

리눅스가 부팅될 때는 단순히 커널만 실행되는 것이 아니라 다양한 서비스와 프로그램이 순서에 따라 시작됩니다.

이 과정에서 중요한 것은 어떤 서비스를 언제, 어떤 순서로 실행할 것인지 관리하는 것입니다.

systemd는 이러한 시스템 초기화와 서비스 관리를 담당하는 시스템입니다.

쉽게 표현하면 리눅스 시스템의 전체적인 실행을 관리하는 지휘자라고 볼 수 있습니다.

 

2. 서비스(Service)와 데몬(Daemon)

서비스는 리눅스가 동작하는 동안 백그라운드에서 특정 작업을 수행하는 프로그램입니다.

일반적으로 사용자가 직접 화면에서 실행하는 프로그램이 아니라 시스템에서 자동으로 동작합니다.

대표적인 예로 다음과 같은 것들이 있습니다.

• SSH 서버
• 웹 서버
• 데이터베이스 서버
• 네트워크 관련 서비스

서비스는 부팅 시 자동으로 실행되도록 설정할 수도 있습니다.

 

3. init에서 systemd로

과거 리눅스에서는 init이 시스템 초기화와 서비스 관리를 담당했습니다.

init은 주로 작업을 순차적으로 실행하는 방식이었기 때문에 시스템이 복잡해질수록 부팅 시간이 증가하는 문제가 있었습니다.

이를 개선하기 위해 Upstart가 등장했고, 서비스 병렬 실행을 통해 부팅 속도를 개선하려 했습니다.

이후 systemd가 등장하여 다음과 같은 부분을 개선했습니다.

• 서비스 병렬 실행
• 서비스 간 의존성 관리
• 시스템 리소스 통합 관리
• 로그 관리
• 장치 관리
• 타겟을 통한 시스템 상태 관리

따라서 systemd의 핵심은 단순히 서비스를 실행하는 것을 넘어 시스템 전체의 리소스와 의존 관계를 관리하는 것입니다.

 

4. systemd의 핵심 개념

systemd를 이해할 때 가장 중요한 개념은 Unit, Target, systemctl입니다.

 

• Unit
  • Unit은 systemd가 관리하는 하나의 대상입니다.
  • 서비스뿐만 아니라 마운트, 소켓, 타이머, 장치, 스왑, 타겟 등 다양한 시스템 자원을 Unit이라는 공통된 개념으로 관리합니다.
  • 예를 들어:
    • service → 서비스
    • mount → 마운트
    • timer → 특정 작업 예약
    • target → 시스템 상태 또는 여러 Unit의 그룹

즉,

systemd는 시스템에서 관리해야 하는 다양한 대상을 Unit으로 추상화하여 관리한다.

특히 중요한 것은 Unit 사이의 의존성(dependency)입니다.

예를 들어 SSH 서비스가 실행되기 전에 네트워크가 준비되어야 한다면 systemd가 이러한 관계를 관리하여 올바른 순서로 서비스를 실행합니다.

 

5. Target

Target은 시스템의 특정 상태나 모드를 나타내는 Unit입니다.

과거의 런레벨 개념을 systemd에서는 Target으로 대체합니다.

대표적인 Target은 다음과 같습니다.

• default.target → 기본 Target
• multi-user.target → 다중 사용자 모드
• graphical.target → 그래픽 환경
• reboot.target → 재부팅
• poweroff.target → 시스템 종료
• rescue.target → 복구 모드
• emergency.target → 긴급 모드

특히 multi-user.target과 graphical.target은 자주 사용되는 Target입니다.

 

6. systemd의 주요 구성 요소

systemd는 하나의 단일 프로그램이라기보다 여러 기능을 수행하는 구성 요소들의 집합으로 볼 수 있습니다.

대표적으로 다음과 같은 데몬이 있습니다.

• journald → 이벤트 로그 관리
• hostnamed → 시스템 호스트명 관리
• homed → 홈 디렉터리 관리
• networkd → 네트워크 인터페이스 관리
• nspawn → 네임스페이스 및 컨테이너 관리

이처럼 systemd는 서비스 관리뿐 아니라 로그, 네트워크, 장치, 리소스 관리 등 시스템 전반의 기능을 담당합니다.

 

7. Unit 파일

Unit 파일은 systemd가 특정 Unit을 어떻게 관리할지 정의한 설정 파일입니다.

주요 섹션은 다음과 같습니다.

• [Unit] → Unit에 대한 기본 정보와 의존 관계
• [Service] → 서비스 실행 방법
• [Install] → 부팅 시 어떤 Target에 연결할지 정의

 

주요 설정 개념

• Description - Unit에 대한 설명입니다.
• ExecStart - 서비스가 시작될 때 실제로 실행할 명령을 지정합니다.
• ExecReload - 서비스를 종료하지 않고 설정을 다시 읽도록 합니다.
• Restart - 서비스가 비정상적으로 종료되었을 때 다시 시작하도록 설정할 수 있습니다.
• After / Before - Unit 사이의 실행 순서를 정의합니다.
• Requires - 강한 의존성을 설정합니다.
• Wants - Requires보다 약한 의존성을 설정합니다. 함께 실행되도록 요청하지만 해당 Unit이 실패하더라도 반드시 현재 Unit까지 영향을 받는 것은 아닙니다.
• Conflicts - 특정 Unit과 동시에 실행되지 않도록 관계를 정의합니다.

 

8. Unit 파일의 위치

Unit 파일은 크게 다음 위치에서 관리됩니다.

 

• /etc/systemd/system/
  • 관리자가 직접 생성하거나 수정하는 영역입니다.
  • 가장 높은 우선순위를 가집니다.

• /run/systemd/system/
  • 런타임에 생성되는 설정입니다.
  • 재부팅하면 사라질 수 있습니다.
• /usr/lib/systemd/system/
  • 패키지가 제공하는 기본 Unit 파일이 위치합니다.
  • 세 위치 중 상대적으로 낮은 우선순위를 가집니다.
  • 따라서 관리자가 직접 설정을 변경해야 할 경우 /etc/systemd/system/이 중요한 위치가 됩니다.

 

9. systemctl

systemctl은 systemd와 Unit을 관리하기 위한 대표적인 명령어입니다.

실무에서 특히 기억해야 할 것은 다음 7가지입니다.

status	Unit의 현재 상태 확인
start	서비스 시작
stop	서비스 중지
restart	서비스를 완전히 재시작
reload	서비스를 유지하면서 설정 다시 적용
enable	부팅 시 자동 시작 설정
disable	부팅 시 자동 시작 해제

 

restart와 reload의 차이는 매우 중요합니다.

• restart
  • 서비스를 완전히 종료한 뒤 다시 시작합니다.
  • 따라서 순간적으로 서비스가 중단될 수 있습니다.
• reload
  • 서비스 자체는 계속 실행하면서 설정 파일을 다시 읽어 적용합니다.
  • 따라서 일반적으로 서비스를 중단하지 않고 설정만 변경해야 할 때 reload를 사용합니다.

 

10. active와 enabled

systemd에서 자주 혼동하는 개념입니다.

• active - 현재 서비스가 실행 중인지 나타냅니다.
• enabled - 시스템이 부팅될 때 해당 서비스가 자동으로 시작되도록 설정되어 있는지를 나타냅니다.

따라서 두 상태는 서로 다른 개념입니다.

active = 지금 실행 중인가?
enabled = 부팅할 때 자동으로 실행되는가?

예를 들어 서비스가 active이면서 disabled일 수도 있습니다.

즉, 현재는 실행 중이지만 재부팅하면 자동으로 실행되지 않을 수 있습니다.

 

Chapter 08. 로그 관리

1. 로그란?

로그는 시스템에서 발생하는 이벤트를 기록한 정보입니다.

쉽게 말하면 시스템의 일기장입니다.

로그는 단순한 기록이 아니라 시스템 운영과 보안에서 중요한 역할을 합니다.

 

운영 측면 - 장애가 발생했을 때 다음과 같은 정보를 확인할 수 있습니다.

• 문제가 언제 발생했는가?
• 어떤 서비스에서 문제가 발생했는가?
• 어떤 작업 이후 문제가 발생했는가?
• 장애의 원인이 무엇인가?

보안 측면 - 로그를 통해 다음과 같은 정보를 추적할 수 있습니다.

• 비인가 접근 시도
• 침입 경로
• 공격 방법
• 피해 범위

따라서 로그는 장애 분석과 보안 감사의 중요한 자료입니다.

 

2. 리눅스 로그 구조

systemd 환경에서는 로그 관리와 관련하여 크게 systemd-journald와 rsyslogd를 이해해야 합니다.

전체적인 흐름은 다음과 같습니다.

시스템 이벤트 발생 → systemd-journald가 수집 → 필요한 로그를 rsyslogd로 전달 → /var/log에 파일 형태로 저장

 

• systemd-journald
  • 시스템이 시작되는 순간부터 다양한 이벤트를 수집합니다.
  • 저널은 바이너리 형태로 저장되기 때문에 일반적인 텍스트 파일처럼 직접 읽는 방식이 아니라 journalctl 등을 통해 확인합니다.
  • /run/log/journal을 사용하며, /run은 메모리 기반 파일시스템이므로 재부팅하면 저장된 저널이 사라질 수 있습니다.
• rsyslogd
  • rsyslogd는 syslog 형식의 로그를 관리하며, 설정에 따라 /var/log 아래에 로그를 종류별 파일로 저장합니다.
  • 대표적인 로그 파일로 다음과 같은 것들이 있습니다.
    • messages
    • secure
    • maillog
    • cron

즉,

journald → 이벤트를 수집하고 관리
rsyslogd → 로그를 파일 형태로 저장

이라는 흐름으로 이해할 수 있습니다.

 

3. 로그 파일 순환(Log Rotation)

로그는 시스템이 동작하는 동안 계속 쌓이기 때문에 하나의 파일에 계속 저장하면 파일 크기가 지나치게 커질 수 있습니다.

로그 파일이 너무 커지면 관리와 분석이 어려워지고 시스템 자원에도 부담이 될 수 있습니다.

따라서 일정한 기준에 도달하면 기존 로그를 보관하고 새로운 로그 파일을 생성하는 로그 순환(Log Rotation)을 수행합니다.

 

4. logrotate

로그 순환을 담당하는 대표적인 유틸리티가 logrotate입니다.

로그 파일이 일정 기간이 지났거나 특정 크기를 초과하면 기존 파일을 백업하고 새로운 로그 파일을 생성합니다.

또한 오래된 로그 파일은 일정 개수나 기간을 기준으로 삭제할 수 있습니다.

예를 들어 로그 파일이 다음과 같이 관리될 수 있습니다.

• testlog.log
• testlog.log.1
• testlog.log.2
• testlog.log.3

새로운 로그가 생성되면 기존 파일들의 번호가 밀리고, 설정된 최대 보관 개수를 초과한 오래된 로그는 삭제됩니다.

즉,

현재 로그 → 이전 로그 보관 → 오래된 로그 삭제

의 구조로 로그 파일의 크기와 개수를 관리합니다.

systemd 환경에서는 logrotate.timer를 통해 주기적으로 logrotate가 실행되도록 구성할 수 있습니다.