Краткая ретроспектива DDoS-атак на сетевом уровне в 2024 году на OVHcloud



1. Введение
Добро пожаловать на краткий ретроспективный обзор ландшафта DDoS-атак в 2024 году, как его видит OVHcloud.

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

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

Оставим контекст в стороне, давайте погрузимся в эту ретроспективу: какой год! 2024 год определенно стал важным поворотным моментом в истории DDoS, по крайней мере, с нашей точки зрения. От старых добрых методов DDoS, возвращающихся в больших масштабах, до нескольких рекордных атак, мы видели довольно много, и никто не сомневается, что события 2024 года станут основным движущим фактором для планирования инфраструктуры анти-DDoS в ближайшие годы.

2. Ковровые бомбардировки сейчас популярны как никогда
В течение 2024 года мы наблюдали внезапное увеличение атак с использованием техники, известной как «ковровая бомбардировка». Эта техника атаки названа в честь жестокого метода ведения войны, который заключается в методичной бомбардировке каждой части поверхности большой территории. Аналогично, «ковровая бомбардировка» в нашем контексте относится к атакам, нацеленным на гораздо большее количество IP-адресов, чем те, которые обслуживают фактическую цель.

Атаки с ковровыми бомбами используются в попытке обойти анти-DDoS-системы. Это связано с тем, что их гораздо сложнее обнаружить и автоматически нейтрализовать: отправляя несколько сотен мегабит в секунду на IP, злоумышленник может достичь огромных объемов, избегая (по крайней мере частично) эвристики обнаружения и возможных мер по нейтрализации. Проще говоря, вместо того, чтобы изо всех сил пытаться бомбить цель, просто бомбите всю область вокруг нее.


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

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

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

3. Рост числа атак с пакетной скоростью: миллиарды пакетов в секунду
В июне 2024 года мы опубликовали статью в блоге под названием «Рост атак на скорость пакетов: когда основные маршрутизаторы становятся злыми». 1 Эта статья представляла наши выводы, касающиеся небольших основных маршрутизаторов, участвующих в DDoS-атаках, и была побочным продуктом наших исследований тревожной тенденции с атаками на скорость пакетов. Читателям следует обратиться к цитируемой статье, чтобы получить подробное объяснение того, как они работают, и почему эти атаки остаются давней угрозой.

С конца 2023 года и начала 2024 года мы отметили значительное увеличение частоты и интенсивности атак с использованием пакетной скорости, при этом интенсивность достигла исторического максимума в конце лета.


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

Однако эта кампания атак не только достигла отметки в миллиард пакетов в секунду, но и фактически пошла намного дальше, достигнув скорости пакетов до 1,9 миллиарда пакетов в секунду. Такая скорость была ошеломляющей для наших команд, и это правильно! Символический порог был не только достигнут, но и значительно превышен. С тех пор несколько организаций сообщили о наблюдении атак 1+ Gpps и более: например, Cloudflare сообщила о скорости более 2 миллиардов пакетов в секунду 2 в кампании атак, которая произошла всего через несколько дней после кампании атак, нацеленной на OVHcloud и его клиентов, в то время как Global Secure Layer сообщила об одной атаке в 3,15 миллиарда пакетов в секунду в то же самое время.


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

4. Постоянно растущие гиперобъемные атаки: достигнуто 4 Тбит/с
В сентябре мы были в восторге от того, что смогли отразить нашу самую первую атаку на 3+ Тбит/с. Однако это был всего лишь предупредительный выстрел перед тем, что должно было произойти: еще одна масштабная кампания атак в октябре. Хотя мы видели всего несколько атак на 2+ Тбит/с в истории OVHcloud, эта двухнедельная кампания привела к более чем 40 атакам в диапазоне от 2 Тбит/с до рекордной (на тот момент) атаки на 4,2 Тбит/с.


Поскольку большинство атак имели схожие характеристики, мы сосредоточимся на самой крупной из них. На момент ее проведения эта атака была самой крупной атакой на битрейт (по сравнению с предыдущими публично известными записями). Она одновременно использовала несколько векторов атак: TCP ACK flood составил ~60% от общего трафика, прямой UDP flood составил 20%, а оставшиеся 20% были выполнены с различными отражениями UDP (в основном DNS).

