Stein 오픈스택 클라우드 서버 구축(12) - NFS,LVM 기반 다중 블록 스토리지 노드 구성하기 (Feat. GlusterFS, GFS)

blog post 

 

 

이번 포스트에서는 지난 포스트에서 구축했던 LVM 기반 블록 스토리지 노드에 NFS 백엔드를 추가하여 멀티 블록 스토리지 노드를 구성해 보겠습니다. 포스트 마지막에는 Cinder와 GlusterFS 문제에 대해서도 간단하게 짚고 포스팅을 마치도록 하겠습니다.

 

관련 포스트: Stein 오픈스택 클라우드 서버 구축(11) - LVM으로 블록 스토리지 구성하기

 

 

 

NFS 개념 및 전체 구성

 

 

 NFS(Network File System)는 물리적으로 떨어져 있는 파일 시스템에 외부에서 원격으로 접근할 수 있도록 하는 네트워크 프로토콜이자 서비스입니다. 아래 그림과 같이 NFS 서버가 동작중인 장치의 디렉토리를 클라이언트에서 마운트 하여 사용할 수 있습니다.

 

 

오픈스택의 Cinder 서비스는 LVM 뿐만 아니라, 이러한 NFS를 통해서도 볼륨 서비스를 제공할 수 있도록 기능을 제공하고 있습니다. Cinder를 통해 NFS 단독으로 스토리지를 구성할 수 있고, LVM과 함께 멀티 백엔드로 구성할 수도 있습니다. 또 같은 스토리지 서버 내에서 동작하도록 구축할 수도 있고 노드를 분리하여 구성할 수도 있습니다.

 

본 포스트에서는 이러한 Cinder 기능을 활용하여 기존 LVM 블록스토리지와 연동함으로써, 아래와 같이 다중 백엔드, 블록 스토리지를 구성해 보도록 하겠습니다.

 

 

 

다중 노드로 구성하기 위해 NFS 백엔드 스토리지 전용 노드 (10.0.0.29 서버)가 추가되며, 해당 노드는 cinder와 같은 오픈스택 관련 서비스 없이 nfs 기반의 저장 공간을 제공하는 노드로 운영됩니다. 여기에서 그림과 같이 /nfs 디렉토리는 기존 스토리지 노드의 mnt_nfs 디렉토리로 마운트 되어 구축될 예정입니다.

 

 

 

NFS 서버 구성

 

 

nfs-utils를 설치합니다.

 

[root@Storage-nfs ~]# yum install nfs-utils

 

/etc/exports 파일에 볼륨을 제공할 디렉토리/허용 네트워크 혹은 특정 ip/접근 권한을 설정해 줍니다.

 

[root@Storage-nfs /]# vim /etc/exports

/nfs 10.0.0.0/24(rw,no_root_squash)

 

nfs 디렉토리 주요 접근 권한 리스트

• ro: 마운트 된 볼륨의 데이터를 읽기만 가능
• rw: 마운트 된 볼륨에 쓰기도 가능
• no_root_squash: 루트 자격이 있어야 쓰기 가능
• noaccess: 디렉토리 접근 불가

기타 자세한 사항은 레드햇 공식 문서를 참고 바랍니다:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/deployment_guide/s1-nfs-server-config-exports

 

 

 

nfs-server 관련 서비스를 시작합니다.

 

[root@Storage-nfs /]# systemctl start rpcbind nfs-server
[root@Storage-nfs /]# systemctl enable rpcbind nfs-server

 

 

방화벽을 사용중이라면, nfs 서비스를 허용해 줍니다.

 

[root@Storage-nfs nfs]# firewall-cmd --add-service=nfs --permanent                                                                                                                
success
[root@Storage-nfs nfs]# firewall-cmd --reload
success

 

 

 

 

 

스토리지 노드 구성

 

 

nfs-utils를 설치합니다.

 

[root@Storage ~]# yum install nfs-utils

 

 

cinder.conf 파일에서 아래와 같이 적용해 줍니다.

 

[root@Storage ~]# vim /etc/cinder/cinder.conf

# 기존 enabled_backends 옵션에 nfs를 추가합니다.
enabled_backends = lvm,nfs

# ... 생략 ...

# 아래 섹션 전체를 가장 하단에 추가해 줍니다,.
[nfs]
volume_driver = cinder.volume.drivers.nfs.NfsDriver
volume_backend_name = NFS
nfs_shares_config = /etc/cinder/nfs_shares
nfs_mount_point_base = $state_path/mnt_nfs

아래와 같이 nfs_shares 파일에 실제 볼륨이 마운트 될 서버의 디렉토리 정보를 입력해 줍니다.

 

[root@Storage ~]# vi /etc/cinder/nfs_shares

Storage-nfs:/nfs

 

 

아래와 같이 nfs 관련 파일의 권한을 수정하고 볼륨 서비스를 재시작해 줍니다.

 

