사막의 여우

CentOS7에서 GlusterFS 클러스터 노드 추가하기

사막의 여우 — Sun, 18 Oct 2020 20:30:21 +0900

blog post

GlusterFS(이하 GFS)는 브릭(Brick)이라 불리는 GFS 전용 디스크 파일시스템을 추가하여 볼륨 크기를 조절할 수 있습니다. 이러한 브릭은 단일 GFS 노드에서 추가할 수도 있고, 다중 노드에서 브릭을 클러스터링 하여 확장할 수도 있습니다.

이번 포스트에서는 디스크를 추가하기 위해 새로운 노드를 하나 더 생성하고, 브릭을 추가하여 기존 클라이언트에 마운트 된 디스크 크기를 확장해 보도록 하겠습니다.

1. 새로운 노드 구성

새로운 노드 (CentOS7)를 생성하고 해당 노드에서 아래 포스트의 1번 작업(GFS 서비스 구성하기)을 동일하게 진행합니다.

CentOS7에서 GlusterFS(GFS)를 활용하여 파일 시스템 마운트 하기

blog post GlusterFS (이하 GFS)는 네트워크 기반 파일 시스템으로, gfs 서버-클라이언트간 스토리지 마운트를 통한 파일 공유는 물론, 클러스터링 및 이중화 구성까지, 다양한 기능을 제공하는 스토리��

itguava.tistory.com

2. 브릭(Brick) 추가하기

새로 추가한 노드(서버2)의 호스트 정보를 아래와 같이 기존 서버/클라이언트 노드에서 추가해 줍니다.

//서버1 노드에서
[root@server ~]# vim /etc/hosts
192.168.0.11 server2
192.168.0.151 client

//클라이언트 노드에서
[root@client ~]# vim /etc/hosts
192.168.0.6 server
192.168.0.11 server2

기존 서버 노드에서 새로 추가한 server2 노드를 피어로 추가합니다.

[root@server gfs_disk]# gluster peer probe server2
peer probe: success.

피어 상태를 확인하면 클라이언트와 서버2 노드가 탐지됩니다.

[root@server gfs_disk]# gluster peer status
Number of Peers: 2

Hostname: client
Uuid: 98576d2f-abf0-4a52-ae4e-fc500b378ac3
State: Peer in Cluster (Connected)

Hostname: server2
Uuid: e5c46127-9f9b-4990-821a-b117aa5672a4
State: Peer in Cluster (Connected)

서버2 노드의 볼륨도 확인됩니다.

[root@server gfs_disk]# gluster volume info
 
Volume Name: gfs_volume
Type: Distribute
Volume ID: 27d23dd1-2b66-4352-a52d-999003a22cc1
Status: Started
Snapshot Count: 0
Number of Bricks: 1
Transport-type: tcp
Bricks:
Brick1: server:/home/gfs_disk
Options Reconfigured:
transport.address-family: inet
storage.fips-mode-rchecksum: on
nfs.disable: on
[root@server gfs_disk]# gluster volume info
 
Volume Name: gfs_volume
Type: Distribute
Volume ID: 27d23dd1-2b66-4352-a52d-999003a22cc1
Status: Started
Snapshot Count: 0
Number of Bricks: 1
Transport-type: tcp
Bricks:
Brick1: server:/home/gfs_disk
Options Reconfigured:
transport.address-family: inet
storage.fips-mode-rchecksum: on
nfs.disable: on

이제 서버2의 노드에서 공유된 브릭을 추가해줍니다. 이때 서버2에서 생성한 볼륨명(gfs_volume)과 해당 볼륨의 디스크 경로(server2:/home/gfs_disk)를 아래와 같이 본인이 생성한 노드 정보에 맞게 설정합니다.

* 참고: 만약 server2 노드에서 루트 파티션 상에 gfs 파티션을 생성하였을 경우, 경고와 함께 진행되지 않습니다. 아래와 같이 [force]옵션을 추가하여 강제로 볼륨을 생성할 수 있으나, 별도의 물리 디스크를 추가하여 파티셔닝 후 해당 파티션을 gfs 볼륨으로 사용할 것을 강력하게 권고합니다. 이번 예시에서는 별도 디스크에 마운트되지 않은 /home 디렉토리를 사용한 관계로, force를 사용했습니다.

[root@server ~]# gluster volume add-brick gfs_volume server2:/home/gfs_disk force
volume add-brick: success

볼륨정보를 확인해 보면, Brick이 두 개(Brick1, Brick2) 잡힌 것을 확인할 수 있습니다.

[root@server ~]# gluster volume info 
 
Volume Name: gfs_volume
Type: Distribute
Volume ID: 27d23dd1-2b66-4352-a52d-999003a22cc1
Status: Started
Snapshot Count: 0
Number of Bricks: 2
Transport-type: tcp
Bricks:
Brick1: server:/home/gfs_disk
Brick2: server2:/home/gfs_disk
Options Reconfigured:
transport.address-family: inet
storage.fips-mode-rchecksum: on
nfs.disable: on

볼륨 정보를 다시 리밸런싱해 줍니다.

[root@server ~]# gluster volume rebalance gfs_volume fix-layout start
volume rebalance: gfs_volume: success: Rebalance on gfs_volume has been started successfully. Use rebalance status command to check status of the rebalance process.
ID: 4730471f-015a-4a4a-b051-ff92ec6c92d1

볼륨 상태를 확인해보면 server2의 볼륨이 정상적으로 마운트된 것을 확인할 수 있습니다.

[root@server ~]# gluster volume status
Status of volume: gfs_volume
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick server:/home/gfs_disk                 49152     0          Y       85723
Brick server2:/home/gfs_disk                49152     0          Y       21621
 
Task Status of Volume gfs_volume
------------------------------------------------------------------------------
Task                 : Rebalance           
ID                   : 74a03d20-0d9f-44b2-9cfd-de16b1d18629
Status               : completed

3. 테스트

마지막으로 추가 마운트 한 디스크를 통해 파일 공유가 잘 진행되는지 확인해봅니다.

서버2 노드의 /home/gfs_disk 디렉토리에서 테스트 파일을 생성합니다.

[root@server2 gfs_disk]# touch test2.txt

클라이언트 노드에서 파일을 확인할 수 있습니다.

[root@client mnt]# ls
test2.txt

클라이언트에서 마운트된 서버의 disk 크기도 증가하는 것을 확인할 수 있습니다

//brick 추가 전
[root@client ~]# df -h
server:/gfs_volume       8.5G  6.6G  1.9G  78% /mnt

//brick 추가 후
[root@client mnt]# df -h
server:/gfs_volume        26G   17G  9.6G  64% /mnt

CentOS7에서 GlusterFS(GFS)를 활용하여 파일 시스템 마운트 하기

사막의 여우 — Sat, 3 Oct 2020 01:05:06 +0900

blog post

