Scaleway Хостинг

Предстоящие изменения цен на 1 января 2022 г.

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

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


Например, для сервера, потребляющего 50 Вт, стоимость электроэнергии в месяц увеличилась с 1,44 евро до 7,20 евро, то есть дополнительные расходы + 5,76 евро в месяц. Мы включили это увеличение затрат в нашу маржу, насколько это было возможно, но возникла необходимость интегрировать часть этого увеличения в наши сборы.

С 1 января 2022 года стоимость всех серверов Dedibox будет увеличиваться на 1 евро в месяц. Это увеличение будет применяться к текущим и будущим заказам.


Повышение цен в связи с расходами на лицензии Microsoft
Что касается последних 8 лет, Microsoft приняла одностороннее решение о повышении цен на свои лицензии SPLA Windows Server на 10%, и поэтому нам необходимо соответствующим образом скорректировать наши цены.

Сложная политика лицензирования Microsoft запрещает нам предлагать вам что-либо, кроме ежемесячных лицензий SPLA на ваших серверах, но будьте уверены, что Scaleway ведет постоянную борьбу, чтобы предложить вам лучшее из экосистемы Microsoft на справедливых условиях.
Новые цены будут применяться ко всем версиям Windows Server 2016, 2019 и 2022. Новые ежемесячные цены (без НДС), основанные на количестве процессоров и ядер, приведены в таблице ниже.


Повышение цен в связи с затратами на лицензию Plesk
Редактор Plesk уже повысил цены еще в январе 2021 года, и в то время мы не позволяли этому повлиять на наше предложение. Однако 1 января 2022 года произойдет еще одно повышение цен, и на этот раз мы соответствующим образом скорректируем наши цены.


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

С наилучшими пожеланиями,
Команда Scaleway.

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

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

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

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

www.scaleway.com/en/docs/

www.scaleway.com/en/dedibox/pricing/?new=true&offered-setup-fees=true

После недавних событий ЕС-США. инициативы, объявленные президентом Джо Байденом, касающиеся технологий и трансатлантической торговли, статус этих двух сторон может быть поставлен под сомнение. Они друзья или враги? Более того, что возобладает: господство или «совместная конкуренция»? Когда дело доходит до технологий, в частности, это не игра с нулевой суммой, и обе стороны могут проиграть Китаю Си Си, если не будет принято совместное видение.

США, которые мы знаем сегодня, сильно отличаются от США, которые привлекали людей со всего мира как новая страна, полная жизненных сил и перспектив. Слова «свобода», «предпринимательская свобода» и «равенство» могут показаться нам знакомыми, но именно они вдохновили европейцев оставить все позади. Мужчины и женщины пересекли океан, зная, что они станут частью новой эры — они осознали, что в их силах изменить свою жизнь.

Двести сорок пять лет спустя США перестали быть новой страной. На протяжении веков он взял на себя роль сверхдержавы. Сегодня здесь зародилась цифровая эра, но те же самые ценности, которые когда-то были священными, теперь находятся под угрозой. Бесспорное технологическое лидерство США ставит своих исторических партнеров в невыносимое положение подчинения. Обновление понятий «независимость», «стратегическая автономия» и «свобода» теперь может исходить из старой Европы.

Чтобы обрести независимость, США устроили революцию. С другой стороны, послевоенная Европа прибегла к регулированию.

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

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

Голосуя за Общий регламент защиты данных (GDPR), Закон о цифровых рынках (DMA) и Закон о цифровых услугах (DSA), Европа стремилась указать, что пришло время обновить стандарты конфиденциальности, скорректировать правила конкуренции и вернуть власть своим гражданам. Намерение никогда не заключалось в том, чтобы вступать в боевые действия. Законодатели США наверняка последуют их примеру.

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

Недавний американо-европейский саммит и совместный ЕС-США. заявление о возобновлении трансатлантического партнерства официально поставило нас на этот путь.

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

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

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

Исследование 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 без необходимости дополнительной настройки.