На свой 7-й саммит OVHcloud собрал все свое сообщество на ежегодную встречу в Порт-де-Версаль, Париж. На вступительной речи, представленной основателем и председателем OVHcloud Октавом Клаба и генеральным директором Мишелем Поленом, за мероприятием следили почти 10 000 человек, посетив выставку Paris Expo или воспользовавшись видеопотоком по всему миру.

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

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

Постоянные инновации для облака SMARTer

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

Поддержка лиц, принимающих решения в сфере ИТ, в переходе на цифровые технологии с помощью Enterprise

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

Поддержка лиц, принимающих решения в сфере ИТ, в переходе на цифровые технологии с помощью Enterprise

С помощью корпоративных продуктов и решений лица, принимающие решения в области ИТ, имеют возможность защитить свои проекты цифрового перехода на основе прозрачного, обратимого, прогнозирующего и мульти-локального облака. В этом году портфель Bare Metal будет пополнен кластерами выделенных серверов на основе частной сети с гарантированной производительностью через стандартные API-интерфейсы для лучшей автоматизации. Компания будет в ближайшее время обновить свою линейку премиум настраиваемым выделенных серверов HG с последнего поколения Intel® Cascade Lake ™ и 2 - ^го поколения AMD EPYC ™ процессоров, чтобы предложить пользователям еще больше производительности и надежности. Наконец, группа реализует свою глобальную стратегию сертификации и проходит процесс квалификации SecNumCloud . 

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

С линейкой продуктов Public Cloud разработчики могут начать свою деятельность мгновенно, с гибкостью ресурсов по запросу, которые позволяют им легко и быстро регулировать использование ресурсов в соответствии со своими потребностями. Компания также остается верна своим обязательствам, используя открытые и совместимые стандарты: теперь доступно публичное облачное хранилище с поддержкой S3 API, и скоро будет завершено согласование общедоступного облака с инструментами RefStack.

Услуги общедоступного облака также расширяются во всем мире: платформа аналитических данных (ADP) теперь позволяет развертывать предварительно настроенные кластеры больших данных менее чем за час в регионах общедоступного облака в Европе, Канаде и Азиатско-Тихоокеанском регионе. Наконец, OVHcloud недавно запустила ряд частных баз данных на основе PostgreSQL, которые полностью управляются и адаптированы к производственным потребностям, чтобы пользователи могли сосредоточиться на своей основной деятельности.

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

Системные администраторы могут использовать серверные решения для построения своей инфраструктуры по лучшей цене и производительности, доступным на рынке. В этом году OVHcloud полностью изменил дизайн выделенных серверов, стремясь упростить его и сделать более универсальным. Чтобы удовлетворить требования средних предприятий, государственных учреждений и университетов к масштабируемости и производительности, OVHcloud недавно выпустила новую линейку  выделенных серверов для инфраструктуры . Вы можете использовать их для построения серверных архитектур в кластерах и управления большими базами данных. Все серверы в линейке Infrastructure оснащены новейшей технологией OVHcloud Link Aggregation (OLA )., который позволяет пользователям объединять сетевые интерфейсы каждого сервера для повышения его доступности, одновременно изолируя его от общедоступной сети и возможных угроз. Некоторые серверы в линейке Infrastructure также предоставляют расширенные функции безопасности с помощью технологии Intel® Software Guard Extensions (SGX), которая полностью изолирует код, который выполняется, и данные, которые обрабатываются. 

OVHCloud также запустит в начале 2020 года свое совершенно новое предложение виртуального частного сервера. Просто и легко масштабируется, от STARTER до ELITE. Он поставляется с такими опциями, как автоматическое резервное копирование и 99,9% SLA.

Расширение присутствия владельцев бизнеса в Интернете и делового общения с помощью решений Market

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

Наконец, как чистый игрок в инфраструктуре как услуги (IaaS), OVHcloud полагается на обширную сеть партнеров, обладающих всеми навыками, необходимыми для развертывания и обслуживания услуг для своих клиентов. Чтобы инвестировать в это, компания переработала партнерскую программу OVHcloud, чтобы лучше поддерживать цифровые преобразования компаний. Это также еще один способ, которым компания фокусируется на своей интернационализации. Программа открыта и соответствует ДНК OVHcloud, и в ее первые участники уже входят такие компании, как Thales, Capgemini и Deloitte.

OpenStack Swift — это распределенная система хранения, которую легко масштабировать по горизонтали с использованием стандартных серверов и дисков.

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



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

Как Swift хранит файлы?

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

На практике, когда объект загружен, контрольная сумма MD5 будет вычисляться на основе имени объекта. Из этой контрольной суммы будет извлечено некоторое количество битов, что даст нам номер «раздела».

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

Давайте посмотрим на пример. В этом случае мы будем использовать только 2 бита из контрольной суммы md5 (слишком мало, но рисовать гораздо проще! Всего 4 раздела)



При загрузке файла, от его имени и других элементов, мы получаем контрольную сумму md5, 72acded3acd45e4c8b6ed680854b8ab1. Если мы возьмем 2 старших бита, мы получим раздел 1.

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

При рекомендованной настройке Swift вы сохраните три идентичные копии объекта. Для одной загрузки мы создаем три реальных файла на трех разных серверах.

Политика Swift

Мы только что видели, как наиболее распространенная политика Swift — хранить идентичные копии объекта.

Это может быть немного дорого для некоторых случаев использования, и Swift также поддерживает политики «стирания кодирования».

Давайте сравним их сейчас.

«Политика реплик», которую мы только что описали. Вы можете выбрать, сколько копий объектов вы хотите сохранить.



Тип политики «кодирование стирания»



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

В OVHcloud мы используем политику 12 + 3 (12 частей от объекта и 3 вычисляемых части)

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

Почему это проблема?

