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



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

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

Удовлетворение высокого спроса в Сингапуре
С тех пор как мы изначально расширили наши облачные вычислительные сервисы в Сингапуре как Linode почти 10 лет назад, мы увидели монументальный рост в регионе, что привело нас к запуску дополнительных основных регионов, включая Сидней, Мельбурн и Джакарту. Расширение нашего присутствия позволяет нам предлагать новые аппаратные классы клиентам с рабочими нагрузками в Сингапуре, поскольку он продолжает служить центральным узлом облачных вычислений в Азии.

Расширение в Мумбаи (in-bom-2) и расширение в Сингапуре (sg-sin-2) оснащены новым вычислительным и сетевым оборудованием, доступностью экземпляров ЦП Premium и полностью оснащены бесплатными основными инструментами, включая частную сеть с VPC, настраиваемую сетевую безопасность с облачным брандмауэром и поддержку метаданных cloud-init.

Новые основные вычислительные регионы: расширение в Лондоне и Мельбурне уже доступны



Спрос на высокопроизводительные облачные вычисления с предсказуемыми ценами продолжает расти, в том числе для наших собственных рабочих нагрузок Akamai. После запуска Madrid в начале этого года мы продолжаем наш общий проект расширения, чтобы обеспечить увеличение вычислительной мощности, работающей на совершенно новом оборудовании, в ключевых регионах. Наши последние сайты включают расширение нашего присутствия в регионе с высоким спросом и развертывание нашего второго основного региона в Австралии. London 2 и Melbourne теперь доступны для всех клиентов.

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

Как построить шлюз NAT в VPC с помощью Linode

Один из наших клиентов, который обрабатывает конфиденциальные данные клиентов, нуждался в безопасной облачной инфраструктуре для своих веб-приложений и баз данных. Мы внедрили шлюз NAT в VPC, чтобы разрешить экземплярам в частных подсетях доступ в Интернет для обновлений и вызовов API, блокируя входящий трафик. Это решение обеспечивает доступ в Интернет частным экземплярам, ​​не раскрывая их напрямую в публичном Интернете, что повышает безопасность. Вот что мы сделали:

На этой схеме показана типичная настройка VPC, разделенная на три основных раздела: VPC, публичная подсеть и частная подсеть. Сначала у нас есть внешний зеленый блок, VPC, который изолирует ресурсы внутри него от других сетей. Пользователи получают доступ к веб-серверу через публичный Интернет, используя статический IP-адрес, назначенный через 1:1 NAT. Веб-сервер обрабатывает запросы и, при необходимости, связывается с сервером базы данных. Веб-сервер связывается с сервером базы данных через сервер маршрутизатора. Сервер маршрутизатора использует пользовательский NAT для безопасной маршрутизации трафика между публичной и частной подсетями. Сервер базы данных, расположенный в частной подсети, получает запросы от веб-сервера через VLAN. Изоляция частной подсети гарантирует, что сервер базы данных не будет напрямую открыт для Интернета, что повышает безопасность. В этом руководстве мы рассмотрим шаги по настройке этой архитектуры, обеспечивающие безопасную и эффективную связь между частной и публичной подсетями. Мы создадим VPC с публичной и частной подсетями, настроим шлюз NAT и настроим VLAN.

Учебник
В этом уроке мы создадим шлюз NAT в VPC, как на схеме, которую мы только что рассмотрели.
www.linode.com/blog/networking/how-to-build-a-nat-gateway-in-a-vpc-with-linode/

2022-2023 EX Linode update


  • Расширение европейского региона: живите в Амстердаме
  • Развертывание услуг облачных вычислений Akamai в Южной Америке
  • Объявление о расширении Азиатско-Тихоокеанского региона основных вычислений вместе с Джакартой
  • Расширение региона основных вычислений в Милане и Осаке
  • Развертывание рабочих нагрузок в Сиэтле (новый регион вычислительного ядра)
  • Akamai открывает новейшую площадку облачных вычислений в Стокгольме
  • Служба метаданных теперь доступна в открытой бета-версии

Смелый новый подход к облаку



С тех пор, как Akamai приобрела Linode в начале 2022 года, мы усердно работали над тем, чтобы объединить платформы под одной крышей. С анонсом Akamai Connected Cloud Linode теперь полностью интегрирована в бренд Akamai. В дальнейшем услуги Linode будут называться услугами облачных вычислений Akamai.

