Scaleway Хостинг

www.scaleway.com/en/pricing/

Scaleway меняет поведение общедоступного IP-адреса с NAT-IP на маршрутизируемый IP-адрес.

Для обеспечения роста компания Scaleway решила внедрить высокодоступный NAT (преобразование сетевых адресов), чтобы обеспечить перемещение IP-адресов между физические машины с экземплярами, которым они были назначены.

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

Маршрутизируемые IP-адреса и IP-адреса NAT
Раньше при каждом развертывании экземпляра Scaleway ему назначался внутренний частный IP-адрес, а также общедоступный IP-адрес, который направлялся к нему через решение NAT (преобразование сетевых адресов) операторского уровня. Однако эта установка создала некоторые проблемы. Например, если гипервизор, на котором размещен экземпляр, был изменен, скажем, после процедуры остановки/запуска, частный IP-адрес также изменится, что может нарушить внутреннюю связь.

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

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

План миграции
Все продукты Scaleway перейдут с IP-адреса NAT на маршрутизируемый IP-адрес. Этот процесс миграции предполагает два сценария:

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

• Kapsule и Kosmos: клиенты смогут выполнить миграцию вручную во втором/третьем квартале 2024 года.
• Публичный шлюз: клиенты могут выполнить миграцию вручную с апреля по май 2024 года.
• Примеры: клиенты могут выполнить миграцию вручную до второго квартала 2024 года (руководство).

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

Примечание 2: убедитесь, что DHCP-клиент правильно настроен на вашем общедоступном сетевом интерфейсе (в большинстве случаев ens2 или eth0). Если во время миграции используются статические конфигурации сети, существует риск потери подключения к Интернету, поэтому вместо этого рекомендуется использовать DHCP. Прежде чем начать миграцию, необходимо обновить пакеты «scaleway-ecosystem» и «cloud-init» до последних версий. Пожалуйста, ознакомьтесь с разделом «Как безопасно перейти на IP Mobility» в документации к вашему продукту.

Автоматическая миграция
Scaleway выполнит миграцию управляемых продуктов на новый стек маршрутизируемых IP-адресов для всех существующих клиентов. График миграции будет сообщен как обычное плановое обслуживание в 2024 году. Автоматическая миграция будет полезна для следующих продуктов:

• Управляемые базы данных (RDB и Redis)
• Балансировщик нагрузки
• Публичный шлюз
• Веб хостинг
• Капсула и Космос
• Экземпляры

Париж, Франция – четверг, 29 февраля 2024 г. – Scaleway, европейский поставщик облачных услуг, с гордостью представляет линейку серверов RISC-V, еще раз подчеркивая свою приверженность инновациям и приверженность развитию технологий завтрашнего дня.

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

Запуск серверов RISC-V — это конкретное и прямое заявление Scaleway о стимулировании экосистемы, в которой технологический суверенитет открыт для всех, от самого низкого уровня и выше. Эта смелая, дальновидная инициатива на развивающемся рынке открывает новые перспективы для всех игроков

сказал Себастьен Люттренжер, директор по исследованиям и разработкам Scaleway.

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

Elastic Metal RV1 доступен для любого бюджета и оснащен процессором T-HEAD TH1520 SoC, 16 ГБ ОЗУ и 128 ГБ встроенной памяти по цене 15,99 евро в месяц. Архитектура RISC-V, хотя и новая и все еще оптимизируется, уже обеспечивает удивительно высокий уровень производительности благодаря своему современному и открытому дизайну. Таким образом, он уже представляет собой надежную альтернативу устоявшимся архитектурам, таким как x86 и ARM.

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

добавил Дэмиен Лукас, генеральный директор Scaleway.

Серверы EM-RV1 являются результатом многомесячных исследований и разработок в парижских лабораториях Scaleway. Каждый аспект их конструкции, от первых прототипов до корпуса, напечатанного на 3D-принтере, свидетельствует об итеративном, кустарном подходе к предоставлению вам ряда надежных серверов RISC-V, доступных в облаке, в кратчайшие сроки.

Чтобы получить дополнительную информацию о серверах Scaleway RISC-V и опробовать их прямо сейчас, посетите labs.scaleway.com/en/em-rv1/

Открытый исходный код делает LLM (большие языковые модели) доступными каждому. Доступно множество вариантов, особенно для вывода. Вы, наверное, слышали о библиотеке вывода Hugging Face, но есть еще OpenLLM, vLLM и многие другие.

Основная проблема, особенно если вы такая компания, как Mistral AI, создающая новые LLM, заключается в том, что архитектура вашего LLM должна поддерживаться всеми этими решениями. Им нужна возможность общаться с Hugging Face, NVIDIA, OpenLLM и так далее.

Вторая проблема — это стоимость, особенно стоимости инфраструктуры, которая вам понадобится для масштабирования развертывания LLM. Для этого у вас есть разные решения:

Выбор подходящих графических процессоров (ваш LLM должен им соответствовать)
Выбор подходящей техники:

• Квантование, которое предполагает уменьшение количества байтов, используемых переменными, поэтому вы можете разместить более крупные модели в меньших ограничениях памяти. Это компромисс между ними, поскольку это может повлиять на точность вашей модели и результаты ее производительности.
• Методы точной настройки, такие как точная настройка с эффективным использованием параметров ( PEFT ). С помощью методов PEFT вы можете значительно снизить затраты на вычисления и память, настроив лишь небольшое количество (дополнительных) параметров модели вместо всех параметров модели. Вы также можете комбинировать методы PEFT с квантованием.
• Затем вам нужно решить, будете ли вы размещать его самостоятельно; вы используете решение PaaS; или готовые к использованию конечные точки API, как это делает OpenAI.

Выбор правильного графического процессора


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

• H100 PCIe 5 — флагманский и самый мощный графический процессор NVIDIA. Он имеет интересные функции, такие как Transformer Engine, библиотека для ускорения моделей Transformer на графических процессорах NVIDIA, включая использование 8-битной точности с плавающей запятой (FP8) на графических процессорах Hopper и Ada Lovelace, чтобы обеспечить лучшую производительность при меньшем использовании памяти как при обучении, так и при выводе.. Это ускоряет обучение моделей Transformer, а это означает, что вы можете поместить в память вдвое больше переменных, в 8 бит вместо 16. Кроме того, библиотека NVIDIA помогает упростить эти изменения; плюс большой объем памяти и пропускная способность памяти являются ключевыми моментами, поскольку чем быстрее вы сможете загрузить свою память, тем быстрее будет работать ваш графический процессор.
• L4 PCIe 4 можно рассматривать как современного преемника NVIDIA T4, предназначенного для вывода, но прекрасно способного обучать меньшие модели LLM. Как и H100, он может работать с новыми форматами данных, такими как FP8. У него меньшая пропускная способность памяти, чем у H100, но это может создать некоторые узкие места в определенных случаях использования, например, при обработке больших пакетов изображений для обучения моделей компьютерного зрения. В этих случаях вы можете не увидеть значительного прироста производительности по сравнению, например, с предыдущей архитектурой Ampere. И в отличие от H100, у него есть возможности рендеринга видео и 3D, поэтому, если вы хотите создать синтетический набор данных для компьютерного зрения с помощью Blender, вы можете использовать этот графический процессор.
• L40S PCIe 4 — это то, что NVIDIA считает новым A100. Он имеет в два раза больше памяти, чем L4, но с большей пропускной способностью памяти и более высокой вычислительной производительностью. По словам NVIDIA, для генеративного ИИ, когда вы оптимизируете свой код с помощью FP8 и так далее, DGX с 8x A100 с 40 Гбит NVlink может работать так же хорошо, как 8 L40S PCIe 4 без NVLink, так что это мощный и интересный графический процессор.

Совет по использованию экземпляров графического процессора 1: образы Docker


При использовании графических процессоров используйте образы Docker и начните с бесплатных изображений NVIDIA. Таким образом, код становится переносимым, поэтому его можно запускать на вашем ноутбуке, на рабочей станции, на экземпляре графического процессора (независимо от облачного провайдера, поэтому без привязки) или на мощном кластере (либо с SLURM в качестве оркестратора, если вы находитесь в мире HPC/AI или Kubernetes, если вы больше в мире AI/MLOps).

NVIDIA регулярно обновляет эти образы, поэтому вы можете воспользоваться улучшениями производительности и исправлениями ошибок/безопасности. Производительность A100 сейчас значительно лучше, чем при запуске, и то же самое будет относиться к H100, L4 и так далее. Кроме того, существует множество функций, позволяющих экономить время, которые позволят вам быстрее создавать POC, например, фреймворк и такие инструменты, как NeMo, Riva и т. д., которые доступны через каталог NGC (выше).

Это также открывает возможность использовать лицензию AI Enterprise для поддерживаемых конфигураций оборудования (что обычно можно увидеть только в предложениях облачных провайдеров), что обеспечит вам поддержку в случае возникновения ошибок или проблем с производительностью и даже предложит помощь на основе данных NVIDIA. ученых, чтобы помочь вам отладить ваш код и получить максимальную производительность от всех этих программ. И, конечно же, вы можете выбрать свою любимую платформу: PyTorch, TensorFlow, Jupyter Lab и так далее.

Использование экземпляров Scaleway GPU
В ОС Scaleway GPU OS 12 мы уже предустановили Docker, поэтому вы можете использовать его прямо из коробки. Меня часто спрашивают, почему не предустановлены CUDA или Anaconda. Причина в том, что эти программы должны выполняться внутри контейнеров, поскольку не у всех пользователей одинаковые требования. Например, они могут использовать разные версии CUDA, cuDNN или Pytorch, поэтому это действительно зависит от требований пользователя. И использовать контейнер, созданный NVIDIA, проще, чем устанавливать и поддерживать среду искусственного интеллекта Python. Кроме того, это упрощает воспроизведение результатов в рамках ваших тренировок или экспериментов.

Итак, в основном вы делаете это:

## Connect to a GPU instance like H100-1-80G {connect-to-a-gpu-instance-like-h100-1-80g}

ssh root@<replace_with_instance_public_ip>

## Pull the Nvidia Pytorch docker image (or other image, with the software versions you need)

docker pull nvcr.io/nvidia/pytorch:24.01-py3
[...]

## Launch the Pytorch container {launch-the-pytorch-container}

docker run --rm -it --runtime=nvidia \
-p 8888:8888 \
-p 6006:6006 \
-v /root/my-data/:/workspace \
-v /scratch/:/workspace/scratch \
nvcr.io/nvidia/pytorch:24.01-py3

