RHOCP) OpenShift Logging (3) - 영구 스토리지(PV) 구성

INTRO

이전 글에서 Openshift Logging을 설치하는 작업을 하였습니다.

RHOCP) OpenShift Logging (2) - Operator 설치

Storage를 임시 볼륨인 EmptyDir로 설정하였기 때문에 수집되는 정보들이 Pod가 삭제되면 사라지게 되는 현상이 발생하였습니다. 이 글에서는 데이터를 영구적으로 저장하기 위해 Openshift Logging에 대한 영구 스토리지를 구성하는 내용을 소개드립니다.

자세한 내용은 아래의 문서를 참고바랍니다.

Configuring the log store - Configuring your Logging deployment | Logging | OpenShift Container Platform 4.13

추가적으로 이 과정을 진행하면서 문제 없이 진행하기 위해서 Kubernetes Volume, Storage class 등의 볼륨에 대한 내용을 인지하고 있어야 합니다.

퍼시스턴트 볼륨

스토리지 클래스

동적 볼륨 프로비저닝

 

 

 

Openshift Logging에 대한 영구 스토리지(Persistent Volume) 구성

이전에 생성한 Openshift Logging의 Instance yaml 파일에서 storage를 수정합니다.

아래의 EmptyDir 설정에서 Storage class를 이용하여 영구 볼륨을 동적으로 생성할 수 있게 변경하였습니다.

<EmptyDir>
apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
# ...
spec:
  logStore:
    type: "elasticsearch"
    elasticsearch:
      nodeCount: 3
      storage: {}


<영구 스토리지>
apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
# ...
spec:
  logStore:
    type: "elasticsearch"
    elasticsearch:
      nodeCount: 3
      storage:
        storageClassName: "olo-csi"
        size: "200G"

 수정한 내용을 반영하기 위해 인스턴스를 삭제하고 재생성합니다.

# oc delete -f olo-instance.yaml

# oc create -f olo-instance.yaml


<Openshift Logging Instance 상태 확인>
# oc get pod -n openshift-logging -o wide
NAME                                            READY   STATUS      RESTARTS   AGE     IP             NODE                       NOMINATED NODE   READINESS GATES
cluster-logging-operator-6f7d96cfb5-mz8hr       1/1     Running     0          4h15m   10.131.0.52    worker2.ocp4.example.com   <none>           <none>
collector-29wbx                                 2/2     Running     0          3h51m   10.128.2.135   worker1.ocp4.example.com   <none>           <none>
collector-4lj9w                                 2/2     Running     0          3h51m   10.130.0.60    master3.ocp4.example.com   <none>           <none>
collector-5mg44                                 2/2     Running     0          3h51m   10.131.2.44    infra3.ocp4.example.com    <none>           <none>
collector-5pfwm                                 2/2     Running     0          3h51m   10.130.3.51    infra2.ocp4.example.com    <none>           <none>
collector-b2cq4                                 2/2     Running     0          3h51m   10.129.2.44    infra1.ocp4.example.com    <none>           <none>
collector-l48l4                                 2/2     Running     0          3h51m   10.129.0.91    master1.ocp4.example.com   <none>           <none>
collector-p2z6n                                 2/2     Running     0          3h51m   10.131.0.57    worker2.ocp4.example.com   <none>           <none>
collector-sfm6c                                 2/2     Running     0          3h51m   10.128.0.66    master2.ocp4.example.com   <none>           <none>
elasticsearch-cdm-3vqyxcvy-1-5f5c9f47bb-hlc2s   2/2     Running     0          3h51m   10.130.3.50    infra2.ocp4.example.com    <none>           <none>
elasticsearch-cdm-3vqyxcvy-2-5cc7d94979-bp6nw   2/2     Running     0          3h51m   10.129.2.43    infra1.ocp4.example.com    <none>           <none>
elasticsearch-cdm-3vqyxcvy-3-7646cd7bcb-77gbw   2/2     Running     0          3h51m   10.131.2.43    infra3.ocp4.example.com    <none>           <none>
elasticsearch-im-app-28183095-c7d7w             0/1     Completed   0          4m29s   10.130.3.95    infra2.ocp4.example.com    <none>           <none>
elasticsearch-im-audit-28183095-sxg8d           0/1     Completed   0          4m29s   10.130.3.94    infra2.ocp4.example.com    <none>           <none>
elasticsearch-im-infra-28183095-j7288           0/1     Completed   0          4m29s   10.130.3.96    infra2.ocp4.example.com    <none>           <none>
kibana-6f8f4bdc67-htwtb                         2/2     Running     0          3h51m   10.130.3.49    infra2.ocp4.example.com    <none>           <none>

