ServerAdmin.ru

Авторская информация о системном администрировании.

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

Второй канал: @srv_admin_live
Сайт: serveradmin.ru

View in Telegram

Recent Posts

🔝 ТОП постов за прошедший месяц. Все самые популярные публикации по месяцам можно почитать со соответствующему хэштэгу #топ. Отдельно можно посмотреть ТОП за прошлый год.

Пользуясь случаем, хочу попросить проголосовать за мой канал, так как это открывает некоторые дополнительные возможности по настройке: https://t.me/boost/srv_admin.

Сегодня ТОПчик выпал на пятницу, так что обзор интересных роликов с youtube выйдет завтра. Там есть полезные видео, так что не захотел его пропускать.

📌 Больше всего пересылок:
◽️Топ-10 артефактов Linux для расследования инцидентов (980)
◽️Терминальный сервер на базе Windows 10,11 (806)
◽️Система управления инфраструктурой OpenRPort (686)

📌 Больше всего комментариев:
◽️Как найти работу в ИТ после 45 лет? (288)
◽️Тайная жизнь современных ОС (231)
◽️Новость с исключением русских мэйнтейнеров (208)

📌 Больше всего реакций:
◽️Шпаргалка по tcpdump (351)
◽️Терминальный сервер на базе Windows 10,11 (318)
◽️Настройка default_server в Nginx (279)

📌 Больше всего просмотров:
◽️Топ-10 артефактов Linux для расследования инцидентов (11612)
◽️Бесплатные курсы Yandex Cloud (11265)
◽️Настройка VM в Proxmox с помощью Terraform (10449)

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

#топ
Ищете удобную и надежную IT-инфраструктуру для вашего проекта?
 
Размещайте собственный сайт, запускайте приложения, обучайте нейросети или загружайте огромное количество данных в одном окне браузера. Все эти и многие другие задачи можно решить в Selectel.
Selectel — один из ведущих провайдеров IT-инфраструктуры и облаков. Выделенные серверы, облако собственной разработки, сервисы информационной безопасности и еще более 50 продуктов — все настраивается и масштабируется из единой панели управления.
 
Что вы получите, выбрав Selectel:
 
— Удобство. Чтобы начать работу с сервером, достаточно выбрать нужные характеристики и в пару кликов запустить его.
— Масштабируемость. Быстрое развертывание новых мощностей при увеличении нагрузки на ваш сайт или приложение.
— Безопасность. Все дата-центры Selectel соответствуют требованиям 152-ФЗ, а также вам будет доступна бесплатная защита от DDoS-атак.
 
Регистрируйтесь в панели управления и разверните инфраструктуру вашего проекта в несколько кликов.
⚠️ На прошлой неделе подписчик поделился жуткой историей с шифровальщиком. Вообще, они все жуткие, но если бэкапы тоже зашифрованы, то это вообще тушите свет. А там такая история, что в городе пострадало много организаций по одной и той же схеме. Кто-то точечно и системно поработал.

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

Я всегда так делаю. Мысленно представляю, что завтра у меня недоступны некоторые или все сервера. Какой план на этот счёт? Чтобы не было всех серверов, сразу отсекаем по максимуму доступ к бэкапам. Я уже много раз писал и рассказывал:

❗️Бэкап-сервера должны сами ходить за данными. У серверов с данными не должно быть полного доступа к бэкапам.

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

Подробно про бэкапы я не так давно рассказывал в отдельных заметках:

⇨ Два принципиально разных подхода к созданию бэкапов
⇨ Проверка бэкапов

По моему мнению надёжные бэкапы - основа спокойной жизни админа. Дальше уже реализуем другие организационные меры:

🔴Закрываем доступ из интернета к внутренним сервисам. По минимуму выставляем их наружу. Не надо без крайней нужды пробрасывать, к примеру, rdp порт. Меня разок через него шифровали. И хотя чаще всего от этого не будет проблем, но раз в 10 лет обязательно найдётся какая-нибудь уязвимость, которая в обход аутентификации позволит выполнить вредоносный код на сервере.

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

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

