RAID không phải backup: 6 hiểu lầm phổ biến về lưu trữ doanh nghiệp

RAID giải quyết bài toán gì và không giải quyết bài toán gì

RAID sinh ra để giữ cho hệ thống tiếp tục chạy khi một hoặc vài ổ đĩa hỏng phần cứng. Nó là cơ chế bảo vệ tính sẵn sàng, đo bằng việc dịch vụ có gián đoạn hay không. Backup sinh ra để giữ một bản sao dữ liệu ở trạng thái quá khứ, có thể quay lại được. Hai mục tiêu này khác nhau về bản chất và không thay thế cho nhau ở bất kỳ mức độ nào.

Điểm mấu chốt: mọi thao tác ghi lên volume RAID đều được nhân bản ngay lập tức xuống toàn bộ ổ thành viên. Nếu người dùng xoá nhầm thư mục, nếu ứng dụng ghi hỏng dữ liệu, nếu ransomware mã hoá file, RAID sẽ nhân bản chính xác hành động phá hoại đó một cách hoàn hảo. Không có một cơ chế nào trong RAID cho phép quay ngược lại trạng thái trước đó.

Sáu hiểu lầm dưới đây là những gì chúng tôi gặp lại nhiều nhất trong các đợt khảo sát hạ tầng khách hàng, và mỗi hiểu lầm đều đã dẫn tới mất dữ liệu thật ở đâu đó. Điểm chung của cả sáu là chúng đều nghe rất hợp lý, đều được lặp lại trong nhiều tài liệu bán hàng, và đều chỉ lộ ra sai sót vào đúng lúc hệ thống gặp sự cố. Chúng tôi trình bày từng hiểu lầm kèm cơ chế kỹ thuật giải thích vì sao nó sai, hậu quả thực tế đã ghi nhận, và cấu hình thay thế nên áp dụng. Bạn có thể dùng danh sách này như một bảng kiểm khi rà soát lại hệ lưu trữ đang chạy.

Hiểu lầm 1: có RAID rồi thì khỏi cần backup

Đây là hiểu lầm gốc, đẻ ra tất cả các hiểu lầm còn lại. Lập luận thường gặp là hệ thống đã chạy RAID 6 chịu được hai ổ hỏng, nên dữ liệu an toàn. Nhưng thống kê nguyên nhân mất dữ liệu trong doanh nghiệp cho thấy hỏng ổ đĩa chỉ chiếm một phần nhỏ. Phần lớn đến từ xoá nhầm, ghi đè nhầm, lỗi ứng dụng, lỗi nâng cấp phần mềm, mã độc và cả nhân viên nghỉ việc cố tình phá.

Ngoài ra RAID không bảo vệ trước sự cố ở tầng cao hơn ổ đĩa: hỏng controller, hỏng backplane, chập nguồn làm cháy nhiều ổ cùng lúc, lỗi firmware khiến toàn bộ mảng mất metadata, cháy phòng server, ngập nước. Trong tất cả các trường hợp này, số ổ hỏng vượt xa khả năng chịu đựng của bất kỳ mức RAID nào.

Khuyến nghị đơn giản: coi RAID là biện pháp giữ uptime, và tính chi phí backup như một hạng mục ngân sách độc lập không được cắt. Một hệ thống lưu trữ hai trăm triệu mà không có backup thì rủi ro thực tế cao hơn một hệ thống một trăm triệu có backup đầy đủ. Khi lập dự toán, hãy tách rõ hai dòng ngân sách: chi phí lưu trữ chính và chi phí bảo vệ dữ liệu. Nếu buộc phải cắt giảm, phần bị cắt nên là dung lượng hoặc tốc độ của tầng chính, không phải phần bảo vệ. Đây là nguyên tắc mà bất kỳ đơn vị nào từng trải qua một sự cố mất dữ liệu đều tự rút ra, nhưng thường là sau khi đã trả giá.

Hiểu lầm 2: RAID 5 vẫn an toàn với ổ dung lượng lớn

