Làm thế nào để phản chiếu một chiều toàn bộ nhóm zfs sang một nhóm zfs khác


15

Tôi có một nhóm zfs chứa một số zvols và bộ dữ liệu trong đó một số cũng được lồng vào nhau. Tất cả các bộ dữ liệu và zvols được chụp theo định kỳ bằng zfs-auto-snapshot. Tất cả các bộ dữ liệu và zvols cũng có một số ảnh chụp nhanh được tạo thủ công.

Tôi đã thiết lập một nhóm từ xa do thiếu thời gian, sao chép ban đầu qua mạng tốc độ cao cục bộ qua zfs gửi -R không hoàn thành (một số bộ dữ liệu bị thiếu, một số bộ dữ liệu đã lỗi thời hoặc thiếu ảnh chụp nhanh).

Bây giờ nhóm đã được điều khiển từ xa qua kết nối tốc độ chậm và tôi cần định kỳ đồng bộ hóa nhóm từ xa với nhóm cục bộ, nghĩa là dữ liệu có trong nhóm cục bộ phải được sao chép vào nhóm từ xa, dữ liệu đi từ nhóm cục bộ phải được xóa khỏi nhóm từ xa và dữ liệu hiện diện trong nhóm từ xa nhưng không phải trong nhóm cục bộ phải bị xóa khỏi nhóm từ xa, bởi dữ liệu có nghĩa là 'zvols', 'bộ dữ liệu' hoặc 'ảnh chụp nhanh'.

Nếu tôi thực hiện điều này giữa hai hệ thống tệp thông thường bằng rsync, thì đó sẽ là "-axPHAX --delete" (đó là những gì tôi thực sự làm để sao lưu một số hệ thống).

Làm cách nào để thiết lập tác vụ đồng bộ hóa để zvols & bộ dữ liệu nhóm từ xa (bao gồm ảnh chụp nhanh của chúng) có thể được đồng bộ hóa với zvols, bộ dữ liệu & ảnh chụp nhanh cục bộ?

Tôi muốn tránh chuyển qua ssh, vì hiệu suất thông lượng thấp của ssh; Thay vào đó tôi thích mbuffer hoặc iscsi hơn.


Làm thế nào bạn làm ban đầu của bạn zfs send -R ...? Nếu bạn dẫn đầu ra qua ssh, bạn đã vô hiệu hóa các ký tự thoát với zfs send -R ... | ssh -e none ...?
Andrew Henle

Ngoài ra - bạn cần đảm bảo kết nối chậm của bạn có đủ băng thông để giữ cho bản sao từ xa được cập nhật. Nếu bạn nhận được nhiều thay đổi cho hệ thống cục bộ hơn mức bạn có thể gửi đến hệ thống từ xa, bạn sẽ không bao giờ có thể cập nhật bản sao từ xa. Lấy một luồng nhân rộng zfs gia tăng và lưu nó vào một tệp. Nếu tệp lớn hơn lượng dữ liệu bạn có thể gửi đến trang web từ xa trong khoảng thời gian giữa các ảnh chụp nhanh, bạn sẽ không bao giờ theo kịp. zfs send -R -i pool@snap1 pool@snap2 | gzip --fast > /output/file.gz
Andrew Henle

Bạn cũng có thể thử sử dụng tập lệnh này để tự động thực hiện: github.com/psy0rz/zfs_autobackup/blob/master/README.md
edwin mở rộng

Câu trả lời:


10

Tuyên bố miễn trừ trách nhiệm: Vì tôi chưa bao giờ sử dụng zvols, tôi không thể nói liệu chúng có sao chép khác với hệ thống tập tin hoặc ảnh chụp nhanh thông thường không. Tôi cho rằng họ là như vậy, nhưng đừng tin lời tôi.


Câu hỏi của bạn thực sự là nhiều câu hỏi, tôi cố gắng trả lời chúng một cách riêng biệt:

Làm thế nào để nhân rộng / nhân bản hồ bơi hoàn chỉnh đến vị trí xa

