Selfheal at Webhosting - внешняя часть

Вступление

С почти 6000000 веб-сайтов, размещенных на более чем 15000 серверах, команда OVHcloud Webhosting SRE управляет множеством предупреждений в течение рабочего дня.

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

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



Что такое самоисцеление ?

Selfheal относится к автоматизации решения оповещения в производственных условиях. Автоматизированный процесс может исправить известные проблемы без вмешательства администратора.

Зачем нам это нужно?

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

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

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

Оборудование

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

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

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

Программного обеспечения

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

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

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

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

Selfheal на веб — хостинг

В Webhosting мы разделяем selfheal на две части:

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

В этой статье мы обсудим внешнюю часть.

Внешнее самоисцеление

Контекст:

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

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

Мы могли выбрать существующий инструмент (например, StackStorm), но мы этого не сделали. Вот почему:

  • Создание микросервисов в OVH действительно просто и быстро.
  • Структурированные, подробные и простые журналы с уникальным идентификатором uuid для отслеживания каждой задачи самовосстановления в нашей внутренней системе журналов (что позволяет нам легко строить графики). 
  • Простая интеграция с нашими существующими инструментами и экосистемой 
  • Быстрое и простое развертывание во всех наших регионах
  • Простой CI / CD (модульное тестирование и т. Д.)
  • Пользовательские уведомления, например чат-бот
  • Интеллект и история



Как это устроено

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

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

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

Все выполненные действия сохраняются. Это избавляет от необходимости выполнять одно и то же исправление несколько раз на данном сервере и выявлять сложные проблемы.

Конкретный пример замены неисправного диска

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

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

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

  1. Поставьте сервер на обслуживание, чтобы истощить запросы клиентов
  2. Создайте запрос центра обработки данных на замену жесткого диска
  3. Переустановите сервер

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

Первое, что мы сделали, — автоматизировали проверку зондом.

Затем мы решили автоматизировать все это с помощью простого рабочего процесса в нашем приложении с самовосстановлением, а затем организовать вызов API.



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

Заключить

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

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

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

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

Как работает PCI-Express и почему вам это нужно? #GPU



Что такое PCI-Express?

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

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



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

Если вы используете графические процессоры, вы должны знать, что есть 2 способа подключить их к материнской плате, чтобы позволить ей подключаться к другим компонентам (сети, ЦП, устройству хранения). Решение 1 — через PCI Express, а решение 2 — через SXM2 . Мы поговорим о SXM2 в будущем. Сегодня мы сосредоточимся на PCI Express . Это связано с тем, что он сильно зависит от выбора соседнего оборудования, такого как шина PCI или ЦП.



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

Как работает PCI-Express и почему нужно заботиться о количестве линий PCIe? Что такое линии PCI-Express и есть ли связанные с этим ограничения ЦП?

Каждый GPU V100 использует 16 линий PCI-e. Что именно это означает?

Выписка из NVidia V100 продукта спецификации листа

В «х16» означает, что PCIe имеет 16 выделенных полос. Итак… следующий вопрос: что такое полоса PCI Express?

Что такое линия PCI Express?

2 устройства PCI Express с его внутренним соединением: рисунок, вдохновленный потрясающей статьей - что такое чипсет и почему меня это должно волновать

Дорожки PCIe используются для связи между устройствами PCIe или между PCIe и ЦП. Полоса состоит из двух проводов: один для входящей связи, а другой с удвоенной пропускной способностью трафика для исходящего.

Связь по дорожкам похожа на связь сетевого уровня 1 — все дело в максимально быстрой передаче битов по электрическим проводам! Однако метод, используемый для PCIe Link, немного отличается, поскольку устройство PCIe состоит из линий xN. В нашем предыдущем примере N = 16, но это может быть любая степень двойки от 1 до 16 (1/2/4/8/16).

Итак… если PCIe похож на сетевую архитектуру, это означает, что уровни PCIe существуют, не так ли?

Да! Вы правы, PCIe имеет 4 слоя:



Физический уровень (также известный как уровень больших переговоров )

Физический уровень (PL) несет ответственность за ведение переговоров условия для получения исходных пакетов (PLP для пакетов физического уровня) , то есть ширина полосы частот , и с другим устройством.

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

Пакеты, полученные на физическом уровне (также известный как PHY) , поступают от других устройств PCIe или из системы (например, через память прямого доступа — DAM или от ЦП) и инкапсулируются в кадр.

Назначение Start-of-Frame — сказать: «Я отправляю вам данные, это начало», и для этого требуется всего 1 байт!


Слово « конец кадра» также составляет 1 байт, чтобы сказать «до свидания, я сделал это».


Этот уровень реализует декодирование 8b / 10b или 128b / 130b, которое мы объясним позже и в основном используется для восстановления тактовой частоты.

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

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

Layer Data Link Packet
 затем следуют уровне транзакций пакетов , а затем закрывается с МЦРК (Local Циклические Redundancy Check) и используется для проверки слоя транзакции пакета (значение фактического Payload) целостность.

Если LCRC подтвержден, то уровень звена данных отправляет сигнал ACK (ACKnowledge) на передатчик через физический уровень . В противном случае он отправляет сигнал NAK (Not AcKnowledge) на передатчик, который повторно отправит кадр, связанный с порядковым номером, для повторной попытки; эта часть обрабатывает буфер воспроизведения на стороне получателя .

Уровень транзакций

Уровень транзакции отвечает за управление фактической полезной нагрузкой (заголовок + данные), а также (необязательный) дайджест сообщения ECRC (сквозная циклическая проверка избыточности) . Этот пакет уровня транзакции поступает с уровня звена данных, где он декапсулирован .

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

Заголовок описывает тип транзакции, например:

  • Операция памяти
  • Транзакция ввода-вывода
  • Транзакция конфигурации
  • или сообщение транзакции



Уровень приложения

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

Как PCIe общается с остальным миром?

PCIe Link использует концепцию коммутации пакетов, используемую в сети в полнодуплексном режиме.

Устройство PCIe имеет внутренние часы для управления циклами передачи данных PCIe Этот цикл передачи данных также организуется благодаря ссылочным часам. Последний отправляет сигнал через выделенную полосу (которая не является частью x1 / 2/4/8/16/32, упомянутой выше) . Эти часы помогут как принимающим, так и передающим устройствам синхронизироваться для передачи пакетов.

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

x16 означает 16 линий параллельной связи по протоколу PCIe 3 поколения

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

Для обеспечения целостности устройство PCIe использует кодировку 8b / 10b для PCIe поколений 1 и 2 или схему кодирования 128b / 130b для поколений 3 и 4.

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

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

Быстрые примеры

Давайте упростим это на примере 8b / 10b: согласно IEEE 802.3, пункт 36, таблица 36–1a на основе спецификаций Ethernet здесь представляет собой кодировку таблицы 8b / 10b:

IEEE 802.3 пункт 36, таблица 36–1a - таблица кодирования 8b / 10b

Итак, как получатель может различить всех, кто повторяет 0 (имя кодовой группы D0.0)?



Кодирование 8b / 10b состоит из кодировок 5b / 6b + 3b / 4b.

Следовательно, 00000 000 будет закодировано в 100111 0100, 5 первых битов исходных данных 00000 будут закодированы в 100111 с использованием кодирования 5b / 6b ( rd + ); то же самое касается второй группы из 3 бит исходных данных 000, закодированных в 0100 с использованием кодирования 3b / 4b ( rd- ).

Это могло бы быть также 5b / 6b кодирования й + и 3b / 4b кодирование RD- решений 00000 000 превращается в 011000 1011

Следовательно, исходные данные, которые были 8-битными, теперь являются 10-битными из-за управления битами (1 управляющий бит для 5b / 6b и 1 для 3b / 4b).


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

PCIe поколения 1 и 2 были разработаны с кодированием 8b / 10b,
 что означает, что фактические передаваемые данные составляли только 80% от общей нагрузки (поскольку 20% — 2 бита используются для синхронизации часов).

PCIe Gen3 и 4 были разработаны с 128b / 130b,
 что означает, что управляющие биты теперь составляют только 1,56% полезной нагрузки. Неплохо, не правда ли?

Давайте вместе рассчитаем пропускную способность PCIe

Вот таблица спецификаций версий PCIe



Консорциум PCI-SIG Теоретическая пропускная способность PCIe / Технические характеристики полосы / пути



