В настоящее время я разрабатываю новый сервер резервного копирования. Он будет работать под управлением Windows Server 2012 R2 с хранилищем с прямым подключением, и я рассматриваю возможность использования дисковых пространств, а не карты RAID. (Как поклонник ZFS, я определенно вижу преимущества отказа от аппаратного RAID, если все сделано правильно.)
Я ожидаю, что мои критически важные для производительности рабочие нагрузки будут в основном последовательными. Поскольку это массовое хранилище последовательных данных, где производительность чтения (восстановление резервных копий) более критична, чем производительность записи (создание резервных копий), я подумал, что четность будет хорошей подходящей для получения плотного и недорогого хранилища данных резервного копирования.
Я видел некоторые результаты в блогах, когда дело доходит до записи производительности дисков четности, например, в эта статья Деррика Влодарца из Beta News, а также в этот технический документ от Fujutsu.
Изучая это подробнее, кажется, что статья в блоге не тестировалась с выделенными дисками журналов, которые, по-видимому, могут значительно повысить производительность записи в пространстве хранения с четностью, согласно эта статья TechNet. К сожалению, ни один из двух тестов, о которых я упоминал ранее, не тестировал влияние дисков журналов, но Microsoft утверждает, что они увидели прирост производительности на 150%, что для моего приложения, я думаю, поместит его там, где я хочу, чтобы производительность была .
Все это хорошая информация, но есть один кусок головоломки, который мне не удалось найти. Рассматриваемые твердотельные накопители должны использоваться только для ведения журнала в зеркале, и, насколько я понимаю, они предназначены только для обеспечения краткосрочного стабильного хранения записей. Таким образом, я не думаю, что они должны быть очень большими. По крайней мере, таков вывод, который я сделал из работы с дисками ZFS и ZIL - размер не критичен, хотя в этом случае диски большего размера могут прослужить дольше при интенсивной нагрузке записи, поскольку запись распределяется по большему диску.
Я уже понимаю, что, поскольку все, что записано в массив, также будет записано в журнал, они должны иметь возможность записывать с желаемой скоростью. Как говорит Microsoft:
Обратите внимание, что пропускная способность дисков журнала теперь будет общим пределом пропускной способности для всех пространств четности, созданных в этом конкретном пуле хранения, и вы можете обменять дополнительную емкость на производительность. Другими словами, убедитесь, что выделенные диски журнала работают очень быстро, и увеличивайте количество дисков журнала в соответствии с количеством пространств четности в пуле.
Однако я не смог найти и надеюсь, что Server Fault сможет мне помочь: Есть ли какие-либо передовые практики для выбора подходящего размер SSD-накопителей, которые будут использоваться в качестве дисков журнала для массива четности дискового пространства?
Мате, ответ уже в цитате. Вы можете добавить несколько SSD, а не большой SSD.
Вы были правы, что журнал - это просто тайник для паритета. Но это значит, что для зеркальных пространств это совершенно бесполезно. Даже WBC по умолчанию составляет максимум 1 ГБ для любого массива, который вы можете переопределить с помощью PowerShell, но есть также жесткий предел в 100 ГБ.
В наши дни вы даже не можете купить SSD меньше 120 ГБ. Просто возьми их, и все будет в порядке. Я тоже так поступил.
Я также могу доказать это с помощью цифр, ознакомьтесь с моей серией подробных тестов по этому поводу:
Пробелы с четностью TL; DR - отстой даже с выделенным журналом, но не так уж и много. На самом деле, это отстой, даже если это чистый SSD-массив. Обидно, правда. Microsoft дает много бла-бла об этом, но на самом деле, если MD и ZFS могут делать это правильно, почему они не могут?