Размер полосы какой выбрать рейд 10

Обновлено: 21.11.2024

Ниже показана текущая конфигурация нашего сервера. Через несколько недель я буду моделировать аварийное восстановление, установив 5 новых дисков (1 горячий резерв) и восстановив все виртуальные машины из резервных копий.

Получу ли я что-нибудь, изменив размер полосы RAID на значение, отличное от 64 КБ? Контроллер RAID имеет следующие параметры: 8 КБ, 16 КБ, 32 КБ, 64 КБ, 128 КБ, 256 КБ, 512 КБ, 1 МБ.

Будем очень признательны за любые рекомендации, основанные на приведенной ниже спецификации. Спасибо.

2 ответа 2

Я попытаюсь обобщить свои комментарии в ответ. Основная строка:

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

Для чередования необходимо выбрать некоторый размер полосы, а 64 КБ — это значение по умолчанию, выбранное производителем. Поскольку производитель (в данном случае LSI, переименованный в Dell) имеет чертовски большой опыт работы с огромным количеством установок с различными уровнями RAID и рабочими нагрузками, вы можете просто поверить, что они сделали мудрый выбор.
64 КБ, вероятно, примерно соответствует среднему размеру ваших запросов в виртуализированной среде (по крайней мере, намного больше, чем 256 КБ или 1 МБ) и, таким образом, является хорошим компромиссом между задержкой и оптимизацией времени поиска 1 .
точные прогнозы производительности приложений с различными размерами полосы на основе моделей почти невозможны из-за сильно различающегося характера рабочих нагрузок и сложности моделей, учитывающих разные алгоритмы упреждающего чтения и кэширования на разных уровнях

Если вы из тех, кто хочет получить эти доказательства, вы можете сделать это, запустив типичную нагрузку и некоторые нетипичные сценарии нагрузки с различными конфигурациями размера полосы, собрав данные (производительность подсистемы ввода-вывода на уровне сервера Xen, производительность внутреннего сервера и время ответа на прикладном уровне) и проведите его статистическую оценку. Однако это займет очень много времени и вряд ли приведет к каким-либо новаторским результатам, кроме "Возможно, я просто оставил значения по умолчанию в конце", поэтому я считаю это пустой тратой ресурсов. .

1 Если вы предполагаете скорость передачи 100 МБ/с для одного диска, довольно легко увидеть, что чтение килобайта занимает около 0,01 мс, поэтому 64 КБ будут иметь задержку чтения 0,64 мс. Учитывая, что среднее «время обслуживания» произвольного запроса ввода-вывода обычно находится в диапазоне 5-10 мс, задержка чтения составляет лишь небольшую часть от общего времени ожидания. С другой стороны, чтение 512 КБ займет около 5 мс, что будет иметь значение для типа рабочей нагрузки «случайное небольшое чтение», что значительно уменьшит количество операций ввода-вывода в секунду, которые ваш массив сможет обеспечить в этом конкретном случае, в 1,5 раза. 2. Сценарий с одновременными случайными большими операциями чтения принесет пользу, поскольку чтение больших блоков вызовет меньше времени на поиск, но очень маловероятно, что вы увидите этот сценарий в виртуализированной среде.

Какой размер полосы RAID лучше всего подходит для массива жестких дисков? Каковы настройки по умолчанию для размера полосы рейда и упреждающего чтения файловой системы? Приемлемы ли эти значения по умолчанию? Как эти настройки влияют на производительность моего сервера?

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

В современных операционных системах размер полосы рейда по умолчанию составляет от 128 КБ до 256 КБ. Это также относится к размеру полосы аппаратных RAID-карт по умолчанию. Кроме того, значение опережающего чтения файловой системы по умолчанию составляет от 128 КБ до 256 КБ во многих современных операционных системах.

Когда подходят значения по умолчанию?

Для серверов, на которых в основном размещается множество небольших файлов или данные размещаются на твердотельных накопителях, эти настройки по умолчанию, вероятно, подходят как для упреждающего чтения, так и для размера полосы рейда. В случае SSD эти значения по умолчанию подходят, потому что SSD очень хорошо считывают небольшие биты данных, расположенные в любом месте на диске, и поэтому размер полосы и упреждающее чтение практически не влияют на производительность для современных SSD. Для жестких дисков в типичных случаях использования эти значения по умолчанию также подходят, поскольку многие файлы меньше этих значений по умолчанию. Это означает, что большинство отдельных файлов, которые вы читаете, хранятся на одном диске, и поэтому при чтении файла доступ осуществляется только к одному диску. Увеличение размера полосы в этой ситуации не сильно меняет шаблон доступа к диску и, следовательно, не сильно влияет на производительность.

Таким образом, во многих случаях вам не нужно беспокоиться об этих настройках, и значения по умолчанию подойдут.Однако в одном случае использования, когда многие пользователи одновременно обращаются к файлам размером более 256 КБ, и эти файлы хранятся на обычных жестких дисках, параметры чередования рейдов и опережающего чтения файловой системы критически важны для повышения производительности диска.

Когда следует изменить значения по умолчанию?

Этот тип шаблона доступа очень распространен для «сайтов с пробками» и сайтов для скачивания файлов. Это связано с тем, что большие размеры файлов хорошо подходят для менее дорогого хранилища на жестком диске, а доступ к большим файлам при использовании жестких дисков — это именно то, где вы можете получить выгоду от изменения настроек по умолчанию. В этом случае настройки по умолчанию значительно уступают оптимизированной конфигурации.

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

Каковы оптимальные настройки?

Для RAID 10 или RAID 0 на обычных жестких дисках лучше всего использовать полосу размером 2 МБ, если она доступна. Если вы не можете выбрать размер полосы до 2 МБ, выберите максимально допустимое значение. Для аппаратных RAID-карт максимальный размер полосы часто составляет 1 МБ, поэтому в таких ситуациях это будет лучшим вариантом. Значение по умолчанию 256 КБ неэффективно для чтения больших файлов с обычных жестких дисков. Для твердотельных накопителей подойдет любое значение 128 КБ или выше.

Для RAID 5, RAID 50, RAID 6 или RAID 60 размер полосы от 256 КБ до 512 КБ идеально подходит для видеосайтов и сайтов загрузки больших файлов, размещенных на жестких дисках, а размер полосы от 128 КБ до 256 КБ будет оптимальным. лучше, когда доступ обычно к небольшим файлам или когда данные хранятся на SSD. Почему эти уровни RAID типа «четности» лучше с меньшим размером полосы, выходит за рамки этой статьи. Достаточно сказать, что если вы заботитесь о производительности, RAID 10 намного лучше, чем RAID 5/50/6/60.

Для параметров упреждающего чтения файловой системы оптимальное значение обычно составляет 512 КБ, если размер страйпа рейда составляет не менее 1 МБ. Это обеспечит максимальную производительность для сервера, который в основном читает большие файлы с жестких дисков.

Почему размер полосы влияет на производительность?

Чтобы понять это, полезно представить себе, что на самом деле происходит на жестком диске.

«Жесткий диск» от walknboston находится под лицензией CC BY 2.0

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

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

Поэтому, чтобы максимизировать производительность, вы хотите считывать как можно больше данных каждый раз, когда головка чтения-записи перемещается в другую часть диска. Операционные системы знают об этом, поэтому всякий раз, когда данные запрашиваются для чтения с диска, ОС продолжает и считывает больше данных, чем было запрошено, исходя из предположения, что данные могут понадобиться в конечном итоге. Эта функция называется «упреждающее чтение». Во многих операционных системах это значение упреждающего чтения по умолчанию равно 256 КБ.

Пример шаблонов чтения массива RAID 0 из 4 дисков / массива RAID 10 из 8 дисков с различными размерами чередования и размерами чтения

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

В первом примере чтение размером 256 КБ является очень типичным, поскольку во многих операционных системах значение упреждающего чтения по умолчанию равно 256 КБ. Это означает, что даже если ваше приложение запрашивает чтение только 1 КБ данных из файла, следующие 256 КБ данных из того же файла также будут считаны с диска. Если размер файла меньше 256 КБ, то весь файл будет прочитан сразу. Вот почему значения упреждающего чтения и чередования важны только тогда, когда типичный размер вашего файла больше, чем упреждающее чтение по умолчанию, равное 256 КБ.