В кластерах, где у нас есть комбинация политики кодирования стирания и среднего размера объекта 32 КБ, мы получим более 70 миллионов файлов * на диск *.

На сервере с 36 дисками это 2,5 миллиарда файлов.

Кластеру Swift необходимо регулярно перечислять эти файлы, чтобы:

• Подавать объект покупателям
• Обнаружение битовой гнили
• Реконструировать объект, если фрагмент был потерян из-за сбоя диска

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

В следующем посте мы увидим, как мы это решили.

В нашей серии статей о переносе инфраструктуры веб-хостинга из Парижа на Gravelines (первая из которых находится здесь ) мы не упомянули базы данных. Однако это очень важная часть, так как необходимо перенести 800 000 баз данных!

В этой новой серии публикаций мы расскажем вам о нашем опыте работы с базами данных веб-хостинга.

Как обрабатывать 800 тыс. Баз данных?

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

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

OVH предлагает два типа баз данных:

• Общие базы данных (которые мы называем SharedSQL )

• Частные базы данных (которые мы называем, как вы уже догадались, PrivateSQL)

Что такое SharedSQL?

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

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

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

Что такое PrivateSQL?

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

У каждого пользователя есть свой сервер? На самом деле, нет! Несколько лет назад мы использовали технологию Docker для контейнеризации наших баз данных, мы уже обсуждали это в этом посте: www.ovh.com/en/blog/docker-administration-databases-a-flying-ideas/. В PrivateSQL закрыто не только пространство базы данных, но и гарантировано выделенное службе ОЗУ. Это означает, что в любых обстоятельствах производительность остается неизменной.

Семь отличий!

При рассмотрении вопроса о миграции нам пришлось изучить разницу в архитектуре между Paris и Gravelines.

Что касается PrivateSQL, все было просто: нет никакой разницы, мы уже согласовали архитектуры, когда помещали их в контейнер. Перенести их было бы проще простого: нам просто нужно было переместить контейнер из точки А в точку Б.

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

Вот упрощенная схема PrivateSQL



Напротив, базы данных SharedSQL на самом деле не были согласованы. Когда мы настраивали центр обработки данных Gravelines в 2016 году, мы воспользовались гибкостью Docker, чтобы пересмотреть нашу технологию баз данных и, следовательно, адаптировать наше прежнее решение.

Небольшая сравнительная схема SharedSQL в Париже и Gravelines:

SharedSQL на Paris P19 и Gravelines:



С одной стороны (в Париже) у нас есть серверы с единой системой управления базами данных (MySQL), на которых размещено 2500 баз данных на одной машине.

С другой стороны (в Gravelines) мы добавили уровень: контейнеры Docker имеют одну и ту же систему баз данных (MySQL), на которой размещается до 250 баз данных. На каждой машине размещается по 10 контейнеров.

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

Вот что он дает:



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

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

И вдруг у нас возникла еще одна проблема миграции.

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

Что такое IPMI? Какова цель IPMI? Зачем мне нужен IPMI? Все это справедливые вопросы. В мире хостинг-провайдеров IPMI или (интерфейс интеллектуального управления платформой) используется почти так же, как «SDDC (программно-определяемый центр обработки данных)» или «IaaS (инфраструктура как услуга)», но что это означает и почему вы должны забота?

IPMI был создан в результате сотрудничества между Intel, Dell, Hewlett Packard и NEC. С момента своего создания он стал отраслевым стандартом как важное аппаратное решение, которое позволяет администраторам серверов отслеживать состояние оборудования, регистрировать данные сервера и разрешать доступ к серверу без физического доступа к серверу. Получая доступ к серверу через IPMI, вам предоставляется доступ к BIOS системы, наличие этого доступа позволяет вам установить или переустановить вашу собственную операционную систему, исправить любые ошибки в конфигурации сети или повторно включить доступ по SSH или RDP с помощью KVM (Keyboard Video Mouse) доступ к сервер.



Используя инфраструктуру OVHcloud®, вы сможете использовать IPMI и получить доступ к BIOS вашего сервера. Это позволяет вам быть эффективным администратором сервера и устранять любые проблемы, которые могут возникнуть с вашим сервером, а также устанавливать любую операционную систему, совместимую с компонентами вашего сервера.

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

Чтобы узнать больше о том, как получить доступ к IPMI из OVHcloud Manager и как установить операционную систему, использующую IPMI, обратитесь к следующим руководствам, которые шаг за шагом проведут вас через процесс: Начало работы с IPMI, Как установить ОС с IPMI.

Абстрактно

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

В этом посте мы предлагаем способ проведения экспериментов, который можно воспроизвести с помощью Kubernetes-as-a-service, управляемой платформы для выполнения распределенных вычислений вместе с другими инструментами (Argo, MinIO), которые учитывают преимущества платформы.



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

Вступление

Когда я начал свою докторскую диссертацию, я прочитал кучу статей, относящихся к той области, в которой я работаю, то есть к AutoML. Из этого исследования я понял, насколько важно хорошо проводить эксперименты, чтобы они были достоверными и проверяемыми. Я начал спрашивать своих коллег, как они проводят свои эксперименты, и у них был общий шаблон: разработайте свое решение, посмотрите на другие решения, связанные с той же проблемой, запустите каждое решение 30 раз, если оно стохастическое. с эквивалентными ресурсами и сравните свои результаты с другими решениями с помощью статистических тестов: Вилкоксона-Манна-Уитни при сравнении двух алгоритмов или теста Фридмана. Поскольку это не основная тема данной статьи, я не буду подробно останавливаться на статистических тестах.

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

