OVHcloud Managed Kubernetes сертифицированный Kubernetes 1.18

OVH Blog News
Наш продукт OVH Managed Kubernetes уже более года доступен в общедоступном режиме. Отныне Kubernetes версии 1.18 сертифицирован CNCF на нашей платформе.



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

Kubernetes 1.18 состоит из 38 улучшений: 15 улучшений переходят в стабильную версию, 11 улучшений — в бета-версии и 12 — в альфа-версии.

Мы очень гордимся тем, что помогаем нашим клиентам перейти на этот очень гибкий и удивительный продукт: Kubernetes!

Давайте вместе проверим некоторые особенности этого нового выпуска.

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

Для установки или обновления kubectl: kubernetes.io/docs/tasks/tools/install-kubectl/.

Создание эфемерных контейнеров с помощью Kubectl для отладки (альфа)

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

Для получения дополнительной информации: kubernetes.io/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container

Применить на стороне сервера — бета 2

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

Эта функция может использоваться со следующим флагом при применении манифеста:
kubectl apply --server-side

Если вам нужно форсировать конфликты, вы можете использовать флаги « 
--force-conflicts
» и все.
Для получения дополнительной информации:  https://kubernetes.io/blog/2020/04/01/kubernetes-1.18-feature-server-side-apply-beta-2/

Улучшения Ingress API

В этот API есть 3 важных дополнения:

  • Новое  
    pathType
     поле, в котором можно указать, как должны быть сопоставлены входящие пути.
  • Новый  
    IngressClass
     ресурс, который может указать, как контроллеры должны реализовывать Ingress.
  • Поддержка подстановочных знаков в именах хостов.

Для получения дополнительной информации: kubernetes.io/blog/2020/04/02/improvements-to-the-ingress-api-in-kubernetes-1.18/

Обновление кластера до Kubernetes 1.18

В дополнение к автоматическим обновлениям исправлений в соответствии с политикой безопасности, которую вы выбираете на панели клиента, OVHcloud предлагает вам легко обновить кластер до Kubernetes 1.18. Давайте вместе посмотрим!

Перед обновлением кластера

Поймите свои потребности. Kubernetes следует политике поддержки N-2, что означает, что 3 последних минорных версии (в настоящее время 1.16, 1.17 и 1.18) продолжают получать исправления безопасности и ошибки, поэтому любая из этих версий с последним патчем считается «стабильной».

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

Убедитесь, что вы можете обновить



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

Например, если у вас есть 2 узла с загрузкой ЦП 50%, когда первый узел будет обновлен, второй узел возьмет на себя нагрузку первого узла, поэтому вам необходимо убедиться, что вы готовы к запуску. ваши приложения с одним узлом меньше.

Убедитесь, что у вас есть все манифесты Kubernetes в актуальном состоянии и они применимы. Непосредственное редактирование развертываний на стороне сервера — не лучшая практика.

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

Обновление вашего кластера


Перейдите в свой кластер на панели управления OVHcloud и нажмите «Обновить до следующей младшей версии Kubernetes».





Последний, но тем не менее важный

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

Поисковая система по каталогам GAIA-X - под капотом

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



Инициатива GAIA-X возникла из-за необходимости повысить осведомленность о суверенитете данных и создать надежную федеративную облачную экосистему для Европы.

В этой статье мы обсудим, как группа демонстраторов GAIA-X, состоящая из 3DS OUTSCALE, Docaposte, German Edge Cloud, Orange Business Services, OVHcloud, Scaleway и T-System, создала прототип поисковой системы по каталогам.



Одной из целей поисковой системы по каталогу было дать пользователю возможность искать и выбирать услуги, соответствующие их потребностям. Цель состоит в том, чтобы быть инклюзивным и предоставлять информацию пользователям, чтобы они могли сделать прозрачный и осознанный выбор. Информация, описанная для каждой услуги, включает, по крайней мере, все соответствующие «Правила политики», определенные руководством GAIA-X как обязательные, и набор технических описаний. «Правила политики» охватывают множество областей (защита данных, безопасность, обратимость и т. Д.) И разработаны в двух документах: один для правил политики инфраструктуры, а другой — правил политики данных и программного обеспечения.

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

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

Например, если клиент запрашивает « базу данных, соответствующую стандарту PCI-DSS для платежных услуг, размещенную в Германии в соответствии с Кодексом поведения по защите данных CISPE », интересующими объектами являются « база данных », « PCI-DSS », « Германия ». и « Защита данных CISPE ».

Но как сущности соотносятся друг с другом и как они определяются? И можно ли их классифицировать?

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



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



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

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

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

Мы использовали Gitlab с управляемой кластерной интеграцией Kubernetes и стандартными настройками конвейера CI / CD для развертывания микросервисов. Для хранения данных мы использовали графовую базу данных Neo4j.



Следующим шагом с онтологией и таксономией было заполнение базы данных.

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



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

Для расширенных запросов мы решили не раскрывать язык запросов Neo4j Cypher, а создать еще более простую грамматику синтаксического анализа, основанную на отношениях между узлами и их атрибутами. Это позволило нам реализовать поле ввода произвольной формы с автозаполнением. Мы использовали движок Parsing Expression Grammar PEG.js, используя следующую грамматику:

logical_and ::= expression "AND" logical_and
expression  ::= "NOT" expression / primary
primary     ::= "(" logical_or ")
              | rules
rules       ::= node relation node
              | node relation "ANY(" node+ ")"
              | node relation "ALL(" node+ ")“
              | node.property "=" value
              | node.property "!=" value
              | node.property "IN ANY(“ value+ “)"


Эта грамматика позволяет пользователю выражать более сложные запросы, такие как:

Service IMPLEMENTS ANY('S3', 'SWIFT') AND (Service COMPLIES_WITH 'GDPR' OR Provider LOCATED_IN 'European Economic Area')

Service.type = 'object storage' AND Service LOCATED_IN ALL('France', 'Germany')




Наконец, исходный код выпущен под лицензией BSD-3, и мы предоставляем спецификации OpenAPI, JSONSchema и JSON-LD для облегчения взаимодействия и повторного использования.



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

Бастион OVHcloud - Часть 1

OVH Blog News
Бастион? Мы говорим об инди-игре?

Не в этот раз! (хоть и хорошая игра!).



В OVHcloud изрядное количество инфраструктур построено на базе Linux. У нас много разных вкусов; таких как Debian, Ubuntu, Red Hat… и этот список можно продолжить. Однажды у нас даже был старый добрый Gentoos! Все они хранятся на голых серверах, на виртуальных машинах и повсюду в контейнерах. Если у него есть ЦП (или виртуальный ЦП), мы, вероятно, загрузили на него какой-то дистрибутив Linux. Но это еще не все. У нас также были коробки Solaris, которые позже превратились в коробки OmniOS, которые теперь превратились в блестящие коробки FreeBSD. У нас также есть много сетевых устройств, разбитых по разным конструкторам, охватывающих широкий диапазон поколений моделей.



Как вы, наверное, догадались, у нас есть разнородные системы, которые предоставляют несколько различных услуг. Но, несмотря на эту неоднородность, знаете ли вы, что у всех них общего? Да, все ping, но есть кое-что поинтереснее: ими можно управлять ssh.

Эта проблема

SSH был де-факто стандартом администратора в течение некоторого времени, заменяя устаревшие программы, такие как rlogin, которые с радостью передавали ваш пароль в виде открытого текста по сети, поэтому мы используем его постоянно, как и большинство компаний отрасли.

Есть два обычных способа его использования: либо вы просто вводите пароль своей учетной записи, когда удаленный сервер запрашивает его, что более или менее похоже rlogin(без передачи вашего пароля в виде открытого текста по сети); или вы используете аутентификацию с открытым ключом, генерируя так называемую «пару ключей», при этом закрытый ключ находится на вашем столе (или на смарт-карте), а соответствующий открытый ключ находится на удаленном сервере.

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

Парольная аутентификация

Во-первых, способ пароля. Что ж, мы все уже знаем, что пароли — отстой. Либо вы выбираете тот, который слишком легко взломать, либо вы выбираете очень сложный, который никогда не вспомните. Это заставляет вас использовать менеджер паролей, защищенный… мастер-паролем. Даже надежные парольные фразы, такие как « Correct Horse Battery Staple », в конечном итоге являются не более чем тщательно продуманным паролем. Они приносят целый ряд проблем, таких как тот факт, что они всегда подвергаются атакам грубой силы, и некоторые пользователи могут пострадать от чумы повторного использования паролей… Как системный администратор, вы никогда не спите спокойно, если знаете, что безопасность вашей системы находится всего в одном пароле. Конечно, есть способы снизить риск, такие как принудительное периодическое обновление пароля, минимальная длина и / или сложность пароля, или отключение учетной записи после нескольких сбоев и т. Д. Но вы просто возлагаете дополнительную нагрузку на своих пользователей и по-прежнему не достигается удовлетворительный уровень безопасности.

Аутентификация с открытым ключом

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

Аутентификация на основе PKI

Для полноты — потому что отсюда я слышу вас, гуру SSH! — в последних версиях серверов SSH есть третий способ, а именно аутентификация на основе PKI с доверенным центром сертификации (CA). Вы устанавливаете общедоступный сертификат своего ЦС на все свои серверы, и они будут принимать любое соединение, подтвержденное сертификатом, предоставленным указанным ЦС, полагаясь наsubjectNameсертификата. Это определяет, среди прочего, к какой учетной записи можно получить доступ на сервере. Это очень централизованный способ управления доступом, когда вся власть находится в руках того, кто контролирует ваш ЦС. Это может быть очень успешным, если делать это очень осторожно, с большим количеством процессов безопасности и процессов доставки сертификатов. Правильное управление центром сертификации — не шутка, и неправильное выполнение может сильно вас укусить. Это также было несколько недавним дополнением к OpenSSH, и, учитывая неоднородность, которую мы описали выше, это оставило бы множество систем на стороне. Есть еще одна причина, по которой мы не выбрали этот метод, но прежде чем погрузиться в него, давайте поговорим о наших потребностях.

Что нам нужно

В OVHcloud у нас есть различные технические группы, которые управляют своей собственной инфраструктурой, а не полагаются на общий внутренний ИТ-отдел. Этот принцип является частью корпоративной культуры и ДНК. У него есть свои недостатки; такие как дополнительная сложность в ведении исчерпывающего и актуального инвентаря наших собственных активов, но его преимущества намного перевешивают их: несколько команд могут выполнять итерацию быстрее, поскольку они могут использовать существующие продукты OVHcloud в качестве строительных блоков для создания новых инновационных продуктов. Однако это не должно происходить за счет безопасности, которая лежит в основе всего, что мы делаем в OVHcloud.

Но как нам удалось разработать системы безопасности для управления всеми этими серверами по SSH, не мешая различным рабочим группам?



