Seberapa sering saya harus me-reboot server Linux?


30

Saya memiliki banyak server Linux (SUSE 9 & 10) yang digunakan untuk menjalankan layanan web yang menyediakan data ke grid perhitungan besar. Baru-baru ini kami mengalami beberapa kesulitan untuk menjelaskan pemadaman (yaitu perangkat keras dan perangkat lunak log tidak menunjukkan kesalahan yang jelas) dan kami mulai bertanya-tanya apakah waktu kerja yang lama (biasanya 200-300 hari) adalah masalah. Mengingat bahwa server ini banyak digunakan, haruskah saya mempertimbangkan siklus reboot reguler?

Jawaban:


47

Anda harus reboot setelah pembaruan kernel (kecuali jika Anda menggunakan KSplice), yang lain adalah opsional. Secara pribadi saya reboot pada siklus bulanan selama jendela pemeliharaan untuk memastikan server dan semua layanan kembali seperti yang diharapkan. Dengan cara ini saya dapat cukup yakin jika saya harus melakukan reboot yang tidak sesuai jadwal (yaitu pembaruan kernel kritis) bahwa sistem akan kembali dengan benar. Pemantauan otomatis server dan layanan (yaitu Nagios) juga berjalan jauh untuk membantu proses ini (reboot, saksikan lampu menyala merah dan semoga semuanya kembali menjadi hijau).

PS jika Anda melakukan reboot secara teratur, Anda ingin memastikan Anda menyetel cek fsck Anda (yaitu jumlah pemasangan maksimal antara pemeriksaan dengan tepat, jika tidak, reboot cepat 2 menit mungkin memakan waktu 30 menit jika server mulai fsck'ing beberapa terabyte data. Saya biasanya mengatur jumlah mount saya ke 0 (tune2fs -c 0) dan interval antara pemeriksaan hingga 6 bulan atau lebih dan kemudian secara manual memaksa fsck sesekali dan mengatur ulang hitungan.


1
Teratur pengujian DRBCP Anda adalah suatu keharusan, dan jenis cek adalah besar awal ke arah itu.
Scott Pack

Anda tidak perlu melakukan reboot setelah pembaruan kernel - ksplice.com
raspi

1
KSplice benar, dengan KSplice Anda dapat menjalankan tambalan perangkat lunak (Kernel, Database, dll.). Namun Karena Oracle membeli KSplice, itu mungkin bukan solusi bagi siapa pun yang tidak menggunakan barang-barang Oracle (yang baru-baru ini membeli KSplice).
Kurt

11

Saya benar-benar me-reboot server saya secara teratur, setiap kali perubahan konfigurasi besar dilakukan. Sangat penting untuk mengetahui bahwa dalam keadaan darurat perangkat lunak server akan muncul tanpa kerumitan. Hal terakhir yang Anda inginkan adalah berada di posisi di mana Anda mencoba untuk memulihkan dari pemadaman tetapi harus mengacaukan konfigurasi server Anda karena Anda tidak mengujinya secara menyeluruh ketika Anda mengaturnya.


6

Server Linux tidak perlu di-boot ulang kecuali Anda benar - benar perlu mengubah versi kernel yang berjalan. Sebagian besar masalah dapat diselesaikan dengan mengubah file konfigurasi dan memulai kembali layanan dengan skrip init.

Anda harus berhati-hati terhadap reboot ... jika Anda mengubah sesuatu "dengan cepat" tanpa mencerminkan perubahan Anda pada file konfigurasi layanan, perubahan itu tidak akan diterapkan setelah reboot.

Saya biasanya reboot setelah pembaruan sistem yang dijadwalkan. Secara umum tidak perlu, tetapi saya melakukannya ketika tidak ada orang di kantor, jadi mengapa tidak? Seringkali ada peningkatan kernel ketika saya melakukan pembaruan.


Tentu saja mereka perlu reboot dari waktu ke waktu. Ketika Anda memperbarui perangkat lunak dan perangkat lunak tertentu sedang berjalan Anda masih akan menggunakan versi lama dari perangkat lunak karena salinan versi lama masih aktif dalam RAM. Anda harus memulai ulang perangkat lunak itu (dengan layanan restart atau reboot) agar pembaruan dapat diterapkan. Beberapa aplikasi memerlukan reboot dan tidak dapat diperbarui melalui layanan restart
BlueWizard

1
@JonasDralle, layanan harus berhenti dan memulai ulang secara otomatis ketika mereka ditingkatkan. Kalau tidak, itu adalah bug dalam implementasi layanan itu!
Alexis Wilke

4

Tidak benar-benar diperlukan, penanganan memori linux sangat baik. Tetapi jika Anda memiliki waktu uptime yang panjang itu, Anda mungkin menjalankan kernel yang telah diketahui kerentanannya - Anda mungkin ingin melihatnya.


3
Linux mungkin menangani memorinya ok, tetapi aplikasi individual mungkin tidak - tumpukan mereka bisa menjadi terfragmentasi jika berjalan untuk waktu yang lama. Tentu saja hal-hal seperti prefork Apache (yang mendaur ulang prosesnya) umumnya tidak menderita ini. Hal-hal lain yang menggunakan satu proses berumur sangat panjang (mis. Mysql) mungkin. Tergantung pada aplikasi Anda.
MarkR

4

Saya pikir Anda harus reboot jika ada pembaruan kernel terbaru ATAU pembaruan libc. Banyak hal yang terkait dengan libc dan tidak mungkin untuk membongkar lib itu dari memori sepenuhnya dan menggantinya dengan versi baru kecuali Anda melakukan reboot.

Sebagai contoh, bahkan hal-hal dasar seperti / bin / ls dan hal-hal lain di / bin menggunakan libc. Jika Anda hanya menjalankan konsol dan menggunakan bash, Anda menggunakan 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)

