Kubernetes의 스토리지: OpenEBS vs Rook(Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor

업데이트!. 댓글에서 독자 중 한 명이 시도해 보라고 제안했습니다. 린스터 (어쩌면 그 사람이 직접 작업하고 있을 수도 있음) 그래서 이 솔루션에 대한 섹션을 추가했습니다. 나도 썼다 설치방법 포스팅, 프로세스가 나머지 프로세스와 매우 다르기 때문입니다.

솔직히 포기하고 포기했어요 Kubernetes (적어도 지금은). 나는 사용할 것이다 헤로 꾸. 왜? 보관 때문에! 내가 Kubernetes 자체보다 스토리지에 더 많은 관심을 기울일 것이라고 누가 생각이나 했을까요? 나는 사용한다 헤츠너 클라우드가격이 저렴하고 성능이 좋기 때문에 처음부터 다음을 사용하여 클러스터를 배포해 왔습니다. 목장 경영자. 모든 것을 스스로 배우고 싶었기 때문에 Google/Amazon/Microsoft/DigitalOcean 등의 관리형 Kubernetes 서비스를 시도하지 않았습니다. 나는 또한 알뜰하다.

그렇습니다. 저는 가능한 Kubernetes 스택을 평가할 때 어떤 스토리지를 선택할지 결정하는 데 많은 시간을 보냈습니다. 저는 가격 때문에 오픈 소스 솔루션을 선호하지만, 제한적인 무료 버전이 있기 때문에 호기심에 몇 가지 유료 옵션을 살펴보았습니다. 다양한 옵션을 비교하면서 최근 테스트에서 얻은 몇 가지 수치를 적어 두었는데, 이는 Kubernetes 스토리지에 대해 배우는 사람들에게 흥미로울 수 있습니다. 개인적으로 지금은 Kubernetes에 작별 인사를 했지만. 나는 또한 언급하고 싶다 CSI 드라이버, Hetzner Cloud 볼륨을 직접 프로비저닝할 수 있지만 아직 시도하지 않았습니다. 특히 노드 오류 및 기타 유사한 상황이 발생하는 경우 복제와 모든 노드에 영구 볼륨을 신속하게 마운트하는 기능이 필요했기 때문에 클라우드 소프트웨어 정의 스토리지를 살펴보았습니다. 일부 솔루션은 특정 시점 스냅샷과 오프사이트 백업을 제공하므로 편리합니다.

6~7개의 스토리지 솔루션을 테스트했습니다.

오픈EBS

내가 이미 말했듯이 이전 게시물에서목록에 있는 대부분의 옵션을 테스트한 후 처음에는 OpenEBS를 선택했습니다. OpenEBS는 설치와 사용이 매우 쉽지만, 솔직히 로드 중인 실제 데이터로 테스트한 결과 성능에 실망했습니다. 이것은 오픈 소스이며 개발자가 스스로 작업합니다. 슬랙 채널 도움이 필요할 때마다 항상 큰 도움이 되었습니다. 안타깝게도 다른 옵션에 비해 성능이 매우 좋지 않아 테스트를 다시 실행해야 했습니다. OpenEBS에는 현재 3개의 스토리지 엔진이 있는데 cStor에 대한 벤치마크 결과를 올려보겠습니다. 아직 Jiva 및 LocalPV에 대한 번호가 없습니다.

간단히 말해서 Jiva가 조금 더 빠르며 LocalPV는 일반적으로 빠르며 직접 디스크 벤치마크보다 나쁘지 않습니다. LocalPV의 문제점은 볼륨이 준비된 노드에서만 액세스할 수 있고 복제가 전혀 없다는 것입니다. 다음을 통해 백업을 복원하는 데 몇 가지 문제가 발생했습니다. 요트 노드 이름이 다르기 때문에 새 클러스터에 있습니다. 백업에 관해 이야기하면 cStor는 Velero용 플러그인를 사용하면 특정 시점에 스냅샷의 오프사이트 백업을 수행할 수 있으며 이는 Velero-Restic을 사용한 파일 수준 백업보다 더 편리합니다. 나는 썼다 여러 스크립트, 이 플러그인을 사용하여 백업 및 복원을 더 쉽게 관리할 수 있습니다. 전체적으로 OpenEBS를 정말 좋아하는데 성능이...

사기꾼

Rook은 오픈 소스이기도 하며, 목록의 나머지 옵션과 구별되는 점은 다양한 백엔드를 사용하여 복잡한 스토리지 관리 작업을 처리하는 스토리지 조정자라는 점입니다. 세프, EdgeFS 그리고 다른 것들은 작업을 크게 단순화시킵니다. 몇 달 전에 EfgeFS를 시도했을 때 문제가 있어서 주로 Ceph로 테스트를 했습니다. Ceph는 블록 스토리지뿐만 아니라 S3/Swift 및 분산 파일 시스템과 호환되는 객체 스토리지도 제공합니다. Ceph에서 제가 좋아하는 점은 볼륨 데이터를 여러 디스크에 분산시켜 볼륨이 단일 디스크에 들어갈 수 있는 것보다 더 많은 디스크 공간을 사용할 수 있다는 것입니다. 편안해요. 또 다른 멋진 기능은 클러스터에 디스크를 추가하면 자동으로 모든 디스크에 데이터가 재배포된다는 것입니다.

Ceph에는 스냅샷이 있지만 내가 아는 한 Rook/Kubernetes에서는 직접 사용할 수 없습니다. 사실, 나는 이것에 깊이 들어 가지 않았습니다. 그런데 오프사이트 백업이 없어서 벨레로/레스틱으로 뭔가를 이용해야 하는데, 시점 스냅샷은 아니고 파일 단위 백업만 있습니다. Rook에서 제가 정말 좋아했던 점은 Ceph로 작업하는 것이 얼마나 쉬운지였습니다. 이는 거의 모든 복잡한 내용을 숨기고 문제 해결을 위해 Ceph와 직접 대화할 수 있는 도구를 제공합니다. 불행하게도 Ceph 볼륨의 스트레스 테스트 중에 계속해서 문제가 발생했습니다. 이 문제이로 인해 Ceph가 불안정해집니다. 이것이 Ceph 자체의 버그인지, 아니면 Rook이 Ceph를 관리하는 방식의 문제인지는 아직 명확하지 않습니다. 메모리 설정을 만지작거리고 나아졌으나 문제가 완전히 해결되지는 않았습니다. Ceph는 아래 벤치마크에서 볼 수 있듯이 괜찮은 성능을 가지고 있습니다. 대시보드도 잘 되어있습니다.

랜처 롱혼

저는 롱혼을 정말 좋아해요. 내 생각에는 이것이 유망한 해결책이다. 사실, 개발자 자신(Rancher Labs)은 이것이 아직 작업 환경에 적합하지 않다는 것을 인정하고 있으며 이는 이를 보여줍니다. 오픈 소스이고 괜찮은 성능을 가지고 있지만(아직 최적화하지는 않았지만) 볼륨이 포드에 연결하는 데 매우 오랜 시간이 걸리고 최악의 경우 특히 대규모 백업을 복원한 후 또는 최악의 경우 15~16분이 걸립니다. 워크로드를 업그레이드합니다. 여기에는 스냅샷과 이러한 스냅샷의 오프사이트 백업이 있지만 볼륨에만 적용되므로 다른 리소스를 백업하려면 여전히 Velero와 같은 것이 필요합니다. 백업 및 복원은 매우 안정적이지만 너무 느립니다. 정말이지 엄청나게 느립니다. Longhorn에서 중간 정도의 데이터를 작업할 때 CPU 사용량과 시스템 로드가 급증하는 경우가 많습니다. 롱혼을 관리할 수 있는 편리한 대시보드가 ​​있습니다. 나는 이미 Longhorn을 좋아한다고 말했지만 약간의 작업이 필요합니다.

스토리지 OS

StorageOS는 목록의 첫 번째 유료 제품입니다. 관리형 스토리지 크기가 500GB로 제한된 개발자 버전이 있지만 노드 수에는 제한이 없는 것 같습니다. 영업부에서는 내 기억이 맞다면 비용이 125TB당 월 1달러부터 시작한다고 말했습니다. 기본 대시보드와 편리한 CLI가 있지만 성능에 이상한 현상이 일어나고 있습니다. 일부 벤치마크에서는 꽤 괜찮았지만 볼륨 스트레스 테스트에서는 속도가 전혀 마음에 들지 않았습니다. 일반적으로 무슨 말을 해야할지 모르겠습니다. 그래서 사실 잘 이해가 안 됐어요. 여기에는 오프사이트 백업이 없으며 볼륨을 백업하려면 Restic과 함께 Velero를 사용해야 합니다. 이상한데 상품이 유료라서요. 그리고 개발자들은 Slack에서 소통하는 것을 열망하지 않았습니다.

남자 이름

나는 Reddit의 기술 디렉터로부터 Robin에 대해 배웠습니다. 나는 전에 그에 대해 들어 본 적이 없습니다. 무료 솔루션을 찾고 있었기 때문일 수도 있지만 Robin은 유료입니다. 10TB의 스토리지와 XNUMX개의 노드를 갖춘 꽤 넉넉한 무료 버전이 있습니다. 전반적으로 제품은 꽤 괜찮고 기능도 좋습니다. 훌륭한 CLI가 있지만 가장 멋진 점은 볼륨 및 기타 리소스를 포함하여 전체 애플리케이션(리소스 선택기에서는 Helm 릴리스 또는 "플렉스 앱"이라고 함)의 스냅샷을 찍고 백업할 수 있으므로 Velero 없이도 작업할 수 있다는 것입니다. 그리고 하나의 작은 세부 사항만 아니라면 모든 것이 훌륭할 것입니다. 예를 들어 재해로부터 복구하는 경우와 같이 새 클러스터에서 애플리케이션을 복원(또는 Robin에서 호출하는 대로 "가져오기")하는 경우 복원, 물론 작동하지만 애플리케이션을 계속 백업하는 것은 금지되어 있습니다. 개발자가 확인한 것처럼 이번 릴리스에서는 이것이 불가능합니다. 이는 특히 다른 장점(예: 믿을 수 없을 정도로 빠른 백업 및 복원)을 고려하면 다소 이상합니다. 개발자는 다음 릴리스까지 모든 것을 수정할 것을 약속합니다. 성능은 일반적으로 좋지만 이상한 점을 발견했습니다. 호스트에 연결된 볼륨에서 직접 벤치마크를 실행하면 포드 내에서 동일한 볼륨을 실행하는 것보다 읽기 속도가 훨씬 빠릅니다. 다른 모든 결과는 동일하지만 이론적으로는 차이가 없어야 합니다. 작업 중이지만 복원 및 백업 문제로 인해 속상했습니다. 마침내 적합한 솔루션을 찾았다고 생각했고 더 많은 공간이나 더 많은 서버가 필요할 때 비용을 지불할 용의도 있었습니다.

포트웍스

여기서는 별로 할 말이 없습니다. 이것은 유료 제품이며 똑같이 멋지고 비쌉니다. 성능은 정말 놀랍습니다. 이것은 지금까지 가장 좋은 지표입니다. Slack은 Google의 GKE Marketplace에 나열된 대로 가격이 노드당 월 205달러부터 시작한다고 말했습니다. 직접 구매하면 더 싸질지는 모르겠네요. 어차피 그럴 여유가 없어서 정적 프로비저닝에 만족하지 않는 한 개발자 라이선스(최대 1TB 및 3개 노드)가 Kubernetes에서 실질적으로 쓸모가 없다는 점에 매우 실망했습니다. 평가판 기간이 끝나면 볼륨 라이선스가 자동으로 개발자로 다운그레이드되기를 바랐지만 그런 일은 일어나지 않았습니다. 개발자 라이선스는 Docker에서만 직접 사용할 수 있으며 Kubernetes의 구성은 매우 번거롭고 제한적입니다. 물론 저는 오픈소스를 선호하지만, 돈이 있다면 반드시 Portworx를 선택할 것입니다. 지금까지 그 성능은 다른 옵션과 비교할 수 없습니다.

린스터

이 부분은 게시글이 올라온 후 한 독자분이 Linstor를 사용해 보라고 제안하셔서 추가했습니다. 직접 사용해 보니 마음에 들었습니다! 하지만 좀 더 자세히 살펴봐야 할 것 같습니다. 현재로서는 성능이 상당히 좋다고 말씀드릴 수 있습니다(아래에 벤치마크 결과를 첨부했습니다). 실제로 오버헤드 없이 직접 디스크 벤치마크와 동일한 성능을 얻었습니다. (Portworx의 수치가 직접 디스크 벤치마크보다 더 좋은 이유는 저도 모르겠습니다. 마법이겠죠.) 어쨌든 Linstor는 지금까지는 매우 효과적인 것 같습니다. 설정하는 것이 아주 어렵지는 않지만 다른 옵션만큼 간단하지는 않습니다. 먼저 Linstor(커널 모듈 및 도구/서비스)를 설치하고 Kubernetes 외부, 호스트에서 직접 씬 프로비저닝 및 스냅샷 지원을 위한 LVM을 설정한 다음 Kubernetes에서 스토리지를 사용하는 데 필요한 리소스를 생성해야 했습니다. 제대로 작동하지 않아서 좀 아쉬웠습니다. CentOS 그리고 사용해야 했습니다 Ubuntu물론 큰 문제는 아니지만, 문서(정말 훌륭합니다!)에 언급된 몇몇 패키지가 지정된 Epel 저장소에서 사용할 수 없다는 점이 조금 불편합니다. Linstor는 스냅샷 기능은 있지만 오프사이트 백업은 지원하지 않아서 볼륨 백업을 위해 Velero와 Restic을 다시 사용해야 했습니다. 파일 수준 백업보다는 스냅샷을 선호하지만, 성능과 안정성만 좋다면 감수할 만합니다. Linstor는 오픈 소스이지만 유료 지원이 있습니다. 제가 제대로 이해했다면 지원 계약이 없더라도 제한 없이 사용할 수 있는 것 같은데, 확인해 봐야겠습니다. Linstor가 Kubernetes 환경에서 얼마나 검증되었는지는 모르겠지만, 스토리지 계층 자체는 Kubernetes 외부에 있고, 꽤 오래전부터 있었던 것 같으니 실제 환경에서 이미 검증되었을 가능성이 높습니다. 제가 생각을 바꿔 Kubernetes로 다시 돌아갈 만한 해결책이 있을까요? 잘 모르겠습니다. 좀 더 알아보고 복제에 대해 공부해야 할 것 같습니다. 두고 봐야죠. 하지만 첫인상은 좋습니다. 더 자유롭게 활용하고 새로운 것을 배우려면 Heroku 대신 자체 Kubernetes 클러스터를 사용하는 게 훨씬 나을 것 같습니다. Linstor는 다른 도구들처럼 설치가 쉽지 않아서 조만간 설치 과정에 대한 글을 올리겠습니다.

벤치마크

불행히도 나는 비교에 대해 글을 쓸 것이라고 생각하지 않았기 때문에 비교에 대해 많은 메모를 보관하지 않았습니다. 기본 fio 벤치마크 결과와 단일 노드 클러스터에 대한 결과만 있으므로 아직 복제된 구성에 대한 수치는 없습니다. 그러나 이러한 결과를 통해 각 옵션에서 기대할 수 있는 사항에 대한 대략적인 아이디어를 얻을 수 있습니다. 테스트된 볼륨에 대해 동일한 클라우드 서버, 4개 코어, 16GB RAM 및 추가 100GB 디스크에서 옵션을 비교했기 때문입니다. 각 솔루션에 대해 벤치마크를 38번 실행하고 평균 결과를 계산했으며, 각 제품에 대한 서버 설정을 재설정했습니다. 이것은 단지 일반적인 아이디어를 제공하기 위한 것이며 완전히 비과학적인 것입니다. 다른 테스트에서는 읽기와 쓰기 테스트를 위해 볼륨에서 XNUMXGB의 사진과 비디오를 복사했지만 아쉽게도 숫자를 저장하지 않았습니다. 즉, Portworkx가 훨씬 빨랐습니다.

볼륨 벤치마크를 위해 다음 매니페스트를 사용했습니다.

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: dbench
spec:
  storageClassName: ...
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
apiVersion: batch/v1
kind: Job
metadata:
  name: dbench
spec:
  template:
    spec:
      containers:
      - name: dbench
        image: sotoaster/dbench:latest
        imagePullPolicy: IfNotPresent
        env:
          - name: DBENCH_MOUNTPOINT
            value: /data
          - name: FIO_SIZE
            value: 1G
        volumeMounts:
        - name: dbench-pv
          mountPath: /data
      restartPolicy: Never
      volumes:
      - name: dbench-pv
        persistentVolumeClaim:
          claimName: dbench
  backoffLimit: 4

먼저 적절한 스토리지 클래스로 볼륨을 생성한 다음 백그라운드에서 fio를 사용하여 작업을 실행했습니다. 성능을 추정하는 데 1GB가 걸렸고 너무 오래 기다리지 않았습니다. 결과는 다음과 같습니다.

각 측정 항목의 최고 값은 녹색으로, 최악의 값은 빨간색으로 강조했습니다.

결론

보시다시피 대부분의 경우 Portworx는 다른 것보다 성능이 뛰어났습니다. 하지만 나에게는 비싸다. Robin의 가격이 얼마인지는 모르겠지만 훌륭한 무료 버전이 있으므로 유료 제품을 원한다면 시도해 볼 수 있습니다(복원 및 백업 문제가 곧 해결되기를 바랍니다). 세 가지 무료 서비스 중에서 OpenEBS에 대한 문제가 가장 적었지만 성능은 형편없습니다. 더 많은 결과를 저장하지 못해 아쉽지만, 수치와 제 댓글이 도움이 되셨으면 좋겠습니다.

출처 : habr.com