Ansible 은 인프라스트럭처 관리와 소프트웨어 프로비저닝을 자동화하기 위한 오픈 소스 도구 및 프레임워크입니다. Ansible 은 다음 3가지의 핵심 구성 요소를 가지고 있습니다.
- 인벤토리 : 관리 대상 호스트 (서버, 가상 머신 등) 의 목록 및 그룹을 정의하는 INI 또는 YAML 파일
- 플레이북 : 작업 (task), 역할 (role), 변수, 조건문 등을 포함한 YAML 파일로, 여러 대상 호스트에서 작업을 수행
- 모듈 : 특정 작업을 수행하기 위한 실행 가능한 코드 블록

Ubuntu 22.04 기반에서 Ansible 을 설치, 설정하고 실제로 실행하는 방법을 알아보겠습니다.

[테스트를 위한 사전 준비]

- Ubuntu 22.04 기반 서버 3대 (Ansible 서버 1대, 대상 호스트 2대)

1. 설치

Ansible 설치는 굉장히 간단합니다.

Ansible 명령을 수행할 Ansible 서버에만 몇 개의 패키지를 설치하면 되며, 작업을 수행할 서버에 설치할 패키지 또는 Agent 는 없습니다.

(그렇기 때문에 본 매뉴얼의 모든 명령은 Ansible 서버에서만 실행합니다)

Ansible 는 SSH 기반으로 명령을 수행하기 때문에 sshpass 패키지까지 설치해줘야 합니다.

그리고 Ansible 은 Python 으로 제작되었기 때문에 Ansible 설치시 Python 도 같이 설치가 됩니다.

# apt -y update

# apt -y upgrade

# apt -y install ansible sshpass

# ansible --version
ansible 2.10.8
  config file = None
  configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3/dist-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.10.12 (main, Jun 11 2023, 05:26:28) [GCC 11.4.0]

2. 인벤토리 설정

1) 인벤토리 파일 생성

관리하는 서버의 정보를 담은 파일을 아래와 같이 생성합니다.

섹션 이름은 서버를 그룹핑하기 위한 명칭으로 적절히 설정하면 되고,

대상 호스트는 IP 또는 도메인으로 입력할 수 있습니다.

섹션 내에 여러대의 호스트 추가가 가능합니다.

# vi servers.ini

2) SSH 공개키 복사

Ansible 은 ssh 를 이용하여 대상 호스트로 명령을 수행합니다.

ssh 공개키를 생성하고 대상 호스트에 설정하여두면 Ansible 명령 실행시마다 패스워드를 입력하는 번거로움을 줄일 수 있습니다.

# ssh-keygen 
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): (그냥 엔터)
Enter passphrase (empty for no passphrase): (그냥 엔터)
Enter same passphrase again: (그냥 엔터)
Your identification has been saved in /root/.ssh/id_rsa
Your public key has been saved in /root/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:2bKuWWJfCBqiNnkCYgKZRmI6GEZDynqWbGM41/TsbAk root@kuru80-223962
The key's randomart image is:
+---[RSA 3072]----+
|=B               |
|X+.              |
|Oo  .            |
|++ + o   o       |
|B.@ E + S .      |
|=O.o * o +       |
|.= .. B + .      |
|. +  o * .       |
|      o.o        |
+----[SHA256]-----+

생성된 공개키를 대상 호스트로 복사합니다. 처음 호스트 접속시 패스워드가 필요하지만 키 복사가 완료된 후에는 패스워드가 필요 없게 됩니다.

# ssh-copy-id root@10.101.0.23

# ssh-copy-id root@10.101.0.34

3) 연결 테스트

Ansible 에서 주로 사용하는 옵션은 세가지가 있습니다. (help 에서는 더 많은 옵션이 출력됩니다)

-m : 모듈

-i : 인벤토리

-u : 유저명

유저명은 제외하고 아래와 같이 인벤토리 (servers.ini) 에 등록된 모든 호스트에 ping 테스트를 해봅니다.

참고로 all 말고 섹션명을 지정해주면 인벤토리 내의 특정 세션에 등록된 호스트로만 명령을 실행합니다.

# ansible -i servers.ini all -m ping
10.101.0.34 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}
10.101.0.23 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

3. 옵션

Ansible 은 기본적으로 작업을 병렬 처리 합니다.

기본 동시 처리되는 호스트 개수는 5개 입니다.

# ansible-config dump |grep -i forks
DEFAULT_FORKS(default) = 5

서버의 자원이 충분하여 동시에 처리되는 양을 늘리고자 할 경우 아래와 같이 설정파일을 수정하여 동시처리 개수를 늘릴 수 있습니다.

설정파일은 아래 여러 가지 방법중 한가지 방법을 이용하여 설정할 수 있으며, 우선 순위대로 검색되는 구성 파일으로 적용되어집니다.

- ANSIBLE_CONFIG (환경변수)
- ansible.cfg (현재 디렉토리)
- ~/.ansible.cfg (홈디렉토리)
- /etc/ansible/ansible.cfg

디렉토리가 바뀌어도 항상 적용이 가능하도록 세번째 방법으로 설정해보겠습니다.

# vi ~/.ansible.cfg

저장만 해도 변경된 것이 확인되었습니다.

# ansible-config dump |grep -i forks
DEFAULT_FORKS(/root/.ansible.cfg) = 10

아래는 중요하거나 자주 사용하는 옵션입니다. 모두 [default] 섹션에 넣어주면 됩니다.

- remote_user

: 원격 호스트에 연결할 때 사용할 SSH 사용자 이름을 지정합니다. 기본값은 현재 사용자의 이름입니다. 이 옵션을 설정하여 명시적으로 원격 사용자를 지정할 수 있습니다.
예) remote_user = myuser

- private_key_file

: SSH 키 파일의 경로를 지정합니다. 이 옵션을 사용하여 사용자 지정 SSH 키 파일을 사용할 수 있습니다.
예) private_key_file = /path/to/ssh/keyfile

- inventory

: 인벤토리 파일의 경로를 지정합니다. 기본적으로 ansible.cfg 파일이 있는 디렉토리에서 inventory 파일을 검색하며, 이 옵션을 사용하여 사용자 정의 인벤토리 파일을 지정할 수 있습니다. 인벤토리 파일의 경로를 지정하면 ansible 명령 실행시 -i 옵션을 이용해 인벤토리 파일을 일일이 명시하지 않아도 됩니다.
예) inventory = /root/servers.ini

- roles_path

: 역할 (roles) 디렉토리의 기본 경로를 지정합니다. 이 옵션을 사용하여 역할을 저장하는 디렉토리를 사용자 정의할 수 있습니다.
예) roles_path = /path/to/custom/roles

- forks

: 병렬로 실행될 작업 수를 지정합니다. 기본값은 5이며, 시스템 리소스에 따라 적절한 값을 설정할 수 있습니다.
예) forks = 10

- become

: 작업을 슈퍼 유저(루트) 권한으로 실행할지 여부를 지정합니다. yes로 설정하면 슈퍼 유저로 작업을 실행합니다.
예) become = yes

- become_user

: 슈퍼 유저(루트) 권한으로 작업을 실행할 때 사용할 사용자를 지정합니다.
예) become_user = root

- timeout

: SSH 연결 또는 명령 실행의 타임아웃을 지정합니다. 기본값은 10초입니다.
예) timeout = 30

4. 플레이북 설정

플레이북 (playbook) 을 활용한 다양한 예시를 준비했습니다.

1) 대상 서버로 파일 복사하기

아래와 같이 플레이북 파일을 작성합니다.

# vi copy.yaml

- 플레이북 파일의 시작은 --- 로 시작하고, 여러개의 작업이 있을 경우 작업 단위마다 - 으로 구분해줘야 합니다.

- hosts : 섹션을 지정합니다. hosts 를 web 섹션으로 하지 않고 all 로 입력 할 경우 인벤토리에 등록된 모든 호스트로 파일을 복사하게 됩니다.

- name : 작업을 구분하기 위한 명칭입니다. (위, 아래 둘다)

- copy : 복사하려는 로컬 파일과 붙여넣으려는 대상 호스트의 디렉토리를 지정합니다.

작성한 플레이북을 실행합니다.

# ansible-playbook -i servers.ini copy.yaml

2) 패스워드 변경하기

대상 호스트의 root 패스워드를 변경합니다.

# vi chpasswd.yaml

- name: 플레이북의 이름을 정의합니다. 이 이름은 플레이북을 식별하기 위해 사용됩니다.
- hosts: 플레이북이 실행될 호스트 그룹을 지정합니다. "all"은 모든 호스트를 대상으로 하는 것을 의미합니다.
- tasks: 플레이북에서 실행할 작업 목록을 정의합니다.
- name: 각 작업의 이름을 지정합니다. 이것은 작업을 식별하기 위한 레이블입니다.
- user 모듈: 이 모듈은 사용자 관리 작업을 수행합니다.
- name: root: user 모듈에 전달된 사용자 이름으로 "root" 사용자를 지정합니다. 이 플레이북은 "root" 사용자의 비밀번호를 변경합니다.
- update_password: always: 사용자 모듈의 update_password 옵션을 "always"로 설정하면 항상 비밀번호를 업데이트하도록 강제합니다.
- password: user 모듈에서 변경할 비밀번호를 정의합니다. 이 플레이북에서는 "12345678"을 password_hash 필터를 사용하여 SHA-512로 해싱한 값을 비밀번호로 설정합니다. 해싱된 비밀번호를 사용하면 보안성을 향상시킬 수 있습니다.

작성한 플레이북을 실행합니다.

# ansible-playbook -i servers.ini chpasswd.yaml

3) 패키지 설치하기

이 예시는 원격 서버의 APT 패키지 관리자를 사용하여 패키지를 설치합니다.
# vi apt.yaml

- name: 플레이북의 이름을 정의합니다. 이 이름은 플레이북을 식별하기 위해 사용됩니다.
- hosts: 플레이북이 실행될 호스트 그룹을 지정합니다. "web"은 모든 호스트를 대상으로 하는 것을 의미합니다.
- tasks: 플레이북에서 실행할 작업 목록을 정의합니다.
- apt 모듈: 패키지 설치 작업을 수행합니다.

작성한 플레이북을 실행합니다.

# ansible-playbook -i servers.ini apt.yaml

4) 데몬 컨트롤 하기

이 예제에서는  Ubuntu 에서 Apache 웹 서버를 시작하는 플레이북을 사용합니다.
# vi apache2.yaml

