about NetApp

Я обратил внимание, что очень многие, в особенности впервые сталкивающиеся с SAN, обязательно хотят реализовать у себя возможность бездисковой загрузки серверов из SAN, с созданного в ней LUN-а. Но потом как-то охладевают к этой идее, по причине ряда сложностей реализации и неочевидности преимуществ. Действительно, если у вас blade-ферма на три десятка blades в ней, то экономия на жестких дисках по ценам изготовителя blades, может вылиться в экономию, за которую можно пострадать, но при всего 2-4 серверах в SAN это обычно не стоит выделки. Однако если вы все же решили заняться SAN boot, то вот какие полезные сведения я обнаружил в блоге группы поддержки решений Microsoft, сформированной в NetApp.

Во-первых, следует знать, что на сегодняшний день загрузка из SAN для актуальных OS Microsoft полностью поддерживаемое решение. См. статью из Knowledge Base.

Во-вторых, следует помнить, что проблемы с зонингом – есть “номер один” всех проблем с SAN boot. Если у вас что-то не работает – начните с проверки зонинга. Чаще всего разрешение проблемной ситуации с зонингом и есть решение проблемы загрузки из SAN. Если ваша система на поддержке – обратитесь в поддержку NetApp, они “знают много гитик”. Проверяйте и перепроверяйте все настройки зонинга ДО того, как начнете долбить поддержку.

Третий момент, который стоит помнить, это то, что поддержка MS MPIO на этапе загрузки крайне ограничена. Используемый в MS на этапе инсталляции WinPE (Windows Preinstall Environment) не рассчитан на работу с MPIO, и подключение LUN по нескольким путям может давать непредсказуемые результаты. При первой загрузке этапа установки, инсталлятор Windows загружает модуль boot.wim (это и есть WinPE) и начинает копирование файлов из дистрибутива в “локальный диск”, который в вашем случае будет SAN LUN-ом. После копирования загрузится уже собственно Windows. Поддержка рекомендует на время работы WinPE физически отключать второй путь, который можно будет подключить назад позже, когда у вас уже будет работающий MPIO.

Также стоит помнить, что MPIO не поддерживается в sysprep. Вам придется настроить MPIO непосредственно на том образе, с которого будут грузиться система, но официально не поддерживается его конфигурирование непосредственно в syspreped образе. Оно работает, как показывает опыт. Но не поддерживается MS. Be warned, есличо.

MPIO, несмотря на написанное выше, настоятельно рекомендуется для загрузки SAN boot! Если в момент загрузки вы потеряете связь с SAN LUN, с которого система загружается, она упадет в BSOD Inacessible boot device. Смотрите по этому поводу статью в TechNet.

Для того, чтобы LUN в SAN был увиден системой на этапе инсталляции, он должен быть подключен из BIOS карты HBA. Это поддерживается для “аппаратных” HBA FC (FCoE), а также для hardware HBA iSCSI. Теоретически есть методы загрузки из SAN и для Software iSCSI, но рассмотрение этой темы выходит за рамки данной статьи.

Напомню еще раз, что, для двухпортовых карт, вы должны активировать поддержку загрузки в BIOS только для одного из двух имеющихся портов HBA! Реализация отличается в зависимости от вендора HBA, так что внимательно проследите эту тему самостоятельно по документации. На этапе загрузки не работает MPIO, и LUN должен видеться только по одному пути!

Если после всего перечисленного выше, инсталлятор по прежнему не видит диск, на который он может установить OS, то, скорее всего, в дистрибутиве проблема с драйверами для данного типа HBA. Можно попробовать вставить правильные драйвера непосредственно в инсталлятор, в модули boot.wim и install.wim, либо подставьте драйвера вручную, когда это запрашивает инсталлятор. Опять же тема интеграции драйверов в дистрибутив Windows достаточно хорошо рассмотрена в интернете.

Помните, что если вы вынули CD/DVD-диск, чтобы вставить на его место диск с драйверами, то не забудьте вернуть назад диск с дистрибутивом для продолжения установки. :)

Обратите внимание, что в Windows Host Utilities Installation and Setup Guide со страницы 95 идет очень детальное и подробное описание настройки SAN Boot.

Для практической проверки и отработки решения группа построила стенд из 22 серверов Fujitsu RX200, снабженных двухпортовыми FCoE HBA Brocade 1020, включенных в два коммутатора Brocade 8000 FCoE, куда также подключены два контроллера FAS6030 с дисками. HBA обладают возможностью загрузки из SAN в их BIOS, а сервера имеют средства управления Fujitsu iRMS (аналог HP iLO и DELL DRAC). Система хранения NetApp имеет активированную лицензию FlexClone, используемую в дальнейшем процессе. В принципе, описываемые процессы могут быть реализованы и без FlexClone, но с ним они куда эффективнее расходуют пространство хранения, так как место на диске занимают только изменения относительно мастер-LUNа.

Начнем с создания пустого volume и на нем LUN-а, который будет мастер-образом. Смонтируем данный LUN на один из серверов, заполним и сконфигурируем его, а позже склонируем для остальных серверов. Не забудьте установить в этот образ OS все нужные роли, драйвера и приложения, в данном случае были установлены NetApp DSM, Host Utilities, а также драйвера и приложение управления HBA от Brocade.

Запустим sysprep с опциями –generalize и –shutdown, после чего сервер отключится и LUN необходимо отмапить от сервера. Эталонный мастер-образ подготовлен.

Теперь подготовим остальные сервера на загрузку из SAN. Помните, что в BIOS HBA необходимо включить загрузку с SAN LUN только для одного порта! Смотрите ссылку на документ Boot from SAN in Windows Server 2003 and Windows Server 2008 из MS Download Center.

В имеющемся HBA в BIOS была выбрана опция загрузки “First visible LUN” (эти настройки могут отличаться для разных HBA, решайте по аналогии) с тем чтобы обеспечить наиболее простую загрузку, которая не потребует в дальнейшем перенастройки при изменениях, как в случае опции “Preferred LUN”. Вариант First visible LUN, разумеется, требует некоторых предосторожностей, например дисковый массив с загрузочным LUN должен располагаться в ближайшей к серверам фабрике, чтобы минимизировать задержки, а также иметь LUN ID 0.

Создаем клон тома мастер-образа, например с помощью FlexClone. Маппим LUN в клоне тома (не оригинальный мастер-образ, а клон!) на сервер. Включаем сервер с использованием iRMC и подключаемся к серверной консоли.

Сервер загружается и запускается mini-setup после sysprep. В нем вы можете задать пароль, изменить имя сервера, назначить IP-адрес, и так далее (если вы знакомы с развертыванием образов Windows с использованием sysprep, это не должно быть неожиданностью). После завершения mini-setup вы получаете созданную из мастер-образа индивидуальную копию установки Windows.

Итак, мы за несколько минут получили полностью загруженный в индивидуальный образ Windows физический сервер, загружаемый из SAN.

Немного иначе происходит процесс для загрузки виртуальных серверов из SAN.

В случае pass-through disks Hyper-V все происходит также, как и в случае физического сервера, но нужно создать для VM еще один клон, и назначить ему LUN ID отличный от 0, чтобы он не пересекся с LUN, используемым для загрузки физического сервера. Используя LUN FlexClone вы можете создать клоны мастер-LUN непосредственно на том же volume, где он сам и находится. Следите, чтобы на volume либо было достаточно места для записи хранимых “разностных” изменений, или чтобы была активирована опция “volume autogrow” и места было достаточно уже на aggregate этого тома. Если вам понадобится создать больше VM, просто создайте еще несколько клонов мастер-LUN.

В случае использования VHD, следует создать LUN для физического сервера, содержащий файлы VHD для находящихся на нем виртуальных. Также можно использовать возможности sub-LUN клонирования FlexClone, создав один клон LUN-а с множеством клонов VHD в нем.

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

Использование же FlexClone в данном случае поможет значительно сократить занятый объем. Например, в описываемом случае, около 50 LUN-ов разлчных проектов данного стенда имеют совокупную емкость около 5TB, занимая при этом на диске всего около 300GB.

Недавно один мой коллега провел “для себя” небольшой подсчет цен на решение SAN, сравнив стоимость “железа” для построения сети передачи данных iSCSI и FC разной пропускной способности.

Данные оказались любопытными, и я упросил его разрешить мне их опубликовать.

По оси X – количество подключаемых в SAN хостов-серверов, по Y – цена оборудования без учета стоимости работы и времени, только “железо”.

Цены брались “real-life” и “street price” (не list price). Разумеется dual fabric и по два порта на хост, и так далее, как положено в реал лайфе. Выбиралось оборудование за минимальную цену, выполняющее поставленную задачу, но, естественно, из доступного данному партнеру списка вендоров (поэтому, главным образом, Cisco и IBM (Brocade)). В подсчет включались HBA и NIC, коммутаторы, SFP, кабеля, лицензии на порты, где нужны, и так далее.