🔴Не оставляйте свои рабочие места включенными 24/7. Я сам такое практиковал раньше. Удобно, когда рабочий комп всегда включен и к нему можно удалённо подключиться. Сейчас даже дома не оставляю свой рабочий ноут включённым, когда ухожу из дома или надолго отхожу от рабочего места. Выключаю ноут, когда надо - включаю. RDP тоже на нём отключен.

🔴 Не подключайте к своему рабочему компу бэкапы, не настраивайте беспарольные доступы куда-либо, не назначайте лишние права своей учётке в инфраструктуре. Нередко на компы админов злоумышленники заходят руками и смотрят, к чему есть доступ. Если у вас пароли в KeePass, а файл закрыт надёжным паролем, уже с вашего компа ничего не сделать. Пароли в Winbox и Xshell у меня зашифрованы мастер-паролем, на ключе для ssh тоже пароль.

Если сами страдали от шифровальщиков, расскажите, как они заходили к вам и к каким последствиям это приводило. Ко мне один раз заходили через rdp, один раз через письмо у пользователя. У него, кстати, антивирус не помог. Не распознал шифровальщика. Всё, к чему у пользователя был доступ, зашифровали.

#security
Менеджеры удалённых подключений - очень консервативная тема. Я и по себе сужу, потому что много лет пользуюсь одним и тем же. И по своим знакомым, у которых тоже обычно всё один раз настроено, что и используется много лет.

Для ssh у меня Xshell 5, бесплатная версия от 2017 года. А для rdp - mRemoteNG. Обе программы откровенно устарели, пробовал другие, но не могу сказать, что они были сильно лучше, поэтому окончательно так и не перешёл на что-то другое. Привычки к комбинациям клавиш Xshell меня жёстко держат. Хотя ставил и пользовался XPipe, но некоторые баги и неудобства там так и не исправили. В итоге забросил её. Но идея обёртки над Windows Terminal мне нравится, так как нравится этот терминал. В нём комфортно работать. Он и выглядит симпатично, и работать в нём удобно.

По рекомендации подписчика попробовал SSH/SFTP клиент Snowflake. Поначалу смутило, что он больше не развивается. С другой стороны посмотрел свой Xshell и перестал смущаться. Развивать в подобных программах особо нечего, если реализована базовая функциональность. Программа бесплатная, код открыт. Установил и попробовал. В целом, она мне понравилась. В ней необычный набор возможностей, которые подойдут и будут удобны тем, кто не является большим специалистом по Linux, у кого немного серверов, кто любит править файлы не в консоли. Я, когда только начинал изучать Unix, подключался к серверу по ftp и редактировал текстовые конфиги в Total Commander.

Понравилось в Snowflake:

◽️Удобный файловый менеджер с функциональным поиском файлов. Открывается одновременно с ssh сессией. Такое ощущение, что изначально был разработан именно он, а потом добавилось всё остальное.
◽️Анализ использования диска. Функциональность похожа на ncdu, только запускается в клиенте, в отдельной вкладке.
◽️Список служб systemd с возможностью управления: остановить, запустить, отключить автозапуск и т.д.
◽️Сниппеты с сохранёнными консольными командами, которые можно запускать в ssh сессиях. Можно сохранить что-то типа такого:
netstat -ntu | grep -vE "(Address|servers|127.0.0.1)" | awk '{print $5}' | cut -d ':' -f 1 | sort -n | uniq -c | sort -n
Это подсчёт сетевых подключений с каждого ip. И запускать в любом терминале, выбирая из списка сохранённых команд.
◽️Возможность работать в файловом менеджере и редакторе с sudo. Это то, чего лично мне не хватает в WinSCP. Ему нужен сразу пользователь с правами. Он не умеет делать sudo для доступа к файлу.

Минусы:

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

Ещё он умеет запускать графики с основными системными ресурсами. Для меня это ни плюс, ни минус, просто есть. Мне лично не нужны такие возможности.

В целом, менеджер выглядит самобытно и интересно. Есть версия и под Windows, и под Linux. Рекомендую сразу в настройках поменять тему терминала со светлой на тёмную. Мне вообще непривычен светлый терминал. Попробуйте, может вам зайдёт. От терминального менеджера много не требуется. Главное, чтобы удобно лично тебе было.

Исходники / Обзор от RedOS / ▶️Видеообзор

#менеджеры_подключений
Хотели бы присоединиться к проекту, который приносит пользу миллионам пользователей? 🚀

