VIO-LENCE / Eternal Nightmare

第2世代ベイエリアスラッシュメタルバンドVIO-LENCEのデビューアルバムのタイトルソング。

 

 

★★★★★★★★★☆

#thrash-metal

BLIND ILLUSION / Blood Shower

アメリカサンフランシスコ出身のプログレッシブスラッシュメタルバンドBLIND ILLUSIONのデビューアルバム収録曲。

 

 

★★★★★★★★☆☆

#thrash-metal

FORBIDDEN / Through Eyes of Glass(Live)

TESTAMENTと同じベイエリア出身のスラッシュメタルバンドFORBIDDENのデビュー作より。個人的に一番好きな曲。

 

 

★★★★★★★★★☆

 

TESTAMENT / Practice what you preach

ベイエリア出身の第2世代スラッシュメタルバンドTESTAMENTの3rdアルバムのタイトル曲。

 

 

★★★★★★★★★☆

[Nutanix] AOS의 EOL에 대해서

 

4월 AOS 5.6 릴리스에 맞춰 지원 정책에 변경이 있었습니다. 내용중에는 AOS의 EOL에 대해서도 변경이 있기에 비망록 차원에서 이번에는 간단히 AOS의 라이프사이클에 대해서 소개를 할까 합니다.

 

AOS의 라이프사이클에 대해 소개를 하기 전에 AOS의 버전 번호에 대한 정의를 먼저 소개하겠습니다. AOS는 4개의 번호로 정의가 되어있습니다. 각 번호는 “메이저 버전”, “마이너 버전”, “보수 버전”, “패치 버전”을 뜻합니다.

 

 

Nutanix EOL Bulletine AOS Versions에서는 기본적으로 “마이너 버전”으로 구분되어있습니다.

Nutanix EOL Bulletine AOS Versions

 

그런데 가만히 위의 EOL 정보를 확인해보면 버전중 “LTS”가 붙어있는 버전을 확인할 수 있습니다. 현재로는 AOS 5.5가 그것인데요, 그외의 버전은 붙어있지 않죠.

“LTS”는 Long Term Support, 이른바 장기간 지원을 하는 버전입니다. GA 릴리스후 최대 18개월후 EOL을 맞이합니다. “LTS”는 12개월 주기로 새로운 버전을 릴리스할 예정이라는군요.

 

장기간이 있다면 물론 단기간도 있습니다. 단기간은 “STS”, Short Term Support로 GA 릴리스후 6개월로 지원이 끝납니다. 6개월?  (゜Д゜) ???

OS의 지원이 6개월이라니 믿기지 않을지 모르겠습니다만 “STS”는 기본적으로 신기능 추가가 목적인 버전으로 실환경보다는 검증환경에서 새로운 기능을 확인하기 위한 것이 목적일지 모르겠습니다. 그렇다면 지원이 6개월이라도 어느정도 납득이 되네요. 😉

 

참고로 4월에 릴리스된 AOS 5.6는 10월에 지원이 종료된답니다.

 

이미 Nutanix를 이용하고 있는 분들은 AOS가 빈번히 릴리스되는 것을 알고 계실 겁니다. 새로운 버전이 릴리스되었을 때는 버전의 지원 기간을 확인하도록 주의하시길 바랍니다. 😉

 

지원 정책에 대해 더욱 자세히 알고 싶으신 분들은 지원 정책 페이지를 확인하세요.

 

[VMware] vSAN 캐시 디스크에 장애가 발생하면 디스크 그룹이 보이지않음

 

※ 조금 시간이 지난 내용일지 모르겠습니다.

 

작년에 vSAN에 대한 팁을 몇가지 소개한 적이 있습니다. 내용중에 vSAN 도입후 장애 테스트를 실행할 경우는 가동중인 디스크를 해제하지말고 “vsanDsikFaultInjection.pyc”를 이용하도록 소개를 했었습니다. 이 스크립트를 실행하면 캐시/용량 디스크의 장애 시험을 할 수 있죠.

 

제 자신도 vSAN을 도입한 뒤에는 “vsanDsikFaultInjection.pyc”를 이용하여 디스크의 장애 시험을 행하고 있습니다만, vSAN 6.5부터 예상 밖의 문제에 부딪혔습니다.

 