GlusterFS (이하 GFS)는 네트워크 기반 파일 시스템으로, gfs 서버-클라이언트간 스토리지 마운트를 통한 파일 공유는 물론, 클러스터링 및 이중화 구성까지, 다양한 기능을 제공하는 스토리지 도구입니다. 이러한 다양한 기능들을 지원하는 이유로 많은 클라우드 시스템에서 백엔드 스토리지 시스템으로 gfs를 활용하고 있습니다. 이번 포스트에서는 간단한 GFS 서버를 구축해보고, 클라이언트 리눅스에서 마운트하도록 구성해보겠습니다.

1. GFS 서비스 구성하기

* 참고: 아래 작업을 모든 GFS 노드에서 진행합니다.

gfs 설치를 위해 yum 레포지토리를 설치합니다.

[root@server ~]# yum install epel-release centos-release-gluster

설치된 gfs의 레포지토리를 활성화합니다.

[root@server ~]# sed -i -e "s/enabled=1/enabled=0/g" /etc/yum.repos.d/CentOS-Gluster-7.repo

glusterfs를 설치합니다.

[root@server ~]# yum --enablerepo=centos-gluster7,PowerTools -y install glusterfs-server

설치된 버전을 확인해봅니다.

[root@server ~]# gluster --version
glusterfs 7.7
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.

방화벽에서 glusterfs를 허용합니다.

[root@server ~]# firewall-cmd --add-service=glusterfs --permanent
success
[root@server ~]# firewall-cmd --reload
success

gluster 데몬을 실행합니다.

[root@server ~]# systemctl restart glusterd glusterfsd
[root@server ~]# systemctl enable glusterd glusterfsd

2. GFS 서버의 마운트

* 참고: 서버 노드(디스크를 제공할 노드)에서 아래 작업을 진행합니다.

서버노드에서 대상 노드 (클라이언트)를 탐색합니다.

[root@server gfs_disk]# gluster peer probe client
peer probe: success. 
[root@server gfs_disk]# gluster peer status
Number of Peers: 1

Hostname: client
Uuid: 98576d2f-abf0-4a52-ae4e-fc500b378ac3
State: Peer in Cluster (Connected)

클라이언트에서 마운트하여 사용할 gfs 전용 디렉토리를 생성합니다.

[root@server ~]# mkdir -p /home/gfs_disk

아래와 같이 gluster 명령을 사용하여 앞서 생성한 gfs_disk 디렉토리를 gfs 전용 볼륨으로 생성합니다.

* 참고: 만약 루트 파티션에 gfs 파티션을 생성할 경우, 경고와 함께 진행되지 않습니다. 아래와 같이 [force]옵션을 추가하여 강제로 볼륨을 생성할 수 있으나, 별도의 물리 디스크를 추가하여 파티셔닝 후 해당 파티션을 gfs 볼륨으로 사용할 것을 강력하게 권고합니다. 이번 예시에서는 별도 디스크에 마운트되지 않은 /home 디렉토리를 사용한 관계로, force를 사용했습니다.

[root@server home]# gluster volume create gfs_volume transport tcp server:/home/gfs_disk force
volume create: gfs_volume: success: please start the volume to access data

생성한 gfs_volume을 클라이언트에서 원격 마운트 하도록 볼륨 서비스를 시작합니다.

[root@server home]# gluster volume start gfs_volume
volume start: gfs_volume: success

생성된 볼륨 정보를 확인해 봅니다.

[root@server home]# gluster volume info
 
Volume Name: gfs_volume
Type: Distribute
Volume ID: 27d23dd1-2b66-4352-a52d-999003a22cc1
Status: Started
Snapshot Count: 0
Number of Bricks: 1
Transport-type: tcp
Bricks:
Brick1: server:/home/gfs_disk
Options Reconfigured:
transport.address-family: inet
storage.fips-mode-rchecksum: on
nfs.disable: on

3. GFS 클라이언트 구성하기

* 참고: 클라이언트 노드(디스크를 실제 사용할 노드)에서 아래 작업을 진행합니다.

gfs 서비스를 설치합니다.

[root@client ~]# yum --enablerepo=centos-gluster7 install glusterfs glusterfs-fuse

서버에서 생성한 gfs 볼륨(gfs_volume)을 클라이언트의 디렉토리 (/mnt)에 마운트합니다.

[root@client /]# mount -t glusterfs server:/gfs_volume /mnt

디스크 파티션을 확인해보면 정상적으로 서버의 볼륨을 마운트한 것을 확인할 수 있습니다.

[root@client /]# df -ha | grep server
server:/gfs_volume       8.5G  6.6G  1.9G  78% /mnt

4. 테스트

간단한 테스트를 해보겠습니다. 서버 노드의 gfs 디렉토리에 파일 하나를 생성해 봅니다.

[root@server ~]# touch /home/gfs_disk/testfile.sh

클라이언트 노드의 디렉토리(/mnt)에서도 testfile.sh 파일을 볼 수 있습니다.

[root@client ~]# ls /mnt/
testfile.sh

CentOS7에서 NTP 서버 구축으로 시간 동기화 하기

사막의 여우 — Wed, 30 Sep 2020 11:18:58 +0900

blog post

NTP (Network Time Protocol)는 pc와 pc 간 (혹은 서버-클라이언트 간) 시간을 동기화하기 위해 사용되는 프로토콜입니다. 시간 동기화를 하는 방법에는 클라이언트 pc가 직접 외부 시간에 클라이언트가 동기화할 수도 있고, 직접 NTP 서버를 구축하여 클라이언트가 서버의 시간에 동기화하도록 구성할 수도 있습니다. 이번 포스트에서는 간단한 NTP 서버를 구축하고 클라이언트가 이 NTP 서버에 시간을 동기화하도록 구성해 보도록 하겠습니다.

NTP 서버 구성

ntp 서버에서 시간 동기화를 위한 도구 (chrony)를 설치합니다.

[root@server ~]# yum install chrony

아래와 같이 기존 ntp 풀은 비활성화하고, 서버 역시 외부로부터 대한민국 표준시를 받아와야 하므로 kr 서버로 표준시를 동기화 하도록 설정합니다.

[root@server ~]# vim /etc/chrony.conf

# 기존 옵션 비활성화
#server 0.centos.pool.ntp.org iburst
#server 1.centos.pool.ntp.org iburst
#server 2.centos.pool.ntp.org iburst
#server 3.centos.pool.ntp.org iburst

# 대한민국 표준시로 ntp 동기화 설정
server 3.kr.pool.ntp.org
server 1.asia.pool.ntp.org
server 0.asia.pool.ntp.org

allow 192.168.0.0/24

...이하생략...

ntp 서비스 관련 방화벽을 허용합니다.

[root@server ~]# firewall-cmd --add-service=ntp --permanent
[root@server ~]# firewall-cmd --reload

chronyd 데몬을 재시작 후 sources 명령을 통해 동기화되고 있음을 확인할 수 있습니다.