Либо вам повезло и исходный код доступен, либо в публикации указан псевдокод. В этом случае вам необходимо повторно реализовать решение, чтобы можно было его протестировать и сравнить. Даже если вам повезло и есть доступный исходный код, часто отсутствует вся среда (например, точная версия пакетов, сама версия python, версия JDK и т. Д.…). Отсутствие нужной информации влияет на производительность и может потенциально искажать эксперименты. Например, новые версии пакетов, языков и т. Д. Обычно имеют лучшую оптимизацию, которую может использовать ваша реализация. Иногда бывает сложно найти версии, которые использовались практикующими.

Другая проблема — сложность настройки кластера с помощью программного обеспечения HPC (например, Slurm, Torque). Действительно, для управления таким решением требуются технические знания: настройка сети, проверка того, что каждый узел имеет зависимости, необходимые для установленных запусков, проверка того, что узлы имеют одинаковые версии библиотек и т. Д. Эти технические шаги отнимают время у исследователей, таким образом отвлеките их от основной работы. Более того, чтобы извлечь результаты, исследователи обычно делают это вручную, они извлекают различные файлы (через FTP или NFS), а затем выполняют статистические тесты, которые сохраняют вручную. Следовательно, рабочий процесс проведения эксперимента относительно дорог и ненадежен.

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

Решение

OVH предлагает Kubernetes-as-a-service, платформу управляемого кластера, где вам не нужно беспокоиться о том, как настроить кластер (добавить узел, настроить сеть и т. Д.), Поэтому я начал исследовать, как я мог бы аналогичным образом проводить эксперименты. к решениям для высокопроизводительных вычислений. Argo Workflows вышла из коробки. Этот инструмент позволяет вам определять рабочий процесс шагов, которые вы можете выполнять в своем кластере Kubernetes, когда каждый шаг заключен в контейнер, который в общих чертах называется образом. Контейнер позволяет запускать программу в определенной среде программного обеспечения (языковая версия, библиотеки, сторонние программы), дополнительно ограничивая ресурсы (время процессора, память), используемые программой.

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

Пример использования: оценка решения AutoML

Вариант использования, который мы используем в нашем исследовании, будет связан с измерением сходимости байесовской оптимизации (SMAC) по проблеме AutoML.

Для этого варианта использования мы указали рабочий процесс Argo в следующем файле yaml

Настроить инфраструктуру

Сначала мы настроим кластер Kubernetes, во-вторых, мы установим службы в нашем кластере и, наконец, проведем эксперимент.

Кластер Kubernetes

Установка кластера Kubernetes с OVH — это детская игра. Подключитесь к панели управления OVH, перейдите к Public Cloud > Managed Kubernetes Service, затем Create a Kubernetes clusterследуйте инструкциям в зависимости от ваших потребностей.

• После создания кластера:
  
  • Примите во внимание политику обновления изменений. Если вы исследователь и для выполнения вашего эксперимента требуется некоторое время, вам следует избегать обновления, которое отключило бы вашу инфраструктуру во время выполнения. Чтобы избежать такой ситуации, лучше выбрать «Минимальная недоступность» или «Не обновлять».
  • Загрузите 

    kubeconfig

    файл, он будет использоваться позже 

    kubectl

    для подключения к нашему кластеру.
  • Добавьте хотя бы один узел в свой кластер.
После установки вам понадобится kubectl  — инструмент, позволяющий управлять кластером.Если все настроено правильно, должно получиться примерно следующее:

kubectl top nodes
NAME      CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
node01   64m          3%     594Mi           11%

Установка Арго

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

curl -sSL -o /usr/local/bin/argo https://github.com/argoproj/argo/releases/download/v2.3.0/argo-linux-amd64
chmod +x /usr/local/bin/argo

Настройте учетную запись службы:

kubectl create rolebinding default-admin --clusterrole=admin --serviceaccount=default:default

Затем с клиентом попробуйте простой рабочий процесс hello-world, чтобы убедиться, что стек работает (статус: успешно):

argo submit --watch https://raw.githubusercontent.com/argoproj/argo/master/examples/hello-world.yaml
Name:                hello-world-2lx9d
Namespace:           default
ServiceAccount:      default
Status:              Succeeded
Created:             Tue Aug 13 16:51:32 +0200 (24 seconds ago)
Started:             Tue Aug 13 16:51:32 +0200 (24 seconds ago)
Finished:            Tue Aug 13 16:51:56 +0200 (now)
Duration:            24 seconds

STEP                  PODNAME            DURATION  MESSAGE
 ✔ hello-world-2lx9d  hello-world-2lx9d  23s

Вы также можете получить доступ к панели управления пользовательского интерфейса через localhost:8001:



kubectl port-forward -n argo service/argo-ui 8001:80

Настроить репозиторий артефактов (MinIO)

Артефакт — это термин, используемый Argo, он представляет собой архив, содержащий файлы, возвращаемые шагом. В нашем случае мы будем использовать эту функцию, чтобы возвращать окончательные результаты и делиться промежуточными результатами между шагами.Чтобы Artifact работал, нам нужно хранилище объектов. Если он у вас уже есть, вы можете пропустить часть установки, но все равно нужно его настроить.Как указано в руководстве, мы использовали MinIO, вот манифест для его установки ( minio-argo-artifact.install.yml):

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  # This name uniquely identifies the PVC. Will be used in deployment below.
  name: minio-pv-claim
  labels:
    app: minio-storage-claim
spec:
  # Read more about access modes here: https://kubernetes.io/docs/user-guide/persistent-volumes/#access-modes
  accessModes:
    - ReadWriteOnce
  resources:
    # This is the request for storage. Should be available in the cluster.
    requests:
      storage: 10
  # Uncomment and add storageClass specific to your requirements below. Read more https://kubernetes.io/docs/concepts/storage/persistent-volumes/#class-1
  #storageClassName:
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  # This name uniquely identifies the Deployment
  name: minio-deployment
