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

Какую информацию содержит FRU EEPROM и как с ней работать

Набор возможных данных, хранимых во FRU EEPROM, определяется спецификацией Intel IPMI FRU Information Storage. Вся информация разделена на пять областей, присутствие каждой из которых не обязательно и определяется информацией в общем заголовке FRU EEPROM, где размещены указатели на данные каждой из них в следующем порядке:

1. Область для внутреннего использования (Internal Use Area) — ее
содержимое не описано спецификацией. Предполагается, что эта часть EEPROM может использоваться программным обеспечением BMC или другого контроллера на плате для хранения какой-то служебной информации (например, внутренних состояний).

2. Область информации о шасси (Chassis Information Area) — здесь содержится базовая информация о «корпусе» или «шасси» устройства, описываемого этим FRU EEPROM. Основным параметром тут является «тип шасси», который представляет собой целое число, выбираемое согласно спецификации SMBIOS (см. DMTF DSP0134, Table 17). Например, значение 0x17 соответствует типу «Rack Mount Chassis». Также в этой области может содержаться информация о серийном номере шасси и его артикуле (part number).

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

Какие еще есть области во FRU EEPROM, и как утилита frugen и библиотека libfru помогают с ними работать — читайте в статье Александра Амелькина, технического эксперта департамента разработки BIOS и BMC в компании YADRO, а также автора и мейнтейнера проекта frugen / libfru.

Подарить свое сердце? А может, лучше подарить свой сервер? 💙

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

Как перенести сервер:

1️⃣Заходим в Панель управления, выбираем конкретный сервер и нажимаем «Доступ»

2️⃣Кликаем кнопку «Передать»

3️⃣Указываем логин аккаунта, на который переносится сервер, и вводим код подтверждения (он придет на почту)

4️⃣У получателя сервер появится в списке. Его можно принять или вообще отказаться от переноса

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

Перенести сервер на другой акк →

Начинаю собирать домашнюю "лабу". И моя небольшая история

Я расту, и с ростом меня растут мои аппетиты. Занимаюсь программированием я класса с.. 8? Где-то так, но у меня не было возможности устроить себе рабочее место. Моим рабочим местом долгое время был небольшой ноутбук на селероне с 4 гб оперативной памяти. На нём я и простенькие сайты умудрялся делать, и в SA:MP играл (кто-то помнит?), и делал даже сервер для CR:MP.

Появился в сознательном возрасте компьютер у меня позже, но он тоже был не мощный. Не очень новый процессор, видеокарта только встроенная в процессор, один монитор. Но я пытался выжимать максимум, на нём я начал изучать Питон, тыкал Шарпы. Сейчас я окончательно закрепил себя у себя в сознании как Python Backend Web-developer.

Дальше, уже в другой квартире даже, появилась возможность собрать компьютер получше. Ryzen 7 3700X, 32 Гб ОЗУ (которые появились даже позже, изначально сидел на 12), RTX 3060.

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

Примерно в то же время, даже немного раньше, чем второй монитор, я взял себе у знакомого старый Synology NAS, за недорого относительно цен на них на новые.

Купил в него диск на 4 Тб, так чтоб надолго. Пользуюсь =)

Это только начало ведь. Я расту, аппетиты растут.

По работе набирался опыта работы с железками. Видел коммутаторы, впервые смотрел как вживую настраивается Микротик (одно дело в PNET тыкнуть на роутер и вот тебе консоль, другое - настраивать реальное устройство). Что самое интересное - я узнал про Proxmox.

Не то что бы я раньше не знал про виртуализацию. Виртуалки конечно запускал, и линукс на них, но только изнутри Винды в VirtualBox или VMWare. А тут - проксмокс!

Буквально на днях решил протестировать, что же это такое. Помните ноутбук на селероне с 4 Гб оперативки, про который шла речь выше? Так вот, я взял его, старичка, накатил проксмокс по гайду с Хабра, даже виртуалочку одну на убунту всё таки создал. Более того, даже приложение по работе, которое я разрабатываю, развернул. Правда, больше ничего я не разверну - оно уже всё вместе кушает 3.28Гб ОЗУ из 4х. Но я хочу больше...

