Scaleway Хостинг

Исследование OpenAI в 2018 году показало, что объем вычислительной мощности, необходимой для обучения современных моделей искусственного интеллекта, удваивается каждые 3,4 месяца. Такой экспоненциальный рост привел к поразительному увеличению в 300000 раз всего за 6 лет — начиная с 2012 года, года, широко известного как начало эры глубокого обучения ИИ. Это явление напрямую связано с растущей сложностью лежащих в основе моделей глубокого обучения: так называемых искусственных нейронных сетей (ИНС). Вдохновленные тем, как работает наш собственный мозг, с математической точки зрения ИНС представляют собой матрицы числовых значений, называемых весами или параметрами ИНС. Подходящие параметры вычисляются на этапе разработки, требующем большого объема вычислений, который называется обучением модели, а затем используются для умножения любых входных данных, поступающих в ИНС, с целью получения (надеюсь, разумных) выходных данных. Несколько упрощенное практическое правило: чем больше количество параметров, тем мощнее модель. AlexNet, нейронная сеть, положившая начало революции глубокого обучения в 2012 году, использовала 61 миллион параметров для классификации изображений в один из 1000 классов. Если 61 миллион — это много, подождите, пока вы не услышите, сколько их в крупнейшей нейронной сети, обученной на сегодняшний день: 175 миллиардов! Это количество значений, параметризующих GPT-3 (Generative Pre-Trained Transformer 3), разработанный OpenAI в 2020 году. Получив приглашение, GPT-3 может генерировать работающий код, писать стихи и создавать текст, который почти невозможно определить кроме того, что исходит от человека. Этот впечатляющий подвиг машинного обучения еще несколько лет назад можно было бы считать чистой научной фантастикой, поэтому есть большие надежды на то, что может предложить следующий по величине ИИ.

Однако за такие новаторские достижения приходится платить. Фактически, затраты, связанные с вычислительными ресурсами, необходимыми для обучения этих моделей, двукратны. Начнем с очевидного: денежных затрат, которые оплачивают исследовательские группы и компании, стоящие за созданием моделей. Однако это еще не все. Ущерб, который обучение модели наносит окружающей среде, — это вторая цена, которую несем все мы. К счастью, нам не нужно позволять этим соображениям откладывать подъем машин, если мы мудро выбираем место обучения. Недавнее исследование, проведенное Google, показывает, что определенный выбор, сделанный в отношении того, как и где мы обучаем нейронные сети, может снизить связанный с этим углеродный след до 1000 раз!

Давайте возьмем пример GPT-3 и посмотрим, сколько энергии можно сэкономить, проведя обучение в энергоэффективном центре обработки данных по сравнению с традиционным. GPT-3 был обучен на кластере, состоящем из 10000 графических процессоров V100 Nvidia: аппаратных ускорителей, разработанных с единственной целью оптимизации вычислений, используемых при обучении искусственных нейронных сетей. Потребляемая мощность одного графического процессора V100 составляет 300 Вт. Сколько времени нужно было на обучение GPT-3? Согласно исходной статье, для окончательного обучения модели требовалось 3,14x1023 FLOPS (операций с плавающей запятой в секунду). Общая стоимость обучения, вероятно, будет на порядок выше, поскольку типичный проект глубокого обучения включает обучение множеству различных вариантов модели, прежде чем выбрать наиболее эффективную. Для минимальной оценки возьмем 3,14x1023 FLOPS и рассмотрим только мощность, потребляемую графическими процессорами (в то время как на самом деле нам пришлось бы добавить в смесь процессоры, сеть и память). С точки зрения производительности V100 может обрабатывать 14 терафлопс при использовании чисел с плавающей запятой одинарной точности, но теоретически это число удваивается до 28 терафлопс для формата половинной точности, который использовался OpenAI. При использовании 10 000 графических процессоров это соответствует примерно 13 дням обучения или 10 000 x (300 Вт) x (13 дней) = 936 МВт-ч энергии, потребляемой только графическими процессорами.