뭐가 예상 밖이냐면 말이죠, 캐시 디스크에 장애를 일으키면 디스크 그룹이 보이지않게 된다는 겁니다. 이건 문제입니다. 디스크 그룹이 않보이면 뭐가 문제냐면 말이죠, 그 디스크 그룹내의 용량 디스크를 삭제할 수 없기 때문입니다. 용량 디스크를 삭제할 수 없으면 장애가 발생한 캐시 디스크를 교환했더라도 디스크 그룹을 새로 만들 수 없습니다. 왜냐하면 용량 디스크는 여전히 장애가 발생했던 캐시 디스크의 디스크 그룹의 메타 데이터를 갖고 있어 디스크 그룹을 만들려해도 용량 디스크가 표시되질 않기 때문입니다.  (용량 디스크에 장애가 발생하였을 경우는 디스크 그룹이 보이지않는 문제는 발생하지 않습니다)

 

이 현상, vSAN 6.5~6.6.1의 버그인거 같습니다. vSAN 6.2까지는 이 버그의 영향을 받지않았으며 캐시 디스크에 장애가 발생해도 디스크 그룹은 보여지기 때문에 Web Client를 통해 용량 디스크나 디스크 그룹을 삭제할 수 있었습니다. 이 버그, vSAN 6.7에서 해결(이라기보다는 대응)되었다고 합니다.

 

검증환경에서 확인을 해보죠.

 

위의 그림은 vSAN 6.6.1의 검증 환경입니다. 3 노드 구성으로 첫번째 노드(n-esxi65-15)의 캐시 디스크에 장애를 일으키겠습니다.

 

“vsanDsikFaultInjection.pyc”를 실행하여 “Permanent Disk Failure” 상태를 만듭니다.

 

보이시나요? 첫번째 노드(n-esxi65-15)의 디스크 그룹이 보이지 않게 되었습니다. 하지만 캐시 디스크와 용량 디스크는 확인을 할 수 있습니다. 하지만… 용량 디스크를 삭제할 수 있는 방법이 없습니다. 허허허

 

이번에는 버그를 대응한 vSAN 6.7의 검증 환경입니다. 역시나 3 노드 구성으로 첫번째 노드(n-esxi67-21)의 캐시 디스크에 장애를 일으키겠습니다.

“vsanDsikFaultInjection.pyc”를 실행하여 “Permanent Disk Failure” 상태를 만듭니다.

음? 대응되었을 버전임에도 불구하고 vSAN 6.6.1과 동일하게 디스크 그룹이 보이지 않게 되었습니다. 아울러 용량 디스크를 삭제할 수 있는 메뉴가 없습니다. 흐음…

 

HTML5 Client로 다시금 vSAN 6.7 클러스터를 확인해 봤습니다. 확인해보니 [Remove Disk(s)] 메뉴가 있네요! 😉 아시겠지만 Flash Client는 vSAN 6.7에서 비추천, 다음의 버전에서 비지원이 됩니다. 따라서 Flash Client에는 이 대응 메뉴가 추가되지 않은 것 같습니다.

 

[Remove Disk(s)]를 클릭하면 용량 디스크를 삭제할 수 있습니다.

 

깔끔하게(?) 삭제가 되었네요. 흐흐

 

참고로 이 버그의 영향을 받는 vSAN 6.5 ~ 6.6.1 환경에서 만약 캐시 디스크에 장애가 발생하였다면 아래의 방법으로 ESXi에서 직접 용량 디스크를 삭제할 수 있습니다.

 

우선 삭제할 용량 디스크의 디바이스명을 확인합니다.

esxcli vsan storage list

 

디바이스명을 확인했다면 다음의 명령어를 실행, 용량 디스크를 하나씩 삭제합니다.

esxcli vsan storage remove –evacuation-mode=noAction –disk=디스크명

😉

 

[VMware] vExpert VSAN 2018을 수상했습니다

 

영광스럽게 올해도 vExpert VSAN 2018을 수상하게 되었습니다.

 

 

vExpert VSAN 2018 Announcement

 

vExpert VSAN 프로그램은 vExpert의 서브 프로그램으로 vExpert 안에서 모집하여 vExpert 팀과 Storage & Availability 부문(SABU)에서 심사, 수상자를 결정합니다. VSAN 이외에는 NSX와 Cloud가 있으며 각각 8월, 10월경에 수상자를 발표하는 것 같습니다. (작년에는 그랬네요)

 

하여간 굉장히 기쁘네요. 흐흐 올해는 한국분도 수상을 하신 것 같아 더욱 반갑네요. 😉

 