- name: 플레이북의 이름을 지정합니다.
- hosts: 플레이북을 실행할 호스트 그룹 또는 호스트 이름을 지정합니다.
- become: yes: become 키워드를 사용하여 플레이북을 실행할 때 슈퍼유저(루트) 권한으로 실행합니다. 이는 데몬 또는 서비스를 시작하거나 중지할 때 필요한 권한을 얻기 위해 사용됩니다.
- tasks: 수행할 작업 목록을 나열합니다.
- name: 작업의 이름을 지정합니다.
- service 모듈: 서비스 관리 작업을 수행하는 모듈입니다.
- name: apache2: 서비스의 이름을 지정합니다. Ubuntu 에서 Apache 웹 서버는 apache2 로 알려져 있습니다.
- state: started: 서비스를 시작하도록 지정합니다. 이 작업은 Apache 웹 서버가 이미 실행 중인 경우에는 아무 작업도 수행하지 않습니다.

작성한 플레이북을 실행합니다.

# ansible-playbook -i servers.ini apache2.yaml

5) 사용자 생성 및 그룹 할당
이 예시는 원격 서버에 사용자를 생성하고 그룹에 할당하는 플레이북입니다. user 및 group 모듈을 사용합니다.

# vi useradd.yaml

* 설명

- name: 플레이북의 이름을 지정합니다.
- hosts: 플레이북을 실행할 호스트 그룹 또는 호스트 이름을 지정합니다.
- tasks: 수행할 작업 목록을 나열합니다.
- group 및 user 모듈: 그룹 및 사용자 생성 및 할당 작업을 수행합니다.

작성한 플레이북을 실행합니다.

# ansible-playbook -i servers.ini useradd.yaml

6) 보안 패치 적용
서버에 보안 패치를 적용합니다.
# vi update.yaml

작성한 플레이북을 실행합니다.

# ansible-playbook -i servers.ini update.yaml

7) MySQL 설치 및 설정
MySQL 데이터베이스를 설치하고 설정합니다.

DB 생성, 계정 생성 및 DB 권한 부여까지 진행합니다.
# vi mysql.yaml

작업을 설명하면, 아래와 같이 순차 처리됩니다.

- MySQL 설치

- MySQL 시작

- python3-pymysql 설치 (Ansible 에서 MySQL 관리하기 위해 필요)

- root 패스워드 변경 (null -> 12345678)

- DB 생성

- DB 계정 생성

- 계정에 DB 권한 부여

* 작업별로 MySQL 쿼리 실행을 위해 root 계정정보를 입력해 주었습니다.

작성한 플레이북을 실행합니다.

# ansible-playbook -i servers.ini mysql.yaml

8) Docker 컨테이너 배포 및 관리

Docker 컨테이너를 배포하고 관리합니다.

플레이북에서 대상 호스트에 Docker 패키지와 docker-py 설치 작업 후 컨테이너를 구동하는 절차로 작성하면 되지만, 여기에서는 Docker 및 docker-py 가 대상 호스트에 설치되었다고 가정하고 컨테이너 구동 방법만 설명드립니다.

* 참고 : Docker 및 docker-py 설치 (Ubuntu 22.04)

(대상 호스트에서)

# apt -y install apt-transport-https ca-certificates curl gnupg lsb-release
# curl -fsSL https://download.docker.com/linux/ubuntu/gpg |gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
# echo   "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" |tee /etc/apt/sources.list.d/docker.list > /dev/null
# apt -y update
# apt -y install docker-ce docker-ce-cli containerd.io

# apt -y install python3-pip

# pip3 install docker-py

플레이북을 작성합니다.

(Ansible 서버에서)

# vi docker.yaml

- name: 플레이북의 이름을 지정합니다. 이 이름은 플레이북을 식별하는 레이블입니다.
- hosts: 플레이북을 실행할 호스트 또는 호스트 그룹을 지정합니다. 이 예시에서는 "db" 호스트 그룹에 대한 작업을 수행합니다.
- tasks: 플레이북에서 실행할 작업 목록을 정의합니다.
- name: 각 작업의 이름을 지정합니다. 이것은 작업을 식별하는 레이블입니다.
- docker_image 모듈: 이 모듈은 Docker 이미지 관리 작업을 수행합니다. name 속성은 다운로드하려는 Docker 이미지의 이름을 지정합니다. 이 예시에서는 "nginx:latest" 이미지를 다운로드합니다.
- docker_container 모듈: 이 모듈은 Docker 컨테이너 관리 작업을 수행합니다. name 속성은 컨테이너의 이름을 지정하고, image 속성은 사용할 Docker 이미지를 지정합니다. ports 속성은 컨테이너와 호스트 간의 포트 매핑을 설정합니다. 이 예시에서는 "my_nginx"라는 이름의 컨테이너를 생성하고 "nginx:latest" 이미지를 사용하며, 호스트의 80번 포트와 컨테이너의 80번 포트를 연결합니다.

작성한 플레이북을 실행합니다.

# ansible-playbook -i servers.ini docker.yaml

GlusterFS 를 RAID 와 같은 여러가지 형태로 구성 가능하지만 본 매뉴얼에서는 단일 서버로 서비스하는 방법에 대해 기술하였습니다.

[사전 작업]
서버에 추가 Disk 를 연결하고 /data 디렉토리로 마운트 했습니다.
그리고 마운트 디렉토리 안에 gv0 이라는 Brick 디렉토리를 생성해 두었습니다.

Brick 디렉터리는 GlusterFS 볼륨에서 데이터를 저장하는 디렉터리를 뜻합니다.
- /data/gv0

1. 설치

호스트 명을 변경합니다.
# hostnamectl set-hostname gnode

호스트를 등록 합니다.
# vi /etc/hosts

GlusterFS 설치를 위한 Repository 를 등록해줍니다.
등록은 yum 로 간단히 할 수 있습니다.
# yum -y install centos-release-gluster

GlusterFS 패키지를 설치합니다.
# yum -y install glusterfs glusterfs-libs glusterfs-server

서버 부팅시 glusterd 데몬이 자동 구동 되도록 하고, 현재 세션에서도 구동시켜줍니다.
# systemctl enable --now glusterd

설치된 버전을 확인합니다.

# glusterd --version
glusterfs 9.6
Repository revision: git://git.gluster.org/glusterfs.git
Copyright (c) 2006-2016 Red Hat, Inc. <https://www.gluster.org/>
GlusterFS comes with ABSOLUTELY NO WARRANTY.
It is licensed to you under your choice of the GNU Lesser
General Public License, version 3 or any later version (LGPLv3
or later), or the GNU General Public License, version 2 (GPLv2),
in all cases as published by the Free Software Foundation.

2. 볼륨 생성

Cluster Pool 을 구성합니다.

여러대로 구성할 경우 본 서버가 아닌 다른 서버를 peer 로 등록해야 하지만, 단일 서버로 구성할 예정이므로 추가할 peer 가 없습니다.

Pool 을 구성하는 peer 리스트를 확인합니다.

# gluster pool list
UUID Hostname  State
eb4dba8d-df9a-4471-962a-103200830683 localhost Connected 

볼륨을 구성합니다.

# gluster volume create gv0 gnode:/data/gv0
volume create: gv0: success: please start the volume to access data

* 에러 출력시

volume create: gv0: failed: The brick gnode:/data/gv0 is being created in the root partition. It is recommended that you don't use the system's root partition for storage backend. Or use 'force' at the end of the command if you want to override this behavior.

위와 같은 에러 메세지는 별도의 파티션 디렉토리가 아니고 루트 (/) 파티션에서 생성한 디렉토리에서 볼륨을 구성할때 경고 메세지가 출력되는 것입니다. 추가 디스크나 별도의 파티션을 추가하지 않았지만 테스트 목적으로 구성하고 싶다면, 명령 뒤에 force 문자를 추가하여 실행할 수 있습니다.

예) gluster volume create gv0 gnode:/data/gv0 force

gv0 볼륨을 시작합니다.

# gluster volume start gv0

volume start: gv0: success

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

# gluster volume info gv0

 
Volume Name: gv0
Type: Distribute
Volume ID: 5aeec667-d4f8-433c-8fec-91ae275569ea
Status: Started
Snapshot Count: 0
Number of Bricks: 1
Transport-type: tcp
Bricks:
Brick1: gnode:/data/gv0
Options Reconfigured:
storage.fips-mode-rchecksum: on
transport.address-family: inet
nfs.disable: on

3. Client 마운트

GlusterFS 에서는 몇가지 마운트 방법을 제공합니다. GlusterFS (FUSE), NFS, iSCSI, SMB 방식인데 여기에서는 일반적인 FUSE 방식을 설명하겠습니다.

Client 에서 마운트에 필요한 패키지를 설치하고 마운트를 합니다.

GlusterFS 서버를 찾을 수 있도록 도메인을 연결하면 좋겠지만 현재 테스트 환경에서는 hosts 파일을 이용하였으므로 Client 에서도 찾을 수 있도록 /etc/hosts 파일에 아래 내용을 작성해 줍니다.

# vi /etc/hosts

클라이언트 패키지를 설치하고 마운트를 합니다.

# yum -y install glusterfs-client  // CentOS 명령어 이므로 Ubuntu 사용자는 apt 명령 사용

# mkdir /backup

# mount -t glusterfs gnode:/gv0 /backup

# df -h
파일 시스템     크기  사용  가용 사용% 마운트위치
tmpfs           1.5G  2.3M  1.5G    1% /run
/dev/sda2       214G   29G  174G   15% /
tmpfs           7.3G   66M  7.3G    1% /dev/shm
tmpfs           5.0M  4.0K  5.0M    1% /run/lock
tmpfs           1.5G  192K  1.5G    1% /run/user/1000
gnode:/gv0       10G  135M  9.9G    2% /backup

* 참고

디렉토리에 쿼터를 적용하는 방법이나 GlusterFS 를 RAID 서버와 같이 여러대로 구성하는 방법은 아래 포스팅을 참고해주세요.

https://sysdocu.tistory.com/1821

# dd if=/dev/zero of=sysdocu.bin bs=100M count=10

위와 같이 실행시 1GB (100MB * 10) 짜리 sysdocu.bin 파일이 생성됩니다.

Github 에 올려진 소스 코드를 다운로드 하는 방법입니다.

CentOS 7 환경에서 테스트하였습니다.

1. 패키지 설치
우선 소스 코드를 다운로드 하기위해 github 패키지를 설치합니다.
# yum -y install git

2. Public 코드 다운로드
공개 코드는 아무나 접근하여 다운로드가 가능하므로 아래와 같이 실행할 수 있습니다.
# git clone https://github.com/sysdocu/html-sample.git

리포지토리 이름으로 생성된 디렉토리로 이동합니다.
# cd html-sample

파일 내용을 확인합니다.
# ls -al

3. Private 코드 다운로드
1) 직접 계정 입력
Private 리포지토리 URL 을 공개 코드 다운로드와 같이 명령을 실행하면 Username, Password 를 입력하는 절차가 출력됩니다. 하지만 CLI 에서 명령 한줄로 처리하고자 할때 아래와 같이 사용이 가능합니다.
# git clone https://<username>:<password>@github.com/sysdocu/html-secret.git