[root@server ~]# systemctl restart chronyd
[root@server ~]# chronyc sources
210 Number of sources = 3
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^? 210.183.236.141               2   6     1     2    +71ms[  +71ms] +/-   42ms
^? 27.114.150.13                 2   6     1     2    +72ms[  +72ms] +/-  184ms
^? sh11.paina.net                2   6     1     3    +89ms[  +89ms] +/-  109ms

NTP 클라이언트 설정

클라이언트 역시 chrony 데몬을 설치합니다.

yum install chrony

클라이언트는 앞서 구축한 ntp 서버와 시간을 동기화 할 예정이므로, 우선 서버 호스트명을 지정합니다.

[root@client ~]# vim /etc/hosts
192.168.0.6 ntp-server

클라이언트에서도 마찬가지로 기존 chrony 시간 동기화 풀은 주석 처리하고, 앞서 설정한 ntp-server로 시간 동기화 서버를 지정합니다.

[root@client ~]# vim /etc/chrony.conf

# 기존 옵션 비활성화
#server 0.centos.pool.ntp.org iburst
#server 1.centos.pool.ntp.org iburst
#server 2.centos.pool.ntp.org iburst
#server 3.centos.pool.ntp.org iburst

# ntp-server와 시간 동기화
server ntp-server

데몬 재시작 후, 소스를 확인해보면 ntp-server로 잡힌 것을 확인할 수 있습니다.

[root@client ~]# systemctl restart chronyd
[root@client ~]# chronyc sources
210 Number of sources = 1
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^? ntp-server                    3   6     1     9   -217ms[ -217ms] +/-  140ms

[Kubernetes] minikube 대시보드 활성화 과정

사막의 여우 — Sun, 17 May 2020 21:12:23 +0900

blog post

이번 포스트는 이전 포스트에 이어서, 설치한 minikube를 기반으로 대시보드를 구축해 보겠습니다. 대시보드에서도 약간의 삽질 과정이 있어서 따로 다뤄보았습니다. 이전 포스트가 궁금하신 분들은 아래 포스트를 보고 오시기 바랍니다.

[Kubernetes] 첫 시작. Minikube 설치 삽질 과정 (feat. docker)

blog post 오픈스택을 멀티 노드로 구성하는 과정에서 간단한 테스트 용 컨테이너가 필요하여 도커를 구축해 보기로 하였습니다. 단순히 도커만 설치하는 것이 아니라 쿠버네티스도 사용해 볼 겸,

itguava.tistory.com

이전 포스트에서 첫 minikube 설치를 마치고 아래와 같이 대시보드를 실행해보니 에러가 발생했습니다.

[user@Compute0 /]$ minikube dashboard
* 대시보드를 활성화하는 중 ...
* 
* [DASHBOARD_ROLE_REF] Unable to enable dashboard run callbacks: running callbacks: [sudo KUBECONFIG=/var/lib/minikube/kubeconfig /var/lib/minikube/binaries/
v1.18.2/kubectl apply -f /etc/kubernetes/addons/dashboard-ns.yaml -f /etc/kubernetes/addons/dashboard-clusterrole.yaml -f /etc/kubernetes/addons/dashboard-cl
usterrolebinding.yaml -f /etc/kubernetes/addons/dashboard-configmap.yaml -f /etc/kubernetes/addons/dashboard-dp.yaml -f /etc/kubernetes/addons/dashboard-role
.yaml -f /etc/kubernetes/addons/dashboard-rolebinding.yaml -f /etc/kubernetes/addons/dashboard-sa.yaml -f /etc/kubernetes/addons/dashboard-secret.yaml -f /et
c/kubernetes/addons/dashboard-svc.yaml: Process exited with status 1
stdout:
namespace/kubernetes-dashboard unchanged
clusterrole.rbac.authorization.k8s.io/kubernetes-dashboard unchanged
configmap/kubernetes-dashboard-settings unchanged
deployment.apps/dashboard-metrics-scraper unchanged
deployment.apps/kubernetes-dashboard unchanged
role.rbac.authorization.k8s.io/kubernetes-dashboard unchanged
rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard unchanged
serviceaccount/kubernetes-dashboard unchanged
secret/kubernetes-dashboard-certs unchanged
secret/kubernetes-dashboard-csrf unchanged
secret/kubernetes-dashboard-key-holder unchanged
service/kubernetes-dashboard unchanged
service/dashboard-metrics-scraper unchanged

stderr:
The ClusterRoleBinding "kubernetes-dashboard" is invalid: roleRef: Invalid value: rbac.RoleRef{APIGroup:"rbac.authorization.k8s.io", Kind:"ClusterRole", Name
:"cluster-admin"}: cannot change roleRef
]
* Suggestion: Run: 'kubectl delete clusterrolebinding kubernetes-dashboard'
* Related issue: https://github.com/kubernetes/minikube/issues/7256

쿠버네티스가 좋은 점은, 오픈스택과 달리 에러가 발생하면 추천 명령어를 제시하네요. (이런건 오픈스택도 배워야할듯,,_) 위의 제안대로 쿠버네티스 대시보드의 clusterrolebinding을 제거해 보았습니다.

[user@Compute0 /]$ kubectl delete clusterrolebinding kubernetes-dashboard
clusterrolebinding.rbac.authorization.k8s.io "kubernetes-dashboard" deleted

하지만 여전히 minikube 에드온 상황을 보니 dashboard가 활성화되어 있지 않았습니다.

[user@Compute0 /]$ minikube addons list
|-----------------------------|----------|--------------|
|         ADDON NAME          | PROFILE  |    STATUS    |
|-----------------------------|----------|--------------|
| dashboard                   | minikube | disabled     |
| default-storageclass        | minikube | enabled ✅   |
| efk                         | minikube | disabled     |
| freshpod                    | minikube | disabled     |
| gvisor                      | minikube | disabled     |
| helm-tiller                 | minikube | disabled     |
| ingress                     | minikube | disabled     |
| ingress-dns                 | minikube | disabled     |
| istio                       | minikube | disabled     |
| istio-provisioner           | minikube | disabled     |
| logviewer                   | minikube | disabled     |
| metallb                     | minikube | disabled     |
| metrics-server              | minikube | disabled     |
| nvidia-driver-installer     | minikube | disabled     |
| nvidia-gpu-device-plugin    | minikube | disabled     |
| registry                    | minikube | disabled     |
| registry-aliases            | minikube | disabled     |
| registry-creds              | minikube | disabled     |
| storage-provisioner         | minikube | enabled ✅   |
| storage-provisioner-gluster | minikube | disabled     |
|-----------------------------|----------|--------------|

minikube 명령어 옵션을 보니 addon을 enable 할 수 있는 명령이 있는것을 발견하여 활성화 해주었습니다.

[user@Compute0 /]$ minikube addons enable dashboard
* The 'dashboard' addon is enabled

