Category: HowTo

Grub2 에 기본 커널 지정하기

Grub2 은 리눅스 시스템의 부팅 메니져이다. 리눅스는 커널을 여러개를 설치하고 부팅시에 선택해서 원하는 커널로 부팅을 할 수 있도록 해준다. 비상 복구가 필요할 경우에도 부팅 메니져인 Grub2 에서 비상복구 모드를 선택하면 된다.

문제는 어떻게 기본 커널을 지정할 수 있을까?

먼저, 기본 부팅 커널은 다음과 같이 확인할 수 있다.

ZSH
1
2
]# cat /boot/grub2/grubenv | grep saved
saved_entry=CentOS Linux (5.0.2-1.el7.elrepo.x86_64) 7 (Core)

만일 부팅 상황이라면 위에 설정한 커널을 기본으로 부팅을 진행하게 된다. 만일 이 기본 커널을 변경하고자 할 경우에는 어떻게 할까?

우선, 현재 Grub2 에 등록된 커널 목록들을 알아야하는데 다음과 같이 하면 알 수 있다.

ZSH
1
2
3
4
5
]# awk -F\' /^menuentry/{print\$2} /etc/grub2-efi.cfg
CentOS Linux (5.0.8-1.el7.elrepo.x86_64) 7 (Core)
CentOS Linux (5.0.2-1.el7.elrepo.x86_64) 7 (Core)
CentOS Linux (4.20.11-1.el7.elrepo.x86_64) 7 (Core)
CentOS Linux (0-rescue-9ee89927656147d5ab3501cc9c85f579) 7 (Core)

커널 목록을 확인할 수 있는데, 맨 위쪽부터 0 을 시작으로 번호를 붙일 수 있다. 이러한 번호는 기본 부팅 커널을 바꾸는데 유용하게 사용된다. 이제 기본 부팅 커널을 다음과 같이 바꿀 수 있다.

ZSH
1
]# grub2-set-default 0

확인을 한번 해보면 다음과 같다.

ZSH
1
2
]# cat /boot/grub2/grubenv | grep saved
saved_entry=0

이렇게 한 후에 다시 Grub 을 설치해줘야 한다.

ZSH
1
]# grub2-mkconfig -o /etc/grub2-efi.cfg

정상적으로 되었다면 기본 부팅 커널이 바꾼 것이다.

systemctl tomcat no bind 8005 port

Tomcat 을 설치하고 난후에 systemd 에 유닛으로 등록하고 나고 서비스를 시작하고 shutdown 을 하려고 할때에 다음과 같은 오류를 만날 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
Feb 26 12:17:40 ubuntu18 systemd[1]: Stopping Apache Tomcat Web Application Container...
Feb 26 12:17:40 ubuntu18 shutdown.sh[2798]: Feb 26, 2019 12:17:40 PM org.apache.catalina.startup.Catalina stopServer
Feb 26 12:17:40 ubuntu18 shutdown.sh[2798]: SEVERE: Could not contact [localhost:8005] (base port [8005] and offset [0]). Tomcat may not be running.
Feb 26 12:17:40 ubuntu18 shutdown.sh[2798]: Feb 26, 2019 12:17:40 PM org.apache.catalina.startup.Catalina stopServer
Feb 26 12:17:40 ubuntu18 shutdown.sh[2798]: SEVERE: Error stopping Catalina
Feb 26 12:17:40 ubuntu18 shutdown.sh[2798]: java.net.ConnectException: Connection refused (Connection refused)
Feb 26 12:17:40 ubuntu18 shutdown.sh[2798]:         at java.net.PlainSocketImpl.socketConnect(Native Method)
Feb 26 12:17:40 ubuntu18 shutdown.sh[2798]:         at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
Feb 26 12:17:40 ubuntu18 shutdown.sh[2798]:         at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
Feb 26 12:17:40 ubuntu18 shutdown.sh[2798]:         at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
Feb 26 12:17:40 ubuntu18 shutdown.sh[2798]:         at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
Feb 26 12:17:40 ubuntu18 shutdown.sh[2798]:         at java.net.Socket.connect(Socket.java:589)

8005 포트로 접속을 할 수 없어서 셧다운시에 오류를 발생시키는 것이다. 왜 이런문제가 발생할까? systemd tomcat 유닛의 내용은 다음과 같다.

