Системное администрирование *

Продолжаю рассматривать отечественные дистрибутивы Linux на роль домашней и рабочей системы. На этот раз посмотрим на RED ОС.

Свое знакомство с мониторингом Icinga2 я начал в 2018-м году, со статей IT-KB, за что им огромная благодарность. Статьи были подробные, под Debian 8. В то время я активно использовал FreeBSD и за несколько дней изучения мне удалось запустить мониторинг в CBSD JAIL. В 2020-м все это было мною опробовано на Debian 10. Естественно с подробным документированием и составлением статей в личной WiKi. Мониторинг интересный, легкий, возможности широкие, мобильный клиент под Android приличный и удобный. Но есть проблема - даже по своим заметкам в WiKi установка в новой локации каждый раз занимает от часа до двух (на данный момент в телефоне уже с 10-к штук инстансов).

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

В этом году руководство приняло решение обновлять железо в серверной. Но, с учетом уго древности, требовалось обновить если не всё, то почти всё.
На момент принятия решения об обновлении мы имели полку HP C3000 с блэйд серверами g6-g7 поколений, подключенную к дисковым хранилищам, через ethernet 1GbE аплинки. Дисковые хранилища с sas 10k без кэша. Все это добро работало по iSCSI протоколу, на блэйд серверах были старенькие ESXi. Из нагрузки имелось порядка 70-80 vm разной направленности - начиная от 1С с базами данных до высоконагруженных сервисов. Признаюсь, я умолчал о standalone сервере на nvme под сверх нагруженный сервис, но об этом, может, расскажу позже, если статья зайдет.

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

В итоге согласовали покупку 4 серверов hp dl360g10 в nvme исполнении backplane, сетевых карт 2*25GbE, свитчей mellanox SN2410-CB2FC, nvme дисков с минимум 3 DWPD. Всё оборудование с поддержкой RDMA/RoCE.

О том, как всё это новое добро настраивалось и какие решения были приняты далее.

Привет, Хабр! На связи автор статьи двухлетней давности «Пожалуйста, прекратите называть админов девопсами». В ней, если помните, я ловил пескарей в процессе поиска работы офигевал от несоответствия реального мира и моих онтологических ожиданий. С тех золотых денёчков изменилось примерно всё — и вот, с учётом полученного за прошедшее время опыта я хотел бы оглянуться, посмотреть назад и понять, выдержали ли мои прошлые соображения проверку временем.

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

Системы хранения и обработки данных или СХД отлично справляются не только с огромными объёмами данных, но и позволяют предприятию управлять ими – практически в любой нише, будь то интернет магазин или промышленное производство.

Долгое время на рынке большой популярностью пользовались продукты зарубежных разработчиков. Но после 2022 года российские предприниматели лишились многих востребованных СХД – HPE, DELLEMC, Fujitsu, HGST. Со временем и в этом секторе удалось наладить параллельный импорт – но это практически никак не решило проблему, поскольку поставляемая продукция до сих пор лишена критичных для бизнеса сервиса и технической поддержки.

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

Marzban — это cреда на базе Xray-core, которая предоставляет простой и удобный пользовательский интерфейс для создания и управления учетных записей прокси (XTLS-Reality, Trojan, Vless, VMess, Shadowsocks) и созданный с использованием Python и ReactJS.

В данной статье рассмотрим установку и настройку сервера Marzban, настройка конфигураций клиентов и настройка дополнительных нод (масштабирование)

В наше время растет популярность децентрализованных альтернатив современным подходам к маршрутизации трафика в вычислительных сетях (например, для обхода санкционных блокировок недружественных стран и анонимизации трафика). Одним из примеров такого подхода является Yggdrasil. Новые подходы обещают нам инновации, децентрализации и конечно же гарантии безопасности. Но так ли это на самом деле? И хотя многие опытные пользователи и так знают о проблемах безопасности подобных сетей, мне бы хотелось подсветить их сильнее на одном конкретном примере, не претендуя на звание создателя rocket science.

ПРЕДУПРЕЖДЕНИЕ. Все совпадения вымышлены. Автор не ставил своей целью просканировать весь Yggdrasil и проэксплуатировать все уязвимости безопасности.

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

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

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

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

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

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

Привет! Меня зовут Петр и мы в компании Nixys очень любим Redis. Эта база используется, если не на каждом нашем проекте, то на подавляющем большинстве. Мы работали как с разными инсталляциями Redis, так и с разными версиями, вплоть до самых дремучих, вроде 2.2. Несмотря на то, что в Интернете очень много статей и докладов по этой БД, мы в своей практике достаточно часто встречаемся с непониманием некоторых основных концепций Redis и со стороны разработчиков, и со стороны системных администраторов.

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

Эта статья - сборник разных вопросов и ответов на них, которые звучали в комментариях к моим предыдущим статьям (Современные технологии обхода блокировок: V2Ray, XRay, XTLS, Hysteria, Cloak и все-все-все, Bleeding-edge обход блокировок с полной маскировкой: настраиваем сервер и клиент XRay с XTLS-Reality быстро и просто и других из той же серии) и в личных сообщениях.

Тема больших списков IP адресов не перестаёт быть актуальной, не обошла она и меня стороной, вызвав, скорее, академический интерес. Желание покрутить-повертеть базы адресов переросло в проект-хобби выходного дня – одностраничное веб-приложение претендующее на роль помощника системного администратора. Инструментов пока немного, но начало положено, и те, что есть, позволят вдоволь наиграться с любыми базами адресов IPv4 сохранёнными в формате CSV файла.

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

Задача: имеется 5 аппаратов Yealink SIP-T46U и 20 аппаратов SIP-T31P. Их необходимо настроить, то есть, перевести из состояния "новый из коробки" в состояние "готов к использованию".

Процесс автопровижининга можно разделить на 5 этапов:

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

Автоинструментарий упрощает внедрение Observability. С гордостью представляем Grafana Beyla — автоинструментарий eBPF с открытым исходным кодом, который сейчас в стадии публичного тестирования. Beyla сообщает данные о задержках для основных запросов, а также метрики RED (Rate-Errors-Duration) для сервисов Linux HTTP/S и gRPC — и всё это без модификации кода для ручной вставки зондов.

В этой статье мы рассмотрим, как установить и настроить Grafana Beyla с помощью Grafana Cloud для улучшения наблюдаемости приложений. Ещё поделимся планами на будущее.

Технология NVMe через различные фабрики (далее NVMeOF) оформлена в качестве стандарта летом 2016 года, она была встроена в пятую ветку ядра Linux.

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

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

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

Задача: подключить много дисков с нескольких серверов

В данной статье описывается способ создания минималистичного образа sd карты c debian arm64 на примере отладочной платы с zynq ultrascale zcu106. Данный способ можно использовать для создания загрузочных образов других устройств с соответствующими изменениями. Битстрим, ядро Linux и dts для удобства разработки размещаются отдельными файлами.

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

…и попутно воспитать сотрудников

Всем привет! Хочу поделиться опытом борьбы с большим «зоопарком» гипервизоров и виртуальных машин (далее – ВМ), а точнее историей по созданию внутреннего сервиса по контролю за виртуальными машинами, благодаря которому нам в IT стало сильно проще работать с нашим зоопарком, а сотрудники стали присылать информацию по удалению неактуальных ВМ.

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

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

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

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

И снова о гостиничной инфраструктуре.

В предыдущей статье мы рассказали о достаточно простой реализации WiFi для мини-отеля.

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

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