ch
Feedback

不要被骗子欺骗!Telemetrio 会找到并标记这些频道 👉 如果想查看标记,请订阅

Записки IT специалиста

Записки IT специалиста

前往频道在 Telegram

IT-канал, просто о сложном https://interface31.ru Купить рекламу: https://telega.in/c/interface31

显示更多
9 067
订阅者
无数据24 小时
+487 天
+6230 天
帖子存档
СИМВОЛ. Старт продаж в готовом квартале Выбирайте квартиру по стартовым ценам в финальной очереди квартала СИМВОЛ. Чтобы использовать все преимущества центра Москвы. И всюду успевать без спешки. И любоваться столицей из панорамных окон. - Дом внутри ТТК - 100+ открытых объектов инфраструктуры, в том числе школа - Самый большой двор в СИМВОЛЕ - 1,2 га - В доме детская, переговорная, коворкинг - Собственный парк "Зеленая река" площадью 10 га - 3 станции метро в пешей доступности СИМВОЛ - квартал в историческом районе Лефортово, в 2 км от Садового кольца. Узнать больше Проектная декларация на сайте https://наш.дом.рф/. Застройщик: ООО СЗ МАРТ. Финансовые услуги оказывает: Банк ВТБ (ПАО). #реклама simvol-kvartal.ru О рекламодателе

858 терабайт государственных данных Южной Кореи сгорели к чёртовой матери. Бэкапа просто не было 26 сентября 2025 года в госу
858 терабайт государственных данных Южной Кореи сгорели к чёртовой матери. Бэкапа просто не было 26 сентября 2025 года в государственном дата-центре National Information Resources Service (NIRS) в городе Тэджон вспыхнул пожар. За несколько часов огонь уничтожил серверы облачного хранилища G-Drive (от слова government), где чиновникам выделялось по 30 ГБ для хранения различных документов, которые запрещено было хранить на офисных компьютерах. Им пользовалось 17% всех федеральных чиновников в Корее, или около 125 тысяч человек. Но не только — там хранились данные ещё 163 онлайн-сервисов южнокорейского правительства. Масштаб потерь оценивается в 858 терабайт данных, которые могут быть утеряны навсегда. Среди пострадавших сервисов — регистрация бизнесов, проверка безопасности продуктов, сертификация импорта и экспорта, обработка визовых заявок. Представьте: вы подали документы на визу месяц назад, и вся эта информация просто испарилась. Или зарегистрировали компанию — и теперь никто не может подтвердить, что она вообще существует. ✅ Подробнее: https://habr.com/ru/articles/954512 В этой новости все прекрасно. И в очередной раз показывает, что госы - такие госы и не только у нас в стране.

Кто ты в коллективе? Узнай в нашем новом ИИ-тесте ⚡Кто-то душа компании, кто-то предпочитает продумывать стратегии, а кто-то
Кто ты в коллективе? Узнай в нашем новом ИИ-тесте ⚡Кто-то душа компании, кто-то предпочитает продумывать стратегии, а кто-то обладает лидерством... В честь голосования за лучшего работодателя на HH мы создали тест, который определит, какую роль в команде играете именно вы. ⚡ С вас — ответы на вопросы и голос, с нас — результаты и крутая ИИ-аватарка. Будь с командой первых!❤️ Узнать больше #реклама 16+ О рекламодателе

Расходы на виртуализацию. Краткие итоги Расходы на виртуализацию – это любимая тема для обсуждения, как только вопрос заходит
Расходы на виртуализацию. Краткие итоги Расходы на виртуализацию – это любимая тема для обсуждения, как только вопрос заходит об этой самой виртуализации. Но следует понимать следующее – мы живем в третьем десятилетии 21 века и основная рабочая нагрузка сейчас виртуализирована. Нравится, не нравится – но это де-факто новый стандарт. Причем мир все дальше уходит от виртуальных машин и отдает предпочтение контейнерам – LXC, Docker и т.д. Это нормальный и закономерный процесс, глупо его игнорировать или вставлять палки в колеса. Ничего хорошего здесь не выйдет, прогресс продолжит двигаться дальше, а вот вы вполне можете вылететь на его обочину со всеми неприятными вытекающими. Как мы уже показали в прошлых публикациях, которые мы повторили вчера и сегодня, накладные расходы на контейнеры практически равны нулю, накладные расходы на виртуальные машины сильно зависят от типа эмулируемого оборудования и тут уже надо смотреть для чего вам собственно эта виртуалка и какие задачи она решает. Скажем если это сервер лицензирования, то производительность там стоит на последнем месте, а главное неизменность набора железа. Поэтому мы выбираем эмулируемые устройства в ущерб производительности. Хотим переносимость между хостами с разными поколениями процессора – миримся с тем, что некоторые современные инструкции виртуалка не поддерживает. Желаем максимальную производительность – выбираем самые современные синтетические устройства. Но в любом случае расходы на виртуализацию не должны превышать 10-15%, если более, то вы что-то сделали не так, или сознательно пожертвовали производительностью ради иных преимуществ. А теперь вернемся к нашим процентам. Ребята, если для вас эти 10-15% являются критичными, то у меня плохая новость – ваша система не тянет рабочую нагрузку и справляется из последних сил. Откройте любую систему мониторинга и посмотрите пороги срабатывания триггеров по основным показателям. Примерно будет так: 80% - начинаем беспокоиться и принимать меры, 90% - бьем во все колокола, включаем сирену и вообще сигнализируем, что ситуация полный швах! А это как раз ваши 10-15% «потерянные» на виртуализации. Если так, то ваша система и без виртуализации не имела никакого запаса производительности и любой резкий скачок спокойно выбьет ее из седла, а виртуализация только подсветила проблему. Что касается производительности, то мы будем исходить из того, что высокие значения «попугаев» никому не нужны. Пользователи производственных систем не экстремальные геймеры и выжимать максимум из железа им без нужды. Есть определенный уровень комфортной эксплуатации и все что выше нее просто останется незамеченным. Если брать ту же 1С, то это 35-40 «попугаев» по Гилеву. Вы можете станцевать ужом на сковородке и обеспечить 60-70-100!!! Но кто это заметит? Поэтому, если мы удовлетворили базовую потребность пользователей в комфортной работе, то лишние вычислительные ресурсы можем смело потратить на инфраструктуру, ту же виртуализацию. Ну было у нас 75 «попугаев» Гилева, стало 65 – кто это заметит? Никто. Но за эти 10 «попугаев» мы приобретаем переносимость, высокую доступность, снижение затрат на сопровождение и многие другие плюшки. А мораль сей басни проста: нет ничего бесплатного, за все мы чем-то вынуждены платить. Но «попугаи» сами по себе не являются высшей ценностью, реальная эксплуатация всегда компромисс и не всегда в пользу высокой производительности.

НайтиIT в Санкт-Петербурге На "Найти IT" ты сможешь найти работу, пообщаться с работадателями и узнать всё о стажировках и ва
НайтиIT в Санкт-Петербурге На "Найти IT" ты сможешь найти работу, пообщаться с работадателями и узнать всё о стажировках и вакансиях! Кто будет: Альфа-Банк, Сбер, Ozon Tech, МТС, X5 Tech — больше 30 компаний, которые ищут студентов ИТ-специальностей Где и когда: Санкт-Петербург, DAA EXPO — 11 октября, 12:00–17:00 Зарегистрироваться #реклама careerday.fut.ru О рекламодателе

​​Скорость виртуальной сети в Proxmox После вчерашней публикации возник ряд вопросов по скорости виртуальной сети в пределах одного хоста. Т.е. мы рассматриваем скорость сетевого взаимодействия между виртуальными машинами и/или контейнерами, находящимися на одном физическом гипервизоре и подключенных к одному сетевому мосту. При этом неважно, подключен данный мост к сетевому интерфейсу или нет. Начнем с контейнеров. Контейнер с принципа не имеет сетевого интерфейса в его классическом понимании, нам нет необходимости что-то эмулировать на этом уровне, он просто пользуется ресурсами хоста. В этом случае скорость лимитируется только вычислительными способностями CPU и пропускной способностью памяти и как правило измеряется в десятках Гбит/с. Для виртуальных машин ситуация немного посложнее, там появляется эмулируемое оборудование и определенные сопутствующие потери на виртуализацию, также многое зависит от того, какой тип эмулируемого оборудования мы используем. При использовании эмуляции реальных сетевых адаптеров, скажем E1000 мы можем упереться в ограничения драйвера. Если же используем полностью виртуальный VirtIO, то скорость также ограничивается только возможностями процессора и памяти. Если сравнивать контейнер и виртуальную машину, то контейнер будет всегда немного быстрее, за счет меньших накладных расходов. Что касается конкретных физических чисел, то на современном этапе развития вычислительной техники вы скорее всего упретесь в пропускную способность памяти. Для примера мы выполнили тест на процессоре Core i5-4670 3,4 ГГц с 32 ГБ DDR3 2400 и получили значения около 35 Гбит/с, что близко к потолку пропускной способности этого типа памяти в двухканальном режиме (около 38 Гбит/с). Поэтому бояться виртуальных сетей не нужно, скорость в пределах одного сетевого моста всегда будет выше физических возможностей относительно недорого Ethernet оборудования.

🔥 Игнатий Цукергохер — айтишник с 15-летним опытом в IT-индустрии вещает с дивана про IT, кибербез и геймдев. В канале делюс
🔥 Игнатий Цукергохер — айтишник с 15-летним опытом в IT-индустрии вещает с дивана про IT, кибербез и геймдев. В канале делюсь добытыми мною эксклюзивными инсайдами и рассказываю про: ✅ Импортозамещение в IT и кибербезе: как Россия развивает свои технологии и как усиливает ИБ. ✅ Геймдев: новинки, тренды и отечественные игры. ✅ Крупные отраслевых события: конференции, выставки и запуски. ✅ Отечественные разработки: железо, софт, игры и многое другое. Подписывайся на канал чтобы читать новости от коллеги по отрасли! #IT #Игры #Новости #кибербез #ИгнатийЦукергохер

​​Сегодня в обсуждении возник вопрос о влиянии виртуализации на производительность. Поэтому решили провести небольшой экспресс-тест. Для начала хост, компьютер не очень мощный, даже наоборот, но в данном случае это не имеет никакого значения. Processor: Intel(R) Celeron(R) CPU J3355 @ 2.00GHz CPU cores: 2 Frequency: 2428.759 MHz RAM: 15Gi Swap: 8.0Gi Kernel: Linux 5.15.108-1-pve x86_64 Disks: sda 223.6G SSD CPU: SHA256-hashing 500 MB 5.458 seconds CPU: bzip2-compressing 500 MB 10.662 seconds CPU: AES-encrypting 500 MB 2.635 seconds ioping: seek rate min/avg/max/mdev = 103.4 us / 146.3 us / 6.43 ms / 67.6 us ioping: sequential read speed generated 8.81 k requests in 5.00 s, 2.15 GiB, 1.76 k iops, 440.4 MiB/s Теперь LXC контейнер: Processor: Intel(R) Celeron(R) CPU J3355 @ 2.00GHz CPU cores: 2 Frequency: 2500.000 MHz RAM: 2,0Gi Swap: 512Mi Kernel: Linux 5.15.108-1-pve x86_64 Disks: sda 223,6G SSD CPU: SHA256-hashing 500 MB 5,858 seconds CPU: bzip2-compressing 500 MB 11,333 seconds CPU: AES-encrypting 500 MB 2,666 seconds ioping: seek rate min/avg/max/mdev = 110.8 us / 163.9 us / 4.42 ms / 62.5 us ioping: sequential read speed generated 8.16 k requests in 5.00 s, 1.99 GiB, 1.63 k iops, 408.1 MiB/s Как видим - разница на уровне погрешности измерений. Поэтому можно смело говорить, что производительность контейнеров примерно равна производительности хоста. Теперь KVM виртуальная машина, значения по умолчанию. Processor: Common KVM processor CPU cores: 2 Frequency: 1996.800 MHz RAM: 3,9Gi Swap: 974Mi Kernel: Linux 4.19.0-20-amd64 x86_64 Disks: sda 8G HDD CPU: SHA256-hashing 500 MB 8,569 seconds CPU: bzip2-compressing 500 MB 15,707 seconds CPU: AES-encrypting 500 MB 15,507 seconds ioping: seek rate min/avg/max/mdev = 257.1 us / 698.5 us / 29.7 ms / 742.4 us ioping: sequential read speed generated 2.75 k requests in 5.00 s, 686.5 MiB, 549 iops, 137.3 MiB/s В отличии от контейнера виртуалка добавляет отдельный слой виртуального железа и это вносит свои издержки. Так как у нас эмулируется Common KVM processor, то сразу видим провал по частоте до номинальной и первые два процессорных теста примерно соответствуют разнице в частоте. А вот третий полностью зависит от поддержки аппаратных инструкций процессора и здесь разница довольно серьезная. Но зато Common KVM processor является универсальным и переносимым. Дисковая система по умолчанию без кеширования и результат тоже хуже, чем на хосте. Но и виртуальные машины применяются там. где нужна более серьезная изоляция на уровне железа, либо его специальная эмуляция, так как не все сценарии поддерживаются в контейнерах. Если же нужна производительность, то смело берем LXC.

🎥 Вебинар по Linux: "Инфраструктура как код: практическое знакомство с Vagrant и Ansible" ☝️На вебинаре вы узнаете: - как ра
🎥 Вебинар по Linux: "Инфраструктура как код: практическое знакомство с Vagrant и Ansible" ☝️На вебинаре вы узнаете: - как работает Vagrant и зачем он нужен системному администратору; - как использовать Ansible для автоматизации настройки виртуальных машин; - какие шаги нужны для развертывания тестового стенда в Linux; - типичные сценарии применения Vagrant + Ansible в работе администратора. 💪 В результате вебинара вы: - научитесь создавать тестовый стенд с помощью Vagrant; - сможете применять Ansible для конфигурации виртуальных машин; - попробуете связку Vagrant + Ansible для автоматизации задач; - получите базовое понимание принципов «инфраструктуры как код». 🎁 Все участники вебинара получат специальные условия на полное обучение курса "Administrator Linux. Professional" 👉 Для участия зарегистрируйтесь: https://tglink.io/4279ea2ad978?erid=2W5zFK4MpSk Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

