Одним из ключевых преимуществ использования Kubernetes является огромная экосистема вокруг него. От Rancher к Istio , от Грача до ДЕЛЕНИЯ , от gVisor к KubeDB , экосистема Kubernetes богата, живая и постоянно растет. Мы подходим к тому моменту, когда для большинства потребностей развертывания мы можем сказать, что для этого существует проект с открытым исходным кодом на основе K8s .

Одним из latests дополнений в этой экосистеме является Agones проект с открытым исходным кодом, мультиплеер, посвященный игровой сервер хостинг построен на Kubernetes, разработанный Google в сотрудничестве с Ubisoft . О проекте было объявлено в марте , и он уже наделал много шума…

В OVH Platform Team мы фанаты как онлайн-игр, так и Kubernetes, поэтому мы сказали себе, что нам нужно протестировать Agones. И что может быть лучше для его тестирования, чем развертывание в нашей службе OVH Managed Kubernetes , установка кластера игровых серверов Xonotic и участие в некоторых олдскульных смертельных матчах с коллегами?



И, конечно же, нам нужно было написать об этом, чтобы поделиться опытом…

Почему Агоны?

Agones ( происходящее от греческого слова ag, n, соревнования, проводимые во время публичных фестивалей или, в более общем смысле, «соревнование» или «соревнование в играх») призвано заменить обычные проприетарные решения для развертывания, масштабирования и управления игровыми серверами.

Agones обогащает Kubernetes настраиваемым контроллером и настраиваемым определением ресурса. С их помощью вы можете стандартизировать инструменты и API Kubernetes для создания, масштабирования и управления кластерами игровых серверов.

Постой, о каких игровых серверах ты говоришь?

Что ж, основное внимание Agones уделяется многопользовательским онлайн-играм, таким как FPS и MOBA, динамичным играм, требующим выделенных игровых серверов с малой задержкой, которые синхронизируют состояние игры между игроками и служат источником правды для игровых ситуаций.

Для таких игр требуются относительно недолговечные выделенные игровые серверы, где каждый матч выполняется на экземпляре сервера. Серверы должны иметь состояние (они должны сохранять состояние игры), при этом состояние обычно сохраняется в памяти на время матча.

Задержка — это ключевая проблема, поскольку соревновательные аспекты игр в реальном времени требуют быстрых ответов от сервера. Это означает, что подключение устройства игрока к игровому серверу должно быть максимально прямым, в идеале в обход любого промежуточного сервера, такого как балансировщик нагрузки.

А как подключить игроков к нужному серверу?

У каждого издателя игр были свои собственные проприетарные решения, но большинство из них следуют аналогичной схеме: со службой подбора игроков, которая группирует игроков в матч, взаимодействует с диспетчером кластера для предоставления выделенного экземпляра игрового сервера и отправки игрокам IP-адрес и порт, чтобы они могли напрямую подключаться к серверу и играть в игру.



Agones, его настраиваемый контроллер и настраиваемое определение ресурса заменяют сложную инфраструктуру управления кластером на стандартизированные инструменты и API на основе Kubernetes. Сервисы подбора игроков взаимодействуют с этими API для создания новых модулей игровых серверов и передачи их IP-адресов и портов заинтересованным игрокам.

Вишенка на торте

Использование Kubernetes для этих задач также дает приятный дополнительный бонус, например, возможность развернуть полную игровую инфраструктуру в среде разработчика (или даже в мини-кубе ) или легко клонировать ее для развертывания в новом центре обработки данных или облачном регионе, но также предлагая целую платформу для размещения всех дополнительных услуг, необходимых для создания игры: управление учетными записями, списки лидеров, инвентарь…

И, конечно же, простота использования платформ на базе Kubernetes, особенно когда они динамические, разнородные и распределенные, как большинство игровых онлайн-платформ.

Развертывание Agones в управляемом OVH Kubernetes

Есть несколько способов установить Agones в кластер Kubernetes. Для нашего теста мы выбрали самый простой: установку с помощью Helm.

Включение создания ресурсов RBAC

Первым шагом к установке Agones является настройка учетной записи службы с достаточными разрешениями для создания некоторых специальных типов ресурсов RBAC.

kubectl cre

kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole=cluster-admin --serviceaccount=kube-system:default

Теперь у нас есть привязка роли кластера, необходимая для установки.

Установка диаграммы Agones

Теперь продолжим, добавив репозиторий Agones в список репозиториев Helm.

helm repo add agones https://agones.dev/chart/stable

А затем установите стабильную диаграмму Agones:

helm install --name my-agones --namespace agones-system agones/agones

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

Подтверждение успешного запуска Agones

Чтобы убедиться, что Agones работает в нашем кластере Kubernetes, мы можем взглянуть на поды в agones-systemпространстве имен:

kubectl get --namespace agones-system pods

Если все в порядке, вы должны увидеть agones-controllerмодуль со статусом " Работает":

$ kubectl get --namespace agones-system pods
NAME                                 READY   STATUS    RESTARTS   AGE
agones-controller-5f766fc567-xf4vv   1/1     Running   0          5d15h
agones-ping-889c5954d-6kfj4          1/1     Running   0          5d15h
agones-ping-889c5954d-mtp4g          1/1     Running   0          5d15h

Вы также можете увидеть более подробную информацию, используя:

kubectl describe --namespace agones-system pods

Посмотрев на agones-controllerописание, вы должны увидеть что-то вроде:

$ kubectl describe --namespace agones-system pods
Name:               agones-controller-5f766fc567-xf4vv
Namespace:          agones-system
[...]
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 

Где все Conditionsдолжно иметь статус True.

Развертывание игрового сервера

Мир Agones Hello довольно скучный, простой эхо-сервер UDP, поэтому мы решили пропустить его и перейти непосредственно к чему-то более интересному: игровому серверу Xonotic.

Xonotic — это многопользовательский шутер от первого лица с открытым исходным кодом, и довольно хороший, с множеством интересных игровых режимов, карт, оружия и параметров настройки.

Развернуть игровой сервер Xonotic поверх Agones довольно просто:

kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/agones/release-0.9.0/examples/xonotic/gameserver.yaml

Развертывание игрового сервера может занять некоторое время, поэтому нам нужно дождаться его статуса, Readyпрежде чем его использовать. Мы можем получить статус с помощью:

kubectl get gameserver

Мы ждем, пока выборка не выдаст Readyстатус на нашем игровом сервере:

$ kubectl get gameserver
NAME      STATE   ADDRESS         PORT   NODE       AGE
xonotic   Ready   51.83.xxx.yyy   7094   node-zzz   5d

Когда игровой сервер готов, мы также получаем адрес и порт, который мы должны использовать для подключения к нашей игре deathmatch (в моем примере 51.83.xxx.yyy:7094).

Время фрага

Итак, теперь, когда у нас есть сервер, давайте протестируем его!

Мы загрузили клиент Xonotic для наших компьютеров (он работает в Windows, Linux и MacOS, поэтому нет оправдания) и запустили его:



Затем заходим в меню многопользовательской игры и вводим адрес и порт нашего игрового сервера:



И мы готовы играть!

А на стороне сервера?

На стороне сервера мы можем следить за тем, как идут дела на нашем игровом сервере, используя kubectl logs. Начнем с поиска модуля, в котором запущена игра:

kubectl get pods

Мы видим, что наш игровой сервер работает в модуле под названием xonotic:

$ kubectl get pods 
NAME      READY   STATUS    RESTARTS   AGE
xonotic   2/2     Running   0          5d15h

Затем мы можем использовать kubectl logsего. В модуле есть два контейнера, основной xonoticи вспомогательный Agones, поэтому мы должны указать, что нам нужны журналы xonoticконтейнера:

$ kubectl logs xonotic
Error from server (BadRequest): a container name must be specified for pod xonotic, choose one of: [xonotic agones-gameserver-sidecar]
$ kubectl logs xonotic xonotic
>>> Connecting to Agones with the SDK
>>> Starting health checking
>>> Starting wrapper for Xonotic!
>>> Path to Xonotic server script: /home/xonotic/Xonotic/server_linux.sh 
Game is Xonotic using base gamedir data
gamename for server filtering: Xonotic
Xonotic Linux 22:03:50 Mar 31 2017 - release
Current nice level is below the soft limit - cannot use niceness
Skeletal animation uses SSE code path
execing quake.rc
[...]
Authenticated connection to 109.190.xxx.yyy:42475 has been established: client is v6xt9/GlzxBH+xViJCiSf4E/SCn3Kx47aY3EJ+HOmZo=@Xon//Ks, I am /EpGZ8F@~Xon//Ks
LostInBrittany is connecting...
url_fclose: failure in crypto_uri_postbuf
Receiving player stats failed: -1
LostInBrittany connected
LostInBrittany connected
LostInBrittany is now spectating
[BOT]Eureka connected
[BOT]Hellfire connected
[BOT]Lion connected
[BOT]Scorcher connected
unconnected changed name to [BOT]Eureka
unconnected changed name to [BOT]Hellfire
unconnected changed name to [BOT]Lion
unconnected changed name to [BOT]Scorcher
[BOT]Scorcher picked up Strength
[BOT]Scorcher drew first blood! 
[BOT]Hellfire was gunned down by [BOT]Scorcher's Shotgun
[BOT]Scorcher slapped [BOT]Lion around a bit with a large Shotgun
[BOT]Scorcher was gunned down by [BOT]Eureka's Shotgun, ending their 2 frag spree
[BOT]Scorcher slapped [BOT]Lion around a bit with a large Shotgun
[BOT]Scorcher was shot to death by [BOT]Eureka's Blaster
[BOT]Hellfire slapped [BOT]Eureka around a bit with a large Shotgun, ending their 2 frag spree
[BOT]Eureka slapped [BOT]Scorcher around a bit with a large Shotgun
[BOT]Eureka was gunned down by [BOT]Hellfire's Shotgun
[BOT]Hellfire was shot to death by [BOT]Lion's Blaster, ending their 2 frag spree
[BOT]Scorcher was cooked by [BOT]Lion
[BOT]Eureka turned into hot slag
[...]

Добавить друзей…

