Проблема с сервером (реальный кейс из практики) - триллер из жизни системного администратора!
Проблема произошла с выделенным сервером для сайта zakazartistov.com (zakazartistov.com.ua / zakazartistov.com.kz). Первоначальный анализ проблемы. Сайт стал медленно редактироваться. Не стабильно отдавал контент.

Виктор Таран: Тех. Директор студии Клондайк
Первая идея была о массированной 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 дополнениями.
После тестирования машины сайт залит обратно, восстановлена многосайтовость. Склеены зеркала. Сайт полностью работоспособен. Так же сервер избавлен от двух неисправностей, природу которых так и не смогли объяснить ни тех. поддержка, ни Битрикс.
Полностью обновленное ПО на сервере.Во избежание подобных поломок, принято решение впредь изменить систему бэкапирвоания с использованием внешних носителей, способных быстро развернуть существующий сайт на резервном сервере, фактически просто переписав, А запись. Более детально сканируем диски в штатном режиме на плохие сектора.
По окончательному анализу ошибки, все работы были логичны и справедливы. Более быстрое решение проблемы не гарантировало сохранности контента.
Оставить комментарий