spec:
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        # Label is used as selector in the service.
        app: minio
    spec:
      # Refer to the PVC created earlier
      volumes:
      - name: storage
        persistentVolumeClaim:
          # Name of the PVC created earlier
          claimName: minio-pv-claim
      containers:
      - name: minio
        # Pulls the default MinIO image from Docker Hub
        image: minio/minio
        args:
        - server
        - /storage
        env:
        # MinIO access key and secret key
        - name: MINIO_ACCESS_KEY
          value: "TemporaryAccessKey"
        - name: MINIO_SECRET_KEY
          value: "TemporarySecretKey"
        ports:
        - containerPort: 9000
        # Mount the volume into the pod
        volumeMounts:
        - name: storage # must match the volume name, above
          mountPath: "/storage"
---
apiVersion: v1
kind: Service
metadata:
  name: minio-service
spec:
  ports:
    - port: 9000
      targetPort: 9000
      protocol: TCP
  selector:
    app: minio

• Примечание . Измените следующие пары «ключ-значение»:
  

  • spec > resources > requests > storage > 10

     соответствуют 10 ГБ хранилища, запрошенного MinIO для кластера

  • TemporaryAccessKey

  • TemporarySecretKey

kubectl create ns minio
kubectl apply -n minio -f minio-argo-artifact.install.yml

Примечание: в качестве альтернативы вы можете установить MinIO с Helm.Теперь нам нужно настроить Argo, чтобы использовать наше хранилище объектов MinIO:

kubectl edit cm -n argo workflow-controller-configmap
...
data:
  config: |
    artifactRepository:
      s3:
        bucket: my-bucket
        endpoint: minio-service.minio:9000
        insecure: true
        # accessKeySecret and secretKeySecret are secret selectors.
        # It references the k8s secret named 'argo-artifacts'
        # which was created during the minio helm install. The keys,
        # 'accesskey' and 'secretkey', inside that secret are where the
        # actual minio credentials are stored.
        accessKeySecret:
          name: argo-artifacts
          key: accesskey
        secretKeySecret:
          name: argo-artifacts
          key: secretkey

Добавьте учетные данные:

kubectl create secret generic argo-artifacts --from-literal=accesskey="TemporaryAccessKey" --from-literal=secretkey="TemporarySecretKey"

Примечание. Используйте правильные учетные данные, указанные выше.Создайте ведро my-bucketс правами Read and writeподключившись к интерфейсу localhost:9000:



kubectl port-forward -n minio service/minio-service 9000

Убедитесь, что Argo может использовать Artifact с хранилищем объектов:

argo submit --watch https://raw.githubusercontent.com/argoproj/argo/master/examples/artifact-passing.yaml
Name:                artifact-passing-qzgxj
Namespace:           default
ServiceAccount:      default
Status:              Succeeded
Created:             Wed Aug 14 15:36:03 +0200 (13 seconds ago)
Started:             Wed Aug 14 15:36:03 +0200 (13 seconds ago)
Finished:            Wed Aug 14 15:36:16 +0200 (now)
Duration:            13 seconds

STEP                       PODNAME                            DURATION  MESSAGE
 ✔ artifact-passing-qzgxj
 ├---✔ generate-artifact   artifact-passing-qzgxj-4183565942  5s
 └---✔ consume-artifact    artifact-passing-qzgxj-3706021078  7s

Примечание: если вы застряли с сообщением ContainerCreating, есть большая вероятность, что Argo не сможет получить доступ к MinIO, например, из-за неверных учетных данных.

Установить частный реестр

Теперь, когда у нас есть способ запустить рабочий процесс, мы хотим, чтобы каждый шаг представлял конкретную программную среду (то есть изображение). Мы определили эту среду в Dockerfile.Поскольку каждый шаг может выполняться на разных узлах в нашем кластере, образ необходимо где-то хранить, в случае Docker нам требуется частный реестр.Получить приватный реестр можно разными способами:
• Докер Хаб
• Gitlab.com
• OVH - учебник
• Harbour : позволяет иметь собственный реестр в кластере Kubernetes.
В нашем случае мы использовали частный реестр OVH.

# First we clone the repository
git clone git@gitlab.com:automl/automl-smac-vanilla.git
cd automl-smac-vanilla

# We build the image locally
docker build -t asv-environment:latest .

# We push the image to our private registry
docker login REGISTRY_SERVER -u REGISTRY_USERNAME
docker tag asv-environment:latest REGISTRY_IMAGE_PATH:latest
docker push REGISTRY_IMAGE_PATH:latest

Разрешите нашему кластеру извлекать образы из реестра:

kubectl create secret docker-registry docker-credentials --docker-server=REGISTRY_SERVER --docker-username=REGISTRY_USERNAME --docker-password=REGISTRY_PWD

Попробуйте наш эксперимент на инфраструктуре

git clone git@gitlab.com:automl/automl-smac-vanilla.git
cd automl-smac-vanilla

argo submit --watch misc/workflow-argo -p image=REGISTRY_IMAGE_PATH:latest -p git_ref=master -p dataset=iris
Name:                automl-benchmark-xlbbg
Namespace:           default
ServiceAccount:      default
Status:              Succeeded
Created:             Tue Aug 20 12:25:40 +0000 (13 minutes ago)
Started:             Tue Aug 20 12:25:40 +0000 (13 minutes ago)
Finished:            Tue Aug 20 12:39:29 +0000 (now)
Duration:            13 minutes 49 seconds
Parameters:
  image:             m1uuklj3.gra5.container-registry.ovh.net/automl/asv-environment:latest
  dataset:           iris
  git_ref:           master
  cutoff_time:       300
  number_of_evaluations: 100
  train_size_ratio:  0.75
  number_of_candidates_per_group: 10

STEP                       PODNAME                            DURATION  MESSAGE
 ✔ automl-benchmark-xlbbg
 ├---✔ pre-run             automl-benchmark-xlbbg-692822110   2m
 ├-·-✔ run(0:42)           automl-benchmark-xlbbg-1485809288  11m
 | └-✔ run(1:24)           automl-benchmark-xlbbg-2740257143  9m
 ├---✔ merge               automl-benchmark-xlbbg-232293281   9s
 └---✔ plot                automl-benchmark-xlbbg-1373531915  10s

Примечание :
• Здесь у нас всего 2 параллельных прогона, вы можете получить гораздо больше, добавив их в список 

  withItems

   . В нашем случае список соответствует семенам.

• run(1:24)

  соответствуют пробегу 

  1

  с семенами

  24

• Мы ограничиваем ресурсы на запуск, используя запросы и ограничения , см. Также Управление вычислительными ресурсами .
Затем мы просто получаем результаты через веб-интерфейс пользователя MinIO localhost:9000(вы также можете сделать это с помощью клиента ).

Результаты находятся в каталоге с тем же именем, что и имя рабочего процесса argo, в нашем примере это так my-bucket > automl-benchmark-xlbbg.



Ограничение нашего решения

Решение не может выполнять параллельные шаги на нескольких узлах. Это ограничение связано с тем, как мы объединяем наши результаты от параллельных шагов к шагу слияния. Мы используем volumeClaimTemplates, то есть монтируем том, и это невозможно сделать между разными узлами. Проблему можно решить двумя способами:
• Использование параллельных артефактов и их агрегирование, однако это постоянная проблема с Argo
• Непосредственно реализовать в коде вашего запуска способ сохранить результат в доступном хранилище (например, MinIO SDK )
Первый способ предпочтительнее, это означает, что вам не нужно изменять и настраивать код для конкретной файловой системы хранилища.

Советы по улучшению решения

Если вы хотите продолжить настройку, вам следует изучить следующие темы:
• Контроль доступа : чтобы ограничить пользователей в разных пространствах (по соображениям безопасности или для контроля ресурсов).
• Исследуя селектор Арго и селектор Kubernetes : в случае , если у вас есть кластер состоит из узлов , которые имеют различное оборудование , и что вам требуется эксперимент с использованием конкретного оборудования (например, конкретный процессор, графический процессор).
• Настройте распределенный MinIO : он гарантирует, что ваши данные будут реплицированы на несколько узлов и останутся доступными в случае отказа узла.
• Мониторинг вашего кластера .

Вывод

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

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



Совместное исследование в OVH через диссертацию

Тезис CIFRE означает на французском языке « Convention Industrielle de Formation par la Recherche», буквально « Промышленная конвенция для обучения через исследования». Цель состоит в том, чтобы поощрять исследовательское сотрудничество между частными и государственными организациями. Для предпринимателей и аспирантов CIFRE — это средство обучения посредством исследований и приобретения серьезных научных знаний. Для ученых это средство управления новым кандидатом наук и применения результатов исследований в экономическом кейсе. ANRT ассоциация управления CIFRE диссертацию.

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

AutoML, как пример тезиса AI

настройки конвейеров машинного обучения ». MO расшифровывается как Multi-Objective и AutoML для автоматизированного машинного обучения.

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

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

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

Этот тезис направлен на продвижение упомянутых выше проблем, тем самым облегчая и улучшая использование AutoML.

OVH и AI

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

В результате тесного сотрудничества с частным партнером NVIDIA, OVH предоставляет программную платформу NVIDIA GPU Cloud (NGC) в качестве эксклюзивного европейского продукта. Целью этого партнерства является облегчение доступа к искусственному интеллекту, позволяя пользователям запускать свою обработку через NGC на продуктах NVIDIA, размещенных в инфраструктуре OVH.

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

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

Итак, как мы можем количественно оценить это качество обслуживания? Как мы понимаем качество, обеспечиваемое каждым продуктом каждый день, с максимальной точностью?

Первым шагом было найти существующие инструменты, но мы быстро поняли, что ни одно решение не отвечает нашим требованиям. Основываясь на этом наблюдении, мы решили разработать собственное решение для вычисления QoS: DepC. Первоначально созданная для команды WebHosting, эта платформа быстро распространилась по OVH. Сейчас он используется внутри компании десятками команд.

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

Чтобы быть максимально прозрачными, мы также решили объяснить и обосновать наши методы расчета. Вот почему мы решили сделать DepC открытым. Вы можете найти его на Github.

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

Что такое QoS?

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

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

QoS выражается в процентах, начиная со 100%, когда обслуживание выполняется идеально, а затем постепенно уменьшается в случае сбоя. Этот процент должен быть связан с периодом: месяц, день, время и т. Д. Таким образом, сервис может иметь 99,995% QoS в текущий день, тогда как накануне оно было 100%.

Важны и другие концепции:

• SLA (соглашение об уровне обслуживания) : не путать с QoS, это договор между заказчиком и поставщиком, указывающий на ожидаемое качество обслуживания. Этот контракт может включать штрафы, предоставленные заказчику в случае невыполнения целей.
• SLO (цель уровня обслуживания) : это относится к цели, которую поставщик услуг хочет достичь с точки зрения QoS.
• SLI (индикатор уровня обслуживания) : это мера (время отклика ping, код состояния HTTP, задержка сети ...), используемая для оценки качества обслуживания. SLI лежат в основе DepC, поскольку они позволяют нам преобразовывать необработанные данные в QoS.

Цели

DepC изначально был создан для команды WebHosting. 5 миллионов веб-сайтов, распределенных на более чем 14 000 серверов, инфраструктура, необходимая для работы веб-сайтов (описанная в этой статье ), а также постоянные изменения затрудняют расчет качества обслуживания в реальном времени для каждого из наших клиентов.. Кроме того, чтобы идентифицировать проблему в прошлом, нам также нужно было знать, как восстановить QoS, чтобы отразить состояние инфраструктуры в то время.

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

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

