惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

P
Palo Alto Networks Blog
S
Security Affairs
T
Tor Project blog
T
Threatpost
Hacker News - Newest:
Hacker News - Newest: "LLM"
C
Cyber Attacks, Cyber Crime and Cyber Security
The Hacker News
The Hacker News
A
Arctic Wolf
K
Kaspersky official blog
O
OpenAI News
Spread Privacy
Spread Privacy
人人都是产品经理
人人都是产品经理
爱范儿
爱范儿
Simon Willison's Weblog
Simon Willison's Weblog
雷峰网
雷峰网
P
Privacy & Cybersecurity Law Blog
Know Your Adversary
Know Your Adversary
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Last Week in AI
Last Week in AI
Martin Fowler
Martin Fowler
量子位
博客园_首页
Cyberwarzone
Cyberwarzone
博客园 - 三生石上(FineUI控件)
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
IT之家
IT之家
N
News and Events Feed by Topic
博客园 - 司徒正美
V2EX - 技术
V2EX - 技术
S
Schneier on Security
博客园 - 叶小钗
Attack and Defense Labs
Attack and Defense Labs
AI
AI
Application and Cybersecurity Blog
Application and Cybersecurity Blog
博客园 - 【当耐特】
Jina AI
Jina AI
C
CXSECURITY Database RSS Feed - CXSecurity.com
C
Cybersecurity and Infrastructure Security Agency CISA
D
Darknet – Hacking Tools, Hacker News & Cyber Security
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
大猫的无限游戏
大猫的无限游戏
Cloudbric
Cloudbric
H
Hacker News: Front Page
The Last Watchdog
The Last Watchdog
V
V2EX
S
SegmentFault 最新的问题
V
Visual Studio Blog
PCI Perspectives
PCI Perspectives
Microsoft Security Blog
Microsoft Security Blog

Все публикации подряд на Хабре

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет Midjourney в 2026? Мой немного грустный разбор этого шикарного инструмента Никто не любит писать тесты, но ИИ может исправить это IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит Производители вернули в продажу материнки с DDR3. Что происходит? Управление агентом с телефона через Telegram теперь в KodaCode От координации к лидерству: как меняется роль руководителя разработки Я сделала родителям бизнес вместо пенсии: зарабатываем 70 тысяч, мама не даёт продать В три раза быстрее приемка товара и оптимизация трудозатрат на 73%: как «РСТ-Инвент» помог Gulliver Group ИИ-шечный мир победил? О влиянии искусственного интеллекта на игропром Кремль снижает давление на Телеграмм пока Европа строит интернет по паспорту Как CEO, CTO и CIO за 8 часов собрали ИИ-директора, который умеет держать позицию под давлением Как (не) потерять домен за выходные Вместо 8 разных VPS: как я организовал практику студентам на одном сервере Почему твой Open Source проект не замечают? R&D: искусство управления неопределенностью в разработке AI-дефляция: вакансий для разработчиков больше, а рост зарплат — худший за 15 лет Мы отдали управление роботами OpenClaw. Что из этого вышло Галактический ID: система идентификации для всех форм разумной жизни Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» Код-ревью, в котором дело не в коде Данные переехали. Команда — нет Системной подход к сдаче OSWE в 2025 Почему комната управления реактором покрашена в цвет морской пены 4 YAML-файла вместо PySpark: как аналитикам строить пайплайны без разработчиков LLM-агент для поиска свободных доменов: автоматизируем подбор Когда, зачем и как правильно начинать новую сессию в Claude Code? Как я заставил нейросеть писать макросы для FreeCAD Анатомия ИИ‑агента для подбора персонала. От тысячи резюме к топ‑10 за минуты Опыт разработчика как экономика внимания Автономность как точка невозврата: кто будет субъектом в цифровом будущем Обучение ИИ в «диких» условиях: как рутинные действия превращаются в датасеты Как измерить LLM для задач кибербеза: обзор открытых бенчмарков Где хранить код? Сравнение GitHub, GitLab и Bitbucket Математика объясняет, почему нормальное распределение встречается повсюду Почему ваш FinOps не работает: 12 тезисов от практиков Как подписать проектную документацию УКЭП с использованием бесплатных лицензий Pilot Адаптивное администрирование Sigla Vision Я грузил уран в бочки, а потом 20 лет строил ИТ в атомной отрасли Чем позвонить с Эвереста? История и обзор спутниковой связи. Часть 2 Как языковая модель помогает контролировать качество инструктажей по охране труда в металлургии Как не передать на desktop свой IP в РКН Анатомия SAP Privileges: как устроено управление правами в macOS MoneyDev: Сказка про три главных слова Обновлённый токенизатор видео K-VAE 2.0 от Сбера Как сделать диспетчеризацию дома на 1284 квартиры почти бесплатно Как мы разогнали железную дорогу Мы дали агентам рутину. Теперь надо решить — что делать с освободившимся временем Токсичный контент, промпт-хакинг и защита ИИ — всё о Guardrails для LLM Умный город начинается с точного взгляда: как «Фалькон Тех» меняет пространство к лучшему Навайбкодил приложение для анализа графов Почему Дюну так интересно читать? Упрощаем работу с рутиной или как стать Гендальфом Белым Деконструкция Go: CPU, RAM и что там происходит. Go Assembler база. Часть 1.1 Какие профессии исчезнут из-за ИИ, а какие появятся? И что с этим делать Как мы построили IT-отдел, где хочется расти: архитектурные встречи, прозрачные метрики и книжные подарки Rufler: Делаем из Claude Code автономный рой через один YAML-конфиг Sing-box и белый список приложений Как построить надёжный обмен сообщениями в микросервисах: лучшие практики для enterprise OpenAI строит MLM-пирамиду, а McKinsey и Accenture помогают ей в этом Дом, который не построил Фишер (Часть 2) «Сверхзвуковой математик» против «Вдумчивого логиста»: битва алгоритмов 3D-упаковки Мультимодальные модели – грубый и дорогой инструмент Разговоры ничего не стоят. Код тоже Проверки физических лиц: с кого начнет ФНС Топ-10 бесплатных нейросетей для создания видео в 2026 году Первые слои кода: как наши решения сегодня определяют архитектуру ИИ на десятилетия Разработка нового статического анализатора: PVS-Studio JavaScript Поиск уязвимостей ПО: базовый минимум или роскошный максимум Почему оценка персонала не работает как инструмент управления Как мы разработали ИИ-ассистента и сократили рутину продуктовой команды на 50% Как я ушел из найма, нажарил косточек и продал на маркетплейсах на 168 млн в год Когда 1С:ERP уже внедрена, а нормального производственного плана всё ещё нет Как я сделал Claude мультимодальным, подключив к нему Qwen Omni Как приглашение на вакансию мечты превращается в атаку Infrastructure as Code: философия и лучшие практики IaC Тестируем Yandex Code Assistant на задаче, в которой нужно хранить секреты nxs-universal-chart v3.0: новое поколение универсального Helm-чарта Callback Injection: Техника, которая отправила Microsoft Defender в глухой нокаут «Все идеи на стол»: митап как способ вывести проект из тупика Сегодня я узнал нечто новое о GPU благодаря багу в своей игре Как заставить LLM ̶ ̶г̶а̶л̶л̶ю̶ ̶ эволюционировать Карта событий как фундамент аналитики: практический кейс для E-commerce Что выбрать для AI: x86, ARM или RISC-V? Дайджест железа за март Роль соматических мутаций в развитии аутоиммунных заболеваний: путь к избирательной терапии Mythos от Anthropic — тревожный сигнал для всех, а не только для банков Guardrails для LLM на Java: как приручить промпт‑инъекции и токсичные ответы Green-VLA: как мы собрали VLA-модель для реального антропоморфного робота и не потеряли обобщение Финансовая гонка вооружений: почему умные люди добровольно в ней участвуют Эра ИИ-агентов наступила: выбираем лучшего цифрового сотрудника # Практический опыт внедрения WinCC Redundancy на производственном предприятии Сделал MVP за 3 дня, а потом неделю прикручивал оплату. Оно того стоило? Физика против Маска: почему Starship V3 может оказаться ещё одной катастрофой Нефть Венесуэлы: крупнейшие запасы в мире, но не крупнейшая нефтяная держава JPA 4. Переосмысление Hibernate Почему зеркальная фотокамера Nikon D5 десятилетней давности идеально подошла для миссии «Артемида-2» Проект «Уровень-Спутник» или как мы сделали платформу для гидрологов «Замедлиться, чтобы ускориться»: почему ИИ повышает цену ошибок в требованиях и архитектуре Как с нуля поднять трафик IT-компании на 1657% при бюджете 55 тыс. и выжить Pixel-perfect Downsampling — идеальная отрисовка 50 миллионов точек без потерь
Энергия — новый дефицит. Как архитектура хранения влияет на ОРЕХ ЦОД
Дмитрий Никитин · 2026-06-25 · via Все публикации подряд на Хабре

Энергия — новый дефицит. Как архитектура хранения влияет на ОРЕХ ЦОД

Средний

8 мин

0

В течение десятилетий главным ограничением для центров обработки данных считались вычислительные мощности, скорость сетей и стоимость хранения. Но в середине 2020-х ситуация резко изменилась. Теперь на первое место выходит не место в стойках и даже не сами серверы, а электричество.

Современный ЦОД всё чаще упирается в лимиты энергоснабжения, охлаждения и тепловыделения. В некоторых регионах новые площадки уже невозможно подключить к электросетям без строительства отдельной инфраструктуры. Рост ИИ-нагрузок только ускорил этот процесс: если классический серверный шкаф потреблял 5–10 кВт, то ИИ-стойки могут выходить далеко за пределы 60 кВт и требуют совершенно иной энергетической архитектуры.

На этом фоне хранение данных перестаёт быть исключительно вопросом производительности или ёмкости. Теперь оно напрямую влияет на OPEX — операционные расходы ЦОД: счета за электричество, охлаждение, инфраструктуру питания, резервирование, UPS, генераторы и даже аренду площадей.

Парадоксально, но в эпоху SSD и ИИ индустрия снова возвращается к старой идее: не все данные должны храниться одинаково.

Когда киловатт важнее терабайта

В 2024 году дата-центры мира потребляли около 415 ТВт·ч электроэнергии — примерно 1,5% мирового потребления электричества. По прогнозам, к 2030 году этот показатель может вырасти до 945 ТВт·ч.
Это уже не «незаметная» отрасль инфраструктуры. По масштабу энергопотребления дата-центры начинают конкурировать с крупными промышленными секторами и целыми государствами. Особенно показателен пример Ирландии — одного из крупнейших европейских хабов гиперскейлеров. В 2024 году дата-центры потребляли около 22% всей электроэнергии страны. Для сравнения: в 2015 году их доля составляла лишь 5%.
В США ситуация развивается аналогично. По оценкам EPRI и DOE, к концу десятилетия дата-центры могут потреблять до 9–12% всей электроэнергии страны.

И здесь важно понимать: рост энергопотребления связан не только с GPU и обучением нейросетей. Огромную роль играет хранение данных.

Хранение — это не «пассивная» инфраструктура

Многие воспринимают системы хранения как нечто вторичное: данные лежат на дисках, пока серверы работают. Но в реальности хранение — это постоянно работающая энергетическая система. Даже если пользователь ничего не делает с данными, массивы продолжают вращать шпиндели HDD, питать контроллеры, поддерживать кэш, синхронизировать RAID, выполнять фоновые проверки, обслуживать дедупликацию и охлаждаться. Именно поэтому стоимость хранения определяется не только ценой носителя, но и стоимостью его поддержания в «живом состоянии».

В современном ЦОД почти каждый ватт, потреблённый ИТ-оборудованием, требует дополнительных затрат на охлаждение. Электричество превращается в тепло, а тепло нужно отводить. Поэтому 1 кВт нагрузки редко остаётся просто 1 кВт в счёте за электроэнергию.
Отсюда возникает ключевой показатель индустрии — коэффициент эффективности энергопотребления (PUE, Power Usage Effectiveness). Если PUE равен 1,5, это означает, что на каждый киловатт, потреблённый ИТ-оборудованием, ещё 0,5 кВт тратится на инфраструктуру: охлаждение, вентиляцию, питание и вспомогательные системы.
Иными словами, лишние 100 кВт хранения могут означать не 100, а 150–180 кВт реального потребления площадки.

SSD: энергетический парадокс

На первый взгляд SSD выглядят идеальным ответом на энергетический кризис: у них нет механики, ниже задержки, выше IOPS и ниже энергопотребление на операцию. И это действительно так — для горячих данных.

Проблема начинается тогда, когда SSD используют для хранения массивов редко востребованной информации. Флэш-память очень энергоэффективна при интенсивной работе, но экономически невыгодна для холодного хранения. Причина проста: стоимость хранения петабайтов на SSD остаётся высокой, а сами устройства требуют постоянного питания и контроллерной инфраструктуры.

Кроме того, рост плотности NAND приводит к усложнению коррекции ошибок, увеличению фоновых процессов и росту тепловыделения. Современные NVMe-системы высокой плотности уже становятся серьёзным источником тепла в стойках.

В ИИ-ЦОД это особенно заметно. Высокоплотные NVMe-массивы начинают конкурировать с вычислительными узлами за энергетический и тепловой бюджет.

HDD: дешёвые терабайты, дорогая эксплуатация

Жёсткие диски долгое время считались оптимальным компромиссом между ценой и объёмом. Но у HDD есть фундаментальная проблема: механика требует постоянной энергии. Даже если данные не читаются, диск вращается, поддерживает позиционирование головок, участвует в работе RAID-массива и нагревается. В масштабах одного диска это кажется мелочью. Но современный архивный кластер может содержать десятки тысяч HDD.

Представим систему на 20 000 дисков с усреднённым энергопотреблением 8 Вт на диск. Только шпиндели будут постоянно потреблять около 160 кВт. С учётом охлаждения и инфраструктуры реальная нагрузка может приближаться к 250–300 кВт. За год это превращается в миллионы киловатт-часов.
А теперь главный вопрос: действительно ли все эти данные нужны в онлайн-режиме?

Очень часто — нет.

Исследования эксплуатационных профилей показывают, что огромная часть корпоративных данных практически не читается после первых месяцев жизни. Но они продолжают храниться в дорогой онлайн-инфраструктуре, как будто к ним обращаются ежесекундно.

Именно здесь архитектура начинает влиять на экономику.

Главная ошибка хранения: одинаковое отношение ко всем данным

На практике многие компании строят инфраструктуру по принципу «всё всегда онлайн». Причины понятны — их так проще администрировать и автоматизировать, меньше задержек и нет необходимости в сложной политике жизненного цикла данных. Но энергетически это катастрофически неэффективно.

Хранить архив десятилетней давности на постоянно вращающихся HDD или NVMe — примерно то же самое, что держать двигатель автомобиля заведённым круглосуточно только потому, что машина может понадобиться завтра.

Современная экономика хранения требует не просто масштабирования, а стратификации данных.

«Горячо-холодно» в иерархии хранения

Иерархическое хранение появилось давно, но раньше его основной целью была производительность. Теперь на первый план выходит энергетика.

Горячие данные

Это данные, к которым обращаются постоянно: базы данных, виртуальные машины, транзакционные системы, ИИ-инференс, аналитика в реальном времени. Для них оправданы NVMe, all-flash массивы, высокоскоростные SAN, многоуровневое кэширование. Здесь стоимость ватта компенсируется бизнес-ценностью скорости.

Тёплые данные

Данные, к которым обращаются периодически: резервные копии последних недель, медиаконтент, аналитические выгрузки, инженерные архивы, активные репозитории. Обычно используются HDD-кластеры, объектные хранилища, плотные массивы промежуточного слоя хранения. Задача — максимальная ёмкость при умеренном энергопотреблении.

Холодные данные

А вот здесь начинается настоящая энергетическая экономика. Холодные данные — это долгосрочные архивы, хранение файловдля соблюдения нормативных требований, юридические копии, научные архивы, исторические бэкапы, медиахранилища и «на всякий случай». Ключевая особенность: эти данные почти никогда не читаются. И именно здесь онлайн-диски становятся крайне неэффективными.

Почему лента до сих пор актуальна

Магнитная лента десятилетиями считалась «устаревшей технологией». Но энергетический кризис ЦОД неожиданно вернул её в центр внимания. Главное преимущество ленточного хранения предельно простое:

картридж вне привода не потребляет энергию вообще.

Не «мало». Не «экономично». Ноль.

В отличие от HDD-массивов, где вся система постоянно находится под питанием, ленточный архив потребляет заметную энергию только в момент чтения или записи. По некоторым оценкам, ленточные системы могут потреблять до 1500 раз меньше энергии по сравнению с сопоставимыми дисковыми архивами.

Это колоссальная разница. Особенно если речь идёт о сотнях петабайт архивных данных.

Разница в энергоэффективности между типами носителей:

Вывод: для одного и того же объёма данных HDD потребляет в ~3 раза больше энергии, чем SSD, и в ~300–400 раз больше, чем лента.

Реальные примеры

IBM, 2022.

Данные: 65% всех данных в ЦОД — архивные (холодные). Решение: перенос архива с HDD на ленту.

Результат:

  • Снижение энергопотребления на >93% для архивных данных.

  • При 10 ПБ архива — до 7% снижения общего потребления ЦОД.

  • Отсрочка инвестиций в новую инфраструктуру.

Вывод: лента — не устаревшая технология, а стратегический инструмент устойчивости.

Evaluator Group, 2024.

Сценарий: 80% неактивных данных перемещены из all-flash массива в публичное облако через FabricPool.

Результат:

  • 30% экономии TCO за 5 лет.

  • Освобождение производительного flash-хранилища для горячих данных.

  • Автоматизация на основе политик без участия администратора.

