Category: HowTo

x86_64 시스템에서 4MB 크기 HugePageSize 변경 불가.

HugePage 는 Linux 의 기본 메모리 페이지 크기인 4K(4096) 가 아닌 더 큰 페이지를 사용하도록함으로서 잦은 메모리 액세스를 줄여 자원 소모를 줄이게 해준다.

최신의 Linux 는 전부 이것을 지원하며 다음과 같이 확인 할 수 있다.

기본 메모리 페이지는 Hugepagesize 인 2MB(2048kb) 임을 확인할 수 있다.

그런데, 이 메모리 페이지 크기를 바꿀 수 있지 않을까? 결론부터 말하면 불가능하다.

이 Hugepagesize 는 CPU 지원에 의존한다.

  • 2MB – cpu에 ‘pse’ 가 지원되면 된다.
  • 1G – cpu 가 ‘pdpe1gb’ 가 지원되면 된다.

최신의 CPU 는 위 두가지 ‘pse’, ‘pdpe1gb’ 를 모두 지원한다. 1GB 의 메모리 페이지를 지원한다. 하지만 4MB 의 메모리 페이지를 지원하지 않는다. 그렇다면 왜 이 글을 쓰는가? 이유는 MySQL 문서 때문이다.

shell> cat /proc/meminfo | grep -i huge
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 4096 kB

https://dev.mysql.com/doc/refman/5.7/en/large-page-support.html

MySQL 문서를 보면 위와 같이 4096Kb 라고 나온다. 하지만 x86_64 시스템에서는 절대로 4096kb 가 될수가 없다. 2MB 아니면 1GB 만 가능하다.

혹시나 해서 이것을 바꾸기 위해서 다음과 같이 부팅 파라메터를 주고 재부팅을 해뒀다.

하지만 부팅 메시지에 다음과 같이 나온다.

지원하지 않는다는 메시지를 보여준다.

결론은 Hugepagesize 는 CPU 에서 지원해줘야 하는 것이며 최신의 x86_64 의 경우 2MB, 1GB 두가지만 지원한다.

Linux PAGE_SIZE 그리고 HugePage

다음의 글이 도움이 될 듯 싶다.

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.

https://community.oracle.com/thread/3828422

XFS 마운트 옵션.

XFS 파일 시스템은 요즘에 들어서 많이 사용되는 파일 시스템입니다. SGI 회사에서 개발한 것으로 대용량 파일 시스템으로 특화되어 있습니다. 최근들어 Big Data 가 대두되면서 스토리지 용량이 대용량화 되면서 XFS 가 떠오르는데, CentOS 7 배포판은 기본 파일시스템으로 XFS 가 되었습니다.

XFS 는 옵션들이 많이 있는데, 보통 대용량으로 많이 사용할 경우에 다음과 같은 옵션을 주로 많이 사용합니다.

 

UBUNTU 14.04 KVM 게스트에 콘솔 접속하기

KVM 가상화를 사용하고 있고 게스트로 Ubuntu14.04 를 사용하고 있다면 콘솔 접속을 위해서는 다음과 같이 해주어야 한다.

ttyS0 터미널 설정

KVM 게스트인 Ubuntu14.04 에 콘솔로 접속하기 위해서는 게스트 Ubuntu14.04 에 ttyS0 터미널로 접속을 해야 한다. 그런데 Ubuntu 14.04 에는 ttyS0 터미널 설정이 되어 있지 않아 이를 설정을 해야 한다.

/etc/init/ttyS0.conf 파일을 다음과 같이 생성한다.

 

그리고 다음과 같이 /etc/securetty 파일에 ttyS0 를 추가 해준다.

 

/etc/default/grub 편집

이제 grub 에서 ttyS0 이 콘솔 접속이 되도록 다음과 같이 편접해 준다.

위와같이 편접을 한 후에 grub 을 다시 시작해 줍니다.

 