Любой, кто по неосторожности положил ноутбук себе на колени и запустил сразу слишком много приложений, знает, что во время работы машины нагреваются. 10000 графических процессоров, которые работают на пределе своих возможностей в течение двух недель подряд, сильно нагреваются. Фактически, большая часть энергии, потребляемой в типичном центре обработки данных, идет не только на включение серверов, но и на охлаждение самого центра обработки данных. Эти и другие сопутствующие расходы учитываются показателем, называемым PUE, Power Usage Effectiveness. Этот коэффициент представляет собой отношение A / B, которое измеряет общее количество энергии A, необходимое для передачи конечного количества энергии B серверу. PUE всегда больше 1, так как значение 1 будет означать идеальную эффективность, когда на обслуживание центра обработки данных не тратится энергия. В традиционном центре обработки данных PUE может быть где-то около 1,5 и более. Это означает, что фактические затраты энергии на обучение такой модели, как GPT-3, составят не менее 936 МВтч x 1,5 = 1404 МВтч. Есть ли способ уменьшить это число?

Самый простой способ сократить количество энергии, затрачиваемой на облачные вычисления, — это выбрать центр обработки данных с более низким PUE. У Scaleway DC5, расположенного в пригороде Парижа, PUE составляет 1,15, что означает сокращение накладных расходов с 50% до 15%. Эти сокращения распространяются как на создателей модели, так и на среду, от которой мы все получаем прибыль. Вернемся к примеру с GPT-3: обучение в центре обработки данных, таком как DC5, приведет к энергопотреблению 936 МВтч x 1,15 = 1076 МВтч, сэкономив 328 МВтч, или 23% энергии, потребляемой традиционным центром обработки данных.. Для сравнения: для питания 2000 домов во Франции требуется около 1 МВт. Однако, хотя этот расчет учитывал только обучение окончательной модели, в действительности эксперименты, необходимые для достижения этой точки, увеличили бы общую стоимость энергии в 10-100 раз. Другими словами, обучение такой модели, как GPT-3, в энергоэффективном центре обработки данных, таком как DC5, позволяет сэкономить достаточно энергии, чтобы управлять средним городом в течение нескольких дней, а возможно, и недель.

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

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

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

Chia — это криптовалюта, основанная на Proof of Space.

Короче говоря, чтобы получить монеты Чиа, вам понадобится Proof of Space. Чем больше у вас хранилища, тем выше ваши шансы получить Proof of Space, тем больше монет Chia вы можете заработать.

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

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


Как видите (масштаб в петабайтах), используемое пространство бесконтрольно растет и уже достигло 7 эксабайт.

Несмотря на то, что Chia должна быть «экологичнее», чем биткойн или другие криптовалюты, основанные на Proof of Work (требующие очень энергоемких вычислительных ресурсов), ее сеть теперь составляет в общей сложности семь тысяч петабайт во всем мире.

Если учесть, что один жесткий диск в среднем составляет 8 ТБ, Chia на сегодняшний день потребляет около миллиона жестких дисков в мире. Один миллион жестких дисков, основанный на предположениях, основан на цене монеты Chia.

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

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

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

Облако, которое имеет смысл.

Чтобы обслужить как можно больше клиентов, мы решили, что с сегодняшнего дня:

• Построение Chia запрещено на всех экземплярах SSD и NVMe, выделенных серверах, службах RPN-SAN, BMaaS и блочных хранилищах. Планирование Chia требует чрезвычайно интенсивного ввода-вывода и разрушает большинство твердотельных накопителей менее чем за несколько недель.
• Важное примечание: Chia plotting влечет за собой ответственность клиента в соответствии с разделом 9 нашего контракта. Мы будем выставлять счет клиентам за любые SSD и NVM, уничтоженные из-за заговора Chia.
• Фермерство Chia разрешено на всех BMaaS, выделенных серверах и сервисах блочного хранилища без каких-либо ограничений.
• Выращивание чиа разрешено в хранилище объектов Scaleway при условии, что наш отдел продаж сделал предварительный запрос и одобрил его.
• Важное примечание: выращивание Chia в Scaleway Object Storage без предварительного разрешения будет ограничено до 250 ТБ и будет оплачено из расчета 0,08 евро за ГБ.
• Это первая мера, которая будет реализована в Scaleway, и мы тщательно следим за тем, чтобы Chia не повлияла на компании, предпринимателей или стартапы, которые доверяют нам предоставление наилучшего возможного обслуживания.