консорциум PCI-SIG PCIe теоретическая необработанная спецификация скорости передачи данных. Чтобы получить такие числа, давайте посмотрим на общую формулу пропускной способности:



  • BW означает пропускную способность
  • MT / s: мегапереводы в секунду
  • Кодирование может быть 4b / 5b /, 8b / 10b, 128b / 130b,…

Для PCIe v1.0:





Таким образом, с 16 полосами для NVIDIA V100, подключенными к PCIe v3.0 , эффективная скорость передачи данных (пропускная способность данных) составляет почти 16 ГБ / с / путь ( фактическая пропускная способность составляет 15,75 ГБ / с / путь ).

Вы должны быть осторожны, чтобы не запутаться, поскольку общую пропускную способность также можно интерпретировать как двухстороннюю пропускную способность; в этом случае мы считаем, что общая пропускная способность x16 составляет около 32 ГБ / с.

Примечание: Еще один элементкоторый мы не рассматривал, что максимальные потребности теоретической пропускной способности будут снижены примерно1 Гбит / с для протоколов коррекции ошибок ( ЦЭР и МЦРК ), а также в заголовках ( Начальный тег, последовательность теги, заголовок ) иНакладные расходы на нижний колонтитул ( конечный тег) объяснялись ранее в этом сообщении в блоге.

В заключение

Мы видели, что PCI Express сильно изменился и основан на тех же концепциях, что и сеть. Чтобы извлечь максимум из устройств PCIe, необходимо понимать основы базовой инфраструктуры.

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

Подводить итоги:

Друзья не позволяют друзьям создавать собственные хосты на GPU

Спонсорство JupyterCon 2020: обмен ценностями и поддержка инфраструктуры

Повторяя вчерашнее объявление в блоге Jupyter, OVHcloud гордится тем, что поддерживает JupyterCon в качестве платинового спонсора и донора инфраструктуры.



Как вы, наверное, знаете, Jupyter стал огромным фактором развития сообщества программистов, поддерживая более 140 ядер, таких как Python, R, Julia, Spark, Sas, Haskell, Ruby, C ++, Go и т. Д.

Проект Jupyter воплощает в себе открытые и совместные сообщества разработчиков, которые являются ключевыми ценностями в структуре нашей собственной экосистемы.

В последние годы Jupyter и OVHcloud работали рука об руку над такими проектами, как Mybinder.org и NbViewer. Я хотел бы поблагодарить совет директоров Jupyter и NumFocus за их открытость и доверие, которые сделали возможным такое успешное партнерство.

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

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

Лидер в Европе в рейтинге Forrester Wave ™: услуги размещенного частного облака в Европе, второй квартал 2020 г.



OVHcloud, европейский лидер в области размещенного частного облака!

OVHcloud был признан лидером на европейском рынке размещенного частного облака согласно последнему отчету Forrester о размещенных частных облачных услугах в Европе, второй квартал 2020 года. Нас отметили за способность унифицировать услуги при обеспечении эмансипированного европейского предложения в соответствии с Законом об облачных технологиях.

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

Forrester Wave ™

В OVHcloud мы являемся глобальным облачным игроком, предоставляющим полную свободу выбора своим клиентам через 4 категории продуктов (Hosted Private Cloud, Baremetal Cloud, Public Cloud и Web Cloud), которые полностью взаимосвязаны и предназначены для всех вариантов использования клиентов.

В отчете Forrester содержится оценка нашего размещенного частного облака и наших предложений Baremetal.

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

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

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

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

Четкое видение будущего рынка размещенного частного облака

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

Наши решения OVHcloud Hosted Private Cloud основаны на ведущих решениях на рынке  (OVHcloud — проверенный поставщик облачных услуг VMware) и  основаны на  новейших аппаратных  технологиях (OVHcloud проектирует и создает собственные серверы и центры обработки данных).

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

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

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

Строим будущее вместе с экосистемой OVHcloud

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

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

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

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

Вы хотите знать больше?

Если вы хотите получить более подробную информацию о службах размещенного частного облака OVHcloud и загрузить анализ Forrester Wave ™, щелкните здесь.

Празднование присоединения 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 в конце этого года!

Переход к хранилищу Ceph нового поколения в OVHcloud с LXD

Вступление

