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

В наших предыдущих статьях мы объясняли, почему нам пришлось переместить 800 000 баз данных из одного центра обработки данных в 300 километров. Итак, мы… Моя команда и я сделали это! Это была настоящая горелка мозгов, так что я надеюсь, что наша история поможет вам рассмотреть больше огромных технических проектов, с которыми мы любим играть.


Правила

• Чтобы уменьшить задержку, база данных должна быть перенесена одновременно с использованием веб-сайта.
• Поскольку базы данных распределены по всем доступным серверам MySQL, гранулярность миграции должна быть базой данных, а не экземпляром MySQL. Другими словами, мы не можем перенести весь сервер MySQL. Мы должны переместить только часть этого.
• Поскольку на ссылку между веб-сайтом и его базой данных нет необходимости ссылаться, веб-сайт в Gravelines должен иметь возможность связаться с базой данных в Париже (например), и наоборот.
• Чтобы связаться со своей базой данных, веб-сайт использует имя хоста, имя пользователя и пароль. Мы хотим, чтобы миграция была прозрачной, поэтому никому не нужно менять какие-либо из этих элементов для связи с их новой базой данных.
• Платформы баз данных меняются между Парижем и Гравелином, как показано ниже.

Подводя итог, вот что мы имеем до миграции веб-кластера:

И это то, что мы хотим после миграции:


Еще несколько вещей…

• Очевидно, что мы имели в виду одну из самых важных вещей при работе с базами данных: согласованность. Для каждой базы данных мы должны были определить точку согласованности. До этого момента на временной шкале чтение / запись производились в Париже. После этого чтение / запись были сделаны в Gravelines.
• Мы верим в прозрачность и обратимость. Это обе ключевые части нашего облака SMART. Вот почему мы хотели предоставить вам доступ к этой точке согласованности в виде дампа на вашей панели управления OVHcloud. Для каждой перенесенной базы данных мы решили предоставить вам доступ к дампу на один месяц.
• Миграция 800K баз данных примерно за 60 ночей означала, что мы должны быть очень быстрыми и масштабируемыми. Наш рекорд был 1 июля 2019 года, когда мы успешно мигрировали 13502 базы данных за 1 час 13 минут и 31 секунду.
• Если вы привыкли быть на дежурстве, вы знаете, что ваше внимание и эффективность снижаются ночью. Повторение процесса миграции примерно 60 раз в год усилит это, поэтому мы хотели, чтобы все было максимально автоматизировано и максимально просто. Как мы увидим позже, чтобы запустить миграцию базы данных, нам просто нужно было выполнить одну команду на одном хосте:

migrate-p19

Теперь вы знаете правила, пора начинать игру!

1-й уровень
Первый уровень всегда легкий, где вы узнаете, как игра работает, с помощью своего рода учебника! Итак, начнем с небольшой миграции базы данных. Вот как мы это делаем:

1. У источника (Париж)

• Установите режим только для чтения. Нам абсолютно необходимо избегать записи во время миграции, чтобы избежать знаменитого раскола мозга. Самый простой способ сделать это — перевести базу данных в режим только для чтения. В большинстве случаев веб-сайтам нужно только читать базы данных, но в некоторых случаях им нужно чтение и запись, и поэтому они будут повреждены. Это не проблема, потому что сайт в настоящее время перенесен и закрыт. Мы заблокируем доступ на запись в случае, если база данных используется другим хостом, на который не влияет ночная миграция.
• Дамп базы данных и положить куда-нибудь дамп. Мы решили хранить дампы в общедоступном облачном хранилище (PCS) OVHcloud, поскольку мы уже используем это решение для хранения 36 миллионов дампов в месяц. Добавление 800 000 дампов в год — не проблема для этой потрясающей платформы!
• 3 минуты и 31 секунда.

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


2. В пункте назначения (Гравелин)
Получить дамп и импортировать его.
Создайте пользователя и разрешения с правами записи.


3. Переключиться на новую базу данных
На данный момент сайт все еще вызывает базу данных в Париже. Таким образом, веб-сайт (независимо от того, находится ли он в Париже или Gravelines) может связываться с новой базой данных, мы будем обновлять DNS, чтобы имя указывало на экземпляр Gravelines MySQL, а не на Париж.
Доступ для чтения к парижской базе данных также удален.
Наконец, мы обновим нашу информационную систему, чтобы вы могли получить дамп с PCS через панель управления. Это обновление также позволяет нам перенаправить все действия, доступные из панели управления (например, изменить пароль, создать дамп), в новую базу данных на Gravelines.


Уровень 2: «Децентрализованный конечный автомат»
Чтобы подтвердить концепцию миграции, сначала мы выполнили все эти шаги вручную и последовательно. Естественный способ автоматизировать это — написать скрипт, который сделает то же самое, но быстрее. Это централизованный метод, но такие методы рано или поздно сталкиваются с узкими местами и предполагают единую точку отказа.

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


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

• Источник
• Пункт назначения
• Тот, который обновляет DNS

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