## You can work with Jupyter Lab, Pytorch etc… {you-can-work-with-jupyter-lab-pytorch-etc}

Совет по использованию экземпляров графического процессора 2: MIG


Одной из уникальных особенностей H100 является MIG, или многоэкземплярный графический процессор, который позволяет разделить графический процессор на семь частей. Это действительно полезно, если вы хотите оптимизировать свою рабочую нагрузку. Если у вас есть рабочие нагрузки, которые не полностью нагружают графические процессоры, это хороший способ иметь несколько рабочих нагрузок и максимизировать использование графического процессора. Он работает с автономными виртуальными машинами и очень легко работает в Kubernetes. Вы запрашиваете одну ссылку на графический процессор, соответствующую разделению, которое вы хотите использовать для одного ресурса графического процессора.

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

nvidia.com/gpu: '1' . по желаемому имени раздела MIG, например, nvidia.com/mig-3g.40gb: 1

docs.nvidia.com/datacenter/tesla/mig-user-guide/index.html

Совет по использованию экземпляров графического процессора 3: NVIDIA Transformer Engine и FP8


Все графические процессоры последнего поколения (доступные в новейшей архитектуре графических процессоров Nvidia, а именно Hopper и Ada Lovelace) используют NVIDIA Transformer Engine, библиотеку для ускорения моделей Transformer на графических процессорах NVIDIA, включая использование 8-битной точности с плавающей запятой (FP8) в Hopper. и графические процессоры Ada, чтобы обеспечить более высокую производительность при меньшем использовании памяти как при обучении, так и при выводе.

Что касается использования формата данных FP8, то на самом деле существует два типа FP8, которые предлагают компромисс между точностью и динамическим диапазоном чисел, которыми вы можете манипулировать (см. диаграмму). При обучении нейронных сетей можно использовать оба этих типа. Обычно активация и вес вперед требуют большей точности, поэтому тип данных E4M3 лучше всего использовать во время прямого прохода. Однако при обратном проходе градиенты, проходящие через сеть, обычно менее подвержены потере точности, но требуют более высокого динамического диапазона. Поэтому их лучше всего хранить в формате данных E5M2. Этим можно даже управлять автоматически с помощью формата «ГИБРИД» (подробнее здесь).

Transformer Engine предназначен не только для трансформеров. Поскольку он также может оптимизировать линейные операции, он может принести пользу другим архитектурам моделей, таким как компьютерное зрение (см. пример MNIST). Итак, по сути, вы устанавливаете пакет движка Transformer с помощью «pip», загружаете пакет и просто тестируете или заменяете определенный оперант. модули (из ваших любимых сред глубокого обучения) с помощью модуля, входящего в состав пакета Transformer engine (см. пример MNIST выше). Если вы хотите потратить немного времени на оптимизацию своего кода, используя Transformer Engine и формат FP8, вы можете это сделать. Здесь полезно оптимизировать, потому что вы будете использовать меньше памяти, использовать больше переменных и ускорять вывод и обучение. Поэтому обязательно оптимизируйте свой код!

Использование LLM в производстве: создание чат-бота с искусственным интеллектом с помощью RAG


Если вы хотите использовать LLM в производстве, возможно, вам захочется создать чат-бота, и для этого вам, вероятно, понадобится точно настроить модель ваших данных для вашего конкретного случая использования. С библиотекой Transformers Hugging Face это легко с точки зрения кода; но улучшить результаты может быть сложно, поскольку это требует множества проб и ошибок.

Другой метод — взглянуть на RAG, или Retrival Augmented Generation, который можно выполнить перед тонкой настройкой или вместо нее. Таким образом, риск поломки модели снижается, как и риск тонкой настройки. Кроме того, при использовании RAG не требуется затрат на тонкую настройку, поскольку вы не платите за использование графического процессора при нескольких попытках, необходимых для точной настройки; и вы можете сохранить конфиденциальность своих данных, разместив их локально. Кроме того, вы снижаете риск возникновения галлюцинаций, что всегда плохо, когда вы пытаетесь создать чат-бота с искусственным интеллектом для своего бизнеса. Поэтому я включил документацию, объясняющую эту систему. У NVIDIA даже есть проект на GitHub, который позволит вам создать своего первого чат-бота с искусственным интеллектом с помощью RAG всего за пять минут.

Что вам нужно для обучения основам LLM
Во-первых, много денег! В официальном документе LLaMA говорится, что обучение LLaMa с использованием 2048 графических процессоров A100 емкостью 80 ГБ заняло 21 день. Мы не можем предполагать, сколько это стоит, но кто-то другой написал здесь (подсказка: это очень много!)
Вам также понадобится команда экспертов… но не обязательно сотни! Mixture от Mistral AI превзошел GPT3.5 (согласно тесту Mistral AI) при команде численностью менее 20 человек.
Также потребуется много данных: для этого вам, возможно, придется порыться в Интернете или обратиться за помощью к партнерству. Затем данные необходимо будет подготовить, т.е. очистить и дедуплицировать.
Наконец, вам понадобится много вычислительной мощности! Если мы посмотрим на этот график NVIDIA:

… мы видим большой скачок между A100 и H100 (время обучения от одного месяца до одной недели для самых больших моделей).

