Гибкая телеметрия в OVHCloud - Часть III

Эта статья является третьей в серии статей, мы рекомендуем сначала прочитать часть 1 и часть 2:

  • Рождение гибкой телеметрии в OVHcloud — Часть I
  • Гибкая телеметрия в OVHCloud — Часть II

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

Макро и Микровидение

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



Микровидение



Три блока данных

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



BurdownChart

(1) Это прогресс текущего спринта и его процент завершения. Процент выполнения просто вычисляется:



(2) Это показывает, сколько раз команда разработчиков выходила из спринта, чтобы что-то исправить, и время завершения. На прилагаемом графике показаны пиковые дни, когда команда была мобилизована.



Чтобы сообщить об этом типе информации:

  • Команды добавляют в поле «Ярлык» JIRA заголовок: препятствие.
  • Они регистрируют время, проведенное в поле «Журнал работы» в JIRA.



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

NB: Важно отделить спринт от препятствий. Эти две части информации позволяют сравнить «ожидаемое» и «неожиданное». Это позволяет предложить 2 типа графиков.

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



Природа препятствия

Пример: мы предоставляем 30 часов на исправление ошибок во время спринтов; должны ли мы сосредоточиться на создании чего-то нового или сокращении технического долга?

Вывод: Сегодня Agile-телеметрию используют 19 команд в OVHCloud. Это облегчает и позволяет нам измерять производительность и прогресс команд удаленно и в режиме реального времени. Он также предоставляет нам актуальную информацию, необходимую для реализации наших проектов. Именно эта методология получила награду Innovations Awards для сотрудников OVHCloud.

Если вы хотите погрузиться в Agile Telemetry, вы можете сделать это прямо сейчас!!! Просто возьмите нашу панель инструментов с открытым исходным кодом и нашего бота Jerem — github.com/ovh/jerem.

ML Serving: облачный инструмент для развертывания машинного обучения

Сегодня мы рады объявить о выпуске нового продукта Public Cloud . Чтобы ускорить и упростить ваши проекты машинного обучения, мы вводим ML Serving .

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



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

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

Дизайн обслуживания ML

Служба ML была разработана для удовлетворения следующих требований:

  • Легкость использования
  • Управление версиями модели
  • Стратегии развертывания
  • Простота доступа
  • Высокая доступность
  • Обратимость
  • Безопасность

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

  • Среда выполнения обслуживания: обрабатывает фактический вывод модели.
  • Центр обслуживания: обеспечивает оркестровку модели и управление

Время выполнения обслуживания

Компонент Serving Runtime является автономным и нацелен на упрощение использования и доступа. Таким образом, его две основные задачи — загрузить модели и раскрыть их.

Простота доступа

Мы обнаружили, что самый простой способ раскрыть модель — использовать HTTP API. Затем он легко интегрируется в любое бизнес-приложение. Среда выполнения обслуживания предоставляет API, ограниченный тем, что важно — конечную точку для описания модели и другую для ее оценки.

Входные данные API по умолчанию отформатированы как тензоры JSON. Ниже приведен пример входной полезной нагрузки для набора данных Титаника при оценке шансов на выживание двух пассажиров:

{
  "fare" : [ [ 7 ], [ 9 ] ],   
  "sex" : [ [ "male" ], [ "female" ] ],   
  "embarked" : [ [ "Q"], ["S" ] ],   
  "pclass" : [ [ "3" ], [ "2" ] ],   
  "age" : [ [ 27 ], [ 38 ] ] 
}


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

{   
  "fare" : 7,   
  "sex" : "male",   
  "embarked" : "Q",   
  "pclass" :"3",   
  "age" : 27 
}


ML Serving также поддерживает распространенные форматы изображений, такие как JPG и PNG.

Легкость использования

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

  • Tensorflow SavedModel
  • HDF5
  • ONNX
  • PMML

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

Гибкость

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

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

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

Центр обслуживания

Компонент Serving Hub направлен на удовлетворение всех требований производственного уровня: управление версиями, безопасность, развертывание и высокая доступность.

Его основные задачи — это упаковка Serving Runtime с экспортированными моделями в образ Docker, а затем их развертывание в кластере Kubernetes. В глобальном масштабе компонент во многом полагается на свои функции Kubernetes. Например, для концентратора не требуется база данных, поскольку вся информация о моделях и развертываниях хранится в виде настраиваемых ресурсов Kubernetes.

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



При использовании API управления моделями развертывание модели так же просто, как предоставление имени и пути к файлам модели в серверной части хранилища. Затем Serving Hub запускает рабочий процесс для создания образа Docker, который упаковывает файл с экземпляром Serving Runtime перед его отправкой в ​​реестр. Образ является автономным, и его можно просто запустить с помощью Docker.

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