[root@Storage ~]# chmod 640 /etc/cinder/nfs_shares
[root@Storage ~]# chgrp cinder /etc/cinder/nfs_shares 
[root@Storage ~]# systemctl restart openstack-cinder-volume
[root@Storage ~]# chown -R cinder. /var/lib/cinder/mnt_nfs

 

 

 

컴퓨트 노드 구성

 

 

컴퓨트 노드 역시 nfs 유틸을 설치해 줍니다.

 

[root@Compute0 ~]# yum install nfs-utils

 

기존 LVM에 멀티노드로 구성하는 경우라면 아래는 이미 저장되어 있으므로 진행할 필요는 없습니다. nfs만 구성하는 경우는 아래 정보를 입력해 줍니다.

 

[root@Compute0 ~]# vim /etc/nova/nova.conf

[cinder]
os_region_name = RegionOne

 

전체 구축은 마쳤습니다. 다음으로 nfs 시스템이 잘 구축되었는지 확인해 보도록 하겠습니다.

 

 

 

확인

 

 

컨트롤러 노드에서 볼륨 서비스 리스트를 확인해 봅니다. 아래와 같이 Storage@nfs 호스트가 추가되고 enabled, up 상태라면 정상적으로 시스템이 구축되었다고 볼 수 있습니다.

 

[root@Controller ~]# openstack volume service list
+------------------+-------------+------+---------+-------+----------------------------+
| Binary           | Host        | Zone | Status  | State | Updated At                 |
+------------------+-------------+------+---------+-------+----------------------------+
| cinder-scheduler | Controller  | nova | enabled | up    | 2020-04-13T03:43:41.000000 |
| cinder-volume    | Storage@lvm | nova | enabled | up    | 2020-04-13T03:43:40.000000 |
| cinder-volume    | Storage@nfs | nova | enabled | up    | 2020-04-13T03:43:46.000000 |
+------------------+-------------+------+---------+-------+----------------------------+

 

 

다음으로 실제로 nfs 기능이 잘 동작하는지도 확인해보겠습니다.

 

여기에서 실제로 다중 백엔드 스토리지가 잘 동작하는지 확인하는 것이 다소 애매합니다. 오픈스택 foundation 및 다른 블로그에서는 volume의 'type'을 만들어서 테스트하곤 하지만, 해당 방법으로는 실제로 nfs 디렉토리에 디스크 볼륨이 잘 저장되는지 확인하기 어렵습니다. 왜냐하면 type을 아무리 lvm, nfs로 생성하더라도, 기본 저장 공간인 lvm 스토리지에 여유 공간이 있으면, 1차적으로 모든 볼륨은 lvm으로 생성됩니다.

 

 

 

따라서 저는 약간의 편법을 사용하여 기존 LVM의 물리적으로 저장할 수 있는 최대 공간(현재 저의 경우 35GB)에 가득 차도록 35GB 디스크(disk1)를 생성하고, 여기에서 추가 볼륨(disk2)을 생성하여 2번째 디스크가 nfs 볼륨으로 자동으로 저장되는지 확인해 보았습니다.

 

아래와 같이 우선 두개의 35GB 볼륨 (disk1, disk2)을 생성합니다. 생성된 볼륨 id를 잘 확인해 둡니다.

 

[root@Controller ~]# openstack volume create --size 35 disk1
[root@Controller ~]# openstack volume create --size 35 disk2
[root@Controller ~]# openstack volume list
+--------------------------------------+-------+-----------+------+-------------+
| ID                                   | Name  | Status    | Size | Attached to |
+--------------------------------------+-------+-----------+------+-------------+
| 0d5b20c6-f98f-4869-8d92-aa784b474765 | disk2 | available |   35 |             |
| 8c23a355-3831-49b1-82b7-8edce0fc9932 | disk1 | available |   35 |             |
+--------------------------------------+-------+-----------+------+-------------+

 

 

우선 lvdisplay 명령을 통해 생성된 볼륨 정보를 확인해 봅니다. 

볼륨 명을 확인해 보니 disk1의 볼륨인 것을 확인할 수 있습니다. 즉 disk1은 35GB로 LVM으로 마운트 되었고, 볼륨 그룹(centos)의 최대 공간(35GB)을 전부 할당받았음을 확인할 수 있습니다.

 

또한 볼륨 그룹(vgdisplay)를 보면 여유공간(Free)이 없는 것을 볼 수 있습니다.

 

[root@Controller ~]# vgdisplay
  --- Volume group ---
  VG Name               centos
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  3
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               2
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               39.51 GiB
  PE Size               4.00 MiB
  Total PE              10114
  Alloc PE / Size       10103 / 39.46 GiB
  Free  PE / Size       11 / 44.00 MiB
  VG UUID               0He2RT-LewY-Ruvd-deEZ-Yy0Q-F8ZC-bqKudb

[root@Storage ~]# lvdisplay

