Рейтинг
0.00

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

33 читателя, 1303 топика

Каждая стойка питается от трехфазных кабелей "32A"

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



Стратегия OVHcloud для продвижения и защиты инноваций

Во время саммита 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 не забыл свои ценности и намерен как можно больше участвовать в открытых инновациях и продвигать эту «экономику мира».

OVHcloud dedicated servers | Rise Limited Edition



Серверы Selected Rise bare metal теперь предлагаются по еще более выгодной цене и без платы за установку, предлагая идеальные хостинговые решения для ваших веб-сайтов и приложений.

Серверы Rise основаны на платформах Intel Xeon, что гарантирует вам высокую производительность. Все серверы Rise включают ряд функций, таких как пропускная способность 500 Мбит/с, пространство для хранения 500 ГБ и широкий спектр операционных систем.
www.ovh.ie/dedicated_servers/rise/

Rise-LE-1
Limited Quantity
From €52.24 ex. VAT/month
No stup fees (€49.99)
www.ovh.ie/dedicated_servers/rise/rise-limited-edition-1/

Rise-LE-2
Limited Quantity
From €61.74 ex. VAT/month
No setup fees (€59.99)
www.ovh.ie/dedicated_servers/rise/rise-limited-edition-2/

Просмотрите все цены на этот диапазон выделенных серверов OVHcloud
www.ovh.ie/dedicated_servers/rise/prices

Инфраструктура внутренних баз данных OVHcloud

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


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

В этой новой серии постов мы рассмотрим инфраструктуру внутренних реляционных баз данных OVHcloud. Этот первый пост посвящен инфраструктуре внутренних баз данных. В OVHcloud мы используем 3 основные СУБД (системы управления базами данных), PostgreSQL MariaDB и MySQL, каждая из которых опирается на одну кластерную архитектуру.

Но сначала, что такое кластер? Кластер — это группа узлов (физических или виртуальных), работающих вместе для предоставления службы SQL.

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

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

Каждый кластер состоит из 3 узлов, каждый из которых выполняет свою роль — основной, реплика и резервное копирование.

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



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

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


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

Теперь давайте поговорим о резервных копиях. Как я упоминал ранее, резервные копии являются важной частью баз данных корпоративного уровня. Чтобы избежать необходимости поддерживать разные процессы для разных разновидностей СУБД, мы разработали общий процесс резервного копирования, который мы применяем ко всем этим.

Это позволило нам автоматизировать его более эффективно и абстрагировать сложность различных программ.

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

Но главная причина наличия отдельного узла резервного копирования заключается в следующем: резервное копирование никак не влияет на кластер. Действительно, резервное копирование полной базы данных может оказать очень заметное влияние на производительность (блокировки, потребление ресурсов ЦП и ОЗУ и т. Д.), И мы не хотим этого делать на производственных узлах.

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



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

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