INI
1
2
3
4
5
6
7
8
9
10
11
12
13
14
[Service]
Type=forking
 
Environment="CATALINA_HOME=/opt/tomcat"
Environment="CATALINA_BASE=/home/systemv/was1"
 
ExecStart=/opt/tomcat/bin/catalina.sh start
ExecStop=/opt/tomcat/bin/catalina.sh stop
 
User=systemv
Group=systemv
UMask=0007
RestartSec=10
Restart=on-failure

그리고 이 상태로 다음과 같이 tomcat 을 서비스로 시작 한다.

ZSH
1
]# systemctl start tomcat.service

이렇게 하고 난후에 netstat 명령어로 포트 리스닝 상태를 살펴보면 8005 포트가 보이지 않는다. 더 큰 문제는 shutdown 포트가 올라오지 않으면 Tomcat 이 작동하지 않는데 있다.

해결 방법은 의외로 간단하다. 다음과 같이 systemd tomcat 유닛 파일에 WorkingDirectory 를 CATALINA_BASE 로 해주면 된다.

diff
1
2
3
4
5
6
7
[Service]
Type=forking
 
+ WorkingDirectory=/home/systemv/was1
 
Environment="CATALINA_HOME=/opt/tomcat"
Environment="CATALINA_BASE=/home/systemv/was1"

이렇게 하게되면 tomcat 이 shutdown 포트까지 올라오면서 정상적으로 다 구동되게 된다.

ps, 이걸 몰라 3시간을 해멧다.

Ubuntu APT Could not get lock /var/lib/dpkg/lock 문제

우분투(Ubuntu) 를 부팅하고 난 후에 로그인을 하면 몇개의 새로운 업데이트가 있는지를 알려준다. 그래서 새로운 패키지 설치를 위해서 ‘apt upgrade’ 명령을 하게 되면 다음과 같은 오류 메시지를 만나곤 한다.

ZSH
1
2
3
# apt upgrade
E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?

패키지를 설치하는 명령어인 dpkg 명령어가 이미 실행중인 것으로 인해서 실행이 안된다는 것이다. 실행을 할때에 lock 파일을 생성하게 되는데, 이를 근거로 혹시 다른 것이 이미 실행되고 있는건 아닌지 추측하고 있다.

도대체 무슨 일이 벌어지고 있는 걸까? 다른 것이 이미 실행중일지도 모르니까 다음과 같이 프로세스를 체크해 본다.

ZSH
1
2
3
4
# ps aux | grep apt
root      1350  0.0  0.0   4504   736 ?        Ss   20:05   0:00 /bin/sh /usr/lib/apt/apt.systemd.daily install
root      1355  0.0  0.0   4504  1684 ?        S    20:05   0:00 /bin/sh /usr/lib/apt/apt.systemd.daily lock_is_held install
root     12203  0.0  0.0  15504  1008 ttyS0    S+   20:06   0:00 grep --color=auto apt

보아하니 apt.systemd.daily 이것이 apt 명령어를 실행하고 그래서 dpkg 가 이미 실행되고 있는 것으로 보인다.

이것은 아마도 부팅과 동시에 패키지를 업데이트 해주는일을 하는 녀석인 것으로 보이는데, 자동으로 패키지를 업데이트를 해준다니 얼마나 고맙겠냐만은 때로는 어떤 것이 설치되는지를 직접 선택하거나 해야하는 경우에는 자동으로 알아서 해주는것이 큰 위험이 될 수도 있다.

이것을 멈추게 하는 방법이 있다.

ZSH
1
2
3
4
# systemctl disable apt-daily-upgrade.service
# systemctl disable apt-daily-upgrade.timer
# systemctl disable apt-daily.service
# systemctl disable apt-daily.timer

이렇게하면 부팅하면서 자동으로 apt 업데이트를 하는 건 막을 수 있다.

참고,

만일 부팅과장에서 각 서비스별 소비된 시간을 알고 싶다면 다음과 같이 확인해 볼 수 있다.

ZSH
1
2
# systemd-analyze
Startup finished in 2.903s (kernel) + 1min 56.476s (userspace) = 1min 59.379s

이렇게 보면 userspace 로 인한 시간이 1분이 넘어간다. 좀 더 자세하게 보기 위해서는 다음과 같이 확인해 볼수 있다.

ZSH
1
2
3
4
5
6
7
# systemd-analyze blame
    1min 13.990s apt-daily-upgrade.service
         34.654s apt-daily.service
          3.130s dev-sda1.device
          3.002s networking.service
          1.852s apparmor.service
          1.818s snmpd.service

Ubuntu18.04 호스트네임 영구 변경 설정

Ubuntu18.04 에서 호스트네임을 변경하기 위해서는 다음과 같이 해준다.

ZSH
1
]# hostnamectl set-hostname testserv1

이렇게 한 후에 리부팅을 하면 원래 변경전 호스트네임이 나온다. 이럴때 /etc/cloud/cloud.cfg 파일에서 다음과 같이 변경을 해주면 된다.

diff
1
2
- 15 preserve_hostname: false
+ 15 preserve_hostname: true

이렇게 바꾼후에 다음과 같이 로그인 서비스를 재시작 해준다.

ZSH
1
]# systemctl restart systemd-logind.service

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

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

/etc/default/grub 편집

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

INI
1
2
3
GRUB_CMDLINE_LINUX="console=tty1 console=ttyS0,115200"
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"

위와같이 편집을 한 후에 grub 을 다시 작성해준다.

ZSH
1
]# update-grub2

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

Bash 파일 존재 유무 체크하기

Bash 쉘 스크립트를 작성할때 자주 사용하는 로직인 바로 파일 존재 유무를 체크하는 것이다. 파일 하나만 체크할 수도 있고 여러파일을 체크할 수도 있다. 여러 파일을 체크할때는 다음과 같이 할 것이다.

ZSH
1
2
]$ ls *file.txt
ls: cannot access *file.txt: 그런 파일이나 디렉터리가 없습니다

이것을 Bash 쉘 스크립트에서는 어떻게 리턴을 받아야 하나하는 고민이 생긴다. 가장 쉬운 방법은 stdout, stderror 를 체크하는 방법이다.

Bash 에서 이를 exit code 라고 하고 $? 에 세팅이되어 다음과 같은 로직이 가능해진다.

ZSH
1
2
3
4
5
6
7
8
9
10
#!/bin/bash
 
ls *file.txt
 
if [ $? -eq 0 ]
then
  echo "file exist!!"
else
  echo "file doesn't exist!!" >&2
fi

명령어가 성공(stdout)하면 $?에 0, stderr 면 1 이다. 위를 실행하면 다음과 같다.

ZSH
1
2
3
]$ ./a.sh
ls: cannot access *file.txt: 그런 파일이나 디렉터리가 없습니다
file doesn't exist!!

위 방법외에도 한줄로 다음과 같이 할 수도 있다.

ZSH
1
(ls x.txt && echo yes) || echo no

AND 와 OR 연산자를 이용해서 메시지를 출력하도록 한다.

하지만 위 방법도 오류 메시지, 혹은 결과가 출력이 되는데 이를 방지하고 결과만 받고 싶다면 다음과 같이 할 수 있다.

ZSH
1
(ls x.txt >> /dev/null 2>&1 && echo yes) || echo no

이렇게 하면 결과 출력 없이 yes, no 만 출력이 된다.

출처: How to check if a file exists in a shell script

Database 를 위한 공유 메모리, HugePages 계산하기

Database 시스템은 공유메모리 혹은 HugePages 에 매우 의존적입니다. 서버에서 데이터베이스가 가동되면 Database 가 사용하는 메모리는 Database만을 위해서 사용되어 집니다. 대부분의 큰 Database 시스템은 다른 서버 프로그램 없이 단독으로 설치되어 운영되어지기 때문에 얼마만큼 물리적 메모리를 Database 에 할당할지가 Database 시스템 전체에 큰 영향을 미칩니다.

이 글에서 Database 시스템을 위한 공유메모리, HugePages 등을 할당할때에 고려사항은 무엇이며 얼마나 할당하는 것이 좋은지를 살펴보겠습니다.

Oracle 11g or 12c

먼저 Oracle 은 물리적 메모리에 약 80% 를 Oracle 이 사용하도록 할당하도록 합니다. 여기서 대략 80% 라고 했는데, 만일 몇가지 프로그램을 함께 돌린다면 약 75% 가 적당합니다.

물리 메모리의 약 80% 할당

