[VMware] Windows vCenter에서 VCSA로의 마이그레이션

 

얼마전에 vSphere 6.7이 릴리스되었죠.

Introducing VMware vSphere 6.7!

 

이번 버전은 vCenter Server로써는 특별한 버전입니다. 왜냐하면 이번 버전 6.7은 Windows vCenter를 지원하는 마지막 버전이 되기 때문입니다. 정확하게 말하자면 지원은 하지만 Windows vCenter은 ”비추천”이 되어버린 버전입니다. (이 내용에 대해서는 과거의 포스팅을 확인하세요)

 

그렇다면 말입니다… Windows vCenter를 이용하는 환경이라면 언젠가는 VCSA로의 마이그레이션이 필요하다는 말이 되죠. 아마도… 18개월에서 24개월 정도일까요? 물론 6.5 이하의 버전을 계속 이용한다면 가능한 Windows vCenter의 연명이 가능할지도 모르겠습니다만, vSphere 환경을 계속적으로 이용을 한다면 언젠가는 VCSA로의 이사가 필요합니다.

특히 vSphere 5.5를 운용중인 환경일 경우, 올해 9월 18일로 general Support가 종료되기 때문에 꽤나 심각하게 VCSA로의 마이그레이션을 검토해야 됩니다.

 

제 테스트 환경에도 Windows vCenter가 몇대 있기에 6.7 릴리스 기념(?)으로 VCSA로 이사를 해봤습니다. 😉

참고로 Windows vCenter 6.0 U2로부터 VCSA 6.7로 업그레이드함과 동시에 이행했습니다.

그렇다면 간단하게 소개를 하도록 하죠.

 

우선 마이그레이션을 하기 위해서는 “사전체크”를 실시해야 됩니다.

① Windows vCenter에 VCSA 6.7 iso 이미지를 마운트하여 화일내의 ”migration-assistant\VMware-Migration-Assistant.exe”를 실행합니다.

 

② migration assistant가 시작되었다면 administrator@vsphere.local의 패스워드를 입력합니다. migration assistant가 정상적으로 vCenter에 접속되었다면 자동적으로 이행에 필요한 ”사전체크”가 시작됩니다. ”사전체크” 결과, 이행 조건을 만족시키고 있는 상태라면 프롬프트에 ”Waiting for migration to start…”가 표시됩니다. 이로써 이행준비 끝입니다.

※ 이 migration assistant는 이행이 끝날때까지 닫지않도록 주의합니다.

 

③ 이번에는 이행 작업을 실시할 서버에 VCSA 6.7 iso 이미지를 마운트하여 ”vcsa-ui-installer\win32\installer.exe” 화일을 실행합니다. 설치마법사가 시작되면 「Migrate」를 클릭합니다.

※ VCSA의 설치마법사는 Windows vCenter 에서는 실행하지 마세요. 당연한거지만 이행중 Windows vCenter가 정지되기 때문에 이행작업을 이어나갈 수 없습니다.

 

④ 처음에 얘기했듯이 ”이행”도 ”설치”와 같은 프로세스입니다. 스테이지 1에서 VCSA를 전개하여 스테이지 2에서 VCSA를 구성하는 순으로 진행됩니다. [NEXT]를 클릭합니다.

 

⑤ EULA에 동의합니다.

 

⑥ Windows vCenter의 정보를 입력후 [NEXT]를 클릭합니다.

 

⑦ Windows vCenter의 증명서를 받아들입니다.

 

⑧ migration assistant를 확인해보면 네트워크의 정보가 확인되어집니다.

 

⑨ VCSA의 전개할 환경 정보를 입력후 [NEXT]를 클릭합니다.

 

⑩ 자기 증명서의 경고를 받아들입니다.

 

⑪ VCSA를 전개할 데이터센터를 선택후 [NEXT]를 클릭합니다.

 

⑫ VCSA를 전개할 클러스터를 선택후 [NEXT]를 클릭합니다.

 

⑬ 전개할 VCSA의 이름, root 패스워드를 설정후 [NEXT]를 클릭합니다.

 

⑭ VCSA의 사이즈를 결정합니다.

 

⑮ VCSA를 전개할 데이터스토어를 선택후 [NEXT]를 클릭합니다.

 

⑯ 이행에 필요한 일시적인 네트워크를 설정후 [NEXT]를 클릭합니다.

 

⑰ 설정 내용을 확인후 [FINISH]를 클릭합니다.

 

⑱ 스테이지 1이 시작되어 VCSA가 새롭게 전개됩니다.

 

