☰

zpool 내보내기는 정확히 무엇을 수행합니까?

tag-icon • tag-icon zfs eject
zpool 내보내기는 정확히 무엇을 수행합니까?

zpool export에 대한 부분을 읽은 후 man zpool약간 걱정이 됩니다.

시스템에서 지정된 풀을 내보냅니다. 모든 장치는 내보낸 것으로 표시되지만 여전히 다른 하위 시스템에서 사용 중인 것으로 간주됩니다. 충분한 수의 장치가 존재하는 한 시스템 간에 장치를 이동하고 가져올 수 있습니다(엔디안이 다른 시스템도 포함).

"그러나 여전히 다른 하위 시스템에서 사용 중인 것으로 간주됩니다"는 무엇을 의미합니까? "충분한 수의 장치가 있는 한"은 무엇을 의미합니까?

배경:

프로덕션 서버의 VM 스토리지를 ZFS 스냅샷을 기반으로 대기 서버에 복사하는 상당히 복잡한 백업 스크립트가 있습니다(정확하게 말하면 호스트와 VM의 다양한 스크립트 시스템이 함께 작동하여 파일 시스템을 고정합니다). VM을 선택하고 ZFS 스냅샷을 만들고 VM의 파일 시스템 고정을 해제한 다음 스냅샷을 대기 서버에 복사합니다. 이 부분은 매력처럼 작동합니다.

그런데 사실 복제 외에 일종의 백업이 필요해요. 즉, VM 저장소를 디스크에 백업한 다음 연결된 상자에서 꺼내어 다른 위치에 안전하게 보관하고 싶습니다.

나는 최선의 접근 방식에 대해 신중하게 생각하고 다음과 같은 아이디어를 생각해냈습니다.

  • 예비 서버에 SATA/SAS 하드 드라이브 캐리어를 설치하면 거기에 하드 드라이브를 연결하거나 분리할 수 있습니다(또는 백플레인에 연결된 기존 캐리어 중 하나를 사용할 수 있습니다).
  • 대기 서버에 새 HDD를 삽입하고 해당 HDD로만 구성된 VDEV를 포함하는 새 ZPOOL을 만듭니다.
  • 프로덕션 서버가 해당 VM 스토리지를 새 ZPOOL에 복사하도록 합니다.또한복사된 ZPOOL에.
  • 복사가 완료되면 새 ZPOOL을 내보내고 새 HDD를 분리한 후 안전한 장소에 보관하세요. **
  • 예비 서버에 두 번째 새 HDD(ZPOOL의 약자)를 삽입하고 처음 두 단계를 반복합니다. ****
  • 등등... (예를 들어 현재 백업 서버에 연결된 HDD를 매일 다른 HDD로 교체하거나, HDD 7개를 사용하고 매주 교체하는 등).

** 이것은 제가 좋아하지 않는 단계입니다(위에 인용된 섹션을 읽은 후). 한편으로는 내보내기 전에 파일 시스템이 마운트 해제(따라서 플러시)되었으므로 ZPOOL(유일한 장치)을 내보낸 후 HDD를 제거하는 데 문제가 없어야 합니다. 반면, 매뉴얼에는 풀을 내보낸 후에도 HDD가 여전히 "다른 하위 시스템에서 사용 중인 것으로 간주"된다고 나와 있는데, 이는 이 경우 단순히 삭제하는 것은 나쁜 생각이라고 믿게 만듭니다.

그래서 저는 이 진술이 정확히 무엇을 의미하는지, 그리고 하드 드라이브를 고려하는 방법을 알고 싶습니다.아니요다른 하위 시스템은 더 이상 사용되지 않습니다.

**** 나는 이것을 위해 약간의 노력을 기울여야 한다는 것을 알았습니다. 계획은 udevHDD가 연결될 때 백업 서버가 인식하고 기존 ZPOOL을 가져올 수 있도록 하는 적절한 규칙이 있는 스크립트를 생성하는 것입니다(HDD는 USB가 아닌 SATA-3 또는 SAS 12G를 통해 직접 연결됩니다). 그러나 그것은 문제의 일부가 아닙니다.

결론적으로:

정확히 zpool export, ZPOOL에 있는 유일한 장치 HDD를 내보낸 후 안전하게 물리적으로 제거하려면 어떤 단계를 수행해야 합니까?

답변1

나는 당신이 설명하는 것과 비슷한 일을 하고 있는데 zpool 내보내기를 사용할 때 약간 혼란스러울 수도 있다고 생각합니다.

zpool 내보내기는 시스템에서 전체 풀...스냅샷 등을 제거합니다. 당신이 원하는 것이 아닌가요?

요청한 작업을 수행하기 위한 첫 번째 단계는 우리가 다루고 있는 zpool의 유형을 이해하는 것입니다. 특히 간단한 미러 풀이 필요할 수 있습니다. 최소 3개의 드라이브.

내 경우에는 3개의 미러가 있는 zpool이 있습니다. 안전하게 보관하기 위해 데이터를 오프사이트로 이동하려는 경우 이동 중인 드라이브를 "오프라인"으로 설정한 다음 어레이에서 제거합니다. 이것은 다음과 같습니다:

      pool: pool_09
 state: ONLINE
  scan: resilvered 1000G in 2h15m with 0 errors on Sun Nov 22 19:49:53 2020

config:

        NAME                         STATE     READ WRITE CKSUM
        pool_09                      ONLINE       0     0     0
          mirror-0                   ONLINE       0     0     0
            c0t5000C500B0BCFB13d0    ONLINE       0     0     0
            c0t5000C500B0889E5Bd0    ONLINE       0     0     0
            c0t5000C500B09F0C54d0    ONLINE       0     0     0
        logs
          mirror-1                   ONLINE       0     0     0
            c0t5F8DB4C095690612d0s3  ONLINE       0     0     0
            c0t5F8DB4C095691282d0s3  ONLINE       0     0     0


      # zpool offline  pool_09 c0t5000C500B0BCFB13d0

이렇게 하면 풀에 미러링된 드라이브 2개가 남게 되므로 여전히 로컬 오류를 견딜 수 있습니다. 나로서는 드라이브를 다른 시스템으로 가져오지 않겠지만 왜 그렇게 할 수 없는지 모르겠습니다. 방금 다른 건물로 가져갔습니다.

미러를 다시 동기화할 준비가 되면 제거된 드라이브를 다시 어레이에 넣고 "온라인"으로 전환합니다.

zpool online pool_09 c0t5000C500B0BCFB13d0

온라인으로 전환하면 ZFS는 드라이브를 자동으로 재동기화하고 프로세스를 반복할 수 있습니다.

이 작업을 수행하기 위해 여러 개의 회전 드라이브를 사용하고 싶지는 않을 것입니다. 이것이 작동하는지 확실하지 않습니다. 10x 미러 세트 같은 것이 있다면 그럴 것 같습니다. 제거된 드라이브가 어레이에서 벗어난 시간이 길수록 재동기화하는 데 시간이 더 오래 걸립니다.

또 다른 옵션은 zfs가 모든 데이터를 보내는 또 다른 풀을 만든 다음 풀을 내보내고 오프사이트로 가져가는 것입니다. 아직 이 작업을 수행하지는 않았지만 작동할 것입니다. 하지만 아마도 훨씬 느릴 것입니다.

.

관련 정보