Назад | Перейти на главную страницу

Dell VRTX - медленное общее хранилище кластера

У меня есть совершенно новый блок Dell VRTX, настроенный как отказоустойчивый кластер с виртуальными машинами HA Hyper-V. Это мой первый раз, когда я настраиваю кластеризацию, и мой первый раз с одним из этих блоков, поэтому я уверен, что что-то упустил.

Виртуальные машины испытывают большую задержку диска и низкую производительность при доступе к своим файлам VHD (x), расположенным на общем томе кластера.

VRTX имеет 10 жестких дисков SAS по 900 ГБ 10K в конфигурации RAID 6, а VRTX имеет резервные контроллеры Shared PERC 8. Оба блейда имеют полный доступ к виртуальным дискам. Установлено два блейд-сервера M520, каждый с ОЗУ 128 ГБ. MPIO настроен для контроллеров PERC 8. Операционная система на блейд-серверах - Server 2012 (НЕ R2).

Массив RAID 6 разделен на небольшой (8 ГБ) том для кворума-свидетеля кластера и большой (6,5 ТБ) том для общего тома кластера (установленный на узлах как C: \ ClusterStorage \ Volume1)

Пример медленного доступа к диску: вход в виртуальную машину Server 2012 и автоматический запуск диспетчера сервера. Доступ к диску достигает 100%, со скоростью записи около 20 МБ, скоростью чтения около 500 КБ и средним временем отклика более 1000 мс, иногда с пиками до 4000-5000 мс или около того. Меня действительно беспокоит задержка.

Есть ли что-то конкретное, на что я должен обратить внимание в своей конфигурации? Кажется, не имеет значения, использую ли я VHD или VHDX, динамический или статический.

это:

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

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

Я испытал точно такую ​​же проблему производительности с VRTX с Dual SPERC8. Что я сделал, чтобы обойти это на данный момент, так это изменил двойную конфигурацию на одну конфигурацию. Таким образом, я могу использовать обратную запись, которая работает намного лучше.

  • Точные шаги:
    • Снимаем второй контроллер SPERC 8.
    • Снимаем второй расширитель
    • Подключите внутренние соединения SAS заново.
    • Понижение версии шасси до 1.25 (работает так же, как и обновление, никаких специальных действий не требуется)
    • Удалите все виртуальные диски (резервные данные / виртуальные машины при необходимости)
    • Выключите и выключите весь VRTX (для уверенности отсоедините и снова подсоедините силовые кабели)
    • создать VD с включенной обратной записью

Чтобы увидеть разницу в производительности, проверьте этот / мой поток по адресу: http://en.community.dell.com/support-forums/servers/f/906/t/19587459.aspx

Обновить:
Результаты теста:
Двойной PERC / RAID6 / сквозная запись: чтение 2500 МБ / с, запись 200 МБ / с
Двойной PERC / RAID10 / сквозная запись: чтение 2500 МБ / с, запись 400 МБ / с
Один PERC / RAID6 / Обратная запись: чтение 2500 МБ / с Запись 2700 МБ / с

Пока Dual PERC привязан к политике сквозной записи, я бы придерживался настройки Single PERC

Больше не требуется удалять второй контроллер SPERC, чтобы иметь возможность использовать обратную запись вместо сквозной записи, как описано в сообщении Эрика. Теперь вы можете отключить второй контроллер PERC8 с CMC. В текущей прошивке (1.35) второй отключенный контроллер может быть установлен как отключенный и требует ручного вмешательства для активации в случае отказа основного активного контроллера. Полезность этого в примечаниях к патчу не особо подробно описывается, но это «исправление» предназначено для того, чтобы позволить людям включить обратную запись и избавиться от ужасной производительности, которая наблюдается при использовании обоих контроллеров в сквозной записи.

Автоматическая отработка отказа (холодная отработка отказа, вызывающая отключение) - это функция, которая будет выпущена позже. Гораздо позже будет фактическое «активное / активное» обновление прошивки, которое позволит «живое» аварийное переключение без простоев.

Шаги:

  1. Загрузите прошивку VRTX CMC версии 1.35 или выше.
  2. Выключите все свои лезвия.
  3. В интерфейсе CMC нажмите «Обзор шасси> Обновить».
  4. Установите оба флажка для контроллеров CMC в заголовке «Прошивка CMC» и нажмите «Применить обновление CMC».
  5. Введите расположение файла микропрограммы CMC и примените его.
  6. CMC покажет вам прогресс. Загрузка занимает около 8 минут, после применения обновления еще несколько минут. CMC перезагрузятся после применения обновления, и вы будете исключены из веб-интерфейса.
  7. После перезагрузки CMC перейдите в раздел «Хранение> Контроллеры> Устранение неполадок».
  8. Для выбранного вами SPERC выберите параметр «Отключить контроллер RAID» и примените его. Это перезагрузит ваш компонент хранилища.
  9. После перезагрузки перейдите в «Хранилище> Виртуальные диски> Управление», выберите «Изменить: политика записи» и выберите «Обратная запись» вместо «Сквозная запись» для всех ваших виртуальных дисков (если у вас нет причин не делать этого).
  10. Вышеупомянутое изменение будет выполнено немедленно, но все же рекомендуется выполнить сброс CMC еще раз в разделе «Обзор шасси> Питание> Управление» с помощью «Сбросить CMC (горячая перезагрузка)».
  11. Загрузите выключенные лезвия.

Это позволит вам установить второй PERC8 в VRTX на случай, если другой выйдет из строя. Но вам придется вручную вмешаться, чтобы переключиться в случае сбоя. Я полагаю, что это в первую очередь предназначено для труднодоступных мест (удаленные офисы без ИТ-персонала или легкий доступ для технических специалистов службы поддержки Dell). Это то, для чего мы его используем.

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