Info
Content

Introducing Cloud Native Storage for vSphere

출처 : https://blogs.vmware.com/virtualblocks/2019/08/14/introducing-cloud-native-storage-for-vsphere/

 

클라우드 네이티브 스토리지가 필요한 이유

컨테이너 환경은 high-churn, 아주 역동적인 환경이다. 매시간 수십, 수백, 수천 개의 컨테이너를 만들고 삭제할 수 있다. 수동으로 회전할 때 스토리지를 관리하는 것은 엄청난 변화율 때문에 불가능하다. 컨테이너 워크로드에 대한 스토리지 프로비저닝을 자동화하는 답이 필요해진다.

Cloud Native Storage(CNS)는 vSphere 및 K8(Kuebernetes) 기능으로, K8이 vSphere에 스토리지를 완전히 자동화되고 확장 가능한 방식으로 프로비저닝하는 방법과 vCenter 내의 CNS UI를 통해 관리자가 컨테이너 볼륨에 대한 가시성을 제공할 수 있도록 하는 기능이다.

컨테이너와 VM을 동일 플랫폼, 방법으로 실행하고, 모니터링하고, 관리한다. 라이프사이클과 운영에 인프라스트럭쳐의 단순화가 필요하다. 워크로드와 클라우드 간에 일관된 운영을 위해 이미 알고 있는 플랫폼을 사용해서, 비용 절감과 인프라 관리에 소요되는 시간을 줄이고 비즈니스 가치를 제공하는 애플리케이션을 구축하는 데 더 많은 시간을 투자하십시오.

Screenshot-2019-08-08-151830.png

클라우드 네이티브 스토리지란?

CNS는 CNA(Cloud Native Applications)의 스토리지를 설명하는 데 사용되는 용어다. CNA는 일반적으로 Kubernetes, Mesos, Docker Swarm과 같은 컨테이너형 Orchestrator에서 컨테이너화되고, 배포/관리한다. 이러한 앱에서 사용하는 스토리지는 일시적이거나 영구적일 수 있지만, 대부분의 경우 영구적이어야 한다.

점점 더 많은 개발자들이 애플리케이션을 개발, 구축, 구현, 실행 및 관리하기 위해 컨테이너와 쿠버네티스와 같은 새로운 기술을 채택하고 있기 때문에, VMware 스택이 이러한 애플리케이션을 실행하는 데 필요한 모든 인프라를 제공하는 것이 중요하다.

스테이트풀(상태저장) 애플리케이션을 위한 스토리지 인프라가 중요하기 때문에 기본적으로 vSphere에 CNS를 구축했다. CNS의 목적은 CNA가 직면하는 스토리지 문제를 해결하는 것이다. 현재 CNS는 쿠버네티스가 컨테이너 오케스트레이션을 위한 사실 표준으로 발전했기 때문에 쿠버네티스에서 실행되는 워크로드를 지원한다.

CNS는 두 부분으로 구성된다.

  • K8용 Container Storage Interface(CSI) 플러그인
  • vCenter 내의 CNS 제어 영역

Screenshot-2019-08-13-104141.png

CNS는 vSphere에서 스토리지 프로비저닝과 관리 작업을 모두 수행하는 방법에 대한 이해를 K8s에 제공한다. 또한 CNS는 vSphere 관리자에게 물리적 인프라의 컨테이너 사용에 대한 가시성을 제공한다. 여기에는 VM 볼륨처럼 백업 Disk에 컨테이너 볼륨을 매핑하고 용량 관리를 관리하는 작업이 포함된다.

1월에 우리가 함께 찍은 베타 데모 비디오를 보고 아이디어를 얻도록 하자!

그래서, 우리가 어떻게 여기에 왔을까? 그리고 우리는 지금 무엇을 하고 있을까?

이전 – vSphere Cloud Provider(VCP)

vSphere Storage for Kubernets(vSphere Cloud Provider)는 2017년에 처음 시작한 쿠버네티스의 vSphere 스토리지 솔루션이었다. VCP는 내부 해커톤에 의한 프로젝트로 시작되었고 대중들에 의해 오픈소스와 consumable로 만들어졌다. 그 이후로 고객의 요구와 버그 보고서를 따라가면서 개선되었다.

VCP 이전에는 볼륨 프로비저닝을 수동으로, 한 번에 하나의 VMDK를 적절한 작업자 노드에 마운트하고 포맷하여 컨테이너에 탑재해야 했는데, 규모에 따라 프로비저닝이 불가능했다. VCP는 스토리지(VMDK)를 프로비저닝 및 삭제하고, 연결/삭제하고, 마운트/해제하고, K8s 노드에 대해 자동으로 포맷하는 기능을 추가했다.

VCP는 현재 VMware PKS, RedHat OpenShift, Google Cloud의 Anthos, Lancher 등을 제공하는 다양한 Kubernetes as a Service(KaaS)에 의해 활발하게 사용되고 있다. 기본적으로 현재 vSphere에서 KaaS 솔루션을 실행할 경우 VCP를 사용한다.

