반응형
작성일: 2024년 8월 14일

 

 

CPU 온도 모니터링

$ apt install lm-sensors

$ sensors-detect --auto

$ systemctl restart module-init-tools

$ watch sensors

 

 

프로세스 별 Network traffic 모니터링

$ apt install nethogs

$ nethogs eth0

$ apt install iftop

$ iftop -i eth0

 

 

 

 

 

 

 

 

 


 

반응형
작성일: 2024년 8월 14일

 

SSD, HDD 등 저장 장치에 대해서 Read, Write 성능을 측정하기 위해서는 dd 같은 명령어를 사용하면 성능 수치까지 나오지만

실제로 File copy를 하면서 실사용 환경과 같이 Read, Write 성능을 측정해보고 싶다면 아래 shell script를 활용해보는 것을 추천한다.

 

#!/bin/bash

fallocate -l 1G sample-big.file

CNT=0
while true; do
        CUR_DATE=`date +%4Y-%m-%d-%H-%M-%S`
        CNT=$(( ${CNT}+1 ))
        echo ""
        echo ""
        echo "============= TEST START ================"
        echo "Test time:  ${CUR_DATE}"
        echo "Test count: $CNT"
        START_TIME=`date +%s%N`
        cp sample-big.file sample-big-1.file
        sync
        END_TIME=`date +%s%N`
        INTERVAL_TIME_NANO=$(( ${END_TIME}-${START_TIME} ))
        INTERVAL_TIME_NANO_COMMA=$(numfmt --grouping ${INTERVAL_TIME_NANO})
        INTERVAL_TIME_MILI=$(( ${INTERVAL_TIME_NANO}/1000000 ))
        INTERVAL_TIME_MILI_COMMA=$(numfmt --grouping ${INTERVAL_TIME_MILI})
        echo "Total execution time: ${INTERVAL_TIME_NANO_COMMA} (nanosec)   ${INTERVAL_TIME_MILI_COMMA} (milisec)"
        BPS=$(( 1073741824*1000000/${INTERVAL_TIME_NANO} ))
        BPS_COMMA=$(numfmt --grouping ${BPS})
	echo "IO BPS: ${BPS_COMMA} (KBytes / Sec)"
        rm sample-big-1.file
        sync
        echo "============= TEST END =================="
        echo ""
        echo ""
        sleep 2
done

 

만약, Read, Write 부하를 더 많이 주고 싶다면 `fallocate` 명령으로 더 큰 사이즈의 file을 테스트하도록 하면 된다.
(위 코드에서 1G를 10G 또는 100G로 수정하면 됨)

 

위 스크립트를 실행하면, 아래와 같이 테스트가 되면서 출력물이 나온다.

 

$ my-run.sh

============= TEST START ================
Test time:  2024-08-14-10-58-10
Test count: 1
Total execution time: 1,400,259,865 (nanosec)   1,400 (milisec)
IO BPS: 766,816 (KBytes / Sec)
============= TEST END ==================




============= TEST START ================
Test time:  2024-08-14-10-58-14
Test count: 2
Total execution time: 758,501,406 (nanosec)   758 (milisec)
IO BPS: 1,415,609 (KBytes / Sec)
============= TEST END ==================

... 중간 생략 ...

 

 

여담:
내가 일하고 있는 연구소에서 사용중인 Ubuntu 18.04 장비 중에서 Linux 4.15.0-143-generic 커널 버전을 사용하는 모델만
SSD I/O와 HDD I/O 성능이 100분의 1 수준으로 떨어지는 증상이 있었다.
이를 쉽게 재현하기 위해서 위와 같은 Script를 만들었다.
위 IO 과부하 테스트를 해본 결과, 아래와 같은 Linux kernel version 들이 모두 IO 성능이 급격하게 떨어지는 현상이 있다.

4.15.0-136-generic   -> 정상
4.15.0-137-generic   -> SSD HDD IO 성능 저하 이슈 발생
4.15.0-138-generic   -> SSD HDD IO 성능 저하 이슈 발생
4.15.0-139-generic   -> SSD HDD IO 성능 저하 이슈 발생
4.15.0-140-generic   -> SSD HDD IO 성능 저하 이슈 발생
4.15.0-141-generic   -> SSD HDD IO 성능 저하 이슈 발생
4.15.0-142-generic   -> SSD HDD IO 성능 저하 이슈 발생
4.15.0-143-generic   -> SSD HDD IO 성능 저하 이슈 발생
4.15.0-144-generic   -> 정상

 

 


 

반응형
작성일: 2024년 8월 13일

 

 

특정 버전의 Linux Kernel 설치하기

apt 명령으로 아래와 같은 특정 kernel version을 설치한다.

예를 들어, linux kernel version 4.15.0-137 을 설치한다면, 아래 예제 명령과 같이 실행한다.

$ apt-get install linux-image-4.15.0-137-generic \
                  linux-headers-4.15.0-137-generic \
                  linux-modules-4.15.0-137-generic \
                  linux-modules-extra-4.15.0-137-generic

 

 

GRUB 설정하기

새로운 Linux kernel version이 설치되었다고 해서, 새로 설치한 Kernel version으로 부팅되는 것이 아니다.

GRUB 설정을 수정해야 내가 원하는 linux kernel version으로 부팅된다.

아래 예제 GRUB 파일과 같이 수정하면 된다.

$ vi /etc/default/grub

... 중간 생략 ...

## 방금 새로 설치한 linux kernel version에 대한 이름을 설정한다.
GRUB_DEFAULT='Advanced options for Ubuntu>Ubuntu, with Linux 4.15.0-137-generic'

## 아래와 같이 설정하면, 3초 동안 countdown하는 화면이 나온다.
## countdown하는 동안에 'ESC or F4 or SHIFT' 키를 누르면 GRUB 부팅 설정이 나온다.
## 이때 Default kernel version이 아닌 다른 kernel version을 고를 수 있다.
GRUB_TIMEOUT_STYLE=countdown
GRUB_TIMEOUT=3

... 중간 생략 ...

 

 

grub 설정 파일을 저장하고, 아래와 같이 update-grub 명령을 수행한다.

$ update-grub

Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.15.0-213-generic
Found initrd image: /boot/initrd.img-4.15.0-213-generic
Found linux image: /boot/vmlinuz-4.15.0-143-generic
Found initrd image: /boot/initrd.img-4.15.0-143-generic
Found linux image: /boot/vmlinuz-4.15.0-142-generic
Found initrd image: /boot/initrd.img-4.15.0-142-generic
Found linux image: /boot/vmlinuz-4.15.0-137-generic
Found initrd image: /boot/initrd.img-4.15.0-137-generic
done

$

 

 

Linux OS를 reboot

아래와 같이 reboot 명령을 수행하고, 부팅 초기에 "countdown" 화면이 나오면

[ESC] 또는 [SHIFT] 또는 [F4] 키를 눌러서 원하는 Linux kernel version을 선택한다.

$ reboot

 

 

GNU GRUB 화면 (Linux kernel version 선택)

 

GNU GRUB 화면 (Linux kernel version 선택)

 

 

 

Linux kernel version의 적용 여부 확인

아래와 같이 `uname -sr` 명령으로 새로 설치한 linux kernel version으로 부팅되었는지 확인한다.

$ uname -sr
Linux 4.15.0-137-generic
$

 

 

 

 


 

반응형
작성일: 2024년 8월 10일

 

차박 여행을 한지 1년 5개월이 지났다.

차박 용품 중에서 제일 중요한 아이템은 "매트"가 아닐까 생각한다.

비록 차에서 잠을 자더라도 잘 자야 다음 날 여행이 즐겁다.

 

1년 전에 구입해서 사용했던 차박용 자충매트는 사용해보니 몇 가지 불편함이 있었다.

  • 자충 매트가 너무 컸다. 매트가 길어서 트렁크를 닫을 때 간섭이 있었다. 그래서 트렁크 문을 닫을 때마다 조심스러웠다.
  • 매트가 크니까 접을 때 불편했다.
  • 자충매트가 부풀 때는 빠르게 잘 부풀었는데, 반대로 접을 때는 엄청난 힘을 줘야 바람이 빠졌다.
  • 매트 접는 것이 쉽지 않다보니 그냥 대충 둘둘 말아서 방 구석에 세워놓게 된다. (공간을 많이 차지함)
  • 꿀잠을 자겠다고 두꺼운 자충 매트를 샀더니, 아무리 잘 접어도 부피가 크다.

 

