• Почему не всегда переход на 8Gb FC действительно ускоряет работу приложений?

    3n03kc3lc5T15W45R2a8m6fc393eb3c801943Простая как мычание формула “быстрее – значит лучше” завладела умами в 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-инфраструктура может стать ежедневным источником головной боли, и непрекращающейся борьбы с загадочно вылезающими то тут, то там проблемами. Следует трезво понимать и представлять себе такую опасность, и быть готовым к ней. А как первый шаг – задаться вопросом из другого рекламного ролика: “А если не видно разницы – то зачем платить больше?”

  • Главная Storages, Новое Fibre Channel, iSCSI, NAS, NetApp, SAN
    • NAS & SAN

      Kids__6_Bin_Storage_Drawer NAS – Network-attached Storage, «устройство хранения, подключенное к сети» и SAN – Storage Area Network, «сеть хранения данных» – это не просто «переставленные в разном порядке буквы»;), это две концепции организации и использования сетевого хранения данных.
      Часто приходится сталкиваться с принципиальным непониманием у клиентов разницы между NAS и SAN-подключением внешнего дискового массива, преимуществах и недостатках каждого из вариантов.
      Итак,  давайте вкратце, не влезая в дебри и частности, разберемся что есть что, чем отличается друг от друга и какие плюсы-минусы есть у каждого.

       

    • Главная Storages, Новое Fibre Channel, iSCSI, Storages, мысли
      • Кризис – время искать оптимальные решения. Часть 2

        EMOTICON MONEY Почти всегда, начиная разговор с клиентом по поводу использования 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.

        Romx

        http://blog.aboutnetapp.ru/

      • Главная Storages, Новое Fibre Channel, iSCSI