Наши группы IaaS, Trust & Safety и Excellence работают вместе, чтобы отслеживать действия, связанные с вредоносными или оскорбительными заговорами и сельским хозяйством Chia, чтобы гарантировать, что это не повлияет на качество наших услуг для других клиентов.

За дополнительной информацией обращайтесь к нашим отделам продаж или совершенствованию.

Гаспар Плантроу, вице-президент PaaS.

7 апреля в 16:35 по всемирному координированному времени компания Scaleway столкнулась с серьезным инцидентом в зоне доступности FR-PAR-1, который повлиял на наш продукт Load Balancer. Часть инфраструктуры балансировщика нагрузки была недоступна во время инцидента. В результате также пострадали продукты Database, Kubernetes Kapsule и IoT Hub, которые полагаются на Load Balancer как часть своей инфраструктуры.

Проблема была обнаружена и устранена к 17:18 по всемирному координированному времени специалистами по сетевым продуктам и пользователям и API.

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

Сразу началось восстановление сервисов. Большинство сервисов Load Balancer были восстановлены к 20:34 по всемирному координированному времени, а несколько критических случаев заставили нашу команду по надежности сайта и инженеров по продуктам работать до 0:04 по всемирному координированному времени 8 апреля. Продолжительность основного отключения составила почти 4 часа, а общий инцидент длился 7 часов 29 минут.

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

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

Анализ воздействия
Инцидент затронул несколько продуктов Scaleway.
Что касается Load Balancer, только 1574 экземпляра Load Balancer, принадлежащих 775 организациям-клиентам, были отключены до того, как мы исправили проблему и начали процедуру восстановления. Эти балансировщики нагрузки и их серверы были недоступны во время инцидента. После инцидента все ресурсы Load Balancer были восстановлены до нормального состояния.

Для базы данных было задействовано до 50 балансировщиков нагрузки, и был потерян доступ к соответствующим базам данных (до 500). Во время инцидента данные были в полной безопасности, но недоступны. В период восстановления создание базы данных и обновление «Разрешенных IP-адресов» было невозможно. Резервные копии оставались доступными и экспортируемыми в любое время.

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

Что касается Интернета вещей, это затронуло 33 клиента. Поскольку Центр Интернета вещей использует балансировщик нагрузки, базу данных и Kubernetes Kapsule, служба была недоступна во время инцидента. После инцидента все клиентские ресурсы Центра Интернета вещей были восстановлены в нормальном режиме.

Основная причина и решение проблемы
Инцидент был вызван ручным вызовом API-интерфейса Load Balancer Trust and Safety (T&S) с запросом на удаление ресурсов злонамеренного пользователя. Этот конкретный вызов не был частью обычного рабочего процесса; он состоял в созданном запросе, который должен был выдать ошибку. К сожалению, ошибка в API, представленная ранее реализацией функции «Проекты», вызвала обход проверок безопасности и спровоцировала лавинную недействительность экземпляров Load Balancer.

Хронологию инцидента можно найти здесь, на странице статуса Scaleway.

Звонок был сделан 7 апреля в 16:35 по всемирному координированному времени, а сигналы тревоги были включены в наш внутренний канал мониторинга в 16:45 по всемирному координированному времени.

Команда немедленно начала процедуру содержания и восстановления.

• 7 апреля 2021 г., 16:53 по всемирному координированному времени. API балансировщика нагрузки был переведен в режим только для чтения, чтобы избежать дальнейших операций со стороны клиентов.
• 7 апреля 2021 г., 17:20 по всемирному координированному времени. Конфигурации балансировщика нагрузки были восстановлены из нашей внутренней резервной копии базы данных, сделанной часом ранее. Данные не были потеряны, так как балансировщики нагрузки не имеют состояния.
• 7 апреля 2021 г., 17:54 UTC. Запущен процесс восстановления экземпляра Load Balancer.
• 7 апреля 2021 г., 20:10 по всемирному координированному времени 1400 экземпляров были успешно вылечены, 110 по-прежнему не работали и требовали ручного лечения.
• 7 апреля 2021 г., 20:35 по всемирному координированному времени. Все экземпляры Load Balancer были успешно восстановлены. Некоторые критические дела еще предстояло расследовать.
• 7 апреля 2021 г., 22:12 по всемирному координированному времени. Службы базы данных и IoT Hub вернулись в нормальное состояние. Некоторые крайние случаи с парой балансировщиков нагрузки и Kubernetes Kapsule все еще решались.
• — Пользовательские сертификаты TLS были недоступны, и их приходилось восстанавливать из безопасного хранилища сертификатов.
• — Обнаружение живучести серверной части не удалось из-за фильтрации IP-адресов на внутренних серверах и того факта, что IP-адреса балансировщика нагрузки изменились.
• 8 апреля 2021 г., 00:04 UTC. Все экземпляры Load Balancer были восстановлены и исправлены. Все услуги вернулись в нормальное состояние.