Мозг миграции: CloudDB
Мы любим концепцию «ешь свою еду»! Это самый лучший контроль качества, и благодаря отзывам, которые вы нам предоставили, наш первый источник запросов по функциям. Поэтому неудивительно, что мы использовали наш собственный продукт CloudDB для хранения графиков состояний миграций баз данных.

Технически граф состояний — это строка в таблице. Упрощенная структура этой таблицы выглядит следующим образом:

- database_name VARCHAR(255) PRIMARY KEY,
- source VARCHAR(255),
- destination VARCHAR(255),
- status VARCHAR(255) NOT NULL DEFAULT 'Waiting',
- dump_url TEXT

За исключением dump_url, все поля заполняются до начала миграции. Другими словами, мы знаем, где находятся базы данных и где они будут.

Мы победили все проблемы этого уровня. Теперь пришло время победить финального монстра!

Уровень 3: Миграция 800K баз данных
Теперь, когда мы знаем, как переносить одну базу данных децентрализованным способом, давайте заполним CloudDB всеми базами данных, которые мы хотим перенести! Вот как выглядит миграция:

В Париже
Примерно раз в минуту * каждый хост из 780 серверов баз данных спрашивает CloudDB, есть ли у них что-то, что нужно выгрузить. Столбцы источника и состояния таблицы используются для получения этой информации:

SELECT … WHERE source = me AND status = 'To dump';

Если это так, они выполняют свои задачи и обновляют CloudDB о том, что они делают. Когда они закончат, они передают эстафету для этой миграции Гравелинам:

UPDATE … SET status = 'To import' WHERE database_name = '…';

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

SELECT … WHERE destination = me AND status = 'To import';

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

UPDATE … SET status = 'DNS to update' WHERE database_name = '…';

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

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

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

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

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

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

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

Но для этого босса есть чит-код: итерация!

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

Этот метод возможен благодаря двум вещам:

• Волшебная команда
• Большая красная кнопка

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

migrate-p19 --max-procs 400

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

Команда migrate-p19 является планировщиком. Он обновляет CloudDB каждые 10 секунд, поэтому мы всегда выполняем эти 400 миграций параллельно:

SELECT COUNT(database_name) … WHERE status in ('To dump', 'Dumping', 'Dump failed', 'To import', …);
42
UPDATE … SET status = 'To dump' WHERE status = 'Waiting' LIMIT (400 - 42);

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

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

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

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



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

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

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

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


Наши первые поколения водоблочных технологий были разработаны нашими командами и изготовлены извне. Эти водоблоки имели оптимальную мощность 60 Вт при температуре воды 30 ° С.

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


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

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

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


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


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

В течение этого периода мы все еще проектировали наши водоблоки внутри и производили их снаружи. Оптимальная мощность для этого поколения водяных блоков составляет 60 Вт при температуре воды 30 ° C.

Наши водные блоки продолжали развиваться. Мы заменили медную выпуклую концевую опорную плиту на простую. Крест на крышке был заменен крестом внутри водоблока. Это позволило нам еще больше снизить стоимость водяных блоков без ущерба для производительности.


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


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


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


Здесь у вас есть параллельное сравнение стандартного, водоблока ЦП и более компактного водоблока графического процессора:


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


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


2015 и далее
В предыдущих параграфах описана наша технология водоблоков в 2014 году. С тех пор мы прошли большой путь. Мы использовали новые технологии, такие как 3D-печать, и внесли некоторые фундаментальные изменения в дизайн.

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

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

В настоящее время архитектура распределяет услуги в «специфических» регионах OpenStack (например GRA3). Каждое место может быть идентифицированы два или три буквами (GRA для Гравелин здесь), а затем рядом (3 для третьей области в этом месте).

Мы будем перемещать объект хранения и Cloud Архивные услуги от этих конкретных регионов в «глобальных» регионах.

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

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

Как только эта операция будет завершена, конкретные регионы GRA1, GRA3 и GRA5 больше не хозяин объекта хранения и облака Архивные услуги. Они будут автоматически доступны в проекте с помощью нового глобального GRA региона.

Эта операция будет проводиться во всех местах общественного Облако: Гравлин (GRA), Страсбург (SBG), Beauharnois (BHS), Варшава (WAW), Лондон (Великобритания), Франкфурте (DE), Сингапур (SGP) и Сидней (SYD).

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

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

Кроме того, стоит модификации конфигурации синхронизации для контейнеров, а также адрес по имени домена (CNAME или TXT DNS записей). Если ваши домены нацелены наш IP — адрес непосредственно (запись), вам необходимо переключиться на запись CNAME.

Все новые проекты Public Cloud будет их объектов хранения и Клауд Архивные услуги однозначно направлены на новые глобальные регионы.

2. 18 февраля 2020: Удаление конечных точек для объектов хранения и облачного Архива в конкретных регионах.

Некоторые конечные точки Swift будут удалены из каталога услуг (объявленного Keystone) для конкретных регионов, а затем будут доступны только для регионов мира.

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

Благодарим Вас за выбор OVH.
Облако команды Public

• 2x2.5G / 4x2.5G for Baremetal Low-End (KS, SYS, RISE, ADV)
• SuperSmartNIC (SSN) with PCIe for 4 servers
• Segment Routing IPv6 (SR6)
• OpenStack Neutron
• Opensource HW/SW

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

