Дата-центры OVH

Обеспечение безопасности и контроля ваших данных


7е издание саммита OVHcloud отметит 20 — летний OVH
Это событие будет возможность поблагодарить нашу экосистему. В этот день мы вновь подтверждаем обязательство, которые делают нам альтернативный плеер в облаке в течение двух десятилетий.
Вы также узнаете наши новейшие решения и инновации. Это позволит вам сохранить полный контроль над вашими данными и максимально свободно.
summit.ovhcloud.com/fr/subscription/
summit.ovhcloud.com/fr/

www.ovh.com/sg/dedicated-servers/
www.ovh.com.au/dedicated-servers/

lg.ovh.net/
sgp.smokeping.ovh.net/smokeping?target=APAC
syd.smokeping.ovh.net/smokeping?target=APAC
weathermap.ovh.net/#apac
www.apac-tools.ovh/traceroute/

В 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 (индикатор уровня обслуживания): это мера (время ответа на пинг, код состояния HTTP, задержка в сети…), используемая для оценки качества услуги. SLI лежат в основе DepC, поскольку они позволяют нам преобразовывать необработанные данные в QoS.

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

ovh.github.io/depc/guides/kafka.html

Расчет 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 нашего неконтролируемого узла.


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

ovh.github.io/depc/guides/queries.html#operation-based-qos
Для этого примера мы использовали только логический оператор. Однако DepC предоставляет несколько типов логических операций для разных приложений:

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

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

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

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


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

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

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

Github: github.com/ovh/depc
Documentation: ovh.github.io/depc/
Presentation FOSDEM 2019 (EN): fosdem.org/2019/schedule/event/python_compute_qos_of_your_infrastructure/
Presentation PyconFR 2018 (FR): pyvideo.org/pycon-fr-2018/calculer-la-qos-de-vos-infrastructures-avec-asyncio.html

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


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


Люди, которые хотя бы немного заинтересованы в облачных сервисах или управлении центрами обработки данных и ИТ-инфраструктурой, безусловно, связывают OVH — предприятие, начавшее свое приключение с услуг хостинга в 1999 году. С момента появления компании на рынке, правильное управление и развитие компании сделали ее сегодня одним из европейских лидеров в области услуг хостинга, который также предлагает свои услуги по всему миру. С момента запуска первого дата-центра в Париже в 2003 году, компания выросла до такой степени, что в настоящее время она насчитывает до 28 дата-центров по всему миру (включая Польшу, Австралию, Канаду, США и даже Сингапур). Целью нашего визита, однако, были дата-центры, расположенные во Франции, в частности, в очаровательном городе Рубе.


Рубе это город, расположенный в департаменте О-де-Франс, на границе с Бельгией. На первый взгляд видно, что это промышленно развитый город. Тем не менее, ландшафт современности переплетается с фабриками и залами, которые были повреждены зубом времени, заброшенные и забытые, которые прославились на долгие годы. Конечно, большинство из вас не может представить себе современные дата-центры в этом типе обстановки, но, к нашему удивлению, выбор такого местоположения стал фактом. Более того, это не случайно. Все действительно тщательно продумано. Стратегическое расположение объектов не только способствует резервированию, но также вытекает непосредственно из плана действий компании, который сосредоточен, прежде всего, на использовании уже имеющихся ресурсов инфраструктуры. Это не означает, что OVH не строит свои собственные центры.


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


Старые, хотя и модернизированные залы изначально не вызывают симпатии, но достаточно заглянуть в них, чтобы понять, что мы имеем дело с действительно продуманным действием. Первое, что сразу бросается в глаза — это отсутствие кондиционера. Охлаждение является одним из важнейших элементов такой большой инфраструктуры. OVH, однако, нашли совершенно другой способ охлаждения серверов, что подразумевает отсутствие какого-либо кондиционера. Это связано с общепринятой политикой компании. Это говорит об использовании воздушного охлаждения только на 30%. Остальные 70% — это только жидкостное охлаждение. Также стало известно, что компания работает над жидкостным охлаждением с 2010 года. Решение о реализации этого типа решения позволило снизить стоимость электроэнергии до 10%. Использование водяного охлаждения для современных компьютеров не удивляет подавляющее большинство пользователей сегодня. Другое дело, если говорить о жидкостном охлаждении всех машин, имеющихся в огромном зале. Отличается ли водяное охлаждение серверов (и фактически установленных в них процессоров) от традиционного водяного охлаждения? На самом деле, это чрезвычайно просто и основано на том же принципе, что и для домашних компьютеров. В дополнение к типичным элементам для этого типа системы (трубопроводная система, теплообменник и блок с жидкостью), также важно использовать небольшое рабочее колесо, которое позволяет контролировать вращение. Стоит добавить, что система водяного охлаждения компании может быть включена в типовые решения если говорить о жидкостном охлаждении всех машин, имеющихся в огромном зале. Отличается ли водяное охлаждение серверов (и фактически установленных в них процессоров) от традиционного водяного охлаждения? На самом деле, это чрезвычайно просто и основано на том же принципе, что и для домашних компьютеров. В дополнение к типичным элементам для этого типа системы (трубопроводная система, теплообменник и блок с жидкостью), также важно использовать небольшое рабочее колесо, которое позволяет контролировать вращение. Стоит добавить, что система водяного охлаждения компании может быть включена в типовые решения если говорить о жидкостном охлаждении всех машин, имеющихся в огромном зале. Отличается ли водяное охлаждение серверов (и фактически установленных в них процессоров) от традиционного водяного охлаждения? На самом деле, это чрезвычайно просто и основано на том же принципе, что и для домашних компьютеров. В дополнение к типичным элементам для этого типа системы (трубопроводная система, теплообменник и блок с жидкостью), также важно использовать небольшое рабочее колесо, которое позволяет контролировать вращение. Стоит добавить, что система водяного охлаждения компании может быть включена в типовые решения Отличается ли водяное охлаждение серверов (и фактически установленных в них процессоров) от традиционного водяного охлаждения? На самом деле, это чрезвычайно просто и основано на том же принципе, что и для домашних компьютеров. В дополнение к типичным элементам для этого типа системы (трубопроводная система, теплообменник и блок с жидкостью), также важно использовать небольшое рабочее колесо, которое позволяет контролировать вращение. Стоит добавить, что система водяного охлаждения компании может быть включена в типовые решения Отличается ли водяное охлаждение серверов (и фактически установленных в них процессоров) от традиционного водяного охлаждения? На самом деле, это чрезвычайно просто и основано на том же принципе, что и для домашних компьютеров. В дополнение к типичным элементам для этого типа системы (трубопроводная система, теплообменник и блок с жидкостью), также важно использовать небольшое рабочее колесо, которое позволяет контролировать вращение. Стоит добавить, что система водяного охлаждения компании может быть включена в типовые решенияподключи и играй. Замена любых компонентов занимает буквально одно мгновение, благодаря использованию быстрых соединителей. В результате только один человек может обрабатывать 50 серверов.


В связи с тем, что жидкость обладает гораздо более высокой тепловой эффективностью, чем воздух, ее использование стало очевидным. Следует помнить, что обеспечение адекватного охлаждения является одним из наиболее важных аспектов этого типа объектов. Прежде всего, центры обработки данных должны быть доступными и высокоэффективными независимо от условий. С другой стороны, однако, их энергоэффективность должна быть тщательно рассмотрена. Многие из вас, безусловно, считают, что высокое энергопотребление является результатом питания оборудования в центрах обработки данных. Однако, правда немного отличается, потому что это питание систем, которые понижают температуру, потребляет до 40% от общего потребления энергии. Нельзя скрывать, что экономия на системах охлаждения не является хорошей идеей, однако правильное управление может сделать экономию не только возможной, но и безопасной. Он состоит в основном из соответствующей конфигурации центра (с учетом максимальной полезности), инвестиций в возобновляемые источники энергии, но, прежде всего, жидкостного охлаждения, что позволяет снизить расходы до 95%. Это также напрямую приводит к энергоэффективности, которая, согласно общедоступным данным, составляет 1,09 PUE (Эффективность использования энергии ).


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

