Zfs: 기능 요청-온라인 분할 클론

zfs promote 가) 이미 필요한 작업을 수행 할 수있는 것 같습니다.

       zfs promote clone-filesystem

           Promotes a clone file system to no longer be dependent on its "ori
           gin"  snapshot.  This  makes it possible to destroy the file system
           that the clone was created from. The clone parent-child  dependency
           relationship  is reversed, so that the origin file system becomes a
           clone of the specified file system.

           The snapshot that was cloned, and any snapshots  previous  to  this
           snapshot,  are  now owned by the promoted clone. The space they use
           moves from the origin file system to the promoted clone, so  enough
           space  must  be  available  to  accommodate these snapshots. No new
           space is consumed by this operation, but the  space  accounting  is
           adjusted. The promoted clone must not have any conflicting snapshot
           names of its own. The rename subcommand can be used to  rename  any
           conflicting snapshots.

나는 zfs promote를보고 있었지만 이것은 단지 부모-자식 관계를 뒤집는 것처럼 보인다.

제가 생각했던 것은 두 파일 시스템이 서로 완전히 독립적 인 최종 상태였습니다.

이에 대한 일부 사용 사례는
VM 템플릿 복제-다른 VM을 생성하기 위해 복제 된 기본 이미지가 있으며, 이는 템플릿에서 분리되어 템플릿을 업데이트 / 파괴 / 다시 생성 할 수 있습니다.
데이터베이스 복제-많은 변경 사항을 겪고 테스트 복제 자체의 기반이 될 수있는 dev 용 prod db를 복제합니다. 개발 용 독립 파일 시스템을 갖는 것보다

original @ snapshot 을 복제 한 후에는 데이터 세트를 수정하고 자유롭게 복제 할 수 있지만, 두 디스크 모두에 여전히 공통된 데이터를 공유한다는 점을 제외하고는 서로 영향을 미치지 않습니다.

템플릿 (원본)을 파괴 / 다시 생성하려면 해당 템플릿에있는 모든 스냅 샷 (복제 원본으로 사용 된 스냅 샷 제외)을 간단히 삭제하면됩니다. zfs는 원본의 이름을 바꾸고 zfs는 동일한 이름으로 새 스냅 샷을 만듭니다 (원본 속성). 클론 수는 원본 데이터 세트의 이름에 바인딩되지 않으므로 둘 다 자유롭게 이름을 바꿀 수 있습니다.

유일한 단점은 original @ snapshot (= 클론의 기본)에 보관 된 모든 _unique_ 데이터는 클론 또는 (클론 승격 후) 원본을 제거하지 않는 한 해제 할 수 없다는 것입니다.

결국 @ greg-hydrogen zfs promote 가 귀하의 요구를 충족하는지 결정 했습니까? 또는 여기에 여전히 가능한 기능 요청이 있습니까?

이에 대해 언급하기 위해 원본-복제 관계를 중복 제거 된 종류로 변환하는 기능이 있다면 좋을 것입니다. 데이터.

@behlendorf : 거의 확실하게 요구를 충족시키지 못합니다.
http://jrs-s.net/2017/03/15/zfs-clones-probably-not-what-you-really-want/
문제를 잘 설명합니다.

개념적으로 수행하려는 작업은 다음과 같습니다.

user @ backup :

1. 날짜 기반 스냅 샷 생성
2. 미러로 테스트하기 위해 백업에서 전송

zfs snapshot backup/prod<strong i="11">@20170901</strong>
zfs send -R backup/prod<strong i="12">@20170901</strong> | ssh test zfs recv ... test/mirror

user @ test :

1. 거울을 소독 할 장소를 만듭니다.
2. 소독하다
3. 스냅 샷
4. 사용을 위해 삭제 된 버전 복제
5. 사용해

zfs clone test/mirror<strong i="23">@20170901</strong> test/sanitizing
sanitize sanitizing
zfs snapshot test/sanitizing<strong i="24">@sanitized</strong>
zfs clone test/sanitizing<strong i="25">@sanitized</strong> test/test
dirty test/test