Bạn cần chia nhiệm vụ thành hai phần: đầu tiên, bản sao ban đầu phải được hoàn thành, sau đó có thể sao chép tăng dần, miễn là bạn không gây rối với các ảnh chụp sao chép . Để cho phép nhân rộng, bạn cần giữ lại các ảnh chụp sao chép cuối cùng, mọi thứ trước đó có thể bị xóa. Nếu bạn xóa ảnh chụp nhanh trước đó, zfs recvsẽ khiếu nại và hủy bỏ bản sao. Trong trường hợp này, bạn phải bắt đầu lại từ đầu, vì vậy hãy cố gắng không làm điều này.

Nếu bạn chỉ cần các tùy chọn chính xác, chúng là:

  • zfs send:
    • -R: gửi mọi thứ trong nhóm hoặc tập dữ liệu đã cho (sao chép đệ quy, cần thiết mọi lúc, bao gồm -p). Ngoài ra, khi nhận, tất cả các ảnh chụp nhanh nguồn đã xóa sẽ bị xóa ở đích.
    • -I: bao gồm tất cả các ảnh chụp nhanh trung gian giữa ảnh chụp sao chép cuối cùng và ảnh chụp sao chép hiện tại (chỉ cần với các lần gửi tăng dần)
  • zfs recv:
    • -F: mở rộng nhóm mục tiêu, bao gồm xóa các bộ dữ liệu hiện có bị xóa trên nguồn
    • -d: loại bỏ tên của nhóm nguồn và thay thế nó bằng tên nhóm đích (phần còn lại của các đường dẫn hệ thống tập tin sẽ được giữ nguyên và nếu cần cũng được tạo)
    • -u: không gắn hệ thống tập tin vào đích

Nếu bạn thích một ví dụ hoàn chỉnh, đây là một đoạn script nhỏ:

#!/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

Sử dụng một cái gì đó nhanh hơn SSH

Nếu bạn có kết nối được bảo mật đầy đủ, ví dụ như đường hầm IPSec hoặc OpenVPN và một Vlan riêng biệt chỉ tồn tại giữa người gửi và người nhận, bạn có thể chuyển từ SSH sang các lựa chọn không được mã hóa như mbuffer như được mô tả ở đây hoặc bạn có thể sử dụng SSH với mã hóa yếu / không mã hóa và vô hiệu hóa nén, được chi tiết ở đây . Ngoài ra còn có một trang web về việc giới thiệu lại SSH nhanh hơn nhiều, nhưng tiếc là tôi không nhớ URL - tôi sẽ chỉnh sửa nó sau nếu tôi tìm thấy nó.

Đối với các bộ dữ liệu rất lớn và kết nối chậm, cũng có thể hữu ích cho lần truyền đầu tiên qua đĩa cứng (sử dụng đĩa được mã hóa để lưu trữ zpool và truyền trong gói kín qua chuyển phát nhanh, thư hoặc trực tiếp). Vì phương thức truyền tải không quan trọng đối với send / recv, bạn có thể dẫn mọi thứ vào đĩa, xuất nhóm, gửi đĩa đến đích, nhập nhóm và sau đó truyền tất cả các lần gửi tăng dần qua SSH.

Vấn đề với các snapshot lộn xộn

Như đã nêu trước đó, nếu bạn xóa / sửa đổi ảnh chụp sao chép, bạn sẽ nhận được thông báo lỗi

cannot send 'pool/fs@name': not an earlier snapshot from the same fs

điều đó có nghĩa là lệnh của bạn sai hoặc bạn đang ở trạng thái không nhất quán khi bạn phải xóa các ảnh chụp nhanh và bắt đầu lại.

