2017.05.28 12:11

[VMware] vSAN 중복 제거와 압축 이용시의 고려사항

아시다시피 vSAN 6.2에서 새롭게 중복 제거와 압축 기능이 추가되었습니다. 


중복 제거와 압축의 목적은 vsanDatastore의 효율적인 이용입니다. VMware사의 문서에 의하면 최대 7배의 용량을 절약할 수 있다고 합니다.




간단히 중복 제거 와 압축 기능에 대해서 복습(?)하도록 하죠. :)

데이터는 캐시 티어인 핫티어로부터 용량 티어인 콜드 티어로 디스테이징할 때 4KB의 청크 사이즈로 분할되어 중복 제거가 이루어집니다. 중복 제거가 이루어진 데이터는 이어서 압축도 실행됩니다. 압축은 중복 제거를 위해 4KB의 사이즈로 분할된 블록 데이터를 대상으로, 2KB 미만 사이즈로 이루어집니다.



중복 제거와 압축 기능은 All Flash 구성이라면 간단히 이용을 할 수 있습니다. 하지만 중복 제거 와 압축 기능을 이용하기 위해서는 몇가지 고려할 점이 있습니다. 


▶ 중복 제거와 압축 기능은 캐시 티어에서는 실행되지않습니다

위의 그림을 보시면 알 수 있듯이 중복 제거와 압축은 캐시 티어에서 용량 티어에 저장되는 시점에서 이루어집니다.


▶ 중복 제거와 압축 기능은 세트입니다. 

따라서 중복 제거 기능만 이용 또는 압축 기능만 이용은 할 수 없습니다.


▶ 중복 제거와 압축은 "디스크 그룹"단위로 구현됩니다. 

따라서 용량 티어의 SSD에 장애가 발생하여 교환이 필요할 경우 해당 디스크 그룹을 일단 삭제, 교환후 새롭게 디스크 그룹을 만들어야 합니다. 아울러 장애가 발생했을 경우는 디스크 그룹내의 모든 디스크가 장애로 표시되어집니다.(놀라지 마시길... 흐흐)


▶ 운용중에 중복 제거와 압축 기능을 유효/무효화할 수 있습니다. 

하지만 기능을 유효화에서 무효화(또는 그 반대)로 변경을 하게되면 모든 디스트 그룹이 순차적으로 삭제, 재포맷, 재작성되어집니다. 용량이 많으면 많을수록 성능에 큰 영향을 줄 수 있으므로 주의하시길 바랍니다.


▶ 중복 제거와 압축 기능은 만능이 아닙니다.

중복 제거와 압축 기능이 모든 워크로드에 맞는 만능은 아닙니다. 위에서 설명했듯이 중복 제거와 압축은 캐시 티어에서는 이루어지지 않습니다. 따라서 쓰기 처리가 많이 발생하는 워크로드나 트랜잭션이 많이 발생하는 데이터 베이스, 동영상 데이터 등은 중복 제거와 압축 기능을 향유할 수 없거나 큰 효과는 기대할 수 없는 경우도 있습니다.


중복 제거와 압축 기능 이용을 검토중인 분들에서 위의 내용이 조금이라도 도움이 되었으면 합니다. 아울러 공식문서도 확인을 하시고, 설계시에는 장애/복구 시나리오도 충분히 검토하세요~! :)




저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Trackback 0 Comment 2
2017.05.10 21:20

[VMware] vSAN Fault Domain에 대해서

vSAN을 도입한 기업이 있다고 하죠.

스몰 스타트로서 3대의 ESXi 호스트로 vSAN을 구성했습니다. 구성후 이런저런 검증을 걸쳐 실환경의 도입이 결정되어 최종적으로는 수십대의 규모로 확장을 계획하고 있습니다. 호스트를 간단히 추가할 수 있으며 호스트가 늘면 늘수록 성능도 향상되는 vSAN의 특징처럼 별어려움없이 호스트를 추가되어져 복수의 서버랙에 걸쳐 vSAN이 확장되었습니다.  


여기서 질문입니다.

만약 vSAN을 구성하고 있는 서버랙중 하나가 전력 장애로 인해 수용된 호스트가 전부 다운되었습니다. 가상머신에는 어떤 영향이 있을까요? 


