GNU/Linux

«Всё, что имеет начало, имеет и конец, Нео».

Серия вопросов подходит к завершению и остался последний, самый объёмный вопрос:

В: У Вас маленькая организация. Есть некий сервер, который совмещает в себе много разных функций. Шлюз, файлопомойка, прокси, web-сервер, даже есть виртуалка на KVM, внутри которой крутится условная 1С на windows. В один прекрасный момент к Вам начинают сыпаться сообщения от пользователей, что «Всё тормозит и ничего не работает». Ваши действия? Что и как диагностировать будете? Какими командами? Гуглить времени нет из-за ощущения влажного дыхания директора в затылок.

О: Диагностику можно условно разделить на четыре этапа. По количеству компонентов, которые могли стать «слабым звеном». Это процессор, память, диск и сеть. Но, в первую очередь, надо смотреть в логи. Основное - dmesg, syslog, messages. Зачастую это сэкономит массу времени. Так же не стоит забывать про встроенные средства обзорного мониторинга. Например sar позволяет понять что происходило с системой в последнее время без внешнего мониторинга. Так же различные средства внешнего мониторинга позволят получить обзор системы за последнее время и понять какие метрики являются аномальными. Если этого нет, метрик недостаточно или нужно смотреть в реальном времени - по шагам смотрим каждый компонент:

- Процессор. Необходимо понимать и знать какая нагрузка на процессор данного сервера является штатной. Т.е. нагрузка в 80% может быть вполне нормальной для сервера, а 20% может быть повышенной. Для этого нужен какой-либо мониторинг, который обеспечивает хранение исторических данных, внешний - zabbix, observium, spectrum, munin, или внутренний - sar. Текущую нагрузку можно посмотреть командой top и её производными, htop, atop и прочими, либо sysstat, vmstat. Можно посмотреть load average командой uptime. Если нагрузка аномальна - надо понимать из чего она складывается. Тут три основных компонента - User time, IO wait и System или kernel time. Соответственно это время процессора, затраченное на приложения пользователя, ожидания ввода/вывода и на работу самом системы. С user time всё относительно просто. Достаточно определить проблемное приложение и «поправить» его настройки или просто перезапустить его. IO wait - скорее всего проблема с дисковой подсистемой и более детально об этом будет ниже. Если повышен System time - значит сама система потребляет завышенное количество ресурсов. Причин может быть много и надо иметь более детальное представление о системе. Например старые версии Ubuntu имели глючный kswapd, который утилизировал процессор на 100% при своей работе. Или большое количество сетевых пакетов в следствии той или иной разновидность dos/ddos. Или «залипло» некое приложение пользователя и плодит тяжелые для системы операции, такие как выделение/освобождение памяти или создание большого количества процессов и их завершение.

- Память. Утилизацию можно посмотреть командами top, free, cat /proc/meminfo, vmstat, sar. Необходимо обратить внимание на объём свободной памяти и использование swap. Надо понимать, что метрика «free» не всегда отображает реальное положение дел. В частности буферы/кеш, которые могу занимать память, но могут выгружаться из неё при необходимости. Так же надо знать какие данные попадают в swap. Например, почему при свободной памяти может использоваться swap.

- Диск. Крайне желательно понимать что за диски, как они подключены и собраны. Информацию по использованию можно посмотреть командами iostat или iotop. Первая работает в разрезе блочных устройств, вторая по приложениям. Метрики на которые надо обратить внимание - скорость чтения/записи, время ожидания, количество операций, утилизация устройства. Далее, в зависимости от типа дисков, есть разные варианты развития событий. У виртуальных машин при аномалиях нужно смотреть на диски гипервизора и их утилизацию. У физических серверов - на тип диска и транспорт подключения. Если это обычный диск - смотрим smart и прочие метрики диска командами smartctl, hddtemp, hddparm. Большое количество bad-блоков или перегрев диска могут отрицательно влиять на скорость. Если диски собраны в raid - смотрим на его состояние. Если это программный рейд - команды mdadm или zpool. Для аппаратных через утилиты производителя или через iLO. Для внешних диском надо смотреть из транспорт. Это FC или сеть. Для FC смотрим статистику портов на SAN свичах командами sfpshow, porterrshow и т.д. Для сети смотрим количество ошибок портах командами ifconfig, ip, cat /proc/net/dev. Для внешних дисков так же надо смотреть нагрузку на дисковом массиве или SDS. Так же это могут быть так называемые шумные соседи, которые при отсутствии QOS или его неправильной настройке могут оказывать взаимное влияние.

