Безопасно обновить выделенный сервер (не потерять доступ и без даунтайма)

Надо очень постараться, чтоб уронить CentOS обновлением. Systemd до перезагрузки останется работать старый (ЕМНИП), а вот демон SSHd перезапустится, но на твоё текущее подключение повлиять не должен. Просто обновляйся без ребута.

Обновляться без перезагрузки - это мину подкладывать самому себе на будущее.

Либо надо обновлять только то что перезагрузки не требует и так, либо если уж по-серьезному, ядро там приезжает или еще что, надо выделить время и проверить работоспособность сервера после обновления не отходя далеко и надолго.

Никак нельзя совсем обезопасить себя. Одно из самых лучших решений использовать снапшоты FS (btrfs/zfs/lvm) и в случае чего быстро откатиться/достать данные

XFS на весь диск :(

Не понял, вообще 1 раздел на / что-ли, даже без LVM? Тогда конечно имеется определённый риск что какое-нибудь приложение заполонит всё место и начнутся рандомные отказы и после перезагрузки или крэша сервер уже не поднимется. А ты вместо этого боишься секьюрити апдейтов.

А ты вместо этого боишься секьюрити апдейтов.

Секьюрити то я ставлю + выборочно еще некоторые сервисы обновляю.

Не понял, вообще 1 раздел на / что-ли, даже без LVM? Тогда конечно имеется определённый риск что какое-нибудь приложение заполонит всё место и начнутся рандомные отказы и после перезагрузки или крэша сервер уже не поднимется.

Да. Смысла нет в LVM — конфигурацию разделов мне так часто менять не надо и LVM подтормаживает. Если место не начнет забиваться по 10ГБ в секунду, то система мониторинга успеет предупредить. Хотя в целом ты прав, лучше иметь несколько разделов.

я конечно скажу банальность, но что мешает у себя поставить тот же дистр с теми же обновлениями, потом обновить его до упора, убедиться что проблем нет, и тогда сделать то же самое в продакшене?

Очень много поднимать, поднятие автоматизировано не на 100%.

В общем успешно обновился. Упал RabbitMQ — поднял руками. Упал Redis — сам поднялся. И слетели SELinux метки для файлов — некоторые файлы перестали отдаваться. В целом норм :) Спасибо всем.

ну так такой стенд надо держать у себя локально.

по ходу снять fsdump или блочный образ тоже можно, кстати

ну так такой стенд надо держать у себя локально.

Я просто голую CentOS у себя держу, иногда обкатываю что-нибудь. Полный дамп сильно долго снимать, 512ГБ я буду долго скачивать :)

да, долговато. Но что случится если все навернется? все равно ведь придется все пересобирать - а тут почти готово все на стенде, сидит и ждет. ну короче, я тут практикую нормальную сисадминскую паранойю, можно меня слушать, можно не слушать :)

LVM подтормаживает
XFS на весь диск

Профессионалы в треде! А машина у тебя тюнингованная десятка с ведром на выхлопе?

ШТА?

Поддержу.
Для ТС - ради профитов в дальнейшем можно и подождать, конечно от скорости канала зависит сколько ждать, но думаю все-таки у вас не мобильный инет.

Упал RabbitMQ — поднял руками.

Скорее всего он не упал. Там в пакете баг: https://bugzilla.redhat.com/show_bug.cgi?id=1259564.

Смысла нет в LVM — конфигурацию разделов мне так часто менять не надо

На сервере LVM — это жизненная необходимость. Иначе, как было сказано, первый же вышедший их под контроля процесс выжрать всё место. Да и фрагментация будет страшной под ext4.

Плюс не выделишь отдельные разделы под контейнеры того же LVM.

Плюс не задействуешь более оптимальные ФС под задачи, где нужно. Я так на одном сервере, где разбивал систему не я, до сих пор мучаюсь. Ради мегатонны мелкофайлового кеша приходится reiserfs поднимать в loop-образах. Даже в таком варианте оно работает заметно быстрее, чем ext4 на весь раздел :)

и LVM подтормаживает

На уровне погрешностей измерения. «Тормоза» там не дисковые, а процессорные. На современных процессорах примитивнейший пересчёт положения блоков перед записью — это даже не смешно. А вот выиграть за счёт правильно организации ФС можно много.

где разбивал систему не я

В моем случае сервак устанавливал хостер. Просто никто специально не просил ничего, поставили на свое усмотрение.

Иначе, как было сказано, первый же вышедший их под контроля процесс выжрать всё место

С LVM тоже трудности: если сразу неправильно разметить место, то на живую раздел уже не уменьшить — нужно выключать сервер, а в случае с XFS раздел вообще нельзя уменьшить. Выделять по чуть-чуть — фрагментация и тормоза и можно вовремя не успеть добавить места LV-шке, а если выделенное место больше не требуется, то назад не уменьшить по описанной выше причине. Причем фрагментация XFS/ext4 вообще не заметна на фоне тормозов LVM-снапшотов и фрагментации LVM.

За тем чтобы место на разделе не заканчивалось следит система мониторинга. Если очень резко сожрется 200ГБ (в чем я сомневаюсь), то система все равно сможет перезагрузится, т.к. после завершения процессов освобождаются inode удаленных файлов и после перезагрузки получим немного свободного места.

В общем соглашусь, что хорошо бы иметь LVM на сервере, но это явно не must have.

Плюс не задействуешь более оптимальные ФС под задачи, где нужно.

XFS идеально подходит под задачи. + имеем много памяти, а значит кучу кэшей

приходится reiserfs поднимать в loop-образах

Ядро с протухшими патчами в продакшн? Неподдерживаемая ФС в продакшн? Очень интересно посмотреть, что будет если загрузить не то ядро или на попытки подмонтировать такую ФС с LiveCD.

На уровне погрешностей измерения

На уровне снапшотов и фрагментации.

Настоятельно рекомендую на будущее настроить возможность удаленного управления сервером (KVM или подобное). Сэкономит очень много времени, когда такая нужда случится.

Из вопроса (полежит 15 минут) ясно что его можно и обновить/перегрузить. На моей памяти, обновления ни разу не уронили fedor'у.

возможность удаленного управления сервером (KVM или подобное)

Только по запросу и только 2 часа бесплатно :( Пишут что есть IPMI, но не работает.

если сразу неправильно разметить место, то на живую раздел уже не уменьшить

Ну так на то и LVM, чтобы не выделять сразу МНОГО в расчёте на будущее, а выделять сколько нужно и добавлять, когда понадобится.

Выделять по чуть-чуть — фрагментация

Выделять просто с умеренным запасом. Я обычно порядка двукратного от текущего занятого места выделяю. И добавляю, когда заполняется на 70-90% (в зависимости от условий).

и тормоза

Заметных тормозов не будет даже при сильной (в понимании LVM) фрагментации. И тормозов будет намного меньше, чем в результате фрагментации свободного места при использовании диска целиком.

Кроме того, если совсем уже хочется иметь прямую разметку, при выделении блоков перемещать их и объединять вручную. LVM это позволяет делать, при чём весьма безопасно и в онлайне. Я так несколько раз разделы видео и торрентов объединял, которые много лет растут, с объёмов в десятки гигабайт в единицы терабайт, многие десятки расширений за 8 лет :)

Причем фрагментация XFS/ext4 вообще не заметна на фоне тормозов LVM-снапшотов и фрагментации LVM.

Хм. Снапшоты не имеют к нашему вопросу вообще никакого отношения, так как не имеют аналога в простой ФС, а фрагментация LVM тормозит заведомо намного меньше фрагментации ФС :) Потому что она имеет единичные разрезы.

но это явно не must have.

В серверном случае — именно must have :) Это на ноуте с SSD на 128Гб она обычно не востребована :D

XFS идеально подходит под задачи

Отвратительно удаляет мелочь. Совершенно не годится для кешей с тучей мелких файлов, что на сервере бывает весьма часто.

имеем много памяти, а значит кучу кэшей

Файловый кеш очень быстро вылетает. Вообще, за последние годы на моих нагрузках это проблема номер один. Основная часть тормозов вылезает именно на интенсивной параллельной работе с мелочью, когда файловая структура вытесняется из кеша ОС. Сканирование обширных каталогов с целью удаления мелочи под активной параллельной загрузкой — это жесть, что в ext4, что в xfs.

Ядро с протухшими патчами в продакшн? Неподдерживаемая ФС в продакшн?

А что, в CentOS из ядра выкинули reisrefs? Ну, это их личные проблемы :) У меня штатные Debian или Ubuntu используются.

На уровне снапшотов и фрагментации.

Вот, опять снапшоты зачем-то :)

Отвратительно удаляет мелочь. Совершенно не годится для кешей с тучей мелких файлов, что на сервере бывает весьма часто.

xfs рвет ext4 как Ty3uK грелку.

простой тест создание/удаление файлов 2.5 миллиона файлов в одной директории