다시 확인해보니 활성화 되었네요.

[user@Compute0 /]$ minikube addons list
|-----------------------------|----------|--------------|
|         ADDON NAME          | PROFILE  |    STATUS    |
|-----------------------------|----------|--------------|
| dashboard                   | minikube | enabled ✅  |
| default-storageclass        | minikube | enabled ✅  |
| efk                         | minikube | disabled     |
| freshpod                    | minikube | disabled     |
| gvisor                      | minikube | disabled     |
| helm-tiller                 | minikube | disabled     |
| ingress                     | minikube | disabled     |
| ingress-dns                 | minikube | disabled     |
| istio                       | minikube | disabled     |
| istio-provisioner           | minikube | disabled     |
| logviewer                   | minikube | disabled     |
| metallb                     | minikube | disabled     |
| metrics-server              | minikube | disabled     |
| nvidia-driver-installer     | minikube | disabled     |
| nvidia-gpu-device-plugin    | minikube | disabled     |
| registry                    | minikube | disabled     |
| registry-aliases            | minikube | disabled     |
| registry-creds              | minikube | disabled     |
| storage-provisioner         | minikube | enabled ✅   |
| storage-provisioner-gluster | minikube | disabled     |
|-----------------------------|----------|--------------|

다시 대시보드로 접속을 시도해 보았으나 이번엔 proxy에서 행이 걸리는 문제가 발생했습니다.

[user@Compute0 /]$ minikube dashboard                                                                                                                      
* Verifying dashboard health ...
* 프록시를 시작하는 중 ...
* Verifying proxy health ...
* Opening http://127.0.0.1:41668/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/ in your default browser...
^C

일단 이 상태에서 lynx 명령을 사용하여 위의 url로 접속해보니 로컬로 접속은 되는 것으로 보이지만, 외부에서 192.168.0.25 (이 호스트의 Ip)로 접근하려고 하면 여전히 접근이 안됩니다. 아마도 쿠버네티스 자체에서 외부 접근 ip는 막은 것으로 예상하여 열심히 구글링을 해 본 결과, 아래와 같이 proxy 설정을 하면 된다고 하네요.

[user@Compute0 /]$ kubectl proxy --address='0.0.0.0' --disable-filter=true
W0517 19:06:56.197172   14394 proxy.go:167] Request filter disabled, your proxy is vulnerable to XSRF attacks, please be cautious
Starting to serve on [::]:8001

또 저 상태에서 그냥 행이 걸립니다. (쿠버네티스는 행 걸린 상태가 그냥 동작 한다는 의미인가..? 왜 다 저 상태로 두는지 이해가 안됨. 아니면 비정상적인 상황인지도 의문이네요)

어찌됐든, 이 상태에서 앞서 minikube dashboard 명령을 통해 받은 url에 Ip만 적용하여 접속해보니 접속이 되네요.

http://<자신의 external ip>:8001/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/

그리고 위의 proxy 가 동작하는 상태에서 ctrl+c로 종료하면 저 대시보드도 종료됩니다 (왜 이렇게 만들었는지 참,, 오픈스택처럼 그냥 외부에서 접속할 수 있도록 따로 설정이 있으면 어떨까 하는 생각이 듦)

대시보드 접속 과정은 여기까지 입니다. 크게 어려운 내용은 없지만 처음 시도하는 과정에서 외부 접근을 위해 proxy 설정 부분에서 애를 먹었네요. 다음 포스트에서는 본격적으로 컨테이너를 생성하고 devstack을 설치하는 과정을 다뤄보도록 하겠습니다. 물론 개인적으로 실험적인 내용이라 잘 될지는 모르겠네요.

[Kubernetes] 첫 시작. Minikube 설치 삽질 과정 (feat. docker)

사막의 여우 — Sun, 17 May 2020 17:10:48 +0900

blog post

오픈스택을 멀티 노드로 구성하는 과정에서 간단한 테스트 용 컨테이너가 필요하여 도커를 구축해 보기로 하였습니다. 단순히 도커만 설치하는 것이 아니라 쿠버네티스도 사용해 볼 겸, 도커 드라이버를 사용하는 쿠버네티스 시스템을 구축해 보기로 했습니다. 마침 쿠버네티스 구축에 대해 알아보니 minikube라 불리는 테스트용 쿠버네티스 서비스가 있는 것을 발견하여 이를 활용해 보기로 했습니다. 그런데 막상 실제 문서를 참고하여 진행해보니 기존 매뉴얼 및 블로그의 설명과 실제 운영 환경에서의 차이가 있어보이네요. 처음 진행하는 과정에서 저처럼 어려움을 겪고 계신 분들이 계시다면 이 글을 포함하여 앞으로 진행할 내용들이 조금이나마 도움이 되길 바랍니다.

현재 저는 아래와 같은 환경에서 진행합니다.

CentOS7 Linux 3.10.0-1062.4.1.el7.x86_64
Memory 8G, CPU 2core, SSD 256GB
Network: 192.168.0.25/24.
현재 오픈스택의 컴퓨트노드로 활용중이며, KVM 기반 VM이 2대 동작 중

참고로 최종 목표는 쿠버네티스에서 도커 기반 컨테이너를 생성하고 그 위에 devstack을 설치해 보는 것입니다.

우선 다음과 같이 kubectl이라고 불리는 쿠버네티스 클라이언트 릴리즈 버전을 받아오고,,

[root@Compute0 bin]# curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl

kubectl 파일의 소유권을 설정한 후에 /usr/local/bin/ 디렉토리로 옮겨줍니다.

[root@Compute0 bin]# chmod +x ./kubectl
[root@Compute0 bin]# mv ./kubectl /usr/local/bin/kubectl

다음으로 쿠버네티스 레포지토리를 설정해 주고,,

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

클라이언트를 설치합니다.

[root@Compute0 bin]# yum install kubernetes-client
[root@Compute0 bin]# curl -Lo minikube https://storage.googleapis.com/minikube/releases/v0.29.0/minikube-linux-amd64  && chmod +x minikube  && sudo cp minikube /usr/local/bin/  && rm minikube

버전을 확인해보면 1.10.1 버전으로 동작하는 중이라는 것을 알 수 있습니다.

[root@Compute0 root]$ minikube version
minikube version: v1.10.1
commit: 63ab801ac27e5742ae442ce36dff7877dcccb278

minikube의 vm 드라이버를 도커로 설정하기 위해 필요한 도커 패키지를 설치하고,,

[root@Compute0 bin]# yum install docker-ce docker-ce-cli containerd.io

--vm-driver 옵션을 사용하여 아래와 같이 실행해보니 일반 유저로 해야한다고 한다고 하네요.

[root@Compute0 root]# minikube start --vm-driver=docker

그래서 일반 사용자로 전환하여 아래와 같이 다시 실행해보니 이번엔 docker group에 사용자 (아마도 현재 로그인한 'user')를 추가하려면 권한이 있어야 한다고 하며 usermod를 사용할 것을 제안합니다.