- Сеть. Для начала можно просто проверить пингом. Обычным и тяжелыми пакетами, размером 1кб. Далее смотрим ошибки на портах сервера или на коммутаторе (если есть доступ). Команды выше. Проверяем настройки командой ethtool. Смотрим скорость интерфейса и подключения. Смотрим внешний мониторинг на предмет утилизации сети. Пробуем проверить качество канала чем то простым, вроде ftp. Если сервер удалённый - смотрим маршруты, на предмет потерь и перестройки. Для этого можно использовать tracepath или mtr.

На этом всё. Для тех, кто дочитал до конца всю серию постов и кому это всё интересно - у меня есть небольшой бонус:

В конце января я решился на один интересный эксперимент. Я выложил на популярных сайтах по поиску работы своё резюме с завышенным ценником. Ну вернее я выложил в регионе резюме с московской зарплатой. Раз в неделю я понижал ожидаемый уровень зарплаты и смотрел количество отзывов, приглашений на собеседования, реальных собеседований, а так же приглашений на работу. Следующий пост будет накопительным, с января по текущую дату, а дальнейшие посты - еженедельные отчёты по успехам. Ну и в последнем посте я попытаюсь собрать всю информацию и сделать отчёт, на сколько востребованы Linux-администраторы в регионах, что предлагают и что ожидают в ответ.

To be continued…

Коснемся темы бекапа, вроде простой вопрос но как много но..

Мне совсем не понравились ответы на эти вопросы, к сожалению очень похоже на презентацию систем хранения,

---

В: Необходимо сделать резервное копирование неких данных. Что бы Вы использовали? Как сделать дёшево и как правильно?

О: Самое простое и дешевое решение это архивация неких данных и вынос на внешний носитель. Для работы с обычными файлами этот метод вполне рабочий. А вот для копирования баз данных, особенно больших и нагруженных, такой метод не подходит. Всё дело в том, что между началом копирования и завершением проходит достаточно много изменений в базе и на выходе получается не консистентный бекап. В таких случаях используется логирование действий для последующей «догонки» базы до актуального состояния. Например в psql для этого используется WAL, у oracle это FRA и т.д., но это уже в зоне ответственности администратора баз данных. Виртуальные машины можно бекапить снапшотами с ротацией и выносом их на другой носитель.

В+: А более «взрослые» решения?

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

---

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

Задача бекапирования на самом деле намного сложнее.

Представьте что у вас файловое хранилище на несколько десятков терабайт, и туда идет запись 7*24, причем записываемые файлики размеров гигабайт по 5-10.

Взрослые решения являются взрослыми из за цены, недавно на HPE day это обсуждали, нормального бекапа все равно не получается, к сожалению оркестраторы не всегда возможно использовать, а иногда они просто не в состоянии помочь.

Бекап это то что позволяет восстановить доступ доступ к сервису, в наикратчайшие сроки(этим в основном и определяется стоимость решения), и вообще его надо делить на три части:

- оперативный(восстановление после программных сбоев или неверных действий пользователей);

- аварийный(восстановление после выхода из строя оборудования);

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

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

Данный пост является продолжением серии постов про собеседования на должность системного администратора linux. По традиции комментарии к предыдущему посту (Системный администратор Linux. Вопросы. Часть 2) в большинстве своём скатились в срач. Адекватных были единицы, но ради них эти посты я и пишу.

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

Вводные завершены, продолжаем список вопросов и ответов.

В: Как отключить iptables на RHEL/Centos 7?

О: Начиная с 7й версии было изменено название демона с iptables на firewalld. Для отключения надо сделать systemctl stop firewalld, а так же отключить его запуск при загрузке systemctl disable firewalld.

В+: Всегда ли этого достаточно?

О+: Нет. Иногда используются надстройки и кастомные скрипты для восстановления правил iptables после перезагрузки. Надо просмотреть вывод systemctl status на предмет скриптов восстановления iptables, а так же post-up, pre-up, post-down, pre-down скрипты в /etc/sysconfig/network-scripts/.

В: Как выполнить некий скрипт на условной 1000 серверов?

О: Можно написать скрипт, который будет обходить сервера по списку и выполнять на них нужные действия.

В+: А есть какие то готовые решения?

О+: Да. Сейчас особенно популярен Ansible. Помимо него есть puppet, chef и т.д. Так же есть различные web-интерфейсы для данных систем. Такие как платный Ansible Tower или бесплатные AWX, Foreman.

В: Необходимо сделать резервное копирование неких данных. Что бы Вы использовали? Как сделать дёшево и как правильно?

О: Самое простое и дешевое решение это архивация неких данных и вынос на внешний носитель. Для работы с обычными файлами этот метод вполне рабочий. А вот для копирования баз данных, особенно больших и нагруженных, такой метод не подходит. Всё дело в том, что между началом копирования и завершением проходит достаточно много изменений в базе и на выходе получается не консистентный бекап. В таких случаях используется логирование действий для последующей «догонки» базы до актуального состояния. Например в psql для этого используется WAL, у oracle это FRA и т.д., но это уже в зоне ответственности администратора баз данных. Виртуальные машины можно бекапить снапшотами с ротацией и выносом их на другой носитель.

