На что влияет размер единицы распределения
Какой размер кластера выбрать при форматировании
При форматировании диска или флешки вы наверняка замечали, что система предлагает вам выбрать размер так называемого «кластера». Его размер варьируется от типа файловой системы диска. К примеру, для NTFS минимальный размер кластера составляет 512 Байт, а максимальный – 64 Кб. Для FAT32 – от 4 до 64 Кб. Зачастую на выбор доступно много вариантов, которые могут поставить неподготовленного пользователя перед логичным вопросом: какой размер кластера выбрать при форматировании флешки, диска или любого другого накопителя?
Что такое размер кластера
Кластер (Allocation Unit Size, англ.) – это блок, в который система будет записывать информацию на вашем накопителе. Весь диск (флешка) состоит из большого массива этих блоков, каждый из которых содержит в себе определенное количество данных. Размер кластера не влияет на объем диска, но он может повлиять на то, как система работает с файлами на вашем носителе и насколько эффективно использует доступное ей пространство.
Какой размер кластера выбрать
Вы вряд ли заметите невооруженным взглядом разницу при использовании различных размеров кластера, но этот параметр все-таки влияет на производительность файловой системы. При выборе размера кластера все зависит от того, для чего вы будете использовать носитель. Если вы будете сохранять много мелких файлов, тогда лучше уменьшить размер кластера, чтобы система не тратила место зазря. Если же содержимое диска состоит в основном из огромных файлов, тогда можно увеличить размер кластера, что увеличит производительность, поскольку Windows будет проводить меньше обращений к ячейкам
Лучше понять это поможет простой пример:
Если у вас есть файл размером 3 Кб, а размер кластера равняется 4 Кб, тогда файл займет весь кластер или ячейку. Это значит, что 1 Кб свободного пространства будет потерян. В потерянное пространство записать другие файлы нельзя, поэтому место фактически теряется впустую. На 10 таких файлах потеря составит уже 10 Кб, на 100 – 100 Кб, на 1000 – 1000 Кб и так далее. В таком случае лучше использовать размер кластера 512 байт или 1 Кб, поскольку файл займет шесть или три кластера без фрагментации и не будет тратить ячейки диска зря. Таким образом увеличивается эффективность хранения информации, но при этом уменьшается производительность, поскольку системе надо выполнять больше обращений к блокам.
В современном мире размеры накопителей становятся все больше и больше, а вместе с этим размер кластера играет все меньшую и меньшую роль. Исходя из этого, универсальным решением будет использовать параметры размера кластера по умолчанию и не менять их. Конечно, если вы дотошный пользователь, который хочет делать все как надо и по руководству, тогда исходите из того, что для больших файлов используем большой размер кластера, а для маленьких – маленький. Но опять же, особой разницы вы не заметите, если только не храните десятки и сотни тысяч файлов объемом 2-3 Кб на своих флешках или жестких дисках.
Как узнать размер кластера диска или флешки
Простая команда, выполненная в командной строке, позволит вам узнать, какой размер кластера используется на подключенном к компьютеру диску. Примечание: для выполнения этой команды вам нужна учетная запись с правами Администратора. Если ваш профиль не имеет этих прав, система попросит ввести пароль Администратора.
Теперь вы знаете для чего нужен размер кластера и из какого принципа исходить при форматировании диска или флешки.
Определяемся с размером кластера при форматировании USB накопителя в NTFS
При форматировании USB накопителя или жесткого диска обычными средствами ОС Windows в меню есть поле «Размер кластера». Обычно пользователь пропускает это поле, оставляя его значение по умолчанию. Также причиной этому может стать то, что нет подсказки относительно того, как правильно выставить этот параметр.
Какой выбрать размер кластера при форматировании флешки в NTFS
Если открыть окно форматирования и выбрать файловую систему NTFS, то в поле размер кластера становятся доступными варианты в диапазоне от 512 байт до 64 Кб. 
Давайте разберемся, как влияет параметр «Размер кластера» на работу флешки. По определению, кластер представляет собой минимальный объем, выделенный для хранения файла. Для оптимального выбора этого параметра при форматировании устройства в файловой системе NTFS нужно учитывать несколько критериев.
Данная инструкция понадобится Вам при выполнении форматирования съемного накопителя в NTFS.
Критерий 1: Размеры файлов
Определитесь с тем, файлы какого размера вы собираетесь хранить на флешке.
Например, размер кластера на флешке 4096 байт. Если скопировать файл размером 1 байт, то он займет на флешке все равно 4096 байт. Поэтому для небольших файлов лучше использовать размер кластеров поменьше. Если же флешка предназначается для хранения и просмотра видео и аудио файлов, то размер кластера лучше выбрать побольше где-то 32 или 64 кб. Когда флешка предназначена для различных целей, то можно оставить значение по умолчанию.
Помните, что неправильно выбранный размер кластера приводит к потере пространства на флешке. Система выставляет стандартный размер кластера 4 Кб. И если на диске есть 10 тысяч документов по 100 байт каждый, то потери составят 46 Мб. Если вы отформатировали флешку с параметром кластера 32 кб, а текстовый документ будет всего 4 кб. То он все равно займет 32 кб. Это приводит к нерациональному использованию флешки и потере части пространства на ней.
Корпорация Microsoft для расчета потерянного пространства использует формулу:
(размер кластера)/2*(количество файлов)
Критерий 2: Желаемая скорость обмена информацией
Учитывайте тот факт, что от размера кластера зависит скорость обмена данных на вашем накопителе. Чем больше размер кластера, тем меньше операций выполняется при обращении к накопителю и тем выше скорость работы флеш-накопителя. Фильм, записанный на флешке с размером кластера 4 кб, будет воспроизводиться медленнее, чем на накопителе с размером кластера 64 кб.
Критерий 3: Надежность
Примите к сведению, что флешка, отформатированная с кластерами больших размеров более надежна в эксплуатации. Уменьшается количество обращений к носителю. Ведь, надежнее отправлять порцию информации одним большим куском, чем несколько раз маленькими порциями. 
Имейте в виду, что с нестандартными размерами кластеров могут быть проблемы с софтом, работающим с дисками. В основном это служебные программы, использующие дефрагментацию, а она выполняется только при стандартных кластерах. При создании загрузочных флешек размер кластера также нужно оставлять стандартным. Кстати, выполнить данную задачу Вам поможет наша инструкция.
Некоторые пользователи на форумах советуют при размерах флеш-накопителя более 16 Гб, разделять его на 2 тома и форматировать их по разному. Том меньшего объема отформатировать с параметром кластера 4 Кб, а другой под большие файлы под 16-32 Кб. Таким образом будет достигнута и оптимизация пространства и нужное быстродействие при просмотре и записи объемных файлов.
Итак, правильный подбор размера кластера:
И если Вы затрудняетесь с выбором кластера при форматировании, то лучше оставляйте его стандартным. Также можете написать об этом в комментариях. Мы постараемся помочь Вам с выбором.
Помимо этой статьи, на сайте еще 12496 инструкций.
Добавьте сайт Lumpics.ru в закладки (CTRL+D) и мы точно еще пригодимся вам.
Отблагодарите автора, поделитесь статьей в социальных сетях.
Какой кластер выбрать при форматировании флешки
При проведении форматирования жесткого носителя данных, операционная система предлагает пользователю определиться с двумя основными задачами – видом файловой системы и какой размер кластера выбрать при форматировании флешки или жесткого диска. Фундаментальная задача пользователя состоит в грамотном и взвешенном выборе кластера для последующей корректной и оптимизированной работы жесткого носителя данных.
Что такое файловая система
Файловая система – это определенный вид разметки дискового накопителя. Другими словами, это порядок построения файловых данных и их каталогов на жестком носителе. На сегодняшний день существуют более 50 видов файловых систем, но наиболее востребованными являются FAT 32, NTFS и exFAT.
FAT 32 – такой вид файловой системы, при котором данные, размер которых больше 4 ГБ не смогут сохраниться на флешке или другом носителе, а также отсутствует поддержка регулирования прав доступа к материалам диска. Этот вариант идеально подойдет владельцам у которых нет необходимости записи и переноса данных больших размеров, а также носителей с небольшим объемом памяти от 1 до 8 ГБ.
NTFS – это одна из популярнейших категорий файловых систем, которая устанавливается операционной системой по умолчанию при процессе форматирования. Характеризуется оптимальным использованием дискового пространства и встроенной возможностью ограничения доступа к данным конкретным пользователям.
exFAT – файловая система, которая характеризуется широчайшими пределами размеров файлов, в отличии от системы FAT 32 и применяется в современных флешках больших объемов. На сегодняшний момент является альтернативой NTFS.
Что такое размер кластера
Размер кластера – это самая наименьшая единица памяти флешки, которая выделяется для конкретного файла. На сегодняшний момент для флешек можно подобрать различный объем кластера, начиная от 512 Б и заканчивая 32 МБ в прямой зависимости от целей, для которых будет эксплуатироваться внешний диск. Кроме того, следует уточнить, что различные файловые системы переносных дисков предоставляют абсолютно различные размеры кластеров. Так, FAT 32 позволяет создавать кластеры размером до 32 КБ, система NTFS – до 64 КБ, а exFAT позволил осуществить создание кластера в максимальном объеме – от 512 Б до внушительных 32 МБ. Чтобы решить вопрос какой кластер выбрать при форматировании флешки, необходимо понять на что влияет размер самого кластера.
При форматировании переносного жесткого диска, выбранный размер кластера в первую очередь оказывает влияние на объем памяти, которую возможно будет использовать для хранения файлов самых различных размеров. Предпочтение незначительного размера кластера позволяет сохранять больший объем небольших файлов на жестком носителе, поскольку они станут занимать меньше места на нем.
Чтобы более подробно разобраться с этим вопросом, можно привести следующий пример. Если конкретный объект (текстовый документ, картинка и другие) имеет размер 1 КБ, а размер кластера составляет 32 КБ, то данный файл займет все 32 КБ памяти на диске. Если же размер кластера составляет, например, 4 КБ – то файл использует только 4 КБ, что позволит сэкономить целых 28 КБ памяти для записи других данных.
Какой класстер выбрать
В первую очередь чтобы определиться с тем, какой кластер выбрать при форматировании флешки, необходимо отталкиваться от размера носителя и от размеров данных, которые будут на него записываться и храниться.
Если флешка будет применяться для хранения крупных данных, например, игр, фильмов и музыки, то следует остановить свой выбор на большем размере кластера, от 32 Кб и больше, что позволит считывать данные более быстро. Если же носитель данных предназначен для работы с множеством файлов с небольшим размером, то целесообразно установить кластер меньшего объема, например, от 4КБ и ниже, при этом процесс введения и вывода данных будет максимально оптимизирован.
Размер кластера по умолчанию для файловых систем FAT, NTFS и exFAT
Аннотация
Во всех файловых системах, используемых Windows, дисковое пространство организовывается с учетом размера кластеров (или размера единицы распределения). Размер кластера — минимальный объем дискового пространства, который может быть выделен для хранения файла. Таким образом, если размер файла не кратен размеру кластера, для его хранения необходимо использовать дополнительное пространство (кратное размеру кластера). При обычном разделении пространства на жестком диске средний объем памяти, потерянной в таком случае, можно рассчитать по формуле (размер кластера)/2 * (количество файлов).
Если размер кластера не задан во время форматирования раздела, используются значения по умолчанию, зависящие от размера раздела. Эти значения выбираются с учетом оптимального соотношения теряемого объема и числа кластеров в разделе.
Дополнительная информация
Раздел (том) жесткого диска можно отформатировать под файловую систему NTFS, FAT или exFAT. В зависимости от метода форматирования раздела в Windows могут использоваться следующие значения по умолчанию.
С помощью команды FORMAT без указания размера кластера.
С помощью программы Windows Explorer, когда в поле Единица размещения в диалоговом окне Формат оставлено значение Стандартный размер размещения.
По умолчанию размер кластера для файловой системы NTFS в Windows NT 4.0 и более поздних версий равен 4 КБ. Это обусловлено тем, что сжатие файлов в NTFS невозможно для дисков с большим размером кластера. Команда форматирования не использует размер кластера больше 4 КБ, кроме случая, когда пользователь переопределяет значения по умолчанию. Вы можете сделать это, используя /А: переключение вместе с командой Format или с помощью указания большего размера кластера в соответствующем поле при форматировании с помощью проводника.
Размеры кластера по умолчанию для файловой системы NTFS
В следующей таблице описаны размеры кластера по умолчанию для NTFS.
Windows 7, Windows Server 2008 R2, Windows Server 2008, Windows Vista, Windows Server 2003, Windows XP и Windows 2000
Какие факторы влияют на производительность систем хранения и как?
Системы хранения данных для подавляющего большинства веб-проектов (и не только) играют ключевую роль. Ведь зачастую задача сводится не только к хранению определенного типа контента, но и к обеспечению его отдачи посетителям, а также обработки, что накладывает определенные требования к производительности.
В то время, как при производстве накопителей используется множество других метрик, чтоб описать и гарантировать должную производительность, на рынке систем хранения и дисковых накопителей, принято использовать IOPS, как сравнительную метрику, с целью «удобства» сравнения. Однако производительность систем хранения, измеряемая в IOPS (Input Output Operations per Second), операциях ввода / вывода (записи / чтения), подвержена влиянию большого множества факторов.
В этой статье я хотел бы рассмотреть эти факторы, чтобы сделать меру производительности, выраженную в IOPS, более понятной.
Начнем с того, что IOPS вовсе не IOPS и даже совсем не IOPS, так как существует множество переменных, которые определяют сколько IOPS мы получим в одних и других случаях. Также следует принять во внимание, что системы хранения используют функции чтения и записи и обеспечивают различное количество IOPS для этих функций в зависимости от архитектуры и типа приложения, в особенности в случаях, когда операции ввода / вывода происходят в одно и тоже время. Различные рабочие нагрузки предъявляют различные требования к операциям ввода / вывода (I/O). Таким образом, системы хранения, которые на первый взгляд должны были бы обеспечивать должную производительность, в действительности могут не справится с поставленной задачей.
Основы производительности накопителей
Для того, чтоб приобрести полноценное понимание в вопросе, начнем с основ. IOPS, пропускная способность (MB/s или MiB/s) и время отклика в миллисекундах (мс) являются общепринятыми единицами измерения производительности накопителей и массивов из них.
IOPS обычно рассматривают в ключе измерения способности устройства хранения производить чтение / запись блоками размером 4-8КБ в случайном порядке. Что типично для задач онлайн-обработки транзакций, баз данных и для запуска различных приложений.
Понятие пропускной способности накопителя обычно же применимо при чтении / записи крупного файла, к примеру, блоками 64КБ и более, последовательно (в 1 поток, 1 файл).
Время отклика — время, которое необходимо накопителю для того, чтоб начать производить операцию записи / чтения.
Преобразование между IOPS и пропускной способностью может быть выполнено следующим образом:
IOPS = пропускная способность / размер блока;
Пропускная способность = IOPS * размер блока,
где размер блока — количество информации, переданное на протяжении одной операции ввода / вывода (I/O). Таким образом, зная такую характеристику жесткого диска (HDD SATA), как пропускную способность — мы с легкостью можем вычислить количество IOPS.
К примеру, возьмем стандартный размер блока — 4КБ и стандартную пропускную способность, заявленную производителем для последовательной записи или чтения (I/O) — 121 Мбайт / с. IOPS = 121 МБ / 4 КБ, в результате чего получим значение порядка 30 000 IOPS для нашего жесткого диска SATA. Если же размер блока увеличить и сделать равным 8 КБ, значение будет порядка 15 000 IOPS, то есть снизится практически пропорционально увеличению размера блока. Однако нужно четко понимать, что тут мы рассматривали IOPS в ключе последовательной записи или чтения.
Все меняется драматическим образом для традиционных жестких SATA дисков, если чтение и запись будут случайными. Тут начинает играть роль задержка (latency), которая очень критична в случае жестких дисков HDDs (Hard Disk Drives) SATA / SAS, а порой даже и в случае твердотельных накопителей SSD (Solid State Drive). Хотя последние зачастую обеспечивают производительность на порядки лучшую, чем у «вращающихся» накопителей, за счет отсутствия движущихся элементов, но все же могут возникать ощутимые задержки при записи, в виду особенностей технологии, и, как следствие, при использовании их в массивах. Глубокоуважаемый amarao провел довольно полезное исследование по использованию твердотельных накопителей в массивах, как выяснилось, производительность будет зависеть от latency самого медленного из дисков. Более подробно с результатами Вы можете ознакомиться в его статье: SSD + raid0 — не всё так просто.
Но вернемся к производительности отдельно взятых накопителей. Рассмотрим случай с «вращающимися» накопителями. Время, требуемое для выполнения одной случайной операции ввода / вывода будет определятся такими составляющими:
где T(A) — время доступа (access time или seek time), также известное, как время поиска, то есть время, требуемое для того, чтоб считывающая головка, была помещена на дорожку с нужным нам блоком информации. Зачастую в спецификации диска производителем указываются 3 параметра:
— время, требуемое, чтоб переместиться с самой дальней дорожке к самой ближней;
— время, требуемое для перемещения между смежными дорожками;
— среднее время доступа.
Таким образом мы приходим к волшебному выводу, что показатель T(A) может быть улучшен, если мы размещаем наши данные на как можно более близких дорожках, а все данные располагаются как можно дальше от центра пластины (требуется меньше времени для перемещения блока магнитных головок, а на внешних дорожках данных больше, так как больше длина дорожки и она вращается быстрее, нежели внутренняя). Теперь становится понятно почему дефрагментация может быть так полезна. Особенно с условием размещения данных на внешних дорожках в первую очередь.
T(L) — задержка, вызванная вращением диска, то есть время, требуемое для того, чтоб считать или записать конкретный сектор на нашей дорожке. Легко понять, что оно будет лежать в пределах от 0 до 1/RPS, где RPS — количество оборотов в секунду. К примеру при характеристике диска в 7200 RPM (оборотов в минуту) мы получим 7200/60 = 120 оборотов в секунду. То есть один оборот происходит за (1/120) * 1000 (количество миллисекунд в секунде) = 8,33 мс. Средняя же задержка в этом случае, будет равна половине времени, затрачиваемому на один оборот — 8,33/2 = 4,16 мс.
T(R/W) — время чтения или записи сектора, которое определяется размером выбранного при форматировании блока (от 512 байт и до… нескольких мегабайт, в случае с более емкими накопителями — от 4 килобайт, стандартный размер кластера) и пропускной способностью, которая указана в характеристиках накопителя.
Среднюю задержку вращения, которая приблизительно равна времени, затраченному на половину оборота, зная скорость вращения 7200, 10 000 или 15 000 RPM, легко определить. И выше мы уже показали как.
Остальные же параметры (среднее время поиска чтения и записи) определить сложнее, они определяются уже в результате тестов и указываются производителем.
Для расчета количества случайных IOPs жесткого диска возможно применить следующую формулу, при условии когда количество одновременных операций чтения и записи одинаково (50%/50%):
1/( ( (среднее время поиска чтения + среднее время поиска записи) / 2) / 1000) + (средняя задержка вращения / 1000)).
Многие интересуются, почему именно такое происхождение формулы? IOPS — количество операций ввода или вывода в секунду. Именно потому мы делим в числителе 1 секунду (1000 миллисекунд) на время с учетом всех задержек в знаменателе (выраженное также в секундах или миллисекундах), требуемое для осуществления одной операции ввода или вывода.
То есть формула может быть записана и таким образом:
1000 (мс) / ((среднее время поиска чтения (мс) + среднее время поиска записи (мс)) /2) + средняя задержка вращения (мс))
Для накопителей с различным количеством RPM (вращений в минуту), мы получим следующие значения:
Для 7200 RPM накопителя IOPS = 1/(((8,5+9,5)/2)/1000) + (4,16/1000)) = 1/((9/1000) +
(4,16/1000)) = 1000/13,16 = 75,98;
Для 10K RPM SAS накопителя IOPS = 1/(((3,8+4,4)/2)/1000) + (2,98/1000)) =
1/((4,10/1000) + (2,98/1000)) = 1000/7,08 = 141,24;
Для 15K RPM SAS накопителя IOPS = 1/(((3,48+3,9)/2)/1000) + (2,00/1000)) =
1/((3,65/1000) + (2/1000)) = 1000/5,65 = 176,99.
Таким образом мы видим драматические изменения, когда с десятков тысяч IOPS при последовательном чтении или записи, производительность падает до нескольких десятков IOPS.
И уже, при стандартном размере сектора в 4КБ, и наличию столь малого числа IOPS, мы получим значение пропускной способности отнюдь не в сотню мегабайт, а менее, чем в мегабайт.
Эти примеры также иллюстрируют причину незначительных изменений в номинальных дисковых IOPS от разных производителей для дисков с одним и тем же показателем RPM.
Теперь становится понятным, почему данные производительности, лежат в довольно широких диапазонах:
7200 RPM (Rotate per Minute) HDD SATA — 50-75 IOPS;
10K RPM HDD SAS — 110-140 IOPS;
15K RPM HDD SAS — 150-200 IOPS;
SSD (Solid State Drive) — десятки тысяч IOPS на чтение, сотни и тысячи на запись.
Однако номинальный дисковый IOPS остается все же далеко неточными, так как не учитывает различий в характере нагрузок в отдельно взятых случаях, что очень важно понимать.
Также, для лучшего понимания темы, рекомендую ознакомиться еще с одной полезной статьей от amarao: Как правильно мерять производительность диска, благодаря которой становиться также понятным, что latency вполне не фиксирована и также зависит от нагрузки и ее характера.
Единственное, хотелось бы добавить:
При расчете производительности жесткого диска можно пренебречь снижением количества IOPS при увеличении размера блока, почему?
Мы уже поняли, что для «вращающихся» накопителей, время, требуемое для случайного чтения или записи, складывается из следующих компонент:
И далее даже рассчитали производительность при случайном чтении и записи в IOPS. Вот только параметром T(R/W) мы там по сути пренебрегли, и это не случайно. Мы знаем, что допустим, последовательное чтение может быть обеспечено на скорости в 120 мегабайт в секунду. Становится понятным, что блок в 4КБ, будет считан за примерно 0,03 мс, время на два порядка меньшее, нежели время остальных задержек (8 мс + 4 мс).
Таким образом, если при размере блока в 4КБ мы имеем 76 IOPS (основная задержка была вызвана вращением накопителя и временем позиционирования головки, а не самим процессом чтения или записи), то при размере блока в 64КБ, падение IOPS будет не в 16 раз, как при последовательном чтении, а лишь на несколько IOPS. Так как время, затрачиваемое на непосредственно чтение или запись, возрастет на 0,45 мс, что составляет лишь порядка 4% от общего времени задержки.
В результате мы получим 76-4% = 72,96 IOPS, что согласитесь, совсем не критично при расчетах, так как падение IOPS не в 16 раз, а лишь на несколько процентов! И при расчетах производительности систем куда важнее не забыть учесть другие важные параметры.
Волшебный вывод: при расчете производительности систем хранения, основанных на жестких дисках, следует подбирать оптимальный размер блока (кластера), для обеспечения нужной нам максимальной пропускной способности в зависимости от типа данных и используемых приложений, причем падением IOPS при увеличении размера блока с 4КБ до 64КБ или даже 128КБ можно пренебречь, либо учитывать, как 4 и 7% соответсвенно, если в поставленной задаче они будут играть важную роль.
Также становится понятным, почему не всегда есть смысл использовать очень большие блоки. Скажем, при видеостриминге, двухмегабайтный размер блока может оказаться далеко не самым оптимальным вариантом. Так как падение количества IOPS будет более, чем в 2 раза. Помимо прочего добавятся другие деградационные процессы в массивах, связанные с многопоточностью и вычислительной нагрузкой при распределении данных по массиву.
Оптимальный размер блока (кластера)
Оптимальный размер блока нужно учитывать в зависимости от характера нагрузки и типа используемых приложений. Если идет работа с данными небольшого размера, к примеру с базами данных — следует выбрать стандартные 4 КБ, если же речь идет о стриминге видеофайлов — размер кластера лучше выбирать от 64 КБ и более.
Следует помнить, что размер блока не столь критичен для SSD, сколько для стандартных HDD, так как позволяет обеспечить нужную пропускную способность в виду небольшого количества случайных IOPS, количество которых снижается незначительно при увеличении размера блока, в отличии от SSD, где наблюдается практически пропорциональная зависимость.
Почему стандарт 4 КБ?
Для многих накопителей, в особенности твердотельных, значения производительности, к примеру записи, начиная с 4 КБ, становятся оптимальными, это видно из графика:
В то время, как на чтение, скорость также довольно существенна и более менее сносна начиная с 4 КБ:
Именно по этой причине 4 КБ размер блока очень часто применяют за стандартный, так как при меньшем размере идут большие потери производительности, а при увеличении размера блока, в случае работы с небольшими данными, данные будут распределены менее эффективно, занимать весь размер блока и квота накопителя будет использоваться не эффективно.
Уровень RAID
Если Ваша система хранения представляет собой массив накопителей объединенных в RAID определенного уровня, то производительность системы будет зависеть в значительной степени от того, какой именно уровень RAID был применен и какой процент от общего числа операций приходится на операции записи, ведь именно запись является причиной снижения производительности в большинстве случаев.
Так, при RAID0, на каждую операцию ввода будет расходоваться лишь 1 IOPS, ведь данные будут распределены по всем накопителям без дублирования. В случае же зеркала (RAID1, RAID10), каждая операция записи будет потреблять уже 2 IOPS, так как информация должна быть записана на 2 накопителя.
В более высоких уровнях RAID потери еще существеннее, к примеру в RAID5 штрафной коэффициент будет уже 4, что связано с тем, каким образом данные распределяются по дисках.
RAID5 используется вместо RAID4 в большинстве случаев, так как распределяет четность (контрольные суммы) по всем дискам. В массиве RAID4 один из дисков ответственен за всю четность, в то время как данные распространены более чем на 3 диска. Именно потому мы применяем штрафной коэффициент 4 в массиве RAID5, так как мы читаем данные, читаем четность, затем пишем данные и пишем четность.
В массиве RAID6 все аналогично, за исключением того, что мы вместо вычисления четности единожды, делаем это дважды и таким образом имеем 3 операции чтения и 3 записи, что дает нам уже штрафной коэффициент 6.
Казалось бы, что в таком массиве, как RAID-DP все будет аналогично, так как это по сути модифицированный массив RAID6. Но не тут то было… Хитрость заключается в том, что применяется отдельная файловая система WAFL (Write Anywhere File Layout), где все операции записи последовательны и производятся на свободное место. WAFL в основном напишет новые данные в новое местоположение на диске и затем переместит указатели на новые данные, устраняя таким образом операции чтения, которые должны иметь место. Кроме того идет запись журнала в NVRAM, который отслеживает транзакции записи, инициирует запись и может восстановить их при необходимости. Идет запись в буфер в начале, а затем они уже «сливаются» на диск, что ускоряет процесс. Вероятно эксперты в NetApp могут просветить нас более подробно в комментариях, за счет чего достигается экономия, я пока что еще не до конца разобрался в этом вопросе, но запомнил, что штрафной коэффициент RAID будет всего лишь 2, а не 6. «Хитрость» весьма существенна.
При больших массивах RAID-DP, которые состоят из десятков дисков, существует понятие уменьшения «штрафа четности», который возникает при записи четности. Так при росте массива RAID-DP, требуется меньшее количество дисков, выделяемых под четность, что приведет к снижению потерь, связанных с записями четностей. Однако в небольших массивах, либо с целью повышения консерватизма, мы можем пренебречь этим явлением.
Теперь, зная о потерях IOPS в результате применения того либо другого уровня RAID, мы можем рассчитать производительность массива. Однако, пожалуйста, примите к сведению, что другие факторы, такие как пропускная способность интерфейса, неоптимальное распределение прерываний по ядрах процессора и т.п., пропускная способность RAID-контроллера, превышение допустимой глубины очереди — могут оказывать негативное влияние.
В случае пренебрежения этими факторами, формула будет следующей:
Функциональные IOPS = (Исходные IOPS * % операций записи / штрафной коэффициент RAID) + (Исходные IOPS * % чтения), где Исходные IOPS = усредненный IOPS накопителей * количество накопителей.
Рассчитаем для примера производительность массива RAID10 из 12 дисков HDD SATA, если известно, что одновременно происходит 10% операций записи и 90% операций чтения. Допустим, что диск обеспечивает 75 случайных IOPS, при размере блока 4КБ.
Исходные IOPS = 75*12 = 900;
Функциональные IOPS = (900*0,1/2) + (900*0,9) = 855.
Таким образом видим, что при малой интенсивности записи, что в основном наблюдается в системах, рассчитанных на отдачу контента, влияние штрафного коэффициента RAID минимально.
В целях консерватизма я рекомендую добавлять от 20% от нужного числа IOPS, при проектировании систем.
Зависимость от приложений
Производительность нашего решения очень сильно может зависеть от приложений, которые будут исполнятся впоследствии. Так это может быть обработка транзакций — «структурированных» данных, которые организованы, последовательны и предсказуемы. Зачастую в этих процессах можно применить принцип пакетной обработки, распределив эти процессы во времени так, когда нагрузка минимальна, тем самым оптимизировав потребление IOPS. Однако в последнее время появляется все больше и больше медийных проектов, где данные «не структурированы» и требуют совсем иных принципов их обработки.
По этой причине подсчет необходимой производительности решения для конкретного проекта может стать весьма сложной задачей. Некоторые из производителей сторедж-хранилищ и экспертов утверждают, что IOPS не имеют значения, так как клиенты в подавляющем большинстве используют до 30-40 тысяч IOPS, в то время, как современные системы хранения обеспечивают сотни тысяч и даже миллионы IOPS. То есть современные хранилища удовлетворяют нужды 99% клиентов. Тем не менее это утверждение может быть справедливо далеко не всегда, лишь для бизнес-сегмента, который размещает хранилища у себя, локально, но не для проектов, размещаемых в дата-центрах, которые зачастую, даже при использовании готовых решений хранения, должны обеспечивать довольно высокую производительность и отказоустойчивость.
В случае размещения проекта в дата-центре, в большинстве случаев, все же более экономично строить системы хранения самостоятельно на основе выделенных серверов, нежели использовать готовые решения, так как становится возможным более эффективно распределить нагрузку и подобрать оптимальное оборудование для тех, либо других процессов. Помимо прочего, показатели производительности готовых систем хранения, далеки от реальных, так как в большинстве своем основаны на данных профилей синтетических тестов производительности, при применении 4 или 8 КБ размера блока, в то время как большинство клиентских приложений работает сейчас в средах с размером блока от 32 до 64 КБ.
Как видим из графика:
Менее, чем 5% систем хранения, настроены с применением блока менее 10 КБ и менее, чем 15% используют блоки с размером менее 20 КБ. Кроме того, даже для определенного приложения, редко когда возникает потребления I/O лишь одного типа. К примеру у базы данных будут различные профили I/O для различных процессов (файлы с данными, логирование, индексы …). А значит, заявленные синтетические тесты производительности систем, могут быть далекими от истины.
А что на счет задержек?
Даже если мы будем игнорировать тот факт, что инструменты, применяемые для измерения latency, имеют тенденцию измерять средние времена ожидания и упускают то, что один единственный I/O в каком-то из процессов, может занимать куда больше времени, чем другие, таким образом замедляя ход всего процесса, то совсем не учитывают то, насколько время ожидания I/O изменится в зависимости от размера блока. Помимо прочего это время также будет зависеть от конкретного приложения.
Таким образом мы приходим к еще одному волшебному выводу, что не только размер блока является не очень хорошей характеристикой при измерении производительности IOPS систем, но и latency может оказаться вполне бесполезным параметром.
Хорошо, если ни IOPS, ни время ожидания не являются хорошей мерой измерения производительности системы хранения, то что тогда?
Только реальный тест исполнения приложения на конкретном решении…
Этот тест будет тем реальным методом, который наверняка позволит понять, насколько производительным будет решение для Вашего случая. Для этого понадобится запустить копию приложения на отдельно взятом хранилище и симулировать нагрузку за определенный период. Только так можно получить достоверные данные. И разумеется, нужно измерять не метрики хранилища, а метрики приложения.
Тем не менее учет приведенных выше факторов, влияющих на производительность наших систем, может быть весьма полезным при подборе хранилища или построении определенной инфраструктуры на основе выделенных серверов. С определенной степенью консерватизма становится возможным подобрать более-менее реальное решение, исключить некоторые технические и программные изъяны в виде не оптимального размера блока при разбивке или не оптимальной работы с дисками. Решение, конечно, не будет на 100% гарантировать расчетную производительность, но в 99% случаев можно будет говорить, что решение справится с нагрузкой, особенно, если добавлять консерватизм в зависимости от типа приложения и его особенностей в расчет.