То, что будет скоро, буквально до 30 июня максимум: мой первый МиниПК. Характеристики такие: N100, 16 Gb RAM, 1Tb SSD. Беру его как раз для виртуалок. Тестовое окружение для того, чтобы деплоить и тестировать свои приложения а-ля как будто на реальном сервере, плюс отдельные виртуалки под разные сервисы, какие - посмотрим. Возможно, первым сервисом, который я поставлю, будет Plex (или его аналог). И сразу же поставлю Gitea, которая сейчас работает с моего компьютера.

И то, что будет раньше 30 июня, совсем скоро - локальная сеть быстрее 100 мбит. Я пока что взял один коммутатор с 5 портами по 2.5 гбит, надо будет подумать, между кем делить трафик на коммутаторе. Может, буду с МиниПК как раз раздавать фильмы/сериалы, и поведу быструю локалку на телевизоры - к одному на кухне, к другому в зале. Тут есть проблема - я не знаю как это сделать красиво. Сейчас телики работают по вайфаю. Как вести провод - придумаем.

P.S. Если бы тут можно было вставить больше одной фотографии - я бы вставил, но увы.

Задача о новой фиче, которую никто не видит

Задача будет полезна разработчикам веб-приложений и сервисов.

Текст подготовил Артём Шумейко — внештатный райтер, амбассадор Selectel и автор YouTube-канала о разработке.

Условие

В компании «ГигаПост» выпустили долгожданное обновление: на сайте появилась новая кнопка «Подписаться на тему». Интерфейс готов, API поддерживает, проверено на стенде — все работает как часы.

Но после релиза начались странности. Некоторые пользователи видят кнопку, а некоторые — нет. Кто-то говорит, что она появилась через сутки. Кто-то — что только после нажатия Ctrl+F5.

Команда фронтенда уверена — код задеплоен. Бэкенд-эндпоинт отвечает корректно. На тестовом стенде все видно. Даже сам разработчик открывает сайт на своем ноутбуке — кнопка есть.

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

И вот тогда кто-то предложил простую мысль: а пользователи вообще видят свежую версию сайта?

Задача

Почему часть пользователей не видит новую кнопку, хотя код задеплоили? В чем может быть причина? Где в цепочке доставки может остаться старая версия?

Предлагайте свое решение в комментариях. А правильный ответ можно подсмотреть в Академии Selectel.

Говорят, в Selectel появились GPU за рубль.

Проверить

Как обнаружить anycast-адреса сервисов при помощи неравенства треугольника

Технически, по одному и тому же IP-адресу может отвечать всякий интернет-узел, который находится на (двунаправленном) техническом пути следования пакетов. Чтобы такое работало без запинки для многих IP-источников - требуется согласовать пути следования пакетов на уровне IP-сети, то есть, средствами BGP. Штатный способ использования этой особенности называется Anycast. Настроить и поддерживать сложно, но, при грамотном подходе, метод отлично работает и достаточно широко используется в глобальной Сети. При Anycast один и тот же IP-адрес, наблюдаемый из разных точек Интернета, адресует разные физические узлы. Эти физические узлы могут быть географически распределены - ближе к пользователям. Обычно, так и делается, потому что это одно из основных практических преимуществ Anycast, но далеко не единственное преимущество - anycast-адреса могут быть разведены средствами BGP и коммутации сетевых сегментов из соображений устойчивости к DDoS-атакам, распределения прочей нагрузки, повышения надёжности и т.д. Примеры: 1.1.1.1, 8.8.8.8, многие корневые DNS-серверы.

Как подручными средствами проверить, что какой-то интернет-сервис стоит за anycast-адресами? Для этого нужно использовать неравенство треугольника. Тестируемый узел должен отвечать в рамках того или иного протокола, который позволяет измерить сетевое время доставки пакетов.