Как работать с большим количеством данных
Наши клиенты Superpod используют Spark для подготовки данных, который использует ЦП (около 10 000 виртуальных ЦП) и около 100 ТБ блочного хранилища, прежде чем набор данных будет сохранен в объектном хранилище. Кстати, Scaleway в настоящее время работает над предложением управляемого кластера Spark: следите за этим!

NVIDIA также предоставляет такие инструменты, как NeMo data Curator (через NGC/Nvidia AI Enterprise, поэтому мы говорим о контейнерах), который имеет такие функции, как загрузка данных и извлечение текста, переформатирование и очистка текста, фильтрация качества, дедупликация на уровне документа и т.д. многоязычная дезактивация последующих задач и многое другое.

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

Как начать обучение
Чтобы начать обучение, вам понадобится более одного графического процессора, поэтому строительными блоками будут NVIDIA DGX H100 — готовые к использованию компьютеры с установленной максимальной конфигурацией сервера, так что вы получите лучшее из лучшего:

• 8 графических процессоров NVIDIA H100 емкостью 80 ГБ и 640 ГБ общей памяти графического процессора
• 18 подключений NVIDIA NVLink на каждый графический процессор
• 900 гигабайт в секунду двунаправленной пропускной способности между графическими процессорами благодаря NVLink
• 4x NVIDIA NVSwitch™
• 7,2 терабайта в секунду двунаправленной пропускной способности между графическими процессорами
• В 1,5 раза больше, чем предыдущее поколение
• 10 сетевых интерфейсов NVIDIA ConnectX-7, 400 гигабит в секунду
• 1 терабайт в секунду пиковой пропускной способности двунаправленной сети
• Два процессора Intel Xeon Platinum 8480C, всего 112 ядер и системная память объемом 2 ТБ.
• SSD-накопитель NVMe емкостью 30 терабайт — высокоскоростное хранилище для максимальной производительности.

Чтобы построить Superpod, вы берете этот сервер, а затем объединяете 32 из них, ни больше, ни меньше. Это то, что NVIDIA называет масштабируемой единицей. Если вы увеличите четыре масштабируемых устройства, у вас будет 128 узлов, и это будет система SuperPOD H100. Каждый из четырех блоков имеет производительность 1 экзафлопс в формате FP8, что в общей сложности составляет до 4 эксафлопс в формате FP8, а кластер управляется NVIDIA Base Command Manager, поэтому программное обеспечение NVIDIA с оркестратором SLURM позволяет запускать задания на нескольких компьютерах для провести обучение.

Итак, в Scaleway у нас есть два суперкомпьютера:
Jeroboam, уменьшенная версия кластера, предназначенная для обучения написанию кода с несколькими графическими процессорами и несколькими узлами:

• 2 узла NVIDIA DGX H100 (16 графических процессоров Nvidia H100)
• До 63,2 PFLOPS (тензорное ядро ​​FP8)
• 8 графических процессоров Nvidia H100 80 ГБ SXM с NVlink до 900 ГБ/с на узел
• Двойной процессор Intel Xeon Platinum 8480C (всего 112 ядер с частотой 2 ГГц)
• 2 ТБ оперативной памяти
• 2x NVMe по 1,92 ТБ для ОС
• NVMe емкостью 30,72 ТБ для временного хранилища
• Пропускная способность (для 2 DGX): до 40 ГБ/с при чтении и 30 ГБ/с при записи.
• Сеть межсоединений графических процессоров Nvidia Infiniband со скоростью до 400 Гбит/с (на уровне кластера)
• Высокопроизводительное хранилище DDN емкостью 60 ТБ с низкой задержкой.

Nabuchodonosor, «настоящая вещь» для обучения, которая также создана для людей, которые хотят обучать LLM с помощью видео, а не только текста, благодаря большому объему высокопроизводительного хранилища…

• 127 узлов NVIDIA DGX H100 (1016 графических процессоров Nvidia H100)
• До 4 EFLOPS (тензорное ядро ​​FP8)
• 8 графических процессоров Nvidia H100 80 ГБ SXM с NVlink до 900 ГБ/с на узел
• Двойной процессор Intel Xeon Platinum 8480C (всего 112 ядер с частотой 2 ГГц)
• 2 ТБ оперативной памяти
• 2x NVMe по 1,92 ТБ для ОС
• NVMe емкостью 30,72 ТБ для временного хранилища
• Сеть межсоединений графических процессоров Nvidia Infiniband со скоростью до 400 Гбит/с (на уровне кластера)
• 1,8 ПБ высокопроизводительного хранилища DDN с низкой задержкой
• Пропускная способность (для 127 DGX): до 2,7 ТБ/с при чтении и 1,95 ТБ/с при записи.

Обучение LLM


Проблема обучения LLM Nabuchodonosor заключается в том, что это пользовательский опыт HPC, что означает работу SLURM, а не Kubernetes. Однако это по-прежнему контейнеры, которые вы создаете поверх образов контейнеров NVIDIA NGC (Pytorch, Tensorflow, Jax…). Вот почему, когда вы пишете свой код с этими изображениями NGC, даже с одним небольшим графическим процессором, ваш код сможет легче масштабироваться. Одна из лучших практик — если у вас, скажем, 100 узлов, не запускайте задания на всех из них. Сохраните несколько запасных на случай, если один или два графических процессора выйдут из строя (такое случается!) Таким образом, если у вас возникнут какие-либо проблемы, вы сможете перезапустить свою работу, заменив неисправные узлы.

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