​​До свиданья наш ласковый миша Мир IT постоянно находится в движении, меняются технологии, подходы, условия. И вчерашние технологии оказываются не соответствующими текущим вызовам. Поэтому нужно находить в себе силы пересматривать старые привычки и менять используемый стек решений. Сегодня мы поговорим об mdadm, старом-добром mdadm, который мы все любим, знаем и используем. Но увы, время mdadm прошло и сегодня он уже не выполняет возлагаемых на него функций и не оправдывает ожиданий. В чем проблема? А проблема в таком явлении, как bitrot, битовое гниение (https://t.me/interface31/2600) – деградация данных, не связанная с физическим выходом из строя накопителя и часто даже не препятствующая чтению данных, так как встроенные во многие форматы методы коррекции позволяют такие ошибки исправлять. Но на системах холодного хранения данных такие ошибки могут накапливаться и незаметно повреждать данные вплоть до невосстановимого уровня. Об этом давно предупреждали разработчики Proxmox и поэтому в доступных вариантах организации хранилища mdadm нет, что вызывало и вызывает недоумения у многих пользователей. Но они правы и буквально вчера мы столкнулись с неприятной ситуацией с битовым гниением на mdadm. Медицинская организация, некие наборы данных хранятся в файловом хранилище в виде архивов подписанных ЭП, срок хранения требуется большой, десятки лет. Это требования регламента и единственной альтернативой ему может служить бумажный архив, который, при выполнении всех требований по защите персональных данных становится вовсе неподъемным. Вчера, при обращении к одному из таких архивов выяснилось, что архив читается, распаковывается, но проверку подписи не проходит. Т.е. фактически мы утратили часть архива, так как данные документы перестали считаться подлинными. Учитывая важность архива конечно-же делались его копии, в т.ч. и во внешнее хранилище. Извлеченная из бекапа копия проверку подписи прошла. Следовательно? Следовательно мы имеем дело с классическим bitrot, которое тихо и незаметно портит данные, и никто об этом ни сном, ни духом. Мы запустили проверку архива и результат был неутешительный, повреждены оказались еще около десятка файлов, один из них имел ошибки распаковки, но все-таки распаковался. Да, десяток файлов из тысяч – это мало, но в данном случае вполне достаточно для создания серьезных проблем. А причем тут mdadm? А при том, что все это хранилище как раз было организовано средствами mdadm: LVM поверх двух зеркал по 4 ТБ. Да, mdadm защищает нас от физического выхода диска из строя, но от битового гниения спасти не может. Кто может? Современные файловые системы с контролем целостности данных: ZFS или btrfs, но для этого избыточность также должна создаваться средствами этих ФС, в этом случае они смогут эффективно выявлять повреждения и восстанавливать их за счет избыточных данных. Если же вы просто натянете btrfs поверх mdadm – то ничего работать не будет, избыточность брать неоткуда. Поэтому, как бы прост, понятен и удобен не был mdadm – его время вышло, говорим старичку спасибо и отправляем на заслуженную пенсию.

Встречайте AIOps в INFRAX — виртуального инженера, который работает прямо внутри карточки инцидента: - анализирует логи, - пр
Встречайте AIOps в INFRAX — виртуального инженера, который работает прямо внутри карточки инцидента: - анализирует логи, - предлагает команды, - помогает устранять неполадки быстрее и надёжнее. 🔐 Все действия прозрачны и безопасны: журналируются в инциденте и выполняются строго в рамках ваших политик доступа. Что такое INFRAX? Это: 🖥 Мультиметричный мониторинг — CPU, память, диски, трафик, доступность узлов, интерактивные графики и гибкие алерты. 🎫 Helpdesk — управление тикетами, статусы, приоритеты, исполнители и комментарии, портал самообслуживания для пользователей. 🤖 Автоматизация — агенты для Windows/Linux, запуск скриптов по расписанию, планировщик задач, автодетект узлов. 🔐 Удалённые подключения — RDP, SSH, VNC прямо из веба или нативных клиентов, видеозапись сессий для аудита. 📚 База знаний — статьи, категории, контроль публикаций, статистика по популярности. 👥 Управление пользователями — детальная система прав, интеграция с IAM, аудит действий, изоляция данных. 📊 Дашборды — мониторинг, техподдержка, удалённые подключения с realtime-обновлением. 🔥 Infrax — это ситуационный центр вашей ИТ-инфраструктуры. Всё, что нужно для стабильной и безопасной работы сервисов, в одном решении. #реклама О рекламодателе

Встречайте AIOps в INFRAX — виртуального инженера, который работает прямо внутри карточки инцидента: - анализирует логи, - предлагает команды, - помогает устранять неполадки быстрее и надёжнее. 🔐 Все действия прозрачны и безопасны: журналируются в инциденте и выполняются строго в рамках ваших политик доступа. Что такое INFRAX? Это: 🖥 Мультиметричный мониторинг — CPU, память, диски, трафик, доступность узлов, интерактивные графики и гибкие алерты. 🎫 Helpdesk — управление тикетами, статусы, приоритеты, исполнители и комментарии, портал самообслуживания для пользователей. 🤖 Автоматизация — агенты для Windows/Linux, запуск скриптов по расписанию, планировщик задач, автодетект узлов. 🔐 Удалённые подключения — RDP, SSH, VNC прямо из веба или нативных клиентов, видеозапись сессий для аудита. 📚 База знаний — статьи, категории, контроль публикаций, статистика по популярности. 👥 Управление пользователями — детальная система прав, интеграция с IAM, аудит действий, изоляция данных. 📊 Дашборды — мониторинг, техподдержка, удалённые подключения с realtime-обновлением. 🔥 Infrax — это ситуационный центр вашей ИТ-инфраструктуры. Всё, что нужно для стабильной и безопасной работы сервисов, в одном решении. #реклама О рекламодателе

Zabbix – а куда делся мой ресурс SSD? Жил был Zabbix и его судьба, как это обычно случается, была трудна. Вначале, он как Сир
Zabbix – а куда делся мой ресурс SSD? Жил был Zabbix и его судьба, как это обычно случается, была трудна. Вначале, он как Сирота Казанская жил, где придется, потом, кое-как обрел свой угол, где и обретался худо-бедно… Потом администраторам приблудился компьютер, не самый плохой, что-то типа Ryzen 5, и они подумали – если он никому не нужен, то сделаем на нем свой сервер и соберем на него всякие админские штуки, тот же Zabbix, чего он там по закоулкам тусуется. Сказано – сделано. Докупили память, новые NVMe диски, поставили Proxmox и запустили это все в эксплуатацию. А третьего дня сильно удивились – а куда делся ресурс SSD? За четыре с небольшим месяца (131 день) кто-то скушал 79% ресурса SSD. Диски, так как серьезной нагрузки не предполагалось, брали недорогие, Kingston NV2 500 ГБ с TBW 160 ТБ. Несложный подсчет показал, что ежесуточный объем записи на диски составил 745 ГБ и основной виновник в этом – процесс MySQL обслуживающий Zabbix. Если продолжать такими темпами, то дисков хватит еще на два месяца. 👆 Мораль? Изучайте потребности собственных приложений в ресурсах перед покупкой комплектующих, а не после. И да, диск – это расходный материал.

REKONFA Live 6 ноября приглашаем всех, кто имеет отношение к маркетингу и рекламным технологиям, обсудить рынок, тренды, вызо
REKONFA Live 6 ноября приглашаем всех, кто имеет отношение к маркетингу и рекламным технологиям, обсудить рынок, тренды, вызовы и их решения. С докладами на актуальные темы выступят лидеры индустрии и медийные спикеры. Принять участие можно офлайн и онлайн. Мероприятие бесплатное, нужно только зарегистрироваться. Зарегистрироваться #реклама 18+ ya.rekonfa.ru О рекламодателе

​​Монолит против виртуализации Сегодня завершили трехдневную эпопею с переносом инфраструктуры одного заказчика на новый сервер в виртуальную среду. Процесс прошел сравнительно мягко, как для нас, так и для заказчика как раз благодаря тому, что виртуализация позволяет «есть слона по частям». Долго рассказывать, но простой сервер небольшой организации для 1С и общей папки за прошедшие восемь лет превратился в сущего монстра. Уже несколько раз менялось железо, добавлялись и убирались роли, в общем много чего делалось, но система оставалась монолитом. А это вызывало проблемы и сложности. Всегда приходилось учитывать влияние одних служб на другие, искать компромиссы по выделению ресурсов, крайне осторожно подходить к обслуживанию и обновлению. И вот очередной час пришел, старое железо начало однозначно намекать, что намерено в скором времени отправиться в края вечной охоты. Поэтому купили новое железо и запланировали переезд, только уже с применением виртуализации. Кто-то скажет, а какая разница, сервер все равно один, только добавляется лишняя прослойка в лице виртуализации. Но нет, виртуализация позволяет надежно изолировать службы друг от друга. Обеспечить гарантированное выделение ресурсов. Убрать взаимное влияние служб. Обеспечить индивидуальную настройку любых параметров. И в случае переезда виртуальные машины и контейнеры предоставляют гораздо большую гибкость. Просто перемещаем виртуалку на другой хост виртуализации и все, никаких дополнительных перенастроек. Аналогично и с резервным копированием и временем восстановления. Скопировать на новый хост виртуалки и запустить их всегда быстрее, чем заново настроить монолит, даже при наличии всех данных. Теперь о том, как это лучше делать. Все упирается в план. Прежде всего вы должны разделить существующие сервисы по отдельным контейнерам или виртуальным машинам. Оптимально: один сервис – одна виртуальная машина (контейнер). Далее – считаем ресурсы, как дисковые, так и по оперативной памяти. И то и другое можно выделять с превышением суммарной наличной емкости, но понимать, что этот момент придется постоянно контролировать. По памяти проще, виртуальная машина может пиково забрать память и через некоторое время вернуть ее. Виртуальные диски растут только в одну сторону, даже если потом внутри мы удалили данные, внешний размер диска не уменьшится. Но, зная, что у нас есть запас по пространству мы можем нарезать диски с перехлестом. Зачем? Скажем пошел неконтролируемый рост логов, пусть лучше он займет лишнее место, чем приведет к остановке сервиса. А там сигнал от мониторинга, выявление проблемы, ручные процедуры по приведению в норму дискового пространства. Контейнер или виртуальная машина? Начнем с того, что контейнеры – это не про виртуализацию, это про изоляцию. Каждый контейнер предоставляет изолированную программную среду с прямым доступом к оборудованию и ядру. Да, при необходимости вы можете использовать нужное вам программное окружение. Но контейнер с Debian 8 на Proxmox 8 не означает, что вы там используете Debian 8, а то, что вы используете ядро от Debian 12 в окружении библиотек из Debian 8. Виртуалка – это совсем иное дело, это отдельный хост, со своим набором виртуального железа, виртуальной ОС и для заключенных внутри нее служб она ничем не отличается от обычного ПК. Что выбрать? Смотрите сами. Контейнер дает минимальную потерю по производительности, фактически вы работаете на железе хоста. Также контейнеры используют память хоста и то, то вы им выделили – это лимиты. Но они имеют свои особенности эксплуатации и это надо читать документацию к гипервизору. Виртуалки более требовательны, так как у них запущено собственное ядро и собственное окружение, что потребляет лишнюю память и дает лишние потери производительности на слое виртуализации. Но они могут быть полностью отвязаны от железа хоста. Что выбрать – смотреть по ситуации. Но в любом случае такая структура будет более гибкой и управляемой, нежели монолит.

СОБЫТИЕ. Финал продаж в лучшей новостройке России Успейте стать жителем дома-лауреата федеральной премии "ТОП ЖК - 2025" в номинации "Лучшая новостройка Москвы и России". - Первый в столице дом с "парящими" мостами и парком на крыше - Вертикальная инфраструктура: детские и спортивные площадки, коворкинги и лаунжи между небом и землей - Парк "Событие" у дома: 24 га благоустроенных пространств для отдыха Сейчас вы можете купить квартиру в доме СОБЫТИЕ с рассрочкой 0% от застройщика на 2 года. Узнать больше Проектная декларация на сайте https://наш.дом.рф/. Застройщик: ООО СЗ РАЗВИТИЕ. Финансовые услуги оказывает: Банк ВТБ (ПАО). #реклама dom-sobytie.ru О рекламодателе

Административная виртуалка В свете перевода всей инфраструктуры 1С на Linux и в контейнеры встает закономерный вопрос – как о
Административная виртуалка В свете перевода всей инфраструктуры 1С на Linux и в контейнеры встает закономерный вопрос – как обслуживать все это хозяйство. «Что значит как?» —спросит иной читатель, со своего рабочего места. Но тут не все так просто. Да, повседневные задачи вы можете выполнять откуда угодно, в т.ч. и удаленно. Инструментов для этого хватает. Но некоторые процедуры, такие как обновление информационной базы и вообще практически любые работы в конфигураторе требуют перемещения по сети значительных объемов данных и практически невозможны на удаленке. Хорошо, если у вас есть выделенное рабочее место в локальной сети, а если вы нештатный админ или аутсорсер? Также рабочее место может оказаться выключено во внерабочее время, зависнуть, в общем много чего может случиться. Поэтому мы уже давно практикуем административные виртуалки. Это обычная виртуалка с самой обычной Windows 10/11 на том же самом гипервизоре (или на любом доступном, если их несколько). Такая машина всегда доступна, и вы можете настроить ее как специализированное рабочее место – т.е. только то, что нужно под задачи и ничего лишнего. 👉 Накладные расходы – место на диске и потребляемая память. В этом случае уместно использовать Memory ballooning для динамического выделения памяти или просто включать такую виртуалку по необходимости если свободной памяти не очень много. 👆 А плюсов такого решения более чем достаточно. Про высокую доступность такого рабочего места мы уже говорили. Но оно еще и повторяемо – вы можете взять уже настроенную виртуалку и сделать из нее шаблон. После чего быстро разворачивать ее по необходимости. Зависла – перезагрузим из веб-интерфейса гипервизора, выключена – включим. Сломалась – починим, хотя быстрее развернуть новую из готового шаблона. Нужно выполнить какие-то ресурсоемкие работы? Добавили вычислительных ресурсов. И все это в быстрой внутренней сети гипервизора. ❓ А вы используете подобные инструменты?

Технологии - просто и понятно 👾 это Пролог - в канале есть: • про космос и бизнес • технологии искусственного интеллекта • пост о методе Фейнмана 🤔 и многое другое... Только самое интересное в @get_prologue ! подписывайтесь ✔️

Накладные расходы на контейнер Вчера в обсуждениях поднимали этот вопрос, а сегодня мы как раз поднимали новый контейнер с Po
Накладные расходы на контейнер Вчера в обсуждениях поднимали этот вопрос, а сегодня мы как раз поднимали новый контейнер с Postgres. Накладные расходы чистого контейнера (без баз) вы можете видеть на скриншотах. 🔹 Итого по памяти ~ 50 МБ, обратите внимание, что сам контейнер показывает большее значение. Но никакого противоречия тут нет, так как контейнер считает внутри и собственное потребление и совместно используемые с хостом ресурсы, в частности ядро. 🔹 Итого по диску ~ 500 МБ, цифра на фоне типовых размер баз 1С достаточно скромная. Даже при использовании SSD небольшого размера. Примерно такая же картина наблюдается и в контейнере с Apache. 👆 Таким образом накладные расходы на дополнительные контейнеры можно считать несущественными.

Вы уже работаете в IT и задумали перейти в SRE? Скорее всего вы думаете: ❓ С чего начать? ❓ Каких компетенций мне не хватает?
Вы уже работаете в IT и задумали перейти в SRE? Скорее всего вы думаете: ❓ С чего начать? ❓ Каких компетенций мне не хватает? ❓ Как составить четкий план развития? ❓ Как понять, чего от меня ждут работодатели? Ищите ответы 11 октября онлайн на SRE Day! После него вы уйдёте с четким пониманием своих сильных сторон и точек роста, пошаговым планом развития, алгоритмом действий при аварии и реальными связями в комьюнити. У вас будет уникальная возможность задать вопрос экспертам и получить моментальный фидбек. 📌 Первым десяти участникам — скидка почти 40%. Если вы готовы сделать карьерный рывок, скорее оставляйте заявку и будьте в числе первых! Подробнее — на сайте 🔥