⑲ 스테이지 1이 끝나 VCSA가 전개되었습니다. 계속해서 스테이지 2를 진행합니다.

※ 스테이지 1이 끝난 상태에서는 Windows vCenter에 영향은 없습니다. 단지 여기서 일단 이행 작업을 중지, 스테이지 2를 나중에 실행할 경우는 순서 ①의 migration assistant를 다시금 실행해야할 필요가 있습니다.

 

⑳ 스테이지 2의 마법사를 시작합니다.

 

㉑ 스테이지 2를 시작하면 ”사전체크”가 새롭게 실행되어 네트워크 구성을 재확인함과 동시에 migration assistant의 로그가 VCSA로 복사되어집니다.

 

㉒ Active Directory의 정보를 입력합니다. Windows vCenter가 AD 도메인에 참가된 상태였기 때문에  새롭게 전개한 VCSA도 AD 도메인에 참가시킵니다.

 

㉓ 이행할 데이터를 결정합니다. 또한 이행시 발생하는 다운타임도 확인을 할 수 있습니다.

Configuration　：　구성정보만을 이행합니다.

Configuration and historical data (events and tasks)　：　구성정보를 포함하여 이벤트, 태스크의 이력도 이행을 합니다.

Configuration and historical data (events, tasks and performance metrics)　：　구성정보를 포함하여 이벤트, 태스크, 성능 메트릭의 이력도 이행을 합니다.

선택한 데이터는 VCSA의 시작을 우선시 할지, 데이터의 이행을 우선시할지를 선택할 수 있습니다.

제 경우는 모든 데이터의 이행을 우선시하도록 선택을 하였습니다. 40분정도 다운타임이 발생하는거 같네요. 😉

 

㉔ CEIP의 참가여부를 선택합니다.

 

㉕ 이행에 필요한 정보가 제대로 설정되었는지 확인을 합니다. 문제가 없다면 VCDB의 백업실행후 [FINISH]를 클릭합니다.

 

㉖ 여기서 경고가 표시됩니다. [OK]를 클릭하면 Windows vCenter가 정지됩니다. [OK]를 클릭합니다.

 

㉗ 이행이 시작됩니다.

 

㉘ migration assistant에서도 데이터의 이행이 시작되는 것을 확인할 수 있습니다.

※ 데이터 이행이 끝나면 자동적으로 정지됩니다.

 

㉙ 데이터 이행이 끝나 Windows vCenter가 정지되었습니다. 잘못해서 시작하지 않도록 주의하세요. 🙂

 

㉚ 이행은 순서 ㉓에서 표시된 예상시간보터 일찍, 약 30분 정도 걸렸습니다.

 

㉛ 무사히 VCSA로 이행되었으므로 가상 어플라이언스의 관리 페이지에 접속해 보도록 하죠. 로그인후 헬스 상태를 확인합니다. VCSA 6.7부터는 GUI에서도 각 서비스의 정지/시작을 할 수 있는 [서비스]가 추가되었네요.

 

㉜ HTML5 Client에도 접속을 해보겠습니다. 문제없이 데이터센터, 클러스터, 호스트 등의 오브젝트 정보가 표시되는 것을 확인할 수 있었습니다.

 

이행은 의외로 간단히 끝났습니다. 걸린 시간도 어느정도 설치마법사에서 표시된 시간과 크게 차이가 없었습니다. 또한 이행후 동작을 확인해봤습니다만 문제없이 이행되어있었습니다.

오랫동안 Windows vCenter를 운용해온 관리자로써는 VCSA의 허들이 꽤 높게 보일 수 있을겁니다. 하지만 그런 걱정은 할 필요없습니다. 기본적으로 VCSA를 콘솔이나 SSH로 접속하여 관리할 필요가 없고, 예를들어 6.0 이후는 Windows vCenter에서도 관련 서비스는 ”services.msc”이 아닌 ”service-control” 명령어를 이용해야되는 등 Windows vCenter에서도 VCSA에서도 운용의 경계가 거의 없어졌기 때문이죠. 더군다나 VCHA나 네이티브 백업 등 새로운 기능은 VCSA에서만 제공되기 때문에 이행하지않을 이유가 없습니다.

Windows vCenter를 운용중인 관리자분들은 VCSA로의 마이그레이션을 검토하시길 바랍니다.

 

출처: http://virtualhive.tistory.com/1039 [Virtual Hive]

[VMware] vSAN 6.7 릴리스

 

