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

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

По сути, предложение, по словам Алена Фиокко, технического директора OVH, является постоянным кластерным контроллером. Клиенты, которые вносят свои правила использования компьютеров и ресурсов хранения, могут устанавливать их постоянно, даже если они не используют Kubernetes постоянно в OVH. Политика сохраняется.

Номера не нужны клиентам, этот контроллер. «Правда в том, заявляет Fiocco, что нам требуются сравнительно небольшие ресурсы от нас». Однако, как только клиенты используют ресурсы OVH для своего кластера Kubernetes, они платят за фактическое «потребление» или необходимые ресурсы. «В свою очередь, клиенты имеют доступ ко всему общедоступному облаку OVH», согласно CTO, а также к различным виртуальным машинам, например, в OpenStack или VMware.

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

Предложение для разных потребителей Кубернеца
Kubernetes обещает общий стандарт для поставщиков гибридных и мультиоблачных услуг. Являясь одним из немногих сертифицированных поставщиков Cloud Native Computing Foundation (CNCF) в Европе, OVH решила выпустить альтернативу существующим вариантам Kubernetes. Предложение, которое теперь доступно, начинает OVH, чтобы расширить свой облачный портфель 18 октября 2018 года с частной бета-программой. Теперь управляемый сервис Kubernetes состоит из следующих компонентов:

• Балансировщик нагрузки, изначально встроенный в Kubernetes
• Настраиваемые политики для обновлений безопасности
• Выбор между двумя последними версиями Kubernetes, доступными на рынке, в настоящее время 1.11 и 1.12

Преимущества для клиентов следующие:

• Используйте стандартный открытый API, который выигрывает от большого сообщества и широкой экосистемы, включая 627 компаний и проектов, перечисленных на сайте CNCF landscape.cncf.io/. API также предоставляет все преимущества OVH, включая поддержку 24x7, бесплатную защиту от DDoS и доступ к ведущей европейской оптоволоконной сети со скоростью 16 Тбит / с, ведущему европейскому облачному провайдеру.
• В комплекте с Kubernetes-совместимой управляемой службой: хотя службы других поставщиков не работают из-за настройки с некоторыми инструментами, служба OVH Managed Kubernetes полностью совместима с Kubernetes. Например, клиенты могут использовать оригинальное устройство контроля доступа Kubernetes (RBAC).
• Модель биллинга с оплатой по факту использования в публичном облаке OVH обеспечивает прозрачное ценообразование. OVH бесплатно предоставляет программное обеспечение для оркестровки Kubernetes, а также необходимую инфраструктуру. Поэтому клиенты платят только за постоянную систему хранения и вычислительную инфраструктуру, в которой работают их контейнеры, по стандартной цене общедоступного облака OVH и необходимого объема.

Это то, что говорят клиенты
Например, клиенты получают кластер с гарантированной постоянной производительностью ЦП и ОЗУ, начиная с 26,18 евро (включая НДС) в месяц, а инфраструктура, состоящая из пяти рабочих узлов с общим объемом оперативной памяти 35 гигабайт и 10 vCores для 130,90. Евро (с учетом НДС) доступно в месяц. Для клиентов, которые хотят использовать Kubernetes и их контейнеры в облаке OVH, дополнительные расходы не требуются, поскольку входящая и исходящая пропускная способность уже включена.

Три из клиентов, которые уже знают предложение OVH, описывают свое преимущество:

В Saagie мы предлагаем оркестратор Data Labs, который изощренно использует Kubernetes. Мы протестировали несколько управляемых сервисов Kubernetes от других поставщиков. Основанный на стандартах сервис OVH Managed Kubernetes обеспечивает нам отличную мобильность

сказал Юн Чене, технический директор комплексного оператора платформы данных Saagie.

Мы уже пытались построить наш кластер Kubernetes самостоятельно, но мы не смогли сделать это, потому что установка и обслуживание были слишком сложными для нас. Благодаря сервису OVH Managed Kubernetes мы смогли перенести наши приложения в Kubernetes, не беспокоясь об установке и обслуживании платформы. Бета-фаза проекта Kube прошла гладко благодаря присутствию и отзывчивости команды OVH

