Minio SNSD on Kubernetes (2/2)

2024.07.04 - [MLOps/MinIO] - Minio SNSD on Kubernetes (1/2)

Minio SNSD on Kubernetes (1/2)

이전 글에 이어, File Server는 Web UI에서 사용하는 것을 가정했기 때문에 속도(10Mb/s 이상)가 중요했습니다. 이번에는 SNSD 설치 과정에서 겪은 시행착오에 대해 작성하고 SNSD(File Server)는 마무리 하도록 하겠습니다. 

---

데이터의 안정성을 위해 두 개의 디스크 드라이브에 똑같은 내용을 1대1 복사하여 백업 용도로 저장하고자 했고, 운영안정성을 위해 두 개의 서버를 사용하고자 했다.

처음에는 2 Server 2 Disk 방법을 시도했으나..

첫번째 (Single Node Multi Drive)

minio server /data1 /data2

첫번째 구성안

 각 서버에 동일한 Pod(2개의 드라이버가 포함된 MinIO서버 실행)가 동작할 수 있도록 Statefulset의 replicas를 2로 설정하고 시도했었지만 쿠버네티스 환경에 익숙하지 않아서, *PV에서 에러가 계속 발생했다.

*PVC가 Bound는 되는데, pod 로그를 찍어보면 연결이 안된다는 오류가 났다.

 

이런저런 검색과 고민 끝에 지금 yaml 설정으로는 Server 1에서 Server 2의 디스크를 읽을 수 없고, Server 2에서는 Server 1의 디스크를 읽을 수 없는 상황이라 판단하고, Server 2의 디스크를 Server 1에 Mount하여 PV 값 변경 후 쿠버네티스에 apply 했다.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-server-1
  namespace: minio-file
spec:
  capacity:
    storage: 1Ti
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  local:
    path: /mnt/minio-file-1
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
                - server1
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-server-2
  namespace: minio-file
spec:
  capacity:
    storage: 1Ti
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  local:
    path: /mnt/minio-file-2
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
                - server2

첫번째 해결 방법 적용 결과

 

이렇게 하니, 실행은 되었지만 하나의 서버에 여러 요청이 몰리게 되면 속도가 저하되지 않을까? ( 실제로 이 시점에 두 건이상의 업로드와 다운로드를 걸었을때, 속도 저하 현상을 확인했었고 당시에는 이게 맞다고 생각했다. ) 두 개의 서버로 부하를 분산해야 되지 않을까? 하는 생각에 MNMD를 다시 시도했다.

 

두번째 (Multi Node Multi Disk)

두번째 방법 구성안

MNMD에서는 모든 PV 타입을 아래와 같이 NFS로 변경하였고, Statefulset의 args도 아래와 같이 설정했다.

# server-{1...3}
apiVersion: v1
kind: PersistentVolume
metadata:
  name: server-1
  namespace: minio-file
spec:
  capacity:
    storage: 1000Gi
  accessModes:
    - ReadWriteOnce
  nfs:
    path: /mnt/minio_file-{1...3}
    server: server{1...3} ip

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: minio
  labels:
     app: minio
spec:
  selector:
    matchLabels:
      app: minio
  serviceName: minio
  replicas: 3
  template:
    metadata:
      labels:
        app: minio
    spec:
      containers:
      - name: minio
        image: minio/minio:latest
        args:
        - server
        - http://minio-{0...2}.minio.default.svc.cluster.local/data
        ports:
        - containerPort: 9000
        volumeMounts:
        - name: data
          mountPath: /data
  volumeClaimTemplates:
  - metadata:
      name: data
      namespace: minio-file
    spec:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 1000Gi

PV는 NFS로 미리 생성을 하고, Statefulset을 적용했다.

*주소의 경우 {Pod 이름}.{Service 이름}.{Namespace}.{k8s}.{cluster_dns}로 이루어진다.

두번째 해결 방법 적용 결과

결과는 의도한대로 3개의 서버에 각 드라이브가 뜨는 형태가 되었지만, 속도는 여전히 느렸는데(3Mb/s ~ 4Mb/s)

