​​Netrunner 23 - манная каша со вкусом KDE

Не так давно мы рассматривали KDE Neon - дистрибутив от разработчиков KDE, которые предлагают пользователю интересное сочетание плавающих релизов KDE Plasma на базе стабильной платформы Ubuntu LTS, поэтому мы не могли пройти мимо другого аналогичного дистрибутива - Netrunner.

Их объединяет то, что также как и Neon, Netrunner находится под крылом Blue Systems GmbH - крупного спонсора KDE и бывшего главного спонсора Kubuntu.

Но впоследствии их пути разошлись и текущие выпуски Netrunner основаны на Debian.

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

https://interface31.ru/tech_it/2023/10/netrunner-23-mannaya-kasha-so-vkusom-kde.html

​​И снова про рекламу и донаты

Эта тема уже неоднократно поднималась на данном ресурсе и непременно будет подниматься вновь, так уж устроен человек.

Мы сейчас не будем бросаться в крайности, потому что всегда найдется категория читателей, которая в принципе не переносит рекламу и считает, что автор должен персонально им и вообще должен быть голодным.

Мы же будем говорить о читателе адекватном, который в принципе понимает, что количество и качество публикуемых материалов каким-то образом связано с количеством рекламы и где-то там соглашается с позицией: нет рекламы – нет контента.

Сегодня мы хотим показать другую сторону этой всей кухни – то, как создаются материалы и сколько времени это занимает.

Все материалы в канале делятся, собственно, на материалы канала и анонсы статей сайта. Обязательный план – минимум одна заметка в день.

Средняя техническая заметка для Telegram занимает 1-2 часа времени. Потому что нужно найти материал, проверить его, скомпоновать, упорядочить и придумать как уместить все это в 4000 символов.

Короткая заметка за жизнь, типа этой, также занимает не менее часа, потому что нужно сделать подводку, выразить основную мысль и сделать заключение, опять-таки в пределах тех самых 4000 символов.

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

Итого по нашему плану имеем 1,5 х 7 = 10,5 часов, полный рабочий день с переработкой. Это только на подготовку коротких заметок в канал.

Но основной контент мы по-прежнему размещаем на сайте. План – от 4 статей в месяц. А вот там все гораздо сложнее.

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

Развернуть систему, проверить все интересующие аспекты, сделать скриншоты – где-то еще часа два. Потому что проверить и посмотреть надо многое, но не все из этого попадет в статью.

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

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

Само написание обзора – час-полтора, затем вычитка, проверка орфографии, пунктуации, стилистики – еще полчаса.

Что имеем в сухом остатке? По минимуму 5,5-6 часов. На обзор, который читается за 5-10 минут. В этом, собственно, и смысл подобных материалов – коротко, но емко дать общую информацию. Полотно на десять экранов вниз с сотней картинок просто никто не будет читать.

Технические статьи занимают еще больше времени. Там тоже все начинается с этапа изучения уже написанного, тот же час.

Затем изучается документация, еще час-два. Потом стенд и кропотливая запись каждого действия.
Сделали? Разворачиваем стенд по новой и дословно воспроизводим записанное. Должны получить полное совпадение результата. В зависимости от сложности еще часа два -три.

Если документация скупа или что-то не получается, то начинается поиск и отладка, тоже часы, но мы их считать не будем.

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

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

Итог? Опять по минимуму 9-10 часов, на одну статью.

Итого в месяц получаем 40-50 часов работы с контентом, это полноценная рабочая неделя (пяти или шестидневная).

Можно ли тащить такой объем на энтузиазме? Или донатах, которых за прошлый год набралось целых шесть с хвостиком тысяч рублей? Совмещая это с основной работой, семьей, бытом? Занимаясь этим регулярно, через «лениво» и «не хочу»?

Как минимум семья не поймет, а потом и сам сядешь и подумаешь: «А на фига оно мне надо? Может лучше в лес или на рыбалку?»

​​SMART атрибуты NVMe дисков

Если SATA SSD имели набор атрибутов SMART унаследованный от жестких дисков, многие из которых были бесполезны и не отражали реального состояния устройства, то NVMe диски получили обновленный набор атрибутов, разработанный как раз с учетом специфики устройств.

