Virtual Hive

(1) vSAN 파일 서비스의 구성 (2) 파일 공유의 작성과 이용 (3) 장애 발생 시의 움직임 이번에는 장애 발생 시의 동작에 대해서 소개를 하겠습니다. ■ ESXi 호스트의 장애 우선은 ESXi 호스트 장애 시의 동작에 대해서 살펴보겠습니다. vSAN File Services 구성에 대한 소개에서 설명은 했습니다만 FSVM은 EAM（vSphere ESX Agent Manager）에 의해 설치되어 관리되기 때문에 vSphere HA나 DRS 등의 영향을 받지 않습니다. 따라서 ESXi 호스트가 정지해도 FSVM는 페일오버하지 않습니다. 파일 서비스를 구성한 ESXi 호스트에는 1대의 ESXi 호스트가 이른바 헤드 노드가 됩니다. 당연할지 모르갰습니다만 ESXi 호스트의 장애가 헤드 노드에서 일어났는지..

※ 조금 시간이 지난 내용일지 모르겠습니다. 작년에 vSAN에 대한 팁을 몇가지 소개한 적이 있습니다. 내용중에 vSAN 도입후 장애 테스트를 실행할 경우는 가동중인 디스크를 해제하지말고 "vsanDsikFaultInjection.pyc"를 이용하도록 소개를 했었습니다. 이 스크립트를 실행하면 캐시/용량 디스크의 장애 시험을 할 수 있죠. 제 자신도 vSAN을 도입한 뒤에는 "vsanDsikFaultInjection.pyc"를 이용하여 디스크의 장애 시험을 행하고 있습니다만, vSAN 6.5부터 예상 밖의 문제에 부딪혔습니다. 뭐가 예상 밖이냐면 말이죠, 캐시 디스크에 장애를 일으키면 디스크 그룹이 보이지않게 된다는 겁니다. 이건 문제입니다. 디스크 그룹이 않보이면 뭐가 문제냐면 말이죠, 그 디스크 그룹..

2017/12/5 Updated커뮤니티 회원님에게 좋은 정보를 들었습니다. 어쩌면 이 KB가 해결방법인지 모르겠네요. 다음에 또 다시 발생한다면 써봐야겠네요.A virtual machine on a vSAN datastore might be renamed when vSAN becomes inaccessible 얼마전 vSAN을 도입한 고객사에서 장애가 발생했습니다. 4 호스트의 소규모 구성이었습니다만 운없게 2 호스트가 1시간안에 멈춰버린거 같았습니다.(FTT=1임에도 불구하고 "접근불가" 상태의 가상머신이 많았기 때문이죠) 장애 발생후 호스트는 복구를 했으며 vSAN 클러스터의 헬스 상태나 오브젝트의 헬스 상태도 정상이었도 모든 가상머신도 정상적이었던거 같습니다.(표면적으로는 말이죠) 몇시간 뒤에 고객..

VSAN을 구성하게되면 클러스터간의 하트비트가 관리네트워크로부터 VSAN네트워크로 변경되게 됩니다.때문에 이미 HA가 구성되어있는 vSphere 환경에서 VSAN을 구성하려면, 일단 HA를 무효화후 VSAN을 구성, 다시금 HA를 유효화해줘야 합니다. 설정자체는 문제가 없습니다. 전혀 문제될게 없죠. 문제는 VSAN 환경이란 겁니다. 일반적인 클러스터 구성시는 하트비트용으로 1.데이터스토어 2.격리어드레스를 이용하여 장애를 판단하게 됩니다.하지만 VSAN 환경은 1.데이터스토어가 없을 경우가 많습니다. 왜냐구요? 비싼 외부 스토리지를 대신하기위해 VSAN을 구성했잖아요... 흐흐 때문에 장애의 판단은 2.격리어드레스뿐이 됩니다.(외부 스토리지가 존재하지않는다면) 하지만...격리어드레스는 일반적으로 관리네..

Virtual SAN은 '스토리지 정책'이외에 하드웨어의 장애발생시 다음 동작이 실행되도록 설계되어있습니다. 네트워크, 네트워크 어댑터나 ESXi 호스트에 장애가 발생했을 경우HDD나 SSD 혹은 RAID컨트롤러나 HBA등 스토리지 컨트롤러에 장애가 발생했을 경우 네트워크, 네트워크 어댑터나 ESXi 호스트에 장애가 발생했을 경우는 60분후에 데이터의 재동기가 이루어집니다. 이것을 Absent 라고 합니다. 장애가 발생했는데도 불구하고 60분후에 데이터의 재동기가 이루어지는 것은, 60분이내에 장애가 복구될 수 있을 가능성이 있기 때문이죠. HDD나 SSD 혹은 RAID컨트롤러나 HBA등 스토리지 컨트롤러에 장애가 발생했을 경우는 즉시 데이터의 재동기가 이루어집니다. 이것을 Degraded라고 합니다. ..

NexentaStor를 iSCSI 스토리지로 이용하고 있는 고객 인프라에서 얼마전 장애가 발생했습니다.상황은 다음과 같았습니다.ESXi는 물론 가상 머신에 접속불가NexentaStor 컨솔 접속 불가, SSH 불가, 웹관리툴인 NMV 접속불가하지만, ping 정상 소통... 결국 서버를 강제 셧다운 -> 기동으로 복구했습니다만, messages에 아무런 로그도 남아있지 않았습니다. 근본적인 원인을 모르는 상황이기에 복구가 되었어도 찜찜했죠. 복구후 SSH로 접속해서 이런 저런 로그를 살피다보니 nms.log 화일에 다음과 같은 에러가 남아있더군요. fault trigger 'memory-check (E3)' failed 2 times, 3 left until the configured maximum is..

근래들어 가상화 기술이 각광을 받고 있습니다. 옆나라 일본에서는 2006년을 기점으로 매년 35%이상 증가하리라는 예측이 나올 정도로 급격히 확산되고 있는 이 가상화 기술에는 "서버의 가상화", "스토리지의 가상화", "PC(데스크탑)의 가상화", "어플리케이션의 가상화" 등이 여러 종류가 있으며 이중에서도 가장 활발한 움직임을 보이고 있는 것은 "서버 가상화"입니다. "서버의 가상화"는 VMware를 선두로 Microsoft, Citrix, Oracle, Sun, Virtual Iron, Parallels 등 많은 벤더들이 이미 제품을 투입한 상태로, 조금이라도 높은 가상화 시장의 점유율을 차지하기 위해 보다 안정된 시스템, 관리툴을 개발에 막대한 자금을 투입하고 있습니다. 그덕분에 "서버의 가상화" ..