Proftpd правило ограничения подключений пользователем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поняли?

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

О VMDK

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

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

Мои предложения

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

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

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

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

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

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

2. Если возможно, переместите RAM из кэша хранилища на реальные серверы

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

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

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

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

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