Stripe size какой выбрать raid 10
What RAID stripe size is ideal for an array of hard drives? What are the default settings for both raid stripe size and filesystem readahead? Are those defaults acceptable? How do these settings impact the performance of my server?
In this post, we’ll go into detail as to what settings are ideal for a server depending upon what type of files it hosts and what type of drives it uses. First we’ll get you the basic answer as to what the best settings are, and then we’ll go into detail as to why that is the case.
In modern operating systems, the default raid stripe size is somewhere between 128KB and 256KB by default. This is also the case for hardware raid cards default stripe size. As well, the file system readahead value defaults to somewhere between 128KB and 256KB in many modern operating systems.
RAID 1 на базе SSD Kingston и контроллеров Broadcom
Итак, RAID-массив первого уровня на базе контроллера Broadcom MegaRAID 9460-16i объединяет от двух до 32 накопителей Kingston, которые являются копиями друг друга, и обеспечивает полную избыточность. Если при использовании традиционных HDD скорость записи и чтения данных оставалась на уровне этого самого HDD, то с использование NVMe SSD-решений мы получаем десятикратный прирост производительности. Особенно по части времени доступа к данным. Например, с двумя SSD Kingston DC1000M U.2 NVMe в серверном RAID 1 мы получим 350 000 IOPS при чтении случайных данных и 75 000 IOPS при записи.
В отношении последовательной скорости чтения результаты будут соответствовать характеристикам накопителя — 3200 Мбайт/с. Но, поскольку оба NVMe SSD находятся в рабочем состоянии, данные могут считываться с них одновременно, что делает операции чтения довольно быстрыми. А вот скорость записи (заявленная составляет 2000 Мбайт/с) будет медленнее, потому что каждая операция записи выполняется дважды.
Массив RAID 1 идеально подходит для небольших баз данных или любой другой среды, которая требует отказоустойчивости, но небольшой емкости. Зеркальное копирование накопителей особенно выручает в сценариях аварийного восстановления (производительность при этом немного ухудшается), поскольку обеспечивает мгновенную “реанимацию” важных данных, если один из накопителей в массиве выходит из строя. Но, поскольку этот уровень защиты требует удвоения емкости для хранения зеркальной копии данных (для хранения 100 Тбайт потребуется 200 Тбайт места), во многих корпоративных системах используются более экономичные варианты хранения: RAID 5 и RAID 6.
RAID 5 на базе SSD Kingston и контроллеров Broadcom
Для организации RAID-массива пятого уровня нам потребуется как минимум три накопителя, данные на которых чередуются (циклически записываются на все накопители в массиве), но не дублируются. При их организации следует учитывать их более сложное устройство, так как здесь появляется такое понятие, как “контрольная сумма” (или же “четность”). Под этим понятием подразумевается логическая алгебраическая функция XOR (она же исключающее „ИЛИ“), которая и диктует использование минимум трех накопителей в массиве (максимум – 32). При этом информация о четности записывается на все «диски» в массиве.
Для массива из четырех SATA SSD-накопителей Kingston DC500R с емкостью по 3,84 Тбайт каждый, мы получим 11,52 Тбайт пространства и 3,84 для контрольных сумм. А если объединить в RAID пятого уровня 16 NVMe-накопителей Kingston DC1000M U.2 с емкостью 7,68 Тбайт — поучим 115,2 Тбайт с потерей 7,68 Тбайт. Как видите, чем больше накопителей, тем в итоге лучше. Лучше еще и потому, что чем больше накопителей в RAID 5, тем выше суммарная производительность при операциях записи. А линейное чтение будет достигать уровня RAID 0.
Группа дисков RAID 5 обеспечивает высокую пропускную способность (особенно для больших файлов) и избыточность с минимальной потерей мощности. Лучше всего такой тип организации массива подходит для сетей, которые выполняют много небольших операций ввода-вывода (I / O) одновременно. А вот использовать его для задач, требующих большого количества операций записи небольших или небольших блоков, не стоит.
Есть и еще один нюанс: при отказе хотя бы одного из NVMe-накопителей, RAID 5 переходит в режим деградации и выход из строя еще одного устройства хранения может стать критичным для всех данных. В случае сбоя одного накопителя в массиве RAID-контроллер использует информацию о четности для воссоздания всех недостающих данных.
When should the defaults be changed?
This type of access pattern is very common for “tube sites” and file download sites. This is because the massive file sizes lend themselves well to less expensive hard drive storage, and large file accesses when using hard drives, is exactly where you can gain a benefit from changing the default settings. In this use case, the default settings massively under-perform compared to an optimized configuration.
For file hosting sites or other use cases where there are large numbers of users simultaneously accessing large files, and these files are stored on hard drives, a large stripe size will give you a huge performance increase compared to a small stripe size.
Разбираем работу SSD Kingston в самых популярных типах RAID — “1”, “5”, “10”, “50”
Итак, “нулевой” уровень RAID не обеспечивает избыточности данных, а только увеличивает производительность. Никакой защиты данных RAID 0 не предоставляет вообще, поэтому в рамках корпоративного сегмента мы его рассматривать не будем. RAID 1, с другой стороны, обеспечивает полную избыточность, но лишь скромный прирост производительности, и поэтому его следует рассматривать в том случае, если повышение производительности не является основополагающим фактором при создании RAID-массива из SSD.
Why does stripe size impact performance?
To understand this, it helps to visualize what is actually happening in a hard drive.
“Hard Drive” by walknboston is licensed under CC BY 2.0
A hard drive has a read-write head attached to an arm, and a spinning disk that contains the actual data. To read a file, the arm has to move to the spot on the disk where the data is located, and the data is read from the disk as it spins past the read-write head.
The main limitation on speed of these hard drives, is how quickly the read-write head can move from one spot on the hard drive to another. Generally, this can occur about 100 times per second — allowing you to read files that are located on 100 different drive locations per second as a maximum.
Therefore, to maximize performance, you want to read as much data as possible each time the read-write head moves to a different part of the disk. Operating systems know this, so, whenever data is requested to be read from disk, the OS goes ahead and reads more data than it was asked to, on the assumption the data might be needed eventually. This feature is called “readahead”. In many operating systems, this readahead value defaults to 256KB.
Example read patterns of a 4 drive raid 0 array / 8 drive raid 10 array, with varying stripe sizes and read sizes
Above you can see which parts of which drives are accessed when performing a read operation of different sizes. Because the start of a file can be anywhere, we indicate the most typical access pattern by assuming the read request begins somewhere in the middle of a stripe.
In the first example, a 256KB read, is very typical because in many operating systems, the default readahead value is 256KB. This means that, even if your application only asks to read 1KB of data from a file, the following 256KB of data from the same file will also be read from disk. If the file is smaller than the 256KB readahead, then the entire file will be read at once. This is why the readahead and stripe values are only important when your typical file size is bigger than the default readahead of 256KB.
Unfortunately, a 256KB stripe is also a common default for raid arrays. So the top-left diagram shows what happens nearly always when using default settings — 256KB of data is read, and, this data is read from 2 different drives from the 4 drive raid 10, 99% of the time. So in this default scenario, 128KB is read from each of two drives, nearly every time. (The read would only occur from a single drive in the rare case where a read quest begins at the exact start of the 256KB raid stripe.)
When changing the stripe size to 1MB, while leaving the readahead to the default of 256KB, you will read the 256KB from just one drive 75% of the time, and it would split the read between two drives 25% of the time. The 25% happens when your 256KB read request begins in the fourth quarter of the stripe. So in most cases, 256KB is read from just one drive, and 25% of the time, 128KB is read from each drive.
Keeping in mind before, each drive can only “seek” to a different part of the disk around 100 times per second. Meanwhile, sequential reads can go about 100MB/s on our example drive (these numbers can be doubled to 200 seeks / sec and 200MB/s on newer drives, but the ratios stay about the same).
So what happens when the default situation causes 128KB reads on each drive, on average, per seek? Well, 128KB read per seek x 100 seeks / second = 12.8MB/s is the maximum performance you’ll get. On a drive that can read 100MB/s, this is only 12% of the maximum speed the drive could perform if it was only doing sequential reads. This is really poor performance, and a big focus on optimizing a RAID array here is to increase this figure.
When are the defaults OK?
For servers that primarily host a lot of small files, or host their data using SSDs, these default settings are probably fine for both readahead and raid stripe size. In the case of SSDs, these defaults are ok because SSDs are very good at reading small bits of data located anywhere on the drive, and so, the stripe size and readahead has little or no effect on performance for modern SSDs as well. For hard drives, for typical use cases, these defaults are also ok because many files are smaller than these default settings. This means that most single files you read are stored on a single drive, and therefore, reading the file only accesses a single drive. Increasing the stripe size in this situation does not change the drive access pattern much, and therefore, doesn’t impact performance much.
So, for many situations, you don’t need to be worried about these settings and the defaults will be fine. However, in one use case, where many users are simultaneously accessing files larger than 256KB, and those files are stored on regular hard drives, the raid stripe and filesystem readahead settings are critically important to improve drive performance.
What are the optimal settings?
For RAID 10 or RAID 0 on regular hard drives, a stripe size of 2MB, if available, is best. If you can’t select a stripe size as large as 2MB, pick the largest value you’re allowed. For hardware raid cards, the maximum stripe size is often 1MB, so this would be the best option in those situations. The default of 256k is not efficient for reading large files from regular hard drives. For SSDs, any value of 128KB or higher should perform fine.
For RAID 5, RAID 50, RAID 6, or RAID 60, a stripe size between 256k and 512k would be ideal for tube sites and large file download sites hosted on hard drives, while a stripe size between 128KB and 256KB would be better when accesses are typically of small files, or when the data is stored on SSD. Why these “parity” type RAID levels are better off with a smaller stripe size is beyond the scope of this article. Suffice it to say if you care about performance, RAID 10 is far better than RAID 5 / 50 / 6 / 60.
For file system readahead settings, the optimal value is typically 512KB so long as your raid stripe is at least 1MB. This will provide the maximum performance for a server that primarily reads large files from hard drives.
But why not increase the readahead and stripe to absurd levels anyway?
It may seem like you can just keep increasing the readahead and always get better performance, but this is not the case. A major caveat is, you don’t want to arbitrarily read multiple megabytes for your readahead. The biggest reason for this is, the data read has to sit in ram until it’s actually needed. If a client is slowly downloading a file, it may take a long time before they need data that’s several MB ahead of what they’ve already downloaded. This data sits in ram as part of the linux file system cache, which is used to store copies of recently read files. To store this new data in the cache, something else has to be removed first. Likewise, if your server needs this ram for some other reason, such as, a different file has just been read from disk, old data will be flushed out of ram. If your end user hasn’t downloaded that data yet, this flushed data will need to be read from the drive again! This is very wasteful of your very limited seeks / second and limited MB/s, forcing the server to read the same data multiple times in order to send it to a user just once.
As well, although a drive can do sequential reads much faster than it can read multiple files, it still takes longer to read a lot of data than a little bit of data, so you only want to read data you’ll actually use. Now that the drive is performing a large percentage of the sequential data transfer it is capable of, there are diminishing returns, and increasing costs, to simply growing the readahead forever.
One way to address this is to manage the amount of ram used for readaheads to a reasonable level, so that the odds are very good that the data will still be in ram when you actually need it. Let’s say that for a server with a good amount of ram (8gb or larger), you don’t want to devote more than 25% of the ram for this purpose. So let’s calculate that out.
For a server with 1,000 simultaneous users downloading files or watching videos, a 1MB readahead means that 1GB of recently read data needs to be kept in ram at all times. This is necessary to prevent this data from being discarded before it is used. For a server with 8gb ram, 1gb ram use is pretty reasonable. There is a good chance this data will not be flushed before you need it.
However, let’s say your server is very busy — it has 10,000 simultaneous connections. Meanwhile, you also are having performance issues, and you think a huge readahead may help with this, so you set it to 10MB. You are hoping that a 10MB readahead and 40MB RAID stripe size will get you to that magic level of 90MB/s reads in the chart from earlier.
However, with a 10MB readahead setting on a server with 10,000 simultaneous users, readaheads will require 100GB of ram! Unless this server 512GB ram or more, it is certain that most of the data you read from disk will be discarded before a user ever downloads it, making your performance problems dramatically worse. As well this is ram that could otherwise be used for larger TCP buffers, which would speed up users downloads. For servers with a huge number of connections, these various caches and buffers are a delicate balancing act.
Как SSD Kingston живут в режиме RAID с контроллерами Broadcom
На заре появления SSD-накопителей RAID-конструкции таили в себе много нюансов. В том числе из-за использования менее отказоустойчивых HDD-дисков. Твердотельные накопители гораздо надежнее своих собратьев на основе магнитных дисков. Как мы знаем, в SSD-решениях нет движущихся элементов, поэтому механические повреждения сведены к нулю. Выход твердотельных накопителей из строя вследствие скачков напряжения тоже маловероятен, учитывая, что на уровне домашнего ПК и любого сервера вас предохраняют ИБП, сетевые фильтры и даже блок питания.
При этом у твердотельных накопителей есть еще один существенный плюс: даже если ячейки памяти износятся на запись – чтение данных с них все равно можно будет произвести, а вот при повреждении магнитного диска – увы.
На сегодняшний день использовать SSD-решения в RAID-массивах разных уровней вполне нормальная практика. Главное – выбирать правильные твердотельные накопители, латентность которых минимальна. А еще в идеале использовать SSD одного и того же производителя и одной и той же модели, чтобы не получилась мешанина из накопителей, поддерживающих разные типы нагрузок и построенных на базе разных типов памяти, контроллеров и прочих технологий. То есть, если уж мы решили закупить для создания RAID-массива четыре или 16 NVMe SSD компании Kingston – пусть лучше все они будут из одной серии и модельного ряда.
К слову, в прошлой статье мы неспроста приводили в пример контроллеры Broadcom, когда говорили о NVMe SSD от Kingston. Дело в том, что в мануалах к этим устройствам сразу прописываются совместимые накопители (включая решения от вышеупомянутого американского производителя SSD), с которыми контроллер будет работать без нареканий. На эту информацию и нужно опираться при выборе связки «контроллер-SSD» для RAID.
What’s the catch?
A big caveat here is that these improvements only occur if the file you are reading is at least as big as the readahead setting. The readahead will only read to the end of the file you are accessing. So, for a web site where 90% of requests are for 10KB image thumbnails, none of this will make a difference. Nearly all requests will be for 10KB images, and, with a default readahead of 256KB these 10KB images will already be loaded in their entirety every time. As well, a 256KB RAID stripe means that, almost always, the entire 10KB file will reside on a single disk, so the disadvantages of a small stripe size do not apply when reading files much smaller than the stripe size.
The situation in our diagram, and the value of these optimizations, are most relevant for file hosting or “tube” sites where the average file size is multiple megabytes, not multiple kilobytes.
Another catch is that there are diminishing returns on the readahead compared to the maximum stripe size. For our final example, let’s look at a 2MB readahead with a 256KB or 1MB stripe size.
The read pattern of a 2MB readahead with either a 256KB or 1MB stripe
What is the performance here? Well, for a 256KB stripe, you read 2MB split across all 4 disks — an average of 512KB per seek. With 100 seeks per second, even the 256KB stripe array can read 51.2MB / s from each disk — much more than with the default 256KB readahead. In our example drive, this is 51% of the maximum performance the drives are capable of, a huge improvement over a 256KB readahead.
The array with a 1MB stripe does even better — in nearly all cases, a 2MB read will require participation from 3 out of 4 drives. 2MB per read with 3 seeks per read 682KB per seek, or 68.2MB/s for a drive that can do 100 seeks / second. This is getting pretty close to the maximum speed our drive can go of 100MB/s.
Can we increase this to huge levels to get even more performance?
Although these values seem even better than before, you can see the rate of improvement is slowing dramatically. For the defaults, a 256KB readahead and 256KB stripe gave you 12.8MB/s. For a 512KB readahead and 1MB stripe, you got to 34.1MB/s. Increasing the readahead a further 4 fold increased theoretical performance to 68.2MB, so this increases are declining fast.
There is also a problem that, we are assuming that reading the data from the drive takes zero time. When the drive is reading data at 10% of the maximum sequential speed, this oversight is a rounding error. But when you’re dealing with reading data at 40 – 60% of the drives maximum theoretical speed, and you assume these sequential reads take zero time, this introduces a huge error into the equation. The drive cannot spend 50% of its time reading data sequentially and then an additional 100% of its time seeking between different files on disk.
The below diagram shows this tradeoff that you make in real world numbers:
Assumes 100MB/s maximum sequential read rate and 100 seeks / second maximum seek rate, typical for a 1TB 7200 RPM SATA Hard drive. Modern 8TB drives may perform up to 2x this.
The KB per seek of 128KB in our default example of 256KB stripe and 256KB readahead is very similar to the 90% time spent seeking example in the above chart. This value gives a hypothetical maximum performance of 10MB/s with 114KB average read per seek — very close to our example figures. However, from our previous example, where a 2MB readahead on n a 256KB stripe would lead to a 512KB read per seek, you can see the performance expected fall be between 30MB/s and 40MB/s levels. This is far short of the 51.2MB/s estimated when we assumed that reading data took zero time. Meanwhile, the 2MB readahead with 1MB stripe would lead to 682KB per seek, which exactly matches the 40MB/s level from the table above. This is also far short of the 68.2MB/s we estimated when assuming that sequential reads take zero time.
For this reason, about 40MB/s, or 40% of the maximum sequential read speed of the drive, is about the realistic maximum you can expect for a multi-client server use case. This is true even if you optimize the raid stripe and readahead perfectly. Beyond this point, additional performance becomes far more difficult to achieve, requiring dramatically increased KB read per seek, which has its own negative performance consequences.
RAID 50 на базе SSD Kingston и контроллеров Broadcom
Комбинированный массив, аналогичный RAID’у десятого уровня, который представляет собой массив нулевого уровня, созданный из массивов пятого уровня. Как и в предыдущем случае, основная цель данного массива состоит в получении удвоенной производительности при сохранении надежности данных в массивах RAID 5. При этом RAID 50 обеспечивает повышенную производительность записи и лучшую защиту данных, нежели стандартный RAID 5 в случае сбоя диска, а также способен к более быстрому восстановлению в случае отказа одного из накопителей.
Группа дисков RAID 50 разбивает данные на более мелкие блоки, а затем распределяет их на каждый массив RAID 5. Группа дисков RAID 5, в свою очередь, также разбивает данные на более мелкие блоки, вычисляет четность, производит логическую операцию OR для блоков, а затем выполняет операции записи в блоки данных и контроля четности для каждого диска в группе дисков.
И хотя производительность неизбежно снижается в случае сбоя одного из накопителей, это не столь существенно, как в массиве RAID 5, поскольку один сбой влияет только на один из массивов, оставляя другой полностью работоспособным. На самом деле RAID 50 может выдержать до восьми отказов HDD/SSD/NVMe-накопителя, если каждый отказавший “диск” находится в отдельном массиве RAID 5.
RAID 50 лучше всего использовать для приложений, которым требуется высокая надежность и которые должны обрабатывать большое количество запросов при сохранении высокой скорости передачи данных и более низкой стоимости накопителей, чем в массиве RAID 10. Однако, поскольку для настройки массива RAID 50 требуется минимум шесть накопителей, стоимость не полностью исключается как фактор. Одним из недостатков RAID 50 является то, что, как и RAID 5, ему нужен сложный контроллер: такой как упомянутый нами в прошлой статье MegaRAID 9460-16i от Broadcom.
Стоит также отметить, что RAID 50 имеет меньше используемого дискового пространства, чем RAID 5, из-за выделения емкости для содержания записей контроля четности. Тем не менее, он все еще имеет больше полезного пространства, чем другие уровни RAID, особенно те, которые используют зеркалирование. При минимальном требовании в шесть дисков RAID 50 может быть дорогостоящим вариантом, но дополнительное дисковое пространство оправдывает затраты, защищая корпоративные данные. Этот тип массива рекомендуется для работы с данными, требующими высокой надежности хранения, высокой частоты запросов, высокой скорости передачи и большой емкости для размещения.
Зачем нужен RAID на SSD?
Преимущества массивов хранения на основе SSD по сравнению с массивами хранения на жестких дисках включают сокращение времени доступа к данным на накопителе и превосходную производительность в операциях чтения/записи. Однако для идеальной производительности RAID’а на базе SSD требуется оптимальное сочетание процессора, кэша, программного и аппаратного обеспечения. Когда все эти факторы идеально работают вместе, RAID-массив из SSD может значительно превзойти сопоставимую конфигурацию с применением традиционных HDD.
Типичный SSD потребляет меньше энергии, чем жесткие диски, поэтому при объединении большого количества твердотельных накопителей в RAID-массив экономия энергии по сравнению с RAID-массивом из HDD может привести еще и к снижению расходов при оплате корпоративных счетов за электроэнергию.
Однако SSD RAID имеет ограничения и недостатки: в частности, более высокая цена за гигабайт пространства по сравнению с жесткими дисками сопоставимой емкости. А время наработки флеш-памяти на отказ ограничено определенным количеством циклов перезаписи. То есть у SSD-накопителей есть определенный срок службы, который зависит от эксплуатации: чем активнее перезаписывается информация на нем, тем быстрее накопитель выйдет из строя. С другой стороны, корпоративные твердотельные накопители имеют приличный срок службы, сопоставимый с механическими жесткими дисками.
How does an optimized RAID stripe improve performance?
To improve performance, you want to do your best to increase the amount of data read for each “seek”. This is where the RAID stripe and readahead play a critical role.
First, lets take a look at the 1MB stripe size. In the first example, still with a 256KB read size, 75% of requests will only “hit” one drive, and each request will still read 256KB. 25% of the time, you read 128KB from each drive for each seek. So on average, this means, for each seek, 224KB of data is read from a drive. Assuming 100 seeks / second, this allows for performance of 22.4MB/s per drive, a 75% performance improvement compared to the default settings!
The next way we can increase performance is to increase the readahead on the array. Our second example shows the result of a 512KB readahead value, with either a 256KB or 1MB stripe.
Two different ways a 512KB sized read can occur on a 1MB stripe RAID array
In the image above, you can see what happens for a read request depending upon where within a stripe the read occurs. For the 256KB stripe, in 99% of cases, a 512KB read will “hit” 3 different disks. (If the read is perfectly aligned to the start of a stripe, it will read from 2 drives in order to complete the request, but this is rare.) For a 1MB stripe, a 512KB read will, 50% of the time, only read from one drive, while 50% of the time it will read from 2 drives to complete the request. Which of these occurs depends how far into the stripe the read request begins, as depicted above.
How does this impact performance? The total data read is 512KB, and, for a 256KB stripe, this requires 3 seeks (you read from 3 different drives). So on average, a single seek results in 171KB of data read. As a single drive can do 100 seeks / second, this equals 17.1MB/s per drive. Compared to the 12.8MB/s you saw on a 256KB stripe with 256KB reads, this is a 33% improvement. Pretty good!
How does this 512KB read size perform for a 1MB stripe? Well, 50% of the time there is 1 seek, and 50% of the time there are 2 seeks — an average of 1.5 seeks per read. Reading 512KB, you average 341KB per seek. As a single drive can do 100 seeks / second, this comes out to 34.1MB/s. Compared to the defaults of 256KB readahead and 256KB stripe size, this is a speed increase of 2.6 times as fast! It also gives you 1/3 of the maximum theoretical performance of the drive, a huge increase from the default case.
RAID 6 и RAID 60: про них мы тоже не забыли
Раз уж мы поговорили о массивах пятого и пятидесятого уровней, грех не упомянуть и о таких типах организации массивов как RAID 6 и RAID 60.
Производительность RAID 6 аналогична RAID 5, но здесь уже минимум два накопителя отдаются под контроль четности, что позволяет массиву пережить выход из строя двух накопителей без потери данных (в RAID 5 такая ситуация крайне нежелательна). Благодаря этому обеспечивается более высокая надежность. В остальном все так же, как и в массиве пятого уровня: в случае сбоя одного или двух дисков контроллер RAID использует блоки четности для воссоздания всей недостающей информации. При сбое двух накопителей восстановление происходят не одновременно: сначала реанимируется первый накопитель, затем – второй. Таким образом, выполняются две операции по восстановлению данных.
Нетрудно догадаться, что, если RAID 50 представляет собой массив нулевого уровня из массивов пятого уровня, то RAID 60 – это массив нулевого уровня из массивов шестого уровня, о которых мы только что рассказали. То есть такая организация RAID-хранилища позволяет пережить потерю двух SSD в каждой группе накопителей RAID 6. Принцип работы схож с тем, про который мы рассказывали в разделе про RAID 50, но количество сбоев, которые может выдержать массив шестидесятого уровня, вырастает с 8 до 16 накопителей. Обычно такие массивы используются для онлайн-обслуживания клиентов, которое требует высокой отказоустойчивости.
Подводим итоги:
Несмотря на то, что зеркалирование обеспечивает большую отказоустойчивость, чем RAID 50/60, оно также требует гораздо больше места. Поскольку количество данных удваивается, вы фактически получаете только 50% от общей емкости установленных в сервере накопителей для записи и хранения информации. Выбор между RAID 50/60 и RAID 10, скорее всего, будет зависеть от имеющихся бюджетов, емкости сервера и ваших потребностей в защите данных. Причем стоимость выходит на первый план, когда мы говорим об SSD-решениях (как корпоративного, так и потребительского класса).
Не менее важно, что теперь мы точно знаем – RAID на базе SSD вполне безопасное решение и нормальная практика для современного бизнеса. В рамках домашнего применения тоже есть резон переходить на NVMe, если позволяют бюджеты. А если у вас еще остался вопрос, зачем же все это нужно, вернитесь к началу статьи – мы уже подробно ответили на него.
Данная статья подготовлена при поддержке наших коллег из Broadcom, которые предоставляют свои контроллеры инженерам Kingston для тестирования с накопителями SATA/SAS/NVMe корпоративного класса. Благодаря этому дружескому симбиозу, клиентам не приходится сомневаться в надежности и стабильности работы накопителей Kingston c HBA- и RAID-контроллерами производства Broadcom.
Дополнительную информацию о продуктах Kingston можно найти на официальном сайте компании.
Do you love servers?
We hope this article has helped you learn about an often-misunderstood and important setting for tuning disk performance. With SSDs becoming ever more popular, there are fewer cases where there is a need to tweak these settings. However, for certain websites hosting large files on hard drives, it is still important to optimize these values. For a RAID 10 array, a filesystem readahead of 512KB and a RAID stripe size of 2MB is ideal (1MB if 2MB is not available). See some of our other articles if you want to know more about similar topics regarding RAID, performance optimization, or server configuration and administration.
В: Что такое RAID и зачем он нужен? Какой RAID лучше использовать?
О: Ответу на этот вопрос посвящен раздел [ RAID ].
В: Можно ли использовать в RAID массиве диски разного размера?
О: Да. можно. Но, при этом, используемая емкость у ВСЕХ дисков будет равна емкости наименьшего диска.
Из этого следует, что добавлять в уже существующий RAID массив можно только диски такого же или большего размера.
В: Можно ли использовать в RAID массиве диски разных производителей?
О: Да, можно. Но при этом надо иметь ввиду, что точные размеры дисков одинаковой емкости (36/73/146. ГБ) у разных производителей могут отличаться на несколько килобайт. Когда вы создаете новый RAID массив, на это можно не обращать внимание, но если вы добавляете диски к уже существующему массиву (например, меняете вышедший из строя диск), то важно, чтобы новый диск был больше чем старые, или точно такого же размера.
В: Что такое Write Through и Write Back?
О: Это способ записи данных, полученных RAID контроллером, на дисковый массив. По другому эти способы еще называются так: прямая запись ( Write Through ) и отложенная запись ( Write Back ). Какой из этих способов будет использоваться определяется в BIOS-е контроллера (либо при создании массива, либо позднее).
- Write Through - данные записываются непосредственно на дисковый массив. Т.е. как только данные получены, они сразу же записываются на диски и после этого контроллер подает сигнал управляющей ОС о завершении операции.
- Write Back - данные записываются сначала в кэш , и только потом (либо по мере заполнения кэш -а, либо в моменты минимальной загрузки дисковой системы) из кэш -а на диски. При этом, сигнал о завершении операции записи передается управляющей ОС сразу же по получении данных кэш -ем контроллера.
Избежать описанной проблемы можно или с помощью установки на RAID контроллер BBU (см. ниже), или посредством подключения всего сервера через источник бесперебойного питания (UPS) с функцией программируемого выключения.
Кстати, некоторые RAID контроллеры не позволяют включить функцию Write Back без установленного BBU .
В: Что такое BBU и зачем он нужен?
О: BBU (Battery Backup Unit ) необходим для предотвращения потери данных находящихся в кэш -е RAID контроллера и еще не записанных на диск (отложенная запись - "write-back caching"), в случае аварийного выключения компьютерной системы.
Существуют три разновидности BBU :
- Просто BBU : это аккумулятор, который обеспечивает резервное питание кэша через RAID контроллер.
- Переносимые (Transportable) BBU (tBBU): это аккумулятор, который размещен непосредственно на модуле кэш и питает его независимо от RAID контроллера. В случае выхода из строя RAID контроллера, это позволяет перенести данные, сохраненные в кэш -е, на резервный контроллер и уже на нем завершить операцию записи данных. : основная идея заключается в следующем: в случае сбоя питания RAID контроллер копирует содержимое кэш -а в энергонезависимую память (например, в случае с технологией Adaptec »Zero-Maintenance Cache Protection - на NAND флэш накопитель). Питание, необходимое для завершения этого процесса, обеспечивается встроенным супер-конденсатором. После восстановления питания, данные из флэш памяти копируются обратно в кэш контроллера.
В: Что такое Hot Spare (Hotspare)?
О: Hot Spare - (Резервная Замена Дисководов ("Горячее резервирование")) - Одна из наиболее важных особенностей, которую обеспечивает RAID контроллер, с целью достичь безостановочное обслуживание с высокой степенью отказоустойчивости. В случае выхода из строя диска, восстанавливающая операция будет выполнена RAID контроллером автоматически, если выполняются оба из следующих условий:
- Имеется "резервный" диск идентичного объема, подключенный к тому же контроллеру и назначенный в качестве резервного, именно он и называется Hotspare ;
- Отказавший диск входит в состав избыточной дисковой системы, например RAID 1 , RAID 3 , RAID 5 или RAID 0+1 .
Обратите внимание: резервирование позволяет восстановить данные, находившиеся на неисправном диске, если все диски подключены к одному и тому же RAID контроллеру.
"Резервный" диск может быть создан одним из двух способов:
- Когда пользователь выполняет утилиту разметки, все диски, которые подключены к контроллеру, но не сконфигурированы в любую из групп дисководов, будут автоматически помечены как "резервные" ( Hotspare ) диски (автоматический способ поддерживается далеко не всеми контроллерами).
- Диск может также быть помечен как резервный ( Hotspare ), при помощи соответствующей утилиты RAID контроллера.
В течение процесса автоматического восстановления система продолжает нормально функционировать, однако производительность системы может слегка ухудшиться.
Для того, что бы использовать восстанавливающую особенность резервирования, Вы должны всегда иметь резервный диск ( Hotspare ) в вашей системе. В случае сбоя дисковода, резервный дисковод автоматически заменит неисправный диск, и данные будут восстановлены. После этого, системный администратор может отключить и удалить неисправный диск, заменить его новым диском и сделать этот новый диск резервным.
В этом разделе использованы материалы с сайта "3dnews".
В: Что такое Copyback Hot Spare?
О: Copyback Hot Spare это функция RAID контроллера, которая позволяет пользователям закрепить физическое расположение диска "горячего резерва" ( Hot Spare ), что позволяет улучшить управляемость системы.
В: Что такое JBOD?
О: JBOD (Just a Bunch of Disks) это способ подключить диски к RAID контроллеру не создавая на них никакого RAID . Каждый из дисков доступен так же, как если бы он был подключен к обычному адаптеру. Эта конфигурация применяется когда необходимо иметь несколько независимых дисков, но не обеспечивает ни повышения скорости, ни отказоустойчивости.
В: Что такое размер страйпа (stripe size)?
О: размер страйпа ( stripe size ) определяет объем данных записываемых за одну операцию ввода/вывода. размер страйпа задается в момент конфигурирования RAID массива и не может быть изменен позднее без переинициализации всего массива. Больший размер страйпа обеспечивает прирост производительности при работе с большими последовательными файлами (например, видео), меньший - обеспечивает большую эффективность в случае работы с большим количеством небольших файлов.
В: Нужно ли заниматься архивированием данных в случае использования RAID?
О: Конечно да! RAID это вовсе не замена архивированию, основное его назначение это повышение скорости и надежности доступа к данным в нормальном режиме работы. Но только регулярное архивирование данных гарантировано обеспечит их сохранность при любых отказах оборудования, пожарах, потопах и прочих неприятностях.
Имеется сервер HP Proliant ML150. Конфигурация 2 x Xeon 2.8GHz, 2GB RAM, Adaptec SCSI Raid 2120S + BBU + 4 x 36GB HDD (15rpm). Сервер будет использоваться для 1С бухгалтерии версии 6 (файл-сервер). Подскажите, пожалуйста, какой оптимальный размер блока (Stripe Size) для массива RAID 10 (именно его хочу использовать) в такой конфигурации? При создании любого (RAID 0, 10, 5 ) массива через БИОС контроллера по умолчанию предлагается значение 256 KB. В меню контроллера есть возможность выбора значений этого параметра от 8 до 1024 KB. Прошивка контроллера самая новая с сайта адаптека (firmware version 8205). Заранее благодарен всем, кто ответит.
Ну хотя бы скажите 256 KB это нормально для Adaptec-a? Может firmware Adaptec-ов заточены под этот размер? А то я как то привык к тому, что универсальным считается размер 64 KB. Не знаю, правда, какой размер по умолчанию был до перепрошивки нового firmware - пришел новый сервер и я сразу обновил BIOS и самого сервера и firmware контроллера ещё до установки OS. Играться с размерами страпа и тестировать нету времени. Посоветуйте хоть что нибудь, пожалуйста.
Да мы просто адаптеки очень мало пользуем. По логике вещей лучше всего работает дефолтный страйп, но конкретно сказать не могу. Лучше всего таки попробовать по быстрому - воткнуть винт с операционкой (чтобы не переставлять после переинитов), создать небольшой том (чтобы инитился шустрее) и прогнать иометр с сотней потоков. За несколько часов управитесь вполне. Или подождите до завтра - придет exLH, он с ними более плотно общался.
Это ваш сотрудник? Если да, то спасибо. Так наверное и сделаю - нету времени тестить. Надеюсь он заглянет в эту ветку
Во-первых, 2120 контроллер старый и не блещет (я с ним не особенно и возился-то). На опыте 2130 скажу, что влияние выставления страйп-сайза конечно роль играет (но далеко не всегда такую, какую хочется . Причины этого (как они мне видятся) я уже излагал - можно поиском найти. Я бы советовал оставить страйп-сайз по умолчанию - контроллер (вернее firmware) "заточен" именно под него.
exLH писал(а): Я бы советовал оставить страйп-сайз по умолчанию - контроллер (вернее firmware) "заточен" именно под него.
То-есьт вы имеете в ввиду, что контроллер 2120s "заточен" под размер страйпа в 256KB? Я правильно понял? Или вообще это дефолтный размер для всех адаптеков? Дело в том что, вот в этой ветке в третем посте человек пишет, что у него тоже после перепрошивки адаптека на более новую версию firmware 7349 размер страйпа по умолчанию изменился с 64 КБ на 256 КБ. Уж не помню точно какая версия стояла у меня до перепрошивки (по памяти вроде 7244, а сейчас у меня версия 8205), но мне почему-то кажется, что раньше у меня тоже по умолчанию размер страйпа выставлялся на 64 КБ.
Неужели это значит, что начиная с версии прошивки 7349 firmware Adaptec-ов заточено под размер страйпа в 256 КБ? Может такое быть?
Если вас не затруднит посоветуйте, пожалуйста, что-нибудь по этому поводу. Потому как терзают смутные сомнения мою голову. Хотелось бы правильно настроить контроллер. Буду вам примного благодарен за любю помощь.
Да Вы столько времени уже убили на вопросы, что не один раз уже можно было эксперимент провести . Мы советуем, если точно знаем. А тут можем дать только общие рекомендации, которые уже высказали.
Вполне вероятно, что адаптек переточил фирмварь под новый страйп.
Спасибо. Возможность этого факта меня и интересовала.
Попробовал всё-таки поганять IOmeter на патерне Fileserver - действительно при страйпе в 256К работает быстрее чем при 64К. Total IOs больше на 25-27% при страйпе 256К в сравнении с страйпом 64К. Решил однозначно ставить 256К :D .
Ради интереса попробовал при 128 КВ - оказалось быстрее чем при 64, но медленне чем при 256, при 512К даже чуть быстрее на 1-5% чем при 256К, а вот при размере страйпа в 1024КВ скорость ниже чем при 256КВ.
Дело в том, что страйп - это не только размер блока на диске. Контроллер внутри себя тоже оперирует данными не на уровне байтов, а на уровне блоков. Размер этих блоков как правило не указывается (разве что майлекс в явном виде позволял этим управлять). И взаимодействие страйпа и внутреннего блока контроллера оценить можно только методом тыка на совершенно кокнретной задаче. Но в большинстве случаев, как мы уже сказали и это подтвердилось Вашим экспериментом, лучше всего работает дефолтный страйп - просто программеры фирмвари выставляют дефолтные размеры не от балды, а так, как они считают более правильным. Им естественно виднее.
Про заточку LSI под 64К слышал только от Тринити, сам не проверял, ну нету у нас LSI Да и нужно ещё отдельно подумать об "правильном" эксперименте и интерпретации его результатов, чтоб сделать вывод о этой "заточке".
А вот у всех контроллеров, что довелось мне потестить никакой "заточки" под дефолтный страйп не наблюдалось. И вообще то есть предположение, что страйп должен быть равен (или ближайшее большее значение) среднему (наиболее часто встречающемуся) размеру блока обмена с диском. Отсюда и знаменитые дефолтные 64К, ибо таким блоком винда с диском обычно работает Но винда, не 1С, последняя может вовсе не 64К'шным блок с диском работать (и что-то мне подсказывает что так оно и будет ), тут уже perfmon'ом смотреть нужно.
Я как правило смотрел иометром с блоками 2к, но пробовал и другие до 64к включительно. Почему говорю о "заточке"? Потому что в большинстве случаев этот страйп оказывался или самым шустрым или среди самых шустрых. Но другие размеры блока на каких-то задачах давали небольшой прирост (порядка 5-10%), а на других достаточно серьезные провалы - в десятки %. Так что 64к - это не абсолютно самый быстрый, но наиболее сбалансированный. А т.к. в большинстве случаев нагрузку точно предугадать невозможно, отсюда и родилась рекомендация. Но точно также мы рекомендуем при наличии времени и точно известных характеристиках нагрузки - поэкспериментировать.
gs писал(а): Я как правило смотрел иометром с блоками 2к, но пробовал и другие до 64к включительно. Почему говорю о "заточке"? Потому что в большинстве случаев этот страйп оказывался или самым шустрым или среди самых шустрых. Но другие размеры блока на каких-то задачах давали небольшой прирост (порядка 5-10%), а на других достаточно серьезные провалы - в десятки %. Так что 64к - это не абсолютно самый быстрый, но наиболее сбалансированный. А т.к. в большинстве случаев нагрузку точно предугадать невозможно, отсюда и родилась рекомендация. Но точно также мы рекомендуем при наличии времени и точно известных характеристиках нагрузки - поэкспериментировать.
Мне этот эксперимент видится примерно так: берем иометр и делаем паттерн 8к блок, соотношение чтение-запись скажем 67-33, колличество потоков 100 (вообще сюда надо подставлять цифры снятые и перфмона на реальной базе). И прогоняем это дело на массиве со страйпом в 2к и с 64к. Сравниваем йопсы, так как они нам и нужны. Линейные потоки это отдельная тема, к ним эти соображения по выбору страйпа не имеют никакого отношения. Вы такой экскримент делали?
Очень часто задают вопрос о том, как правильно выбрать stripe-size для того или иного массива.
Как посчитать, а что будет если на массиве и SQL, и файловый сервер?
А если SQL работает с дисками блоками по 8КБ, а RAID-контроллер не позволяет задать такой страйп, то наверное все теперь будет работать неоптимально и вообще наверное нужно искать такой контроллер, где stripe в 8КБ можно задать?
На самом деле, все это не совсем так.
То что какое-то конкретное приложение общается с дисками блоками по ххКБ вовсе не означает, что именно такой stipe-size будет оптимальным. Поэтому практически всегда на вопрос “как настроить, чтобы было лучше”, следует простой ответ: “оставьте то значение, которое предлагается по умолчанию”.
Разработчики прошивки тратят много времени на оптимизацию кода прошивки, тратят много сил на обеспечение высокой производительности. Но все эти оптимизации наилучшим образом работают как раз на выбранных в качестве “default” значениях.
До недавнего момента я все это говорил, ссылаясь исключительно на свое понимание вопроса, но на днях представитель Adaptec в своем блоге разместил точно такой же совет:
While there is credibility in doing the maths and trying to match the stripe size to the OS/application requirements, the reality is that the defaults will “normally” walk all over specifying a particular size. Why? Because our engineers spend a lot of time in making the defaults work best. We aim to make an out-of-the-box experience for the majority of users, and put a lot of effort into making the product work without a user having to be a rocket scientist to use it.
Зачем же производитель контроллеров дает выбор? Конечно, в ряде случаев можно получить дополнительные проценты (хотя обычно все-таки доли процентов) производительности, тщательно проанализировав характер нагрузки и выбрав значение, которое характерно именно для нее.
Особенно это будет заметно, если размер блоков, которыми приложение общается с дисками, будет больше, чем stripe по умолчанию, а нагрузка создается преимущественно случайным обращением.
Но такая ситуация возникает довольно редко, поэтому если никакие экстраординарные приложения использовать не предполагается, отдайтесь на волю разработчиков и пусть они, зная свой продукт изнутри, выберут для Вас правильные настройки.
P.S. Здесь речь идет о внутренних RAID-контроллерах. В “больших” системах есть свои особенности, связанные с работой кэша, и там оптимизация настроек может дать более заметный эффект.
В прошлом материале мы уже рассмотрели вопрос о том “Применим ли RAID на SSD” на примере накопителей Kingston, но сделали это только в рамках нулевого уровня. В текущей статье мы разберем варианты использования профессиональных и домашних NVMe-решений в самых популярных типах RAID-массивов и расскажем о совместимости контроллеров Broadcom с накопителями Kingston.
RAID 10 на базе SSD Kingston и контроллеров Broadcom
Итак, RAID 0 предоставляет нам двукратный прирост скорости и времени доступа, а RAID 1 обеспечивает надежность. В идеале бы их совместить, и тут на помощь приходит RAID 10 (или же 1+0). “Десятка” собирается из четырех SATA SSD- или NVMe-накопителей (максимум – 32) и подразумевает массив из “зеркал”, количество накопителей в котором всегда должно быть кратно четырем. Данные в этом массиве записываются посредством разбиения на фиксированные блоки (как в случае с RAID 0) и чередования между накопителями, распределяя копии между «дисками» в массиве RAID 1. А благодаря возможности одновременного доступа к нескольким группам дисков, RAID 10 показывает высокую производительность.
Так как RAID 10 способен распределять данные по нескольким зеркальным парам, это означает, что он может допускать сбой одного накопителя в паре. Однако в случае сбоя обеих зеркальных пар (то есть всех четырех накопителей) произойдет неизбежная потеря данных. В итоге мы также получаем хорошую отказоустойчивость и надежность. Но стоит иметь в виду, что, как и RAID 1, массив десятого уровня использует только половину суммарной емкости, а потому является дорогостоящим решением. Да еще и сложным в настройке.
RAID 10 подходит для использования с хранилищами данных, которым требуется 100-процентная избыточность групп зеркальных дисков, а также повышенная производительность ввода-вывода RAID 0. Это лучшее решение для баз данных среднего размера или любой среды, которая требует более высокой отказоустойчивости, чем в RAID 5.
Читайте также: