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/

Linode and Akamai



Я рад сообщить, что Linode заключила соглашение о приобретении Akamai.

Вы можете прочитать официальный пресс-релиз в нашем пресс-центре.

Если вы еще не знакомы с Akamai, они существуют с первых дней существования Интернета. Они изобрели CDN и управляют самой сложной в мире платформой доставки контента. За прошедшие годы они добавили в свое портфолио, среди прочего, решения для обеспечения безопасности и периферийных устройств мирового класса.

Как и Akamai, мы были пионерами в области облачных вычислений. Linode начала свою деятельность в квартире почти 20 лет назад и выросла в компанию из 256 человек, которая работает на 11 рынках и обслуживает клиентов в 185 странах. Мы заслужили доверие миллионов клиентов, ускорили внедрение инноваций, создали продукты мирового класса и создали Linode как настоящую альтернативу крупнейшим конкурентам в нашей отрасли.

Когда мы начали рассматривать нашу долгосрочную дорожную карту и то, как обеспечить наилучшее качество обслуживания клиентов, мы знали, что для этого потребуется больше — больше сети, больше безопасности, больше масштаба. Это то, что Акамай делает лучше всех. Приложения и данные все чаще перемещаются на периферию, где вам требуется более широкий диапазон отказоустойчивости, охвата, малой задержки и безопасности. Сочетание того, что хорошо делает Akamai, с тем, что хорошо делает Linode, объединяет их под одной крышей в массовом масштабе, создавая самую распределенную вычислительную платформу в мире — от ядра до периферии.

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

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

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

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

Akamai приобретет Linode



Akamai обсудит приобретение на телефонной конференции с финансовыми результатами за четвертый квартал и конец 2021 года сегодня, 15 февраля, в 16:30. ЕТ.

КЕМБРИДЖ, Массачусетс, 15 февраля 2022 г. — Akamai Technologies, Inc. (NASDAQ: AKAM), самое надежное в мире решение для поддержки и защиты цифровых технологий, сегодня объявила о заключении окончательного соглашения о приобретении Linode, одного из самые простые в использовании и пользующиеся наибольшим доверием поставщики платформ инфраструктуры как услуги (IaaS).

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

«Возможность объединить удобные для разработчиков возможности облачных вычислений Linode с ведущей на рынке граничной платформой и службами безопасности Akamai имеет большое значение для Akamai, — сказал д-р Том Лейтон, главный исполнительный директор и соучредитель Akamai Technologies. «Akamai уже более 20 лет является пионером в сфере граничных вычислений, и сегодня мы рады начать новую главу в нашей эволюции, создав уникальную облачную платформу для создания, запуска и защиты приложений от облака до периферии. Это большая победа для разработчиков, которые теперь смогут создавать приложения на платформе, обеспечивающей беспрецедентный масштаб, охват, производительность, надежность и безопасность».

Кристофер Акер, основатель и главный исполнительный директор Linode, добавил: «Мы запустили Linode 19 лет назад, чтобы сделать мощь облака проще и доступнее. Попутно мы создали платформу облачных вычислений, которой доверяют разработчики и компании по всему миру. Сегодня эти клиенты сталкиваются с новыми проблемами, поскольку облачные услуги становятся всеохватывающими, включая вычисления, хранение, безопасность и доставку от ядра до периферии. Решение этих проблем требует огромной интеграции и масштабирования, которые Akamai и Linode планируют объединить под одной крышей. Это знаменует новую захватывающую главу для Linode и важный шаг вперед для наших нынешних и будущих клиентов».

В соответствии с условиями соглашения Akamai согласилась приобрести все находящиеся в обращении акции компании с ограниченной ответственностью Linode примерно за 900 миллионов долларов после обычной корректировки покупной цены. В результате структурирования сделки как покупки активов Akamai рассчитывает добиться экономии денежных средств по налогу на прибыль в течение следующих 15 лет, чистая текущая стоимость которой оценивается примерно в 120 миллионов долларов. Ожидается, что сделка будет закрыта в первом квартале 2022 года и зависит от обычных условий закрытия.

Ожидается, что в 2022 финансовом году приобретение Linode добавит около 100 миллионов долларов дохода и немного увеличит прибыль на акцию не по GAAP примерно на 0,05–0,06 доллара. Akamai предоставит дополнительную информацию о Linode, а также финансовые результаты за четвертый квартал и конец 2021 года, а также прогнозы доходов на весь год по телефону сегодня, 15 февраля 2022 года, в 16:30. ЕТ.

