ZFS cho người mới bắt đầu

 (ikrima.dev)
2 điểm bởi GN⁺ 2023-09-06 | 1 bình luận | Chia sẻ qua WhatsApp
  • Một hướng dẫn nhập môn tổng hợp từ khắc phục sự cố ZFS trên FreeNAS, cấu hình volume mới cho đến chiến lược sao lưu; trình bày liền mạch các cấu trúc và lệnh cần thiết khi vận hành ZFS lần đầu
  • ZFS vừa cung cấp filesystem vừa là trình quản lý volume logic; sau khi bắt đầu tại Sun Microsystems, trên Linux, FreeBSD và các hệ thống khác hiện chủ yếu dùng mã OpenZFS
  • Cấu trúc cơ bản được chia thành vdev gom các đĩa vật lý, pool tập hợp các vdev, dataset đóng vai trò filesystem, và volume ở dạng block device; RAIDZ-1/2/3 lần lượt chịu được lỗi 1, 2, 3 đĩa
  • Các lệnh thực tế xoay quanh zpool create/status/list/import/export/destroy/scrub và zfs create/mount/list/get/set/snapshot/diff/rollback/send/recv/destroy; để tránh vấn đề do tên thiết bị thay đổi, nên dùng device UUID
  • snapshot bảo vệ nhẹ trạng thái tại một thời điểm cụ thể và có thể được sao chép sang pool hoặc hệ thống khác bằng zfs send/recv, nhưng chỉ snapshot thì khó thay thế backup hoặc DR

Khái niệm cơ bản về ZFS

  • ZFS là một filesystem cục bộ như ext4, NTFS, exFAT, đồng thời cũng đảm nhiệm vai trò trình quản lý volume logic như LVM trên Linux
  • ZFS do Sun Microsystems tạo ra, và mã nguồn ZFS từng được công bố theo giấy phép mã nguồn mở cho đến trước khi Oracle mua lại Sun
  • Vì phần mã đã công khai trước đó đã được port sang nhiều OS, dự án OpenZFS sau này được tạo ra, và phần lớn các hệ thống họ Unix như Linux và FreeBSD dùng mã này
  • Nội dung được tổng hợp từ góc nhìn người mới bắt đầu để người lần đầu tiếp cận ZFS có thể hiểu cấu trúc và các lệnh vận hành

Thành phần cấu thành ZFS

  • vdev gồm một hoặc nhiều ổ đĩa vật lý, và ngoài ổ cứng còn có thể bao gồm cả file
    • Có thể kết hợp theo dạng mirror hoặc RAIDZ
    • Có 7 loại vdev, bao gồm các loại quan trọng như hot spare, L2ARC, ZIL
  • pool gồm một hoặc nhiều vdev, và thường tạo volume hoặc dataset bên trong pool
    • Khi tạo pool bằng lệnh zpool, vdev được định nghĩa cùng lúc
    • Có thể trộn nhiều loại vdev để cấu hình cấp RAIDZ
  • dataset là thành phần tương ứng với filesystem trong ZFS
    • Có thể thiết lập quyền truy cập người dùng, quota, nén, snapshot, v.v.
  • volume tương tự dataset nhưng cung cấp biểu diễn dạng block device
    • Chỉ cung cấp một phần chức năng của dataset
    • Hữu ích khi chạy filesystem khác trên ZFS hoặc xuất iSCSI extent

Các loại RAIDZ

  • Dynamic/Simple Stripe, tức RAID0, phân tán dữ liệu không có parity; nếu mất một thiết bị thì mất toàn bộ dữ liệu
  • MIRROR, tức RAID1, mirror các đĩa và được dùng với 2–4 đĩa hoặc nhiều hơn
  • RAIDZ-1, tức RAID5, phân tán parity cùng với dữ liệu và có thể chịu mất 1 ổ đĩa vật lý trước khi RAID hỏng
    • RAIDZ cần tối thiểu 3 đĩa
  • RAIDZ-2, tức RAID6, có thể chịu mất tối đa 2 ổ đĩa vật lý
    • RAIDZ-2 cần tối thiểu 4 đĩa
  • RAIDZ-3 chịu được mất tối đa 3 ổ đĩa vật lý
    • Cần tối thiểu 4 đĩa, nhưng tốt hơn là không dùng với dưới 5 đĩa

