реклама
Появившись намного ранее флэш-памяти, Solid State Drive стал накопителем информации, не содержащим каких-либо механических компонентов. Пионером в создании стала корпорация Dataram, представив для промышленных целей SSD Bulk Core в 1976 году. Он содержал в себе 8 планок энергозависимой RAM-памяти, каждая из которых имела объем 256 килобайт. Стоимость составляла 9700 долларов США. Работал, был востребован, но из-за уязвимости данных высокого авторитета в соответствующих кругах не заслужил.
Потребительский класс стали завоевывать в 1982 году, оснастив компьютер Apple II внешним накопителем RAM Disk, который стоил дороже самого компьютера, поэтому пользователями был принят с большой осторожностью, несмотря на агрессивную рекламу.
Далее, в силу собственного характера и темперамента, я пропущу историю создания и распространения флеш-памяти, пропущу и пересказ того, как был создан первый SSD на ее основе. Всю эту информацию с легкостью можно почерпнуть в сети, готовясь к какому-нибудь докладу или создавая презентацию по теме. А вот на видах и классификациях современных SSD мы с вами задержимся:
Память
реклама
Флеш-память различается методом соединения ячеек в массив. И имеет 2 конструкции: NOR и NAND.
NAND-тип флеш-памяти нам максимально интересен и он был анонсирован Toshiba в 1989 году на International Solid-State Circuits Conference.
1. Планарный тип или 2D.
реклама
реклама
Важной особенностью линии развития памяти в цепочке SLC-MLC-TLC является увеличение уровней ячеек. Но. резко падает выносливость, грубо говоря до серьезных цифр (на порядки) падает число циклов полной перезаписи. Да и скорость падает. Прямо регресс какой-то. Успокаивает то, что цена тоже падает и, как это ни странно, падает ощутимо. Плюс растет качество контроллеров, да всегда уменьшается техпроцесс. Впрочем, чтобы глубоко не погружаться в технические джунгли самому и не замучить вас, мои читатели, скажу, что эти страшные цифры снижения выносливости с переходом применения памяти от одной к другой вряд ли будут опасны для простого пользователя. Этих цифр хватит, чтобы мы с вами пользовались своим новым SSD много лет. Другое дело сервера и рабочие станции. Тут уж не грех и про эту самую «выносливость» подумать. Но и производители не дремлют. Линейка PRO некоторых производителей, например, говорит нам о том, что диск на основе MLC прослужит долго при максимальных нагрузках, но и стоить будет значительно дороже аналога на TLC. Подведя промежуточный итог на этапе рассказа о типах памяти скажем так: SLC получила распространение в корпоративном сегменте, TLC стала безусловным монополистом в рознице, а продукция на основе MLC ориентирована, в первую очередь, на тех, кто ценит надежность и при этом хочет выжать все возможное из своей машины.
Все бы так и оставить, но потенциал двумерной NAND оказался ограничен. С этого я начал свой рассказ о памяти. Когда возможности 15-нанометрового технологического процесса были практически исчерпаны, а дальнейшее совершенствование программной части перестало обеспечивать сколь-либо заметного прироста важнейших показателей, на смену планарным микросхемам пришла флэш-память 3D NAND.
2. 3D NAND
После того, как мы поговорим чуточку о другом, к видам памяти мы еще вернемся, да и у вас, мои дорогие читатели, появится повод дочитать мои размышления до конца.
А поговорим мы о физическом интерфейсе подключения и форм-факторе, что иногда одно и тоже, в свете разговора о пропускной способности. И здесь мы начнем с маленькой, но важной закономерности. Неважно сколько лет мы подключаем свои HDD к шине для накопителей, важно, что сможет позволить этот интерфейс нашей памяти. С какой скоростью он позволяет обмениваться информацией? Вспомним азбучные вещи:
1. IDE / SATA/
Кому-то интересно будет узнать, что IDE SSD тоже были как в форм-факторе 2,5 дюйма, так и 3,5, а вот список привычных интерфейсов пользовательского уровня для внутренних носителей: SATA 2 интерфейс обратно совместим и поддерживается на SATA 1 портах. SATA 3 интерфейс обратно совместим и поддерживается на SATA 1 и SATA 2 портах. Однако максимальная скорость диска будет медленнее из-за скоростных ограничений порта.
Как эти азбучные данные применить к размышлениям о SSD? А вот как:
Например, SanDisk Extreme SSD поддерживает интерфейс SATA 6 Гбит/с и при подключении к портам SATA 6 Гбит/с может доходить до 550/520MБ/s последовательного чтения и последовательной записи соответственно. Однако, когда диск подключен к порту SATA 3 Гбит/с, она может доходить до 285/275MБ/s последовательного чтения и последовательной записи соответственно. В любом случае, это будет много быстрее, чем использование даже самого скоростного HDD.
Дальше возник совершенно простой вопрос. Поскольку память для SSD способна работать и на гораздо больших скоростях, а развитие и физические возможности интерфейса SАТА и всех его итераций исчерпали себя, то надо дать что-то другое данным носителям информацми. Дать новое или уже имеющееся и применяемое. Кстати, несмотря на то, что SАТА для HDD вполне достаточный интерфейс, задумывались о новом, как раз для HDD дисков. А применять стали для SSD. Что же нашли? А вот что:
Далее я просто приведу пример других известных форм-факторов без комментариев. Потом вернемся к обсуждению новейших видов памяти с привязкой ее к этим форм-факторам и их интерфейсам. Мне кажется, что так нам будет легче внести ясность в предмет обсуждения:
Экзотику лишь упомянем. Это, например, накопитель, который вставляют прямо в слот оперативной памяти
Еще один, который сейчас редко встретишь. SATA-Express, с интерфейсом, использующим 2 линии PCI-Express, что позволяет достигать максимальной пропускной способности в 2 ГБ. Реализации не нашел. Сейчас SSD-диски M.2 (забегая немного вперед) могут использовать 4 линии PCI-Express с пиковой пропускной способностью 4 ГБ/с. Для подключения используется специальный кабель.
2. mSATA
3. PCI-E AIC (add-in-card)
4. U.2
двигаемся дальше и поговорим о
это новый стандарт SSD-накопителей. Обычные SSD различных форм-факторов работают по интерфейсу SATA, который передает информацию медленнее, чем на это способен сам накопитель. NVMe работает по интерфейсу PCI Express, производительности которого нам за глаза хватает. Диск NVMe выдает бо́льшую скорость чтения-записи данных.
Плывя по течению простых рассуждений о твердотельных накопителях, мы приближаемся к финалу повествования и вновь вспоминаем мою короткую историю в самом начале. OPTANE+QLC. Надо разобраться. Для этого мы мысленно возвращаемся в раздел Память. Начнем с несколько противоречивого лично для меня этапа развития памяти:
3D NAND QLC.
OPTANE. Intel Optane. Optane Memory.
Что сказать? Младшая версия обойдется нам от 25000 рублей, старшая в 2 раза дороже. Еще раз подчеркну, что здесь мы имеем бескомпромиссную скорость, заявленную надежность, хорошую гарантию и тот объем, который мы захотим себе позволить (из имеющихся).
Я, начиная свой рассказ c прочтенной когда-то рекламы, и поверхностно погрузив вас в тонкости информации о SSD, принял для себя решение о том, какой SSD я бы хотел иметь в своем компьютере. И я приобрел его. Это «всего лишь»:
Безусловно пора заканчивать. В самом финале скажу следующее:
2. Мною не тестировался приобретенный накопитель. Такие тесты уже есть. Плюс, я даже не сказал, какой накопитель у меня был до этого. Не было такой цели.
3. Попытался рассказать попроще о довольно сложном. Возможно, данный материал здесь, учитывая высокий уровень теоретической и практической подготовки наших читателей, поможет кому-то ответить на еще не возникшие вопросы.
Что такое IOPS и как его посчитать?
IOPS используется для определения производительности диска или дискового массива.
Основными измеряемыми величинами являются операции линейного (последовательного) и произвольного (случайного) доступа.
Под линейными операциям чтения/записи, при которых части файлов считываются последовательно, одна за другой, подразумевается передача больших файлов (более 128 К). При произвольных операциях данные читаются случайно из разных областей носителя, обычно они ассоциируются с размером блока 4 Кбайт.
В зависимости от вида операции, этот размер может варьироваться от байт до килобайт и даже нескольких мегабайт. Существует множество типов ввода/вывода и многозадачная и многохостовая система почти никогда не использует какой-то один. Виртуализация только добавляет разнообразия к паттернам ввода/вывода.
Никакая система хранения не может показывать максимальные значения IOPS безотносительно к характеру операций ввода/вывода, значений latency и размеру блоков.
Latency это мера того, сколько времени занимает выполнение одного запроса ввода/вывода, с точки зрения приложения.
Приложения которые интенсивно используют операции на запись являются хорошими кандидатами для RAID 10, тогда как приложения которые интенсивно используют операции на чтение могут быть размещены на RAID 5.
IOPS используются для определения производительности диска или дискового массива. Для примера можно считать, что максимальный IOPS для диска:
Вычислим максимальный IOPS для диска
Для примера возьмем диск: Seagate ST500DM002-1BC142
Чтобы вычислить IOPS используем уравнение:
Вычисляем максимальное значение IOPS для дискового массива
В примечании к разработке системы хранения, вычисление производительности дисковой системы имеет решающее значение для работы данной системы. Большинство систем используют RAID для обеспечения избыточности хранилища. В этом разделе описывается, как вычисляются IOPS для RAID-массивов.
Максимальное значение IOPS для чтения
Вычисление максимального значения IOPS чтения (maxReadIops) для RAID-массива:
maxReadIops = numDisks * diskMaxIops
Соответственно для массива из 4 дисков максимальное значение IOPS чтения будет следующим:
Максимальное значение IOPS для записи
Штраф на запись RAID-массива
Наиболее распространенные типы RAID и их штрафы на запись определяются в следующей таблице:
| RAID Type | Write Penalty |
|---|---|
| RAID 1 | 2 |
| RAID 5 | 4 |
| RAID 6 | 6 |
| RAID 10 | 2 |
Чтобы вычислить максимальное значение IOPS записи (maxWriteIops) для заданного RAID-массива, разделим максимальное значение IOPS чтения (maxReadIops) на штраф за запись RAID-массива (raidWritePenalty): maxWriteIops = maxReadIops / raidWritePenalty
Используя наш пример с 4-мя дисками и конфигурацией RAID 10, получаем следующие значения:
Проектирование для производительности
Простое вычисление максимального количества IOPS для чтения и записи для существующего или будущего RAID-массива недостаточно. Для обеспечения последовательной и устойчивой производительности необходимо определить требования к производительности для системы, чтобы определить лучшее решение для диска. Минимальный требуемый IOPS должен быть определен таким образом, чтобы можно было приобрести необходимое количество дисков с требуемой скоростью.
Для начала необходимо знать требования к производительности (например, чтение и запись IOPS) для данной системы или приложения. Эта информация может быть получена из документации поставщика или программного обеспечения.
Вычисление минимально необходимого IOPS
Чтобы вычислить минимальное количество IOPS (minReqdIops), добавьте количество требуемых IOPS чтения (reqdReadIops) к сумме количества требуемых IOPS записи (reqdWriteIops) и штрафа RAID (raidWritePenalty): minReqdIops = reqdReadIops + (reqdWriteIops * raidWritePenalty)
ПРИМЕЧАНИЕ. Этот расчет определяет минимальное количество IOPS, необходимое для соответствия спецификации производительности. Это означает, что дисковый массив НЕ должен работать ниже этого уровня производительности.
Вычисляем минимальное количество дисков для RAID-массива
Как только минимальное количество требуемых IOPS определено, очень легко определить минимальное количество и скорость дисков, необходимых для создания RAID-массива для удовлетворения требований к производительности.
Минимальное количество дисков по скорости диска
Минимальное количество дисков, необходимых для выполнения нашего требования к производительности (minNumDiskMinPerf), рассчитывается следующим образом: minNumDisksMinPerf = minReqdIops / maxIopsByDiskSpeed
Используя информацию из расчета минимально необходимых IOPS выше и предполагая, что мы хотим создать массив из 10 000 RPM-дисков (
125-150 IOPS), вычисление минимального количества дисков, которое будет соответствовать нашим минимальным требованиям к производительности (minNumDisksMinPerf) 1800 IOPS (minReqdIops) выглядит следующим образом:
Минимальное количество дисков по типу RAID
Тип RAID определяет минимальное количество дисков для удовлетворения требований типа RAID. Например, для RAID 5 всегда требуется как минимум 3 диска. Для RAID 10 всегда требуется как минимум 4 диска.
Для любых массивов, требующих большого количества дисков, используйте множитель в приведенной ниже таблице, чтобы определить правильное количество дисков для соответствия требованиям типа RAID:
| Тип RAID | Количество дисков | RAID множитель |
|---|---|---|
| RAID5 | 3 | N/A |
| RAID10 | 4 | 4 |
После вычисления количества дисков по скорости, определяем минимальное количество дисков, требуемых по типу RAID.
В примере, когда 10K RPM-диски были выбраны для построения массива, расчет показывает, что требуется не менее 14 дисков. Если тип RAID будет 5, 14 дисков будет достаточным. Однако, если тип RAID будет равен 10, минимальное количество дисков, требуемых этим типом RAID, будет 8, поскольку множитель для RAID 10 равен 4.
Программы для измерения IOPS
IOmeter — тест IOPS
IOzone — тест IOPS
FIO — тест IOPS
CrystalDiskMark — тест IOPS
SQLIO — набор тестов для расчета производительности (IOPS, MB, Latency) под сервера БД
wmarow — калькулятор RAID по производительности IOPS
«20 тысяч IOPS на узел — хорошие показатели с учётом задержек в 5 мс». Для OLTP — нет
Поводом написать эту статью стал весьма достойный обзор Как мы тестировали VMware vSAN. компании КРОК. Обзор-то достойный, но в нем есть фраза, с которой я борюсь уже больше десятка лет. Админы СХД, виртуализаторы и интеграторы раз за разом повторяют: «Задержки в 5 мс — это отличный показатель». Даже цифра в 5 мс десять лет не меняется. Я это слышал вживую от весьма уважаемых админов уже не меньше десятка раз. От менее уважаемых — десятки, а уж сколько раз читал в интернете… Нет, нет, нет. Для OLTP нагрузок 5 мс, особенно так, как их обычно измеряют — это epic fail. Мне приходилось объяснять причины этого уже много раз, на этот раз я решил собрать свои мысли в переиспользуемую форму.
Сразу оговорюсь, что в упомянутой выше статье этих ошибок нет, скорее фраза сработала как триггер.
Типичное начало
Всё что описано в данной статье, верно для распространенных СУБД, используемых для типичной бизнесовой OLTP. Больше всего у меня опыт с MS SQL Server, но, как минимум, для PostgeSQL, Oracle и Sybase многие моменты и выводы также останутся верны.
На этом уровне уже сервер не стоит под столом директора, диски уже не внутри сервера, а в СХД, разработчики знают про индексы, а администраторы уже умеют PowerShell, и менеджеры ИТ начинают говорить умные слова типа SLA и RPO/RTO. Вот на этом уровне возникает интересная ситуация:
Кстати, всё вышесказанное не только про «свои» сервера, но и про облачные сервисы и виртуализацию. Там есть кучка своей специфики, но типичная клиническая картина примерно та же: в меру оптимизированная БД, неглупые сотрудники разработки и сопровождения, по процессору и памяти резерв есть, «выхлоп» от дальнейших вложений почти равен нулю.
Так вот. Эта вся песня про «5 мс» чушь и ерунда. Если вы сами такое говорите — читайте эту статью. А если вам такое говорят — готовьте аргументы. Раньше, когда я слышал эти слова, я злился, но я уже не злюсь. У меня, как у того горшка с петуньей из «Автостопом по галактике» только одна мысль: «Ну вот опять. «.
Кто виноват?
Почему БД такая медленная? Ну казалось бы, типичный сервер с 20-64 ядрами на частоте 2-3 ГГц способен выполнить 50-150 миллиардов простых операций, а максимальные (синтетические) тесты баз данных показывают на подобных машинах всего лишь 10000-50000 транзакций в секунду. Эй! Это ж от миллиона до десятка возможных миллионов операций на транзакцию. Это не просто много, это очуметь как много.
Такого оверхеда стоят ACID-требования к транзакциям.
К слову, буква-в-букву эти требования не выполняются почти нигде и никогда, а в распределённых системах просто никогда (CAP-теорема мешает). Для нашей ситуации скорее всего дороже других стоит требование «D», это требование обеспечивается ключевым механизмом всех распространенных OLTP СУБД: WAL, write-ahead log (PostgeSQL), он же журнал транзакций (SQL Server), он же REDO log (Oracle). Вот он — камень на шее производительности, и он же фундамент Durability транзакций.
Что такое WAL
Давайте ненадолго забудем про современные SSD, про крутые СХД. Пусть у нас есть сервер, в нем один или несколько дисков.
Любая транзакция, даже вставка одной записи, как минимум потенциально, а на самом деле почти всегда и реально — неатомарное действие. Нам почти всегда нужно изменить не только ту страницу, где лежит запись, но и страницы индексов, возможно, служебные страницы. При этом в одной транзакции одна и та же страница может поменяться много раз. Плюс у нас параллельно могут выполняться другие транзакции. Более того — соседние во времени транзакции постоянно «теребят» одни и те же страницы. Если мы будем дожидаться записи каждой страницы на диск перед продолжением действий, а именно это по сути требуется в Durability, то нам придётся записывать во много раз больше и ждать обязательного окончания каждой записи на энергонезависимый носитель. Никаких кешей, никакой перестановки операций в очереди, а иначе не будет целостности! Более того, нам как-то надо отмечать какие данные уже по фиксированным транзакциям, а какие — ещё нет (и какие были данные раньше). Для понимания — типичный одиночный жёсткий диск (HDD) в таком режиме даст 50-100 IOPS и это константа уже 20 лет. На одну даже маленькую транзакцию потребуется 5-10 операций записи. Ах, да, чтобы знать, что записывать — надо прочитать. Даже очень-очень высоконагруженные на запись OLTP системы читают в раза 3 больше чем пишут. Таким образом наша транзакция стоит 20-40 IO, а значит 0,2-0,8 секунд на диск.
2 транзакции в секунду. Маловато? Давайте попробуем раскидать по дискам? Ой, а нам надо всё равно дожидаться пока предыдущий запишется и параллельность в итоге отсутствует. Как быть? А давайте заведем файл-журнал в который будем последовательно записывать все операции записи в БД и отметки транзакций! Плюсы:
Такой журнал и называется write-ahead log/transaction log/REDO log.
Ура! Супер! Было 2 транзакции в секунду, стало 300 — улучшили в 150 раз. А какой ценой? Как выясняется, цена значительна:
Это объяснение очень упрощенное, «на пальцах». Для нашей темы этого хватит. WAL — ключевой, фундаментальный механизм обеспечения транзакционности, он обязательно write-through, доступ однопоточный только на последовательную запись, с точки зрения хранилища глубина очереди 1.
Тему write-ahead logging в БД должен хотя бы в минимальном объёме знать каждый, кто так или иначе администрирует СУБД, или инфраструктуру СУБД, или разрабатывает базы данных.
WAL и СХД
Производители СХД «с рождения» сталкиваются с СУБД. Именно для баз данных бизнес покупает эти безумно дорогие комплексы: от street price хранилищ Dell-EMC, HP, Hitachi, NetApp при верстке бюджета глаза наполняются слезами у большинства топ-менеджеров, если они, конечно, не получат процент от этой цены. Но тут есть инженерно-маркетинговый конфликт. Я его поясню на примере Dell-EMC, но только потому что помню, где у них документация.
А маркетологам надо продавать. Гиперконвергентность! Виртуализация! Гибкость развертывания! Дедупликация! Простота настройки! Много-много IOPS! Красивые презентации, уверенный голос, строгие костюмы. Ну а как иначе продать решение с 6-7-значным ценником в долларах? За этим как-то забывается, что от СХД можно добиться либо latency, либо throughput, но не обоих сразу, что какая-нибудь лицензия на балансировщик нагрузки стоит как еще одна полка, что если интенсивная запись будет длиться больше часа, то оперативной памяти контроллеров не хватит и производительность просядет до «как будто кеша нет», что обучение сотрудников заказчика стоит еще 100000 рублей за первый курс, ну и подобные уловки…
То ли наслушавшись-начитавшись маркетологов, то ли от лени, то ли ещё из-за каких-то тараканов, но почему-то часто админы СХД делают примерно так. Берем большую полку, всю её объединяем в что-то плоское, нарезаем на thin provisioned LUNs и раздаём по LUN на сервер. Или по два, потому что «системный раздел хорошо дедуплицируется». А когда, я вижу, что с дисковой подсистемой со стороны SQL ад-ад-ад, то начинается та самая песня, что «5 мс отличный показатель», что «100000 IOPS», «Ваша нагрузка на СХД менее 5%»
Когда какая-нибудь загрузка данных на ноутбуке разработчика выполняется 5 минут, а на 40 ядерном сервере с 1 ТиБ RAM и СХД за полмиллиона долларов та же самая задача выполняется час, то даже у самых терпеливых заказчиков появятся вопросы обоснованности затрат.
| Средняя задержка на разделе с WAL | никогда не будет в секунду больше транзакций, чем: |
|---|---|
| 5 мс | 200 |
| 1 мс | 1000 |
| 0,5 мс | 2000 |
| 0,1 мс | 10000 |
| 0,05 мс | 20000 |
Что делать
Советы администраторам и DBA
Для OLTP перестаньте считать «утилизацию» и IOPS. Отдельно замечу — совсем не смотрите на IOPS с большой глубиной очереди: даже на разделах с данными большие очереди обычно короткий всплеск или что-то, что не влияет на реальную производительность OLTP.
Делить дисковое пространство на LUN — это не прихоть DBA. У базы данных есть несколько разных профилей нагрузки дисковой подсистемы. Как минимум можно выделить следующее:
Есть и другие виды нагрузки, но они слегка экзотичны (например, может быть хранилище файлов, хранящихся в БД в виде каталога FileStream). У всех этих видов нагрузки разные, зачастую противоречащие требования к дискам. Если они все свалены на один раздел, то вы не только ухудшаете производительность, но очень важно, что лишаетесь возможности понять из-за чего система тормозит, а также лишаетесь возможности улучшить только ту часть которая требует улучшения без глобальных улучшений/апгрейдов СХД. Поэтому главная рекомендация:
Ознакомьтесь с рекомендациями производителя СХД и СУБД, постарайтесь разобраться «почему они так советуют» и спроектируйте систему с учетом разных видов нагрузки. Разнесите принципиально разные виды нагрузки на разные разделы.
MS SQL Server
Если говорить про MS SQL, то на самом деле есть некоторое количество способов снизить нагрузку на bottleneck журнала транзакций, может кому-то поможет:
Вот и всё. Нет никой магии. 20000 IOPS с 5 мс latency и с очередью 4-16 ничего не говорит о производительности СХД для задач OLTP. Для OLTP надо правильно размечать СХД, правильно выбирать метрику производительности и уметь измерять её.
На горизонте есть очень интересный новый участник борьбы за производительность систем хранения для БД. Это Intel Optane. У нынешних SSD «красивые» цифры производительности начинаются от глубины очереди 4, что на самом деле не очень жизненно. Плюс эта производительность на запись обеспечивается некоторым объёмом оперативной памяти внутри SSD, и, если запись идёт достаточно интенсивно, то потом наступает существенная деградация производительности. А еще у SSD ограничен ресурс. Да, у современных серверных и топовых «гражданских» он достаточно большой, но совсем не бесконечный. И тут на сцене появляется Intel Optane: судя по тестам несерверных моделей (раз, два ) задержки на случайных операциях на очереди глубины 1 выходят на уровень около 20 микросекунд. Это по сути без кеширования, без деградации. SSD при таком же профиле начинают тупить до 100-300 мкс. Ресурс уже сейчас выходит за типичный ресурс SSD.
Ну цена, да. Но потенциально эта железка открывает новые горизонты производительности OLTP «традиционной», не in-memory архитектуры без отказа от ACID. А с другой стороны latency 20 мкс заставляет задуматься о судьбе «обычных» СХД. На low-latency требованиях им будет очень тяжело конкурировать с Optane (снова привет встроенным системам хранения?).
Это всё очень круто и я надеюсь на успех (и подешевление) Optane.
eugeneb0 и apatyukov за добрые советы и вычитку.
