Не обращайте внимания на тот SAN за занавеской

Не наживая врагов в команде SAN, как я могу убедить себя и разработчиков приложений в том, что наши серверы SQL не страдают от плохо настроенного хранилища? Просто использовать статистику perfmon? Другие тесты, такие как sqlio?

Короче говоря, вероятно, нет способа быть по-настоящему уверенным. Я бы сказал (я администратор SAN), что если ваши приложения работают в соответствии с вашими ожиданиями, не беспокойтесь об этом. Если вы начинаете видеть проблемы с производительностью, которые, по вашему мнению, могут быть связаны с производительностью SAN / Disk IO, возможно, стоит спросить. Я не использую много хранилищ HP, как вы, но в мире IBM / NetApp я могу сказать по опыту, что не так много вариантов, которые позволили бы вам настроить его «плохо». Большинство корпоративных хранилищ в наши дни требует много догадок при построении массивов рейдов и действительно не позволяет вам сделать это неправильно. Если они не смешивают скорости и емкости дисков в рамках одних и тех же групп рейдов, в большинстве случаев вы можете быть уверены, что ваш диск работает нормально.

Если я проведу нагрузочный тест на этих дисках SAN, действительно ли это даст мне надежную, повторяемую оценку того, что я увижу, когда мы начнем работать? (при условии, что программное обеспечение SAN может по-разному "динамически настраиваться" в разные моменты времени.)

Нагрузочное тестирование должно быть достаточно надежным. Просто имейте в виду, что при нагрузочном тестировании одного бокса, находящегося в общем массиве SAN / Disk, на его производительность могут (и будут) влиять другие системы, использующие то же хранилище.

Влияет ли интенсивный ввод-вывод в одной части SAN (скажем, на сервере Exchange) на мои SQL-серверы? (при условии, что они не предоставляют выделенные диски каждому серверу, как мне сказали, что это не так)

Это может. Дело не только в дисках или дисках, на которых находятся серверы. Все данные обслуживаются контроллером диска, а затем коммутатором SAN. Производительность, которую вы увидите, в значительной степени зависит от того, как контроллер диска подключен к соответствующим дисковым полкам и соответствующему SAN. Если весь массив подключается к магистральной сети SAN через одну прядь оптоволоконного кабеля 4 Гбит / с, очевидно, что это отразится на производительности. Если массив подключен через две резервные сети SAN, которые сбалансированы по нагрузке, с использованием транковых каналов, тогда для одного обмена будет невозможно использовать слишком большую полосу пропускания. Еще одна вещь, которую необходимо учитывать, - это количество операций ввода-вывода в секунду, на которое способен массив. Пока массив и сеть SAN, к которой он подключен, масштабируются правильно, интенсивный ввод-вывод в других частях среды SAN не должен влиять на производительность SQL.

Поможет ли здесь запрос разделения логических дисков для различных функций логических дисков (данные vs журнал vs tempdb)? Будет ли SAN видеть различную активность ввода-вывода на них и оптимально настраивать их по-другому?

Вероятно, это вопрос ваших предпочтений, а также во многом зависит от того, как его настраивают администраторы хранилища. Они могут предоставить вам три LUN в одном массиве или томе, и в этом случае все равно все будет одинаково. Если они предоставили вам отдельные LUN ​​на разных массивах, в разных томах (физически разных дисках), то, возможно, вам стоит разделить их.

Прямо сейчас мы находимся в небольшом космическом кризисе. Командам разработчиков приказывают обрезать архивы данных и т. Д. Могут ли проблемы с пространством заставить команду SAN принимать различные решения о том, как они настраивают внутреннее хранилище (уровни RAID и т. Д.), Что может повлиять на производительность моего сервера?

Я не думаю, что ваш администратор хранилища изменит уровень рейда, чтобы освободить место. Если да, то его, вероятно, следует уволить. Проблемы с пространством могут привести к тому, что вещи будут настроены по-другому, но обычно это не влияет на производительность. Они могут просто стать немного более ограниченными в отношении того, сколько места они вам дают. Они могут включать такие функции, как дедупликация данных (если массив поддерживает это), что может снизить производительность массива во время выполнения процесса, но не круглосуточно.