RAID 5 chịu được đúng một ổ hỏng. Khi một ổ chết, mảng vào trạng thái degraded và phải rebuild bằng cách đọc toàn bộ dữ liệu trên tất cả các ổ còn lại để tính lại parity. Với ổ 4TB thời trước, quá trình này mất khoảng nửa ngày. Với ổ nearline SATA 16TB hoặc 20TB hiện nay, rebuild có thể kéo dài nhiều ngày, đặc biệt khi hệ thống vẫn phục vụ tải sản xuất song song.

Rủi ro nằm ở hai chỗ. Thứ nhất, trong suốt thời gian rebuild dài như vậy, mảng không còn dự phòng, một ổ nữa hỏng là mất toàn bộ volume. Xác suất này không nhỏ vì các ổ thường cùng lô, cùng tuổi, cùng chịu tải như nhau. Thứ hai là lỗi đọc không sửa được, gọi là URE. Ổ nearline phổ thông có tỷ lệ URE khoảng một trên mười mũ mười lăm bit đọc. Khi rebuild phải đọc hàng trăm terabyte liên tục, khả năng gặp một URE trở nên đáng kể, và với nhiều controller thì một URE giữa quá trình rebuild đủ để làm hỏng cả quá trình.

Khuyến nghị: với ổ từ 8TB trở lên, không dùng RAID 5. Chọn RAID 6 nếu ưu tiên dung lượng, chấp nhận write penalty cao hơn. Chọn RAID 10 nếu workload thiên về ghi ngẫu nhiên như database, vì rebuild của RAID 10 chỉ là copy một ổ mirror sang ổ mới, nhanh hơn nhiều lần và không cần đọc toàn mảng.

• RAID 5 chịu 1 ổ hỏng, RAID 6 chịu 2 ổ, RAID 10 chịu nhiều ổ nếu không rơi cùng một cặp mirror
• Ổ từ 8TB trở lên: bỏ RAID 5, chuyển RAID 6 hoặc RAID 10
• RAID 6 write penalty 6, RAID 10 write penalty 2, cân nhắc theo tỷ lệ đọc ghi của ứng dụng
• Bật patrol read hoặc consistency check định kỳ để phát hiện sector hỏng trước khi cần rebuild
• Không mua toàn bộ ổ cùng một lô sản xuất nếu tránh được

Hiểu lầm 3: snapshot là backup

Snapshot trên SAN, NAS hay hypervisor hoạt động theo cơ chế tham chiếu khối dữ liệu. Nó không sao chép toàn bộ dữ liệu sang chỗ khác mà chỉ giữ lại các block cũ khi có thay đổi. Điều đó có nghĩa snapshot phụ thuộc hoàn toàn vào chính volume gốc. Nếu volume hỏng, nếu mảng RAID mất, nếu controller lỗi metadata, toàn bộ snapshot mất theo. Snapshot cũng nằm chung phạm vi quản trị, nên tài khoản admin bị chiếm là xoá được hết chỉ bằng vài lệnh.

Snapshot vẫn cực kỳ hữu ích, nhưng đúng vai trò của nó là điểm quay lui nhanh trong khoảng thời gian ngắn. Ví dụ chụp snapshot trước khi nâng cấp ứng dụng để có thể rollback trong vài phút, hoặc giữ snapshot theo giờ để người dùng tự khôi phục file vừa xoá nhầm. Đó là bổ sung cho backup chứ không phải thay thế.

Một lưu ý vận hành: snapshot giữ quá lâu trên hệ thống ghi nhiều sẽ ăn dung lượng rất nhanh và làm giảm hiệu năng do chuỗi tham chiếu dài. Với máy ảo trên VMware, snapshot để quên vài tuần là nguyên nhân kinh điển của việc datastore đầy và toàn bộ VM treo. Đặt chính sách tự động xoá snapshot quá 7 ngày và giám sát dung lượng còn trống ở mức cảnh báo 20 phần trăm.