위와 같은 불편함을 겪고 나서 좀더 나에게 잘 맞는 매트를 구입하고 싶었다.

그래서 구입한 것인 "네이터하이크 자동 충전 에어매트(Naturehike Automatic Inflatable Sleeping Pad)"라는 자충 매트이다.

Naturehike 홈페이지를 보니 등산 캠핑 용품을 판매하는 브랜드처럼 보인다.

(즉, 자동차 차박 용품 브랜드는 아니다)

 

일단, 차박 용품이 아니니까 차박에 어울릴까 걱정하면서 구입했다.

걱정은 했지만, 구입 후 만족하고 있다.

어떤 점이 좋았냐면,

  • 접었을 때 작고 가볍다. 그리고 보관, 운반이 쉽다.
  • 에어 패드(에어 매트) 스스로 잘 부풀어 오른다. (어느 정도 자동으로 부풀면 마지막에 약간 바람을 불어넣어주면 끝)
  • 접기가 정말 편하다. 작은 힘으로 둘둘 말면, 잘 말린다.

 

https://youtu.be/ygA4SjrkOpA?si=YBebqpHog4noXj0y

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

에어 매트 사이즈: 185(길이) x 55(폭) x 3.5(두께)    단위: cm

 

 

 

 

 

 

 


 

반응형
작성일: 4월 15일

 

 

Kubernetes를 사용하면서 만나는 문제 상황

Kubernetes service resource를 삭제하고 다시 생성하면, Public IP(또는 EXTERNAL-IP) 값이 변경된다.

AWS, Oracle Cloud, Azure, GCP(Google Cloud Platform) 같은 Public Cloud Infra에서 제공하는 

Reserved Public IP 기능과 Service YAML에 'externalIPs' 값을 설정하면 Public IP Address를 고정시킬 수 있지만,

Helm Chart를 작성하거나 Kubernetes Service Manifest 파일을 작성할 때마다 

  1. Reserved Public IP 생성 요청
  2. 위에서 생성된 Public IP 값을 확인 후 Service Manifest 작성(또는 Helm chart) 작성

한다는 것은 참 불편한 작업이다.

 

 

그래서 아래의 기능을 수행하는 Python script를 만들었다.

 

  1. my-conf.yaml 파일에서 Public IP address 정보를 갱신할 'Kubernetes service' 정보와 'Internet domain name' 목록을 설정
  2. DNS 서버에서 Kubernetes API server에게 Service resource의 public IP address를 조회 요청
  3. 이렇게 얻은 public IP address(즉, EXTERNAL-IP)를 자동으로 DNS 서버의 Zone file에 반영
  4. BIND9 서비스 데몬을 재기동

 

아래 예제 설정과 Python 소스 코드를 이용하면 잘 동작함 ^^

 

설정 파일 작성  [ 파일명: my-conf.yaml ]

 

$ cat my-conf.yaml

zone_file: /var/cache/bind/my-domain.kr.zone
json_file: /var/cache/bind/my-domain.kr.json

domain_name: my-domain.kr

services:
  - kube_svc_name: almighty
    host_name: almighty
  - kube_svc_name: myhappyserver
    host_name: myhappynacserver
  - kube_svc_name: my-ingress-nginx-controller
    host_name: myproxyserver

 

 

 

BIND9 Zone File 생성을 위한 Jinja2 Template 파일 작성  [ 파일명: zone.j2 ]

 

$ cat zone.j2

; ------------------------------------------------------------------------------------------
; NOTE:
;   이 파일은 대한민국 서울에 사는 Andrew Jeong이 만든 "DNS Auto Configuration Application"이
;   자동으로 생성한 파일입니다.
;   사용자가 이 파일을 직접 편집해도 일정 시간 이후에 Application에 의해서 재작성될 것입니다.
;   따라서 이 Zone file을 직접 편집하는 것을 금합니다.
;   만약, Zone file에 반영할 내용이 있다면 같은 폴더에 있는 JSON 파일을 수정해야 합니다.
; ------------------------------------------------------------------------------------------

; Internet Domain Zone :  {{ origin }}
; Exported date        :  {{ now }}

$ORIGIN {{ origin }}
$TTL {{ ttl }}

;
; SOA Record
;
@    IN    SOA    {{ soa['mname'] }}    {{ soa['rname'] }} (
    {{ soa['serial'] }} 	; serial
    {{ soa['refresh'] }} 	; refresh
    {{ soa['retry'] }} 	; retry
    {{ soa['expire'] }} 	; expire
    {{ soa['minimum'] }} 	; minimum ttl
)


{% if ns is defined -%}
;
; NS Records
;
{% for entry in ns -%}
@   IN  NS  {{ entry['host'] }}
{% endfor %}
{% endif %}


{%- if mx is defined -%}
;
; MX Records
;
{% for entry in mx -%}
@	IN	MX	{{ entry['preference'] }}    {{ entry['host'] }}
{% endfor %}
{% endif %}


{%- if spf is defined -%}

; SPF Records
{% for entry in spf -%}
{{ entry['domain'] }}		IN	TXT	"{{ entry['record'] }}"
{% endfor %}
{% endif %}


{%- if a is defined -%}
;
; A Records
;
{% for entry in a -%}
	{{ "{:<17}".format(entry['name']) }}  IN  A      {{ entry['ip'] }}
{% endfor %}
{% endif %}


{%- if aaaa is defined -%}

; AAAA Records
{%- for entry in aaaa -%}
{{ entry['name'] }}		IN	AAAA	{{ entry['ip'] }}
{% endfor %}
{% endif %}


{%- if cname is defined -%}
;
; CNAME Records
;
{% for entry in cname -%}
	{{ "{:<17}".format(entry['name']) }}  IN  CNAME  {{ entry['alias'] }}
{% endfor %}
{% endif %}


{%- if ptr is defined -%}
;
; PTR Records
;
{% for entry in ptr -%}
{{ entry['name'] }}		IN	PTR	"{{ entry['host'] }}"
{% endfor %}
{% endif %}


{%- if txt is defined -%}
;
; TXT Records
;
{% for entry in txt -%}
{{ entry['name'] }}		IN	TXT	"{{ entry['txt'] }}"
{% endfor %}
{% endif %}


{%- if srv is defined -%}
;
; SRV Records
;
{% for entry in srv -%}
{{ entry['name'] }}		IN	SRV	{{ entry['priority'] }}   {{ entry['weight'] }} {{ entry['port'] }}   {{ entry['target'] }}
{% endfor %}
{%- endif %}

; End of Zone

 

 

 

BIND9 Zone File 생성을 위한 JSON 파일 작성  [ 파일명: /var/cache/bind/my-domain.kr.json ]

$ cat /var/cache/bind/my-domain.kr.json

{
    "origin": "my-domain.kr.",
    "ttl": 600,
    "soa": {
        "mname": "ns.my-domain.kr.",
        "rname": "sejong.my-domain.kr.",
        "serial": "2024041500",
        "refresh": 3600,
        "retry": 600,
        "expire": 604800,
        "minimum": 86400
    },
    "ns": [
        {
            "host": "ns.my-domain.kr."
        },
        {
            "host": "ns1.my-domain.kr."
        }
    ],
    "a": [
        {
            "name": "@",
            "ip": "16.6.80.3"
        },
        {
            "name": "ns",
            "ip": "16.6.80.3"
        },
        {
            "name": "ns1",
            "ip": "13.2.88.15"
        },
        {
            "name": "myhappyserver",
            "ip": "13.93.28.9"
        },
        {
            "name": "my-ingress-nginx-controller",
            "ip": "10.1.7.6"
        },
        
        ... 중간 생략 ...
        
        {
            "name": "almighty",
            "ip": "129.154.195.186"
        }
    ],
    "cname": [
        {
            "name": "my-nicname-server",
            "alias": "almighty"
        },
        {
            "name": "toy",
            "alias": "my-ingress-nginx-controller"
        },
        
        ... 중간 생략 ...
        
        {
            "name": "my-supersvc",
            "alias": "mail.sogang.ac.kr"
        }
    ]
}

 

 

로그 파일 생성을 위한 Python Script 작성  [ 파일명: my_log.py ]

$ cat my_log.py

#!/usr/bin/python3

import logging
import logging.handlers
import os
import datetime
import threading
import time