Еще есть комплексная платформа Nvidia NeMo, которая также поможет вам создавать, настраивать и развертывать генеративные модели искусственного интеллекта.


Суперкомпьютеры Scaleway были построены всего за три-семь месяцев, поэтому обеспечить своевременную доставку всех компонентов и их правильное подключение с помощью более чем 5000 кабелей было непростой логистической задачей!

Обеспечение электропитанием также является довольно сложной задачей: энергопотребление системы Nabuchodonosor Superpod составляет 1,2 МВт, а это означает, что мы можем разместить только два блока DGX в каждой стойке, так что это не очень эффективное использование площади центра обработки данных. Еще есть стоимость электроэнергии, которая, например, во Франции в пять раз выше, чем в США. Но поскольку углеродоемкость французской электроэнергии очень низкая, она генерирует примерно в семь раз меньше выбросов, чем, например, в Германии. Более того, поскольку все машины искусственного интеллекта Scaleway размещены в DC5, который не имеет кондиционера и, следовательно, потребляет на 30–40% меньше энергии, чем стандартные центры обработки данных, мы можем сказать, что это одна из самых устойчивых установок искусственного интеллекта в мире. Подробнее об искусственном интеллекте и устойчивом развитии здесь.

Что дальше?


В этом году Scaleway выпустит суперчипNVIDIA GH200 Grace Hopper, который сочетает в себе процессоры Grace ARM и графические процессоры Hopper в одном устройстве, которые связаны со скоростью 900 ГБ/с. Вы можете соединить 256 таких устройств вместе, что намного больше, чем вы можете подключить в конфигурации DGX, описанной выше (8 графических процессоров, подключенных со скоростью 900 ГБ/с с помощью NVlink в одном серверном узле DGX H100). А если вам нужно больше, вы даже можете подключить несколько ячеек 256 GH200 через Infiniband со скоростью 400 Гбит/с. Так что это действительно для случаев использования, где память является узким местом, поэтому это действительно для HPC и для вывода LLM. Когда они все собраны вместе, это похоже на гигантский графический процессор, предназначенный для самых требовательных случаев использования, например, в здравоохранении и науках о жизни.

Стеллаж в DC5 завершен. Проводка Atari. Светодиодам тесно. Хорошая плотность — 672 сервера в стойке.

18 марта 2024 г. обслуживание общедоступного сетевого интерфейса для рабочих узлов Kapsule будет прекращено.

Усиление безопасности повсюду было и всегда будет нашим главным приоритетом, и именно поэтому кластеры Kapsule не могут иметь только публичные IP-адреса. Это здорово, часто очень удобно, и мы оставим общедоступные IP-адреса по умолчанию. Но лучший путь вперед — использовать бесплатные частные сети Scaleway для защиты вашей инфраструктуры. Они позволяют всем вашим облачным ресурсам — узлам, базам данных, «голому железу» — взаимодействовать в изолированной и безопасной сети без использования общедоступного Интернета.

Вот почему мы ввели новое значение по умолчанию — «контролируемую изоляцию», при котором узлы имеют как общедоступные, так и частные IP-адреса.

Срок удаления

• По состоянию на 18 октября 2023 г. общедоступные кластеры устарели ( журнал изменений ). К новым кластерам Kapsule должна быть подключена (бесплатная) частная сеть.
• 4 декабря 2023 г. мы покажем уведомление об устаревании во всех кластерах без частных конечных точек и предупреждения о необходимости миграции.
• 18 марта 2024 г. обслуживание устаревшей общедоступной сети будет прекращено ( уведомление ).
• В период с 18 марта 2024 г. по 26 апреля 2024 г. кластеры Kapsule, по-прежнему имеющие общедоступные конечные точки, будут автоматически перенесены Scaleway в частные сети.

Миграции будут происходить регион за регионом в следующем порядке:

• PL-WAW: 18 марта 2024 г. – 22 марта 2024 г.
• NL-AMS: 1 апреля 2024 г. – 5 апреля 2024 г.
• FR-PAR: 15 апреля 2024 г. – 26 апреля 2024 г.

Как узнать, использует ли мой кластер только общедоступные сети?
До мая 2023 года и до того, как VPC стал общедоступным в Scaleway, режим сети по умолчанию был полностью общедоступным.
Если вы создали кластер Kapsule до этого времени, весьма вероятно, что ваш кластер не был настроен с подключенной частной сетью.
Однако, если вы не уверены, использует ли ваш кластер эту функцию, вы можете проверить несколько мест:

• В списке кластеров Kubernetes найдите столбец «Сеть»; появится предупреждение (!) «Паблик»
• Для любого кластера, который еще предстоит перенести, в верхней части обзора будет отображаться постоянный желтый предупреждающий баннер.

Что я получу от этого?
Перейдя на частную сеть в начале 2024 года, вы защитите свою инфраструктуру от будущего.

