Tôi nên khởi động lại máy chủ Linux bao lâu một lần?


30

Tôi có nhiều máy chủ Linux (SUSE 9 & 10) được sử dụng để chạy các dịch vụ web cung cấp dữ liệu cho các lưới tính toán lớn. Gần đây, chúng tôi đã gặp một số khó khăn khi giải thích sự cố ngừng hoạt động (tức là nhật ký phần cứng và phần mềm không hiển thị bất kỳ lỗi rõ ràng nào) và chúng tôi bắt đầu tự hỏi liệu thời gian hoạt động dài (thường là 200-300 ngày) có phải là vấn đề không. Cho rằng các máy chủ này được sử dụng rất nhiều, tôi có nên xem xét một chu kỳ khởi động lại thường xuyên không?

Câu trả lời:


47

Bạn phải khởi động lại sau khi cập nhật kernel (trừ khi bạn đang sử dụng KSplice), mọi thứ khác là tùy chọn. Cá nhân tôi khởi động lại theo chu kỳ hàng tháng trong một cửa sổ bảo trì để đảm bảo máy chủ và tất cả các dịch vụ hoạt động trở lại như mong đợi. Bằng cách này, tôi có thể chắc chắn một cách hợp lý nếu tôi phải thực hiện khởi động lại ngoài lịch trình (tức là cập nhật kernel quan trọng) rằng hệ thống sẽ hoạt động trở lại đúng cách. Giám sát tự động các máy chủ và dịch vụ (ví dụ Nagios) cũng đi một chặng đường dài để giúp quá trình này (khởi động lại, xem đèn chuyển sang màu đỏ và sau đó hy vọng tất cả trở lại màu xanh lá cây).