В+: А более «взрослые» решения?

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

В: Есть безлимитный бюджет и задача построить максимально отказоустойчивую инфраструктуру. Ваши действия.

О: Основное правило - всех элементов по два. Если говорить про сервер, под систему должно быть два диска в зеркале (тут обычно спрашивается про то, какие raid бывают) или загрузка по SAN, две сетевые карты с LACP или иной active-active агрегацией, два независимых HBA адаптера в двух PCI слотах, каждый из которых подключается в отдельную SAN фабрику. Два блока питания на раздельных линиях питания. Разумеется таких серверов должно быть тоже два. Желательно в разных, георазнесённых, ЦОДах.

В+: А что касается остальной, не серверной части?

О+: Тот же принцип - всего по два. Главное, что бы приложение, которое работает в этой инфраструктуре, тоже умело резервироваться. Т.е. работало по принципу active-active или active-standby без участия человека. Так же, надо учитывать, что одно «плечо» должно тянуть суммарную нагрузку и при этом не упираться в свой предел. Например, штатный максимум по нагрузке на CPU одного плеча - 40%. При падении старого плеча будет 80%. И останется 20% на непредвиденные ситуации, которые часто в таких случаях появляются.

В: Что нужно для кластерной виртуализации?

О: Основное требование - наличие общего хранилища. Так же желательно иметь одинаковые настройки сети на всех нодах кластера. Это нужно для горячей миграции и для миграции машин при авариях.

В: Каким образом можно подключить диски к кластеру?

О: Общее хранилище может быть реализовано различными средствами - SAN, iSCSI, Ceph.

В+: Какой способ оптимальный из предложенных?

О+: Всё зависит от инфраструктуры, целей, бюджета и количества инженеров, выделенных на поддержку. Например Ceph можно собрать из весьма разносортных нод. При минимальном бюджете это хорошее решение. Вот только затраты человеческих ресурсов на него значительно завышены. SAN - дорогое по железу и относительно простое в поддержке решение. В любом случае придётся платить. Либо за железо, либо инженерам.

В: В чём преимущество Fibre Channel перед iSCSI?

О: В SAN сетях есть гарантированная доставка, меньше накладных ресурсов, сеть разрабатывалась как транспорт для дисковых носителей. В тоже время iSCSI это надстройка над ethernet, со всеми его недостатками.

В+: Допустим у нас есть два простых FC свича и два Ethernet свича. Каждую пару свичей мы соединим двумя линками. Что с ними произойдёт?

О+: FC свичи, при наличии лицензии, объединят два линка в один с удвоенной пропускной способностью. Ethernet свичи получат так «кольцо» и перестанут работать спустя какое-то время, которое зависит от объёма траффика в данном сегменте сети.

В: Есть некая виртуальная машина на VMWare. У машины 2 гигабайта памяти. В настройках машины стоят галочки «Можно добавлять память на горячую» и «Можно добавлять процессор на горячую». Внутри машины стоят все нужные гостевые дополнения. Система стоит x64. Можно ли сделать машине 6 гигабайт памяти на горячую?

О: Нет. На горячую можно будет подойти к отметке в 4 гигабайта, но пересечь её не получится.

В+: Почему? Система, ведь, поддерживает?

О+: Основной принцип памяти - отсутствие фрагментации. Т.е. вся память должна быть непрерывна. Если система стартует с объёмом памяти менее 4 гигабайт, часть старших адресов 32-битной шины резервируется под ввод-вывод. Соответственно расширять память можно до этих пределов. Если на старте памяти было 4 гигабайта и более, под ввод-вывод резервируется блок в верхней части уже существующего 64-битного адресного пространства.

В: Есть неограниченный бюджет и некая абстрактная платформа, которая умеет много памяти. Какой теоретический максимум памяти можно установить в такой сервер если система x86 и если система x64?

О: Предел x86 - 32 бита непрерывного адресного пространства, т.е. 4 гигабайта. Однако с использованием PAE объём памяти увеличивается до 64 гигабайт, но не более 4 гигабайт на процесс, т.к. адресная шина так и сталось 32 бита. Теоретический предел существующих x64 систем - 48 бит адресного пространства.

В+: Из чего получаются эти 48 бит?

О+: Размер страницы памяти 4 килобайта или 12 бит. Нумерация страниц - 36 бит. Итого получается 256 терабайт памяти.

На этом пока всё. Остался последний большой вопрос, объёмом на отдельный пост.