class MyLog():
    def __init__(self, dir, logname) -> None:
        self.logname = logname
        self.dir = os.path.join(dir,logname)
        self.InitLogger()

    def InitLogger(self):
        ## Log format 설정하기
        formatter = logging.Formatter("[%(asctime)s] %(levelname)s %(filename)s:%(lineno)d - %(message)s")
        if os.path.exists(self.dir) == False :
            os.makedirs(self.dir)

        log_File = os.path.join(self.dir,  self.logname + ".log")
        timedfilehandler = logging.handlers.TimedRotatingFileHandler(filename=log_File, when='midnight', interval=1, encoding='utf-8')
        timedfilehandler.setFormatter(formatter)
        timedfilehandler.suffix = "%Y%m%d.log"

        self.logger = logging.getLogger(self.logname)
        self.logger.addHandler(timedfilehandler)
        self.logger.setLevel(logging.INFO)

        self.delete_old_log(self.dir, 3)

        now = datetime.datetime.now()
        self.toDay = "%04d-%02d-%02d" % (now.year, now.month, now.day)
        self.th_auto_delete = threading.Thread(target=self.auto_delete, daemon=True)
        self.th_auto_delete.start()

    '''
    함수 인자 설명:
      - fpath:삭제할 파일이 있는 디렉토리,
      - age:경과일수
    '''
    def delete_old_log(self, fpath, age):
        for fp in os.listdir(fpath):
            fp = os.path.join(fpath, fp)
            if os.path.isfile(fp):
                timestamp_now = datetime.datetime.now().timestamp()
                if os.stat(fp).st_mtime < timestamp_now - (age * 24 * 60 * 60):
                    try:
                        os.remove(fp)
                    except OSError:
                        print(fp, 'this log file is not deleted')

    def auto_delete(self):
        while True:
            now = datetime.datetime.now()
            day = "%04d-%02d-%02d" % (now.year, now.month, now.day)
            if self.toDay != day:
                self.toDay = day
                self.delete_old_log(self.dir, 3)
            time.sleep(600)


## This is test code.
if __name__ == '__main__':
    log = MyLog("my_log_test_dir", logname="sejong")
    for idx in range(3):
        log.logger.info(f"로그 메시지가 잘 기록되는지 테스트 중 {idx}")

 

 

Kubernetes External-IP를 조회 및 DNS 자동 설정을 위한 Python Script 작성 [  파일명: kube-dns-auto-config.py ]

 

#!/usr/bin/python3

import os
import time
import socket
import shutil
import subprocess
import yaml
import json
import datetime
#from datetime import datetime
from kubernetes import client, config
from jinja2 import Environment, FileSystemLoader

import my_log


###############################################################
## NOTE: You have to fix the following variable 'my_run_dir'
###############################################################
my_run_dir = "/opt/kube-dns-auto-config/"


def search_host_from_json_data(host_name):
    for item in json_data['a']:
        if item['name'] == host_name:
            return item
    return None


def chk_ip_addr_changed(conf_svc_item):
    kube_svc_name = conf_svc_item["kube_svc_name"]
    host_name = conf_svc_item["host_name"]

    log.logger.info(f"\n")
    log.logger.info(f"[ Checking configuration '{kube_svc_name}' / '{host_name}' ]")

    for item in kube_svc_info.items:
        if item.metadata.name == kube_svc_name:
            ip_addr_k8s_svc = item.status.load_balancer.ingress[0].ip
            log.logger.info(f"  {kube_svc_name:<11} from K8S SVC EXT-IP : {ip_addr_k8s_svc:>15}")

            dns_record = search_host_from_json_data(host_name)
            if dns_record == None:
                log.logger.info("  host_name {host_name} is not found.")
                return 0
            log.logger.info(f"  {host_name:<11} from JSON file      : {dns_record['ip']:>15}")
            if ip_addr_k8s_svc == dns_record['ip']:
                log.logger.info("  IP address of domain name is not changed. Nothing to do.")
                return 0
            else:
                log.logger.info(f"  IP address of domain name is changed;   {dns_record['ip']} -> {ip_addr_k8s_svc}")
                dns_record['ip'] = ip_addr_k8s_svc
                return 1
    return 0



def get_new_serial(old_serial):
    curr_date = datetime.datetime.today().strftime("%Y%m%d")
    bool_today = old_serial.startswith(curr_date)
    if bool_today is True:
        ## Serial 값이 오늘 한번이라도 Update된 경우
        int_old_serial = int(old_serial)
        new_serial = str(int_old_serial + 1)
    else:
        ## Serial 값이 처음 Update되는 경우
        new_serial = f"{curr_date}00"

    log.logger.info(f"old_serial: [{old_serial}]")
    log.logger.info(f"new_serial: [{new_serial}]")

    return new_serial


def make_bkup_file(serial):
    zone_file = my_conf_info['zone_file']
    bkup_zone_file = f"{zone_file}_{serial}"
    shutil.copy(zone_file, bkup_zone_file)

    bkup_json_file = f"{json_file}_{serial}"
    shutil.copy(json_file, bkup_json_file)

    return None


def make_zone_file():
    ## Jinja2 environment object and refer to templates directory
    env = Environment(loader=FileSystemLoader(my_run_dir))
    template = env.get_template('zone.j2')

    template.globals['now'] = datetime.datetime.now().isoformat()
    rendered_data = template.render(json_data)

    log.logger.info(f"rendered_data: \n{rendered_data}")

    fp = open(my_conf_info['zone_file'], "w")
    fp.write(rendered_data)
    fp.close()

    return None


## ------------------------------------------------------------------------
##     Begin of Main
## ------------------------------------------------------------------------

if __name__ == '__main__':
    log = my_log.MyLog("log_kube_dns", logname="kb_log")
    log.logger.info("#####  Start program  #####")

    ## Load configration from YAML file.
    conf_path = my_run_dir + "my-conf.yaml"
    with open(conf_path) as fp:
        my_conf_info = yaml.load(fp, Loader = yaml.FullLoader)

    json_file = my_conf_info['json_file']

    ## Configs can be set in Configuration class directly or using helper utility
    config.load_kube_config()
    v1 = client.CoreV1Api()

    ##
    ## !!! Main service logic !!!
    ##
    while True:
        svc_ip_changed = 0

        with open(json_file) as json_fp:
            json_data = json.load(json_fp)

        kube_svc_info = v1.list_service_for_all_namespaces(watch=False)
        for conf_svc_item in my_conf_info['services']:
            svc_ip_changed += chk_ip_addr_changed(conf_svc_item)

        if svc_ip_changed > 0:
            log.logger.info(f"IP address is changed")
            log.logger.info(f"json_data: \n\n{json_data}\n")

            new_serial = get_new_serial(json_data['soa']['serial'])
            json_data['soa']['serial'] = new_serial

            ## BKUP file 만들기
            make_bkup_file(new_serial)

            ## JSON 파일에 변경된 내용을 Update한다.
            json_str = json.dumps(json_data, indent=4)
            with open(json_file, "w") as json_outfile:
                json_outfile.write(json_str)

            ## JSON Data를 Zone DB 포맷으로 변환하여 Zone file에 저장
            make_zone_file()

            ## Restart BIND9 service
            ret_value = subprocess.call("systemctl restart bind9", shell=True)
            log.logger.info(f"\n\n")
            log.logger.info(f"[ BIND9 is restarted ] 'systemctl' return: {ret_value}\n\n")
        time.sleep(60)

    ## ------------------------------------------------------------------------
    ##     End of Main
    ## ------------------------------------------------------------------------

 

 

 

실행하기 (테스트하기)

$ /opt/kube-dns-auto-config/kube-dns-auto-config.py

 

 

위와 같이 Python script를 실행하고, 로그 파일을 열람한다.

$ tail -f /opt/kube-dns-auto-config/log_kube_dns/kb_log/kb_log.log

 

 

 

 

 

주의 사항

위 Python script를 실행하는 DNS 서버 장비에 $KUBE_CONFIG 파일이 존재해야 한다.

예를 들어, /home/sejong/.kube/config 같은 파일이 있어야 이 Python 프로그램이 Kubernetes API server에 접근이 가능하다.

 

 

 


 

 

##
## 채용 관련 글
##
제가 일하고 있는 기업 부설연구소에서 저와 같이 연구/개발할 동료를 찾고 있습니다.
(이곳은 개인 블로그라서 기업 이름은 기재하지 않겠습니다. E-mail로 문의주시면 자세한 정보를 공유하겠습니다.)

