Posts tagged ‘cifs’

Как переименовать CIFS/SMB-share

Как ни удивительно прозвучит, но в Data ONTAP нет средства переименовать созданную сетевую NAS-шару. Но зато есть возможность задать одному тому более одного имени шары. Таким образом можно сделать (не)хитрый финт: вместо переименования шары, задаем ей новое имя, а старое – удаляем. Это можно сделать руками, если у вас этих шар немного. Но когда их сотни и тысячи, то хочется завести уже какой-то инструмент. ?? вот недавно я в communities.netapp нашел скрипт на Perl, который делает именно это.

#!/usr/bin/perl -w
##########################################################
# cifs_share_rename
# rename a netapp cifs share
#Michael.S.Denney@gmail.com
$version=1.0;
##########################################################
#TO DO:
use strict;
use warnings;
use Getopt::Long;
use POSIX;
##################Global VARS#################################
use vars qw($version $verbose $debug $filer $share $new_share);
##################Predeclare SUBS#############################
use subs qw(run_cmd);
##############################################################
GetOptions(
          'f=s' => \$filer,
          'filer=s' => \$filer,
          's=s' => \$share,
          'share=s' => \$share,
          'n=s' => \$new_share,
          'new_share=s' => \$new_share,
          'v' => \$verbose,
          'd' => \$debug
);
my $t=' ';
print "verbose on\n" if $verbose;
print "debug on\n" if $debug;
$verbose=1 if $debug;
unless ($filer and $share and $new_share) {
   print "Usage: cifs_share_rename -f  -s  -n \n";
   print "Usage: cifs_share_rename --filer  --share  --new_share \n";
   exit 1 ;
}

my $cmd="ssh $filer cifs shares $share";
print "$cmd\n";
my ($stdout,$stderr)=run_cmd $cmd;
if (@$stderr){
    print "$_\n" foreach (@$stderr);
    exit 1;
}
my $path;my $comment;my $access;my %security;

print "search share=>$share\n";
foreach (@$stdout){
   print "$_\n" ;
   if (/^\S+\s+(\/vol\/\S+\s+|\/vol\/\S+\/\S+\s+)(.*)?/){
      $path=$1;
      $comment=$2;
   }#end if regex
   if ( /\s+(.+)\s+\/\s+Read/g){
        push @{$security{read}},$1;
   }
   if ( /\s+(.+)\s+\/\s+Change/g){
      push @{$security{change}},$1;
   }
   if ( /\s+(.+)\s+\/\s+Full\sControl/g){
      push @{$security{'full control'}},$1;
   }

}
print "path=>$path\n" if $path;
print "comment=>$comment\n" if $comment;
print "cifs read=>$_ \n" foreach (@{$security{read}});
print "cifs full control=>$_ \n" foreach (@{$security{'full control'}});
print "cifs change=>$_ \n" foreach (@{$security{change}});

$cmd="$t ssh $filer cifs shares -add $new_share $path -comment \'$comment\'" if ($comment);
$cmd="$t ssh $filer cifs shares -add $new_share $path" unless ($comment);
print "$cmd\n";
($stdout,$stderr)=run_cmd $cmd;
if (@$stderr){
    print "$_\n" foreach (@$stderr);
    unless ((grep /MS-DOS/,@$stderr)and @$stderr == 1){
       exit 1;
    }
}
print "$_\n" foreach (@$stdout);

$cmd="$t ssh $filer cifs access -delete $new_share everyone";
print "$cmd\n";
($stdout,$stderr)=run_cmd $cmd;
if (@$stderr){
    print "$_\n" foreach (@$stderr);
    exit 1 unless (grep /successfully modified/,@$stderr);
}
print "$_\n" foreach (@$stdout);

foreach my $type ('read','change','full control'){#type
   print "type=$type\n";
   foreach (@{$security{$type}}){
      $cmd="$t ssh $filer cifs access $new_share \'$_\' $type";
      print "$cmd\n";
      ($stdout,$stderr)=run_cmd $cmd;
      if (@$stderr){
          print "$_\n" foreach (@$stderr);
          exit 1 unless (grep /successfully modified/,@$stderr);
      }
      print "$_\n" foreach (@$stdout);
   }
}#end foreach type
$cmd="$t ssh $filer cifs shares -delete $share";
print "$cmd\n";
($stdout,$stderr)=run_cmd $cmd;
if (@$stderr){
    print "$_\n" foreach (@$stderr);
    exit 1;
}
print "$_\n" foreach (@$stdout);
##########################################################
sub run_cmd{
##########################################################
   my $cmd=" @_";
   my $err_file="/dev/shm/err.$$";
   $cmd.=" 2>$err_file";
   my @stdout=qx($cmd);
   chomp @stdout;
   my @stderr;
   if (-s $err_file) { #if the error file has messages
      open ERR,"$err_file";
      @stderr=();
      close ERR;
      chomp @stderr;
      #print "$_\n" foreach (@stderr);
   }
   unlink ($err_file);
   return (\@stdout,\@stderr);
}

SMB 3.0

Для начала терминологическое вступление. Вокруг файлового протокола 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 осенью этого года.

WAFL File Folding

О любопытной функции внутри Data ONTAP прочитал недавно в блоге ntapgeek. Эта фича называется WAFL File Folding и позволяет экономить место на дисках для файлов, отдаваемых по протоколу CIFS.

Принцип работы File Folding таков. Как вы уже знаете (а кто не знает – идите и читайте), все перезаписи данных на WAFL осуществляются, согласно конструкции файловой системы, таким образом, что они не меняют собственно содержимого блока данных в файле, а записываются в отдельный свободный блок, куда переставляется “указатель”-inode. Это позволяет быстро и просто делать снэпшоты, так как в WAFL не нужно, как во всех прочих реалиациях снэпшотов, переносить содержимое перезаписывамых блоков в отдельное место. Единожды записанный блок, помещенный в снэпшот, уже никак не будет изменен, так устроена FS.

Однако представим себе такую странную ситуацию, когда обширный файл, с которого у нас взят снэпшот, перезаписывается, целиком или полностью, ровно теми же данными, что уже лежат в нем. Для каждого блока такого файла на диске будет занято по меньшей мере два физческих блока. Один – оригинальный, лежащий запертым в снэпшоте, и второй – измененный, лежащий в пространстве “активной файловой системы”, даже несмотря на то, что содержимое этих блоков совершенно идентичное.

Я теряюсь в догадках, что это за операция такое проделвывает, но факт того, что это сделано именно для CIFS, подсказывает мне, что что-то в CIFS любит перезаписывать целиком файлы, даже, например, при незначительных изменениях в нем. Например, представм, что это какой-нибудь Winword, и в нем большой файл, в котором мы поправили запятую, и нажали “сохранить”. ?? весь этот файл, блок за блоком, перезаписался поверх теми же данными, что были (за исключением этой запятой). Не знаю, возможно кто-то подскажет, о чем тут идет речь.

Так или иначе, в результате такой перезаписи, мы будем иметь на дисках два файла, из равного набора блоков, один в снэпшоте, а один в собственно файловой системе, ведь WAFL не видит, что там такое произошло с файлом. Попросили из приложения перезаписать стотыщ блоков – вот вам стотыщ свободных блоков, пишите в них, ведь исходный файл в снэпшоте, блоки его нельзя трогать.

Вот для решения такой проблемы и предназначена малоизвестная фича, под названием WAFL File Folding.

Включают ее командой:

> options cifs.snapshot_file_folding.enable on

и эта команда делает следующее:

В Data ONTAP начинает работать процесс, который физически сравнивает в перезаписываемых файлах блоки данных с соответствующими блоками в наиболее свежем снэпшоте с этого файла. ?? если блоки оказываются идентичными, то просто указывать вместо таких “псевдоизмененных” и “псевдоперезаписанных” блоков, на блоки в крайнем по времени снэпшоте. Это что-то отдаленно напоминает дедупликацию, но там похожий процесс работает только внутри активной файловой системы, между разными в ней файлами, а тут – между пространством активной файловой системы и пространством самого свежего снэпшота.

Теоретически, как и любой процесс экономии пространства, этот процесс дополнительно нагружает процессор и занимает память задачей попарного сравнения блоков. Однако, если этот процес достигает определенного для него лимита использования RAM, он приостанавливается, и ждет ее освобождения, так что в принципе страшного ничего произойти не должно.

Утверждается, что фича эта тихо живет уже довольно давно, полагаю она была добавлена по заказу какого-нибудь Особо Любимого Клиента и его специфической задачи, и не особенно раскручивается для прочих. Данная опция существует в Data ONTAP вплоть до версии 8.1 в 7-Mode.

Так что если в ващем хранилище CIFS есть сходная проблема с перезаписью, то можете попробовать, по идее это должно экономить какое-то количество пространства на дисках, при использовании снэпшотов. Помните, однако, что это займет сколько-то процессора и памяти, так что включив это обязательно проследите за поведением системы какое-то время.

UPD: из комментариев к “зеркалу” данного поста на https://communities.netapp.com/groups/netapp-ru (если вы там еще не были - сильно рекомендую сходить и ознакомиться, это форум и сообщество по NetApp, созданное мною на официальном сайте NetApp, чтобы было удобнее вести дискуссии и обсуждения, в формате форума, и так далее. Я туда также зеркалю свои посты отсюда).

“Ну именно офисные приложения word и exel и перезаписывают файлы целиком. При открытии файла на редактирование ms офис создает новый временный файл и работаем в нем, а операция сохранения это удаляем старый, копируем новый. То есть файл всегда пишется целиком. А так как на CIFS разделах делать снепшоты очень удобно (в винде встроены механизмы отслеживания версионности файлов и нет необходимости привлекать администраторов чтоб открыть любой файл из предыдущих версий) то начинает быстро “распухать” раздел по них.

Поэтому на томах доступных для CIFS где работают с офисными приложениями и снепшоты делаются по сколько раз в день, что затрудняет возможность проведения дедупликации перед ними, данная опция маст хэв :) “

SMB vs. iSCSI: как дела у Hyper-V? Результаты неожиданны.

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

image

 

Network Adapter: BytesReceived/sec

image

 

NetApp Array Performance

Net_Data_Sent

image

CPU_Busy

image

CIFS vs. iSCSI Ops/sec

image

 

Как вы видите, как со стороны хоста Hyper-V, так и со стороны контроллера NetApp, уровни загрузки CPU, а также производительность сети оказались сравнимыми! Важно отметить, что, в данном случае, мы еще даже не используем SMB2.2, так как работает Server 2008 R2 SP1, а не Server.Next. Если же мы видим равную производительность для текущего поколения софта, запущенного на оборудовании четырехлетней давности, то что же мы получим, когда появится Server.Next?

Но где же вообще разница между протоколами, спросите вы, а что там с latency?

Давайте посмотрим, вот картина на стороне NetApp:

image

Неожиданно, не правда-ли?

На первый взгляд, все неплохо, исключая взлет 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, это должно оказаться весьма неплохо!

NetApp System Analyser for CIFS

Продолжая тему контроля пользователей NAS, начатую постом про команду cifs top, хочу отметить любопытную утилиту, доступную на сайте NOW: NetApp System Analyser for CIFS

Это автономная утилита под x32 и x64 Windows, помогает контролировать и анализировать загрузку NAS-системы пользователями по протоколу CIFS.

image

Утилита состоит из четырех компонент:

Dashboard: основная панель, показывающая обзор состояния контроллера системы хранения, таких его параметров, как CPU utilization, объемы трафика, счетчики производительности CIFS и общую информацию по системе.

image

Analyzer: Создает отчеты и делает рекомендации по вашей ситуации, определяя возможные источники проблем.

image

User Statistics: Показывает статистику по пользователям,  позволяет оценить кто из пользователей (а также серверов или приложений) и сколько использует ресурсов CIFS.

 

Support Report: Собирает данные, необходимые для работы NetApp Support, для анализа и устранения проблем, связанных с CIFS. Вывод может быть послан непосредственно в NetApp из самой утилиты, или записан и отослан отдельно.

Полезные команды: cifs top

Если с занимающими много места на дисках пользователями NAS можно справиться механизмом квот, то что делать с пользователями, которые используют много, но не места, а системных ресурсов, например загружая систему большим числом операций ввода-вывода?

Прежде всего таких следует найти и оценить загрузку от них. В этом поможет команда cifs top.

Для начала нам надо включить системную опцию:

fas1> options cifs.per_client_stats.enable on

Далее, собрав некоторую статистику, введем команду:

fas1> cifs top –n 3 –s w - показать трех самых активных пользователей, отсортировав список по объемам записи

    ops/s  reads(n, KB/s) writes(n, KB/s) suspect/s   IP              Name
     263 |     29   215 |     137   627 |        0 | 10.56.10.120 ENGR\varun
     248 |     27   190 |     126   619 |        1 | 10.56.10.120 ENGR\jill
     246 |     26   195 |     125   616 |       19 | 10.56.12.118 MKTG\bob

 

Более подробно о доступных ключах команды можно узнать из встроенной документации и манов.

Поддержка SMB2.0 в протоколе CIFS на NetApp

Появившийся на Wndows Vista, а позднее и на Windows Server 2008 протокол SMB2.0, дальнейшая разработка Microsoft своего сетевого протокола, показывает заметное улучшение производительности, однако требует для своей работы пока не слишком распространенных платформ Vista и Server 2008.

Но для тех, кто уже перешел на новые платформы, интересно будет узнать, что SMB2.0 поддерживается в протоколе CIFS в NetApp FAS начиная с версии ONTAP 7.3.1
Для включения SMB2.0 надо изменить значение системной опции options cifs.smb2.enable

Любопытное исследование, показывающее эффект от перехода на SMB2.0 с Jumbo Frames в гигабитной локальной сети найдено тут:
http://www.alternativerecursion.info/?p=48

image

Пожалуйста, обратите внимание, что SMB2.0 поддерживается только в Vista, Windows 7 и Server 2008, включать его при использовании в сети клиентов XP и Server 2003 нельзя.

Официальный документ из технической библиотеки NetApp:
SMB 2.0 – Next Generation CIFS protocol in Data ONTAP®

NFS и CIFS: что выбрать?

Прежде всего выбор NAS-протокола определяется принадлежностью IT-инфраструктуры, использующей NAS-устройство, к одному из двух «царств» - «Windows» или «UNIX».
«Родной» (native) протокол для Windows – CIFS, для UNIX (Linux, Solaris, AIX, FreeBSD и т.п.) – NFS. Конечно, в большинстве OS существует поддержка протоколов соседнего «царства». Так, например, NFS для Windows поставляется в бесплатном ныне продукте MS Services for UNIX 3.5 (SFU, бесплатно скачивается с вебсайта Microsoft) или SAMBA (www.samba.org, включен ныне в большинство дистрибутивов UNIX) для поддержки CIFS на UNIX. Но, разумеется, родной протокол для системы почти всегда предпочтительнее, хотя бы просто из соображений минимизации настроек и инсталляций, а значит ошибок администраторов и неожиданных проблем с производительностью.

Stateless и Stateful протоколы. Что это и чем грозит.