전력 장애가 발생한 서버랙안에 수용된 호스트에 모든 데이터가 저장되어있는 가상머신은 정지하게 되죠. (몰론 서버랙 전체에 장애가 발생하는 경우는 거의 없습니다. 특히나 데이터 센터라면 제로에 가깝습니다만, 이런 장애가 전혀 발생하지않는다는 보장도 없죠. 흐흐)


자아, 이렇게 복수의 서버랙에 걸쳐 vSAN을 구성하였을 경우, 이러한 장애에는 어떻게 대비하면 될까요?


간단합니다. 일부 서버랙에 데이터가 집중되지 않도록 할 수 서버랙 사이에 데이터를 분산 배치하면 됩니다. Fault Domain을 구성하면 되죠.


vSAN을 구성하고 있는 ESXi 호스트가 데이터 보호의 기본단위인 기본적(?)인 vSAN 클러스터에 비해 Fault Domain은 서버랙 단위로 데이터를 보호할 수 있습니다.


위의 그림처럼 FTT=1의 스토리지 정책의 경우 각 랙안의 호스트에 데이터를 저장하게 됩니다. 따라서 서버랙 하나에 장애가 발생하여 랙안의 호스트가 전부 다운되어도 가상머신이 정지하는 일은 없어집니다. 


Fault Domain도 개념자체는 기본적인 vSAN 구성과 동일합니다. FTT=1의 경우 최소 3 호스트가 필요하듯 Fault Domain의 경우는 최소 3 그룹이 필요합니다. 그룹별로 호스트수가 같을 필요는 없습니다.


간단하게 구성하는 방법을 소개하자면...


① vSAN 클러스터를 선택후, [구성] → [Virtual SAN] → [Fault Domain & Stretched Cluster]순으로 클릭, "Fault Domain 그룹" 작성을 클릭합니다.


② 작성하고자 "Fault Domain 그룹"이름과 멤버로 등록할 호스트를 선택합니다.


③ 제 경우는 3개의 그룹을 작성하여 각각 2 호스트를 등록하였습니다. 이로써 Fault Domain은 끝입니다. 흐흐


④ 실제로 가상머신을 작성, 스토리지 정책을 확인해보면 컴포넌트와 위트니스가 각각 Fault Domain 그룹에 나뉘어져 있는 것을 확인할 수 있습니다.


이처럼 Fault Domain은 이미 운영중인 vSAN 클러스터에서도 서비스 정지없이 매우 간단히 구성을 할 수 있습니다. 그럼에도 불구하고 장애에 대한 대응 레벨을 서버랙 단위까지 확장하고 있으므로 vSAN 클러스터의 확장을 검토중이신 관리자분들은 Fault Domain도 함께 고려해보시길 바랍니다. :)












저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Trackback 0 Comment 4
2017.05.03 12:40

[Nutanix] AOS 5.1 릴리스

5월 1일 Nutanix의 AOS 5.1가 릴리스되었습니다.


Upgrade to AOS 5.1 Today!


출처 Nutanix


5.1에서는 다음과 같은 기능이 추가되었습니다.

    • All Flash, Hybird 혼재로 클러스터 구성이 가능
    • vSphere 6.5 / vCenter 6.5 지원
    • Prism으로부터 CVM의 메모리 증가 가능
    • admin 계정으로 CVM 컨솔 접근 가능
    • SSP(Self-Service Portal)을 통해 독커 컨테이너의 관리 가능
    • 사용자 정의 경고 작성 가능


아울러 5.0에서 tech preview였던 Hot-Add 기능과 XenServer가 정식으로 Nutanix 하드웨어상에서 하이퍼바이저로 이용이 가능하게 되었습니다. 


AOS 이외에 복수의 Prism을 통합관리할 수 있는 Prism Central, Nutanix 환경의 일부를 화일서버 영역으로 구성할 수 있는 AFS(Acropolis File Services), Nutanix 환경에서 컨테이너 서비스를 제공할 수 있는 ACS(Acropolis Container Services), Nutanix 도입툴인 Foundation도 각각 새로운 버전이 릴리스되었습니다.


