Это стандартная практика - отделять файлы журналов и данных для отделения дисков от ОС (tempdb, резервные копии и файл подкачки). Имеет ли смысл эта логика, когда все ваши диски основаны на SAN, а ваши LUNS не разделены на определенные наборы дисков или рейдов? -это всего лишь часть x-го числа дисков в сети SAN, а LUN - это просто место
Журналы и диски данных имеют разные шаблоны доступа к данным, которые конфликтуют друг с другом (по крайней мере, теоретически), когда они совместно используют диск.
Журнал пишет
Доступ к журналу состоит из очень большого количества небольших последовательных записей. Несколько упрощенно, журналы БД - это кольцевые буферы, содержащие список инструкций для записи элементов данных в определенные места на диске. Шаблон доступа состоит из большого количества небольших последовательных записей, которые должны быть гарантированно завершены - поэтому они записываются на диск.
В идеале журналы должны находиться на тихом (то есть не разделенном между собой) томе RAID-1 или RAID-10. Логически вы можете рассматривать процесс как основную СУБД, записывающую записи журнала и один или несколько потоков чтения журнала, которые потребляют журналы и записывают изменения на диски данных (на практике процесс оптимизируется так, что записи данных записываются сразу по возможности). Если на дисках журнала есть другой трафик, заголовки перемещаются этими другими доступами, и последовательные записи журнала становятся случайными записями журнала. Это намного медленнее, поэтому занятые диски могут создать горячую точку, которая действует как узкое место во всей системе.
Запись данных
(обновлено) Записи журнала должны быть зафиксированы на диске (называемом стабильным носителем), чтобы транзакция была действительной и имела право на фиксацию. Логически это можно увидеть как записи в журнале, которые затем записываются, а затем используются как инструкции для записи страниц данных на диск с помощью асинхронного процесса. На практике записи на диск на самом деле подготавливаются и буферизируются в момент создания записи в журнале, но их не нужно записывать немедленно для фиксации транзакции. Дисковые буферы записываются на стабильный носитель (диск) с помощью процесса Lazy Writer (спасибо Полу Рэндалу за указание на это), который в этой статье Technet обсуждается более подробно.
Это модель произвольного доступа, поэтому совместное использование одних и тех же физических дисков с журналами может создать искусственное узкое место для производительности системы. Записи журнала должны быть записаны для фиксации транзакции, поэтому случайный поиск замедляет этот процесс (случайный ввод-вывод намного медленнее, чем последовательный ввод-вывод журнала) превратит журнал из последовательного в устройство произвольного доступа. Это создает серьезное узкое место в производительности в загруженной системе, и его следует избегать. То же самое относится и к совместному использованию временных областей с томами журнала.
Роль кеширования
Контроллеры SAN, как правило, имеют большие кэш-памяти ОЗУ, которые могут в определенной степени поглощать трафик произвольного доступа. Однако для обеспечения целостности транзакций желательно иметь запись на диск из СУБД, гарантированно завершенную. Когда контроллер настроен на использование кэширования с обратной записью, грязные блоки кэшируются, и вызов ввода-вывода сообщается хосту как завершенный.
Это может сгладить множество проблем с конкуренцией, поскольку кэш-память может поглощать много операций ввода-вывода, которые в противном случае выходили бы на физический диск. Он также может оптимизировать чтение и запись по четности для RAID-5, что уменьшает влияние на производительность томов RAID-5.
Вот те характеристики, которыми руководствуется школа мысли «Пусть SAN справится с этим», хотя эта точка зрения имеет некоторые ограничения:
Кэширование с обратной записью все еще имеет режимы сбоя, которые могут привести к потере данных, и контроллер подключился к СУБД, заявив, что блоки записаны на диск, а на самом деле их нет. По этой причине вы, возможно, не захотите использовать кэширование с обратной записью для транзакционного приложения, особенно для хранения критически важных или финансовых данных, где проблемы с целостностью данных могут иметь серьезные последствия для бизнеса.
SQL Server (в частности) использует ввод-вывод в режиме, когда флаг (называемый FUA или принудительный доступ с обновлением) принудительно выполняет физическую запись на диск до возврата вызова. У Microsoft есть программа сертификации, и многие поставщики SAN производят оборудование, которое соответствует этой семантике (требования приведены здесь ). В этом случае никакое количество кеша не оптимизирует запись на диск, что означает, что трафик журнала будет зависать, если он находится на занятом общем томе.
Если приложение генерирует много дискового трафика, его рабочий набор может переполнить кэш, что также вызовет проблемы с конфликтами при записи.
Если SAN используется совместно с другими приложениями (особенно на том же диске), трафик из других приложений может создавать узкие места в журнале.
Некоторые приложения (например, хранилища данных) генерируют большие скачки переходной нагрузки, что делает их довольно антисоциальными в сетях SAN.
Даже в больших SAN отдельные тома журналов все еще рекомендуются. Вы можете сойти с рук, не беспокоясь о макете в слабо используемом приложении. В действительно больших приложениях вы можете даже получить выгоду от нескольких контроллеров SAN. Oracle публикует серию тематических исследований по макету хранилища данных, где в некоторых из более крупных конфигураций используются несколько контроллеров.
Возложите ответственность за производительность там, где она принадлежит
На объектах с большими объемами или где производительность может быть проблемой, сделайте команду SAN ответственной за производительность приложения. Если они собираются игнорировать ваши рекомендации по настройке, убедитесь, что руководство осведомлено об этом и что ответственность за производительность системы лежит в соответствующем месте. В частности, установите приемлемые руководящие принципы для ключевой статистики производительности БД, такой как ожидания ввода-вывода или ожидания защелки страниц или приемлемые SLA приложений-ввода-вывода.
Обратите внимание, что ответственность за распределение производительности между несколькими командами создает стимул для того, чтобы уточнить и передать ответственность другой команде. Это известный анти-паттерн управления и формула для проблем, которые тянутся месяцами или годами, так и не решаясь. В идеале должен быть единый архитектор с полномочиями определять изменения приложения, базы данных и конфигурации SAN.
Также проведите тестирование системы под нагрузкой. Если вы можете это организовать, то на Ebay можно купить недорогие серверы и массивы прямого подключения на Ebay. Если вы настроите такую коробку с одним или двумя дисковыми массивами, вы сможете изменить конфигурацию физического диска и измерить влияние на производительность.
В качестве примера я провел сравнение между приложением, работающим в большой сети SAN (IBM Shark), и коробкой с двумя сокетами с массивом U320 с прямым подключением. В этом случае оборудование стоимостью 3000 фунтов стерлингов, приобретенное у ebay, превзошло высокопроизводительную сеть хранения данных стоимостью 1 млн фунтов стерлингов в два раза - на хосте с примерно эквивалентной конфигурацией процессора и памяти.
В связи с этим конкретным инцидентом можно утверждать, что подобные вещи - очень хороший способ сохранить честность администраторов SAN.
Я предполагаю, что тег Equallogic и содержание запроса означают, что вы говорите о Equallogic SAN. Далее следует конкретно об Equallogic, и он не применяется к другим типам SAN.
При использовании массивов Equallogic конкретные диски, используемые для томов, не могут быть указаны так точно, как они могут, например, с массивами EMC Clariion, поэтому подход должен быть немного другим.
Equallogic архитектура очень автоматизирована и динамична. Его основной строительный блок - это блок массива, а не пакеты / группы RAID в массиве, как это видно в других сетях SAN. Каждый массив полностью сконфигурирован для RAID 5, 6, 10 или 50, хотя это не означает, что для каждого массива существует только одна группа RAID, вы просто никогда не сможете решать или взаимодействовать с ними на этом уровне. Вы помещаете массивы в пулы хранения, а ваши пулы затем входят в группу хранения. Группа хранения имеет кластерный \ виртуальный IP-адрес, который вы используете в качестве цели обнаружения iSCSI для всех томов в этой группе - программное обеспечение для управления группой EQL и стек MPIO хоста обрабатывают перенаправление уровня ip, необходимое для фактической маршрутизации на наиболее подходящий порт на отдельные массивы при запросе блоков данных, но это то, что у вас мало или нет возможности контролировать.
Тома хранения назначаются из общего свободного пространства в каждом пуле. Все тома в пуле распределены по всем массивам в этом пуле (максимум до 4 отдельных массивов) для распределения сетевого ввода-вывода по общему количеству сетевых интерфейсов (2-4 на массив Eql в зависимости от модели) и ввода-вывода через столько контроллеров, сколько возможно. Программное обеспечение управления Equallogic отслеживает производительность тома / массива с течением времени и динамически оптимизирует распределение блоков по массивам элементов. В общем, если вы не знаете, что делаете, вы должны поместить все массивы в один пул и позволить ему делать свое дело, просто не забудьте настроить высокоскоростные диски (SAS 10k \ 15k) на RAID 10, среднюю скорость на RAID 50. или 5, чтобы гарантировать, что процесс оптимизации действительно выбирает действительно высокопроизводительные диски.
В грубом приближении у вас будет где-то между 2500-5000 IOP на массив PS, в зависимости от типа диска и типа RAID. Если вы предоставляете достаточное количество IOP, то автоматизированный процесс управления должен в конечном итоге обеспечить хорошую производительность, даже если вы просто объедините все тома в один пул.
Однако, если вы хотите гарантировать, что ваши журналы, базы данных, временные хранилища, диски ОС и т. Д. Фактически изолированы друг от друга, вы можете сделать несколько вещей. Во-первых, вы можете определить предпочтение RAID для тома, который будет гарантировать, что определенный том всегда хранится только в массивах этого типа RAID (если они присутствуют в пуле, к которому принадлежит том). Во-вторых, вы можете определить многоуровневые пулы хранения, которые содержат только массивы, обеспечивающие различные уровни производительности, требуемые для этого конкретного уровня, а затем распределяете ваши тома в соответствующие пулы. Предупреждение о работоспособности, которое приходит с этим подходом, заключается в том, что вам, как правило, понадобится много массивов, чтобы на самом деле обеспечить лучшую общую производительность - это может быть менее важно для вас, чем гарантировать производительность на ваших критических томах, хотя зачастую это все еще лучший выбор. Эталонная архитектура Dell для баз данных Oracle использует один пул с 2 массивами RAID 10 для данных, диск для голосования и OCR, а также отдельный пул с одним массивом RAID 5 для области восстановления Flash.
В любой момент времени с Equallogic вы должны спросить себя, будут ли решения, которые вы принимаете в отношении принудительного разбиения, обеспечивать лучшую совокупную производительность для ваших томов с точки зрения доступных сетевых интерфейсов, дисковых дисков и контроллеров. Если вы не можете ответить на этот вопрос, выберите минимальное количество пулов и оставьте его обрабатывать детали или попросите специалиста по Equallogic сделать реальный дизайн. Если у вас есть только один массив, то вы ничего не можете сделать с точки зрения разделения томов.
источник
Мы храним наши БД в отдельных блоках SAN, но с отдельными LUN для данных, журналов и резервных копий, каждая на разных группах дисков, с разбивкой по скорости - с нашими журналами на LUN RAID 10 15Krpm, данными на LUN RAID 10 10 / 15krpm и резервным копированием на RAID 5 7.2krpm LUN. Мы также представляем журналы и данные через разные контроллеры в одной и той же сети 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 подходит. Для интенсивной записи, как только вы заполняете буфер записи, ваш облажался!)
источник
Знайте обо всем смешении терминов здесь также.
В общем и целом:
В одном массиве может быть несколько томов, о которых следует помнить, когда вы выполняете полноценную оптимизацию, обсуждаемую в этой теме.
Ключевым моментом является то, о чем упоминали несколько других (не забывайте об этом), разделение данных / журнала / резервного копирования на разных дисках, а не только на отдельных томах.
Изменить: и Хелвик выше дал вам большой ответ об Equallogic SAN!
источник