Cloudflare Сервис

30 октября 2024 года поставщик облачного хостинга OVHcloud (AS16276) столкнулся с кратковременным, но значительным отключением. Согласно их отчету об инциденте, проблема началась в 13:23 UTC и была описана просто как « Происходит инцидент на нашей магистральной инфраструктуре ». OVHcloud отметил, что инцидент закончился 17 минут спустя, в 13:40 UTC. Как крупный глобальный поставщик облачного хостинга, некоторые клиенты используют OVHcloud в качестве источника для сайтов, предоставляемых Cloudflare — если заданный контент-актив отсутствует в нашем кэше для сайта клиента, мы извлекаем актив из OVHcloud.

Мы наблюдали, как трафик начал падать в 13:21 UTC, как раз перед заявленным временем начала. К 13:28 UTC он был примерно на 95% ниже, чем до инцидента. Восстановление, по-видимому, началось в 13:31 UTC, а к 13:40 UTC, заявленному времени окончания инцидента, он достиг примерно 50% от уровня до инцидента.



Cloudflare обычно обменивается большей частью своего трафика с OVHcloud по пиринговым ссылкам. Однако, как показано ниже, объем пирингового трафика во время инцидента значительно упал. Похоже, что некоторый небольшой объем трафика на короткое время начал проходить по транзитным ссылкам из Cloudflare в OVHcloud из-за внезапных изменений в дата-центрах Cloudflare, в которых мы получали запросы OVHcloud. (Пиринг — это прямое соединение между двумя сетевыми провайдерами с целью обмена трафиком. Транзит — это когда одна сеть платит промежуточной сети за передачу трафика в сеть назначения.)




Поскольку мы пирингуем напрямую, мы обмениваемся большей частью трафика через наши частные сеансы пирингования с OVHcloud. Вместо этого мы обнаружили, что маршрутизация OVHcloud в Cloudflare полностью прекратилась на несколько минут, затем переключилась на один порт Internet Exchange в Амстердаме и, наконец, нормализовалась глобально через несколько минут.

Как показывают графики ниже, мы обычно видим наибольший объем трафика от OVHcloud в наших центрах обработки данных во Франкфурте и Париже, поскольку OVHcloud имеет крупные центры обработки данных в этих регионах. Однако при этом переходе к транзиту и переходе к точке обмена данными Amsterdam Internet Exchange мы увидели всплеск трафика, направляемого в наш центр обработки данных в Амстердаме. Мы подозреваем, что изменения маршрутизации являются самыми ранними признаками либо внутренней реконвергенции BGP, либо общего восстановления сети в пределах AS12676, начиная с их присутствия вблизи нашей точки обмена данными в Амстердаме.

В отчете о расследовании, опубликованном OVHcloud, отмечается, что инцидент был вызван « проблемой в конфигурации сети, ошибочно допущенной одним из наших пиринговых партнеров », и что « мы немедленно перенастроили наши сетевые маршруты для восстановления трафика ». Одним из возможных объяснений инцидента с магистральной сетью может быть утечка маршрута BGP упомянутым пиринговым партнером, когда OVHcloud мог принять полную таблицу Интернета от однорангового узла и, следовательно, перегрузить свою сеть или сеть пирингового партнера трафиком или вызвать неожиданные внутренние обновления маршрута BGP в AS12676.

При расследовании того, какая утечка маршрута могла стать причиной инцидента, затронувшего OVHcloud, мы обнаружили доказательства нарушения максимального порогового значения префикса на нашем пиринге с Worldstream (AS49981) в Амстердаме.

Oct 30 13:16:53  edge02.ams01 rpd[9669]: RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 141.101.65.53 (External AS 49981) changed state from Established to Idle (event PrefixLimitExceeded) (instance master)

Поскольку количество полученных префиксов превысило лимиты, настроенные для нашего пирингового сеанса с Worldstream, сеанс BGP автоматически перешел в состояние ожидания. Это предотвратило влияние утечки маршрута на сеть Cloudflare. При анализе данных протокола мониторинга BGP (BMP) из AS49981 до автоматического отключения сеанса мы смогли подтвердить, что Worldstream отправлял объявления с AS-путями, которые содержали их транзитного провайдера Tier 1 восходящего потока.

За это время мы также обнаружили более 500 000 объявлений BGP от AS49981, поскольку Worldstream объявлял маршруты многим своим одноранговым узлам, что видно на Cloudflare Radar.


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

Из-за ошибки конфигурации на одном из основных маршрутизаторов все маршруты были на короткое время объявлены всем нашим одноранговым узлам. В результате мы получили больше трафика, чем ожидалось, что привело к перегрузке на некоторых путях. Чтобы решить эту проблему, мы временно отключили эти сеансы BGP, чтобы локализовать проблему и стабилизировать сеть. Приносим извинения за неудобства

Мы полагаем, что Worldstream также раскрыл маршруты в ходе пиринговой сессии OVHcloud в Амстердаме, что и привело к сегодняшним последствиям.

Заключение
Cloudflare уже писала о существенных утечках маршрутов, и существует несколько методов, позволяющих предотвратить влияние утечек маршрутов BGP на вашу сеть. Один из них — установить максимальные ограничения префиксов для однорангового узла, чтобы сеанс BGP автоматически разрывался, когда одноранговый узел отправляет больше префиксов, чем ожидается. Другие перспективные меры — это Autonomous System Provider Authorization (ASPA) для BGP, где Resource Public Key Infrastructure (RPKI) помогает защитить сеть от принятия маршрутов BGP с недействительным путем AS, или RFC9234, который предотвращает утечки, привязывая строгие отношения между клиентами и поставщиками к обновлениям BGP. Для повышения устойчивости Интернета мы рекомендуем операторам сетей следовать рекомендациям, определенным в MANRS для операторов сетей manrs.org/netops/

Два года назад Cloudflare развернула наш парк серверов 12-го поколения на базе процессоров AMD EPYC Genoa-X с их огромным 3D V-кэшем. Эта архитектура с большим объемом кэша идеально подходила для нашего уровня обработки запросов, на тот момент FL1. Но при оценке оборудования следующего поколения мы столкнулись с дилеммой — процессоры, обеспечивающие наибольший прирост пропускной способности, сопровождались значительным уменьшением объема кэша. Наш устаревший программный стек не был оптимизирован для этого, и потенциальные преимущества в пропускной способности ограничивались растущей задержкой.

В этом блоге описывается, как переход на FL2 — переписанный на Rust основной слой обработки запросов Cloudflare — позволил нам продемонстрировать весь потенциал Gen 13 и добиться повышения производительности, которое было бы невозможно на нашей предыдущей платформе. FL2 устраняет зависимость от большего кэша, позволяя масштабировать производительность в зависимости от количества ядер, сохраняя при этом наши соглашения об уровне обслуживания (SLA). Сегодня мы с гордостью объявляем о запуске Cloudflare Gen 13 на базе серверов AMD EPYC™ 5-го поколения Turin, работающих под управлением FL2, эффективно захватывая и масштабируя производительность на периферии сети.