В Авито актуальна вакансия в команду, которая занимается разработкой продукта по управлению виртуальной инфраструктурой:

1️⃣SRE инженер в команду Dev

Также в поиске инженера команда инфраструктуры, которая обеспечивает весь фундамент Авито (от серверов до внутреннего облака):

2️⃣Системный инженер HPC кластеров

А ещё есть вакансия в команде, которая занимается развитием и администрированием систем, повышающих безопасность компании, на основе Infrastructure as Code подхода:

3️⃣DevOps Engineer

Вас будут ждать:

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

Скорее откликайтесь!
За что больше всего люблю дистрибутив Debian, так это за его консерватизм. Много лет назад я написал статью на сайте:

Как настроить сетевые параметры в Debian

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

Собрался с силами и переработал статью, актуализировал. Перенёс все настройки на ip, замерив ifconfig и route. Давно серьёзно не занимался сайтом и контентом нём. Это забирает очень много времени. Нет возможности его выделять. Одна переработка заняла целый день. А если писать с нуля, то нужно ещё больше времени. Для того, чтобы подобная статья вышла в топ поисковиков, приходится работать с SEO, надо это знать. Из-за этого текст выглядит немного косоязычно. Но если этого не сделать, то текст заберут другие сайты, добавят SEO и статья от них уйдёт в ТОП. Так что лучше самому сразу сделать так, как надо.

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

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

◽️статические и динамические настройки ip адресов
◽️dns и hostname
◽️статические маршруты
◽️vlan
◽️отключение ipv6
◽️несколько адресов на одном интерфейсе

Узнал для себя некоторые новые вещи, на которые раньше не обращал внимание. Например, 2 типа активации сетевого интерфейса в /etc/network/interfaces:

▪️auto - интерфейс активируется при загрузке системы. Это подходящая настройка для статичного сетевого адаптера.
▪️allow-hotplug - интерфейс поднимается, когда подсистема udev обнаружит его. Это произойдёт и при загрузке системы, как в случае с auto, если сетевая карта будет подключена, и в случае подключения, отключения устройства. Например, если это usb сетевая карта или VPN туннель. Настройка больше подходит для динамических сетевых интерфейсов.

Ещё интересный момент. Если сбросить dhcp lease через консоль соответствующей командой:

# dhclient -r

То вы не только потеряете все полученные по dhcp настройки, но и статические адреса. Соответственно, вас отключает по ssh. Для меня это было сюрпризом. Такие вещи надо делать осторожно, имея доступ к консоли сервера напрямую.

#debian#network
Завершу тему с тестированием дисков информацией про кэширование в Proxmox VE. У него стандартный набор режимов, которые будут плюс-минус такие же и у рейд контроллеров. Сделаю в формате небольшой шпаргалки, а подробности с картинками есть в документации.

▪️None - режим по умолчанию. Если не хочется разбираться в этой теме, то можете оставлять этот режим и не заморачиваться. Он универсален для сервера общего назначения. Гипервизор никак не вмешивается в операции ввода-вывода. VM работает как-будто напрямую с хранилищем. Может отправлять данные в очередь хранилища на запись, либо дожидаться реальной записи.

▪️Writethrough - операции записи VM идут напрямую в хранилище, как и в режиме none. В этом режиме добавляется кэш гипервизора, который используется только для чтения. То есть мы получаем такую же надёжность записи, как и в none, но добавляется кэш на операции чтения. Если у вас сервер отдаёт много статики, то можете включить этот режим.

Железный рейд контроллер без батарейки обычно работает в таком же режиме.

▪️Directsync - кэширование гипервизора не используется вообще, как в none. Отличие этого режима в том, что мы заставляем VM работать с хранилищем только в режиме реальной записи с подтверждением. То есть виртуалка не использует очередь хранилища. Затрудняюсь придумать пример, где это реально надо. Никогда не использовал этот режим.

▪️Writeback - операции записи и чтения кэшируются гипервизором. VM будет получать подтверждения о записи, когда данные попадут в кэш гипервизора, а не хранилища. Это существенно увеличивает быстродействие дисков VM. Особенно если у гипервизора много свободной оперативной памяти для кэша. Если будет сбой сервера и данные из кэша хоста не успеют записаться, то мы получим потерю информации с разными последствиями для системы. Она скорее всего выживет, но если там работала СУБД, то база может оказаться битой.

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

