OVH развернула, эксплуатировала и поддерживала собственную волоконно-оптическую сеть с 2006 года. Она объединяет 32 точки присутствия (PoP) по всему миру. Как эта инфраструктура приносит пользу нашим клиентам? Почему мы должны постоянно развивать его? А что означает «пропускная способность сети»? Читай дальше что бы узнать.



Что означает «пропускная способность сети»?
Все наши 28 центров обработки данных подключены к Интернету через магистраль ОВЧ. Под этим мы подразумеваем нашу собственную сеть, управляемую нашими собственными командами. Эта сеть охватывает 32 точки присутствия (PoP), которые связаны друг с другом через волоконно-оптические кабели.

Каждый PoP действует как пересечение шоссе между OVH и другими провайдерами. К ним могут относиться провайдеры интернет-услуг, облачные провайдеры и операторы связи. Когда мы говорим о пропускной способности сети, мы имеем в виду общую емкость всех этих «пересечений». И это то, что достигло 15 Тбит / с.

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

Зачем нам нужны такие огромные мощности?
Управляя нашей основой, мы можем предложить нашим клиентам высококачественную пропускную способность и низкий уровень задержек в любой точке мира. Это также помогает нам защищать пользователей от атак типа «отказ в обслуживании» (DDoS).

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

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

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

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

Новые базовые маршрутизаторы были добавлены в центры обработки данных в Сиднее и Сингапуре. Каждый маршрутизатор поддерживает до 4,8 Тбит / с пропускной способности.

Мы также установили четыре новых магистральных маршрутизатора (два в Сингапуре и два в Сиднее), которые подключены через 100 Гбит / с. Благодаря этим дополнениям OVH может подключаться к большему числу поставщиков, и в результате мы можем расширить наши возможности за пределами нашей собственной сети.

OVH также инвестировал в 100 Гбит / с ссылки для подключения к другим PoP. Увеличение нашей способности справляться с DDoS-атаками усилило безопасность нашей сети.

Наконец, мы смогли получить драгоценные миллисекунды, добавив новую связь с низкой задержкой между двумя центрами данных OVH в Азиатско-Тихоокеанском регионе (задержка в 88 мс вместо 144 мс) и изменение маршрутизации через Сингапур.

Страсбург, 4 сентября 2018 года. Мы начали обзор наших инфраструктур с центрами данных Страсбурга, кодовыми именами SBG 1,2,3 и 4. Более месяца мы проведем экскурсию и осмотрим наши 12 сайтов и 28 центров обработки данных, развернутых по всему миру. Все перед нашим ежегодным мероприятием, саммит OVH, который состоится 18 октября в Париже.


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

Какие новости от SBG?
Начнем с электричества, после аудита, который мы начали на всех наших сайтах. В партнерстве с нашим поставщиком мы обеспечили инфраструктуру среднего напряжения на сайте. Мы отделили SBG1 от SBG2. Каждый центр данных теперь независимо и эффективно защищен. Со своей стороны, SGB3 был разработан с низковольтными генераторами и полностью независимыми цепями ИБП от SBG1 / 2 и 4.

Имеется в общей сложности 10 генераторов BT, протестированных ежемесячно для проверки электрической безопасности сайта.

Мы также начали ввод в эксплуатацию центра обработки данных SBG3, который извлекает выгоду из последних стандартов OVH, включая новые генераторы, которые его часть (см. Фото ниже). SBG3 будет иметь критическую ИТ-мощность 4 МВт и сможет вмещать до 25 000 серверов, что почти удвоит текущую общую пропускную способность сайта.



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

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

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

Четверг 7/09 состоялся второй этап нашего тура с центром обработки данных в Лимбурге в Германии, в нескольких миллисекундах от Страсбурга, по волокнам. Было вполне естественно путешествовать между Францией и Германией в тот же день, когда два бывших чемпиона мира по футболу встретились в Мюнхене!

Для управления инфраструктурой мы внедрили библиотеку передовой практики ITIL * в OVH, которая является гибкой организацией, используя методы SCRUM в развитии своих услуг. Репозиторий ITIL стал международным обязательством в области управления ИТ-услугами, но его также часто считают тяжелым и, вероятно, задушить организацию, теряя гибкость. Как SCRUM может сочетаться с ITIL? Объединив оба мира, вы получите «Agile Service Management».

