klondike

Корпоративный блог студии "Клондайк"

Клондайк интернет маркетинга - WEB, SEO, SMM


Previous Entry Share Next Entry
Таран Виктор
klondike

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

Проблема произошла с выделенным сервером для сайта 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)
лог:
[Spoiler (click to open)]1566640
1566641
1566642
1566643
1568416
1568417
1568418
1568419
1568420
1568421
1568422
1568423
1568424
1568425
1568426
1568427
1570208
1570209


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

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

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

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

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

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

= Лайки не ставим =

?

Log in

No account? Create an account