Относится к этот вопрос: при построении сети хранения данных администраторы хранения обычно создают массивы физических дисков на основе типа ввода-вывода (последовательный или произвольный доступ) и предоставляют LUN из этих массивов хостам, которым требуется этот конкретный тип ввода-вывода?
Это зависит ™. Для ваших стандартных малоиспользуемых виртуальных машин я обычно помещаю большинство из них на несколько RAID 6 и позволяю кэшированию и многоуровневому управлению пакетами. Для таких вещей, как сильно пострадавший сервер БД Exchange или SQL Server, у них обычно есть выделенные LUN (ы), которые предназначены для их нужд.
Однако это действительно зависит от вашей архитектуры хранения.
Я стараюсь соответствовать ожидаемым требованиям ввода-вывода к архитектуре. Практически для всего, что я делал, подход SAN если вы загрузите в него достаточно дисков, общее количество операций ввода-вывода превысит все рабочие нагрузки, кроме специализированных в итоге работает очень хорошо. Если у меня 96 используемых шпинделей, то общего количества операций ввода-вывода, имеющихся в моем распоряжении, будет достаточно, чтобы файлы журнала SQL-сервера загружались даже с сервером Exchange, работающим на тех же дисках.
Теория (разделение ввода / вывода - лучшая практика) переходит в реальность в том, как спроектированы некоторые из этих больших массивов SAN. В то время последовательный Количество операций ввода-вывода четырех дисков по 15 000 об / мин довольно велико, многие из этих массивов намеренно рандомизируют структуру блоков, поэтому вы не получите такой производительности, даже если вы создадите дисковую группу из 4 дисков, выделенную исключительно для одного тома журнала SQL. Они, вероятно, столкнутся с некоторыми последовательными преимуществами, поскольку размер блока обычно больше, чем 4 КБ, используемый самими дисками, но это не будет кричащий демон, которого вы ожидаете от чистой последовательной загрузки.
Это вступает в игру, если я строю преданный хранилище для базы данных. Это предполагает, что потребности в вводе-выводе этой единственной службы настолько велики, или что SLA ввода-вывода достаточно жесткое, поэтому гарантии производительности являются обязательными. В этом случае я фактически создам отдельные дисковые группы для таких вещей, как тома Log, TempDb и DB. Такой дизайн случается не очень часто, на самом деле очень редко.
Я бы хотел сказать `` да '' на это, так как это заставит меня выглядеть суперпрофессионально, но, честно говоря, в 99% случаев я просто покупаю любой тип массива, который мне нужен (сейчас я прохожу большую фазу 3Par, но я за эти годы я прошел через большинство из них) и купите столько полок, сколько у меня хватит места, затем заполните их дисками нужного количества и скорости, а затем создайте LUN, соответствующие уровню RAID и требованиям к производительности - хотя я обычно не принимайте во внимание, является ли производительность случайной или последовательной. Я склонен предполагать все, но резервные копии будут случайным вводом-выводом, поэтому основываю свои предположения на этом, по крайней мере, так, если я действительно получу некоторые преимущества кэширования или последовательного выполнения, то это просто «подливка». Я знаю, что это звучит немного лениво, но я присматриваю за МНОЖЕСТВОМ массивов, и, если у вас нет очень фиксированного набора требований, всегда должна быть какая-то `` комната для маневра '', связанная с загрузкой массивов, вы никогда не сможете получить правильно-впервые.
Тем не менее, для местного DAS я склонен быть более конкретным, так как это сложнее изменить, но обычно я не использую слишком много этого.
Нет, потому что для большинства томов в сети SAN выполняется несколько типов операций ввода-вывода. Если есть часть вашей среды, которую вы можете предсказать (например, сервер базы данных на 80% выполняет случайное чтение или сервер резервного копирования на 90% выполняет последовательную запись), разделение может принести вам пользу, если у вас (а) нет широкой полосы, и все еще помещают тома в определенные рейды, и (б) у вас достаточно устаревший контроллер, чтобы вы могли серьезно повысить производительность с помощью RAID-10.
изменить: щелкнув, разделение журналов базы данных и данных является хорошей идеей по большему количеству причин, чем тип RAID. Даже если вы используете один и тот же тип RAID, вы хотите разделить их, чтобы контроллер мог использовать разные алгоритмы оптимизации кэша для каждого тома.
Если у вас есть пулы, преимущества разделения этих рабочих нагрузок на их собственный пул дисков обычно не оправдывают затрат на производительность. За некоторыми исключениями, лучше всего поместить все тома для всех типов ОС в один большой пул, содержащий все ресурсы.