К сожалению, страйп размером 256 КБ также используется по умолчанию для RAID-массивов. Таким образом, диаграмма вверху слева показывает, что происходит почти всегда при использовании настроек по умолчанию — считывается 256 КБ данных, и эти данные считываются с 2 разных дисков из 4-дискового рейда 10 в 99% случаев.Таким образом, в этом сценарии по умолчанию 128 КБ считываются с каждого из двух дисков почти каждый раз. (Чтение может происходить только с одного диска в тех редких случаях, когда задание на чтение начинается точно в начале полосы рейда размером 256 КБ.)

При изменении размера полосы на 1 МБ и оставлении упреждающего чтения со значением по умолчанию, равным 256 КБ, вы будете считывать 256 КБ только с одного диска в 75 % случаев, а чтение будет разделяться между двумя дисками в 25 % случаев. . 25% происходит, когда ваш запрос на чтение 256 КБ начинается в четвертой четверти чередования. Таким образом, в большинстве случаев только с одного диска считывается 256 КБ, а в 25 % случаев с каждого диска считывается по 128 КБ.

Напомним, что каждый диск может «искать» разные части диска только около 100 раз в секунду. Между тем, скорость последовательного чтения на диске из нашего примера может достигать 100 МБ/с (эти цифры могут быть удвоены до 200 операций поиска в секунду и 200 МБ/с на более новых дисках, но соотношение остается примерно таким же).

Так что же происходит, когда ситуация по умолчанию приводит к чтению 128 КБ на каждом диске в среднем за одну операцию поиска? Что ж, 128 КБ чтения за поиск x 100 запросов в секунду = 12,8 МБ/с — это максимальная производительность, которую вы получите. На диске, который может читать 100 МБ/с, это составляет всего 12% от максимальной скорости, которую диск мог бы обеспечить, если бы он выполнял только последовательное чтение. Это действительно низкая производительность, и оптимизация RAID-массива здесь направлена на то, чтобы увеличить этот показатель.

Как оптимизированная полоса RAID повышает производительность?

Чтобы повысить производительность, вы должны сделать все возможное, чтобы увеличить объем данных, считываемых при каждом поиске. Именно здесь полоса RAID и упреждающее чтение играют решающую роль.

Во-первых, давайте взглянем на размер полосы 1 МБ. В первом примере, по-прежнему с размером чтения 256 КБ, 75% запросов будут «обращаться» только к одному диску, и каждый запрос по-прежнему будет считывать 256 КБ. В 25% случаев вы читаете 128 КБ с каждого диска при каждом поиске. Таким образом, в среднем это означает, что при каждом поиске с диска считывается 224 КБ данных. Предполагая 100 операций поиска в секунду, это обеспечивает производительность 22,4 МБ/с на каждый диск, что на 75 % больше производительности по сравнению с настройками по умолчанию!

Следующий способ повысить производительность — увеличить упреждающее чтение в массиве. Во втором примере показан результат упреждающего чтения 512 КБ с полосой размером 256 КБ или 1 МБ.

Два разных способа чтения размером 512 КБ на массиве RAID с чередованием 1 МБ

На изображении выше вы можете видеть, что происходит с запросом на чтение в зависимости от того, где в полосе происходит чтение. Для страйпа 256 КБ в 99% случаев чтение 512 КБ «попадет» на 3 разных диска. (Если чтение идеально выровнено по началу чередования, оно будет считываться с 2 дисков, чтобы выполнить запрос, но это бывает редко.) Для чередования 1 МБ чтение 512 КБ будет в 50% случаев только читать с одного диска, в то время как 50% времени он будет читать с 2 дисков для выполнения запроса. Что из этого происходит, зависит от того, как далеко в полосе начинается запрос на чтение, как показано выше.

Как это влияет на производительность? Общий объем прочитанных данных составляет 512 КБ, а для полосы размером 256 КБ требуется 3 поиска (вы читаете с 3 разных дисков). Таким образом, в среднем один поиск приводит к чтению 171 КБ данных. Поскольку один диск может выполнять 100 операций поиска в секунду, это соответствует 17,1 МБ/с на диск. По сравнению с 12,8 МБ/с, которые вы видели на страйпе 256 КБ с чтением 256 КБ, это улучшение на 33%. Неплохо!