Скорость создания/удаления определялась по df -i; sleep 10; df -i --> разница/10

ext4:
создание
 inodes2   inodes1  / sleep
(2341013 - 2338591) / 10 = 242.2
(2357900 - 2341013) / 10 = 1688.7
(2359097 - 2357900) / 10 = 119.7
(2364177 - 2359097) / 10 = 508.0
(2367787 - 2364225) / 10 = 356.2
(2376019 - 2367787) / 10 = 823.2
(2379280 - 2376019) / 10 = 326.1
(2383236 - 2379280) / 10 = 395.6
(2387116 - 2383236) / 10 = 388.0
(2393272 - 2387116) / 10 = 615.6
(2404643 - 2393272) / 10 = 1137.1

$ vmstat 10

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  2 140504 118248 466568 1163432    0    0    48  3446 1314 2174  2  1 58 39  0
 0  3 140504 156920 467188 1128352    0    0     0  6143  910 1443  2  1 55 42  0
 0  3 140504 145332 467872 1135128    0    0     1  2925  548  502  0  0 55 44  0
 0  3 140512 150232 470760 1116104    0    1     3 13096  530  592  1  2 58 39  0
 0  3 140512 147836 471248 1121932    0    0     0  5480  578  426  0  0 56 43  0
 0  3 140512 122820 472160 1133492    0    0     0  4992  498  421  0  1 61 38  0
 0  3 140512 140260 472028 1122776    0    0     0  3655  480  385  0  0 58 42  0
 0  2 140512 183692 472124 1080728    0    0     0  4677  499  466  0  1 53 46  0

Total files: 2534871

Удаление:
(2478379 - 2486326) / 10 = -794.7
(2470284 - 2478295) / 10 = -801.1
(2462257 - 2470284) / 10 = -802.7
(2454218 - 2462257) / 10 = -803.9
(2446207 - 2454218) / 10 = -801.1

(1644608 - 1652638) / 10 = -803.0
(1642607 - 1644608) / 10 = -200.1
(1632302 - 1642607) / 10 = -1030.5
(1620538 - 1632302) / 10 = -1176.4
(1612527 - 1620538) / 10 = -801.1
(1604503 - 1612527) / 10 = -802.4


procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  3 141496 1536896 692956 387108    0    0     1  6705 1069  698  1  1 57 42  0
 0  2 141496 1535872 693568 386984    0    0    51  6145  848  571  0  0 61 38  0
 0  2 141496 1542880 693676 379044    0    0     0  6475  880  517  0  0 59 41  0
 0  2 141496 1541136 694152 379164    0    0    37  6320  880  525  0  0 57 42  0
 0  2 141496 1537852 694260 379036    0    0     0  6778  948  520  0  0 58 41  0
 0  2 141496 1537364 694736 379056    0    0    37  6184  849  636  0  1 56 43  0


XFS

Создание

(    3 -     3)   / 10 = 0
(59534 -     3)   / 10 = 5953.1
(113205 - 59575)  / 10 = 5363.0
(166155 - 113239) / 10 = 5291.6
(218203 - 166190) / 10 = 5201.3
(270638 - 218207) / 10 = 5243.1
(324747 - 270669) / 10 = 5407.8

(1211545 - 1170707) / 10 = 4083.8
(1253588 - 1211734) / 10 = 4185.4
(1294603 - 1253802) / 10 = 4080.1
(1349654 - 1294702) / 10 = 5495.2
(1396565 - 1349684) / 10 = 4688.1

(2398621 - 2347602) / 10 = 5101.9
(2442792 - 2398621) / 10 = 4417.1
(2488683 - 2442811) / 10 = 4587.2
(2534874 - 2488695) / 10 = 4617.9


$ vmstat 10
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  1 141164 391996  56780 1617656    0    0     7    18    8    5  1  0 99  0  0
 0  1 141164 135336  47496 1795256    0    0     0 25302 1760 3826  4 10 86  1  0
 0  1 141164 148828  44216 1693576    0    0     7 27863 1672 3584  3 11 84  2  0
 1  0 141164 151564  44220 1613376    0    0     0 24162 1499 3300  3 10 86  1  0
 1  1 141164 114880  44228 1558792    0    0     0 27302 1385 3056  3 11 85  1  0
 1  1 141164 128048  44232 1497192    0    0     0 23874 1299 2882  3 10 86  1  0
 1  1 141164 124736  44240 1448048    0    0     0 26326 1528 3287  3 11 85  1  0
 1  0 141164 112212  44248 1411808    0    0     0 25005 1310 2821  3 11 85  1  0