실행중인 Pod가 PV를 잘 만들어서 사용하고있는지 확인합니다.

# oc get pvc -n openshift-logging
NAME                                         STATUS   VOLUME                                     CAPACITY      ACCESS MODES   STORAGECLASS   AGE
elasticsearch-elasticsearch-cdm-3vqyxcvy-1   Bound    pvc-a56542a7-d69a-4a67-8dd3-c67047ffebac   195312500Ki   RWO            olo-csi        3h56m
elasticsearch-elasticsearch-cdm-3vqyxcvy-2   Bound    pvc-5f713caa-28ae-49fa-9480-f8fe0127ffad   195312500Ki   RWO            olo-csi        3h56m
elasticsearch-elasticsearch-cdm-3vqyxcvy-3   Bound    pvc-3ba83135-52d8-467e-8d48-06fe0ea73df6   195312500Ki   RWO            olo-csi        3h56m

# oc get pv -n openshift-logging
NAME                                       CAPACITY      ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                                          STORAGECLASS   REASON   AGE
pvc-3ba83135-52d8-467e-8d48-06fe0ea73df6   195312500Ki   RWO            Delete           Bound    openshift-logging/elasticsearch-elasticsearch-cdm-3vqyxcvy-3   olo-csi                 3h53m
pvc-5f713caa-28ae-49fa-9480-f8fe0127ffad   195312500Ki   RWO            Delete           Bound    openshift-logging/elasticsearch-elasticsearch-cdm-3vqyxcvy-2   olo-csi                 3h53m
pvc-a56542a7-d69a-4a67-8dd3-c67047ffebac   195312500Ki   RWO            Delete           Bound    openshift-logging/elasticsearch-elasticsearch-cdm-3vqyxcvy-1   olo-csi                 3h53m


<PV 저장 확인>
# ls -l /data/pv
total 0
drwxrwsr-x 3 root 1000680000 27 Aug  2 19:28 pvc-3ba83135-52d8-467e-8d48-06fe0ea73df6
drwxrwsr-x 3 root 1000680000 27 Aug  2 19:28 pvc-5f713caa-28ae-49fa-9480-f8fe0127ffad
drwxrwsr-x 3 root 1000680000 27 Aug  2 19:28 pvc-a56542a7-d69a-4a67-8dd3-c67047ffebac

 

 

 

 

Openshift Logging에 대한 PV를 NFS로 사용하면 안되는 이유

Redhat Openshift Documents 내용을 참고하면 NFS를 이용하여 Volume or Persistent Volume을 생성하여 Elasticsearch storage를 사용하는 것을 데이터 손상 등에 대한 이유로 권장하지 않는다고 기록되어 있습니다.

https://docs.openshift.com/container-platform/4.13/logging/config/cluster-logging-log-store.html#cluster-logging-elasticsearch-storage_cluster-logging-store

 

이에 대한 개인적인 생각을 아래에 적어보겠습니다.

- 리눅스 서버에서 Local Storage에서 NFS 공유:  IOPS 이슈 발생 가능성 높음

- NAS 이용한 NFS 공유:  성능이 좋은 스토리지라면 IOPS 이슈가 크게 발생하지 않을 것이라고 생각하지만 용도에 맞지 않기도 하고 RW가 많이 일어나는 서비스이기 때문에 권장하지 않음

- iSCSI 및 SAN을 이용한 공유:  Fibre Channel을 이용하여 LUN을 받아오기 때문에 IOPS 이슈는 거의 없음 (가장 좋은 방법)

 

추가로 Elasticsearch Community에서 토론한 내용들이 보이네요.

Does elasticsearch not support nfs as data directory?