Метод Agile основан на трех основных элементах:

• Взаимодействие между людьми
• Важность инструментов
• Непрерывная адаптация к изменениям

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

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

Аналогичным образом договорные соглашения переходят на внутренние соглашения (OLA) и внешние (SLA) соглашения об уровне обслуживания, которые позволяют измерять качество услуг без учета предполагаемого предоставляемого обслуживания.

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

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

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

Таким образом, объединение SCRUM и ITIL не является невозможным; мы тогда берем лучшее из обоих миров, полагаясь на первоначальную философию ITIL: «вдохновляйтесь этим методом и применяйте его так, чтобы он был вам лучше всего».

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

В OVH CAB не является административным органом, который управляет всем. Он распространяется таким образом, что вызов операций выполняется между «знанием». Мы задаем себе классические вопросы, связанные с изменениями, чтобы измерить его подготовку (укомплектование персоналом, время, откат ...) и присущий ему риск. С тех пор изменения отслеживаются, архивируются и передаются изнутри и снаружи через «рабочие» задачи.

Сварной водяной блок без какой-либо работы: мы последовательно выполнили 7 штук, которые были полностью собраны (водонепроницаемы), за один проход. Мы держим 10! в 0/1/10/100/1000 :)

Следующий шаг:
— тест на большой громкости
— проверить некоторые варианты параметров 1 на 1

travaux.ovh.net/?do=details&id=32451

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

Вот почему после шести лет хороших и лояльных услуг мы прекратим предложение VPS 2012. С четверга 13/09/2012 22:00 по Парижскому времени. В ночь на среду с 12 по четверг 13-го.

Объем: 639 x VPS 2012, все присутствующие на той же территории: vw-rbx2-018
Список оказанных услуг: дайте комментарий ниже.

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

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

Мы благодарим вас за ваше понимание, и мы будем рады встретить вас на наших новых диапазонах VPS.

Команда VPS OVH

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

Чтобы достичь этого, мы определили OpenStack (решение, на котором построено предложение Public Cloud), два основных момента, которые, по нашему мнению, необходимы для клиентов:

• Использование OpenStack API через клиенты OpenStack, библиотеки или API OVH v6;
• гарантированная производительность на экземплярах (процессор, оперативная память, диск, сеть).

В этой статье основное внимание уделяется первому вопросу: как в OVH мы измеряем производительность API Public Cloud. Я представлю решение, которое мы создали и как оно вписывается в экосистему ОВХ. Я закончу конкретный случай, который пока

Ралли: ориентированный на клиента инструмент тестирования OpenStack
Ралли — это кирпич проекта OpenStack, который определяется как Benchmarking как сервисное решение. Его роль заключается в проверке платформы OpenStack с точки зрения клиента и извлечении мер времени выполнения.

Проект, разработанный в Python, был начат в 2013 году. Версия 1.0.0 только что была выпущена в июле 2018 года. Выбор использования этого проекта в OVH был относительно прост, так как он является частью экосистемы OpenStack и что она обеспечивает функциональность, которая отвечает нашим потребностям.

Ралли предлагает запустить сценарии, которые являются наборами последовательных тестов, которые могут быть параметризованы с большей или меньшей степенью сложности. Таким образом, можно, например, просто протестировать создание маркера аутентификации и подтвердить операцию. Возможны и другие более сложные манипуляции: протестировать в одном сценарии аутентификацию и создание нескольких экземпляров путем присоединения томов. Эта гибкость позволяет нам представить довольно легко и без ограничений очень конкретные тесты. Ралли изначально обеспечивает очень много сценариев, классифицированных функциональными кирпичами (Nova, Neutron, Keystone, Glance, например).

Ралли измеряет время отклика на каждом этапе сценария и целиком. Данные сохраняются в базах данных и могут быть экспортированы в виде отчетов HTML или JSON. Инструмент способен повторять несколько раз по одному сценарию и вычислять средние значения, а также другие статистические данные (медиана, 90-й процентиль, 95-й процентиль, минимум, максимум) путем итерации и по всем из них.


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

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

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