Удаление:

(2531357 - 2534874) / 10 = -351.7
(2500135 - 2531357) / 10 = -3122.2
(2473375 - 2500135) / 10 = -2676.0
(2448845 - 2473365) / 10 = -2452.0
(2393933 - 2448835) / 10 = -5490.2
(2321764 - 2393914) / 10 = -7215.0
(2259804 - 2321732) / 10 = -6192.8
(2189649 - 2259801) / 10 = -7015.2
(2117866 - 2189649) / 10 = -7178.3
(2050844 - 2117866) / 10 = -6702.2
(1983289 - 2050822) / 10 = -6753.3
(1918134 - 1983289) / 10 = -6515.5
(1847696 - 1918134) / 10 = -7043.8
(1777260 - 1847696) / 10 = -7043.6


procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0 141156 2355352  45340 202944    0    0   313    82  413 1087  1  1 98  0  0
 0  0 141156 2380356  45348 202556    0    0  1516  1328 1020 1904  2  5 93  1  0
 0  0 141156 2381652  45356 202464    0    0  1291  1334  885 1683  0  4 90  5  0
 0  0 141156 2370860  45364 202444    0    0  1196  1551  905 1744  1  4 90  5  0
 0  0 141156 2342540  45376 202336    0    0  1836  2630 1073 2020  1  7 90  3  0
 0  1 141156 2332452  45384 202464    0    0  1997  3798 1138 2113  1  7 83  9  0
 1  0 141156 2309836  45392 202556    0    0  1773  3268 1091 2041  1  7 84  9  0
 0  0 141156 2301244  45400 202428    0    0  1971  3737 1169 2167  1  8 85  7  0
 0  1 141156 2288376  45408 202488    0    0  1966  3783 1129 2082  0  8 86  6  0
 0  0 141156 2274724  45416 202844    0    0  1838  3395 1796 3468  2  7 81 10  0
 1  1 141144 2249800  45660 217352    2    0  2019  3507 2087 4113  3  8 80  9  0
 1  0 141144 2248772  45668 204740    0    0  1844  3498 3225 6465  7  8 79  6  0
 0  0 141144 2225452  45676 208004    0    0  2048  3486 2775 5633  6  9 79  7  0
 0  0 141144 2220352  45684 205884    0    0  2017  3531 1330 2503  2  8 85  5  0
 1  0 141144 2211824  45692 205916    0    0  1973  3473 1252 2351  2  8 88  3  0
 1  0 141144 2195960  45700 205884    0    0  2115  3694 1272 2383  1  9 87  3  0
 2  0 141096 2180600  45708 205960    5    0  2045  3497 1256 2377  1  8 85  6  0

Debian Jessie, stock kernel 3.16.7-ckt11-1+deb8u3

Выводы?

Выводы?

Мало данных для выводов.

— Не вижу сброса кешей.
— Не вижу активной параллельной работы.

Не исключаю, что в последние несколько лет XFS сильно подкрутили на этот счёт, то без нормальных тестов на веру принять не могу :)

...

Шесть лет назад в таких условиях xfs удалял на два(!) порядка медленнее, чем ext4 :) Надо будет достать скрипты и попробовать повторить тесты.

— Не вижу сброса кешей.

Они были.

— Не вижу активной параллельной работы.

xfs и так рвет ext4 (смотри также iowait для обоих). на параллельной работе ext4 совсем плохой будет.

Не исключаю, что в последние несколько лет XFS сильно подкрутили на этот счёт, то без нормальных тестов на веру принять не могу :)

Потесть, чо, я вот не поленился потестить прямо сейчас.

Шесть лет назад в таких условиях xfs удалял на два(!) порядка медленнее, чем ext4

Я в курсе. xfs я использую лет 10 как минимум, начал использовать ее когда ext3 не умел ресайз онлайн.

Шесть лет назад

Red Hat не зря сделали XFS по умолчанию в RHEL 7. Они очень много ништяков сделали для XFS последнее время. Для параллельной работы подходит лучше других ФС. На счет мелких файлов не помню, но ситуация улучшилась.

используй докер. состав список используемых сервисов. создай для них образы докера. отключи сервисы, запусти докеры.

Докер в продакшн ни за что. KVM только если.

как уже на форуме обсуждалось, то проблемы с докером связаны с беспечностью админов,которые используют образы кем-то сгененированные вместо генерации своих образов.

и в интернете полно проектов, которые ушли от виртуализации на докер.