안녕하세요. 오늘은 Snapshot LUN 에 대해서 썰을 한번 풀어볼려고 합니다.

먼저 Snapshot LUN 이란 무엇이냐부터 시작해야하는데요, 일단 관련 KB 는 다음과 같습니다.

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

용어를 잘 구분하셔야 하는데, Snapshot LUN 이라고 해서 vSphere snapshot 이나, 스토리지 어레이의 Snapshot 하고는 혼동하시면 안됩니다. 별개의 것이라고 이해하시는게 편합니다.

스토리지 어레이를 통해 LUN 의 복제를 수행하게 되면, 동일한 내용을 가진 LUN 이 하나 더 생기는 것과 마찬가지인데요, 이때는 LUN 의 내용도 내용이지만, 해당 LUN 의 UUID 및 메타데이터까지 동일한 LUN 이 존재하게 됩니다. ESXi 라면 VMFS datastore 를 복제하는 샘이 되니까 여기서의 UUID 는 VMFS datastore 의 UUID 를 의미합니다.

즉, naa 값만 다른 동일한 LUN 이 생성되는 것이죠.  DR 등을 위해 복제된 LUN 을 아마 호스트에 붙이고, VMFS 를 마운트할려고 하실텐데, 이때

이때 ESXi 가 물어보는 것이 Signature 를 유지할것이냐, Resignature 를 할거냐고 물어봅니다.

ESXi 가 물어보는이유는 ESXi 가 예상했던 UUID 가 아니라 다른 UUID 를 보기 때문입니다. UUID Mismatch 가 발생하게 되는 것이죠. 이러한 LUN 들을 Snapshot LUN 이라고 합니다. (또는 Unresolved LUN) 이때 esxcfg-volume -l 또는 esxcli storage vmfs snapshot list 커맨드를 실행하면 이 이러한 LUN 들을 확인 할 수 있습니다.

[root@localhost:~] esxcfg-volume -l

Scanning for VMFS-6 host activity (4096 bytes/HB, 1024 HBs).

VMFS UUID/label: 5d88b34e-208a5b78-d558-64006a7b0fce/Synology

Can mount: No (the original volume is still online)

Can resignature: Yes

Extent name: naa.6001405d1cce620dffecd4e65d8cecdf:1     range: 0 – 9983 (MB)

위에 보시면 Can Mount : No 라고 되어있습니다. 그 이유는 이번 예에서는 같은 호스트에 오리지널 LUN 과 복제된 LUN 을 같이 붙여놓은 케이스이기 때문에 그렇습니다. 동시에 마운트가 불가능한거죠 UUID 가 똑같기 때문에 그렇습니다. 이때 Original LUN 의 마운트를 해제하면 그때부터 붙일 수 있게 됩니다.

[root@localhost:~] esxcli storage filesystem unmount -u 5d88b34e-208a5b78-d558-64006a7b0fce

[root@localhost:~] esxcfg-volume -l

Scanning for VMFS-6 host activity (4096 bytes/HB, 1024 HBs).

VMFS UUID/label: 5d88b34e-208a5b78-d558-64006a7b0fce/Synology

Can mount: Yes

Can resignature: Yes

Extent name: naa.6001405d1cce620dffecd4e65d8cecdf:1     range: 0 – 9983 (MB)

UUID Mismatch 가 발생하게 되는 이유는 다음과 같습니다.

When a VMFS is copied, so is that UUID because it is stored in the metadata of the VMFS (just like the VMFS name). In SAN storage, each device has a unique serial number so when that data (the VMFS) is copied to a new one and presented to ESXi, ESXi detects a UUID mismatch and will not mount it by default 

그래서 UUID 를 변경할것이냐고 물어보는것이고, 변경하는 것이 권장됩니다. 변경하게 되면 그때부터는 복제된 LUN 이 아니라 그냥 새로운 LUN 으로 인식합니다. 그렇지만 실제 DR 상황이 아니라 DR 훈련상황이라면 훈련때문에 복제를 끊고, 훈련이 끝나고 나서 다시 풀싱크 복제를 거는것은 비효율적일 수 있습니다. 그래서 쓸 수 있는 것이 Signature 를 변경하지 않고 마운트 하는 것 (Force Mount) 입니다.

Force mount 가 아니라 Resignature 를 하게 되면 UUID 를 변경하고, snap-XXXXXX 라는 형태의 이름을 가진 VMFS datastore 를 마운트 합니다. 여기서 XXXXXX 는 기존 데이터스토어의 이름이구요. 오리지널 LUN 과 구분하기 위해서 변경되는 것입니

이때 Force mount 를 하게 되면 Snapshot LUN 을 마운트 하는 것이라고 이야기 합니다. 이때는 UUID 를 변경하지 않고 마운트가 됩니다.

중요한것은 Force mount 는 일시적으로 쓰는 방법이지, 결코 권장되는 방법은 아니라는 것입니다. 그 이유는 다음과 같습니다.

Note: Keeping the existing signature will cause problems in the future, such as preventing the increase of the datastore size, and preventing the datastore from automatically mounting on new hosts, etc. So, “force mounting” (mounting the datastore while keeping the existing signature) is just a temporary step to gain immediate access. After that, please either schedule a maintenance window for the VMs on that datastore and assign the new signature, or migrate the VMs off the datastore so they are not affected by the maintenance.

위의 몇가지 오퍼레이션들이 불가능해 짐으로 필요한 경우에만 하시는것이 좋겠습니다. 아래 링크도 참조하세요.

VMFS Snapshots and the FlashArray Part II: Why not Force Mount?