У мене є багато серверів Linux (SUSE 9 і 10), які використовуються для запуску веб-служб, які надають дані у великі сітки розрахунків. Нещодавно у нас виникли труднощі з поясненням несправностей (тобто журнали апаратного та програмного забезпечення не показують явних помилок), і ми починаємо задаватися питанням, чи не проблема тривалого часу роботи (як правило, 200-300 днів). Враховуючи, що ці сервери сильно використовуються, чи варто розглянути питання про регулярний цикл перезавантаження?
Відповіді:
Ви повинні перезавантажити після оновлення ядра (якщо ви не використовуєте KSplice), все інше не є обов'язковим. Особисто я перезавантажуюсь щомісяця під час вікна технічного обслуговування, щоб переконатися, що сервер та всі сервіси повертаються, як очікувалося. Таким чином, я можу бути впевненим, якщо мені доведеться зробити позапланову перезавантаження (тобто критичне оновлення ядра), що система відновиться належним чином. Автоматизований моніторинг серверів і сервісів (наприклад, Nagios) також допомагає цьому процесу (перезавантажте систему, спостерігайте, як вогні червоніють, а потім, сподіваємось, все повернемося до зеленого кольору).
PS, якщо ви регулярно перезавантажуєтесь, ви хочете переконатися, що ви настроїли свої чеки fsck (тобто максимальна кількість монтування між чеками належним чином, інакше швидке 2-хвилинне перезавантаження може зайняти 30 хвилин, якщо сервер почне fsck'ing пару терабайт даних. Зазвичай я встановлюю кількість монтажу на 0 (tune2fs -c 0), а інтервал між перевірками - 6 місяців або близько того, а потім вручну примушувати fsck раз у раз і скидати кількість.
Я фактично перезавантажую свої сервери на досить регулярній основі, будь-коли вноситься основні зміни конфігурації. Важливо знати, що в разі надзвичайної ситуації серверне програмне забезпечення вийде без зайвих проблем. Останнє, що вам потрібно, - це бути в положенні, коли ви намагаєтеся відновити після відключення, але вам доводиться возитися з конфігурацією вашого сервера, тому що ви не ретельно перевіряли це під час налаштування.
Сервери Linux ніколи не потребують перезавантаження, якщо вам абсолютно не потрібно змінити працюючу версію ядра. Більшість проблем можна вирішити, змінивши файл конфігурації та перезапустивши службу зі скриптом init.
Потрібно стежити за перезавантаженнями ... якщо ви щось змінили "на льоту", не відображаючи змін у файлі конфігурації служби, ці зміни не будуть застосовані після перезавантаження.
Я зазвичай перезавантажуюсь після запланованих оновлень системи. Це взагалі не потрібно, але я їх роблю, коли нікого в офісі немає, так чому б і ні? У будь-якому випадку, часто я оновлюю ядро, коли я переживаю оновлення.
Насправді не потрібно, обробка оперативної пам'яті Linux - це чудово. Але якщо у вас є час такої довжини, ви, ймовірно, працюєте з ядрами, які мають вразливі місця - можливо, ви захочете це переглянути.
Я думаю, вам слід перезавантажити, якщо недавно було оновлено ядро АБО libc. З libc багато речей пов'язано, і не можна повністю вивантажити цю пам'ять із пам'яті та замінити її новою версією, якщо ви не перезавантажите її.
Наприклад, навіть основні речі, такі як / bin / ls та інші речі в / bin, використовують libc. Якщо ви просто запускаєте консоль і використовуєте bash, ви використовуєте 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)
І так, якщо ви зміните файли в /etc/init.d, які якимось чином впливають на запуск, я рекомендую перезавантажити. Ви не хочете, щоб дізнатися, що ви зробили невелику помилку у файлі запуску, коли вам потрібні речі та запуск швидко.
Якщо сервер пройшов багато днів без перезавантаження, це насправді означає, що немає можливості бути впевненим, що він знову з'явиться належним чином. Це ще раз тому, що на ньому може бути змінено багато конфігураційних файлів, і ніхто не перезавантажував його довгий час, щоб переконатися, що він з'явився. Крім того, якщо сервер має багато оновлень, і ви не перезавантажувались довгий час, перезавантажтесь перед тим, як застосувати оновлення, інакше, якщо є проблема, ви не можете бути впевнені, що це було викликано помилкою конфігурації. давно або нові оновлення, які ви застосували.
Нарешті, якщо ви перезавантажите критичний сервер через дуже довгий час, fsck може означати, що вам доведеться чекати дуже довго, щоб він відновився. Ви можете використовувати tune2fs, щоб уникнути цього, але гарна ідея регулярно перевіряти це. Ось чому ви не повинні знаходитись у становищі, де ви залежите лише від одного сервера, і якщо це піде, весь ваш веб-сайт втратив. У вас повинен бути ще один у режимі очікування.
Ще одна річ, на яку слід звернути увагу, не дивлячись на те, як саме використовується пам'ять та процесор і якими програмами.
topповинні бути в змозі визначити, які процеси є винуватцем втрати ресурсів, а потім мати можливість безпосередньо керувати ними. Іншою ідеєю було б ініціалізувати cronjob для відключення та перезапустити ваші процеси за певним графіком.
Перезавантажити це не погано, якщо це було так довго, щоб ви могли запустити перевірку диска (fsck) на кореневому розділі. Вашим аргументом може бути те, що це допомагає забезпечити цілісність даних.
Правильно запущений сервер Linux потребує перезавантаження лише для оновлень ядра. Те ж саме не завжди можна сказати для певного програмного забезпечення - наприклад, мені іноді доводиться перезапускати apache2 або пошта.
У моїй інфраструктурі є два сайти даних, альфа-альфа (де операції відбуваються щодня) та бета-версія (резервний сайт, у випадку, якщо в альфа-справі все відбувається жахливо). Хоча це зараз не так, я наполягаю на запланованому простої на альфа-сайті кожні 6 місяців, щоб ми могли запускати всі сервіси з бета-версії.
Це дозволить досягти двох речей. По-перше, це доведе, що наш сайт відновлення аварій повністю життєздатний. По-друге, це дасть мені тиждень часу, щоб видалити накопичену сировину в альфа.
Я зараз не перезавантажую свої сервери так часто, як слід. Я погоджуюсь з іншими плакатами, які сказали, що важливо знати, що ваші сервери повернуться, коли вам потрібно. Ви не хочете "думати", що вони зроблять це, лише щоб з'ясувати, що ви щось змінили і не зробили це правильно, чи не задокументували.
Ви можете додатково написати деякі сценарії, які перевірять (наскільки це можливо), чи поточний стан вашої машини буде станом машини після перезавантаження.
Що я маю на увазі під цим ...
/etc/init.d/*
/etc/fstab
/etc/mtab) мають відповідний запис/etc/fstab/etc/fstabпристрої, також наразі встановлені.Це, звичайно, не повна перевірка будь-якими способами, але це зменшує ризик виникнення проблем після перезавантаження.
Крім цього, вам слід (imo) встановити політику для оновлення пакетів сервера, у певному розумному порядку, наприклад, 1 група на тиждень ...
Також є загальний план, наприклад "Всі сервери пройдуть повне оновлення ОС раз на 6 місяців".
Залежить від завдань, що виконуються на сервері. Для деяких віртуальних серверів ми часто використовуємо перезавантаження замість тобто перезавантаження apachectl, і це займе лише 5-10 секунд довше. Але деякі важко завантажені машини перезавантажуються кілька разів на рік, а цілий екіпаж адміністратора контролює процес.