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

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

Начали говорить о наших партнерах и предложениях с VMware OpenStack Veeam Zerto и FusionStormIT обеспечить расширение центра обработки данных, замена центра обработки данных и аварийного восстановления.

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

Speed, flexibility and simplicity
Combine the very best aspects of both our Public Cloud solutions and Web Hosting plans.
With Cloud Web, you get an isolated, easy-to-use server with an ultra-powerful SSD disk!
www.ovh.ie/web-hosting/cloud-web.xml

Grab our promotional offers to reserve your .rent, .college or .website domain name, and get up to 83% off!
www.ovh.ie/domains/

Need help configuring your server or solution? Fear not, brave soldier — our technical guides are here to help you.
docs.ovh.com/ie/en/


summit.ovh.com/en

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

«Что делает меня самым гордым, так это то, что TheOverTheBox (OTB) — это чистый проект наших исследований и разработок и обогащенный обратной связью с клиентами», — говорит Башир Эсса, инженер-исследователь по телекоммуникациям в OVH. Первоначальная идея заключалась в том, чтобы найти продукт, который обеспечит его доступ в Интернет и увеличит его скорость. После многих исследований и тестов появилась первая версия OverTheBox. «С течением времени появились новые идеи. Клиенты сделали много возвратов использования, которые мы приняли во внимание, потому что использование первой версии OTB было «слишком сложным» для подавляющего большинства пользователей. И с нашей стороны, мы, вундеркинды R & D, мы всегда ищем прирост производительности и добавленные функции, микро-настройки. С этими двумя дополнительными предубеждениями мы пришли ко второй версии OTB. "

В частности, новая версия изначально в 3 раза мощнее, чем ее предшественница, с максимальной зашифрованной скоростью 400 Мбит / с против 130 прежде, благодаря использованию очень мощного и недавнего сообщества, поэтому недавнее, что это должен был изменить наше ядро, чтобы иметь возможность отключить окно!

Среди других новинок коммутатор был интегрирован на передней панели, он является важным компонентом для упрощения конфигурации, поскольку клиентам больше не нужно отключать DHCP своих ящиков для работы службы, которая была черная точка v1. Этот коммутатор имеет 14 портов, в том числе 2 WAN по умолчанию, но все легко модифицируется клиентом, если он пожелает. Эргономика корпуса также была пересмотрена, чтобы предложить «стойкий» формат. Это подходит для наших новых профессиональных клиентов, которые полагаются на OTB для своей сети.

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

Адриен Галлоу, разработчик OTB, поднимает капюшон для любопытных, чтобы понять, как все это работает.

В OTBv2 есть две технологии агрегации. С одной стороны, MPTCP, основанный на TCP, позволяет объединять только TCP-соединения, а с другой, MUD, основанный на UDP, позволяет агрегировать все протоколы. Каждая из этих технологий имеет разные характеристики. MPTCP пытается максимизировать пропускную способность, поддерживая хорошую задержку, в то время как MUD пытается минимизировать задержку, пытаясь сохранить хороший битрейт.

Первая версия OTB запускалась в туннеле TCP для трафика, отличного от TCP (который не агрегируется MPTCP). Агрегация пожертвовала латентностью в пользу пропускной способности, что не всегда соответствовало трафику, особенно VoIP. Поэтому мы добавили новый туннель на основе MUD для агрегирования чувствительных к задержкам сообщений (и, в частности, дрожания).

Мы предлагаем три различные технологии агрегации:

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

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

Одна из главных критических замечаний, высказанных клиентами, через форумы или во время событий, особенно в ходе Саммита 2017 года, действительно была сложностью конфигурации. «Первая версия потребовала много настроек и предоставила пользователю возможность настраивать практически любой параметр», — говорит Grégoire Delattre, DevOps по проекту с самого начала. Это предполагает, что он сам знает, что у него есть навыки, в противном случае риск велик, что он не может получить желаемое качество. Вот почему для этой второй версии мы выбрали конфигурацию, предложенную по умолчанию. Это намного проще для подавляющего большинства пользователей, и полученные результаты в среднем намного лучше. Разумеется, самая знающая воля всегда будет в состоянии настраивать и настраивать по своему усмотрению, как объяснил Адриен.

«Мы всегда хотим сделать лучше. У нас уже есть другие потенциальные улучшения, такие как интеграция решения частной сети vRack в службу OverTheBox, чтобы сделать OTB шлюзом для всех служб OVH, — говорит Grégoire. Тем временем, версия 2 выполняет свои обещания в том смысле, что клиент, который вызвал нас при малейшем падении потока, который он нашел, никогда не связывается с нами сейчас, потому что его решение OTB автоматически решает проблему! ».

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

www.ovh.co.uk/private-cloud/

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

Чтобы достичь этого, мы определили 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.