Что предлагает AMD EPYCTurin?

• Процессоры AMD EPYC 5-го поколения на базе архитектуры Turin обеспечивают не только увеличение количества ядер. Архитектура улучшает работу серверов Cloudflare по многим параметрам.
• Увеличено в 2 раза количество ядер: до 192 ядер против 96 ядер у 12-го поколения, при этом технология SMT обеспечивает 384 потока.
• Улучшенная производительность на такт: архитектурные улучшения Zen 5 обеспечивают более высокую частоту инструкций за цикл по сравнению с Zen 4.
• Повышенная энергоэффективность: несмотря на большее количество ядер, Turin потребляет до 32% меньше ватт на ядро ​​по сравнению с Genoa-X.
• Поддержка DDR5-6400: более высокая пропускная способность памяти для обеспечения работы всех этих ядер.

Однако процессоры Turin с высокой плотностью OPN намеренно идут на компромисс: приоритет отдается пропускной способности, а не кэшу на ядро. Наш анализ всей линейки Turin выявил этот сдвиг. Например, сравнение процессоров Turin с самой высокой плотностью OPN с нашими процессорами Gen 12 Genoa-X показывает, что 192 ядра Turin используют 384 МБ кэша L3. Это оставляет каждому ядру доступ всего к 2 МБ, что составляет одну шестую часть от объема кэша Gen 12. Для любой рабочей нагрузки, которая в значительной степени зависит от локальности кэша, как в нашем случае, это сокращение представляло серьезную проблему.



Диагностика проблемы с помощью счетчиков производительности.
Для нашего слоя обработки запросов FL1, основанного на NGINX и LuaJIT, это сокращение кэша представляло собой серьезную проблему. Но мы не просто предположили, что это будет проблемой; мы провели измерения.
В ходе оценки производительности процессоров 13-го поколения мы собрали данные счетчиков производительности и профилирования процессора, чтобы точно определить, что происходит «под капотом», используя инструмент AMD uProf. Полученные данные показали:

• По сравнению с серверами 12-го поколения, оснащенными 3D V-кэш-процессорами, частота промахов в кэше L3 значительно возросла.
• Задержка при выборке данных из памяти определяла основное время обработки запроса, поскольку данные, которые ранее хранились в L3, теперь требовали обращения к DRAM.
• Увеличение задержки возрастало по мере роста загрузки ЦП и ухудшения конкуренции за кэш.

Попадание в кэш L3 завершается примерно за 50 циклов; промахи в кэше L3, требующие доступа к DRAM, занимают более 350 циклов, что на порядок больше. При в 6 раз меньшем объеме кэша на ядро, FL1 на процессорах 13-го поколения обращался к памяти гораздо чаще, что приводило к задержкам.

Компромисс: задержка против пропускной способности
Наши первоначальные тесты, проведенные на FL1 на процессорах 13-го поколения, подтвердили то, что уже указывали счетчики производительности. Хотя процессор Turin мог обеспечить более высокую пропускную способность, это сопровождалось значительными задержками.


Оценочный сервер Gen 13 с процессором AMD Turin 9965, показавший 60% прирост пропускной способности, оказался впечатляющим, а повышение производительности обеспечило наибольшее улучшение общей стоимости владения (TCO) для Cloudflare.

Однако увеличение задержки более чем на 50% неприемлемо. Рост задержки обработки запросов напрямую повлияет на качество обслуживания клиентов. Мы столкнулись со знакомым вопросом об инфраструктуре: принять ли решение без выгоды с точки зрения совокупной стоимости владения, смириться с увеличением задержки или найти способ повысить эффективность без увеличения задержки?

Постепенное повышение производительности за счет оптимизации параметров.
Чтобы найти путь к оптимальному результату, мы сотрудничали с AMD для анализа данных Turin 9965 и проведения целенаправленных экспериментов по оптимизации. Мы систематически тестировали множество конфигураций:

• Настройка оборудования: корректировка аппаратных средств предварительной выборки и фильтров зондирования Data Fabric (DF), показавшая лишь незначительные улучшения.
• Увеличение количества рабочих: запуск большего количества рабочих уровня FL1, что повысило производительность, но привело к перераспределению ресурсов из других производственных служб.
• Привязка и изоляция ЦП: Настройка конфигураций изоляции рабочих нагрузок для поиска оптимального сочетания, с ограниченным успехом.

Конфигурация, которая в конечном итоге принесла наибольшую пользу, оказалась конфигурацией с поддержкой технологии AMD Platform Quality of Service (PQOS). Расширения PQOS позволяют осуществлять тонкую регулировку совместно используемых ресурсов, таких как кэш и пропускная способность памяти. Поскольку процессоры Turin состоят из одного кристалла ввода-вывода и до 12 кристаллов ядерных комплексов (CCD), каждый из которых использует кэш L3 на 16 ядрах, мы протестировали эту технологию. Вот как показали себя различные экспериментальные конфигурации.

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



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

К счастью, нам не приходилось начинать с нуля. Как мы объявили во время Недели Дня рождения 2025 года, мы уже перестраивали FL1 с нуля. FL2 — это полная переработка нашего слоя обработки запросов на Rust, построенная на основе наших фреймворков Pingora и Oxy, заменяющая 15 лет кода NGINX и LuaJIT.

Проект FL2 не был инициирован для решения проблемы кэша 13-го поколения — он был обусловлен необходимостью повышения безопасности (безопасность памяти в Rust), ускорения темпов разработки (строгая модульная система) и повышения общей производительности (меньше ресурсов ЦП, меньше памяти, модульное выполнение).

Более чистая архитектура FL2, с улучшенными шаблонами доступа к памяти и меньшим количеством динамического выделения памяти, возможно, не будет зависеть от огромных кэшей L3 так, как это было в FL1. Это дало нам возможность использовать переход на FL2, чтобы доказать, можно ли реализовать прирост пропускной способности Gen 13 без увеличения задержки.

Проверка: FL2 на Gen 13
По мере развертывания FL2, показатели производительности наших серверов 13-го поколения подтвердили наши предположения.


Повышение эффективности работы нашей новой системы FL2 оказалось существенным еще до каких-либо оптимизаций. FL2 сократила задержку на 70%, что позволило нам повысить загрузку ЦП на процессорах 13-го поколения, строго соблюдая наши соглашения об уровне обслуживания (SLA) по задержке. В случае с FL1 это было бы невозможно.

