Что нового для сетей цод
Для воплощения новой концепции Huawei в сетях ЦОД используется несколько подходов.
В 2022 году компания Broadcom, и в частности входящая в неё Brocade, по геополитическим причинам отказались от партнёрства с Huawei, как китайским производителем. Вскоре наше подразделение, которое занимается системами хранения данных, сделало упор на использование систем, связанных с удалённым прямым доступом к памяти другого устройства (RoCEv2), и не зря.
В испытаниях мы зафиксировали прирост производительности по сравнению со стандартным Fibre Channel. Так, Dorado и программно-определяемая FusionStorage 8 показывают в RoCEv2-сценариях по меньшей мере 20%-й выигрыш в производительности за счёт использования алгоритмов машинного обучения (применяется шесть лицензированных алгоритмов, работающих на уровне карт ускорения machine learning непосредственно на коммутаторах).
Фактически линейка Huawei DCN вместе с нашими новыми СХД даёт возможность получить решение «три в одном» и, согласно самым скромным подсчётам, открывает новый рынок сетей хранения данных величиной около $5 млрд.
Использование нового, комплексного подхода в случае с Huawei SDN позволяет работать с приложениями более гранулярно. В этой связи повышенное значение приобретают гибкая настройка контейнеров и настройка связности с ними. Сама по себе модель управления стала гораздо нагляднее и проще — не в последнюю очередь благодаря использованию принципов Drag-n-Drop и WYSIWYG.
Наш метод автоматизации сети претворяется на практике с помощью целого набора инновационных решений. Среди них — симуляция события. Упрощённо рассуждая, перед тем как что-либо настроить, мы имитируем действие выбранных опций, в том числе с точки зрения сетевой составляющей.
Например, если изменения грозят застопорить какие-то потоки трафика, система предупредит инженера о соответствующем риске до принятия этих изменений. Такого типа обратная связь, реализованная по проактивной, а не по реактивной модели, серьёзно упрощает эксплуатацию ЦОДа.
Другая отличительная особенность нового подхода Huawei к построению сетей в ЦОДах — применение ранее упомянутой интеллектуальной платформы O&M 1-3-5. Делается это прежде всего с целью получить стопроцентную визуализацию сети. Администратор видит, без преувеличения, всё сколько-нибудь значимое, что творится в ЦОДе или кампусной сети.
Соответственно, необходимо понимать, как происходящее соотносится с работой приложений. В стандартных сценариях, когда задействуются визуализаторы других производителей, в конечном счёте либо остается удовлетвориться сбором информации по NetFlow, что не ведёт к точности картины в сети ЦОДа, либо приходится ставить дорогие съёмники трафика в критических точках.
Ни тот, ни другой выход нельзя признать приемлемым в 2020 году. В случае же с O&M 1-3-5 коммутаторы и беспроводные устройства, такие как точки доступа, могут снимать ERSPAN всего проходящего через них трафика до уровня Layer-4 и отдавать эту информацию, в связи с чем панорама сетевой активности приобретает высочайшую степень детализации.
— В случае с single node deployment возможен ли кластер A-P / A-A?
— Single node deployment скорее имеет смысл, когда задача — собрать демолабораторию, получить proof-of-concept. Как только у нас возникает задача посложнее, мы используем ClusterWare на основе GaussDB — нашей массивно-параллельной базы данных с плавающими адресами — и тогда получаем сценарий active-active. В серьёзных внедрениях это требует трёх-четырёх серверов.
Архитектура решения и ключевые моменты в коде
Мы выделили отдельный модуль platform-services:common, где мы описали абстракции над платформенными сервисами. И эти абстракции не зависят ни от GMS, ни от HMS напрямую.
В отдельном модуле platform-services: integration мы описали логику, как должны сопоставляться интерфейсы из common-модуля с их конкретными платформенными реализациями. Сами реализации под каждую платформу мы поместили тоже в отдельные модули. Получились два платформозависимых модуля GMS и HMS.
Еще есть модуль fallback с заглушечными реализациями сервисов. Он нужен на тот случай, когда на девайсе пользователя вообще, например, нет никаких мобильных сервисов. Или когда у пользователя HMS-девайс, и он в приложении встречает фичу, которая пока что доступна только для GMS-девайсов.
Рассмотрим, как это работает на примере пушей. Вот так выглядит платформонезависимый интерфейс для получения PushToken, который описан в нашем platform-services:common модуле.
interface PushTokenSource {
fun getPushTokenSingle(): Single<String>
}
Его платформенная реализация через Huawei Mobile Services.
@InjectConstructor
class HuaweiPushTokenSource(
private val context: Context,
private val schedulersProvider: SchedulersProvider,
) : PushTokenSource {
companion object {
private const val TOKEN_SCOPE = "HCM"
}
override fun getPushTokenSingle(): Single<String> {
return Single.fromCallable {
val options = AGConnectInstance.getInstance().options.getString("client/app_id")
val instanceId = HmsInstanceId.getInstance(context)
val token = instanceId.getToken(appId, TOKEN_SCOPE)
if (token.isNullOrEmpty()) throw PushTokenException("Push token is null")
token
}.subscribeOn(schedulersProvider.backgroundScheduler)
}
}
В integration-модуле живет код, который определяет доступные пользователю сервисы.
@InjectConstructor
class HuaweiPlatformServicesDetector(
private val context: Context,
) : PlatformServicesDetector {
override fun isAvailable(): Boolean {
val huaweiApiAvailability = HuaweiApiAvailability.getInstance()
val result = huaweiApiAvailability.isHuaweiMobileServicesAvailable(context)
return result == ConnectionResult.SUCCESS
}
}
Для каждой фичи есть отдельный провайдер, который имеет доступ к информации об имеющихся на девайсе сервисах, и мы можем прописать здесь любые условия для получения той или иной реализации сервисов.
@InjectConstructor
class PushTokenSourceProvider(
private val firebasePushTokenSource: FirebasePushTokenSource,
private val huaweiPushTokenSource: HuaweiPushTokenSource,
private val fallbackPushTokenSource: FallbackPushTokenSource,
private val platformServices: PlatformServices,
) : Provider<PushTokenSource> {
override fun get(): PushTokenSource {
return when (platformServices.getPreferredPlatformServices()) {
Type.GOOGLE -> firebasePushTokenSource
Type.HUAWEI -> huaweiPushTokenSource
null -> fallbackPushTokenSource
}
}
}
Ну и по месту использования мы просто инжектим общий платформонезависимый интерфейс из модуля common.
@InjectConstructor
internal class PushTokenManagerImpl(
private val pushTokenSource: PushTokenSource,
/*...*/
) : PushTokenManager {
/*...*/
private fun getTokenSingle(): Single<String> {
return pushTokenSource.getPushTokenSingle()
.doOnError {
clearPushState()
Timber.tag(LOG_TAG).e(it.asNonFatal())
}
.doOnSuccess { token ->
saveToken(token)
Timber.tag(LOG_TAG).d("Push token is $token")
}
}
}
Если мы по какой-то причине в будущем решим отказаться от единой для всех платформ сборки, то мы не будем рефакторить большую часть приложения, а лишь изменим детали реализации integration-модуля, который сопоставляет интерфейс с их реализациями и переделаем связывание в нем из runtime в compile time.
Еще надо отметить, что если у Huawei какие-то сервисы будут работать лучше, или они будут дешевле. Или будет такая ситуация, когда у Huawei эта реализация есть, а у Google ее еще нет (или вообще нет), то можем использовать для Huawei пользователей именно Huawei-реализацию.
Какие продукты и решения huawei предлагает в 2020 году
Касательно места Huawei в технологическом мире чем дальше, тем в меньшей степени нашу компанию справедливо называть сетевым вендором, вендором серверов или какого-либо другого отдельного типа продуктов. Сегодня объективно правильнее будет говорить о том, что мы предлагаем, в терминах синергии: одно решение в совокупности с другим производит кумулятивный эффект, и получившееся оказывается больше (и ценнее!) суммы своих составных элементов.
Бесспорно, известность Huawei получила как производитель телеком-оборудования. Однако до сих пор даже не все наши коллеги по рынку осведомлены о наших решениях в сфере искусственного интеллекта и машинного обучения. Ещё меньше людей в курсе того, что эти разработки составляют неотъемлемую часть едва ли не всех наших актуальных продуктов.
В какую же сторону мы смотрим?
Крайне высокий приоритет в общетехнологической стратегии Huawei — у IP-сетей.
Притом немалая часть нашей деятельности напрямую связана с открытыми наработками, в первую очередь применительно к SRv6 и Wi-Fi 6. Это неудивительно, если принять во внимание тот факт, что около 45% наших сотрудников так или иначе относится к R&D.
Стандартные — иногда хочется сказать «допотопные» — сети, управление которыми осуществлялось через командную строку, претерпели разительные изменения. В ходе эволюции выделились сети ЦОД (DCN), Intent-Driven Networks (IDN), а также Autonomous Driving Networks (ADN).
По большому счёту, основной отличительный признак SDN — автоматизация, и наиболее зрелая автоматизация на сегодняшний день имеет место именно в сетях ЦОД. В свою очередь, главное, что добавило прагматическое применение концепции Intent-Driven, если оставить за скобками нюансы, — это понимание того, что происходит в сети.
В случае с сетью старого образца инженеру не всегда было по силам сориентироваться в потоках трафика. Потребность же создать карту сервисов могла вызвать не то что приступ паники — лёгкое помешательство: доступные на тот момент инструменты, включая съём по NetFlow, общей картины происходящего в сети не давали.
Среди опорных трендов ближнего прицела, которым Huawei привержена в своей стратегии, — распространение идеологии Autonomous Driving Network (ADN). Под это определение подпадают подвижные сети разного толка с автономным управлением.
Следует сделать оговорку: вне зависимости от того, каков прорывной потенциал решения, важно отдавать себе отчёт в том, насколько оно зрелое. Как показало наше исследование, среди наиболее популярных направлений, в которых работает Huawei и другие производители, самый зрелый домен — сети ЦОД (DCN).
На втором месте — оптические сети, на третьем — операторы связи. Таким образом, в случае с ЦОДами мы располагаем максимально глубоко проработанными решениями, как с точки зрения их ввода в эксплуатацию, так и с точки зрения их дальнейшего использования.
Для того чтобы воплощать в жизнь автономные управляемые сети так, как мы видим, был сформирован зонтичный бренд iMaster NCE. Он интегрирует в себя:
Это целостный комплекс, части которого состыкованы не формально и «чтобы было», а бесшовно. И действительно, максимально зрелым он проявляет себя в ЦОДах, с их тщательно проработанными процессами.
В случае с DCN мы развиваем свой подход к системе управления и эксплуатации сети, который кратко обозначили как O&M 1-3-5. Здесь 1 — это время, за которое мы должны получить сообщение об ошибке в сети, а именно одна минута. Соответственно, три минуты допустимо потратить на обработку ошибки, а пять минут — на её устранение. Разумеется, перечисленные цифры лишь ориентир, точнее, средние показатели по протоколам машинного обучения, которые вшиты в систему и доказали свою эффективность: во львиной доле систем возможно ограниченное количество сценариев неполадок, и на самые распространённые из них приходится приблизительно 90% всего, что в принципе может приключиться с сетью. Ранее 1-3-5 называлось FabricInsight, теперь же входит в состав iMaster NCE.
В качестве иллюстрации рассмотрим сеть в ЦОДе банка. Легко представить, как его бизнес-запросы ложатся на сетевые технологии. Для начала его core service — тот же онлайн-банкинг — должен работать на высоких скоростях и без потерь. В случае с системой iMaster требуемое достигается, в частности, за счёт того, что она формирует требования, полученные от вышестоящих систем, и транслирует их в нижестоящие (так происходит с сетевыми рекомендациями и пр.).
В дело вступает тот или иной набор шаблонов, которые выбираются и устанавливаются на подлежащую сеть. Допустим, набор правил AI Fabric, рассчитанной на использование c конвергентными сетями RoCE второй версии, с возможностью прямого доступа к памяти на уровне Fibre Channel / InfiniBand на Ethernet-сети.
Важно и держать под контролем то, что было внедрено. Речь идёт в том числе о правилах информационной безопасности и симуляции отказов. Подобные решения получат распространение как раз в 2020 году, и отдельные их внедрения уже произведены.
До iMaster NCE сетевая архитектура в ЦОДах на базе решений Huawei выглядела примерно следующим образом. Существовала отдельная система управления сетевыми элементами eSight, для управления устройствами транспорта задействовалась U2000, вместе с ними использовались Agile Controller в качестве SDN-контроллера и FabricInsight в качестве сетевого анализатора.
Все перечисленные составляющие практически не взаимодействовали между собой и не создавали добавленной ценности при эксплуатации. Соответственно, такая инфраструктура предполагала наличие трёх консолей управления, и решения в сети принимались на основе различных данных.
Будучи EMS, eSight не включает в себя U2000. Последнюю было решено инкорпорировать в новый продукт NCE Transport. В настоящее время Huawei производит замену у своих заказчиков, чтобы во всех новых проектах использовалась не U2000, а NCE-T. Ранее чаще всего U2000 применялась исключительно для транспортных задач, фактически на уровне оптики. Её кросс-продуктовое использование возможно, например для управления маршрутизаторами операторского класса и устройствами оптического уплотнения каналов, однако подобные кейсы представляют собой редкие исключения.
Напротив, архитектура iMaster NCE является конвергентной. При её создании компания задалась целью тесно интегрировать ранее слабо взаимодействовавшие друг с другом продукты, чтобы развёртывать сеть, приближенную к состоянию автопилота. Нам, без лишней похвальбы, это удалось.
Высокая степень самостоятельности сетевой инфраструктуры достигается совокупностью решений. Помимо всего прочего, анализатор «натаскивается» с помощью накопленных данных. В него зашита часть алгоритмов обучения. Например, в системе используются библиотеки PyTorch и MLib для того чтобы предсказывать, когда произойдёт деградация интерфейса, при каких условиях оптический приёмо-передатчик выйдет из строя и т. д.
В стандартных сценариях не редки ситуации, когда пресейл битых две недели корпит над high-level design, после чего осуществляется low-level design. Отныне всё проще благодаря тому, что в систему добавлена дизайн-студия. Ничто не мешает спроектировать дизайн в ней, и после того, как устройства будут присоединены к системе, они получат данные HLD и будут настроены в соответствии с намерениями инженера. Применительно к сетям ЦОД подобная функциональность, насколько нам известно, пока больше нигде не реализована.
Новой модели сопутствует новый подход к развёртыванию сети и управления ею — iMaster 2-3-4. Сам по себе iMaster представляет собой модульное программное обеспечение, и заказчик волен выбирать, каких модулей ему будет достаточно. Минимальный набор — это SDN-контроллер и система управления устройствами (в старых терминах — eSight).
Дальше возможны дополнения: анализатор, средства планирования и т. д., — в зависимости от целей клиента. Когда ожидается, что сеть будет статичной, почти наверняка нет никакой надобности задействовать модули planning и construction на постоянной основе.
В случае если у нас постоянно меняется сетевая инфраструктура — скажем, используется cloud computing, вычисления, связанные с большими данными и пр., — определённо потребуется анализатор. Известно, что система будет постоянно модифицироваться и расти? Значит, понадобится регулярно осуществлять её оптимизацию, и тогда нужен максимальный набор.
Обзор графического интерфейса и возможностей устройства
Шутки в сторону, ближе к делу. Сразу отмечу: Web-интерфейс логичный и интуитивно понятный. Работает всё очень быстро, особенно, если сравнивать с тяжеловесным Cisco FMC.
Вверху расположены шесть вкладок: Dashboard, Monitor, Policy, Object, Network, System:
Вкладка Dashboard. Тут всё понятно. Некоторая инфографика, информация об устройстве, лицензиях, Syslog-сообщения и т.д.
Вкладка Monitor
. Здесь можно посмотреть информацию о текущих соединениях, некоторую статистику.
Тут же представлены некоторые инструменты диагностики. Приятно, что есть
Вкладка Policy
. Самая главная вкладка. Здесь консолидируются все политики управления трафиком:
- Security Policy – большой список доступа.
- NAT Policy — все необходимые варианты трансляции IP-адресов: динамический NAT, публикация серверов, NAT-исключения и т.д.
Нюанс. Нет возможности настроить Destination NAT. А это бывает иногда полезно. Например, когда по какой-то причине на сервисе намертво «зашит» адрес внешнего ресурса, а этот самый внешний ресурс переезжает на другой IP-адрес. Сталкивались, такое бывает. Ну это мелочи… - Bandwidth Management и Quota Control. Круто, что есть. Весьма востребовано.
- Proxy Policy. Можно включить некэширующее проксирование. Устройство умеет проксировать пользовательские запросы, то есть, Huawei становится в разрыв TCP-сессии между клиентом и сервером:
Есть два варианта проксирования: TCP Proxy и SSL Decrypt. Последний вариант – для дешифрации SSL-трафика. Дешифрация работает стандартно, с подменой сертификата. Протестировать не получилось: для SSL Decrypt требуется дополнительная нетриальная лицензия. Причём, политики настроить можно, просто они не работают.
- Authentication Policy. Ооо, это одна из моих любимых тем – аутентификация пользователей, интеграция с AD и всё такое. В настройках политик всё просто: выбираем шаблон трафика и говорим, нужно аутентифицировать или нет.
Как именно аутентифицировать пользователей настраивается в другой вкладке – Objects – в настройках аутентификационного домена. Но раз в другой вкладке, то и вернёмся к этому вопросу чуть позже. - Остаются Security Protection и ASPF. Подробно останавливаться не буду. Если кратко, в Security Protection включаются различные защиты от DDoS-атак, флудинга, IP Sweep, Port Scanning, дефрагментация, чёрные списки и прочее-прочее-прочее.
ASPF (application specific packet filter) – это инспекция пакетов на открытие доп сессий через файрвол. Для FTP, SIP, H323 и т.д.
Вкладка Objects
. Здесь настраивается всё, что впоследствии применяется в политиках (на вкладке Policy). В частности, всё, что относится к Content Security. Например:
- Настройки антивируса
- Настройки IPS
- Профиль URL-фильтрации
- Защита электронной почты
- И т. д.
Вкладка Network
. Тут настраиваем наши интерфейсы, маршрутизацию и VPN.
Подробно здесь останавливаться не буду, упомяну только некоторые моменты:
- Интерфейсы. По умолчанию все интерфейсы маршрутизируют. Но любой интерфейс можно сделать коммутируемым, настроить как access или как trunk. Можно добавить interface vlan, subinterface, агрегировать порты. В общем, в плане интерфейсов всё очень и очень гибко. Это плюс.
- Маршрутизация. Есть PBR, есть варианты балансировки по WAN портам. К статическим маршрутам можно добавлять трекинг. Из динамических протоколов присутствуют RIP, OSPF и BGP.
- VPN. Есть L2TP, GRE, DSVPN. Последнее – это аналог DMVPN у циски. Стоп. Но где же IPsec? Где же SSL VPN? Я точно помню, что в бюллетене видел данные по IPsec и SSL VPN. Ок, изучаем руководство пользователя. Находим вот такую фразу:
The IPSec VPN and SSL VPN functions are not provided in versions shipped to Russia in accordance with Russian laws.
Ну и дела. Неужели нет вариантов пользоваться этими сервисами в России? — Конечно же есть. Как выяснилось, нам досталась железка с софтов PWE (payload without encryption). То есть, как NPE (no payload encryption) у циски. Чтобы не получать разрешение от ФСБ, ввозятся именно такие устройства. Чтобы запустить шифрование, просто скачивается и устанавливается полноценный софт. Кстати, без проблем можно ввести железку с шифрованием официально — с получением разрешения ФСБ на ввоз. В этом случае просто увеличится время поставки.
Вкладка System
. Тут ничего интересного – стандартные системные настройки: время, SNMP, учётки администраторов, логирование, лицензии, апдейты, апгреды и т.д. В общем, описательная часть ограничится скриншотом.
Вернёмся к Security Policy
и посмотрим их подробнее. Это то место, в котором объединяются все функции устройства. Нажмём Add и посмотрим, что можно настроить в плане фильтрации трафика.
Первые опции – классический файрвол: зоны и IP-адреса. Чуть ниже – Services. Это номера портов. Всё стандартно.
Более интересные опции.