VCP는 vSphere를 기반으로 한 K8s 환경의 가시성 및 문제 해결과 관련하여, 용량 관리 및 문제 추적은 어려웠으며 많은 수동 단계가 필요했다.

CNS는 vCenter용 내장 대시보드를 통해 이러한 문제를 해결하고,  관리자가 용량 사용과 할당뿐 아니라 볼륨 사용과 K8s 인프라 내의 파드 및 애플리케이션에 대한 매핑을 파악할 수 있도록 함으로써 IaaS 플랫폼이 이러한 문제를 해결하는 것을 목표로 한다.

CNS는 VCP의 다음 발전으로, 완전히 새로운 인터페이스(Container Storage Interface – CSI)로 다시 작성되어, 처음부터, 기업용으로 준비되고, 스토리지에 대한 Kubernetes의 수정된 방향에 부합한다.

VCP에서 CSI로 이동하는 이유는?

VCP는 목적을 제공했으며, 관리자의 개입 없이 K8s를 통해 인스턴스화된 볼륨의 동적 프로비저닝을 기본 vSphere 인프라에 생성할 수 있었다. 그러나 결점이 없는 것은 아니었다.

VCP는 K8이 기반 인프라와 대화하는 방법을 이해할 수 있는 메커니즘을 제공한다는 점에서 Kubernetes가 "Cloud Provider"라고 부르는 것이다.

Kubernetes Cloud Provider는 "in-tree"와 "out-tree"이라는 두 가지 형식이 있다. 이는 기본적으로 하나는 다운로드하여 설치할 때(트리 내) K8s 바이너리와 함께 박스로 배송되고(in-tree), 다른 하나는 클러스터에서 배포한 후 클러스터에 설치해야 함(out-of-tree)을 의미한다.

이들 각각은 장단점이 있지만, 트리 내에는 다음과 같은 세 가지 주요 라이프사이클 제약이 있다.

  • 클라우드 프로바이더 업그레이드를 위한 K8s 릴리스 주기에 얽매여 있음
  • 클라우드 제공자를 업그레이드하려면 모든 K8s을 업그레이드해야 함
  • K8s 배포가 최신 버전의 K8s을 지원하지 않는 경우 클라우드 제공자 코드를 그대로 유지하고, 변경할 수 없으며, 버그 수정도 없고, 기능도 없는 경우

그 결과, 프로젝트로서 Kubernetes는 자사의 핵심 코드베이스에서 모든 클라우드 제공자 코드를 제거하고 통합 구축 공급업체들이 out-of-tree 모델을 사용하도록 하기로 결정했다.

이것은 앞으로 실행 가능한 유일한 해결책은 다시 쓰는 것이라는 것을 의미했다. 이와 같이, 우리는 새로운 CSI 사양을 기반으로 스토리지 통합을 처음부터 다시 작성하는 기회를 가졌다.

이를 통해 우리의 스토리지 통합은 단순히 K8을 위한 미래형 솔루션이 아니라, CSI 규격을 지원하는 Container Orchestrator가 될 수 있다. 이러한 노력은 우리가 in-line 커뮤니티와 긴밀하게 협력할 수 있도록 K8s 스토리지 및 오픈 소스 작업에 대한 지침과 조정 기능을 제공한 헵티오를 인수함으로써 큰 도움이 되었다.

현재 - Container Native Storage

CNS는 기본적으로 vSphere에 구축되어 있으므로 처음부터 vSphere에 따라 확장되며 수많은 미래의 혁신을 가능하게 하는 것이 중요하다. vCenter 자체 내의 새로운 CNS Control Plane은 K8s에 설치된 CSI 플러그인의 모든 요청을 중개하며, 이를 통해 단일 스토리지 백엔드에 얽매이지 않고 향후 기능을 쉽게 확장할 수 있다.

다시 쓰기 작업의 일환으로 CNS 제어판은 FCD(First Class Disks)로 알려진 vSphere의 기능을 사용하도록 제작되었다. FCD를 사용하면 VMDK와 볼륨이 존재하며 VM과 완전히 독립적인 라이프사이클을 가질 수 있다.

FCD는 vSphere의 first-class 시민으로서 완벽하게 관리되므로, 더 이상 공간을 소비하는 데이터스토어에 오래도록 잊혀지지 않는 격리된 VMDK가 없어야 함!

Screenshot-2019-08-08-150833.png

CNS 볼륨 프로비저닝 워크플로우

또한 CNS는 이러한 볼륨의 SPBM 프로비저닝을 완벽하게 지원하며, 이는 K8s StorageClass 개념과 정확히 일치하는 기본 정책 기반 스토리지 워크플로우를 고려할 때 vSAN에 가장 적합하다. 즉, 태그 기반 SPBM 정책을 사용하는 경우 CNS는 VMFS 및 NFS에서도 작동한다.

CNS는 vSphere 6.7 U3의 일부로 추가 비용 없이 표준 vSphere 라이센스를 보유한 모든 사용자에게 제공된다.

CNS 설치 및 스핀 업에 대한 설명서를 주의 깊게 살펴보십시오.

 

No Comments
Back to top