Благодаря эффективному устранению узкого места в кэше, FL2 позволяет масштабировать пропускную способность линейно в зависимости от количества ядер. Влияние неоспоримо на высокопроизводительные процессоры AMD Turin 9965: мы добились двукратного прироста производительности, раскрыв истинный потенциал оборудования. Дальнейшая настройка системы позволит нам добиться еще большей мощности от нашего парка процессоров 13-го поколения.

Улучшение характеристик с появлением 13-го поколения.
Благодаря тому, что FL2 раскрыл огромный потенциал высокопроизводительных процессоров AMD Turin 9965 с большим количеством ядер, мы официально выбрали эти процессоры для развертывания в рамках 13-го поколения. Аппаратная квалификация завершена, и серверы 13-го поколения уже поставляются в больших объемах для поддержки нашего глобального развертывания.

Улучшения производительности


Влияние Gen 13 на бизнес
Увеличенная вдвое пропускная способность по сравнению с Gen 12 для бескомпромиссного качества обслуживания клиентов: удваивая пропускную способность при сохранении соответствия нашим соглашениям об уровне обслуживания (SLA) по задержке, мы гарантируем, что наши приложения останутся быстрыми и отзывчивыми, а также смогут выдерживать огромные пики трафика.

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

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

Gen 13 + FL2: готовы к пределу возможностей
Наш устаревший уровень обработки запросов FL1 столкнулся с проблемой конкуренции за кэш на Gen 13, что вынудило нас пойти на неприемлемый компромисс между пропускной способностью и задержкой. Вместо того чтобы идти на компромисс, мы создали FL2.

Разработанная с использованием значительно более оптимизированной схемы доступа к памяти, технология FL2 устраняет зависимость от огромных кэшей L3 и обеспечивает линейное масштабирование в зависимости от количества ядер. Работая на платформе AMD Turin 13-го поколения, FL2 обеспечивает вдвое большую пропускную способность и 50% повышение энергоэффективности, при этом сохраняя задержку в пределах наших соглашений об уровне обслуживания (SLA). Этот прорыв является отличным напоминанием о важности совместной разработки аппаратного и программного обеспечения. Серверы 13-го поколения, не ограниченные лимитами кэша, теперь готовы к развертыванию для обработки миллионов запросов в глобальной сети Cloudflare.

Если вас интересует работа над инфраструктурными проектами глобального масштаба, мы нанимаем сотрудников www.cloudflare.com/careers/jobs

Несколько месяцев назад Cloudflare объявила о переходе на FL2, нашу переработанную на Rust версию основного уровня обработки запросов Cloudflare. Этот переход ускоряет нашу способность помогать создавать лучший Интернет для всех. Благодаря миграции в программном стеке, Cloudflare обновила конструкцию серверного оборудования, улучшив его возможности и повысив эффективность для удовлетворения меняющихся потребностей нашей сети и программного обеспечения. Серверы 13-го поколения оснащены 192-ядерным процессором AMD EPYC Turin 9965, 768 ГБ оперативной памяти DDR5-6400, 24 ТБ хранилища PCIe 5.0 NVMe и двумя сетевыми картами с портами 100 Гбит/с.

13-е поколение предлагает:

• До 2 раз более высокая пропускная способность по сравнению с Gen 12 при сохранении уровня задержки в пределах SLA.
• Повышение производительности на ватт до 50%, что снижает затраты на расширение центров обработки данных.
• Увеличение пропускной способности на стойку до 60% при сохранении постоянного энергопотребления стойки.
• Вдвое больший объем памяти, в 1,5 раза больший объем хранилища, в 4 раза большая пропускная способность сети.
• В дополнение к шифрованию памяти, добавлена ​​поддержка аппаратного шифрования PCIe.
• Улучшена поддержка мощных, требующих интенсивного теплоотвода ускорителей PCIe, устанавливаемых без доработок.

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





Процессор


На этапе проектирования мы протестировали несколько процессоров AMD EPYC™ 5-го поколения, получивших кодовое название Turin, в аппаратной лаборатории Cloudflare: AMD Turin 9755, AMD Turin 9845 и AMD Turin 9965. В таблице ниже приведены различия в характеристиках кандидатов для серверов 13-го поколения по сравнению с AMD Genoa-X 9684X, используемым в наших серверах 12-го поколения. Следует отметить, что все три кандидата предлагают увеличение количества ядер, но с меньшим объемом кэша L3 на ядро. Однако, благодаря переходу на FL2, новые рабочие нагрузки менее зависимы от кэша L3 и хорошо масштабируются с увеличением количества ядер, обеспечивая увеличение пропускной способности до 100%.

Три представленных процессора предназначены для разных сценариев использования: AMD Turin 9755 предлагает превосходную производительность на ядро, AMD Turin 9965 жертвует производительностью на ядро ​​ради энергоэффективности, а AMD Turin 9845 жертвует количеством ядер ради меньшего энергопотребления сокета. Мы протестировали три процессора в производственной среде.



Почему именно AMD Turin 9965?
Во-первых, FL2 положила конец проблеме нехватки кэша L3.

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

Некоторые могут заметить, что у 9965 всего 2 МБ кэша L3 на ядро, что на 83,3% меньше, чем 12 МБ на ядро ​​у Genoa-X 9684X 12-го поколения. Зачем отказываться от того самого преимущества в кэше, которое дало Gen 12 его превосходство? Ответ кроется в том, как эволюционировали наши рабочие нагрузки.

Cloudflare перешла с FL1 на FL2, полностью переписав свой слой обработки запросов на Rust. Благодаря новому программному стеку конвейер обработки запросов Cloudflare стал значительно менее зависимым от большого кэша L3. Нагрузки FL2 масштабируются почти линейно с количеством ядер, а 192 ядра 9965 обеспечивают двукратное увеличение количества аппаратных потоков по сравнению с Gen 12.

Во-вторых, производительность на единицу общей стоимости владения (TCO). В ходе производственной оценки 192 ядра 9965 показали наибольшее суммарное количество запросов в секунду среди трех кандидатов, а его производительность на ватт благоприятно масштабировалась при TDP 500 Вт, обеспечивая превосходную общую стоимость владения на уровне стойки.



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

Наконец, они обладают обратной совместимостью. Архитектура процессоров AMD поддерживает память DDR5-6400, PCIe Gen 5.0 и CXL 2.0 Type 3 во всех моделях. AMD Turin 9965 имеет наибольшее количество высокопроизводительных ядер на сокет в отрасли, что максимизирует вычислительную плотность на сокет, поддерживая конкурентоспособность и актуальность платформы на долгие годы. Переход с AMD Genoa-X 9684X на AMD Turin 9965 обеспечивает более длительную поддержку безопасности от AMD, продлевая срок службы серверов Gen 13 до того, как они устареют и потребуют обновления.

Память

Поскольку процессор AMD Turin имеет вдвое больше ядер, чем предыдущее поколение, ему требуется больше памяти, как по объему, так и по пропускной способности, для обеспечения увеличения производительности.