Điều này có một số ý nghĩa tiêu cực:

  1. Bạn không thể xóa ảnh chụp sao chép cho đến khi ảnh chụp sao chép mới được chuyển thành công. Vì các ảnh chụp sao chép này bao gồm trạng thái của tất cả các ảnh chụp nhanh (cũ) khác, không gian trống của các tệp đã bị xóa và ảnh chụp nhanh sẽ chỉ được lấy lại nếu quá trình sao chép kết thúc. Điều này có thể dẫn đến các sự cố không gian tạm thời hoặc vĩnh viễn trên nhóm của bạn mà bạn chỉ có thể khắc phục bằng cách khởi động lại hoặc hoàn tất quy trình sao chép hoàn chỉnh.
  2. Bạn sẽ có nhiều ảnh chụp nhanh bổ sung, làm chậm lệnh danh sách (ngoại trừ Oracle Solaris 11, trong đó điều này đã được sửa).
  3. Bạn có thể cần phải bảo vệ các ảnh chụp nhanh chống lại việc xóa (vô tình), ngoại trừ bởi chính tập lệnh.

Có một giải pháp khả thi cho những vấn đề đó, nhưng tôi đã không tự mình thử nó. Bạn có thể sử dụng zfs bookmark, một tính năng mới trong OpenSolaris / illumos được tạo riêng cho nhiệm vụ này. Điều này sẽ giải phóng bạn quản lý ảnh chụp. Nhược điểm duy nhất là hiện tại, nó chỉ hoạt động cho các bộ dữ liệu duy nhất, không đệ quy. Bạn sẽ phải lưu một danh sách tất cả các bộ dữ liệu cũ và mới của bạn và sau đó lặp qua chúng, đánh dấu, gửi và nhận chúng, sau đó cập nhật danh sách (hoặc cơ sở dữ liệu nhỏ, nếu bạn muốn).

Nếu bạn thử tuyến đường đánh dấu, tôi sẽ thích thú khi nghe cách nó hoạt động cho bạn!


cảm ơn bạn rất nhiều vì câu trả lời chi tiết này tôi chỉ gửi..receive-ing a zpool.
jitter

1
kịch bản hay. Tôi muốn thêm -d 1vào cả hai zfs listlệnh để giới hạn độ sâu tìm kiếm (không cần tìm kiếm bên dưới tên nhóm). Điều này tránh sự chậm trễ lâu trên các nhóm có nhiều ảnh chụp nhanh (ví dụ: nhóm "sao lưu" của tôi có 320000 ảnh chụp nhanh và zfs list -r -t snapshot backupmất 13 phút để chạy. Chỉ mất 0,06 giây với -d 1). Các zfs destroylệnh trong vòng lặp for sau đó cần các -rtùy chọn để xóa đệ quy tất cả các bức ảnh chụp với snapname cùng.
cas

5

Cá nhân, tôi sẽ tạo cho mình một danh sách các zvols, bộ dữ liệu, v.v. trên máy chủ từ xa không có ảnh chụp nhanh cập nhật và sau đó mang đến những ảnh chụp nhanh đó zfs send, ngay cả khi điều này tốn thời gian và sử dụng nhiều của băng thông.

Sau đó tôi chỉ có thể tiếp tục sử dụng zfs sendtừ đó trở đi và không phải phát minh lại bánh xe bằng cách viết mã đồng bộ hóa của riêng tôi. rsynclà tốt cho các hệ thống tệp cũ nhưng zfs sendtốt hơn cho zfs - nó biết chính xác các khối đã thay đổi trong ảnh chụp và chỉ gửi chúng, trong khi rsync phải so sánh các tệp riêng lẻ và / hoặc dấu thời gian giữa các máy chủ cục bộ và từ xa. áp dụng tương tự btrfs sendcho các btrfs pool.

Nếu bạn chỉ có một số ít ảnh chụp nhanh cần được cập nhật, điều này có thể được thực hiện thủ công. Mặt khác, để tự động thực hiện, bạn cần một danh sách các ảnh chụp nhanh cục bộ mới nhất so với ảnh chụp nhanh từ xa và tập lệnh để so sánh các phiên bản và sau đó là zfs sendảnh chụp nhanh cục bộ đã lỗi thời trên máy chủ rmeote.

