Что такое alibaba cloud
1С в Elastic Compute Service Alibaba Cloud. Сокровища Алибабы
Если ты умеешь что-то делать хорошо, всегда найдется азиат, который сможет лучше
(один из самых популярных интернет мемов).
Aliexpress уже стал именем нарицательным в всем мире. Но Alibaba Group это не только интернет-молл, но и сервис облачных вычислений №1 в Китае.
Интересующихся прошу под кат…
К министру обороны Китая входит начальник штаба.
-Мой генерал, нам объявила войну Чехословакия.
-Какова численность их армии?
-50 тысяч человек.
-Отлично. Подумайте в какой гостинице их разместить.
юмор времен СССР
Постановка задачи
Когда интернет-гиганты рассказывают о больших нагрузках на свои сервисы, они всегда делают это невольно озираясь на Восток.
Еще бы, ты рапортуешь о регистрации миллионного (десяти-, ста- миллионного) посетителя, с гордостью показывая графики и таблицы, а потом приходит «небольшой» почтовик из Поднебесной и рассказывает как они обрабатывают миллиардный траффик (кстати сейчас, в дни Китайского Нового Года он максимальный).
Я давно общаюсь (в основном конечно с продавцами Aliexpress) с китайскими товарищами и эти люди внушают мне уважение.
Поэтому пройти мимо возможности проникнуть, хотя бы и виртуально за Великую китайскую стену я не мог. Прошел с небольшими потерями.
… В любой непонятной ситуации — матерись.
флотская мудрость
Решение
Матерился я часто, но в основном от восхищения. Уходил от компьютера, звал жеванного крота, возвращался с линейкой… цифры сходились до тысячных.
Но обо всем по порядку.
Тем кто не любит много букв
Понятно что 1С Предприятие разместилось там как влитое, причем на стандартных, а не премиум дисках. Пока это лучшие сервера из тех которые побывали в моих руках, как по качеству, так и по соотношению цена/качество. Из минусов только отсутствие русского языка, русскоязычной поддержки и нашего менталитета.
Стоимость зависит от физической локации, в материковом Китае к примеру в полтора раза дешевле чем в Западной Европе.
Чтобы получить сервер на территории Китая, нужно прислать сканы документов (водительского удостоверения или паспорта). Даже если вы не собираетесь размещать 1С или что бы то ни было в облачных сервисах, я настоятельно рекомендую вам потратить один доллар на регистрацию и посмотреть, что такое гармония технических решений.
Кроме того, это сервера, где в тестах 1С Postgres + Ubuntu уверенно опередил Microsoft SQL + Windows.
Тестовый контур и порядок работы
Сервер Windows 2008 R2, Сервер Ubuntu 16.04
Postgres 11, MS SQL 2014 evaluation, в Linux MS SQL 2017 evaluation
1С: Предприятие 8.3 (8.3.13.1644), Бухгалтерия предприятия, редакция 3.0 (3.0.66.70)
crystal disk mark, winrar, 7zip
HammerDB
Тестовые конфигурации 1С с сайтов www.gilev.ru и fragster.ru, а также обработка эмулирующая работу пользователей в 1С Бухгалтерия предприятия.
Конфигурация обеих виртуальных машин одинаковая (4 ядра 16 Гб ОЗУ и 50 Гб HDD) приближенная к реальной рабочей.
На обоих серверах установлен гуи и тесты проводились попеременно с одного на другой.
Методика и ссылки на использованные конфигурации — в первой статье.
Картинки кликабельны. Полные принтскрины результатов под спойлерами.
Полученные результаты
Даже путь в тысячу ли начинается с первого шага.
Лао-цзы
Если о сервисах Azure написаны книги, то о сервисах Elastic Compute Service можно писать собрание сочинений.
Часть из них я просто не знаю, не то чтобы рассказать как они работают.
Этой статье я лишь делаю первый шаг внутрь всего этого многообразия.
Тем кого много букв не пугает, приступим
Как я уже сказал, Elastic Compute Service произвел на меня сильное впечатление.
С самого начала… С самого начала я обнаружил, что из 40+ предлагаемых тестовых продуктов сервер для 1С не собрать — не хватит мощности.
Закинул удочку в саппорт — и получил вежливый ответ, что они такие дела не решают, надо обращаться в финансовую поддержку.
Поэтому второе письмо посылал уже с меньшим энтузиазмом… Через день на меня смотрело уже три китайца.
Надо сказать, что кроме врожденной вежливости, во всем что касается общения у китайцев видна гордость за проведение Олимпийских Игр 2020. Поэтому везде где это только уместно видишь их логотип:
А уместно наверное везде. В России обычно про такое говорят: Сделано с любовью. Для Китая может это просто хорошо выполненная работа.
Мужик из Москвы на новой машине в Питере спрашивает дорогу у местного.
— О 97, — говорит тот, глядя на номера, — Из какого это ты региона?
— Это ты — из региона, а я из Москвы!
анекдот.ру
Который уточнив цель моего визита, а я показал ему на принскрине какую конфигурацию хочу получить
, (немного расстроился конечно, что я не собираюсь покупать сервера бочками), взял с меня слово, что я помогу подключиться всем желающим из России (что я несколько самоуверенно пообещал) и выдал мне купон на 150$ (по поводу купона еще отдельная история ниже).
… и вот отсюда уже идет начало
Как я уже говорил, сервис сделан отлично. Даже основательно задумавшись, не придумать детали, которую хотелось бы улучшить.
Мне даже кажется, что несколько перегруженные элементами страницы выбора услуги, сделаны так не случайно, а с целью поразить масштабом происходящего.
При этом продуманность ощущается даже в мелочах — типа виртуального тура для нового пользователя:
и обязательного знакомства с SLA
или приветствия командной строки Ubuntu (это вообще так мило).
Ну а возможность работать из веб-интерфейса — это конечно киллер-фича.
Думаю, каждый кто настраивал сервера в облаках, наступал на эти грабли — поменял порт RDP и забыл прописать в брандмауэре или сетевую карту отключил, многое бывает. Одно неосторожное движение мышью — и вы уже по разные стороны монитора, сервер спокойно пыхтит где-то в Амстердаме, а вы в Питере бьетесь головой о стол.
А тут если виртуальная машина в принципе стартовала — вы к ней получите доступ.
Что еще удобно — ярлычок странички с тикетами обращения в поддержку есть на каждом экране.
Что не удивительно, во первых в тестовых машинах было по 4 ядра, а во вторых отлично сбалансированные диски.
Скорость доступа в интернет обрезана ровно настолько, насколько заплачено.
Как я уже сказал, в такой конфигурации оборудования в тестах 1С Postgres рванул Microsoft.
Причем с дефолтными настройками, больше, чем с рекомендованными.
Тесты HammerDB для MS SQL почти дотянули до опубликованных официальных Alibaba Cloud Performance White Paper
APDEX в обоих вариантах ожидаемо максимальный.
-А пуркуа бы и не па?: подумал я. И собрал конфигурацию виртуальной архитектуры среднего бизнеса своей мечты
(это конечно для красного словца, на самом деле просто которую бы я рекомендовал, мечты то у меня побольше).
Почти вписавшись в отведенные 150$ купона.
Техническое отступление: VPN и WWW сервера конечно можно было не собирать самому, а купить готовые, в наборе предлагаемых сервисов конечно же есть и тот и другой, так же как и например ApsaraDB для MS SQL.
Но VPN мне показалось, что выйдет дороже, а для веб-серверов конфигурация слабовата, 1С Битрикс она не потянет.
… и только я застыл посреди всего этого благолепия… как меня прибили.
… ты просишь без уважения, ты не предлагаешь дружбу, ты даже не назвал меня крестным отцом.
Надеюсь, мы еще помиримся.
Так что на этом месте повествование заканчивается и пора подвести полный итог
Elastic Compute Service Alibaba Cloud отличный выбор для размещения виртуальной инфраструктуры, как для ИТ гурманов, так и для обычных пользователей.
Пока недостаточно изученный и представленный в нашей стране, поэтому небольшая доля авантюризма в этом решении присутствует.
Дальнейшее его развитие в России зависит возможно от нас самих. Кто не рискует, тот не пьет шампанского.
Может Europe и обгонит в EMEA регионе the Middle East and Africa.
Я рекомендую его как минимум к просмотру всем прочитавшим эту статью, как образец технического совершенства.
Да пребудет с вами восточная мудрость и благоденствие.
И да, от своих слов я не отказываюсь, пишите, перекину вам контакты менеджера региона EMEA, господина Leo Liu.
Статья продолжает цикл тестов облачных платформ:
Если у тебя есть фонтан, заткни его; дай отдохнуть и фонтану
Козьма Прутков
С каждой статьей я сам открыл для себя что-то новое, и надеюсь удалось частично поделиться этим с вами.
Русские Блоги
Alibaba Cloud OSS (Служба хранения объектов) Введение
В последнее время компания хочет использовать Alibaba Cloud OSS для хранения точных изображений пассажиропотока, поэтому заранее ознакомьтесь и сделайте запись
Примечание. В официальных документах Alibaba Cloud подробно описаны OSS и процесс разработки. Большая часть этой статьи относится к официальным документам.
1. Введение продукта
1. Что такое OSS
Вы можете использовать интерфейс API / SDK, предоставляемый Alibaba Cloud или инструментом миграции OSS, чтобы легко перемещать большие объемы данных в Alibaba Cloud OSS или из него. После того, как данные сохранены в Alibaba Cloud OSS, вы можете выбрать стандартный тип (Стандартный) сервис Alibaba Cloud OSS в качестве основного метода хранения для мобильных приложений, больших веб-сайтов, обмена изображениями или аудио и видео в горячих точках. Вы также можете выбрать более низкие затраты и более длительные периоды хранения. Тип низкочастотного доступа (нечастый доступ) и тип архива (архив) службы Alibaba Cloud OSS используются в качестве резервной копии и архивирования данных нечастого доступа.
2. Преимущества
3. Обзор функций
4. Используйте сценарии
4.1 Массовое хранение приложений, таких как изображения, аудио и видео
OSS может использоваться для хранения больших файлов, таких как изображения, аудио и видео, а также журналы. Различные терминальные устройства, программы веб-сайтов и мобильные приложения могут напрямую записывать или считывать данные в OSS. OSS поддерживает два метода потоковой передачи и записи файлов.
4.2 Разделение статических и динамических ресурсов веб-страниц или мобильных приложений
Используя пропускную способность BGP, OSS может напрямую загружать данные со сверхнизкой задержкой. Он также может сотрудничать со службой ускорения Alibaba Cloud CDN, чтобы обеспечить наилучший опыт распространения обновлений изображений, аудио и видео, а также мобильных приложений.
4.3 Обработка данных в облаке
После загрузки файлов в OSS вы можете сотрудничать со службой транскодирования медиаданных (MTS) и службой обработки изображений (IMG) для обработки данных в облаке.
5. Ограничения на использование
2. Руководство по разработке
1. Введение в основные понятия
1.1 Место для хранения (ведро)
Соглашение об именовании пространства хранения выглядит следующим образом:
1.2 Объект / Файл (Объект)
OSS предоставляет дополнительную функцию загрузки, пользователи могут использовать эту функцию для непрерывной записи дополнительных данных в конце объекта.
Соглашение об именах для объектов выглядит следующим образом:
Он не может начинаться с символов «/» или «\».
1.3Регион (регион)
Регион представляет регион и физическое местоположение центра обработки данных OSS. Пользователь может выбрать регион для хранения данных на основе стоимости и источника запроса. В целом, регионы, которые ближе к пользователям, имеют более высокие скорости доступа. Для деталей, пожалуйста, проверьтеРегион, в котором открыт OSS。
Регион указывается при создании сегмента. После определения его нельзя изменять. Все объекты в сегменте хранятся в соответствующем центре обработки данных. В настоящее время параметр Регион на уровне объекта не поддерживается.
1.4Endpoint (доступ к доменному имени)
Конечная точка представляет собой имя домена доступа внешних служб OSS. OSS предоставляет внешние сервисы в виде HTTP RESTful API. При доступе к разным регионам требуются разные доменные имена. Конечные точки, необходимые для доступа к одному региону через интрасеть и экстрасеть, также различаются. Например, конечной точкой экстрасети региона Ханчжоу являетсяoss-cn-hangzhou.aliyuncs.comКонечная точка Интранетаoss-cn-hangzhou-internal.aliyuncs.com, Для получения подробной информации, пожалуйста, обратитесь кКонечная точка, соответствующая каждому региону。
1.5AccessKey (ключ доступа)
Для получения дополнительной информации о AccessKey, пожалуйста, обратитесь к Контроль доступа。
1.6 Сильная последовательность
Операция объекта является атомарной в OSS. Операция будет либо успешной, либо неудачной, и не будет объекта с промежуточным состоянием. OSS гарантирует, что Объект, который читает пользователь, будет завершен после завершения загрузки, и OSS не вернет пользователю частично загруженный Объект.
Операция Object также имеет строгую согласованность с OSS.После того, как пользователь получает успешный ответ на PUT, загруженный объект сразу же читается, и три копии данных были успешно записаны. Промежуточное состояние для загрузки отсутствует, то есть чтение после записи не может считывать данные. То же самое относится и к операции удаления: после того, как пользователь успешно удаляет указанный Объект, Объект немедленно становится несуществующим.
Строгая согласованность облегчает архитектурное проектирование пользователя. Вы можете использовать ту же логику, что и традиционное запоминающее устройство, чтобы использовать OSS, и изменение сразу видно, без учета различных проблем, вызванных окончательной согласованностью.
2. Тип хранения
OSS предоставляет три типа хранения: стандартный, низкочастотный доступ и архивирование, охватывающее все виды сценариев хранения данных от горячего до холодного.
2.1 Стандартный тип хранения (Standard)
Стандартный тип хранения OSS обеспечивает высоконадежные, высокодоступные и высокопроизводительные службы хранения объектов, которые могут поддерживать частый доступ к данным. Возможности ответа служб с высокой пропускной способностью и низкой задержкой OSS могут эффективно поддерживать доступ к данным различных точек доступа. Стандартный тип хранения является подходящим выбором для различных социальных сетей и обмена фотографиями, аудио и видео приложениями, большими веб-сайтами и анализа больших данных.
2.2 Тип хранилища с нечастым доступом
Тип хранения низкочастотного доступа OSS подходит для долговременного хранения данных, к которым редко обращаются. Цена за единицу хранения ниже, чем у стандартного типа, подходит для долгосрочного резервного копирования различных мобильных приложений, интеллектуальных устройств и корпоративных данных. Объекты хранилища с низкочастотным доступом имеют наименьшее время хранения, а файлы со сроком хранения менее 30 дней будут предварительно списаны с платы за удаление. Объект хранения с низкочастотным доступом имеет минимальное пространство для измерений. Если размер объекта составляет менее 64 КБ, пространство для хранения будет рассчитано в соответствии с 64 КБ, а сбор данных будет стоить плату.
2.3 Тип хранилища архива (Архив)
Тип хранения архива OSS имеет самую низкую цену за единицу среди трех типов хранения. Он подходит для архивных данных, которые необходимо хранить в течение длительного времени (рекомендуется более полугода). К нему редко обращаются во время цикла хранения. Для размораживания данных, когда они доступны для чтения, требуется 1 минута. Он подходит для архивных данных, медицинских изображений, научных материалов и пленочных материалов, которые необходимо хранить в течение длительного времени. Объекты с типом хранилища архива имеют наименьшее время хранения, а файлы со сроком хранения менее 60 дней будут предварительно списаны с платы за удаление. Объект хранения архивного типа имеет минимальное пространство для измерений.Если размер объекта меньше 64 КБ, пространство для хранения будет рассчитано в соответствии с 64 КБ, а сбор данных будет стоить плату.
2.4 Сравнение типов хранилищ
3. Пример демо
3.1 Среда строительства
Установите JDK (выше 1.6), добавьте зависимости maven или импортируйте jar-пакет
groupId > com.aliyun.oss groupId >
artifactId > aliyun-sdk-oss artifactId >
version > 2.8.2 version >
Как облако Alibaba Cloud управляет десятками тысяч кластеров Kubernetes с помощью… Kubernetes
Рис. 1. Экосистема Kubernetes в облаке Alibaba Cloud
С 2015 года Alibaba Cloud Container Service for Kubernetes (ACK) является одним из самых быстрорастущих облачных сервисов в Alibaba Cloud. Он обслуживает многочисленных клиентов, а также поддерживает внутреннюю инфраструктуру Alibaba и другие облачные сервисы компании.
Как и в аналогичных контейнерных сервисах от облачных провайдеров мирового уровня, наши главные приоритеты — надёжность и доступность. Поэтому для десятков тысяч кластеров Kubernetes создана масштабируемая и глобально доступная платформа.
В этой статье мы поделимся опытом управления большим количеством кластеров Kubernetes на облачной инфраструктуре, а также архитектурой базовой платформы.
Вступление
Kubernetes стал фактически стандартом для различных рабочих нагрузок в облаке. Как показано на рис. 1 вверху, всё больше и больше приложений Alibaba Cloud теперь работают в кластерах Kubernetes: это приложения с сохранением состояния и без (stateful/stateless), а также менеджеры приложений. Управление Kubernetes всегда представляло интересную и серьёзную тему обсуждения для инженеров, которые занимаются построением и обслуживанием инфраструктуры. Когда речь идёт об облачных провайдерах, таких как Alibaba Cloud, на первый план выходит проблема масштабирования. Как управлять кластерами Kubernetes в таком масштабе? Мы уже рассказывали о лучших практиках управления огромными кластерами Kubernetes с 10 000 узлами. Конечно, это интересная проблема масштабирования. Но есть и другая шкала масштаба: количество самих кластеров.
Мы обсуждали эту тему со многими пользователями ACK. Большинство из них предпочитают запускать десятки, если не сотни, небольших или средних кластеров Kubernetes. На это есть разумные причины: ограничение потенциального ущерба, разделение кластеров для разных команд, создание виртуальных кластеров для тестирования. Если ACK стремится обслуживать глобальную аудиторию по такой модели использования, то должна надёжно и эффективно управлять большим количеством кластеров в более чем 20 регионах.
Рис. 2. Проблемы управления огромным количеством кластеров Kubernetes
Каковы основные проблемы управления кластерами в таком масштабе? Как показано на рисунке, необходимо разобраться с четырьмя проблемами:
Платформа ACK предназначена для решения большинства вышеперечисленных проблем. В настоящее время она надёжно и стабильно управляет более чем 10 тыс. кластерами Kubernetes по всему миру. Посмотрим, как удалось этого добиться, в том числе благодаря нескольким ключевым принципам дизайна/архитектуры.
Дизайн
Куб-на-кубе и соты
В отличии от централизованной иерархии, сотовая архитектура (cell-based architecture) обычно используется для масштабирования платформы за пределы одного дата-центра или для расширения области аварийного восстановления.
Каждый регион в облаке Alibaba Cloud состоит из нескольких зон (AZ) и обычно соответствует конкретному дата-центру. В большом регионе (например, Хуанчжоу) частенько встречаются тысячи клиентских кластеров Kubernetes под управлением ACK.
ACK управляет этими кластерами Kubernetes с помощью самого Kubernetes, то есть у нас работает метакластер Kubernetes для управления клиентскими кластерами Kubernetes. Такая архитектура также называется «куб-на-кубе» (kube-on-kube, KoK). Архитектура KoK упрощает управление клиентскими кластерами, поскольку развёртывание кластера становится простым и детерминированным. Что ещё важнее, мы можем повторно использовать функции нативного Kubernetes. Например, управление API-серверами через деплой, использование оператора etcd для управления несколькими etcd. Такая рекурсия всегда приносит особое удовольствие.
В пределах одного региона развёртываются несколько метакластеров Kubernetes, в зависимости от числа клиентов. Эти метакластеры мы называем сотами (cell). Чтобы защититься от сбоя целой зоны, ACK поддерживает мультиактивные развёртывания в одном регионе: метакластер распределяет компоненты мастера клиентских кластеров Kubernetes по нескольким зонам и запускает их одновременно, то есть в мультиактивном режиме. Чтобы обеспечить надёжность и эффективность мастера, ACK оптимизирует размещение компонентов и гарантирует, что сервер API и etcd стоят близко друг к другу.
Такая модель позволяет эффективно, гибко и надёжно управлять Kubernetes.
Планирование ресурсов метакластера
Как мы уже упоминали, количество метакластеров в каждом регионе зависит от числа клиентов. Но в какой момент добавить новый метакластер? Это типичная проблема планирования ресурсов. Как правило, принято создавать новый, когда существующие метакластеры исчерпали все свои ресурсы.
Возьмём, к примеру, сетевые ресурсы. В архитектуре KoK компоненты Kubernetes из клиентских кластеров деплоятся как pod’ы в метакластере. Мы используем Terway (рис. 3) — высокопроизводительный плагин, разработанный Alibaba Cloud для управления контейнерной сетью. Он предоставляет богатый набор политик безопасности и позволяет подключаться к виртуальным частным облакам (VPC) клиентов через интерфейс Alibaba Cloud Elastic Networking Interface (ENI). Чтобы эффективно распределять сетевые ресурсы по узлам, pod’ам и сервисам в метакластере, мы должны тщательно отслеживать их использование внутри метакластера из виртуальных частных облаков. Когда сетевые ресурсы подходят к концу, создаётся новая сота.
Для определения оптимального количества клиентских кластеров в каждом метакластере мы также учитываем свои затраты, требования к плотности, квоту ресурсов, требования к надёжности и статистические данные. Решение о создании нового метакластера принимается на основании всей этой информации. Обратите внимание, что маленькие кластеры в будущем могут сильно расшириться, поэтому расход ресурсов растёт даже при неизменном количестве кластеров. Обычно мы оставляем достаточно свободного пространства для роста каждого кластера.
Рис. 3. Сетевая архитектура Terway
Масштабирование компонентов мастера в клиентских кластерах
У компонентов мастера разные потребности в ресурсах. Они зависят от числа узлов и pod’ов в кластере, количества нестандартных контроллеров/операторов, взаимодействующих с APIServer.
В ACK каждый клиентский кластер Kubernetes отличается по размеру и требованиям к среде выполнения. Не существует универсальной конфигурации для размещения компонентов мастера. Если мы ошибочно установим низкий лимит ресурсов крупному клиенту, то его кластер не справится с нагрузкой. Если установить консервативно высокий лимит для всех кластеров, то ресурсы потратятся впустую.
Чтобы найти тонкий компромисс между надёжностью и стоимостью, ACK использует систему типов. А именно, мы определяем три типа кластеров: малый, средний и большой. У каждого типа отдельный профиль распределения ресурсов. Тип определяется на основе загрузки компонентов мастера, количества узлов и других факторов. Тип кластера может изменяться с течением времени. ACK постоянно отслеживает эти факторы и может соответствующим образом повышать/понижать тип. После изменения типа кластера распределение ресурсов обновляется автоматически при минимальном вмешательстве пользователя.
Мы работаем над улучшением этой системы в части более мелкозернистого масштабирования и более точного обновления типов, чтобы эти изменения происходили плавнее и имели больше экономического смысла.
Рис. 4. Интеллектуальное многоступенчатое переключение типов
Эволюция клиентских кластеров в масштабе
В предыдущих разделах описаны некоторые аспекты управления большим количеством кластеров Kubernetes. Однако есть ещё одна проблема, которую необходимо решить: эволюция кластеров.
Kubernetes — это «Linux» в мире облаков. Он непрерывно обновляется и становится более модульным. Мы должны постоянно поставлять нашим клиентам новые версии, исправлять уязвимости и обновлять существующие кластеры, а также управлять большим количеством связанных компонентов (CSI, CNI, Device Plugin, Scheduler Plugin и многие другие).
В качестве примера возьмём управление компонентами Kubernetes. Для начала мы разработали централизованную систему регистрации и управления всеми этими подключаемыми компонентами.
Рис. 5. Гибкие и подключаемые компоненты
Прежде чем двигаться дальше, нужно убедиться в успешности обновления. Для этого мы разработали систему проверки работоспособности компонентов. Проверка выполняется до и после обновления.
Рис. 6. Предварительная проверка компонентов кластера
Для быстрого и надёжного обновления этих компонентов работает система непрерывного развёртывания с поддержкой частичного продвижения (grayscale), пауз и других функций. Стандартные контроллеры Kubernetes недостаточно хорошо подходят для такого использования. Поэтому для управления компонентами кластера мы разработали набор специализированных контроллеров, включая плагин и вспомогательный модуль управления (sidecar management).
Например, контроллер BroadcastJob предназначен для обновления компонентов на каждой рабочей машине или проверки узлов на каждой машине. Задание Broadcast запускает pod на каждом узле кластера, словно DaemonSet. Однако DaemonSet всегда поддерживает длительную работу pod’a, в то время как BroadcastJob сворачивает его. Контроллер Broadcast также запускает pod’ы на вновь присоединённых узлах и инициализирует узлы с необходимыми компонентами. В июне 2019 года мы открыли исходный код движка автоматизации OpenKruise, который сами используем внутри компании.
Рис. 7. OpenKurise организует выполнение задания Broadcast на всех узпах
Чтобы помочь клиентам в выборе правильных конфигураций кластеров, мы также предоставляем набор предопределённых профилей, включая профили Serverless, Edge, Windows и Bare Metal. Поскольку ландшафт расширяется, а потребности наших клиентов растут, мы добавим больше профилей, чтобы упростить утомительный процесс настройки.
Рис. 8. Продвинутые и гибкие профили кластеров для различных сценариев
Глобальная наблюдаемость по дата-центрам
Как показано ниже на рис. 9, облачная служба Alibaba Cloud Container развёрнута в двадцати регионах мира. Учитывая такой масштаб, одна из ключевых задач ACK заключается в том, чтобы легко отслеживать состояние запущенных кластеров: если клиентский кластер столкнётся с проблемой, мы сможем быстро отреагировать на ситуацию. Другими словами, нужно придумать решение, которое позволит эффективно и безопасно собирать статистику в реальном времени с клиентских кластеров во всех регионах — и визуально представлять результаты.
Рис. 9. Глобальное развёртывание службы Alibaba Cloud Container в двадцати регионах
Как и во многих системах мониторинга Kubernetes, у нас в качестве основного инструмента работает Prometheus. Для каждого метакластера агенты Prometheus собирают следующие показатели:
На рисунке 10 система мониторинга может быть разделена на три уровня:
Рис. 10. Глобальная многоуровневая архитектура мониторинга на базе механизма федерации Prometheus