Максимальная пропускная способность при использовании 12 каналов.
Выбранный процессор AMD EPYC 9965 поддерживает двенадцать каналов памяти, и для 13-го поколения мы устанавливаем модули во все из них. Мы выбрали 64 ГБ памяти DDR5-6400 ECC RDIMM в конфигурации «один модуль на канал» (1DPC).

Эта конфигурация обеспечивает пиковую пропускную способность памяти 614 ГБ/с на сокет, что на 33,3% больше по сравнению с нашей серверной платформой 12-го поколения. Используя все 12 каналов, мы гарантируем, что процессор никогда не будет испытывать «нехватку» данных, даже при самых ресурсоемких параллельных нагрузках.

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

Оптимальный объем памяти — 4 ГБ на ядро.
Наши серверы 12-го поколения имеют конфигурацию с 4 ГБ оперативной памяти на ядро. Мы пересмотрели это решение при проектировании серверов 13-го поколения.
Cloudflare ежемесячно запускает множество новых продуктов и услуг, и каждый новый продукт или услуга требует всё большего объёма памяти. Со временем это приводит к накоплению объёма памяти, что может стать проблемой нехватки памяти, если объём памяти не будет рассчитан должным образом.
Первоначально предполагалось соотношение памяти к ядру от 4 до 6 ГБ на ядро. При наличии 192 ядер на AMD Turin 9965 это соответствует диапазону от 768 ГБ до 1152 ГБ. Следует отметить, что при больших объемах шаг изменения емкости модуля DIMM обычно составляет 16 ГБ. При 12 каналах в конфигурации 1DPC доступны варианты 12x 48 ГБ (576 ГБ), 12x 64 ГБ (768 ГБ) или 12x 96 ГБ (1152 ГБ).

• 12 x 48 ГБ = 576 ГБ, или 1,5 ГБ на поток. Объем памяти в этой конфигурации слишком мал; это приведет к нехватке памяти для ресурсоемких задач и нарушению нижнего предела.
• 12 x 96 ГБ = 1152 ГБ, или 3,0 ГБ/поток. Это означает увеличение емкости на ядро ​​на 50%, а также приведет к увеличению энергопотребления и существенному росту стоимости, особенно в нынешних рыночных условиях, когда цены на память в 10 раз выше, чем год назад.
• 12 x 64 ГБ = 768 ГБ, или 2,0 ГБ/поток (4 ГБ/ядро). Эта конфигурация соответствует нашему соотношению памяти к ядрам в Gen 12 и представляет собой двукратное увеличение объема памяти на сервер. Сохранение объема памяти на уровне 4 ГБ на ядро ​​обеспечивает достаточную емкость для рабочих нагрузок, масштабируемых с увеличением количества ядер, таких как наша основная рабочая нагрузка, FL, и обеспечивает достаточный запас памяти для будущего роста без избыточного выделения ресурсов.

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

Решение: 12 модулей по 64 ГБ, что в сумме составляет 768 ГБ. Это сохраняет проверенное соотношение 4 ГБ/ядро, обеспечивает двукратное увеличение общей емкости по сравнению с 12-м поколением и остается в оптимальном ценовом диапазоне модулей DIMM.

Повышение эффективности за счет двойного ранга
В Gen 12 мы продемонстрировали, что двухранговые модули DIMM обеспечивают заметно более высокую пропускную способность памяти, чем одноранговые модули, с преимуществами до 17,8% при соотношении чтения и записи 1:1. Двухранговые модули DIMM быстрее, потому что они позволяют контроллеру памяти обращаться к одному рангу, пока другой обновляется. Этот же принцип применим и здесь.

Наши требования также предусматривают пропускную способность памяти примерно в 1 ГБ/с на каждый аппаратный поток. При пиковой пропускной способности в 614 ГБ/с на 384 потоках мы обеспечиваем 1,6 ГБ/с на поток, что значительно превышает минимальный показатель. Анализ производственных условий показал, что рабочие нагрузки Cloudflare не ограничены пропускной способностью памяти, поэтому мы сохраняем этот запас как резерв для будущего роста нагрузки.

Выбрав модули памяти DDR5 RDIMM 2Rx4 с максимальной поддерживаемой частотой 6400 МТ/с, мы обеспечиваем минимальную задержку и наилучшую производительность в конфигурации памяти нашей платформы Gen 13.

Хранилище


В 12-м поколении наша архитектура хранения данных претерпела трансформацию, когда мы перешли от M.2 к EDSFF E1.S. В 13-м поколении мы увеличиваем емкость хранения и пропускную способность, чтобы соответствовать новейшим технологиям. Мы также добавили фронтальный отсек для накопителей, что обеспечивает гибкость и позволяет устанавливать до 10 накопителей U.2, чтобы идти в ногу с ростом продаж продуктов хранения Cloudflare.

Переход на PCIe 5.0
В Gen 13 используются накопители NVMe PCIe Gen 5.0. Хотя Gen 4.0 хорошо себя зарекомендовал, переход на Gen 5.0 гарантирует, что наша подсистема хранения данных сможет передавать данные с меньшей задержкой и справляться с возросшими требованиями к пропускной способности хранилища, предъявляемыми новым процессором.

от 16 ТБ до 24 ТБ
Помимо увеличения скорости, мы физически расширяем массив с двух до трех NVMe-накопителей. Наша серверная платформа 12-го поколения была разработана с четырьмя слотами для накопителей E1.S, но только два из них были заняты 8-терабайтными дисками. Серверная платформа 13-го поколения использует ту же конструкцию с четырьмя доступными слотами для накопителей E1.S, но три из них заняты 8-терабайтными дисками. Зачем добавлять третий диск? Это увеличивает емкость хранилища на сервер с 16 ТБ до 24 ТБ, обеспечивая расширение нашей общей емкости хранилища для поддержания и улучшения производительности кэша CDN. Это также поддерживает прогнозируемый рост для Durable Objects, Containers и сервисов Quicksilver.

Передний отсек для дисков для установки дополнительных накопителей.
Для Gen 13 шасси спроектировано с передним отсеком для накопителей, который может поддерживать до десяти накопителей U.2 PCIe Gen 5.0 NVMe. Передний отсек для накопителей позволяет Cloudflare использовать одно и то же шасси на вычислительных и хранилищных платформах, а также обеспечивает гибкость при необходимости преобразования вычислительной версии в версию для хранения данных.

Выносливость и надежность
Мы проектируем наши серверы с расчетом на 5-летний срок службы и требуем от накопителей ресурс в 1 операцию записи в день (DWPD) на протяжении всего срока службы сервера.

Как Samsung PM9D3a, так и Micron 7600 Pro соответствуют спецификации 1 DWPD с аппаратным резервированием (OP) приблизительно на 7%. Если в будущем потребуется более высокая ресурсоемкость, у нас есть возможность зарезервировать дополнительную пользовательскую мощность для увеличения эффективного OP.

