ESXi host loses connectivity to a VMFS3 and VMFS5 datastore (2113956)

https://kb.vmware.com/s/article/2113956

아마 VMware KB 중에 가장 많이 보셨던 KB 중 하나가 아닐까 합니다. 길게 설명은 되어있는데.. 요약하면 vmkernel.log 에서 아래 메세지의 발생과 함께, VMFS datastore 로의 Connectivity 에 문제가 생기는 이슈이죠. 아래로그는 구글에서 발췌한 것입니다만, 경험이 있으신분은 아마도 익숙하실겁니다. 

2015-04-11T14:12:56.482Z cpu3:38545)HBX: 1929: ATS Miscompare detected between test and set HB images at offset 3387392 on vol ‘53003a80-2832c375-6a9a-0025b5a102cc’.

2017-10-25T22:18:46.916Z cpu4:66250)NMP: nmp_ThrottleLogForDevice:3617: Cmd 0xf1 (0x439d002e7400, 67860) to dev "naa.60060160a40ed018f48eee4fc74527f6" on path "vmhba66:C2:T1:L0" Failed: H:0x0 D:0x2 P:0x0 Valid sense data: 0xe 0x1d 0x0. Act:NONE

DISCLAIMER : 아래의 내용은 제가 이해하는 내용이기 때문에, official 한 것으로 받아들이시면 곤란하고, 참고만 하시기 바랍니다. This is my understanding. not from VMware, please use this as reference only.

위 로그에서 Cmd 0xf1 부분은 Cmd 0x89 로 보셨던 분들도 많으실텐데요, 제가 알기로는 0xf1 은 EMC 에서 사용하는 ATS Compare 코드로 알고 있습니다. SCSI opcode 에서 ATS 가 표준코드로 등록된 지가 그렇게 길지 않아서 벤더 자체적으로 ATS 코드를 구현해서 쓰는 경우도 있었던것 같습니다. 현재는 SCSI opcode 중에서 89 가 COMPARE AND WRITE 로 SCSI T10 표준으로 정해져있습니다. 따라서 대부분은 0x89 로 보실겁니다.

In the initial VAAI release, the ATS primitives had to be implemented differently on each storage array, requiring a different ATS opcode depending on the vendor. ATS is now a standard T10 SCSI command and uses opcode 0x89 (COMPARE AND WRITE).

