Введение в системы хранения данных

    От автора



    Добрый день, хабр! А вы знаете, что продает HP, кроме принтеров? А Dell, кроме ноутбуков и мониторов? А Hitachi, кроме бытовой техники? Что общего у перечисленных компаний и EMC? Ответ кажется простым для специалистов, но не так очевиден для среднего IT-специалиста.

    Все перечисленные компании продают (в т.ч.) системы хранения данных. Какие системы? Да, по своему опыту я убедился, что познания в области хранения данных большинства знакомых мне IT-инженеров заканчиваются в области RAID. Так родилась идея написать эту статью, или даже несколько. Для начала мы рассмотрим ряд технологий в области управления информацией, отметим, какие существуют подходы к хранению данных и почему каждого из них оказывалось недостаточно. Здесь описываются базовые принципы DAS, NAS и SAN, поэтому специалистам эта статья будет, скорее всего, бесполезна, если же вам эта тема не близка, но интересна, добро пожаловать!


    Введение


    Цель статьи – рассмотреть концептуальные основы подходов к построению систем хранения данных. Здесь намеренно не приводится технических характеристик, т.к. к сути они отношения не имеют. Дабы статья не выглядела рекламной брошюрой, не будет и названий продуктов, а также степеней «хороший» и «не имеющий аналогов». Исчерпывающей статью также назвать нельзя, наоборот, я постарался охватить минимально-достаточный материал, доступный для понимания среднему инженеру, никогда не имевшему дело с СХД. Итак, начнем.

    DAS (Direct Attached Storage)


    Эта вещь вам давно знакома. Вспомним схему работы с диском обычного PC: материнская плата соединяется с HDD посредством интерфейсов ATA/SATA. Вы уже давно все это знаете, а значит представляете, что такое DAS. Точнее, вы понимаете, что такое архитектура DAS внутреннего типа. Существует также архитектура DAS внешнего типа, которая отличается от внутренней допустимым расстоянием между, вообще говоря, несколькими серверами и устройством хранения.

    external DAS

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

    Из принципиальной простоты архитектуры DAS следуют основные ее преимущества: наименьшая цена по сравнению с остальными, рассмотренными ниже и относительная простота внедрения. Кроме того, такой конфигурацией легче управлять ввиду хотя бы того, что число элементов системы мало. Целостность данных в DAS обеспечивается применением старой и популярной технологии RAID.
    Однако такое решение подойдет для относительно некритичных задач и ограниченного числа рабочих станций. Совместное использование конечных вычислительных ресурсов накладывает ряд ограничений. Количество одновременно подключенных машин не превышает числа портов в устройстве хранения, ограниченная пропускная способность увеличивает время чтения-записи (IO), неэффективное использование кеша и т.д.

    Частично проблемы производительности могут быть решены парком серверов (например разделенные по типу обрабатываемых запросов), каждый из которых нагружает отдельное устройство хранения.

    parallel external DAS

    Однако и у этой схемы начинаются трудности, когда возникает необходимость разделять данные между серверами, или объем занимаемой памяти оказывается неравномерным. Очевидно, что в таких условиях DAS не отвечает требованиям масштабируемости и отказоустойчивости, по этой причине были придуманы NAS и SAN.

    NAS (Network Attached Storage)


    Представим себе сервер в локальной сети, который не делает ничего, кроме как расшаривает свои папки. Это практически и есть NAS. Да, NAS – это всего лишь устройство для файлового обмена в IP сети. Минимальная конфигурация NAS выглядит так:

    NAS

    О структуре. NAS-устройство (файл-сервер) – это выделенный высокопроизводительный сервер, имеющий собственную ОС, оптимизированную для операций чтения/записи. Сервер имеет несколько сетевых интерфейсов для связи с IP сетью и устройством хранения: GigabitEthernet, FastEthernet, FDDI и проч. Кроме того, NAS обладает большим объемом оперативной памяти, большая часть которой используется как кеш, что позволяет выполнять операцию записи асинхронно, а чтение ускорить за счет буферизации. Таким образом, данные могут долгое время находится в оперативной памяти, не попадая на диск.

    Storage (дисковый массив) – то, что чаще всего изображается в статьях, где речь идет о дата-центрах. Другими словами это шкаф (стойка) с дисками, соединенный (или интегрированный) с файл-сервером. Интегрированный? Да, NAS может быть отдельным сервером (как на рисунке) или входить в состав цельного устройства. В первом случае имеем дело с gateway реализацией NAS, во втором – с монолитной системой. О gateway реализации мы еще вспомним, когда будем говорить о SAN.

    Как работает NAS? NAS поддерживает работу с протоколами шаринга CIFS и NFS. Клиент монтирует у себя файловую систему, предоставляемую NAS'ом и выполняет операции чтения/записи в обычном файловом режиме, а сервер NAS их обрабатывает, переводя на язык блочного доступа, понятный стораджу. Кроме этого, поддерживаются такие протоколы, как FTP, DFS, SMB и т.д.Вот и весь NAS… быстро и вкусно.

    Какой профит от использования NAS и почему типовому решению нужно отводить целый класс? Во-первых, операции IO занимают меньше времени, следовательно, NAS работает существенно быстрее, чем сервера «общего назначения», так если в вашей архитектуре есть сервер, который должен отдавать много статики, стоит подумать об использовании NAS. Во-вторых, централизованное хранение проще в управлении. В-третьих, общее увеличение емкости NAS происходит прозрачно для клиентов, все операции добавления/удаления памяти скрыты от потребителей. В-четвертых, предоставление доступа на уровне файловой системы позволяет вводить понятие привилегий rwx. Забегая вперед, можно отметить, что при помощи NAS без ущерба пропускной способности легко организовать мультисайтововсть (о том, что это такое мы расскажем, когда речь пойдет о репликации).

    Но есть и ряд ограничений, связанных с использованием NAS. В основном это связано с базовым для NAS принципом. Сама по себе избыточность TCP/IP как протокола доступа к данным приводит к накладным расходам. Высокая нагрузка на сеть с довольно ограниченной пропускной способностью увеличивает время отклика. Производительность системы в целом зависит не только от NAS, но и от качества работы коммутирующих устройств сети. Кроме того, без правильного resource allocation, клиент, запрашивающий слишком большие объемы файлов, может влиять на скорость работы других клиентов

    SAN (Storage Area Network)


    Здесь аналогии с enthernet я не придумал :(. SAN (сеть хранения данных) – это инфраструктура блочного хранения данных, построенная на базе высокоскоростной сети.

    Как видно из определения, основное отличие от NAS заключается в предоставлении доступа к данным на блочном уровне. Если же сравнивать SAN и DAS, ключевым понятием здесь является сеть. Так, среди основных компонентов SAN те же компоненты, но от прочих архитектур ее отличает наличие специальных коммутаторов, поддерживающих передачу данных по FibreChannel или (Fast- GB- etc.) Ethernet:

    SAN

    История SAN начинается с конца 1980-х, когда впервые была предложена идея построения FC сети. В ранних реализациях в качестве коммутирующего устройства использовались хабы, такой подход называется управляемой петлей (Arbitrated Loop, далее FC-AL):

    SAN FC-AL

    Схема взаимодействия в FС-AL аналогична CSMA/CA: каждый раз, когда какой-либо узел в FC-AL собирается выполнить операцию IO, он посылает блокирующий пакет, оповещая всех о начале передачи. Когда пакет возвращается отправителю, узел получает полный контроль над петлей для проведения операции. По окончанию операции все узлы оповещаются об освобождении канала и процедура повторяется. Очевидно, что такая ситуация ничем не лучше DAS, а к проблемам пропускной способности добавляется еще одна: в каждый момент времени только один клиент может выполнять операцию IO. Кроме того, использование 8-битной адресации в FC-AL позволяет иметь не более 127 устройств в сети. Короче говоря, FС-AL оказался ничем не лучше DAS.

    На смену FC-AL пришла архитектура, название которой я не стану переводить: FC-Switched Fabric (FC-SW). Именно эта реализация SAN дошла до наших дней. В FC-SW вместо хаба используется один или несколько коммутаторов, таким образом данные предаются не по разделяемому, а по индивидуальным каналам.
    Как и в Ethernet на базе этих коммутаторов можно построить множество топологий, в частности, к корневому (-ым) может быть подключен другой коммутатор или хаб:

    SAN FC-SW

    Преимущества SAN очевидны:
    • общий объем памяти может расти не только за счет увеличения емкости существующих сторожей, но и за счет добавления новых;
    • каждый хост может работать с любым устройством хранения, а не только со своим, как в случае с DAS;
    • сервер имеет несколько «путей» получения данных (multipathing), поэтому, при правильно построенной топологии, даже после выхода из строя одного из коммутаторов система останется рабочей;
    • есть такая опция, как Boot From SAN, это означает что серверу теперь даже не нужен собственный загрузочный диск;
    • существует опция zoning, позволяющая разграничивать доступ серверов к ресурсам;
    • отчасти решена проблема с пропускной способностью – отчасти, т.к. узким местом по-прежнему остается канал между устройством хранения и коммутатором, однако, такие операции, как например резервное копирование не оказывают влияния на всю сеть.

    Еще одно важное преимущество SAN, о котором нужно сказать отдельно. Гибкая архитектура и предоставление доступа на блочном уровне позволяют построить множество различных решений в зависимости от задачи. Например, если мы снабдим один из серверов специальной ОС, мы получим не что иное, как gateway-реализацию NAS (см. рис. выше), таким образом в рамках решения для одного предприятия могут сочетаться и DAS, и NAS, и SAN.

    Но нельзя без ложки дегтя. Один из главных недостатков SAN – это цена. Оставим цифры маркетологам, отметим только что SAN могут себе позволить далеко не все.

    Вместо заключения


    Очень кратко были рассмотрены основные подходы к построению систем управления данными. Здесь не затронуты такие понятия, как IP SAN или CAS, ничего не сказано про iSCSI и про технологии передачи в целом – пока оставим это для самостоятельного чтения.
    Очень поверхностно сказано о защите данных от потерь, способах резервного копирования, что делать, если сгорел датацентр, короче говоря о внештатных ситуациях (disasters) – они-то и станут предметом нашего следующего обзора.
    Спасибо, что были с нами.
    Dell Technologies
    Компания

    Комментарии 61

      +2
      Эх… теория… картинки… а в реале все гораздо интересней!!!
        +3
        > Но нельзя без ложки дегтя. Один из главных недостатков SAN – это цена. Оставим цифры маркетологам, отметим только что SAN могут себе позволить далеко не все.

        А NAS (Celerra, например), надо полагать, может позволить себе любой голодранец?
        Да-а, я ожидал более серьезного подхода к вопросу от коллег из EMC. :-}
          –3
          Я могу прямо сейчас собрать — воткнуть винт и память в валяющийся P4, загрузить ось и расшарить винт по сетке. Или в модем с роутером usb-флэшку воткнуть, она автоматом расшарится. Это разве будет не NAS по определению? Я думал просто шара, а оказывается NAS :)
            +4
            А я могу прямо сейчас собрать — воткнуть винт и память в валяющийся P4, загрузить ось, с установленным на нем iSCSI target или COMSTAR FC target, и получить «SAN по определению», и что?
            Речь-то не об этом.
            0
            а при чем здесь Celerra? в начале статьи я указал, что не буду упоминать названий продуктов, а в конце еще раз отметил, что цены — это область маркетинга. но если вы настаиваете: начнем с того, что NAS — это не Celerra, а решение, цена которого сильно зависит от вендора и возможностей. более того, если говорить именно про Celerra — это семейство продуктов, среди которых есть решения и для среднего бизнеса, стоимость которых не идет в сравнение с тем же Symmetrix.

            так что мимо. странно, ожидал от коллег из нетап комментариев по существу.
              +5
              Ну Celerra же NAS, не так ли? :) Тогда к чему это разделение на «SAN, который дорогой (и, читай „для взрослых“), и это… как его… ну это… NAS» ;)

              Позвольте, я дам очень простое определение тому, что такое SAN, и что такое NAS, и где они раздляются, а вы со мной, уверен, согласитесь.

              Все очень просто: все зависит от того, на какой стороне образуется файловая система. Если на стороне стораджа, то это NAS. Если на стороне хоста — SAN.
              И нет никакого разделения на «дешевое» и «дорогое». Может быть наколенный «SAN» на iSCSI, и может быть сверхдорогой NAS, в виде какого-нибудь Isilon (специально, как вы понимаете, подбираю из вашей области названия;)

              Вообще, позвольте, по дружески, по коллежьему, вообще поклевать печень. Ну что это вообще такое? Перестраиваться уже надо, новое мЫшление должно быть, в связи с закапыванием Clariion и курсом на VNX. :)

              > В основном это связано с базовым для NAS принципом. Сама по себе избыточность TCP/IP как протокола доступа к данным приводит к накладным расходам.

              Выше я уже показал, что нет никакого «базового принципа NAS, связанного с TCP/IP». iSCSI не становится меньше SAN-протоколом, оттого, что ходит поверх «избыточного TCP/IP».

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

              Снова укажу пальцем. Высокая нагрузка на сеть с ограниченной пропускной способностью _не_ есть свойство NAS. Это просто кривая сеть. Используйте сеть с высокой пропускной способностью и с низкой нагрузкой, и этой проблемы не будет. Следовательно — это не проблема NAS, а проблема сети.

              > Производительность системы в целом зависит не только от NAS, но и от качества работы коммутирующих устройств сети.

              Из этого можно сделать вывод, что SAN полностью свободна от негативного влияния низкого качества коммутирующих устройств в сети? ;)

              > Кроме того, без правильного resource allocation, клиент, запрашивающий слишком большие объемы файлов, может влиять на скорость работы других клиентов

              Снова это не о NAS, а о настройке сети.

              Да, в отношении NAS есть такой нелепый предрассудок, что если мы расшариваем интернет через дэлинки и реалтеки, то и для NAS они пойдут, «чо там, эзернет же», что и порождает глубоко укоренившееся заблуждение, что NAS это «фаловая помойка», «торренты качать, пока ноутбук выключен» и ни на что другое он не пригоден «то ли дело SAN!» (произносится с завистливым придыханием). Выше я постарался показать, что причина вовсе не в NAS или SAN.

              Равно как и нельзя делить «дешевый NAS» и «дорогой SAN». Сторадж дешевый и дорогой не оттого, кто делает файловую систему. Любой сторадж, и NAS, и SAN может быть и дешевым и дорогим.

              Согласны ли вы со мной?
                0
                я с вами практически полностью согласен, благодарю за развернутый комментарий :)
                по определению SAN-NAS можно спорить, но в целом идея верная.
                да, Isilon — это дорого. очень. пожалуй, тут вы действительно правы, сравнение цен SAN и NAS как таковых некорректно.

                iSCSI не становится меньше SAN-протоколом, оттого, что ходит поверх «избыточного TCP/IP».
                говоря об избыточности, я имел ввиду накладные расходы на синхронизацию канала и малый размер пакета, и, как следствие, расходы на обработку малых пакетов. по этой причине разрабатываются новые протоколы (с бОльшим размером пакета) и в ряде случаев предпочтение отдается FibreChannel

                Из этого можно сделать вывод, что SAN полностью свободна от негативного влияния низкого качества коммутирующих устройств в сети? ;)
                нет, но здесь следует иметь ввиду, что мы говорим о выделенном и специализированном сетевом оборудовании — естественно, сам по себе SAN еще ничего не обещает. да, все зависит от оборудования и настройки, однако, разделять понятия «NAS» и «сеть» в данном случае некорректно.
            0
            Как раз такой теории в интернете полно, хотелось бы более конкретных статей про системы хранения! Конечно это чисто мое мнение.
              0
              отчасти с вами согласен. отчасти, т.к. внятный материал на русском есть пожалуй что по SAN, а на хабре данная тема развита слабо. в любом случае — это начало, базис, на котором далее можно будет говорить более предметно.
                0
                Тогда выскажу свои пожелания, мне бы интересно было бы почитать как раз о выборе системы хранения, когда уже стандартных возможностей железного райда становиться мало или скорее всего хочется чего-то более производительного. Например: Имеется пару серверов(debian) c виртуализацией(kvm+openVZ) сервисов, хотелось бы общее хранилище с достаточной производительностью например по FC(все находиться рядом), тут как раз встает выбор SAN хранилища и FC адаптеров, хотелось бы как раз примеров(возможно даже описания настроек) реализаций таких систем. Именно это не понятно системным администраторам которые переходят из SMB сектора в более высокий эшелон, так как не всегда есть возможность потрогать технологии до покупки, а после бывает возникает много вопросов совместимости или не правильного выбора. На сайтах производителей в основном лишь промо материал, который не дает решения конечной цели.
                  0
                  спасибо за ваш комментарий. одна из основных целей данной статьи — выявить предметную заинтересованность в области хранения данных. ваше пожелание будет адресовано в отдел прикладных решений, думаю, что в рамках NDA мы сможем опубликовать несколько примеров с блекджеком и графиками.
                    0
                    Заинтересованность есть офигительно какая. Могли бы и так спросить. Нужно: дёшево, опенсорсно, надёжно, с сетевой репликацией и защитой от split-brain.

                    Пока я наткнулся на основную проблему: нет адекватных производителей SAS HBA на рынке. HP пытался что-то предложить, но слился, LSI поддерживает только rpm (RHEL/SUSE), на адаптек без слёз смотреть невозможно.

                    Что там ещё есть-то?
                      0
                      Когда чего-то на рынке нет, для меня это первый признак, что, хотя этого, вы «хотите странного».
                      Я не сторонник теории заговоров, что Adaptec, LSI и десятки нонеймов втайне сговорились, чтобы «зажимать» технологии и лишать себя прибыли.

                      Может быть это просто не нужно никому, потому и нет?
                        0
                        Что странного в желании видеть SAS HBA? У LSI просто не поддерживается debian, так что его установка чуть сложнее. У adaptec'а HBA не обеспечивают нужные параметры работы.

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

                    Я бы на вашем месте вообще не рассматривал вендоров, которые не дают пощупать оборудование в триал.

                    > мне бы интересно было бы почитать как раз о выборе системы хранения, когда уже стандартных возможностей железного райда становиться мало или скорее всего хочется чего-то более производительного. Например: Имеется пару серверов(debian) c виртуализацией(kvm+openVZ) сервисов,

                    Кстати, в блог NetApp заходите сегодня днем, там будет новая статья именно про это. :)
                      0
                      >Кстати, в блог NetApp заходите сегодня днем, там будет новая статья именно про это

                      Буду весь день мониторить блок, может как раз будет что нужно начинающим пользоватям систем хранения

                      >Я бы на вашем месте вообще не рассматривал вендоров, которые не дают пощупать оборудование в триал

                      Вообщем может быть и в МСК нету с этим особых проблем, а вот на урале обычно с этим проблемы, так как все привозиться под заказ.
                        +2
                        Ох, да, извините, сам ненавижу этот пресловутый московский центропупкизм :(
                        Увы, есть такая беда с «немосквой». :(

                        С другой стороны… Вы платите только за транспортировку взятого в Москве стораджа в два конца. Это может быть совсем немного, если прикинуть к цене покупки?
                        Почем у нас стоит доставить на Урал автотранспортом 30 килограмм?
                          0
                          Да конечно это вариант, думаю окло 2к в одну сторону стоит, хотя такой способ прибавляет много лишней головной боли(бумаги+обьяснить руководтсву зачем нам тратить деньги на пересылку туда обратно, без возможного коненчого результата). И если компания продавец готова на такое, то думаю это для нее большой + для нее!
                          • НЛО прилетело и опубликовало эту надпись здесь
                        0
                        Кстати, в блог NetApp заходите сегодня днем, там будет новая статья именно про это. :)
                        какая дерзкая реклама в блоге EMC однако :)…
                          +2
                          Чорт, меня заметили. :)

                          На самом деле, с тех пор, как корпоративные блоги «выпилили» из дефолтной выдачи на главной, все эти блоги, и NetApp, и EMC, потеряли кучу читателей, которые могут просто не знать о появлении новой статьи, если не переключатся на режим отображения «Все».
                          Хотите, я буду также рекламировать вас? Все же в одном корыте мы тут все, против всяких самодельных «хоронилищ данных»на трехтерабайтных дисках в RAID-6, в корпусе из упаковочного картона. :)
                            0
                            Хотите, я буду также рекламировать вас?
                            ну если в положительном ключе — можно только приветствовать :)
                              0
                              Мы буквально в одном шаге от подписания локального пакта о ненападении в рамках Хабрахабра :)

                              Договорились :)
                  –2
                  Вы бы цифры привели (а в идеале еще и какие-нибудь абстрактные цены), а то непонятно, за что переплачивать при установке всех этих NAS. Не проще ли просто сервер с 4 хорошими HDD + 1/10 Гб канал до него поставить? Так же, хорошо бы обосновать такое утверждение:

                  > Сама по себе избыточность TCP/IP как протокола доступа к данным приводит к накладным расходам.

                  Это как? Пропускная способность дисковой системы выше пропускной способности сети? Цифр не хватает.

                  Плюс, где-то было упомянуто использование кеширования дисковых операций в сторадже. Операции записи тоже кешируются в ОЗУ? А надежно ли это?

                  Также, не освещена проблема восстановления данных при отказе устройства хранения.

                  В общем, без цифр это все выглядит неаргументированно, и впечатления не производит, а просто смотристя как статья в стиле «наши системы хорошие и дорогие, так что покупайте у нас». Товарищи, мы же все-таки на Хабре. Тут словами «гигабит в секунду» никого не испугаешь.
                    +1
                    о цифрах говорить имеет смысл, когда есть конкретная задача и конкретные требования. в ряде случаев действительно нет никакого смысла переплачивать, если можно обойтись 1 сервером с «хорошими» HDD. абстрактно можно лишь сказать, что например NAS ускоряет операции файловой системы в разы.

                    хорошо бы обосновать такое утверждение
                    см. выше.

                    Операции записи тоже кешируются в ОЗУ? А надежно ли это?
                    да, операции записи тоже кешируются, т.е. записанные вами данные могут вообще до диска не дойти, если были помечены на удаление раньше. здесь кроется опасность: что произойдет с данным в кеше, если возникнут проблемы с электричеством? На этот случай, как правило, предусмотрен автономный источник питания, позволяющий в аварийном режиме сбросить весь кеш на диск. Но и с этим источником могут начаться проблемы, в конце концов, его заряда может просто не хватить до устранения проблем. Можно использовать резервный ИБП, но и он не лишен перечисленных проблем, поэтому без использования внешних инструментов обеспечить целостность данных невозможно. О том, как из такой ситуации выйти при помощи внешних инструментов, речь пойдет в следующей статье.
                      0
                      Мой негативный опыт общения с адаптеком говорит, что основная проблема с wb-кешем не в перебоях с электричеством, а в сбое промежуточного оборудования/драйверов.
                      +3
                      > Не проще ли просто сервер с 4 хорошими HDD + 1/10 Гб канал до него поставить?

                      Кастомеры, которым уже мало стораджа, допустим, на пару сотен дисков, читают ваше «сервер с 4 хорошими HDD» со смесью ностальгии и зависти :)

                      > Это как? Пропускная способность дисковой системы выше пропускной способности сети?

                      Запросто. Что вас удивляет?

                      > Операции записи тоже кешируются в ОЗУ? А надежно ли это?

                      Настолько, насколько надежна вообще операция записи в память.

                        0
                        Хотел было найти и запостить любимую картинку с трехдюймовым флопиком и надписью на нем черным маркером «Все что было на компьютере», но увы, уже не находится. :)
                      0
                      Хм, думаю что подобного рода инфу любой желающий найдет в вики.
                      А вот чего нет — так это типовых решений: video streaming storage, db server, static server.
                      Точнее лично мне было бы интересно что появилось новое — дешевое или продвинутое за последние 2-3 года.
                      Вот в свое время анонсировались некие NFS blade сервера, типа быстро и дешево для баз данных или статики.
                      Ну или как поставить дома видео стриммер на гиг :)
                        +2
                        Вы определитесь, либо «дёшего», либо «fc». Они взаимно исключающие.
                          0
                          я разве говорил 'fc'?
                          но «дешево» бывает разное и FC тоже бывает недорогой.
                          вообще без задачи и цифр разговор «в пользу бедных»
                            +2
                            Ок, даю бюджет дешёвого iscsi:

                            любой сервер с шестью-восмью sata'шными дырками. (пусть, 8). 8 SATA'шных винтов RE/NS серии, или рапторы.

                            Линк по двум гигабитным портам в multipath.

                            Расходы:

                            сервер: сколько не жалко, допустим $1500
                            Диски: примерно $1200
                            Гигабиты — в комплекте с сервером — $0
                            Два гигабитных порта на любых свичах, можно даже неуправляемых — около $20 (по $10) на каждый.
                            Лицензии на mdadm: $0
                            Лицензии на iscsi-target: $0
                            Лицензии на iscsi-initiator: $0
                            Лицензии на multipathd: $0

                            Ваш вариант? Заметим, указанный выше вариант легко скейлится до 10G и любого числа винтов.
                              +1
                              Зарплату amarao и его сменщика забыли приплюсовать к цене решения ;)
                                0
                                Предполагается, что купив fiber channel меня можно увольнять, а работать оно будет святым духом? Нет. Значит, в данном случае это константа не влияющая на цену решения.
                                  0
                                  Константа, но совсем другого порядка.
                                  В непрофильных компаниях системы хранения эксплуатируют, зачастую, совсем не специалисты, чаще всего умеющие, главным образом, поднять кейс в вендорском саппорте, и сделать что напишут. И ничего, работают компании.
                                    0
                                    Ага. Тут недавно один из наших клиентов, доверившийся такому саппорту, клиентов больше 12 часов лежал. Вместо того, чтобы за пол-часа всё сделать.
                                      0
                                      А сколько ваших конкурентов, доверившихся такому саппорту, не лежало, их не больше ли будет?
                                        0
                                        Не знаю. Извините, статистики нет. Но я исхожу из принципа, что компании, в которых работают сотрудники, не понимающие как используемые ими технологии работают, проигрывают тем, в которых работают те, кто понимает.

                                        Возможно, я ошибаюсь, и офисный плантон может работать лучше толковых специалистов.
                                          0
                                          > Не знаю. Извините, статистики нет.

                                          Ну просто из соображений здравого смысла? ;)

                                          > Возможно, я ошибаюсь, и офисный плантон может работать лучше

                                          В своей области — безусловно да. Просто вы впадаете в обычный IT-шный центропупкизм. _Не все_ компании в мире, использующие системы хранения данных, это IT-компании. Я бы даже сказал, что IT-компаний среди них меньшинство.
                                            0
                                            Ну проблемы «абстрактных хомячков» в вакууме я не могу оценить, но могу примерно сказать, что цены от EMC c лихвой перекрывают з/п специалиста, а специалист всё равно нужен (если вообще нужен). Если специалист не нужен, то тут EMC очень трудно с dlink, levelone и foxconn конкурировать.
                                      0
                                      Пардон, «один из наших конкурентов».
                                  0
                                  Вы вообще читать умеете?
                                  Где задачи, где цифры производительности?
                                  Сторадж — это вам не тумбочка что бы оценивать по красоте.

                                  «легко скейлиться до 10G» — означает что вы его даже не пробовали нагрузить на 1G полноценно.
                                    0
                                    Легко скейлится до 10G означает, что у меня оно на 10G, но я не вижу проблем с переводом его на 1G.
                            +1
                            Фантастически дорого.

                            И ни слова про iscsi over 10G, заметим… А ведь стоимость 10G инфраструктуры (а местами там даже 1G достаточно) просто смехотворная на фоне FC — при вполне сравнимых результатах.

                            всё, что может предложить FC — уже в iscsi есть. Местами «из коробки», местами с помощью тривиального допиливания через multipathd.
                              +3
                              EMC-NTAP срач! ура-ура (+
                                0
                                Не дождетесь :)
                                0
                                К слову о DAS. Стоят у нас полочки Promise VessJBOD 1730 в паре с контроллером Promise Supertrak EX8658 и HP MSA 60 c HP P411/1Gb. Вполне бюджетные, надёжные, и во многих случаях достаточные решения. И кстати это не «SCSI и FC», а вполне даже SAS. Соединение между полками и контроллерами по MiniSAS кабелю (SFF8088).
                                  0
                                  Ключевое слово «достаточные решения».
                                  Когда задача — перевезти на сто метров полтора десятка кирпичей не нужно не только покупать самосвал, но и вообще автомобиль, вполне достаточно ручной тачки.
                                  Но это не значит, что ручная тачка это подходящее решение для замены автомобиля (в любой ситуации).
                                    0
                                    Так я и написал «во многих случаях». Есть много контор, у которых нету денег, а полтора десятка кирпичей как раз валяются. Просто в самой статье информация о DAS предоставлена в ключе «старое, убогое, медленное — короче проехали». ИМХО рановато хоронить DAS.
                                      0
                                      Просто в самой статье информация о DAS предоставлена в ключе...
                                      Вам показалось. Никто DAS не хоронит, о недостатках сказано затем, чтобы было понятно, зачем люди придумали SAN.
                                  +1
                                  Как выглядит сферический клиент в вакууме, которому могут понадобится описанные в статье решения? Если не брать уж очень крупных. На ум сразу вспоминается картинка image
                                  За что люди платят деньги, покупая столь дорогие решения?
                                    0
                                    За спокойный сон.

                                    PS. Предлагаю этой картинке уже присвоить почетное наименование «IT-баян».
                                      0
                                      <img src="" alt=«image»/>

                                      Извините, не сдержался. :)
                                        +1
                                        Во-первых неправильно, цена проезда на автобусе на единицу человека/груза будет меньше.

                                        Во-вторых именно по этой причине возят на газелях, а не на S500.
                                          0
                                          Да если бы там, в этой картинке (в оригинале), только эта нелепость была…
                                            0
                                            Аргументов так и не привел ни кто конкретных. Вы знаете о чем речь, а я пока нет.
                                              0
                                              А каких вам еще аргументов не хватает?

                                              Ответьте на вопрос самому себе, отчего сто километров можно проехать на Порше Панамера, автобусе Volvo и самосвале Камаз, а также в сто раз дешевле перечисленного на ВАЗ-«копейке», но все равно есть люди, которые покупают Порш, автобус или самосвал, затем поменяйте «автомобиль» на «систему хранения» и получите ответ для системы хранения.
                                                0
                                                Предположим мне нужно ехать на 1500км в тайгу, где болото и нет дороги. Я покупаю внеорожник, подгатавливаю его к этому и еду. Внедорожник и подготовка меняем на OpenSource software. Я лишь дважды сталкивался с людьми, которые покупали СХД и все они были чем-то не довольны.
                                                  0
                                                  Ничего удивительного, люди вообще всегда чем-нибудь да недовольны, некоторые даже недовольны всегда и всем.
                                                    +1
                                                    ЗЫ.
                                                    > Я лишь дважды сталкивался с людьми, которые покупали СХД

                                                    Даже не знаю как прокомментировать. Это очень серьезная выборка для того, чтобы сделать вывод :)

                                                      0
                                                      По этому я и спросил, кто типичный покупатель, т.к. живьем я их не видел.

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                      Самое читаемое