Соответствие стандартам NVMe 2.0 и OCP NVMe 2.0
Как Samsung PM9D3a, так и Micron 7600 используют спецификацию NVMe 2.0 (вместо NVMe 1.4) и спецификацию OCP NVMe Cloud SSD Specification 2.0. Ключевые улучшения включают в себя зонированные пространства имен (ZNS) для более эффективного управления усилением записи, команду Simple Copy Command для перемещения данных внутри устройства без пересечения шины PCIe, а также улучшенную блокировку команд и функций для более жесткого контроля безопасности. Спецификация OCP 2.0 также добавляет расширенные возможности телеметрии и отладки, специально разработанные для работы в центрах обработки данных, что соответствует нашему акценту на управляемость всего парка устройств.

Тепловой КПД
Накопители по-прежнему будут выполнены в форм-факторе E1.S толщиной 15 мм. Большая площадь поверхности корпуса необходима для охлаждения новых контроллеров Gen 5.0, которые могут потреблять до 25 Вт при длительной интенсивной работе. Корпус высотой 2U обеспечивает достаточный воздушный поток над накопителями E1.S, а также отсеками для накопителей U.2, — преимущество, подтвержденное нами в Gen 12, когда мы приняли решение перейти от форм-фактора 1U к 2U.

Сеть


Более восьми лет два порта 25 Гбит/с Ethernet составляли основу нашего парка оборудования. С 2018 года они хорошо нам служили, но по мере совершенствования процессоров для обработки большего количества запросов и масштабируемости нашей продукции мы официально достигли предела своих возможностей. Для 13-го поколения мы вчетверо увеличиваем пропускную способность каждого порта.

Почему именно 100 Гбит/с Ethernet и почему именно сейчас?
Пропускная способность сетевых интерфейсных карт (NIC) должна соответствовать росту вычислительной производительности. При наличии 192 современных ядер наши каналы 25 Гбит/с Ethernet станут ощутимым узким местом. Данные, полученные в ходе недельной эксплуатации наших центров обработки данных по всему миру, показали, что на наших серверах 12-го поколения пропускная способность P95 на порт стабильно превышает 50% от доступной пропускной способности. Поскольку пропускная способность на каждом сервере 13-го поколения удваивается, мы рискуем перегрузить пропускную способность сетевых интерфейсных карт.



Решение перейти на 100 GbE вместо 50 GbE было продиктовано экономическими соображениями отрасли: объемы производства трансиверов 50 GbE остаются низкими, что делает их невыгодным вариантом для цепочки поставок. Два порта 100 GbE также обеспечивают суммарную пропускную способность 200 Гбит/с на сервер, что гарантирует готовность к росту трафика в ближайшие несколько лет.

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

Обе сетевые карты соответствуют форм-фактору OCP 3.0 SFF/TSFF со встроенной защелкой, что обеспечивает унифицированность шасси с Gen 12 и гарантирует, что полевым специалистам не потребуются новые инструменты или обучение для замены.

Распределение PCIe
Слот OCP 3.0 NIC на материнской плате имеет выделенные линии PCIe 4.0 x16, обеспечивающие двунаправленную пропускную способность 256 Гбит/с, чего более чем достаточно для двух интерфейсов 100 Гбит/с (суммарная скорость 200 Гбит/с) с запасом.

Управление


Мы сохраняем архитектурный сдвиг, введенный в Gen 12, заключающийся в разделении компонентов управления и безопасности от материнской платы на модуль Project Argus Data Center Secure Control Module 2.0.


Непрерывность работы с DC-SCM 2.0
Мы продолжаем развивать стандарт Data Center Secure Control Module 2.0 (DC-SCM 2.0). Разделяя функции управления и безопасности от материнской платы, мы гарантируем, что «мозг» системы безопасности сервера останется модульным и защищенным.

В модуле DC-SCM размещены наши наиболее важные компоненты:

• Базовая система ввода-вывода (BIOS)
• Контроллер управления материнской платой (BMC)
• Аппаратный корень доверия (HRoT) и TPM (Infineon SLB 9672)
• Два флэш-чипа BMC/BIOS для резервирования

Почему мы продолжаем работу над DC-SCM 2.0
Решение сохранить эту архитектуру для 13-го поколения обусловлено доказанным повышением уровня безопасности, которое мы наблюдали в предыдущем поколении. Перенеся эти функции в отдельный модуль, мы сохраняем:

• Быстрое восстановление: Двойное резервирование образов позволяет практически мгновенно восстановить прошивку BIOS/UEFI и BMC в случае обнаружения случайного повреждения или вредоносного обновления.
• Физическая прочность: В шасси 13-го поколения механизм обнаружения вторжений также смещен дальше от плоского края шасси, что затрудняет физический перехват.
• Шифрование PCIe: В дополнение к технологии TSME (Transparent Secure Memory Encryption) для шифрования данных между процессором и памятью, которая была включена еще в наших платформах 10-го поколения, процессор AMD Turin 9965 для 13-го поколения расширяет шифрование на трафик PCIe, что гарантирует защиту данных при передаче по каждой шине в системе.
• Операционная согласованность: Использование стека управления Gen 12 означает, что наши процедуры аудита безопасности, развертывания, предоставления ресурсов и операционных стандартов остаются полностью совместимыми.

Power


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

Переход к мощности 1300 Вт
В то время как наши узлы 12-го поколения комфортно работали с резервным источником питания 800 Вт 80 PLUS Titanium CRPS (Common Redundant Power Supply), спецификация 13-го поколения требует более мощного источника питания. Мы выбрали резервный источник питания 80 PLUS Titanium CRPS мощностью 1300 Вт.

Потребляемая мощность процессоров Gen 13 в типичном режиме работы выросла до 850 Вт, что на 250 Вт больше, чем 600 Вт у Gen 12. Основными факторами являются процессор с TDP 500 Вт (вместо 400 Вт), удвоение объема памяти и дополнительный NVMe-накопитель.

Почему 1300 Вт вместо 1000 Вт? В существующей экосистеме блоков питания отсутствуют жизнеспособные высокоэффективные варианты мощностью 1000 Вт. Для обеспечения надежности цепочки поставок мы перешли к следующему отраслевому стандарту — 1300 Вт.

Регламент ЕС Lot 9 требует, чтобы серверы, развертываемые в Европейском Союзе, имели блоки питания с КПД при нагрузке 10%, 20%, 50% и 100%, равным или превышающим пороговое значение, указанное в регламенте. Это пороговое значение соответствует требованиям программы сертификации блоков питания 80 PLUS, предусматривающим использование блоков питания титанового класса. Для Gen 13 мы выбрали блоки питания титанового класса, чтобы обеспечить полное соответствие требованиям EU Lot 9 и гарантировать возможность развертывания серверов в наших европейских центрах обработки данных и за их пределами.

