Multi-area OSPF и проектирование сетей: рекомендации по планированию

Эффективное планирование и проектирование сетевой топологии имеют решающее значение для поддержания надежных, масштабируемых и высокопроизводительных систем связи. Одним из ключевых протоколов для достижения таких целей в крупномасштабных сетях является протокол маршрутизации Open Shortest Path First (OSPF). Использование OSPF не только оптимизирует передачу сетевого трафика, но и повышает масштабируемость и упрощает управление. В этой статье рассматриваются технические нюансы multi‑area OSPF, предлагаются идеи и лучшие практики для проектирования сетей.

https://telegra.ph/Multi-area-OSPF-i-proektirovanie-setej-rekomendacii-po-planirovaniyu-11-21

#ит_статьи #network #multi_area #ospf #architecture

Почему мое приложение на 2 vCPU работает быстрее в виртуалке, чем в контейнере?

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

Контейнеры реализуют идею «Собрал один раз — запускай где угодно», что позволяет командам разработки и эксплуатации управлять приложениями легче и более системно. Но довольно часто после переноса приложения как есть в Kubernetes производительность вдруг оказывается ниже ожидаемой.

Эта заметка в первую очередь смотрит на проблему со стороны CPU: почему при переносе сервисов из VM в мир Kubernetes (контейнеров) могут возникнуть определённые сложности и как они могут привести к просадке в производительности. Внутренние узкие места самого приложения — сетевой ввод-вывод, дисковый ввод-вывод и тому подобное — остаются за рамками обсуждения.

https://telegra.ph/Pochemu-moe-prilozhenie-na-2-vCPU-rabotaet-bystree-v-virtualke-chem-v-kontejnere-11-24

#ит_статьи #devops #kubernetes #performance #numa #cgroups #cpulimit

Настройка сервера Syslog и пересылка логов с Linux-хоста

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

Резервирование — критичная вещь, когда речь идёт о важных или чувствительных данных. Что если вам нужно понять, что происходило внутри системы перед тем, как сетевое устройство или рабочая станция окончательно «легли»? Что если злоумышленник смог проникнуть в систему, натворил дел и подчистил следы, изменив локальные логи? Нетрудно представить, почему отказ от централизованного логирования может обернуться серьёзными проблемами.

В этой заметке мы разберём:
- Как настроить сервер Syslog.
- Как настроить Linux-хост для пересылки логов на сервер Syslog.

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

https://telegra.ph/Nastrojka-servera-Syslog-i-peresylka-logov-s-Linux-hosta-11-24

#ит_статьи #devops #linux #syslog #logging

Разбираемся в процессе Secure Boot в Linux

Эта заметка начнётся с общего обзора процесса загрузки Ubuntu, а затем углубится в то, какую роль в нём играет SecureBoot, если он включён. Я затрону такие вещи, как shim, переменные EFI и MOK. Информация, которую вы тут увидите, собрана из источников, перечисленных в конце статьи. Также будут команды и примеры вывода, чтобы картина получилась более целостной.

Понимание процесса загрузки вместе с SecureBoot важно, потому что без нормального представления о том, как всё устроено внутри Linux-системы, очень легко случайно превратить её в кирпич, пытаясь включить такие настройки, как SecureBoot. Это низкоуровневые операции, которые при неосторожности могут наделать много бед.

https://telegra.ph/Razbiraemsya-v-processe-Secure-Boot-v-Linux-11-25

#ит_статьи #linux #boot #uefi #secureBoot #shim #mok #kernel

eBPF вместо всего: почему это новая эра сетей, мониторинга и безопасности?

Раньше модификация Linux требовала пересборки ядра или использования дополнительных модулей. Но теперь есть eBPF — технология, которая позволяет программировать ядро на лету, не жертвуя стабильностью. Звучит как мечта системного администратора или очередной тренд, который существует только на бумаге, но нет. Обработка миллионов пакетов в секунду, отслеживание уязвимостей в реальном времени и замена традиционных агентов мониторинга чем-то более эффективным — это не будущее. Это настоящее, в котором уже живут, например, CloudFlare и Netflix.

https://telegra.ph/eBPF-vmesto-vsego-pochemu-ehto-novaya-ehra-setej-monitoringa-i-bezopasnosti-11-27

#ит_статьи #devops #linux #kernel #eBPF

OpenTelemetry

OpenTelemetry — это open-source фреймворк для наблюдения за системой. Он предоставляет вендоронезависимые, или, если угодно, нейтральные API, SDK и другие инструменты для сбора телеметрии из cloud-native приложений и их инфраструктуры, чтобы понимать их состояние и производительность.

