bcache trên md hoặc md trên bcache


11

bcache cho phép một hoặc nhiều ổ đĩa nhanh như ổ đĩa trạng thái rắn dựa trên flash (SSD) hoạt động như một bộ đệm cho một hoặc nhiều ổ đĩa cứng chậm hơn .

Nếu tôi hiểu đúng,

  • một ổ SSD * có thể được chỉ định để lưu trữ nhiều ổ cứng sao lưu và sau đó các thiết bị được lưu trong bộ nhớ cache có thể được RAID với mdadm
    hoặc
  • nhiều ổ cứng có thể được RAID vào một thiết bị md sao lưu duy nhất và SSD được gán cho bộ đệm

Tôi đang tự hỏi đó là cách tiếp cận saner. Tôi nhận thấy rằng việc phát triển RAID5 / 6 có thể đơn giản hơn với một hoặc một kỹ thuật khác, nhưng tôi không chắc chắn điều đó!

Có lý do chính đáng nào không (ví dụ: tăng dung lượng lưu trữ sao lưu hoặc bất kỳ thứ gì khác) để chọn một cách tiếp cận khác (đối với hệ thống tệp không gốc lớn có chứa tệp sao lưu VM)?


* bởi "một SSD" Tôi có nghĩa là một số loại thiết bị SSD dự phòng, ví dụ RAID1 của hai SSD vật lý


Trong cả hai trường hợp, tất cả các đĩa bcachesao lưu sẽ phải được định dạng bcache- vì vậy bạn sẽ phải tạo một mdmảng, định dạng đĩa kết quả hoàn toàn dưới dạng bcachephân vùng được sao lưu, liên kết nó với ổ đĩa đệm của nó và đi từ đó hoặc định dạng nhiều các đĩa với bcache, liên kết chúng với ổ đĩa đệm của chúng, sau đó định dạng nhiều đĩa thành một mảng. Trong cả hai trường hợp, có nhiều điểm thất bại có thể xảy ra, tất cả đều phụ thuộc vào khả năng tương tác giữa hai hệ thống tập tin - không đề cập đến fs cuối cùng. xem ở đây : cuộn xuống .
mikeerv

Nhờ github.com/g2p/blocks , bạn có thể chuyển đổi tại chỗ, mặc dù có một số hạn chế đối với việc này.
Adam Ryczkowski

@mikeerv Tôi hiểu tất cả điều đó, đây là cho một máy chủ được xây dựng có mục đích nên tất cả đều tốt. "Hai hệ thống tập tin" nghĩa là gì? bcache không phải là một hệ thống tập tin - hệ thống tập tin duy nhất tôi sẽ có là XFS trên thiết bị bcache hoặc mdadm cuối cùng (tùy thuộc vào tùy chọn tôi chọn).

Cảm ơn @Adam, chuyển đổi tại chỗ không phải là vấn đề đối với tôi.

@mikeerv không, không phải vậy. Các hệ thống tập tin (ví dụ: btrfs, xfs, extN, v.v.) sống trên các thiết bị khối. mdadm và bcache hoạt động ở cấp thiết bị khối không ở cấp hệ thống tập tin (btrfs nhầm lẫn vấn đề với vi phạm phân lớp, nhưng đó là một cuộc trò chuyện hoàn toàn riêng biệt).

Câu trả lời:


4

Tôi nghĩ rằng bộ nhớ đệm toàn bộ thiết bị md có ý nghĩa nhất.

Đặt bcache để lưu trữ toàn bộ thiết bị md hy sinh toàn bộ ý tưởng về việc đột kích, bởi vì nó giới thiệu một điểm thất bại duy nhất khác.

  • Lỗi OTH của đĩa SSD là tương đối hiếm và bcache có thể được đưa vào chế độ writethrough/ writearound(trái ngược với writebackchế độ), trong đó không có dữ liệu được lưu trữ chỉ cho thiết bị bộ đệm và lỗi bộ nhớ cache không giết chết thông tin trong cuộc đột kích làm cho nó một lựa chọn tương đối an toàn.

  • Một thực tế khác là có phần lớn tính toán đáng kể của RAID-5 mềm; khi lưu riêng từng thành viên đột kích quay vòng, máy tính vẫn phải tính lại tất cả các chẵn lẻ, ngay cả trên các lần truy cập bộ đệm

  • Rõ ràng, bạn sẽ hy sinh một số không gian ssd đắt tiền, nếu bạn lưu trữ riêng từng ổ đĩa. - Trừ khi bạn có kế hoạch sử dụng bộ đệm ssd đột kích.

  • Cả hai tùy chọn tương đối không ảnh hưởng đến thời gian của quá trình phát triển - mặc dù tùy chọn với các ổ đĩa quay được lưu trữ riêng biệt có khả năng bị chậm hơn do lưu lượng xe buýt nhiều hơn.