여기서 고려해야할 사항이 하나 있습니다. 80%를 할당하라고 해서 무조건 80%를 할당하게 되면 문제가 됩니다. 예를들어 16GB 의 물리 메모리로 운영하는 경우에 80%면 12.8GB 이고 서버에서 사용가능한 용량은 3.2GB 입니다. 요새 데스크탑 컴퓨터도 안되도 4GB 는 사용하는데 아무리 가벼운(?) 리눅스 서버라도 3.2GB 는 운영하는데 너무 적어 보입니다.

이럴때는 운영체제에서 사용할 최소 메모리를 남겨두고 나머지를 Oracle 에 할당하는게 현명하다고 할 수 있습니다.

또하나 중요하게 고려해야할 사항은 Oracle 에서 AMM을 쓰느냐 안쓰느냐 하는 문제 입니다. 이 둘의 차이는 다음과 같습니다.

AMM 을 사용할 경우: /dev/shm 장치를 이용한 공유메모리 모델 사용. HugePages 사용 불가

AMM을 사용하지 않을 경우: System V 공유 메모리 모델 사용. HugePages 사용 가능

 

Oracle 11g 버전으로 넘어오면서 전에 없던 기능이 하나 생겼는데, 그것은 바로 AMM(Aotomactic Memory Management) 입니다. AMM은 Oracle의 메모리 모델인 SGA와 PGA 를 통틀어서 메모리 관리를 자동으로 해준다는 개념입니다.

AMM 기능을 이용하면 대략적으로 SGA 영역은 Oracle 할당받은 메모리 영역에서 85%, PGA 는 약 15%로 나눠서 관리한다고 합니다.

또 한가지 AMM의 특징이 있는데, 공유메모리 모델중에서 /dev/shm 장치를 이용한 Posix 규격의 공유메모리 모델을 사용한다고 합니다. 이 메모리 모델은 메모리 가상 장치를 통해서 프로세스가 공유할 내용을 파일로 저장해서 공유하는 방법으로 오로지 용량에만 제약사항이 있습니다. 공유할 내용을 파일로 생성할때에 얼마만한 크기로 생성할지는 전적으로 서버 프로그램, 여기서는 Oracle, 에 의해서 결정됩니다. 최근의 모든 리눅스 서버는 /dev/shm 이 자동으로 마운트되어 있으며 기본적으로 전체 물리메모리의 50%를 사용합니다.

용량을 바꾸기 위해서는 다음과 같이 해줍니다. CentOS 6과 CentOS 7 배포판 별로 차이가 조금 있습니다.

/dev/shm 공유 메모리 크기 변경
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
## CentOS 6
umount /dev/shm
mount -t tmpfs shmfs -o size=4g /dev/shm
## /etc/fstab
- tmpfs                   /dev/shm                tmpfs   defaults        0 0
+ tmpfs                   /dev/shm                tmpfs   defaults,size=12G        0 0
 
## Apply changes of /dev/shm
mount -o remount /dev/shm
 
## CentOS 7
## /etc/fstab
+ shmfs                   /dev/shm                tmpfs   defaults,size=12G        0 0
 
## Apply changes of /dev/shm
mount -o remount /dev/shm

 

만일 AMM을 사용하지 않을 경우에는 SystemV 의 공유메모리 설정을 따르게 됩니다. 이때에 HugePages 도 함께 사용할 수 있습니다. 이 설정들은 커널 파라메터로 조정하며 그 설정 변수는 다음과 같습니다.

shmmax: 단일 프로세스가 공유메모리를 호출하기 위한 최대 값. 단위 Bytes

shmall: 시스템을 통틀어 사용가능한 공유 메모리 Page 량. 단위 Page

nr_hugepages: Huge 페이지 개수.

 

여기서 중요한 것이 만일 HugePages 를 사용한다면 shmall 은 사용되지 않습니다. shmall 은 리눅스 메모리의 기본단위인 4096bytes(4k) 를 기반으로 계산되어 지는데, HugPages 는 이보다 더 큰 2048k(2MB) 를 기반으로 페이지를 나누기 때문입니다.

어찌됐든 이런 모든 상황을 고려해서 사용가능한 메모리를 구한다면 다음과 같은 공식으로 구할 수 있습니다.

Oracle 를 위한 shmall, shmmax, nr_hugepages 크기 구하기
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
#!/bin/sh
#
#
 
if [ -z $1 ]; then
        echo "Usage: shm_setup.sh size(MB)"
        exit 1
fi
 