Следующий шаг в основном доставляет удовольствие: попросить коллег подключиться к серверу и провести настоящий смертельный бой, как в Quake 2 раза.

И сейчас?

У нас есть рабочий игровой сервер, но мы едва раскрыли возможности Agones: развертывание флота (набор теплых игровых серверов, которые доступны для распределения), тестирование FleetAutoscaler (для автоматического увеличения и уменьшения флота в ответ на спроса), создавая некую фиктивную службу распределения. В следующих статьях блога мы углубимся в это и исследуем эти возможности.

И в более широком контексте мы продолжим наше исследовательское путешествие на Agones. Проект еще очень молодой, на ранней стадии альфа, но он показывает некоторые впечатляющие перспективы.

В 2017 году многие факторы способствовали значительному росту OVH: найм в Европе; приобретение компании в США; строительство 14 новых дата-центров; и начало деятельности в Азиатско-Тихоокеанском регионе. Менее чем за 18 месяцев мы удвоили количество сотрудников с двенадцати сотен до двадцати пятисот. Я не рекомендую масштабировать так быстро!

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



Один из разработанных мною инструментов имеет аббревиатуру « BFLNT ». Название не очень сексуальное, но выполняет свою работу. Я предложил использовать этот инструмент для изучения всей организации OVH, чтобы ответить на несколько простых вопросов, которые необходимо задать при наборе персонала в цифровой компании. Вот некоторые из этих вопросов: 

• Как при наборе новых команд убедиться, что мы по-прежнему строим цифровую компанию? 
• Как мы узнаем, что фокусируем наши усилия в нужном месте?  
• Как мы описываем миссию каждого сотрудника?  
• Что включает в себя трансформация бизнеса в цифровое предприятие?  
• Как эта трансформация повлияет на бизнес-модель?  

Это не единственная основа для определения структуры цифрового предприятия. Если вам известны другие подобные инструменты, не стесняйтесь делиться ими в Twitter @olesovhcom. 

B: BAU = Бизнес как обычно

В BAU мы объединяем все проекты, задачи и ежедневные действия, необходимые для выполнения процессов, необходимых для предоставления услуги, проданной клиенту. Эти бизнес-процессы остаются неизменными во времени.

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

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



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

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

Сравнение стандартной и цифровой бизнес-моделей компании показывает, что в стандартной бизнес-модели стоимость BAU пропорциональна доходу. В цифровом предприятии BAU — это фиксированная стоимость. Цифровые компании продолжают инвестировать и использовать программное обеспечение, роботов, дроны и все, что можно автоматизировать, чтобы еще больше снизить затраты. Таким образом, цифровая компания набирает сотрудников не для выполнения процессов BAU, а для их дальнейшей автоматизации.

Когда я начал OVH, я сразу захотел использовать программное обеспечение везде. Почему? Во-первых, я родился с компьютером в руках и хотел сделать коробку, в которой я мог бы кодировать сумасшедшие вещи. К тому же я запустил OVH ни с чем. В программном обеспечении я увидел решение, позволяющее делать многое с небольшими затратами и снижать затраты клиентов. С самого начала мы закодировали все бизнес-процессы. Сегодня клиент по-прежнему может зайти на сайт, заказать услугу, оплатить, а программное обеспечение настроит инфраструктуру и предоставит услугу. Нет человеческого вмешательства. Исторически наши цены были дешевле из-за такого отношения к программному обеспечению в нашей ДНК.

Однако не существует технологии, которая могла бы все автоматизировать, поэтому за пределами нашего основного бизнеса остальная часть BAU (пока) не полностью оцифрована., хотя программное обеспечение, роботы и автоматизация поддерживают каждую из следующих областей нашей работы. Служба поддержки отвечает на вопросы наших клиентов об использовании продуктов и услуг. Торговые представители слушают клиента, чтобы понять потребности клиента и выбрать правильный продукт. Заводские команды собирают серверы и отправляют их в центры обработки данных. Мы не оцифровали строительство и расширение наших центров обработки данных. Финансовые, кадровые и юридические группы необходимы для поддержки деятельности OVH. Так что даже в таких цифровых компаниях, как OVH, BAU без вмешательства человека (пока) не соответствует действительности. Мы знаем, что давление рынка, направленное на то, чтобы предлагать еще более дешевые и масштабируемые продукты, будет постоянно ставить нас под сомнение. OVH стремится к дальнейшей индустриализации, автоматизации, развитию,

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

twitter.com/olesovhcom/status/1109533124336254981?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1109533336417042432%7Ctwgr%5Eshare_3&ref_url=https%3A%2F%2Fwww.ovh.com%2Fblog%2Fthe-role-of-humans-in-digital-businesses%2F

BAU основана на идеальной компании, но мы знаем, что идеального мира не существует. По этой причине я создал еще 4 функции BFLNT: 

• F: FIX 
• L: LEAN 
• N: НОВИНКА 
• Т: ПРЕОБРАЗОВАНИЕ  

F: FIX

Поскольку невозможно предоставить BAU без сбоев, проекты, процессы и команды FIX готовы решать непредвиденные проблемы.

В OVH наши команды RUN работают над 2 миссиями 24/7:  

• Отслеживайте заказанные клиентами, предоставляемые BAU услуги и ИСПРАВЛЕНИЯ программного обеспечения, которые автоматически исправляют ошибки в программном обеспечении BAU. Команды RUN также вмешиваются, когда программное обеспечение FIX не исправляет ошибки.
• Реагируйте на клиентов, сообщающих об инцидентах, пропущенных мониторингом. Даже самый лучший мониторинг не может представить все возможные проблемы.  

Мы постоянно улучшаем наш мониторинг, исправления программного обеспечения и программное обеспечение BAU. Вскрытие процесс на месте для устранения повторяющихся проблем. Неправильное выполнение этого процесса может привести к дополнительному найму для FIX и, таким образом, к увеличению стоимости. Или снизить качество обслуживания.

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

Американские компании, вероятно, понимают важность FIX больше, чем европейские. Значительные инвестиции в FIX в эти компании связаны с FIX в их ДНК. Из-за огромной стоимости FIX американские цифровые компании стремятся увеличить объемы и выйти на мировой рынок как один из способов уменьшить влияние расходов FIX на бизнес-модель.

С девизами никогда не уступать и не сдаваться, то FIX команда цепко упорствовать. Они проводят каждый день, сосредотачиваясь на выявлении и устранении проблем. Не каждый может справиться с такой работой. Черты характера, которые мы ищем в наших командах FIX, — это позитив, радость, настойчивость, смелость и сильная ориентация на служение.

L: LEAN

Бережливое производство в цифровом контексте предполагает повышение эффективности работы программного обеспечения BAU так же, как оптимизацию работы на сборочных линиях в производстве. Это три приоритета LEAN. Во-первых, LEAN может принимать форму рефакторинга кода, оптимизации баз данных и изменения языков программирования, что позволяет быстрее выполнять программное обеспечение с меньшими вычислительными ресурсами. Во-вторых, LEAN также улучшает код для исправления ошибок, обнаруженных FIX. Наконец, команды LEAN также разрабатывают идеи, исходящие от BAU.

Члены команды LEAN — дотошные перфекционисты, работающие над теми редкими случаями проблем, которые неизбежно произойдут. Эти группы также рассматривают общие улучшения услуг, а также конкретные задачи, например, как лучше всего предоставлять услуги клиентам за 10 секунд вместо 20.

Обоснование таких небольших постепенных улучшений скорости не является защитным, потому что наши конкуренты будут делать это. Команды LEAN страстно и постоянно выходят за рамки собственных возможностей в том, что Саймон Синек называет «Бесконечной игрой». Это спорт, которому нет предела.

N: НОВИНКА

Принятие риска заложено в ДНК каждой компании. НОВОЕ для цифровых компаний обычно означает разработку нового кода, чтобы предложить клиентам новые функции, новые продукты, новые услуги, и все это для удовлетворения новых потребностей клиентов. 

Но NEW — это не только написание кода. NEW должен учитывать потребности клиентов и бизнес-модель, которая включает цену, стоимость, объем и размер рынка. Как только мы рассмотрим эти факторы, мы сосредоточимся на программном обеспечении. НОВЫМ командам требуются маркетинговые, технические и финансовые ноу-хау при разработке новых продуктов.  

НОВЫЕ команды взаимодействуют с клиентами в быстрых циклах повторяющихся процессов. Они тестируют идеи с клиентами, отказываются от неэффективных и работают с теми, которые работают. Развитие отношений с клиентами на основе доверия и сотрудничества имеет решающее значение для этого процесса. 

Компромисс и сбои также являются частью портфолио NEW Team. Клиент всегда хочет, чтобы 1 + 1 равнялось 3, и нам нужно выполнить поставку, что требует нестандартного мышления. Примером успеха OVH в этой области является охлаждение центров обработки данных, которое мы разработали в 2003 году. С самого начала мы были убеждены, что найдем способ охлаждать центры обработки данных водой, аналогично тому, как применялось жидкостное охлаждение. разработан для охлаждения автомобильных двигателей. Мы просто сказали себе, что это возможно, а затем сделали это возможным. Этот пример показывает, что цифровые компании нечасто создают действительно новые изобретения . На самом деле мы адаптируем существующие технологии в новых условиях. Это истинное значение слова взломать. 

Появление ИИ во многом разрушает индустрию программного обеспечения. НОВЫЕ и LEAN программного кода AI которые «Автоматы с »  на разработчиках .  Начало. Это отличная тема для будущего сообщения в блоге. 

Т: ПРЕОБРАЗОВАНИЕ

ТРАНСФОРМАЦИЯ бизнеса — это хорошо известный процесс. Иногда ТРАНСФОРМАЦИЯ необходима, потому что компания работает неэффективно и ее необходимо реструктурировать. Иногда ТРАНСФОРМАЦИЯ необходима, потому что компания очень успешна и растет, поэтому ей необходимо преобразовать процессы и организацию, чтобы эффективно работать в более широком масштабе.

