01

TCS — это инфраструктура в эпоху облачных технологий

TCS (Tencent Cloud-native Suite) — это собственная облачная версия PaaS-платформы Tencent, которая предоставляет облачную платформу и продукты PaaS собственной разработки Tencent (такие как Credis, TDSQL, TSF) и т. д. В то же время TCS также является общей базой для публичного облака Tencent, собственного облака TCE Tencent и продуктов SaaS Tencent, обеспечивая единую базу для вывода и доставки облачных продуктов Tencent в различных сценариях.

Собственная облачная инфраструктура TCS — это уровень инфраструктуры и контейнерной платформы в решении TCS/TCE. Она обеспечивает собственные облачные вычисления, хранилище, сеть и другие возможности для приватизированного вывода различных облачных продуктов Tencent, скрывая различия в базовой IaaS. За последние два года TCS претерпела несколько итераций версий, поддерживала быстрое технологическое развитие и эволюцию, а также обеспечивала техническую поддержку для победы в тендерах и успешной реализации многих проектов по приватизации продуктов Tencent.

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

02

Обзор технической карты

● Собственная облачная инфраструктура TCS2.0.

● Собственная облачная инфраструктура TCS2.3.0.

03

Технический краткий обзор

3.1 Контейнерная сеть TCS-CNI

● Истории пользователей и технологий.

В версии TCS2.0 (TCE3.8.0) TCS предоставляет только возможности контейнерной сети фланели (IPIP Overlay). В условиях растущей конкуренции в области облачных контейнеров решение фланелевой контейнерной сети не может обеспечить сильную конкурентоспособность контейнерной платформы TCS.

Когда был запущен проект версии TCS2.1.0, мы ожидали, что технологическое решение для контейнерной сети будет постоянно развиваться. Мы заметили, что все более популярная технология eBPF и cilium, успешный технологический проект eBPF в контейнерной сети, отвечают нашим потребностям. В версии TCS2.1.0 мы глубоко преобразовали и оптимизировали cilium на основе сообщества, предоставив два сетевых режима: IPIP и BGP и интегрировав их в TCS, чтобы они стали решением контейнерной сети по умолчанию для высокоядерных (4.14+). В то же время мы разработали собственный модуль IPAM, обеспечивающий такие функции, как автоматическое расширение CIDR, обслуживание IP и назначение IP-адресов для контейнерной сети TCS.

С выпуском cilium в TCS2.1.0 мы получили больше требований от клиентов в отношении контейнерных сетей, таких как более богатые решения для контейнерных сетей, однокластерные многоконтейнерные сетевые решения, один модуль с несколькими сетевыми картами, требования RDMA и многоадресная рассылка. требования. подождите. Мы продолжим развивать решение контейнерной сети, формируя единую структуру расширения контейнерной сети на основе multus, интегрируя готовые плагины контейнерной сети, такие как cilium, IPIP, VLAN, BGP, RMDA, sriov, хост. -gw и т. д., а также работа с унифицированными инструкциями по управлению IPAM и планированию сети образуют окончательное решение контейнерной сети TCS-CNI.

TCS-CNI обеспечивает многофункциональную, высокопроизводительную, масштабируемую, стабильную и надежную контейнерную сеть для контейнерной платформы TCS и продуктов PaaS/SaaS. Она также поддерживает требования к контейнерной сети продуктов верхнего уровня TCS, таких как KubeVM и TCS-Edge. . В третьей версии TCS 2.3.0 TCS-CNI поддерживает самостоятельное планирование различных типов сетей, ожидаемых клиентами, на странице продукта. Вы можете использовать страницу продукта для самообслуживания мощных функций контейнерной сети, предоставляемых TCS.

Схема архитектуры TCS-CNI:

● Проекты и технические достижения

В рамках проекта миграции общедоступного облака Tencent на базовый проект TCS TCS-CNI предоставляет контейнерную сеть VLAN и функции сквозного VIP-контейнера TGW (Tencent Gateway) для приложений управления и контроля продуктов IaaS общедоступного облака Tencent, обеспечивая высокопроизводительную контейнерную сеть и низкую стоимость. канал передачи данных балансировки нагрузки при потерях.