Điều đó là đủ nếu bạn chỉ quan tâm đến ảnh chụp nhanh nhất cho mỗi tập dữ liệu. Nếu bạn quan tâm đến tất cả các ảnh chụp nhanh trước đó, rõ ràng kịch bản của bạn cũng sẽ phải xử lý chúng .... và điều đó trở nên phức tạp hơn rất nhiều. Trong một số trường hợp, bạn có thể phải quay lại trên máy chủ từ xa để có thể gửi lại các ảnh chụp nhanh trung gian / bị thiếu.

Nếu bạn muốn có kết nối an toàn đến máy chủ từ xa, bạn thực sự có rất ít sự lựa chọn ngoài việc sử dụng ssh- hoặc có thể thiết lập một đường hầm với openvpnhoặc một cái gì đó và sử dụng netcat.


Còn việc sử dụng Zrep thì sao? bolthole.com/solaris/zrep
Xdg

dunno, không bao giờ sử dụng nó. Có vẻ như nó sẽ là một câu trả lời hay, mặc dù nếu ai đó thực hiện một nghiên cứu và thử nghiệm nhỏ và viết nó lên (đó là một gợi ý).
cas

Tôi đã thử nghiệm nó trên Ubuntu (ZFS trên linux) và nó không hoạt động trên các bộ dữ liệu sâu hơn (tank / cái gì đó / một số thứ khác). Tôi đã sử dụng cổng này để shell - link . Cờ đệ quy export ZREP_R=-Rhoàn toàn không hoạt động. :(
Xdg

1

Hãy xem 'zrepl', trên FreeBSD, có thể làm cho cuộc sống của bạn, và bất cứ ai về vấn đề đó, dễ dàng hơn rất nhiều. Nó đã được trình bày vài ngày trước trong BSDCan2018 tại Ottawa. Nó có vẻ đầy hứa hẹn và có thể là một giải pháp cho các vấn đề của bạn



Câu hỏi trong Câu hỏi là: "Làm cách nào để tôi thiết lập tác vụ đồng bộ hóa để các bộ dữ liệu & bộ dữ liệu nhóm từ xa (bao gồm ảnh chụp nhanh của chúng) có thể được đồng bộ hóa với các bản ghi, bộ dữ liệu & ảnh chụp nhanh cục bộ?"
Jeff Schaller

0

zrep là một giải pháp tất cả trong một tốt đẹp, VÀ có tài liệu + móc nối về cách nhận chuyển khoản nhanh hơn so với chuyển SSH đơn giản

https://github.com/bolthole/zrep

đó cũng là nền tảng chéo: được hỗ trợ trên linux, freebsd và solaris / illumos



1
Câu hỏi trong Câu hỏi là: "Làm cách nào để tôi thiết lập tác vụ đồng bộ hóa để các bộ dữ liệu & bộ dữ liệu nhóm từ xa (bao gồm ảnh chụp nhanh của chúng) có thể được đồng bộ hóa với các bản ghi, bộ dữ liệu & ảnh chụp nhanh cục bộ?"
Jeff Schaller

Jeff, bạn có gợi ý rằng "câu trả lời" tốt nhất, sẽ là các bit cut-n-paste từ tài liệu zrep, thay vì chỉ đưa ra một tham chiếu đến zrep?
Philip Brown

1
Tôi không biết câu trả lời tốt nhất sẽ là gì, nhưng một liên kết đến phần mềm không phải là một giải pháp. Trên thực tế, nó đã được đề cập. Câu hỏi đặt ra: Hồi Làm cách nào để thiết lập tác vụ đồng bộ hóa để các zvols & bộ dữ liệu nhóm từ xa (bao gồm ảnh chụp nhanh của chúng) có thể được đồng bộ hóa với zvols, bộ dữ liệu & ảnh chụp nhanh cục bộ?
Jeff Schaller

vâng đó là câu hỏi Tuy nhiên, để hoàn thành nhiệm vụ WELL, đòi hỏi nhiều hơn một chút viết lên một trang web ở đây. Đó là lý do tại sao zrep là một shellscript 2000 dòng. Ngay cả khi một người phải loại bỏ tất cả các phần mà vấn đề ban đầu không bao giờ cần, thì vẫn sẽ có vài trăm dòng kịch bản cần thiết để thực hiện.
Philip Brown
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.