Привет, постоянные и не очень читатели!

Всего одна сделка (зато какая — на 61 000 000 000 $) неплохо так встряхнула мир виртуализации и IT в целом: Broadcom купила VMware, упразднила кучу SKU и ввела подписную модель лицензирования крупными пакетами (многие оплачивают то, что им и не нужно вовсе, так как пакетов меньше просто нет). 

Самое плохое, что ни партнёры, ни конечные клиенты не были готовы к такому повороту событий и сопутствующему ущербу, а потому долго оправлялись: 

• Кто-то обанкротился (не шучу — сотни VAR/MSP потеряли статус и клиентов без предварительных ласк, что схлопнуло их бизнес или значительную его часть); 

• Кто-то (не будем тыкать пальцем в Siemens) частично использует ПО без лицензий; 

• Кто-то ушел в OpenStack (например, американская страховая компания Geico), Nutanix (австралийская финтех-компания Computershare перенесла 24000 виртуалок) и Proxmox VE (технологическая компания HorizonIQ из Штатов) с Ceph; 

• А кто-то хочет уйти от VMware, но не может из-за жесткой привязки к вендору. 

Вариантов, как все выкручиваются, много, а довольных новой моделью VMware by Broadcom — мало. Если у вас тоже наболело или вы просто зашли поглядеть на ещё один способ сложить (или нет?) все виртуалки в одну проприетарную корзину Huawei Cloud Stack, то эта серия статей для вас.

Если что-то интересующее вас в материал не попало, то задавайте вопросы в комментариях. Я или хабравчане, которые уже работали с Huawei Cloud Stack, дадим ответ. А в крайнем случае всегда можно изучить официальную документацию — у Huawei она более чем подробная.

Что такое Huawei Cloud Stack

Huawei Cloud Stack (HCS) — это полноценное, готовое из коробки решение для частного (on-premise aka локальное размещение) и гибридного облака. С ним вы получаете платформу, объединяющую виртуальные машины, контейнеры (K8s), инструменты хранения и аналитики больших данных, работу с ИИ, а в довесок — те же API и интерфейсы, что и в публичном облаке Huawei (что хорошо для гибридных сценариев). В регионах, вроде России, у Huawei есть локальные технологические партнеры (например, Cloud.ru — бывший SberCloud — для публичного облака).

Суть HCS в физическом распределении и логическом объединении IT-инфраструктуры. Физически у вас может быть несколько ЦОДов или серверных в разных регионах или даже городах, объединённых единой облачной платформой, которая собирает разрозненное железо в общий пул ресурсов. С программной точки зрения Huawei Cloud Stack даёт единую платформу эксплуатации и технического обслуживания (O&M, Operations and Maintenance) ЦОДов в разных регионах: мониторинг состояния серверов, отслеживание аварий, замена отказавшего узла, обновление ПО, управление конфигурациями — всё это доступно через единый интерфейс с отвязкой самих облачных сервисов от модуля управления.

Коротко по техническому фундаменту Huawei Cloud Stack: он исторически вырос из OpenStack-архитектуры и до сих пор во многом опирается на неё как на базовый слой IaaS. Но в актуальных версиях это уже не чистый OpenStack, а сильно переработанный стек с глубокой интеграцией проприетарных компонентов Huawei. 

Под капотом там связка из виртуализации на KVM, сетевой части с SDN-оркестрацией, и распределённого хранилища (по смыслу близкого к Ceph-подходу, но в реализации это их стек: Huawei OceanStor + сопутствующие компоненты). Поверх этого лежит собственная облачная операционная платформа Huawei — FusionSphere/OpenStack-стек в разных поколениях решений, плюс слой управления и эксплуатации через проприетарную платформу управления ManageOne (про неё дальше).

Контейнерная часть построена вокруг Kubernetes (как стандартный оркестратор для облачных сервисов) и сервиса Cloud Container Engine (CCE), который отвечает за развёртывание и управление Kubernetes-кластерами. Для PaaS и нативных облачных сценариев (cloud-native) есть сервис ServiceStage и другие компоненты экосистемы Huawei Cloud.

