У меня есть совершенно новый блок 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. Что я сделал, чтобы обойти это на данный момент, так это изменил двойную конфигурацию на одну конфигурацию. Таким образом, я могу использовать обратную запись, которая работает намного лучше.
Чтобы увидеть разницу в производительности, проверьте этот / мой поток по адресу: 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) второй отключенный контроллер может быть установлен как отключенный и требует ручного вмешательства для активации в случае отказа основного активного контроллера. Полезность этого в примечаниях к патчу не особо подробно описывается, но это «исправление» предназначено для того, чтобы позволить людям включить обратную запись и избавиться от ужасной производительности, которая наблюдается при использовании обоих контроллеров в сквозной записи.
Автоматическая отработка отказа (холодная отработка отказа, вызывающая отключение) - это функция, которая будет выпущена позже. Гораздо позже будет фактическое «активное / активное» обновление прошивки, которое позволит «живое» аварийное переключение без простоев.
Шаги:
Это позволит вам установить второй PERC8 в VRTX на случай, если другой выйдет из строя. Но вам придется вручную вмешаться, чтобы переключиться в случае сбоя. Я полагаю, что это в первую очередь предназначено для труднодоступных мест (удаленные офисы без ИТ-персонала или легкий доступ для технических специалистов службы поддержки Dell). Это то, для чего мы его используем.
Надеюсь, к концу года у нас будет функция автоматического переключения при отказе, а затем в течение следующего года настоящая активная / активная конфигурация с включенной обратной записью (синхронизированные кеши). Я не собираюсь задерживать дыхание ради исправления прошивки синхронизированного кеша ... Я подозреваю, что это будет нелегко для Dell.