Рейтинг
0.00

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

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

Выделенные серверы

  • Выделенные серверы: мы увеличили максимальную DS на заказ от 5 до 10 (API или веб-сайт).
  • Развернули CloudDB on SSD NVMe storage, повышая скорость ввода-вывода
  • Теперь мы предоставляем Redis 4.0 and MongoDB 4.0 для Cloud Dababases и частные предложения SQL. Так что теперь мы предоставляем MySQL, PgSQL, MariaDB, MongoDB и Redis.
  • Наши предложения электронной почты Pro теперь доступны в Польше
  • Private Cloud SDDC offers (hosts and storage dedicated to you only + VMware licences included) are now available inside our UK Datacenter

Evolution des services OpenStack a GRA1

Une opération de maintenance est programmée pour la région GRA1 le 10 octobre 2018, entre 21h00 et 1h00 (UTC+2). Aucune perturbation n'est à prévoir sur vos instances, mis à part certaines API de cette région qui resteront injoignables pendant la durée de l'opération.

Les endpoints API qui seront mis en maintenance sont les suivants:
compute.gra1.cloud.ovh.net/v2/
network.compute.gra1.cloud.ovh.net/
volume.compute.gra1.cloud.ovh.net/v1/
volume.compute.gra1.cloud.ovh.net/v2/
image.compute.gra1.cloud.ovh.net/

Les autres régions resteront accessibles par API et via votre interface client OVH.

Cette opération nous permet de préparer l'avenir. Grâce à cette montée de version d'OpenStack, nous allons pouvoir continuer d'améliorer notre offre Public Cloud en vous proposant de nouvelles fonctionnalités dans les prochains mois.

Les appels API que vous avez l'habitude d'utiliser ne changeront pas, cette nouvelle version est rétrocompatible avec l'ancienne.

Les versions cible des composants OpenStack de cette région seront:
  • Glance: 13.0.0 (Newton) ;
  • Cinder: 9.1.4 (Newton) ;
  • Nova: 14.1.0 (Newton) ;
  • Neutron: 9.4.1 (Newton).

Les composants non concernés par cette opération sont:
  • Keystone: 11.0.3 (Ocata) ;
  • Swift: 2.15.1 (Pike) ;
  • Horizon: 12.0.0 (Pike).

Vous pourrez suivre l'état d'avancement de l'opération en consultant cette tâche:
travaux.ovh.net/?do=details&id=34067

Harness the power of the OVH cloud for FY19

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 мс) и изменение маршрутизации через Сингапур.

Обзор датацентров 2019 года, шаг 1: Страсбург, Франция, Центральная Европа

Страсбург, 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 и гибкость для управления его инфраструктурами?

Для управления инфраструктурой мы внедрили библиотеку передовой практики 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 не является административным органом, который управляет всем. Он распространяется таким образом, что вызов операций выполняется между «знанием». Мы задаем себе классические вопросы, связанные с изменениями, чтобы измерить его подготовку (укомплектование персоналом, время, откат ...) и присущий ему риск. С тех пор изменения отслеживаются, архивируются и передаются изнутри и снаружи через «рабочие» задачи.