user @ backup :

1. 생산을 더 많이 사용하면서 ...
2. 업데이트 된 스냅 샷 생성
3. 제품에서 테스트로 증분 변경 사항 보내기
4. 이전 증분 마커를 삭제합니다 (제 경우에는 70GB를 확보합니다).

dirty prod/prod
zfs snapshot backup/prod<strong i="35">@20170908</strong>
zfs send -I backup/prod<strong i="36">@20170901</strong> backup/prod<strong i="37">@20170908</strong> | ssh test zfs recv test/mirror
zfs destroy backup/prod<strong i="38">@20170901</strong>

user @ test :

• 이것은 문제가 나타나는 곳입니다.
• 약간의 카 졸링을 사용하면 살균 볼륨을 파괴 할 수 있습니다.
• 하지만 남은 두 가지 항목 인 test/mirror@20170908 및 test/test 의 출처 인 test/mirror@20170901 가 남았습니다.
• 원하는 경우 업데이트 된 미러 ( test/mirror@20170908 )를 제거 할 수 있지만 그렇게해도 아무런 소용이 없습니다 (내 목표는 해당 데이터를 사용하는 것이므로).

진행하기 위해서는 실제로 살균을 실행하고 테스트를 사용하는 것을 중지하고 테스트를 완전히 파괴하고 테스트로 미러를 복제하고 테스트를 사용하여 다시 시작한 다음 마침내 원본을 파괴 할 수 있습니다 스냅 사진. 또는 패스를 수행하고 나중에 백업시 새 스냅 샷을 트리거하고 증분을 전송하고 테스트를 위해 미러링되지 않은 스냅 샷을 삭제 한 후 다시 시도 할 것인지 결정할 수 있습니다.

Fwiw, 이것을 맛보기 위해 ... :

zfs list -t all -o used,refer,name,origin -r test/mirror test/test
 USED   REFER  NAME                              ORIGIN
 161G   1.57M  test/mirror                       -
  65G   82.8G  test/mirror<strong i="54">@2017081710</strong>            -
    0   82.4G  test/mirror<strong i="55">@201709141737</strong>          -
3.25G   82.8G  test/test                         test/mirror<strong i="56">@2017081710</strong>

(숫자가 정말 잘못되었습니다. 실제로 4 개의 볼륨이 포함 된 1 개의 볼륨이 있으므로 재귀 플래그가 있습니다 ...)

이제 zfs send | zfs recv 를 사용하여 종속성을 끊을 수 있으며 작은 일에도 괜찮다는 것을 이해합니다. 그러나 내 풀의이 부분은 풀에서 사용 가능한 공간의 약 두 배이고 절반은 아마도 그보다 클 것입니다. 즉, 해당 작업을 수행하는 데 문제가 있음을 의미합니다. 또한 재 처리하는 데 막대한 양의 바이트입니다. 스냅 샷 사용에 대한 나의 희망은 COW의 혜택을받을 수있는 것이었지만, 결국에는 분기 트리의 어느 쪽에서도 사용되지 않는 데이터가있는 분기 지점에 대한 비용을 지불해야하기 때문에 COW 비용이 청구됩니다.

@behlendorf 안녕하세요, 진행 상황이 있습니까? 원본 파일 시스템에서 클론을 분할하면 VM 템플릿 및 / 또는 대용량 파일 수준 복원에 정말 좋습니다. 실제 예제는 위에 붙여 넣은 @jsoref 링크를 참조하십시오.

@kpande : 목표는 전체 데이터 세트 (이 작업이 발생할 때마다)가 아니라 변경된 사항 (COW)에 대해 비용을 지불하는 것입니다 (공간 및 데이터 전송).

