ITBlogs

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

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

Browse by Tags

All Tags » technology   (RSS)

  • Silent Data Corruption - неотслеженное повреждение данных
    Без технологии защиты, действующей “от двери и до двери”, повреждение данных может пройти незамеченным, и тогда процесс восстановления окажется длительным, трудным и дорогостоящим, если и вообще возможным. Без технологии проверки целостности данных на всем протяжении пути данных, такое необнаруженное повреждение может вести к неожиданным и трудноотлавливаемым проблемам.Недавняя статья в Read More...
  • Silent Data Corruption - неотслеженное повреждение данных
    Без технологии защиты, действующей “от двери и до двери”, повреждение данных может пройти незамеченным, и тогда процесс восстановления окажется длительным, трудным и дорогостоящим, если и вообще возможным. Без технологии проверки целостности данных на всем протяжении пути данных, такое необнаруженное повреждение может вести к неожиданным и трудноотлавливаемым проблемам.Недавняя статья в Read More...
  • Проблемы (и решения) Usable Space. Часть 1. Основы.
    В ближайшие несколько постов я бы хотел поговорить о некоторых аспектах usable space на системах хранения NetApp. Usable Space на NetApp, а также местоды его образования из raw, это также источник бесчисленных спекуляций наших уважаемых конкурентов (в дальнейшем "Н.У.К." ;). Я отдельно остановлюсь на "говнилках" на эту тему в отдельном посте, а пока давайте разберем фундаментальные 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.

  • Методы записи во Flash memory в SSD
    В связи с нынешней активизацией на рынке SSD и Flash, возможно кому-то будет интересно посмотреть, какие продвинутые методы применяют разработчики решений, для преодоления присущей flash-memory по своей природе ограничений на число циклов записи. Ограничения сегодня уже достаточно далеко отодвинуты, но, тем не менее, совсем сбрасывать со счетов этот фактор нельзя. Основной метод, применяемый для преодоления [...]
  • Методы записи во Flash memory в SSD
    В связи с нынешней активизацией на рынке SSD и Flash, возможно кому-то будет интересно посмотреть, какие продвинутые методы применяют разработчики решений, для преодоления присущей flash-memory по своей природе ограничений на число циклов записи. Ограничения сегодня уже достаточно далеко отодвинуты, но, тем не менее, совсем сбрасывать со счетов этот фактор нельзя. Основной метод, применяемый для преодоления [...]
  • Capacity guide
    Любопытный документ найден в форумах NetApp Communities (кстати, рекомендую. Это открытый ресурс). “Обмен дисковой емкости на зашиту данных” Хотя это руководство и для StoreVault (S-series), но изложенное там верно и для FAS. Из этого документа можно выяснить как превращается raw capacity дисков в usable capacity дискового пространства NetApp, и что вы получаете при этом взамен уменьшения пространства. [...]
  • Дедупликация. Новости и слухи.
    Мне в очередной раз на хвосте мышко притащила свежие слухи о ближайшем будущем этой темы. Во первых, многие заметили, произошел отказ от аббревиатуры A-SIS, в пользу более понятного NetApp Dedupe и просто Deduplication. Шаг естественный. Немногие сходу вспомнят, что A-SIS это Advanced Single Instance Store, еще меньше - поймут о чем речь. Переход от “инженерной” аббревиатуры [...]
  • «Передний край» – iWARP
    Что есть что на горизонте. Стремительное продвижение технологий в повседневность IT-служб иногда поразительно. Сегодня, когда интерфейсы Gigabit Ethernet устанавливаются уже даже в ноутбуки, реальностью становится 10Gigabit Ethernet, который еще пару лет назад был чем-то из области лабораторных изысканий. Что же принесет нам этот виток скоростной гонки интерфейсов – давайте посмотрим. RDMA RDMA это Remote DMA. Для тех, кто [...]

This Blog

Syndication

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