Как видите, это не просто OpenStack-дистрибутив, а потому поговорим о причинах, из-за которых корпоративные и государственные инфраструктуры строят на Huawei Cloud Stack, а не на других решениях, вроде VMware или публичных облаков.

Почему выбирают Huawei Cloud Stack

Многие конкуренты предлагают либо чистую виртуализацию, либо сложный OpenStack, который требует высоких компетенций у команды. А HCS подходит тем, кто просто хочет развернуть облако локально в своём ЦОДе или серверной (возможен и гибридный вариант), при этом получить удобство и пользовательский опыт, сопоставимые с Apple VMware.

Huawei Cloud Stack предлагает готовый стек (что очевидно из названия) под ключ с быстрым стартом: не нужно отдельно собирать гипервизор, сеть, SDS и управление. Ещё один плюс: Huawei — как комплексный вендор — предлагает заказчикам и железо (разумеется, HCS работает лучше всего на серверах Huawei FusionServer и xFusion, СХД OceanStor, коммутаторах CloudEngine), и софт, и поддержку, и какую-никакую уверенность, что завтра всё не схлопнется: компания давно доказала свою устойчивость к кризисам, жестким международным санкциям и конкуренции.

Даже если гипотетически что-то пойдёт не так, Компартия не оставит Huawei в беде, так как компания занимается технологическим суверенитетом Китая. На деле же у HCS всё замечательно: аналитическое агентство Omdia (Omdia Universe: CloudOps, 2025) поставило Huawei Cloud Stack на 1-е место в области управления облачными операциями (CloudOps). Платформа получила высочайшие оценки за развитые инструменты наблюдаемости, мониторинга и централизованного управления.

И есть за что.

Админы работают с HCS через платформу управления облаком (CMP, cloud management platform) ManageOne — это централизованная система и единая точка входа, через которую можно управлять частным и публичным облаками, а также комплексно мониторить всё это добро (от физического оборудования до приложений). Всё построено на удобном GUI.

В ManageOne есть система SecMaster — центр безопасности (SOC — Security Operation Center) с мониторингом в реальном времени и автоматическим реагированием. Он собирает и коррелирует события безопасности со всех облачных сервисов для комплексной видимости на единой панели управления. SecMaster может автоматически обрабатывать до 99% рутинных инцидентов безопасности. Очень полезно для больших корпоратов, госов, телекома и других зарегулированных заказчиков, но и для SMB будет полезно.

В составе платформы Huawei Cloud Stack есть встроенная система управления данными, которая сама отслеживает шесть аспектов качества и достоверности данных (целостность, эффективность, своевременность, согласованность aka когерентность, точность, уникальность) и сравнивает данные из разных систем. Система использует ИИ-инструменты для автоматизации этих процессов.

У платформы современная облачно-ориентированная архитектура, а поставляется она с инструментами автоматического развертывания HCC Turnkey (инструмент жизненного цикла и автоматизации развертывания, настройки и ввода в эксплуатацию Huawei Cloud Stack).

Подытожим. Huawei Cloud Stack чаще всего рассматривают не как замену какого-то голого гипервизора или SDS, а как полноценную зрелую платформу-сервис для построения облачной инфраструктуры корпоративного уровня. Она аналогична по функционалу публичным облакам AWS, Azure и Google Cloud, но работает на вашем оборудовании. Во многих сценариях (хоть, конечно, и не во всех) это полноценная альтернатива VMware + NSX + vSAN, Nutanix, Microsoft Azure Stack, OpenStack (Red Hat и др.), связке Proxmox VE + Ceph + ... + ... + …

Сценарии применения HCS в продакшене

В этом разделе я не стану рассказывать о том, как применяют частные/гибридные облака в целом (как класс) — про это есть килотонны материала на Хабре и в интернетах. Куда интереснее посмотреть, как используют именно Huawei Cloud Stack в инсталляциях, и какие задачи платформа решает. Да, многое перекликается с индустрией, но все проприетарные фичи, особенности и терминология будет именно из мира HCS. И, разумеется, это не взаимоисключающие сценарии.

1. Конвергентный пул ресурсов

