Производительность ввода-вывода MSSQL снизилась после консолидации SAN?

Первое, что следует помнить при объединении этих массивов EQL в единый пул, - это то, что рабочая нагрузка на каждом томе может повлиять на производительность на других томах. Возможно, ваша база данных SQL - хотя сейчас она находится на большем количестве физических шпинделей - имеет больше конфликтов за ресурсы из-за того, что другие рабочие нагрузки используют одни и те же шпиндели.

Второй важный фактор, который приходит на ум, - это сеть хранения. Если участники находятся в отдельных пулах или группах, почти весь сетевой трафик iSCSI идет от ввода-вывода к узлам или от них. Однако с участниками в одной группе и пуле вы должны учитывать внутригрупповой трафик - в основном, перемещение страниц. Движение страниц сохраняет используемую емкость даже между участниками, а также уравновешивает «горячие» данные участникам с относительно более низкой рабочей нагрузкой. Ознакомьтесь с официальным документом на Балансировщики нагрузки Equallogic для получения более подробной информации.

Это увеличение трафика может легко превысить возможности ваших коммутаторов, если они не будут соответствовать стандартам, описанным в Матрица совместимости систем хранения данных Dell (см. стр.19)

Вы также можете прочитать лучшие практики технический документ для VMware и Equallogic, чтобы убедиться, что ваша конфигурация не является причиной проблем.

Некоторые вопросы:

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

   К сожалению, у меня нет активной гарантии ни на один из массивов.

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

   Хотя у меня есть штаб-квартира SAN ... не могли бы вы рассказать, на что мне следует обратить внимание, чтобы это исправить?

Легче всего проверить это в «экспериментальном анализе», который дает вам график вашей рабочей нагрузки по сравнению с «расчетным максимальным IOPS». Вы можете просмотреть это как для всей группы, так и для отдельных участников. Вы также можете увидеть количество операций ввода-вывода в секунду для отдельных шпинделей и глубину очереди в разделе оборудования, хотя по одним только этим числам может быть сложно определить, перегружены ли шпиндели.

3. Сколько членов / массивов у вас сейчас в одном пуле?

   Сейчас в одном пуле 5 массивов

Я настоятельно рекомендую вам рассмотреть возможность разделения их на два пула, в которых не более 3 участников. Том распределяется между 3 участниками только тогда, когда он не находится в процессе перебалансировки емкости другому участнику (что часто происходит на томах со снимками, постоянно меняющими используемое пространство). Сокращение количества участников до 3-х участников остановит большое количество «оттока» из-за перебалансировки целых срезов между участниками в бесконечной погоне после получения максимально равной емкости между участниками.

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

Разница в производительности между VMDK и iSCSI на уровне блоков зависит от типа рабочей нагрузки и может сильно отличаться от приложения к приложению. Я настоятельно рекомендую вам выполнить тест, например, запустить некоторые из ваших приложений на обоих типах протокола доступа к хранилищу, и посмотреть, как он себя ведет. Поскольку VMDK является дополнительным слоем между приложением и хранилищем, он может работать медленнее, если хост, управляющий виртуальным диском, сильно загружен.

Вы, вероятно, сократите свое "время кеширования" при совместном использовании дисков

Представьте, что у вас есть два приложения «А» и «Б»:

• Приложение «A» имеет небольшую базу данных размером всего 40 ГБ, загружает 1 ГБ в день, и в большинстве запросов используются данные за последние дни недели. На сервере с 20 ГБ ОЗУ, выделенным для дискового кеша, вероятно, в дисковом кэше будут храниться данные за 20 дней, и большинство операций чтения не приведет к перемещению головки диска.

• Приложение «B», с другой стороны, представляет собой средний архив с 2000 ГБ, загружает 20 ГБ данных каждый день, и большинство запросов читают все это последовательно. Это архив, и в основном он выполняет текстовые запросы, которые сложно индексировать, а последовательное чтение в любом случае происходит в течение дня, чего достаточно для пользователей приложения. Как и многие архивы, он используется только аудиториями, которым не нужны более быстрые ответы.

