'VMware'에 해당되는 글 466건

  1. 2018.02.17 [VMware] vSphere 5.5의 지원 종료에 대해서
  2. 2018.02.10 [VMware] Web Client 접속시 [400] Single Sign-On 에러가 표시됨
  3. 2018.02.01 [VMware] vSAN 6.6 환경에서 ovf 전개가 실패함
  4. 2018.01.06 [ETC] Intel CPU 버그에 의한 취약점에 대해서
  5. 2018.01.03 [VMware] vSAN 팁 몇가지 (1)
  6. 2017.12.20 [VMware] vSAN 6.2 Essentials 무료 공개
  7. 2017.12.19 [VMware] vExpert 2018 응모개시
  8. 2017.12.05 [VMware] vRealize Suite Lifecycle Manager(vRSLCM) 구성 - 실패담
  9. 2017.11.24 [Microsoft] VMware vSphere on Azure hardware
  10. 2017.11.23 [VMware] vRealize Automation 7.3 (20)
2018.02.17 13:57

[VMware] vSphere 5.5의 지원 종료에 대해서


아직 실환경에서 현역으로 운용중일 vSphere 5.5의 지원 기간이 올해(2018년) 9월 19일로 종료됩니다.


vSphere 5.5 and vSAN 5.5 End of General Support Reminder


정식으로는 "제네럴 지원의 종료-End of General Support (EOGS)"로 이후 2년간의 "테크니컬 가이던스" 기간에 들어가므로 최장으로 2020년 9월 19일까지는 최소한의 지원을 받으며 이용을 할 수 있습니다.


하지만 "제네럴 지원"에서 제공되는 업데이트나 업그레이드, 버그 수정 패치나 보안 패치의 지원을 받을 수 없게되므로 EOGS 이후 발생하는 버그나 보안 취약점에 대한 수정 패치가 제공되지 않을 수 있습니다.


물론 EOGS 전에 vSphere 6.x로 버전업을 하는 것이 최상책입니다만, 당장 대응이 않될 경우는 예산을 포함하여 검토가 필요하리라 생각됩니다.


라이프사이클 매트릭스에 의하면 vSphere(ESXiとvCenter) 5.5를 포함, 아래의 제품도 2018년 9월 18일로 EOGS를 맞이합니다.。

    • Cisco Nexus 1000V
    • Integrated OpenStack 3.1
    • Site Recovery Manager 5.5, 5.8 
    • vCenter Server Heartbeat 6.6
    • vCenter Update Manager 5.5 
    • vRealize Automation 6.2.5 Advanced/Enterprise Edition
    • vSAN 5.5 :)
    • vSphere Data Protection 5.5, 5.8
    • vSphere Storage Appliance 5.5



Trackback 0 Comment 0
2018.02.10 16:01

[VMware] Web Client 접속시 [400] Single Sign-On 에러가 표시됨

얼마전 검증환경의 vCenter에 접속할 수 없게 되었습니다. 외부 PSC와 VCSA의 구성입니다만, Web Client로 접속을 하면 다음과 같은 에러가 표시되며 접속을 할 수 없었습니다. 물론 HTML5 Client에서도 않되더군요.

[400] Single Sign-On 서버에 인증 요구를 송신중 에러가 발생했습니다. – null

 

에러코드와 메시지로 SSO에 문제가 있는 것같아 조사를 했습니다만 뾰족한 해결방법은 찾을 수가 없었습니다. 이런 SSO 관련의 에러의 경우 VCSA와 PSC 사이의 시간차가 원인일 경우가 적지않기에 각각 시간을 확인해 봤습니다만 NTP 관련은 정상이었습니다. 인터넷에서 비슷한 증상을 찾아내어 대응을 해봤습니다만 성과는 없었죠. 더군다나 검증환경이나 백업 데이터가 있을리도 없고... 흐흐 

결국 재설치를 각오하고 마지막으로 실행한 방법이 적중(?)한 것인지 무사히 vCenter에 접속할 수 있게 되었습니다.


우선 새롭게 PSC를 설치했습니다. 설치시 SSO 구성은 문제(?)의 첫 번째 PSC의 SSO에 조인하는 옵션을 지정했습니다. 새로운 PSC를 설치후 VCSA에서 다음의 명령어를 실행하여 PSC의 re-point를 실시했습니다.

root@k-vc02 [ ~ ]# cmsso-util repoint –repoint-psc k-psc04.kiiro.local
Validating Provided Configuration …
Validation Completed Successfully.
Executing repointing steps. This will take few minutes to complete.
Please wait …
Stopping all the services …
All services stopped.
Starting all the services …
Started all the services.
The vCenter Server has been successfully repointed to the external Platform Services Controller k-psc04.kiiro.local.

 