• Команда WebHosting управляет миллионами веб-сайтов, поэтому масштабирование было бы очень трудным.
• Мы не единственные гаранты правильного функционирования веб-сайтов. Это также зависит от клиента, который может (намеренно или нет) генерировать ошибки, которые будут интерпретированы как ложные срабатывания.
• Даже если бы мы решили предыдущие трудности и можно было бы рассчитать QoS веб-сайтов, было бы невозможно определить первопричины в случае сбоя.

Нам нужно было найти другое решение…

График зависимостей

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

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

1. Исходный код ваших веб-сайтов размещен на серверах хранения (называемых filerz ).
2. Базы данных, используемые сайтом, также размещены на серверах баз данных .

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



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

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

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

Однако создание дерева зависимостей (узлов и их отношений) не требует от нас знания Neo4j, потому что мы разработали демон, который позволяет нам преобразовывать сообщения JSON в узлы на графе. DepC предоставляет API, так что каждая команда может добавлять новые элементы в свое дерево зависимостей, не изучая Cypher.

Принцип такой:

1. Пользователи DepC отправляют сообщение JSON в потоке данных Kafka . Это сообщение указывает, какие новые узлы должны быть созданы, а также их взаимосвязь (например, узел веб-сайта, подключенный к анодному фильтру ). Все узлы и отношения содержат временную информацию, которая помогает поддерживать изменения инфраструктуры с течением времени.
2. DepC анализирует эти сообщения, а затем обновляет график зависимостей в реальном времени.

Поскольку DepC доступен на Github, документация по этой части доступна в этом руководстве.

Расчет QoS

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

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

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

Контролируемые узлы

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

Здесь мы находим концепцию SLI, которую мы видели выше: DepC анализирует необработанные данные, отправленные зондами, чтобы преобразовать их в QoS.

Принцип очень простой:

• Пользователи объявляют индикаторы в DepC, определяя запрос на получение данных из базы данных временных рядов, а также порог, который подразумевает снижение QoS для этого узла.
• DepC запускает этот запрос для всех узлов, выбранных пользователем, затем каждый результат анализируется, чтобы вычислить QoS, как только пороговое значение будет превышено. Затем мы получаем QoS данного узла. Обратите внимание, что этот процесс выполняется каждую ночь благодаря инструменту планирования задач Airflow .

Технически анализ временных рядов DepC — это просто преобразование отсортированного по времени списка значений в отсортированный по времени список логических значений.



В этом случае расчет очень прост: значение «истина» увеличит QoS, а значение «ложь» - снизит его. Например, из 100 точек, когда 95 баллов ниже порогового значения ( верно ), QoS будет 95% (DepC запускает этот расчет каждую ночь; количество точек данных на самом деле намного выше).
Обратите внимание, что для завершения этой части DepC в настоящее время поддерживает базы данных временных рядов OpenTSDB и Warp10. Скоро будут добавлены другие базы данных временных рядов (InfluxDB, Prometheus…).

Неконтролируемые узлы

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

Представьте себе, например, узел, представляющий «клиента», связанный с несколькими контролируемыми узлами типа «сервер». У нас нет данных для анализа по этому клиенту. С другой стороны, для «серверных» узлов мы можем рассчитать их QoS благодаря наблюдаемым узлам. Затем мы объединяем эти показатели QoS, чтобы получить значение «клиентского» узла.

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




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

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

• И : все зависимости должны работать, чтобы услуга была предоставлена.
• ИЛИ : для оказания услуги достаточно одной зависимости.
• СООТНОШЕНИЕ (N) : необходимо, чтобы N% зависимостей работали для предоставления услуги.
• ATLEAST (N) : независимо от количества зависимостей, услуга предоставляется, если функционируют как минимум N зависимостей.

Мы не будем слишком углубляться во внутреннее функционирование, которое позволяет нам рассчитывать QoS в больших масштабах. Но если вас это интересует, я приглашаю вас посмотреть конференцию, которую мы провели на FOSDEM 2019 в Python devroom. Видео и слайды доступны по этому адресу .

Вывод

DepC уже используется десятками команд в OVH. Выбранная архитектура позволяет нам предлагать визуализацию QoS через встроенный веб-интерфейс с самим DepC или депортировать дисплей в Grafana.


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



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

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

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

Ссылки

• Github: https://github.com/ovh/depc
• Документация: https://ovh.github.io/depc/
• Презентация FOSDEM 2019 (EN): https://fosdem.org/2019/schedule/event/python_compute_qos_of_your_infrastructure/
• Презентация PyconFR 2018 (FR): https://pyvideo.org/pycon-fr-2018/calculer-la-qos-de-vos-infrastructures-avec-asyncio.html

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

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

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

В течение следующих 12 месяцев мы запустим бренд OVHcloud, начиная с нашего заметного мероприятия OVHcloud Summit в Париже.



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

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

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

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

Сценарии

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

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

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

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

Самостоятельный перенос сайтов

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

Вот что обычно приходилось делать нашим клиентам:

• Определите все базы данных, используемые в их исходном коде
• Настройте целевую учетную запись
• Поместите сайт на обслуживание в центр обработки данных в Париже, чтобы избежать раздвоения мозгов
• Перенести все данные: файлы исходного кода, а также базы данных
• Настройте новые учетные данные базы данных в исходном коде сайта.
• Убедитесь, что сайт работает как задумано
• Измените свою зону DNS, чтобы перенаправить свой веб-сайт на новый IP-адрес нового кластера Gravelines.
• Повторно откройте сайт и дождитесь окончания задержки распространения DNS.

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