4월 17일 vSphere 6.7가 릴리스되었습니다. 물론 vSAN도 버전 6.7이 릴리스되었습니다. 😉

간단히 새롭게 추가나 개선된 기능을 정리하자면…

• vSAN도 HTML5 Client에서 조작이 가능하게 되었습니다. 또한 새로운 기능은 HTML5 Client에서만 설정이 가능합니다.
• vROps의 플러그인이 통합되어 HTML5 Client에서도 vSphere는 물론 vSAN의 모니터링이 가능하게 되었습니다.
• iSCSI 서비스가 WSFC를 지원하게 되었습니다. 이로써 Failover Cluster의 공유 스토리지로써 vSAN을 이용할 수 있게 되었습니다.
• 재동기의 성능이 향상되었습니다. 네트워크 대역의 최저 20%를 재동기용으로 보장을 하게됩니다. 만약 재동기 트래픽이 발생하지 않을 경우는 VM의 IO에 100% 이용되도록 동적으로 조정이 된다고 합니다.
• VM swap 화일이 디폴트로 씬프로비저닝으로 작성되게 되었습니다.
• vSAN 네트워크의 중첩 기능이 개선되어  멀티 vsan vmkernel 구성시, 장애가 발생하면 곧바로 네트워크의 페일오버가 이루어집니다.
• 확장 클러스터 구성시, Witness의 트래픽을 분리할 수 있게 되었습니다.
• 확장 클러스터 구성시 Primary-Secondary 사이에서 레플리카 데이터를 부분적으로 동기후 나머지는 Proxy Owner에 의해 로컬 복사를 실행하여 네트워크 트래픽을 최소화할 수 있다고 합니다.
• 헬스 체크 항목의 추가와 새로운 esxcli 명령어가 추가되었습니다.
• GSS에 의한 원격 감시와 능동적인 대응이 강화되었다고 합니다.
• USB/SD 카드에서도 코어덤프 파티션의 동적 확장이 가능하게 되어 코어덤프와 로그를 항구적으로 유지가 가능하게 되었다고 합니다.
• 4K 디바이스를 지원하게 되었습니다.
• 어플리케이션 레벨에서 동기를 하는 VM과 그 데이터를 동일한 ESXi 호스트에 유지하는  Host Pinning이 확장 클러스터 이외에도 지원을 하게 되었다고 합니다.

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

 

[VMware] VMware 구성 상한의 확인 사이트

 

이런 사이트가 공개되었네요.

VMware Configuration Maximums

이 사이트가 뭐냐하면 말이죠, VMware 프로덕트의 구성의 제한(상한)을 확인, 버전별로 비교를 할 수 있는 사이트입니다. 이 사이트를 이용하지 않는다면 각 버전별로 구성 상한을 정리해둔 공식문서로 확인을 해야만 하죠.

아직 이용할 수 있는 프로덕트가 vSphere 뿐이고 버전도 6.0 이상이기에 완전하지는 않습니다만 버전별의 비교 기능은 꽤 유용하게 이용할 수 있을거 같습니다.

제안이나 설계시 활용해야겠습니다. 🙂

 

[VMware] vRealize Automation 7.4 발표

 

2018/04/13 Updated

릴리스되었네요! 😉

vRealize Automation 7.4 release notes

 

3월 29일 vRealize Automation 7.4이 발표되었습니다!!!

What’s New in vRealize Automation 7.4

작년 5월에 7.3이 릴리스된 후 약 1년만에 업데이트 버전입니다. 아직까지 추가된 기능의 완전한 내용은 알 수 없습니다만, 위의 공식 블로그에서 발표된 기능만으로도 릴리스되면 당장 버전업을 하고 싶어지네요. 흐흐

간단히 내용을 정리하자면 발표된 7.4에서는 다음과 같은 기능이 추가되는것 같습니다.

• • 이용자가 GUI 기반의 폼으로부터 서비스 요구를 할 수 있는 커스텀 폼 디자이너
  • 블루프린트로써 OVF 화일을 이용가능
  • vRO(vRealize Orchestrator)의 멀티 테넌트 기능 지원
  • vRO의 UI 변경(HTML5)
  • Azure/AWS용 커스텀 속성의 추가
  • 20개 이상의 블루프린트와 120개 이상의 OVF 어플리케이션 팩키지 추가

vRealize Automation 7.4의 발표와 더불어 vRealize Operations 6.7, vRealize Suite Lifcycle Manager 1.2 도 발표되었습니다.