Результат любопытен, и показывает неоднозначность вопроса “дороговизны”. Так, например, на 1-8 хостов стоимость решения 10G Ethernet в разы перекрывает тот же 8G FC, а вот на 16-24 хоста в SAN все уже не столь очевидно (больше 24 хостов анализ не производился, там уже начинаются “директоры” и совсем иного класса оборудование).

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

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

Как вы видите, в обоих случаях величина эффективности использования хранилища сравнима и высока.

Так как мы увидели, что производительность и уровень использования системы хранения примерно одинаков, давайте посмотрим на остальные критерии и попытаемся ответить на вопрос, что же лучше.

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

“Ethernet storage” принято называть все системы хранения, использующие ethernet для передачи данных. Это могут быть NFS или CIFS NAS, а также iSCSI или FCoE SAN.

Использование Ethernet как среды передачи данных систем хранения становится все популярнее, однако задачи создания “сети хранения данных” с использованием ethernet предъявляют особые требования к стабильности и надежности работы сети. То что “прокатит” для раздачи интернета в офисе может “не прокатить” при создании сети IP-SAN или NFS для критически важных для бизнеса задач.

Если перед вами стоит задача организации такой сети передачи данных, хочу обратит ваше внимание на свежий перевод в библиотеке Netwell: TR-3802 Ethernet Storage Best Practices.

Как организовывать и настраивать транкинг VLAN? Как работает и чем полезен протокол Spanning Tree? Что такое, и как работает VIF – Virtual Interfaces в NetApp? Чем отличаются Single mode и Multi-mode VIF? Static и Dynamic Multimode VIF? Почему объединенные в etherchannel (ethernet-транкинг) порты могут не давать ожидаемой от этого объединения увеличения полосы пропускания? Как работают Jumbo Frames и Flow Control на уровне Ethernet, и как правильно его применять?

Все это в исключительно полезном документе техбиблиотеки NetApp доступном теперь и на русском языке:

TR-3802 Ethernet Storage Best Practices.

PS. Кстати может быть полезен и не только пользователям NetApp.

Тестлаб компании NetApp продолжает тестировать и публиковать показатели производительности различных программных систем, работающих с системой хранения через различные протоколы доступа, с акцентом именно на сравнение производительности различныхпротоколов. Очередь дошла и до популярной базы данных MySQL, часто использующейся в различных веб-проектах.

По результатам недавно опубликованного отчета о тестировании производительности работы базы данных MySQL 5.0.56 (InnoDB) на сервере HP DL580 G5 под RHEL4, с использованием трех протоколов доступа – FC, iSCSI и NFS, к системе хранения FAS3070 можно оценить эффективность использования передачи данных по этим трем протоколам.

MySQL 5.0 Performance Protocol Comparison

При тестировании использовался открытый тестовый пакет генерации нагрузки DBT-2 Rel.40 (Database Test Suite), генерировавший нагрузку профиля OLTP (16K random read/write в пропорции 57% read/43% write) для базы объемом 100GB. Больше подробностей можно узнать из приведенного документа. Также приведены подробные описания конфигов и использованных настроек всех компонентов.

Для затравки – один из измеренных результатов.

Тестировние показало, что использование iSCSI дало снижение всего на 9%, а NFS – всего на 16% относительно взятой за максимум производительности на FC. Результаты показывают, что широко распространившееся во времена MySQL 3.23 мнение, что NFS в базах MySQL непригоден для использования, уже не соответствует действительности. 
Любопытно, что того же мнения теперь придерживаются и “с той стороны баррикад”, в Sun/Oracle:
”for MySQL on Linux over NFS, performance is great, right out of the box.”

Интересущимся рекомендую тщательно просмотреть отчет, там есть над чем подумать. Есть основания предполагать, что с более новым железом (все же FAS3070 это уже довольно старая система, c ONTAP 7.2.4) и с новым клиентским софтом (RHEL4, использовавшийся на хосте, имел ядро 2.6.9-42.EL.smp) разница может оказаться еще менее значительной.

Также интересующимся рекомендую обратить внимание на документы:

Linux (RHEL 4) 64-Bit Performance with NFS, iSCSI, and FCP Using an Oracle Database on NetApp Storage

Best Practices Guidelines for MySQL

Компания NetApp опубликовала результаты тестирования 4Gb FC и Software iSCSI по 1Gb Ethernet и 10Gb Ethernet в среде MS Hyper-V R2 с использованием своей системы хранения NetAp FAS3160A (система midrange-класса).