다시금 Web Client에 접속을 하니 정상적으로 로그인 화면이 표시되어 무사히 복구가 되었습니다.  :)


VCSA 상에서 PSC의 정보를 확인해보니 표시되는 PSC는 새롭게 설치한 PSC뿐이더군요.

root@k-vc02 [ ~ ]# /usr/lib/vmware-vmafd/bin/vmafd-cli get-ls-location –server-name localhost
https://k-psc04.kiiro.local:443/lookupservice/sdk

 

SSO 관련의 문제이기에 vCenter의 설정이나 구성에는 영향이 없습니다만, 일단 인벤토리나 분산 가상 스위치 등의 설정 확인후 대응 끝~! :)


참고로 이전부터 동료나 고객에게 종종 "Embedded PSC"와 "External PSC"의 설치 케이스의 질문을 받고는 합니다만 Platform Services Controller (PSC) FAQ」에 명기되어있습니다.

If you want/need Enhanced Linked Mode (e.g. multiple vCenter Servers in the same vSphere SSO Domain) you have to use an external PSC.

그러니까 "Enhanced Linked Mode"를 이용할 경우, "External PSC"를 설치하라고 합니다. 또한...


There could be a product that recommends and external PSC for some reason. But outside of that there is really no benefit to running an External PSC without Enhanced Linked Mode.

"Enhanced Linked Mode"를 이용하지 않을 경우 "External PSC"는 그다지 장점이 없다고 합니다. 

대부분의 경우 "Embedded PSC"로 충분하다는 말이겠죠. 🙂


Trackback 0 Comment 0
2018.02.01 21:50

[VMware] vSAN 6.6 환경에서 ovf 전개가 실패함


얼마전 동료에게 공유받은 내용입니다.


vSAN 6.6 환경에서 ovf 템플릿을 전개하려고 하면 다음과 같은 메시지와 함께 실패할 경우가 있습니다.

The operation is not allowed in the current state (현재 상태에서 허용되지 않는 작업입니다)



■ 원인

vSAN 6.6의 알려진 버그인거 같습니다. 릴리즈 노트를 확인해보면 알려진 문제로 소개되었습니다.


vSAN 클러스터에 OVF 템플릿을 배포하는 경우 vSAN 클러스터에서 DRS를 사용하지 않도록 설정하면 작업이 실패합니다. 다음과 유사한 메시지가 표시될 수 있습니다. 현재 상태에서 허용되지 않는 작업입니다.


이 문제는 6.6.1 에서도 해결되지않은 듯, 6.6.1 릴리즈 노트에도 명기되어있습니다.



■ 해결방법

릴리즈 노트에는 워크어라운드로 DRS를 유효화하라고 쓰여있습니다. 아마도 ovf 전개시 DRS의 추천치를 적용하려고 하기 때문이 아닐까 싶습니다만, 문제는 DRS를 이용하기 위해서는 Enterprise Plus 에디션이 필요하다는 점입니다. Standard 이하의 에디션의 경우는 이 워크어라운드가 그다지 도움이 되질 않습니다.




물론 필요한 ovf 화일을 도입초기의 평가판 라이센스가 유효기간중에 전개하면 될지도 모르겠습니다만... 일단 정규 라이센스를 적용후에는 Web Client에서는 ovf 템플릿을 전개할 수 없을 수 있습니다. 이럴 경우는 ESXi Host Client로 접속하여 ESXi 호스트상에서 전개를 하면 회피할 수 있으니 참고하시길...





Trackback 0 Comment 0
2018.01.06 16:24

[ETC] Intel CPU 버그에 의한 취약점에 대해서

연초부터 심각한 버그로 업계가 들끓고 있네요. :)


보안 취약성에 대해 표준화를 추진하는 CVE (Common Vulnerabilities and Exposures)로 아래의 취약성이 공개되었죠. 취약성의 내용은 CPU 아키텍쳐 버그에 대한 것입니다.



CVE-2017-5753과 CVE-2017-5715는 별명 "Spectre", CVE-2017-5754는 "Meltdown"란 별명으로 둘 다 심각한 버그라고 합니다.


"Meltdown"은 1995년 이후 릴리스된 Intel CPU의 모든 세대가 버그의 영향을 받을 수 있다고 하며 이 버그로 인해 커널 메모리의 정보가 악의를 가진 유저에 의해 참조할 수 있다고 합니다. 이 문제는 CPU 아키텍쳐의 문제이기 때문에 백신이나 암호화로도 취약점을 막을 수 없다고 하는군요. ("Meltdown"は은 AMD사의 CPU에서는 영향이 보고되지 않고 있다고 합니다)


"Spectre"는 임의의 프로그램으로부터 유저 프로그램의 정보를 참조할 수 있는 버그라고 합니다. 둘다 심각한 버그지만 "Meltdown"이 훨씬 문제인거 같네요.


버그도 문제이지만, 버그를 수정할 패치를 적용후 CPU의 성능이 최대 30% 저하되는 검증 결과가 보고되어 파문이 커지고 있으며 Intel사가 버그에 대해 "타사의 CPU에서도 발생할 수 있으며 수정 패치 적용후 성능이 저하되는 문제도 일반 유저에게는 그다지 큰 영향을 끼치지 않는다"라고 발표했습니다만, 반응은 잠잠해지질 않네요.


취약성의 대상이 과거 20년간 릴리스된 모든 CPU이기 때문인지 그 여파는 거대한 듯, Google사나 Microsoft사、Amazon사、RedHat사 등 업계의 대표 기업들이 속속 내용을 공개해고 있습니다.


VMware사도 본 취약성에 대한 보안 권고를 공개하였고 "Spectre"에 대한 패치를 릴리스 했습니다. "Meltdown"에 대해서는 아래의 코멘트만 발표, 수정 패치의 릴리스는 없습니다.


A third issue due to speculative execution, Rogue Data Cache Load (CVE-2017-5754), was disclosed along the other two issues. It does not affect ESXi, Workstation, and Fusion because ESXi does not run untrusted user mode code, and Workstation and Fusion rely on the protection that the underlying operating system provides.


ESXi는 신뢰하지않는 유저 모드의 코드는 실행하질 않고, Workstation과 Fusion은 OS가 제공하는 보호기능에 의존하고 있기 때문에 "Meltdown"의 영향은 받질않는다는거 같네요. :)


Nutanix사 역시 1월 8일 패치 릴리스의 타임라인을 공개하겠다고 발표했습니다.


버그에 대상이 광범위하기 때문에 한동안 주의깊게 이용중인 솔루션, 하드웨어 벤더들의 대응상황을 체크하는 것이 좋을 듯 싶습니다.




Trackback 0 Comment 0
2018.01.03 17:33

[VMware] vSAN 팁 몇가지

이미 10,000사 이상에서 도입되었으며 기세가 점점 거대해지는 vSAN입니다만 고객과 얘기를 해보면 의외로 vSAN에 대한 정보가 부족한 것 같습니다. 왜냐하면 vSAN이란 솔루션의 특징은 알고 있어도 실제로 도입할 경우나 도입후 운용해나갈 경우 주의해야될 점들에 대해서는 잘모르는것 같았기 때문입니다.


따라서 도입시나 운용시 조금은 주의가 필요한 내용을 정리해 봤습니다.(이미 알려진 내용일지 모르겠습니다)


● 하나의 RAID Controller에서는 VMFS과 vSAN FS을 구성할 수 없습니다.

아마 초기 버전의 vSAN 구성에서 있을 수 있는 경우일지 모르겠습니다만, 최근에도 지원 의뢰가 있는거 같습니다. 하나의 RAID Controller상에서 VMFS과 vSAN FS을 구성하는 것은 지원을 받을 수 없습니다. 하나의 RAID Controller에 ESXi용 RAID 1과 vSAN용 non-RAID를 구성하는 것은 피해야 됩니다. 

vSAN을 구성할 경우 ESXi의 부트 디바이스로 내장 SD카드나 SATADOM 같은 플래시 디바이스를 이용하는 것이 일반적이라고 할 수 있습니다만 스크래치 파티션을 로컬 데이터스토어에 보존하기위해 하드 디스크에 ESXi를 설치하고자 할 때는, ESXi용으로 RAID Controller를 준비, vSAN용 RAID Controller를 추가로 준비해줘야 됩니다.


● 부트 디바이스로 내장 SD 카드를 이용할 경우, 스크래치 파티션을 고려해야 됩니다.

내장 USB 메모리나 SD 카드에 ESX를 설치할 경우 로그는 RAM 디스크상에 보존됩니다. 단지 RAM 디스크상에 보존되기 때문에 ESXi 호스트를 재기동하면 로그는 사라지고 이로인해 장해의 원인 규명이 힘들어지게 됩니다.


이를막기위해서는 스크래치 파티션을 구성할 필요가 있습니다만, vSAN에서는 ① ESXi 호스트의 로컬 데이터스토어를 이용하든지 ② NFS의 디렉토리를 호스트별로 준비하는 방법뿐입니다. 단지 ①의 경우는 위의 팁에서 소개를 했듯이 RAID Controller를 추가로 준비해야되죠. ②역시 NFS 디렉토리를 준비해줘야 됩니다.