Когда компании переходят на облака, они переходят и на конвергентные пулы ресурсов (грубо говоря, это общий слой ресурсов для виртуалок, контейнеров и облачных сервисов), созданных на основе физической инфраструктуры. Huawei заявляет бесшовную интеграцию с тем, что уже есть. Если сильно упростить, то HCS подхватит вашу инфраструктуру через единую систему управления ManageOne — и вы сможете управлять как старыми ресурсами (например, VMware) так и новым облаком из одного окна, не пересобирая железо. В итоге у вас получится среда, где все сервисы, софт и железо будут выделяться клиентам, обслуживаться и мониториться в едином контуре. Но на практике всё равно стараются делать это плавно, потому что нужно переобучить персонал, нанять новых специалистов и настроить централизованное управление и мониторинг/наблюдаемость. 

Итак, какие пулы есть:

• Пул виртуализации (Virtualization pool);

• Пул серверов без операционной системы (Bare metal server pool);

• Пул блочных хранилищ (Block storage pool);

• Пул файловых хранилищ (File storage pool);

• Пул сетевых ресурсов (Network resource pool);

• Пул хранилища для аварийного восстановления (DR storage pool);

• Пул хранилищ резервного копирования (Backup storage pool);

А также можно выделить ещё несколько дополнительных пулов:

• Пул ресурсов Cloud Federation с Huawei Cloud Stack: одноранговый пул ресурсов Huawei Cloud Stack подключен к локальному облаку;

• Пул ресурсов гибридного облака уровня управления: ресурсы публичного облака подключаются к Huawei Cloud Stack через API.

Для объединения и управления пулами используется ПО для виртуализации ЦОДов — FusionSphere с OpenStack-компонентами. 

В HCS конвергентный пул ресурсов основан на базе унифицированной, но при этом иерархической и доменно-ориентированной архитектуры управления (то есть вы можете управлять ресурсами и на уровне всей компании, и на уровне отдельных подразделений/филиалов — с соблюдением границ и политик). Такой подход полностью соответствует зрелой IT-среде и типовой структуре крупных компаний, например, в телекоме.

2. Облачный хостинг (Hosting Cloud)

Второй сценарий — Hosting Cloud, то есть развёртывание собственного облака на своей площадке с раздачей ресурсов пользователям. Это могут быть как внешние клиенты (у операторов связи и провайдеров), так и внутренние подразделения, отделы, филиалы и офисы в крупных компаниях.

Важный момент — это полноценная сервисная модель с изоляцией арендаторов, квотами и самообслуживанием (а не просто виртуализация). По сути получаем внутреннего облачного провайдера, а потому и требования к отказоустойчивости, процессам и поддержке должны соответствовать. Всё это (как и у других частных облаков) может работать в изолированном контуре в Offline Mode, то есть без подключения к публичным сетям вообще. Для некоторых сценариев кибербеза и комплаенс-политик это архиважно, а потому подходит госам, банкам, телекому и корпоратам с закрытыми средами.

3. Управление мультиоблачной средой (Multi-Cloud)

Следующий сценарий — Multi-Cloud. Используют, когда нужно связать разные облачные контуры и централизованно админить их — так называемая федерация облаков. Всё это реализуется через Cloud Federation с Huawei Cloud Stack Management и HCS Online Management.

Если всё сделать через Cloud Federation с Huawei Cloud Stack Management, то ManageOne может использовать ресурсы других облаков двумя способами: 

• В простом варианте одноранговые облачные ресурсы связываются через API, но тогда локальное облако поддерживает только базовый набор сервисов Huawei Cloud: виртуальные машины (ECS), диски (EVS), сети (VPC) и публичные IP-адреса (EIP). Есть и более продвинутый вариант — полноценная облачная федерация. В этом случае облака регистрируют сервисы друг у друга, и тогда вообще все ресурсы одного облака можно использовать в другом. 

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

В HCS есть отличная фича — распределение сервисов по логическим зонам доступности (Availability Zone, AZ) физических ресурсов (вычисления, сеть, хранилище) внутри одного кластера. Но чтобы этот механизм завёлся, задержки между разными AZ должны быть не более 2 мс. Так что раскидать зоны доступности по разным зданиям без дорогого DWDM-оборудования не получится. Подробнее про эту фичу будет дальше.