В цифровых компаниях чаще встречается ПРЕОБРАЗОВАНИЕ к плоским трансверсальным моделям, в которых организации используют коллективный разум. У этих компаний нет роскоши платить за организационную разобщенность, борьбу с эгоизмом или медленное исполнение из-за недостатка информации. Цифровой гр ompanies га Ve  surviv ал  в их  ДНК. Представьте живое существо, созданное матерью-природой, органы которого автономны и взаимозависимы. При этом уделяется внимание вовлечению в компанию мужчин и женщин из разных стран, разных стран и способов мышления, что позволяет им эффективно работать вместе. Результат миллионов лет дарвиновской эволюции делает эти компании более органичными., Более гуманным, и более надежные , которые  помогают S им  выжить .  

Команды ТРАНСФОРМАЦИИ разделяют идеал никогда не сдаваться , но работают тихо и чутко. Они специализируются на преобразовании компании. Преобразование культуры — это первый шаг, который достигается путем слушания, объяснения и передачи смысла, тем самым помогая сотрудникам пройти через процесс ТРАНСФОРМАЦИИ. Они поощряют и успокаивают сотрудников, сохраняя при этом сосредоточенность. 

ПОДВЕДЕНИЕ

Цифровые компании уже используют LEAN, что дает возможность трансформировать BAU. Поскольку они идут рука об руку, культура также должна измениться. После автоматизации BAU центр тяжести компании должен переключиться на данные, которые, в свою очередь, изменят организацию, ее функционирование и роли отдельных лиц в компании.  

Cоздание команд BAU, FIX, LEAN, NEW и TRANSFORMATION требует понимания психологии, глубокой мотивации всех участников и поиска лучших талантов, которые могут работать вместе. В OVH около 50% команд работают над BAU, 10% над FIX, 25% над LEAN, 10% над NEW и 5% над TRANSFORMATION. Наша цель — перейти примерно к 40% на BAU, 10% на FIX, 30% на LEAN, 15% на NEW и 5% на TRANSFORMATION. 

LEAN и НОВЫЕ команды дороги. Компании должны нанимать сотрудников, которые разрабатывают программное обеспечение и которым необходимо преобразовать бизнес, его организацию и культуру. Это инвестиции в существующие производственные инструменты для лучшего будущего. Если мыслить на долгую перспективу, без этих инвестиций не обойтись. И есть много хороших новостей. Во-первых, создание групп LEAN и NEW позволяет компании переквалифицировать все эти прямые инвестиционные затраты. На уровне бюджета все эти OPEX могут быть инвестированы как CAPEX  и амортизированы в течение 5 лет. Это свидетельствует о том, что бизнес остался прибыльным, несмотря на глубокую внутреннюю трансформацию. Однако это не меняет ситуацию с денежными потоками; работникам по-прежнему нужно платить. Увеличение капитала может быть необходимо для того , чтобы иметь средствадля инвестирования  в LEAN и NEW и, таким образом, для снижения затрат на BAU. На рынке есть много игроков, которые помогают в этом. Увеличится доходность, и это хорошо в долгосрочной перспективе. 




Использование  экосистемной модели взаимозависимости еще больше сократит затраты на BAU . Конкурентное преимущество, которое американские компании имеют перед европейскими компаниями, часто объясняется скоростью и их способностью идти на риск. В Европе, склонной к риску, мы осторожны, предпочитаем действовать медленнее и сохранять контроль. На самом деле в Европе компромисс не используется, и люди предпочитают мыслить двоично: хорошее или плохое. В Европе, мы еще не видели , что решения приходят через доверие и работу с в экосистеме. 

Я по-прежнему убежден, что ни компания, ни экосистема не могут добиться успеха без доверия , которое не может существовать без страсти . Компания и экосистема по определению являются организациями, основанными на человеческих заботах. Узы доверия создаются частично благодаря пониманию собственных ограничений и готовности быть уязвимыми. Однако нелегко создавать организации, в которых уязвимость является признаком зрелости, а не признанием слабости.Это не типичный образ мышления, который сотрудники используют на работе. На самом деле часто бывает наоборот. Совершенно необходимо знать, как создать среду, которая способствует доверию и побуждает женщин и мужчин работать вместе. Доверие — основа компании, надежной, прибыльной долгосрочной экосистемы. 

Мы определенно живем в страстное время!  

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

В команде Observability мы встречаем эти фрагменты как запросы в базе данных временных рядов (TSDB), чтобы выражать непрерывные запросы, которые отвечают за автоматизацию различных вариантов использования, таких как: удаление, сведение или любая бизнес-логика, которая должна манипулировать данными временных рядов.

Мы уже представили  TSL в предыдущем сообщении блога , в котором было продемонстрировано, как наши клиенты используют доступные протоколы OVH Metrics, такие как Graphite, OpenTSDB, PromQL и WarpScript ™, но когда дело доходит до манипулирования или даже создания новых данных , у вас нет много вариантов, хотя вы можете использовать WarpScript ™ или TSL в качестве языка сценариев вместо языка запросов.

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

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

Нам нужно было решение, которое сфокусировалось бы на бизнес-логике без необходимости запускать все приложение. Таким образом, кому-то, кто хочет создать файл JSON с ежедневным отчетом (например), нужно будет только выразить соответствующий запрос.

Вы не должны FaaS!

Планирование работы — старая привычная рутина. Будь то задания bash cron, раннеры или специализированные планировщики, когда дело доходит до упаковки фрагмента кода и его периодического запуска, для этого есть название: FaaS.

FaaS был создан с простой целью: сократить время разработки. Мы могли бы найти реализацию с открытым исходным кодом для оценки (например, OpenFaas ), но большинство из них полагалось на управляемый стек контейнеров. Наличие одного контейнера на запрос было бы очень дорогостоящим, плюс разогрев контейнера для выполнения функции, а затем его замораживание было бы очень контрпродуктивным.

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

#def <Циклы>

Именно тогда мы решили создать «Loops»: платформу приложений, на которой вы можете отправить код, который хотите запустить. Вот и все. Цель состоит в том, чтобы продвинуть функцию (буквально!), А не модуль, как это делают все текущие решения FaaS:

function dailyReport(event) {
    return Promise.resolve('Today, everything is fine !')
}

Затем вы можете выполнить его вручную, используя HTTP-вызов или планировщик, подобный Cron.

Оба эти аспекта необходимы, поскольку у вас может быть (например) ежемесячный отчет, но в один прекрасный день потребуется дополнительный, через 15 дней после последнего отчета. Циклы упростят создание нового отчета вручную в дополнение к ежемесячному.

Когда мы начали создавать Loops, были некоторые необходимые ограничения:

• Эта платформа должна легко масштабироваться , чтобы поддерживать производственную нагрузку OVH.
• Он должен быть высокодоступным
• Он должен быть независимым от языка , потому что некоторые из нас предпочитают Python, а другие JavaScript.
• Это должно быть надежно
• Часть планирования не должна коррелировать с частью выполнения ( культура μService )
• Он должен быть безопасным и изолированным, чтобы любой мог размещать непонятный код на платформе.

Реализация петель

Мы решили построить нашу первую версию на V8 . Мы выбрали JavaScript в качестве первого языка, потому что его легко изучить, а асинхронными потоками данных легко управлять с помощью Promises. Кроме того, он очень хорошо сочетается с FaaS, поскольку функции Javascript очень выразительны. Мы построили его на основе нового модуля виртуальной машины NodeJS , который позволяет выполнять код в выделенном контексте V8 .

Контекст V8 похож на объект (JSON), изолированный от вашего исполнения. В контексте вы можете найти собственные функции и объекты. Однако, если вы создадите новый контекст V8, вы увидите, что некоторые переменные или функции изначально недоступны (например, setTimeout (), setInterval () или Buffer ). Если вы хотите их использовать, вам придется внедрить их в свой новый контекст. Последнее, что нужно помнить, это то, что когда у вас есть новый контекст, вы можете легко выполнить сценарий JavaScript в строковой форме.

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

Мы не хотели выполнять скрипты с eval () , поскольку вызов этой функции позволяет выполнять JS-код в основном общем контексте с вызывающим его кодом. Затем вы можете получить доступ к тем же объектам, константам, переменным и т. Д. Эта проблема безопасности стала нарушением условий сделки для новой платформы.

Теперь мы знаем, как выполнять наши скрипты, давайте реализуем для них некоторое управление. Чтобы не иметь состояния , каждый экземпляр рабочего цикла Loops (то есть движок JavaScript, способный запускать код в контексте виртуальной машины) должен иметь последнюю версию каждого цикла (цикл — это сценарий, который нужно выполнить). Это означает, что когда пользователь отправляет новый цикл, мы должны синхронизировать его с каждым рабочим циклом. Эта модель хорошо согласуется с парадигмой pub / sub, и, поскольку мы уже используем Kafka в качестве инфраструктуры pub / sub, оставалось лишь создать специальную тему и использовать ее у рабочих. В этом случае публикация включает API, в который пользователь отправляет свои циклы, которые создают событие Kafka, содержащее тело функции. Поскольку у каждого воркера есть своя группа потребителей Kafka, все они получают одинаковые сообщения.

Рабочие подписываются на обновления Loops как потребители Kafka и поддерживают хранилище Loop, которое представляет собой встроенный ключ (хэш Loop) / значение (текущая версия функции). В части API хэши цикла используются в качестве параметров URL для определения того, какой цикл выполнять. После вызова цикл извлекается из карты, затем вводится в контекст V8 , выполняется и отбрасывается. Этот механизм перезагрузки горячего кода гарантирует, что каждый цикл может быть выполнен для каждого рабочего. Мы также можем использовать возможности наших балансировщиков нагрузки для распределения нагрузки на рабочих. Эта простая модель распределения позволяет избежать сложного планирования и упрощает обслуживание всей инфраструктуры.

Для защиты от перезагрузки мы используем очень удобную функцию сжатия журналов Kafka . Сжатие журнала позволяет Kafka сохранять последнюю версию каждого сообщения с ключом. Когда пользователь создает новый цикл, ему будет присвоен уникальный идентификатор, который используется в качестве ключа сообщения Kafka. Когда пользователь обновляет цикл, это новое сообщение будет перенаправлено всем потребителям, но поскольку ключ уже существует, Kafka сохранит только последнюю версию. Когда рабочий перезапускается, он будет использовать все сообщения для восстановления своего внутреннего KV, поэтому будет восстановлено предыдущее состояние. Кафка здесь используется как постоянное хранилище .

Время выполнения циклов

Даже если базовый движок может запускать собственный Javascript, как указано выше, мы хотели, чтобы он выполнял более идиоматические запросы временных рядов, такие как TSL или WarpScript ™ . Для этого мы создали абстракцию Loops Runtime, которая оборачивает не только Javascript, но также запросы TSL и WarpScript ™ в код Javascript. Пользователи должны объявить цикл с его средой выполнения, после чего остается лишь вопрос работы оберток. Например, выполнение цикла WarpScript ™ включает в себя использование простого сценария WarpScript ™ и его отправку посредством HTTP-вызова запроса узла.

Обратная связь по петлям

Безопасное выполнение кода — это начало, но когда дело доходит до выполнения произвольного кода, также полезно получить некоторую обратную связь о состоянии выполнения . Удачно это было или нет? В функции есть ошибка? Если цикл находится в состоянии сбоя, пользователь должен быть немедленно уведомлен.

Это приводит нас к одному особому условию: скрипты пользователя должны уметь определять, все ли в порядке или нет. В базовом движке JavaScript есть два способа сделать это : обратные вызовы и обещания.
Мы выбрали Promises, который предлагает лучшее асинхронное управление. Каждый цикл возвращает обещание в конце скрипта. Отклоненное обещание приведет к статусу ошибки HTTP 500, а решенное — к статусу HTTP 200.

Планирование циклов

При публикации Loops вы можете объявить несколько триггеров аналогично Cron. Каждый триггер будет выполнять HTTP-вызов вашего цикла с дополнительными параметрами.

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

functions:
  warp_apps_by_cells:
    handler: apps-by-cells.mc2
    runtime: ws
    timeout: 30
    environment:
    events:
      - agra:
          rate: R/2018-01-01T00:00:00Z/PT5M/ET1M
          params:
            cell: ovh-a-gra
      - abhs:
          rate: R/2018-01-01T00:00:00Z/PT5M/ET1M
          params:
            cell: ovh-a-bhs

Планирование основано на Metronome, который представляет собой планировщик событий с открытым исходным кодом, с особым упором на планирование, а не на выполнение. Это идеально подходит для циклов, поскольку циклы обрабатывают выполнение, а метроном управляет вызовами выполнения.

Петли трубопроводов

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

Болевые точки: масштабирование приложения NodeJS

Рабочие циклов — это приложения NodeJS. Большинство разработчиков NodeJS знают, что NodeJS использует однопоточный цикл обработки событий . Если вы не позаботитесь о потоковой модели своего приложения nodeJS, вы, скорее всего, пострадаете из-за недостаточной производительности, поскольку будет использоваться только один поток хоста.

NodeJS также имеет доступный модуль кластера , который позволяет приложению использовать несколько потоков. Вот почему в воркере Loops мы начинаем с потока N-1 для обработки вызовов API, где N — общее количество доступных потоков, в результате чего один остается выделенным для главного потока.

Главный поток отвечает за использование тем Kafka и поддержание хранилища Loops , а рабочий поток запускает сервер API. Для каждого запрошенного выполнения цикла он запрашивает у мастера содержимое скрипта и выполняет его в выделенном потоке.

При такой настройке на каждом сервере запускается одно приложение NodeJS с одним потребителем Kafka, что позволяет очень легко масштабировать инфраструктуру, просто добавляя дополнительные серверы или облачные экземпляры.

Вывод

В этом посте мы предварительно ознакомились с Loops, масштабируемой, ориентированной на метрики FaaS с встроенной поддержкой JavaScript и расширенной поддержкой WarpScript ™ и TSL .

У нас еще есть несколько вещей, которые нужно улучшить, например импорт зависимостей в стиле ES5 и предварительный просмотр показателей для проектов циклов наших клиентов. Мы также планируем добавить больше сред выполнения , особенно WASM , что позволит использовать многие другие языки, которые могут быть ориентированы на него, например Go, Rust или Python , в соответствии с предпочтениями большинства разработчиков.

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

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

Мы объявили об этом на OVH Summit 2018… Мы собирались удвоить общедоступную пропускную способность на выделенных серверах OVH, не меняя цены.

Обещание есть обещание, поэтому несколько недель назад мы его выполнили: теперь ваши серверы имеют вдвое большую пропускную способность по той же цене!

www.ovh.com/blog/wp-content/uploads/2019/03/IMG_0185-300x218.jpg

Мы с самого начала знали, что это обновление возможно, поскольку наше сетевое ядро ​​20 Тбит / с определенно может справиться с дополнительной нагрузкой! Мы ежедневно работаем, чтобы вам было приятно пользоваться нашей сетью, которая является одной из крупнейших в мире среди хостинг-провайдеров.

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

Он также более чем способен управлять волнами DDoS-атак, которые прибывают почти ежедневно, отправляя миллионы запросов на размещенные серверы в попытке сделать их недоступными. Они поглощаются нашей внутренней защитой от DDoS-атак без какого-либо воздействия на клиента! Напоминаем, что несколько лет назад мы пострадали от одной из самых крупных атак, в результате которой был генерирован трафик более 1 Тбит / с, но, тем не менее, он был поглощен нашей инфраструктурой без какого-либо ущерба для наших клиентов.

Чтобы гарантировать эту дополнительную общедоступную полосу пропускания, наши команды по работе с сетями и Bare Metal тесно сотрудничали, чтобы быть все более и более БЕРЕМЕННЫМИ, когда дело касается нашей инфраструктуры. В результате тысячи активных устройств (маршрутизаторы, коммутаторы, серверы и т. Д.) Были обновлены полностью прозрачным образом!

Общий процесс развертывания занял некоторое время, так как мы выполнили последовательное обновление с использованием подхода QoS и изоляции для предотвращения возможных всплесков трафика. Ассортимент продуктов по ассортименту, центр обработки данных по центру обработки данных… Само развертывание было быстрым и безболезненным, поскольку оно было полностью автоматизировано. Потенциальным узким местом было убедиться, что все работает, как задумано, что включало тщательный мониторинг всей нашей серверной фермы, поскольку удвоение пропускной способности может иметь огромное влияние, особенно на OVH, где (позвольте мне еще раз упомянуть!) Исходящий трафик действительно неограничен !

Вот краткий обзор новой полосы пропускания для каждого диапазона серверов:



Даже если удвоение пропускной способности еще не покрывает весь диапазон наших диапазонов или серверов So you Start и Kimsufi, мы не забыли наших клиентов, которые используют эти серверы. Мы также обновили наши параметры пропускной способности, чтобы предложить всем нашим клиентам еще лучший сервис по еще более выгодной цене.

Но мы не собираемся останавливаться на достигнутом! Вскоре мы объявим о некоторых приятных новых функциях в сетевой части. И, конечно же, в ближайшие месяцы появится множество других инноваций. Но это другие истории, которые будут рассказаны в других сообщениях блога…

С 2000 года команды OVH самостоятельно проектируют и собирают все серверы группы OVH. Фактически, в настоящее время в эксплуатации находится 400 тыс. Серверов, а в 2018 году был собран миллионный сервер! Наши выделенные серверы являются основой всех продуктов OVHcloud. Вот почему мы хотели расширить различные линейки, чтобы улучшить общее впечатление наших клиентов.

Наши новые линейки выделенных серверов вот-вот будут запущены!

Новая линейка выделенных серверов OVH направлена ​​на то, чтобы предложить широкий выбор серверов, которые одновременно являются мощными и простыми в использовании.



В течение последних нескольких месяцев все инженерные группы, задействованные в Bare Metal Product Unit, работали над основами новых выделенных серверов и будущими предложениями. От ценностного предложения нашего портфеля до наших функциональных требований (т.е. технических строительных блоков); от нашей методологии, соблюдения нормативных требований и производственных процессов до стандартов нашего центра обработки данных и отраслевых основ — мы обратились ко всей цепочке создания стоимости! 

Это был важный и очень интересный путь, в ходе которого мы извлекли выгоду из отзывов наших клиентов , интегрировали ограничения масштабируемости и развили операционное превосходство (и наши амбиции!). И поскольку инновации — это наша движущая сила, мы хотели извлечь уроки из наших предыдущих проблем, но при этом, как всегда, использовали новаторский подход! 

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

«Но что такое« голый »сервер?»

«Голый» сервер — это просто физический сервер с одним арендатором. Это то, что отличает его от других форм вычислений, таких как виртуализация, и позволяет клиентам получить доступ к специфическим для оборудования функциям, которые иначе не могли бы быть обеспечены постоянными гарантированными ресурсами или управлялись с помощью уровня виртуализации (гибкость оборудования, данные- интенсивные проекты, вычислительная мощность и т. д.). Каждый сервер может выполнять любой объем работы для клиента или может иметь несколько одновременных пользователей, но его ресурсы полностью посвящены тому, кто его арендует, без какой-либо блокировки!

Краткий обзор производственной цепочки серверов без ОС!

Глобальный подход

Что значит развернуть новый ассортимент? Что ж, для такой компании, как OVH, где «голое железо» составляет огромную площадь в 400 тыс. Серверов в 28 центрах обработки данных — это требует большой организации…

• Отзывы клиентов и постоянное совершенствование
• Производительность и инновации
• Устойчивость и масштабируемость
• Линия продуктов и варианты использования
• Качество и бережливое производство
• Лучшее конкурентное соотношение для наших клиентов!

Эти шесть столпов были нашими ключевыми драйверами при запуске этой феноменальной программы по запуску нашей новой линейки выделенных серверов!

Давайте начнем наше новое путешествие по OVHcloud!

Первый новый модельный ряд из нашего семейства выделенных серверов уже здесь! Его имя — Advance.

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

Многие, многие новые технические функции (материнские платы, процессоры, память, диски, сети, опции и т. Д.) И преимущества встроены в новую линейку, например:

• Масштабируемая инфраструктура 
• Более высокая неограниченная пропускная способность сети 
• Бесплатная частная сеть, входящая в комплект всех серверов: vRack 
• Сетевые интерфейсы 10 Гбит / с
• Высокопроизводительные накопители NVMe (корпоративный класс) 
• Новые возможности индивидуальной настройки привода 
• Свободное место для хранения резервных копий удаленно от сервера 
• 256 дополнительных бесплатных IP-адресов 
• Лучшая защита от DDoS-атак 

Но дело не только в технических улучшениях…

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



Все это задумано. Наша цель — упростить доступность и предоставить вам лучшее, что есть в нашей отрасли, с точки зрения соотношения цены и качества.

Кроме того, мы много работали над повышением уровня качества и общей зрелости, перейдя к ключевому стандарту: ISO 27001. Потому что соответствие и качество так же важны, как и производительность! Но об этом мы поговорим в другом посте?…

А теперь следите за обновлениями, ведь это только начало! OVHcloud ускоряется для ВАС.

14 марта OVH получила сертификат ISO / IEC 27001: 2013 для системы управления информационной безопасностью выделенных серверов.



Этот сертификат, полученный после независимого аудита, проведенного компанией LNE, обеспечивает надежную уверенность для клиентов и пользователей услуг, размещенных на этих серверах.

Что такое стандарт и сертификация ISO 27001?

ISO / IEC 27001 — это международный стандарт, который описывает «требования к созданию, внедрению, поддержке и постоянному совершенствованию системы менеджмента информационной безопасности» (СМИБ). Он описывает организационный метод, который обеспечивает конфиденциальность, целостность, доступность и прослеживаемость информационной системы.

Ежедневная безопасность

С самого начала OVH безопасность была одной из основных целей групп, которые проектируют, эксплуатируют и развивают сервисы. СМИБ направлена ​​на обеспечение систематического, сопоставимого и очевидного функционирования средств, реализованных для обеспечения безопасности.

СМИБ — это подход к созданию, поддержанию, мониторингу и обеспечению постоянного улучшения инструментов и процессов для:

• Выявление и консолидация обязательств OVH с точки зрения информационной безопасности.
• Установите соответствующие, понятные и последовательные цели информационной безопасности.
• Внедрение подхода, основанного на оценке рисков, для определения и приоритизации улучшений безопасности.
• Установите, промышленно внедряйте и используйте меры безопасности.
• Общайтесь и координируйте свои действия со всеми вовлеченными внутренними и внешними заинтересованными сторонами.

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

Командные усилия

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

Сертификационный аудит

Сертификационные аудиты проводятся аккредитованными компаниями, в данном случае LNE, аккредитованными COFRAC. Сам аудит проходит в строгом формате и основан на формальных требованиях. Аудит — это вызов для команд, но также и для аудитора. На основе посещений офисов и центров обработки данных, групповых интервью, углубленного анализа документации и наблюдения за системами в течение нескольких недель аудитор должен сформулировать свое мнение об актуальности реализованных мероприятий, их эффективности и, конечно, их соответствие всем требованиям стандарта ISO 27001. Аудитор также определяет возможности улучшения, которые необходимо рассмотреть в конце аудита.

Какой объем?

Объем системы управления информационной безопасностью охватывает предоставление, подключение, оперативную поддержку и вывод из эксплуатации выделенных серверов, выделенных клиентам, ресурсы, предоставляемые клиентам для настройки, использования и мониторинга выделенной инфраструктуры и управления услугами командами OVH. Таким образом, СМИБ сконцентрирована на услугах, предоставляемых заказчику.

Безопасность как код

СУИБ охватывает все физические серверы, управляемые OVH, то есть несколько сотен тысяч серверов в центрах обработки данных группы. Понимание и управление безопасностью эффективным и устойчивым способом в таком широком диапазоне означает согласование каждого решения с принципами стандартизации и автоматизации промышленной модели OVH. В цепочке создания стоимости OVH все повторяющиеся задачи, выполняемые персоналом, должны быть постепенно сокращены. В результате СМИБ и безопасность улучшаются за счет автоматизации повседневной деятельности и разработки инструментов для безопасного управления сервисом. Вмешательство человека должно быть ограничено случаями, требующими глубокого анализа или сложной координации. Эта модель позволяет экспоненциально увеличивать масштаб системы управления при ограничении ресурсов, необходимых для ее работы.

Модульная система управления информационной безопасностью (СУИБ)

В некоторой степени все продукты OVH используют информационные системы для поддержки услуги, и сами они размещаются на выделенных серверах, как и все другие продукты OVH. Определение графика зависимостей и внутренних обязанностей — это своего рода мизансцен. Однако это было предварительным условием для определения четкой и понятной организации безопасности, которая позволила СМИБ эффективно функционировать. Был применен модульный подход, позволяющий сегментировать и структурировать обязанности каждой задействованной команды. Эти отношения регулируются набором внутренних соглашений об обслуживании, определенных и отслеживаемых в СМИБ.

Например, центры обработки данных имеют отдельную СМИБ для обеспечения физической безопасности хостинговых сайтов и безопасности операций центра обработки данных. Эта СМИБ имеет независимую сертификацию и обеспечивает прочную основу для соблюдения требований к услугам.

Сертификация ISMS выделенного сервера основана на сертификации центра обработки данных и распространяется на серверы, размещенные в этих сертифицированных центрах обработки данных. На сегодняшний день это центры обработки данных в Рубе (RBX 2,3,5,6,7), все центры обработки данных в Страсбурге, Богарнуа, Сингапуре и Сиднее. Парижский центр обработки данных (P19), на котором размещена часть информационной системы для поддержки услуги, также затрагивается, хотя в нем нет выделенных серверов, выделенных клиентам. Хотя все серверы компании охвачены СУИБ, сертификация касается только этих центров обработки данных.

Что дальше?

ISO 27001 — это общий стандарт, который решает проблемы большинства наших клиентов и устанавливает структуру и организацию для обеспечения безопасности услуг. Однако он не учитывает соблюдение требований, связанных с конкретным сектором бизнеса. Стандарт ISO 27001 предусматривает возможность добавления дополнительных требований, и для этой цели также разработана СМИБ для выделенных серверов. Таким образом, СМИБ будет постепенно интегрировать новые конкретные меры, чтобы покрыть, например, потребности в размещении персональных данных о здоровье, требования банковского сектора или нормативные особенности государственного сектора в разных странах, где OVH предоставляет услуги.

Параллельно группы работают над расширением периметра сертификации, чтобы включить в него все центры обработки данных группы, в частности центры в Эрите (Великобритания), Лимбурге (Германия), Озарове (Польша) и Гравелайнс (Франция). Цель состоит в том, чтобы предоставить всем клиентам OVH единый уровень гарантии безопасности независимо от выбранного региона центра обработки данных.

Наконец, группы продолжат работу с другими группами продуктов, чтобы завершить каталог сертифицированных продуктов и постепенно распространить его на все предложения OVH «Инфраструктура как услуга».

Поприветствуйте этого прекрасного новорожденного в GPGPU Nvidia Family Ampere

ОБНОВЛЕНИЕ БЛОГА ОТ 14 МАЯ 2020

В предыдущем выпуске …

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

Факт 1. Графические процессоры хороши для (барабанной дроби)…

Как только вы поймете, что глубокое обучение — это просто массовое параллельное умножение и сложение матриц, происходит волшебство. Графические процессоры общего назначения (GPGPU) (то есть графические процессоры или варианты графических процессоров, предназначенные для чего-то другого, кроме графической обработки) идеально подходят для…



Прекрасно, не правда ли? Но почему? Позвольте мне рассказать вам небольшую историю

Факт 2: было время, когда графические процессоры были просто графическими процессорами.

Да, Вы прочли это правильно…

Первые графические процессоры в 90-х годах были разработаны очень линейно. Инженер взял инженерный процесс, используемый для графического рендеринга, и реализовал его на оборудовании.

Для простоты вот как выглядит процесс графического рендеринга:



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

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

Короче говоря, видеокарты изначально были предназначены для графической обработки. Какой сюрприз!

Факт 3: процессоры — это спортивные автомобили, а графические процессоры — массивные грузовики

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

Это полная противоположность логике ЦП, где операции должны выполняться последовательно. В результате GPGPU нуждались в массивно-параллельной архитектуре общего назначения, чтобы иметь возможность обрабатывать все точки (вершины), строить все сетки (тесселяцию), создавать освещение, выполнять преобразование объекта из абсолютной ссылки, применять текстуру и выполнить штриховку (мне, наверное, еще не хватает некоторых частей!). Однако цель этого сообщения не состоит в том, чтобы подробно рассматривать обработку и рендеринг изображений, поскольку мы сделаем это в другом сообщении в будущем.

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

Вот красивое видео от Mythbusters, в котором объясняются две концепции CPU и GPU:

Факт 4: 2006 — NVIDIA убила тейлоризм обработки изображений

Предыдущий метод обработки изображений был реализован с использованием специализированного персонала (оборудования) на каждом этапе производственной линии на фабрике изображений.

Все изменилось в 2006 году, когда NVIDIA решила представить универсальные графические процессоры, использующие арифметические логические единицы (ALU), также известные как ядра CUDA, которые могли выполнять многоцелевые вычисления (что-то вроде вычислений на GPU Жан-Клода Ван Дамма. единицы измерения!).



Даже сегодня современные архитектуры графических процессоров (такие как Fermi, Kepler или Volta) состоят из необщих ядер, называемых модулями специальных функций (SFU), для выполнения высокопроизводительных математических графических операций, таких как sin, косинус, обратное и квадратное root, а также блоки наложения текстуры (TMU) для операций с матрицами большой размерности, участвующих в наложении текстуры изображения.

Факт 5: GPGPU можно просто объяснить с помощью Pokémon!

Поначалу может показаться, что архитектура графического процессора трудна для понимания, но поверьте мне… это не так!

Вот мой подарок вам: Pokédex, который поможет вам понять графические процессоры простым языком.

Micro-Architecture Family

Вот как вы его используете… В основном у вас есть четыре семейства карт:

Эта семья уже многим из вас будет известна. Речь, конечно же, идет о Ферми, Максвелле, Кеплере, Вольте, Ампера и т. Д.

