Ностальгия… Ностальгия…
- Мы тут тебе старенький компьютер привезем…
Старенький, что сейчас под этим подразумевают? Ну какой-нибудь Core первых поколений, куда уж старее…
А когда открыли и там такое. Ну прямо не знаешь, что сказать. При этом, как выяснилось, подключить IDE диск тоже не к чему, ни у меня, ни у коллег таких переходников не осталось.
Хорошо, что все данные сохранялись в сетевую папку, а к самому софту нашелся установочный диск и он до сих пор читается.
А дальше пошли сплошные сложности. Данный ПК коптил небо не просто так, а в составе некоторого медицинского оборудования. Софт на современные ОС не ставится, точнее поставить в режиме совместимости можно, но нет драйвера для взаимодействия с прибором через COM-порт.
Все что есть – работает только под Windows 2000/XP, производитель его с рынка ушел, бывший дистрибьютор разводит руками и предлагает купить новый прибор за много-много денег.
Опытным путем выяснили, что прибор нормально переваривает переходник COM-USB на классическом PL-2303, а значит жить немного проще.
Пока план такой, на современную платформу поставить виртуальную машину с пробросом в нее COM-порта и установкой туда Windows XP и требуемого софта. Сценарий, конечно, немного посложнее для персонала, но ничего такого, что нельзя было бы осилить.
Подобные проекты уже были, мы ставили на современные в то время машины с Windows 7 виртуалки с Windows 98 и PDF принтером в ней, чтобы была возможность быстро и безболезненно перегнать в PDF архив сканов в формате AWD, который использовался в Windows 9.x для сканов по умолчанию, а потом был выпилен даже на чтение.
Так что времена идут – ничего не меняется. Хорошо, что сегодня есть виртуализация, которая позволяет при необходимости запустить старые системы на современном железе, чем продлить жизнь многих специфических промышленных и отраслевых систем.
- Мы тут тебе старенький компьютер привезем…
Старенький, что сейчас под этим подразумевают? Ну какой-нибудь Core первых поколений, куда уж старее…
А когда открыли и там такое. Ну прямо не знаешь, что сказать. При этом, как выяснилось, подключить IDE диск тоже не к чему, ни у меня, ни у коллег таких переходников не осталось.
Хорошо, что все данные сохранялись в сетевую папку, а к самому софту нашелся установочный диск и он до сих пор читается.
А дальше пошли сплошные сложности. Данный ПК коптил небо не просто так, а в составе некоторого медицинского оборудования. Софт на современные ОС не ставится, точнее поставить в режиме совместимости можно, но нет драйвера для взаимодействия с прибором через COM-порт.
Все что есть – работает только под Windows 2000/XP, производитель его с рынка ушел, бывший дистрибьютор разводит руками и предлагает купить новый прибор за много-много денег.
Опытным путем выяснили, что прибор нормально переваривает переходник COM-USB на классическом PL-2303, а значит жить немного проще.
Пока план такой, на современную платформу поставить виртуальную машину с пробросом в нее COM-порта и установкой туда Windows XP и требуемого софта. Сценарий, конечно, немного посложнее для персонала, но ничего такого, что нельзя было бы осилить.
Подобные проекты уже были, мы ставили на современные в то время машины с Windows 7 виртуалки с Windows 98 и PDF принтером в ней, чтобы была возможность быстро и безболезненно перегнать в PDF архив сканов в формате AWD, который использовался в Windows 9.x для сканов по умолчанию, а потом был выпилен даже на чтение.
Так что времена идут – ничего не меняется. Хорошо, что сегодня есть виртуализация, которая позволяет при необходимости запустить старые системы на современном железе, чем продлить жизнь многих специфических промышленных и отраслевых систем.
👍51😁3🥱3
Какое самое старое оборудование есть у вас в эксплуатации?
Anonymous Poll
4%
i386 и аналоги
2%
i486 и аналоги
4%
Pentium I и аналоги
3%
Pentium II и аналоги
3%
Pentium III и аналоги
11%
Pentium IV и аналоги
33%
Сore Duo/Quad и аналоги
17%
Core i3/5/7 первых поколений
15%
Это перепись динозавров?
6%
Я и слов таких не знаю, мне результат посмотреть
Что такое Service mesh и зачем он нужен?
Service mesh автоматизирует маршрутизацию, отказоустойчивость, безопасность и мониторинг. Но нужен ли он именно вам или это просто лишний оверхед?
В бесплатном уроке эксперт учебного центра Слёрм разберёт:
✔️ Проблемы микросервисной архитектуры;
✔️ Что такое Service mesh и как он работает;
✔️ Какие задачи решает Service mesh;
✔️ Кому он нужен, а кому – только усложнит жизнь;
✔️ Когда можно обойтись без него.
👉 Получить урок — у бота-помощника 👈
Смотрите сами и делитесь с коллегами!
Реклама. ООО "СЛЁРМ". ИНН 3652901451. erid: 2W5zFJHg1hz
Service mesh автоматизирует маршрутизацию, отказоустойчивость, безопасность и мониторинг. Но нужен ли он именно вам или это просто лишний оверхед?
В бесплатном уроке эксперт учебного центра Слёрм разберёт:
✔️ Проблемы микросервисной архитектуры;
✔️ Что такое Service mesh и как он работает;
✔️ Какие задачи решает Service mesh;
✔️ Кому он нужен, а кому – только усложнит жизнь;
✔️ Когда можно обойтись без него.
👉 Получить урок — у бота-помощника 👈
Смотрите сами и делитесь с коллегами!
Реклама. ООО "СЛЁРМ". ИНН 3652901451. erid: 2W5zFJHg1hz
Выгрузка и загрузка информационных баз 1С при помощи автономного сервера
При работе с информационными базами 1С:Предприятие очень часто возникают задачи выгрузить или загрузить дамп информационной базы или ее конфигурацию.
Обычно для этих целей используют Конфигуратор, но данный способ имеет ряд неудобств. Во-первых, Конфигуратор требует монопольного доступа к базе, т.е. выгнать из нее всех пользователей.
Во-вторых, могут быть сложности с серверами на Linux без графического окружения, а так как Конфигуратор работает в режиме толстого клиента, то все данные в полном объеме гоняются по сети, таким образом удаленная работа на медленном канале становится попросту невозможной.
От всех этих недостатков вас может избавить Автономный сервер, который поставляется вместе с платформой и располагается в папке
В нашем примере будет использована платформа Linux, но все команды будут прекрасно работать и в среде Windows.
Будем считать, что мы находимся в директории с бинарными файлами платформы, а дампы и конфигурации будем располагать в домашнем каталоге текущего пользователя.
Начнем с самого популярного, выгрузки базы в DT-файл:
В целом параметры в комментариях не нуждаются, только уточним что в опции --db-server мы указываем имя или адрес сервера базы данных и указываем учетные данные также от сервера СУБД.
Параметр --dbms указывает тип СУБД, можете использовать
Выгонять пользователей для этого не нужно, но помните, что в возможно нарушение целостности создаваемого файла выгрузки.
Кроме того, следует помнить, что выгрузка информационной базы не является средством резервного копирования!
Загрузить базу можно обратной командой:
Для выгрузки конфигурации используйте:
Для загрузки:
После загрузки конфигурации вам потребуется обновить конфигурацию базы данных:
В данной заметке мы коснулись лишь малой части того, что умеет автономный сервер, показав лишь самые часто используемые операции. Больше информации можно найти в официальной документации.
При работе с информационными базами 1С:Предприятие очень часто возникают задачи выгрузить или загрузить дамп информационной базы или ее конфигурацию.
Обычно для этих целей используют Конфигуратор, но данный способ имеет ряд неудобств. Во-первых, Конфигуратор требует монопольного доступа к базе, т.е. выгнать из нее всех пользователей.
Во-вторых, могут быть сложности с серверами на Linux без графического окружения, а так как Конфигуратор работает в режиме толстого клиента, то все данные в полном объеме гоняются по сети, таким образом удаленная работа на медленном канале становится попросту невозможной.
От всех этих недостатков вас может избавить Автономный сервер, который поставляется вместе с платформой и располагается в папке
bin под именем ibcmd.В нашем примере будет использована платформа Linux, но все команды будут прекрасно работать и в среде Windows.
Будем считать, что мы находимся в директории с бинарными файлами платформы, а дампы и конфигурации будем располагать в домашнем каталоге текущего пользователя.
Начнем с самого популярного, выгрузки базы в DT-файл:
./ibcmd infobase dump --db-server=srv-db --dbms=PostgreSQL --db-name=base-01 --db-user=postgres --db-pwd=Pa$$word_1 ~/1cv8.dt
В целом параметры в комментариях не нуждаются, только уточним что в опции --db-server мы указываем имя или адрес сервера базы данных и указываем учетные данные также от сервера СУБД.
Параметр --dbms указывает тип СУБД, можете использовать
PostgreSQL или MSSQLServer. Выгонять пользователей для этого не нужно, но помните, что в возможно нарушение целостности создаваемого файла выгрузки.
Кроме того, следует помнить, что выгрузка информационной базы не является средством резервного копирования!
Загрузить базу можно обратной командой:
./ibcmd infobase restore --db-server=srv-db --dbms=PostgreSQL --db-name=base-01 --db-user=postgres --db-pwd=Pa$$word_1 ~/1cv8.dt
Для выгрузки конфигурации используйте:
./ibcmd infobase config save --db-server=srv-db --dbms=PostgreSQL --db-name=base-01 --db-user=postgres --db-pwd=Pa$$word_1 ~/1cv8.cf
Для загрузки:
./ibcmd infobase config load --db-server=srv-db --dbms=PostgreSQL --db-name=base-01 --db-user=postgres --db-pwd=Pa$$word_1 ~/1cv8.cf
После загрузки конфигурации вам потребуется обновить конфигурацию базы данных:
./ibcmd infobase config apply --db-server=srv-db --dbms=PostgreSQL --db-name=base-01 --db-user=postgres --db-pwd=Pa$$word_1
В данной заметке мы коснулись лишь малой части того, что умеет автономный сервер, показав лишь самые часто используемые операции. Больше информации можно найти в официальной документации.
👍38🤔2
Программные лицензии 1С – как узнать причину слета лицензии и быстро активировать ее заново
Про программные лицензии ходит много мифов, мол они сильно капризные, слетают на ровном месте и т.д. и т.п.
Но на самом деле работа программных лицензий подвержена жесткой логике, которая описана в тоненькой желтой книжке, которую никто не читает.
При отсутствии этой самой тонкой желтой книжки всегда можете обратиться к нашей статье:
▫️ Особенности применения программных лицензий 1С:Предприятие
Итак, если лицензия слетела, то первым делом нужно открыть подробную информацию в окне, где вам об этом сообщается, вы увидите примерно то, что показано на рисунке.
В данном случае причиной слета лицензии было изменение дисковой конфигурации компьютера, что соответствует реальному положению дел.
Но не следует спешить активировать новую лицензию. Сначала внимательно изучите текущий список оборудования. В нашем случае в него затесались два внешних жестких диска. Их перед получением лицензии следует отключить.
Потому что добавлять в конфигурацию оборудование можно, удалять нельзя.
Кстати, после того как вы отключите внешние диски, то запустите 1С еще раз и снова посмотрите Журнал поиска ключа, чтобы четко понимать какие именно накопители будут влиять на текущую лицензию и уже после этого занимайтесь ее восстановлением.
Если у вас нет резервного ПИН-кода, то следует воспользоваться сервисами самообслуживания, либо написать письмо на адрес [email protected]. Письмо желательно писать с того адреса, на который зарегистрирована лицензия.
В нем в произвольной форме указываете номер поставки и просите выдать резервный пин-код.
Если пишите с другого адреса, то укажите также текущий пин-код и сведения о владельце лицензии.
Теперь о сервисах самообслуживания, это быстро и удобно, сейчас их четыре:
▫️ Восстановить данные о лицензии
▫️ Получить текущее состояние пин-кодов
▫️ Получить резервный пин-код
▫️ Получить лицензию из файла
Обратите внимание на новый, четвертый сервис, который позволяет получить данные лицензии из файла, что очень удобно если вы не знаете какая именно лицензия была активирована на данном устройстве.
Про программные лицензии ходит много мифов, мол они сильно капризные, слетают на ровном месте и т.д. и т.п.
Но на самом деле работа программных лицензий подвержена жесткой логике, которая описана в тоненькой желтой книжке, которую никто не читает.
При отсутствии этой самой тонкой желтой книжки всегда можете обратиться к нашей статье:
▫️ Особенности применения программных лицензий 1С:Предприятие
Итак, если лицензия слетела, то первым делом нужно открыть подробную информацию в окне, где вам об этом сообщается, вы увидите примерно то, что показано на рисунке.
В данном случае причиной слета лицензии было изменение дисковой конфигурации компьютера, что соответствует реальному положению дел.
Но не следует спешить активировать новую лицензию. Сначала внимательно изучите текущий список оборудования. В нашем случае в него затесались два внешних жестких диска. Их перед получением лицензии следует отключить.
Потому что добавлять в конфигурацию оборудование можно, удалять нельзя.
Кстати, после того как вы отключите внешние диски, то запустите 1С еще раз и снова посмотрите Журнал поиска ключа, чтобы четко понимать какие именно накопители будут влиять на текущую лицензию и уже после этого занимайтесь ее восстановлением.
Если у вас нет резервного ПИН-кода, то следует воспользоваться сервисами самообслуживания, либо написать письмо на адрес [email protected]. Письмо желательно писать с того адреса, на который зарегистрирована лицензия.
В нем в произвольной форме указываете номер поставки и просите выдать резервный пин-код.
Если пишите с другого адреса, то укажите также текущий пин-код и сведения о владельце лицензии.
Теперь о сервисах самообслуживания, это быстро и удобно, сейчас их четыре:
▫️ Восстановить данные о лицензии
▫️ Получить текущее состояние пин-кодов
▫️ Получить резервный пин-код
▫️ Получить лицензию из файла
Обратите внимание на новый, четвертый сервис, который позволяет получить данные лицензии из файла, что очень удобно если вы не знаете какая именно лицензия была активирована на данном устройстве.
👍42🔥3
🐧 Вы уже работаете с Linux, но хотите оперативно устранять сбои и решать нестандартные задачи при настройке серверов?
💪 Все продвинутые навыки — от баш-скриптов и умения гибко рулить авторизацией до применения подхода Infrastructure as code — ждут вас на онлайн-курсе «Administrator Linux. Professional» от OTUS.
Пройдите тестирование, чтобы:
- оценить свои навыки;
- занять место на курсе по специальной цене;
- получить доступ к бесплатным урокам курса (доступны сайте курса).
👉 Полное тестирование: https://otus.pw/A0v3/?erid=2W5zFHdRTFn
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
💪 Все продвинутые навыки — от баш-скриптов и умения гибко рулить авторизацией до применения подхода Infrastructure as code — ждут вас на онлайн-курсе «Administrator Linux. Professional» от OTUS.
Пройдите тестирование, чтобы:
- оценить свои навыки;
- занять место на курсе по специальной цене;
- получить доступ к бесплатным урокам курса (доступны сайте курса).
👉 Полное тестирование: https://otus.pw/A0v3/?erid=2W5zFHdRTFn
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
Сакральная желтая бумажка
С завидным постоянством наблюдем необъяснимое, можно даже сказать – сакральное отношение некоторых пользователей к пин-кодам программных лицензий 1С:Предприятие.
Когда любой предложение что-то там сделать разбивается о «да вы что, это же новый пин-код придется использовать». На встречный вопрос «а что в этом такого, они для этого и нужны» приходится выслушивать истории одна другой удивительнее.
Но все они сходятся к тому, что как закончатся пин-коды на бумажке, так сразу будет беда, все обязательно станет, лицензии слетят, а для их получения придется пройти сложный квест и прорваться сквозь злую поддержку.
Причина таких страшных сказок кроется не в системе программного лицензирования 1С:Предприятие, а в отсутствии культуры работы с ней.
Начнем с того, что любой лист программной лицензии содержит некоторое количество активных кодов и резервных к ним. Резервный коды нужны как раз для переактивации системы и сама поддержка 1С русским языком пишет:
Мы рекомендуем запрос доп пин-кода присылать сразу после использования последнего пин-кода, не дожидаясь запроса лицензии от программы. В запросе указывайте наименование организации, рег.номер лицензии и все цифры активного пин-кода, взамен которого требуется доп.пин-код.
По факту, если вы используете для обращения почту указанную при регистрации достаточно просто указать рег.номер лицензии и вам вышлют резервный пин-код в течении короткого времени.
Также та же самая поддержка рекомендует:
Также мы рекомендуем пользователям самостоятельно вести учет пин-кодов по всем программным лицензиям, указывая в таблице:
- рег.номер лицензии
- пин-код
- дату активации пин-кода
- имя компьютера, где активирован пин-код
- предыдущий пин-код (взамен которого активирован данный пин-код)
- имя файла, куда сохранены данные пользователя, указанные при первичном получении данной лицензии
Правила несложные, но мы очень редко видели, что кто-то им следует. Зато многократно сталкивались с тем, что администратор в принципе не имел понятия какой именно рег.номер лицензии на этом компьютере, какой пин-код активирован и с какими данными пользователя.
А в этом случае никакое наличие бумажек с кодами вам не поможет. Поэтому никакой сакральности в этих желтых бумажках нет. Нужно использовать код – используйте. И тут же запрашивайте новый. Задача полностью будничная, указали рег.номер – получили новый код. И никому не интересно зачем он вам и для чего.
Ну и не ждите слета лицензии, если по правилам она должна слететь. Просто переактивируйте не дожидаясь слета, а то, что она слетит – это 100%. И никакие соображения о мнимой «экономии» лицензий тут неприемлемы.
Экономить тут нечего и незачем, разве что заведомо спровоцировать остановку сервиса в самый неподходящий момент. Оно вам надо?
С завидным постоянством наблюдем необъяснимое, можно даже сказать – сакральное отношение некоторых пользователей к пин-кодам программных лицензий 1С:Предприятие.
Когда любой предложение что-то там сделать разбивается о «да вы что, это же новый пин-код придется использовать». На встречный вопрос «а что в этом такого, они для этого и нужны» приходится выслушивать истории одна другой удивительнее.
Но все они сходятся к тому, что как закончатся пин-коды на бумажке, так сразу будет беда, все обязательно станет, лицензии слетят, а для их получения придется пройти сложный квест и прорваться сквозь злую поддержку.
Причина таких страшных сказок кроется не в системе программного лицензирования 1С:Предприятие, а в отсутствии культуры работы с ней.
Начнем с того, что любой лист программной лицензии содержит некоторое количество активных кодов и резервных к ним. Резервный коды нужны как раз для переактивации системы и сама поддержка 1С русским языком пишет:
Мы рекомендуем запрос доп пин-кода присылать сразу после использования последнего пин-кода, не дожидаясь запроса лицензии от программы. В запросе указывайте наименование организации, рег.номер лицензии и все цифры активного пин-кода, взамен которого требуется доп.пин-код.
По факту, если вы используете для обращения почту указанную при регистрации достаточно просто указать рег.номер лицензии и вам вышлют резервный пин-код в течении короткого времени.
Также та же самая поддержка рекомендует:
Также мы рекомендуем пользователям самостоятельно вести учет пин-кодов по всем программным лицензиям, указывая в таблице:
- рег.номер лицензии
- пин-код
- дату активации пин-кода
- имя компьютера, где активирован пин-код
- предыдущий пин-код (взамен которого активирован данный пин-код)
- имя файла, куда сохранены данные пользователя, указанные при первичном получении данной лицензии
Правила несложные, но мы очень редко видели, что кто-то им следует. Зато многократно сталкивались с тем, что администратор в принципе не имел понятия какой именно рег.номер лицензии на этом компьютере, какой пин-код активирован и с какими данными пользователя.
А в этом случае никакое наличие бумажек с кодами вам не поможет. Поэтому никакой сакральности в этих желтых бумажках нет. Нужно использовать код – используйте. И тут же запрашивайте новый. Задача полностью будничная, указали рег.номер – получили новый код. И никому не интересно зачем он вам и для чего.
Ну и не ждите слета лицензии, если по правилам она должна слететь. Просто переактивируйте не дожидаясь слета, а то, что она слетит – это 100%. И никакие соображения о мнимой «экономии» лицензий тут неприемлемы.
Экономить тут нечего и незачем, разве что заведомо спровоцировать остановку сервиса в самый неподходящий момент. Оно вам надо?
👍26⚡1
Настраиваем таймеры systemd вместо заданий cron
Технологии постоянно развиваются, внося в нашу жизнь новые инструменты, которые вытесняют и заменяют старые и привычные нам. Но зачастую администраторы не спешат не только применять их на практике, но даже изучать.
Нет, здоровый консерватизм безусловно оправдан, но исключительно в разумных пределах. Гораздо хуже, когда внедрение новых технологий тормозится по надуманным или "идеологическим" причинам несмотря на то, что они предоставляют гораздо более широкие возможности.
Одна из таких технологий - таймеры systemd, которые позволяют по-новому взглянуть на некоторые классические задачи.
https://interface31.ru/tech_it/2021/04/nastraivaem-taymery-systemd-vmesto-zadaniy-cron.html
Технологии постоянно развиваются, внося в нашу жизнь новые инструменты, которые вытесняют и заменяют старые и привычные нам. Но зачастую администраторы не спешат не только применять их на практике, но даже изучать.
Нет, здоровый консерватизм безусловно оправдан, но исключительно в разумных пределах. Гораздо хуже, когда внедрение новых технологий тормозится по надуманным или "идеологическим" причинам несмотря на то, что они предоставляют гораздо более широкие возможности.
Одна из таких технологий - таймеры systemd, которые позволяют по-новому взглянуть на некоторые классические задачи.
https://interface31.ru/tech_it/2021/04/nastraivaem-taymery-systemd-vmesto-zadaniy-cron.html
👍39
Аренда IT-Оборудования от АТОМДАТА под любые задачи и масштаб
От базовых решений - до создания критической информационной инфраструктуры:
- Быстрое предоставление оборудования с собственного склада или подбор и закупка под проект;
- Оперативный подбор конфигурации под задачу, бюджет или по другими параметрам;
- Техническая поддержка 24/7. 3 линии поддержки
- Помощь с настройкой ПО и запуском оборудования;
- SLA 99,98 с финансовой компенсацией;
- Размещение оборудования в собственных ЦОДах "Росатома", а также партнерских ЦОДах в РФ или на площадке заказчика;
Бесплатное тестирование оборудования под задачу!
Подробности и бесплатная консультация
#реклама
О рекламодателе
От базовых решений - до создания критической информационной инфраструктуры:
- Быстрое предоставление оборудования с собственного склада или подбор и закупка под проект;
- Оперативный подбор конфигурации под задачу, бюджет или по другими параметрам;
- Техническая поддержка 24/7. 3 линии поддержки
- Помощь с настройкой ПО и запуском оборудования;
- SLA 99,98 с финансовой компенсацией;
- Размещение оборудования в собственных ЦОДах "Росатома", а также партнерских ЦОДах в РФ или на площадке заказчика;
Бесплатное тестирование оборудования под задачу!
Подробности и бесплатная консультация
#реклама
О рекламодателе
👍4
Шеф, все пропало!
В продолжение вчерашней темы, что делать если у вас вообще ничего не осталось. Или вы не знаете где это все.
Ситуация неприятная, но решаемая. Исходить будем из того, что лицензии по факту есть и куда-то установлены. Ну как куда-то, вариантов немного – сервер или рабочие станции пользователей.
Поэтому берем утилиту LicDataViewer или, если жалко 300 руб., утилиту ring и пытаемся получить доступную информацию из файлов лицензии. В результате вы узнаете:
Регистрационный номер поставки
Наименование продукте
Использованный пин-код
Регистрационная информация пользователя
Почта, на которую зарегистрирована лицензия
Все это сохраняем в надежном месте, эта информация нам еще понадобится.
Далее смотрим, если мы выяснили судьбу всех пин-кодов лицензии кроме резервных, то хорошо. Иначе пишем на линию лицензирования [email protected] и просим предоставить информацию о состоянии пин-кодов, в запросе указываем регистрационный номер поставки.
Если вы писали с почты, на который зарегистрирован продукт, то пин-коды придут в развернутом виде. Нет – часть кода будет закрыта звездочками, но это пока не важно. Нам нужен их статус.
Коды могут быть:
Активными – активирован на оборудовании
Использованными (заблокированными) – код использовался ранее, потом была выполнена повторная активация с резервным кодом
Резервные – свободный код для активации
Нас интересуют активные, они должны совпадать с фактически используемыми компьютерами, если же вы видите в этом списке непонятные имена ПК, то значит эти лицензии остаются активными на оборудовании, которое выведено из эксплуатации или утрачено.
По возможности находим эти ПК и удаляем файлы лицензии. Это исключит возможный слет лицензии по причине активации ее на более чем одном ПК.
Если же по факту у вас лицензия работает на одном ПК, а в присланной информации числится за другим, то лучше не ждать пока эти два узла окажутся включены одновременно и повторно получить лицензию на доступном ПК при помощи резервного кода.
В случае, когда коды закончились или утрачен листочек с программной лицензией, а доступа к почте нет, то снова обращаемся на линию поддержки и просим прислать резервный код, или коды, закрытые звездочкой указав всю доступную информацию, которую мы выдернули из файла лицензии.
Наконец, если файл лицензии утрачен (вышел из строя ПК и т.д.) и мы не знаем регистрационных данных, которые надо повторно ввести посимвольно, то снова пишем запрос на линию поддержки, в котором указываем всю доступную информацию, а также регистрационные данные, которые вы пытались вводить.
В этом случае вас могут попросить сформировать и прислать файл запроса лицензии. После чего предоставят в письме данные о регистрационной информации, которая была реально использована.
Ее луче переносить копипастом, а после успешной активации лицензии обязательно сохранить в виде файла.
Как видим, ничего страшного в данной ситуации нет, особенно если есть активные лицензии.
Если же нет, то вам достаточно знать регистрационный номер поставки и хотя бы приблизительно организацию или физическое лицо, на которое выполнялась активация. Если не помните, можете указать несколько. А дальше алгоритм тот же: состояние кодов, получение недостающих кодов, уточнение регистрационной информации.
В продолжение вчерашней темы, что делать если у вас вообще ничего не осталось. Или вы не знаете где это все.
Ситуация неприятная, но решаемая. Исходить будем из того, что лицензии по факту есть и куда-то установлены. Ну как куда-то, вариантов немного – сервер или рабочие станции пользователей.
Поэтому берем утилиту LicDataViewer или, если жалко 300 руб., утилиту ring и пытаемся получить доступную информацию из файлов лицензии. В результате вы узнаете:
Регистрационный номер поставки
Наименование продукте
Использованный пин-код
Регистрационная информация пользователя
Почта, на которую зарегистрирована лицензия
Все это сохраняем в надежном месте, эта информация нам еще понадобится.
Далее смотрим, если мы выяснили судьбу всех пин-кодов лицензии кроме резервных, то хорошо. Иначе пишем на линию лицензирования [email protected] и просим предоставить информацию о состоянии пин-кодов, в запросе указываем регистрационный номер поставки.
Если вы писали с почты, на который зарегистрирован продукт, то пин-коды придут в развернутом виде. Нет – часть кода будет закрыта звездочками, но это пока не важно. Нам нужен их статус.
Коды могут быть:
Активными – активирован на оборудовании
Использованными (заблокированными) – код использовался ранее, потом была выполнена повторная активация с резервным кодом
Резервные – свободный код для активации
Нас интересуют активные, они должны совпадать с фактически используемыми компьютерами, если же вы видите в этом списке непонятные имена ПК, то значит эти лицензии остаются активными на оборудовании, которое выведено из эксплуатации или утрачено.
По возможности находим эти ПК и удаляем файлы лицензии. Это исключит возможный слет лицензии по причине активации ее на более чем одном ПК.
Если же по факту у вас лицензия работает на одном ПК, а в присланной информации числится за другим, то лучше не ждать пока эти два узла окажутся включены одновременно и повторно получить лицензию на доступном ПК при помощи резервного кода.
В случае, когда коды закончились или утрачен листочек с программной лицензией, а доступа к почте нет, то снова обращаемся на линию поддержки и просим прислать резервный код, или коды, закрытые звездочкой указав всю доступную информацию, которую мы выдернули из файла лицензии.
Наконец, если файл лицензии утрачен (вышел из строя ПК и т.д.) и мы не знаем регистрационных данных, которые надо повторно ввести посимвольно, то снова пишем запрос на линию поддержки, в котором указываем всю доступную информацию, а также регистрационные данные, которые вы пытались вводить.
В этом случае вас могут попросить сформировать и прислать файл запроса лицензии. После чего предоставят в письме данные о регистрационной информации, которая была реально использована.
Ее луче переносить копипастом, а после успешной активации лицензии обязательно сохранить в виде файла.
Как видим, ничего страшного в данной ситуации нет, особенно если есть активные лицензии.
Если же нет, то вам достаточно знать регистрационный номер поставки и хотя бы приблизительно организацию или физическое лицо, на которое выполнялась активация. Если не помните, можете указать несколько. А дальше алгоритм тот же: состояние кодов, получение недостающих кодов, уточнение регистрационной информации.
👍29❤7
Почему современные приложения все чаще используют конфигурационные файлы в форматах JSON или YAML
Среди многих наших коллег очень часто возникает непонимание и даже возмущение, когда они сталкиваются с конфигурационными файлами в JSON или YAML. Основное нарекание вызывает «неудобный» формат, который заставляет контролировать пробелы или вложенность скобок.
То ли дело старый добрый текстовый конфиг. Когда-то я тоже не особо понимал это стремление и также временами возмущался свалившимися «на ровном месте» сложностями.
Но, по мере того как стал более плотно заниматься разработкой и разными обменами между разнотипными системами полностью поменял свое мнение.
Текстовый конфиг прост только на первый взгляд, с технической точки зрения это непрерывный поток символов, который нам нужно каждый раз полностью парсить и разбирать, при этом с учетом контекста, в случае, когда следующая запись относится к предыдущей.
Сложностей тут много, особенно учитывая, что строгого порядка написания конфигурационных файлов нет и тут может быть так, а там иначе.
А еще веселее становится, когда нам нужно настроить взаимодействие нескольких систем и вносит изменения в конфигурацию программно, допустим через API.
Особенно это касается всяких скриптов и панелек, которые должны сначала прочитать и показать вам текущую конфигурацию, а потом внести в нее изменения.
Каждый раз вам придется полностью читать и разбирать файл конфигурации, а потом еще решать задачу, как записать свои изменения правильно. Особенно если файл еще мог правиться вручную.
Поэтому истории известны множество историй, когда или панели ломали рабочие конфиги, либо после ручных правок ломалась работа панелей, либо сочетание этих обоих способов давало совершенно неожиданный результат.
Как быть?
Отказаться от текста в пользу структур. Основной особенностью JSON или YAML является то, что и то и другое набор объектов уровня ключ – значение, совокупность которых представляет из себя структуру.
Что такое структура хорошо известно любому, кто программирует на любом современном языке. И ее плюсы по сравнению с плоским текстом.
При этом каждый объект может как просто иметь значение, так и быть хранилищем еще одного объекта, позволяя создавать разветвленные структуры.
Но суть не в этом. Любая структура позволяет работать с собой избегая ее полного перебора.
Мы можем просто выполнить поиск по ключу и получить новую структуру, которая будет содержать только выбранные ключи и их значения.
Также просто и вносить изменения, мы находим нужный элемент структуры и добавляем в него новую пару ключ – значение.
И совершенно неважно, правили или будет править этот конфиг после нас руками. Благодаря структуре нам не надо анализировать текстовый файл и думать куда именно вставить изменения.
Есть структура и мы работаем именно с ней. В качестве примера, возьмем тот же Netplan.
Чтобы получить информацию о сетевых интерфейсах нам не надо читать весь файл, нам достаточно получить значение ключа ethernets, который будет содержать в качестве значения еще одну структуру, в которой уже ключом будет наименование сетевого адаптера.
Возможно, на первый взгляд, выглядит немного сложно, но на самом деле мы всегда знаем где что искать и откуда что удалять или добавлять, не боясь при этом пересечься с чьими-то правками и поломать синтаксис конфига.
Поэтому JSON или YAML будут все чаще использоваться для конфигурационных файлов по вполне объективными причинам.
Из минусов? Работать с ними в традиционных консольных текстовых редакторах неудобно, да это и не нужно.
В 21 веке существуют гораздо более удобные среды разработки, которые позволяют редактировать такие файлы с проверкой и подсветкой синтаксиса с рабочего ПК подключаясь к серверу по SSH.
Например, VS Code, про который мы рассказывали в нашей недавней статье:
🔹 Настраиваем Visual Studio Code для удаленной работы через SSH
Среди многих наших коллег очень часто возникает непонимание и даже возмущение, когда они сталкиваются с конфигурационными файлами в JSON или YAML. Основное нарекание вызывает «неудобный» формат, который заставляет контролировать пробелы или вложенность скобок.
То ли дело старый добрый текстовый конфиг. Когда-то я тоже не особо понимал это стремление и также временами возмущался свалившимися «на ровном месте» сложностями.
Но, по мере того как стал более плотно заниматься разработкой и разными обменами между разнотипными системами полностью поменял свое мнение.
Текстовый конфиг прост только на первый взгляд, с технической точки зрения это непрерывный поток символов, который нам нужно каждый раз полностью парсить и разбирать, при этом с учетом контекста, в случае, когда следующая запись относится к предыдущей.
Сложностей тут много, особенно учитывая, что строгого порядка написания конфигурационных файлов нет и тут может быть так, а там иначе.
А еще веселее становится, когда нам нужно настроить взаимодействие нескольких систем и вносит изменения в конфигурацию программно, допустим через API.
Особенно это касается всяких скриптов и панелек, которые должны сначала прочитать и показать вам текущую конфигурацию, а потом внести в нее изменения.
Каждый раз вам придется полностью читать и разбирать файл конфигурации, а потом еще решать задачу, как записать свои изменения правильно. Особенно если файл еще мог правиться вручную.
Поэтому истории известны множество историй, когда или панели ломали рабочие конфиги, либо после ручных правок ломалась работа панелей, либо сочетание этих обоих способов давало совершенно неожиданный результат.
Как быть?
Отказаться от текста в пользу структур. Основной особенностью JSON или YAML является то, что и то и другое набор объектов уровня ключ – значение, совокупность которых представляет из себя структуру.
Что такое структура хорошо известно любому, кто программирует на любом современном языке. И ее плюсы по сравнению с плоским текстом.
При этом каждый объект может как просто иметь значение, так и быть хранилищем еще одного объекта, позволяя создавать разветвленные структуры.
Но суть не в этом. Любая структура позволяет работать с собой избегая ее полного перебора.
Мы можем просто выполнить поиск по ключу и получить новую структуру, которая будет содержать только выбранные ключи и их значения.
Также просто и вносить изменения, мы находим нужный элемент структуры и добавляем в него новую пару ключ – значение.
И совершенно неважно, правили или будет править этот конфиг после нас руками. Благодаря структуре нам не надо анализировать текстовый файл и думать куда именно вставить изменения.
Есть структура и мы работаем именно с ней. В качестве примера, возьмем тот же Netplan.
Чтобы получить информацию о сетевых интерфейсах нам не надо читать весь файл, нам достаточно получить значение ключа ethernets, который будет содержать в качестве значения еще одну структуру, в которой уже ключом будет наименование сетевого адаптера.
Возможно, на первый взгляд, выглядит немного сложно, но на самом деле мы всегда знаем где что искать и откуда что удалять или добавлять, не боясь при этом пересечься с чьими-то правками и поломать синтаксис конфига.
Поэтому JSON или YAML будут все чаще использоваться для конфигурационных файлов по вполне объективными причинам.
Из минусов? Работать с ними в традиционных консольных текстовых редакторах неудобно, да это и не нужно.
В 21 веке существуют гораздо более удобные среды разработки, которые позволяют редактировать такие файлы с проверкой и подсветкой синтаксиса с рабочего ПК подключаясь к серверу по SSH.
Например, VS Code, про который мы рассказывали в нашей недавней статье:
🔹 Настраиваем Visual Studio Code для удаленной работы через SSH
👍29🤡12❤2
Почему такое потребление памяти контейнером с PostgreSQL в Proxmox
Anonymous Poll
7%
Для контейнеров память показывается некорректно
13%
Контейнеры хитро делят память с хостом
1%
PostgreSQL сам по себе экономичный
5%
Неправильно настроена конфигурация Postgres
2%
На NVMe дисках Postgres предпочитает читать, нежели занимать память
6%
Данные загружает в свою память сервер 1С, а не Postgres
25%
Proxmox некорректно показывает занятую память, учитывая только used, без buff/cache
2%
А не пофиг? Главное - работает
9%
Виртуалки - наше все! Контейнеры - хипстеркая ерунда
31%
Ничего не понятно, но очень интересно
Как и где айтишнику искать валютную удаленку?
Если вы знаете английский хотя бы на среднем уровне и имеете пару лет опыта работы.
Линкедин - не самый подходящий для этого ресурс, как тогда ее получить, договорившись о лучших для себя условиях?
Полина Мещерякова, основательница GOTHIRED, которая помогает с трудоустройством IT-специалистов в международные компании, рассказывает в своем свежем посте про Линкедин.
‼️Она также предоставит пошаговый план по поиску валютной удаленки на эфире 28 февраля в 18:00 по Москве в канале @efmchannel.
Cкорее подписывайтесь и забирайте после эфира подарок: 🎁 шаблон резюме для международной компании.
🚀Полина (ex-ООН, ех-МГИМО) помогла 150+ кандидатам трудоустроиться в ведущие компании - Вольво, Майкрософт и др., и выучить английский язык, присоединяйтесь!
#реклама
О рекламодателе
Если вы знаете английский хотя бы на среднем уровне и имеете пару лет опыта работы.
Линкедин - не самый подходящий для этого ресурс, как тогда ее получить, договорившись о лучших для себя условиях?
Полина Мещерякова, основательница GOTHIRED, которая помогает с трудоустройством IT-специалистов в международные компании, рассказывает в своем свежем посте про Линкедин.
‼️Она также предоставит пошаговый план по поиску валютной удаленки на эфире 28 февраля в 18:00 по Москве в канале @efmchannel.
Cкорее подписывайтесь и забирайте после эфира подарок: 🎁 шаблон резюме для международной компании.
🚀Полина (ex-ООН, ех-МГИМО) помогла 150+ кандидатам трудоустроиться в ведущие компании - Вольво, Майкрософт и др., и выучить английский язык, присоединяйтесь!
#реклама
О рекламодателе
❤1
Скорость виртуальной сети в Proxmox
После вчерашней публикации возник ряд вопросов по скорости виртуальной сети в пределах одного хоста.
Т.е. мы рассматриваем скорость сетевого взаимодействия между виртуальными машинами и/или контейнерами, находящимися на одном физическом гипервизоре и подключенных к одному сетевому мосту. При этом неважно, подключен данный мост к сетевому интерфейсу или нет.
Начнем с контейнеров. Контейнер с принципа не имеет сетевого интерфейса в его классическом понимании, нам нет необходимости что-то эмулировать на этом уровне, он просто пользуется ресурсами хоста.
В этом случае скорость лимитируется только вычислительными способностями CPU и пропускной способностью памяти и как правило измеряется в десятках Гбит/с.
Для виртуальных машин ситуация немного посложнее, там появляется эмулируемое оборудование и определенные сопутствующие потери на виртуализацию, также многое зависит от того, какой тип эмулируемого оборудования мы используем.
При использовании эмуляции реальных сетевых адаптеров, скажем E1000 мы можем упереться в ограничения драйвера. Если же используем полностью виртуальный VirtIO, то скорость также ограничивается только возможностями процессора и памяти.
Если сравнивать контейнер и виртуальную машину, то контейнер будет всегда немного быстрее, за счет меньших накладных расходов.
Что касается конкретных физических чисел, то на современном этапе развития вычислительной техники вы скорее всего упретесь в пропускную способность памяти.
Для примера мы выполнили тест на процессоре Core i5-4670 3,4 ГГц с 32 ГБ DDR3 2400 и получили значения около 35 Гбит/с, что близко к потолку пропускной способности этого типа памяти в двухканальном режиме (около 38 Гбит/с).
Поэтому бояться виртуальных сетей не нужно, скорость в пределах одного сетевого моста всегда будет выше физических возможностей относительно недорого Ethernet оборудования.
После вчерашней публикации возник ряд вопросов по скорости виртуальной сети в пределах одного хоста.
Т.е. мы рассматриваем скорость сетевого взаимодействия между виртуальными машинами и/или контейнерами, находящимися на одном физическом гипервизоре и подключенных к одному сетевому мосту. При этом неважно, подключен данный мост к сетевому интерфейсу или нет.
Начнем с контейнеров. Контейнер с принципа не имеет сетевого интерфейса в его классическом понимании, нам нет необходимости что-то эмулировать на этом уровне, он просто пользуется ресурсами хоста.
В этом случае скорость лимитируется только вычислительными способностями CPU и пропускной способностью памяти и как правило измеряется в десятках Гбит/с.
Для виртуальных машин ситуация немного посложнее, там появляется эмулируемое оборудование и определенные сопутствующие потери на виртуализацию, также многое зависит от того, какой тип эмулируемого оборудования мы используем.
При использовании эмуляции реальных сетевых адаптеров, скажем E1000 мы можем упереться в ограничения драйвера. Если же используем полностью виртуальный VirtIO, то скорость также ограничивается только возможностями процессора и памяти.
Если сравнивать контейнер и виртуальную машину, то контейнер будет всегда немного быстрее, за счет меньших накладных расходов.
Что касается конкретных физических чисел, то на современном этапе развития вычислительной техники вы скорее всего упретесь в пропускную способность памяти.
Для примера мы выполнили тест на процессоре Core i5-4670 3,4 ГГц с 32 ГБ DDR3 2400 и получили значения около 35 Гбит/с, что близко к потолку пропускной способности этого типа памяти в двухканальном режиме (около 38 Гбит/с).
Поэтому бояться виртуальных сетей не нужно, скорость в пределах одного сетевого моста всегда будет выше физических возможностей относительно недорого Ethernet оборудования.
👍57❤2
Как и зачем делить базы данных по отдельным установкам СУБД
В комментариях также спрашивали, как и по каким принципам делить базы по установкам экземпляров сервера БД и сколько памяти кому выделять.
Если брать конкретные цифры, то дать тут общие рекомендации сложно, нужно смотреть на сценарии применения, объемы данных, интенсивность и характер обращения к СУБД, в общем – требуется индивидуальный подход.
Поэтому вместо этого мы рассмотрим общие принципы, и вы могли понять для чего и зачем мы плодим установки и какие плюсы от этого получаем.
Описывая модель нами сознательно предельна упрощена и не требует каких-либо специфических знаний, а также применима к любым СУБД, а не только PostgreSQL.
Одной из задач СУБД – является быстрое и эффективное предоставление прикладному ПО доступа к хранящихся в базе данных. А получить мы их можем одним единственным образом – прочитать с диска.
Но чтение с диска – процесс дорогой и достаточно медленный. Поэтому, чтобы избежать повторного чтения СУБД помещает поднятые с диска данные в оперативную память. И делать так она будет до тех пор, пока будет иметь доступную память.
Именно этим объясняется известное всем стремление SQL-серверов занять всю доступную память. В простейших случаях, когда база по размеру гораздо меньше, чем размер оперативной памяти, то она будет закеширована практически вся.
Если же суммарный размер данных больше размера доступной памяти, то данные в кеше будут иметь приоритет по количеству обращений к ним. Таким образом более горячие данные будут вытеснять более холодные.
При достаточном количестве памяти через некоторое время будет достигнут некоторый баланс и все горячие данные будут в кеше. Иначе одни будут постоянно вытеснять другие и СУБД будет вынуждена постоянно прибегать к дисковому чтению.
Хотя это не всегда плохо, с появлением быстрых дисков, таких как NVMe, иногда более оптимально будет читать данные с диска, нежели тратить на их хранение достаточно ограниченный ресурс оперативной памяти.
А теперь про то, зачем делить базы по разным экземплярах СУБД. Представим, что у нас есть некоторый единый сервер, где находятся базы торгового подразделения и бухгалтерии.
Весь месяц бухгалтерия тихо вбивает первичку, проводит оплаты, а торговля торгует, получает остатки, взаиморасчеты, резервы и задолженности. Кеш прогрет, его хватает обоим базам и вроде бы все хорошо.
Но вот наступает конец месяца, и бухгалтерия начинает закрывать месяц, готовить отчетность, начислять зарплату, считать налоги, формировать регламентированные отчеты.
Объем потребляемых ею данных резко вырастет, и они просто вытеснят из кеша данные торгового отдела. И чем активнее будет работать бухгалтерия, тем хуже будет торговле.
При этом у бухгалтерии все хорошо, у них все летает, а у торговли раньше резервы или задолженность считались за пару секунд, а теперь программа тупит десятками секунд или минутами. Что вызывает сплошной негатив пользователей.
Также возможен обратный сценарий, когда торговля активно подбивает итоги и тормозит уже бухгалтерия.
Какой выход? В лоб – добавить память. Но опять-таки мы не можем гарантировать, что кто-то не перетянет на себя все одеяло, разве что памяти с запасом хватит на всех. Но это не про современные объемы данных.
Поэтому просто делим один экземпляр СУБД на два и каждому выделяем свое количество памяти. Да, в итоге каждый получит меньше, чем мог бы откусить из общей кучи и может начать работать немного медленнее.
Но это будет гарантированная производительность, особенно после того, как вы определите достаточный объем памяти для хранения всего горячего кеша. Соседи могут делать все, что угодно. Равно как и вы.
Но теперь мы можем анализировать и оптимизировать выделение ресурсов под единственный характер нагрузки. Можем делать быстрее, можем медленнее, но самого плохого сценария – качелей, когда сегодня все летает, а завтра все тормозит – мы избежим.
При этом накладные расходы на дублирование экземпляров СУБД минимальные, особенно если мы используем контейнеры.
В комментариях также спрашивали, как и по каким принципам делить базы по установкам экземпляров сервера БД и сколько памяти кому выделять.
Если брать конкретные цифры, то дать тут общие рекомендации сложно, нужно смотреть на сценарии применения, объемы данных, интенсивность и характер обращения к СУБД, в общем – требуется индивидуальный подход.
Поэтому вместо этого мы рассмотрим общие принципы, и вы могли понять для чего и зачем мы плодим установки и какие плюсы от этого получаем.
Описывая модель нами сознательно предельна упрощена и не требует каких-либо специфических знаний, а также применима к любым СУБД, а не только PostgreSQL.
Одной из задач СУБД – является быстрое и эффективное предоставление прикладному ПО доступа к хранящихся в базе данных. А получить мы их можем одним единственным образом – прочитать с диска.
Но чтение с диска – процесс дорогой и достаточно медленный. Поэтому, чтобы избежать повторного чтения СУБД помещает поднятые с диска данные в оперативную память. И делать так она будет до тех пор, пока будет иметь доступную память.
Именно этим объясняется известное всем стремление SQL-серверов занять всю доступную память. В простейших случаях, когда база по размеру гораздо меньше, чем размер оперативной памяти, то она будет закеширована практически вся.
Если же суммарный размер данных больше размера доступной памяти, то данные в кеше будут иметь приоритет по количеству обращений к ним. Таким образом более горячие данные будут вытеснять более холодные.
При достаточном количестве памяти через некоторое время будет достигнут некоторый баланс и все горячие данные будут в кеше. Иначе одни будут постоянно вытеснять другие и СУБД будет вынуждена постоянно прибегать к дисковому чтению.
Хотя это не всегда плохо, с появлением быстрых дисков, таких как NVMe, иногда более оптимально будет читать данные с диска, нежели тратить на их хранение достаточно ограниченный ресурс оперативной памяти.
А теперь про то, зачем делить базы по разным экземплярах СУБД. Представим, что у нас есть некоторый единый сервер, где находятся базы торгового подразделения и бухгалтерии.
Весь месяц бухгалтерия тихо вбивает первичку, проводит оплаты, а торговля торгует, получает остатки, взаиморасчеты, резервы и задолженности. Кеш прогрет, его хватает обоим базам и вроде бы все хорошо.
Но вот наступает конец месяца, и бухгалтерия начинает закрывать месяц, готовить отчетность, начислять зарплату, считать налоги, формировать регламентированные отчеты.
Объем потребляемых ею данных резко вырастет, и они просто вытеснят из кеша данные торгового отдела. И чем активнее будет работать бухгалтерия, тем хуже будет торговле.
При этом у бухгалтерии все хорошо, у них все летает, а у торговли раньше резервы или задолженность считались за пару секунд, а теперь программа тупит десятками секунд или минутами. Что вызывает сплошной негатив пользователей.
Также возможен обратный сценарий, когда торговля активно подбивает итоги и тормозит уже бухгалтерия.
Какой выход? В лоб – добавить память. Но опять-таки мы не можем гарантировать, что кто-то не перетянет на себя все одеяло, разве что памяти с запасом хватит на всех. Но это не про современные объемы данных.
Поэтому просто делим один экземпляр СУБД на два и каждому выделяем свое количество памяти. Да, в итоге каждый получит меньше, чем мог бы откусить из общей кучи и может начать работать немного медленнее.
Но это будет гарантированная производительность, особенно после того, как вы определите достаточный объем памяти для хранения всего горячего кеша. Соседи могут делать все, что угодно. Равно как и вы.
Но теперь мы можем анализировать и оптимизировать выделение ресурсов под единственный характер нагрузки. Можем делать быстрее, можем медленнее, но самого плохого сценария – качелей, когда сегодня все летает, а завтра все тормозит – мы избежим.
При этом накладные расходы на дублирование экземпляров СУБД минимальные, особенно если мы используем контейнеры.
👍40👌5
Слышали ли вы, что...
❓SRE — это просто «продвинутый DevOps»,
❓внедрение SRE требует огромных ресурсов и подходит только гигантам вроде Google,
❓SRE занимается только устранением инцидентов.
Правда в том, что эти и многие другие убеждения далеки от реальности. Мы собрали для вас PDF-файл, в котором разоблачаем самые популярные мифы о SRE.
Это must-have для тех, кто хочет понять, как SRE может помочь именно вашей работе и бизнесу, без лишних сложностей и заблуждений.
📍Переходите к боту-помощнику и забирайте полезный PDF прямо сейчас 🔗
Реклама. ООО "СЛЁРМ". ИНН 3652901451. erid: 2W5zFGhuBRi
❓SRE — это просто «продвинутый DevOps»,
❓внедрение SRE требует огромных ресурсов и подходит только гигантам вроде Google,
❓SRE занимается только устранением инцидентов.
Правда в том, что эти и многие другие убеждения далеки от реальности. Мы собрали для вас PDF-файл, в котором разоблачаем самые популярные мифы о SRE.
Это must-have для тех, кто хочет понять, как SRE может помочь именно вашей работе и бизнесу, без лишних сложностей и заблуждений.
📍Переходите к боту-помощнику и забирайте полезный PDF прямо сейчас 🔗
Реклама. ООО "СЛЁРМ". ИНН 3652901451. erid: 2W5zFGhuBRi
Тонкие настройки LXC. Процессор
Мы активно используем контейнеры LXC и постоянно сталкиваемся с необходимостью их тонкой настройки. Поэтому в данной заметке мы приведем только то, с чем постоянно имеем дело и что может вам пригодиться, не перегружая ее теоретической информацией.
Для примера возьмем задачу, когда у нас есть некоторый процессор 16 ядер / 32 потока и мы хотим разместить на нем сервер 1С, сервер СУБД и всяко-разно по мелочи.
Сервер 1С версии ПРОФ может использовать не более 12 ядер, но просто взять и указать в его настройках ограничение по ядрам мы не можем, потому что при старте контейнер будет выбирать ядра случайным образом, что ведет к изменению процессора и слету лицензии 1С.
Поэтому укажем ядра явно, для этого в конфигурационный файл /etc/pve/lxc/nnn.conf (где nnn – ID контейнера) добавим:
Это заставит его использовать 12 первых ядер. Ядра нумеруются начиная с нуля. Можно указывать отдельные номера через запятую или диапазон через тире, оба способа можно комбинировать. Например:
Серверу 1С ядра выделили, но остальные контейнеры, даже будучи ограниченными по количеству ядер могут использовать ядра совместно с сервером 1С, хотя у нас есть много еще свободных.
Поэтому явно указываем доступные ядра и для других машин, скажем 12-23 серверу СУБД и диапазон 24-31 для всех остальных.
В многопроцессорных системах дополнительно можно указать номер узла NUMA который может использовать контейнер, это позволит избежать задержек, когда процессор работая на ядрах одного процессора будет обращаться к памяти, которую обслуживает другой процессор.
Для этого используйте:
Где цифра указывает номер узла NUMA начиная с нуля, можем указать несколько значений с нуля или через запятую.
Хорошо, когда ядер много и можно всем раздать, но как быть, если процессорные ресурсы делятся между несколькими контейнерами. В этом случае следует настроить лимиты. Как мы помним, процессорное время выделяется процессам порциями – тиками. Если тиков всем не хватает – собирается очередь.
Это ведет к росту LA, значение LA в 1 на ядро означает, что свободных тиков нет, а значение более единицы указывает на наличие очереди.
Начнем с гибкого лимита, который позволяет установить относительный приоритет процессов, для этого мы используем следующий параметр:
Число 512 указывает приоритет, он может принимать значение от 1 до 1024, значение по умолчанию – 1024. Таким образом контейнер со значением 512 в случае возникновения конкуренции за ресурсы получит в два раза меньше тиков, чем контейнер без этой настройки.
Если же тиков хватает всем, либо более привилегированный контейнер не проявляет большой активности, то ограничения не применяются. Но если вдруг ему снова потребуются ресурсы, то они будут выделены в первую очередь.
Вместе с мягким есть и жесткое ограничение, когда мы просто не выделяем процессорных ресурсов более лимита, при этом у нас не растет очередь и процессы контейнера ограничены указанными рамками вне зависимости от наличия свободного ресурса.
Числа означают следующее: максимальное время использования ЦПУ, период в течении которого применяется ограничение в микросекундах. В приведенном примере мы выделили контейнеру половину процессорного ресурса. И он не сможет никогда его превысить, даже если процессор полностью простаивает.
Ну и наконец мы можем полностью закрепить ядро за контейнером, после чего ни один другой контейнер не сможет его использовать, если ядро занято хоть одним процессом назначенного ему контейнера.
Это позволяет обеспечить гарантированную производительность критичным сервисам.
Этот параметр нужно обязательно сочетать с
При этом мы можем выделить контейнеру большее количество ядер, скажем 8, но в эксклюзивное использование ему перейдут только 4, а за остальные он будет конкурировать с другими контейнерами.
Мы активно используем контейнеры LXC и постоянно сталкиваемся с необходимостью их тонкой настройки. Поэтому в данной заметке мы приведем только то, с чем постоянно имеем дело и что может вам пригодиться, не перегружая ее теоретической информацией.
Для примера возьмем задачу, когда у нас есть некоторый процессор 16 ядер / 32 потока и мы хотим разместить на нем сервер 1С, сервер СУБД и всяко-разно по мелочи.
Сервер 1С версии ПРОФ может использовать не более 12 ядер, но просто взять и указать в его настройках ограничение по ядрам мы не можем, потому что при старте контейнер будет выбирать ядра случайным образом, что ведет к изменению процессора и слету лицензии 1С.
Поэтому укажем ядра явно, для этого в конфигурационный файл /etc/pve/lxc/nnn.conf (где nnn – ID контейнера) добавим:
lxc.cgroup2.cpuset.cpus = 0-11
Это заставит его использовать 12 первых ядер. Ядра нумеруются начиная с нуля. Можно указывать отдельные номера через запятую или диапазон через тире, оба способа можно комбинировать. Например:
lxc.cgroup2.cpuset.cpus = 0, 1, 8-10,17-20
Серверу 1С ядра выделили, но остальные контейнеры, даже будучи ограниченными по количеству ядер могут использовать ядра совместно с сервером 1С, хотя у нас есть много еще свободных.
Поэтому явно указываем доступные ядра и для других машин, скажем 12-23 серверу СУБД и диапазон 24-31 для всех остальных.
В многопроцессорных системах дополнительно можно указать номер узла NUMA который может использовать контейнер, это позволит избежать задержек, когда процессор работая на ядрах одного процессора будет обращаться к памяти, которую обслуживает другой процессор.
Для этого используйте:
lxc.cgroup2.cpuset.mems: 0
Где цифра указывает номер узла NUMA начиная с нуля, можем указать несколько значений с нуля или через запятую.
Хорошо, когда ядер много и можно всем раздать, но как быть, если процессорные ресурсы делятся между несколькими контейнерами. В этом случае следует настроить лимиты. Как мы помним, процессорное время выделяется процессам порциями – тиками. Если тиков всем не хватает – собирается очередь.
Это ведет к росту LA, значение LA в 1 на ядро означает, что свободных тиков нет, а значение более единицы указывает на наличие очереди.
Начнем с гибкого лимита, который позволяет установить относительный приоритет процессов, для этого мы используем следующий параметр:
lxc.cgroup2.cpu.shares: 512
Число 512 указывает приоритет, он может принимать значение от 1 до 1024, значение по умолчанию – 1024. Таким образом контейнер со значением 512 в случае возникновения конкуренции за ресурсы получит в два раза меньше тиков, чем контейнер без этой настройки.
Если же тиков хватает всем, либо более привилегированный контейнер не проявляет большой активности, то ограничения не применяются. Но если вдруг ему снова потребуются ресурсы, то они будут выделены в первую очередь.
Вместе с мягким есть и жесткое ограничение, когда мы просто не выделяем процессорных ресурсов более лимита, при этом у нас не растет очередь и процессы контейнера ограничены указанными рамками вне зависимости от наличия свободного ресурса.
lxc.cgroup2.cpu.max: 50000 100000
Числа означают следующее: максимальное время использования ЦПУ, период в течении которого применяется ограничение в микросекундах. В приведенном примере мы выделили контейнеру половину процессорного ресурса. И он не сможет никогда его превысить, даже если процессор полностью простаивает.
Ну и наконец мы можем полностью закрепить ядро за контейнером, после чего ни один другой контейнер не сможет его использовать, если ядро занято хоть одним процессом назначенного ему контейнера.
Это позволяет обеспечить гарантированную производительность критичным сервисам.
lxc.cgroup2.cpuset.cpu_exclusive = 1
Этот параметр нужно обязательно сочетать с
lxc.cgroup2.cpuset.cpus = 0-3
При этом мы можем выделить контейнеру большее количество ядер, скажем 8, но в эксклюзивное использование ему перейдут только 4, а за остальные он будет конкурировать с другими контейнерами.
👍61🔥12
По этой теме не утихают холивары, поэтому повторим данный материал.
Папка, каталог или директория?
Данный вопрос давно занимает умы коллег и является предметом частых споров на счет того, какой из этих терминов является единственно правильным.
Сегодня в очередной раз пришлось столкнуться с измышлениями на данную тему, что и послужило поводом для написания данной заметки.
Начнем с языковых трудностей. В английском языке есть два слова: directory и catalog, которые переводятся на русский как каталог.
Но имеют различный смысл, directory, по сути, ближе к справочнику, это список однотипных данных, предназначенный для поиска по нему. Например: телефонный или адресный справочник.
Но встречаются и варианты со словом каталог, скажем, каталог запчастей. Хотя на английском все это будет directory (Parts Directory).
Слово catalog применяется для коллекций однотипных элементов предполагающий их более широкий выбор и обработку. Например, каталог марок, монет, книг. Каталог интернет-магазина и т.д. и т.п. Т.е. каталог не предназначен только для поиска, а содержит исчерпывающие данные о каждом элементе, позволяя подробно ознакомиться с ним.
Но вернемся к файловым системам, первоначально файловые системы были плоские, т.е. все файлы находились в единственном корневом каталоге. Потом возникла иерархия на основе тех самых каталогов.
Каталог представлял и представляет специальный файл с набором записей о принадлежащих ему файлах и подкаталогах, которые содержат имя объекта и ссылку на место файловой системы (кластер, inode) где он хранится.
В английском языке данная структура однозначно попадает под понятие directory и на русский переводится как каталог. И литературно правильно использовать именно этот термин.
Слово директория возникло в любительских переводах 90-х, когда этим занимались различные энтузиасты и представляет обычную транслитерацию слова directory. По подобному принципу возникли флоппи и хард диски вместо гибких и жестких.
Но данный термин плотно вошел сначала в компьютерный сленг, а после и в русский язык и также обрел массовое употребление.
В настоящий момент слово директория употребляется в том числе и серьезной компьютерной литературе в качестве синонима слова каталог и их можно считать полностью равнозначными.
За рубежом же никакого разночтения не было и повсеместно использовался термин directory, что нашло отражение в командах: cd, dir, mkdir и т.д.
Иногда встречается ошибочное мнение, что директории – это в UNIX/Linux, а каталоги в DOS/Windows, однако это не так. Достаточно взять англоязычные версии и убедиться, что кроме directory никаких иных терминов не используется.
Шло время, компьютеры становились все более распространенными и все чаще работать с ними начинали обычные пользователи, далекие от всех этих технических терминов.
Чтобы облегчить им работу была придумана концепция рабочего стола, который логически повторял обычный рабочий стол. Файлы представлялись как документы, а каталоги как папки (folder) с этими документами.
С тех пор повелось файлы изображать преимущественно в виде близком бумажным документам, а каталоги в виде канцелярских папок. Такой подход впервые был внедрен в Apple в Mac System Software, предшественнице Mac OS.
Начиная с Windows 95 папки стали использоваться в ОС Microsoft, а также перекочевали в графические оболочки Linux, первоначально в KDE и GNOME.
Со временем термин стал общеупотребительным и стал употребляться наравне с directory (каталогом). В русском языке появилось сразу три термина обозначающие одно и то же: каталог, папка и директория.
Существует еще одно заблуждение, что термин папка можно применять только в графической среде. Однако это не так. Каталог – это объект файловой системы и его свойства не меняются в зависимости от наличия или отсутствия графической оболочки. И поэтому мы можем называть его любым из этих трех терминов.
Папка, каталог или директория?
Данный вопрос давно занимает умы коллег и является предметом частых споров на счет того, какой из этих терминов является единственно правильным.
Сегодня в очередной раз пришлось столкнуться с измышлениями на данную тему, что и послужило поводом для написания данной заметки.
Начнем с языковых трудностей. В английском языке есть два слова: directory и catalog, которые переводятся на русский как каталог.
Но имеют различный смысл, directory, по сути, ближе к справочнику, это список однотипных данных, предназначенный для поиска по нему. Например: телефонный или адресный справочник.
Но встречаются и варианты со словом каталог, скажем, каталог запчастей. Хотя на английском все это будет directory (Parts Directory).
Слово catalog применяется для коллекций однотипных элементов предполагающий их более широкий выбор и обработку. Например, каталог марок, монет, книг. Каталог интернет-магазина и т.д. и т.п. Т.е. каталог не предназначен только для поиска, а содержит исчерпывающие данные о каждом элементе, позволяя подробно ознакомиться с ним.
Но вернемся к файловым системам, первоначально файловые системы были плоские, т.е. все файлы находились в единственном корневом каталоге. Потом возникла иерархия на основе тех самых каталогов.
Каталог представлял и представляет специальный файл с набором записей о принадлежащих ему файлах и подкаталогах, которые содержат имя объекта и ссылку на место файловой системы (кластер, inode) где он хранится.
В английском языке данная структура однозначно попадает под понятие directory и на русский переводится как каталог. И литературно правильно использовать именно этот термин.
Слово директория возникло в любительских переводах 90-х, когда этим занимались различные энтузиасты и представляет обычную транслитерацию слова directory. По подобному принципу возникли флоппи и хард диски вместо гибких и жестких.
Но данный термин плотно вошел сначала в компьютерный сленг, а после и в русский язык и также обрел массовое употребление.
В настоящий момент слово директория употребляется в том числе и серьезной компьютерной литературе в качестве синонима слова каталог и их можно считать полностью равнозначными.
За рубежом же никакого разночтения не было и повсеместно использовался термин directory, что нашло отражение в командах: cd, dir, mkdir и т.д.
Иногда встречается ошибочное мнение, что директории – это в UNIX/Linux, а каталоги в DOS/Windows, однако это не так. Достаточно взять англоязычные версии и убедиться, что кроме directory никаких иных терминов не используется.
Шло время, компьютеры становились все более распространенными и все чаще работать с ними начинали обычные пользователи, далекие от всех этих технических терминов.
Чтобы облегчить им работу была придумана концепция рабочего стола, который логически повторял обычный рабочий стол. Файлы представлялись как документы, а каталоги как папки (folder) с этими документами.
С тех пор повелось файлы изображать преимущественно в виде близком бумажным документам, а каталоги в виде канцелярских папок. Такой подход впервые был внедрен в Apple в Mac System Software, предшественнице Mac OS.
Начиная с Windows 95 папки стали использоваться в ОС Microsoft, а также перекочевали в графические оболочки Linux, первоначально в KDE и GNOME.
Со временем термин стал общеупотребительным и стал употребляться наравне с directory (каталогом). В русском языке появилось сразу три термина обозначающие одно и то же: каталог, папка и директория.
Существует еще одно заблуждение, что термин папка можно применять только в графической среде. Однако это не так. Каталог – это объект файловой системы и его свойства не меняются в зависимости от наличия или отсутствия графической оболочки. И поэтому мы можем называть его любым из этих трех терминов.
👍33🥱11👎3