Как мы предотвратим повторение этого
После анализа происшествия сразу были приняты следующие меры:

• Ошибка Load Balancer T&S API была исправлена, и в тестовые наборы были немедленно добавлены дополнительные тесты.
• Процедура тестирования T&S API была обновлена с дополнительными межгрупповыми проверками и обзорами.
• Kubernetes Kapsule теперь проверяет состояние балансировщика нагрузки перед запуском автоматического восстановления.

И в ближайшее время будут реализованы:

• Улучшение рекомендаций по реализации T&S API.
• Улучшите тестовое покрытие Load Balancer T&S API и используйте инструменты анализа покрытия.
• Развертывайте и разрабатывайте инструменты для улучшения и ускорения общей процедуры восстановления Load Balancer.
• Продукт Database в рамках постоянного улучшения производительности в настоящее время модернизирует свою инфраструктуру Load Balancer, чтобы сделать ее менее подверженной сбоям.

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

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

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

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

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

Из этого события можно извлечь урок: зависимость — враг устойчивости. Мы будем заглядывать внутрь Scaleway, чтобы извлечь уроки из этого события и определить наши зависимости. Зависимость от одного сервера или одного центра обработки данных сама по себе является помехой, которую необходимо сбалансировать с помощью подхода с несколькими зонами доступности или несколькими регионами. Точно так же глобальная цифровая экономика находится под угрозой из-за слишком сильной зависимости от нескольких доминирующих облачных провайдеров, и, как мы видели, весь Интернет время от времени отключается из-за этих зависимостей. Мы, поставщики облачных услуг, обязаны обеспечить максимальную устойчивость к внешним воздействиям, но за это приходится платить: избыточность. Эту избыточность также необходимо учитывать клиентам облачных вычислений, разрабатывая отдельные схемы резервного копирования и создавая свои планы аварийного восстановления. Хорошая новость заключается в том, что облачные приложения могут легко и легко создать избыточность, распределяя свои приложения и данные между поставщиками облачных услуг с использованием хорошо установленных стандартов.
Я написал эту статью год назад: «Облако мертво, да здравствует мультиоблако», и это все еще звучит правдоподобно сегодня, особенно после этого события. Подход с несколькими облаками обеспечивает максимально возможный уровень устойчивости. Я считаю, что в Scaleway у нас есть скромность признать, что наше облако не универсально. Мы считаем, что ни один облачный провайдер быть не может. Вот почему так важна совместимость. Облачные архитекторы уже знают основные концепции и уже используют Kubernetes, Load Balancers и Terraform для абстрагирования и обеспечения устойчивости.

В заключение, не откладывайте больше думать об устойчивости. Работайте со своими облачными архитекторами и системными администраторами. Поговорите со всеми своими поставщиками облачных услуг. Распределите свою рабочую нагрузку и активы. Задайте трудные вопросы.
Сегодня мы призываем все заинтересованные стороны быть прозрачными в отношении своих мер безопасности. Вместе мы строим цифровое общество завтрашнего дня. Если у вас есть какие-либо вопросы, вы можете связаться с нами по адресу transparent@scaleway.com

Вы слышали об IP-адресах и IPv6? Адрес Интернет-протокола (IP-адрес) — это цифровая метка для идентификации и определения местоположения сетевых устройств. Каждое устройство, подключенное к любой компьютерной сети, которая использует Интернет-протокол для связи, будет иметь IP-адрес.

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

