Пять шагов к спасению Linux-» target=»_blank»>сервера, который рухнул
Мне доводилось видеть множество Linux-» target=»_blank»>серверов, которые, без единой перезагрузки, работали годами, в режиме 24×7. Но ни один компьютер не застрахован от неожиданностей, к которым могут вести «железные», программные и сетевые сбои. Даже самый надёжный » target=»_blank»>сервер может однажды отказать. Что делать? Сегодня вы узнаете о том, что стоит предпринять в первую очередь для того, чтобы выяснить причину проблемы и вернуть машину в строй.
Поиск и устранение неполадок: раньше и теперь
Когда, в 1980-х, я начал работать системным администратором Unix — задолго до того, как Линус Торвальдс загорелся идеей Linux — если с » target=»_blank»>сервером было что-то не так, это была реальная засада. Тогда было сравнительно мало инструментов для поиска проблем, поэтому для того, чтобы сбойный » target=»_blank»>сервер снова заработал, могло понадобиться много времени.
Теперь всё совсем не так, как раньше. Как-то один системный администратор вполне серьёзно сказал мне, говоря о проблемном » target=»_blank»>сервере: «Я его уничтожил и поднял новый».
В былые времена такое звучало бы дико, но сегодня, когда ИТ-инфраструктуры строят на основе виртуальных машин и контейнеров… В конце концов, развёртывание новых » target=»_blank»>серверов по мере необходимости — это обычное дело в любой облачной среде.
Сюда надо добавить инструменты DevOps, такие, как Chef и Puppet, используя которые легче создать новый » target=»_blank»>сервер, чем диагностировать и «чинить» старый. А если говорить о таких высокоуровневых средствах, как Docker Swarm, Mesosphere и Kubernetes, то благодаря им работоспособность отказавшего » target=»_blank»>сервера будет автоматически восстановлена до того, как администратор узнает о проблеме.
Данная концепция стала настолько распространённой, что ей дали название — бес» target=»_blank»>серверные вычисления. Среди платформ, которые предоставляют подобные возможности — AWS Lambda, Iron.io, Google Cloud Functions.
Благодаря такому подходу облачный сервис отвечает за администрирование » target=»_blank»>серверов, решает вопросы масштабирования и массу других задач для того, чтобы предоставить клиенту вычислительные мощности, необходимые для запуска его приложений.
Бес» target=»_blank»>серверные вычисления, виртуальные машины, контейнеры — все эти уровни абстракции скрывают реальные » target=»_blank»>серверы от пользователей, и, в некоторой степени, от системных администраторов. Однако, в основе всего этого — физическое аппаратное обеспечение и операционные системы. И, если что-то на данном уровне вдруг разладится, кто-то должен привести всё в порядок. Именно поэтому то, о чём мы сегодня говорим, никогда не потеряет актуальности.
Помню разговор с одним системным оператором. Вот что он говорил о том, как надо поступать после сбоя: «Переустановка » target=»_blank»>сервера — это путь вникуда. Так не понять — что стало с машиной, и как не допустить такого в будущем. Ни один сносный администратор так не поступает». Я с этим согласен. До тех пор, пока не обнаружен первоисточник проблемы, её нельзя считать решённой.
Итак, перед нами » target=»_blank»>сервер, который дал сбой, или мы, по крайней мере, подозреваем, что источник неприятностей именно в нём. Предлагаю вместе пройти пять шагов, с которых стоит начинать поиск и решение проблем.
Шаг первый. Проверка аппаратного обеспечения
В первую очередь — проверьте железо. Я знаю, что звучит это тривиально и несовременно, но, всё равно — сделайте это. Встаньте с кресла, подойдите к » target=»_blank»>серверной стойке и удостоверьтесь в том, что » target=»_blank»>сервер правильно подключён ко всему, необходимому для его нормальной работы.
Я и сосчитать не смогу, сколько раз поиски причины проблемы приводили к кабельным соединениям. Один взгляд на светодиоды — и становится ясно, что Ethernet-кабель выдернут, или питание » target=»_blank»>сервера отключено.
Конечно, если всё выглядит более-менее прилично, можно обойтись без визита к » target=»_blank»>серверу и проверить состояние Ethernet-соединения такой командой:
Если её ответ можно трактовать, как «да», это значит, что исследуемый интерфейс способен обмениваться данными по сети.
Однако, не пренебрегайте возможностью лично осмотреть устройство. Это поможет, например, узнать, что кто-то выдернул какой-нибудь важный кабель и обесточил таким образом » target=»_blank»>сервер или всю стойку. Да, это до смешного просто, но удивительно — как часто причина отказа системы именно в этом.
Ещё одну распространённую аппаратную проблему невооружённым взглядом не распознать. Так, сбойная память является причиной всевозможных проблем.
Виртуальные машины и контейнеры могут скрывать эти проблемы, но если вы столкнулись с закономерным появлением отказов, связанных с конкретным физическим выделенным » target=»_blank»>сервером, проверьте его память.
Для того, чтобы увидеть, что BIOS/UEFI сообщают об аппаратном обеспечении компьютера, включая память, используйте команду dmidecode:
Даже если всё тут выглядит нормально, на самом деле это может быть и не так. Дело в том, что данные SMBIOS не всегда точны. Поэтому, если после dmidecode память всё ещё остаётся под подозрением — пришло время воспользоваться Memtest86. Это отличная программа для проверки памяти, но работает она медленно. Если вы запустите её на » target=»_blank»>сервере, не рассчитывайте на возможность использовать эту машину для чего-нибудь другого до завершения проверки.
Если вы сталкиваетесь со множеством проблем с памятью — я видел такое в местах, отличающихся нестабильным электропитанием — нужно загрузить модуль ядра Linux edac_core. Этот модуль постоянно проверяет память в поиске сбойных участков. Для того, чтобы загрузить этот модуль, воспользуйтесь такой командой:
Подождите какое-то время и посмотрите, удастся ли что-нибудь увидеть, выполнив такую команду:
Эта команда даст вам сводку о числе ошибок, разбитых по модулям памяти (показатели, название которых начинается с csrow ). Эти сведения, если сопоставить их с с данными dmidecode о каналах памяти, слотах и заводских номерах компонентов, помогут выявить сбойную планку памяти.
Шаг второй. Поиск истинного источника проблемы
Итак, » target=»_blank»>сервер стал странно себя вести, но дым из него ещё пока не идёт. В » target=»_blank»>сервере ли дело? Прежде чем вы попытаетесь решить возникшую проблему, сначала нужно точно определить её источник. Скажем, если пользователи жалуются на странности с » target=»_blank»>серверным приложением, сначала проверьте, что причина проблемы — не в сбоях на клиенте.
Например, друг однажды рассказал мне, как его пользователи сообщили о том, что не могут работать с IBM Tivoli Storage Manager. Сначала, конечно, казалось, что виновен во всём » target=»_blank»>сервер. Но в итоге администратор выяснил, что проблема вообще не была связана с » target=»_blank»>серверной частью. Причиной был неудачный патч Windows-клиента 3076895. Но то, как сбоило это обновление безопасности, делало происходящее похожим на проблему » target=»_blank»>серверной стороны.
Кроме того, нужно понять, является ли причиной проблемы сам » target=»_blank»>сервер, или » target=»_blank»>серверное приложение. Например, » target=»_blank»>серверная программа может работать кое как, а железо оказывается в полном порядке.
Для начала — самое очевидное. Работает ли приложение? Есть множество способов проверить это. Вот два моих любимых:
Если оказалось, что, например, веб-» target=»_blank»>сервер Apache не работает, запустить его можно такой командой:
Если в двух словах, то прежде чем диагностировать » target=»_blank»>сервер и искать причину проблему, узнайте — » target=»_blank»>сервер ли виноват, или что-то другое. Только тогда, когда вы поймёте, где именно находится источник сбоя, вы сможете задавать правильные вопросы и переходить к дальнейшему анализу того, что произошло.
Это можно сравнить с неожиданной остановкой автомобиля. Вы знаете, что машина дальше не едет, но, прежде чем тащить её в сервис, хорошо бы проверить, есть ли бензин в баке.
Шаг третий. Использование команды top
Шаг четвёртый. Проверка дискового пространства
Даже сегодня, когда в кармане можно носить терабайты информации, на » target=»_blank»>сервере, совершенно незаметно, может кончиться дисковое пространство. Когда такое происходит — можно увидеть весьма странные вещи.
Разобраться с дисковым пространством нам поможет старая добрая команда df, имя которой является сокращением от «disk filesystem». С её помощью можно получить сводку по свободному и использованному месту на диске.
Обычно df используют двумя способами.
Если что-то кажется вам странным, можно копнуть глубже, воспользовавшись командой Iostat. Она является частью sysstat — продвинутого набора инструментов для мониторинга системы. Она выводит сведения о процессоре, а также данные о подсистеме ввода-вывода для блочных устройств хранения данных, для разделов и сетевых файловых систем.
Вероятно, самый полезный способ вызова этой команды выглядит так:
Такая команда выводит сведения об объёме прочитанных и записанных данных для устройства. Кроме того, она покажет среднее время операций ввода-вывода в миллисекундах. Чем больше это значение — тем вероятнее то, что накопитель перегружен запросами, или перед нами — аппаратная проблема. Что именно? Тут можно воспользоваться утилитой top для того, чтобы выяснить, нагружает ли » target=»_blank»>сервер MySQL (или какая-нибудь ещё работающая на нём СУБД). Если подобных приложений найти не удалось, значит есть вероятность, что с диском что-то не так.
Работая с утилитами для проверки дисков, обращайте внимание, что именно вы анализируете.
Например, нагрузка в 100% на логический диск, который представляет собой несколько физических дисков, может означать лишь то, что система постоянно обрабатывает какие-то операции ввода-вывода. Значение имеет то, что именно происходит на физических дисках. Поэтому, если вы анализируете логический диск, помните, что дисковые утилиты не дадут полезной информации.
Шаг пятый. Проверка логов
Для новичков в Linux лог-файлы могут выглядеть как ужасная мешанина. Это — текстовые файлы, в которые записываются сведения о том, чем занимаются операционная система и приложения. Есть два вида записей. Одни записи — это то, что происходит в системе или в программе, например — каждая транзакция или перемещение данных. Вторые — сообщения об ошибках. В лог-файлах может содержаться и то, и другое. Эти файлы могут быть просто огромными.
Данные в файлах журналов обычно выглядят довольно таинственно, но вам всё равно придётся с ними разобраться. Вот, например, хорошее введение в эту тему от Digital Ocean.
Есть множество инструментов, которые помогут вам проверить логи. Например — dmesg. Эта утилита выводит сообщения ядра. Обычно их очень и очень много, поэтому используйте следующий простой сценарий командной строки для того, чтобы просмотреть 10 последних записей:
Вот ещё один удобный сценарий командной строки:
Он сканирует логи и показывает возможные проблемы.
Бывает полезно настроить journald так, чтобы он сохранял логи после перезагрузки системы. Сделать это можно, воспользовавшись такой командой:
Самый распространённый способ работать с этими журналами — такая команда:
Она покажет все записи журналов после последней перезагрузки. Если система была перезагружена, посмотреть, что было до этого, можно с помощью такой команды:
Мне, например, нравится система для управления логами с открытым кодом Graylog. Она собирает, индексирует и анализирует самые разные сведения. В её основе лежат MongoDB для работы с данными и Elasticsearch для поиска по лог-файлам. Graylog упрощает отслеживание состояния » target=»_blank»>сервера. Graylog, если сравнить её со встроенными средствами Linux, проще и удобнее. Кроме того, среди её полезных возможностей можно отметить возможность работы с многими DevOps-системами, такими, как Chef, Puppet и Ansible.
Итоги
Как бы вы ни относились к вашему » target=»_blank»>серверу, возможно, он не попадёт в Книгу Рекордов Гиннеса как тот, который проработал дольше всех. Но стремление сделать » target=»_blank»>сервер как можно более стабильным, добираясь до сути неполадок и исправляя их — достойная цель. Надеемся, то, о чём мы сегодня рассказали, поможет вам достичь этой цели.
Уважаемые читатели! А как вы обычно поступаете с упавшими » target=»_blank»>серверами?
Топ-10 причин падения » target=»_blank»>серверов
— Ты чего такой грустный?
— Да вот » target=»_blank»>сервер вчера «упал».
— Ну да, ты что его до сих пор не «поднял»?
— Поднял, но он со стола упал.
10 место. Резервное копирование. Системные администраторы бывают двух видов: которые делают резервные копии и которые пока не делают резервные копии. Бывает еще и третий вид, но очень редкий: системные администраторы, которые проверяют свои резервные копии. На них вся надежда.
8 место. Оборудование. Вместо » target=»_blank»>серверных платформ используются обычные рабочие станции. Бывали случаи, когда база 1С лежала у бухгалтера на рабочем компьютере на диске D, и даже резервных копий никто не делал! Вопиющая смелость!
7 место. Использование нелицензионного ПО. Был случай, когда один товарищ пытался убедить меня в то, что весть его софт абсолютно лицензионный. Дабы подтвердить свои слова, мне был продемонстрирован лицензионный компакт-диск со всем софтом, купленный в фирменной палатке на Ждановичах. Чек прилагался.
6 место. Плановые замены HDD. Примерно раз в два-три месяца слышу новую историю про рассыпавшийся RAID. Для » target=»_blank»>серверных винчестеров ресурс составляет не более 4 лет. Еще одной частой ошибкой является использование дешевых, не » target=»_blank»>серверных винчестеров, что также весьма чревато. Еще я рекомендую при покупке нового оборудования закупать парочку винчестеров в запас, на всякий пожарный.
5 место. Запуск нескольких сервисов на одном » target=»_blank»>сервере. Говорят, системные администраторы не смешиваю. Все они смешивают! Особенно любят администраторы смешивать контроллеры домена с чем-нибудь еще, например, с MS SQL и с 1C, файловым » target=»_blank»>сервером, прокси-» target=»_blank»>сервером и др. Лет 5 назад это не вызвало бы больших нареканий, но сегодня нравы поменялись, смешивать как минимум, неприлично, как максимум, небезопасно.
4 место. Встроенная учетная запись администратора. Как взломать » target=»_blank»>сервер: берем шару и подбираем пароль к встроенной учетной записи администратора. Если пароль состоит из 4 цифр – пара минут, и » target=»_blank»>сервер наш! А всего-то нужно было учетную запись отключить, а еще лучше и переименовать, да через групповые политики.
2 место. Брандмауэр. Какими бы крепкими ни были стены города, они не защитят жителей от больного чумой внутри периметра. Конечно, все дома в городе забором не обнесешь, а вот улочку с » target=»_blank»>серверами обгородить вполне возможно, более того, сисадмины могут сделать это бесплатно и быстро, а если повезет, то и качественно.
В очередной раз мы видим, как данные статистики сходятся с жизненными реалиями. А как дела обстоят у вас?
Андрей Махнач
руководитель отдела инфраструктурных решений СООО «ДПА»
Проблемы с » target=»_blank»>сервером — что делать?
Как могут выглядеть типичные сбои » target=»_blank»>сервера:
Причины сбоя и поломок » target=»_blank»>сервера, типичные неисправности:
Как устранить и предотвратить проблемы с » target=»_blank»>сервером
Предотвратить поломки » target=»_blank»>сервера значительно проще и дешевле, чем устранять, когда они уже проявились.
Вот несколько требований, выполняя которые вы сможете снизить вероятность отказа вашего » target=»_blank»>сервера:
Если несмотря на все предпринятые меры у вас все же возникли проблемы с » target=»_blank»>сервером, что делать?
В некоторых случаях можно попробовать самостоятельно провести диагностику, чтобы понять, что произошло и как исправить проблемы с » target=»_blank»>сервером:
Срочный ремонт » target=»_blank»>серверов, что можно сделать
Как устранить проблему с » target=»_blank»>сервером. Если у вас на » target=»_blank»>сервере произошел сбой, а его простой или потеря данных грозят компании серьезными убытками, лучше не пытаться исправить все самостоятельно, а сразу обратиться к специалистам за помощью, это будет быстрее и эффективнее.
Например, неквалифицированная попытка восстановить данные может вместо этого окончательно их уничтожить.
Обслуживание » target=»_blank»>серверов
Инженеры ГК «Интегрус» уже много лет занимаются сервисным обслуживанием и ремонтом » target=»_blank»>серверов, к нам всегда можно обратиться за бесплатной консультацией, аудитом, а если понадобится — то и за срочным ремонтом » target=»_blank»>серверов.
Мы выполняем весь перечень ремонтных работ, работ по восстановлению данных с » target=»_blank»>сервера при аппаратном или программном сбое, восстановлению » target=»_blank»>сервера из бэкапа, сервисному обслуживанию, настройке защиты » target=»_blank»>сервера от взлома, профилактике и мониторингу, модернизации, созданию » target=»_blank»>серверной «под ключ».
Популярные причины падения сайтов
Медленная загрузка и некорректная работа сайта, полное падение веб-ресурса или недоступность отдельных страниц – это настоящее бедствие для любого онлайн-бизнеса в независимости от тематики и направления. Теряется трафик, потенциальные клиенты уходят на конкурирующие ресурсы, падают продажи, снижаются seo-показатели и позиции в поисковой выдаче. Эта публикация посвящена обзору наиболее распространенных проблем и типичных «болезней» сайтов, опираясь на опыт сервиса мониторинга доступности сайтов ХостТрекер и его клиентов.
Причины недоступности веб-сайтов
Как с этим бороться?
Чтобы избежать оттока клиентов и падения продаж, снижения позиций при ранжировании поисковиками, нужно постоянно контролировать работу ресурса, своевременно получать информацию о недоступности сайта для пользователей и устранять неполадки.
Иными словами, постоянно поддерживать сайт.
Физически невозможно круглосуточно следить за функционированием веб-ресурсов, поминутно в ручном режиме перезагружая отдельные страницы. Поэтому желательно максимально автоматизировать процесс работы, обновлений и мониторинга сайта, а также каким-то образом настроить обратную связь — чтобы вовремя узнавать о неполадках. Популярными решениями являются сервисы Яндекс.Метрика и Google Analytics. Они действуют таким образом: клиент размещает у себя на сайте специальный скрипт, который каждый раз при входе на сайт посетителя отправляет данные куда надо. Во-первых, Вы получаете много хорошей статистики. Во-вторых, если вдруг посещение сайта падает, то появляется предположение, что с сайтом что-то не то, о чем они вас могут оповестить. Могут и отдельно перепроверить. Разные сервисы предлагают разные интересные функции. Но есть и отдельные профессиональные инструменты для подобных задач.
Сервисы мониторинга: выявление проблем
Провести диагностику веб-ресурса, выявить причины неполадок и установить круглосуточный контроль над функционированием сайта можно с помощью специализированных сервисов. Службы мониторинга предоставляют различные инструменты для комплексной и полностью автоматизированной проверки сайтов. Примером такого сервиса является, собственно, ХостТрекер.
С помощью подобных сервисов можно легко и быстро найти слабые места сайта и получить реальную картину его поведения во времени, а также избежать награды непричастных и наказания невиновных.
Это работает для всех вышеуказанных проблем. Если сервис показывает, что у сайта «прыгает» скорость загрузки, при том что количество посетителей равномерно распределено в течении дня, или же возвращаются таймауты — вопросы к хостеру. Также это может быть свидетельством того, что ваш сайт «перерос» купленный когда-то начальный пакет услуг » target=»_blank»>сервер, » target=»_blank»>хостинга, и сейчас для стабильной работы ему нужно больше ресурсов. К хостеру же возникают вопросы, если в договоре он гарантирует SLA 99.9%, а сам ежемесячно проводит многочасовые технические работы: легко проверить, не нарушил ли он свои гарантии. Если часто выпадают ошибки 50Х — скорее всего, дело в сайте или настройках » target=»_blank»>сервера. В этом случае обращаемся к разработчикам. Сервисы также контролируют срок действия сертификатов и доменов, вовремя оповещая о необходимости продления, а также множество других вещей.
Диагностика VPS или что делать, если » target=»_blank»>сервер упал речь о » target=»_blank»>сервере под управлением CentOS и ISPmanager
Мы (пока что) пользуемся Windows, поэтому бородатым тру-админам чтение доставит лулзов и хихихохонек. С другой стороны, почему-то бородатые тру-админы не дают себе труда публично изложить свои навыки простыми русскими словами на благо всего человечества. А мы даем.
Итак, самые популярные проблемы виртуальных » target=»_blank»>серверов.
Нехватка оперативной памяти
Проявляется, обычно, в самопроизвольном завершении работы тех или иных сервисов. Отключиться может apache, mysql, ftp или обслуживание dns.
Dos-атака из внешнего мира
Например, кто-то решил спарсить ваш контент или найти дыру в безопасности сайта. Ваш » target=»_blank»>сервер перестает выдерживать высокую синтетическую нагрузку и тупит.
Нехватка дискового пространства
Очень частая проблема, поскольку компьютеры склонны генерировать данные неутомимо, бездумно и безостановочно 🙂
Также следует сделать автоматизированную проверку свободного объема диска, например через Ping-admin и служебный домен для проведения различных автотестов