근무지 위치:
  서울시 서초구 서초동, 3호선 남부터미널역 근처 (전철역 출구에서 회사 입구까지 도보로 328m)
필요한 지식 (아래 내용 중에서 70% 정도를 미리 알고 있다면 빠르게 협업할 수 있음):
  - 운영체제 (학부 3~4학년 때, 컴퓨터공학 운영체제 과목에서 배운 지식 수준):
    예를 들어, Processor, Process 생성(Fork)/종료, Memory, 동시성, 병렬처리, OS kernel driver  
  - Linux OS에서 IPC 구현이 가능
    예를 들어, MSGQ, SHM, Named PIPE 등 활용하여 Process간 Comm.하는 기능 구현이 가능하면 됨. 
  - Algorithm(C언어, C++ 언어로 구현 가능해야 함)
    예를 들어, Hashtable, B-Tree, Qsort 정도를 C 또는 C++로 구현할 수 있을 정도 
  - Network 패킷 처리 지식(Layer 2 ~ 4, Layer 7)
    예를 들어, DHCP Server/Client의 주요 Feature를 구현할 정도의 능력이 있으면 됨.
  - Netfilter, eBPF 등 (IP packet hooking, ethernet packet 처리, UDP/TCP packet 처리)
  - IETF RFC 문서를 잘 읽고 이해하는 능력 ^^
  # 위에 열거한 내용 외에도 제가 여기 블로그에 적은 내용들이 대부분 업무하면서 관련이 있는 주제를 기록한 것이라서
  # 이 블로그에 있는 내용들을 잘 알고 있다면, 저희 연구소에 와서 연구/개발 업무를 수행함에 있어서 어려움이 없을 겁니다.
회사에서 사용하는 프로그래밍 언어:
  - 프로그래밍 언어: C, C++, Go
    (참고: 아직 연구소 동료들이 Rust를 사용하진 않습니다만, 새 언어로써 Rust를 사용하는 것을 고려하는 중)
근무 시간:
  - 출근: 8~10시 사이에서 자유롭게 선택
  - 퇴근: 8시간 근무 후 퇴근 (오후 5시 ~ 7시 사이)
  - 야근 여부: 거의 없음 (내 경우, 올해 상반기 6개월간 7시 이후에 퇴근한 경우가 2회 있었음)
  - 회식 여부: 자유 (1년에 2회 정도 회식하는데, 본인이 집에 가고 싶으면 회식에 안 감. 왜 참석 안 하는지 묻지도 않음)
외근 여부:
  - 신규 프로젝트 멤버 -> 외근 전혀 하지 않음 (나는 신규 프로젝트만 참여해서 지난 1년 동안 한번도 외근 없었음)
  - 상용 프로젝트 멤버 -> 1년에 5회 미만 정도로 외근
팀 워크샵 여부:
  - 팀 워크샵 자체를 진행하지 않음. (워크샵 참석하는 거 싫어하는 개발자 환영 ^^)
연락처:
  - "sejong.jeonjo@gmail.com"  # 궁금한 점은 이 연락처로 문의주세요.
  - 블로그 비밀 댓글 (제가 하루에 한번씩 댓글 확인하고 있음)
원하는 인재상:
  - 우리 부설연구소는 "긴 호흡으로 프로젝트를 진행"하기 때문에 최소 2년간 한 가지 주제를 꾸준하게 연구/개발할 수 있는 개발자를 원함.
  - 우리 부설연구소는 자주적으로 연구 주제를 찾아서 업무를 하기 때문에 능동적으로 생각하고 행동하는 동료를 원함.
  - 차분하게 연구 주제에 몰입하고, 해법을 찾는 것을 즐기는 사람.
내가 느끼는 우리 연구소의 장점:
  - 갑/을 관계가 없음. (제가 근무하고 있는 연구소는 SI업종이 아니라서 갑/을 회사 개념이 없음)
  - 연구소 자체적으로 연구 주제를 발굴하고 시스템을 개발하기 때문에 개발 일정에 대한 스트레스가 적음
  - 빌딩 전체를 우리 회사가 사용하므로 분위기가 산만하지 않음.
  - 근처에 예술의전당, 우면산 둘레길이 있어서 점심 시간에 산책하기 좋음 ^^
  - 연구소 동료들 매너가 Good (2년간 일하면서 한번도 감정에 스크레치 생기거나 얼굴 붉히며 싸운 적 없음 ^^)

 

 

반응형

 


작성한 날: 2024년 8월 7일
테스트했던 Pi 모델: Pi 4, Pi 5

 

터미널을 열어서 아래 명령(CLI)를 입력한다.

$ sudo  apt install -y fonts-unfonts-core

 

 

Raspbian Desktop 시작 메뉴에서 [ Raspberry Pi Configuration ] 창을 연다.

메뉴를 찾아가는 순서는 아래와 같다.

  [ 시작 메뉴 ]  ->  [ 기본 설정 ]  ->  [ Raspberry Pi Configuration ]  ->  [ Localisation ]

 

[ Locale ] 설정 항목에서 아래와 같이 설정한다.

 - Language : ko (Korean)

 - Character Set : UTF-8

 

[ Raspberry Pi Configuration ] 창을 닫는다.

 

아래와 같이 명령을 실행하여 한글 패키지를 설치한다.

 

$ sudo  apt install -y fcitx fcitx-hangul
... 출력 화면 생략 ...


$ vim  /etc/default/im-config
... 중간 생략 ...
IM_CONFIG_DEFAULT_MODE=fcitx     # <-- "auto" 값을 "fcitx" 값으로 수정 
... 중간 생략 ...


$ reboot

 

 

 

Raspberry Pi를 Reboot하고 나면, [한/영] 전환하는 키 조합을 설정한다. 메뉴를 찾아가는 순서는 아래와 같다.

 [ 시작 메뉴 ]  ->  [ 기본 설정 ]  ->  [ Fcitx 구성 ]  ->  [ 전역 설정 ] 탭 

 

[ 전역 설정 ] 탭에서 [ 트리거 입력기 ]를 설정한다.

나는 [ Shift + Space ] 키 조합과 [ Right Alt ] 키를 설정했다.  (아래아한글 프로그램의 한영 전환 키처럼 설정)

 

 


 

 

 

##
## 채용 관련 글
##
제가 일하고 있는 기업 부설연구소에서 저와 같이 연구/개발할 동료를 찾고 있습니다.
(이곳은 개인 블로그라서 기업 이름은 기재하지 않겠습니다. E-mail로 문의주시면 자세한 정보를 공유하겠습니다.)

근무지 위치:
  서울시 서초구 서초동, 3호선 남부터미널역 근처 (전철역 출구에서 회사 입구까지 도보로 328m)
필요한 지식 (아래 내용 중에서 70% 정도를 미리 알고 있다면 빠르게 협업할 수 있음):
  - 운영체제 (학부 3~4학년 때, 컴퓨터공학 운영체제 과목에서 배운 지식 수준):
    예를 들어, Processor, Process 생성(Fork)/종료, Memory, 동시성, 병렬처리, OS kernel driver  
  - Linux OS에서 IPC 구현이 가능
    예를 들어, MSGQ, SHM, Named PIPE 등 활용하여 Process간 Comm.하는 기능 구현이 가능하면 됨. 
  - Algorithm(C언어, C++ 언어로 구현 가능해야 함)
    예를 들어, Hashtable, B-Tree, Qsort 정도를 C 또는 C++로 구현할 수 있을 정도 
  - Network 패킷 처리 지식(Layer 2 ~ 4, Layer 7)
    예를 들어, DHCP Server/Client의 주요 Feature를 구현할 정도의 능력이 있으면 됨.
  - Netfilter, eBPF 등 (IP packet hooking, ethernet packet 처리, UDP/TCP packet 처리)
  - IETF RFC 문서를 잘 읽고 이해하는 능력 ^^
  # 위에 열거한 내용 외에도 제가 여기 블로그에 적은 내용들이 대부분 업무하면서 관련이 있는 주제를 기록한 것이라서
  # 이 블로그에 있는 내용들을 잘 알고 있다면, 저희 연구소에 와서 연구/개발 업무를 수행함에 있어서 어려움이 없을 겁니다.
회사에서 사용하는 프로그래밍 언어:
  - 프로그래밍 언어: C, C++, Go
    (참고: 아직 연구소 동료들이 Rust를 사용하진 않습니다만, 새 언어로써 Rust를 사용하는 것을 고려하는 중)
근무 시간:
  - 출근: 8~10시 사이에서 자유롭게 선택
  - 퇴근: 8시간 근무 후 퇴근 (오후 5시 ~ 7시 사이)
  - 야근 여부: 거의 없음 (내 경우, 올해 상반기 6개월간 7시 이후에 퇴근한 경우가 2회 있었음)
  - 회식 여부: 자유 (1년에 2회 정도 회식하는데, 본인이 집에 가고 싶으면 회식에 안 감. 왜 참석 안 하는지 묻지도 않음)
외근 여부:
  - 신규 프로젝트 멤버 -> 외근 전혀 하지 않음 (나는 신규 프로젝트만 참여해서 지난 1년 동안 한번도 외근 없었음)
  - 상용 프로젝트 멤버 -> 1년에 5회 미만 정도로 외근
팀 워크샵 여부:
  - 팀 워크샵 자체를 진행하지 않음. (워크샵 참석하는 거 싫어하는 개발자 환영 ^^)
연락처:
  - "sejong.jeonjo@gmail.com"  # 궁금한 점은 이 연락처로 문의주세요.
  - 블로그 비밀 댓글 (제가 하루에 한번씩 댓글 확인하고 있음)
원하는 인재상:
  - 우리 부설연구소는 "긴 호흡으로 프로젝트를 진행"하기 때문에 최소 2년간 한 가지 주제를 꾸준하게 연구/개발할 수 있는 개발자를 원함.
  - 우리 부설연구소는 자주적으로 연구 주제를 찾아서 업무를 하기 때문에 능동적으로 생각하고 행동하는 동료를 원함.
  - 차분하게 연구 주제에 몰입하고, 해법을 찾는 것을 즐기는 사람.
내가 느끼는 우리 연구소의 장점:
  - 갑/을 관계가 없음. (제가 근무하고 있는 연구소는 SI업종이 아니라서 갑/을 회사 개념이 없음)
  - 연구소 자체적으로 연구 주제를 발굴하고 시스템을 개발하기 때문에 개발 일정에 대한 스트레스가 적음
  - 빌딩 전체를 우리 회사가 사용하므로 분위기가 산만하지 않음.
  - 근처에 예술의전당, 우면산 둘레길이 있어서 점심 시간에 산책하기 좋음 ^^
  - 연구소 동료들 매너가 Good (2년간 일하면서 한번도 감정에 스크레치 생기거나 얼굴 붉히며 싸운 적 없음 ^^)

 

반응형

 


 

 

Rook를 이용하여 Ceph 설치한 날짜: 2024년 8월 7일
Rook version: 1.10.10
Ceph version: 17.2.5(quincy) and 15.2.17 (octopus)      ## 이 두 버전 모두 잘 동작했다.

 

지난 2년 동안 NFS server를 이용하여 Kubernetes PV(Persistent Volume)의 Storage로 사용했었는데, 별로 좋지 않음을 경험하고는 Ceph를 사용해야겠다는 결단이 생겼다.

Ceph 설치가 만만치 않은 작업이지 않을까 걱정했는데, 괜한 걱정이었다.

Rook operator official document의 설명을 따라서 설치하니까 30분 만에 Ceph cluster가 뚝딱하고 만들어졌다.

Test용 Example App까지 Rook operator에 포함되어 있어서 Test까지 다 포함해서 1시간이 채 안 걸렸다.

 

일단, 아래 공식 문서인 Rook Ceph document를 읽고 따라하면 일사천리로 설치와 테스트가 모두 끝난다.

 

 

Quickstart - Rook Ceph Documentation

Quickstart Welcome to Rook! We hope you have a great experience installing the Rook cloud-native storage orchestrator platform to enable highly available, durable Ceph storage in your Kubernetes cluster. If you have any questions along the way, please don'

rook.io

 

 


그럼... 설치를 시작해보자 !

 

설명은 위 공식 문서에 있으니까, 설정을 생략하고 명령만 적어 놓겠다. 

그냥 아래 명령어를 따라 수행하면 된다. 

 

Ceph 설치 전에 준비할 내용:
  Kubernetes worker node에 Ceph가 Storage로 사용할 Raw device가 있어야 한다.
  (즉, 한번도 사용하지 않은 깨끗한 SSD, HDD 같은 것이 필요하다. Format이 안 되어 있어서 Filesystem도 없는 상태면 딱 좋다.)
  나는 깡통 qcow2 이미지를 각 worker node의 Virtual disk로 사용했다.
  그리고 Ceph는 3-node cluster로 구성할 것이니까, worker node 3개에 각각 Raw device가 1개씩 있어야 한다.

모든 worker node에 Raw device를 추가 장착했다면, 아래와 같이 `lsblk -f` 명령을 수행하여 깡통 상태의 Storage가 있는지 확인한다.

아래 명령 결과에서 vdb가 아무도 사용하지 않는, 그리고 formatting도 하지 않은 완전한 깡통 상태의 Storage 이다.

$  lsblk -f

NAME                  FSTYPE      LABEL UUID                                   MOUNTPOINT
vda
└─vda1                LVM2_member       >eSO50t-GkUV-YKTH-WsGq-hNJY-eKNf-3i07IB
  ├─ubuntu--vg-root   ext4              c2366f76-6e21-4f10-a8f3-6776212e2fe4   /
  └─ubuntu--vg-swap_1 swap              9492a3dc-ad75-47cd-9596-678e8cf17ff9   [SWAP]

vdb    ## <- 이 "vdb" 저장 장치와 같이 아무 설정도 없는 상태의 Storage가 있어야 한다.

$

모든 workder node에서 위 명령으로 vdb storage 정보를 확인했다면, 이제 본격적으로 설치 작업을 한다.

 

 

아래 명령은 kubernetes bastion node 또는 kubectl 수행이 가능한 PC에서 수행한다.
########################################################################
## GitHub에서 Rook operator를 내려 받는다.
########################################################################
$  git clone --single-branch --branch v1.10.10 https://github.com/rook/rook.git

$  cd rook/deploy/examples


########################################################################
## Rook operator 운영에 필요한 custom resource definition을 생성하고
## Rook operator 리소스를 kubernetes cluster에 배포한다.
########################################################################
$  kubectl create -f crds.yaml -f common.yaml -f operator.yaml

########################################################################
## 참고:
##   내가 테스트할 때, 위 명령으로 ceph operator를 구동하고, 바로 아래의 cluster를
##   구축하려고 하니까 OSD orchestration 단계에서 실패했다.
##   정확한 원인은 모르겠는데, operator 구동 시작 후 20초 정도 기다렸다가 cluster 구축
##   하는 명령을 수행하면 오류없이 잘 cluster가 구축되었다.
########################################################################

########################################################################
## rook-ceph-operator pod가 running 상태인지 확인한다.
########################################################################
$  kubectl -n rook-ceph get pod


########################################################################
## Ceph cluster를 생성한다.
########################################################################
$  kubectl create -f cluster.yaml

########################################################################
## 주의:
##   내가 사용한 CPU는 "Intel(R) Xeon(R) E-2124G CPU @ 3.40GHz" 인데,
##   이 CPU를 사용했을 때 Ceph cluster 구성이 완료되려면 대략 3분 정도 시간이 걸렸다.
##   따라서, 아래와 같이 rook-ceph-operator 로그를 보면서 진행 과정을 보는 것이 좋다.
##   대략 3분 정도 로그가 올라가다가 마지막 부분에 "op-osd: finished .... "
##   이런 문구가 출력되면 작업이 끝난 것이다.
########################################################################
$  kubectl -n rook-ceph logs -l app=rook-ceph-operator -f

... 중간 생략 ...

2023-01-06 07:05:19.680387 I | cephclient: successfully disallowed pre-quincy osds and enabled all new quincy-only functionality
2023-01-06 07:05:19.681868 I | op-osd: finished running OSDs in namespace "rook-ceph"
2023-01-06 07:05:19.682577 I | ceph-cluster-controller: done reconciling ceph cluster in namespace "rook-ceph"

<< 위 문장이 출력되면, 끝난 것이다. Ctrl+C 키를 눌러서 kubectl log 명령을 종료시킨다 >>

########################################################################
## 만약 3분이 지났는데 'done reconciling ceph cluster ..." 로그가 출력되지 않는다면
## cluster, operator, crds를 모두 삭제하고 다시 시작해야 한다.
##  (예: kubectl delete -f cluster.yaml -f operator.yaml -f ...)
########################################################################