Horizon 관련의 프로그램도 있습니다만, Horizon의 경우는 vExpert의 서브 프로그램이 아닌 독립 프로그램인 것 같습니다. 정식 명칭은 VMware EUC Champions입니다.

Here They Are: VMware 2018 EUC Champions

 

 

#2018, #%ec%88%98%ec%83%81, #vexpert, #vmware, #vsan

[Nutanix] AHV의 어피니티 정책에 대해서

 

오늘은 Nutanix AHV의 어피니티 정책에 대해서 간단히 소개를 할까 합니다.

Nutanix AOS에서 지원을 하고 있는 어피니티 정책은 다음의 2 종류가 있습니다.

• VM-Host Affinity Policy
• VM-VM Anti−Affinity Policy

 

●VM-Host Affinity Policy

가상머신을 특정의 호스트상에서만 가동하도록 제한을 하는 정책입니다. 이 정책을 설정하면 가상머신은 특정 호스트상에서만 가동을 하게 됩니다.

이 정책은 Prism에서 가상머신 단위로 설정을 할 수 있습니다. 설정하고자하는 가상머신의 [Update] → [Set Affinity]로부터 가동할 호스트를 선택하기만 하면 됩니다.

 

이 정책을 이용할 경우, 한 가지 주위가 필요한 점이 있습니다. 이 정책이 설정된 가상머신은 VMHA(VM Hight Availability)나 ADS(Acropolis Dynamic Scheduling)의 영향을 받지않습니다. 따라서 가상머신이 가동중인 호스트에 장애가 발생하여도 페일오버되지 않으며 ADS에 의한 라이브 마이그레이션도 동작을 하지않습니다. 때문에 정책 설정시에는 호스트 장애 대책으로 2 이상의 호스트를 지정하는 것을 추천하고 있습니다.

 

이 정책이 설정된 가상머신의 클론을 작성하였을 경우, 정책은 해재됩니다만, DR 등에 의한 스냅숏의 복원의 경우는 정책이 유지됩니다.

 

참고로 이 정책을 설정후에는 라이브 마이그레이션의 대상 호스트가 정책 설정시 선택한 호스트만 표시가 됩니다.(다른 호스트로의 라이브 마이그레이션 실행 자체를 원천봉쇄하고 있습니다. 흐흐)

 

●VM-VM Anti−Affinity Policy

특정 가상머신을 같은 호스트에서 가동하지 않도록 하는 정책입니다. 이 정책은 Prism에서는 설정을 할 수 없고 aCLI에서 설정을 할 필요가 있습니다.

 

nutanix@NTNX-1XXXXX2-A-CVM:192.168.1.51:~$ acli

① Acropolis CLI를 시작합니다.

 

<acropolis> vm_group.create AffinityGroup01
AffinityGroup01: complete

② 우선 VM 그룹을 만듭니다.

 

<acropolis> vm_group.add_vms AffinityGroup01 vm_list=v-vom01,v-central01
v-central01: complete
v-vom01: complete

③ 작성한 VM 그룹에 가상머신을 추가합니다.

 

<acropolis> vm_group.list_vms AffinityGroup01
VM name VM UUID
v-central01 c63eddf4-bc58-4256-b9e7-5d723a7943a8
v-vom01 d9f7d6df-3d7b-49d8-92ef-48dbb048de27

④ 제대로 VM 그룹에 가상머신이 추가되었는지 확인을 합니다.

 

<acropolis>
<acropolis> vm_group.antiaffinity_set AffinityGroup01
AffinityGroup01: complete

⑤ VM 그룹에 대해 안티-어피니티 룰을 유효화합니다.

정책 설정후에는 정책을 위반(수동으로 가상머신을 라이브 마이그레이션)했더라도 잠시후 자동적으로 정책이 적용됩니다. 🙂

 

이 정책은 VM-Host Affinity Policy과는 달리 ADS나 VMHA의 영향을 받습니다.

 

참고로 이 정책과는 반대의 특정 가상머신을 동일한 호스트상에서 가동토록하는 VM-VM Affinity Policy은 현재(AOS 5.7)에서도 지원을 하지않고 있습니다.

 

[VMware] vCenter 6.7의 고급 연결 모드에 대해서

 

대규모 환경이나 여러 거점이 있어 각각 vSphere 환경이 있을 경우, 운용이 번잡하죠. 각 환경을 관리하기 위해서는 각 환경의 vCenter에 접속하지 않으면 않되기 때문이죠. 이것을 해결하기 위한 기능이 “고급 연결 모드”입니다.

 