Что такое подключенное облако Akamai?
Akamai Connected Cloud — это широкораспределенная пограничная и облачная платформа для облачных вычислений, безопасности и доставки контента. Услуги облачных вычислений Akamai включают основные облачные службы вычислений, хранения, сети, базы данных и управления контейнерами, необходимые для создания, развертывания и защиты приложений и рабочих нагрузок везде, где компании подключаются к сети. Службы облачных вычислений, работающие в Akamai Connected Cloud, позволяют компаниям распределять рабочие нагрузки и приложения по всему вычислительному континууму — от ядра до периферии — для решения проблем, связанных с затратами, производительностью и масштабированием, с которыми сегодня сталкиваются централизованные платформы облачных вычислений.

Расширение нашей миссии
Миссия Linode заключалась в ускорении инноваций за счет упрощения и доступности облачных вычислений. Эта миссия продолжается как часть смелого нового видения Akamai, теперь с полным спектром услуг, которые нужны разработчикам, работающими на одной из самых распределенных облачных платформ в мире. Это также даст разработчикам доступ к:
  • Три новых основных центра облачных вычислений корпоративного масштаба в США и Европе. В дополнение к существующим 11 сайтам облачных вычислений новые сайты будут подключены к магистрали Akamai, соединяя их с самой распределенной пограничной сетью на планете. Они также станут шаблоном для 10 дополнительных основных сайтов, которые мы планируем развернуть по всему миру в течение года.
  • Более чем в 50 городах, в которых мы планируем начать развертывание распределенных площадок в этом году, чтобы перенести базовые возможности облачных вычислений в труднодоступные места, которые в настоящее время недостаточно обслуживаются традиционными поставщиками облачных услуг. Эти регионы предлагают подмножество сервисов облачных вычислений Akamai, но идентичны с точки зрения доступности и производительности.
  • Агрессивные новые цены на облачный исходящий трафик, которые используют мощность сети Akamai для снижения стоимости облачного исходящего трафика за счет внедрения экономики, подобной CDN, в облачную передачу данных. Новая модель ценообразования на исходящий трафик предназначена для значительного снижения тарифов на исходящий трафик по сравнению с гиперскейлерами и альтернативными поставщиками облачных услуг.
  • Соответствие новым стандартам ISO, SOC 2 и HIPAA доступно немедленно.
  • В течение следующих нескольких месяцев вы заметите некоторые косметические изменения в работе с Linode — например, увидите логотип Akamai там, где появился логотип Linode. Мы также работаем над улучшением общего потока между двумя сайтами, чтобы сохранить простоту, которую разработчики узнали из Linode, а также познакомить как разработчиков, так и предприятия с новыми сервисами, работающими в Akamai Connected Cloud. Со временем вы также заметите другие улучшения дизайна и взаимодействия с пользователем, основанные на нашей дорожной карте продукта. На данный момент никаких изменений в социальных каналах Linode нет, поэтому продолжайте использовать их для связи с нами.

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

Akamai Linode Cloud теперь поддерживает Kali Linux

Теперь мы поддерживаем 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

Когда разработчики развертывают рабочую нагрузку на платформе облачных вычислений, они часто не задумываются о базовом оборудовании, на котором работают их службы. В идеализированном образе «облака» обслуживание оборудования и физические ограничения невидимы. К сожалению, оборудование иногда нуждается в обслуживании, что может привести к простоям. Чтобы не перекладывать эти простои на наших клиентов и соответствовать обещаниям облака, 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, — это живые существа, которые будут продолжать развиваться.

Linode получает 2 награды Stevie Awards



Я рад сообщить, что четвертый год подряд компания Linode Support была удостоена награды Stevie Awards, получив две бронзовые награды. Каждая награда является для нас большим достижением — в каждой категории мы соревнуемся с некоторыми из крупнейших организаций мира, поэтому победа для нас особенно волнительна.

В этом году служба поддержки Linode получила бронзу в номинации «Отдел обслуживания клиентов года», что является признанием общей работы всей нашей команды службы поддержки. Мы также получили бронзовую награду в номинации «Лучшая инициатива по взаимодействию с клиентами» за наши усилия по взаимодействию с нашими клиентами на основе их отзывов.

Мы также снова имеем право выиграть «Приз зрительских симпатий за любимое обслуживание клиентов». Вы можете проголосовать за Линоде здесь. Мы были бы признательны, если бы вы уделили минутку и проголосовали за нашу команду сейчас (и каждый день до 1 апреля!).

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

Для нас большая честь быть неоднократным лауреатом премии Стиви среди других наград за обслуживание клиентов. Узнайте больше о том, как наши клиенты хвалят нашу команду поддержки клиентов на сайтах отзывов, таких как G2, Peerspot и TrustRadius.

