[리눅스 입문과 운영] 부팅 및 시스템 관리 데몬의 이해

[tonykang22]

부팅 및 시스템 관리 데몬의 이해

리눅스 시스템 부팅 순서

1. BIOS에서 하드웨어 검사 후 부팅 기기 선택 및 파티션 식별
2. 부트로더에서 커널 선택 및 커널 로드
3. 커널 자료구조 초기화 및 시작 서비스 구동

BIOS? UEFI?

BIOS

• 컴퓨터에 전원이 인가되면 실행이 시작되는 최초의 프로그램
• 바이오스는 마더보드에 연결된 디바이스를 초기화하고 검사 (POST)하는 역할을 수행
  • POST : Power On Self Test
• 부트로더 또는 운영체제를 RAM으로 읽어오는 기능을 수행
• 클라우드/가상화/컨테이너 환경에서는 시스템 관리자가 하드웨어 상태를 직접 관리할 일은 많지 않다.
• 만약, 호스트 머신 하드웨어의 문제가 발생했다면?
  • 인스턴스 stop, start로 해결 (VM이 다른 호스트에서 구동된다.)

dmidecode

• DMI 테이블 정보를 사람이 읽을 수 있는 형태로 출력해주는 도구
• DMI 테이블 : 하드웨어 구성 요소에 대한 정보를 추적하기 위한 산업 표준
  • 시스템 하드웨어 정보, 시리얼 번호, BIOS 리비전 등의 정보가 유지됨

물리 호스트

AWS EC2 : 가상화된 환경이기 때문에 대부분의 경우 Not Specified

부트모드 : BIOS? UEFI ?

BIOS(Basic Input/Output System) vs. UEFI (Unified Extensible Firmware Interface)

• BIOS : 전통적인 PC 펌웨어 (Legacy BIOS)
• UEFI : BIOS를 계승해서 좀 더 정형화하고 표준화한 PC 펌웨어
• 주요 차이점 : UEFI는 2TB 이상 Storage 지원, 더 빠른 부팅시간, UI 및 기능 개선 (주소공간 추가)
• PC 환경에서는 UEF가 표준화되어 가고 있지만, 가상화 환경에서는 BIOS가 여전히 많이 사용됨

부트로더

• 사용 가능한 커널을 확인하고 로드하는 작업을 수행
• 대부분의 부트 로더는 부팅 타임에 사용 가능한 운영체제를 선택하기 위한 UI를 제공
• 커널 부팅 방법에 대한 설정
  • 예) -s 옵션 : 런레벨1, 단일 사용자모드, 시스템 관리 목적으로 부팅 (예: 네트워크 연결 안됨)

Bootloader 종류

GRUB (Grand Unified Boot Loader)

• 대부분 (Ubuntu, RHEL 등)의 리눅스 배포판에서 기본 부트 로더로 사용
• GRUB의 두 브랜치 : GRUB Legacy, GRUB 2
• GRUB 설정
  • 커널 목록, 부팅 옵션 등
  • 부팅 옵션 : debug, init=/bin/bash, root=/dev/foo, single
  • 일반 텍스트 파일로 설정을 관리 (/boot/grub/grb.cfg, /boot/grub2/grub.cfg)
• 운영체제 구동 전인데 파일시스템을 사용 가능한가?
  • 대부분의 파일시스템을 인식(ext3, ext4, BtrFS, ZFS, FAT32, exFAT)

시작 서비스 ?

• 시스템 구동 시 최초로 실행되는 사용자 레벨 프로세스
• 시스템 구동에 필요한 각종 스크립트를 실행
  • 컴퓨터 이름 설정
  • 타임존 설정
  • fsck로 디스크 상태 확인
  • 파일시스템 마운트
  • /tmp 디렉토리의 오래된 파일 삭제
  • 네트워크 인터페이스 구성
  • 패킷 필터 설정
  • 네트워크 서비스 시작
  • 기타 데몬 시작

시작 서비스 위치 (/etc/init.d/)

실행 레벨 ?

실행 레벨 / 오퍼레이팅 모드

• 운영체제가 부팅 이후의 머신 상태를 결정
  • 어떤 프로그램을 실행할 것인지 결정
• 예) single user : 파일시스템 마운트, 네트워크 비활성화, 시스템 관리용 쉘 접근
• 예) multi-user : 일반적인 사용자 접근
• SysV에서는 run level 개념 사용, systemd에서는 오퍼레이팅 모드 개념 사용

init 프로세스 구현

• System V init, Upstart
• launchd (Mac OS)
• systemd
  • 기존 init 프로세스보다 더 넓은 범위의 기능을 제공
  • 그러나 Unix의 철학 : "단순하고 짧고 명료하고 모듈 방식의 확장"과 상충된다.
  • Red Hat, Debian, Ubuntu에서 기존 init 프로세스로 선택되면서 논란의 종지부
• 시스템 어드민 관점
  • 유지할 레거시 시스템이 없는 경우, 대부분 환경에서 systemd가 사용

About systemd

systemd 주요 역할

• 기존 init 프로세스의 기능을 지원 및 통합
• 동작 모드에 따른 시작 서비스 관리 (기존 run level)
• 병렬 실행 및 종속성 모델 관리
• 커널 로그 엔트리 관리 (journald)
• 네트워크 연결 관리 (networkd)
• 로그인 관리 (logind)