릴리스 일정은 발표되지 않았습니다만 4-5월중이 되지않을까 싶네요. 😉

 

[Nutanix] Acropolis File Services(AFS)에 대해서-3

 

이번에는 AFS의 공유 폴더 작성할 때 설정이 가능한 다음의 기능에 대해서 소개를 할까합니다.

• • ABE (액세스 기반 열거)
  • SSR (셀프 서비스 복구)

위의 기능들은 화일 서버 서비스를 제공하기 위해서는 필수불가결한 기능이죠. 없으면 관리자는 지옥을 경험하게 될겁니다.  🙂

이 기능들을 이용하기 위해서는 공유 폴더 작성시 기능을 유효화하기만 하면 됩니다. 간단하죠. 물론 실제로 이용을 하기 위해서는 별도의 작업이 필요합니다.

 

ABE(Access Based Enumeration)

다들 아시리라 생각됩니다만 이 기능은 액세스 권한이 없는 폴더를 안보이게 하는 기능입니다. 음… 표현이 좀 이상하군요. 정확히는 액세스 권한에 따라서 폴더를 표시하는 기능입니다. 이 기능은 비단 AFS만의 기능이 아니죠. 이른바 SMB를 이용하는 Windows 화일 공유 서비스의 표준 기능이기 때문에 설정도 동일합니다. 😉

폴더의 “보안 설정의 고급 설정”에서 허가할 사용자나 그룹을 추가, 그외는 액세스 권한을 삭제해주면 됩니다.

 

ABE 유효후 액세스 권한이 제대로 설정되었다면 왼쪽 그림처럼 권한이 없는 사용자에게는 보이지 않습니다. 반대로 권한이 있는 사용자라면 오른쪽 그림처럼 ”Human Resources”란 폴더가 보이게 됩니다. 당연한걸 설명했네요. 쩝…

 

SSR(Self Service Restore)

SSR도 아시다시피 관리자를 통하지않고 사용자 자신이 백업 데이터로부터 필요한 데이터를 복구하는 기능입니다. 단지 AFS의 SSR은 NGT를 설치하여 이용하는 SSR과는 다릅니다. 🙂

 

AFS 구성시 마지막에 Protection Domain 이름을 설정한 것을 기억하시나요? AFS를 구성하면 자동적으로 백업이 작성됩니다. 작성된 백업잡은 화일서버의 [Protect]에서 확인을 할 있죠.

[Protect]를 클릭하면 ”시간”, ”일”, ”주”, ”월”별로 스케쥴이 설정되어있는 것을 확인할 수 있습니다. 이 스케줄을 필요에 따라서 변경이 가능합니다만 변겅은 [Protect]에서 가능합니다. Protection Domain에서는 이 스케줄이 표시되지않으니 주의하세요.

 

스케줄링되어진 백업잡은 자동적으로 실행이 됩니다. SSR을 유효한 공유 폴더의 속성을 열어 [과거의 버전]탭을 클릭하면 백업(스냅숏)이 생성되어있는 것을 확인할 수 있습니다. 확인삼아 백업 데이터의 하나를 열어보겠습니다.

 

백업이 생성된 날짜와 시간을 확인할 수 있기에 간단히 필요한 데이터를 복구할 수 있습니다.

 

여기까지가 AFS에 의한 화일서버 서비스 구성에 대한 소개였습니다.

 

[Nutanix] Acropolis File Services(AFS)에 대해서-2

 

저번에는 AFS의 도입에 대해서 소개를 했습니다. 이번에는 공유 폴더의 작성이나 쿼터 설정에 대해서 소개를 하도록 하죠.

 ① [File Server]를 선택하여 ［＋ Share］를  클릭합니다.

 ② 다음의 정보를 입력합니다.

• NAME：공유 폴더명
• FILE SERVER：공유 폴더를 작성할 화일 서버

※공유 폴더명으로 “Global”, “Printers”, “admin$”, “ipc$”, “homes”는 AFS에서 예약된 이름이므로 이용할 수 없습니다.

공유 폴더명을 지정했다면 ABE와 SSR 기능을 유효화후 [Save]를 클릭합니다.

 ③ 공유 폴더가 작성된 것을 확인합니다.

 ④ 공유 폴더가 작성되었다면 우선 쿼터를 설정합니다. 작성한 공유 폴더를 선택하여 [Add Quota Policy]를 클릭합니다.

 ⑤ 다음의 정보를 설정후 [Save]를 클릭하기만 하면 됩니다. 🙂