• Надежная идентификация всех используемых баз данных сложна. Можно искать все имена баз данных в исходном коде наших клиентов, но это очень долгая операция, надежная только в том случае, если исходный код не изменяется в течение этого времени. Это также требует работы со многими особыми случаями: двоичные файлы, выполняемые в CGI, обфускация исходного кода или даже хранение имени баз данных в… базе данных. Этот метод не позволяет нам рассчитывать на 100% надежность нашей миграции.
• Перенос файлов можно выполнить двумя способами:
  
  1. В файловом режиме сценарий миграции проходит по дереву файлов и копирует их по одному.
  
  
  2. В блочном режиме сценарий миграции берет данные с жесткого диска и побитно передает их на целевой жесткий диск без учета древовидной структуры.

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

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

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

• Изменение исходного кода — опасная операция, которую мы не позволяем делать, потому что это может сильно повлиять на веб-сайт. Кроме того, это требует исчерпывающего определения всех видов использования баз данных…
• Некоторые наши клиенты не размещают свою зону DNS дома. После этого мы не сможем изменить IP-адрес их веб-сайта без их вмешательства, что требует от нас сохранения этого IP-адреса, если мы хотим достичь хорошего уровня надежности для миграции.

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

IP через грузовые автомобили

Интернет основан на IP-протоколе для адресации машин в сети. Это не зависит от физического материала, на котором происходит обмен сообщениями, можно использовать многие: оптические каналы, электрические, беспроводные; даже странствующих голубей, как это описано в юмористическом стандарте, установленном 1 апреля 1990 года!

Эта первоапрельская шутка нас вдохновила, хотя мы не знатоки голубей. В самом деле, даже если задержка (продолжительность путешествия для сообщения из точки A в точку B) важна, пропускная способность (количество отправленной информации / время в пути) потенциально огромна: USB-ключ содержит много данных! При некоторых больших передачах физическое перемещение данных — разумный способ увеличить пропускную способность передачи.

Поэтому мы подумали о варианте просто перенести инфраструктуру из Парижа в Gravelines. У этого есть преимущества:

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

Но это также создает некоторые проблемы:

• Как сократить время нарезки сайтов между остановкой машин в Париже, их загрузкой, транспортировкой, разгрузкой и повторным зажиганием? Время отключения будет порядка нескольких дней.
• Что делать в случае аварии в дороге? Падение сервера, ДТП…
• Как убедиться, что данные не изменятся во время транспортировки из-за вибрации грузовика?
• Как интегрировать эту инфраструктуру, не соблюдая стандарты индустриализации, действующие в Gravelines?

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

Масштабируемые миграции

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

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

• IP-адреса: мы не контролировали все зоны DNS, мы считали, что IP-адреса сайтов наших клиентов не могут быть изменены. Это означает, что мы должны перенести сразу все веб-сайты, использующие один и тот же IP-адрес.
• Filerz : миграция в файл данных режима на filerz не является возможным из - за большое количество файлов, мы должны выполнить миграцию в блочной режиме и тем самым перенести все клиент в том же filerz одновременно.
• Базы данных: все базы данных на одном веб-сайте должны быть перенесены одновременно, чтобы сайт продолжал работать, а идентификаторы баз данных не должны изменяться. Эти базы данных потенциально могут использоваться двумя разными местоположениями, включая разные кластеры; эти приспособления должны быть перенесены одновременно.

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

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

Устранение зависимостей от баз данных

Одно из самых сложных ограничений — это надежная миграция баз данных вместе с веб-сайтами.

Можем ли мы представить себе 95% надежную миграцию с учетом только баз данных, предоставленных с хостингом (то есть, не считая нетипичных случаев, которые обнаруживаются только путем анализа исходного кода веб-сайтов)?

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

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

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

Это не идеальное решение: добавление сетевого туннеля означает добавление задержки 10 мс. И на некоторых CMS, выполняющих десятки SQL-запросов последовательно, эта задержка быстро заметна. Но, ограничив этот эффект только базами данных без ссылок, мы могли бы упростить это сильное ограничение. Все сайты продолжат работу. Некоторые сайты могут работать медленно, но для наших обычных случаев веб-хостинга последствия минимальны.

Обход зависимости IP-адреса

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

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

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

И наконец, ничто не мешает нам использовать балансировку нагрузки Paris или Gravelines для выполнения этого перенаправления трафика.

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

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

IP-адреса больше не были точкой блокировки. Снижая это ограничение, мы теперь можем переносить клиентов filerz by filerz. Можем ли мы сделать еще лучше?

Перенести filerz как блок

Чтобы добиться большего, нам потребуется декоррелировать клиентов каждого filerz. Как мы могли это сделать?

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

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

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

Теперь у нас есть все элементы для реализации нового сценария миграции!

Давай, сделаем это еще раз.

Наш финальный сценарий

После прочтения предыдущих разделов вы, вероятно, уже имеете хорошее представление о том, как мы переносим кластеры. Вот основные шаги:

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


2 / Построение сетевого соединения между новым и старым центром обработки данных.


3 / Миграция IP-трафика на новый кластер с перенаправлением в Париж для немигрированных сайтов.


4 / Копирование данных без взлома сайтов.


5 / Ночью: отключение сайтов первого filerz, перенос его данных и связанных баз данных.


6 / Ночью: отключение сайтов, миграция второго filerz и связанных баз данных.


7 / Закрытие исходного кластера.


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

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

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

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

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

До скорой встречи для дальнейших приключений!

В прошлом месяце команда OVH и Binder объединилась, чтобы поддержать рост экосистемы BinderHub по всему миру.



Приблизительно 100 000 еженедельных пользователей общедоступного развертывания mybinder.org и 3 000 уникальных репозиториев git, в которых размещены значки Binder, ощущали потребность в дополнительных ресурсах и вычислительном времени.

Сегодня мы рады объявить, что OVH теперь является частью всемирной федерации BinderHubs, поддерживающих mybinder.org. Весь трафик на mybinder.org теперь распределяется между двумя BinderHub: один находится в ведении группы Binder, а другой — в инфраструктуре OVH.