Давайте перейдем к самой фабрике. Площадь объекта составляет 14 тысяч. м², благодаря чему в нем могут разместиться до 100 сотрудников из отдельных производственных бригад. Стоит добавить, что объект был разделен на отдельные лаборатории. Мы найдем там не только аппаратную или программную лабораторию, но и лабораторию, посвященную исследованиям работы серверов при экстремальных температурах. Почему OVH фокусируется на собственном производстве, поскольку подавляющее большинство компаний передают производство на аутсорсинг сторонним компаниям? Преимущества собственного производства видны невооруженным глазом, и все, кажется, понимают их. Это не только возможность быстрого реагирования на изменения рынка, но и строгий контроль спроса на необычные решения своих клиентов или постоянное технологическое совершенствование каждого из элементов. Что больше завод производит до 120000 серверов в год. Однако это число было увеличено до 400 000


Следует также подчеркнуть необычный подход к производству, который предполагает производство только определенного количества серверов без какого-либо излишка продукции. Сборка одного сервера занимает всего 2 минуты. Одна стойка содержит до 40. Это означает, что производство полной серверной стойки занимает около 80 минут. Мы также узнали, что их ежедневное производство не должно превышать максимум 8-12 готовых шкафов, состоящих из 40 машин. Почему? Это очень просто. В такой динамично развивающейся отрасли нельзя допустить каких-либо убытков, которые компания понесет в случае избытка продукции, потому что, что если планы по строительству отдельных элементов изменятся в процессе производства?

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


Работа фабрики в основном сосредоточена на производстве элементов, необходимых для сборки сервера. Помимо внесения непрерывных исправлений и регулярного тестирования в различных условиях (одна из лабораторий для собственного использования имеет мощность около 1 МВт!), Следует также выделить обширную программу восстановления сервера. Это одна из ключевых задач, стоящих перед сотрудниками компании. Восстановление частей с прекращенных серверов является частью бизнес-модели предприятия, которая действительно приносит результаты. Из чего он состоит? Это очень просто. После примерно 4 лет работы не каждый сервер перерабатывается. Прежде всего проверяется его способность продолжать работу и извлекаются только те фрагменты, которые пригодны для дальнейшей эксплуатации. Полученное таким образом оборудование подвергается соответствующим испытаниям, которые очень точно иллюстрируют, они функциональны? В связи с тем, что большинство демонтированных серверов больше не являются последними и наиболее эффективными решениями, это оборудование используется в несколько менее эффективных устройствах, которые, тем не менее, отвечают требованиям менее требовательных клиентов.


Внедрение современных решений и их постоянное совершенствование — сложное искусство, которое, несмотря на многие усилия, не всегда приносит ожидаемые результаты. Сегодня сложно отрицать популярность облачных сервисов, которые становятся все более популярными для клиентов. Стоит подчеркнуть, что, несмотря на общую тенденцию к росту, только небольшая доля предприятий в Польше выбирают этот тип решения. По данным ОГО, в 2017 году только 8% компаний использовали облачные сервисы. Многие потенциальные клиенты не выбирают такие решения по крайней мере по нескольким причинам. Среди наиболее распространенных недостатков они упоминают проблемы безопасности. Вопрос о правилах также остается загадкой, что во многих случаях вызывает некоторые сомнения и вызывает бесчисленные вопросы. Как будет выглядеть дальнейшее развитие облачных сервисов, особенно в Польше? Мы обязательно узнаем в ближайшее время.

Image Colorization (DeOldify)


market-place.ai.ovh.net/
market-place.ai.ovh.net/#!/registration

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

Служба полностью автономна и может использоваться любым оркестратором контейнеров (в OVH или где-либо еще) для организации и обслуживания ваших образов при каждом развертывании контейнера.

labs.ovh.com/private-registry

Служба OVH Managed Kubernetes предлагает вам полностью управляемый кластер, в котором вы выбираете рабочие узлы по своему выбору в каталоге OVH Public Cloud VM constant performance. Теперь мы изучаем лучший способ добавить поддержку для GPU и голых металлических (без виртуализации) рабочих, так что вы можете смешивать и сочетать свои виртуальные машины, для еще более специализированных и мощных конфигураций. Помогите нам сформировать новые возможности нашего предложения Kubernetes, ответив на короткий опрос (рассказывая нам о ваших потребностях в аппаратном и программном обеспечении, ваших конкретных случаях использования...) и у вас будет возможность получить доступ к частной бета-версии в течение лета.

labs.ovh.com/gpu-baremetal-kubernetes-nodes

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

Возобновление расширения OVH остается по цене 2,99 € HT/ год.
Пожалуйста, примите наши извинения за доставленные неудобства.
Доменные имена команды