Hiểu lầm 4: đồng bộ NAS hai chiều là đã có backup

Rất nhiều doanh nghiệp dựng hai NAS ở hai văn phòng và bật đồng bộ thời gian thực, rồi yên tâm rằng dữ liệu đã có hai bản ở hai nơi. Vấn đề là đồng bộ nhân bản mọi thay đổi, bao gồm cả thay đổi phá hoại. File bị mã hoá ở NAS A sẽ được đẩy sang NAS B trong vài phút. Xoá thư mục ở một đầu là mất ở cả hai đầu. Bản chất đây là nhân bản, không phải sao lưu, vì không có chiều thời gian.

Cách sửa không phức tạp. Chuyển từ đồng bộ hai chiều sang sao chép một chiều theo lịch, kết hợp giữ nhiều phiên bản tại đích với retention rõ ràng. Ví dụ giữ 14 bản ngày, 8 bản tuần, 6 bản tháng. Đích đến bật snapshot hoặc immutability và tài khoản dùng để đẩy dữ liệu không có quyền xoá phiên bản cũ. Khi đó một sự cố ở nguồn không thể phá được lịch sử ở đích.

Với các NAS phổ thông, tính năng phiên bản hoá thường có sẵn nhưng mặc định tắt hoặc đặt số phiên bản rất thấp. Kiểm tra lại thiết lập này là việc mất mười lăm phút nhưng thay đổi hoàn toàn khả năng phục hồi. Cùng với đó, hãy kiểm tra xem thùng rác mạng và snapshot của volume có đang bật hay không, và đang giữ lại bao nhiêu ngày. Một cấu hình tối thiểu hợp lý cho thư mục dùng chung là bật phiên bản hoá với ít nhất ba mươi phiên bản, kèm snapshot hàng ngày giữ trong bảy tới mười bốn ngày. Chi phí dung lượng phát sinh thường dưới mười phần trăm nhưng đủ cứu bạn khỏi hầu hết trường hợp xoá nhầm hoặc ghi đè.

• Đồng bộ hai chiều nhân bản cả lỗi và cả mã độc, không có khả năng quay lại quá khứ
• Thay bằng sao chép một chiều theo lịch cộng giữ nhiều phiên bản tại đích
• Tài khoản đẩy dữ liệu chỉ có quyền ghi thêm, không có quyền xoá bản cũ
• Bật snapshot ở đích và đặt retention rõ ràng theo ngày, tuần, tháng
• Kiểm tra định kỳ rằng phiên bản cũ thực sự khôi phục được, không chỉ nhìn thấy trong giao diện

Hiểu lầm 5: có hot spare là yên tâm

Hot spare rút ngắn thời gian bắt đầu rebuild, đó là giá trị thật của nó. Nhưng nó không rút ngắn thời gian rebuild, không giảm rủi ro URE, và không giúp gì nếu nguyên nhân hỏng nằm ngoài ổ đĩa. Nhiều hệ thống chúng tôi kiểm tra có cấu hình hot spare nhưng ổ đó đã hỏng âm thầm từ lâu và không ai biết, vì hot spare không tham gia đọc ghi nên lỗi chỉ lộ ra đúng lúc cần dùng.

Điều nguy hiểm hơn là hot spare tạo cảm giác an toàn khiến đội vận hành trì hoãn thay ổ hỏng. Mảng chạy trên hot spare tức là đã tiêu hết một lớp dự phòng, nhưng đèn báo trên giao diện thường trở lại màu xanh sau khi rebuild xong, làm mất tín hiệu cảnh báo. Kết quả là nhiều tháng sau vẫn chưa ai đặt mua ổ thay thế.

Khuyến nghị vận hành: bật patrol read để hot spare được kiểm tra định kỳ, cấu hình cảnh báo qua email hoặc SNMP cho mọi sự kiện thay đổi trạng thái ổ, và duy trì tồn kho ổ dự phòng tại chỗ đúng model đúng firmware. Với hệ thống quan trọng, thời gian chờ ổ thay thế từ nhà cung cấp phải nằm trong hợp đồng dịch vụ, không phải chờ đặt hàng.