고급 연결 모드는 여러 vCenter를 하나의 관리 UI(Web Client)에서 관리할 수 있게 해줍니다. 고급 연결 모드를 구성하면 PSC 사이에 SSO 정보는 물론 롤이나 권한, 정책 등이 복제됩니다.

 

이 고급 연결 모드, vCenter 5에서는 ”연결 모드”로 불렸습니다. 이 연결 모드가 PSC와 vCenter의 아키텍쳐로 크게 바뀐 vCenter 6부터 ADAM을 의존하지 않게되어 VCSA에서도 구성이 가능한 ”고급 연결 모드”로 개선된 것이라고 할 수 있습니다.

 

vCenter 6.5까지는 이 고급 연결 모그를 구성하기 위해서는 PSC를 Embedded가 아닌 External PSC로 설치를 할 필요가 있었습니다. 이건 이거대로 번잡해지는데요… External PSC는 VCHA를 구성할 수 없기 때문입니다. vCenter는 VCHA를 구성하면 간단히 가용성을 확보할 수 있습니다만 External PSC는 결국 NSX나 3rd Party의 로드 밸런서에 의존할 수 밖에 없었기 때문입니다.

 

6.7부터는 Embedded PSC에서도 고급 연결 모드를 구성할 수 있게 되었습니다. 이로써 더욱 간단히 고급 연결 모드를 구성할 수 있게 되었습니다. 가용성도 로드 밸런서 없이 VCHA를 구성하기만 하면 되죠. 🙂

고급 연결 모드를 구성하는 방법은 아주 간단합니다. 우선 최초의 VCSA(Embedded PSC)를 설치합니다. (제 경우는 이전에 WIndows vCenter에서 VCSA로 이행 & 업그레이드한 VCSA 6.7를 이용했습니다)

 

최초의 VCSA가 설치되었다면 2번째 VCSA(Embedded PSC)를 설치합니다. 설치중 스테이지 2의 [SSO 설정]에서 [기존SSO 도메인에 참가]를 선택하여 처음에 설치한 VCSA를 지정해주기만 하면 됩니다.

 

2번째 VCSA 설치후 HTML5 Client에 접속을 해보면 인벤토리에 2대의 vCenter가 표시되는 것을 확인할 수 있습니다. 여기서 SSO로 Active Directory 도메인을 추가하면 양쪽 다 AD 도메인 계정으로 접속, 관리를 할 수 있습니다.

 

며칠전 vSphere 6.5 Update 2도 릴리스되었습니다. vCenter 6.5 U2는 vCenter 6.7의 기능이 그대로 이식되어 Embedded PSC의 고급 연결 모드가 구성 가능하다고 합니다.

 

※주의!!!! 

현시점(2018년 5월 6일)에서는 vSphere 6.5 Update 2로부터 vSphere 6.7로의 업그레이드는 지원을 하지않습니다.

vSphere 6.7 로 업그레이드를 검토중인 경우는 vSphere 6.5 Update 2로는 업그레이드하지 마세요.

 

[VMware] VCSA의 백업과 복원

 

※ 일본어 환경의 캡쳐를 이용하고 있습니다.

VCSA 6.5부터 VCSA의 가용성을 높이는 기능이 2가지 추가되었습니다. “vCenter High Availability(VCHA)”와 “네이티브 백업(화일 베이스 백업)”이 그것입니다. VCHA에 대해서는 과거에 소개를 했었으니 이번에는 네이티브 백업(화일 베이스 백업)”에 대해서 소개를 할까 합니다.

VCSA 6.0까지는 화일 베이스의 백업이나 DB만을 백업하는 것은 지원을 하지 않았습니다. 따라서 VDP나 3rd 파티의 백업 솔루션을 이용하여 VCSA 전체를 백업해야되었습니다. 하지만 6.5부터 화일 베이스의 백업이 가능하게 되어 간단히 필요한 데이터를 백업할 수 있게 되었습니다.

또한 6.7에서는 백업을 정기적으로 돌릴 수 있는 일정이 가능하게 되어, 더이상 VCSA의 백업에 대해서 고민할 필요가 없어졌습니다. 😉

 

(1) VCSA의 백업

우선 수동으로 백업을 실행해보도록 하겠습니다.

① VCSA 관리 페이지의 [Backup]을 선택, [지금 백업]을 클릭합니다.

