Типичный Сисадмин

Коллега поделился по-настоящему странной проблемой, с которой столкнулся после обновления нескольких виртуальных машин Ubuntu Server. Эта история – отличный пример того, какими непредсказуемыми могут быть трудовые будни, и как важно иногда просто сравнить конфиги. Началось все с рутинной задачи: обновления старых Ubuntu серверов. Два из них, работавшие на версии 18.04, потребовали двух последовательных циклов do-release-upgrade. Однако после второго апгрейда, до версии 22.04, обе эти виртуальные машины наотрез отказались нормально загружаться, просто зависая на старте. Логи намекали на проблемы с монтированием корневого раздела /dev/vda1. Самое мистическое в этой ситуации было то, что если загрузиться в консоль восстановления, а затем выбрать опцию "продолжить обычную загрузку", система волшебным образом стартовала и работала как ни в чем не бывало. Две из двадцати виртуальных машин демонстрировали идентичное поведение, что добавляло загадочности. Админ перепробовал многое: проверил конфигурации, вручную обновил тип виртуальной машины, пересобрал initramfs, обновил GRUB – но ничего не помогало, кроме этого странного обходного пути через rescue-консоль. Подозрение падало на конфигурацию самой ВМ, так как даже live-образ Ubuntu 22.04 на этих машинах загружался с трудом. В ходе поисков решения были отброшены различные гипотезы: нехватка места на /boot, проблемы с fstab или udev (хотя и пробовались разные варианты монтирования), ошибки файловой системы. Kernel panic при обычной загрузке указывал на невозможность найти корневой раздел, который, тем не менее, прекрасно находился при старте через rescue-режим. Разгадка пришла, когда автор сделал то, что, по его собственному признанию, "нужно было сделать еще прошлой ночью": он сравнил (diff) XML-файл конфигурации проблемной виртуальной машины (/etc/libvirt/qemu/server.xml) с аналогичным файлом работающей ВМ. И вот оно! В секции <video> у проблемных машин был указан тип модели vmvga. Простое изменение `vmvga` на `qxl` немедленно решило проблему! Виртуальные машины стали загружаться штатно. Как именно конфигурация виртуальной видеокарты могла повлиять на доступ к диску при загрузке – остается небольшой загадкой, но это яркий пример того, что при крупных обновлениях операционных систем могут меняться поддержка или поведение различных моделей виртуального оборудования. Старые конфигурации виртуальных машин не всегда переносятся без сюрпризов. Linux / Линукс 🥸

Креативный админ 🎹 Типичный 🥸 Сисадмин

🔵Освойте одну из самых востребованных профессий в российском IT в 2025 В OTUS стартует новый поток онлайн-курса «Архитектор 1С», где вы научитесь проектировать информационные системы, используя продвинутые возможности платформы 1С. 4 месяца обучения и вы сможете: ▫️ Формировать архитектуру окружения 1С, ▫️ Моделировать бизнес-процессы и создавать прототипы разработки ▫️ Проектировать технические проекты в СППР ▫️ Работать с Git, OneScript, Vanessa, SonarCube, Apdex, Grafana ▫️ Устанавливать и настраивать РИБ А еще узнаете, как организовать работу отдела разработки 1С, какие есть виды документации в 1С и какие организационные мероприятия существуют в 1С. 👉 Пройдите короткий тест прямо сейчас: https://vk.cc/cN5YLa Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Домовой серверной — причина, по которой иногда само чинится. Главное - вовремя покормить 🍔 Типичный 🏥 Сисадмин

🔍 Windows 11 сокращает срок хранения точек восстановления до 60 дней Начиная с июня 2025 (обновление 24H2), автоматические точки восстановления Windows 11 будут удаляться через 60 дней вместо прежних 90. Изменение затронет все будущие версии, включая 25H2. — Автоточки (создаваемые системой перед обновлениями) теперь «живут» всего 2 месяца; — Ручные точки (созданные пользователем) не ограничены и хранятся, пока есть место на диске; — Если сбой проявится позже 60 дней после обновления — откатиться через автоточку будет нельзя. Официально Microsoft это сделала для оптимизации дискового пространства. Неофициально (по мнению PCWorld) — подталкивает пользователей к облачным бэкапам OneDrive. Типичный 🥸 Сисадмин

Что делать, если MySQL/MariaDB переросла один сервер? Стратегии масштабирования 🎹 Вопрос, который рано или поздно встает перед многими: что предпринять, когда база данных MySQL или MariaDB становится слишком большой и нагруженной для одного хоста, а простое увеличение CPU/RAM уже не помогает? По следам недавнего обсуждения, инициированного коллегой, собрал пул эффективных стратегий и практических советов. Первым и часто самым логичным шагом является внедрение репликации и разделение нагрузки, особенно на чтение. Если ваше приложение генерирует значительно больше запросов на чтение, чем на запись (например, в соотношении 90/10), добавление реплик (read replicas) и направление на них части трафика через приложение или с помощью ProxySQL может дать существенный выигрыш. ProxySQL, к слову, полезен на любом этапе, так как способен кешировать запросы и управлять пулами соединений, снижая нагрузку даже на одиночный мастер-сервер. Когда нагрузка на запись становится значительной (приближаясь к соотношению 50/50 или даже преобладая), стоит рассмотреть решения для multi-master кластеризации, такие как Galera Cluster. Эта технология, встроенная в MariaDB и используемая в Percona XtraDB Cluster (PXC), обеспечивает синхронную репликацию и повышает доступность. Однако важно помнить, что хотя Galera помогает с масштабированием записи, все узлы в кластере по-прежнему должны обрабатывать все транзакции, что может стать ограничением. Для действительно огромных нагрузок, особенно смешанных или с преобладанием записи, следующим шагом может стать шардинг. Технологии вроде Vitess предоставляют инструменты для горизонтального масштабирования путем разделения данных на множество независимых баз (шардов). Альтернативно, шардинг можно реализовать на уровне приложения, но это требует серьезных изменений в коде и усложняет многие операции, например, поиск по всем данным.

Масштабировать MySQL, не оптимизировав запросы, – это как пытаться выиграть гонку на машине с квадратными колесами, просто доливая в нее больше бензина 🚘

Не стоит забывать и об оптимизации и кешировании на уровне приложения. Часто лучший запрос – это тот, который не пришлось делать. Прежде чем бросаться в масштабирование инфраструктуры, необходимо убедиться, что все запросы к базе данных максимально эффективны, используются правильные индексы, а частые данные кешируются, например, с помощью Redis. Иногда корень проблемы кроется в неэффективной логике самого приложения, требующей пересмотра. В некоторых случаях рассматривается переход на другие СУБД. PostgreSQL часто упоминается за его зрелые возможности кластеризации и хорошую масштабируемость на одном узле. Для специфических MySQL-совместимых распределенных решений есть TiDB, а для аналитических нагрузок, убивающих традиционные реляционные базы, — ClickHouse. Однако смена СУБД – это всегда большой проект, и важно понимать, что ни одна из них не является "волшебной палочкой". Прежде чем приступать к масштабным изменениям, критически важно понять характер вашей нагрузки: соотношение операций чтения и записи, самые тяжелые запросы, наличие кешируемого контента. Часто проблема, формулируемая как "как масштабировать MySQL", на самом деле является проблемой XY, скрывающей необходимость оптимизации приложения или самих запросов к базе. Опыт показывает, что некоторые решения, например, master-master репликация на бинарных логах или InnoDB Clusters, могут быть нестабильны в продакшене, в то время как Galera Cluster считается более надежным для multi-master конфигураций. Идеального решения не существует, есть только наиболее подходящее для ваших текущих задач 🎩 Типичный 🥸 Сисадмин

Больше ничего не надо. Правда 😬 Типичный 🥸 Сисадмин

Nvidia Инвестирует в Ядерную Энергию для AI Nvidia (через фонд NVentures) вложилась в TerraPower – ядерный стартап Билла Гейтса, разрабатывающий малые модульные реакторы (SMR). Цель – обеспечить энергией растущие аппетиты AI-датацентров. В раунде на $650 млн также участвовал HD Hyundai. Пилотная АЭС Natrium (345 МВт + 1 ГВт хранилище) в Вайоминге ожидается к 2030 году, но регуляторное одобрение еще не получено. Другие техгиганты (AWS, Google, Microsoft, Oracle) также активно смотрят в сторону SMR. Для Nvidia это логичный шаг: больше энергии – больше проданных GPU. Однако SMR – технология дорогая, медленная и рискованная (NuScale уже свернули проект). Скептики сомневаются в их экономической целесообразности. Главное, чтобы SMR не начали "троттлить" из-за перегрева 💥 🥸 godnoTECH - Новости IT

Типичный 🎹 Сисадмин

