Điểm:3

Khởi động đúng cách RAID1 dựa trên phần mềm với ổ đĩa bị thiếu hoặc bị lỗi không đúng cách

lá cờ gf

tl;dr. Có cách nào để khởi động đúng RAID1 dựa trên phần mềm với một ổ đĩa bị thiếu hoặc bị lỗi (không phải do người dùng bị lỗi trước) không?

Nói rõ hơn, có thể khởi động RAID1 dựa trên phần mềm mà không cần ổ cứng NẾU bạn làm hỏng ổ đĩa trước khi khởi động lại. Tôi biết điều này là chủ quan, nhưng đây không phải là một giải pháp hợp lý cũng như một câu trả lời có thể chấp nhận được. Ví dụ; Một cơ sở bị mất điện và ổ cứng bị hỏng cùng lúc mất điện. Cố gắng khởi động với một ổ cứng đã xuống cấp không được “đúng cách” không thành công sẽ khiến hệ thống rơi vào chế độ khẩn cấp.

Tôi đã đọc nhiều bài đăng từ đây và các diễn đàn khác, tất cả đều khuyên bạn nên cài đặt grub trên tất cả các phân vùng hoặc xây dựng lại grub theo cách thủ công, hãy thêm không thất bại đến /etc/fstab các tùy chọn hoặc các giải pháp có vẻ đơn giản khác; nhưng thực tế là không có khuyến nghị nào trong số này có hiệu quả.

Mặc dù tôi đã đồng ý với việc điều này là không thể, nhưng có điều gì đó không dễ dàng xảy ra. Vì vậy, tôi đang xem liệu có ai khác gặp sự cố này hoặc có giải pháp cho sự cố này không.

Môi trường của tôi:

Tôi có một bo mạch chủ cũ hơn không hỗ trợ UEFI, vì vậy tôi đã khởi động chế độ kế thừa/MBR.
hệ điều hành:

con mèo/etc/redhat-phát hành
Phiên bản máy trạm Red Hat Enterprise Linux 7.6 (Maipo)

hạt nhân:

uname âr
3.10.0-957.el7.x86_64

thưa bà:

mdadm âphiên bản
mdadm â v4.1-rc1 2018-03-22

RAID của tôi là RAID1 trên ba ổ đĩa. (sda, sdb, sdc) và có 4 phân vùng

md1 - /khởi động
md2 - /nhà
md3 - /
md4 - trao đổi

Tôi đã cài đặt grub trên tất cả các phân vùng và đảm bảo rằng tất cả các phân vùng khởi động đều có cờ khởi động. fdisk /dev/sd[a,b,c] tất cả đều hiển thị một * trong trường khởi động bên cạnh phân vùng thích hợp
-- và --
cài đặt grub2 /dev/sd[a,b,c] (dưới dạng các lệnh riêng biệt, với kết quả cài đặt thành công).

Nhân rộng vấn đề:

  1. Tắt nguồn hệ thống với tất cả các ổ đĩa được gán cho RAID và RAID hoạt động hoàn toàn.
  2. Tháo ổ cứng
  3. hệ thống điện lên

Kết quả: Hệ thống sẽ khởi động qua grub. Gdm sẽ cố gắng hiển thị màn hình đăng nhập nhưng sau khoảng 20 giây, nó sẽ không thành công và chuyển sang bảng điều khiển khẩn cấp. Có nhiều bộ phận bị thiếu trong một hệ thống bình thườngâ. Ví dụ; /boot và /etc không tồn tại. Dường như không có bất kỳ thông báo hoặc sự cố hoảng loạn hạt nhân nào được hiển thị trong dmesg.

Một lần nữa, chìa khóa ở đây là; RAID phải được lắp ráp hoàn chỉnh, tắt nguồn và tháo ổ đĩa. Nếu bạn làm hỏng một ổ đĩa đúng cách và xóa nó khỏi RAID, thì bạn có thể khởi động mà không cần ổ đĩa.

