Любопытную, и, честно говоря, даже неожиданную для меня тему исследовал блоггер NetApp Lobanov.
Следящие за темой уже знают, что в Hyper-V 3.0 Microsoft объявила, что будет поддерживать работу по NAS протоколу SMBv2.2.
Вы помните, что VMware уже с версии 3.0 активно рекомендует использовать NAS для подключения датасторов виртуальных машин по файловому протоколу NFS, и пользуется при этом большими преимуществами такого варианта перед “классическим” блочным FC и iSCSI, о чем я уже не раз писал в этом блоге. Однако у Microsoft в ее Hyper-V не было такой возможность в штатном, поддерживаемом порядке, впрочем и пользователи, скорее всего, не особо это требовали. Отчасти это было связано с широко распространенным убеждением, что NAS-протоколы, и уж CIFS/SMB в особенности, вообще не пригодны для производительных применений. ?? если в отношении NFS в VMware эти заблуждения уже более-менее развеяны многочисленными результатами тестов, как NetApp и EMC, так и самой VMware, да и сотнями и тысячами практических реализаций разного масштаба, то в отношении CIFS по прежнему бытует стойкое убеждение в непригодности его ни для чего, кроме “домашних папок” и копирования файлов по сети.
Отчасти это действительно так. CIFS как протокол сетевой файловой системы, значительно сложнее устроен, чем NFS, обладает множеством хитрых возможностей, и, как следствие, заметно большей величиной “оверхеда”, накладных расходов. Кроме того, CIFS (или SMB 1.0) никогда и не ориентировался на такое применение.
Однако первым шагом в сторону переработки и устранения старых родовых болячек NetBIOS и LAN Manager, от которого ведет свою родословную CIFS, был сделан в SMB v2.0, в котором Microsoft показала, что она знает о проблемах, и приняла решение их устранить. С тех пор CIFS/SMB развивается, не слишком шумно, но довольно существенно, а как видимый результат – появление поддержки новой версии, SMB v2.2 в качестве поддерживаемого протокола доступа к датасторам в новой версии Hyper-V.
Однако, пока Windows 8, Hyper-V 3.0 и SMB 2.2 не вышли в релиз, что же может показать в плане производительности обычный SMB2.0, появившийся в Windows Server 2008, и поддерживаемый в Data ONTAP?
Posted by lobanov on Sep 29, 2011 10:06:19 AM
В свете грядущих новостей о поддержке в Hyper-V работы по SMB через версию SMB 2.2, у нас скоро появится новая возможность работать с виртуальными машинами через IP сеть. До сих пор существовала только одна такая возможность, подключая LUN по iSCSI. Очеивдный вопрос, вертящийся у всех на языке, как будут обстоять дела в варианте с SMB с точки зрения эффективности использования системы хранения, управления, и, самое главное, с точки зрения производительности. Для того, чтобы разобраться во всем этом, мы решили провести эксперимент, сравнив эти два варианта подключения, использовав оборудование нашей тестовой лаборатории.
Для теста использовался один сервер в следующей конфигурации:
- 16 CPU (Dual Socket Quad Core with HyperThreading)
- 48 GB RAM
- Один 1Gbs Ethernet NIC
- Win2K8R2 SP1
Один контроллер NetApp FAS6030 под Data ONTAP 8.0.1 работает на один сетевой адаптер Ethernet 1Gbs, на контроллере создано два тома flexvol:
- “HVoverSMB_CIFS” это CIFS share, смонтированная на хост Hyper-V как symbolic link.
- “HVoverSMB_ISCSI” несет один LUN, подключенный к хосту Hyper-V по протоколу iSCSI.
Оба тома имеют размер 1TB в режиме Thin-Provisioned, и LUN на томе для iSCSI также сделан Thin-Provisioned. Таким образом, со стороны хоста Hyper-V мы видим 2TB usable storage, в то время, как на стороне контроллера пространство на дисках почти не занято. Мы решили не использовать 10G Ethernet, так как хотели замедлить, для наглядности, время загрузки, и максимально нагрузить сеть в процессе эксперимента.
Мы создали 20 VM на iSCSI LUN, и 20 VM на CIFS Share. Каждая виртуальная машина имела следующую конфигурацию:
- 1 CPU
- 2 GB RAM
- Win2K8R2 SP1
- 40GB VHD
Оригинальный эталонный шаблон VM был создан с использованием нашей новой техники Thick/Thin VHD , о которой я рассказывал ранее, а последующие копии с этого шаблона созданы с использованием Sub-Lun cloning, и файлового SIS cloning vпри помощи cmdлетов Start-NaClone, и Copy-NaHostFile. ??тоговый результат 40 VM, и 1.6TB дисков виртуальных машин занимают менее 16GB на контроллере!
Затем мы подвергли получившуюся систему испытанием старым добрым Boot Storm – одновременной загрузкой 20 виртуальных машин каждого типа, и сбором данных о производительности как на хосте Hyper-V, так и на контроллере NetApp. Мы собирали данные производительности Hyper-V при помощи Performance Monitor, обращая внимание, в первую очередь, на CPU и призводительность сетевого адаптера. Контроллер NetApp мониторился с помощью Get-NaSysStat PowerShell Script. Оба инструмента был настроены на сбор данных каждые 5 секунд.
Результаты
Время загрузки
В обоих тестах загрузка до экрана Logon заняла менее 90 секунд для всех 20 виртуальных машин. Давайте посмотрим, что в это время происходило на хостах Hyper-V и контроллере NetApp.
Hyper-V-Host Performance
CPU load
Network Adapter: BytesReceived/sec
NetApp Array Performance
Net_Data_Sent
CPU_Busy
CIFS vs. iSCSI Ops/sec
Как вы видите, как со стороны хоста Hyper-V, так и со стороны контроллера NetApp, уровни загрузки CPU, а также производительность сети оказались сравнимыми! Важно отметить, что, в данном случае, мы еще даже не используем SMB2.2, так как работает Server 2008 R2 SP1, а не Server.Next. Если же мы видим равную производительность для текущего поколения софта, запущенного на оборудовании четырехлетней давности, то что же мы получим, когда появится Server.Next?
Но где же вообще разница между протоколами, спросите вы, а что там с latency?
Давайте посмотрим, вот картина на стороне NetApp:
Неожиданно, не правда-ли?
На первый взгляд, все неплохо, исключая взлет latency до 4ms в самый “разгар шторма”. Но посмотрите на параметр read latency для теста CIFS. Почему он показывает меньшую latency на идентичной нагрузке? То что мы видим, это преимущества протокола SMB 2.x; Windows использует собственный кэш NTFS для улучшения производительности на чтение, просто посылая на систему хранения меньше избыточных запросов чтения.
Величина эффективности использования пространства хранения на NetApp
??спользуя thin-provisioning, single copy rapid provisioning, и дедупликацию, мы получили фантастически высокие результаты для обоих протоколов.
| ??мя |
Общий размер |
??спользовано |
Доступно |
Дедупликация |
Aggregate |
| HVoverSMB_CIFS |
1024.0 GB |
1% |
1015.9 GB |
да |
aggr0 |
| HVoverSMB_ISCSI |
1024.0 GB |
1% |
1013.7 GB |
да |
aggr0 |
Как вы видите, в обоих случаях величина эффективности использования хранилища сравнима и высока.
Так как мы увидели, что производительность и уровень использования системы хранения примерно одинаков, давайте посмотрим на остальные критерии и попытаемся ответить на вопрос, что же лучше.
CIFS
За:
- Одна сетевая папка CIFS на любое число хостов Hyper-V или кластеров Clusters.
- Перемещение VM между хостами Hyper-V становится гораздо проще, так как все хосты имеют доступ к одним и тем же VHD.
- Значительно более высокий уровень плотности VM на том.
Против:
- Конфигурирование прав на CIFS share несколько сложновато, так как требует разобраться со специфическими разрешениями на Share и NTFS, которые требуются для Hyper-V.
- В настоящий момент не поддерживается.
iSCSI
За:
- Конфигурирование прав NTFS очевидно.
- Поддерживается.
- Равная производительность с FCP без необходимости сложного зонирования.
Против:
- К LUN-ам не может быть совместного доступа от нескольких хостов и кластеров, без использования WSFC, и CSV.
- Перемещение VHD на другой хост Hyper-V требует переконфигурирования системы хранения или копирования файлов VHD по сети.
Выводы
Результаты теста и их анализ показывают, что сегодня SMB2.0 и iSCSI сравнимы. Оба варианта подключения обеспечивают достаточную эффективность и позволяют работу виртуальных машин по IP-сети. Мы ожидаем, что большинство сложностей с правами и разрешениями будет устранена в Server.Next. Факт неподдерживаемости SMB конечно делает iSCSI однозначным победителем, но, если быть честными, если SMB начнет поддерживаться… следует отдать должное прогрессу в работе SMB. В итоге, мы уже с нетерпением ждем выхода Server.Next, SMB2.2, и Hyper-V 3.0 over SMB, это должно оказаться весьма неплохо!