Tạo pool và kiểm tra trạng thái

  • ZFS pool được tạo theo dạng zpool create [pool] [devices]
    • Ví dụ pool một đĩa: zpool create tank /dev/sdb
    • Ví dụ stripe 3 đĩa: zpool create tank /dev/sdb /dev/sdc /dev/sdd
    • Ví dụ mirror 2 đĩa: zpool create tank mirror sdb sdc
    • Ví dụ RAIDZ pool: zpool create tank raidz sdb sdc sdd
    • RAIDZ2/3 có thể tạo theo dạng zpool create [pool name] raidz[1,2,3] [devices]
  • Khi tạo pool, có thể chỉ định mount point mặc định bằng flag -m
    • Ví dụ: zpool create tank -m /mnt/tank mirror sdb sdc
  • Trong ví dụ dùng tên thiết bị dạng /dev/sdx, nhưng để tránh vấn đề khởi động do tên thiết bị thay đổi, nên dùng device UUID
  • zpool status là lệnh cơ bản để kiểm tra trạng thái pool
    • state cho biết pool có online hay không
    • status hiển thị thông tin bổ sung về pool
    • action cho biết các bước tiếp theo cần thực hiện
    • scan hiển thị tiến trình scrub hoặc trạng thái lần scrub gần nhất
    • errors cho biết pool có vấn đề hay không
  • zpool list hiển thị các chi tiết như kích thước pool, dung lượng đã cấp phát, dung lượng trống, fragmentation, capacity, dedup, health
  • zpool history hiển thị lịch sử các lệnh đã dùng để thay đổi cấu hình kể từ khi pool được tạo

Import, export, xóa pool và scrub

  • Sau khi tạo, pool thường được import và mount tự động, nhưng sau khi khắc phục sự cố hoặc re-image hệ thống, có thể cần import thủ công
  • Chạy zpool import không kèm tên pool sẽ hiển thị danh sách các pool có thể import
    • Nếu không có pool nào có thể import, thông báo no pools available to import sẽ được hiển thị
    • Nếu chỉ định tên pool, pool đó sẽ được import; lệnh import cũng thực hiện mount pool
    • zpool import -a import tất cả pool có thể import
  • Dùng -R như zpool import -R /mnt/tank2 tank sẽ mount vào vị trí alternate root
    • Đây không phải mount path của chính pool, mà là thư mục root thay thế
  • zpool export [pool name] là thao tác ngược với import: unmount các filesystem đã mount trong pool rồi thử export
    • Nếu unmount filesystem thất bại, có thể dùng -f để buộc unmount
    • Nếu có ZFS volume đang được sử dụng, export vẫn thất bại ngay cả khi dùng -f
  • zpool destroy xóa pool và các dataset hoặc volume con của nó
    • Cần cẩn trọng vì toàn bộ dữ liệu và cả snapshot cũng sẽ bị xóa
  • ZFS scrub kiểm tra tính hợp lệ dữ liệu bằng cách so sánh mọi block trong pool với checksum đã biết
    • Với vdev có parity, dữ liệu hỏng được phục hồi bằng dữ liệu từ các đĩa bình thường
    • Để duy trì tình trạng hệ thống, cần chạy scrub theo lịch
    • Bắt đầu: zpool scrub [pool]
    • Kiểm tra trạng thái: xem vùng scan trong zpool status
    • Dừng: zpool scrub -s [pool]

Tạo và mount dataset

  • zfs create là lệnh tạo filesystem hoặc volume mới; ở đây tập trung vào dataset hơn là volume
  • zfs create tank/dataset1 tạo dataset1 bên dưới tank
    • Dataset tank được tạo tự động khi chạy zpool create
  • zfs create -p tạo cả các dataset cha chưa tồn tại, giống mkdir -p
    • Nếu dataset cha không tồn tại, zfs create thông thường sẽ thất bại
  • Chạy zfs mount không có đối số sẽ hiển thị các ZFS filesystem hiện đang được mount và mount point của chúng
    • Kết quả này không bao gồm child dataset
  • zfs mount [pool|dataset] mount filesystem được chỉ định
    • zfs mount -a mount tất cả filesystem
  • Child dataset có thể được mount ngay cả khi không có parent dataset
    • Trong trường hợp này, đường dẫn cần thiết sẽ được tạo trong OS filesystem
    • Nếu sau đó cố mount parent dataset, có thể gặp lỗi directory is not empty do thư mục đã được tạo
  • zfs unmount [dataset] unmount dataset được chỉ định