Меня зовут Филип Дорош. Я работаю в OVHcloud с 2017 года инженером DevOps. Сегодня я хочу рассказать вам историю о том, как мы развернули Ceph следующего поколения в OVHcloud. Но сначала несколько слов о Ceph: Ceph — это программно определяемое решение для хранения данных, которое поддерживает дополнительные тома публичного облака OVHcloud, а также наш продукт Cloud Disk Array. Но я не буду утомлять вас маркетинговыми вещами — давайте начнем!



Похоже, это интересная задача ...

Полтора года назад мы начали очень знакомый спринт. Помимо обычных вещей, с которыми нам приходится иметь дело, была одна задача, которая выглядела немного интереснее. Заголовок гласил: « Оцените, можем ли мы запускать новые версии Ceph на нашем текущем программном обеспечении ». Нам нужны были более новые версии Ceph и Bluestore для создания решения Ceph следующего поколения со всеми флеш-хранилищами.

Наше программное решение (которое мы называем устаревшим решением) основано на Docker. Звучит действительно круто, но мы запускаем Docker немного иначе, чем по назначению. Наши контейнеры очень сохраняют состояние. Мы запускаем полноценную систему инициализации внутри контейнера в качестве точки входа в докер. Затем эта система инициализации запускает все необходимое программное обеспечение внутри контейнера, включая Puppet, который мы используем для управления «вещами». Похоже, мы используем контейнеры Docker так же, как контейнеры LXC, не так ли?…

Наша унаследованная инфраструктура Ceph (аллегория)

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

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

Второй вариант — запустить Ceph с супервизором внутри контейнера Docker. Хотя это звучит как план, даже в документации supervisord четко указано, что supervisord «не предназначен для запуска вместо init как« process id 1 ».». Так что это тоже явно не вариант.

Нам нужен был systemd!

На этом этапе стало ясно, что нам нужно решение, позволяющее запускать systemd как внутри контейнера, так и на хосте. Похоже, настало идеальное время для перехода на совершенно новое решение — решение, которое было разработано для запуска полной ОС внутри контейнера. Поскольку наш Docker использовал бэкэнд LXC, это было естественным выбором для оценки LXC. В нем были все необходимые функции, но с LXC нам пришлось бы самостоятельно кодировать всю автоматизацию, связанную с контейнерами. Но можно ли избежать всей этой дополнительной работы? Оказывается, может…

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

Поэтому я переустановил свои серверы разработчиков с выпуском Ubuntu Server LTS и установил на них LXD.



LXD имеет все необходимое для создания полнофункциональных кластеров Ceph:

  • он поддерживает «толстые» контейнеры с отслеживанием состояния,
  • он поддерживает systemd внутри контейнера,
  • он поддерживает образы контейнеров, поэтому мы можем подготовить индивидуальные изображения и без проблем использовать их,
  • передача целых блочных устройств в контейнеры,
  • передача обычных каталогов в контейнеры,
  • поддержка простого запуска, остановки, перезапуска контейнера,
  • REST API, который будет рассмотрен в следующих частях статьи,
  • поддержка нескольких сетевых интерфейсов в контейнерах с использованием macvlan.

После нескольких часов ручной работы у меня был кластер Ceph, на котором запущен выпуск Mimic внутри контейнеров LXD. Я набрал ceph health и получил «HEALTH_OK». Приятно! Это сработало отлично.

Как нам это индустриализировать?

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

Демон LXD предоставляет удобный REST API, который мы использовали для создания нашего модуля Puppet. Вы можете общаться с API локально через сокет unix и через сеть, если вы настроили его раскрытие. Для использования в модуле было действительно удобно использовать команду запроса lxc, которая работает, отправляя необработанные запросы в LXD через сокет unix. Модуль теперь имеет открытый исходный код на GitHub, поэтому вы можете скачать его и поиграть с ним. Он позволяет настраивать основные параметры LXD, а также создавать контейнеры, профили, пулы хранения и т. Д.

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



Модуль LXD Puppet на момент написания этого документа предоставляет следующие определения:

  • lxd :: profile
  • lxd :: изображение
  • lxd :: хранилище
  • lxd :: container

Для получения полной справки посетите его страницу GitHub — github.com/ovh/lxd-puppet-module.

Ручная установка VS Автоматическая установка с Puppet

Я покажу вам простой пример того, как создать точно такую ​​же настройку вручную, а затем снова автоматически с помощью Puppet. Для целей этой статьи я создал новый экземпляр Public Cloud с Ubuntu 18.04, один дополнительный диск и уже настроенное мостовое устройство br0. Предположим, есть также DHCP-сервер, прослушивающий интерфейс br0.

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