▪️Writeback (unsafe) - то же самое, что Writeback, но с одним отличием. В режиме Writeback гостевая VM может отправить команду на запись данных в реальное хранилище, а не кэш гипервизора. У неё есть возможность принудительно поддерживать консистентность данных. В режиме unsafe команда на запись в хранилище всё равно перехватывается кэшем хоста. Это обеспечивает максимальное быстродействие VM и максимальную ненадёжность сохранности данных. Я этот режим использую на тестовых гипервизорах.

❗️Все эти режимы имеют смысл при использовании типа диска RAW. Например, при использовании LVM Storage или обычных raw файлов с хранением в директории хоста. Во всех остальных случаях (qcow2, zfs) кэширование лучше не трогать и оставлять его в режиме none. Также следует аккуратно менять режимы при использовании raid контроллера с батарейкой, встроенной памятью и включенным кэшированием. Будет неочевидно, какой режим выбрать - тот или иной кэш гипервизора или самого контроллера, либо их обоих. Надо тестировать на своей нагрузке. Я в таких случаях оставляю кэш контроллера и не использую кэш гипервизора. Просто интуитивно так делаю. Как лучше, я не знаю.

🔹Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#proxmox#disk
Открытый практикум Linux by Rebrain: Редактор vi

Для знакомства с нами после регистрации мы отправим вам запись практикума «DevOps by Rebrain». Вы сможете найти её в ответном письме!

👉Регистрация

Время проведения:


6 ноября (среда) в 20:00 по МСК

Программа практикума:

▫️Узнаем, что такое редактор vi
▪️Поговорим о том, почему vi до сих пор популярен
▫️Практикуемся в работе с vi: основные команды и режимы работы

Кто ведёт?

Андрей Буранов — системный администратор в департаменте VK Play. 10+ лет опыта работы с ОС Linux. 8+ лет опыта преподавания. Входит в топ-3 лучших преподавателей образовательных порталов.

Бесплатные практикумы по DevOps, Linux, Networks и Golang от REBRAIN каждую неделю. Подключайтесь!

Реклама. ООО "РЕБРЕИН". ИНН 7727409582 erid: 2Vtzqv5D5yJ
Пока была возможность, решил проверить, какой штраф на дисковые операции накладывает виртуализация в Proxmox. В моей работе чаще всего именно дисковая подсистема является узким местом серверов. CPU обычно хватает, память сейчас недорога и легко расширяется. С дисками проблем больше всего.

Взял тестовый сервер Proxmox, в котором есть железный RAID контроллер без кэша и собранный RAID10 из 4-х HDD. Воткнул туда дополнительно обычный SSD AMD Radeon R5 R5SL480G 480ГБ. RAID10 подключил как обычный LVM storage, а SSD как LVM-Thin.

Нарезал там LV для хоста:

# lvcreate -V 10G -n test_ssd --thinpool SSD-RADEON/SSD-RADEON
# lvcreate -L 10G -n test_raid10 raid10

Сделал фс ext4 и смонтировал:

# mkfs.ext4 /dev/SSD-RADEON/test_ssd
# mkfs.ext4 /dev/raid10/test_raid10
# mount /dev/SSD-RADEON/test_ssd /mnt/SSD-RADEON
# mount /dev/raid10/test_raid10 /mnt/raid10

Прогнал серию из 10-ти тестов для каждого хранилища с помощью dd:

# dd if=/dev/zero of=/mnt/raid10/tempfile bs=1M count=2000 oflag=direct
# dd if=/dev/zero of=/mnt/SSD-RADEON/tempfile bs=1M count=2000 oflag=direct

Далее взял fio и прогнал тесты с его помощью:

Линейное чтение: 
# fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=1M -iodepth=32 -rw=read -runtime=30 -filename=/dev/raid10/test_raid10

Линейная запись: 
# fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=1M -iodepth=32 -rw=write -runtime=30 -filename=/dev/raid10/test_raid10

Пиковые IOPS случайной записи: 
# fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 -rw=randwrite -runtime=30 -filename=/dev/raid10/test_raid10

