Các hệ thống tập tin gốc Xen DomU trở thành chỉ đọc trên chuyển đổi dự phòng IP ảo iSCSI

Các máy chủ Xen của tôi là openSUSE 11.1 với open-iscsi cho cụm iSCSI SAN của chúng tôi. Các mô-đun SAN nằm trong một nhóm chuyển đổi dự phòng IP phía sau một IP ảo mà những người khởi xướng kết nối với.

Trong trường hợp máy chủ SAN chính bị hỏng, thứ cấp sẽ chọn vai trò là mục tiêu. Tất cả được xử lý bởi phần mềm LeftHand SAN / iQ và hoạt động tốt trong hầu hết các tình huống.

Vấn đề tôi gặp phải là đôi khi một số Xen DomUs của tôi sẽ có hệ thống tập tin gốc của chúng chỉ đọc sau khi chuyển đổi IP. Nó không nhất quán và xảy ra với một tập hợp con khác nhau mỗi khi xảy ra lỗi chuyển đổi dự phòng. Tất cả đều chạy cùng một hình ảnh phần mềm openSUSE 11.1.

Các hệ thống tập tin gốc cho mỗi DomU được gắn kết bằng iscsi mở trong Dom0 và sau đó Xen sử dụng trình điều khiển thiết bị khối tiêu chuẩn để hiển thị nó cho DomU.

Triệu chứng chính xác là một root khi chạy touch /testsẽ trả về lỗi "hệ thống tập tin chỉ đọc". Tuy nhiên, đầu ra của mountnó cho thấy nó được gắn đọc-ghi. Tất nhiên, tất cả các I / O khác trên domU cũng bị lỗi tại thời điểm này nên máy bị hỏng. Chỉ cần khởi động lại nó xmtừ Dom0 mà không cần kết nối lại phiên iSCSI sẽ khiến mọi thứ hoạt động trở lại.

Về phía Dom0, các thông báo nhật ký hệ thống trong quá trình chuyển đổi dự phòng giống như sau:

kernel: connection1:0: iscsi: detected conn error (1011)
iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
iscsid: connection1:0 is operational after recovery (1 attempts) 

Tôi đang có một thời gian khó khăn để tìm ra lớp nào để gỡ lỗi vấn đề này, nó có phải là một cái gì đó trong hạt nhân DomU không? hoặc ở cấp độ Dom0 hoặc Xen? Tôi nghĩ rằng có khả năng một số tham số ở đâu đó cần điều chỉnh để tăng thời gian chờ, nhưng tôi không chắc chắn nên tìm ở đâu.

Tôi thực sự không nghĩ rằng đó là một vấn đề với open-iscsi đơn giản vì thiết bị khối được kết nối vẫn có thể đọc và ghi được từ Dom0.

Cuối cùng tôi đã giải quyết điều này bằng cách sử dụng các lời khuyên và cài đặt sau từ tài liệu mở iscsi:

8.2 iSCSI settings for iSCSI root
---------------------------------

When accessing the root parition directly through a iSCSI disk, the
iSCSI timers should be set so that iSCSI layer has several chances to try to
re-establish a session and so that commands are not quickly requeued to
the SCSI layer. Basically you want the opposite of when using dm-multipath.

For this setup, you can turn off iSCSI pings by setting:

node.conn[0].timeo.noop_out_interval = 0
node.conn[0].timeo.noop_out_timeout = 0

And you can turn the replacement_timer to a very long value:

node.session.timeo.replacement_timeout = 86400

Sau khi thiết lập kết nối với mỗi LUN như được mô tả ở trên, chuyển đổi dự phòng hoạt động như một bùa mê, ngay cả khi phải mất vài phút để xảy ra.

Điều này có vẻ như là một vấn đề với bộ khởi tạo iSCSI chạy trên dom0. Người khởi tạo không nên gửi SCSI thất bại lên ngăn xếp một cách nhanh chóng. Có lẽ bạn sẽ muốn đặt ConnFailTimeout trong iscsi.conf đây là cài đặt xác định khoảng thời gian trước khi nó coi lỗi kết nối là lỗi và gửi lỗi đó lên ngăn xếp SCSI.

Tôi cũng sẽ xem xét việc chuyển đổi dự phòng thực sự mất bao lâu, nó có thể mất nhiều thời gian hơn bạn mong đợi. Nếu vậy có lẽ việc chuyển đổi dự phòng VIP mất quá nhiều thời gian do các vấn đề liên quan đến ARP.

Có bất kỳ thông báo nào trong dom0 chỉ ra bất kỳ loại lỗi đọc / ghi hoặc lỗi scsi nào tại thời điểm chuyển đổi dự phòng không? Nếu vậy, có vẻ như lỗi ghi này đang được truyền cho domU. Các domU không "biết" rằng đó là một thiết bị iSCSI, do đó, nó hoạt động như thể đĩa bên dưới đã biến mất và kết nối lại hệ thống tập tin chỉ đọc (xem mount (1) manpage - errors=continue / errors=remount-ro / errors=panic)

Từ quan điểm của dom0, nó sẽ không được thay đổi thành chỉ đọc - hành vi chỉ đọc này là một ngữ nghĩa hệ thống tập tin, không phải là một ngữ nghĩa thiết bị khối.

Bạn đề cập rằng "tất cả các I / O khác đều thất bại" tại thời điểm này - bạn có nghĩa là domU hay dom0?

Thông thường khi thiết lập giải pháp HA iSCSI tôi sử dụng đa luồng thay vì tiếp quản IP ảo - nó cho phép máy chủ hiển thị rõ hơn và bạn không có phiên iSCSI đột nhiên biến mất sau đó cần phải khởi động lại - luôn luôn có hai trong số chúng . Đây có phải là một lựa chọn trong môi trường này?

Ừm ... Một phần của vấn đề cũng là bạn không chạy / với tư cách RO. Thực hành tốt nhất trạng thái bảo mật khôn ngoan mà bạn nên có "/" được gắn ro và rằng bất kỳ hệ thống tệp nào cần rw nên được gắn riêng biệt, (ví dụ: / var và / tmp). Nếu có các thư mục dưới / etc cần ghi vào, chúng nên được chuyển đến / var / etc / path và được liên kết với / etc.

"/" chỉ nên được gắn RW trong chế độ người dùng.

Thiết lập theo kiểu này có thể ngăn chặn segfault trong tình huống trên khi kết hợp với các đề xuất khác.