Hyper-V и производительность. Часть 8 — Копирование файлов на диск CSV. Используйте узел координатор!


Продолжая цикл заметок о производительности Hyper-V, сегодня мы поговорим об операции копирования на диски, использующие новую технологию Cluster Shared Volumes (CSV). На самом деле, эта заметка никак не касается самого Hyper-V, работы или производительности уже существующих виртуальных машин, а затрагивает лишь производительность операции копирования файлов на том CSV.


После того, как вы создали кластер из нескольких узлов и настроили общие диски на использование CSV, настало время создавать виртуальные машины. Часто процесс заключается не только в создании новых виртуальных машин, но и в копировании существующих или создании их из готовых шаблонов — что также подразумевает копирование шаблона из Библиотеки. На какой же узел следует копировать файлы виртуальных дисков, где нужно создавать виртуальные машины по шаблонам из Библиотеки? Удобным нововведением CSV является доступность общего диска одновременно со всех узлов кластера. Вы можете выполнить операцию копирования файла с сетевого ресурса в каталог «C:\ClusterStorage\Volume1» на любом из узлов. Но будет ли время копирования одинаковым на всех узлах? Рассмотрим задачу на практике, а после поговорим о теории.


В моём примере имеется кластер из двух одинаковых узлов с разделяемым дисковым хранилищем. Чтобы не упираться в производительность копирования по сети, я скопирую тестовый файл виртуального диска на локальных системный диск каждого из узлов. Размер этого файла равен 6.4 ГБ. Я буду копировать этот файл на общих кластерный ресурс CSV по очереди на обоих узлах, задав результируемому файлу имя, содержащее номер узла, измеряя время копирования и отслеживая счетчики производительности в Performance Monitor.


На первом узле процесс копирования занял 155 секунд.



На втором узле тот же процесс занял уже 196 секунд — более, чем на четверть больше!



Я «локально» копирую одинаковый файл на двух узлах на общий диск, но результат на втором узле заметно хуже, чем на первом! В чём же разница?


Дело в том, что первый узел является координатором или владельцем данного тома CSV — так что все операции записи для него действительно локальны. Тогда как второй узел владельцем CSV не является, и на самом деле операции записи в новый файл перенаправляются по сети!


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


Посмотрим, как выглядел процесс копирования с точки зрения счетчиков производительности в Performance Monitor.


Заметим, что на первом узле все записи, расширяющие файл (а только так работает операция file copy), являются локальными, — это линия красного цвета, а перенаправленных записей нет вообще.



Для второго узла картина обратная. Все записи на том CSV являются перенаправленными — это линия зелёного цвета — тогда как локальных операций записи нет вообще (их и не может быть во время копирования нового файла на том CSV).



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


Как же понять, какой узел является координатором того или иного тома CSV? Это можно увидеть в консоли Failover Cluster Manager.



Если вы предпочитаете работать из командной строки (например, на Hyper-V Server 2008 R2), вы можете воспользоваться следующим коммандлетом Powershell: Get-ClusterSharedVolume.


Comments (6)

  1. Алексей, немного не тот сценарий. Я в курсе, что, CSV предназначен только для храниния файлов ВМ. Предполагалось, что есть некластеризованная ВМ. Через консоль Hyper-V делается экспорт, экспортированные файлы копируются на общий том, и уже с координатора выполняется импорт.

  2. Alex A says:

    Смотри выше )

  3. Исходя из этой же логики, поэтому рекомендуется при экспорте ВМ на CSV выполнять операцию импорта с хоста-координатора?

  4. Alex A says:

    Копировать руками на общий том CSV нельзя.

    Копируйте на локальный диск координатора и импортируйте, или прямо со Stand Alone узла запустите консоль Hyper-V, соединитесь с узлом-координатором и импортируйте.

     Очевидно, что наиболее правильным было бы использовать SCVMM для переноса ВМ с stand-alone узла на кластер. Он бы сделал всё быстро (BITS) и поддерживаемым способом.

  5. Alex A says:

    Не очень понял вопроса.

    Импорт быстрее делать на координаторе - во время импорта пишутся файлы на CSV.

    Экспорт вы делаете "с CSV", а не "на CSV", так что на каком узле это запускать неважно.

    P.S. Мы обсуждали, что на CSV допустимо размещать ТОЛЬКО кластеризованные виртуальные машины. За координацию доступа к файловой системе отвечает Cluster API. Экспорта из консоли Hyper-V "на CSV" я бы категорически не рекомендовал делать. Мало того, что это не поддерживается, но вы можете повредить целостности файловой системы,записывая в те блоки, которые координатор уже использует для своих задачю

  6. Т.е. импорт быстрее и правильнее делать на хосте-координаторе, верно?

Skip to main content