Xin chào, gần đây tôi gặp phải một vấn đề thú vị: thiết lập bộ nhớ để sao lưu một số lượng lớn thiết bị khối.
Hàng tuần, chúng tôi sao lưu tất cả các máy ảo trên đám mây của mình, vì vậy chúng tôi cần có khả năng duy trì hàng nghìn bản sao lưu và thực hiện việc đó một cách nhanh chóng và hiệu quả nhất có thể.
Thật không may, cấu hình tiêu chuẩn RAID5, RAID6 trong trường hợp này, chúng tôi sẽ không được phép làm như vậy, vì quá trình khôi phục trên các đĩa lớn như của chúng tôi sẽ rất lâu và rất có thể sẽ không bao giờ kết thúc.
Hãy xem có những lựa chọn thay thế nào:
— Tương tự như RAID5, RAID6, nhưng có mức chẵn lẻ có thể cấu hình được. Trong trường hợp này, việc đặt trước được thực hiện không phải theo từng khối mà cho từng đối tượng riêng biệt. Cách dễ nhất để thử mã hóa xóa là mở rộng .
là một tính năng ZFS hiện chưa được phát hành. Không giống như RAIDZ, DRAID có khối chẵn lẻ phân tán và trong quá trình khôi phục, sử dụng tất cả các đĩa của mảng cùng một lúc, điều này giúp nó có khả năng khắc phục lỗi đĩa tốt hơn và phục hồi nhanh hơn sau lỗi.
Máy chủ có sẵn Fujitsu Primergy RX300 S7 với bộ xử lý CPU Intel Xeon E5-2650L 0 @ 1.80GHz, chín thanh RAM Đã đăng ký Samsung DDR3-1333 8Gb PC3L-10600R ECC (M393B1K70DH0-YH9), kệ đĩa Supermicro SuperChassis 847E26-RJBOD1, được kết nối qua Bộ mở rộng LSI SAS2X36 kép và 45 đĩa Seagage ST6000NM0115-1YZ110 trên 6TB mọi người
Trước khi quyết định bất cứ điều gì, trước tiên chúng ta cần kiểm tra mọi thứ một cách chính xác.
Để làm được điều này, tôi đã chuẩn bị và thử nghiệm nhiều cấu hình khác nhau. Để làm điều này, tôi đã sử dụng minio, hoạt động như một chương trình phụ trợ của S3 và khởi chạy nó ở các chế độ khác nhau với số lượng mục tiêu khác nhau.
Về cơ bản, trường hợp minio đã được thử nghiệm trong việc mã hóa xóa và đột kích phần mềm với cùng số lượng đĩa và tính chẵn lẻ của các đĩa, đó là: RAID6, RAIDZ2 và DRAID2.
Để tham khảo: khi bạn khởi chạy minio chỉ với một mục tiêu, minio sẽ hoạt động ở chế độ cổng S3, cung cấp hệ thống tệp cục bộ của bạn dưới dạng bộ lưu trữ S3. Nếu bạn khởi chạy minio chỉ định một số mục tiêu, chế độ Mã hóa xóa sẽ tự động bật, chế độ này sẽ truyền dữ liệu giữa các mục tiêu của bạn đồng thời cung cấp khả năng chịu lỗi.
Theo mặc định, minio chia mục tiêu thành các nhóm gồm 16 đĩa, mỗi nhóm có 2 điểm chẵn lẻ. Những thứ kia. Hai đĩa có thể bị lỗi cùng lúc mà không làm mất dữ liệu.
Để kiểm tra hiệu suất, tôi đã sử dụng 16 đĩa, mỗi đĩa 6TB và viết các đối tượng nhỏ có kích thước 1 MB lên chúng, điều này mô tả chính xác nhất tải trọng trong tương lai của chúng tôi, vì tất cả các công cụ sao lưu hiện đại đều chia dữ liệu thành các khối vài megabyte và ghi chúng theo cách này.
Để tiến hành đo điểm chuẩn, chúng tôi đã sử dụng tiện ích s3bench, khởi chạy trên một máy chủ từ xa và gửi hàng chục nghìn đối tượng như vậy đến minio trong hàng trăm luồng. Sau đó tôi đã cố gắng yêu cầu họ quay lại theo cách tương tự.
Kết quả benchmark được thể hiện trong bảng sau:
Như chúng ta có thể thấy, minio ở chế độ mã hóa xóa riêng của nó hoạt động kém hơn đáng kể khi ghi so với minio chạy trên phần mềm RAID6, RAIDZ2 và DRAID2 trong cùng một cấu hình.
Riêng tôi kiểm tra minio trên ext4 vs XFS. Điều đáng ngạc nhiên là đối với loại khối lượng công việc của tôi, XFS lại chậm hơn đáng kể so với ext4.
Trong đợt thử nghiệm đầu tiên, Mdadm tỏ ra vượt trội hơn ZFS, nhưng sau đó rằng bạn có thể cải thiện hiệu suất ZFS bằng cách đặt các tùy chọn sau:
xattr=sa atime=off recordsize=1Mvà sau đó các bài kiểm tra với ZFS đã trở nên tốt hơn rất nhiều.
Bạn cũng có thể lưu ý rằng DRAID không mang lại nhiều hiệu suất hơn RAIDZ, nhưng về mặt lý thuyết thì nó sẽ an toàn hơn nhiều.
Trong hai thử nghiệm gần đây nhất, tôi cũng đã thử chuyển siêu dữ liệu (đặc biệt) và ZIL (nhật ký) sang máy nhân bản từ SSD. Nhưng việc xóa siêu dữ liệu không mang lại nhiều lợi ích cho tốc độ ghi và khi xóa ZIL, đạt mức trần với mức sử dụng 100%, vì vậy tôi coi thử nghiệm này là một thất bại. Tôi không loại trừ rằng nếu tôi có ổ SSD nhanh hơn thì có lẽ điều này có thể cải thiện đáng kể kết quả của tôi, nhưng thật không may, tôi đã không có chúng.
Cuối cùng, tôi quyết định sử dụng DRAID và mặc dù ở trạng thái beta nhưng đây là giải pháp lưu trữ nhanh nhất và hiệu quả nhất trong trường hợp của chúng tôi.
Tôi đã tạo một DRAID2 đơn giản trong cấu hình có ba nhóm và hai phụ tùng được phân phối:
# zpool status data
pool: data
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
draid2:3g:2s-0 ONLINE 0 0 0
sdy ONLINE 0 0 0
sdam ONLINE 0 0 0
sdf ONLINE 0 0 0
sdau ONLINE 0 0 0
sdab ONLINE 0 0 0
sdo ONLINE 0 0 0
sdw ONLINE 0 0 0
sdak ONLINE 0 0 0
sdd ONLINE 0 0 0
sdas ONLINE 0 0 0
sdm ONLINE 0 0 0
sdu ONLINE 0 0 0
sdai ONLINE 0 0 0
sdaq ONLINE 0 0 0
sdk ONLINE 0 0 0
sds ONLINE 0 0 0
sdag ONLINE 0 0 0
sdi ONLINE 0 0 0
sdq ONLINE 0 0 0
sdae ONLINE 0 0 0
sdz ONLINE 0 0 0
sdan ONLINE 0 0 0
sdg ONLINE 0 0 0
sdac ONLINE 0 0 0
sdx ONLINE 0 0 0
sdal ONLINE 0 0 0
sde ONLINE 0 0 0
sdat ONLINE 0 0 0
sdaa ONLINE 0 0 0
sdn ONLINE 0 0 0
sdv ONLINE 0 0 0
sdaj ONLINE 0 0 0
sdc ONLINE 0 0 0
sdar ONLINE 0 0 0
sdl ONLINE 0 0 0
sdt ONLINE 0 0 0
sdah ONLINE 0 0 0
sdap ONLINE 0 0 0
sdj ONLINE 0 0 0
sdr ONLINE 0 0 0
sdaf ONLINE 0 0 0
sdao ONLINE 0 0 0
sdh ONLINE 0 0 0
sdp ONLINE 0 0 0
sdad ONLINE 0 0 0
spares
s0-draid2:3g:2s-0 AVAIL
s1-draid2:3g:2s-0 AVAIL
errors: No known data errorsĐược rồi, chúng ta đã sắp xếp xong bộ nhớ, bây giờ hãy nói về những gì chúng ta sẽ sao lưu. Ở đây tôi muốn nói ngay về ba giải pháp mà tôi đã thử và đó là:
- cái nĩa , một giải pháp chuyên biệt để sao lưu thiết bị khối, có sự tích hợp chặt chẽ với Ceph. Có thể tìm ra sự khác biệt giữa các ảnh chụp nhanh và tạo bản sao lưu gia tăng từ chúng. Hỗ trợ một số lượng lớn phụ trợ lưu trữ, bao gồm cả cục bộ và S3. Yêu cầu một cơ sở dữ liệu riêng để lưu trữ bảng băm chống trùng lặp. Nhược điểm: viết bằng python, có cli hơi không phản hồi.
- cái nĩa , một công cụ sao lưu nổi tiếng và đã được chứng minh từ lâu, có thể sao lưu dữ liệu và sao chép nó rất tốt. Có thể lưu các bản sao lưu cục bộ và vào máy chủ từ xa thông qua scp. Có thể sao lưu các thiết bị chặn nếu được khởi chạy bằng cờ --special, một trong những nhược điểm: khi tạo bản sao lưu, kho lưu trữ bị chặn hoàn toàn, vì vậy nên tạo một kho lưu trữ riêng cho từng máy ảo, về nguyên tắc đây không phải là vấn đề, may mắn là chúng được tạo rất dễ dàng.
là một dự án đang phát triển tích cực, được viết bằng go, khá nhanh và hỗ trợ một số lượng lớn phụ trợ lưu trữ, bao gồm lưu trữ cục bộ, scp, S3 và nhiều hơn nữa. Riêng biệt, tôi muốn lưu ý rằng có một được tạo đặc biệt cho phần còn lại, cho phép bạn nhanh chóng xuất bộ nhớ để sử dụng từ xa. Trong tất cả những điều trên, tôi thích nó nhất. Có thể sao lưu từ stdin. Nó hầu như không có nhược điểm đáng chú ý, nhưng có một số tính năng:
Đầu tiên, tôi đã thử sử dụng nó ở chế độ kho lưu trữ chung cho tất cả các máy ảo (như Benji) và thậm chí nó còn hoạt động khá tốt, nhưng các thao tác khôi phục mất rất nhiều thời gian, bởi vì... Mỗi lần trước khi khôi phục, Restic sẽ cố gắng đọc siêu dữ liệu của tất cả các bản sao lưu. Vấn đề này được giải quyết dễ dàng, như với borg, bằng cách tạo một kho lưu trữ riêng cho từng máy ảo. Cách tiếp cận này đã được chứng minh là rất hiệu quả trong việc quản lý các bản sao lưu. Các kho lưu trữ riêng biệt có thể có mật khẩu riêng để truy cập dữ liệu và chúng tôi cũng không phải lo lắng rằng kho lưu trữ chung có thể bị hỏng bằng cách nào đó. Bạn có thể tạo ra các kho lưu trữ mới dễ dàng như trong bản sao lưu borg.
Trong mọi trường hợp, việc loại bỏ trùng lặp chỉ được thực hiện so với phiên bản trước của bản sao lưu; bản sao lưu trước đó được xác định bởi đường dẫn dành cho bản sao lưu đã chỉ định, vì vậy nếu bạn sao lưu các đối tượng khác nhau từ stdin vào một kho lưu trữ chung, đừng quên chỉ định địa chỉ lưu trữ. lựa chọn
--stdin-filenamehoặc chỉ định rõ ràng tùy chọn mỗi lần--parent.
Thứ hai, việc khôi phục thiết bị xuất chuẩn mất nhiều thời gian hơn so với việc khôi phục hệ thống tệp do tính chất song song của nó. Trong tương lai, chúng tôi dự định bổ sung hỗ trợ chặt chẽ hơn cho việc sao lưu cho các thiết bị khối.
Thứ ba, hiện nay nên sử dụng , bởi vì phiên bản 0.9.6 có lỗi khôi phục lâu các tệp lớn.
Để kiểm tra tính hiệu quả của bản sao lưu và tốc độ ghi/khôi phục từ bản sao lưu, tôi đã tạo một kho lưu trữ riêng và thử sao lưu một hình ảnh nhỏ của máy ảo (21 GB). Hai bản sao lưu đã được thực hiện mà không thay đổi bản gốc, sử dụng từng giải pháp được liệt kê để kiểm tra xem dữ liệu bị trùng lặp được sao chép nhanh hơn/chậm hơn như thế nào.
Như chúng ta có thể thấy, Borg Backup có tỷ lệ hiệu quả sao lưu ban đầu tốt nhất, nhưng lại kém hơn về cả tốc độ ghi và khôi phục.
Restic hóa ra nhanh hơn Benji Backup, nhưng phải mất nhiều thời gian hơn để khôi phục về thiết bị xuất chuẩn và thật không may, nó vẫn chưa biết cách ghi trực tiếp vào thiết bị khối.
Sau khi cân nhắc tất cả những ưu và nhược điểm, tôi quyết định giải quyết phản kháng с máy chủ còn lại là giải pháp sao lưu thuận tiện và hứa hẹn nhất.
Trong video màn hình này, bạn có thể thấy kênh 10 gigabit được sử dụng hoàn toàn như thế nào trong một số hoạt động sao lưu chạy đồng thời. Điều đáng chú ý là tỷ lệ tái chế đĩa không tăng trên 30%.
Tôi rất hài lòng với giải pháp tôi nhận được!
Nguồn: www.habr.com