Инженерная группа Интернета (IETF) и IANA впервые развернули исходную версию Интернет-протокола в 1983 году и назвали ее Интернет-протоколом v4 (IPv4). Каждый адрес IPv4 имеет 32 бита, что ограничивает адресное пространство до 4 294 967 296 доступных адресов. Может показаться, что это много, и еще в 1983 году этого, безусловно, было достаточно для нужд всех пользователей Интернета. Но к концу 1990-х, по мере того, как использование Интернета росло и росло, стало очевидно, что это не так, и многие провайдеры интернет-услуг увидели быстрое исчерпание своих доступных адресов IPv4.

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

Все это побудило к созданию новой версии Интернет-протокола для решения этих проблем. Новая версия протокола была разработана и выпущена в 1998 году и получила название Internet Protocol v6 (IPv6). Размер IPv6-адреса составляет 128 бит, поэтому в его адресном пространстве имеется около 340 282 366 920 938 000 000 000 000 000 000 000 000 уникальных IP-адресов. Или записано цифрами: 340 триллионов, 282 миллиарда, 366 миллионов, 920 тысяч, 938 — с последующими 24 нулями. Достаточно, чтобы каждый атом на поверхности Земли имел IP-адрес. Предположим, этого нам хватит на некоторое время.

После нескольких лет тестирования новый протокол получил более широкое распространение в течение 2000 года. Поскольку последний доступный блок IPv4 / 8 был назначен в апреле 2018 года, мы сейчас находимся в ситуации, когда текущие потребности IPv4 могут быть удовлетворены только путем восстановления неиспользуемых подсетей или обмен IP-адресами между поставщиками услуг. Поскольку Интернет растет с каждым днем, полное исчерпание IPv4, без каких-либо адресов для обмена или подсетей для использования, не за горами. Вот почему в Scaleway мы поощряем использование IPv6 в ваших производственных системах. В этом сообщении блога мы объясним, как использовать IPv6 в различных продуктах Scaleway.

В Scaleway Elements и Scaleway Dedibox все виртуальные экземпляры и выделенные серверы совместимы с IPv6, а возможность подключения по IPv6 предоставляется без каких-либо дополнительных затрат.

IPv6 в виртуальных экземплярах Scaleway Elements
Виртуальные экземпляры Scaleway Elements имеют подсеть / 64 IPv6 каждый. Подсеть статически маршрутизируется к виртуальному экземпляру, и по умолчанию для каждого из ваших экземпляров настроен один IPv6-адрес. Вы можете увидеть настроенные адреса IPv4 и IPv6 вашего экземпляра, а также сетевую маску и информацию о вашей подсети на странице информации об экземпляре каждого виртуального экземпляра:


IPv6 в частных сетях Scaleway на виртуальных экземплярах
Частная сеть на Scaleway Elements — это сеть Ethernet второго уровня, подобная локальной сети. Новый сетевой интерфейс с уникальным адресом управления доступом к среде передачи (MAC-адресом) настраивается на каждом экземпляре в частной сети. Это виртуальные, но полностью частные локальные сети, которые надежно соединяют ваши экземпляры, не открывая их публично. Каждая частная сеть полностью совместима с IPv6. Чтобы настроить IPv6 в своей частной сети, вы всегда должны использовать подсеть / 64, и мы рекомендуем использовать диапазон уникальных локальных адресов (ULA) fc00 :: / 7. Генераторы адресов ULA IPv6 широко доступны для создания персонализированного диапазона.

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

IPv6 в Scaleway Dedibox
В целях борьбы с полным исчерпанием доступных адресов IPv4 каждый клиент может запросить бесплатную подсеть IPv6 / 48 из консоли Scaleway Dedibox. Это обеспечивает теоретический максимум 18 446 744 073 709 551 616 адресов IPv6.

В отличие от IPv4, IPv6 не имеет маски подсети. Вместо этого используется длина префикса или, для краткости, «префикс». Длина префикса IPv6 работает аналогично CIDR (бесклассовая междоменная маршрутизация) в IPv4. Он определяет, сколько битов адреса определяют сеть, в которой он существует. Длина префикса может иметь любое значение от 1 до 128, но наиболее распространенные префиксы, используемые в сетях IPv6, кратны четырем.

Чтобы использовать подсеть IPv6 на нескольких выделенных серверах, вы можете разделить эту подсеть на более мелкие префиксы со следующими ограничениями:

• Столько префиксов / 56, сколько у вас выделенных серверов
• Столько префиксов / 64, сколько у вас есть резервных IP-адресов

