Привет, Хабр! Меня зовут Сергей Качкин. Вместе с командой я занимаюсь тестированием производительности систем хранения данных: много тестов делаем сами, видим результаты наших коллег и заказчиков, так у нас накопилось некоторое количество опыта, которым хочется поделиться. 

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

Привет, Хабр! Меня зовут Павел, я инженер по разработке инфраструктуры в компании YADRO. В апреле 2023 года разработчики Molecule представили мажорный релиз инструмента в версии 5.0.0. Помимо множества багфиксов и улучшений, пользователи получили возможность написать свой собственный драйвер, подключить его в уже существующие сценарии тестирования ролей и использовать как molecule.docker или molecule.openstack. Я не нашел или плохо искал статей об этом и решил написать поэтапное руководство по разработке собственного драйвера — от примитивного Hello world до работающего прототипа.

В статье вы найдете пример custom_docker доработки оригинального драйвера molecule.docker, описание базовых классов и методов из API Molecule, а также рассказ о нюансах разработки и эксплуатации.

(первая часть тут: https://habr.com/ru/post/456446/)

CEPH

Введение

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

Выбор CEPH. Часть 1

У нас было пять стоек, десять оптических свичей, настроенный BGP, пару десятков SSD и куча SAS дисков всех цветов и размеров, а ещё proxmox и желание засунуть всю статику в собственное S3 хранилище. Не то чтобы это всё было нужно для виртуализации, но раз начал использовать opensource — то иди в своём увлечении до конца. Единственное, что меня беспокоило — это BGP. В мире нет никого более беспомощного, безответственного и безнравственного, чем внутренняя маршртутизация по BGP. И я знал, что довольно скоро мы в это окунёмся.

Задача стояла банальная — имелся CEPH, работал не очень хорошо. Надо было сделать "хорошо".
Доставшийся мне кластер был разнородным, настроенным на скорую руку и практически не тюнингованным. Он состоял из двух групп разных нод, с одной общей сеткой выполняющей роль как cluster так и public network. Ноды были набиты четырьмя типами дисков — два типа SSD, собранными в два отдельных placement rule и два типа HDD разного размера, собранными в третью группу. Проблема с разными размерами была решена разными весами OSD.

Саму настройку разделили на две части — тюнинг операционной системы и тюнинг самого CEPH и его настроек.

Привет, я Паша, разработчик в Yandex Infrastructure, и я катаю гусей. С 2019 года я развиваю S3-хранилище как для внутренних пользователей Яндекса, так и для клиентов Yandex Cloud. А «гусём» называется наш бэкенд S3 API: он написан на Go, а из словосочетания Go + S3 получился goose. Возможно, вы также слышали про GeeseFS — это наш высокопроизводительный FUSE-клиент для S3. C его помощью вы можете на своём ноутбуке или виртуалке подмонтировать папку, которая будет работать с бакетом S3. 

Для чего нам «гуси» и прочая орнитология? Яндексовая инсталляция хранилища S3 хранит миллиарды файлов. Это огромные объёмы данных, а также метаданных. Для хранения метаданных мы научились использовать умное шардирование, и теперь сами управляем распределением занятого места и нагрузкой между шардами баз.

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

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

Меня увлекла тема отказоустойчивости, а конкретно - отказоустойчивой работы с файлами. В этой статье я попытался соединить все полученные знания:

Кто участвует в процессе записи

Ошибки, которые могут произойти

Что от нас зависит, а что нет

И самое главное - как это этого защититься

Лонгрид посвящается любителям CLI в знак солидарности лучшего эмулятора терминала на OS Android, который испытывает «кошмарную» монополию Google.

В данной работе вербализация пойдет о нижеизложенном со всеми остановками:

[+] глубоко настраивать средý (флэшка, виджет, стиль, зеркала и конфиги);
[+] управлять серверами через ssh;
[+] скачивать ролики/отрывки с YouTube;
[+] нарезать видео, создавать gif;
[+] воспроизводить текст/музыку/радио прямо в CLI;
[+] нарезать mp3-бигфайлы (аналогов приложений на Android попросту нет), и склеивать аудиофайлы;
[+] редактировать документы;
[+] проверять орфографию: как текстовых файлов, так и различных статей по url, например, проверка орфографии статей на Habr-e;
[+] генерировать словари различной сложности со скоростью Си;
[+] создавать блок-схемы; графики; облако слов и даже 3D-визуализацию;
[+] заниматься Data Science на Android-мощностях;
[+] тестировать интернет соединение/интерфейс (требуется частично Root);
[+] сниффить/сканировать сети (требуется частично Root);
[+] запускать и управлять TOR-сетью (deleted);
[+] управлять приложениями и процессами в ОС Android (требуется Root);
[+] анализировать память;
[+] защищать любые данные от случайного редактирования/уничтожения (требуется Root);
[+] автоматически шифровать и бэкапить по ночам любые данные в своё облако;
[+] чекать username(s) и e-mail(s);
[+] проводить аудит безопасности (об опасности сердить скрипт-кидди с их любимыми: «сниффить, парсить, брутить, дампить, сканить, фишить»);
[+] работать с электропочтой;
[+] изучать UNIX/shell;
[+] программировать на Android (на выбор пользователя. В Termux портированы несколько интерпретируемых и компилируемых языков программирования);
[+] запускать python/php/npm скрипты в т.ч. в одно касание с рабочего стола;
[+] работать с криптографией, стеганографией и цифровыми подписями;
[+] парсить данные;
[*] и даже запускать GNU-GUI-софт из CLI.

Под капотом d2c.io мы используем Ansible. С его помощью мы создаем виртуальные машины у облачных провайдеров, устанавливаем программное обеспечение, а также управляем Docker-контейнерами с приложениями клиентов.

Ansible – удобный инструмент, который готов к работе почти без настройки. Это возможно благодаря отсутствию агентов (agentless system), поэтому не нужно ничего предустанавливать на обслуживаемые хосты.

Для подключения к хостам в большинстве случаев используется ssh. Однако оборотной стороной этой медали является определенная медлительность, так как вся логика находится на управляющем сервере и каждую задачу (task) Ansible формирует локально и отправляет на исполнение через SSH-подключение. Затем он принимает результат, анализирует его и переходит к следующему шагу. В статье мы рассмотрим, как можно ускорить работу Ansible.

Настройка Network UPS Tools на Linux на примере ИБП Eaton 5E650iUSB

Описание

Сервис Linux NUT (Network UPS Tools) — это комплекс программ мониторинга и управления различными блоками бесперебойного питания (далее ИБП). Полный список поддерживаемых моделей можно получить, посмотрев список драйверов в файле /usr/share/nut/driver.list.

В руководстве описана настройка отключения ПК агентом NUT при потере напряжения в сети на примере ИБП Eaton 5E 650iUSB на Ubuntu-подобных дистрибутивах. Для использования под другие дистрибутивы используйте пакетный мененджер своего дистрибутива или соберите из исходных кодов. Новейшую версию Network UPS Tools можно скачать на GitHub по ссылке ссылке.

Часть 1
Часть 2
Часть 3
Часть 4

В этой серии постов мы внимательно рассмотрим один из главных ингредиентов в контейнере – namespaces. В процессе мы создадим более простой клон команды docker run – нашу собственную программу, которая будет принимать на входе команду (вместе с её аргументами, если таковые имеются) и разворачивать контейнер для её выполнения, изолированный от остальной системы, подобно тому, как вы бы выполнили docker run для запуска из образа.

Введение

Я делала много вещей с компьютерами, но в моих знаниях всегда был пробел: что конкретно происходит при запуске программы на компьютере? Я думала об этом пробеле — у меня было много низкоуровневых знаний, но не было цельной картины. Программы действительно выполняются прямо в центральном процессоре (central processing unit, CPU)? Я использовала системные вызовы (syscalls), но как они работают? Чем они являются на самом деле? Как несколько программ выполняются одновременно?

Наконец, я сломалась и начала это выяснять. Мне пришлось перелопатить тонны ресурсов разного качества и иногда противоречащих друг другу. Несколько недель исследований и почти 40 страниц заметок спустя я решила, что гораздо лучше понимаю, как работают компьютеры от запуска до выполнения программы. Я бы убила за статью, в которой объясняется все, что я узнала, поэтому я решила написать эту статью.

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

Более удобный формат статьи.

То, что ChatGPT может автоматически генерировать что-то, что хотя бы на первый взгляд похоже на написанный человеком текст, удивительно и неожиданно. Но как он это делает? И почему это работает? Цель этой статьи - дать приблизительное описание того, что происходит внутри ChatGPT, а затем исследовать, почему он может так хорошо справляться с созданием более-менее осмысленного текста. С самого начала я должен сказать, что собираюсь сосредоточиться на общей картине происходящего, и хотя я упомяну некоторые инженерные детали, но не буду глубоко в них вникать. (Примеры в статье применимы как к другим современным "большим языковым моделям" (LLM), так и к ChatGPT).

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

1. Параметры для удобного просмотра лога
2. Вывод актуальных изменений в файл
3. Просмотр изменений в определённых строках файла
4. Просмотр ещё не влитых в родительскую ветку изменений
5. Извлечение файла из другой ветки
6. Пара слов о ребейзе
7. Сохранение структуры ветки после локального мержа
8. Исправление последнего коммита вместо создания нового
9. Три состояния в Git и переключение между ними
10. Мягкая отмена коммитов
11. Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
12. Игнорирование пробелов
13. Добавление определённых изменений из файла
14. Поиск и удаление старых веток
15. Откладывание изменений определённых файлов
16. Хорошие примечания к коммиту
17. Автодополнения команд Git
18. Создание алиасов для часто используемых команд
19. Быстрый поиск плохого коммита

Одной из важных составляющих информационной безопасности инфраструктуры компании является SIEM - система управлением событиями и информацией безопасности. Такую систему можно условно поделить на 2 основные части — подсистему сбора событий и подсистему анализа полученных событий. Правильная настройка первой поможет обнаружить вторжение на ранних этапах проникновения, облегчит написание событий тревоги (алертов), а если вас всё-таки взломали, то позволит разобраться, как и почему это произошло, какие действия выполняли злоумышленники. Основным инструментом для сбора системных событий в линукс-системах является auditd. На основе этого инструмента созданы и другие, например, auditbeat, go-audit, которые дополняют основной функционал auditd. Поэтому, разобравшись с основными принципами работы базового инструмента, вам не составит труда воспользоваться и всеми остальными.

Структура статьи:

- Краткое знакомство с инструментом: общее описание auditd, плюсы и минусы, синтаксис;

- Принципы написания правил: практические советы по специфике инструмента, которые позволят делать меньше ошибок при работе с ним;

- Как тестировать правила: порядок действий, который позволит внедрить наборы правил в инфраструктуру любого размера;

- Алгоритм тестирования правил: упорядоченный список действий для проверки отдельно каждого правила и фильтров к нему;

- Модель угроз: как рассматривать систему с точки зрения атакующего, чтобы ничего не забыть;

- Пример: применяем полученные знания на практике.

Вы когда-нибудь задумывались над тем, как вы создаете виртуальные машины?
Как правило, это долгий и скучный процесс, богатый ручной работой.

Начнем с простого вопроса:

Что означает QEMU/KVM или QEMU-KVM?

Можно ответить - это QEMU + KVM или qemu-system, запущенный с kvm в качестве ускорителя. Но в какой-то степени это еще и анахронизм, так как с появлением KVM его разработчики для интеграции с QEMU поддерживали отдельный форк qemu-kvm, но начиная с QEMU версии 1.3 (декабрь 2012) все основные изменения из qemu-kvm были перенесены в главную ветку QEMU, а qemu-kvm объявлен устаревшим.

В разных дистрибутивах до сих пор еще можно встретить исполняемый файл qemu-kvm или просто kvm, но это лишь обертки над qemu-system:

exec qemu-system-x86_64 -enable-kvm "$@"

или симлинки:

/usr/bin/kvm -> qemu-system-x86_64

А в самом qemu существует проверка:

Еще несколько слов о Path MTU Discovery Black Hole

Вместо вступления