[user@Compute0 root]$ minikube start --vm-driver=docker
   Centos 7.7.1908 위의 minikube v1.10.1
✨  유저 환경 설정 정보에 기반하여 docker 드라이버를 사용하는 중

❗  'docker' 드라이버가 다음 이슈를 기록하였습니다: "docker version --format {{.Server.Os}}-{{.Server.Version}}" exit status 1: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.40/version: dial unix /var/run/docker.sock: connect: permission denied
   Suggestion: Add your user to the 'docker' group: 'sudo usermod -aG docker $USER && newgrp docker'
   문서: https://docs.docker.com/engine/install/linux-postinstall/

   Failed to validate 'docker' driver

아래와 같이 도커의 제안대로 usermod를 사용하여 권한 변경해보았고

[user@Compute0 root]$ sudo usermod -aG docker $USER && newgrp docker

다시 해보니 실행해보니 실행이 되는 것처럼 보입니다.

[user@Compute0 root]$ minikube start --vm-driver=docker
   Centos 7.7.1908 위의 minikube v1.10.1
✨  유저 환경 설정 정보에 기반하여 docker 드라이버를 사용하는 중
   Starting control plane node minikube in cluster minikube
   Pulling base image ...
   Downloading Kubernetes v1.18.2 preload ...
    > preloaded-images-k8s-v3-v1.18.2-docker-overlay2-amd64.tar.lz4: 525.43 MiB

위의 로그에 이어 도커 컨데이너를 생성하고 쿠버네티스가 팟을 생성하는 것처럼 보이네요.

   Creating docker container (CPUs=2, Memory=2200MB) ...
   쿠버네티스 v1.18.2 을 Docker 19.03.2 런타임으로 설치하는 중
    ▪ kubeadm.pod-network-cidr=10.244.0.0/16
   Verifying Kubernetes components...
   Enabled addons: default-storageclass, storage-provisioner
   끝났습니다! 이제 kubectl 이 "minikube" 를 사용할 수 있도록 설정되었습니다

쿠버네티스 상태를 확인해 보면 아래와 같이 구성된 것을 볼 수 있습니다.

[user@Compute0 root]$ minikube status
minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

여기까지가 저의 첫 쿠버네티스 minicube 설치 과정입니다. 이어서 다음 포스트에서도 대시보드를 설치하고 컨테이너를 생성하는 과정을 다루도록 하겠습니다.

Stein 오픈스택 클라우드 서버 구축(16) - Neutron 기반 Service Function Chaining (SFC) 기능 추가하기

사막의 여우 — Wed, 13 May 2020 21:47:08 +0900

blog post

오픈스택에서 네트워킹 기능을 전담하는 컴포넌트로 Neutron이 있습니다. Public & Private 네트워크 구성부터 서브네팅, 라우터, DHCP, 패킷 포워딩 등, 다양한 기능을 수행하죠. 하지만 Neutron의 기능은 이게 끝이 아닙니다. 기본 기능에서 확장하여 추가 기능들을 사용할 수 있습니다. 아래 링크에서 보시면 어떠한 추가 기능들이 있는지 대략적으로 살펴볼 수 있습니다.

OpenStack Docs: Configuration

docs.openstack.org

이번 포스트에서는 Neutron을 확장하여 Service Function Chaining(이하 SFC)으로 불리는 기능을 추가해 보도록 하겠습니다. 참고로, 오픈스택 클라우드 시스템을 운영하는 과정에 있어 반드시 필요한 기능은 아니기 때문에 꼭 설치할 필요는 없는 기능입니다.

SFC의 개념 및 활용 방법에 관해서는 별도의 포스트로 다루도록 하고, 이번 포스트에서는 설치와 세팅에 집중하도록 하겠습니다.

* 참고: 현재 아래 설정을 토대로 Stein 버전에서 sfc를 시도해 본 결과, 체이닝 룰이 제대로 적용되지 않는 것으로 보입니다. 실행 테스트를 진행 중에 있으며, 결과에 대해 추후에 다시 포스팅하도록 하겠습니다. 아래 설정은 오픈스택 공식 문서를 바탕으로 작성하였으며, 참고만 바랍니다.

컨트롤러 노드

컨트롤러 노드에서 우선 패키지를 설치합니다.

[root@Controller ~]# yum install https://cbs.centos.org/kojifiles/packages/python-networking-sfc/8.0.0/1.el7/noarch/python2-networking-sfc-8.0.0-1.el7.noarch.rpm

neutron.conf에서 아래와 같이 설정해 줍니다.

[root@Controller ~]# vim /etc/neutron/neutron.conf
[DEFAULT]

//아래 옵션에서 2개의 플러그인 추가
service_plugins = flow_classifier,sfc

...기타 옵션 생략...

// 아래 항목 전체 추가
[sfc]
drivers = ovs

[flowclassifier]
drivers = ovs

서비스를 재시작 해 줍니다.

[root@Controller ~]# systemctl restart neutron-server

DB 데이터도 동기화해 줍니다.

[root@Controller ~]# neutron-db-manage --subproject networking-sfc upgrade head

컴퓨트 노드 설정

아래와 같이 ml2에서 확장 agent로 sfc를 추가해 줍니다.

[root@Compute0 ~]# vim /etc/neutron/plugins/ml2/ml2_conf.ini
[agent]
extensions = sfc

다음으로 openvswitch 서비스를 재시작해줍니다.

[root@Compute0 ~]# systemctl restart neutron-openvswitch-agent

SFC 설정은 여기까지 입니다.

[Openstack] 잘못된 ovs 브릿지 인터페이스 설정으로 인해 시스템 재부팅 후 네트워크가 단절된 문제 해결

사막의 여우 — Wed, 13 May 2020 21:31:01 +0900

blog post

이 문제는 오픈스택의 네트워크 노드 재부팅 후 발생한 문제로, openvswitch(이하 ovs)의 기술적 문제라기 보다는 사실 관리자의 시스템 설정 실수에 가깝습니다. 지난 밤에 예상치 못하게 전원이 내려가는 바람에 시스템을 재부팅하게 되었습니다. 대부분 노드가 정상적으로 부팅되었으나, 네트워크 노드에 ssh 연결이 되지 않았습니다. 간단한 문제였지만 상황에 대해 정리해 두기 위해 포스팅합니다.

상황

우선 시스템 터미널로 직접 들어가 봅니다. 역시나 ping은 게이트웨이까지도 가지 않는 상황입니다.

[root@Network ~]# ping 8.8.8.8
...반응없음...

ip, 게이트웨이 정보도 잘 잡혀있습니다.