Đó là quá trình nhanh chóng và tương đối đơn giản để cấu hình bcache để loại bỏ ổ đĩa ssd, khi bạn cần thay thế nó. Nhờ các khối nên có thể di chuyển thiết lập đột kích cả hai cách tại chỗ.

Bạn cũng nên nhớ rằng, tại thời điểm hiện tại hầu hết (tất cả?) Các bản phân phối CD trực tiếp không hỗ trợbcache , vì vậy bạn không thể truy cập dữ liệu của mình bằng các công cụ như vậy bất kể tùy chọn bcache- mdraidbố cục bạn đã chọn.


1
Tôi đã cập nhật câu hỏi để làm rõ rằng tôi không có kế hoạch để có bộ nhớ cache SSD không dư thừa. Điểm đạn thứ hai của bạn là một điểm tuyệt vời, cảm ơn vì điều đó. Bạn nói về không gian thứ ba: ý bạn là vì bạn đang lưu trữ chẵn lẻ trên SSD? Đây là lần cuối cùng của bạn, tôi đang sử dụng F20 nhưng cuối cùng sẽ sử dụng RHEL / CentOS7 hoặc Debian Jessie (nếu bcache-tools thực hiện việc cắt giảm).

@JackDoumund Viên đạn thứ 3 của Ad: Vâng, chính xác là như vậy. Nhưng vì bạn có kế hoạch sử dụng ổ đĩa ssd đột kích, điều đó không áp dụng cho bạn.
Adam Ryczkowski

1
Nó vẫn như vậy bởi vì chúng sẽ không chỉ được nhân đôi mà còn cần lưu trữ chẵn lẻ RAID cho các ổ đĩa sao lưu. Đây không phải là trường hợp nếu RAID được thực hiện bên dưới bcache mà tôi nghĩ là quan điểm của bạn

Tôi tin rằng bạn có nghĩa ngược lại: ma trận ssd không phải lưu trữ tính chẵn lẻ của đĩa quay, nếu nó được cung cấp cho toàn bộ ổ đĩa sợ.
Adam Ryczkowski

1
vâng, đó chính xác là những gì tôi muốn nói!

1

Tôi nghĩ cách tiếp cận lành mạnh là lưu trữ thiết bị MD kết quả.

bcache được thiết kế để đọc và ghi tuần tự qua máng.

Nếu bạn bcache mỗi thiết bị một cách riêng biệt, một cách hợp lý, một số thiết bị tước thành một MD đột kích hoặc bị tước, từ quan điểm của bcache, sẽ liên tục viết các khối ngẫu nhiên.

Mặc dù âm lượng MD bcached sẽ trông như bình thường, ghi tệp vào âm lượng, thay vào đó là khối ngẫu nhiên cho một số thiết bị.

Toàn bộ điểm của cuộc đột kích cứng và phần mềm là thực hiện việc tách dữ liệu trong phần phụ trợ để hệ thống tệp kết quả trông giống như một ổ đĩa bình thường.

Điều này có thể không đúng (vì các nhà phát triển bcache có thể thông minh và giải thích cho tình huống đó), nhưng điều tối ưu logic phải làm là lưu trữ bộ nhớ cache, thay vì chặn thiết bị.


cũng là một điểm rất tốt

Ghi tuần tự lớn vào RAID5 / 6 tạo ra ghi tuần tự cho tất cả các thiết bị thành phần. Mỗi thiết bị thành phần nhận được mọi khối dữ liệu N-1 (hoặc chẵn lẻ), nhưng dữ liệu mà nó nhận được là tuần tự. Nhưng bạn nói đúng rằng nó sẽ bóp méo mọi thứ. Nếu có một số đoạn nhìn thấy ghi một phần thường xuyên, dẫn đến đọc-sửa-ghi của (một phần) dải chẵn lẻ, có thể được lưu trữ bởi bcache. Bộ nhớ đệm cao hơn, trước khi ghi một phần sọc từng chạm vào thiết bị MD, thậm chí còn tốt hơn nữa.
Peter Cordes
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.