root @ ubuntu: ~ # wget https://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64-root.tar.xz 
root @ ubuntu: ~ # wget https: // cloud-images .ubuntu.com / bionic / current / bionic-server-cloudimg-amd64-lxd.tar.xz 
root @ ubuntu: ~ # mkdir -p ubuntu1804 / rootfs 
root @ ubuntu: ~ # tar -xf bionic-server-cloudimg-amd64 -lxd.tar.xz -C ubuntu1804 / 
root @ ubuntu: ~ # tar -xf bionic-server-cloudimg-amd64-root.tar.xz -C ubuntu1804 / rootfs / 
root @ ubuntu: ~ # cd ubuntu1804 / 
root @ ubuntu : ~ / ubuntu1804 # tar -czf ../ubuntu1804.tar.gz *


В конце вы получите образ ubuntu1804.tar.gz, который можно использовать с LXD. Для целей этой статьи я поместил это изображение в каталог, доступный через HTTP, например: example.net/lxd-image/

Ручная настройка

Первым делом давайте установим LXD.

root @ ubuntu: ~ # apt install lxd

Во время установки пакета вы увидите сообщение: «Чтобы пройти начальную конфигурацию LXD, запустите: lxd init», но мы просто сделаем все шаги вручную.

Следующим шагом будет добавление нового пула хранения.

root @ ubuntu: ~ # lxc storage create default dir source = / var / lib / lxd / storage-pools / 
default Создание пула хранения по умолчанию


Затем создайте собственный профиль, который будет иметь: переменную окружения http_proxy, установленную на ”, ограничение памяти 2 ГБ, крыши в пуле хранения по умолчанию и eth0, который будет частью моста br0.

root@ubuntu:~# lxc profile create customprofile
Profile customprofile created
root@ubuntu:~# lxc profile device add customprofile root disk path=/ pool=default
Device root added to customprofile
root@ubuntu:~# lxc profile device add customprofile eth0 nic nictype=bridged parent=br0
Device eth0 added to customprofile
root@ubuntu:~# lxc profile set customprofile limits.memory 2GB


Распечатываем весь профиль, чтобы проверить, все ли в порядке:

root@ubuntu:~# lxc profile show customprofile
config:
  environment.http_proxy: ""
  limits.memory: 2GB
description: ""
devices:
  eth0:
    nictype: bridged
    parent: br0
    type: nic
  root:
    path: /
    pool: default
    type: disk
name: customprofile
used_by: []


Затем давайте загрузим изображение LXD в формате Unified Tarball:

root@ubuntu:~# wget -O /tmp/ubuntu1804.tar.gz http://example.net/lxd-images/ubuntu1804.tar.gz


И импортируйте его:

root@ubuntu:~# lxc image import /tmp/ubuntu1804.tar.gz --alias ubuntu1804
Image imported with fingerprint: dc6f4c678e68cfd4d166afbaddf5287b65d2327659a6d51264ee05774c819e70


Когда все будет готово, давайте создадим наш первый контейнер:

root@ubuntu:~# lxc init ubuntu1804 container01 --profile customprofile
Creating container01


Теперь давайте добавим несколько каталогов хоста в контейнер:
обратите внимание, что вы должны установить правильного владельца каталога на хосте!

root@ubuntu:~# mkdir /srv/log01
root@ubuntu:~# lxc config device add container01 log disk source=/srv/log01 path=/var/log/


И в качестве последнего штриха добавьте в контейнер раздел хоста:

root@ubuntu:~# lxc config device add container01 bluestore unix-block source=/dev/sdb1 path=/dev/bluestore


/ dev / sdb1 будет доступен внутри контейнера. Мы используем его для передачи устройств для Ceph's Bluestore в контейнер.

Контейнер готов к запуску.

root@ubuntu:~# lxc start container01


Вуаля! Контейнер запущен и работает. Мы настраиваем наши контейнеры так же, как указано выше.

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

Автоматическая установка с Puppet

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

Затем создайте новый класс или добавьте его к одному из существующих классов; все, что вам подходит.



Я подключил его к своему марионеточному серверу. Обратите внимание, что я использую мостовое устройство br0, которое было подготовлено ранее другими модулями, и что изображения LXD размещаются на веб-сервере example.net/lxd-images/ в виде унифицированных тарболов.

