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

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

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

Итак, что мы предлагаем:
— Всем пользователям виртуального хостинга — 13% скидка при пополнении баланса на год или два года по любому тарифу;

— Всем пользователям Виртуального хостинга, кто давно хотел прокачать свои проекты по мощности, а также всем нашим пользователям ВПС мы предлагаем — 25% скидку на приобретение новой VPS на данные конфигурации:

25 июля 2022 внесли изменения в документ «Условия использования отдельных сервисов: Предоставление облачного хранилища», где термин «Облачное хранилище» изменился на «Объектное хранилище».

Новое наименование будет отражено в отчетных документах, на сайте и в панели управления.

Условия использования сервиса и предоставление услуги остаются прежними.
Изменения вступают в силу с 1 августа 2022 г.

Данное уведомление носит информационный характер и не требует каких-либо действий.

В прошлом месяце Google объявила о пятилетнем обязательстве в размере 1,2 миллиарда долларов США перед Латинской Америкой для расширения цифровой инфраструктуры, поддержки цифровых навыков, развития предпринимательской экосистемы и помощи в создании инклюзивных и устойчивых сообществ. Чтобы развить эти инициативы и удовлетворить растущий спрос на облачные сервисы во всем мире, мы рады сообщить, что в Мексике появится новый регион Google Cloud.

Когда он будет запущен, этот новый облачный регион станет нашим третьим в Латинской Америке, присоединившись к Сантьяго, Чили, и Сан-Паулу, Бразилия, среди 34 регионов и 103 зон, которые в настоящее время работают по всему миру, обеспечивая высокопроизводительное облако с низкой задержкой. обслуживание клиентов всех размеров и отраслей. Это поможет поддержать цифровую трансформацию предприятий, облачных компаний и организаций государственного сектора.

«Мы очень рады объявлению о новом облачном регионе в Мексике. Это свидетельствует о приверженности Google Cloud своим клиентам», — сказал Антонио Гичард Гонсалес, исполнительный директор по цифровым технологиям Liverpool. «В Ливерпуле мы продолжим работать с Google Cloud, чтобы найти решения наших самых больших проблем и расширить наши цифровые возможности».

«Облачный регион в Мексике откроет новые возможности для использования облачных технологий организациями государственного сектора страны. Различные государственные организации выиграют от эффективного и безопасного взаимодействия, облегчая доступ к вычислительной мощности и информационным технологиям. Важно отметить, что компьютерные разработки в Мексике являются узкоспециализированными, поэтому они могут стать важным ориентиром для других испаноязычных стран», — заявил д-р Хуан Карлос Сармьенто Товилла, генеральный директор по информационным системам Федерального суда административной юстиции.

Франсиско Марта, генеральный директор по развитию цифрового бизнеса в Grupo Financiero Banorte, добавил: «Для Banorte это, несомненно, важная веха, которая позволит нам ускорить нашу цифровую трансформацию и активизировать инициативы, которые мы изучаем с помощью Google Cloud в рамках нормативно-правовой базы. Для Мексики это поворотный момент в процессе оцифровки, который мы уже наблюдаем у многих наших клиентов, партнеров и поставщиков».

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

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

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

Создание среды для совместной работы. В современной гибридной рабочей среде Google Cloud предоставляет инструменты, необходимые для изменения того, как люди подключаются, создают и сотрудничают.

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

Построение более чистого и устойчивого будущего: с 2007 года компания Google придерживается нулевого уровня выбросов углерода, и мы работаем над достижением революционной цели — полностью перейти на безуглеродную энергию к 2030 году. Сегодня, когда клиенты используют Google Cloud — самое чистое облако в мире, промышленность — их рабочие нагрузки уже соответствуют 100% возобновляемой энергии. Мы помогаем клиентам обезуглероживать свои приложения и инфраструктуру с помощью таких технологий, как Carbon Footprint и Active Assist.

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

Этот облачный регион станет последней инвестицией в поддержку цифровой трансформации мексиканских организаций. В прошлом году мы открыли центр поддержки для поддержки местных компаний, а также глобальных компаний, работающих в Мексике. Мы также открыли центр доставки и увеличили нашу команду в Монтеррее для поддержки местной экосистемы. Между тем, с помощью таких инициатив, как Capacita+, Grow with Google for Women in STEM и учебных программ на юго-востоке страны, мы работаем над развитием цифровых навыков и возможностей обучения для технологов в Мексике.