지금까지의 경험상, 스크래치 파티션 때문에 ①이나 ②를 준비하는 사례는 거의 없었습니다. 때문에  Remote Syslog와 Network Dump를 구성하는 방법이 가장 무난할지 모르겠습니다. 단지 이것도 모든 로그를 보존할 수 있는 것이 아니기 때문에 vSAN을 도입할 경우는 돈을 들여 스크래치 파티션을 준비하든지 syslog 만을 준비하여 최소한의 로그라도 보존을 하든지를 고려해야될 필요가 있습니다. 개인적으로는 vRealize Log Insight에 로그를 전송하는 것을 추천하고 싶네요. 

 


● vsanDatastore의 미사용영역을 항상 30% 확보하도록 합니다.

운용시작후 vsanDatastore의 사용영역이 전체영역의 80%를 넘지않도록 주의하는 것은 널리 알려져 있습니다. (SIer에 따라서는 70%를 이용가능한 최대영역으로 안내를 하는 경우도 있죠)

이와 비슷한 내용일지 모르겠습니다만 vsanDatastore의 미사용영역은 항상 30% 정도 확보해두는 것을 추천합니다. FTT가 다른 복수의 스토리지 정책을 이용는 환경에서 스토리지 정책을 변경할 경우, 일시적으로 변경전의 스토리지 정책과 변경하는 스토리지 정책이 공존하게 됩니다.


예를들어 가상머신에 FTT=1의 스토리지 정책이 적용되어있다고 하죠 이 가상머신의 스토리지 정책을 erasure coding의 스토리지 정책으로 변경할 경우, 데이터의 변환이 끝날 때까지 RAID 1와 RAID 5가 공존하게 됩니다. RAID 5의 스토리지 정책으로 변경중 vsanDatastore의 영역이 부족하면 정책 변경은 실패합니다.


따라서 vsanDatastore의 미사용영역은 항상 30% 정도 남겨두도록 하는 것을 추천합니다.



● 최소 구성은 3 호스트, 하지만 4 호스트를 추천합니다.

네, 알고 있습니다. vSAN의 최소 구성의 호스트 수는 3 호스트입니다.(ROBO나 2 호스트 다이렉트 접속 구성을 제외) 지원도 문제없이 받을 수 있습니다.


하지만 3 호스트면 가상머신의 가용성 유지에 불안한 점이 있습니다. 특히 운용중의 리스크가 커지게 됩니다. 3 호스트 구성시는 1 호스트를 유지보수하더라도 FTT=1를 충족할 수 없게되어 가용성을 확보할 수 없게 되기 때문이죠.


1 호스트 유지보수중 다른 호스트에 장해가 발생할 경우는 거의 드물다고요? 이렇게 생각하시는 분들, 장해가 발생한 뒤에는 늦습니다. 저같으면 싫습니다. 매번 두근두근하면서 패치 적용하는 건... 흐흐 :)


호스트 장해에 대한 대비는 물론이지만, 운용시 유지보수의 편리성을 생각한다면 vSAN 클러스터는 최소 4 호스트 구성을 추천합니다.


 


● “중복제거와 압축” 기능의 유효시, 디스크 단위의 삭제는 않됩니다.

All-Flash 모드의 vSAN을 도입하여 ”중복제거와 압축”기능을 검토하고 계신 분들은 “중복제거와 압축” 기능은 디스크 그룹 단위로 구성된다는 것에 주의하시길... 디스크 그룹 단위로 구성이 되기 때문에 capacity SSD에 장애가 발생하면 해당 디스크 그룹을 일단 삭제, SSD 교환후 새롭게 작성을 해야됩니다.


운용을 시작하여 일정 시간이 경과후 발생하면 의외로 번거로운 문제가 될 수 있으므로 "중복제거와 압축"기능을 검토할 경우는 운용면에서의 부하도 충분히 검토를 하시길 바랍니다.


● vSAN을 구성하면 ESXi 호스트의 reboot는 시간이 걸립니다.

거의 포스팅에서도 소개를 했습니다만, vSAN의 호스트는 부팅시 vSAN 메타 데이터 테이블을 재작성합니다. (KB에 의하면 디스크 그룹당 최장 1시간이 걸릴 수도 있다고 합니다)

때문에 non-vSAN의 ESXi 호스트보다 시작에 시간이 걸립니다. 기동에 실패하여 에러가 표시되기 전까지는 인내심을 갖고 기다리기 바랍니다.


ESXi 호스트의 시작이내 재시작시에는 DCUI나 원격 콘솔에서 부팅 프로세스를 확인하는 것을 추천합니다.


● 가동중에 디스크를 뽑는 것은 장해 테스트라고 할 수 없습니다.