Так для обоих дисков. С dd сделал по 10 тестов, с fio по 5. Потом создал VM на Debian 12, создал для неё такие же диски, выбрав параметры:

▪️Device: SCSI
▪️Cache: Default (No cache)
▪️IO thread: yes
▪️Async IO: Default (io_uring)

Настройки все по умолчанию. И там выполнил точно такие же тесты. Свёл всё в одну таблицу. Я тут приводить точные цифры тестов не буду, так как они не имеют принципиального значения. Цифры можете сами посмотреть. Перейду сразу к выводам.

Разброс в производительности не более 9%. А если точно, то разница между хостом и VM только в одном тесте на запись была 9%, в остальных случаях 2-6%. Немного удивило то, что в паре тестов в VM результаты были выше на 2%, чем на хосте. Я несколько раз перепроверял, но ситуация воспроизводилась снова. Не знаю, с чем это может быть связано.

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

#proxmox#disk#perfomance
Тема тестирования производительности диска непростая. Если есть время и чёткая задача, то с помощью fio и продолжительного времени на тесты, можно добиться стабильного результата. А если хочется быстро оценить работу диска и сравнить результат, то возникают вопросы даже с самым простым тестом на последовательную запись.

Я попытался немного разобраться с этой темой и сделал ряд тестов в виртуальных машинах. Основные сложности тут следующие:

1️⃣ Если просто писать данные на диск с уровня операционной системы Linux, то она будет их кэшировать, пока у неё достаточно оперативной памяти для этого. Если не учитывать этот момент, то результаты будут разными в зависимости от объёма оперативной памяти и размера записываемых данных.

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

3️⃣ Если используется аппаратный рейд контроллер, то там есть свой слой кэширования, плюс запись в несколько потоков может идти быстрее, чем в один.

На практике это выглядит так. Берём виртуальную машину на Proxmox с 1G оперативной памяти и виртуальным диском без кэширования. Пробуем тесты на запись с помощью dd и разных флагов:

# dd if=/dev/zero of=/tempfile bs=1M count=512
259 MB/s

# dd if=/dev/zero of=/tempfile bs=1M count=2000
247 MB/s

# dd if=/dev/zero of=/tempfile bs=1M count=2000 oflag=direct
240 MB/s

# dd if=/dev/zero of=/tempfile bs=1M count=2000 oflag=dsync
123 MB/s

# dd if=/dev/zero of=/tempfile bs=1M count=2000 oflag=sync
123 MB/s

Используются флаги:

▪️direct - прямая запись в обход файлового кэша и синхронизации
▪️dsync - запись данных с синхронизацией каждого блока, то есть ждём подтверждение диска об успешной записи
▪️sync - запись данных и метаданных с синхронизацией

Результаты меня удивили. Я всегда был уверен, что запись dd по умолчанию будет вестись в кэш ОС, если хватает оперативной памяти. Я провёл много тестов на разных виртуалках, в разных гипервизорах, с разным количеством памяти в VM. И везде запись нулей из /dev/zero на диск в кэш не попадала. Из-за большого количества тестов глаз замылился, и я не мог понять, в чём причина. Подумал уже, что по дефолту dd работает с флагом direct, но это не так.

Причина вот в чём. Если файл /tempfile уже существует, то запись ведётся напрямую, а если отсутствует и оперативы достаточно, то в кэш. Проверяем:

# dd if=/dev/zero of=/tempfile bs=1M count=200
231 MB/s
# rm /tempfile
# dd if=/dev/zero of=/tempfile bs=1M count=200
635 MB/s

Если взять ещё меньше файл, то скорость будет ещё больше:

# rm /tempfile
# dd if=/dev/zero of=/tempfile bs=1M count=100
1.6 GB/s

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

# dd if=/tempfile of=/tempfile2 bs=1M count=128
910 MB/s

Всё было записано в кэш. Скорость диска мы вообще не увидели. Для тестирования линейной скорости записи на диск обязательно используйте флаг direct или sync. Значения вы получите разные в зависимости от флага, но они точно будут без использования кэша ОС.

А теперь я включу кэширование диска (Write back) на уровне гипервизора и выполню тесты с direct:

# dd if=/dev/zero of=/tempfile bs=1M count=2000 oflag=direct
1.0 GB/s

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

