PTG (Project Team Gathering) – это мероприятие, на котором команды разработчиков встречаются для обсуждения текущих задач, статусов и планов. Несколько лет назад PTG отделилось от основного OpenStack саммита.

PTG впервые проводился в онлайн формате через Zoom и Jitsi Meet. Однако сочетание картинки и звука на встрече сделало это изменение совсем незаметным, особенно на фоне ныне привычных командных митингов через IRC.

Трехчасовые сессии, посвященные Neutron, проходили со вторника по пятницу. Основной протокол встреч опубликован в OpenStack Etherpad и в списке рассылки OpenStack. Повестка мероприятия была сформирована на основе предложений разработчиков Neutron, а расписание встреч подготовил ее председатель, PTL (Project Team Lead) команды Neutron Slawek Kaplonski.

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

Привет, меня зовут Максим, я системный администратор. Три года назад мы с коллегами начали переводить продукты на микросервисы, а в качестве платформы решили использовать Openstack, и столкнулись с некоторым количеством неочевидных граблей при автоматизации тестовых схем. Этот пост про нюансы настройки OpenStack, которые с трудом находятся на пятой странице выдачи поисковика (а лучше, чтобы легко находились на первой).

Нагрузка на ядра: было — стало

NAT

В некоторых инстансах мы используем dualstack. Это когда виртуальная машина получает сразу два адреса — IPv4 и IPv6. Сначала мы сделали так, что «плавающий» v4-адрес назначался во внутренней сети через NAT, а v6 машина получала через BGP, но с этим есть пара проблем.

NAT — дополнительный узел в сети, где и без него нужно следить за нормальным распределением нагрузки. Появление NAT в сети почти всегда ведёт к сложностям с отладкой — на хосте один IP, в базе другой, и отследить запрос становится сложно. Начинаются массовые поиски, а разгадка всё равно будет внутри OpenStack.

Ещё NAT не позволяет сделать нормальную сегментацию доступов между проектами. У всех проектов свои подсети, плавающие IP постоянно мигрируют, и с NAT управлять этим становится решительно невозможно. В некоторых инсталляциях говорят об использовании NAT 1 в 1 (внутренний адрес не отличается от внешнего), но это всё равно оставляет лишние звенья в цепочке взаимодействия с внешними сервисами. Мы пришли к мнению, что для нас лучший вариант — это BGP сеть.

abstract: разница между текущей производительностью и производительностью теоретической; latency и IOPS, понятие независимости дисковой нагрузки; подготовка тестирования; типовые параметры тестирования; практическое copypaste howto.

Предупреждение: много букв, долго читать.

Лирика

Очень частой проблемой, является попытка понять «насколько быстрый сервер?» Среди всех тестов наиболее жалко выглядят попытки оценить производительность дисковой подсистемы. Вот ужасы, которые я видел в своей жизни:

• научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
• использование bonnie++
• использование iozone
• использование пачки cp с измерениема времени выполнения
• использование iometer с dynamo на 64-битных системах

Это всё совершенно ошибочные методы. Дальше я разберу более тонкие ошибки измерения, но в отношении этих тестов могу сказать только одно — выкиньте и не используйте.

Данная заметка является переводом статьи из блога компании Scout. В статье дается простое и наглядное объяснение такого понятия, как load average. Статья ориентирована на начинающих Linux-администраторов, но, возможно, будет полезна и более опытным админам. Заинтересовавшимся добро пожаловать под кат.

Не так давно посчастливилось пройти курс Red Hat Virtualization (RH-318) и принять участие в сдаче соответствующего экзамена на статус RHCVA — Red Hat Certified Virtualization Administrator(EX-318). Подобных тем на Хабре я, к сожалению, не нашел, поэтому поделюсь собственным опытом подготовки к сдаче экзамена.

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