위와같이 설정을 하고 재부팅을 한 후에 KVM 콘솔 접속을 하면 아주 잘 됩니다.

 

KVM에 Bridge Network 설정

CentOS 6 에는 가상화로 KVM만 지원합니다. Xen은 빼버렸습니다. 가상화로 KVM을 하게되면 사용할 수 있게됩니다. 그런데, KVM을 활성화하게 되면 virbr0 라는 가상의 이더넷이 생성이되는데 이것이 NAT로 동작하게 됩니다. 그러니까 KVM의 게스트들은 virbr0 의 NAT를 이용해서 인터넷을 하게 되는 것입니다.

그런데 제가 집에서 사용하는 인터넷 사용환경은 공유기를 이용해서 각 피시에서 private ip 주소를 할당해서 사용합니다. 그래서 KVM의 게스트들도 직접 공유기로 부터 private ip 주소를 할당 받기를 원했습니다. 그렇게 하기위해서는 virbr0 를 NAT를 정지시키고 br0 을 만들어서 eth0와 br0를 Bridged 시키면 됩니다.

이 문서는 이것을 설명한 것입니다.

처음 KVM을 설치해서 보면 다음과 같이 나옵니다. NAT로 동작하고 있다는 증거입니다.

Bridged 로 바꿔보겠습니다. 절차는 다음과 같습니다.

  1. virbr0 를 지웁니다.
  2. eth0 에 dhcp 기능을 지우고 br0 로 Bridged 한다.
  3. br0 만드는데, dhcp 로 아이피를 새로 받도록 한다. TYPE 를 Bridged 로 해준다.

Virbr0 를 지운다. 

버추얼쉘(virsh) 명령어를 이용해 네트워크 리스트를 봅니다.

버추얼 네트워크 이름이 ‘default’로 나오네요. 이것을 지우겠습니다.

eth0 의 dhcp 를 지우고 br0 로 Bridged 한다.

다음과 같이 합니다.

br0 를 만든다.

다음과 같이 합니다.

위과정을 거치면 설정은 끝납니다. 한가지 더 있는데, 리눅스의 NetworkManager 데몬을 꺼주고 network 서비스를 다시 올려줍니다.

이제 virt-manager 로 KVM 게스트를 설치할 다음과 같이 이더넷을 설정해 주면 됩니다.

Virt-Manager 에서 Br0 설정

 

Ubuntu 16.04 KVM 게스트에 콘솔 접속하기

KVM 가상화를 사용하고 있고 게스트로 Ubuntu16.04 를 사용하고 있다면 콘솔 접속을 위해서는 Grub2 설정을 다음과 같이 해주면 된다.

위와같이 해주고 다음과 같이 grub 을 갱신해준다.

 

[AWS] Private Subnet 으로 서비스 구성하기.

AWS 는 전 세계적으로 가장 인기있는 Cloud Platform 이다. Web Console을 이용해서 원하는 자원을 구성하고 컴퓨터, 네트워크, 저장소등을 실시간으로 생성할 수 있으며 네트워킹 구성도 실시간으로 구성이 가능하다.

그래서 많은 IT 업체들이 AWS 클라우드를 사용하고 있다. 특히나 전 세계를 대상으로 인터넷 서비스를 하려는 업체들은 AWS 를 통해서 막대한 IT 인프라 구축비용 절감하고 있다.

오늘은 AWS 클라우드를 이용해서 가장 많은 구성이며 기본적인 구성인 Web Service 를 Private Subnet 을 이용해 구성해보도록 하겠다.

이 포스트는 AWS 클라우드에 대해서 어느정도 기초지식을 갖추고 있다고 가정하고 쓰여졌다. AWS 클라우드를 사용하기 위해서는 기본적인 개념들이 존재하는데, 예를들어 VPC, ELB, Security Group, Route Table, InterGateWay 등에 대해서 모두 알고 있다라고 가정한다.

목표

내가 목표로하는 전체적인 시스템 구성은 다음과 같다.