vSAN 도입직후 대부분 장해 테스트를 하실겁니다. 네트워크나 전원, 혹은 호스트 장해 테스트를 하시겠죠. 물론 디스크(cache 티어나 capacity 티어) 장해에 대해서도 테스트를 하실겁니다. 단지 디스크는 다른 장해 테스트와는 달리 간단히 장해 상태를 만들 수 없죠. 결국 가동중인 디스크를 뽑는 것이 일반적으로 이루어지고 있지 않을까 합니다.(과거에 저도 장해 테스트로 가동중인 디스크를 뽑는 방법을 소개한 적이 있습니다... )


이건 absent 상태가 되어 제대로 된 장해 테스트라고 할 수 없습니다.(물론 이 상태에서 ClomRepairDelay의 타임아웃이 되면 데이터의 동기가 실행되므로 결과적으로는 같을지 모르겠습니다...)


그렇다면 어떻게 해야되느냐...? Failure Testing을 이용하면 됩니다.


VMware 공식 문서인 이 Failure Testing에는 호스트 장해, 디스크 장해시의 동작에 대한 설명과 함께 디스트 장해를 발생시킬 수 있는 방법도 소개하고 있습니다.

/usr/lib/vmware/vsan/bin/vsanDiskFaultInjection.pyc


위의 명령어를 이용하면 간단히 디스크를 Permanent Error 상태로 만들 수 있습니다. 장해 테스트를 하실 경우는 꼭 이용해보세요.


음... 원래 HCI의 디스크 장해 테스트의 목적은 "장해가 발생해도 서비스(가상머신)는 정지하지 않는 것을 확인"하는 것이라고 생각합니다만, 이상하게 "가상머신의 가용성을 어떻게 수복하는가"를 확인하는 쪽으로 바뀐 것 같네요. :)



● 격리 어드레스 변경후는 vSphere HA를 재유효화해야 됩니다.

이것도 이미 알고 계시리라 생각됩니다. vSAN을 구성하면 하트비트가 관리 네트워크로부터 vSAN 네트워크로 변경되죠. 따라서 호스트 격리시에 이용되는 격리 어드레스도 변경해줘야 됩니다. 격리 어드레스는 vSphere HA의 고급설정에서 변경이 가능합니다만 변경후 추가 작업이 필요합니다.


격리 어드레스의 변경은 vSphere HA를 일단 무효후 다시금 유효화해주지 않으면 반영되지 않습니다. 격리 어드레스를 변경한 뒤에는 반드시 vSphere HA를 재유효화해 주는 것을 잊지마세요. :)



 VCSA을 Easy Install로 설치하였을 경우는 vSAN 구성후 스토리지 정책을 적용해주세요.

vSAN 6.6부터 vSAN 클러스터상에 VCSA를 설치하는 것이 무지하게 편해졌습니다. VCSA 설치시 "새로운 vSAN 클러스터에 포함되는 ESXi 호스트에 설치" 옵션을 선택해주기만 하면 되죠. 간단히 싱글 호스트에 일시적으로 vsanDatastore를 구성, VCSA를 설치해줍니다. VCSA가 설치되면 남은 ESXi 호스트를 vSAN 클러스터에 추가해주면 vSAN 구성이 끝납니다. 간단하죠. :)

하지만 잘 생각해보세요. vsanDatastore 상에 가상머신(VCSA)를 설치했다는 말은 자동적으로 vSAN Default Storage Policy가 적용된다는 말이죠. vSAN Default Storage Policy는 FTT=1에 Stripe=1입니다. 이말은 최소한 3 호스트가 필요하다는 말이죠. 하지만 VCSA를 설치한 시점에서는 1 호스트밖에 없으므로 VCSA는 스토리지 정책이 적용되지 않은 상태가 됩니다.

 

Easy Install로 VCSA를 설치했을 경우는 vSAN 구성이 끝난 뒤에 잊지말고 스토르지 정책을 적용해주세요. 

 



● 컴포넌트 사이즈에는 최대치가 있습니다.

vsanDatastore에는 최대 62TB의 vmdk 화일을 작성할 수 있습니다. 최대 사이즈는 다른 스토리지와 다를바없습니다만 vSAN의 경우는 조금 특수합니다. vSAN은 최종적으로 capacity 디스크에 "컴포넌트"로 저장이 됩니다. 이 컴포넌트에는 최대 사이즈가 있어, 255GB가 최대 사이즈입니다. 255GB를 넘는 화일은 자동적으로 분할되어 복수의 capacity 디스크에 저장이 됩니다. 컴포넌트는 분할되어 각 정보는 메타데이터에 의해 관리됩니다. 예를들어 vmdk 화일 사이즈가 1TB의 경우, capacity 디스트에 저장되는 컴포넌트 수는 4 이상이 됩니다. FTT=1의 경우 8 이상이 되는거죠. 참고로 오브젝트는 분할되지 않습니다.