Ниже будем указывать атрибуты в форме ID Наименование RU (Наименование EN)

🔹 01 Критические предупреждения (Critical Warning) – флаг, указывающий на критические состояния накопителя, не является статическим, может изменять состояние динамически, возможные значения:

▫️0x01 – доступное свободное пространство упало ниже порогового значения
▫️0x02 – температура вышла за пороговые значения (как вверх, так и вниз)
▫️0x03 - надежность подсистемы NVM ухудшилась из-за значительных проблем, связанных со средой передачи данных, включая ошибки, снижающие надежность подсистемы NVM
▫️0x04 – накопитель перешел в режим только чтения
▫️0x08 – устройство энергозависимой памяти (DRAM) вышло из строя

🔹 02 Температура всего устройства (Composite Temperature) – средняя температура накопителя в градусах Кельвина, для перевода в градусы Цельсия необходимо вычесть из значения 273.15. Рекомендации о порогах температур задаются именно для этого значения.

🔹 03 Доступно резервных блоков (Available Spare) – процент оставшихся резервных блоков, в норме 100 и это значение будет уменьшаться

🔹 04 Критический остаток резервных блоков (Available Spare Threshold) - при падении запаса ниже указанного значения для этого поля контроллером будет сформировано событие.

🔹 05 Процент износа (Percentage Used) - показывает процент износа устройства согласно указанного производителем ресурса, 100% обозначает полный износ, значение может превышать 100, максимальное значение 255.

🔹 06 Всего прочитано данных (Data Units Read) - количество прочитанных блоков по 512 байт, единица означает тысячу прочитанных блоков.

🔹 07 Всего записано данных (Data Units Written) - количество записанных блоков по 512 байт, единица означает тысячу записанных блоков.

🔹 08 Количество команд чтения (Host Read Commands) – количество команд чтения, выполненных контролером.

🔹 09 Количество команд записи (Host Write Commands) – количество команд записи, выполненных контроллером

🔹 10 Время занятости контроллера (Controller Busy Time) – время, которое контроллер обрабатывал команды ввода-вывода или когда в очереди находились запросы. Значение представлены в минутах.

🔹 11 Количество включений питания (Power Cycles) – счетчик включений накопителя

🔹 12 Количество отработанных часов (Power On Hours) – общее время работы накопителя в часах, учитывается также время нахождения в режимах энергосбережения

🔹 13 Небезопасных выключений (Unsafe Shutdowns) – количество выключений, когда питания накопителя было отключено прежде, чем он получил от системы уведомление о выключении питания

🔹 14 Количество неисправимых ошибок (Media and Data Integrity Errors) – счетчик неисправимых ошибок ECC, вычисления контрольных сумм CRC или несоответствия LBA

🔹 15 Записей об ошибках в журнал (Number of Error Information Log Entries) – количество записей об ошибках, произведенных в журнал контроллера

🔹 16 Время работы при высокой температуре (Warning Composite Temperature Time) – время, в минутах, которое накопитель работал с превышением порога температуры

🔹 17 Время работы при критической температуре (Critical Composite Temperature Time) - время, в минутах, которое накопитель работал с превышением критического порога температуры

🔹 18 Термодатчик 1 (Temperature Sensor 1) – первый сенсор температуры, точно узнать размещение сенсора можно только из описания диска, чаще всего контроллер.

🔹 19 Термодатчик 2 (Temperature Sensor 2) – второй сенсор температуры, точно узнать размещение сенсора можно только из описания диска, чаще всего NAND.

​​Стандартные systemd target в Linux

Говоря о юнитах systemd, нельзя не отметить такой тип юнита как таргет (цель, taget). Таргет – это особый тип юнита, который позволяет объединить несколько юнитов в группу и управлять ими как единым целым.

Вы можете создать собственный таргет из взаимозависимых служб и, скажем, одновременно перезапускать все относящиеся к веб-серверу службы: веб-север, СУБД, PHP и т.д.

