Главная Storages, Новое Кризис – время искать оптимальные решения. Часть 2
  • Кризис – время искать оптимальные решения. Часть 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/

Комментарии

  1. Хорошая статейка, действительно, встречался с тем,что давайте поставим FC,а то у нас базы чет медленно обрабатываются.

    У меня только в одном месте FC (кое-как) оправдывает себя. На полке СХД из 12 SCSI.

  2. Из статьи не совсем понятно, за что нужно платиь (функции/опции) лицензируя FC?
    Для объективности, есть вендоры у которых можно свободно скачать MPIO с сайта без всяких ограничений.

  3. > действительно, встречался с тем,что давайте поставим FC,а то у нас базы чет медленно обрабатываются.

    На самом деле я понимаю откуда такое идет. С точки зрения банальной логики, от штуки, которая стоит вдесятеро сверх нормальной цены, поневоле ждешт каких-то чудес. 🙂

    FC это признак элитарности, когда сидишь в серверной и мечтаешь “Эх, а вот файбер ченнэл бы… (Мерс SLK, гитару Фендер стратокастер с комбом) вот тогда бы все залетало (заиграло, все бы девки – мои).

    Но на практике оказывается, что Файбер ченнэл – есть, а счастья – нет. 🙂

  4. > Из статьи не совсем понятно, за что нужно платиь (функции/опции) лицензируя FC?

    Есть вендоры, у которых использование протокола FC стоит денег. Впрочем в данном бюджете не принципиальных. Дело в том, что данный текст взят с моего блога, посвященного конкретным решениям конкретного вендора, поэтому я про этот аспект и упомянул.

    > Для объективности, есть вендоры у которых можно свободно скачать MPIO с сайта без всяких ограничений.

    Есть такие, есть и другие, всякие есть. Опять же, после пары HBA в каждый хост и FC-коммутаторов это незначительные траты, обычно.

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

    Дисковая очередь больше 2 указывает на то, что дисковая подсистема перегружена. Откуда вывод, что при очереди 8-9 имеем слабо нагруженную дисковую подсистему? Данное утверждение будет верно только при использовании софтового RAID-массива, построенного средствами операционной системы на 5 физических дисках.

  6. Скорость передачи сигнала, и частота несущей частоты вот упущение в данной статье ,
    скорость передачи у всех примерно равна , а несущяя отличается в зависимости от стандарта передачи 10Мбит 100 1000 10000 , чем выше скорость передачи тем выше несущяя, и тем меньше задерка на передачу 1 байта…
    поэтому если канал не загружен , это не значит что скорость не узкое место …