Узнайте больше о нашей глобальной облачной инфраструктуре, включая новые и перспективные регионы.
cloud.google.com/infrastructure

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

Поскольку разработчики, заботящиеся о безопасности, стремятся установить меры безопасности и уменьшить уязвимости, Akamai Linode Cloud рада добавить уровень защиты. Он предлагает возможности тестирования и конфигурации, поддерживаемые Kali Linux в виде стандартного дистрибутива, развернутого на любом вычислительном экземпляре, или приложения Marketplace, которое включает пользовательский интерфейс Kali и полный набор инструментов.

Кали Линукс Дистрибутив
Дистрибутив Kali, доступный на Linode, представляет собой облегченный дистрибутив Linux, который позволяет разработчикам более широко включать Kali в свои технические стеки. Kali основана на Debian Testing, что делает ее стабильной, современной и удобной платформой. Пользовательский интерфейс по умолчанию, доступный для Kali, представляет собой хорошо настраиваемый и проверенный временем XFCE, который использует меньше ресурсов, чем более графически интенсивные среды рабочего стола, такие как GNOME или KDE Plasma.

www.linode.com/marketplace/apps/kali-linux/kali-linux/

Когда разработчики развертывают рабочую нагрузку на платформе облачных вычислений, они часто не задумываются о базовом оборудовании, на котором работают их службы. В идеализированном образе «облака» обслуживание оборудования и физические ограничения невидимы. К сожалению, оборудование иногда нуждается в обслуживании, что может привести к простоям. Чтобы не перекладывать эти простои на наших клиентов и соответствовать обещаниям облака, Linode внедряет инструмент под названием Live Migrations.

Live Migrations — это технология, которая позволяет экземплярам Linode перемещаться между физическими машинами без прерывания обслуживания. Когда Linode перемещается с помощью Live Migrations, переход невидим для процессов этого Linode. Если оборудование хоста нуждается в обслуживании, Live Migration можно использовать для беспрепятственного переноса всех линодов этого хоста на новый хост. После завершения этой миграции физическое оборудование может быть отремонтировано, и время простоя не повлияет на наших клиентов.

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

Как работают живые миграции

Live Migration в Linode начинались, как и большинство новых проектов; с большим количеством исследований, серией прототипов и помощью многих коллег и менеджеров. Первым шагом вперед было изучение того, как QEMU обрабатывает Live Migration. QEMU — это технология виртуализации, используемая Linode, а Live Migrations — это функция QEMU. В результате наша команда сосредоточилась на том, чтобы внедрить эту технологию в Linode, а не изобретать ее.

Итак, как же работает технология Live Migration в том виде, в котором она реализована в QEMU? Ответ состоит из четырех шагов:

• Целевой экземпляр qemu запускается с точно такими же параметрами, которые существуют в исходном экземпляре qemu.
• Диски прошли Live Migration. О любых изменениях на диске также сообщается во время выполнения этой передачи.
• Оперативная память перенесена в реальном времени. Любые изменения в страницах ОЗУ также должны быть сообщены. Если на этом этапе также произойдут какие-либо изменения дисковых данных, эти изменения также будут скопированы на диск целевого экземпляра QEMU.
• Точка переключения выполнена. Когда QEMU определяет, что в ОЗУ недостаточно страниц, которые он может уверенно сократить, исходный и конечный экземпляры QEMU приостанавливаются. QEMU копирует последние несколько страниц ОЗУ и состояние машины. Состояние машины включает в себя кэш ЦП и следующую инструкцию ЦП. Затем QEMU указывает приемнику начать передачу, и приемник продолжает работу с того места, на котором остановился источник.
• Эти шаги объясняют, как выполнить динамическую миграцию с помощью QEMU на высоком уровне. Однако указание точного способа запуска целевого экземпляра QEMU — очень ручной процесс. Кроме того, каждое действие в процессе должно быть начато в нужное время.

Как в Linode реализованы живые миграции
Посмотрев на то, что разработчики QEMU уже создали, как мы можем использовать это в Linode? Ответ на этот вопрос заключается в том, где была основная часть работы для нашей команды.

В соответствии с шагом 1 рабочего процесса Live Migration целевой экземпляр QEMU запускается для принятия входящего Live Migration. При реализации этого шага первой мыслью было взять профиль конфигурации текущего Linode и запустить его на целевой машине. Теоретически это было бы просто, но если подумать об этом, то можно обнаружить более сложные сценарии. В частности, профиль конфигурации сообщает вам, как загрузился Linode, но он не обязательно описывает полное состояние Linode после загрузки. Например, пользователь мог подключить устройство блочного хранения, подключив его к Linode после его загрузки, и это не будет задокументировано в профиле конфигурации.

Чтобы создать экземпляр QEMU на целевом хосте, необходимо было получить профиль работающего в данный момент экземпляра QEMU. Мы профилировали этот запущенный в данный момент экземпляр QEMU, проверив интерфейс QMP. Этот интерфейс дает нам информацию о том, как устроен экземпляр QEMU. Он не предоставляет информацию о том, что происходит внутри экземпляра с точки зрения гостя. Он сообщает нам, куда подключаются диски и в какой виртуализированный слот PCI подключаются виртуальные диски, как для локального SSD, так и для блочного хранилища. После запроса QMP и проверки экземпляра QEMU создается профиль, точно описывающий, как воспроизвести эту машину в месте назначения.

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

На этом этапе мы должны сделать перерыв в документировании Live Migration и переключиться на объяснение того, как QEMU достигает этих целей. Дерево процессов QEMU состоит из управляющего процесса и нескольких рабочих процессов. Один из рабочих процессов отвечает за такие вещи, как возврат вызовов QMP или обработка Live Migration. Другие процессы сопоставляются один к одному с гостевыми процессорами. Среда гостя изолирована от этой стороны QEMU и ведет себя как отдельная независимая система.

В этом смысле мы работаем с тремя слоями:

• Уровень 1 — это наш уровень управления;
• Уровень 2 — это часть процесса QEMU, которая обрабатывает все эти действия за нас; а также
• Уровень 3 — это фактический гостевой уровень, с которым взаимодействуют пользователи Linode.

После того, как место назначения загружено и готово принять входящую миграцию, целевое оборудование сообщает исходному оборудованию, что источник должен начать отправку данных. Источник запускается, как только он получает этот сигнал, и мы сообщаем QEMU в программном обеспечении, чтобы начать миграцию диска. Программное обеспечение автономно отслеживает ход работы с диском, чтобы проверить, когда он будет завершен. Затем программное обеспечение автоматически переключается на миграцию ОЗУ, когда диск заполнен. Затем программное обеспечение снова автономно отслеживает миграцию ОЗУ, а затем автоматически переключается в режим переключения, когда миграция ОЗУ завершена. Все это происходит в сети Linode со скоростью 40 Гбит/с, поэтому сетевая сторона работает довольно быстро.

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

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

• Время останавливается по словам гостя. Если гость использует службу синхронизации времени, такую ​​как сетевой протокол времени (NTP), то NTP автоматически повторно синхронизирует время после завершения динамической миграции. Это связано с тем, что системные часы будут отставать на несколько секунд.
• Сетевые запросы прекращаются. Если эти сетевые запросы основаны на TCP, например, SSH или HTTP, потери подключения не будет. Если эти сетевые запросы основаны на UDP, например, потоковое видео в реальном времени, это может привести к потере нескольких кадров.

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

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

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

Вот некоторые из областей, где встречались пограничные случаи:

• Необходимо было создать внутренний инструментарий для организации Live Migration для групп поддержки клиентов и эксплуатации оборудования Linode. Это было похоже на другие существующие инструменты, которые у нас были и которые мы использовали в то время, но настолько отличались, что для его создания потребовались большие усилия по разработке:
• Этот инструмент должен автоматически просматривать весь парк оборудования в центре обработки данных и выяснять, какой хост должен быть местом назначения для каждого линода Live Migrated. Соответствующие характеристики при выборе этого варианта включают доступное пространство для хранения SSD и распределение оперативной памяти.
• Физический процессор конечной машины должен быть совместим с входящим Linode. В частности, ЦП может иметь функции (также называемые флагами ЦП), которые может использовать пользовательское программное обеспечение. Например, одной из таких функций является aes, которая обеспечивает шифрование с аппаратным ускорением. ЦП места назначения для динамической миграции должен поддерживать флаги ЦП исходного компьютера. Это оказалось очень сложным пограничным случаем, и в следующем разделе описывается решение этой проблемы.
• Изящная обработка случаев сбоев, включая вмешательство конечного пользователя или потерю сети во время динамической миграции. Эти случаи сбоев перечислены более подробно в следующем разделе этого поста.

