Празднование присоединения Harbour к ограниченному списку проектов CNCF Graduated



Пару месяцев назад, через год после того, как наша служба Managed Kubernetes стала общедоступной, мы запустили службу Managed Private Registry. В предыдущем сообщении в блоге мы рассказали, почему решили основать его на проекте CNCF Harbour. Два сотрудника OVHcloud стали сопровождающими проекта. Теперь у нас есть новое событие, которое нужно отпраздновать: Фонд облачных вычислений только что объявил, что Харбор присоединился к очень ограниченному списку «завершенных» проектов.

Выпуск CNCF: высший уровень зрелости

CNCF размещает несколько десятков проектов с открытым исходным кодом и отлично справляется со своей работой, предлагая этим проектам поддержку роста как с точки зрения инфраструктуры и инструментов, так и с точки зрения сообщества и осведомленности. Однако большинство этих проектов находятся в «песочнице CNCF» или на стадии «инкубации». В настоящее время «завершили» только 11 проектов, включая Kubernetes, Prometheus и Helm. Харбор стал последним, кто получил этот большой знак признания.



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

OVHcloud с гордостью демократизирует гавань

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

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



Больше для наших нынешних и будущих пользователей управляемого реестра!

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

  • план «M», идеальный для средних компаний-разработчиков программного обеспечения или бизнес-единиц в крупных организациях; теперь включает сканирование уязвимостей
  • план «L» теперь может содержать до 5 ТБ ваших артефактов (слои контейнера, диаграммы Helm и т. д.)

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

В настоящее время демонстрируя очень стабильную версию Harbour 1.10, наша контейнерная команда уже планирует перейти на Harbour 2.0.

До встречи на саммите Kubecon Europe и OVHcloud в конце этого года!

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

Создание экосистемы партнерских отношений, разделяющих те же ценности, что и мы, является ключевой стратегической целью 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. Будьте на связи!

Управление Harbour в облачном масштабе: история Harbour Kubernetes Operator

Недавно наша команда контейнерных платформ сделала нашу услугу «Частный управляемый реестр» общедоступной. В этом сообщении блога мы объясним, почему OVHcloud выбрал основу для этой службы на проекте Harbour, построил для него оператор Kubernetes и открыл его исходный код в рамках проекта CNCF goharbor.



Необходимость частного реестра S.MART

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

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

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

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

Идеальное сочетание набора функций с открытым исходным кодом и корпоративного уровня

Изучив перспективы точной настройки нашего набора функций и модели ценообразования, мы искали лучшие существующие технологии, чтобы поддержать его, и остановились на инкубационном проекте CNCF Harbor (подаренном CNCF компанией VMWare). Помимо того, что Harbour является одним из немногих проектов, достигших инкубационного состояния CNCF, что подтверждает твердую приверженность сообщества, он также стал ключевой частью нескольких коммерческих решений для контейнеризации предприятий. Мы также высоко оценили подход, принятый Харбором: не изобретать колесо заново, а использовать лучшие в своем классе технологии для таких компонентов, как сканирование уязвимостей, доверие к контенту и многие другие. Он использует мощную сеть проектов с открытым исходным кодом CNCF и обеспечивает высокий уровень качества UX.



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

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

Кроме того, Kubernetes для обеспечения высокой доступности сервисов без сохранения состояния и хранилища объектов (на основе Openstack Swift и совместимость с S3 API ) был очевидным выбором для проверки этих требований.

Решение операционных проблем в масштабе облачного провайдера

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

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

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

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

Универсальный оператор, разработанный для любого развертывания в гавани

Читатели, знакомые с проектом Harbour, могут задаться вопросом, какое значение этот оператор привносит в текущий каталог развертываний, включая версию Helm Chart, поддерживаемую проектом.

