Kernel hugepages does not alter the calculation of SHMMAX, which you need to set large enough to fit your largest Oracle SGA. SHMMAX applies to SYS V shared memory, which can be hugepages or use conventional 4K memory pages. SHMMAX is not relevant when you use /dev/shm POSIX shared memory (Oracle AMM).
The Oracle database requires shared memory for the SGA. This can be Sys V (IPC) or POSIX /dev/shm.
Shared memory and semaphores, and the SHM kernel parameters, belong to System V IPC, which can be monitored using the ipcs command. Sys V shared memory can be configured to be 2 MB kernel hugepages, or use the default 4 KB memory pages. Kernel hugepages can drastically reduce the memory requirements for managing required memory pages and make better use of the TLB buffer.
The SHMMAX parameter is used to define the maximum size (in bytes) for a shared memory segment and should be set large enough for the largest SGA size. If the SHMMAX is set incorrectly, for example too low, you may receive the following error: ORA-27123: unable to attach to shared memory segment.
SHMMAX for a server that runs Oracle database is typically set to 4 TB or whatever the platform being x86 or x64 theoretically supports. The parameter is a safeguard parameter. A process cannot use more shared memory than available. Obviously this is not considered a risk when using a dedicated server for running Oracle database.
POSIX shared memory maps shared memory to files using a virtual shared memory filesystem in RAM. It uses /dev/shm and applies when configuring the Oracle database to use Automatic Memory Management (AMM). An Oracle instance can use either Sys V shared memory including kernel hugepages or /dev/shm for SGA, but not both at the same time. You can however use different shared memory concepts for different Oracle instances on the same server. For example, running an +ASM instance using AMM and another Oracle database instance using ASMM.
XFS 파일 시스템은 요즘에 들어서 많이 사용되는 파일 시스템입니다. SGI 회사에서 개발한 것으로 대용량 파일 시스템으로 특화되어 있습니다. 최근들어 Big Data 가 대두되면서 스토리지 용량이 대용량화 되면서 XFS 가 떠오르는데, CentOS 7 배포판은 기본 파일시스템으로 XFS 가 되었습니다.
XFS 는 옵션들이 많이 있는데, 보통 대용량으로 많이 사용할 경우에 다음과 같은 옵션을 주로 많이 사용합니다.
CentOS 6 에는 가상화로 KVM만 지원합니다. Xen은 빼버렸습니다. 가상화로 KVM을 하게되면 사용할 수 있게됩니다. 그런데, KVM을 활성화하게 되면 virbr0 라는 가상의 이더넷이 생성이되는데 이것이 NAT로 동작하게 됩니다. 그러니까 KVM의 게스트들은 virbr0 의 NAT를 이용해서 인터넷을 하게 되는 것입니다.
그런데 제가 집에서 사용하는 인터넷 사용환경은 공유기를 이용해서 각 피시에서 private ip 주소를 할당해서 사용합니다. 그래서 KVM의 게스트들도 직접 공유기로 부터 private ip 주소를 할당 받기를 원했습니다. 그렇게 하기위해서는 virbr0 를 NAT를 정지시키고 br0 을 만들어서 eth0와 br0를 Bridged 시키면 됩니다.
이 문서는 이것을 설명한 것입니다.
처음 KVM을 설치해서 보면 다음과 같이 나옵니다. NAT로 동작하고 있다는 증거입니다.
KVM의 NAT 네트워크
ZSH
1
2
3
4
5
6
7
8
9
# ifconfig virbr0
virbr0 Link encap:Ethernet HWaddr00:00:00:00:00:00
AWS 는 전 세계적으로 가장 인기있는 Cloud Platform 이다. Web Console을 이용해서 원하는 자원을 구성하고 컴퓨터, 네트워크, 저장소등을 실시간으로 생성할 수 있으며 네트워킹 구성도 실시간으로 구성이 가능하다.
그래서 많은 IT 업체들이 AWS 클라우드를 사용하고 있다. 특히나 전 세계를 대상으로 인터넷 서비스를 하려는 업체들은 AWS 를 통해서 막대한 IT 인프라 구축비용 절감하고 있다.
오늘은 AWS 클라우드를 이용해서 가장 많은 구성이며 기본적인 구성인 Web Service 를 Private Subnet 을 이용해 구성해보도록 하겠다.
이 포스트는 AWS 클라우드에 대해서 어느정도 기초지식을 갖추고 있다고 가정하고 쓰여졌다. AWS 클라우드를 사용하기 위해서는 기본적인 개념들이 존재하는데, 예를들어 VPC, ELB, Security Group, Route Table, InterGateWay 등에 대해서 모두 알고 있다라고 가정한다.
목표
내가 목표로하는 전체적인 시스템 구성은 다음과 같다.
위 구성도에서 눈여겨 봐야할 포인트는 다음과 같다.
외부 인터넷과 연결을 위해서 반드시 Public Subnet 이 한개는 있어야 한다.
서비스를 제공할 인스턴스들은 Private Subnet 에 있어야 한다.
Private Subnet 에 있는 인스턴스들에서 외부와의 인터넷 통신은 Public Subnet 에 있는 NAT 서버를 통해서 한다.
Private Subnet 에 Web Service 인스턴스들은 ELB(Elastic Load Balancer) 를 통해서 하며 ELB는 반드시 Public Subnet 에 있어야 한다.
VPC 생성하기
AWS 서비스에 가입하면 각 Region 마다 기본적인 사항들이 자동으로 생성된다. 그중에 VPC도 다음과 같이 기본으로 생성이 된다. Tokyo Region은 다음과 같다.
VPC CIDR: 172.31.0.0/16
Route table: rtb-ef0bcd8a
Network ACL: acl-3cef2859
Subnet: subnet-55d41722
Subnet Type: Public
Default VPC 은 인터넷과 자동으로 연결된 거대한 하나의 Public Subnet 기도 하다. 하지만 나는 이 Public Subnet 을 사용하지 않고 새롭게 VPC을 생성할 것이다. VPC 의 생성에서 고려해야할 사항은 얼마만큼의 IP 대역을 사용할 것인가에 있다.
Web Service VPC 생성
Subnet 생성하기
이제 서브넷을 생성해야 한다. 중요한 것은 Public Subnet 1개와 Private Subnet 1개는 반드시 있어야 한다.
여기서 중요한 것도 IP 대역이다. 한 서브넷에 얼마만큼의 IP 대역을 쓸것인가 하는 것이다. 나는 다음과 같이 할당 했다.
Public Subnet: 10.31.0.0/22 – 1018 개 IP 대역, AZ: ap-northeast-1b, Name: JumpSubnet(NAT)
Private Subnet: 10.31.4.0/22 – 1018 개 IP 대역, AZ: ap-northeast-1b, Name: WebSubnet
여기서 한가지 Public Subnet, Private Subnet 을 구분하는 설정값은 존재하지 않는다. AWS 에서 이 둘의 구분은 Internet Gateway 와 연결이 되어진 네트워크이냐 아니냐에 따라 달라진다. Internet Gateway 에 연결되었다면 Public, 그렇지 않으면 Private 이라는 개념이다. 그럼 이러한 연결 설정은 어디서 하는가?
Subnet 에 대해서 Internet Gateway 연결을 하거나 기타 네트워크 경로 설정은 Route Table 에서 하기 된다. Route Table 에서 생설할때에 고려해야 할 사항은 다음과 같다.
어느 서브넷과 연결시킬 것인가?
어떤 외부세계와 연결시킬 것인가?
Route Table 이 존재하면 수정을하고 없으면 생성을 하면 된다.
Public Subnet
Public 서스넷 Route Table 서브넷 연결
Public 서스넷 Route Table 라우팅 테이블
Public Subnet 을 위한 Route Table 은 위와같이 연결할 서브넷과 라우팅 테이블을 정의해주면 된다. 여기서 핵심은 라우팅 테이블에서 Internet Gateway 연결을 해줘야한다. 위 화면에서 igw-98de5cfd 가 바로 그것이다.
Internet Gateway 가 연결되어 있다면 그것이 Public Subnet 이 된다.
Private Subnet
Private 서스넷 Route Table 서브넷 연결
Private 서스넷 Route Table 라우팅 테이블
Private Subnet 을 위한 서브넷 연결과 라우팅 테이블은 위와 같습니다. 라이팅 테이블을 보면 Internet Gateway 연결이 없다. 그래서 이 라우팅 테이블과 연결된 Subnet 은 Private Subnet 이 된다.
Private Subnet 은 외부 인터넷과 연결이 안되기 때문에 Private Subnet 인스턴스에 접속하고 제어하고 Private Subnet 의 인스턴스들이 인터넷연결을 위한 NAT 인스턴스가 필요하다.
Security Group 생성
Security Group 은 인터넷 방화벽이라고 생각하면 편하다. Security Group 은 인스턴스마다 할당할 수 있다. Security Group 에도 NAT를 위한 것과 NAT 에 의존해야할 인스턴스를 위한 것 두개를 만든다.
Security Group 을 생성할대는 Inbound 프로토콜, 포트 와 Outbound 프로토콜, 포트 를 생각해야 한다.
NAT Security Group
Outbound 는 “All Traffic” 으로 제약을 풀어줘도 된다. 보안상 외부로의 접속을 차단해야할 상황이라면 설정을 해야하면 된다.
Inbound 접속 제한을 해야함으로 다음과 같이 설정해준다.
NAT 를 위한 Security Group
중요한 사항은 80, 443, ICMP 에 대한 NAT 접속은 Private Subnet 으로부터 받는걸로 설정을 해야 한다는 것이다.
NAT 의존하는 인스턴스를 위한 Security Group
Outbound 는 “All Traffic” 으로 제약을 풀어줘도 된다. 물론 보안상 문제가 된다면 제한을 걸고 싶은 포트를 지정해주면 된다.
NAT 에 의존하는 인스턴를 위한 Security Group
SSH 서비스 접속포트는 NAT 서버 주소를 지정해준다. HTTP, HTTPS, ICMP 는 모든 영역에서 접속을 허용하도록 한다. 왜 이렇게 하냐하면 HTTP, HTTPS 는 AWS 의 Public ELB 를 통해서 외부로 서비스를 해야하는데 Public ELB -> private subnet 인스턴스에 접속이 이루어져야 하기 때문인데 문제는 접속할 IP를 알수가 없다. 그래서 접속하는 주소지를 모두 열어준다.
NAT Instance 생성
NAT Instance 가 필요한 이유는 다음과 같다.
Private Subnet 에 있는 인스턴스들을 제어하기 위해
Private Subnet 에 있는 인스턴스들이 인터넷을 하기 위해.
Private Subnet 에 있는 인스턴스들이 인터넷이 되어야 하는 이유는 OS 및 각종 소프트웨어의 자동 업데이트 때문이다. 보안 업데이트를 하기위해서는 업데이트 프로그램을 다운로드해야하는데 대부분 인터넷을 통해서 다운로드가 된다. 따라서 Private Subnet 도 인터넷이 되어야 한다.
또다른 이유는 AWS 의 S3 와 같은 외부 서비스를 이용하기 위해서다. S3 저장소는 HTTP 주소를 통해서 자원에 접근할 수 있도록 해주는데, 이를 Private Subnet 에서 이용하기 위해서는 인터넷이 되어야 한다.
NAT Instance 는 외부에서 연결을 해야함으로 EIP를 할당해준다. EIP가 없더라도 Public Ip를 할당해줘야 한다. 그리고 Subnet 은 Public Subnet 과 연결해 준다.
Instance: EC2 Linux System
Subnet: JumpSubnet(NAT)
Seucrity Group: NAT 를 위해 생성한 Security Group
EIP, Public IP 할당
중요한 것은 반드시 Public Subnet 에 인스턴스를 생성해 준다.
Private Subnet Route Table 조작
이제 앞에서 Private Subent 의 Route Table 을 조작할 때다. Private Subnet 의 Route Table 은 Local 외에 모든 연결을 NAT Instance 로 가게 설정 한다.
Private Subnet 을 위한 라우팅 테이블 조작
위와 같이 두번째 타켓으로 NAT 인스턴스를 지정해 준다. 그러면 이 라이팅에 연결된 Subnet 들은 외부와 통신을 위해서 NAT 인스턴스를 통해서 이루어지게 된다.
NAT 인스턴스 마스커레이딩 설정
지금까지의 내용은 인터넷을 찾아보면 나온다. 하지만 여기까지만 하면 절대로 Private Subnet 에 인스턴스에서 인터넷이 될수가 없다. 지금까지의 작업은 Network 단에서의 작업이였다. Security Group은 인스턴스단에서 이루어진 방화벽 작업일뿐 패킷의 경로를 조작해주는 것은 아니였다.
그런데, 이 모든 것을 다한다고 하더라도 OS에서 패킷의 경로를 원하는대로 조작해주지 않으면 Private Subnet 에 인스턴스들로부터 온 패킷과 받는 패킷들은 전송되지 않는다.
NAT 라는 것을 간단하게 설명하자면 우리가 가정에서 많이 쓰는 공유기와 같은 기능을 한다. 외부의 공인아이피를 가지고 내부의 사설 아이피를 할당해서 인터넷이 되게하는 것이 공유기의 역활인데, NAT 도 똑같다.
공유기가 없던 시절에 리눅스를 이용해서 공유기를 만들었었는데, 리눅스에 네트워크 카드를 두개 끼우고 하나는 외부망에 하나는 내부망에 연결하고 내부망에 허브를 두고 서로 통신이되도록 리눅스에서 설정을 해줬었다. 이 설정을 마스커레이딩(MASQUERADE) 이라 불렀다.
먼저 리눅스 커널에서 패킷을 포워딩 하도록 다음과 같이 설정해 준다.
리눅스 커널 설정
ZSH
1
2
3
4
5
]# vim /etc/sysctl.d/nat.conf
net.ipv4.ip_forward=1
net.ipv4.conf.eth0.send_redirects=0
]# sysctl -p /etc/sysctl.d/nat.conf
그리고 iptables 에 nat 체인에 마스커레이딩 설정을 해준다.
iptable NAT 설정.
ZSH
1
2
3
4
5
6
7
8
9
]# vim /etc/iptables.rules
*nat
:PREROUTING ACCEPT[0:0]
:INPUT ACCEPT[0:0]
:OUTPUT ACCEPT[0:0]
:POSTROUTING ACCEPT[0:0]
-APOSTROUTING-oeth0-jMASQUERADE
COMMIT
]# /sbin/iptables-restore < /etc/iptables.rules
Private 인스턴스 접속
Private 인스턴스를 접속하기 위해서는 다음과 같은 절차를 따른다.
먼저 NAT 서버에 SSH 접속을 한다.
NAT 서버에서 Private 인스턴스로 접속을 한다.
Private 인스턴스에 접속한 후에 OS 업데이트 명령을 쳐보고 잘된다면 설정이 제대로 된 것이다.
ELB 설정.
Elastic Load Balancer 는 여러개의 서버들을 한대 묶어서 분산을 시켜주는 역활을 한다. 기존의 L4 스위치와 같은 역활을 하는 것인데 설정을 하게되면 ELB 접속을 위한 도메인이 생성된다. 이 도메인은 Amazon 에서 자동할당된 것으로 이것을 바꾸고 싶다면 DNS 서버에서 CNAME 으로 도메인을 등록하면 된다.
한가지 ELB의 제약 조건이 있는데, 그것은 반드시 Internet Gateway 와 연결되어야 한다. 이 말을 바꿔서 말하면 ELB는 반드시 Public Subnet 에 위치해야 한다는 뜻이다.
결국 ELB 때문이라도 반드시 하나의 Public Subnet 이 있어야 한다는 결론이 나온다.
ELB 설정
위 그림을 보면 JumpSubnet(NAT)가 보이는데, 이게 바로 Public Subnet 이다. 반드시 1개의 Public Subnet 을 포함한다면 나머지 서브넷은 Private 이여도 상관이 없고 Private Subnet 에 있는 인스턴스들도 ELB를 통해서 서비스를 할 수 있게 된다.
ELB 에서 뒷단의 인스턴스들을 선택하기 위해서는 먼저 Subnet 을 반드시 선택해줘야 한다.
Private Subnet 의 인스턴스가 선택된 상태
위와 같이 Private Subnet 의 인스턴스를 선택할 수 있다. ELB의 경우 대부분 HTTP 80 을 Inbound 로 받기 때문에 Private Subnet 안에 설치한 인스턴스에 웹서버를 올리기 되면 ELB를 통해서 서비스를 제공할 수 있게 된다.
이것으로 간단하게 Private Subnet 으로 서비스 구성하기 에 대해 간단하게 정리해 봤다.
CentOS 7로 배포판 버전이 바뀌면서 가장 크게 바뀐것이 Systemd 입니다. 기존의 볼수 없었던 서비스 하나일뿐이라고 생각할 수 있지만 Systemd 는 단지 서비스 하나의 문제가 아닙니다.
Linux 의 기본 뼈대 프로세스
Linux는 운영체제 입니다. 전원을 넣고 부팅이 되는 과정에서 시스템을 초기화하고 기타 서비스들을 위한 환경을 조성하고 그들을 시작시켜주는 일을 하는 초기화 프로세스가 필요합니다.
CentOS 6 까지는 Sys V 라고해서 init 프로세스가 이것을 담당했습니다. 커널이 메모리에 로딩되면 가장 먼저 실행되는 프로세스로 init 프로세스를 실행시킵니다. 이 프로세스는 init 스크립트, init 설정등을 기반으로 RunLevel 이나 각 서비스별 실행 스크립트를 실행시키는 겁니다.
CentOS 7 로 올라오면서 Sys V 의 init 프로세스를 버리고 Systemd 로 바꾼 겁니다. 이는 Linux 의 기본 뼈대 프로세스를 바꾼 것으로 매우 큰 변화라고 할만 합니다. Systemd 는 기준의 Sys V init 보다 훨씬 많은 기능을 제공 합니다.
시스템 부팅 프로세스
Service Management
cgroup 을 이용한 프로세스 자원관리
서비스 프로세스 관리
흔히들 Daemon 프로그램들을 위한 로깅, 자원할당, 부팅관리등 Systemd 로 모두 할 수 있습니다.
주요한 명령어들
Systemd 를 위한 주요한 명령어들은 다음과 같습니다.
systemctl
systemd-analyze
systemd-cgls
systemd-cgtop
systemd-loginctl
현재 작동하고 있는 서비스들 목록은 다음과 같이 확인 가능 합니다.
systemctl
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
~]# systemctl
UNIT LOAD ACTIVE SUB DESCRIPTION
proc-sys-fs-binfmt_misc.automountloaded active waiting Arbitrary Executable File Formats File System Automount Point
sys-devices-pci0000:00-0000:00:01.1-ata2-host1-target1:0:0-1:0:0:0-block-sr0.deviceloaded active plugged QEMU_DVD-ROM
sys-devices-pci0000:00-0000:00:03.0-virtio0-net-eth0.deviceloaded active plugged Virtio network device
sys-devices-pci0000:00-0000:00:04.0-sound-card0.deviceloaded active plugged82801FB/FBM/FR/FW/FRW(ICH6 Family)High Definition Audio Controller(QEMU Virtual Machine)
sys-devices-pci0000:00-0000:00:05.0-virtio1-block-vda-vda1.deviceloaded active plugged/sys/devices/pci0000:00/0000:00:05.0/virtio1/block/vda/vda1
sys-devices-pci0000:00-0000:00:05.0-virtio1-block-vda-vda2.deviceloaded active plugged/sys/devices/pci0000:00/0000:00:05.0/virtio1/block/vda/vda2
sys-devices-pci0000:00-0000:00:05.0-virtio1-block-vda.deviceloaded active plugged/sys/devices/pci0000:00/0000:00:05.0/virtio1/block/vda
sys-devices-platform-serial8250-tty-ttyS1.deviceloaded active plugged/sys/devices/platform/serial8250/tty/ttyS1
sys-devices-platform-serial8250-tty-ttyS2.deviceloaded active plugged/sys/devices/platform/serial8250/tty/ttyS2
sys-devices-platform-serial8250-tty-ttyS3.deviceloaded active plugged/sys/devices/platform/serial8250/tty/ttyS3
sys-devices-pnp0-00:04-tty-ttyS0.deviceloaded active plugged/sys/devices/pnp0/00:04/tty/ttyS0
sys-module-configfs.deviceloaded active plugged/sys/module/configfs
sys-subsystem-net-devices-eth0.deviceloaded active plugged Virtio network device
-.mountloaded active mounted/
dev-hugepages.mountloaded active mounted Huge Pages File System
dev-mqueue.mountloaded active mounted POSIX Message Queue File System
run-user-0.mountloaded active mounted/run/user/0
위 목록은 현재 동작중인 서비스들만 보여주는데, 모든 서비스들을 보고 싶다면 다음과 같습니다.
모든 서비스 목록
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
~]# systemctl list-unit-files
UNIT FILE STATE
session-2.scopestatic
arp-ethers.servicedisabled
auditd.serviceenabled
autovt@.servicedisabled
avahi-daemon.serviceenabled
blk-availability.servicedisabled
brandbot.servicestatic
console-getty.servicedisabled
console-shell.servicedisabled
container-getty@.servicestatic
cpupower.servicedisabled
crond.serviceenabled
dbus-org.fedoraproject.FirewallD1.serviceenabled
dbus-org.freedesktop.Avahi.serviceenabled
dbus-org.freedesktop.hostname1.servicestatic
dbus-org.freedesktop.locale1.servicestatic
dbus-org.freedesktop.login1.servicestatic
dbus-org.freedesktop.machine1.servicestatic
dbus-org.freedesktop.network1.serviceinvalid
서비스 활성화, 비활성화, 시작, 정지, 재시작
부팅시에 서비스를 시작하도록 하기위 해서는 다음과 같이 해줍니다.
부팅시 서비스 활성화 방법
ZSH
1
2
~]# systemctl enable vsftpd
Created symlink from/etc/systemd/system/multi-user.target.wants/vsftpd.serviceto/usr/lib/systemd/system/vsftpd.service.
서비스 비활성화, 시작, 중지, 재시작, 릴로드는 다음과 같습니다.
비활성화, 시작, 중단, 재시작, 릴로드 방법
ZSH
1
2
3
4
5
~]# systemctl disable vsftpd
~]# systemctl start vsftpd
~]# systemctl stop vsftpd
~]# systemctl restart vsftpd
~]# systemctl reload vsftpd
서비스가 활성화, 실행중인지 다음과 같이 질의를 할 수 있습니다.
서비스가 활성화, 실행 질의.
ZSH
1
2
3
4
~]# systemctl is-enabled vsftpd
[enabled,disabled]
~]# systemctl is-active vsftpd
[inactive,active,failed]
서비스 및 설정 파악
서비스에 대한 systemd 설정에 대한 모든 정보를 다음과 같이 확인할 수 있습니다.
서비스의 systemd 정보 확인.
ZSH
1
]# systemctl show http.service
각 서비스들은 서로간의 의존관계를 가지고 있습니다. 이는 다음과 같은 명령어로 확인이 가능합니다.
systemctl list-dependencies
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
~]# systemctl list-dependencies
default.target
●├─auditd.service
●├─avahi-daemon.service
●├─brandbot.path
●├─crond.service
●├─dbus.service
●├─irqbalance.service
●├─kdump.service
●├─mariadb.service
●├─network.service
●├─NetworkManager.service
●├─nginx.service
●├─openstack-glance-api.service
●├─openstack-glance-registry.service
●├─php-fpm.service
●├─plymouth-quit-wait.service
●├─plymouth-quit.service
특정 서비스에 대한 의존성을 알고 싶다면 서비스명을 주면 됩니다.
systemctl list-dependencies mariadb.service
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
~]# systemctl list-dependencies mariadb.service
mariadb.service
●├─-.mount
●├─system.slice
●└─basic.target
●├─firewalld.service
●├─microcode.service
●├─rhel-autorelabel-mark.service
●├─rhel-autorelabel.service
●├─rhel-configure.service
●├─rhel-dmesg.service
●├─rhel-loadmodules.service
●├─paths.target
●├─slices.target
●│├─-.slice
●│└─system.slice
Systemd 자체를 재시작하기 위해서는 다음과 같이 합니다.
systemd 재시작.
ZSH
1
]# systemctl daemon-reload
Unit File 편집
다음과 같이 Unit file 출력도 지원합니다.
Unit file 내용 보기.
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
]# systemctl cat ntpd.service
# /usr/lib/systemd/system/ntpd.service
[Unit]
Description=Network Time Service
After=syslog.targetntpdate.servicesntp.service
[Service]
Type=forking
EnvironmentFile=-/etc/sysconfig/ntpd
ExecStart=/usr/sbin/ntpd-untp:ntp$OPTIONS
PrivateTmp=true
[Install]
WantedBy=multi-user.target
Systemd 는 기본적으로 /usr/lib/system 디렉토리에 Unit File 을 보관합니다. 그런데, 커스터마이징 하기위해서 이 파일들을 직접 편집하기 보다는 /etc/systemd/system/ntpd.service.d 처럼 커스터마이징 하고 싶은 서비스의 디렉토리를 만들고 .conf 로 끝나는 설정파일을 만들어서 바꾸고자하는 설정을 넣으면 됩니다. 만일 이러한 과정이 귀찮다면 단순하게 다음과 같이 함으로써 자동으로 알아서 커스터마이징 설정파일을 만들어줍니다.
커스터 마이징 설정파일 만들기.
ZSH
1
]# systemctl edit ntpd
위 명령어는 다음을 수행 합니다.
/etc/systemd/system/ntpd.service.d 디렉토리 생성
시스템에 등록된 기본 편집기(대부분 VIM)을 연다.
내용을 입력하고 저장하면 1에서 생성한 디렉토리에 override.conf 파일을 생성하고 내용을 읽는다. (여기서 systemctl daemon-reload 는 불필요)
만일 /usr/lib/system/system/ntpd.service Unit File 자체를 편집하고 싶다면 –full 옵션을 주면 됩니다.
Unit File 자체 편집
ZSH
1
]# systemctl edit ntpd --full
부팅 상태 분석
Systemd 의 주요한 임무는 부팅 과정을 관리하고 정보를 제공하는 것입니다. 부팅 시간 정보는 다음과 같이 확인할 수 있습니다.
Systemd 에서 타겟(Target)은 동시에 서비스들을 시작하는걸 허용하기 위한 그룹 메커니즘입니다. 이는 Sys V 에 Run Level 과 비슷합니다. Sys V 에서는 init 명령어를 통해서 Run Level 를 바꿀 수 있었는데, Systemd 는 타겟을 바꿀 수 있습니다.