Как этот размер чтения 512 КБ работает для чередования 1 МБ? Что ж, в 50% случаев выполняется 1 поиск, а в 50% случаев — 2 поиска — в среднем 1,5 поиска на чтение. Читая 512 КБ, вы в среднем 341 КБ за поиск. Поскольку один диск может выполнять 100 операций поиска в секунду, получается 34,1 МБ/с. По сравнению со значениями по умолчанию 256 КБ упреждающего чтения и 256 КБ размера полосы, это увеличение скорости в 2,6 раза! Это также дает вам 1/3 от максимальной теоретической производительности диска, что является огромным увеличением по сравнению со случаем по умолчанию.

В чем подвох?

Большое предостережение заключается в том, что эти улучшения происходят только в том случае, если размер файла, который вы читаете, не меньше значения, заданного параметром упреждающего чтения. Упреждающее чтение будет читать только до конца файла, к которому вы обращаетесь. Таким образом, для веб-сайта, где 90% запросов приходится на миниатюры изображений размером 10 КБ, ничто из этого не будет иметь значения. Почти все запросы будут для изображений размером 10 КБ, а при упреждающем чтении по умолчанию, равном 256 КБ, эти 10-килобайтные изображения уже будут загружаться полностью каждый раз. Кроме того, полоса RAID размером 256 КБ означает, что почти всегда весь файл размером 10 КБ будет находиться на одном диске, поэтому недостатки небольшого размера полосы не применяются при чтении файлов, намного меньших размера полосы.

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

Еще одна проблема заключается в том, что отдача от упреждающего чтения уменьшается по сравнению с максимальным размером полосы. В качестве последнего примера рассмотрим упреждающее чтение 2 МБ с размером полосы 256 КБ или 1 МБ.

Шаблон чтения с упреждающим чтением 2 МБ с чередованием 256 КБ или 1 МБ

Какая здесь производительность? Что ж, для полосы размером 256 КБ вы читаете 2 МБ, разделенных на все 4 диска — в среднем 512 КБ на поиск. При 100 операциях поиска в секунду даже страйп-массив размером 256 КБ может считывать 51,2 МБ/с с каждого диска — намного больше, чем при упреждающем чтении по умолчанию 256 КБ. В нашем примере это 51% от максимальной производительности, на которую способны диски, что является огромным улучшением по сравнению с 256 КБ упреждающего чтения.

Массив с полосой размером 1 МБ работает еще лучше: почти во всех случаях для чтения данных объемом 2 МБ требуется участие трех из четырех дисков. 2 МБ на чтение с 3 поисками на чтение 682 КБ на поиск или 68,2 МБ/с для диска, который может выполнять 100 операций поиска в секунду. Это приближается к максимальной скорости, которую может развивать наш накопитель — 100 МБ/с.

Можем ли мы увеличить это до огромного уровня, чтобы получить еще большую производительность?

Хотя эти значения кажутся даже лучше, чем раньше, скорость улучшения резко снижается. По умолчанию упреждающее чтение 256 КБ и полоса 256 КБ давали вам 12,8 МБ/с. Для упреждающего чтения 512 КБ и чередования 1 МБ вы получаете 34,1 МБ/с. Увеличение упреждающего чтения еще в 4 раза увеличило теоретическую производительность до 68,2 МБ, поэтому это увеличение быстро снижается.

Есть также проблема, заключающаяся в том, что мы предполагаем, что чтение данных с диска занимает нулевое время. Когда накопитель считывает данные со скоростью 10 % от максимальной последовательной скорости, эта оплошность является ошибкой округления. Но когда вы имеете дело со чтением данных на скорости 40–60 % от максимальной теоретической скорости накопителя и предполагаете, что эти последовательные чтения занимают нулевое время, это вносит огромную ошибку в уравнение. Накопитель не может тратить 50 % своего времени на последовательное чтение данных, а затем еще 100 % своего времени на поиск между различными файлами на диске.

На диаграмме ниже показан этот компромисс, который вы делаете в реальных цифрах:

Предполагается максимальная скорость последовательного чтения 100 МБ/с и максимальная скорость поиска 100 операций поиска в секунду, что типично для жесткого диска SATA емкостью 1 ТБ, 7200 об/мин. Современные накопители емкостью 8 ТБ могут работать в 2 раза быстрее.

В нашем примере по умолчанию с чередованием 256 КБ и упреждающим чтением 256 КБ время, затрачиваемое на поиск 128 КБ, очень похоже на 90 % времени, затрачиваемого на поиск в приведенном выше примере. Это значение дает гипотетическую максимальную производительность 10 МБ/с при среднем чтении 114 КБ на поиск — очень близко к цифрам из нашего примера. Однако из нашего предыдущего примера, где упреждающее чтение 2 МБ на полосе размером 256 КБ приведет к чтению 512 КБ за один поиск, можно увидеть, что ожидаемое падение производительности находится между уровнями 30–40 МБ/с. Это намного меньше оценочных 51,2 МБ/с, когда мы предполагали, что чтение данных занимает нулевое время. Между тем, упреждающее чтение 2 МБ с чередованием 1 МБ приведет к 682 КБ на поиск, что точно соответствует уровню 40 МБ/с из таблицы выше. Это также далеко от 68,2 МБ/с, которые мы оценили, предполагая, что последовательное чтение занимает нулевое время.

По этой причине около 40 МБ/с, или 40 % от максимальной скорости последовательного чтения диска, является реалистичным максимумом, которого можно ожидать в случае использования многоклиентского сервера. Это верно, даже если вы оптимизируете полосу рейда и отлично читаете вперед. После этого повышения производительности становится гораздо труднее добиться, требуя значительного увеличения КБ чтения на поиск, что имеет свои негативные последствия для производительности.

Но почему бы в любом случае не увеличить упреждающее чтение и чередование до абсурдного уровня?

Может показаться, что можно просто увеличивать упреждающее чтение и всегда повышать производительность, но это не так. Главное предостережение: вы не хотите произвольно считывать несколько мегабайт для упреждающего чтения. Самая большая причина этого заключается в том, что считанные данные должны находиться в оперативной памяти до тех пор, пока они действительно не понадобятся. Если клиент медленно загружает файл, может пройти много времени, прежде чем ему потребуются данные, опережающие на несколько МБ то, что они уже скачали. Эти данные находятся в оперативной памяти как часть кеша файловой системы Linux, который используется для хранения копий недавно прочитанных файлов. Чтобы сохранить эти новые данные в кеше, сначала нужно удалить что-то еще. Точно так же, если вашему серверу нужна эта оперативная память по какой-либо другой причине, например, с диска только что был прочитан другой файл, старые данные будут удалены из оперативной памяти. Если ваш конечный пользователь еще не загрузил эти данные, эти сброшенные данные необходимо будет снова прочитать с диска! Это очень расточительно из-за ваших очень ограниченных запросов в секунду и ограниченных МБ/с, заставляя сервер считывать одни и те же данные несколько раз, чтобы отправить их пользователю только один раз.

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

Один из способов решения этой проблемы – управлять объемом оперативной памяти, используемой для опережающего чтения, на разумном уровне, чтобы с высокой вероятностью данные все еще находились в оперативной памяти, когда они вам действительно понадобятся. Допустим, для сервера с хорошим объемом оперативной памяти (8 ГБ или больше) вы не хотите выделять для этой цели более 25% оперативной памяти. Итак, давайте посчитаем это.

Для сервера с 1000 одновременных пользователей, загружающих файлы или просматривающих видео, 1 МБ упреждающего чтения означает, что 1 ГБ недавно прочитанных данных должен постоянно храниться в оперативной памяти. Это необходимо для предотвращения удаления этих данных до их использования. Для сервера с 8 ГБ ОЗУ использование 1 ГБ ОЗУ вполне разумно. Скорее всего, эти данные не будут удалены до того, как они вам потребуются.

Тем не менее, предположим, что ваш сервер очень загружен — к нему подключено 10 000 одновременных подключений. Между тем, у вас также есть проблемы с производительностью, и вы думаете, что огромное упреждающее чтение может помочь с этим, поэтому вы устанавливаете его на 10 МБ. Вы надеетесь, что упреждающее чтение 10 МБ и размер полосы RAID 40 МБ помогут вам достичь волшебного уровня чтения 90 МБ/с, показанного на графике ранее.