위의 그림처럼 가상머신에 3개의 vmdk 화일이 있다고 하죠. 스토리지 정책은 FTT=1입니다. 하드 디스크 1과 2는 100GB 정도입니다. 이에비해 하드 디스크 3은 약 400GB 정도됩니다. 하드 디스크 1과 2는 FTT=1의 정책이 적용되어 각각 2개의 컴포넌트가 각각 다른 호스트상에 저장되게 됩니다.

 

하드 디스크 3은 400GB 이므로 컴포넌트의 최대 사이즈를 넘습니다. 따라서 RAID 1의 안에 각각 RAID 0로 3개의 컴포넌트로 분할되어 저장되어 있는 것을 확인할 수 있습니다.(몇개의 컴포넌트로 분할될지는 화일의 사이즈에 따라서 달라집니다)


재미있죠? :)


거대한 가상머신을 작성할 경우는 이 컴포넌트의 구성이나 배치도 고려하는 것이 좋습니다.



 

이외에도 팁이 있으리라 싶습니다만, 생각나는건 이정도네요. vSAN의 도입이나 운용에 조금이나마 도움이 되었으면 합니다. :)

Trackback 0 Comment 1
2017.12.20 19:05

[VMware] vSAN 6.2 Essentials 무료 공개

vSAN계에서는 유명한 인물이 2명있습니다. Cormac Hogan씨와 Duncan Epping씨가 바로 그 2명입니다.

2명 모두 VMware사의 SABU(Storage & Availability Business Unit) CTO면서도 vSphere Clustering관련, 스토리지나 vSAN 관련의 유익한 정보를 많이 소개해주고 있어 항상 도움을 받고있죠. 


이 두명이 집필한 Essential Virtual SAN (VSAN): Administrator’s Guide to VMware Virtual SAN의 vSAN 6.2 대응판을 무료로 공개해주었습니다.

Holiday gift: vSAN Essentials book available for free

vSAN Essentials e-book is now free

 

300 페이지에 걸쳐 아키텍쳐를 시작으로 설치, 스토리지 정책, 관리/운용 그리고 트러블슈팅까지 vSAN의 모든 것을 커버하고 있습니다. vSAN 6.2 대응이라 조금은 오래된 내용일 듯 보일지도 모르겠습니다만, 대부분은 지금도 충분히 활용할 수 있는 내용입니다. vSAN 인프라의 관리자분들이나 vSAN 도입을 검토하고 계신 분들에게는 필독서라고 생각합니다.

 

다시 한번 Cormac Hogan씨와 Duncan Epping씨에게 감사를 드리고 싶네요. :)


Trackback 0 Comment 0
2017.12.19 13:03

[VMware] vExpert 2018 응모개시

vExpert 2018의 응모가 시작되었습니다.

vExpert 2018 Applications are Now Open

 

올해부터는 vExpert 전용 포털이 준비되어 응모도 vExpert 전용 포털에서 이루어집니다.

 

vExpert이 되면 Expert 전용 Slack 채널 참가를 비롯하여 vExpert 인증서, 1년간 이용할 수 있는 평가 라이센스 등이 VMware사로부터 제공되며 각 3rd 파티에서 제공되는 각종 혜택이 있습니다.

Andrea Mauro씨의 정리 : vExpert 2017 Benefits


응모기간은 2017년 12월 19일부터 1개월간이며 수상자 발표는 2018년 2월 16일로 예정되어있습니다.

 

2017년 VMware 제품이나 테크놀러지의 보급에 공헌한 분이나 VMware Love인 분들은 꼭 응모해보세요. :)


Trackback 0 Comment 0
2017.12.05 23:21

[VMware] vRealize Suite Lifecycle Manager(vRSLCM) 구성 - 실패담

음... 너무 까분거 같네요. 쩝... 


얼마전에 vRSLCM의 구성을 소개하면서 기존의 vRA를 추가했었습니다. 아무 생각없이 여기에 다른 제품을 추가했습니다. 


결과는...  2/3 성공, 1/3 실패였습니다.


왜 실패를 했는지를 포함, 간단히 제품 추가에 대해서 소개를 하겠습니다.


vRealize Suite Lifecycle Manager(vRSLCM) 설치
vRealize Suite Lifecycle Manager(vRSLCM) 구성



우선 지난번에 vRA를 추가한 환경에 새롭게 제품을 추가하기로 했습니다.



① "Manage Environments"를 클릭, 지난번에 추가한 vRA의 타일 메뉴로부터 "Add Products"를 실행합니다.


② 왠지 그냥 CEIP를 참가해버렸습니다. 흐흐


③ vRA이외의 나머지 제품을 모두 선택했습니다. 선택후 "Create Environment"를 클릭... 제대로 진행된다면 vRealize Business for Cloud, vRealize Log Insight, vRealize Operations Manager가 설치될겁니다.