Интересная тема. Пару часов проковырялся с тестами, документацией, статьями. Забыл упомянуть, что погонял тесты с помощью sysbench, используя те же размеры блока и их количества. Результаты полностью совпадают с dd.

❗️Если при тестах диска вы видите очень большой разброс в значениях, у вас 100% где-то что-то залетает в кэш. Я не раз слышал от знакомых и читателей замечания по этому поводу. Люди получают сильно разные результаты тестов и не понимают, как их интерпретировать. Могут из-за этого ошибочно посчитать одно хранилище или формат диска быстрее другого.

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

В тренажере вы разработаете собственный проект "Key-value in-memory distributed storage with cluster autoscaling and load balancing". Это сложная, но интересная задача, которая направлена на изучение принципов распределенных систем, автомасштабирования и балансировки нагрузки. Реализация такого проекта позволит вам более глубоко понять архитектуру современных распределенных систем и получить практические навыки.

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

🔸Что ждет в уроке?
Basic Networking – изучите основные принципы сетевого взаимодействия, работа с протоколами и настройка сетевых соединений

- Распределенные системы
- Сетевая Модель OSI
- Протоколы Транспортного Уровня
- Погружение в TCP
- TCP сокеты в Python - базовое взаимодействие
- TCP сокеты в Python - надежность и многозадачность

Выполните практическое задание по Basic Networking и Broadcast_p2p networks и тестирование на закрепление материала

➡️ Регистрация на демо-доступ

Реклама, ООО "Инженеркатех", ИНН 9715483673.
Прочитал очень интересную техническую статью на хабре, в которой много просто любопытных и прикладных моментов. Зафиксирую некоторые их них в заметке для тех, кто не захочет читать весь материал. Он объёмный.

Как небольшой «тюнинг» Talos Linux увеличил производительность NVMe SSD в 2.5 раза

1️⃣ Кто-то заезжает в облака, кто-то выезжает. Автор построил Kubernetes кластер на Bare Metal, снизив затраты по сравнению с Google Cloud в 4 раза, увеличив производительность в 4 раза! Так что не стоит полностью забывать железо и жить в облачных абстракциях. В каких-то случаях стоит спускаться на землю и не терять навык работы на ней.

2️⃣ Очень объёмный и насыщенный материал по тестированию дисковой подсистемы с конкретными примерами для fio. Если не хочется сильно вникать, то можно сразу брать готовые команды для линейного чтения, линейной записи, задержки случайного чтения и т.д. Там для всех популярных метрик есть примеры.

3️⃣ Автор собрал свой Docker контейнер, который выполнят весь набор тестов и выводит результат в формате CSV для удобного экспорта в табличку с графиками.

# docker run -it --rm --entrypoint /run.sh --privileged maxpain/fio:latest /dev/nvme0n1

❗️Тест fio с записью на диск деструктивный. Нельзя запускать этот тест на диске с данными. Они будут уничтожены. Это для чистых блочных устройств. Я попробовал эти тесты. Удобно сделано. Рекомендую забрать к себе. Там всё самое интересное в скрипте /run.sh. Можно сохранить к себе на память только его:

# docker create --name fio maxpain/fio:latest false
# docker cp fio:/run.sh ~/run.sh

Полученные данные каким-то образом переносятся вот в такую наглядную таблицу. Я не понял, как это сделано, но надеюсь, что получиться разобраться. Очень удобно и наглядно проводить тестирование и сравнивать результаты.

4️⃣ Производительность дисковой подсистемы в Talos Linux по сравнению с обычным Debian была в 1,5-2 раза ниже. Причина была в разных параметрах ядра.

5️⃣ Настроек ядра очень много. Сравнение настроек в разных дистрибутивах вручную очень трудоёмкая задача. Автор сгрузил diff файл параметров ядра указанных систем в ChatGPT и он сразу же выдал ответ, какой параметр приводит к снижению производительности:

В Talos Linux включен параметр CONFIG_IOMMU_DEFAULT_DMA_STRICT=y, в то время как в Debian используется CONFIG_IOMMU_DEFAULT_DMA_LAZY=y. Режим strict в IOMMU заставляет ядро немедленно выполнять сброс кэшей IOMMU при каждом связывании и отвязывании DMA (то есть при каждом вводе-выводе), что приводит к дополнительной нагрузке на систему и может значительно снизить производительность ввода-вывода при интенсивных операциях, таких как тестирование IOPS.

