У нас есть три сервера SQL Server, и на каждом сервере есть около пяти или шести баз данных. Мы находимся в процессе перевода этих серверов в новую сеть SAN, и я работаю над оптимальной конфигурацией RAID. В настоящее время все файлы журнала для всех баз данных совместно используют массив RAID, в этом массиве RAID нет ничего, кроме файлов журнала, но все базы данных используют этот же массив для своих файлов журнала.
Я читал, что файлы журналов лучше всего хранить на отдельных дисках. Но в нашем случае я не уверен, что лучше всего иметь один большой массив примерно с 8 дисками, на которых находятся все файлы журналов. Или было бы лучше создать четыре двух дисковых массива и предоставить некоторым из более крупных баз данных свои собственные выделенные диски для файлов журналов?
Журналы
Журналы - это в основном структура с последовательным доступом. Проще говоря, вы можете рассматривать их как кольцевой буфер записей, которые говорят: «Запишите эти данные в этот блок». Когда механизм БД выдает запись, он фактически записывает одну из этих записей в журнал. Затем процесс чтения журнала выполняет асинхронно и записывает блоки на диск.
Поскольку активность головки диска относительно небольшая, журналы ведутся относительно быстро. Однако, если активность записи журнала конкурирует с активностью произвольного доступа на том же диске, конкуренция может значительно повлиять на производительность записи журнала, что влияет на общую производительность БД.
Кроме того, запись журналов на отдельный диск дает вам некоторую избыточность. Если вы выполняете резервное копирование данных, записи журнала с момента резервного копирования могут быть повторены для восстановленной базы данных. Это означает, что в случае аварии необходимо удалить и журнал, и тома данных, чтобы вызвать потерю данных.
По этим причинам у вас должны быть журналы на отдельном массиве (разных физических дисках) для томов данных. Одна зеркальная пара может обрабатывать довольно большой объем трафика журнала, если нет конкуренции, поэтому вам, вероятно, не понадобится ничего, кроме этого, если у вас нет очень больших объемов транзакций. Однако убедитесь, что на томах журналов больше ничего не генерирует дисковую активность.
TempDB
Если у вас есть процессы, которые интенсивно используют TempDB, вы получите выигрыш в производительности от его использования на томе RAID-10, поскольку это обеспечивает лучшую производительность записи, чем RAID-5. (см. примечания по кэшированию обратной записи ниже). Если вы размещаете свои данные и индексы на томах RAID-5 и у вас есть процессы, которые интенсивно используют TempDB, вы можете получить преимущество, разместив TempDB на отдельном томе RAID-10. Если вы используете RAID-10 и для томов данных, это не имеет значения.
Данные и индексы
Если у вас действительно большие объемы данных, вы можете поместить данные в RAID 5, 6, 50 (чередующиеся блоки RAID-5) или 60. Если ваши объемы данных меньше, вы можете использовать RAID-10. Если у вас есть RAID-5 (или аналогичный) на ваших томах данных, вам, вероятно, понадобится отдельный том TempDB, иначе система, вероятно, будет нормально работать с данными, индексами и TempDB, совместно использующими один том RAID-10.
Кэширование с обратной записью
Если контроллеры RAID в вашей сети SAN поддерживают резервное питание от батареи, вы можете настроить для них кэширование с обратной записью. Это означает, что кэш контроллеров выполняет запись в ОЗУ и оптимизирует запись обратно на диск. Кэширование с обратной записью может значительно повысить производительность томов RAID-5, но добавляет системе дополнительные режимы сбоя.
В случае сбоя питания резервная батарея сохранит кэшированные данные в течение нескольких дней. Когда вы повторно активируете SAN, он запишет кэшированные записи. Теоретически это довольно надежно и, вероятно, сработает. Тем не менее, существует множество анекдотических историй о сбоях кешей обратной записи.
Если вы можете активировать кэширование с обратной записью для каждого тома, рассмотрите возможность его отключения в журналах. Таким образом, сбой кеша может быть восстановлен без повреждения данных путем восстановления базы данных и повторения транзакций журналов, как описано выше. Протестируйте свою систему, чтобы убедиться, что ее производительность удовлетворительна.
Вывод
Отдельные тома журнала и данных. Если вы используете RAID 4, 5, 6, 40, 50 или 60 и у вас большая активность в TempDB, рассмотрите возможность размещения TempDB на отдельном томе RAID-10. Если у вас нет очень больших объемов данных, вы можете совместно использовать данные, индексы и TempDB на томе RAID-10. Тома журналов не должны использовать общие диски с источниками интенсивной дисковой активности.
Массив журнала транзакций должен иметь как минимум RAID 1 (зеркальный), рекомендуется 1 + 0 (зеркальный + чередующийся), для чего требуется как минимум 4 физических диска.
RAID 5 НИКОГДА не следует использовать для журналов транзакций, только для файлов данных из-за характера последовательной записи для журналов транзакций, а для повышения производительности вы всегда должны разделять файлы журнала и данных на разные физические массивы.
Я бы разделил его только на 2 массива, иначе вы тратите много дисков. Если у вас есть один массив с 8 дисками, у вас должно быть 7 дисков. Однако если у вас 4 массива, у вас будет только 4 диска.
Еще одна вещь, о которой следует подумать, это производительность чтения и записи RAID 1 по сравнению с RAID 5. Теоретически RAID 1 как 1x запись, 2x чтение и 2x поиск, тогда как RAID 5 имеет (N-1) x запись, Nx чтение и 1x поиск . Теоретически, на практике ваши шаблоны чтения / записи / кеширования и контроллер имеют значение.
Шаблон доступа к диску для файлов журнала - только добавление. Запись журнала станет определяющим фактором для общей производительности в базах данных с большим количеством операций обновления или вставки. Поиск головки диска доминирует во время выполнения физического ввода-вывода.
С точки зрения общей производительности, цель состоит в том, чтобы предоставить каждому файлу журнала отдельный дисковый шпиндель, чтобы движение головки всегда было минимальным.
В целях надежности дополните эту стратегию так, чтобы каждый файл журнала получал двухдисковый аппаратный RAID 1.
Хранение файлов журнала в сети SAN может затруднить контроль за конфликтом заголовков диска, в зависимости от рассматриваемой системы SAN.
Я бы предпочел 2 отдельных RAID1, состоящих из 2 дисков каждый, а не RAID0 / 1 (или 1/0), сделанный из 4 дисков, если мы говорим о хранении файлов журналов для нескольких разных баз данных. Выберите базу данных с наибольшей активностью файла журнала и дайте ей собственный набор шпинделей.
Как предлагается в другом месте, отбросьте любые мысли об использовании RAID5.
Немного поздно, но отвечу на будущее.
Все предыдущие ответы верны, но для локальных дисков; С SAN, NAS (те крупные коммерческие, а не ваши домашние) это меняется.
Уточните у своего поставщика и модель, которую вы приобретаете. Причина в том, что производители заявляют, что RAID на самом деле не имеет значения для журналов транзакций. Производители также заявляют, что отдельные диски для журналов транзакций и файлов данных вызовут проблемы с производительностью, и их следует размещать на одном томе.
Отчасти это связано с тем, что в сетях SAN, если вы не получите полные диски, другой том будет двигать головками, и вы потеряете прирост производительности, а также узким местом будет HBA и сеть, а не диски.
Итак, посмотрите, что производитель рекомендует для оборудования, а затем начните тестирование и мониторинг.
Чем больше вы разделяете пути данных, тем меньше будет конфликтов, поэтому с точки зрения производительности разумнее разделить массивы и предоставить каждую базу данных (или самые загруженные, не самые большие, но те, которые совершают наибольшее количество транзакций за во-вторых) собственный лог-файл на диске.