Требуются несколько важных вещей:

  • ДЕЛЕГАЦИЯ
    • Любая централизованная «группа безопасности», отвечающая за разрешение доступа для всей компании, недопустима. Он не масштабируется, как бы вы это ни делали.
    • Менеджеры или технические руководители должны быть полностью автономными в управлении своим собственным периметром, с точки зрения серверов / систем / устройств, а также в отношении тех лиц, которым предоставлен доступ в пределах их периметра.
    • Переход члена команды в другую команду или выход из компании должен быть полностью непрерывным, независимо от того, к каким системам у этого человека был доступ (помните о неоднородности выше?).
    • Предоставление доступа новому члену команды также должно быть беспрепятственным, чтобы он мог испачкать руки как можно быстрее.
    • Временное предоставление доступа кому-либо за пределами команды (или компании) к данному активу на ограниченный период времени должно быть простым.
    • Все это должно быть автономным
  • АУДИТОРИЯ И ОТСЛЕЖИВАНИЕ
    • Каждое действие необходимо регистрировать с большим количеством деталей; будь то изменение зазора или подключение к системе; будь то успех или нет. Мы также хотим, чтобы он был доступен для некоторых SIEM .
    • Каждая терминальная сессия должна быть записана. Ага, вы правильно прочитали. Это та функция, которая вам никогда не понадобится… пока вы этого не сделаете.
    • Создание отчетов для проверки доступа должно быть простым.
  • БЕЗОПАСНОСТЬ И УСТОЙЧИВОСТЬ
    • Мы должны обеспечить большую безопасность, чем простой прямой доступ по SSH без дополнительных затрат.
    • Любой компонент, который мы должны добавить, чтобы удовлетворить эти потребности, должен быть постоянно в рабочем состоянии, даже (и особенно), когда остальная часть вашей инфраструктуры разваливается, потому что именно тогда вам понадобится SSH.

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

Войдите в бастион!

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



  • Администратор хочет подключиться к машине с именем server42
  • Он не может использовать SSH напрямую со своего корпоративного ноутбука на server42, потому что server42 защищен брандмауэром и разрешает входящие SSH-соединения только из бастионных кластеров компании
  • Вместо этого администратор запускает сеанс SSH с бастионом, используя на нем свою именную учетную запись. Его ноутбук согласовывает сеанс SSH, используя свой закрытый ключ. Это этап аутентификации: бастион гарантирует, что администратор, представляющий себя Джоном Админом, действительно является этим человеком, что возможно благодаря тому, что открытый ключ Джона Админа находится внутри его учетной записи-бастиона. Мы называем это * входящим * подключением.
  • После аутентификации Джон Админ просит бастион открыть соединение с учетной записью root на server42.
  • Бастион проверяет, разрешен ли Джон Админ доступ к учетной записи root на server42, это часть авторизации. Предположим, для этого примера, что Джон Админ действительно может подключаться к этому серверу, используя закрытый ключ бастиона его команды (подробнее об этом позже).
  • Бастион инициирует SSH-соединение с server42 от имени Джона Админа, используя закрытый ключ бастиона своей команды.
  • Брандмауэр server42 разрешает входящие SSH-соединения с бастиона, и соединение успешно согласовывается, поскольку открытый ключ бастиона группы администраторов John Admin установлен в учетной записи root server42. Мы называем это * исходящим * соединением.

Теперь у нас есть два установленных SSH-соединения: входящее соединение между администратором Джона и бастионом и выходное соединение между бастионом и server42.

Теперь происходит некоторая магия, и бастион «соединяет» эти два соединения вместе с помощью псевдотерминала (a pty) между ними. Джон Админ теперь считает, что он напрямую подключен к server42 и может взаимодействовать с ним, как если бы это было так.
Между тем, бастион может записывать все, что набирает Джон Админ (или, точнее, все, что * видит * Джон Админ, мы не будем записывать пароли, которые он набирает на noechoтерминалах!), Этим занимается ovh-ttyrecпрограмма.

Чтобы быть совершенно ясным, server42 не знает, кто такой Джон Админ, и ему это не нужно: мы отделили аутентификацию и авторизацию. Только бастиону необходимо знать и аутентифицировать администратора, удаленный сервер знает только бастион и доверяет ему (или, точнее, существование команды Джона Админа на бастионе). Это открывает целый ряд возможностей… но об этом в следующем посте!

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

OVHcloud Web Statistics: новый интерфейс статистики для вашего веб-сайта, размещенного в OVHcloud

OVH Blog News
Если вы когда-либо управляли или редактировали веб-сайт, у вас наверняка будет опыт отслеживания просмотров страниц и статистики посещений.

Если это так, то эта статья для вас! Будьте готовы вступить в 2020 год с совершенно новым интерфейсом!



Немного истории

На рынке есть несколько решений, которые помогут вам анализировать посещения вашего веб-сайта.

Существуют два метода, которые помогут вам собрать эту информацию:

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

В 2004 году, чтобы обеспечить безопасность ваших данных, мы решили использовать локальное решение под названием Urchin… но пришло время меняться!

Почему?

  • Urchin был куплен Google, и программное обеспечение больше не выпускается. Таким образом, с 2012 года он не развивался.
  • Urchin основан на Flash Player. Поддержка Flash Player прекращена, и в 2020 году он будет остановлен компанией Adobe. Поддержки для него больше не будет.
  • Это не лучший опыт.
  • Urchin не позволяет пользователям визуализировать статистику субдоменов. (пример: app.mydomain.com)



Как мы предоставляем статистику вашего сайта?

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

Что это за потребности:

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

Долгое время мы пытались избежать эффекта «придумано не здесь», потому что восстановление статистического инструмента — не наша основная работа. Поэтому мы перепробовали множество решений на рынке. Открытый исходный код или нет. Бесплатно или с лицензией. И мы не нашли решения, способного масштабировать наше количество журналов и вычислять статистику для всех веб-сайтов, которые мы размещаем!