Протоколы файлового доступа NFS и CIFS, кроме принадлежности к двум «лагерям» UNIX и Windows, различаются также принципиальной разницей способов обращения к данным: т.н. stateless и stateful.
NFS это протокол stateless. Это означает, прежде всего то, что он по своей природе не сохраняет состояние соединения, и каждое обращение к файлу начинается «как с чистого листа». Причиной этого было то, что NFS изначально создавался как протокол доступа к данным по априори ненадежным, «глобальным» сетям. Между обращениям к файлу мог случиться обрыв и восстановление соединения, маршрут к файлу, с точки зрения сети, мог поменяться (что нормальная ситуация для TCP-сети). Все это не должно было оказывать влияния на процесс доступа к данным.
Для правильной обработки таких ситуаций была выбрана так называемая «stateless» модель соединения. При этом каждое обращение делается предполагая, что состояние соединения не сохраняется или не известно. Операция изменения байта в файле производится как «обратиться к файлу – проверить его существование – открыть файл на запись – записать байт – закрыть файл». При этом между операциями файл может исчезнуть, быть вновь создан, переместиться на другое устройство и так далее. С точки зрения протокола NFS это совершенно неважно. Состояние соединения между приложением и его файлом не хранится, и каждое соединение создается заново. Казалось бы излишние усилия и накладные расходы? Однако при общей аскетичности NFS как протокола (а создавался он еще во времена, когда модем на 2400 бод был вполне приемлемым средством доступа к данным), во многих случаях эти дополнительные операции с файлами не слишком обременяют процесс.

CIFS – Common Internet File System - Обобщенная ??нтернетная Файловая Система (также ранее известный как SMB – Server Message Blocks - Блоки Сообщений Сервера) рожден уже в наше время. ??значально он разрабатывался как сетевой протокол, применявшийся в среде системы Microsoft LAN Manager, сперва для DOS, а потом для Windows, как совместная разработка MS и IBM. Унаследовав технологии LAN Manager и его протокол SMB со времен DOS, войдя в новую OS Microsoft Windows и пройдя длинный путь развития, протокол был стандартизирован в 1987 году в IETF (RFC1001, RFC1002, IETF STD 19) под названием CIFS.
Это более сложный, чем NFS, протокол. Его область применения это уже гораздо более надежная LAN. Она позволила выбрать для него во многом более выгодную модель «stateful», при этом соединение будучи открыто, например, подразумевается открытым, его состояние сохраняется в OS, и оно не требует для каждой записи проходить все операции с самого начала: «проверили существование – открыли – записали байт – закрыли». Однако вследствие того, что NFS протокол более простой, и во многих местах даже примитивный (не забудьте, для какой среды он изначально проектировался), зачастую в ряде случаев он, несмотря на все дополнительные «накладные расходы», оказывается более быстродействующим. А для операций, связанных, например, с переподключением хранилища данных в кластерной или иной отказоустойчивой конфигурации, еще и более предпочтительным, за счет того, что изначально предполагает соединение между потребителем данных и его источником ненадежным и способным исчезнуть или измениться в любой миг.

Для использования NFS в среде Windows можно использовать бесплатно распространяемый ныне Microsoft продукт MS Services for UNIX (SFU), в который включен клиент для NFS. Поддержка протокола NFS для среды UNIX же обычно включена по умолчанию во все дистрибутивы.
Поддержка же CIFS в среде UNIX осуществляется через продукт под названием SAMBA, это результат reverse engineering-а сетевого обмена протокола и воссоздания средств использования протокола в независимом свободно распространяемом продукте. Такое непростое и чреватое будущими проблемами совместимости решение было выбрано потому, что, несмотря на свою стандартизацию в IETF, протокол CIFS закрыт и является собственностью Microsoft, что ограничивает его использвание в ряде случаев в продуктах т.н. «свободного программного обеспечения» (GNU). Официально лицензией на его использование владеют в настоящий момент два крупнейших производителя NAS, такие как Network Appliance и EMC. Лишь только они используют полнофункциональный протокол CIFS в своих независимых от MS продуктах. Остальные вынуждены либо использовать SAMBA, либо применять для него версию Windows Storage Server, несущий в себе CIFS по умолчанию.