########################################################################
## Ceph 관련 pod가 running 상태인지 확인한다.
########################################################################
$  kubectl -n rook-ceph get pod
NAME                                                 READY   STATUS      RESTARTS   AGE
csi-cephfsplugin-provisioner-d77bb49c6-n5tgs         5/5     Running     0          140s
csi-cephfsplugin-provisioner-d77bb49c6-v9rvn         5/5     Running     0          140s
csi-cephfsplugin-rthrp                               3/3     Running     0          140s
csi-rbdplugin-hbsm7                                  3/3     Running     0          140s
csi-rbdplugin-provisioner-5b5cd64fd-nvk6c            6/6     Running     0          140s
csi-rbdplugin-provisioner-5b5cd64fd-q7bxl            6/6     Running     0          140s
rook-ceph-crashcollector-minikube-5b57b7c5d4-hfldl   1/1     Running     0          105s
rook-ceph-mgr-a-64cd7cdf54-j8b5p                     1/1     Running     0          77s
rook-ceph-mon-a-694bb7987d-fp9w7                     1/1     Running     0          105s
rook-ceph-mon-b-856fdd5cb9-5h2qk                     1/1     Running     0          94s
rook-ceph-mon-c-57545897fc-j576h                     1/1     Running     0          85s
rook-ceph-operator-85f5b946bd-s8grz                  1/1     Running     0          92m
rook-ceph-osd-0-6bb747b6c5-lnvb6                     1/1     Running     0          23s
rook-ceph-osd-1-7f67f9646d-44p7v                     1/1     Running     0          24s
rook-ceph-osd-2-6cd4b776ff-v4d68                     1/1     Running     0          25s
rook-ceph-osd-prepare-node1-vx2rz                    0/2     Completed   0          60s
rook-ceph-osd-prepare-node2-ab3fd                    0/2     Completed   0          60s
rook-ceph-osd-prepare-node3-w4xyz                    0/2     Completed   0          60s


########################################################################
## Rook toolbox를 이용하여 Ceph cluster 상태 정보를 조회한다.
##   toolbox에 대한 자세한 설명은 아래 Web document를 확인
##     https://rook.io/docs/rook/v1.10/Troubleshooting/ceph-toolbox/
########################################################################

########################################################################
## Rook toolbox를 설치한다.
########################################################################
$  kubectl create -f deploy/examples/toolbox.yaml


########################################################################
## Rook toolbox pod 내부에서 `ceph status` 명령을 수행하여 ceph cluster 상태를 조회한다.
########################################################################
$  kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- bash
  
bash-4.4$ ceph status
  cluster:
    id:     661d89a0-d4c5-432b-97d7-6a4d06beaf52
    health: HEALTH_OK

  services:
    mon: 3 daemons, quorum a,b,d (age 10m)
    mgr: b(active, since 11m), standbys: a
    osd: 3 osds: 3 up (since 10m), 3 in (since 11m)

  data:
    pools:   1 pools, 1 pgs
    objects: 2 objects, 449 KiB
    usage:   62 MiB used, 750 GiB / 750 GiB avail
    pgs:     1 active+clean

bash-4.4$
bash-4.4$
bash-4.4$
bash-4.4$ ceph df
--- RAW STORAGE ---
CLASS     SIZE    AVAIL    USED  RAW USED  %RAW USED
hdd    750 GiB  750 GiB  62 MiB    62 MiB          0
TOTAL  750 GiB  750 GiB  62 MiB    62 MiB          0

--- POOLS ---
POOL  ID  PGS   STORED  OBJECTS     USED  %USED  MAX AVAIL
.mgr   1    1  449 KiB        2  1.3 MiB      0    237 GiB

bash-4.4$ exit

$

 

 

예제 App을 이용하여 Ceph 동작 유무를 확인한다.

 

 

###############################################################################
## `git clone`한 소스 코드에 examples 디렉토리가 있다.
## examples 디렉토리로 이동하여 예제 App을 구동해보자.
## 당연히, 위 Ceph에서 PV를 할당받는 예제이다.
###############################################################################
$  cd /deploy/examples

###############################################################################
## 예제 App이 사용할 StorageClass를 생성한다.
###############################################################################
$  kubectl apply -f csi/rbd/storageclass.yaml
cephblockpool.ceph.rook.io/replicapool created
storageclass.storage.k8s.io/rook-ceph-block created

$  kubectl create -f mysql.yaml
service/wordpress-mysql created
persistentvolumeclaim/mysql-pv-claim created
deployment.apps/wordpress-mysql created

$  kubectl get pvc
NAME             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
mysql-pv-claim   Bound    pvc-6d458ff1-54bf-4f34-b010-a0f4b2a0966e   20Gi       RWO            rook-ceph-block   94s

$  kubectl create -f wordpress.yaml
service/wordpress created
persistentvolumeclaim/wp-pv-claim created
deployment.apps/wordpress created

$  kubectl get pod
NAME                               READY   STATUS    RESTARTS   AGE
wordpress-7cf5c5c8b-5cgqk          1/1     Running   0          42s
wordpress-mysql-6f99c59595-9vs7z   1/1     Running   0          4m8s

$  kubectl get svc  wordpress
NAME              TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
wordpress         LoadBalancer   10.96.232.248   10.1.4.160    80:31494/TCP   27s

 

참고로, wordpress pod가 구동되고 1분 정도 경과된 후에 Web browser로 접속하는 것이 좋다.
(wordpress가 MySQL DB에  초기 설정값을 만드느라 시간을 좀 쓰는 듯...)

 

Web browser를 이용하여 EXTERNAL-IP에 출력된 주소로 접속해보자.

아래처럼 Wordpress 설정 화면이 출력되면, 정상 동작하는 것이다.

 

 

 

Ceph를 설치하고, Storage를 할당 받아서 PV(Persistent Volume)을 사용하는 것까지 완벽하게 동작한다.

 

 


 

Ceph Dashboard

아래의 Web Docs를 보고 따라 설정하면 된다.

 

1) Prometheus를 먼저 설치한다.

 

Prometheus Monitoring - Rook Ceph Documentation

Prometheus Monitoring Each Rook Ceph cluster has some built in metrics collectors/exporters for monitoring with Prometheus. If you do not have Prometheus running, follow the steps below to enable monitoring of Rook. If your cluster already contains a Prome

rook.io

2) Dashboard를 설치한다.

 

Ceph Dashboard - Rook Ceph Documentation

Ceph Dashboard The dashboard is a very helpful tool to give you an overview of the status of your Ceph cluster, including overall health, status of the mon quorum, status of the mgr, osd, and other Ceph daemons, view pools and PG status, show logs for the

rook.io

 

위 설명을 따라하면, 아래와 같이 Web UI, Dashboard를 볼 수 있다.

Ceph Dashboard / Cluster 상태 정보 조회

 

Ceph Dashboard / OSD 정보 조회

 

Ceph Dashboard / Pool list 조회


 

참고: Ceph 관련하여 읽으면 도움이 되는 문서

SKT TACO(Openstack) 개발자가 직접 Ceph를 설치하면서 작성한 블로그. 

 

K8S 클러스터의 영구저장소로 ceph 사용하기

 

devocean.sk.com

 

 

SKT Kubernetes solution(TKS) 개발자 "엄주관" 님이 직접 Rook를 이용하여 Ceph 및 예제 앱을 설치하면서 작성한 블로그.  

 

Kubernetes 스토리지 오퍼레이터 Rook 맛보기

 

devocean.sk.com

 

 


 

 

 

 

##
## 채용 관련 글
##
제가 일하고 있는 기업 부설연구소에서 저와 같이 연구/개발할 동료를 찾고 있습니다.
(이곳은 개인 블로그라서 기업 이름은 기재하지 않겠습니다. E-mail로 문의주시면 자세한 정보를 공유하겠습니다.)

근무지 위치:
  서울시 서초구 서초동, 3호선 남부터미널역 근처 (전철역 출구에서 회사 입구까지 도보로 328m)