• USER OR GROUP：쿼터를 설정할 유저나 그룹
• QUOTA：쿼터값（용량）
• ENFORCEMENT TYPE：한계치를 넘었을 때의 액션

※메일 알림은 필요에 따라서 받는 이를 설정해주면 됩니다.

  

⑥ 다음에는 공유 폴더의 액세스 권한 설정입니다. 공유 폴더 작성시의 디폴트 액세스 권한은 “everyone”입니다. 네… 이대로는 화일 서버로 이용하기가 뭐하죠… 흐흐  따라서 적절한 액세스 권한을 설정해줘야 합니다만, 액세스 권한의 설정은 Prism에서는 할 수가 없습니다. 공유 폴더의 액세스 권한 설정은 AD 도메인에 소속되어있는 Windows OS 서버(내지는 PC)를 통해 행해야 됩니다.（문서에도 써있죠）

To set share level permissions for AFS shares. Navigate to the Microsoft Management Console. Select Shared folder and select the file server that requires updated permissions. Navigate to the share properties and update the manage permissions.

라고 말입니다. 😉

여기까지 설정을 하였다면 이용자에게 공개할 수 있게 됩니다.

다음에는 보다 화일 서버답게 이용을 할 수 있도록 해주는 ABE와 SSR의 설정에 대해서 소개를 하겠습니다.

 

 

#acropolis-file-services, #afs, #ahv, #aos, #cvm, #esxi, #%eb%8f%84%ec%9e%85, #fsvm, #nutanix

[VMware] vRealize Automation 환경의 모니터링

 

vROps는 관리팩을 설치하므로써 다양한 제품이나 솔루션을 감시할 수 있습니다. 이 관리팩은 기본적으로 팩키지 화일을 설치하여 vROps에 모니터링에 필요한 메트릭이나 오브젝트의 정의를 생성합니다만, vROps 6.6부터 아래의 제품에 대해서는 관리팩이 통합된 형태로 제공되고 있습니다.

• vSphere vSAN
• vRealize Log Insight
• vRealize Bussines for Cloud
• vRealize Automation

 

위의 제품에 대해서는 별도로 관리팩을 설치할 필요없이 바로 모니터링의 구성이 가능합니다.

 

작년부터인가요? vRealize Automation에 관한 설치 시리즈를 포스팅하고 있습니다만, vROps와의 통합에 대해서도 소개를 한 적이 있습니다. 이번에는 반대로 vROps쪽에서 vRA의 환경을 모니터링하기 위한 방법을 소개하도록 하겠습니다.

 

① [관리] → [솔루션]의 솔루션 리스트에서 “vRealize Automation”를 선택하여 [구성(기어 아이콘)]을 클릭합니다.

 

② vRA 환경 접속에 필요한 정보(인스턴스)를 작성합니다.

• 표시명 : 작성하는 접속 구성 정보명
• vRealize Automation 어플라이언스 URL : https://vRA 가상 어플라이언스
• 인증정보 : 새롭게 작성을 합니다.

 

③ 다음의 인증정보를 입력후 [OK]를 클릭합니다.

• 인증정보명 : 작성하는 인증정보명
• SysAdmin : vRA의 시스템 관리자(일반적으로는administrator)
• SysAdmin : vRA 시스템 관리자의 패스워드
• SuperUser : 테넌트 관리자
• SuperUser : 테넌트 관리자의 패스워드

 

④ 인증정보의 작성이 끝났다면 [접속 테스트]를 실행, 정상적으로 접속이 되는지 확인을 합니다.

 

⑤ 설정을 저장후, 솔루션 구성을 종료합니다.

 

⑥ 솔루션의 구성이 끝나면 데이터의 수신과 수집이 시작됩니다. 여기까지 왔다면 남은건 데이터가 축적되는 것을 기다리기만 하면 됩니다. 😉

 

⑦ 수신한 데이터는 [대쉬보드]의 “vReazlie Automation”에서 확인을 할 수 있습니다.

 

⑧ 모니터링이 가능한 디폴트 정보는 “테넌트”나 “비지니스 그룹”, “블루프린트” 리스트를 포함,  “테넌트별의 중대한 알람”, “인기 블루프린트”가 있습니다. 대쉬보드의 커스터마이즈에서 성능의 메트릭 등의 위젯을 추가하면 더욱 자세한 정보를 모니터링할 수 있습니다.

 

[Nutanix] Nutanix 데모 사이트의 소개

 

demo.nutanix.com은 Nutanix사가 공개하고 있는 데모용 사이트입니다.