Тепловая конструкция: 2U снова приносит свои плоды.
Принятый нами в 12-м поколении форм-фактор 2U1N продолжает приносить свои плоды. В 13-м поколении используются 5 80-мм вентиляторов (против 4 в 12-м поколении) для компенсации возросшей тепловой нагрузки от процессора мощностью 500 Вт. Больший объем вентиляторов в сочетании с характеристиками воздушного потока в 2U-корпусе означает, что вентиляторы работают значительно ниже максимального рабочего цикла при типичных температурах окружающей среды, поддерживая энергопотребление вентиляторов в диапазоне < 50 Вт на вентилятор.

Поддержка ускорителя без дополнительных настроек


Сохранение модульности нашего парка серверов является ключевым требованием к их проектированию. Это требование позволило Cloudflare быстро модернизировать и развернуть графические процессоры по всему миру более чем в 100 городах в 2024 году. В 13-м поколении мы продолжаем поддерживать высокопроизводительные дополнительные карты PCIe.

В 13-м поколении обновлена ​​компоновка корпуса в форм-факторе 2U, адаптированная для поддержки более высоких требований к питанию и теплоотводу. Если в 12-м поколении использовалась только одна двухслотовая видеокарта, то архитектура 13-го поколения теперь поддерживает две двухслотовые карты PCIe.

Стартовая площадка для масштабирования Cloudflare и выведения его на новый уровень.
Каждое поколение серверов Cloudflare — это попытка сбалансировать противоречащие друг другу ограничения: производительность против энергопотребления, емкость против стоимости, гибкость против простоты. Серверы 13-го поколения имеют вдвое больше ядер, вдвое больший объем памяти, вчетверо большую пропускную способность сети, в 1,5 раза больший объем хранилища и обеспечивают перспективность для развертывания в ускоренном режиме — и все это при одновременном снижении общей стоимости владения и сохранении надежного набора функций управления и уровня безопасности, которые требуются нашему глобальному парку серверов.

Серверы 13-го поколения полностью сертифицированы и будут развернуты для обработки миллионов запросов в глобальной сети Cloudflare в более чем 330 городах. Как всегда, стремление Cloudflare к максимально эффективному предоставлению услуг в Интернете на этом не заканчивается. По мере начала развертывания 13-го поколения мы планируем архитектуру для 14-го поколения.

Если вас вдохновляет возможность внести свой вклад в создание лучшего интернета, присоединяйтесь к нам. Мы набираем сотрудников www.cloudflare.com/careers/jobs/

На этой неделе Cloudflare исполняется 15 лет. Мы любим отмечать свой день рождения, анонсируя новые продукты и функции, которые вносят вклад в развитие Интернета, и на этой неделе мы будем делать это активно. Но в этот раз мы также задумались о том, что изменилось в Интернете за последние 15 лет, а что — нет.
www.youtube.com/watch?v=XeKWeBw1R5A

В некоторых аспектах наблюдается явный прогресс: когда мы запустили систему в 2010 году, зашифровано было менее 10% интернета, а сегодня зашифровано уже более 95%. Мы гордимся своей ролью в достижении этого.




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

Бизнес-модель Интернета
Однако другие вещи остаются удивительно стабильными: базовая бизнес-модель интернета последние 15 лет остаётся неизменной: создавать интересный контент, найти способ привлечь внимание аудитории и затем генерировать ценность из полученного трафика. Будь то реклама, подписки, продажа товаров или просто осознание того, что кто-то потребляет то, что вы создали, генерация трафика стала двигателем интернета, каким мы его знаем сегодня.

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

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

Трафик ≠ ценность
Но та же система вознаграждения, основанная на трафике, также создала множество проблем, на которые мы сетуем по поводу текущего состояния интернета. Трафик всегда был несовершенным показателем ценности. За последние 15 лет мы наблюдали, как интернет всё больше движим раздражающими кликбейтами или опасными агрэбейтами. Целые медиаорганизации выстраивали свой бизнес, декларируя цель — писать заголовки, вызывающие максимальный выброс кортизола, потому что именно это генерирует максимальный трафик.

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

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

От поиска к ответам
Что изменилось? Главной системой поиска информации в интернете последние 15 лет были поисковые системы. Они собирали контент, создавали индекс, а затем предоставляли пользователям карту сокровищ, следуя которой, те генерировали трафик. Создатели контента были рады позволить поисковым системам собирать свой контент, поскольку их было ограниченное количество, поэтому затраты на инфраструктуру были относительно низкими, и, что ещё важнее, поисковые системы давали сайтам что-то в виде трафика — исторической валюты интернета, — который возвращался на сайты.

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

Не нужно далеко ходить, чтобы увидеть, как всё стремительно меняется на наших глазах. ChatGPT, Claude от Anthropic и другие стартапы в области ИИ — это не поисковые системы, а системы ответов. Даже Google, столп поиска, всё чаще предлагает «Обзоры ИИ» вместо десяти синих ссылок. Мы часто обращаемся к научно-фантастическим фильмам, чтобы заглянуть в наше вероятное будущее. В них услужливый интеллектуальный робот не отвечал на вопросы словами: «Вот ссылки, по которым вы можете перейти, чтобы, возможно, найти то, что ищете». Нравится вам это или нет, будущее всё больше будет состоять из ответов, а не из поисков.

Кратковременная боль
В краткосрочной перспективе это будет крайне болезненно для некоторых отраслей, основанных на монетизации трафика. И это уже происходит. Хотя электронная коммерция и приложения для социальных сетей пока не столкнулись со значительным падением трафика из-за перехода всего мира на Answer Engines, в медиакомпаниях это произошло. В чём разница? Что ж, в первом случае вам всё равно придётся покупать то, что рекомендует Answer Engine, и пока мы по-прежнему ценим общение с другими людьми.

Но для медиакомпаний, если Answer Engine в большинстве случаев даёт краткое изложение того, что вы ищете, читать статью не обязательно. И потеря трафика для медиакомпаний уже существенная. И это касается не только традиционных СМИ. Исследовательские группы инвестиционных банков, отраслевые аналитики, крупные консалтинговые компании — все они отмечают значительное снижение числа пользователей, находящих их контент, потому что мы всё чаще получаем ответы, а не ищем карты сокровищ.

Некоторые утверждают, что эти поисковые системы или агенты действуют от имени людей. Конечно, ну и что? Без изменений они всё равно будут убивать бизнес создателей контента. Если вы попросите своего агента обобщить информацию из двадцати разных источников новостей, но сами ни разу не посетите ни один из них, вы всё равно подорвёте бизнес-модель этих источников. Агенты не кликают по рекламе. А если этим агентам разрешено агрегировать информацию от имени нескольких пользователей, это ещё большая проблема, потому что тогда теряется и доход от подписки. Зачем подписываться на Wall Street Journal, New York Times, Financial Times или Washington Post, если мой агент может бесплатно пользоваться услугами другого пользователя, который это делает?

