делал нечто подобное, но для связки vcenter + netbox, тоже инвентарил гиппервизоры и виртуалки, только на PoSh.
Netbox прикольный, но только нужно понять, что все крутится вокруг id, у каждой сущности он есть, будь то IP или интерфейс. То есть чтобы заинвентарить тачку, нужно её создать, создать интерфейс, создать ip, потом проассоциировать все это друг с другом.
Из плюсов, можно создавать кастомные поля и заполнять их своими данными. Я так хранил id виртуалки, а специальный обработчик(не я делал, там что-то с помощью питона и внутреннего интерпретатора) создавал кнопку, нажимая на которую переходил по ссылке на виртаулку.
Потом виртуалки стали более эфемерными и смысл их инвентарить пропал. Все должно быть в виде кода в гите.
У нас я использую это для работы Компаса на сервере для конструкторов. То есть 3D модельки нормально отрисовываются и в целом нагрузка идет именно на GPU.
Другое дело, я не смог настроить справедливое разделение ресурсов, но если сравнивать по цене, это топ. Дело в том, что альтернатива это платные лицензии Nvidia на виртуальные GPU, еще более дорогие сами GPU. Плюс не тривиальная настройка.
А так какую-нибудь не сильно дорогую GPU Ampere на сервере RDS вполне хватает на несколько человек.
Чей-то домашний осмос себя изжил? Для стирки/посудомойки такой подход и правда оправдан, смысл в том, чтобы на тэнах и поверхностях не оседал известковый налет и ржавчина. Соли просто переводятся в растворимый вид и не оседают, по железу все верно, оно остается в фильтре. Но для увлажнения желательно воду близкой по чистоте к дистиллированной. То есть то, что в воде хорошо растворяется в воде останется и будет в воздухе в виде взвесей.
При таком подходе воздух мб лучше прогонять через увлажненные поверхности как в допотопных кондиционерах(желательно медных, чтоб ничего не выросло). Но даже так, все будет зарастать отложениями. Вопрос только будут они на испарителе или в воздухе как с туманом.
Обратный осмос не такой уж и дорогой. У меня дома есть робот пылесос со станцией самоочистки, тряпочки полощет на станции. Потом воду обратно собирает в бак для грязной воды. Бак для чистой воды набираю из под фильтра обратноосмотического. У нас очень жесткая вода и мне не хотелось бы в нем отложений. Можно заливать трилоном Б, но ведь все эти минералы останутся на поверхности которые пылесос протирает. А в стиралку норм, досыпаю немного при каждой стирке.
PS Вообще хотелось бы два краника из под осмоса, один технический, другой после постфильтра минерализатора. Для утюга и бака станции самоочистки.
я не настоящий девопсер, но есть же kraken или dragonfly - p2p распространение докер образов. Хотя это не решит проблему высокой нагрузки на диск при pull, только ускорит само скачивание образов. С другой стороны у dragonfly тоже есть прогрев, но прогреет он только кэш самого dragonfly, а не кэш докера.
Это связано с тем, что любой, у кого есть доступ к файлу, может использовать его для аутентификации, не зная фактического пароля. Кстати, по похожему принципу построена атака pass the hash, когда злоумышленник вместо пароля использует его хэш, и этого бывает достаточно для аутентификации в системе.
$pwd = read-host "password:" -AsSecureString
$Encrypted = ConvertFrom-SecureString -SecureString $pwd Для шифрования используется API защиты данных Windows (DPAPI), расшифровать можно только из профиля пользователя(сеанса). Если просто получить доступ к строке, то без доступа к учетке пользователя не получится расшифровать.
С тем же успехом можно утверждать, что пароль можно дернуть из кред менеджера через
на windows используется в лучшем случае WSL под капотом которого старый добрый Hyper-v. Используете вы скорее всего docker desktop, который в свою очередь требует лицензионного соглашения. Да и в целом он всегда был тормозным и весьма глючным. У себя использую rancher desktop, при прочих равных куда меньше проблем с ним.
У меня стройкое предубеждение, что докер на windows использует не все ядра с хоста при запуске.
Но в любом случае, существуют накладные расходы на виртуализацию. А еще при долгой работе появляется куча мусора, старые контейнеры, слои, кеши. Виртуальный диск WSL разрастается и с удивлением видим забитый диск C.
Этот плагин же поддерживает работу в удаленной среде, проще завести на вашем гипервизоре виртуалку на Linux с докером. Не нужно будет мощное железо, да регламентную очистку будет проще делать. А то и вообще в кубере запускать.
Большинство ролей для сервера которые здесь перечислены это скорее сервис и как правило он развернут на виртуальной машине.
Речь в статье по контексту идет о серверном железе. В этом смысле сервера отличаются только вендорозависмыми фичами(и то это в основном IPMI), количеством ядер и их частоте, поддерживаемым количеством оперативной памяти. Остальное либо идет из коробки, либо добавляется в слоты PCI-E, в этом серверное железо не отличается от десктопного. Единственное, логично, что под холодное хранение нужны HDD и под задачи, где узким местом является дисковая система - нужны SSD и вполне вероятно которые NVMe.
А вот про разные дисковые интерфейсы на плате их стандартах и прочее, было бы интересно, особенно про новые U2.
делал нечто подобное, но для связки vcenter + netbox, тоже инвентарил гиппервизоры и виртуалки, только на PoSh.
Netbox прикольный, но только нужно понять, что все крутится вокруг id, у каждой сущности он есть, будь то IP или интерфейс. То есть чтобы заинвентарить тачку, нужно её создать, создать интерфейс, создать ip, потом проассоциировать все это друг с другом.
Из плюсов, можно создавать кастомные поля и заполнять их своими данными. Я так хранил id виртуалки, а специальный обработчик(не я делал, там что-то с помощью питона и внутреннего интерпретатора) создавал кнопку, нажимая на которую переходил по ссылке на виртаулку.
Потом виртуалки стали более эфемерными и смысл их инвентарить пропал. Все должно быть в виде кода в гите.
тема S3 select не раскрыта
S3 select + json или parquet
У нас я использую это для работы Компаса на сервере для конструкторов. То есть 3D модельки нормально отрисовываются и в целом нагрузка идет именно на GPU.
Другое дело, я не смог настроить справедливое разделение ресурсов, но если сравнивать по цене, это топ. Дело в том, что альтернатива это платные лицензии Nvidia на виртуальные GPU, еще более дорогие сами GPU. Плюс не тривиальная настройка.
А так какую-нибудь не сильно дорогую GPU Ampere на сервере RDS вполне хватает на несколько человек.
Может кто уже писал, но зря вы недооцениваете RDP, аппаратная поддержка GPU того стоит.
WIN + R
gpedit.msc
Конфигурация компьютера > Административные шаблоны > Компоненты Windows > Службы удаленных рабочих столов > Узел сеансов удаленных рабочих столов > Среда удаленных сеансов
Использовать аппаратные видеоадаптеры для всех сеансов служб удаленных рабочих столов - Включено
Единственное, я не смог распределить нагрузку по сеансам на разные GPU, экспериментировал с серверов RDS и несколькими пользователями.
Там же можно поиграться с UDP
Erlang, I love you.
точно, есть. Правда у меня на кухне кран встроенный в обычный кран для воды с переключателем.
Придется дополнительный кран подключать, но может оно и не плохо.
Чей-то домашний осмос себя изжил? Для стирки/посудомойки такой подход и правда оправдан, смысл в том, чтобы на тэнах и поверхностях не оседал известковый налет и ржавчина. Соли просто переводятся в растворимый вид и не оседают, по железу все верно, оно остается в фильтре. Но для увлажнения желательно воду близкой по чистоте к дистиллированной. То есть то, что в воде хорошо растворяется в воде останется и будет в воздухе в виде взвесей.
При таком подходе воздух мб лучше прогонять через увлажненные поверхности как в допотопных кондиционерах(желательно медных, чтоб ничего не выросло). Но даже так, все будет зарастать отложениями. Вопрос только будут они на испарителе или в воздухе как с туманом.
Обратный осмос не такой уж и дорогой. У меня дома есть робот пылесос со станцией самоочистки, тряпочки полощет на станции. Потом воду обратно собирает в бак для грязной воды. Бак для чистой воды набираю из под фильтра обратноосмотического. У нас очень жесткая вода и мне не хотелось бы в нем отложений. Можно заливать трилоном Б, но ведь все эти минералы останутся на поверхности которые пылесос протирает. А в стиралку норм, досыпаю немного при каждой стирке.
PS Вообще хотелось бы два краника из под осмоса, один технический, другой после постфильтра минерализатора. Для утюга и бака станции самоочистки.
плюсую, только делать его на пару, потому что паром гораздо легче управлять
красные или синие?
Красные или синие?
Rancher manager/harvester
я не настоящий девопсер, но есть же kraken или dragonfly - p2p распространение докер образов. Хотя это не решит проблему высокой нагрузки на диск при pull, только ускорит само скачивание образов. С другой стороны у dragonfly тоже есть прогрев, но прогреет он только кэш самого dragonfly, а не кэш докера.
и теперь мы тут
он же не некромант
и сколько стоит?
$pwd = read-host "password:" -AsSecureString$Encrypted = ConvertFrom-SecureString -SecureString $pwdДля шифрования используется API защиты данных Windows (DPAPI), расшифровать можно только из профиля пользователя(сеанса). Если просто получить доступ к строке, то без доступа к учетке пользователя не получится расшифровать.С тем же успехом можно утверждать, что пароль можно дернуть из кред менеджера через
$Cred = Get-StoredCredential -Target PowerShell$pass = [Net.NetworkCredential]::new('', $cred.Password).Passwordна windows используется в лучшем случае WSL под капотом которого старый добрый Hyper-v. Используете вы скорее всего docker desktop, который в свою очередь требует лицензионного соглашения. Да и в целом он всегда был тормозным и весьма глючным. У себя использую rancher desktop, при прочих равных куда меньше проблем с ним.
https://learn.microsoft.com/en-us/windows/wsl/wsl-config - Стоит почитать по кастомной настройке WSL.
У меня стройкое предубеждение, что докер на windows использует не все ядра с хоста при запуске.
Но в любом случае, существуют накладные расходы на виртуализацию. А еще при долгой работе появляется куча мусора, старые контейнеры, слои, кеши. Виртуальный диск WSL разрастается и с удивлением видим забитый диск C.
Этот плагин же поддерживает работу в удаленной среде, проще завести на вашем гипервизоре виртуалку на Linux с докером. Не нужно будет мощное железо, да регламентную очистку будет проще делать. А то и вообще в кубере запускать.
Большинство ролей для сервера которые здесь перечислены это скорее сервис и как правило он развернут на виртуальной машине.
Речь в статье по контексту идет о серверном железе. В этом смысле сервера отличаются только вендорозависмыми фичами(и то это в основном IPMI), количеством ядер и их частоте, поддерживаемым количеством оперативной памяти. Остальное либо идет из коробки, либо добавляется в слоты PCI-E, в этом серверное железо не отличается от десктопного. Единственное, логично, что под холодное хранение нужны HDD и под задачи, где узким местом является дисковая система - нужны SSD и вполне вероятно которые NVMe.
А вот про разные дисковые интерфейсы на плате их стандартах и прочее, было бы интересно, особенно про новые U2.
микротик жи)