여러 zvol과 데이터 세트가 포함된 zfs 풀이 있는데 그 중 일부는 중첩되어 있습니다. 모든 데이터세트와 zvol은 zfs-auto-snapshot에 의해 주기적으로 스냅샷이 생성됩니다. 모든 데이터세트와 zvol에는 수동으로 생성된 스냅샷도 있습니다.
원격 풀을 설정했는데 시간 부족으로 인해 로컬 고속 네트워크를 통한 zfs send -R을 통한 초기 복사가 완료되지 않았습니다(일부 데이터 세트가 누락되었거나 일부 데이터 세트가 오래되었거나 스냅샷이 누락됨).
이제 풀은 느린 연결을 통해 물리적으로 원격에 있으며 원격 풀을 로컬 풀과 주기적으로 동기화해야 합니다. 즉, 로컬 풀에 있는 데이터를 원격 풀에 복사해야 하고 로컬 풀의 데이터를 복사해야 합니다. 원격 풀에서 삭제되며, 원격 풀에는 있지만 로컬 풀에는 없는 데이터는 원격 풀에서 삭제되어야 합니다. 즉, "zvols", "datasets" 또는 "snapshots"을 의미합니다.
rsync를 사용하여 두 개의 일반 파일 시스템 간에 이 작업을 수행하려면 "-axPHAX --delete"(일부 시스템을 백업하기 위해 실제로 수행하는 작업)가 됩니다.
원격 풀 zvol 및 데이터 세트(스냅샷 포함)가 로컬 zvol, 데이터 세트 및 스냅샷과 동기화될 수 있도록 동기화 작업을 설정하려면 어떻게 해야 합니까?
처리량 성능이 낮기 때문에 ssh를 통한 전송을 피하고 싶습니다. mbuffer 또는 iscsi를 선호합니다.
답변1
면책 조항: 저는 zvol을 사용해 본 적이 없기 때문에 일반 파일 시스템이나 스냅샷과 다르게 복제하는지 말할 수 없습니다. 나는 그렇게 생각하지만 내 말을 받아들이지 마십시오.
귀하의 질문은 실제로 여러 질문이므로 개별적으로 답변해 드리겠습니다.
전체 풀을 원격 위치로 복사/미러링하는 방법
작업을 두 부분으로 나누어야 합니다. 먼저 초기 복사를 수행해야 하고 그 다음 증분 복사를 수행할 수 있습니다.복사본 스냅샷을 엉망으로 만들지 않는 한. 증분 복제를 활성화하려면 마지막 복제 스냅샷을 유지해야 하며 그 이전의 모든 내용은 삭제될 수 있습니다. 이전 스냅샷이 삭제되면 zfs recv
오류가 발생하고 복제가 중단됩니다 . 이 경우 다시 시작해야 하므로 그렇게 하지 마십시오.
올바른 옵션이 필요한 경우 다음과 같습니다.
zfs send
:-R
: 지정된 풀 또는 데이터세트 아래의 모든 항목을 보냅니다(재귀 복사, 항상 필수, 포함-p
). 또한 수신 시 삭제된 모든 소스 스냅샷이 대상에서 삭제됩니다.-I
: 마지막 복제 스냅샷과 현재 복제 스냅샷 사이의 모든 중간 스냅샷을 포함합니다. (증분 전송하는 경우에만 필요)
zfs recv
:-F
: 소스에서 삭제된 기존 데이터 세트 삭제를 포함하도록 대상 풀을 확장합니다.-d
: 소스 풀의 이름을 버리고 대상 풀 이름으로 바꿉니다. (나머지 파일 시스템 경로는 유지되며 필요한 경우 생성될 수 있습니다.)-u
: 대상에 파일 시스템을 마운트하지 마십시오.
완전한 예를 원한다면 다음과 같은 작은 스크립트가 있습니다.
#!/bin/sh
# Setup/variables:
# Each snapshot name must be unique, timestamp is a good choice.
# You can also use Solaris date, but I don't know the correct syntax.
snapshot_string=DO_NOT_DELETE_remote_replication_
timestamp=$(/usr/gnu/bin/date '+%Y%m%d%H%M%S')
source_pool=tank
destination_pool=tank
new_snap="$source_pool"@"$snapshot_string""$timestamp"
destination_host=remotehostname
# Initial send:
# Create first recursive snapshot of the whole pool.
zfs snapshot -r "$new_snap"
# Initial replication via SSH.
zfs send -R "$new_snap" | ssh "$destination_host" zfs recv -Fdu "$destination_pool"
# Incremental sends:
# Get old snapshot name.
old_snap=$(zfs list -H -o name -t snapshot -r "$source_pool" | grep "$source_pool"@"$snapshot_string" | tail --lines=1)
# Create new recursive snapshot of the whole pool.
zfs snapshot -r "$new_snap"
# Incremental replication via SSH.
zfs send -R -I "$old_snap" "$new_snap" | ssh "$destination_host" zfs recv -Fdu "$destination_pool"
# Delete older snaps on the local source (grep -v inverts the selection)
delete_from=$(zfs list -H -o name -t snapshot -r "$source_pool" | grep "$snapshot_string" | grep -v "$timestamp")
for snap in $delete_from; do
zfs destroy "$snap"
done
SSH보다 빠른 것을 사용하십시오
IPSec 또는 OpenVPN 터널과 같이 충분히 안전한 연결이 있고 발신자와 수신자 사이에만 존재하는 별도의 VLAN이 있는 경우 SSH에서 mbuffer와 같은 암호화되지 않은 대안으로 전환할 수 있습니다.여기에 명시된 바와 같이또는 약한 암호화/비활성화 및 압축이 비활성화된 SSH를 사용할 수 있습니다.자세한 내용은 여기. SSH를 더 빠르게 만들기 위해 다시 컴파일하는 방법에 대한 웹사이트도 있지만 안타깝게도 URL이 기억나지 않습니다. 나중에 찾으면 편집하겠습니다.
매우 큰 데이터 세트와 느린 연결의 경우 하드 디스크를 통한 첫 번째 전송도 유용할 수 있습니다(암호화된 디스크를 사용하여 zpool을 저장하고 택배, 우편 또는 밀봉된 패키지로 직접 전송). 전송 방법은 보내기/받기에 중요하지 않으므로 모든 것을 디스크로 파이프하고, 풀을 내보내고, 디스크를 대상으로 보내고, 풀로 가져온 다음 모든 증분 전송을 SSH로 보낼 수 있습니다.
스냅샷 혼동 문제
앞서 언급했듯이 복제 스냅샷을 삭제/수정하면 오류 메시지가 나타납니다.
cannot send 'pool/fs@name': not an earlier snapshot from the same fs
이는 명령이 잘못되었거나 일관성이 없는 상태이므로 스냅샷을 삭제하고 다시 시작해야 함을 의미합니다.
이는 여러 가지 부정적인 영향을 미칩니다.
- 새 복제 스냅샷이 성공적으로 전송될 때까지 복제 스냅샷을 삭제할 수 없습니다. 이러한 복제 스냅샷에는 다른 모든(이전) 스냅샷의 상태가 포함되어 있으므로 삭제된 파일과 스냅샷의 빈 공간은 복제가 완료될 때까지 회수되지 않습니다. 이로 인해 풀에 임시 또는 영구적인 공간 문제가 발생할 수 있으며, 이는 재부팅하거나 전체 복제 프로세스를 완료해야만 해결할 수 있습니다.
- 추가 스냅샷이 많아지면 list 명령 속도가 느려집니다(이 문제가 해결된 Oracle Solaris 11 제외).
- 스크립트 자체를 제외하고 (우발적인) 삭제로부터 스냅샷을 보호해야 할 수도 있습니다.
이러한 문제에 대한 가능한 해결책이 있지만 직접 시도하지는 않았습니다. zfs bookmark
이 작업을 위해 특별히 만들어진 OpenSolaris/illumos의 새로운 기능을 사용할 수 있습니다 . 이를 통해 스냅샷 관리의 제약에서 벗어날 수 있습니다. 유일한 단점은 현재 단일 데이터 세트에서만 작동하고 재귀적으로 작동하지 않는다는 것입니다. 모든 이전 데이터세트와 새 데이터세트의 목록을 유지한 다음 이를 반복하고 북마크하고 보내고 받은 다음 목록(또는 원하는 경우 소규모 데이터베이스)을 업데이트해야 합니다.
북마크 경로를 시도해 보시면 어떻게 될지 알고 싶습니다!
답변2
개인적으로 저는 원격 서버에 zvol, 데이터세트 등의 목록을 직접 만들겠습니다.아니요zfs send
시간이 많이 걸리고 대역폭이 많이 소모되더라도 최신 스냅샷을 가지고 있는 다음 으로 해당 스냅샷을 업데이트하십시오 .
zfs send
그런 다음 자체 동기화 코드를 작성하여 바퀴를 다시 만들 필요 없이 계속 사용할 수 있습니다 . rsync
오래된 파일 시스템에는 좋지만 zfs send
zfs에는 더 좋습니다.정확히스냅샷의 어떤 블록이 변경되어 전송되었는지오직반면 rsync는 로컬 서버와 원격 서버 간의 개별 파일 및/또는 타임스탬프를 비교해야 합니다. btrfs send
btrfs 풀 에도 동일하게 적용됩니다 .
업데이트할 스냅샷이 몇 개뿐인 경우 수동으로 업데이트할 수 있습니다. 그렇지 않은 경우 이를 자동화하려면 최신 로컬 스냅샷과 원격 스냅샷의 목록, 그리고 zfs send
rmeote 서버의 만료된 로컬 스냅샷과 버전을 비교하는 스크립트가 필요합니다.
각 데이터세트의 최신 스냅샷에만 관심이 있다면 이것으로 충분합니다. 이전의 모든 스냅샷에 관심이 있다면 당연히 스크립트도 이를 처리해야 합니다. 이는 더욱 복잡해집니다. 어떤 경우에는 중간/손실된 스냅샷을 다시 보낼 수 있도록 원격 서버에서 롤백해야 할 수도 있습니다.
원격 서버에 대한 보안 연결을 원한다면 실제로 ssh
터널을 설정 openvpn
하고 사용하기 위해 다른 것을 사용하거나 사용할 수 밖에 없습니다 netcat
.
답변3
FreeBSD에서 "zrepl"을 확인해 보세요. 여러분의 삶과 다른 사람의 삶을 훨씬 쉽게 만들어 줄 수 있습니다. 며칠 전 오타와에서 열린 BSDCan2018에서 출시되었습니다. 유망해 보이고 문제를 해결할 수도 있습니다.
답변4
zrep은 훌륭한 올인원 솔루션이며 일반 SSH 전송보다 빠른 속도를 얻는 방법에 대한 문서 + 후크가 있습니다.
https://github.com/bolthole/zrep
또한 크로스 플랫폼입니다. Linux, freebsd 및 Solaris/illumos를 지원합니다.