Стандартная практика для разделения файлов журнала и данных для отделения дисков от ОС (также tempdb, резервные копии и файл подкачки). Имеет ли смысл эта логика, когда все ваши диски основаны на SAN, а ваши LUNS не вырезаны из определенных наборов дисков или рейдов? - они всего лишь часть x количества дисков в SAN, а LUN - это просто выделение пространства
Журналы и диски с данными имеют разные шаблоны доступа к данным, которые конфликтуют друг с другом (по крайней мере, теоретически), когда они совместно используют диск.
Запись в журнал
Доступ к журналу состоит из очень большого количества небольших последовательных записей. Несколько упрощенно, журналы БД представляют собой кольцевые буферы, содержащие список инструкций для записи элементов данных в определенные места на диске. Шаблон доступа состоит из большого количества небольших последовательных операций записи, выполнение которых должно быть гарантировано, поэтому они записываются на диск.
В идеале журналы должны находиться в тихом (т.е. не совместно используемом ни с чем другом) томе RAID-1 или RAID-10. Логически вы можете рассматривать процесс как основную СУБД, записывающую записи журнала, и один или несколько потоков чтения журналов, которые используют журналы и записывают изменения на диски данных (на практике процесс оптимизирован так, что записи данных записываются немедленно, где это возможно). Если на дисках журнала есть другой трафик, эти другие обращения перемещают головы, и последовательные записи журнала становятся случайными записями журнала. Они намного медленнее, поэтому загруженные диски журналов могут создать точку доступа, которая выступает узким местом для всей системы.
Запись данных
(обновлено) Записи журнала должны быть зафиксированы на диске (называемом стабильным носителем), чтобы транзакция была действительной и имела право на фиксацию. Логически это можно рассматривать как записи журнала, которые затем используются в качестве инструкций для записи страниц данных на диск асинхронным процессом. На практике записи на дисковые страницы фактически подготавливаются и буферизируются в момент создания записи в журнале, но их не нужно записывать немедленно, чтобы транзакция была зафиксирована. Дисковые буферы записываются на стабильный носитель (диск) процессом Lazy Writer (спасибо Полу Рэндалу за указание на это), который Эта статья Technet обсуждает более подробно.
Это в значительной степени шаблон произвольного доступа, поэтому совместное использование одних и тех же физических дисков с журналами может создать искусственное узкое место для производительности системы. Записи журнала должны быть записаны для транзакции для фиксации, поэтому случайные поиски замедляют этот процесс (случайный ввод-вывод много медленнее, чем последовательный ввод-вывод журнала) превратит журнал из последовательного в устройство произвольного доступа. Это создает серьезное узкое место в производительности в загруженной системе, и этого следует избегать. То же самое применимо при совместном использовании временных областей с томами журналов.
Роль кеширования
Контроллеры SAN, как правило, имеют большие кэши ОЗУ, которые могут в определенной степени поглощать трафик произвольного доступа. Однако для целостности транзакций желательно, чтобы запись на диск из СУБД была гарантированно завершена. Когда контроллер настроен на использование кэширования с обратной записью, грязные блоки кэшируются, и вызов ввода-вывода сообщается хосту как завершенный.
Это может сгладить множество проблем, связанных с конкуренцией, поскольку кэш может поглощать много операций ввода-вывода, которые в противном случае были бы отправлены на физический диск. Он также может оптимизировать чтение и запись с четностью для RAID-5, что снижает влияние томов RAID-5 на производительность.
Вот характеристики, лежащие в основе концепции «Пусть SAN решит это», хотя эта точка зрения имеет некоторые ограничения:
Кэширование с обратной записью все еще имеет режимы сбоя, которые могут привести к потере данных, и контроллер обманул СУБД, заявив, что блоки были записаны на диск, а на самом деле этого не произошло. По этой причине вы можете не захотеть использовать кэширование с обратной записью для транзакционного приложения, особенно для чего-то, что содержит критически важные или финансовые данные, где проблемы с целостностью данных могут иметь серьезные последствия для бизнеса.
SQL Server (в частности) использует ввод-вывод в режиме, в котором флаг (называемый FUA или принудительный доступ к обновлению) принудительно выполняет физическую запись на диск перед возвратом вызова. Microsoft имеет программа сертификации и многие поставщики SAN производят оборудование, которое соблюдает эту семантику (требования суммированы Вот). В этом случае никакое количество кеша не будет оптимизировать запись на диск, что означает, что трафик журнала воля thrash, если он сидит на занятом общем томе.
Если приложение генерирует большой дисковый трафик, его рабочий набор может переполнить кеш, что также вызовет проблемы с конкуренцией при записи.
Если сеть SAN используется совместно с другими приложениями (особенно на том же диске), трафик из других приложений может создавать узкие места в журнале.
Некоторые приложения (например, хранилища данных) генерируют большие временные всплески нагрузки, что делает их антисоциальными в сетях SAN.
Даже в больших SAN отдельные тома журналов по-прежнему рекомендуются. Вы можете не беспокоиться о макете в малоиспользуемом приложении. В действительно больших приложениях вы можете даже получить преимущество от нескольких контроллеров SAN. Oracle публикует серию тематических исследований компоновки хранилищ данных, в которых некоторые из более крупных конфигураций включают несколько контроллеров.
Возложите ответственность за производительность там, где она должна
На объектах с большими объемами или где производительность может быть проблемой, возложите на группу SAN ответственность за производительность приложения. Если они собираются игнорировать ваши рекомендации по настройке, убедитесь, что руководство осведомлено об этом и что ответственность за производительность системы лежит на соответствующем месте. В частности, установите приемлемые руководящие принципы для ключевой статистики производительности БД, такой как ожидания ввода-вывода или ожидания защелки страниц, или приемлемые SLA ввода-вывода приложений.
Обратите внимание, что разделение ответственности за производительность между несколькими командами создает стимул для того, чтобы переложить ответственность на другую команду. Это известный антипаттерн управления и формула проблем, которые тянутся месяцами или годами, но никогда не решаются. В идеале должен быть один архитектор с полномочиями определять изменения конфигурации приложения, базы данных и SAN.
Кроме того, протестируйте систему под нагрузкой. Если вы можете организовать это, бывшие в употреблении серверы и массивы с прямым подключением можно будет довольно дешево купить на Ebay. Если вы настроили такой ящик с одним или двумя дисковыми массивами, вы можете изменить конфигурацию физического диска и измерить влияние на производительность.
В качестве примера я провел сравнение между приложением, работающим в большом SAN (IBM Shark), и двухсокетным блоком с массивом U320 с прямым подключением. В этом случае оборудование на сумму 3000 фунтов стерлингов, приобретенное на ebay, в два раза превзошло высокопроизводительную сеть SAN стоимостью 1 млн фунтов стерлингов - на хосте с примерно эквивалентной конфигурацией процессора и памяти.
Исходя из этого конкретного инцидента, можно утверждать, что наличие чего-то подобного - очень хороший способ сохранить честность администраторов SAN.
Я предполагаю, что тег Equallogic и содержание запроса означают, что вы имеете дело с Equallogic SAN. Дальнейшее описание относится именно к Equallogic и не относится к другим типам SAN.
С массивами Equallogic конкретные диски, используемые для томов, не могут быть указаны так точно, как, скажем, с массивами EMC Clariion, поэтому подход должен быть немного другим.
Архитектура Equallogic очень автоматизирована и динамична. Его основным строительным блоком является блок массива, а не пакеты \ группы RAID в массиве, как в других сетях SAN. Каждый массив полностью настроен для RAID 5, 6, 10 или 50, хотя это не означает, что существует только одна группа RAID на массив, вы просто никогда не сможете принимать решения или взаимодействовать с ними на этом уровне. Вы помещаете массивы в пулы хранения, а затем ваши пулы принадлежат к группе хранения. Группа хранения имеет кластерный \ виртуальный IP-адрес, который вы используете в качестве цели обнаружения iSCSI для всех томов в этой группе - программное обеспечение для управления EQL Group и стек MPIO хоста обрабатывают перенаправление уровня IP, необходимое для фактического перенаправления на наиболее подходящий порт на отдельные массивы при запросе блоков данных, но это то, что у вас мало или нет возможности контролировать.
Тома хранения назначаются из общего свободного пространства в каждом пуле. Все тома в пуле распределены по всем массивам в этом пуле (максимум до 4 отдельных массивов), чтобы распределить сетевой ввод-вывод по общему количеству сетевых интерфейсов (2-4 на каждый массив Eql в зависимости от модели) и ввод-вывод. через как можно больше контроллеров. Программное обеспечение управления Equallogic отслеживает производительность тома \ массива с течением времени и динамически оптимизирует распределение блоков по массивам-членам. В общем, если вы не знаете, что делаете, вам следует поместить все массивы в один пул и позволить ему делать свое дело, просто не забудьте убедиться, что вы настроили свои высокоскоростные диски (SAS 10k \ 15k) с RAID 10, среднюю скорость с RAID 50 или 5, чтобы гарантировать, что процесс оптимизации действительно выберет действительно высокопроизводительные диски. Чтобы действительно достичь оптимального состояния, может потребоваться несколько дней (7+), но в целом он должен довольно быстро достичь сбалансированного распределения, поскольку он немедленно распределяет тома по как можно большему количеству массивов (снова до 4), когда они изначально создан.
Грубо говоря, у вас будет где-то между 2500-5000 операций ввода-вывода в секунду на массив PS, в зависимости от типа диска и типа RAID. Если вы обеспечите достаточное количество общих операций ввода-вывода в секунду, тогда автоматизированный процесс управления должен в конечном итоге дать вам хорошую производительность, даже если вы просто объедините все тома в один пул.
Однако, если вы хотите гарантировать, что ваши журналы, базы данных, временные хранилища, диски ОС и т. Д. Фактически изолированы друг от друга, вы можете сделать несколько вещей. Во-первых, вы можете определить предпочтение RAID для тома, которое будет гарантировать, что конкретный том всегда будет храниться только в массивах этого типа RAID (если они присутствуют в пуле, к которому принадлежит том). Во-вторых, вы можете определить многоуровневые пулы хранения, которые содержат только массивы, обеспечивающие различные уровни производительности, необходимые для этого конкретного уровня, а затем распределить свои тома по соответствующим пулам. Предупреждение о вреде для здоровья, связанное с этим подходом, заключается в том, что вам обычно потребуется много массивов, чтобы это действительно обеспечило лучшую общую производительность - это может быть менее важно для вас, чем гарантия производительности на ваших критических томах, хотя часто это все равно лучше выбор. Эталонная архитектура Dell для Oracle DB использует один пул с 2 массивами RAID 10 для данных, диска для голосования и OCR, а также отдельный пул с одним массивом RAID 5 для Flash Recovery Area.
На всех этапах работы с Equallogic вы должны спрашивать себя, будут ли решения, которые вы принимаете в отношении принудительного разбиения, обеспечить лучшую совокупную производительность для ваших томов с точки зрения доступных сетевых интерфейсов, дисковых шпинделей и контроллеров. Если вы не можете ответить на этот вопрос, выберите минимальное количество пулов и оставьте его разбираться с деталями или попросите специалиста Equallogic сделать настоящий дизайн. Если у вас есть только один массив, вы ничего не можете сделать с точки зрения разделения томов.
Мы храним наши БД на отдельных блоках SAN, но с отдельными данными, журналами и резервными логическими модулями, каждый на разных дисковых группах, многоуровневыми по скорости - с нашими журналами на RAID 10 15Krpm LUN, данными на RAID 1 10 / 15krpm LUN и резервным копированием на RAID 5 LUN со скоростью 7,2 об / мин. Мы также представляем журналы и данные через разные контроллеры в одной сети SAN.
Отличный вопрос!
Сначала взгляните на Брент Озар "Steel Cage BlogMatch" дискуссии по этому поводу.
В нашей компании для большинства серверов мы помещаем данные и журналы на один диск SAN и оставляем это на усмотрение группы SAN, чтобы убедиться, что все работает правильно.
Я начинаю думать, что это не лучшая стратегия, особенно для серверов большого объема. Основная проблема заключается в том, что у меня действительно нет возможности проверить, действительно ли команда SAN делает что-то большее, чем собирает вместе достаточное количество дисков для необходимого нам пространства. Мы не запускаем тесты ввода-вывода для дисков SAN с нашей стороны или чего-то еще, мы просто предполагаем, что они «делают свою работу» (корректируя производительность, а также занимаемое пространство), что, вероятно, немного наивно.
Другая моя мысль заключается в том, что Добрый Доступ к данным и журналам отличается. Я попытаюсь найти статью, которую я недавно прочитал, в которой говорилось о том, что два разных типа дисков действительно должны быть оптимизированы очень разными способами (я думаю, что одному нужна оптимизация для последовательной записи, а другому - для случайного чтения, что-то в этом роде .)
Короче говоря, да, вы должны создать отдельные тома для файлов данных SQL Server, файлов журналов и файлов данных и журналов TempDB.
Поскольку вы отметили свой вопрос с помощью Equallogic, прочтите бесплатный Справочное руководство по архитектуре Dell: Развертывание Microsoft® SQL Server® с массивами хранения Dell ™ EqualLogic ™ серии PS5000 (требуется регистрация) перед проектированием вашего решения. Часто вы обнаружите, что рекомендации по конкретным конфигурациям могут значительно отличаться от общих рекомендаций.
Я бы согласился с BradC (+1) по производительности. Как правило, в хорошей SAN будет больше необработанных операций ввода-вывода, чем вы можете ожидать.
По-прежнему неплохо отделить свои РЕЗЕРВНЫЕ КОПИИ от вашей действующей системы (очевидно, я знаю, но если бы у меня был 1 фунт стерлингов за каждый раз, когда я это вижу ...)
Также рекомендуется хранить базу данных tempdb подальше от файлов журнала. Палатка парня SAN закатит глаза на вас, когда вы начнете нуждаться в "разных бакетах" (технический термин) для журналов, данных и температуры, но если вы скажете им это, вы сможете измерить различный объем ввода-вывода данных, идущий в каждую область и пусть они покажут вам свои причудливые графики производительности!
Просто дважды / дважды проверьте, правильно ли настроили SAN-специалисты. Если вам нужен RAID 10, настаивайте на нем (я), даже несмотря на то, что они продолжали говорить, что их RAID 5 не имеет потери производительности.
(Для "файловых" операций вполне подойдет RAID 5. Для интенсивных операций записи, как только вы заполняете буфер записи, вы облажались!)
Также помните о смешении терминов здесь ..
В общем, и очень простые:
У вас может быть несколько томов в одном массиве, о чем следует помнить, когда вы выполняете полноценную оптимизацию, обсуждаемую в этом потоке.
Ключевым моментом является то, что упомянули несколько других (не забывайте), разделение данных / журнала / резервного копирования на разных шпинделях дисков, а не только на отдельные тома.
Изменить: и Helvick выше дал вам отличный ответ о Equallogic SAN!