④ 설치에 필요한 정보를 입력합니다. 우선 vRealize Business for Cloud의 설치에 필요한 정보를 입력하고...


⑤ 이번에는 vRealize Log Insight의 정보...


⑥ 마지막으로 vRealize Operations Manager의 설치 정보를 입력후 "NEXT"를 클릭....


⑦ 구성의 유효화 체크에 문제가 없다면 "SUBMIT" !


⑧ 설치가 시작됩니다.


⑨ "Request"에서 진행중인 job을 클릭하면...


⑩ 설치 상태를 확인할 수 있습니다.


⑪ 의외로 아무런 문제없이 진행되길래 '간단~ ' 흥얼거렸더니만...


⑫ 실패했습니다. 쩝... 원인은 vRealize Business for Cloud의 라이센스 추가에서 실패한거 같았습니다. 가만히 생각을 해보니 vRealize Business for Cloud의 라이센스 지정하는 부분이 없었습니다. --; 실패하고보니 이 vRSLCM는 일단 설치가 시작되면 job를 취소할 수 없는걸 알았습니다. 정보도 그다지 많지않고 말이죠... 음...


⑬ 불행중 다행(?)이랄까 vRealize Business for Cloud이외의 두 제품은 제대로 설치가 된 거 같았습니다.


⑭ 설치된 각 제품은 "Manage Environments"에서 vRA과 동일하게 상세정보나 컴포넌트의 추가, 버전의 호환성 확인이 가능합니다.


음... 이 vRSLCM, 확실히 vRealize 제품의 라이프사이클를 관리 부분에서 각 제품의 버전을 확인한다든지 호환성이 있는 컴포넌트를 추가할 수 있는 것은 설치의 포스팅에서도 언급했듯이 매력적입니다만... job(요청)에 대한 부분은 로그 확인이나 재실행 같은 조작의 부분을 조금 더 개선해줬으면 하네요... :)


   









Trackback 0 Comment 0
2017.11.24 12:45

[Microsoft] VMware vSphere on Azure hardware

2017/12/23 updated


두 회사, 협의를 한거 같네요.

VMware사는 얼마전 "지원을 하지않을 것"이라는 발표내용을 "지원을 한다"고 내용을 변경했습니다.

Recently, Microsoft announced a preview of VMware virtualization on Azure, a bare-metal solution that is stated to run a VMware stack on Azure hardware, co-located with other Azure services in partnership with VMware-certified partners. This offering is being developed independent of VMware, however it is being offered as a dedicated, server-hosted solution similar in approach to other VMware Cloud Provider Partners (VCPP). The deployment is on VMware certified hardware consisting of FlexPod. VMware is in the process of engaging with the partner to ensure compliance and that the appropriate support model is in place. 

VMware vSphere on Azure 서비스는 다른 VCPP(클라우드 제공 파트너)와 같은 방식의 전용 하드웨어를 이용한 호스팅 서비스로써 지원을 한다는 내용입니다.


한편 마이크로소프트사도 동일한 내용을 소개하며 Cisco사와 NetApp사의 컨버지드 솔루션인 Flexpod를 제공 기반으로 이용할 것이라고 밝혔습니다.

To enable this solution, we are working with multiple VMware Cloud Provider Program partners and running on existing VMware-certified hardware. For example, our preview hardware will use a flexpod bare metal configuration with NetApp storage.

 

흐음... 이걸로 일단은 두 회사의 관계가 진정된거 같네요. :)






작년 AWS의 하드웨어 상에서 vSphere 환경을 이용할 수 있는 VMware Cloud on AWS가 발표되어, 올해 미국 서부 리전에서 처음으로 서비스가 개시되었죠.


Azure에서도 동일한 내용의 서비스를 제공한다는 발표가 있었습니다.


Transforming your VMware environment with Microsoft Azure



위의 발표에 의하면 Azure 하드웨어상에서 완전한 vSphere 환경을 제공한다 고합니다.

Today, we’re excited to announce the preview of VMware virtualization on Azure, a bare-metal solution that runs the full VMware stack on Azure hardware, co-located with other Azure services.

 

아마도 온프레미스의 vSphere 환경을 Azure에 이행할 수 있도록 일시적인 용도의 서비스가 아닐까 싶습니다. 왜냐하면 "Azure 하드웨어상에서 vSphere 환경을 제공"한다는 내용이 메인이라기보다는 "vSphere 환경에서 가동중인 워크로드를 Azure에 이행"하는 것이 주요목적인 듯 하기 때문입니다.


위의 발표에 대해 2일후 VMware사에서도 발표를 했습니다만 뉘앙스가 다릅니다.

VMware – The Platform of Choice in the Cloud