Советники по сделке
PJT Partners выступала в качестве финансового консультанта, а WilmerHale выступала в качестве юрисконсульта Akamai. DH Capital выступала в качестве финансового консультанта, а Latham & Watkins выступала в качестве юридического советника Linode.

15 февраля, в 16:30
Akamai обсудит приобретение Linode во время телефонной конференции по финансовым результатам за четвертый квартал и конец 2021 года сегодня, 15 февраля 2022 года, в 16:30. По восточному времени. Звонок может включать перспективные финансовые рекомендации от руководства. Доступ к звонку можно получить по номеру (844) 578-9671 (или (508) 637-5655 для международных звонков) с использованием идентификационного номера конференции 7579719. Прямая веб-трансляция звонка и сопровождающие слайды доступны в разделе «Связи с инвесторами» на сайте www. .akamai.com. Кроме того, повтор звонка будет доступен в течение двух недель после конференции на веб-сайте Akamai или по телефону (855) 859-2056 (или (404) 537-3406 для международных звонков) с использованием идентификационного номера конференции 7579719.

Использование финансовых показателей не по GAAP
В дополнение к предоставлению финансовых показателей, основанных на общепринятых принципах бухгалтерского учета в Соединенных Штатах Америки (GAAP), Akamai предоставляет дополнительные финансовые показатели, которые не подготовлены в соответствии с GAAP (не GAAP). Руководство использует финансовые показатели, не относящиеся к GAAP, в дополнение к финансовым показателям GAAP, чтобы понять и сравнить операционные результаты за отчетные периоды, для принятия финансовых и операционных решений, для целей планирования и прогнозирования, для измерения вознаграждения руководителей и для оценки финансовых результатов Akamai. Финансовая мера non-GAAP, используемая в этом выпуске, представляет собой чистую прибыль non-GAAP на разводненную акцию.

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

Этот финансовый показатель не по GAAP не заменяет представление финансовых результатов Akamai по GAAP и должен использоваться только в качестве дополнения, а не вместо финансовых результатов Akamai, представленных в соответствии с GAAP. Для исторических показателей, не относящихся к GAAP, Akamai представила сверку всех финансовых показателей, не относящихся к GAAP, которые использовались в ее финансовой отчетности и презентациях для инвесторов, с наиболее сопоставимыми финансовыми показателями GAAP. Эти сверки можно найти под заголовком «Сверка GAAP с финансовыми показателями, не относящимися к GAAP» в разделе «Отношения с инвесторами» на веб-сайте Akamai.

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

Использование финансовых показателей не по GAAP
В дополнение к предоставлению финансовых показателей, основанных на общепринятых принципах бухгалтерского учета в Соединенных Штатах Америки (GAAP), Akamai предоставляет дополнительные финансовые показатели, которые не подготовлены в соответствии с GAAP (не GAAP). Руководство использует финансовые показатели, не относящиеся к GAAP, в дополнение к финансовым показателям GAAP, чтобы понять и сравнить операционные результаты за отчетные периоды, для принятия финансовых и операционных решений, для целей планирования и прогнозирования, для измерения вознаграждения руководителей и для оценки финансовых результатов Akamai. Финансовая мера non-GAAP, используемая в этом выпуске, представляет собой чистую прибыль non-GAAP на разводненную акцию.

Чистая прибыль не по GAAP на разводненную акцию – чистая прибыль не по GAAP, деленная на средневзвешенную разводненную обыкновенную акцию в обращении. Разводненные средневзвешенные акции в обращении корректируются в расчетах не по GAAP на акцию для акций, которые будут переданы Akamai в соответствии со сделками хеджирования облигаций, заключенными в связи с выпуском конвертируемых старших облигаций на сумму 1 150 миллионов долларов США со сроком погашения в 2027 и 2025 годах соответственно. В соответствии с GAAP акции, переданные в рамках операций хеджирования, не считаются компенсирующими акции при расчете полностью разводненных акций до тех пор, пока они не будут переданы. Тем не менее, компания получила бы выгоду от операций хеджирования облигаций и не допустила бы разводнения, поэтому руководство считает, что корректировка этой выгоды дает содержательное представление об операционных результатах. Что касается конвертируемых старших облигаций со сроком погашения в 2027 и 2025 годах, если средневзвешенная цена акций Akamai не превышает 116,18 и 95,10 долларов США, соответственно, начальной цены конвертации, не будет никакой разницы между разводненной средневзвешенной обыкновенной акцией по GAAP и не по GAAP. Акции выдающиеся.

Чистая прибыль не по GAAP – чистая прибыль по GAAP, скорректированная с учетом следующих налоговых статей: амортизация приобретенных нематериальных активов; компенсация на основе акций; амортизация капитализированного вознаграждения, основанного на акциях; расходы, связанные с приобретением; расходы на реструктуризацию; прибыли и убытки от юридических расчетов; расходы, понесенные в связи с пожертвованиями в фонд Akamai; амортизация долгового дисконта и затрат на выпуск; амортизация капитализированных процентных расходов; определенные прибыли и убытки от инвестиций; доходы и убытки от инвестирования по методу долевого участия; и другие неповторяющиеся или необычные события, которые могут возникать время от времени.

Корректировки не по GAAP и основание Akamai для их исключения из финансовых показателей не по GAAP описаны ниже:
  • Амортизация приобретенных нематериальных активов – Akamai произвела амортизацию нематериальных активов, включенных в ее финансовую отчетность по GAAP, в связи с различными приобретениями Akamai. Сумма покупной цены приобретения, относящаяся к нематериальным активам, и срок соответствующей амортизации могут значительно различаться и уникальны для каждого приобретения; поэтому Akamai исключает амортизацию приобретенных нематериальных активов из своих финансовых показателей, не предусмотренных GAAP, чтобы предоставить инвесторам последовательную основу для сравнения операционных результатов до и после приобретения.
  • Компенсация, основанная на акциях, и амортизация капитализированной компенсации, основанной на акциях. Хотя компенсация, основанная на акциях, является важным аспектом компенсации, выплачиваемой сотрудникам Akamai, справедливая стоимость на дату предоставления варьируется в зависимости от цены акций на момент предоставления, различных методологий оценки., субъективные предположения и разнообразие типов наград. Это затрудняет интерпретацию сравнения текущих финансовых результатов Akamai с предыдущими и будущими периодами; поэтому Akamai считает полезным исключить компенсацию, основанную на акциях, и амортизацию капитализированной компенсации, основанной на акциях, из своих финансовых показателей, не предусмотренных GAAP, чтобы подчеркнуть эффективность основного бизнеса Akamai и соответствовать тому, как многие инвесторы оценивают ее эффективность. и сравнить его операционные результаты с аналогичными компаниями.
  • Затраты, связанные с приобретением. Затраты, связанные с приобретением, включают комиссионные за транзакции, консультационные услуги, расходы на комплексную проверку и другие прямые расходы, связанные со стратегической деятельностью. Кроме того, последующие корректировки первоначальных расчетных сумм условного вознаграждения и возмещения убытков Akamai, связанных с конкретными приобретениями, включаются в расходы, связанные с приобретением. На эти суммы влияют сроки и размер приобретений. Akamai исключает затраты, связанные с приобретением, из своих финансовых показателей не по GAAP, чтобы обеспечить полезное сравнение операционных результатов Akamai с предыдущими периодами и с аналогичными компаниями, поскольку такие суммы значительно различаются в зависимости от масштабов сделок по приобретению и не отражают основную деятельность Akamai. .
  • Расходы на реструктуризацию – Akamai понесла расходы на реструктуризацию в связи с программами, которые существенно изменили либо объем деятельности, осуществляемой Компанией, либо способ ведения этой деятельности. Эти расходы включают выходное пособие и связанные с ним расходы на сокращение рабочей силы, обесценение долгосрочных активов, которые больше не будут использоваться в операциях (включая активы в форме права пользования, другое имущество и оборудование, относящееся к объекту, и программное обеспечение для внутреннего использования) и комиссионные за увольнение. за любые контракты, расторгнутые в рамках этих программ. Akamai исключает эти статьи из своих финансовых показателей, не предусмотренных GAAP, при оценке эффективности своей деятельности, поскольку такие статьи значительно различаются в зависимости от масштабов реструктуризации и не отражают ожидаемые будущие операционные расходы. Кроме того, эти сборы не обязательно дают осмысленное представление об основах текущей или прошлой деятельности компании.
  • Амортизация долгового дисконта и затрат на выпуск, а также амортизация капитализированных процентных расходов. В августе 2019 года Akamai выпустила конвертируемые старшие облигации на сумму 1 150 млн долларов США со сроком погашения в 2027 году и процентной ставкой по купону 0,375%. В мае 2018 года Akamai выпустила конвертируемые старшие облигации на сумму 1 150 млн долларов со сроком погашения в 2025 году и процентной ставкой купона 0,125%. Вмененные процентные ставки по этим конвертируемым старшим облигациям составляли 3,10% и 4,26% соответственно. Это является результатом дисконтов по долговым обязательствам, учитываемых для функций конвертации, которые должны учитываться отдельно как капитал в соответствии с GAAP, что снижает балансовую стоимость конвертируемых долговых инструментов. Дисконты по долгу амортизируются как процентные расходы вместе с затратами на выпуск долга. Процентные расходы, исключенные из результатов Akamai не по GAAP, состоят из этих неденежных компонентов и исключены из оценки руководством операционных результатов компании, поскольку руководство считает, что неденежные расходы не отражают текущие операционные результаты.
  • Прибыли и убытки от инвестиций – Akamai зафиксировала прибыли и убытки от выбытия, изменения справедливой стоимости и обесценения определенных инвестиций. Akamai считает, что исключение этих сумм из своих финансовых показателей не по GAAP полезно для инвесторов, поскольку типы событий, приводящие к возникновению этих прибылей и убытков, не отражают основную деятельность Akamai и текущую операционную деятельность.
  • Юридические расчеты – Akamai понесла убытки, связанные с урегулированием юридических вопросов. Akamai считает, что исключение этих сумм из своих финансовых показателей, не предусмотренных GAAP, полезно для инвесторов, поскольку типы событий, в результате которых они возникают, не являются репрезентативными для основной деятельности Akamai.
  • Благотворительный фонд Akamai Foundation — Akamai понесла расходы на финансирование Akamai Foundation, частного корпоративного фонда, занимающегося поощрением нового поколения технологических новаторов путем поддержки образования в области математики и естественных наук. Первое пожертвование Akamai было сделано в 2018 году, чтобы обеспечить постоянное пожертвование для Akamai Foundation, чтобы позволить ему расширить сферу своей деятельности. В четвертом квартале 2020 года Akamai пополнил фонд, чтобы обеспечить конкретные инициативы по увеличению разнообразия в технологической отрасли. Akamai считает, что исключение этих сумм из финансовых показателей не по GAAP полезно для инвесторов, поскольку эти нечастые и почти единовременные расходы не являются репрезентативными для ее основной деятельности.
  • Доходы и убытки от инвестиций по методу долевого участия. Akamai отражает доходы или убытки в отношении своей доли прибыли и убытков от инвестиций по методу долевого участия. Akamai исключает такие доходы и убытки, поскольку она не осуществляет прямого контроля над операциями с инвестициями, а соответствующие доходы и убытки не являются репрезентативными для ее основной деятельности.
  • Влияние на налог на прибыль корректировок, не предусмотренных GAAP, и некоторых отдельных налоговых статей. Корректировки, не предусмотренные GAAP, описанные выше, отражаются до налогообложения. Эффект налога на прибыль от корректировок, не предусмотренных GAAP, представляет собой разницу между расходами по налогу на прибыль, предусмотренным GAAP, и налогом на прибыль, не предусмотренным GAAP. Расходы по подоходному налогу без учета GAAP рассчитываются на основе дохода до налогообложения без учета GAAP (доход по GAAP до налогообложения, скорректированный с учетом корректировок, не предусмотренных GAAP) и исключают определенные отдельные налоговые статьи (например, учет или освобождение от оценочных поправок), если таковые имеются. Akamai считает, что применение корректировок, не предусмотренных GAAP, и связанного с ними налога на прибыль позволяет Akamai выделять прибыль, относящуюся к ее основной деятельности.

