Всем привет! Каждый день наша большая и дружная команда инженеров решает сложные задачи и вносит вклад в создание высокотехнологичных продуктов — систем обработки и хранения данных. Мы решили познакомить вас с их рутиной поближе, и сегодня начинаем серию интервью с коллегами, чтобы от первого лица рассказать обо всех нюансах их работы.
Производительность — одна из ключевых характеристик качественного программного обеспечения: прочие характеристики систем хранения данных не будут оценены по достоинству, если она работает медленно или нестабильно. Сегодня мы беседуем с Сергеем Качкиным kachini — руководителем отдела технической экспертизы департамента прикладных исследований и технической экспертизы компании YADRO.
У его профессии несколько названий: аналитик производительности, performance engineer, performance tester. И все они достаточно мало распространены в России. Между тем инжиниринг производительности помогает создавать эффективные компьютерные системы, которые работают быстро и надежно. Его задача — изучить, почему система функционирует не так, как хотелось бы, разобраться в причинах медленной или не соответствующей целевым параметрам работы, выявлять и находить проблемные места, помогать их устранять.
Сергей Качкин рассказал о поиске узких мест в программном стеке и оптимизации производительности СХД, о том, чем занимается его команда.
Сергей, как вы пришли в компанию YADRO? Был ли у вас уже опыт работы с OpenPOWER?
До этого я работал у другого вендора, занимался поддержкой проприетарной версией ОС UNIX на IA64 (не путать с x86) процессорах в части производительности ядра. Архитектура EPIC не похожа на RISC, она совсем другая. Так что опыт работы с OpenPOWER в компании YADRO у меня первый, и перестройка заняла какое-то время. Но идея у OpenPOWER, несмотря на некоторый минимализм, та же самая, поэтому всё можно освоить.
Чем занимаются performance–инженеры? Какие методы применяют в работе? Сложно ли вам набирать новых сотрудников?
Основная специализация нашей команды — инжиниринг производительности или performance engineering. Это отдельная дисциплина, нацеленная на то, чтобы убедиться: разрабатываемое решение удовлетворяет нефункциональным требованиям, в частности — производительности. Она включает в себя набор практик, знаний, методов и техник, которые могут применяться на разных этапах разработки программного обеспечения: подготовительном, этапе программирования, тестирования и эксплуатации системы.
В России эта дисциплина не очень распространена, по крайней мере, такое впечатление создается по результатам поиска сотрудников. Однако в мире, это сформировавшееся направление. Эта IT специализация редко связана с непосредственным написанием кода. Мы мало программируем и, собственно, и не умеем делать это так, как профессиональные программисты. При этом требуются специфические навыки, для локализации «горячих точек» в софте, влияющих на нефункциональные требования. С одной стороны, это помогает создавать продукт, удовлетворяющий требованиям, с другой — предотвращать затраты на дальнейшую оптимизацию или переделку.
Как вы обеспечиваете контроль качества и выявление узких мест в стеке программного обеспечения?
Методы можно разделить на два подвида. Первый — это системно-ориентированный подход (system centric approach). Он ориентирован на ресурсы: мы анализируем загрузку отдельных компонентов системы и на основании полученных результатов делаем предположение, где имеется узкое место.
Второй — это подход, ориентированный на приложение (application centric approach), когда объектом исследования становятся приложения целиком или отдельные процессы в Linux. Мы смотрим, что делает приложение, какую работу выполняет. Полезная эта работа, или оно делает что-то бесполезное, то есть попусту тратит время. Если приложение в состоянии ожидания, мы смотрим, чего оно ждёт. Обычно это аппаратные или программные ресурсы, механизмы синхронизации.
В реальной жизни приходится переключаться между этими методами. То есть, с одной стороны, мы смотрим на ресурсы: есть ли там какие-то явные проблемы, ошибки. Делаем выводы. Потом смотрим на приложение: как оно себя чувствует. В данном случае приложение — это программный код СХД или иное, что является объектом оптимизации.
Как понять, что СХД работает «на пределе»? Как определить, что запас производительности исчерпан? Какие параметры об этом свидетельствуют? Какие основные метрики используются для оценки производительности СХД?
Обычному пользователю доступно несколько метрик. Основная — это время отклика. Важно его абсолютное значение. Кроме времени отклика важна также пропускная способность. Если с ростом нагрузки время отклика начинает расти, при этом показатели IOPS и объем передаваемых данных не увеличиваются, то это означает, что какой-то ресурс СХД близок к насыщению. Как известно, система хранения работает настолько быстро, насколько быстро может функционировать ее самый медленный ресурс.
При этом разные приложения могут быть критичны либо ко времени отклика, либо к пропускной способности. Например, если мы говорим о базе данных, то обычно это произвольный доступ мелкими блоками, много чтения, и ей важны производительность в IOPS и минимальное время отклика. Для других нагрузок типа потоковых при бэкапах, записи с видеокамер или интернета вещей важнее пропускная способность, возможность записать большой поток данных.
Оптимизируется ли система хранения под конкретную задачу, или создается как универсальное решение?
Уже долгое время системы хранения, по крайней мере общего назначения, универсальны. Они не «затачиваются» под какую-то конкретную нагрузку и стараются «угодить» наиболее распространенным приложениям. Ведь примерно известно, какой профиль нагрузки у базы данных, системы резервного копирования, видеонаблюдения и так далее. Система хранения должна адекватно реагировать на такие нагрузки без каких-либо дополнительных настроек.
Поэтому системы хранения общего назначения изначально проектируются так, чтобы удовлетворить наиболее типовым задачам. Для этого применяются синтетические тесты c набором «критичных» профилей, моделирующих реальную ситуацию. В большинстве случаев работает, но реальность всегда гораздо сложнее.
Реальные нагрузки моделируются синтетикой весьма приблизительно. Это вообще наукоемкая область, потому что кроме IOPS, пропускной способности, размера блока и соотношения операций чтения и записи у нагрузки гораздо больше характеристик. Это и локализация пятна данных на диске, наличие «горячих областей», распределение запросов во времени, и равномерность их поступления. Поэтому есть вероятность, что конкретная нагрузка не попадёт ни в один из профилей. Может быть из-за особенностей программного обеспечения или специфики самой бизнес-задачи. В этом случае нужна настройка системы под конкретные задачи.
Исследуют приложение, как оно работает. И может потребоваться изменить либо работу приложения, либо настройки системы хранения. Иногда гораздо проще решить проблемы на стороне приложения с помощью какой какой-то настройки, чем заниматься изменением СХД.
А настраивается под задачу система автоматически? Нужны ли для этого искусственный интеллект? Может ли администратор или пользователь сам выбирать профиль нагрузки?
Системы хранения уже давно делают это автоматически — администратора такой задачей не загружают. Обычно стараются достигать этого без использования искусственного интеллекта —традиционными алгоритмами. Однако у ИИ большой потенциал. Если он позволит предсказывать, какие блоки данных и в какой момент времени может запросить приложение, то можно заранее к этому готовиться.
Если раньше алгоритмы оптимизации были достаточно простыми, типа упреждающего чтения, то есть при последовательном чтении данных система заранее загружала данные в кэш, или наоборот освобождала кэш-память для других данных, то теперь возможности расширяются: система сможет подготовиться к пику запросов или сложно организованному «пятну горячих данных».
Каковы должны быть масштабы оптимизации СХД? Охватывает ли она также ПО/оборудование серверов, инфраструктуру (SAN)? Предполагает ли обязательную тесную интеграцию программного и аппаратного стеков?
С точки зрения performance engineering система рассматривается целиком, в комплексе, то есть приложение, хост (сервер), инфраструктура хранения данных, (SAN), СХД. Важно представлять, как работает приложение, потому что именно оно генерирует запросы к СХД. Всё это, конечно, учитывается и используется.
Считается, что самый оптимальный вариант использования накопителей разных типов в СХД — многоуровневое хранение данных. Можно ли тиринг рассматривать как средство увеличения производительности системы хранения?
Вообще говоря, тиринг похож на кэширование — у них есть общие элементы. Разница лишь в том, что при кэшировании данные дублируются, то есть они находятся и на SSD (в кэше), и на диске, а при тиринге хранятся только в одном месте. То есть, если кэширование — это способ оптимизации производительности, то и тиринг тоже можно рассматривать как метод оптимизации.
В чем вы видите преимущества/недостатки программно-определяемых СХД (SDS) с точки зрения анализа производительности и оптимизации системы? Может быть, это более простые, более гибкие решения?
На самом деле, как раз наоборот. SDS — это распределенная система, состоящая из множества серверов, которые взаимодействуют между собой. Если используются специальные операционные системы, какие-то файловые системы, то это тоже добавляет сложности. С точки зрения инжиниринга это сложнее, но в чем-то интереснее. С другой стороны, к SDS обычно не применяются какие-то жесткие требования по производительности, в то время как к классическим системам хранения подход более строгий. То, что прощается программно-конфигурируемым системам, традиционной СХД не простят.
Одна из целей компании — разработка оптимизированных продуктов для искусственного интеллекта, интернета вещей и сетей пятого поколения. Как вы считаете, насколько сложная это задача? Что будут представлять собой такие продукты?
На данный момент для хранения сырых данных в ИИ часто используют файловые хранилища, для тренинга и построения моделей — SDS, то есть это почти всегда распределенные решения. По моему ощущению, во многих компаниях ИИ сейчас используется как некий эксперимент, на него смотрят и пытаются понять, чем он может быть полезен. Поэтому и требования к железу не очень жесткие. Если работает — хорошо, не работает — можно подождать день-другой. По мере того, как работа ИИ в компаниях будет более критичной, возрастут и требования к дисковым подсистемам. Мы увидим новые СХД решения для ИИ и интернета вещей уже mission critical-класса.
Какую роль в оптимизации ПО играет партнерство YADRO с мировыми технологическими компаниями?
С точки зрения технического специалиста оно, конечно, помогает. Такое сотрудничество способствует общению инженеров друг с другом, их доступу к информации, готовым разработкам, и не приходится каждый раз «изобретать велосипед».
Как вам видится роль виртуализации в СХД? Способствует ли она устранению узких мест в ПО или наоборот? И как взаимосвязаны производительность и надежность системы? Можно ли сохранить надежность, увеличивая производительность?
Конечно, виртуализация добавляет сложности, но она может быть полезна для изоляции одной функциональности СХД от другой. В целом это дополнительные издержки и усложнения, поэтому рассматривать ее следует критически, с осторожностью.
Что касается увеличения производительности, то на этом пути, в самом деле, легко потерять надежность. Это своего рода дуализм. Например, когда мы говорим о серверах, то для высокопроизводительного сервера (HPC) надежность обычно на втором месте. Системы хранения, как правило, должны в первую очередь обеспечивать высокую доступность, обладать соответствующей функциональностью и приемлемой производительностью. При увеличении надежности уровня резервирования, система становится сложнее. Возникает необходимость синхронизации элементов. При этом производительность системы неизбежно будет страдать. Задача разработки, свести этот эффект к минимуму.
Сейчас появляются новые классы памяти типа Storage Class Memory, Persistent Memory, совершенствуются флэш-накопители. Как это влияет на архитектуру систем? Успевает ли программное обеспечение за этими изменениями?
Ну, по крайней мере, старается. Вообще, появление быстрой памяти в значительной степени изменило работу performance-инженеров вообще в отрасли. До появления SSD подавляющее большинство проблем с производительностью ИТ систем были связаны с вводом-выводом систем хранения. Потому что есть быстрые процессоры и диски (HDD) с механическими элементами, которые на много порядков медленнее процессора. Поэтому приходилось за счёт алгоритмов пытаться сгладить задержки от медленных дисков.
С появлением быстрой памяти и алгоритмы должны меняться. Если алгоритм достаточно тяжёлый, раньше он всё равно помогал, потому что диск намного медленнее. Если удалось скрыть задержки механики – уже хорошо. С появлением SSD софт должен работать иначе. Он должен вносить минимальную задержку, чтобы получить от SSD максимум скорости. То есть снизилась необходимость в сложных алгоритмах, скрывающих задержки от дисков. Особо критичную к времени отклика базу данных с интенсивным вводом-выводом можно перенести на SSD.
Поменяет ли это архитектуру системы хранения? И да, и нет. Потому что никуда не делись диски. С одной стороны, код должен уметь работать с SSD, то есть быть очень быстрым. С другой, механические диски используются для нагрузок, которые они хорошо выдерживают, типа потоковых. При этом размер дисков многократно вырос, а скорость осталась, как и 10 лет назад.
Производительность — одна из ключевых характеристик качественного программного обеспечения: прочие характеристики систем хранения данных не будут оценены по достоинству, если она работает медленно или нестабильно. Сегодня мы беседуем с Сергеем Качкиным kachini — руководителем отдела технической экспертизы департамента прикладных исследований и технической экспертизы компании YADRO.
У его профессии несколько названий: аналитик производительности, performance engineer, performance tester. И все они достаточно мало распространены в России. Между тем инжиниринг производительности помогает создавать эффективные компьютерные системы, которые работают быстро и надежно. Его задача — изучить, почему система функционирует не так, как хотелось бы, разобраться в причинах медленной или не соответствующей целевым параметрам работы, выявлять и находить проблемные места, помогать их устранять.
Сергей Качкин рассказал о поиске узких мест в программном стеке и оптимизации производительности СХД, о том, чем занимается его команда.
Сергей, как вы пришли в компанию YADRO? Был ли у вас уже опыт работы с OpenPOWER?
До этого я работал у другого вендора, занимался поддержкой проприетарной версией ОС UNIX на IA64 (не путать с x86) процессорах в части производительности ядра. Архитектура EPIC не похожа на RISC, она совсем другая. Так что опыт работы с OpenPOWER в компании YADRO у меня первый, и перестройка заняла какое-то время. Но идея у OpenPOWER, несмотря на некоторый минимализм, та же самая, поэтому всё можно освоить.
Чем занимаются performance–инженеры? Какие методы применяют в работе? Сложно ли вам набирать новых сотрудников?
Основная специализация нашей команды — инжиниринг производительности или performance engineering. Это отдельная дисциплина, нацеленная на то, чтобы убедиться: разрабатываемое решение удовлетворяет нефункциональным требованиям, в частности — производительности. Она включает в себя набор практик, знаний, методов и техник, которые могут применяться на разных этапах разработки программного обеспечения: подготовительном, этапе программирования, тестирования и эксплуатации системы.
В России эта дисциплина не очень распространена, по крайней мере, такое впечатление создается по результатам поиска сотрудников. Однако в мире, это сформировавшееся направление. Эта IT специализация редко связана с непосредственным написанием кода. Мы мало программируем и, собственно, и не умеем делать это так, как профессиональные программисты. При этом требуются специфические навыки, для локализации «горячих точек» в софте, влияющих на нефункциональные требования. С одной стороны, это помогает создавать продукт, удовлетворяющий требованиям, с другой — предотвращать затраты на дальнейшую оптимизацию или переделку.
Как вы обеспечиваете контроль качества и выявление узких мест в стеке программного обеспечения?
Методы можно разделить на два подвида. Первый — это системно-ориентированный подход (system centric approach). Он ориентирован на ресурсы: мы анализируем загрузку отдельных компонентов системы и на основании полученных результатов делаем предположение, где имеется узкое место.
Второй — это подход, ориентированный на приложение (application centric approach), когда объектом исследования становятся приложения целиком или отдельные процессы в Linux. Мы смотрим, что делает приложение, какую работу выполняет. Полезная эта работа, или оно делает что-то бесполезное, то есть попусту тратит время. Если приложение в состоянии ожидания, мы смотрим, чего оно ждёт. Обычно это аппаратные или программные ресурсы, механизмы синхронизации.
В реальной жизни приходится переключаться между этими методами. То есть, с одной стороны, мы смотрим на ресурсы: есть ли там какие-то явные проблемы, ошибки. Делаем выводы. Потом смотрим на приложение: как оно себя чувствует. В данном случае приложение — это программный код СХД или иное, что является объектом оптимизации.
Как понять, что СХД работает «на пределе»? Как определить, что запас производительности исчерпан? Какие параметры об этом свидетельствуют? Какие основные метрики используются для оценки производительности СХД?
Обычному пользователю доступно несколько метрик. Основная — это время отклика. Важно его абсолютное значение. Кроме времени отклика важна также пропускная способность. Если с ростом нагрузки время отклика начинает расти, при этом показатели IOPS и объем передаваемых данных не увеличиваются, то это означает, что какой-то ресурс СХД близок к насыщению. Как известно, система хранения работает настолько быстро, насколько быстро может функционировать ее самый медленный ресурс.
При этом разные приложения могут быть критичны либо ко времени отклика, либо к пропускной способности. Например, если мы говорим о базе данных, то обычно это произвольный доступ мелкими блоками, много чтения, и ей важны производительность в IOPS и минимальное время отклика. Для других нагрузок типа потоковых при бэкапах, записи с видеокамер или интернета вещей важнее пропускная способность, возможность записать большой поток данных.
Оптимизируется ли система хранения под конкретную задачу, или создается как универсальное решение?
Уже долгое время системы хранения, по крайней мере общего назначения, универсальны. Они не «затачиваются» под какую-то конкретную нагрузку и стараются «угодить» наиболее распространенным приложениям. Ведь примерно известно, какой профиль нагрузки у базы данных, системы резервного копирования, видеонаблюдения и так далее. Система хранения должна адекватно реагировать на такие нагрузки без каких-либо дополнительных настроек.
Поэтому системы хранения общего назначения изначально проектируются так, чтобы удовлетворить наиболее типовым задачам. Для этого применяются синтетические тесты c набором «критичных» профилей, моделирующих реальную ситуацию. В большинстве случаев работает, но реальность всегда гораздо сложнее.
Реальные нагрузки моделируются синтетикой весьма приблизительно. Это вообще наукоемкая область, потому что кроме IOPS, пропускной способности, размера блока и соотношения операций чтения и записи у нагрузки гораздо больше характеристик. Это и локализация пятна данных на диске, наличие «горячих областей», распределение запросов во времени, и равномерность их поступления. Поэтому есть вероятность, что конкретная нагрузка не попадёт ни в один из профилей. Может быть из-за особенностей программного обеспечения или специфики самой бизнес-задачи. В этом случае нужна настройка системы под конкретные задачи.
Исследуют приложение, как оно работает. И может потребоваться изменить либо работу приложения, либо настройки системы хранения. Иногда гораздо проще решить проблемы на стороне приложения с помощью какой какой-то настройки, чем заниматься изменением СХД.
А настраивается под задачу система автоматически? Нужны ли для этого искусственный интеллект? Может ли администратор или пользователь сам выбирать профиль нагрузки?
Системы хранения уже давно делают это автоматически — администратора такой задачей не загружают. Обычно стараются достигать этого без использования искусственного интеллекта —традиционными алгоритмами. Однако у ИИ большой потенциал. Если он позволит предсказывать, какие блоки данных и в какой момент времени может запросить приложение, то можно заранее к этому готовиться.
Если раньше алгоритмы оптимизации были достаточно простыми, типа упреждающего чтения, то есть при последовательном чтении данных система заранее загружала данные в кэш, или наоборот освобождала кэш-память для других данных, то теперь возможности расширяются: система сможет подготовиться к пику запросов или сложно организованному «пятну горячих данных».
Каковы должны быть масштабы оптимизации СХД? Охватывает ли она также ПО/оборудование серверов, инфраструктуру (SAN)? Предполагает ли обязательную тесную интеграцию программного и аппаратного стеков?
С точки зрения performance engineering система рассматривается целиком, в комплексе, то есть приложение, хост (сервер), инфраструктура хранения данных, (SAN), СХД. Важно представлять, как работает приложение, потому что именно оно генерирует запросы к СХД. Всё это, конечно, учитывается и используется.
Считается, что самый оптимальный вариант использования накопителей разных типов в СХД — многоуровневое хранение данных. Можно ли тиринг рассматривать как средство увеличения производительности системы хранения?
Вообще говоря, тиринг похож на кэширование — у них есть общие элементы. Разница лишь в том, что при кэшировании данные дублируются, то есть они находятся и на SSD (в кэше), и на диске, а при тиринге хранятся только в одном месте. То есть, если кэширование — это способ оптимизации производительности, то и тиринг тоже можно рассматривать как метод оптимизации.
В чем вы видите преимущества/недостатки программно-определяемых СХД (SDS) с точки зрения анализа производительности и оптимизации системы? Может быть, это более простые, более гибкие решения?
На самом деле, как раз наоборот. SDS — это распределенная система, состоящая из множества серверов, которые взаимодействуют между собой. Если используются специальные операционные системы, какие-то файловые системы, то это тоже добавляет сложности. С точки зрения инжиниринга это сложнее, но в чем-то интереснее. С другой стороны, к SDS обычно не применяются какие-то жесткие требования по производительности, в то время как к классическим системам хранения подход более строгий. То, что прощается программно-конфигурируемым системам, традиционной СХД не простят.
Одна из целей компании — разработка оптимизированных продуктов для искусственного интеллекта, интернета вещей и сетей пятого поколения. Как вы считаете, насколько сложная это задача? Что будут представлять собой такие продукты?
На данный момент для хранения сырых данных в ИИ часто используют файловые хранилища, для тренинга и построения моделей — SDS, то есть это почти всегда распределенные решения. По моему ощущению, во многих компаниях ИИ сейчас используется как некий эксперимент, на него смотрят и пытаются понять, чем он может быть полезен. Поэтому и требования к железу не очень жесткие. Если работает — хорошо, не работает — можно подождать день-другой. По мере того, как работа ИИ в компаниях будет более критичной, возрастут и требования к дисковым подсистемам. Мы увидим новые СХД решения для ИИ и интернета вещей уже mission critical-класса.
Какую роль в оптимизации ПО играет партнерство YADRO с мировыми технологическими компаниями?
С точки зрения технического специалиста оно, конечно, помогает. Такое сотрудничество способствует общению инженеров друг с другом, их доступу к информации, готовым разработкам, и не приходится каждый раз «изобретать велосипед».
Как вам видится роль виртуализации в СХД? Способствует ли она устранению узких мест в ПО или наоборот? И как взаимосвязаны производительность и надежность системы? Можно ли сохранить надежность, увеличивая производительность?
Конечно, виртуализация добавляет сложности, но она может быть полезна для изоляции одной функциональности СХД от другой. В целом это дополнительные издержки и усложнения, поэтому рассматривать ее следует критически, с осторожностью.
Что касается увеличения производительности, то на этом пути, в самом деле, легко потерять надежность. Это своего рода дуализм. Например, когда мы говорим о серверах, то для высокопроизводительного сервера (HPC) надежность обычно на втором месте. Системы хранения, как правило, должны в первую очередь обеспечивать высокую доступность, обладать соответствующей функциональностью и приемлемой производительностью. При увеличении надежности уровня резервирования, система становится сложнее. Возникает необходимость синхронизации элементов. При этом производительность системы неизбежно будет страдать. Задача разработки, свести этот эффект к минимуму.
Сейчас появляются новые классы памяти типа Storage Class Memory, Persistent Memory, совершенствуются флэш-накопители. Как это влияет на архитектуру систем? Успевает ли программное обеспечение за этими изменениями?
Ну, по крайней мере, старается. Вообще, появление быстрой памяти в значительной степени изменило работу performance-инженеров вообще в отрасли. До появления SSD подавляющее большинство проблем с производительностью ИТ систем были связаны с вводом-выводом систем хранения. Потому что есть быстрые процессоры и диски (HDD) с механическими элементами, которые на много порядков медленнее процессора. Поэтому приходилось за счёт алгоритмов пытаться сгладить задержки от медленных дисков.
С появлением быстрой памяти и алгоритмы должны меняться. Если алгоритм достаточно тяжёлый, раньше он всё равно помогал, потому что диск намного медленнее. Если удалось скрыть задержки механики – уже хорошо. С появлением SSD софт должен работать иначе. Он должен вносить минимальную задержку, чтобы получить от SSD максимум скорости. То есть снизилась необходимость в сложных алгоритмах, скрывающих задержки от дисков. Особо критичную к времени отклика базу данных с интенсивным вводом-выводом можно перенести на SSD.
Поменяет ли это архитектуру системы хранения? И да, и нет. Потому что никуда не делись диски. С одной стороны, код должен уметь работать с SSD, то есть быть очень быстрым. С другой, механические диски используются для нагрузок, которые они хорошо выдерживают, типа потоковых. При этом размер дисков многократно вырос, а скорость осталась, как и 10 лет назад.