Truy vấn dataset và thiết lập thuộc tính

  • zfs list [dataset name] hiển thị thông tin về dataset được chỉ định
    • Cũng có thể truyền mount point làm đối số thay cho tên dataset
  • Chạy zfs list không kèm tên dataset sẽ hiển thị đệ quy tất cả dataset trong hệ thống
  • Khi chỉ định tên dataset, dùng flag -r để hiển thị đệ quy bên dưới dataset đó
  • ZFS property điều khiển hành vi của filesystem, volume, snapshot, clone
    • Có thể trông tương tự mount option
  • zfs get all [dataset] hiển thị tất cả property của dataset
  • Kiểm tra giá trị của một property cụ thể như zfs get compression tank
  • Dùng zfs set để thiết lập property
    • Ví dụ: zfs set compression=lz4 tank
    • Sau khi thiết lập, có thể xác nhận giá trị compression đã đổi thành lz4 bằng zfs get compression tank

Cách snapshot hoạt động và ứng dụng

  • snapshot lưu trạng thái filesystem tại một thời điểm cụ thể nhưng không sao chép file
  • snapshot đánh dấu dữ liệu hiện có là read-only; dữ liệu mới được thêm vào filesystem sau đó không ảnh hưởng đến các data block hiện có mà snapshot bảo vệ
  • Luồng ví dụ như sau
    • Tạo snapshot 1 trên filesystem đang có dữ liệu Data A
    • Sau đó thêm Data B và tạo snapshot 2
    • Sau đó thêm Data C
    • snapshot 1 bảo vệ Data A, còn snapshot 2 bảo vệ Data A và Data B
    • Dù xóa snapshot 1, Data A vẫn tiếp tục được bảo vệ bởi snapshot 2
  • Dung lượng dữ liệu mà snapshot sử dụng rất nhỏ
    • Vì thay vì sao chép file, nó ghi metadata block cấp cao nhất của filesystem cho biết dữ liệu thuộc về snapshot
  • snapshot hữu ích trong kiểm thử phát triển phần mềm hoặc tạo failsafe trước khi nâng cấp
  • Không nên xem chỉ riêng snapshot là giải pháp backup hoặc DR

Lệnh snapshot

  • Tạo snapshot dùng dạng zfs snapshot [pool/dataset@snapshot_name]
    • Ví dụ: zfs snapshot tank/dataset1@snapshot1
  • Xem danh sách snapshot bằng zfs list -t snapshot
  • Nếu có nhiều child dataset, có thể tạo snapshot trên top-level dataset hoặc tạo snapshot recursive bằng flag -r
    • Ví dụ snapshot thông thường: zfs snapshot tank@snapshot-master
    • Ví dụ snapshot recursive: zfs snapshot -r tank@recursive
  • zfs diff [older snapshot] [newer snapshot] so sánh khác biệt giữa các snapshot
    • Trong output, có thể kiểm tra file được thêm và các đường dẫn đã sửa đổi
  • Khôi phục snapshot bằng zfs rollback [pool/dataset@snapshot_name]
    • Khi rollback, các file được tạo sau snapshot sẽ bị xóa
    • Các snapshot mới hơn cũng bị xóa, và trong trường hợp này có thể được yêu cầu dùng tùy chọn -r

ZFS send/recv và sao chép

  • ZFS send là chức năng có thể gửi snapshot dưới dạng data stream
  • Có thể sao chép snapshot và dataset vào file, pool khác, hoặc hệ thống khác thông qua SSH
  • Ví dụ dùng hai pool tên là tank và backup
    • Dataset tank/Movies có 1.50G dữ liệu
    • Trước khi truyền, tạo snapshot bằng zfs snapshot tank/Movies@$(date '+%Y-%m-%d_%H-%M')
    • Truyền snapshot sang backup pool bằng zfs send tank/Movies@2020-11-03_15-29 | zfs recv backup/Movies
  • Sau khi truyền, zfs list hiển thị cả backup/Movies và tank/Movies, và zfs list -t snapshot cũng cho thấy snapshot ở cả hai phía
  • zfs send là chức năng đáng tìm hiểu với nhiều tùy chọn và trường hợp sử dụng; khi dùng cùng RAIDZ và snapshot, nó có thể làm filesystem vững chắc hơn

Xóa dataset và snapshot

  • Xóa dataset dùng dạng zfs destroy [pool/dataset]
    • Cũng có thể dùng flag -r
  • Xóa snapshot cũng dùng zfs destroy [pool/dataset@snapshot_name]
    • Khi xóa snapshot cũng có thể dùng flag -r
  • ZFS cung cấp nhiều chức năng hơn, nhưng tài liệu này gần với điểm khởi đầu để nắm các khái niệm và lệnh cơ bản

Tài liệu tham khảo

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-09-06
Các ý kiến trên Hacker News
  • Tôi mới bắt đầu dùng ZFS, và đường cong học tập dốc hơn tôi tưởng. Giá mà có một wrapper dễ dùng giúp đơn giản hóa tối đa các trường hợp sử dụng phổ biến
    Ví dụ khi tạo pool thì cứ dùng các giá trị mặc định hợp lý như ashift=12, nén lz4, xattr=sa, acltype=posixacl, atime=off, còn mã hóa thì chỉ cần bật/tắt thay vì nhiều tùy chọn
    Nó nên tạo khóa mã hóa, thiết lập một service systemd để giải mã pool khi khởi động, và hướng dẫn sao lưu khóa. zfs list nên hiển thị dataset đã được mount hay chưa, có mã hóa hay không, và khóa đã được nạp hay chưa
    Nên bỏ dataset đệ quy, và dùng {pool}:{dataset} thay vì {pool}/{dataset} để phân biệt rõ pool với dataset. Tên pool hoặc snapshot cũng không nên bắt người dùng tự đặt; nên tự động gán các quy tắc như {hostname}-[A-Z], {pool name}_{datetime created} và tên rút gọn dạng số
    Khi tạo pool, đừng bắt nhập disk ID thủ công; nên cho tạo bằng /dev/sda, /dev/sdb rồi lưu metadata lên đĩa để dù đổi thứ tự ổ vẫn không bị nhầm
    Tiến trình nên luôn được hiển thị bằng pv, và nên tự động thiết lập scrub hằng tuần cùng snapshot theo giờ/ngày/tuần/tháng và dọn dẹp định kỳ
    Nếu gửi dữ liệu sang một đĩa chưa có pool, sau khi xác nhận thì nên tạo một pool một đĩa với cùng cấu hình như pool gửi, và zpool với zfs nên được gộp thành một lệnh duy nhất
    Khi gửi dataset đã mã hóa, nên tự động dùng --raw; mặc định gửi nên là --replicate, và nếu có thể thì dùng -I. Cũng cần có cách mount và duyệt dataset snapshot dễ dàng, thay vì giấu filesystem snapshot trong một thư mục ẩn
    • Có sự pha trộn giữa các đề xuất hợp lý và gu cá nhân rất mạnh. Tôi hiểu mặc định ashift=12 hay cú pháp {pool}:{dataset}, nhưng có vẻ đã quá muộn để đổi, và một số đề xuất có thể làm hỏng các trường hợp sử dụng mà ta chưa biết
      Cách đặt tên pool theo hostname không phù hợp với SAN pool, vốn có thể được import từ nhiều host
      Theo tôi, scrub hằng tuần, snapshot định kỳ và dọn dẹp định kỳ là việc của scheduler của hệ điều hành. Gộp zpool và zfs cũng có thể làm được, nhưng cuối cùng sẽ thành kiểu zfs -pool XXXX, zfs -volume XXXX; tôi không hiểu tại sao lại cần
      Dataset đệ quy thực sự có những lúc hữu ích. Ngược lại, tôi hoàn toàn đồng ý rằng zfs list nên cho biết trạng thái mount, có mã hóa hay không, và khóa đã được nạp hay chưa
      Phần “đừng bắt nhập disk ID” thì hơi mơ hồ. Có thể chỉ định bằng ID, WWN, label, sdX và nhiều cách khác, nhưng dù sao vẫn phải cho hệ thống biết sẽ dùng đĩa nào
      Tính năng lưu metadata lên đĩa để vẫn tìm được sau khi đổi thứ tự đã có rồi. Dù rút cắm đổi chỗ vài ổ rồi import pool, nó vẫn tìm ra
      Một số đề xuất ổn nếu làm mặc định, nhưng vài đề xuất dường như chưa cân nhắc đủ các nhu cầu và kiểu sử dụng ngoài trường hợp của bản thân. ZFS nhắm tới tập người dùng rộng hơn nhiều
    • Việc tạo pool bằng /dev/sda, /dev/sdb rồi nói ZFS bị nhầm, nói thật thì gần với vấn đề của người dùng vì không dùng đúng cách hiện đại hơn là vấn đề của ZFS
      Trên Linux từ khá lâu đã có tham chiếu đầy đủ như /dev/disk/by-id/ata-$manufactuer-$serial-$whatever. Khi tạo pool nên dùng những đường dẫn kiểu này
    • Nhiều đề xuất mang nặng gu cá nhân; bản thân điều đó không xấu, nhưng trông như đang cố làm lung lay các quy ước hiện có. Chẳng hạn tôi không hiểu vì sao phải là {pool}:{dataset}
      Nếu không muốn tự đặt tên snapshot, công cụ nhỏ tôi viết https://github.com/rollcat/zfs-autosnap có thể phù hợp
      Đưa zfs-autosnap snap vào cron chạy hằng giờ và zfs-autosnap gc chạy hằng ngày thì nó sẽ xoay vòng lịch sử snapshot theo chính sách lưu giữ
      Dùng một wrapper lệnh ZFS đơn giản không khó, nên bạn có thể lấy code của tôi để làm công cụ riêng
    • Tôi từng đọc rằng một trong những bài kiểm tra cuối cùng của thợ rèn học việc là tự làm mọi công cụ mà một thợ rèn thực thụ sẽ dùng, tức là đe, búa, kìm, v.v.
      Ở chỗ làm, tôi cũng đã viết nhiều script để tạo mảng ZFS phù hợp với kiểu triển khai dự kiến cho ngày hôm đó. Trong đó có tạo volume mã hóa LUKS để đặt zvol lên, chuẩn hóa quy tắc đặt tên, đặt các mặc định như ashift=12, nén lz4
      Đó là chuyện từ rất lâu trước khi ZFS có mã hóa tích hợp, và vì cách hiện tại vẫn ổn nên tôi chưa cập nhật script để hỗ trợ mã hóa của ZFS
      Giờ tôi không còn nhớ nhiều flag nữa, nhưng script đóng vai trò như tài liệu, và những người khác trong nhóm chỉ cần chạy make-zfs-big-mirror hoặc make-big-zfs-undundant-raid0
      Một ngày nào đó nếu phải provision hệ thống hơn 20 lần mỗi năm, ngay cả việc đó cũng có thể được tự động hóa bằng provisioning
    • Như những người khác đã nói, đây là các đề xuất rất nặng gu cá nhân. Có quan điểm thì không sao, nhưng nhiều mục trải từ “không giống cách tôi quen dùng trên Linux” cho đến các đề xuất thực sự có vấn đề
      Không đặt tên pool là vô lý. Bạn đâu có tạo pool thường xuyên đến vậy, cứ đặt tên là được
      Nếu không muốn tự đặt tên snapshot, có thể dùng httm và zfs allow. Ví dụ httm -S . sẽ tạo snapshot như rpool/ROOT/ubuntu_tiebek@snap_2022-12-14-12:31:41_httmSnapFileMount
      zfs và zpool đều là các lệnh Unix tốt, mỗi lệnh có nhiều subcommand. Tôi cho rằng việc các nhà thiết kế ZFS không tạo một lệnh quản trị đơn nhất phức tạp hơn là một quyết định rất thông minh
      Việc mount và duyệt dataset snapshot một cách rõ ràng cũng có thể làm dễ dàng bằng zfs mount. Tuy vậy, tôi mong mọi người cũng tin rằng một giao diện ảo ổn định giúp tìm kiếm mọi phiên bản của file dễ hơn, và việc này khó hơn nhiều trên btrfs chẳng hạn. httm cũng đáng tham khảo
      [0]: https://kimono-koans.github.io/opinionated-guide/#dynamic-sn...

  • Còn có thêm nhiều thứ hữu ích trong ZFS. Nên biết sự khác nhau giữa zpool-attach(8) và zpool-replace(8), và zfs list -t all -o space sẽ cho thấy dung lượng đang được dùng vào đâu
    Để bảo vệ hệ điều hành trước các thay đổi lớn hoặc nâng cấp, ZFS Boot Environments là tính năng tốt nhất. https://is.gd/BECTL có thể hữu ích làm điểm bắt đầu
    zpool history poolname hiển thị toàn bộ cấu hình pool và lịch sử thay đổi. Ví dụ, các thay đổi như zpool create, autotrim=on, atime=off, compression=zstd, recordsize=1m sẽ được ghi lại
    Cũng có thông tin quan trọng bị thiếu trong hướng dẫn. Mirror 3-way vẫn giữ dữ liệu nếu 2 trong 3 đĩa hỏng, mirror 4-way vẫn giữ nếu 3 trong 4 đĩa hỏng, và mirror N-way vẫn bảo toàn dữ liệu nếu N-1 trong N đĩa hỏng
    Điều này hữu ích khi dữ liệu là quan trọng nhất nhưng không có nhiều slot hoặc đĩa

    • Mirror N-way cũng có đặc tính là ZFS có thể chia việc đọc ra nhiều đĩa để xử lý. Với các đĩa quay vốn bị giới hạn số thao tác I/O, điểm này từng khá quan trọng

  • Tôi đã vận hành cơ sở dữ liệu PostgreSQL dung lượng lớn nhiều TB trên ZFS suốt nhiều năm. Nhờ ZFS, việc sao lưu, tạo môi trường kiểm thử dựa trên snapshot cũ, và tiết kiệm dung lượng đĩa nhờ nén tích hợp trở nên rất dễ dàng
    Nếu quan tâm, có thể đọc kinh nghiệm tại https://lackofimagination.org/2022/04/our-experience-with-po...

  • Khi bắt đầu với ZFS, thứ giúp ích nhất là ZFS Handbook của FreeBSD và bài viết của Aaron Toponce
    [0] https://docs.freebsd.org/en/books/handbook/zfs/
    1 https://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux...

    • Tôi thích tài liệu FreeBSD
      Tôi đã cài FreeBSD lên một chiếc HP Microserver cũ với 1GB ECC RAM có sẵn, cũng có 5 ổ cứng 500GB cũ, rồi vừa xem FreeBSD Handbook vừa cấu hình thành mirror 5x. Đó là lần đầu dùng FreeBSD nhưng rất suôn sẻ

  • Gần đây tôi tái xây dựng khá nhiều hạ tầng chủ yếu là các máy chủ LAMP, và quyết định đặt tất cả trên ZFS trên Linux để sao lưu/nhân bản hiệu quả và mã hóa
    Tôi đã khá quen với việc dùng ZFS cùng rsync cho sao lưu từ lâu, và kết quả là ổn, nhưng khi cố làm cho đúng thì tốn thời gian hơn dự kiến rất nhiều. Đặc biệt trên web có rất nhiều lời khuyên sai về cơ sở dữ liệu và replication
    Với cơ sở dữ liệu, tối thiểu cần tinh chỉnh cơ bản như căn chỉnh kích thước block. Về mariadb/InnoDB, tài liệu của Let's Encrypt tại https://github.com/letsencrypt/openzfs-nvme-databases là vượt trội. Nó giải thích lý do cho mọi mục và trích dẫn nhiều nguồn, nên rất có giá trị
    Tìm thêm trên web sẽ thấy vô tận các lời khuyên mâu thuẫn, giai thoại và huyền thoại đi kèm những lý thuyết không đầy đủ, thiếu căn cứ. Cuối cùng bạn phải tự kiểm thử, hiểu các mục mình điều chỉnh, và việc quyết định không điều chỉnh cũng không sao
    Về replication, tôi thật sự khuyên đọc man page. ZFS cung cấp công cụ replication vững chắc, nhưng quá tổng quát nên có cảm giác như các lệnh plumbing cấp thấp của Git. Vì nó không giả định bạn sẽ dùng qua SSH, bạn phải tự nối các phần lại, và nếu muốn tự động hóa thì phải nghĩ đến cả các điều kiện biên, nên ban đầu khá đáng sợ
    Vì vậy mọi người thường tìm đến các công cụ như syncoid, nhưng các script replication kiểu syncoid có điểm rất tệ. Chúng không dùng chế độ send --replication của ZFS, mà vì cho rằng như vậy linh hoạt hơn nên đã tái triển khai không hoàn chỉnh bằng Perl
    Khi mới thử nghiệm, tôi restore mới thì phát điên khi thấy tất cả encryption root bị hỏng, và các thuộc tính dataset không được đồng bộ tự động đầy đủ. Chỉ cần dùng tùy chọn replication đệ quy tích hợp là ZFS sẽ xử lý những việc này
    Nếu quyết tâm tự viết script thì không khó. Chỉ cần giữ đơn giản và đừng nhét một đống thứ không cần thiết vào pipeline như syncoid. Khi kiểm thử thực tế, những thứ đó còn làm chậm đi. Xem tiến độ bằng pv rồi cứ đẩy đi là chạy nhanh
    Có thể một ngày nào đó tôi sẽ công khai script replication của mình. Tôi cảm thấy hầu như không có script tham khảo tốt nào vừa xử lý các phần cơ bản, vừa không tái triển khai replication một cách lộn xộn

    • Tài liệu đó có nhắc đến việc tinh chỉnh io_capacity và io_capacity_max, nhưng nếu bấm vào tài liệu MySQL để xem vai trò thực sự của các tham số này thì đáng tiếc là chúng không hữu ích lắm
      Các giá trị này kiểm soát I/O nền như việc gộp change buffer, và có thể lấy mất I/O khỏi các tiến trình chính đang thật sự cần làm việc
      Theo kinh nghiệm vận hành một MySQL DB khá bận với 120K QPS, tôi không thấy cần đụng đến cả hai. Nếu cảm thấy cần, trước tiên nên giám sát thời gian redo log đầy lên và tỷ lệ dirty page trong buffer pool. Có lẽ điều chỉnh các tham số khác sẽ tốt hơn
      [0] https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.ht...
    • Khi thực hiện các tinh chỉnh cơ bản như căn chỉnh kích thước block cho cơ sở dữ liệu, có một điểm bất ngờ cần kiểm tra. Thông thường người ta bảo hãy khớp kích thước record, và trên thực tế điều đó dẫn đến việc giảm kích thước record của filesystem ZFS chứa dữ liệu
      Ở một mức nào đó việc này có thể hiệu quả hơn, nhưng theo kinh nghiệm thì nó làm giảm mạnh tỷ lệ nén
      Một hiệu ứng phụ thú vị là, tùy workload, nếu băng thông đĩa là nút thắt thì thông lượng thậm chí có thể tệ hơn. Nhờ nén, bạn có thể đọc/ghi nhanh hơn khả năng của đĩa vật lý; nếu làm hỏng khả năng nén thì băng thông đọc/ghi có thể bị ảnh hưởng xấu

  • Tôi bắt đầu dùng ZFS trên Linux từ vài năm trước và nhìn chung mọi thứ diễn ra suôn sẻ
    Điều duy nhất làm tôi ngạc nhiên là giá trị mặc định của volblocksize khá tệ đối với hầu hết cấu hình RAIDZ. Nếu không muốn mất 50% dung lượng đĩa thô, cần tăng giá trị này lên
    Các bài viết liên quan như sau
    https://jro.io/nas/#overhead
    https://openzfs.github.io/openzfs-docs/Basic%20Concepts/RAID...
    https://www.delphix.com/blog/zfs-raidz-stripe-width-or-how-i...
    Cuối cùng tôi còn xem đến một trong các bảng tính liên quan đến ZFS
    ZFS overhead calc.xlsx
    https://docs.google.com/spreadsheets/d/1tf4qx1aMJp8Lo_R6gpT6...
    RAID-Z parity cost
    https://docs.google.com/spreadsheets/d/1pdu_X2tR4ztF6_HLtJ-D...

    • Cá nhân tôi cho rằng hiệu suất dung lượng 50% của mirror vdev là cái giá hợp lý nếu xét đến sự đơn giản và hiệu năng cải thiện đáng kể. Hiện nay pool RAIDZ cũng có thể mở rộng, nhưng vẫn phức tạp hơn nhiều và hiệu năng cũng không tốt bằng

  • Khi còn trẻ và ngốc nghếch hơn, tôi đã đọc nhiều bài của những người hâm mộ nhiệt thành viết rằng hệ điều hành NAS mã nguồn mở, có lẽ là FreeNAS, và ZFS tuyệt vời đến mức nào. Tôi mua một máy chủ micro HP cũ cấu hình rất thấp trên eBay, rồi lao vào mà không thật sự biết mình đang làm gì
    Tôi hỏi vài câu trên diễn đàn cộng đồng, nhưng phần lớn câu trả lời là “Bạn đã đọc tài liệu chưa?”, “RAM có đủ không?”
    Thứ gọi là tài liệu đó là một bộ slide PowerPoint có phong cách khó đọc, giọng văn hơi mang tính truyền giáo, giả định người đọc đã có nhiều kiến thức, và cũng không được cập nhật định kỳ. Lượng RAM cần thiết cũng mơ hồ, chủ yếu chỉ nhấn mạnh rằng hãy lắp nhiều nhất có thể
    Cuối cùng tôi đã phớt lờ mọi dấu hiệu cảnh báo về công nghệ, bầu không khí cường điệu và trình độ hiểu biết của mình, rồi mất rất nhiều dữ liệu. Tôi đã học được nhiều điều

    • Tôi tò mò không biết bạn còn nhớ đại khái chuyện đó cách đây bao lâu không. ZFS đã có từ đầu những năm 2000, và tôi nhớ FreeNAS bắt đầu vào năm 2005
      Tôi nghĩ hệ thống tệp đã ổn định hơn nhiều, và tài liệu cũng rõ ràng hơn
      Dù vậy, vì nó mạnh hơn và cao cấp hơn các hệ thống tệp journaling truyền thống như ext3, nên cũng có nhiều cách hơn để tự làm hỏng mọi thứ

  • Để ghi lại thêm vài điều cho sau này, toàn bộ tính dư thừa của ZFS nằm ở tầng vdev. zpool được tạo từ một hoặc nhiều vdev, và trong mọi trường hợp, nếu mất dù chỉ một vdev trong zpool thì zpool sẽ bị phá hủy vĩnh viễn
    Về mặt lịch sử, RAIDZ, tức RAID parity, không thể mở rộng bằng cách thêm đĩa. Cách duy nhất để tăng kích thước RAIDZ là thay từng đĩa trong mảng bằng đĩa lớn hơn, và hy vọng không có đĩa nào hỏng trong lúc rebuild
    Theo đánh giá rất nghiệp dư của tôi, tôi chỉ cân nhắc RAIDZ khi có nhiều đĩa, như RAIDZ2 hoặc RAIDZ3. Nếu n<=6 và ngân sách cho phép, tôi sẽ dùng nhiều mirror vdev. Trong môi trường vận hành, cần tìm hiểu thêm về các chỉ số hiệu năng đọc/ghi của nhiều kiểu RAID

    • Mirror pool thường đúng là cách an toàn hơn
      Tuy nhiên, tôi chỉ có thể khuyên dùng RAIDZ1 khi có backup toàn bộ tại chỗ và bạn khá tin tưởng vào năng lực cũng như hệ thống giám sát của mình
      Trường hợp của tôi có một pool 3x3 ổ đĩa, và gửi snapshot đến một đích backup nằm thấp hơn vài U trong rack. Đích backup đó thức dậy hằng ngày, có pool 3x4 ổ đĩa và cũng dùng RAIDZ1
      Nếu một ổ trong NAS hỏng, kế hoạch là khởi động backup ngay để nhận snapshot rồi thay ổ. Như vậy có thể giảm thiểu khả năng mất dữ liệu do ổ thứ hai hỏng trong lúc resilver
      Dữ liệu thật sự quan trọng thì tất nhiên cũng được lưu ở bên ngoài

  • Tôi đang gặp một vấn đề ZFS mà mình không hiểu. Trong một zpool, zpool status in ra danh sách lỗi được phát hiện, nhưng lỗi không nằm ở file mà luôn chỉ xuất hiện ở snapshot, và ở các mục dạng hex có vẻ là snapshot đã bị xóa
    Nếu xóa snapshot bị đánh dấu lỗi rồi chạy zpool scrub hai lần, lỗi biến mất và scrub cũng không tìm thấy lỗi nào. zpool status chưa từng hiển thị lỗi trên bất kỳ thiết bị nào
    Không có lỗi ở file, không có lỗi ở thiết bị, scrub cũng không phát hiện lỗi, nhưng khi đang chạy thì mỗi ngày lại có khoảng 12 “lỗi” mới xuất hiện trong zpool status. Tôi không hiểu chuyện này có thể xảy ra như thế nào

    • Câu hỏi rất hay. Hiện tôi không có thời gian tự tìm các issue trùng lặp, nhưng bạn có thể tìm hoặc đặt câu hỏi trên mailing list https://zfsonlinux.topicbox.com/groups/zfs-discuss và GitHub issue https://github.com/openzfs/zfs/issues
      Cái trước trông có vẻ lạ, nhưng là giao diện web bình thường của mailing list
    • Tôi cũng gặp cùng vấn đề. Thỉnh thoảng một file có vẻ bị hỏng không chỉ trong snapshot mà cả ở phiên bản file hiện tại
      Không thể di chuyển hay sửa đổi, chỉ có thể xóa. Tôi hoàn toàn không có manh mối vì sao những file này bị hỏng. May là tất cả đều là các file ISO Linux lớn nên không đến mức nghiêm trọng