CLI 한줄에 계정 정보 입력시 <username> 이나 <password> 에 특수문자가 들어가게 될 경우 아래와 같은 문자로 치환해주어야 합니다.

[이미지 출처] https://stackoverflow.com/questions/10054318/how-do-i-provide-a-username-and-password-when-running-git-clone-gitremote-git/10056098#10056098

2) Git 자격 증명 사용
직접 계정을 입력하는 방법은 history 에도 남고 패스워드가 탈취될 가능성이 있기 때문에 안전한 방법이 아닙니다. 하지만 강화된 보안 방법인 'Git 자격 증명' 을 사용하면 계정이 아닌 토큰으로 인증이 가능하며, 계정에 대한 작업 권한도 제어가 가능하고, 일정 시간이 지나 토큰의 효력이 상실되기 때문에 패스워드 탈취에 대한 부담도 줄일 수 있습니다.

우선 Github 에 로그인을 하고 토큰 생성 페이지 (바로가기 : https://github.com/settings/tokens) 로 이동합니다.

페이지 내에서 'Generate a personal access token' 링크 또는 'Generate new token' > 'Generate new token (classic)' 을 누르고, 토큰 발급 이유를 'Note' 에 적당히 입력 후, 토큰의 만료 기간을 선택합니다. repo 의 모든 기능에만 체크하고, 하단의 [Generate token] 를 누르면 토큰이 출력됩니다. 이것을 복사하여 CLI 명령어에 사용하도록 합니다.

# git clone https://<token>@github.com/sysdocu/html-secret.git

다운로드가 확인되었으며, 리포지토리 이름으로 생성된 디렉토리로 이동합니다.
# cd html-secret

파일 내용을 확인합니다.
# ls -al

GlusterFS 는 분산 파일 시스템으로써 여러 대의 서버를 클러스터로 구성하여 대용량의 데이터를 분산 저장하고 관리할 수 있는 기술입니다. RAID 와 같이 각각의 노드에 데이터를 따로 저장하거나 (Distributed), 복제 저장하거나 (Replicated), 분산 저장 (Disperse) 이 가능합니다. GlusterFS 는 Redhat 이 개발하고 오픈 소스로 제공되며, 다양한 용도의 분산 스토리지 및 파일 공유에 이용됩니다.

본 매뉴얼에서의 테스트 환경은 CentOS 7 이며, 다양한 볼륨 구성을 예제로 다루었습니다.

CentOS 6 또는 8 버전은 설치 방법에 약간 차이가 있으니 아래 Documents 를 참고해 주세요.

https://wiki.centos.org/SpecialInterestGroup/Storage/gluster-Quickstart

[사전 작업]
각 노드에 추가 Disk 를 연결하고 /data 디렉토리로 마운트 했습니다.
그리고 각 마운트 디렉토리 안에 gv0 이라는 Brick 디렉토리를 생성해 두었습니다.

Brick 디렉터리는 GlusterFS 볼륨에서 데이터를 저장하는 디렉터리를 뜻합니다.
- /data/gv0

1. GlusterFS 서버 구축

1) hostname 설정

호스트 명을 변경합니다.
# hostnamectl set-hostname gnode1  // 1번 노드에서
# hostnamectl set-hostname gnode2  // 2번 노드에서

# hostnamectl set-hostname gnode3  // 3번 노드에서

(모든 노드에서)
호스트를 등록 합니다.
# vi /etc/hosts

위는 gnode1 의 hosts 내용인데, 자신의 노드는 따로 행을 추가하지 말고 127.0.0.1 라인에 기록해 둡니다.

gnode2, gnode3 노드에서의 hosts 는 각각 다음과 같습니다.

2) 패키지 설치
GlusterFS 설치를 위한 Repository 를 등록해줍니다.
등록은 yum 로 간단히 할 수 있습니다.
# yum -y install centos-release-gluster

GlusterFS 패키지를 설치합니다.
# yum -y install glusterfs glusterfs-libs glusterfs-server

서버 부팅시 glusterd 데몬이 자동 구동 되도록 하고, 현재 세션에서도 구동시켜줍니다.
# systemctl enable --now glusterd

설치된 버전을 확인합니다.

# glusterd --version
glusterfs 9.6
Repository revision: git://git.gluster.org/glusterfs.git
Copyright (c) 2006-2016 Red Hat, Inc. <https://www.gluster.org/>
GlusterFS comes with ABSOLUTELY NO WARRANTY.
It is licensed to you under your choice of the GNU Lesser
General Public License, version 3 or any later version (LGPLv3
or later), or the GNU General Public License, version 2 (GPLv2),
in all cases as published by the Free Software Foundation.

서버간 통신이 이루어져야 하므로 firewalld 또는 iptables 와 같은 방화벽에서 서로의 IP 를 허용해주거나, 데이터가 없는 테스트 서버일 경우 방화벽을 잠시 내려 테스트 합니다.

2. 복제 (Replica) 볼륨 구성

replica 볼륨은 데이터를 여러 브릭에 복제하여 데이터의 안정성과 내구성을 제공합니다.

RAID 시스템의 1 (mirror) 과 유사합니다. 노드 2대로만 구성하는 것이 아니고 여러대로 복제가 가능합니다.

GlusterFS 에서는 기본 3대 이상으로 구성할 것을 권하고 있으며, 2대로 구성을 원할경우 아래 '8. 판사 (Arbiter) 볼륨 구성' 을 참고하세요.

여기에서는 3대의 노드로 구성해 보겠습니다.

패키지 설치와 호스트네임 등록 이후의 설정은 하나의 노드에서만 합니다.

1) Pool 연결

(gnode1 노드에서)

Cluster Pool 을 구성합니다.

# gluster peer probe gnode2

peer probe: success

# gluster peer probe gnode3
peer probe: success

연결된 노드를 확인합니다.

gnode1 에서 명령 실행시 연결된 두개의 노드 (gnode2, gnode3) 가 보입니다.

# gluster peer status
Number of Peers: 2

Hostname: gnode2
Uuid: edea03f3-472b-47b5-a711-ed06763631c4
State: Peer in Cluster (Connected)

Hostname: gnode3
Uuid: 0771cb09-89d3-4a5b-8e7d-3980473ffc0e
State: Peer in Cluster (Connected)

다른 노드에서도 같은 명령을 사용해보면 자신의 노드를 제외한 총 2개의 노드 정보가 확인됩니다.

참고로 peer 노드 제거 명령은 'gluster peer detach <노드명>' 을 사용합니다.

Pool 리스트를 확인합니다.

# gluster pool list
UUID Hostname  State
edea03f3-472b-47b5-a711-ed06763631c4 gnode2    Connected 
0771cb09-89d3-4a5b-8e7d-3980473ffc0e gnode3    Connected 
25d3f6cb-b2ed-4aa1-add7-0a27890ed5ed localhost Connected 

이 명령에서는 자신의 노드를 포함한 총 3개의 노드 정보가 확인됩니다.

2) 볼륨 생성

데이터를 저장할 수 있도록 GlusterFS 볼륨을 생성합니다.

(gnode1 노드에서)

3대의 노드를 하나의 볼륨으로 묶습니다. (볼륨명 : gv0, 복제본 : 3)

# gluster volume create gv0 replica 3 gnode1:/data/gv0 gnode2:/data/gv0 gnode3:/data/gv0

volume create: gv0: success: please start the volume to access data

여기에서 volume create: gv0: failed: /data/gv0 is already part of a volume 에러가 출력되는 분은 아래 '5. 볼륨 재구성' 을 참고하세요.

노드 서버 3대로 복제 저장 구성을 한 이유는 2대로만 복제 구성하면 스플릿 브레인에 취약할 수 있기 때문입니다. 스플릿 브레인은 분산 파일 시스템에서 복제된 데이터의 일관성을 유지하기 위해 중요한 개념입니다. 복제된 볼륨이 스플릿 브레인에 취약하다는 것은 데이터의 불일치가 발생할 수 있는 가능성이 있다는 것을 의미합니다. 복제 2 볼륨은 두 개의 복제본을 가지고 있으므로 데이터의 일관성을 유지하기 위해 두 복제본이 동기화되어야 합니다. 그러나 네트워크 문제, 장애 등의 이유로 복제본 간의 통신이 중단되면 각각의 복제본이 독립적으로 운영되는 상황이 발생할 수 있습니다. 이는 데이터의 일관성을 해치는 스플릿 브레인 상태를 초래할 수 있습니다.

gv0 볼륨을 시작합니다.

# gluster volume start gv0

volume start: gv0: success

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

# gluster volume info gv0

 
Volume Name: gv0
Type: Replicate
Volume ID: 09540703-2a84-4dce-bb6c-af156cf1813d
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: gnode1:/data/gv0
Brick2: gnode2:/data/gv0
Brick3: gnode3:/data/gv0
Options Reconfigured:
cluster.granular-entry-heal: on
storage.fips-mode-rchecksum: on
transport.address-family: inet
nfs.disable: on
performance.client-io-threads: off

* 중요 : 볼륨 생성 후 옵션을 하나 설정합니다.

볼륨 구성이 어떠한 형태이던 (비록 replica 일지라도) GlusterFS Cluster 를 구성하는 한 개의 peer 가 장애가 났을때 Client 는 42초간 (default) GlusterFS 의 응답을 기다리느라 데이터를 읽거나 쓰지 못하게 됩니다. 서비스 제공시 42초는 긴 시간이기 때문에 장애 서버의 다운을 감지하고 해당 peer 를 빠르게 제거하기 위한 옵션 network.ping-timeout 을 설정해 주어야 합니다.

여기에서는 서버 응답 대기시간을 0초로 적용합니다. 이렇게 하면 peer 다운시 찰나의 지연 (delay) 이 있지만 끊어지지 않으며 데이터 유실또한 발생하지 않습니다.

# gluster volume set gv0 network.ping-timeout 0

volume set: success

# gluster volume info | grep timeout
network.ping-timeout: 0

추후 장애 peer 복구시 파티션 (Brick Directory) 연결 및 glusterd 데몬이 순자적으로 이루어진다면, 다른 peer 에서 생성, 변경된 파일이 자동으로 동기화되어 최신 데이터를 유지하게 됩니다.

사용가능한 옵션 종류는 아래 URL 에서 확인 가능합니다.

https://access.redhat.com/documentation/ko-kr/red_hat_gluster_storage/3.5/html/administration_guide/volume_option_table

* 데이터 저장 형태

데이터가 어느 노드에 어떻게 저장되는지 확인하고 싶어서 적당한 크기의 파일을 하나씩 입력해 보았고 아래 내용으로 확인되었습니다.

- 파일을 저장하면 replica 3 으로 구성된 gnode1, gnode2, gnode3 노드에 동일한 데이터 저장