Шаблон проектирования оператора быстро становится популярным и имитирует ориентированный на приложения контроллер, который расширяет Kubernetes для управления более сложными приложениями с отслеживанием состояния. Проще говоря, он предназначен для разных сценариев использования, чем Helm. В то время как диаграмма Helm предлагает универсальный установщик, который также будет развертывать различные зависимости Harbor (база данных, кеш и т. Д.) Из образов Docker с открытым исходным кодом, другие предприятия, операторы услуг и облачные провайдеры, такие как мы, захотят выбрать и -выбрать услугу или технологию, лежащую в основе этих компонентов.

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

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

Мы разработали оператор (используя платформу OperatorSDK), чтобы как дополнительные модули Harbor (хранилище Helm Chart, сканер уязвимостей и т. Д.), Ни зависимости (серверная часть хранилища реестра, относительные и нереляционные базы данных и т. Д.) Могли легко соответствовать вашему конкретному варианту использования.

Упрощенная архитектура службы управляемого частного реестра OVHcloud'd

Вклад в проект Harbor и оператора

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

С этой целью Жереми Монсинжон и Пьер Перонне также были приглашены в качестве сопровождающих в проекте Harbour с упором на goharbor / оператора.

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

Скачать Harbour or the Harbour Operator: официальное репозиторий Harbour Github — www.github.com/goharbor

Узнайте больше о гавани: Официальный сайт гавани — goharbor.io/

Создание и использование снимков OpenStack

Что такое снимок в публичном облаке OpenStack / OVHcloud?

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

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



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



Как создать снимок
Использование интерфейса командной строки

Чтобы создать моментальный снимок экземпляра с помощью интерфейса командной строки, используйте следующую команду:

# Load your OpenStack credentials
$ source openrc

# Using the openstack client
$ openstack server image create --name <name of the new image> <instance name or uuid>

# Or using the nova client (deprecated)
$ nova image-create <instance name or uuid> <name of the new image>


Использование Horizon

После входа в Horizon вы можете создать моментальный снимок на странице « Вычислить» → «Экземпляры », щелкнув действие «Создать моментальный снимок».



Статус снимка и информацию о нем можно найти на странице Compute → Images.



Затем вы можете выбрать снимок при создании нового экземпляра.

Снимки в реальном времени и согласованность данных

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

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

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

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

Обеспечение согласованности снимков

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

Эта связь происходит через виртуальное устройство, добавленное к экземпляру, когда OpenStack Nova обнаруживает, что используемое изображение имеет следующее свойство: hw_qemu_guest_agent set to yes.

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

# Using the openstack client
$ openstack image set --property hw_qemu_guest_agent=yes <image name or uuid>

# Or using the glance client (deprecated)
$ glance image-update --property hw_qemu_guest_agent=yes <image name or uuid>


Чтобы проверить, что свойства действительно установлены, используйте следующую команду:

$ openstack image show -f value -c properties <image name or uuid>


На следующей диаграмме показан рабочий процесс создания снимка в этих условиях:



Конкретный шаг, который предотвращает любые несоответствия, — это №6: QEMU-agent замораживает файловую систему.

Настройка агента QEMU

Linux
Qemu-guest-agent не установлен по умолчанию, но после его установки и запуска механизм замораживания / размораживания файловой системы будет работать сразу после установки.

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