Тестирование производилось с помощью IOmeter (о котором я уже не раз писал в блоге), с 4 хост-серверов IBM x3550 (1x Quad-core Intel Xeon E5420, 2,5GHz), на каждом из которых бы установлен Windows 2008 R2 c Hyper-V role и 8 виртуальными машинами в каждом, с Windows 2008 64-bit Enterprise edition (итого 32 виртуальных машины). Интерфейсы каждого сервера: FC – QLogic QLE2462, Gigabit Ethernet – Intel PRO/1000 PT dual port, 10G Ethernet – Intel Ethernet Server Adapter X520, включались в коммутаторы Brocade 200E, Cisco 4948 Ethernet Switch и Fujitsu XG1200 соотвественно.
Особое внимание при тестировании уделялось получению результатов, приближенных к “боевым”, позволяющим использовать их для оценки реальной, “живой” инфраструктуры Hyper-V.

Использовался паттерн: 100% Random, 75% Read, 4KB и 8KB Request size.

Тесты показали сравнительно незначительную разницу между всеми тремя вариантами (4Gb FC, 1Gb software iSCSI, 10Gb software iSCSI) как в IOPS, так и в Latency. Дополнительная загрузка задачи softwre iSCSI initiator составила 3-5 процентов, в том числе и на 512 outstanding IOs (очень высокая загрузка), и разница со значением загрузки при использовании FC уменьшалась с повышением объемов загрузки (Outstanding IOs).

Показательно почти полное отсутствие значимого отличия по быстродействию между 4Gb FC и 1Gb iSCSI на рассматриваемой задаче.
Отсутствие значительной разницы между 1Gb Ethernet и 10Gb Ethernet по видимому связано с тем, что Software iSCSI initiator на 10G Ethernet перестал быть эффективен, и, возможно, следует рассмотреть использование iSCSI HBA для таких высокоскоростных решений.
Также сравнительно небольшую разницу дает включение и использование Jumbo Frames как на 1G Ethernet, так и на 10G Ethernet, что скорее всего говорит о специфике Hyper-V R2 в этом вопросе.

Лимит по производительности системы хранения FAS3160A для такой конфигурации не был достигнут.

Подробности и полный документ по результатам –тут:
http://www.netapp.com/us/library/technical-reports/tr-3846.html

В блогах MSDN найден любопытный документ тестирования iSCSI на 10G Ethernet, с использованием MS Windows Server 2008, Hyper-V, и системы хранения NetApp FAS3070.
Даже несмотря на то, что использовался довольно старенький сторадж (3070 это топовая модель предыдущей midrange-линейки, в настоящий момент уже не выпускаемая, вся серия 3000 уже целиком заменена на 3100), и чисто “софтверный” iSCSI, результаты могут показаться любопытными тем, кто еще раздумывает “А насколько быстр на самом деле этот непонятный iSCSI?”

http://download.microsoft.com/download/F/B/3/FB38CA2C-6694-4D25-8452-4A28668A87F2/MSFT-NetApp-10G.docx

Следует отметить, что карты 10G Ethernet, например рассматриваемая в этом тестировании двупортовая Intel 10 Gigabit AF DA dual port Server Adapter по ценам Price.ru стоит ~770$, а вообще 10G адаптеры начинаются уже от 500$.

Специально свое мнение вынесу из комментов, так как читают меня в основном из RSS, и в комменты мало кто ходит.

Я не считаю, что Fibre Channel это плохо. FC это замечательная технология. Но любая технология лучше всего работает на своем месте, там, где она нужнее, там, где ее преимущества наиболее проявляются.

Целью же моего предыдущего поста была попытка донести мысль, что в случаях, когда то или иное дорогостоящее решение не дает существенных, сравнимых с затратами на него результатов, использовать его неразумно и расточительно. Те же деньги можно потратить с гораздо большим результатом иным способом. И этих способов немало.
Затраты должны быть соизмеримы, и решения должны быть соразмерны задачам.

В прошлом своем посте я не столько пытался “опустить” FC, сколько донести мысль, что когда клиент покупает на “последние деньги” какой-нибудь Xyratex или Infortrend (все совпадения с реальным торговыми марками случайны;), при этом наполняет его дисками c “митина”, потому что “нет денег на родные”, но при этом собирается половину, а то и две трети цены массива потратить просто на “провод” для подключения, то это, мне кажется, крайний случай несбалансированности.