Идти в ногу с изменениями в платформе Linode, что является непрерывным процессом. Для каждой функции, которую мы поддерживаем на Linodes сейчас и в будущем, мы должны убедиться, что эта функция совместима с Live Migrations. Эта задача описана в конце этого поста.
Флаги ЦП
В QEMU есть разные варианты представления процессора гостевой операционной системе. Один из этих вариантов — передать номер модели и функции центрального ЦП (также называемые флагами ЦП) непосредственно гостю. Выбрав эту опцию, гость может использовать всю необремененную мощность, которую позволяет система виртуализации KVM. Когда KVM впервые был принят Linode (что предшествовало Live Migrations), этот параметр был выбран, чтобы максимизировать производительность. Однако позже это решение вызвало множество проблем во время разработки Live Migrations.


В тестовой среде для Live Migration исходный и конечный хосты были двумя идентичными машинами. В реальном мире наш парк аппаратного обеспечения не на 100% одинаков, и между машинами существуют различия, которые могут привести к появлению разных флагов ЦП. Это важно, потому что, когда программа загружается в операционную систему Linode, Linode представляет этой программе флаги ЦП, и программа загружает определенные разделы программного обеспечения в память, чтобы использовать эти флаги. Если Linode переносится в режиме реального времени на конечный компьютер, который не поддерживает эти флаги ЦП, программа аварийно завершает работу. Это может привести к сбою гостевой операционной системы и перезагрузке Linode.

Мы обнаружили три фактора, которые влияют на то, как флаги процессора машины представляются гостям:

• Существуют незначительные различия между ЦП, зависящие от того, когда ЦП был приобретен. ЦП, приобретенный в конце года, может иметь другие флаги, чем приобретенный в начале года, в зависимости от того, когда производители ЦП выпускают новое оборудование. Linode постоянно покупает новое оборудование для увеличения мощности, и даже если модель ЦП для двух разных аппаратных заказов одинакова, флаги ЦП могут различаться.
• Разные ядра Linux могут передавать в QEMU разные флаги. В частности, ядро ​​Linux для исходного компьютера Live Migration может передавать в QEMU флаги, отличные от флагов ядра Linux на целевом компьютере. Обновление ядра Linux на исходном компьютере требует перезагрузки, поэтому это несоответствие нельзя устранить путем обновления ядра перед выполнением динамической миграции, поскольку это приведет к простою линодов на этом компьютере.
• Точно так же разные версии QEMU могут влиять на то, какие флаги ЦП будут представлены. Обновление QEMU также требует перезагрузки машины.

Таким образом, Live Migration необходимо было реализовать таким образом, чтобы предотвратить сбои программы из-за несоответствия флагов CPU. Доступны два варианта:

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

• Первый способ более простой из двух. Все флаги ЦП отправляются от источника к целевому оборудованию. Когда целевое оборудование настраивает новый экземпляр qemu, оно проверяет, установлены ли как минимум все флаги, которые присутствовали на исходном Linode. Если они не совпадают, динамическая миграция не выполняется.
• Второй метод намного сложнее, но он может предотвратить неудачные миграции, возникающие в результате несоответствия флагов ЦП. Перед запуском Live Migration мы создаем список оборудования с совместимыми флагами ЦП. Затем из этого списка выбирается целевая машина.
• Второй метод нужно выполнять быстро, и он очень сложен. В некоторых случаях нам нужно проверить до 226 флагов ЦП на более чем 900 машинах. Написать все эти 226 проверок флагов ЦП было бы очень сложно, и их нужно было бы поддерживать. В конечном итоге эта проблема была решена благодаря удивительной идее, предложенной основателем Linode Крисом Акером.

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

>>> 1 & 1
1
>>> 2 & 3
2
>>> 1 & 3
1

Чтобы понять, почему побитовая операция and дает такие результаты, полезно представить числа в двоичном формате. Давайте рассмотрим побитовую операцию и операцию для чисел 2 и 3, представленных в двоичном виде:

>>> # 2: 00000010
>>> # &
>>> # 3: 00000011
>>> # =
>>> # 2: 00000010

Побитовая операция and сравнивает двоичные цифры или биты двух разных чисел. Начиная с самой правой цифры в приведенных выше числах, а затем влево:

Самые правые/первые биты 2 и 3 равны 0 и 1 соответственно. Побитовое и результат для 0 и 1 равен 0.
Второй крайний правый бит 2 и 3 равен 1 для обоих чисел. Побитовое и результат для 1 и 1 равен 1.
Все остальные биты для этих чисел равны 0, а побитовый результат для 0 и 0 равен 0.
Тогда двоичное представление полного результата будет 00000010, что равно 2.

Для Live Migration полный список флагов ЦП представлен в виде двоичной строки, где каждый бит представляет собой отдельный флаг. Если бит равен 0, то флаг отсутствует, а если бит равен 1, то флаг присутствует. Например, один бит может соответствовать флагу aes, а другой бит может соответствовать флагу mmx. Конкретные позиции этих флагов в двоичном представлении поддерживаются, документируются и используются машинами в наших центрах обработки данных.

Поддерживать это представление списка намного проще и эффективнее, чем поддерживать набор операторов if, которые гипотетически проверяли бы наличие флага процессора. Например, предположим, что всего нужно отследить и проверить 7 флагов ЦП. Эти флаги могут быть сохранены в 8-битном числе (один бит остается для будущего расширения). Пример строки может выглядеть так: 00111011, где крайний правый бит показывает, что aes включен, второй крайний правый бит показывает, что включен mmx, третий бит указывает, что другой флаг отключен, и так далее.

Как показано в следующем фрагменте кода, мы можем увидеть, какое оборудование будет поддерживать эту комбинацию флагов, и вернуть все совпадения за один цикл. Если бы мы использовали набор операторов if для вычисления этих совпадений, для достижения этого результата потребовалось бы гораздо большее количество циклов. Для примера Live Migration, когда на исходной машине присутствуют 4 флага ЦП, потребуется 203 400 циклов, чтобы найти подходящее оборудование.

Код Live Migration выполняет побитовую операцию и над строками флагов ЦП на исходном и целевом компьютерах. Если результат равен строке флага ЦП исходной машины, то целевая машина совместима. Рассмотрим этот фрагмент кода Python:

>>> # The b'' syntax below represents a binary string
>>>
>>> # The s variable stores the example CPU flag 
>>> # string for the source:
>>> s = b'00111011'
>>> # The source CPU flag string is equivalent to the number 59:
>>> int(s.decode(), 2)
59
>>> 
>>> # The d variable stores the example CPU flag 
>>> # string for the source:
>>> d = b'00111111'
>>> # The destination CPU flag string is equivalent to the number 63:
>>> int(d.decode(), 2)
63
>>>
>>> # The bitwise and operation compares these two numbers:
>>> int(s.decode(), 2) & int(d.decode(), 2) == int(s.decode(), 2)
True
>>> # The previous statement was equivalent to 59 & 63 == 59.
>>>
>>> # Because source & destination == source, 
>>> # the machines are compatible

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

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

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

Много времени уходит на то, чтобы программное обеспечение «просто работало…

Случаи отказа
Одна функция, о которой не очень часто говорят в программном обеспечении, — это изящная обработка случаев сбоя. Программное обеспечение должно «просто работать». Много времени на разработку уходит на то, чтобы программное обеспечение «просто работало», и это в значительной степени относится к Live Migrations. Много времени было потрачено на обдумывание всех способов, в которых этот инструмент не мог работать, и изящное решение этих случаев. Вот некоторые из этих сценариев и способы их решения:

Что произойдет, если клиент захочет получить доступ к функции своего Linode из Cloud Manager? Например, пользователь может перезагрузить Linode или подключить к нему том блочного хранилища.

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

Что произойдет, если целевой Linode не загрузится?

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

Что произойдет, если вы потеряете сеть во время миграции?

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

Что произойдет, если остальная часть Интернета отключится, но исходное и целевое оборудование все еще работает и обменивается данными, а исходный или целевой Linode работает нормально?

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