Управлять производительностью в сегодняшней сложной распределённой среде — задача ещё та. Телеметрия жизненно необходима, чтобы DevOps- и IT-команды могли разбираться, как ведут себя эти системы и что влияет на их работу. Чтобы получить полноценную картину о поведении сервисов и приложений, нужно инструментировать все используемые фреймворки и библиотеки, да ещё и на разных языках программирования.

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

OpenTelemetry важен потому, что он стандартизирует способ сбора телеметрии и её передачу в backend-платформы. Он закрывает пробелы в observability, предлагая общий формат инструментирования для всех сервисов. Помимо этого, он поддерживает множество популярных open-source проектов, включая Jaeger и Prometheus.

https://telegra.ph/OpenTelemetry-11-27

#ит_статьи #devops #opentelemetry #monitoring #observability

GoAccess

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

Хотя вывод в терминал является стандартным, программа также способна генерировать полный автономный HTML-отчет в реальном времени (что отлично подходит для аналитики, мониторинга и визуализации данных), а также отчеты в формате JSON и CSV.

https://goaccess.io/

#ит_заметки #devops #linux #shell #logs #goaccess

Запуск GUI-приложений в Docker-контейнере

Docker обычно используют, чтобы упаковывать фоновые сервисы и консольные утилиты. Но им вполне можно запускать и графические программы! Для этого есть два варианта: использовать уже работающий на хосте X-сервер или поднять VNC-сервер прямо внутри контейнера.

https://telegra.ph/Zapusk-GUI-prilozhenij-v-Docker-kontejnere-11-30

#ит_статьи #devops #linux #docker #vnc #X11

Исследуем NUMA

В системах Symmetric Multiprocessor (SMP) вся физическая память выглядит как единый пул. Все CPU делят между собой аппаратные ресурсы и одно адресное пространство, потому что ядро в системе тоже одно.

Когда физическая память и устройства ввода-вывода находятся на одинаковом расстоянии по задержкам от набора независимых физических CPU (сокетов), такую систему называют UMA (Uniform Memory Access).

В UMA-конфигурации все физические процессоры обращаются к памяти через один и тот же контроллер и работают на одном общем bus’е. Из-за физических ограничений общей шины и растущих конфликтов при обращениях, собрать большой SMP-сервер довольно сложно — чем больше CPU, тем все хуже масштабируется.

NUMA (Non Uniform Memory Access) даёт возможность строить системы покрупнее, но ценой различающихся задержек при доступе к памяти.

Один CPU-сокет (который может содержать несколько логических ядер, каждое с двумя гиперпотоками) — это UMA. Но как только в системе появляется два и более сокетов, она становится NUMA. Такой дизайн — компромисс: мы получаем большую систему, но вместе с ней и более высокие задержки доступа к памяти.

Главный плюс NUMA-серверов — заметно более высокая производительность по всем направлениям (compute, memory, network, storage). Иногда такого уровня просто не добиться на UMA-системах.

Linux-ядро понимает NUMA и учитывает привязку процессов к CPU и локальность данных, чтобы по возможности держать задержки на низком уровне. Библиотека libnuma и утилита numactl позволяют приложениям подсказывать ядру, как им хотелось бы управлять памятью.

https://telegra.ph/Issleduem-NUMA-12-01

#ит_статьи #devops #linux #kernel #numa

Удобные git-diff’ы в терминале с FZF

Иногда команда git diff ощущается немного неудобной. Она вываливает на экран кучу информации разом. Я пользуюсь git diff не только чтобы проверить изменения перед коммитом, но и чтобы просматривать pull-request’ы или искать баги, появившиеся между двумя коммитами. Когда изменённых файлов много, бесконечная прокрутка вверх-вниз быстро начинает раздражать.

Хочется чего-то по-типу IDE: список файлов слева, diff — справа. При этом покидать терминал совсем не хочется. Я думал, что для такого придётся городить какой-то хитрый bash-скрипт. Но оказалось, что всё можно сделать довольно просто — с помощью инструмента fzf.

https://telegra.ph/Udobnye-git-diffy-v-terminale-s-FZF-12-02

#ит_статьи #linux #git #fzf #bash #zsh #diff

Как справиться с лог-штормом “Too Many Open Files”

Если ваш HTTP-сервер встречает вас ошибкой 599: Network Connection Timed out, значит, дела так себе. Первым делом стоит проверить, вообще ли сервер доступен и можете ли вы зайти на него по SSH. А дальше в бой вступает его лог-файл. Скорее всего, там вы увидите что-то в духе:

HTTP: Accept error: accept tcp [::]:<port_number>: accept4: too many open files