Итак, мы решили разработать альтернативное решение и предложили его по умолчанию для всех: OVHcloud Web Statistics (или OWStats).

Так что нового?

Новый пользовательский интерфейс для быстрой визуализации наиболее актуальной статистики



Вы можете найти несколько разделов:



  • Панель управления : сводка действий в вашем домене с помощью панели управления. 
  • Браузеры : дополнительная техническая информация о различных браузерах и платформах, используемых для посещения вашего домена.
  • Геолокация : какая страна / регион посещает ваш домен (данные анонимны, поэтому это только общий обзор).
  • Запросы : Обзор самых просматриваемых страниц
  • Роботы : Анализ ботов, посещающих ваш домен
  • Статус : эволюция кода статуса и страницы с ошибками, которые следует изучить.

Было бы проще, если бы мы показали несколько картинок, не так ли?

Ну конечно бы! Здесь у вас есть:

Панель управления:



Страница геолокации:



И страницы статуса:



Некоторые цифры

Благодаря этому новому инструменту мы можем вычислять вашу статистику до 8 раз быстрее.
Мы также вычисляем 2,5 ТБ логов в день!

Хотите больше информации?

Этот пост является предварительным просмотром нашей входящей службы веб-статистики OVH. Мы вернемся к вам с дополнительными сообщениями о технических деталях по мере приближения даты выпуска!

Надежная цифровая экосистема. Он сейчас здесь! И мы вместе!

OVH Blog News
Драматический масштаб кризиса COVID-19, без сомнения, кардинально изменит наше видение мира. Неотложность ситуации радикально изменила наше социальное поведение и методы работы. Возникли региональные и международные проблемы.

Давайте рассмотрим страны, компании — целые сектора, например, сектор здравоохранения, которые сейчас так сильно пострадали. Каковы конкретные последствия таких концепций, как устойчивость, суверенитет и доверие?



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

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

Защищая нашу свободу выбора

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

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

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

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

Инициативы для надежной европейской цифровой экосистемы

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

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

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