Идти в ногу с изменениями
После сотен тысяч успешных живых миграций иногда задают вопрос: «Когда выполняется живая миграция?» Live Migrations — это технология, использование которой со временем расширяется и которая постоянно совершенствуется, поэтому отметить завершение проекта не всегда просто. Один из способов ответить на этот вопрос — подумать, когда будет завершена основная часть работы по этому проекту. Ответ таков: для надежного, безотказного программного обеспечения работа не выполняется в течение длительного времени.

Поскольку со временем для Linodes разрабатываются новые функции, необходимо проделать работу, чтобы обеспечить совместимость этих функций с Live Migrations. При внедрении некоторых функций не требуется никаких новых разработок для Live Migrations, и нам нужно только проверить, что Live Migrations по-прежнему работает должным образом. Для других работа по обеспечению совместимости Live Migration отмечена как задача на раннем этапе разработки новых функций.

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

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

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

В течение этого года мы расширили линейку серверов Bare Metal новыми конфигурациями на базе процессоров Intel Xeon Rocket Lake и AMD EPYC 3-го поколения Milan. Мы хотели подчеркнуть наше недавнее введение этих планов, предназначенных для удовлетворения потребности в скорости — и все это по доступным ценам.



Конфигурация Intel E-2388G хорошо подходит для приложений с интенсивными вычислениями, которым требуется сетевая производительность с низкой задержкой — такие рабочие нагрузки, как потоковое видео и игры. E-2388G обеспечивает значительно более высокую общую производительность, чем предыдущий ЦП (E-2288G). Эта конфигурация в настоящее время доступна в Амстердаме, Атланте, Лондоне, Майами, Нью-Джерси, Силиконовой долине, Сингапуре, Сиднее и Токио — еженедельно добавляются новые местоположения.

Конфигурации с AMD EPYC 7543P обладают огромной вычислительной мощностью. Они хорошо подходят для запуска ваших собственных виртуальных машин или больших баз данных, которые могут в полной мере использовать преимущества молниеносно быстрого хранилища NVMe SSD этих серверов. 24-ядерная версия 7543P также идеально подходит для инфраструктуры блокчейна. В настоящее время мы развертываем серверы с процессором AMD EPYC 7543P, и если вы заинтересованы в его размещении в определенном месте, просто сообщите нам об этом.

http://www.vultr.com

Мы в Vultr гордимся тем, что делаем облачную инфраструктуру доступной для всех — разработчиков, малых и средних предприятий и крупных предприятий. Это желание снизить цены привело нас к созданию Vultr Talon, революционной платформы, которую мы представляем сегодня в бета-версии. С Vultr Talon мы теперь предлагаем лучшие в своем классе виртуализированные графические процессоры, начиная с графического процессора с тензорными ядрами NVIDIA A100, по цене в несколько раз дешевле полноценного графического процессора. Vultr — первый поставщик облачных услуг, предлагающий виртуализацию графических процессоров NVIDIA A100 для обеспечения совместного использования графических процессоров и обеспечения оптимального использования ресурсов.

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

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

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

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

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

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

Виртуализация графического процессора NVIDIA A100 в облаке, обеспечивающая эффективные вычисления и снижающая затраты на ИИ

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

Используя наш опыт в области виртуализации и облачной инфраструктуры, мы стремились перевернуть модель предоставления GPU с ног на голову. Вместо того, чтобы предлагать целые физические графические процессоры по менее доступным ценам, мы стремились обеспечить совместное использование графических процессоров с помощью виртуализации всего за небольшую часть стоимости. Работая в тесном сотрудничестве с NVIDIA, мы разработали платформу Vultr Talon на базе графических процессоров NVIDIA и программного обеспечения NVIDIA AI Enterprise, которую мы представляем в сегодняшней бета-версии.

Изменившая мир технология графических процессоров NVIDIA теперь доступна по цене от 90 долларов в месяц или всего 0,13 доллара в час.

В основе Vultr Talon лежит современная платформа виртуализации графических процессоров NVIDIA. Вместо того, чтобы подключать целые физические графические процессоры к виртуальным машинам, мы подключаем только часть в виде виртуального графического процессора (vGPU). Виртуальные графические процессоры работают на базе NVIDIA AI Enterprise, которая включает программное обеспечение NVIDIA vGPU и оптимизирована для удаленного выполнения рабочих нагрузок ИИ и высокопроизводительного анализа данных.

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

