AWS EC2 Virtualization 2017: Introducing Nitro

http://www.brendangregg.com/blog/2017-11-29/aws-ec2-virtualization-2017.html 

• Для себя:
  • HVM позволяет использовать фичи железа: enhanced networking, какие-то фишки CPU.
  • с4., m4. - уже HVM only, последняя серия, где можно было использовать PV - это c3/m3
• Nitro - Latest AWS supervisor. Hardware virtualization is now fast
• Зеленый цвет (высокая производительность) впервые появился на CPU (самое важное), распространяется правее. Это намеренное решение AWS.
• Каждое направление развивается по следующим стадиям:
  • Virtualized in Software: работает с неизменной гостевой ОС, все эмулируемые операции в 2-10 раз медленнее
  • Paravirtualization: Гипервизор позволяет эффективные гипервызовы, и гостевая ОС должна использовать драйвера и модификации ядра для вызова этих гипервызовов. Координация меджу гипервизором и гостевой ОС для улучшения производительности. 10-50% падения производительности. Не может пользоваться расширенной функциональностью аппаратной части, которая есть на хосте.
  • Virtualized in Hardware. Поддержка виртуализации в железе. Близкая к железу скорость работы в гостевой ОС. 0.1-0.5% падение производительности. Необходима для “enhanced networking + GPU processing”
• Fully Emulated: аналог VMWare 1998. Первые гипервизоры использовали полную эмуляцию и бинарную трансляцию для привилегированных операций (syscalls & page table операции). Большие падения производительности, особенно для высоко нагруженных I/O задач.
• Xen PV 3.0: Enter paravirtualization. Гостевая ОС модифицирована, чтобы знать о гипервизоре и чтобы делать эффективные вызовы гипервизора. AMI и boot - paravirt (PV). Kernel делает гипервызовы (hypercalls) вместо привилегированных инструкций. И ядро использует paravirt network + storage drivers. Это улучшает производительность, но всё ещё просадки при выполнении привилегированных операций (syscalls, page table events). CPU тоже чуть лучше, чем в Fully Emulated, но хуже, т.к. ещё не появилась HW виртуализация в CPU (Intel VT-x, AMD-V). m1.small
• Xen HVM 3.0. Более современный гипервизор на процессорах с аппаратной поддержкой для CPU и памяти (VT-x). Paravirt драйвера используются для сети и storage devices. AMI и boot - теперь тоже HVM. Прерывания и таймеры - все еще на software virtualization, но загружаются и работают уже достаточно быстро (поэтому - зеленые)
• Xen HVM 4.0.1. boot HVM, uses Paravirt (PV) drivers with HVM features (PV on HVM = PVHVM).
Много путаницы:
  • AMI type: PV vs HVM, но на самом деле там PV vs (HVM + PV drivers) vs (HVM + PVHVM). Most often, HVM is HVM + PVHVM.
  • еще путаница: производительность. Первые HVM не использовали Paravirt drivers, поэтому были медленнее, чем PV (поэтому многие рекомендовали PV чем HVM). Вскоре производительность HVM обогнала PV, и рекомендация устарела.
  • в 2014 Netflix перевела все инстансы PV -> HVM (PVHVM)
• Xen AWS 2013. Начиная c 2013 некоторые инстансы начали поддерживать аппаратную виртуализацию для сетевых интерфейсов: Single Root I/O Virtualization (SR-IOV). Первым был c3, AWS назвала это Enhanced Networking. Сперва это было через ixgbe драйвер для работы до 10Гбит, а потом ena драйвер для скоростей до 25Гбит. Они в Netflix тестировали это и добились 2М packets per second
• Xen AWS 2017. В 2015 AWS запустила c4., которая использует аппаратную виртуализацию для EBS. Эта же технология использовалась для запуска новых storage-optimized инстансов в 2017: i3., которые использовали SR-IOV и nvme драйвер. Netflix протестировали - 3М storage IOPS.
• AWS Nitro 2017. На последнем re:Invent был анонсирован новый гипервизор Nitro, под которым работает c5. Nitro основан на ядре KVM, но не использует многие его дополнения (напр QEMU). Также упрощена работа с I/O (не используется domO или IDD), так как работают с железом напрямую
Цель Nitro - сделать производительность, неотличимую от “bare metal”. Теперь аппаратная поддержка используется и для прерываний (детали есть в статье “Comprehensive Implementation and Evaluation of Direct Interrupt Delivery”)
Все предыдущие улучшения - являются частями Nitro, которые постепенно появлялись в AWS.
Brendan пробовал протестировать оверхед от Nitro - получилось точно меньше 1%, очень часто - неотличимо от железа.
Чем еще хорош c5 - он позволяет считывать PMC (Performance Monitoring Counters) (отдельная статья Brendan-а). Раньше на некоторых инстансах можно было считывать 7 PMC, теперь их сотни. И вы можете анализировать низкоуровнево производительность CPU (можно искать способы поднять производительность на 5-10%)
m5 также использует Nitro, AWS пообещал, что все инстансы постепенно перетащит на Nitro.
За исключением Bare Metal инстансов
• AWS Bare Metal 2017. 0% оверхеда, реальные железяки, на которых вы можете запускать все, что хотите (Xen, KVM, …). Они называются Nitro System, в отличие от предыдущих Nitro Hypervisor

Problem with App on k8s: postmortem

https://community.monzo.com/t/resolved-current-account-payments-may-fail-major-outage-27-10-2017/26296/95

• Monzo’s head of eng.
• Stack: k8s + сотни микросервисов (in Docker container). etcd for k8s. linkerd (routing, lb)
• За две недели до - обновили etcd: 3->9 нод (1->3 в каждой AZ)
• За день до - запустили новый сервис, но проблемы, поэтому отсколировали до 0 (сервис остался)
• 14:10 релиз (мелкие изменения постоянно), после этого начались проблемы (реквесты падают)
• 14:12 Откатили изменения, но ошибки остались
• 14:16 внутреннее признание, что outage
• 14:18 обнаружили, что linkerd в нездоровом состоянии. Не заметил изменений о новых подах, поэтому трафик не доходил
• 14:26 Поняли, что проще всего перезапустить все linkerd инстансы (сотни). Задействовали резервную систему для платежей
• 14:37 Новые поды linkerd не стартовали, т.к. информацию нельзя получить с apiserver. Поняли, что проблема где-то в k8s, поэтому рестартовали все 3 apiserver. После их рестарта - linkerd стартовал успешно
• 15:13 linkerd поды рестартовали, но все процессы перестали получать трафик (у клиентов все лежит)
• 15:27 linkerd логирует NullPointerException когда птыается распарсить вывод от apiserver. Они поняли, что это несовместимость версий k8s и linkerd, а точнее - проблема распарсить сервис, в котором нет подов. К этому времени они уже долго тестировали новую версию linkerd, с решенной проблемой - они ее релизят чтобы решить проблему
• 15:31 После анализа проблемы, поняли, что можно все починить, если убить тот сервис, которые не содержит подов. Удалили сервис - заработала старая версия linkerd
• RootCause: Был найден баг в k8s, когда обновление с удаление подом (а сервис жив) - падало по timeout. Поэтому