ServerAdmin.ru
28.6K subscribers
265 photos
34 videos
12 files
2.59K links
Авторская информация о системном администрировании.

Информация о рекламе: @srv_admin_reklama_bot
Автор: @zeroxzed

Второй канал: @srv_admin_live
Сайт: serveradmin.ru
Download Telegram
​​Смотрите, какой любопытный проект у нас появился:
https://repka-pi.ru

Аналог Raspberry Pi. Выполнен в полностью идентичном форм-факторе, включая габаритные размеры, размеры и расположение основных интерфейсов, места и размеры отверстий для крепления.

Разработка в России. Это не переклеивание шильдиков. Компонентная база китайская, по маркировке всё видно, схемотехника и трассировка российские. Продукт коммерческой компании, без бюджетных денег. Подробное описание разработки лучше почитать от создателей.

Одноплатники в свободной продаже. Заказать можно как на сайте проекта, так и на ozon. ❗️Существенный минус - образы ОС от Raspberry Pi не подходят из-за разных схем питания. У репки свой образ Repka OS на базе Ubuntu. Также поддерживается работа ALT Linux.

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

Мне прям всё понравилось. Цена конкурентная, сайт, описание, упаковка чёткие. Отзывы хорошие, в том числе на качество компонентов, сборки и пайки. Да и в целом хорошо, что подобные компании и продукты есть в России. Это позволяет нарабатывать компетенции, создавать высококвалифицированные рабочие места.

Жаль, что мне одноплатники никогда не были нужны, так бы купил. Цена платы - 7400, сразу с корпусом - 9700. Ждать доставки из Китая не надо. Озон за несколько дней привезёт в любой пункт выдачи.

p.s. Узнал о репке из рекламы в ВК. А кто-то думает, что реклама не работает. Сработала очень даже хорошо для заказчиков.

#железо #отечественное
​​Очень простой и быстрый способ в Linux узнать, какой тип диска у вас в системе, HDD или SSD:

# cat /sys/block/sda/queue/rotational
1

# cat /sys/block/sde/queue/rotational
0

Диск sda — HDD, sde — SSD. Это работает только для железных серверов. То есть параметр буквально указывает, что первый диск с вращением, а второй — без. На основе этих данных ядро системы по возможности избегает одиночного поиска, чтобы лишний раз не дёргать диск. Вместо этого выстраивает запросы в очередь. Для SSD этот механизм становится неактуальным.

В виртуальных машинах могут быть разные значения. Чаще всего они будут показывать, что работают на HDD, если в гипервизоре специально не настроена эмуляция SSD. В Proxmox за это отвечает один из параметров диска — SSD Emulation. Если поставить соответствующую галочку, то виртуалка будет понимать, что работает на SSD. Это имеет смысл делать, хоть и не критично.

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

#железо
Хочу продолжить вчерашнюю тему с удалёнными перезагрузками и отрубанием серверов. Немного повспоминал и решил сразу написать, пока не забыл, ещё несколько своих историй по этой теме.

1️⃣ Эту историю я тут описывал и даже статью написал. После обновления сделал штатную перезагрузку виртуалки, а она не поднялась. Немного подождал и пошёл смотреть консоль. Там принудительно началась проверка fsck диска на 3Тб. Длилась она несколько часов. Пришлось понервничать, так как не был уверен, что всё завершится благополучно. С тех пор на больших дисках слежу за этими проверками.

2️⃣ Этот случай был недавно. Достался в наследство сервер с MSSQL, где базы вынесены на отдельный дисковый массив, который представляет из себя внешнюю коробку, подключенную по SCSI разъёму (если не ошибаюсь, точно не помню уже). Проблема в том, что коробочка недорогая. Качество уровня desktop, больше для домашних пользователей. Решили сэкономить. После штатного отключения питания, коробочка не включилась. У неё было своё отдельное питание. Сервер загрузился, базы все лежат. Подключаюсь к серверу, массива нет, соответственно, ничего не работает. Попросил человека на месте проверить, в чём дело. Сказал, что коробка выключена и не включается.

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

3️⃣ С подобной ситуацией сталкивался не раз и уже сильно учёный на этот счёт. Все серваки, подключенные к УПСу должны штатно завершать свою работу, когда заряд кончается. Обычно к этому приходят не сразу, а после того, как в один прекрасный день электричество вырубят не на 5 минут, а на пол дня.

И второй важный момент. Они не должны подниматься автоматически. К этому тоже приходят не сразу, а после того, как хапнут проблем. Я всё это проходил. Вырубается электричество, серваки штатно завершают работу, когда батареи пусты. Потом подаётся электричество, серваки включаются, а через 5 минут электричество опять отключают. И всё моментально аварийно падает в момент загрузки. На этом этапе я лично терял VM. С тех пор автоматически запускаются только гипервизоры. А виртуальные машины я или кто-то ещё включает вручную через некоторое время, когда точно понятно, что отключения прекратились и батареи немного зарядились.

❗️ Это просто совет. Когда меняете сетевые настройки, существенные параметры файрвола, либо что-то по железу (добавляете какое-то хранилище, сетевую карту с загрузкой драйвера), либо в системе то, что потенциально может приводить к проблемам загрузки или внешнего доступа. Не откладывайте перезагрузку, а сделайте её по возможности как можно раньше. Иначе может случиться так, что вы через пол года перезагрузите сервер и начнутся проблемы, которые вызваны этими изменениями, а вы про них забыли. Таких примеров у меня была масса.

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

Либо настраиваешь firewall, применяешь правила, всё в порядке, доступ на месте. И забываешь включить автозапуск файрвола. Через несколько месяцев перезагружаешься и не замечаешь, что правил нет и у тебя всё в открытом доступе. Потом это долго можно не замечать, если не ставил на мониторинг.

Ещё пример. Меняешь сложный dialplan в asterisk. Перезагрузку откладываешь на потом, чтобы не прерывать текущую работу. И забываешь. А при очередной перезагрузке не можешь понять, почему что-то работает неправильно. Трудно быстро вникнуть и вспомнить, что ты менял несколько месяцев назад.

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

#железо
​​В среде Windows, а точнее ещё даже DOS, была и есть очень популярная программа для тестирования работы диска MHDD. Думаю, если не все, то очень многие её знают. Во времена HDD это было лучшее средство проверить состояние диска, оценить скорость чтения и времени отклика каждого сектора.

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

Помимо проверки диска, она умеет делать аккуратные копии повреждённых дисков, а так же безвозвратно удалять данные на них, перезаписывая всё нулями.

Эту утилиту часто используют в составе различных Rescue CD на базе Linux. Но при желании, вы можете воспользоваться любым дистрибутивом и установить whdd туда самостоятельно. Например, в Debian это можно сделать следующим образом.

1️⃣ Ставим зависимости:
# apt install libncursesw5 libtinfo5 smartmontools
2️⃣ Качаем deb пакет под Xenial:
# wget https://launchpad.net/~eugenesan/+archive/ubuntu/ppa/+files/whdd_2.2+20160129-1~eugenesan~xenial1_amd64.deb
3️⃣ Устанавливаем:
# dpkg -i whdd_2.2+20160129-1~eugenesan~xenial1_amd64.deb

Так что можно взять любой LiveCD на базе deb пакетов и пользоваться. Также пакеты есть под AltLinux, ArchLinux, Gentoo, Slackware. Либо можно собрать из исходников самостоятельно. Проект open source.

Сайт / Исходники

#железо
Почему я не люблю работать с железом

Расскажу вам необычную историю из моей практики, которая случилась на днях. Есть у меня компания, с которой я работаю уже очень давно. У неё есть простенькая серверная и несколько своих серверов. К одному из них была подключена бюджетная дисковая полка фирмы HighPoint. Её купили ещё до меня. Лет 10 она честно отработала.

В какой-то момент после планового отключения электричества она не включилась. Человек на месте её покрутил, потряс, не включается. Разобрал, продул, снова включил - заработала. Тогда я сразу понял, что ей конец и форсировал покупку нового сервера. Его купили, оперативно там всё настроил, начали переносить нагрузку. Занимался другой человек. Всё самое основное перенесли.

Вскорости опять обесточивание. Полка не включается уже никак, ничего не помогает. Ничего критичного там уже нет, люди нормально работают. Но остались некоторые данные, которые хотелось бы забрать. Программист не успел перекинуть несколько второстепенных баз. А из бэкапов если доставать, то надо где-то MS SQL разворачивать, так как бэкапились его дампы.

Приехал я и начал шаманить. Стучал, тряс, разбирал, дул. Ничего не помогает. Не включается. Делаю ход конём. Беру сетевой удлинитель, подключаю не в УПС в серверной, а в розетку в соседней комнате. Нажимаю на кнопку - завелась. Просто чудо. Забрали всю инфу оттуда.

В следующий приезд надо было эту полку окончательно отключить и убрать, выключив предварительно сервер, к которому она подключена. Делаю всё очень аккуратно. Погасил сервер, долго не выключается. Переключаюсь на KVM на него, чтобы посмотреть, что на экране. Дождался выключения, возвращаюсь к себе за ноут.

⚡️Прилетают алерты. На соседнем сервере вылетел диск из рейда. I/O улетает в потолок, сервак фактически зависает. Виснет и SSH подключение, и с консоли логинишься, оболочка не загружается. Минут 10 подождал, понял, что дело труба. Судя по таймингам, проблемы спровоцировало нажатие кнопок на KVM. Я там ничего не дергал, железо не двигал. Просто подошёл и немного поработал за клавой с мышкой. Как это могло привести к тому, что начались сбои на HDD диске соседнего сервера, я хз. Какая-то статика что ли или ещё что-то. Даже идей нет.

С таким я сталкивался не раз. Очень не люблю работать с железом, особенно с серверами, которые работают 24/7 не в специализированном помещении. Если не соблюдается режим по температуре и влажности, то серверы или другое оборудование нередко не включается, после обесточивания.

Зависший сервер пришлось гасить принудительно. Скрестил пальцы, включаю. RAID10 живой, диск на месте, начался ребилд. Пока пишу заметку, rebuild на 75% закончен. На вид всё в порядке. Что это было - х.з.

Такие вот незапланированные приключения на ровном месте. Я уже давно не покупаю железо и не устраиваю серверные. Всё это наследство прошлого. Всегда стараюсь убедить арендовать железо в ЦОД, или своё на colocation поставить. Если всё аккуратно считать, то это не обязательно будет дороже. Но точно стабильнее и надёжнее.

Если у кого-то есть идеи, что могло спровоцировать проблемы с диском на соседнем сервере, поделитесь. Точно не было случайных ударов, пинков, каких-то сильных вибраций и т.д. Провода не задевал и не дёргал. Возможно соседний сервер выключился и каких-то колебаний добавил. Может в этом дело.

#железо
Ещё одну историю про железо расскажу. Как-то кучно было на прошлой неделе. В одном сервере для бэкапов вылетел диск из рейд массива. Он сначала помигал параметром SMART Current_Pending_Sector. То появлялся, то исчезал. В принципе, это не критично. Я видел много дисков, которые годами работают в массивах с этими метриками, и с ними в целом всё в порядке. Главное, чтобы всё стабильно было, не прыгало туда сюда в значениях.

Этот немного попрыгал и вывалился из массива. Он был в составе RAID6. Я для бэкапов обычно делаю его. Иногда RAID10 для увеличения производительности. Но только с RAID6 чувствую себя спокойно, так как он позволяет штатно пережить выход двух дисков из строя. Потеря одного совершенно некритична, нет нужды срочно менять диск, что не так для других уровней. RAID5 лично я вообще не использую и вам не советую.

Здесь рейд был создан на базе mdadm, так что замена прошла штатно. Я уже описывал её в заметке, которую сам постоянно использую:
https://t.me/srv_admin/723
Только в заметке диски SSD и меньше 2TB, поэтому там работает утилита sfdisk для копирования разметки. Для больших дисков она не подходит, надо использовать sgdisk. Скопировать таблицу разделов с /dev/sda на /dev/sdb:
# sgdisk -R /dev/sdb /dev/sda
Важно не перепутать диски. Таблица разделов склонируется вместе с GUID, что в данном случае нам не надо. Поэтому меняем GUID:
# sgdisk -G /dev/sdb

Если боитесь напортачить с автоматической разметкой нового диска, то сделайте это вручную с помощью parted. Посмотрите разметку существующего диска и создайте вручную такую же на новом.

Дальше всё то же самое по инструкции, что я привёл выше. Ребилд длился часов 14 в итоге. Всё прошло штатно. Если всё же надумаете когда-нибудь использовать RAID5, то делайте это с SSD дисками размером не больше 1-2 TB. Думаю там это может быть обоснованно.

Мониторинг SMART в случае с mdadm обычно делаю примерно так:
https://serveradmin.ru/monitoring-smart-v-zabbix/
Если рейд железный и сервер с bmc, то в зависимости от возможностей платформы. Некоторые передают параметры смарт, некоторые нет. Если контроллер данные не передаёт, то уже ничего не поделать. Приходится довольствоваться его метриками. Я поэтому и люблю mdadm. Диски и его статус легко обложить метриками, какими пожелаешь. И поведение более чем предсказуемое.

#железо