3. Quota 설정

Brick 디렉토리에 하위 디렉토리를 생성하여 용량을 제한을 할 수 있습니다.

공식 Document : https://docs.gluster.org/en/v3/Administrator%20Guide/Directory%20Quota/

gv0 볼륨 쿼터 설정을 활성화 합니다.

# gluster volume quota gv0 enable

volume quota : success

참고로 비활성화는 enable 대신 disable 을 입력합니다.

그리고 Client 가 마운트하여 사용하던 중 쿼터 제한을 걸때 사용하는 옵션이 있는데 이에 대한 설명은 아래와 같습니다. (Default : on)

# gluster volume set gv0 quota-deem-statfs on

* 참고

- on: GlusterFS는 디렉토리의 용량 제한을 강제로 적용하고, 해당 디렉토리에서 사용 가능한 실제 용량을 디렉토리의 용량 제한으로 간주합니다. 즉, 사용자가 설정한 용량 제한보다 실제 사용 중인 용량이 크더라도 GlusterFS는 해당 디렉토리의 용량 제한을 적용합니다. 이는 사용자가 실제 사용 중인 용량을 고려하지 않고 일관된 용량 제한을 유지하고자 할 때 유용합니다.

(예 : 2GB 데이터 사용중에 쿼터를 1GB 로 제한하면, 제한값은 1GB 에 머물러 있음)
- off: GlusterFS는 디렉토리의 용량 제한을 강제로 적용하지 않고, 실제 사용 중인 용량을 기준으로 디렉토리의 용량 제한을 판단합니다. 즉, 사용자가 설정한 용량 제한보다 실제 사용 중인 용량이 크다면 GlusterFS는 해당 디렉토리의 용량 제한을 초과로 간주합니다. 이는 실제 사용 중인 용량을 기준으로 용량 제한을 적용하고자 할 때 유용합니다.

(예 : 2GB 데이터 사용중에 쿼터를 1GB 로 제한하면, 제한값은 2GB 에 머물러 있음)

하위 디렉토리를 그냥 만들면 mkdir 명령을 내린 노드에서만 디렉토리가 생성되기때문에 쿼터 적용이 되지 않습니다.

볼륨을 마운트하고 디렉토리를 만들어 놓아야 합니다.

Client 또는 아무 node 에서나 마운트 명령을 내려도 상관없습니다.

# mkdir /imsi

# mount -t glusterfs gnode1:/gv0 /imsi

# mkdir /imsi/{apple,banana,grape}

# umount /imsi

하위 디렉토리에 각 1G 씩 용량 제한을 합니다.

디렉토리를 지정할때는 Brick 디렉토리 (/data/gv0) 를 제외하고 하위 디렉토리만 입력합니다.

# gluster volume quota gv0 limit-usage /apple 1GB

volume quota : success
# gluster volume quota gv0 limit-usage /banana 1GB
volume quota : success
# gluster volume quota gv0 limit-usage /grape 1GB
volume quota : success

gv0 볼륨의 쿼터 설정값을 확인합니다.

# gluster volume quota gv0 list

                  Path                   Hard-limit  Soft-limit      Used  Available  Soft-limit exceeded? Hard-limit exceeded?
-------------------------------------------------------------------------------------------------------------------------------
/apple                                     1.0GB     80%(819.2MB)   0Bytes   1.0GB              No                   No
/banana                                    1.0GB     80%(819.2MB)   0Bytes   1.0GB              No                   No
/grape                                     1.0GB     80%(819.2MB)   0Bytes   1.0GB              No                   No

Hard-limit 는 1GB 로 원하는 용량이 제한 되었지만, Soft-limit 는 80% 선으로 설정된 것이 보입니다.

- Hard-limit : 사용자 또는 프로세스가 설정된 최대 제한을 초과하지 못하도록 하는 제한하는 값입니다.

- Soft-limit : 사용자 또는 프로세스가 현재 사용 중인 리소스의 제한으로, 사용자가 시스템 리소스를 임시로 초과할 수 있는 한계를 설정합니다. Soft-limit은 Hard-limit 보다 작거나 같아야 합니다. Soft-limit 을 초과하려는 경우에는 경고가 발생하지만 작업을 계속할 수 있습니다. 시스템의 안정성을 고려하기 위해 용량이 거의 채워져간다는 알림을 주기 위한 용도 정도로 보면 됩니다.

Soft-limit 도 100% 까지 사용하기 위해 아래와 같이 변경 설정 해줍니다.

# gluster volume quota gv0 limit-usage /apple 1GB 100
volume quota : success
# gluster volume quota gv0 limit-usage /banana 1GB 100
volume quota : success
# gluster volume quota gv0 limit-usage /grape 1GB 100
volume quota : success

변경 내용을 확인합니다.

# gluster volume quota gv0 list
                  Path                   Hard-limit  Soft-limit      Used  Available  Soft-limit exceeded? Hard-limit exceeded?
-------------------------------------------------------------------------------------------------------------------------------
/apple                                     1.0GB    100%(1.0GB)   0Bytes   1.0GB              No                   No
/banana                                    1.0GB    100%(1.0GB)   0Bytes   1.0GB              No                   No
/grape                                     1.0GB    100%(1.0GB)   0Bytes   1.0GB              No                   No

4. Client 마운트

GlusterFS 에서는 몇가지 마운트 방법을 제공합니다. GlusterFS (FUSE), NFS, iSCSI, SMB 방식인데 여기에서는 일반적인 FUSE 방식을 설명하겠습니다.

Client 에서 마운트에 필요한 패키지를 설치하고 마운트를 합니다.

GlusterFS 서버를 찾을 수 있도록 도메인을 연결하면 좋겠지만 현재 테스트 환경에서는 hosts 파일을 이용하였으므로 Client 에서도 찾을 수 있도록 /etc/hosts 파일에 아래 내용을 작성해 줍니다.

# vi /etc/hosts

그리고 마운트 할때는 gnode1 부터 gnode3 까지 아무 서버로 연결해도 상관없습니다.

# yum -y install glusterfs-client

# mkdir /backup

# mount -t glusterfs gnode1:/gv0 /backup

또는 쿼터 적용된 디렉토리로 마운트가 가능합니다.

# mount -t glusterfs gnode1:/gv0/apple /backup

마운트 디렉토리에 파일을 쓰면 모든 노드에 동일하게 복제되어 저장됩니다.

-------------------- 여기부터 다양한 스토리지 구성 테스트 --------------------

5. 볼륨 재구성 (볼륨 완전 삭제, 재생성)

볼륨을 삭제하고 다시 구성할때 에러가 발생하는데 어떻게 해결하는지 알아봅니다.

볼륨을 중지해야 삭제가 가능하기 때문에 먼저 중지 명령을 내립니다.

# gluster volume stop gv0
Stopping volume will make its data inaccessible. Do you want to continue? (y/n) y
volume stop: gv0: success

볼륨을 삭제합니다.
# gluster volume delete gv0
Deleting volume will erase all information about the volume. Do you want to continue? (y/n) y
volume delete: gv0: success

이 상태에서 동일한 디렉토리로 볼륨 설정을 하면 아래와 같이 에러가 발생합니다.

# gluster volume create gv0 replica 3 gnode1:/data/gv0 gnode2:/data/gv0 gnode3:/data/gv0
volume create: gv0: failed: /data/gv0 is already part of a volume

이는 볼륨을 생성하려는 디렉토리에 메타데이터가 있거나 구성의 흔적 때문인데, 해결책은 아래와 같습니다.

(모든 노드에서 : 볼륨 구성했던 이력이 있는 모든 서버)

# setfattr -x trusted.glusterfs.volume-id /data/gv0
# setfattr -x trusted.gfid /data/gv0
# rm -rf /data/gv0/.glusterfs*

그리고 하나의 노드에서 아래와 같이 명령을 내리면 볼륨이 정상적으로 생성됩니다.

# gluster volume create gv0 replica 3 gnode1:/data/gv0 gnode2:/data/gv0 gnode3:/data/gv0
volume create: gv0: success: please start the volume to access data

6. 장애 노드 (peer) 교체

replica 3 (peer 3개) 으로 구성된 cluster 에서 1개의 노드 (peer) 가 장애나면 2개의 peer 에서 무정지로 서비스가 가능합니다. 이때 장애난 peer 를 새로운 서버로 변경한다고 했을때 cluster 를 재구성 하는 방법 입니다.

gnode1, gnode2, gnode3 중에서 gnode2 가 장애 났다고 가정합니다.

사전작업으로 gnode2 노드에 추가 Disk 를 연결하고 /data 디렉토리로 마운트 했습니다.
그리고 마운트 디렉토리 안에 gv0 이라는 Brick 디렉토리를 생성해 두었습니다..
- /data/gv0

(gnode1 또는 gnode3 에서)

remove-brick 명령을 이용해 장애난 peer 를 replica cluster 에서 제외합니다. (replica 3 -> 2)
# gluster volume remove-brick gv0 replica 2 gnode2:/data/gv0 force
Remove-brick force will not migrate files from the removed bricks, so they will no longer be available on the volume.
Do you want to continue? (y/n) y
volume remove-brick commit force: success

peer 목록에서 제외합니다.
# gluster peer detach gnode2
All clients mounted through the peer which is getting detached need to be remounted using one of the other active peers in the trusted storage pool to ensure client gets notification on any changes done on the gluster configuration and if the same has been done do you want to proceed? (y/n) y
peer detach: success

볼륨 정보를 확인합니다.
# gluster volume info
 
Volume Name: gv0
Type: Replicate
Volume ID: 8e2fbb51-5f00-43f3-9d09-0655cac39dfb
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: gnode1:/data/gv0
Brick2: gnode3:/data/gv0
Options Reconfigured:
performance.client-io-threads: off
nfs.disable: on
transport.address-family: inet
storage.fips-mode-rchecksum: on
cluster.granular-entry-heal: on
network.ping-timeout: 0

gnode2 라는 peer 가 cluster 에서 제거된 것이 확인되었습니다.
다시 peer 를 추가 하고 replica 3 으로 재설정하여 데이터를 동기화 합니다. 

# gluster peer probe gnode2
peer probe: success

add-brick 명령으로 새로운 노드 하나만 기입하여 replica 3 으로 재구성 합니다.
# gluster volume add-brick gv0 replica 3 gnode2:/data/gv0
volume add-brick: success

이렇게 작업은 마무리 되었습니다.
참고로 success 메세지가 출력되어도 데이터가 동기화 되는 것에는 시간이 걸리므로 상태를 잘 지켜보시기 바랍니다.

7. 복제 (Replica) 볼륨 확장

1) Replica 증설 및 축소

3개의 노드가 replica 3 으로 구성된 상태에서 노드를 한대 더 추가하여 replica 4 로 구성해보겠습니다. (replica 3 -> 4)