Если вы не считаете, что создатели контента должны работать бесплатно или что они каким-то образом больше не нужны (и то, и другое наивно), что-то нужно менять. Визит агента — это не то же самое, что визит человека, и поэтому правила должны быть другими. Если ничего не изменится, резкое падение трафика в медиаэкосистеме разрушит бизнес-модель, которая создала тот богатый контентом Интернет, которым мы пользуемся сегодня.

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

Поощрение лучшего контента
Но есть основания для оптимизма. Контент — это топливо, питающее любую систему искусственного интеллекта, и компании, управляющие этими системами, понимают, что в конечном итоге им необходимо финансово поддерживать экосистему. Поэтому, похоже, мы находимся на пороге новой, более совершенной и, возможно, более здоровой модели интернет-бизнеса. Поскольку создатели контента используют инструменты, подобные тем, что предоставляет Cloudflare, чтобы ограничить использование их контента роботами искусственного интеллекта без компенсации, мы уже наблюдаем формирование рынка и заключение более выгодных сделок между компаниями, работающими с ИИ, и контент-провайдерами.
blog.cloudflare.com/introducing-ai-crawl-control/

Самое интересное, какие контент-компании получают самые выгодные предложения. Это не авторы агитационных заголовков. Это не новостные организации, пишущие очередную версию политических событий. Это не спам-фермы, полные чепухи. Именно Reddit и другие необычные сайты лучше всего напоминают нам о старом Интернете. Те из вас, кто достаточно стар, вспомните Интернет не последних 15 лет, а последних 35. Мы потеряли часть того, что делало ранний Интернет великим, но есть признаки того, что у нас, наконец, могут появиться стимулы вернуть его.

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

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

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

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

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

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

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

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

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

Поддержка экосистемы
Мы не справимся в одиночку и не планируем пытаться. Наша миссия — не «сделать Интернет лучше», а « помочь сделать Интернет лучше». Решения, разработанные для развития этого рынка, должны быть открытыми, совместимыми, стандартизированными и доступными для многих организаций. Мы предпримем несколько обнадеживающих шагов в этом направлении, объявив о партнёрствах и сотрудничестве на этой неделе. И мы гордимся тем, что являемся лидером в этой области.

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



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

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

Мы обращаемся к вам, чтобы сообщить вам о предстоящем изменении, которое повлияет на совместимость устройств с сертификатами Let's Encrypt, выпущенными после 15 мая 2024 г. Мы обращаемся к вам, поскольку мы определили, что вы в настоящее время используете сертификаты Let's Encrypt через Universal SSL, Advanced. Диспетчер сертификатов, специальные сертификаты или SSL для SaaS. Мы рекомендуем вам ознакомиться с изменением Let's Encrypt и заранее внести все необходимые изменения.

Обзор изменений
Let's Encrypt выдает сертификаты через две цепочки: корневую цепочку ISRG X1 и корневую цепочку ISRG X1, перекрестно подписанную корневым центром сертификации DST X3 компании IdenTrust. Цепочка с перекрестной подписью позволила сертификатам Let's Encrypt завоевать широкое доверие, в то время как чистая цепочка за последние 3 года обеспечила совместимость с различными устройствами, в результате чего количество Android-устройств, доверяющих ISRG Root X1, увеличилось с 66% до 93,9%.

Let's Encrypt объявила, что срок действия цепочки с перекрестной подписью истекает 30 сентября 2024 года. В результате Cloudflare прекратит выдачу сертификатов из цепочки центров сертификации с перекрестной подписью 15 мая 2024 года.

Влияние
Истечение срока действия цепочки с перекрестной подписью в первую очередь повлияет на старые устройства (например, Android 7.0 и более ранние версии) и системы, которые полагаются исключительно на цепочку с перекрестной подписью и не имеют цепочки ISRG Root X1 в своем хранилище доверенных сертификатов. Это изменение может привести к сбоям проверки сертификатов на этих устройствах, что потенциально может привести к появлению предупреждающих сообщений или проблемам с доступом для пользователей, посещающих ваш веб-сайт.

Влияние на сертификаты, выданные через Universal SSL, Advanced Certificate Manager или SSL для SaaS:

• Чтобы подготовиться к истечению срока действия ЦС, после 15 мая Cloudflare больше не будет выдавать сертификаты из цепочки с перекрестной подписью. Сертификаты, выданные до 15 мая, будут по-прежнему выдаваться клиентам с цепочкой с перекрестной подписью. Сертификаты, выпущенные 15 мая или позже, будут использовать цепочку ISRG Root X1. Кроме того, это изменение влияет только на сертификаты RSA. Это не влияет на сертификаты ECDSA, выданные через Let's Encrypt. Сертификаты ECDSA сохранят тот же уровень совместимости, который они имеют сегодня.

Влияние на сертификаты, загруженные через пользовательские сертификаты:

• Сертификаты, загруженные в Cloudflare, объединяются в цепочку сертификатов, которую Cloudflare считает наиболее совместимой и эффективной. После 15 мая 2024 года все сертификаты Let's Encrypt, загруженные в Cloudflare, будут объединены с цепочкой ISRG Root X1 вместо цепочки с перекрестной подписью. Сертификаты, загруженные до 15 мая, будут продолжать использовать цепочку с перекрестной подписью до тех пор, пока этот сертификат не будет продлен.

Важные даты
15 мая 2024 г.: Cloudflare прекратит выдачу сертификатов из цепочки центров сертификации с перекрестной подписью. Кроме того, пользовательские сертификаты Let's Encrypt, загруженные после этой даты, будут связаны с цепочкой ISRG X1 вместо цепочки с перекрестной подписью.
30 сентября 2024 г. Срок действия цепочки центров сертификации с перекрестной подписью истечет.

Рекомендации:

• Чтобы уменьшить влияние этого изменения, мы рекомендуем предпринять следующие шаги:
• Измените центры сертификации. Если ваши клиенты отправляют запросы к вашему приложению с устаревших устройств и вы ожидаете, что это изменение повлияет на них, мы рекомендуем использовать другой центр сертификации или загрузить сертификат из выбранного вами центра сертификации.
• Мониторинг. После внедрения изменения мы рекомендуем отслеживать ваши каналы поддержки на предмет любых запросов, связанных с предупреждениями о сертификатах или проблемами доступа.
• Обновите хранилище доверенных сертификатов. Если вы контролируете клиентов, подключающихся к вашему приложению, мы рекомендуем обновить хранилище доверенных сертификатов, включив в него цепочку ISRG Root X1, чтобы предотвратить влияние.