Среди многих проектов, требующих контейнерных сетей Underlay, TCS-CNI реализует решения для контейнерных сетей, такие как Overlay, BGP, VLAN, RDMA и т. д., для каждого клиента по требованию, или свободно комбинирует смешанные решения для контейнерных сетей, чтобы предоставить клиентам независимые от IaaS решения. высокопроизводительная сеть контейнеров.

В приватизированном проекте вывода CVM (облачная виртуальная машина, служба эластичных вычислений Tencent) крупного коммерческого банка модуль IPAM TCS-CNI обеспечивает унифицированное управление IP-адресами и возможности распределения для контейнеров и экземпляров CVM.

● Перспективы на будущее

TCS-CNI в настоящее время имеет слабую поддержку IPv6, и мы добавим возможности IPv6 в последующих версиях. Что касается технологического прогресса, мы продолжим инвестировать в область eBPF, оптимизировать связи в плоскости данных контейнеров TCS и использовать возможности eBPF для расширения продуктов с добавленной стоимостью сети TCS в областях наблюдения и безопасности (NetworkPolicy ).

3.2 Балансировка нагрузки L4 TCS-LB

● Истории пользователей и технологий.

В версии TCS2.0 (TCE3.8.0) сам TCS не имеет модуля балансировки нагрузки, а предоставляет лишь решение для подключения к TGW по сценарию TCE (tgw-cloud-provider), то есть автоматическое подключение к API плоскости управления TGW на основе правил пересылки K8s, плоскость данных предоставляется TGW.

Поскольку многие облачные продукты SaaS/PaaS используют TCS2.1.0 в качестве основы для вывода отдельно или в сочетании, бизнес-сторона облачных продуктов выдвинула для нас потребность в облачной балансировке нагрузки L4. Поскольку TGW имеет множество зависимостей и занимает большой объем ресурсов, а самому TCS необходимо достичь конечной цели миниатюризации ресурсов 8C16Gi, мы должны изучить «маленькое» облачное решение для балансировки нагрузки L4. Когда был создан проект версии TCS2.1.0, мы выбрали Keepalived/LVS для реализации функции плоскости данных и самостоятельно разработали набор компонентов плоскости управления на основе API K8s, в конечном итоге сформировав решение Keepalived-manager.

Благодаря успешной реализации Keepalived-manager в версии TCS2.1.0 и достижению хороших результатов в интеграции TCS в некоторые проекты TCS и с облачными продуктами, бизнес-сторона облачных продуктов выдвинула более высокие требования к нашей балансировке нагрузки L4. Самое сложное новое требование, с которым в то время столкнулся Keepalived-Manager, заключалось в том, как использовать «маленькие» ресурсы для поддержки «больших» проблем VIP с высокой доступностью в нескольких зонах доступности и как преодолеть ограничения производительности одной машины для достижения высокой доступности. производительность в режиме работы с одним главным устройством Keepalived-Manager.

После нашего анализа и оценки Keepalived-manager, возможно, больше не сможет поддерживать нас в движении вперед. Мы обратили внимание на технологическое решение eBPF, аналогичное TCS-CNI — XDP. После нашего исследования и изучения проектов или статей с открытым исходным кодом, таких как Google Maglev, Facebook Katran и Cilium, мы решили разработать облачный модуль балансировки нагрузки на основе XDP — TCS-LoadBalancer (TCS-LB, директор внутреннего кодового имени проекта). . TCS-LB хорош для обслуживания облачных решений: его можно портировать на любой дистрибутив Linux и оборудование без адаптации, а также он обеспечивает простые, контролируемые и наблюдаемые возможности эксплуатации и обслуживания на основе K8s. TCS-LB предоставляет самому TCS, а также продуктам SaaS и PaaS возможности балансировки нагрузки, которые могут быть «большими» или «маленькими»: «маленький» отражается в том факте, что он может быть размещен на 8C16Gi TCS Master. обеспечить высокопроизводительные возможности пересылки данных и «большие» возможности. Это отражается в том, что он может обеспечить возможности высокой доступности для аварийного восстановления AZ (доступной зоны) и высокопроизводительные возможности для горизонтального расширения.