파트너의 경우는 my.nutanix.com의 계정으로 이용을 할 수 있습니다.

 

로그인하면 각 하이퍼바이저별로 클러스터를 조작할 수 있습니다. 하이퍼바이저 이외에는 Dell EMC의 XC 시리즈나 Prism Central의 데모가 가능합니다.

 

각 하이퍼바이저를 간단히 비교할 수도 있습니다.

 

Prism Central도 조작을 할 수 있죠. Prism Central의 경우는 별도의 라이센스가 필요하기 때문에 여기서 이것저것 만질 수 있는 것은 아주 편리합니다.

 

Prism Central에서는 Calm도 조작을 할 수 있습니다. 이미 몇개의 프로젝트가 만들어져있네요. 흐흐 여기서 Calm의 공부를 해도 될 거 같습니다. 😉

 

이 데모 사이트는 Prism Element/Prism Central의 데모 이외에도 활용할 수 있을거 같습니다.

• • 하이퍼바이저의 기능 비교
  • 조작 방법의 확인
  • 매뉴얼 작성용 스크린 캡쳐
  • NPP 시험 대책 (특히나 Prism Central) 😉

 

[Nutanix] NPP 5.0 테스트

 

어제 NPP 5.0 시험을 패스했습니다. 아직까지 NPP에 대해서 모르시는 분들은 과거의 포스팅 [Nutanix] NPP를 아시나요? 을 확인하세요.

 

작년말부터 NPP를 업데이트 하려고 Administration Course도 등록을 했습니다만, 제대로 준비를 못했죠.

 

연말연시 연휴중 특별히 할일도 없고해서 준비를 재개, NPP 시험까지 치뤘습니다만 결과는 실패…  ﾟ(ﾟ´Д｀ﾟ)ﾟNPP 4.0, 4.5보다 어려워졌더군요. 일단 중지, 한동안 냅뒀다가 어제 다시금 시험을 치뤘습니다. 결과는 또 실패… (´・ω・｀)

 

음… 실환경도 있어서 이것저것 다루고있고, 고객에게 워크숍이나 설명회도 하고 있는데도 이런 결과라니…  흐흐 괜시리 혼자서 열받아 연속으로 시험에 도전… 또 실패… 아무리 무상의 시험이라고 해도 3번이나 떨어지는 멍~해지더군요. 쩝…

 

그래서 조금 시간을 두고 생각해봤죠. 가만히 생각해보니 Security나 Migration 관련부분이 약한거 같았습니다. 예를들어 Data-at-Rest Encryption나 ESXi에서 AHV로의 이행 같은 부분이죠. 그래서 문서를 읽어보기로 했습니다. Security Management나 Migration Guide를 중심으로 문서를 가볍게 읽었죠. 그뒤에 4번째의 시험… 겨우 패스했습니다. ( ´Д｀)=3

 

후우… 무상이라고 얕잡아본 것을 반성하면서… 앞으로 NPP 5.0 시험에 도전하실 분들을 위해 간단히 어드바이스를 하자면… 우선은 Administration Course를 들으시길… self-paced이기 때문에 자신의 페이스로 Nutanix의 Enterprise Cloud Platform에 대해서 배울 수 있습니다.

 

다음에는 공식문서일까요 개인적으로 벤더 문서중 Nutanix사의 문서가 가장 알기 쉽고 찾기 쉽다고 생각합니다. NPP 시험을 치루고자 하는 분들은 시험 전에 꼭 읽어보세요. (3번이나 떨어진 제가 어드바이스라고 하는 것도 그렇네요. 쩝…)

 

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

 

영광스럽게 올해도 vExpert 2018을 수상하게 되었습니다. 2012년부터 7년째의 수상으로 더없이 기쁠뿐입니다. 😉

 

vExpert 프로그램이 어떤 것인지는 과거의 포스팅에서 몇번이고 언급했으니, 과거 포스팅을 확인하시고요, 올해의 vExpert 2018는 전세계적에서 1,522명이 수상을 하게되었습니다. 한국 분은 저를 포함 2명인거 같네요. (거주지가 한국인 분은 1명… 흐흐) vExpert Directory에서 확인이 가능합니다.

 

한국도 작은 시장은 아니라고 생각합니다. 좀 더 많은 분들이 수상을 하게 되었으면 하는 바램이네요.

 

올한해도 VMware를 시작으로 한 가상화/클라우드 관련 정보를 공유해 나가겠으니 계속해서 잘 부탁드리겠습니다~