자세한 내용은 릴리스노트를 확인하세요.

저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Trackback 0 Comment 0
2017.05.01 15:50

[VMware] vSAN Network Design Guide

vSAN 6.6 버전에 맞춘 네트워크 설계 가이드가 공개되었습니다.


VMware vSAN Network Design


이전 버전은 PDF로만 제공이 되었었습니다만, 이번에는 아주 깔끔한 디자인의 온라인 페이지로 구성되어있습니다. (물론 PDF로도 다운로드가 가능합니다)



네트워크 어댑터의 티밍같은 기본적인 구성은 물론 Stretched Cluster 구성이나 iSCSI 타겟 구성 등의 베스트 프랙티스도 있으니 꼭 확인을 해보시기 바랍니다. :)



저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Trackback 0 Comment 0
2017.04.23 18:19

[VMware] vCenter HA (VCHA) 구성

vSphere의 버전이 올라가면 올라갈수록 VCSA를 중요시하는 것을 알 수 있습니다. vSphere 5.1에서 VCSA가 처음으로 릴리스되었을 때는 대부분의 이용자들이 눈도 않줬을 겁니다만 지금은 상황이 많이 달려졌을 듯합니다.


우선 Windows vCenter과 확장성이 같아졌죠. 5.5까지는 지원할 수 있는 호스트 수나 가상머신의 수도 Windows 버전보다 모자랐었습니다만, 6.0에서는 완전히 같아져 클러스터당 최대 64 노드, 최대 8,000대의 가상머신을 관리할 수 있게 되었습니다. 물론 VCSA 6.5에서는 더욱 향상되었습니다. 아울러 6.5는 OS도 SLES가 아닌 Photon OS로 변경되어 더욱 경량화되었습니다. 여기에 Windows vCenter에는 없는 기능이 추가되었죠. 그것이 바로 VCHA(vCenter HA) 기능입니다.


출처:vCenter High Availability Performance and Best Practice


위 그림처럼 VCHA는 말그대로 vCenter를 failover하는 기능입니다. vSphere HA에 의한 failover와는 다릅니다. VCHA는 Active-Passive의 구성입니다. 따라서 Passive용 VCSA와 Witness용 VCSA를 도입해야 됩니다.


VCHA는 간단히 구성을 할 수 있습니다. VCHA의 구성방법은 두 가지가 있습니다.


Basic

VCSA가 HA를 전개하는 클러스터상에 존재할 경우 이용할 수 있습니다. 이 방법은 하트비트용 네트워크만 준비해 놓으면 됩니다. HA구성 마법사를 진행하면 되죠. 


Advanced

Basic과는 달리 VCSA가 HA를 전개하는 클러스터상에 없을 경우 이용을 합니다. 예를들어 컴퓨트 클러스터와 다른 호스트 상에 VCSA가 있을 경우가 되겠네요. 이 방법을 이용할 경우는 하트비트용 네트워크를 준비후 수동으로 Active VCSA에 네트워크 어댑터를 추가해줘야 됩니다.



검증환경에서 VCHA(vCenter HA)를 검증해봤습니다. 제 검증환경은 VCSA가 다른 호스트에 있기 때문에 구성방법은 Advanced를 이용했습니다.



① 우선 Active용 VCSA(vc65-ha-a)에 하트비트용 네트워크를 추가해줍니다.


② VCSA의 가상어플라이언스 관리 페이지를 통해 추가한 하트비트용 네트워크에 IP 어드레스틑 수동으로 지정해줍니다.


③ Web Client로 접속후 VCSA를 선택하여 [설정] → [vCenter HA] → [구성]을 선택합니다.


④ 구성마법사가 표시되므로 [고급구성]을 선택하여 [다음으로]를 클릭합니다.


⑤ Passive와 Witness의 하트비트용 네트워크와 서브넷을 설정후 [다음으로]를 클릭합니다.


이 단계에서 일단 구성마법사의 진행은 중지합니다. 창을 닫지마시고 그대로 두세요. 이 상태에서 Passive와 Witness의 클론을 작성해야됩니다.


⑦ Web Client에 접속을 하여 VCSA를 선택, Passive VCSA용 클론을 작성합니다. 