AI "Пнул Спящий Рынок Коммутаторов: +32% Роста и Взлет 800 GbE Рынок сетевых коммутаторов для дата-центров, долгое время пребывавший в стагнации, получил мощный импульс благодаря буму AI. Аналитики IDC зафиксировали в Q1 2025 выручку в $11.7 млрд, что на 32.3% больше год к году. Главный драйвер – развертывание высокоскоростной инфраструктуры с низкой задержкой для поддержки AI-нагрузок. Доходы от коммутаторов для ЦОД выросли на 54.7% в Q1, ускорившись по сравнению с +32.1% в Q4 2024. Сегмент 200/400 GbE показал рост на 189.7% год к году. IDC также начала отслеживать 800 GbE коммутаторы, которые уже принесли $350.8 млн, быстро заняв 5% рынка. Главный бенефициар – Nvidia. Её выручка от коммутаторов взлетела на 760.3% год к году, достигнув $1.46 млрд, и на 183.7% по сравнению с Q4 2024. У Arista рост доходов от коммутаторов для ЦОД составил +27.1% ($1.6 млрд). А вот у Cisco доходы от этого сегмента умудрились упасть на 3.2%, что намекает на успешное откусывание доли конкурентами в этом раскаленном сегменте (хотя общая выручка Cisco от коммутаторов выросла на 4.7%). Рынок коммутаторов для кампусных и филиальных сетей (не ЦОД) тоже подрос, но скромнее – на +9.6%. Выручка от WLAN также показала рост на +10.6% в Q1, что говорит о стабилизации рынка после проблем с поставками из-за COVID-19. И здесь AI также играет роль, стимулируя спрос на новое поколение Wi-Fi (6 GHz) и AI-управляемые решения. --- Кажется, AI скоро потребует для своей работы персональный интернет-магистраль прямо в стойку. И чтобы без шейпинга! Типичный 🥸 Сисадмин

Встречаются как-то создатель Linux, два отца Windows NT и отец Sysinternals...

На фото причины, которые до сих пор не могут договориться об одном формате конфигов для всего. Поэтому мы и не сидим без работы. З.Ы. Руссиновича это не касается, он просто чинит то, что эти трое напридумывали. Типичный 🥸 Сисадмин

Типичный 🧘 Сисадмин

Когда KVM не прокинут, а консоль нужна срочно 🎹 Типичный 🥸 Сисадмин

🙃 Минобрнауки.рф ведёт в онлайн-казино Официальный домен минобрнауки.рф, ранее принадлежавший Министерству просвещения РФ, теперь перенаправляет пользователей на сайт онлайн-казино. Всё из-за того, что министерство вовремя не продлило регистрацию. Домен был зарезервирован для госнужд ещё в 2010 году, но после 2 марта 2023 года стал «ничейным». Уже 4 апреля его выкупило частное лицо и настроило редирект на азартный ресурс. Онлайн-казино, к слову, запрещены в России, и такие сайты подлежат блокировке. Координационный центр доменов .RU/.РФ объяснил, что с 2019 года ответственность за продление доменов полностью лежит на самих госорганах. Чтобы избежать таких историй, планируют ввести отдельного регистратора для органов власти. Законопроект уже готовят. 🥸 godnoTECH - Новости IT

После того как понял, насколько ценны современные веб-интерфейсы без всякой олдовой жути ☕️ Типичный 🥸 Сисадмин

Кто такой Gordon 🤔 Наш новый Team Lead по контейнерам? Типичный 🥸 Сисадмин

⚡Открытая трансляция главного зала Saint HighLoad++ 2025!🖐️ Подключайтесь и слушайте доклады от спикеров Garage Eight, Яндекса, Сбера, Ozon и других компаний. Saint HighLoad++ 2025 — это конференция, которая определяет будущее высоконагруженных систем. 23 и 24 июня все желающие могут бесплатно посмотреть онлайн-трансляцию главного зала. Открытую трансляцию организовали совместно с генеральным партнером конференции — Garage Eight. Garage Eight — международная продуктовая IT-компания. С 2011 года развивает экосистему высоконагруженных инвестиционных продуктов, у которых сотни тысяч пользователей в 183 странах. Продукты отмечены наградами от Global Banking and Finance Review, Global Business Magazine и World Business Stars. Как всегда, в главном зале — топовые эксперты и самые актуальные темы. ✅ Подключайтесь! 

Microsoft чистит Центр обновления Windows: устаревшие драйверы под удаление Компания объявила о стратегии по повышению безопасности и совместимости Windows: 1. Удаление устаревших драйверов — Драйверы с современными аналогами исключаются из ЦО Windows — WMIS (Windows Metadata and Internet Services) больше не поддерживается — Изменён процесс предварительного подписания драйверов 2. Процедура для партнёров — Удалённые драйверы можно *переопубликовать*, но требуется обоснование — После чистки — 6-месячный льготный период для подачи жалоб — Регулярные чистки станут нормой (следующий этап — более широкий охват) 3. Цели — Снижение рисков безопасности — Оптимизация набора драйверов в ЦО — Партнёрам рекомендовано проверить драйверы через Программу оборудования Типичный 🥸 Сисадмин

Когда железо получило больше травм, чем ты за всю карьеру, но всё равно работает 🔥 Всратый монтаж 🥸