Но об этом мы поговорим как-нибудь позже, а сегодня наше внимание займут стандартные таргеты.

Посмотреть список стандартных целей можно командой:

systemctl -–type=target

После чего мы увидим список всех активных таргетов, чтобы увидеть полный список используйте команду:

systemctl -–type=target -–all

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

After=network.target

Если вы используете сетевые файловые системы, такие как NFS или CIFS/SMB и ваша служба должна запуститься после того, как они будут смонтированы:

After=remote-fs.target

И не нужно ничего придумывать, systemd уже подумала за вас.

У некоторых целей может быть сразу несколько вариантов, например, существуют сразу три сетевых таргета:

▫️ network-pre.target
▫️ network.target
▫️ network-online.target

Цель network-pre.target представляет собой точку состояния системы перед запуском сетевых служб и может быть использована для запуска тех служб, которые обязательно должны быть активны на момент запуска сети, например, брандмауэр.

Данная цель должна использоваться как Before=network-pre.target или Wants=network-pre.target.

Собственно network.target обозначает состояние запуска всех сетевых служб системы и для прочих юнитов, которым нужна сеть мы должны использовать After=network.target, т.е. состояние после того, как все сетевые службы были запущены.

И, наконец, network-online.target – это точка состояния системы, когда все сетевые службы успешно и гарантированно запущены. Используется только с Wants= и After=, используется в основном для устаревших служб или сценариев, которые некорректно работают с After=network.target.

Отдельного разговора заслуживают Boot targets – цели загрузки, эти таргеты являются аналогами уровней запуска init. Существуют следующие загрузочные таргеты:

▫️ poweroff.target (runlevel 0) – выключение системы
▫️ rescue.target (runlevel 1) – режим восстановления системы
▫️ multi-user.target (runlevel3) – многопользовательский режим (консольный режим без графики)
▫️ graphical.target (runlevel 5) – режим графического окружения
▫️ reboot.target (runlevel 6) – перезагрузка системы

Также существует загрузочный таргет по умолчанию - default.target, который является символьной ссылкой на один из загрузочных таргетов и определяет в какой именно режим будет загружена система по умолчанию.

Узнать текущее состояние по умолчанию можно командой:

systemctl get-default

А установить новую цель загрузки можно командой:

 systemctl set-default graphical.target

При этом graphical.target имеет одну особенность, при отсутствии графики он запускается и работает аналогично multi-user.target и поэтому не следует удивляться, увидев его в системе без графической оболочки или в контейнере.

По-умолчанию graphical.target для систем без графического окружения используют Debian и Ubuntu.

Также мы можем переключаться между уровнями загрузки без перезагрузки системы при помощи команды isolate. Так если мы выполним в графической среде:

systemctl isolate multi-user.target

То все графические модули будут остановлены, и система перейдет в режим командной строки.

Ну и напоследок весьма злая шутка:

systemctl set-default reboot.target 👻👻👻

После чего можно принимать ставки как быстро коллега разберется в чем дело. Но такие шутки довольно вредны для здоровья. Минздрав предупреждает!

​​Linux – права файловой системы

Все знают, что Linux унаследовал и использует классическую систему прав UNIX, которая строится вокруг трех субъектов: владельца, группового владельца и остальных, каждый из которых имеет право на чтение – r, запись – w и исполнение – х.

Записываются права посимвольно слева на право: владелец – группа – прочие, для каждого указываются доступные права – rwx, отсутствующее право заменяется прочерком, например:

rw- r—- r—-

Обозначает право на запись и чтение для владельца и только чтение для группы и прочих.

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

Т.е. приведенный набор прав можно записать как:

110 100 100

Или в более привычной восьмеричной форме:

644

Да, несмотря на то что запись ведется привычными десятичными цифрами система указания прав использует восьмеричную систему.

Так чтобы понять, что значит тот или иной набор прав в цифрах – переводим его в двоичную форму и заменяем биты действиями:

755 -> 111 101 101 -> rwx r-x r-x

Т.е. полные права у владельца и чтение и исполнение для остальных.

Теперь перейдем от файлов к директориям, директория — это такой особый тип файла, который содержит записи о файлах, содержащихся в этой директории.