TCS-LB завершил предварительные возможности версии TCS2.2.1 и завершил официальный выпуск версии TCS2.3.0, став модулем балансировки нагрузки по умолчанию в TCS2.3.0.

Архитектура TCS-LB и схема трафика:

TCS-LB — это модуль собственной разработки, стоящий на плечах гигантов технической продукции:

● Проекты и технические достижения

В провинциальном коде состояния нуклеиновых кислот менеджер поддержки активности TCS обеспечивает стабильные и надежные возможности балансировки нагрузки L4 для обработки всех нагрузок трафика кода нуклеиновых кислот в контейнер APP нуклеиновых кислот.

В проекте вывода COS (Облачное хранилище объектов, продукт для хранения объектов Tencent) для интеллектуальных автомобилей горизонтальная масштабируемость TCS-LB обеспечивает COS высокопроизводительными возможностями балансировки нагрузки L4. Текущий клиент обеспечивает непрерывный и стабильный трафик с пропускной способностью 20 ГБ. в 2023 году емкость будет увеличена до 100 ГБ.

Среди многих проектов TCS PaaS TCS-LB обеспечивает высокопроизводительную и высокодоступную VIP-возможности балансировки нагрузки в зоне доступности для облачных продуктов, таких как Credis/TDMQ.

● Перспективы на будущее

TCS-LB в настоящее время не поддерживает IPv6. Как и TCS-CNI, в следующей версии нам необходимо дополнить возможности TCS-LB IPv6 и реализовать полномодульную возможность IPv6 (двойного стека) базы TCS для повышения производительности TCS. в сертификационной оценке и преимуществах технологического лидерства. В то же время TCS-LB также должен постепенно оптимизировать канал передачи данных с помощью TCS-CNI и перенести возможности прямого подключения VIP и Underlay Network Pod, реализованные базой TCS общедоступного облака, обратно в TCS-LB.

3.3 Облегченная виртуальная машина KubeVM

● Истории пользователей и технологий.

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

В версии TCS2.2.1 мы выпустили облегченный модуль планирования и доставки ресурсов виртуальной машины TCS KubeVM. TCS KubeVM использует технологию Kubevirt с открытым исходным кодом для глубокой интеграции других плагинов и возможностей TCS, включая плагин хранилища LocalPV CSI, сетевой плагин TCS-CNI, плагин графического процессора и т. д., предоставляя готовые к использованию возможности. создание и управление виртуальными машинами на базе TCS.

В версии TCS2.3.0 KubeVM постепенно становится более стабильной и простой в использовании. Важные функции включают интеграцию трех пакетов виртуализации TencentOS, управление рабочей нагрузкой виртуальных машин на граничном узле TCS-Edge, управление жизненным циклом виртуальных машин, управление образами, поддержку графических процессоров, виртуализацию. Вход в систему, создание снимков и холодная миграция, мониторинг сигналов тревоги, поддержка и другие возможности.

TCS KubeVM — это решение для доставки виртуальных машин, основанное на оркестрации контейнеров. Оно позволяет бизнесу виртуальных машин и контейнерному бизнесу работать в одном кластере посредством унифицированной оркестрации и планирования Kubernetes, используя один и тот же пул ресурсов, обеспечивая при этом меньшие потери ресурсов управления и контроля. стратегия перепроданности может улучшить использование ресурсов. Исходя из характеристик KubeVM, мы реализовали компактную архитектуру TCE3.10.0 и архитектуру версии TCS PaaS на базе KubeVM:

● Проекты и технические достижения

В проекте миниатюризации TCE3.10.0 мы используем технологию KubeVM для унификации пулов ресурсов контейнеров и виртуальных машин и единообразного управления распределением и перепродажей ресурсов для достижения архитектурной цели миниатюризации TCE.

В некоторых проектах, где у клиентов нет IaaS, KubeVM предоставляет облегченные возможности виртуализации для развертывания продуктов TCS PaaS/SaaS, обеспечивая требования к экономии ресурсов и изоляции.

● Перспективы на будущее

Текущая версия KubeVM по-прежнему больше ориентирована на реализацию функций, а также на обеспечение стабильности и работоспособности и по-прежнему слаба в построении возможностей продукта. Мы надеемся восполнить недостатки возможностей продукта в следующей версии. В то же время нам также необходимо успешно реализовывать различные проекты миниатюризации TCE и проекты TCS на базе KubeVM в различных средах клиентов. В процессе практики и внедрения мы будем дорабатывать продукт KubeVM, чтобы он стал более стабильным и простым в использовании.

3.4 Периферийные вычисления TCS-Edge

● Истории пользователей и технологий.

Благодаря популярности облачных технологий и распространению облачных технологий на периферийные устройства IoT многие клиенты и бизнес-стороны, занимающиеся продуктами PaaS/SaaS, выдвинули потребность в возможностях Edge в нашей TCS.

Выпущена версия TCS2.3.0 TCS-Edge. TCS-Edge — это приватизированное решение для доставки периферийных вычислений, основанное на платформе периферийных вычислений Tencent Cloud с открытым исходным кодом SuperEdge, которая расширяет облачные возможности TCS от облака до периферии и позволяет управлять периферийными ресурсами и периферийными рабочими нагрузками из центрального облака.

Функция рабочей нагрузки виртуальной машины управления пограничными узлами, предоставляемая TCS-Edge + KubeVM, является основной функцией TCS-Edge, которая может предоставлять облегченные услуги виртуальных машин для каждого пограничного сайта.

Схема архитектуры TCS-Edge:

● Проекты и технические достижения

В проекте интеграции границы облака станции трафика комбинация TCS-Edge + KubeVM обеспечит облегченные возможности рабочей нагрузки виртуальных машин для пограничных узлов каждой станции трафика.

Приватизация ведущей новой энергетической компании TI(TencentCloud TI Платформа, полнофункциональная платформа Tencent для разработки искусственного интеллекта) В выходном проекте TCS-Edge + IECP(Тенсент ОблакоПлатформа периферийных вычислений IoT) + TI Обеспечить управление узлами и GPU вычислительная мощность.

● Перспективы на будущее

В последующих версиях TCS TCS-Edge предоставит более полные возможности продуктовизации, включая мультиархитектуру одного кластера, пул пограничных узлов (NodeUnit/NodeGroup) и возможности продуктовизации периферийных рабочих нагрузок. В то же время мы надеемся расширить на Edge больше расширенных функций и модулей TCS, таких как TCS-LB, контейнерное промежуточное ПО SSM и т. д., чтобы еще больше повысить конкурентоспособность продукта TCS-Edge.

3.5 Контейнерное локальное хранилище LocalPV

● Истории пользователей и технологий.

Локальное хранилище контейнеров LocalPV предоставляет контейнерной платформе возможности планирования емкости локального диска и ограниченного квотой объема хранилища. TCS служит самой низкой базой, а контейнерная платформа, независимая от IaaS, является незаменимой возможностью TCS. Многие вспомогательные компоненты и управление облачными продуктами. все элементы управления построены на базе LocalPV. В версиях TCE3.8.0 и TCS2.0 LocalPV, предоставляемый TCS, уже имеет возможность локальной квоты тома и частичного планирования мощности. В ходе разработки TCS2.1.0 и TCS2.3.0 мы спланировали и реализовали множество требований к облачным продуктам.

После выпуска TCS2.3.0 мы предоставили более мощные и полные функции для LocalPV, такие как более точное определение емкости, использование одного модуля с несколькими LocalPV, планирование нескольких локальных дисков компьютеров и резервное копирование на основе ссылки xfs (реализация CoW) и Возможность восстановления. Возможности LocalPV, предоставляемые TCS2.3.0, недоступны в некоторых проектах локального объема с открытым исходным кодом и продуктах конкурентов. Он не только обеспечивает стабильные и надежные возможности локального объема для облачных продуктов, подключенных к TCE/TCS, но также предоставляет саму контейнерную платформу TCS. конкурентоспособность.

Резервное копирование и восстановление LocalPV:

● Проекты и технические достижения

В проекте приватизации Cloud Nest (продукт Tencent Database PaaS) Cloud Nest использует возможности резервного копирования и восстановления TCS LocalPV для достижения возможностей резервного копирования и быстрого восстановления экземпляров базы данных.

● Перспективы на будущее

Квота TCS2.3.0 LocalPV реализована на основе LoopDevice, что приводит к некоторой потере производительности. В ответ на все более строгие требования облачных продуктов TCE/TCS и KubeVM мы разрабатываем решение для квот на основе prjquota и с нетерпением ждем его скорейшего запуска, чтобы обеспечить возможности LocalPV с большей производительностью.

3.6 Контейнерная платформа и улучшение планирования

● Истории пользователей и технологий.

В версии TCE3.8.0/TCS2.0 TCS использует Kubernetes 1.16 для создания контейнерной платформы и базы. В версии TCE3.10.0/TCS2.3.0 TCS плавно обновляется до Kubernetes 1.18, чтобы обеспечить большую совместимость подключаемых модулей и исправить множество потенциальных CVE и ошибок.

Контейнерная платформа TCS2.3.0 и возможности планирования также сделали множество расширений, таких как статический порт NodePort, черный список NodePort, сохранение IP-адресов и назначенное планирование, сохранение ресурсов (применимо к KubeVM и сценариям Pod с отслеживанием состояния), поддержка Topo и назначенное планирование, возможность планирования qGPU. и т. д. Эти усовершенствования в контейнерной платформе и возможностях планирования обеспечивают облачным продуктам TCE/TCS более сильные возможности контейнерной платформы, а также повышают конкурентоспособность самой контейнерной платформы TCS.

● Перспективы на будущее

С каждой основной версией TCS/TCE мы планируем обновлять версию Kubernetes, чтобы собственная облачная технология TCS соответствовала последней версии сообщества и поддерживала технологический прогресс. Мы активно сотрудничаем с командой TKE для интеграции расширенных функций контейнерной платформы TCS и возможностей планирования в версию TKE, а также для разработки последующих возможностей контейнерной платформы TCS на основе версии TKE.

3.7 Управление кластером и DIOH

● Истории пользователей и технологий.

В версии TCE3.8.0/TCS2.0 развертывание TCS (глобального кластера) основано на режиме tke-installer плюс скриптовое развертывание компонентов TCS Addon. Этот метод имеет плохую масштабируемость и ремонтопригодность. Изменение параметров запуска или образов некоторых компонентов управления и контроля может потребовать перепаковки всего tke-installer, а реализовать автоматическое обновление компонентов управления и контроля на месте невозможно. В то же время неравномерность сценария развертывания аддонов привела к очень низкой вероятности успешного развертывания.

Когда была запущена версия TCS2.2.0, мы создали проект DIOH — это аббревиатура от «развертывание за один час», чтобы обеспечить единое и высококачественное решение для развертывания всех компонентов TCS, достигая цели «мы можем автоматически и высоко». -качество доходит до дома любого клиента. Цель: доставить любую зафиксированную версию любого компонента. Области DIOH охватывают производительность исследований и разработок, автоматическое тестирование развертывания и управление кластерами.

В проекте DIOH мы унифицировали формат пакета базового компонента TCS, и владелец компонента должен предоставлять шаблоны диаграмм, файлы Dockerfile образа контейнера и шаблоны RPM унифицированным образом. На основе унифицированного пакета компонентов мы разработали новое решение по управлению кластером TCS (кластер-оператор/узел-оператор). По сравнению со старой версией решения, которое контролирует только определение этапа развертывания и позволяет владельцу компонента предоставлять сценарии развертывания. , новый оператор кластера. Решение /node-operator подчеркивает стандартизацию всех элементов управления жизненным циклом: унифицированный формат пакета, а также контроль установки и обновления, что помогает повысить надежность развертывания и обновления кластера, а также упрощает создание новых TCS. в автоматизированном конвейере исследований и разработок. Кластеризируйте или обновите компоненты и, наконец, запустите тесты e2e, чтобы улучшить качество компонентов TCS/TCE.

После выпуска TCS2.3.0 мы предоставим автоматизированные и эффективные возможности управления кластерами и подкластерами для каждого проекта на основе новой версии управления кластерами и решений DIOH. Мы также предоставляем богатые конфигурации для удовлетворения различных требований клиентов по высокой доступности и функциям. потребности.

