Рамка
Параллельный мир
Снаружи — цифровая экосистема для миллионов пользователей. Внутри — классика, купленная в 2026 году.
Снаружи это группа компаний с массовым цифровым продуктом. Приложение открывает счёт за пару минут, сервис работает без очередей и офисов, пользователей миллионы. Это витрина цифровой экосистемы в самом современном её понимании.
Внутри работает классика: трёхуровневая архитектура, VMware по подписке VCF, FC-фабрика на Brocade, сеть на Cisco, бэкап на Data Domain и многошкафная ленточная библиотека. Каждая новая потребность закрывается новым классом оборудования от вендора первого эшелона. Экономия на компонентах здесь не принята как метод.
Портрет ниже собирательный по форме, но вполне конкретный по содержанию: всё описанное есть в открытых источниках. Этот парк строили и обслуживают не мы. Мы хотим разобраться в его логике, а не оценивать чужой выбор, поэтому пишем без иронии. У этого мира есть своя последовательная логика, и она заслуживает разбора.
Вычисления
Хосты партиями
Сотни хостов, волны по несколько десятков, одна конфигурация у двух производителей сразу.
Парк виртуализации измеряется сотнями хостов, и растёт он волнами по несколько десятков одинаковых серверов. Типовой хост последней волны — 1U, два процессора по 32 ядра, около 1.5 TB памяти и ни одного диска данных. Загрузка идёт с зеркальной пары M.2, а наружу выведены два двухпортовых HBA на 32G и два двухпортовых адаптера 25GbE.
В этом описании важны три детали.
Первая — хост без дисков. Данные живут на массивах, хост только считает. Отказавший сервер выводится из кластера и заменяется новым с тем же профилем за час. То есть хост здесь расходник, а не место хранения.
Хост без дисков — расходник. Его меняют, не задумываясь, потому что данные живут не на нём.
Вторая — одна и та же конфигурация запрашивается у двух производителей сразу. В одной закупке лежат практически идентичные спецификации на Dell PowerEdge и HPE ProLiant: тот же процессор, тот же объём памяти, тот же набор адаптеров. Выигрывает тот, кто даст лучшие условия и срок поставки. Кластеру VMware безразлично, чей шильдик на корпусе, а закупке это даёт защиту от дефицита и от зависимости от одного вендора.
Третья — выбор середины по ядрам. В выпуске 08 мы писали, что лицензирование по физическим ядрам тянет к процессорам с меньшим числом ядер, а в выпуске 10 — что питание и плотность тянут в обратную сторону. Здесь выбор сделан посередине: 32 ядра на сокет, 64 на хост. Подписка VCF считает минимум 16 ядер на процессор, так что вилка для волны из 50 хостов идёт от 1600 ядер подписки на самых скромных процессорах до 9600 на 96-ядерных. Выбранная середина даёт 3200, и это только одна волна.
К этому же решению относится память. На хосте 64 ядра и около 1.5 TB памяти, то есть примерно 24 GB на ядро. Подписка считается по ядрам, а память в неё не входит, поэтому её выгодно набирать по максимуму, а ядра держать в середине. В выпуске 08 мы называли это неизменным лицензионным периметром: ВМ получают больше ресурсов, а счёт за подписку не растёт.
Сеть хранения
Фабрика, которую не выключают
FC здесь не наследство, а выбор: его расширяют, а не доживают.
Хранение подключено к хостам по Fibre Channel через две независимые фабрики на коммутаторах Brocade. Фабрику не перестраивают и не заменяют на Ethernet, её расширяют. Новые коммутаторы ставятся текущего поколения с оптикой 32G, а порты добавляются лицензиями по 8 штук за раз. То есть растёт ёмкость той же топологии, к которой уже привыкли эксплуатация, мониторинг и процедуры.
Деталь, которая хорошо показывает логику: новые коммутаторы относятся к поколению 64G, но приходят с оптикой 32G — под те HBA, что стоят в хостах. Скорость фабрики можно будет поднять позже, заменой оптики и адаптеров, не трогая сами коммутаторы. Фабрику покупают на вырост, а платят за ту скорость, которая нужна сейчас.
В выпуске 09 мы показывали, что при уходе с VMware выделенную FC-фабрику часто можно убрать и отдать её полосу Ethernet на 25G и 100G. Здесь логика обратная, и она последовательна. FC даёт предсказуемую задержку, физически отделяет трафик хранения от остальной сети и опирается на компетенции, которые у команды уже есть и которые легко найти на рынке. Пока основная платформа трёхуровневая, отказываться от FC незачем.
Однако за это приходится платить. Первое — две сети вместо одной: отдельные коммутаторы, отдельная кабельная система и отдельные контракты поддержки. Второе — отдельный набор знаний, который нужно держать в команде. Этот мир платит за обе позиции осознанно.
Хранение
Своя полка на каждую задачу
Новая потребность не втискивается в существующий массив — под неё покупается новый класс.
Массивов в этом мире десятки, и разброс поколений идёт от гибридных систем с вращающимися дисками до новейших all-NVMe. Новая потребность не втискивается в существующий массив: под неё покупается новый, подходящий по классу. Судя по открытым описаниям вакансий, рядом работают массивы как минимум двух производителей и отдельное объектное хранилище S3, то есть разнородность здесь не только по поколениям, но и по вендорам.
Принцип «своя полка на каждую задачу» виден и по структуре группы. Каждая компания внутри неё получает собственный блочный массив и собственную платформу для файлов и объектов. В последних закупках это Pure Storage: FlashArray парой под блочную нагрузку и FlashBlade парой под объект и файл. Старшая модель сразу ставится с внешними фабричными модулями, чтобы потом расти в несколько шасси. Отдельно существует контур на локальном NVMe — серверы с десятью накопителями по 7.68 TB, по всей видимости под vSAN.
Разнородностью здесь управляет VMware. Storage vMotion переносит ВМ между массивами без остановки, политики хранения выбирают класс носителя, а гипервизор выступает общим знаменателем для всего, что стоит ниже. Без этого слоя десятки массивов превратились бы в десятки островов.
Цена этого — десятки жизненных циклов. У каждого массива свой срок поддержки, своя матрица совместимости прошивок, своя консоль и свой инженер вендора на эскалации. В выпуске 11 мы писали про парк, который нарастает слоями. Здесь те же слои, только каждый куплен новым и стоит на поддержке.
Вторая площадка
Две скорости репликации
Синхронно — там, где ошибка стоит секунд транзакций. Асинхронно — всё остальное.
Вторая площадка получает основной объём данных асинхронно. RPO измеряется минутами, канал не определяет задержку записи на основной площадке, а дистанцию между площадками можно выбирать по рискам, а не по физике синхронной записи. В выпуске 07 мы считали предел синхронной схемы на 50 и на 600 км. Для основного парка этот вопрос здесь просто не стоит.
Рядом работает синхронный контур. Массивы с ActiveCluster держат данные одновременно на двух площадках там, где потеря даже нескольких секунд транзакций дороже, чем добавочная задержка записи. Это та часть, ради которой пользователь и открывает приложение.
Почему синхронный контур держится на массивах, а не на средствах самой виртуализации? В VCF 9.1 растянутый Metro-кластер на vSAN ESA есть. А вот репликация на удалённую площадку с оркестрацией переключения в базовую подписку не входит: для неё нужен отдельный продукт восстановления или аддон ACC, который доступен только для VCF. Когда хранение и так живёт на внешних массивах с FC, а массивы умеют синхронную пару сами, логичнее отдать репликацию им. Гипервизору остаются перезапуск ВМ и планы переключения.
То есть репликация разделена по цене ошибки. Синхронная схема стоит дорого и по железу, и по каналу, поэтому применяется к контуру, где RPO должен быть нулевым. Всё остальное живёт на асинхронной схеме с понятными планами восстановления. Деньги позволили бы сделать синхронным всё, но этот мир так не делает, и это хороший признак: разделение здесь продиктовано инженерной логикой, а не бюджетом.
Резервное копирование
Бэкап по учебнику
Софт резервного копирования, Data Domain на каждой площадке и многошкафная лента — лестница защиты целиком.
Резервное копирование построено так, как его рисуют в учебных курсах вендоров. Софт резервного копирования снимает ВМ и пишет копии на Data Domain через DD Boost. Дедупликация начинается на стороне источника, и в сеть уходят только уникальные блоки. На каждой площадке стоит свой апплайнс, а DD Replication передаёт между ними уже дедуплицированные данные. Ёмкость куплена вечными лицензиями, поддержка — на 5 лет вперёд. Апплайнсы ставятся без внутреннего HA-кластера: резервом служит вторая площадка, а не второй контроллер.
Долгосрочное хранение уходит на ленту. Большая многошкафная библиотека — последняя ступень лестницы, о которой мы писали в выпуске 13. Она самая дешёвая по терабайту, самая медленная на восстановление и физически отделена от всего, что можно зашифровать удалённо.
В выпуске 13 мы оставили открытым вопрос, нужны ли дедуп-апплайнсы как класс, если дедупликация уже есть на медиа-сервере. В этом мире ответ однозначный: нужны. Если масштаб — сотни хостов, а бюджет позволяет, апплайнс даёт глобальную дедупликацию по всем заданиям, предсказуемую скорость приёма и репликацию, которой не нужно управлять отдельно. Решение не для всех, но внутри своей логики оно цельное.
Безопасность и доставка
Периметр и доставка — тоже на гипервизоре
Межсетевые экраны, балансировщики, WAF и гостевые Linux — всё держится на VMware.
На границе стоят аппаратные межсетевые экраны того же производителя, что и сеть, а сервер их централизованного управления развёрнут как ВМ на VMware. Балансировщики и WAF куплены в виде виртуальных апплайнсов и тоже работают на VMware. Гостевые Linux лицензируются по модели «на хост гипервизора»: одна подписка закрывает любое число ВМ на двухсокетном сервере.
То есть VMware здесь не просто гипервизор. На нём держатся безопасность, доставка приложений, лицензирование гостевых ОС и управление сетью. Уход с него был бы многолетней программой, которая затронула бы каждый слой, а не проектом миграции ВМ. Поэтому мир и не уходит: если считать не только подписку, но и всё, что на ней стоит, решение остаться выходит дешевле решения уйти.
Когда на гипервизоре живут периметр, балансировка и лицензии гостевых ОС, уход — это не миграция, а перестройка.
Среды
Тест за стенкой
Граница между тестом и продуктивом проведена не в VLAN, а в шкафах.
Тестовая зона отделена от основной физически: отдельный шкаф, свои хосты, свои коммутаторы. Логическое разделение через VLAN и отдельные кластеры здесь достаточным не считается.
Логика понятна. Физическая граница исключает случайное пересечение тестового трафика с продуктивом, упрощает аудит и разговор с регулятором. Изменения проходят через стенд, который не делит с продуктивом ни одного порта.
Однако у такой границы есть цена. Железо, которое большую часть времени загружено частично, занимает место, питание и контракты поддержки наравне с продуктивным. При сотнях продуктивных хостов тестовый шкаф составляет малую долю парка, и мир эту долю спокойно оплачивает.
Практики
Современное внутри классики
Terraform и ванильный Kubernetes поверх VMware: современное не обязано быть новым.
Самая неожиданная деталь портрета — то, как этот мир работает с изменениями. Инфраструктура описывается кодом: Terraform с провайдером vSphere создаёт ВМ, сети и политики. Контейнерные нагрузки работают в ванильном Kubernetes, развёрнутом на обычных ВМ поверх VMware, а хранение для подов выдаётся через vSphere CSI. Никакой Tanzu и никакого VKS, просто кластеры на ВМ.
У этого выбора есть практическое объяснение. Как мы писали в выпуске 14, отдельная Tanzu Kubernetes Grid закончилась на версии 2.5.4, а VKS работает только поверх Supervisor, то есть привязан к тому, как VMware развивает контейнерный слой. Ванильный Kubernetes на обычных ВМ от этого не зависит: его можно обновлять в своём темпе, а при желании перенести на другую платформу вместе с манифестами и Terraform-кодом.
В выпуске 14 мы утверждали, что Terraform и Ansible переживают уход с VMware и что мир на VMware не заканчивается. Здесь тот же тезис виден с обратной стороны: современные практики не требуют новой платформы. Декларативное описание инфраструктуры и контейнерная оркестрация прекрасно работают на классике. Связь между «современным» и «новым» слабее, чем принято думать.
Нагрузки ИИ
ИИ сразу флагманом
Без пилота и промежуточных поколений — сразу кластер на B300 и отдельная фабрика 400/800G.
Когда понадобились вычисления для ИИ, этот мир не стал проходить промежуточные ступени. Обычный путь идёт от пары карт в обычном сервере через пилотный узел к кластеру. Здесь не было ни пилота, ни поколения H100 или H200: сразу закупается кластер меньше чем из десятка узлов по 8 ускорителей B300, причём с выбором из двух вариантов поставки — Cisco UCS и Supermicro.
Под кластер строится отдельная Ethernet-фабрика на Cisco Nexus. Фронтенд работает на 400G по схеме spine-leaf, и существующие коммутаторы ЦОДа включаются в неё как leaf. Бэкенд для обмена между ускорителями использует 800G-оптику. Каждый узел получает около 3 TB памяти, локальные NVMe и адаптеры по 200G, а в варианте Cisco ещё и DPU.
То есть в одном ЦОДе работают две скорости сети. Хосты основного парка подключены по 25GbE, и этого им хватает, потому что хранение идёт по отдельной FC-фабрике. ИИ-кластер живёт на 400G и 800G, и его фабрика к основному парку не добавляет ничего, кроме общих leaf-коммутаторов.
Логика прыжка через поколения такая. Разрыв между H100 и B300 по памяти и пропускной способности слишком велик, чтобы промежуточная закупка успела окупиться до следующей. Кто покупает ступень за ступенью, платит дважды и дважды перестраивает питание. Кто может сразу взять флагман, делает это один раз.
Цена приходит в киловаттах. В выпуске 10 мы писали, что узел на 8 ускорителей с воздушным охлаждением вырос с 3.5 до 8.6 kW. Узел на B300 по нашей оценке потребляет уже больше 12 kW, а производители закладывают на стойку с такими узлами до 70 kW. Если умножить на число узлов, кластер меньше чем из десятка таких машин выходит около 100 kW — это больше, чем потребляет площадка из четырёх стоек с пятью поколениями оборудования, которую мы разбирали в выпуске 11. Мы знаем, что далеко не каждый собственный или коммерческий ЦОД имеет такой ввод на стойку. Для этого мира это решаемая инженерная задача, а не ограничение.
Что перенять
Что этот мир делает правильно
Предсказуемость, двойной источник поставки, горизонт поддержки и разделение по классам.
Если убрать всё, что связано с бюджетом, у этого мира останется несколько решений, которые стоит перенять любому.
Предсказуемость важнее элегантности. Каждый слой понятен, задокументирован у вендора и знаком любому инженеру, которого можно нанять. Экзотики, которую знает один человек, здесь нет.
Сравнение на одной спецификации. Конфигурация собирается заранее, под нагрузку, и только потом уходит производителям. Участники соревнуются сроками и условиями, а не тем, кто сильнее урежет спецификацию. Ценно здесь не число вендоров, а то, что сравнивают одно и то же.
Горизонт поддержки покупается сразу. Пять лет поддержки в момент закупки покрывают 3 года первичной эксплуатации и почти весь второй круг и снимают вопрос постгарантии, о котором мы писали в выпуске 06. А волны закупки держат большую часть парка в возрасте до 6 лет, где по нашей шкале доверие к оборудованию не опускается ниже 85–90%.
Разделение по классам. Своя полка под каждую задачу, синхронная репликация только для контура с нулевым RPO, физическая граница для теста — всё это примеры одного принципа: не смешивать то, что можно не смешивать.
Современные практики без смены платформы. IaC и контейнеры внедрены там, где люди уже работают, без ожидания большой миграции.
Пределы
Где у этого мира границы
Пределы видны даже при неограниченном бюджете: ядра, разнородность, ввод и поток денег.
Лицензии растут вместе с волнами. Каждая партия хостов увеличивает лицензионную базу VCF пропорционально ядрам. При подписочной модели это постоянный, а не разовый расход, и если вендор пересматривает цену, этот расход растёт быстрее самого парка.
Разнородность всё равно накапливается. Двойной источник поставки защищает закупку, но приводит к смешанному парку: две линейки серверов, два набора прошивок и инструментов управления. Добавьте к этому десятки массивов разных поколений — и получится, что каждый слой однороден внутри себя, а их сочетание сложное. Часть парка этот вопрос уже закрывает: новые массивы Pure куплены с подпиской Evergreen, где поддержка идёт по неизменной ставке, а контроллеры и ёмкость обновляются без остановки и без замены массива целиком. Но на десятки систем прошлых лет это не распространяется.
Киловатты. Две сети вместо одной, физически отдельный тест, многошкафная библиотека и ИИ-кластер мощностью под сотню киловатт делают этот мир ограниченным по вводу раньше, чем по месту. В выпуске 10 мы называли это так: стойка кончается раньше. Здесь раньше кончается ввод.
Зависимость от потока денег. В выпуске 12 мы описывали инфраструктурный долг. У этого мира долга нет, пока платят: всё на подписке, всё на поддержке, всё обновляется волнами. Но именно такая модель накапливает долг быстрее всех, если поток прерывается. Подписки истекают одновременно, поддержка массивов заканчивается каскадом, а новые волны перестают приходить. Устойчивость этого мира — функция бюджета, а не архитектуры.
У этого мира нет долга, пока платят. И нет запаса прочности, если перестанут.
Чек-лист
Чек-лист: что взять без такого бюджета
Десять пунктов, которые работают и без сотен хостов на подписке.
Итог
Вместо вывода
Параллельный мир не отстал от рынка. Он выбрал другую ось оптимизации: вместо стоимости владения — предсказуемость, вместо унификации — свой класс оборудования под каждую задачу, вместо миграции — расширение того, что уже работает.
В одном из ближайших выпусков мы опишем противоположный полюс — парк, собранный из самого дешёвого, что формально проходит требования. Реальные заказчики живут между этими полюсами, и почти у каждого найдётся что взять с обеих сторон.
Если ваш парк ближе к этому миру, чем к тому, и вы хотите понять, где он держится на архитектуре, а где только на бюджете, давайте разберём это вместе.