[root@Network ~]# ifconfig eno16777736
eno16777736: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.27  netmask 255.255.255.0  broadcast 0.0.0.0
        inet6 ...  prefixlen 64  scopeid 0x20<link>
        ether ...  txqueuelen 1000  (Ethernet)
        RX packets 22543  bytes 3005069 (2.8 MiB)
        RX errors 0  dropped 34  overruns 0  frame 0
        TX packets 17005  bytes 3007077 (2.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
[root@Network ~]#
[root@Network ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eno33554976
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eno33554976

혹시나 브릿지나 ovs에 바인딩되어 있는지(네트워크 설정을 구성한지 좀 오래돼서 정확히 기억이 나지 않는 상황) 확인해봅니다.

[root@Network ~]# ovs-vsctl show
...생략...
 Bridge "br-eth1"
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port "phy-br-eth1"
            Interface "phy-br-eth1"
                type: patch
                options: {peer="int-br-eth1"}
        Port "br-eth1"
            Interface "br-eth1"
                type: internal
        Port "eno16777736"
            Interface "eno16777736"
    ovs_version: "2.11.0"

문제를 찾았습니다. eno16777736인터페이스가 br-eth1에 바인딩 되어 있는 것을 볼 수 있습니다.

문제는 아래와 같이, 현재 network 스크립트를 통해 eno16777736 인터페이스에 ip 및 게이트웨이를 할당받도록 설정되어 있었고,

[root@Network ~]# vim /etc/sysconfig/network-scripts/ifcfg-eno16777736
TYPE="Ethernet"
BOOTPROTO="static"
NAME="eno16777736"
DEVICE="eno16777736"
ONBOOT="yes"
IPADDR="192.168.0.27"
PREFIX="24"
GATEWAY="192.168.0.1"
DNS1="8.8.8.8"

ovs 브릿지(br-eth1)도 리눅스 인터페이스에서 다운되어 있던 상황이었습니다.

[root@Network ~]# ip link
...생략...
12: br-eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:0c:29:2b:2e:4c brd ff:ff:ff:ff:ff:ff

해결

우선 eno16777736 물리 인터페이스의 ip, gateway, dns 정보를 제거했습니다. 왜냐하면 바인딩한 브릿지가 직접 ip를 할당받아야 하기 때문입니다.

[root@Network ~]# vim /etc/sysconfig/network-scripts/ifcfg-eno16777736
TYPE="Ethernet"
BOOTPROTO="static"
NAME="eno16777736"
DEVICE="eno16777736"
ONBOOT="yes"

다음으로 재부팅 후 자동으로 브릿지 인터페이스를 활성화 할 수 있도록 아래와 같이 스크립트를 하나 작성했습니다.

[root@Network ~]# vim /var/tmp/create_interface.sh
#!/bin/bash

ip link set up br-eth1
ip addr add 192.168.0.27/24 dev br-eth1
route add default gw 192.168.0.1 dev br-eth1
echo "nameserver 8.8.8.8" > /etc/resolv.conf

시스템에서 스크립트를 사용할 수 있도록 권한을 변경해 주었고,

[root@Network ~]# chmod 755 /var/tmp/create_interface.sh

스크립트를 부팅 과정에서 실행해 주도록 했습니다. 다만 물리 인터페이스가 올라온 후에 ovs 브릿지 인터페이스를 활성화 해 주기 위해 set_interface라는 systemd 서비스 스크립트를 작성하여 systemd를 통해 스크립트가 실행되도록 했습니다.

[root@Network ~]# vim /etc/systemd/system/set_interface.service
[Unit]
Description=Description for sample script goes here
After=network.target

[Service]
Type=simple
ExecStart=/var/tmp/create_interface.sh
TimeoutStartSec=0

[Install]
WantedBy=default.target

마지막으로 이 서비스를 활성화 해주고 재부팅해 보았습니다.

[root@Network ~]# systemctl enable set_interface
[root@Network ~]# shutdown -r now

정상적으로 ovs 브릿지 인터페이스가 ip를 할당받은 것을 볼 수 있습니다.

[root@Network ~]# ifconfig
br-eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.27  netmask 255.255.255.0  broadcast 0.0.0.0
        inet6 ...  prefixlen 64  scopeid 0x20<link>
        ether ...  txqueuelen 1000  (Ethernet)
        RX packets 26436  bytes 3524796 (3.3 MiB)
        RX errors 0  dropped 316  overruns 0  frame 0
        TX packets 19324  bytes 3468697 (3.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eno16777736: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 ...  prefixlen 64  scopeid 0x20<link>
        ether ...  txqueuelen 1000  (Ethernet)
        RX packets 2179769  bytes 1653637286 (1.5 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 19353  bytes 3558987 (3.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        
...생략...

[root@Network ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 br-eth1
10.0.0.0        0.0.0.0         255.255.255.0   U     101    0        0 eno33554976
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 br-eth1

[Openstack] 시스템 재부팅 후 대시보드 접속 불가 문제

사막의 여우 — Wed, 13 May 2020 18:56:56 +0900

blog post

Controller 노드 시스템 재부팅 후 dashboard 접속을 시도해보니 연결이 되지 않는 문제가 발생하였습니다.

httpd 로그를 확인해 보았으나,,

[Wed May 13 18:19:42.814169 2020] [suexec:notice] [pid 3772] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Wed May 13 18:19:42.815253 2020] [ssl:warn] [pid 3772] AH01906: RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Wed May 13 18:19:42.873645 2020] [lbmethod_heartbeat:notice] [pid 3772] AH02282: No slotmem from mod_heartmonitor
[Wed May 13 18:19:42.875085 2020] [ssl:warn] [pid 3772] AH01906: RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Wed May 13 18:19:42.875165 2020] [ssl:warn] [pid 3772] AH02292: Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)
[Wed May 13 18:19:42.903273 2020] [mpm_prefork:notice] [pid 3772] AH00163: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips mod_wsgi/3.4 Python/2.7.5 configured -- resuming normal operations
[Wed May 13 18:19:42.903314 2020] [core:notice] [pid 3772] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'

경고성 메시지 외에는 별다른 문제를 찾지 못했습니다. 다음으로 네트워크에 문제가 있는것으로 보고 패킷을 떠본 결과,

[root@Controller ~]# tcpdump -i eno16777736 port 443                                                                                                         
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno16777736, link-type EN10MB (Ethernet), capture size 262144 bytes
18:40:46.264345 IP ec2-54-227-239-17.compute-1.amazonaws.com.https > 192.168.0.30.51345: Flags [P.], seq 3289390902:3289391162, ack 851732253, win 336, optio
ns [nop,nop,TS val 2636456577 ecr 190860862], length 260
18:40:46.264352 IP 192.168.0.30.51345 > ec2-54-227-239-17.compute-1.amazonaws.com.https: Flags [.], ack 260, win 2043, options [nop,nop,TS val 190869664 ecr 
2636456577], length 0
18:40:46.769590 IP 192.168.0.30.50973 > 17.248.161.48.https: Flags [P.], seq 3791151273:3791151455, ack 3335606655, win 2048, options [nop,nop,TS val 1908701
66 ecr 1207587178], length 182
18:40:46.769641 IP 192.168.0.30.50973 > 17.248.161.48.https: Flags [P.], seq 182:1237, ack 1, win 2048, options [nop,nop,TS val 190870166 ecr 1207587178], le
ngth 1055
18:40:46.769753 IP 192.168.0.30.50973 > 17.248.161.48.https: Flags [P.], seq 1237:2292, ack 1, win 2048, options [nop,nop,TS val 190870166 ecr 1207587178], l
ength 1055
18:40:46.769925 IP 192.168.0.30.50973 > 17.248.161.48.https: Flags [P.], seq 2292:2949, ack 1, win 2048, options [nop,nop,TS val 190870166 ecr 1207587178], l
ength 657
...생략...

192.168.0.30(개인PC)에서 들어오는 패킷은 보이지만 26에서의 응답 패킷이 보이지 않았습니다. 이를 통해 firewall 문제를 예상해보고 확인해보니,,

[root@Controller ~]# firewall-cmd --list-ports
11211/tcp 5672/tcp 5000/tcp 9292/tcp 6080/tcp 6081/tcp 6082/tcp 8774/tcp 8775/tcp 8778/tcp 9696/tcp 5900-5999/tcp

443 포트가 차단되어 있는 것을 알 수 있었고, 아래와 같이 포트를 허용하여 해결할 수 있었습니다.

[root@Controller ~]# firewall-cmd --add-port=443/tcp --permanent
success
[root@Controller ~]# firewall-cmd --reload
success

[Openstack ] 오픈스택 VPNaaS 환경 구성 과정에서 발생한 Max retries exceeded with url 에러 메시지 출력 문제

사막의 여우 — Wed, 13 May 2020 02:10:39 +0900

blog post

VPNaaS를 구성하는 과정에서, 앞서 발생한 인스턴스의 네트워킹 문제를 해결하니 또 다른 문제가 발생하였습니다. 이번 포스트를 통해 이 이슈를 해결(?)하는 과정을 기록해 둡니다. 혹시 비슷한 현상을 겪고 있는 분들에게 도움이 되길 바랍니다.

상황

openstack vpn 관련 명령어를 입력하니 다음과 같이 "...Max retries exceeded with url..." 관련 메시지가 출력되기 시작했습니다.

[root@Controller img]# openstack vpn ike policy list
Unable to establish connection to http://10.0.0.26:9696/v2.0/vpn/ikepolicies: HTTPConnectionPool(host='10.0.0.26', port=9696): Max retries exceeded with url:
 /v2.0/vpn/ikepolicies (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fbe085c6d90>: Failed to establish a new connection: [Er
rno 111] \xec\x97\xb0\xea\xb2\xb0\xec\x9d\xb4 \xea\xb1\xb0\xeb\xb6\x80\xeb\x90\xa8',))

컨트롤러 노드에서 neutron-server 재시작도 불가능한 상황에 처했고,,

[root@Controller neutron]# systemctl restart network-server
Failed to restart network-server.service: Unit not found.

journalctl로 실시간 메시지를 확인해보니 역시나, 연신 에러 메시지를 뿜어내고 있었습니다.

[root@Controller neutron]# journalctl -f
-- Logs begin at 금 2019-11-29 02:44:41 KST. --
 5월 12 23:32:51 Controller neutron-server[104365]: /usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py:22: PkgResourcesDeprecationWarning: Parameters 
to load are deprecated.  Call .resolve and .require separately.
 5월 12 23:32:51 Controller neutron-server[104365]: return pkg_resources.EntryPoint.parse("x=" + s).load(False)
 5월 12 23:32:52 Controller neutron-server[104365]: Delete associated vpnservices ['309a23df-a1de-4273-906f-0d2f3a875fa8'] before removing providers [u'opens
wan'].
 5월 12 23:32:52 Controller systemd[1]: neutron-server.service: main process exited, code=exited, status=1/FAILURE
 5월 12 23:32:52 Controller systemd[1]: Failed to start OpenStack Neutron Server.
 5월 12 23:32:52 Controller systemd[1]: Unit neutron-server.service entered failed state.
 5월 12 23:32:52 Controller systemd[1]: neutron-server.service failed.
 5월 12 23:32:52 Controller systemd[1]: neutron-server.service holdoff time over, scheduling restart.
 5월 12 23:32:52 Controller systemd[1]: Stopped OpenStack Neutron Server.
 5월 12 23:32:52 Controller systemd[1]: Starting OpenStack Neutron Server...
 5월 12 23:32:54 Controller neutron-server[104384]: /usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py:22: PkgResourcesDeprecationWarning: Parameters 
to load are deprecated.  Call .resolve and .require separately.
 5월 12 23:32:54 Controller neutron-server[104384]: return pkg_resources.EntryPoint.parse("x=" + s).load(False)
 5월 12 23:32:54 Controller neutron-server[104384]: Delete associated vpnservices ['309a23df-a1de-4273-906f-0d2f3a875fa8'] before removing providers [u'opens
wan'].
 5월 12 23:32:55 Controller systemd[1]: neutron-server.service: main process exited, code=exited, status=1/FAILURE
 5월 12 23:32:55 Controller systemd[1]: Failed to start OpenStack Neutron Server.
 5월 12 23:32:55 Controller systemd[1]: Unit neutron-server.service entered failed state.
 5월 12 23:32:55 Controller systemd[1]: neutron-server.service failed.
 5월 12 23:32:55 Controller systemd[1]: neutron-server.service holdoff time over, scheduling restart.
 5월 12 23:32:55 Controller systemd[1]: Stopped OpenStack Neutron Server.
 5월 12 23:32:55 Controller systemd[1]: Starting OpenStack Neutron Server...
 5월 12 23:32:56 Controller neutron-server[104401]: /usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py:22: PkgResourcesDeprecationWarning: Parameters 
to load are deprecated.  Call .resolve and .require separately.

해결

우선 위에서 journalctl 메시지를 통해 vpn 서비스 설정에 문제가 있다는 것은 확인할 수 있었습니다. 따라서 neutron_vpnaas.conf, neutron.conf 설정 파일에 문제가 없는지 검토하기 시작했습니다.

역시 문제는 설정에 있었습니다. neutron_vpnaas.conf 파일을 확인해 보니 아래와 같이 설정되어 있었습니다.

[service_providers]
service_provider = VPN:strongswan:neutron_vpnaas.services.vpn.service_drivers.ipsec.IPsecVPNDriver:default

오픈스택 문서를 확인해보니 RHEL계열은 openswan을 쓴다고 하네요. 그래서 아래와 같이 바꿔줬습니다.

[service_providers]
service_provider = VPN:openswan:neutron_vpnaas.services.vpn.service_drivers.ipsec.IPsecVPNDriver:default

이후 neutron-server를 재시작 해주니 별다른 에러 없이 잘 동작하는 것을 볼 수 있었습니다.

이상으로 트러블 슈팅이라고 말하기도 부끄러운 트러블 슈팅 과정을 마칩니다,,

[Openstack ] 오픈스택 VPNaaS 환경 구성 과정에서 발생한 get_vpn_services_on_host 에러 메시지 출력 문제

사막의 여우 — Wed, 13 May 2020 00:02:11 +0900

blog post

이 포스트는 openstack vpnaas 설정 중에 발생한 문제를 해결하는 과정을 기록한 글입니다. 해결 방법이 100% 확실한 방법은 아닌 만큼, 혹시 참고하시는 분들이 계시다면 꼭 단순 참고용으로만 봐주시기 바랍니다.

상황

오픈스택에 vpnaas 서비스 설치 후, 동작중이던 인스턴스의 네트워크가 단절되는 상황이 발생했습니다. 일단 ping이 게이트웨이 10.10.0.1로도 가지 않는 것으로 보아, 라우터 쪽 문제로 예상되었습니다.

아래와 같이 네트워크 노드에서 ip netns로 확인결과 갑자기 router 네임스페이스가 사라졌습니다...(?)

[root@Network neutron]# ip netns
qdhcp-585040c0-8dea-43f0-ba73-001955f59ce1 (id: 2)
qdhcp-b7fc4869-1e35-4d34-9f84-2a66b6d3c984 (id: 0)
ns1

바로 로그를 확인해 보았고, 아래와 같이 에러 로그가 주기적으로 발생하는 것을 볼 수 있었습니다. 정확한 원인 파악은 어려우나, get_vpn_services_on_host 메시지로 보아, vpn에 문제가 있는 건 확실해 보였습니다.

2020-05-12 23:03:14.396 100151 ERROR neutron_lib.rpc [-] Timeout in RPC method get_vpn_services_on_host. Waiting for 55 seconds before next attempt. If the server is not down, consider increasing the rpc_response_timeout option as Neutron server(s) may be overloaded and unable to respond quickly enough.: MessagingTimeout: Timed out waiting for a reply to message ID 7b0b7e6e47014ec7b14f9885b66850b5
2020-05-12 23:03:14.396 100151 WARNING neutron_lib.rpc [-] Increasing timeout for get_vpn_services_on_host calls to 120 seconds. Restart the agent to restore it to the default value.: MessagingTimeout: Timed out waiting for a reply to message ID 7b0b7e6e47014ec7b14f9885b66850b5
2020-05-12 23:03:38.404 100151 ERROR neutron.agent.l3.agent [-] Failed reporting state!: MessagingTimeout: Timed out waiting for a reply to message ID 8a0d222588bb4499871bfaab94b6335e
2020-05-12 23:03:38.404 100151 ERROR neutron.agent.l3.agent Traceback (most recent call last):
2020-05-12 23:03:38.404 100151 ERROR neutron.agent.l3.agent   File "/usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py", line 913, in _report_state
2020-05-12 23:03:38.404 100151 ERROR neutron.agent.l3.agent     True)
2020-05-12 23:03:38.404 100151 ERROR neutron.agent.l3.agent   File "/usr/lib/python2.7/site-packages/neutron/agent/rpc.py", line 101, in report_state
2020-05-12 23:03:38.404 100151 ERROR neutron.agent.l3.agent     return method(context, 'report_state', **kwargs)
2020-05-12 23:03:38.404 100151 ERROR neutron.agent.l3.agent   File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/client.py", line 178, in call
2020-05-12 23:03:38.404 100151 ERROR neutron.agent.l3.agent     retry=self.retry)
...생략...

해결

1. 우선 Controller노드에서 "openstack vpn" 관련 생성한 "ipsec, ike" 목록은 전부 제거 후 다시 neutron-server, neutron-l3-agent 재시작 조치를 취해보았으나 여전히 위의 메시지가 주기적으로 발생하였습니다.

2. 2차적으로 설정 파일 (neutron_vpnaas.conf, neutron.conf)의 옵션 설정을 검사해보았으나, 별다른 문제는 보이지 않았습니다.

3. 마지막으로 설정 파일 및 openstack vpnaas 패키지를 전부 제거하였습니다. 이후 vpnaas 패키지를 컨트롤러 노드에만 설치하고 옵션을 재설정 해보았습니다. neutron-server, neutron-l3-agent 재시작한 결과, 에러 메시지가 사라졌습니다.

[root@Network neutron]# tail -f /var/log/neutron/l3-agent.log                                                                                                
2020-05-12 23:35:18.752 102422 INFO oslo.privsep.daemon [-] privsep daemon starting
2020-05-12 23:35:18.755 102422 INFO oslo.privsep.daemon [-] privsep process running with uid/gid: 0/0
2020-05-12 23:35:18.756 102422 INFO oslo.privsep.daemon [-] privsep process running with capabilities (eff/prm/inh): CAP_DAC_OVERRIDE|CAP_DAC_READ_SEARCH|CAP_NET_ADMIN|CAP_SYS_ADMIN/CAP_DAC_OVERRIDE|CAP_DAC_READ_SEARCH|CAP_NET_ADMIN|CAP_SYS_ADMIN/none
2020-05-12 23:35:18.757 102422 INFO oslo.privsep.daemon [-] privsep daemon running as pid 102422
2020-05-12 23:35:20.664 102382 INFO neutron.agent.l3.agent [-] Starting router update for 700c5054-6612-477a-970c-f3f7eebbaea6, action 3, priority 2, update_id 6f64e165-d6ca-48dc-863d-36ccbeb79829. Wait time elapsed: 0.000
2020-05-12 23:35:20.988 102382 INFO oslo_rootwrap.client [-] Spawned new rootwrap daemon process with pid=102427
2020-05-12 23:35:22.595 102382 INFO neutron.agent.l3.agent [-] Finished a router update for 700c5054-6612-477a-970c-f3f7eebbaea6, update_id 6f64e165-d6ca-48dc-863d-36ccbeb79829. Time elapsed: 1.931
2020-05-12 23:35:42.892 102382 INFO neutron.agent.l3.agent [-] Agent has just been revived. Doing a full sync.
2020-05-12 23:35:59.241 102382 INFO neutron.agent.l3.agent [-] Starting router update for 700c5054-6612-477a-970c-f3f7eebbaea6, action 3, priority 2, update_id db09717d-d8e4-4532-adf1-25521ea32560. Wait time elapsed: 0.000
2020-05-12 23:35:59.397 102382 INFO neutron.agent.l3.agent [-] Finished a router update for 700c5054-6612-477a-970c-f3f7eebbaea6, update_id db09717d-d8e4-4532-adf1-25521ea32560. Time elapsed: 0.156

아마도 Controller, Network 노드에 모두 vpnaas 패키지를 설치했던 것이 서로 충돌이 나지 않았나 예상해봅니다.