일단 VMFS3/5 에서 발생하는것으로 알려져있고.. VMFS6 에서도 일부 발생한다는 사례가 있는것으로 알려져있습니다. VMFS6 의 경우 ESXi 6.5 Patch2 에서 개선된 것으로 알고 있습니다. (https://kb.vmware.com/s/article/2151104)

그리고 workaround 로 ATS heartbeat 을 disable 하라고 되어있습니다.

To resolve this issue, revert the heartbeat to non-ATS mechanisms by disabling ATS heartbeat on ALL hosts sharing the datastore where these errors are seen.

여기서 많이들 오해하시는 것이.. ATS Heartbeat 을 disable 하는 것이 ATS 전체를 disable 하는 것으로 오해되는 경우가 있습니다. 그렇다면 일단 ATS 가 무엇인지 한번 알아볼 필요가 있겠습니다.

VAAI 에서 Block 스토리지를 위해 포함된 기능은 크게 3가지입니다. 2번/3번은 오늘 글에서는 상세한 설명을 생략하겠습니다.

1. Atomic Test & Set (ATS) – 0x89 – HardwareAcceleratedLocking
2. XCOPY (Extended Copy) – 0x83 – HardwareAcceleratedMove
3. Write Same (Zero) – 0x93 – HardwareAcceleratedInit

이중 ATS 의 경우는 주로 효율적인 Lock 을 위해 사용됩니다. Lock 이 필요한 이유는 VMFS 가 Clustered File system 이기 때문입니다. VMFS 같은 shared 가 가능한 시스템은, 하나의 호스트에서 볼륨의 메타데이터를 업데이트를 할 필요가 있을 때, 다른 호스트에서 동시에 변경할 수 없도록 반드시 Lock 을 잡아야합니다. Lock 을 잡지 않고 다수의 호스트에서 메타데이터 업데이트를 실행한다면 모든 호스트에서 해당 볼륨에 대해 같은 메타데이터를 보고 있다고 확신할수가 없는것이죠. 즉 메타데이터의 무결성을 위해 Locking 메카니즘을 필요로 합니다.

ATS 이전에는 VMFS volume 에 대해서 Lock 을 잡을 때 SCSI Reservation 방식을 사용했습니다. SCSI Reservation 의 경우 문제가 되는 부분이 메타데이터의 업데이트만 필요한데 볼륨 전체의 Lock 을 잡는다는 것이죠. 하나의 호스트에서 완전한 Lock 을 잡기 때문에 그 동안에서는 다른 호스트에서의 접근이 불가능합니다. 이러한 특성으로 인해, Contention 들도 발생하고, VMFS 볼륨의 확장에 제약이 있었습니다. 

ATS 는 SCSI Reservation 으로 인한 문제점을 해소하고자 나온 방식 입니다.  Lock 을 잡을 때 전체 볼륨의 Lock 을 잡는것이 아니라, 메타데이터 업데이트에 필요한 영역만 Lock 을 잡는 것이죠. 

Metadata 가 업데이트 되는 경우는 볼륨내에 파일이 생기거나, 지워지거나 변경되는 경우에 업데이트를 필요로 합니다. 그외의 경우도 있는데 아래 링크를 참조 하시기 바랍니다.

https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.storage.doc/GUID-7A385576-9434-432E-92C4-51E26A4761AA.html

그리고 Lock 을 잡기 위해서는 아래와 같은 절차를 필요로 합니다.

1. Acquire on-disk locks
2. Upgrade an optimistic lock to an exclusive/physical lock
3. Unlock a read-only/multiwriter lock
4. Acquire a heartbeat
5. Clear a heartbeat
6. Replay a heartbeat
7. Reclaim a heartbeat
8. Acquire on-disk lock with dead owner

저도 깊게 알지는 못해서 상세히 알려드리기는 좀 어렵구요;; ATS 가 어떤 부분에 사용되는지만 알아보면

vSphere 4.0 에서는 VAAI 가 없었기 때문에 SCSI Reservation 이 1~8 까지 모든영역에 대해서 사용되었습니다.

vSphere 4.1 에서는 1과 2 에 대해서 ATS 가 사용되도록 개선되었습니다. 더 상세히 따지자면, 1과 2에 대해서, 그 마저도 Contention 이 발생하지 않을 때에만, ATS 가 사용됩니다. 엄밀히 말하면 VMFS3 데이터스토어에서 그렇습니다. 만약 ATS 를 사용해서 Lock 을 잡지 못한다면 SCSI Reservation 을 사용합니다. 그래서 VMFS3 는 ATS+SCSI 방식이라고 이야기합니다.

VMFS5 에서는 1~8 까지의 모든 과정에서 ATS 를 사용합니다. SCSI Reservation 이 더이상 사용되지 않는 것이지요.  그래서 ATS Only  라고 이야기합니다. Contention 이 있다하더라도 ATS 를 사용하도록 Try 합니다. 

즉 ATS 를 Disable 한다는 의미는 1~8번까지의 과정을 ATS 가 아닌 SCSI Reservation 을 사용하도록 Revert 한다는 의미를 가집니다. 하게 되면 필연적으로 성능저하가 발생하게 되어있습니다. 그래서 VMware 나 스토리지 벤더에서도 ATS 를 disable 하는 것은 왠만하면 권장하지 않습니다. 스토리지가 ATS 를 지원하지 못하는 경우를 제외하고 말이지요. 

일단 heartbeat 이 어떤 것인지를 알아보겠습니다. 이게 저만 그런걸수도 있는데 heartbeat 이라는게 그냥 생각해보면, 호스트에서 해당 VMFS 볼륨이 살아있는지를 체크하는 용도인것처럼 보입니다. 그렇지만 실제로는 그렇지 않습니다.  실제로는 해당 볼륨에 액세스하고있는 호스트가 살아있는지 체크하는 용도입니다. 즉 하나의 VMFS 볼륨에는 해당 볼륨에 액세스하고 있는 호스트별로 Heartbeat 영역이 존재합니다. 즉 각각의 호스트에서 해당 Heartbeat 영역에 대한 업데이트를 하면서, 호스트가 살아있는지 죽었는지를 다른 호스트에게 알려주는 역할을 하고 있는 것입니다. 

만약 하나의 호스트가 Lock 을 잡고 있다면, 다른 호스트에서는 Lock 을 임의로 풀수가 없습니다. 그렇지만 만약 Lock 을 잡고 있는 호스트가 Crash 되었다던지 해서 사용가능한 상태가 아닌 경우에는 굳이 해당 호스트가 Lock 을 계속 잡고 있도록 할 필요가 없겠지요. 이 경우에 해당호스트의 Heartbeat 영역이 일정시간이상 업데이트 되지 않았다면 다른 호스트에서 현재 잡혀있는 Lock 을 풀수 있습니다.  제가 알기로는 이게 8초 동안 해당 호스트에서 Heartbeat I/O 가 없으면 다른 호스트에서 Lock 을 풀 수 있는것으로 알고 있습니다.

왜 Lock 을 풀어야 하느냐? 호스트에서 VMDK 파일에 대해서도 Lock 을 잡고 있기 때문입니다. 가령 VM A 가 Host 1에서 Running 중인데, Crash 되었다 라고 한다면? vSphere HA 를 통해서 Host 2 로 Failover 되고 Poweron 되어야 합니다. 이전 호스트가 계속 lock 을 잡고 있다면 새로운 호스트에서 VM Power On 을 할수가 없기 때문입니다.

그렇다면 ATS heartbeat 는 무엇인가? 이것은 vSphere 5.5U2 부터 추가된 기능입니다. 기존에는 Heartbeat 을 업데이트하기 위해서 SCSI Read/Write 를 ESXi 호스트에서 보내면서 Heartbeat 을 업데이트 하는 방식이었는데, 쉽게 말씀드리면, 이 SCSI Read/Write 를 호스트에서 안보내고 스토리지내부에서 처리하도록 하게 한것입니다. 즉 Read/Write 를 보내는 대신에, 스토리지 내부에서 Read/Write 를 발생시키라는 커맨드를 날리는 것이죠. 일종의 offload 라고 보시면 됩니다.

이 기능을 사용하게 되면 필수적으로 호스트에서 ATS 커맨드의 사용빈도가 높아지게 되고, 해당 오퍼레이션으로 인해 스토리지에 부하를 주게 되어있습니다. 호스트에서 할일을 스토리지에 넘긴거니까 당연한것이죠. 그런데 여기서 위에서 언급한 ATS MISCOMPARE 문제가 발생하는 것입니다. 정확하게 어떤 조건에서 발생하는지는 명확하지 않으나, Heartbeat 업데이트를 위한 ATS 커맨드가 Failed 이 되는 경우 ATS MISCOMPARE 메세지가 발생하고, VMFS 볼륨으로의 연결에 문제가 생기는 이슈가 발생하는 것입니다.

이것은 ATS heartbeat 자체의 문제라기 보다는 특정 스토리지와 특성을 타는 부분으로 알려져있습니다.

1. 예를 들면 Solidfire 스토리지의 경우, ESXi 에서 보내는 ATS 커맨드는 512 byte 크기인데 인데, Solidfire 의 경우는 4K block size 를 사용하는 스토리지이기 때문에 발생한다고 합니다. ESXi 에서 4K ATS 커맨드를 보낼 수 있다라면 해결할 수 있는 부분이라고 합니다. http://www.vmdude.fr/en/news-en/solidfire-vs-ats-heartbeat/
2.  EMC VMAX 스토리지의 경우 0x89 대신에 0xF1 을 사용하는데요, 이 F1 커맨드가 시간에 아주 민김하다고 합니다. 따라서, heartbeat 을 업데이트 하는 과정 자체가 아주 시간에 민감해지게 되어서, ATS 커맨드 failed 이 발생할 수 있는 확률이 높아진다고 합니다. http://timsvirtualworld.com/2015/04/ats-miscompare-issue-with-emc-vmax/
3. EMC VNX 스토리지에서도 발생하는 경우가 있는것으로 알려져있습니다. https://community.emc.com/docs/DOC-52756

따라서 ATS MISCOMPARE 가 발생한다면 “ATS heartbeat만” disable 하도록 권고가 되어있는 것입니다. ATS 전체를 disable 하라는 의미가 아니니 잘 이해하셔야 합니다. ATS heartbeat 을 disable 하면 호스트에서 스토리지로 offload 하던 기능을 disable 하는 것입니다. 즉 기존에 호스트에서 스토리지로 heartbeat 업데이트를 위한 read/write 를 보내는 방식으로 설정하는 것입니다. 위 KB 에서 언급한 증상이 발생하는 경우에만 disable 하는 것을 권고하고 있으니 참고 하시기 바랍니다.