Уже существуют различные инициативы; Я приведу три примера из тех, которые продвигают цифровой суверенитет:

  • По всей Европе существует облачный проект Gaia-X — совместная инициатива государственных органов Германии и Франции, поддерживаемая их соответствующими экосистемами. Цель этого облачного проекта — определить оси влияния надежного европейского облака. Эта европейская экосистема, объединяющая интеграторов, производителей, игроков в телекоммуникационном секторе и организации, существует и объединена сильным набором ценностей.
  • Во Франции существует Стратегический комитет промышленности, известный как Comité Stratégique de Filière (CSF). Он был инициирован Министерством финансов и промышленности, и такие игроки, как Atos, Oodrive, Outscale, OVHcloud, Scaleway и многие другие, подтвердили свою приверженность разработке надежных решений. Игроки интеграции, такие как CapGemini, GFI, Sopra и Thales, также много работали, чтобы предложить альтернативные, надежные суверенные решения.
  • Что же касается владельцев бизнеса, то мы можем оценить успех призыва к действию от 9 апреля для улучшения цифрового суверенитета в Европе и во всем мире в будущем * (по инициативе Рафаэля Ришара (Неодиа), Паскаля Гаята (Лес Cas d'OR du Digital, Les Pionniers du Digital), Матье Хуг (Тилкаль) и Ален Гарнье (Jamespot)). Он был подписан более чем 100 владельцами бизнеса (включая меня и Октава от имени OVHcloud) и доказывает, насколько важно осознавать эти темы и насколько коллективное участие является ключевым элементом совместных действий.

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

Все поняли, что сейчас самое время действовать, а не просто выявлять проблемы. Октав клаб, основатель и председатель OVHcloud, всегда упорно трудился, чтобы защитить сильные ценности, и преуспел в создании европейского чемпиона компании — единственный европейский облачный плеер, который находится в пределах топ-10 во всем мире.

Чтобы нести ответственность, мы должны действовать.

Обязательство OVHcloud инвестировать и укреплять доверие в будущее

Инвестиции в нашу надежную инфраструктуру: мы инвестируем в нашу собственную сеть из 30 центров обработки данных и в нашу собственную телекоммуникационную сеть с транзитом более 20 ТБ. Мы также инвестируем в два надежных центра обработки данных, расположенных во Франции, которые предназначены для европейских игроков с наиболее важными данными — наших государственных услуг, больниц и передовых отраслей. Наши центры обработки данных имеют самые высокие сертификаты с точки зрения безопасности (HDS, SecNumCloud в процессе, ISO / IEC 27001, 27017 и 27018, PCI DSS и т. Д.).

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

Инвестиции в энергоэффективную модель: более 15 лет OVHcloud разрабатывает технологии водяного охлаждения для своих серверов, значительно сокращая затраты на строительство и эксплуатацию, а также резко ограничивая потребление энергии.

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

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

Open Trusted Cloud — каталог проверенных решений

Мы призываем издателей программного обеспечения и SaaS сотрудничать с нами и помочь с появлением новой инициативы: Open Trusted Cloud.



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

OVHcloud гарантирует размещенные решения:

  • Выбор места для хранения и обработки данных, обеспечивающий соблюдение местного европейского законодательства.
  • Соблюдение европейского «кодекса поведения» CISPE по защите данных 1 .
  • Соблюдение «Кодекса поведения» по обратимости данных при содействии Европейской комиссии (SWIPO IaaS 2 )
  • При необходимости, соответствие требованиям для хостинга медицинских данных (сертификация HDS) и хостинга финансовых данных (соответствие SOC / ACPR / EBA и сертификация PCI-DSS) во Франции и в некоторых европейских странах.
  • И в некоторых случаях, если на решения ссылаются правильные организации, C2-хостинг для государственных услуг во Франции.

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

Присоединяйтесь к нашей инициативе Open Trusted Cloud, и вместе мы докажем, что будущее может быть согласовано с нашими ценностями!

Как развертывать готовые к облаку образы на голых серверах

OVH Blog News
Прямо сейчас OVHcloud участвует как в Cloud (на основе OpenStack), так и в BareMetal. Вот почему мы стараемся придерживаться того же подхода при развертывании операционных систем. В этой статье мы объясним, как это сделать, на примере недавно доступного дистрибутива: RedHat © Entreprise Linux.



Что такое облачный образ?

Для тех, кто не знает, готовые к облаку образы — это предустановленный дистрибутив, который поставляется в формате одного файла (RAW, QCOW2, OVF,…) и может быть загружен гипервизором, чтобы система была готова в секунд, без необходимости терпеть весь процесс установки.
Поскольку у вас может быть много разных виртуальных машин на основе этих образов, это своего рода ситуация, подходящая для всех, что делает их довольно интересными для работы.
Вы можете спросить: «Как я могу настроить такие параметры, как имя хоста, сеть, ключ ssh, на этом сервере перед загрузкой?» Здесь на помощь приходят метаданные cloud-init и instance .

Что такое метаданные cloud-init и instance ?

Cloud-init  — это решение, разработанное Canonical как «отраслевой стандартный метод множественного распространения для межплатформенной инициализации экземпляра облака» , и, насколько мы его использовали, оно работает довольно хорошо.
Cloud-init  — это служба, которая запускается при первой загрузке для изменения размера ваших разделов, настройки имени хоста, сети, передачи и выполнения сценариев, сообщения другим службам о том, что он активен, и других возможностей.
Вся эта информация хранится в метаданных экземпляра, которые могут иметь разные формы. В основном, возможно, в виде метаданных , предоставляемых облаком , в форме коллекции файлов JSON. Ниже приведен пример файла meta_data.json .

{
«ключи»: [
{
«данные»: «ssh-rsa AAAAB3NzaC1yc2AACABQCnZ0Ma2nE99GXH == jcollin@ovhcloud.com»,
«тип»: «ssh»,
«имя»: «ключ1»
}
],
«public_keys»: {
«key1»: «ssh-rsa AAAAB3NzaC1yc2AACABQCnZ0Ma2nE99GXH == jcollin@ovhcloud.com»
},
«uuid»: «12345678-1234-1234-1234-abcdefghijkl»,
«availability_zone»: «nova»,
«hostname»: «myhostname»,
«устройства»: [],
«launch_index»: 0,
«project_id»: «abcdefgh-4321-4321-1234-lkjihgfedcba»,
«name»: «myhostname»
}

Как это работает на BareMetal?

Он почти такой же, как и в облаке, только требует дополнительной работы. Работая с OpenStack, мы хотим применить облачный процесс к голым серверам. Он во многом вдохновлен Ironic, модулем OpenStack Baremetal.

Изображение

В этом примере мы будем использовать случай с недавно доступным RedHat © Entreprise Linux, и, поскольку мы можем предоставить два способа разместить его на вашем сервере, процесс примерно такой же.



Мы используем официальный готовый к облаку образ RHEL, предоставленный RedHat ©, используем его в нашей собственной фабрике шаблонов, созданной с помощью Packer и OVHcloud Public Cloud, для загрузки и предварительной установки пакетов, которые будут использоваться позже в процессе установки, например mdadm, lvm2 и другие.

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

Процесс

Чтобы установить такой образ на ваш сервер без операционной системы , мы загружаем его в образе восстановления и выполняем с ним множество операций, таких как:

  1. протирание дисков
  2. настройка разделов и RAID (если есть)
  3. создание раздела config-drive (об этом поговорим позже)
  4. монтирование всех установочных разделов во временную папку
  5. rsyncing изображения во временной папке
  6. сделать его загрузочным (позже в этой части)
  • если у дистрибутива должна быть лицензия, требуется один дополнительный шаг, например:
  1. регистрация в RedHat © Subscription Manager '
  2. перезагрузка
  3. жду телефон

config-drive

Это источник метаданных нашего экземпляра на голых серверах. Он содержит все необходимые файлы для cloud_init, чтобы установить и настроить систему при первой загрузке.
Это небольшой (1 МБ) раздел с файловой системой ISO-9660 (да, это означает, что он доступен только для чтения), который будет обнаружен облачной службой инициализации вместо стандартных meta_data .

Делаем образ загрузочным

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

  • создание 
    /etc/fstab
  • конфигурация grub с некоторыми конкретными предустановками
  • установка инструментов типа lvm2 , mdadm
  • создание 
    /boot/initramfs
    с дополнительными драйверами
  • установка grub
  • синхронизация 
    /boot/efi
    раздела

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

домашний телефон

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

Это простой скрипт, который выполнит HTTP POST для самодельной службы. Это позволяет нам узнать, что сервер наконец загружен, и что сразу после первых шагов cloud-init исходный будет ждать окончания процесса и делать вызов только тогда, когда вы можете войти на свой сервер.

Что делает все это сложным?

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



Настройка для RHEL 7 немного отличается от настройки для RHEL 8, но у вас есть те же сценарии, которые нужно применить (или не применять), когда дело доходит до лицензирования. Поскольку у нас нет возможности лицензировать RHEL, стандартным методом покупки лицензии у OVH является способ BYOL, который означает: « Принесите свою собственную лицензию» .

RedHat © это сложно?

На самом деле нет. Но у RedHat © есть стандарты, и мы должны их уважать, поэтому возникают проблемы.

Перед тем как быть в состоянии продать RedHat © Entreprise Linux на Baremetal, мы должны были удостоверить каждый наш аромат с аппаратными тестами, такие как сети, вычислительные, доступ к дискам, память, виртуализации возможностей, и многой другим. Процесс долгий, но вы должны знать, что делаете, еще лучше, потому что даже если каждый дистрибутив отличается, каждый сервер тоже.

Итак, да, мы с гордостью можем сказать, что достигли этого подвига, как и другие крупные производители.


Будущее

Как я уже говорил вам, этот процесс довольно близок к OpenStack Ironic, и, если это может быть будущее с точки зрения предоставления Baremetal как услуги, может потребоваться небольшая работа над вашим облачным образом.
И если вы готовы к этой задаче, возможно, создайте свой собственный образ, чтобы установить его на свои новые серверы, с помощью функции « Принесите свое собственное изображение», которая сейчас находится в разработке!

OVHcloud теперь доступен на платформе Cloud 66

OVH Blog News
Создание экосистемы партнерских отношений, разделяющих те же ценности, что и мы, является ключевой стратегической целью OVHcloud. В соответствии с этой целью мы рады сообщить, что теперь мы стали партнером Cloud 66. Это усиливает наше ценностное предложение по отношению к аудитории наших разработчиков. Вместе с Cloud 66 мы помогаем разработчикам работать более продуктивно, используя преимущества подхода OVHcloud SMART.



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



Что предлагает Cloud 66?



Cloud 66 предоставляет решения, которые позволяют разработчикам создавать, развертывать, запускать и управлять приложениями в любом облаке полностью автоматизированным и оптимизированным образом . Использование этих решений похоже на наличие собственной команды DevOps, которая следит за тем, чтобы серверы работали для приложений в производственной среде. Разработчики могут просто сосредоточиться на написании кода, и им не нужно беспокоиться об инфраструктуре. Cloud 66 интегрировал OVHcloud в качестве одного из поставщиков облачной инфраструктуры, где можно развертывать и запускать приложения.

Почему это должно меня беспокоить?

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

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

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

Он работает с вашими Ruby, Node или контейнерными приложениями

Давайте посмотрим на практические элементы — это помогает продемонстрировать, насколько просто развертывать приложения с Cloud 66.

Во-первых, убедитесь, что у вас есть следующее: 

  • Аккаунт Cloud 66
  • Git Repo, содержащий код вашего приложения
  • Аккаунт в OVHcloud



Допустим, вы разработчик приложения Ruby. После выбора того, что вы хотите развернуть собственное приложение, вам будет предложено выбрать фреймворк. Из-за его интуитивно понятного пользовательского интерфейса вы, вероятно, выберете «Развернуть Rails & Rack Frameworks».

Предоставьте информацию о своем приложении

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

Доступ к вашему репозиторию Git

Cloud 66 поддерживает как общедоступные, так и частные репозитории Git. Если вы используете частный репозиторий Git, вам необходимо добавить и утвердить открытый SSH-ключ Cloud 66 у своего провайдера Git:



Определение вашего приложения

Наконец, вас попросят ввести URL-адрес репозитория Git, ветку для развертывания, имя вашего приложения и среду для развертывания.



Настройка вашего приложения

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



Разверните свое приложение в OVHcloud

Чтобы использовать OVHcloud в качестве целевой среды для развертывания, просто выберите OVHcloud в раскрывающемся меню при выборе облачного провайдера.

Вам необходимо выбрать регион API (доступны США, ЕС и CA). Обратите внимание, что это не регион для развертывания, это ваш объект выставления счета. Например, если вы зарегистрировали учетную запись OVHcloud во Франции: выберите OVHcloud EU.

Введите идентификатор проекта OVH и создайте имя для своей цели развертывания.

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

Как только это будет сделано, просто нажмите « Развернуть приложение», ваше приложение будет развернуто в экземплярах Public Cloud, а ваши ресурсы будут динамически выделены Cloud 66: готово!



Кто такое Cloud 66?

Штаб-квартиры Cloud 66 находятся в Сан-Франциско и Лондоне, их миссия — повысить продуктивность разработчиков. Созданный в 2012 году, он обслуживает более 1000+ компаний в 120 странах. Компания развертывает приложения 2 миллиона раз в день для тысяч разработчиков по всему миру.

Что дальше?

Вы можете прямо сейчас начать создание учетной записи Cloud 66. Чтобы отпраздновать наше партнерство с Cloud 66, когда вы настраиваете учетную запись Cloud 66, просто используйте код: Hello-OVHcloud, и вы получите бесплатные кредиты в размере 66 долларов для использования в Cloud 66.

Мы планируем провести веб-семинар 30 июня для более глубокого знакомства с продуктами Cloud 66, чтобы вы могли увидеть и узнать, насколько просто развернуть свое приложение с Cloud 66 в OVHcloud. Будьте на связи!

Механизм интерпретации: инструмент с открытым исходным кодом для интерпретации ваших моделей в ML Serving

OVH Blog News
Контекст

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



Скорее всего, вы читали статьи о методах машинного обучения (ML) или даже использовали модели машинного обучения — возможно, это заставило вас усомниться в их использовании в производственных системах. В самом деле, даже если модель дает интересные результаты, результаты могут показаться практикам неясными. Не всегда очевидно, почему модель приняла решение, особенно когда есть много функций с различными значениями и метками. Для неопытных пользователей предсказание будет казаться волшебным. В ответ на это новая область исследований, известная как интерпретируемость, направлена ​​на демистификацию моделей черного ящика. Исследование интерпретирует объяснения прогнозов, что, в свою очередь, дает пользователям уверенность в результатах. Таким же образом подтверждается использование моделей в производстве.

Чтобы преодолеть эту проблему, мы вместе с Университетом Лилля и Центрального Лилля инициировали проект, заключающийся в разработке современных методов интерпретируемости, не зависящих от моделей.



Классификация метода изображена на рисунке выше. Во-первых, мы отделяем локальные методы от глобальных. Локальные методы объясняют один прогноз, сделанный моделью, в то время как глобальные методы исследуют поведение всех функций для набора образцов. Во-вторых, мы различаем способ представления результатов методами (например, ранжирование важности признаков, график прогнозирования воздействия для значений признаков, дерево правил и т. Д.…).

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

Механизм интерпретации

Использовать механизм интерпретируемости довольно просто. Чтобы установить инструмент, вы можете ввести его pip install interpretability-engine, а затем использовать его через интерфейс командной строки.

На этом этапе мы предполагаем, что у вас уже есть развернутая модель с токеном, URL-адресом развертывания и образцами. Затем вы можете попытаться объяснить свою модель с помощью следующей команды:

interpretability-engine --token XXX --deployment-url https://localhost:8080 --samples-path my_dataset.csv --features 0 1 2 --method 'pdp'


Примечание: 0 1 2 — это указатели характеристик

Вы также можете получить образцы, хранящиеся в хранилище объектов, с помощью swift, см .: interpretability-engine --help.

Пример в наборе данных iris

Теперь давайте попробуем конкретный пример на наборе данных радужной оболочки глаза. Мы обучили модель с помощью scikit, экспортируем ее в формат ONNX и развертываем на ML Serving, см. Документацию.

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

Примеры выглядят так (формат csv):

4.7,3.2,1.3,.2
4.6,3.1,1.5,.2
5,3.6,1.4,.2
5.4,3.9,1.7,.4
...


Примечания :

  • Каждая строка — это экземпляр, а каждый столбец — это функция.
  • Первый столбец соответствует 
    sepal.length
    , второй - 
    sepal.width
    , третий - 
    petal.length
    и последний - 
    petal.width
    .
  • Порядок функции должен соответствовать порядку функции в экспортированном формате, см. Ограничения, подробно описанные ниже.

Затем запускаем следующую команду:

interpretability-engine --token xxx --deployment-url https://xxxx.c1.gra.serving.ai.ovh.net/iris/ --samples-path iris.csv --features 0 1 2 3 --feature-names "sepal.length" "sepal.width" "petal.length" "petal.width" --label-names "setosa" "vergicolor" "virginica"


И получаем следующий рисунок:



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

Примечание: если вы хотите сохранить результат, используйте опцию--output-file you-result-filename.pdf

Ограничения и будущая работа

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

Среди них — отсутствие методов. На данный момент доступен только один глобальный метод (PDP). Мы планируем добавить дополнительные методы, более эффективные с точки зрения вычислений, такие как ALE. Мы также планируем добавить локальные методы с целью объяснения одного прогноза. Самый эффективный с точки зрения вычислений — LIME. Другие методы, такие как [Anchors] () или [SHAP] (), звучат многообещающе, но пока остаются дорогими.

Другое ограничение связано с именами функций, которые зависят от того, как вы экспортировали свою модель. Модель, обученная в scikit и экспортированная в формат ONNX, будет иметь только один вход с формой, соответствующей количеству функций. Следовательно, функции не имеют имен и основаны на их индексах. Чтобы решить эту проблему, мы позволяем пользователю сопоставлять указатель функций с именами с помощью этой опции --feature-names. Таким образом, когда объяснение экспортируется, его легче читать. Аналогичная проблема существует с этикетками, в этом случае вы можете использовать эту опцию --label-names.

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

На данный момент экспортированные результаты доступны для чтения, когда есть некоторые функции, но остается вопрос, как представить сотни функций с помощью методов PDP?

Открытый источник

Открытый исходный код является частью культуры OVHCloud, поэтому мы сделали инструмент доступным на Github. Если у вас есть какие-либо мысли по поводу улучшений, не стесняйтесь сообщить нам об этом через PR.

Ссылки

Распределенное обучение в контексте глубокого обучения

OVH Blog News


Ранее в блоге OVHcloud…

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



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



Поэтому я решил написать статью о том, как работают графические процессоры:



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



Как обсуждалось ранее, обучение нейронных сетей зависит от:

  • Входные данные
  • Архитектура нейронной сети, состоящая из «слоев»
  • Вес
  • Скорость обучения (шаг, используемый для настройки весов нейронной сети)

Зачем нам нужно распределенное обучение

Глубокое обучение в основном используется для изучения шаблонов неструктурированных данных. Неструктурированные данные — например, текстовый корпус, изображение, видео или звук — могут представлять огромный объем данных для обучения.

Обучение такой библиотеки может занять несколько дней или даже недель из-за размера данных и / или размера сети.

Можно рассмотреть несколько подходов к распределенному обучению.

Различные подходы к распределенному обучению

Когда дело доходит до глубокого обучения, существует две основные категории распределенного обучения, и обе они основаны на парадигме «разделяй и властвуй».

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

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

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

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

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

3 шпаргалки для лучшего понимания распределенного глубокого обучения

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









Теперь вам нужно выбрать стратегию распределенного обучения (с умом).

Дополнительная литература

Хотя мы многое рассмотрели в этом сообщении в блоге, мы почти не рассмотрели все аспекты распределенного обучения Deep Learning, включая предыдущую работу, историю и связанную с ней математику.
Я настоятельно рекомендую вам прочитать замечательную статью « Параллельное и распределенное глубокое обучение » Вишаха Хегде и Шимы Усмани (обе из Стэнфордского университета).
А также статью « Демистификация параллельного и распределенного глубокого обучения: углубленный анализ параллелизма», написанную Талом Бен-Нун и Торстеном Хефлером ETH Zurich, Switzerland. Я предлагаю вам начать с перехода к разделу 6.3 .

BigBlueButton

OVH Blog News
Во время кризиса Covid-19 OVHcloud старался поддерживать тесный контакт со школами и университетами и продолжать их поддерживать. Мы всегда делимся своими идеями и возможностями со студентами на ярмарках вакансий, карьерных встречах, демонстрациях технологий и практических семинарах.

В рамках этой инициативы OVHcloud предлагает школам и университетам ваучеры, которые дают студентам возможность учиться на практике. Эти ваучеры позволяют учителям создавать экземпляры Public Cloud и изучать новое программное обеспечение для виртуализации. Ваучеры также используются для заказа выделенных серверов с целью поддержки решений электронного обучения, таких как BigBlueButton. Университет ISEN Ouest занимается этим с начала кризиса Covid-19.



Коротко о BigBlueButton

BigBlueButton (BBB) ​​- это система веб-конференций, предназначенная для электронного обучения. BBB — это проект с открытым исходным кодом, начатый в 2007 году в рамках GNU LGPL. Он предоставляет широкий спектр функций видеоконференций (аудио, видео, совместное использование экрана, белая доска, запись сеанса и т. Д.) С простым и интуитивно понятным пользовательским интерфейсом. Для электронного обучения BBB расширяет свои функциональные возможности и совместимость с различными системами управления обучением (LMS); такие как Moodle, Canvas, Jenzabar, Sakai или Schoology.



BBB @ ISEN

16 марта — го, Франция вошла в строгую изоляцию, и все школы и учебные центры были закрыты. На следующий день ISEN Ouest решила, что им необходимо эффективное решение для электронного обучения своих студентов, поэтому установила BigBlueButton на выделенных серверах, размещенных в OVHcloud.

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

Чтобы ответить на этот вызов, ISEN Ouest разработал архитектуру следующим образом:

  • Один выделенный сервер Rise-1 на передней панели, настроенный как масштабируемый балансировщик нагрузки Scalelite , подключенный к среде ISEN Ouest Moodle .
  • Два выделенных сервера Infra-1 с 64 ГБ ОЗУ и гарантированной пропускной способностью 2 Гбит / с для видеоконференций BBB, а также для размещения виртуальных классов и встреч. Один сервер расположен в одном из наших центров обработки данных в Страсбурге, а другой — в Рубе — это распределяет нагрузку и обеспечивает непрерывность обслуживания в случае сбоя. 

Наконец, архитектура была построена ISEN в соответствии с архитектурой, предложенной Scalelite.



Чтобы участвовать в уроках, студенты подключаются к цифровой рабочей области, предоставляемой ISEN, и присоединяются к предварительно настроенному классу в Moodle. Они автоматически идентифицируются и добавляются в «список учащихся». Учителя берут на себя роль модераторов в классе и могут управлять своим классом со всей необходимой им автономией.

После нескольких учебных занятий, посвященных электронному обучению с помощью BBB, преподаватели ISEN могли проводить подавляющее большинство запланированных уроков (кроме тех, которые требуют практических инструментов, таких как лабораторное оборудование).

Ежедневно платформа принимает около 600 студентов и преподавателей, которые разделены между 20-40 виртуальными классами. Балансировщик нагрузки поглощает пики соединения между двумя серверами BBB и сглаживает нагрузку, которая может превышать 1 Гбит / с.

BBB @ OVHcloud

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

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

Благодаря некоторым обсуждениям с Эммануэлем, главой ISEN Nantes и бывшим менеджером учебного центра в OVHcloud, мы открыли для себя BBB и захотели попробовать.

Наш первый тест был проведен на одном выделенном сервере Infra-1:

  • Процессор: Intel Xeon-E 2274G — 4 c / 8 t — 4 ГГц / 4,9 ГГц 
  • Оперативная память: 32 ГБ
  • Накопитель: 2 × 960 Go SSD, NVMe Soft RAID 
  • Публичная сеть: 1 Гбит / с 
  • Частная сеть: 2 Гбит / с 

После этого первоначального эксперимента и благодаря упрощенным сценариям установки BBB мы установили его на инстанс публичного облака C2-60 (16 ядер; 60 Go RAM; 400 Go SSD; гарантированная пропускная способность 1 Гбит в общедоступной сети и до 4 Гбит / с. в частной сети). Это повысило устойчивость и упростило обслуживание.

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

  • Нет необходимости устанавливать программное обеспечение локально (через веб-браузер).
  • Идеальное качество звука и видео без задержки, 
  • Очень просто и удобно.
  • Доступны различные интерактивные режимы: доска, управление группами, совместное использование слайд-шоу и т. Д.
  • Легкая интеграция с Moodle. 



BBB @ #Open_Solidarity

Благодаря Worteks BigBlueButton стал одним из бесплатных инструментов, предлагаемых во время кризиса COVID19. Это возможно благодаря нашей инициативе #OpenSolidarity.

Так что, если вы учитель или инструктор, ищущий решение для электронного обучения, простое в использовании, с большим количеством функций и надежным дизайном, обратите внимание на экземпляры BBB от W'Sweet.