Архитектура семьи

Это центр, где происходит волшебство: оркестровка, кеш, планирование рабочих нагрузок… Это мозг графического процессора.

Многоядерная Units (ака CUDA Cores) Семейный

Это представляет собой физическое ядро, где на самом деле происходят математические вычисления.

Программирование Модель семьи

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



Как играть?

• Начните с выбора карты из Micro-Architecture семьи
• Посмотрите на компоненты, и выберите соответствующую карту из архитектуры семьи
• Посмотрите на компоненты в семействе Micro-Architecture и выберите их из семейства Multi-Core Units , затем поместите их под карточкой « Архитектура».
• Теперь, если вы хотите знать , как программировать GPU, место Programming Model — Multi-Core Units специальную карту поверх многоядерных блоков  карт
• Наконец, поверх специальной карты Programming Model — Multi-Core Units поместите все карты Programming Model  рядом с SM.
• Тогда у вас должно получиться что-то вроде этого:

Примеры конфигураций карт:

Ферми


Кеплер


Максвелл


Паскаль


Вольта


Тьюринг


Немного поигравшись с различными микроархитектурами, архитектурами и многоядерными модулями, вы должны увидеть, что графические процессоры так же просты, как и Pokémon!

Наши коллеги из команды K8S на прошлой неделе запустили решение OVH Managed Kubernetes, в котором они управляют главными компонентами Kubernetes и создают ваши узлы поверх нашего решения Public Cloud. Я не буду описывать здесь детали того, как это работает, но в блогах уже есть много сообщений об этом ( здесь и здесь, чтобы вы начали).

В команде Prescience мы используем Kubernetes уже больше года. Наш кластер включает 40 узлов, работающих поверх PCI. Мы постоянно запускаем около 800 модулей и в результате генерируем множество показателей.

Сегодня мы рассмотрим, как мы обрабатываем эти метрики для мониторинга нашего кластера Kubernetes, и (что не менее важно!) Как это сделать с вашим собственным кластером.

Показатели OVH

Как и в любой другой инфраструктуре, вам необходимо отслеживать свой кластер Kubernetes. Вам необходимо точно знать, как ведут себя ваши узлы, кластер и приложения после их развертывания, чтобы предоставлять надежные услуги вашим клиентам. Чтобы сделать это с нашим собственным кластером, мы используем OVH Observability.

OVH Observability не зависит от серверной части, поэтому мы можем передавать метрики в одном формате и запрашивать в другом. Он может обрабатывать:

• Graphite
• InfluxDB
• Metrics2.0
• OpentTSDB
• Prometheus
• Warp10

Он также включает управляемую Grafana для отображения показателей и создания панелей мониторинга.

Узлы мониторинга

Первое, что нужно контролировать, — это состояние узлов. Все остальное начинается с этого.

Чтобы контролировать ваши узлы, мы будем использовать Noderig и Beamium, как описано здесь. Мы также будем использовать Kubernetes DaemonSets для запуска процесса на всех наших узлах.



Итак, приступим к созданию пространства имен…

kubectl create namespace metrics

Затем создайте секрет с метриками токена записи, которые вы можете найти в панели управления OVH.

kubectl create secret generic w10-credentials --from-literal=METRICS_TOKEN=your-token -n metrics

Скопируйте metrics.ymlв файл и примените конфигурацию с помощью kubectl

metrics.yml
# This will configure Beamium to scrap noderig
# And push metrics to warp 10
# We also add the HOSTNAME to the labels of the metrics pushed
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: beamium-config
  namespace: metrics
data:
  config.yaml: |
    scrapers:
      nodering:
        url: http://0.0.0.0:9100/metrics
        period: 30000
        format: sensision
        labels:
          app: nodering

    sinks:
      warp:
        url: https://warp10.gra1.metrics.ovh.net/api/v0/update
        token: $METRICS_TOKEN

    labels:
      host: $HOSTNAME

    parameters:
      log-file: /dev/stdout
---
# This is a custom collector that report the uptime of the node
apiVersion: v1
kind: ConfigMap
metadata:
  name: noderig-collector
  namespace: metrics
data:
  uptime.sh: |
    #!/bin/sh
    echo 'os.uptime' `date +%s%N | cut -b1-10` `awk '{print $1}' /proc/uptime`
---
kind: DaemonSet
apiVersion: apps/v1
metadata:
  name: metrics-daemon
  namespace: metrics
spec:
  selector:
    matchLabels:
      name: metrics-daemon
  template:
    metadata:
      labels:
        name: metrics-daemon
    spec:
      terminationGracePeriodSeconds: 10
      hostNetwork: true
      volumes:
      - name: config
        configMap:
          name: beamium-config
      - name: noderig-collector
        configMap:
          name: noderig-collector
          defaultMode: 0777
      - name: beamium-persistence
        emptyDir:{}
      containers:
      - image: ovhcom/beamium:latest
        imagePullPolicy: Always
        name: beamium
        env:
        - name: HOSTNAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        - name: TEMPLATE_CONFIG
          value: /config/config.yaml
        envFrom:
        - secretRef:
            name: w10-credentials
            optional: false
        resources:
          limits:
            cpu: "0.05"
            memory: 128Mi
          requests:
            cpu: "0.01"
            memory: 128Mi
        workingDir: /beamium
        volumeMounts:
        - mountPath: /config
          name: config
        - mountPath: /beamium
          name: beamium-persistence
      - image: ovhcom/noderig:latest
        imagePullPolicy: Always
        name: noderig
        args: ["-c", "/collectors", "--net", "3"]
        volumeMounts:
        - mountPath: /collectors/60/uptime.sh
          name: noderig-collector
          subPath: uptime.sh
        resources:
          limits:
            cpu: "0.05"
            memory: 128Mi
          requests:
            cpu: "0.01"
            memory: 128Mi

Не стесняйтесь менять уровни коллектора, если вам нужна дополнительная информация.

Затем примените конфигурацию с помощью kubectl…

$ kubectl apply -f metrics.yml
# Then, just wait a minutes for the pods to start
$ kubectl get all -n metrics
NAME                       READY   STATUS    RESTARTS   AGE
pod/metrics-daemon-2j6jh   2/2     Running   0          5m15s
pod/metrics-daemon-t6frh   2/2     Running   0          5m14s

NAME                          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE AGE
daemonset.apps/metrics-daemon 40        40        40      40           40          122d

Вы можете импортировать нашу панель управления в свою Grafana отсюда и сразу же просматривать некоторые показатели о ваших узлах.

OVH Метрики

Поскольку OVH Kube — это управляемая служба, вам не нужно контролировать apiserver, etcd или панель управления. Об этом позаботится команда OVH Kubernetes. Поэтому мы сосредоточимся на показателях cAdvisor и показателях состояния Kube.

Самым зрелым решением для динамического считывания метрик внутри Kube (на данный момент) является Prometheus.


В следующем выпуске Beamium мы сможем воспроизвести функции скребка Prometheus.


Чтобы установить сервер Prometheus, вам необходимо установить Helm в кластере…

kubectl -n kube-system create serviceaccount tiller
kubectl create clusterrolebinding tiller \
    --clusterrole cluster-admin \
    --serviceaccount=kube-system:tiller
helm init --service-account tiller

Затем вам нужно создать следующие два файла: prometheus.yml и values.yml.

# Based on https://github.com/prometheus/prometheus/blob/release-2.2/documentation/examples/prometheus-kubernetes.yml
serverFiles:
  prometheus.yml:
    remote_write:
    - url: "https://prometheus.gra1.metrics.ovh.net/remote_write"
      remote_timeout: 120s
      bearer_token: $TOKEN
      write_relabel_configs:
      # Filter metrics to keep
      - action: keep
        source_labels: [__name__]
        regex: "eagle.*|\
            kube_node_info.*|\
            kube_node_spec_taint.*|\
            container_start_time_seconds|\
            container_last_seen|\
            container_cpu_usage_seconds_total|\
            container_fs_io_time_seconds_total|\
            container_fs_write_seconds_total|\
            container_fs_usage_bytes|\
            container_fs_limit_bytes|\
            container_memory_working_set_bytes|\
            container_memory_rss|\
            container_memory_usage_bytes|\
            container_network_receive_bytes_total|\
            container_network_transmit_bytes_total|\
            machine_memory_bytes|\
            machine_cpu_cores"

    scrape_configs:
    # Scrape config for Kubelet cAdvisor.
    - job_name: 'kubernetes-cadvisor'
      scheme: https
      tls_config:
        ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
      kubernetes_sd_configs:
      - role: node
      
      relabel_configs:
      - target_label: __address__
        replacement: kubernetes.default.svc:443
      - source_labels: [__meta_kubernetes_node_name]
        regex: (.+)
        target_label: __metrics_path__
        replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor
        
      metric_relabel_configs:
      # Only keep systemd important services like docker|containerd|kubelet and kubepods,
      # We also want machine_cpu_cores that don't have id, so we need to add the name of the metric in order to be matched
      # The string will concat id with name and the separator is a ;
      # `/;container_cpu_usage_seconds_total` OK
      # `/system.slice;container_cpu_usage_seconds_total` OK
      # `/system.slice/minion.service;container_cpu_usage_seconds_total` NOK, Useless
      # `/kubepods/besteffort/e2514ad43202;container_cpu_usage_seconds_total` Best Effort POD OK
      # `/kubepods/burstable/e2514ad43202;container_cpu_usage_seconds_total` Burstable POD OK
      # `/kubepods/e2514ad43202;container_cpu_usage_seconds_total` Guaranteed POD OK
      # `/docker/pod104329ff;container_cpu_usage_seconds_total` OK, Container that run on docker but not managed by kube
      # `;machine_cpu_cores` OK, there is no id on these metrics, but we want to keep them also
      - source_labels: [id,__name__]
        regex: "^((/(system.slice(/(docker|containerd|kubelet).service)?|(kubepods|docker).*)?);.*|;(machine_cpu_cores|machine_memory_bytes))$"
        action: keep
      # Remove Useless parents keys like `/kubepods/burstable` or `/docker`
      - source_labels: [id]
        regex: "(/kubepods/burstable|/kubepods/besteffort|/kubepods|/docker)"
        action: drop
        # cAdvisor give metrics per container and sometimes it sum up per pod
        # As we already have the child, we will sum up ourselves, so we drop metrics for the POD and keep containers metrics
        # Metrics for the POD don't have container_name, so we drop if we have just the pod_name
      - source_labels: [container_name,pod_name]
        regex: ";(.+)"
        action: drop
    
    # Scrape config for service endpoints.
    - job_name: 'kubernetes-service-endpoints'
      kubernetes_sd_configs:
      - role: endpoints
      
      relabel_configs:
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
        action: replace
        target_label: __scheme__
        regex: (https?)
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
        action: replace
        target_label: __metrics_path__
        regex: (.+)
      - source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]
        action: replace
        target_label: __address__
        regex: ([^:]+)(?::\d+)?;(\d+)
        replacement: $1:$2
      - action: labelmap
        regex: __meta_kubernetes_service_label_(.+)
      - source_labels: [__meta_kubernetes_namespace]
        action: replace
        target_label: namespace
      - source_labels: [__meta_kubernetes_service_name]
        action: replace
        target_label: kubernetes_name

    # Example scrape config for pods
    #
    # The relabeling allows the actual pod scrape endpoint to be configured via the
    # following annotations:
    #
    # * `prometheus.io/scrape`: Only scrape pods that have a value of `true`
    # * `prometheus.io/path`: If the metrics path is not `/metrics` override this.
    # * `prometheus.io/port`: Scrape the pod on the indicated port instead of the
    # pod's declared ports (default is a port-free target if none are declared).
    - job_name: 'kubernetes-pods'
      kubernetes_sd_configs:
      - role: pod

      relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
        action: replace
        target_label: __metrics_path__
        regex: (.+)
      - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
        action: replace
        regex: ([^:]+)(?::\d+)?;(\d+)
        replacement: $1:$2
        target_label: __address__
      - action: labelmap
        regex: __meta_kubernetes_pod_label_(.+)
      - source_labels: [__meta_kubernetes_namespace]
        action: replace
        target_label: namespace
      - source_labels: [__meta_kubernetes_pod_name]
        action: replace
        target_label: pod_name
      - source_labels: [__meta_kubernetes_pod_node_name]
        action: replace
        target_label: host
      - action: labeldrop
        regex: (pod_template_generation|job|release|controller_revision_hash|workload_user_cattle_io_workloadselector|pod_template_hash)

