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

Производительность копирования файла общего тома кластера из SAN

Я надеюсь, что кто-нибудь поможет мне решить странную проблему.

Мы используем отказоустойчивый кластер Microsoft с сервером 2008 R2 и Equallogic PS4000 SAN. Наша основная конфигурация состоит из 2 серверов Dell Poweredge T710 в кластере. У нас есть CSV и Quorm. Каждый сервер имеет 10 сетевых карт Broadcom 1 Гбит / с. Прямо сейчас 4 NICS подключены к сети iSCSI для доступа к SAN. Они используют MPIO и пакет Dell HIT.

У нас есть 5 виртуальных машин, работающих на каждом узле, и все работает без сбоев. Никаких заметных проблем с производительностью или чего-либо еще. В сети SAN я вижу 4 подключения iSCSI от каждого сервера к каждому тому (CSV и Quorm). Опять же, похоже, он отлично работает.

Проблема, с которой я столкнулся, связана с резервными копиями. Я пробовал несколько программ резервного копирования, например, Backupchain и Veeam. Проблема в том, что они оба очень-очень медленно создают резервные копии виртуальных машин. Например, у меня есть виртуальный жесткий диск объемом 500 ГБ (фиксированный диск), работающий в кластере. Резервное копирование этого виртуального жесткого диска занимает более 18 часов, и это с отключенными сжатием и депапированием, которое должно быть быстрым.

У нас также есть отдельный сервер, предназначенный только для резервного копирования. Он имеет много направленных подключенных хранилищ. В рамках устранения неполадок я решил включить этот сервер в кластер в качестве узла. Теперь у него есть доступ к CSV и он может читать из C: \ clusterstorage \ volume1, где находятся наши VHD. Этот резервный сервер имеет только 2 сетевых карты. 1 сетевая карта подключается к сети iSCSI, а другая - только к основной сети. В нем есть Intel NICS без какого-либо MPIO или объединения.

Итак, с третьим сервером в кластере я начал проводить тесты. У меня есть тестовый виртуальный жесткий диск размером около 7 ГБ, который хранится в CSV. Я протестировал копирование файлов этого VHD со всех трех серверов в направленное подключенное хранилище на соответствующем сервере. 2 сервера Dell, которые являются основными узлами в кластере (на них размещены виртуальные машины), читают этот файл со скоростью около 20 Мбит / с. Что при такой скорости замедляет резервное копирование. Другой сервер, у которого есть только 1 сетевая карта к SAN, читает со скоростью около 100 Мбит / с.

Сегодня я провел несколько часов по телефону с Dell по этому поводу. Мы прошли через всевозможные тесты, и он оказался довольно тупым. Он действительно не понимает, почему этот сервер только с 1 сетевой картой читает примерно в 5 раз быстрее, чем серверы с 4 сетевыми адаптерами и MPIO.

Мы изучили использование сетевых адаптеров в сети во время копирования файла. Серверы с 4 сетевыми адаптерами немного увеличили активность во время копирования файлов, но она увеличилась только до 8-10% на всех 4 сетевых адаптерах. Другой сервер с 1 сетевой картой подскочил более чем на 80% во время копирования файла.

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

У кого-нибудь есть мнение по этому поводу? Любая обратная связь будет принята с благодарностью.

Заранее спасибо.

Судя по предоставленной вами информации, процесс резервного копирования помещает CSV в Перенаправленный доступ Режим. Возможно, ваше программное обеспечение резервного копирования не поддерживает CSV и пытается получить доступ к файлам VHD через сервер, который не владеет ресурсами.

Вы сможете убедиться в этом, просмотрев CSV в диспетчере отказоустойчивого кластера в разделе «Хранилище».

Если это так, я бы связался с Veeam, чтобы узнать, как они рекомендуют выполнять кластерное резервное копирование Hyper-V.

Более подробная информация о перенаправленном доступе доступна здесь: http://blogs.technet.com/b/askcore/archive/2010/12/16/troubleshooting-redirected-access-on-a-cluster-shared-volume-csv.aspx

Для меня это звучит как неправильно настроенная установка MPIO. Невозможно точно определить проблему, не проводя часы на своем сайте, но вот несколько советов, на которые стоит обратить внимание:

  • Как Equallogic настроен для представления LUN (ов)? Он активен / пассивен или активен / активен? Он использует ALUA? Если это не ALUA, то вы, возможно, столкнетесь с перебоями путей, из-за которых SAN оказывается на коленях во время интенсивного ввода-вывода.
  • Вы используете jumbo-кадры? Если да (или если вы не знаете) - проверьте SAN, коммутатор (и) и ник (ы) на ВСЕХ устройствах, чтобы убедиться, что настройка MTU везде одинакова.

Каждый уважаемый поставщик SAN предлагает лучшие практики для различных сценариев использования. Вы сможете найти его для MPIO в Windows с iSCSI.