Мы пишем, чтобы сообщить вам, что в соответствии с решением об адекватности, принятым Европейской комиссией в отношении передачи персональных данных в Соединенные Штаты, Cloudflare прошла сертификацию в соответствии с Рамочной программой конфиденциальности данных ЕС-США, Рамочной программой конфиденциальности данных между Швейцарией и США. и расширение Соединенного Королевства (Великобритании) к Соглашению о конфиденциальности данных ЕС-США (вместе именуемому «DPF»). В результате, если каждая структура будет признана адекватной, Cloudflare теперь будет полагаться на DPF как на юридический механизм передачи данных из ЕС, Швейцарии и Великобритании.

Как указано в нашем Дополнении об обработке данных, мы продолжим полагаться на Стандартные договорные условия ЕС (и Дополнение Великобритании) при переводах из ЕС, Швейцарии и Великобритании в другие третьи страны, которые не подлежат определению адекватности.

Мы также обновили нашу Политику конфиденциальности, включив в нее подробную информацию о нашей самостоятельной сертификации в DPF, в частности, о механизмах рассмотрения жалоб и надзоре, осуществляемых Федеральной торговой комиссией США.

Что мне нужно делать?
Если вы являетесь клиентом самообслуживания или корпоративным клиентом по нашему стандартному контракту (что означает отсутствие изменений в Дополнении об обработке данных), то никаких действий не требуется. Мы просим вас ознакомиться с нашим обновленным DPA, который включен посредством ссылки в наше Соглашение о подписке на самообслуживание и Соглашение о корпоративной подписке. Мы обновили наше Дополнение об обработке данных, чтобы отразить, что любая передача персональных данных за пределы Европейской экономической зоны, Великобритании или Швейцарии будет осуществляться в соответствии с Рамочным соглашением о конфиденциальности данных ЕС-США, расширением британско-американского соглашения о данных ЕС-США. Структура конфиденциальности и Соглашение о конфиденциальности данных между Швейцарией и США соответственно, при условии, что эти структуры признаны участвующими юрисдикциями в качестве адекватных правовых механизмов для передачи данных из ЕС, Великобритании и Швейцарии в США. Для переводов из ЕЭЗ, Великобритании и Швейцарии в любую другую страну, в которой нет действующего соглашения об адекватности, DPA Cloudflare продолжит включать соответствующие стандартные договорные положения.
www.cloudflare.com/terms/

Если у вас есть договорное соглашение: пожалуйста, свяжитесь с вашими менеджерами по работе с клиентами, если вы хотите обновить свое соглашение с Cloudflare.

Вам нужно больше рекомендаций?
Если у вас есть какие-либо вопросы, обратитесь к Cloudflare Trust Hub для получения дополнительной информации. www.cloudflare.com/trust-hub/gdpr/

Команда Cloudflare по вопросам конфиденциальности

Cloudflare поднимает цены впервые за последние 12 лет. Начиная с 15 января 2023 года с новых регистраций будет взиматься плата в размере 25 долларов США в месяц для нашего плана Pro (ранее 20 долларов США в месяц) и 250 долларов США в месяц для нашего бизнес-плана (больше 200 долларов США в месяц). Любые платные клиенты, которые зарегистрируются до 15 января 2023 года, включая всех платящих клиентов, которые зарегистрировались в любой момент в течение последних 12 лет, будут использовать старую месячную цену до 14 мая 2023 года.

Мы также представляем вариант оплаты ежегодно, а не ежемесячно, на который, как мы надеемся, перейдет большинство клиентов. Годовые планы доступны сегодня со скидкой от новой месячной ставки до 240 долларов в год для плана Pro (эквивалент 20 долларов в месяц, экономия 60 долларов в год) и 2400 долларов в год для бизнес-плана (эквивалент 200 долларов в месяц, экономия 600 долларов в год). Другими словами, если вы решите платить за Cloudflare ежегодно, вы можете зафиксировать наши старые месячные цены.

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

История Cloudflare
Cloudflare был запущен 27 сентября 2010 года. В то время у нас было два плана: один бесплатный план, который был бесплатным, и план Pro, который стоил 20 долларов в месяц. Наша сеть на тот момент состояла из «четырех с половиной» дата-центров: Чикаго, Иллинойс; Эшберн, Вирджиния; Сан-Хосе, Калифорния; Амстердам, Нидерланды; и Токио, Япония. Маршрутизация в Токио была настолько нестабильной, что мы отключали ее на полдня, чтобы не испортить маршрутизацию по всему миру. Самая большая разница в первые пару лет между нашими бесплатными и профессиональными планами заключалась в том, что только последний включал поддержку HTTPS.


В июне 2012 года мы представили наш бизнес-план за 200 долларов в месяц и корпоративный план, адаптированный для наших крупнейших клиентов. К тому времени мы не только добились надежной работы в Токио, но и добавили еще 18 центров обработки данных по всему миру, в общей сложности 23. В наш бизнес-план в качестве основного преимущества было добавлено смягчение последствий DDoS-атак, чего раньше мы боялись предлагать.


Перенесемся в сегодняшний день, и многое изменилось. Мы работаем более чем в 275 городах более чем в 100 странах мира. Мы включили поддержку HTTPS в наш бесплатный план с запуском Universal SSL в сентябре 2014 года. Мы включили неограниченную защиту от DDoS-атак в наш бесплатный план с запуском Unmetered DDoS Mitigation в сентябре 2017 года. Сегодня мы ежедневно останавливаем атаки для пользователей бесплатного плана. основе, что более чем в 10 раз превышает то, что было в заголовках новостей еще в 2013 году.


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


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

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

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

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

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

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

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

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

15 июня или после 2019 Cloudflare начнет собирать налог на добавленную стоимость («НДС») по продажам своих услуг клиентам на территории Российской Федерации в соответствии с требованиями новых российских правил НДС, вступившие в силу с 1 января 2019 г. В соответствии новые правила, Cloudflare обязано взимать налог НДС в размере 20%. Другими словами, 16,67% от счета представляет собой НДС.

Пример:

• Стоимость продукта: $ 100
• НДС цены: $ 120
• Сумма НДС: $ 20 ($ 100 * 20%)
• Ставка НДС: 16,67% ($ 20/120)

Вы получили это уведомление, потому что ваш счет подлежит новому НДС. Наши данные свидетельствуют о том, что ваша компания или ее руководство находится в России или услуги выполняются в России. Если ваша компания или управление больше не находятся в России или услуги не производятся в России, пожалуйста, обновите ваш профиль учетной записи, следуя инструкции, приведенные здесь с помощью учетной записи электронной почты, связанную с вашей учетной записью CloudFlare. Там, вы можете также указать свой номер НДС России, если вы хотите, чтобы ваш номер НДС указан в счете-фактуре.

Спасибо за ваше сотрудничество.