И права тут значат немного иное: r - право получения имен файлов в каталоге (но не их атрибутов), x - право получения доступа к файлам и их атрибутам, w - право манипулировать именами файлов, т.е. создавать, удалять, переименовывать.

Минимально разумный набор прав к директории r-x, полный rwx.

Поэтому обычно в Linux используются следующие права по умолчанию: 644 для файлов и 755 для директорий.

Т.е. владелец имеет права на запись и чтение файла, группа и остальные – только чтение, а также полный доступ к директории для владельца и только чтение для остальных.

Право на исполнение файлов по умолчанию не устанавливается.

Это – минимальный набор знаний, которые вы должны иметь о правах доступа к файловой системе Linux.

Но не все знают, что на самом деле права доступа это не три, а четыре октета, просто первый ноль часто пропускается и правильно будет не 777, а 0777. Что интересного содержит первый октет?

Там также трехбитовая запись, каждый бит в которой (слева-направо) означает:

SUID – SGID – stiky

sticky-бит – он же 001 или 1 – может быть установлен только для каталога, его установка для файлов игнорируется. В переводе stiky означает – липкий, что полностью соответствует его работе.

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

SGID – 010 или 2 - устанавливает группу владельца каталога для каждого создаваемого в нем файла, по умолчанию файлы создаются с группой создавшего его пользователя.

SUID – 100 или 4 – право запускать файл с правами его владельца, а не пользователя который его запустил. Широко используется для ряда системных утилит, таких как passwd. Ведь пользователь должен иметь право изменить сам себе пароль, но для этого необходимы права root, что легко решается через установку SUID.

В буквенной записи SUID и SGID заменяют x на s в правах пользователя или группы, установленный sticky-бит заменяет x на t в правах для остальных.

В восьмеричном виде записывается первым октетом. Например, комбинация stiky + SGID + стандартные права 755 может быть записана так:

011 111 101 101 -> 3755 –> rwx r-s r-t

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


Более подробно рекомендуем прочитать в наших статьях:

🔹 Linux - начинающим. Работаем с файловой системой. Теория

🔹 Linux - начинающим. Работаем с файловой системой. Практика

​​Мониторинг. Внешний и внутренний.

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

Система мониторинга внутри периметра является внутренней и рассчитана на классический сценарий: рядом с ней, внутри этого же периметра всегда есть сотрудник, который всегда может отреагировать и оценить ситуацию.

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

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

Что произошло? Упал интернет? Выключили электричество или выбило питающий стойку автомат? А может это просто Zabbix упал?

Чтобы иметь возможность получить ответы на эти вопросы и понадобится внешний мониторинг.

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

Поэтому нам нужна, может быть менее сложная, но полноценная система внешнего мониторинга с доступом во внутреннюю сеть. Это можно легко организовать при помощи VPN.

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

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

При этом важно мониторить также внешний адрес и доступность сервисов на нем. Так если VPN упал, но внешний адрес и порт доступны, то стоит проверить сам VPN-сервер или срок действия сертификатов к нему (как клиентских, так и серверных).

Мы чаще всего реализуем эту схему как Zabbix в качестве внутреннего мониторинга и The Dude на CHR в качестве внешнего. Эта связка позволяет не усложнять схему, все-таки Zabbix сложный и тяжелый продукт, но получать максимум актуальной информации, для проверки сетевой доступности и снятия ключевых показателей The Dude подходит достаточно неплохо.

А как решаете подобные задачи вы? Используете разделение мониторинга на внешний и внутренний?

​​Программные лицензии 1С – как узнать причину слета лицензии и быстро активировать ее заново

Про программные лицензии ходит много мифов, мол они сильно капризные, слетают на ровном месте и т.д. и т.п.

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

При отсутствии этой самой тонкой желтой книжки всегда можете обратиться к нашей статье:

▫️ Особенности применения программных лицензий 1С:Предприятие

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

В данном случае причиной слета лицензии было изменение дисковой конфигурации компьютера, что соответствует реальному положению дел.