먼저 추가되는 노드 (gnode4) 에서 사전 작업을 해주세요.

- 추가디스크 mount (/data) 및 디렉토리 생성 (/data/gv0)

- hostname 및 hosts 설정 (기존 노드 포함)

- glusterfs 패키지 설치 및 가동

기존 노드 서버에서 피어를 추가하고 재구성 명령을 실행합니다.

# gluster peer probe gnode4
peer probe: success

# gluster volume add-brick gv0 replica 4 gnode4:/data/gv0
volume add-brick: success

볼륨 정보를 출력합니다.

# gluster volume info
 
Volume Name: gv0
Type: Replicate
Volume ID: 63328573-90cc-4272-8094-9fd7b9d74821
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 4 = 4
Transport-type: tcp
Bricks:
Brick1: gnode1:/data/gv0
Brick2: gnode2:/data/gv0
Brick3: gnode3:/data/gv0
Brick4: gnode4:/data/gv0
Options Reconfigured:
features.quota-deem-statfs: on
features.inode-quota: on
features.quota: on
cluster.granular-entry-heal: on
storage.fips-mode-rchecksum: on
transport.address-family: inet
nfs.disable: on
performance.client-io-threads: off

추가했던 노드를 제거하는 방법은 다음과 같습니다. (replica 4 -> 3)

# gluster volume remove-brick gv0 replica 3 gnode4:/data/gv0 force
Remove-brick force will not migrate files from the removed bricks, so they will no longer be available on the volume.
Do you want to continue? (y/n) y
volume remove-brick commit force: success

# gluster peer detach gnode4
All clients mounted through the peer which is getting detached need to be remounted using one of the other active peers in the trusted storage pool to ensure client gets notification on any changes done on the gluster configuration and if the same has been done do you want to proceed? (y/n) y
peer detach: success

볼륨 정보를 확인합니다.

# gluster volume info
 
Volume Name: gv0
Type: Replicate
Volume ID: 63328573-90cc-4272-8094-9fd7b9d74821
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: gnode1:/data/gv0
Brick2: gnode2:/data/gv0
Brick3: gnode3:/data/gv0
Options Reconfigured:
features.quota-deem-statfs: on
features.inode-quota: on
features.quota: on
cluster.granular-entry-heal: on
storage.fips-mode-rchecksum: on
transport.address-family: inet
nfs.disable: on
performance.client-io-threads: off

2) Replica 용량 증설

replica 3 은 복제본이 3개 있다는 뜻이므로 데이터 안정성을 어느정도 확보 했다고 볼 수 있습니다. 하지만 노드의 용량이 줄어들 경우에는 또다른 노드를 마련해서 데이터 저장 공간을 확보해야 하는데요. 추가할 노드 수는 복제본 수의 배수여야 합니다. (예: replica 3 의 볼륨 확장시 3의 배수인 6, 9, 12, ... 의 개수로만 추가 가능)

추가된 노드를 GlusterFS 클러스터에 포함 시키는 방법은 아래와 같습니다.

먼저 추가되는 노드 (gnode4, gnode5, gnode6) 에서 사전 작업을 해주세요.

- 추가디스크 mount (/data) 및 디렉토리 생성 (/data/gv0)

- hostname 및 hosts 설정 (기존 노드 포함)

- glusterfs 패키지 설치 및 가동

그리고 기존 노드에서 peer 를 추가합니다.

# gluster peer probe gnode4

# gluster peer probe gnode5

# gluster peer probe gnode6

볼륨 상태를 출력하여 추가된 노드를 확인합니다.

# gluster volume status
Status of volume: gv0
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick gnode1:/data/gv0                      49152     0          Y       11850
Brick gnode2:/data/gv0                      49152     0          Y       9917 
Brick gnode3:/data/gv0                      49152     0          Y       29859
Self-heal Daemon on localhost               N/A       N/A        Y       12991
Quota Daemon on localhost                   N/A       N/A        Y       13185
Self-heal Daemon on gnode2                  N/A       N/A        Y       10432
Quota Daemon on gnode2                      N/A       N/A        Y       10537
Self-heal Daemon on gnode5                  N/A       N/A        Y       9175 
Quota Daemon on gnode5                      N/A       N/A        Y       9186 
Self-heal Daemon on gnode6                  N/A       N/A        Y       9173 
Quota Daemon on gnode6                      N/A       N/A        Y       9184 
Self-heal Daemon on gnode4                  N/A       N/A        Y       6471 
Quota Daemon on gnode4                      N/A       N/A        Y       6483 
Self-heal Daemon on gnode3                  N/A       N/A        Y       30817
Quota Daemon on gnode3                      N/A       N/A        Y       30979
 
Task Status of Volume gv0
------------------------------------------------------------------------------
There are no active volume tasks

위에서 노드가 추가되었지만 아직 Brick 사용 상태는 아닌것으로 확인됩니다.

추가한 노드에도 데이터가 쓰여질 수 있도록 볼륨을 확장해야 합니다.

이를 위해 gluster volume add-brick 명령을 사용합니다.

볼륨명과 replica 구성은 그대로 하고, 추가할 노드만 적어주면 됩니다.

# gluster volume add-brick gv0 replica 3 gnode4:/data/gv0 gnode5:/data/gv0 gnode6:/data/gv0
volume add-brick: success

볼륨 상태를 확인합니다.

# gluster volume info
 
Volume Name: gv0
Type: Distributed-Replicate
Volume ID: 24463284-fb20-4d4b-9d13-0b891c2f892f
Status: Started
Snapshot Count: 0
Number of Bricks: 2 x 3 = 6
Transport-type: tcp
Bricks:
Brick1: gnode1:/data/gv0
Brick2: gnode2:/data/gv0
Brick3: gnode3:/data/gv0
Brick4: gnode4:/data/gv0
Brick5: gnode5:/data/gv0
Brick6: gnode6:/data/gv0
Options Reconfigured:
features.quota-deem-statfs: on
features.inode-quota: on
features.quota: on
cluster.granular-entry-heal: on
storage.fips-mode-rchecksum: on
transport.address-family: inet
nfs.disable: on
performance.client-io-threads: off

'replica 3 구성이 2세트로, 총 6개의 brick 이 구성되어 있다' 라는 뜻인데 아래와 같이 Brick 상태를 보면 추가된 brick 3개는 아직 활성화되지 않은 것으로 출력됩니다.

# gluster volume status |grep Brick
Brick gnode1:/data/gv0                      49152     0          Y       30890
Brick gnode2:/data/gv0                      49152     0          Y       23376
Brick gnode3:/data/gv0                      49152     0          Y       16274
Brick gnode4:/data/gv0                      N/A       N/A        N       N/A  
Brick gnode5:/data/gv0                      N/A       N/A        N       N/A  
Brick gnode6:/data/gv0                      N/A       N/A        N       N/A 

볼륨을 확장 (add-brick) 하거나 축소 (remove-brick) 할 때는 서버 간에 데이터 균형을 재조정해야 하는데, 이때 필요한 패키지가 glusterfs-geo-replication 입니다. 데이터 균형을 맞추기 전에 패키지 설치를 해야합니다.

# yum -y install glusterfs-geo-replication

rebalance 명령으로 데이터 균형 작업을 진행합니다.

# gluster volume rebalance gv0 start
volume rebalance: gv0: success: Rebalance on gv0 has been started successfully. Use rebalance status command to check status of the rebalance process.
ID: df6c2123-04d7-4b45-9311-e05430db6cac

rebalance 상태는 다음 명령으로 확인할 수 있습니다.

status 항목에 모든 작업이 completed 된것과 volume rebalance 작업이 성공되었다는 메세지를 확인할 수 있습니다.
# gluster volume rebalance gv0 status
                                    Node Rebalanced-files          size       scanned      failures       skipped               status  run time in h:m:s
                               ---------      -----------   -----------   -----------   -----------   -----------         ------------     --------------
                                  gnode2                0        0Bytes             2             0             0            completed        0:00:00
                                  gnode3                0        0Bytes             2             0             0            completed        0:00:00
                                  gnode4                0        0Bytes             0             0             0            completed        0:00:00
                                  gnode5                0        0Bytes             1             0             0            completed        0:00:00
                                  gnode6                0        0Bytes             1             0             0            completed        0:00:00
                               localhost                0        0Bytes             2             0             0            completed        0:00:00
volume rebalance: gv0: success

Client 에서는 마운트 되어 있던 GlusterFS 파티션 가용 공간이 자동으로 두 배 늘어난 것이 확인됩니다.

(용량 확장 전)

# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        889M     0  889M   0% /dev
tmpfs           907M   84K  907M   1% /dev/shm
tmpfs           907M   97M  810M  11% /run
tmpfs           907M     0  907M   0% /sys/fs/cgroup
/dev/vda1        25G   17G  9.0G  65% /
tmpfs           182M     0  182M   0% /run/user/0
gnode1:/gv0      10G  135M  9.9G   2% /backup

(용량 확장 후)

# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        889M     0  889M   0% /dev
tmpfs           907M   84K  907M   1% /dev/shm
tmpfs           907M   97M  810M  11% /run
tmpfs           907M     0  907M   0% /sys/fs/cgroup
/dev/vda1        25G   17G  9.0G  65% /
tmpfs           182M     0  182M   0% /run/user/0
gnode1:/gv0      20G  270M   20G   2% /backup

* 데이터 저장 형태

데이터가 어느 노드에 어떻게 저장되는지 확인하고 싶어서 적당한 크기의 파일을 하나씩 입력해 보았고 아래 내용으로 확인되었습니다.

- 파일을 저장하면 처음 replica 3 으로 구성된 gnode1, gnode2, gnode3 노드에 데이터 저장

- 추가 파일을 저장하면 나중 replica 3 으로 구성된 gnode4, gnode5, gnode6 노드에 데이터 저장

- 디렉토리는 모든 노드에서 생성

- Client 에서는 모든 노드의 데이터가 합쳐져 보임

즉, gnode1 (또는 gnode2 또는 gnode3) 의 데이터와 gnode4 (또는 gnode5 또는 gnode6) 의 데이터를 합치면 온전한 사용자 데이터가 된다는 것을 확인하였습니다.

3) Replica 구성 및 볼륨 제거

볼륨을 제거하면 구성 방식 (replica, stripe 등) 정보가 같이 삭제 됩니다.

우선 마운트 되어있는 Client 에서 모두 unmount 하여 스토리지를 분리합니다.

# umount /backup

운영중인 볼륨을 중지합니다.

# gluster volume stop gv0
Stopping volume will make its data inaccessible. Do you want to continue? (y/n) y
volume stop: gv0: success

볼륨을 삭제 합니다.

gluster volume delete gv0
Deleting volume will erase all information about the volume. Do you want to continue? (y/n) y
volume delete: gv0: success

