`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Задержки, IOPS’ы, супермаркеты, аэропорты

+77
голосов

Поговорка «время – деньги» отражает суть транзакционных приложений (Online Transaction Processing, OLTP). На них построены ERP-системы, бухгалтерский и складской учет, онлайн-торговля, банковские операции – структурированные повторяющиеся задачи обработки данных в режиме реального времени. OLTP – это способ организации баз данных, при которых система работает с потоком относительно небольших по размерам транзакций и от нее требуется минимальное время отклика. Показателем ее эффективности служит количество транзакций, выполняемых за секунду. То есть, обслуженных банковских переводов, совершенных покупок, выполненных товарных отгрузок – денег в чистом виде.

Накладные расходы транзакционных приложений тем выше, чем интенсивнее трафик между энергозависимой памятью серверов (процессорный кэш, оперативная память, с ее скоростью доступа в несколько наносекунд) и постоянными носителями систем хранения данных (СХД). Задержки ввода/вывода зависят от возможностей СХД, свойств накопителей и транспортных средств передачи данных. Приход SSD на корпоративный рынок поломал подходы к хранению данных, в OLTP-приложениях особенно. Это коснулось не только внешних СХД с многоуровневым хранением данных. В какой-то степени произошел возврат от консолидированного хранения к распределенным вычислениям на серверах с внутренними системами хранения данных (и механизмами их синхронизации на узлах). Появились решения с кэширующими хост-адаптерами и ускорителями внешних СХД на флэш-памяти. В обиход операционных серверов вошли внутренние массивы с флэш-памятью как основным или кэширующим носителем. Производительность ввода/вывода все так же зависит от сочетания накопителей и транспортной сети, но при этом ресурсом оптимизации все больше становится контроль за приложениями, запросами ввода/вывода и подбором носителей, способных обеспечить минимальные задержки в заданной структуре данных.

Дисковый ввод/вывод в операциях с произвольной выборкой

В транзакционных системах есть место и потоковым операциям (sequential access) – например, при записи временных копий баз данных и протоколов их изменений. При последовательном доступе порции данных, как правило, длинные, размещаются в смежных областях памяти устройств хранения. В таких операциях важно, какой объем данных накопители могут принять или отдать в секунду, MB/s.

Но, когда говорят о производительности устройств хранения транзакционных систем, всегда имеют в виду скорость работы под нагрузкой ввода/вывода случайного доступа, при обращениях с произвольной выборкой (random access). При доступе многопоточных приложений к ячейкам таблиц баз данных запросы короткие, адресные поля – обширные, логика обращений сложная. Имеет значение, сколько переходов между адресами и сколько операций ввода/вывода устройство успевает обслужить в секунду – IOPS (Input Output Operations per Second).

Пока HDD были единственным носителем, обеспечивающем пристойную скорость доступа под случайной нагрузкой, индустрия хранения боролась за короткие задержки и большие IOPS с физическими ограничениями жестких дисков: скоростью вращения приводов, плотностью записи на магнитной поверхности, механикой и аэродинамикой полета головок. Ускорение прохождения запросов, защиту данных и их восстановление после сбоев обеспечивали мощные многоканальные RAID-контроллеры или специализированные ОС – через объединение дисков в длинные пулы. С приходом SSD подходы стали стремительно меняться – уж очень велик разрыв в производительности между HDD и SSD, именно в операциях с произвольной выборкой.

HDD, что при чтении, что при записи, гоняют головки над магнитной поверхностью. Каждый переход между областями данных вносит задержки – на перемещение головок между дорожками (track-to-track, seek time) и вращение (пока нужный сектор не провернется и не попадет под головки, rotation latency). Набегает до десяти миллисекунд на каждую операцию ввода/вывода. Во избежание хаотических перелетов головок RAID-контроллеры упорядочивают опросы к дискам – с учетом карты адресов, расположения секторов, скорости вращения приводов. Сократить время обработки запросов (latency) помогает увеличение количества HDD в RAID-группе, распараллеливание запросов (с учетом выбранного уровня RAID), кэширование запросов в памяти контроллера массива. Но всему есть предел – механические ограничения вращающихся приводов HDD непреодолимы.

В SSD обращение по адресу ячейки памяти занимает меньше сотни микросекунд. По производительности случайного чтения в IOPS SSD в 200-400 раз быстрее HDD. Операции записи, в том числе случайной, малыми блоками, даются устройствам на флэш-памяти не так легко. При отсутствии резерва свободных (или заранее «стертых») ячеек копируется целый столбец матрицы ячеек, меняется значение ячейки и записывается обратно. Эту работу выполняет собственный контроллер SSD. Контроллеры разнообразны, далеко не все из них хорошо справляются с нагрузкой произвольного обращения малыми блоками, и далеко не все прошивки контроллеров оптимизированы под множественные запросы. Выбирая подходящие SSD, выбирают модель использования – то есть, контроллер и прошивку. Дополнительные расходы на запись и преждевременный износ ячеек SSD можно снизить увеличением служебной области, которую контроллер использует для переноса данных.

Когда диски объединены в RAID-массив, на показатели IOPS влияют четыре основных фактора:

Среднее значение IOPS в расчете на диск. Для HDD, чем выше скорость вращения шпинделя – тем выше его пределы по IOPS. Для SSD все зависит от контроллера диска, реализации микросхем флэш-памяти, прошивок, степени заполнения диска. Показатели IOPS на чтение короткими блоками (Random Read 4K IOPS) высокие у всех SSD. Высокие значения IOPS на запись (Random Write 4K IOPS) говорят о пригодности SSD для работы под нагрузкой случайного доступа.

Количество дисков – несколько дисков в составе массива выдают больше IOPS, чем один, за счет распараллеливания запросов RAID-контроллером.

Уровень RAID. У разных уровней RAID разные накладные расходы («штрафы») на операции записи. Для RAID 6 каждая команда записи операционной системы порождает шесть операций ввода/вывода на дисках. Для RAID 1 и 10 каждый запрос на запись требует двух дисковых операций. Чем меньше обращений к дискам – тем выше показатели продуктивности дисковой подсистемы.

Соотношение чтения/записи. Чем больше операций записи в структуре запросов, и чем больше накладные расходы RAID – тем ниже общее число IOPS дисковой системы.

Еще раз. В операциях случайного доступа не имеет значения переданный объем данных в единицу времени (MB/s). Важным является количество отработанных дисковой подсистемой запросов ввода/вывода (IO). В механических приводах HDD счет привязан к перемещениям головок и их маршруту, в SSD – к количеству затронутых блоков. Показатель IOPS (или KIOPS – если речь о тысячах операций в секунду) часто применяют как понятную («больше-лучше») метрику для сравнения систем хранения. Если бы все было так просто.

Latency и IOPS: в поисках смысла

Latency – это длительность обработки одного запроса ввода/вывода, задержка устройства хранения перед ответом. В отличие от довольно абстрактной метрики IOPS, latency имеет прямое физическое выражение – это время ожидания ответа приложением (пользователем). Впечатляющие значения IOPS – это то, что показывает лабораторный тест производителя системы хранения данных – для подачи ее в выгодном свете. Система может выдавать прорву IOPS, но… на операциях последовательного чтения из кэша. Или при чудовищных задержках. Или при монопольном обслуживании одного хоста. Нет стандартных методов измерения IOPS, учитывающих рабочий объем и структуру данных, процент операций записи, свойства хостов и приложений.

Задержки обработки запросов (большие значения latency) – наименее приемлемая черта транзакционных систем. Прохождение запросов сравнивают с расчетом на кассах супермаркета. Одиночное устройство хранения (кассир) в каждый момент времени обслуживает один запрос (покупателя), остальные ждут в очереди. Чем короче время обслуживания, тем быстрее движется очередь. Если устройств (касс) несколько, есть распараллеливание, ленты и считывающие устройства удобные, а кассиры проворные – очередь движется быстрее. Любое отклонение от размеренного ритма (пиковые нагрузки, разброс длин запросов, хаотические переходы между адресами, гиперактивность по записи) очередь растягивает.

В пустом супермаркете со скучающими кассирами покупатель проводит на кассе секунды (latency), а число покупателей, обслуженных за час (IOPS) измеряется единицами. В час пик в очереди можно провести несколько десятков минут (latency), при том, что кассиры успевают выдать за час сотни кассовых чеков (IOPS). Супермаркетам важнее количество (IOPS), покупателям – качество сервиса (низкое значение latency). Длинные очереди порождают больше IOPS, но при этом и latency увеличивается.

Реальные транзакционные приложения – такие, как серверы баз данных – исключительно чувствительны к времени отработки запросов (latency), особенно высоконагруженные на запись. Им, по большому счету, безразлично, сколько IOPS выдает система хранения. Небезразлично архитекторам систем хранения (управляющим супермаркетами). Их задача – создать структуру обслуживания запросов с высоким потенциалом по IOPS, но без потери качества сервиса (latency) в условиях реальной нагрузки. На взаимосвязь между значением latency и числом IOPS влияет структура приложений, размер блоков данных, которыми они оперируют, cоотношение операций чтения и записи, их распараллеливание. Эта многофакторность приводит к важному выводу: пиковую производительность в IOPS невозможно удерживать на одном уровне при различных типах операций ввода-вывода и требованиях по задержкам. А значит – нельзя использовать в качестве основной метрики производительности системы хранения.

Latency и качество сервиса

Еще одна образная аналогия – зона прилета любого крупного европейского аэропорта, принимающего десятки бортов в час. Пограничники на паспортном контроле проверяют паспорта и визы. Когда прилетает внутренний рейс, преимущественно с гражданами EU, задержки паспортного контроля минимальны и составляют секунды (вот источник высокой пропускной способности в IOPS – все запросы одинаково короткие, беглый взгляд на паспорт). Контакт с не-гражданином EU потребует большего времени, возможно, минуты. А если (приложение и длина блока таковы, что) пограничник начинает задавать вопросы о цели приезда, ожидание затянется надолго, особенно при наличии языкового барьера. Общая пропускная способность аэропорта (в IOPS) может быть большой – как в самом загруженном европейском порту, Хитроу, но проку с нее пассажирам, если там всегда длинные очереди (queue depth) и часовые задержки на прилете (latency). Кстати, в Борисполе еще хуже – и пропускная способность порта мала, и очереди обеспечены, и задержки.

Итак, latency – это мера времени выполнения одного запроса ввода/вывода, в привязке к приложению и его особенностям. Обычно говорят о миллисекундах задержек как приемлемом для баз данных уровне. Неспособность системы хранения оперативно внести изменения и завершить операцию записи приводят к большим задержкам обработки запросов, те – к удлинению очереди запросов и растратам вхолостую процессорных ресурсов. Если операции с базами данных напрямую связаны с продажами – как при веб-торговле – то стабильно высокий уровень latency оборачивается потерей пользователей и денег. Не вовремя обработанные запросы могут нарушить сервисные соглашения SLA и повлечь штрафные санкции.

«Качество сервиса» воспринимается как показатель комфорта пользователей. Для владельцев же транзакционных систем, «переплавляющих» время в деньги, большие задержки– это их прямые убытки. При всем внимании к облачным вычислениям (управляемости, гибкости, надежности, безопасности инфраструктуры), производительность была и остается основным драйвером бизнеса. Неудивительно, что многие компании возвращают свои данные в корпоративные ЦОДы, после попыток исхода на удаленные площадки (в том числе и по соображениям безопасности). Риски не стали меньше, просто работать в критических приложениях с высоким уровнем задержек решительно невозможно. Бизнес обязывает.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365

+77
голосов

Напечатать Отправить другу

Читайте также

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT