ITBlogs

Сообщество IT-профессионалов
Welcome to ITBlogs Sign in | Join | Help
in Search

Сетевые системы хранения как объект разговора

Browse by Tags

All Tags » iscsi   (RSS)

  • SAN boot
    Я обратил внимание, что очень многие, в особенности впервые сталкивающиеся с SAN, обязательно хотят реализовать у себя возможность бездисковой загрузки серверов из SAN, с созданного в ней LUN-а. Но потом как-то охладевают к этой идее, по причине ряда сложностей реализации и неочевидности преимуществ. Действительно, если у вас blade-ферма на три десятка blades в ней, то экономия на жестких дисках по Read More...
  • iSCSI или FC? Цена решения.
    Недавно один мой коллега провел “для себя” небольшой подсчет цен на решение SAN, сравнив стоимость “железа” для построения сети передачи данных iSCSI и FC разной пропускной способности. Данные оказались любопытными, и я упросил его разрешить мне их опубликовать. По оси X – количество подключаемых в SAN хостов-серверов, по Y – цена оборудования без учета стоимости работы и времени, только “железо”. Read More...
  • SMB vs. iSCSI: как дела у Hyper-V? Результаты неожиданны.
    Любопытную, и, честно говоря, даже неожиданную для меня тему исследовал блоггер NetApp Lobanov . Следящие за темой уже знают, что в Hyper-V 3.0 Microsoft объявила, что будет поддерживать работу по NAS протоколу SMBv2.2 . Вы помните, что VMware уже с версии 3.0 активно рекомендует использовать NAS для подключения датасторов виртуальных машин по файловому протоколу NFS, и пользуется  при этом большими Read More...
  • Ethernet Storage
    “Ethernet storage” принято называть все системы хранения, использующие ethernet для передачи данных. Это могут быть NFS или CIFS NAS, а также iSCSI или FCoE SAN. Использование Ethernet как среды передачи данных систем хранения становится все популярнее, однако задачи создания “сети хранения данных” с использованием ethernet предъявляют особые требования к стабильности и надежности работы сети. То что Read More...
  • MySQL 5.0 Performance Protocol Comparison
    Тестлаб компании NetApp продолжает тестировать и публиковать показатели производительности различных программных систем, работающих с системой хранения через различные протоколы доступа, с акцентом именно на сравнение производительности различныхпротоколов. Очередь дошла и до популярной базы данных MySQL, часто использующейся в различных веб-проектах. По результатам недавно опубликованного отчета о Read More...
  • Результаты тестирования FC и Software iSCSI под MS Hyper-V R2
    Компания 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), на каждом из которых бы установлен Read More...
  • Производительность iSCSI на 10G Ethernet
    В блогах MSDN найден любопытный документ тестирования iSCSI на 10G Ethernet, с использованием MS Windows Server 2008, Hyper-V, и системы хранения NetApp FAS3070. Даже несмотря на то, что использовался довольно старенький сторадж (3070 это топовая модель предыдущей midrange-линейки, в настоящий момент уже не выпускаемая, вся серия 3000 уже целиком заменена на 3100), и чисто “софтверный” Read More...
  • Еще несколько слов об оптимальности.
    Специально свое мнение вынесу из комментов, так как читают меня в основном из RSS, и в комменты мало кто ходит. Я не считаю, что Fibre Channel это плохо. FC это замечательная технология. Но любая технология лучше всего работает на своем месте, там, где она нужнее, там, где ее преимущества наиболее проявляются. Целью же моего предыдущего поста была попытка донести мысль, что в случаях, когда то или Read More...
  • Кризис - время искать оптимальные решения. Часть 2

    Почти всегда, начиная разговор с клиентом по поводу использования 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 и протоколы. Любопытная аналитика.
    Любопытные цифры приведены в аналитическом отчете ESG (Enterprise Strategy Group Inc.), опубликованном в начале этого года (доступен на сайте NetApp). Более половины (54%) из 329 опрошенных ответило, что, после внедрения решеня серверной виртуализации, объемы хранения увеличились (причем ответ “свыше 20%” дали 18% от этого количества). 68% ответивших считают, что FibreChannel есть “технология, предлагающая максимальную производительность” (и всего [...]
  • «Передний край» – iWARP
    Что есть что на горизонте. Стремительное продвижение технологий в повседневность IT-служб иногда поразительно. Сегодня, когда интерфейсы Gigabit Ethernet устанавливаются уже даже в ноутбуки, реальностью становится 10Gigabit Ethernet, который еще пару лет назад был чем-то из области лабораторных изысканий. Что же принесет нам этот виток скоростной гонки интерфейсов – давайте посмотрим. RDMA RDMA это Remote DMA. Для тех, кто [...]

This Blog

Syndication

Powered by Community Server (Personal Edition), by Telligent Systems