아직 테스트하던 peer 는 연결되어진 상태입니다. 볼륨을 재구성 할 예정이므로 peer 연결 해제 및 데이터 삭제 방법만 알아두고 넘어가기로 합니다.

* 노드 분리 방법

# gluster peer detach <노드 이름>

* 데이터 삭제 (각 노드에서 실행)

# setfattr -x trusted.glusterfs.volume-id /data/gv0
# setfattr -x trusted.gfid /data/gv0
# rm -rf /data/gv0/.glusterfs*

8. 분산 (Disperse) 볼륨 구성 - with Parity peer

disperse 볼륨은 데이터와 패리티를 사용하여 데이터를 분산 저장하고, 손상된 브릭의 데이터를 복구할 수 있는 내구성을 제공합니다.

RAID 시스템의 5 구성과 매우 유사한 기능을 제공하고 있어서 파일을 쓸 경우 모든 Brick 에 동시 분산 저장이 되기 때문에 파일 I/O 속도가 빠르며 peer 한 대가 다운되어도 나머지 peer 에서 데이터 조합이 가능하기 때문에 무정지 서비스가 가능합니다. 하지만 peer 두 대 이상이 다운될 경우 Client 에서는 모든 데이터를 읽지 못하게 됩니다.

그럼 disperse 형식으로 볼륨을 생성해 보겠습니다.

먼저 gnode1 노드에서 peer 를 추가 합니다.

# gluster peer probe gnode2

# gluster peer probe gnode3

볼륨을 생성합니다.

# gluster volume create gv0 disperse 3 gnode1:/data/gv0 gnode2:/data/gv0 gnode3:/data/gv0
volume create: gv0: success: please start the volume to access data

disperse 3 옵션은 3개의 노드 (peer) 로 분산 저장 구성한다는 의미입니다. 결국 2개의 데이터 peer 와 1개의 패리티 peer 로 자동 구성됩니다.

생성한 볼륨을 시작합니다.

# gluster volume start gv0
volume start: gv0: success

볼륨에 서버 응답 대기시간을 0초로 적용합니다.

# gluster volume set gv0 network.ping-timeout 0

volume set: success

볼륨 정보를 확인합니다.

# gluster volume info
 
Volume Name: gv0
Type: Disperse
Volume ID: fb35eca2-9c54-4768-9ea9-eb27c0fd223d
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x (2 + 1) = 3
Transport-type: tcp
Bricks:
Brick1: gnode1:/data/gv0
Brick2: gnode2:/data/gv0
Brick3: gnode3:/data/gv0
Options Reconfigured:

network.ping-timeout: 0
storage.fips-mode-rchecksum: on
transport.address-family: inet
nfs.disable: on

여기에서 'Number of Bricks: 1 x (2 + 1) = 3' 를 볼 수 있는데, 위에서 설명한대로 (2 + 1) 은 2개의 데이터 Brick 과 1개의 Parity Brick 으로 구성되어 있음을 나타냅니다. 앞에 1 x 는 '이런 세트가 하나있다' 라고 이해하시면 됩니다.

Parity Brick 은 데이터 안정성을 위해 자동 생성되는 Brick 으로, 구성하는 서버 수량에 따라 아래와 같이 자동 할당 됩니다. 그리고 각각의 Brick 이 10GB 의 용량을 가지고 있을때 사용가능한 최종 데이터 저장 용량은 아래와 같습니다.

- 노드가 2개 일때 : 구성 불가. 최소한 3대가 필요합니다.

- 노드가 3개 일때 : 1 x (2 + 1) = 3  # 총 20GB

- 노드가 4개 일때 : 1 x (3 + 1) = 4  # 총 30GB

- 노드가 5개 일때 : 1 x (4 + 1) = 5  # 총 40GB

특이사항으로, 4대로 구성할때만 아래와 같은 메세지가 출력됩니다.

There isn't an optimal redundancy value for this configuration. Do you want to create the volume with redundancy 1 ? (y/n) y

* 데이터 저장 형태

데이터가 어느 노드에 어떻게 저장되는지 확인하고 싶어서 적당한 크기의 파일을 하나씩 입력해 보았고 아래 내용으로 확인되었습니다.

- 데이터 노드 (peer) 에 나뉘어져 저장

   > 데이터 노드가 2대 일때 : 10MB 파일 저장시 gnode1 에 5M, gnode2 에 5M 저장

   > 데이터 노드가 3대 일때 : 10MB 파일 저장시 gnode1 에 3.4M, gnode2 에 3.4M, gnode3 에 3.4M 저장

- 1대의 데이터 peer 에 저장되는 용량만큼 Parity Peer 에 저장

- 디렉토리는 모든 노드에서 생성

- 데이터 peer 에 생성되는 용량은 512 byte 단위로 생성됌

   > 이용자가 10 byte 텍스트 파일을 생성하더라도 데이터 peer 마다 512 byte 크기의 파일이 생성

   > 데이터 peer 가 2대 일때, 이용자가 1000 byte 파일을 생성한다면 각 peer 마다 512 byte 크기의 파일이, 이용자가 1200 byte 파일을 생성하면 각 peer 마다 1024 byte 크기의 파일이 생성 됌.

- peer 1대 장애 : Client 에서 데이터 및 서비스 유지 가능

- peer 2대 장애 : Client 에서 '입력/출력 오류' 상태로 빠짐. 추후 서버가 부팅되어 peer 파티션이 연결되고 glusterd 데몬이 구동되면 자동 연결 됌

참고로 disperse 볼륨에서는 패리티 파편을 명시적으로 지정하지 않습니다. GlusterFS 에서는 disperse 볼륨에 대한 패리티 파편의 위치를 추적하지 않습니다. 대신, disperse 볼륨은 데이터와 패리티를 조합하여 고유한 분산 방식으로 데이터를 보관합니다. 따라서, disperse 볼륨에서는 특정 peer 가 패리티 peer 인지를 명확하게 알 수 없습니다. 데이터와 패리티 파편은 모든 peer 에 균등하게 분산되므로 각 peer 는 동시에 데이터와 패리티를 저장합니다.

9. 판사 (Arbiter) 볼륨 구성

Arbiter 는 GlusterFS 의 Replica 구성에서 사용되는 옵션 중 하나입니다. Replica 구성은 데이터를 여러 Brick 에 복제하여 내구성과 가용성을 제공하는 방식입니다. 일반적으로 Replica 구성은 세 개의 복제 Brick 을 사용하지만, Arbiter 를 사용하면 세 번째 복제 Brick 대신에 판사 (Arbiter) Brick 을 사용합니다.
Arbiter 의 역할은 데이터의 복제를 수행하는 것이 아니라 복제 집합의 일부로서 데이터의 일관성을 유지하는 역할을 합니다. 각 복제 Brick 은 데이터를 가지고 있지만, 판사 Brick 은 실제 데이터를 저장하지 않고, 오로지 복제 그룹 내의 데이터 일관성을 확인하는 역할을 수행합니다. 따라서 Arbiter 를 사용하면 세 번째 Brick 으로 저장할 데이터 용량을 절약할 수 있습니다.
Arbiter 를 사용하는 Replica 구성은 데이터의 내구성과 가용성을 유지하면서 용량 효율성을 개선할 수 있습니다. 예를 들어, 10GB 의 데이터를 저장해야 할 때, 일반적인 Replica 구성은 3개의 10GB Brick 을 필요로 합니다. 그러나 Arbiter 를 사용하는 Replica 구성에서는 2개의 10GB Brick 과 1개의 Arbiter Brick 만으로도 같은 수준의 내구성을 제공할 수 있습니다. (Replica 2 를 구성하는 2개의 Brick 에 데이터 차이가 있어도 Arbiter 때문에 어떤게 최신 peer 인지 구분 가능)

gnode1 노드에서 peer 를 추가 합니다.

# gluster peer probe gnode2

# gluster peer probe gnode3

Arbiter 볼륨을 생성합니다.

# gluster volume create gv0 replica 2 arbiter 1 gnode1:/data/gv0 gnode2:/data/gv0 gnode3:/data/gv0
volume create: gv0: success: please start the volume to access data

볼륨을 시작합니다.

# gluster volume start gv0
volume start: gv0: success

볼륨에 서버 응답 대기시간을 0초로 적용합니다.

# gluster volume set gv0 network.ping-timeout 0

volume set: success

볼륨 정보를 확인합니다.

# gluster volume info
 
Volume Name: gv0
Type: Replicate
Volume ID: 2b88b6dd-c50d-4752-96fd-7acb98ce0d53
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x (2 + 1) = 3
Transport-type: tcp
Bricks:
Brick1: gnode1:/data/gv0
Brick2: gnode2:/data/gv0
Brick3: gnode3:/data/gv0 (arbiter)
Options Reconfigured:

network.ping-timeout: 0
cluster.granular-entry-heal: on
storage.fips-mode-rchecksum: on
transport.address-family: inet
nfs.disable: on
performance.client-io-threads: off

2대의 Replica 서버와 1대의 Arbiter 서버가 구성 되었습니다.

각 peer 가 10GB 일때, Client 에서 사용 가능한 최대 용량은 10G 입니다.

* 데이터 저장 형태

데이터가 어느 노드에 어떻게 저장되는지 확인하고 싶어서 적당한 크기의 파일을 하나씩 입력해 보았고 아래 내용으로 확인되었습니다.

- 10MB 파일 저장시 gnode1, gnode2 에 각각 10MB 파일 생성되고 gnode3 에는 0 Byte 의 파일 생성

- 디렉토리는 모든 노드에서 생성

- peer 1대 장애 : Client 에서 데이터 및 서비스 유지 가능

- peer 2대 장애 : Client 에서 '전송 종료지점이 연결되어 있지 않습니다' 상태로 빠짐. 추후 다운되었던 Replica 서버 또는 Arbiter 서버가 1대라도 부팅되어 peer 파티션이 연결되고 glusterd 데몬이 구동되면 자동 연결 됌

10. 통합 (Distributed) 볼륨 구성

Distributed 는 GlusterFS 의 기본 볼륨 구성값으로써 모든 peer 의 용량을 합하여 제공되는 방식입니다. disperse 볼륨과 같이 다량의 peer 에 동시에 데이터를 읽고 쓸 수 있는 구성이 아닌, 단순히 용량만 합하여 제공하기 때문에 peer 에 순차적으로 데이터를 저장하는 특징을 보입니다. 모든 peer 에 동시에 데이터를 읽고 쓰지 않으므로 속도가 disperse 보다 빠르지 않으며 parity peer 도 없기 때문에 하나의 peer 가 다운될 경우 데이터를 읽거나 쓰지 못하는 상황이 발생되며, peer 의 서버 대수가 많이 늘어날 수록 장애가 발생할 확률도 높아지게 됩니다.