Методика. Пусть мы обнаружили IP-адрес сервиса (обычно, из DNS) и хотим его проверить. Пусть узел под этим адресом отвечает по ICMP - ping. Возьмём два опорных узла-источника, расположенных в совсем разных местах Интернета: например, узел в Амстердаме (обозначим его А) и узел во Владивостоке (соответственно - В). Тестируемый узел назовём Т. Принцип: если среднее время доставки ping между А, В (А <--> В) существенно превышает сумму ping для А --> Т и В --> Т, то сервис, работающий на узле T, скорее всего, использует Anycast. Поэтому измеряем время силами ping. Это и есть нарушение неравенства треугольника: если сумма расстояний (в смысле ICMP) от каждой из точек тестирования к тестируемому узлу меньше, чем расстояние между этими точками, то тестируемый узел - это, скорее всего, как минимум два узла, использующих один и тот же IP-адрес, то есть, это anycast-адрес.

Конечно, тут всегда есть место для погрешности, однако в подавляющем большинстве случаев Anycast так виден - иначе в нём не было бы смысла. Можно взять несколько опорных точек, а не две, тогда точность возрастёт.

Новая консоль для облачных серверов

Встречайте в панели серийную консоль — быструю и с удобным копипастом.

Работает «из коробки» на серверах, установленных после 4 апреля 2024. Для остальных — одна команда в панели управления, и готово.

Из удобных фич:

➖ Поддержка Ctrl+C/Ctrl+V, скролла и мыши в терминале.
➖ Подсветка синтаксиса в один клик.
➖ Независимость от публичной сети и SSH.
➖ Мгновенный запуск и оптимизация потребления ресурсов.

✏️ VNC-консоль также остается доступной. На всех серверах, кроме тех, что с Виндой, можно легко переключаться между консолями.

Затестить новую консоль →

Как связать пару тысяч ИП и маркет?

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

Рассказываем на примере кейса XWAY. Переходите в Академию Selectel чтобы узнать, как компания:

• Построила гибридную и отказоустойчивую инфраструктуру с обработкой 1 000 запросов в секунду.

• Использует облачные серверы, Managed Kubernetes и выделенные серверы от Selectel для обеспечения высокой производительности.

• Обеспечивает быструю и надежную сетевую связность при уровне SLA 99,98%

• Автоматизировала управление инфраструктурой, снизив зависимость от сторонних специалистов.

Лондон-Париж. Дедики там, блики крыш

Невозможно не вспомнить когда-то популярную песню. И невозможно не рассказать, что мы открыли целых 2 новых локации для выделенных серверов — Лондон и Париж.

Итак, в наличии по 5 сборок (но скоро могут разобрать, успевайте):

💂В Великобритании:

Минимальная: AMD EPYC 3151, 4 ядра, 2.7 ГГц, 8 потоков, 32 ГБ RAM, 1 ТБ NVMe — за 7 800 ₽/мес

Максимальная: AMD EPYC 7702, 64 ядра, 2.0 ГГц, 128 потоков, 512 ГБ RAM, 2 × 2 ТБ NVMe — за 27 300 ₽/мес

🥐 Во Франции:

Минимальная, как и у британских соседей.

Максимальная: 2 × AMD EPYC 7742, 64 ядра, 2.25 ГГц, 128 потоков, 512 ГБ RAM, 2 × 2 ТБ NVMe — за 48 100 ₽/мес

Пополнить коллекцию дедиков →

Доброго дня. В этом посте хочу описать способ развертывания приложений в Docker на Linux сервере без использования реестра. Для этого нужно:

1. Сохранение образа docker save -o myimage.tar myimagename

2. Передача файл myimage.tar на сервер по FTP или любым другим способом

3. Загрузка образа docker load -i myimage.tar или podman load -i myimage.tar

Такой способ позволяет разворачивать Docker‑образы без использования реестра — просто, удобно и быстро. Если у вас по любой причине нет реестра, но хочется использовать Docker, вы можете найти это полезным. Надеюсь, кому‑то пригодится в реальной практике. Если вы используете другие подходы или автоматизируете процесс — поделитесь в комментариях. Спасибо за внимание!

Мы используем коммутаторы Arista с rear-to-front обдувом, что очень удобно для кабель-менеджмента, поскольку вся укладка кабелей как правило происходит с тыльной стороны стойки, при этом спереди всё выглядит минималистично и без проводов. Но вот что бывает когда стойка узкая, в нашем случае всего 600мм. Стойка, кстати, российского бренда NTSS. По бокам есть Zero-U лотки для крепления PDU, но они недостаточно утоплены вглубь. Да и PDU достаточно жирные — APC 8886. Мы также попробовали установить родные PDU от NTSS, но проблему это не решило.

