Tình huống khủng khiếp - hệ thống tệp được gắn đồng thời bởi nhiều phiên bản HĐH độc lập

Làm thế nào để tôi thoát khỏi tình huống này một cách an toàn?

Chi tiết như sau:

Một máy chủ xen đã có các thiết bị khối được phân bổ cho VM. Nhưng những thiết bị này cũng đã được gắn bên trong Xen.

Trong thực tế, 44 thiết bị khối này đã được gắn kết như thế này. Để làm cho vấn đề tồi tệ hơn, mỗi thiết bị vật lý được nhìn thấy trên 4 đường dẫn và mỗi đường dẫn được gắn trên một điểm gắn kết riêng. Nói cách khác, các thiết bị thực sự được gắn 5 lần mỗi cái.

HĐH máy khách VM nhìn thấy đường dẫn qua thiết bị giả PowerPath (được phân bổ dưới dạng thiết bị chặn phy: cho domU)

Một số thiết bị được định dạng là ext2 và reiserfs.

Không cần phải giải thích cho tôi các rủi ro tham nhũng hệ thống tập tin ở đây.

Tôi sợ rằng ngay cả việc ngắt kết nối các hệ thống tệp có thể gây ra tham nhũng và cảm thấy rằng tại thời điểm này, rút ​​điện từ máy chủ, là lựa chọn an toàn nhất .

Lưu ý rằng hầu hết các ứng dụng, cơ sở dữ liệu Oracle, trong tất cả các máy ảo vẫn đang chạy và đang sử dụng.

Tôi phát hiện ra điều này khi điều tra việc sử dụng CPU cao trên dom0. Có một quá trình "tìm" không thành công, với cwd -> / media / đĩa-12 được gắn từ / dev / sdf1, thuộc về / dev / emcpowerr

Trước khi có ai hỏi, có một lần tôi đã thấy các quy trình không thể bị giết và tiếp tục sử dụng CPU và RAM (không giống như quy trình không còn tồn tại / zombie), là khi có các I / O được cam kết nổi bật, ví dụ như đã đồng bộ hóa trở lại nhưng chưa có trên đĩa . Thông thường hơn điều này xảy ra trên băng I / O.

Gợi ý!?

Tái bút: Tôi có dự kiến ​​các thiết bị sẽ được "dành riêng" một khi được gắn, để ngăn chặn điều này không? Hay điều đó là không thể trên Linux?

EDIT: Đầu tiên tôi tin rằng KDE trong hypanneror) là thủ phạm. Có vẻ như KDE đang gắn các thiết bị có thể khi đăng nhập để tạo biểu tượng trên màn hình. Tuy nhiên, điều tương tự không xảy ra trên các máy chủ Xen khác, nhưng tất cả các máy chủ khác đang chạy phiên bản SLES và KDE cũ hơn nhiều ... V4 dường như là một máy vi phạm, với 3,4 hoạt động tốt hơn).

Hơn nữa, hai VM không quan trọng đã bị treo. Sau khi tắt chúng, chúng sẽ không khởi động lại do hỏng hệ thống tệp. VM chính / sản xuất vẫn đang chạy và cơ sở dữ liệu trên nó vẫn hoạt động, nhưng rõ ràng đây là một quả bom hẹn giờ. Khách hàng đang cố gắng xây dựng lại môi trường trên một máy ảo khác trên một máy chủ khác nhưng bị kẹt trong các vấn đề cấu hình một số thành phần, vì vậy chúng tôi đang chờ ...

Trong mọi trường hợp, tôi cảm thấy rằng không có câu trả lời nào cho đến nay là "thực hành tốt nhất luôn luôn tắt một cách duyên dáng" Và tôi hy vọng sẽ có được một cái gì đó cụ thể hơn ... Trong mọi trường hợp, tôi cảm thấy rằng tình huống này có thể được bảo đảm cẩn thận hơn Suy nghĩ. Việc tắt sẽ khiến IO nổi bật, đặc biệt là các cập nhật dữ liệu meta của hệ thống tệp từ trình ảo hóa, sẽ được đồng bộ hóa và gây ra lỗi hệ thống tệp lớn có khả năng?