Private Subnet 서비스 구성도

위 구성도에서 눈여겨 봐야할 포인트는 다음과 같다.

  • 외부 인터넷과 연결을 위해서 반드시 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 생성
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 서스넷 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 서스넷 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
NAT 를 위한 Security Group

중요한 사항은 80, 443, ICMP 에 대한 NAT 접속은 Private Subnet 으로부터 받는걸로 설정을 해야 한다는 것이다.

NAT 의존하는 인스턴스를 위한 Security Group

Outbound 는 “All Traffic” 으로 제약을 풀어줘도 된다. 물론 보안상 문제가 된다면 제한을 걸고 싶은 포트를 지정해주면 된다.

NAT 에 의존하는 인스턴를 위한 Security Group
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 을 위한 라우팅 테이블 조작
Private Subnet 을 위한 라우팅 테이블 조작

위와 같이 두번째 타켓으로 NAT 인스턴스를 지정해 준다. 그러면 이 라이팅에 연결된 Subnet 들은 외부와 통신을 위해서 NAT 인스턴스를 통해서 이루어지게 된다.

NAT 인스턴스 마스커레이딩 설정

지금까지의 내용은 인터넷을 찾아보면 나온다. 하지만 여기까지만 하면 절대로 Private Subnet 에 인스턴스에서 인터넷이 될수가 없다. 지금까지의 작업은 Network 단에서의 작업이였다. Security Group은 인스턴스단에서 이루어진 방화벽 작업일뿐 패킷의 경로를 조작해주는 것은 아니였다.

그런데, 이 모든 것을 다한다고 하더라도 OS에서 패킷의 경로를 원하는대로 조작해주지 않으면 Private Subnet 에 인스턴스들로부터 온 패킷과 받는 패킷들은 전송되지 않는다.

NAT 라는 것을 간단하게 설명하자면 우리가 가정에서 많이 쓰는 공유기와 같은 기능을 한다. 외부의 공인아이피를 가지고 내부의 사설 아이피를 할당해서 인터넷이 되게하는 것이 공유기의 역활인데, NAT 도 똑같다.

공유기가 없던 시절에 리눅스를 이용해서 공유기를 만들었었는데, 리눅스에 네트워크 카드를 두개 끼우고 하나는 외부망에 하나는 내부망에 연결하고 내부망에 허브를 두고 서로 통신이되도록 리눅스에서 설정을 해줬었다. 이 설정을 마스커레이딩(MASQUERADE) 이라 불렀다.

먼저 리눅스 커널에서 패킷을 포워딩 하도록 다음과 같이 설정해 준다.

그리고 iptables 에 nat 체인에 마스커레이딩 설정을 해준다.

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 설정
ELB 설정

위 그림을 보면 JumpSubnet(NAT)가 보이는데, 이게 바로 Public Subnet 이다. 반드시 1개의 Public Subnet 을 포함한다면 나머지 서브넷은 Private 이여도 상관이 없고 Private Subnet 에 있는 인스턴스들도 ELB를 통해서 서비스를 할 수 있게 된다.

ELB 에서 뒷단의 인스턴스들을 선택하기 위해서는 먼저 Subnet 을 반드시 선택해줘야 한다.

Private Subnet 의 인스턴스가 선택된 상태
Private Subnet 의 인스턴스가 선택된 상태

위와 같이 Private Subnet 의 인스턴스를 선택할 수 있다. ELB의 경우 대부분 HTTP 80 을 Inbound 로 받기 때문에 Private Subnet 안에 설치한 인스턴스에 웹서버를 올리기 되면 ELB를 통해서 서비스를 제공할 수 있게 된다.

 

이것으로 간단하게 Private Subnet 으로 서비스 구성하기 에 대해 간단하게 정리해 봤다.

가상 Guest 이미지 마운팅

가상 Guest OS의 이미지를 마운트하는 법을 설명합니다. 이미지 마운트에는 두가지 방법이 있습니다.