Приводя аналогии из полюбившегося автопрома: человек покупает какую-нибудь вазовскую “классику”, возить тещу и помидорную рассаду на дачу. Ну что, вполне себе задача, практическая. Не гонки Формулы, но не всем же, в конце концов, нужна Формула? Вот такая наша жизнь, в ней тоже надо ездить на дачу.
И вот, вместо покупки, например, более новой и безопасной машины, или вместо того, чтобы потратить деньги, например, на перебор двигателя, юстировку колес и промывку карбюратора-инжектора, покупатель тратит деньги, выкроенные из семейного бюджета на дачный автомобиль, на установку в “классику” ксеноновых фар, гоночных “ковшей”-сидений из красной кожи, низкопрофильной резины и брызговиков Sparco, на остатки.

По моему мнению, FC в entry (да зачастую и не только entry) level это типичный пример гаражного тюнинга и “синих писалок” в IT. Это эффектно, но, как и дырки в глушителе, выдающие мощный рев на светофоре, нисколько не помогают с него уехать быстрее.

Почти всегда, начиная разговор с клиентом по поводу использования iSCSI вместо Fibre Channel, раз за разом я сталкиваюсь с одним упорным возражением:

“Ну… хм… Это же медленно!”

Ну, казалось бы, очевидно: FC это 4Gb/s, а iSCSI - 1Gb/s, “один” ведь в четыре раза меньше, чем “четыре” ведь так?

Давайте разберем что здесь на самом деле “медленно” и медленно ли.

Для определенности давайте рассматривать какую-нибудь реальную задачу.

Вот пример:
Требуется система хранения данных для консолидации данных 4 серверов, 1 файловый сервер и 3 сервера баз данных. Необходимо обеспечить двухпутевое отказоустойчивое подключение.

Но сперва немного теории.

Я уже писал на тему странного спутывания в восприятии совершенно разных параметров канала передачи данных: “полосы пропускания” (анг. “bandwith”) и “скорости” (анг. “speed”).
Для интересующихся подробностями просто сошлюсь на ранее опубликованный пост, а остальным перескажу вкратце.
“Скорость” канала передачи данных равна скорости света в соответствующей среде, и она постоянная, вне зависимости, используем мы 10Mb/s Ethernet или 16GB/s Infiniband.
Переводя на аналогии из “повседневной жизни” это ограничение скорости на дороге - 100 km/h.
Все автомобили по дороге передвигаются с разрешенной скоростью, и ее не превышают по причине физического ее ограничения на уровне физических констант.

В чем же отличие?
В полосе пропускания.
Полоса пропускания - это “рядность автострады”, это способность пропустить через себя “много данных” сразу. Но многорядность автострады никак не ускоряет движение одинокого автомобиля, проезжающего раз в минуту.

Несколько парадоксальный вывод, который я делал в том посте требует некоторого волевого усилия для осознания.
Неважно, насколько “быстрым” (с какой ширины полосой пропускания) интерфейсом соединена ваша система хранения с сервером, если объемы обработки данных этим сервером не достигают потолка имеющейся полосы пропускания.

Если скорость считывания и записи сервера с системы хранения, например, не превышают 10 Мбит/с, то совершенно неважно для быстродействия, используете ли вы 100Mbit/s Fast Ethernet, FC, Infiniband, или подставьте_любой_баззворд_из_презентации.
Если вы не используете даже имеющуюся полосу пропускания целиком, то расширение ее “неиспользуемой части” в 10 раз не приведет к сколь-нибудь значимому увеличению реального быстродействия системы.

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

Вернемся к нашей практической системе хранения для 4 серверов.
В ходе предварительного анализа производительности, наиболее нагруженный сервер баз данных показал, по данным Windows Performance Monitor, следующие показатели:

Disk Read bytes/s 2700902/Average 63587550/Max
Disk Write bytes/s 736811/Average 1616167/Max

То есть, самый нагруженный сервер системы, в максимуме нагрузки, достигал порога чтения всего, примерно, в 60-65 мегабайт в секунду!
Это всего лишь (в пике дневной нагрузки, прошу заметить!) около 55-60% от полосы пропускания одного интерфейса Gigabit Ethernet, или, в случае типовой нагрузки в 2.5-3MB/s, всего около 2-3% от полосы пропускания GigE!

Возможно в данном случае мы упираемся в предел возможности локальных дисков серверов, на смену которым призвана встать система хранения, и сервер имеет большой запас по производительности, если мы обеспечим ему широкую полосу пропускания для данных? Но нет, показатель Disk Read/Write Queue редко когда превышает значение 8-9, что означает относительно слабо нагруженную дисковую подсистему, значит в дисковую производительность сервер практически не упирается.