Мы идентифицировали около 150 000 исходных IP-адресов, в основном принадлежащих домашним интернет-провайдерам из Европы и Северной Америки. В большинстве случаев злоумышленники, похоже, не использовали подмену источника, поскольку наши данные показывают, что трафик с IP-адресов, принадлежащих интернет-провайдеру, поступал из прямого пиринга с указанным интернет-провайдером или связанным провайдером обмена/транзита. Однако удивительное количество уникальных исходных IP-адресов и значительный объем, проходящий через обмен/транзит, указывают на то, что, возможно, имеет место необнаруженный подмен. Таким образом, общее количество уникальных исходных IP-адресов следует рассматривать с большой долей соли.

Еще одна примечательная вещь заключается в том, что несколько десятков атакующих IP-адресов отправляли 1+ Гбит/с каждый, что предполагает высококачественные бытовые соединения с большой пропускной способностью загрузки. Более того, согласно нашему анализу, весь трафик атак прямого пути (примерно 80% от общего числа) исходил из ботнета на базе Mirai.

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

Читатели должны обратить внимание, что после атаки на 4,2 Тбит/с, о которой мы только что говорили, несколько злоумышленников сообщили о еще более высоких показателях, таких как 5,6 Тбит/с на Cloudflare в конце 2024 года4 или более поздняя атака на 6,5 Тбит/с, о которой сообщила Nokia в феврале 2025 года.

5. Спуфинг институциональных и частных интернет-провайдеров
И последнее, но не менее важное: в течение года мы также наблюдали еще одну растущую тенденцию: крупномасштабный спуфинг крупных домашних интернет-провайдеров.

Мы привыкли видеть множество IP-адресов, принадлежащих домашним интернет-провайдерам, участвующим в атаках, поскольку множество скомпрометированных устройств находится в этих сетях (« Я вижу тебя… Интернет вещей! »). Однако мы наблюдали растущее число атак с использованием этих IP-адресов, но исходящих из дальнего зарубежья: например, мы обнаружили трафик, использующий IP-адреса основных французских интернет-провайдеров (Orange, SFR, Bouygues, Free), но исходящий с западного побережья США или Азиатско-Тихоокеанского региона и проходящий через не связанных между собой пиринговых партнеров (несмотря на то, что мы напрямую пирингуем с указанными интернет-провайдерами!). В этой ситуации исходные IP-адреса, очевидно, подделываются.



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

Объяснение этих атак заключается в том, что злоумышленники пытаются использовать гипотетические обходы в уровнях защиты, такие как слабый контроль скорости, правила разрешения/пересылки и другие. Это имеет смысл, поскольку, как крупный европейский игрок, базирующийся во Франции (со значительным бизнесом во Франции), мы могли бы рассмотреть возможность быть менее строгими с французскими IP-адресами. Также гораздо сложнее реагировать на атаку, которая может привести к действиям, также блокирующим законный трафик, что произойдет, если кто-то решит запретить целые диапазоны для таких атак (мы этого не делаем!).

Более того, иногда у нас есть клиенты, которые просят нас отключить любую защиту от DDoS для их IP-адресов, потому что «мы можем доверять им». Но Интернет работает не так. Как провайдер, защита от внешнего спуфинга, возможно, выполнима на бумаге, но на деле это почти невозможно. Вот почему у нас есть меры безопасности, и обход их даже с лучшими намерениями часто оказывается плохим решением не только для запрашивающих клиентов, но и для любых других служб, которые могут быть затронуты из-за этого.

Наконец, эта проблема подчеркивает критическую необходимость устранения DDoS-атак: все сетевые операторы должны играть свою роль в предотвращении IP-спуфинга. Это должно быть сделано на двух уровнях: на уровне сервера/коммутатора путем локального предотвращения IP-спуфинга с определенного хоста и на сетевом уровне путем предотвращения исходящего трафика с исходными IP-адресами, не принадлежащими сетевому оператору.

6. Операция PowerOFF и последствия
Операция PowerOFF — это продолжающаяся совместная операция нескольких правоохранительных органов по всему миру, специально направленная на прекращение операций DDoS-for-hire. В начале ноября 2024 года они закрыли печально известную платформу dstatc.cc, которая предоставляла злоумышленникам средства для оценки возможностей и эффективности DDoS-атак. Наряду с этим закрытием были закрыты несколько веб-сайтов DDoS-for-hire, ликвидированы ботнеты и арестованы киберпреступники.


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