Протокол пограничного шлюза и защита ваших линодов

Сегодня мы здесь, чтобы поговорить о протоколе пограничного шлюза (BGP) и недавнем шаге, который мы предприняли для его защиты в наших сетях. Некоторое время мы подписывали наши префиксы с помощью Route Origin Authorizations (ROA), но внедрили проверку маршрута на всех наших пограничных шлюзах по всему миру и теперь удаляем префиксы, недействительные для RPKI.

Чтобы понять это изменение, нам нужно понять, как работает протокол TCP. BGP — это один из протоколов, обеспечивающих работу Интернета. Интернет представляет собой обширную сеть сетей. Эти независимые сети имеют свои собственные диапазоны IP-адресов, предоставляемые региональными интернет-регистратурами (RIR). Эти диапазоны — это то, что BGP называет префиксами.

Затем эти префиксы группируются вместе в абстрактной системе, называемой автономной системой (AS), идентифицируемой номером, называемым номером автономной системы (ASN). Наконец, пограничный маршрутизатор каждой независимой сети, говорящий по протоколу BGP, называется равноправным узлом. Для работы BGP каждый узел обменивается информацией о маршрутизации со своими соседними узлами в форме объявлений префикса сети. Поскольку одноранговые узлы могут обмениваться всеми имеющимися у них маршрутами в зависимости от политики маршрутизации, AS не нужно напрямую подключаться к другой AS, чтобы узнать ее префиксы. В таком случае промежуточная AS служит транзитной AS, обмениваясь маршрутной информацией с пограничными AS.


Взлом BGP
Ложное объявление префиксов, которые никто не контролирует, преднамеренное или случайное, называется захватом BGP. Результатом чего являются различные типы атак, такие как DDoS, мониторинг, спам и многое другое.


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

Поскольку BGP обычно предпочитает кратчайшую длину пути AS, противник может предложить более короткую длину пути AS, чем законный владелец префикса. Другие атрибуты BGP также могут использоваться для предпочтения пути, но это поведение очень сильно зависит от политик маршрутизации ASN.
Злоумышленник должен объявить более конкретный префикс, чем тот, который может быть объявлен настоящей исходной AS. Перехват на основе длины префикса с большей вероятностью будет успешным, поскольку он не зависит от потенциально сложных политик BGP.
Хотя сложность атаки достаточно высока, чтобы такая атака была успешной, перехват BGP почти невозможно остановить без какой-либо формы авторизации. И здесь в игру вступает RPKI.

RPKI
Думайте о RPKI как о цифровых подписях; он подтверждает, что маршрутизаторы, говорящие по протоколу BGP, принимают только определенные автономные системы, которым разрешено создавать определенные префиксы. По сути, с помощью RPKI объявления о маршрутах BGP, выдаваемые маршрутизатором, могут быть подписаны и проверены на основе сертификата ROA, чтобы гарантировать, что маршрут исходит от держателя ресурсов и является допустимым маршрутом.

Когда в наших сетях включен RPKI, мы подписываем наши префиксы маршрутов с помощью ROA и удаляем объявления BGP из источников с недействительными подписями RPKI. Это действует как превентивная мера против многих угроз, связанных с перехватом BGP, включая DDoS, спам, фишинг, мониторинг данных и многое другое.

Мы делаем все возможное, чтобы сделать Интернет более безопасным. Чтобы узнать больше о RPKI, обратитесь к этой документации от ARIN.
www.arin.net/resources/manage/rpki/

NVMe в действии: когда следует переходить на хранилище NVMe



Облачное хранилище NVMe — когда-то прерогатива высокопроизводительных центров обработки данных и высокопроизводительных вычислительных установок — работает значительно быстрее, чем традиционные технологии блочного хранения. В то время как задержка жесткого диска обычно измеряется в миллисекундах, задержка NVMe измеряется в микросекундах. Многие современные накопители NVMe могут достигать задержки менее 20 микросекунд.

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

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

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

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

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

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

Теперь, когда появился NVMe, стоит внимательно посмотреть, что он может сделать для вашей сети. Компания Cloud Spectator недавно провела тесты известных крупных облачных провайдеров, которые доминируют на рынке облачных вычислений, и альтернативных облачных провайдеров, которые предлагают паритет основных облачных продуктов и глобальную доступность по конкурентоспособным ценам. Анализ включал Linode, Amazon Web Services, Microsoft Azure, Google Cloud Platform, Vultr и DigitalOcean. Все тесты проводились в дата-центре в Северной Америке для каждого провайдера.
www.linode.com/content/cloud-block-storage-benchmarks/