Snapshot LUN

안녕하세요. 오늘은 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?

 

 

6 thoughts on “Snapshot LUN

  1. 안녕하세요. Storage를 이용한 DR 환경을 구성하다 막히는 부분을 찾다가 오게 됐습니다. Storage Level에서 복제를 수행한 볼륨을 DR에 붙일때도 똑같은 상황이 발생하는데요. DR 쪽에는 원본 볼륨이 없음에도 바로 마운트가 불가한 이유는 뭘까요?

    또.. Keep Signature를 할 경우, 한대의 호스트에서만 Datastore 액세스가 가능한데, 혹시 왜 이런건지 자문을 구할 수 있을까요?

    1. keep signature 는 다른 말로 이야기하면 강제 mount 라서, vCenter 상에서는 한대에서만 마운트가 됩니다. 다른 호스트에서 마운트를 할려면 esxi 호스트별로 접속해서 force mount 를 해야합니다.
      esxcfg-volume -M 인가 그렇죠

      위 부분은 KB https://kb.vmware.com/s/article/1011387 에 설명이 되어있습니다.
      When one ESXi/ESX host force mounts a VMFS datastore residing on a LUN is detected as a snapshot, an object is added to the datacenter grouping in the vCenter Server database to represent that datastore.

      When a second ESXi/ESX host attempts to do the same operation on the same VMFS datastore, the operation fails because an object already exists within the same datacenter grouping in the vCenter Server database.

      Because an object already exists, vCenter Server does not allow mounting the datastore on any other ESXi/ESX host residing in that same datacenter.

      DR 쪽에는 원본 볼륨이 없는데도 마운트가 안되는 경우는 볼륨 자체가 Read-only 상태일 가능성이 높습니다. 보통 복제가 걸려있는 상태에서는 Read-only 상태구요. 이걸 R/W 가 가능한 상태로 바꿔줘야 합니다. 볼륨이 R/O 상태가 아닌지 한번 확인해보세요~

      1. 빠른 답변 감사합니다.저 KB를 제가 찾던 부분이 있네요. 최근에 Storage 복제로 SRM 없이 DR을 구현하는 사이트에서 절차를 작성하다 보니, 메뉴얼상에 기존 서명을 유지하는 부분을 보통의 DR절차로 해석을 했는데, KB를 참고해보면, DR 절차시 Datastore를 Resignature로 붙여야 되겠군요.

        https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.storage.doc/GUID-95B35AE1-2C29-42C5-ACD8-74C513FBA224.html

        You can keep the signature if, for example, you maintain synchronized copies of virtual machines at a secondary site as part of a disaster recovery plan. In the event of a disaster at the primary site, you mount the datastore copy and power on the virtual machines at the secondary site.

        이 부분 마치 DR시 기존 서명 유지하는 방법을 권하는걸로 보이는데.. 업데이트좀 필요한거 아닌가요 ㅠㅠ?

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다