Кеширующий прокси или зеркало репозитория?
Уже не первый раз сталкиваемся с тем, что начинающие администраторы путают эти два понятия. Поэтому попробуем внести ясность.
По мере роста количества машин под управлением Linux возникает проблема доступа к репозиториям. Например, при обновлении весь парк машин будет многократно выкачивать один и тот же объем трафика.
Дополнительными негативными факторами могут быть скорость канала или скорость доступа к репозиториям. Все это заставляет задуматься о том, как решить проблему.
Первое что приходит на ум – это локальное зеркало репозитория. Создать его несложно, для этого есть штатная утилита apt-mirror. С ее помощью можно поддерживать на собственных ресурсах полную копию репозиториев системы.
Но тут возникают иные сложности, так, например, размер репозиториев текущей версии Debian для архитектуры amd64 составляет 778 ГБ, сюда как минимум следует добавить all и еще 258 ГБ. Получаем примерно 1 ТБ требуемого дискового пространства.
Если у нас в эксплуатации несколько систем, то зеркала репозиториев нужно будет организовать для каждой из них. При переходе на новую версию – добавить новые репозитории.
В итоге получаем весьма значительное расходование места, причем достаточно бесполезное, поскольку по факту вы будете использовать лишь малую его часть.
Уменьшить размер локальных репозиториев в целом можно, например, скачав только самые нужные или оставив только последние версии пакетов, но все это не устраняет общей проблемы – значительный перерасход места.
Альтернатива локальному репозиторию – кеширующий прокси-сервер. Он работает по схожему, но несколько иному принципу.
Как и любой прокси-сервер он становится посредником между системой и репозиторием и один раз скачав любой пакет помещает его в локальный кеш. При последующих запросах пакет будет уже отдаваться из кеша, без повторного скачивания.
Локальная структура также организуется по принципу репозиториев, с учетом версии системы, архитектуры, источника пакетов и т.д.
Поэтому один кеширующий прокси может без проблем обслуживать любое количество систем и их версий. Никаких настроек при этом делать не надо. Новая система первый раз скачает необходимые файлы из интернета, а остальные получат их уже из локального хранилища.
Потребовался новый пакет или обновление? Аналогично, один раз качаем, остальное получаем локально.
При этом размер кеша будет равен размеру реально используемых пакетов и их версий. И разница с локальным репозиторием получается где-то на порядок.
Поэтому для большинства сценариев оптимальным будет использование именно кеширующего прокси.
Локальные репозитории в свою очередь следует использовать для закрытого контура или крупных систем с узким внешним каналом.
Настроить кеширующий прокси Apt-Cacher NG можно по нашей статье: Установка и настройка Apt-Cacher NG - кеширующего прокси-сервера обновлений для Debian и Ubuntu
Уже не первый раз сталкиваемся с тем, что начинающие администраторы путают эти два понятия. Поэтому попробуем внести ясность.
По мере роста количества машин под управлением Linux возникает проблема доступа к репозиториям. Например, при обновлении весь парк машин будет многократно выкачивать один и тот же объем трафика.
Дополнительными негативными факторами могут быть скорость канала или скорость доступа к репозиториям. Все это заставляет задуматься о том, как решить проблему.
Первое что приходит на ум – это локальное зеркало репозитория. Создать его несложно, для этого есть штатная утилита apt-mirror. С ее помощью можно поддерживать на собственных ресурсах полную копию репозиториев системы.
Но тут возникают иные сложности, так, например, размер репозиториев текущей версии Debian для архитектуры amd64 составляет 778 ГБ, сюда как минимум следует добавить all и еще 258 ГБ. Получаем примерно 1 ТБ требуемого дискового пространства.
Если у нас в эксплуатации несколько систем, то зеркала репозиториев нужно будет организовать для каждой из них. При переходе на новую версию – добавить новые репозитории.
В итоге получаем весьма значительное расходование места, причем достаточно бесполезное, поскольку по факту вы будете использовать лишь малую его часть.
Уменьшить размер локальных репозиториев в целом можно, например, скачав только самые нужные или оставив только последние версии пакетов, но все это не устраняет общей проблемы – значительный перерасход места.
Альтернатива локальному репозиторию – кеширующий прокси-сервер. Он работает по схожему, но несколько иному принципу.
Как и любой прокси-сервер он становится посредником между системой и репозиторием и один раз скачав любой пакет помещает его в локальный кеш. При последующих запросах пакет будет уже отдаваться из кеша, без повторного скачивания.
Локальная структура также организуется по принципу репозиториев, с учетом версии системы, архитектуры, источника пакетов и т.д.
Поэтому один кеширующий прокси может без проблем обслуживать любое количество систем и их версий. Никаких настроек при этом делать не надо. Новая система первый раз скачает необходимые файлы из интернета, а остальные получат их уже из локального хранилища.
Потребовался новый пакет или обновление? Аналогично, один раз качаем, остальное получаем локально.
При этом размер кеша будет равен размеру реально используемых пакетов и их версий. И разница с локальным репозиторием получается где-то на порядок.
Поэтому для большинства сценариев оптимальным будет использование именно кеширующего прокси.
Локальные репозитории в свою очередь следует использовать для закрытого контура или крупных систем с узким внешним каналом.
Настроить кеширующий прокси Apt-Cacher NG можно по нашей статье: Установка и настройка Apt-Cacher NG - кеширующего прокси-сервера обновлений для Debian и Ubuntu
👍55❤2👀1
Принципы работы Apt-Cacher NG
В обсуждениях к предыдущей заметки выяснилось, что не все коллеги понимают принцип действия данного продукта, поэтому мы посчитали нужным остановиться на нем подробнее.
Apt-Cacher NG по своей сути – это обычный кеширущий прокси сервер, только с некоторыми особенностями кеширования. Работа с прокси не является чем-то необычным для Linux и поэтому никаких дополнительных сущностей там не возникает.
После того, как в настройках APT или репозитория мы тем или иным способом указали прокси-сервер, то все общение с внешним миром у нас будет через него и только через него. Если Apt-Cacher NG окажется недоступным, то никакого доступа к репозиториям у нас не будет.
В этом плане является предпочтительным подключение его через Zeroconf, в этом случае если прокси доступен – то трафик идет через него, если же нет, то напрямую.
В самом начале кеш прокси у нас пуст. А клиент, скажем Debian 12, хочет скачать пакет top. Он формирует стандартный HTTP-запрос к файлу пакета в стандартном репозитории и передает его прокси-серверу.
Прокси смотрит конечный URL и проверяет свой кеш, если данного пакета там нет, то запрос уходит в удаленный репозиторий и клиент производит скачивание напрямую из него, при этом трафик проходит через прокси-сервер.
Это важный момент, и мы специально заостряем на него внимание, никакого двойного скачивания не происходит, т.е. Apt-Cacher NG не качает пакет сначала в кеш, а потом из кеша отдает его клиенту. Клиент качает пакет через прокси напрямую, но при этом прокси кеширует пакет и размещает в специальной структуре однозначно связанной с URL.
Когда у нас этот же самый пакет захочет скачать второй клиент, то он также сформирует HTTP запрос к стандартному репозиторию и передаст его прокси-серверу. Прокси-сервер снова проверит кеш и найдет закешированный для этого URL пакет, после чего отдаст его из локального кеша, без повторного скачивания из сети.
А теперь у нас в сети появляется другая система и хочет скачать тот же самый пакет. Возможно даже с тем же самым именем. Но прокси не так просто провести. Для другой системы иди другой архитектуры или даже другого репозитория или PPA у нас будет совсем другой URL, для которого не будет закешированного пакета.
Поэтому сначала снова будет прямое скачивание из удаленного репозитория, а потом пакет будет отдаваться из кеша. При этом Apt-Cacher NG абсолютно не нужно знать какие у вас в эксплуатации системы и из каких репозиториев вы качаете.
Оно просто выделяет все проходящие через него пакеты, не обязательно DEB, Apt-Cacher NG также умеет работать и с RPM и сохраняет их в кеш с привязкой к URL. При повторном запросе он смотрит в собственную базу и если находит кешированный пакет, то отдает его из локального хранилища.
Таким образом важно понимать, что если вам нужно обновить несколько однотипных систем, то не нужно запускать обновления сразу. Обновите одну систему, чтобы все нужные пакеты попали в кеш и только потом запускайте обновления на остальных.
В обсуждениях к предыдущей заметки выяснилось, что не все коллеги понимают принцип действия данного продукта, поэтому мы посчитали нужным остановиться на нем подробнее.
Apt-Cacher NG по своей сути – это обычный кеширущий прокси сервер, только с некоторыми особенностями кеширования. Работа с прокси не является чем-то необычным для Linux и поэтому никаких дополнительных сущностей там не возникает.
После того, как в настройках APT или репозитория мы тем или иным способом указали прокси-сервер, то все общение с внешним миром у нас будет через него и только через него. Если Apt-Cacher NG окажется недоступным, то никакого доступа к репозиториям у нас не будет.
В этом плане является предпочтительным подключение его через Zeroconf, в этом случае если прокси доступен – то трафик идет через него, если же нет, то напрямую.
В самом начале кеш прокси у нас пуст. А клиент, скажем Debian 12, хочет скачать пакет top. Он формирует стандартный HTTP-запрос к файлу пакета в стандартном репозитории и передает его прокси-серверу.
Прокси смотрит конечный URL и проверяет свой кеш, если данного пакета там нет, то запрос уходит в удаленный репозиторий и клиент производит скачивание напрямую из него, при этом трафик проходит через прокси-сервер.
Это важный момент, и мы специально заостряем на него внимание, никакого двойного скачивания не происходит, т.е. Apt-Cacher NG не качает пакет сначала в кеш, а потом из кеша отдает его клиенту. Клиент качает пакет через прокси напрямую, но при этом прокси кеширует пакет и размещает в специальной структуре однозначно связанной с URL.
Когда у нас этот же самый пакет захочет скачать второй клиент, то он также сформирует HTTP запрос к стандартному репозиторию и передаст его прокси-серверу. Прокси-сервер снова проверит кеш и найдет закешированный для этого URL пакет, после чего отдаст его из локального кеша, без повторного скачивания из сети.
А теперь у нас в сети появляется другая система и хочет скачать тот же самый пакет. Возможно даже с тем же самым именем. Но прокси не так просто провести. Для другой системы иди другой архитектуры или даже другого репозитория или PPA у нас будет совсем другой URL, для которого не будет закешированного пакета.
Поэтому сначала снова будет прямое скачивание из удаленного репозитория, а потом пакет будет отдаваться из кеша. При этом Apt-Cacher NG абсолютно не нужно знать какие у вас в эксплуатации системы и из каких репозиториев вы качаете.
Оно просто выделяет все проходящие через него пакеты, не обязательно DEB, Apt-Cacher NG также умеет работать и с RPM и сохраняет их в кеш с привязкой к URL. При повторном запросе он смотрит в собственную базу и если находит кешированный пакет, то отдает его из локального хранилища.
Таким образом важно понимать, что если вам нужно обновить несколько однотипных систем, то не нужно запускать обновления сразу. Обновите одну систему, чтобы все нужные пакеты попали в кеш и только потом запускайте обновления на остальных.
👍44🔥2👀2
+1 полезный калан, где вы найдете самые актуальные новости связанные с автоматизацией складской и транспортной логистики.
Вот самые классные темы:
- Что будет с программными решениями по модели as a service и почему облачные сервисы потеряли доверие бизнеса.
- Почему food-market отстает по уровню цифровой зрелости от других отраслей.
- Зачем для эффективной работы с системой маркировки «Честный знак» нужна WMS.
- Подкаст «Логистика на ночь», очень понравился недавний выпуск о последней мили.
Всё о цифровых технологиях и не только - коротко, ёмко и по делу на канале @GTLogistics_tech, подписывайтесь!
Реклама. ООО "ДЖИТИ ЛОДЖИСТИКС". ИНН 6670420812. erid: LjN8K7T4s
Вот самые классные темы:
- Что будет с программными решениями по модели as a service и почему облачные сервисы потеряли доверие бизнеса.
- Почему food-market отстает по уровню цифровой зрелости от других отраслей.
- Зачем для эффективной работы с системой маркировки «Честный знак» нужна WMS.
- Подкаст «Логистика на ночь», очень понравился недавний выпуск о последней мили.
Всё о цифровых технологиях и не только - коротко, ёмко и по делу на канале @GTLogistics_tech, подписывайтесь!
Реклама. ООО "ДЖИТИ ЛОДЖИСТИКС". ИНН 6670420812. erid: LjN8K7T4s
🤮3👀2
Легкий мониторинг
Коллеги часто спрашивают что-нибудь простое для мониторинга небольшой инфраструктуры.
Действительно, не везде нужны такие монстры как 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