$ file /dev/virtio-ports/org.qemu.guest_agent.0
/dev/virtio-ports/org.qemu.guest_agent.0: symbolic link to `../vport2p1'


Если этого файла нет, гостевой агент qemu не будет работать, а это значит, что для вашего образа не установлено hw_qemu_guest_agentсвойство yes.

Дистрибутивы на основе Debian (Debian, Ubuntu)

# Install the agent
user@agent:~$ sudo apt-get update
user@agent:~$ sudo apt-get install qemu-guest-agent

# Check the agent is started (it should be automatically started and enabled)
user@agent:~$ sudo service qemu-guest-agent status


Распределения на основе Redhat (Centos, Fedora)

# Install the agent
user@agent:~$ sudo yum install qemu-guest-agent

# Enable the agent
user@agent:~$ sudo chkconfig qemu-guest-agent on

# Start the agent
user@agent:~$ sudo service qemu-guest-agent start

# Check the agent is started
user@agent:~$ sudo service qemu-guest-agent status


Windows

Загрузите и установите MSI, связанный с вашей архитектурой (32- или 64-разрядные версии, хотя мы рекомендуем 64-разрядные версии для публичного облака) из проекта Fedora: fedorapeople.org/groups/virt/virtio-win/direct-downloads/ последний-qemu-ga /

Вы можете проверить, что служба запущена, используя эту команду powershell:

PS C:\Users\Administrator> Get-Service QEMU-GA

Status   Name               DisplayName
------   ----               -----------
Running  QEMU-GA            QEMU Guest Agent


Документацию Fedora по созданию образов Windows с драйверами virtIO можно найти здесь. [2]

Расширенное использование: перехватчики агента QEMU

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

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

Кроме того, в некоторых дистрибутивах уже есть ловушка fsfreeze.

Добавьте скрипт fsfreeze-hook

Во-первых, нам нужно добавить и активировать механизм fsfreeze-hook:

# Create the folders to receive the hooks
debian@agent:~$ sudo mkdir -p /etc/qemu/fsfreeze-hook.d

# Download the fsfreeze-hook from the QEMU repository
debian@agent:~$ sudo wget -O /etc/qemu/fsfreeze-hook https://raw.githubusercontent.com/qemu/qemu/master/scripts/qemu-guest-agent/fsfreeze-hook
debian@agent:~$ sudo chmod +x /etc/qemu/fsfreeze-hook

# Add the configuration of the qemu-guest-agent daemon to use this script
debian@agent:~$ sudo tee /etc/default/qemu-guest-agent > /dev/null <<EOF
DAEMON_ARGS="-F/etc/qemu/fsfreeze-hook"
EOF

# Restart the service to take the modifications into account
debian@agent:~$ sudo service qemu-guest-agent restart


Пример скрипта перехвата

/etc/qemu/fsfreeze-hook cкрипт позволяет пользователям добавлять пользовательские скрипты, которые будут выполняться до и после замораживания файловой системы.

Добавим тест, который записывает в файл при замораживании и оттаивании экземпляра:

debian@agent:~$ sudo tee /etc/qemu/fsfreeze-hook.d/test_hook.sh > /dev/null <<EOF
#!/bin/bash

case \$1 in
 freeze)
   echo "I'm frozen" > /tmp/freeze
   ;;
 thaw)
   echo "I'm thawed" >> /tmp/freeze
   ;;
 *)
   exit 1
   ;;
esac
EOF

debian@agent:~$ sudo chmod +x /etc/qemu/fsfreeze-hook.d/test_hook.sh


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

Сделайте снимок своего экземпляра:

$ openstack server image create --name test_snapshot <instance name or uuid>


Убедитесь, что тестовый хук запущен:

# It works!
debian@agent:~$ sudo cat /tmp/freeze
I'm frozen
I'm thawed


Очистите тест:

debian@agent:~$ sudo rm /etc/qemu/fsfreeze-hook.d/test_hook.sh /tmp/freeze


Почему это не включено по умолчанию?

Qemu-guest-agent не установлен по умолчанию в большинстве дистрибутивов. Так почему бы нам не добавить его по умолчанию в предоставляемые нами базовые изображения?

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

Источники:
  • Запись в блоге Себастьяна Хана «OpenStack: выполнение согласованных снимков» [1]
  • Вики-статья proxmox о гостевом агенте QEMU [2]
  • Документация Fedora по созданию образов Windows с драйверами virtIO [3]

Кластеры OVHcloud Object Storage поддерживают S3 API

Что такое объектное хранилище?

Знаете ли вы, что большой объем данных в Интернете хранится в объектном хранилище?

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

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

Следующее подчеркивает разницу между традиционными файловыми системами и стратегией хранения объектов:



Стандартный и двусторонний

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

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

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

API S3

Интерфейс программирования приложений Amazon S3 (S3 API) — наиболее распространенный способ хранения, управления и извлечения данных из хранилищ объектов. S3 API — это интерфейсный API поверх OpenStack Swift. Чтобы использовать S3 API в OVHcloud, вам необходимо получить учетные данные S3 в форме Keystone (1), которая является модулем аутентификации в OpenStack. Это предоставит вам идентификатор ключа доступа и секретный ключ, которые вы можете использовать в своем инструменте S3 (2). Получив эти учетные данные, вы сможете общаться с OVHcloud, используя «язык» S3, и использовать наши решения для объектного хранилища. S3 API проверит ваши учетные данные (4) и переведет ваши вызовы в Swift API (5) для выполнения ваших запросов (6).



Пример использования: API S3 в действии


Рассмотрим типичный пример: использование S3 API для хранения мультимедийных и статических файлов для веб-сайта WordPress в OVHcloud Object Storage.

Мы будем использовать плагин WordPress под названием Media Cloud, который хранит мультимедиа (изображения, видео) в облачных сервисах. После его установки нам потребуются учетные данные S3 для настройки плагина, сгенерированные с помощью OpenStack CLI.

$ openstack ec2 credentials create
+------------+-----------------------------------------------------------+
| Field:     | Value                                                     |       
+------------+-----------------------------------------------------------+
| access     | 5a4d8b8d88104123a862c527ede5a3d3                          |
| links      | {u'self': u'https://auth.cloud.ovh.net/...                |
| project_id | 20e124b71be141299e111ec26b1892fa                          |
| secret     | 925d5fcfcd9f436d8ffcb20548cc53a2                          |
| trust_id   | None                                                      |
| user_id    | d74d05ff121b44bea9216495e7f0df61                          |
+------------+-----------------------------------------------------------+


Теперь мы можем настроить плагин, выбрав в мастере запись «Совместимость с S3» и предоставив учетные данные при появлении запроса. Обязательно укажите правильную конечную точку, например storage.gra.cloud.ovh.net для региона Graveline во Франции или storage.us-east-va.cloud.ovh.us для региона Vint Hill. в США.



Наконец, просто загрузите изображения в раздел «Медиа» и дважды проверьте, что они размещены в OVHcloud Object Storage.



Из всех доступных вариантов объектное хранилище — это простое, чрезвычайно надежное, высокодоступное и бесконечно масштабируемое решение для хранения данных. Кроме того, OVHcloud установил стандарт, обеспечив совместимость своего предложения Object Storage с де-факто сервисом Amazon S3.

Преимущества архитектуры NVMe для наших экземпляров Public Cloud

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



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

Архитектура NVMe для наших экземпляров Public Cloud



Чтобы обеспечить максимальную производительность хранилища, мы работали с рядом наших клиентов над PoC, в котором использовалась та же функция PCI Passthrough, чтобы включить самое быстрое устройство хранения в наши экземпляры Public Cloud: карты NVMe с 1,8 ТБ пространства .

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



Очистите устройство перед его перераспределением

Вы говорите быстро, но как быстро?

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

Сначала создайте экземпляр i1-180, используя OpenStack CLI.

$ openstack server create --flavor i1-180 --image "Ubuntu 19.04" \
  --net Ext-Net --key-name mykey db01


Проверьте устройства NVMe на экземпляре.

$ lsblk | grep nvme
nvme2n1 259:0    0  1.8T  0 disk
nvme1n1 259:1    0  1.8T  0 disk
nvme0n1 259:2    0  1.8T  0 disk
nvme3n1 259:3    0  1.8T  0 disk


У нас есть четыре устройства NVMe, поэтому давайте создадим с ними RAID 0.

$ mdadm --create /dev/md1 --level 0 --raid-devices 4 \
  /dev/nvme0n1 /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started


Теперь отформатируем рейд-устройство.

$ mkfs.xfs /dev/md1
meta-data=/dev/md1               isize=512    agcount=32, agsize=58601344 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=0, rmapbt=0, reflink=0
data     =                       bsize=4096   blocks=1875243008, imaxpct=5
         =                       sunit=128    swidth=512 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=521728, version=2
         =                       sectsz=512   sunit=8 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0


После монтирования файловой системы на / mnt мы готовы запустить тест.

Прочитать тест

Мы начнем с теста чтения, используя блоки размером 4 КБ, и поскольку у нас 32 виртуальных ядра в этой модели, мы будем использовать 32 задания. Пошли!

$ fio --bs=4k --direct=1 --rw=randread --randrepeat=0 \
  --ioengine=libaio --iodepth=32 --runtime=120 --group_reporting \
  --time_based --filesize=64m --numjobs=32 --name=/mnt/test
/mnt/test: (g=0): rw=randread, bs=® 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
[...]
fio-3.12
Starting 32 processes
Jobs: 32 (f=32): [r(32)][100.0%][r=9238MiB/s][r=2365k IOPS][eta 00m:00s]
/mnt/test: (groupid=0, jobs=32): err= 0: pid=3207: Fri Nov 29 16:00:13 2019
  read: IOPS=2374k, BW=9275MiB/s (9725MB/s)(1087GiB/120002msec)
    slat (usec): min=2, max=16031, avg= 7.39, stdev= 4.90
    clat (usec): min=27, max=16923, avg=419.32, stdev=123.28
     lat (usec): min=31, max=16929, avg=427.64, stdev=124.04
    clat percentiles (usec):
     |  1.00th=[  184],  5.00th=[  233], 10.00th=[  269], 20.00th=[  326],
     | 30.00th=[  363], 40.00th=[  388], 50.00th=[  412], 60.00th=[  437],
     | 70.00th=[  465], 80.00th=[  506], 90.00th=[  570], 95.00th=[  635],
     | 99.00th=[  775], 99.50th=[  832], 99.90th=[  971], 99.95th=[ 1037],
     | 99.99th=[ 1205]
   bw (  KiB/s): min=144568, max=397648, per=3.12%, avg=296776.28, stdev=46580.32, samples=7660
   iops        : min=36142, max=99412, avg=74194.06, stdev=11645.08, samples=7660
  lat (usec)   : 50=0.01%, 100=0.02%, 250=7.41%, 500=71.69%, 750=19.59%
  lat (usec)   : 1000=1.22%
  lat (msec)   : 2=0.07%, 4=0.01%, 10=0.01%, 20=0.01%
  cpu          : usr=37.12%, sys=62.66%, ctx=207950, majf=0, minf=1300
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued rwts: total=284924843,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=32
 
Run status group 0 (all jobs):
   READ: bw=9275MiB/s (9725MB/s), 9275MiB/s-9275MiB/s (9725MB/s-9725MB/s), io=1087GiB (1167GB), run=120002-120002msec
 
Disk stats (read/write):
    md1: ios=284595182/7, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=71231210/1, aggrmerge=0/0, aggrticks=14348879/0, aggrin_queue=120, aggrutil=99.95%
  nvme0n1: ios=71231303/2, merge=0/0, ticks=14260383/0, in_queue=144, util=99.95%
  nvme3n1: ios=71231349/0, merge=0/0, ticks=14361428/0, in_queue=76, util=99.89%
  nvme2n1: ios=71231095/0, merge=0/0, ticks=14504766/0, in_queue=152, util=99.95%
  nvme1n1: ios=71231096/4, merge=0/1, ticks=14268942/0, in_queue=108, util=99.93%


2370 тыс. Операций ввода-вывода в секунду. Потрясающие цифры, не правда ли?

Написать тест

Готовы к тесту записи?

$ fio --bs=4k --direct=1 --rw=randwrite --randrepeat=0 --ioengine=libaio --iodepth=32 --runtime=120 --group_reporting --time_based --filesize=64m --numjobs=32 --name=/mnt/test
/mnt/test: (g=0): rw=randwrite, bs=® 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
[...]
fio-3.12
Starting 32 processes
Jobs: 32 (f=32): [w(32)][100.0%][w=6702MiB/s][w=1716k IOPS][eta 00m:00s]
/mnt/test: (groupid=0, jobs=32): err= 0: pid=3135: Fri Nov 29 15:55:10 2019
  write: IOPS=1710k, BW=6680MiB/s (7004MB/s)(783GiB/120003msec); 0 zone resets
    slat (usec): min=2, max=14920, avg= 6.88, stdev= 6.20
    clat (nsec): min=1152, max=18920k, avg=587644.99, stdev=735945.00
     lat (usec): min=14, max=18955, avg=595.46, stdev=736.00
    clat percentiles (usec):
     |  1.00th=[   21],  5.00th=[   33], 10.00th=[   46], 20.00th=[   74],
     | 30.00th=[  113], 40.00th=[  172], 50.00th=[  255], 60.00th=[  375],
     | 70.00th=[  644], 80.00th=[ 1139], 90.00th=[ 1663], 95.00th=[ 1991],
     | 99.00th=[ 3490], 99.50th=[ 3949], 99.90th=[ 4686], 99.95th=[ 5276],
     | 99.99th=[ 6521]
   bw (  KiB/s): min=97248, max=252248, per=3.12%, avg=213714.71, stdev=32395.61, samples=7680
   iops        : min=24312, max=63062, avg=53428.65, stdev=8098.90, samples=7680
  lat (usec)   : 2=0.01%, 4=0.01%, 10=0.01%, 20=0.86%, 50=11.08%
  lat (usec)   : 100=15.35%, 250=22.16%, 500=16.34%, 750=6.69%, 1000=5.03%
  lat (msec)   : 2=17.66%, 4=4.38%, 10=0.44%, 20=0.01%
  cpu          : usr=20.40%, sys=41.05%, ctx=113183267, majf=0, minf=463
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,205207842,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=32
 
Run status group 0 (all jobs):
  WRITE: bw=6680MiB/s (7004MB/s), 6680MiB/s-6680MiB/s (7004MB/s-7004MB/s), io=783GiB (841GB), run=120003-120003msec
 
Disk stats (read/write):
    md1: ios=0/204947351, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=0/51301962, aggrmerge=0/0, aggrticks=0/27227774, aggrin_queue=822252, aggrutil=100.00%
  nvme0n1: ios=0/51302106, merge=0/0, ticks=0/29636384, in_queue=865064, util=100.00%
  nvme3n1: ios=0/51301711, merge=0/0, ticks=0/25214532, in_queue=932708, util=100.00%
  nvme2n1: ios=0/51301636, merge=0/0, ticks=0/34347884, in_queue=1089896, util=100.00%
  nvme1n1: ios=0/51302396, merge=0/0, ticks=0/19712296, in_queue=401340, util=100.00%


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

Конечно, для этого примера мы представляем оптимальный сценарий. RAID 0 по своей природе опасен, поэтому любой сбой на одном из устройств NVMe может повредить ваши данные. Это означает, что вы обязательно должны создавать резервные копии критически важных данных, но это само по себе открывает множество новых возможностей. Так что мы на 100% уверены, что ваши базы данных полюбят эти экземпляры! Вы можете найти более подробную информацию о них на нашем  веб-сайте Public Cloud .

Партнерство MyBinder и OVH

В прошлом месяце команда 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:


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

Установка 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 за поддержку. Вы молодцы!