필요한 지식 (아래 내용 중에서 70% 정도를 미리 알고 있다면 빠르게 협업할 수 있음):
  - 운영체제 (학부 3~4학년 때, 컴퓨터공학 운영체제 과목에서 배운 지식 수준):
    예를 들어, Processor, Process 생성(Fork)/종료, Memory, 동시성, 병렬처리, OS kernel driver  
  - Linux OS에서 IPC 구현이 가능
    예를 들어, MSGQ, SHM, Named PIPE 등 활용하여 Process간 Comm.하는 기능 구현이 가능하면 됨. 
  - Algorithm(C언어, C++ 언어로 구현 가능해야 함)
    예를 들어, Hashtable, B-Tree, Qsort 정도를 C 또는 C++로 구현할 수 있을 정도 
  - Network 패킷 처리 지식(Layer 2 ~ 4, Layer 7)
    예를 들어, DHCP Server/Client의 주요 Feature를 구현할 정도의 능력이 있으면 됨.
  - Netfilter, eBPF 등 (IP packet hooking, ethernet packet 처리, UDP/TCP packet 처리)
  - IETF RFC 문서를 잘 읽고 이해하는 능력 ^^
  # 위에 열거한 내용 외에도 제가 여기 블로그에 적은 내용들이 대부분 업무하면서 관련이 있는 주제를 기록한 것이라서
  # 이 블로그에 있는 내용들을 잘 알고 있다면, 저희 연구소에 와서 연구/개발 업무를 수행함에 있어서 어려움이 없을 겁니다.
회사에서 사용하는 프로그래밍 언어:
  - 프로그래밍 언어: C, C++, Go
    (참고: 아직 연구소 동료들이 Rust를 사용하진 않습니다만, 새 언어로써 Rust를 사용하는 것을 고려하는 중)
근무 시간:
  - 출근: 8~10시 사이에서 자유롭게 선택
  - 퇴근: 8시간 근무 후 퇴근 (오후 5시 ~ 7시 사이)
  - 야근 여부: 거의 없음 (내 경우, 올해 상반기 6개월간 7시 이후에 퇴근한 경우가 2회 있었음)
  - 회식 여부: 자유 (1년에 2회 정도 회식하는데, 본인이 집에 가고 싶으면 회식에 안 감. 왜 참석 안 하는지 묻지도 않음)
외근 여부:
  - 신규 프로젝트 멤버 -> 외근 전혀 하지 않음 (나는 신규 프로젝트만 참여해서 지난 1년 동안 한번도 외근 없었음)
  - 상용 프로젝트 멤버 -> 1년에 5회 미만 정도로 외근
팀 워크샵 여부:
  - 팀 워크샵 자체를 진행하지 않음. (워크샵 참석하는 거 싫어하는 개발자 환영 ^^)
연락처:
  - "sejong.jeonjo@gmail.com"  # 궁금한 점은 이 연락처로 문의주세요.
  - 블로그 비밀 댓글 (제가 하루에 한번씩 댓글 확인하고 있음)
원하는 인재상:
  - 우리 부설연구소는 "긴 호흡으로 프로젝트를 진행"하기 때문에 최소 2년간 한 가지 주제를 꾸준하게 연구/개발할 수 있는 개발자를 원함.
  - 우리 부설연구소는 자주적으로 연구 주제를 찾아서 업무를 하기 때문에 능동적으로 생각하고 행동하는 동료를 원함.
  - 차분하게 연구 주제에 몰입하고, 해법을 찾는 것을 즐기는 사람.
내가 느끼는 우리 연구소의 장점:
  - 갑/을 관계가 없음. (제가 근무하고 있는 연구소는 SI업종이 아니라서 갑/을 회사 개념이 없음)
  - 연구소 자체적으로 연구 주제를 발굴하고 시스템을 개발하기 때문에 개발 일정에 대한 스트레스가 적음
  - 빌딩 전체를 우리 회사가 사용하므로 분위기가 산만하지 않음.
  - 근처에 예술의전당, 우면산 둘레길이 있어서 점심 시간에 산책하기 좋음 ^^
  - 연구소 동료들 매너가 Good (2년간 일하면서 한번도 감정에 스크레치 생기거나 얼굴 붉히며 싸운 적 없음 ^^)
반응형

 



virsh, virt-install 명령 테스트한 날짜: 2023년 8월 7일

 

KVM을 사용하다보면, Virt-Manager라는 GUI 툴이 조작하기 편해서 계속 Virt-Manager만 사용하게 된다.

그런데 가끔 SSH 터미널만 사용할 수 있는 환경이거나 CLI Command만 이용해서 Script를 작성할 때는 virsh를 꼭 사용해야 한다.

 

Virtual Machine 생성하기 (그리고 VM에 OS 설치하기)

##
##  2023년 1월에 실제 Ubuntu 설치할 때 사용했던 명령.
##   참고: --disk 옵션에 기존에 사용했던 qcow image file을 사용하면 kernel을 못 찾는다는 에러 발생.
##        원인은 아직 모르겠음.
##   참고: 아래 명령을 수행하고 대략 55초 정도 지나야 Console에 text message가 출력된다.
##        (내가 사용한 HW Spec: i7-11700, 64GB)
##        따라서 느긋하게 기다려야 제대로 설치가 가능하다.
##

## 참고: size 단위는 GB.

## Case: OS 설치하면서 VM instance 시작하기
##       (주의: OS 설치하면서 VM start 할 때는 --osinfo 옵션을 빼야 한다.)

$ virt-install \
  --name my-vm \
  --ram 4096 \
  --vcpus 2 \
  --disk /mnt/sda1/virtual_storage/waas.qcow2,size=100 \
  --disk /mnt/hdd0/virtual_machine/harbor-2nd-storage.qcow2,size=500 \
  --graphics none \
  --network network=br-ex \
  --console pty,target.type=virtio \
  --autoconsole text \
  --location /home/iso/ubuntu-22.04.1-live-server-amd64.iso
 


## Case: 기존 사용했던 VM 이미지를 이용하여 VM instance 기동하기.

$ virt-install \
  --import \               ## 기존 VM image 파일을 이용하겠다는 옵션
  --osinfo ubuntu22.04 \   ## 이 osinfo 옵션을 꼭 추가해야 한다.
  --name my-vm \
  --ram 4096 \
  --vcpus 2 \
  --disk /mnt/sda1/virtual_storage/waas.qcow2,size=100 \
  --graphics none \
  --network network=br-ex \
  --console pty,target.type=virtio \
  --autoconsole text

  
  
##
## CPU Pinning, Hugepages 설정이 필요해서 사용했던 명령.
##

$ virt-install --import \
  --name my-machine \
  --vcpus 4 \
## CPU Pinning  
  --cpuset=2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32 \
  --memory=4096 \
## Hugepages  
  --memorybacking hugepages=on \
  --numatune 0 \
  --disk /mydir/my-machine.qcow2 \
  --network bridge=my-br \
  --network bridge=ems-br \
  --os-variant rhel7.9 \
  --noautoconsole
  
  
  ##
  ## 주의:
  ##  아래 --osinfo, --os-variant 옵션을 사용하면 VM instance 생성할 때 오류가 발생한다.
  ##  꼭 필요한 옵션이 아니니까, 아래 2가지 옵션을 사용하지 않는 것이 좋다. (2023년 1월 현재)
  ##    --osinfo ubuntu22.04
  ##    --os-variant ubuntu22.04
  ##
  
  
  ##
  ## 주의:
  ##  VM instance 내부에서 OS 설치가 끝나고, 자동 reboot되어야 하는게 정상이지만
  ##  가끔 OS termination 단계에서 실패하고 멈춘 경우가 있다.
  ##  reboot 시도 후 30초 후에도 console 화면의 변화가 없다면
  ##  과감하게 VM instance destroy를 시도한다.  (아래 명령을 사용)
  ##  
  $  
  ##

 

위 `virt-install` 명령을 실행하면, 바로 아래 화면이 출력되고

이 화면에서 대략 55~60초 정도 기다려야 다음 설치 화면으로 넘어간다.

 

 

위 화면에서 대략 55~60초 정도 기다리면, 드디어 아래와 같이 OS 설치 시작 화면이 나온다.

 

 

비록 Text Terminal 이지만, 조금이라도 예쁜 설치 화면을 원하면 "rich mode"를 선택한다.

이후부터는 일반적인 Ubuntu OS 설치 절차와 같다.

 

 

 

 

 

 

Virtual Machine 목록 보기

$  virsh list --all
 Id   Name     State
-------------------------
 1    x-node   running
 -    am0      shut off
 -    aw0      shut off
 -    aw1      shut off
 $

 

 

Virtual Machine 기동하기

##
## am0 가상 머신을 기동하기
##

$  virsh start am0
Domain am0 started


##
## am0 가상 머신이 기동되었는지 확인하기
##