Можно задуматься: какое отношение “слишком много открытых файлов” имеет к ошибке accept в HTTP? На самом деле объяснение довольно занятное. В Debian каждый сокет считается открытым файлом. Вот вам и связь! Поскольку каждый сокет — это файл, а сервер превысил лимит на количество открытых файлов, он просто не в состоянии принимать новые TCP-подключения.

# команда, которая считает количество открытых файлов сервисом
lsof -u <user-running-the-service> | wc -l

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

https://telegra.ph/Kak-spravitsya-s-log-shtormom-Too-Many-Open-Files-12-03

#ит_статьи #devops #linux #ulimit #performance

Как работает chroot и зачем он нужен

chroot (change root) — одна из тех забавных и в то же время впечатляющих штук в Linux, которые мне очень нравятся. Когда я впервые столкнулся с этим, меня реально поразило, что можно просто переключиться в другую корневую файловую систему прямо из текущей, поковыряться в ней и поменять что нужно ещё до того, как вы загрузитесь в неё. Я не раз пользовался chroot, чтобы внести правки в файловую систему без необходимости загружаться в неё напрямую. Например, установить пакет, обновить hostname и так далее. Давайте разберёмся глубже, зачем это нужно и какие у этого есть ограничения.

https://telegra.ph/Kak-rabotaet-chroot-i-zachem-on-nuzhen-12-04

#ит_статьи #devops #linux #chroot #rootfs

Управление учётными данными в Systemd

В версии 247 systemd получил систему управления учётными данными. Она позволяет передавать чувствительную информацию от системы в юнит. Основной сценарий использования — передача конфигурации, паролей, приватных ключей и прочего подобного. Подробнее эта функциональность описана в systemd.exec(5).

В Release Note нововведение было описано следующим образом:

Появилась поддержка шифрованных и аутентифицированных учётных данных.
Она расширяет логику, появившуюся в v247, добавляя возможность неинтерактивного симметричного шифрования и проверки подлинности.
Для этого используется ключ, который хранится в /var/ или в чипе TPM2 (если он есть), или сразу оба источника (по умолчанию, если TPM2 присутствует, применяется комбинированный вариант, иначе — только ключ в /var/). Учётные данные автоматически расшифровываются в момент запуска сервиса и предоставляются ему уже в открытом виде.
Новый инструмент `systemd-creds` позволяет заранее зашифровать данные для такого использования, а новые параметры в файле сервиса — LoadCredentialEncrypted= и SetCredentialEncrypted= — настраивают работу с такими учётными данными.

Эта возможность полезна для того, чтобы хранить чувствительные вещи, вроде SSL-сертификатов, паролей и подобного, в зашифрованном виде «на покое», расшифровывая их только при необходимости — и так, чтобы всё это было привязано к конкретной установке ОС или оборудованию.

Выглядит как минимум любопытно. Давайте посмотрим, как это работает на практике!

https://telegra.ph/Upravlenie-uchyotnymi-dannymi-v-Systemd-12-05-2

#ит_статьи #devops #linux #systemd #credentials #security #hardening

Введение в Seccomp

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

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

https://telegra.ph/Vvedenie-v-Seccomp-12-06

#ит_статьи #linux #seccomp #bpf #security #kernel

Введение в Landlock

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

https://telegra.ph/Vvedenie-v-Landlock-12-07

#ит_статьи #linux #seccomp #landlock #security #sandbox

Связь между подами в Kubernetes

Одним из ключевых элементов Kubernetes является под - логическая группа из одного или нескольких тесно связанных контейнеров. Понимание того, как поды обмениваются данными друг с другом, критично, если вы хотите строить устойчивые и масштабируемые приложения в кластере Kubernetes. В этой заметке мы подробно разберёмся, как работает связь «pod-to-pod» и посмотрим на разные паттерны и техники взаимодействия.

https://telegra.ph/Svyaz-mezhdu-podami-v-Kubernetes-12-08

#ит_статьи #devops #kubernetes #pods #networking

Изучаем, как работает ingress-контроллер, собрав свой собственный на bash

В этой статье вы узнаете, как работает Ingress-контроллер в Kubernetes, построив его с нуля на bash.

https://telegra.ph/Izuchaem-kak-rabotaet-ingress-kontroller-sobrav-svoj-sobstvennyj-na-bash-12-09

#ит_статьи #devops #kubernetes #ingress #bash #nginx

Наконец-то ребята из контейнерной платформы “Штурвал” прислушались к сообществу и сделали альтернативу бесячей форме на сайте для получения community-лицензии. Теперь ее можно получить через бота в телеге: @l4_helper_bot.
Может ещё и Open-Source-версию сделают?