※ 클론 작성 방법의 소개는 생략을 하겠습니다. 단지 클론 작성 도중에 필요한 "사용자 지정 규격" 정의시에는 다음 항목 설정에 주의를 해야합니다.

    • 호스트명 : Active VCSA의 호스트명
    • 시간대 : Active VCSA와 동일한 시간대
    • NIC #1 : Active VCSA의 IP 어드레스(관리 네트워크)
    • NIC #2 : 순서 ⑤에서 설정한 Passive VCSA의 하트비트용 IP 어드레스 (디폴트 게이트웨이는 설정하지않습니다)

위의 항목 이외에는 VCHA 구성만의 특별한 설정은 없습니다. 모두 설정을 하셨다면 클론을 작성하여 정상적으로 시작되는 것까지 확인을 합니다.


⑧ 이번에는 Witness VCSA용 클론을 작성합니다.

Web Client에 접속을 하여 VCSA를 선택, Passive VCSA용 클론을 작성합니다. 

※ 기본적으로 Passive VCSA용 클론 작성과 동일합니다만, "사용자 지정 규격" 정의시의 항목 설정이 약간 다릅니다.

    • 호스트명 : Active VCSA의 호스트명
    • 시간대 : Active VCSA와 동일한 시간대
    • NIC #1 : DHCP
    • NIC #2 : 순서 ⑤에서 설정한 Witness VCSA의 하트비트용 IP 어드레스 (디폴트 게이트웨이는 설정하지않습니다)

위의 항목 이외에는 VCHA 구성만의 특별한 설정은 없습니다. 모두 설정을 하셨다면 클론을 작성하여 정상적으로 시작되는 것까지 확인을 합니다.


⑨ 다시금 구성마법사를 열어둔 웹페이지로 돌아가서 [마침]을 클릭합니다.


⑩ 구성마법사를 마침과 동시에 HA 클러스터 구성이 시작됩니다.


⑪ 구성은 오래 걸리지않았습니다. 구성이 완료되면 화면 중앙에 각 노드의 롤과 상태가 표시됩니다. HA 구성 초기에는 Active의 정보가 Passive로 복제되기 때문에 상단처럼 경고가 표시될 겁니다.


⑫ 하지만, 정상적으로 정보의 복제가 끝나면 "정상"이 됩니다.


⑬ [감시] 탭에서 HA의 건전성이 "양호"인 것을 확인할 수 있습니다.



VCHA 구성후 failover를 확인해 봤습니다. 제대로 동작을 하는지 말이죠... 흐흐


 우선 Active용 VCSA를 정지했습니다.


Web Client의 페이지를 '새로고침'하면 "failover"가 진행중인 것을 확인할 수 있습니다. failover가 종료될 때까지 일시적으로 에러 화면이 표시될 경우도 있습니다만 대략 6분정도 걸린 것 같았습니다.


 Web Client에 로그인후 VCHA의 상태를 보면 Active 노드의 상태가 끊어져 Passive노드로 변경된 것을 확인할 수 있습니다.


 [감시] 탭에서도 HA의 건전성이 "경고"인 것을 확인할 수 있습니다. 제대로 동작을 하는군요. 흐흐 


구성을 해보니 의외로 failover에 시간이 걸리는걸 알 수 있었습니다. VMware사 공식 블로그에도 vCenter의 구성과 인벤토리의 크기에 따라 시간은 다르지만 대략 4-9분이 걸리는 것을 확인했다고 합니다. 이렇다면 솔직히 싱글 클러스터 환경에서는 vSphere HA로 failover되는 것이 훨씬 빠르게 복구될 겁니다. (물론 vSphere HA는 VCSA에 정지가 발생하지만...) 굳이 이 VCHA를 이용하지않아도 될거 같네요.

하지만 복수의 클러스터를 싱글 vCenter로 관리할 경우는 vSphere HA 뿐만이 아니라 이 VCHA도 병용을 하면 더욱 강건한 vCenter의 중첩구성을 할 수 있지않을까 싶습니다.



퍼포먼스와 베스트 프랙티스에 대해서는 아래 문서를 확인하세요.

vCenter High Availability Performance and Best Practice



저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Trackback 0 Comment 0


티스토리 툴바