6️⃣ Разница в производительности может быть значительной между разными версиями ядра Linux. Это связано с патчами безопасности, которые снижают производительность. Для каких-то старых ядер, которые уже не поддерживаются, этих патчей может не быть. На них производительность будет выше (а безопасность ниже).

7️⃣ Благодаря множественным манипуляциям над системой Talos Linux автору удалось подтянуть её производительность до оригинального Debian. Но всё равно она была ниже. Из этого можно сделать вывод, что различные альтернативные дистрибутивы Linux стоит использовать осторожно и осмысленно. Изначальная разница в производительности в 2 раза как-бы не мелочь.

Статью рекомендую прочитать полностью. Если работаете с железом и Linux, будет полезно. Я для себя забрал оттуда тесты и табличку. Попробую всё это скрестить, чтобы так же красиво и быстро сравнивать результаты. Пригодится как минимум для тестов разных типов хранилищ в системах виртуализации.

☝️ Отметил для себя полезность ИИ. Надо начинать пользоваться.

#linux#perfomance
Предлагаю вашему вниманию ping нетрадиционной графической ориентации - gping. Ну а если серьёзно, то эта заметка будет про две пинговалки, дополняющие стандартный ping.

1️⃣ Про gping я уже писал несколько лет назад. Она умеет строить график времени отклика пингуемого хоста или группы (❗️) хостов. В целом, ничего особенного в этом нет, но тот, кто формирует списки пакетов к дистрибутивам решил, что утилита достойна внимания и включил её в стандартные репозитории Debian и Ubuntu. В Убутне она уже есть, начиная с 23-й версии. В Debian появится в 13-й. Она уже там.

Ставим так:

# apt install gping

Пингуем несколько хостов и смотрим отклик:

# gping 1.1.1.1 8.8.8.8 8.8.4.4

1.1.1.1 отвечает заметно быстрее. Есть версия и под Windows. Скачать можно в репозитории. Gping скорее нужен для побаловаться в личном терминале. Я себе в WSL поставил. А вот следующий пример будет более востребован на серверах и прикладных задачах.

2️⃣Fping позволяет быстро пинговать списки узлов. Это старя программа, которая давно живёт в стандартных репозиториях. Мониторинг Zabbix с самых первых версий именно её использует для своих icmp проверок (icmpping, icmppingloss, icmppingsec).

Ставим так:

# apt install fping

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

# fping -g 192.168.13.0/24 -qa
192.168.13.1
192.168.13.2
192.168.13.17
192.168.13.50
192.168.13.186

Очень удобный вывод - 1 строка, 1 адрес. Не нужна дополнительная обработка, если используется в скриптах. Диапазон можно явно указать:

# fping -s -g 192.168.13.1 192.168.13.50 -qa

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

# fping 10.20.1.2
10.20.1.2 is alive

Можно скрыть вывод, а результат отследить кодом выхода:

# fping 10.20.1.2 -q
# echo $?
0

Успех, то есть хост ответил.

# fping 10.20.1.3 -q
# echo $?
1

Хост не ответил, код выхода 1. Удобно, что нет лишнего вывода. Ничего обрезать и скрывать не надо.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#linux#terminal
Предлагаю вашему вниманию ping нетрадиционной графической ориентации - gping. Ну а если серьёзно, то эта заметка будет про две пинговалки, дополняющие стандартный ping.

1️⃣ Про gping я уже писал несколько лет назад. Она умеет строить график времени отклика пингуемого хоста или группы (❗️) хостов. В целом, ничего особенного в этом нет, но тот, кто формирует списки пакетов к дистрибутивам решил, что утилита достойна внимания и включил её в стандартные репозитории Debian и Ubuntu. В Убутне она уже есть, начиная с 23-й версии. В Debian появится в 13-й. Она уже там.

Ставим так:

# apt install gping

Пингуем несколько хостов и смотрим отклик:

# gping 1.1.1.1 8.8.8.8 8.8.4.4