Полный пример модуля, использующего модуль LXD Puppet:

class mymodule { 
 
    class {':: lxd':} 
 
    lxd :: storage {'default': 
        driver => 'dir', 
        config => { 
            'source' => '/ var / lib / lxd / storage-pools / default ' 
        } 
    } 
 
    lxd :: profile {' exampleprofile ': sure 
        =>' present ', 
        config => { 
            ' environment.http_proxy '=>' ', 
            ' limits.memory '=>' 2GB ', 
        }, 
        devices => { 
            'root' => { 
                'path' => '/', 
                'pool' => 'default',
                'type' => 'disk', 
            }, 
            'eth0' => {
                'nictype' => 'bridged', 
                'parent' => 'br0', 
                'type' => 'nic', 
            } 
        } 
    } 
 
    lxd :: image {'ubuntu1804': sure 
        => 'present', 
        repo_url => ' http://example.net/lxd-images/ ', 
        image_file =>' ubuntu1804.tar.gz ', 
        image_alias =>' ubuntu1804 ', 
    } 
 
    lxd :: container {' container01 ': 
        state =>' start ', 
        config => { 
            'user.somecustomconfig' => 'Моя потрясающая пользовательская переменная env',
        }, 
        profiles => ['exampleprofile'], 
        image => 'ubuntu1804',
        устройства => { 
            'log' => { 
                'path' => '/ var / log /', 
                'source' => '/ srv / log01', 
                'type' => 'disk', 
            }, 
            'bluestore' = > { 
                'путь' => '/ dev / bluestore', 
                'source' => '/ dev / sdb1', 
                'type' => 'unix-block', 
            } 
        } 
    } 
}


Теперь осталось только запустить марионеточный агент на машине. Он применит желаемое состояние:

root@ubuntu:~# puppet agent -t
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Retrieving locales
Info: Loading facts
Info: Caching catalog for ubuntu.openstacklocal
Info: Applying configuration version '1588767214'
Notice: /Stage[main]/Lxd::Install/Package[lxd]/ensure: created
Notice: /Stage[main]/Lxd::Config/Lxd_config[global_images.auto_update_interval]/ensure: created
Notice: /Stage[main]/Mymodule/Lxd::Storage[default]/Lxd_storage[default]/ensure: created
Notice: /Stage[main]/Mymodule/Lxd::Profile[exampleprofile]/Lxd_profile[exampleprofile]/ensure: created
Notice: /Stage[main]/Mymodule/Lxd::Image[ubuntu1804]/Exec[lxd image present http://example.net/lxd-images//ubuntu1804.tar.gz]/returns: executed successfully
Notice: /Stage[main]/Mymodule/Lxd::Container[container01]/Lxd_container[container01]/ensure: created
Notice: Applied catalog in 37.56 seconds


В конце концов, у вас будет запущен новый контейнер:

root@ubuntu:~# lxc ls
+-------------+---------+--------------------+------+------------+-----------+
|    NAME     |  STATE  |        IPV4        | IPV6 |    TYPE    | SNAPSHOTS |
+-------------+---------+--------------------+------+------------+-----------+
| container01 | RUNNING | 192.168.0.5 (eth0) |      | PERSISTENT | 0         |
+-------------+---------+--------------------+------+------------+-----------+


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



Как это хорошо !?

Я призываю всех внести свой вклад в модуль или поставить ему звезду на GitHub, если вы сочтете его полезным.

Планы на будущее

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

В будущем мы планируем перенести всю нашу устаревшую инфраструктуру на новое решение на основе LXD. Это будет гигантский проект для миграции: более 50 ПБ размещается на более чем 2000 выделенных серверах, но это уже история для другого раза.

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

Улучшения Ingress API

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

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

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

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

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

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

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

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

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



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

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

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

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

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


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





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

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

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

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



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

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



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

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

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

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

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

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



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



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

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

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

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



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

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



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

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

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


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

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

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




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



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

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

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

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



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



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

Эта проблема

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

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

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

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

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

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

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

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

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

Что нам нужно

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

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



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

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

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

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

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



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

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

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

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

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

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

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

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



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

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

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

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

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

Почему?

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



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

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

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

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

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

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

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

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



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



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

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

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

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



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



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



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

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

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

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