Итак, давайте посчитаем. В случае нашей рассмотренной выше небольшой IT-системы из четырех серверов, в случае выбора FC нам необходимы:
1. по два однопортовых или по одному двухпортовому FC HBA на каждый сервер - 8 однопортовых или 4 двухпортовых (QLogic QLE2462 2port - 700$ * 4 = 2400$)
2. два FC-коммутатора (недостаточно встроенных FC-портов для подключения всех 6 линков) допустим, пусть это будут массовые и недорогие Brocade 200E - 4000$ * 2 = 8000$.
3. Лицензия на FC (в зависимости от выбранного массива цена варьируется, например для системы типа FAS2050 это около 1200$ для одноконтроллерной и 2400$ для двухконтроллерной, отказоустойчивой, “кластерной” системы)
4. ПО поддержки многопутевости (стоит заметить, что в поставке Windows средство обеспечения многопутевости MPIO не поддерживает FC, только iSCSI, и использование MPIO с FC требует установки дополнительного программного модуля, так называемого DSM, обычно предлагаемого поставщиком решения системы хранения, он недорог, но тоже не 0$)
5. Кабеля FC optical LC-LC для подключения серверов к коммутаторам (8 шт) и коммутаторов к массиву (2 шт) (LC-LC optical 5m - 50$ * 10 = 500$).
6. затраты на монтаж и настройку (варьируется).
Кажется ничего не забыл :)

Итого, нетрудно видеть, только на возможность использования протокола Fibre Channel мы потратим по меньшей мере около 12-15 тысяч долларов! При этом, как я показал выше, эти 12 тысяч совершенно не увеличат производительность получившейся системы. Они потрачены исключительно “на понты”, на возможность бросить в разговоре с коллегами “а, мы тут файбер ченэл себе прикупили”. :)
“Хороший понт дороже денег”, не спорю. ;) Но 12 тысяч это 12 тысяч. Тем более в наше непростое время на дворе.

Но если бы мы использовали эти, вполне существенные деньги, на что-нибудь действительно дающее реальный эффект, например на пару дополнительных серверов для других задач, премию сисадминам оплату услуг хорошего программиста-оптимизатора баз данных, или, например, в случае системы хранения данных, на дополнительные 10-12 дисков, то за те же деньги мы бы получили (см. ранее про IOPS дисков) систему хранения по меньшей мере на 1800-2500 IOPS быстрее!

И только за счет отказа от “крутого”, “понтового”, но избыточного, и поэтому совершенно “неполезного” в данном случае Fibre Channel.

Статья “Уменьшение стоимости хранения за счет экономии дискового пространства” о использовании сравнительно новой и все еще пока малоизвестной опции Space Reclamation в SnapDrive.

Статья “Oracle на NFS”, о некоторых аспектах все еще пока не слишком распространенного способа хранения данных баз Oracle на NAS-системе, с использованием NFS.

О плюсах и преимуществах использования дедупликации NetApp в задачах построения катастрофоустойчивых конфигураций на VMware Virtual Infrastructure.

О некоторых аспектах отказоустойчивого использования Exchange 2007 и его встроенных средств репликации LCR и CCR.

Вторая часть серии про работу Oracle на NetApp, на этот раз на FC.

Руководство по правильному выравниванию структур создаваемых виртуальных дисков виртуальных машин в среде VMware, относительно блоков данных систем хранения NetApp.

Руководство Best Practices по развертыванию хранилища MS Exchange 2007 SP1 на системе хранения NetApp.

Статья о том, почему при использовании Oracle на системах NetApp протокол доступа, FC, iSCSI или NFS, на самом деле не важен, и как добиться этого.

Руководство по интеграции средств системы NetApp VTL и ПО NetBackup Vault.

Статья “A-SIS созрела”, о том, как устроена, как работает, и что может вам дать технология дедупликации в системах хранения NetApp.

Статья о трех задачах резервного копирования в VMware, и как можно их решить с использованием средств предлагаемых NetApp.

О использовании систем хранения NetApp для резервного копирования Disk-to-Disk, и какие преимущества имеет такая система перед традиционными решениями.

О том, как создавалась FAS3100, какие цели были поставлены, и как удалось создать экономически эффективную систему хранения midrange-класса.

А подписаться на получение новых выпусков можно на странице компании Verysell Distribution.