сказал Винсент Дэви, ответственный за DevOps в ITK, специалисте по решениям для интеллектуального фермерства.

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

говорит Жером Балдуччи, технический директор Whoz, поставщик инструментов для искусственного интеллекта в этой области. HR.

Дальнейшее развитие управляемого сервиса Kubernetes
Управляемая служба Kubernetes уже доступна для всех клиентов через центр обработки данных OVH в Гравелине (Франция) и будет постепенно внедряться в различных регионах OVH Public Cloud в течение следующих нескольких месяцев. Кроме того, он скоро будет совместим с технологией «vRack». Это позволяет клиентам OVH

• Создание гибридной частной инфраструктуры на глобальном уровне в нескольких центрах обработки данных с 28 собственными центрами обработки данных OVH на четырех континентах.
• доступ к кластерам Kubernetes как в частной, так и в стандартной общедоступной сети,
• Благодаря расширению «Облачное соединение OVH» объединяются все имеющиеся у них ресурсы как в облаке OVH, так и на локальном уровне.

www.ovh.com/fr/kubernetes/

On the way to the 1000 stars today with cds, ovh is 7th on the Top 10 Developers on GitHub

www.ovh.ie/ovh-deals/

www.ovh.com/fr/public-cloud/instances/tarifs/

Уважаемый клиент, к сожалению, из-за большого количества запросов, проходящих через наш DNS (213.186.33.99), OVH пришлось приостановить разрешение DNS для следующего DNSBL:
zen.spamhaus.org
pbl.spamhaus.org
sbl.spamhaus.org
xbl.spamhaus.org
multi.surbl.org

Следовательно, запрос к одному из этих DNSBL будет последовательно представлять собой ответ NXDOMAIN по состоянию на 25 февраля 2019 года.
В соответствии с рекомендациями последнего, вам следует использовать собственный распознаватель DNS для использования этих служб, а не общедоступного поставщика DNS:
https://www.spamhaus.org/faq/section/DNSBL%20Usage#261
Спасибо за Ваше понимание.

• added a new 4x10G PNI with ukdsltd at London
• upgraded our PNI with transtelco from 4x10G to 1x100G at Dallas and LosAngeles
• added 100G with TeliaCarrier at Ashburn
• added 100G with vodafone_de at Frankfurt

Управление Kubernetes над Kubernetes было хорошей идеей для компонентов без контроля состояния плоскости управления… но как насчет etcd?


В нашем предыдущем посте мы описали архитектуру Kubinception, как мы запускаем Kubernetes над Kubernetes для компонентов без состояний в плоскостях управления кластерами клиентов. Но как насчет компонента с состоянием, etcd?

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

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


Этот полный подход Kubinception имеет преимущество быть простым, он кажется продолжением того, что мы делаем с компонентами без сохранения состояния. Но если взглянуть на него подробно, он показывает свои недостатки. Развертывание кластера etcd не так просто и просто, как развертывание без сохранения состояния и является критически важным для работы кластера, мы не могли просто обработать его вручную, нам был необходим автоматизированный подход для управления им на более высоком уровне. www.diycode.cc/projects/coreos/etcd-operator

Использование оператора
Мы были не единственными, кто думал, что сложность работы с развертыванием и работой кластера etcd на Kubernetes была чрезмерной, люди из CoreOS заметили это, и в 2016 году они выпустили элегантное решение проблемы: etcd оператор coreos.com/blog/introducing-the-etcd-operator.html

Оператор — это специальный контроллер, который расширяет API Kubernetes для простого создания, настройки и управления экземплярами сложных (часто распределенных) приложений с отслеживанием состояния в Kubernetes. Для записи, понятие оператора было введено CoreOS с оператором etcd.


Оператор etcd управляет кластерами etcd, развернутыми в Kubernetes, и автоматизирует рабочие задачи: создание, уничтожение, изменение размера, аварийное переключение, непрерывное обновление, резервное копирование
kubernetes.io

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

Оператор etcd может быть настроен на использование постоянных томов (PV) для хранения данных, поэтому теоретически проблема была решена. Теоретически, поскольку управление томами не было достаточно зрелым, когда мы тестировали его, и если модуль etcd был убит и переназначен, новый модуль не смог получить свои данные на PV. Таким образом, риск полной потери кворума и блокирования клиентского кластера все еще был у оператора etcd.
kubernetes.io/docs/concepts/storage/persistent-volumes/

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