• Если вы соедините диски этих двух серверов в одном хранилище с использованием одного и того же кеша 64 ГБ, приложения «A» и «B» будут перемещать 21 ГБ данных в день. Тогда в кеше будет храниться не более 3 дней данных. До слияния приложение «А» выполняло большую часть своих запросов в ОЗУ, теперь большинству из них требуется физическое чтение с диска. До слияния приложение «B» имело небольшой параллелизм с приложением «A» при доступе к диску, теперь он имеет много параллелизма.

Есть идея?

Сегментирование кэшей диска очень важно для производительности, поскольку скорость ОЗУ в 4–4 миллиона раз выше, чем у дисков с произвольным доступом 15 КБ. Диски должны перемещать головку, чтобы получить данные, ОЗУ - нет. Диски 15k RPM - пустая трата денег. Они примерно в 2 раза быстрее обычных дисков SATA для произвольного доступа и стоят более чем в 2 раза дороже дисков SATA.

О ВМДК

Мои серверы слишком велики, и в прошлом у нас были проблемы с большими виртуальными машинами (например, 700 ГБ ОЗУ) на VMWare. У нас также были серьезные проблемы с производительностью и необъяснимые сбои. По этой причине мы перешли на KVM. В то время я не был менеджером сервера виртуализации, поэтому не могу сказать, что было не так с нашим VMWare. Но с тех пор, как мы перешли на KVM и я стал менеджером сервера виртуализации, у нас больше нет проблем.

У меня есть несколько изображений vm на физических устройствах (пересылка SCSI) и некоторые изображения в виде файлов изображений .img (аналогично VMDK с фиксированным размером). Люди в Интернете говорят, что пересылка SCSI намного быстрее, но для моих схем использования производительность такая же. Если есть разница, то я ее не заметил. Единственное, что при создании новой виртуальной машины мы должны указать KVM не кэшировать доступ к диску в операционной системе хоста. Не знаю, есть ли у VMWare подобный вариант.

Мои пожелания вам

1. Изменить стратегию хранения

Торговля хранилищами внутренними дисками. 24 внутренних диска SATA позволяют создать большой рейд 10, который будет намного дешевле и быстрее, чем большинство хранилищ. Кроме того, у вас будет дополнительное преимущество: при меньших затратах у вас будет избыток дискового пространства на тех серверах, которые можно использовать для задач перекрестного резервного копирования и обслуживания.

Но не раскрывает это лишнее пространство вашим пользователям. Держись при себе. А то бэкапы делать будет ад.

Используйте хранилища для вещей, для которых они предназначены:

• Централизованное резервное копирование;
• База данных / архивы, которые слишком велики для размещения на внутренних дисках;
• База данных / архивы, шаблоны использования которых не ускоряются за счет дисковых кешей, и количество головок дисков, необходимых для производительности, не помещается на внутренних дисках или в выделенном хранилище.

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

2. По возможности переместите оперативную память из кеша хранилища на реальные серверы.

Предполагая, что у вас будет такой же объем кеш-памяти в хранилищах после объединения, у вас может быть достаточно оперативной памяти. Попробуйте переместить оперативную память из кеша хранилища на реальные серверы в той пропорции, которая была у вас раньше. Это если чипы RAM совместимы. Это может помочь.

3. Отсутствие RAID 6 для критически важных баз данных

Рейды 5 и 6 являются худшими для производительности базы данных. Перейти к Raid 10. Raid 10 удваивает скорость чтения, потому что у вас есть две независимые копии каждого сектора, которые можно читать независимо.

4. Переместите журнал базы данных на специальный внутренний диск.

Я использую postgres, и перенос журнала упреждающей записи на выделенный диск имеет большое значение. Дело в том, что большинство современных серверов баз данных записывают информацию в журнал до записи информации в самой области данных базы данных. Журнал обычно представляет собой кольцевой буфер, и все записи выполняются последовательно. Если у вас есть выделенный физический диск, головка всегда будет на месте для записи, почти не будет времени на поиск, даже если это диск с малой скоростью вращения. Как я читал в Интернете, Mysql использует тот же дизайн.