7. Заключение и заключительные слова
В прошлом атаки DDoS на сетевом уровне часто игнорировались как незначительное неудобство или даже как решенная проблема. Однако, как показал 2024 год, они по-прежнему представляют собой растущую и давнюю угрозу, с которой необходимо серьезно бороться. Это одна из причин, по которой атаки DDoS часто упоминаются в отчетах об угрозах, исходящих от различных субъектов, таких как недавний отчет об угрозах, опубликованный Французским национальным агентством информационной безопасности (ANSSI) в феврале 2025 года.

Хотя атаки на уровне приложений (особенно HTTPS) сейчас более популярны по нескольким причинам, никто не должен игнорировать атаки на сетевом уровне как незначительный риск. Если успешная работа с миллиардами пакетов в секунду или несколькими терабитами трафика может показаться достижением для некоторых из нас, для многих это очень сложная задача. Будьте готовы!

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

Chat Ovhcloud Changelog





chat.ovhcloud.com

26-03-2025
Новые функции
  • Добавлено сохранение разговоров в браузере.
  • Добавлена ​​страница «О программе».
  • Добавлена ​​страница настроек.
  • Добавлена ​​возможность экспортировать и импортировать историю разговоров из файла JSON.
  • Добавлена ​​возможность использовать пользовательский токен OVHcloud AI Endpoints.
  • Добавлена ​​поддержка отправки вложений в чате.
  • Добавлена ​​кнопка «Журнал изменений» на вертикальной панели навигации.
  • Добавлен отказ от ответственности при запуске приложения.

Улучшения
  • Переработан дизайн приложения с использованием цветов OVHcloud.
  • Исправлены ошибки и улучшена производительность.

19-03-2025
Исправления ошибок
  • Изображения выгружались, когда покидали экран, что изменяло продолжительность обсуждения и вызывало ошибки прокрутки, когда пользователь прокручивал страницу.
  • Кнопка «Назад» в аудиоплеере работала неправильно при воспроизведении звука.

Новые функции
  • История разговоров теперь отображается во всплывающем окне, чтобы интерфейс был максимально чистым и отображал только то, что действительно полезно.
  • Добавлена ​​кнопка «Изменить». Добавлена ​​кнопка «Новый чат».

Улучшения
  • Изменена логика прокрутки в разговорах: теперь, если пользователь прокручивает страницу вверх, разговор больше не прокручивается автоматически при генерации ответа.
  • Добавлена ​​кнопка, которая появляется, когда пользователь не находится в конце разговора, что позволяет быстро прокручивать страницу вниз.
  • Улучшено отображение ошибок при сбое шага в плане выполнения.
  • Добавлена ​​анимация, указывающая пользователю на то, что план выполнения генерируется. Добавлена ​​анимация, указывающая пользователю на то, что ответ генерируется.
  • Добавлена ​​возможность остановить генерацию ответа.
  • Пользователь больше не может отправлять сообщения во время генерации ответа.
  • Оптимизирована производительность приложения.

OVHcloud размещает несколько миллионов веб-сайтов на платформе WebCloud



OVHcloud размещает несколько миллионов веб-сайтов на платформе WebCloud, которая внутри компании называется «mutu». Он состоит из нескольких технических элементов: шлюз, вычислительные мощности, хранилище, база данных, резервное копирование.

Сегодня давайте немного поговорим о шлюзе.

Когда вы вводите https:// с сайта, размещенного на «mutu», вы запускаете веб-соединение со шлюзом, который защищает соединение между клиентом и веб-сайтом с помощью шифрования SSL. OVHcloud использует Let's Encrypt SSL, партнером которого мы являемся со статусом Platinum с момента… их основания :)

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

В настоящее время мы меняем тип алгоритма шифрования с RSA 4096 на ECDSA P-256. В марте около 75% сертификатов все еще были в формате RSA 4096 и только 25% в формате ECDSA P-256, но через 3 месяца 100% будут в формате ECDSA P-256.

Почему мы меняем алгоритм шифрования?
Мы планируем использовать генерацию случайных чисел с помощью QRNG (квантового компьютера) для повышения качества наших SSL-сертификатов. Квантовая технология предоставляет нам более качественную «случайную» цепочку, уровень энтропии которой можно проверить в любой момент. В более общем плане QRNG обеспечивает 85% энтропии вместо 70% для электроники. Это математика… :)

Чтобы сгенерировать закрытый ключ ECDSA P-256, (только) 32 байта случайных данных. Это намного меньше, чем RSA 4096. Мы пытаемся использовать меньше символов и распространить использование QNRG на все сертификаты.

