Когда-то я создавал свои собственные SQL-серверы и контролировал конфигурацию дисков, уровни RAID и т. Д. Традиционный совет по разделению данных, журналов, базы данных tempdb, резервных копий (в зависимости от бюджета!) Всегда был довольно важной частью процесса проектирования сервера SQL.
Теперь с SAN уровня предприятия я просто запрашиваю определенный объем дискового пространства для нового сервера SQL, разделенного на логические диски для данных, резервных копий и общих файловых ресурсов. Конечно, облегчает мою работу, но есть часть меня, которая чувствует себя не совсем комфортно, потому что я не могу заглянуть «за кулисы», чтобы увидеть, что там на самом деле происходит.
Насколько я понимаю, команда SAN не настраивает различные «типы» дисков по-разному (оптимизация дисков данных для произвольного доступа по сравнению с дисками журналов для потоковой записи). Отчасти это может зависеть от самого продукта SAN (у нас есть HP XP12000 и HP XP24000), но я был уверен, что программное обеспечение HP выполняет все виды конфигурации динамической производительности (отслеживая горячие точки ввода-вывода и перенастраивая на лету, чтобы оптимизировать эти LUN), чтобы командам приложений и администраторам баз данных не приходилось беспокоиться ни о чем подобном. Что-то о «распределении нагрузки на все серверы по огромному количеству шпинделей» или что-то в этом роде.
Мои вопросы / обсуждение:
Не делая врагов в команде SAN, как я могу заверить себя и разработчиков приложений, что наши SQL-серверы не страдают от плохо сконфигурированного хранилища? Просто использовать статистику perfmon? Другие тесты, такие как sqlio?
Если я загружу тест на эти диски SAN, это действительно дает мне надежную, повторяемую меру того, что я увижу, когда мы начнем жить? (при условии, что программное обеспечение SAN может «динамически настраиваться» по-разному в разные моменты времени.)
Влияет ли тяжелый ввод-вывод в одной части SAN (скажем, на сервер Exchange) на мои SQL-серверы? (при условии, что они не дают выделенные диски каждому серверу, как мне сказали, это не так)
Поможет ли здесь запрос на разделение логических дисков для различных функций логических дисков (data vs log vs tempdb)? Будет ли SAN видеть разные операции ввода-вывода и оптимально настраивать их по-разному?
Мы сейчас в некотором космическом кризисе. Группам приложений говорят, что нужно урезать архивы данных и т. Д. Может ли проблема с пространством привести к тому, что группа SAN примет разные решения о том, как настроить внутреннее хранилище (уровни RAID и т. Д.), Что может повлиять на производительность моего сервера?
Спасибо за ваши мысли (похожая тема кратко обсуждается в этом вопросе SF )
Ответы:
Не делая врагов в команде SAN, как я могу заверить себя и разработчиков приложений, что наши SQL-серверы не страдают от плохо сконфигурированного хранилища? Просто использовать статистику perfmon? Другие тесты, такие как sqlio?
Короче говоря, наверняка нет способа быть по-настоящему уверенным. Я бы сказал (я администратор SAN), что если ваши приложения работают в соответствии с вашими ожиданиями, не беспокойтесь об этом. Если вы начнете видеть проблемы с производительностью, которые, по вашему мнению, могут быть связаны с производительностью ввода-вывода SAN / Disk, тогда стоит поинтересоваться. Я не так много использую хранилище HP, как вы, но в мире IBM / NetApp я могу сказать по своему опыту, что не так много вариантов, которые позволили бы вам настроить его «плохо». Большинство корпоративных хранилищ в наши дни отнимает много догадок при создании raid-массивов и не позволяет вам сделать это неправильно. Если они не смешивают скорости и емкости дисков в одних и тех же рейд-группах, в большинстве случаев вы можете быть уверены, что ваш диск работает нормально.
Если я загружу тест на эти диски SAN, это действительно дает мне надежную, повторяемую меру того, что я увижу, когда мы начнем жить? (при условии, что программное обеспечение SAN может «динамически настраиваться» по-разному в разные моменты времени.)
Нагрузочное тестирование должно быть достаточно надежным. Просто имейте в виду, что при нагрузочном тестировании одного блока это означает, что, находясь в общем SAN / Disk Array, на его производительность могут (и будут) влиять другие системы, использующие то же хранилище.
Влияет ли тяжелый ввод-вывод в одной части SAN (скажем, на сервер Exchange) на мои SQL-серверы? (при условии, что они не дают выделенные диски каждому серверу, как мне сказали, это не так)
Может. Это не все о дисках или дисках, на которых работают серверы. Все данные обслуживаются через контроллер диска, а затем коммутатор SAN. Производительность, которую вы увидите, во многом зависит от того, к какому дисковому контроллеру подключены соответствующие дисковые полки и соответствующая SAN. Если весь массив подключится к магистральной сети SAN по одной нити 4 Гбит / с волокна, то очевидно, что это повлияет на производительность. Если массив подключен к двум резервным SAN, которые сбалансированы по нагрузке с использованием транкинговых каналов, то для одного обмена невозможно будет использовать слишком большую полосу пропускания. Еще одна вещь, которую необходимо учитывать, - это количество операций ввода-вывода в секунду, на которые способен массив. Пока массив и SAN, к которому он подключен, правильно масштабируются,
Поможет ли здесь запрос на разделение логических дисков для различных функций логических дисков (data vs log vs tempdb)? Будет ли SAN видеть разные операции ввода-вывода и оптимально настраивать их по-разному?
Вероятно, это вопрос предпочтений, который также сильно зависит от того, как его настраивают администраторы хранилища. Они могут дать вам три LUN в одном и том же массиве или томе, в любом случае все равно. Если они дали вам отдельные логические модули в разных массивах, на разных томах (физически разных дисках), то, возможно, стоит разделить их.
Мы сейчас в некотором космическом кризисе. Группам приложений говорят, что нужно урезать архивы данных и т. Д. Может ли проблема с пространством привести к тому, что группа SAN примет разные решения о том, как настроить внутреннее хранилище (уровни RAID и т. Д.), Что может повлиять на производительность моего сервера?
Я не думаю, что ваш администратор хранилища изменит уровень рейда, чтобы освободить место. Если он это сделает, то его, вероятно, уволят. Проблемы с пространством могут привести к тому, что вещи будут конфигурироваться по-разному, но обычно это не влияет на производительность. Они могут просто стать немного более узкими в том, сколько места они вам дают. Они могут включать такие функции, как дедупликация данных (если массив поддерживает это), которые могут снизить производительность массива во время выполнения процесса, но не круглосуточно.
источник
У команды SAN должны быть инструменты, которые помогут вам определить, является ли ваше приложение горячим. Очевидно, вы должны следить и измерять на своем конце тоже.
Большая часть моего опыта связана с EMC, поэтому YMMV. Но следующее должно относиться к большинству оборудования SAN.
В массив входит только очень много портов. Иногда между ними есть переключатель SAN, с помощью которого вы можете определять зоны. Тот факт, что массив представляет собой большой пул хранения, не означает, что вам не следует беспокоиться о производительности ввода-вывода.
Поэтому, если вы чувствуете, что у вас проблемы с вводом-выводом, вам нужно сузить место, где находится узкое место. Если он находится где-то между HBA и массивом, вы можете выяснить, не превышен ли HBA или не превышен ли порт SAN на стороне коммутатора / массива. Кроме того, у вас должны быть шаблоны доступа для группы мониторинга SAN для вашего приложения, как с холодного старта, так и с горячих.
Очевидно, что основное хранилище действительно имеет значение, скажем, работает медленный большой RAID5 по сравнению с быстрым RAID10, поскольку в какой-то момент вам придется попадать на диск независимо от разных уровней кэша.
НТН. Вы можете пропинговать меня в автономном режиме, если у вас есть конкретная проблема, так как это может занять некоторое время, чтобы разобраться.
источник
Не делая врагов в команде SAN, как я могу заверить себя и разработчиков приложений, что наши SQL-серверы не страдают от плохо сконфигурированного хранилища? Просто использовать статистику perfmon? Другие тесты, такие как sqlio?
Первое, что вам нужно знать, прежде чем приступать к каким-либо сравнительным тестам, - это какой допуск необходим для вашей рабочей нагрузки. Поэтому сравните ваши собственные результаты, прежде чем проверять новую систему. Таким образом, если вы обнаружите, что во время пиковых нагрузок вы используете максимальную нагрузку, скажем, 56 МБ / с, обнаружив, что дисковый массив, подключенный к SAN, «только» передает 110 МБ / с при имитированных пиковых нагрузках, вы можете заверил, что предел не будет каналом ввода / вывода.
При проверке нового дискового массива я провел такой тест производительности. В новом массиве вместо дисков Fibre Channel (SCSI) использовались диски SATA, и мне нужно было убедиться, что он будет работать в нашей среде. Я был глубоко сомнителен. Но после определения характеристик я обнаружил, что в новой системе достаточно пиковых нагрузок ввода-вывода, чтобы соответствовать измеренному пику на более надежных дисках. Это удивило меня.
Если я загружу тест на эти диски SAN, это действительно дает мне надежную, повторяемую меру того, что я увижу, когда мы начнем жить? (при условии, что программное обеспечение SAN может «динамически настраиваться» по-разному в разные моменты времени.)
Из-за общей природы дисковых массивов, подключенных к SAN, производительность меняется в течение недели. Если вы уже знаете, когда ваша пиковая нагрузка ввода-вывода, выполните серию нагрузочных тестов в течение дня, когда ваша пиковая нагрузка ввода-вывода. Таким образом, вы сможете лучше охарактеризовать, какие издержки ввода / вывода доступны в те периоды, которые вас больше всего интересуют. Нагрузочные тесты в непиковые периоды дадут вам представление о том, как получатся «быстрые» вещи, но пиковое тестирование даст дать вам проверку истинных границ.
Влияет ли тяжелый ввод-вывод в одной части SAN (скажем, на сервер Exchange) на мои SQL-серверы? (при условии, что они не дают выделенные диски каждому серверу, как мне сказали, это не так)
Если LUN Exchange совместно используют диски с вашими LUN SQL, они обязательно будут. Мы используем EVA HP, а не XP, но я думаю, что они используют ту же терминологию «группы дисков». LUN в той же группе дисков совместно используют диски и, следовательно, борются за ввод-вывод на этих физических устройствах. Чем больше дисков вы поместите в группу дисков, тем больше пространства для маневра у массива будет для манипулирования вводом / выводом. Массивы (по крайней мере, EVA делают это, и я предполагаю, что более дорогие XP делают то же самое) распределяют логические блоки LUN по физическим дискам непоследовательным образом. Это позволяет ему делать то, что вы предлагаете, то есть динамически распределять группы часто используемых блоков на разные физические устройства, чтобы повысить параллелизм и уменьшить конфликты ввода-вывода на уровне диска.
Вопрос, который нужно задать, состоит в том, какой бюджет ввода-вывода имеет эта группа дисков, и не превышены ли в приложениях, использующих эти LUN, значения ввода-вывода. Это вопрос, который администраторы хранилища должны будут отслеживать. Может случиться так, что пиковый ввод-вывод для Exchange (вероятно, во время резервного копирования) может не совпадать с нагрузками SQL, и обе системы могут счастливо сосуществовать.
Поможет ли здесь запрос на разделение логических дисков для различных функций логических дисков (data vs log vs tempdb)? Будет ли SAN видеть разные операции ввода-вывода и оптимально настраивать их по-разному?
Для массивов HP вам необходимо разместить разные шаблоны ввода / вывода в разные группы дисков, а не в LUN. Например, шаблоны ввода-вывода базы данных не должны сосуществовать с шаблонами доступа к веб-серверу. Разные LUN не улучшат вашу производительность, если они не находятся в разных дисковых группах. Если они находятся в одной группе дисков, единственным реальным преимуществом является операционная система, в которой она может выполнять планирование ввода-вывода в ядре для улучшения параллелизма дисковой подсистеме. Это сказал ...
Массивы HP, на мой взгляд, в любом случае, знают о различных шаблонах доступа на LUN, но уделяют пристальное внимание фактическим логическим блокам. Размещение журналов на другом LUN накладывает ограничение на логические блоки, которые будут получать такого рода трафик ввода-вывода, и это облегчит задачу правильной сортировки логических блоков на физических дисках.
Мы сейчас в некотором космическом кризисе. Группам приложений говорят, что нужно урезать архивы данных и т. Д. Может ли проблема с пространством привести к тому, что группа SAN примет разные решения о том, как настроить внутреннее хранилище (уровни RAID и т. Д.), Что может повлиять на производительность моего сервера?
Определенно. Если места недостаточно, вы не будете получать выделенные группы дисков для своего ввода-вывода (если ваша среда хранения не достаточно велика, чтобы оправдать выделение 7 ТБ физического диска для вашего исключительного использования, и в этот момент это может иметь место). ). Дискуссия о Raid5 / Raid10 в значительной степени зависит от политики организации, и лучше всего спрашивать.
источник
Я предлагаю открыть диалог с вашей командой SAN и поставщиком, чтобы решить ваши проблемы. Одна из проблем, с которой вы столкнетесь при выполнении собственных тестов, заключается в том, что ваши тесты могут не иметь отношения к тому, что происходит в производственной среде, особенно при пиковых нагрузках. Большинство сетей хранения данных имеют тонны кэша с резервным питанием от батареи, что во многих случаях (особенно когда вы запускаете синтетические тесты производительности) означает, что вы пишете в ОЗУ и получаете невероятную производительность.
В зависимости от вашей среды и используемого вами решения, некоторые поставщики CE, возможно, только что прилетели и настроили SAN в соответствии со стандартом, который он предпочитает. Это происходит чаще, чем вы думаете. Вам придется отказаться от оболочки «Команда SAN знает все», пока не будете уверены, что решение соответствует вашим требованиям.
Удачи.
источник
Однажды я был на конференции оракула с докладом на эту тему - вменяемым SAN для баз данных.
Суть доклада доступна в этом файле PDF или на сайте авторов здесь
источник