Опыт тестирования PostgreSQL 13 на ARM-серверах HUAWEI TaiShan 200 / Хабр

ddceccf Каталог

Что нового для сетей цод

Для воплощения новой концепции 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.Опыт тестирования PostgreSQL 13 на ARM-серверах HUAWEI TaiShan 200 / Хабр

В качестве иллюстрации рассмотрим сеть в ЦОДе банка. Легко представить, как его бизнес-запросы ложатся на сетевые технологии. Для начала его 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 применялась исключительно для транспортных задач, фактически на уровне оптики. Её кросс-продуктовое использование возможно, например для управления маршрутизаторами операторского класса и устройствами оптического уплотнения каналов, однако подобные кейсы представляют собой редкие исключения.Опыт тестирования PostgreSQL 13 на ARM-серверах HUAWEI TaiShan 200 / Хабр

Напротив, архитектура 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

. Самая главная вкладка. Здесь консолидируются все политики управления трафиком:

  1. Security Policy – большой список доступа.
  2. NAT Policy — все необходимые варианты трансляции IP-адресов: динамический NAT, публикация серверов, NAT-исключения и т.д.
    Нюанс. Нет возможности настроить Destination NAT. А это бывает иногда полезно. Например, когда по какой-то причине на сервисе намертво «зашит» адрес внешнего ресурса, а этот самый внешний ресурс переезжает на другой IP-адрес. Сталкивались, такое бывает. Ну это мелочи…
  3. Bandwidth Management и Quota Control. Круто, что есть. Весьма востребовано.
  4. Proxy Policy. Можно включить некэширующее проксирование. Устройство умеет проксировать пользовательские запросы, то есть, Huawei становится в разрыв TCP-сессии между клиентом и сервером:

    Опыт тестирования PostgreSQL 13 на ARM-серверах HUAWEI TaiShan 200 / Хабр

    Есть два варианта проксирования: TCP Proxy и SSL Decrypt. Последний вариант – для дешифрации SSL-трафика. Дешифрация работает стандартно, с подменой сертификата. Протестировать не получилось: для SSL Decrypt требуется дополнительная нетриальная лицензия. Причём, политики настроить можно, просто они не работают.

  5. Authentication Policy. Ооо, это одна из моих любимых тем – аутентификация пользователей, интеграция с AD и всё такое. В настройках политик всё просто: выбираем шаблон трафика и говорим, нужно аутентифицировать или нет.
    Как именно аутентифицировать пользователей настраивается в другой вкладке – Objects – в настройках аутентификационного домена. Но раз в другой вкладке, то и вернёмся к этому вопросу чуть позже.
  6. Остаются Security Protection и ASPF. Подробно останавливаться не буду. Если кратко, в Security Protection включаются различные защиты от DDoS-атак, флудинга, IP Sweep, Port Scanning, дефрагментация, чёрные списки и прочее-прочее-прочее.

    ASPF (application specific packet filter) – это инспекция пакетов на открытие доп сессий через файрвол. Для FTP, SIP, H323 и т.д.

Вкладка Objects

. Здесь настраивается всё, что впоследствии применяется в политиках (на вкладке Policy). В частности, всё, что относится к Content Security. Например:

  1. Настройки антивируса
  2. Настройки IPS
  3. Профиль URL-фильтрации
  4. Защита электронной почты
  5. И т. д.

Вкладка Network

. Тут настраиваем наши интерфейсы, маршрутизацию и VPN.

Подробно здесь останавливаться не буду, упомяну только некоторые моменты:

  1. Интерфейсы. По умолчанию все интерфейсы маршрутизируют. Но любой интерфейс можно сделать коммутируемым, настроить как access или как trunk. Можно добавить interface vlan, subinterface, агрегировать порты. В общем, в плане интерфейсов всё очень и очень гибко. Это плюс.
  2. Маршрутизация. Есть PBR, есть варианты балансировки по WAN портам. К статическим маршрутам можно добавлять трекинг. Из динамических протоколов присутствуют RIP, OSPF и BGP.
  3. 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. Это номера портов. Всё стандартно.

Более интересные опции.

Оцените статью
Huawei Devices
Добавить комментарий