По трафику веб-сайта мы можем наблюдать распределение HTTP (без шифрования) и HTTPS (с шифрованием):
  • 59% HTTPS
  • 41% HTTP (перенаправление HTTP -> HTTPS)

Для трафика HTTPS распределение TLS выглядит следующим образом:
  • 88% ТЛС1.3
  • 12% ТЛС1.2

С точки зрения производительности ECDSA быстрее RSA при обмене доменами верхнего уровня. Это в основном связано с тем, что размеры ключей меньше, а значит, и сертификат SSL также меньше. Это означает, что для установления TLS-соединения требуется передавать меньше данных, и, следовательно, сокращается время загрузки веб-сайта :)

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

Я бы хотел предоставить вам раздел о Anti-DDoS L7, который мы внедрили на наших шлюзах, но тема слишком деликатна, чтобы раскрывать технические подробности о методах защиты, которые мы внедрили (и мы совершенствуемся с каждым днем).

www.ovhcloud.com/en-ie/web-hosting/

Изменение цен на несколько расширений доменных имен

Несколько регистраторов сообщили нам о повышении цен.

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

В таблице ниже вы найдете список соответствующих продлений, а также новые цены на продление, действующие с пятницы, 4 апреля 2025 года.




Чтобы воспользоваться текущими более низкими ценами в течение 10 лет, мы настоятельно рекомендуем продлить регистрацию всех соответствующих доменных имен до пятницы, 4 апреля 2025 года.

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

IP Failover — это хорошо, BGP — лучше



Для переключения трафика с одной платформы на другую, с одной виртуальной машины на другую, для балансировки нагрузки в RR

labs.ovhcloud.com/en/bgp-service/

Почему стоит выбрать наше решение BGP?
  • Высокая доступность и отказоустойчивость: многосетевое подключение обеспечивает бесперебойную работу сети.
  • Используйте свой собственный IP-адрес (BYOIP): анонсируйте свои собственные префиксы IP-адресов непосредственно в нашей глобальной магистральной сети.
  • Защита от DDoS-атак: интегрированные средства защиты защищают вашу инфраструктуру от масштабных атак.
  • Простая интеграция с облаком: простая интеграция BGP с нашими VPS, Baremetal, публичными и частными облачными сервисами (на этапе альфа-тестирования поддерживается только Baremetal).

Огромная работа была проделана в районе Франкфурта по оптической сети



Во-первых, переход на новую архитектуру Gridless следующих 2 узлов:
  • Центр обработки данных Лимбург, Делавэр
  • Equinix FR5 PoP
Он также включает в себя сайты, напрямую подключенные к этим двум узлам.

Включите 800Gbps carrier lambda в нашей оптической сети. Теперь мы можем развернуть новые маршрутизаторы для поддержки 400Gbps соединений в нашем центре обработки данных Limburg,DE.

Вот некоторые цифры для той же пропускной способности между Лимбургом и Франкфуртом:
  • увеличить использование спектра на 52% (с 937,5 ГГц до 450 ГГц)
  • снизить стоимость 100 Гбит/с на 51%
  • сократить наш экологический след на 33%
  • снизить энергопотребление на 50% (с 0,6 Вт/Гбит/с до 0,3 Вт/Гбит/с)

Во-вторых, повышение отказоустойчивости центра обработки данных Лимбург, Германия, а также всего Франкфурта и всех других центров обработки данных OVHcloud.


  • воспользовался преимуществами Gridless Migration для разделения узла ROADM на 2 разных фотонных узла
  • интегрировали новую точку доступа Interxion FRA15 в нашу оптическую сеть, что включает перемещение одного из двух волокон из центра обработки данных в Страсбурге, Франция, в это новое место
  • включите новое оптоволокно между Datacenter Limburg, FR и новой точкой доступа FRA15, добавив разнообразия для центра обработки данных. Datacenter Limburg,DE теперь имеет 3 различных пути к внешнему миру

Слава командам! Отличная работа!

В последние несколько дней мы много слышим о проектах строительства «центров обработки данных мощностью 1 ГВт» для ИИ во Франции

Чтобы понять потребность, вы должны помнить эти три цифры:

Потребуется 50Me для инвестирования в 1000 графических процессоров, которые будут работать в центре обработки данных, потребляющем 1 МВт электроэнергии.