Unit, Unit 파일

• systemd가 관리하는 기본 개체 단위
• Unit 유형
  • service, socket, device, mount, automount, swap, target, path, timer, slice, scope
  • unit 파일의 suffix로 활용 (예: ssh.service)
• Unit 별로 수행할 작업의 정의나 설정은 unit에 정의
• Unit 파일 형싱 (INI 파일 형식)
  • Unit Section
    • Description : 사람이 읽을 수 있는 Unit 정보. 레이블로 활용
    • After, Requires, Wants : Unit의 종속성을 지정
  • Unit 유형 Section : Unit 유형에 따른 속성들 정의
    • ExecStart : 구동할 명령어를 지정 (절대 경로 사용)
    • Restart : 서비스 재시작 여부 지정
  • Install Section : Unit 설치와 관련된 정보 정의
    • Alias : Unit을 등록할 때 사용하는 이름
      • 예) systemctl enable sshd.service
    • WantedBy : Unit간 종속성 지정
      • 예) multi-user.target : 해당실행모드 구동 시 자동실행

systemctl

• systemd 관리용 도구
• systemd의 상태를 조사하고 설정을 변경하는데 사용되는 도구
  • 예) 모든, "load 되고 active 상태"의 서비스 확인
    • $ systemctl list-units --type=service
  • 예) active 여부와 관계없이 모든 설치된 서비스 확인
    • $ systemctl list-unit-files --type=service
• 자주 사용되는 systemctl 서브 커맨드
  • enable [unit] : unit이 부팅 시 자동 활성화
  • disable [unit] : unit이 부팅 시 자동 활성화되는 것을 방지
  • isolate [target] : 타겟의 실행 모드를 변경
  • start [unit] : unit을 즉시 활성화
  • stop [unit] : unit을 즉시 비활성화
  • restart [unit] : unit을 재시작. 실행되지 않은 상태였다면 start
  • status [unit] : unit의 상태 및 최근 로그 내용을 확인
  • kill [pattern] : 패턴과 일치하는 unit에 시그널을 보냄
  • reboot : 컴퓨터를 재시작
  • daemon-reload : unit 파일들과 systemd 설정 정보를 다시 로드

Unit 간의 의존성

• Unit 파일의 [Unit] 영역에 명시적 종속성 설정을 지원
• 패키지 매니저를 통해 설치한 경우, 관련된 설정이 포함됨
• 예) Wants
  • 가능하다면 함께 실행이 필요한 unit
  • 반드시 요구되는 종속성은 아님
• 예) Requires
  • 엄격한 의존성을 가짐.
  • 종속성을 가진 unit이 실패하는 경우 서비스가 종료됨

Unit 간의 실행 순서 조정

• Before, After 제약을 지정해 순서를 조정할 수 있음
  • Wants, Requires 보다 After 속성이 자주 사용됨
• 명시적으로 요청되지 않은 경우 직렬적인 종속성은 없음
  • 병렬적 수행이 용이하도록 설계됨

시스템 재부팅 및 종료

시스템 문제의 경우

• 운영중인 시스템 재부팅은 서비스 중단을 초래한다.
• 근본적인 원인을 찾아야한다.
  • 예) 메모리 풀, 네트워크 소켓 수 증가 등을 단순히 재부팅으로 해결하면 안된다.
• 시작 스크립트를 수정하거나 중요한 설정을 변경한 후에는 재부팅해 검증이 필요하다.
  • 몇 주가 지난 시점에 변경된 설정으로 문제가 발생하면 원인을 추적하는데 매우 큰 비용이 발생한다.

물리 호스트 종료

• halt, shutdown(로그인된 사용자에게 알림), reboot(재시작)
• 예) 종료 : sudo shutdown -h now / sudo halt -p
• 예) 재부팅 : sudo reboot

클라우드 가상 머신 종료

• halt, shutdown, reboot
• 웹 콘솔, API 이용
  • 권장하지 않음. 물리 호스트의 전원을 끄는 것과 유사하기 때문이다.
• 인스턴스 종료(termination)는 인스턴스를 삭제
  • 복구가 안된다고 봐야한다.
  • 종료 방지 기능 사용

서버가 부팅이 되지 않을 때

부팅에 실패한 시스템 복구 방법

• 디버깅하지 않고 백업에서부터 복구
  • 클라우드에서 많이 사용되는 방법
• 디버깅 모드로 시스템을 구동해 복구
  • 단일 사용자 모드(single-user mode), 복구 모드(rescue mode), 긴급 모드(emergency mode)를 사용해 복구
  • 네트워크 사용 불가이기 때문에 콘솔에 물리적인 접근이 필요하다.
    • 최신 세대 EC2는 직렬 콘솔 접근을 제공하지만, 사전 조건들이 있다.
  • 클라우드에서는 사용이 힘든 방법이다.
• 복구 머신 이용하여 복구
  • 다른 시스템 이미지로 부팅한 후 문제가 있는 시스템의 파일시스템을 디버깅 서버에 마운트해 복구
  • 클라우드 환경에서 많이 사용한다.