Goto Top

Part0. 들어가기 전에

뉴타닉스 바이블은 Steven Poitras가 운영하고 있는 http://nutanixbible.com/에 있는 내용을 번역한 것입니다. 뉴타닉스 바이블과 관련된 모든 저작권은 Steven Poitras에게 있습니다.

본 사이트는 뉴타닉스 바이블에 있는 내용을 가능하면 원문 그대로 번역한 것이며, 번역 및 사이트 구축 과정에서 실수나 오류가 있을 수 있으므로, 이 점은 넓은 마음으로 양해를 부탁드리며, 잘못된 내용에 대해 지적해 주시면 빠른 시간 내에 적용할 수 있도록 하겠습니다.

뉴타닉스 바이블의 내용과 관련하여 궁금한 사항을 chlee@virtual-space.co.kr로 메일을 주시면 빠른 시간 내에 성실한 답변을 드리도록 하겠습니다.

목차(Table of Contents)

Part I. A Brief Lesson in History

1.1 데이터센터의 진화 (The Evolution of the Datacenter)

1.1.1 메인프레임 시대 (The Era of Mainframe)

1.1.2 Stand-Alone 서버로 이동 (The Move to Stand-Alone Servers)

1.1.3 중앙 집중화된 스토리지 (Centralized Storage)

1.1.4 가상화의 도입 (The Introduction of Virtualization)

1.1.5 가상화의 성숙 (Virtualization Matures)

1.1.6 SSDs (Solid State Disks)

1.1.7 클라우드 시대 (In Comes Cloud)

1.2 레이턴시의 중요성 (The Importance of Latency)

1.2.1 대역폭 살펴보기 (Looking at the Bandwidth)

1.2.2 메모리 레이턴시의 영향 (The impact to Memory Latency)

1.3 Book of Web-Scale

1.3.1 하이퍼컨버전스 (Hyper-convergence)

1.3.2 소프트웨어 정의 인텔리전스 (Software defined intelligence)

1.3.3 분산 처리 시스템 (Distributed autonomous system)

1.3.4 점진적 및 선형적 확장 (Incremental and linear scale out)

1.3.5 요약 정리

Part II. Book of Prism

2.1 설계 방법론 (Design Methodology)

2.2 아키텍처

2.2.1 프리즘 서비스 (Prism Services)

2.3 네비게이션 (Navigation)

2.3.1 프리즘 센트럴 (Prism Central)

2.3.2 프리즘 엘리먼트 (Prism Element)

2.3.3 단축 키 (Keyboard Shortcuts)

2.4 사용 방법 및 Troubleshooting

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

2.4.2 하이퍼바이저 업그레이드 (Hypervisor Upgrade)

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

2.4.4 입출력 매트릭스 (I/O Metrics)

2.4.5 용량 계획 (Capacity Planning)

2.5 APIs and Interfaces

2.5.1 ACLI

2.5.2 NCLI

2.5.3 PowerShell CMDlets

2.6 통합 (Integrations)

2.6.1 오픈스택 (OpenStack)

2.6.2 Puppet

Part III. Book of Acropolis

3.1 아키텍처 (Architecture)

3.1.1 하이퍼컨버지드 플랫폼 (Hyperconverged Platform)

3.1.2 분산 시스템 (Distributed Systems)

3.1.3 소프트웨어 정의 (Software-defined)

3.1.4 클러스터 컴포넌트 (Cluster Components)

3.1.5 아크로폴리스 서비스 (Acropolis Services)

3.1.6 동적 스케줄러 (Dynamic Scheduler)

3.1.7 보안 및 암호 (Security and Encryption)

3.1.8 드라이브 분해 (Drive Breakdown)

3.2 분산 스토리지 패브릭 (Distributed Storage Fabric)

3.2.1 데이터 구조 (Data Structure)

3.2.2 입출력 I/O 아키텍처

3.2.3 메타데이터 확장성 (Scalable Metadata)

3.2.4 데이터 보호 (Data Protection)

3.2.5 가용성 도메인(Availability Domain)

3.2.6 데이터 패스 리질리언시 (Data Path Resiliency)

3.2.7 용량 최적화 (Capacity Optimization)

3.2.8 스토리지 티어링 및 우선순위(Storage Tiering and Prioritization)

3.2.9 디스크 밸런싱(Disk Balancing)

3.2.10 스냅샷 및 클론(Snapshots and Clones)

3.2.11 네트워킹 and I/O

3.2.12 데이터 로컬리티 (Data Locality)

3.2.13 쉐도우 클론 (Shadow Clones)

3.2.14 스토리지 레이어 및 모니터링(Storage Layers and Monitoring)

3.3 서비스 (Services)

3.3.1 뉴타닉스 게스트 툴 (NGT: Nutanix Guest Tool)

3.3.2 OS 커스터마이제이션 (OS Customization)

3.3.3 블록 서비스 (Block Services)

3.3.4 파일 서비스 (File Services)

3.3.5 컨테이너 서비스 (Container Services)

3.4 백업 및 DR (Backup and Disaster Recovery)

3.4.1 구현 컨스트럭트 (Implementation Constructs)

3.4.2 보호 엔티티 (Protecting Entities)

3.4.3 백업 및 복원 (Backup and Restore)

3.4.4 App Consistent Snapshots

3.4.5 복제 및 DR (Replication and Disaster Recovery)

3.4.6 클라우드 커넥트 (Cloud Connect)

3.4.7 매트로 가용성 (Metro Availability)

3.5 Application Mobility Fabric

3.6 관리 (Administration)

3.5.1 중요 페이지 (Important Pages)

3.5.2 클러스터 명령어 (Cluster Commands)

3.5.3 메트릭스 및 임계 값

3.5.4 Gflags

3.5.5 장애 처리 및 고급 관리

Part IV. Book of AHV

4.1 아키텍처 (Architecture)

4.1.1 노드 아키텍처 (Node Architecture)

4.1.2 KVM 아키텍처 (KVM Architecture)

4.1.3 설정 최대값 및 확장성 (Configuration maximums and scalability)

4.1.4 네트워킹 (Networking)

4.2 동작방식(How It Works)

4.2.1 스토리지 I/O 경로 (Storage I/O Path)

4.2.2 IP 주소 관리 (IP Address Management)

4.2.3 VM HA (VM High Availability)

4.3 관리 (Administration)

4.3.1 중요 페이지 (Important Pages)

4.3.2 명령어 참조 (Command Reference)

4.3.3 메트릭스 및 임계 값

4.3.4 장애 처리 및 고급 관리

Part V. Book of vSphere

5.1 아키텍처 (Architecture)

5.1.1 노드 아키텍처 (Node Architecture)

5.1.2 설정 최대값 및 확장성

5.1.3 네트워킹 (Networking)

5.2 동작방식(How It Works)

5.2.1 Array Offloads – VAAI

5.2.2 CVM 자동절체 (CVM Autopathing aka Ha.py)

5.3 관리 (Administration)

5.3.1 중요 페이지 (Important Pages)

5.3.2 명령어 참조 (Command Reference)

5.3.3 메트릭스 및 임계 값

5.3.4 장애 처리 및 고급 관리

Part VI. Book of Hyper-V

6.1 아키텍처 (Architecture)

6.1.1 노드 아키텍처 (Node Architecture)

6.1.2 설정 최대값 및 확장성 제약

6.1.3 네트워킹 (Networking)

6.2 동작방식(How It Works)

6.2.1 Array Offloads – ODX

6.3 관리 (Administration)

6.3.1 중요 페이지 (Important Pages)

6.3.2 명령어 참조 (Command Reference)

6.3.3 메트릭스 및 임계 값

6.3.4 장애 처리 및 고급 관리

Part VII. Book of XenServer

Part VIII. Book of Foundation

8.1 아키텍처 (Architecture)

8.2 시스템 이미징 및 배포 (System Imaging and Deployment)


Part I. A Brief Lesson in History

본문을 시작하기 전에, 오늘의 현실을 가능하게 했던 주요 기술적 또는 환경적 측면에서 인프라스트럭처의 역사에 대해 간략하게 살펴보도록 한다.

1.1 데이터센터의 진화 (The Evolution of the Datacenter)

지난 수십 년 동안, 데이터센터는 엄청난 발전 및 진화를 계속해 왔다. 본 섹션에서는 데이터센터의 각 세대별 특징을 간략하게 설명한다.

1.1.1 메인프레임 시대 (The Era of Mainframe)

메인프레임(Mainframe)은 수년 동안 시장을 지배하였으며, 오늘날 데이터센터 핵심 아키텍처의 기반을 제공하였다. 메인프레임 시대의 특징은 다음과 같다.

  • 기본적으로 CPU, 메인 메모리, 스토리지가 컨버지드된 구조
  • 안정적이고 효율적인 내부 이중화 구조

그러나, 메인프레임은 다양한 장점에도 불구하고 다음과 같은 이슈를 제기하였다.

  • 인프라스트럭처를 구축하는데 많은 비용 필요
  • 내재된 고유의 복잡성
  • 유연성 부족 및 높은 사일로 환경

1.1.2 Stand-Alone 서버로 이동 (The Move to Stand-Alone Servers)

기업 내 조직이 메인프레임의 기능을 활용하기 어렵다는 사실이, 오히려 Stand-Alone 서버를 사용하게 하는 촉매제가 되었다. Stand-Alone 서버의 주요 특징은 다음과 같다.

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

그러나, Stand-Alone 서버는 다음과 이슈를 제기하였다.

  • 사일로우 개수의 증가
  • 낮은 또는 균일하지 않은 자원 활용률
  • 서버가 컴퓨트 및 스토리지의 SPOF (Single Point Of Failure)가 됨

1.1.3 중앙 집중화된 스토리지 (Centralized Storage)

비즈니스는 항상 이윤을 추구해야 하는데, 데이터는 기업의 이윤추구를 위한 핵심 수단이다. DAS(Direct-Attached Storage)를 사용하는 경우에, 조직은 로컬에서 가용한 자원보다 더 많은 자원이 필요하거나 또는 서버 장애가 발생하더라도 데이터 손실이 없는 데이터 고가용성(Data HA) 기능이 필요하였다.

메인프레임과 Stand-Alone 서버를 대체한 중앙 집중화된 스토리지는 데이터 보호 기능을 갖는 대용량의 공유 스토리지 풀(Storage Pool)을 제공하였다. 중앙 집중화된 스토리지의 주요 특징은 다음과 같다.

  • 스토리지 자원의 풀링을 통해 보다 나은 스토리지 자원의 활용률 제공
  • RAID를 기반으로 하는 중앙 집중화된 데이터 보호 기술은 서버 장애로 인한 데이터의 손실 가능성 제거
  • 스토리지는 네트워크에 연결되어 스토리지 서비스 제공

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

  • 중앙 집중화된 스토리지는 잠재적으로 매우 고가일 수 있음. 그러나, 데이터는 하드웨어 보다 가치가 큼.
  • 복잡성의 증가 (SAN Fabric, WWPNs, RAID 그룹, 볼륨, 스핀들 카운트 등)
  • 중앙 집중화된 스토리지는 추가적인 관리 툴 및 전문가를 필요로 함.

1.1.4 가상화의 도입 (The Introduction of Virtualization)

컴퓨터 기술의 발전 단계에서 볼 때, 이 시점에서의 컴퓨트 활용률은 매우 낮았으며, 자원 효율성은 거의 바닥 수준이었다. 이 시기에 가상화(Virtualization)가 도입되었으며, 가상화는 하나의 하드웨어 플랫폼에서 복수의 워크로드 및 운영체제(Operating System)를 VM(Virtual Machine)으로 구동할 수 있는 환경을 제공하였다. 가상화는 비즈니스가 하드웨어 자원의 활용률을 증가시킬 수 있도록 하였으나, 반면에 사일로우 수 및 장애가 미치는 영향을 증가시켰다. 가상화의 주요 특징은 다음과 같다.

  • 하드웨어로부터 OS를 추상화 (VM)
  • 컴퓨트 자원의 효율적인 활용은 워크로드의 집적도를 향상시킴

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

  • 사일로우의 수 및 관리 복잡성의 증가
  • VM의 HA(High-Availability) 기능이 구성되지 않을 경우에, 컴퓨트 노드의 장애에 따른 영향이 매우 큼.
  • 풀링(Pooling)된 지원의 부족
  • 추가적인 관리 툴 및 전문가 필요

1.1.5 가상화의 성숙 (Virtualization Matures)

하이퍼바이저는 매우 효율적이면서도 많은 기능을 제공하는 솔루션이 되었다. VMware vMotion, HA, DRS 등과 같은 툴이 출시됨에 따라, 유저는 VM HA 기능 및 컴퓨트 워크로드를 동적으로 마이그레이션 할 수 있는 능력을 갖게 되었다. 유일한 제약은 중앙 집중화된 스토리지에 의존한다는 것인데, 이것은 두 개의 경로를 병합해야 한다는 것을 의미한다. 중앙 집중화된 스토리지를 사용하는 경우의 단점은 스토리지 어레이에 부하가 가중되고, VM의 수가 증가함에 따라 스토리지 I/O에 대한 경합이 증가한다는 것이다. 주요 특징은 다음과 같다.

  • 클러스터 구성으로 컴퓨트 자원을 풀링
  • 워크로드를 컴퓨트 노드들간에 동적으로 마이그레이션 (DRS/vMotion)
  • 컴퓨트 노드 장애 시에 VM HA 기능 활용
  • 중앙 집중화된 스토리지의 사용을 요구

이슈는 다음과 같다.

  • VM의 수가 증가함에 따라 스토리지에 대한 수요 증가
  • 스토리지 어레이의 스케일-아웃에 대한 요구사항은 사일로우 수 및 복잡성을 증가시킴
  • 스토리지 어레이에 대한 요구사항은 GB 당 가격을 상승시킴
  • 스토리지 어레이에서 자원의 사용을 위한 경합 증가
  • 다음과 같은 요구사항을 보장하기 위해 스토리지 설정이 복잡해짐
    • 데이터스토어/LUN 당 VM 비율
    • I/O 요구사항을 만족하기 위한 스핀들 카운트(Spindle Count)

1.1.6 SSDs (Solid State Disks)

SSD는 대규모의 디스크 인클로저에 대한 필요 없이 높은 I/O 성능을 제공함으로써 I/O 병목현상을 줄여준다. 그러나, 성능 측면에서 괄목할만한 진보가 이루어졌지만, 컨트롤러 및 네트워크가 가용한 대용량의 I/O를 처리할 수 있도록 발전하지 못했다. SSD의 주요 특징은 다음과 같다.

  • 전통적인 HDD에 비해 I/O 성능이 매우 뛰어남
  • 탐색 시간을 근본적으로 제거

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

  • 병목현상이 디스크의 스토리지 I/O에서 컨트롤러 및 네트워크로 이동
  • 사일로우 이슈가 해결된 것은 아님
  • 어레이 설정의 복잡성은 여전히 존재

1.1.7 클라우드 시대 (In Comes Cloud)

“클라우드”의 정의는 매우 모호하다. 간단하게 클라우드는 어느 누군가에 의해 어딘가에서 제공되는 호스트팅된 서비스(Hosted Services)를 사용할 수 있다는 것을 의미한다.

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

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

클라우드 서비스의 특징은 다음과 같다.

  • 셀프 서비스 / 온 디멘드
    • 빠른 시간 가치(TTV: Time to value) / 진입 장벽이 거의 없음
  • 서비스 및 SLA 중심
    • 계약에 의해 가동시간, 가용성, 성능 등을 보장
  • 종량제 기반 모델
    • 사용량에 따라 비용 지불 (일부 서비스는 무료)

클라우드 분류 (Cloud Classification)

일반적으로 클라우드 서비스는 다음과 같은 세가지 카테고리로 분류된다.

  • SaaS (Software as a Service)
    • 소프트웨어 및 서비스를 간단한 URL을 통해 사용
    • Examples: Workday, Salesfoce.com, Google 검색 등
  • PaaS (Platform as a Service)
    • 개발 및 배포 플랫폼
    • Examples: Amazon Elastic Beanstalk / Relational Database Services (RDS), Google App Engine 등
  • IaaS (Infrastructure as a Service)
    • 서비스로 VM, 컨테이너, NFV 제공
    • Examples: Amazon EC2/ECS, Microsoft Azure, Google Compute Engine (GCE), etc.

IT 관점의 변화 (Shift in IT focus)

클라우드는 IT 담당자에게 매우 흥미로운 딜레마를 제공한다. IT는 클라우드를 수용하거나 또는 새로운 대안을 제공할 수 있다. IT는 데이터를 내부에 유지하면서 클라우드에서 제공하는 셀프 서비스 및 신속한 배포 등을 제공할 수 있다.

이러한 변화는 IT가 그들의 최종 사용자에게 서비스 제공자로서 보다 활발한 역할을 하도록 요구한다.

1.2 레이턴시의 중요성 (The Importance of Latency)

다음 테이블은 특정 유형의 I/O와 관련된 다양한 종류의 레이턴시를 정리한 것이다.

항목 레이턴시 비고
L1 cache reference 0.5 ns
Branch Mispredict 5 ns
L2 cache reference 7 ns 14x L1 cache
Mutex lock/unlock 25 ns
Main memory reference 100 ns 20x L2 cache, 200x L1 cache
Compress 1KB with Zippy 3,000 ns
Sent 1KB over 1Gbps network 10,000 ns 0.01 ms
Read 4K randomly from SSD 150,000 ns 0.15 ms
Read 1MB sequentially from memory 250,000 ns 0.25 ms
Round trip within datacenter 500,000 ns 0.5 ms
Read 1MB sequentially from SSD 1,000,000 ns 1 ms, 4x memory
Disk seek 10,000,000 ns 10 ms, 20x datacenter round trip
Read 1MB sequentially from disk 20,000,000 ns 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가 자신의 캐시(L1 vs. L2)에 엑세스 하는 속도는 ~0.5-7ns 이하이다. 메인 메모리인 경우에 엑세스 속도는 ~100ns 이하이다. 반면에, 로컬 4K SSD Read는 150,000ns 또는 0.15ms 이하이다.

일반적인 엔터프라이즈 클래스의 SSD (여기에서는 Intel S3700의 경우에), 이 디바이스의 성능은 다음과 같다.

  • 랜덤 I/O 성능
    • 랜덤 4K Reads: 최대 75,000 IOPS
    • 랜덤 4K Writes: 최대 36,000 IOPS
  • 순차 데이터 대역폭
    • 연속된 순차 데이터 Reads: 최대 500MB/s
    • 연속된 순차 데이터 Writes: 최대 460MB/s
  • 레이턴시(Latency)
    • Read: 50us
    • Write: 65us

1.2.1 대역폭 살펴보기 (Looking at the Bandwidth)

전통적인 스토리지인 경우에, 다음과 같은 종류의 I/O 인터페이스가 있다.

  • Fiber Channel (FC)
    • 4-, 8-, and 10-Gb
  • Ethernet (FCoE 포함)
    • 1-, 10-Gb, (40-Gb IB), etc.

하기 계산을 위해, Intel S3700에서 가용한 500MB/s Read, 460MB/s Write 대역폭을 사용한다. 계산식은 다음과 같다.

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

[NOTE] 숫자는 Partial SSD가 가능하지 않기 때문에 반올림되었다. 또한, 모든 I/O를 처리하기 위하여 필요한 CPU를 산정할 수 없기 때문에, 컨트롤러 CPU 파워를 무제한이라고 가정하였다.

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

상기의 테이블에서 보는 것과 같이, SSD가 제공할 수 있는 이론적인 최대의 성능을 사용하기 위해서는, 사용되는 네트워킹의 유형에 따라 1개의 SSD로부터 9개의 SSD를 사용하는 모든 경우에, 네트워크가 병목의 원인이 될 수 있다.

1.2.2 메모리 레이턴시의 영향 (The impact to Memory Latency)

전형적인 메모리 레이턴시는 ~100ns(가변) 인데, 계산은 다음과 같다.

  • 로컬 메모리 Read 레이턴시: 100ns + [OS / hypervisor overhead]
  • 네트워크 메모리 Read 레이턴시: 100ns + NW RTT latency + [2 x OS / hypervisor overhead]

전형적인 네트워크 RTT를 ~0.5ms(~500,000ns, 스위치 벤더에 따라 가변적임)로 가정할 경우에, 계산식은 다음과 같다.

  • 네트워크 메모리 Read 레이턴시: 100ns + 500,000ns + [2 x OS / hypervisor overhead]

이론적으로 10,000ns RTT를 갖는 초고속 네트워크를 가정하는 경우에, 계산식은 다음과 같다.

  • 네트워크 메모리 Read 레이턴시: 100ns + 10,000ns + [2 x OS / hypervisor overhead]

이것이 의미하는 것은 이론적으로 매우 빠른 네트워크라고 하더라도, non-네트워크 메모리 액세스와 비교할 때, 약 10,000%의 오버헤드가 있다. 네트워크 속도가 느린 경우에 오버헤드는 500,000%까지 증가할 수 있다.

상기와 같은 네트워크 오버헤드를 줄이기 위해, 서버에서의 캐싱 기술을 개발되었다.

1.3 Book of Web-Scale

본 섹션에서는 “웹-스케일(Web-Scale)” 인프라스트럭처의 핵심 개념과, 뉴타닉스가 “웹-스케일” 인프라스트럭처를 사용하는 이유에 대해 설명한다. 본론으로 들어가기 전에 명확하게 언급할 것은, 웹-스케일은 고객이 “웹-스케일”이 될 필요성이 있다는 것을 의미하는 것은 아니다(e.g. Google, Facebook, Microsoft). “웹-스케일”은 모든 규모에 적용할 수 있으며 많은 장점을 제공한다(3-노드 또는 수천 개의 노드).

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

  • 복잡성(Complexity), 복잡성(Complexity), 복잡성(Complexity)
  • 시스템의 단계적 또는 점진적 확장에 대한 요구
  • 민첩성(Agility) 필요

“웹-스케일” 인프라스트럭처를 이야기할 때 사용되는 주요 컨스트럭트는 다음과 같다.

  • 하이퍼컨버전스 (Hyper-convergence)
  • 소프트웨어 정의 인텔리전스 (Software defined intelligence)
  • 분산 처리 시스템 (Distributed autonomous system)
  • 점진적 및 선형적 확장 (Incremental and linear scale out)

상기 외에 “웹-스케일” 인프라스트럭처의 추가적인 요건은 다음과 같다.

  • API 기반의 자동화 및 풍부한 분석 기능 (API-based automation and rich analytics)
  • 셀프 힐링 (Self-healing)

다음 섹션에서 “웹-스케일” 인프라스트럭처의 기반을 이루는 주요 컨스트럭트가 실제적으로 무엇을 의미하는지에 대한 기술적 설명을 제공한다.

1.3.1 하이퍼컨버전스 (Hyper-convergence)

하이퍼-컨버전스가 실제적으로 무엇인지에 대해서는 여러 가지 옵션이 있다. 하이퍼-컨버전스는 컴포넌트(e.g. 가상화, 네트워킹 등)의 범위에 따라 가변적이다. 그러나, 핵심 컨셉은 다음과 같이 정의할 수 있는데, 원천적으로(Natively) 2개 또는 그 이상의 컴포넌트를 1개의 유닛으로 결합하는 것이다. 여기에서 “원천적으로(Natively)”가 키 워드(Key Word)이다. 가장 효과적인 것이 되기 위해서는, 컴포넌트가 원천적으로 통합되어야 하며, 단순히 함께 번들(Bundle Together) 되는 것은 아니다. 뉴타닉스의 경우에, 어플라이언스에서 사용되는 단일 노드를 구성하기 위해 “컴퓨트 + 스토리지”를 원천적으로 컨버지드 하였다. 다른 벤더는 스토리지를 네트워크 등과 컨버지드 하였다. 하이퍼-컨버전스가 실제적으로 의미하는 것은 다음과 같다.

  • 하이퍼-컨버전스(Hyper-Convergence)는 2개 또는 그 이상의 컴포넌트를 1개의 유닛으로 원천적으로 완벽하게 통합하여야 하고, 쉽게 확장할 수 있어야 한다.

하이퍼-컨버전스의 장점은 다음과 같다.

  • 유닛 단위로 확장 (Single unit to scale)
  • 로컬 I/O 지원 (Localized I/O)
  • 컴퓨트와 스토리지를 컨버지드 함으로써, 전통적인 컴퓨트/스토리지 사일로우 제거

1.3.2 소프트웨어 정의 인텔리전스 (Software defined intelligence)

소프트웨어 정의 인텔리전스는 핵심 로직을 일반적으로 전용 또는 특정 하드웨어(e.g. ASIC/FPGA)에 구현하지 않고, 범용 하드웨어에서 소프트웨어로 구현하는 것을 의미한다. 뉴타닉스는 전통적인 스토리지 로직(e.g. RAID, 데이터 중복제거, 데이터 압축 등)을 표준 x86 하드웨어에서 동작하는 뉴타닉스 CVM에 포함되어 프로세스로 구동되는 소프트웨어로 구현하였다.

  • 하드웨어에 구현된 주요 로직을 범용 하드웨어에서 동작하는 소프트웨어로 구현

소프트웨어 정의 인텔리전스의 장점은 다음과 같다.

  • 빠른 릴리즈 사이클 (Rapid release cycles)
  • 전용 하드웨어에 대한 의존성을 제거 (Eliminate of proprietary hardware reliance)
  • 범용 하드웨어를 사용함으로써 가격 절감 (Utilization of commodity for better economics)

1.3.3 분산 처리 시스템 (Distributed autonomous system)

분산 자치 시스템(Distributed Autonomous Systems)은 1개의 유닛이 어떤 처리에 대한 책임을 갖는 전통적인 개념을 버리고, 클러스터 내의 모든 노드에게 해당 역할을 분산하는 것이다. 이것을 순수한 분산 시스템으로 간주할 수 있다. 전통적으로, 벤더는 하드웨어가 매우 안정적일 것이라고 가정하는데, 대부분의 경우에 이것은 사실일 수 있다. 그러나, 분산 시스템의 핵심 아이디어는 궁극적으로 모든 하드웨어에 장애가 발생할 수 있으며, 해당 장애를 우아하게 무중단적인 방법으로 처리해야 한다는 것이다.

분산 시스템은 장애를 허용하고 이를 처리할 수 있도록 설계되는데, 이것은 셀프-힐링 및 자치 기능 등을 의미한다. 컴포넌트 장애 시에, 장애 처리 및 복구 작업을 투명하게 수행하고, 설계된 대로 오퍼레이션을 지속한다. 경고(Alerting) 기능을 통하여 관리자에게 장애 상황을 알려주지만, 시간에 민감한 중요한 항목이 아닌 경우에, 어떤 복구 작업(e.g. 장애 노드 교체)은 관리자의 스케줄에 따라 수행될 수 있다. 장애를 처리하는 다른 방법은 장애가 발생한 상태로 놓아두는 것이다 (교체 없는 리빌드). “마스터(Master)”가 필요한 항목에 대해서는 마스터 선정 프로세스가 사용된다. 마스터 장애 시에, 새로운 마스터가 선정된다. 태스크 프로세싱을 분산하기 위해 맵리듀스 컨셉을 사용한다. 분산 처리 시스템의 정의는 다음과 같다.

  • 책임 및 역할을 시스템을 구성하고 있는 모든 노드에 분산
  • 태스크의 분산 처리를 위해 맵리듀스와 같은 개념을 사용
  • “마스터”가 필요한 경우에 마스터 선정 프로세스를 사용

분산 처리 시스템의 장점은 다음과 같다.

  • SPOF(Single Point Of Failure) 제거
  • 병목 현상을 없애기 위해 워크로드 분산

1.3.4 점진적 및 선형적 확장 (Incremental and linear scale out)

점진적 및 선형적 스케일-아웃은 어떤 규모의 자원으로 시작하고, 필요에 따라 시스템의 성능을 선형적으로 증가시키면서 자원을 확장할 수 있는 기능과 관련되어 있다. 상기에서 설명한 모든 컨스트럭트는 이것을 실제로 구현 가능하게 만드는 중요한 기술들이다. 예를 들어, 전통적으로 가상 워크로드를 구동하기 위해 3-티어 컴포넌트(서버, 스토리지, 네트워크)를 사용하는 경우에, 각 컴포넌트는 독립적으로 확장된다. 한가지 예로, 서버의 수를 스케일-아웃 하는 경우에, 스토리지 성능은 스케일-아웃 되지 않는다. 뉴타닉스와 같은 하이퍼-컨버지드 플랫폼은, 새로운 노드를 추가할 때, 다음과 같은 자원이 선형적으로 스케일-아웃 된다.

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

점진적 및 선형적 확장의 진정한 의미는 다음과 같다.

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

점진적 및 선형적 확장의 장점은 다음과 같다.

  • 작은 규모로 시작하고, 필요에 따라 확장
  • 클러스터 규모에 관계 없이 균일하고 일관성 있는 성능 제공

1.3.5 요약 정리

  • 비효율적인 컴퓨트 활용률이 가상화로 이동하는 계기가 되었다.
  • vMotion, HA, DRS 등과 같은 기능들은 중앙 집중화된 스토리지의 사용을 요구하였다.
  • VM의 개수가 많아짐으로 인해 스토리지의 부하 및 경합을 증가시켰다.
  • SSD가 병목 현상을 줄이기 위해 도입되었으나, 병목 현상의 원인이 네트워크/컨트롤러로 변경되었다.
  • 네트워크를 통한 캐싱/메모리 액세스 기능은 오버헤드의 증가로 인해 해당 기술의 장점이 최소화되었다.
  • 어레이 설정의 복잡성은 여전히 동일한 상태로 남아있다.
  • 서버 사이드 캐시(Service Side Cache)가 어레이 부하 및 네트워크 영향을 줄이기 위하여 도입되었으나, 솔루션에 다른 컴포넌트를 추가시켰다.
  • 로컬리티(Locality)는 전통적으로 네트워크를 사용할 때 수반되는 병목 현상 및 오버헤드를 줄이는데 도움을 준다.
  • 포커스가 인프라스트럭처에서 쉬운 관리 및 단순화된 스택으로 이동하였다.
  • 웹-스케일 월드가 구축되었다.

Part II. Book of Prism

2.1 설계 방법론 (Design Methodology)

뉴타닉스 플랫폼의 핵심 설계 방향은 간단하고 직관적인 제품을 개발하는 것이다. 본 섹션에서는 뉴타닉스의 설계 방법론에 대해서 설명한다.

뉴타닉스 설계 방법론에 대해서는 제품 설계 책임자인 Jeremy Sallee가 작성한 하기의 문서를 참조한다.
http://salleedesign.com/stuff/sdwip/blog/nutanix-case-study/

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

2.2 아키텍처

프리즘(Prism)은 분산 자원 관리 플랫폼으로, 유저는 프리즘을 통하여 뉴타닉스 환경의 오브젝트 및 서비스를 관리하고 모니터링할 수 있다.

프리즘은 다음과 같은 두 개의 카테고리로 분류할 수 있다.

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

뉴타닉스 플랫폼의 일부로서, 프리즘의 개념을 설명하는 그림은 다음과 같다.

[그림 5-1] 하이-레벨 프리즘 아키텍처


프리즘은 2개의 메인 컴포넌트로 이루어져 있다.

  • 프리즘 센트럴 (Prism Central)
    • 복수의 아크로폴리스 클러스터를 관리할 수 있는 멀티-클러스터 매니저로 1개의 중앙 집중화된 관리 인터페이스를 제공한다. 프리즘 센트럴은 선택적인 소프트웨어 어플라이언스(VM)로 관리자가 아크로폴리스 클러스터에 수동으로 설치하여야 한다.
    • 1-to-Many 클러스터 매니저
  • 프리즘 엘리먼트 (Prism Element)
    • 로컬 클러스터 관리 및 오퍼레이션을 위한 로컬 클러스터 매니저이다. 모든 아크로폴리스 클러스터는 내장된 프리즘 엘리먼트를 갖는다.
    • 1-to-1 클러스터 매니저

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

[그림 5-2] 프리즘 아키텍처

PRO TIP

대규모 또는 복수 사이트의 분산 배포를 위해서는 오퍼레이션의 단순화 및 모든 클러스터/사이트에 대한 단일 관리 UI 제공을 위해 프리즘 센트럴의 사용을 권고한다.


2.2.1 프리즘 서비스 (Prism Services)

프리즘 서비스는 모든 CVM에 탑재되어 있으며, 리더로 선정된 프리즘은 모든 HTTP 요청의 처리에 대한 책임을 갖는다. 마스터를 갖는 다른 컴포넌트와 유사하게, 만약 프리즘 리더에 장애가 발생하면, 새로운 프리즘이 리더로 선정된다. 프리즘 리더가 아닌 CVM이 HTTP 요청을 받으면, HTTP 응답 상태 코드인 “301’을 사용하여 프리즘 리더로 리다이렉트 된다.

프리즘 서비스 및 HTTP 요청의 처리 흐름에 대한 개념도는 다음 그림과 같다.


[그림 5-3] 프리즘 서비스 – 요청 처리


프리즘 포트 (Prism Ports)

프리즘은 80, 9440 포트를 사용한다. 만약 80번 포트로 들어오면, 해당 요청은 HTTPS인 9440 포트로 리다이렉트 된다.


뉴타닉스가 권고하는 클러스터 외부 IP를 사용하는 경우에는, 클러스터 외부 IP는 현재의 프리즘 리더로 매핑되어 있으므로, HTTP 요청은 프리즘 리더로 전달된다. 프리즘 리더에 장애가 발생하면, 클러스터 외부 IP는 새롭게 선정된 프리즘 리더로 매핑되며, Gratuitous ARP (gARP)를 사용하여 ARP 캐시를 삭제한다.


PRO TIP

클러스터의 임의의 CVM에서 “curl localhost:2019/prism/leader” 명령어를 이용하여 현재 프리즘 리더로 동작하고 있는 노드를 확인할 수 있다.


2.3 네비게이션 (Navigation)

프리즘은 매우 직관적이고 사용하기 간단하다. 본 섹션에서는 프리즘의 메인 페이지 및 기본적인 사용 방법에 대해 설명한다.

프리즘 센트럴(배포된 경우에)은 설정 단계에서 지정한 IP 또는 상응하는 DNS 엔트리를 이용하여 접속할 수 있다. 프리즘 엘리먼트는 프리즘 센트럴(특정 클러스터를 클릭)에서 또는 임의의 뉴타닉스 CVM으로의 네비게이션을 통해 또는 클러스터 IP(권고하는 방법)로 액세스할 수 있다.

프리즘으로 접속하면, 첫 번째로 로그인 페이지가 디스플레이 되며, 프리즘의 로컬 사용자 계정 또는 Active Directory 계정을 이용하여 로그인 할 수 있다.


[그림 6-1] 프리즘 로그인 페이지

프리즘에 로그인 하면, 프리즘 센트럴이 관리하는 모든 클러스터 또는 프리즘 엘리먼트에서 관리하는 로컬 클러스터의 상태 정보를 제공하는 대시보드(Dashboard) 페이지가 디스플레이 된다.

다음 섹션에서 프리즘 센트럴 및 프리즘 엘리먼트에 대한 자세히 설명한다.

2.3.1 프리즘 센트럴 (Prism Central)

프리즘 센트럴은 다음과 같은 메인 페이지를 포함한다.

  • Home Page
    • 클러스터 모니터링을 위한 대시보드로 클러스터의 서비스 상태, 용량 계획, 성능, 태스크 등과 관련된 상세한 정보를 제공한다. 관심 있는 아이템을 클릭하면 보다 상세한 정보를 확인할 수 있다.
  • Explorer Page
    • 서비스, 클러스터, VM, 호스트에 대한 관리 및 모니터링
  • Analysis Page
    • 이벤트와 관련된 클러스터 및 관리 오브젝트에 대한 상세한 성능 분석 정보 제공
  • Alerts
    • 클러스터 레벨의 경고(Alerts) 정보 제공

복수의 클러스터를 관리하고 모니터링 할 수 있는 프리즘 센트럴 대시보드 화면은 다음과 같다.

[그림 6-2] 프리즘 센트럴 대시보드

상기 화면에서 클러스터 환경에 대한 전체적인 상태를 모니터링할 수 있으며, 경고 또는 특정 항목을 클릭함으로써 보다 상세한 정보를 확인할 수 있다.


PRO TIP

만약 모든 상태가 GREEN이면, 클러스터가 정상적인 상태이다.


2.3.2 프리즘 엘리먼트 (Prism Element)

프리즘 엘리먼트는 다음과 같은 페이지를 포함한다.

  • Home Page
    • 로컬 클러스터 모니터링 대시보드로 경고, 용량, 성능, 헬스, 태스크 등과 관련된 상세한 정보를 제공한다. 관심 있는 아이템을 클릭하면, 보다 상세한 정보를 확인할 수 있다.
  • Health Page
    • NCC 헬스 체크 상태 정보를 포함하여 환경, 하드웨어 및 관리 오브젝트의 헬스 및 상태 정보 제공
  • VM Page
    • 전체 VM 관리, 모니터링 및 CRUD (AHV)
    • VM 모니터링 (AHV 이외)
  • Storage Page
    • 컨테이너 관리, 모니터링 및 CRUD
  • Hardware Page
    • 서버, 디스크, 네트워크 관리, 모니터링 및 헬스, 클러스터 확장, 노드 및 디스크 제거
  • Data Protection Page
    • DR, Cloud Connect, Metro Availability 설정, PD 오브젝트 관리, 스냅샷, 복제 및 복구
  • Analysis Page
    • 이벤트와 관련된 클러스터 및 관리 오브젝트에 대한 상세한 분석 정보 제공
  • Alerts Page
    • 로컬 클러스터 및 환경 경고(Alerts) 정보 제공

Home Page는 경고, 서비스 상태, 용량, 성능, 태스크 등을 포함하여 다양하고 풍부한 상세 정보를 제공한다. 관심 있는 아이템을 클릭하면, 보다 상세한 정보를 확인할 수 있다.

로컬 클러스터 상세 정보를 제공하는 프리즘 엘리먼트 대시보드는 다음과 같다.

[그림 6-3] 프리즘 엘리먼트 대시보드

2.3.3 단축 키 (Keyboard Shortcuts)

프리즘에서 가장 중요한 기능 중의 하나는 접근성 및 사용 편의성이다. 최종 사용자의 편의성을 위하여 몇 개의 단축키가 추가되었으므로 사용자는 키보드 만을 이용하여 많을 작업을 쉽게 수행할 수 있다.

단축키는 다음과 같다.

View 변경 (페이지 내에서)

  • O - Overview View
  • D - Diagram View
  • T - Table View

Activities and Events

  • A - Alerts
  • P - Tasks

드롭 다운 및 메뉴 (화살표 키를 사용하여 섹션을 이동)

  • M - Menu drop-down
  • S - Settings (gear icon)
  • F - Search bar
  • U - User drop down
  • H - Help

2.4 사용 방법 및 Troubleshooting

본 섹션에서는 프리즘의 주요 기능과 일반적인 Troubleshooting 시나리오에 대해 설명한다.

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

뉴타닉스 소프트웨어를 업그레이드하는 작업은 매우 간단하며, 클러스터 서비스의 중단 없이 수행할 수 있다.

뉴타닉스 소프트웨어 업그레이드 작업을 진행하기 위해서는, 프리즘에 로그인 한 후에 셋팅 메뉴에서 “Upgrade Software”를 선택하거나 단축키인 "S"키를 누른다.

[그림 7-1] 프리즘 – 셋팅 – 업그레이드 소프트웨어

다음 그림과 같이 “Upgrade Software” 다이얼로그 박스가 디스플레이 되고, 현재 동작중인 소프트웨어 버전, 그리고 가용한 업그레이드 버전 정보를 제공한다. NOS 바이너리 이미지의 수작업 업로드도 가능하다.

업그레이드 버전을 클라우드에서 다운로드 받고, 해당 버전을 수작업으로 업로드 할 수 있다.

[그림 7-2] 업그레이드 소프트웨어 – 메인


업그레이드 대상 소프트웨어를 뉴타닉스 CVM으로 업로드 한다.

[그림 7-3] 업그레이드 소프트웨어 – 업로드


업로드 작업이 종료되면, “Upgrade” 버튼을 클릭하여 업그레이드 작업을 시작한다.

[그림 7-4] 업그레이드 소프트웨어 – 업그레이드 정합성 체크


업그레이드할 소프트웨어의 정합성 체크에 문제가 없는 경우에, 다음과 같이 “확인” 다이얼로그 박스가 디스플레이 된다.

[그림 7-5] 업그레이드 소프트웨어 – 업그레이드 확인


업그레이드 작업을 시작하기 전에, 사전 정합성 체크 작업을 수행하고, 문제가 없으면 업그레이드 작업을 시작한다. 업그레이드는 롤링 방식으로 진행되는데, 업그레이드할 바이너리 이미지의 Write 작업은 모든 노드에서 동시에 수행되고, 업그레이드한 소프트웨어의 적용을 위한 재부팅 작업은 순차적으로 수행된다.

[그림 7-6] 업그레이드 소프트웨어 – 업그레이드 작업 수행


업그레이드 작업이 완료되고, 업그레이드한 소프트웨어의 버전이 표시되면, 업그레이드 된 버전에 포함되어 있는 새로운 기능을 즉시 사용할 수 있다.

[그림 7-7] 업그레이드 소프트웨어 – 업그레이드 작업 완료


NOTE

프리즘 리더 노드를 업그레이드 하는 동안에 프리즘 세션이 잠시 끊어질 수 있다. 그러나 모든 VM 및 서비스에는 영향이 없다


2.4.2 하이퍼바이저 업그레이드 (Hypervisor Upgrade)

뉴타닉스 소프트웨어 업그레이드 작업과 유사하게, 프리즘에서 하이퍼바이저 업그레이드 작업은 롤링 방식으로 완전 자동화되어 있다.

하이퍼바이저 업그레이드를 위해서는 “Upgrade Software” 다이얼로그 박스에서 “Hypervisor” 탭을 클릭한다.

하이퍼바이저 업그레이드 버전을 클라우드에서 다운로드 받고, 해당 버전을 수동으로 업로드 할 수 있다.


[그림 7-8] 업그레이드 하이퍼바이저 – 메인


업그레이드 대상 소프트웨어를 하이퍼바이저로 업로드 한다. 업그레이드 소프트웨어의 업로드 작업이 완료되면, “Upgrade” 버튼을 클릭하여 업그레이드 프로세스를 시작한다.

[그림 7-9] 업그레이드 하이퍼바이저 – 업그레이드 정합성 체크


업그레이드할 하이퍼바이저의 정합성 체크에 문제가 없는 경우에 다음과 같이 “확인” 다이얼로그 박스가 디스플레이 된다.

[그림 7-10] 업그레이드 하이퍼바이저 – 업그레이드 확인


시스템은 호스트 사전 업그레이드 체크(Host Pre-Upgrade Check) 작업을 수행하고, 하이퍼바이저 업그레이드 버전을 클러스터에 업로드 한다.

[그림 7-11] 업그레이드 하이퍼바이저 – 업그레이드 사전 체크


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

[그림 7-12] 업그레이드 하이퍼바이저 – 업그레이드 작업 수행


롤링 방식으로 진행되는 뉴타닉스 소프트웨어 업그레이드 작업과 유사하게, 각 호스트는 동작중인 VM에 전혀 영향을 주지 않고, 롤링 방식으로 업그레이드 된다. 호스트에서 동작중인 VM의 라이브 마이그레이션 작업이 수행되고, 호스트를 업그레이드 한 후에, 해당 호스트는 재부팅 된다. 모든 호스트의 업그레이드 작업이 완료될 때까지 동일한 작업을 반복한다.


PRO TIP

클러스터에서 임의의 CVM에서 “host_upgrade –status” 명령어를 사용하여 클러스터 레벨의 업그레이드 상태를 확인할 수 있다. 상세한 호스트 업그레이드 상태 정보는 “~/data/logs/host_upgrade.out” 파일에 기록된다.


업그레이드 작업이 완료되면, 업그레이드한 소프트웨어의 버전이 표시되고, 업그레이드 된 버전에 포함되어 있는 새로운 기능을 즉시 사용할 수 있다.

[그림 7-13] 업그레이드 하이퍼바이저 – 업그레이드 작업 완료


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

아크로폴리스 클러스터를 동적으로 확장할 수 있는 능력은 뉴타닉스 플랫폼의 핵심 기능이다. 아크로폴리스 클러스터를 확장하기 위해서는, 노드를 랙에 장착하고 케이블을 연결한 후에 전원을 인가한다. 일단 노드의 전원이 인가되면, 클러스터는 mDNS를 사용하여 확장 대상이 되는 노드들을 자동으로 검색한다.

다음 그림은 7개의 노드로 구성된 클러스터에서, 추가할 1개의 노드에 대한 정보를 보여준다.

[그림 7-14] 노드 추가 – 검색


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

일단 추가할 노드가 검색되면, “Hardware” Page에서 “Expand Cluster” 버튼을 클릭하여 노드 추가 작업을 시작할 수 있다.

[그림 7-15] 하드웨어 페이지 – Expand Cluster


또한, 셋팅 메뉴에서 “Expand Cluster” 메뉴를 클릭하여 노드 추가 작업을 수행할 수 있다.

[그림 7-16] 셋팅 메뉴 – Expand Cluster


“Expand Cluster” 메뉴를 선택하면, 다음 그림과 같은 다이얼로그 박스가 디스플레이 된다. 추가할 노드를 선택하고, Controller VM, 하이퍼바이저, IPMI IP 정보를 입력한다.

[그림 7-17] 클러스터 확장 – 호스트 선택


호스트를 선택한 후에, 추가될 노드의 하이퍼바이저 버전이 기존 노드의 버전과 다른 경우에, 하이퍼바이저를 업그레이드하여야 한다. 다음 메뉴에서 업그레이드 할 하이퍼바이저를 업로드 한다.

[그림 7-18] 클러스터 확장 – 호스트 설정


업로드가 완료되면, “Expand Cluster” 버튼을 클릭하여 이미징 및 노드 추가 작업을 시작한다.

[그림 7-19] 클러스터 확장 – 작업 시작


잡(Job)이 제출되고, 상응하는 태스크 아이템이 다음과 같이 디스플레이 된다.

[그림 7-20] 클러스터 확장 – 작업 수행


상세한 작업 상태는 해당 태스크를 선택하여 확인할 수 있다.

[그림 7-21] 클러스터 확장 – 상세 작업 상태


이미징 및 노드 추가 작업이 완료되면, 갱신된 클러스터 사이즈 및 자원 정보를 확인할 수 있다.

[그림 7-22] 클러스터 확장 – 노드 추가 작업 완료


2.4.4 입출력 매트릭스 (I/O Metrics)

성능과 관련된 이슈를 해결하는 과정에서 병목현상을 찾아내는 것은 매우 중요한 작업이다. 이러한 과정을 지원하기 위해, 뉴타닉스는 VM 페이지에 I/O Metrics 섹션을 추가하였다.

레이턴시는 매우 다양한 변수(큐의 길이, I/O 사이즈, 시스템 조건, 네트워크 속도 등)에 의해 결정된다. I/O Metrics 페이지는 I/O 사이즈, 레이턴시, 소스 및 패턴과 관련된 인사이트(Insight)를 제공하는데 도움을 준다.

I/O Metrics를 사용하기 위해서는, VM 페이지로 이동한 후에 테이블에서 해당 VM을 선택한다. 다음은 VM 페이지에서 제공하는 I/O Metrics 이다.

[그림] VM 페이지 - 상세

VM 테이블의 하단에서 I/O Metrics 탭을 찾을 수 있다.

[그림] VM 페이지 - I/O Metrics 탭

I/O Metrics 탭을 선택하면 상세한 정보가 디스플레이 된다. 다음에서 I/O Metrics 탭에서 제공하는 정보를 세분화하여 어떻게 활용할 수 있는지를 설명한다.

첫 번째로, “Avg I/O Latency” 섹션은 과거 3시간 동안의 평균 R/W 레이턴시 정보를 제공한다. 디폴트로, 가장 최근의 레이턴시 값이 디스플레이 된다.

물론 마우스를 이용하여 특정 시간 대의 레이턴시 값을 확인할 수 있다.

[그림] I/O Metrics - 레이턴시

본 정보는 갑작스러운 스파이크가 발생하였을 때 매우 유용하다. 스파이크가 발생하였을 경우에, 좀 더 상세한 분석을 위해서는 스파이크를 클릭하고 추가적으로 제공되는 상세 정보를 분석한다.

[그림] I/O Metrics - 레이턴시

만약 레이턴시가 정상적이면, 상세 분석을 진행할 필요가 없다.

다음 섹션에서는 Read/Write I/O 사이즈에 대한 히스토그램 정보를 디스플레이 한다.

[그림] I/O Metrics - I/O 사이즈 히스토그램

다음 그림은 4K ~ 32K 범위의 Read I/O 사이즈 히스토그램 정보이다.

[그림] I/O Metrics - Read I/O 사이즈 히스토그램

다음 그림은 16K ~ 64K (최대 512K까지) 범위의 Write I/O 사이즈 히스토그램 정보이다.

[그림] I/O Metrics - Write I/O 사이즈 히스토그램


PRO TIP

레이턴시 스파이크가 발생하였을 때, 첫 번째로 확인해야 할 사항은 I/O 사이즈이다. I/O 사이즈가 작을 (4K ~ 32K) 때 보다는 I/O 사이즈가 클수록 (64K ~ 1MB) 레이턴시가 커진다.


다음 섹션에서는 Read/Write I/O에 대한 I/O 레이턴시 히스토그램 정보를 디스플레이 한다.

[그림] I/O Metrics – 레이턴시 히스토그램

Read 레이턴시 히스토그램을 살펴보면, 대부분의 Read I/O는 1ms 이내에서 처리된다 (일부 Read I/O는 2~5ms 범위에서 처리).

[그림] I/O Metrics – Read 레이턴시 히스토그램

“Read Source”를 분석하면, 대부분의 I/O는 SSD 티어에서 서비스 된다.

[그림] I/O Metrics – Read Source SSD

데이터 Read 요청 시에, 데이터는 실시간으로 Unified Cache (DRAM + SSD) 영역으로 이동된다(“I/O Path and Cache” 섹션 참조). 즉, 데이터는 Cache 영역으로 이동되고, DRAM으로부터 서비스 된다.

[그림] I/O Metrics – Read Source DRAM

결국, 기본적으로 모든 Read I/O 레이턴시는 1ms 이내에서 서비스 된다.

[그림] I/O Metrics – Read 레이턴시 히스토그램

대부분의 Write I/O 레이턴시는 1~2ms 이내의 범위에서 서비스 된다.

[그림] I/O Metrics – Write 레이턴시 히스토그램


PRO TIP

만약 Read 레이턴시에서 스파이크가 발생하였는데, I/O 사이즈가 크지 않다면, Read I/O가 어디에서 서비스 되고 있는지를 확인하여야 한다. 초기에 HDD 영역에서 Read가 발생하면 DRAM Cache 영역에서 Read가 발생할 때 보다 레이턴시가 커진다. 그러나, 데이터가 캐싱되고 난 이후에 모든 Read는 DRAM 영역에서 처리되기 때문에 레이턴시 측면에서 성능이 개선되는 것을 확인할 수 있다.


마지막 섹션에서는 I/O 패턴(랜덤 데이터 vs. 순차 데이터)에 대한 정보를 디스플레이 한다.

[그림] I/O Metrics – 랜덤 데이터 vs 순차 데이터

일반적으로 I/O 패턴은 애플리케이션 또는 워크로드에 따라 가변적이다 (e.g. VDI는 주로 랜덤 데이터인 반면에 하둡은 기본적으로 순차 데이터임). 일반적으로 대부분의 워크로드에는 랜덤 데이터와 순차 데이터가 혼합되어 있다. 예를 들어, 데이터베이스에서 INSERT 및 일부 Query 데이터는 랜덤 데이터인 반면에 ETL 작업은 순차 데이터이다.


2.4.5 용량 계획 (Capacity Planning)

프리즘 센트럴의 “Cluster Runway” 섹션에서 특정 클러스터를 클릭하면, 용량 계획과 관련된 상세 정보를 얻을 수 있다.

[그림 7-23] 프리즘 센트럴 – 용량 계획

상기 메뉴는 클러스터 운영과 관련된 상세한 정보를 제공하는데, 본 정보를 활용하여 부족한 자원이 무엇인지를 확인할 수 있다. 또한, 자원을 가장 많이 사용하고 있는 VM은 무엇인지, 클러스터 확장을 위해 가장 적합한 노드 타입은 무엇인지에 대한 상세한 정보 등을 확인할 수 있다.

[그림 7-24] 프리즘 센트럴 – 용량 계획 – 권고

HTML5는 프리즘에서 쉽고, 간단하며, 직관적인 관리 인터페이스를 제공하기 위한 핵심 기술이다. 또 다른 핵심 기능은 자동화를 위해 필수적인 API의 제공이다. 프리즘 UI에서 제공되는 모든 기능은 REST API를 통하여 제공되기 때문에, 유저는 REST API를 사용하여 뉴타닉스 플랫폼을 위한 전용 콘솔의 개발이 가능하며, 작업을 자동화할 수 있다.

다음 섹션에서는 뉴타닉스 플랫폼이 제공하는 API 및 사용 예제를 설명한다.


2.5 APIs and Interfaces

뉴타닉스는 소프트웨어-정의(Software-defined) 환경과 같은 매우 동적인 환경을 지원하기 위해 다양한 API 및 인터페이스를 제공하기 때문에, 유저는 이러한 API 및 인터페이스를 사용하여 자신의 목적에 맞는 프로그램 및 관리 인터페이스를 작성할 수 있다. 뉴타닉스가 제공하는 주요 인터페이스는 다음과 같다.

  • REST API
  • CLI: ACLI & NCLI
  • Scripting Interfaces

프리즘 UI에서 제공되는 모든 기능이 REST API로 제공되기 때문에, 유저는 REST API를 이용하여 자동화된 기능 및 통합 기능을 쉽게 구축할 수 있다. 즉, 유저는 Saltstack, Puppet, vRealize Operations, System Center Orchestrator, Ansible 등과 같은 TOOL과 연동하여 자신의 환경에 맞는 전용 워크플로우를 작성할 수 있다.

뉴타닉스는 REST API Explorer를 제공하는데, 이것을 이용하여 뉴타닉스가 제공하는 모든 REST API 동작을 직접 확인할 수 있다

[그림 8-1] 프리즘 REST API Explorer

각 API를 클릭하면 API의 상세 정보 및 REST 호출에 대한 예제를 확인할 수 있다.

[그림 8-2] 프리즘 REST API 호출 예제


API 인증 스킴 (API Authentication Scheme)

뉴타닉스 소프트웨어 버전 4.5부터 클라이언트 및 HTTP 호출 인증을 위해 HTTPS 기본 인증을 사용한다.


2.5.1 ACLI

ACLI (Acropolis CLI)는 뉴타닉스 제품의 아크로폴리스(Acropolis)에서 제공되는 기능을 관리하기 위한 CLI로 뉴타닉스 소프트웨어 4.1.2 이상의 버전에서 지원한다.

[NOTE] ACLI에서 제공되는 대부분의 기능은 HTML5 GUI 및 REST API로 지원된다.

ACLI shell 사용

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

acli

또는

설명: Linux shell에서 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 및 VM 명 / UUID, MAC 주소, IP 주소 등을 포함하는 상세 정보 출력

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.clone <CLONE NAME(S)> clone_from_vm=<SOURCE VM NAME>

Example: vm.clone testClone clone_from_vm=MYBASEVM

기존 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에 추가

설명: 디스크를 생성하여 VM에 추가

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

NIC을 VM에 추가

설명: NIC을 VM에 추가

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

Example: vm.nic_create testVM network=vlan.100

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

설명: 지정한 디스크 ID로부터 부팅하도록 설정

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

Example: vm.update_boot_device testVM disk_addr=scsi.0

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

설명: 지정한 CD-ROM으로부터 부팅하도록 설정

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

Example: vm.update_boot_device testVM disk_addr=ide.0

ISO를 CD-ROM에 마운트

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

단계:
1. ISO 이미지를 컨테이너에 업로드
2. 클라이언트 IP에 대한 Whitelist 설정
3. ISO를 share에 업로드

ISO를 가지는 CD-ROM 생성

vm.disk_create <VM NAME> clone_nfs_file=<PATH TO ISO> cdrom=true

Example: vm.disk_create testVM clone_nfs_file=/default/ISOs/myfile.iso cdrom=true

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

vm.disk_update <VM NAME> <CDROM 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> <CDROM BUS> empty=true

VM의 전원 인가

설명: VM의 전원 인가

vm.on <VM NAME(S)>

Example: vm.on testVM

모든 VM의 전원 인가

Example: vm.on *

Prefix와 매칭되는 모든 VM의 전원 인가

Example: vm.on testVM*

특정 범위 내에 있는 VM의 전원 인가

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


2.5.2 NCLI

[NOTE] 본 섹션에서 설명하는 NCLI의 모든 기능은 HTML5 및 REST API에서 지원된다. NCLI 명령어는 자동화 등 특정 목적을 위해서 사용할 수 있다.

NFS whitelist에 서브넷 추가

설명: NFS whitelist에 특정 서브넷을 추가

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으로 Copy

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

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

퍼블릭 키 제거

설명: 클라이언트 액세스를 위해 등록되어 있는 퍼블릭 키 제거

ncli cluster remove-public-keys name=myPK

보호 도메인 (Protection Domain) 생성

설명: 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 파일 (aka 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>

스냅샷 생성 및 복제 스케줄 생성

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

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를 Activate

ncli pd activate name=<PD NAME>

DSF 쉐도우 클론 활성화

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

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

vDisk의 데이터 중복제거 설정

설명: 지정된 vDisk에 대한 Fingerprinting 및 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


2.5.3 PowerShell CMDlets

본 섹션에서는 뉴타닉스 PowerShell CMDlets의 사용법에 대해 설명한다.

기본 설명

Windows PowerShell은 .NET 프레임워크에 포함되어 있는 강력한 shell 및 스크립트 언어이다. PowerShell은 Interactive 방식으로 사용하기 매우 간단하며 직관적이다. PowerShell은 몇 개의 컨스트럭트 및 아이템을 포함하고 있다.

CMDlets

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

Piping or Pipelining

Piping은 PowerShell에서 매우 중요한 기능으로, 정확하게 사용하면 작업을 단순화하는데 매우 유용하다. 즉, Piping을 이용하면, 이전 명령어에서 수행된 결과 값을 새로운 명령어의 입력 값으로 지정할 수 있다. 간단한 예는 다음과 같이, 현재 프로세스의 목록을 가져와서, 필터링을 한 후에, 정렬하는 작업이다.

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

Piping은 for-each를 대신하여 사용할 수 있다.

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

주요 오브젝트 타입

PowerShell의 주요 오브젝트 타입에 대해 설명한다. getType() 메소드를 사용하여 오브젝트 타입에 대한 정보를 쉽게 얻을 수 있다. 예를 들어, $someVariable.getType() 명령어는 해당 변수의 오브젝트 타입을 반환한다.

변수 (Variable)

$myVariable = "foo"

[NOTE] 명령어의 결과 값 또는 파이프라인에 변수를 지정할 수 있다.

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

상기의 예에서, 괄호 안의 명령어가 먼저 수행되고, 결과 값이 변수에 할당된다.

배열 (Array)

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

[NOTE] 배열, 해시테이블, 커스텀 오브젝트에 대한 배열을 지정할 수 있다.

해시 테이블 (Hash Table)

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

유용한 명령어

다음 명령어는 특정한 CMDlet에 대한 도움말을 출력한다.

Get-Help <CMDlet Name>

Example: Get-Help Get-Process

명령어 또는 오브젝트의 속성 및 메소드를 출력한다.

<Some expression or object> | Get-Member

Example: $someObject | Get-Member


뉴타닉스 CMDlets 및 사용 방법

뉴타닉스 CMDlets Installer를 다운로드 한다. 뉴타닉스 CMDlets는 프리즘 4.0.1 이상의 버전에서 다운로드 받을 수 있다.

[그림 8-3] 프리즘 CMDlets Installer 링크


뉴타닉스 Snappin 로드

뉴타닉스 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

뉴타닉스 Consistency Groups 가져오기

Set to variable

$cgs = Get-NTNXProtectionDomainConsistencyGroup

Interactive

Get-NTNXProtectionDomainConsistencyGroup

Interactive and formatted

Get-NTNXProtectionDomainConsistencyGroup | ft


리소스 및 스크립트

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


2.6 통합 (Integrations)

2.6.1 오픈스택 (OpenStack)

오픈스택(OpenStack)은 클라우드 구축 및 관리를 위한 오픈 소스 플랫폼이다. 오픈스택은 크게 프론트엔드(대시보드 및 API)와 인프라스트럭처 서비스(컴퓨트, 스토리지 등)로 구분된다.

오픈스택과 뉴타닉스 솔루션은 다음과 같은 컴포넌트로 구성되어 있다.

  • 오픈스택 컨트롤러 (OpenStack Controller)
    • OpenStack UI, API, 서비스를 호스팅하고 있는 기존 또는 새롭게 프로비저닝된 VM 또는 호스트이다. 모든 OpenStack API 호출을 처리한다. 아크로폴리스 OVM 배포 환경에서 오픈스택 컨트롤러는 아크로폴리스 OpenStack Deriver와 같은 호스트에 위치할 수 있다.
  • 아크로폴리스 오픈스택 드라이버 (Acropolis OpenStack Driver)
    • OSC(OpenStack Controller)로부터 OpenStack RPC를 받아 Native Acropolis API로 변환하는 역할을 수행한다. 본 컴포넌트는 OSC, OVM과 같이 배포될 수도 있고, 새로운 VM으로 배포될 수 있다.
  • 아크로폴리스 오픈스택 서비스 VM (Acropolis OpenStack Services VM: OVM)
    • 아크로폴리스 드라이버를 포함하고 있는 VM으로 OSC로부터 OpenStack RPC를 받아 Native Acropolis API로 변환하는 역할을 수행한다.

오픈스택 컨트롤러(OSC)는 기존 VM/호스트가 될 수 있으며, 또한 뉴타닉스 솔루션에서 오픈스택의 일부로서 배포될 수 있다. 아크로폴리스 OVM은 일종의 헬퍼 VM(Helper VM)으로 뉴타닉스 오픈스택 솔루션의 일부로써 배포된다.

클라이언트는 Web UI, HTTP, SDK, CLI, API 등과 같은 메소드를 사용하여 오픈스택 컨트롤러와 통신하고, 오픈스택 컨트롤러는 아크로폴리스 OVM과 통신하는데, 아크로폴리스 OVM은 오픈스택 드라이버를 사용하여 클라이언트의 요청을 Native Acropolis REST API call로 변환한다.

뉴타닉스 오픈스택 컴포넌트들 간의 통신은 다음 그림과 같다.

[그림 9-1] 오픈스택 + 아크로폴리스 오픈스택 드라이버

상기는 복잡한 오픈스택 인프라스트럭처 및 관련된 관리 모듈 없이, 오픈스택 포털 및 API의 장점을 최대한 활용할 수 있는 아키텍처이다. 모든 백-엔드 인프라스트럭처 서비스(컴퓨트, 스토리지, 네트워크)는 뉴타닉스 Native 서비스를 활용한다. 즉, 노바 컴퓨트 호스트(Nova Compute host)를 배포할 필요가 없다. 오픈스택 서비스들을 위한 API가 공개되어 있기 때문에, OSC는 OVM과 통신하고, OVM은 OSC의 요청을 Native Acropolis API call로 변환한다. 또한, 매우 간단한 배포 모델을 지원하기 때문에, 30분 이내에 오픈스택과 뉴타닉스 솔루션을 배포할 수 있다.


지원되는 오픈스택 컨트롤러

뉴타닉스 소프트웨어 4.5.1 버전을 기준으로 할 때, 현재의 솔루션은 Kilo 버전 이상을 지원하는 OpenStack Controller 이여야 한다.


오픈스택 컴포넌트의 역할은 다음 테이블과 같다.

항목 역할 OpenStack Controller Acropolis OVM Acropolis Cluster Prism
테넌트 대시보드 사용자 인터페이스 및 API X
관리자 대시보드 인프라 모니터림 및 운영 X X
오케스트레이션 오브젝트 CRUD 및 라이프사이클 관리 X
자원 할당(Quotas) 자원 제어 및 제한 X
유저, 그룹 및 역할 역할 기반의 접근 제어(RBAC) X
SSO Single-sign on X
플랫폼 통합 오픈스택과 뉴타닉스 통합 X
인프라스트럭처 서비스 타깃 인프라스트럭처(컴퓨트, 스토리지, 네트워크) X

2.6.1.1 오픈스택 컴포넌트

오픈스택은 다양한 인프라스트럭처 서비스를 담당하고 있는 여러 개의 컴포넌트로 구성되어 있다. 이러한 컴포넌트의 일부는 오픈스택 컨트롤러에, 일부는 Acropolis OVM에 탑재된다.

핵심 오픈스택 컴포넌트들간의 역할은 다음 테이블과 같다.

컴포넌트 역할 OpenStack Controller Acropolis OVM
Keystone 아이덴터티 서비스 X
Horizon 대시보드 및 UI X
Nova 컴퓨트 X
Swift 오브젝트 스토리지 X X
Cinder 블록 스토리지 X
Glance 이미지 서비스 X X
Neutron 네트워킹 X
Heat 오케스트레이션 X
Others 모든 다른 컴포넌트 X

오픈스택 컴포넌트들간의 통신 관계는 다음 그림과 같다.

[그림 9-2] 오픈스택 – 뉴타닉스 API 통신

다음의 섹션에서 주요 오픈스택 컴포넌트가 뉴타닉스 플랫폼에 어떤 방식으로 통합되었는지를 설명한다.

노바 (Nova)

노바(Nova)는 오픈스택 플랫폼을 위한 컴퓨트 엔진 및 스케줄러이다. 뉴타닉스 오픈스택 솔루션에서 각 Acropolis OVM은 컴퓨트 호스트로서 동작하고, 모든 아크로폴리스 클러스터는 오픈스택 인스턴스 스케줄링의 대상이 되는 단일 하이퍼바이저 호스트로 동작한다. Acropolis OVM은 Nova-Compute 서비스를 구동한다.

오픈스택 포탈의 'Admin'->'System'->'Hypervisors 메뉴에서 Nova 서비스를 확인할 수 있다.

다음 그림은 Nova 서비스, 호스트 및 상태 정보를 보여준다.

[그림 9-3] 오픈스택 Nova 서비스

Nova 스케줄러는 선택된 Availability Zone에 기반하여 인스턴스를 어느 컴퓨트 호스트(Acropolis OVM)에 배정할지를 결정한다. 이러한 요청은 선택된 Acropolis OVM으로 송신되고, Acropolis OVM은 해당 요청을 타깃 호스트(i.e. 아크로폴리스 클러스터)의 Acropolis 스케줄러로 전달한다. Acropolis 스케줄러는 클러스터 내에서 최적의 노드 위치를 결정한다. 클러스터에서 개별 노드는 OpenStack에 노출되지 않는다.

오픈스택 포탈의 'Admin'->'System'->'Hypervisors' 메뉴에서 컴퓨트 및 하이퍼바이저 호스트 정보를 확인할 수 있다. Acropolis OVM이 컴퓨트 호스트로 동작하는 정보는 다음 그림과 같다.

[그림 9-4] 오픈스택 컴퓨트 호스트

Acropolis Cluster가 하이퍼바이저 호스트로 동작하는 정보는 다음 그림과 같다.

[그림 9-5] 오픈스택 하이퍼바이저 호스트

상기 그림에서 보는 것과 같이 모든 Acropolis 클러스터 리소스는 1개의 하이퍼바이저 호스트로 간주된다.

스위프트 (Swift)

스위프트(Swift)는 오브젝트 저장소로 파일의 저장 및 검색을 위해 사용된다. 현재 Swift는 스냅샷 또는 이미지의 백업/복구만을 위해 사용된다.

신더 (Cinder))

신더(Cinder)는 오픈스택의 볼륨 컴포넌트로 iSCSI target으로 제공된다. Cinder는 뉴타닉스 솔루션에서 Acropolis Volumes APIs를 사용한다. 이러한 볼륨은 인스턴스에 직접적으로 블록 디바이스로 어태치(Attached) 된다.

[그림 9-6] 오픈스택 Cinder 서비스

글랜스 / 이미지 리파지토리 (Glance / Image Repo)

글랜스(Glance)는 오픈스택을 위한 이미지 저장소로 프로비저닝을 위한 모든 가용한 이미지를 보여준다. 이미지는 ISO, 디스크, 스냅샷을 포함한다.

이미지 리파지토리(Image Repo)는 Glance에 의해 퍼블리싱 된 가용한 이미지를 저장하는 리파지토리이다. Image Repo는 뉴타닉스 환경에 위치할 수도 있고, 외부 소스에 위치할 수도 있다. 이미지가 뉴타닉스 플랫폼에 호스트 될 때, 이미지는 OVM의 Glance에 의해 오픈스택 컨트롤러로 퍼블리시 된다. 이미지가 단지 외부 소스에 위치하는 경우에 Glance는 오픈스택 컨트롤러에 의해 호스팅 되고, 아크로폴리스 클러스터에서는 이미지 캐시가 사용된다.

Glance는 클러스터 별로 활성화되고, 항상 Image Repo와 함께 위치한다. Glance가 복수의 클러스터에서 활성화될 때, Image Repo는 복수의 클러스터에 걸쳐 있게 되고, 오픈스택 포탈에서 생성된 이미지는 Glance가 동작하고 있는 모든 클러스터에 배포된다. Glance를 호스팅 하지 않는 클러스터는 이미지 캐시를 사용하여 이미지를 로컬에서 캐싱한다.


PRO TIP

대규모 배포인 경우에, Glance는 사이트 당 최소 2개의 Acropolis Cluster에서 동작해야 한다. 이렇게 하면, 클러스터 장애 시에 Image Repo HA가 동작하게 되고, 이미지가 이미지 캐시에 없을 때에도 해당 이미지는 항상 가용하게 된다.


외부 소스가 Image Repo / Glance를 호스트 할 때, Nova가 외부 소스로부터 타깃 아크로폴리스 클러스터로의 데이터 이동에 대한 책임을 갖는다. 이러한 경우에, 아크로폴리스 클러스터에서 이미지 캐시를 사용하는데, 이미지를 로컬에 캐싱하여 이미지에 대한 연속적인 프로비저닝 요청에 대응한다.

뉴트론 (Neutron)

뉴트론(Neutron)은 오픈스택의 네트워킹 컴포넌트로 네트워크 설정에 대한 책임을 갖는다. Acropolis OVM은 네트워크 CRUD 오퍼레이션이 오픈스택 포탈에 의해 수행되는 것을 가능하게 하고, 요구된 변경사항은 아크로폴리스에 적용하는 역할을 수행한다.

오픈스택 포탈의 Admin'->'System'->'System Information'->'Network Agents' 메뉴에서 Neutron 서비스를 확인할 수 있다. Neutron 서비스, 호스트 및 상태 정보는 다음 그림과 같다.

[그림 9-7] 오픈스택 Neutron 서비스

Neutron은 인스턴스가 부팅할 때 IP를 할당한다. 이러한 경우에 아크로폴리스는 VM에 할당될 IP 주소를 받는다. VM이 DHCP 요청을 수행할 때, 아크로폴리스 마스터는 늘 그렇듯이 AHV와 함께 사설 VXLAN에서 DHCP 요청에 응답한다.


지원하는 네트워크 타입

현재 버전에서는 로컬 및 VLAN 네트워크만 지원된다.


Keystone과 Horizon 컴포넌트는 Acropolis OVM과 인터페이스 하는 오픈스택 컨트롤러에서 동작한다. OVM은 오픈스택 드라이버를 포함하고 있는데, 오픈스택 드라이버는 OpenStack API call을 Native Acropolis API call로 변환하는 역할을 수행한다.

2.6.1.2 설계 및 배포

대규모 클라우드 환경의 배포를 위해서는 유연성 및 로컬리티를 제공하면서도 최종 사용자의 요구사항을 충족시킬 수 있는 분산 배포 토폴로지를 사용하는 것이 매우 중요하다.

오픈스택은 배포를 위해 다음과 같은 하이-레벨 컨스트럭트를 사용한다.

  • 지역 (Region)
    • 지역에는 복수의 Availability Zone이 위치할 수 있다. US-Northeast 또는 US-West 등이 지역에 해당한다.
  • 가용성 존 (Availability Zone)
    • 클라우드 서비스를 제공하는 특정 사이트 또는 데이터센터이다. US-Northeast-1 또는 US-West-1이 여기에 해당한다.
  • 호스트 집합 (Host Aggregate)
    • 컴퓨트 호스트의 그룹으로, Row, Aisle 또는 Site / AZ와 동일할 수 있다.
  • 컴퓨트 호스트 (Compute Host)
    • Nova-Compute 서비스를 제공하는 Acropolis OVM
  • 하이퍼바이저 호스트 (Hypervisor Host)
    • 1개의 Acropolis Cluster (1개의 호스트로 인식됨)

하이-레벨 컨스트럭트간의 관계는 다음 그림과 같다.

[그림 9-8] 오픈스택 – 배포 레이아웃


다음 그림은 컨스트럭트의 실제 배포 예이다.

[그림 9-9] 오픈스택 – 배포 레이아웃 – 예제

오픈스택 포탈의 'Admin'->'System'->'Host Aggregates' 메뉴에서 호스트(Host), 호스트 집합(Host Aggregates), 가용성 존(Availability Zone)을 관리할 수 있다.

다음 그림은 호스트(Host), 호스트 집합(Host Aggregates), 가용성 존(Availability Zone)에 대한 정보를 보여준다.

[그림 9-10] 오픈스택 호스트 집합 및 가용성 존


2.6.1.3 서비스 디자인 및 확장

뉴타닉스는 대규모 배포를 위해 로드 밸런서(Load Balancer)를 사용하여 오픈스택 컨트롤러에 복수의 Acropolis OVM을 연결할 것을 권고한다. 이러한 구조는 HA를 지원할 뿐만 아니라, 트랜젝션을 분산시킬 수 있다는 장점이 있다. Acropolis OVM은 확장을 가능하게 하기 위해 어떤 종류의 상태 정보도 갖지 않는다.

단일 사이트 환경에서 Acropolis OVM의 확장 배포는 다음 그림과 같다.

[그림 9-11] 오픈스택 – OVM 로드 밸런싱

Acropolis OVM이 상기와 같은 목적을 달성하기 위한 한 가지 메소드는 Keepalived 및 HAproxy를 사용하는 것이다.

멀티 사이트에 배포하는 경우에, 오픈스택 컨트롤러는 멀티 사이트에 존재하는 여러 개의 Acropolis OVM과 통신하여야 한다.

멀티 사이트에 배포하는 예제는 다음 그림과 같다.


[그림 9-12] 오픈스택 – 멀티 사이트


2.6.1.4 배포 (Deployment)

OVM은 CentOS / Redhat 배포 버전에서 standalone RPM으로 배포할 수도 있고, 완전한 VM으로 배포할 수도 있다. Acropolis OVM은 오픈스택 컨트롤러 및 뉴타닉스 클러스터와 네트워크 연결이 보장되기만 하면 어떤 종류의 플랫폼(Nutanix or Non-Nutanix)에 배포할 수 있다.

뉴타닉스 AHV 클러스터에서 Acropolis OVM을 VM으로 배포하는 절차는 다음과 같다. 만약 OVM이 이미 배포되었다면, VM 생성 단계를 생략할 수 있다. OVM을 배포하기 위해서는 전체 OVM 이미지를 사용할 수도 있고, 기존의 CentOS / Redhat VM 이미지를 사용할 수도 있다.

먼저, 제공된 Acropolis OVM 디스크 이미지를 아크로폴리스 클러스터로 임포트(Import) 한다. 이것은 SCP를 이용하여 디스크 이미지를 복사하거나 또는 복사할 파일의 URL을 지정하여 수행할 수 있다. 여기에서는 Images API를 이용하여 임포트 하는 방법을 설명한다.


[NOTE] Acropolis OVM을 아크로폴리스 클러스터가 아닌 다른 환경에 배포하는 것이 가능하다.


Images API를 이용하여 디스크 이미지를 임포트 하기 위해 다음 명령어를 수행한다.

image.create <IMAGE_NAME> source_url=<SOURCE_URL> container=<CONTAINER_NAME>

OVM을 위한 Acropolis 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을 생성하고 전원을 인가한 후에 제공된 인증서를 이용하여 SSH로 OVM에 접속한다.

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>

# 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

# 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 및 Neutron endpoint를 인지할 수 있도록 설정한다.

오픈스택 컨트롤러에 로그인 한 후에, keystonerc_admin source를 입력한다.

# enter keystonerc_admin
source ./keystonerc_admin

먼저, 컨트롤러를 포인팅 하고 있는 Glance에 대한 기존 엔드포인트를 삭제한다.

# Find old Glance endpoint id (port 9292)
keystone endpoint-list # Remove old keystone endpoint for Glance
keystone endpoint-delete <GLANCE_ENDPOINT_ID>

새로운 Glance 엔드포인트를 생성하고 포인트를 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

컨트롤러를 포인팅 하고 있는 Neutron에 대한 기존 엔드포인트를 삭제한다.

# Find old Neutron endpoint id (port 9696)
keystone endpoint-list # Remove old keystone endpoint for Neutron
keystone endpoint-delete <NEUTRON_ENDPOINT_ID>

새로운 Glance 엔드포인트를 생성하고 포인트를 OVM으로 지정한다.

# Find Glance service id
keystone service-list | grep glance
# 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

엔드포인트를 생성한 후에, Nova 및 Cinder가 Glance 호스트의 새로운 Acropolis 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 볼륨을 비활성화 한다(만약 이미 비활성화 하지 않았다면).

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

모든 파일을 수정한 후에, Nova 및 Cinder 서비스를 재시작 하여 새로운 설정 값이 적용되도록 한다. 다음 명령어를 사용하여 서비스를 재시작 할 수도 있고, 다운로드 받은 스크립트를 수행하여 서비스를 재시작 할 수도 있다.

# 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


2.6.2 Puppet

Puppet는 LCM (Lifecycle Configuration Management) 툴로서 DevOps, 보안 및 컴플라이언스, 프로그램에 의한 제어, 인프라스트럭처 및 App 스택의 관리를 가능하게 한다.

2.6.2.1 고급관리 및 Troubleshooting

주요 로그 파일
컴포넌트 로그 파일
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*

“*”로 표시된 로그 파일은 Acropolis OVM에서만 존재한다.

PRO TIP

OVM에서 서비스가 정상 동작 중임에도 불구하고, OpenStack Manager에서 서비스가 “DOWN”으로 표시되면 NTP를 체크한다. 대부분의 서비스가 OSC와 Acropolis 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 인스턴스의 상세 정보 출력

nova show <INSTANCE_NAME>

Nova 하이퍼바이저 호스트 목록 출력

nova hypervisor-list

Nova 하이퍼바이저 호스트의 상세 정보 출력

nova hypervisor-show <HOST_ID>

Glance 이미지 목록 출력

glance image-list

Glance 이미지의 상세 정보 출력

glance image-show <IMAGE_ID>


Part III. Book of Acropolis

3.1 아키텍처 (Architecture)

아크로폴리스(Acropolis)는 분산 멀티-리소스 매니저로, 데이터 및 플랫폼의 통합 관리를 수행한다.

아크로폴리스는 다음과 같은 세 개의 주요 컴포넌트로 구성되어 있다.

  • 분산 스토리지 패브릭 (Distributed Storage Fabric)
    • DSF는 뉴타닉스 플랫폼의 핵심 컴포넌트로 뉴타닉스 분산 파일 시스템(Nutanix Distributed Filesystem: NDFS)을 포함한다. NDFS는 스토리지 자원을 풀링(Pooling) 하는 분산 시스템으로 출발하여 대규모의 확장 가능한 스토리지 플랫폼으로 발전하였다.
  • 앱 모빌리티 패브릭 (App Mobility Fabric)
    • 하이퍼바이저가 하드웨어로부터 OS를 추상화하는데 비해, AMF는 하이퍼바이저로부터 워크로드(VM, 스토리지, 컨테이너 등)를 추상화한다. AMF는 하이퍼바이저간에 또는 클라우드간에 워크로드를 동적으로 마이그레이션 할 수 있게 할 뿐만 아니라 뉴타닉스 노드에서 하이퍼바이저를 변경할 수 있는 기능을 제공한다.
  • 하이퍼바이저
    • Acropolis Hypervisor는 뉴타닉스가 모든 책임을 갖고 제공하는 CentOS KVM 기반의 하이퍼바이저이다.

뉴타닉스 플랫폼의 모든 기능은 분산 개념에 기반하여 구현되었으며, 특히, 이러한 분산 개념을 가상화 및 자원 관리 공간으로 확장하였다. 아크로폴리스(Acropolis)는 워크로드 및 자원 관리, 프로비저닝, 오퍼레이션을 가능하게 하는 백엔드 서비스이다. 아크로폴리스의 목표는 동작중인 워크로드로부터 기반 자원(e.g. 하이퍼바이저, 온프레미스, 클라우드 등)을 추상화하여 운영을 위한 단일 플랫폼을 제공하는 것이다.

이것은 하이퍼바이저, 클라우드 사업자 및 플랫폼간에 워크로드를 자유롭게 이동시키는 것을 가능하게 한다.

아크로폴리스의 하이-레벨 아키텍처는 다음 그림과 같다.

[그림 10-1] 하이-레벨 아크로폴리스 아키텍처

VM 관리를 지원하는 하이퍼바이저

AOS 4.7 버전 기준으로, VM 관리를 지원하는 하이퍼바이저는 AHV와 ESXi이다. 그러나, VM 관리를 지원하는 하이퍼바이저의 종류를 가까운 미래에 추가할 예정이다. 현재 Volumes API 및 Read-only 오퍼레이션은 모든 하이퍼바이저에서 지원한다.

3.1.1 하이퍼컨버지드 플랫폼 (Hyperconverged Platform)

뉴타닉스 솔루션은 컨버지드 “스토리지 + 컴퓨트” 솔루션으로 로컬 컴포넌트를 사용하며 “가상 컴퓨팅 플랫폼”으로 알려진 가상화를 위한 분산 플랫폼을 생성한다. 뉴타닉스 솔루션은 “하드웨어 + 소프트웨어”가 번들된 어플라이언스 형태로 제공되며, 2U 섀시에 2개(6000/7000 series) 또는 4개(1000/2000/3000/3050 series) 노드를 장착할 수 있다.

뉴타닉스 노드에는 업계 표준 하이퍼바이저(현재 ESXi, Hyper-V, Acropolis Hypervisor 지원)와 뉴타닉스 Controller VM(CVM)이 탑재된다. 뉴타닉스 CVM은 뉴타닉스 소프트웨어를 구현한 VM으로 해당 호스트에서 동작하는 하이퍼바이저 및 모든 게스트 VM의 I/O 오퍼레이션 서비스를 제공한다. VMware vSphere가 탑재된 뉴타닉스 플랫폼에서, SSD 및 HDD 디바이스를 관리하는 iSCSI 컨트롤러는 VM-Direct Path (Intel VT-d)를 사용하여 직접적으로 CVM으로 전달된다. Hyper-V인 경우에는, 스토리지 디바이스가 CVM으로 pass-through 된다.

뉴타닉스 노드의 논리적인 구성은 다음 그림과 같다.

[그림 10-3] 컨버지드 플랫폼 (Converged Platform)

3.1.2 분산 시스템 (Distributed System)

분산 시스템(Distributed System)이 제공하여야 하는 핵심 세 가지 기능은 다음과 같다.

  • SPOF (Single Point Of Failure)가 없어야 한다.
  • 어느 규모에서든지 병목현상이 없어야 한다 (선형적인 확장이 가능하여야 한다).
  • 맵리듀스(MapReduce)를 지원하여야 한다.

뉴타닉스 노드의 그룹으로 분산 시스템(뉴타닉스 클러스터)을 구성하며, 프리즘(Prism) 및 아크로폴리스(Acropolis) 기능을 제공하는 책임을 갖는다. 모든 서비스 및 컴포넌트는 고가용성 및 어느 규모에서든 선형적인 성능을 제공하기 위하여 클러스터의 모든 CVM에 분산된다.

뉴타닉스 노드가 어떻게 뉴타닉스 클러스터를 구성하는 지에 대한 예는 다음 그림과 같다.

[그림 11-1] 뉴타닉스 클러스터 – 분산 시스템

분산 기술은 메타데이터 및 데이터에도 유사하게 적용된다. 메타데이터 및 데이터가 모든 노드 및 모든 디스크 디바이스에 분산된다는 것은, 정상적인 데이터의 입력 및 장애 시 재구축 동안에도 가능한 한 최대한의 성능을 보장할 수 있다는 것을 의미한다.

다음 그림은 각 노드가 처리해야 할 작업량이 클러스터가 확장됨에 따라 현저하게 감소하는 것을 보여준다.

[그림 11-1] 뉴타닉스 클러스터 – 분산 시스템

Key Point: 클러스터에서 노드의 수가 증가함에 따라 (클러스터 확장), 노드가 전체 작업의 일부분만을 수행하면 되기 때문에 어떤 종류의 작업은 실제적으로 매우 효율적으로 수행된다.

3.1.3 소프트웨어 정의 (Software-defined)

상기에서 언급했던 것과 같이, 뉴타닉스 플랫폼은 소프트웨어 기반의 솔루션으로 “소프트웨어 + 하드웨어”가 번들된 어플라이언스 형태로 공급된다. 뉴타닉스 소프트웨어 및 로직의 대부분을 포함하고 있는 Controller VM은 처음부터 확장 가능한 플러그인 아키텍처로 설계되었다. 하드웨어에 의존하지 않는, 순수하게 100% 소프트웨어 기반의 솔루션을 제공할 때의 가장 큰 장점은 확장성(Extensibility)에 있다. 수명주기를 갖는 다른 제품과 마찬가지로, 기존 기능의 향상 및 새로운 기능이 지속적으로 추가되어야 한다.

뉴타닉스 플랫폼은 ASIC/FPGA와 같은 어떤 종류의 하드웨어에 대한 의존성이 없기 때문에, 새로운 기능의 개발 및 배포는 단지 소프트웨어 업그레이드만으로 가능하다. 이것은 데이터 중복제거와 같은 새로운 기능을 최신 버전의 뉴타닉스 소프트웨어로 업그레이드함으로써 배포할 수 있다는 것을 의미한다. 또한, 레거시 하드웨어 모델에 차세대 기능을 제공하는 소프트웨어의 배포를 가능하게 한다. 예들 들어, NX-2400과 같이 뉴타닉스 초기 하드웨어 플랫폼과 올드 버전의 뉴타닉스 소프트웨어로 워크로드를 구동하고 있다고 가정한다. 올드 버전의 소프트웨어는 데이터 중복제거 기능을 지원하지 않기 때문에, 구동중인 워크로드는 데이터 중복제거의 장점을 활용할 수 없다. 데이터 중복제거 기능을 적용하기 위해, 워크로드가 동작중인 상태에서 뉴타닉스 소프트웨어의 롤링 업그레이드(Rolling Upgrade) 작업을 수행하면, 해당 워크로드에 데이터 중복제거 기능을 적용할 수 있다. 실질적으로 매우 쉽고 간단하다.

기능과 유사하게, DSF에 새로운 어댑터 또는 인터페이스를 생성하는 것 또한 매우 중요한 장점이다. 뉴타닉스 제품이 처음 출시된 시점에서는 하이퍼바이저로부터의 I/O를 위해 단지 iSCSI만을 지원하였는데, 현재는 NFS 및 SMB를 지원하도록 기능이 추가되었다. 뉴타닉스는 HDFS와 같이 다양한 워크로드 및 하이퍼바이저를 지원하기 위해 새로운 어댑터를 지속적으로 추가할 예정이다. 다시 반복하지만, 뉴타닉스의 모든 기능은 소프트웨어 업그레이드를 통해 배포될 수 있다. 이것은 최신 기능을 적용하기 위해 하드웨어 업그레이드 또는 일반적으로 소프트웨어 구매를 필요로 하는 대부분의 레거시 인프라스트럭처와는 반대되는 특징이다. 즉, 뉴타닉스 플랫폼은 레거시 인프라스트럭처와 다르다. 모든 기능이 소프트웨어로 배포되기 때문에, 뉴타닉스 소프트웨어는 어떤 종류의 하드웨어 플랫폼, 어떤 종류의 하이퍼바이저에서 구동할 수 있으며, 단순히 소프트웨어 업그레이드를 통해 배포할 수 있다.

소프트웨어 정의 컨트롤러 프레임워크의 논리적인 표현은 다음 그림과 같다.

[그림 10-4] 소프트웨어 정의 컨트롤러 프레임워크

3.1.4 클러스터 컴포넌트 (Cluster Components)

뉴타닉스 제품은 배포 및 운영이 매우 간단한데, 이것은 소프트웨어 측면에서 추상화(Abstraction) 자동화(Automation), 통합(Integration) 등을 통하여 가능하다.

뉴타닉스 플랫폼은 다음과 같은 하이-레벨 컴포넌트로 구성되어 있다.

[그림 10-5] 뉴타닉스 클러스터 컴포넌트

카산드라 (Cassandra)

  • 주요 역할: 분산 메타데이터 저장
  • 설명: 카산드라(Cassandra)는 분산 “Ring-like” 방식으로 모든 클러스터 메타데이터의 저장 및 관리를 수행하는데, Apache Cassandra를 대폭 수정한 것이다. “Strict Consistency”를 지원하기 위해 PAXOS 알고리즘을 적용하였다. 카산드라는 클러스터의 모든 노드에서 동작한다. 카산드라는 Medusa로 불리는 인터페이스를 통해 액세스 된다.

주키퍼 (Zookeeper)

  • 주요 역할: 클러스터 설정 관리자
  • 설명: 주키퍼(Zookeeper)는 Apache Zookeeper를 기반으로 개발되었으며, 호스트, IP 주소, 상태 등을 포함하여 클러스터 설정과 관련된 모든 정보를 저장한다. Zookeeper 서비스는 클러스터에서 3개의 노드에서 동작하며, 3개 노드 중에 임의의 노드가 리더로 선정된다. 리더는 모든 요청을 받고, 해당 요청을 다른 Zookeeper 노드로 전달한다. 만약 리더가 응답하지 않으면, 새로운 리더가 자동으로 선정된다. Zookeeper는 Zeus로 불리는 인터페이스를 통해 액세스 된다.

스타게이트 (Stargate)

  • 주요 역할: 데이터 I/O 매니저
  • 설명: 스타게이트(Stargate)는 모든 데이터 관리 및 I/O 오퍼레이션에 대한 책임을 가지며, 하이퍼바이저(via NFS, iSCSI, or SMB)부터의 메인 인터페이스이다. 스타게이트 서비스는 로컬 I/O를 지원하기 위하여 클러스터의 모든 노드에서 동작한다.

큐레이터 (Curator)

  • 주요 역할: 맵 리듀스 클러스터 관리
  • 설명: 큐레이터(Curator)는 클러스터 전체에서 태스크의 관리 및 분산에 대한 책임을 가지며, 디스크 밸런싱, 데이터 중복계수 조정 등과 같은 많은 작업을 수행한다. 큐레이터 서비스는 모든 노드에서 동작하며, 태스크(Task) 및 잡(Job) 분배에 대한 책임을 갖는 큐레이터 마스터에 의해 통제된다. 큐레이터는 2종류의 스캔 작업을 수행하는데, 전체 스캔(Full Scan)은 6시간 주기로, 부분 스캔(Partial Scan)은 1시간 주기로 수행된다.

프리즘 (Prism)

  • 주요 기능: UI 및 API
  • 설명: 프리즘(Prism)은 컴포넌트 및 관리자를 위한 관리 게이트웨이로 뉴타닉스 클러스터의 설정 및 모니터링을 지원한다. 프리즘은 nCLI, HTML5 UI, REST API를 포함한다. 프리즘 서비스는 클러스터의 모든 노드에서 동작하며, 클러스터의 다른 컴포넌트와 마찬가지로 선정된 리더를 사용한다.

제네시스(Genesis)

  • 주요 역할: 클러스터 컴포넌트 및 서비스 매니저
  • 설명: 제네시스(Genesis)는 모든 노드에서 동작하는 프로세스로 초기 설정뿐만 아니라 서비스의 시작 및 종료 등의 책임을 갖는다. 제네시스는 클러스터와 무관하게 동작하므로 클러스터의 설정 및 동작을 요구하지 않는다. 제네시스가 정상 동작하기 위해서는 주키퍼가 정상적으로 동작하여야 한다. 제네시스는 cluster_init 및 cluster_status 페이지의 정보를 출력하는 역할을 담당한다.

크로노스(Chronos)

  • 주요 역할: 잡(Job) 및 태스크(Task) 스케줄러
  • 설명: 크로노스(Chronos)는 큐레이터의 스캔 결과로 발생한 잡(Job) 및 태스크(Task)를 인계 받아, 노드들에게 태스크를 스케줄링하고 조정하는 책임을 갖는다. 크로노스는 모든 노드에서 동작하며, 선정된 크로노스 마스터에 의해 통제된다. 크로노스 마스터는 태스크 및 잡의 분배에 대한 책임을 가지며, 큐레이터 마스터와 동일한 노드에서 동작한다.

세레브로(Cerebro)

  • 주요 역할: 복제 및 DR 매니저
  • 설명: 세레브로(Cerebro)는 DSF의 복제 및 DR 기능에 대한 책임을 갖는다. 세레브로는 스냅샷 스케줄링, 리모트 사이트로의 복제, 사이트 마이그레이션 및 페일오버 기능을 수행한다. 세레브로는 클러스터의 모든 노드에서 동작하며, 모든 노드가 리모트 클러스터 또는 사이트로의 복제 작업에 참여한다.

피토스(Pithos)

  • 주요 역할: vDisk 설정 매니저
  • 설명: 피토스(Pithos)는 vDisk 설정 데이터에 대한 책임을 갖는다. 피토스는 모든 노드에서 동작하며, 카산드라 DBMS 기반에서 동작한다.

3.1.5 아크로폴리스 서비스 (Acropolis Services)

아크로폴리스 슬레이브(Acropolis Salve)는 모든 노드에서 동작하고, 임의로 선정된 아크로폴리스 마스터(Acropolis Master)는 태스크 스케줄링, 실행, IPAM 등의 오퍼레이션에 대한 책임을 갖는다. 마스터를 갖는 다른 컴포넌트와 유사하게, 아크로폴리스 마스터에 장애가 발생하면, 새로운 노드가 마스터로 선정된다.

아크로폴리스 마스터(Acropolis Master) 및 아크로폴리스 슬레이브(Acropolis Slave)의 역할은 다음과 같다.

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

아크로폴리스 마스터와 아크로폴리스 슬레이브간의 관계는 다음 그림과 같다.

[그림 10-2] 아크로폴리스 서비스


3.1.6 동적 스케줄러 (Dynamic Scheduler)

자원의 효율적인 스케줄링은 자원의 효과적인 사용을 보장하는데 매우 중요하다. ADS (Acropolis Dynamic Scheduler)는 VM의 위치를 결정하기 위하여 컴퓨트 사용률(CPU/Memory)에 기반하고 있는 전통적인 방법을 확장한다. ADS는 VM 및 볼륨(ABS)의 위치를 결정하기 위하여 컴퓨트 뿐만 아니라 스토리지 및 다른 컴포넌트를 사용한다. 이것은 자원의 효과적인 사용과 최적의 최종 사용자 성능을 보장한다.

자원 스케줄링은 다음 2개의 주요 영역으로 구분할 수 있다.

  • 초기 배치 (Initial Placement)
    • 아이템이 Power-On 될 때의 위치 결정
  • 런타임 최적화 (Runtime Optimization)
    • 런타임 메트릭스에 기반한 워크로드 이동

하이-레벨 스케줄러 아키텍처는 다음 그림과 같다.

[그림] ADS (Acropolis Dynamic Scheduler)

동적 스케줄러(Dynamic Scheduler)는 위치의 최적화를 위해 하루 24시간 동안 지속적으로 동작한다 (매 15분 마다 동작: Gflag: lazan_anomaly_detection_period_secs). 추정된 값은 축적된 사용률 값(Historical utilization values)과 보정 알고리즘(Smoothing algorithm)을 이용하여 계산된다. 추정된 값은 위치를 결정하는데 사용되며, 갑작스러운 스파이크는 데이터를 왜곡할 수 있기 때문에 제외된다.


자원의 최적화를 위한 새로운 접근 방법

기존의 스케줄링 / 최적화 플랫폼(VMware DRS, Microsoft PRO)은 워크로드를 클러스터 자원들에 균일하게 배포하는데 초점을 두고 있다.

예를 들어, 3개의 노드로 구성된 클러스터에서 각 노드의 자원 사용률이 각각 50%, 5%, 5%라고 가정할 때, 전형적인 솔루션은 워크로드를 각 노드에 약 20% 정도로 균일하게 재조정하는 것이다. 왜 그래야만 하는 것일까?

우리가 실제적으로 목표하는 바는 왜곡(Skew)을 제거하는 것이 아니라, 자원에 대한 경합을 제거 또는 무효화하는 것이다. 자원에 대한 경합이 없는 경우에, 워크로드를 재조정함으로써 얻을 수 있는 이득은 없다. 실제로, VM의 불필요한 이동은 자원을 소비하여야만 하는 부가적인 필수적인 작업(e.g. Memory Transfer, Cache Re-localization 등)을 동반한다.

ADS (Acropolis Dynamic Scheduler)는 자원 사용률의 왜곡이 아닌, 단지 자원에 대한 예상된 경합이 있는 경우에만 워크로드 이동 작업을 수행한다.

NOTE: Acropolis DSF는 데이터의 Hot Spot을 제거하고 재구축 시간을 단축시키기 위해 클러스터에서 데이터를 모든 노드 및 모든 디스크에 균일하게 분산시킨다. DSF의 관련된 기능은 “디스크 밸런싱(Disk Balancing” 섹션을 참조한다.


3.1.6.1 위치 결정 (Placement Decisions)

위치 결정(Placement decisions)은 다음과 같은 아이템에 기반하여 수행된다.

  • 컴퓨트 사용률 (Compute Utilization)
    • 각 노드의 컴퓨트 사용률을 지속적으로 모니터링 한다. 만약 노드의 기대된 CPU 할당이 임계 값(호스트 CPU의 85%, Gflag: lazan_host_cpu_usage_threshold_fraction)을 넘어서는 경우에 해당 호스트에서 VM을 마이그레이션 함으로서 워크로드를 재조정한다. 여기에서 언급해야 할 핵심 사항은 마이그레이션은 경합이 있는 경우에만 수행된다는 것이다. 만약 노드들간에 CPU 사용률이 균일하지 않다고 하더라도(e.g. 4개 노드의 CPU 사용률이 10%, 1개 노드의 CPU 사용률이 50%), 자원에 대한 경합이 없으면, 마이그레이션으로 얻을 수 있는 이득이 없기 때문에 마이그레이션을 수행하지 않는다.
  • 스토리지 성능 (Storage Performance)
    • 하이퍼컨버지드 플랫폼은 컴퓨트와 스토리지 지원을 모두 관리한다. 스케줄러는 각 노드의 Stargate 프로세스 사용률을 모니터링 한다. 만약 어떤 Stargate가 할당된 임계 값(Stargate에 할당된 CPU 사용률 85%, Gflag: lazan_stargate_cpu_usage_threshold_pct)을 넘어서는 경우에, 특정 호스트의 부하를 분산시키기 위해 자원을 마이그레이션 한다. Stargate의 부하를 분산 또는 제거하기 위해 VM 및 ABS 볼륨을 마이그레이션 할 수 있다.
  • [Anti-]Affinity Rules
    • Affinity 또는 Anti-Affinity 제약은 클러스터에서 어떤 자원이 다른 자원에 의존하여 어디에서 스케줄 되어야 하는지를 결정한다. 어떤 경우에, 특정 VM들은 라이선스 이슈로 동일 노드에서 동작되어야 한다. 이러한 경우에 VM들은 동일 호스트에 Affined 된다. 다른 경우는, 가용성 목적으로 VM들이 서로 다른 노드에서 동작하여야 한다. 이러한 경우에 VM들은 Anti-Affined 된다.

스케줄러는 상기의 아이템에 기반하여 워크로드 위치의 최적화를 위해 최선의 선택을 수행한다. 시스템은 너무 많은 마이그레이션이 발생하지 않도록 하기 위해 자원의 이동에 대한 패널티를 부과한다. 이것은 매우 중요한 아이템으로 자원의 이동으로 인해 워크로드에 어떤 부정적인 영향을 주지 않아야 하기 때문이다.

마이그레이션 작업 수행 후에, 시스템은 마이그레이션의 효과성(Effectiveness) 및 실제적인 이득이 무엇인지를 판단한다. 이러한 학습 모델은 마이그레이션 결정을 위한 합리적인 근거를 보장하기 위한 자가 학습 방법이다.


3.1.7 보안 및 암호 (Security and Encryption)

3.1.7.1 보안 (Security)

보안은 뉴타닉스 플랫폼의 핵심 기능이다. 뉴타닉스 SecDL(Security Development Lifecycle)은 개발 프로세스의 모든 단계에서 보안 기능을 적용한다. 뉴타닉스 플랫폼은 공장에서부터 안전하게 출고된다.

뉴타닉스 플랫폼은 다음과 같은 보안 인증 및 조건을 준수한다.

  • 공통 평가 기준 (Common Criteria)
    • 공통 평가 기준은 대부분의 경우에 적용되는 것으로 정부 및 공공 기관을 대상으로 컴퓨터 제품을 판매하는 회사는 일련의 표준을 준수하여야 한다. CC는 캐나다, 프랑스, 독일, 네델란드, 영국 및 미국에 의해 개발되었다.
  • STIGs (Security Technical Implementation Guides)
    • DOD IA 및 IA를 준수하는 디바이스 및 시스템을 위한 설정 표준이다. 1998년 이래로, DISA FSO (Field Security Operations)가 STIGs를 제공함으로써 DoD 보안 시스템의 보안 상태를 향상시키는 중요한 역할을 수행하게 되었다. STIGs는 정보 시스템 또는 소프트웨어를 “lock down”하는 기술적 가이드를 포함하고 있는데, 이것은 악의적인 컴퓨터 공격으로부터의 취약성을 방지한다.
  • FIPS 140-2
    • FIPS 140-2 표준은 보안 모듈을 위한 정보 기술 보안 인증 프로그램으로 일반 기업이 민감하지만 일급 보안 대상이 아닌 정보의 수집, 저장, 공유, 전달하는 공공 기관 및 공익 산업(파이넨스 및 헬스-케어 산업) 등에 사용될 수 있도록 자신들의 제품을 인증 받을 수 있는 프로그램이다.
  • TAA 컴플라이언스
    • 1974년 거래에 관한 법률 및 기타 목적을 위해 협상 무역 협정을 실행하고 인증하기 위한 법률(Act)이다. 연방 정부에 의해 구매되는 제품은 미국산 제품이어야 한다.

SMCA (Security Configuration Management Automation)

뉴타닉스 보안 기술은 클러스터에 있는 모든 CVM/AHV 호스트가 배포 라이프사이클을 통하여 기준에 만족하는 것을 보장하기 위하여 고객이 특정 시점에서의 보안 기준 검사로부터 지속적인 모니터링 및 기준을 보완 및 개선할 수 있는 기능을 제공한다. 뉴타닉스 보안 기술은 문서화된 보안 기준(STIGs)의 모든 컴포넌트를 검사하고, 만약 기준에 부합하지 않은 항목이 있는 경우에는 고객의 개입 없이 지원되는 보안 기준으로 재설정한다.

Ad-doc SCMA 실행

SCMA는 설정된 스케줄(디폴트는 시간 단위)에 기반하여 실행되지만, 필요한 시점에 수행하는 것도 가능하다. SCMA 툴을 수행하기 위해서는 CVM에서 다음 명령어를 수행한다.

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

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

뉴타닉스 nCLI는 매우 엄격한 보안 요구사항을 만족할 수 있도록 다양한 설정 기능을 제공한다.

CVM 보안 설정 (CVM Security Settings)

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(Department of Defense)에서 요구하는 로그인 배너 기능을 활성화 또는 비활성화한다.

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

로그인 배너 변경 (Custom login banner)

디폴트로 DoD에서 요구하는 로그인 배너가 활성화된다. 로그인 배너를 변경하려면 다음과 같은 작업을 수행한다 (임의의 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 only 설정

SNMPv3 only traps을 활성화 또는 비활성화 한다.

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


하이퍼바이저 보안 설정 (Hypervisor Security Settings)

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(Department of Defense)에서 요구하는 로그인 배너 기능을 활성화 또는 비활성화한다.

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) 설정

강력한 패스워드 정책을 활성화 또는 비활성화한다(minlen=15, difok=8, remember=24).

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


클러스터 잠금 (Cluster Lockdown)

클러스터 잠금 기능은 패스워드 기반의 CVM 접근을 제한하고, 키 기반의 접근만을 허용한다.

클러스터 잠금 기능은 프리즘의 설정 메뉴에서 수행할 수 있다.

[그림] 클러스터 잠금 메뉴

클러스터 잠금 메뉴를 선택하면 현재의 설정 정보를 출력하며, CVM 접근을 위한 SSH 키를 추가 또는 삭제할 수 있다.

[그림] 클러스터 잠금 페이지

새로운 키를 추가하기 위해서는 “New Public Key” 버튼을 클릭하고, 공개키를 입력한다.

[그림] 클러스터 잠금 – 키 추가

SSH 키 생성

SSH 키를 생성하기 위해서는 다음 명령어를 실행한다.

ssh-keygen -t rsa -b 2048

상기 명령어를 실행하면 Public Key 및 Private Key가 파일로 생성된다.

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

키를 추가하고 해당 키를 가지고 정상적으로 CVM에 접근할 수 있으면, 패스워드 기반의 로그인을 제한할 수 있다. 그러나, “Enable Remote Login with Password” 옵션을 해제하면 확인 창이 출력되고, 클러스터 잠금 기능을 활성화하기 위해서는 “OK” 버튼을 클릭한다.

3.1.7.2 암호 (Encryption)

뉴타닉스는 SED (Self-encrypting drives) 및 KMS (Key Management server)로 검증된 FIPS-140-2 Level-2를 지원하는 Data-at-Rest Encryption을 제공한다. KMS와의 통신은 KMIP 및 TCG를 포함하는 표준 프로토콜을 사용한다. KMS 서버의 예로는 Vometric, SafeNet 등이 있다.

다음 그림은 데이터 암호화의 개요를 보여준다.

[그림] 데이터 암호 – 개요

SED 암호화는 스토리지 디바이스를 “데이터 밴드(Data Band): 보안 상태 또는 보안되지 않는 상태로 구분”로 분리하여 동작한다. 뉴타닉스의 경우에, 부트 및 뉴타닉스 홈 파티션은 키 사이즈가 작은 키로 암호화 된다. 모든 디바이스 및 밴드는 Level-2 표준에 따라 사이즈가 큰 키로 암호화 된다.

클러스터가 기동될 때, 클러스터는 드라이브의 암호를 해제할 키를 얻기 위해 KMS 서버와 통신한다. 보안을 보장하기 위해 클러스터에서 키는 캐싱 되지 않는다. 콜드 부트 및 IPMI 리셋인 경우에, 노드는 드라이브의 암호를 해제하기 위해 KMS 서버와 통신할 필요가 있다. CVM을 Soft Reboot하는 경우에는 이러한 과정은 발생하지 않는다.


3.1.8 드라이브 분해 (Drive Breakdown)

본 섹션에서는 뉴타닉스 플랫폼에서 SSD, HDD와 같은 스토리지 디바이스를 어떻게 사용하고 있는지를 설명한다.

[NOTE] 본 섹션에서 설명하는 용량 정보는 Base10 Gigabyte(GB)가 아닌 Base2 Gibibyte(GiB)를 기반으로 한다. 파일 시스템을 갖는 드라이브의 포맷 및 관련된 오버헤드를 고려하였다.

SSD 드라이브

SSD 디바이스는 상기에서 설명한 몇 개의 주요 아이템을 저장하는 용도로 사용한다.

  • Nutanix Home (Controller VM Core)
  • Cassandra (메타데이터 스토리지))
  • OpLog (영구적인 Write 버퍼)
  • Unified Cache (SSD Cache 부분)
  • Extent Store(영구 스토리지)

뉴타닉스 노드에 장착되어 있는 SSD 드라이브의 분해 정보는 다음 그림과 같다.

[그림 10-6] SSD 드라이브 분해

[NOTE] 뉴타닉스 소프트웨어 4.0.1 버전부터 OpLog 사이즈는 동적으로 결정되는데, 이것으로 인해 Extent Store 부분이 동적으로 증가한다. 상기에서 사용된 수치는 OpLog를 최대로 사용한다는 것을 가정한 것이다. 상기의 그림과 비율은 실제 크기를 고려한 것은 아니다. Remaining GiB 용량을 계산할 때는 탑다운 방식으로 해야 한다. 예를 들어, OpLog 계산에 필요한 Remaining GiB는 포맷된 SSD 용량에서 뉴타닉스 홈과 카산드라 용량을 차감한 이후에 계산하여야 한다.

OpLog는 모든 SSD 디바이스에 분산된다.

Nutanix Home은 가용성을 보장하기 위해 첫 번째 2개의 SSD에 미러링 된다. AOS 5.0 버전에서부터 Cassandra는 노드에 장착된 SSD를 통하여 공유되며(현재는 최대 4개), SSD 당 15GiB로 초기 예약된다(만약 메타데이터가 증가하면 Stargate SSD를 사용할 수 있다). 2개의 SSD를 갖는 경우에는 메타데이터가 2개의 SSD에서 미러링 된다. SSD 당 메타데이터 예약은 15GiB이다(2개의 SSD를 갖는 경우에는 30GiB, 4개 이상의 SSD는 갖는 경우에는 60GiB).

AOS 5.0 이전 버전에서, Cassandra는 디폴트로 첫 번째 SSD에 존재하였다. 만약 첫 번째 SSD에 장애가 발생하면 CVM은 재시작 되고 Cassandra 스토리지는 2번째 SSD에 존재하였다. 이러한 경우에 SSD 당 메타데이터 예약은 첫 번째 2개의 디바이스를 포함하므로 30GiB이다.

대부분의 뉴타닉스 모델은 1개 또는 2개의 SSD를 포함하고 있으나, 더 많은 SSD 드라이브를 포함하고 있더라도 동일한 알고리즘이 적용된다. 예를 들어, 2개의 400GB SSD 드라이브를 포함하고 있는 NX-3060 또는 NX-6060 모델인 경우에, 노드 당 100GiB의 OpLog, 40GiB의 Unified Cache, 그리고 ~440GiB까지의 Extent Store SSD가 할당된다.

HDD 드라이브

HDD 드라이브는 기본적으로 대용량의 스토리지로 사용되기 때문에, HDD의 분해 정보는 매우 간단하다.

  • 큐레이터 예약 (큐레이터 스토리지)
  • Extent Store (영구 스토리지)

[그림 10-7] HDD 드라이브 분해

예를 들어, 4개의 1TB HDD가 장착되어 있는 NX-3060-G4 모델에 적용할 경우에, 노드 당 큐레이터 예약으로 80GiB, Extent Store로 최대 3.4TiB가 할당된다.

[NOTE] 상기 수치는 뉴타닉스 소프트웨어 4.0.1 버전에서는 정확하지만, 릴리즈에 따라 달라질 수 있다.


3.2 분산 스토리지 패브릭 (Distributed Storage Fabric)

DSF(Distributed Storage Fabric)는 하이퍼바이저에게 일종의 공유 스토리지 어레이로 인식되지만, 모든 I/O는 최고의 성능을 제공하기 위해 로컬에서 처리된다. 다음 섹션에서 뉴타닉스 노드들이 어떤 방식으로 분산 플랫폼을 구성하는 지에 대해 상세히 설명한다.

3.2.1 데이터 구조 (Data Structure)

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

스토리지 풀 (Storage Pool)

  • 주요 역할: 물리적 디바이스의 그룹
  • 설명: 스토리지 풀(Storage Pool)은 물리적 스토리지 디바이스의 그룹으로 클러스터에 장착되어 있는 PCIe SSD, SSD 및 HDD 디바이스를 포함한다. 스토리지 풀은 여러 개의 뉴타닉스 노드에 걸쳐 구성되며, 클러스터가 확장됨에 따라 스토리지 풀도 확장된다. 대부분의 환경에서 단지 1개의 스토리지 풀이 사용된다.

컨테이너 (Container)

  • 주요 역할: VM 및 파일의 그룹
  • 설명: 컨테이너(Container)는 스토리지 풀의 논리적 세그먼트로 VM 또는 파일(vDisk)의 그룹이다. 데이터 중복계수 등과 같은 몇 개의 설정 옵션을 컨테이너 레벨에서 설정할 수 있으나, 이러한 옵션들은 실제적으로는 VM 또는 파일 레벨에서 적용된다. 컨테이너는 일반적으로 데이터스토어와 1:1 관계를 갖는다(NFS/SMB인 경우).

vDisk

  • 주요 역할: vDisk
  • 설명: vDisk는 DSF에서 512KB 이상의 파일로 *.vmdk, VM 하드 디스크 등을 포함한다. vDisk는 복수의 Extent로 구성되고, Extent는 그룹화되어 Extent Group으로 디스크에 저장된다.

최대 DSF vDisk 사이즈 (Maximum DSF vDisk Size)

DSF/스토리지 측면에서 vDisk 사이즈에 대한 제약은 없다. AOS 4.6 버전 기준으로 vDisk 사이즈는 64bit singed 정수로 저장되는데, 사이즈는 바이트 단위로 저장된다. 이것은 vDisk 사이즈의 이론적인 최대 값이 2^63-1 or 9E18 (9 Exabytes)라는 것을 의미한다. vDisk 최대 사이즈 이하로 제한되는 것은 ESXi에서 최대 vmdk 사이즈와 같이 클라이언트에서의 제한에 기인한다.


DSF와 하이퍼바이저간의 매핑은 다음 그림과 같다.

[그림 11-2] 하이-레벨 파일시스템 분해


Extent

  • 주요 역할: 논리적으로 연속된 데이터
  • 설명: Extent는 n개의 연속된 데이터 블록(게스트 OS 블록 사이즈에 의존)으로 구성되어 있는 1MB 사이즈의 논리적으로 연속된 데이터이다. Extent는 Granularity 및 효율성을 위해 일종의 슬라이스(Slice)라고 불리는 sub-Extent 기반으로 Write/Read/Modify 된다. Extent의 슬라이스는 캐시로 이동될 때, Read/Cache 되는 데이터의 양에 따라 트림(Trim) 된다.

Extent Group

  • 주요 역할: 물리적으로 연속되어 저장되는 데이터
  • 설명: Extent Group은 1MB 또는 4MB의 사이즈로 물리적으로 연속되어 저장되는 데이터이다. Extent Group은 CVM이 관리하는 스토리지 디바이스에 파일로 저장된다. Extent는 성능 향상 및 노드/디스크들간의 데이터 스트라이핑(Data Stripping)을 위해 Extent Group으로 동적으로 분산된다.

[NOTE] 뉴타닉스 소프트웨어 4.0 버전에서, Extent Group은 데이터 중복제거 기능의 활성화 여부에 따라 1MB 또는 4MB가 될 수 있다.

Extent, Extent Group과 파일시스템간의 관계는 다음 그림과 같다.

[그림 11-3] 로우-레벨 파일시스템 분해

다음 그림은 상기의 그림을 다르게 표현한 것이다.

[그림 11-4] 그래픽컬 파일시스템 분해


3.2.2 I/O 경로 및 캐시

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

[그림 11-5] DSF I/O 패스

올-플래시 (All-Flash) 노드 설정에서 Extent Store는 모두 SSD 디바이스로 구성되므로, 즉 1개의 플래시 티어만 존재하므로 티어간의 ILM이 발생하지 않는다.

OpLog

  • 주요 역할: 영구 Write 버퍼
  • 설명: OpLog는 파일 시스템 저널(Journal)과 유사하며, 버스트(Burst) 특성을 갖는 랜덤 Write의 처리를 위한 용도로, 데이터는 보다 큰 덩어리로 합쳐진 후에 순차적으로 Extent Store로 이동된다. Write 요청이 발생하면, OpLog는 데이터의 가용성 목적을 위해 Write ACK를 반환하기 전에, 다른 n개 노드의 CVM OpLog에 데이터를 동기적으로 복제한다. 모든 CVM OpLog는 복제 작업에 참여하는데, 로드에 기반하여 동적으로 선택된다. OpLog는 Write I/O 성능의 극대화를 위해, 특히 랜덤 I/O 워크로드, CVM의 SSD 티어에 저장된다. 모든 SSD 디바이스가 참여하며 OpLog 스토리지의 일부분을 처리한다. 순차 워크로드(Sequential Workload)인 경우에는, OpLog를 바이패스(Bypass) 하고, 직접적으로 Extent Store에 저장된다. 만약 데이터가 OpLog에 위치하고 있고 Extent Store로 이동되지 않았다면, 모든 Read 요청은 직접적으로 OpLog에서 수행된다. 데이터가 Extent Store로 이동되면, 데이터는 Extent Store/Unified Cache에서 서비스된다. 데이터 중복제거 기능을 활성화한 컨테이너에서 모든 Write I/O는 해시 알고리즘을 사용하여 지문(Fingerprint)을 생성하고, Unified Cache에서 지문에 기반으로 데이터 중복제거 작업을 수행한다.

vDisk 당 OpLog 사이징

OpLog는 공유 자원(Shared Resources)이지만, 할당(Allocation)은 모든 vDisk가 자원 사용에 대한 동등한 기회를 부여하기 위해 vDisk 기반으로 수행된다. 이것은 vDisk 당 OpLog Limit(OpLog에서 vDisk가 가질 수 있는 최대 용량)를 활용하여 구현되었다. 복수의 vDisk를 갖는 VM은 vDisk 당 Limit를 여러 개 갖는 것이 된다.

vDisk 당 Limit는 AOS 4.6 버전에서 6GB이다 (이전 버전에서는 2GB).

vDisk Limit는 Gflag의 vdisk_distributed_oplog_max_dirty_MB에서 설정을 변경할 수 있다.

Extent Store

  • 주요 역할: 영구 데이터 스토리지
  • 설명: Extent Store는 DSF의 대용량 영구 스토리지(Persistent Bulk Storage)로 SSD와 HDD에 걸쳐 존재하며, 추가적인 디바이스/티어를 쉽게 확장할 수 있다. Extent Store에 저장되는 데이터는 A) OpLog에서 이동된 경우이거나, B) 순차 데이터로 OpLog를 바이패스(Bypass) 하는 경우이다. 뉴타닉스 ILM 모듈이 I/O 패턴에 기반하여 동적으로 데이터의 위치를 결정하고, 티어간에 데이터를 이동시킨다.

순차 Write의 특징 (Sequential Write Characterization)

AOS 4.6 버전 기준으로, vDisk에 대한 Write IO의 크기가 1.5MB 보다 큰 경우에 해당 Write IO는 순차 Write (Sequential Write)로 인식된다. 순차 Write IO는 이미 데이터 사이즈가 크기 때문에 OpLog에 Write 되지 않고, 직접 Extent Store에 Write 된다.

이러한 동작은 Gflag의 vdisk_distributed_oplog_skip_min_outstanding_write_bytes에 설정된 값을 기준으로 수행된다.

모든 다른 IO는, 데이터 사이즈가 64K를 넘는 경우라도, OpLog에 의해 처리된다.

Unified Cache

  • 주요 역할: 동적 Read 캐시
  • 설명: Unified Cache는 중복 제거된(Deduplicated) Read 캐시로 CVM 메모리와 SSD에 걸쳐 존재한다. 캐시에 존재하지 않는 데이터의 Read 요청 시에(또는 특정 지문에 기반하여), 데이터는 Unified Cache의 Single-Touch Pool로 적재된다. Single-Touch Pool은 메모리로만 구성되어 있으며, 데이터가 캐시에서 삭제될 때까지 LRU를 사용한다. 연속적인 Read 요청이 발생한 경우에, 데이터는 메모리와 SSD로 구성된 Multi-Touch Pool의 메모리 영역으로 이동된다(실제적으로 데이터가 이동되는 것은 아니고, 캐시 메타데이터만 변경된다). Multi-Touch Pool에는 2 종류의 LRU 사이클이 존재하는데, 하나는 인메모리(In-memory) 부분을 위한 것으로, 데이터를 Multi-Touch Pool의 SSD 부분으로 이동시키며, 이때 새로운 LRU 카운터가 할당된다. Multi-Touch Pool에 위치하고 있는 데이터에 대해 Read 요청이 발생하면, 데이터는 Multi-Touch Pool의 맨 꼭대기로 이동하고 새로운 LUR 카운터가 할당된다.

Unified Cache의 동작 알고리즘은 다음 그림과 같다.

[그림 11-6] DSF Unified Cache


캐시 Granularity 및 로직

데이터는 4K 단위로 캐시에 적재되며, 모든 캐싱은 실시간으로 수행된다. 즉, 데이터를 캐시로 옮기기 위한 배치 프로세스가 없으므로 지연이 전혀 없다.

모든 CVM은 자신의 로컬 캐시를 가지며 CVM이 호스팅하고 있는 vDisk(로컬 노드에서 구동중인 VM의 vDisk)를 관리한다. vDisk가 클론 될 때 (e.g., 새로운 클론, 스냅샷 등) 모든 새로운 vDisk는 자신의 블록 맵을 가지고, 원본 vDisk는 “변경불가”로 표시된다. 이러한 방식을 통해 모든 CVM은 캐시 일관성을 갖는 베이스 vDisk의 캐시된 복사본을 갖는다.

Overwirte가 발생하는 경우에, 해당 Overwrite는 VM의 블록 맵에서 새로운 Extent로 리다이렉트 된다. 이러한 과정을 통해 어떠한 경우에라도 캐시 일관성이 깨지는 것을 방지한다.


Extent Cache

  • 주요 역할: 인메모리 Read 캐시
  • 설명: Extent Cache는 인메모리 Read 캐시로 CVM 메모리에만 존재한다. 이것은 데이터 중복제거 기능을 사용하지 않는 컨테이너에서 지문을 갖지 않는 데이터를 저장하는데 사용한다. 뉴타닉스 소프트웨어 3.5 버전에서 Unified Cache로부터 분리되었으나, 뉴타닉스 소프트웨어 4.5 버전에서 Unified Cache로 통합되었다.

3.2.3 메타데이터 확장성 (Scalable Metadata)

메타데이터는 모든 인텔리전트 시스템의 핵심으로, 모든 파일시스템 또는 스토리지 어레이에서 가장 핵심적인 기능이다. DSF 관점에서, DSF 성공에 결정적인 영향을 끼친 몇 가지 주요 특징은 다음과 같다.

  • 실시간으로 100% 정확해야 한다(“Strict Consistency”로 알려짐),
  • ACID 컴플라이언트 해야 한다.
  • 무제한으로 확장할 수 있어야 한다.
  • 어느 규모에서든지 병목현상이 없어야 한다 (선형적인 확장성을 제공해야 한다).

상기의 아키텍처 섹션에서 설명한 바와 같이, DSF는 Key-Value로 구성된 데이터를 저장하기 위해 “Ring-Like” 구조를 사용하는데, 메타데이터 및 플랫폼 데이터(e.g. 통계 데이터 등)를 저장한다. 메타데이터 가용성 및 리던던시를 보장하기 위해 홀수 노드(e.g. 3, 5 등)로 구성된 RF(Replication Factor)를 사용한다. 메타데이터 Write 또는 Update 시에, Row가 Ring에서 특정 노드에 Write 되고, 다시 n개의 피어(Peer)에 복제된다(n은 클러스터 사이즈에 의존). 어떤 종류의 변경이 최종 완료되기 전에 대부분의 노드가 동의해야만 하는데, 이것을 위해 PAXOS 알고리즘을 사용한다. 이것은 플랫폼의 일부로서 저장되는 모든 데이터 및 메타데이터의 “Strict Consistency”를 보장한다.

4개의 노드로 구성된 클러스터에서 메타데이터의 입력/변경은 다음 그림과 같이 처리된다.

[그림 11-7] 카산드라 Ring 구조

확장 시의 성능 또한 DSF 메타데이터의 중요한 특징이다. 전통적인 듀얼 컨트롤러 또는 “마스터” 모델과 달리, 모든 뉴타닉스 노드는 전체 플랫폼 메타데이터의 일정 부분에 대한 책임을 갖는다. 메타데이터가 클러스터의 모든 노드에 의해 서비스 및 관리되기 때문에 전통적인 병목현상을 제거한다. 클러스터 사이즈가 변경되는 동안(노드 추가/제거)에 키(Key)의 재분배를 최소화하기 위해 Consistent Hash Scheme을 사용한다. 클러스터가 확장될 때(e.g. 4개의 노드에서 8개의 노드로 확장될 때), 노드는 “Block Fault Tolerance” 및 안정성을 고려하여 Ring 구조에 추가된다.

다음 그림은 메타데이터 “Ring” 및 “Ring”이 어떤 방식으로 확장되는지를 보여준다.

[그림 11-8] 카산드라 스케일-아웃


3.2.4 데이터 보호 (Data Protection)

뉴타닉스 플랫폼은 노드/디스크 장애, 데이터 손상과 같은 장애가 발생하더라도 데이터 리던던시 및 가용성을 보장하기 위하여 데이터 복제계수(Replication Factor: RF)로 알려진 리질리언시 팩터(Resiliency Factor)와 체크섬(Checksum)을 사용한다. 상기에서 설명한 바와 같이, OpLog가 스테이징 영역으로 사용되어, 입력 데이터의 Write 오퍼레이션을 레이턴시가 적은 SSD 티어에서 수행한다. 로컬 OpLog에 데이터를 Write 할 때, 데이터는 호스트에 Write 작업이 성공적으로 수행되었다는 ACK를 반환하기 전에, 다른 1개 또는 2개의 뉴타닉스 CVM의 OpLog(RF에 의존)에 동기적으로 복제된다. 이것은 데이터가 최소한 2개 또는 3개의 독립적인 위치에 존재한다는 것을 보장하기 때문에, 기본적으로 Fault Tolerant를 지원한다는 것을 의미한다.

[NOTE] RF3인 경우에, 메타데이터가 RF5이어야 하기 때문에 최소한 5개의 노드가 필요하다.

OpLog 피어는 에피소드(1GB의 vDisk 데이터) 당 선택되며, 모든 노드가 적극적으로 참여한다. 피어를 선택하기 위해서는 다양한 변수(응답 시간, 업무량, 용량 사용률 등)가 고려된다. 이런 과정을 통하여 데이터의 단편화를 방지하고, 모든 CVM/OpLog의 부하를 균일하게 유지하도록 보장한다.

데이터 RF는 프리즘에서 설정할 수 있으며, 컨테이너 레벨에서 수행된다. “Hot 노드”를 제거하기 위하여 모든 노드가 OpLog 복제 작업에 참여하므로, 확장 시에도 선형적 성능을 보장한다. 데이터가 Write 되는 동안에, 체크섬이 계산되고, 체크섬은 메타데이터의 일부로 저장된다. 그리고 나서, 데이터는 RF가 유지된 상태로 비동기적으로 Extent Store로 이동된다. 노드 또는 디스크 장애 시에, 데이터는 RF를 유지하기 위해 클러스터의 모든 노드들로 재복제(Re-replicated) 된다. 데이터 Read 시점에, 데이터의 유효성을 검증하기 위하여 체크섬(Checksum)을 계산한다. 체크섬과 데이터가 일치하지 않는 경우에는, 데이터 복제본을 Read 하고 유효하지 않는 데이터를 대체한다.

실제적인 I/O 발생하지 않는 동안에도, 데이터 무결성/완전성을 보장하기 위하여 데이터는 항상 모니터링 된다. 스타게이트의 스크라버 오퍼레이션(Scrubber Operation)은 Extent Group을 지속적으로 스캔하고, 디스크가 많이 사용되지 않은 동안에 체크섬 기반의 정합성 작업을 수행한다. 이러한 과정을 통해 Bit Rot 또는 Corrupted Sector 등과 같은 이슈가 발생한 경우에도 데이터를 보호한다.

상기에서 설명한 로직을 그림으로 표현하면 다음과 같다.

[그림 11-9] DSF 데이터 보호


3.2.5 가용성 도메인(Availability Domain)

가용성 도메인(Node/Block/Rack Fault Tolerance로 알려진)은 분산 시스템의 핵심 기능으로 컴포넌트 및 데이터의 위치를 결정하기 위해 사용된다. DSF는 현재 노드 및 블록 폴트 톨러런스 기능을 지원하고 있으며, 클러스터 사이즈가 증가함에 따라 랙 폴트 톨러런스(Rack Fault Tolerance) 기능까지 확장시킬 예정이다. 뉴타닉스 플랫폼에서 “블록”은 1개, 2개, 또는 4개의 서버 노드를 장착할 수 있는 섀시(Chassis)이다.

[NOTE] 블록 폴트 톨러런스(Block Fault Tolerance) 기능이 동작하기 위해서는 최소한 3개 이상의 블록이 사용되어야 한다. 그렇지 않은 경우에는 디폴트로 노드 폴트 톨러런스 기능이 동작한다.

블록 폴트 톨러런스 기능의 활성화를 보장하기 위해서는 동일 유형의 블록을 사용할 것을 권고한다. 일반적인 시나리오 및 노드/블록 폴트 톨러런스 레벨은 본 세션의 마지막 부분에서 설명한다. 최소 3개 블록에 대한 요구사항은 정족수(Quorum)를 보장하기 위한 것이다. 예를 들어, NX-3460-G4는 4개의 노드를 갖는 블록이다. 블록 레벨로 역할 또는 데이터를 분산하는 이유는, 블록 장애 또는 유지보수 동안에도 시스템의 중단 없는 서비스를 보장하기 위한 것이다.

[NOTE] 블록에서 PSU(Power Supply Unit)와 팬(Fan)이 유일한 공유 컴포넌트이다. 가용성 도메인 기능을 제공하기 위해서는 다음과 같은 유형의 데이터에 대한 가용성이 보장되어야 한다.

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

데이터 (VM 데이터)

DSF에서, 데이터 복제본을 클러스터의 다른 블록에 Write 함으로써 블록 장애 또는 계획된 다운타임의 경우에도 데이터 가용성을 보장한다. 이것은 RF2 및 RF3 모두에 적용될 뿐만 아니라 블록 장애 시에도 적용된다. 가장 단순한 비교는 “노드 폴트 톨러런스(Node Fault Tolerance)”인데, 이것은 데이터를 다른 노드에 복제함으로써, 노드의 장애 시에도 데이터를 보호한다. 블록 폴트 톨러런스(Block Fault Tolerance)는 노드 폴트 톨러런스 기능을 확장하여 블록 장애 시에 데이터 가용성을 보장한다.

다음 그림은 3개의 블록으로 배포된 환경에서 복제본 데이터의 위치가 어떤 방식으로 동작하는지를 보여준다.

[그림 11-25] 블록 폴트 톨러런스에서 복제본 데이터의 위치

블록 장애 시에도, 블록 폴트 톨러런스 기능이 유지되고, 재 복제된 블록(Re-replicated blocks)은 클러스터의 다른 블록에 복제된다.

[그림 11-26] 블록 장애 시 복제본 데이터의 위치

블록 폴트 톨러런스 조건

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

동시 장애 허용
블록 수 유형 클러스터 FT1 클러스터 FT2
<3 노드 단일 노드 듀얼 노드
3-5 노드 + 블록 단일 블록 (최대 4개 노드) 단일 블록 (최대 4개 노드)
5+ 노드 + 블록 단일 블록 (최대 4개 노드) 단일 블록 (최대 8개 노드)

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” 구조를 사용하고, 데이터 일관성 및 가용성을 보장하기 위하여 Ring에서 n개의 피어(Peer)에 메타데이터를 복제한다.

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

[그림 11-27] 12개의 노드로 구성된 카산드라 Ring

카산드라 피어(Peer) 복제는 Ring에서 시계 방향으로 n개의 노드에 반복된다. 블록 폴트 톨러런스 기능이 활성화되면, 피어(Peer)를 블록에 분산시킴으로써, 2개의 피어가 동일 블록에 위치하지 않도록 보장한다.

상기의 Ring 구조를 블록 기반의 배치로 변환한 후의 노드 배치는 다음과 같다.

[그림 11-28] 카산드라 노드/블록 폴트 톨러런스 위치

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

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

[그림 11-29] 전체 카산드라 노드/블록 폴트 톨러런스 위치

메타데이터 인식 조건 (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:
    • > 3 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.

클러스터 설정 데이터(Configuration Data)

뉴타닉스는 클러스터 설정 정보를 관리하기 위하여 주키퍼(Zookeeper)를 사용한다. 주키퍼 역할은 블록 장애 시에 클러스터 설정 정보의 가용성을 보장하기 위하여 블록 폴트 톨러런스 방법에 기반하여 분산된다.

3개의 주키퍼 노드가 블록 폴트 톨러런스 방식에 따라 분산된 그림은 다음과 같다.

[그림 11-30] 블록 폴트 톨러런스 방식에 따른 주키퍼 노드의 분산

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

[그림 11-31] 블록 장애 시에 주키퍼 배치

블록이 정상 상태로 복귀되면, 블록 폴트 톨러런스 기능을 유지하기 위하여 주키퍼 역할이 원래 노드로 복원된다.

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


3.2.6 데이터 패스 리질리언시 (Data Path Resiliency)

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

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

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

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

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

[그림] 데이터 패스 리질리언시 – 정상 상태


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


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

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

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

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

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

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

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

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


3.2.6.1 잠재적인 장애 레벨 (Potential levels of failure)

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

  • 디스크 장애
  • CVM 장애
  • 노드 장애

3.2.6.2 디스크 장애 (Disk Failure)

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

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

  • HA 이벤트: 없음
  • I/O 실패: 없음
  • 레이턴시: 영향 없음

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

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

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

다음 그림은 디스크 장애 및 재보호(Re-Protection)의 예이다.

[그림] 데이터 패스 리질리언시 – 디스크 장애

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

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

3.2.6.3 노드 장애 (Node Failure)

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

  • HA 이벤트: 발생
  • I/O 실패: 없음
  • 레이턴시: 영향 없음

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

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


[그림] 데이터 패스 리질리언시 – 노드 장애

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

PRO TIP

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

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

# Node status
ncli cluster get-domain-fault-tolerance-status type=node

# Block status
ncli cluster get-domain-fault-tolerance-status type=rackable_unit


3.2.6.4 CVM 장애 (CVM Failure)

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

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

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

  • HA 이벤트: 없음
  • I/O 실패: 없음
  • 레이턴시: 네트워크를 통한 I/O가 증가하기 때문에 잠재적으로 높을 수 있음

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

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

AHV인 경우에는 iSCSI 멀티-패스 기능을 사용하는데, 프라이머리 경로는 로컬 CVM이고, 다른 2개의 패스는 리모트로 설정되어 있다. 프라이머리 패스에 장애가 발생하면, 2개의 패스 중에 1개가 Active로 된다.

ESXi, Hyper-V 환경에서의 Autopathing과 유사하게, 로컬 CVM이 온라인 상태로 변경되면, 프라이머리 패스가 모든 I/O 서비스를 처리한다.


3.2.7 용량 최적화 (Capacity Optimization)

뉴타닉스 플랫폼은 모든 워크로드를 대상으로 가용 용량을 효율적으로 사용하기 위해 광범위한 종류의 스토리지 최적화 기술을 제공한다. 이러한 기술들은 워크로드의 특징에 따라 자동적으로 적용되므로, 수작업 설정 및 세부 튜닝이 필요하지 않다.

뉴타닉스는 다음과 같은 최적화 기술을 사용한다.

  • Erasure Coding
  • 데이터 압축 (Compression)
  • 데이터 중복제거 (Deduplication)

다음 섹션에서 각 기술에 대해 상세히 설명한다.

워크로드의 특징에 따른 용량 최적화 기술의 적용 예는 다음 테이블과 같다.

데이터 변환 애플리케이션 비고
Erasure Coding Most 전통적인 RF와 비교할 때, 적은 오버헤드로 고가용성을 제공한다. 일반적인 Write 또는 Read I/O에 영향을 주지 않는다. 디스크/노드/블록 장애 시에 데이터를 디코드(Decode) 하여야 하기 때문에 Read 시에 약간의 오버헤드가 발생할 수 있다.
인라인 압축 (Inline Compression) All 랜덤 I/O에 영향을 주지 않으며, 스토리지 티어 사용률을 증가시킨다. 데이터 복제 및 디스크로부터의 Read를 줄여주기 때문에 대규모 또는 순차 I/O 성능을 향상시킨다.
오프라인 압축 (Offline Compression) None 인라인 압축이 단지 대규모 또는 순차 Write에만 적용되므로, 랜덤 또는 작은 I/O 압축을 위해 후처리 압축을 적용해야 한다.
성능 티어 중복제거 (Performance Tier Deduplication) P2V/V2V, Hyper-V(ODX), Cross-Container 클론 효율적인 아크로폴리스 클론을 사용하여 생성되거나 또는 클론 되지 않은 데이터인 경우에 캐시 효율성을 증가시킨다.
용량 티어 중복제거 (Capacity Tier Deduplication) 성능 티어 중복제거와 동일 효율적인 아크로폴리스 클론을 사용하여 생성되거나 또는 클론 되지 않은 데이터인 경우에 적은 오버헤드로 디스크 효율성을 증가시킨다.

3.2.7.1 Erasure Coding

뉴타닉스 플랫폼은 데이터 보호 및 가용성을 위해 RF(Replication Factor)를 사용한다. 이러한 메소드는 Read가 1개 이상의 스토리지 로케이션에서 일어나지 않고, 장애 시에 데이터 재계산 작업이 필요하지 않기 때문에, 최고 수준의 가용성을 제공한다. 그러나, 이것은 데이터 전체의 중복을 요구하기 때문에, 스토리지 자원의 비용이 증가하는 단점이 있다.

가용성을 유지하면서 필요한 스토리지의 용량을 줄이기 위하여, DSF는 Erasure Coding(EC)을 사용하여 데이터를 인코드(Encode) 할 수 있는 기능을 제공한다.

패리티를 계산하는 RAID(레벨 4, 5, 6 등) 컨셉과 유사하게, EC는 다른 노드에 있는 일련의 데이터 블록을 인코드(Encode)하고 패리티를 계산한다. 호스트 또는 노드의 장애 시에, 패리티를 이용하여 손실된 데이터 블록을 계산한다. DSF에서, 데이터 블록은 Extent Group이고, 각 데이터 블록은 다른 노드에 위치하여야 하고, 또한 다른 vDisk에 소속되어 있어야 한다.

스트립(Strip)에서 데이터 및 패리티 블록의 수는 허용 가능한 장애의 수준에 기반하여 설정 가능하다. 설정은 일반적으로 <데이터 블록의 수> / <패리티 블록의 수>로 지정한다.

예를 들어, “RF2 like” 가용성(e.g. N+1)은 스트립(e.g. 3/1 or 4/1)에서 3개 또는 4개의 데이터 블록과 1개의 패리티 블록으로 구성할 수 있다. “RF3 like” 가용성(e.g. N+2)은 스트립(e.g. 3/2 or 4/2)에서 3개 또는 4개의 데이터 블록과 2개의 패리티 블록으로 구성할 수 있다.


PRO TIP

nCLI “ctr [create / edit] … erasure-code=<N>/<K>” 명령어를 이용하여 디폴트 스트립 사이즈 (“RF2 like”인 경우에 4/1, “RF3 like”인 경우에 4/2)를 변경할 수 있다. nCLI 명령어에서 N은 데이터 블록의 수이고, K는 패리티 블록의 수이다.


기대 오버헤드(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배 N/A N/A
7+ 4/1 1.25배 4/2 1.5배

PRO TIP

노드 장애 시에, 스트립의 재구축을 허용하기 위해, 스트립 사이즈 (데이터 + 패리티) 보다 최소한 1개 이상 많은 노드로 클러스터를 구성해야 한다. 이것은 스트립이 재구축(큐레이터에 의해 백그라운드로 수행)되는 동안에 Read 시의 계산 오버헤드를 제거한다. 예들 들어, 스트립 사이즈가 4/1인 경우에 클러스터는 최소한 6개의 노드로 구성되어야 한다. 상기의 테이블은 이와 같은 Best Practices에 기반하여 작성된 것이다.


인코딩은 후처리 작업으로 수행되며, 태스크의 분산을 위해 큐레이터 맵리듀스 프레임워크를 이용한다. EC는 후처리 프레임워크이므로, 전통적인 Write I/O 패스에는 영향을 주지 않는다.

RF를 사용하는 일반적인 환경은 다음과 같다.

[그림 11-10] 전형적인 DSF RF 데이터 배치

본 시나리오에서는 RF2와 RF3 데이터가 혼합되어 있으며, 원본은 로컬에 복제본은 클러스터의 다른 노드에 분산되어 있다.

큐레이터 전체 스캔이 동작할 때, 큐레이터는 인코드 대상이 되는 Extent Group을 찾는다. 인코드 대상이 되는 Extent Group은 “Write-Cold”이여야 하는데, 이것은 Write 된지 1시간 이상 지난 데이터를 의미한다. 인코드 대상이 되는 데이터를 찾은 후에, 인코딩 작업은 분산되고, 크로노스에 의해 통제된다.

스트립 사이즈가 4/1 및 3/2인 경우에 EC 적용은 다음과 같다.

[그림 11-11] DSF 인코딩 스트립 – 용량 증가 전

데이터 인코딩 작업이 성공적으로 완료되면, 즉, 스트립 및 패리티 계산이 완료되면, 복제본 Extent Group은 삭제된다.

EC가 수행된 후에 스토리지 용량이 증가한 환경은 다음과 같다.

[그림 11-12] DSF 인코딩 스트립 – 용량 증가 후


PRO TIP

스토리지 용량 절감을 위한 최적의 조합은 Erasure Coding과 인라인 압축을 적용하는 것이다.


3.2.7.2 압축 (Compression)

뉴타닉스 용량 최적화 엔진(Capacity Optimization Engine)은 디스크에서 데이터의 효율성을 향상시키기 위한 데이터 변환 작업에 대한 책임을 갖는다. 압축(Compression)은 데이터 최적화를 위한 COE의 주요 기능 중의 하나이다. DSF는 고객의 니즈 및 데이터 유형에 가장 적합한 방법론을 제공해 주기 위해 인라인 압축(Inline compression)과 오프라인 압축(Offline compression) 기능을 제공한다.

인라인 압축(Inline Compression)은 순차 스트림 데이터 또는 I/O 사이즈가 큰 데이터(>64K)를 Extent Store(SSD + HDD)에 Write 할 때 압축을 한다. 인라인 압축은 랜덤 데이터를 OpLog에서 Extent Store로 이동할 때 적용된다.


OpLog 압축 (OpLog Compression)

AOS 5.0 버전에서, 4K 이상의 입력 데이터에 대해 압축 작업이 수행되는데, 압축 효율이 매추 좋다 (Gflag: vdisk_distributed_oplog_enable_compression). 이렇게 함으로써 OpLog 용량을 보다 효율적으로 사용할 수 있으므로 성능이 향상된다는 장점이 있다.

AOS 5.0 버전에서, 4K 이상의 입력 데이터에 대해 압축 작업이 수행되는데, 압축 효율이 매추 좋다 (Gflag: vdisk_distributed_oplog_enable_compression). 이렇게 함으로써 OpLog 용량을 보다 효율적으로 사용할 수 있으므로 성능이 향상된다는 장점이 있다.

OpLog에서 Extent Store로 데이터를 이동할 때, 데이터는 먼저 압축을 해제하고, 64K 단위로 데이터를 모은 후에 재압축 된다.

본 기능은 디폴트로 활성화되어 있으며, 관리자의 추가적인 설정은 필요하지 않다.


오프라인 압축(Offline Compression)은 처음에 데이터를 평문(압축하지 않은 상태)으로 Write 하고, 이후에 클러스터 레벨에서 데이터를 압축하기 위해 큐레이터 프레임워크를 이용한다. 인라인 압축을 활성화하였으나, I/O가 랜덤 데이터인 경우에, 데이터는 압축되지 않은 상태로 OpLog에 Write 되고, 이후에 Exntent Store로 Write 하는 시점에 메모리 상에서 압축 작업을 수행한다.

AOS 5.0 버전에서부터 뉴타닉스는 데이터 압축을 위해 LZ4 및 LZ4HC 알고리즘을 사용한다. AOS 5.0 이전의 버전에서는 데이터 압축을 위해 Google Snappy 압축 라이브러리를 이용하였는데, 이것은 계산 오버헤드를 최소화하면서도 좋은 압축률을 제공하고 압축 및 해제 작업을 매우 빠른 시간에 수행한다는 장점을 갖는다.

일반 데이터의 압축을 위해 압축 및 성능이 매우 뛰어난 LZ4 알고리즘을 사용한다. 콜드 데이터의 압축을 위해서는 압축률이 개선된 LZ4HC 알고리즘을 사용한다.

콜드 데이터는 다음과 같은 2가지 카테고리로 특징지을 수 있다.

  • Regular 데이터: 3일 동안 RW가 없는 데이터 (Gflag: curator_medium_compress_mutable_data_delay_secs)
  • Immutable 데이터 (스냅샷): 1일 동안 RW가 없는 데이터 (Gflag: curator_medium_compress_immutable_data_delay_secs)

인라인 압축과 DSF Write I/O 패스와의 관계는 다음 그림과 같다.

[그림 11-13] 인라인 압축 I/O 패스


PRO TIP

인라인 압출은 순차 또는 용량이 큰 데이터 Write에 압축을 적용하고 랜덤 Write에는 적용되지 않기 때문에 거의 대부분의 경우에 인라인 압축(compression delay=0)을 적용한다.

인라인 압축은 SSD 티어의 가용 용량을 증가시키기 때문에 성능을 증가시키고 보다 많은 데이터를 SSD 티어에 저장할 수 있다. 또한, 순차 또는 용량이 큰 데이터는 인라인으로 압축되어 저장되기 때문에 RF를 위한 복제 데이터도 압축되어 저장된다. 압축된 데이터는 네트워크 트래픽을 감소시키기 때문에 성능이 증가한다는 장점도 있다.

스토리지 용량 절감을 위한 가장 좋은 방법은 인라인 압축과 Erasure Coding을 동시에 적용하는 것이다.


오프라인 압축(Offline Compression)인 경우에, 모든 새로운 Write I/O는 압축되지 않은 상태로 일반적인 DSF I/O 경로를 따른다. 압축 Delay(설정 가능한 정보)가 충족된 이후, 해당 데이터는 압축 대상 데이터가 된다. 압축은 Extent Store의 모든 영역에서 수행된다. 오프라인 압축은 큐레이터 맵리듀스 프레임워크를 이용하기 때문에 모든 노드가 압축 태스크를 수행한다. 압축 태스크는 크로노스에 의해 제어된다.

오프라인 압축과 DSF Write I/O 패스와의 관계는 다음 그림과 같다.

[그림 11-14] 후처리 압축 Write I/O 패스

Read I/O인 경우에, 데이터는 먼저 메모리에서 압축을 해제한 후에, I/O 서비스가 제공된다. 자주 참조되는 데이터인 경우에, 데이터는 HDD 티어에서 압축이 해제되고, ILM 모듈이 해당 데이터를 캐시 또는 SSD로 이동시킨다.

프리즘의 “Storage -> Dashboard” 페이지에서 현재 압축률을 확인할 수 있다.


3.2.7.3 데이터 중복제거 엔진 (Data Deduplication Engine)

데이터 중복제거 엔진(Data Deduplication Engine)은 DSF의 소프트웨어 기반 기능으로 성능 티어(Unified Cache) 및 용량 티어(Extent Store)에서 데이터의 중복제거 기능을 수행한다. 데이터의 입수 시점에 16K 단위로 SHA-1 해시 알고리즘을 이용하여 지문(Fingerprint)을 생성한다. 지문은 데이터의 입수 시점에만 생성되고, 저장된 블록의 메타데이터의 일부로 영구히 저장된다.

[NOTE] 초기에는 4K 단위로 지문을 생성하였으나, 16K 단위로 지문을 생성하면 메타데이터 관리의 오버헤드가 줄어들게 되어 데이터 중복제거의 성능이 향상된다. 중복제거된 데이터는 Unified Cache에 4K 단위로 캐싱된다.

데이터의 Re-read를 요구하는 백그라운드 스캔을 사용하는 전통적인 접근방법과 달리, 뉴타닉스는 데이터의 입수 시점에 지문을 생성하는 인라인 지문 생성 기능을 수행한다. 용량 티어에서 중복제거 되어야 할 중복 데이터인 경우에, 데이터를 스캔 또는 Re-read 할 필요 없이, 중복된 데이터를 삭제할 수 있다.

메타데이터 오버헤드를 좀 더 효율적으로 관리하기 위해, 데이터 중복제거 상황을 추적할 수 있는 지문 참조 카운트(Fingerprint Refcount)를 모니터링 한다. 낮은 지문 참조 카운트 값을 갖는 지문은 메타데이터 오버헤드를 최소화하기 위해 폐기된다. 단편화(Fragmentation)의 최소화를 위해 용량 티어 데이터 중복제거는 Full Extent가 사용된다.


PRO TIP

Unified Cache의 장점을 충분히 활용하기 위해 베이스 이미지에 성능 티어 데이터 중복제거 기능을 사용한다(vdisk_manipulator 명령어를 이용하여 수작업으로 설정).

P2V / V2V, ODX를 사용하는 Hyper-V 환경(ODX는 전체 데이터의 복제 작업 수행), 또는 컨테이너 간의 클론 작업을 수행하는 경우(뉴타닉스는 단일 컨테이너 사용을 권고하기 때문에 일반적으로 권고되지 않는 환경)에 용량 티어 데이터 중복제거 기능을 사용한다.

상기와 같은 환경 이외에서는, 압축이 더 많은 용량 절감 효과가 있기 때문에, 데이터 중복제거 기능 대신에 데이터 압축 기능을 사용한다.


데이터 중복제거 엔진의 확장성 및 로컬 VM의 I/O 요청에 대한 처리는 다음 그림과 같다.

[그림 11-16] 데이터 중복제거 엔진 – 확장

지문은 I/O 사이즈가 64K 이상인 데이터에 대해 데이터의 입수 시점에 생성된다. 지문 생성을 위해 SHA-1 알고리즘을 사용하는데, CPU 오버헤드를 최소화할 수 있도록 Intel의 가속 기능을 사용한다. 데이터의 입수 시점에 지문이 생성되지 않는 데이터(예를 들어, 사이즈가 64K 이하인 데이터)인 경우에, 지문 생성은 백그라운드 프로세스에 의해 수행된다. 데이터 중복제거 엔진은 용량 티어(Extent Store)와 성능 티어(Unified Cache)에서 수행된다. 복수의 데이터가 동일 지문을 갖는, 즉 중복 데이터가 검출되면, DSF 맵리듀스 프레임워크인 큐레이터가 백그라운드 프로세스를 통하여 중복된 데이터를 삭제한다. Read 되어야 할 데이터는 멀티-티어/풀 캐시인 DSF Unified Cache로 캐시된다. 동일 지문을 갖는 데이터에 대한 연속된 Read 요청은 캐시에서 바로 서비스 된다. Unified Cache 및 POOL 구조에 대해서는 I/O 패스 개요의 서브 섹션인 “Unified Cache”를 참조한다.


Fingerprinted vDisk Offsets

AOS 4.6.1 버전부터 vDisk의 Limit가 없어졌기 때문에 전체 vDisk를 대상으로 데이터 중복제거가 적용된다.

AOS 4.6.1 이전 버전에서 메타데이터 관리 효율성이 증가하여 Limit가 24GB로 증가되었다. AOS 4.5 이전 버전에서는 vDisk의 첫 번째 12GB만이 데이터 중복제거의 대상이 되었다.


데이터 중복제거 엔진과 DSF I/O 패스간의 관계는 다음 그림과 같다.

[그림 11-17] EDE I/O 패스

프리즘의 “Storage ->Dashboard” 메뉴에서 데이터 중복제거 현황을 확인할 수 있다.


데이터 중복제거 + 데이터 압축

AOS 4.5 버전부터 동일 컨테이너에서 데이터 중복제거 기능과 데이터 압축 기능을 동시에 적용할 수 있다. 그러나, 데이터가 중복제거 대상이 아닌 경우에도 압축은 적용된다.


3.2.8 스토리지 티어링 및 우선순위(Storage Tiering and Prioritization)

디스크 밸런싱(Disk Balancing) 섹션에서 뉴타닉스 클러스터에서 모든 노드들간의 스토리지 용량이 어떤 방식으로 풀(Pooled) 되는지, 그리고 ILM이 핫 데이터(Hot Data)를 어떤 방식으로 로컬에 유지하는지를 설명한다. 디스크 티어링(Disk Tiering)을 위해 유사한 개념을 적용하는데, 클러스터 SSD 티어 및 클러스터 HDD 티어는 클러스터 레벨로 동작하고, DSF ILM이 데이터 이동 이벤트의 트리거에 대한 책임을 갖는다. 로컬 노드의 SSD 티어는 노드에서 동작하는 VM에 의해 요청된 모든 I/O에 대한 최고의 우선순위를 갖지만, 클러스터 SSD의 모든 자원은 클러스터의 모든 노드에서 사용할 수 있다. SSD 티어는 항상 최고의 성능을 제공하며, 하이브리드 어레이를 관리하는데 있어서 매우 중요하다.

티어(Tier) 간의 우선순위는 다음 그림과 같다.

[그림 11-18] DSF 티어 우선순위

다양한 종류의 자원(예를 들어, SSD, HDD 등)들이 함께 풀(Pooled Together)로 구성되고, 클러스터 레벨의 스토리지 티어를 형성한다. 이것은 클러스터의 모든 노드가, 그것이 로컬이든 리모트이든 간에, 전체 티어 용량을 사용할 수 있다는 것을 의미한다.

클러스터 레벨의 티어링 구조는 다음 그림과 같다.

[그림 11-19] DSF 클러스터 레벨의 티어링

일반적인 질문은, 로컬 노드의 SSD가 Full 차면 어떤 일이 발생하는가 이다. 디스크 밸런싱 섹션에서 언급한 바와 같이, 기본 개념은 디스크 티어에서 디바이스의 사용률을 균일하게 유지하는 것이다. 로컬 SSD의 사용률이 높은 경우에, 디스크 밸런싱 기능이 동작하여 로컬 SSD의 콜드(Cold) 데이터를 클러스터의 다른 SSD로 이동시킨다. 이것은 로컬 SSD 공간을 확보하여 로컬 노드가 Write를 네트워크를 경유하지 않고 로컬 SSD에서 수행하도록 한다. 여기에서의 핵심 포인트는 모든 CVM 및 SSD 자원을 사용하여, 잠재적 병목현상의 원인이 될 수 있는 리모트 I/O를 제거하고, 네트워크를 I/O를 수행하는데 따르는 오버헤드를 줄인다는 것이다.

[그림 11-20] DSF 클러스터 레벨의 티어 밸런싱

다른 케이스는 전체 티어 사용률이 지정된 임계 값([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%의 데이터만 이동된다.

[그림 11-21] DSF 티어 ILM

DSF ILM은 I/O 패턴을 항상 모니터링하고, 필요한 경우에 데이터를 마이그레이션 할 뿐만 아니라 티어에 관계 없이 핫 데이터(Hot Data)를 로컬로 가져온다.

3.2.9 디스크 밸런싱(Disk Balancing)

DSF는 매우 동적인 플랫폼으로 설계되어, 다양한 워크로드를 지원할 뿐만 아니라 이종의 노드를 허용한다. 즉, NX-3060-G4와 같은 컴퓨트 중심의 노드와 NX-6035-G4와 같은 스토리지 중심의 노드를 하나의 클러스터에 혼합할 수 있다. 데이터를 균일하게 분산하는 것은 스토리지 용량이 큰 노드를 혼합할 때 매우 중요한 기능이다. DSF는 디스크 밸런싱(Disk Balancing)이라고 불리는 매우 기본적인 기능을 지원하는데, 이것은 클러스터에서 데이터의 균일한 분산을 보장하기 위하여 사용된다. 디스크 밸런싱은 로컬 스토리지 용량에 대한 노드 레벨의 사용률을 기반으로 동작하고, DSF ILM과 통합된다. 디스크 밸런싱의 목적은 사용률이 지정된 임계 값을 넘어선 경우에, 노드들간의 사용률을 균일하게 유지하는 것이다.

다음 그림은 NX-3060-G, NX-6035-G4 노드가 혼합된 클러스터에서, 디스크 사용률이 균일하지 않은 상태이다.

[그림 11-22] 디스크 밸런싱 – 사용률이 균일하지 않은 상태

디스크 밸런싱은 DSF 큐레이터 프레임워크를 이용하는데, 스케줄링 된 프로세스로 수행되거나, 임계 값을 넘어선 경우(예를 들어, 로컬 노드의 스토리지 사용률이 n% 보다 큰 경우)에 수행된다. 데이터가 균일하게 분산되지 않은 경우에, 큐레이터는 이동하여야 할 데이터를 결정하고, 클러스터의 노드들에게 태스크를 분산한다. NX-3060-G4와 같이 모든 노드의 유형이 동일한 경우에 사용률은 매우 균일하여야 한다. 그러나, 만약 노드에서 동작 중인 특정 VM이 다른 VM들 보다 훨씬 많은 데이터를 Write 하게 되면, 노드 당 디스크 사용률이 왜곡(Skew)될 수 있다. 이러한 경우에, 디스크 밸런싱 기능이 동작하여 해당 노드의 콜드 데이터를 클러스터의 다른 노드로 이동시킨다. 노드 유형이 다르거나(예들 들어, NX-3060-G4 + NX-6035-G4), 또는 스토리지 전용 모드(VM을 구동하지 않는)로 사용되는 경우에, 데이터 이동에 대한 필요성이 발생할 수 있다.

다음 그림은 혼합된 클러스터에서 디스크 밸런싱 기능이 수행된 후의 상태를 보여준다.

[그림 11-23] 디스크 밸런싱 – 균일한 상태

특정 시나리오에서, 고객은 일부 노드를 스토리지 전용으로 사용할 수 있다. “스토리지 전용” 노드는, 단지 CVM만이 구동되고, 해당 노드의 주요 목적은 대용량의 스토리지로 사용되는 경우이다. 이러한 경우에, 보다 많은 Read 캐시를 제공하기 위하여 노드의 전체 메모리를 CVM에 할당할 수 있다.

다음 그림은 스토리지 전용 노드가 포함된 클러스터에서 디스크 밸런싱 작업이 어떤 방식으로 수행되는지를 보여준다.

[그림 11-24] 디스크 밸런싱 – 스토리지 전용 노드

3.2.10 스냅샷 및 클론(Snapshots and Clones)

DSF는 VAAI, ODX, nCLI, REST API, 프리즘 등에 의해 사용되는 오프로드된 스냅샷 및 클론(Offloaded snapshots and clones)을 지원한다. 스냅샷 및 클론 작업을 위해 가장 효과적이고 효율적인 알고리즘으로 알려져 있는 ROW(Redirect-On-Write) 알고리즘을 사용한다. 상기의 데이터 구조(Data Structure) 섹션에서 설명한 것과 같이, VM은 파일들(vmdk/vhdx)로 구성되어 있는데, 파일은 뉴타닉스 플랫폼에서는 vDisk이다.

vDisk는 논리적으로 연속된 데이터 청크(Chunk)인 Extents로 구성되는데, Extent는 스토리지 디바이스에서 파일로 저장되는 물리적으로 연속된 데이터인 Extent Group으로 그룹핑 되어 저장된다. 스냅샷 또는 클론 작업이 요청될 때, 베이스 vDisk는 “변경불가능(Immutable)”로 표시되고, Read/Write가 가능한 다른 vDisk가 생성된다. 이 시점에서, 두 개의 vDisk는 동일한 블록 맵(Block Map)을 갖는데, 블록 맵은 해당하는 Extent에 대한 vDisk의 메타데이터 매핑이다. 스냅샷 체인의 검색(Read 레이턴시가 추가됨)을 필요로 하는 전통적인 접근방법과 달리, 모든 vDisk는 자신의 블록 맵을 갖는다. 이것은 일반적으로 Depth가 깊은 스냅샷 체인의 검색에 따른 오버헤드를 제거하기 때문에, 성능에 영향을 주지 않고, 연속적으로 스냅샷을 생성할 수 있게 한다.

스냅샷 생성 요청 시의 동작은 다음 그림과 같다.

[그림 11-32] 스냅샷 블록 매의 예제

이전에 생성된 스냅샷 또는 클론의 vDisk를 대상으로 스냅샷 또는 클론을 생성할 때에도 동일한 메소드가 적용된다.

[그림 11-33] 멀티-스냅샷의 블록 맵 및 신규 Write

VM 또는 vDisk(s)의 스냅샷 또는 클론 작업에 동일한 메소드를 사용한다. VM 또는 vDisk의 클론 작업이 요청될 때, 현재 블록 맵을 락킹(Locking)한 후에 클론을 생성한다. 이러한 작업은 메타데이터 수준에서만 수행되기 때문에, 실질적인 I/O는 발생하지 않는다. 클론의 클론을 생성할 경우에도 동일한 메소드가 적용되는데, 이전에 클론 된(Cloned) VM이 “베이스 vDisk”가 되고, 클론 시에, 해당 블록 맵은 락킹되고, 2개의 클론이 생성되는데, 하나는 클론 대상이 될 VM을 위한 것이고, 다른 하나는 새로운 클론을 위한 것이다.

2개의 클론은 모두 이전 블록 맵을 상속받고, 새로운 Write/Update는 자신의 개별적인 블록 맵에서 발생한다.

[그림 11-34] 멀티-클론 블록 맵

앞에서 언급한 바와 같이, 모든 VM/vDisk는 자신의 개별적인 블록 맵을 갖는다. 그러므로, 상기의 예제에서, 베이스 VM으로부터 생성된 모든 클론은 자신의 블록 맵을 갖고, 모든 Write/Update는 자신의 블록 맵에서 수행된다.

[그림 11-34] 멀티-클론 블록 맵

VM/vDisk의 연속적인 클론 또는 스냅샷 생성 요청은 오리지널 블록 맵의 락킹과 R/W 액세스를 위한 새로운 클론 생성의 원인이 된다.

3.2.11 네트워킹 and I/O

뉴타닉스 플랫폼은 노드들간의 통신을 위해 어떤 종류의 백플레인도 사용하지 않고, 단지 표준 10GbE 네트워크에 기반한다. 뉴타닉스 노드에서 동작하는 VM의 모든 스토리지 I/O는 전용 사설 네트워크(Dedicated Private Network)를 사용하는 하이퍼바이저에 의해 처리된다. I/O 요청은 하이퍼바이저에 의해 처리되는데, 해당 요청은 로컬 CVM의 사설 IP로 전달된다. CVM은 퍼블릭 10GbE 네트워크의 외부 IP를 사용하여 다른 뉴타닉스 노드와 함께 리모트 복제 작업을 수행한다. 모든 Read 요청은 대부분의 경우에 로컬에서 처리되며, 10GbE 네트워크를 전혀 사용하지 않는다. 이것은 퍼블릭 10GbE 네트워크를 사용하는 트래픽은 DSF 리모트 복제 트래픽과 VM 네트워크 I/O라는 것을 의미한다. 그러나, CVM이 가용하지 않거나, 또는 데이터가 리모트에 존재하는 경우에 CVM이 클러스터의 다른 CVM으로 요청을 전달한다. 또한, 디스크 밸런싱과 같은 클러스터 레벨의 태스크인 경우에 10GbE 네트워크에서 일시적으로 I/O가 발생한다.

다음 그림은 VM의 I/O 패스가 사설 및 퍼블릭 10GbE 네트워크 어떤 방식으로 통신하는 지를 보여준다.

[그림 11-54] DSF 네트워킹

3.2.12 데이터 로컬리티 (Data Locality)

컨버지드(컴퓨트 + 스토리지) 플랫폼에서, I/O 및 데이터 로컬리티(Data Locality)는 뉴타닉스에서 클러스터 및 VM 성능을 위해 매우 중요한 기능이다. 상기의 I/O 패스에서 설명한 바와 같이, 모든 Read/Write I/O는 로컬 CVM에 의해 처리된다. VM 데이터는 CVM에 의해 로컬에서 처리되고, CVM이 컨트롤하는 로컬 디스크에 저장된다. HA 이벤트 동안에 VM이 기존 하이퍼바이저 노드에서 다른 하이퍼바이저 노드로 이동될 때, 새로 마이그레이션된 VM 데이터는 이동된 로컬 CVM에 의해 서비스된다. 올드 데이터(Old Data)에 대한 Read 요청(VM의 이동으로 인해 리모트 노드/CVM에 저장된)은 로컬 CVM에 의해 리모트 CVM으로 전달된다. 모든 Write I/O는 로컬에서 즉시 처리된다. DSF는 I/O가 다른 노드에 발생한다는 것을 검출하고, 모든 Read I/O가 로컬에서 서비스될 수 있도록 백그라운드로 데이터를 로컬로 마이그레이션 한다.

데이터 로컬리티는 다음과 같은 두 가지 경우에 발생한다.

  • 캐시 로컬리티 (Cache Locality)
    • Unified Cache에 로컬로 저장된 vDisk 데이터. vDisk extent는 노드에 원격으로 존재할 수 있다.
  • Extent 로컬리티 (Extent Locality)
    • vDisk extent가 VM과 마찬가지로 동일한 노드에 로컬로 존재하여야 한다.

다음 그림은 VM이 하이퍼바이저 노드간을 이동함에 따라 데이터가 어떤 방식으로 따라가는 지를 보여준다.

[그림 11-55] 데이터 로컬리티(Data Locality)


데이터 마이그레이션을 위한 임계 값

캐시 로컬리티는 실시간으로 발생하고, vDisk 오너쉽(Ownership)을 기반으로 결정된다. vDisk / VM이 다른 노드에 이동될 때, vDisk의 오너쉽이 이동된 로컬 CVM으로 변경된다. 일단 오너쉽이 변경되면, 데이터는 Unified Cache에 로컬로 캐시된다. 잠정적으로 오너쉽을 갖고 있는 모든 노드에서 캐시가 존재하게 된다 (현재 리모트 호스트). 이전에 호스팅 하던 Stargate는 300초 이상 리모트 I/O가 발생하는 것을 인지하면 vDisk 토큰을 포기한다. 오너쉽에 의해 강제된 캐시 일관성에 따라 vDisk 데이터를 캐시한다.

Extent 로컬리티는 표본화된 오퍼레이션으로 다음과 같은 조건이 만족되면 Extent Group이 마이그레이션된다. “10분 단위의 윈도우에서 랜덤인 경우 3 터치(Touch), 순차인 경우는 10 터치(Touch)”이고, 1 터치(Touch)는 매 10초 동안에 1번 이상의 Read가 발생한 것을 의미한다.


3.2.13 쉐도우 클론 (Shadow Clones)

아크로폴리스 DSF(Distributed Storage Fabric)은 “쉐도우 클론(Shadow Clones)”으로 불리는 기능을 제공하는데, 이것은 “멀티-리더(Multi-Reader)” 시나리오를 갖는 특정 vDisk 또는 VM 데이터의 분산 캐싱(Distributed Caching) 기술이다. 이것의 가장 좋은 사례는, VDI 배포 동안에 많은 “링크드 클론(Linked Clones)”의 Read 요청이 마스터 또는 베이스 VM 전달되는 경우이다. VMware View인 경우에, 이것은 복제 디스크(Replica Disk)라고 불리며 모든 링크드 클론에 의해 Read 되고, XenDesktop인 경우에, 이것은 MCS Master VM으로 불린다. 이것은 배포 서버, 리파지토리 등과 같이 “멀티-리더(Multi-Reader)” 시나리오를 갖는 모든 시나리오에 적용된다. 데이터 I/O 로컬리티는 VM의 성능 향상을 위해 매우 중요하며, DSF의 핵심 기능이다.

쉐도우 클론 기능을 위해, DSF는 데이터 로컬리티를 위해 수행했던 것과 유사하게 vDisk 액세스 추세를 모니터링 한다. 그러나, 요청이 2개 이상의 리모트 CVM(로컬 CVM 포함)으로부터 발생하고, 모든 요청이 Read I/O인 경우에, vDisk는 변경불가능(Immutable)로 표시된다. 일단, 디스크가 변경불가능으로 표시되면, vDisk에 대한 Read 요청을 캐시에서 처리하기 위해 각 CVM에 의해 로컬에 캐시(베이스 vDisk의 쉐도우 클론) 된다. 이러한 방식으로 각 노드의 VM은 베이스 VM의 vDisk를 로컬에서 Read 하게 한다. VDI 경우에, 이것은 복제 디스크(Replica Disk)가 각 노드에 캐시되고, 베이스 VM에 대한 모든 Read 요청이 로컬에서 서비스 된다는 것을 의미한다.

[NOTE] 데이터는 네트워크 트래픽을 줄이고 효율적인 캐시 사용률을 위해 단지 Read 시에만 마이그레이션 된다.

베이스 VM이 변경되는 경우에는 쉐도우 클론은 삭제되고, 쉐도우 클론 프로세스가 다시 시작된다. 쉐도우 클론 기능은 디폴트로 활성화(뉴타닉스 소프트웨어 4.0.2 이상의 버전)되어 있으며, nCLI 명령어(ncli cluster edit-params enable-shadow-clones=<true/false>)를 사용하여 활성/비활성화 할 수 있다.

쉐도우 클론의 동작은 다음 그림과 같다.

[그림 11-56] 쉐도우 클론(Shadow Clones)


3.2.14 스토리지 레이어 및 모니터링(Storage Layers and Monitoring)

뉴타닉스 플랫폼은 멀티-레이어에서 스토리지를 모니터링 하는데, VM/게스트 OS로부터 물리 디바이스 디스크까지의 모든 범위를 포함한다. 다양한 티어 및 티어들간의 관계를 안다는 것은 솔루션을 모니터링 하고, 오퍼레이션이 어떻게 연관되어 있는지를 시각적인 정보로 표현해 줄 수 있기 때문에 매우 중요하다. 각 레이어에서 제공하는 오퍼레이션 및 모니터링 정보는 다음 그림과 같다.

[그림 11-57] 스토리지 계층

가상머신 레이어 (Virtual Machine Layers)

  • 주요 역할: 하이퍼바이저에 의해 제공하는 VM 메트릭스(Metrics)
  • 설명: VM 또는 게스트 레벨의 메트릭스는 하이퍼바이저로부터 직접 가져오며, VM이 보는 성능과 애플리케이션이 보는 I/O 성능 정보를 제공한다.
  • 사용 시기: 장애처리(Troubleshooting) 또는 VM 레벨의 상세 정보가 필요한 경우

하이퍼바이저 레이어 (Hypervisor Layers)

  • 주요 역할: 하이퍼바이저가 제공하는 메트릭스(Metrics)
  • 설명: 하이퍼바이저 레벨의 메트릭스는 하이퍼바이저로부터 직접 가져오는데, 하이퍼바이저가 보는 가장 정확한 메트릭스이다. 이러한 정보는 하이퍼바이저 노드 별로 또는 클러스터 전체 레벨로 볼 수 있다. 하이퍼바이저 레이어는 플랫폼이 보는 성능 측면에서 가장 정확한 데이터를 제공하기 때문에 대부분의 경우에 활용될 수 있다. 특정 시나리오에서 하이퍼바이저는 VM으로부터 오는 오퍼레이션을 합치거나 나눌 수 있는데, 이러한 경우에 VM과 하이퍼바이저가 제공하는 메트릭스에 차이가 있을 수 있다. 이러한 정보에 뉴타닉스 CVM에 의해 서비스되는 캐시 사용량 정보도 포함된다.
  • 사용 시기: 가장 상세하고 가치 있는 메트릭스를 제공하므로 대부분의 경우에 필요

컨트롤러 계층(Controller Layer)

  • 주요 역할: 뉴타닉스 컨트롤러가 제공하는 메트릭스(Metrics)
  • 설명: 컨트롤러 레벨의 메트릭스는 뉴타닉스 컨트롤러(e.g. Stargate 2009 page)로부터 직접 가져오며, 뉴타닉스 프론트엔드가 NFS/SMB/iSCSI로부터 보는 정보 또는 모든 백엔드 오퍼레이션(e.g. ILM, 디스크 밸런싱 등) 정보를 제공한다. 이러한 정보는 CVM 별로 또는 클러스터 전체 레벨로 볼 수 있다. 컨트롤러가 제공하는 메트릭스는 하이퍼바이저가 제공하는 메트릭스와 일반적으로 일치하지만, 추가적으로 모든 백엔드 오퍼레이션(e.g. ILM, 디스크 밸런싱 등)을 포함한다. 이러한 정보에는 메모리에 의해 서비스되는 캐시 사용량 정보가 포함된다. 특정 케이스에서, IOPS와 같은 메트릭스는 NFS/SMB/iSCSI 클라이언트가 사이즈가 큰 IOPS를 보다 작은 여러 개의 IOPS로 나눌 수 있기 때문에 일치하지 않을 수도 있다. 그러나, 대역폭과 같은 메트릭스는 일치한다.
  • 사용 시기: 하이퍼바이저 레이어와 유사하게, 얼마나 많은 백엔드 오퍼레이션이 수행되고 있는지를 확인할 때 사용된다.

디스크 레이어(Disk Layer)

  • 주요 역할: 디스크 디바이스가 제공하는 메트릭스(Metrics)
  • 설명: 디스크 레벨의 메트릭스는 CVM을 통하여 물리 디스크 디바이스로부터 직접 가져오며, 백엔드가 보는 정보를 제공한다. 이것은 디스크에서 I/O가 수행되는 OpLog 또는 Extent Store의 사용량 정보를 포함한다. 이러한 데이터는 디스크 별로, 특정 노드의 디스크들로, 또는 클러스터 전체 레벨에서 볼 수 있다. 일반적인 경우에, 디스크 오퍼레이션은 입력 Write 뿐만 아니라 캐시의 메모리 부분에서 서비스 되지 않는 Read 숫자와 일치하여야 한다. 캐시의 메모리 부분에서 서비스되는 모든 Read는 해당 오퍼레이션이 디스크 디바이스 사용하지 않기 때문에 디스크 레이어에서 카운트 되지 않는다.
  • 사용 시기: 얼마나 많은 오퍼레이션이 캐시 또는 디스크에서 수행되고 있는지 확인하고자 할 때 활용한다.

메트릭스 및 통계 데이터 보유

메트릭스 및 시계열 데이터는 프리즘 엘리먼트에서 90일 동안 저장된다. 프리즘 센트럴 및 인사이트에서는, 데이터가 무기한 저장된다 (스토리지 용량이 충분하다는 것을 가정).


3.3 서비스 (Services)

3.3.1 뉴타닉스 게스트 툴 (NGT: Nutanix Guest Tool)

뉴타닉스 게스트 툴(NGT: Nutanix Guest Tool)은 소프트웨어 기반의 In-Guest 에이전트 프레임워크로 뉴타닉스 플랫폼에서 VM과 관련된 고급 관리 기능을 제공한다.

본 솔루션은 VM에 설치되는 GNT Installer와 에이전트와 뉴타닉스 플랫폼간에 코디네이션 기능을 수행하는 Guest Tool Framework로 구성되어 있다.

NGT Installer는 다음과 같은 컴포넌트를 포함한다.

  • 게스트 에이전트 서비스 (Guest Agent Service)
  • 셀프-서비스 리스토어 (Self-Service Restore): File-Level Restore CLI로 알려짐
  • VM 모빌리티 드라이버 (VM Mobility Drivers) (AHV를 위한 VritIO 드라이버)
  • 윈도우 VM을 위한 VSS 에이전트 및 하드웨어 프로바이더
  • 리눅스 VM을 위한 애플리케이션 컨시스턴트 스냅샷 지원 (Quiesce를 위한 스크립트를 통해)

프레임워크는 몇 개의 하이-레벨 컴포넌트로 구성되어 있다.

  • 게스트 에이전트 서비스 (Guest Agent Service)
    • 아크로폴리스, 뉴타닉스 서비스, 게스트 에이전트간의 게이트웨이다. 클러스터에서 CVM에 분산되어 있으며, 선정된 NGT 마스터는 프리즘 리더인 노드에서 위치한다 (클러스터 vIP를 사용).
  • 게스트 에이전트 (Guest Agent)
    • NGT 설치 과정에 VM의 OS에 배포되는 에이전트 및 관련된 서비스이다. 모든 로컬 기능 (e.g., VSS, 셀프-서비스 리스토어(SSR) 등)을 처리하고, 게스트 툴 서비스와의 통신 및 제어 기능을 수해한다.

컴포넌트들간의 관계는 다음 그림과 같다.

[그림] 게스트 툴 매핑

3.3.1.1 게스트 툴 서비스 (Guest Tool Service)

게스트 툴 서비스(Guest Tool Service)는 다음과 같은 2개의 주요 역할을 수행한다.

  • NGT 마스터 (NGT Master)
    • NGT 프록시로부터 받은 요청을 처리하고, 아크로폴리스 컴포넌트와 인터페이스 한다. 클러스터 당 1개의 NGT 마스터가 동적으로 선정되고, 만약 마스터에 장애가 발생하면 새로운 마스터가 선정된다. 본 서비스는 내부적으로 포트 2073에서 Listen 한다.
  • NGT 프록시 (NGT Proxy)
    • 모든 CVM에서 동작하며, 요구된 액티비티를 수행하기 위해 요청을 NGT 마스터로 전달한다. 프리즘 리더 (VIP를 호스팅하고 있는) 역할을 수행하고 있는 CVM이 게스트 에이전트로부터의 통신을 처리한다. NGT 프록시는 외부적으로 포트 2074에서 Listen 한다.

현재 NGT 마스터

다음의 명령어를 사용하여 NGT 마스터 역할을 수행하고 있는 CVM의 IP를 확인할 수 있다.

nutanix_guest_tools_cli get_master_location


NGT 마스터와 NGT 프록시간의 관계는 다음 그림과 같다.

[그림] 게스트 툴 서비스 (Guest Tool Service)


3.3.1.2 게스트 에이전트 (Guest Agent)

게스트 에이전트(Guest Agent)는 앞에서 언급했던 것과 같이 다음 그림과 같은 하이-레벨 컴포넌트로 구성되어 있다.


[그림] 게스트 에이전트 (Guest Agent)


3.3.1.3 통신 및 보안 (Communication and Security)

게스트 에이전트 서비스(Guest Agent Service)는 SSL을 사용하여 뉴타닉스 클러스터 IP를 통해 게스트 툴 서비스(Guest Tool Service)와 통신한다. 뉴타닉스 클러스터 컴포넌트와 User VM이 다른 네트워크를 사용하는 경우에는 다음과 같은 조건을 확인하여야 한다.

  • User VM 네트워크로부터 클러스터 IP로의 통신이 가능한지 확인한다.

또는

  • 방화벽 규칙(관련된 NAT 설정을 포함하여)을 생성하여 User VM 네트워크로부터 클러스터 IP의 2074 포트로의 통신을 가능하게 한다

게스트 툴 서비스는 CA(Certificate Authority)로 동작하며, NGT가 활성화된 User VM을 위한 인증서 쌍Certificate Pair)의 생성에 대한 책임을 갖는다. 본 인증서는 User VM을 위한 설정된 ISO에 포함되고, NGT 배포 프로세스의 일부로 사용된다. 이러한 인증서는 설치 과정에서 User VM의 내부에 설치된다.

3.3.1.4 NGT 에이전트 설치 (NGT Agent Installation)

NGT 에이전트 설치는 프리즘, CLI/Scripts(nCLI/REST/PowerShell)로 수행된다.

프리즘을 통하여 NGT를 설치하기 위해서는 VM 페이지를 방문하고, NGT를 설치할 VM을 선택하고 “Enable NGT”를 클릭한다.


[그림] VM에서 NGT를 활성화

NGT 설치 과정을 계속하기 위해서는 “Yes”를 클릭한다.


[그림] NGT 프롬프트 활성화

다음 그림에서 보는 것과 같이, VM은 소프트웨어와 유일한 인증서를 포함하는 생성된 Installer가 마운트 된 CD-ROM을 가져야 한다.

[그림] NGT 활성화 – CD-ROM

NGT Installer CD-ROM은 OS에서 다음과 같이 보여진다.

[그림 ] NGT 활성화 – OS에서 CD-ROM

설치 과정을 시작하기 위해서는 CD-ROM을 더블클릭 한다.

[그림] NGT 활성화 – Installer

설치 프로세스의 일부로서 Python, PyWin, 뉴타닉스 모빌리티 드라이버(크로스-하이퍼바이저 호환성을 위한)가 설치된다.

설치가 완료되면, VM을 재부팅하여야 한다.

설치 및 재부팅이 완료되면, “Programs and Features”에서 다음과 같이 설치된 모듈들을 확인할 수 있다.


[그림] NGT 활성화 – 설치된 프로그림

다음 그림과 같이 NGT 에이전트 및 VSS 하드웨어 프로바이더 서비스를 확인할 수 있다.


[그림] NGT 활성화 – 서비스

이제, NGT가 정상적으로 설치되었으며, NGT 기능을 사용할 수 있다.


대량 NGT 배포 (Bulk NGT Deployment)

NGT를 각각의 VM에서 설치하지 않고, 베이스 이미지에 NGT를 내장하여 배포하는 것이 가능하다. 베이스 이미지에 포함된 NGT를 사용하기 위해서는 다음과 같은 절차를 따른다.

1. NGT를 마스터 VM에 설치하고 통신이 정상적인지를 확인한다.

2. 마스터 VM으로부터 VM을 복제(Clone) 한다

3. 각각의 클론에서 NGT ISO를 마운트 한다 (새로운 인증서 쌍을 생성하기 위해).

  • 예제: ncli ngt mount vm-id=<CLONE_ID> OR via Prism
  • 자동화 방법: 곧 제공 예정

4. 클론의 전원을 인가한다.

클론 VM이 부팅될 때, VM은 새로운 NGT ISO를 검출하고, 설정 파일 및 새로운 인증서를 복사하고, 게스트 툴 서비스와 통신을 시작한다.

3.3.2 OS 커스터마이제이션 (OS Customization)

뉴타닉스는 Cloudinit 및 Sysprep를 사용하여 OS를 커스터마이제이션 할 수 있는 기능을 제공한다. Cloudinit은 패키지로 Linux 클라우드 서버의 부트스트랩을 처리할 수 있다. Cloudinit은 Linux 인스턴스의 초기화 및 커스터마이제이션을 가능하게 한다. Sysprep은 Windows에서 사용할 수 있는 OS 커스터마이제이션 툴이다.

일반적인 OS 커스터마이제이션은 다음과 같은 기능을 포함한다.

  • 호스트 이름 설정 (Setting Hostname)
  • 패키지 설치 (Installing packages)
  • 사용자 및 키 관리 추가 (Adding users / key management)
  • 커스텀 스크립트 (Custom Scripts)

3.3.2.1 지원하는 설정 기능 (Supported Configurations)

일반적인 OS 커스터마이제이션은 다음과 같은 기능을 포함한다.

  • 하이퍼바이저
    • AHV
  • 운영체제
    • Linux: 대부분의 최신 배포 버전
    • Windows: 대부분의 최신 배포 버전

3.3.2.2 전체 조건 (Pre- Requisites)

Cloudinit를 사용하기 위해서는 다음과 같은 조건을 만족하여야 한다.

  • Cloudinit 패키지가 Linux 이미지에 설치되어야 한다.

Sysprep은 Windows 설치 버전에 디폴트로 포함되어 있다.

3.3.2.3 패키지 설치 (Package Installation)

Cloudinit은 다음과 같음 명령어를 사용하여 설치할 수 있다.

Red Hat 기반의 시스템 (CentOS, RHEL)

yum -y install CloudInit

Debian 기반의 시스템 (Ubuntu)

apt-get -y update; apt-get -y install CloudInit

Sysprep은 기본 Windows 설치 파일의 일부이다.

3.3.2.4 이미지 커스터마이제이션 (Image Customization)

OS 커스터마이제이션을 위해 커스텀 스크립트를 사용할 수 있도록, 프리즘 또는 REST API로 관련 기능을 제공한다. 이러한 옵션은 VM의 생성 및 클론 과정에서 지정할 수 있다.

[그림] 커스텀 스크립트 – 입력 옵션

뉴타닉스는 커스텀 스크립트 경로를 지정하기 위한 몇 개의 옵션을 제공한다.

  • ADSF 경로
    • 이전에 ADSF에 업로드 한 파일 사용
  • 파일 업로드
    • 사용될 파일을 업로드
  • 스크립트 입력 또는 복사
    • Cloudinit 스크립트 도는 Unatttend.xml 텍스트

뉴타닉스는 스크립트를 포함하는 CD-ROM의 생성을 통해 첫 번째 부트 동안에 유저 데이터 스크립트를 Cloudinit 또는 Sysprep 프로세스로 전달한다. 일단 프로세스가 완료되면 CD-ROM을 제거한다.

3.3.2.5 입력 포맷팅 (Input Formatting)

플랫폼은 다양한 유저 데이터 입력 포맷을 지원한다. 여기에서는 몇 가지 중요한 입력 포맷에 대해 설명한다.

유저 데이터 스크립트 (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

Cloudinit 실행 검증

Cloudinit 로그는 /var/log/cloud-init.log 및 cloud-init-output.log 파일에서 확인할 수 있다.

Unattend.xml (Sysprep – Windows)

Unattend.xml 파일은 부트 시에 이미지 커스터마이제이션을 위해 Sysprep이 사용하는 입력 파일이다.

스크립트는 “<?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>

3.3.3 블록 서비스 (Block Services)

아크로폴리스 블록 서비스(Acropolis Block Service) 기능은 백엔드 DSF 스토리지를 iSCSI를 통하여 외부 소비자에게 노출시킨다 (게스트 OS, 물리 호스트, 컨테이너 등).

이것은 모든 종류의 OS가 DFS에 접근하여 DFS의 스토리지 서비스를 이용할 수 있게 하는데, OS는 하이퍼바이저를 바이패스하여 뉴타닉스와 직접적으로 통신한다.

ABS(Acropolis Block Service)의 핵심 Use-Case는 다음과 같다.

  • 공유 디스크 (Shared Disks)
    • Oracle RAC, Microsoft 페일오버 클러스터링 등
  • 퍼스트 클래스 엔티티로서의 디스크
    • 실행 컨텍스트의 수명이 짧고, 데이터가 매우 중요한 애플리케이션
    • 컨테이너, 오픈스택 등
  • 게스트가 요청하는 iSCSI
    • 베어 메탈 소비자
    • vSphere 환경에서 동작하는 Microsoft Exchange

3.3.3.1 지원하는 OS (Qualified Operating Systems)

지원하는 OS는 iSCSI 사양을 준수하는 OS로 다음과 같은 OS를 지원한다.

  • Microsoft Windows Server 2008 R2, 2012 R2
  • Redhat Enterprise Linux 6.0+

3.3.3.2 블록 서비스 컨스트럭트 (Block Services Constructs)

ABS(Acropolis Block Services)를 구성하는 엔티티는 다음과 같다.

  • Data Services IP: 클러스터 레벨의 IP로 iSCSI 로긴 요청 시에 사용한다 (AOS 4.7 버전에 포함된 기능).
  • Volume Group: iSCSI 타깃 및 디스크 디바이스의 그룹으로 중앙 집중화된 관리, 스냅샷, 정책 설정 등을 지원한다.
  • Disks: Volume Group에서 스토리지 디바이스 (iSCSI 타깃에게는 LUN으로 인식됨)
  • Attachment: 특정한 Initiator IQN을 Volume Group에 액세스할 수 있도록 허용하는 것

[NOTE]백엔드에서 VG의 디스크는 DSF에서 vDisk이다.

3.3.3.3 전제 조건

ABS 설정을 시작하기 전에, 센트럴 디스커버리 및 로그인 포탈 역할을 수행하는 Data Services IP를 설정하여야 한다.

“Cluster Details” 페이지에서 Data Services IP를 설정할 수 있다.

[그림] 블록 서비스 – Data Services IP

Data Services IP는 nCLI / API를 통해 설정할 수 있다.

ncli cluster edit-params external-data- services-ip-address=<DATA SERVICES IP ADDRESS>

3.3.3.4 타깃 생성 (Target Creation)

블록 서비스를 사용하기 위한 첫 번째 작업은 iSCSI 타깃이 되는 “Volume Group”을 생성하는 것이다.

스토리지 페이지에서 오른쪽 상단의 “+ Volume Group”을 클릭한다.

[그림] 블록 서비스 – 볼륨 그룹 추가

볼륨 그룹 생성을 위해 설정하여야 할 정보는 다음과 같다.

[그림] 블록 서비스 – 볼륨 그룹 생성 정보

타깃(LUN으로 보여짐)에 디스크를 추가하기 위해 “+ Add new disk” 버튼을 클릭하면 다음과 같은 화면이 출력된다.

[그림] 블록 서비스 – 디스크 추가

여러 개의 디스크를 추가하기 위해서는 “Add” 버튼을 클릭하고, 상기와 같은 작업을 반복한다.

디스크를 추가한 후의 작업은 볼륨 그룹을 VM 또는 Initiator IQN에 할당하는 것이다. 이렇게 함으로써 VM은 iSCSI 타깃에 접근할 수 있다.

[그림] 블록 서비스 – Initiator IQN / VM

“Save” 버튼을 클릭하면 볼륨 그룹 설정이 완료된다.

볼륨 그룹은 ACPI / API 이용해 생성할 수 있다.

# Create VG (VG 생성)

vg.create <VG Name>

# Add disk(s) to VG (VG에 디스크 추가)

vg.disk_create <VG Name> container=<CTR Name> create_size=<Disk size, e.g. 500G>

# Attach initiator IQN to VG (VG를 Initiator IQN에 붙임)

vg.attach_external <VG Name> <Initiator IQN>

3.3.3.5경로 HA (Path High-Availability)

앞에서 설명했던 것과 같이 Data Services IP는 디스커버리를 위해 사용된다. 이것은 개별적인 CVM IP 주소를 모두 알고 있을 필요 없이 1개의 주소만 사용할 수 있게 한다.

Data Services IP는 현재 iSCSI 마스터에 할당된다. 마스터에 장애가 발생하면, 새로운 iSCSI 마스터가 설정되고, Data Services IP로 할당된다. 이러한 과정을 통해 디스커버리 포탈을 항상 가용한 상태로 유지된다.

iSCSI initiator는 iSCSI 타깃 포탈로 Data Services IP로 설정된다. 로그인 요청이 발생하면, 플랫폼은 정상 동작 중인 Stargate로 iSCSI 로그인 요청을 리다이렉트 한다.

[그림] 블록 서비스 – 로그인 리다이렉트

액티브 Stargate가 다운되면, Initiator는 iSCSI 로그인을 Data Services IP로 재시도하는데, 해당 요청은 정상 동작 중인 다른 Stargate로 리다이렉트 된다.

[그림] 블록 서비스 – 장애 처리

이전에 장애가 발생했던 Stargate가 복구되어 정상적인 상태를 유지하게 되면, 현재의 액티브 Stargate는 I/O 작업을 멈추고 액티브 iSCSI 세션을 종료한다. Initiator가 iSCSI 로그인을 재시도할 때, Data Services IP는 복구된 Stargate로 리다이렉트한다.

[그림] 블록 서비스 – 페일백

헬스 모니터링 및 디폴트 (Health Monitoring and Defaults)

블록 서비스를 위한 Stargate 헬스는 Zookeeper를 사용하여 모니터링 되는데, 이것은 DSF에서 사용하는 동일한 메커니즘이다.

페일백을 위한 디폴트 시간은 120초이다. 이것은 이전에 장애가 발생한 Stargate가 2분 이상 동안 정상적인 상태를 유지하게 되면, I/O를 멈추고 세션을 종료한 후에, iSCSI 로그인을 재시도하도록 한다.

상기와 같은 메커니즘을 사용하면, 경로 HA를 위해 클라이언트에서 제공하는 MPIO를 사용할 필요가 없다. 타깃에 연결할 때, “Enable Multi-path”를 활성화할 필요가 없다.

[그림] 블록 서비스 – No MPIO

3.3.3.6 다중경로 (Multi-Pathing)

iSCSI 프로토콜 스펙에 따르면, Initiator와 타깃(Target)간에 타깃 당 1개의 iSCSI 세션(TCP connection)을 사용하여야 한다. 이것은 Stargate와 타깃간의 관계가 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
     }
   }

다음의 1개의 VG를 생성하고 3개의 디스크 디바이스를 생성한 것이다. 클라이언트 프로그램에서 검색하면 각각의 디바이스에 대한 개별적인 타깃을 다음과 같이 볼 수 있다.

[그림] 블록 서비스 – 버츄얼 타깃

즉, 각 디스크 디바이스는 자신의 iSCSI 세션을 가지게 되고, 이러한 세션들은 복수의 Stargate를 통하여 호스팅 됨으로써 확장성과 성능을 향상시킨다.

[그림] 블록 서비스 – 다중 경로

로드 밸런싱은 각 타깃에 대해 iSCSI 세션 설정 (iSCSI 로그인) 시에 발생한다.


Active Path(s)

다음 명령어를 이용하여 버츄얼 타깃을 호스팅하고 있는 액티브 스타게이트(Active Stargate) 정보를 확인할 수 있다 (스타게이트를 호스팅하고 있는 CVM IP 출력).

# Windows 
Get-NetTCPConnection -State Established -RemotePort 3205 

# Linux 
iscsiadm -m session -P 1

AOS 4.7 버전에서 클러스터 노드들로 타깃은 분산하기 위해 간단한 해쉬 함수가 사용된다. 필요한 경우에 뉴타닉스는 알고리즘을 보완하고 최적화하는 작업을 계속 진행할 예정이다. 또한, 노드가 정상 동작을 하는 한 선호된 노드를 계속 사용하는 것도 가능하다.

SCSI UNMAP (TRIM)

ABS는 SCS T10 스펙 기반의 SCSI UNMAP (TRIM) 명령어를 지원한다. 이 명령어는 삭제된 블록으로부터 디스크 공간을 회수하고자 할 때 사용된다.


3.3.4 파일 서비스 (File Services)

파일 서비스(File Services)는 유저가 뉴타닉스 플랫폼을 고가용성을 지원하는 파일 서버 기능을 사용할 수 있게 한다. 파일 서비스는 유저가 홈 디렉토리 및 파일을 저장할 수 있도록 1개의 네임스페이스를 제공한다.

3.3.4.1 지원 환경 (Supported Configurations)

파일 서비스는 다음과 같은 환경에서 지원된다 (좀 더 상세한 정보는 관련 문서를 참조한다).

  • 하이퍼바이저 (Hypervisor)
    • AHV
    • ESXi (AOS 5.0 이상)
  • 파일 프로토콜 (File Protocols)
    • CIFS 2.1
  • 호환 가능한 기능 (Compatible Features)
    • Async-DR

3.3.4.2 파일 서비스 컨스트럭트 (File Service Construct)

파일 서비스는 다음과 같은 하이-레벨 컨스트럭트로 구성되어 있다

  • 파일 서버 (File Server)
    • 하이-레벨 네임스페이스로 각 파일 서버는 배포된 자신의 파일 서버 VM(FSVM: File Server VM)을 갖는다.
  • 공유 (Share)
    • 유저에게 제공되는 공유(Share)로 파일 서버는 복수의 Share(e.g. 부서별 공유 등)를 갖는다.
  • 폴더 (Folder)
    • 폴더는 파일 저장을 위한 것으로 FSVM을 통해 공유된다.

컨스트럭트들간의 매핑은 다음 그림과 같다.


[그림] 파일 서비스 매핑

파일 서비스 기능에는 뉴타닉스 플랫폼에서 가용성 및 확장성을 보장하기 위해 구현한 동일한 분산 기술이 적용되어 있다. 파일 서버 배포의 일부로써 최소 3개의 FSVM(File Services VM)이 배포된다.


[그림] 파일 서비스 상세


지원되는 프로토콜 (Supported Protocols)

뉴타닉스 NOS 4.6 버전에서는, SMB(버전 2.1까지)가 파일 서비스의 클라이언트 커뮤니케이션을 위해 지원되는 유일한 프로토콜이다.


FSVM(File Services VM)은 뉴타닉스 플랫폼에서 에이전트 VM으로 동작하며, 설정 및 설치 프로세스의 일부로서 배포된다.

아크로폴리스 플랫폼에서 FSVM의 상세한 뷰는 다음 그림과 같다.


[그림] FSVM 배포 아키텍처

3.3.4.3 인증 및 허가 (Authentication and Authorization)

파일 서비스 기능은 Microsoft AD(Active Directory) 및 DNS와 완벽하게 통합되어 있다. 이것은 AD에 이미 설정되어 있는 모든 인증 및 허가 기능의 사용을 가능하게 한다. 파일 관리를 위한 공유 권한, 유저 및 그룹 관리 등은 전통적인 Windows MMC를 사용하여 수행할 수 있다.

설치 프로세스의 일부로서 다음과 같은 AD / DNS 객체가 생성된다.

  • 파일 서버를 위한 AD Computer 계정
  • 파일 서버 및 FSVM을 위한 AD SPN(Service Principal Name)
  • 모든 FSVM 가리키는 파일 서버를 위한 DNS 엔트리
  • 각 FSVM을 위한 DNS 엔트리

파일 서버 생성을 위한 AD 권한 (AD Privileges for File Server Creation)

파일 서비스 기능을 배포할 때 AD 및 DNS 객체가 생성되기 때문에 도메인 관리자 또는 동등한 권한을 갖는 유저 계정을 사용하여야 한다.


3.3.4.4 고가용성 (High-Availability)

FSVM은 데이터 스토리지를 위해 In-Guest iSCSI를 통해 액세스할 수 있는 아크로폴리스 볼륨 API를 사용한다. 이것은 FSVM의 장애 시에 모든 iSCSI target으로의 연결을 가능하게 한다.

FSVM 스토리지의 개요는 다음 그림과 같다.

[그림] FSVM 스토리지

경로 가용성(Path Availability)를 제공하기 위해 FSVM 내에서 DM-MPIO를 사용할 수 있는데, FSVM은 디폴트로 액티브 경로를 로컬 CVM으로 지정한다.

[그림] FSVM MPIO

로컬 CVM이 가용하지 않은 경우(e.g. 액티브 경로 장애)에, DM-MPIO은 리모트 CVM으로 페일오버 경로를 활성화시키고 IO를 인계 받는다.

[그림 11-73] FSVM MPIO 페일오버

로컬 CVM이 다시 정상 동작하게 되면, 로컬 IO을 제공하기 위해 로컬 CVM으로 액티브 경로를 지정한다.

일반적인 운영 환경에서 각 FSVM은 데이터 스토리지를 위해 자신의 VG(Volume Group)와 통신을 수행하며, 다른 VG와는 수동적인 연결(Passive Connection)을 갖는다. 각 FSVM은 1개의 IP를 가지는데, 클라이언트가 DFS 리퍼럴 프로세스(DSF Referral Process)의 일부로서 FSVM과의 통신을 위한 것이다. DFS 리퍼럴 프로세스 클라이언트를 폴더를 호스팅하고 있는 정확한 IP로 연결시켜 주기 때문에, 클라이언트는 개별적인 FSVM의 IP 주소를 알 필요가 없다.

[그림] FSVM의 일반적인 운영 프로세스

FSVM의 장애(e.g. 유지보수 또는 전원 비인가 등) 시에, 장애가 발생한 FSVM의 IP와 VG는 클라이언트의 가용성을 보장하기 위해 다른 FSVM이 인계 받는다.

장애가 발생한 FSVM의 IP와 VG의 인계 과정은 다음 그림과 같다.

[그림] FSVM 페일오버 시나리오

장애가 발생한 FSVM이 다시 정상 동작하게 되면, IP와 VG을 다시 인계 받고 클라이언트에게 IO 서비스 제공한다.


3.3.5 컨테이너 서비스 (Container Services)

뉴타닉스는 도커(Docker)를 사용하여 뉴타닉스 플랫폼에서 영구적인 컨테이너 사용할 수 있는 기능을 제공한다. 이전에도 뉴타닉스 플랫폼에서 도커를 구동시키는 것이 가능하였으나, 컨테이너의 비영구적 속성으로 인해 데이터 영속성(Data Persistence)에 대한 이슈가 있었다.

도커와 같은 컨테이너 기술은 하드웨어 가상화와 다른 접근 방법을 사용한다. 전통적인 가상화 기술에서 각 VM은 자신의 OS를 갖고 있지만, VM들은 기반이 되는 하드웨어를 공유하는 방식이다. 애플리케이션 및 관련된 자원을 포함하고 있는 컨테이너는 독립적인 프로세스로 구동이 되지만 기반이 되는 OS 커널을 공유하는 방식이다.

VM과 컨테이너간의 간단한 비교는 다음과 같다.

구분 가상머신(VM) 컨테이너(Containers)
가상화 유형 하드웨어 레벨의 가상화 OS 커널 가상화
오버헤드 많음 적음
프로비저닝 속도 느림 (수초 ~ 수분) 실시간 / 빠름 (us ~ ms)
성능 오버헤드 제한된 성능 본래의 성능
보안 완전히 격리 (보안에 유리) 프로세스 레벨의 격리 (보안 취약)

3.3.5.1 지원되는 환경

컨테이너는 다음과 같은 환경에서 지원된다 (지원되는 환경에 대한 상세한 정보는 관련 문서를 참조한다.)

  • 하이퍼바이저
    • AHV
  • 컨테이너 시스템
    • Docker 1.11

AOS 4.7 버전에서는 도커 기반의 컨테이너에서 단지 스토리지 통합만을 지원한다. 그러나, 다른 종류의 컨테이너 시스템은 뉴타닉스 플랫폼에서 VM으로 구동할 수 있다.

3.3.5.2 컨테이너 서비스 컨스트럭트 (Container Services Constructs)

ACS (Acropolis Container Services)는 다음과 같은 엔티티로 구성된다.

  • Nutanix Docker Host Image: 뉴타닉스는 사전에 설정 및 테스트된 Docket Host Image를 제공하며, 뉴타닉스 서포트 포털에서 다운로드 받을 수 있다. 본 이미지는 도커 호스트 프로비저닝을 위한 Docker Machine Driver에 의해 사용된다.
  • Nutanix Docker Machine Driver: Docker Machine 및 Acropolis Image Services를 사용하여 Docker Container Host Provisioning를 처리한다.
  • Nutanix Docker Volume Driver: 볼륨의 생성, 마운트, 포맷하고 컨테이너에 Attach하기 위한 ABS (Acropolis Block Services)와의 인터페이스에 대한 책임을 갖는다.

다음 엔티티는 도커를 구성한다 (Note: 모든 것이 필요한 것은 아니다).

  • Docker Image: 컨테이너를 이한 베이스 이미지
  • Docker Registry: 도커 이미지를 위한 저장 공간
  • Docker Hub: 온라인 컨테이너 마켓플래이스 (퍼블릭 도커 레지스트리)
  • Docker File: Docker Image 생성 방법을 설명하는 텍스트 파일
  • Docker Container: 구동 중인 도커 이미지 인스턴스
  • Docker Engine: 도커 컨테이너의 생성, 배포, 구동을 담당
  • Docker Swarm: 도커 호스트 클러스터링 및 스케줄링 플랫폼
  • Docker Daemon: 도커 클라이언트로부터의 요청을 처리하고, 컨테이너의 빌드, 구동, 배포 등과 같은 작업을 처리한다.

3.3.5.3 아키텍처 (Architecture)

뉴타닉스 솔루션은 Docker Machine을 사용하여 생성된 VM에서 구동 중인 Docker Engine을 사용한다. 뉴타닉스 플랫폼에서 이러한 머신들은 일반 VM과 혼합하여 구동할 수 있다.

[그림] 도커 – 하이 레벨 아키텍처

뉴타닉스는 Docker Volume Driver를 개발하여 제공하는데, 뉴타닉스 ABS (Acropolis Block Services) 기능을 사용하여 볼륨 그룹을 생성, 포맷하고 컨테이너에 Attach 한다. 이것은 컨테이너의 전원이 온/오프 되거나 이동되었을 때 데이터를 영구적으로 유지하게 한다.

데이터 영속성은 뉴타닉스 볼륨 드라이버를 이용하여 구현되었는데, 볼륨을 호스트 및 컨테이너에 Attach하기 위해 ABS(Acropolis Block Services)를 이용한다.

[그림] 도커 – 블록 서비스

3.3.5.4 전제 조건

컨테이너 서비스를 사용하기 위해서는 다음과 같은 조건이 만족되어야 한다.

  • 뉴타닉스 클러스터가 AOS 4.7 또는 이상 이여야 한다.
  • 뉴타닉스 Docker Host Image를 다운로드 하여 아크로폴리스 이미지 서비스에서 이미지로 존재하여야 한다.
  • 뉴타닉스 데이터 서비스 IP가 설정되어야 한다.
  • Docker Toolbox가 설정을 위해 클라이언트 머신에 설치되어야 한다.
  • 뉴타닉스 Docker Machine Driver가 클라이언트의 경로에 존재하여야 한다.

3.3.5.5 도커 호스트 생성 (Docker Host Creation)

상기의 전제 조건에 모두 만족되었다고 가정할 때의 첫 번째 단계는 Docker Machine을 이용하여 뉴타닉스 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-machine ssh를 통하여 새롭게 프로비전된 Docker Host로 접속한다.

docker-machine ssh <DOCKER_HOST_NAME>

볼륨 드라이버를 시작하기 전에, 드라이버가 최신 버전인지를 확인하고, 최신 버전이 아닌 경우에 다음의 명령어로 최신 버전을 받는다.

docker pull orionapps/vol-plugin

최신 버전을 받았으면, 뉴타닉스 Docker Volume Driver를 시작한다.

~/start-volume-plugin.sh

상기 명령어를 수행하면 설정을 위해 다음과 같은 정보를 입력 받는다.

  • 클러스터 IP (Cluster IP)
  • 데이터 서비스 IP (Data Services IP)
  • 프리즘 사용자 ID (Prism Username)
  • 프리즘 패스워드 (Prism Password)
  • 뉴타닉스 스토리지 컨테이너 이름 (Nutanix Storage Container Name)

상기 정보를 입력하고 나서, 다음의 명령어로 컨테이너가 볼륨 플러그인을 수행하는 것을 확인할 수 있다.

[root@DOCKER-NTNX-00 ~]# docker ps
CONTAINER ID        IMAGE                  ... NAMES
37fba568078d        orionapps/vol-plugin   ... NutanixVolumePlugin

3.3.5.6 도커 컨테이너 생성 (Docker Container Creation)

뉴타닉스 Docker Host가 배포되고, 볼륨 드라이버를 시작한 후에, 영구 스토리지를 갖는 컨테이너를 프로비저닝 한다.

영구 스토리지를 갖는 컨테이너의 프로비저닝은 전형적인 Docker run command structure와 뉴타닉스 볼륨 드라이버를 이용하여 수행하는데 예제는 다음과 같다.

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

상기 명령어를 수행하였을 때의 백-엔드 워크플로우는 다음과 같다.

[그림] 도커 – 컨테이너 생성 워크플로우

상기 과정을 완료하면, 영구 스토리지를 갖는 컨테이너가 구동된 것이다.


3.4 백업 및 DR (Backup and Disaster Recovery)

뉴타닉스는 유저가 DSF에서 구동중인 VM 및 오브젝트를 백업, 복원 및 재해복구(Disaster Recovery) 할 수 있는 백업 및 DR(Disaster Recovery) 기능을 제공한다.

다음 섹션에서 다음과 같은 주제를 설명한다.

  • 구현 컨스트럭트 (Implementation Constructs)
  • 보호 엔티티 (Protection Entities)
  • 백업 및 복원 (Backup and Restore)
  • 복제 및 DR (Replication and DR)

[NOTE] 뉴타닉스가 백업 및 DR을 위한 기능을 제공하더라도, 플랫폼이 제공하는 기능(VSS, 스냅샷 등)을 활용하기 위하여 전통적인 솔루션 (e.g., Commvault, Rubrik, etc)을 사용할 수 있다.

3.4.1 구현 컨스트럭트 (Implementation Constructs)

뉴타닉스 DR에서는 다음과 같은 컨스트럭트를 사용한다.

3.4.1.1 보호 도메인 (Protection Domain: PD)
  • 주요 역할: 보호되어야 할 VM 또는 파일의 매크로 그룹
  • 설명: 지정된 스케줄에 기반하여 함께 복제되어야 할 VM 및 파일의 그룹이다. PD는 컨테이너 전체를 보호할 수도 있고, 개별적인 VM 또는 파일을 보호할 수도 있다.

PRO TIP

다양한 RPO/RTO를 충족할 수 있도록 다양한 서비스 티어를 위해 복수의 PD를 생성한다. 파일 분산(e.g. Golden Images, ISO, etc.)을 위해 복제할 파일을 갖는 PD를 생성한다.

3.4.1.2 컨시스턴시 그룹 (Consistency Group)
  • 주요 역할: PD에서 Crash-Consistent를 지원하는 VM 또는 파일의 부분 집합
  • 설명: PD의 부분 집합으로 Crash-Consistent 방식으로 스냅샷을 생성할 필요가 있는 VM 또는 파일의 그룹이다. CG는 VM/파일을 리스토어 할 때, VM/파일들이 Consistent State로 복구되는 것을 보장한다. PD는 여러 개의 컨시스턴시 그룹을 가질 수 있다.

PRO TIP

App 및 DB와 같이 상호 의존성이 있는 VM들을 Consistent State로 복구하기 위해서는, 해당애플리케이션 또는 서비스 VM을 컨시스턴시 그룹으로 생성한다.

3.4.1.3 복제 스케줄(Replication Schedule)
  • 주요 역할: 스냅샷 및 복제 스케줄
  • 설명: 특정한 PD 및 CG에서 VM의 스냅샷 및 복제 스케줄이다.

PRO TIP

스냅샷 스케줄은 요구된 RPO와 동일하여야 한다.

3.4.1.4 보유 정책(Retention Policy)
  • 주요 역할: 보유하여야 할 로컬 또는 리모트 스냅샷의 개수
  • 설명: 보유 정책에서는 유지하여야 할 로컬 및 리모트 스냅샷의 개수를 정의한다.

PRO TIP

보유 정책은 VM/파일 당 요구된 복구 지점(Restore Point)의 개수와 동일하여야 한다.

3.4.1.5 리모트 사이트 (Remote Site)
  • 주요 역할: 리모트 뉴타닉스 클러스터
  • 설명: 리모트 뉴타닉스 클러스터는 백업 또는 DR을 위한 타깃(Target)으로 사용될 수 있다.

PRO TIP

타깃 사이트는 전체 사이트 장애를 대비하여 충분한 용량(컴퓨트/스토리지)을 가지고 있어야 한다. 특정 환경인 경우에, 클러스터에서 랙(Rack)간의 복제 및 DR이 의미가 있는 경우가 있다.


단일 사이트에서 PD, CG, VM/파일간의 논리적인 관계는 다음과 같다.

[그림 11-37] DR 컨스트럭트 매핑

3.4.2 보호 엔티티 (Protecting Entities)

다음과 같은 워크플로우를 사용하여 VMs, VGs, Files와 같은 엔티티를 보호할 수 있다.

“Data Protection” 페이지에서 “+Protection Domain -> Async DR”을 선택한다.

[그림] DR – Async PD

PD 이름을 지정하고 “Create” 버튼을 클릭한다.

[그림 11-37] DR – PD 생성

보호할 엔티티를 선택한다.

[그림] DR – Async PD

“Protect Selected Entities”를 클릭한다.

[그림] DR – 엔티티 보호

보호되어야 할 엔티티가 “Protected Entities” 영역에 출력된다.

[그림] DR – 보호될 엔티티

“Next”를 클릭한 후에, 스냅샷 및 복제 스케줄을 생성하기 위해 “Next Schedule”를 클릭한다.

[그림] DR – 스케줄 생성

스케줄 설정을 완료하기 위해 “Create Schedule”를 클릭한다.

복수 스케줄 (Multiple Schedules)

복수의 스냅샷 및 복제 스케줄을 생성하는 것이 가능하다. 예를 들어, 로컬 백업을 위해 시간 단위의 스케줄과 리모트 사이트로 일 단위의 복제를 위한 스케줄을 생성할 수 있다.

단순화를 위해 전체 컨테이너를 보호할 수 있다는 것을 언급하는 것은 중요하다. 그러나, 뉴타닉스 플랫폼은 보호할 수 있는 레벨을 세분화하여, VM 또는 파일 레벨의 보호 기능을 제공한다.

3.4.3 백업 및 복원 (Backup and Restore)

뉴타닉스 백업 기능은 DSF 스냅샷 기능을 이용하는데, Cerebro에 의해 기동되고, Stargate에 의해 수행된다. 스냅샷 기능은 효율적인 스토리지 활용 및 낮은 오버헤드를 보장하기 위해 zero copy 방식을 사용한다. 뉴타닉스 스냅샷에 대한 상세한 정보는 “스냅샷 및 클론(Snapshots and Clones)” 섹션을 참조한다.

일반적인 백업 및 복원 오퍼레이션은 다음을 포함한다.

  • 스냅샷 (Snapshot): 복원 지점을 생성하고 복제 (필요한 경우에)한다.
  • 복원 (Restore): 이전의 스냅샷으로부터 VM 및 파일을 복원한다 (오리지널 오브젝트를 대체).
  • 클론 (Clone): 복원과 유사하나 오리지널 오브젝트를 대체하지 않는다 (스냅샷으로부터 새로운 오브젝트를 생성한다).

“Data Protection” 페이지의 “Protecting Entities” 섹션에서 이전에 생성된 보호 도메인(Protection Domain)을 확인할 수 있다.

[그림] DR – PD 확인

대상 PD를 선택하면, 다음과 같은 옵션을 볼 수 있다.

[그림] DR – PD Actions

“Take Snapshot”을 클릭하면 선택한 PD의 스냅샷을 생성할 수 있으며 필요한 경우에 리모트 사이트로 복제할 수 있다.

[그림] DR – 스냅샷 생성

“Migrate” 버튼을 클릭하여 리모트 사이트로 엔티티를 페일오버 할 수 있다.

[그림] DR – 마이그레이트

또한, 아래와 같이 테이블 형태로 PD 스냅샷을 조회할 수 있다.

[그림] DR – 로컬 스냅샷

여기서부터 PD 스냅샷을 복원 (Restore) 또는 클론 (Clone) 기능을 설명한다.

[그림] DR – 스냅샷 복원

“Create new entities”를 선택하면 PD의 스냅샷을 지정된 Prefix를 갖는 새로운 엔티티로 클론 작업을 수행하고, “Overwrite existing entities”를 선택하면 현재의 엔티티를 스냅샷으로 대체한다.

스토리지 전용 백업 타깃

백업 및 아카이빙 목적을 위해, 백업 타깃의 역할을 수행하는 스토리지 전용의 클러스터를 리모트 사이트로 설정할 수 있다. 이러한 경우에 데이터는 스토리지 전용의 클러스터로 복제된다.

3.4.4 App Consistent Snapshots

뉴타닉스는 VSS (VmQuiesced Snapshot Service) 기능을 제공하는데, 이것은 애플리케이션 일관성 스냅샷의 생성을 보장할 수 있도록 OS 및 애플리케이션의 오퍼레이션을 잠시 멈추는 기능을 수행한다.

VSS (VmQuiesced Snapshot Service)

VSS는 Windows 용어로 일반적으로 Volume Shadow Copy Service이다. 그러나, 이러한 솔루션이 Windows 및 Linux에 적용되므로, 뉴타닉스는 VmQuiesced Snapshot Service로 수정하여 사용한다.

3.4.4.1 지원 환경

본 솔루션은 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+

3.4.4.2 전체 조건

뉴타닉스 VSS 스냅샷을 사용하기 위해서는 다음과 같은 조건을 만족하여야 한다.

  • 뉴타닉스 플랫폼
    • 클러스터 가상 IP (Cluster Virtual IP)가 반드시 설정되어야 한다.
  • 게스트 OS / UVM
    • NGT가 설치되어야 한다.
    • CVM VIP가 2074 포트로 통신되어야 한다.
  •  DR 설정
    • UVM이 “Use application consistent snapshots”이 활성화된 PD에 존재하여야 한다.

3.4.4.3 아키텍처

본 기능은 AOS 4.6 버전에서부터 NGT (Nutanix Guest Tools) 패키지의 일부로 설치되는 Nutanix Hardware VSS provider를 사용하여 구현되었다. NGT에 대한 상세 정보는 “Nutanix Guest Tools” 섹션을 참조한다.

VSS 아키텍처는 다음 그림과 같다.

[그림] VSS 아키텍처

Application Consistent Snapshot을 생성하기 위해서는 다음과 같은 데이터 보호 워크플로우를 따르고, VM을 보호할 때 “Use application consistent snapshots”를 활성화한다.

뉴타닉스 VSS 활성화/비활성화

UVM에서 NGT가 활성화된 경우에, 뉴타닉스 VSS 기능은 디폴트로 활성화 된다. 그러나, 다음의 명령어를 사용하여 뉴타닉스 VSS 기능을 비활성화 할 수 있다.

ncli ngt disable-applications application-names=vss_snapshot vm_id=<VM_ID>

3.4.4.4 Windows VSS 아키텍처

뉴타닉스 VSS 솔루션은 Windows VSS 프레임워크와 통합되었다. Windows VSS 아키텍처는 다음 그림과 같다.

[그림] 뉴타닉스 VSS – Windows 아키텍처

NGT를 설치하면 NGT Agent 및 VSS Hardware Provider 서비스를 확인할 수 있다.

[그림] VSS Hardware Provider

3.4.4.5 Linux VSS 아키텍처

Linux 솔루션은 Windows 솔루션과 유사하게 동작하지만, Linux 배포판에는 Windows VSS 프레임워크와 같은 것이 제공되지 않기 때문에 스크립트가 사용된다.

뉴타닉스 VSS 솔루션은 Windows VSS 프레임워크와 통합되었다. 다음 그림은 하이-레벨 아키텍처이다.

[그림] 뉴타닉스 VSS – Linux 아키텍처

Pre-Freeze 및 Post-Thaw 스크립트는 다음 디렉토리에 위치한다.

  • Pre-freeze: /sbin/pre_freeze
  • Post-thaw: /sbin/post-thaw

ESXi Stun 제거하기

ESXi는 VMware Guest Tools를 사용하여 Application Consistent Snapshot을 지원한다. 그러나, 이러한 프로세스 동안에, 델타 디스크가 생성되고, ESXi는 가상 디스크를 새로운 Write IO를 처리하는 새로운 델타 파일에 다시 매핑시키기 위해 VM을 “stuns” 한다. Stuns는 VMware 스냅샷이 제거될 경우에도 발생한다.

이러한 Stun 프로세스 동안에 VM의 게스트 OS는 어떠한 종류의 오퍼레이션도 실행시키지 않기 때문에, 결국 교착 상태에 있게 된다 (e.g., PING 실패, IO 없음). Stun 시간은 vmdk의 개수와 데이터스토어 메타데이터 오퍼레이션(e.g., 새로운 델타 디스크 생성 등)의 속도에 의존적이다.

뉴타닉스 VSS를 사용하면 VMware 스냅샷 및 Stun 프로세스를 바이패스하기 때문에 VM 및 OS의 가용성 및 성능에 전혀 영향을 주지 않는다.

3.4.5 복제 및 DR (Replication and Disaster Recovery)

뉴타닉스는 복제 및 DR 기능을 제공하는데, 스냅샷 및 클론 섹션에서 설명한 동일한 기능을 기반으로 구현되었다. 세레브로(Cerebro)는 DSF에서 DR 및 복제 기능의 관리에 대한 책임을 갖는 컴포넌트이다. 세레브로는 모든 노드에서 동작하며, 세레브로 마스터가 선정되고(NFS 마스터와 유사), 선정된 세레브로 마스터는 복제 태스크의 관리에 대한 책임을 갖는다. 세레브로 마스터 역할을 하는 CVM에 장애가 발생하면, 다른 CVM이 마스터로 선정되고, 세레브로 마스터 역할을 수행한다. 세레브로 페이지의 URL은 <CVM IP>:2020 이다. DR 기능은 다음과 같이 기능으로 세분화할 수 있다.

  • 복제 토폴로지 (Replication Topology)
  • 복제 생애주기 (Replication Lifecycle)
  • 글로벌 데이터 중복제거 (Global Deduplication)

3.4.5.1 복제 토폴로지(Replication Topology)

전통적으로, Site to Site, Hub and Spoke, Full and/or Partial Mesh와 같은 몇 가지의 주요 복제 토폴로지(Replication Topology)가 있다. 단지 Site to Site, Hub and Spoke 토폴로지를 허용하는 전통적인 솔루션과 달리, 뉴타닉스는 Full Mesh 또는 유연한 Many-to-Many 모델을 제공한다.

[그림 11-36] 복제 토폴로지(Replication Topology)의 예제

기본적으로, 이것은 관리자가 자신의 니즈에 적합한 복제 기능을 구현할 수 있게 한다.

3.4.5.2 복제 생애주기 (Replication Lifecycle))

뉴타닉스 복제는 상기에서 언급한 세레브로 서비스를 이용한다. 세레브로(Cerebro) 서비스는 동적으로 선정된 CVM인 “세레브로 마스터(Cerebro Master)”와 모든 CVM에서 동작하는 세레브로 슬레이브(Cerebro Slave)로 분류된다. 세레브로 마스터 역할을 수행하는 CVM에 장애가 발생하면, 새로운 마스터가 선정된다.

세레브로 마스터는 로컬 세레브로 슬레이브에게 태스크 분배 관리, 그리고 리모트 복제가 발생하는 경우에 리모트 세레브로 마스터와의 코디네이션에 대한 책임을 갖는다.

복제 작업 동안에, 세레브로 마스터가 복제되어야 할 데이터를 찾고, 복제 작업을 세레브로 슬레이브에게 할당하면, 세레브로 슬레이브는 복제할 데이터 및 어디로 보내야 할지를 스타게이트에게 알려준다.

복제 아키텍처는 다음 그림과 같다.

[그림 11-38] 복제 아키텍처

리모트 사이트에 프록시를 설정하는 것이 가능한데, 프록시는 클러스터로부터 들어오는 모든 코디네이션 및 복제 트래픽의 브리지 역할을 수행한다.

PRO TIP

프록시를 설정한 리모트 사이트인 경우에, 클러스터 IP를 사용하면, 프리즘 리더가 해당 IP로 지정되고, CVM에 장애가 발생하더라도 가용성이 보장된다.

프록시를 사용한 복제 아키텍처는 다음 그림과 같다.

[그림 11-39] 복제 아키텍처 – 프록시

특정 시나리오에서, SSH 터널을 사용하여 리모트 사이트를 설정하는 것이 가능한데, 이 경우에 모든 트래픽은 2개의 CVM간에만 흐른다.

[NOTE] SSH 터널은 개발 및 테스트 환경에서만 설정하여야 하고, 가용성을 보장하기 위해 클러스터 IP를 사용한다.

SSH 터널을 사용한 복제 아키텍처는 다음 그림과 같다.

[그림 11-40] 복제 아키텍처 – SSH 터널

3.4.5.3 글로벌 데이터 중복제거(Global Deduplication)

데이터 중복제거 엔진 섹션에서 설명한 바와 같이, DSF는 메타데이터 포인터만의 갱신으로 데이터 중복제거 작업을 수행한다. 동일한 개념이 DR 및 복제 기능에도 적용된다. WAN을 통하여 데이터를 전송하기 전에, DSF는 리모트 사이트에 질의(Query)를 수행하고, 타깃 사이트에 지문이 존재하는지(데이터가 이미 존재한다는 것을 의미)를 체크한다. 만약 지문이 존재하면, 데이터가 전송되지 않고, 단지 메타데이터 갱신만 발생한다. 타깃에 존재하지 않는 데이터는 압축이 된 후에 타깃 사이트로 전송된다. 이 시점에서, 양 사이트에 존재하는 데이터는 데이터 중복제거를 위해 사용된다.

다음 그림은 각각 1개 이상의 PD를 갖는 3개의 사이트로 구성된 환경에서 글로벌 데이터 중복제거 동작을 보여준다.

[그림 11-41] 복제 데이터 중복제거

PRO TIP

복제 시의 데이터 중복제거 작업을 수행하기 위해서는 소스 및 타깃 컨테이너/vStore에서 데이터 중복제거(Fingerprinting) 기능을 활성화해야 한다.


3.4.6 클라우드 커넥트 (Cloud Connect)

클라우드 커넥트(Cloud Connect) 기능은 DSF의 DR/복제 기능을 클라우드 프로바이더(Amazon Web Services, Microsoft Azure 지원)로 확장한 것이다.

[NOTE] 클라우드 커넥트 기능은 현재 백업/복제 기능만을 지원한다.

DR/복제를 위해 사용될 리모트 사이트를 생성하는 것과 매우 유사하게, “클라우드 리모트 사이트(Cloud Remote Site)”를 생성하여야 한다. 새로운 클라우드 리모트 사이트를 생성할 때, 뉴타닉스는 엔드포인트로 사용될 EC2(현재 m1.xlarge) 또는 Azure VM(현재 D3)에서 1개의 노드를 갖는 뉴타닉스 클러스터를 자동으로 스핀업 한다.

클라우드 인스턴스는 로컬 클러스터 동작을 위해 사용된 것과 동일한 아크로폴리스 Code-Base를 기반으로 한다. 이것은 모든 복제 기능(e.g. 글로벌 데이터 중복제거, 델타 기반의 복제 등)을 사용할 수 있다는 것을 의미한다.

복수의 뉴타닉스 클러스터가 클라우드 커넥트 기능을 사용하는 경우에, A) 리전(Region)에서 동작하는 동일한 AMI 인스턴스를 공유할 수도 있고, B) 새로운 인스턴스를 스핀업 할 수도 있다.

클라우드 인스턴스(Cloud Instance)의 스토리지는 “클라우드 디스크(Cloud Disk)”를 사용하는데, 클라우드 디스크는 S3(AWS) 또는 BlobStore(Azure)에서 지원하는 논리적 디스크이다. 데이터는 egroups로 저장되는데, 이것은 오브젝트 스토어에서 파일이다.

클라우드 커넥트로 사용된 “리모트 사이트”의 논리적 표현은 다음 그림과 같다.

[그림 11-42] 클라우드 커넥트 리전(Region)

클라우드 기반의 리모트 사이트가 다른 뉴타닉스 리모트 사이트와 유사하기 때문에, 고가용성을 요구하는 경우(e.g. 전체 리전 장애 시에도 데이터 가용성 보장)에 클러스터는 복수의 리전에 복제할 수 있다.

[그림 11-43] 클라우드 커넥트 멀티-리전(Region)

클라우드 커넥트를 사용하여 복제된 데이터에 대해 동일한 복제/보유 정책을 적용할 수 있다. 데이터/스냅샷의 오래되었거나 만료가 되면, 클라우드 클러스터는 필요한 경우에 데이터를 삭제한다.

만약 복제가 자주 발생하지 않으면(e.g. 일 또는 주 단위), 플랫폼은 예정된 복제 작업 시간 이전에 클라우드 인스턴스의 전원을 On 시키고, 복제 작업이 완료된 후에 전원을 Down 하도록 설정할 수 있다.

모든 클라우드 리전에 복제된 데이터는 클라우드 리모트 사이트를 갖는 기존 또는 새로 생성한 뉴타닉스 클러스터로 내려 받은 후에 복구할 수 있다.

[그림 11-44] 클라우드 커넥트 – 복구(Restore)


3.4.7 매트로 가용성 (Metro Availability)

뉴타닉스는 컴퓨트 및 스토리지 클러스터를 복수의 물리적 사이트에 걸쳐 구성할 수 있는 “스트레치 클러스터링(Stretch Clustering) 기능을 제공한다. 이러한 배포 환경에서 컴퓨트 클러스터는 2개의 로케이션에 걸쳐지게 되고, 공유 스토리지 풀에 액세스할 수 있다.

이것은 VM HA 도메인을 단일 사이트에서 2개의 사이트로 확장한 것으로, “0”에 근접한 RTO 및 “0” RPO를 지원한다.

이러한 배포 환경에서, 각 사이트는 자신의 뉴타닉스 클러스터를 가지지만, 컨테이너는 Write ACK를 송신하기 전에 리모트 사이트에 동기적으로 복제함으로써 “확장”된다.

매트로 가용성 아키텍처는 다음 그림과 같다.

[그림 11-45] 매트로 가용성 – 정상 상태

사이트 장애가 발생하면, HA 이벤트가 발생하고 VM은 다른 사이트에서 재기동 된다. 사이트 장애 시의 동작은 다음 그림과 같다.

[그림 11-46] 매트로 가용성 – 사이트 장애

2개의 사이트간에 링크 장애가 발생하면, 각 클러스터는 독립적으로 오퍼레이션 한다. 링크가 복구되면, 사이트는 재동기화를 수행(변경분만 동기화)하고, 동기적으로 복제를 시작한다.

링크 장애 시의 동작은 다음 그림과 같다.

[그림 11-47] 매트로 가용성 – 링크 장애



3.5 Application Mobility Fabric

내용 추가 예정입니다.


3.6 관리 (Administration)

3.6.1 중요 페이지 (Important Pages)

이것은 표준 유저 인터페이스 이외에 고급 뉴타닉스 페이지로 상세한 통계 및 메트릭스 정보를 확인할 수 있다. URL 포맷은 http://<뉴타닉스 CVM IP>:<포트/패스>로, 예를 들어, “http://MyCVM-A:2009”와 같다.

[NOTE] 다른 서브넷에서 접속하고자 하는 경우에, 페이지에 액세스하기 위해서는 CVM에서 iptables가 비활성화되어야 한다.

2009 페이지 (2009 Page)

스타게이트 페이지로 백엔드 스토리지 시스템을 모니터링 하기 위해 사용되며, 고급 사용자에 의해 사용되어야 한다.

2009/latency 페이지 (2009/latency Page)

스타게이트 페이지로 백엔드 레이턴시를 모니터링 하기 위해 사용된다.

2009/vdisk_stats 페이지 (2009/vdisk_stats Page)

스타게이트 페이지로 vDisk와 관련된 다양한 통계 정보를 제공하는데, I/O 사이즈, 레이턴시, Write Hits (e.g., OpLog, eStore), Read Hits (e.g. SSD, HDD 등) 등과 같은 정보를 포함한다.

2009/h/traces 페이지 (2009/h/traces Page)

스타게이트 페이지로 오퍼레이션의 액티비티를 추적하는데 사용된다.

2009/h/vars 페이지 (2009/h/vars Page)

스타게이트 페이지로 다양한 카운터의 모니터링을 위해 사용된다.

2010 페이지 (2010 Page)

큐레이터 페이지로 큐레이터 동작을 모니터링 하기 위해 사용된다.

2010/master/control 페이지 (2010/master/control Page)

큐레이터 컨트롤 페이지로 수작업으로 큐레이터 잡(Curator Job)을 수행시키기 위해 사용된다.

2011 페이지 (2011 Page)

크로노스(Chronos) 페이지로 큐레이터에 의해 스케줄링 된 잡(Job) 및 태스크(Task)를 모니터링 하기 위해 사용된다.

2020 페이지 (2020 Page)

세레브로(Cerebro) 페이지로 PD, 복제 상태 및 DR을 모니터링 하기 위해 사용된다.

2020/h/traces 페이지 (2002/h/traces Page)

세레브로 페이지로 PD 오퍼레이션 및 복제와 관련된 액티비티를 추적하기 위해 사용된다.

2030 페이지 (2030 Page)

메인 아크로폴리스 페이지로 호스트, 모든 작업 중인 태스크, 네트워킹 등과 관련된 상세 정보를 제공한다.

2030/sched 페이지 (2030/sched Page)

아크로폴리스 페이지로 위치 결정을 위해 사용된 VM 및 자원 스케줄링에 대한 상세 정보를 제공한다. 또한, 가용한 호스트 자원 및 각 호스트에서 동작 중인 VM 정보를 제공한다.

2030/tasks 페이지 (2030/tasks Page)

아크로폴리스 페이지로 아크로폴리스 태스크 및 상태 정보를 제공한다. 태스크에 대한 상세 JSON 정보를 얻기 위해서는 태스크 UUID를 클릭한다.

2030/vms 페이지 (2030/vms Page)

아크로폴리스 페이지로 아크로폴리스 VM 및 VM에 대한 상세 정보를 제공한다. 콘솔을 연결하려면 VM 이름을 클릭한다.


3.6.2 클러스터 명령어 (Cluster Commands)

클러스터 상태 체크 (Check cluster status)

설명: CLI 명령어로 클러스터 상태 체크

cluster status

로컬 CVM 서비스 상태 체크 (Check local CVM service status)

설명: CLI 명령어로 특정 CVM의 서비스 상태 체크

genesis status

뉴타닉스 클러스터 업그레이드 (뉴타닉스 cluster upgrade)

설명: CLI 명령어 클러스터 롤링(Rolling) 업그레이드 수행

업그레이드 패키지를 CVM의 “/tmp/”에 업로드

패키지의 압축 해제

tar xzvf ~/tmp/nutanix*

업그레이드 수행

~/tmp/install/bin/cluster -i ~/tmp/install upgrade

상태 체크

upgrade_status

노드 업그레이드 (Node(s) Upgrade)

설명: 특정 노드를 현재 클러스터 버전으로 업그레이드

지정된 버전으로 동작 중인 CVM에서 다음 명령어를 수행

cluster -u <NODE_IP(s)> upgrade_node

하이퍼바이저 업그레이드 상태 (Hypervisor upgrade status)

설명: 임의의 CVM에서 CLI 명령어를 이용하여 하이퍼바이저 업그레이드 상태 체크

host_upgrade --status

모든 CVM에서 상세 정보는 다음 로그 파일을 참조한다.

~/data/logs/host_upgrade.out

CLI로 클러스터 서비스 재시작 (Restart cluster service from CLI)

설명: CLI로 클러스터 서비스 재시작

서비스 중지

cluster stop <Service Name>

중지된 서비스 재시작

cluster start #NOTE: This will start all stopped services

CLI로 클러스터 서비스 시작 (Start cluster service from CLI)

설명: CLI로 중지된 클러스터 서비스 시작

중지된 서비스 시작

cluster start #NOTE: This will start all stopped services

또는 특정 서비스만 시작

Start single service: cluster start <Service Name>

CLI로 로컬 서비스 재시작 (Restart local service from CLI)

설명: CLI로 특정 클러스터 서비스 재시작

서비스 중지

genesis stop <Service Name>

서비스 시작

cluster start

CLI로 로컬 서비스 시작 (Start local service from CLI)

설명: CLI로 중지된 클러스터 서비스 시작

cluster start #NOTE: This will start all stopped services

cmdline으로 클러스터에 노드 추가 (Cluster add node from cmdline)

설명: CLI로 클러스터 노드 추가 실행

ncli cluster discover-nodes | egrep "Uuid" | awk '{print $4}' | xargs -I UUID
ncli cluster add-node node-uuid=UUID

vDisk 개수 출력 (Find number of vDisks)

설명: vDisk 개수 출력

vdisk_config_printer | grep vdisk_id | wc -l

클러스터 ID 출력 (Find cluster ID)

설명: 현재 클러스터의 클러스터 ID 출력

zeus_config_printer | grep cluster_id

오픈 포트 (Open port)

설명: iptables를 통하여 포트 활성화

sudo vi /etc/sysconfig/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport <PORT> -j ACCEPT
sudo service iptables restart

쉐도우 클론 체크 (Check for Shadow Clones)

설명: “name#id@svm_id” 형식으로 쉐도우 클론 출력

vdisk_config_printer | grep '#'

레이턴시 페이지 상태 초기화 (Reset Latency Status Page)

설명: 레이턴시 페이지(<CVM IP>:2009/latency)의 카운터를 초기화

allssh "wget $i:2009/latency/reset"

vDisk 개수 출력 (Find numbers of vDisks)

설명: DSF에서 현재 vDisk (files) 개수 출력

vdisk_config_printer | grep vdisk_id | wc -l

CLI로 큐레이터 스캔 시작 (Start Curator scan from CLI)

설명: CLI로 큐레이터 FULL 스캔 시작

allssh "wget -O - "http://$i:2010/master/api/client/StartCuratorTasks?task_type=2";"

Ring을 콤팩트 (Compact ring)

설명: 메타데이터 Ring을 콤팩트

allssh "nodetool -h localhost compact"

NOS 버전 출력 (Find NOS version)

설명: NOS 버전 출력 (NOTE: nCLI 명령어로도 수행 가능)

allssh "cat /etc/nutanix/release_version"

CVM 버전 출력 (Find CVM version)

설명: CVM 이미지 버전 출력

allssh "cat /etc/nutanix/svm-version"

수작업으로 vDisk Fingerprint 수행 (Manually fingerprint vDisk(s))

설명: 특정 vDisk에 대해 데이터 중복제거(Fingerprint) 수행 (NOTE: 컨테이너에서 데이터 중복제거 기능이 활성화되어 있어야 함)

vdisk_manipulator –vdisk_id=<vDisk ID> --operation=add_fingerprints

모든 클러스터 노드의 Factory_Config.JSON 출력 (Echo Factory_Config.json for all cluster nodes)

설명: 클러스터에서 모든 노드의 factory_config.json 출력

allssh "cat /etc/nutanix/factory_config.json"

특정 노드의 NOS 버전 업그레이드 (Upgrade a single Nutanix node’s NOS version)

설명: 클러스터의 다른 노드와 일치시키기 위해 특정 노드의 NOS 버전 업그레이드

~/cluster/bin/cluster -u <NEW_NODE_IP> upgrade_node

DSF에서 파일(vDisks) 목록 출력 (List files(vDisks) on DSF)

설명: 클러스터의 다른 노드와 일치시키기 위해 특정 노드의 NOS 버전 업그레이드

nfs_ls

도움말 출력

nfs_ls --help

NCC (Nutanix Cluster Check) 설치 (Install NCC)

설명: 잠재적인 이슈 및 클러스터 헬스를 체크하기 위하여 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 실행 (Run NCC)

설명: 잠재적인 이슈 및 클러스터 헬스를 체크하기 위하여 NCC 실행한다. NCC를 실행하는 것이 모든 클러스터 이슈에 대한 Troubleshooting에서 첫 번째 작업이다.

NCC가 설치되어 있는지 확인한다 (상기 설치 단계 참조).

NCC 헬스 체크를 실행

ncc health_checks run_all

프로그레스 모니터 CLI를 사용하여 태스크 목록 출력 (List tasks using progress monitor cli)

progress_monitor_cli -fetchall

프로그레스 모니터 CLI를 사용하여 태스크 제거 (Remove task using progress monitor cli)

progress_monitor_cli --entity_id=<ENTITY_ID> --operation=<OPERATION> --entity_type=<ENTITY_TYPE> --delete


3.6.3 메트릭스 및 임계 값

다음 섹션에서 뉴타닉스 백엔드의 특정한 메트릭스 및 임계 값에 대해 설명한다.

보다 상세한 내용 추가 예정입니다.

3.6.4 Gflags

내용 추가 예정입니다.

3.6.5 장애 처리 및 고급 관리

아크로폴리스 로그 출력 (Find Acropolis logs)

설명: 클러스터에서 아크로폴리스 로그 출력

allssh "cat ~/data/logs/Acropolis.log"

클러스터 ERROR 로그 출력 (Find cluster error logs)

설명: 클러스터의 ERROR 로그 출력

allssh "cat ~/data/logs/<COMPONENT NAME or *>.ERROR"

스타게이트에 대한 예제:

allssh "cat ~/data/logs/Stargate.ERROR"

클러스터 FATAL 로그 출력 (Find cluster fatal logs)

설명: 클러스터의 FATAL 로그 출력

allssh "cat ~/data/logs/<COMPONENT NAME or *>.FATAL"

스타게이트에 대한 예제:

allssh allssh "cat ~/data/logs/Stargate.FATAL"


3.6.5.1 스타게이트 2009 페이지 사용하기 (Using the 2009 Page (Stargate))

대부분의 경우에, 프리즘(Prism)에서 원하는 모든 정보 및 데이터를 얻을 수 있다. 그러나, 특정 시나리오에서 또는 좀 더 상세한 데이터가 필요한 경우에, 2009 페이지로 알려진 스타게이트(Stargate) 정보를 활용할 수 있다. 2009 페이지는 “<CVM IP>:2009”로 액세스 한다.


백엔드 페이지 액세스

만약, 다른 네트워크 세그먼트(L2 서브넷)에서 접속하고자 하는 경우에, 모든 백엔드 페이지에 액세스하기 위해서는 IP tables에 Rule을 추가해 주어야 한다.


TOP 페이지는 클러스터에 대한 다양한 상세 정보를 제공한다.

[그림 14-1] 2009 페이지 – 스타게이트 개요


본 섹션에는 2개의 주요 영역이 있는데, 첫 번째 영역은 Admitted / Outstanding 오퍼레이션의 개수를 보여주는 I/O Queue 정보이다. 다음 그림은 개요 섹션의 일부인 Queue 부분이다.

[그림 14-2] 2009 페이지 – 스타게이트 개요 - Queues


두 번째 영역은 캐시 사이즈 및 Hit Ratio 정보를 보여주는 Unified Cache에 대한 상세 정보이다. 다음 그림은 개요 섹션의 일부인 Unified Cache 부분이다.

[그림 14-3] 2009 페이지 – 스타게이트 개요 – Unified Cache


PRO TIP

만약 워크로드가 Read Heavy인 경우에, 최대의 Read 성능을 위해서는 Hit Ratio가 80~90%+ 이상이어야 한다.


[NOTE] 상기의 값은 스타게이트/CVM 별로 제공된다.


다음 섹션은 “클러스터 상태(Cluster State)”인데, 클러스터에서 다양한 스타게이트 및 스타게이트의 디스크 사용률 정보를 제공한다. 스타게이트 및 디스크 사용률 정보(가용/전체)는 다음 그림과 같다.

[그림 14-4] 2009 페이지 – 클러스터 상태 – 디스크 사용률


다음은 “NFS 슬레이브(NFS Slave)” 섹션으로 vDisk에 대한 상세 및 통계 정보를 제공한다. vDisk 및 I/O 상세 정보는 다음 그림과 같다.

[그림 14-5] 2009 페이지 – NFS 슬레이브 – vDisk 통계


PRO TIP

잠재적인 성능 이슈를 확인하기 위해서는 다음과 같은 정보를 참조한다.

1. 평균 레이턴시 (Average latency)

2. 평균 오퍼레이션 사이즈 (Average op size)

3. 평균 미처리 개수 (Average outstanding)

보다 상세한 정보는 vdisk_stats 페이지를 참조한다.


3.6.5.2 2009/vdisk_stats 페이지 사용 (Using the 2009/vdisk_stats Page)

2009 vdisk_stats 페이지는 vDisk에 대한 보다 상세한 정보를 제공하는데, 무작위성(Randomness), 레이턴시 히스토그램, I/O 사이즈, Working Set 상세 정보 등과 같은 아이템의 상세정보 및 히스토그램을 포함한다.

왼쪽 컬럼에서 “vDisk ID”를 클릭하면 vdisk_stats 페이지로 이동할 수 있다. vDisk ID에 대한 상세 정보는 다음 그림과 같다.

[그림 14-6] 2009 페이지 – vDisks 정보

vdisk_stats 페이지는 상세한 vDisk 통계 정보를 제공한다.


[NOTE] 상기 페이지에서 정보는 실시간으로 제공되면, 패이지 갱신을 통하여 데이터를 갱신할 수 있다.


첫 번째 영역은 “Ops and Randomness” 섹션으로 I/O 패턴이 랜덤인지 순차인지를 보여준다. “Ops and Randomness” 섹션 정보는 다음 그림과 같다.

[그림 14-7] 2009 페이지 – vDisks 통계 – Ops and Randomness

다음 섹션에서는 프론트엔드 Read 및 Write I/O 레이턴시 (VM/OS가 보는 레이턴시) 정보를 제공한다. “프론트엔드 Read 레이턴시” 히스토그램은 다음 그림과 같다.

[그림 14-8] 2009 페이지 – vDisks 통계 – 프론트엔드 Read 레이턴시

“프론트엔드 Write 레이턴시” 히스토그램은 다음 그림과 같다.

[그림 14-9] 2009 페이지 – vDisks 통계 – 프론트엔드 Write 레이턴시

다음 주요 영역은 I/O 사이즈 분포로 Read 및 Write I/O 사이즈의 히스토그램 정보를 제공한다. “Read 사이즈 분포”는 다음 그림과 같다.

[그림 14-10] 2009 페이지 – vDisks 통계 – Read I/O 사이즈

“Write 사이즈 분포”는 다음 그림과 같다.

[그림 14-11] 2009 페이지 – vDisks 통계 – Write I/O 사이즈

다음 주요 영역은 “Working Set Size” 섹션으로 최근 2분 및 1시간 동안에 working set size에 대한 정보를 제공한다. 이것은 Read 및 Write로 구분된다. “Working Set Size” 테이블은 다음과 같다.

[그림 14-12] 2009 페이지 – vDisks 통계 – Working Set

“Read Source”는 어느 티어 또는 어느 위치에서 Read I/O가 서비스되었는지에 대한 상세 정보를 제공한다. “Read Source” 상세 정보는 다음과 같다.

[그림 14-13] 2009 페이지 – vDisks 통계 – Read Source


PRO TIP

만약 Read 레이턴시가 높은 경우에, vDisk에 대한 Read Source를 살펴보고, I/O가 어디에서 서비스되고 있는지를 확인한다. 대부분의 경우에, 높은 레이턴시는 Read가 HDD(Extent Store HDD)에서 수행될 때 발생한다.


“Write Destination” 섹션은 새로운 Write I/O가 어디에서 발생하는지에 대한 정보를 제공한다. “Write Destination” 테이블은 다음과 같다.

[그림 14-14] 2009 페이지 – vDisks 통계 – Write Destination


PRO TIP

랜덤 또는 64K 이하의 I/O는 OpLog에 Write 된다. 큰 또는 순차 I/O는 OpLog를 바이패스(Bypass)하여 직접적으로 Extent Store에 Write 된다.


다른 중요한 정보는 무슨 데이터가 ILM을 통하여 HDD에서 SSD로 마이그레이션 되는가 이다. “Extent Group Up-Migration” 테이블은 최근 300, 3600, 86400초 동안에 HDD로부터 SSD로 마이그레이션 된 데이터 정보를 제공한다.

[그림 14-15] 2009 페이지 – vDisks 통계 – Extent Group Up-Migration


3.6.5.3 2010 페이지 사용 (큐레이터)

2010 페이지는 큐레이터 맵리듀스 프레임워크의 모니터링을 위한 상세 페이지로, 잡(Jobs), 스캔(Scan) 및 관련된 태스크(Task)에 대한 상세 정보를 제공한다.

큐레이터 페이지는 http://<CVM IP>:2010로 액세스할 수 있다.


[NOTE] 만약 큐레이터 마스터에 있지 않은 경우에는, “큐레이터 마스터(Curator Master” 링크를 클릭한다.


TOP 페이지는 가동시간(Uptime), 빌드 버전 등과 같은 큐레이터 마스터에 대한 상세 정보를 제공한다.

다음 섹션은 “큐레이터 노드(Curator Nodes)” 페이지로 클러스터에서 노드에 대한 상세 정보(역할, 헬스 상태 등)를 제공한다. 이것들은 큐레이터가 분산 프로세싱 및 태스크 위임 등을 위해 사용하는 노드들이다.

“큐레이터 노드(Curator Nodes” 테이블을 다음과 같다.

[그림 14-16] 2010 페이지 – 큐레이터 노드

다음 섹션은 “큐레이터 잡(Curator Jobs)” 페이지로 종료된 또는 현재 진행 중인 잡에 대한 정보를 제공한다.

2가지 유형의 잡(Job)이 있는데, 하나는 부분 스캔(Partial Scan)으로 매 60분 마다 수행되고, 다른 하나는 전체 스캔(Full Scan)으로 매 6시간 마다 수행된다.


[NOTE] 부분 스캔 및 전체 스캔 시작 시간은 사용률 및 다른 액티비티에 따라 가변적이다.


큐레이터 스캔 작업은 주기적인 스케줄에 의해 수행되지만, 특정 클러스터 이벤트에 이해 트리거 될 수도 있다.

잡 실행(Job Execution)을 위한 몇 가지 이유는 다음과 같다.

  • 주기적인 실행 (정상 상태)
  • 디스크 / 노드 / 블록 장애
  • ILM 불균형 (ILM Imbalance)
  • 디스크 / 티어 불균형 (Disk/Tier Imbalance)

“큐레이터 잡(Curator Jobs)” 테이블은 다음과 같다.

[그림 14-17] 2010 페이지 – 큐레이터 잡(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)과 관련된 유형(Type), 이유(Reason), 태스크(Task) 및 수행시간(Duration) 등을 포함한 상세 정보를 제공한다.

다음 섹션은 “백그라운드 태스크 통계(Background Task Stats)” 테이블로 태스크 유형(Types of Task), 작업량(Quantity Generated) 및 우선순위(Priority) 등과 같은 상세 정보를 제공한다.

다음 그림은 잡의 상세 정보를 보여준다.

[그림 14-18] 2010 페이지 – 큐레이터 잡(Jobs) – 상세 정보

“백그라운드 태스크 통계(Background Task Stats)” 테이블을 다음과 같다.

[그림 14-19] 2010 페이지 – 큐레이터 잡(Jobs) – 태스크(Tasks)

다음 섹션은 “맵리듀스 잡(MapReduce Jobs)” 테이블로 각 큐레이터 잡에 의해 시작된 실제 맵리듀스 잡에 대한 정보를 제공한다. 부분 스캔(Partial Scan)은 1개의 맵리듀스 잡을 가지고, 전체 스캔(Full Scan)은 4개의 맵리듀스 잡을 갖는다.

“맵리듀스 잡(MapReduce Jobs)” 테이블은 다음과 같다.

[그림 14-20] 2010 페이지 – 맵리듀스 잡(MapReduce Jobs)

“Job ID”를 클릭하면 맵리듀스 잡 상세 정보 페이지로 이동하는데, 태스크 상태(Task Status), 맵리듀스 잡에 대한 다양한 카운터 및 상세 정보를 제공한다.

다음 그림은 잡 카운터(Job Counters)의 일부 정보이다.

[그림 14-21] 2010 페이지 – 맵리듀스 잡(MapReduce Jobs) – 카운터(Counters)

메인 페이지에서 다음 섹션은 “Queued Curator Jobs” 및 “Last Successful Curator Scans” 섹션이다. 이들 테이블은 언제 주기적인 스캔 작업이 수행되는지, 그리고 최종적으로 성공한 스캔 작업에 대한 상세 정보를 제공한다.

“Queued Curator Jobs” 및 “Last Successful Curator Scans” 섹션에서 제공하는 정보는 다음 그림과 같다.

[그림 14-22] 2010 페이지 – Queued and Successful Scans


3.6.5.4 고급 CLI 정보 (Advanced CLI Information)

프리즘(Prism)은 일반적인 장애처리 및 성능 모니터링 이슈와 관련된 모든 필요한 정보를 제공하여야 한다. 그러나, 상기에서 언급된 백앤드 페이지 또는 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에 주의하여야 한다. “데이터 구조(Data Structure)” 섹션에서 언급한 바와 같이, 데이터 중복제거된 경우에, 데이터 중복제거에 의해 발생되는 잠재적인 프래그멘테이션을 상쇄하기 위해 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         |
+----------------------------------------------------------------------------------------------------------------------------------------+
...

IV. Book of AHV

4.1 아키텍처

4.1.1 노드 아키텍처 (Node Architecture)

아크로폴리스 하이퍼바이저(Acropolis Hypervisor) 배포에서, CVM(Controller VM)은 VM으로 동작하고, 디스크는 PCI pass-through를 사용하여 CVM으로 제공된다. 이것은 전체 PCI 컨트롤러(장착된 디스크 포함)가 하이퍼바이저를 바이패스(Bypass) 하여 직접적으로 CVM으로 전달(Pass-through) 되게 한다. 아크로폴리스 하이퍼바이저는 CentOS KVM을 기반으로 한다.


[그림 13-1] 아크로폴리스 하이퍼바이저 노드

아크로폴리스 하이퍼바이저는 CentOS KVM 기반으로 구현되었으며, KVM의 기본 기능을 확장하여 HA, 라이브 마이그레이션 등과 같은 기능을 포함한다.

아크로폴리스 하이퍼바이저는 Microsoft Server Virtualization Validation Program 인증을 받았으며, Microsoft OS 및 애플리케이션 구동과 관련된 인증을 획득하였다.

4.1.2 KVM 아키텍처 (KVM Architecture)

KVM은 다음과 같은 컴포넌트로 구성되어 있다.

  • KVM-kmod
    • KVM 커널 모듈
  • Libvirtd
    • API로서, KVM 및 QEMU 관리를 위한 관리 도구이자 대몬(Daemon)이다. 아크로폴리스와 KVM/QEMU간의 통신은 libvirtd를 통해 이루어진다.
  • Qemu-kvm
    • 모든 VM을 위한 유저 스페이스에서 동작하는 에뮬레이터(Emulator) 및 버츄얼라이저(Virtualizer)이다. 아크로폴리스 하이퍼바이저에서 이것은 하드웨어 지원 가상화(Hardware-assisted Virtualization)를 위해 사용되며, VM은 HVM으로 동작한다.

KVM 컴포넌트들간의 관계는 다음 그림과 같다.


[그림 13-2] KVM 컴포넌트들간의 관계

아크로폴리스와 KVM간의 통신은 Libvirtd를 통하여 이루어진다.


프로세서 세대 호환성 (Processor Generation Compatibility)

VM을 다른 프로세서 세대들간의 이동을 가능하게 하는 VMware의 EVC(Enhanced vMotion Capability)와 유사하게, 아크로폴리스 하이퍼바이저는 클러스터에서 가장 오래된 프로세서 세대를 결정하고, 모든 MENU 도메인을 해당 레벨로 제약한다. 이것은 AHV 클러스터에서 프로세서 세대들의 혼합을 가능하게 하고, 호스트들간의 마이그레이션을 보장한다.

4.1.3 설정 최대값 및 확장성 (Configuration maximums and scalability)

설정 최대값 및 확장성 제약은 다음과 같다.

  • 최대 클러스터 사이즈: N/A – 뉴타닉스 클러스터 사이즈와 동일
  • VM 당 최대 vCPU 개수: 호스트 당 물리 코어의 개수
  • VM 당 최대 메모리: VM 당 최대 메모리: MIN (4TB, 노드의 가용한 물리 메모리 용량)
  • 최대 가상 디스크 사이즈: 9EB (Exabyte)
  • 호스트 당 최대 VM의 개수: N/A – 메모리에 의해 제약됨
  • 클러스터 당 최대 VM의 개수: N/A – 메모리에 의해 제약됨

AHV는 ESXi 및 Hyper-V와 같이 전통적인 스토리지 스택을 갖지 않는다. 즉, 모든 디스크는 SCSI 블록 디바이스로서 VM으로 패스된다. 이것은 최대 가상 디스크 사이즈가 DSF vDisk 사이즈(9 Exabytes)에 의한 제한된다는 것을 의미한다.

4.1.4 네트워킹 (Networking)

아크로폴리스 하이퍼바이저는 모든 VM 네트워킹을 위해 OVS(Open vSwitch)를 사용한다. VM 네트워킹은 프리즘/aCLI를 통하여 설정되고, 각 VM NIC은 TAP 인터페이스로 연결된다.

OVS 아키텍처의 개념적 다이어그램은 다음과 같다.


[그림 13-3] Open vSwitch 네트워크 개요

4.1.4.1 VM NIC 유형

AHV는 다음과 같은 VM 네트워크 인터페이스 유형을 지원한다.

  • Access (디폴트)
  • Trunk (NOS 4.6 이상)

디폴트로 VM NIC은 Access 인터페이스로 생성되지만, VM의 OS에게 Trunk 인터페이스로 변경하는 것이 가능하다.

Trunk 인터페이스는 다음의 명령어로 추가할 수 있다.

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


4.2 동작 방식 (How it works)

4.2.1 스토리지 I/O 경로 (Storage I/O Path)

AHV는 ESXi 또는 Hyper-V와 같이 전통적인 스토리지 스택을 사용하지 않는다. 모든 디스크는 raw SCSI 블록 디바이스로서 VM에 패스함으로써 I/O 경로를 경량화된 최적의 상태로 유지한다.

[NOTE] 아크로폴리스는 최종 사용자로부터 KVM, VIRSH, QEMU, LIBBIRT, iSCSI를 추상화하고, 모든 백엔드 설정을 처리한다. 이렇게 함으로써 사용자가 보다 높은 수준의 작업(프리즘 또는 ACLI를 통하여 VM 관리 등)에 집중할 수 있도록 한다. 다음에 제공되는 기능은 단지 정보 제공 목적이므로, VIRSH, LBVIRT 등과 같은 명령어를 직접 사용할 것을 권고하는 것은 아니다.

각 AHV 호스는 iSCSI redirector 대몬(Daemon)을 가지는데, NOP OUT 명령어를 이용하여 클러스터 전체의 Stargate 헬스 상태를 모니터링 한다. 다음에서 iscsi_redirector가 127.0.0.1:3261에서 listening 하고 있는 것을 확인할 수 있다.

Proto ... Local Address   Foreign Address   State     PID/Program name
...
tcp   ... 127.0.0.1:3261  0.0.0.0:*         LISTEN    8044/python
...

QEMU는 iSCSI target portal로 동작하는 iSCSI redirector를 갖도록 설정된다. 로그인 요청 시에, 리다이렉터가 수행되어, iSCSI 로그인 요청은 정상 동작 중인 스타게이트로 리다이렉트 된다 (로컬 스타게이트가 우선순위를 가짐).


[그림 13-4] iSCSI Multi-pathing – 정상 상태


다음에서 qemu-kvm이 정상 동작중인 Stargate와 세션을 맺은 것을 확인할 수 있다. [NOTE] 디스크 디바이스 별로 1개의 세션이 존재한다 (PID 24845 참조)

[root@NTNX-BEAST-1 log]# netstat -np | egrep tcp.*qemu
Proto ... Local Address       Foreign Address     State       PID/Program name
tcp   ... 10.3.140.101:50410  10.3.140.151:3261   ESTABLISHED 25293/qemu-kvm
tcp   ... 10.3.140.101:50434  10.3.140.151:3261   ESTABLISHED 23198/qemu-kvm
tcp   ... 10.3.140.101:50464  10.3.140.151:3261   ESTABLISHED 24845/qemu-kvm
tcp   ... 10.3.140.101:50465  10.3.140.151:3261   ESTABLISHED 24845/qemu-kvm
...

도메인 XML 파일에서 설정 정보를 확인할 수 있다.

<devices>
<emulator>/usr/libexec/qemu-kvm</emulator>
...
<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>

우선되는 Controller 타입은 virtio-scsi (SCSI 디바이스의 디폴트 타입)이다. IDE 디바이스(사용 가능할지라도)를 사용하는 것은 대부분의 시나리오에서 권고하지 않는다. virtio가 Windows와 같이 사용되기 위해서는 virto 드라이버, Nutanix mobility 드라이버, 또는 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>
...

Active 스타게이트가 다운(Down) 되면(NOP OUT 명령어에 대한 응답이 실패하면), iSCSI redirector는 로컬 스타게이트를 “건강불량(Unhealthy)”으로 표시한다. QEMU가 iSCSI 로그인을 재시도할 때, redirector는 로그인을 정상 동작 중인 다른 스타게이트로 리다이렉트 한다.

[그림 13-5] iSCSI Multi-pathing – 로컬 CVM 다운(Down)


일단, 로컬 스타게이트가 정상 상태로 백업되면 (NOP OUT 명령어에 대한 응답을 시작하면), iSCSI redirector는 리모트 스타게이트와의 모든 연결을 끊기 위하여 TCP kill을 수행한다. 그리고 나서, QEMU는 iSCSI 로그인을 다시 시도하고, 로컬 스타게이트로 리다이렉트 된다.

[그림 13-6] iSCSI Multi-pathing – 로컬 CVM 백업


4.2.2 IP 주소 관리 (IP Address Management)

아크로폴리스 IP 주소 관리(IP Address Management: IPAM) 솔루션은 DHCP 범위를 설정하고, VM에 IP를 할당할 수 있는 기능을 제공한다. IPAM은 DHCP 요청과 DHCP 응답을 인터셉트 하기 위하여 VXLAN과 OpenFlow 룰(Rule)을 사용한다.

아크로폴리스 마스터가 로컬로 동작 중인 노드에서 뉴타닉스 IPAM 솔루션을 이용한 DHCP 요청은 다음 그림과 같이 처리된다.


[그림 13-7] IPAM – 로컬 아크로폴리스 마스터

만약 아크로폴리스 마스터가 리모트에서 동작 중인 경우에는, 동일한 VXLAN이 네트워크에서 요청을 처리하기 위해 사용된다.


[그림 13-8] IPAM – 리모트 아크로폴리스 마스터

관리되지 않는 네트워크(Unmanaged Network) 시나리오에서는 전통적인 DHCP / IPAM 솔루션을 사용할 수 있다.


4.2.3 VM HA (VM High Availability)

아크로폴리스 하이퍼바이저 VM HA는 호스트 또는 블록 장애 시에 VM 가용성을 보장하기 위해 구현된 기능이다. 호스트 장애 시에, 특정 호스트에서 동작 중이던 VM은 클러스터에서 정상 동작 중인 다른 노드에서 재기동 된다. 아크로폴리스 마스터는 정상 동작 중인 호스트에서 VM의 재기동에 대한 책임을 갖는다.

아크로폴리스 마스터는 모든 클러스터 호스트에서 libvirt 연결을 모니터링 함으로써 호스트의 헬스를 추적한다.


[그림 13-9] VM HA – 모니터링

아크로폴리스 마스터가 가용하지 않은 경우(파티션(Partitioned), 고립(Isolated), 장애(Failed))에, 새로운 아크로폴리스 마스터가 클러스터에서 정상 동작 중인 노드로 선정된다. 만약, 클러스터가 파티션 되면(예를 들어, X 노드가 다른 Y 노드와 통신이 되지 않으면), 정족수(Quorum)을 갖는 부분은 상태를 유지하게 되고, VM은 해당 호스트에서 재기동 된다.


디폴트 VM 재기동 정책 (Default VM restart policy)

호스트 장애 시에, 모든 AHV 클러스터는 디폴트로 VM을 재기동하기 위해 “Best Effort” 기반으로 동작한다. “Best Effort” 모드에서, 호스트가 가용하지 않게 되었을 때, 이전에 동작 중인 VM은 남아 있는 정상 동작 중인 호스트에서 제기동 된다. 이것은 Best Effort (남아 있는 자원을 예약하지 않음) 모드이기 때문에, VM의 재기동 여부는 가용한 AHV 지원에 의존한다.


HA를 위한 자원 예약은 다음과 같은 2가지 유형을 지원한다.

  • 호스트 예약 (Reserve Hosts)
    • X개의 호스트를 예약한다. X는 장애 허용 호스트 수로 1, 2 등과 같이 호스트 수이다.
    • 이것은 호스트가 동일한 용량의 RAM을 갖는 경우에 디폴트 모드이다.
  • 세그먼트 예약 (Reserve Segments)
    • 클러스터에서 N개의 호스트에 Y 자원을 예약한다. 이것은 클러스터 FT 레벨의 기능으로, 클러스터에 동작 중인 VM의 수와 노드의 수를 기반으로 자원을 예약한다.
    • 이것은 일부 호스트의 RAM 용량이 다른 경우에 디폴트 모드이다.

PRO TIP

다음과 같은 경우에 호스트 예약을 사용한다.

  • 동일한 노드로 클러스터를 구성한 경우(모든 호스트의 RAM 용량이 동일)
  • 콘솔리데이션(Consolidation) 비율이 성능 보다 중요한 경우

다음과 같은 경우에 세그먼트 예약을 사용한다.

  • 노드를 혼합하여 클러스터를 구성한 경우 (호스트의 RAM 용량이 동일하지 않음)
  • 성능이 콘솔리데이션 비율 보다 중요한 경우

4.2.3.1 호스트 예약 (Reserve Hosts)

디폴트로, 장애 허용 개수가 클러스터 FT 레벨과 동일하다 (예를 들어, FT1인 경우 1, FT2인 경우 2). 디폴트 값은 aCLI 명령어로 변경할 수 있다.


PRO TIP

다음 aCLI 명령어를 사용하여 예약된 페일오버 호스트 수를 설정할 수 있다.

acli ha.update num_reserved_hosts=<NUM_RESERVED>


호스트 예약 시나리오는 다음 그림과 같다.


[그림 13-10] HA – 호스트 예약


호스트 장애 시에, VM은 예약된 호스트에서 재기동 한다.


[그림 13-11] HA – 호스트 예약 – 페일오버


만약 장애 발생한 호스트가 정상 동작 상태로 복귀되면, VM은 데이터 로컬리티를 위한 데이터 이동을 최소화하기 위해 오리지널 호스트로 다시 라이브 마이그레이션 된다.


[그림 13-12] HA – 호스트 예약 – 페일 백(Fail Back)


4.2.3.2 세그먼트 예약 (Reserve Segments)

세그먼트 예약은 자원 예약을 클러스터의 모든 호스트로 분산시킨다. 이러한 시나리오에서, 각 호스트는 HA를 위해 일정 부분의 자원을 예약한다. 이것을 보장하기 위해서는 전체 클러스터가 호스트 장애 시에 VM의 재기동을 위한 충분한 페일오버 용량을 가져야 한다.


PRO TIP

세그먼트 기반의 예약을 사용할 때, 호스트 밸런싱을 유지해야 한다. 이것은 높은 사용률을 제공해 주며, 너무 많은 세그먼트가 예약되지 않는다는 것을 보장한다.


세그먼트 예약 시나리오는 다음과 같다.


[그림 13-13] HA – 세그먼트 예약


호스트 장애 시에, VM은 클러스터의 남아있는 정상 동작 중인 호스트에서 재기동 된다.


[그림 13-14] HA – 세그먼트 예약 - 페일오버


세그먼트 예약 계산 (Reserved segments calculation)

시스템이 자동으로 세그먼트 예약 전체 수 및 호스트 당 예약을 계산한다. 어떤 방식으로 용량 계산을 수행하는지에 대한 이해를 돕기 위해, 상세한 계산 방법을 설명한다.

아크로폴리스 HA는 호스트 장애 시에 VM을 성공적으로 재기동 할 수 있도록 충분한 용량을 예약하기 위해 고정된 사이즈의 세그먼트를 사용한다. 아크로폴리스 HA의 고유한 기능 중의 하나는 복수의 작은 VM을 1개의 고정된 사이즈의 세그먼트에 패킹(Packing) 할 수 있다는 것이다. 다양한 사이즈의 VM을 갖는 클러스터에서, 1개의 세그먼트가 복수의 VM을 수용할 수 있으므로, 고정된 사이즈의 세그먼트 스킴에 따른 단편화를 줄일 수 있다.

VM을 위한 가장 최적의 위치는(최소의 세그먼트 예약 수를 갖는), 컴퓨터 사이언스의 문제로 알려진, Bin-Packing 문제로 정의된다. 최적의 솔루션은 NP-hard (지수 문제) 이나, 일반적인 경우에 최적의 솔루션에 근접한 휴리스틱 솔루션을 사용할 수 있다. 뉴타닉스는 위치 알고리즘을 지속적으로 향상시키고 있다. 뉴타닉스는 최신 버전에서 일반적인 경우에 0.35 엑스트라 오버헤드를 갖기를 기대한다. 현재, 단편화 문제는 0.5 ~ 1 사이에서 가변적인데, 이것은 설정된 호스트 장애 당 1.5 ~ 2의 전체 오버헤드가 있다는 것을 의미한다.

세그먼트 예약을 사용할 때, 다음과 같은 몇 가지의 컨스트럭트가 있다.

  • 세그먼트 사이즈 = 동작 중인 VM의 최대 메모리(GB)
  • 가장 부하가 많은 호스트 = 가장 많은 용량을 갖는 VM을 갖는 호스트
  • 단편화 오버헤드 = 0.5 ~ 1

상기 정보를 기반으로, 기대 예약 세그먼트의 수를 계산할 수 있다.

  • 예약 세그먼트 = (가장 부하가 많은 호스트 / 세그먼트 사이즈) X (1 – 단편화 오버헤드)

4.3 관리 (Administration)

내용 추가 예정입니다.

4.3.1 중요 페이지 (Important Pages)

내용 추가 예정입니다.

4.3.2 명령어 참조 (Command Reference)

OVS에서만 10GbE 링크 활성화 (Enable 10GbE links only on OVS)

설명: 로컬 호스트에서 단지 bon0만을 대상으로 10g 활성화

manage_ovs --interfaces 10g update_uplinks

설명: 전체 클러스터의 OVS 업링크 출력

allssh "manage_ovs --interfaces 10g update_uplinks"

OVS 업링크 출력 (Show OVS uplinks)

설명: 로컬 호스트의 OVS 인터페이스 출력

manage_ovs show_interfaces

설명: 전체 클러스터의 인터페이스 출력

allssh "manage_ovs show_interfaces"

OVS 스위치 정보 출력 (Show OVS switch information)

설명: 스위치 정보 출력

ovs-vsctl show

OVS 브리지 목록 출력 (List OVS bridges)

설명: 브리지 정보 출력

ovs-vsctl list br

OVS 브리지 정보 출력 (Show OVS bridge information)

설명: OVS 포트 정보 출력

ovs-vsctl list port br0
ovs-vsctl list port <bond>

OVS 인터페이스 정보 출력 (Show OVS interface information)

설명: 인터페이스 정보 출력

ovs-vsctl list interface br0

브리지에서 포트/인터페이스 정보 출력

설명: 브리지에서 포트 정보 출력

ovs-vsctl list-ports br0

설명: 브리지에서 인터페이스 정보 출력

ovs-vsctl list-ifaces br0

OVS 브리지 생성 (Create OVS bridge)

설명: 브리지 생성

ovs-vsctl add-br <bridge>

브리지에 포트 추가 (Add ports to bridge)

설명: 브리지에 포트 추가

ovs-vsctl add-port <bridge> <port>

설명: 브리지에 bond 포트 추가

ovs-vsctl add-bond <bridge> <port> <iface>

OVS bond 상세 정보 출력

설명: bond 상세 정보 출력

ovs-appctl bond/show <bond>

예제:

ovs-appctl bond/show bond0

bond 모드 및 bond에 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

bond에서 LACP 상세 정보 출력

설명: LACP 상세 정보 출력

ovs-appctl lacp/show <bond>

bond 모드 설정

설명: 포트에 bond 모드 설정

ovs-vsctl set port <bond> bond_mode=<active-backup, balance-slb, balance-tcp>

OpenFlow 정보 출력

설명: OVS OpenFlow 상세 정보 출력

ovs-ofctl show br0

설명: OpenFlow Rule 정보 출력

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


4.3.3 메트릭스 및 임계 값 (Metrics and Thresholds)

내용 추가 예정입니다.


4.3.4 장애 처리 및 고급 관리

iSCSI Redirector 로그 체크 (Checks iSCSI Redirector Logs)

설명: 모든 호스트의 iSCSI Redirector 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


Part V. Book of vSphere

5.1 아키텍처 (Architecture)

5.1.1 노드 아키텍처 (Node Architecture)

ESXi 배포에서, CVM은 VM으로 동작하고, 디스크는 VMDirectPath I/O를 사용하여 제공된다. 이것은 Full PCI Controller (and attached devices)를 가능하게 하여 하이퍼바이저를 바이패스(Bypass)하여 직접적으로 CVM으로 Pass-Through 된다.


[그림 15-1] ESXi 노드 아키텍처

5.1.2 설정 최대값 및 확장성

설정 최대값 및 확장성 제약은 다음과 같다.

  • 최대 클러스터 사이즈: 64
  • VM 당 최대 vCPU: 128
  • VM 당 최대 메모리: 4TB
  • 최대 가상 디스크 사이즈: 62TB
  • 호스트 당 최대 VM 개수: 1024
  • 클러스터 당 최대 VM 개수: 8000 (만약 HA가 활성화되면, 데이터스토어 당 2048)

[NOTE] vSphere 6.0 기준

5.1.3 네트워킹 (Networking)

모든 ESXi 호스트는 로컬 vSwitch를 가지며, 뉴타닉스 CVM과 호스트간의 내부 호스트 통신(Intra-Host Communication)을 위해 사용된다. 외부 통신 및 VM을 위해 표준 vSwitch(default) 또는 dvSwitch를 사용한다.

로컬 vSwitch(vSwitchNutanix)는 뉴타닉스 CVM과 ESXi 호스트간의 통신을 위한 것이다. 호스트는 vSwitchNutanix 상에서 VMkernel 인터페이스(vmk1 – 192.168.5.1)를 가지고, CVM은 vSwitchNutanix 상의 포트 그룹(svm-iscsi-pg – 192.168.5.2)을 갖는다. 이것이 프라이머리 스토리지 통신 경로이다.

외부 vSwitch는 표준 vSwitch 또는 dvSwitch 일 수 있다. 외부 vSwitch는 ESXi 호스트 및 CVM을 위한 외부 인터페이스(External Interface) 뿐만 아니라 호스트에서 VM에 의해 사용되는 포트그룹을 제공한다. 외부 VMKernel 인터페이스는 호스트 관리, vMotion 등의 용도로 사용된다. 외부 CVM 인터페이스는 다른 뉴타닉스 CVM과의 통신을 위해 사용된다. 많은 포트그룹을 생성해야 할 경우에는 트렁크(Trunk)에서 VLAN이 활성화되어 있는지를 확인하여야 한다.

vSwitch 아키텍처의 개념적 다이어그램은 다음과 같다.


[그림 15-2] ESXi vSwitch 네트워크 개요


업링크 및 티밍 정책 (Uplink and Teaming Policy)

스위치 HA를 위해 2개의 스위치에 듀얼 ToR 스위치 및 업링크를 갖도록 구성하기를 권고한다. 디폴트로, 시스템은 Active/Passive 모드를 갖는 업링크 인터페이스를 갖는다. 추가적인 네트워크 대역폭을 위해 Active/Active 업링크 인터페이스 기능을 제공하는 업스트림 스위치(e.g. vPC, MLAG, etc.)를 사용할 수 있다.


5.2 동작방식(How It Works)

5.2.1 Array Offloads – VAAI

뉴타닉스 플랫폼은 VAAI(VMware APIs for Array Integration)을 지원하는데, 이것은 하이퍼바이저가 어레이에 대한 특정 작업의 오프로드(Offloads)를 가능하게 한다. 이것은 하이퍼바이저가 중간자 역할(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/를 방문하면, 다양한 프리미티브에 대한 설명을 참조할 수 있다.

전체 파일 클론(Full File Clone) 및 빠른 파일 클론(Fast File Clone)의 경우에, DSF의 “Fast Clone”이 수행되는데, 이것은 생성된 각 클론이 ROW(Redirect on Write)를 사용한 쓰기 가능한 스냅샷(Write Snapshots)이라는 것을 의미한다. 모든 클론은 자신의 블록 맵(Block Map)을 가지는데, 이것은 체인의 깊이(Chain Depth)를 걱정할 필요가 없다는 것을 의미한다. 시나리오에 대한 VAAI의 적용 여부는 다음과 같다.

  • Clone VM with Snapshot –> VAAI will NOT be used
  • Clone VM without Snapshot which is Powered Off –> VAAI WILL be used
  • Clone VM to a different Datastore/Container –> VAAI will NOT be used
  • Clone VM which is Powered On –> VAAI will NOT be used

VMware View인 경우에 적용되는 시나리오는 다음과 같다.

  • View Full Clone (Template with Snapshot) –> VAAI will NOT be used
  • View Full Clone (Template w/o Snapshot) –> VAAI WILL be used
  • View Linked Clone (VCAI) –> VAAI WILL be used

VAAI 오퍼레이션이 수행되었는지의 여부의 “NFS Adaptor” Activity Traces 페이지에서 확인할 수 있다.

5.2.2 CVM 자동절체 (CVM Autopathing aka Ha.py)

본 섹션에서, CVM 장애처리 로직을 설명한다. CVM 장애는 유저가 CVM의 전원을 다운한 경우, CVM 롤링 업그레이드(CVM Rolling Upgrade), 또는 CVM을 다운(Down)시킬 수 있는 모든 경우를 포함한다. DSF는 Autopathing 기능을 지원하는데, 이것은 로컬 CVM이 가용하지 않은 상태가 되었을 때, I/O가 클러스터의 다른 CVM에 의해 투명하게 처리되게 하는 기능이다. 하이퍼바이저와 CVM은 전용 vSwitch를 통하여 사설 192.168.5.x 네트워크를 사용하여 통신한다. 이것은 모든 스토리지 I/O가 CVM의 내부 사설 IP(192.168.5.2)를 통해 수행된다는 것을 의미한다. CVM의 외부 IP는 CVM간의 통신 및 리모트 복제를 위해 사용된다.

ESXi 호스트의 네트워킹은 다음 그림과 같다.

[그림 16-1] ESXi 호스트 네트워킹

로컬 CVM에 장애가 발생하면, 로컬 CVM에 의해 호스트된 로컬 192.168.5.2 주소는 가용하지 않게 된다. DSF는 자동으로 이러한 장애를 검출하고, 10GbE를 통해 I/O를 클러스터의 다른 CVM으로 리다이렉트 한다. Re-routing은 호스트에서 동작 중인 하이퍼바이저 및 VM과 무관하게 수행된다. 이것은 CVM의 전원이 다운되었다 하더라도 VM은 DSF에서 I/O를 지속할 수 있다는 것을 의미한다. 일단 로컬 CVM이 백업되고 가용한 상태가 되면, 트래픽은 다시 완벽하게 로컬 CVM으로 전달되어 서비스된다.

CVM 자동절체(CVM Autopathing) 기능은 다음 그림과 같다.

[그림 16-2] ESXi 호스트 네트워킹 – 로컬 CVM 다운(Down)


5.3 관리 (Administration)

5.3.1 중요 페이지 (Important Pages)

내용 추가 예정입니다.

5.3.2 명령어 참조 (Command Reference)

ESXi 클러스터 업그레이드 (ESXi Cluster Upgrade)

설명: CLI를 이용하여 ESXi 호스트의 자동 업그레이드 수행

# Upload upgrade offline bundle to a Nutanix NFS container

# Log in to Nutanix CVM

# Perform upgrade

for i in `hostips`;do echo $i && ssh root@$i "esxcli software vib install -d /vmfs/volumes/<Datastore Name>/<Offline bundle name>";done

# 예제

for i in `hostips`;do echo $i && ssh root@$i "esxcli software vib install -d /vmfs/volumes/NTNX-upgrade/update-from-esxi5.1-5.1_update01.zip";done

ESXi 호스트의 순차적인 리부팅 작업 수행한다.

ESXi 호스트 서비스 재시작 (Restart ESXi host services)

설명: 점진적인 방법으로 각 ESXi 호스트 서비스를 재시작

for i in `hostips`;do ssh root@$i "services.sh restart";done

ESXi 호스트 NIC이 “Up” 상태인 목록 출력 (Display ESXi host NICs in “Up” state)

설명: ESXi 호스트 NIC이 “Up” 상태인 목록 출력

for i in `hostips`;do echo $i && ssh root@$i esxcfg-nics -l | grep Up;done

ESXi 호스트 10GbE NIC 및 상태 출력(Display ESXi 10GbE NICs and status)

설명: ESXi 호스트의 10GbE NIC과 상태 정보 출력

for i in `hostips`;do echo $i && ssh root@$i esxcfg-nics -l | grep ixgbe;done

ESXi 호스트 액티브 어댑터 출력 (Display ESXi host active adapters)

설명: ESXi 호스트의 액티브, 스탠바이, 사용되지 않는 어댑터 정보 출력

for i in `hostips`;do echo $i &&  ssh root@$i "esxcli network vswitch standard policy failover get --vswitch-name vSwitch0";done

ESXi 호스트 라우팅 테이블 출력 (Display ESXi host routing tables)

설명: ESXi 호스트의 라우팅 테이블 출력

for i in `hostips`;do ssh root@$i 'esxcfg-route -l';done

데이터스토어에서 VAAI의 활성화 여부 체크 (Check if VAAI is enabled on datastore)

설명: 데이터스토어에서 VAAI의 활성화/지원 여부 체크

mkfstools -Ph /vmfs/volumes/<Datastore Name>

VIB 승인 레벨을 “Community Supported”로 설정 (Set VIB acceptance level to community supported)

설명: VIB 승인 레벨을 “Community Supported”로 설정

esxcli software acceptance set --level CommunitySupported

VIB 설치 (Install 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 용량 체크 (Check ESXi ramdisk space)

설명: ESXi RAMDISK의 Free Space 체크

for i in `hostips`;do echo $i; ssh root@$i 'vdf -h';done

pynfs 로그 삭제 (Clear pynfs)

설명: 모든 ESXi 호스트에서 pynfs 로그 삭제

for i in `hostips`;do echo $i; ssh root@$i '> /pynfs/pynfs.log';done


5.3.3 메트릭스 및 임계 값

내용 추가 예정입니다.

5.3.4 장애 처리 및 고급 관리

내용 추가 예정입니다.


Part VI. Book of Hyper-V

6.1 아키텍처 (Architecture)

6.1.1 노드 아키텍처 (Node Architecture)

Hyper-V 배포에서, CVM은 VM으로 동작하고, 디스크는 Disk Pass-through를 사용하여 제공된다.


[그림 18-1] Hyper-V 노드 아키텍처


6.1.2 설정 최대값 및 확장성

설정 최대값 및 확장성 제약은 다음과 같다.

  • 최대 클러스터 사이즈: 64
  • VM 당 최대 vCPU: 64
  • VM 당 최대 메모리: 1TB
  • 최대 가상 디스크 사이즈: 62TB
  • 호스트 당 최대 VM 개수: 1024
  • 클러스터 당 최대 VM 개수: 8000

[NOTE] Hyper-V 2012 R2 기준

5.1.3 네트워킹 (Networking)

모든 Hyper-V 호스트는 내부 전용의 가상 스위치(Virtual Switch)를 가지는데, 뉴타닉스 CVM과 호스트간의 내부 호스트 통신(Intra-Host Communication)을 위해 사용된다. 외부 통신 및 VM을 위해 외부 가상 스위치(External Virtual Switch: Default) 또는 논리적 스위치(Logical Switch)가 사용된다.

내부 스위치(InternalSwitch)는 뉴타닉스 CVM과 Hyper-V 호스트간의 로컬 통신을 위한 것이다. 호스트는 InternalSwitch에서 가상 이더넷 인터페이스(vEth:192.168.5.1)를 가지고, CVM도 InternalSwitch에서 vEth(192.168.5.2)를 가진다. 이것이 프라이머리 스토리지 통신 경로이다.

외부 vSwitch는 표준 가상 스위치 또는 논리적 스위치가 될 수 있다. 외부 vSwitch는 Hyper-V 호스트, CVM을 위한 외부 인터페이스일 뿐만 아니라 해당 호스트에서 동작 중인 VM에 의해 사용되는 논리적 및 VM 네트워크이다. 외부 vEth 인터페이스는 호스트 관리, 라이브 마이그레이션 등을 위해 사용된다. 외부 CVM 인터페이스는 다른 뉴타닉스 CVM과의 통신을 위해 사용된다. 많은 포트그룹을 생성해야 할 경우에는 트렁크(Trunk)에서 VLAN이 활성화되어 있는지를 확인하여야 한다.

가상 스위치(Virtual Switch) 아키텍처의 개념적 다이어그램은 다음과 같다.

[그림 18-2] Hyper-V 가상 스위치 네트워크 개요


업링크 및 티밍 정책 (Uplink and Teaming Policy)

스위치 HA를 위해 2개의 스위치에 듀얼 ToR 스위치 및 업링크를 갖도록 구성하기를 권고한다. 디폴트로, 시스템은 스위치에서 LBFO team을 갖는데, 이것은 어떤 종류의 특별한 설정을 요구하지 않는다.


6.2 동작방식(How It Works)

6.2.1 Array Offloads – ODX

뉴타닉스 플랫폼은 Microsoft ODX (Offloaded Data Transfer)를 지원하는데, 이것은 하이퍼바이저가 어레이에 대한 특정 작업의 오프로드(Offloads)를 가능하게 한다. 이것은 하이퍼바이저가 중간자(man in the middle) 역할을 수행할 필요가 없기 때문에 매우 효율적이다. 현재 뉴타닉스는 SMB에 대한 ODX 프리미티브를 지원하는데, 이것은 전체 복사(Full Copy) 및 제로잉 오퍼레이션(Zeroing Operation)을 포함한다. 그러나, 쓰기 가능한 스냅샷(Writable Snapshots)을 이용한 “빠른 파일 클론(Fast File Clone)” 오퍼레이션을 갖는 VAAI와 달리, ODX 프리미티브는 전체 복사(Full Copy)를 수행한다. 이러한 이유로, nCLI, REST API 또는 PowerShell CMDlets에 의해 수행할 수 있는 DSF 클론을 사용하는 것이 보다 효율적이다. 현재 ODX는 다음과 같은 오퍼레이션에 적용된다.

  • In VM or VM to VM file copy on DSF SMB share
  • SMB share file copy

SCVMM 라이브러리(DSF SMB share)로부터 템플릿을 배포한다.


[NOTE] 공유(Shares)는 짧은 이름(e.g. not FQDN)을 사용하여 SCVMM 클러스터에 추가되어야 한다. 이러한 작업을 수행하기 위한 가장 쉬운 방법은 엔트리를 클러스터의 호스트 파일에 추가하는 것이다 (e.g. 10.10.10.10 nutanix-130).


ODX는 다음과 같은 오퍼레이션에 적용되지 않는다.

  • Clone VM through SCVMM
  • Deploy template from SCVMM Library (non-DSF SMB Share)
  • XenDesktop Clone Deployment

ODX 오퍼레이션의 수행 여부는 “NFS Adaptor” Activity Traces 페이지에서 확인할 수 있다. 오퍼레이션 액티비티는, vDisk를 복제할 때는 “NfsSlaveVaaiCopyDataOp”이고, 디스크를 제로잉(Zeroing Out) 할 때는 “NfsSlaveVaaiWriteZerosOp”이다.


6.3 관리 (Administration)

6.3.1 중요 페이지 (Important Pages)

내용 추가 예정입니다.

6.3.2 명령어 참조 (Command Reference)

복수의 리모트 호스트에서 명령어 실행 (Execute command on multiple remote hosts)

설명: 하나 또는 여러 개의 리모트 호스트에서 PowerShell 실행

$targetServers = "Host1","Host2","Etc"
Invoke-Command -ComputerName  $targetServers {
         <COMMAND or SCRIPT BLOCK>

가용한 VMQ 오프로드 체크 (Check available VMQ Offloads)

설명: 특정 호스트에서 가용한 VMQ 오프로드 개수를 출력

gwmi –Namespace "root\virtualization\v2" –Class Msvm_VirtualEthernetSwitch | select elementname, MaxVMQOffloads

지정한 접두사와 매칭되는 VM의 VMQ 비활성화 (Disable VMQ for VMs matching a specific prefix)

설명: 특정 VM에 대한 VMQ 비활성화

$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix} | Get-VMNetworkAdapter | Set-VMNetworkAdapter -VmqWeight 0

지정한 접두사와 매칭되는 VM의 VMQ 활성화 (Enable VMQ for VMs matching a specific prefix)

설명: 특정 VM의 VMQ 활성화

$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix} | Get-VMNetworkAdapter | Set-VMNetworkAdapter -VmqWeight 1

지정한 접두사와 매칭되는 VM의 전원 인가 (Power-On VMs matching a certain prefix)

설명: 지정한 접두사와 매칭되는 VM의 전원 인가

$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix -and $_.StatusString -eq "Stopped"} | Start-VM

지정한 접두사와 매칭되는 VM을 Shutdown (Shutdown VMs matching a certain prefix)

설명: 지정한 접두사와 매칭되는 VM을 Shutdown

$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix -and $_.StatusString -eq "Running"}} | Shutdown-VM -RunAsynchronously

지정한 접두사와 매칭되는 VM을 Stop (Stop VMs matching a certain prefix)

설명: 지정한 접두사와 매칭되는 VM을 Stop

$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix} | Stop-VM

Hyper-V 호스트의 RSS 설정 정보 가져오기 (Get Hyper-V host RSS settings)

설명: Hyper-V 호스트의 RSS 설정 정보 가져오기

Get-NetAdapterRss

Winsh 및 WinRM 연결 체크 (Check Winsh and WinRM connectivity)

설명: Winsh 및 WinRM 연결/상태 체크

allssh "winsh "get-wmiobject win32_computersystem"


6.3.3 메트릭스 및 임계 값

내용 추가 예정입니다.

6.3.4 장애 처리 및 고급 관리

내용 추가 예정입니다.


Part VII. Book of XenServer

내용 추가 예정입니다.


Part VIII. Book of Foundation

8.1 아키텍처 (Architecture)

Foundation은 뉴타닉스가 제공하는 툴로서, 뉴타닉스 클러스터의 부트스트래핑(Bootstraping), 이미징(Imaging), 배포(Deployment)를 위해 사용된다. 이미징 프로세스 동안에 지정된 AOS 및 하이퍼바이저를 설치한다.

공장 출하 시에, 모든 뉴타닉스 노드에는 AHV가 사전에 설치되어 있으므로, 다른 하이퍼바이저를 사용하기 위해서는 Foundation을 이용하여 노드를 재이미징(Re-Imaging) 하여야 한다.

[NOTE] 일부 OEM 제품은 공장 출하 시에 요구된 하이퍼바이저가 설치되어 있다.

Foundation 아키텍처는 다음 그림과 같다.

[그림] Foundation – 아키텍처


AOS 4.5 버전에서부터, 설정의 편의성을 위해 Foundation이 CVM에 포함되었다. Installer Store는 업로드 된 이미지를 저장하기 위한 디렉토리로, 초기 이미징 및 클러스터 확장 시에 사용된다.

Foundation Discovery Applet은 노드 검색, 사용자가 연결할 노드의 선택 기능을 제공한다. 사용자가 접속할 노드를 선택하면, Applet은 localhost:9442 IPv4를 포트 8000의 CVM IPv6 링크 로컬 주소에 프록시 한다.

Applet 아키텍처는 다음 그림과 같다.

[그림] Foundation – Applet 아키텍처

[NOTE] Discovery Applet은 단지 검색 및 노드에서 구동 중인 Foundation 서비스를 프록시 하는 역할을 수행한다. 모든 이미징 및 설정 작업은 Applet이 아닌 Foundation 서비스에 의해 처리된다.


PRO TIP

타깃 뉴타닉스 노드가 다른 네트워크에 위치하는 경우에 (사용자가 뉴타닉스 노드와 다른 네트워크에 연결되어 있는 경우에), 만약 CVM의 IPv4 주소가 할당되어 있다면 CVM의 Foundation 서비스에 직접 연결할 수 있다 (Discovery Applet를 사용하는 대신에).

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


8.1.1 입력 (Inputs)

Foundation 툴은 다음과 같은 입력 값을 필요로 한다. 일반적인 경우에 노드 당 3개의 고정 IP가 필요하다 (하이퍼바이저, CVM, 원격 관리 (e.g. IPMI, iDRAC, etc)). 추가적으로 클러스터 및 데이터 서비스 IP 주소가 필요하다.

  • 클러스터 (Cluster)
    • 이름 (Name)
    • IP*
    • NTP*
    • DNS*
  • CVM
    • CVM 당 IP
    • 넷마스크 (Netmask)
    • 게이트웨이 (Gateway)
    • 메모리 (Memory)
  • 하이퍼바이저 (Hypervisor)
    • 하이퍼바이저 호스트 당 IP
    • 넷마스크 (Netmask)
    • 게이트웨이 (Gateway)
    • DNS*
    • 호스트 이름의 Prefix
  • IPMI
    • 노드 당 IP
    • 넷마스크 (Netmask)
    • 게이트웨이 (Gateway)

[NOTE] 상기에서 “*”로 표시된 항목은 선택 사항이나, 부득이한 경우가 아니면 설정을 권고한다.


8.2 시스템 이미징 및 배포 (System Imaging and Deployment)

첫 번째 단계는 Foundation UI 연결하는 것인데, 이것은 Discovery Applet에서 수행된다 (만약 동일 L2 네트워크인 경우에, 노드 IP는 필요하지 않음).

[그림] Foundation – Discovery Applet


만약 원하는 노드를 검색하지 못하는 경우에, 동일 L2 네트워크인지를 확인한다.

선택된 노드의 Foundation 인스턴스에 연결한 후에 메인 Foundation UI가 디스플레이 된다.

[그림] Foundation – 검색 페이지


검색 페이지는 검색된 모든 노드 및 블록 정보를 디스플레이 한다.

클러스터 구성을 위해 원하는 모든 노드를 선택한 후에 “Next” 버튼을 클릭한다.

[그림] Foundation – 노드 선택


다음 페이지에서 클러스터 및 네트워크 정보를 입력한다.

[그림] Foundation – 클러스터 정보


[그림] Foundation – 네트워크 정보


모든 정보를 정확하게 입력한 후에 “Next” 버튼을 클릭한다.

다음 페이지에서 노드 상세 정보 및 IP 주소를 입력한다.

[그림] Foundation – 노드 설정


필요한 경우에, 다음 페이지에서 호스트 이름 및 IP 주소를 변경한다.

[그림] Foundation – 호스트 이름 및 IP


네트워크 설정을 검증하기 위해서는 “Validate Network” 버튼을 클릭한다. “Validate Network”는 IP 주소 충돌 및 네트워크 연결 여부를 체크한다.

[그림] Foundation – 네트워크 검증


네트워크 검증이 성공적으로 완료되면, 다음 단계에서 설치하고자 하는 AOS 및 하이퍼바이저 이미지를 선택할 수 있다.

AOS를 업그레이드 하고자 할 경우에는 해당 이미지를 뉴타닉스 Portal 사이트에서 다운로드 받은 후에 Foundation으로 업로드 작업을 수행하여야 한다. 설치하고자 하는 AOS 이미지를 선택한 후에, 하이퍼바이저를 선택할 수 있다.

AHV인 경우에는 AHV 이미지가 Acropolis 이미지에 포함되어 있다. 다른 하이퍼바이저를 사용하는 경우에는 설치하고자 하는 하이퍼바이저 이미지를 업로드 하여야 한다.

[NOTE] AOS와 하이퍼바이저 버전의 호환성 여부를 반드시 확인하여야 한다.

설치하고자 하는 AOS 및 하이퍼바이저 이미지를 선택한 후에, “Create” 버튼을 클릭한다.

[그림] Foundation – 이미지 선택


만약 이미징 작업이 필요하지 않으면, “Skip” 버튼을 클릭하여 이미징 작업을 수행하지 않을 수 있다. “Skip” 버튼을 클릭하면, AOS 및 하이퍼바이저의 재이미징 작업을 수행하지 않지만, 클러스터 정보는 설정하여야 한다 (e.g. IP 주소 등).

[그림] Foundation – 클러스터 생성 과정


클러스터 생성 작업이 성공적으로 완료되면, 다음과 같은 화면이 디스플레이 된다.

[그림] Foundation – 클러스터 생성 완료


클러스터 생성이 성공적으로 완료되면, 임의의 CVM IP 또는 클러스터 IP로 로그인이 가능하고 뉴타닉스 플랫폼을 사용할 수 있다.