10TB의 이동 데이터 세트가 있고 설정하려는 데이터 세트의 변형이 있다면 10TB를 복사하고 변형을 적용한 다음 20TB를 지불 할 수 있습니다 (사용 가능한 20TB가있는 경우). 그러나 내 변형이 원래 10TB와 실제로 10MB 만 다를 경우 10TB + 10MB를 지불 할 수없는 이유는 무엇입니까? -스냅 샷 + 클론이 제공합니다. 10TB가 충분히 이동하여 10TB (라이브 + 10TB 스냅 샷 + 10TB 분기)를 지불하고 10MB 변형이 이동하여 이제 자체 10TB (라이브 및 스냅 샷에서 분기)가됩니다. 그 동안 30TB 문제를 "수정"하려면 10TB (= 40TB-zfs send + zfs recv를 통해)를 사용해야합니다. 그것은 이상적이지 않습니다. 물론 "작동"할 수 있지만 "빠르거나"원격 공간 효율적이지 않습니다.

수정 된 전송 / 수신은 흥미롭게 들리지만 (다소 내 사용 사례와 일치하기 때문에)-여러 곳에서 언급 된 것을 찾을 수 있지만 실제로 수정되는 내용에 대한 유용한 설명을 찾을 수 없습니다.

Fwiw, 우리 시스템의 경우 전송 측에서 살균이 발생하도록 전환했습니다 (개인 정보 보호 측면에서도 더 낫습니다). 이로 인해 대부분 숲에서 벗어날 수있었습니다.

데이터 변형이 "수정"되지 않고 시스템에 zfs 스냅 샷 + zfs 전송을위한 리소스가 있지만 실제로 "변형"을 수행하기 위해 두 번째 데이터베이스를 호스팅하는 데 리소스를 할당하고 싶지 않은 경우입니다. 기본 및 보조간에 전체 볼륨을 전송하기 위해 비용을 지불 할 필요가 없습니다 (즉, 이전 스냅 샷이 이미있는 시스템에 증분 스냅 샷을 전송하는 것이 좋습니다).

예, 중복 제거를 사용할 수 있다는 것을 알고 있습니다. 우리는 CPU / 램에 대한 비용을 지불하고 있으므로, 드문 작업 (변형 된 클론 새로 고침)을 빠르게 만들기 위해 일정한 cpu + ram을 사용하는 것은 좋지 않은 트레이드 오프처럼 느껴졌습니다.

@kpande 이 링크 는 현재 클론의 문제를 아주 명확하게 보여줍니다. 결국 클론이 기본 스냅 샷에서 너무 많이 갈라지면 둘 사이의 영구적 인 부모-> 자식 관계가 혼란의 원인이됩니다. 클론을 분할하는 것은 더 이상 연결되지 않은 것으로 간주하기 위해 너무 많이 갈라 졌다는 명확한 표시입니다.

그러나 좀 더 실용적인 예를 들어 보겠습니다.

kvm/vmimages 를 여러 가상 디스크 이미지에 대한 데이터 저장소 컨테이너로 지정하고 매일 스냅 샷을 만듭니다. 기본 대답은 "각 디스크에 대한 데이터 세트 사용"이라는 것을 알고 있지만 libvirt 풀은 제대로 작동하지 않습니다. 그래서 우리는 다음과 같은 것을 가지고 있습니다.

kvm/vmimages
kvm/vmimages<strong i="11">@snap1</strong>
kvm/vmimages<strong i="12">@snap2</strong>
kvm/vmimages<strong i="13">@snap3</strong>

어떤 시점에서 vm 디스크에 나쁜 일이 발생하지만 (예 : 심각한 게스트 파일 시스템 손상) 그 동안 다른 사용자가 다른 디스크에 새롭고 중요한 데이터를 적극적으로 저장하고 있습니다. 기본적으로 몇 가지 대조적 인 요구 사항이 있습니다. a) 어제의 손상되지 않은 이전 데이터로 되돌리려면 b) 스냅 샷에서 찾을 수없는 업로드 된 새 데이터를 보존하고 c) 서비스 중단을 최소화하기 위해.