--- Logical volume ---
  LV Path                /dev/centos/volume-8c23a355-3831-49b1-82b7-8edce0fc9932
  LV Name                volume-8c23a355-3831-49b1-82b7-8edce0fc9932
  VG Name                centos
  LV UUID                dPheVC-fOz6-Fv0M-7ewj-u1rH-rD4f-0QeCw8
  LV Write Access        read/write
  LV Creation host, time Storage, 2020-04-13 12:50:35 +0900
  LV Pool name           centos-pool
  LV Status              available
  # open                 0
  LV Size                35.00 GiB
  Mapped size            0.00%
  Current LE             8960
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     8192
  Block device           253:8

 

다음으로 우리가 cinder.conf에서 지정했던 nfs 마운트 디렉토리(mnt_nfs)를 살펴보겠습니다.

 

아래와 같이 디렉토리(9ef36e681fa6cbdcb502346b8cd02f91)가 생성되었고, 그 안에 볼륨이 저장된 것을 확인할 수 있습니다. 앞서 disk2의 id와 같은 것으로 보아, 해당 볼륨이 disk2 볼륨 파일인 것을 알 수 있습니다.

 

[root@Storage ~]# ls /var/lib/cinder/mnt_nfs
9ef36e681fa6cbdcb502346b8cd02f91
[root@Storage ~]# ls /var/lib/cinder/mnt_nfs/9ef36e681fa6cbdcb502346b8cd02f91/
volume-0d5b20c6-f98f-4869-8d92-aa784b474765

 

마지막으로 위의 마운트 디렉토리(mnt_nfs)의 실제 물리 공간인 Storage-nfs 장비에서 /nfs 디렉토리를 확인해보면 아래와 같이 볼륨 파일이 저장된 것을 확인할 수 있습니다. 이로써 nfs가 정상 동작하고 있음을 확인할 수 있습니다.

 

[root@Storage-nfs ~]# ls /nfs
volume-0d5b20c6-f98f-4869-8d92-aa784b474765

 

GlusterFS에 관하여

 

 

 

마지막으로 GlusterFS(이하 GFS)에 관해서 잠시 언급하고 포스팅을 마치도록 하겠습니다.

현재 오픈스택 Stein 버전을 기준으로, Cinder에서 GFS 사용을 시도해보면 아래와 같이 모듈을 찾을 수 없다는 에러가 발생합니다.

 

2020-04-13 00:56:05.298 127946 ERROR cinder.cmd.volume [req-caf14883-7bd9-4312-8111-25a3b80ae206 - - - - -] Volume service Storage@glusterfs failed to start.: ImportError: No module named glusterfs
2020-04-13 00:56:05.298 127946 ERROR cinder.cmd.volume Traceback (most recent call last):
2020-04-13 00:56:05.298 127946 ERROR cinder.cmd.volume   File "/usr/lib/python2.7/site-packages/cinder/cmd/volume.py", line 104, in _launch_service
2020-04-13 00:56:05.298 127946 ERROR cinder.cmd.volume     cluster=cluster)
2020-04-13 00:56:05.298 127946 ERROR cinder.cmd.volume   File "/usr/lib/python2.7/site-packages/cinder/service.py", line 400, in create
2020-04-13 00:56:05.298 127946 ERROR cinder.cmd.volume     cluster=cluster, **kwargs)
2020-04-13 00:56:05.298 127946 ERROR cinder.cmd.volume   File "/usr/lib/python2.7/site-packages/cinder/service.py", line 155, in __init__
2020-04-13 00:56:05.298 127946 ERROR cinder.cmd.volume     *args, **kwargs)
2020-04-13 00:56:05.298 127946 ERROR cinder.cmd.volume   File "/usr/lib/python2.7/site-packages/cinder/volume/manager.py", line 269, in __init__
2020-04-13 00:56:05.298 127946 ERROR cinder.cmd.volume     active_backend_id=curr_active_backend_id)
2020-04-13 00:56:05.298 127946 ERROR cinder.cmd.volume   File "/usr/lib/python2.7/site-packages/oslo_utils/importutils.py", line 44, in import_object
2020-04-13 00:56:05.298 127946 ERROR cinder.cmd.volume     return import_class(import_str)(*args, **kwargs)
2020-04-13 00:56:05.298 127946 ERROR cinder.cmd.volume   File "/usr/lib/python2.7/site-packages/oslo_utils/importutils.py", line 30, in import_class
2020-04-13 00:56:05.298 127946 ERROR cinder.cmd.volume     __import__(mod_str)
2020-04-13 00:56:05.298 127946 ERROR cinder.cmd.volume ImportError: No module named glusterfs
2020-04-13 00:56:05.298 127946 ERROR cinder.cmd.volume

 

위의 문제가 발생한 이유는 현재 Cinder 서비스가 GFS 지원을 중단했기 때문으로 보입니다. 아래 GFS 공식 문서에서도 이에 대해 언급하고 있습니다.

 

https://docs.gluster.org/en/latest/Administrator%20Guide/GlusterFS%20Cinder/ 

 

오픈스택 Ocata 버전부터 Cinder에서 빠진다는 내용을 볼 수 있습니다. 혹시나 GFS로 블록 스토리지 구축을 계획하고 계신다면 이 부분을 꼭 참고하시기 바랍니다.