Хотя технически возможно использовать подсети меньшего размера, они непрактичны для сетей на базе Ethernet, поскольку для SLAAC (автоконфигурация адреса без сохранения состояния) требуется 64 бита. SLAAC автоматически генерирует 64-битный идентификатор интерфейса на основе существующего MAC-адреса сетевого интерфейса. Поскольку каждый MAC-адрес уникален, сгенерированный идентификатор интерфейса также уникален. Эти автоматически сгенерированные 64-битные идентификаторы интерфейса действительны во всем мире для адресации и однозначной идентификации каждого сетевого интерфейса в Интернете.


Конфигурация подсети на вашем Dedibox выполняется с использованием клиента DHCPv6 и DUID подсети (уникальный идентификатор DHCP). DUID — это ваш «ключ» для подсети, и DHCP-сервер выделяет подсеть вашему компьютеру, сравнивая DUID со своей базой данных. Если соответствующая комбинация найдена, он доставляет данные конфигурации (адрес, время аренды, DNS-серверы и т. Д.) Клиенту.

Для получения дополнительной информации о настройке IPv6 на вашем сервере Dedibox, в том числе в различных дистрибутивах Linux и Windows, обратитесь к нашей специальной документации.

Автоконфигурация IPv6-адреса без сохранения состояния на серверах Dedibox
На нескольких выделенных серверах Dedibox вы также можете использовать автоконфигурацию адреса без сохранения состояния (SLAAC), что позволяет вашему серверу автоматически получать адрес IPv6. При использовании SLAAC сервер отправляет запрос маршрутизатора для получения префикса IPv6 с глобальной маршрутизацией, который генерирует полный адрес IPv6 на основе идентификатора сетевого интерфейса, известного как EUI-64. Это делается посредством обмена запросом маршрутизатора -> объявлением маршрутизатора. RA позволяет настроить маршрут по умолчанию и позволяет получить постоянно назначенный статический IPv6 для вашего Dedibox без какой-либо ручной настройки. Вы можете включить эту функцию прямо из консоли, нажав соответствующую кнопку:


IPv6 на серверах Scaleway Bare Metal Cloud
Серверы Scaleway Bare Metal Cloud имеют подсеть / 128 IPv6 и позволяют использовать один IPv6-адрес на вашем сервере. Этот IP-адрес настраивается автоматически во время установки машины, и каждый сервер Bare Metal Cloud поддерживает IPv6 без необходимости дополнительной настройки.

Отмечая первую годовщину создания нашего контейнерного оркестратора Kubernetes Kapsule, мы рады сообщить, что запускаем инновационный и ориентированный на сообщество опыт: Breakathon. 25 марта разработчики и сообщества пользователей всех уровней приглашаются проверить пределы кластеров Kubernetes Kapsule и по-настоящему проверить свои навыки, сочетая веб-разработку, управление несколькими кластерами, тематические исследования AI и анализ производительности.

The Breakathon — «Вы уровень босса?»
Этот 9-часовой марафон технологических задач, основанный на концепции традиционного хакатона, имеет изюминку. Scaleway также предлагает своему сообществу проверить пределы своего решения Kubernetes Kapsule самым креативным и экстремальным способом. Breakathon предоставит участникам беспрецедентную возможность участвовать в построении значимой экосистемы, получая при этом удовольствие.

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

Участие в Kubernetes Kapsule Breakathon — это способ не только проверить, насколько хорошо пользователи знают Kubernetes, независимо от вашего уровня, но и пригласить их участвовать и влиять на развитие продукта. В настоящее время Kubernetes Kapsule предлагает следующие возможности: иногда недостаточно используются. Редакторы программного обеспечения сместили свои приоритеты и теперь активно инвестируют в модели SaaS (программное обеспечение как услуга). Мы хотим демистифицировать сложность безопасности в облаке и архитектуре Kubernetes

сказала Эммануэль Демомпион, менеджер по продуктам Scaleway Kubernetes Капсула.

www.scaleway.com/en/kubernetes-kapsule/

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

Выход в Великобританию — еще один захватывающий шаг вперед в нашей международной экспансии, продвигающий нашу миссию по созданию и масштабированию облака таким образом, чтобы это было целесообразно для наших клиентов и их конечных пользователей. Рынок Великобритании имеет первостепенное значение для глобальной стратегии роста Scaleway, и мы с нетерпением ждем возможности продемонстрировать нашим клиентам из Великобритании наши инновационные технологии и выдающийся опыт работы с клиентами. В ознаменование нашего приезда в Великобританию мы также рады запустить нашу программу стартапов. Эта программа имела безоговорочный успех с момента ее запуска в июне прошлого года, поддерживая более 100 компаний услугами IaaS и Paas, а также бесценным обучением и наставничеством. Поскольку мы сами не так давно были стартапом, мы считаем важным помочь следующему поколению европейских технологических лидеров расти.

С Covid 19 Европа вступила в величайший момент цифровой и экологической трансформации. Центры обработки данных и облачные вычисления лежат в основе этой трансформации. Последняя экспансия Scaleway в Лондон демонстрирует, что Великобритания помогает формировать цифровую инфраструктуру завтрашнего дня. Scaleway начинала с веры в то, что Европа может предложить устойчивые цифровые решения мирового класса. Решения, которые могут конкурировать в глобальном масштабе, и Brexit этого не изменили. Продолжающийся устойчивый рост Scaleway по всей Европе, безусловно, будет доказывать это.

Нора Герби, бывший главный представитель компании «Лондон и партнеры» во Франции

Scaleway для британских стартапов
Чтобы отпраздновать и отметить наш переезд в Великобританию, мы одновременно запускаем британскую версию нашей успешной глобальной программы стартапов, направленной на то, чтобы помочь стартапам масштабироваться и охватить более широкую аудиторию. Запущенная в июне 2020 года программа Scaleway Startup Program выбирает 15 компаний каждый месяц для участия в программе. Выбранные компании получают доступ к облачным инструментам Scaleway в виде кредитов на сумму до 30 000 фунтов стерлингов в течение 12-месячного периода в дополнение к обучению и наставничеству в области ИТ, разработки продуктов и маркетинга. Программа стартапов также предоставляет участникам бесценную возможность использовать международную сеть контактов Scaleway.

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

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

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

Додди Эль-Габри, соучредитель и генеральный директор Cinebur.

Эта программа предназначена для стартапов, разделяющих наши ценности и предпринимательскую ДНК.

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

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

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

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

Заявки на участие в этой специальной британской программе открыты с 15 марта по 15 апреля: www.scaleway.com/en/startup-program/

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

Купите свой Apple Silicone M1 как услугу прямо сейчас! В Scaleway мы гордимся тем, что раздвигаем границы возможного и того, что технологии могут сделать для вас. Вот почему мы представляем вам полностью родную версию macOS Big Sur, работающую на молниеносном Mac mini M1, обеспечивающую инновационные энергоэффективные вычисления и позволяющую выполнять больше вычислений, сжигая меньше.

Максимально используйте передовые технологии при непревзойденном соотношении цена / качество. Наш новый Apple Silicon M1 as-a-Service идеально подходит для непрерывной интеграции и доставки ваших сложных macOS или iOS.
www.scaleway.com/en/hello-m1/

IoT маршруты
Обмен сообщениями между издателями MQTT и подписчиками MQTT — это нормально, за исключением того, что не все программное обеспечение может понимать MQTT, и на уровне между вашими объектами и вашим приложением вам может потребоваться несколько дополнительных программных инструментов для обработки ваших данных.

Что такое маршруты Интернета вещей
Маршрут — это подписчик, который будет пересылать полученные сообщения ряду приложений, например:

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

В то время как некоторые маршруты будут принимать только сообщения (база данных, хранилище, обмен сообщениями и т. Д.), Другие также могут реагировать на сообщения (бессерверные, AI,…), позволяя вам «отвечать» другими сообщениями в вашем Центре Интернета вещей.

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


Подводя итог, можно сказать, что маршруты являются связующим звеном между Центром Интернета вещей и множеством другого программного обеспечения, чтобы упростить вашу жизнь и сосредоточиться на том, что делает вас ценным: на вашей работе. Для получения дополнительной информации о маршрутах обратитесь к нашей специальной документации. Количество доступных маршрутов по-прежнему невелико, но вскоре оно значительно увеличится. Не стесняйтесь сообщить нам о своих пожеланиях!
www.scaleway.com/en/docs/scaleway-iothub-route/