Программная квалификация
Другое использование предусмотрено, когда мы должны выполнять патчи кода или выполнять обновления безопасности или программного обеспечения. В каждом из этих случаев трудно, без инструментов, измерять воздействие этих изменений. В качестве примера можно привести обновление ядра для последних недостатков безопасности (Spectre и Meldwon), которые объявили о снижении производительности. Ралли теперь позволяет нам легко оценить возможные последствия.

Аппаратная квалификация
Случай также может возникнуть, когда мы хотим протестировать новый ряд физических серверов для использования на панели управления OpenStack. Затем ралли позволяет нам проверить, есть ли разница в производительности.

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

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

Мы использовали экспорт JSON, реализованный в Rally, для извлечения измеренных значений во время тестов и нажатия их на платформу показателей. Затем мы создали приборную панель, которая позволяет нам визуализировать эти времена ответа с течением времени для каждого теста и по регионам. Мы можем легко визуализировать их эволюцию с течением времени и сравнивать время отклика по регионам. В соседних регионах (например, в Франции: GRA, RBX и SBG) мы должны получить практически одинаковое время отклика. Если это не так, мы ищем происхождение разницы, чтобы исправить проблему.


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

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

После дальнейших исследований мы обнаружили, что узкое место было на уровне базы данных для версии Juno OpenStack. Действительно, OpenStack применяет мягкое удаление при удалении данных. Это означает, что он помечает данные как удаленные, но фактически не удаляет их из таблицы. В нашем случае таблица «экземпляры» состоит из столбца «project_id» и «deleted». Когда Rally перечисляет серверы проекта, запрос имеет тип:

SELECT * FROM instances WHERE project_id=’xxx’ AND deleted = 0 ;

К сожалению, в Juno версии OpenStack в этой таблице нет индекса («project_ id», «deleted»), в отличие от версии OpenStack от Newton. В проекте Rally в каждом регионе тесты начинаются примерно с 3000 новых экземпляров каждый день. Через 3 месяца в наших базах данных было 270 000 экземпляров мягкого удаления. Этот большой объем данных в базах данных, связанных с отсутствием индексов в таблице, объясняет задержки, которые мы обнаружили в определенных регионах (только в версии Juno).

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


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

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

We just added 2x100G between Limburg and the POP of Frankfurt. We have now 600G of capacity between Limburg Datacenter and Frankfurt.

Крупнейший поставщик облачных технологий в Европе увеличил присутствие своего канала в США с новой партнерской программой.

OVHcloud, штаб-квартира которой находится в Рубе, Франция, вошла в рынок США только недавно, после приобретения VMware vcloud Air. Благодаря своей партнерской программе на уровне США, запущенной на этой неделе, OVHcloud надеется расширить охват своего портфеля IaaS, охватывая виртуальное облако, основанное на VMware, сервер с открытым металлом и общедоступные облачные опции.

Дэвид Вигглсворт Давид Уигглсворт
«Я думаю, что мы — лучшая техническая тайна, о которой никто не слышал», — сказал Дэвид Вигглсворт, главный сотрудник.


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

OVHcloud уже подписал несколько партнеров из США, включая поставщика решений FusionStorm. Вигглсворт отметил, что предложения OVHcloud также будут продаваться представителями продаж VMware.

HPE обновляет партнерскую программу
Hewlett Packard Enterprise (HPE) на этой неделе представила усовершенствования программы Partner Ready, которая теперь увеличивает вознаграждение для реселлеров.

По словам HPE, реселлеры теперь могут получать повышенные скидки и другие стимулы для продажи продуктов на «высоко растущих рынках», в частности, в хранилищах, в составной инфраструктуре, гиперкондиционных технологиях, программных и потребительских услугах. Улучшения программы Partner Ready вступят в силу 1 ноября, сказал HPE.

«Из-за изменений, которые мы внесли, реселлеры и другие типы бизнес-партнеров должны рассматривать это как возможность удвоить свой фокус и усилия вокруг HPE, потому что это окажется очень полезным», — сказал Терри Ричардсон, вице-президент North Американские каналы и альянсы в HPE.