DB_MEMORY=$(($1+500))
PAGE=$(getconf PAGESIZE)
HUGEPAGE=$(cat /proc/meminfo |grep -i Hugepagesize|awk '{print $2}')
 
echo "Actually For DB memory has about 100MB bigger than $1
Totally DB's Memory is $DB_MEMORY MB"
 
if [ $DB_MEMORY -le '500' ]; then
        echo "DB's Memory should be greater than 500MB"
        exit 1
else
        echo "PAGESIZE: $PAGE"
        echo "HugePage Size: $HUGEPAGE"
        echo ""
        echo "kernel.shmmax = $(($DB_MEMORY*1024*1024))"
        echo "kernel.shmall = $((($DB_MEMORY*1024*1024)/$PAGE))"
        echo "vm.nr_hugepages = $(($DB_MEMORY/($HUGEPAGE/1024)))"
        echo "@oinstall soft memlock = unlimited"
        #echo "@oinstall soft memlock = $(($DB_MEMORY*1024))"
        echo "@oinstall hard memlock = unlimited"
        #echo "@oinstall hard memlock = $(($DB_MEMORY*1024))"
fi

보시면 아시겠지만 다른분이 만들어놓은 것으로 최소 500MB 용량을 넘는 것으로해서 shmmax, shmall, hugepages 를 모두 계산하고 있습니다.

MySQL 5.x

MySQL 의 경우에, InnoDB 엔진만을 사용한다는 전제하에, 전체 메모리의 80%를 MySQL이 할당해서 사용하도록 설정합니다.

물리 메모리의 약 80%를 MySQL에 할당(InnoDB만 사용)

MySQL 은 오로지 SystemV 의 공유메모리 모델을 따릅니다. 따라서 HugePages 를 사용할 수 있는데, 이를 위해서는 다음과 같이 my.cnf 에 설정을 해줘야 합니다.

MySQL 의 HugePage 사용설정
INI
1
2
[mysqld]
large-pages

그리고 shmmax,shmall,nr_hugepages 는 앞에 스크립트를 이용해서 구합니다.

Linux 설정

SystemV 공유 메모리 모델의 경우에 몇가지를 더 해줘야 합니다.

첫째로 Transparent Huge Pages (THP) 설정을 꺼야 합니다. 성능저하가 발생한다고 하네요. 다음과 같이 간단히 처리 할 수 있습니다.

Transparent Huge Pages (THP) 비활성화
ZSH
1
2
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

매번 부팅시마다 자동으로 설정하고 싶다면 부팅 파라메터를 수정해 줍니다.

Ubuntu 의 경우에는 다음과 같이 해줍니다.

Transparent Huge Pages (THP) 비활성화를 위한 grub 설정
diff
1
2
3
4
# vim /etc/default/grub
- GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"
+ GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0 transparent_hugepage=never"
# update-grub2

CentOS 의 경우에는 다음과 같이 해줍니다.

Transparent Huge Pages (THP) 비활성화를 위한 grub 설정
diff
1
2
3
4
# vim /etc/default/grub
- GRUB_CMDLINE_LINUX="crashkernel=auto rhgb quiet"
+ GRUB_CMDLINE_LINUX="crashkernel=auto rhgb quiet transparent_hugepage=never"
# update-grub2

확인도 가능한데, 다음과 같이 AnonHugePages 값이 0Kb 명 THP 가 비활성화 된 것입니다.

1
2
]# grep Huge /proc/meminfo
AnonHugePages:     0

마지막으로 커널이 HugePage 를 사용할 그룹이 누군지를 지정해 줍니다.

HugePage 그룹 지정
INI
1
vm.hugetlb_shm_group = `id -g mysql`

위와같이 리눅스 시스템 사용자의 그룹ID 를 알아내도록 명령어를 입력할 수도 있고 아니면 그냥 그룹ID를 찾아서 적어줘도 됩니다.

Telegraf 설치 및 설정

Telegraf 는 서버내의 각종 지표들을 수집하는 에이전트(Agent) 프로그램 입니다. 서버 자체뿐만 아니라 각종 서버소프트웨어들에 지표도 함께 수집할 수 있으며 InfluxDB, OpenTSDB, Kafka 등과 같은 데이터소스(Datasource)에 저장하도록 할 수 있습니다.

환경

설치 및 설정 환경은 다음과 같습니다.

  • CentOS x86_64

설치