Ví dụ:
mdadm --manage /dev/md[1,2,3,4] --fail /dev/sda[1,2,3,4] (dưới dạng các lệnh riêng biệt)
mdadm --manage /dev/md[1,2,3,4] --remove /dev/sda[1,2,3,4] (dưới dạng các lệnh riêng biệt)

Tôi biết điều này có vẻ tầm thường, nhưng tôi vẫn chưa tìm ra giải pháp khả thi nào để khởi động hệ thống có RAID1 đã xuống cấp. Bạn sẽ nghĩ rằng đây phải là một vấn đề đơn giản với một giải pháp đơn giản, nhưng điều này có vẻ không đúng.

Mọi trợ giúp, đầu vào hoặc đề xuất sẽ được đánh giá rất cao.

Điểm:6
lá cờ ca

Chắc chắn có thể khởi động mảng MD RAID1 bị lỗi - ít nhất là nếu BIOS bỏ qua đĩa bị lỗi (nếu không, bạn có thể chỉ cần khởi động thủ công từ đĩa còn sống).

Đối với vấn đề cụ thể của bạn, có lẽ bạn đang gặp vấn đề này bọ cánh cứng. Một đoạn trích (nhưng đọc tất cả các báo cáo lỗi sẽ là một ý tưởng hay):

RHEL 7.6 dracut-iniqueue script có giá trị mặc định là 180 giây (như định nghĩa trong biến RDRETRY), cao hơn systemd root dịch vụ gắn kết (90 giây). Điều này có thể dẫn đến hệ thống không thể khởi động khi root nằm trên thiết bị RAID1 phần mềm đã xuống cấp (người dùng bị loại xuống vỏ khẩn cấp). Nhìn thấy https://bugzilla.redhat.com/show_bug.cgi?id=1451660# cho một ví dụ về vấn đề. Lưu ý rằng điều này chỉ xảy ra khi thiết bị RAID mong đợi bản thân đang khỏe mạnh, nhưng không ngờ mảng bị xuống cấp trong khi khởi động.

Vượt qua "rd.retry=30" khi khởi động sẽ sửa mảng khởi động bị xuống cấp vấn đề, vì mảng bị bắt buộc bắt đầu trước systemctl root hết thời gian dịch vụ gắn kết. Hơn nữa, thời gian chờ dracut rd.retry kéo dài là không phù hợp với trang man dracut.cmdline(7), trong đó nó được nêu thời gian chờ phải là 30 giây.

...

Thông tin bổ sung: Tôi đã truy tìm vấn đề về cách mdadm --incremental, dracut timeout (rd.retry) và thời gian chờ mặc định systemctl tương tác:

  • mdadm --incremental sẽ không bắt đầu/chạy một mảng bất ngờ bị xuống cấp;
  • dracut sẽ buộc bắt đầu mảng sau 2/3 giá trị thời gian chờ đã qua. Với mặc định RHEL hiện tại, số tiền này là 180/3*2 = 120 giây;
  • systemctl dự kiến ​​​​sẽ gắn hệ thống tệp gốc trong tối đa 90 giây. Nếu nó không thành công, nó sẽ hủy bỏ kịch bản nháp và rơi vào tình trạng khẩn cấp vỏ bọc. Thấp hơn 90 so với thời gian chờ của bản vẽ, điều đó có nghĩa là bản vẽ không không có cơ hội để bắt đầu mảng. Giảm thời gian chờ rd.retry (cài đặt như trang hướng dẫn gợi ý) cho phép dracut bắt đầu khởi động mảng, cho phép dịch vụ systemctl thành công.

như lỗi Nên được sửa trong các bản phát hành RHEL/CentOS 7 điểm gần đây, tôi thực sự khuyên bạn nên cập nhật hệ thống của mình nếu có thể. Nếu không, hãy thử vượt qua rd.retry=30 như tùy chọn khởi động kernel.

Will Roberts avatar
lá cờ gf
shodanshok. Cảm ơn bạn! Đây chính xác là vấn đề và việc thay đổi cài đặt md.raid buộc RAID phải xây dựng lại trước khi hết thời gian chờ và cho phép hệ thống khởi động đúng cách.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.