Продукты HPE, которые соответствуют рыночным возможностям, которые он нацеливает, включают HPE Nimble Storage и 3PAR для хранения данных, SimpliVity и Synergy для композиционных и гиперконверсированных технологий, а также GreenLake и Datacenter Care для предложений, предлагаемых вовремя.

HPE заявила, что также улучшит партнерскую программу со следующими функциями:

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

RapidFire Tools расширяет возможности MSP
RapidFire Tools Inc., базирующаяся в Атланте, расширяет свои предложения поставщиков услуг (MSP) с помощью InDoc — инструмента, обеспечивающего веб-доступ к сетевым данным клиентов.

InDoc, облачный портал Amazon, встроен в продукт RapidFire Tools Network Detective Reporter для планирования автоматических сетевых сканирований и отчетов. Техники MSP могут использовать InDoc для получения сетевых данных с помощью настольных или мобильных устройств и могут также хранить информацию на портале, такую ​​как заметки о клиенте, процедуры исправления, контрольные списки и пароли. Информация хранится в зашифрованном хранилище данных. InDoc использует дополнительные уровни шифрования для конфиденциальных данных и паролей. Инструмент включает журнал использования, который обеспечивает аудиторский след техников, которые получили доступ к данным, и когда они это сделали, согласно RapidFire Tools.

Майкл Миттель (Michael Mittel), генеральный директор RapidFire Tools, сказал, что более 95% бизнеса компании принадлежит MSP, отметив, что поставщики услуг «все еще являются частью нашего бизнеса».

Он сказал, что RapidFire Tools теперь имеет более 6000 MSP, используя свои инструменты по всему миру. Он добавил, что компания расширяет свои предложения для включения продуктов, которые MSP могут перепродать своим клиентам.

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

Касея сообщает о росте на 30%, подписании МСП
Касея привел рост MSP, поскольку по сравнению с прошлым годом он увеличился более чем на 30% и прогнозирует ежегодные заказы на сумму более 250 миллионов долларов США.

Поставщик решений для управления ИТ-инфраструктурой сказал, что использование последней версии своего продукта удаленного мониторинга и управления, VSA, превысило ожидания компании. По словам Касеи, за первые несколько месяцев после ее выпуска более 300 организаций приняли эту технологию. Кроме того, компания заявила, что в 2018 году около 400 MSP подписали контракт на Unitrends MSP. В мае Касея приобрела Unitrends, поставщика непрерывности бизнеса и восстановления после сбоев (DR).

searchitchannel.techtarget.com/news/252447944/OVHcloud-expands-US-footprint-with-channel-partner-program

New GAME server customization:
2x 960GB NVMe + 4TB SATA
available on MC-64 and MC-64-OC
www.ovh.ie/dedicated_servers/game/1801mc03.xml
www.ovh.ie/dedicated_servers/game/1801mc04.xml

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

OVH высадился в Австралии в мае прошлого года и с тех пор сосредоточил свое внимание на местном секторе малого и среднего бизнеса.

Г-н Клаба сказал, что основная часть фундаментальной работы была завершена.

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

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

«Мы можем это сделать, потому что мы предлагаем высококачественные услуги, с преимуществами, которые нас отличает».

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

«Мы являемся многоместным облаком, где мы присутствуем во всем мире, но приспосабливаемся к разным культурам и рынкам», — сказал он.
«Хотя наши конкуренты часто блокируют наших клиентов, предлагая решения, которые нельзя использовать ни с кем другим, мы не предаем наших клиентов».

Стоимость OVH составляет 1,5 трлн. Долл. США, что является одним из немногих европейских единорогов, чтобы сделать отметку во всем мире.

Г-н Клаба сказал, что местные технологии начали догонять Силиконовой долине.

Есть более 600 частных стартапов стоимостью более $ 1 млрд, но только около 60 находятся в Европе.

«Европа опаздывает, но не наивна, а инициативы растут», — сказал г-н Клаба.

«Инновационная экосистема в Европе находится на подъеме, при этом многие стартапы расширяются и делают сбор средств на высоком уровне в Лондоне, Париже, Берлине, Лиссабоне или Таллинне».