Схема архитектуры управления кластером DIOH:

API управления кластером DIOH:

● Перспективы на будущее

Мы работаем с командой разработчиков продуктов TKE над созданием ClusterAPI следующего поколения (ClusterAPI v2). Решения по управлению и контролю кластеров TCS и TKE будут постепенно интегрироваться и унифицироваться в последующих версиях, предоставляя унифицированный API для каждого продукта Tencent Cloud. облегчить интеграцию и доступ.

3.8 Многокластерная нагрузка

● Истории пользователей и технологий.

В версии TCS2.1.0 TCS поддерживает возможности мультикластера. Мы четко понимаем, что возможности мультикластера не являются реальным конечным требованием пользователей. Конечным требованием пользователей должно быть планирование и развертывание приложений в нескольких кластерах для достижения возможностей мультикластерного аварийного восстановления.

В версии TCS2.3.0 мы интегрировали кластерную сеть для реализации возможностей планирования мультикластерных приложений и доставки ресурсов. В то же время мы реализовали возможности взаимодействия нескольких кластеров приложений и обнаружения сервисов на основе платформы объявления маршрутов и обнаружения сервисов TCS-CNI — ClusterMesh. По сравнению с ClusterMesh сообщества cilium, ClusterMesh, реализованный TCS, является более легким, не зависит от системы cilium и может работать в ядрах более низких версий, обеспечивая возможности обнаружения многокластерных сервисов независимо от ядра и подключаемых модулей CNI.

В версии TCS2.3.0 пользователи могут использовать функции кластерной сети и ClusterMesh, предоставляемые TCS, чтобы легко выпускать многокластерные приложения и включать многокластерные приложения для достижения межкластерной катастрофоустойчивости.

Кластерная сеть интеграции TCS:

Схема архитектуры мультикластерного приложения и реализация ClusterMesh:

● Перспективы на будущее

В настоящее время доставка ресурсов нескольких кластеров и планирование приложений, обеспечиваемые TCS, являются возможностями «черного экрана». В следующей версии мы будем коммерциализировать эту возможность.

3.9 Собственная облачная установка DCOS и Igniter

● Истории пользователей и технологий.

В версии TCE3.8.0 техническая архитектура продукта DCOS сложна, и его обязанности не ясны в сравнении с другими продуктами TCE OSP. Кроме того, сложность технической архитектуры приводит к плохой работоспособности и масштабируемости продукта. В версии TCE3.10.0 мы постепенно начали настраивать и оптимизировать общую архитектуру продуктов DCOS. Мы унифицировали возможности мониторинга серверов с платформой Yunshao. В будущем мы также унифицируем серверную часть. возможности управления активами в CMDB и выше. Обеспечьте совместимость API. После реконструкции позиционирование DCOS в большей степени ориентировано на позиционирование «родной облачной установочной платформы», что значительно улучшило производительность одновременной установки. В то же время сама DCOS в TCS2.3.0 становится все более легкой. Версия DCOS может использоваться только с выходом TCS.

Igniter — это система установки «голого железа», разработанная командой TCS. По сравнению со старой версией системы установки она решает проблему недостаточного IP-адреса для установки, поддерживает сосуществование нескольких инструментов установки и обеспечивает установку с несколькими конфигурациями. В то же время Igniter архитектурно отделен от DHCP, что позволяет независимо развертывать DHCP с высокой доступностью и обеспечивает более надежные возможности эксплуатации, обслуживания и управления для внеполосного IP. В версии TCS2.3.0/TCE3.10.0 мы работали с основной командой технического обслуживания и доставки над интеграцией решения Igniter + auto_install_os, чтобы обеспечить возможность быстрой и гибкой пакетной установки для установок в открытой зоне в различных средах клиентов.

Архитектура и блок-схема DCOS:

● Проекты и технические достижения

В проектах доставки TCE и некоторых проектах доставки физических компьютеров TCS Igniter + auto_install_os используется для реализации установки зоны на месте клиента, что значительно повышает эффективность доставки зоны. В то же время модуль DCOS TCS предоставляет CVM (vstation) управление IP-адресами CVM, автоматическую регистрацию CMDB и другие возможности.