첫번째방법

1.Guest OS 이미지에 파티션으로부터 디바이스 맵(Device Map)을 생성합니다.

2.볼륨(Volume) 그룹을 스캔합니다.

이렇게 볼륨이 잡히면 이 방법은 유효합니다. 그렇지 않으면 두번째 방법을 사용해야 합니다.

3.볼륨(volume) 그룹의 속성을 바꿉니다.

볼륨의 상태를 확인합니다.

4.이제 볼륨을 마운팅하면 됩니다.


이렇게 마운트가 되면 마운트 포인터(Mount Point)를 통해서 접근할 수 있습니다. 언마운트(Umount)는 다음과 같이 합니다.

5.언마운트(Unmount) 합니다.

6.볼륨속성을 바꿉니다.

7.디바이스 맵을 지웁니다.

두번째 방법

두번째 방법은 위의 첫번째 방법 2번째에서 오류가 날경우에 사용하면 됩니다. 즉, 볼륨을 스캔했는데 볼륨이 없다면 바로 마운팅하는 것입니다.

1.Guest OS 이미지에 파티션으로부터 디바이스 맵(Device Map)을 생성합니다.

2.볼륨 그룹을 스캔합니다.

이렇게 볼륨 그룹이 없다고 나옵니다.

3.그냥 마운트를 하면 됩니다.

4.Unmount 는 다음과 같이 합니다.

 

CentOS 7 Systemd 이해하기

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 보다 훨씬 많은 기능을 제공 합니다.

  1. 시스템 부팅 프로세스
  2. Service Management
  3. cgroup 을 이용한 프로세스 자원관리
  4. 서비스 프로세스 관리

흔히들 Daemon 프로그램들을 위한 로깅, 자원할당, 부팅관리등 Systemd 로 모두 할 수 있습니다.

주요한 명령어들

Systemd 를 위한 주요한 명령어들은 다음과 같습니다.

  1. systemctl
  2. systemd-analyze
  3. systemd-cgls
  4. systemd-cgtop
  5. systemd-loginctl

현재 작동하고 있는 서비스들 목록은 다음과 같이 확인 가능 합니다.

위 목록은 현재 동작중인 서비스들만 보여주는데, 모든 서비스들을 보고 싶다면 다음과 같습니다.

서비스 활성화, 비활성화, 시작, 정지, 재시작

부팅시에 서비스를 시작하도록 하기위 해서는 다음과 같이 해줍니다.

서비스 비활성화, 시작, 중지, 재시작, 릴로드는 다음과 같습니다.

서비스가 활성화, 실행중인지 다음과 같이 질의를 할 수 있습니다.

서비스 및 설정 파악

서비스에 대한 systemd 설정에 대한 모든 정보를 다음과 같이 확인할 수 있습니다.

각 서비스들은 서로간의 의존관계를 가지고 있습니다. 이는 다음과 같은 명령어로 확인이 가능합니다.

특정 서비스에 대한 의존성을 알고 싶다면 서비스명을 주면 됩니다.

Systemd 자체를 재시작하기 위해서는 다음과 같이 합니다.

Unit File 편집

다음과 같이 Unit file 출력도 지원합니다.

Systemd 는 기본적으로 /usr/lib/system 디렉토리에 Unit File 을 보관합니다. 그런데, 커스터마이징 하기위해서 이 파일들을 직접 편집하기 보다는 /etc/systemd/system/ntpd.service.d 처럼 커스터마이징 하고 싶은 서비스의 디렉토리를 만들고 .conf 로 끝나는 설정파일을 만들어서 바꾸고자하는 설정을 넣으면 됩니다. 만일 이러한 과정이 귀찮다면 단순하게 다음과 같이 함으로써 자동으로 알아서 커스터마이징 설정파일을 만들어줍니다.