Заявление Akamai в соответствии с Законом о реформе судебных разбирательств по частным ценным бумагам
Этот выпуск и/или наша телефонная конференция о прибылях и убытках, запланированная на сегодня, содержит информацию о будущих ожиданиях, планах и перспективах руководства Akamai, которые представляют собой прогнозные заявления для целей положений о безопасной гавани в соответствии с Законом о реформе судебных разбирательств по частным ценным бумагам от 1995 года, включая заявления об ожидаемых будущих финансовых результатах и ​​преимуществах планируемого приобретения Linode. Фактические результаты могут существенно отличаться от тех, которые указаны в этих прогнозных заявлениях, в результате различных важных факторов, включая, помимо прочего, неспособность продолжать генерировать денежные средства на том же уровне, что и в предыдущие годы; возможность завершить сделку Linode своевременно или вообще; неопределенность в отношении того, будут ли реализованы ожидаемые выгоды от сделки с Linode; неопределенность в отношении того, будет ли бизнес Linode успешно интегрирован с бизнесом Akamai, в том числе будет ли технология Linode взаимодействовать, как ожидается, с существующей технологией Akamai; влияние объявления о предполагаемой сделке на способность Linode поддерживать отношения со своими ключевыми клиентами, поставщиками и сотрудниками; неспособность наших инвестиций в инновации создать решения, которые будут приняты на рынке; неспособность увеличить наши доходы с той же скоростью, что и в прошлом, и не допустить, чтобы наши расходы росли более высокими темпами, чем наши доходы; влияние продолжающейся пандемии COVID-19; дефекты или сбои в наших продуктах или ИТ-системах; отказ интеграции любого из наших приобретений; задержка в разработке или неспособность разработать новые предложения услуг или функции, а также, если они будут разработаны, отсутствие принятия рынком таких предложений услуг и функций или отказ таких решений работать должным образом, а также другие факторы, которые обсуждаются в Годовом отчете Компании. по форме 10-K, ежеквартальные отчеты по форме 10-Q и другие документы, периодически подаваемые в SEC.

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

Об Акамай
Akamai питает и защищает жизнь в сети. Самые инновационные компании по всему миру выбирают Akamai для обеспечения безопасности и предоставления своих цифровых услуг, помогая миллиардам людей жить, работать и развлекаться каждый день. Благодаря крупнейшей и самой надежной в мире пограничной платформе Akamai делает приложения, код и возможности ближе к пользователям, а угрозы — подальше. Узнайте больше о продуктах и ​​услугах Akamai для обеспечения безопасности, доставки контента и периферийных вычислений на сайтах www.akamai.com, blogs.akamai.com или следите за новостями Akamai Technologies в Twitter и LinkedIn.

Contacts:
Gina Sorice
Media Relations
646-320-4107
gsorice@akamai.com

Tom Barth
Investor Relations
617-274-7130
tbarth@akamai.com

Теперь доступно блочное хранилище NVMe



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

https://www.linode.com

Теперь используйте Google Pay для оплаты своих линодов



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

Модернизация центра обработки данных Linode Atlanta завершена



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

Информация о работоспособности и соответствии требованиям центра обработки данных в Атланте:
  • Соглашение об уровне обслуживания для DC, обеспечивающее 100% бесперебойную работу
  • Питание — резервирование 2N
  • Охлаждение — резервирование N + 1
  • Соответствие — SOC 1, тип 2, SOC 2, тип 2, HIPAA, PCI-DSS, GDPR Privacy Shield и SSAE-16/18

Теперь поддерживает облачный брандмауэр
Атланта — один из первых центров обработки данных, поддерживающих Linode Cloud Firewall. Брандмауэры можно легко развернуть и настроить с помощью Cloud Manager или Linode API для любых новых или существующих ресурсов в Атланте. Узнайте больше о бета-версии Cloud Firewall и о том, как начать работу.
Обратите внимание, что облачные брандмауэры в настоящее время доступны в некоторых центрах обработки данных, поскольку мы продолжаем внедрять эту функцию в нашей глобальной инфраструктуре.

Скоро в Атланте
Блочное хранилище, объектное хранилище и VLAN (бета) скоро появятся в Атланте. Чтобы получать уведомления о доступности новых продуктов в Атланте и других центрах обработки данных, вы можете следить за блогом, подписываться на ежемесячный информационный бюллетень In the Node или зарегистрироваться для участия в нашей программе тестирования пользователей Linode Green Light.

https://www.linode.com