Đề xuất lưu trữ không đồng nhất dự phòng ZFS hoặc LVM hoặc MD


10

Tôi có cùng một vấn đề với hầu hết mọi người: làm thế nào để tạo ra một giải pháp lưu trữ cá nhân đáng tin cậy với thực tế là:

  1. Ổ cứng không thành công với sự đều đặn đáng báo động. Mất tập tin là không thể chấp nhận.
  2. Thỉnh thoảng tôi sẽ mua một ổ cứng mới. Chắc chắn, giá / GB tốt nhất là một kích thước khác so với lần mua ổ cứng cuối cùng.
  3. 2 có nghĩa là theo thời gian tôi có một bộ sưu tập đĩa không đồng nhất. Tôi muốn sử dụng tất cả chúng, và các đĩa bị lỗi thường sẽ được thay thế bằng các đĩa lớn hơn.

  4. Toàn vẹn dữ liệu và độ tin cậy đối với tôi quan trọng hơn tốc độ.

Vì vậy, sau khi đập đầu vào vấn đề này trong vài ngày (và ở phía sau đầu của tôi trong nhiều năm), tôi đề xuất giải pháp sau đây. Tôi sẽ mô tả một giải pháp mà tôi đã thử nghiệm dựa trên ZFS linux có sẵn trong Ubuntu PPA , nhưng LVM, MD và btrfs có thể được sử dụng để đạt được điều tương tự. Đối với điều này, tôi sẽ sử dụng RAID1 (ZFS mirror vdevs).

  1. Cho tập hợp các ổ đĩa của bạn, nhóm chúng thành hai bộ đĩa, sao cho dung lượng của mỗi bộ càng gần nhau càng tốt.
  2. Phân vùng các đĩa lớn hơn sao cho có một phân vùng có cùng kích thước với một trong các đĩa nhỏ hơn, trong nhóm khác.
  3. Tạo vdevs sao cho mỗi đĩa có gương của nó trên một đĩa khác.

Ví dụ: hãy xem xét một bộ đĩa của ổ đĩa 2TB mới, ổ đĩa 750 GB cũ hơn, 2 ổ đĩa 400 GB cũ hơn và một ổ đĩa 500 GB cũ hơn. Phân vùng được nhân đôi tối ưu có 2TB không gian có thể sử dụng và được mô tả trong sơ đồ sau trong đó ':' phân tách các phân vùng và '|' tách đĩa:

+------------------------------------------------------------------+
| 2TB (sda1)        : (sda2)       : (sda3)       : (sda4)         |
+------------------------------------------------------------------+--+
| 750 GB (sdb)      | 400 GB (sdc) | 400 GB (sdd) | 500 GB (sde1)  :XX|
+---------------------------------------------------------------------+

Tạo zpool của bạn như

zpool create archive mirror /dev/sda1 /dev/sdb mirror /dev/sda2 /dev/sdc mirror /dev/sda3 /dev/sdd mirror /dev/sda4 /dev/sde1

Điều này tạo ra 4 vdev nhân đôi. Nếu bất kỳ một trong các đĩa bị lỗi, nó có thể được thay thế (với bất kỳ kích thước đĩa nào) và phân vùng để tạo lại các phân vùng bị thiếu. Điều quan trọng là các vdev ZFS có thể được thêm vào một nhóm nhưng không bị xóa . Vì vậy, nếu có thể, khi một người mua một ổ đĩa mới, bạn muốn sắp xếp lại các vdevs hiện có. Giả sử lần mua tiếp theo là ổ 3TB. Cấu hình tối ưu của bạn là 3,5TB có thể sử dụng, như được mô tả trong sơ đồ sau. Bây giờ là 5 cặp vdev. Điều này có thể đạt được bằng cách phân vùng thích hợp và liên tiếp thất bại và phân vùng lại các ổ đĩa.

+--------------------------------------------------------------+-------------+
| 3 TB (sdf1)       : (sdf2)      : (sdf3)      : (sdf4)       | 500GB (sde) |
+--------------------------------------------------------------+-------------+-+
| 2TB (sda1)        | 400GB (sdb) | 400GB (sdc) | 750GB (sdd1) : (sdd2)      :X| 
+------------------------------------------------------------------------------+

Việc duy trì việc ghép các ổ đĩa nhân đôi này cũng có thể được thực hiện với LVM hoặc với MD RAID, ý tưởng là đảm bảo mỗi ổ đĩa luôn có một ổ đĩa gương hoặc phân vùng. Bởi vì mọi thứ đều được nhân đôi, chúng tôi có thể tự do thất bại các ổ đĩa và sắp xếp lại các phân vùng khi các ổ đĩa được thêm hoặc xóa. Sử dụng LVM hoặc MD, có thể loại bỏ các ổ đĩa và thu nhỏ mảng, nếu muốn, với chi phí cho các công cụ khôi phục ít phức tạp hơn trong ZFS so với BTRFS.

Bất kỳ ý kiến ​​về thủ tục này? Một kịch bản tốt có thể xử lý việc phân bổ và sắp xếp lại các ổ đĩa. Bạn có nhận xét gì về LVM so với MD so với ZFS không? Bất kỳ ý kiến ​​về hiệu suất của mảng phân vùng kỳ lạ kết quả? Sắp xếp dữ liệu trên nhiều phân vùng trên cùng một ổ đĩa sẽ gây ra tình trạng tìm kiếm quá mức và thất bại sớm?

Nhà phát triển BTRFS: mọi người đều muốn điều này và LVM hoặc MD không cần thiết về mặt kỹ thuật (và theo tôi, không tối ưu). Làm cho nó dễ dàng để duy trì một mảng không đồng nhất dư thừa sẽ là một tính năng giết người cho btrfs. Đó là một hack trên LVM / MD / ZFS. Tối thiểu hóa resliver / resync là mong muốn ồ ạt.

Vâng, đây rõ ràng là một Dropbo của người nghèo. Bạn không cần phần cứng chuyên dụng cho điều đó ...

Câu trả lời:


4

Tôi đã thử nghiệm điều này với ZFS và hiệu suất ghi là khoảng một nửa so với mức cần thiết, bởi vì ZFS phân phối đọc và ghi trên tất cả các vdev (do đó chia I / O cho một số vị trí trên cùng một đĩa). Do đó, tốc độ bị giới hạn bởi tốc độ của đĩa có nhiều phân vùng nhất. Tốc độ đọc dường như bằng với băng thông đĩa. Lưu ý rằng một cặp phân vùng ZFS trên hai đĩa có tốc độ đọc gấp đôi một đĩa, bởi vì nó có thể đọc song song từ các đĩa.

Sử dụng mảng MD LINEAR hoặc LVM để tạo hai nửa kết quả với hiệu suất ghi gấp đôi so với đề xuất ZFS ở trên, nhưng có nhược điểm là LVM và MD không biết dữ liệu được lưu trữ ở đâu. Trong trường hợp hỏng đĩa hoặc nâng cấp, một bên của mảng phải bị hủy hoàn toàn và được cấp lại / gửi lại, tiếp theo là phía bên kia. (ví dụ: resync / resliver phải sao chép 2 * (kích thước của mảng))

Do đó, có vẻ như giải pháp tối ưu là tạo một gương ZFS vdev duy nhất trên hai thiết bị LVM hoặc MD LINEAR kết hợp các đĩa thành các "nửa" có kích thước bằng nhau. Điều này có khoảng gấp đôi băng thông đọc của bất kỳ một đĩa nào và băng thông ghi bằng với băng thông đĩa riêng lẻ.

Sử dụng BTRFS raid1 thay vì ZFS cũng hoạt động, nhưng có một nửa băng thông đọc vì ZFS phân phối số lần đọc của nó để tăng gấp đôi băng thông, trong khi BTRFS xuất hiện thì không (theo thử nghiệm của tôi). BTRFS có lợi thế là các phân vùng có thể được thu hẹp, trong khi chúng không thể với ZFS (vì vậy nếu sau khi thất bại, bạn có nhiều khoảng trống, với BTRFS, bạn có thể xây dựng lại một mảng dự phòng nhỏ hơn bằng cách thu nhỏ hệ thống tệp, sau đó sắp xếp lại các đĩa).

Điều này là tẻ nhạt để làm bằng tay nhưng dễ dàng với một số kịch bản tốt.

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.