Итак, для тех, кто еще не знает mybinder.org, вот краткое изложение.

Что такое Юпитер?

Jupyter — потрясающий проект с открытым исходным кодом, который позволяет пользователям создавать, визуализировать и редактировать интерактивные записные книжки. Он поддерживает множество популярных языков программирования, таких как Python, R и Scala, а также некоторые стандарты представления, такие как разметка, фрагменты кода, визуализация диаграмм…



Пример локальной записной книжки Jupyter, читающей записную книжку внутри клиента предвидения репозитория OVH GitHub.

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

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

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

Что такое JupyterHub?

JupyterHub — еще более потрясающий проект с открытым исходным кодом, предлагающий многопользовательскую функцию для ноутбуков Jupyter. Благодаря нескольким подключаемым механизмам аутентификации (например, PAM, OAuth), он позволяет создавать записные книжки Jupyter на лету из централизованной инфраструктуры. Затем пользователи могут легко делиться своими записными книжками и правами доступа друг с другом. Это делает JupyterHub идеальным для компаний, учебных аудиторий и исследовательских лабораторий.

Что такое BinderHub?

Наконец, BinderHub — это вишенка на торте: он позволяет пользователям превращать любой репозиторий Git (например, GitHub) в коллекцию интерактивных записных книжек Jupyter одним щелчком мыши.



Binder экземпляр развернутого OVH можно ознакомиться здесь .

• Просто выберите общедоступный репозиторий git (лучше, если он уже содержит записные книжки Jupyter ).
• Скопируйте URL-адрес выбранного репозитория в правильное поле привязки.
• Щелкните кнопку запуска.
• Если связыватель впервые видит предоставленный вами репозиторий, вы увидите журналы компиляции. Ваш репозиторий анализируется и готовится к запуску связанной записной книжки Jupyter .
• После завершения компиляции вы будете автоматически перенаправлены на выделенный экземпляр.
• Затем вы можете начать взаимодействовать и взламывать ноутбук.
• На начальной странице подшивки вы увидите ссылку, по которой можно поделиться своим репозиторием с другими.

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

Инструменты, используемые BinderHub

BinderHub соединяет несколько сервисов вместе, чтобы обеспечить создание и реестр образов Docker на лету. Он использует следующие инструменты:

• Облачный провайдер, такой как OVH.
• Kubernetes для управления ресурсами в облаке
• Helm для настройки и управления Kubernetes.
• Docker для использования контейнеров, которые стандартизируют вычислительные среды.
• Пользовательский интерфейс BinderHub, к которому пользователи могут получить доступ, чтобы указать репозитории Git, которые они хотят создать.
• BinderHub для создания образов Docker с использованием URL-адреса репозитория Git.
• Реестр Docker, в котором размещаются образы контейнеров.
• JupyterHub для развертывания временных контейнеров для пользователей.

Что происходит, когда пользователь щелкает ссылку Binder?

После того, как пользователь щелкает ссылку Binder, происходит следующая цепочка событий:

1. BinderHub разрешает ссылку на репозиторий.
2. BinderHub определяет, существует ли уже образ Docker для репозитория по последней ссылке (хэш, ветка или тег git commit).
3. Если изображение не существует, BinderHub создает модуль сборки, который использует repo2docker для:
   
   • Получите репозиторий, связанный со ссылкой.
   • Создайте образ контейнера Docker, содержащий среду, указанную в файлах конфигурации в репозитории.
   
   
   • Отправьте этот образ в реестр Docker и отправьте информацию реестра в BinderHub для дальнейшего использования.
4. BinderHub отправляет реестр образов Docker в JupyterHub.
5. JupyterHub создает для пользователя модуль Kubernetes, который обслуживает созданный образ Docker для репозитория.
6. JupyterHub отслеживает активность модуля пользователя и уничтожает его после короткого периода бездействия.

Схема архитектуры BinderHub

Как мы это развернули?

На платформе OVH Kubernetes

Одна замечательная особенность проекта Binder заключается в том, что он полностью не зависит от облака, вам просто нужен кластер Kubernetes для развертывания.

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

Для этого мы использовали 2 сервиса в OVH Public Cloud:

• Kubernetes кластер сегодня потребляет 6 узлов 

  C2-15

  экземпляров виртуальных машин (она будет расти в будущем)
• Docker реестра

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

Установка HELM на наш новый кластер

После завершения автоматической установки нашего кластера Kubernetes мы загрузили административный YAML-файл, позволяющий управлять нашим кластером и запускать 

kubectl

на нем команды.

kubectl

это официальный и самый популярный инструмент, используемый для администрирования кластера Kubernetes. Более подробную информацию о том, как его установить, можно найти здесь .
Автоматическое развертывание полного стека Binder уже подготовлено в виде пакета Helm. Helm — это менеджер пакетов для кубернетов, и для работы ему нужны клиентская часть ( 

helm

) и серверная часть ( 

tiller

).
Всю информацию об установке 

helm

и 

tille

можно найти здесь .

Конфигурация нашего развертывания Helm

После 

tiller

установки в нашем кластере все было готово для автоматизации развертывания связующего в нашей инфраструктуре OVH.
Конфигурация 

helm

развертывания довольно проста, и все шаги были описаны командой Binder здесь .

Интеграция в процесс CD / CI binderhub

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

Затем мы подождали их следующего запуска рабочего процесса Travis, и он сработал.

С этого момента стек ovh для binder был запущен и доступен всем отовсюду по этому адресу: ovh.mybinder.org/

Что будет дальше?

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

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

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

Специальная благодарность

Мы благодарны командам Binder, Jupyter и QuantStack за их помощь, команде OVH K8s для OVH Managed Kubernetes и OVH Managed Private Registry, а также команде OVH MLS за поддержку. Вы молодцы!