Но не следует спешить активировать новую лицензию. Сначала внимательно изучите текущий список оборудования. В нашем случае в него затесались два внешних жестких диска. Их перед получением лицензии следует отключить.

Потому что добавлять в конфигурацию оборудование можно, удалять нельзя.

Кстати, после того как вы отключите внешние диски, то запустите 1С еще раз и снова посмотрите Журнал поиска ключа, чтобы четко понимать какие именно накопители будут влиять на текущую лицензию и уже после этого занимайтесь ее восстановлением.

Если у вас нет резервного ПИН-кода, то следует воспользоваться сервисами самообслуживания, либо написать письмо на адрес [email protected]. Письмо желательно писать с того адреса, на который зарегистрирована лицензия.

В нем в произвольной форме указываете номер поставки и просите выдать резервный пин-код.

Если пишите с другого адреса, то укажите также текущий пин-код и сведения о владельце лицензии.

Теперь о сервисах самообслуживания, это быстро и удобно, сейчас их четыре:

▫️ Восстановить данные о лицензии
▫️ Получить текущее состояние пин-кодов
▫️ Получить резервный пин-код
▫️ Получить лицензию из файла

Обратите внимание на новый, четвертый сервис, который позволяет получить данные лицензии из файла, что очень удобно если вы не знаете какая именно лицензия была активирована на данном устройстве.

​​Установка и запуск нескольких экземпляров сервера 1С:Предприятие на одном компьютере. Платформа Linux

Запуск нескольких экземпляров сервера на одном компьютере является штатной возможностью сервера 1С:Предприятие и позволяет использовать несколько платформ одновременно или разделить сервера на рабочие и тестовые.

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

Процесс установки дополнительных экземпляров сервера 1С:Предприятие на платформе Linux в целом несложен, однако официальная документация скупа и обрывочна, поэтому исправим данный пробел.

https://interface31.ru/tech_it/2023/10/ustanovka-i-zapusk-neskolkih-ekzemplyarov-servera-1spredpriyatie-na-odnom-kompyutere-platforma-linux.html

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

По Windows c задержкой в два дня, а по Linux в три… Интересно почему… Трудности перевода, не иначе.

И, оказывается, за рубежом есть ресурсы по 1С. Надо Борису Нуралиеву написать, он, походу, не в курсе.

А еще я несколько раз расстрелял товарища и написал ему всяких гадостей в личку, но это строго после того, как он меня разоблачил.

Но выяснилось, что сей пассажир жив и здоров, пришлось исправить это недоразумение 5 минут назад.

Я все понимаю, но подобное поведения для меня загадка. Зачем? Почему? Что он получил от этого?

Невеселые новости от Oracle Cloud.

При очередном входе система потребовала безальтернативно подключить MFA.

А это потребует либо дополнительных телодвижений от зарубежных контрагентов (которые могут быть вообще не в курса таких технических сложностей), либо самостоятельных телодвижений по обеспечению этой самой MFA.

Фактически это очень и очень сильно усложняет использование бесплатных VPS от Оracle, особенно с их любовью выключать сервера за "неактивность".

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

​​Ваш Zabbix напрасно поднимает панику, у нас еще много памяти

Не столь давно, после внедрения Zabbix один из заказчиков пожаловался, что Zabbix начал присылать сообщения о том, что недостаточно оперативной памяти, но на самом деле памяти еще достаточно.

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

Так что, Zabbix неправильно считает память или напрасно нагнетает панику? Вовсе нет, давайте разбираться.

Давайте возьмем еще один хост с Proxmox и посмотрим, судя по графику у нас в запасе еще около 10 ГБ свободной памяти, неплохо.

Но если запустим команду:

free -h

То картина существенно изменится, как оказывается свободной памяти у нас всего 2,2 ГБ, а доступной 6,3 ГБ.

При этом у нас 3,8 ГБ разделяемой памяти и 8,3 ГБ буферной/кеша.

Внимательный читатель, вооружившись калькулятором, скажет: стоп, что-то не сходятся у вас доходы с расходами.

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

Т.е. если мы сложим вместе used + shared + buff/cache то полученное значение не будет соответствовать total – free.