Эти три числа работают вместе на нескольких уровнях шкалы:
  • 50Me — 1k GPU — 1MW
  • 500Me — 10k GPU — 10MW
  • 5Mde — 100k GPU — 100MW
  • 50Mde — 1M GPU — 1GW

80% этих сумм используются для покупки графических процессоров, 20% — для создания центра обработки данных.

Для какой нужды? Графические процессоры используются в двух целях:
  • обучение и, следовательно, создание модели LLM с данными (обучение)
  • использование существующей модели LLM клиентами (вывод)

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

Вот почему для нужд обучения на рынок выходит новое поколение графических процессоров: суперчипы. Вместо десятков независимых графических процессоров, которые вы подключаете друг к другу последовательно, каждый суперчип объединяет десятки графических процессоров на одной карте. Отличная работа! Вы сократили расстояние между графическими процессорами и теперь можете подключить в 10 раз больше графических процессоров вместе, не снижая производительности. С другой стороны, у вас есть новые задачи, которые нужно решить: как распределить энергию и охладить инфраструктуру, которая в 10 раз плотнее, как приобрести источник энергии мощностью 1 ГВт и как обеспечить его избыточность.

Для размещения вычислительной мощности в центре обработки данных мы используем отсеки, также известные как стойки, которые представляют собой своего рода шкафы шириной 0,6 м, глубиной 1 м и высотой 2,5 м. На каждый отсек подается около 20 кВт электроэнергии. Для его охлаждения используется свежий воздух, прогоняемый через залив.

Если мы хотим использовать в отсеке более 20 кВт, воздуха будет недостаточно для его охлаждения. Вам необходимо перейти на водяное охлаждение. Вот тут мы начинаем говорить о новом поколении центров обработки данных, и в некоторых случаях речь идет о мощности 1 ГВт. Действительно, для размещения суперчипов мы сейчас говорим о стойках мощностью 120 кВт или даже предполагаем 240 кВт на стойку и систему водяного охлаждения для улавливания и отвода всего этого тепла. Это совершенно новое решение с точки зрения мощности на отсек, а также с точки зрения масштабируемой системы водяного охлаждения. Вот почему такого типа ЦОД не существует и поэтому его необходимо построить.

Для использования выводов нет необходимости в столь сложных центрах обработки данных. И суперчип тоже не нужен. Для модели LLM требуется система графических процессоров, потребляющая от 100 Вт до 10 кВт, редко 20 кВт, что эквивалентно от 1 до 16 графических процессоров. Поскольку каждая система независима, вы можете подключить столько систем параллельно, сколько захотите, что позволит вам обрабатывать большой веб-трафик или мобильный трафик. Еще лучше иметь несколько центров обработки данных вывода, работающих параллельно, и почему бы не создать по одному на страну? Это обеспечивает высокую доступность и низкие задержки за счет использования ближайшего к посетителю центра обработки данных.

И причем здесь OVHcloud? У нас более 40 центров обработки данных в нескольких странах Европы, Канады, Северной Америки и Азии. Мы являемся экспертами в области водяного охлаждения уже более 20 лет. Это позволяет нам охлаждать более 500 тыс. физических серверов во всех наших центрах обработки данных. Наши внутренние технологии с открытым исходным кодом обходятся в 20–40 раз дешевле рыночных решений. У нас есть центры обработки данных мощностью от 40 МВт до 100 МВт, в которых можно проводить обучение, с отсеками мощностью 40 кВт, но у нас также есть центры обработки данных по всему миру для предоставления выводов. Наши инвестиции соответствуют потребностям наших клиентов, и при необходимости мы можем ускориться.

Развертывание Nutanix на OVHcloud начинается здесь



Хотите начать с малого и расширяться? Новая линейка OVHcloud SCALE, включающая выделенные серверы, сертифицированные Nutanix, идеально подходит для начала.

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

www.ovhcloud.com/en-ie/hosted-private-cloud/nutanix/configurator/





Масштабируйтесь по мере роста:
Благодаря 72 готовым конфигурациям и полностью настраиваемым параметрам серверы SCALE идеально подходят для аварийного восстановления, миграции рабочих нагрузок и ресурсоемких сред Nutanix.

Готовы начать?
Изучите Nutanix на OVHcloud: ознакомьтесь с серверами SCALE
Погрузитесь в подробности: прочитайте наш блог
Переходите на Nutanix на OVHcloud, масштабируйтесь уже сегодня!

С уважением,
Команда OVHcloud