about NetApp

Для начала терминологическое вступление. Вокруг файлового протокола Microsoft довольно много путаницы, начнем с ее распутывания.

• SMB – “Server Message Block” – первоначальная версия протокола, разработанная еще во времена MS LAN manager 1.0(почти уже никто не застал те времена, и не помнит что это, совсем каменный век IT, середина 80-х). Некоторый отголосок этой аббревиатуры остался в названии опенсорсного продукта SAMBA, реализации файлового протокола SMB путем его реверс-инжиниринга.
• CIFS – (он же SMB-“просто” или SMB 1.0) – “Common Internet File System” – название CIFS появилось, когда Microsoft в 1996 году начала процесс стандартизации уже существовавшего протокола, в качестве RFC в IETF. Процесс стандартизации этот застопорился где-то на начальном этапе, и MS решила не продолжать его, остановившись на проведении в RFC первой версии драфта (сегодня его статус уже expired). Тем не менее название CIFS в индустрии закрепилось, и постепенно почти вытеснило SMB.
• SMB 2.0 – протокол, появившийся в Windows Server 2008, Vista, и поддерживающийся в более поздних OS. Microsoft осознала в какой-то момент, что файловый протокол, разработанный в середине 80-х, пусть и весьма совершенный на тот момент, и имеющий возможности постепенного расширения и добавления возможностей на уровне протокола, страшно отстал от современности (ситуация как примерно с Internet Explorer), страдает рядом существенных проблем, которые стали более заметны с годами. ?? вот в компании дошли руки до начала глубокой модернизации протокола SMB. Обратите внимание, что SMB 2.0 уже некорректно называть “CIFS”. CIFS это только SMB 1.0, поэтому постепенно название CIFS будет уходить. Я, в свою очередь, в этом блоге также буду постепенно избавляться от термина “CIFS”. Если мы говорим о новых версиях файлового протокола Microsoft, то мы будем называть его SMB (v2.0, v2.1, v2.2 AKA v3.0). В SMB 2.0 (и последующих его модификациях: 2.1, 2.2) были улучшены многие насущно важные аспекты, мешавшие SMB 1.0. Протокол был значительно упрощен, и, вместе с тем, улучшен. Появилась возможность кэширования и объединения нескольких команд в одну “цепочку”. Улучшилась работа по “длинным” сетям с большими уровнями задержек, что позволили использовать SMB 2.0 даже в географически распределенных локальных сетях, соединенных через WAN и VPN. Улучшилась реакция на кратковременные дисконнекты сети и масштабируемость.
  Но работы в группе разработки SMB не стояли на месте, и к выходу Server 2012 была готова новая, еще более глубоко переработанная версия:
• SMB 3.0 – это самая новая на сегодня версия файлового протокола Microsoft, с которым компания готова побороться с некоторым вынужденным засилием NFS в файловых системах хранения (NAS). В ее разработке MS буквально скакнула через несколько ступенек, и подготовила крайне интересный и современный продукт, с множеством новинок и хорошим заделом на будущее. Продолжая развитие SMB 2.0, в Microsoft еще более значительно улучшили производительность работы протокола, реализовали такие интересные вещи, как SMBDirect, с использованием RDMA Transport Protocol (Remote DMA, технология, используемая в высокоскоростых сетях, таких как 10G Ethernet и Infiniband) и поддержку многоканального режима, возможность использовать Remote VSS, BranchCache v2, Transparent Failover, шифрования. Немалую роль в популяризации и распространении SMB 3.0 должен сыграть и MS Hyper-V, впервые поддерживающий в его лице файловые протоколы для подключения стораджа.

Официально о поддержке, кроме самой Microsoft, уже заявили EMC и NetApp, два крупнейших игрока рынка NAS, а также поддержка SMB 3.0 появится и в открытом проекте SAMBA. Есть надежда, что к этим игрокам, после выхода Server 2012 подтянутся и остальные, уж больно много полезного появилось в новом SMB.

Так, например, SMB 3.0 явственно нацелился не только на традиционный для SMB 1.0/CIFS/SMB 2.0 сегмент канала связи от сервера до конечной клиентской машины, но и на межсерверный коннект (как бы ни звучало это дико и невообразимо для Old Skool: “Между серверами по бэкбону гонять данные? MS SQL? Exchange? По CIFS SMB? Да вы шутите!”). Для этого в нем появились средства SMBDirect и multichannel, позволяющие полноценно использовать производительные возможности вплоть до все еще невообразимого многими 40G Ethernet. Например можно объединить на уровне протокола (а не EtherChannel) в мультилинковый “транк” четыре 10G-линка. А использование RDMA (наиболее известным пользователем технологий RDMA является протокол Infiniband, славящийся своей низкой латентностью) и iWARP (я рассказывал о них в давней заметке в этом блоге) позволит даже выйти по уровню латентности и полосе пропускания для файлового протокола на уровень FC, при этом сохранив все преимущества файлового, а не тупого блочного протокола.

SMB 2.0 поддерживается в системах NetApp уже довольно давно, и требует просто включения соответствующей опции в конфигурации (> options cifs.smb2.enable on и > options cifs.smb2.client.enable on), так что если вы используете в своей сети клиентов не ниже Windows Vista/7, и сервера не ниже Server 2008, то есть смысл включить на сторадже эти опции и перейти целиком на версию протокола SMB 2.0, вы можете получить довольно заметный прирост в производительности.

Поддержка SMB 3.0 в NetApp появится в версии Data ONTAP 8.2, планируемой к выпуску в RC осенью этого года.

Любопытную, и, честно говоря, даже неожиданную для меня тему исследовал блоггер 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?

Looking ahead Hyper-V over SMB vs. iSCSI

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, это должно оказаться весьма неплохо!