Теперь давайте разберемся что значит каждый вид памяти:

▫️ used – использованная, память которая напрямую используется рабочими процессами в системе

▫️ free – свободная, это память которая не используется ни одним процессом и может быть выделена незамедлительно.

▫️ shared – разделяемая, используется для ускорения межпроцессного взаимодействия, что позволяет исключить передачу информации между процессами через ядро.

▫️ buff/cache – буфер ввода-вывода и кеш VFS (виртуальной файловой системы), играет очень важную роль, так как позволяет разместить в памяти наиболее часто запрашиваемые данные, системные библиотеки и т.п.

▫️ available – доступная, память которая может быть выделена процессу без обращения к пространствам подкачки.

И именно доступная (available) память наиболее точно отображает положение дел с наличием памяти в системе, и именно она используется в триггерах Zabbix.

Proxmox же просто показывает нам used, а остальное помечает свободным. Исходя из этого у нас имеется 10 ГБ «свободной» памяти, на самом деле нам доступно только 6 ГБ, где остальное?

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

Поэтому разные участки кеша и буферов тоже имеют собственный вес и этот вес может давать им преимущество над запущенными процессами.

В некоторых случаях система может решить, что освобождать кеш дорого и дешевле будет отправить некоторые страницы памяти в подкачку или вовсе позвать OOM Killer и пристрелить какой-нибудь жирный процесс. 🔫🔫🔫

Собственно, это мы и видим в данном случае - 4.7 ГБ памяти содержит «дорогой» кеш и не сможет быть быстро освобождена. Точнее, система будет держаться за этот кеш до последнего, потому что после его очистки плохо станет всем, а пристрелят или отправят в своп только некоторых.

Поэтому в данном случае Zabbix прав, с чем наши заказчики скоро столкнулись, когда OOM Killer начал выключать одну из малоактивных виртуалок.

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

Почему у жесткого диска указан TRIM и что это обозначает?

​​Итак, откуда у жесткого диска команда TRIM

К сожалению, правильный ответ на вопрос дали только 23% читателей. И это действительно диск с SMR, а наличие поддержки TRIM у жесткого диска – 100% признак черепицы.

Коротко вспомним, что SMR диск, как и SSD, имеет большой штраф на запись, потому что мы не можем изменить один кластер, не перезаписав всю ленту. Поэтому запись всегда идет в свободные ленты или медиакеш с обычной технологией записи.

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

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

Более подробно об этом в нашей статье: Что такое черепичная магнитная запись SMR и стоит ли ее избегать?

​​Как внедрять изменения и не остаться у разбитого корыта

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

Зачем это нужно? А затем, чтобы если что-то пойдет не так вы смогли и успели вернуть инфраструктуру к первоначальному состоянию. И на любом этапе, при любой ситуации понимали сколько времени у вас есть на решение проблемы и когда можно попытаться ее решить, а когда пора возвращать все как было.

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

Поэтому мы делаем так: планируем и разбиваем на части внедрение, выполняем замеры времени и составляем временной график. Это позволяет оценить сколько времени нам понадобится на то, чтобы все сделать как надо.

Затем берем и планируем обратный процесс: т.е. полный откат всех внесенных изменений от конечного состояния к начальному. И составляем второй временной график. Это сразу поможет понять сколько времени понадобится чтобы вернуть все как было, даже если откатываться придется с самого-самого последнего этапа.

И только теперь можно говорить о необходимом размере технологического окна, которое должно позволять выполнить процесс как внедрения, так отката после этого.

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

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

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

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

Это может усложнить и удлинить процесс, но позволит реализовать его частями. Теперь, если что-то пошло не так – возвращаемся к очередной точке фиксации.

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

Если проводить аналогию, то внедрение единым разом – это спринт, бег на короткие дистанции, где мы резко срываемся с места и изо всех сил несемся к финишу, только вот на самых последних метрах можно бодро рухнуть лицом в асфальт, наступив на внезапно развязавшийся шнурок.

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

А каких методов планирования придерживаетесь вы? Спринт или спортивная ходьба? Планируете ли откаты?