NFS(Network File System) 사용으로 인한 속도 저하로 판단하고 DirectPV를 적용하려고 했지만..

https://github.com/minio/directpv

DirectPV는 비어있는 파티션에만 적용이 가능해서 빠른 포기. ( 현재 OS를 사용하고 있는 디스크 드라이브도 사용할 예정 및 다른 디스크 드라이브 포맷도 불가능해서 이 방법은 적용할 수 없었다. )

 

최종 ( SNSD + Site Replication ) 

그렇게 이런 저런 테스트들을 시도해 보다가 어떨땐 속도가 빠르고(10Mb/s 이상) 어떨땐 속도가 느린(3Mbs) 현상을 발견했는데, 처음엔 네트워크 문제 (물리적위치와 IP 대역이 다른 두 개의 서버를 사용중이였다.) 라 생각하고 네트워크쪽으로 문제를 해결하려고 접근했으나, 돌고 돌아 MinIO의 자체 로드밸런서에 의해 SDD에 붙느냐 HDD에 붙느냐에 따라 속도 차이가 발생한다는 것을 발견했다.

https://min.io/docs/minio/linux/operations/install-deploy-manage/multi-site-replication.html

SSD와 HDD를 섞어서 테스트를 하다보니 문제점을 찾는데 더 오랜 시간이 걸렸었다.

결과적으로, SSD HDD를 묶어 사용하면 어느 저장장치에 물리느냐에 따라 속도 차이가 심하게 발생하므로, 메인은 SSD 백업은 HDD에 되도록 Site Replication을 이용하여 위 그림처럼 분리하였다.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-minio-folder-backup
  namespace: minio-file
spec:
  capacity:
    storage: 900Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: minio-file
  local:
    path: /mnt/minio-file-backup
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - server2
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: minio-file-backup
  namespace: minio-file
spec:
  serviceName: "minio-file"
  replicas: 1
  selector:
    matchLabels:
      app: minio-file
  template:
    metadata:
      labels:
        app: minio-file
    spec:
      containers:
      - name: minio-file-backup
        image: minio/minio
        args:
        - server
        - /data
        env:
        - name: MINIO_ROOT_USER
          valueFrom:
            secretKeyRef:
              name: minio-secret
              key: MINIO_ROOT_USER
        - name: MINIO_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: minio-secret
              key: MINIO_ROOT_PASSWORD
        ports:
        - containerPort: 9000
        volumeMounts:
        - name: pvc
          mountPath: /data
      nodeSelector:
        kubernetes.io/hostname: server2

  volumeClaimTemplates:
  - metadata:
      name: pvc
      labels:
        app: minio-file-backup
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 900Gi
      storageClassName: minio-file

메인 서버(SSD)와 백업 서버(HDD) 각각 로컬 디스크 드라이브를 참조하여 Pod가 실행되도록 했고, 같은 서비스위에서 작동(minio-file)하도록 설정했다.

 

Site Replication 설정 방법

 

Site Replication은 WebUI를 이용해서 설정했는데, Admin으로 접속하여 Site Replication 탭 선택 후, 추가 버튼을 이용하여 복제될 peer sites를 설정하면 된다.

Endpoint는 Backup 서버로 생성한 Pod의 주소이며, 위에 언급한 {Pod 이름}.{Service 이름}.{Namespace}.{k8s}.{cluster_dns} 이 방식대로 주소를 입력하면 되고, Access Key와 Secret Key는 Pod를 생성할 때 사용한 계정 이름과 비밀번호를 입력하면 된다.

# 예제
http://minio-file-backup-0.minio-file.minio-file.svc.cluster.local:9000

이렇게 설정함으로써 SSD의 속도를 유지하면서, 안정성을 위한 데이터 복제 기능까지 넣을 수 있게 되었다.

 

마치며

여러가지 테스트를 돌려보며 실험 변인(SSD, HDD, 네트워크 등)을 통제하지 않아서 원인을 찾는데 더 오래 걸렸던 것 같습니다. (저장장치가 문제될 것 이라고는 생각을 못한 것도 한몫함)

다음부터는 시행착오의 횟수를 줄이기 위해 확실한 변인 통제를 염두해 두고자 합니다.