Предустановленные изображения

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

В настоящее время в OVHCloud доступны две модели: анализ тональности для английского языка и еще одна для французского языка. Оба основаны на знаменитой архитектуре BERT (и ее французского аналога CamemBERT), поддерживаемой Hugging Face, и тонко настроены для анализа настроений с использованием Stanford Sentiment Treebank (1).

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

Следующие шаги

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

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

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

Обслуживание OVHcloud ML:

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

Конфиденциальность и удаленная работа - не забывайте о безопасности ваших данных

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



Удаленная работа стала стандартом во всем мире, как никогда раньше. В срочном порядке компаниям пришлось очень быстро развернуть новые цифровые инструменты, чтобы адаптироваться, особенно в тех случаях, когда их инфраструктуры требовали масштабирования. Было крайне важно поддерживать непрерывность бизнеса — и для этого многие компании выбрали сторонние решения, доступные в Интернете. Однако быстрый выбор иногда может нанести ущерб как цифровой безопасности, так и стратегической автономии. Несколько дней назад мы поделились некоторыми основными принципами защиты ваших данных. Теперь мы должны рассмотреть жизненно важный вопрос — какова будет цена этих тактических решений в долгосрочной перспективе?

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

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

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

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

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

Если говорить более глобально, у Европы есть только один реальный путь к достижению стратегической и суверенной автономии с точки зрения облачной инфраструктуры. Это потребует создания экосистемы технологических игроков, основанной на европейских ценностях, гарантирующих основные права для бизнеса. OVHcloud осознает эту проблему и выступил с широкой инициативой по цифровой помощи под названием #Open_solidarity. Его цель — быстро объединить сообщество технических игроков и предоставить бесплатные решения для удаленной работы, совместной работы (образование / безопасность) и здравоохранения — с гарантией, что данные, созданные локально, обрабатываются также и локально.



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

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

  • Если вы тоже хотите присоединиться к этому акту цифровой солидарности, вы можете подать заявку на то, чтобы стать официальным участником, заполнив нашу онлайн-форму здесь .
  • Если вы ищете бесплатное решение, посетите нашу специальную платформу: https://open-solidarity.com/

Еще один день в жизни ProxySQL: делиться заботой

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



В этом посте я объяснил, как нам пришлось продвинуть proxySQL за его пределы.

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

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

Вот два реальных случая, когда у нас было неожиданное поведение ProxySQL, в результате чего появился патч для MariaDB / MySQL.

1. Важность цитирования


Неожиданное поведение

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

Копать

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

[ОШИБКА] Обнаружено разорванное соединение во время SET NAMES на 192.168.59.272, 3306: 2019, Невозможно инициализировать набор символов (null) (путь: compiled_in)


ОШИБКА 1064 (42000): у вас есть ошибка в синтаксисе SQL; проверьте руководство, которое соответствует вашей версии сервера MySQL, чтобы найти правильный синтаксис для использования рядом с «двоичным» в строке 1


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

В поисках золота

Жюльен много работал — он прочитал тонны журналов, отследил множество PID и отследил проблему вплоть до ИСПОЛЬЗОВАНИЯ триггерного случая, выполнив эту команду:

set names binary COLLATE binary;


Сопоставление — это своего рода набор правил для сравнения строк. Он может определять, например, при сортировке по алфавиту, если Aидет раньше a, éследует ли рассматривать как eили нет, или где œдолжно быть в алфавите.

Вы можете узнать больше об этом в Базе знаний MariaDB.

Исправление

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

При написании ProxySQL Рене Канна делал то же, что и все разработчики, — следовал документации коннектора MariaDB. И ошибка была отсюда:

According to the documentation on SET NAMES syntax (https://dev.mysql.com/doc/refman/5.7/en/set-names.html) :

charset_name and collation_name may be quoted or unquoted

This doesn't seem true for "SET NAMES binary COLLATE binary" , that requires the collation name to be quoted.


(https://bugs.mysql.com/bug.php?172id=93692)

Эффект бабочки

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

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

2. Когда провода перекрещиваются

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

Неожиданное поведение

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

MySQL_Session.cpp:2964:handler(): [WARNING] Error during query on (42,192.168.59.272,3306): 1267, Illegal mix of collations (utf8_general_ci,IMPLICIT) and (dec8_swedish_ci,COERCIBLE) for operation '='


Копать

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

Мы решили взглянуть на исходный код коннектора.

В поисках золота

Если вам интересно, вы можете взглянуть на более старые версии кода libmariadb / my_charset.c, начиная со строки 541. Вы заметите, что dec8_swedish_ci нигде не найти. Но если вы присмотритесь, вы заметите dec8_swedisch_ci. Дорогие друзья из Швеции, опечатка была сделана не только вами.

Исправление

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

Мы разделили репозиторий GitHub mariadb-corporation / mariadb-connector-c , исправили несколько опечаток и предложили запрос на перенос, который затем был объединен в середине февраля.

Эффект бабочки

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



Вывод

Как ведущий поставщик веб-хостинга в Европе, мы сталкиваемся с законом действительно больших чисел ( en.wikipedia.org/wiki/Law_of_truly_large_numbers ). TL; DR: произойдет каждое событие с ненулевой вероятностью.

У нас размещено более 1,3 миллиона веб-сайтов. Предположим, что 0,0001% наших клиентов могут вызвать одну конкретную ошибку — у нас есть по крайней мере 1 клиент, который ее вызовет. Вопрос не в том, если, а в том, когда нам придется с этим бороться и как это сделать.

Хотите знать, как мы заметили, что попали в Закон действительно больших чисел? Следите за обновлениями, ведь мы скоро напишем об этом.

Поделиться заботой

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

Защитите себя и защитите свою ИТ-инфраструктуру

20 марта 2020 года ENISA (Агентство Европейского Союза по кибербезопасности) опубликовало статью, в которой содержится призыв к компаниям и частным лицам проявлять бдительность после попыток мошенничества, которые извлекают выгоду из кризиса здравоохранения, вызванного COVID-19. Различные организации, такие как ANSSI (Национальное агентство кибербезопасности Франции), NCSC (Национальный центр кибербезопасности) и CISA.(Агентство по кибербезопасности и безопасности инфраструктуры) предупреждают, что хакеры используют кризис COVID-19 для увеличения объема мошенничества (фишинг, мошенничество с личными данными, выдача себя за медицинские учреждения и т. Д.) И распространения вредоносных программ (вымогателей, вирусов троянских коней) ). Последние иногда приписывались экспертам в группах APT (продвинутые постоянные угрозы).



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

Чтобы устранить основные риски, мы основываем наши рекомендации на структуре ATT & CK, предложенной Mitre, которая ссылается на различные тактики, методы и процедуры, используемые хакерами для достижения успеха в своих попытках. Следующая матрица ATT & CK объединяет наши наблюдения и устанавливает наиболее часто используемые методы получения доступа к ИТ-системе. Мы пытаемся предложить базовые меры по снижению рисков для 9 из этих 11 методов, чтобы вы могли снизить риски. Перечисленные нами матрицы предлагаются в качестве примера для иллюстрации предложений и ни при каких обстоятельствах не исключают анализ рисков, адаптированный к вашему сектору, инфраструктуре или специализации.



Предвидеть атаки, используя полномочия

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

Долгое время ИТ-безопасность оставалась в руках экспертов, а технические принципы доступа к ИТ-системе основывались на социальной инженерии. Повышая осведомленность о рисках кибербезопасности, предоставляя сотрудникам возможность отмечать потенциальные угрозы (подозрительные электронные письма, поддельные профили в LinkedIn, получать уже открытые посылки и т. Д.) И объясняя, как эти эскалации могут способствовать общей безопасности ИТ-инфраструктуры., вы привлечете больше внимания пользователей. Чтобы расширить их участие в глобальном процессе и показать им важность роли, которую они должны играть в борьбе с угрозами безопасности, мы рекомендуем показать им процесс, демонстрирующий, насколько важны их действия.

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

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



Ограничение воздействия на ИТ-систему

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

Срочность настройки политики удаленной работы побудила некоторые команды открывать службы RDP (протокол удаленного рабочего стола), SSH (Secure Shell) и SMB (обмен файлами) непосредственно в Интернете, чтобы сотрудники без VPN также могли подключаться. Между тем, пока они настраивают работающую VPN, жизненно важно ограничить доступ к этим сервисам только для сотрудников, например, путем настройки доверенных IP-адресов в брандмауэре, чтобы заблокировать любых роботов, которые могут непрерывно сканировать Интернет. Протоколы RDP и SMB по-прежнему являются наиболее уязвимыми (например, вспомните Wannacry или уязвимость BlueKeep ).

Когда VPN настроен, попросите своих пользователей установить надежные пароли и, если возможно, настроить двухфакторную аутентификацию.

Эти действия положительно влияют на:



Обнаружение необычного поведения

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

Независимо от того, говорим ли мы о SIEM (Security Event Management), принцип один и тот же — он включает обнаружение необычной активности. И это начинается с обнаружения сильных сигналов. Пользователь входит в систему ночью или в выходные? Пользователь подключается через необычного или неавторизованного интернет-провайдера?
Вы также можете контролировать использование машин в нерабочее время, чтобы обнаружить необычно интенсивное использование ЦП, которое может указывать на зараженную машину (криптомайнинг, программы-вымогатели и т. Д.).

Вы знали?

Вы можете использовать объявления BGP через 
pyasn
инструмент
 с открытым исходным кодом, предлагаемый Технологическим университетом Делфта, для обогащения данных IP.
Инструменты Sysmon также очень полезны для мониторинга вашей среды Windows.

Даже если он слишком реактивен, обнаружение очень важно для ограничения ущерба. В 2019 году среднее время обнаружения вторжений в мире составляло 56 дней.

Эти действия положительно влияют на:



Вывод

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

Анонс Kafka-on-Pulsar: добавление поддержки протокола Kafka в Apache Pulsar

Этот пост был опубликован в блогах StreamNative и OVHcloud, его соавторами являются Сиджи Го, Цзя Чжай и Пьер Земб. Спасибо Горацио Гонсалесу за иллюстрации!



Мы рады сообщить, что StreamNative и OVHcloud открывают исходный код «Kafka on Pulsar» (KoP). KoP обеспечивает поддержку протокола Apache Kafka в Apache Pulsar, вводя обработчик протокола Kafka на брокерах Pulsar. Добавив обработчик протокола KoP в существующий кластер Pulsar, вы теперь можете перенести существующие приложения и службы Kafka в Pulsar без изменения кода. Это позволяет приложениям Kafka использовать мощные функции Pulsar, такие как:

  • Оптимизация операций благодаря многопользовательской среде корпоративного уровня 
  • Упрощенные операции с архитектурой без ребалансировки 
  • Бесконечное хранение потока событий с помощью Apache BookKeeper и многоуровневого хранилища
  • Бессерверная обработка событий с помощью функций Pulsar

Что такое Apache Pulsar?

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

Необходимость КОП

Pulsar предоставляет унифицированную модель обмена сообщениями как для очередей, так и для потоковых рабочих нагрузок. Pulsar реализовал собственный двоичный протокол на основе protobuf, чтобы обеспечить высокую производительность и низкую задержку. Такой выбор protobuf делает удобным реализацию клиентов Pulsar, и проект уже поддерживает языки Java, Go, Python и C ++ наряду с сторонними клиентами, предоставляемыми сообществом. Однако существующие приложения, написанные с использованием других протоколов обмена сообщениями, пришлось переписать, чтобы принять новый унифицированный протокол обмена сообщениями Pulsar.

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

Сотрудничество StreamNative и OVHcloud

StreamNative получал много входящих запросов о помощи по переходу с других систем обмена сообщениями на Pulsar и осознавал необходимость поддержки других протоколов обмена сообщениями (таких как AMQP и Kafka) изначально на Pulsar. StreamNative начал работу над внедрением общей структуры обработчиков протоколов в Pulsar, которая позволила бы разработчикам, использующим другие протоколы обмена сообщениями, использовать Pulsar.

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

В результате OVHcloud решила сместить и построить основу своего продукта «тема как услуга» под названием ioStream на Pulsar вместо Kafka. Мультиарендность Pulsar и общая архитектура с Apache Bookkeeper упростили операции по сравнению с Kafka.

Создав первый регион, OVHcloud решила реализовать его в качестве прокси-сервера для проверки концепции, способного на лету преобразовывать протокол Kafka в Pulsar. В ходе этого процесса OVHcloud обнаружил, что StreamNative работает над внедрением протокола Kafka в Pulsar, и они объединили усилия для разработки KoP.



KoP был разработан, чтобы предоставить оптимизированное и комплексное решение, использующее инфраструктуру хранения потоков событий Pulsar и BookKeeper и структуру подключаемого обработчика протоколов Pulsar. KoP реализован как плагин обработчика протокола с именем протокола «kafka». Его можно установить и настроить для работы в составе брокеров Pulsar.

Распределенный журнал

И Pulsar, и Kafka используют очень похожую модель данных для журналов как для обмена сообщениями pub / sub, так и для потоковой передачи событий. Например, оба они построены поверх распределенного журнала. Ключевое различие между этими двумя системами заключается в том, как они реализуют распределенный журнал. Kafka реализует распределенный журнал в архитектуре на основе разделов, где распределенный журнал (раздел в Kafka) предназначен для хранения в наборе брокеров, в то время как Pulsar развертывает архитектуру на основе сегментов для реализации своего распределенного журнала, используя Apache BookKeeper как его масштабируемый уровень хранения сегментов. Архитектура Pulsar на основе * сегментов * обеспечивает такие преимущества, как отсутствие перебалансировки, мгновенная масштабируемость и неограниченное хранение потоков событий. Вы можете узнать больше о ключевых различиях между Pulsar и Kafka вэтот блог Splunk и в этом блоге проекта Bookkeeper.

Поскольку обе системы построены на схожей модели данных, распределенном журнале, очень просто реализовать обработчик протокола, совместимый с Kafka, используя распределенное хранилище журналов Pulsar и его подключаемую структуру обработчика протоколов (введенную в выпуске 2.5.0).

Реализации

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

  • Поиск темы : все клиенты подключаются к любому брокеру для поиска метаданных (то есть брокера-владельца) тем. После получения метаданных клиенты устанавливают постоянные TCP-соединения с брокерами-владельцами.
  • Производство : клиенты обращаются к брокеру- владельцу тематического раздела, чтобы добавить сообщения в распределенный журнал.
  • Потребление : клиенты обращаются к брокеру- владельцу раздела темы, чтобы прочитать сообщения из распределенного журнала.
  • Смещение : сообщения, создаваемые для тематического раздела, назначаются со смещением. Смещение в Pulsar называется MessageId. Потребители могут использовать смещения для поиска заданной позиции в журнале для чтения сообщений.
  • Состояние потребления : Обе системы поддерживают состояние потребления для потребителей в рамках подписки (или группы потребителей в Kafka). Состояние потребления хранится в теме __offsets в Kafka, а состояние потребления хранится в виде курсоров в Pulsar.

Как видите, это все примитивные операции, обеспечиваемые масштабируемым распределенным хранилищем журналов, таким как Apache BookKeeper. Основные возможности Pulsar реализованы поверх Apache BookKeeper. Таким образом, довольно легко и просто реализовать концепции Kafka, используя существующие компоненты, которые Pulsar разработал для BookKeeper.

На следующем рисунке показано, как мы добавляем поддержку протокола Kafka в Pulsar. Мы представляем новый обработчик протоколов, который реализует проводной протокол Kafka, используя существующие компоненты (такие как обнаружение тем, распределенная библиотека журналов — ManagedLedger, курсоры и т. Д.), Которые уже есть в Pulsar.



Темы

В Kafka все темы хранятся в одном плоском пространстве имен. Но в Pulsar темы организованы в иерархические мультитенантные пространства имен. Мы вводим параметр kafkaNamespace в конфигурацию брокера, чтобы администратор мог отображать темы Kafka в темах Pulsar.

Чтобы пользователи Kafka могли использовать функцию мультитенантности Apache Pulsar, пользователь Kafka может указать клиент Pulsar и пространство имен в качестве своего имени пользователя SASL, когда он использует механизм аутентификации SASL для аутентификации клиента Kafka.

Идентификатор сообщения и смещение

В Kafka каждому сообщению присваивается смещение после его успешного создания в разделе темы. В Pulsar каждому сообщению присваивается «MessageID». Идентификатор сообщения состоит из 3 -х компонентов, главная книга-ID , начальные идентификаторы и пакетный индекс . Мы используем тот же подход в оболочке Pulsar-Kafka для преобразования Pulsar MessageID в смещение и наоборот.

Сообщения

И сообщение Kafka, и сообщение Pulsar имеют ключ, значение, временную метку и заголовки (примечание: в Pulsar это называется «свойствами»). Мы автоматически конвертируем эти поля между сообщениями Kafka и сообщениями Pulsar.

Поиск по теме

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

Создавать сообщения

Когда обработчик запросов Kafka получает созданные сообщения от клиента Kafka, он преобразует сообщения Kafka в сообщения Pulsar, сопоставляя поля (т.е. ключ, значение, временную метку и заголовки) одно за другим, и использует API добавления ManagedLedger для добавления этих преобразованных сообщений Pulsar. в BookKeeper. Преобразование сообщений Kafka в сообщения Pulsar позволяет существующим приложениям Pulsar использовать сообщения, созданные клиентами Kafka.

Потреблять сообщения

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

Координатор группы и управление взаимозачетами

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

Модель Пульсара сложно согласовать с моделью Кафки. Следовательно, для обеспечения полной совместимости с клиентами Kafka мы реализовали координатор группы Kafka, сохраняя изменения и смещения группы координаторов в системной теме под названием public / kafka / __ offsets в Pulsar.

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

Соедините две популярные экосистемы обмена сообщениями

В обеих компаниях мы ценим успех клиентов. Мы считаем, что предоставление собственного протокола Kafka на Apache Pulsar снизит барьеры для людей, использующих Pulsar для достижения успеха в бизнесе. Интегрируя две популярные экосистемы потоковой передачи событий, KoP открывает новые варианты использования. Клиенты могут использовать преимущества каждой экосистемы и создать действительно унифицированную платформу потоковой передачи событий с Apache Pulsar, чтобы ускорить разработку приложений и сервисов в реальном времени.

С помощью KoP сборщик журналов может продолжать собирать данные журналов из своих источников и отправлять сообщения в Apache Pulsar, используя существующие интеграции с Kafka. Последующие приложения могут использовать функции Pulsar для обработки событий, поступающих в систему, для выполнения бессерверной потоковой передачи событий.

Попробуй это

Исходный код KoP открыт под лицензией Apache License V2 по адресу https://github.com/streamnative/kop .

Мы с нетерпением ждем ваших вопросов и PR. Вы также можете присоединиться к каналу #kop в Pulsar Slack, чтобы обсудить все о Kafka-on-Pulsar.

StreamNative и OVHcloud также проводят веб-семинар по KoP 31 марта. Если вы хотите узнать больше о KoP, зарегистрируйтесь . С нетерпением жду встречи с вами онлайн.



Спасибо

Первоначально проект KoP был инициирован StreamNative. Команда OVHcloud присоединилась к проекту для совместной работы над проектом KoP. Большое спасибо Пьеру Зембу и Стивену Ле Ру из OVHcloud за их вклад в этот проект!

Семейство Open Source Metrics приветствует Catalyst и Erlenmeyer

В OVHcloud Metrics мы любим открытый исходный код! Наша цель — предоставить всем нашим пользователям полноценный опыт . Мы полагаемся на базу данных временных рядов Warp10, которая позволяет нам создавать инструменты с открытым исходным кодом для наших пользователей. Давайте взглянем на некоторые из них в этом блоге.



Инструмент для хранения

Наша инфраструктура основана на базе данных временных рядов с открытым исходным кодом: Warp10 . Эта база данных включает две версии: автономную и распределенную . Распределенный полагается на распределенные инструменты, такие как Apache Kafka, Apache Hadoop и Apache HBase .

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

Прием данных метрик

Собственно говоря, мы были первыми, кто застрял в процессе приема ! Мы часто создаем адаптированные инструменты для сбора и отправки данных мониторинга на Warp10 — так появился noderig . Noderig является адаптированным инструментом , который способен собрать в простое ядро метрик с любого сервера или любой виртуальной машины . Также можно безопасно отправлять метрики на бэкэнд. Beamium , инструмент Rust, может передавать метрики Noderig одному или нескольким бэкэндам Warp 10 .



Что, если я хочу собирать собственные специальные показатели ? Во-первых, вам нужно будет разоблачить их по «модели Прометея». Beamium затем может подручных приложений на основе их файл конфигурации и вперед все данные в сконфигурированной Деформация 10 бэкэндом (ов)!

Если вы хотите отслеживать определенные приложения с помощью агента Influx Telegraf (чтобы предоставить необходимые вам метрики), мы также предоставили соединитель Warp10 Telegraf , который был недавно объединен!

Пока это выглядит великолепно, но что, если я обычно нажимаю метрики Graphite, Prometheus, Influx или OpenTSDB ; как я могу просто перейти на Warp10 ? Наш ответ - Catalyst : прокси-уровень, который может анализировать метрики в связанных форматах и ​​преобразовывать их в родной для Warp10.

Катализатор

Catalyst  — это HTTP-прокси Go, используемый для анализа нескольких записей в базе данных TimeSeries с открытым исходным кодом. На данный момент он поддерживает несколько операций записи в базу данных TimeSeries с открытым исходным кодом; такие как OpenTSDB, PromQL, Prometheus-remote_write, Influx и Graphite. Catalyst запускает HTTP-сервер, который прослушивает определенный путь ; начиная с имени временного ряда протокола, а затем с собственного запроса . Например, чтобы собрать данные о притоке, вы просто отправляете запрос на адрес 
influxdb/write
. Catalyst автоматически проанализирует 
influx
данные и преобразует их в собственный формат приема Warp 10 .



Запросы метрик

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

Теперь давайте возьмем пользователя, который использует Telegraf и отправляет данные в Warp10 с помощью Catalyst. Они захотят использовать встроенную панель управления Influx Grafana, но как? А как насчет пользователей, которые автоматизируют запросы с помощью протокола запросов OpenTSDB? Нашим ответом было разработать прокси: Эрленмейер

Эрленмейер

Erlenmeyer  — это HTTP-прокси Go, который позволяет пользователям запрашивать Warp 10 на основепротокола запросовс открытым исходным кодом . На данный момент он поддерживает несколько форматов TimeSeries с открытым исходным кодом; такие как PromQL, удаленное чтение Prometheus, InfluxQL, OpenTSDB или Graphite. Эрленмейер запускает HTTP-сервер, который прослушивает определенный путь ; начиная с имени временного ряда протокола, а затем с собственного запроса . Например, чтобы выполнить запрос promQL, пользователь отправляет запрос в
prometheus/api/v0/query
. Эрленмейер изначально проанализирует
promQL
запрос, а затем создаст собственный запрос WarpScript, который может поддерживатьлюбойбэкэнд Warp10 .



Продолжение следует

Сначала Erlenmeyer и Catalyst представили быструю реализацию собственных протоколов, призванную помочь внутренним группам выполнять миграцию, при этом используя знакомый инструмент . Теперь мы интегрировали множество встроенных функций каждого протокола и чувствуем, что они готовы к совместному использованию. Это время , чтобы сделать их доступными для Warp10 сообщества , поэтому мы можем получить обратную связь и продолжать работать в поддержке протоколов с открытым исходным кодом. Вы можете найти нас в игровой комнате OVHcloud Metrics !

Другим пользователям Warp10 может потребоваться нереализованный протокол. Они смогут использовать Erlenmeyer и Catalyst для поддержки их на собственном сервере Warp10.

Добро пожаловать, Erlenmeyer и Catalyst — Metrics Open Source проекты!

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

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



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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

COVID ‑ 19 - Одна команда - одна компания - #Open_solidarity

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



Гарантия здоровья и безопасности всех сотрудников — приоритет OVHcloud

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

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

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



Наши команды прилагают все усилия, чтобы поддержать вас в лучших условиях. Как следствие, мы внедряем планы обеспечения непрерывности бизнеса. Нашим приоритетом является обеспечение высококачественных операционных услуг, которые необходимы для всей деятельности наших клиентов — как для вашего бизнеса, так и в более стратегическом национальном масштабе. Мы намерены применять это во всем мире, где бы мы ни присутствовали. Наша группа поддержки клиентов также работает удаленно из дома и будет готова ответить на запросы поддержки в обычном режиме. Эта система, которая действует уже 2 недели в Италии, теперь развернута во всех странах, не влияя на качество обслуживания. Мы также защищаем сотрудников в наших центрах обработки данных, усиливая профилактические меры на местах. Сегодня все операции по обслуживанию центров обработки данных и серверов можно выполнять в обычном режиме. Наша инфраструктура способна использовать полосу пропускания 20 Тбит / с, и по этой причине мы не думаем, что этот кризис повлияет на качество услуг, которые мы вам предлагаем. Мы работаем в тесном контакте с нашими поставщиками и не ожидаем возникновения каких-либо проблем с предоставлением ресурсов для будущих поставок, необходимых для производства наших собственных серверов.«Команды OVHcloud работают исключительно на высоком уровне, — объясняет Мишель Полен.

Участие в усилиях: открытая солидарность

Чтобы бороться с кризисом в сфере здравоохранения, многие компании солидарны друг с другом, предлагая решения для удаленной работы, совместной работы и хостинга для здравоохранения. Учитывая серьезность ситуации и самоизоляцию, требуемую во многих странах, мы можем ожидать, что эти решения будут пользоваться очень большим спросом. Такие концепции, как помощь друг другу и совместная работа как сообщество, являются фундаментальными ценностями OVHcloud, и они претворяются в жизнь нашим основателем — Октавом Клаба — и генеральным директором Мишелем Поленом. В результате OVHcloud решила сделать все возможное, чтобы предлагать бесплатные инфраструктуры без каких-либо обязательств на время кризиса COVID-19. Цель этого — помочь и поддержать всплески трафика для веб-сайтов, относящихся к этим секторам бизнеса.



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

Мишель Паулен, генеральный директор OVHcloud

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

Октав Клаба, основатель OVHcloud

Объясняя медленные запросы моему менеджеру

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



Прежде чем идти дальше, давайте резюмируем, что это за четыре типа запросов:

  • Выбрать для чтения данных
  • Вставка предназначена для добавления данных
  • Обновление предназначено для изменения данных, которые уже существуют
  • Удалить для удаления данных

my-database=# select * from customers where nic = XXX;
my-database=# insert into customers values (1, 'user-firstname', 'user-lastname', '21');
my-database=# update customers set address = 'xxx xxx' where nic = 'XXX';
my-database=# delete from customers where nic = XXX


Когда дело доходит до рабочих нагрузок SQL, существует два разных типа: OLTP и OLAP .

Рабочие нагрузки OLTP

OLTP (для O н L ине Т ransactional Р rocess) рабочие нагрузки соответствуют «органической» использованием баз данных. Эти операции используются для более эффективного использования баз данных веб-сайтов, API-интерфейсов, платформ электронной коммерции и т. Д. В то время как OLAP полагается исключительно на чтение, рабочие нагрузки OLTP полагаются на все типы запросов, включая выбор, вставку, обновление и удаление. В OLTP мы хотим, чтобы запросы отвечали как можно быстрее, обычно менее чем за несколько сотен миллисекунд. Причина этой потребности в скорости состоит в том, чтобы уменьшить влияние запросов на взаимодействие с пользователем вашего приложения. В конце концов, кто любит веб-сайты, которые загружаются бесконечно? Что касается количества запросов, мы обычно считаем их тысячами в секунду.

my-database=# insert into cart values (...); -- create a new cart
my-database=# insert into cart_content values (...); -- add items
my-database=# update cart_content set ... where ...; -- modify your cart
my-database=# select item_name, count from cart_content where ...; -- check the content
my-database=# insert into sales values (...); -- validate the cart


Рабочая нагрузка OLAP

OLAP (для O н L INE A nalytic P rocess) рабочие нагрузки используются для извлечения и анализа больших объемов данных (отсюда и название). Они являются основным инструментом, используемым программными платформами бизнес-аналитики для составления прогнозов и отчетов. Что касается запросов, рабочие нагрузки OLAP обычно полагаются исключительно на несколько избранных, которые периодически выполняются и могут занять много времени (от минут до часов).

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

Классифицирующие запросы: хорошие, плохие, уродливые… и медленные

Теперь, когда у нас есть общее представление о двух типах рабочих нагрузок, давайте сосредоточимся на OLTP, поскольку они обычно наиболее актуальны для частей ваших платформ, ориентированных на клиентов. В начале этого поста я описал четыре различных типа SQL-запросов с точки зрения их назначения. Теперь мы классифицируем их по поведению: хорошее, плохое, уродливое и медленное. Что это значит, спросите вы? Разрешите пояснить (спойлер: вы хотите, чтобы ваши запросы попадали в категорию «хорошо»)…



Добро

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

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

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

my-database=# select firstname, lastname from customers where id = 123;


Плохо

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

Возьмем пример. На вашем веб-сайте есть форма, в которой пользователи могут создать учетную запись, в которой они указывают свой возраст. В пользовательском интерфейсе текстовое поле позволяет пользователю вводить все, что он хочет, и передавать значение в виде строки. Но если ваша схема хорошо спроектирована, в поле «возраст» должно быть указано целое число. Таким образом, если пользователь пытается ввести свой возраст в виде строки в поле, а не числа, СУБД должна вернуть ошибку. Решение простое: форма пользовательского интерфейса должна проверять тип данных, заполненных в поле, и возвращать сообщение об ошибке, например «недопустимые данные», в интерфейсе пользовательского интерфейса, вместо того, чтобы ждать, пока СУБД сделает это. В подобных случаях рекомендуется разрешать только числа.

my-database=# insert into user values (1, 'user-firstname', 'user-lastname', 'twenty years old');
ERROR:  invalid input syntax for integer: "twenty years old"


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

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

Уродливый

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

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

-- STEP #1
process 1: BEGIN; -- this will start the transaction
process 2: BEGIN;
 
-- STEP #2
process 1: UPDATE stock SET available = 10 WHERE id = 123; -- lock row 123
process 2: UPDATE stock SET available = 0 WHERE id = 456; -- lock row 456
 
-- STEP #3 The ugly part starts now
process 1: UPDATE stock SET available = 1 WHERE id = 456; -- wait for lock on row 456
process 2: UPDATE stock SET available = 9 WHERE id = 123; -- wait for lock on row 123


Мы видим, что у нас есть два процесса, пытающихся обновить запас в рамках транзакции. Процессы №1 и №2 блокируют разные строки. Процесс №1 блокирует строку 123, а процесс №2 блокирует строку 456 на этапе 2. На этапе 3, не снимая блокировки с текущей строки, процесс №1 пытается получить блокировку для строки 456, которая уже принадлежит процесс №2, и наоборот. Чтобы завершить транзакцию, они оба ждут друг друга. Я выбрал простой пример с двумя запросами, но эта проблема может возникнуть с десятками или тысячами запросов одновременно. Общие правила при работе с транзакциями — совершать их как можно быстрее.

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

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

process 34099 detected deadlock while waiting for ShareLock on transaction 4026716977 after 1000.042 ms
DETAIL: Process holding the lock: 34239. Wait queue: .
CONTEXT: while locking tuple (259369,24) in relation "table"
STATEMENT: SELECT col from table where ...


Ваша любимая СУБД в конечном итоге убьет все запросы, но только по истечении заданного времени ожидания. И, конечно же, тайм-аут означает, что ваши клиенты будут ждать результата, прежде чем выдаст ошибку. Ага, это некрасиво…

И медленный…

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

  • Плохо написанные запросы (а в продукте этого нет?)
  • Отсутствующие индексы
  • Получено слишком много строк
  • Слишком много данных для обработки

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

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

Вывод

Подведем итоги и подведем итоги:

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

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

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