Nếu các đĩa đang được ghi từ một điểm gắn kết duy nhất thì không có tác hại nào được thực hiện. Thực hiện tắt máy sạch, (sao lưu nó từ trạng thái treo nếu bạn sẽ) sửa chữa các gắn kết. Không chạy bất cứ thứ gì ngoại trừ các ứng dụng cần thiết trên Dom0. Nếu, OTOH, các phân vùng đang được viết từ nhiều đường dẫn, đó là BAD và trở nên tồi tệ hơn bởi lần thứ hai. Rút phích cắm.

Tôi không có lý do cụ thể nhưng cảm giác ruột thịt của tôi nói với tôi rằng sau đây có thể là cách tiếp cận tốt nhất:

1. Tắt các ứng dụng.
2. Sao chép tất cả dữ liệu từ VM qua mạng vào vị trí sao lưu.
3. Hủy gắn kết các hệ thống tệp từ bên trong VM.
4. Tắt máy ảo. (Hiện tại chỉ có một VM chạy trên máy chủ này).
5. Đảm bảo không có domUs nào được thiết lập để bắt đầu tự động.
6. Rút nguồn trên máy chủ để ngăn không cho trình ảo hóa thực hiện bất kỳ hành động "đóng" nào, đồng bộ hóa I / O nổi bật, v.v.
7. Khởi động máy ảo, hy vọng rằng chính trình ảo hóa đã sống sót sau khi bị mất điện.
8. Nếu thất bại, xây dựng lại môi trường. (Các đĩa khởi động VM được dựa trên tệp, nhưng các điểm gắn dữ liệu nằm trên đĩa bên ngoài được phân bổ dưới dạng thiết bị khối)
9. Kiểm tra xem trình ảo hóa có đang gắn bất kỳ hệ thống tệp nào thuộc về domUs không. Hủy gắn kết những cái này trước khi bất kỳ domUs nào được bắt đầu)
10. Tắt tự động gắn KDE.
11. Khởi động VM và buộc kiểm tra FS đầy đủ.

Thay thế cho 11: Khởi động VM và gắn kết các hệ thống tệp mà không có fsck đầy đủ.

Lý do là tôi không muốn Xen hypanneror có thêm cơ hội hoàn toàn cần thiết để gây ra tham nhũng trên các hệ thống tệp domU.

Tôi không phải là chuyên gia Xen và chưa có kinh nghiệm với nó. Nhưng cách tiếp cận của tôi nếu tôi ở vị trí của bạn sẽ là: đầu tiên tôi biết tôi có thể mất dữ liệu (thậm chí có thể là tất cả); thứ hai tôi sẽ cố gắng tạo ảnh chụp nhanh và sau đó tạm dừng các máy ảo, khôi phục chúng trong môi trường khác nhau an toàn.
Tôi không muốn cho bạn hy vọng sai lầm, nhưng tôi nghĩ bạn sẽ may mắn nếu bạn có thể phục hồi bất cứ điều gì.

Cảnh báo : làm theo những lời khuyên này có thể khiến bạn mất tất cả dữ liệu. Điều này tùy thuộc vào bạn để xem nó có đáng để mạo hiểm hay không.

Với rất nhiều may mắn, các ứng dụng của bạn vẫn hoạt động vì dữ liệu họ đang sử dụng hoàn toàn nằm trong bộ nhớ biến động. Bạn nên cố gắng tận dụng tình huống này (cố gắng đánh giá xem đó có phải là trường hợp trên cơ sở từng ứng dụng không) và xuất dữ liệu trực tiếp sang chia sẻ mạng nếu ứng dụng cung cấp tính năng như vậy. Nếu có bất kỳ dữ liệu nào trên đĩa, chức năng xuất này có thể bị "khóa" giống như findcâu lệnh của bạn hoặc sự cố (và làm hỏng ứng dụng hoặc HĐH) do dữ liệu đĩa bị thay đổi / bị hỏng.

Sau đó, bạn có thể thử thực hiện một ảnh chụp nhanh trực tiếp, hướng dẫn trong bài viết sau: Tạo ảnh chụp nhanh trong Xen . Tôi sẽ chụp ảnh nhanh theo từng byte, mặc dù nó có thể bị kẹt giống như findlệnh của bạn ... Tuy nhiên, tôi sẽ không hy vọng nhiều như vậy.

Trước khi thực hiện lệnh trước đó, bạn phải đọc tài liệu này từ Citrix để giúp hiểu các ảnh chụp nhanh trong Xen (PDF) .

Tôi chúc bạn may mắn.