● Перспективы на будущее

В следующей версии мы реализуем архитектуру следующего поколения «облачной установочной платформы» Igniter и DCOS. Помимо более простой архитектуры и более удобной эксплуатации и обслуживания, она также реализует возможности высокой доступности Igniter и DHCP. В то же время, что касается возможностей продукта, мы предоставим такие функции, как несколько сетевых карт и поддержка IPv6. Что касается адаптации моделей, мы продолжим наращивать усилия по поддержке адаптации моделей Синхай, а также будем внедрять и адаптировать специальные модели, такие как модели интеллектуальных сетевых карт Yinshan, для повышения конкурентоспособности продукции TCE.

3.10 Архитектура высокой доступности

● Истории пользователей и технологий.

В версии TCE3.8.0 высокая доступность всей TCS в нескольких зонах доступности зависит от возможности высокой доступности в нескольких зонах доступности облачного продукта TGW VIP. Поэтому в версии TCS2.0/TCS2.1.0 отсутствует функция высокой доступности. Возможности ECMP VIP, TCS не обеспечивает высокую доступность в нескольких зонах доступности. Благодаря доступу к большему количеству облачных продуктов от TCS, компании TCS срочно необходимо согласовать эту часть своих возможностей для удовлетворения потребностей в выпуске облачных продуктов отдельно или в сочетании. Только базовые ресурсы TCS могут обеспечить возможности высокой доступности в нескольких зонах доступности.

В версии TCS2.3.0 с возможностью горизонтального расширения модуля TCS-LB в режиме BGP TCS обеспечивает возможности высокой доступности в зоне доступности с автоматическим переключением при сбое для подключенных облачных продуктов.

В ходе проверки доставки некоторых клиентских сред мы обнаружили, что некоторые клиенты не смогли предоставить компьютерным залам динамическую маршрутизацию BGP/OSPF для реализации возможностей ECMP, но им требовались TCS и облачные продукты TCS для обеспечения возможностей высокой доступности AZ. В более поздней версии TCS2.3.0 мы представили новую архитектуру нескольких зон доступности, используя несколько VIP в нескольких зонах доступности для достижения высокой доступности зоны доступности на основе DNS и обеспечения высокой доступности зоны доступности для клиентов без возможностей ECMP.

Архитектура высокой доступности на основе режима BGP TCS-LB:

Высокодоступная архитектура без ECMP:

● Проекты и технические достижения

В некоторых проектах TCS PaaS/SaaS, где клиентам требуется высокая доступность в нескольких зонах доступности, режим BGP TCS-LB обеспечивает возможности работы в нескольких зонах доступности для различных облачных продуктов и платформ TCS и достиг идеальных результатов в тестах клиентов и реальных сценариях аварийного восстановления.

В некоторых проектах, где клиентам требуется высокая доступность в нескольких зонах доступности, но они не могут обеспечить возможности динамической маршрутизации, TCS использует решение архитектуры высокой доступности без ECMP, чтобы обеспечить возможности высокой доступности в нескольких зонах доступности с коммутацией нескольких VIP для каждого облачного продукта.

● Перспективы на будущее

В следующем году TCS объединит TSF или поможет клиентам реализовать возможности мультиактивности в удаленных местах, помогая большему количеству облачных продуктов достичь возможностей аварийного восстановления с высокой доступностью «финансового уровня» в средах клиентов.

3.11 Миниатюрная архитектура и оптимизация ресурсов

● Истории пользователей и технологий.

В архитектуре TCE3.8.0 для доставки набора TCE требуется больше ресурсов управления и контроля TCE. Например, для поставки минимального набора продуктов IaaS требуется первоначальные 17 баз и вспомогательных компьютеров. При подаче заявок или реализации проектов с меньшим количеством ресурсов продаж. ресурсы управления и контроля должны быть ограничены. Дозировка часто вызывает вопросы.