У команды SAN должны быть инструменты, которые помогут вам определить, является ли ваше приложение активным. Очевидно, вы должны контролировать и измерять и со своей стороны.

По большей части мой опыт связан с EMC, так что YMMV. Но следующее должно относиться к большей части оборудования SAN.

В массив входит ограниченное количество портов. Иногда между ними есть переключатель SAN, который позволяет определять зоны. Тот факт, что массив по сути представляет собой большой пул хранилища, не означает, что вам не следует беспокоиться о производительности ввода-вывода.

Поэтому, если вы чувствуете, что у вас проблемы с вводом-выводом, вам нужно сузить круг проблем. Если он находится где-то между HBA и массивом, вы можете выяснить, исчерпан ли HBA или порт SAN на стороне коммутатора / массива превышен. Кроме того, у вас должна быть команда SAN для отслеживания шаблонов доступа для вашего приложения, как при холодном запуске, так и в горячем состоянии.

Очевидно, что базовое хранилище имеет значение, скажем, медленный большой RAID5 против быстрого RAID10, поскольку в какой-то момент вам придется ударить по диску независимо от разных уровней кеша.

HTH. Вы можете связаться со мной в автономном режиме, если у вас возникла конкретная проблема, так как это может занять некоторое время.

Не наживая врагов в команде SAN, как я могу убедить себя и разработчиков приложений в том, что наши серверы SQL не страдают от плохо настроенного хранилища? Просто использовать статистику perfmon? Другие тесты, такие как sqlio?

Первое, что вам нужно знать, прежде чем проводить какое-либо тестирование, - это то, с какой толерантностью должна работать ваша собственная рабочая нагрузка. Поэтому протестируйте свои собственные данные, прежде чем проверять новую систему. Таким образом, если вы обнаружите, что вы выдвигаете максимум, скажем, 56 МБ / с во время пиковых нагрузок (резервное копирование?), Обнаружив, что дисковый массив, подключенный к SAN, «только» выдвигает 110 МБ / с при моделируемых пиковых нагрузках, вы можете быть уверен, что ограничение не будет на канал ввода-вывода.

Проверяя новый дисковый массив, я проводил такое тестирование производительности. В новом массиве использовались диски SATA вместо дисков Fibre Channel (SCSI), и мне нужно было убедиться, что он будет работать в нашей среде. Я был в глубоком сомнении. Но после характеристики я обнаружил, что новая система имеет достаточно накладных расходов ввода-вывода при пике, чтобы не отставать от измеренного пика на более надежных дисках. Это меня удивило.

Если я проведу нагрузочный тест на этих дисках SAN, действительно ли это даст мне надежную, повторяемую оценку того, что я увижу, когда мы начнем работать? (при условии, что программное обеспечение SAN может по-разному "динамически настраиваться" в разные моменты времени.)

Из-за общего характера подключенных к SAN дисковых массивов производительность меняется в течение недели. Если вы уже знаете, когда у вас пиковая нагрузка ввода-вывода, выполните серию нагрузочных тестов в течение дня, когда ваша пиковая нагрузка ввода-вывода. Таким образом, вы сможете лучше охарактеризовать, какие накладные расходы ввода-вывода доступны в периоды, которые вас больше всего интересуют. Нагрузочные тесты в непиковые периоды дадут вам представление о том, насколько быстро все будет происходить, но пиковое тестирование будет дать вам проверку истинных границ.

Влияет ли интенсивный ввод-вывод в одной части SAN (скажем, на сервере Exchange) на мои SQL-серверы? (при условии, что они не предоставляют выделенные диски каждому серверу, как мне сказали, что это не так)

Если LUN Exchange используют общие диски с вашими SQL LUN, они обязательно это сделают. Мы используем HP EVA, а не XP, но я думаю, что они используют ту же терминологию «группы дисков». LUN в одной группе дисков совместно используют диски и поэтому конкурируют за ввод-вывод на этих физических устройствах. Чем больше дисков вы помещаете в дисковую группу, тем больше пространства для маневра у массива для операций ввода-вывода. Массивы (по крайней мере, это делают EVA, и я предполагаю, что более дорогие XP делают то же самое) распределяют логические блоки LUN по физическим дискам непоследовательным образом. Это позволяет ему делать то, что вы предлагаете, а именно динамически распределять группы часто используемых блоков по разным физическим устройствам для увеличения параллелизма и уменьшения числа конфликтов ввода-вывода на уровне диска.

Возникает вопрос: какой бюджет ввода-вывода имеет эта дисковая группа, и не превышена ли для приложений, использующих эти LUN, подписка на ввод-вывод. Это вопрос, который администраторы хранилища должны будут отслеживать. Может случиться так, что пиковое количество операций ввода-вывода для Exchange (вероятно, во время резервного копирования) может не совпадать с загрузкой SQL, и обе системы могут успешно сосуществовать.

Поможет ли здесь запрос разделения логических дисков для различных функций логических дисков (данные vs журнал vs tempdb)? Будет ли SAN видеть различную активность ввода-вывода на них и оптимально настраивать их по-другому?

Для массивов HP вам нужно будет поместить разные шаблоны ввода-вывода на другой диск. группы не LUN. Например, шаблоны ввода-вывода базы данных не должны сосуществовать с шаблонами доступа к веб-серверу. Разные LUN ​​не могут заметно улучшить вашу производительность, если они не находятся в разных дисковых группах. Если они находятся в одной дисковой группе, единственное реальное преимущество - это операционная система, которая может выполнять планирование ввода-вывода в ядре, чтобы улучшить параллелизм с дисковой подсистемой. Тем не менее ...

Массивы HP, насколько я понимаю, знают о различных шаблонах доступа к LUN, но уделяют пристальное внимание фактическим логическим блокам. Размещение журналов на другом LUN накладывает ограничения на логические блоки, которые будут получать такой трафик ввода-вывода, и это упростит задачу правильной сортировки логических блоков на физических дисках.

Мы сейчас находимся в небольшом космическом кризисе. Командам разработчиков приказывают обрезать архивы данных и т. Д. Могут ли проблемы с пространством заставлять команду SAN принимать различные решения о том, как они настраивают внутреннее хранилище (уровни RAID и т. Д.), Что может повлиять на производительность моего сервера?

Определенно. Если места мало, вы не собираетесь получать выделенные дисковые группы для ввода-вывода (если только ваша среда хранения не достаточно велика, чтобы оправдать выделение 7 ТБ физического диска для вашего исключительного использования, в этот момент это может быть так. ). Дебаты Raid5 / Raid10 во многом зависят от политики организации, и лучше всего спросить.

Я предлагаю начать диалог с вашей командой SAN и поставщиком, чтобы решить ваши проблемы. Одна из проблем, с которыми вы столкнетесь при запуске собственных тестов, заключается в том, что ваши тесты могут не иметь отношения к тому, что происходит в производственной среде, особенно при пиковых нагрузках. Большинство сетей SAN имеют массу кэш-памяти с автономным питанием, что во многих случаях (особенно при выполнении синтетических тестов) означает, что вы выполняете запись в ОЗУ и получаете отличную производительность.

В зависимости от вашей среды и решения, которое вы используете, какой-то поставщик CE может просто прилететь и настроить SAN на любой стандарт, который он предпочитает. Так бывает чаще, чем вы думаете. Вам придется отказаться от оболочки «команда SAN знает все», пока вы не будете уверены, что решение соответствует вашим требованиям.

Удачи.

Однажды я был на конференции оракулов с докладом на эту тему - нормальный SAN для баз данных.

Суть доклада доступна в этот файл PDF или на сайте авторов Вот