• Если Huawei Cloud Stack используют вместе с публичным облаком Huawei, добавляется ещё один слой — интеграция с HCS Online Management. В этом случае аутентификация и права пользователей синхронизируются, а пользователи локального облака (HCS) могут работать с сервисами публичного (HCS Online) через ту же консоль. Это сильно упрощает доступ и снижает ручную настройку, но важно помнить, что эта связка всё ещё находится внутри одной экосистемы — вы не получите универсальный мультиоблачный слой.

4.1. Независимое развертывание сервисов больших данных и управление ими

На базе облегчённой инфраструктуры (то есть HCS, из которого при установке убрали всё лишнее, оставив только компоненты управления) можно независимо развернуть глобальную зону, построить физические кластеры MRS и DWS, а также выбрать необходимые сервисы.

Чтобы развернуть независимую глобальную зону, нужно:

• Использовать HCC Turnkey — он поддерживает автоматизированную установку с нуля, добавление новых узлов/регионов и обновление версий.

• При установке убрать сетевые узлы и связанные с ними бэкенд-хранилища, а также базовые облачные сервисы (включая IaaS-сервисы и сервисы безопасности, ECS, EVS, VPC и всё, что с ними связано). По сути убираем всё, что не требуются для независимого развёртывания физических MRS и DWS-кластеров, но оставляем систему управления.

• Развернуть FusionSphere OpenStack, ManageOne, независимый пул ресурсов для сервисов больших данных и часть общих компонентов.

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

4.2. Отделение независимой глобальной зоны от существующего региона (независимое развертывание глобальной зоны)

Есть и ещё один специфический сценарий — независимая глобальная зона. Нужен он в основном крупным компаниям и операторам, которые либо мигрируют со старых версий Huawei Cloud Stack 6.5.1, либо хотят какое-то время держать обе версии параллельно инфраструктуру параллельно.

Суть в том, что раньше глобальную зону можно было жёстко связать с основным регионом, а в Huawei Cloud Stack 8.x её уже можно вынести в отдельный независимый управляющий слой. Для этого используется всё та же HCC Turnkey, через которую можно автоматически развернуть новую независимую глобальную зону; перенести в неё данные управления — например ManageOne и BCManager (ПО для аварийного восстановления), масштабировать инфраструктуру; добавлять новые регионы и сервисы, настроить межрегиональный DR (Disaster Recovery).

Если инфраструктура строится сразу на новых версиях Huawei Cloud Stack 8.x, то всё проще, так как HCC Turnkey в них — единый инструмент установки, масштабирования, обновлений и настройки резервирования между регионами. А для защиты виртуальных и физических серверов, корпоративных данных от масштабных сбоев, аварий и природных катастроф можно включить сервис межрегионального DR и резервного копирования — CSDR (Cloud Server Disaster Recovery), который занимается репликацией в удаленный резервный ЦОД и может комбинироваться с локальными системами высокой доступности, например VHA (Volume High Availability).

5. Высокая доступность и аварийное восстановление (Disaster Recovery)

Важнейшие части любой облачной платформы — это высокая доступность (HA, high availability) и аварийное восстановление (DR, disaster recovery). Huawei Cloud Stack поддерживает несколько уровней отказоустойчивости и DR для management plane. 

Но в документации Huawei Cloud Stack эти термины имеют немного другой смысл:

Теперь возвращаемся к HCS — он поддерживает несколько уровней отказоустойчивости и DR для management plane.

Уровень 1. Cross-AZ HA (высокая доступность между зонами доступности) для management plane

Если основной ЦОД (прод) выходит из строя, management plane продолжает работать в DR-центре для управления поддерживаемыми облачными сервисами. Получается отказоустойчивость между разными AZ (зонами доступности) и что-то вроде active-active / hot standby внутри одной площадки или региона — то есть management plane уже заранее развёрнут в двух AZ, а значит целевое время восстановления (RTO, Recovery Time Objective) небольшое.

Уровень 2. Cross-region DR (межрегиональное аварийное восстановление) для management plane

Если прод падает, можно восстановить данные management plane в DR-регион и использовать его для управления поддерживаемыми облачными сервисами. Это не совсем active-active, а DR с переключением и восстановлением. Так что нужны учения с плановыми проверками резервной площадки. Этот вариант отлично подходит и для плановых контролируемых переключений, когда нужен ремонт и(или) обслуживание основного ЦОДа, так как бизнес-процессы переезжают на DR-площадку с нулевой потерей данных (RPO, Recovery Point Objective).

Уровень 3. Geo-redundant DR (георезервное аварийное восстановление) для management plane, гибрид HA + DR

Management plane разворачивают в трёх ЦОДах (в двух городах), чтобы получить максимальную отказоустойчивость между AZ и межрегиональное DR. То есть внутри основного региона уже есть Cross-AZ HA, а поверх добавляют отдельный DR-регион. Если падает одна AZ, то работает обычный Cross-AZ HA; если обе AZ прода падают (аварии, потопы, метеориты и другие летающие объекты), то уже включается Cross-region DR — управление поддерживаемыми облачными сервисами продолжается через DR-ЦОД. Получается отказоустойчивый гибрид: локально active-active между AZ + отдельный DR-регион поверх этого.

Что выбрать?

Для большинства сценариев достаточно Cross-AZ HA в пределах одного региона. Если у вас жесткие требования к отказоустойчивости (регуляторы, непрерывность бизнеса даже при авариях на уровне регионов), то выбирайте Cross-region DR. Geo-redundant DR — это максимальный уровень защиты, который подойдёт крупному бизнесу и облачным провайдерам. Но за такую непрерывность бизнес-процессов придётся оплачивать три ЦОДа/серверных/стойки в двух разных городах и сетевую инфраструктуру между ними.

6. Интеграция физических сетевых устройств с iMaster NCE-Fabric и iMaster NCE-FabricInsight

Для мониторинга, централизованного управления и диагностики физических сетей в HCS сетевое оборудование можно подключить к двум платформам — iMaster NCE-Fabric и iMaster NCE-FabricInsight.

iMaster NCE-Fabric — это система автоматизации и управления сетью ЦОДа, которая отлично подходит большому бизнесу. По сути — единая консоль, через которую админы управляют fabric-сетью (это сеть, в которой строится распределённая фабрика из spine и leaf-коммутаторов, к leaf подключают серверы, а каждый leaf подключают ко всем spine — всё вместе работает как единая система): от настройки и развёртывания до мониторинга и оптимизации.

Платформа умеет автоматизировать сетевые сценарии для облаков, интеграции вычислительных ресурсов и сетевой инфраструктуры, а вместе с iMaster NCE-FabricInsight закрывает почти весь жизненный цикл эксплуатации. Huawei также выделяет L3 Autonomous Driving — когда часть рутинных операций, диагностики, проектирования, развёртывания, сопровождения и оптимизации система берёт на себя.

iMaster NCE-FabricInsight работает как аналитическая надстройка поверх Huawei Big Data. Она собирает телеметрию с сетевых устройств, прогоняет их через собственные алгоритмы, анализирует и в реальном времени смотрит на состояние сети и поведение приложений. То есть она ищет проблемы на инфраструктурном и сервисном уровнях: где выросли задержки, что деградирует, как это влияет на приложение. Для больших fabric-сетей в продакшене штука полезная — она ближе к концепции наблюдаемости (Observability), чем к простому мониторингу, а потому помогает быстрее находить проблемы, что архиважно для высоконагруженных облачных сред и ИИ-инфраструктур.

Различия и роли систем:

7. Сценарий периферийной инфраструктуры

В сценарии с филиалами и распределённой инфраструктурой Huawei Cloud Stack строится вокруг центрального ЦОДа и edge-площадок (периферийных). Это классический подход крупного бизнеса с распределённой структурой — например, когда есть федеральный ЦОД и edge-узлы в областях и(или) филиалах. Про это я написал отдельную «Edge Computing: зачем бизнесу вычисления на периферии и какое оборудование для этого нужно».

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