Recently, Microsoft announced preview of VMware virtualization on Azure, a bare-metal solution that is stated to run a VMware stack on Azure hardware, co-located with other Azure services in partnership with VMware-certified partners. No VMware-certified partner names have been mentioned nor have any partners collaborated with VMware in engineering this offering.

This offering has been developed independent of VMware, and is neither certified nor supported by VMware.

내용인즉근 AWS처럼 두회사가 공동으로 서비스를 개발한 것이 아니고 마이크로소프트사가 단독으로 서비스를 제공하고 있기 때문에 VMware사의 인증도 받지않았으며 지원도 받을 수 없다는 것입니다. 흐음...


두 회사의 발표 내용을 정리하자면... 

Azure에서도 베어메탈 기반의 vSphere 환경을 이용할 수 는 있다. 하지만 VMware사의 지원을 받을 수 없으니 서비스가 개시되어도 이행 목적이 아닌 실환경의 가동은 신중히 검토해야된다... 가 아닐까 싶네요.


Trackback 0 Comment 0
2017.11.23 12:09

[VMware] vRealize Automation 7.3 (20)

은근슬쩍 vRA의 버전을 7.3으로 바꿨습니다. :)


(0) vRA 개요

(1) vRA 구성요소

(2) vRA 설치 - vRA어플라이언스

(3) vRA 설치 - IaaS서버

(4) vRA 초기설정 - 테넌트 작성

(5) 테넌트 구성 - AD

(6) 엔드포인트 작성

(7) 데이터 콜렉션과 패브릭 그룹 작성

(8) 머신 접두사와 네트워크 프로화일 작성

(9) 비지니스 그룹과 예약 작성

(10) 블루프린트 작성

(11) 서비스 카탈로그 작성

(12) 블루프린트의 요구

(13) 승인 정책의 설정

(14) 커스텀 속성(사용자 지정 속성)의 설정

(15) vRO 엔드포인트 작성

(16) NSX와의 통합

(17) 가상머신의 임포트

(18) 가상머신의 해제

(19) Nutanix 엔드포인트 작성

(20) vROps와의 통합


이번에는 vROps와의 통합에 대해서 소개를 하겠습니다.

아시다시피 vROps는 성능감시및 인프라의 수용능력이나 장애 예측을 제공하는 툴이죠. vROps와의 통합을 하므로써 vRA는 전개한 가상머신의 헬스 뱃지를 아이템 상에 표시를 할 수 있게됩니다. 이용자는 자신의 아이템 화면에서 가상머신의 건강상태를 한눈에 파악할 수 있죠. vROps는 vRA의 테넌트나 비지니스 그룹, 블루프린트 등의 오브젝트를 대쉬보드에 표시할 수 있게됩니다. 어느 테넌트, 어느 비지니스 그룹의 건강상태가 좋은지 나쁜지, 어떤 블루프린트가 인기가 있는지 등을 파악할 수 있죠.


vROps 6.5까지는 vRA를 모니터링하기 위해서는 관리팩을 설치해야되었습니다만, 6.6부터는 vSAN과 동일하게 vRA도 관리팩이 통합되었습니다. 따라서 관리팩을 설치할 필요없이 vRA 접속정보를 등록해주기만 하면 됩니다.


(20) vROps와의 통합

① vRA 포털에 테넌트 관리자로 접속을 하여 [관리] → [리소스의 재이용] 순으로 클릭을 합니다.


② [메트릭 프로바이더]로부터 "vRealize Operations Manager 엔드포인트"를 선택, 다음의 vROps 정보를 입력합니다.

    • URL : https://vROps/suite-api

    • 유저명 : vROps 관리자 계정

    • 패스워드 : vROps 관리자 패스워드


③ [접속 테스트]를 실행하여 정상적으로 접속되는 것을 확인후 [보존]을 클릭합니다.


④ vROps의 증명서를 신뢰해주시면 설정은 끝입니다. 


⑤ vROps로부터 가상머신의 헬스 정보가 표시됩니다. 위의 화면처럼 가상머신을 디플로이하면 [리소스의 재이용]의 [디플로이] 메뉴에 헬스 정보가 표시되기 시작합니다.


⑥ 이번에는 이용자로 접속을 해봤습니다. 자신의 아이템을 선택하면 화면 오른쪽 하단에 가상머신의 건강상태를 알 수 있는 헬스 뱃지가 표시되는 것을 확인할 수 있습니다.


이걸로 vROps와의 통합은 끝입니다. 간단하죠? vROps쪽에서 vRA의 오브젝트를 모니터링하기 위해서는 vROps에서 vRA의 솔루션을 설정해줘야 됩니다. 이건 나중에 소개를 하도록 하죠. :)








Trackback 0 Comment 0