ZFS - phá hủy zvol trùng lặp hoặc bộ dữ liệu ngăn chặn máy chủ. Làm thế nào để phục hồi?

Tôi đang sử dụng Nexentastor trên máy chủ lưu trữ thứ cấp chạy trên HP ProLiant DL180 G6 với 12 ổ đĩa Midline (7200 RPM). Hệ thống có CPU E5620 và RAM 8GB. Không có thiết bị ZIL hoặc L2ARC.

Tuần trước, tôi đã tạo một zvol thưa thớt 750GB với tính năng khấu trừ và nén được chia sẻ thông qua iSCSI đến máy chủ VMWare ESX. Sau đó tôi đã tạo một hình ảnh máy chủ tệp Windows 2008 và sao chép ~ 300GB dữ liệu người dùng vào VM. Khi đã hài lòng với hệ thống, tôi đã chuyển máy ảo đến một cửa hàng NFS trên cùng một nhóm.

Sau khi chạy và chạy với máy ảo của tôi trên kho dữ liệu NFS, tôi đã quyết định loại bỏ zvol 750GB ban đầu. Làm như vậy đã đình trệ hệ thống. Truy cập vào giao diện web Nexenta và NMC tạm dừng. Cuối cùng tôi đã có thể có được một vỏ thô. Hầu hết các hoạt động của hệ điều hành đều ổn, nhưng hệ thống đã bị treo trên zfs destroy -r vol1/filesystemlệnh. Xấu xí. Tôi đã tìm thấy hai mục bugzilla OpenSolaris sau đây và bây giờ hiểu rằng máy sẽ bị brick trong một khoảng thời gian không xác định. Đã 14 giờ, vì vậy tôi cần một kế hoạch để có thể lấy lại quyền truy cập vào máy chủ.

http://bugs.opensolaris.org/orpdatabase/view_orms.do?orms_id=6924390

và

http://bugs.opensolaris.org/orpdatabase/view_orms.do;jsessionid=593704962bcbe0743d82aa339988?orms_id=6924824

Trong tương lai, có lẽ tôi sẽ nhận lời khuyên được đưa ra trong một trong những cách giải quyết của buzilla:

Workaround
    Do not use dedupe, and do not attempt to destroy zvols that had dedupe enabled.

Cập nhật: Tôi đã buộc hệ thống tắt nguồn. Khi khởi động lại, hệ thống gian hàng tại Importing zfs filesystems. Đó là cách đó trong 2 giờ.

Điều này đã được giải quyết. Điều quan trọng là khối lượng trùng lặp cần phải tắt cờ khấu trừ trước khi xóa. Điều này nên được thực hiện ở cấp độ nhóm cũng như cấp độ zvol hoặc hệ thống tập tin. Mặt khác, việc xóa về cơ bản là bị lặp lại. Quá trình này mất thời gian vì bảng sao chép ZFS đang được tham chiếu. Trong trường hợp này, RAM giúp. Tôi đã tạm thời thêm 16 Gigabyte RAM vào hệ thống và đưa máy chủ trở lại trực tuyến. Các zpool nhập khẩu hoàn toàn trong vòng 4 giờ.

Đạo đức có lẽ là suy luận không siêu bóng bẩy và RAM là điều cần thiết cho hiệu suất của nó. Tôi đang đề xuất 24GB trở lên, tùy thuộc vào môi trường. Nếu không, hãy để lại ZFS khấu trừ. Nó chắc chắn không hợp lý cho người dùng gia đình hoặc các hệ thống nhỏ hơn.

Là một người sử dụng lâu dài các thiết bị sê-ri Sun / Oracle ZFS 7000, tôi có thể nói với bạn mà không có câu hỏi nào không được đánh bóng. Không bao giờ nhầm lẫn bán hàng với giao hàng! Nhân viên bán hàng sẽ cho bạn biết "Ồ, nó đã được sửa". Trong cuộc sống thực - cuộc sống thực của tôi - tôi có thể nói với bạn rằng 24 GB không đủ để xử lý các "bảng DDT". Đó là, chỉ mục back end lưu trữ bảng khấu trừ. Bảng đó phải nằm trong bộ nhớ hệ thống để mỗi I / O bị chặn trong chuyến bay để tìm ra liệu nó có cần được ghi vào đĩa hay không. Nhóm lưu trữ của bạn càng lớn, dữ liệu thay đổi càng nhiều, bảng này càng lớn - và nhu cầu về bộ nhớ hệ thống càng lớn. Bộ nhớ đó phải trả giá bằng ARC (bộ đệm) và đôi khi, chính hệ điều hành - đó là lý do tại sao bạn gặp phải tình trạng treo, vì một số lệnh nhất định xảy ra ở nền trước, một số trong nền. Có vẻ như xóa hồ bơi xảy ra ở phía trước, trừ khi bạn nói khác đi trong CLI. Thuật sĩ GUI sẽ không làm điều này.

Ngay cả việc xóa hàng loạt dữ liệu NFS trong một chia sẻ được xác định trên một khối lượng được khấu trừ sẽ đưa hệ thống của bạn xuống một nửa nếu bạn không có đủ bộ nhớ để xử lý "ghi" cho ZFS để bảo nó xóa dữ liệu.

Nói chung, trừ khi bạn tối đa hóa bộ nhớ và thậm chí sau đó, hãy tìm cách dự trữ bộ nhớ cho HĐH bằng cách hạn chế ARC và DDT (và tôi không nghĩ rằng bạn có thể hạn chế DDT theo bản chất của nó, đó chỉ là một chỉ số được gắn chính xác vào I / O của bạn) - sau đó bạn bị hos trong khi xóa lớn hoặc zvol / pool định mệnh.