8. Edge Region (периферийный регион)

Для edge-сценариев можно сделать упрощённый регион с минимальной стоимостью внедрения. Сеть обычно строят по упрощённой L2-схеме без полноценной SDN/fabric-архитектуры. В минимальном конфиге достаточно одной пары коммутаторов, но для масштабирования и резервирования можно добавить ещё парочку.

Конечно, такое упрощение имеет свои нюансы: edge-регионы не поддерживают тяжёлую корпоративную артиллерию, вроде OBS (Object Storage Service, масштабируемое объектное хранилище для работы с петабайтами любых типов данных), BMS (Bare Metal Server, выделенный физический сервер на облачной платформе) или полноценные сценарии DR. Сервисное и управляющее хранилища объединены, а блочное хранилище строится на раздельной архитектуре ПО и аппаратной части (взаимодействие через API). Да, надёжность и функционал хуже (включая gPaaS и AI DaaS), чем в центральном регионе, но зато такой edge-регион развернуть намного быстрее и дешевле.

Подытожу

Почти все описанные выше сценарии не исключают друг друга, а наслаиваются. Компания может одновременно использовать Hosting Cloud для внутренних сервисов, федерацию с публичным облаком, edge-регионы для филиалов, Cross-AZ HA для высокой доступности и отдельные кластеры под аналитику больших данных. Всё зависит от конкретной инфраструктуры и задач бизнеса. Ну а поскольку Huawei Cloud Stack — это полноценная корпоративная облачная платформа с централизованным управлением вычислениями, сетью, контейнерами, хранилищем, DR, периферийными вычислениями и мультиоблачными сценариями, то функционал ограничен лишь бюджетом и фантазией IT-архитектора. 

Как лицензируется Huawei Cloud Stack

После истории с VMware вопрос лицензирования стал чуть больше интересовать бизнес. Лицензии на облачные платформы могут определять совокупную стоимость владения (TCO, total cost of ownership) всей IT-инфраструктурой. На момент выхода статьи Huawei Cloud Stack не лицензируется по одним лишь подпискам и пакетам (как VMware). Цены на Huawei Cloud Stack в открытом доступе не публикуются, так что точные цифры можно получить только через отдел продаж Huawei или локальных партнеров — всё по запросу. 

HCS — это огромный набор сервисов и компонентов (вроде FusionSphere и ManageOne), у которых разные модели лицензирования. Разумеется, погружаться в это нужно, только если вы действительно захотите работать с гибридным облаком Huawei, поэтому я затрону только самое важное для общего понимания. 

Итак, во главе всего стоит License Management — это единая система управления всеми лицензиями, которая ограничивает платформу HCS тем функционалом, что вы купили. Через неё идёт вся работа по лицензиям, будь то проверка состояния, поиск проблем, отзыв старых/ненужных лицензий и замена их на новые. Удобная штука для админов, которая позволит избежать неприятных ситуаций, когда забыли продлить лицензию — и сервисы прода встают.

Huawei выделяет два типа лицензий: 

• Лицензии на программный продукт (product license) 

• Лицензии на облачный сервис (cloud service license) 

ManageOne может импортировать оба, но другие продукты и облачные сервисы в том же регионе поддерживают лишь один тип.

Начнём с лицензии на лицензии на программный продукт (product license)

Чтобы начать работу с License Management, сначала нужно импортировать действующий файл лицензии (License File) — иначе не запустится. Этот файл хранит информацию о том, какие функции, в каком объёме и в течение какого срока заказчик может использовать. Там же прописывается льготный период (после развертывания системы по умолчанию вы получаете пробный период на 60 дней), параметры ограничения ресурсов/функций и данные о продаже. 

Файлы лицензий бывают трёх типов:

• Срочная лицензия — это конечные подписки, например, на 1, 2 или 3 года;

• Бессрочная коммерческая лицензия — её можно купить до конца времён, но вот поддержка и обновления в сделку не входят, а потому мажорные обновления — это покупка новых файлов;

• Комбинированная лицензия (бессрочная + срочная).

