Системы хранения данных как предмет разговора
Posts tagged ‘fc’
Ну вот, и результаты SPC-1, то есть для “тяжелого” блочного доступа, подоспели.
Правда, пока не готов Full Disclosure Report, а есть только Executive Summary, в котором многие важные детали опускаются.
Но посмотреть все равно интересно. Ждем выкладки детального отчета. - Опубликован и Full Disclosure Report
Я обратил внимание, что очень многие, в особенности впервые сталкивающиеся с 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, анализировавшая производительность Oracle 11g на RHEL и системе хранения NetApp.
Для затравки вам картинка:
Полностью читать – там:
Red Hat Enterprise Linux Protocol Performance Comparison with Oracle Database 11g Release 2
http://www.netapp.com/us/library/technical-reports/tr-3932.html
Простая как мычание формула “быстрее – значит лучше” завладела умами в Enterprise также крепко, как в массовом рынке “больше мегагерцев – значит лучше” (или “больше мегапикселей – значит лучше”). С появлением на рынке новой спецификации интерфейса 8Gb/s FC начал раскручиваться новый виток этой маркетинговой истерии. “А у вас еще не используется 8Gb/s? Тогда мы идем к вам!”.
Однако нужен ли он на самом деле в конкретно вашей задаче, и даже более того, готовы ли вы, и ясно представляете ли себе все скрытые “засады” от перехода на 8Gb/s FC, стоящие за простым “увеличением вдвое скорости FC”?
Ранее в этом блоге я уже отвечал на первую часть этого вопроса, и показывал, что пока ваши приложения не уперлись в bandwidth нынешнего интерфейса, расширение вдвое полосы пропускания незагруженного интерфейса по сути равно расширению вдвое полосности автодороги, по которой проезжает один грузовик в минуту. Скорости грузовика от пункта А в пункт Б это не увеличит, а цену дороги (и стоимость доставки груза, в результате) увеличит несомненно.
На вторую часть этого вопроса, о скрытых “засадах” перехода, о которых вы, возможно, не задумывались, отвечает инженер NetApp Archie Hendryx в его блоге на сайте NetApp Communities.
Например, вы можете столкнуться с тем, что пассивная FC-инфраструктурв (кабели, патч-панели и прочее), нормально работавшие на 4Gb/s, будут сыпать CRC errors, Protocol errors, Code violations, которые могут снизить реальную скорость передачи данных по FC-сети даже ниже ранее нормально работавших без retry и ошибок каналов 4Gb/s. Те проблемы, например несоблюдение правильных углов перегиба волокна, или незначительное загрязнение концов оптических pigtails (пыль, отпечатки пальцев), которые никак не влияли на работу 4Gb/s FC, могут быть серьезной проблемой для более “строгого” к соблюдению спецификаций 8Gb/s FC. ?? если в небольшой инфраструктуре вы можете, крякнув, вписать в бюджет следующего года полную прекладку или аудит кабельного волокна, увеличив в разы, по результату, стоимость такого “апгрейда”, то в больших инфраструктурах это, зачастую, просто физически невозможно.
Ранее нормально работавшая годами без вмешательства FC-инфраструктура может стать ежедневным источником головной боли, и непрекращающейся борьбы с загадочно вылезающими то тут, то там проблемами. Следует трезво понимать и представлять себе такую опасность, и быть готовым к ней. А как первый шаг – задаться вопросом из другого рекламного ролика: “А если не видно разницы – то зачем платить больше?”
Тестлаб компании 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) разница может оказаться еще менее значительной.
Также интересующимся рекомендую обратить внимание на документы:
Специально свое мнение вынесу из комментов, так как читают меня в основном из RSS, и в комменты мало кто ходит.
Я не считаю, что Fibre Channel это плохо. FC это замечательная технология. Но любая технология лучше всего работает на своем месте, там, где она нужнее, там, где ее преимущества наиболее проявляются.
Целью же моего предыдущего поста была попытка донести мысль, что в случаях, когда то или иное дорогостоящее решение не дает существенных, сравнимых с затратами на него результатов, использовать его неразумно и расточительно. Те же деньги можно потратить с гораздо большим результатом иным способом. ?? этих способов немало.
Затраты должны быть соизмеримы, и решения должны быть соразмерны задачам.
В прошлом своем посте я не столько пытался “опустить” FC, сколько донести мысль, что когда клиент покупает на “последние деньги” какой-нибудь Xyratex или Infortrend (все совпадения с реальным торговыми марками случайны;), при этом наполняет его дисками c “митина”, потому что “нет денег на родные”, но при этом собирается половину, а то и две трети цены массива потратить просто на “провод” для подключения, то это, мне кажется, крайний случай несбалансированности.
Приводя аналогии из полюбившегося автопрома: человек покупает какую-нибудь вазовскую “классику”, возить тещу и помидорную рассаду на дачу. Ну что, вполне себе задача, практическая. Не гонки Формулы, но не всем же, в конце концов, нужна Формула? Вот такая наша жизнь, в ней тоже надо ездить на дачу.
?? вот, вместо покупки, например, более новой и безопасной машины, или вместо того, чтобы потратить деньги, например, на перебор двигателя, юстировку колес и промывку карбюратора-инжектора, покупатель тратит деньги, выкроенные из семейного бюджета на дачный автомобиль, на установку в “классику” ксеноновых фар, гоночных “ковшей”-сидений из красной кожи, низкопрофильной резины и брызговиков Sparco, на остатки.
По моему мнению, FC в entry (да зачастую и не только entry) level это типичный пример гаражного тюнинга и “синих писалок” в IT. Это эффектно, но, как и дырки в глушителе, выдающие мощный рев на светофоре, нисколько не помогают с него уехать быстрее.
Наверняка многие слышали за последний год-два о новом направлении развития протокола FC, по замыслу Cisco (и, отчасти Brocade) его транспортом станет “нативный” Ethernet, что неудивительно при таком успехе стремительно дешевеюшего 10G Ethernet. По видимому на сегодня будущее FC в конвергенции транспорта из собственного проперитарного в широкодоступный Ethernet.
?? вот, NetApp снова на острие. По сообщению SearchStorage
14 октября объявлено о нативной поддержке FCoE в системах хранения NetApp моделей FAS и V.
Ожидается, что доступные к концу года native FCoE target cards, устанавливаемые в систему хранения, будут стоить сравнимо с нынешними 8GB FC.
??нтерес к этой технологии у NetApp не случаен, компания давно и прочно удерживает лидерство среди стремительно набирающих популярность систем хранения протокола iSCSI или (IP-SAN), конвергирующего SAN в транспорт IP обычно over того же Gigabit и 10G Ethernet. Теперь сюда логично прибавится FCoE.
Напомню, что в отличие от iSCSI, использующего транспортные возможности протокола IP, FCoE транспортируется не поверх IP, а уровнем ниже, непосредственно на “канальном” (в терминах ISO/OSI) уровне Ethernet. Это позволяет преодолеть ряд недостатков, присущих iSCSI, передающегося на “сетевом” уровне, инкапсулированного в IP-пакеты, однако получающего свои недостатки, характерные для работы на таком уровне.
Думаю подробный разбор FCoE как такового я напишу чуть позже, тогда станет понятнее место и назначение этого “новичка” в команде протоколов, поддерживаемых NetApp.
Вторая часть серии про работу Oracle на NetApp, на этот раз на FC.
Руководство по интеграции средств системы NetApp VTL и ПО NetBackup Vault.
А подписаться на получение новых выпусков можно на странице компании Verysell Distribution.
Любопытные цифры приведены в аналитическом отчете ESG (Enterprise Strategy Group Inc.), опубликованном в начале этого года (доступен на сайте NetApp).
Более половины (54%) из 329 опрошенных ответило, что, после внедрения решеня серверной виртуализации, объемы хранения увеличились (причем ответ “свыше 20%” дали 18% от этого количества).
68% ответивших считают, что FibreChannel есть “технология, предлагающая максимальную производительность” (и всего 22% ответили так для NFS).
Всего 19% считают о NFS, что она “наилучшим образом оптимизирована для задач виртуализации серверов” (против 49% FC и 45% iSCSI)
При этом среди тех, кто уже использует то или иное решение, ситуация обратная.
“Мы уже используем эту технологию и она нас полностью устраивает” 65% назвали NFS, и уже только 53% FC.