Vultr Talon использует технологию NVIDIA Multi-Instance GPU для виртуальных машин с объемом памяти GPU не менее 10 ГБ, что повышает ценность производительности за счет предоставления арендаторам гарантированного QoS, полностью изолированной памяти GPU с высокой пропускной способностью, кэш-памяти и выделенных вычислительных ядер.

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



Части NVIDIA A100 всего от 90 долларов в месяц
Графический процессор NVIDIA A100 с тензорными ядрами обеспечивает невероятное ускорение для глубокого обучения, высокопроизводительных вычислений (HPC) и анализа данных. Благодаря технологическим прорывам в архитектуре NVIDIA Ampere, таким как тензорные ядра третьего поколения, точность TensorFloat-32 (TF32) и структурная разреженность, NVIDIA A100 обеспечивает унифицированный ускоритель рабочих нагрузок для анализа данных, обучения ИИ, вывода ИИ и высокопроизводительных вычислений.

В сочетании с программным пакетом NVIDIA AI Enterprise, который оптимизирован для разработки и развертывания ИИ и сертифицирован для работы в виртуализированных средах, NVIDIA A100 ускоряет работу всех основных сред глубокого обучения и анализа данных, таких как TensorFlow и PyTorch, а также более 700 приложений HPC.

Облачные экземпляры с одним или несколькими физическими графическими процессорами обычно продаются за тысячи долларов в месяц. Напротив, сегодня мы представляем набор планов Vultr, которые дают вам часть графического процессора NVIDIA A100 с тензорными ядрами, а также выделенные виртуальные ЦП, ОЗУ, хранилище и пропускную способность по цене от 90 долларов в месяц или 0,13 доллара в час. Эти экземпляры позволяют выделять ресурсы графического процессора с большей степенью детализации и предоставляют разработчикам оптимальный объем ускоренных вычислений.



Прямо сейчас в нашей панели управления вы можете предоставить инстансы GPU с широким спектром спецификаций.

Что вы можете делать с виртуализированным графическим процессором NVIDIA A100 с тензорными ядрами?

Планы Vultr с графическим процессором NVIDIA A100 и программным обеспечением NVIDIA AI Enterprise подходят для широкого спектра сценариев использования в производстве и разработке. В частности, мы рекомендуем их для рабочих нагрузок вывода ML и построения моделей для обработки естественного языка, распознавания голоса и компьютерного зрения.

В дополнение к пакету программного обеспечения NVIDIA AI Enterprise, NVIDIA также предлагает каталог NGC, центр дополнительного программного обеспечения для искусственного интеллекта и высокопроизводительных вычислений, оптимизированного для графических процессоров. NGC включает в себя контейнеры корпоративного уровня, фреймворки, предварительно обученные модели, диаграммы Helm и отраслевые комплекты разработки программного обеспечения (SDK) для специалистов по данным, разработчиков и команд DevOps, чтобы быстрее создавать и развертывать свои решения. С помощью NGC разработчики могут развертывать оптимизированные по производительности программные контейнеры AI/HPC, предварительно обученные модели AI и ноутбуки Jupyter, которые ускоряют разработку AI и рабочие нагрузки HPC в любых локальных, облачных и пограничных системах с GPU.

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

Графический процессор Bare Metal для больших рабочих нагрузок
Если вы хотите выполнить рабочую нагрузку, требующую нескольких физических графических процессоров, у нас также есть серверы Bare Metal с четырьмя графическими процессорами NVIDIA A100 и двумя 24-ядерными процессорами Intel Xeon.

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

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

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

http://www.vultr.com

Обращаем ваше внимание, что 20 августа будут изменены цены на тарифные планы хостинга линейки SSD. Новые стоимости тарифов уже указаны на странице: hoster.ru/price
Новая стоимость тарифов будет распространяться на заказ новых аккаунтов хостинга и на продление существующих. Просим учитывать изменение цен при пополнении баланса лицевого счета.

Собираетесь на VMware Explore 2022?
Лучшие специалисты в области мультиоблачной вселенной соберутся на выставке VMware Explore 2022 в Сан-Франциско. OVHcloud гордится тем, что является серебряным спонсором!

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

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

Еще есть время зарегистрироваться на этот вебинар серии экспертов, чтобы узнать:

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

events.actualtechmedia.com/register-now/1003/ransomware-series-the-realities-of-remote-workers-and-ransomware-risk/