② 다음의 정보를 입력후 [시작]을 클릭합니다.

• • 백업 위치 : 백업 서버의 정보입니다. 전 점프서버에 FTP 서버를 설치했습니다. FTP 이외에 HTTP, HTTPS, SCP, FTPS를 이용할 수 있습니다.
  • 백업 서버 자격 증명 : 백업 서버의 자격 증명을 입력합니다.
  • 암호화(옵션) : 백업 데이터의 암호화를 할 경우, 암호를 지정합니다.
  • 데이터 : 백업 데이터를 선택합니다. 구성정보는 물론 이벤트나 통계 정보도 백업을 할 수 있습니다.

③ 백업이 실행됩니다.

④ 백업 상태가 완료된 것이 확인되면 끝입니다. 😉

⑤ 백업 서버에서는 저장된 백업 데이터를 확인할 수 있습니다.

 

(2) VCSA의 복원

이번에는 복원을 해보겠습니다. 복원이라고 해도 VCSA를 가상 어플라이언스로 복원하는 것은 아닙니다. 새롭게 VCSA를 전개후 데이터를 복사하는 형태입니다.

① VCSA 설치 마법사는 시작하여 [복원]을 선택합니다.

② 스테이지 1의 구성을 시작합니다.

③ EULA 동의후 복원할 백업의 정보를 입력합니다.

• • 위치 또는 IP 어드레스/호스트 이름 :  백업 데이터의 절대경로(backup-metadata.json 화일이 저장되어있는 폴더)
  • 유저 이름 : 백업 서버의 유저 이름
  • 패스워드 : 백업 서버의 유저의 패스워드

④ 검출된 백업의 정보를 확인루 [Next]를 클릭합니다.

⑤ 여기서부터는 새롭게 전개할 VCSA의 정보를 입력합니다. 이 부분은 새롭게 VCSA를 전개하는 방법과 동일하므로 소개를 하지않겠습니다.

⑥ 네트워크 정보는 백업 데이터로부터 정보가 자동적으로 반영되므로 새롭게 입력을 할 필요는 없습니다만, 네트워크 포트 그룹만은 올바르게 지정을 해줘야 됩니다.

⑦ [완료]를 클릭하여 VCSA의 전개를 시작합니다.

⑧ HTML5 Client에서도 새롭게 전개되는 VCSA를 확인할 수 있습니다.

⑨ VCSA의 전개가 끝났다면 계속해서 스테이지 2로 진행을 합니다.

⑩ 다시금 백업 서버의 자격 증명 정보를 입력후 [Next]를 클릭합니다.

⑪ 복원 대상의 VCSA가 아직 동작중이라면 정지후 [종료]를 클릭합니다.

⑫ 복원이 시작됩니다.

⑬ VCSA의 복원이 정상적으로 완료되었습니다.

⑭ VCSA의 관리 페이지로 접속을 하여 전체 상태에 이상이 없는 것을 확입니다.

⑮ HTML5 Client로 접속을 하여 데이터센터, 클러스터, 호스트 등 복원하기 전과 차이가 없는 것을 확인합니다.

 

(3) VCSA 백업의 일정

VCSA 6.5에서는 이 일정 기능이 없었기에 매번 관리자가 직접 백업을 실행하거나 스크립트를 짜서 운용할 수 밖에 없었습니다만, VCSA 6.7에서는 대망(?)의 백업 실행 일정을 설정할 수 있게 되었습니다.

① 백업 일정의 [편집]을 클릭합니다.

② 수동으로 백업을 실행했던 것과 동일하게 백업 정보를 입력합니다. 기본적인 백업 정보이외에 “일정”과 “보존할 백억 수”를 추가로 설정후 [저장]을 클릭합니다. 설정이 가능한 백업 일정은 “일단위”, “주단위”, “요일단위”입니다.

③ 백업 일정이 작성된 것을 확인합니다. 참고로 백업 일정은 하나만 작성을 할 수 있으며 작성한 백업 일정은 삭제하지않고 “사용 안 함” 설정도 가능합니다.

백업 서버만 준비가 된다면 아주 간단히 백업을 작성하거나 일정을 설정할 수 있습니다. 복원 자체도 간단합니다. VCSA에 관해서는 별도의 백업 솔루션을 이용할 필요가 없습니다.

VCSA를 도입한 관리자 분들은 빨리 6.7로 업그레이드하여 백업에 고민으로부터 해방되시길… 🙂