설치는 Telegraf 홈페이지에서 관련 파일을 다운로드 받으면 됩니다. Telegraf 는 배포판별로 패키지를 제공하기 때문에 편하게 설치를 할 수 있습니다.

다운로드 및 설치.
ZSH
1
2
wget https://dl.influxdata.com/telegraf/releases/telegraf-1.3.1-1.x86_64.rpm
yum localinstall telegraf-1.3.1-1.x86_64.rpm

 

설정

설정은 /etc/telegraf/telegraf.conf 파일에서 해주시면 되며, 주요 설정은 다음과 같습니다.

telegraf.conf
INI
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
[agent]
  ## Specify the log file name. The empty string means to log to stderr.
  logfile = "/var/log/telegraf/telegraf.log"
 
  ## Override default hostname, if empty use os.Hostname()
  hostname = "systemv"
 
[[outputs.influxdb]]
  # urls = ["udp://localhost:8089"] # UDP endpoint example
  urls = ["http://localhost:8086"] # required
  ## The target database for metrics (telegraf will create it if not exists).
  database = "systemv" # required
 
  username = "systemv"
  password = "패스워드"
 
[[inputs.cpu]]
  percpu = true
  totalcpu = true
  collect_cpu_time = false
 
[[inputs.disk]]
  mount_points = ["/"]
  ignore_fs = ["tmpfs", "devtmpfs"]
 
[[inputs.diskio]]
  devices = ["sda"]
 
[[inputs.kernel]]
 
[[inputs.mem]]
 
[[inputs.processes]]
 
[[inputs.swap]]
 
[[inputs.system]]
 
[[inputs.net]]
interfaces = ["eth0"]
 
[[inputs.netstat]]

위 설정만으로도 주요한 Linux 시스템의 지표들을 수집할 수 있습니다. 설정을 다 했다면 다음과 같이 시작해 줍니다.

telegraf 서비스 시작
ZSH
1
service telegraf start

 

InfluxDB 설치 및 설정

InfluxDB 는 Time Series Database 로 각광을 받는 데이터베이스 시스템입니다. SQL 로 데이터 조회가 가능하며 Retention 설정(보유기간을 설정) 할 수 있는 특징이 있습니다.

환경

설치 환경은 다음과 같습니다.

  • CentOS x86_64

설치

다음의 페이지에서 다운로드를 받을 수 있습니다.

InfluxDB 는 각 배포판별로 패키지를 제공 합니다. 패키지를 이용하면 손쉽게 설치할 수 있고 init script 등록도 자동으로 되기 때문에 패키지 설치를 권장 합니다.

InfluxDB 설치
ZSH
1
2
wget https://dl.influxdata.com/influxdb/releases/influxdb-1.2.4.x86_64.rpm
yum localinstall influxdb-1.2.4.x86_64.rpm

설치가 끝나면 다음과 같은 파일들을 확인할 수 있습니다.

주요 InfluxDB 파일들.
1
2
/etc/influxdb/influxdb.conf  # 설정 파일
/etc/rc.d/init.d/influxdb # init Script 파일

설정

대부분의 설정은 /etc/influxdb/influxdb.conf 파일에서 이루어 집니다.  주요한 설정은 다음과 같습니다.

주요 InfluxDB.conf 파일
INI
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
# Meta 데이터 저장할 위치 지정.
[meta]
  # Where the metadata/raft database is stored
  dir = "/var/lib/influxdb/meta"
 
# 실제 데이터를 저장할 디렉토릴 지정.
[data]
  # The directory where the TSM storage engine stores TSM files.
  dir = "/var/lib/influxdb/data"
 
  # The directory where the TSM storage engine stores WAL files.
  wal-dir = "/var/lib/influxdb/wal"
 
# Clustering 서비스 설정 통제
[coordinator]
  write-timeout = "10s"  # write request 가 기다릴시간. 이 시간이 지나면 에러 리턴
  max-concurrent-queries = 0  # 최대 동시 쿼리 개수. 0 은 unlimited.
  query-timeout = "0"  # 시스템이 kill 하기전에 쿼리 수행허용 시간
  log-queries-after = "0s" # slow 쿼리를 기록할 한계시간. 0 은 slow 쿼리 로깅을 하지 않음.
  max-select-point = 0
  max-select-series = 0
  max-select-buckets = 0
 
# 데이터 보관기간 설정.
[retention]
  enabled = true # 설정 사용함.
  check-interval = "30m" # 보관기간 정책 체크할 인터발 시간. 30분에 한번씩 보관기간 정책 체크.
 
# 모니터링 데이터를 위한 내부 데이터베이스 생성 설정.
[monitor]
  store-enabled = true # 내부 데이터베이스 생성 활성화.
  store-database = "_internal" # 저정할 데이터베이스 이름
  store-interval = "10s" # 10마다 통계치를 저장.
 
# Web 기반 관리자 페이지 설정
[admin]
  enabled = true
  bind-address = ":8083"
  https-enabled = false
  https-certificate = "/etc/ssl/influxdb.pem"
 
# HTTP 엔드포인트 설정. 이것은 InfluxDB 에서 데이터를 넣고 빼는데 핵심이 되는 매커니즘이다.
[http]
  enabled = true
  bind-address = ":8086"
  auth-enabled = true
  log-enabled = true
  write-tracing = false
  pprof-enabled = false # 트러블슈팅이나 모니터링에 사용함.
  https-enabled = false
  https-certificate = "/etc/ssl/influxdb.pem"
  ### Use a separate private key location.
  # https-private-key = ""
  max-row-limit = 10000
  realm = "InfluxDB"
 
# 사용하지 않음.
[[graphite]]
  enabled = false
 
# 사용하지 않음.
[[collectd]]
  enabled = false
 
# 사용하지 않음.
[[opentsdb]]
  enabled = false
 
# 사용하지 않음.
[[udp]]
  enabled = false
 
# 지속적인 쿼리. 이 기능은 아주 유용한데, 일단 활성화를 해둔다.
[continuous_queries]
  enabled = true
  log-enabled = true
  run-interval = "5s"

대략 위와같이 설정한 후에 InfluxDB 를 시작해 줍니다.

influxdb 시작
1
2
3
[root@localhost influxdb]# service influxdb start
Starting influxdb...
influxdb process was started [ OK ]

 

Database 설정

앞에서의 설정은 InfluxDB 시스템에 대한 설정이라면 이번 Database 설정은 Time Series 데이터를 위한 접근 제어, 데이터베이스 생성등에 관한 것입니다.

먼저, 전체 Database 에 최고 관리자를 생성해야 합니다. 최고 관리자는 모든 데이터베이스에 대해서 READ, WRITE 권한을 가집니다.

influxdb 관리자 생성
ZSH
1
2
3
4
5
[root@localhost influxdb]# influx
Connected to http://localhost:8086 version 1.2.4
InfluxDB shell version: 1.2.4
> CREATE USER Admin WITH PASSWORD '패스워드' WITH ALL PRIVILEGES
>

Ctl+D 를 누르고 나온후에 이번에는 관리자 권한을 얻기 위해서 인증 로그인을 합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
[root@localhost influxdb]# influx
Connected to http://localhost:8086 version 1.2.4
InfluxDB shell version: 1.2.4
> AUTH
username: Admin
password:
> USE _internal
Using database _internal
> SHOW USERS
user  admin
----  -----
Admin true
 
>

위와같이 관리자 인증을 통해서 내부 데이터베이스인 _internal 에 접근이 가능하며, 현재 인증된 사용자가 어떤 권한을 가지고 있는지도 살펴볼수 있습니다.

데이터베이스 및 일반 사용자 생성

이제 데이터 수집을 위한 데이터베이스와 이 데이터베이스에 접근하기 위한 일반 사용자 생성을 해보겠습니다.

데이터베이스 및 일반 사용자 생성
ZSH
1
2
3
4
5
6
7
[root@orion203 influxdb]# influx
Connected to http://localhost:8086 version 1.2.4
InfluxDB shell version: 1.2.4
> CREATE DATABASE systemv
> CREATE USER voyager WITH PASSWORD '패스워드'
> GRANT ALL ON systemv TO voyager
>

먼저 데이터베이스 systemv 를 생성하고 일반 사용자인 voyager 도 생성합니다. 그리고 systemv 데이터베이스에 voyager 사용자에게 모든 권한을 부여 합니다. 이렇게 되면 voyager 사용자는 systemv 데이터베이스에만 접근이 가능한 일반 사용자가 됩니다.

이제 외부 수집서버에서 InfluxDB 로 접근할때에 일반사용자인 voyager 로 인증하고 systemv 데이터베이스에 데이터를 저장할 수 있습니다.