가능한 솔루션으로 클론이 떠 오릅니다. kvm/vmimages@snap3 를 kvm/restored 로 복제하여 영향을받는 VM에 대한 서비스를 즉시 복원 할 수 있습니다. 이제 다음과 같이됩니다.

kvm/vmimages
kvm/vmimages<strong i="20">@snap1</strong>
kvm/vmimages<strong i="21">@snap2</strong>
kvm/vmimages<strong i="22">@snap3</strong>
kvm/restored   # it is a clone of snap3
kvm/restored<strong i="23">@snap1</strong>
...

영향을받는 VM은 kvm/restored 에서 실행되고 다른 모든 VM은 kvm/vmimages 에 남아 있습니다. 이 시점에서, 당신은 모든 여분의 디스크 삭제 kvm/restored 과에서 원래, 손상된 디스크 kvm/vmimages . 이전의 손상된 디스크 이미지가 여전히 실제 디스크 공간을 사용하고 있으며 kvm/restored 덮어 쓰기가 이전의 삭제 불가능한 kvm/vmimages@snap3 로 인해 추가 공간을 소비한다는 것을 알기 전까지는 모든 것이 잘 보입니다. 당신은 또한 당신의 클론을 제거하지 않고이 오래된 스냅 샷을 제거 할 수 없습니다, 당신은 간단하게 올릴 수 없습니다 kvm/restored 삭제 kvm/vmimages 가 유일하고 진정한 "권위"데이터 원본이 아니기 때문에 (예 : 실제 데이터가 두 데이터 세트에 저장 됨).

소스에서 클론을 분리하면 위의 문제가 완전히 해결됩니다. 이 경우 수정 된 보내기 / 받기가 어떻게 도움이되는지 확실하지 않습니다.

@kpande 먼저, 귀하의 견해와 해결책을 공유해 주셔서 감사합니다 (흥미 롭습니다!). 나는 신중하고 매우 구체적인 게스트 구성 (및 호스트 데이터 세트 트리)이 위에 노출 된 문제를 피할 수 있다는 데 전적으로 동의합니다.

즉, libvirt (및 스토리지 풀 구현)는 특히 Windows 가상 머신으로 혼합 환경을 관리 할 때이 접근 방식과 잘 어울리지 않습니다. 더욱이 이것은 하나의 예일뿐입니다. 예를 들어 분할 가능한 클론은 "실제"가상 머신을 생성하기 위해 마음대로 인스턴스화 할 수있는 "골드 마스터 / 기본 이미지"를 생성하는 데 사용되는 경우 매우 유용합니다.

혹시, 잠재적으로 사용되지 않는, 스냅 샷을 원본을 제거 할 수 없으므로 사건의 현재 상태로, 그 일을하는 것은, 할당 된 공간에 많은 당신을 세금을 부과합니다. 놀랍게도 ZFS가 CoW 파일 시스템이기 때문에 이것은 상대적으로 간단한 작업이어야한다는 것입니다. 원본 스냅 샷을 삭제할 때 "간단히"참조되지 않은 모든 블록을 해제하고 부모 / 자식 관계를 제거합니다. 즉, 소스 스냅 샷에서 얽 히지 않은 실제 파일 시스템을 복제하자.

따옴표 안에 "단순히"세계를 사용했다는 점에 유의하십시오. 실제로는 단순한 논리적 작업이지만 기본 zfs 파일 시스템에 매핑되는지 여부는 확실하지 않습니다.

@kpande 괜찮아요, 충분히 공평합니다-만약 진짜 기술적 인 문제가 있다면, 나는 그것을 받아 들여야합니다. 그러나 이것은 특정 사용 사례가 유효하지 않다고 말하는 것과 다릅니다.

이 뷰 (예 : "신화적인"BPR를 포함하지 않고 원래 부모 스냅 샷에서 클론을 분할 할 수 없음)가 zfs 개발자가 공유한다면이 FR은 닫힐 수 있다고 생각합니다.

감사.