distributed 볼륨 구성을 위해 gnode1 노드에서 peer 를 추가 합니다.

# gluster peer probe gnode2

중간에 아무런 옵션을 주지 않으면 기본 Distributed 상태로 볼륨이 생성됩니다.

# gluster volume create gv0 gnode1:/data/gv0 gnode2:/data/gv0
volume create: gv0: success: please start the volume to access data

볼륨을 시작합니다.

# gluster volume start gv0
volume start: gv0: success

볼륨에 서버 응답 대기시간을 0초로 적용합니다.

# gluster volume set gv0 network.ping-timeout 0

volume set: success

볼륨 정보를 확인합니다.

# gluster volume info
 
Volume Name: gv0
Type: Distribute
Volume ID: 77a483c0-479e-4237-91af-aa76058a3f2d
Status: Started
Snapshot Count: 0
Number of Bricks: 2
Transport-type: tcp
Bricks:
Brick1: gnode1:/data/gv0
Brick2: gnode2:/data/gv0
Options Reconfigured:

network.ping-timeout: 0
storage.fips-mode-rchecksum: on
transport.address-family: inet
nfs.disable: on

2대의 Brick 이 Distribute 로 구성 되었습니다.

각 peer 가 10GB 일때, Client 에서 사용 가능한 최대 용량은 20G 입니다.

* 데이터 저장 형태

데이터가 어느 노드에 어떻게 저장되는지 확인하고 싶어서 적당한 크기의 파일을 하나씩 입력해 보았고 아래 내용으로 확인되었습니다.

- gnode1 로 마운트하고 파일 저장시 gnode1 노드에 생성되고 계속 저장시 gnode1 노드 용량 (10GB) 까지만 저장 가능

- gnode2 로 마운트하고 파일 저장시 gnode2 노드에 생성되고 계속 저장시 gnode2 노드 용량 (10GB) 까지만 저장 가능

- Client 에서는 20GB 용량으로 보이고 gnode1, gnode2 에 저장된 데이터가 모두 보임

- 디렉토리는 모든 노드에서 생성

- peer 1대 장애 : 장애난 peer 의 데이터는 보이지 않고 남아있는 peer 내의 데이터만 보임. 추후 서버가 부팅되어 peer 파티션이 연결되고 glusterd 데몬이 구동되면 모든 파일들이 잘 보이게 됌

11. NFS 서비스 제공하기 (with NFS-Ganesha) --- 작성중

GlusterFS 를 일반적인 fuse 형식이 아닌 NFS 형식으로 마운트 할 수 있게 기능을 제공합니다.

볼륨 정보를 보면 아래와 같은 nfs 기본 옵션이 출력됩니다.

# gluster volume info
 
Volume Name: gv0
Type: Replicate
Volume ID: 563a8023-dc1c-4b2d-a86c-af8dcf21c5da
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: gnode1:/data/gv0
Brick2: gnode2:/data/gv0
Brick3: gnode3:/data/gv0
Options Reconfigured:
cluster.granular-entry-heal: on
storage.fips-mode-rchecksum: on
transport.address-family: inet
nfs.disable: on
performance.client-io-threads: off

여기에서 NFS 를 사용하지 않는 옵션이 켜져 (on) 있습니다. 이것을 off 하고 몇가지 설정을 더 하면, GlusterFS 에서 제공하는 NFS 서버를 사용할 수 있습니다. 하지만 GlusterFS 에서 제공하는 NFS 서버 방식은 NFSv3 이고, 요새는 NFSv4 를 지원하는 NFS-Ganesha 가 별도 배포되고 있습니다. NFS-Ganesha 는 GlusterFS 와의 통합을 용이하게 하기 위해 개발된 것으로 기존의 GlusterFS NFS 서버 대신 NFS-Ganesha 를 사용하면 GlusterFS 와 NFS 간의 상호 운용성이 향상되고 다양한 기능과 유연성을 제공할 수 있습니다.
- 다양한 NFS 버전 지원 : NFSv3, NFSv4, NFSv4.1 및 NFSv4.2 를 지원하므로 다양한 클라이언트와의 상호 운용성이 높아집니다.
- 고급 기능 : 파일 시스템 관리, 보안, 액세스 제어, 성능 튜닝 등의 고급 기능을 제공합니다.
- 확장성 : 다중 프로토콜 지원, 클러스터링, 로드 밸런싱 등의 기능을 통해 GlusterFS 클러스터의 확장성을 향상시킵니다.
- 유연한 구성 : 다양한 구성 옵션과 플러그인 아키텍처를 제공하여 사용자의 요구에 맞게 유연하게 구성할 수 있습니다.

이러한 이유로 NFS-Ganesha 를 이용해 GlusterFS 의 NFS 서비스를 구성해 보겠습니다.

1) 설치

(모든 노드에서)

# yum -y install centos-release-nfs-ganesha30
# sed -i -e "s/enabled=1/enabled=0/g" /etc/yum.repos.d/CentOS-NFS-Ganesha-30.repo
# yum --enablerepo=centos-nfs-ganesha30 -y install nfs-ganesha-gluster

기본 설정 파일은 별도로 백업해놓고 새로운 설정을 추가 합니다.

# mv /etc/ganesha/ganesha.conf /etc/ganesha/ganesha.conf.ori
# vi /etc/ganesha/ganesha.conf

데몬 부팅 설정과 함께 데몬을 시작합니다.

# systemctl enable --now nfs-ganesha

서비스 포트 열린것이 확인되었습니다.

# netstat -nltp |grep ganesha
tcp6       0      0 :::875                  :::*                    LISTEN      18997/ganesha.nfsd  
tcp6       0      0 :::2049                 :::*                    LISTEN      18997/ganesha.nfsd 

2) Client 에서 마운트하기

마운트 하려는 디렉토리를 생성합니다.

# mkdir /backup

볼륨 전체는 마운트가 안되고,

# mount -t nfs gnode1:/gv0 /backup

하위 디렉토리는 마운트 가능합니다.

# mount -t nfs gnode1:/gv0/apple /backup

iSCSI 는 서버 간에 SCSI 명령을 TCP/IP 네트워크를 통해 전송하기 위한 프로토콜입니다. 이를 통해 원격 스토리지 장치에 접근하여 데이터를 전송하고 저장할 수 있습니다. iSCSI는 LAN 또는 WAN 을 통해 스토리지 리소스를 공유하고, 데이터 센터에서 스토리지 자원을 효율적으로 활용할 수 있도록 도와줍니다. iscsi-initiator (client) 와 target (server or storage) 간의 설정을 통해 iSCSI 를 사용하여 스토리지를 관리하고 데이터를 전송할 수 있습니다.

본 매뉴얼은 Rocky Linux 9 환경 (IP : 192.168.10.2) 에서 테스트 후 작성되었습니다.

1. iSCSI 서버 설치

1) targetcli 패키지 설치

targetcli 패키지를 설치합니다.

# dnf -y install targetcli

서버 부팅시 데몬이 자동으로 실행될 수 있도록 하고, 현재 세션에서도 데몬을 가동 시킵니다.

# systemctl enable target
# systemctl start target

이미지 파일이 저장될 디렉토리를 생성합니다.

볼륨이 큰 파티션이나 추가 장치를 마운트 해서 연결해도 됩니다.

# mkdir /storage

2) iSCSI target 만들기

targetcli 에 진입하면 IQN, LUN 등의 생성 및 관리 작업을 할 수 있습니다.

# targetcli
Warning: Could not load preferences file /root/.targetcli/prefs.bin.
targetcli shell version 2.1.53
Copyright 2011-2013 by Datera, Inc and others.
For help on commands, type 'help'.

/> 

targetcli 에 진입하면 위와 같이 Warning 메세지를 볼 수 있는데, 별도의 사용자 환경 설정 파일을 생성하지 않아서 로드하지 못했다는 경고 메세지 입니다. 이 메시지는 문제를 일으키지 않으며, targetcli 의 기능에 지장을 주지 않습니다.

다음과 같이 1G 짜리 저장소 파일 (taget) 을 생성합니다.

형식) backstores/fileio create <backstore_fileio_이름> <이미지파일_전체_경로> <용량> <기록 방식>

/> backstores/fileio create disk01 /storage/1GB_image.img 1G write_back=false

Created fileio disk01 with size 1073741824

[ 스토리지 개체 생성 방식 ]

위 예시에서 이미 fileio 타입으로 파일을 생성했지만, 스토리지 개체를 생성하는 방식에는 두가지가 있으며 차이점은 아래와 같습니다.
- backstores/fileio : 파일을 사용하여 스토리지를 제공합니다. 이 방법은 이미지 파일이나 기존 파일 시스템을 사용하여 스토리지를 만들 수 있습니다. 파일 시스템 이미지 파일을 사용하면 가상의 블록 디바이스가 생성되어 iSCSI 타겟에 연결될 수 있습니다.
- backstores/block : 블록 장치 (파티션) 를 사용하여 스토리지를 제공합니다. 실제 블록 장치 (예: 하드 디스크) 나 루프백 장치를 사용하여 스토리지를 만들 수 있습니다. 블록 백스토어를 사용하면 블록 디바이스가 직접 iSCSI 타겟에 연결될 수 있습니다.

[ 쓰기 방식 ]

- write_back=true : 데이터를 메모리에 캐시한 후 비동기적으로 디스크에 기록합니다. 이는 성능을 향상시킬 수 있는 방식이지만, 시스템이 갑작스럽게 종료되는 경우 데이터 손실의 위험성이 있습니다.
- write_back=false : 데이터를 직접 디스크에 기록하며, 동기적인 방식으로 수행됩니다. 데이터의 일관성과 안정성이 보장됩니다. 그러나 성능은 약간 저하될 수 있습니다.

3) IQN 설정

IQN 은 반드시 형식에 맞게 작성해주어야 합니다.

형식) iqn.<연도>-<월>.<도메인 이름 역순>:<고유 이름>

/> iscsi/ create iqn.2023-06.kr.sysdocu:target01

Created target iqn.2023-06.kr.sysdocu:target01.
Created TPG 1.
Global pref auto_add_default_portal=true
Created default portal listening on all IPs (0.0.0.0), port 3260.

4) LUN 만들기

LUN (Logical Unit Number) 은 iSCSI target 에 연결된 논리적인 디스크 단위입니다.

LUN 을 만들기 위해 다음과 같이 명령을 실행합니다.

/> iscsi/iqn.2023-06.kr.sysdocu:target01/tpg1/luns create /backstores/fileio/disk01

Created LUN 0.

위 명령어는 target01 이라는 IQN 을 가진 target 의 TPG (Target Portal Group) 1 에 LUN 을 생성하고, 해당 LUN 을 /backstores/fileio/disk01 에 연결한다는 의미입니다.

5) IQN 의 ACL 생성