Однако при настройке упреждающего чтения 10 МБ на сервере с 10 000 одновременных пользователей для опережающего чтения потребуется 100 ГБ оперативной памяти! Если этот сервер не имеет 512 ГБ оперативной памяти или более, наверняка большая часть данных, которые вы читаете с диска, будет удалена до того, как пользователь когда-либо загрузит их, что значительно усугубит ваши проблемы с производительностью. Кроме того, это оперативная память, которую в противном случае можно было бы использовать для больших буферов TCP, что ускорило бы загрузку пользователями. Для серверов с огромным количеством подключений эти различные кэши и буферы являются деликатным балансом.

Вы любите серверы?

Мы надеемся, что эта статья помогла вам узнать о часто неправильно понимаемом и важном параметре для настройки производительности диска. Поскольку твердотельные накопители становятся все более популярными, становится все меньше случаев, когда необходимо настраивать эти параметры. Однако для некоторых веб-сайтов, на жестких дисках которых размещаются большие файлы, по-прежнему важно оптимизировать эти значения. Для массива RAID 10 идеальными являются упреждающее чтение файловой системы 512 КБ и размер полосы RAID 2 МБ (1 МБ, если 2 МБ недоступны). Ознакомьтесь с другими нашими статьями, если вы хотите узнать больше о похожих темах, касающихся RAID, оптимизации производительности, конфигурации и администрирования серверов.

Я собираюсь настроить новый RAID 10 с 8 дисками и столкнулся с выбором размера полосы.

Из того, что я помню о размере полосы, это то, что в моем RAID 10 файлы конфигурации будут распределены по 4 дискам.

Поскольку 95 % моих файлов будут иметь размер от 120 до 300 КБ (максимум около 250 КБ), оптимальным будет размер полосы 64 КБ или 32 КБ для минимизации потерянного пространства. Верно ли это?

Кроме того, я рассматриваю возможность использования RefFS вместо NTFS. Самый большой вопрос для меня здесь заключается в том, насколько «безопасна» ReFS в рабочей среде Windows Server 2012 и что насчет фрагментации?

Спасибо всем, кто возьмет здесь :-)

10 ошибок при отключении электроэнергии и как их избежать

2022-03-23 18:00:00 UTC Веб-семинар Веб-семинар: LogicMonitor — 10 ошибок при обработке сбоев и как их избежать Все подробности о событии Просмотреть все события

Северная земля

То, что Adaptec описывает, представляет собой размер "полосы" или полосатого элемента, поэтому в вашем случае я бы выбрал 64 КБ.

Я согласен с Патриком. Даже если вы придерживаетесь четырех дисков в своем RAID 10, вам будет лучше перенести ОС на OBR 10. Помимо времени загрузки, вы, вероятно, не заметите разницы в производительности. И поскольку это сервер, вы, вероятно, не будете часто его перезагружать. Большинство людей здесь, в SW, скажут вам, что установка ОС на SSD — это пустая трата ресурсов на сервере. Я признаю, что я устанавливаю Hyper-V на отдельные SSD, но я использую недорогие 32-64-гигабайтные, в зависимости от того, что доступно в то время, главным образом потому, что они дешевле, чем USB-накопители из списка рекомендуемого оборудования Microsoft, гораздо проще настроить, а гипервизор можно настроить с нуля за несколько минут, если SSD выйдет из строя. Windows Server на «голом железе» — это совсем другая история.

16 ответов

Патрик Фаррелл

Вы устанавливаете на него гипервизор, а затем виртуальную машину или устанавливаете «голое железо» Windows? Я бы выбрал NTFS, особенно если вы говорите о сервере 2012 года.

Нет, это Windows Server на SSD с использованием NTFS и RAID 10 с данными.

Северная земля

Какой производитель сервера и какой RAID-контроллер вы используете. Здесь задействованы два разных размера «полосы». Существует размер «элемента полосы» (часто называемый размером «полосы»), который соответствует размеру диска. Затем есть размер «полосы», который равен размеру полосы, умноженному на количество дисков в полосе. В вашем случае, 4-дисковый RAID 10, это будет размер полосы x 2 из-за зеркалирования. RAID 0 будет иметь размер полосы x 4, RAID 5 будет иметь размер полосы x 3. Примечание. Поскольку вы используете SSD, RAID 5 будет здесь приемлемым выбором, поскольку у SSD нет проблем с URE, которые есть у жестких дисков, и их повышенная скорость. сокращает время восстановления и влияние на производительность массива при ухудшении состояния и восстановлении.

При настройке массива RAID большинство контроллеров, с которыми я работал (LSI, на которых основаны контроллеры Dell и некоторые контроллеры HP), требуют ввода размера «полосы». Вот почему я спросил вас о марке сервера и модели RAID-контроллера. Вам нужно будет выяснить, вводите ли вы размер «полосы» или «полосы». Массив «полоса» очень похож на кластер файловой системы в том смысле, что он может содержать только один файл или часть одного файла. Если контроллер использует размер полосы, в вашем случае (средний размер файла 120–330 КБ) я бы выбрал 64 КБ, что даст вам размер полосы 128 КБ. Это достаточно мало, чтобы не тратить много места, но достаточно велико, чтобы производительность с большими файлами была удовлетворительной.

Что касается фрагментации, не беспокойтесь об этом. Во-первых, вы используете твердотельные накопители, и фрагментация не является для них проблемой, поскольку в них нет движущихся частей. А во-вторых, аппаратные RAID-контроллеры будут записывать данные куда угодно, и вы ничего не можете с этим поделать.

Примечание. Размер полосы 64 КБ является рекомендуемым размером для Hyper-V, если вы решите виртуализировать в будущем. Если это производственный сервер, вам действительно следует подумать о его виртуализации. Если бы вы использовали VMware для своего гипервизора, вам бы понадобился размер полосы 512 КБ, поскольку VMFS 5 и более поздние версии используют размеры блоков 1 МБ (1024 КБ). Другими словами, войдя в мир виртуализации, вы должны основывать свои решения на рекомендациях поставщика гипервизора.

Редактировать: ИМО, большое жирное НЕТ на REFS, это еще не достаточно зрело. Придерживайтесь NTFS.

Northlandeng написал:

Какой производитель сервера и какой RAID-контроллер вы используете. Здесь задействованы два разных размера «полосы». Существует размер «элемента полосы» (часто называемый размером «полосы»), который соответствует размеру диска. Затем есть размер «полосы», который равен размеру полосы, умноженному на количество дисков в полосе. В вашем случае, 4-дисковый RAID 10, это будет размер полосы x 2 из-за зеркалирования. RAID 0 будет иметь размер полосы x 4, RAID 5 будет иметь размер полосы x 3. Примечание. Поскольку вы используете SSD, RAID 5 будет здесь приемлемым выбором, поскольку у SSD нет проблем с URE, которые есть у жестких дисков, и их повышенная скорость. сокращает время восстановления и влияние на производительность массива при ухудшении состояния и восстановлении.

При настройке массива RAID большинство контроллеров, с которыми я работал (LSI, на которых основаны контроллеры Dell и некоторые контроллеры HP, ) вы вводите размер "полосы". Вот почему я спросил вас о марке сервера и модели RAID-контроллера. Вам нужно будет выяснить, вводите ли вы размер «полосы» или «полосы». Массив «полоса» очень похож на кластер файловой системы в том смысле, что он может содержать только один файл или часть одного файла. Если контроллер использует размер полосы, в вашем случае (средний размер файла 120–330 КБ) я бы выбрал 64 КБ, что даст вам размер полосы 128 КБ. Это достаточно мало, чтобы не тратить много места, но достаточно велико, чтобы производительность с большими файлами была удовлетворительной.

Что касается фрагментации, не беспокойтесь об этом. Во-первых, вы используете твердотельные накопители, и фрагментация не является для них проблемой, поскольку в них нет движущихся частей. А во-вторых, аппаратные RAID-контроллеры будут записывать данные куда угодно, и вы ничего не можете с этим поделать.

Примечание. Размер полосы 64 КБ является рекомендуемым размером для Hyper-V, если вы решите виртуализировать по дороге. Если это производственный сервер, вам действительно следует подумать о его виртуализации. Если бы вы использовали VMware для своего гипервизора, вам бы понадобился размер полосы 512 КБ, поскольку VMFS 5 и более поздние версии используют размеры блоков 1 МБ (1024 КБ). Другими словами, как только вы войдете в мир виртуализации, вы должны основывать свои решения на рекомендациях поставщика гипервизора.

Редактировать: ИМО, большое жирное НЕТ на REFS, он еще недостаточно зрелый. Придерживайтесь NTFS.

