Исследование влияния Meltdown на AWS-инфраструктуру

 

3 января 2018 года мировая общественность узнала о возможности атак Meltdown и Spectre, обусловленных архитектурными особенностями современных процессоров. Это произошло примерно на неделю раньше запланированного срока из-за утечек. Мы много писали об этом, а потому повторяться не будем — достаточно сказать, что уязвимости являются самыми большими из вскрытых в последнее десятилетие и требуют полного переосмысления микропроцессорных архитектур, а также принципов взаимодействия ПО и CPU.

Публичные облачные компании вроде Amazon Web Services (AWS) были проинформированы об уязвимостях до обнародования информации и работали над подготовкой системных исправлений, которые предотвратили бы раскрытие информации в облачной инфраструктуре со множеством арендаторов. На данный момент нет универсального исправления для Spectre, поэтому большинство смягчающих мер на сегодняшний день прежде всего нацелены против более лёгкой для использования злоумышленниками уязвимости Meltdown.

Недавно в своём блоге SolarWinds решила поделиться опытом использования инфраструктуры AWS в течение последних недель в связи с Meltdown. Компания, как и многие другие в секторе SaaS (ПО как услуга), пострадала от частичного простоя, вызванного усилиями AWS по борьбе с Meltdown. Первым признаком предстоящих проблем стали полученные в середине декабря email-сообщения о необходимости перезагрузки всех паравиртуализированных (PV) хостов до 5 января. SolarWinds в основном работает с HMV-системами, но для поддержки устаревших платформ используют и несколько PV. Как видно из приведённой диаграммы, взятой из сервисного звена серверов Python, когда 20 декабря были перезагружены PV-системы, результатом стал рост нагрузки CPU на внушительные 25% — были и другие сообщения о схожих проблемах, связанных с производительностью или стабильностью работы серверов после их перезагрузки накануне 5 января:

Для HVM-серверов AWS смогла выпустить заплатку против Meltdown, не требующую перезагрузки. Судя по всему, для серверов HVM EC2 они начали развёртываться около 4 января 00:00 UTC по времени восточного побережья США и закончили в 20:00 UTC. Это очень быстро — очевидно, Amazon форсировала процесс из-за преждевременной утечки информации. Подобный рост нагрузки процессоров был замечен на нескольких сервисных звеньях:

В этот же период было зарегистрировано дополнительное увеличение нагрузки CPU на PV-серверах, которые уже были обновлены. По-видимому, они тоже получали какие HVM-исправления примерно в то же время, как и все полноценные HVM:

С точки зрения производительности, затронуты обновлением были почти все уровни платформы — как инфраструктура EC2, так и управляемые службы AWS (RDS, Elasticache, VPN Gateway). Например, SolarWinds активно использует Kafka для обработки потоков в Solarwinds Cloud. Рост нагрузки на CPU во время развёртывания обновления оказался умеренным, около 4 %:

Но в то же время частота обмена пакетами в том же кластере Kafka, снизилась на значение до 40 %. Пропускная способность при этом не уменьшилась, так что, по мнению SolarWinds, время отклика отдельных пользователей увеличилось, что привело к увеличению размеров пакетов данных и уменьшению количества небольших пакетов:

Звенья СУБД Cassandra, которые SolarWinds использует для хранения данных, тоже были затронуты по всем направлениям. Наблюдались всплески нагрузки CPU примерно на 25 % на экземплярах вроде m4.2xlarge и других типов. Даже если мощностей достаточно, это заставляет задуматься о расширении, чтобы компенсировать потенциальный рост нагрузки.

Влияние на производительность также наблюдалось и для внутренних звеньев SolarWinds. Например, задержки p99, связанные с записью в Cassandra, возрастали на значение до 45 %.

Также были обнаружены скачки в задержках в управляемых службах AWS, таких как AWS Elasticache Memcached. Например, на приведённом memcached-кластере при средней нагрузке на CPU в 8 % рост оказался почти двукратным:

Это привело к весьма существенному удлинению хвоста задержек (Tail latency) и таймаутов кеша, то есть для некоторых пользователей ожидание отклика возросло многократно:

Как видно из диаграмм, новый базовый уровень производительности систем существенно изменился после исправлений для борьбы с Meltdown. Заплатки KPTI необходимы для поддержки изоляции памяти, чтобы предотвратить использование уязвимостей в публичной облачной инфраструктуре, сдаваемой множеству арендаторов. Разработчикам ПО необходимо будет понять, как можно снизить возросшие накладные расходы ресурсов CPU от переключений между пользовательским адресным пространством и ядром, которые добавляют KPTI-исправления.

Приложения, часто делающие системные вызовы для чтения или записи данных по сети или из дисковых систем, должны быть оптимизированы. Небольшие операции ввода-вывода стали более «дорогими», и разработчикам придётся оптимизировать код, чтобы уменьшить частоту таких вызовов, объединяя несколько в один. Найти оптимальное значение между большими размерами пакетов и задержками сложно и потребует ПО, которое умеет адаптироваться под несколько переменных одновременно. Отрадно видеть, что потребительские библиотеки Kafka смогли динамически оптимизироваться по мере увеличения задержек сетевых вызовов.

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

Также неясно, к чему приведёт появление новых заплаток против Meltdown и Spectre, — можно лишь предположить, что они будут продолжать влиять на производительность любой масштабной бизнес-инфраструктуры. Придётся адаптировать принципы разработки программного обеспечения для распределённых систем, чтобы приспособиться к меняющимся условиям. Стоит добавить, что на общую производительность также повлияют исправления для клиентских систем. Впрочем, по состоянию на 12 января SolarWinds заметила существенное снижение CPU-нагрузки своих систем. Неясно, стало ли это следствием развёртывания дополнительных заплаток или были иные причины, однако уровни нагрузки процессоров возвращаются к уровням до появления HVM-исправлений.

Если вы заметили ошибку — выделите ее мышью и нажмите CTRL+ENTER. | Можете написать лучше? Мы всегда рады новым авторам.

Источник:

Постоянный URL: https://servernews.ru/964080
Поделиться:  

Комментарии

Система Orphus