• Более безопасный Kubernetes: частные сети позволяют вашим облачным ресурсам взаимодействовать в изолированной и безопасной сети без использования общедоступного Интернета.
• Более устойчивый кластер: частные сети позволяют настраивать кластеры из нескольких зон доступности.
• Сверхгибкие возможности изоляции: вы можете либо сохранять общедоступные IP-адреса на своих узлах (защищенные группами безопасности), либо иметь только частные IP-адреса на узлах с одним выходным IP-адресом. Или оба!
• Готовы к большему количеству функций: вскоре плоскости управления будут изолированы от ваших рабочих узлов, и все они будут общаться в одной частной сети. Вы даже сможете ограничить/разрешить диапазон IP-адресов или портов, чтобы контролировать, кто может получить доступ к серверу API.

Какова плата?
VPC и частные сети предоставляются совершенно бесплатно.

Будут ли простои во время миграции?
Да, подключение частной сети к кластеру Kapsule приводит к неизбежным потерям сети от 1 до 10 минут.

Что произойдет после начала миграции:

• Ваша плоскость управления будет перезапущена в первый раз: API Kubernetes вашего кластера будет временно недоступен.
• Ваши пулы будут обновлены для миграции узлов в частную сеть. Все ваши узлы будут перезагружены в соответствии с указанной политикой обновления ваших пулов.
• После перезагрузки всех ваших узлов ваша плоскость управления будет настроена на использование частной сети и перезапущена еще раз. Затем ваши балансировщики нагрузки будут перенастроены и также перенесены в частную сеть.
• Наконец, сетевой интерфейс контейнера (CNI) вашего кластера будет перенастроен и перезапущен для использования частной сети.

Важно! На этапе №4 сеть модулей вашего кластера будет временно недоступна в течение 1–10 минут, поскольку все модули CNI перезапускаются. Ориентировочная продолжительность зависит от размера вашего кластера и используемого вами CNI. На этом этапе ваши модули не смогут взаимодействовать друг с другом.

Как мне перенести кластеры Kapsule?

• Либо с помощью консоли Scaleway: в информации о вашем кластере перейдите на вкладку «Частная сеть», чтобы начать миграцию.
• Или через Terraform: просто установите Private_network_id с ресурсом Scaleway_k8s_cluster, чтобы запустить миграцию.

• Нет PNID => PNID: переводит кластер в частный
• PNID a => PNID b: предупреждение, затем принудительное создание нового кластера.

Пожалуйста, внимательно выбирайте частную сеть.

• После подключения кластера к частной сети вы не сможете отменить эту миграцию.
• Кластер невозможно переместить в другую частную сеть после миграции.
• Частную сеть невозможно отключить.

24 января в 23:48 по центральноевропейскому времени (CET) компания Scaleway столкнулась с инцидентом в регионе FR-PAR, который затронул клиентов, использующих управляемые сервисы Kubernetes Kapsule, Kosmos, как с взаимными, так и с выделенными средами, а также некоторые продукты, такие как Cockpit.

Проблема была решена к 01:03 той же ночи. Вот обзор того, что произошло.

Хронология инцидента
23:48: В Scaleway Kubernetes API возникла ситуация нехватки памяти (OOM). Инцидент начался, затронув API-интерфейс региона Kubernetes FR-PAR, что привело к тому, что узлы не смогли пройти аутентификацию в своей плоскости управления, в результате чего некоторые узлы стали NotReady.
23:48: На API-шлюзе обнаружена повышенная нагрузка, при этом количество запросов значительно возросло.
00:00:10: Инцидент передан на внутреннюю эскалацию и обработан дежурными инженерами Scaleway.
00:00–00:30: Продолжается диагностика: ситуация с OOM определена как основная причина сбоя.
00:35 — 00:40: Приняты меры по увеличению оперативной памяти API Kubernetes и запуску дополнительных реплик.
00:43: Исправление сработало, количество запросов к API-шлюзу быстро сокращается.
00:54: Узлы Kubernetes восстанавливали работу, большая очередь действий на отслеживаемых экземплярах
01:03: Все кластеры FR-PAR начали стабилизироваться после реализации дальнейших мер, таких как очистка кеша реестра и мониторинг любых дальнейших проблем.
01:13: Показатели в Cockpit начали появляться снова, указывая на полное восстановление.
После инцидента: для обеспечения стабильности были внесены непрерывный мониторинг и корректировки, включая корректировки конфигураций сервисов.

Влияние

• Увеличение времени ответа шлюза API, приводящее к некоторой недоступности (достижение тайм-аутов)
• Узлы Kubernetes не могут пройти аутентификацию и поэтому временно переходят в состояние «Неготов», что приводит к сбою в обслуживании.
• При необходимости активация процесса автоматического восстановления кластера, генерирующая автоматическую замену узла.

Основная причина и решение проблемы
На стороне Кубернетеса
Инцидент возник из-за сценария нехватки памяти (OOM) в API Scaleway Kubernetes, вызванного одновременным развертыванием в FR-PAR. Ситуация еще более усложнялась, поскольку этот API в настоящее время обрабатывал аутентификацию, не позволяя Kubelet обновлять свои аренды, что приводило к тому, что узлы переходили в состояние NotReady и повторяли попытки на неопределенный срок.
Решение:
Для исправления были предприняты следующие корректирующие действия:

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

Долгосрочные решения:
Мы планируем реализовать следующие меры безопасности:

• Реализация локального кэша аутентификации
• Дальнейшие разработки по аутентификации узлов.

На стороне API-шлюза
На API-шлюз значительно возросла нагрузка, в первую очередь из-за подавляющего количества запросов, исходящих от неисправных компонентов на стороне Kubernetes.

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

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

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

8 декабря в 09:45 компания Scaleway столкнулась с инцидентом в зоне доступности NL-AMS-1, который повлиял на клиентов, использующих продукты в этой зоне доступности. Проблема была решена к 14:10 того же дня. Вот важная информация о том, что произошло.

Продукт Block Storage столкнулся с проблемой, и в результате другие продукты на его основе (например, Instances, Kapsule, Load Balancer, Managed Databases и т. д.) столкнулись либо с высокой задержкой, либо с недоступностью.

Глобальная недоступность: 2 часа 40 минут.
Влияние на платформу (задержка, недоступность и т. д.): 5 часов 20 минут.

Контекст
Наш продукт блочного хранилища основан на программно определяемом хранилище Ceph, смешанном с нашими собственными API для управления всеми запросами продуктов.

Эти API выполняют две основные роли: управление нашей собственной инфраструктурой и повышение ее безопасности.

Мы выполняли критическое обновление безопасности нашего кластера блочного хранилища NL-AMS-1, чтобы укрепить его перед периодом «заморозки».

Эти обновления уже были выполнены на нескольких наших кластерах Ceph (а также на предварительном и рабочем) без какого-либо воздействия, что побудило нас выполнить это обновление в кластере NL-AMS-1. Это обновление оказалось корнем проблемы.

Хронология инцидента
Мы запланировали вмешательство в нашу платформу блочного хранилища в NL-AMS-1 в четверг, 7 декабря, в 15:00. Это вмешательство было предназначено для обновления нашей версии Ceph с использованием более свежих обновлений безопасности.

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

В пятницу, 8 декабря, в 9:40 утра мы начали наблюдать увеличение нагрузки на кластер с незначительным влиянием на время отклика, с нашей точки зрения. Ситуация была стабильной, и, с нашей точки зрения, воздействие становилось меньше.

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

Наши специалисты выявили проблему в 11:45. В нашем кластере были установлены параметры настройки, отличные от настроек по умолчанию.

Применение исправлений требовало времени и требовало постепенного их применения на всех серверах.

В 13:40 блочное хранилище было восстановлено и работало стабильно. Произошло незначительное влияние на производительность из-за балансировки нагрузки из-за применения обновленных настроек.

После этого все наши команды (Instance, DB, K8S и т. д.) работали над тем, чтобы вернуть свои услуги.

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

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

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

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

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

Кроме того, во время проблем с этим поколением блочного хранилища возникли некоторые проблемы, связанные с аппаратным обеспечением, которые замедлили время разрешения.

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

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

Также обратите внимание, что у нас есть новые предложения (с низкой задержкой), разработанные с использованием нового оборудования и еще более высокой отказоустойчивости. В настоящее время они находятся в публичной бета-версии.

Эти предложения с низкой задержкой обеспечивают два уровня производительности (IOPS 5K и 15K) и улучшенное время отклика.

Они доступны через наш новый API/путешествие пользователя/инструменты разработки и уже совместимы с Instance, Kapsule (только в новых кластерах, с определенной версией CSI — ссылка на документ?) и DBaaS (предложения с оптимизированной стоимостью). Доступные AZ на данный момент ограничены, но в ближайшие месяцы появятся новые: FR-PAR-1, FR-PAR-2, NL-AMS-1, NL-AMS-3, PL-WAW-3.

Вы уже можете попробовать их и воспользоваться скидкой 50% во время публичного бета-тестирования (уже действует до 1 февраля).

Что нового в Scaleway?
Привет! В преддверии сенсационного лета мы в Scaleway продолжаем усердно работать над тем, чтобы представить вам самые последние и лучшие облачные инновации. Новое в этом месяце: выберите инстансы в нашей новой зоне доступности в Амстердаме; Виртуальное частное облако для более надежной инфраструктуры, чем когда-либо; новая управляемая база данных со встроенными выделенными ресурсами; и многое другое кроме этого! Включая совершенно новый раздел, ориентированный на клиента, в этом месяце с участием Sentium Consulting; и уникальные идеи об экологически чистых ИТ, открытом исходном коде и истории происхождения Elastic Metal, рассказанные впервые!

Обновления продукта
Экземпляры теперь доступны в нашем новом AMS-3 AZ.
Мы открыли новую зону доступности (AZ) в Амстердаме! AMS-3 в Нидерландах теперь открыт, предлагая улучшенную доступность и близость к вашим операциям в скандинавских странах. Scaleway по-прежнему стремится предоставлять суверенную и избыточную облачную среду. Испытайте непревзойденную производительность, надежность и суверенность данных благодаря развертывание ваших экземпляров в AMS-3.

VPC теперь общедоступен для защиты всей вашей инфраструктуры!
Виртуальное частное облако поможет вам распределить ресурсы по зонам доступности в одной изолированной сети. Идеальный способ максимально повысить надежность инфраструктуры без ущерба для безопасности. Ваша архитектура станет более надежной за счет распределения ресурсов по зонам доступности в каждом регионе (PAR-AMS-WAW) и обмена данными в одной и той же частной сети. Настройте свой VPC прямо сейчас и защитите свою инфраструктуру Scaleway!
Теперь доступны управляемые базы данных с выделенными ресурсами!

Откройте для себя нашу новую управляемую базу данных DB-POP2 для PostgreSQL и MySQL с включенными выделенными ресурсами (виртуальный ЦП и ОЗУ). Этот новый модельный ряд готов поддерживать самые интенсивные рабочие нагрузки баз данных и обеспечивать душевное спокойствие изо дня в день.

Kubernetes Kapsule и Kosmos теперь изначально интегрированы с Cockpit!
Отслеживайте показатели и журналы уровня управления с помощью Cockpit, чтобы обнаруживать инциденты Kubernetes и диагностировать сбои, пока не стало слишком поздно. Воспользуйтесь новой информацией об использовании плоскости управления и рабочих узлов, от ЦП до памяти, чтобы оптимизировать распределение ресурсов. Прочтите нашу справочную документацию Cockpit, чтобы узнать, какие другие продукты Scaleway теперь интегрированы в Cockpit.

Новая бета-версия
Хранилище данных теперь в Discovery!
Хранилище данных обеспечивает бесшовную аналитику больших наборов данных, поддерживая SQL, Apache Spark, ​​хранилище S3 и многое другое, а также автоматизирует масштабирование и администрирование для не отвлекающей разработки приложений. В августе мы выпустим первый прототип в раннем доступе для пользователей, подписавшихся на бета-версию.

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

Клиентоориентированность
Масштабируемость Scaleway помогает клиентам Sentium Consulting достичь новых высот
«Стремление Scaleway к надежности и масштабируемости действительно помогло нашим клиентам добиться выдающихся успехов», — говорит Генри Смит, генеральный директор Sentium Consulting, которая предоставляет передовые решения в области искусственного интеллекта и анализа данных для таких секторов, как здравоохранение, недвижимость, фармацевтика, финансы. и гостеприимство www.scaleway.com/en/customer-testimonials

Новые ресурсы
Как инженеры могут сделать ИТ более устойчивым? Часть 3. Тематические исследования экологически чистых ИТ
Зеленые ИТ могут снизить потребление энергии до 30%… но это еще не все! Это также может вдвое сократить требования к серверу и сэкономить огромное количество CO2 и воды.
www.scaleway.com/en/blog/how-can-engineers-make-it-more-sustainable-part-3

Скейлеры выходят на открытый исходный код: «Вы не знаете, сколько вы приносите на стол».
Вот как Лейла Марабезе, один из младших инженеров DevOps Scaleway, стала участвовать в разработке открытого исходного кода. В этом видеоинтервью она делится трудностями, досадными неудачами и, конечно же, успехами.
www.scaleway.com/en/blog/open-source-leila-marabese

Нерассказанная история Elastic Metal
Как выделенные серверы, устаревший продукт Scaleway, переместились в общедоступное облако, чтобы стать Elastic Metal, нашим уникальным предложением для «голого железа»?
www.scaleway.com/en/blog/elastic-metal-story

Шифрование в состоянии покоя для экземпляров
В этом сообщении блога мы расскажем вам о процессе реализации шифрования в состоянии покоя для разделов на сервере и о том, как легко интегрировать его в среду приложения. www.scaleway.com/en/blog/encryption-at-rest-for-instances

Помогите нам создать шлюз API, который вы хотите видеть в облаке
Мы выпускаем прототип будущего продукта API Gateway, и нам нужна ваша помощь! Присоединяйтесь к нашей фазе раннего доступа, пока мы разрабатываем этот захватывающий новый продукт под открытым небом. www.scaleway.com/en/blog/api-gateway-early-access/
И, как всегда, вы можете присоединиться к нашему сообществу Slack, чтобы пообщаться с нашим сообществом инженеров. Увидимся там!
До следующего месяца,
Команда Скейлвей

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

Что нового?

Бесконечное масштабирование
Экземпляры теперь доступны в новый АМС-3 АЗ
Наше новейшее предприятие в Амстердаме, Нидерланды (AMS-3), открыто, предлагает улучшенную доступность и близость к вашим предприятиям в скандинавском регионе. Scaleway по-прежнему стремится предоставить вам независимую облачную среду с резервированием. Испытайте непревзойденную производительность, надежность и независимость данных, развернув свои экземпляры в AMS-3


Новые базы данных с выделенными ресурсами.
Управляемая база данных для MySQL и PostgreSQL представляет новое семейство с оптимизацией для производства и ее выделенными ресурсами. Это идеальный выбор для интенсивных рабочих нагрузок и ежедневного спокойствия. Обеспечьте лучшую производительность в любое время и повышенную стабильность. Создайте новую базу данных POP начиная с 17 июля 2023 года.


VPC теперь общедоступен для защиты всей вашей инфраструктуры
Виртуальное частное облако поможет вам распределить ресурсы по зонам доступности в одной изолированной сети. Это идеально подходит для обеспечения максимальной надежности инфраструктуры без ущерба для безопасности. Ваша архитектура будет более надежной за счет распределения ресурсов по зонам доступности в пределах региона (PAR-AMS-WAW), взаимодействующих в одной и той же частной сети. Настройте свой VPC прямо сейчас и защитите свою инфраструктуру Scaleway!