В версии TCE3.10.0 мы сделали миниатюрную архитектуру. Цель миниатюризированной архитектуры не только в том, чтобы быть «маленькой» (целевой минимальный набор продуктов IaaS должен начинаться с 5 единиц управления и контроля), но, что более важно, мы ожидаем, что это будет стандартизированная архитектура для последующих версий и достижения плавное обновление исторических версий. В качестве стандартизированной архитектуры миниатюрная архитектура TCE может использоваться для реализации сценариев с одной зоной доступности, нескольких зон доступности, нескольких регионов и других сценариев различного масштаба и требований аварийного восстановления, а также для обеспечения плавного обновления предыдущих версий. Миниатюрная архитектура TCE необходима; сохранить форму и исторические версии базы и поддержки максимально унифицированными, а изменения архитектуры сделать максимально незаметными для облачных продуктов.

Внедрение миниатюрной архитектуры TCE также сталкивается со сложностью и трудностями, вызванными корректировкой архитектуры, поэтому мы принимаем многоэтапную стратегию. На первом этапе мы объединили базовый контейнер, ресурсы поддержки и UnderlayCVM (развернутый CVM, управляемый TCE) в пул, а затем равномерно перепродали и распределили ресурсы после объединения в пул. Конечно, исходную поддержку промежуточного программного обеспечения и управление развертыванием режима CVM по-прежнему нельзя контейнеризировать. После объединения пула KubeVM на базе TCS будет предоставлять облегченные виртуальные машины. Первый этап завершен. Мы достигли цели по предоставлению минимального набора продуктов IaaS, начиная с 10 баз, и проверили возможности обеспечения высокой доступности в двух зонах доступности и полноценные облачные продукты.

Первый этап архитектуры миниатюризации (минимальный набор продуктов IaaS):

● Перспективы на будущее

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

3.12 Внутренняя адаптация и оптимизация

● Истории пользователей и технологий.

Видение TCE/TCS — создавать продукты, независимые от аппаратной архитектуры и операционной системы. Мы активно адаптируемся к различному оборудованию отечественного производства.

Основы TCS2.3.0 и TCE3.10.0 были адаптированы к распространенным моделям отечественной архитектуры, таким как Feiteng, Kunpeng и Haiguang. Что касается отечественных операционных систем, компания TCS завершила адаптацию различных версий Kirin и TencentOS.

Для оборудования отечественного производства многоядерный режим работы обычно работает плохо, когда ядра не привязаны или привязаны неправильно. Поэтому для достижения более идеального пользовательского опыта наиболее важным является повышение производительности программного обеспечения на оборудовании отечественного производства. . Тюнинг. Мы обобщили опыт использования ядра CPU/Numa в адаптации различных отечественных моделей и в настоящее время интегрируем его в возможности производства. Продукты, подключенные к TCS, могут использовать усовершенствованные возможности планирования ЦП, предоставляемые платформой TCS «из коробки».

Усовершенствованная архитектура планирования ЦП TCS:

● Проекты и технические достижения

В тендере на технологию PoC для крупномасштабного государственного проекта частного облака компании TCS и TDSQL продолжили исследование и оптимизацию производительности отечественного оборудования Feiteng-S2500, оптимизируя тестовое приложение, предоставленное заказчиком, до максимальной производительности и вдвое превзойдя конкурентов. цена в конкурентной борьбе. Показатели эффективности QPS достигли полного успеха, что помогло TCE успешно выиграть тендер на этот проект.

04

Заключение

Технологии и продукты облачной инфраструктуры TCS2.3.0 претерпели значительную эволюцию, и многие технологии и продукты были созданы «от 0 до 1». Мы надеемся вложить больше усилий в улучшение удобства использования и стабильности продукта в последующих версиях, чтобы продукты TCS, связанные с облачной инфраструктурой, могли завоевать репутацию и влияние среди пользователей с точки зрения продукта и стабильности. В то же время мы также будем вкладывать больше энергии в создание продуктов облачной инфраструктуры TCS, которые легко доставлять, эксплуатировать и обслуживать, чтобы сэкономить затраты на доставку, эксплуатацию и обслуживание. Что касается технологического развития собственной облачной инфраструктуры TCS, мы продолжим сохранять наш энтузиазм в отношении технологий, интегрировать более передовые и надежные технологии в TCS и поддерживать конкурентоспособность продуктов TCS.