1.1.1.1 отвечает заметно быстрее. Есть версия и под Windows. Скачать можно в репозитории. Gping скорее нужен для побаловаться в личном терминале. Я себе в WSL поставил. А вот следующий пример будет более востребован на серверах и прикладных задачах.

2️⃣Fping позволяет быстро пинговать списки узлов. Это старя программа, которая давно живёт в стандартных репозиториях. Мониторинг Zabbix с самых первых версий именно её использует для своих icmp проверок (icmpping, icmppingloss, icmppingsec).

Ставим так:

# apt install fping

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

# fping -g 192.168.13.0/24 -qa
192.168.13.1
192.168.13.2
192.168.13.17
192.168.13.50
192.168.13.186

Очень удобный вывод - 1 строка, 1 адрес. Не нужна дополнительная обработка, если используется в скриптах. Диапазон можно явно указать:

# fping -s -g 192.168.13.1 192.168.13.50 -qa

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

# fping 10.20.1.2
10.20.1.2 is alive

Можно скрыть вывод, а результат отследить кодом выхода:

# fping 10.20.1.2 -q
# echo $?
0

Успех, то есть хост ответил.

# fping 10.20.1.3 -q
# echo $?
1

Хост не ответил, код выхода 1. Удобно, что нет лишнего вывода. Ничего обрезать и скрывать не надо.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#linux#terminal
Рекомендация — два полезных ресурса для ИТ-специалистов и опытных пользователей:

🧑‍💻NetworkAdmin — автор канала делится полезной информацией про Windows/Linux, актуальными уязвимостями, а также историями основанными на личном опыте в IT.

⚙️EasyTools — сервис содержит набор инструментов для решения повседневных задач прямо в мессенджере, не покидая его.

Инструменты: Загрузчик видео, Генератор паролей, DNS Lookup, Проверка SSL, Whois, Geo IP, Сканер портов, Vendor Lookup.
На прошлой неделе гремела новость с исключением русских мэйнтейнеров из числа ответственных лиц, принимающих изменения в код ядра Linux. Я особо обсуждения не читал, потому что их слишком много, а новости все довольно сухие. Фактуры там не так много.

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

Насколько я понимаю, разработчики ПО не просто так вносят изменения в апстрим базового софта, на основе которого построен их программных продукт. Тут есть чисто экономическая выгода. Если необходимые тебе изменения принимают в апстрим, тебе проще поддерживать свой продукт. Когда ты все необходимые тебе изменения постоянно накатываешь поверх базового продукта, твоя работа постоянно увеличивается по мере выхода новых версий. В какой-то момент эта ноша может оказаться неподъёмной.

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

Один из выходов из этой ситуации - делаешь свой форк, развиваешь его и забиваешь на оригинал. Но тут нужны сопоставимые ресурсы на развитие. Пример такого форка - Angie, который уже сейчас по функциональности опережает Nginx. Я без всяких компромиссов и проблем везде его ставлю по умолчанию на веб сервера. Nginx уже и не нужен.

С ядром Linux в России вряд ли наберётся ресурсов на самостоятельное развитие. Вот если бы с Китаем объединиться, думаю, результат бы был. Может и будет. Поживём - увидим. Всё идёт к тому, что интернет, как и весь мир, сегментируется. Уже и Linux скоро у каждого свой будет.

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

'It's really hard to find maintainers...' Linus Torvalds

#разное
Ушли иностранные MDM-решения, всё пропало и нам пора переходить на ломаный софт темную сторону силы?🐈‍⬛

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

- легким и понятным администрированием из единой консоли
- широким функционалом
- внушительными кейсами (банк 💫 доверяет именно им)
- регулярными доработками и обновлениями

Теперь от общих фраз к делупосту, с которым за 60 секунд вы откроете для себя крутой MDM, который давно уже дорос до UEM🔤

@Safemobile_ru

Реклама, ООО «НИИ СОКБ Центр разработки» ИНН 7724394592, erid: 2SDnje5syzB
Некоторое время назад я упомянул игру Симулятор системного администратора. Посмотрел запись игрового процесса, который мне показался необычным и приближённым к реальности.

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

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

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

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

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

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

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

🎮Steam / ▶️Видео

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

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

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

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

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

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

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

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

🎮Steam / ▶️Видео

#игра
See more posts

View in Telegram