The Nutanix Bible

written by Steven Poitras

Copyright (c) 2019: Nutanix Bible 및 NutanixBible.com, 2019. 본 블로그의 저자 또는 소유자의 명시적 또는 서면 허가 없이 본 자료를 무단으로 사용 또는 복제하는 것은 엄격히 금지되어 있습니다. 원본 내용에 대한 적절하고 구체적인 방향으로 Steven Poitras 및 NutanixBible.com으로부터 완전하고 분명하게 허가를 받은 경우에 발췌 및 링크를 사용할 수 있습니다.

피드백이 있으신가요? 철자 오류를 찾으셨나요? biblefeedback at nutanix dot com으로 피드백을 보내 주세요.


언어별 변역본은 다음과 같습니다.


PDF 버전: 뉴타닉스 바이블(Nutanix Bible)이 자주 업데이트되는 관계로 전용 PDF 버전은 제공하지 않습니다. 그러나, 'Print to PDF' 기능을 이용하여 PDF 버전으로 인쇄할 수 있습니다.

서문

Dheeraj Pandey
Figure 1-1.

Dheeraj Pandey, CEO, Nutanix

"뉴타닉스 바이블(The Nutanix Bible)"로 명명된 이 책의 서문을 기고하게 되어 매우 영광스럽게 생각합니다. 무엇보다 먼저, 자신의 신앙, 불가지론자, 또는 무신론자인 분들에게 포괄적인 내용이 아닌 것처럼 보이는 책의 이름에 대해 언급하겠습니다. "Merriam Webster"에 정의되어 있는 것과 같이 "바이블(bible)"이란 문자 그대로 "성경(Scriptures)"을 의미하기보다는 "높은 권위와 폭넓은 독자층을 가진 뛰어난 출판물"이라는 의미를 가집니다. 이런 측면에서 뉴타닉스 바이블의 본질을 이해할 수 있습니다. 이 책은 뉴타닉스에서 가장 겸손하면서도 지식이 풍부한 직원들 중의 한 사람인 Steven Poitras가 처음 집필을 시작한 것으로, 그는 첫 번째 뉴타닉스 솔루션 설계자로 "초기 직원"이라는 입장에 만족하지 않고 이 분야의 권위자로 자기계발을 계속하고 있습니다. 그에게 지식은 힘이 아니었습니다 - 그가 가진 지식을 공유하는 행위가 회사에서 그를 빛나게 만들었습니다. Steve는 뉴타닉스 기업문화의 전형적인 모습을 보여주고 있습니다 - 그는 주제와 관련된 전문 지식을 기반으로 모든 사람들을 도와주고, Power Shell 또는 Python을 활용하여 단순하고 지루한 작업을 자동화하도록 도와주고, 필드 환경에 유용한 레퍼런스 아키텍처를 만들고 (내용과 형식이 완벽하게 조화된), Yammer 또는 Twitter에서 도움을 필요로 하는 모든 사람에게 실시간으로 대화할 수 있는 친구가 되어주고, 자아성찰 및 자기계발이 필요한 엔지니어와의 투명한 관계를 유지하고, 항상 야망을 갖고 의욕적으로 일합니다.

그는 블로그를 쓰기 시작할 때, 투명성을 가지고 선도하고, 필드에서 이러한 투명성을 바탕으로 디자인을 상쇄할 수 있는 권한를 가진 지지자들을 구축하겠다는 큰 꿈을 가지고 있었습니다. 회사의 입장에서 Steve가 블로그에 제공한 것과 같은 수준의 디자인과 아키텍처를 공개하는 것은 매우 드문 일입니다. 대부분의 오픈 소스 회사는 - 그들의 코드가 오픈 소스이기 때문에 표면적으로 투명하게 보일 수 있을지 모르지만 - 디자인 세부사항 및 내부 동작 방식을 결코 말하지 않습니다. 우리의 경쟁자가 우리 제품 또는 디자인의 약점을 알 때 그것은 우리를 더욱 강하게 만듭니다 - 왜냐하면 우리는 숨길 것이 거의 없고 어떤 것에 대해 비판을 받으면 우리는 그것으로부터 모든 것을 얻을 수 있습니다. 기능의 장단점 또는 디자인 의사결정 등과 관련된 공개적인 비판은 회사 전체를 빠른 시간 내에 Yammer로 몰아붙이고, 머지않은 시간 내에 그것이 진짜 약점인지 아니면 경쟁자가 의도적으로 과장할 정도로 우리의 진정한 강점인지에 대한 결론을 내리게 만듭니다. 본질적으로 뉴타닉스 바이블은 우리 자신을 자만에 빠트리지 않게 보호합니다. 뉴타닉스 바이블은 고객 및 파트너에 대한 뉴타닉스의 정직한 담론의 표현입니다.

권위를 뛰어넘어 이처럼 끊임없이 개선되는 블로그는 전 세계의 폭넓은 독자층을 즐겁게 하고 있습니다. 설계자, 관리자, CIO 등과 같은 IT 전문가들이 컨퍼런스 회장의 로비에서 저를 만났을 때 뉴타닉스 바이블의 상세한 설명, 그림, 도표, 그리고 신선하고 명쾌한 작문 스타일에 대한 찬사를 아끼지 않습니다. Steve는 웹-스케일(Web-Scale)에 대해 이야기하려고 많은 시간과 노력을 투입하고 있습니다. 대부분의 IT 담당자가 "매우 긴급한 일"의 처리에 매몰되어 있는 세계에서 우리의 분산 아키텍처를 활용하도록 만드는 것은 결코 쉬운 일이 아니었습니다. 뉴타닉스 바이블은 컴퓨터 과학 및 소프트웨어 엔지니어링의 장단점을 매우 알기 쉬운 용어로 설명하고 있기 때문에 IT와 데브옵스 간의 간극을 채우는 가교 역할을 합니다. 우리는 향후 3~5년 내에 IT 전문가가 데브옵스의 웹-스케일 용어에 좀 더 친숙해질 수 있기를 희망합니다.

뉴타닉스는 Steve 블로그의 초판을 한 권의 책으로 정리했습니다. 이 책이 업데이트가 되지 않는 그 순간이 뉴타닉스 종말의 시작입니다. 저는 여러분 모두가 "진실, 진리, 오로지 진실만이 너희를 자유롭게 하리라 (자기만족 및 자만심으로부터)"라는 것을 우리에게 지속적으로 상기시켜 주기를 기대합니다.

Keep us honest.

 

--Dheeraj Pandey, CEO, Nutanix

 

Stuart Miniman
Figure 1-2.

Stuart Miniman, Principal Research Contributor, Wikibon

오늘날 사용자는 신기술에 끊임없이 도전을 받고 있습니다. IT가 "새로운 더 나은 방법"으로 바꿀 수 있는 새로운 기회에 대한 제한은 없지만, 새로운 기술을 채택하는 것이 쉽지 않으며 더욱 중요한 것은 운영 및 프로세스의 변경이 매우 어렵다는 것입니다. 엄청나게 성장한 오픈 소스 기술도 적절한 문서의 부족으로 어려움을 겪고 있습니다. Wikibon은 커뮤니티가 이러한 문제를 해결하는 데 도움을 줄 수 있다는 믿음을 기반으로 설립되었습니다. Steve Poitras가 블로그 게시물로 시작한 뉴타닉스 바이블은 하이퍼컨버전스 및 웹-스케일의 원리를 배우고, 뉴타닉스 및 하이퍼바이저 아키텍처를 좀 더 깊이 있게 이해하고자 하는 IT 담당자들에게 매우 가치 있는 레퍼런스가 되었습니다. Steve가 기술한 개념은 업계에서 가장 똑똑한 엔지니어 중 일부가 솔루션을 위해 설계한 고급 소프트웨어 엔지니어링 문제입니다. 이 책은 기술의 진실성을 손상시키지 않으면서 IT 담당자들이 이해할 수 있는 방식으로 이러한 기술들을 설명합니다.

분산 시스템 및 소프트웨어 기반 인프라의 개념은 IT 담당자가 이해하여야 하는 매우 중요한 개념입니다. 저는 뉴타닉스 고객 및 이러한 경향을 이해하고자 하는 모든 사람들이 이 책을 읽도록 권장합니다. 여기에서 설명하는 기술은 전 세계에서 가장 큰 데이터센터의 일부를 지원합니다.

 

--Stuart Miniman, Principal Research Contributor, Wikibon

시작하기

Steven Poitras
Figure 1-3.

Steven Poitras, Principal Solutions Architect, Nutanix

뉴타닉스 바이블에 오신 것을 환영합니다. 저는 매일 뉴타닉스 플랫폼과 작업합니다 - 저는 프로덕션 벤치마킹 실험실에서 이슈를 관리하는데, 이슈를 찾으려고 노력하며 그 이슈의 특징, 원인, 그리고 한계가 무엇인지를 찾습니다. 본 책에서 기술된 아이템은 저 뿐만 아니라 뉴타닉스의 다양한 엔지니어들에 의해 매일 활용되는 요령 및 가이드의 실제적인 문서로 사용됩니다.

NOTE: 본 문서는 뉴타닉스의 내부적인 동작에 대해 설명하고 있습니다. 본 블로그에 설명되어 있는 모든 항목은 뉴타닉스 플랫폼에 구현되어 있으며, 뉴타닉스 환경을 성공적으로 동작시키기 위해 모든 지식이 필요한 것은 아닙니다.

즐기십시오!

 

--Steven Poitras, Principal Solutions Architect, Nutanix

역사에서의 교훈

인프라스트럭처의 역사와 오늘날 우리가 있는 곳으로 인도했던 기술들에 대해 간략히 살펴본다.

데이터센터의 진화

데이터센터는 지난 수십 년 동안 엄청나게 발전했다. 다음 섹션에서 각 시대를 자세히 살펴본다.

메인프레임 시대

메인프레임은 수년 동안 시장을 지배하였으며, 오늘날 우리기 사용하고 있는 기술의 핵심 기반을 제공하였다. 회사는 다음과 같은 메인프레임의 주요 특징을 활용할 수 있었다.

  • 기본적으로 CPU, 메인 메모리, 스토리지가 컨버지드된 구조
  • 내부 이중화 설계

그러나 메인프레임은 또한 다음과 같은 이슈를 제기하였다.

  • 높은 인프라 조달 비용
  • 내재된 복잡성
  • 유연성 부족 및 높은 사일로 환경

독립형 서버로의 이동

기업 내 비즈니스 조직이 메인프레임 기능을 활용하기 어렵다는 사실이 부분적으로 피자박스 또는 독립형 서버를 도입하는 계기가 되었다. 독립형 서버의 주요 특징은 다음과 같다.

  • CPU, 메인 메모리, DAS
  • 메인프레임 보다 높은 유연성
  • 네트워크를 통한 액세스

그러나 독립형 서버는 더 많은 이슈를 제기하였다.

  • 사일로 수를 증가시킴
  • 낮은 또는 균일하지 않은 자원 활용률
  • 서버가 컴퓨트 및스토리지 모두에서 SPOF가 됨

중앙 집중식 스토리지

비즈니스는 항상 돈을 벌 필요가 있는데 데이터는 이러한 퍼즐의 핵심 요소이다. DAS를 사용하는 조직은 로컬에서 가용한 것보다 더 많은 공간이 필요하거나 서버 장애로 인해 데이터를 사용할 수 없는 환경에서 데이터 고가용성이 필요하였다.

중앙 집중식 스토리지는 메인프레임과 독립형 서버 모두를 대체하였는데 공유 가능한 대규모의 스토리지 풀 및 데이터 보호 기능을 제공하였다. 중앙 집중식 스토리지의 주요 특징은 다음과 같다.

  • 스토리지 자원의 풀링을 통해 스토리지 활용률 향상
  • RAID를 통한 중앙 집중식 데이터 보호로 서버 장애로 인한 데이터 손실 가능성 제거
  • 네트워크를 통해 스토리지 서비스 제공

중앙 집중식 스토리지와 관련된 이슈는 다음과 같다.

  • 중앙 집중식 스토리지가 잠재적으로 더 고가이지만 데이터는 하드웨어 보다 더 가치가 있다.
  • 복잡성 증가 (SAN 패브릭, WWPNs, RAID 그룹, 볼륨, 스핀들 카운트 등)
  • 중앙 집중식 스토리지는 다른 관리 툴/팀을 요구하였다.

가상화의 도입

시간상으로 이 시점에서 컴퓨트 활용률이 낮았고 자원 효율성은 수익성에 양향을 미치고 있었다. 그런 다음 가상화가 도입되어 단일 하드웨어에서 여러 개의 워크로드 및 운영체제를 VM으로 실행할 수 있었다. 가상화는 피자박스 사용률을 높였을 뿐만 아니라 사일로의 수와 장애가 미치는 영향을 증가시켰다. 가상화의 주요 특징은 다음과 같다.

  • 하드웨어로부터 OS를 추상화 (VM)
  • 매우 효율적인 컴퓨트 활용률은 워크로드 통합 유도

가상화와 관련된 이슈는 다음과 같다.

  • 사일로 수 및 관리 복잡성 증가
  • VM HA 기능 부족으로 컴퓨트 노드의 장애가 미치는 영향이 더 커짐
  • 풀링된 지원 부족
  • 다른 관리 툴/팀 필요

가상화의 성숙

하이퍼바이저는 매우 효율적이고 기능이 풍부한 솔루션이 되었다. VMware vMotion, HA, DRS 등과 같은 툴이 출시됨에 따라 사용자는 VM 고가용성을 제공하고 컴퓨트 워크로드를 동적으로 마이그레이션 할 수 있는 기능을 갖게 되었다. 유일한 주의사항은 두 개의 경로를 병합해야만 하는 중앙 집중식 스토리지에 의존한다는 것이었다. 유일한 단점은 이전에 스토리지 어레이에 대한 부하가 증가했고 VM 스프롤으로 인해 스토리지 I/O에 대한 경합이 발생했다.

주요 특징은 다음과 같다.

  • 클러스터링을 통한 컴퓨트 자원의 풀링
  • 컴퓨트 노드들 간에 워크로드를 동적으로 마이그레이션 하는 기능 (DRS/vMotion)
  • 컴퓨트 노드 장애 시에 VM HA 기능 도입
  • 중앙 집중식 스토리지를 요구

이슈는 다음과 같다.

  • VM 스프롤에 의한 스토리지 수요 증가
  • 더 많은 어레이의 스케일아웃에 대한 요구 사항은 사일로 수 및 복잡성을 증가시킴
  • 어레이에 대한 요구 사항으로 인해 GB 당 가격 상승
  • 어레이에 대한 자원 경합의 가능성
  • 다음과 같은 요구 사항을 보장해야 하는 필요성 때문에 스토리지 설정을 훨씬 더 복잡하게 만들었다.
    • 데이터스토어/LUN 당 VM 비율
    • I/O 요구 사항을 만족하기 위한 스핀들 카운트

Solid State Disks (SSDs)

SSD는 수많은 디스크 인클로저에 대한 필요 없이 훨씬 높은 I/O 성능을 제공함으로써 이러한 I/O 병목현상을 완화하는 데 도움을 주었다. 그러나 성능이 엄청나게 향상되었으나 컨트롤러 및 네트워크가 가용한 방대한 I/O를 처리할 수 있도록 발전하지 못했다. SSD의 주요 특징은 다음과 같다.

  • 기존 HDD 보다 훨씬 높은 I/O 특성
  • 본질적으로 탐색 시간 제거

SSD와 관련된 주요 이슈는 다음과 같다.

  • 병목현상이 디스크의 스토리지 I/O에서 컨트롤러/네트워크로 이동
  • 사일로는 여전히 남아있음
  • 어레이 설정의 복잡성은 여전히 남아있음

클라우드 시대

클라우드란 용어는 정의상 매우 모호할 수 있다. 간단히 말해서 다른 사람에 의해 어딘가에서 제공되는 서비스를 소비하고 활용할 수 있는 능력이다.

클라우드 도입으로 인해, IT, 비즈니스 및 최종 사용자의 관점이 바뀌었다.

비즈니스 그룹 및 IT 소비자는 IT가 클라우드와 동일한 기능, 민첩성 및 가치 창출 시간을 제공하도록 요구한다. 그렇지 않은 경우에 그들은 직접 클라우드로 갈 것인데, 이것은 IT 담당자에게 "데이터 보안"이라고 하는 새로운 이슈를 제기한다.

클라우드 서비스가 제공하는 핵심 기능은 다음과 같다.

  • 셀프서비스 / 온 디멘드
    • 신속한 가치 창출 시간 (TTV) / 진입 장벽이 거의 없음
  • 서비스 및 SLA 중심
    • 계약으로 가동시간 / 가용성 / 성능 보장
  • 종량제 기반 모델
    • 실제 사용량에 따라 비용 지불 (일부 서비스는 무료)
클라우드 분류

대부분의 일반적인 클라우드 분류는 다음과 같은 세 가지의 주요 버킷으로 구분된다 (최고 레벨에서 시작하여 아래로 이동)

  • SaaS (Software as a Service)
    • 간단한 URL을 통해 소비되는 모든 소프트웨어 / 서비스
    • 예: Workday, Salesfoce.com, Google Search 등
  • PaaS (Platform as a Service)
    • 개발 및 배포 플랫폼
    • 예: Amazon Elastic Beanstalk / Relational Database Services (RDS), Google App Engine 등
  • IaaS (Infrastructure as a Service)
    • 서비스로 VM, 컨테이너, NFV 제공
    • 예: Amazon EC2/ECS, Microsoft Azure, Google Compute Engine (GCE) 등
IT 포커스터의 변화

클라우드는 IT에게 흥미로운 딜레마를 제기한다. IT는 클라우드를 받아들일 수도 있고, 아니면 대안을 제공하려고 노력할 수도 있다. IT는 데이터를 내부에 유지하려고 하지만, 셀프서비스, 신속성 등과 같은 클라우드 기능을 제공할 필요가 있다.

이러한 변화는 IT가 그들의 최종 사용자(회사 직원)에게 합법적인 서비스 제공자로서 보다 많은 역할을 하도록 요구한다.

레이턴시의 중요성

다음 그림은 특정 유형의 I/O와 관련된 다양한 레이턴시(Latency)를 나타낸다.

항목 레이턴시 비고
L1 cache reference 0.5 ns
L2 cache reference 7 ns 14x L1 cache
DRAM access 100 ns 20x L2 cache, 200x L1 cache
3D XPoint based NVMe SSD read 10,000 of ns (expected) 10 us or 0.01 ms
NAND NVMe SSD R/W 20,000 ns 20 us or 0.02 ms
NAND SATA SSD R/W 50,000-60,000 ns 50-60 us or 0.05-0.06 ms
Read 4K randomly from SSD 150,000 ns 150 us or 0.15 ms
P2P TCP/IP latency (phy to phy) 150,000 ns 150 us or 0.15 ms
P2P TCP/IP latency (vm to vm) 250,000 ns 250 us or 0.25 ms
Read 1MB sequentially from memory 250,000 ns 250 us or 0.25 ms
Round trip within datacenter 500,000 ns 500 us or 0.5 ms
Read 1MB sequentially from SSD 1,000,000 ns 1 ms, 4x memory
Disk seek 10,000,000 ns or 10,000 us 10 ms, 20x datacenter round trip
Read 1MB sequentially from disk 20,000,000 ns or 20,000 us 20 ms, 80x memory, 20x SSD
Send packet CA -> Netherlands -> CA 150,000,000 ns 150 ms

(credit: Jeff Dean, https://gist.github.com/jboner/2841832)

상기 테이블은 CPU가 ~0.5-7ns에서 자신의 캐시(L1 vs. L2)에 액세스할 수 있음을 보여준다. 메인 메모리인 경우 이러한 액세스는 ~100ns에서 발생하지만 로컬 4K SSD 읽기는 150,000ns 또는 0.15ms이다.

일반적인 엔터프라이즈 클래스 SSD를 사용하는 경우 (인텔 S3700 - SPEC) 이 디바이스의 성능은 다음과 같다.

  • 랜덤 I/O 성능 (Random I/O performance):
    • 랜덤 4K 읽기: 최대 75,000 IOPS
    • 랜덤 4K 쓰기: 최대 36,000 IOPS
  • 순차 대역폭 (Sequential bandwidth):
    • 지속적인 순차 읽기: 최대 500MB/s
    • 지속적인 순차 쓰기: 최대 460MB/s
  • 레이턴시 (Latency):
    • 읽기: 50us
    • 쓰기: 65us

대역폭 살펴보기

기존 스토리지인 경우 I/O를 위한 몇 가지 주요 미디어 유형이 있다.

  • 파이버 채널 (FC)
    • 4-, 8-, 16- and 32-Gb
  • 이더넷 (FCoE 포함)
    • 1-, 10-Gb, (40-Gb IB) 등

하기 계산을 위해 인텔 S3700에서 제공하는 500MB/s 읽기, 460MB/s 쓰기 대역폭을 사용한다.

계산식은 다음과 같다.

numSSD = ROUNDUP((numConnections * connBW (in GB/s)) / ssdBW (R or W))

NOTE: 부분 SSD가 가능하지 않기 때문에 숫자는 반올림되었다. 계산식은 모든 I/O를 처리하기 위해 필요한 CPU를 고려하지 않으며 컨트롤러 CPU 파워를 무제한이라고 가정한다.

네트워크 대역폭 네트워크 대역폭을 최대로 활용하기 위해 필요한 SSD
컨트롤러 연결 가용한 네트워크 대역폭 읽기 I/O 쓰기 I/O
Dual 4Gb FC 8Gb == 1GB 2 3
Dual 8Gb FC 16Gb == 2GB 4 5
Dual 16Gb FC 32Gb == 4GB 8 9
Dual 32Gb FC 64Gb == 8GB 16 19
Dual 1Gb ETH 2Gb == 0.25GB 1 1
Dual 10Gb ETH 20Gb == 2.5GB 5 6

상기 테이블에서 보는 것과 같이 SSD가 제공할 수 있는 이론적인 최대 성능을 활용하고자 할 때, 활용되는 네트워킹의 유형에 따라 1 ~ 9개의 SSD를 사용하는 어떤 경우에서든 네트워크가 병목현상의 원인이 될 수 있다.

메모리 레이턴시에 미치는 영향

일반적인 메인 메모리 레이턴시는 ~100ns(가변적임)이며 다음과 같은 계산을 수행할 수 있다.

  • Local memory read latency = 100ns + [OS / hypervisor overhead]
  • Network memory read latency = 100ns + NW RTT latency + [2 x OS / hypervisor overhead]

일반적인 네트워크 RTT가 ~0.5ms(500000ns, 스위치 벤더에 따라 가변적임)라고 가정하면 계산식은 다음과 같다.

  • Network memory read latency = 100ns + 500,000ns + [2 x OS / hypervisor overhead]

이론적으로 10,000ns RTT를 제공하는 매우 빠른 네트워크를 가정하면 계산식은 다음과 같다.

  • Network memory read latency = 100ns + 10,000ns + [2 x OS / hypervisor overhead]

이것이 의미하는 바는 이론적으로 빠른 네트워크라고 하더라도 네트워크가 아닌 메모리 액세스와 비교하면 약 10,000%의 오버헤드가 있다는 것이다. 네트워크 속도가 느린 경우에 레이턴시가 500,000% 이상 증가할 수 있다.

이러한 오버헤드를 줄이기 위해 서버 측 캐싱 기술이 도입되었다.

유저 스페이스와 커널 스페이스

자주 논의되는 주제 중의 하나는 커널 스페이스와 유저 스페이스에서 수행되는 작업과 관련된 논쟁이다. 여기에서 각각이 무엇인지, 그리고 각각의 장단점에 대해 설명한다.

모든 운영체제(OS)에는 두 가지 핵심 실행 영역이 있다.

  • 커널 스페이스 (Kernel Space)
    • OS에서 가장 많은 권한을 갖는 부분
    • 스케줄링, 메모리 관리 등을 처리
    • 물리적 디바이스 드라이버를 포함하고 하드웨어 상호작용을 처리
  • 유저 스페이스 (User Space)
    • 커널 스페이스 이외의 모든 것
    • 대부분의 애플리케이션과 프로세스가 있는 곳
    • 보호된 메모리 및 실행

이 두 개의 스페이스는 OS 오퍼레이션을 위해 함께 동작한다. 다음 단계로 넘어가기 전에 몇 가지 주요 항목을 정의한다.

  • 시스템 콜 (System Call)
    • 커널 콜(Kernel Call)이라고도 불리는데, 액티브 프로세스에서 인터럽트(자세한 것은 나중에 설명)를 통해 생성된 요청으로 커널에 의해 수행되는 어떤 작업
  • 컨텍스트 스위치 (Context Switch)
    • 실행을 프로세스에서 커널로 또는 그 반대로 이동

예를 들어, 일부 데이터를 디스크에 쓰는 간단한 애플리케이션인 경우에 다음과 같은 순서로 작업이 수행된다.

  1. 애플리케이션이 디스크에 데이터를 쓰려고 한다.
  2. 시스템 콜을 호출한다.
  3. 커널로 컨텍스트를 전환한다.
  4. 커널이 데이터를 복사한다.
  5. 드라이버를 통해 디스크에 쓰기를 실행한다.

다음은 이러한 상호작용의 예를 보여준다.

User and Kernel Space Interaction
Figure. 유저 및 커널 스페이스 상호작용 (User and Kernel Space Interaction)

하나가 다른 것보다 나은가? 현실에는 각각 장단점이 있다.

  • 유저 스페이스 (User Space)
    • 매우 유연함
    • 장애 도메인의 격리 (프로세스)
    • 비효율적일 수 있음
      • 컨텍스트 스위치를 전환하는 데 걸리는 시간 (~1,000ns)
  • 커널 스페이스 (Kernel Space)
    • 매우 엄격함
    • 장애 도메인이 넓음
    • 효율적일 수 있음
      • 컨텍스트 스위치를 줄임

폴링과 인터럽트

또 다른 핵심 컴포넌트는 이 둘 사이의 상호작용을 처리하는 방법이다. 상호작용에는 두 가지 주요 유형이 있다.

  • 폴링 (Polling)
    • 끊임없이 "POLL", e.g. 지속적으로 무언가를 요청
    • 예: 마우스, 모니터 새로 고침 빈도 등
    • CPU를 지속적으로 요구하지만 레이턴시는 훨씬 짧음
    • 커널 인터럽트 핸들러 비용 제거
      • 컨텍스트 스위치를 제거
  • 인터럽트 (Interrupt)
    • "미안하지만, 나는 FOO가 필요해"
    • 예: 무언가의 요청을 위해 손을 듦
    • "CPU 효율"이 더 높을 수 있지만 반드시 그런 것은 아님
    • 일반적으로 훨씬 더 높은 레이턴시

유저 스페이스 / 폴링으로 이동

디바이스가 훨씬 빨라짐에 따라 (e.g. NVMe, 인텔 Optane, pMEM), 커널과 디바이스 상호작용이 병목현상이 되었다. 이러한 병목현상을 없애기 위해 많은 벤더가 작업을 커널에서 폴링 기반의 유저 스페이스로 옮김으로써 훨씬 나은 결과를 얻었다.

이에 대한 좋은 사례가 인텔의 Storage Performance Development Kit (SPDK)Data Plane Development Kit (DPDK)이다. 이 프로젝트들은 성능을 극대화하고 가능한 한 레이턴시를 줄이는 데 중점을 두고 있으며 큰 성공을 거두었다.

이러한 변화는 두 가지 핵심 변경으로 이루어져 있다.

  1. 디바이스 드라이버를 유저 스페이스로 이동 (커널 대신)
  2. 폴링 사용 (인터럽트 대신)

이는 커널 기반의 작업과 비교했을 때 훨씬 뛰어난 성능을 제공하는 데 다음을 제거하였기 때문에 가능하게 되었다.

  • 값비싼 시스템 콜 및 인터럽트 핸들러
  • 데이터 복사
  • 컨텍스트 스위치

다음은 유저 스페이스 드라이버를 사용하는 디바이스 상호작용을 보여준다.

User Space and Polling Interaction
Figure. 유저 스페이스와 폴링 상호작용 (User Space and Polling Interaction)

사실은 뉴타닉스가 AHV 제품(vhost-user-scsi)을 위해 개발했던 일부 소프트웨어가 인텔의 SPDK 프로젝트에 실제적으로 사용되고 있다.

Book of Web-Scale

web·scale - /web ' skal/ - noun - computing architecture
a new architectural approach to infrastructure and computing.

본 섹션에서는 “웹-스케일(Web-Scale)” 인프라의 몇 가지 핵심 개념과 이를 활용하는 이유에 대해 설명한다. 시작하기 전에 분명하게 언급하고 싶은 것은 "웹-스케일은 웹-스케일(e.g. Google, Facebook, Microsoft)이 되어야 한다는 것을 의미하는 것은 아니다"라는 것이다.. “웹-스케일” 구조는 어떤 규모(세 개의 노드 또는 수천 개의 노드)에서도 적용 가능하며 많은 장점을 제공한다.

역사적으로 도전 과제는 다음과 같다.

  • 복잡성, 복잡성, 복잡성
  • 증분 기반 성장에 대한 요구
  • 민첩성 필요

"웹 스케일" 인프라에 대해 이야기할 때 사용되는 몇 가지 핵심 컨스트럭트가 있다.

  • 하이퍼컨버전스 (Hyper-convergence)
  • 소프트웨어 정의 인텔리전스 (Software defined intelligence)
  • 분산 자율 시스템 (Distributed autonomous system)
  • 증분 및 선형 스케일 아웃 (Incremental and linear scale out)

기타 관련 항목은 다음과 같다.

  • API 기반 자동화 및 풍부한 분석 기능 (API-based automation and rich analytics)
  • 핵심 테넌트로서의 보안 (Security as a core tenant)
  • 셀프 힐링 (Self-healing)

다음 섹션에서 그들이 실제로 무엇을 의미하는지에 대한 기술적 관점을 제공한다.

하이퍼컨버전스

하이퍼컨버전스(Hyper-convergence)가 실제로 무엇을 의미하는지에 대해서는 의견이 분분하다. 또한 컴포넌트(e.g. 가상화, 네트워킹 등)의 범위에 따라 다르다. 그러나 핵심 개념은 다음과 같다: 기본적으로 두 개 이상의 컴포넌트를 하나의 유닛으로 결합한다. 여기에서 “기본적으로(Natively)”가 핵심 단어이다. 가장 효과적이기 위해서는 컴포넌트가 기본적으로 통합되어야 하며 단순히 함께 번들 되어서는 안된다. 뉴타닉스의 경우 컴퓨트 + 스토리지를 기본적으로 통합하여 어플라이언스에서 사용되는 단일 노드를 구성한다. 다른 벤더에게는 스토리지를 네트워크 등과 통합하는 것이 될 수 있다.

하이퍼컨버전스가 실제적으로 의미하는 것은 다음과 같다.

  • 쉽게 확장할 수 있도록 두 개 이상의 컴포넌트를 단일 유닛(Single Unit)으로 기본적으로 통합하는 것

장점은 다음과 같다.

  • 유닛 단위로 확장
  • 로컬 I/O 지원
  • 컴퓨트와 스토리지를 통합함으로써 기존 컴퓨트/스토리지 사일로 제거

소프트웨어 정의 인텔리전스

소프트웨어 정의 인텔리전스(Software-Defined Intelligence)는 일반적으로 전용 또는 특정 하드웨어(e.g. ASIC/FPGA)에 구현된 핵심 로직을 범용 하드웨어에서 소프트웨어로 구현하는 것이다. 뉴타닉스의 경우 기존 스토리지 로직(e.g. RAID, 중복제거, 압축 등)을 표준 하드웨어에 탑재된 각 뉴타닉스 컨트롤러 VM(CVM)에서 실행되는 소프트웨어로 구현하였다.

Note
지원되는 아키텍처

뉴타닉스는 현재 x86 및 IBM POWER 아키텍처를 모두 지원한다.

소프트웨어 정의 인텔리전스의 실제적인 의미는 다음과 같다.

  • 하드웨어에서 핵심 로직을 가져와 범용 하드웨어에서 소프트웨어로 수행

장점은 다음과 같다.

  • 빠른 릴리스 사이클
  • 전용 하드웨어에 대한 의존성 제거
  • 더 나은 경제성을 위해 범용 하드웨어 활용
  • 평생 투자 보호

평생 투자 보호(Lifespan Investment Protection)에 대해 좀 더 부연 설명하면: 구형 하드웨어에서 최신 및 최고의 소프트웨어를 실행할 수 있다. 이것은 감가상각 주기에 들어간 하드웨어에서 최신 소프트웨어를 실행시킬 수 있으며 공장에서 출하된 새로운 제품과 기능적으로 동일하다는 것을 의미한다.

분산 자율 시스템

분산 자율 시스템(Distributed Autonomous Systems)은 단일 유닛이 어떤 일의 수행에 대한 책임을 갖는 기존 개념에서 벗어나 클러스터 내의 모든 노드에게 그 역할을 분산하는 것을 포함한다. 이것을 순수 분산 시스템을 만드는 것으로 생각할 수 있다. 전통적으로 벤더는 하드웨어가 매우 안정적일 것이라고 가정했는데 이것은 대부분의 경우에 사실일 수 있다. 그러나 분산 시스템의 핵심은 하드웨어 장애가 궁극적으로 발생할 것이고 해당 장애를 우아하고 중단 없는 방식으로 처리하는 것이 중요하다는 아이디어이다.

분산 시스템은 장애를 수용하고 치료하며 셀프-힐링 및 자율적인 무언가를 형성하도록 설계되었다. 컴포넌트 장애 시에 시스템은 장애를 투명하게 처리 및 치료하며 예상된 오퍼레이션을 지속한다. 경고를 통해 관리자가 장애 상황을 인지할 수 있지만 시간에 민감한 치명적인 사항이 아니면 어떤 조치(e.g. 장애 노드 교체)는 관리자의 일정에 맞추어 수행될 수 있다. 다른 방법은 장애가 발생한 상태로 두는 것이다(교체 없는 리빌드). “마스터(Master)”가 필요한 항목인 경우에 선거 프로세스가 활용된다. 이 마스터가 실패하면 새로운 마스터가 선출된다. 작업 처리를 분산하기 위해 맵리듀스(MapReduce) 개념이 활용된다.

분산 자율 시스템이 실제적으로 의미하는 것은 다음과 같다.

  • 시스템 내의 모든 노드에 역할 및 책임을 분산
  • 맵리듀스와 같은 개념을 활용하여 작업의 분산 처리 수행
  • “마스터”가 필요한 경우에 선거 프로세스 사용

장점은 다음과 같다.

  • SPOF 제거
  • 워크로드를 분산하여 병목현상 제거

증분 및 선형 스케일아웃

증분 및 선형 스케일아웃(Incremental and Linear Scale-out)은 특정 규모의 자원으로 시작하고 필요할 때 시스템을 확장함과 동시에 시스템의 성능을 선형적으로 증가시키는 기능과 관련되어 있다. 위에서 언급한 모든 컨스트럭트는 이것을 실현하는 데 중요한 역할을 한다. 예를 들어 전통적으로 가상 워크로드를 실행하기 위해 3-계층의 컴포넌트가 있다: 서버, 스토리지, 네트워크 - 이들 각각은 독립적으로 확장된다. 예를 들어 서버 수를 확장할 때 스토리지 성능을 확장하지 않는다. 뉴타닉스와 같은 하이퍼컨버지드 플랫폼을 사용하면 새로운 노드를 확장할 때 다음과 같은 자원이 자원이 동시에 확장된다.

  • 하이퍼바이저 / 컴퓨트 노드 수
  • 스토리지 컨트롤러 수
  • 컴퓨트 및 스토리지 성능 / 용량
  • 클러스터 전체 오퍼레이션에 참여하는 노드 수

증분 및 선형 스케일아웃이 실제적으로 의미하는 것은 다음과 같다.

  • 성능/능력을 선형적으로 증가시키면서 스토리지/컴퓨트를 점진적으로 확장할 수 있는 기능

장점은 다음과 같다.

  • 작은 규모로 시작하고 확장하는 기능
  • 규모에 관계없이 균일하고 일관성 있는 성능

요약 정리

웹-스케일 인프라의 특징을 요약하면 다음과 같다.

  1. 비효율적인 컴퓨트 활용률이 가상화로 이동하는 계기가 되었다.
  2. vMotion, HA, DRS 등과 같은 기능은 중앙 집중식 스토리지를 요구하였다.
  3. VM 스프롤은 스토리지에서 부하 및 경합이 증가하였다.
  4. SSD가 이슈를 줄이기 위해 도입되었으나 병목현상이 네트워크/컨트롤러로 변경되었다.
  5. 네트워크를 통한 캐시/메모리 액세스는 오버헤드가 커서 장점이 최소화되었다.
  6. 어레이 설정의 복잡성은 여전히 동일한 상태로 남아 있다.
  7. 서버 측 캐시가 어레이 부하 및 네트워크 영향을 줄이기 위해 도입되었으나 솔루션에 다른 컴포넌트를 추가시켰다.
  8. 로컬리티는 전통적으로 네트워크를 경유할 때 직면하는 병목현상 및 오버헤드를 줄이는 데 도움을 준다.
  9. 포커스가 인프라에서 관리 편의성 및 스택 단순화로 이동되었다.
  10. 웹-스케일 세계의 탄생!

Part 1: Core

Book of Basics

일반화된 'Book of Webscale'에서 설명한 바와 같이 뉴타닉스는 스택 전체에서 이러한 원칙을 활용한다. 본 섹션에서 핵심 아키텍처 개념뿐만 아니라 이러한 기본사항을 다룬다.

제품 및 플랫폼

수년 동안 뉴타닉스 제품 기능 세트 및 포트폴리오가 크게 성장했다. 본 섹션에서 현재 포트폴리오 및 파트너십에 대해 다룬다. NOTE: 최신 포트폴리오 및 오퍼링에 대해서는 뉴타닉스 웹 페이지를 참조한다.

뉴타닉스가 태어났을 때 뉴타닉스는 정말로 한 가지에 집중했다: "스토리지 단순화". 이를 위해 로컬 스토리지 자원을 인텔리전트 소프트웨어와 결합하여 "중앙 집중식 스토리지"와 같은 기능을 제공하는 분산 스토리지 패브릭(Distributed Storage Fabric: DSF는 초창기에 뉴타닉스 분산 파일 시스템(Nutanix Distributed File System: NDFS)으로 불렸음)이라는 기능으로 해결했다.

제품에 대해 이야기하기 보다 수년 동안 제품 포트폴리오가 성장함에 따라 오히려 결과 및 그것을 달성하기 위한 여정에 초점을 맞추고자 한다. 다음 단계에서 고객의 "여정(Journey)"과 뉴타닉스가 고객이 그것을 달성할 수 있도록 도와준 결과에 대해 다룬다.

1단계: 데이터센터 현대화 (Core: 코어)

코어(Core)는 복잡한 3-티어 인프라에서 간단한 HCI 플랫폼으로의 마이그레이션을 용이하게 하는 기본 뉴타닉스 제품을 포함한다. AOS는 모든 핵심 서비스(스토리지, 업그레이드, 복제 등)를 제공하고, 프리즘(Prism)은 컨트롤 플레인 및 관리 콘솔을 제공하며, AHV는 무료 가상화 플랫폼(NOTE: ESXi, Hyper-V 및 XenServer를 사용할 수 있음)을 제공한다.

코어(Core) 기능은 다음을 포함한다.

  • 핵심 플랫폼 (HCI)
  • 스토리지 서비스
  • 가상화
  • 중앙 집중식 관리 및 운영
  • 업그레이드
  • 복제 / DR
Products Ecosystem - Core
Figure. 제품 에코시스템 - 코어 (Products Ecosystem - Core)
2단계: 프라이빗 클라우드 지원 (Essentials: 에센셜)

에센셜(Essentials)은 핵심 인프라를 프라이빗 클라우드처럼 사용할 수 있는 기능을 제공하는 데 중점을 둔다. Flow는 네트워크 세그멘테이션 및 보안 기능을 제공하고, Files는 파일 서비스를 제공하며, Calm은 셀프서비스, 쿼터 및 오케스트레이션 기능을 제공한다.

에센셜(Essentials) 기능은 다음을 포함한다.

  • 고급 분석 및 이상 징후 탐지
  • 자동화 및 오케스트레이션
  • 셀프서비스 포탈 및 쿼터
  • 마이크로세그멘테이션
  • 파일 서비스
Products Ecosystem - Private Cloud
Figure. 제품 에코시스템 - 프라이빗 클라우드 (Products Ecosystem - Private Cloud)
3단계: 하이브리드 클라우드 지원 (Enterprise: 엔터프라이즈)

엔터프라이즈(Enterprise)는 클라우드와 클라우드 서비스 간의 워크로드 마이그레이션 기능을 제공하는 데 중점을 둔다. 여기에는 클라우드와 온-프레미스 배포에서 비용 거버넌스 및 컴플라이언스 기능을 제공하는 Beam 뿐만 아니라 Frame(DaaS), Xi Leap(DRaaS) 등과 같은 다른 클라우드 서비스가 포함된다.

엔터프라이즈(Enterprise) 기능은 다음을 포함한다.

  • 정책 기반 DR / 런북 자동화
  • DRaaS
  • 하이브리드 클라우드 비용 거버넌스 및 컴플라이언스
  • Desktops As-A-Service (DaaS)
  • Database As-A-Service (RDS)
  • 쿠버네티스 / 도커 서비스
  • 오브젝트 스토리지
  • 블록 서비스
Products Ecosystem - Hybrid Cloud
Figure. 제품 에코시스템 - 하이브리드 클라우드 (Products Ecosystem - Hybrid Cloud)
플랫폼

뉴타닉스는 현재 다음 플랫폼을 지원한다.

  • 뉴타닉스 어플라이언스 (Nutanix Appliance)
    • NX (Supermicro)
    • HPE Powered (Coming soon!)
  • OEM 어플라이언스 (OEM Appliance)
    • Nutanix on Lenovo HX
    • Nutanix on IBM CS
    • Nutanix on Dell XC
  • 3rd 파티 서버 지원 (Third-Party Server Support)
    • Nutanix on HPE ProLiant and Apollo
    • Nutanix on Cicsco UCS
    • Nutanix on Intel Data Center Blocks
    • Nutanix Tactical and Ruggedized platforms on Klas

하이퍼컨버지드 플랫폼

동영상 시청을 원하시면 다음 링크를 클릭하세요: LINK


하이퍼컨버지드 시스템을 위한 몇 가지 핵심 구조가 있다.

  • 컴퓨팅 스택(e.g. 컴퓨트 + 스토리지)을 통합하고 단순화해야 한다.
  • 시스템의 노드들 간에 데이터와 서비스를 분할(분산) 해야 한다.
  • 중앙 집중식 스토리지와 동일한 기능(e.g. HA, 라이브 마이그레이션 등)을 제공해야 한다.
  • 데이터를 가능한 한 실행(컴퓨트)과 가깝게 유지해야 한다 (레이턴시의 중요성).
  • 하이퍼바이저와 무관해야 한다.
  • 하드웨어와 무관해야 한다.

다음 그림은 일반적인 3-티어 스택과 하이퍼컨버지드 스택의 예를 보여준다.

3-Tier vs. HCI
Figure. 3-티어 vs. HCI (3-Tier vs. HCI)

보시다시피 하이퍼컨버지드 시스템은 다음을 수행한다.

  • 컨트롤러를 가상화하여 호스트로 이동
  • 소프트웨어를 통해 핵심 서비스 및 로직 제공
  • 시스템의 모든 노드에 데이터 분산(분할)
  • 스토리지를 컴퓨트의 로컬로 이동

뉴타닉스 솔루션은 워크로드를 실행하기 위해 로컬 컴포넌트를 활용하여 분산 플랫폼을 생성하는 "컴퓨트 + 스토리지"가 컨버지드 된 솔루션이다.

각 노드는 업계 표준 하이퍼바이저(현재 ESXi, AHV, Hyper-V and XenServer 지원) 및 뉴타닉스 컨트롤러 VM(Controller VM: CVM)을 실행한다. 뉴타닉스 CVM은 뉴타닉스 소프트웨어를 실행하고 해당 호스트에서 실행 중인 하이퍼바이저 및 모든 VM에게 모든 I/O 오퍼레이션 서비스를 제공한다.

다음 그림은 일반적인 노드가 논리적으로 어떻게 보이는지에 대한 예를 제공한다.

Converged Platform
Figure 10-3. 컨버지드 플랫폼 (Converged Platform)

뉴타닉스 CVM은 핵심 뉴타닉스 플랫폼 로직을 담당하며 다음과 같은 서비스를 처리한다.

  • 스토리지 I/O 및 변환 (중복제거, 압축, Erasure Coding)
  • UI / API
  • 업그레이드
  • DR / 복제
  • 기타

NOTE: 일부 서비스/기능은 추가 헬퍼 VM을 생성하거나 MSP(Microservices Platform)를 사용한다. 예를 들어 뉴타닉스 파일(Files)은 추가 VM을 배포하는 반면 뉴타닉스 오브젝트(Objects)는 MSP 용 VM을 배포하고 이를 활용한다.

VMware vSphere를 실행하는 뉴타닉스 유닛의 경우 SSD 및 HDD 디바이스를 관리하는 SCSI 컨트롤러는 VM-Direct 경로(인텔 VT-d)를 활용하는 CVM으로 직접 전달된다. Hyper-V의 경우 스토리지 디바이스는 CVM으로 전달된다.

Note
컨트롤러 가상화 (Virtualizing the Controller)

유저 스페이스에서 뉴타닉스 컨트롤러를 VM으로 실행하는 주요 이유는 크게 두 가지 핵심 영역으로 나뉜다.

  1. 모빌리티 (Mobility)
  2. 리질리언시 (Resiliency)

처음부터 우리는 우리가 단일 플랫폼 회사 이상이라는 것을 알고 있었다. 이러한 의미에서 그것이 하드웨어든 클라우드든 하이퍼바이저 벤더든 선택은 우리에게 항상 매우 중요한 일이었다.

유저 스페이스에서 VM으로 실행함으로써 뉴타닉스 소프트웨어를 기반 하이퍼바이저 및 하드웨어 플랫폼과 분리한다. 이를 통해 우리는 모든 운영 환경(온-프레미스 및 클라우드)에서 핵심 코드 베이스를 동일하게 유지하면서 다른 하이퍼바이저에 대한 지원을 신속하게 추가할 수 있었다. 추가적으로 우리에게 벤더 별 릴리스 주기에 구애받지 않는 유연성을 제공했다.

유저 스페이스에서 VM으로 실행되는 특성으로 인해 하이퍼바이저 외부에 있는 업그레이드 또는 CVM 장애와 같은 작업을 정교하게 처리할 수 있다. 예를 들어 CVM이 다운되는 치명적인 문제가 발생하더라도 전체 노드는 클러스터의 다른 CVM에서 오는 스토리지 I/O 및 서비스로 오퍼레이션을 지속한다. AOS (뉴타닉스 핵심 소프트웨어) 업그레이드 중에 해당 호스트에서 실행 중인 워크로드에 영향을 주지 않고 CVM을 재기동할 수 있다.

분산 시스템

분산 시스템에는 세 가지 매우 핵심적인 원칙이 있다.

  1. SPOF가 없어야 한다.
  2. 규모에 관계없이 병목현상이 없어야 한다 (선형적인 확장이 가능해야 함).
  3. 동시 실행 기능을 활용해야 한다 (MapReduce).

뉴타닉스 노드 그룹은 함께 프리즘 및 아크로폴리스 기능 제공을 담당하는 분산 시스템(뉴타닉스 클러스터)을 구성한다. 모든 서비스 및 컴포넌트는 고가용성 및 확장 시 선형적인 성능 제공을 위해 클러스터의 모든 CVM에 분산된다.

다음 그림은 이러한 뉴타닉스 노드가 뉴타닉스 클러스터를 구성하는 방법의 예를 보여준다.

Distributed Storage Fabric Overview
Figure 11-1. 뉴타닉스 클러스터 - 분산 시스템 (Nutanix Cluster - Distributed System)

이러한 기술은 메타데이터와 데이터에 동일하게 적용된다. 메타데이터와 데이터가 모든 노드와 모든 디스크 디바이스에 분산되도록 함으로써 정상적인 데이터 입력 및 재보호 중에 가능한 최고의 성능을 보장할 수 있다.

이를 통해 맵리듀스 프레임워크(Curator)는 클러스터의 모든 자원을 활용하여 액티비티를 동시에 수행할 수 있다. 샘플 액티비티에는 데이터 재보호, 압축, Erasure Coding, 중복제거 등이 포함된다.

다음 그림은 클러스터의 확장에 따라 각 노드에서 처리되는 작업 비율(%)을 어떤 방식으로 현저하게 감소되는지를 보여준다.

Work Distribution - Cluster Scale
Figure. 작업 분포 - 클러스터 규모 (Work Distribution - Cluster Scale)

Key Point: 클러스터 내의 노드 수가 증가함에 따라 (클러스터 확장), 각 노드가 작업의 일부만을 처리하기 때문에 실제로 특정 액티비티가 더 효율적으로 된다.

소프트웨어 정의

소프트웨어 정의 시스템에는 세 가지 핵심 원칙이 있다.

  • 플랫폼 이동성을 제공하여야 한다 (하드웨어, 하이퍼바이저)
  • 맞춤 하드웨어에 의존해서는 안 된다.
  • 빠른 개발 속도를 제공해야 한다 (기능, 버그 수정, 보안 패치).
  • 무어 법칙의 장점을 활용해야 한다.

위에서 언급한 바와 같이 (아마도 여러 번) 뉴타닉스 플랫폼은 번들 된 소프트웨어 + 하드웨어 어플라이언스로 제공되는 소프트웨어 기반 솔루션이다. 컨트롤러 VM(Controller VM)은 뉴타닉스 소프트웨어 및 로직의 대부분이 있는 곳으로 처음부터 확장 가능하고 플러그인이 가능한 아키텍처로 설계되었다. 소프트웨어로 정의되고 하드웨어 오프로드 또는 구조에 의존하지 않는 주요 이점은 확장성에 있다. 모든 제품 수명주기와 마찬가지로 고급 및 새로운 기능이 항상 도입될 것이다.

맞춤형 ASIC/FPGA 또는 하드웨어 기능에 의존하지 않음으로써 뉴타닉스는 간단한 소프트웨어 업데이트를 통해 이러한 새로운 기능을 개발하고 배포할 수 있다. 즉 현재 버전의 뉴타닉스 소프트웨어를 업그레이드하여 새로운 기능(e.g. 중복제거)을 배포할 수 있다. 또한 레거시 하드웨어 모델에 새로운 세대의 기능을 배포할 수 있다. 예를 들어 이전 세대의 하드웨어 플랫폼(e.g. 2400)에서 구 버전의 뉴타닉스 소프트웨어로 워크로드를 실행하고 있다고 가정한다. 실행 중인 소프트웨어 버전은 워크로드에게 큰 도움이 될 수 있는 중복제거 기능을 제공하지 않는다. 이러한 기능을 사용하려면 워크로드가 실행되는 동안 뉴타닉스 소프트웨어 버전의 롤링 업그레이드를 수행하면 중복제거 기능을 사용할 수 있다. 정말로 그렇게 쉽다.

기능과 마찬가지로 DSF에 새로운 "어댑터" 또는 인터페이스를 만드는 것이 또 다른 핵심 능력이다. 제품이 처음 출시되었을 때 하이퍼바이저 I/O를 위해 단지 iSCSI만을 지원하였지만 이제는 NFS 및 SMB를 포함하도록 확장되었다. 향후에는 다양한 워크로드 및 하이퍼바이저를 (HDFS 등) 위한 새로운 어댑터를 만들 수 있다. 다시 반복하지만 이러한 모든 것은 소프트웨어 업데이트를 통해 배포될 수 있다. 이는 "최신 및 최고" 기능을 적용하기 위해 하드웨어 업그레이드 또는 일반적으로 소프트웨어 구매를 필요로 하는 대부분의 레거시 인프라와 반대되는 특징이다. 뉴타닉스를 사용하면 다르다. 모든 기능이 소프트웨어로 배포되므로 모든 하드웨어 플랫폼, 모든 하이퍼바이저에서 실행할 수 있으며 간단한 소프트웨어 업그레이드를 통해 배포될 수 있다.

디음 그림은 소프트웨어 정의 컨트롤러 프레임워크의 논리적인 표현을 보여준다.

Software-Defined Controller Framework
Figure 10-4. 소프트웨어 정의 컨트롤러 프레임워크 (Software-Defined Controller Framework)

클러스터 컴포넌트

동영상 시청을 원하시면 다음 링크를 클릭하세요: LINK


사용자 중심의 뉴타닉스 제품은 배포 및 운영이 매우 간단하다. 이것은 주로 추상화와 소프트웨어에서 많은 자동화/통합을 통해 가능하다.

다음은 메인 뉴타닉스 클러스터 컴포넌트에 대한 상세한 설명이다 (모든 것을 암기하거나 알 필요가 없으니 걱정하지 마세요).

Nutanix Cluster Components
Figure 10-5. 뉴타닉스 클러스터 컴포넌트 (Nutanix Cluster Components)
카산드라 (Cassandra)
  • 주요 역할: 분산 메타데이터 스토어
  • 설명: 카산드라는 크게 수정된 Apache Cassandra를 기반으로 모든 클러스터 메타데이터를 분산 링 방식으로 저장하고 관리한다. PAXOS 알고리즘이 “엄격한 일관성(Strict Consistency)”을 유지하기 위해 사용된다. 이 서비스는 클러스터의 모든 노드에서 실행된다. 카산드라는 메두사(Medusa)로 불리는 인터페이스를 통해 액세스 된다.
주키퍼 (Zookeeper)
  • 주요 역할: 클러스터 설정 매니저
  • 설명: 주키퍼는 호스트, IP 주소, 상태 등을 포함한 모든 클러스터 설정 정보를 저장하며 Apache Zookeeper를 기반으로 한다. 이 서비스는 클러스터의 세 노드에서 실행되며 그중 하나가 리더로 선출된다. 리더는 모든 요청을 받아 동료들에게 전달한다. 만약 리더가 응답하지 않으면 새로운 리더가 자동으로 선출된다. 주키퍼는 제우스(Zeus)로 불리는 인터페이스를 통해 액세스 된다.
스타게이트 (Stargate)
  • 주요 역할: 데이터 I/O 매니저
  • 설명: 스타게이트는 모든 데이터 관리 및 I/O 오퍼레이션을 담당하며 하이퍼바이저(NFS, iSCSI, 또는 SMB를 통해)의 메인 인터페이스이다. 이 서비스는 로컬 I/O를 지원하기 위해 클러스터의 모든 노드에서 실행된다.
큐레이터 (Curator)
  • 주요 역할: 맵 리듀스 클러스터 관리 및 정리
  • 설명: 큐레이터는 클러스터 전체에서 작업을 관리하고 분산하는 역할을 담당하며 디스크 밸런싱, 사전 예방적 스크러빙 등과 같은 많은 작업을 수행한다. 큐레이터는 모든 노드에서 실행되며 태스크(Task) 및 잡(Job) 위임을 담당하는 선출된 큐레이터 마스터에 의해 제어된다. 큐레이터는 두 가지 스캔 유형이 있는데 전체 스캔(Full Scan)은 6시간 주기로 부분 스캔(Partial Scan)은 1시간 주기로 발생한다.
프리즘 (Prism)
  • 주요 기능: UI 및 API
  • 설명: 프리즘은 컴포넌트 및 관리자가 뉴타닉스 클러스터를 설정하고 모니터링할 수 있는 관리 게이트웨이이다. 여기에는 nCLI, HTML5 UI 및 REST API가 포함된다. 프리즘은 클러스터의 모든 노드에서 실행되며 클러스터의 모든 컴포넌트와 같이 선출된 리더를 사용한다.
제네시스 (Genesis)
  • 주요 역할: 클러스터 컴포넌트 및 서비스 매니저
  • 설명: 제네시스는 각 노드에서 실행되는 프로세스로 초기 설정뿐만 아니라 모든 서비스 상호작용(시작/중지 등)을 담당한다. 제네시스는 클러스터와 독립적으로 실행되는 프로세스로 클러스터 설정/실행을 요구하지 않는다. 제네시스가 실행되기 위한 유일한 요구 사항은 주키퍼가 기동되어 실행 중이어야 한다는 것이다. cluster_init 및 cluster_status 페이지는 제네시스에 의해 출력된다.
크로노스 (Chronos)
  • 주요 역할: 잡 및 태스크 스케줄러
  • 설명: 크로노스는 큐레이터 스캔 및 노드 간의 스케줄링/스로틀링의 결과로 발생되는 잡 및 테스크를 인계받는다. 크로노스는 모든 노드에서 실행되며 태스크 및 잡 위임을 담당하고 큐레이터 마스터와 동일한 노드에서 실행되는 선출된 크로노스 마스터에 의해 제어된다.
세레브로 (Cerebro)
  • 주요 역할: 복제/DR 매니저
  • 설명: 세레브로는 DSF의 복제 및 DR 기능을 담당한다. 여기에는 스냅샷 스케줄링, 원격 사이트로의 복제, 사이트 마이그레이션/페일오버가 포함된다. 세레브로는 클러스터의 모든 노드에서 실행되며 모든 노드가 원격 클러스터/사이트로의 복제에 참여한다.
피토스 (Pithos)
  • 주요 역할: vDisk 설정 매니저
  • 설명: 피토스는 vDisk (DSF에서 파일) 설정 데이터를 담당한다. 피토스는 모든 노드에서 실행되며 카산드라를 기반으로 구현되었다.

무중단 업그레이드

Book of Prism의 '뉴타닉스 소프트웨어 업그레이드' 및 '하이퍼바이저 업그레이드' 섹션에서 AOS 및 하이퍼바이저 버전 업그레이드를 수행하는 데 사용되는 단계를 강조하였다. 본 섹션에서는 다양한 유형의 업그레이드를 무중단 방식으로 수행할 수 있는 기술에 대해 다룬다.

AOS 업드레이드

AOS 업그레이드의 경우 수행되는 몇 가지 핵심 단계가 있다.

1 - 업그레이드 사전 검사

업그레이드 사전 검사 중에 다음 항목이 검증된다. NOTE: 업그레이드를 계속하려면 이 작업이 성공적으로 완료되어야 한다.

  • AOS, 하이퍼바이저 버전 간의 버전 호환성 확인
  • 클러스터 헬스 체크 (클러스터 상태, 여유 공간) 및 컴포넌트 체크 (e.g. 메두사, 스타게이트, 주키퍼 등)
  • 모든 CVM과 하이퍼바이저 간의 네트워크 연결 확인
2 - 업그레이드 소프트웨어를 두 노드에 업로드

업그레이드 사전 검사가 완료되면 시스템은 업그레이드 소프트웨어 바이너리를 클러스터의 두 노드에 업로드한다. 이것은 폴트-톨러런스를 위해 수행되는데 하나의 CVM이 재부팅하면 다른 CVM이 다른 소프트웨어를 가져올 수 있도록 한다.

3 - 업그레이드 소프트웨어 단계

소프트웨어가 두 CVM에 업로드되면 모든 CVM은 병렬로 업그레이드를 준비한다.

CVM에는 AOS 버전 용으로 두 개의 파티션이 있다.

  • 활성 파티션 (Active Partition) - 현재 실행 중인 버전
  • 수동 파티션 (Passive Partition) - 업그레이드가 준비되는 곳

AOS 업그레이드가 발생하면 비횔성 파티션에서 업그레이드를 수행한다. 업그레이드 토큰이 수신되면 업그레이드된 파티션을 액티브 파티션으로 표시하고 CVM을 업그레이드된 버전으로 재부팅한다. 이는 bootbank / altbootbank와 유사하다.

NOTE: 업그레이드 토큰은 노드 간에 반복적으로 전달된다. 이를 통해 한 번에 하나의 CVM만 재부팅한다. CVM이 재부팅되고 안정되면(서비스 상태 및 통신 확인) 모든 CVM이 업그레이드될 때까지 토큰을 다음 CVM으로 전달할 수 있다.

Note
업그레이드 오류 처리 (Upgrade Error Handling)

일반적인 질문은 업그레이드가 성공적이지 않거나 부분적으로 프로세스에 이슈가 있으면 무슨 일이 발생하는가에 대한 것이다.

일부 업그레이드 이슈가 발생할 경우 업그레이드는 중지되고 진행되지 않는다. NOTE: 업그레이드가 실제로 시작되기 전에 업그레이드 사전 검사에서 대부분의 문제를 발견할 수 있기 때문에 이는 매우 드문 경우이다. 그러나 업그레이드 사전 검사가 성공하고 실제 업그레이드 중에 일부 문제가 발생할 경우 클러스터에서 실행 중인 워크로드 및 사용자 I/O에 아무런 영향을 미치지 않는다.

뉴타닉스 소프트웨어는 지원되는 업그레이드 버전 간에 혼합 모드로 무기한 동작하도록 설계되었다. 예를 들어 클러스터가 x.y.foo를 실행 중이고 x.y.bar로 업그레이드하는 경우 시스템은 두 버전 모두에서 CVM을 무기한 실행할 수 있다. 이것은 실제로 업그레이드 프로세스 중에 발생한다.

예를 들어 x.y.foo로 실행 중인 4노드 클러스터를 x.y.bar로 업그레이드를 시작한 경우 첫 번째 노드를 업그레이드하면 첫 번째 노드는 x.y.bar가 실행되고 다른 노드는 x.y.foo가 실행된다. 이 프로세스는 계속 진행되고 CVM은 업그레이드 토큰을 받을 때 x.y.bar로 재부팅된다.

파운데이션 (이미징)

아키텍처

파운데이션(Foundation)은 뉴타닉스 클러스터의 부트스트래핑, 이미징 및 배포를 위해 활용되는 뉴타닉스 제공 툴이다. 이미징 프로세스는 선택한 하이퍼바이저뿐만 아니라 원하는 버전의 AOS 소프트웨어를 설치한다.

기본적으로 뉴타닉스 노드는 AHV가 사전 설치되어 제공되므로 다른 하이퍼바이저 유형을 활용하려면 파운데이션을 사용하여 노드를 원하는 하이퍼바이저로 재이미징해야 한다. NOTE: 일부 OEM 제품은 원하는 하이퍼바이저로 공장에서 직접 배송된다.

파운데이션 아키텍처의 하이-레벨 뷰는 다음 그림과 같다.

Foundation - Architecture
Figure. 파운데이션 - 아키텍처 (Foundation - Architecture)

AOS 4.5 버전부터 파운데이션은 설정을 단순화하기 위해 CVM에 내장되어 있다. 인스톨러 스토어(Installer Store)는 업로드된 이미지를 저장하기 위한 디렉토리로 이미징이 필요할 때 클러스터 확장뿐만 아니라 초기 이미징을 위해 사용된다.

파운데이션 디스커버리 애플릿(여기에서 찾을 수 있음: HERE)은 노드를 검색하고 사용자가 연결할 노드를 선택할 수 있도록 한다. 사용자가 연결할 노드를 선택하면 애플릿은 localhost:9442 IPv4를 CVM의 8000번 포트에서 IPv6 링크 로컬 주소에 프록시한다.

애플릿 아키텍처의 하이-레벨 뷰는 다음 그림과 같다.

Foundation - Applet Architecture
Figure. 파운데이터션 - 애플릿 아키텍처 (Foundation - Applet Architecture)

NOTE: 디스커버리 애플릿(Discovery Applet)은 노드에서 실행되는 파운데이션 서비스의 검색 및 프록시의 수단일 뿐이다. 모든 이미징 및 설정은 애플릿이 아닌 파운데이션 서비스에 의해 처리된다.

Note
Pro tip

타깃 뉴타닉스 노드(e.g. WAN을 통해)와 다른 네트워크를 사용하는 경우(L2) IPv4 주소가 할당된 CVM의 파운데이션 서비스에 직접 연결할 수 있다 (디스커버리 애플릿을 사용하는 대신에).

직접 연결을 위해 <CVM_IP>:8000/gui/index.html을 사용한다.

입력

파운데이션 툴은 설정을 위해 다음과 같은 입력 값을 가진다 (아래). 일반적인 배포에는 노드 당 3개의 IP 주소가 필요하다 (하이퍼바이저, CVM, 원격 관리(e.g. IPMI, iDRAC 등)). 노드 별 주소 외에 클러스터 가상 IP와 데이터 서비스 IP를 설정하는 것이 좋다.

  • 클러스터 (Cluster)
    • 이름 (Name)
    • IP*
    • NTP*
    • DNS*
  • CVM
    • CVM 당 IP (IP per CVM)
    • 넷마스크 (Netmask)
    • 게이트웨이 (Gateway)
    • 메모리 (Memory)
  • 하이퍼바이저 (Hypervisor)
    • 하이퍼바이저 호스트 당 IP (IP per hypervisor host)
    • 넷마스크 (Netmask)
    • 게이트웨이 (Gateway)
    • DNS*
    • 호스트 이름의 접두사 (Hostname prefix)
  • IPMI*
    • 노드 당 IP (IP per node)
    • 넷마스크 (Netmask)
    • 게이트웨이 (Gateway)

NOTE: “*”로 표시된 항목은 선택 사항이지만 매우 권장됨

시스템 이미징 및 배포

첫 번째 단계는 디스커버리 애플릿을 통해 수행할 수 있는 파운데이션 UI에 연결하는 것이다 (동일 L2에 있는 경우 노드 IP는 필요 없음).

Foundation - Discovery Applet
Figure. 파운데이션 - 디스커버리 애플릿 (Foundation - Discovery Applet)

원하는 노드를 찾을 수 없는 경우 동일 L2 네트워크에 있는지 확인한다.

선택한 노드의 파운데이션 인스턴스에 연결하면 메인 파운데이션 UI가 나타난다.

Foundation - Discovery Page
Figure. 파운데이션 - 디스커버리 페이지 (Foundation - Discovery Page)

검색된 모든 노드와 해당 섀시가 표시된다. 클러스터를 구성할 노드를 선택하고 “Next” 버튼을 클릭한다.

Foundation - Node Selection
Figure. 파운데이션 - 노드 선택 (Foundation - Node Selection)

다음 페이지는 클러스터 및 네트워크 입력을 요구한다.

Foundation - Cluster Information
Figure. 파운데이션 - 클러스터 정보 (Foundation - Cluster Information)
Foundation - Network Applet
Figure. 파운데이션 - 네트워크 정보 (Foundation - Network Information)

세부 정보를 입력한 후에 “Next” 버튼을 클릭한다.

다음으로 노드 세부 정보와 IP 주소를 입력한다.

Foundation - Node Setup
Figure. 파운데이션 - 노드 설정 (Foundation - Node Setup)

필요한 경우 호스트 이름과 IP 주소를 수동으로 재정의할 수 있다.

Foundation - Hostname and IP
Figure. 파운데이션 - 호스트 이름 및 IP (Foundation - Hostname and IP)

네트워크 설정을 검증하고 진행하려면 “Validate Network” 버튼을 클릭한다. 이를 통해 IP 주소 충돌을 체크하고 연결을 보장한다.

Foundation - Network Validation
Figure. 파운데이션 - 네트워크 검증 (Foundation - Network Validation)

네트워크 검증이 성공적으로 완료되면 이제 원하는 이미지를 선택한다.

아크로폴리스를 현재 CVM에 있는 것보다 최신 버전으로 업그레이드하려면 포털에서 다운로드하고 Tarball을 업로드한다. 원하는 AOS 이미지를 얻은 후에 하이퍼바이저를 선택한다.

AHV의 경우 이미지는 아크로폴리스 이미지에 내장되어 있다. 다른 하이퍼바이저인 경우 원하는 하이퍼바이저 이미지를 업로드해야 한다. NOTE: AOS와 하이퍼바이저 버전이 호환성 매트릭스(LINK)에 있는지 확인한다.

원하는 이미지가 있으면 “Create” 버튼을 클릭한다.

Foundation - Select Images
Figure. 파운데이션 - 이미지 선택 (Foundation - Select Images)

이미징이 필요하지 않은 경우 “Skip”을 클릭하여 이미징 프로세스를 건너뛸 수 있다. 이렇게 하면 하이퍼바이저 및 뉴타닉스 클러스터를 재이미징하지 않고 단지 클러스터만(e.g. IP 주소 등) 설정한다 .

그런 다음 파운데이션은 이미징 (필요한 경우) 및 클러스터 생성 프로세스를 진행한다.

Foundation - Cluster Creation Process
Figure. 파운데이션 - 클러스터 생성 프로세스 (Foundation - Cluster Creation Process)

클러스터 생성이 성공하면 완료 화면이 나타난다.

Foundation - Cluster Creation Complete
Figure. 파운데이션 - 클러스터 생성 완료 (Foundation - Cluster Creation Complete)

이제 임의의 CVM 또는 클러스터 가상 IP에 로그인하여 뉴타닉스 플랫폼을 사용할 수 있다.

드라이브 분할

본 섹션에서는 다양한 스토리지 디바이스(SSD/HDD)가 뉴타닉스 플랫폼에 의해 어떻게 분할되고, 파티션되고, 활용되는지를 다룬다. NOTE: 사용된 모든 용량은 Base10 Gigabyte (GB)가 아닌 Base2 Gibibyte (GiB)를 기반으로 한다. 파일 시스템을 위한 드라이브 포맷팅 및 관련된 오버헤드를 고려하였다.

SSD 디바이스

SSD 디바이스는 위에 자세히 설명된 몇 가지 주요 아이템을 저장한다.

  • 뉴타닉스 홈 (CVM 코어)
  • 카산드라 (메타데이터 스토리지)
  • OpLog (영구 쓰기 버퍼)
  • 유니파이드 캐시 (SSD 캐시 부분)
  • 익스텐트 스토어 (영구 스토리지)

다음 그림은 뉴타닉스 노드의 SSD에 대한 스토리지 분할의 예를 보여준다.

SSD Drive Breakdown
Figure 10-6. SSD 드라이브 분할 (SSD Drive Breakdown)

NOTE: OpLog에 대한 사이징이 릴리스 4.0.1에서 동적으로 수행되므로 익스텐트 스토어 부분이 동적으로 증가할 수 있다. 사용된 값은 완전히 활용된 OpLog를 가정한다. 그래픽과 비율은 실제 크기에 맞게 그려지지 않았다. 나머지 GiB 용량은 탑다운 방식으로 계산한다. 예를 들어 OpLog 계산에 사용될 나머지 GiB는 포맷된 SSD 용량에서 뉴타닉스 홈과 카산드라를 차감한 이후의 것이다.

OpLog는 AOS 5.5를 기준으로 노드 당 최대 8개까지 모든 SSD 디바이스에 분산된다 (Gflag: max_ssds_for_oplog). NVMe 디바이스를 사용하는 경우 OpLog는 SATA SSD 대신 해당 디바이스에 위치한다.

뉴타닉스 홈은 가용성 보장을 위해 처음 두 개의 SSD에 미러링 된다. AOS 5.0 현재 카산드라는 SSD 당 15GiB(메타데이터 사용량이 증가하면 일부 스타게이트 SSD를 활용할 수 있음)의 초기 예약으로 노드의 SSD(현재 최대 4개)에 분할된다. 듀얼 SSD 시스템에서 메타데이터는 SSD 간에 미러링 된다. SSD 당 메타데이터 예약은 15GiB이다 (듀얼 SSD의 경우 30GiB, 4 + SSD의 경우 60GiB).

AOS 5.0 이전에는 카산드라가 기본적으로 첫 번째 SSD에 있었고, 그 SSD에 장애가 발생하면 CVM은 재시작되고 카산드라 스토리지는 두 번째에 있었다. 이 경우 SSD 당 메타데이터 예약은 처음 두 개의 디바이스에 대해 30GiB이다.

대부분의 모델은 1개 또는 2개의 SSD와 함께 제공되지만 더 많은 SSD 디바이스와 함께 제공되는 모델에도 동일한 알고리즘이 적용된다. 예를 들어 2x400GB SSD가 있는 샘플 3060 또는 6060 노드에 적용하면 노드 당 100GiB의 OpLog, 40GiB의 유니파이드 캐시, 그리고 최대 440GiB의 익스텐트 스토어 SSD 용량을 제공한다.

HDD 디바이스

HDD 디바이스는 기본적으로 대용량의 스토리지로 사용되기 때문에 분할이 훨씬 간단하다.

  • 큐레이터 예약 (큐레이터 스토리지)
  • 익스텐트 스토어 (영구 스토리지)
HDD Drive Breakdown
Figure 10-7. HDD 드라이브 분할 (HDD Drive Breakdown)

예를 들어 4x1TB HDD가 있는 샘플 3060 노드에 적용하면 노드 당 80GiB의 큐레이터 예약, 최대 3.5TiB의 익스텐트 스토어 HDD 용량을 제공한다.

NOTE: 위의 값은 AOS 4.0.1 버전에서 정확하며 릴리스에 따라 달라질 수 있다.

Book of Prism

prism - /'priz?m/ - noun - control plane
one-click management and interface for datacenter operations.

설계 방법론 및 최신 형태

아름답고 공감적이며 직관적인 제품을 만드는 것이 뉴타닉스 플랫폼의 핵심이며 뉴타닉스가 진지하게 고민하는 것이다. 본 섹션에서 설계 방법론과 설계 반복 과정에 대해 다룬다. 내용 추가 예정입니다!

그동안 뉴타닉스 제품 설계 책임자인 Jeremy Sallee가 디자인 방법론 및 반복 과정에 대해 다룬 이 훌륭한 게시물을 확인하세요 (누가 디자인했습니까?) - http://salleedesign.com/blog/nutanix-case-study/

뉴타닉스 비지오 스텐실은 다음 링크에서 다운로드할 수 있다: http://www.visiocafe.com/nutanix.htm

아키텍처

프리즘은 사용자가 뉴타닉스 환경 전체에서 오브젝트와 서비스를 관리하고 모니터링할 수 있도록 해주는 분산 자원 관리 플랫폼이다.

이러한 기능은 두 가지 주요 카테고리로 구분된다.

  • 인터페이스 (Interfaces)
    • HTML5 UI, REST API, CLI, PowerShell CMDlets 등
  • 관리 (Management)
    • 정책 정의 및 컴플라이언스, 서비스 디자인 및 상태, 분석 및 모니터링

다음 그림은 뉴타닉스 플랫폼의 일부로서 프리즘의 개념적 특성을 보여준다.

High-Level Prism Architecture
Figure 5-1. 하이-레벨 프리즘 아키텍처 (High-Level Prism Architecture)

프리즘은 두 가지 메인 컴포넌트로 나뉜다.

  • 프리즘 센트럴 (Prism Central: PC)
    • 여러 개의 아크로폴리스 클러스터를 관리하기 위한 멀티 클러스터 매니저로 단일 중앙 집중식 관리 인터페이스를 제공한다. 프리즘 센트럴은 아크로폴리스 클러스터 (실행 가능) 이외에도 배포할 수 있는 선택적인 소프트웨어 어플라이언스(VM)이다.
    • 1-to-Many 클러스터 매니저
  • 프리즘 엘리먼트 (Prism Element: PE)
    • 로컬 클러스터 관리 및 오퍼레이션을 담당하는 로컬 클러스터 매니저이다. 모든 아크로폴리스 클러스터에는 프리즘 엘리먼트가 내장되어 있다.
    • 1-to-1 클러스터 매니저

프리즘 센트럴과 프리즘 엘리먼트의 개념적 관계는 다음 그림과 같다.

Prism Architecture
Figure 5-2. 프리즘 아키텍처 (Prism Architecture)
Note
Pro tip

대규모 또는 분산 배포(e.g. 1개 이상의 클러스터 또는 여러 개의 사이트)인 경우 오퍼레이션을 단순화하고 모든 클러스터/사이트에 대해 단일 관리 UI를 제공하기 위해 프리즘 센트럴의 사용을 권고한다.

프리즘 서비스

프리즘 서비스는 HTTP 요청의 처리를 담당하는 선출된 프리즘 리더와 함께 모든 CVM에서 실행된다. 마스터를 갖는 다른 컴포넌트와 유사하게 프리즘 리더가 실패하면 새로운 마스터가 선출된다. 프리즘 리더가 아닌 CVM이 HTTP 요청을 받으면 HTTP 응답 상태 코드인 “301’을 사용하여 현재 프리즘 리더로 영구적으로 리다이렉트한다.

다음은 프리즘 서비스의 개념과 HTTP 요청 처리 방법을 나타낸 것이다.

Prism Services - Request Handling
Figure 5-3. 프리즘 서비스 – 요청 처리 (Prism Services - Request Handling)
Note
프리즘 포트 (Prism Ports)

프리즘은 포트 80과 9440에서 수신 대기하며, 만약 HTTP 트래픽이 80번 포트로 들어오면 해당 요청은 9440 포트에서 HTTPS로 리다이렉트된다.

클러스터 가상 IP를 사용할 때(권장) 현재 프리즘 리더가 항상 호스트 한다. 프리즘 리더가 실패하면 클러스터 가상 IP는 새로 선출된 프리즘 리더가 맡게 되며 오래된 ARP 캐시 엔트리를 삭제하기 위해 Gratuitous ARP(gARP)가 사용된다. 이 시나리오에서는 클러스터 가상 IP를 사용하여 프리즘에 액세스할 때마다, 클러스터 가상 IP가 이미 프리즘 리더이므로 리다이렉션이 필요하지 않다.

Note
Pro tip

모든 CVM에서 'curl localhost:2019/prism/leader'를 실행하여 현재 프리즘 리더를 확인할 수 있다.

인증 및 접근 제어

인증

프리즘은 현재 다음 인증 공급자와의 통합을 지원한다.

  • 프리즘 엘리먼트 (Prism Element: PE)
    • 로컬
    • 액티브 디렉토리
    • LDAP
  • 프리즘 센트럴 (Prism Central: PC)
    • 로컬
    • 액티브 디렉토리
    • LDAP
    • SAML 인증 (IDP)
Note
SAML / 2FA

SAML 인증을 사용하면 프리즘을 SAML과 호환되는 외부 ID 제공 업체(e.g. Okta, ADFS 등)와 통합할 수 있다.

또한 이러한 공급자가 프리즘에 로그인하는 사용자를 지원하는 MFA(Multi-Factor Authentication) / 2FA(Two-Factor Authentication) 기능을 활용할 수 있다.

접근 제어

내용 추가 예정입니다.

기능 및 사용법

다음 섹션에서 몇 가지 일반적인 장애 처리 시나리오와 함께 대표적인 프리즘 사용법에 대해 설명한다.

이상 징후 탐지

IT 운영의 세계에는 많은 노이즈가 있다. 전통적으로 시스템은 많은 경고, 이벤트 및 통지를 생성하며, 종종 운영자는 a) 노이즈에서 손실되었기 때문에 중요한 경고를 보지 못하거나 또는 b) 경고/이벤트를 무시할 수 있다.

뉴타닉스 이상 징후 탐지 기능을 사용하면 시스템은 시계열 데이터(e.g. CPU 사용량, 메모리 사용량, 레이턴시 등)의 계절적 추세를 모니터링하고 예상 값의 "밴드(Band)"를 설정할 수 있다. "밴드" 범위를 벗어나는 값에 대해서만 이벤트/경고를 발생시킨다. 모든 엔티티 또는 이벤트 페이지에서 이상 징후 이벤트/경고를 볼 수 있다.

다음 차트는 이러한 시스템에서 일부 대규모 배치 처리를 수행할 때 발생하는 많은 I/O 및 디스크 사용량의 이상 징후를 보여준다.

Prism - Anomaly Chart
Figure. 프리즘 - 이상 징후 차트 (Prism - Anomaly Chart)

다음 이미지는 샘플 메트릭과 설정된 "밴드"에 대한 시계열 값을 보여준다.

Prism - Anomaly Band
Figure. 프리즘 - 이상 징후 밴드 (Prism - Anomaly Band)

이것은 "정상"상태에 대한 경고를 원하지 않기 때문에 불필요한 경고를 감소시킨다. 예를 들어 데이터베이스 시스템은 캐싱 등으로 인해 정상적으로 95% 이상의 메모리 사용률로 실행된다. 이 경우에 뭔가 잘못될(e.g. 데이터베이스 서비스 다운) 수 있기 때문에 이상 징후일 가능성이 10%라고 말한다.

또 다른 예는 일부 배치 워크로드가 주말에 어떻게 실행되는지이다. 예를 들어 근무 주간에는 I/O 대역폭이 낮을 수 있지만, 일부 배치 프로세스(e.g. 백업, 보고서 등)가 실행되는 주말에 I/O가 급격히 증가할 수 있다. 시스템은 이것의 계절성을 감지하고 주말 동안에 밴드를 올린다.

여기에서 값이 예상되는 밴드를 벗어났기 때문에 이상 징후 이벤트가 발생했음을 알 수 있다.

Prism - Anomaly Event
Figure. 프리즘 - 이상 징후 이벤트 (Prism - Anomaly Event)

이상 징후에 대한 또 다른 관심 주제는 계절성이다. 예를 들어 소매업자는 휴일 기간 동안의 수요가 연중 다른 기간 또는 월 마감 동안 보다 높다는 것을 알 수 있다.

이상 징후 탐지는 이러한 계절성을 설명하며 다음 기간을 활용하여 미시적(일별) 및 거시적(분기별) 추세를 비교한다.

  • 일별 (Daily)
  • 주별 (Weekly)
  • 월별 (Monthly)

사용자는 맞춤 경고 또는 정적 임계 값을 설정할 수 있다.

Prism - Anomaly Custom Event
Figure. 프리즘 - 이상 징후 커스텀 이벤트 (Prism - Anomaly Custom Event)
Note
이상 징후 탐지 알고리즘 (Anomaly Detection Algorithm)

뉴타닉스는 밴드를 결정하기 위해 '일반화된 극한의 학생 편차 테스트(Generalized Extreme Studentized Deviate Test)'라는 방법을 활용한다. 이것을 이해하는 간단한 방법은 값이 알고리즘에 의해 설정된 상한과 하한 사이에 있는 신뢰 구간과 유사하다.

알고리즘은 계절성 및 예상되는 밴드를 계산하기 위해 3배의 세분화된 데이터(e.g. 일별, 주별, 월별 등)가 필요하다. 예를 들어 각각의 계절성을 반영하기 위해 다음과 같은 양의 데이터가 필요하다.

  • 일별 (Daily): 3일
  • 주별 (Weekly): 3주 (21일)
  • 월별 (Monthly): 3개월 (90일)

트위터는 이것을 어떻게 활용하는지에 대한 좋은 자료를 가지고 있는데, 로직에 대한 보다 자세한 설명은 다음 링크 참조: LINK

뉴타닉스 소프트웨어 업그레이드

뉴타닉스 소프트웨어 업그레이드를 수행하는 것은 매우 간단하고 무중단(non-disruptive) 프로세스이다.

시작하려면 프리즘에 로그인하고 오른쪽 상단의 기어 아이콘(설정)을 클릭하거나 'S'를 누르고 “Upgrade Software”를 선택한다.

Prism - Settings - Upgrade Software
Figure 7-1. 프리즘 – 설정 – 업그레이드 소프트웨어 (Prism - Settings - Upgrade Software)

그러면 “Upgrade Software” 다이얼로그 박스가 나타나고 현재 소프트웨어 버전과 사용 가능한 업그레이드 버전이 표시된다. AOS 바이너리 파일을 수동으로 업로드하는 것도 가능하다.

그런 다음 클라우드에서 업그레이드 버전을 다운로드하거나 수동으로 버전을 업로드할 수 있다.

Upgrade Software - Main
Figure 7-2. 업그레이드 소프트웨어 – 메인 (Upgrade Software - Main)

그런 다음 업그레이드 소프트웨어를 뉴타닉스 CVM에 업로드한다.

Upgrade Software - Upload
Figure 7-3. 업그레이드 소프트웨어 – 업로드 (Upgrade Software - Upload)

소프트웨어가 로드된 후 “Upgrade”를 클릭하여 업그레이드 프로세스를 시작한다.

Upgrade Software - Upgrade Validation
Figure 7-4. 업그레이드 소프트웨어 – 업그레이드 정합성 체크 (Upgrade Software - Upgrade Validation)

그러면 “확인” 다이얼로그 박스가 나타난다.

Upgrade Software - Confirm Upgrade
Figure 7-5. 업그레이드 소프트웨어 – 업그레이드 확인 (Upgrade Software - Confirm Upgrade)

업그레이드는 업그레이드 사전 검사부터 시작하여 롤링 방식으로 소프트웨어 업그레이드를 시작한다.

Upgrade Software - Execution
Figure 7-6. 업그레이드 소프트웨어 – 업그레이드 작업 수행 (Upgrade Software - Execution)

업그레이드가 완료되면 업데이트된 상태가 표시되고 모든 새로운 기능에 액세스할 수 있다.

Upgrade Software - Complete
Figure 7-7. 업그레이드 소프트웨어 – 업그레이드 작업 완료 (Upgrade Software - Complete)
Note
Note

현재 프리즘 리더가 업그레이드될 때 프리즘 세션이 잠시 중단된다. 실행 중인 모든 VM 및 서비스는 영향을 받지 않는다.

하이퍼바이저 업그레이드

뉴타닉스 소프트웨어 업그레이드와 마찬가지로 하이퍼바이저 업그레이드는 프리즘을 통해 롤링 방식으로 완전히 자동화될 수 있다.

시작하려면 위의 비슷한 단계에 따라 “Upgrade Software” 다이얼로그 박스를 열고 'Hypervisor'를 선택한다.

그런 다음 클라우드에서 하이퍼바이저 업그레이드 버전을 다운로드하거나 수동으로 버전을 업로드할 수 있다.

Upgrade Hypervisor - Main
Figure 7-8. 업그레이드 하이퍼바이저 – 메인 (Upgrade Hypervisor - Main)

그런 다음 업그레이드 소프트웨어를 하이퍼바이저에 로드한다. 소프트웨어가 로드된 후 'Upgrade'를 클릭하여 업그레이드 프로세스를 시작한다.

Upgrade Hypervisor - Upgrade Validation
Figure 7-9. 업그레이드 하이퍼바이저 – 업그레이드 정합성 체크 (Upgrade Hypervisor - Upgrade Validation)

그러면 “확인” 다이얼로그 박스가 나타난다.

Upgrade Hypervisor - Confirm Upgrade
Figure 7-10. 업그레이드 하이퍼바이저 – 업그레이드 확인 (Upgrade Hypervisor - Confirm Upgrade)

그러면 시스템은 호스트 업그레이드 사전 검사를 수행하고 하이퍼바이저 업그레이드를 클러스터에 업로드한다.

Upgrade Hypervisor - Pre-upgrade Checks
Figure 7-11. 업그레이드 하이퍼바이저 – 업그레이드 사전 검사 (Upgrade Hypervisor - Pre-upgrade Checks)

업그레이드 사전 검사가 완료되면 롤링 방식으로 하이퍼바이저 업그레이드가 진행된다.

Upgrade Hypervisor - Execution
Figure 7-12. 업그레이드 하이퍼바이저 – 업그레이드 작업 수행 (Upgrade Hypervisor - Execution)

뉴타닉스 소프트웨어 업그레이드의 롤링 특성과 마찬가지로 각 호스트는 실행 중인 VM에 영향을 주지 않고 롤링 방식으로 업그레이드된다. VM은 현재 호스트에서 라이브 마이그레이션되고, 호스트는 업그레이드된 다음 재부팅된다. 이 프로세스는 클러스터의 모든 호스트를 업그레이드할 때까지 각 호스트에서 반복된다.

Note
Pro tip

뉴타닉스 CVM에서 “host_upgrade –status”를 실행하여 클러스터 전체 업그레이드 상태를 확인할 수 있다. 호스트 별 상세 상태는 “~/data/logs/host_upgrade.out”에 기록된다.

업그레이드가 완료되면 업데이트된 상태가 표시되고 모든 새로운 기능에 액세스할 수 있다.

Upgrade Hypervisor - Complete
Figure 7-13. 업그레이드 하이퍼바이저 – 업그레이드 작업 완료 (Upgrade Hypervisor - Complete)

클러스터 확장 (노드 추가)

Cluster Expansion
Figure. 클러스터 확장 (Cluster Expansion)

아크로폴리스 클러스터를 동적으로 확장할 수 있는 능력은 뉴타닉스 플랫폼의 핵심 기능이다. 아크로폴리스 클러스터를 확장하려면 노드를 랙에 장착하고 케이블을 연결한 후에 전원을 켠다. 노드 전원을 켜면 현재 클러스터는 mDNS를 사용하여 노드를 검색한다.

그림은 검색된 노드가 1개인 예제 7노드 클러스터를 보여준다.

Add Node - Discovery
Figure 7-14. 노드 추가 – 검색 (Add Node - Discovery)

여러 개의 노드를 동시에 검색하여 클러스터에 추가할 수 있다.

노드가 검색되면 “Hardware” 페이지의 오른쪽 상단에서 있는 “Expand Cluster”를 클릭하여 확장을 시작할 수 있다.

Hardware Page - Expand Cluster
Figure 7-15. 하드웨어 페이지 - 클러스터 확장 (Hardware Page - Expand Cluster)

또한 모든 페이지에서 설정 아이콘을 클릭하여 클러스터 확장 프로세스를 시작할 수 있다.

Gear Menu - Expand Cluster
Figure 7-16. 설정 메뉴 – 클러스터 확장 (Gear Menu - Expand Cluster)

그러면 추가할 노드를 선택하고 컴포넌트의 IP 정보를 설정할 수 있는 확장 클러스터 메뉴가 시작된다.

Expand Cluster - Host Selection
Figure 7-17. 클러스터 확장 – 호스트 선택 (Expand Cluster - Host Selection)

호스트를 선택하면 추가될 노드의 이미지를 만드는 데 사용될 하이퍼바이저 이미지를 업로드하라는 메시지가 표시된다. AHV 또는 이미지가 파운데이션 인스톨러 스토어에 이미 있는 경우에는 업로드가 필요하지 않다.

Expand Cluster - Host Configuration
Figure 7-18. 클러스터 확장 – 호스트 설정 (Expand Cluster - Host Configuration)

업로드가 완료되면 “Expand Cluster”를 클릭하여 이미징 및 확장 프로세스를 시작한다.

Expand Cluster - Execution
Figure 7-19. 클러스터 확장 – 작업 시작 (Expand Cluster - Execution)

그런 다음 잡(Job)이 제출되고 해당 태스크 아이템이 나타난다.

Expand Cluster - Execution
Figure 7-20. 클러스터 확장 – 작업 수행 (Expand Cluster - Execution)

자세한 테스크 상태는 태스크를 확장하여 볼 수 있다.

Expand Cluster - Execution
Figure 7-21. 클러스터 확장 – 상세 작업 상태 (Expand Cluster - Execution)

이미징 및 노드 추가 프로세스가 완료되면 업데이트된 클러스터 크기와 자원을 확인할 수 있다.

Expand Cluster - Execution
Figure 7-22. 클러스터 확장 – 노드 추가 작업 완료 (Expand Cluster - Execution)

I/O 메트릭스

병목현상을 파악하는 것은 성능 문제 해결 프로세스의 매우 중요한 부분이다. 이 프로세스를 돕기 위해 뉴타닉스는 VM 페이지에 "I/O 메트릭스(I/O Metrics)" 섹션을 도입했다.

레이턴시는 여러 변수(큐 깊이, I/O 크기, 시스템 조건, 네트워크 속도 등)에 따라 달라진다. 이 페이지는 I/O 크기, 레이턴시, 소스 및 패턴에 대한 통찰력을 제공하는 것을 목표로 한다.

새로운 섹션을 사용하려면 VM 페이지로 이동하여 테이블에서 원하는 VM을 선택한다. 여기에서 높은 수준의 사용량 메트릭스를 확인할 수 있다.

VM Page - Details
Figure. VM 페이지 - 상세 (VM Page - Details)

'I/O Metrics' 탭은 테이블 아래 섹션에서 찾을 수 있다.

VM Page - I/O Metrics Tab
Figure. VM 페이지 - 입출력 메트릭스 탭 (VM Page - I/O Metrics Tab)

'I/O Metrics' 탭을 선택하면 상세 뷰가 표시된다. 본 섹션에서 이 페이지를 세분화하고 그것을 어떻게 사용하는지를 설명한다.

첫 번째 뷰는 지난 3시간 동안의 평균 레이턴시를 보여주는 “Avg I/O Latency” 섹션이다. 기본적으로 가장 최근에 보고된 값이 해당 시점에 상응하는 세부 메트릭스와 함께 표시된다.

플롯 위로 마우스를 가져가면 과거 레이턴시 값을 볼 수 있고 플롯의 시간을 클릭하여 아래와 같은 세부 메트릭스를 볼 수 있다.

I/O Metrics - Latency Plot
Figure. 입출력 메트릭스 - 레이턴시 플롯 (I/O Metrics - Latency Plot)

이것은 갑작스러운 스파이크가 보일 때 유용할 수 있다. 스파이크가 보이고 추가 조사가 필요하면 스파이크를 클릭하고 아래의 세부 정보를 분석한다.

I/O Metrics - Latency Plot
Figure. 입출력 메트릭스 - 레이턴시 플롯 (I/O Metrics - Latency Plot)

레이턴시가 모두 정상이면 추가 분석을 진행할 필요가 없다.

다음 섹션은 읽기 및 쓰기 I/O에 대한 I/O 크기 막대 그래프를 보여준다.

I/O Metrics - I/O Size histogram
Figure. 입출력 메트릭스 - I/O 크기 막대 그래프 (I/O Metrics - I/O Size histogram)

여기에서 읽기 I/O 범위가 크기 기준으로 4K에서 32K까지인 것을 볼 수 있다.

I/O Metrics - Read I/O Size histogram
Figure. 입출력 메트릭스 - 읽기 I/O 크기 막대 그래프 (I/O Metrics - Read I/O Size histogram)

여기에서 쓰기 I/O 범위가 크기 기준으로 16K에서 64K까지이며 최대 512K까지인 것을 볼 수 있다.

I/O Metrics - Write I/O Size histogram
Figure. 입출력 메트릭스 - 쓰기 I/O 크기 막대 그래프 (I/O Metrics - Write I/O Size histogram)
Note
Pro tip

레이턴시에서 스파이크를 보았을 때 첫 번째로 확인해야 할 것은 I/O 크기이다. 일반적으로 큰 I/O(64K~1MB)가 작은 I/O(4K~32K) 보다 레이턴시가 더 높다.

다음 섹션에서는 읽기 및 쓰기 I/O에 대한 I/O 레이턴시 막대 그래프를 보여준다.

I/O Metrics - Latency histogram
Figure. 입출력 메트릭스 – 레이턴시 막대 그래프 (I/O Metrics - Latency histogram)

읽기 레이턴시 막대 그래프를 보면 대부분의 읽기 I/O가 최대 2~5ms 이하의 sub-ms(<1ms)인 것을 볼 수 있다.

I/O Metrics - Read Latency histogram
Figure. 입출력 메트릭스 – 읽기 레이턴시 막대 그래프 (I/O Metrics - Read Latency histogram)

아래의 "읽기 소스"를 살펴보면 대부분의 I/O가 SSD 계층에서 서비스되는 것을 볼 수 있다.

I/O Metrics - Read Source SSD
Figure. 입출력 메트릭스 - SSD에서 읽기 (I/O Metrics - Read Source SSD)

데이터가 읽힐 때 데이터는 실시간으로 유니파이드 캐시(DRAM+SSD)로 전송된다 (“I/O 경로 및 캐시” 섹션 참조). 여기에서 데이터가 캐시에 저장되어 있고 DRAM에서 서비스되는 것을 볼 수 있다.

I/O Metrics - Read Source DRAM
Figure. 입출력 메트릭스 - DRAM에서 읽기 (I/O Metrics - Read Source DRAM)

기본적으로 모든 읽기 I/O 레이턴시가 sub-ms(< 1ms)인 것을 볼 수 있다.

I/O Metrics - Read Latency histogram
Figure. 입출력 메트릭스 - 읽기 레이턴시 막대 그래프 (I/O Metrics - Read Latency histogram)

여기에서 대부분의 쓰기 I/O 레이턴시가 1~2ms인 것을 볼 수 있다.

I/O Metrics - Write Latency histogram
Figure. 입출력 메트릭스 - 쓰기 레이턴시 막대 그래프 (I/O Metrics - Write Latency histogram)
Note
Pro tip

읽기 레이턴시에서 스파이크가 보이고 I/O 크기가 크지 않다면 읽기 I/O가 어디에서 서비스되고 있는지를 확인하여야 한다. HDD에서 초기 읽기는 DRAM 캐시보다 레이턴시가 높지만 캐시에 저장된 이후의 모든 읽기는 DRAM에서 서비스되므로 레이턴시가 향상된 것을 볼 수 있다.

마지막 섹션에서는 I/O 패턴과 랜덤 대 순차가 얼마나 되는지를 보여준다.

I/O Metrics - RW Random vs. Sequential
Figure. 입출력 메트릭스 – RW 랜덤 데이터 vs 순차 데이터 (I/O Metrics - RW Random vs. Sequential)

일반적으로 I/O 패턴은 애플리케이션 또는 워크로드에 따라 다르다 (e.g. VDI는 주로 랜덤 데이터인 반면에 하둡은 기본적으로 순차 데이터임). 다른 워크로드는 두 가지가 혼합되어 있다. 예를 들어 데이터베이스에서 입력 및 일부 조회는 랜덤일 수 있지만 ETL 중에는 순차이다.

용량 계획

자세한 용량 계획 세부 정보를 얻으려면 프리즘 센트럴의 'Cluster Runway' 섹션에서 특정 클러스터를 클릭하면 자세한 내용을 불 수 있다.

Prism Central - Capacity Planning
Figure 7-23. 프리즘 센트럴 – 용량 계획 (Prism Central - Capacity Planning)

이 뷰는 클러스터 런웨이에 대한 자세한 정보를 제공하며 가장 제약된 자원(제한 자원)을 식별한다. 또한 상위 자원 소비자가 무엇인지에 대한 자세한 정보는 물론 클러스터 확장을 위한 추가 용량 또는 이상적인 노드 유형을 정리할 수 있는 몇 가지 잠재적 옵션을 얻을 수 있다.

Prism Central - Capacity Planning - Recommendations
Figure 7-24. 프리즘 센트럴 – 용량 계획 – 권고 (Prism Central - Capacity Planning - Recommendations)

HTML5 UI는 프리즘의 핵심적인 부분으로 간단하고 사용하기 쉬운 관리 인터페이스를 제공한다. 또 다른 핵심 기능은 자동화에 사용할 수 있는 API이다. 프리즘 UI에 노출된 모든 기능은 뉴타닉스 플랫폼과 프로그래밍 방식으로 인터페이스 할 수 있도록 풀 세트의 REST API를 통해 제공된다. 이를 통해 고객과 파트너는 자동화 및 3rd 파티 툴의 사용이 가능하고 자체 UI를 만들 수 있다.

다음 섹션에서 이러한 인터페이스를 설명하고 몇 가지 예제 사용법을 제공한다.

APIs 및 인터페이스

동적 또는 "소프트웨어-정의" 환경의 핵심인 뉴타닉스는 간단한 프로그래밍 및 인터페이스가 가능하도록 광범위한 인터페이스를 제공한다. 메인 인터페이스는 다음과 같다.

  • REST API
  • CLI - ACLI & NCLI
  • 스크립트 인터페이스 (Scripting interfaces)
Note
developer.nutanix.com

API에 대한 자세한 내용과 샘플 코드를 보려면 다음 사이트 참조: developer.nutanix.com

이것의 핵심은 프리즘 UI의 모든 기능과 데이터 포인트를 노출하고 오케스트레이션 또는 자동화 도구가 뉴타닉스 작업을 쉽게 수행할 수 있도록 해주는 REST API이다. 이를 통해 Saltstack, Puppet, vRealize Operations, System Center Orchestrator, Ansible 등과 같은 툴을 사용하여 뉴타닉스를 위한 사용자 정의 워크플로우를 쉽게 만들 수 있다. 또한 이것은 3rd 파티 개발자가 자체 사용자 정의 UI를 만들고 REST를 통해 뉴타닉스 데이터를 가져올 수 있다는 것을 의미한다.

다음 그림은 개발자가 API와 상호 작용하고 예상되는 데이터 포맷을 볼 수 있는 뉴타닉스 REST API Explorer의 작은 스니펫을 보여준다.

Prism REST API Explorer
Figure 8-1. 프리즘 REST API 익스플로러 (Prism REST API Explorer)

오퍼레이션을 확장하여 REST 호출의 세부 정보 및 예제를 표시할 수 있다.

Prism REST API Sample Call
Figure 8-2. 프리즘 REST API 호출 예제 (Prism REST API Sample Call)
Note
API 인증 스킴 (API Authentication Scheme)

AOS 4.5 버전부터 HTTPS를 통한 기본 인증이 클라이언트 및 HTTP 호출 인증에 활용된다.

ACLI

아크로폴리스 CLI(ACLI)는 뉴타닉스 제품의 아크로폴리스 부분을 관리하기 위한 CLI이다. 본 기능은 AOS 4.1.2 이상의 버전에서 지원된다.

NOTE: 이러한 모든 액션은 HTML5 GUI 및 REST API를 통해 수행할 수 있다. 나는 작업의 자동화를 위한 스크립팅의 일부로 이 명령들을 사용한다.

ACLI 쉘 사용

설명: ACLI 쉘로 진입 (CVM에서 동작)

acli

또는

설명: Linux 쉘에서 ACLI 명령어 수행

ACLI <Command>

ACLI 결과 값을 JSON 포멧으로 출력

설명: ACLI 결과 값을 JSON 포맷으로 출력

acli -o json

호스트 리스트 출력

설명: 클러스터에서 아크로폴리스 노드 목록 출력

host.list

네트워크 생성

설명: VLAN 기반 네트워크 생성

net.create <TYPE>.<ID>[.<VSWITCH>] ip_config=<A.B.C.D>/<NN>

Example: net.create vlan.133 ip_config=10.1.1.1/24

네트워크 목록 출력

설명: 네트워크 목록 출력

net.list

DHCP 범위 생성

설명: DHCP 범위 생성

net.add_dhcp_pool <NET NAME> start=<START IP A.B.C.D> end=<END IP W.X.Y.Z>

Note: 만약 아크로폴리스 DHCP 서버의 주소가 네트워크 생성 중에 설정되지 않는 경우에 .254는 아크로폴리스 DHCP 서버에 의해 예약되어 사용된다.

Example: net.add_dhcp_pool vlan.100 start=10.1.1.100 end=10.1.1.200

기존 네트워크 상세정보 얻기

설명: VM 이름 / UUID, MAC 주소 및 IP를 포함한 네트워크의 VM 및 세부 정보 얻기

net.list_vms <NET NAME>

Example: net.list_vms vlan.133

네트워크에 DHCP 및 DNS 서버 설정

설명: DHCP 및 DNS 설정

net.update_dhcp_dns <NET NAME> servers=<COMMA SEPARATED DNS IPs> domains=<COMMA SEPARATED DOMAINS>

Example: net.set_dhcp_dns vlan.100 servers=10.1.1.1,10.1.1.2 domains=splab.com

VM 생성

설명: VM 생성

vm.create <COMMA SEPARATED VM NAMES> memory=<NUM MEM MB> num_vcpus=<NUM VCPU> num_cores_per_vcpu=<NUM CORES> ha_priority=<PRIORITY INT>

Example: vm.create testVM memory=2G num_vcpus=2

대량의 VM 생성

설명: 대량의 VM 생성

vm.create  <CLONE PREFIX>[<STARTING INT>..<END INT>] memory=<NUM MEM MB> num_vcpus=<NUM VCPU> num_cores_per_vcpu=<NUM CORES> ha_priority=<PRIORITY INT>

Example: vm.create testVM[000..999] memory=2G num_vcpus=2

기존 VM으로부터 VM 복제

설명: 기존 VM으로부터 VM 복제

vm.clone <CLONE NAME(S)> clone_from_vm=<SOURCE VM NAME>

Example: vm.clone testClone clone_from_vm=MYBASEVM

기존 VM으로부터 대량의 VM 복제

설명: 기존 VM으로부터 대량의 VM 복제

vm.clone <CLONE PREFIX>[<STARTING INT>..<END INT>] clone_from_vm=<SOURCE VM NAME>

Example: vm.clone testClone[001..999] clone_from_vm=MYBASEVM

디스크를 생성하고 VM에 추가

설명: OS를 위한 디스크 생성

vm.disk_create <VM NAME> create_size=<Size and qualifier, e.g. 500G> container=<CONTAINER NAME>

Example: vm.disk_create testVM create_size=500G container=default

VM에 NIC 추가

설명: NIC을 생성하고 추가

vm.nic_create <VM NAME> network=<NETWORK NAME> model=<MODEL>

Example: vm.nic_create testVM network=vlan.100

VM의 부트 디바이스를 디스크로 설정

설명: VM 부트 디바이스 설정

지정된 디스크 ID로 부트 디바이스 설정

vm.update_boot_device <VM NAME> disk_addr=<DISK BUS>

Example: vm.update_boot_device testVM disk_addr=scsi.0

VM의 부트 디바이스를 CD-DROM을 설정

VM 부트 디바이스를 CD-ROM으로 설정

vm.update_boot_device <VM NAME> disk_addr=<CD-ROM BUS>

Example: vm.update_boot_device testVM disk_addr=ide.0

ISO를 CD-ROM에 마운트

설명: ISO를 VM의 CD-ROM으로 마운트

단계:

1. ISO 이미지를 컨테이너에 업로드

2. 클라이언트 IP에 대한 화이트리스트 설정

3. ISO를 공유에 업로드

ISO를 갖는 CD-ROM 생성

vm.disk_create <VM NAME> clone_nfs_file=<PATH TO ISO> CD-ROM=true

Example: vm.disk_create testVM clone_nfs_file=/default/ISOs/myfile.iso CD-ROM=true

만약 CD-ROM을 이미 생성하였다면 ISO만 마운트

vm.disk_update <VM NAME> <CD-ROM BUS> clone_nfs_file<PATH TO ISO>

Example: vm.disk_update atestVM1 ide.0 clone_nfs_file=/default/ISOs/myfile.iso

ISO 이미지를 CD-ROM으로부터 제거

설명: ISO를 CD-ROM으로부터 제거

vm.disk_update <VM NAME> <CD-ROM BUS> empty=true

VM의 전원 켜기

설명: VM의 전원 켜기

vm.on <VM NAME(S)>

Example: vm.on testVM

모든 VM의 전원 켜기

Example: vm.on *

접두사와 매칭되는 모든 VM의 전원 켜기

Example: vm.on testVM*

특정 범위 내에 있는 VM의 전원 켜기

Example: vm.on testVM[0-9][0-9]

NCLI

NOTE: 이러한 모든 액션은 HTML5 GUI 및 REST API를 통해 수행할 수 있다. 나는 작업의 자동화를 위한 스크립팅의 일부로 이 명령들을 사용한다.

NFS 화이트리스트에 서브넷 추가

설명: NFS 화이트리스트에 특정 서브넷을 추가

ncli cluster add-to-nfs-whitelist ip-subnet-masks=10.2.0.0/255.255.0.0

뉴타닉스 버전 출력

설명: 뉴타닉스 소프트웨어의 현재 버전 출력

ncli cluster version

숨겨진 NCLI 옵션 출력

설명: 숨겨진 NCLI 명령어 또는 옵션 출력

ncli helpsys listall hidden=true [detailed=false|true]

스토리지 풀 목록 출력

설명: 스토리지 풀 목록 출력

ncli sp ls

컨테이너 목록 출력

설명: 컨테이너 목록 출력

ncli ctr ls

컨테이너 생성

설명: 새로운 컨테이너 생성

ncli ctr create name=<NAME> sp-name=<SP NAME>

VM 목록 출력

설명: VM 목록 출력

ncli vm ls

퍼블릭 키 목록 출력

설명: 기존에 등록되어 있는 퍼블릭 키 목록 출력

ncli cluster list-public-keys

퍼블릭 키 추가

설명: 클라이언트 액세스를 위한 퍼블릭 키 추가

퍼블릭 키를 CVM으로 복사

퍼블릭 키를 클러스터에 추가

ncli cluster add-public-key name=myPK file-path=~/mykey.pub

퍼블릭 키 제거

설명: 클라이언트 액세스를 위한 퍼블릭 키 제거

ncli cluster remove-public-keys name=myPK

보호 도메인 생성

설명: PD 생성

ncli pd create name=<NAME>

원격 사이트 생성

설명: 복제를 위한 원격 사이트 생성

ncli remote-site create name=<NAME> address-list=<Remote Cluster IP>

컨테이너의 모든 VM을 위한 PD 생성

설명: 컨테이너에 존재하는 모든 VM을 보호

ncli pd protect name=<PD NAME> ctr-id=<Container ID> cg-name=<NAME>

지정된 VM을 갖는 PD 생성

설명: 지정된 VM 보호

ncli pd protect name=<PD NAME> vm-names=<VM Name(s)> cg-name=<NAME>

DSF 파일(vDisk로 알려진)를 위한 PD 생성

설명: 지정된 DSF 파일 보호

ncli pd protect name=<PD NAME> files=<File Name(s)> cg-name=<NAME>

PD 스냅샷 생성

설명: PD의 One-Time 스냅샷 생성

ncli pd add-one-time-snapshot name=<PD NAME> retention-time=<seconds>

원격 사이트로 스냅샷 및 복제 스케줄 생성

설명: 스냅샷을 생성하고, n개의 원격 사이트로의 복제 스케줄 생성

ncli pd set-schedule name=<PD NAME> interval=<seconds> retention-policy=<POLICY> remote-sites=<REMOTE SITE NAME>

복제 상태 출력

설명: 복제 상태 모니터링

ncli pd list-replication-status

PD를 원격 사이트로 마이그레이션

설명: PD를 원격 사이트로 페일오버

ncli pd migrate name=<PD NAME> remote-site=<REMOTE SITE NAME>

PD 활성화

설명: 원격 사이트에서 PD를 활성화 시킴

ncli pd activate name=<PD NAME>

DSF 쉐도우 클론 활성화

설명: DSF 쉐도우 클론 기능 활성화

ncli cluster edit-params enable-shadow-clones=true

vDisk의 데이터 중복제거 설정

설명: 데이터 중복제거 활성화 및 특정 vDisk에 대한 On-Disk 데이터 중복제거 활성화

ncli vdisk edit name=<VDISK NAME> fingerprint-on-write=<true/false> on-disk-dedup=<true/false>

클러스터 리질리언시 상태 체크

# 노드 상태 (Node status)
ncli cluster get-domain-fault-tolerance-status type=node

# 블록 상태 (Block status)
ncli cluster get-domain-fault-tolerance-status type=rackable_unit

PowerShell CMDlets

아래에서 뉴타닉스 PowerShell CMDlets, 사용 방법 및 Windows PowerShell의 몇 가지 일반적인 배경에 대해 다룬다.

기본 설명

윈도우즈 PowerShell은 .NET 프레임워크 기반의 강력한 쉘 및 스크립트 언어이다. 언어를 사용하기가 매우 간단하며 직관적인 인터액티브 방식으로 제작되었다. PowerShell에는 몇 가지 주요 컨스트럭트/아이템이 있다.

CMDlets

CMDlets은 특정 오퍼레이션을 수행하는 명령 또는 .NET 클래스이다. 이들은 대개 Getter/Setter 방법론을 따르며 일반적으로 <Verb>-<Noun> 기반 구조를 사용한다. 예를 들어 Get-Process, Set-Partition 등과 같다.

파이핑 또는 파이프라이닝

파이핑은 PowerShell에서 매우 중요한 컨스트럭트로(Linux에서 사용하는 것과 유사) 정확하게 사용하면 작업을 크게 단순화할 수 있다. 파이핑을 사용하면 기본적으로 파이프라인의 한 섹션의 결과를 파이프라인의 다음 섹션의 입력으로 사용할 수 있다. 파이프라인은 필요한 만큼 길어질 수 있다 (파이프의 다음 섹션으로 공급되는 출력이 남아 있다고 가정). 아주 간단한 예제는 현재 프로세스를 가져와서 특정 특성이나 필터와 일치하는 프로세스를 찾아서 정렬하는 것이다.

Get-Service | where {$_.Status -eq "Running"} | Sort-Object Name


for-each 대신에 파이핑을 사용할 수 있다. 예를 들면 다음과 같다.

# For each item in my array
$myArray | %{
  # Do something
}

주요 오브젝트 유형

다음은 PowerShell의 주요 오브젝트 유형의 일부이다. getType() 메소드를 사용하여 오브젝트 유형을 쉽게 얻을 수 있다. 예를 들어 $someVariable.getType()은 오브젝트 유형을 반환한다.

변수

$myVariable = "foo"

Note: 변수를 일련의 명령 또는 명령 파이프라인의 출력으로 설정할 수 있다.

$myVar2 = (Get-Process | where {$_.Status -eq "Running})

이 예제에서 괄호 안의 명령이 먼저 수행되고 그 결과가 변수에 저장된다.

배열

$myArray = @("Value","Value")

Note: 배열, 해시 테이블 또는 사용자 정의 오브젝트의 배열을 가질 수 있다.

해시 테이블

$myHash = @{"Key" = "Value";"Key" = "Value"}

유용한 명령어

특정 CMDlet에 대한 도움말 내용 얻기 (Linux에서 man 페이지와 유사).

Get-Help <CMDlet Name>

Example: Get-Help Get-Process

명령 또는 오브젝트의 속성 및 메소드를 나열한다.

<Some expression or object> | Get-Member

Example: $someObject | Get-Member

핵심 뉴타닉스 CMDlets 및 사용법

뉴타닉스 CMDlets은 프리즘 UI(AOS 4.0.1 이상의 버전)에서 직접 다운로드할 수 있으며 오른쪽 상단의 드롭-다운 메뉴에서 찾을 수 있다.

Prism CMDlets Installer Link
Figure 8-3. 프리즘 CMDlets 인스톨러 링크 (Prism CMDlets Installer Link)
뉴타닉스 Snappin 로드

Snappin이 로드되어 있는지 확인하고 그렇지 않으면 로드한다.

if ( (Get-PSSnapin -Name NutanixCmdletsPSSnapin -ErrorAction SilentlyContinue) -eq $null )
{
    Add-PsSnapin NutanixCmdletsPSSnapin
}

뉴타닉스 CMDlets 목록

Get-Command | Where-Object{$_.PSSnapin.Name -eq "NutanixCmdletsPSSnapin"}

아크로폴리스 클러스터에 연결

Connect-NutanixCluster -Server $server -UserName "myuser" -Password (Read-Host "Password: " -AsSecureString) -AcceptInvalidSSLCerts

특정 검색 문자열과 일치하는 뉴타닉스 VM 가져오기

Set to variable

$searchString = "myVM"
$vms = Get-NTNXVM | where {$_.vmName -match $searchString}

Interactive

Get-NTNXVM | where {$_.vmName -match "myString"}

Interactive and formatted

Get-NTNXVM | where {$_.vmName -match "myString"} | ft

뉴타닉스 vDisk 가져오기

Set to variable

$vdisks = Get-NTNXVDisk

Interactive

Get-NTNXVDisk

Interactive and formatted

Get-NTNXVDisk | ft

뉴타닉스 컨테이너 가져오기

Set to variable

$containers = Get-NTNXContainer

Interactive

Get-NTNXContainer

Interactive and formatted

Get-NTNXContainer | ft

뉴타닉스 PD 가져오기

Set to variable

$pds = Get-NTNXProtectionDomain

Interactive

Get-NTNXProtectionDomain

Interactive and formatted

Get-NTNXProtectionDomain | ft

뉴타닉스 컨시스턴시 그룹 가져오기

Set to variable

$cgs = Get-NTNXProtectionDomainConsistencyGroup

Interactive

Get-NTNXProtectionDomainConsistencyGroup

Interactive and formatted

Get-NTNXProtectionDomainConsistencyGroup | ft

리소스 및 스크립트

NOTE: 위의 일부 스크립트는 정상적으로 동작하지 않을 수 있으므로 참조 목적으로만 사용해야 한다.

뉴타닉스 Github (https://github.com/nutanix)를 방문하면 좀 더 많은 스크립트를 찾을 수 있다.

Book of Acropolis

a·crop·o·lis - /? ' krap?lis/ - noun - data plane
storage, compute and virtualization platform.

아키텍처

아크로폴리스는 분산 다중 자원 관리자, 오케스트레이션 플랫폼 및 데이터 플레인이다.

세 가지 주요 컴포넌트로 나뉜다.

  • 분산 스토리지 패브릭 (Distributed Storage Fabric: DSF)
    • 뉴타닉스 플랫폼의 핵심으로 뉴타닉스 분산 파일 시스템(Nutanix Distributed Filesystem: NDFS)을 확장한다. NDFS는 이제 스토리지 자원을 풀링하는 분산 시스템에서 대규모의 성능이 뛰어난 스토리지 플랫폼으로 발전하였다.
  • 앱 모빌리티 패브릭 (App Mobility Fabric: AMF)
    • 하이퍼바이저는 하드웨어에서 OS를 추상화하고 AMF는 하이퍼바이저에서 워크로드(VM, 스토리지, 컨테이너 등)를 추상화한다. 이를 통해 하이퍼바이저, 클라우드 간에 워크로드를 동적으로 이동할 수 있을 뿐만 아니라 뉴타닉스 노드가 하이퍼바이저를 변경할 수 있는 기능을 제공한다.
  • 하이퍼바이저
    • CentOS KVM 하이퍼바이저 기반의 다목적 하이퍼바이저.

뉴타닉스가 하는 모든 것이 분산되어 있기 때문에 이를 가상화 및 자원 관리 공간으로 확대하고 있다. 아크로폴리스는 워크로드 및 자원 관리, 프로비저닝 및 오퍼레이션 기능을 제공하는 백엔드 서비스이다. 목표는 오퍼레이션을 위한 단일 플랫폼을 제공하면서 실행 중인 워크로드에서 기반 자원(e.g. 하이퍼바이저, 온-프레미스, 클라우드 등)을 추상화하는 것이다.

이를 통해 워크로드를 하이퍼바이저, 클라우드 공급자 및 플랫폼 간에 원활하게 이동할 수 있다.

이 그림은 다양한 계층에서 아크로폴리스의 개념적 특성을 보여주는 이미지를 강조한다.

High-level Acropolis Architecture
Figure 10-1. 하이-레벨 아크로폴리스 아키텍처 (High-level Acropolis Architecture)
Note
VM 관리를 위해 지원하는 하이퍼바이저 (Supported Hypervisors for VM Management)

AOS 4.7 현재 AHV와 ESXi가 VM 관리를 지원하는 하이퍼바이저이지만 향후 확대될 수 있다. 볼륨 API 및 읽기 전용 오퍼레이션은 여전히 모두에서 지원된다.

아크로폴리스 서비스

아크로폴리스 슬레이브는 태스크 스케줄링, 실행, IPAM 등을 담당하는 선출된 아크로폴리스 마스터와 함께 모든 CVM에서 실행된다. 마스터가 있는 다른 컴포넌트와 마찬가지로 아크로폴리스 마스터가 실패하면 새로운 마스터가 선출된다.

각각의 역할 구분은 다음과 같다.

  • 아크로폴리스 마스터 (Acropolis Master)
    • 태스크 스케줄링 및 실행
    • 통계 정보 수집 및 퍼블리싱
    • 네트워크 컨트롤러 (하이퍼바이저 용)
    • VNC 프록시 (하이퍼바이저 용)
    • HA (하이퍼바이저 용)
  • 아크로폴리스 슬레이브 (Acropolis Slave)
    • 통계 정보 수집 및 퍼블리싱
    • VNC 프록시 (하이퍼바이저 용)

다음은 아크로폴리스 마스터/슬레이브 관계의 개념적 뷰를 보여준다.

Acropolis Services
Figure 10-2. 아크로폴리스 서비스 (Acropolis Services)

동적 스케줄러

자원을 효과적으로 소비하기 위해서는 효율적인 자원 스케줄링이 필수적이다. ADS(Acropolis Dynamic Scheduler)는 배치 결정을 위해 컴퓨팅 활용률(CPU/MEM)에 의존하는 전통적인 스케줄링 방법을 확장한다. VM 및 볼륨(ABS) 배치 결정을 위해 컴퓨팅뿐만 아니라 스토리지와 다른 요소를 활용한다. 이를 통해 자원이 효과적으로 소비되고 최종 사용자 성능이 최적화된다.

자원 스케줄링은 두 가지 핵심 영역으로 나눌 수 있다.

  • 초기 배치 (Initial Placement)
    • 전원을 켤 때 항목이 스케줄링되는 위치
  • 런타임 최적화 (Runtime Optimization)
    • 런타임 메트릭스 기반으로 워크로드 이동

오리지널 아크로폴리스 스케줄러는 출시 이후 초기 배치 결정을 담당했었다. AOS 5.0에서 출시된 ADS는 이를 바탕으로 런타임 자원 최적화를 제공한다.

그림은 스케줄러 아키텍처의 하이-레벨 뷰를 보여준다.

Acropolis Dynamic Scheduler
Figure. 아크로폴리스 동적 스케줄러 (Acropolis Dynamic Scheduler: ADS)

동적 스케줄러는 배치 최적화를 위해 하루 종일 지속적으로 실행된다 (현재 15분마다: Gflag: lazan_anomaly_detection_period_secs). 예상 수요는 과거 활용률 값을 사용하여 계산되고 스무딩 알고리즘에 제공된다. 이 예상 수요는 이동을 결정하기 위해 사용되며 갑작스러운 스파이크가 결정을 왜곡하지 않도록 한다.

Note
자원 최적화에 대한 다른 접근 방식 (A different approach towards resource optimization)

기존 스케줄링/최적화 플랫폼(VMware DRS, Microsoft PRO)을 살펴보면 클러스터 자원 전체에서 워크로드/VM의 균형을 균일하게 맞추는데 중점을 둔다. NOTE: 왜곡을 제거하기 위해 얼마나 적극적으로 시도하는가는 밸런싱 설정에 따라 결정된다 (e.g. manual -> none, conservative -> some, aggressive -> more).

예를 들어 클러스터에 3개의 호스트가 있으며 각 호스트의 사용률이 50%, 5%, 5%이다. 일반적인 솔루션은 각 호스트 활용률이 ~20%가 되도록 워크로드를 재조정하려고 한다. 그런데 왜?

우리가 실제로 하려고 하는 것은 왜곡을 제거하는 것이 아니라 자원에 대한 경합을 제거/무효화하는 것이다. 자원에 대한 경합이 없으면 워크로드 밸런싱으로 얻을 수 있는 이득은 없다. 사실 불필요한 이동을 강요함으로써 우리는 자원을 소비하는 필수적인 추가 작업(e.g. 메모리 전송, 캐시 리로컬라이제이션 등)을 유발한다.

ADS(Acropolis Dynamic Scheduler)는 왜곡 때문이 아니라 자원에 대한 예상 경합이 있는 경우에만 워크로드 이동을 호출한다. NOTE: 아크로폴리스 DSF는 다른 방식으로 동작하고 클러스터 전체에서 데이터의 균일한 분산을 보장하여 핫스팟을 제거하고 재구축 속도를 높인다. DSF에 대한 자세한 내용은 “디스크 밸런싱” 섹션을 참조한다.

전원을 켤 때 ADS는 클러스터 전체에서 VM 초기 배치의 균형을 맞춘다.

배치 결정

배치 결정은 다음 항목을 기반으로 한다.

  • 컴퓨트 사용률 (Compute Utilization)
    • 각 개별 노드의 컴퓨트 사용률을 모니터링한다. 노드의 예상 CPU 할당이 임계 값(현재 호스트 CPU의 85% | Gflag: lazan_host_cpu_usage_threshold_fraction)을 위반하는 경우 워크로드의 균형을 조정하기 위해 해당 호스트에서 VM을 마이그레이션한다. 여기서 언급할 중요한 것은 마이그레이션은 경합이 있는 경우에만 수행된다는 것이다. 노드들 간의 사용률에 왜곡이 있는 경우(e.g. 10%에서 3노드, 50%에서 1노드) 마이그레이션으로 얻을 수 있는 이득이 없기 때문에 자원에 대한 경합이 있을 때까지 마이그레이션을 수행하지 않는다.
  • 스토리지 성능 (Storage Performance)
    • 하이퍼컨버지드 플랫폼이므로 컴퓨트 및 스토리지 지원을 모두 관리한다. 스케줄러는 각 노드의 스타게이트 프로세스 사용률을 모니터링한다. 특정 스타게이트가 할당 임계 값(현재 스타게이트에 할당된 CPU의 85% | Gflag: lazan_stargate_cpu_usage_threshold_pct)을 위반하는 경우 핫스팟을 제거하기 위해 호스트 간에 자원을 마이그레이션한다. 핫 스타게이트를 제거하기 위해 VM 및 ABS 볼륨을 마이그레이션할 수 있다.
  • [Anti-]Affinity Rules
    • Affinity 또는 Anti-Affinity 제약조건은 환경의 다른 자원에 기반하여 특정 자원이 스케줄링되는 위치를 결정한다. 어떤 경우에 라이선스 이슈로 VM들을 동일 노드에서 실행해야 한다. 이 경우에 VM들은 동일 호스트에 Affined 된다. 다른 경우 가용성을 위해 VM들을 서로 다른 노드에서 실행해야 한다. 이 경우에 VM들은 Anti-Affined 된다.

스케줄러는 이전 항목을 토대로 워크로드 배치의 최적화를 위해 최선을 다할 것이다. 시스템은 너무 많은 마이그레이션이 발생하지 않도록 하기 위해 자원의 이동에 대한 패널티를 부과한다. 이것은 이동이 워크로드에 부정적인 영향을 미치지 않도록 하기 위한 핵심 항목이다.

마이그레이션 후 시스템은 "효과성"을 판단하고 실제 이득이 무엇인지 확인한다. 이 학습 모델은 마이그레이션 결정에 유효한 근거가 있는지 확인하기 위해 자체 최적화할 수 있다.

보안 및 암호

보안

보안은 뉴타닉스 플랫폼의 핵심 부분이며 첫날부터 염두에 두었다. 뉴타닉스 SecDL(Security Development Lifecycle)은 개발 프로세스의 모든 단계에 보안을 통합한다. 이 시스템은 최종 사용자가 사후에 플랫폼의 보안을 "강화(Harden)"하도록 요구하는 것이 아닌 공장에서 안전하게 배송된다.

뉴타닉스는 스택의 일부(온-프레미스 및 오프-프레미스)에 대해 다음과 같은 보안 인증/자격을 보유하고 있다.

  • 공통 평가 기준 (Common Criteria)
    • 공통 평가 기준은 주로 공공 시장(주로 국방 및 인텔리전스 용)에 컴퓨터 제품을 판매하는 회사가 한 세트의 표준에 대해서만 평가받도록 하기 위해 만들어졌다. CC는 캐나다, 프랑스, 독일, 네덜란드, 영국 및 미국 정부에 의해 개발되었다.
  • STIGs (Security Technical Implementation Guides)
    • DOD IA 및 IA-활성화된 디바이스/시스템에 대한 설정 표준. 1998년부터 DISA FSO(Field Security Operations)가 보안 기술 구현 안내서(STIGs)를 제공함으로써 DoD(국방부) 보안 시스템의 보안 상태를 향상시키는 중요한 역할을 수행하였다. STIGs에는 악의적인 컴퓨터 공격에 취약할 수 있는 정보시스템/소프트웨어를 "잠금"할 수 있는 기술 지침이 포함되어 있다.
  • FIPS 140-2
    • FIPS 140-2 표준은 민감하지만 기밀이 아닌 정보를 수집, 저장, 전송, 공유 및 보급하는 정부 부처 및 규제 산업(금융 및 헬스-케어 기관과 같은)에서 사용할 수 있도록 제품을 인증받으려는 민간 부분 벤더가 제작한 암호화 모듈을 위한 정보 기술 보안 인증 프로그램이다.
  • NIST 800-53
  • NIST 800-131a
  • ISO 27001
  • ISO 27017
  • ISO 27018
SMCA (Security Configuration Management Automation)

뉴타닉스 보안 엔지니어링은 이제 고객에게 특정 시점의 보안 기준 점검에서 지속적인 모니터링/자체-교정 기준으로 발전하여 클러스터의 모든 CVM/AHV가 배포 수명주기 동안 기준 준수를 유지할 수 있도록 한다. 이 새로운 혁신은 문서화된 보안 기준(STIGs)의 모든 컴포넌트를 검사하고, 준수하지 않은 것으로 발견되면 고객의 개입 없이 지원되는 보안 기준으로 재설정하도록 한다.

Note
애드 혹 SCMA 실행 (Ad-hoc SCMA execution)

SCMA는 설정된 스케줄(기본값: HOURLY)에 기반하여 실행되지만 온-디멘드로도 실행할 수 있다. SCMA 툴을 실행하려면 CVM에서 다음 명령어를 수행한다.

# Run on a single CVM
sudo salt-call state.highstate

# Run on all CVMs
allssh "sudo salt-call state.highstate"

뉴타닉스 nCLI를 통해 고객은 보다 엄격한 보안 요구 사항을 지원하기 위해 다양한 구성 설정을 제어할 수 있다.

CVM 보안 설정

SCMA 정책의 클러스터 전체 설정을 지원하기 위해 nCLI에 다음 명령이 추가되었다. 아래 목록은 모든 명령과 기능을 제공한다.

CVM 보안 설정 가져오기

ncli cluster get-cvm-security-config


이 명령은 현재 클러스터 설정을 출력한다. 기본 출력은 다음과 같이 표시된다.

Enable Aide : false
Enable Core : false
Enable High Strength P... : false
Enable Banner : false
Enable SNMPv3 Only : false
Schedule : DAILY


CMV 로그인 배너 설정

이 명령은 뉴타닉스 CVM에 로그인할 때 동의 로그인 배너의 국방부(DoD) 지식을 활성화 또는 비활성화한다.

ncli cluster edit-cvm-security-params enable-banner=[yes|no] #Default:no

Note
사용자 정의 로그인 배너 (Custom login banner)

기본적으로 동의 로그인 배너의 국방부 지식이 사용된다. 사용자 정의 배너를 활용하려면 다음 단계를 수행한다 (CVM에서 Nutanix user로 실행).

  1. 기존 배너의 백업 생성
    • sudo cp -a /srv/salt/security/KVM/sshd/DODbanner /srv/salt/security/KVM/sshd/DODbannerbak
  2. vi를 사용하여 기존 배너를 수정
    • sudo vi /srv/salt/security/KVM/sshd/DODbanner
  3. 모든 CVM에서 단계를 반복하거나 수정된 배너를 모든 CVM으로 복사
  4. 우의 명령을 사용하여 배너 활성화

CVM 패스워드 강도 설정

이 명령은 고강도 패스워드 정책을 활성화 또는 비활성화한다 (minlen=15, difok=8, remember=24).

ncli cluster edit-cvm-security-params enable-high-strength-password=[yes|no] #Default:no


AIDE(Advanced Intrusion Detection Environment) 설정

이 명령은 AIDE 서비스의 주 단위 실행을 활성화 또는 비활성화한다.

ncli cluster edit-cvm-security-params enable-aide=true=[yes|no] #Default:no


SNMPv3 전용 설정

이 명령은 SNMPv3 전용 트랩을 활성화 또는 비활성화한다.

ncli cluster edit-cvm-security-params enable-snmpv3-only=[true|false] #Default:false


SCMA 스케줄 설정

이 명령은 SCMA 실행 주기를 설정한다.

ncli cluster edit-cvm-security-params schedule=[HOURLY|DAILY|WEEKLY|MONTHLY] #Default:HOURLY

하이퍼바이저 보안 설정

SCMA 정책의 클러스터 전체 설정을 지원하기 위해 nCLI에 다음 명령이 추가되었다. 아래 목록은 모든 명령과 기능을 제공한다.

하이퍼바이저 보안 설정 가져오기

ncli cluster get-hypervisor-security-config


이 명령은 현재 클러스터 설정을 출력한다. 기본 출력은 다음과 같이 표시된다.

Enable Aide : false Enable Core : false Enable High Strength P... : false Enable Banner : false Schedule : DAILY


하이퍼바이저 로그인 배너 설정

이 명령은 뉴타닉스 AHV에 로그인할 때 동의 로그인 배너의 국방부(DoD) 지식을 활성화 또는 비활성화한다.

ncli cluster edit-hypervisor-security-params enable-banner=[yes|no] #Default:no


하이퍼바이저 패스워드 강도 설정

이 명령은 고강도 패스워드 정책을 활성화 또는 비활성화한다 (minlen=15, difok=8, remember=24).

ncli cluster edit-hypervisor-security-params enable-high-strength-password=[yes|no] #Default:no


AIDE(Advanced Intrusion Detection Environment) 설정

이 명령은 AIDE 서비스의 주 단위 실행을 활성화 또는 비활성화한다.

ncli cluster edit-hypervisor-security-params enable-aide=true=[yes|no] #Default:no


SCMA 스케줄 설정

이 명령은 SCMA 실행 주기를 설정한다.

ncli cluster edit-hypervisor-security-params schedule=[HOURLY|DAILY|WEEKLY|MONTHLY] #Default:HOURLY

클러스터 잠금

클러스터 잠금은 패스워드 기반 CVM 액세스를 비활성화하고 키 기반 액세스만 허용하는 기능이다.

클러스터 잠금 설정은 프리즘의 설정 메뉴에서 찾을 수 있다.

Cluster Lockdown Menu
Figure. 클러스터 잠금 메뉴 (Cluster Lockdown Menu)

현재 설정이 표시되고 액세스를 위해 SSH 키를 추가/제거할 수 있다.

Cluster Lockdown Page
Figure. 클러스터 잠금 페이지 (Cluster Lockdown Page)

새로운 키를 추가하려면 “New Public Key” 버튼을 클릭하고 공개 키 세부 사항을 입력한다.

Cluster Lockdown - Add Key
Figure. 클러스터 잠금 – 키 추가 Cluster Lockdown - Add Key)
Note
SSH 키 작업 (Working with SSH keys)

SSH 키를 생성하려면 다음 명령을 실행한다.

ssh-keygen -t rsa -b 2048


그러면 키 쌍이 만들어지고 두 개의 파일이 생성된다.

  • id_rsa (private key)
  • id_rsa.pub (public key - this one is used when adding a key to the cluster)

일부 키를 추가하고 액세스 권한을 확인한 후에 “Enable Remote Login with Password”을 선택 해제하여 패스워드 기반 로그인을 비활성화할 수 있다. 작업을 확인하는 팝업이 나타나면 “OK”를 클릭하여 잠금을 진행한다.

데이터 암호화 및 키 관리

데이터 암호화는 권한이 있는 사람만 데이터를 이해할 수 있는 방식으로 당사자들이 데이터를 인코딩할 수 있도록 허용하는 방법으로 권한이 없는 사람은 이해할 수 없다.

예를 들어 누군가에게 보내고 싶은 메시지가 있고 그 메시지만 읽을 수 있도록 하려면 암호(키)로 메시지(일반 텍스트)를 암호화하고 암호화된 메시지(암호 텍스트)를 보낼 수 있다. 이 메시지를 도난당하거나 가로채면 공격자는 메시지를 해독할 암호 없이 대부분 쓸모없는 암호문만 볼 수 있다. 원하는 당사자가 메시지를 받으면 우리가 제공한 키를 사용하여 메시지를 해독할 수 있다.

데이터를 암호화하는 몇 가지 주요 방법이 있다.

  • 대칭 암호화 (개인 키 암호화)
    • 데이터 암호화 및 복호화를 위해 동일 키 사용
    • 예: AES, PGP*, Blowfish, Twofish, etc.
  • 비대칭 암호화 (공개 키 암호화)
    • 하나의 키는 암호화(공개 키)를 위해 사용하고 다른 키는 복호화(개인 키)를 위해 사용
    • 예: RSA, PGP*, etc.

NOTE: PGP(또는 GPG)는 대칭 키와 비대칭 키를 모두 사용한다.

데이터 암호화에 대해 이야기할 때, 암호화는 일반적으로 두 가지 주요 컨텍스트에서 수행된다.

  • 동적 데이터(In-flight): 두 당사자 간에 전송되는 데이터 (e.g. 네트워크를 통해 데이터 전송)
  • 정적 데이터(At-Rest): 정적 데이터 (e.g. 디바이스에 저장된 데이터)

AOS 5.8 버전에서 뉴타닉스는 정적 데이터(At-Rest) 암호화를 지원한다.

다음 섹션에서 뉴타닉스가 데이터 암호화 및 키 관리 옵션을 관리하는 방법에 대해 설명한다.

데이터 암호화

뉴타닉스는 다음과 같은 세 가지 주요 옵션을 통해 정적 데이터(Data-At-Rest) 암호화를 제공한다.

  • 네이티브 소프트웨어 기반 암호화(FIPS-140-2 Level-1) * AOS 5.5에서 출시
  • 자체 암호화 드라이브(SED) 사용 (FIPS-140-2 Level-2)
  • 소프트웨어 + 하드웨어 암호화

암호화는 클러스터 또는 컨테이너 레벨에서 설정하며 하이퍼바이저 유형에 따라 다르다.

  • 클러스터 레벨 암호화:
    • AHV, ESXi, Hyper-V
  • 컨테이너 레벨 암호화:
    • ESXi, Hyper-V

NOTE: SED 기반 암호화를 사용하여 배포하는 경우 물리 디바이스가 자체적으로 암호화되므로 클러스터 레벨이 된다.

설정 메뉴(기어 아이콘)에서 'Data-at-Rest Encryption'로 이동하여 클러스터의 암호화 상태를 볼 수 있다. 현재 상태를 제공하고 암호화를 설정할 수 있다 (현재 활성화되어 있지 않은 경우).

이 예에서는 클러스터 레벨의 암호화가 설정되어 있음을 알 수 있다.

Data Encryption - Enabled (cluster level)
Figure. 데이터 암호 – 활성화 (클러스터 레벨) (Data Encryption - Enabled (cluster level))

이 예제에서는 다음과 같은 특정 컨테이너에 대해 암호화가 사용되었다.

Data Encryption - Enabled (container level)
Figure. 데이터 암호 – 활성화 (컨테이너 레벨) (Data Encryption - Enabled (container level))

“Edit Configuration” 버튼을 클릭하여 설정을 활성화/수정할 수 있다. 암호화에 사용되는 KMS 또는 현재 활용 중인 KMS 유형을 설정할 수 있는 메뉴가 나타난다.

Data Encryption - Configure
Figure. 데이터 암호 – 설정 (Data Encryption - Configure)

외부 KMS인 경우 메뉴는 서명을 위해 CA에 제공할 수 있는 CSR 요청 프로세스로 안내한다.

네이티브 소프트웨어 기반 암호화

뉴타닉스 소프트웨어 암호화는 네이티브 AES-256 정적 데이터 암호화를 제공한다. 이는 모든 KMIP 또는 TCG 호환 외부 KMS 서버(Vormetric, SafeNet 등) 또는 AOS 5.8에서 도입된 뉴타닉스 네이티브 KMS(아래에서 자세히 설명)와 상호 작용할 수 있다. 암호화/복호화를 위해 시스템은 인텔 AES-NI 가속을 활용하여 소프트웨어로 이 작업을 수행할 때의 잠재적 성능 영향을 최소화한다.

데이터가 쓰일 때(OpLog 및 익스텐트 스토어) 데이터는 체크섬 경계에서 디스크에 쓰이기 전에 암호화된다.

암호화는 디스크에 쓰기 전에 데이터에 마지막으로 적용되는 변환이다.

Data Encryption - Transform Application
Figure. 데이터 암호 – Application 변환 (Data Encryption - Transform Application)
Note
암호화 및 데이터 효율성 (Encryption and Data Efficiency)

중복제거 또는 압축을 적용한 후에 데이터를 암호화하므로 이러한 방법을 통한 모든 스토리지 용량 절감 가능이 유지된다. 간단히 말해 중복제거 및 압축 비율은 암호화되거나 암호화되지 않은 데이터에 대해 정확히 동일하다.

데이터를 읽을 때 체크섬 경계에서 데이터를 읽고 복호화 작업을 수행한 후에 게스트 VM에 데이터를 반환한다. 체크섬 경계에서 암호화/복호화 작업을 수행하므로 읽기 증폭이 발생하지 않는다. 인텔 AES NI 오프로드 기능을 활용하기 때문에 성능/레이턴시에 미치는 영향은 거의 없다.

SED 기반 암호화

이 그림은 아키텍처의 하이-레벨 개요를 보여준다.

Data Encryption - SED
Figure. Data Encryption - SED (Data Encryption - SED)

SED 암호화는 스토리지 디바이스를 보안 또는 보안되지 않은 상태를 갖는 “데이터 밴드"로 분할하여 동작한다. 뉴타닉스의 경우 부트 및 뉴타닉스 홈 파티션은 간단하게 암호화된다. 모든 디바이스 및 밴드는 Level-2 표준에 따라 빅 키로 강력하게 암호화된다.

클러스터가 시작되면 KMS 서버를 호출하여 드라이브 잠금 해제 키를 얻는다. 보안을 위해 클러스터에서 키는 캐싱 되지 않는다. 콜드 부트 및 IPMI 리셋인 경우 노드는 드라이브 잠금 해제를 위해 KMS 서버를 다시 호출할 필요가 있다. CVM을 소프트 리부트 하는 경우에 이러한 과정은 발생하지 않는다.

키 관리 (KMS)

뉴타닉스는 다른 전용 KMS 솔루션의 대안으로 네이티브 키 관리(로컬 키 관리자 - LKM) 및 스토리지 기능(AOS 5.8에서 도입)을 제공한다. 이는 전용 KMS 솔루션의 필요성을 없애고 환경을 단순화하기 위해 도입되었지만 외부 KMS는 여전히 지원된다.

이전 섹션에서 언급했듯이 키 관리는 모든 데이터 암호화 솔루션에서 매우 중요한 부분이다. 안전한 키 관리 솔루션을 제공하기 위해 스택 전체에서 여러 개의 키가 사용된다.

솔루션에 세 가지 유형의 키가 사용된다.

  • 데이터 암호화 키 (DEK: Data Encryption Key)
    • 데이터 암호화에 사용되는 키
  • 키 암호화 키 (KEK: Key Encryption Key)
    • DEK 암호화에 사용되는 암호화 키
  • 마스터 암호화 키 (MEK: Master Encryption Key)
    • KEK 암호화에 사용되는 암호화 키
    • 로컬 키 관리자를 사용할 때만 적용 가능

다음 그림은 다양한 키와 KMS 옵션 간의 관계를 보여준다.

Data Encryption - Key Management
Figure. 데이터 암호 – 키 관리 (Data Encryption - Key Management)

LKM(로컬 키 매니저) 서비스는 모든 뉴타닉스 노드에 분산되며 각 CVM에서 기본적으로 실행된다. 이 서비스는 FIPS 140-2 Crypto 모듈(현재 인증 작업 진행 중)을 사용하며, 키 관리는 키 관리 활동(e.g. re-key, backup keys 등) 외에 최종 사용자에게 투명하다.

데이터 암호화를 설정할 때 'Cluster’s local KMS'를 선택하면 네이티브 KMS를 활용할 수 있다.

Data Encryption - Configure
Figure. 데이터 암호 - 설정 (Data Encryption - Configure)

마스터 키(MEK: Master Encryption Key)는 키의 리질리언시 및 보안을 위해 Shamir의 Secret Sharing 알고리즘을 사용하여 클러스터의 모든 노드에 분할되어 저장된다. 키를 다시 구성하려면 최소 ROUNDUP (N / 2) 노드를 사용할 수 있어야 한다. 여기서 N은 클러스터의 노드 수다.

Note
키 백업 및 키 로테이션 (Key Backups and Key Rotation)

암호화가 활성화되면 데이터 암호화 키(DEK)를 백업하는 것이 좋다. 백업을 수행하는 경우 강력한 암호로 보안을 유지하고 안전한 위치에 저장해야 한다.

시스템은 KEK와 MEK를 모두 로테이션(re-key)할 수 있는 기능을 제공한다. 시스템은 매년 마스터 키(MEK)를 자동으로 로테이션하지만 필요에 따라 이 작업을 수행할 수도 있다. 노드 추가/제거의 경우 마스터 키도 로테이션 한다.

분산 스토리지 패브릭

분산 스토리지 패브릭(Distributed Storage Fabric: DSF)은 중앙 집중식 스토리지 어레이처럼 하이퍼바이저에게 보이지만 모든 I/O는 로컬에서 처리되어 최고의 성능을 제공한다. 이러한 노드들이 분산 시스템을 구성하는 방법에 대한 자세한 내용은 다음 섹션에서 확인할 수 있다.

데이터 구조

아크로폴리스 분산 스토리지 패브릭은 다음과 같은 하이-레벨 스트럭트로 구성되어 있다.

스토리지 풀 (Storage Pool)
  • 주요 역할: 물리적 디바이스의 그룹 (Group of physical devices)
  • 설명: 스토리지 풀은 클러스터의 PCIe SSD, SSD 및 HDD 디바이스를 포함하는 물리적 스토리지 디바이스의 그룹이다. 스토리지 풀은 여러 개의 뉴타닉스 노드에 걸쳐있을 수 있으며 클러스터가 확장됨에 따라 스토리지 풀도 확장된다. 대부분의 설정에서는 단일 스토리지 풀만 활용된다.
컨테이너 (Container)
  • 주요 역할: VM/파일의 그룹 (Group of VMs/files)
  • 설명: 컨테이너는 스토리지 풀의 논리적 세그먼트이며 VM 또는 파일(vDisk) 그룹을 포함한다. 일부 설정 옵션(e.g. RF)은 컨테이너 레벨에서 설정되지만 개별 VM/파일 레벨에서 적용된다. 컨테이너는 일반적으로 데이터스토어(NFS/SMB인 경우)와 1:1 매핑을 가진다.
vDisk
  • 주요 역할: vDisk
  • 설명: vDisk는 .vmdk, VM 하드 디스크를 포함하여 DSF에서 512KB가 넘는 파일이다. vDisk는 논리적으로 "블록 맵(block map)"을 구성하는 vBlock으로 구성되어 있다.
Note
최대 DSF vDisk 크기 (Maximum DSF vDisk Size)

DSF/스타게이트 측면에서 vDisk 크기에 부과된 인위적인 제한은 없다. AOS 4.6에서 vDisk 크기는 크기를 바이트 단위로 저장하는 부호 있는 64비트 정수로 저장된다. 이는 이론상 최대 vDisk 크기가 2^63-1 or 9E18(9 Exabytes) 일 수 있음을 의미한다. 이 값 미만의 제한은 ESXi의 최대 vmdk 크기와 같은 클라이언트 측의 제한 때문이다.

다음 그림은 DSF와 하이퍼바이저 간의 매핑 관계를 보여준다.

High-level Filesystem Breakdown
Figure 11-2. 하이-레벨 파일시스템 분할 (High-level Filesystem Breakdown)
vBlock
  • 주요 역할: 1MB의 vDisk 주소 공간 (1MB chunk of vDisk address space)
  • 설명: vBlock은 vDisk를 구성하는 1MB 청크의 가상 주소 공간이다. 예를 들어 100MB의 vDisk는 100x1MB vBlock이 있고, vBlock 0은 0-1MB, vBlock 1은 1-2MB이다. 이 vBlock은 익스텐트 그룹으로 디스크에 파일로 저장되는 익스텐트에 매핑된다.
익스텐트 (Extent)
  • 주요 역할: 논리적으로 연속적인 데이터 (Logically contiguous data)
  • 설명: 익스텐트는 n개의 연속적인 블록(게스트 OS의 블록 크기에 따라 달라짐)으로 구성된 1MB의 논리적으로 연속적인 데이터이다. 익스텐트는 세분화 및 효율성을 위해 서브-익스텐트(슬라이스로 알려진) 기준으로 쓰기/읽기/수정된다. 익스텐트의 슬라이스는 캐시로 이동될 때 읽기/캐시되는 데이터의 양에 따라 트림된다.
익스텐트 그룹 (Extent Group)
  • 주요 역할: 물리적으로 연속되어 저장되는 데이터 (Physically contiguous stored data)
  • 설명: 익스텐트 그룹은 1MB 또는 4MB의 물리적으로 연속되어 저장되는 데이터이다. 이 데이터는 CVM이 소유한 스토리지 디바이스에 파일로 저장된다. 익스텐트는 성능 향상을 목적으로 노드/디스크 간에 데이터 스트라이핑을 제공하기 위해 익스텐트 그룹 간에 동적으로 분산된다. NOTE: AOS 4.0 현재 익스텐트 그룹은 중복제거에 따라 1MB 또는 4MB가 될 수 있다.

다음 그림은 이러한 스트럭트와 다양한 파일 시스템 간의 관계를 보여준다.

Low-level Filesystem Breakdown
Figure 11-3. 로우-레벨 파일시스템 분해 (Low-level Filesystem Breakdown)

다음은 이러한 유닛이 어떻게 관련되어 있는지를 보여주는 다른 그래픽 표현이다.

Graphical Filesystem Breakdown
Figure 11-4. 그래픽컬 파일시스템 분해 (Graphical Filesystem Breakdown)

입출력 경로 및 캐시

동영상 시청을 원하시면 다음 링크를 클릭하세요: LINK


일반적인 하이퍼컨버지드 스토리지 I/O 경로는 다음과 같은 핵심 계층으로 분류할 수 있다.

  1. 가상 디스크에 대한 게스트 OS(UVM)
    • 이것은 뉴타닉스와 변함없이 유지된다. 하이퍼바이저에 따라 게스트 OS는 디바이스 드라이버를 사용하여 가상 디스크 디바이스와 통신한다. 하이퍼바이저에 따라 이는 virtio-scsi(AHV), pv-scsi(ESXi) 등이 될 수 있다. 가상 디스크는 하이퍼바이저에 따라 다르다 (e.g. vmdk, vhd 등).
  2. 아크로폴리스 DSF에 대한 하이퍼바이저 (CVM을 통해)
    • 하이퍼바이저와 뉴타닉스 간의 통신은 CVM과 하이퍼바이저의 로컬 인터페이스를 통한 표준 스토리지 프로토콜(e.g. iSCSI, NFS, SMBv3)을 통해 이루어진다. 이 시점에서 모든 통신은 호스트의 로컬에서 발생한다 (I/O가 원격인 시나리오가 있다 (e.g. 로컬 CVM 다운 등)).
  3. 뉴타닉스 I/O 경로
    • 이것은 하이퍼바이저와 UVM에 모두 투명하며 뉴타닉스 플랫폼에서 기본으로 제공된다.

다음 이미지는 이러한 계층에 대한 하이-레벨 개요를 보여준다.

High-level I/O Path
Figure. 하이-레벨 I/O 경로 (High-level I/O Path)

뉴타닉스 I/O 경로는 다음과 같은 하이-레벨 컴포넌트로 구성되어 있다.

DSF I/O Path
Figure 11-5. DSF I/O 경로 (DSF I/O Path)

*AOS 5.10부터 AES(Autonomous Extent Store)를 사용하여 필요조건이 만족될 때 지속적인 랜덤 워크로드를 처리할 수 있다.

^올-플래시 노드 설정에서 익스텐트 스토어는 SSD 디바이스로만 구성되며, 단일 플래시 계층만 존재하므로 Tier ILM이 발생하지 않는다. 하이브리드 플래시(e.g. NVMe, 인텔 옵테인 등 + SATA SSD)를 사용하는 경우 고성능 미디어는 Tier 0, 저성능 미디어는 Tier 1이 된다. 하이브리드인 경우, 올-플래시 시나리오가 아닌, 플래시는 Tier 0, HDD는 티어 1이 된다.

OpLog
  • 주요 역할: 영구 쓰기 버퍼 (Persistent write buffer)
  • 설명: OpLog는 파일 시스템 저널과 유사하며 랜덤 쓰기의 버스트를 처리하고 이를 병합한 다음 데이터를 순차적으로 익스텐트 스토어로 배수하는 스테이징 영역으로 구축된다. 쓰기 시에 OpLog는 데이터의 가용성을 위해 쓰기를 승인하기 전에 다른 n개의 CVM OpLog에 동기적으로 복제한다. 모든 CVM OpLog는 복제에 참여며 부하에 따라 동적으로 선택된다. OpLog는 매우 빠른 쓰기 I/O 성능을 제공하기 위해, 특히 랜덤 I/O 워크로드의 경우, CVM의 SSD 티어에 저장된다. 모든 SSD 디바이스가 참여하여 OpLog 스토리지의 일부를 처리한다. 순차 워크로드의 경우 OpLog를 바이패스하고 쓰기는 익스텐트 스토어로 직접 이동한다. 데이터가 현재 OpLog에 있고 배수되지 않은 경우 모든 읽기 요청은 배수될 때까지 직접적으로 OpLog에서 수행되며, 데이터가 배수되면 익스텐트 스토어/유니파이드 캐시에서 서비스된다. 지문(중복제거로 알려진)이 활성화한 컨테이너의 경우 모든 쓰기 I/O는 해시 알고리즘을 사용하여 지문을 생성하며 유니파이드 캐시에서 지문을 기반으로 중복제거를 가능하게 한다.
Note
vDisk 별 OpLog 사이징 (Per-vDisk OpLog Sizing)

OpLog는 공유 자원이지만 각 vDisk가 동일한 기회를 활용할 수 있도록 vDisk 별로 할당된다. 이는 vDisk 당 OpLog 제한(OpLog에서 vDisk 당 최대 데이터 양)을 통해 구현된다. 여러 개의 vDisk를 갖는 VM은 vDisk 별 제한에 디스크 수를 곱한 만큼 활용할 수 있다.

vDisk 별 제한은 현재 6GB(AOS 4.6 기준)로 이전 버전의 2GB에서 증가하였다.

이것은 다음 Gflag: vdisk_distributed_oplog_max_dirty_MB에 의해 제어된다.

익스텐트 스토어 (Extent Store)
  • 주요 역할: 영구 데이터 스토리지 (Persistent data storage)
  • 설명: 익스텐트 스토어는 DSF의 영구 대용량 스토리지로 모든 디바이스 티어(PCIe SSD, SATA SSD, HDD)에 있으며 추가 디바이스/티어를 용이하게 하기 위해 확장할 수 있다. 익스텐트 스토어에 입력되는 데이터는 A) OpLog에서 배수되거나 B) 본질적으로 순차/지속되며 OpLog를 직접 바이패스한다. 뉴타닉스 ILM은 I/O 패턴에 기반으로 티어 배치를 동적으로 결정하며 티어 간에 데이터를 이동시킨다.
Note
순차 쓰기 특징 (Sequential Write Characterization)

쓰기 IO는 vDisk에 1.5MB 이상의 처리되지 않은 쓰기 IO가 있는 경우에 순차 쓰기로 인식된다 (AOS 4.6 현재). 이를 충족하는 IO는 이미 장렬된 데이터가 크고 병합의 이점을 활용할 수 없기 때문에 OpLog를 바이패스하여 직접 익스텐트 스토어로 이동한다.

이것은 다음 Gflag: vdisk_distributed_oplog_skip_min_outstanding_write_bytes에 의해 제어된다.

큰 IO(e.g. >64K)를 포함한 다른 모든 IO는 OpLog에 의해 처리된다.

AES (Autonomous Extent Store)
  • 주요 역할: 영구 데이터 스토리지 (Persistent data storage)
  • 설명: AES(Autonomous Extent Store)는 AOS 5.10에 도입된 익스텐트 스토어에서 데이터 쓰기/저장을 위한 새로운 방법이다. 주로 로컬 + 클로벌 메타데이터('메타데이터 확장성' 섹션에서 자세히 설명)의 혼합을 활용하며 메타데이터 로컬리티로 인해 훨씬 더 효율적이고 지속적인 성능을 제공한다. 지속적인 랜덤 워크로드는 OpLog를 바이파스하고 AES를 사용하여 익스텐트 스토어에 직접 쓴다. 버스트 랜덤 워크로드는 일반적인 OpLog I/O 경로를 사용하고 가능한 경우에 AES를 사용하여 익스텐트 스토어로 배수한다. NOTE: AOS 5.10부터 AES를 활용하려면 노드가 올-플래시이고 최소 12개의 SSD(NVMe/SATA 혼합 가능)가 있어야 한다.
유니파이드 캐시 (Unified Cache)
  • 주요 역할: 동적 읽기 캐시 (Dynamic read cache)
  • 설명: 유니파이드 캐시는 중복 제거된 읽기 캐시이며 CVM 메모리와 SSD에 걸쳐 있다. 캐시에 없는 데이터의 읽기 요청 시에(또는 특정 지문을 기반으로 하는) 데이터는 메모리에 완전히 저장된 유니파이드 캐시의 싱글-터치 풀에 배치되며 LRU는 데이터가 캐시에서 제거될 때까지 사용된다. 이후의 모든 읽기 요청은 메모리와 SSD로 구성된 멀티-터치 풀의 메모리 부분으로 데이터를 이동시킨다 (실제적으로 데이터는 이동되지 않고 메타데이터만 캐시). 여기서부터 두 개의 LRU 사이클이 있는데, 하나는 인메모리 부분을 위한 것으로 제거는 데이터를 새로운 LRU 카운터가 할당되는 멀티-터치 풀의 SSD 부분으로 이동시킨다. 멀티-터치 풀에 있는 데이터에 대한 모든 읽기 요청은 데이터를 새로운 LRU 카운터가 주어지는 멀티-터치 풀의 피크로 이동시킨다.

다음 그림은 유니파이드 캐시에 대한 하이-레벨 개요를 보여준다.

DSF Unified Cache
Figure 11-6. DSF 유니파이드 캐시 (DSF Unified Cache)
Note
캐시 세분성 및 로직 (Cache Granularity and Logic)

데이터는 4K 단위로 캐시로 가져오고 모든 캐싱 작업은 실시간으로 수행된다 (e.g. 데이터를 캐시로 가져오기 위한 지연 또는 배치 프로세스 데이터가 없음).

각 CVM에는 호스팅 하는(e.g. 동일 노드에서 실행 중인 VM) vDisk의 관리를 위한 자체 로컬 캐시가 있다. vDisk가 복제될 때 (e.g., 새로운 클론, 스냅샷 등) 각 새로운 vDisk는 자신의 블록 맵을 가지며 원본 vDisk는 “변경 불가(Immutable)”로 표시된다. 이를 통해 각 CVM은 캐시 일관성을 갖는 베이스 vDisk의 자체 캐시 복사본을 보유할 수 있다.

덮어쓰기의 경우 VM의 자체 블록 맵에서 새로운 익스텐트로 리다이렉트된다. 이렇게 하면 캐시 손상이 없다.

익스텐트 캐시 (Extent Cache)
  • 주요 역할: 인메모리 읽기 캐시 (In-memory read cache)
  • 설명: 익스텐트 캐시는 완전히 CVM 메모리에 있는 인메모리 읽기 캐시이다. 중복제거 및 지문이 비활성화된 컨테이너의 지문을 갖지 않는 익스텐트를 저장한다. AOS 3.5부터 유니파이드 캐시로부터 분리되었으나 AOS 4.5에서 유니파이드 캐시로 통합되었다.

메타데이터 확장성

동영상 시청을 원하시면 다음 링크를 클릭하세요: LINK


메타데이터는 모든 인텔리전트 시스템의 핵심이며 모든 파일시스템 또는 스토리지 어레이에 훨씬 더 중요하다. '메타데이터(Metadata)'라는 용어에 대해 확신이 없는 사람들을 위해; 기본적으로 메타데이터는 '데이터에 대한 데이터'이다. DSF와 관련하여 성공에 중요한 몇 가지 주요 원칙이 있다.

  • 시간이 100% 정확해야 한다 (“엄격한 일관성”으로 알려짐).
  • ACID를 준수해야 한다.
  • 무제한으로 확장할 수 있어야 한다.
  • 규모에 관계없이 병목현상이 없어야 한다 (선형적인 확장성을 제공해야 한다).

AOS 5.10부터 메타데이터는 글로벌 메타데이터와 로컬 메타데이터(이전에는 모든 메타데이터가 글로벌 메타데이터 이었음)로 구분된다. 이에 대한 동기는 "메타데이터 로컬리티"를 최적화하고 메타데이터 조회를 위해 시스템의 네트워크 트래픽을 제한하는 것이다.

이러한 변경의 근거는 모든 데이터가 글로벌일 필요는 없다는 것이다. 예를 들어 모든 CVM이 특정 익스텐트가 어느 물리 디스크에 있는지 알 필요가 없으며, 어떤 노드가 그 데이터를 보유하고 있는지만 알면 되고, 단지 그 노드만 데이터가 어느 디스크에 있는지를 알면 된다.

이를 통해 시스템에 저장된 메타데이터의 양을 제한하고(로컬 전용 데이터에 대해서는 메타데이터 RF 제거) "메타데이터 로컬리티"를 최적화할 수 있다.

다음 이미지는 로컬 매타데이터와 글로벌 메타데이터의 차이점을 보여준다.

Figure. 글로벌 vs. 로컬 메타데이터 (Global vs. Local Metadata)
로컬 메타데이터 (Local Metadata)
  • 설명 (Description):
    • 로컬 노드에서만 필요한 정보를 포함하는 CVM 당 로컬 메타데이터 저장소. 이것은 AOS 5.10에서 도입된 AES(Autonomous Extent Store)에 의해 활용된다.
  • 스토리지 매커니즘 (Storage Mechanism):
    • AES DB (Rocksdb 기반)
  • 저장되는 데이터 유형 (Types of data stored):
    • 물리적 익스텐트/익스텐트 그룹의 배치 (e.g. egroup to disk mapping) 등
글로벌 메타데이터 (Global Metadata)
  • 설명 (Description):
    • 모든 CVM에서 전역적으로 사용할 수 있고 클러스터의 CVM에서 분할된 메타데이터. AOS 5.10 이전의 모든 메타 데이터.
  • 스토리지 매커니즘 (Storage Mechanism):
    • 메두사 저장소 (카산드라 기반)
  • 저장되는 데이터 유형 (Types of data stored):
    • vDisk 블록 맵, 익스텐트와 노드 매핑, 시계열 통계, 설정 등

아래 섹션에서 글로벌 매타데이터의 관리 방법을 다룬다.

위의 아키텍처 섹션에서 언급했듯이 DSF는 필수적인 메타데이터뿐만 아니라 다른 플랫폼 데이터(e.g. 통계 등)를 저장하는 키-값 스토어로 "링과 같은(ring-like)" 구조를 활용한다. 글로벌 메타데이터 가용성 및 리던던시를 보장하기 위해 홀수 노드(e.g. 3, 5 등)로 구성된 복제계수(RF)를 사용한다. 글로벌 메타데이터 쓰기 또는 갱신 시에 ROW는 해당 키를 소유한 링의 노드에 기록된 다음 n개의 피어(n은 클러스터 크기에 의존)로 복제된다. 대부분의 노드는 어떤 것이 커밋되기 전에 동의해야 하며, 이는 PAXOS 알고리즘을 사용하여 수행된다. 이를 통해 플랫폼의 일부로 저장되는 모든 데이터 및 글로벌 메타데이터의 “엄격한 일관성(Strict Consistency)”를 보장한다.

다음 그림은 4노드 클러스터에 대한 글로벌 메타데이터 삽입/업데이트의 예를 보여준다.

Figure 11-7. 카산드라 링 구조 (Cassandra Ring Structure)

규모에 따른 성능 또한 DSF 글로벌 메타데이터의 또 다른 중요한 구조이다. 기존의 듀얼 컨트롤러 또는 “마스터/슬레이브” 모델과 달리 각 뉴타닉스 노드는 전체 플랫폼 메타데이터의 서브셋을 담당한다. 이를 통해 클러스터의 모든 노드에서 글로벌 메타데이터를 서비스하고 조작할 수 있으므로 기존 병목현상이 제거된다. 클러스터 크기 변경(노드 "추가/제거"라고도 함) 동안 키의 재분배를 최소화하기 위해 키 파티셔닝에 일관된 해싱 스키마를 활용한다. 클러스터가 확장될 때(e.g. 4노드에서 8노드로) “블록 인식(Block Awareness)” 및 신뢰성을 위해 노드 사이의 링 전체에 노드가 삽입된다.

다음 그림은 글로벌 메타데이터 "링"의 예와 확장 방법을 보여 준다.

Figure 11-8. 카산드라 스케일-아웃 (Cassandra Scale Out)

데이터 보호

동영상 시청을 원하시면 다음 링크를 클릭하세요: LINK


뉴타닉스 플랫폼은 현재 복제계수(Replication Factor: RF)로 알려진 리질리언시 팩터(Resiliency Factor)와 체크섬을 사용하여 노드나 디스크 장애 또는 손상 시 데이터 리던던시와 가용성을 보장한다. 위에서 설명한 바와 같이 OpLog는 들어오는 쓰기를 레이턴시가 짧은 SSD 티어에 흡수하기 위한 스테이징 영역의 역할을 한다. 로컬 OpLog에 쓰면 데이터는 호스트에 상공적인 쓰기로 승인(ACK) 되기 전에 다른 하나 또는 두 개의 뉴타닉스 CVM의 OpLog(RF에 의존)에 동기적으로 복제된다. 이를 통해 데이터가 적어도 두 개 또는 세 개의 독립적인 위치에 존재하므로 폴트 톨러런트를 지원한다. NOTE: RF3인 경우 메타데이터가 RF5이므로 최소 5개의 노드가 필요하다.

OpLog 피어는 모든 에피소드(1GB의 vDisk 데이터)에 대해 선택되며 모든 노드가 적극적으로 참여한다. 피어를 선택하기 위해 다양한 변수(응답 시간, 업무량, 용량 사용률 등)가 고려된다. 이렇게 하면 단편화를 제거하고 모든 CVM/OpLog의 동시에 사용할 수 있다.

데이터 RF는 프리즘에서 설정하며 컨테이너 레벨에서 수행된다. 모든 노드가 OpLog 복제에 참여하여 “핫 노드”를 제거하고 확장 시 선형적인 성능을 보장한다. 데이터를 쓰는 동안 체크섬이 계산되고 메타데이터의 일부로 저장된다. 그런 다음 데이터는 RF가 절대적으로 유지되는 익스텐트 스토어로 비동기적으로 배수된다. 노드 또는 디스크 장애의 경우 데이터는 RF를 유지하기 위해 클러스터의 모든 노드 간에 재복제된다. 데이터를 읽을 때마다 데이터가 유효한지 확인하기 위해 체크섬이 계산된다. 체크섬과 데이터가 일치하지 않으면 데이터의 복제본을 읽고 유효하지 않는 복사본을 대체한다.

액티브 I/O가 발생하지 않는 경우에도 데이터는 무결성을 보장하기 위해 지속적으로 모니터링된다. 스타게이트의 스크라버(Scrubber) 오퍼레이션은 디스크를 많이 사용하지 않을 경우 익스텐트 그룹을 지속적으로 스캔하고 체크섬 유효성 검사를 수행한다. 이것은 비트 부패(Bit Rot) 또는 손상된 섹터와 같은 것을 방지한다.

다음 그림은 이것이 논리적으로 어떻게 보이는지에 대한 예를 보여준다.

DSF Data Protection
Figure 11-8. DSF 데이터 보호 (DSF Data Protection)

가용성 도메인

동영상 시청을 원하시면 다음 링크를 클릭하세요: LINK


가용성 도메인(노드/블록/랙 인식으로 알려진)은 분산 시스템이 컴포넌트 및 데이터 배치를 결정하기 위해 준수해야 하는 핵심 구조이다. 뉴타닉스에서 "블록(Block)"은 한 개, 두 개 또는 네 개의 서버 "노드(Node)"를 포함하는 섀시를 의미하고, "랙(Rack)"은 한 개 이상의 "블록"을 포함하는 물리적 유닛이다. NOTE: 블록 인식(Block Awareness)을 활성화하려면 최소 3개 이상의 블록을 사용하어야 하고, 그렇지 않으면 기본적으로 노드 인식(Node Awareness)이 설정된다.

뉴타닉스는 현재 다음 레벨 또는 인식 기능을 지원한다.

  • 디스크 (항상)
  • 노드 (항상)
  • 블록 (AOS 4.5 기준)
  • 랙 (AOS 5.9 기준)

인식 기능을 활성화하고 불균형이 발생하지 않도록 하기 위해서는 동일 사양의 블록/랙을 사용하는 것이 좋다. 일반적인 시나리오와 활용되는 인식 레벨은 본 세션의 맨 아래에서 설명한다. 3블록 요구 사항은 쿼럼을 보장하기 위한 것이다. 예를 들어 3450은 4개의 노드를 갖는 블록이다. 블록에 역할 또는 데이터를 분산하는 이유는 블록 장애가 발생하거나 유지보수가 필요한 경우 시스템이 중단 없는 계속 실행될 수 있도록 하기 위한 것이다. NOTE: 블록 내에서 리던던트 PSU와 팬이 유일한 공유 컴포넌트이다.

NOTE: 랙 인식 기능을 사용하려면 관리자가 블록을 배치할 "랙"을 정의해야 한다.

다음은 이것이 프리즘에서 어떻게 설정되는지 보여준다.

Rack Configuration
Figure. 랙 설정 (Rack Configuratioon)

인식 기능은 몇 가지 주요 중점 영역으로 나눌 수 있다.

  • 데이터 (VM 데이터)
  • 메타데이터 (카산드라)
  • 설정 데이터 (주키퍼)
데이터 (VM 데이터)

DSF를 사용하면 데이터 복제본이 클러스터의 다른 [블록/랙]에 저장되어 [블록/랙] 장애 또는 계획된 다운타임의 경우에도 데이터를 계속 사용할 수 있다. 이는 [블록/랙] 장애의 경우뿐만 아니라 RF2 및 RF3 시나리오 모두에 적용된다. 쉽게 비교할 수 있는 “노드 인식 기능”은 복제본을 다른 노드로 복제하여 노드 장애 시 데이터 보호 기능을 제공한다. 블록 및 랙 인식 기능은 노드 인식 기능을 향상하여 [블록/랙] 중단 시에 데이터 가용성을 보장한다.

다음 그림은 3블록 배포에서 복제본 배치가 동작하는 방식을 보여준다.

Block/Rack Aware Replica Placement
Figure 11-25. 블록/랙 인식 기반 복제본 배치 (Block/Rack Aware Replica Placement)

[블록/랙] 장애의 경우 [블록/랙] 인식 기능이 유지되고(가능한 경우에) 데이터는 클러스터 내의 다른 [블록/랙]에 복제된다.

Block/Rack Failure Replica Placement
Figure 11-26. 블록/랙 장애 시의 복제본 배치 (Block/Rack Failure Replica Placement)
인식 기능의 조건 및 장애 허용 범위

일반적인 시나리오 및 톨러런스 레벨(Level of Tolerance)은 다음과 같다.

원하는 인식 유형 (Desired Awareness Type) FT 레벨 (FT Level) EC 활성화 여부 (EC Enabled?) 최소 유닛 (Min. Units) 동시 장애 허용 (Simultaneous failure tolerance)
Node 1 No 3 Nodes 1 Node
Node 1 Yes 4 Nodes 1 Node
Node 2 No 5 Nodes 2 Node
Node 2 Yes 6 Nodes 2 Nodes
Block 1 No 3 Blocks 1 Block
Block 1 Yes 4 Blocks 1 Block
Block 2 No 5 Blocks 2 Blocks
Block 2 Yes 6 Blocks 2 Blocks
Rack 1 No 3 Racks 1 Rack
Rack 1 Yes 4 Racks 1 Rack
Rack 2 No 5 Racks 2 Racks
Rack 2 Yes 6 Racks 2 Racks

AOS 4.5 이상의 버전에서 블록 인식 기능은 최선의 방식(Best Effort)으로 동작하므로 활성화를 위한 엄격한 요구사항을 가지지 않는다. 이것은 균일하지 않은 스토리지 용량(e.g. 스토리지 중심의 노드)을 갖는 클러스터가 블록 인식 기능을 비활성화하지 않도록 하기 위한 것이다. 상기에서 언급한 것과 같이, 최선의 방법(Best Practices)은 스토리지 용량의 불균형을 최소화하기 위해 동일 사양의 블록으로 구성하는 것이다.

AOS 4.5 이전의 버전에서는 다음과 같은 조건을 만족하여야 한다.

  • 만약 블록간의 SSD 또는 HDD 티어의 분산 (Variance) 값 > 최대 분산 값: 노드 인식 기능
  • 만약 블록간의 SSD 또는 HDD 티어의 분산 (Variance) 값 < 최대 분산 값: 블록 + 노드 인식 기능

최대 티어 분산은 100 / (RF + 1)로 계산한다.

  • RF2인 경우에는 33%, RF3인 경우에는 25%
메타데이터 (카산드라)

메타데이터 확장성(Scalable Metadata) 섹션에서 설명한 것과 같이, 뉴타닉스는 메타데이터 및 다른 필수적인 정보를 저장하기 위하여 대폭 수정된 카산드라(Cassandra) 플랫폼을 사용한다. 카산드라는 “링과 유사(Ring-like)”한 구조를 사용하고, 데이터 일관성 및 가용성을 보장하기 위하여 링에서 n개의 피어에 메타데이터를 복제한다.

다음 그림은 12개의 노드를 갖는 클러스터에서 카산드라 링 구조이다.

12 Node Cassandra Ring
Figure 11-27. 노드 카산드라 링 (Node Cassandra Ring)

카산드라 피어 복제는 링에서 시계 방향으로 n개의 노드에 반복된다. [블록/랙] 인식 기능이 활성화되면, 피어를 [블록/랙]에 분산시킴으로써, 2개의 피어가 동일 [블록/랙]에 위치하지 않도록 보장한다.

상기의 링 구조에서 [블록/랙] 인식 기능을 활성화한 후의 노드 배치는 다음과 같다.

Cassandra Node Block/Rack Aware Placement
Figure 11-28. 블록/랙 인식 기능을 반영한 카산드라 노드 배치 (Cassandra Node Block/Rack Aware Placement)

[블록/랙] 인식 기능의 특징에 기반하여, [블록/랙] 장애 시에도 최소한 2벌의 데이터가 존재한다 (메타데이터 RF3인 경우 – 대규모의 클러스터에서는 RF5를 사용할 수 있다).

링 구성을 위한 전체 노드 복제 토폴로지는 다음 그림과 같다.

Full Cassandra Node Block/Rack Aware Placement
Figure 11-29. 블록/랙 인식 기능을 반영한 전체 카산드라 노드 배치 (Full Cassandra Node Block/Rack Aware Placement)
Note
메타데이터 인식 조건 (Metadata Awareness Conditions)

아래에서 몇 가지 일반적인 시나리오 및 어떤 레벨의 인식 기능(Awareness)이 활용되는지 알아본다.

  • FT1 (Data RF2 / Metadata RF3) will be block aware if:
    • >= 3 blocks
    • Let X be the number of nodes in the block with max nodes. Then, the remaining blocks should have at least 2X nodes.
      • Example: 4 blocks with 2,3,4,2 nodes per block respectively.
        • The max node block has 4 nodes which means the other 3 blocks should have 2x4 (8) nodes. In this case it WOULD NOT be block aware as the remaining blocks only have 7 nodes.
      • Example: 4 blocks with 3,3,4,3 nodes per block respectively.
        • The max node block has 4 nodes which means the other 3 blocks should have 2x4==8 nodes. In this case it WOULD be block aware as the remaining blocks have 9 nodes which is above our minimum.
  • FT2 (Data RF3 / Metadata RF5) will be block aware if:
    • >= 5 blocks
    • Let X be the number of nodes in the block with max nodes. Then, the remaining blocks should have at least 4X nodes.
      • Example: 6 blocks with 2,3,4,2,3,3 nodes per block respectively.
        • The max node block has 4 nodes which means the other 3 blocks should have 4x4==16 nodes. In this case it WOULD NOT be block aware as the remaining blocks only have 13 nodes.
      • Example: 6 blocks with 2,4,4,4,4,4 nodes per block respectively.
        • The max node block has 4 nodes which means the other 3 blocks should have 4x4==16 nodes. In this case it WOULD be block aware as the remaining blocks have 18 nodes which is above our minimum.
클러스터 설정 데이터 (주키퍼)

뉴타닉스는 클러스터 설정 정보를 관리하기 위해 주키퍼(Zookeeper)를 사용한다. 주키퍼 역할은 [블록/랙] 장애 시에 클러스터 설정 정보의 가용성을 보장하기 위해 [블록/랙] 인식 기능에 기반하여 분산된다.

3개의 주키퍼 노드가 [블록/랙] 인식 기능에 기반하여 분산된 그림은 다음과 같다.

Zookeeper Block/Rack Aware Placement
Figure 11-30. 블록/랙 인식 기능을 적용한 주키퍼 노드의 분산 (Zookeeper Block/Rack Aware Placement)

[블록/랙] 장애가 발생했다는 것은 주키퍼 노드들 중의 하나에 장애가 발생했다는 것을 의미하는데, 다음 그림에서 보는 것과 같이, 주키퍼 역할이 클러스터의 다른 노드로 이동되어야 한다.

Zookeeper Placement Block/Rack Failure
Figure 11-31. 블록/랙 장애 시에 주키퍼 배치 (Zookeeper Placement Block/Rack Failure)

[블록/랙]이 정상 상태로 복귀되면, [블록/랙] 인식 기능을 유지하기 위하여 주키퍼 역할이 원래 노드로 복원된다.

NOTE: AOS 4.5 이전 버전에서, 상기의 마이그레이션이 자동화되지 않기 때문에, 수작업으로 처리하여야 한다.

데이터 패스 리질리언시

DSF 또는 기본 스토리지 플랫폼에서 가장 중요한 개념은 아닐지라도, 신뢰성과 리질리언시(Reliability and Resiliency)는 핵심 개념이다.

하드웨어가 안정적이라는 가정하에서 구축된 전통적인 아키텍처와 달리, 뉴타닉스는 다른 접근 방법, 즉 모든 하드웨어는 궁극적으로 장애가 발생할 수 있다고 가정한다. 이러한 가정하에, 시스템은 클러스터 서비스에 영향을 주지 않도록 모든 가능한 장애 상황을 매우 정교하고 효율적인 방법으로 처리할 수 있도록 설계되었다.

NOTE: 이것은 하드웨어 품질이 좋지 않다는 것을 의미하는 것이 아니고, 단지 새로운 발상의 전환이다. 뉴타닉스 하드웨어 및 QA 팀은 매우 철저한 품질 관리 프로세스를 수행한다.

이전의 섹션에서 언급한 바와 같이, 메타데이터 및 데이터는 클러스터의 FT 레벨에 기반한 RF를 사용하여 보호된다. AOS 5.0 버전에서 지원되는 FT 레벨은 FT1과 FT2인데, 이것은 각각 메타데이터 RF3 및 데이터 RF2, 또는 메타데이터 RF5 및 데이터 RF3와 대응된다.

메타데이터가 어떤 방식으로 공유되는지는 “메타데이터 확장성(Scalable Metadata)” 섹션을 참조한다. 데이터가 어떤 방식으로 공유되는지는 “데이터 보호(Data Protection)” 섹션을 참조한다.

정상 상태에서, 클러스터 데이터 레이아웃은 다음에서 보는 것과 같다.

Data Path Resiliency - Normal State
Figure. 데이터 패스 리질리언시 – 정상 상태 (Data Path Resiliency - Normal State)

상기 그림에서 보는 것과 같이, VM / vDisk 데이터는 2개 또는 3개의 복제본을 가지며 노드 및 관련된 스토리지 디바이스의 디스크에 분산된다.

Note
데이터 분산의 중요성 (Importance of Data Distribution)

메타데이터 및 데이터가 모든 노드 및 모든 디스크 디바이스에 분산된다는 것은 정상 데이터의 입력 및 데이터 재보호(Re-Protection) 동안에 가능한 한 최고의 성능을 보장한다는 것을 의미한다.

데이터를 시스템에 쓸 때, 원본 데이터 및 복제본 데이터는 로컬 노드 및 다른 원격 노드에 분산된다. 이런 과정을 통하여 특정 노드에 데이터가 집중(e.g. 노드 또는 디스크 성능이 떨어짐)되는 것을 제거하고 일관적인 쓰기 성능을 보장한다.

데이터를 재보호(Re-Protected)하여야 할 디스크 또는 노드의 장애 시에, 클러스터의 모든 자원을 데이터 재구축 작업에 사용할 수 있다. 디스크 또는 노드 장애 시에, 메타데이터 스캔 작업(장애가 발생한 디바이스에 무슨 데이터가 저장되었었는지 및 복제본 데이터는 어느 위치에 존재하는지 검색)은 모든 CVM에 균일하게 분산된다. 정상 동작중인 모든 CVM에서 데이터 복제본의 검색 작업이 완료되면, 디스크 디바이스(SSD + HDD) 및 호스트 네트워크 업링크를 사용하여 동시에 데이터 재구축 작업이 진행된다.

예를 들어, 4개의 노드로 구성된 클러스터에서 1개의 디스크에 장애가 발생하면, 각 CVM은 전체 메타데이터 스캔 및 데이터 재구축 작업량의 25%만을 수행하면 된다. 10개의 노드로 구성된 클러스터에서 각 CVM은 메타데이터 스캔 및 데이터 재구축 작업의 10%만을 수행하면 된다. 50개의 노드로 구성된 클러스터에서 각 CVM은 메타데이터 스캔 및 데이터 재구축 작업의 2%만을 수행하면 된다.

Key Point: 데이터를 균일하게 분산함으로써, 뉴타닉스는 일관적인 쓰기 성능을 보장하고 데이터 재구축 작업의 시간을 현저하게 단축시킨다. 본 기능은 클러스터 레벨의 기능에도 동일하게 적용된다(e.g. Erasure Coding, 데이터 압축, 데이터 중복제거 등).

HA Pairs를 사용하거나 또는 1개의 디스크가 모든 데이터 복제본을 갖는 다른 솔루션과 비교할 때, 만약 미러링된 노드/디스크가 사용중인(IO 과부하 또는 자원 제약) 경우에, 데이터 서비스 성능 이슈에 직면할 수 있다.

또한, 데이터가 재보호되어야만 하는 환경에서 장애가 발생한 경우에, 데이터 서비스가 1개의 스토리지 컨트롤러, 1개의 노드 디스크 자원 또는 1개 노드의 네트워크 업링크로 제한될 수 있다. 특히, 테라 바이트 레벨의 데이터가 재보호 되어야 하는 경우에 데이터 서비스가 로컬 노드의 디스크 및 네트워크 대역폭으로 심각하게 제한될 수 있기 때문에, 만약 추가적인 장애가 발생한 경우에 잠재적인 데이터 손실에 대한 가능성을 현저하게 증가시킨다.

잠재적인 장애 레벨

분산 시스템을 구현하기 위해, DSF는 컴포넌트, 서비스, 컨트롤러 VM의 장애 시에, 이를 처리하기 위한 기능이 구현되어 있으며, 다음과 같은 카테고리로 분류할 수 있다.

  • 디스크 장애 (Disk Failure)
  • CVM 장애 (CVM Failure)
  • 노드 장애 (Node Failure)

Note
리빌드 작업은 언제 시작하는가? (When does a rebuild begin?)

계획되지 않은 장애가 발생한 경우에(정상적으로 동작하지 않는 경우에 사전에 오프라인 상태로 전환하는 경우가 있음) 리빌드 프로세스는 즉시 시작된다.

리빌딩 작업을 시작하기 위해 60분을 기다리고 리빌드 작업 동안에 단지 1개의 복사본을 유지(매우 위험하며 어떠한 종류의 장애가 발생하면 데이터 손실이 발생할 수 있음)하는 다른 벤더와 달리, 뉴타닉스는 잠재적으로 더 높은 스토리지 활용도를 희생하면서 이러한 위험을 감수하고자 하지 않는다.

장애가 발생한 경우에 뉴타닉스는 다음과 같은 이유로 리빌드 작업을 즉시 시작한다. a) 메타 데이터의 세밀성 b) RF 쓰기를 위해 동적으로 피어 선택(장애 발생 시에도 모든 새로운 데이터(e.g. 새로운 쓰기 / 덮어 쓰기)는 설정된 RF를 유지) c) 뉴타닉스는 리빌드 동안에 온라인 상태로 복귀한 작업을 처리할 수 있으며, 유효성이 검증된 데이터는 다시 승인(Re-Admit) 할 수 있다. 이러한 시나리오에서 데이터가 "과복제(Over-Replicated)" 될 수 있는데, 큐레이터는 스캔 후에 "과복제(Over-Repliacted)"된 복제본을 삭제한다.

디스크 장애 (Disk Failure)

디스크 장애(Disk Failure)는 디스크의 물리적 장애로 디스크를 제거한 경우와, 디스크 I/O 에러가 발생하여 디스크가 응답하지 않는 경우로 특징지을 수 있다. 스타게이트가 I/O 에러를 감지하거나 디바이스가 지정된 임계 값 이내에 응답을 하지 않아서 장애가 발생한 경우에, 스타게이트는 해당 디스크를 오프라인으로 마크한다. 이러한 상황이 발생하면, 하데스(Hades)는 S.M.A.R.T를 실행하고 디바이스 상태를 체크한다. 스타게이트가 디스크를 여러 번 오프라인으로 마크하면(1시간 동안에 3번), 하데스는 S.M.A.R.T 테스트가 정상적일지라도 디스크를 온라인으로 마킹하는 작업을 중단한다.

VM에 미치는 영향은 다음과 같다.

  • HA 이벤트 (HA event): 없음 (No)
  • I/O 실패 (Failed I/Os): 없음 (No)
  • 레이턴시 (Latency): 영향 없음 (No Impact)

디스크 장애 이벤트가 발생하면, 맵리듀스 프레임워크인 큐레이터 스캔 작업이 즉시 일어난다. 큐레이터는 메타데이터(카산드라)를 스캔하여 장애가 발생한 디스크에 저장되어 있는 데이터와 복제본을 저장하고 있는 노드/디스크를 찾는다.

큐레이터는 재복제 대상이 되는 데이터를 찾은 후에, 데이터 재복제 작업을 클러스터의 노드에 분산시킨다.

이러한 프로세스 동안에, 불량 디스크를 대상으로 드라이브 셀프 테스트(Drive Self Test)가 시작되고, 에러의 원인을 찾기 위해 SMART 로그가 모니터링 된다.

다음 그림은 디스크 장애 및 재보호의 예이다.

Data Path Resiliency - Disk Failure
Figure. 데이터 패스 리질리언시 – 디스크 장애 (Data Path Resiliency - Disk Failure)

여기서 주목하여야 할 포인트는 뉴타닉스가 어떤 방식으로 데이터 및 복제본을 모든 노드/CVM/디스크에 분산시키는가 하는 것인데, 뉴타닉스 플랫폼에서는 모든 노드/CVM/디스크가 재복제 작업에 참여한다.

이것은 전체 클러스터의 모든 자원을 활용하기 때문에, 데이터 재보호을 위해 필요한 시간을 원천적으로 줄여준다. 즉, 클러스터 사이즈가 클수록 재복제 작업이 빨라진다.

노드 장애 (Node Failure)

VM에 미치는 영향은 다음과 같다.

  • HA 이벤트 (HA event): 발생 (Yes)
  • I/O 실패 (Failed I/Os): 없음 (No)
  • 레이턴시 (Latency): 영향 없음 (No Impact)

노드 장애(Node Failure) 이벤트가 발생하면, VM HA 이벤트가 발생하여 VM을 가상화된 클러스터의 다른 노드에서 재기동 시킨다. 일단 VM이 재기동 되면, VM은 원래대로 I/O를 수행하며, I/O는 로컬 CVM에 의해 처리된다.

상기에서 설명한 디스크 장애 상황과 유사하게, 큐레이터가 메타데이터 스캔을 통해 이전에 장애가 발생한 노드에 저장되었던 데이터 및 복제본을 검색한다. 일단 복제본 데이터의 검색 작업이 완료되면, 모든 노드가 재보호 작업에 참여한다.

Data Path Resiliency - Node Failure
Figure. 데이터 패스 리질리언시 – 노드 장애 (Data Path Resiliency - Node Failure)

노드가 일정 시간 동안 다운된 상태로 유지되면, 해당 노드의 CVM은 메타데이터 링에서 제거된다. 노드가 복구되고 일정 시간 이상 안정된 상태로 유지되면, 해당 노드는 다시 링 구조로 조인된다.

Note
Pro tip

데이터 리질리언시 상태는 프리즘의 대시보드 페이지에서 확인할 수 있다.

물론 CLI 명령어로 데이터 리질리언시 상태를 확인할 수 있다.

# 노드 상태 (Node status)
ncli cluster get-domain-fault-tolerance-status type=node

# 블록 상태 (Block status)
ncli cluster get-domain-fault-tolerance-status type=rackable_unit

상기 정보는 항상 최신 정보이어야 하지만, 큐레이터 파셜 스캔을 통해 데이터를 갱신할 수 있다.

CVM 장애 (CVM Failure)

CVM 장애(CVM Failure)는 CVM 전원 동작으로 CVM이 일시적으로 가용하지 않은 상태로 특징지을 수 있다. 시스템은 이러한 상황을 매우 효율적인 방법으로 처리하도록 설계되었다. CVM 장애가 발생하면, I/O는 클러스터의 다른 CVM으로 리다이렉트 된다. 구체적인 메커니즘은 하이퍼바이저에 따라 다르다.

롤링 업그레이드 프로세스는 실제적으로 이러한 기능을 이용한다. 롤링 업그레이드는 한번에 1개의 CVM을 업그레이드하고, 클러스터에서 모든 CVM의 업그레이드 작업이 끝날 때까지 이러한 작업을 반복한다.

VM에 미치는 영향은 다음과 같다.

  • HA 이벤트 (HA Evetn): 없음 (No)
  • I/O 실패 (Failed I/Os): 없음 (No)
  • 레이턴시 (Latency): 네트워크를 통한 I/O가 증가하기 때문에 잠재적으로 높을 수 있음 (Potentially higher given I/Os over the network)

CVM 장애 이벤트가 발생하면, 장애가 발생한 CVM이 서비스 중이던 I/O는 클러스터의 다른 CVM으로 리다이렉트 된다. ESXi와 Hyper-V는 이것을 CVM 자동절체(CVM Autopathing)라고 부르는 프로세스를 통하여 처리한다. CVM 자동절체는 HA.py(like “happy")를 사용하는데, 트래픽이 전달될 라우팅 정보를 내부 주소(192.168.5.2)로부터 클러스터 내에 존재하는 다른 CVM의 외부 IP로 변경한다. 이것은 단지 I/O 서비스에 대한 책임을 갖는 CVM을 원격에 존재하게 하고, 데이터스토어는 손상되지 않은 상태로 유지할 수 있게 한다.

일단, 로컬 CVM이 복구되어 안정적인 상태가 되면, 라우트 정보가 삭제되고 로컬 CVM이 모든 새로운 I/O를 인수받아 처리한다.

AHV인 경우에는 iSCSI 다중 경로(iSCSI multi-pathing) 기능을 사용하는데, 프라이머리 경로는 로컬 CVM이고, 다른 2개의 경로는 원격으로 설정되어 있다. 프라이머리 경로에 장애가 발생하면, 2개의 경로 중에 1개가 액티브로 된다.

ESXi, Hyper-V 환경에서의 자동절체와 유사하게, 로컬 CVM이 온라인 상태로 변경되면, 프라이머리 경로가 모든 I/O 서비스를 처리한다.

용량 최적화

뉴타닉스 플랫폼은 모든 워크로드를 대상으로 가용 용량을 효율적으로 사용하기 위해 광범위한 종류의 스토리지 최적화 기술을 제공한다. 이러한 기술들은 워크로드 특성에 따라 지능적으로 적용되므로, 수작업 설정 및 세부 튜닝의 필요성을 제거한다.

뉴타닉스는 다음과 같은 최적화 기술을 사용한다.

  • Erasure Coding
  • 데이터 압축 (Compression)
  • 데이터 중복제거 (Deduplication)

다음 섹션에서 각 기술에 대해 상세히 설명한다.

워크로드의 특징에 따른 용량 최적화 기술의 적용 예는 다음 테이블과 같다.

데이터 변환 (Data Transform) 가장 적합한 애플리케이션 (Best suited Application(s)) 비고 (Comments)
Erasure Coding 대부분(Most), 뉴타닉스 파일/오브젝트(Files/Objects)에 이상적(Ideal for Nutanix Files/Objects) 전통적인 RF와 비교할 때, 적은 오버헤드로 고가용성을 제공한다. 일반적인 쓰기 또는 읽기 I/O에 영향을 주지 않는다. 디스크/노드/블록 장애 시에 데이터를 디코드 해야 하기 때문에 읽기 시에 약간의 오버헤드가 발생할 수 있다.
인라인 압축 (Inline Compression) 모두 (All) 랜덤 I/O에 영향을 주지 않으며, 스토리지 티어 사용률을 증가시킨다. 데이터 복제 및 디스크로부터의 읽기를 줄여주기 때문에 대규모 또는 순차 I/O 성능을 향상시킨다.
오프라인 압축 (Offline Compression) 없음 (None) 인라인 압축이 단지 대규모 또는 순차 쓰기에만 압축을 인라인으로 적용하므로, 랜덤 또는 작은 I/O 압축을 위해 후처리 압축을 적용해야 한다.
성능 티어 중복제거 (Performance Tier Deduplication) P2V/V2V, Hyper-V(ODX), 크로스 컨테이너 복제(Cross-Container clones) 효율적인 아크로폴리스 클론을 사용하여 생성되거나 또는 클론 되지 않은 데이터인 경우에 캐시 효율성을 증가시킨다.
용량 티어 중복제거 (Capacity Tier Deduplication) 성능 티어 중복제거와 동일(Same as perf tier dedup) 감소된 디스크 오버헤드로 상기의 이점을 얻음

Erasure Coding

뉴타닉스 플랫폼은 데이터 보호 및 가용성을 위해 RF를 사용한다. 이러한 메소드는 읽기가 1개 이상의 스토리지 로케이션에서 일어나지 않고, 장애 시에 데이터 재계산 작업이 필요하지 않기 때문에, 최고 수준의 가용성을 제공한다. 그러나, 이것은 데이터 전체의 중복을 요구하기 때문에, 스토리지 자원의 비용이 증가하는 단점이 있다.

가용성을 유지하면서 필요한 스토리지 용량을 줄이기 위해, DSF는 Erasure Coding(EC)을 사용하여 데이터를 인코드 할 수 있는 기능을 제공한다.

패리티를 계산하는 RAID(레벨 4, 5, 6 등) 개념과 유사하게, EC는 다른 노드에 있는 일련의 데이터 블록을 인코드하고 패리티를 계산한다. 호스트 또는 노드 장애 시에, 패리티를 이용하여 손실된 데이터 블록을 계산한다. DSF에서, 데이터 블록은 익스텐트 그룹이고, 각 데이터 블록은 다른 노드에 위치하여야 하고, 또한 다른 vDisk에 소속되어 있어야 한다.

스트립(Strip)에서 데이터 및 패리티 블록의 수는 허용 가능한 장애 수준에 기반하여 설정 가능하다. 설정은 일반적으로 <데이터 블록의 수> / <패리티 블록의 수>로 지정한다.

예를 들어, “RF2와 유사(RF2 like)”한 가용성(e.g. N+1)은 스트립(e.g. 3/1 or 4/1)에서 3개 또는 4개의 데이터 블록과 1개의 패리티 블록으로 구성할 수 있다. “RF3와 유사(RF3 like)”한 가용성(e.g. N+2)은 스트립(e.g. 3/2 or 4/2)에서 3개 또는 4개의 데이터 블록과 2개의 패리티 블록으로 구성할 수 있다.

Note
EC와 블록 인식 기능 (EC + Block Awareness)

AOS 5.8 버전부터 EC는 블록 인식 기능을 적용하여 데이터 및 패리티 블록을 배치할 수 있다 (AOS 5.8 이전 버전에서는 노드 레벨에서 수행).

기존 EC 컨테이너는 AOS 5.8로 업그레이드를 하더라도 즉시 블록 인식 기능에 기반하여 배치되지 않는다. 클러스터에서 사용할 수 있는 충분한 블록(strip size (k + n) + 1)이 있는 경우 이전에 노드 인식 기능에 기반한 스트립이 블록 인식 기반으로 적용된다. 새로운 EC 컨테이너는 블록 인식 기능에 기반하여 EC 스트립을 만든다.

기대 오버헤드(Expected Overhead)는 <패리티 블록의 수> / <데이터 블록의 수>로 계산할 수 있다. 예들 들어, 스트립 사이즈가 1/4인 경우에 25%의 오버헤드를 가지므로, RF2가 2배의 용량을 필요로 하는데 비해, 1.25배의 용량을 필요로 한다. 스트립 사이즈가 4/2인 경우에 50%의 오버헤드를 가지므로, RF3가 3배의 용량을 필요로 하는데 비해, 1.5배의 용량을 필요로 한다.

스트립 사이즈와 오버헤드간의 관계는 다음 표와 같다.

FT1 (RF2와 동일) FT2 (RF3와 동일)
클러스터 사이즈(노드) EC 스트립 사이즈 (데이터/패리티) EC 오버헤드(RF2의 2배와 비교) EC 스트립 사이즈 (데이터/패리티) EC 오버헤드(RF3의 3배와 비교)
4 2/1 1.5배 N/A N/A
5 3/1 1.33배 N/A N/A
6 4/1 1.25배 2/2 2배
7 4/1 1.25배 3/2 1.6배
8+ 4/1 1.25배 4/2 1.5배

Note
Pro tip

노드 장애 시에, 스트립의 재구축을 허용하기 위해, 스트립 사이즈(데이터 + 패리티) 보다 최소한 1개 이상 많은 노드로 클러스터를 구성해야 한다. 이것은 스트립이 재구축(큐레이터에 의해 백그라운드로 수행) 되는 동안에 읽기 시의 계산 오버헤드를 제거한다. 예들 들어, 스트립 사이즈가 4/1인 경우에 클러스터는 최소 6개의 노드로 구성되어야 한다. 상기의 테이블은 이와 같은 최적의 방법(Best Practices)에 기반하여 작성된 것이다.

인코딩은 후처리 작업으로 수행되며, 태스크의 분산을 위해 큐레이터 맵리듀스 프레임워크를 이용한다. EC는 후처리 프레임워크이므로, 전통적인 쓰기 I/O 경로에 영향을 주지 않는다.

RF를 사용하는 일반적인 환경은 다음과 같다.

Typical DSF RF Data Layout
Figure 11-10. 전형적인 DSF RF 데이터 레이아웃 (Typical DSF RF Data Layout)

본 시나리오에서는 RF2와 RF3 데이터가 혼합되어 있으며, 원본은 로컬에 복제본은 클러스터의 다른 노드에 분산되어 있다.

큐레이터 전체 스캔이 동작할 때, 큐레이터는 인코드 대상이 되는 익스텐트 그룹(Extent Group)을 찾는다. 인코드 대상이 되는 익스텐트 그룹은 “Write-Cold”이여야 하는데, 이것은 일정 시간 동안 쓰기 작업이 없었다는 것을 의미한다. 이것은 다음과 같은 큐레이터 Gflag : curator_erasure_code_threshold_seconds로 제어된다. 인코드 대상이 되는 데이터를 찾은 후에, 인코딩 작업은 크로노드에 의해 분산되고 조절된다.

스트립 사이즈가 4/1 및 3/2인 경우에 EC 적용은 다음과 같다.

DSF Encoded Strip - Pre-savings
Figure 11-11. DSF 인코딩 스트립 – 용량 증가 전 (DSF Encoded Strip - Pre-savings)

데이터 인코딩 작업이 성공적으로 완료되면, 즉, 스트립 및 패리티 계산이 완료되면, 복제본 익스텐트 그룹은 삭제된다.

EC가 수행된 후에 스토리지 용량이 증가한 환경은 다음과 같다.

DSF Encoded Strip - Post-savings
Figure 11-12. DSF 인코딩 스트립 – 용량 증가 후 (DSF Encoded Strip - Post-savings)
Note
Pro tip

스토리지 용량 절감을 위한 최적의 조합은 Erasure Coding과 인라인 압축을 동시에 적용하는 것이다.

데이터 압축

동영상 시청을 원하시면 다음 링크를 클릭하세요: LINK


뉴타닉스 용량 최적화 엔진(Capacity Optimization Engine)은 디스크에서 데이터의 효율성을 향상시키기 위한 데이터 변환 작업에 대한 책임을 갖는다. 데이터 압축(Compression)은 데이터 최적화를 위한 COE의 주요 기능 중의 하나이다. DSF는 고객의 니즈 및 데이터 유형에 가장 적합한 방법론을 제공해 주기 위해 인라인 압축(Inline Compression)과 오프라인 압축(Offline Compression) 기능을 제공한다. AOS 5.1 버전부터 오프라인 압축 기능이 디폴트로 활성화된다.

인라인 압축은 순차 스트림 데이터 또는 I/O 사이즈가 큰 데이터(> 64K)를 익스텐트 스토어(SSD + HDD)에 쓸 때 압축 작업을 수행한다. 인라인 압축은 OpLog를 바이패스 하는 순차 데이터 뿐만 아니라 OpLog에서 익스텐트 스토어로 데이터를 이동할 때 적용된다.

Note
OpLog 데이터 압축 (OpLog Compression)

AOS 5.0 버전에서, 4K 이상의 입력 데이터에 대해 압축 작업이 수행되는데, 압축 효율이 매우 좋다 (Gflag: vdisk_distributed_oplog_enable_compression). 이를 통해 OpLog 용량을 보다 효율적으로 활용하고 지속적인 성능을 유지할 수 있다.

OpLog에서 익스텐트 스토어로 이동할 때, 데이터는 먼저 압축을 해제하고, 32K 단위의 정렬된 데이터로 재압축 된다 (AOS 5.1 기준).

본 기능은 디폴트로 활성화되어 있으며, 관리자의 추가적인 설정은 필요하지 않다.

오프라인 압축은 처음에 데이터를 평문(압축하지 않은 상태)으로 쓰고, 이후에 클러스터 레벨에서 데이터를 압축하기 위해 큐레이터 프레임워크를 이용한다. 인라인 압축을 활성화하였으나 I/O가 랜덤 데이터인 경우에 데이터는 압축되지 않은 상태로 OpLog에 쓰여지고, 이후에 익스텐트 스토어에 쓰는 시점에 메모리 상에서 압축 작업을 수행한다.

AOS 5.0 버전에서부터 뉴타닉스는 데이터 압축을 위해 LZ4 및 LZ4HC 알고리즘을 사용한다. AOS 5.0 이전의 버전에서는 데이터 압축을 위해 Google Snappy 압축 라이브러리를 이용하였는데, 이것은 계산 오버헤드를 최소화하면서도 좋은 압축률을 제공하고 압축 및 해제 작업을 매우 빠른 시간에 수행한다는 장점을 갖는다.

일반 데이터의 압축을 위해 압축 및 성능이 매우 뛰어난 LZ4 알고리즘을 사용한다. 콜드 데이터의 압축을 위해서는 압축률이 개선된 LZ4HC 알고리즘을 사용한다.

콜드 데이터는 다음과 같은 2가지 카테고리로 특징지을 수 있다.

  • 일반 데이터(Regular data): 3일 동안 RW가 없는 데이터 (Gflag: curator_medium_compress_mutable_data_delay_secs)
  • 변경할 수 없는 데이터 - 스냅샷(Immutable data - snapshots): 1일 동안 RW가 없는 데이터 (Gflag: curator_medium_compress_immutable_data_delay_secs)

인라인 압축과 DSF 쓰기 I/O 경로와의 관계는 다음 그림과 같다.

Inline Compression I/O Path
Figure 11-13. 인라인 압축 I/O 경로 (Inline Compression I/O Path)
Note
Pro tip

대용량/순차 쓰기만 압축하고 랜덤 쓰기 성능에는 영향을 미치지 않으므로 거의 항상 인라인 압축(compression delay=0)을 사용한다.

인라인 압축은 SSD 티어의 가용 용량을 증가시키기 때문에 성능을 증가시키고 보다 많은 데이터를 SSD 티어에 저장할 수 있다. 또한, 순차 또는 용량이 큰 데이터는 인라인으로 압축되어 저장되기 때문에 RF를 위한 복제 데이터도 압축되어 저장된다. 압축된 데이터는 네트워크 트래픽을 감소시키기 때문에 성능이 증가한다는 장점도 있다.

인라인 압축과의 최적의 조합은 Erasure Coding을 동시에 적용하는 것이다.

오프라인 압축인 경우에 모든 새로운 쓰기 I/O는 압축되지 않은 상태로 일반적인 DSF I/O 경로를 따른다. 압축 지연(설정 가능한 정보) 조건이 충족되면, 해당 데이터는 압축 대상 데이터가 된다. 압축은 익스텐트 스토어의 모든 영역에서 수행된다. 오프라인 압축은 큐레이터 맵리듀스 프레임워크를 이용하기 때문에 모든 노드가 압축 작업을 수행한다. 압축 태스크는 크로노스에 의해 제어된다.

오프라인 압축과 DSF 쓰기 I/O 경로와의 관계는 다음 그림과 같다.

Offline Compression I/O Path
Figure 11-14. 오프라인 압축 I/O 경로 (Offline Compression I/O Path)

읽기 I/O인 경우에, 데이터는 먼저 메모리에서 압축을 해제한 후에, I/O 서비스가 제공된다.

프리즘의 “Storage > Dashboard” 페이지에서 현재 압축률을 확인할 수 있다.

데이터 중복제거 엔진

동영상 시청을 원하시면 다음 링크를 클릭하세요: LINK


데이터 중복제거 엔진(Data Deduplication Engine)은 DSF의 소프트웨어 기반 기능으로 성능 티어(유니파이드 캐시) 및 용량 티어(익스텐트 스토어)에서 데이터의 중복제거 기능을 수행한다. 데이터 스트림의 입수 시점에 8K 단위로 SHA-1 해시 알고리즘을 이용하여 지문(Fingerprint)을 생성한다 (stargate_dedup_fingerprint에 의해 제어됨). 지문은 데이터의 입수 시점에만 생성되고, 저장된 블록의 메타데이터의 일부로 영구히 저장된다. 중복 제거된 데이터는 4K 단위로 유니파이드 캐시에 캐싱된다.

데이터 다시 읽기(Re-read)를 요구하는 백그라운드 스캔을 사용하는 전통적인 접근방법과 달리, 뉴타닉스는 데이터의 입수 시점에 지문을 생성하는 인라인 지문 생성 기능을 수행한다. 용량 티어에서 중복제거 되어야 할 중복 데이터인 경우에, 데이터를 스캔 또는 다시 읽기 할 필요 없이, 중복된 데이터를 삭제할 수 있다.

메타데이터 오버헤드를 좀 더 효율적으로 관리하기 위해, 데이터 중복제거 상황을 추적할 수 있는 지문 참조 카운트(Fingerprint Refcount)를 모니터링 한다. 낮은 지문 참조 카운트 값을 갖는 지문은 메타데이터 오버헤드를 최소화하기 위해 폐기된다. 단편화(Fragmentation)의 최소화를 위해 용량 티어 데이터 중복제거는 전체 익스텐트(Full Extent)를 대상으로 수행된다.

Note
Pro tip

유니파이드 캐시(Unified Cache)의 장점을 충분히 활용하기 위해 베이스 이미지에 성능 티어 데이터 중복제거 기능을 사용한다 (vdisk_manipulator 명령어를 이용하여 수작업으로 설정).

P2V/V2V, ODX를 사용하는 Hyper-V 환경(ODX는 전체 데이터의 복제 작업 수행), 또는 컨테이너간의 클론 작업을 수행하는 경우(뉴타닉스는 단일 컨테이너 사용을 권고하기 때문에 일반적으로 권고되지 않는 환경)에 용량 티어 데이터 중복제거 기능을 사용한다.

상기와 같은 환경 이외에서는, 압축이 더 많은 용량 절감 효과가 있기 때문에, 데이터 중복제거 기능 대신에 데이터 압축 기능을 사용한다.

데이터 중복제거 엔진의 확장성 및 로컬 VM의 I/O 요청에 대한 처리 과정은 다음 그림과 같다.

Elastic Dedupe Engine - Scale
Figure 11-16. 데이터 중복제거 엔진 – 확장 (Elastic Dedupe Engine - Scale)

지문은 I/O 사이즈가 64K 이상인 데이터(초기 I/O 또는 OpLog로부터 이동되는 데이터)에 대해 데이터의 입수 시점에 생성된다. 지문 생성을 위해 SHA-1 알고리즘을 사용하는데, CPU 오버헤드를 최소화할 수 있도록 인텔의 가속 기능을 사용한다. 데이터의 입수 시점에 지문이 생성되지 않는 데이터(예를 들어, 사이즈가 64K 이하인 데이터)인 경우에, 지문 생성은 백그라운드 프로세스에 의해 수행된다. 데이터 중복제거 엔진은 용량 티어(익스텐트 스토어)와 성능 티어(유니파이드 캐시)에서 수행된다. 여러 개의 데이터가 동일 지문을 갖는, 즉 중복 데이터가 검출되면, DSF 맵리듀스 프레임워크인 큐레이터가 백그라운드 프로세스를 통해 중복된 데이터를 삭제한다. 읽혀져야할 데이터는 멀티-티어/풀 캐시인 DSF 유니파이드 캐시로 캐싱된다. 동일 지문을 갖는 데이터에 대한 연속된 읽기 요청은 캐시에서 바로 서비스 된다. 유니파이드 캐시 및 풀 구조에 대해서는 I/O 경로 개요의 서브 섹션인 “유니파이드 캐시(Unified Cache)”를 참조한다.

Note
지문화된 vDisk 오프셋 (Fingerprinted vDisk Offsets)

AOS 4.6.1 버전부터 제한이 없기 때문에 전체 vDisk를 대상으로 지문 생성 및 데이터 중복제거 작업을 수행할 수 있다.

AOS 4.6.1 이전 버전에서 높은 메타데이터 효율성으로 인해 제한이 24GB로 증가했다. AOS 4.5 이전 버전에서는 vDisk의 처음 12GB만 지문을 사용할 수 있었다. 이는 OS가 일반적으로 가장 보편적인 데이터이기 때문에, 보다 작은 메타데이터 공간을 유지하기 위해 수행되었다.

데이터 중복제거 엔진과 DSF I/O 경로간의 관계는 다음 그림과 같다.

EDE I/O Path
Figure 11-17. EDE I/O 경로 (EDE I/O Path)

프리즘(Prism)의 “Storage > Dashboard” 메뉴에서 데이터 중복제거 현황을 확인할 수 있다.

Note
데이터 중복제거 + 데이터 압축

AOS 4.5 버전부터 동일 컨테이너에서 데이터 중복제거 기능과 데이터 압축 기능을 동시에 적용할 수 있다. 그러나, 데이터가 중복되지 않은 경우(섹션의 앞부분에서 설명한 조건)에도 압축은 적용된다.

스토리지 티어링 및 우선순위

디스크 밸런싱(Disk Balancing) 섹션에서 뉴타닉스 클러스터에서 모든 노드들간의 스토리지 용량이 어떤 방식으로 풀(Pooled) 되는지, 그리고 ILM이 핫 데이터(Hot Data)를 어떤 방식으로 로컬에 유지하는지를 설명한다. 디스크 티어링(Disk Tiering)을 위해 유사한 개념을 적용하는데, 클러스터 SSD 티어 및 클러스터 HDD 티어는 클러스터 레벨로 동작하고, DSF ILM이 데이터 이동 이벤트의 트리거에 대한 책임을 갖는다. 로컬 노드의 SSD 티어는 노드에서 실행 중인 VM에 의해 요청된 모든 I/O에 대한 최고의 우선순위를 갖지만, 클러스터 SSD의 모든 자원은 클러스터의 모든 노드에서 사용할 수 있다. SSD 티어는 항상 최고의 성능을 제공하며, 하이브리드 어레이를 관리하는데 있어서 매우 중요하다.

티어(Tier)간의 우선순위는 다음 그림과 같다.

DSF Tier Prioritization
Figure 11-18. DSF 티어 우선순위 (DSF Tier Prioritization)

다양한 종류의 자원(예를 들어, SSD, HDD 등)들이 함께 풀(Pooled Together)로 구성되고, 클러스터 레벨의 스토리지 티어를 형성한다. 이것은 클러스터의 모든 노드가, 그것이 로컬이든 원격이든 간에, 전체 티어 용량을 사용할 수 있다는 것을 의미한다.

클러스터 레벨의 티어링 구조는 다음 그림과 같다.

DSF Cluster-wide Tiering
Figure 11-19. DSF 클러스터 레벨의 티어링 (DSF Cluster-wide Tiering)

일반적인 질문은 "로컬 노드의 SSD가 꽉차게되면(Full) 어떤 일이 발생하는가?" 이다. 디스크 밸런싱 섹션에서 언급한 바와 같이, 기본 개념은 디스크 티어에서 디바이스의 사용률을 균일하게 유지하는 것이다. 로컬 SSD의 사용률이 높은 경우에, 디스크 밸런싱 기능이 동작하여 로컬 SSD의 콜드(Cold) 데이터를 클러스터의 다른 SSD로 이동시킨다. 이것은 로컬 SSD 공간을 확보하여 로컬 노드가 쓰기를 네트워크를 경유하지 않고 로컬 SSD에서 수행하도록 한다. 여기에서의 핵심 포인트는 원격 I/O에 모든 CVM 및 SSD 자원을 사용하여 잠재적 병목현상의 원인을 제거하고, 네트워크 I/O를 수행하는데 따르는 오버헤드를 줄인다는 것이다.

DSF Cluster-wide Tier Balancing
Figure 11-20. DSF 클러스터 레벨의 티어 밸런싱 (DSF Cluster-wide Tier Balancing)

다른 케이스는 전체 티어 사용률이 지정된 임계 값 ([curator_tier_usage_ilm_threshold_percent (Default=75)])을 넘어서는 상황으로 DSF ILM이 동작하고, 큐레이터 잡(Job)의 일부로서 데이터를 SSD 티어에서 HDD 티어로 마이그레이션 한다. 이런 방식을 통해, 사용률을 상기에서 언급한 임계 값 이하로 유지하게 하고, 지정한 용량 ([curator_tier_free_up_percent_by_ilm (Default=15)]) 이상의 공간을 확보하게 한다. 마이그레이션 대상 데이터는 마지막 액세스 시간을 사용하여 선택된다. SSD 티어 사용률이 95%인 경우에, SSD 티어에서 20%의 데이터가 HDD 티어로 이동된다 (95% ->75%).

그러나, 사용률이 85%인 경우에는, curator_tier_free_up_percent_by_ilm (Default = 15%)을 사용하여 단지 15%의 데이터만 이동된다.

DSF Tier ILM
Figure 11-21. DSF 티어 ILM (DSF Tier ILM)

DSF ILM은 I/O 패턴을 항상 모니터링하고, 필요한 경우에 데이터를 마이그레이션(다운/업(Down/Up)) 할 뿐만 아니라 티어에 관계 없이 핫 데이터(Hot Data)를 로컬로 가져온다.

디스크 밸런싱

동영상 시청을 원하시면 다음 링크를 클릭하세요: LINK


DSF는 매우 동적인 플랫폼으로 설계되어, 다양한 워크로드를 지원할 뿐만 아니라 이종의 노드를 허용한다. 즉, 컴퓨트 중심의 노드(3050 등)와 스토리지 중심의 노드(60X0 등)를 하나의 클러스터에 혼합할 수 있다. 데이터를 균일하게 분산하는 것은 스토리지 용량이 큰 노드를 혼합할 때 매우 중요한 기능이다. DSF는 디스크 밸런싱(Disk Balancing)이라고 불리는 매우 기본적인 기능을 지원하는데, 이것은 클러스터에서 데이터의 균일한 분산을 보장하기 위하여 사용된다. 디스크 밸런싱은 로컬 스토리지 용량에 대한 노드 레벨의 사용률을 기반으로 동작하고, DSF ILM과 통합된다. 디스크 밸런싱의 목적은 사용률이 지정된 임계 값을 넘어선 경우에, 노드들간의 사용률을 균일하게 유지하는 것이다.

다음 그림은 노드가 혼합된(3050 + 6050) 클러스터에서, 디스크 사용률이 균일하지 않은 상태이다.

Disk Balancing - Unbalanced State
Figure 11-22. 디스크 밸런싱 - 균일하지 않은 상태 (Disk Balancing - Unbalanced State)

디스크 밸런싱은 DSF 큐레이터 프레임워크를 이용하는데, 스케줄링된 프로세스로 수행되거나, 임계 값을 넘어선 경우(예를 들어, 로컬 노드의 스토리지 사용률 > n%)에 수행된다. 데이터가 균일하게 분산되지 않은 경우에, 큐레이터는 이동하여야 할 데이터를 결정하고, 클러스터의 노드들에게 태스크를 분산한다. 모든 노드의 유형이 동일한 경우(e.g. 3050)에 사용률은 매우 균일하여야 한다. 그러나, 만약 노드에서 실행 중인 특정 VM이 다른 VM들 보다 훨씬 많은 데이터를 쓰게 되면, 노드 당 디스크 사용률이 왜곡될 수 있다. 이러한 경우에, 디스크 밸런싱 기능이 동작하여 해당 노드의 콜드 데이터를 클러스터의 다른 노드로 이동시킨다. 노드 유형이 다르거나(e.g. 3050 + 6020/50/70), 또는 스토리지 전용 모드(VM을 실행하지 않는)로 사용되는 경우에, 데이터 이동에 대한 필요성이 발생할 수 있다.

다음 그림은 혼합된 클러스터에서 디스크 밸런싱 기능이 수행된 후의 상태를 보여준다.

Disk Balancing - Balanced State
Figure 11-23. 디스크 밸런싱 – 균일한 상태 (Disk Balancing - Balanced State)

특정 시나리오에서, 고객은 일부 노드를 스토리지 전용으로 사용할 수 있다. “스토리지 전용” 노드는, 단지 CVM만이 실행되고, 해당 노드의 주요 목적은 대용량의 스토리지로 사용되는 경우이다. 이러한 경우에, 보다 많은 읽기 캐시를 제공하기 위해 노드의 전체 메모리를 CVM에 할당할 수 있다.

다음 그림은 스토리지 전용 노드가 포함된 클러스터에서 디스크 밸런싱 작업이 어떤 방식으로 수행되는지를 보여준다.

Disk Balancing - Storage Only Node
Figure 11-24. 디스크 밸런싱 – 스토리지 전용 노드 (Disk Balancing - Storage Only Node)

스냅샷 및 클론

동영상 시청을 원하시면 다음 링크를 클릭하세요: LINK


DSF는 VAAI, ODX, nCLI, REST API, 프리즘 등에 의해 사용되는 오프로드된 스냅샷 및 클론(Offloaded snapshots and clones)을 지원한다. 스냅샷 및 클론 작업을 위해 가장 효과적이고 효율적인 알고리즘으로 알려져 있는 Redirect-On-Write 알고리즘을 사용한다. 상기의 데이터 구조 섹션에서 설명한 것과 같이, VM은 파일들(vmdk/vhdx)로 구성되어 있는데, 파일은 뉴타닉스 플랫폼에서 vDisk이다.

vDisk는 논리적으로 연속된 데이터 청크(Chunk)인 익스텐트(Extents)로 구성되는데, 익스텐트는 스토리지 디바이스에서 파일로 저장되는 물리적으로 연속된 데이터인 익스텐트 그룹(Extent Group)으로 그룹핑 되어 저장된다. 스냅샷 또는 클론 작업이 요청될 때, 베이스 vDisk는 “변경불가능(Immutable)”로 표시되고, 읽기/쓰기가 가능한 다른 vDisk가 생성된다. 이 시점에서, 두 개의 vDisk는 동일한 블록 맵(Block Map)을 갖는데, 블록 맵은 해당하는 익스텐트에 대한 vDisk의 메타데이터 매핑이다. 스냅샷 체인의 검색(읽기 레이턴시가 추가됨)을 필요로 하는 전통적인 접근방법과 달리, 모든 vDisk는 자신의 블록 맵을 갖는다. 이것은 일반적으로 깊이가 깊은 스냅샷 체인의 검색에 따른 오버헤드를 제거하기 때문에, 성능에 영향을 주지 않고, 연속적으로 스냅샷을 생성할 수 있게 한다.

스냅샷 생성 요청 시의 동작은 다음 그림과 같다.

Example Snapshot Block Map
Figure 11-32. 스냅샷 블록 매의 예제 (Example Snapshot Block Map)

이전에 생성된 스냅샷 또는 클론의 vDisk를 대상으로 스냅샷 또는 클론을 생성할 때에도 동일한 메소드가 적용된다.

Multi-snap Block Map and New Write
Figure 11-33. 멀티-스냅샷의 블록 맵 및 신규 Write (Multi-snap Block Map and New Write)

VM 또는 vDisk 스냅샷 또는 클론 작업에 동일한 메소드를 사용한다. VM 또는 vDisk 클론 작업이 요청될 때, 현재 블록 맵을 락킹한 후에 클론을 생성한다. 이러한 작업은 메타데이터 수준에서만 수행되기 때문에, 실질적인 I/O는 발생하지 않는다. 클론의 클론을 생성할 경우에도 동일한 메소드가 적용된다. 이전에 클론된 VM이 “베이스 vDisk”가 되고, 클론 시에 해당 블록 맵은 락킹되고, 두 개의 클론이 생성되는데 하나는 클론될 VM을 위한 것이고 다른 하나는 새로운 클론을 위한 것이다. 클론의 최대 개수에 부과된 제한은 없다.

두 개의 클론은 모두 이전 블록 맵을 상속받고, 새로운 쓰기/갱신은 자신의 개별적인 블록 맵에서 발생한다.

Multi-Clone Block Maps
Figure 11-34. 멀티-클론 블록 맵 (Multi-Clone Block Maps)

앞에서 언급한 바와 같이, 모든 VM/vDisk는 자신의 개별적인 블록 맵을 갖는다. 그러므로, 상기의 예제에서 베이스 VM으로부터 생성된 모든 클론은 자신의 블록 맵을 가지며 모든 쓰기/갱신은 자신의 블록 맵에서 수행된다.

다음은 상기의 설명을 그림으로 표현한 것이다.

Clone Block Maps - New Write
Figure 11-35. 클론 블록 맵 - 새로운 Write (Clone Block Maps - New Write)

VM/vDisk의 모든 후속 클론 또는 스냅샷은 오리지널 블록 맵을 락킹하고 R/W 액세스를 위해 새로운 블록 맵을 생성한다.

네트워킹 및 입출력

뉴타닉스 플랫폼은 노드들간의 통신을 위해 어떤 종류의 백플레인도 사용하지 않고, 단지 표준 10GbE 네트워크에 기반한다. 뉴타닉스 노드에서 실행 중인 VM의 모든 스토리지 I/O는 전용 사설 네트워크를 사용하는 하이퍼바이저에 의해 처리된다. I/O 요청은 하이퍼바이저에 의해 처리되는데, 해당 요청은 로컬 CVM의 사설 IP로 전달된다. CVM은 퍼블릭 10GbE 네트워크의 외부 IP를 사용하여 다른 뉴타닉스 노드와 함께 원격 복제 작업을 수행한다. 모든 읽기 요청은 대부분의 경우에 로컬에서 처리되며, 10GbE 네트워크를 전혀 사용하지 않는다. 이것은 퍼블릭 10GbE 네트워크를 사용하는 트래픽은 DSF 원격 복제 트래픽과 VM 네트워크 I/O라는 것을 의미한다. 그러나, CVM이 가용하지 않거나, 또는 데이터가 원격에 존재하는 경우에 CVM이 클러스터의 다른 CVM으로 요청을 전달한다. 또한, 디스크 밸런싱과 같은 클러스터 레벨의 태스크인 경우에 10GbE 네트워크에서 일시적으로 I/O가 발생한다.

다음 그림은 VM의 I/O 경로가 사설 및 퍼블릭 10GbE 네트워크와 어떤 방식으로 통신하는 지를 보여준다.

DSF Networking
Figure 11-54. DSF 네트워킹 (DSF Networking)

 

데이터 로컬리티

컨버지드(컴퓨트 + 스토리지) 플랫폼에서, I/O 및 데이터 로컬리티(Data Locality)는 뉴타닉스에서 클러스터 및 VM 성능을 위해 매우 중요한 기능이다. 상기의 I/O 경로에서 설명한 바와 같이, 모든 읽기/쓰기 I/O는 로컬 CVM에 의해 처리된다. VM 데이터는 CVM에 의해 로컬에서 처리되고, CVM이 컨트롤하는 로컬 디스크에 저장된다. HA 이벤트 동안에 VM이 기존 하이퍼바이저 노드에서 다른 하이퍼바이저 노드로 이동될 때, 새로 마이그레이션된 VM 데이터는 이동된 로컬 CVM에 의해 서비스된다. 올드 데이터에 대한 읽기 요청(VM의 이동으로 인해 원격 노드/CVM에 저장된)은 로컬 CVM에 의해 원격 CVM으로 전달된다. 모든 쓰기 I/O는 로컬에서 즉시 처리된다. DSF는 I/O가 다른 노드에 발생한다는 것을 검출하고, 모든 읽기 I/O가 로컬에서 서비스될 수 있도록 백그라운드로 데이터를 로컬로 마이그레이션 한다. 데이터는 네트워크 사용을 최소화하기 위해 읽기 전용으로 마이그레이션 된다.

데이터 로컬리티는 다음과 같은 두 가지 경우에 발생한다.

  • 캐시 로컬리티 (Cache Locality)
    • 유니파이드 캐시(Unified Cache)에 로컬로 저장된 vDisk 데이터. vDisk 익스텐트(vDisk Extent)는 노드에 원격으로 존재할 수 있다.
  • 익스텐트 로컬리티 (Extent Locality)
    • vDisk 익스텐트(vDisk Extent)가 VM과 마찬가지로 동일 노드에 로컬로 존재하여야 한다.

다음 그림은 VM이 하이퍼바이저 노드간을 이동함에 따라 데이터가 어떤 방식으로 따라가는지를 보여준다.

Data Locality
Figure 11-55. 데이터 로컬리티 (Data Locality)
Note
데이터 마이그레이션을 위한 임계 값 (Thresholds for Data Migration)

캐시 로컬리티(Cache Locality)는 실시간으로 발생하고, vDisk 오너쉽(vDisk Ownership)을 기반으로 결정된다. vDisk/VM이 다른 노드로 이동될 때, vDisk 오너쉽이 이동된 로컬 CVM으로 변경된다. 일단 오너쉽이 변경되면, 데이터는 유니파이드 캐시에 로컬로 캐시된다. 중간 단계에서 잠시동안 오너쉽을 갖고 있는 모든 노드에 캐시가 존재할 수 있다(현재 원격 호스트). 이전에 호스팅하고 있던 스타게이트는 원격 I/O가 300초 이상 걸릴 때 vDisk 토큰을 포기하고, 로컬 스타게이트가 토큰을 가진다. vDisk 데이터를 캐시하기 위해 오너쉽이 필요하기 때문에 캐시 일관성(Cache coherence)이 유지된다.

익스텐트 로컬리티(Extent Locality)는 표본화된 오퍼레이션으로 다음과 같은 조건이 만족되면 익스텐트 그룹이 마이그레이션 된다: “10분 단위의 윈도우에서 랜덤인 경우 3 터치(Touch), 순차인 경우는 10 터치”이고, 1 터치는 매 10초 동안에 1번 이상의 읽기가 발생한 것을 의미한다".

쉐도우 클론

동영상 시청을 원하시면 다음 링크를 클릭하세요: LINK


아크로폴리스 DSF(Distributed Storage Fabric)는 “쉐도우 클론(Shadow Clones)”으로 불리는 기능을 제공하는데, 이것은 “멀티-리더(Multi-Reader)” 시나리오를 갖는 특정 vDisk 또는 VM 데이터의 분산 캐싱 기술이다. 쉐도우 클론의 가장 좋은 사례는, VDI 배포 동안에 많은 “링크드 클론(Linked Clones)”의 읽기 요청이 마스터 또는 베이스 VM으로 전달되는 경우이다. VMware View인 경우에, 이것은 복제 디스크(Replica Disk)라고 불리며 모든 링크드 클론에 의해 읽혀지고, XenDesktop인 경우에, 이것은 MCS 마스터 VM으로 불린다. 쉐도우 클론은 배포 서버, 리파지토리 등과 같이 “멀티-리더” 시나리오를 갖는 모든 시나리오에 적용된다. 데이터 또는 I/O 로컬리티는 VM의 성능 향상을 위해 매우 중요하며, DSF의 핵심 기능이다.

쉐도우 클론 기능을 위해 DSF는 데이터 로컬리티를 위해 수행했던 것과 유사하게 vDisk 액세스 트랜드를 모니터링 한다. 그러나, 요청이 2개 이상의 원격 CVM(로컬 CVM 포함)으로부터 발생하고, 모든 요청이 읽기 I/O인 경우에, vDisk는 변경불가능(Immutable)으로 표시된다. 일단, 디스크가 변경불가능으로 표시되면, vDisk에 대한 읽기 요청을 캐시에서 처리하기 위해 각 CVM에 의해 로컬에 캐시(베이스 vDisk의 쉐도우 클론) 된다. 이러한 방식으로 각 노드의 VM은 베이스 VM의 vDisk를 로컬에서 읽게된다. VDI인 경우에, 이것은 복제 디스크(Replica Disk)가 각 노드에 캐시되고, 베이스 VM에 대한 모든 읽기 요청이 로컬에서 서비스 된다는 것을 의미한다. NOTE: 데이터는 네트워크 트래픽을 줄이고 효율적인 캐시 사용률을 위해 단지 읽기 시에만 마이그레이션 된다. 베이스 VM이 변경되는 경우에는 쉐도우 클론은 삭제되고, 쉐도우 클론 프로세스가 다시 시작된다. 쉐도우 클론 기능은 디폴트로 활성화(뉴타닉스 소프트웨어 4.0.2 이상의 버전) 되어 있으며, nCLI 명령어(ncli cluster edit-params enable-shadow-clones=<true/false>)를 사용하여 활성/비활성화 할 수 있다.

쉐도우 클론의 동작은 다음 그림과 같다.

Shadow Clones
Figure 11-56. 쉐도우 클론 (Shadow Clones)

스토리지 레이어 및 모니터링

뉴타닉스 플랫폼은 멀티-레이어에서 스토리지를 모니터링 하는데, VM/게스트 OS로부터 물리 디바이스 디스크까지의 모든 범위를 포함한다. 다양한 티어 및 티어들간의 관계를 안다는 것은 솔루션을 모니터링 하고, 오퍼레이션이 어떻게 연관되어 있는지를 시각적인 정보로 표현해 줄 수 있기 때문에 매우 중요하다. 각 레이어에서 제공하는 오퍼레이션 및 모니터링 정보는 다음 그림과 같다.

Storage Layers
Figure 11-57. 스토리지 레이어 (Storage Layers)

 

가상머신 레이어 (Virtual Machine Layers)
  • 주요 역할: 하이퍼바이저에 의해 제공하는 VM 메트릭스
  • 설명: VM 또는 게스트 레벨의 메트릭스는 하이퍼바이저로부터 직접 가져오며, VM이 보는 성능과 애플리케이션이 보는 I/O 성능 정보를 제공한다.
  • 사용 시기: 장애처리 또는 VM 레벨의 상세 정보가 필요한 경우
하이퍼바이저 레이어 (Hypervisor Layers)
  • 주요 역할: 하이퍼바이저가 제공하는 메트릭스
  • 설명: 하이퍼바이저 레벨의 메트릭스는 하이퍼바이저로부터 직접 가져오는데, 하이퍼바이저가 보는 가장 정확한 메트릭스이다. 이러한 정보는 하이퍼바이저 노드 별로 또는 클러스터 전체 레벨로 볼 수 있다. 하이퍼바이저 레이어는 플랫폼이 보는 성능 측면에서 가장 정확한 데이터를 제공하기 때문에 대부분의 경우에 활용될 수 있다. 특정 시나리오에서 하이퍼바이저는 VM으로부터 오는 오퍼레이션을 합치거나 나눌 수 있는데, 이러한 경우에 VM과 하이퍼바이저가 제공하는 메트릭스에 차이가 있을 수 있다. 이러한 정보에는 뉴타닉스 CVM에 의해 서비스 되는 캐시 사용량 정보도 포함된다.
  • 사용 시기: 가장 상세하고 가치 있는 메트릭스를 제공하므로 대부분의 경우에 필요
컨트롤러 계층 (Controller Layer)
  • 주요 역할: 뉴타닉스 컨트롤러가 제공하는 메트릭스
  • 설명: 컨트롤러 레벨의 메트릭스는 뉴타닉스 컨트롤러(e.g. 스타게이트 2009 페이지)로부터 직접 가져오며, 뉴타닉스 프론트엔드가 NFS/SMB/iSCSI로부터 보는 정보 또는 모든 백엔드 오퍼레이션(e.g. ILM, 디스크 밸런싱 등) 정보를 제공한다. 이러한 정보는 CVM 별로 또는 클러스터 전체 레벨로 볼 수 있다. 컨트롤러가 제공하는 메트릭스는 하이퍼바이저가 제공하는 메트릭스와 일반적으로 일치하지만, 추가적으로 모든 백엔드 오퍼레이션(e.g. ILM, 디스크 밸런싱 등)을 포함한다. 이러한 정보에는 메모리에 의해 서비스되는 캐시 사용량 정보가 포함된다. 특정 케이스에서, IOPS와 같은 메트릭스는 NFS/SMB/iSCSI 클라이언트가 사이즈가 큰 IOPS를 보다 작은 여러 개의 IOPS로 나눌 수 있기 때문에 일치하지 않을 수도 있다. 그러나, 대역폭과 같은 메트릭스는 일치한다.
  • 사용 시기: 하이퍼바이저 레이어와 유사하게, 얼마나 많은 백엔드 오퍼레이션이 수행되고 있는지를 확인할 때 사용된다.
디스크 레이어 (Disk Layer)
  • 주요 역할: 디스크 디바이스가 제공하는 메트릭스
  • 설명: 디스크 레벨의 메트릭스는 CVM을 통해 물리 디스크 디바이스로부터 직접 가져오며, 백엔드가 보는 정보를 제공한다. 이것은 디스크에서 I/O가 수행되는 OpLog 또는 익스텐트 스토어(Extent Store)의 사용량 정보를 포함한다. 이러한 데이터는 디스크 별로, 특정 노드의 디스크, 또는 클러스터 전체 레벨에서 볼 수 있다. 일반적인 경우에, 디스크 오퍼레이션은 입력 데이터의 쓰기 뿐만 아니라 캐시의 메모리 부분에서 서비스 되지 않는 읽기 숫자와 일치하여야 한다. 캐시의 메모리 부분에서 서비스되는 모든 읽기는 해당 오퍼레이션이 디스크 디바이스를 사용하지 않기 때문에 디스크 레이어에서 카운트 되지 않는다.
  • 사용 시기: 얼마나 많은 오퍼레이션이 캐시 또는 디스크에서 수행되고 있는지 확인하고자 할 때 활용한다.
Note
메트릭스 및 통계 데이터 보유

메트릭스 및 시계열 데이터는 프리즘 엘리먼트에서 90일 동안 저장된다. 프리즘 센트럴 및 인사이트에서는 데이터가 무기한 저장된다 (스토리지 용량이 충분하다는 것을 가정).

서비스

뉴타닉스 게스트 툴 (NGT)

뉴타닉스 게스트 툴(NGT: Nutanix Guest Tool)은 소프트웨어 기반의 인-게스트 에이전트 프레임워크(In-Guest Agent Framework)로 뉴타닉스 플랫폼에서 VM과 관련된 고급 관리 기능을 제공한다.

본 솔루션은 VM에 설치되는 NGT 인스톨러(NGT Installer)와 뉴타닉스 플랫폼과 에이전트간의 코디네이션 기능을 수행하는 게스트 툴 프레임워크(Guest Tool Framework)로 구성되어 있다.

NGT 인스톨러는 다음과 같은 컴포넌트를 포함한다.

  • 게스트 에이전트 서비스 (Guest Agent Service)
  • 셀프-서비스 리스토어 (Self-Service Restore - File-Level Restore CLI로 알려짐)
  • VM 모빌리티 드라이버 (VM Mobility Drivers - AHV를 위한 VritIO 드라이버)
  • 윈도우 VM을 위한 VSS 에이전트 및 하드웨어 프로바이더
  • 리눅스 VM을 위한 애플리케이션 컨시스턴트 스냅샷 지원 (Quiesce를 위한 스크립트를 통해)

프레임워크는 몇 개의 하이-레벨 컴포넌트로 구성되어 있다.

  • 게스트 툴 서비스 (Guest Tool Service)
    • 아크로폴리스, 뉴타닉스 서비스, 게스트 에이전트간의 게이트웨이다. 클러스터에서 CVM에 분산되어 있으며, 선정된 NGT 마스터는 프리즘 리더 노드에 위치한다(클러스터 vIP를 호스팅).
  • 게스트 에이전트 (Guest Agent)
    • NGT 설치 과정에 VM의 OS에 배포되는 에이전트 및 관련된 서비스이다. 모든 로컬 기능(e.g., VSS, 셀프-서비스 리스토어(SSR) 등)을 처리하고, 게스트 툴 서비스와의 통신 및 제어 기능을 수행한다.

컴포넌트들간의 관계는 다음 그림과 같다.

Guest Tools Mapping
Figure. 게스트 툴 매핑 (Guest Tools Mapping)
게스트 툴 서비스

게스트 툴 서비스(Guest Tool Service)는 다음과 같은 2가지의 주요 역할(Main Role)로 구성된다.

  • NGT 마스터 (NGT Master)
    • NGT 프록시로부터 받은 요청을 처리하고, 아크로폴리스 컴포넌트와 인터페이스 한다. 클러스터 당 하나의 NGT 마스터가 동적으로 선정되고, 만약 마스터에 장애가 발생하면 새로운 마스터가 선정된다. 내부적으로 포트 2073에서 수신 대기한다.
  • NGT 프록시 (NGT Proxy)
    • 모든 CVM에서 동작하며, 요구된 액티비티를 수행하기 위해 요청을 NGT 마스터로 전달한다. 프리즘 리더(VIP를 호스팅하고 있는) 역할을 하는 현재 VM이 게스트 에이전트와의 통신을 처리하는 액티브 CVM이다. 외부적으로 포트 2074에서 수신 대기한다.

Note
현재 NGT 마스터

다음의 명령어를 사용하여 NGT 마스터 역할을 수행하고 있는 CVM IP를 확인할 수 있다.

nutanix_guest_tools_cli get_master_location

NGT 마스터와 NGT 프록시간의 관계는 다음 그림과 같다.

Guest Tools Service
Figure. 게스트 툴 서비스 (Guest Tool Service)
게스트 에이전트

게스트 에이전트(Guest Agent)는 앞에서 언급했던 것과 같이 다음 그림과 같은 하이-레벨 컴포넌트로 구성되어 있다.

Guest Agent
Figure. 게스트 에이전트 (Guest Agent)
통신 및 보안

게스트 에이전트 서비스(Guest Agent Service)는 SSL을 사용하여 뉴타닉스 클러스터 가상 IP를 통해 게스트 툴 서비스(Guest Tool Service)와 통신한다. 뉴타닉스 클러스터 컴포넌트와 UVM이 다른 네트워크를 사용하는 경우에 다음과 같은 조건을 확인하여야 한다.

  • UVM 네트워크로부터 클러스터 가상 IP로의 통신이 가능한지 확인한다.

OR

  • 방화벽 규칙(관련된 NAT 설정을 포함하여)을 생성하여 UVM 네트워크로부터 클러스터 가상 IP의 2074(선호) 포트로의 통신을 가능하게 한다.

게스트 툴 서비스는 CA(Certificate Authority) 역할을 수행하며, NGT가 활성화된 VUM을 위한 인증서 쌍(Certificate Pair)의 생성에 대한 책임을 갖는다. 본 인증서는 VUM 용으로 구성된 ISO에 포함되고, NGT 배포 프로세스의 일부로 사용된다. 본 인증서는 설치 과정에서 VUM의 내부에 설치된다.

NGT 에이전트 설치

NGT 에이전트 설치(NGT Agent Installation)는 프리즘, CLI/Scripts(nCLI/REST/PowerShell)로 수행된다.

프리즘을 통해 NGT를 설치하기 위해서는 VM 페이지를 방문하고, NGT를 설치할 VM을 선택하고 “NGT 활성화(Enable NGT)” 버튼을 클릭한다.

Enable NGT for VM
Figure. VM에서 NGT 활성화 (Enable NGT for VM)

NGT 설치 과정을 계속하기 위해서는 “Yes”를 클릭한다.

Enable NGT Prompt
Figure. NGT 프롬프트 활성화 (Enable NGT Prompt)

다음 그림에서 보는 것과 같이, VM은 소프트웨어가 포함된 인스톨러를 갖는 CD-ROM을 가져야 하며, 고유한 인증서는 CD-ROM에 마운트된다.

Enable NGT - CD-ROM
Figure. NGT 활성화 – CD-ROM (Enable NGT - CD-ROM)

NGT 인스톨러 CD-ROM은 OS에서 다음과 같이 보여진다.

Enable NGT - CD-ROM in OS
Figure. NGT 활성화 – OS에서 CD-ROM (Enable NGT - CD-ROM in OS)

설치 과정을 시작하기 위해서는 CD-ROM을 더블클릭 한다.

Note
자동 설치 (Silent Installation)

다음 명령을 실행(CD-ROM 위치에서 )하여 뉴타닉스 게스트 툴(Nutanix Guest Tools)의 자동 설치를 수행할 수 있다.

NutanixGuestTools.exe /quiet /l log.txt ACCEPTEULA=yes

프롬프트에 따라 라이선스를 수락하면 설치가 완료된다.

Enable NGT - Installer
Figure. NGT 활성화 – 인스톨러 (Enable NGT - Installer)

설치 프로세스의 일부로서 Python, PyWin, 뉴타닉스 모빌리티 드라이버(크로스-하이퍼바이저 호환성을 위한)가 설치된다.

설치가 완료되면, VM을 재부팅하여야 한다.

설치 및 재부팅이 완료되면, “Programs and Features”에서 다음과 같이 설치된 모듈들을 확인할 수 있다.

Enable NGT - Installed Programs
Figure. NGT 활성화 – 설치된 프로그림 (Enable NGT - Installed Programs)

다음 그림과 같이 NGT 에이전트 및 VSS 하드웨어 프로바이더 서비스가 실행되고 있음을 확인할 수 있다.

Enable NGT - Services
Figure. NGT 활성화 – 서비스 (Enabled NGT - Services)

이제 NGT가 정상적으로 설치되었으며 NGT 기능을 사용할 수 있다.

Note
대량 NGT 배포 (Bulk NGT Deployment)

NGT를 각각의 VM에서 설치하지 않고, 베이스 이미지에 NGT를 내장하여 배포하는 것이 가능하다.

베이스 이미지에 포함된 NGT를 사용하기 위해서는 다음과 같은 절차를 따른다.

  1. NGT를 마스터 VM에 설치하고 통신이 정상적인지를 확인한다.
  2. 마스터 VM으로부터 VM을 클론한다.
  3. 각각의 클론에서 NGT ISO를 마운트 한다 (새로운 인증서 쌍을 생성하기 위해).
    • 예제: ncli ngt mount vm-id=<CLONE_ID> OR via Prism
    • 자동화 방법: 곧 제공 예정
  4. 클론의 전원을 켠다.

클론 VM이 부팅될 때, VM은 새로운 NGT ISO를 검출하고, 설정 파일 및 새로운 인증서를 복사하고, 게스트 툴 서비스와 통신을 시작한다.

OS 커스터마이제이션

뉴타닉스는 Cloudinit 및 Sysprep를 사용하여 OS를 커스터마이제이션 할 수 있는 기능을 제공한다. CloudInit은 Linux 클라우드 서버의 부트스트랩을 처리하는 패키지이다. 이를 통해 Linux 인스턴스의 초기 초기화 및 커스터마이제이션이 가능하다. Sysprep은 Windows에서 사용할 수 있는 OS 커스터마이제이션 툴이다.

일반적인 OS 커스터마이제이션은 다음과 같은 기능을 포함한다.

  • 호스트 이름 설정 (Setting Hostname)
  • 패키지 설치 (Installing packages)
  • 사용자 추가 및 키 관리 (Adding users / key management)
  • 커스텀 스크립트 (Custom Scripts)
지원되는 환경

솔루션은 아래 버전을 포함하여 AHV에서 실행되는 Linux 게스트에 적용 할 수 있다 (목록이 완전하지 않을 수 있으니 전체 지원 목록은 별도 문서 참조).

  • 하이퍼바이저
    • AHV
  • 운영체제
    • Linux: 대부분의 최신 배포 버전
    • Windows: 대부분의 최신 배포 버전
전체 조건

Cloudinit을 사용하기 위해서는 다음과 같은 조건을 만족하여야 한다.

  • Cloudinit 패키지가 Linux 이미지에 설치되어야 한다.

Sysprep은 Windows 설치 버전에 디폴트로 포함되어 있다.

패키지 설치

Cloudinit은 다음과 같음 명령어를 사용하여 설치할 수 있다.

Red Hat 기반 시스템 (CentOS, RHEL)

yum -y install CloudInit


Debian 기반 시스템 (Ubuntu)

apt-get -y update; apt-get -y install CloudInit


Sysprep은 기본 Windows 설치 파일의 일부이다.

이미지 커스터마이제이션

OS 커스터마이제이션을 위해 사용자 정의 스크립트(Custom Script)를 사용할 수 있도록 프리즘 또는 REST API로 관련 기능을 제공한다. 이러한 옵션은 VM의 생성 및 클론 과정에서 설정할 수 있다.

Custom Script - Input Options
Figure. 커스텀 스크립트 – 입력 옵션 (Custom Script - Input Options)

뉴타닉스는 사용자 정의 스크립트 경로를 지정하기 위한 몇 개의 옵션을 제공한다.

  • ADSF 경로
    • 이전에 ADSF에 업로드 한 파일 사용
  • 파일 업로드
    • 사용될 파일을 업로드
  • 스크립트 입력 또는 복사
    • Cloudinit 스크립트 또는 Unatttend.xml 텍스트

뉴타닉스는 스크립트를 포함하는 CD-ROM의 생성을 통해 첫 번째 부트 동안에 유저 데이터 스크립트를 Cloudinit 또는 Sysprep 프로세스로 전달한다. 일단 프로세스가 완료되면 CD-ROM을 제거한다.

입력 포맷팅

플랫폼은 다양한 유저 데이터 입력 포맷을 지원한다. 여기에서는 몇 가지 중요한 입력 포맷에 대해 설명한다.

유저 데이터 스크립트 (Cloudinit – Linux)

유저 데이터 스크립트는 부트 프로세스에서 매우 늦게 실행되는 간단한 쉘 스크립트이다 (e.g. “rc.local-like”).

스크립트는 bash 스크립트(“#!”)와 유사하게 시작한다.

유저 데이터 스크립트의 예는 다음과 같다.

#!/bin/bash
touch /tmp/fooTest
mkdir /tmp/barFolder


Include File (Cloudinit – Linux)

Include file은 URL 목록을 포함한다 (라인 당 1개). 각 URL은 다른 스크립트와 유사하게 처리된다.

Include file 스크립트는 “#include”로 시작한다.

Include file 스크립트의 예는 다음과 같다.

#include
http://s3.amazonaws.com/path/to/script/1
http://s3.amazonaws.com/path/to/script/2


클라우드 설정 데이터 (Cloudinit – Linux)

cloud-config 입력 유형은 가장 보편적이며 Cloudinit에서만 적용된다.

스크립트는 “#cloud-init”으로 시작한다.

cloud config 데이터 스크립트의 예는 다음과 같다.

#cloud-config # Set hostname hostname: foobar # Add user(s) users: - name: nutanix sudo: ['ALL=(ALL) NOPASSWD:ALL'] ssh-authorized-keys: - ssh-rsa: <PUB KEY> lock-passwd: false passwd: <PASSWORD> # Automatically update all of the packages package_upgrade: true package_reboot_if_required: true # Install the LAMP stack packages: - httpd - mariadb-server - php - php-pear - php-mysql # Run Commands after execution runcmd: - systemctl enable httpd

Note
Cloudinit 실행 검증 (Validating CloudInit Execution)

Cloudinit 로그는 /var/log/cloud-init.log 및 cloud-init-output.log 파일에서 확인할 수 있다.


Unattend.xml (Sysprep - Windows)

Unattend.xml 파일은 부트 시에 이미지 커스터마이제이션을 위해 Sysprep이 사용하는 입력 파일이다. 보다 자세한 정보는 다음 링크를 참조: LINK

스크립트는 “<?xml version="1.0" ?>”로 시작한다.

Unattend.xml 파일의 예는 다음과 같다.

<?xml version="1.0" ?> <unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="windowsPE"> <component name="Microsoft-Windows-Setup" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="x86"> <WindowsDeploymentServices> <Login> <WillShowUI>OnError</WillShowUI> <Credentials> <Username>username</Username> <Domain>Fabrikam.com</Domain> <Password>my_password</Password> </Credentials> </Login> <ImageSelection> <WillShowUI>OnError</WillShowUI> <InstallImage> <ImageName>Windows Vista with Office</ImageName> <ImageGroup>ImageGroup1</ImageGroup> <Filename>Install.wim</Filename> </InstallImage> <InstallTo> <DiskID>0</DiskID> <PartitionID>1</PartitionID> </InstallTo> </ImageSelection> </WindowsDeploymentServices> <DiskConfiguration> <WillShowUI>OnError</WillShowUI> <Disk> <DiskID>0</DiskID> <WillWipeDisk>false</WillWipeDisk> <ModifyPartitions> <ModifyPartition> <Order>1</Order> <PartitionID>1</PartitionID> <Letter>C</Letter> <Label>TestOS</Label> <Format>NTFS</Format> <Active>true</Active> <Extend>false</Extend> </ModifyPartition> </ModifyPartitions> </Disk> </DiskConfiguration> </component> <component name="Microsoft-Windows-International-Core-WinPE" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="x86"> <SetupUILanguage> <WillShowUI>OnError</WillShowUI> <UILanguage>en-US</UILanguage> </SetupUILanguage> <UILanguage>en-US</UILanguage> </component> </settings> </unattend>

카본 (컨테이너 서비스)

뉴타닉스는 Kubernetes (현재)를 사용하여 뉴타닉스 플랫폼에서 영구 컨테이너를 활용할 수 있는 기능을 제공한다. 이전에 뉴타닉스 플랫폼에서 도커(Docker)를 실행할 수 있었다. 그러나, 컨테이너의 비영구적 속성으로 인해 데이터 영속성(Data Persistence)에 대한 이슈가 있었다.

도커(Docker)와 같은 컨테이너 기술(Container technologies)은 하드웨어 가상화와 다른 접근 방법을 사용한다. 전통적인 가상화 기술에서 각 VM은 자신의 OS를 갖고 있지만, 컨테이너(Container)는 기반이 되는 하드웨어를 공유하는 방식이다. 애플리케이션 및 관련된 자원을 포함하고 있는 컨테이너는 독립적인 프로세스로 실행이 되지만 기반이 되는 OS 커널을 공유하는 방식이다.

VM과 컨테이너간의 간단한 비교는 다음과 같다.

구분 가상머신 (VM) 컨테이너 (Containers)
가상화 유형 하드웨어 레벨의 가상화 OS 커널 가상화
오버헤드 많음 적음
프로비저닝 속도 느림 (수초 ~ 수분) 실시간 / 빠름 (us ~ ms)
성능 오버헤드 제한된 성능 본래의 성능
보안 완전히 격리 (보안에 유리) 프로세스 레벨의 격리 (보안 취약)
지원되는 환경

본 솔루션은 아래 구성에 적용 가능하다 (목록이 완전하지 않을 수 있으니 전체 지원 목록은 별도 문서 참조).

  • 하이퍼바이저
    • AHV
  • 컨테이너 시스템*
    • Docker 1.13

*AOS 4.7 버전부터는 도커 기반 컨테이너와의 스토리지 통합만을 지원한다. 그러나 다른 종류의 컨테이너 시스템은 뉴타닉스 플랫폼에서 VM으로 실행될 수 있다.

컨테이너 서비스 컨스트럭트

ACS(Acropolis Container Services)는 다음과 같은 엔티티로 구성된다.

  • Nutanix Docker Machine Driver: Docker Machine 및 Acropolis Image Services를 사용하여 Docker Container Host Provisioning를 처리한다.
  • Nutanix Docker Volume Plugin: 아크로폴리스 볼륨(Acropolis Volumes)과의 인테피이스에 대한 책임을 가지며, 원하는 컨테이너에 볼륨을 생성, 마운트, 포맷 및 부착(Attch) 한다.

도커(Docket)를 구성하는 엔티티는 다음과 같다 (Note: 모두가 필요하지는 않다).

  • Docker Image: 컨테이너의 베이스 이미지
  • Docker Registry: 도커 이미지 저장 공간
  • Docker Hub: 온라인 컨테이너 마켓플레이스 (퍼블릭 도커 레지스트리)
  • Docker File: 도커 이미지 생성 방법을 설명하는 텍스트 파일
  • Docker Container: 도커 이미지의 인스턴스 생성 실행
  • Docker Engine: 도커 컨테이너의 생성, 배포, 실행
  • Docker Swarm: 도커 호스트 클러스터링/스케줄링 플랫폼
  • Docker Daemon: 도커 클라이언트로부터의 요청을 처리하고, 컨테이너의 구축, 배포, 실행 등과 같은 작업을 수행
  • Docker Store: 신뢰할 수 있는 엔터프라이즈 레벨의 컨테이너를 위한 마켓 플레이스
아키텍처

뉴타닉스 솔루션은 도커 머신(Docker Machine)을 활용하여 생성된 VM에서 실행 중인 도커 엔진(Docker Engine)을 사용한다. 뉴타닉스 플랫폼에서 이러한 머신들을 일반 VM과 혼합하여 실행할 수 있다.

Docker - High-level Architecture
Figure. 도커 – 하이 레벨 아키텍처 (Docker - High-level Architecture)

뉴타닉스는 아크로폴리스 볼륨(Acropolis Volumes) 기능을 사용하여 컨테이너에 볼륨을 생성, 포맷 및 부착(Attach) 하는 Docker Volume Plugin을 제공한다. 이것은 컨테이너의 전원이 온/오프 되거나 이동되었을 때 데이터를 영구적으로 유지하게 한다.

데이터 영속성은 Docker Volume Plugin을 사용하여 구현되었는데, 볼륨을 호스트/컨테이너에 부착(Attach) 하기 위해 아크로폴리스 볼륨을 사용한다.

Docker - Volumes
Figure. 도커 - 볼륨 (Docker - Volumes)
전제 조건

컨테이너 서비스를 사용하기 위해서는 다음과 같은 조건이 만족되어야 한다.

  • 뉴타닉스 클러스터가 AOS 4.7 이상 이여야 한다.
  • iscsi-initiator-utils 패키지가 설치된 CentOS 7.0 이상 또는 Rhel 7.2 이상의 OS 이미지를 다운로드 받아야 하며 아크로폴리스 이미지 서비스(Acropolis Image Service)에 이미지로 존재해야 한다
  • 뉴타닉스 데이터 서비스 IP(Data Services IP)가 설정되어야 한다.
  • 도커 툴박스(Docker Toolbox)는 설정을 위해 사용되는 클라이언트 머신에 설치되어야 한다.
  • 뉴타닉스 도커 머신 드라이버(Nutanix Docker Machine Driver)가 클라이언트 경로에 존재하여야 한다.
도커 호스트 생성

상기의 전제 조건이 모두 만족되었다고 가정할 때의 첫 번째 단계는 도컨 머신(Docker Machine)을 이용하여 뉴타닉스 도커 호스트(Nutanix Docker Host)를 프로비저닝 하는 것이다.

docker-machine -D create -d nutanix \
--nutanix-username <PRISM_USER> --nutanix-password <PRISM_PASSWORD> \
--nutanix-endpoint <CLUSTER_IP>:9440 --nutanix-vm-image <DOCKER_IMAGE_NAME> \
--nutanix-vm-network <NETWORK_NAME> \
--nutanix-vm-cores <NUM_CPU> --nutanix-vm-mem <MEM_MB> \
<DOCKER_HOST_NAME>


상기 명령어를 실행하였을 때, 백-엔드 워크플로우는 다음과 같다.

Docker - Host Creation Workflow
Figure. 도커 – 호스트 생성 워크플로우 (Docker - Host Creation Workflow)

다음 단계는 docker-machine ssh를 통해 새롭게 프로비전된 도커 호스트(Docket Host)에 SSH로 접속하는 것이다.

docker-machine ssh <DOCKER_HOST_NAME>


뉴타닉스 Docker Volume Plugin을 설치하기 위해 다음을 실행한다.

docker plugin install ntnx/nutanix_volume_plugin PRISM_IP= DATASERVICES_IP= PRISM_PASSWORD= PRISM_USERNAME= DEFAULT_CONTAINER= --alias nutanix


뉴타닉스 Docker Volume Plugin이 활성화 되었는지를 확인한다.

[root@DOCKER-NTNX-00 ~]# docker plugin ls ID Name Description Enabled 37fba568078d nutanix:latest Nutanix volume plugin for docker true

도커 컨테이너 생성

뉴타닉스 도커 호스트를 배포하고, Volume Plugin을 활성화 한 후에, 영구 스토리지를 갖는 컨테이너를 프로비저닝 한다.

뉴타닉스 볼륨(Nutanix Volumes)을 사용하는 볼륨(Volumes)은 일반적인 도커 불륨 명령 구조를 사용하고, 뉴타닉스 볼륨 드라이버를 지정하여 생성할 수 있다. 사용 예는 다음과 같다.

docker volume create \
<VOLUME_NAME> --driver nutanix
Example:
docker volume create PGDataVol --driver nutanix


생성된 볼륨을 사용하여 컨테이너를 생성하는 명령어는 다음과 같다.

docker run -d --name <CONTAINER_NAME> \
-p <START_PORT:END_PORT> --volume-driver nutanix \
-v <VOL_NAME:VOL_MOUNT_POINT> <DOCKER_IMAGE_NAME>

Example:
docker run -d --name postgresexample -p 5433:5433 --volume-driver nutanix -v PGDataVol:/var/lib/postgresql/data postgres:latest


상기 명령어를 수행하였을 때의 백-엔드 워크플로우는 다음과 같다.

Docker - Container Creation Workflow
Figure. 도커 – 컨테이너 생성 워크플로우 (Docker - Container Creation Workflow)

상기 과정을 완료하면, 영구 스토리지를 갖는 컨테이너(Container)가 실행된 것을 확인할 수 있다.

백업 및 DR

뉴타닉스는 사용자가 온-프레미스 또는 클라우드 환경(Xi)의 DSF에서 실행 중인 VM 및 오브젝트를 백업, 복원 및 재해복구를 수행할 수 있는 네이티브 백업 및 DR 기능을 제공한다. AOS 5.11 버전에서 뉴타닉스는 이러한 많은 개념을 추상화한 Leap이라는 기능을 출시했다. Leap에 대한 더 자세한 정보는 'Book of Prism'의 'Leap' 섹션을 참조한다.

다음 섹션에서 다음과 같은 주제를 설명한다.

  • 구현 컨스트럭트 (Implementation Constructs)
  • 보호 엔티티 (Protection Entities)
  • 백업 및 복원 (Backup and Restore)
  • 복제 및 DR (Replication and DR)

NOTE: 뉴타닉스가 백업 및 DR을 위한 네이티브 옵션을 제공하지만, 플랫폼이 제공하는 기능(VSS, 스냅샷 등)을 활용하여 전통적인 솔루션(e.g., Commvault, Rubrik, etc)을 사용할 수 있다.

구현 컨스트럭트

뉴타닉스 백업 및 DR에는 다음과 같은 몇 가지 컨스트럭트가 있다.

보호 도메인 (Protection Domain: PD)
  • 주요 역할: 보호할 VM 또는 파일의 매크로 그룹
  • 설명: 지정된 스케줄에 기반하여 함께 복제되어야 할 VM 및 파일의 그룹이다. PD는 컨테이너 전체를 보호할 수도 있고, 개별적인 VM 또는 파일을 보호할 수도 있다.

Note
Pro tip

원하는 RPO/RTO를 충족할 수 있도록 다양한 서비스 티어에 대해 여러 개의 PD를 생성한다. 파일 배포(e.g. 골든 이미지, ISO 등)의 경우에 복제할 파일을 갖는 PD를 생성할 수 있다.

컨시스턴시 그룹 (Consistency Group: CG)
  • 주요 역할: PD에서 크래시-컨시스턴트(Crash-Consistent)를 지원하는 VM 또는 파일의 부분 집합
  • 설명: PD의 부분 집합으로 크래시-컨시스턴트 방식으로 스냅샷을 생성할 필요가 있는 VM/파일의 그룹이다. 이것은 VM/파일을 복구할 때, VM/파일들의 일관성 있는 상태를 보장한다. PD는 여러 개의 컨시스턴시 그룹을 가질 수 있다.

Note
Pro tip

애플리케이션 및 DB와 같이 상호 의존성이 큰 VM들을 일관성 있는 상태로 복구하기 위해 해당 애플리케이션 또는 서비스 VM을 컨시스턴시 그룹으로 생성한다.

스냅샷 스케줄 (Snapshot Schedule)
  • 주요 역할: 스냅샷 및 복제 스케줄
  • 설명: 특정 PD 및 CG에서 VM의 스냅샷 및 복제 스케줄이다.

Note
Pro tip

스냅샷 스케줄은 원하는 RPO와 동일하여야 한다.

보존 정책 (Retention Policy)
  • 주요 역할: 보존하여야 할 로컬 또는 원격 스냅샷의 개수
  • 설명: 보존 정책(Retention Policy)은 유지하여야 할 로컬 및 원격 스냅샷의 개수를 정의한다. NOTE: 원격 보존/복제 정책을 구성하려면 원격 사이트를 구성해야 한다.

Note
Pro tip

보존 정책은 VM/파일 당 요구된 복구 지점(Restore Point)의 개수와 동일하여야 한다.

원격 사이트 (Remote Site)
  • 주요 역할: 원격 뉴타닉스 클러스터
  • 설명: 원격 뉴타닉스 클러스터는 백업 또는 DR을 위한 타깃(Target)으로 사용될 수 있다.

Note
Pro tip

타깃 사이트(Target Site)는 전체 사이트 장애를 대비하여 충분한 용량(컴퓨트/스토리지)을 가지고 있어야 한다. 어떤 환경에서는 단일 사이트 내의 랙간 복제/DR도 의미가 있을수 있다.

단일 사이트에서 PD, CG, VM/파일간의 논리적인 관계는 다음과 같다.

DR Construct Mapping
Figure 11-37. DR 컨스트럭트 매핑 (DR Construct Mapping)

Note
정책 기반 DR 및 런북 (Policy Based DR & Run Books)

정책 기반 DR 및 런북(Policy Based DR & Run Books)은 VM 기반 DR(PD, CG 등)에 정의된 기능을 확장하고 작업을 정책 중심 모델로 추상화한다. 이를 통해 관심 항목(e.g. RPO, 보존 정책 등)에 집중하고, 정책을 VM에 직접 할당하는 대신 카테고리에 할당하여 구성을 단순화한다. 또한 모든 VM에 적용할 수 있는 "기본 정책(Default Policy)"을 허용한다.

NOTE: 이러한 정책은 프리즘 센트럴에서 설정할 수 있다.

보호 엔티티

다음과 같은 워크플로우를 사용하여 VMs, VGs, Files 등과 같은 엔티티를 보호할 수 있다.

“Data Protection” 페이지에서 “+Protection Domain > Async DR”을 선택한다.

DR - Async PD
Figure. DR – 비동기 DR (DR - Async PD)

PD 이름을 입력하고 “Create” 버튼을 클릭한다.

DR - Create PD
Figure. DR – PD 생성 (DR - Create PD)

보호할 엔티티를 선택한다.

DR - Async PD
Figure. DR – 비동기 PD (DR - Async PD)

“Protect Selected Entities”를 클릭한다.

DR - Protect Entities
Figure. DR – 엔티티 보호 (DR - Protect Entities)

보호되어야 할 엔티티가 “Protected Entities” 영역에 출력된다.

DR - Protected Entities
Figure. DR – 보호될 엔티티 (DR - Protected Entities)

“Next”를 클릭한 후에, 스냅샷 및 복제 스케줄을 생성하기 위해 “Next Schedule”를 클릭한다.

원하는 스냅샷 주기, 보존 기간 및 복제할 원격 사이트를 입력한다.

DR - Create Schedule
Figure. DR – 스케줄 생성 (DR - Create Schedule)

스케줄 설정을 완료하기 위해 “Create Schedule” 버튼을 클릭한다.

Note
다중 스케줄 (Multiple Schedules)

여러 개의 스냅샷 및 복제 스케줄을 생성하는 것이 가능하다. 예를 들어, 로컬 백업을 위한 시간 단위 스케줄과 원격 사이트로 일 단위 복제를 위한 스케줄을 생성할 수 있다.

단순화를 위해 전체 컨테이너를 보호할 수 있다는 것은 매우 중요하다. 그러나, 뉴타닉스 플랫폼은 보호할 수 있는 레벨을 세분화하여, VM 또는 파일 레벨의 보호 기능을 제공한다.

백업 및 복원

뉴타닉스 백업 기능은 네이티브 DSF 스냅샷 기능을 이용하는데, 세레브로(Cerebro)에 의해 시작되고, 스타게이트(Stargate)에 의해 수행된다. 스냅샷 기능은 효율적인 스토리지 활용 및 낮은 오버헤드를 보장하기 위해 제로 복사(Zero Copy) 방식을 사용한다. 뉴타닉스 스냅샷에 대한 상세한 정보는 “스냅샷 및 클론(Snapshots and Clones)” 섹션을 참조한다.

일반적인 백업 및 복원 오퍼레이션은 다음을 포함한다.

  • 스냅샷 (Snapshot): 복원 지점을 생성하고 복제 (필요한 경우에) 한다.
  • 복원 (Restore): 이전의 스냅샷으로부터 VM 및 파일을 복원한다 (오리지널 오브젝트를 대체).
  • 클론 (Clone): 복원과 유사하나 오리지널 오브젝트를 대체하지 않는다 (스냅샷으로부터 새로운 오브젝트를 생성한다).

“Data Protection” 페이지의 “Protecting Entities” 섹션에서 이전에 생성된 PD를 확인할 수 있다.

DR - View PDs
Figure. DR – PD 확인 (DR - View PDs)

대상 PD를 선택하면, 다음과 같은 옵션을 볼 수 있다.

DR - PD Actions
Figure. DR - PD 액션 (DR - PD Actions)

“Take Snapshot”을 클릭하면 선택한 PD의 스냅샷을 생성할 수 있으며 필요한 경우에 원격 사이트로 복제할 수 있다.

DR - Take Snapshot
Figure. DR – 스냅샷 생성 (DR - Take Snapshot)

“Migrate” 버튼을 클릭하여 엔티티를 원격 사이트로 페일오버 할 수 있다.

DR - Migrate
Figure. DR – 마이그레이트 (DR - Migrate)

“Migrate” 이벤트(계획된 페일오버)가 발생하면, 시스템은 새로운 스냅샷을 생성하고 복제한 다음 새로 생성된 스냅샷으로 다른 사이트를 "Promote" 한다.

Note
Pro tip

AOS 5.0 이상의 버전에서 단일 노드 복제 대상 데이터 보호를 활용할 수 있다.

또한, 아래와 같이 테이블 형태로 PD 스냅샷을 조회할 수 있다.

DR - Local Snapshots
Figure. DR – 로컬 스냅샷 (DR - Local Snapshots)

여기서부터 PD 스냅샷의 복원(Restore) 또는 클론(Clone) 기능을 설명한다.

DR - Restore Snapshot
Figure. DR – 스냅샷 복원 (DR - Restore Snapshot)

“Create new entities”를 선택하면 PD 스냅샷을 지정된 접두사를 갖는 새로운 엔티티로 클론 작업을 수행하고, “Overwrite existing entities”를 선택하면 현재의 엔티티를 스냅샷 시점의 엔티티로 대체한다.

Note
스토리지 전용 백업 타깃 (Storage only backup target)

백업 및 아카이빙 목적을 위해, 백업 타깃 역할을 수행하는 스토리지 전용 클러스터를 원격 사이트로 설정할 수 있다. 이러한 경우에 데이터는 스토리지 전용 클러스터로 복제된다.

애플리케이션 컨시스턴트 스냅샷

뉴타닉스는 애플리케이션 컨시스턴트 스냅샷(Application Consistent Snapshots)의 생성을 보장하기 위해, OS 및 애플리케이션의 오퍼레이션을 잠시 멈추게(Quiescing) 하기 위한 네이티브 VSS(VmQuiesced Snapshot Service) 기능을 제공한다.

Note
VmQueisced Snapshot Service (VSS)

VSS는 Windows 용어로 일반적으로 Volume Shadow Copy Service이다. 그러나, 이러한 솔루션이 Windows 및 Linux에 적용되므로, 뉴타닉스는 VmQuiesced Snapshot Service로 수정하여 사용한다.

지원되는 환경

본 솔루션은 아래 버전을 포함하여 Windows 및 Linux 게스트 모두에 적용할 수 있다 (목록이 완전하지 않을 수 있으니 전체 지원 목록은 별도 문서 참조).

  • 하이퍼바이저
    • ESXi
    • AHV
  • Windows
    • 2008R2, 2012, 2012R2
  • Linux
    • CentOS 6.5/7.0
    • RHEL 6.5/7.0
    • OEL 6.5/7.0
    • Ubuntu 14.04+
    • SLES11SP3+
전체 조건

뉴타닉스 VSS 스냅샷을 사용하기 위해서는 다음과 같은 조건을 만족하여야 한다.

  • 뉴타닉스 플랫폼
    • 클러스터 가상 IP(Cluster Virtual IP)가 반드시 설정되어야 한다.
  • 게스트 OS / UVM
    • NGT가 설치되어야 한다.
    • CVM VIP가 2074 포트로 통신되어야 한다.
  • DR 설정
    • UVM이 “Use application consistent snapshots” 기능이 활성화된 PD에 존재하여야 한다.
아키텍처

본 기능은 AOS 4.6 버전에서부터 NGT 패키지의 일부로 설치되는 뉴타닉스 하드웨어 VSS 프로바이더(Nutanix Hardware VSS provider)를 사용하여 구현되었다. NGT에 대한 상세 정보는 “Nutanix Guest Tools” 섹션을 참조한다.

VSS 아키텍처는 다음 그림과 같다.

Nutanix Hardware VSS Provider
Figure. VSS 아키텍처 (VSS Architecture)

일반적인 데이터 보호 워크플로에 따라 VM을 보호할 때 “Use application consistent snapshots”을 선택하면 애플리케이션 컨시스턴트 스냅샷을 생성할 수 있다.

Note
뉴타닉스 VSS 활성화/비활성화 (Enabling/Disabling Nutanix VSS)

UVM에서 NGT가 활성화된 경우에, 뉴타닉스 VSS 기능은 디폴트로 활성화 된다. 그러나, 다음 명령어를 사용하여 뉴타닉스 VSS 기능을 비활성화 할 수 있다.

ncli ngt disable-applications application-names=vss_snapshot vm_id=<VM_ID>

Windows VSS 아키텍처

뉴타닉스 VSS 솔루션은 Windows VSS 프레임워크와 통합되었다. Windows VSS 아키텍처는 다음 그림과 같다.

Nutanix VSS - Windows Architecture
Figure. 뉴타닉스 VSS – Windows 아키텍처 (Nutanix VSS - Windows Architecture)

NGT를 설치하면 NGT 에이전트(NGT Agent) 및 VSS 하드웨어 프로바이더(VSS Hardware Provider) 서비스를 확인할 수 있다.

VSS Hardware Provider
Figure. VSS 하드웨어 프로바이더 (VSS Hardware Provider)
Linux VSS 아키텍처

Linux 솔루션은 Windows 솔루션과 유사하게 동작하지만, Linux 배포판에는 Windows VSS 프레임워크와 같은 기능이 제공되지 않기 때문에 스크립트(Scripts)가 사용된다.

Linux VSS 아키텍처는 다음 그림과 같다.

Nutanix VSS - Linux Architecture
Figure. 뉴타닉스 VSS – Linux 아키텍처 (Nutanix VSS - Linux Architecture)

Pre-Freeze 및 Post-Thaw 스크립트는 다음 디렉토리에 위치한다.

  • Pre-freeze: /sbin/pre_freeze
  • Post-thaw: /sbin/post-thaw

Note
ESXi 잠시 멈춤 제거하기 (Eliminating ESXi Stun)

ESXi는 VMware Guest Tools를 사용하여 애플리케이션 컨시스턴트 스냅샷을 지원한다. 그러나, 이러한 프로세스 동안에, 델타 디스크가 생성되고, ESXi는 가상 디스크를 새로운 쓰기 IO를 처리할 새로운 델타 파일로 다시 매핑하기 위해 VM을 “잠시 멈춤(Stuns)” 시킨다. 잠시 멈춤은 VMware 스냅샷이 삭제될 경우에도 발생한다.

이러한 잠시 멈춤 프로세스 동안에 VM의 게스트 OS는 어떠한 종류의 오퍼레이션도 실행시키지 않기 때문에, 결국 멈춤 상태(Stuck state)에 있게 된다(e.g., PING 실패, IO 없음). 잠시 멈춤 시간은 vmdk의 개수와 데이터스토어 메타데이터 오퍼레이션(e.g., 새로운 델타 디스크 생성 등)의 작업 속도에 따라 달리진다.

뉴타닉스 VSS를 사용하면 VMware 스냅샷/잠시 멈춤(Snapshot/Stun) 프로세스를 바이패스 하기 때문에 성능 또는 VM/OS 가용성에 거의 양향을 미치지 않는다.

복제 및 DR

동영상 시청을 원하시면 다음 링크를 클릭하세요: LINK


뉴타닉스는 복제 및 DR 기능을 제공하는데, 스냅샷 및 클론 섹션에서 설명한 동일한 기능을 기반으로 구현되었다. 세레브로(Cerebro)는 DSF에서 DR 및 복제 기능의 관리에 대한 책임을 갖는 컴포넌트이다. 세레브로는 모든 노드에서 실행되며, 세레브로 마스터가 선정되고(NFS 마스터와 유사), 선정된 세레브로 마스터는 복제 태스크 관리에 대한 책임을 갖는다. 세레브로 마스터 역할을 하는 CVM에 장애가 발생하면, 다른 CVM이 마스터로 선정되고, 세레브로 마스터 역할을 수행한다. 세레브로 페이지의 URL은 <CVM IP>:2020 이다. DR 기능은 다음과 같은 기능으로 세분화할 수 있다.

  • 복제 토폴로지 (Replication Topology)
  • 복제 생애주기 (Replication Lifecycle)
  • 글로벌 데이터 중복제거 (Global Deduplication)
복제 토폴로지

전통적으로, Site to Site, Hub and Spoke, Full and/or Partial Mesh와 같은 몇 가지의 주요 복제 토폴로지(Replication Topology)가 있다. 단지 Site to Site, Hub and Spoke 토폴로지를 허용하는 전통적인 솔루션과 달리, 뉴타닉스는 Full Mesh 또는 유연한 Many-to-Many 모델을 제공한다.

Example Replication Topologies
Figure 11-36. 복제 토폴로지 예제 (Example Replication Topologies)

기본적으로 관리자는 회사의 요구를 충족시키는 복제 기능을 결정할 수 있다.

복제 생애주기

뉴타닉스 복제는 상기에서 언급한 세레브로 서비스를 이용한다. 세레브로 서비스는 동적으로 선정된 CVM인 “세레브로 마스터(Cerebro Master)”와 모든 CVM에서 실행 중인 세레브로 슬레이브(Cerebro Slave)로 분류된다. 세레브로 마스터 역할을 수행하는 CVM에 장애가 발생하면, 새로운 마스터가 선정된다.

세레브로 마스터는 로컬 세레브로 슬레이브에게 작업 위임의 관리에 대한 책임을 가질 뿐만 아니라 원격 복제가 발생할 때 원격 세레브로 마스터와의 코디네이션에 대한 책임을 갖는다.

복제 작업 동안에, 세레브로 마스터가 복제되어야 할 데이터를 찾고, 복제 작업을 세레브로 슬레이브에게 할당하면, 세레브로 슬레이브는 복제할 데이터 및 어디로 보내야 할지를 스타게이트에게 알려준다.

복제된 데이터는 프로세스 전반에 걸쳐 여러 계층에서 보호된다. 소스에서 읽은 익스텐트(Extent)는 소스 데이터의 일관성을 보장하기 위해 체크섬을 계산하고(DSF 읽기와 유사한 방식), 타깃에서 새로운 익스텐트의 체크섬이 계산된다(DSF 쓰기와 유사). TCP는 네트워크 계층에서 일관성을 제공한다.

복제 아키텍처는 다음 그림과 같다.

Replication Architecture
Figure 11-38. 복제 아키텍처 (Replication Architecture)

원격 사이트에 프록시를 설정하는 것이 가능한데, 프록시(Proxy)는 클러스터로부터 들어오는 모든 코디네이션 및 복제 트래픽의 브리지헤드(Bridgehead) 역할을 수행한다.

Note
Pro tip

프록시로 구성된 원격 사이트인 경우에, CVM이 다운되더라도 프리즘 리더가 항상 호스트하고 사용할 수 있는 클러스터 가상 IP를 사용한다.

프록시를 사용한 복제 아키텍처는 다음 그림과 같다.

Replication Architecture - Proxy
Figure 11-39. 복제 아키텍처 – 프록시 (Replication Architecture - Proxy)

특정 시나리오에서, SSH 터널(SSH Tunnel)을 사용하여 원격 사이트를 설정하는 것이 가능한데, 이 경우에 모든 트래픽은 2개의 CVM간에만 흐른다.

Note
Note

SSH 터널은 개발 및 테스트 환경에서만 설정하여야 하고, 가용성을 보장하기 위해 클러스터 가상 IP를 사용한다.

SSH 터널을 사용한 복제 아키텍처는 다음 그림과 같다.

Replication Architecture - SSH Tunnel
Figure 11-40. 복제 아키텍처 – SSH 터널 (Replication Architecture - SSH Tunnel)
글로벌 데이터 중복제거

데이터 중복제거 엔진 섹션에서 설명한 바와 같이, DSF는 메타데이터 포인터의 갱신만으로 데이터 중복제거 작업을 수행한다. 동일한 개념이 DR 및 복제 기능에도 적용된다. WAN으로 데이터를 전송하기 전에, DSF는 원격 사이트에 질의를 수행하고, 타깃 사이트에 지문(Fingerprint)이 존재하는지(데이터가 이미 존재한다는 것을 의미)를 체크한다. 만약 지문이 존재하면, 데이터는 전송되지 않고, 단지 메타데이터 갱신만 발생한다. 타깃에 존재하지 않는 데이터는 압축이 된 후에 타깃 사이트로 전송된다. 이 시점에서, 두 사이트에 존재하는 데이터는 중복제거에 사용할 수 있다.

다음 그림은 각각 1개 이상의 PD를 갖는 3개의 사이트로 구성된 환경에서 글로벌 데이터 중복제거 동작을 보여준다.

Replication Deduplication
Figure 11-41. 복제 데이터 중복제거 (Replication Deduplication)
Note
Note

복제 시의 데이터 중복제거 작업을 수행하기 위해서는 소스 및 타깃 컨테이너/vStore에서 데이터 중복제거(Fingerprinting) 기능을 활성화해야 한다.

NearSync

앞에서 언급한 전통적인 비동기 복제 기술을 기반으로 뉴타닉스는 동기 복제에 근접한 NearSync 복제(Near Synchronous Replication) 기능을 제공한다.

NearSync는 두 가지 장점을 모두 제공하는 데, 매우 낮은 RPO(동기 복제(Metro-Availability)와 같이) 외에도 기본 I/O 레이턴시(비동기 복제와 같이)에 미치는 영향이 거의 없다. 이를 통해 사용자는 쓰기를 위해 동기 복제가 요구하는 오버헤드 없이 매우 낮은 RPO를 구현할 수 있다.

NearSync는 LWS(Light-Weight Snapshot)라는 새로운 스냅샷 기술을 사용한다. 비동기 복제에서 사용하는 전통적인 vDisk 기반의 스냅샷 기술과 달리, NearSync는 마커(Marker)를 활용하고, 전적으로 OpLog 영역에서 모든 작업을 수행한다(vDisk 기반의 스냅샷은 익스텐트 스토어 영역에서 수행된다).

메소스(Mesos)는 스냅샷 레이어를 관리하고 전체/증분(Full/Incremental) 스냅샷의 복잡성을 추상화하기 위해 추가된 새로운 서비스이다. 세레브로는 하이-레벨 컨스트럭트 및 정책(e.g. 컨시스턴시 그룹 등)을 계속 관리하는 반면, 메소스는 스타게이트와의 통신 및 LWS 라이프사이클 관리에 대한 책임을 갖는다.

NearSync 컴포넌트들간의 통신 관계는 다음 그림과 같다.

NearSync Components
Figure. NearSync 컴포넌트 상호작용 (NearSync Component Interaction)

사용자가 스냅샷 주기를 15분 이하로 설정할 때 NearSync가 자동적으로 적용된다. 이 때 초기 시드 스냅샷(Seed Snapshot)이 생성되고 원격 사이트로 복제된다. 이 작업이 60분 이내에 완료되면(첫 번째 스냅샷 또는 n 번째 스냅샷이 될 수 있음), LWS 스냅샷 복제 시작과 함께 다른 시드 스냅샷이 즉시 생성되고 복제된다. 일단 두 번째 시드 스냅샷의 복제가 완료되면 이미 복제된 모든 LWS 스냅샷이 유효하게 되며 시스템은 안정적인 NearSync 상태에 있게 된다.

NearSync 활성화부터 실행까지의 타임라인은 다음 그림과 같다.

NearSync Replication Lifecycle
Figure. NearSync 복제 생애주기 (NearSync Replication Lifecycle)

안정된 실행 상태에서 vDisk 스냅샷이 매 시간 생성된다. LWS 이외에 스냅샷을 원격 사이트로 전송하는 대신, 원격 사이트에서는 이전 vDisk 스냅샷과 그 시간대의 LWS를 기반으로 vDisk 스냅샷을 구성한다.

NearSync 동기화가 실패(e.g. 네트워크 단절, WAN 레이턴시 증가 등)하여 LWS 복제가 60분을 초과하면, 시스템은 자동으로 vDisk 기반의 스냅샷으로 다시 전환된다. 이 중 하나가 60분 이내에 완료되면, 시스템은 즉시 다른 스냅샷을 생성할 뿐만 아니라 LWS 복제 작업을 시작한다. 일단 전체 스냅샷의 복제가 완료되면, LWS 스냅샷은 유효하게 되고, 시스템은 안정된 NearSync 상태에 있게 된다. 이러한 프로세스는 NearSync의 초기 활성화 상태와 유사하다.

LWS 기반의 스냅샷이 복원(또는 클론) 될 때, 시스템은 최신 vDisk 스냅샷의 클론을 생성하고 원하는 LWS에 도달할 때까지 LWS를 점차적으로 적용한다.

LWS 기반 스냅샷의 복원 과정은 다음 그림과 같다.

vDisk Restore from LWS
Figure. LWS로부터 vDisk 복원 (vDisk Restore from LWS)

매트로 가용성

뉴타닉스는 컴퓨트 및 스토리지 클러스터를 여러 개의 물리적 사이트에 걸쳐 구성할 수 있는 네이티브 “스트레치 클러스터링(Stretch Clustering)" 기능을 제공한다. 이러한 배포 환경에서 컴퓨트 클러스터는 2개의 위치에 걸쳐있게 되고 공유 스토리지 풀에 액세스할 수 있다.

이것은 VM HA 도메인을 단일 사이트에서 두 개의 사이트로 확장한 것으로 “0”에 근접한 RTO 및 “0” RPO를 지원한다.

이러한 배포 환경에서 각 사이트는 자신의 뉴타닉스 클러스터를 가지지만 쓰기 ACK(Write ACK)를 송신하기 전에 원격 사이트에 동기적으로 복제하여 컨테이너를 “확장(Stretched)” 한다.

매트로 가용성(Metro Availability) 아키텍처는 다음 그림과 같다.

Metro Availability - Normal State
Figure 11-45. 매트로 가용성 – 정상 상태 (Metro Availability - Normal State)

사이트 장애가 발생하면, VM을 재시작 할 수 있는 다른 사이트에서 HA 이벤트가 발생한다. 페일오버 프로세스는 일반적으로 수동 프로세스이다. AOS 5.0 버전을 사용하면 페일오버를 자동화할 수 있는 메트로 위트니스(Metro Witness)를 구성할 수 있다. 위트니스 VM(Witness VM)은 포탈에서 다운로드 할 수 있으며 프리즘을 통해 설정할 수 있다.

사이트 장애 시의 동작은 다음 그림과 같다.

Metro Availability - Site Failure
Figure 11-46. 매트로 가용성 – 사이트 장애 (Metro Availability - Site Failure)

두 사이트간에 링크 장애(Link Failure)가 발생하면 각 클러스터는 독립적으로 오퍼레이션 한다. 링크가 복구되면 사이트는 다시 동기화되고(변경분만 동기화) 동기 복제가 시작된다.

링크 장애 시의 동작은 다음 그림과 같다.

Metro Availability - Link Failure
Figure 11-47. 매트로 가용성 – 링크 장애 (Metro Availability - Link Failure)

클라우드 커넥트

클라우드 커넥트(Cloud Connect) 기능은 DSF의 네이티브 DR/복제 기능을 클라우드 프로바이더(Amazon Web Services, Microsoft Azure 지원)로 확장한 것이다. NOTE: 클라우드 커넥트 기능은 현재 백업/복제 기능으로 제한되어 있다.

네이티브 DR/복제를 위해 사용될 원격 사이트를 생성하는 것과 매우 유사하게, “클라우드 원격 사이트(Cloud Remote Site)”를 생성하여야 한다. 새로운 클라우드 원격 사이트를 생성할 때, 뉴타닉스는 EC2(현재 m1.xlarge) 또는 Azure VM(현재 D3)에 엔드포인트(Endpoint)로 사용될 단일 노드 뉴타닉스 클러스터를 자동으로 스핀업(Spin Up) 한다.

클라우드 인스턴스(Cloud Instance)는 로컬 클러스터 실행을 위해 사용하는 것과 동일한 아크로폴리스 코드 베이스(Acropolis Code-Base)를 기반으로 한다. 이것은 모든 네이티브 복제 기능(e.g. 글로벌 데이터 중복제거, 델타 기반의 복제 등)을 사용할 수 있다는 것을 의미한다.

여러 개의 뉴타닉스 클러스터가 클라우드 커넥트 기능을 사용하는 경우에, A) 리전(Region)에서 실행 중인 동일한 인스턴스를 공유하거나, B) 새로운 인스턴스를 스핀업(Spin Up) 할 수 있다.

클라우드 인스턴스 스토리지는 S3(AWS) 또는 BlobStore(Azure)가 지원하는 논리 디스크인 “클라우드 디스크(Cloud Disk)”를 사용한다. 데이터는 오브젝트 스토어에서 파일로 존재하는 일반적인 egroups으로 저장된다.

클라우드 커넥트로 사용된 “원격 사이트”의 논리적 표현은 다음 그림과 같다.

Cloud Connect - Region
Figure 11-42. 클라우드 커넥트 리전 (Cloud Connect Region)

클라우드 기반 원격 사이트는 다른 뉴타닉스 원격 사이트와 유사하기 때문에, 고가용성을 요구하는 경우(e.g. 전체 리전 장애 시에도 데이터 가용성 보장)에 클러스터는 여러 개의 리전에 복제할 수 있다.

Cloud Connect - Multi-region
Figure 11-43. 클라우드 커넥트 멀티-리전 (Cloud Connect Multi-region)

클라우드 커넥트를 사용하여 복제된 데이터에도 동일한 복제/보존 정책을 적용할 수 있다. 데이터/스냅샷이 오래되거나 만료되면, 클라우드 클러스터는 필요에 따라 데이터를 정리한다.

복제가 자주 발생하지 않는 경우에(e.g. 일 또는 주 단위), 예정된 복제 작업 시간 이전에 클라우드 인스턴스의 전원을 켜고, 복제 작업이 완료된 후에 전원을 끄도록 플랫폼을 설정할 수 있다.

모든 클라우드 리전에 복제된 데이터는 클라우드 원격 사이트가 설정된 기존 또는 새로 생성한 뉴타닉스 클러스터로 다운로드 받은 후에 복원할 수 있다.

Cloud Connect - Restore
Figure 11-44. 클라우드 커넥트 – 복원 (Cloud Connect - Restore)

Application Mobility Fabric (AMF)

내용 추가 예정입니다.

관리

중요 페이지

본 섹션에서 설명하는 페이지는 표준 사용자 인터페이스 이외의 고급 뉴타닉스 페이지로 상세한 통계 및 메트릭스 정보를 제공한다. URL 포맷은 http://<뉴타닉스 CVM IP>:<포트/패스>로, 예를 들어, “http://MyCVM-A:2009”와 같다. NOTE: 다른 서브넷에서 접속하고자 하는 경우에 페이지에 액세스 하기 위해서는 CVM에서 iptables가 비활성화 되어야 한다.

2009 페이지

스타게이트 페이지로 백엔드 스토리지 시스템을 모니터링 하기 위해 사용되며, 고급 사용자에 의해 사용되어야 한다.

2009/latency 페이지

스타게이트 페이지로 백엔드 레이턴시(Backend Latency)를 모니터링 하기 위해 사용된다.

2009/vdisk_stats 페이지

스타게이트 페이지로 vDisk와 관련된 다양한 통계 정보를 제공하는데, I/O 사이즈, 레이턴시, Write Hits(e.g., OpLog, eStore), Read Hits(e.g. SSD, HDD 등) 등과 같은 정보를 포함한다.

2009/h/traces 페이지

스타게이트 페이지로 오퍼레이션의 액티비티 추적을 위해 사용된다.

2009/h/vars 페이지

스타게이트 페이지로 다양한 카운터(Counters)의 모니터링을 위해 사용된다.

2010 페이지

큐레이터 페이지로 큐레이터 실행을 모니터링 하기 위해 사용된다.

2010/master/control 페이지

큐레이터 컨트롤 페이지로 수작업으로 큐레이터 잡(Curator Job)을 수행시키기 위해 사용된다.

2011 페이지

크로노스 페이지로 큐레이터에 의해 스케줄링 된 잡(Job) 및 태스크(Task)를 모니터링 하기 위해 사용된다.

2020 페이지

세레브로 페이지로 PD, 복제 상태 및 DR을 모니터링 한다.

2020/h/traces 페이지

세레브로 페이지로 PD 오퍼레이션 및 복제를 위한 액티비티 추적을 모니터링 하기 위해 사용된다.

2030 페이지

메인 아크로폴리스 페이지로 환경 호스트, 현재 실행 중인 모든 태스크, 네트워킹 등과 관련된 상세 정보를 제공한다.

2030/sched 페이지

아크로폴리스 페이지로 위치 결정을 위해 사용된 VM 및 자원 스케줄링에 대한 상세 정보를 제공한다. 또한, 가용한 호스트 자원 및 각 호스트에서 실행 중인 VM 정보를 제공한다.

2030/tasks 페이지

아크로폴리스 페이지로 아크로폴리스 태스크 및 상태 정보를 제공한다. 태스크에 대한 상세 JSON 정보를 얻기 위해서는 태스크 UUID를 클릭한다.

2030/vms 페이지

아크로폴리스 페이지로 아크로폴리스 VM 및 VM에 대한 상세 정보를 제공한다. 콘솔을 연결하려면 VM 이름을 클릭한다.

클러스터 명령어

클러스터 상태 체크

설명: CLI 명령어로 클러스터 상태 체크

cluster status

로컬 CVM 서비스 상태 체크

설명: CLI 명령어로 특정 CVM의 서비스 상태 체크

genesis status

업그레이드 상태 체크

upgrade_status

노드 업그레이드
하이퍼바이저 업그레이드 상태

설명: 임의의 CVM에서 CLI 명령어를 이용하여 하이퍼바이저 업그레이드 상태 체크

host_upgrade_status

상세 로그 (모든 CVM에서)

~/data/logs/host_upgrade.out

CLI로 클러스터 서비스 재시작

설명: CLI로 클러스터 서비스 재시작

서비스 중지

cluster stop <Service Name>

중지된 서비스 시작

cluster start  #NOTE: 모든 중지된 서비스 시작

CLI로 클러스터 서비스 시작

설명: CLI로 중지된 클러스터 서비스 시작

중지된 서비스 시작

cluster start  #NOTE: 모든 중지된 서비스 시작

또는

단일 서비스 시작

Start single service: cluster start  <Service Name>

CLI로 로컬 서비스 재시작

설명: CLI로 단일 클러스터 서비스 재시작

서비스 중지

genesis stop <Service Name>

서비스 시작

cluster start

CLI로 로컬 서비스 시작

설명: CLI로 중지된 클러스터 서비스 사작

cluster start #NOTE: 모든 중지된 서비스 시작

cmdline으로 클러스터 노드 추가

설명: CLI로 클러스터 노드 추가 수행

ncli cluster discover-nodes | egrep "Uuid" | awk '{print $4}' | xargs -I UUID ncli cluster add-node node-uuid=UUID

클러스터 ID 찾기

설명: 현재 클러스터의 클러스터 ID 찾기

zeus_config_printer | grep cluster_id

포트 열기

설명: IPtables로 포트 활성화

sudo vi /etc/sysconfig/iptables
-A INPUT -m state --state NEW -m tcp -p tcp --dport <PORT> -j ACCEPT
sudo service iptables restart

쉐도우 클론 체크

설명: “name#id@svm_id” 형식으로 쉐도우 클론 출력

vdisk_config_printer | grep '#'

레이턴시 페이지 상태 초기화

설명: 레이턴시 페이지(<CVM IP>:2009/latency)의 카운터 초기화

allssh "wget 127.0.0.1:2009/latency/reset"

vDisk 정보 찾기

설명: 이름, ID, 사이즈, IQN 등의 정보를 포함하는 vDisk 정보 찾기

vdisk_config_printer

vDisk 개수 찾기

설명: DSF에서 현재 vDisk (Files) 개수 찾기

vdisk_config_printer | grep vdisk_id | wc -l

vDisk 상세 정보 얻기

설명: 지정된 vDisk의 상세 정보 얻기 (vDisks egroup IDs, size, transformation and savings, garbage and replica placement)

vdisk_usage_printer -vdisk_id=<VDISK_ID>

CLI로 큐레이터 스캔 시작

설명: CLI로 큐레이터 스캔 시작

# Full Scan
allssh "wget -O - "http://localhost:2010/master/api/client/StartCuratorTasks?task_type=2";"

# Partial Scan
allssh "wget -O - "http://localhost:2010/master/api/client/StartCuratorTasks?task_type=3";"

# Refresh Usage
allssh "wget -O - "http://localhost:2010/master/api/client/RefreshStats";"

CLI로 Under-Replicated 데이터 체크

설명: curator_cli를 이용하여 Under-Replicated 데이터 체크

curator_cli get_under_replication_info summary=true

링 콤팩트

설명: 메타데이터 링 콤팩트

allssh "nodetool -h localhost compact"

AOS 버전 찾기

설명: AOS 버전 찾기 (NOTE: nCLI 명령어로도 수행 가능)

allssh "cat /etc/nutanix/release_version"

CVM 버전 찾기

설명: CVM 이미지 버전 찾기

allssh "cat /etc/nutanix/svm-version"

수작업으로 vDisk Fingerprint 수행

설명: 특정 vDisk에 대해 데이터 중복제거(Fingerprint) 수행 (NOTE: 컨테이너에서 데이터 중복제거 기능이 활성화되어 있어야 함)

vdisk_manipulator ?vdisk_id=<vDisk ID> --operation=add_fingerprints

수작업으로 모든 vDisk Fingerprint 수행

설명: 모든 vDisk에 대해 데이터 중복제거(Fingerprint) 수행 (NOTE: 컨테이너에서 데이터 중복제거 기능이 활성화되어 있어야 함)

for vdisk in `vdisk_config_printer | grep vdisk_id | awk {'print $2'}`; do vdisk_manipulator -vdisk_id=$vdisk --operation=add_fingerprints; done

모든 클러스터 노드의 Factory_Config.JSON 출력

설명: 클러스터에서 모든 노드의 factory_config.json 출력

allssh "cat /etc/nutanix/factory_config.json"

뉴타닉스 1개 노드의 AOS 버전 업그레이드

설명: 클러스터의 AOS 버전과 일치하도록 1개 노드의 AOS 버전 업그레이드

~/cluster/bin/cluster -u <NEW_NODE_IP> upgrade_node

DSF 파일(vDisk) 목록 출력

설명: DSF에 저장된 vDisk 파일 및 관련 정보 출력

Nfs_ls

도움말 출력

Nfs_ls --help

NCC(Nutanix Cluster Check) 설치

설명: 잠재적인 이슈 및 클러스터 헬스 체크를 위해 NCC 설치

뉴타닉스 서포트 포털(portal.nutanix.com)에서 NCC 다운로드

/home/nutanix 디렉토리에 .tar.gz 복사

NCC .tar.gz 압축 해제

tar xzmf <ncc .tar.gz file name> --recursive-unlink

설치 스크립트 실행

./ncc/bin/install.sh -f <ncc .tar.gz file name>

링크 생성

source ~/ncc/ncc_completion.bash
echo "source ~/ncc/ncc_completion.bash" >> ~/.bashrc

NCC 실행

설명: 잠재적인 이슈 및 클러스터 헬스 체크를 위해 NCC를 실행한다. NCC를 실행하는 것이 모든 클러스터 이슈에 대한 장애처리(Troubleshooting) 단계에서의 첫 번째 작업이다.

NCC가 설치되어 있는지 확인한다 (상기 설치 단계 참조).

NCC 헬스 체크 실행

ncc health_checks run_all

프로그레스 모니터 CLI를 사용하여 태스크 목록 출력

progress_monitor_cli -fetchall

프로그레스 모니터 CLI를 사용하여 태스크 제거

progress_monitor_cli --entity_id=<ENTITY_ID> --operation=<OPERATION> --entity_type=<ENTITY_TYPE> --delete
# NOTE: operation and entity_type should be all lowercase with k removed from the begining

메트릭스 및 임계 값

다음 섹션에서 뉴타닉스 백엔드의 특정 메트릭스 및 임계 값에 대해 설명한다. 보다 상세한 내용 추가 예정입니다.

Gflags

내용 추가 예정입니다.

장애 처리 및 고급 관리

아크로폴리스 로그 찾기

설명: 클러스터에서 아크로폴리스 로그 찾기

allssh "cat ~/data/logs/Acropolis.log"

클러스터 ERROR 로그 찾기

설명: 클러스터에서 ERROR 로그 찾기

allssh "cat ~/data/logs/<COMPONENT NAME or *>.ERROR"

스타게이트에 대한 예제

allssh "cat ~/data/logs/Stargate.ERROR"

클러스터 FATAL 로그 찾기

설명: 클러스터에서 FATAL 로그 찾기

allssh "cat ~/data/logs/<COMPONENT NAME or *>.FATAL"

스타게이트에 대한 예제

allssh "cat ~/data/logs/Stargate.FATAL"

2009 페이지 사용하기 (스타게이트)

대부분의 경우에 프리즘에서 원하는 모든 정보 및 데이터를 얻을 수 있다. 그러나 특정 시나리오에서 또는 좀 더 상세한 데이터가 필요한 경우에 2009 페이지로 알려진 스타게이트 정보를 활용할 수 있다. 2009 페이지는 “<CVM IP>:2009”로 액세스 한다.

Note
백엔드 페이지 액세스 (Accessing back-end pages)

만약, 다른 네트워크 세그먼트(L2 서브넷)에서 접속하고자 하는 경우에, 모든 백엔드 페이지에 액세스하기 위해서는 IPtables에 규칙(Rule)을 추가해 주어야 한다.

TOP 페이지는 클러스터에 대한 다양한 상세 정보를 제공한다.

2009 Page - Stargate Overview
Figure 14-1. 2009 페이지 - 스타게이트 개요 (2009 Page - Stargate Overview)

본 섹션에는 2개의 주요 영역이 있는데, 첫 번째 영역은 Admitted / Outstanding 오퍼레이션의 개수를 보여주는 입출력 큐(I/O Queue) 정보이다.

개요 섹션에서 큐(Queue)와 관련된 부분은 다음 그림과 같다.

2009 Page - Stargate Overview - Queues
Figure 14-2. 2009 페이지 - 스타게이트 개요 - 큐 (2009 Page - Stargate Overview - Queues)

두 번째 영역은 캐시 사이즈 및 Hit Ratio 정보를 보여주는 유니파이드 캐시(Unified Cache)에 대한 상세 정보이다.

개요 섹션에서 유티파이드 캐시와 관련된 부분은 다음과 같다.

2009 Page - Stargate Overview - Unified Cache
Figure 14-3. 2009 페이지 - 스타게이트 개요 - 유니파이드 캐시 (2009 Page - Stargate Overview - Unified Cache)
Note
Pro tip

만약 워크로드가 읽기 중심(Read Heavy)인 경우에, 최대의 읽기 성능을 위해서는 히트 율(Hit Ratio)이 80 ~ 90%+ 이상이어야 한다.

NOTE: 상기의 값은 스타게이트/CVM 별로 제공된다.

다음은 클러스터의 다양한 스타게이트 및 디스크 사용률에 대한 상세 정보를 제공하는 “클러스터 상태(Cluster State)” 섹션이다.

스타게이트 및 디스크 사용률 정보(가용/전체)는 다음 그림과 같다.

2009 Page - Cluster State - Disk Usage
Figure 14-4. 2009 페이지 - 클러스터 상태 - 디스크 사용률 (2009 Page - Cluster State - Disk Usage)

다음은 “NFS 슬레이브(NFS Slave)” 섹션으로 vDisk에 대한 상세 및 통계 정보를 제공한다.

vDisk 및 다양한 I/O 상세 정보는 다음 그림과 같다.

2009 Page - NFS Slave - vDisk Stats
Figure 14-5. 2009 페이지 - NFS 슬레이브 - vDisk 통계 (2009 Page - NFS Slave - vDisk Stats)
Note
Pro tip

잠재적인 성능 이슈를 확인하기 위해서는 다음과 같은 정보를 참조한다.

  1. 평균 레이턴시 (Average latency)
  2. 평균 오퍼레이션 사이즈 (Average op size)
  3. 평균 미처리 개수 (Average outstanding)

보다 상세한 정보는 vdisk_stats 페이지를 참조한다.

2009/vdisk_stats 페이지 사용하기

2009 vdisk_stats 페이지는 vDisk에 대한 보다 상세한 정보를 제공하는데, 무작위성(Randomness), 레이턴시 막대 그래프, I/O 사이즈, Working Set 상세 정보 등과 같은 아이템의 상세 정보 및 막대 그래프를 포함한다.

왼쪽 컬럼에서 “vDisk ID”를 클릭하면 vdisk_stats 페이지로 이동할 수 있다.

vDisk ID에 대한 상세 정보는 다음 그림과 같다.

2009 Page - Hosted vDisks
Figure 14-6. 2009 페이지 - 호스트된 vDisks (2009 Page - Hosted vDisks)

vdisk_stats 페이지는 상세한 vDisk 통계 정보를 제공한다. NOTE: 상기 페이지에서 정보는 실시간으로 제공되며, 페이지 갱신을 통해 데이터를 갱신할 수 있다.

첫 번째 영역은 “Ops and Randomness” 섹션으로 I/O 패턴이 랜덤인지 순차인지를 보여준다.

“Ops and Randomness” 섹션 정보는 다음 그림과 같다.

2009 Page - vDisk Stats - Ops and Randomness
Figure 14-7. 2009 페이지 - vDisks 통계 - Ops and Randomness (2009 Page - vDisk Stats - Ops and Randomness)

다음 섹션에서는 프론트엔드 읽기 및 쓰기 I/O 레이턴시(VM/OS가 보는 레이턴시) 정보를 제공한다.

“프론트엔드 읽기 레이턴시” 막대 그래프은 다음 그림과 같다.

2009 Page - vDisk Stats - Frontend Read Latency
Figure 14-8. 2009 페이지 - vDisks 통계 - 프론트엔드 읽기 레이턴시 (2009 Page - vDisk Stats - Frontend Read Latency)

“프론트엔드 쓰기 레이턴시” 막대 그래프은 다음 그림과 같다.

2009 Page - vDisk Stats - Frontend Write Latency
Figure 14-9. 2009 페이지 - vDisks 통계 - 프론트엔드 쓰기 레이턴시 (2009 Page - vDisk Stats - Frontend Write Latency)

다음 주요 영역은 I/O 사이즈 분포로 읽기 및 쓰기 I/O 사이즈 막대 그래프 정보를 제공한다.

“읽기 사이즈 분포”는 다음 그림과 같다.:

2009 Page - vDisk Stats - Read I/O Size
Figure 14-10. 2009 페이지 - vDisks 통계 - 읽기 I/O 사이즈 (2009 Page - vDisk Stats - Read I/O Size)

“쓰기 사이즈 분포”는 다음 그림과 같다.

2009 Page - vDisk Stats - Write I/O Size
Figure 14-11. 2009 페이지 - vDisks 통계 - 쓰기 I/O 사이즈 (2009 Page - vDisk Stats - Write I/O Size)

다음 주요 영역은 “Working Set Size” 섹션으로 최근 2분 및 1시간 동안의 Working Set Size에 대한 정보를 제공한다. 이것은 읽기 및 쓰기 I/O로 세분화된다.

“Working Set Size” 테이블은 다음과 같다.

2009 Page - vDisk Stats - Working Set
Figure 14-12. 2009 페이지 - vDisks 통계 - Working Set (2009 Page - vDisk Stats - Working Set)

“읽기 소스(Read Source)”는 어느 티어 또는 어느 위치에서 읽기 I/O가 서비스 되었는지에 대한 상세 정보를 제공한다.

“읽기 소스(Read Source)” 상세 정보는 다음과 같다.

2009 Page - vDisk Stats - Read Source
Figure 14-13. 2009 페이지 - vDisks 통계 - 읽기 소스 (2009 Page - vDisk Stats - Read Source)
Note
Pro tip

만약 읽기 레이턴시가 높은 경우에 vDisk에 대한 읽기 소스를 살펴보고 읽기 I/O가 어디에서 서비스되고 있는지를 확인한다. 대부분의 경우에 높은 레이턴시는 읽기가 HDD(Estore HDD)에서 수행될 때 발생한다.

“Write Destination” 섹션은 새로운 쓰기 I/O가 어디에서 발생하는지에 대한 정보를 제공한다.

“Write Destination” 테이블은 다음과 같다.

2009 Page - vDisk Stats - Write Destination
Figure 14-14. 2009 페이지 - vDisks 통계 - Write Destination (2009 Page - vDisk Stats - Write Destination)
Note
Pro tip

랜덤 또는 64K 이하의 I/O는 OpLog에 쓴다. 큰 또는 순차 I/O는 OpLog를 바이패스 하여 직접적으로 익스텐트 스토어에 쓴다.

다른 중요한 정보는 무슨 데이터가 ILM을 통해 HDD에서 SSD로 마이그레이션 되는가 이다. “Extent Group Up-Migration” 테이블은 최근 300, 3600, 86400초 동안에 HDD로부터 SSD로 마이그레이션된 데이터 정보를 제공한다.

'Extent Group Up-Migration' 테이블은 다음 그림과 같다.

2009 Page - vDisk Stats - Extent Group Up-Migration
Figure 14-15. 2009 페이지 – vDisks 통계 – Extent Group Up-Migration (2009 Page - vDisk Stats - Extent Group Up-Migration)

2010 페이지 사용하기 (큐레이터)

2010 페이지는 큐레이터 맵리듀스 프레임워크(Curator MapReduce Framework)의 모니터링을 위한 상세 페이지로, 잡(Jobs), 스캔(Scan) 및 관련된 태스크(Task)에 대한 상세 정보를 제공한다.

큐레이터 페이지는 http://<CVM IP>:2010로 액세스 할 수 있다. NOTE: 만약 큐레이터 마스터에 있지 않은 경우에는 “큐레이터 마스터(Curator Master)” 링크를 클릭한다.

TOP 페이지는 가동시간(Uptime), 빌드 버전 등과 같은 큐레이터 마스터에 대한 상세 정보를 제공한다.

다음 섹션은 “큐레이터 노드(Curator Nodes)” 페이지로 클러스터 노드, 역할, 헬스 상태 등과 같은 상세 정보를 제공한다. 이것은 큐레이터가 분산 프로세싱 및 태스크 위임 등을 위해 사용하는 노드들이다.

“큐레이터 노드” 테이블을 다음과 같다.

2010 Page - Curator Nodes
Figure 14-16. 2010 페이지 - 큐레이터 노드 (2010 Page - Curator Nodes)

다음 섹션은 “큐레이터 잡(Curator Jobs)” 페이지로 종료된 또는 현재 진행중인 잡(Jobs)에 대한 정보를 제공한다.

두 가지 유형의 잡(Job)이 있는데, 하나는 부분 스캔(Partial Scan)으로 매 60분 마다 수행되고, 다른 하나는 전체 스캔(Full Scan)으로 매 6시간 마다 수행된다. NOTE: 부분 스캔 및 전체 스캔 시작 시간은 사용률 및 다른 액티비티에 따라 가변적이다.

큐레이터 스캔 작업은 주기적인 스케줄에 의해 수행되지만, 특정 클러스터 이벤트에 의해 트리거 될 수도 있다.

잡 실행(Job Execution)을 위한 몇 가지 이유는 다음과 같다.

  • 주기적인 실행 (정상 상태)
  • 디스크 / 노드 / 블록 장애
  • ILM 불균형 (ILM Imbalance)
  • 디스크 / 티어 불균형 (Disk/Tier Imbalance)

“큐레이터 잡(Curator Jobs)” 테이블은 다음과 같다.

2010 Page - Curator Jobs
Figure 14-17. 2010 페이지 - 큐레이터 잡 (2010 Page - Curator Jobs)

각 잡에 의해 수행된 액티비티 정보는 다음 테이블과 같다.

액티비티 전체 스캔 (Full Scan) 부분 스캔 (Partial Scan)
ILM X X
디스크 밸런싱 (Disk Balancing) X X
데이터 압축 (Compression) X X
데이터 중복제거 (Deduplication) X  
Erasure Coding X  
쓰레기 청소 (Garbage Cleanup) X  

“Execution ID”를 클릭하면 다양한 잡(Job) 통계뿐만 아니라 생성된 태스크 등과 같은 잡(Job)과 관련된 상세 정보를 제공하는 페이지로 이동한다.

페이지의 맨 위에 있는 테이블은 잡(Job)과 관련된 유형(Type), 이유(Reason), 태스크(Task) 및 수행시간(Duration) 등을 포함한 상세 정보를 제공한다.

다음 섹션은 “백그라운드 태스크 통계(Background Task Stats)” 테이블로 태스크 유형, 생성된 수량, 우선순위 등과 같은 상세 정보를 제공한다.

다음 그림은 잡(Job)의 상세 정보를 보여준다.

2010 Page - Curator Job - Details
Figure 14-18. 2010 페이지 - 큐레이터 잡 - 상세 정보 (2010 Page - Curator Job - Details)

“백그라운드 태스크 통계(Background Task Stats)” 테이블을 다음과 같다.

2010 Page - Curator Job - Tasks
Figure 14-19. 2010 페이지 – 큐레이터 잡 – 태스크 (2010 Page - Curator Job - Tasks)

다음 섹션은 “맵리듀스 잡(MapReduce Jobs)” 테이블로 각 큐레이터 잡에 의해 시작된 실제 맵리듀스 잡에 대한 정보를 제공한다. 부분 스캔은 1개의 맵리듀스 잡을 가지고, 전체 스캔은 4개의 맵리듀스 잡을 갖는다.

“맵리듀스 잡(MapReduce Jobs)” 테이블은 다음과 같다.

2010 Page - MapReduce Jobs
Figure 14-20. 2010 페이지 - 맵리듀스 잡 (2010 Page - MapReduce Jobs)

“Job ID”를 클릭하면 맵리듀스 잡 상세 정보 페이지로 이동하는데, 태스크 상태, 맵리듀스 잡에 대한 다양한 카운터 및 상세 정보를 제공한다.

다음 그림은 잡 카운터(Job Counters)의 일부 정보이다.

2010 Page - MapReduce Job - Counters
Figure 14-21. 2010 페이지 - 맵리듀스 잡 - 카운터 ( 2010 Page - MapReduce Job - Counters)

메인 페이지에서 다음 섹션은 “Queued Curator Jobs” 및 “Last Successful Curator Scans” 섹션이다. 이들 테이블은 언제 주기적인 스캔 작업이 수행되는지, 그리고 최종적으로 성공한 스캔 작업에 대한 상세 정보를 제공한다.

“Queued Curator Jobs” 및 “Last Successful Curator Scans” 섹션에서 제공하는 정보는 다음 그림과 같다.

2010 Page - Queued and Successful Scans
Figure 14-22. 2010 페이지 - 대기 및 성공한 스캔 (2010 Page - Queued and Successful Scans)

고급 CLI 정보

프리즘은 일반적인 장애처리 및 성능 모니터링 이슈와 관련된 모든 필요한 정보를 제공한다. 그러나 상기에서 언급된 백앤드 페이지 또는 CLI로 제공되는 좀 더 상세한 정보가 필요한 경우가 있을 수 있다.

vdisk_config_printer

vdisk_config_printer 명령어는 클러스터에 존재하는 모든 vDisk 정보의 목록을 출력한다.

중요한 정보는 다음과 같다.

  • Vdisk ID
  • Vdisk name
  • Parent vdisk ID (if clone or snapshot)
  • Vdisk size (Bytes)
  • Container id
  • To remove bool (to be cleaned up by curator scan)
  • Mutability state (mutable if active r/w vdisk, immutable if snapshot)

vdisk_config_printer 명령어의 실행 결과는 다음과 같다.

nutanix@NTNX-13SM35210012-A-CVM:~$ vdisk_config_printer | more ... vdisk_id: 1014400 vdisk_name: "NFS:1314152" parent_vdisk_id: 16445 vdisk_size: 40000000000 container_id: 988 to_remove: true creation_time_usecs: 1414104961926709 mutability_state: kImmutableSnapshot closest_named_ancestor: "NFS:852488" vdisk_creator_loc: 7 vdisk_creator_loc: 67426 vdisk_creator_loc: 4420541 nfs_file_name: "d12f5058-f4ef-4471-a196-c1ce8b722877" may_be_parent: true parent_nfs_file_name_hint: "d12f5058-f4ef-4471-a196-c1ce8b722877" last_modification_time_usecs: 1414241875647629 ...

vdisk_usage_printer -vdisk_id=<VDISK ID>

vdisk_usage_printer 명령어는 vDisk 및 vDisk의 extents and egtroups에 대한 상세 정보를 제공한다.

중요한 필드는 다음과 같다.

  • Egroup ID
  • Egroup extent count
  • Untransformed egroup size
  • Transformed egroup size
  • Transform ratio
  • Transformation type(s)
  • Egroup replica locations (disk/cvm/rack)

vdisk_usage_printer 명령어의 실행 결과는 다음과 같다.

nutanix@NTNX-13SM35210012-A-CVM:~$ vdisk_usage_printer -vdisk_id=99999 Egid # eids UT Size T Size ... T Type Replicas(disk/svm/rack) 1256878 64 1.03 MB 1.03 MB ... D,[73 /14/60][184108644 /184108632/60] 1256881 64 1.03 MB 1.03 MB ... D,[73 /14/60][152 /7/25] 1256883 64 1.00 MB 1.00 MB ... D,[73 /14/60][184108642 /184108632/60] 1055651 4 4.00 MB 4.00 MB ... none[76 /14/60][184108643 /184108632/60] 1056604 4 4.00 MB 4.00 MB ... none[74 /14/60][184108642 /184108632/60] 1056605 4 4.00 MB 4.00 MB ... none[73 /14/60][152 /7/25] ...

NOTE: 중복제거된 또는 중복제거 되지 않은 egroups (1 vs 4MB)에 대한 egroup size에 주의하여야 한다. “데이터 구조” 섹션에서 언급한 바와 같이 데이터 중복제거된 경우에 데이터 중복제거에 의해 발생되는 잠재적인 프래그멘테이션을 상쇄하기 위해 1MB egroup size가 선호된다.

curator_cli display_data_reduction_report

curator_cli display_data_reduction_report 명령어는 컨테이너 별로 클론, SNAP, 데이터 중복제거, 데이터 압축, Erasure Coding 등의 기능 적용에 따른 스토리지 용량 절감과 관련된 상세한 정보를 제공한다.

중요 필드는 다음과 같다.

  • Container ID
  • Technique (transform applied)
  • Pre reduction Size
  • Post reduction size
  • Saved space
  • Savings ratio

curator_cli display_data_reduction_report 명령어의 실행 결과는 다음과 같다.

nutanix@NTNX-13SM35210012-A-CVM:99.99.99.99:~$ curator_cli display_data_reduction_report Using curator master: 99.99.99.99:2010 E0404 13:26:11.534024 26791 rpc_client_v2.cc:676] RPC connection to 127.0.0.1:9161 was reset: Shutting down Using execution id 68188 of the last successful full scan +--------------------------------------------------------------------------------------+ | Container Id | Technique | Pre Reduction | Post Reduction | Saved | Ratio | +--------------------------------------------------------------------------------------+ | 988 | Clone | 4.88 TB | 2.86 TB | 2.02 TB | 1.70753 | | 988 | Snapshot | 2.86 TB | 2.22 TB | 656.92 GB | 1.28931 | | 988 | Dedup | 2.22 TB | 1.21 TB | 1.00 TB | 1.82518 | | 988 | Compression | 1.23 TB | 1.23 TB | 0.00 KB | 1 | | 988 | Erasure Coding | 1.23 TB | 1.23 TB | 0.00 KB | 1 | | 26768753 | Clone | 764.26 GB | 626.25 GB | 138.01 GB | 1.22038 | | 26768753 | Snapshot | 380.87 GB | 380.87 GB | 0.00 KB | 1 | | 26768753 | Dedup | 380.87 GB | 380.87 GB | 0.00 KB | 1 | | 26768753 | Compression | 383.40 GB | 383.40 GB | 0.00 KB | 1 | | 26768753 | Erasure Coding | 383.40 GB | 245.38 GB | 138.01 GB | 1.56244 | | 84040 | Clone | 843.53 GB | 843.53 GB | 0.00 KB | 1 | | 84040 | Snapshot | 741.06 GB | 741.06 GB | 0.00 KB | 1 | | 84040 | Dedup | 741.06 GB | 741.06 GB | 0.00 KB | 1 | | 84040 | Compression | 810.44 GB | 102.47 GB | 707.97 GB | 7.9093 | ... +---------------------------------------------------------------------------------------------+ | Container Id | Compression Technique | Pre Reduction | Post Reduction | Saved | Ratio | +---------------------------------------------------------------------------------------------+ | 84040 | Snappy | 810.35 GB | 102.38 GB | 707.97 GB | 7.91496 | | 6853230 | Snappy | 3.15 TB | 1.09 TB | 2.06 TB | 2.88713 | | 12199346 | Snappy | 872.42 GB | 109.89 GB | 762.53 GB | 7.93892 | | 12736558 | Snappy | 9.00 TB | 1.13 TB | 7.87 TB | 7.94087 | | 15430780 | Snappy | 1.23 TB | 89.37 GB | 1.14 TB | 14.1043 | | 26768751 | Snappy | 339.00 MB | 45.02 MB | 293.98 MB | 7.53072 | | 27352219 | Snappy | 1013.88 MB | 90.32 MB | 923.55 MB | 11.2253 | +---------------------------------------------------------------------------------------------+

curator_cli get_vdisk_usage lookup_vdisk_ids=<COMMA SEPARATED VDISK ID(s)>

curator_cli get_vdisk_usage lookup_vdisk_ids 명령어는 vDisk 별로 클론, SNAP, 데이터 중복제거, 데이터 압축, Erasure Coding 등의 기능 적용에 따른 스토리지 용량 절감과 관련된 상세한 정보를 제공한다.

중요 필드는 다음과 같다.

  • Vdisk ID
  • Exclusive usage (Data referred to by only this vdisk)
  • Logical uninherited (Data written to vdisk, may be inherited by a child in the event of clone)
  • Logical dedup (Amount of vdisk data that has been deduplicated)
  • Logical snapshot (Data not shared across vdisk chains)
  • Logical clone (Data shared across vdisk chains)

curator_cli get_vdisk_usage lookup_vdisk_ids 명령어의 실행 결과는 다음과 같다.

Using curator master: 99.99.99.99:2010 VDisk usage stats: +------------------------------------------------------------------------------------------------------+ | VDisk Id | Exclusive usage | Logical Uninherited | Logical Dedup | Logical Snapshot | Logical Clone | +------------------------------------------------------------------------------------------------------+ | 254244142 | 596.06 MB | 529.75 MB | 6.70 GB | 11.55 MB | 214.69 MB | | 15995052 | 599.05 MB | 90.70 MB | 7.14 GB | 0.00 KB | 4.81 MB | | 203739387 | 31.97 GB | 31.86 GB | 243.09 MB | 0.00 KB | 4.72 GB | | 22841153 | 147.51 GB | 147.18 GB | 0.00 KB | 0.00 KB | 0.00 KB | ...

curator_cli get_egroup_access_info

curator_cli get_egroup_access_info 명령어는 (read) / modify ([over] write) 등과 같은 최종 액세스에 기반하여 각 bucket의 egroups 수에 대한 성세한 정보를 제공한다. 본 정보는 Erasure Coding의 적용 대상이 되는 egroups의 개수를 추정하는데 사용된다.

중요한 필드는 다음과 같다.

  • Container ID
  • Access \ Modify (secs)

curator_cli get_egroup_access_info 명령어의 실행 결과는 다음과 같다.

Using curator master: 99.99.99.99:2010 Container Id: 988 +----------------------------------------------------------------------------------------------------------------------------------------+ | Access \ Modify (secs) | [0,300) | [300,3600) | [3600,86400) | [86400,604800) | [604800,2592000) | [2592000,15552000) | [15552000,inf) | +----------------------------------------------------------------------------------------------------------------------------------------+ | [0,300) | 345 | 1 | 0 | 0 | 0 | 0 | 0 | | [300,3600) | 164 | 817 | 0 | 0 | 0 | 0 | 0 | | [3600,86400) | 4 | 7 | 3479 | 7 | 6 | 4 | 79 | | [86400,604800) | 0 | 0 | 81 | 7063 | 45 | 36 | 707 | | [604800,2592000) | 0 | 0 | 15 | 22 | 3670 | 83 | 2038 | | [2592000,15552000) | 1 | 0 | 0 | 10 | 7 | 35917 | 47166 | | [15552000,inf) | 0 | 0 | 0 | 1 | 1 | 3 | 144505 | +----------------------------------------------------------------------------------------------------------------------------------------+ ...

Book of AHV

아키텍처

노드 아키텍처

AHV 배포에서 컨트롤러 VM(CVM)은 VM으로 실행되고 디스크는 PCI 패스스루를 사용하여 제공된다. 이것은 전체 PCI 컨트롤러(장착된 디스크 포함)가 하이퍼바이저를 바이패스 하여 직접적으로 CVM으로 전달(Pass-through) 되게 한다. 아크로폴리스 하이퍼바이저는 CentOS KVM을 기반으로 한다. 게스트 VM을 지원하기 위해 전체 하드웨어 가상화(Full Hardware Virtualization)를 사용한다(HVM).

AHV Node
Figure 13-1. AHV 노드 (AHV Node)

AHV는 CentOS KVM 기반으로 구현되었으며, KVM의 기본 기능을 확장하여 HA, 라이브 마이그레이션 등과 같은 기능을 포함한다.

AHV는 Microsoft Server Virtualization Validation Program 인증을 받았으며, Microsoft OS 및 애플리케이션 실행과 관련된 인증을 획득하였다.

KVM 아키텍처

KVM은 다음과 같은 컴포넌트로 구성되어 있다.

  • KVM-kmod
    • KVM 커널 모듈
  • Libvirtd
    • API로서, KVM 및 QEMU 관리를 위한 관리 도구이자 대몬(Daemon)이다. 아크로폴리스와 KVM/QEMU간의 통신은 libvirtd를 통해 이루어진다.
  • Qemu-kvm
    • 모든 VM(도메인)을 위해 유저 스페이스(User Space)에서 실행하는 머신 에뮬레이터(Machine Emulator) 및 버츄얼라이저(Virtualizer)이다. AHV에서 하드웨어 지원 가상화(Hardware-assisted Virtualization)에 사용되며, VM은 HVM으로 실행된다.

KVM 컴포넌트들간의 관계는 다음 그림과 같다.

KVM Component Relationship
Figure 13-2. KVM 컴포넌트들간의 관계 (KVM Component Relationship)

아크로폴리스와 KVM간의 통신은 Libvirt를 통해 이루어진다.

Note
프로세서 세대 호환성 (Processor Generation Compatibility)

VM을 다른 프로세서 세대들간의 이동을 가능하게 하는 VMware의 EVC(Enhanced vMotion Capability)와 유사하게, AHV는 클러스터에서 가장 오래된 프로세서 세대를 결정하고, 모든 QEMU 도메인을 해당 레벨로 제약한다. 이를 통해 AHV 클러스터에서 프로세서 세대들의 혼합을 가능하게 하고 호스트들간의 라이브 마이그레이션을 보장한다.

설정 최대값 및 확장성

설정 최대값 및 확장성 제약은 다음과 같다.

  • 최대 클러스터 사이즈: N/A – 뉴타닉스 클러스터 사이즈와 동일
  • VM 당 최대 vCPU 개수: 호스트 당 물리 코어의 개수
  • VM 당 최대 메모리: 4TB와 노드의 가용한 물리 메모리 용량 중의 최소값
  • 최대 가상 디스크 사이즈: 9EB* (Exabyte)
  • 호스트 당 최대 VM의 개수: N/A – 메모리에 의해 제약됨
  • 클러스터 당 최대 VM의 개수: N/A – 메모리에 의해 제약됨

*AHV는 ESXi 및 Hyper-V와 같이 전통적인 스토리지 스택을 갖지 않고, 모든 디스크는 원시 SCSI 블록 디바이스로 VM에 전달된다. 이것은 최대 가상 디스크 사이즈가 DSF vDisk 사이즈(9 Exabytes)에 의해 제한된다는 것을 의미한다.

네트워킹

AHV는 모든 VM 네트워킹을 위해 OVS(Open vSwitch)를 사용한다. VM 네트워킹은 프리즘/aCLI를 통해 설정되고, 각 VM NIC은 TAP 인터페이스로 연결된다.

OVS 아키텍처의 개념적 다이어그램은 다음과 같다.

Open vSwitch Network Overview
Figure 13-3. Open vSwitch 네트워크 개요 (Open vSwitch Network Overview)

상기 이미지에서 몇 개의 컴포넌트 유형을 볼 수 있다.

Open vSwitch (OVS)

OVS는 Linux 커널에 구현된 오픈 소스 소프트웨어 스위치로 다중 서버 가상화 환경에서 동작하도록 설계되었다. 기본적으로 OVS는 Layer-2 러닝 스위치와 같이 동작하며 MAC 주소 테이블을 유지한다. 하이퍼바이저 호스트와 VM은 스위치의 가상 포트에 연결된다.

OVS는 VLAN 태킹(VLAN tagging), LACP(Link Aggregation Control Protocol), 포트 미러링(Port Mirroring), QoS(Quality of Service) 등과 같은 많은 스위치 기능을 지원한다. 각 AHV 서버는 OVS 인스턴스를 유지하며, 모든 OVS 인스턴스는 하나의 논리 스위치를 구성하기 위해 결합된다. 브릿지(Bridge)로 불리는 컨스트럭트는 AHV 호스트에 존재하는 스위치 인스턴스를 관리한다.

브릿지 (Bridge)

브릿지(Bridge)는 물리 스위치와 가상 네트워크 인터페이스간의 네트워크 트래픽을 관리하는 가상 스위치 역할을 한다. 디폴트 AHV 설정은 br0로 명명된 OVS 브릿지와 virbr0로 명명된 네이티브 Linux 브릿지를 포함된다. 네이티브 Linux 브릿지인 virbr0는 CVM과 AHV 호스트간의 관리 및 스토리지 통신을 담당한다. 다른 모든 스토리지, 호스트 및 VM 네트워크 트래픽은 OVS 브릿지인 br0를 통해 전달된다. AHV 호스트, VM 및 물리 인터페이스는 브리지와의 연결을 위해 "포트(Ports)"를 사용한다.

포트 (Port

포트(Port)는 가상 스위치와의 연결을 위해 브릿지에서 생성된 논리 컨스트럭트이다. 뉴타닉스는 내부(Interal), 탭(Tap), VXLAN, 본드(Bond) 등과 같은 여러 가지 유형의 포트를 사용한다.

  • 내부 포트(Internal Port)는 - 디폴트 브릿지와 동일한 이름(br0)을 가짐 - AHV 호스트에 대한 액세스를 제공한다.
  • 탭 포트(Tap Port)는 VM에 제공되는 가상 NIC과 브릿지(Bridge)를 연결하는 역할을 한다.
  • VXLAN 포트(VXLAN Port)는 아크로폴리스에서 제공하는 IP 주소 관리 기능에 사용된다.
  • 본드된 포트(Bonded Port)는 AHV 호스트의 물리적 인터페이스에 대한 NIC 티밍(NIC Teaming) 구성을 위해 사용한다.
본드 (Bond)

본드된 포트(Bonded Port)는 AHV 호스트의 물리적 인터페이스를 묶는(Aggregate) 데 사용한다. 디폴트로, br0-up으로 명명된 본드가 br0 브릿지에 만들어진다. 노드 이미징 프로세스 후에 모든 인터페이스는 한 개의 본드에 배치되는데, 이것은 파운데이션 이미징 프로세스의 요구사항이다. 디폴트 본드인 br0-up의 이름을 변경하면 종종 bond0라는 이름으로 바뀐다. 뉴타닉스는 브릿지 br0 업링크 인터페이스를 빠르게 식별할 수 있도록 "br0-up" 이름의 사용을 권장한다.

OVS 본드(OVS Bond)는 active-backup, balance-slb, balance-tcp 등과 같은 여러 종류의 로드 밸런싱 모드(Load-Balancing Modes)를 지원한다. 본드에서 LACP 활성화를 지원한다. 설지 중에 "bond_mode" 설정이 지정되지 않기 때문에, 디폴트는 active-backup이며, 이것이 권장 모드이다.

업링크 로드 밸런싱

이전 섹션에서 간략히 언급했듯이 본드 업링크(Bond Uplink)를 통해 트래픽을 조정할 수 있다.

본드 모드(Bond Mode)는 다음과 같다.

  • active-backup
    • 디폴트 설정으로 모든 트래픽을 하나의 액티브 어댑터를 통해 전송한다. 만약 액티브 어댑터가 가용하지 않게 되면, 본드 내의 다른 어댑터가 액티브로 된다. 처리량이 단일 NIC 대역폭으로 제한된다(권장 모드).
  • balance-slb
    • 본드 어댑터(Bond Adaptor)에서 각 VM NIC을 기준으로 밸런싱한다(e.g. VM A nic 1 - eth0 / nic 2 - eth1). VM 당 NIC 처리량을 단일 NIC의 대역폭으로 제한하지만, x개의 NIC을 갖는 VM은 x*어댑터 만큼의 대역폭을 활용할 수 있다(x는 VM NIC 수와 본드 내의 물리 어댑터 수가 같다고 가정) NOTE: 멀티캐스트 트래픽에 대한 주의 사항이 있다.
  • balance-tcp / LACP
    • 본드 어댑터(Bond Adaptor)에서 각 VN NIC의 TCP 세션을 기준으로 밸런싱한다. NIC 당 처리량은 최대 본드 대역폭(물리적 업링크 어댑터 수 * 속도)으로 제한된다. Link Aggregation이 필요하며 LACP가 필요할 때 사용된다.

본드에 대한 추가적인 정보는 AHV 네트워킹 가이드 문서 참조: (LINK).

VM NIC 유형

AHV는 다음과 같은 VM 네트워크 인터페이스 유형을 지원한다.

  • 액세스 (Access) - 디폴트
  • 트렁크 (Trunk) - AOS 4.6 이상

디폴트로 VM NIC은 액세스(Access) 인터페이스(포트 그룹의 VM NIC에서 볼 수있는 것과 유사)로 생성되지만, 트렁크(Trunked) 인터페이스를 VM의 OS까지 노출하는 것이 가능하다. 트렁크로 설정된 NIC은 프라이머리 VLAN을 언태그드(Untagged)로 전송하고, 모든 추가 VLAN을 VM의 동일 vNIC에 태그(Tags)로 보낸다. 이것은 vNIC를 추가하지 않고 여러 네트워크를 VM에 할당하는 데 유용하다.

트렁크 인터페이스는 다음의 명령어로 추가할 수 있다.

vm.nic_create <VM_NAME> vlan_mode=kTrunked trunked_networks=<ALLOWED_VLANS> network=<NATIVE_VLAN>

예제:

vm.nic_create fooVM vlan_mode=kTrunked trunked_networks=10,20,30 network=vlan.10

서비스 체인

AHV 서비스 체인(AHV Service Chaining)은 모든 트래픽을 중간에서 가로채어, 네트워크 경로의 일부로 투명하게 패킷 프로세서(NFV, 어플라이언스, 가상 어플라이언스 등)로 전달하는 기능을 제공한다.

일반적으로 서비스 체인은 다음과 같은 경우에 사용할 수 있다.

  • 방화벽 (e.g. Palo Alto 등)
  • 로드 밸런서 (e.g. F5, NetScaler 등)
  • IDS/IPS/네트워크 모니터 (e.g. 패킷 캡처)

서비스 체인 내에서 다음과 같은 2가지 종류의 패킷 프로세스를 지원한다.

Service chain - Packet Processors
Figure. 서비스 체인 – 패킷 프로세서 (Service chain - Packet Processors)
  • 인라인 패킷 프로세서 (Inline packet processor)
    • OVS에서 패킷을 인라인으로 가로챈다.
    • 패킷을 “변경(Modify) / 허용(Allow) / 거부(Deny)” 할 수 있다.
    • 일반적인 활용 예: 방화벽 및 로드 밸런서
  • 탭 패킷 프로세서 (Tap packet processor)
    • 패킷을 검사한다. 패킷을 도청하는 것이므로 읽기 전용이다.
    • 일반적인 활용 예: IDS / IPS / 네트워크 모니터

모든 서비스 체인 기능은 플로우 - 마이크로세그멘테이션 규칙(Flow - Microsegmentation Rules)이 적용된 후에, 패킷이 로컬 OVS를 떠나기 전에 수행된다. 이것은 네트워크 기능 브리지(Network Function Bridge: br.nf)에서 발생한다.

Service Chain - Flow
Figure. 서비스 체인 – 플로우 (Service Chain - Flow)

NOTE: 단일 체인에서 여러 개의 NFV/패킷 프로세서를 함께 묶을 수 있다.

동작 방식

스토리지 I/O 경로

AHV는 ESXi 또는 Hyper-V와 같이 전통적인 스토리지 스택을 사용하지 않는다. 모든 디스크는 원시 SCSI 블록 디바이스(Raw SCSI Block Devices)로 VM에 전달함으로써 I/O 경로를 경량화된 최적의 상태로 유지한다.

Note
Note

아크로폴리스는 최종 사용자로부터 KVM, VIRSH, QEMU, LIBBIRT, iSCSI를 추상화하고, 모든 백엔드 설정을 처리한다. 이렇게 함으로써 사용자가 보다 높은 수준의 작업(프리즘 또는 ACLI를 통한 VM 관리 등)에 집중할 수 있도록 한다. 다음에 제공되는 기능은 단지 정보 제공 목적이므로, VIRSH, LBVIRT 등과 같은 명령어를 직접 사용할 것을 권고하는 것은 아니다.

각 AHV 호스트는 iSCSI 리다이렉터 대몬을 가지는데, NOP OUT 명령어를 이용하여 클러스터 전체의 스타게이트 헬스 상태를 모니터링 한다.

iscsi_redirector 로그(AHV 호스트의 "/var/log/"에 위치)에서 각 스타게이트 헬스 상태를 확인할 수 있다.

2017-08-18 19:25:21,733 - INFO - Portal 192.168.5.254:3261 is up ... 2017-08-18 19:25:25,735 - INFO - Portal 10.3.140.158:3261 is up 2017-08-18 19:25:26,737 - INFO - Portal 10.3.140.153:3261 is up

NOTE: 로컬 스타게이트는 192.168.5.254 내부 주소를 통해 볼 수 있다.

다음에서 iscsi_redirector가 127.0.0.1:3261에서 수신 대기하는 것을 볼 수 있다.

[root@NTNX-BEAST-1 ~]# netstat -tnlp | egrep tcp.*3261 Proto ... Local Address Foreign Address State PID/Program name ... tcp ... 127.0.0.1:3261 0.0.0.0:* LISTEN 8044/python ...

QEMU는 iSCSI 타깃 포탈(iSCSI target portal)로 iSCSI 리다이렉터와 함께 설정된다. 로그인 요청 시에, 리다이렉터는 iSCSI 로그인을 정상 동작중인 스타게이트로 리다이렉트 한다(로컬 스타게이트가 우선순위를 가짐).

iSCSI Multi-pathing - Normal State
Figure 13-4. iSCSI 멀티-패싱 – 정상 상태 (iSCSI Multi-pathing - Normal State)

도메인 XML 파일에서 설정 정보를 확인할 수 있다.

<devices> ... <disk type='network' device='lun'> <driver name='qemu' type='raw' cache='none' error_policy='report' io='native'/> <source protocol='iscsi' name='iqn.2010-06.com.nutanix:vmdisk-16a5../0'> <host name='127.0.0.1' port='3261'/> </source> <backingStore/> <target dev='sda' bus='scsi'/> <boot order='1'/> <alias name='scsi0-0-0-0'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> ... </devices>

선호하는 컨트롤러 유형은 virtio-scsi(SCSI 디바이스의 디폴트 유형) 이다. 대부분의 시나리오에서 IDE 디바이스(사용 가능할지라도)는 권장하지 않는다. virtio를 Windows와 함께 사용하려면 virto 드라이버, 뉴타닉스 모빌리티 드라이버(Nutanix Mobility Driver), 또는 NGT(Nutanix guest tools)를 설치하여야 한다. 최신 Linux 배포판은 virtio가 사전 설치되어 제공된다.

  

... <controller type='scsi' index='0' model='virtio-scsi'> <driver max_sectors='2048'/> <alias name='scsi0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </controller> ...

액티브 스타게이트가 다운(Down) 되면(NOP OUT 명령어에 대한 응답이 실패하면), iSCSI 리다이렉터는 로컬 스타게이트를 “비정상(Unhealthy)”으로 표시한다. QEMU가 iSCSI 로그인을 재시도할 때, 리다이렉터는 로그인을 정상 동작중인 다른 스타게이트로 리다이렉트 한다.

iSCSI Multi-pathing - Local CVM Down
Figure 13-5. iSCSI 멀티-패싱 - 로컬 CVM 다운 (iSCSI Multi-pathing - Local CVM Down)

로컬 CVM의 스타게이트가 정상 상태로 돌아오면(NOP OUT 명령어에 대한 응답을 시작하면), 원격 스타게이트는 잠시 멈춘 후에 원격 iSCSI 세션에 대한 모든 연결을 끊는다. 그리고 나서, QEMU는 iSCSI 로그인을 다시 시도하고, 로컬 스타게이트로 리다이렉트 된다.

iSCSI Multi-pathing - Local CVM Back Up
Figure 13-6. iSCSI 멀티-패싱 - 로컬 CVM 백업 (iSCSI Multi-pathing - Local CVM Back Up)

전통적인 I/O 경로

모든 하이퍼바이저 및 OS와 마찬가지로 일반적인 액티비티(Common Activity)를 수행하기 위해 상호작용하는 유저 및 커널 스페이스 컴포넌트가 혼합되어 있다. 다음을 읽기 전에, “User vs Kernel Space” 섹션을 참조하기를 권고한다.

VM이 I/O를 수행할 때 다음과 같은 과정을 거친다 (정확한 이해를 돕기 위해 일부 단계를 생략하였다).

  1. VM의 OS가 가상 디바이스를 통해 SCSI 명령어를 실행한다.
  2. virtio-scsi가 요청을 받아 게스트 메모리에 저장한다.
  3. 요청은 QEMU 메인 루프에 의해 처리된다.
  4. Libiscsi는 각 요청을 검사하고 전달한다.
  5. 네트워크 계층은 요청을 로컬 CVM으로 전달한다 (로컬 CVM이 가용하지 않으면 원격 노드의 CVM으로 전달).
  6. 스타게이트가 요청을 처리한다.

상기 단계를 그림으로 표현하면 다음과 같다.

AHV VirtIO Data Path - Classic
Figure. AHV VirtoIO 데이터 경로 – 클래식 (AHV VirtIO Data Path - Classic)

도메인 XML을 살펴보면, 전통적인 I/O 경로에서 qemu-kvm 에뮬레이터를 사용하고 있다는 것을 확인할 수 있다.

... <devices> <emulator>/usr/libexec/qemu-kvm</emulator> ...

AHV 호스트를 살펴보면, qemu-kvm이 로컬 브리지와 IP를 사용하여 정상 동작중인 스타게이트와 세션을 설정했음을 알 수 있다. 외부 통신을 위해 외부 호스트와 스타게이트 IP가 사용된다. NOTE: 디스크 디바이스 당 하나의 세션이 있다 (PID 24845 참조)

[root@NTNX-BEAST-1 log]# netstat -np | egrep tcp.*qemu Proto ... Local Address Foreign Address State PID/Program name tcp ... 192.168.5.1:50410 192.168.5.254:3261 ESTABLISHED 25293/qemu-kvm tcp ... 192.168.5.1:50434 192.168.5.254:3261 ESTABLISHED 23198/qemu-kvm tcp ... 192.168.5.1:50464 192.168.5.254:3261 ESTABLISHED 24845/qemu-kvm tcp ... 192.168.5.1:50465 192.168.5.254:3261 ESTABLISHED 24845/qemu-kvm ...

이제 이 경로에서 메인 루프가 단일 스레드이고 libiscsi가 모든 SCSI 명령을 검사하므로 몇 가지 비효율성이 존재한다.

프로도 I/O 경로 (AHV 터보 모드)

스토리지 기술이 효율적인 방향으로 지속적으로 발전하고 있다. 뉴타닉스도 마찬가지이다. 뉴타닉스는 AHV 및 뉴타닉스 스택에 대한 원천 기술을 보유하고 있으므로, 최신 스토리지 관련 기술을 지속적으로 적용하고 있다.

프로도(Frodo)는 높은 처리량, 낮은 레이턴시, 적은 CPU 오버헤드를 가능하게 하는 AHV를 위한 매우 최적화된 I/O 경로이다.

VM이 I/O를 수행할 때 다음과 같은 과정을 거친다 (정확한 이해를 돕기 위해 일부 단계를 생략하였다).

  1. VM의 OS가 가상 디바이스를 통해 SCSI 명령어를 실행한다.
  2. virtio-scsi가 요청을 받아 게스트 메모리에 저장한다.
  3. 요청은 프로도(Frodo)에 의해 처리된다.
  4. 커스터마이즈된 Libiscsi는 헤더를 추가하고 전달한다.
  5. 네트워크 계층은 요청을 로컬 CVM으로 전달한다 (로컬 CVM이 가용하지 않으면 원격 노드의 CVM으로 전달).
  6. 스타게이트가 요청을 처리한다.

상기 단계를 그림으로 표현하면 다음과 같다.

AHV VirtIO Data Path - Classic
Figure. AHV virtIO 데이터 경로 - 프로도 (AHV VirtIO Data Path - Frodo)

다음 경로는 몇 가지 주요 차이점을 제외하고는 전통적인 I/O 경로와 유사하다.

  • QEMU 메인 루프는 프로도(vhost-user-scsi)로 대체된다.
  • 프로도(Frodo)는 여러 개의 가상 큐(Virtual Queues)를 게스트에 제공한다 (vCPU 당 1개).
  • 다중 vCPU VM을 위해 다중 스레드를 활용한다.
  • Libiscsi는 훨씬 가볍고 효율적인 뉴타닉스 버전으로 대체된다.

게스트 OS 측면에서, 디스크 디바이스를 위해 여러 개의 큐가 할당된 것을 확인할 수 있으며, 이로 인해 성능이 향상되었다는 것을 확인할 수 있다. 어떤 경우에는 QEMU에 비해 I/O 처리를 위한 CPU 오버헤드가 25% 줄어들고, 성능이 최대 3배까지 향상되었다는 것을 볼 수 있다. 다른 하이퍼바이저와 비교할 때, I/O 처리를 위한 CPU 오버헤드가 최대 3배까지 떨어졌다.

AHV 호스트에서, 각 VM 당 1개의 프로도 프로세스가 실행 중인 것을 확인할 수 있다(qemu-kvm-process).

[root@drt-itppc03-1 ~]# ps aux | egrep frodo ... /usr/libexec/qemu-kvm ... -chardev socket,id=frodo0,fd=3 \ -device vhost-user-scsi-pci,chardev=frodo0,num_queues=16... ... /usr/libexec/frodo ... 127.0.0.1:3261 -t iqn.2010-06.com.nutanix:vmdisk... ...

도메인 XML에서 프로도를 사용하는 것을 확인할 수 있다.

... <devices> <emulator>/usr/libexec/frodo</emulator> ...

Note
Pro tip

프로도가 제공하는 다중 쓰레드/연결의 장점을 활용하기 위해서는, VM의 전원이 인가되었을 때 vCPU가 2개 이상 할당되어야 한다.

프로도 I/O 경로는 다음과 같은 특성을 갖는다.

  • 1 vCPU UVM
    • 디스크 디바이스 당 1개의 프로도 쓰레드/세션을 갖는다.
  • >= 2vCPU UVM
    • 디스크 디바이스 당 2개의 프로도 쓰레드/세션을 갖는다.

다음에서 프로도가 로컬 브리지와 IP를 사용하여 정상 동작중인 스타게이트와 세션을 설정했음을 알 수 있다. 외부 통신의 경우 외부 호스트와 스타게이트 IP가 사용된다.

[root@NTNX-BEAST-1 log]# netstat -np | egrep tcp.*frodo Proto ... Local Address Foreign Address State PID/Program name tcp ... 192.168.5.1:39568 192.168.5.254:3261 ESTABLISHED 42957/frodo tcp ... 192.168.5.1:39538 192.168.5.254:3261 ESTABLISHED 42957/frodo tcp ... 192.168.5.1:39580 192.168.5.254:3261 ESTABLISHED 42957/frodo tcp ... 192.168.5.1:39592 192.168.5.254:3261 ESTABLISHED 42957/frodo ...

IP 주소 관리

아크로폴리스 IP 주소 관리(IP Address Management: IPAM) 솔루션은 DHCP 범위를 설정하고, VM에 IP 주소를 할당할 수 있는 기능을 제공한다. IPAM은 DHCP 요청과 DHCP 응답을 가로채기 위해 VXLAN과 오픈플로우 규칙(OpenFlow Rule)을 사용한다.

아크로폴리스 마스터가 로컬로 실행 중인 노드에서 뉴타닉스 IPAM 솔루션을 이용한 DHCP 요청은 다음 그림과 같이 처리된다.

IPAM - Local Acropolis Master
Figure 13-7. IPAM - 로컬 아크로폴리스 마스터 (IPAM - Local Acropolis Master)

만약 아크로폴리스 마스터가 원격에서 실행 중인 경우에는, 네트워크를 통한 요청을 처리하기 위해 동일 VXLAN 터널(VXLAN Tunnel)을 사용한다.

IPAM - Remote Acropolis Master
Figure 13-8. IPAM - 원격 아크로폴리스 마스터 (IPAM - Remote Acropolis Master)

관리되지 않는 네트워크(Unmanaged Network) 시나리오에서 전통적인 DHCP/IPAM 솔루션을 사용할 수 있다.

VM HA

AHV VM HA는 호스트 또는 블록 장애 시에 VM의 가용성을 보장하는 기능이다. 호스트 장애 시에, 이전에 해당 호스트에서 실행중이던 VM은 클러스터의 정상 동작중인 다른 노드에서 재기동된다. 아크로폴리스 마스터는 정상 동작중인 호스트에서 VM의 재기동에 대한 책임을 갖는다.

아크로폴리스 마스터는 모든 클러스터 호스트의 libvirt에 대한 연결을 모니터링 함으로써 호스트 헬스를 추적한다.

HA - Host Monitoring
Figure 13-9. HA - 호스트 모니터링 (HA - Host Monitoring)

아크로폴리스 마스터의 분할(Partitioned), 고립(Isolated), 실패(Failed) 등의 이벤트가 발생하면, 클러스터의 정상 동작중인 노드 중의 하나가 새로운 아크로폴리스 마스터로 선정된다. 만약 클러스터가 분할되면(예를 들어, X 노드가 다른 Y 노드와 통신할 수 없는 경우), 쿼럼(Quorum)을 갖는 쪽이 정상 상태로 남아있고, VM은 해당 호스트에서 재기동된다.

VM HA를 위해 다음과 같은 2가지 모드를 지원한다.

  • 디폴트 모드 (Default Mode)
    • 설정이 필요하지 않은 모드로 AHV 기반의 뉴타닉스 클러스터가 생성되면 디폴트로 적용되는 모드이다. AHV 호스트가 가용하지 않을 경우에 장애가 발생한 호스트에서 실행 중인 VM은 나머지 호스트에서 재기동된다. 만약 나머지 호스트의 지원이 충분하지 않을 경우에는 일부 VM만이 재기동된다.
  • 보장 모드 (Guarantee Mode)
    • 설정이 필요한 모드로 클러스터의 모든 AHV 호스트의 자원을 예약하여 호스트 장애 발생 시에 모든 실패한 VM의 재기동을 보장한다. 보장 모드를 활성화하기 위해 “Manage VM High Availability” 메뉴에서 “Enable HA Reservation”을 체크한다. 보장 모드를 활성화하면 예약된 메모리 용량 및 장애 허용 가능 호스트 개수 정보를 출력한다.

자원 예약

VM HA를 위해 보장 모드를 활성화하면, 시스템은 VM을 위해 호스트 자원을 예약한다. 예약되는 자원의 용량은 다음과 같다.

  • 모든 컨테이너가 RF2인 경우 (FT1)
    • 1개 호스트에 해당하는 자원.
  • RF3 컨테이너를 포함하는 경우 (FT2)
    • 2개 호스트에 해당하는 자원.

호스트의 메모리 용량이 균일하지 않으면 시스템은 호스트 당 예약할 용량을 결정할 때 가장 큰 호스트의 메모리 용량을 사용한다.

Note
AOS 5.0 버전 이후의 자원 예약 (Post 5.0 Resource Reservations)

AOS 5.0 이전 버전에서는 호스트 및 세그먼트 기반의 자원 예약을 지원하였다. AOS 5.0 버전부터 세그먼트 기반의 자원 예약만을 지원하는데, 보장 HA 모드가 활성화되면, 자동적으로 용량 예약 작업이 진행된다.

세그먼트 예약은 클러스터의 모든 호스트에 지원 예약을 분배한다. 본 시나리오에서 각 호스트는 HA를 위해 자원의 일부를 공유한다. 이러한 과정을 통해 전체 클러스터는 호스트 장애 발생 시에 모든 VM을 재기동 할 수 있는 충분한 페일오버 용량을 갖는다.

세그먼트 예약 시나리오는 다음과 같다.

HA - Reserved Segment
Figure 13-13. HA - 세그먼트 예약 (HA - Reserved Segment)

호스트 장애 시에 VM은 클러스터의 정상 동작중인 호스트에서 재기동된다.

HA - Reserved Segment - Fail Over
Figure 13-14. HA - 세그먼트 예약 - 페일오버 (HA - Reserved Segment - Fail Over)
Note
세그먼트 예약 계산 (Reserved segments calculation)

시스템이 자동으로 세그먼트 예약 전체 개수 및 호스트 당 예약을 계산한다.

예약 용량을 찾는 문제는 Knapsack이라는 잘 알려진 문제와 유사하다. 최적해를 찾는 문제는 NP-hard(지수함수) 문제이지만, 일반적인 경우에 휴리스틱 솔루션이 최적해에 근접한 솔루션을 제공한다. 뉴타닉스는 MTHM으로 불리는 알고리즘을 구현하였으며 알고리즘을 지속적으로 개선시킬 예정이다.

관리

내용 추가 예정입니다.

중요 페이지

내용 추가 예정입니다.

명령어 참조

OVS에서만 10GbE 링크 활성화

설명: 로컬 호스트에서 bon0만을 대상으로 10g 활성화

manage_ovs --interfaces 10g update_uplinks

설명: 전체 클러스터의 OVS 10G 업링크 출력

allssh "manage_ovs --interfaces 10g update_uplinks"

OVS 업링크 출력

설명: 로컬 호스트의 OVS 업링크 출력

manage_ovs show_uplinks

설명: 전체 클러스터의 OVS 업링크 출력

allssh "manage_ovs show_uplinks"

OVS 인터페이스 출력

설명: 로컬 호스트의 OVS 인터페이스 출력

manage_ovs show_interfaces

설명: 전체 클러스터의 OVS 인터페이스 출력

allssh "manage_ovs show_interfaces"

OVS 스위치 정보 출력

설명: 스위치 정보 출력

ovs-vsctl show

OVS 브릿지 목록 출력

설명: 브릿지 목록 출력

ovs-vsctl list br

OVS 브릿지 정보 출력

설명: OVS 포트 정보 출력

ovs-vsctl list port br0
ovs-vsctl list port <bond>

OVS 인터페이스 정보 출력

설명: 인터페이스 정보 출력

ovs-vsctl list interface br0

브릿지의 포트/인터페이스 정보 출력

설명: 브릿지의 포트 정보 출력

ovs-vsctl list-ports br0

설명: 브릿지의 ifaces 정보 출력

ovs-vsctl list-ifaces br0

OVS 브릿지 생성

설명: 브릿지 생성

ovs-vsctl add-br <bridge>

브릿지에 포트 추가

설명: 브릿지에 포트 추가

ovs-vsctl add-port <bridge> <port>

설명: 브릿지에 본드 포트 추가

ovs-vsctl add-bond <bridge> <port> <iface>

OVS 본드 상세 정보 출력

설명: 본드 상세 정보 출력

ovs-appctl bond/show <bond>

예제:

ovs-appctl bond/show bond0

본드 모드 설정 및 본드에서 LACP 설정

설명: 포트에서 LACP 활성화

ovs-vsctl set port <bond> lacp=<active/passive>

설명: 모든 호스트에서 bond0 활성화

for i in `hostips`;do echo $i; ssh $i source /etc/profile > /dev/null 2>&1; ovs-vsctl set port bond0 lacp=active;done

본드에서 LACP 상세 정보 출력

설명: LACP 상세 정보 출력

ovs-appctl lacp/show <bond>

본드 모드 설정

설명: 포트에 본드 모드 설정

ovs-vsctl set port <bond> bond_mode=<active-backup, balance-slb, balance-tcp>

OpenFlow 정보 출력

설명: OVS OpenFlow 상세 정보 출력

ovs-ofctl show br0

설명: OpenFlow 규칙 출력

ovs-ofctl dump-flows br0

QEMU PIDs 및 TOP 정보 가져오기

설명: QEMU PIDs 가져오기

ps aux | grep qemu | awk '{print $2}'

설명: 특정 PID에 대한 TOP 메트릭스 정보 가져오기

top -p <PID>

QEMU 프로세스의 액티브 스타게이트 가져오기

설명: 각 QEMU 프로세스의 스토리지 I/O를 위한 액티브 스타게이트 정보 가져오기

netstat ?np | egrep tcp.*qemu

메트릭스 및 임계 값

내용 추가 예정입니다.

장애처리 및 고급 관리

iSCSI 라다이렉터 로그 체크

설명: 모든 호스트의 iSCSI 라다이렉터 Logs 체크

for i in `hostips`; do echo $i; ssh root@$i cat /var/log/iscsi_redirector;done

단일 호스트 예제:

ssh root@<HOST IP>
Cat /var/log/iscsi_redirector

CPU steal (stolen CPU) 모니터

설명: CPU steal time (stolen CPU) 모니터

TOP 명령어를 실행시키고, %st를 찾음 (아래 bold)

Cpu(s):  0.0%us, 0.0%sy,  0.0%ni, 96.4%id,  0.0%wa,  0.0%hi,  0.1%si,  0.0%st

VM 네트워크 자원 통계 모니터링

설명: VM 자원 통계 모니터링

virt-top 실행

Virt-top

네트워킹 페이지로 이동

2 - Networking

Book of vSphere

아키텍처

노드 아키텍처

ESXi 배포에서 CVM은 VM으로 실행되고 디스크는 VMDirectPath I/O를 사용하여 제공된다. 이렇게 하면 전체 PCI 컨트롤러(연결된 디바이스 포함)가 하이퍼바이저를 바이패스하여 직접적으로 CVM으로 전달된다.

ESXi Node Architecture
Figure 15-1. ESXi 노드 아키텍처 (ESXi Node Architecture)

설정 최대값 및 확장성

설정 최대값 및 확장성 제약은 다음과 같다.

  • 최대 클러스터 사이즈: 64
  • VM 당 최대 vCPU: 128
  • VM 당 최대 메모리: 4TB
  • 최대 가상 디스크 사이즈: 62TB
  • 호스트 당 최대 VM 개수: 1,024
  • 클러스터 당 최대 VM 개수: 8,000 (만약 HA가 활성화되면, 데이터스토어 당 2048)

NOTE: vSphere 6.0 기준

Note
Pro tip

ESXi 호스트에서 벤치마크 테스트를 수행할 때, ESXi 호스트의 전원 정책을 “High Performance”로 설정하여야 한다. 이는 P- 및 C- 상태를 비활성화하고 테스트 결과가 인위적으로 제한되지 않도록 한다.

네트워킹

각 ESXi 호스트는 로컬 vSwitch를 가지는데 뉴타닉스 CVM과 호스트간의 내부 호스트 통신(Intra-Host Communication)을 위해 사용된다. 외부 통신 및 VM을 위해 표준 vSwitch(디폴트) 또는 dvSwitch를 사용한다.

로컬 vSwitch(vSwitchNutanix)는 뉴타닉스 CVM과 ESXi 호스트간의 통신을 위한 것이다. 호스트는 이 vSwitch(vmk1 – 192.168.5.1)에 VMkernel 인터페이스를 가지고 있으며, CVM은 이 내부 스위치(svm-iscsi-pg - 192.168.5.2)의 포트 그룹에 바인드된 인터페이스를 갖는다. 이것이 프라이머리 스토리지 통신 경로이다.

외부 vSwitch는 표준 vSwitch 또는 dvSwitch 일 수 있다. 외부 vSwitch는 ESXi 호스트 및 CVM을 위한 외부 인터페이스뿐만 아니라 호스트의 VM에 의해 사용되는 포트 그룹을 제공한다. 외부 VMKernel 인터페이스는 호스트 관리, vMotion 등의 용도로 사용된다. 외부 CVM 인터페이스는 다른 뉴타닉스 CVM과의 통신을 위해 사용된다. 트렁크(Trunk)에서 VLAN을 사용할 수 있다고 가정하면 필요한만큼 많은 포트 그룹을 만들 수 있다.

vSwitch 아키텍처의 개념적 다이어그램은 다음과 같다.

ESXi vSwitch Network Overview
Figure. ESXi vSwitch 네트워크 개요 (ESXi vSwitch Network Overview)
Note
업링크 및 티밍 정책 (Uplink and Teaming Policy)

스위치 HA를 위해 2개의 스위치에 이중 ToR 스위치 및 업링크를 갖는 구성을 권고한다. 기본적으로 시스템에는 액티브/패시브(Active/Passive) 모드의 업링크 인터페이스가 있다. 추가적인 네트워크 처리량을 위해 액티브/액티브(Active/Active) 업링크 인터페이스 기능(e.g. vPC, MLAG, etc.)을 제공하는 업스트림 스위치를 사용할 수 있다.

동작방식

어레이 오프로드 - VAAI

뉴타닉스 플랫폼은 하이퍼바이저가 특정 작업을 어레이로 오프로드 할 수 있게 해주는 VAAI(Array Integration for VMware) API를 지원한다. 이것은 하이퍼바이저가 중간자 역할(man in the middle)을 할 필요가 없기 때문에 매우 효율적이다. 현재 뉴타닉스는 NAS를 위한 VAAI 프리미티브(VAAI primitives)를 지원하는데, 이것은 “전체 파일 클론(Full File Clone)”, “빠른 파일 클론(Fast File Clone)”, “용량 예약(Reserve Space)” 프리미티브를 포함한다. http://cormachogan.com/2012/11/08/vaai-comparison-block-versus-nas/를 방문하면, 다양한 프리미티브에 대한 설명을 참조할 수 있다.

전체 및 및 빠른 파일 클론의 경우에, DSF의 “빠른 클론(Fast Clone)”이 수행되는데, 이것은 생성된 각 클론이 ROW(Re-direct On Write)를 사용한 쓰기 가능한 스냅샷(Writable Snapshots)이라는 것을 의미한다. 이러한 클론들 각각은 자신의 블록 맵(Block Map)을 가지는데, 이것은 체인의 깊이(Chain Depth)를 걱정할 필요가 없다는 것을 의미한다. 시나리오에 대한 VAAI의 적용 여부는 다음과 같다.

  • 스냅샷을 갖는 VM 복제  →  VAAI가 사용되지 않음
  • 스냅샷을 갖지 않으면서 전원이 커진 VM 복제  →  VAAI가 사용됨
  • 다른 데이터스토어/컨테이너를 갖는 VM 복제  →  VAAI는 사용되지 않음
  • 전원이 켜진 VM 복제  →  VAAI가 사용되지 않음

VMware View인 경우에 적용되는 시나리오는 다음과 같다.

  • 뷰 풀 클론 (스냅샷을 갖는 템플릿)  →  VAAI가 사용되지 않음
  • 뷰 풀 클론 (스냅샷을 갖지 않는 템플릿)  →  VAAI가 사용됨
  • 뷰 링크드 클론 (VCAI)  →  VAAI가 사용됨

VAAI 오퍼레이션이 수행되었는지의 여부는 “NFS Adaptor” Activity Traces 페이지에서 확인할 수 있다.

CVM 자동절체

본 섹션에서 CVM 장애처리 로직을 설명한다. CVM 장애는 사용자가 CVM의 전원을 다운한 경우, CVM 롤링 업그레이드, 또는 CVM을 다운시킬 수 있는 모든 경우를 포함한다. DSF는 자동절체(Autopathing) 기능을 지원하는데, 이것은 로컬 CVM이 가용하지 않은 상태가 되었을 때, I/O가 클러스터의 다른 CVM에 의해 투명하게 처리되게 하는 기능이다. 하이퍼바이저와 CVM은 전용 vSwitch에서 사설 192.168.5.0 네트워크를 사용하여 통신한다. 이것은 모든 스토리지 I/O가 CVM의 내부 사설 IP(192.168.5.2)를 통해 수행된다는 것을 의미한다. CVM의 외부 IP는 CVM간의 통신 및 원격 복제를 위해 사용된다.

ESXi 호스트의 네트워킹은 다음 그림과 같다.

ESXi Host Networking
Figure 16-1. ESXi 호스트 네트워킹 (ESXi Host Networking)

로컬 CVM에 장애가 발생하면, 로컬 CVM에 의해 호스트된 로컬 192.168.5.2 주소는 가용하지 않게 된다. DSF는 자동으로 이러한 장애를 검출하고, 10GbE를 통해 I/O를 클러스터의 다른 CVM으로 리다이렉트 한다. 재라우팅(Re-routing)은 호스트에서 실행 중인 하이퍼바이저 및 VM에 투명하게 수행된다. 이것은 CVM의 전원이 꺼지더라도 VM은 DSF에 I/O를 지속할 수 있다는 것을 의미한다. 일단 로컬 CVM이 백업되어 가용한 상태가 되면, 트래픽은 다시 완벽하게 로컬 CVM으로 전달되어 서비스된다.

CVM 자동절체(CVM Autopathing) 기능은 다음 그림과 같다.

ESXi Host Networking - Local CVM Down
Figure 16-2. ESXi 호스트 네트워킹 - 로컬 CVM 다운 (ESXi Host Networking - Local CVM Down)

관리

중요 페이지

내용 추가 예정입니다.

명령어 참조

ESXi 클러스터 업그레이드

설명: CLI 및 커스텀 오프라인 번들을 이용하여 ESXi 호스트의 자동 업그레이드 수행
# 뉴타닉스 CVM에 업그레이드 오프라인 번들 업로드
# 뉴타닉스 CVM으로 로그인
# 업그레이드 수행

cluster --md5sum=<bundle_checksum> --bundle=</path/to/offline_bundle> host_upgrade

# 예제

cluster --md5sum=bff0b5558ad226ad395f6a4dc2b28597 --bundle=/tmp/VMware-ESXi-5.5.0-1331820-depot.zip host_upgrade

ESXi 호스트 서비스 재시작

설명: 점진적인 방법으로 각 ESXi 호스트 서비스 재시작

for i in `hostips`;do ssh root@$i "services.sh restart";done

ESXi 호스트 NIC이 “Up” 상태인 목록 출력

설명: ESXi 호스트 NIC이 “Up” 상태인 목록 출력

for i in `hostips`;do echo $i && ssh root@$i esxcfg-nics -l | grep Up;done

ESXi 호스트 10GbE NIC 및 상태 출력

설명: ESXi 호스트의 10GbE NIC과 상태 정보 출력

for i in `hostips`;do echo $i && ssh root@$i esxcfg-nics -l | grep ixgbe;done

ESXi 호스트 액티브 어댑터 출력

설명: ESXi 호스트의 액티브, 스탠바이, 사용되지 않는 어댑터 정보 출력

for i in `hostips`;do echo $i &&  ssh root@$i "esxcli network vswitch standard policy failover get --vswitch-name vSwitch0";done

ESXi 호스트 라우팅 테이블 출력

설명: ESXi 호스트의 라우팅 테이블 출력

for i in `hostips`;do ssh root@$i 'esxcfg-route -l';done

데이터스토어에서 VAAI 활성화 여부 체크

설명: 데이터스토어에서 VAAI 활성화/지원 여부 체크

vmkfstools -Ph /vmfs/volumes/<Datastore Name>

VIB 승인 레벨을 “Community Supported”로 설정

설명: 3rd 파티 VIB가 설치될 수 있도록 VIB 승인 레벨을 “Community Supported”로 설정

esxcli software acceptance set --level CommunitySupported

VIB 설치

설명: 시그너처(Signature)를 체크하지 않고 VIB 설치

esxcli software vib install --viburl=/<VIB directory>/<VIB name> --no-sig-check

# 또는

esxcli software vib install --depoturl=/<VIB directory>/<VIB name> --no-sig-check

ESXi RAMDISK 용량 체크

설명: ESXi RAMDISK의 Free Space 체크

for i in `hostips`;do echo $i; ssh root@$i 'vdf -h';done

pynfs 로그 삭제

설명: 모든 ESXi 호스트에서 pynfs 로그 삭제

for i in `hostips`;do echo $i; ssh root@$i '> /pynfs/pynfs.log';done

메트릭스 및 임계 값

내용 추가 예정입니다.

장애 처리 및 고급 관리

내용 추가 예정입니다.

Book of Hyper-V

아키텍처

뉴타닉스 Hyper-V 클러스터 생성 시에, Hyper-V 호스트를 지정된 윈도우즈 액티브 디렉토리(Windows Active Directory) 도메인에 자동으로 조인(Join) 시킨다. Hyper-V 호스트들은 VM HA를 위한 페일오버 클러스터(Failover Cluster)에 포함된다. 이 작업이 완료되면 각 개별 Hyper-V 호스트 및 페일오버 클러스터 마다 AD 오브젝트가 생성된다.

노드 아키텍처

Hyper-V 배포에서 CVM은 VM으로 실행되고, 디스크는 디스크 패스-스루(Disk Pass-through)를 사용하여 제공된다.

Hyper-V Node Architecture
Figure 18-1. Hyper-V 노드 아키텍처 (Hyper-V Node Architecture)

설정 최대값 및 확장성

설정 최대값 및 확장성 제약은 다음과 같다.

  • 최대 클러스터 사이즈: 64
  • VM 당 최대 vCPU: 64
  • VM 당 최대 메모리: 1TB
  • 최대 가상 디스크 사이즈: 64TB
  • 호스트 당 최대 VM 개수: 1,024
  • 클러스터 당 최대 VM 개수: 8,000

NOTE: Hyper-V 2012 R2 기준

네트워킹

각 Hyper-V 호스트는 내부 전용 가상 스위치(Virtual Switch)를 가지는데, 뉴타닉스 CVM과 호스트간의 내부 호스트 통신(Intra-Host Communication)을 위해 사용된다. 외부 통신 및 VM을 위해 외부 가상 스위치(External Virtual Switch: 디폴트) 또는 논리적 스위치(Logical Switch)가 사용된다.

내부 스위치(InternalSwitch)는 뉴타닉스 CVM과 Hyper-V 호스트간의 로컬 통신을 위한 것이다. 호스트는 내부 스위치(192.168.5.1)에 가상 이더넷 인터페이스(Virtual Ethernet Interface: vEth)를 가지고 있으며, CVM은 이 내부 스위치(192.168.5.2)에 vEth가 있다. 이것이 프라이머리 스토리지 통신 경로이다.

외부 vSwitch(External vSwitch)는 표준 가상 스위치(Standard Virtual Switch) 또는 논리적 스위치(Logical Switch)가 될 수 있다. 외부 vSwitch는 Hyper-V 호스트 및 CVM을 위한 외부 인터페이스뿐만 아니라 해당 호스트의 VM이 사용하는 논리 및 VM 네트워크를 제공한다. 외부 vEth 인터페이스는 호스트 관리, 라이브 마이그레이션 등을 위해 사용된다. 외부 CVM 인터페이스는 다른 뉴타닉스 CVM과의 통신을 위해 사용된다. 트렁크(Trunk)에서 VLAN을 사용할 수 있다고 가정하면 필요한만큼 많은 포트 그룹을 만들 수 있다.

가상 스위치(Virtual Switch) 아키텍처의 개념적 다이어그램은 다음과 같다.

Hyper-V Virtual Switch Network Overview
Figure. Hyper-V 가상 스위치 네트워크 개요 (Hyper-V Virtual Switch Network Overview)
Note
업링크 및 티밍 정책 (Uplink and Teaming Policy)

스위치 HA를 위해 2개의 스위치에 이중 ToR 스위치 및 업링크를 갖는 구성을 권고한다. 기본적으로 시스템은 특별한 구성을 필요로 하지 않는 스위치 독립적 모드의 LBFO 팀을 갖는다.

동작 방식

어레이 오프로드 - ODX

뉴타닉스 플랫폼은 하이퍼바이저가 특정 작업을 어레이로 오프로드 할 수 있게 해주는 Microsoft ODX(Offloaded Data Transfer)를 지원한다. 이것은 하이퍼바이저가 중간자 역할(man in the middle)을 할 필요가 없기 때문에 매우 효율적이다. 현재 뉴타닉스는 SMB ODX 프리미티브를 지원하는데, 이것은 전체 복사(Full Copy) 및 제로잉 오퍼레이션(Zeroing Operation)을 포함한다. 그러나, “빠른 파일(Fast File)” 클론 오퍼레이션을 지원하는 VAAI와 달리(쓰기 가능한 스냅샷을 이용), ODX 프리미티브는 동일한 기능이 없기 때문에 전체 복사(Full Copy)를 수행한다. 이러한 이유로, nCLI, REST API 또는 PowerShell CMDlets에 의해 호출되는 네이티브 DSF 클론을 사용하는 것이 보다 효율적이다. 현재 ODX에 의해 호출되는 오퍼레이션은 다음과 같다.

  • DSF SMB 쉐어에서 VM 또는 VM에서 VM으로 파일 복사
  • SMB 쉐어 파일 복사

SCVMM 라이브러리(DSF SMB 쉐어)에서 템플릿을 배포한다 - NOTE: 짧은 이름(e.g. FQDN이 아닌)을 갖는 공유(Shares)를 SCVMM 클러스터에 추가하여야 한다. 이러한 작업을 강제하기 위한 가장 쉬운 방법은 엔트리를 클러스터의 호스트 파일에 추가하는 것이다(e.g. 10.10.10.10 nutanix-130).

ODX는 다음과 같은 오퍼레이션을 위해 호출되지 않는다.

  • SCVMM을 통한 VM 복제
  • SCVMM 라이브러리에서 템플릿 배포 (DSF가 아닌 SMB 쉐어)
  • XenDesktop 클론 배포

ODX 오퍼레이션의 유효성 여부는 “NFS Adaptor”의 Activity Traces 페이지에서 확인할 수 있다 (이것이 SMB를 통해 수행되었음에도 불구하고 NFS라고 말했다). vDisk를 복사할 때의 오퍼레이션 액티비티는 'NfsSlaveVaaiCopyDataOp'가 되고, 디스크를 초기화할 때는 'NfsSlaveVaaiWriteZerosOp'가 된다.

관리

중요 페이지

내용 추가 예정입니다.

명령어 참조

여러 개의 원격 호스트에서 명령어 실행

설명: 하나 또는 여러 개의 원격 호스트에서 PowerShell 실행

$targetServers = "Host1","Host2","Etc"
Invoke-Command -ComputerName  $targetServers {
         <COMMAND or SCRIPT BLOCK>
}

가용한 VMQ 오프로드 체크

설명: 특정 호스트에서 가용한 VMQ 오프로드 개수 출력

gwmi -Namespace "root\virtualization\v2" -Class Msvm_VirtualEthernetSwitch | select elementname, MaxVMQOffloads

지정한 접두사와 매칭되는 VM의 VMQ 비활성화

설명: 특정 VM에 대한 VMQ 비활성화

$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix} | Get-VMNetworkAdapter | Set-VMNetworkAdapter -VmqWeight 0

지정한 접두사와 매칭되는 VM의 VMQ 활성화

설명: 특정 VM의 VMQ 활성화

$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix} | Get-VMNetworkAdapter | Set-VMNetworkAdapter -VmqWeight 1

지정한 접두사와 매칭되는 VM의 전원 인가

설명: 지정한 접두사와 매칭되는 VM의 전원 인가

$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix -and $_.StatusString -eq "Stopped"} | Start-VM

지정한 접두사와 매칭되는 VM을 셧다운

Get-VM | Where {$_.Name -match $vmPrefix -and $_.StatusString -eq "Running"}} | Shutdown-VM -RunAsynchronously

지정한 접두사와 매칭되는 VM을 중지

설명: 지정한 접두사와 매칭되는 VM을 중지

$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix} | Stop-VM

Hyper-V 호스트의 RSS 설정 정보 가져오기

설명: Hyper-V 호스트의 RSS(Receive Side Scaling) 설정 정보 가져오기

Get-NetAdapterRss

Winsh 및 WinRM 연결 체크

설명: 컴퓨터 시스템 오브젝트를 오류 없이 번환하는 샘플 쿼리를 수행하여 Winsh 및 WinRM 연결/상태 체크

allssh "winsh "get-wmiobject win32_computersystem"

메트릭스 및 임계 겂

내용 추가 예정입니다.

장애처리 및 고급 관리

내용 추가 예정입니다.

Part 2: Services

Book of Storage Services

볼륨 (블록 서비스)

뉴타닉스 볼륨(Nutanix Volumes) 기능은, 이전에 아크로폴리스 볼륨(Acropolis Volumes)으로 알려진, iSCSI를 통해 외부 소비자(게스트 OS, 물리 호스트, 컨테이너 등)에게 백엔드 DSF 스토리지를 제공한다.

이를 통해 모든 OS는 DFS에 액세스하고 DFS 스토리지 기능을 활용할 수 있다. 이러한 배포 시나리오에서 OS는 하이퍼바이저를 바이패스하여 뉴타닉스와 직접 통신한다.

뉴타닉스 볼륨(Nutanix Volumes)의 핵심 유즈-케이스(Use-Case)는 다음과 같다.

  • 공유 디스크 (Shared Disks)
    • Oracle RAC, Microsoft 페일오버 클러스터링 등
  • 퍼스트 클래스 엔티티로서의 디스크 (Disks as first-class entities)
    • 실행 컨텍스트의 수명이 짧고, 데이터가 매우 중요한 애플리케이션
    • 컨테이너, 오픈스택 등
  • 게스트가 시작한 iSCSI (Guest-initiated iSCSI)
    • 베어 메탈 소비자
    • vSphere 환경에서 동작하는 Microsoft Exchange (Microsoft 지원)
공인된 OS

솔루션은 iSCSI 사양을 준수하며, 공인된 OS는 QA에 의해 검증되었다.

  • Microsoft Windows Server 2008 R2, 2012 R2
  • Redhat Enterprise Linux 6.0+
볼륨 컨스트럭트

뉴타닉스 볼륨(Nutanix Volumes)을 구성하는 엔티티는 다음과 같다.

  • 데이터 서비스 IP(Data Services IP): 클러스터 레벨의 IP로 iSCSI 로긴 요청 시에 사용한다 (AOS 4.7 버전에 포함된 기능).
  • 볼륨 그룹(Volume Group): iSCSI 타깃 및 디스크 디바이스의 그룹으로 중앙 집중화된 관리, 스냅샷, 정책 설정 등을 지원한다.
  • 디스크(Disks): 볼륨 그룹(Volume Group)에 포함된 스토리지 디바이스 (iSCSI 타깃의 LUN으로 보여짐)
  • 부착(Attachment): 볼륨 그룹에 특정 Initiator IQN 액세스를 허용
  • 시크리트(Secret(s)): CHAP/Mutual CHAP 인증에 사용되는 시크리트(Secret)

NOTE: 백엔드에서 VG 디스크는 DSF에서 vDisk이다.

전제 조건

설정을 시작하기 전에, 센트럴 디스커버리 및 로그인 포탈 역할을 수행하는 데이터 서비스 IP(Data Services IP)를 설정하여야 한다.

“Cluster Details” (설정 아이콘 -> Cluster Details) 페이지에서 데이터 서비스 IP를 설정할 수 있다.

Volumes - Data Services IP
Figure. 볼륨 - 데이터 서비스 IP (Volumes - Data Services IP)

데이터 서비스 IP는 nCLI/API를 이용하여 설정할 수 있다.

ncli cluster edit-params external-data- services-ip-address=<DATA SERVICES IP ADDRESS>

타깃 생성

볼륨을 사용하기 위한 첫 번째 작업은 iSCSI 타깃이 되는 “볼륨 그룹”을 생성하는 것이다.

스토리지 페이지에서 오른쪽 상단의 “+ Volume Group”을 클릭한다.

Volumes - Add Volume Group
Figure. 볼륨 - 볼륨 그룹 추가 (Volumes - Add Volume Group)

볼륨 그룹 생성을 위해 설정하여야 할 정보는 다음과 같다.

Volumes - Add VG Details
Figure. 볼륨 - VG 상세 정보 추가 (Volumes - Add VG Details)

다음 단계는 타깃(LUN으로 보여짐)에 디스크의 추가를 위해 “+ Add new disk” 클릭한다.

대상 컨테이너와 디스크 사이즈를 선택할 수있는 메뉴가 나타난다.

Volumes - Add Disk
Figure. 볼륨 - 디스크 추가 (Volumes - Add Disk)

여러 개의 디스크를 추가하기 위해서는 “Add” 버튼을 클릭하고, 상기와 같은 작업을 반복한다.

세부 정보를 지정하고 디스크를 추가한 후에 볼륨 그룹을 VM 또는 Initiator IQN에 부착(Attach) 한다. 이렇게하면 VM이 iSCSI 타깃에 액세스 할 수 있다 (알 수 없는 Initiator 요청은 거부).

Volumes - Add Initiator IQN / VM
Figure. 볼륨 - Initiator IQN / VM (Volumes - Initiator IQN / VM)

“Save” 버튼을 클릭하면 볼륨 그룹 설정이 완료된다.

볼륨 그룹은 ACLI/API를 이용해 생성할 수 있다.

# VG 생성

vg.create <VG Name>

# VG에 디스크 추가

Vg.disk_create <VG Name> container=<CTR Name> create_size=<Disk size, e.g. 500G>

# VG에 Initiator IQN을 부착(Attach)

Vg.attach_external <VG Name> <Initiator IQN>

경로 HA

앞에서 설명했던 것과 같이 데이터 서비스 IP(Data Services IP)는 디스커버리를 위해 사용된다. 이것은 개별적인 CVM IP 주소를 모두 알고 있을 필요 없이 1개의 주소만 사용할 수 있게 한다.

데이터 서비스 IP는 현재 iSCSI 마스터에 할당된다. 마스터에 장애가 발생하면, 새로운 iSCSI 마스터가 선정되고 데이터 서비스 IP가 할당된다. 이러한 과정을 통해 디스커버리 포탈을 항상 가용한 상태로 유지한다.

iSCSI initiator는 iSCSI 타깃 포탈(iSCSC Target Portal)로서 데이터 서비스 IP를 설정한다. 로그인 요청이 발생하면, 플랫폼은 정상 실행 중인 스타게이트로 iSCSI 로그인 요청을 리다이렉트 한다.

Volumes - Login Redirect
Figure. 볼륨 - 로그인 리다이엑트 (Volumes - Login Redirect)

액티브(밀접한 관계가 있는: Affined) 스타게이트가 다운되면, Initiator는 데이터 서비스 IP로 iSCSI 로그인을 재시도하는데, 해당 요청은 정상 실행 중인 다른 스타게이트로 리다이렉트 된다.

Volumes - Failure Handling
Figure. 볼륨 - 장애 처리 (Volumes - Failure Handling)

밀접한 관계가 있는 스타게이트(Affined Stargate)가 복구되어 정상적인 상태를 유지하게 되면, 현재 액티브 스타게이트는 I/O 작업을 멈추고 액티브 iSCSI 세션을 종료한다. Initiator가 iSCSI 로그인을 재시도할 때, 데이터 서비스 IP는 로그인 요청을 밀접한 관계가 있는 스타게이트(Affined Stargate)로 리다이렉트 한다.

Volumes - Failback
Figure. 볼륨 - 패일백 (Volumes - Failback)
Note
헬스 모니터링 및 디폴트 (Health Monitoring and Defaults)

스타게이트 헬스는 DSF와 완전히 동일한 메카니즘으로 볼륨을 위한 주키퍼(Zookeeper for Volumes)를 사용하여 모니터링 된다.

페일백의 경우에 디폴트 인터벌은 120초이다. 이것은 밀접한 관계가 있는 스타게이트(Affined Stargate)가 2분 이상 동안 정상적인 상태를 유지하게 되면, I/O를 멈추고 세션을 종료한 후에, iSCSI 로그인을 재시도하도록 한다. 즉, 밀접한 관계가 있는 스타게이트로 다른 로그인을 강제한다.

상기와 같은 메커니즘을 사용하면, 경로 HA를 위해 클라이언트에서 제공하는 MPIO를 더 이상 사용할 필요가 없다. 타깃에 연결할 때, “Enable Multi-path”(MPIO 활성화)를 활성화할 필요가 없다.

Volumes - No MPIO
Figure. 볼륨 - No MPIO (Volumes - No MPIO)
다중 경로

iSCSI 프로토콜 스펙에 따르면, Initiator와 타깃간에 타깃 당 1개의 iSCSI 세션(TCP 연결)을 사용하여야 한다. 이것은 스타게이트와 타깃간의 관계가 1:1 이라는 것을 의미한다.

AOS 4.7 버전에서, Attached Initiator 당 디폴트로 32개의 가상 타킷이 생성되고, 볼륨 그룹에 추가된 각 디스크 디바이스에 할당된다. 즉, 디스크 디바이스 당 1개의 iSCSI 타깃을 제공한다. 이전에는 각각 하나의 디스크에 여러 개의 볼륨 그룹을 생성하여 처리하였다.

ACLI/API를 이용한 VG 상세 정보를 살펴보면, 각 Attachment에 32개의 가상 타깃이 생성된 것을 볼 수 있다.

attachment_list { external_initiator_name: "iqn.1991-05.com.microsoft:desktop-foo" target_params { num_virtual_targets: 32 } }

다음은 3개의 디스크 디바이스가 추가된 샘플 VG를 생성한 것이다. 클라이언트 프로그램에서 검색할 때 각 디스크 디바이스에 대한 개별적인 타깃을 볼 수 있다 ('-tgt[int]' 포맷의 접미사 사용).

Volumes - Virtual Target
Figure. 볼륨 - 가상 타깃 (Volumes - Virtual Target)

이를 통해 각 디스크 디바이스는 자신의 iSCSI 세션을 가지게 되고, 이러한 세션을 여러 개의 스타게이트에서 호스트 하여 확장성과 성능을 향상시킨다.

Volumes - Multi-Path
Figure. 볼륨 - 다중 경로 (Volumes - Multi-Path)

로드 밸런싱은 각 타깃에 대한 iSCSI 세션 설정(iSCSI 로그인) 시에 발생한다.

Note
액티브 경로 (Active Path(s))

다음 명령어를 이용하여 버츄얼 타깃을 호스팅 하고 있는 액티브 스타게이트 정보를 확인할 수 있다 (스타게이트를 호스팅하고 있는 CVM IP 출력).

# Windows
Get-NetTCPConnection -State Established -RemotePort 3205

# Linux
iscsiadm -m session -P 1

AOS 4.7 버전에서 클러스터 노드들로 타깃을 분산하기 위해 간단한 해쉬 함수를 사용하였다. AOS 5.0에서 아크로폴리스 동적 스케줄러(Acropolis Dynamic Scheduler: ADS)와 통합되어 필요한 경우에 세션의 리밸런싱(Re-Balancing) 작업을 수행한다. 필요한 경우에 뉴타닉스는 알고리즘을 보완하고 최적화하는 작업을 계속 진행할 예정이다. 또한, 노드가 정상 실행 중인 동안에는 선호된 노드로 계속 사용하는 것도 가능하다.

Note
SCSI UNMAP (TRIM)

뉴타닉스 볼륨은 SCSI T10 규격에 포함된 SCSI UNMAP(TRIM) 명령어를 지원한다. 이 명령어는 삭제된 블록으로부터 디스크 공간을 회수하고자 할 때 사용된다.

파일 (파일 서비스)

뉴타닉스 파일(Nutanix Files)을 사용하면 뉴타닉스 플랫폼을 고가용성을 지원하는 파일 서버로 활용할 수 있다. 파일 서비스는 사용자가 홈 디렉토리 및 파일을 저장할 수 있는 단일 네임스페이스(Single Namespace)를 제공한다.

지원 환경

솔루션은 아래와 같은 설정에서 적용할 수 있다 (좀 더 상세한 정보는 관련 문서를 참조한다).

핵심 유즈 케이스 (Core Use-Case(s))

  • 홈 폴더 / 사용자 프로파일 (Home folders / user profiles)
  • 파일 스토리지 (Filer storage)
  • 미디어 서버 (Media server)

관리 인터페이스 (Management interfaces(s))

  • 프리즘 엘리먼트(Prism Element: PE)

하이퍼바이저 (Hypervisor(s))

  • AHV
  • ESXi (AOS 5.0 이상)

업그레이드 (Upgrades)

  • 프리즘(Prism)

호환성 기능 (Compatible Features)

  • 뉴타닉스 스냅샷 및 DR (Nutanix Snapshots and DR)
  • WPV를 포함하는 파일 레벨 스냅샷 (File level snapshots including Windows Previous Version (WPV))
  • 셀프서비스 리스토어 (Self Service Restore)
  • CFT 백업 (CFT Backups)

파일 프로토콜 (File Protocols)

  • CIFS 2.1
  • NFS v4
  • NFS v3 (AFS 3.5 이상)
파일 컨스트럭트

파일 서비스는 다음과 같은 하이-레벨 컨스트럭트로 구성되어 있다.

  • 파일 서버 (File Server)
    • 하이-레벨 네임스페이스로 각 파일 서버는 배포된 자신의 파일 VM(FSVM: Files VM)을 갖는다.
  • 공유 (Share)
    • 사용자에게 제공되는 공유(Share)로 파일 서버는 여러 개의 공유(Share)를 갖는다 (e.g. 부서별 공유 등).
  • 폴더 (Folder)
    • 폴더는 파일 저장을 위한 것으로 FSVM을 통해 공유된다.

컨스트럭트들간의 매핑은 다음 그림과 같다.

Files Mapping
Figure. 파일 매핑 (Files Mapping)

뉴타닉스 파일(Nutanix Files) 기능에 뉴타닉스 플랫폼에서 가용성 및 확장성을 보장하기 위해 구현한 동일한 분산 기술이 적용되어 있다. 파일 서버 배포의 일부로써 최소 3개의 FSVM(File Services VM)이 배포된다.

컴포넌트들의 상세한 뷰(Detailed View)는 다음 그림과 같다.

Files Detail
Figure. 파일 상세 정보 (Files Detail)

FSVM(Files VM)은 뉴타닉스 플랫폼에서 에이전트 VM으로 실행되며, 설정 프로세스의 일부로 투명하게 배포된다.

아크로폴리스 플랫폼에서 FSVM의 상세한 뷰는 다음 그림과 같다.

Files Detail
Figure. FSVM 배포 아키텍처 (FSVM Deployment Arch)
인증 및 권한

뉴타닉스 파일(Nutanix Files) 기능은 Microsoft AD(Active Directory) 및 DNS와 완벽하게 통합되어 있다. 이를 통해 안전하게 설정되어 있는 모든 AD 인증 및 권한 기능을 활용할 수 있다. 모든 공유 사용 권한, 사용자 및 그룹 관리 등을 파일 관리를 위한 기존의 Windows MMC를 사용하여 수행할 수 있다.

설치 프로세스의 일부로서 다음과 같은 AD / DNS 오브젝트가 생성된다.

  • 파일 서버를 위한 AD 컴퓨터 계정
  • 파일 서버 및 FSVM을 위한 AD SPN (Service Principal Name)
  • 모든 FSVM을 가리키고 있는 파일 서버 DNS 엔트리
  • 각 FSVM의 DNS 엔트리

Note
파일 서버 생성을 위한 AD 권한 (AD Privileges for File Server Creation)

파일 서비스 기능을 배포할 때 AD 및 DNS 오브젝트가 생성되기 때문에 도메인 관리자 또는 동등한 권한을 갖는 사용자 계정을 사용하여야 한다.

고가용성 (HA)

각 FSVM은 인게스트 iSCSI(In-Guest iSCSI)를 통해 액세스 되는 FSVM 데이터 스토리지를 위해 뉴타닉스 볼륨 API(Nutanix Volumes API)를 활용한다. 이를 통해 FSVM 장애 시에 모든 FSVM은 모든 iSCSI 타킷에 연결할 수 있다.

FSVM 스토리지의 개요는 다음 그림과 같다.

FSVM Storage
Figure. FSVM 스토리지 (FSVM Storage)

경로 가용성(Path Availability)를 제공하기 위해 디폴트로 액티브 경로가 로컬 CVM으로 설정된 FSVM 내에서 DM-MPIO를 활용할 수 있다.

FSVM MPIO
Figure. FSVM MPIO

로컬 CVM이 가용하지 않은 경우에 (e.g. 액티브 경로 장애), DM-MPIO은 페일오버 경로 중 하나를 원격 CVM으로 활성화 한 후에 IO를 인계 받는다.

FSVM MPIO Failover
Figure. FSVM MPIO 페일오버 (FSVM MPIO Failover)

로컬 CVM이 다시 정상 동작하게 되면, 로컬 CVM이 로컬 IO을 제공하기 위해 액티브 경로로 표시된다.

일반적인 운영 환경에서 각 FSVM은 데이터 스토리지를 위해 자신의 VG(Volume Group)와 통신을 수행하며, 다른 VG와는 수동적인 연결(Passive Connection)을 갖는다. 각 FSVM은 클라이언트가 DFS 리퍼럴 프로세스(DSF Referral Process)의 일부로서 FSVM과의 통신을 위해 사용하는 IP를 갖는다. DFS 리퍼럴 프로세스가 폴더를 호스팅 하고 있는 정확한 IP로 연결시켜 주기 때문에, 클라이언트는 각 개별 FSVM의 IP를 알 필요가 없다.

FSVM Normal Operation
Figure. FSVM 정상 오퍼레이션 (FSVM Normal Operation)

FSVM 장애 시에 (e.g. 유지보수 또는 전원 꺼짐 등), 장애가 발생한 FSVM의 IP 및 VG는 클라이언트의 가용성을 보장하기 위해 다른 FSVM으로 인계된다.

장애가 발생한 FSVM의 IP 및 VG의 인계 과정은 다음 그림과 같다.

FSVM Failure Scenario
Figure. FSVM 장애 시나리오 (FSVM Failure Scenario)

장애가 발생한 FSVM이 다시 돌아와 안정적인 상태가 되면, FSVM은 IP와 VG을 다시 가져와서 클라이언트에게 IO 서비스를 계속 제공한다.

오브젝트 (오브젝트 서비스)

뉴타닉스 오브젝트(Nutanix Objects) 기능은 S3 호환 API(S3 추가 정보: LINK)를 통해 확장성과 내구성이 뛰어난 오브젝트 서비스를 제공한다. 오브젝트(Objects)는 뉴타닉스 플랫폼에 배포되기 때문에 데이터 중복제거, 압축, 복제 등과 같은 AOS 기능을 활용할 수 있다. 오브젝트(Objects)는 AOS 5.11에서 소개되었다.

지원 환경

솔루션은 아래와 같은 설정에서 적용할 수 있다 (좀 더 상세한 정보는 관련 문서를 참조한다).

핵심 유즈 케이스 (Core Use-Case(s))

  • 백업 (Backups)
  • 빅 데이터 / 분석 (Big data/analytics)

관리 인터페이스 (Management interfaces(s))

  • 프리즘 센트럴 (Prism Cental: PC)

하이퍼바이저 (Hypervisor(s))

  • N/A - 뉴타닉스 MSP에서 실행 (MSP를 지원하는 하이퍼바이저에 의존)

업그레이드 (Upgrades)

  • LCM

호환성 기능 (Compatible Features)

  • TBI

오브젝트 프로토콜 (Object Protocols)

  • S3 (version 4)

Note
뉴타닉스 마이크로서비스 플랫폼 (Nutanix Microservices Platform: MSP)

오브젝트(Objcts)는 MSP(Nutanix Microservices Platform)를 활용하는데, 이를 활용하는 최초의 핵심 서비스 중 하나이다.

뉴타닉스 MSP는 IAM(Identity and Access Management) 및 LB(Load Balancing)와 같은 오브젝트 컴포넌트와 관련된 컨테이너 및 플랫폼 서비스를 배포하기 위한 공통 프레임워크 및 서비스를 제공한다.

핵심 용어

본 섹션에서 사용할 핵심 용어의 정의는 다음과 같다.

  • 버킷 (Bucket)
    • 사용자에게 노출되는 조직 단위(Organization Unit)로 오브젝트를 포함(파일 서버의 파일에 공유한다고 생각할 때). 일반적으로 배포는 여러 개의 버킷을 포함할 수 있다(e.g. 부서, 구획 등)
  • 오브젝트 (Object)
    • API(GET/PUT)를 통해 인터페이스 되는 스토리지 및 아이템의 실제 단위(Actual Unit: BLOB)
  • S3
    • AWS(Amazon Web Service)에서 소개된 오리지널 오브젝트 서비스를 설명하기 위해 사용한다. 현재 오브젝트 서비스와 동의어로 사용된다. 또한, S3는 프로젝트 전반에 걸쳐 광범위하게 활용되는 오브젝트 API를 정의하는 데 사용된다.

다음 그림은 개념 구조의 하이-레벨 매핑 관계를 보여준다.

Buckets - Hierarchy
Figure. 오브젝트 - 계층구조 (Buckets - Hierarchy)
오브젝트 컨스트럭트

오브젝트(Objects)는 다음과 같은 몇 개의 하이-레벨 컨스트럭트로 구성되어 있다.

  • 로드 밸런서 (Load Balancer)
    • 로드 밸런서(Load Balancer)는 뉴타닉스 MSP의 일부로서 서비스 및 데이터 요청을 대한 프록시 역할을 담당한다. 이를 통해 서비스 고가용성 및 오브젝트 컨테이너간의 로드 밸런싱을 보장한다.
  • 서비스 관리자 (Service Manager)
    • 서비스 관리자(Service Manager)는 모든 UI 요청에 대한 엔트포인트(Endpoint) 역할을 수행하며, 오브젝트 스토어 인스턴스를 관리한다. 또한 인스턴스로부터 통계 수집에 대한 책임을 갖는다.
  • 메타데이터 서버 (Metadata Server)
    • 메타데이터 서버(Metadata Server)는 뉴타닉스 오브젝트 배포(e.g. 버킷, 오브젝트 등)와 관련된 모든 메타 정보의 수집 및 관리에 대한 책임을 갖는다. 뉴타닉스가 개발한 RocksDB 기반의 키-값 스토어(Key-Value Store)인 ChakrDB를 활용한다. ChakrDB는 스토리지로 뉴타닉스 볼륨(Nutanix Volumes)을 사용한다.
  • 오브젝트 컨트롤러 (Object Controller)
    • 오브젝트 컨트롤러(Object Controller)는 오브젝트 데이터 관리에 대한 책임을 가지며, 메타데이터 업데이트를 위해 메타데이터 서버와 코디네이션 한다. 오브젝트 컨트롤러는 스토리지 프록시 API(Storage Proxy API)를 통해 스타게이트와 인터페이스 한다.
  • 리전 매니저 (Region Manager)
    • 리전 매니저(Region Manager)는 아크로폴리스 DSF에서 모든 오브젝트 스토리지 정보(e.g. 리전(Region))의 관리에 대한 책임을 갖는다.
  • 리전 (Region)
    • 리전(Region)은 오브젝트와 뉴타닉스 vDisk에서 상응하는 위치(Corresponding Location)간의 하이-레벨 매핑 정보를 제공한다. vDisk ID, 오프셋 및 길이와 유사하다.
  • 아틀라스 서비스 (Atlas Service)
    • 아틀라스 서비스(Atlas Service)는 오브젝트 수명주기 정책 적용 및 가비지 콜렉션(Garbage Collection) 수행에 대한 책임을 갖는다.

다음은 오브젝트 서비스 아키텍처의 상세 구조이다.

Buckets - Architecture
Figure. 오브젝트 - 아키텍처 (Buckets - Architecture)

오브젝트(Objects)와 관련된 컴포넌트는 초록색으로 표시하였다. 오브젝트를 사용하면 "덮어쓰기(Overwrite)"라는 개념이 없기 때문에, CxxD가 CRUD(Create/Replace/Update/Delete) 이다. 오브젝트 "덮어쓰기(Overwrite)"를 위해 일반적으로 사용하는 방법은, 새로운 리비전을 생성하거나 또는 새로운 오브젝트를 생성하고 새로운 오브젝트로 지정(Point)하는 것이다.

오브젝트 스토리지 및 I/O

오브젝트는 리전(Region)이라고 불리는 논리적 컨스트럭트로 저장된다. 리전은 vDisk의 고정된 공간 세그먼트이다.

다음 그림은 vDisk와 리전간의 관계를 보여준다.

Buckets - vDisk Region
Figure. 오브젝트 - vDisk 리전 (Buckets - vDisk Region)

작은 오브젝트는 단일 리전(리전 ID, 오프셋, 길이)의 청크(Chunk)에 들어갈 수 있지만, 큰 오브젝트는 여러 리전에 걸처 스트라이프 될 수 있다. 큰 오브젝트가 여러 리전에 걸처 스트라이프(Striped) 될 경우에, 이러한 리전들이 여러 개의 vDisk에서 호스팅 되므로 여러 개의 스타게이트가 동시에 활용될 수 있다.

오브젝트(Object), 청크(Chunk), 리전(Region) 간의 관계를 보여주는 그림은 다음과 같다.

Buckets - Object Chunk
Figure. 오브젝트 - 오브젝트 청크 (Buckets - Object Chunk)

오브젝트 서비스 기능은 가용성 및 확장성을 보장하기 위해 뉴타닉스 플랫폼과 동일한 배포 방법을 사용한다. 오브젝트 배포의 일부로 최소 3개의 오브젝트 VM이 배포된다.

Book of Network Services

플로우 (마이크로세그멘테이션)

플로우(Flow)는 상태 정보를 유지하는 분산 방화벽(Distributed Stateful Firewall)으로, AHV 플랫폼에서 실행되는 엔티티뿐만 아니라 그들이 커뮤니케이션하는 외부 엔티티들간의 상세한 네트워크 실행 및 모니터링 기능을 제공한다.

지원 환경

본 솔루션은 아래의 환경에서 적용 가능하다 (목록이 완전하지 않을 수 있으니 전체 지원 목록은 설명서 참조).

핵심 유즈 케이스 (Core Use Case(s))

  • 마이크로세그멘테이션 (Microsegmentation)

관리 인터페이스 (Management interfaces(s))

  • 프리즘 센트럴 (Prism Central: PC)

지원 환경 (Supported Environment(s))

  • 온-프레미스 (On-Premise):
    • AHV (AOS 5.10 버전부터)

업그레이드 (Upgrades)

  • AOS의 일부 (Part of AOS)

호환성 기능 (Compatible Features)

  • 서비스 체인 (Service Chaining)
  • Calm
  • Epoch

설정 작업은 프리즘 센트럴(Prism Central)에서 정책(Policy)을 정의하고 카테고리(Category)에 할당하는 과정으로 수행된다. 즉, 센터에서 설정 작업을 수행하고, 여러 개의 뉴타닉스 클러스터에 적용한다. 각 AHV 호스트는 오픈플로우(OpenFlow)를 이용하여 규칙(Rules)을 구현한다.

구현 컨스트럭트

뉴타닉스 플로우(Nutanix Flow)의 주요 컨스트럭트는 다음과 같다.

카테고리

카테고리(Category)는 정책과 실행이 적용되는 엔티티 그룹을 정의하는 데 사용된다. 카테고리는 일반적으로 적용되며, 환경, ​​애플리케이션 유형, 애플리케이션 계층 등에 제한되지 않는다.

  • 카테고리(Category): Key/Value "Tag"
  • 예제(Examples): app | tier | group | location | subnet | etc.

예를 들어, 프로덕션 데이터베이스 서비스(Production Database Services)를 제공하는 VM은 다음과 같이 할당된 카테고리를 가질 수 있다.

  • AppTier: Database
  • AppType: MySQL
  • Environment: Production

그런 다음 이러한 카테고리는적용할 규칙/액션(Rules/Actions)을 결정하기 위해 정책에 의해 활용될 수 있다 (플로우 컨텍스트 외부에서도 활용됨).

보안 규칙

보안 규칙(Security Rules)은 정의된 규칙으로, 정의된 카테고리간에 무엇이 허용될 것인지를 결정한다.

Flow - Microsegmentation - Rules
Figure. 플로우 - 마이크로세그멘테이션 - 규칙 (Flow - Microsegmentation - Rules)

보안 규칙(Security Rules)의 종류는 다음과 같다.

  • 애플리케이션 규칙 (App Rule)
    • 트랜스포트(TCP/UDP), 포트 및 출발지/도착지에 “허용/거부(Allowed/Denied)” 할 대상을 정의할 수 있는 일반적인 규칙
    • [Allow|Deny] Transport: Port(s) [To|From]
    • 예제: Allow TCP 8080 from Category:Tier:Web to Category:Tier:App
  • 격리 규칙 (Isolation Rule)
    • 두 카테고리간의 트래픽은 거부하고, 카테고리 내에서의 트래픽은 허용
    • 예제: 테넌트 B로부터 테넌트 A를 분리, 환경을 복제하고 정상적인 네트워크 커뮤니케이션에 영향을 주지 않으면서 병렬적으로 실행하는 것을 허용
  • 검역 규칙 (Quarantine Rule)
    • 지정된 VM/카테고리에 대한 모든 트래픽을 거부
    • 예제: 바이러스에 감염된 VM A, B, C를 격리하여 네트워크를 더 이상 감염시키지 않도록 한다.

다음 그림은 샘플 애플리케이션에서 트래픽의 관리를 위한 플로우 - 마이크로세그멘테이션(Flow - Microsegmentation)의 활용 예를 보여준다.

Flow - Microsegmentation - Example Application
Figure. 플로우 - 마이크로세그멘테이션 - 애플리케이션 예제 (Flow - Microsegmentation - Example Application)
실행

실행(Enforcement)은 규칙이 매칭되었을 때 무슨 액션을 실행하여야 할지를 결정한다. AHV 플로우 - 마이크로세그멘테이션(Flow - Microsegmentation)은 다음과 같은 두 가지 유형의 실행을 지원한다.

  • 적용 (Apply)
    • 정의된 플로우를 허용하고 다른 모든 것을 버림으로써 정책을 실행
  • 모니터 (Monitor)
    • 모든 플로우를 허용하지만 정책 시각화 페이지에서 정책을 위반한 패킷을 강조

플로우 - 마이크로세그멘테이션(Flow - Microsegmentation) 규칙은 UVM을 떠나는 패킷에 처음 적용된다. 이것은 마이크로세그멘테이션 브릿지(br.microseg)에서 발생한다.

Flow - Microsegmentation - Flow
Figure. 플로우 - 마이크로세그멘테이션- 플로우 (Flow - Microsegmentation - Flow)

Epoch (네트워크 모니터링 / DPI)

내용 추가 예정입니다.

Book of Backup / DR Services

Leap (정책 기반 DR / 런북)

뉴타닉스 Leap 기능은 프리즘 센트럴을 통해 설정된 정책 기반의 백업(Policy Driven Backup), DR 및 런북(DR and Run Books) 자동화 서비스를 제공한다. 본 기능은 지난 수년 동안 AOS에서 지원하고 프리즘 엘리먼트에서 설정 기능을 제공했던 뉴타닉스 네이티브 DR 및 복제 기능을 기반으로 확장한 것이다. 복제를 위해 활용된 실제 백엔드 메커니즘에 대한 자세한 내용은 'Book of Acropolis'의 '백업 및 재해복구(DR)'섹션을 참조한다. Leap은 AOS 5.10에서 소개되었다.

지원 환경

본 솔루션은 아래와 같은 환경에서 적용할 수 있다 (목록이 완전하지 않을 수 있느니 전체 지원 목록은 관련 문서 참조).

핵심 유즈 케이스 (Core Use Case(s))

  • 정책 기반 백업 및 복제 (Policy based backups and replication)
  • DR 런북 자동화 (DR run book automation)
  • DRaaS (Xi를 통해)

관리 인터페이스 (Management interfaces(s))

  • 프리즘 센트럴 (Prism Central: PC)

지원 환경 (Supported Environment(s))

  • 온 프레미스 (On-Premise)
    • AHV (AOS 5.10 이상)
  • 클라우드 (Cloud)
    • Xi (AOS 5.10 이상)

업그레이드 (Upgrades)

  • AOS의 일부 (Part of AOS)

호환 기능 (Compatible Features)

  • AOS BC/DR 기능 (AOS BC/DR features)
핵심 용어

본 섹션에서 사용될 용어의 정의는 다음과 같다.

  • 복구 지점 목표 (Recovery Point Objective: RPO)
    • 장애 발생 시 허용되는 데이터 손실을 나타낸다. 예를 들어, RPO를 1시간으로 설정하면 1시간 마다 스냅샷을 만든다. 복원하는 경우에 최대 1시간 전의 데이터로 복원할 수 있다. 동기 복제의 경우에 일반적으로 RPO는 "0"이다.
  • 복구 시간 목표 (Recovery Time Objective: RTO)
    • 장애 이벤트부터 서비스 복원까지 소요된 기간을 나타낸다. 예를 들어, 장애가 발생하고 백업 및 서비스 정상화가 30분 안에 이루어져야 한다고 하면, RTO는 30분이다.
  • 복구 지점 (Recovery Point)
    • 스냅샷으로 알려진 복원 지점 (A restoration point aka snapshot).
구현 컨스트럭트

뉴타닉스 Leap에서 사용하는 핵심 컨스트럭트는 다음과 같다.

보호 정책
  • 주요 역할: 할당된 카테고리에 대한 백업/복제 정책
  • 설명: 보호 정책(Protection Policy)은 RPO(스냅샷 주기), 복구 위치(원격 클러스터 / Xi), 스냅샷 보존 정책(로컬 또는 원격 클러스터) 및 관련 카테고리를 정의한다. 보호 정책을 사용할 때 모든 항목은 카테고리 레벨로 적용된다(디폴트 정책은 일부 또는 모든 카테고리에 적용). 이것이 VM을 선택해야 하는 보호 도메인(Protection Domain)과 다른 점이다.

뉴타닉스 Leap 보호 정책(Protection Policy)의 구조는 다음 그림과 같다.

Leap - Protection Policy
Figure. Leap - 보호 정책 (Leap - Protection Policy)
복구 계획
  • 주요 역할: DR 런북 (DR Run Book)
  • 설명: 복구 계획(Recovery Plan)은 전원 켜기 순서(카테고리 또는 VM 지정 가능) 및 네트워크 매핑(프라이머리 vs. 리커버리, 테스트 페일오버/페일백)을 정의하는 런북(Run Book)이다. 이것은 SRM을 활용할 때 설정하는 항목과 대부분 동일하다. NOTE: 복구 계획을 설정하기 전에 먼저 보호 정책을 설정하여야 한다. 데이터를 복구하기 위해서는 리커버리 사이트에 데이터가 존재하여야 하기 때문이다.

뉴타닉스 Leap 복구 계획(Recovery Plan)의 구조는 다음 그림과 같다.

Leap - Recovery Plan
Figure. Leap - 복구 계획 (Leap - Recovery Plan)
선형 보존 정책
  • 주요 역할: 복구 지점 보존 정책 (Recovery Point retention policy)
  • 설명: 선형 보존 정책(Linear Retention Policy)은 유지하여야 할 복구 지점의 갯수를 지정한다. 예를 들어, RPO가 1시간이고 보존 기간을 10으로 설정한 경우에, 10시간(10 x 1시간)의 복구 지점(스냅샷)을 유지하게 된다.
롤업 보존 정책
  • 주요 역할: 복구 지점 보존 정책 (Recovery Point retention policy)
  • 설명: 롤업 보존 정책(Roll-up Retention Policy)은 RPO 및 보존 기간에 따라 스냅샷을 "롤업(Roll-up)" 한다. 예를 들어, RPO가 1시간이고 보존 기간을 5일로 설정한 경우에, 시간 당 1일분과 일 당 4일분의 복구 지점을 유지한다. 논리는 다음과 같이 특징 지을 수 있다: 보존 기간이 n일인 경우에, RPO 1일, 일별 n-1일분의 복구 지점을 유지한다. 보존 기간이 n주인 경우에, RPO 1일, 일별 1주, 주별 n-1주분의 복구 지점을 유지한다. 보존 기간이 n월인 경우에, RPO 1일, 일별 1주, 주별 1개월, 월별 n-1개월분의 복구 지점을 유지한다. 보유 기간이 n년인 경우에, RPO 1일, 일별 1주, 주별 1개월, 월별 1년, 월별 n-1년분의 복구 지점을 유지한다.
Note
선형 vs. 롤업 보존 (Linear vs. roll-up retention)

보존 기간이 짧은 작은 RPO windows이거나 특정 RPO window로 항상 복구할 필요가 있는 경우에는 선형 보존 정책(Linear Retention Policy)을 사용한다.

보존 기간이 긴 경우에는 롤업 보존 정책(Roll-up Retention Policy)을 사용한다. 롤업 보존 정책이 좀 더 유연한데, 스냅샷 에이징/가지치기(Snapshot Aging/Pruning) 작업을 자동으로 수행할 뿐만 아니라 첫 번째 날의 세분화된 RPO를 제공한다.

Leap 컨스트럭트의 하이-레벨 개요는 다음 그림과 같다.

Leap - Overview
Figure. Leap - 개요 (Leap - Overview)

다음 그림은 Leap이 온-프레미스와 Xi 환경간에 어떤 방식으로 복제 작업을 수행하는지를 보여준다.

Leap - topology
Figure. Leap - 토폴로지 (Leap - Topology)
사용 방법 맟 설정

다음 섹션에서 Leap의 사용 방법 및 설정에 대해 설명한다.

하이-레벨 프로세스는 다음과 같은 하이-레벨 단계로 특징 지울 수 있다.

  1. AZ에 연결 (Connect to Availability Zones (AZs))
  2. 보호 정책 설정 (Configure Protection Policies)
  3. 복구 계획 설정 (Configure Recovery Plan(s))
  4. 패일오버 & 패일백 실행/테스트 (Perform/Test Failover & Failback)
AZ (Availability Zones)에 연결

첫 번째 단계는 Xi AZ 또는 다른 PC가 될 수 있는 AZ에 연결하는 것이다. NOTE: AOS 5.11부터는 최소 2대 이상의 PC를 배포해야 한다 (각 사이트 당 1 개).

PC에서 'Availability Zones'을 검색하거나, 'Administration'  →  'Availability Zones' 메뉴로 이동한다.

Leap - Connect to Availability Zone
Figure. Leap - AZ에 연결 (Leap - Connect to Availability Zone)

'Connect to Availability Zone'을 클릭하고 AZ 유형을 선택한다 (PC 인스턴스로 알려진 'Xi' 또는 'Physical Location').

Leap - Connect to Availability Zone
Figure. Leap - AZ에 연결 (Leap - Connect to Availability Zone)

PC 또는 Xi의 ID 및 패스워드를 입력하고 'Connect' 버튼을 클릭한다.

Leap - Connect to Availability Zone
Figure. Leap - AZ에 연결 (Leap - Connect to Availability Zone)

연결된 AZ가 디스플레이되고 사용 가능한 상태가 된다.

보호 정책 설정

PC에서 'Protection Policies'를 검색하거나 'Policies'  →  'Protection Policies' 메뉴로 이동한다.

Leap - Protection Policies
Figure. Leap - 보호 정책 (Leap - Protection Policies)

'Create Protection Policy'를 클릭한다.

Leap - Protection Policy
Figure. Leap - 보호 정책 생성 (Leap - Create Protection Policy)

이름, 복구 위치, RPO 및 보존 정책에 대한 상세 정보를 입력한다 (이전에 설명).

Leap - Protection Policy Inputs
Figure. Leap - 보호 정책 입력 (Leap - Protection Policy Inputs)

NOTE: Xi인 경우에는 'Target Cluster'를 선택할 필요가 없다.

Leap - Protection Policy Inputs - Xi
Figure. Leap - 보호 정책 입력 - Xi (Leap - Protection Policy Inputs - Xi)

정책을 적용할 카테고리를 선택한다.

Leap - Protection Categories
Figure. Leap - 보호 정책 카테고리 (Leap - Protection Policy Categories)

'Save'를 클릭하면 새롭게 생성된 보호 정책을 확인할 수 있다.

Leap - Protection Policies
Figure. Leap - 보호 정책 (Leap - Protection Policies)
복구 계획 설정

PC에서 'Recovery Plans'을 검색하거나 'Policies'  →  'Recovery Plans' 메뉴로 이동한다.

Leap - Recovery Plans
Figure. Leap - 복구 계획 (Leap - Recovery Plans)

최초로 실행하는 경우에 첫 번째 복구 계획을 작성하라는 화면이 나타난다.

Leap - Create Recovery Plan
Figure. Leap - 복구 계획 생성 (Leap - Create Recovery Plan)

드롭-다운 메뉴를 이용하여 'Recovery Location'를 선택한다.

Leap - Select Recovery Location
Figure. Leap - 복구 위치 선택 (Leap - Select Recovery Location)

NOTE: 복구 위치는 Xi AZ 또는 물리적 AZ가 될 수 있다 (해당 관리 클러스터가 있는 PC).

복구 계획의 이름 및 설명을 입력하고 'Next'를 클릭한다.

Leap - Recovery Plan - Naming
Figure. Leap - 복구 계획 - 네이밍 (Leap - Recovery Plan - Naming)

'Add Entities'를 클릭하고 'Power on Sequence'를 지정한다.

Leap - Recovery Plan - Power On Sequence
Figure. Leap - 복구 계획 - Power On Sequence (Leap - Recovery Plan - Power On Sequence)

각 단계에 추가할 VM 또는 카테고리를 검색한다.

Leap - Recovery Plan - Power On Sequence
Figure. Leap - 복구 계획 - Power On Sequence (Leap - Recovery Plan - Power On Sequence)

'Power on Sequence'가 성공적으로 설정되었으면 'Next'를 클릭한다.

Leap - Recovery Plan - Power On Sequence
Figure. Leap - 복구 계획 - Power On Sequence (Leap - Recovery Plan - Power On Sequence)
Note
전원 인가 순서 (Power On Sequencing)

전원 인가 순서를 결정할 때, 다음과 같은 단계를 고려하는 것이 좋다.

  • 단계 0: 핵심 서비스 (AD, DNS 등)
  • 단계 1: 단계 0에 의존, 단계 2에서 요구되는 서비스 (e.g. DB Tier)
  • 단계 2: 단계 1에 의존, 단계 3에서 요구되는 서비스 (e.g. App Tier)
  • 단계 3: 단계 2에 의존, 단계 4에서 요구되는 서비스 (e.g. Web Tier)
  • 단계 4-N: 의존 관계에 기반하여 반복

다음 단계는 소스 환경과 타깃 환경간에 네트워크를 매핑하는 것이다.

Leap - Recovery Plan - Network Mapping
Figure. Leap - 복구 계획 - 네트워크 매핑 (Leap - Recovery Plan - Network Mapping)
Note
페일오버 / 페일백 네트워크 (Failover / Failback Networks)

대부분의 경우에 테스트 네트워크에서 라우팅 가능하지 않거나 격리된 네트워크를 사용하려고 한다. 이렇게 하면 중복된 SID, ARP 엔트리 등의 이슈가 발생하지 않는다.

Mine (백업 솔루션)

내용 추가 예정입니다.

Book of Orchestration Services

Calm (오케스트레이션 / 자동화)

내용 추가 예정입니다.

Book of Governance Services

Beam (비용 거버넌스 / 컴플라이언스)

내용 추가 예정입니다.

Part 3: Integrations

오픈스택

오픈스택(OpenStack)은 클라우드 구축 및 관리를 위한 오픈 소스 플랫폼이다. 오픈스택은 크게 프론트엔드(대시보드 및 API)와 인프라스트럭처 서비스(컴퓨트, 스토리지 등)로 구분된다.

오픈스택과 뉴타닉스 솔루션은 다음과 같은 컴포넌트로 구성되어 있다.

  • 오픈스택 컨트롤러 (OpenStack Controller)
    • 오픈스택 UI, API, 서비스를 호스팅 하는 기존 또는 새롭게 프로비저닝된 VM 또는 호스트이다. 모든 오픈스택 API 호출을 처리한다. 아크로폴리스 OVM 배포에서 이것은 아크로폴리스 오픈스택 드라이버(Acropolis OpenStack Driver)와 함께 배치될 수 있다.
  • 아크로폴리스 오픈스택 드라이버 (Acropolis OpenStack Driver)
    • 오픈스택 컨트롤러로부터 오픈스택 RPC를 받아 네이티브 아크로폴리스 API로 변환하는 역할을 수행한다. 이것은 오픈스택 컨트롤러, OVM(사전 설치) 상에 배포할 수도 있고, 새로운 VM으로 배포할 수 있다.
  • 아크로폴리스 오픈스택 서비스 VM (Acropolis OpenStack Services VM: OVM)
    • 오픈스택 컨트롤러로부터 오픈스택 RPC를 받아 네이티브 아크로폴리스 API로 변환하는 역할을 수행하는 아크로폴리스 드라이버를 갖는 VM.

오픈스택 컨트롤러는 기존 VM/호스트 일 수도 있고, 뉴타닉스 솔루션에서 오픈스택의 일부로 배포될 수 있다. 아크로폴리스 OVM은 뉴타닉스 오픈스택 솔루션의 일부로 배포되는 일종의 헬퍼 VM(Helper VM)이다.

클라이언트는 예상되는 메소드(Web UI, HTTP, SDK, CLI, API)를 사용하여 오픈스택 컨트롤러와 통신하고, 오픈스택 컨트롤러는 오픈스택 드라이버를 사용하여 요청을 네이티브 아크로폴리스 REST API 호출로 변환하는 아크로폴리스 OVM과 통신한다.

뉴타닉스 오픈스택 컴포넌트들 간의 통신은 다음 그림과 같다.

OpenStack + Acropolis OpenStack Driver
Figure 9-1. 오픈스택 + 아크로폴리스 오픈스택 드라이버 (OpenStack + Acropolis OpenStack Driver)

이를 통해 복잡한 오픈스택 인프라스트럭처 및 관련된 관리 모듈 없이 오픈스택 포털 및 API의 장점을 최대한 활용할 수 있다. 모든 백엔드 인프라스트럭처 서비스(컴퓨트, 스토리지, 네트워크)는 네이티브 뉴타닉스 서비스를 활용한다. 노바 컴퓨트 호스트(Nova Compute Host) 등을 배포할 필요가 없다. 플랫폼은 컨트롤러가 통신하는 이들 서비스에 대한 API를 노출한 다음 네이티브 아크로폴리스 API 호출로 변환한다. 단순화된 배포 모델을 고려할 때 전체 오픈스택 + 뉴타닉스 솔루션은 최대 30분 내에 배포 완료될 수 있다.

지원되는 오픈스택 컨트롤러 (Supported OpenStack Controllers)

현재 솔루션(AOS 4.5.1 버전)은 Kilo 버전 이상을 지원하는 오픈스택 컨트롤러가 필요하다.


오픈스택 컴포넌트의 역할은 다음 테이블과 같다.

항목 역할 오픈스택 컨트롤러 아크로폴리스 OVM 아크로폴리스 클러스터 프리즘
테넌트 대시보드 사용자 인터페이스 및 API X
관리자 대시보드 인프라 모니터림 및 운영 X X
오케스트레이션 오브젝트 CRUD 및 라이프사이클 관리 X
자원 할당(Quotas) 자원 제어 및 제한 X
사용자, 그룹 및 역할 역할 기반의 접근 제어(RBAC) X
SSO Single-sign on X
플랫폼 통합 오픈스택과 뉴타닉스 통합 X
인프라스트럭처 서비스 타깃 인프라스트럭처(컴퓨트, 스토리지, 네트워크) X
오픈스택 컴포넌트

오픈스택은 다양한 인프라스트럭처 기능의 서비스에 대한 책임을 갖는 여러 개의 컴포넌트로 구성되어 있다. 이러한 기능들 중의 일부는 오픈스택 컨트롤러에 의해 호스팅 되며 일부는 아크로폴리스 OVM에 의해 호스팅 된다.

핵심 오픈스택 컴포넌트들간의 역할은 다음 테이블과 같다.

컴포넌트 역할 오픈스택 컨트롤러 아크로폴리스 OVM
Keystone 아이덴터티 서비스 X
Horizon 대시보드 및 UI X
Nova 컴퓨트 X
Swift 오브젝트 스토리지 X X
Cinder 블록 스토리지 X
Glance 이미지 서비스 X X
Neutron 네트워킹 X
Heat 오케스트레이션 X
Others 모든 다른 컴포넌트 X

오픈스택 컴포넌트들간의 통신 관계는 다음 그림과 같다.

OpenStack + Nutanix API Communication
Figure 9-2. 오픈스택 + 뉴타닉스 API 통신 (OpenStack + Nutanix API Communication)

다음 섹션에서 주요 오픈스택 컴포넌트가 뉴타닉스 플랫폼에 어떤 방식으로 통합되었는지를 설명한다.

노바 (Nova)

노바(Nova)는 오픈스택 플랫폼을 위한 컴퓨트 엔진 및 스케줄러이다. 뉴타닉스 오픈스택 솔루션에서 각 아크로폴리스 OVM은 컴퓨트 호스트 역할을 하며, 모든 아크로폴리스 클러스터는 오픈스택 인스턴스 스케줄링의 대상이 되는 단일 하이퍼바이저 호스트 역할을 한다. 아크로폴리스 OVM은 노바-컴퓨트(Nova-Compute) 서비스를 실행한다.

오픈스택 포탈의 'Admin'->'System'->'System Information'->'Compute Services' 메뉴에서 노바(Nova) 서비스를 확인할 수 있다.

다음 그림은 노바(Nova) 서비스, 호스트 및 상태 정보를 보여준다.

OpenStack Nova Services
Figure 9-3. 오픈스택 노바 서비스 (OpenStack Nova Services)

노바 스케줄러(Nova Scheduler)는 선택된 AZ(Availability Zone)를 기반으로 인스턴스를 배치할 컴퓨트 호스트(아크로폴리스 OVM)를 결정한다. 이러한 요청은 선택된 아크로폴리스 OVM으로 전송되고, 아크로폴리스 OVM은 해당 요청을 타깃 호스트(i.e. 아크로폴리스 클러스터)의 아크로폴리스 스케줄러로 전달한다. 아크로폴리스 스케줄러는 클러스터 내에서 최적의 노드 위치를 결정한다. 클러스터 내의 개별 노드는 오픈스택에 노출되지 않는다.

오픈스택 포탈의 'Admin'->'System'->'Hypervisors' 메뉴에서 컴퓨트 및 하이퍼바이저 호스트 정보를 확인할 수 있다.

컴퓨트 호스트 역할을 하는 아크로폴리스 OVM은 다음 그림과 같다.

OpenStack Compute Host
Figure 9-4. 오픈스택 컴퓨트 호스트 (OpenStack Compute Host)

하이퍼바이저 호스트 역할을 하는 아크로폴리스 클러스터는 다음 그림과 같다.

OpenStack Hypervisor Host
Figure 9-5. 오픈스택 하이퍼바이저 호스트 (OpenStack Hypervisor Host)

상기 그림에서 보는 것과 같이 전체 클러스터 자원은 단일 하이퍼바이저 호스트에서 볼 수 있다.

스위프트 (Swift)

스위프트(Swift)는 파일 검색 및 저장을 위해 사용되는 오브젝트 스토어(Object Store) 이다. 현재 스위프트는 스냅샷 및 이미지의 백업/복원만을 위해 활용된다.

신더 (Cinder)

신더(Cinder)는 iSCSI 타깃을 노출하기 위한 오픈스택 볼륨 컴포넌트이다. 신더는 뉴타닉스 솔루션에서 뉴타닉스 볼륨 API를 활용한다. 이러한 볼륨은 블록 디바이스로 인스턴스에 직접 연결된다(인게스트(In-Guest)와 비교할 때).

오픈스택 포탈의 'Admin'->'System'->'System Information'->'Block Storage Services' 메뉴에서 신더(Cinder) 서비스를 확인할 수 있다.

신더(Cinder) 서비스, 호스트 및 상태 정보는 다음 그림과 같다.

OpenStack Cinder Services
Figure 9-6. 오픈스택 신더 서비스 (OpenStack Cinder Services)
글랜스 / 이미지 리파지토리 (Glance / Image Repo)

글랜스(Glance)는 오픈스택을 위한 이미지 스토어(Image Store)로 프로비저닝을 위해 사용 가능한 모든 이미지를 보여준다. 이미지는 ISO, 디스크, 스냅샷을 포함한다.

이미지 리파지토리(Image Repo)는 클랜스에 의해 퍼블리싱된 사용 가능한 이미지를 저장하는 리파지토리이다. 이것은 뉴타닉스 환경 내에 또는 외부 소스에 위치할 수 있다. 이미지가 뉴타닉스 플랫폼에 호스팅 되면 이미지는 OVM의 클랜스에 의해 오픈스택 컨트롤러로 퍼블리시 된다. 이리미 리파지토리가 외부 소스에만 존재하는 경우에 글랜스는 오픈스택 컨트롤러에 의해 호스팅 되며 이미지 캐시는 아크로폴리스 클러스터에서 활용된다.

글랜스는 클러스터 단위로 활성화되며 항상 이미지 리파지로와 함께 존재한다. 글랜스가 여러 개의 클러스터에서 활성화되면 이미지 리파리토리는 이러한 클러스터들을 모두 포괄하고, 오픈스택 포탈을 통해 생성된 이미지는 글랜스를 실행하는 모든 클러스터에 전파된다. 글랜스를 호스팅 하지 않는 클러스터는 이미지 캐시를 사용하여 로컬에서 이미지를 캐싱한다.

Note
Pro tip

대규모 배포인 경우에 글랜스는 사이트 당 최소 2개의 아크로폴리스 클러스터에서 실행해야 한다. 이를 통해 클러스터 장애 시에 이미지 리파지토리 HA를 제공하고, 이미지 캐시에 없을 때에도 이미지를 항상 사용할 수 있게 한다.

외부 소스가 이미지 리파지토리 / 글랜스를 호스팅 할 때, 노바(Nova)는 외부 소스로부터 타깃 아크로폴리스 클러스터로의 데이터 이동에 대한 책임을 갖는다. 이러한 경우에, 아크로폴리스 클러스터는 이미지 캐시를 활용하는데, 이미지에 대한 모든 후속 요청에 대응하기 위해 이미지를 로컬에 캐싱한다.

뉴트론 (Neutron)

뉴트론(Neutron)은 오픈스택의 네트워킹 컴포넌트로 네트워크 설정에 대한 책임을 갖는다. 아크로폴리스 OVM을 사용하면 오픈스택 포탈에서 네트워크 CRUD 오퍼레이션을 수행할 수 있고, 아크로폴리스에서 필요한 변경 작업을 수행한다.

오픈스택 포탈의 'Admin'->'System'->'System Information'->'Network Agents' 메뉴에서 뉴트론(Neutron) 서비스를 확인할 수 있다.

뉴트론(Neutron) 서비스, 호스트 및 상태 정보는 다음 그림과 같다.

OpenStack Neutron Services + Currently only Local and VLAN network types are supported.
Figure 9-7. 오픈스택 뉴트론 서비스 (OpenStack Neutron Services

뉴트론은 인스턴스가 부팅할 때 IP를 할당한다. 이러한 경우에 아크로폴리스는 할당할 VM에 대해 원하는 IP 주소를 받는다. VM이 DHCP 요청을 수행하면, 아크로폴리스 마스터는 AHV에서와 같이 사설 VXLAN을 통해 DHCP 요청에 응답한다.

Note
지원하는 네트워크 유형 (Supported Network Types)

현재 버전에서는 로컬 및 VLAN 네트워크만 지원된다.

키스톤(Keystone)과 호라이즌(Horizon) 컴포넌트는 아크로폴리스 OVM과 인터페이스 하는 오픈스택 컨트롤러에서 실행된다. OVM에는 오픈스택 API 호출을 네이티브 아크로폴리스 API 호출로 변환하는 역할을 수행하는 오픈스택 드라이버(OpenStack Driver)가 있다.

설계 및 배포

대규모 클라우드 배포의 경우에 유연성과 로컬리티를 제공하면서도 최종 사용자의 요구사항을 충족시킬 수 있는 분산 배포 토폴로지를 활용하는 것이 매우 중요하다.

오픈스택은 배포를 위해 다음과 같은 하이-레벨 컨스트럭트를 활용한다.

  • 리전 (Region)
    • 여러 개의 AZ(Availability Zones)가 있는 지리적 대륙 또는 지역. 여기에는 US-Northwest 또는 US-West 등과 같은 리전이 포함될 수 있다.
  • 가용성 존 (Availability Zone)
    • 클라우드 서비스가 호스팅 되는 특정 사이트 또는 데이터센터 위치. 여기에는 US-Northwest-1 또는 US-West-1 등과 같은 사이트가 포함될 수 있다.
  • 호스트 집합 (Host Aggregate)
    • 컴퓨트 호스트의 그룹으로 열(Row), 통로(Aisle) 일 수 있거나 사이트/AZ와 동등할 수 있다.
  • 컴퓨트 호스트 (Compute Host)
    • 노바-컴퓨트(Nova-Compute) 서비스를 실행 중인 아크로폴리스 OVM
  • 하이퍼바이저 호스트 (Hypervisor Host)
    • 아크로폴리스 클러스터(단일 호스트로 보여짐)

하이-레벨 컨스트럭트간의 관계는 다음 그림과 같다.

OpenStack - Deployment Layout
Figure 9-8. 오픈스택 - 배포 레이아웃(OpenStack - Deployment Layout)

다음 그림은 컨스트럭트의 실제 배포 예이다.

OpenStack - Deployment Layout - Example
Figure 9-9. 오픈스택 - 배포 레이아웃 - 예제(OpenStack - Deployment Layout - Example)

오픈스택 포탈의 'Admin'->'System'->'Host Aggregates' 메뉴에서 호스트 (Host), 호스트 집합 (Host Aggregates), 가용성 존 (Availability Zone)을 관리할 수 있다.

다음 그림은 호스트 (Host), 호스트 집합 (Host Aggregates), 가용성 존 (Availability Zone)에 대한 정보를 보여준다.

OpenStack Host Aggregates and Availability Zones
Figure 9-10. 오픈스택 호스트 집합 및 AZ(OpenStack Host Aggregates and Availability Zones)
서비스 디자인 및 확장

대규모 배포의 경우에 로드 밸런서 (Load Balancer)에 의해 추상화된 오픈스택 컨트롤러에 여러 개의 아크로폴리스 OVM을 연결하는 것이 좋다. 이를 통해 HA를 지원하고 OVM 뿐만 아니라 트랜젝션의 분산도 가능하다. OVM은 확장을 가능하게 하기 위해 어떤 종류의 상태 정보도 포함하지 않는다.

단일 사이트에서 OVM 확장 배포의 예는 다음 그림과 같다.

OpenStack - OVM Load Balancing
Figure 9-11. 오픈스택 – OVM 로드 밸런싱(OpenStack - OVM Load Balancing)

OVM에 대해 이러한 목적을 달성하기 위한 한 가지 방법은 Keepalived 및 HAproxy를 사용하는 것이다.

여러 사이트에 걸처있는 환경의 경우에 오픈스택 컨트롤러는 여러 사이트의 여러 아크로폴리스 OVM과 통신한다.

여러 사이트에 대한 배포 예제는 다음 그림과 같다.

OpenStack - Multi-Site
Figure 9-12. 오픈스택 – 멀티 사이트(OpenStack - Multi-Site)
배포

OVM은 CentOS/Redhat 배포판에서 독립형 RPM(Standalone RPM)으로 배포할 수도 있고, 완전한 VM으로 배포할 수도 있다. 아크로폴리스 OVM은 오픈스택 컨트롤러 및 뉴타닉스 클러스터와 네트워크 연결이 보장되기만 하면 어떤 종류의 플랫폼(뉴타닉스 또는 뉴타닉스가 아닌 플랫폼)에도 배포할 수 있다.

뉴타닉스 AHV 클러스터에서 아크로폴리스 OVM을 VM으로 배포하는 절차는 다음과 같다. OVM이 이미 배포된 경우 VM 생성 단계를 건너뛸 수 있다. 전체 OVM 이미지를 사용하거나 기존 CentOS/Redhat VM 이미지를 사용할 수 있다.

먼저 제공된 아크로폴리스 OVM 디스크 이미지를 아크로폴리스 클러스터로 임포트(Import) 한다. 이 작업은 SCP를 이용하여 디스크 이미지를 복사하거나 복사할 파일 URL을 지정하여 수행할 수 있다. 여기에서는 이미지 API(Images API)를 이용하여 임포트 하는 방법을 설명한다. NOTE: 이 VM을 아크로폴리스 클러스터가 아닌 다른 환경에 배포하는 것이 가능하다.

이미지 API(Images API)를 이용하여 디스크 이미지를 임포트 하기 위해 다음 명령어를 수행한다.

image.create <IMAGE_NAME> source_url=<SOURCE_URL> container=<CONTAINER_NAME>


OVM을 위한 아크로폴리스 VM의 생성을 위해 임의의 CVM에서 다음 ACLI 명령어를 수행한다.

vm.create <VM_NAME> num_vcpus=2 memory=16G
vm.disk_create <VM_NAME> clone_from_image=<IMAGE_NAME>
vm.nic_create <VM_NAME> network=<NETWORK_NAME>
vm.on <VM_NAME>


VM을 생성하고 전원을 켠 후에 제공된 ID/패스워드를 이용하여 SSH로 OVM에 접속한다.

Note
OVMCTL Help

CVM에서 다음 명령어를 수행하면 도움말이 출력된다.

ovmctl --help

OVM은 다음과 같은 2가지 배포 모드를 지원한다.

  • OVM-allinone
    • OVM은 모든 아크로폴리스 드라이버 및 오픈스택 컨트롤러를 포함한다.
  • OVM-services
    • OVM은 모든 아크로폴리스 드라이버를 포함하고 외부/원격 오픈스택 컨트롤러와 통신한다.

다음 섹션에서 2가지 배포 모드에 대해 설명한다. 어떤 배포 모드로도 사용이 가능하며, 모드간의 스위치도 가능하다.

OVM-allinone

OVM-allinone 배포는 다음과 같은 단계를 거친다. 다음 명령어를 실행시키기 위해 임의의 CVM에 SSH로 접속한다.

# Register OpenStack Driver service
ovmctl --add ovm --name <OVM_NAME> --ip <OVM_IP> --netmask <NET_MASK> --gateway <DEFAULT_GW> --domain <DOMAIN> --nameserver <DNS>

# Register OpenStack Controller
ovmctl --add controller --name <OVM_NAME> --ip <OVM_IP>

# Register Acropolis Cluster(s) (run for each cluster to add)
ovmctl --add cluster --name <CLUSTER_NAME> --ip <CLUSTER_IP> --username <PRISM_USER> --password <PRISM_PASSWORD>

The following values are used as defaults:
Number of VCPUs per core = 4
Container name = default
Image cache = disabled, Image cache URL = None


다음 명령어를 사용하여 설정 검증 작업을 수행한다.

ovmctl --show


이 시점에서 모든 프로세스 및 서비스가 실행되어야 한다.

OVM-services

OVM-services 배포는 다음과 같은 단계를 거친다. 다음 명령어를 실행시키기 위해 임의의 CVM에 SSH로 접속한다.

# Register OpenStack Driver service
ovmctl --add ovm --name <OVM_NAME> --ip <OVM_IP>

# Register OpenStack Controller
ovmctl --add controller --name <OS_CONTROLLER_NAME> --ip <OS_CONTROLLER_IP> --username <OS_CONTROLLER_USERNAME> --password <OS_CONTROLLER_PASSWORD>

The following values are used as defaults:
Authentication: auth_strategy = keystone, auth_region = RegionOne
auth_tenant = services, auth_password = admin
Database: db_{nova,cinder,glance,neutron} = mysql, db_{nova,cinder,glance,neutron}_password = admin
RPC: rpc_backend = rabbit, rpc_username = guest, rpc_password = guest

# Register Acropolis Cluster(s) (run for each cluster to add)
ovmctl --add cluster --name <CLUSTER_NAME> --ip <CLUSTER_IP> --username <PRISM_USER> --password <PRISM_PASSWORD>

The following values are used as defaults:
Number of VCPUs per core = 4
Container name = default
Image cache = disabled, Image cache URL = None


만약 오픈스택 컨트롤러 배포에서 디폴트 패스워드를 사용하지 않는다면, 패스워들 변경해 주어야 한다.

# Update controller passwords (if non-default are used)
ovmctl --update controller --name <OS_CONTROLLER_NAME> --auth_nova_password <> --auth_glance_password <> --auth_neutron_password <> --auth_cinder_password <> --db_nova_password <> --db_glance_password <> --db_neutron_password <> --db_cinder_password <>


다음 명령어를 사용하여 설정 검증 작업을 수행한다.

ovmctl --show


OVM 설정이 완료되면, 오픈스택 컨트롤러가 글랜스 및 뉴트론 엔드포인트(Glance and Neutron endpoint)를 인지할 수 있도록 설정한다.

오픈스택 컨트롤러에 로그인 한 후에, "source ./keystonerc_admin"를 입력한다.

# enter keystonerc_admin
source ./keystonerc_admin


먼저 컨트롤러를 가리키고 있는 기존 글랜스 엔드포인트(Existing Glance Endpoint)를 삭제한다.

# Find old Glance endpoint id (port 9292)
keystone endpoint-list # Remove old keystone endpoint for Glance
keystone endpoint-delete <GLANCE_ENDPOINT_ID>


다음으로 OVM을 가리킬 새로운 글랜스 엔드포인트를 생성한다.

# Find Glance service id
keystone service-list | grep glance
# Will look similar to the following:
| 9e539e8dee264dd9a086677427434982 | glance | image |

# Add Keystone endpoint for Glance
keystone endpoint-create \
--service-id <GLANCE_SERVICE_ID> \
--publicurl http://<OVM_IP>:9292 \
--internalurl http://<OVM_IP>:9292 \
--region <REGION_NAME> \
--adminurl http://<OVM_IP>:9292


컨트롤러를 가리키고 있는 기존 뉴트론 엔드포인(Existing Neutron Endpoint)를 삭제한다.

# Find old Neutron endpoint id (port 9696)
keystone endpoint-list # Remove old keystone endpoint for Neutron
keystone endpoint-delete <NEUTRON_ENDPOINT_ID>


OVM을 가리킬 새로운 뉴트론 엔드포인트를 생성한다.

# Find Neutron service id
keystone service-list | grep neutron
# Will look similar to the following:
| f4c4266142c742a78b330f8bafe5e49e | neutron | network |

# Add Keystone endpoint for Neutron
keystone endpoint-create \
--service-id <NEUTRON_SERVICE_ID> \
--publicurl http://<OVM_IP>:9696 \
--internalurl http://<OVM_IP>:9696 \
--region <REGION_NAME> \
--adminurl http://<OVM_IP>:9696


엔드포인트를 생성한 후에, 노바 및 신더 설정 파일을 글랜스 호스트의 새로운 아크로폴리스 OVM IP로 업데이트한다.

먼저 “/etc/nova/nova.conf”에 있는 nova.conf 파일을 다음과 같이 수정한다.

[glance]
...
# Default glance hostname or IP address (string value)
host=<OVM_IP>

# Default glance port (integer value)
port=9292
...
# A list of the glance api servers available to nova. Prefix
# with https:// for ssl-based glance api servers.
# ([hostname|ip]:port) (list value)
api_servers=<OVM_IP>:9292


오픈스택 컨트롤러에서 nova-compute를 비활성화 한다 (만약 이미 비활성화 하지 않았다면).

systemctl disable openstack-nova-compute.service
systemctl stop openstack-nova-compute.service
service openstack-nova-compute stop


“/etc/nova/cinder.conf”에 있는 cinder.conf 파일을 다음과 같이 수정한다.

# Default glance host name or IP (string value)
glance_host=<OVM_IP>
# Default glance port (integer value)
glance_port=9292
# A list of the glance API servers available to cinder
# ([hostname|ip]:port) (list value)
glance_api_servers=$glance_host:$glance_port


LVM을 사용하지 않기 때문에, LVM을 코멘트 처리한다.

# Comment out the following lines in cinder.conf
#enabled_backends=lvm
#[lvm]
#iscsi_helper=lioadm
#volume_group=cinder-volumes
#iscsi_ip_address=
#volume_driver=cinder.volume.drivers.lvm.LVMVolumeDriver
#volumes_dir=/var/lib/cinder/volumes
#iscsi_protocol=iscsi
#volume_backend_name=lvm


오픈스택 컨트롤러에서 신더 볼륨(Cinder Voluume)을 비활성화 한다 (만약 이미 비활성화 하지 않았다면).

systemctl disable openstack-cinder-volume.service
systemctl stop openstack-cinder-volume.service
service openstack-cinder-volume stop


오픈스택 컨트롤러에서 Glance-Image를 비활성화 한다 (만약 이미 비활성화 하지 않았다면).

systemctl disable openstack-glance-api.service
systemctl disable openstack-glance-registry.service
systemctl stop openstack-glance-api.service
systemctl stop openstack-glance-registry.service
service openstack-glance-api stop
service openstack-glance-registry stop


모든 파일을 수정한 후에, 노바 및 신더 서비스를 재시작 하여 새로운 설정 값이 적용되도록 한다. 다음 명령어를 사용하여 서비스를 재시작 할 수도 있고, 다운로드 받은 스크립트를 수행하여 서비스를 재시작 할 수도 있다.

# Restart Nova services
service openstack-nova-api restart
service openstack-nova-consoleauth restart
service openstack-nova-scheduler restart
service openstack-nova-conductor restart
service openstack-nova-cert restart
service openstack-nova-novncproxy restart

# OR you can also use the script which can be downloaded as part of the helper tools:
~/openstack/commands/nova-restart

# Restart Cinder
service openstack-cinder-api restart
service openstack-cinder-scheduler restart
service openstack-cinder-backup restart

# OR you can also use the script which can be downloaded as part of the helper tools:
~/openstack/commands/cinder-restart

장애처리 및 고급 관리
주요 로그 위치
컴포넌트 주요 로그 위치
Keystone /var/log/keystone/keystone.log
Horizon /var/log/horizon/horizon.log
Nova /var/log/nova/nova-api.log
/var/log/nova/nova-scheduler.log
/var/log/nova/nove-compute.log*
Swift /var/log/swift/swift.log
Cinder /var/log/cinder/api.log
/var/log/cinder/scheduler.log
/var/log/cinder/volume.log
Glance /var/log/glance/api.log
/var/log/glance/registry.log
Neutron /var/log/neutron/server.log
/var/log/neutron/dhcp-agent.log*
/var/log/neutron/l3-agent.log*
/var/log/neutron/metadata-agent.log*
/var/log/neutron/openvswitch-agent.log*

“*”로 표시된 로그 파일은 아크로폴리스 OVM에만 존재한다.

Note
Pro tip

OVM에서 서비스가 실행중이더라도, 오픈스택 매니저(Admin UI 또는 CLI)에서 서비스가 “DOWN” 상태로 표시되면 NTP를 체크한다. 대부분의 서비스가 오픈스택 컨트롤러와 아크로폴리스 OVM간의 시간 동기화를 요구한다.

명령어 참조

키스톤(Keystone) 소스 로드 (다른 명령어를 수행하기 전에 수행).

source keystonerc_admin


키스톤(Keystone) 서비스 목을 출력

keystone service-list


키스톤(Keystone) 엔드포인트 목록 출력

keystone endpoint-list


키스톤(Keystone) 엔드포인트 생성

keystone endpoint-create \
--service-id=<SERVICE_ID> \
--publicurl=http://<IP:PORT> \
--internalurl=http://<IP:PORT> \
--region=<REGION_NAME> \
--adminurl=http://<IP:PORT>


노바(Nova) 인스턴스 목록 출력

nova list


인스턴스 상세 정보 출력

nova show <INSTANCE_NAME>


노바(Nova) 하이퍼바이저 호스트 목록 출력

nova hypervisor-list


하이퍼바이저 호스트 상세 정보 출력

nova hypervisor-show <HOST_ID>


글랜스(Glance) 이미지 목록 출력

glance image-list


글랜스(Glance) 이미지 상세 정보 출력

glance image-show <IMAGE_ID>

Afterword

Nutanix Bible을 읽어 주셔서 감사합니다!  다가오는 업데이트 소식을 계속 듣고 뉴타닉스 플랫폼을 즐기십시오!