PS nếu bạn khởi động lại thường xuyên, bạn sẽ muốn đảm bảo rằng bạn điều chỉnh kiểm tra fsck của mình (tức là số lần gắn tối đa giữa các lần kiểm tra một cách thích hợp, nếu không, việc khởi động lại nhanh trong 2 phút có thể mất 30 phút nếu máy chủ bắt đầu lấy một vài terabyte dữ liệu. Tôi thường đặt số lần gắn kết của mình thành 0 (Tune2fs -c 0) và khoảng thời gian giữa các lần kiểm tra là 6 tháng hoặc lâu hơn, sau đó buộc một fsck một cách thủ công mỗi lần và đặt lại số đếm.


1
Thường xuyên kiểm tra DRBCP của bạn là điều bắt buộc và loại kiểm tra này là một khởi đầu tuyệt vời theo hướng đó.
Scott Pack

Bạn không cần phải khởi động lại sau khi cập nhật kernel - ksplice.com
raspi

1
KSplice là chính xác, với KSplice bạn có thể sống phần mềm chạy vá (Kernel, Database, v.v.). Tuy nhiên, vì Oracle đã mua KSplice có lẽ không phải là giải pháp cho bất kỳ ai không sử dụng công cụ của Oracle (những người gần đây đã mua KSplice).
Kurt

11

Tôi thực sự khởi động lại máy chủ của mình một cách khá đều đặn, bất cứ khi nào thay đổi cấu hình lớn được thực hiện. Điều quan trọng cần biết là trong trường hợp khẩn cấp, phần mềm máy chủ sẽ xuất hiện mà không gặp rắc rối. Điều cuối cùng bạn muốn là ở một vị trí mà bạn đang cố gắng phục hồi sau khi bị cúp nhưng phải làm rối với cấu hình máy chủ của bạn vì bạn đã không kiểm tra kỹ khi bạn thiết lập nó.


6

Máy chủ Linux không bao giờ cần phải khởi động lại trừ khi bạn thực sự cần thay đổi phiên bản kernel đang chạy. Hầu hết các vấn đề có thể được giải quyết bằng cách thay đổi tệp cấu hình và khởi động lại dịch vụ bằng tập lệnh init.

Bạn cần coi chừng khởi động lại ... nếu bạn thay đổi bất cứ điều gì "nhanh chóng" mà không phản ánh các thay đổi của bạn trong tệp cấu hình của dịch vụ, những thay đổi đó sẽ không được áp dụng sau khi khởi động lại.

Tôi thường khởi động lại sau khi cập nhật hệ thống theo lịch trình, mặc dù. Nói chung là không cần thiết, nhưng tôi làm chúng khi không có ai trong văn phòng, vậy tại sao không? Dù sao, thường có những nâng cấp kernel khi tôi thực hiện cập nhật.


Tất nhiên họ cần phải khởi động lại theo thời gian. Khi bạn cập nhật phần mềm và phần mềm cụ thể đó hiện đang chạy, bạn vẫn sẽ sử dụng phiên bản phần mềm cũ vì bản sao của phiên bản cũ vẫn còn hoạt động trong RAM. Bạn sẽ cần khởi động lại phần mềm đó (bằng cách khởi động lại dịch vụ hoặc khởi động lại) để bản cập nhật có hiệu lực. Một số ứng dụng cần khởi động lại và không thể cập nhật khởi động lại dịch vụ thông qua
BlueWizard

1
@JonasDralle, các dịch vụ sẽ tự động dừng và khởi động lại khi chúng được nâng cấp. Nếu không, đó là một lỗi trong việc thực hiện dịch vụ đó!
Alexis Wilke

4

Không thực sự cần thiết, xử lý bộ nhớ linux là tuyệt vời. Nhưng nếu bạn có thời gian tăng có thể thì bạn có thể đang chạy các hạt nhân có lỗ hổng đã biết - bạn có thể muốn xem nó.


3
Linux có thể xử lý bộ nhớ của nó ổn, nhưng các ứng dụng riêng lẻ có thể không - đống của chúng có thể bị phân mảnh nếu chúng chạy trong một thời gian dài. Tất nhiên, những thứ như prefork Apache (tái chế các quy trình của nó) thường không phải chịu đựng điều này. Những thứ khác sử dụng một quá trình duy nhất tồn tại rất lâu (ví dụ: mysql) có thể. Phụ thuộc vào ứng dụng của bạn.
MarkR

4

Tôi nghĩ bạn nên khởi động lại nếu đã có bản cập nhật kernel gần đây HOẶC bản cập nhật libc. Rất nhiều thứ được liên kết với libc và thực sự không thể tải lib đó khỏi bộ nhớ hoàn toàn và thay thế nó bằng phiên bản mới trừ khi bạn thực hiện khởi động lại.

Ví dụ, ngay cả những thứ cơ bản như / bin / ls và những thứ khác trong / bin cũng sử dụng libc. Nếu bạn chỉ đang chạy một giao diện điều khiển và sử dụng bash, bạn đang sử dụng libc.

$ ldd /bin/bash
        linux-gate.so.1 =>  (0xffffe000)
        libtermcap.so.2 => /lib/libtermcap.so.2 (0xb8029000)
        libdl.so.2 => /lib/libdl.so.2 (0xb8025000)
        libc.so.6 => /lib/libc.so.6 (0xb7ed9000)
        /lib/ld-linux.so.2 (0xb804b000)

$ ldd /bin/ls
        linux-gate.so.1 =>  (0xffffe000)
        librt.so.1 => /lib/librt.so.1 (0xb7f3a000)
        libacl.so.1 => /lib/libacl.so.1 (0xb7f33000)
        libc.so.6 => /lib/libc.so.6 (0xb7de7000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7dd0000)
        /lib/ld-linux.so.2 (0xb7f61000)
        libattr.so.1 => /lib/libattr.so.1 (0xb7dcc000)

Và vâng, nếu bạn thay đổi các tệp trong /etc/init.d, điều này ảnh hưởng đến việc khởi động theo một cách nào đó, tôi sẽ khuyên bạn nên khởi động lại. Bạn không muốn biết rằng bạn đã mắc một lỗi nhỏ trong tệp khởi động khi bạn cần mọi thứ nhanh chóng và chạy lại.

Nếu một máy chủ đã hoạt động nhiều ngày mà không khởi động lại, điều đó thực sự có nghĩa là không có cách nào để chắc chắn rằng nó sẽ xuất hiện trở lại đúng cách. Một lần nữa, điều này là do rất nhiều tệp cấu hình có thể đã bị thay đổi trên đó và không ai khởi động lại nó trong một thời gian dài để đảm bảo rằng nó xuất hiện. Ngoài ra, nếu máy chủ có nhiều bản cập nhật do bạn đã khởi động lại trong một thời gian dài, hãy khởi động lại trước khi bạn áp dụng các bản cập nhật, nếu không, có vấn đề, bạn không thể chắc chắn đó là do lỗi cấu hình a từ lâu hoặc các bản cập nhật mới mà bạn áp dụng.

Cuối cùng, nếu bạn khởi động lại một máy chủ quan trọng sau một thời gian rất dài, fsck có thể có nghĩa là bạn phải đợi rất lâu để nó hoạt động trở lại. Bạn có thể sử dụng Tune2fs để tránh điều này, nhưng tôi cho rằng nên thường xuyên kiểm tra nó. Đây là lý do tại sao bạn không nên ở vị trí mà bạn chỉ phụ thuộc vào 1 máy chủ và nếu điều đó xảy ra, toàn bộ trang web của bạn sẽ biến mất. Bạn nên có một cái khác ở chế độ chờ.


3
+1 cho "khởi động lại trước"
kubanchot

2

Một điều khác để tìm kiếm trong khi có thời gian chết bất ngờ này, là xem xét chính xác bộ nhớ và bộ xử lý đang được sử dụng như thế nào và bằng những chương trình nào. topsẽ có thể xác định quy trình nào là thủ phạm gây mất tài nguyên và sau đó có thể quản lý chúng trực tiếp. Một ý tưởng khác là khởi tạo một cronjob để tắt và khởi động lại các quy trình của bạn theo một lịch trình cụ thể.


+1 - Không phải tất cả các lần mất điện là do sự cố hạt nhân.
pcapademia

2

Nó không phải là một ý tưởng tồi để khởi động lại nếu nó đã quá lâu để bạn có thể chạy kiểm tra đĩa (fsck) trên phân vùng gốc. Đối số của bạn có thể là điều này giúp đảm bảo tính toàn vẹn dữ liệu.


1

Một máy chủ Linux chạy đúng chỉ cần khởi động lại để cập nhật kernel. Điều tương tự không phải lúc nào cũng được nói với một số phần mềm - ví dụ, đôi khi tôi phải khởi động lại apache2 hoặc người đưa thư.


0

Cơ sở hạ tầng của tôi có hai trang web dữ liệu, alpha (nơi hoạt động diễn ra hàng ngày) và beta (trang web sao lưu, trong trường hợp mọi thứ trở nên sai lầm khủng khiếp ở alpha). Mặc dù hiện tại không phải như vậy, nhưng tôi đang cố gắng để có thời gian ngừng hoạt động theo lịch trình tại trang web alpha mỗi 6 tháng, để chúng tôi có thể chạy tất cả các dịch vụ từ phiên bản beta.

Điều này sẽ hoàn thành hai điều. Đầu tiên, nó sẽ chứng minh rằng trang web khắc phục thảm họa của chúng tôi là hoàn toàn khả thi. Thứ hai, nó sẽ cho tôi thời gian đáng giá trong một tuần để loại bỏ hành trình tích lũy ở giai đoạn alpha.

Vì vậy, tôi không khởi động lại máy chủ của mình thường xuyên như tôi nên làm. Tôi đồng ý với những người đăng khác nói rằng điều quan trọng là phải biết rằng máy chủ của bạn sẽ hoạt động trở lại khi bạn cần. Bạn không muốn "nghĩ" rằng họ sẽ, chỉ để biết rằng bạn đã thay đổi một cái gì đó và không thực hiện nó một cách chính xác, hoặc không ghi lại nó.


0

Bạn cũng có thể viết một số tập lệnh sẽ kiểm tra (càng nhiều càng tốt), nếu trạng thái hiện tại của máy của bạn, sẽ là trạng thái của máy khởi động lại sau.

Ý tôi là đây là ...

  • /etc/init.d/*
    • Kiểm tra xem tất cả các dịch vụ hiện đang chạy, được gắn cờ để bắt đầu khởi động
    • Kiểm tra xem tất cả các dịch vụ không chạy được gắn cờ không khởi động khi khởi động
  • /etc/fstab
    • Kiểm tra xem tất cả các hệ thống tập tin được gắn (tức là /etc/mtab) có một mục tương ứng trong/etc/fstab
    • Kiểm tra xem tất cả các hệ thống tệp được chỉ định sẽ được gắn khi khởi động /etc/fstabcũng đang được gắn.

Tất nhiên đây không phải là một kiểm tra đầy đủ bằng bất kỳ phương tiện nào, nhưng nó làm giảm nguy cơ rắc rối sau khi khởi động lại.

Ngoài ra, bạn nên (imo) thiết lập chính sách cập nhật gói máy chủ, theo một số thứ tự hợp lý, giả sử 1 nhóm mỗi tuần ...

  • Máy chủ Crash & Burn
  • Máy chủ phát triển, Máy chủ đào tạo
  • Máy chủ thử nghiệm
  • Máy chủ tiền sản xuất
  • Máy chủ sản xuất

Cũng có một kế hoạch tổng thể, chẳng hạn như "Tất cả các máy chủ sẽ trải qua quá trình nâng cấp hệ điều hành hoàn chỉnh 6 tháng một lần".


0

Phụ thuộc vào các tác vụ đang chạy trên máy chủ. Đối với một số máy chủ ảo, chúng tôi thường sử dụng khởi động lại thay vì khởi động lại apachectl và chỉ mất 5-10 giây. Nhưng một số máy tải nặng được khởi động lại nhiều lần mỗi năm với toàn bộ đội ngũ quản trị viên theo dõi quá trình.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.