немного программист, немного админ
Что можно сказать про оповещения о проблемах в графане? Ну разве что то, что они есть. Не могу сказать, что они мне действительно нравились, но они были недостаточно плохими для того, чтобы заняться их кастомизацией.
Но после обновления графаны до девятой версии всё изменилось. Я обнаружил, что сообщения превратились в малочитаемые простыни (на КПДВ слева).
Решил сократить сообщения и повысить их читаемость, что у меня получилось можете увидеть на той же картинке справа.
Вся полезная информация уместилась в одной табличке:
Как видим, cредний показатель выхода из строя в год (Annualized Failure Rate) превысил 1%, что примерно соответствует показателям классических жёстких дисков.
Ценность отчёта несколько снижает то, что используются достаточно экзотические (во всяком случае, на мой взгляд) модели накопителей. Впрочем, MTFDDAV240TCB — это серверный накопитель Micron 5100 PRO, у меня несколько накопителей этой серии работают, нареканий нет; да и первая строка в таблице — MX500 — достаточно распространённый накопитель пользовательского класса этой же фирмы, заслуживший неплохую репутацию; с чем связан высокий процент выхода накопителей Micron/Crucial из строя у Backblaze — непонятно.
Эта мини-статья родилась как ответ на статью Упрощаем эмуляцию X86 с помощью Live CD, в которой для запуска старых 32-битных приложений на 64-битных дистрибутивах Linux предлагалось использовать QEMU + Live CD — по моему мнению «из пушки по воробьям». Опишу своё решение на chroot + debootstrap.
Опубликован новый вариант атаки "HTTP Request Smuggling", позволяющей «вклиниться» в запросы других пользователей при использовании HTTP/1.1 persistent connection между прокси (фронтендом) и бэкендом.
Продемонстрирована возможность кражи кук, авторизационных данных, подстановки стороннего js-кода и т. п.; атаке оказались подвержены Netflix, Atlassian, AWS, F5 BIG-IP…
На Хабре в последнее время появилась серия холиварных статей:
Семь причин, почему Линукс
Главная причина, почему не Linux (от автора предыдущей статьи)
Главная причина, почему все-таки Linux
В этих статьях и комментариях к ним много говорили о коммунизме, цельности системы, свободе, юзабилити, домохозяйках, глюках… Да о чём угодно, но самое главное для меня если и упоминалось, то только вскользь.
Так что я решил написать свою статью, она будет совсем небольшой не очень большой, не пугайтесь.
Несомненно, вопрос, вынесенный в заголовок статьи, не нов, поднимался не раз и по нему достигнут консенсус «не особо нужна, и даже может быть вредна».
Однако недавнее обсуждение в комментариях заставило меня ещё раз задуматься.
Со временем любой SSD всё равно сильно фрагментируется (внутри, в FTL)… Свежезаписанный SSD при линейном чтении даст высокую скорость, а уже поработавший — гораздо ниже, потому что линейными оно будет только для вас.
Да, обычно такое не должно происходить: или мы пишем «понемногу» в мелкие файлы/небольшие блоки метаинформации ФС (скорость линейного чтения которых нас не особо волнует), либо же мы пишем «помногу» в большие файлы и всё будет хорошо. Бывает и дозапись мелкими блоками в большие файлы — логи, например, однако они относительно короткоживущие и особой проблемы я тут не вижу.
Но легко представился вполне реальный сценарий, при котором всё-таки внутренняя фрагментация SSD может проявиться: файл базы данных, в который идёт достаточно активная случайная запись. Со временем он (оставаясь нефрагментированным на уровне операционной системы) окажется физически очень даже фрагментированным, что может существенно снизить скорость seq scan, резервного копирования и т.п.
Для проверки я написал скрипт и провёл тесты.
Спойлер: проблема присутствует (существенно влияет на производительность) только на одной из попавшихся под руки моделей (и та позиционируется производителем не как datacenter, а как десктопная/ноутбучная).
Есть торговые автоматы собственной разработки. Внутри Raspberry Pi и немного обвязки на отдельной плате. Подключены монетоприёмник, купюроприёмник, банковский терминал… Управляет всем самописная программа. Вся история работы пишется в журнал на флешке (MicroSD), который потом передаётся через интернет (с помощью USB-модема) на сервер, там складывается в БД. Информация о продажах загружается в 1с, также есть простенький веб-интерфейс для мониторинга и т.п.
То есть журнал жизненно необходим — для учёта (там выручка, продажи и т.д.), мониторинга (всевозможные сбои и другие форс-мажорные обстоятельства); это, можно сказать, вся информация, которая у нас об этом автомате.
Флешки показывают себя как очень ненадёжные устройства. Они с завидной регулярностью выходят из строя. Это приводит как к простоям автоматов, так и (если по каким-то причинам журнал не мог быть передан онлайн) к потерям данных.
Это уже не первый опыт использования флешек, до этого был другой проект с более, чем сотней устройств, где журнал хранился на USB-флешках, там тоже были проблемы с надёжностью, временами число вышедших из строя за месяц исчислялось десятками. Пробовали разные флешки, в том числе и брендовые на SLC памяти, да некоторые модели надёжнее других, но замена флешек не решила проблему кардинально.