Покупают все три варианта, но вот что парадоксально — из-за разумной ценовой политики Huawei (а иногда и персональных условий для разных рынков и заказчиков) довольно часто покупают именно подписки или комбо, а не вечные лицензии (да, Broadcom, оказывается, так можно было). Ибо капитальные вложения меньше, а при длительном сотрудничестве цены сопоставимы или даже ниже.

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

Также лицензию можно отозвать (правда не все сервисы поддерживают это), тогда система сгенерит специальный код — revocation code, который позволит идентифицировать отозванную лицензию и использовать её при запросе новой, что полезно, когда лицензия заканчивается или уже истекла, не хватает ёмкости (хранилищ) или нужно заменить лицензию на другую.

При мажорном обновлении, то есть при переходе на новую версию внутри R-ветки (Release / Major release branch)…

… нужно получать новый файл лицензии через апгрейд в системе ESDP. С минорными обновлениями внутри одной C-ветки (Customer / Continuous minor branch) это делать не нужно — там файл сохраняет актуальность и продолжает работать без изменений.

Переходим к лицензии на облачный сервис (cloud service license)

Облачный сервис в контексте HCS — это по сути ПО как услуга или SaaS (от англ. Software as a Service — программное обеспечение как услуга). То есть вы покупаете не ПО, а право пользоваться сервисом на нужный вам срок. 

Здесь тоже нужна лицензия на облачный сервис (Cloud Service License). И тоже есть отдельный электронный файл лицензии облачного сервиса (Cloud Service License File) с CSSN (Cloud Service Serial Number) — по сути это аналог ESN, но уже для облачной среды.

Ещё интересное про лицензирование Huawei Cloud Stack

Сама архитектура HCS (напомню, это по сути конструктор корпоративного облака) позволяет развернуть и лицензировать отдельные компоненты IT-инфраструктуры:

• Только IaaS (вычислительные ресурсы, СХД, сети);

• IaaS + PaaS контейнеры (K8s для микросервисной разработки);

• Дополнительные сервисы (Big Data, AI, IoT, базы данных);

• Edge-регионы;

• DR-контур;

• Федерацию облаков;

• Или полноценную облачную платформу со всем зоопарком сервисов.

Поэтому удобно мигрировать поэтапно: начали с IaaS на 50 серверов, а через год докупили лицензии на Kubernetes и парочку дополнительных сервисов.

В архитектуре HCS поддерживается BYOL (Bring Your Own License) для части сценариев и сервисов. То есть вы можете перенести и использовать купленные лицензии (например, базы данных, операционные системы, СУБД, и сторонний софт) на выделенные физические серверы или виртуальные инстансы в контуре облака. 

И что самое важное, Huawei пока не устраивала и вряд ли устроит рынку резкий разворот модели лицензирования, так как никто не купит Huawei (как Broadcom купил VMware) — денег не хватит, да и Компартия не продаст телеком-вендора с госдолей. Для крупного бизнеса, государств и инфраструктур с горизонтом планирования на 5–7 лет — это серьёзный аргумент.

Всё же стоимость миграции измеряется не только деньгами, но и рисками.

И поэтому вы должны знать, что Huawei как бы одновременно и ушла, и осталась в России. Компания не объявляла о полном уходе с нашего рынка, как это сделали западные вендоры, но официальный Enterprise-бизнес свернула из-за риска вторичных санкций. При этом сохранилась поддержка некоторых клиентов, поставки серверов и СХД стабильно идут через партнёрские и дистрибьюторские схемы, а уже развёрнутые инфраструктуры HCS работают. И да, Huawei не проводит жестких аудитов в РФ.

Это не означает, что платформу нельзя купить и использовать, просто теперь это работает не так прозрачно. Например, HCS обновляют каждые 6-9 месяцев, а клиенты из России получают обновления через закрытые каналы. За годы бизнес уже привык к серому импорту. 

Промежуточные выводы перед переходом ко второй части

Немного теории по Huawei Cloud Stack разобрали — буквально у подножья Эвереста потоптались, но для общего понимания этого достаточно. 

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

Во второй части уже подробнее расскажу, как перенести рабочие нагрузки в облако Huawei Cloud Stack.