Hiểu lầm 6: controller RAID không cần BBU hay bảo vệ cache

Để đạt hiệu năng ghi tốt, controller RAID bật chế độ write back, tức báo cho hệ điều hành rằng dữ liệu đã ghi xong trong khi thực tế nó mới nằm trong bộ nhớ cache của controller. Nếu mất điện đột ngột trong khoảnh khắc đó, dữ liệu trong cache biến mất nhưng ứng dụng đã tin là ghi thành công. Với cơ sở dữ liệu, hậu quả là file dữ liệu không nhất quán, có khi phải khôi phục từ backup.

Giải pháp là module bảo vệ cache. Các thế hệ cũ dùng pin BBU giữ điện cho cache trong vài chục giờ. Các thế hệ hiện tại dùng siêu tụ kết hợp bộ nhớ flash, khi mất điện siêu tụ cấp đủ năng lượng để đổ toàn bộ nội dung cache xuống flash, dữ liệu được ghi tiếp khi có điện trở lại. Cách này không có tuổi thọ pin nên ít phải bảo trì hơn.

Điều nhiều đội IT bỏ sót là controller tự động chuyển sang write through khi module bảo vệ hỏng hoặc pin hết tuổi. Hệ thống vẫn chạy nhưng hiệu năng ghi có thể tụt vài lần, người dùng phàn nàn chậm mà không ai hiểu nguyên nhân. Đưa trạng thái module cache vào danh mục giám sát hàng tháng, cùng với trạng thái ổ và nhiệt độ, là việc nên làm ngay. HQG thường gộp các hạng mục này vào gói bảo trì định kỳ cho khách hàng dùng Dell PowerEdge và HPE ProLiant.

• Write back cần module bảo vệ cache, nếu không có thì bắt buộc để write through
• Siêu tụ cộng flash thay thế pin BBU, không cần thay pin theo chu kỳ
• Module hỏng khiến controller tự hạ về write through, hiệu năng ghi tụt mà không báo lỗi rõ ràng
• Đưa trạng thái cache module vào báo cáo giám sát hàng tháng
• Kết hợp UPS đủ thời lượng và shutdown tự động để giảm rủi ro mất điện đột ngột

Cấu hình khuyến nghị theo từng loại workload

Với máy chủ cơ sở dữ liệu ghi nhiều như SQL Server hoặc PostgreSQL, chọn RAID 10 trên SSD doanh nghiệp, ưu tiên ổ có độ bền ghi mixed use từ 3 DWPD trở lên nếu tải ghi cao. Write penalty thấp và độ trễ ổn định quan trọng hơn dung lượng. Tách file log giao dịch sang volume riêng nếu ngân sách cho phép, vì mẫu truy cập của log là ghi tuần tự khác hẳn với data file.

Với file server và kho lưu trữ tài liệu, RAID 6 trên ổ nearline là lựa chọn cân bằng chi phí. Nhóm 8 tới 12 ổ trong một mảng, không nên làm mảng quá lớn vì thời gian rebuild tăng theo. Bật deduplication nếu nền tảng hỗ trợ và dữ liệu có tính lặp cao. Với repository backup, RAID 6 hoặc RAID 60 phù hợp vì mẫu truy cập chủ yếu là ghi tuần tự khối lớn.

Với môi trường ảo hoá dùng chung, cân nhắc phân tầng: một pool SSD cho máy ảo tải cao và một pool ổ cơ cho dữ liệu ít truy cập. Đo IOPS thực tế trong giờ cao điểm trước khi quyết định, đừng dựa vào ước lượng. Một hệ thống ảo hoá 40 máy ảo văn phòng thường chỉ cần vài nghìn IOPS, trong khi một hệ ERP có thể yêu cầu hàng chục nghìn IOPS với độ trễ dưới 5 mili giây.