• Тестируем внешние HDD через различные подключения.

    logo

    Прочитав статью Михаила Комарова о виртуализации и активно ее комментировав, я задался вопросом: “Какой способ подключения внешнего диска все-таки быстрее? ”

  • Главная Virtualization, Без рубрики iSCSI, Live Migration, Virtualization, VMware, виртуализация, файловая система
    • Конфигурация отказоустойчивого кластера VMware vSphere

      Один из часто задаваемых вопросов – как построить отказоустойчивый кластер vSphere? На самом деле это очень просто, компания VMware прилагает огромные усилия к тому, чтобы конфигурирование ее продуктов и управление ими не занимали слишком много времени и сил у администраторов, и не требовалось запоминать трехэтажные комбинации команд. В частности создание кластерной файловой системы занимает буквально два-три клика мышкой, а дальше она автоматически подключается ко всем хостам, у которых есть доступ к соответствующему дисковому массиву.

      Постараюсь показать как же именно создается кластер высокой доступности vSphere и объяснить как он работает.

    • Главная Virtualization, Без рубрики HDD, iSCSI, Storages, VMware, виртуализация, СХД
      • Дешевое разделяемое хранилище для ESX

        Для полноценной работы почти всего функционала ESX, кроме непосредственного запуска виртуальных машин, требуется shared storage, разделяемое хранилище. Для HA и VMotion, и того, что с ними связано – DRS, Fault Tolerance.

        Но что делать если нет денег на HP EVA, NetApp и даже на Starwind iSCSI? Спасут старые добрые пингвины и старенький, уже слабый, но все еще исправно работающий сервер.

        Итак, берем сервер, очень желательно с аппаратным RAID и обязательно с гигабитной сетью, и набиваем его дисками. Программная часть: CentOS, iSCSI Enterprise Target и/или стандартный NFS сервер, идущий в комплекте с CentOS. Я взял дистрибутив, бывший под рукой, CentOS 5.3 32bit.

      • Главная 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