Спасибо за развернутый ответ.

Я должен прояснить одно недоразумение:

- SSD предназначен только для ОС (Server 2012) в НЕ RAID - поэтому один диск

- RAID 10 предназначен только для данных с использованием дисков HGST NAS емкостью 6 ТБ с URE 10^14. Я отказался от корпоративных жестких дисков, поскольку используемые в настоящее время диски WD отказываются от нас через 3 года и всего 36 тыс. часов. попробуйте HGST NAS, поскольку у меня есть хороший опыт работы с ними, и вы сэкономите 40 %

- RAID-контроллер представляет собой Adaptec 7805 - в руководстве говорится о "размере полосы" со следующим описанием:

"Размер чередования — это объем данных (в КБ), записываемых на один диск перед перемещением на следующий диск
в логическом устройстве. Параметры размера чередования зависят от вашего контроллера и уровня RAID. . Например,
в логическом диске RAID 6 или RAID 60, чем больше дисков включено в логический диск, тем меньше доступных вариантов
размера чередования.Обычно размер чередования по умолчанию обеспечивает наилучшую производительность. ."

У меня будет 16-дисковый массив RAID10, состоящий из сегментов дисков 4x4. Учитывая, что это будет действовать как хранилище данных виртуальной машины ESXi 6.0U3, а поскольку VMFS5 имеет блок размером 1 МБ, следует ли мне установить размер полосы на 256 КБ или 512? Я думаю о 512, так как у нас есть два диска на один диапазон, но я совершенно не понимаю.

В целом больший размер полосы будет работать лучше, поскольку он позволит диску считывать и записывать больший блок последовательных данных. Однако и 256 КБ, и 512 КБ достаточно велики, чтобы не иметь практического значения.

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

У меня будет 16-дисковый массив RAID10, состоящий из сегментов дисков 4x4

Для достижения наилучших результатов используйте 8 наборов двухдисковых зеркал.

Для достижения наилучших результатов используйте 8 наборов двухдисковых зеркал.

Подождите, вы имеете в виду 8xRAID0? Но в этом не было бы никакой избыточности?

Поскольку вы дважды сказали "полосатый", я просто исправлю, что это "полосатый". Я имею в виду, что стриптиз с RAID 10 на шпинделе меня вполне устраивает.

Иногда лучше вернуться к первоначальному замыслу. RAID 10 предназначен для очень специфических сценариев. Что заставляет вас терять 50 % емкости?

Ответ в основной теме :)

Не зная, какую фактическую рабочую нагрузку вы выполняете на своих виртуальных машинах, я не уверен, что вы в любом случае увидите заметную разницу в реальной производительности. Синтетические тесты дают только некоторую информацию. Если вы в конечном итоге имеете дело с большими, непрерывными операциями чтения/записи, размер полосы не имеет большого значения.

Если вы работаете с большим количеством небольших файлов и вам нужна производительность, в любом случае следует говорить о хранилище SSD или NVMe.

Ответ в основной теме :)

Извините, господа, поторопился.

Для уточнения: это 16 960-гигабайтных твердотельных накопителей, которые будут использоваться в качестве хранилища данных для 6 виртуальных машин Windows Server 2019, на которых будет работать специализированный инструмент моделирования, который будет выводить десятки гигабайт данных (возможно, даже сотни) на сим.

Затем данные будут использоваться для создания значительно меньшего набора данных, который в конечном итоге будет использоваться в рабочей среде, а больший набор данных будет удален. Таким образом, производительность чтения/записи имеет первостепенное значение, а не хранилище (у меня есть около 36 ТБ дополнительного хранилища, доступного в среде).

Насколько я понимаю, полоса на диск в сумме = полоса по массиву. Меня смущает то, как это относится к RAID10, а вместе с ним и к промежутку. Если у меня есть 4-дисковый диапазон RAID10, то логически предположим, что у меня должен быть размер полосы 512 КБ для полосы 1 МБ = 1 МБ блока VMFS5, или я совершенно неправ?

Кроме того, какое значение имеют промежутки, когда речь идет о чередовании, чередовании и четырех промежутках в массиве RAID10?

Как вы понимаете, это не моя повседневная работа, но мне приходится иметь дело с этими карточками.

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