values.yml
alertmanager:
  enabled: false
pushgateway:
  enabled: false
nodeExporter:
  enabled: false
server:
  ingress:
    enabled: true
    annotations:
      kubernetes.io/ingress.class: traefik
      ingress.kubernetes.io/auth-type: basic
      ingress.kubernetes.io/auth-secret: basic-auth
    hosts:
    - prometheus.domain.com
  image:
    tag: v2.7.1
  persistentVolume:
    enabled: false

Не забудьте заменить свой токен!

Скребок Прометей довольно мощный. Вы можете изменить метку своего временного ряда, оставить несколько, которые соответствуют вашему регулярному выражению, и т. Д. Эта конфигурация удаляет множество бесполезных метрик, поэтому не стесняйтесь настраивать его, если вы хотите увидеть больше метрик cAdvisor (например).

Установите его с помощью Helm…

helm install stable/prometheus \
    --namespace=metrics \
    --name=metrics \
    --values=values/values.yaml \
    --values=values/prometheus.yaml

Добавить добавить секрет базовой аутентификации…

$ htpasswd -c auth foo
New password: <bar>
New password:
Re-type new password:
Adding password for user foo
$ kubectl create secret generic basic-auth --from-file=auth -n metrics
secret "basic-auth" created

Вы можете получить доступ к интерфейсу сервера Prometheus через prometheus.domain.com.



Вы увидите все показатели для своего кластера, хотя только тот, который вы отфильтровали, будет перенесен в метрики OVH.

Интерфейсы Prometheus — хороший способ изучить ваши метрики, поскольку довольно просто отображать и контролировать вашу инфраструктуру. Вы можете найти нашу панель управления здесь.

Метрики ресурсов

Как сказал @ Martin Schneppenheim в этом посте, для правильного управления кластером Kubernetes вам также необходимо отслеживать ресурсы пода.

Мы установим Kube Eagle, который будет извлекать и предоставлять некоторые метрики о запросах и ограничениях ЦП и ОЗУ, чтобы они могли быть получены только что установленным сервером Prometheus.



Создайте файл с именем eagle.yml.

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  labels:
    app: kube-eagle
  name: kube-eagle
  namespace: kube-eagle
rules:
- apiGroups:
  - ""
  resources:
  - nodes
  - pods
  verbs:
  - get
  - list
- apiGroups:
  - metrics.k8s.io
  resources:
  - pods
  - nodes
  verbs:
  - get
  - list
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  labels:
    app: kube-eagle
  name: kube-eagle
  namespace: kube-eagle
subjects:
- kind: ServiceAccount
  name: kube-eagle
  namespace: kube-eagle
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kube-eagle
---
apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: kube-eagle
  labels:
    app: kube-eagle
  name: kube-eagle
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: kube-eagle
  name: kube-eagle
  labels:
    app: kube-eagle
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kube-eagle
  template:
    metadata:
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "8080"
        prometheus.io/path: "/metrics"
      labels:
        app: kube-eagle
    spec:
      serviceAccountName: kube-eagle
      containers:
      - name: kube-eagle
        image: "quay.io/google-cloud-tools/kube-eagle:1.0.0"
        imagePullPolicy: IfNotPresent
        env:
        - name: PORT
          value: "8080"
        ports:
        - name: http
          containerPort: 8080
          protocol: TCP
        livenessProbe:
          httpGet:
            path: /health
            port: http
        readinessProbe:
          httpGet:
            path: /health
            port: http

$ kubectl create namespace kube-eagle
$ kubectl apply -f eagle.yml

Затем добавьте импорт этой панели управления Grafana (это та же панель, что и Kube Eagle, но перенесена на Warp10).



Теперь у вас есть простой способ контролировать ресурсы вашего модуля в кластере!

Пользовательские показатели

Как Прометей узнает, что ему нужно соскрести куба-орла? Если вы посмотрите на метаданные eagle.yml, вы увидите, что:

annotations:
  prometheus.io/scrape: "true"
  prometheus.io/port: "8080" # The port where to find the metrics
  prometheus.io/path: "/metrics" # The path where to find the metrics

Эти аннотации запустят процесс автоматического обнаружения Prometheus (описанный в prometheus.ymlстроке 114).

Это означает, что вы можете легко добавить эти аннотации к модулям или службам, которые содержат экспортер Prometheus, а затем пересылать эти метрики в OVH Observability. Вы можете найти неполный список экспортеров Прометея здесь.

Объемный анализ

Как вы видели на странице prometheus.yml, мы попытались отфильтровать множество бесполезных показателей. Например, cAdvisor в новом кластере, всего с тремя настоящими производственными модулями, а также со всей системой kube и пространством имен Prometheus, имеет около 2600 метрик на узел. Используя интеллектуальный подход к очистке, вы можете сократить это количество до 126 серий.

Вот таблица, показывающая приблизительное количество метрик, которые вы создадите, в зависимости от количества узлов (N) и количества производственных модулей (P), которые у вас есть:



Например, если вы запустите три узла с 60 подами, вы сгенерируете 264 * 3 + 32 * 60 ~ = 2700 метрик.

NB: модуль имеет уникальное имя, поэтому при повторном развертывании развертывания вы будете каждый раз создавать 32 новых метрики.

(1) Метрики Noderig: os.mem / os.cpu / os.disk.fs / os.load1 / os.net.dropped (in/out) / os.net.errs (in/out) / os.net.packets (in/out) / os.net.bytes (in/out)/ os.uptime

(2) метрики узлов cAdvisor: machine_memory_bytes / machine_cpu_cores

(3) Метрики узлов состояния Kube: kube_node_info

(4) Показатели узлов Kube Eagle: eagle_node_resource_allocatable_cpu_cores / eagle_node_resource_allocatable_memory_bytes / eagle_node_resource_limits_cpu_cores / eagle_node_resource_limits_memory_bytes / eagle_node_resource_requests_cpu_cores / eagle_node_resource_requests_memory_bytes / eagle_node_resource_usage_cpu_cores / eagle_node_resource_usage_memory_bytes

(5) С помощью наших фильтров мы будем отслеживать около пяти system.slices.

(6) Показатели указываются для каждого контейнера. Pod — это набор контейнеров (минимум два): ваш контейнер + контейнер паузы для сети. Таким образом, мы можем рассматривать (2 * 10 + 6) для количества метрик в пакете. 10 показателей из cAdvisor и шесть для сети (см. Ниже) и для system.slice у нас будет 10 + 6, потому что он рассматривается как один контейнер.

(7) cAdvisor предоставит следующие показатели для каждого контейнера :container_start_time_seconds / container_last_seen / container_cpu_usage_seconds_total / container_fs_io_time_seconds_total / container_fs_write_seconds_total / container_fs_usage_bytes / container_fs_limit_bytes / container_memory_working_set_bytes / container_memory_rss / container_memory_usage_bytes

(8) cAdvisor предоставит следующие показатели для каждого интерфейса: container_network_receive_bytes_total * per interface / container_network_transmit_bytes_total * per interface

(9) kube-dns / beamium-noderig-metrics / kube-proxy / canal / metrics-server

(10) Показатели модулей Kube Eagle: eagle_pod_container_resource_limits_cpu_cores / eagle_pod_container_resource_limits_memory_bytes / eagle_pod_container_resource_requests_cpu_cores / eagle_pod_container_resource_requests_memory_bytes / eagle_pod_container_resource_usage_cpu_cores / eagle_pod_container_resource_usage_memory_bytes

Вывод

Как видите, отслеживать кластер Kubernetes с помощью OVH Observability очень просто. Вам не нужно беспокоиться о том, как и где хранить свои метрики, и вы можете сосредоточиться на использовании кластера Kubernetes для эффективной обработки бизнес-нагрузок, как это делаем мы в группе обслуживания машинного обучения.

Следующим шагом будет добавление системы предупреждений, чтобы уведомить вас, когда ваши узлы не работают (например). Для этого вы можете использовать бесплатный инструмент OVH Alert Monitoring.

В команде OVH Observability (ранее Metrics) мы собираем, обрабатываем и анализируем большую часть данных мониторинга OVH. Он представляет около 500 миллионов уникальных показателей, перемещая точки данных с постоянной скоростью 5 миллионов в секунду.

Эти данные можно классифицировать двумя способами: мониторинг хоста или приложения. Мониторинг хоста в основном основан на аппаратных счетчиках (ЦП, память, сеть, диск…), тогда как мониторинг приложений основан на сервисе и его масштабируемости (запросы, обработка, бизнес-логика…).

Мы предоставляем эту услугу для внутренних команд, которые пользуются тем же опытом, что и наши клиенты. По сути, наша служба Observability — это SaaS с уровнем совместимости (поддерживающим InfluxDB, OpenTSDB, Warp10, Prometheus и Graphite), который позволяет ему интегрироваться с большинством существующих решений. Таким образом, команде, которая привыкла к определенному инструменту или уже развернула решение для мониторинга, не нужно будет тратить много времени или усилий при переходе на полностью управляемую и масштабируемую службу: они просто выбирают токен, используют правильный конечная точка, и все готово. Кроме того, наш уровень совместимости предлагает выбор: вы можете отправить свои данные с помощью OpenTSDB, а затем запросить их в PromQL или WarpScript. Подобное комбинирование протоколов приводит к уникальной совместимости с открытым исходным кодом, которая обеспечивает большую ценность.

Scollector, Snap, Telegraf, Graphite, Collectd…

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

В OVH мы используем наборы показателей, вырезанные лазером. У каждого хоста есть определенный шаблон (веб-сервер, база данных, автоматизация…), который экспортирует заданное количество показателей, которые можно использовать для диагностики работоспособности и мониторинга производительности приложений.

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

Beamium & Noderig — Идеальная посадка

Наши требования были довольно простыми:
— Масштабируемость : мониторинг одного узла так же, как мы наблюдаем за тысячами
— Laser-Cut : собирать только релевантные метрики
— Надежность : мы хотим, чтобы метрики были доступны даже в наихудших условиях
— Просто : Несколько компонентов plug-and-play вместо сложных
— Эффективность : мы верим в беспроблемный сбор показателей

Первым решением был Beamium

Beamium обрабатывает два аспекта процесса мониторинга: данные приложения слом и показатели пересылки.

Данные приложения собираются в хорошо известном и широко используемом формате Prometheus. Мы выбрали Prometheus, поскольку в то время сообщество быстро росло, и для него было доступно множество инструментальных библиотек. В Beamium есть две ключевые концепции: источники и приемники.

Источники, из которых Beamium будет извлекать данные, — это просто конечные точки HTTP Prometheus. Это означает, что это так же просто, как предоставить конечную точку HTTP и, в конечном итоге, добавить несколько параметров. Эти данные будут направляться в приемники, что позволяет нам фильтровать их во время процесса маршрутизации между источником и приемником. Приемники — это конечные точки Warp 10 ®, куда мы можем отправлять данные.

После очистки метрики сначала сохраняются на диске, а затем направляются в приемник. Механизм переключения диска при отказе (DFO) позволяет выполнять восстановление после сбоя в сети или удаленно. Таким образом, локально мы сохраняем логику вытягивания Prometheus, но децентрализованно, и мы обращаем ее вспять, чтобы протолкнуть для подачи на платформу, которая имеет много преимуществ:

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

У нас много разных клиентов, некоторые из которых используют хранилище временных рядов для продукта Observability для управления потреблением продукта или транзакционными изменениями при лицензировании. Эти варианты использования не могут быть обработаны с помощью экземпляров Prometheus, которые лучше подходят для мониторинга на основе метрик.

Второй был Noderig

В ходе бесед с некоторыми из наших клиентов мы пришли к выводу, что существующие инструменты нуждаются в определенном уровне знаний, чтобы их можно было использовать в больших масштабах. Например, команда с кластером из 20 тыс. Узлов с Scollector в итоге получит более 10 миллионов метрик только для узлов… Фактически, в зависимости от конфигурации оборудования, Scollector будет генерировать от 350 до 1000 метрик из одного узла.

Это причина создания Noderig. Мы хотели, чтобы он был таким же простым в использовании, как экспортер узлов от Prometheus, но с более детализированным производством метрик по умолчанию.

Noderig собирает метрики ОС (ЦП, память, диск и сеть), используя семантику простого уровня. Это позволяет собирать нужное количество метрик для любого типа хоста, что особенно подходит для контейнерных сред.

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

Собранные метрики доступны через простую конечную точку отдыха, что позволяет вам видеть свои метрики в режиме реального времени и легко интегрировать их с Beamium.

Это работает?

Beamium и Noderig широко используются в OVH и поддерживают мониторинг очень больших инфраструктур. На момент написания мы собираем и храним сотни миллионов показателей с помощью этих инструментов. Так что они определенно работают!

Фактически, в настоящее время мы работаем над выпуском 2.0, который будет доработкой, включающей автообнаружение и горячую перезагрузку.

Рабочий процесс CDS — ключевая особенность платформы OVH CI / CD. Этот структурный выбор добавляет дополнительную концепцию к конвейерам и заданиям CI / CD и после более чем трех лет интенсивного использования, безусловно, является важной особенностью.



Прежде чем углубляться в полное объяснение рабочих процессов CDS, давайте рассмотрим некоторые ключевые концепции конвейеров и заданий. Эти концепции взяты из справочника 8 принципов непрерывной доставки.

Основной элемент: «Работа».

Задание состоит из шагов, которые будут выполняться последовательно. J О.Б. выполняется в специальной рабочей области (т.е. файловая система). Новое рабочее пространство назначается для каждого нового запуска задания.



Стандартная сборка работа выглядит следующим образом:



Вы можете использовать «встроенные» действия, такие как checkoutApplication, скрипт, jUnit, загрузка / скачивание артефактов.

• Действие c heckoutApplication клонирует ваш репозиторий Git
• Действие сценария выполняет вашу команду сборки как «make build».
• Действие artifactUpload загружает ранее созданные двоичные файлы
• Действие jUnit анализирует данный XML-файл в формате Junit, чтобы извлечь результаты его тестирования.

Конвейер: как организовать работу с этапами

С CDS конвейер — это не поток заданий. Трубопровод представляет собой последовательность этапов, каждый из которых содержит один или несколько рабочих мест.



Этап   представляет собой набор заданий , которые будут выполняться параллельно . Этапы выполняются последовательно, если предыдущий этап прошел успешно. 

Возьмем реальный вариант использования: конвейер, на котором построена CDS. Этот конвейер состоит из четырех этапов: 

• Этап «Build Minimal» запущен для всех веток Git. Основная цель этого этапа — скомпилировать Linux-версию двоичных файлов CDS. 
• Этап «Сборка другой ОС / Arch» запускается только  в основной ветке. На этом этапе компилируются все бинарные файлы, поддерживаемые os / arch: linux, openbsd, freebsd, darwin, windows-386, amd64 и arm.  
• Этап «Пакет» запущен для всех веток Git. На этом этапе готовится образ докера и пакет Debian.
• Наконец, запускается этап «Публикация» независимо от ветки Git. 

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

Рабочие процессы CDS: как организовать ваши конвейеры

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

Возьмем пример. Один рабочий процесс для создания и развертывания трех микросервисов:  

• Создайте каждый микросервис 
• Разверните их на подготовительной стадии 
• Запустите интеграционные тесты в тестовой среде 
• Разверните их в производственной среде, а затем повторно запустите интеграционные тесты в производственной среде.

Для строительной части существует только один конвейер для управления, который используется три раза в рабочем процессе с разными контекстами приложения / среды каждый раз. Это называется «контекст конвейера».

Любое условное ветвление рабочего процесса (например, «автоматическое развертывание в промежуточной среде, только если текущая ветвь Git является главной») может быть выполнено с помощью «условного выполнения», установленного в конвейере.



Давайте посмотрим на реальный вариант использования. Это рабочий процесс, который создает, тестирует и развертывает CDS в производственной среде в OVH ( да, CDS создает и развертывает себя! ):

1. Для каждого коммита Git запускается рабочий процесс
2. Пользовательский интерфейс упакован, все двоичные файлы подготовлены, а образы докеров созданы. Задание «UT» запускает модульные тесты. Задание «ИТ» устанавливает CDS в эфемерной среде и запускает в ней интеграционные тесты. Часть 2 автоматически запускается при всех коммитах Git.
3. В части 3 развертывается CDS в нашей подготовительной среде, а затем запускаются интеграционные тесты. Он запускается автоматически, когда текущая ветвь является главной.
4. И последнее, но не менее важное: часть 4 развертывает CDS в нашей производственной среде.

Я е есть сбой на трубопроводе, он может выглядеть следующим образом:





Но, конечно же, с помощью CDS Workflows вы не ограничены самыми сложными задачами! Эти два примера демонстрируют тот факт, что рабочие процессы позволяют создавать и развертывать согласованный набор микросервисов. Я ж вам есть потребности более простые, ваши рабочие процессы, конечно, проще.



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

Больше чем “Pipeline as Code”… “Workflow as Code”

С CDS нет никаких компромиссов. Некоторые пользователи предпочитают рисовать рабочие процессы через веб-интерфейс, другие предпочитают писать код на yaml. CDS позволяет делать и то, и другое!

Есть два способа хранить рабочие процессы: либо в базе данных CDS, либо в репозитории Git с исходным кодом. Мы называем это «Рабочий процесс как код».

Это позволяет иметь рабочий процесс в одной ветке, а затем развивать его в другой ветке. CDS создаст экземпляр рабочего процесса на лету на основе кода yaml, присутствующего в текущей ветке.

CDS — это программное обеспечение с открытым исходным кодом OVH, которое можно найти на github.com/ovh/cds, с документацией на ovh.github.io/cds.