위 명령어는 다음을 수행 합니다.

  1. /etc/systemd/system/ntpd.service.d 디렉토리 생성
  2. 시스템에 등록된 기본 편집기(대부분 VIM)을 연다.
  3. 내용을 입력하고 저장하면 1에서 생성한 디렉토리에 override.conf 파일을 생성하고 내용을 읽는다. (여기서 systemctl daemon-reload 는 불필요)

만일 /usr/lib/system/system/ntpd.service Unit File 자체를 편집하고 싶다면 –full 옵션을 주면 됩니다.

부팅 상태 분석

Systemd 의 주요한 임무는 부팅 과정을 관리하고 정보를 제공하는 것입니다. 부팅 시간 정보는 다음과 같이 확인할 수 있습니다.

총 1분 28초 정도 부팅하는데 걸렸다는 걸 알수 있습니다.

부팅과정에 각 서비스별 초기화하는데 걸린 시간은 다음과 같이 확인할 수 있습니다.

초기화하는데 걸린 시간을 기준으로 정렬해서 정보를 보여줍니다. kdump.service 가 1분 4초정도의 시간을 소비했습니다.

이러한 분석은 다음과 같이 html 파일로 덤프해서 볼 수도 있습니다.

plot.html 은 다음과 같습니다.

systemd-analyze plot

부팅시에 시간이 많이 걸리는 서비스들에 대해서 빨강색으로 표시해줍니다. 이 정보는 부팅과정에서 소비되는 시간을 측정해서 개선점을 찾게 도와줍니다.

시간을 많이 잡아먹는 서비스들을 트리형태로 엮어서(chain)로 볼수도 있습니다.

MariaDB 서비스에 대해서 엮여서 시간을 많이 소모하는 하는 서비스들을 보여 줍니다.

특정 서비스에 대해서 critical-chain 을 보고 싶다면 인수로 서비스명을 주면 됩니다.

서비스 실행을 실패한 서비스들은 다음과 같이 체크 가능 합니다.

타겟바꾸기

Systemd 에서 타겟(Target)은 동시에 서비스들을 시작하는걸 허용하기 위한 그룹 메커니즘입니다. 이는 Sys V 에 Run Level 과 비슷합니다. Sys V 에서는 init 명령어를 통해서 Run Level 를 바꿀 수 있었는데, Systemd 는 타겟을 바꿀 수 있습니다.

이 타겟에 따라서 부팅시 시작되는 서비스들이 달라집니다. 기본 값은 muti-user.target 입니다. 기본 값은 다음과 같이 바꿀 수 있습니다.

 

KVM Ubuntu 가상머신에 콘솔 접속하기

Ubuntu 를 KVM 가상머신으로 설치를 했다면 콘솔 접속을 해보면 안됩니다. 지난번에 CentOS6/7 배포판에서의 가상머신 콘솔접속에 대해서 다루어 었는데, Ubuntu 는 이들과 조금 다르기에 포스팅 해봅니다.

이 글은 ubuntu 14.04 를 대상으로 합니다.

처음 Ubuntu 를 KVM 가상머신으로 설치를 했다면 SSH 나 Virt-manager 나 vnc 를 이용해서 접속을 해야만 합니다. 그래야 콘솔접속을 위한 설정을 해볼 수 있습니다.

GRUB 설정

공통 Grub 설정은 /etc/default/grub 에 있습니다. 다음과 같이 설정을 해줍니다.

그리고 다음과 같이 업데이트를 해줍니다.

Serial 콘솔 만들기

다음과 같이 Serial 콘솔을 만들어 줍니다.

그리고 ttyS0.conf 파일을 다음과 같은 부분을 편집해 줍니다.

위와같이 수정해주고 리붓을 해줍니다.

테스트

Ubuntu 가상머신을 재부팅한 후에 호스트 서버에서 다음과 같이 콘솔 접속을 해봅니다. 그러면 다음과 같이 나오면 성공 입니다.

Enter 를 여러번 쳐주면 나옵니다.