Параллельно с этим, мы работаем над инновациями, чтобы включить сервера дешевле 150E которые у нас «чемпион мира». Сегодня у нас есть 4 семейства серверов: KS, SYS, Rise и ADV. Эти четыре линии будет держать их, даже если названия изменится в связи с тем, что наконец-то управляются OVHcloud в одном менеджере и API.

Существует много изменений вокруг сети. Сегодня мы предлагаем 100M на KS, или 1G 2x1G на всех этих серверах. Мы построили линейку инфра, чтобы иметь возможность предложить либо 2x2.5Gbps дешевле чем 150E сервер. После коммерческого, мы можем синхронизировать NIC на 1G или 2.5G и предложить vrack или нет, но по умолчанию, мы соединим все серверы 2x2.5Gbps.

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

Мы решили сделать наш SmartNIC иначе (иначе SmartNIC рынок только бы купил):

• A SmartNIC не для одного, а для серверов 4 серверов. Таким образом, это снижает затраты на сервере и может быть такое же предложение на серверах дешевле 150E. Это много SuperSmartNIC (ПКР).
• Наш SSN не подключен к серверу с помощью кабеля Ethernet, а через PCIe кабели. Это позволяет нам сделать «включение» сервера на водяном охлаждении, не только электрическая мощность, но и в сеть. Сервер запускается в стойке за 1 секунду, и включает его. А так как это PCIe, просто кабель 2x NIC. Это гораздо проще и дешевле.
• Система SSN поддерживает любой сервер, в любом возрасте технологий, так как даже серверы на старых КС, SYS могут быть соединены в этой PCIe SSN и пользоваться сетью 2x2.5G по умолчанию.
• Все это позволит нам развернуть SR6 (сегмент маршрутизации IPv6) и выполнять все типы пакетов в одной сети, в то время как управление простой способ чешуйки и поэтому предлагают все больше и больше возможностей для наших клиентов BareMetal PCI, PCC и хранения. Является ли это 2.5G или 25G или 50G или 100G, все серверы будут пользоваться теми же функциями. NAT, IP-LB, IP FO, частная сеть L3, L2, ACL, QoS, при VLAN под сети, межсетевой экран и т.д.

В течение нескольких месяцев мы завершим прототип и передадим версии альфа/бета. Нам нужно будет протестировать наши прототипы, и мы находим ошибки. В то же время, по-прежнему много работы на HW, но и на SW. Все это вооруженных сил США переписать всю оркестровку наших контроллеров домена.

После того, как стабильная версия будет работать в наших ДЦ, мы будем делать HW и SW с открытым исходным кодом.

искренне
октава

Каждая стойка питается от трехфазных кабелей «32A» — для распределения питания в стойке мы используем этот SmartFuse — каждый сервер контролируется + имеет индивидуальную электробезопасность — связь на основе CPL через Ethernet (зашифрованная) — считывание больше Слава командам!

www.ovh.ie/black-friday/

www.soyoustart.com/ie/essential-servers/

Или написать тикет тут bill.ovh/billmgr

Во время саммита OVHcloud в октябре прошлого года мы объявили о недавней регистрации 50 семейств патентов.

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



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

Это действительно очень хороший вопрос!

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

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


publications.lib.chalmers.se/records/fulltext/248326/local_248326.pdf
publications.lib.chalmers.se/records/fulltext/248326/local_248326.pdf

Из всех этих причин основными являются:

Защищать себя
Есть две основные угрозы для такой компании, как наша:

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

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

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

Когда мы начали расти и решили открыть филиал в США, территории по определению патентных троллей и GAFAM с тысячами патентов, мы подумали, что скрещивать пальцы в надежде на то, что нас не заметят, явно не правильная стратегия, поэтому мы засучили рукава, разработали патентную программу, соответствующую политику вознаграждений, обучили наших сотрудников интеллектуальной собственности, и мы быстро начали видеть преимущества: почти 50 заявок на патенты за 18 месяцев! И поверьте мне, это только начало!

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

Но следует отметить, что если бы третья сторона (даже добросовестно) подала патент на изобретение, которое в течение нескольких лет хранилось в секрете другой компанией, последняя станет фальшивомонетчиком, если продолжит использовать свое изобретение, не разочаровав ?!

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

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

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

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

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

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

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

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

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

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

Авторское право защищает только форму (т.е. исходный код, объектный код, документацию и т.д.), В то время как патент защищает процесс, метод, независимо от используемого языка.

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

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

Но зачем подавать патент, а потом давать доступ к источникам?

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

«Экономика мира»
Когда Тесла разрешил использовать свои патенты без уплаты лицензионных сборов, Тесла не отказался от своих патентов, сказал Маск: «Тесла не будет возбуждать патентные иски против тех, кто добросовестно хочет использовать нашу технологию».

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

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

Это также то, что мы думаем в OVHcloud, и именно поэтому мы выступаем за SMART Cloud — обратимое, открытое и совместимое облако через открытые инновации.

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