Вывод: автоматическая иерархия окупается за 2–3 года даже без учёта растущих цен на энергию.

C4C Group, 2025.

Проблема: фрагментированная инфраструктура из трёх вендоров, растущие расходы на питание и охлаждение.
Решение: консолидация на единой платформе + автоматическая иерархия «Горячие/ Тёплые/ Холодные».

Результат:

·       Площадь ЦОД уменьшена на 45%

·       Производительность выросла на 38%

·       Питание и охлаждение сократились на 30%

·       Стоимость за ТБ снизилась на 25–40%.

Вывод: правильная иерархия + консолидация = прямое снижение OPEX на треть.

Формула OPEX хранения: как считать экономию

Операционные расходы на хранение складываются из:

OPEXstorage=EIT×Celec+Ecooling×CHVAC+CMaintenance, где

EIT​ - потребление носителей хранения, кВт·ч/год;

Celec​ - цена электроэнергии, руб./ кВт·ч;

Ecooling​ - энергия на охлаждение оборудования, кВт·ч/год;

CHVAC​ - стоимость охлаждения, руб./ кВт·ч;

CMaintenance - расходы на техническое обслуживание (сервисные договоры, ремонт, замена компонентов, персонал), руб./год.

Пример расчёта: 100 ПБ данных

Число часов в году: 8766, 100 ПБ = 100 000 ТБ.

Вывод: правильная иерархия снижает OPEX на 85–90% для архивных данных.

Охлаждение: скрытый множитель расходов

Очень часто при расчёте стоимости хранения компании учитывают только цену носителей, стоимость массивов, лицензии, обслуживание. Но игнорируют охлаждение. А ведь именно оно становится одним из самых дорогих компонентов OPEX.

Каждый дополнительный ватт хранения нагревает помещение и увеличивает нагрузку на системы охлаждения ЦОД. Причём проблема усиливается климатом. Исследования показывают, что значительная часть мировых дата-центров расположена в регионах с тёплым климатом, где охлаждение требует дополнительных затрат энергии.

В эпоху ИИ-нагрузок это превращается в стратегическую проблему.

Будущее ЦОД: энергия как архитектурное ограничение

В ближайшие годы отрасль всё сильнее будет делиться на два мира.

Первый — сверхплотные вычислительные площадки для ИИ и высокопроизводительные нагрузки, где каждый киловатт критически важен.

Второй — энергоэффективные архивные платформы, где главная задача — хранить максимум данных при минимальном потреблении.

Именно поэтому будущее хранения — не в победе одного носителя над другим. Не существует универсальной технологии, одинаково хорошей для всех. Настоящая эффективность возникает только тогда, когда данные автоматически перемещаются между уровнями хранения в зависимости от их жизненного цикла и ценности.

Как проектировать хранение в эпоху дорогой энергии

Шаг 1: Аудит «температуры» данных

  • Измерьте частоту обращений к каждому набору данных.

  • Выделите 20% горячих, 30% тёплых, 50% холодных.

Шаг 2: Автоматизируйте иерархию

·       Используйте политики, основанные на времени хранения (например, перенос через 90 дней без доступа).

·       Используйте автоматическое перемещение редко используемых данных в более дешёвые и энергоэффективные архивные слои хранения — локальные ленточные архивы.

Шаг 3: Выберите носитель по «температуре»

Шаг 4: Пересчитывайте OPEX ежегодно

  • Учитывайте рост цен на электроэнергию.

  • Проверяйте PUE после внедрения иерархии.

Экономика будущего: дешёвое хранение — это уже не про цену диска

Долгое время индустрия измеряла эффективность хранения через стоимость терабайта. Но эпоха энергетических ограничений меняет правила. Теперь важны ватт на терабайт, охлаждение на петабайт, плотность хранения, стоимость доступности данных, энергетическая цена «всегда онлайн» и углеродный след хранения. Именно поэтому архитектура «Горячие/ Тёплые/ Холодные» перестаёт быть исключительно технической концепцией. Она становится финансовой моделью ЦОД.

Компании, которые продолжат хранить весь массив данных на постоянно активных системах, будут платить не только за диски, но и за электричество, охлаждение, UPS, генераторы, расширение энергоснабжения.

В эпоху, когда электричество дороже оборудования, правильная архитектура хранения становится ключом к выживанию и конкурентоспособности ЦОД. Данные имеют температуру.
И эта температура определяет ваш счёт за электроэнергию.

Каковы ваши мысли на этот счёт?