Уши на этих рельсах сделаны как единое целое и снять их невозможно. Чтобы вытащить свитч, необходимо сначала вытащить оба PDU. подобные свитчи достаточно тяжелые, поэтому для крепления в стойке рекомендуется использовать рельсы вместо ушей. Да и предполагалось что рельсы упростят работу с оборудованием, а не усложнят её :(

Что делать — непонятно. На ум приходит только спилить эти уши, но в таком случае свитчи уже будет невозможно прикрутить к стойке. Ставить свитчи вперёд тоже плохое решение, особенно с точки зрения кабель-менеджмента, да и потребуется заменить 18 блоков питания и 36 вентиляторов чтобы развернуть направление обдува :(

Также есть вариант с универсальными рельсами и полками, но это тоже так себе решение, которое потребует доработок.

Ставить горизонтальные PDU вместо вертикальных тоже не хотим, это усложнит кабель-менеджмент.

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

Самое печальное, по моему личному опыту, что в 99% случаев в аренду предлагают стойки шириной 600мм, не больше. А если хочешь шире — то разница в цене будет огромная, так как такая стойка занимает уже больше одной плитки. Да и в текущих реалиях ЦОДы забиты, мест для таких стоек крайне мало.

Что интересно, даже новые ЦОДы везде повально экономят на ширине стоек и ставят эти несчастные 600мм узкие стойки.

Как известно, основной глобальный инструмент для просмотра логов Certificate Transparency (CT-логов) через веб-интерфейс - это crt.sh. Однако сертификаты российских УЦ в глобальные логи пока не попадают (перечень принимаемых сертификатов и пресертификатов в CT-логе всегда ограничен некоторым набором корневых ключей). Для российских УЦ запущены российские CT-логи. Для просмотра российских CT-логов тоже есть сервисы с веб-интерфейсом:

• ct.tlscc.ru - это выделенный экземпляр crt.sh, поддерживаемый ТЦИ и настроенный на российские логи; веб-сайт использует TLS-сертификат, выпущенный от корня ТЦИ, так что если корня в браузере нет, то будет выдаваться предупреждение; (пример запроса);

• precert.ru - отдельный и весьма удобный сервис, имеющий целый ряд преимуществ: например, здесь другой интерфейс для поиска записей, подробная статистика по логам и УЦ; (пример запроса).

Сейчас в российские CT-логи добавляются сведения о сертификатах, выпускаемых НУЦ (все логи) и ТЦИ (логи "Яндекса" и VK). Основной объём логов составляют пресертификаты, которые добавляют сами УЦ, в процессе выпуска сертификата. Пресертификат отличается от сертификата наличием специального расширения (CT Poison), отсутствием SCT-меток и значением подписи. Обратите внимание, что сертификаты добавить в CT-лог может каждый. Например, можно добавить сертификат, найденный на каком-то веб-узле в Сети (если, конечно, сертификат выпущен подходящим УЦ). Но для добавления придётся уже воспользоваться HTTP-интерфейсом соответствующего лога напрямую, подготовив и отправив POST-запрос.

Зачем просматривать CT-логи? Во-первых, наличие сторон, изучающих записи в CT-логах, это основной декларируемый смысл Certificate Transparency. Во-вторых, просмотр логов позволяет пронаблюдать, что и для чего выпускается, и даже минимально контролировать выпуск сертификатов для тех доменов, которые вы администрируете; Certificate Transparency не гарантирует, что сведения о выпущенном сертификате будут в CT-логе, но такие сведения могут там быть, а сам по себе сертификат, благодаря наличию цифровой подписи, это какой-никакой, но документ, подтверждающий хотя бы свой собственный выпуск. В-третьих, в логах можно найти что-то неожиданное - для этого внимание нужно обращать на таймстемпы, на формат (пре)сертификатов, на состояние конкретных лог-сервисов.

В связи с интенсивным сокращением максимального срока действия TLS-сертификатов (пока что обещают 47 дней, но для всех и к 2030 году), коллеги саркастически поинтересовались, можно ли сделать так, чтобы сертификат выписывался на каждый TLS-запрос. Шутки - шутками, но сделать-то можно. И даже не требуется переделывать протокол TLS - есть готовое решение.

Если внимательно посмотреть на алгоритм TLS-хендшейка, то окажется, что секретный ключ, соответствующий открытому ключу из серверного сертификата, требуется там только один раз - для формирования подписи в сообщении CertificateVerify. Соответственно, секретного ключа от сертификата вообще может не быть на сервере, а сервер будет обращаться к некоторому подписывающему узлу, у которого этот ключ есть и который подтвердит TLS-сессию, подписав значение для CertificateVerify. Это вовсе не теоретическое рассуждение, именно так делается на практике, когда входящие соединения принимает прокси-провайдер (CDN, обычно), но передавать этому провайдеру секретные ключи от сертификатов для своих доменов клиент не желает. Первыми в промышленных масштабах такую услугу сделали в Cloudflare, более десяти лет назад. Называется Keyless SSL.

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

Сертификат, таким образом, окончательно превратится в безотзывный тикет доступа, мгновенного действия, а сервер будет привязан к центральному провайдеру (можно совместить с крупными CDN, у которых и так есть собственные хорошо известные УЦ). Проверку совпадения подписей, серверной и на сертификате, будет всё так же проводить браузер (речь, напомню, про веб). В браузере ничего не нужно переделывать совсем: если сервер не смог предъявить корректную подпись в CertificateVerify - TLS-сессия браузером установлена не будет.

Это, если что, была минутка технологического юмора. Но вот то, что развитие инфраструктуры TLS-сертификатов в вебе движется в сторону тикетов доступа (или, скорее, квитанций) - отрицать всё сложнее.

Пишут, что CA/B-форум согласовал дальнейшее сокращение интервала валидности TLS-сертификатов: теперь планируют к 2029 году уменьшить этот интервал до 47 дней. Ожидаемо. Я бы предположил, что ещё короче сделают (да и, фактически, раньше; например, Let's Encrypt уже готовит шестидневные сертификаты).

Тенденция коснётся и сертификатов, выпускаемых "собственными УЦ": если браузер принципиально не верит сертификатам только на основании длительности их интервала валидности, то не играет роли, был ли добавлен корневой ключ УЦ вручную или приехал в составе дистрибутива. (Технически, да, урезать действие ограничения для "домашних" сертификатов можно, но вряд ли имеет смысл на это рассчитывать.) Кроме того, строго автоматический выпуск сертификатов - требует наличия подходящего API на стороне УЦ, тоже немаловажный технологический фактор.

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

Чемпионат мира по метанию серверов на фестивале CloudFest-2025

CloudFest – ежегодный фестиваль интернет-индустрии и облачных вычислений, прошедший в Германии с 17 по 20 марта 2025 года и привлекший почти 9 тысяч посетителей. Мероприятие традиционно проводится в Европе-Парке в Шварцвальде и имеет достаточно насыщенную программу: 250 выступающих от 150 компаний-участников из 80 стран. Доклады, мастер-классы, новинки от гигантов индустрии, стартапы и проч. … но, по понятным причинам шоу-стоппером и гвоздем фестиваля стал чемпионат по метанию серверов – World Server Throwing Championship (WSTC). 

Метались серверы высотой 1U весом примерно 10 кг. (Говорят, можно даже было приносить свои серверы, но это не точно). Здесь всё как в большом спорте – громкие прозвища, например, Бартош-Зверь, Дирк-Машина, чемпионские пояса, анонсеры, чирлидерши и проч. 

В конкурсе принимали участие как мужчины, так и женщины – единственное требование к участникам – надеть перчатки дабы не поранить руки о края девайса и желание метать сервер %&#* далеко (орфография сохранена). 

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

Приводим ссылку на страницу соревнования и пару роликов:

Официальный ролик дополняет любительское видео.

Устроители шутят (или нет?) и поговаривают, что в будущем следует ожидать включение этого вида спорта в олимпийскую программу.

Комменты под видео в сети:

 - Надо биатлон устроить: Сначала пишут код, который выполняет какую-то полезную работу на сервере, подключенном только к ИБП. Потом метают ИБП и сервер. Результаты суммируют.

- Никогда не используйте сервер, который не сможете выбросить в окно.

- Там от сервера - одно название. Ни тебе процессора с кулером, ни Хардов, ни РАМы, ни рек-Маунт-китов.

- Честно говоря, это самое приятное мероприятие, которое я когда-либо видел. 

- Линукс знает, как падать. 

- Обычный день сисадмина.

Внимание, админы! Broadcom опять закручивает гайки и вводит штрафы задним числом для подписчиков VMware.

Как заговорить с сетевиками на одном языке? 😎

В Академии Selectel появился бесплатный курс «Погружение в компьютерные сети». Он поможет разобраться в принципах работы, понять ключевые термины и уверенно ориентироваться в основах. Всего час — и сложные вещи станут простыми.

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

Начните обучение в Академии Selectel прямо сейчас ➡️

Как сделать сервис быстрым и безопасным?

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

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

В Академии Selectel рассказываем, как компания:

• добилась 100% соответствия инфраструктуры 152-ФЗ и готовности к аттестации по требованиям ФСТЭК,

• сократила максимальное время загрузки страниц со стороны конечного пользователя до 1 секунды,

• стабильно работает при средней нагрузке 1 500 RPS.

Представим, что у нас некоторая система, состоящая из микросервисов, которые работают на разных машинах, но внутри общей IP-сети на немаршрутизируемых IP-адресах (10.0.0.0/8, 192.168.0.0/16 и т.д.). Микросервисы разговаривают друг с другом по TCP, подключаясь по IP-адресам, указанным в соответствующих конфигурационных файлах каждого. Но можно указать и не IP-адрес, а некий хостнейм, прописав его же в /etc/hosts. Почему-то часто считают, что "хостнейм эквивалентен IP-адресу". Оно, конечно, удобно так считать, с точки зрения "человекопонятности", но не всегда хорошо с точки зрения безопасной настройки.

Дело в том, что опечатка (или намеренная замена символа) в имени хоста может привести к тому, что адрес окажется в чужой DNS-зоне. Простейший случай: users-db.example.com -> users-db.example.co. Да, должно быть закрыто, да, есть .local, а хостнеймы можно записывать одним "лейблом", но это не решает проблему: использование символьного хостнейма гарантирует дополнительные запросы для разрешения имён, будь то локальные запросы на той же машине или запросы внешние, возникшие из-за опечатки. А всякий, даже локальный, библиотечный/системный вызов, выполняющий трансляцию имён и адресов, готов принести с собой неожиданные эффекты (см. ниже пример уже про IP-адреса). Не обязательно это эффекты от подмены библиотеки или подмены конкретного вызова. А если кто-то умеет записывать в /etc/hosts, то он и конфиг любой поправит. Что, впрочем, не всегда так, поскольку раскладывание hosts по машинам могут автоматизировать - тогда перехватить нужно только точку управления скриптом, формирующим файл. А ведь ещё обычно используется два протокола: v6 и v4, адреса и "резолвинг" там разные.

Если в конфигах микросервисов прописывать непосредственно IP-адреса (пусть и автоматом), то ситуация несколько лучше. Есть неплохие шансы, что трансляция имён/адресов не будет использована. Минимальная опечатка в записи немаршрутизируемого адреса реже приводит к тому, что трафик убегает наружу. Это так потому, что, во-первых, на то они и немаршрутизируемые; во-вторых, в таких системах обычно настраивают различные ACL, а они настраиваются для IP, в других местах, не на конкретной машине с микросервисом, да и пальцы у настраивающих ACL дрожат по-иному.

Тут, впрочем, необходимо отметить некоторые тонкости: ping 010.010.010.010 -- на многих и многих системах отправит пакеты в сторону серверов Google (проверьте). Я раньше рекомендовал использовать этот довольно хитрый "оборот" в рамках собеседований на должность сетевого инженера/разработчика (теперь уже смысла, понятно, нет), поскольку понимание того, почему здесь пакеты уходят в сторону сети Google, раскрывает основную часть опасений, связанных с использованием имён хостов в конфигах. Но всё же, в 010.010.010.010 - более одной "опечатки".