Проблема с сервером (реальный кейс из практики) - триллер из жизни системного администратора!


Первая идея была о массированной DDOS атаке, но после анализа логов от этой версии пришлось отказаться, поскольку количество «мусорных» запросов хоть и находилось выше нормы, но не могло привести к столько сильному замедлению системы.

При более детальном тестирование стала понятна причина. Собрав минимальную информацию для анализа, стала ясна проблема. «Затык» происходил в базовой системе ввода-вывода давая нагрузку на /dev/sda в 100%. При этом, количество информации, проходящей через интерфейс, было явно недостаточно для такой перегрузки. При дальнейшем анализе была выявленна десинхронизация рейд массива и сборка его заново.

md1 : active raid1 sda3[0] sdb3[1]
 1951939452 blocks super 1.1 [2/2] [UU]
 [====>................] check = 21.0% (410989184/1951939452) finish=32008.9min speed=301K/sec
 bitmap: 2/15 pages [8KB], 65536KB chunk

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

Затем тесты сразу же перешли к S.M.A.R.T, который в свою очередь отдал информацию по всем дискам — «ОК»;

Тем самым поставив в тупик дальнейший анализ проблемы. Поскольку явно указывающая проблема на жесткий диск утилитами не подтвердилась, в дальнейшем требовалось найти какой из дисков неисправен и «выбросить» его из массива. Внесение дисков в массив и вынос за его пределы хоть и потенциально опасная операция, но штатная. Однако учитывая важность проекта было решено сделать изначально полный бэкап сайта и развернуть его на другой площадке. Поскольку потеря данных в данном проекте недопустима ни при каких обстоятельствах. А учитывая неявность проблемы и не локализованности причины, пришлось переностить весь сайт.

Поскольку сервер отдавал контент с недопустимо маленькой скоростью — обычное создание бэкапа делалось бы 50 дней, плюс соответственно столько же для его переноса. Такой результат нас не радовал. Посему от него пришлось отказаться сразу, да и создание бэкапа весом 60 GB на потенциально нерабочем носителе не гарантировало успеха.

На запасном сервере экстренно разворачивается старая версия сайта (около 20 дней) беэ медиа контента.

А записи переписываются на запасной сервер

Боевой сервер уходит в LiveCD загрузку

Количество средств для работ с массивом достаточно ограничено в связи со специфичностью LiveCD ОС. Так что из рабочих инструментов только SFTP SSH с ограниченным функционалом (sshfs уже не доступен). Прямое копирование с боевого сервера на запасной не увенчалось успехом, поскольку при чтении файлов выходили IO ошибки. Скорость копирования неудовлетворительна.

Смонтировав массив в режиме «-ro», Удалось повысить скорость работы винтов, но не избавиться от ошибки IO. Однако при уменьшение скорости копирования файлов ошибка исчезала. Пришлось принудительно понизить скорость копирования до 300к-1 м в секунду.

И заливать на промежуточный сервер с полноценным SFTP клиентом поскольку консольные команды 60 Gb файлов корректно не переносили и при первой же ошибке останавливали перенос. В результате копирование заняло несколько дней. Плюс еще пару дней на перенос информации на запасной сервер и тестирование ее.

Далее, после подтверждения работоспособности перенесенного контента, работы на боевом сервере возобновились.

Размонтировав все дисковые массивы, проверили диски по отдельности. В результате проверки поверхности диска:

badblocks -o sda.txt -vs /dev/sda
Checking blocks 0 to 1953514583
Checking for bad blocks (read-only test): 0.93% done, 8:30 elapsed. (18/0/0 errors)

лог:

1566640
1566641
1566642
1566643
1568416
1568417
1568418
1568419
1568420
1568421
1568422
1568423
1568424
1568425
1568426
1568427
1570208
1570209

Далее, сообща со службой поддержки, диск был заменен, новый диск был внесен в рейд массив. И протестирована их работоспособность полноценными тестами обоих дисков и всего массива.

Поскольку сайт находился на другом сервере и работал на 99% в штатном режиме, было принято решение обновить все ПО на сервере, поскольку в сборке от 1С-Битрикс были найдены необъяснимые неисправности, которые даже сами представители Битрикс не смогли исправить.

На чистую ОС накатилась последняя конфигурация битрикс машины, плюс кастомизировалась под zakazartistov.com дополнениями.

После тестирования машины сайт залит обратно, восстановлена многосайтовость. Склеены зеркала. Сайт полностью работоспособен. Так же сервер избавлен от двух неисправностей, природу которых так и не смогли объснить ни тех. поддержка, ни Битрикс.

Полностью обновленое ПО на сервре.

Во избежание подобных поломок, принято решение впредь изменить систему бэкапирвоания с использованием внешних носителей, способных быстро развернуть существующий сайт на резервном сервере, фактически просто переписав, А запись. Более детально сканируем диски в штатном режиме на плохие сектора.

По окончательному анализу ошибки, все работы были логичны и справедливы. Более бысторое решение проблемы не гарантировало сохранности контента.


Оставить комментарий