StatefulSet
Помимо оператора, другим решением было использование StatefulSet, своего рода распределенного развертывания, хорошо подходящего для управления распределенными приложениями с отслеживанием состояния.
kubernetes.io/docs/concepts/workloads/controllers/statefulset/
kubernetes.io/docs/concepts/workloads/controllers/deployment/
github.com/helm/charts/tree/master/incubator/etcd

Существует официальная диаграмма ETCD Helm, которая позволяет развертывать кластеры ETCD в виде StafefulSets, которая обменивает некоторую гибкость оператора и удобство для пользователя на более надежное управление PV, которое гарантирует, что перепланированный модуль etcd будет получать свои данные.


Etcd StatefulSet менее удобен, чем оператор etcd, поскольку он не предлагает простого API для операций, таких как масштабирование, отработка отказа, последовательное обновление или резервное копирование. Взамен вы получаете некоторые реальные улучшения в управлении PV. StatefulSet поддерживает липкую идентификацию для каждой записи etcd, и этот постоянный идентификатор сохраняется при любом перепланировании, что позволяет просто связать его с PV.

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

Постоянные объемы, задержка и простой расчет затрат
Etcd StatefulSet казался хорошим решением… пока мы не начали интенсивно его использовать. В etcd StatefulSet используются PV, то есть тома сетевого хранилища. И т.д.DD довольно чувствительны к задержке в сети, ее производительность сильно ухудшается, когда сталкивается с задержкой.

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

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

С Kubinception мы пытались мыслить нестандартно, казалось, что для etcd нам нужно было выбраться из этой коробки еще раз.

Мультитенантный кластер etcd
Если мы не хотели развертывать etcd внутри Kubernetes, альтернативой было бы развернуть его снаружи. Мы решили развернуть мультитенантный кластер etcd на выделенных серверах. Все клиентские кластеры будут использовать один и тот же ETCD, каждый сервер API получает свое место в этом мультитенантном кластере etcd.



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

Что дальше?
В следующих статьях из серии Kubernetes мы углубимся в другие аспекты построения OVH Managed Kubernetes и дадим клавиатуру некоторым из наших бета-клиентов, чтобы рассказать о своем опыте использования сервиса.

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

Управление выпусками на корпоративном программном обеспечении — непростая задача: обновлять инфраструктуры, справляться со страхом, что редактор программного обеспечения не будет поддерживаться, обновлять лицензии для обеспечения совместимости с новыми версиями и принимать все меры предосторожности для отката, если что-то не работает, как ожидается…

С OVH Private Cloud мы избавим вас от этой сложности. Мы справляемся с этим дорогостоящим и напряженным аспектом, чтобы вы могли сосредоточиться на своем бизнесе и своем производстве.

Но это не значит, что это не проблема для нас.

Обновление сотен vSphere 5.5 до 6.0
vSphere является ведущим продуктом предложения Private Cloud, входящего в пакет SDDC, предоставляемый VMware. vSphere — это программное обеспечение, позволяющее пользователю управлять своими хостами, хранилищем, сетью… С помощью клиента он может создавать кластеры с этими ресурсами для надежного, стабильного и высокодоступного хостинга.

С сентября 2018 года vSphere (vCenter, ESXi…) версии 5.5 прекращает поддержку VMware. Владея безопасностью и стабильностью инфраструктур частного облака, мы начали процессы обновления для всех vCenter.


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

Вот так нам удалось обновить 850 vCenter с версии 5.5 до 6.0 за 4 недели. Другими словами, более 210 vCenter в неделю, 30 vCenter в день, с командой из 10 человек, которые следят за этим обслуживанием в фоновом режиме, не оказывая никакого влияния на производительность клиентов.


Наша команда разработчиков разработала и создала набор сценариев (которые мы называем внутренне «роботом») для автоматизации обновлений vCenter несколько лет назад. Этот робот сильно развился с момента появления продукта Private Cloud и следует за нами с версии 4.1 до 6.5, которая находится в стадии разработки.

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

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

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

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

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