$  virsh list --all
 Id   Name     State
-------------------------
 1    x-node   running
 2    am0      running
 -    aw0      shut off
 -    aw1      shut off
$

 

 

Virtual Machine 종료하기

##
## Graceful Termination of VM instance
## (참고로, 아래 숫자 2는 VM의 ID이다)
##

$  virsh shutdown 2
Domain 2 is being shutdown

$


##
## VM instance 강제 종료
## (참고로, 아래 숫자 2는 VM의 ID이다)
##

$ virsh destroy 2


##
## VM instance 삭제하기
##
$ virsh undefine vm-name

 

 

Virtual Machine의  Console에 접속하기

$  virsh console x-node
Connected to domain x-node
Escape character is ^]

CentOS Linux 8
x-node login: root
Password: ......

[root@x-node ~]# _

 

 

qcow2 image file size 조정 (resize)

##
## 원하는 size로 vm image를 재조정할 수 있다.
## 최초에 작게 만들어진 volume image 용량을 더 크게 늘리기 위해서 사용한다.
##

$ qemu-img  resize  myvm.qcow2  100G


##
##  아래 명령과 같이 수행하여 기존 VM image에서 빈 공간을 제거하고 size를 줄일 수 있다.
##  보통 qcow2 파일을 다른 장비로 옮길 때, vm image size를 줄이기 위한 용도로 사용된다.
##  참고: 원본 qcow2 이미지 파일은 유지되므로 별도로 백업하지 않아도 된다.
 
$  qemu-img convert -O qcow2 source_image.qcow2 shrunk_image.qcow2


##
## volume image 정보를 열람한다.
##

$ qemu-img  info    myvm.qcow2

 

 

qcow2 image 파일 생성하기

##
## 만약 qcow2 type의 virtual volume을 만들고 싶다면 아래와 같이 명령을 수행.
## Volume size는 250GB로 지정했지만, 실제로는 qcow2 파일에 meta data만 생성하기 때문에
## 실제 사이느는 1MB 밖에 안 되고, 시간도 3초 정도 밖에 안 걸린다.
##

$  qemu-img  create  -f qcow2  my-virtual-volume.qcow2  250G

 

 

VM의 OS Type 전체 목록 열람하기

$  virt-install --osinfo list
...
ubuntu-lts-latest, ubuntu-stable-latest, ubuntu22.04, ubuntujammy
ubuntu21.10, ubuntuimpish
ubuntu21.04, ubuntuhirsute
ubuntu20.10, ubuntugroovy
ubuntu20.04, ubuntufocal
...
$

 

 

기존 VM instance에 disk 추가하기

$ virsh edit my-vm

... 중간 생략 ...

  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' discard='unmap'/>
      <source file='/var/lib/libvirt/images/my-vm-a.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <boot order='1'/>
      <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>
    </disk>
    ##
    ## FIXME: 이 부분을 추가한다.
    ##
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/opt/virtual_storage/vol_01.qcow2'/>
      <target dev='vdb' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x09' slot='0x00' function='0x0'/>
    </disk>
    
... 중간 생략 ...

$ virsh reboot my-vm

## 또는 아래와 같이 hypervisor를 restart한다.

$ systemctl restart libvirt-bin

 

위 방식과 다르게 virt-install 명령으로 disk를 추가하여 VM instance를 재시작한다.

virt-install \
  --import \
  --name my-vm \
  --osinfo ubuntu22.04 \
  --ram 2048 \
  --vcpus 2 \
  --disk  /opt/virtual_machine/my-vm.qcow2 \
  --disk  /opt/virtual_machine/my-new-disk.qcow2 \
  --graphics none \
  --network network=br-ex \
  --console pty,target.type=virtio \
  --autoconsole text

 

 

 

 

 


 

 

##
## 채용 관련 글
##
제가 일하고 있는 기업 부설연구소에서 저와 같이 연구/개발할 동료를 찾고 있습니다.
(이곳은 개인 블로그라서 기업 이름은 기재하지 않겠습니다. E-mail로 문의주시면 자세한 정보를 공유하겠습니다.)

근무지 위치:
  서울시 서초구 서초동, 3호선 남부터미널역 근처 (전철역 출구에서 회사 입구까지 도보로 328m)
필요한 지식 (아래 내용 중에서 70% 정도를 미리 알고 있다면 빠르게 협업할 수 있음):
  - 운영체제 (학부 3~4학년 때, 컴퓨터공학 운영체제 과목에서 배운 지식 수준):
    예를 들어, Processor, Process 생성(Fork)/종료, Memory, 동시성, 병렬처리, OS kernel driver  
  - Linux OS에서 IPC 구현이 가능
    예를 들어, MSGQ, SHM, Named PIPE 등 활용하여 Process간 Comm.하는 기능 구현이 가능하면 됨. 
  - Algorithm(C언어, C++ 언어로 구현 가능해야 함)
    예를 들어, Hashtable, B-Tree, Qsort 정도를 C 또는 C++로 구현할 수 있을 정도 
  - Network 패킷 처리 지식(Layer 2 ~ 4, Layer 7)
    예를 들어, DHCP Server/Client의 주요 Feature를 구현할 정도의 능력이 있으면 됨.
  - Netfilter, eBPF 등 (IP packet hooking, ethernet packet 처리, UDP/TCP packet 처리)
  - IETF RFC 문서를 잘 읽고 이해하는 능력 ^^
  # 위에 열거한 내용 외에도 제가 여기 블로그에 적은 내용들이 대부분 업무하면서 관련이 있는 주제를 기록한 것이라서
  # 이 블로그에 있는 내용들을 잘 알고 있다면, 저희 연구소에 와서 연구/개발 업무를 수행함에 있어서 어려움이 없을 겁니다.
회사에서 사용하는 프로그래밍 언어:
  - 프로그래밍 언어: C, C++, Go
    (참고: 아직 연구소 동료들이 Rust를 사용하진 않습니다만, 새 언어로써 Rust를 사용하는 것을 고려하는 중)
근무 시간:
  - 출근: 8~10시 사이에서 자유롭게 선택
  - 퇴근: 8시간 근무 후 퇴근 (오후 5시 ~ 7시 사이)
  - 야근 여부: 거의 없음 (내 경우, 올해 상반기 6개월간 7시 이후에 퇴근한 경우가 2회 있었음)
  - 회식 여부: 자유 (1년에 2회 정도 회식하는데, 본인이 집에 가고 싶으면 회식에 안 감. 왜 참석 안 하는지 묻지도 않음)
외근 여부:
  - 신규 프로젝트 멤버 -> 외근 전혀 하지 않음 (나는 신규 프로젝트만 참여해서 지난 1년 동안 한번도 외근 없었음)
  - 상용 프로젝트 멤버 -> 1년에 5회 미만 정도로 외근
팀 워크샵 여부:
  - 팀 워크샵 자체를 진행하지 않음. (워크샵 참석하는 거 싫어하는 개발자 환영 ^^)
연락처:
  - "sejong.jeonjo@gmail.com"  # 궁금한 점은 이 연락처로 문의주세요.
  - 블로그 비밀 댓글 (제가 하루에 한번씩 댓글 확인하고 있음)
원하는 인재상:
  - 우리 부설연구소는 "긴 호흡으로 프로젝트를 진행"하기 때문에 최소 2년간 한 가지 주제를 꾸준하게 연구/개발할 수 있는 개발자를 원함.
  - 우리 부설연구소는 자주적으로 연구 주제를 찾아서 업무를 하기 때문에 능동적으로 생각하고 행동하는 동료를 원함.
  - 차분하게 연구 주제에 몰입하고, 해법을 찾는 것을 즐기는 사람.
내가 느끼는 우리 연구소의 장점:
  - 갑/을 관계가 없음. (제가 근무하고 있는 연구소는 SI업종이 아니라서 갑/을 회사 개념이 없음)
  - 연구소 자체적으로 연구 주제를 발굴하고 시스템을 개발하기 때문에 개발 일정에 대한 스트레스가 적음
  - 빌딩 전체를 우리 회사가 사용하므로 분위기가 산만하지 않음.
  - 근처에 예술의전당, 우면산 둘레길이 있어서 점심 시간에 산책하기 좋음 ^^
  - 연구소 동료들 매너가 Good (2년간 일하면서 한번도 감정에 스크레치 생기거나 얼굴 붉히며 싸운 적 없음 ^^)

+ Recent posts