Легкий мониторинг
Коллеги часто спрашивают что-нибудь простое для мониторинга небольшой инфраструктуры.
Действительно, не везде нужны такие монстры как Zabbix, поэтому расскажем о нескольких простых инструментах.
Начнем с nmon, он не является мониторингом в прямом смысле этого слова, а ближе к таким утилитам как htop, iotop, ifstat и т.д. Это удобная утилита начальной диагностики и мониторинга показателей в режиме реального времени.
Главное преимущество этой утилиты – ее необычайная гибкость, мы можем в режиме реального времени собирать на экране нужные наборы модулей чтобы отслеживать взаимовлияющие показатели и параметры.
Т.е. вместо нескольких утилит использовать одну. Это удобно и быстро позволяет выявить проблемные места и аномалии.
🔹 Простой и удобный инструмент мониторинга производительности – nmon
Для небольших инсталляций и отдельных узлов можно посоветовать Monitorix – очень легкую систему мониторинга, который может использоваться даже на слабых VPS и встраиваемых компьютерах.
Но в тоже время он умеет практически все, что должен уметь мониторинг: собирать и отображать данные, отслеживать триггеры и посылать уведомления.
Для контроля нескольких узлов придется установить Monitorix на каждый из них, однако есть возможность просматривать данные в единственном месте.
🔹 Monitorix - простой и легкий мониторинг для Linux
Для более сложных систем есть простое централизованное решение – Munin. Он также нетребователен к ресурсам, но работает по клиент-серверной схеме.
За сбор информации отвечают клиенты с необходимым набором плагинов, а вся информация собирается и хранится на сервере. Благодаря наличию плагинов вы можете реализовать практически любую функциональность в тоже время не перегружая систему.
🔹 Устанавливаем и настраиваем систему мониторинга Munin
Что выбрать? Смотрите сами, но имейте ввиду, что мониторинг – это не только большие монстры, но и гораздо более простые и легкие решения, которые можно развернуть прямо сейчас.
Коллеги часто спрашивают что-нибудь простое для мониторинга небольшой инфраструктуры.
Действительно, не везде нужны такие монстры как Zabbix, поэтому расскажем о нескольких простых инструментах.
Начнем с nmon, он не является мониторингом в прямом смысле этого слова, а ближе к таким утилитам как htop, iotop, ifstat и т.д. Это удобная утилита начальной диагностики и мониторинга показателей в режиме реального времени.
Главное преимущество этой утилиты – ее необычайная гибкость, мы можем в режиме реального времени собирать на экране нужные наборы модулей чтобы отслеживать взаимовлияющие показатели и параметры.
Т.е. вместо нескольких утилит использовать одну. Это удобно и быстро позволяет выявить проблемные места и аномалии.
🔹 Простой и удобный инструмент мониторинга производительности – nmon
Для небольших инсталляций и отдельных узлов можно посоветовать Monitorix – очень легкую систему мониторинга, который может использоваться даже на слабых VPS и встраиваемых компьютерах.
Но в тоже время он умеет практически все, что должен уметь мониторинг: собирать и отображать данные, отслеживать триггеры и посылать уведомления.
Для контроля нескольких узлов придется установить Monitorix на каждый из них, однако есть возможность просматривать данные в единственном месте.
🔹 Monitorix - простой и легкий мониторинг для Linux
Для более сложных систем есть простое централизованное решение – Munin. Он также нетребователен к ресурсам, но работает по клиент-серверной схеме.
За сбор информации отвечают клиенты с необходимым набором плагинов, а вся информация собирается и хранится на сервере. Благодаря наличию плагинов вы можете реализовать практически любую функциональность в тоже время не перегружая систему.
🔹 Устанавливаем и настраиваем систему мониторинга Munin
Что выбрать? Смотрите сами, но имейте ввиду, что мониторинг – это не только большие монстры, но и гораздо более простые и легкие решения, которые можно развернуть прямо сейчас.
👍25👀2
А что именно мы мониторим?
Очень часто внедрения системы мониторинга заканчивается тем, что она начинает тихо пылиться где-то на забытой всеми виртуалке, пока не будет отключена совсем.
На вопрос почему такие пользователи обычно отвечают, что все равно от нее нет особого толка.
И это действительно так, если вы не уделили системе мониторинга особого внимания и не настроили какие именно параметры вы хотите контролировать, а также не задали подходящие именно вам пороговые значения – толку от нее действительно не будет.
Любая система мониторинга имеет некоторые настроенные из коробки метрики и триггеры, где-то больше, где-то меньше, но все они рассчитаны на некий сферический сервер в вакууме и использовать без адаптации можно разве что триггеры, срабатывающие на предельных значениях.
Но сообщение о выходе параметров за эти значения равносильны звонку в экстренные службы, если раньше вам об этом не сообщат пользователи или руководство в три часа ночи.
А вот остальные значения нуждаются в серьезном тюнинге. Например, у Zabbix из коробки есть два триггера на дисковое пространство: низкое – 80% и критически низкое – 90%.
Если взять диск объемом в 4 ТБ, то эти значения получатся на уровне 3,2 и 3,6 ТБ, в первом случае у нас еще остается почти целый терабайт и можно спокойно работать несмотря на предупреждение. А при «критическом» срабатывании останется 400 ГБ, что при большинстве сценариев будет еще вполне достаточно на долгое время.
А теперь возьмем SSD 120 ГБ, 80% — это 96 ГБ, а 90 – уже 108 ГБ. Т.е. всего 12 ГБ между уровнями срабатывания и столько же еще в резерве. При интенсивной записи мы можем исчерпать такой размер за считанные минуты.
Поэтому что в том, что в другом случае параметры срабатывания триггеров надо откорректировать согласно фактическому положению дел. Иначе такие предупреждения скоро замылят глаз и перестанут восприниматься как серьезные, что может сыграть злую шутку при реальном недостатке места в системе.
Но сам по себе сервер не представляет такой ценности, как запущенные на нем приложения и часто можно столкнуться с ситуацией, когда сервер сам по себе не выходит за рамки контрольных показателей, а приложение работает из рук вон плохо.
Можно, конечно, найти стандартный шаблон для приложения и радоваться, только вот чему?
Стандартный шаблон он тоже для сферического приложения в вакууме и без адаптации будет практически негоден.
Скажем, если у вас веб-сервер на дешевом-дешевом VPS, то вы можете никогда не дождаться срабатывания триггера на большое число запросов, так как сервер ляжет гораздо раньше.
Многие показатели могут иметь разлет значений на порядок, а то и несколько, скажем критическую нагрузку по IO для HDD средний SSD спокойно переварит, а для NVMе это будут вообще какие-то незначительные цифры.
И это касается очень и очень многого. При том, что никаких общих рекомендаций, мол поставь сюда такую цифру, а сюда такую дать нельзя, все достаточно индивидуально. Поэтому для корректной работы любого шаблона вам придется изучить что отражают все собираемые им метрики и как рассчитать их нормальные и предельные значения для каждого конкретного случая.
Сложно? Ну как сказать, если вы понимаете принцип работы приложения – то не очень, а иначе – придется углубиться в теорию. Но без этого никак, даже не касаясь систем мониторинга без данных знаний вы не сможете нормально эксплуатировать систему.
Или на вопросы пользователей: «Почему тормозит продукт NAME?», будете отвечать: «Ну это же продукт NAME». Но, согласитесь, такой подход не красит специалиста.
При этом нам известны и иные случаи, когда внедрив мониторинг и углубившись в изучение метрик и их влияния на общий результат коллеги серьезно подтягивали производительность которая начинала быть видимой буквально невооруженным глазом.
Поэтому, собираясь внедрять систему мониторинга приготовьтесь углубиться в подробности эксплуатации используемых программных продуктов и показателей, влияющих на их производительность.
Очень часто внедрения системы мониторинга заканчивается тем, что она начинает тихо пылиться где-то на забытой всеми виртуалке, пока не будет отключена совсем.
На вопрос почему такие пользователи обычно отвечают, что все равно от нее нет особого толка.
И это действительно так, если вы не уделили системе мониторинга особого внимания и не настроили какие именно параметры вы хотите контролировать, а также не задали подходящие именно вам пороговые значения – толку от нее действительно не будет.
Любая система мониторинга имеет некоторые настроенные из коробки метрики и триггеры, где-то больше, где-то меньше, но все они рассчитаны на некий сферический сервер в вакууме и использовать без адаптации можно разве что триггеры, срабатывающие на предельных значениях.
Но сообщение о выходе параметров за эти значения равносильны звонку в экстренные службы, если раньше вам об этом не сообщат пользователи или руководство в три часа ночи.
А вот остальные значения нуждаются в серьезном тюнинге. Например, у Zabbix из коробки есть два триггера на дисковое пространство: низкое – 80% и критически низкое – 90%.
Если взять диск объемом в 4 ТБ, то эти значения получатся на уровне 3,2 и 3,6 ТБ, в первом случае у нас еще остается почти целый терабайт и можно спокойно работать несмотря на предупреждение. А при «критическом» срабатывании останется 400 ГБ, что при большинстве сценариев будет еще вполне достаточно на долгое время.
А теперь возьмем SSD 120 ГБ, 80% — это 96 ГБ, а 90 – уже 108 ГБ. Т.е. всего 12 ГБ между уровнями срабатывания и столько же еще в резерве. При интенсивной записи мы можем исчерпать такой размер за считанные минуты.
Поэтому что в том, что в другом случае параметры срабатывания триггеров надо откорректировать согласно фактическому положению дел. Иначе такие предупреждения скоро замылят глаз и перестанут восприниматься как серьезные, что может сыграть злую шутку при реальном недостатке места в системе.
Но сам по себе сервер не представляет такой ценности, как запущенные на нем приложения и часто можно столкнуться с ситуацией, когда сервер сам по себе не выходит за рамки контрольных показателей, а приложение работает из рук вон плохо.
Можно, конечно, найти стандартный шаблон для приложения и радоваться, только вот чему?
Стандартный шаблон он тоже для сферического приложения в вакууме и без адаптации будет практически негоден.
Скажем, если у вас веб-сервер на дешевом-дешевом VPS, то вы можете никогда не дождаться срабатывания триггера на большое число запросов, так как сервер ляжет гораздо раньше.
Многие показатели могут иметь разлет значений на порядок, а то и несколько, скажем критическую нагрузку по IO для HDD средний SSD спокойно переварит, а для NVMе это будут вообще какие-то незначительные цифры.
И это касается очень и очень многого. При том, что никаких общих рекомендаций, мол поставь сюда такую цифру, а сюда такую дать нельзя, все достаточно индивидуально. Поэтому для корректной работы любого шаблона вам придется изучить что отражают все собираемые им метрики и как рассчитать их нормальные и предельные значения для каждого конкретного случая.
Сложно? Ну как сказать, если вы понимаете принцип работы приложения – то не очень, а иначе – придется углубиться в теорию. Но без этого никак, даже не касаясь систем мониторинга без данных знаний вы не сможете нормально эксплуатировать систему.
Или на вопросы пользователей: «Почему тормозит продукт NAME?», будете отвечать: «Ну это же продукт NAME». Но, согласитесь, такой подход не красит специалиста.
При этом нам известны и иные случаи, когда внедрив мониторинг и углубившись в изучение метрик и их влияния на общий результат коллеги серьезно подтягивали производительность которая начинала быть видимой буквально невооруженным глазом.
Поэтому, собираясь внедрять систему мониторинга приготовьтесь углубиться в подробности эксплуатации используемых программных продуктов и показателей, влияющих на их производительность.
👍31❤1🌭1
👍9
Онлайн-марафон по программированию от экспертов Хекслета, VK, Альфа-Банка, OneTwoTrip, Dualboot Partners.
IT-Start: с 0 до выбора профессии за 3 дня.
⏰ Когда: 20-22 марта в 19:00 мск.
✔️Расскажем о преимуществах и подводных камнях профессии “разработчик”.
✔️Рассмотрим востребованне направления в программировании: Python и Java, PHP и Frontend, поговорим с Кириллом Мокевниным (co-founder Хекслет).
✔️Обсудим, какие факты о программировании правда, а какие выдумка. Покажем реальную картину в сфере ИТ сегодня.
Участники смогут задать все интересующие вопросы программистам с многолетним стажем.
IT-Start: с 0 до выбора профессии за 3 дня.
⏰ Когда: 20-22 марта в 19:00 мск.
✔️Расскажем о преимуществах и подводных камнях профессии “разработчик”.
✔️Рассмотрим востребованне направления в программировании: Python и Java, PHP и Frontend, поговорим с Кириллом Мокевниным (co-founder Хекслет).
✔️Обсудим, какие факты о программировании правда, а какие выдумка. Покажем реальную картину в сфере ИТ сегодня.
Участники смогут задать все интересующие вопросы программистам с многолетним стажем.
👌1
The Dude
Во вчерашней заметке о простых системах мониторинга мы не упомянули Dude и сделали это вполне сознательно.
Это отдельный продукт от компании Mikrotik, рассчитанный в первую очередь на работу с оборудованием этого производителя. И если ваша сеть построена на основе продуктов Mikrotik, то Dude придется вам ко двору.
Продукт имеет свою специфику – прежде всего это мониторинг именно сети, кроме того, он умеет собирать данные хостов по SNMP и при желании вы сможете настроить любые метрики, которые можно получить данным способом.
Поэтому Dude не заменяет другие системы мониторинга, но оказывается очень полезным, когда надо беглым взглядом окинуть инфраструктуру и посмотреть все ли везде в порядке. А если нужны подробности, то можно будет обратиться уже к более серьезным системам мониторинга.
Как установить и настроить Dude рассказано в нашей статье:
🔹 The Dude. Установка и быстрое начало работы
Также с его помощью можно организовать централизованный сбор логов, пусть простой, даже скажем – примитивный. Но во многих случаях это будет лучше чем ничего:
🔹 Централизованный сбор логов Mikrotik на сервер The Dude
А пользователи Mikrotik могут воспользоваться специальными функциями для этого оборудования, самой полезной из которых будет централизованное обновление:
🔹 Централизованное управление обновлением RouterOS при помощи The Dude
Во вчерашней заметке о простых системах мониторинга мы не упомянули Dude и сделали это вполне сознательно.
Это отдельный продукт от компании Mikrotik, рассчитанный в первую очередь на работу с оборудованием этого производителя. И если ваша сеть построена на основе продуктов Mikrotik, то Dude придется вам ко двору.
Продукт имеет свою специфику – прежде всего это мониторинг именно сети, кроме того, он умеет собирать данные хостов по SNMP и при желании вы сможете настроить любые метрики, которые можно получить данным способом.
Поэтому Dude не заменяет другие системы мониторинга, но оказывается очень полезным, когда надо беглым взглядом окинуть инфраструктуру и посмотреть все ли везде в порядке. А если нужны подробности, то можно будет обратиться уже к более серьезным системам мониторинга.
Как установить и настроить Dude рассказано в нашей статье:
🔹 The Dude. Установка и быстрое начало работы
Также с его помощью можно организовать централизованный сбор логов, пусть простой, даже скажем – примитивный. Но во многих случаях это будет лучше чем ничего:
🔹 Централизованный сбор логов Mikrotik на сервер The Dude
А пользователи Mikrotik могут воспользоваться специальными функциями для этого оборудования, самой полезной из которых будет централизованное обновление:
🔹 Централизованное управление обновлением RouterOS при помощи The Dude
👍26❤1👌1
Развертывание The Dude
Основным вопросом, после того как вы решили внедрить у себя Dude будет как и куда его установить.
Здесь есть разные варианты, The Dude поддерживает следующие архитектуры:
🔹 TILE devices
🔹 ARM devices
🔹 MMIPS devices
🔹 RouterOS x86
🔹 RouterOS CHR
Обратите внимание, что вам подойдут только те устройства, в которых можно расширить память одним из следующих образов: M.2/MiniPCI-e/Memory card/USB
Таким образом из MMIPS вам подойдут только hEX и hEX S, среди ARM устройств список больше, начиная с RB3011UIAS-RM и hAP ac2, главное – возможность расширить память.
Официальные рекомендации вендора следующие:
🔶 Небольшие инсталляции: < 200 устройств
🔸 hEX (RB750Gr3) с microSD card 16/32GB
🔸 Виртуальная машина 1 vCPU, 512MB RAM, 10GB VHD
🔶 Средние инсталляции: 200 - 500 устройств
🔸 RB1100AHx4 Dude Edition с установленным 60GB SSD
🔸 Виртуальная машина 2 vCPU, 2GB RAM, 20GB VHD
🔶 Крупные инсталляции: > 500 devices
🔸 RB1100AHx4 Dude Edition с установленным 60GB SSD
🔸 TILE based device со слотом M.2 для SSD
🔸 Виртуальная машина 4 vCPU, 4GB RAM, 40GB VHD
Но в целом мы не рекомендуем устанавливать The Dude на устройства, сделав выбор в пользу виртуальной машины. Такой вариант обладает большей гибкостью и переносимостью, а также позволяет легко масштабироваться.
В виртуальной среде можно запустить как RouterOS x86, так и RouterOS CHR, разницы между ними нет – это одна и та же система, все различия в лицензировании.
Для новых установок мы однозначно рекомендуем RouterOS CHR, что это такое и с чем его едят мы рассказывали в нашей статье:
🔹 Mikrotik CHR - виртуальный облачный роутер
Несмотря на прошедшие со времени написания статьи изменения лицензии на CHR все еще доступны для покупки и их цена остается все еще приемлемой.
Установить RouterOS CHR на виртуальную машину в целом несложно. Все что вам потребуется – это создать виртуалку с нужными параметрами и подключить к ней скачанный образ диска CHR, возможно перед этим его придется конвертировать в нужный формат.
Чтобы облегчить этот процесс мы написали скрипт для популярной системы виртуализации Proxmox:
🔹 Установка Mikrotik CHR на виртуальную машину Proxmox
Затем на установленную виртуальную машину вам потребуется установить пакет The Dude, который доступен в наборе Extra packages.
Основным вопросом, после того как вы решили внедрить у себя Dude будет как и куда его установить.
Здесь есть разные варианты, The Dude поддерживает следующие архитектуры:
🔹 TILE devices
🔹 ARM devices
🔹 MMIPS devices
🔹 RouterOS x86
🔹 RouterOS CHR
Обратите внимание, что вам подойдут только те устройства, в которых можно расширить память одним из следующих образов: M.2/MiniPCI-e/Memory card/USB
Таким образом из MMIPS вам подойдут только hEX и hEX S, среди ARM устройств список больше, начиная с RB3011UIAS-RM и hAP ac2, главное – возможность расширить память.
Официальные рекомендации вендора следующие:
🔶 Небольшие инсталляции: < 200 устройств
🔸 hEX (RB750Gr3) с microSD card 16/32GB
🔸 Виртуальная машина 1 vCPU, 512MB RAM, 10GB VHD
🔶 Средние инсталляции: 200 - 500 устройств
🔸 RB1100AHx4 Dude Edition с установленным 60GB SSD
🔸 Виртуальная машина 2 vCPU, 2GB RAM, 20GB VHD
🔶 Крупные инсталляции: > 500 devices
🔸 RB1100AHx4 Dude Edition с установленным 60GB SSD
🔸 TILE based device со слотом M.2 для SSD
🔸 Виртуальная машина 4 vCPU, 4GB RAM, 40GB VHD
Но в целом мы не рекомендуем устанавливать The Dude на устройства, сделав выбор в пользу виртуальной машины. Такой вариант обладает большей гибкостью и переносимостью, а также позволяет легко масштабироваться.
В виртуальной среде можно запустить как RouterOS x86, так и RouterOS CHR, разницы между ними нет – это одна и та же система, все различия в лицензировании.
Для новых установок мы однозначно рекомендуем RouterOS CHR, что это такое и с чем его едят мы рассказывали в нашей статье:
🔹 Mikrotik CHR - виртуальный облачный роутер
Несмотря на прошедшие со времени написания статьи изменения лицензии на CHR все еще доступны для покупки и их цена остается все еще приемлемой.
Установить RouterOS CHR на виртуальную машину в целом несложно. Все что вам потребуется – это создать виртуалку с нужными параметрами и подключить к ней скачанный образ диска CHR, возможно перед этим его придется конвертировать в нужный формат.
Чтобы облегчить этот процесс мы написали скрипт для популярной системы виртуализации Proxmox:
🔹 Установка Mikrotik CHR на виртуальную машину Proxmox
Затем на установленную виртуальную машину вам потребуется установить пакет The Dude, который доступен в наборе Extra packages.
👍24
20 марта ИТ руководители ADV Group, Сталепромышленная компания и M1Cloud поделятся практическим опытом построения индивидуальных решений облачной ИТ-инфраструктуры.
На вебинаре спикеры поделятся опытом кастомизации облака под особые требования ИТ и бизнеса в сфере:
- производительности вычислительных ресурсов
- сетевой связанности
- информационной безопасности
- отказоустойчивых DR-решений
- мониторинга и др.
Приглашаем на вебинар всех, кто отвечает за ИТ-инфраструктуру и рассматривает индивидуальные облачные решения.
Участие бесплатное.
Посмотреть программу и зарегистрироваться
Реклама. ООО "СТЕК ГРУПП". ИНН 7729739360.
На вебинаре спикеры поделятся опытом кастомизации облака под особые требования ИТ и бизнеса в сфере:
- производительности вычислительных ресурсов
- сетевой связанности
- информационной безопасности
- отказоустойчивых DR-решений
- мониторинга и др.
Приглашаем на вебинар всех, кто отвечает за ИТ-инфраструктуру и рассматривает индивидуальные облачные решения.
Участие бесплатное.
Посмотреть программу и зарегистрироваться
Реклама. ООО "СТЕК ГРУПП". ИНН 7729739360.
👍2
Обновление ОС Альт Сервер 10.2 и Альт Рабочая станция 10.2
Буквально на днях, 13 марта компания Базальт СПО выпустила сообщение о выходе новых версий своих основных продуктов Альт Сервер и Альт Рабочая станция, которые получили очередное обновления в рамках платформы 10.
Для Рабочей станции изменений не много, самым важным из них является профиль для установки на btrfs с подтомами для поддержки timeshift.
Также добавлен репозиторий для установки Р7-Офис.
А вот для Альт Сервер изменений гораздо больше, разработчики проанализировали основные сценарии использования и подготовили новый набор профилей при установке, теперь доступны:
▫️Офисный сервер
▫️Сервер Samba-DC (контроллер домена Active Directory)
▫️Домашний сервер
▫️Минимальная установка.
Для роли Домашнего сервера автоматически устанавливается графическая оболочка MATE.
Также оптимизирована работа с сетью и улучшена поддержка оборудования, в том числе и в среде восстановления.
Но самое важное изменение коснулось лицензионной политики:
1.5. Настоящим договором не предусмотрено предоставление прав на использование дистрибутива в качестве хоста виртуализации. При необходимости использовать данную функцию, нужно приобрести лицензию на «Альт Виртуализация».
Хост виртуализации — сервер, предоставляющий сервис доступа к виртуальным машинам и/или контейнерам.
При нарушении данного условия ООО «Базальт СПО» не оказывает техническую поддержку ДИСТРИБУТИВА, а лицензионный договор на такой ДИСТРИБУТИВ считается незаключенным, если иное не указано в письменном соглашении сторон.
Таким образом легальной возможности использовать сборку Proxmox от Альта на базе Альт Сервер больше нет. Хотя все еще остается возможность использовать для этого Стартовый набор (Starterkit), но в этом случае про Реестр и техподдержку можно сразу забыть.
При этом лицензия не допускает разночтений, хотя на некоторых ресурсах пишут, что мол можно установить, но не будет поддержки, потому как четко указано, что при нарушении п. 1.5 лицензионное соглашение считается незаключенным, что лишает вас права легально использовать такой экземпляр ОС.
Буквально на днях, 13 марта компания Базальт СПО выпустила сообщение о выходе новых версий своих основных продуктов Альт Сервер и Альт Рабочая станция, которые получили очередное обновления в рамках платформы 10.
Для Рабочей станции изменений не много, самым важным из них является профиль для установки на btrfs с подтомами для поддержки timeshift.
Также добавлен репозиторий для установки Р7-Офис.
А вот для Альт Сервер изменений гораздо больше, разработчики проанализировали основные сценарии использования и подготовили новый набор профилей при установке, теперь доступны:
▫️Офисный сервер
▫️Сервер Samba-DC (контроллер домена Active Directory)
▫️Домашний сервер
▫️Минимальная установка.
Для роли Домашнего сервера автоматически устанавливается графическая оболочка MATE.
Также оптимизирована работа с сетью и улучшена поддержка оборудования, в том числе и в среде восстановления.
Но самое важное изменение коснулось лицензионной политики:
1.5. Настоящим договором не предусмотрено предоставление прав на использование дистрибутива в качестве хоста виртуализации. При необходимости использовать данную функцию, нужно приобрести лицензию на «Альт Виртуализация».
Хост виртуализации — сервер, предоставляющий сервис доступа к виртуальным машинам и/или контейнерам.
При нарушении данного условия ООО «Базальт СПО» не оказывает техническую поддержку ДИСТРИБУТИВА, а лицензионный договор на такой ДИСТРИБУТИВ считается незаключенным, если иное не указано в письменном соглашении сторон.
Таким образом легальной возможности использовать сборку Proxmox от Альта на базе Альт Сервер больше нет. Хотя все еще остается возможность использовать для этого Стартовый набор (Starterkit), но в этом случае про Реестр и техподдержку можно сразу забыть.
При этом лицензия не допускает разночтений, хотя на некоторых ресурсах пишут, что мол можно установить, но не будет поддержки, потому как четко указано, что при нарушении п. 1.5 лицензионное соглашение считается незаключенным, что лишает вас права легально использовать такой экземпляр ОС.
👍9🤔6❤1
Облака – говорили они. Microsoft, Amazon и Google прекращают доступ к облачным сервисам с 20 марта
Microsoft отправила российским компаниям письмо о том, что c 20 марта 2024 года закроет доступ к своим облачным продуктам. Информацию о письме подтвердили в ГК Softline, а также сообщили о получении аналогичной информации и от Amazon.
В связи с этим ГК Softline предупреждает о возможных функциональных ограничениях в работе облачных продуктов и сервисов Microsoft, Amazon и Google
Поспешим успокоить, речь пока не идет об обычных облачных решениях, а касается в первую очередь программного обеспечения для управления или проектирования (включая облачные решения) в связи с новыми санкциями ЕС.
У Microsoft это, например, Power BI и Dynamics CRM, при этом формулировка в направленных письмах носит размытый характер: включая, но не ограничиваясь.
Но мы бы не советовали расслабляться, если вы используете западные облачные сервисы, то совершенно не лишним будет сделать резервные копии размещенных там данных, а также продумать возможный переезд на отечественные аналоги или собственные вычислительные мощности.
Microsoft отправила российским компаниям письмо о том, что c 20 марта 2024 года закроет доступ к своим облачным продуктам. Информацию о письме подтвердили в ГК Softline, а также сообщили о получении аналогичной информации и от Amazon.
В связи с этим ГК Softline предупреждает о возможных функциональных ограничениях в работе облачных продуктов и сервисов Microsoft, Amazon и Google
Поспешим успокоить, речь пока не идет об обычных облачных решениях, а касается в первую очередь программного обеспечения для управления или проектирования (включая облачные решения) в связи с новыми санкциями ЕС.
У Microsoft это, например, Power BI и Dynamics CRM, при этом формулировка в направленных письмах носит размытый характер: включая, но не ограничиваясь.
Но мы бы не советовали расслабляться, если вы используете западные облачные сервисы, то совершенно не лишним будет сделать резервные копии размещенных там данных, а также продумать возможный переезд на отечественные аналоги или собственные вычислительные мощности.
🤣25👍13🔥7🤯3
Каких поставщиков облачных решений вы используете?
Anonymous Poll
12%
В основном зарубежных
15%
В основном отечественных
4%
Примерно пополам
19%
В основном собственные сервисы
3%
Переходим на отечественные
4%
Переходим на собственные
0%
Свой вариант ответа (в комментариях)
7%
Ничего не понятно, но очень интересно
35%
Не используем облака вообще
erid: LjN8KXuRA
Как эффективно разделять приложения на микросервисы?
🔥 Расскажет Евгений Непомнящий — разработчик в IT Sense.
Встречаемся на бесплатном практическом уроке от OTUS, где вы вместе с опытным экспертом:
- рассмотрите принципы функциональной декомпозиции;
- научитесь выделять отдельные компоненты приложения;
- погрузитесь в методику EventStorming;
- изучите подход API First Design;
- узнаете, как разрабатывать API.
Встречаемся 19 марта в 20:00 мск в рамках курса «Software Architect». Доступна рассрочка на обучение!
👉 Зарегистрируйтесь, чтобы посетить бесплатный урок и получить запись.
Как эффективно разделять приложения на микросервисы?
🔥 Расскажет Евгений Непомнящий — разработчик в IT Sense.
Встречаемся на бесплатном практическом уроке от OTUS, где вы вместе с опытным экспертом:
- рассмотрите принципы функциональной декомпозиции;
- научитесь выделять отдельные компоненты приложения;
- погрузитесь в методику EventStorming;
- изучите подход API First Design;
- узнаете, как разрабатывать API.
Встречаемся 19 марта в 20:00 мск в рамках курса «Software Architect». Доступна рассрочка на обучение!
👉 Зарегистрируйтесь, чтобы посетить бесплатный урок и получить запись.
Особенности использования аппаратных ключей HASP для 1С:Предприятие
Несмотря на то, что ключи HASP более недоступны для покупки у пользователей системы 1С:Предприятие осталось на руках еще достаточно ключей, поэтому информация о их применении остается актуальной.
Бытует мнение, что аппаратные ключи проще и удобнее программных лицензий, однако это не так, у них есть свои особенности и ограничения. Далее мы будем говорить о многопользовательских ключах серии ORGL8, которые поставлялись в вариантах на 5, 10, 20, 50 и 100 лицензий.
Также еще есть ключи серий ORG8A и ORG8B на 300 и 500 лицензий.
Начнем с того, что несколько ключей одной серии не могут быть размещены вместе на одном узле и поэтому вам придется разносить их по разным ПК.
Дальнейшее поведение зависит от того, кто и как получает лицензию с этого ключа. Клиентское приложение при запуске в первую очередь ищет в сети службу HASP License Manager и пытается получить лицензию с ее помощью.
В этом случае ему выдается однопользовательская лицензия и он может запустить неограниченное количество сеансов информационных баз.
При использовании в сети нескольких ключей их желательно явно прописать в nethasp.ini примерно следующим образом:
Если службы HASP LM не найдены или обслуживаемый ими ключ не содержит свободных лицензий, то клиент попытается получить лицензии с сервера или веб-сервера, которые выдают их на сеанс.
Эта особенность часто приводит к сильному перерасходу лицензий в случае возникновения каких-либо сетевых проблем, когда клиенты перестают видеть службу HASP LM, а сервер продолжает иметь к ней доступ, либо ключ установлен на нем локально.
И самое интересное, это взаимодействие с сетевыми ключами сервера или веб-сервера 1С:Предприятие.
В первую очередь сервер ищет локальный ключ и начинает выдавать лицензии из него. По их исчерпании он начинает поиск сетевых ключей, работающих через HASP LM.
Но если в сети находятся несколько ключей, то сервер случайным образом выбирает один из них, дальнейший поиск ключей одной серии не производится.
Таким образом если лицензии на выбранном сетевом ключе будут исчерпаны сервер прекратит выдачу лицензий несмотря на то, что в сети есть еще ключи со свободными лицензиями.
Вместо этого сервер будет производить поиск ключей серий ORG8A и ORG8B, также по одному ключу каждого типа.
Все эти особенности делают использование аппаратных ключей не такой уж простой задачей и заставляют ответственно подходить к планированию инфраструктуры с их использованием.
Несмотря на то, что ключи HASP более недоступны для покупки у пользователей системы 1С:Предприятие осталось на руках еще достаточно ключей, поэтому информация о их применении остается актуальной.
Бытует мнение, что аппаратные ключи проще и удобнее программных лицензий, однако это не так, у них есть свои особенности и ограничения. Далее мы будем говорить о многопользовательских ключах серии ORGL8, которые поставлялись в вариантах на 5, 10, 20, 50 и 100 лицензий.
Также еще есть ключи серий ORG8A и ORG8B на 300 и 500 лицензий.
Начнем с того, что несколько ключей одной серии не могут быть размещены вместе на одном узле и поэтому вам придется разносить их по разным ПК.
Дальнейшее поведение зависит от того, кто и как получает лицензию с этого ключа. Клиентское приложение при запуске в первую очередь ищет в сети службу HASP License Manager и пытается получить лицензию с ее помощью.
В этом случае ему выдается однопользовательская лицензия и он может запустить неограниченное количество сеансов информационных баз.
При использовании в сети нескольких ключей их желательно явно прописать в nethasp.ini примерно следующим образом:
[NH_TCPIP]
NH_SERVER_ADDR = 192.168.111.10, 192.168.111.11
NH_SERVER_NAME = HASP_LM1, HASP_LM2
Если службы HASP LM не найдены или обслуживаемый ими ключ не содержит свободных лицензий, то клиент попытается получить лицензии с сервера или веб-сервера, которые выдают их на сеанс.
Эта особенность часто приводит к сильному перерасходу лицензий в случае возникновения каких-либо сетевых проблем, когда клиенты перестают видеть службу HASP LM, а сервер продолжает иметь к ней доступ, либо ключ установлен на нем локально.
И самое интересное, это взаимодействие с сетевыми ключами сервера или веб-сервера 1С:Предприятие.
В первую очередь сервер ищет локальный ключ и начинает выдавать лицензии из него. По их исчерпании он начинает поиск сетевых ключей, работающих через HASP LM.
Но если в сети находятся несколько ключей, то сервер случайным образом выбирает один из них, дальнейший поиск ключей одной серии не производится.
Таким образом если лицензии на выбранном сетевом ключе будут исчерпаны сервер прекратит выдачу лицензий несмотря на то, что в сети есть еще ключи со свободными лицензиями.
Вместо этого сервер будет производить поиск ключей серий ORG8A и ORG8B, также по одному ключу каждого типа.
Все эти особенности делают использование аппаратных ключей не такой уж простой задачей и заставляют ответственно подходить к планированию инфраструктуры с их использованием.
👍22
Программные и аппаратные лицензии 1С, сходства и различия.
Комментарии к предыдущей заметке показали, что многие читатели не до конца представляют все различия между двумя типами лицензий и подвержены многим предрассудкам и заблуждениям.
Начнем с того, что в основе лицензионной политики 1С, как это ни странно, лежит ЛИЦЕНЗИЯ.
Лицензия может быть однопользовательской, которая позволяет запускать неограниченное число сеансов 1С на одном ПК. Точнее в рамках одной пользовательской сессии, поэтому они так и называются – однопользовательские.
А для терминального сервера вам понадобится по одной однопользовательской лицензии на каждый сеанс пользователя.
Важно понимать, что однопользовательскую лицензию получает сам компьютер и неважно как он это делает.
Второй вид лицензий – многопользовательские, их выдает исключительно сервер и/или веб-сервер по одной на каждый активный сеанс.
При этом что в том, что в другом случае никакого значения тип лицензии (аппаратный или программный) не играет. Важны только сами лицензии.
Сами же лицензии могут быть аппаратными или программными. Начнем с последних.
Лицензии данного типа могут быть однопользовательские (на 1 рабочее место), комбинированные (5, 10 и 20 лицензий) и многопользовательские (от 50 лицензий и более).
Однопользовательская лицензия привязывается к ПК и позволяет запускать там неограниченное число сеансов. При смене ПК либо оборудования к которому привязывается лицензия потребуется повторная активация.
Комбинированные лицензии мы можем активировать как однопользовательские, тогда на каждом ПК используем отдельный пин, либо как многопользовательские, активировав сразу все количество на сервере. Совмещение режимов в рамках одной лицензии не допускается.
Однопользовательская лицензия на 1 рабочее место также может быть активирована на сервере и тогда она будет использоваться как многопользовательская. Все активированные на сервере комплекты лицензий суммируются.
Аппаратные лицензии привязываются к HASP ключу. Однопользовательский ключ (фиолетовый) позволяет использовать единственную лицензию только локально, вы не сможете добавить ее на терминальный сервер или сервер 1С как многопользовательскую.
По свойствам она ничем не отличается от программной однопользовательской, позволяя запускать неограниченное число сеансов на одном ПК.
Многопользовательские сетевые ключи (красные) ни в коем случае не следует путать с многопользовательскими лицензиями. Лицензии там комбинированного типа и могут одновременно использоваться в обоих режимах.
А далее все зависит от того, каким образом эта лицензия будет выдана. Для раздачи лицензий по сети предназначена служба HASP License Manager.
Если лицензию от службы HASP LM получает непосредственно ПК, то такая лицензия используется как однопользовательская.
Если же лицензию выдает сервер и/или веб-сервер с локально установленного сетевого ключа или полученную через службу HASP LM, то она используется как многопользовательская.
Таким образом аппаратные лицензии не дают никакого выигрыша по числу лицензии или сеансов, так как решающее значение имеет только количество лицензий.
К плюсам аппаратных лицензий можно отнести привязку к ключу, а не к компьютеру, что позволяет более просто менять оборудование.
Минусы – более высокие требования к сети и потенциально возможные ситуации резкого исчерпания лицензий в том случае, если компьютер перестал видеть HASP LM и начал получать лицензии с сервера.
При наличии более одного сетевого ключа начинаются сложности с их размещением и поиском, при этом крайне желательно на каждом ПК явно прописать адреса служб HASP LM, в противном случае при ряде условий если компьютер первым находит ключ не содержащий свободных лицензий, то дальнейший поиск ключей не будет продолжен.
Также аппаратный ключ невозможно восстановить при утере. При выходе из строя или физическом повреждении восстановление возможно только при возврате неисправного ключа.
Для восстановления программной лицензии достаточно регистрационной анкеты.
Комментарии к предыдущей заметке показали, что многие читатели не до конца представляют все различия между двумя типами лицензий и подвержены многим предрассудкам и заблуждениям.
Начнем с того, что в основе лицензионной политики 1С, как это ни странно, лежит ЛИЦЕНЗИЯ.
Лицензия может быть однопользовательской, которая позволяет запускать неограниченное число сеансов 1С на одном ПК. Точнее в рамках одной пользовательской сессии, поэтому они так и называются – однопользовательские.
А для терминального сервера вам понадобится по одной однопользовательской лицензии на каждый сеанс пользователя.
Важно понимать, что однопользовательскую лицензию получает сам компьютер и неважно как он это делает.
Второй вид лицензий – многопользовательские, их выдает исключительно сервер и/или веб-сервер по одной на каждый активный сеанс.
При этом что в том, что в другом случае никакого значения тип лицензии (аппаратный или программный) не играет. Важны только сами лицензии.
Сами же лицензии могут быть аппаратными или программными. Начнем с последних.
Лицензии данного типа могут быть однопользовательские (на 1 рабочее место), комбинированные (5, 10 и 20 лицензий) и многопользовательские (от 50 лицензий и более).
Однопользовательская лицензия привязывается к ПК и позволяет запускать там неограниченное число сеансов. При смене ПК либо оборудования к которому привязывается лицензия потребуется повторная активация.
Комбинированные лицензии мы можем активировать как однопользовательские, тогда на каждом ПК используем отдельный пин, либо как многопользовательские, активировав сразу все количество на сервере. Совмещение режимов в рамках одной лицензии не допускается.
Однопользовательская лицензия на 1 рабочее место также может быть активирована на сервере и тогда она будет использоваться как многопользовательская. Все активированные на сервере комплекты лицензий суммируются.
Аппаратные лицензии привязываются к HASP ключу. Однопользовательский ключ (фиолетовый) позволяет использовать единственную лицензию только локально, вы не сможете добавить ее на терминальный сервер или сервер 1С как многопользовательскую.
По свойствам она ничем не отличается от программной однопользовательской, позволяя запускать неограниченное число сеансов на одном ПК.
Многопользовательские сетевые ключи (красные) ни в коем случае не следует путать с многопользовательскими лицензиями. Лицензии там комбинированного типа и могут одновременно использоваться в обоих режимах.
А далее все зависит от того, каким образом эта лицензия будет выдана. Для раздачи лицензий по сети предназначена служба HASP License Manager.
Если лицензию от службы HASP LM получает непосредственно ПК, то такая лицензия используется как однопользовательская.
Если же лицензию выдает сервер и/или веб-сервер с локально установленного сетевого ключа или полученную через службу HASP LM, то она используется как многопользовательская.
Таким образом аппаратные лицензии не дают никакого выигрыша по числу лицензии или сеансов, так как решающее значение имеет только количество лицензий.
К плюсам аппаратных лицензий можно отнести привязку к ключу, а не к компьютеру, что позволяет более просто менять оборудование.
Минусы – более высокие требования к сети и потенциально возможные ситуации резкого исчерпания лицензий в том случае, если компьютер перестал видеть HASP LM и начал получать лицензии с сервера.
При наличии более одного сетевого ключа начинаются сложности с их размещением и поиском, при этом крайне желательно на каждом ПК явно прописать адреса служб HASP LM, в противном случае при ряде условий если компьютер первым находит ключ не содержащий свободных лицензий, то дальнейший поиск ключей не будет продолжен.
Также аппаратный ключ невозможно восстановить при утере. При выходе из строя или физическом повреждении восстановление возможно только при возврате неисправного ключа.
Для восстановления программной лицензии достаточно регистрационной анкеты.
👍33❤3🤮1
Порядок получения лицензий 1С:Предприятия клиентским приложением
Все виды клиентов 1С:Предприятия (кроме веб-клиента) осуществляют поиск лицензии в следующей последовательности:
▫️ Если ранее лицензия была успешно получена, то выполняется попытка получения лицензии из того же файла программной лицензии или HASP ключа что и при последнем подключении
▫️ При первом подключении или в том случае если на предыдущем этапе лицензия не была найдена выполняется поиск локальных программных лицензий
▫️ Поиск локального ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
▫️ Поиск базовой лицензии на локальном компьютере
❗️ Если лицензия не была найдена, то клиент обращается за лицензией на сервер (веб-сервер), поиск выполняет менеджер кластера, на который назначен сервис сеансовых данных в следующем порядке:
▫️ Программная лицензия или ключ защиты HASP откуда была получена лицензия при последнем удачном подключении
▫️ Поиск локальной программной лицензии
▫️ Поиск локального клиентского ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
▫️ Программная лицензия на сервере лицензирования откуда была получена лицензия при последнем удачном запуске
▫️ Поиск программной лицензии на сервере лицензирования
☝️ При этом выдача лицензии сервером имеет свои особенности:
▫️ Лицензия выдается на каждый сеанс, т.е. один клиент может занять несколько лицензий
▫️ Сервер может подключиться только к одному локальному и одному сетевому ключу одной серии
Как видим, алгоритм достаточно сложный и поиск ключей выполняется во многих местах, поэтому для ускорения запуска клиента 1С, если вы не используете аппаратные ключи, следует использовать параметр
Все виды клиентов 1С:Предприятия (кроме веб-клиента) осуществляют поиск лицензии в следующей последовательности:
▫️ Если ранее лицензия была успешно получена, то выполняется попытка получения лицензии из того же файла программной лицензии или HASP ключа что и при последнем подключении
▫️ При первом подключении или в том случае если на предыдущем этапе лицензия не была найдена выполняется поиск локальных программных лицензий
▫️ Поиск локального ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
▫️ Поиск базовой лицензии на локальном компьютере
❗️ Если лицензия не была найдена, то клиент обращается за лицензией на сервер (веб-сервер), поиск выполняет менеджер кластера, на который назначен сервис сеансовых данных в следующем порядке:
▫️ Программная лицензия или ключ защиты HASP откуда была получена лицензия при последнем удачном подключении
▫️ Поиск локальной программной лицензии
▫️ Поиск локального клиентского ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
▫️ Программная лицензия на сервере лицензирования откуда была получена лицензия при последнем удачном запуске
▫️ Поиск программной лицензии на сервере лицензирования
☝️ При этом выдача лицензии сервером имеет свои особенности:
▫️ Лицензия выдается на каждый сеанс, т.е. один клиент может занять несколько лицензий
▫️ Сервер может подключиться только к одному локальному и одному сетевому ключу одной серии
Как видим, алгоритм достаточно сложный и поиск ключей выполняется во многих местах, поэтому для ускорения запуска клиента 1С, если вы не используете аппаратные ключи, следует использовать параметр
UseHwLicenses=0 в конфигурационном файле 1cestart.cfg, который отключит поиск лицензий на аппаратных ключах.
👍28🤮1
Порядок получения лицензий 1С:Предприятия веб-клиентом
Веб-клиент – особый тип клиентского приложения, предназначенный для работы через браузер. Это один из самых специфичных и ограниченных в возможностях клиентов и поэтому работу через него надо избегать.
Однако в ряде случаев особых альтернатив ему нет, например, для техники Apple или планшетов Andriod.
Получение лицензий таким клиентом имеет свои особенности и зависит от режима работы.
Для файловой базы поиск производится на компьютере, где установлен модуль расширения веб-сервера, все лицензии выдаются только в многопользовательском режиме (на сеанс):
▫️ Получение лицензии из файла программной лицензии или HASP ключа откуда была получена лицензия при последнем удачном подключении
▫️ Поиск локальной программной файловой лицензии
▫️ Поиск локального ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
Для клиент-серверных баз локальный поиск ключа на компьютере с установленным модулем расширения веб-сервера не производится, лицензия сразу запрашивается с сервера. Поиск лицензии выполняет менеджер кластера, на который назначен сервис сеансовых данных в следующем порядке:
▫️ Программная лицензия или ключ защиты HASP откуда была получена лицензия при последнем удачном подключении
▫️ Поиск локальной программной лицензии
▫️ Поиск локального клиентского ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
▫️ Программная лицензия на сервере лицензирования откуда была получена лицензия при последнем удачном запуске
▫️ Поиск программной лицензии на сервере лицензирования
При этом, если вы используете веб-клиент для подключения к файловым и клиент-серверным базам одновременно вам будет необходимо держать два комплекта лицензий на веб-сервере и сервере 1С Предприятие в количестве достаточном для запуска нужного числа сеансов.
Веб-клиент – особый тип клиентского приложения, предназначенный для работы через браузер. Это один из самых специфичных и ограниченных в возможностях клиентов и поэтому работу через него надо избегать.
Однако в ряде случаев особых альтернатив ему нет, например, для техники Apple или планшетов Andriod.
Получение лицензий таким клиентом имеет свои особенности и зависит от режима работы.
Для файловой базы поиск производится на компьютере, где установлен модуль расширения веб-сервера, все лицензии выдаются только в многопользовательском режиме (на сеанс):
▫️ Получение лицензии из файла программной лицензии или HASP ключа откуда была получена лицензия при последнем удачном подключении
▫️ Поиск локальной программной файловой лицензии
▫️ Поиск локального ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
Для клиент-серверных баз локальный поиск ключа на компьютере с установленным модулем расширения веб-сервера не производится, лицензия сразу запрашивается с сервера. Поиск лицензии выполняет менеджер кластера, на который назначен сервис сеансовых данных в следующем порядке:
▫️ Программная лицензия или ключ защиты HASP откуда была получена лицензия при последнем удачном подключении
▫️ Поиск локальной программной лицензии
▫️ Поиск локального клиентского ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
▫️ Программная лицензия на сервере лицензирования откуда была получена лицензия при последнем удачном запуске
▫️ Поиск программной лицензии на сервере лицензирования
При этом, если вы используете веб-клиент для подключения к файловым и клиент-серверным базам одновременно вам будет необходимо держать два комплекта лицензий на веб-сервере и сервере 1С Предприятие в количестве достаточном для запуска нужного числа сеансов.
👍15🤮2👀2
Какой тип клиента 1С вы предпочитаете использовать? Можно выбрать несколько вариантов
Anonymous Poll
42%
Тонкий клиент на клиенстком ПК
29%
Тонкий клиент на терминальном сервере
13%
Толстый клиент (для устаревших конфигураций) на клиентском ПК
16%
Толстый клиент (для устаревших конфигураций) на терминальном сервере
22%
Тонкий клиент через веб-сервер
10%
Веб-клиент
19%
Ничего не понятно, но очень интересно
👍6🤮5
Мимикрия
Столкнулся я не так давно с жесткими дисками некой китайской компании BaseTech. Требовалась стопка чего-то недорогого и небольшого по объему.
Как раз для этих задач китайцы в самый раз. Китайские SSD давно не вызывают ни удивления, ни каких-то особых опасений. Обычные бюджетные диски со стандартными характеристиками.
Но китайцы не были бы китайцами, если бы не стремились казаться, а не быть. Возможно, на китайском рынке это и работает, но на нашем вызывает только улыбку.
Сам по себе BaseTech A400 особых ассоциаций не вызвал, ну мало ли, просто совпадение с одной из самых популярных бюджетных моделей.
Но когда я зашел на сайт посмотреть, что это вообще за производитель и что еще производит, то был крайне удивлен моделью BaseTech 970 EVO PLUS, явной отсылкой к одному из лидеров рынка.
Поиском также нашлась ныне отсутствующая в продаже модель BaseTech MX 500 и пазл полностью сложился. Непонятно только зачем вся эта мимикрия…
Столкнулся я не так давно с жесткими дисками некой китайской компании BaseTech. Требовалась стопка чего-то недорогого и небольшого по объему.
Как раз для этих задач китайцы в самый раз. Китайские SSD давно не вызывают ни удивления, ни каких-то особых опасений. Обычные бюджетные диски со стандартными характеристиками.
Но китайцы не были бы китайцами, если бы не стремились казаться, а не быть. Возможно, на китайском рынке это и работает, но на нашем вызывает только улыбку.
Сам по себе BaseTech A400 особых ассоциаций не вызвал, ну мало ли, просто совпадение с одной из самых популярных бюджетных моделей.
Но когда я зашел на сайт посмотреть, что это вообще за производитель и что еще производит, то был крайне удивлен моделью BaseTech 970 EVO PLUS, явной отсылкой к одному из лидеров рынка.
Поиском также нашлась ныне отсутствующая в продаже модель BaseTech MX 500 и пазл полностью сложился. Непонятно только зачем вся эта мимикрия…
😁17
Предсказуемые имена сетевых интерфейсов systemd
Начиная с версии 197, systemd/udev автоматически назначает предсказуемые, стабильные имена сетевых интерфейсов для всех сетевых интерфейсов. Это решение было встречено, скажем мягко, неоднозначно. Поэтому в данной заметке мы расскажем для чего это сделано и какие проблемы решает.
Начнем с классической схемы с eth, первоначально она базировалась на опросе ядром сетевых устройств по мере их появления, а так как порядок загрузки драйверов может носить случайный характер, то eth0 при следующей загрузке мог стать eth1 и наоборот.
Долгое время для решения этой проблемы использовалась схема присвоения имен на основе MAC-адресов, но она имела существенные недостатки в виде необходимости root-доступа на запись файловой системы и способность впадать в состояние гонки при подключении нового устройства.
С появлением виртуализации возникли новые сложности, связанные с тем, что MAC-адреса сетевых интерфейсов виртуальных машин не являются фиксированными и могут меняться.
Другой применяемый подход – biosdevname, в этом случае ядро пыталось считать из BIOS топологию сетевого устройства по принципу порт – индекс – слот и на этом основании присваивать сетевые имена.
Недостаток данного подхода - он полностью неприменим для не x86 устройств.
Но в целом biosdevname предлагал здравый поход: имена полностью автоматические, полностью предсказуемые, они остаются фиксированными, даже если оборудование добавляется или удаляется (т. е. не происходит повторного нумерации), и сломанное оборудование можно без проблем заменить.
В systemd реализована схема во многом похожая на biosdevname, но более развитая и предполагающее большее сходство имен сетевых интерфейсов с именами других устройств, например, блочных.
Она состоит из нескольких политик:
1️⃣ Имена, включающие индексные номера прошивки/BIOS для встроенных устройств (например: eno1)
2️⃣ Имена, включающие индексные номера слотов PCI Express, предоставленные прошивкой/BIOS (например: ens1)
3️⃣ Имена, включающие физическое/географическое расположение разъема оборудования (например: enp2s0)
4️⃣ Имена, включающие MAC-адрес интерфейсов (например: enx78e7d1ea46da)
5️⃣ Классическое, непредсказуемое именование ethX, встроенное в ядро (например: eth0)
Выбор имени происходит следующим образом: политика 3 если она применима и доступна, иначе переход к политике 2, от нее к политике 1. Если не одна политика не подходит, то применяется политика 5.
Политика 4 никогда автоматически не применяется, но может быть включена системным администратором.
Политика 5 применяется только в крайнем случае. Это означает, что, если в системе установлено имя biosdevname, оно будет иметь приоритет. Если пользователь добавил правила udev, которые изменяют имена устройств ядра, они также будут иметь приоритет. Кроме того, любые схемы именования, специфичные для дистрибутива, также будут иметь приоритет.
Таким образом система предоставляет постоянные и предсказуемые имена для сетевого оборудования вне зависимости от версии драйверов и ядра, а также марки оборудования.
Такие имена не меняются при добавлении или удалении оборудования и сохраняются при его замене. Также это гарантирует неизменность имен в виртуальных средах. И, кроме того, не требуется root-доступ на запись файловой системы.
К недостаткам данной схемы можно отнести некоторую начальную неопределенность, ранее в системе с одним сетевым адаптером он гарантированно был eth0, теперь его наименование следует уточнить перед настройкой.
Начиная с версии 197, systemd/udev автоматически назначает предсказуемые, стабильные имена сетевых интерфейсов для всех сетевых интерфейсов. Это решение было встречено, скажем мягко, неоднозначно. Поэтому в данной заметке мы расскажем для чего это сделано и какие проблемы решает.
Начнем с классической схемы с eth, первоначально она базировалась на опросе ядром сетевых устройств по мере их появления, а так как порядок загрузки драйверов может носить случайный характер, то eth0 при следующей загрузке мог стать eth1 и наоборот.
Долгое время для решения этой проблемы использовалась схема присвоения имен на основе MAC-адресов, но она имела существенные недостатки в виде необходимости root-доступа на запись файловой системы и способность впадать в состояние гонки при подключении нового устройства.
С появлением виртуализации возникли новые сложности, связанные с тем, что MAC-адреса сетевых интерфейсов виртуальных машин не являются фиксированными и могут меняться.
Другой применяемый подход – biosdevname, в этом случае ядро пыталось считать из BIOS топологию сетевого устройства по принципу порт – индекс – слот и на этом основании присваивать сетевые имена.
Недостаток данного подхода - он полностью неприменим для не x86 устройств.
Но в целом biosdevname предлагал здравый поход: имена полностью автоматические, полностью предсказуемые, они остаются фиксированными, даже если оборудование добавляется или удаляется (т. е. не происходит повторного нумерации), и сломанное оборудование можно без проблем заменить.
В systemd реализована схема во многом похожая на biosdevname, но более развитая и предполагающее большее сходство имен сетевых интерфейсов с именами других устройств, например, блочных.
Она состоит из нескольких политик:
1️⃣ Имена, включающие индексные номера прошивки/BIOS для встроенных устройств (например: eno1)
2️⃣ Имена, включающие индексные номера слотов PCI Express, предоставленные прошивкой/BIOS (например: ens1)
3️⃣ Имена, включающие физическое/географическое расположение разъема оборудования (например: enp2s0)
4️⃣ Имена, включающие MAC-адрес интерфейсов (например: enx78e7d1ea46da)
5️⃣ Классическое, непредсказуемое именование ethX, встроенное в ядро (например: eth0)
Выбор имени происходит следующим образом: политика 3 если она применима и доступна, иначе переход к политике 2, от нее к политике 1. Если не одна политика не подходит, то применяется политика 5.
Политика 4 никогда автоматически не применяется, но может быть включена системным администратором.
Политика 5 применяется только в крайнем случае. Это означает, что, если в системе установлено имя biosdevname, оно будет иметь приоритет. Если пользователь добавил правила udev, которые изменяют имена устройств ядра, они также будут иметь приоритет. Кроме того, любые схемы именования, специфичные для дистрибутива, также будут иметь приоритет.
Таким образом система предоставляет постоянные и предсказуемые имена для сетевого оборудования вне зависимости от версии драйверов и ядра, а также марки оборудования.
Такие имена не меняются при добавлении или удалении оборудования и сохраняются при его замене. Также это гарантирует неизменность имен в виртуальных средах. И, кроме того, не требуется root-доступ на запись файловой системы.
К недостаткам данной схемы можно отнести некоторую начальную неопределенность, ранее в системе с одним сетевым адаптером он гарантированно был eth0, теперь его наименование следует уточнить перед настройкой.
👍43👀2