Dan ya, jika Anda mengubah file di /etc/init.d yang mempengaruhi startup dalam beberapa cara, saya akan merekomendasikan reboot. Anda tidak ingin mengetahui bahwa Anda membuat kesalahan kecil dalam file startup ketika Anda membutuhkan sesuatu dan berjalan kembali dengan cepat.

Jika server telah berjalan berhari-hari tanpa reboot, itu sebenarnya berarti bahwa tidak ada cara untuk memastikan bahwa itu akan muncul kembali dengan benar. Sekali lagi ini karena banyak file konfigurasi mungkin telah diubah, dan tidak ada yang mem-boot ulang untuk waktu yang lama untuk memastikan itu muncul. Juga, jika server memiliki banyak pembaruan karena dan Anda belum melakukan reboot untuk waktu yang lama, reboot sebelum Anda menerapkan pembaruan, jika tidak, jika ada masalah, Anda tidak dapat memastikan itu disebabkan oleh kesalahan konfigurasi dan lama atau pembaruan baru yang Anda terapkan.

Terakhir, jika Anda me-reboot server yang kritis setelah waktu yang sangat lama, fsck mungkin berarti Anda harus menunggu lama sekali agar bisa muncul kembali. Anda dapat menggunakan tune2fs untuk menghindari hal ini, tetapi sebaiknya Anda memeriksanya secara teratur. Inilah sebabnya mengapa Anda tidak boleh berada dalam posisi di mana Anda hanya bergantung pada 1 server dan jika itu berlaku, seluruh situs web Anda hilang. Anda harus memiliki satu lagi di siaga.


3
+1 untuk "reboot before"
kubanczyk

2

Hal lain yang harus dicari ketika mengalami downtime yang tidak terduga ini, adalah untuk melihat bagaimana tepatnya memori dan prosesor digunakan dan oleh program apa. topharus dapat menentukan proses mana yang menjadi penyebab hilangnya sumber daya, dan kemudian dapat mengelolanya secara langsung. Gagasan lain adalah menginisialisasi cronjob untuk mematikan dan memulai kembali proses Anda pada jadwal tertentu.


+1 - Tidak semua pemadaman disebabkan oleh masalah kernel.
pcapademic

2

Ini bukan ide yang buruk untuk reboot jika sudah lama sehingga Anda dapat menjalankan pemeriksaan disk (fsck) pada partisi root. Argumen Anda bisa jadi ini membantu memastikan integritas data.


1

Server Linux yang dijalankan dengan benar hanya perlu me-reboot untuk pembaruan kernel. Hal yang sama tidak selalu dapat dikatakan untuk beberapa perangkat lunak - misalnya, saya terkadang harus me-restart apache2 atau mailman.


0

Infrastruktur saya memiliki dua situs data, alfa (tempat operasi dilakukan setiap hari) dan beta (situs cadangan, kalau-kalau ada yang salah di alfa). Meskipun saat ini tidak terjadi, saya mendorong untuk menjadwalkan downtime di situs alpha setiap 6 bulan, sehingga kami dapat menjalankan semua layanan dari beta.

Ini akan mencapai dua hal. Pertama, ini akan membuktikan bahwa situs pemulihan bencana kami benar-benar layak. Kedua, ini akan memberi saya waktu satu minggu untuk menghapus akumulasi cruft di alpha.

Karena itu, saya tidak me-reboot server saya sesering yang seharusnya. Saya setuju dengan poster lain yang mengatakan bahwa penting untuk mengetahui bahwa server Anda akan muncul kembali ketika Anda membutuhkannya. Anda tidak ingin "berpikir" bahwa mereka akan melakukannya, hanya untuk mengetahui bahwa Anda telah mengubah sesuatu dan tidak melakukannya dengan benar, atau tidak mendokumentasikannya.


0

Anda juga dapat menulis beberapa skrip yang akan memeriksa (sebanyak mungkin), jika kondisi mesin Anda saat ini, akan menjadi keadaan mesin setelah reboot.

Yang saya maksud dengan ini adalah ...

  • /etc/init.d/*
    • Periksa apakah semua layanan yang sedang berjalan, ditandai untuk mulai saat boot
    • Pastikan semua layanan yang tidak berjalan ditandai untuk tidak memulai saat boot
  • /etc/fstab
    • Periksa bahwa semua sistem file yang terpasang (yaitu /etc/mtab) memiliki entri yang sesuai di/etc/fstab
    • Pastikan semua sistem file yang ditentukan untuk dipasang pada saat boot /etc/fstabjuga saat ini dipasang.

Ini tentu saja bukan pemeriksaan lengkap dengan cara apa pun, tetapi memang mengurangi risiko masalah pasca-reboot.

Tambahan untuk ini, Anda harus (imo) menetapkan kebijakan untuk pembaruan paket server, dalam urutan yang masuk akal, katakan 1 grup per minggu ...

  • Server Crash & Burn
  • Server Pengembangan, Server Pelatihan
  • Server Uji
  • Server Pra-Produksi
  • Server Produksi

Juga memiliki rencana keseluruhan, seperti "Semua server akan melalui peningkatan OS lengkap setiap 6 bulan".


0

Tergantung pada tugas yang berjalan di server. Untuk beberapa server virtual, kita sering menggunakan reboot daripada restart apachectl dan hanya membutuhkan waktu 5-10 detik lebih lama. Tetapi beberapa mesin berat dimuat ulang beberapa kali per tahun dengan seluruh kru admin memantau proses.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.