Мы создали этого робота обновления в роботе-оркестраторе, который, согласно введенным параметрам, будет создавать задачи обновления для каждого частного облака, связанного с техническим обслуживанием, и планировать его на автоматические даты, в течение как минимум 72 часов с момента рассмотрения для клиента, но также количество обновлений, запущенных по часам, и критических периодов (таких как Черная пятница или Зимние распродажи). Клиенты могут перепланировать свои обновления с помощью диспетчера в части «Операции», чтобы выполнить обслуживание в более удобное время для их производства.


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


Подводя итог, мы перешли от необходимости автоматизации операции обновления vCenter, которая должна занимать не менее 12 часов на vCenter, к первой версии автоматизации, которая позволяет выполнить эту операцию за 4 часа, но с слишком высокий уровень ошибок (20%) из-за повторяющихся ошибок, которые должны были быть исправлены SRE вручную. Теперь вторая версия является надежной, надежной и стабильной, избегая известных проблем и создавая только редкие и уникальные проблемы, которые будут исправлены в автоматизации за кураторский проход.

Что дальше?
В последующие месяцы последуют другие виды обслуживания, обновления хоста с версии 5.5 до 6.0, обновления нашего варианта резервного копирования Veeam с версии 8.0 до 9.5, обновления нашего варианта Zerto с 5.0 до 5.5 и множество других обновлений наших внутренних машин. обеспечить процедуру аудита PCI-DSS.

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

Согласно прогнозам IDC, расходы на приобретение искусственного интеллекта и когнитивных систем в период до 2022 года составят 77,6 млрд долларов. Эти инвестиции в основном пойдут на пользу индустрии программного обеспечения, в частности, разработке диалоговых приложений, машинного обучения и решений для глубокого обучения. Чтобы отреагировать на эти новые применения, OVH собрала полный спектр решений для поддержки своих клиентов в их различных проектах в области искусственного интеллекта.

OVH делает новый шаг в сотрудничестве с NVIDIA, став первым европейским облачным провайдером, ставшим проверенным партнером платформы для NVIDIA GPU Cloud (NGC). Это укрепляет его позиции в качестве основного участника процесса демократизации технологий искусственного интеллекта.

Пользователи OVH теперь могут запускать программное обеспечение из реестра контейнеров NGC, который предоставляет полный каталог программного обеспечения AI, оптимизированного для графических процессоров NVIDIA, в инфраструктуре OVH. Клиенты OVH могут развернуть проекты по искусственному интеллекту, ускоренной обработке данных и высокопроизводительным вычислениям в облачной инфраструктуре OVH за считанные минуты благодаря программному обеспечению plug and play, доступному от NGC.

«NVIDIA и OVH имеют общую цель — сделать ИИ более доступным и простым в использовании», — сказал Серж Паларик, вице-президент по развитию корпоративного бизнеса, NVIDIA. «Используя оптимизированное для GPU программное обеспечение от NGC на экземплярах NVIDIA GPU и серверы
NVIDIA DGX-1 с открытым исходным кодом в облачной инфраструктуре OVH, пользователи могут быстро запускать и запускать свои проекты ИИ с невероятной производительностью».

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

• Общедоступные облачные серверы на базе новейших графических процессоров NVIDIA Tesla V100 предлагают отличное соотношение цены и производительности и особенно подходят для стартапов.
• Выделенный пул серверов NVIDIA DGX-1, каждый из которых включает в себя восемь графических процессоров NVIDIA V100 Tensor Core последнего поколения, связанных с технологией NVLink, специально разработан для машинного обучения и глубокого обучения.

Различные варианты использования для разных клиентов
Новые предложения были добавлены в дополнение к большому каталогу данных OVH. Например, OVH Metrics — это специальное предложение IoT, а платформа данных OVH Analytics позволяет развертывать кластеры Hadoop всего за несколько минут.

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

Systran, мировой лидер в области переводческих технологий более 50 лет, также использовал инфраструктуру OVH для интенсивного расчета нейронных сетей, применяемых для более чем 40 языков. Революционная вычислительная производительность системы NVIDIA DGX-1 для искусственного интеллекта позволила Systran индустриализировать производство, а также обучить и обновить более 200 общих и специфических моделей перевода.

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

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