이 기능이 필요한 경우 +1. 예, send / recv를 사용할 수 있지만 이전 (복제) 데이터 세트에서 새 데이터 세트로 전환하려면 해당 데이터 세트를 사용하는 모든 작업의 ​​다운 타임이 필요합니다.

LXD에서 컨테이너가 복사 (복제)되는 상황에 직면했지만 이로 인해 별도로 관리되는 스냅 샷에 문제가 발생합니다.

@kpande : 다시, 내 사용 사례에는 전체 데이터 세트가 데이터베이스이고 몇 가지 데이터베이스 변형이 있습니다.

내가 본 것에서, 그것은 파일 시스템으로 zfs와 함께 overlayfs가 멋지게 재생되는 것 같지 않습니다 (당신의 노트에 따르면 zvols와 ext4 / xfs에서 행복해 보입니다). 이 접근 방식이 대부분의 경우에 적용되는 것처럼 들리며,이 경우 ext4 / xfs를 사용하여 overlayfs를 설정하는 방법을 설명하는 문서를 환영합니다.

즉, 우리 중 일부는 볼륨 관리뿐만 아니라 acl / allow / snapshot 동작 / 브라우징에도 zfs를 사용하고 있으며 ext4 / xfs 대신 zfs와 함께 overlayfs를 사용할 수 있기를 원합니다. 가능하지 않습니다. 버그가 있습니까? 만약 있다면 그것이 강조 되었다면 (여기에서), 그렇지 않다면, overlayfs 접근 방식을지지한다면, 아마도 당신은 그것을 제출할 수있을 것입니다. (당신이 주장한다면, 저는 아마도 그것을 쓸 수 있지만, 저는 그렇게하지 않습니다. t overlayfs에 대해 아는 것이 있으며,이 글에서 핵심 기술인 것 같습니다.)

내가 본 것에서, 그것은 파일 시스템으로 zfs와 함께 overlayfs가 멋지게 재생되는 것 같지 않습니다 (당신의 노트에 따르면 zvols와 ext4 / xfs에서 행복해 보입니다). 이 접근 방식이 대부분의 경우에 적용되는 것처럼 들리며,이 경우 ext4 / xfs를 사용하여 overlayfs를 설정하는 방법을 설명하는 문서를 환영합니다.

overlayfs 접근 방식은 매우 중요하고 일반적인 사용 사례 (다른 이미지 (또는 "골드 마스터"템플릿)에서 시작하는 가상 이미지 복제)에는 작동 하지 않습니다 . 이러한 경우 원본 / 복제 된 이미지가 갈라지면서 공간 낭비를 방지하려면 복제본을 분할하는 것이 중요합니다.

@ ptx0 이것은 게스트 OS가 overlayfs 지원 하고 (따라서 Windows VM이 지원 되지 않음 ) 최종 사용자 (예 : 고객)가 VM 이미지 프로비저닝 / 설치를 크게 변경하려는 경우에만 작동합니다. 참고로이 PR은 기술적으로 마감 된 것을 완전히 이해하고 수락하지만 (예 : BPR이 포함 된 경우) 합법적 인 사용자 사례를 "유효하지 않음"으로 스탬프 처리하는 것은 매우 실망스러운 일입니다. 사용 사례가 아니라면 괜찮습니다. 그러나 아무도이 기능에 대한 유효한 사용 사례가 없다고 가정하지 마십시오.

Windows에는 overlayfs가 필요하지 않으며 폴더 리디렉션 및 로밍 프로필이 내장되어 있습니다.

폴더 리디렉션은 NT 이후로 존재했지만 (모호한 이유로) 리디렉션 된 폴더를 올바르게 처리하지 못하고 리디렉션 된 데스크톱 또는 문서에 직면했을 때 단순히 실패하는 소프트웨어가 있기 때문에 항상 안심할 수있는 것은 아닙니다. 그 외에도 Windows 설치의 클론은 Windows Update의 호의로 원본에서 매우 빠르게 그 자체로 매우 빠르게 분산됩니다. 다른 사용자가 로그온 및 로그 오프하면 속도가 빨라질뿐입니다.