IQN ACL 을 생성하여 iSCSI 대상에 대한 액세스를 허용할 IQN 식별자를 명시적으로 지정합니다.

/> iscsi/iqn.2023-06.kr.sysdocu:target01/tpg1/acls create iqn.2023-06.kr.sysdocu:initiator01
Created Node ACL for iqn.2023-06.kr.sysdocu:initiator01
Created mapped LUN 0.

6) 계정 생성

target 에 계정을 생성하여 접근을 강화 할 수 있습니다.

본 항목을 건너뛰어도 Client 에서 마운트 가능하지만, Openshift 등 필요로 하는 곳이 있습니다.

계정 생성을 위해 target 의 initiator 로 이동합니다.

/> cd iscsi/iqn.2023-06.kr.sysdocu:target01/tpg1/acls/iqn.2023-06.kr.sysdocu:initiator01/

계정과 패스워드를 설정합니다.

/iscsi/iqn.20...u:initiator01> set auth userid=sysdocu
Parameter userid is now 'sysdocu'.
/iscsi/iqn.20...u:initiator01> set auth password=12345678
Parameter password is now '12345678'.

설정된 정보를 확인합니다.

/iscsi/iqn.20...u:initiator01> info
chap_password: 12345678
chap_userid: sysdocu
wwns:
iqn.2023-06.kr.sysdocu:initiator01

7) 정보 확인 및 저장

다음 명령어를 사용하여 생성한 IQN 과 LUN 정보를 확인할 수 있습니다.

/> ls iscsi/iqn.2023-06.kr.sysdocu:target01/tpg1/luns
o- luns .................................................................................................................. [LUNs: 1]
  o- lun0 .............................................................. [fileio/disk01 (/storage/1GB_image.img) (default_tg_pt_gp)]

그리고 exit 명령을 이용해 현재 상태를 저장하고 targetcli 를 빠져나갈 수 있습니다.

/> exit
Global pref auto_save_on_exit=true
Configuration saved to /etc/target/saveconfig.json

2. Client 에서 마운트 하기

1) client 패키지 설치

# yum install iscsi-initiator-utils  // CentOS

# apt-get install open-iscsi         // Ubuntu

2) iSCSI 시작

아래 파일에 IQN ACL 이름을 작성합니다.

# vi /etc/iscsi/initiatorname.iscsi

iscsi 와 iscsid 데몬이 시스템 부팅시 자동 구동되게 설정하고 현재 세션에서도 구동 합니다.

# systemctl enable iscsi

# systemctl enable iscsid

# systemctl start iscsi

# systemctl start iscsid

추후에 /etc/iscsi/initiatorname.iscsi 파일이 변경된 경우 iscsid 데몬을 재시작 해주어야 합니다.

3) Target 검색 및 연결

연결할 iSCSI Target 을 검색합니다.

# iscsiadm -m discovery -t st -p 192.168.10.2
192.168.10.2:3260,1 iqn.2023-06.kr.sysdocu:target01

iSCSI 장치를 연결합니다.

# iscsiadm -m node -T iqn.2023-06.kr.sysdocu:target01 -p 192.168.10.2:3260 -l

연결된 장치를 확인합니다.

# fdisk -l

...

Disk /dev/sda: 1 GiB, 1073741824 bytes, 2097152 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 8388608 bytes

4) 해제 방법

사용을 하지 않을때 해제하는 방법은 아래와 같습니다.

연결 명령 마지막 옵션 l 을 u 로만 바꾸면 됩니다.

# iscsiadm -m node -T iqn.2023-06.kr.sysdocu:target01 -p 192.168.10.2:3260 -u

Bot ID 와 Chat ID 를 알고 있는 상태라면 아래와 같이 간단히 보낼 수 있습니다.

# curl https://api.telegram.org/bot<Bot Token>/sendMessage -d "chat_id=<Chat ID>" -d "text=<보낼 메세지>"

OpenSSL 1.1.1 이상의 버전인지 확인하고 아닐 경우 addext 옵션 사용을 위해 업그레이들 해두면 좋습니다.

( https://sysdocu.tistory.com/1691 )

인증서 생성을 위해 아래 절차를 따릅니다.

# host_fqdn=www.sysdocu.kr
# cert_c="KR"                   // Country Name (C, 2 letter code)
# cert_s="Seoul"               // Certificate State (S)
# cert_l="Seoul"                // Certificate Locality (L)
# cert_o="Sysdocu"          // Certificate Organization (O)
# cert_ou="TechTeam"      // Certificate Organizational Unit (OU)
# cert_cn="${host_fqdn}"  // Certificate Common Name (CN)

미리 입력받은 변수값으로 인증서를 생성합니다.

생성할때 인증서 및 키 파일의 위치를 지정해줍니다.

# mkdir /root/ssl
# openssl req \
    -newkey rsa:4096 \
    -nodes \
    -sha256 \
    -keyout /root/ssl/sysdocu.key \
    -x509 \
    -days 365 \
    -out /root/ssl/sysdocu.crt \
    -addext "subjectAltName = DNS:${host_fqdn}" \
    -subj "/C=${cert_c}/ST=${cert_s}/L=${cert_l}/O=${cert_o}/OU=${cert_ou}/CN=${cert_cn}"

인증서 생성이 확인되었습니다.

# ll /root/ssl/
합계 12
-rw-r--r--. 1 root root 1952  4월  4 16:15 sysdocu.crt
-rw-------. 1 root root 1704  4월  4 16:15 sysdocu.key

리눅스 쉘에서 파일명앞에 - 가 붙어 있어 삭제하기 어려운 경우가 있었습니다.

명령 뒤에 따라오는 옵션으로 판단하고 삭제가 되지 않았던 것인데

알고보면 삭제 방법은 간단합니다.

-로 시작되는 파일 확인

# ls

-test.txt

삭제 실패 명령어들

# rm -test.txt
rm: 부적절한 옵션 -- 't'
Try 'rm ./-test.txt' to remove the file `-test.txt'.
Try 'rm --help' for more information.

# rm \-test.txt
rm: 부적절한 옵션 -- 't'
Try 'rm ./-test.txt' to remove the file `-test.txt'.
Try 'rm --help' for more information.

# rm '-test.txt'
rm: 부적절한 옵션 -- 't'
Try 'rm ./-test.txt' to remove the file `-test.txt'.
Try 'rm --help' for more information.

# rm "-test.txt"
rm: 부적절한 옵션 -- 't'
Try 'rm ./-test.txt' to remove the file `-test.txt'.
Try 'rm --help' for more information.

삭제 성공 명령어

디렉토리를 포함하여 삭제할 파일명을 지정하면 됩니다.

# rm ./-test.txt
rm: remove 일반 빈 파일 `./-test.txt'? y

*.sysdocu.kr 과 같이 여러개의 서브도메인 인증서를 각각 받지 말고 와일드카드 문자를 이용해 하나의 인증서만 발급받으면 관리가 편한 장점이 있습니다.

아래와 같이 간단하게 발급받을 수 있으며, 방법은 사용이 가능한 기본 도메인과 와일드카드 문자가 들어간 도메인을 같이 발급받으면 됩니다.

1. 설치

# yum -y install letsencrypt certbot

2. 발급

# certbot certonly --manual --preferred-challenges=dns -d sysdocu.kr -d "*.sysdocu.kr"

발급할때 도메인 주인이 맞는지 확인하는 과정이 나옵니다.

출력된 value 값을 DNS 에 TXT 형식으로 추가해 보라는 것입니다.

예)

Please deploy a DNS TXT record under the name:
_acme-challenge.sysdocu.kr.
with the following value:
e9s7AlTjBg9VN_H0eDfYLOiF6QvXiIZotAbWQ0EVibA

엔터를 치면 한개 더 해보라고 합니다.

(입력한 도메인이 두개라서 두번 요청하는 듯 보임)

예)

Please deploy a DNS TXT record under the name:
_acme-challenge.sysdocu.kr.
with the following value:
Ei0XXe8aAlzIyu_RQdQuk-qPmR1RxpHtuhYsAyHq05M

저는 네임서버가 bind 로 구성되어 있어 zone 파일에 아래와 같이 추가하고 데몬을 reload 하였습니다.

_acme-challenge.sysdocu.kr. IN TXT WMeM_AiR_OPKOo_8R8MxzSwnGAXktK8Q6mQbx-A5r_k
_acme-challenge.sysdocu.kr. IN TXT 6lEcqLN9LlomU23A28ycDsVSvezrEvRiidA5F7a2gHs

다시 발급화면으로 돌아가 엔터를 치면, 발급이 성공하였다는 메세지가 출력됩니다.

인증서는 아래 경로에 잘 저장이 된것을 확인하였습니다.

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/sysdocu.kr/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/sysdocu.kr/privkey.pem
This certificate expires on 2023-06-12.
These files will be updated when the certificate renews.

# ll /etc/letsencrypt/live/sysdocu.kr/
합계 4
-rw-r--r-- 1 root root 692  3월 14 14:17 README
lrwxrwxrwx 1 root root  34  3월 14 14:17 cert.pem -> ../../archive/sysdocu.kr/cert1.pem
lrwxrwxrwx 1 root root  35  3월 14 14:17 chain.pem -> ../../archive/sysdocu.kr/chain1.pem
lrwxrwxrwx 1 root root  39  3월 14 14:17 fullchain.pem -> ../../archive/sysdocu.kr/fullchain1.pem
lrwxrwxrwx 1 root root  37  3월 14 14:17 privkey.pem -> ../../archive/sysdocu.kr/privkey1.pem

# ll /etc/letsencrypt/archive/sysdocu.kr/
합계 20
-rw-r--r-- 1 root root 1846  3월 14 14:17 cert1.pem
-rw-r--r-- 1 root root 3749  3월 14 14:17 chain1.pem
-rw-r--r-- 1 root root 5595  3월 14 14:17 fullchain1.pem
-rw------- 1 root root 1704  3월 14 14:17 privkey1.pem

* 참고

갱신시 파일이름이 변경되므로 라이브 디렉토리 ( /etc/letsencrypt/live/sysdocu.kr/ ) 에 있는 인증서를

설정 등에 사용하시면 편리합니다.

* 참고

자동 갱신을 원할 경우 쉘스크립트를 만들고 아래 명령을 추가합니다.

certbot renew --quiet --no-self-upgrade

그리고 crond 등의 스케쥴러에 등록하여 사용하시면 됩니다.

인증서는 3개월 사용이 가능하며 만료 1개월 전부터 갱신이 가능하니

매월 보름간격으로 체크하도록 하면 문제없이 갱신이 됩니다.

0 0 1,16 * * root /root/ssl-renew.sh

아래는 run.sh 파일에서 master 라는 글자가 들어간 라인만 주석처리 하는 방법입니다.

# cat run.sh

# sed -i '/master/s/^/#/' run.sh

# cat run.sh