Конспект админа: корпоративные SAN и самое главное в работе архитектора (обновлено)

    image alt text


    В прошлой статье я рассказал об основных понятиях SAN на примере небольших инсталляций. Сегодня копнем глубже и разберемся с построением сетей хранения для крупной организации. Разумеется, одна короткая статья никак не заменит объемные труды Brocade и HP, но хотя бы поможет сориентироваться и выбрать правильный курс при проектировании.


    При построении крупных сетей хранения основной головной болью становится архитектура решения, а вовсе не типы оптики и производители коммутаторов. Узлов-потребителей значительно больше и многие из них критичны для бизнеса, поэтому использовать простую схему "подключил несколько серверов к хранилищу напрямую, да и все" не получится.


    Пара слов о топологиях и надежности


    Если немного упростить, то "большая" сеть SAN отличается от маленькой только надежность и, в меньшей степени, производительностью. Базовые технологии и протоколы аналогичны тем, что применяются в сетях из нескольких серверов. Как правило, отдельные сети SAN называют фабриками – в одной организации свободно может находиться с десяток фабрик.


    В инфраструктуре уровня Enterprise балом по-прежнему правят протокол Fibre Channel и оптические линии. Последние годы активную экспансию ведут конвергентные решения, но о них я расскажу чуть позже.


    Под спойлером спрятаны основные топологии SAN, чтобы немного освежить знания
    • Каскад. Самая ненадежная топология, которая иногда применяемая с небольшим количество узлов.
      image alt text
      Устройства последовательно подключены друг к другу, что дает больше точек отказа и увеличение нагрузки при масштабировании. Частным случаем каскада можно назвать подключение точка-точка, когда СХД подключается напрямую к серверу.


    • Кольцо. Тот же каскад, но оконечный коммутатор соединен с первым. Надежность и производительность больше, ведь протокол FSPF (Fabric Shortest Path First) поможет выбрать кратчайший маршрут. Однако, работоспособность такой сети часто нарушается в процессе масштабирования и не гарантируется при обрыве нескольких линков.
      image alt text


    • Полный граф (full mesh), где каждый коммутатор соединен с каждым. Такая топология обладает высокой отказоустойчивостью и производительностью, но стоимость решений и возможности масштабирования оставляют желать лучшего.
      image alt text
      Граф удобно использовать для связи пограничных коммутаторов нескольких площадок.


    • Ядро-периферия (core-edge). На практике используется чаще всего и по своей сути аналогична привычной сетевой топологии "звезда".
      image alt text
      В центре размещаются несколько коммутаторов (ядро сети), к ним подключаются периферийные коммутаторы с оконечными устройствами. Решение выходит отказоустойчивым, производительным и хорошо масштабируемым.


    Основной схемой построения SAN в большинстве случаев является Core-Edge, с несколькими зарезервированными коммутаторами в центре. Рекомендую использовать в первую очередь ее, а всякую экзотику сохранить для нетипичных случаев. Кстати, кольцо, несмотря на свою моральную ветхость, активно используется внутри систем хранения для соединения дисков с контроллерами.


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


    Памятка, на всякий случай

    Единая точка отказа – это любой компонент системы, чей выход из строя нарушает работоспособность всей системы самым радикальным образом. Таким компонентом может быть не зарезервированное сетевое соединение, единственный контроллер в системе хранения или коммутатор SAN.


    Основная работа проектировщика сети хранения заключается в том, чтобы построить сеть без единой точки отказа, в которой оптимально сочетаются масштабируемость и стоимость. В качестве отправной точки выбирают построение двух независимых фабрик для подстраховки друг друга. Называется такое решение "резервированная фабрика", и все ее узлы подключаются одновременно к двум фабрикам с использованием технологии Multipath.


    Если что-то случается с любым важным узлом одной из фабрик, то обмен данными происходит через ее дублера, без каких-либо негативных последствий. Разумеется, при построении нужно заложить в каждую фабрику некоторый запас производительности, как правило двукратный. Если этого не сделать, то при аварии может заметно просесть производительность любых использующих SAN сервисов.


    Еще один момент, который стоит принимать в расчет, называется SAN Oversubscription.


    image alt text


    Этот труднопереводимый термин означает конкуренцию нескольких устройств за одну линию связи. Типичная ситуация: к коммутатору подключено 10 клиентов, которые обращаются к СХД в другом сегменте через единственный линк ISL (Intersite Link, канал между коммутаторами). При таком сценарии Oversubscription будет равен 10:1. Если число линков ISL увеличить до двух, то соотношение станет 5:1.


    То есть, при ситуации Oversubscription в канал пытается пролезть больше трафика, чем может осилить этот канал. Разумеется, возникают очереди на входе и падает производительность конкретных приложений. Чтобы такого не происходило, всегда оставляйте запас по пропускной способности "туннелей" между фабриками. Скорее всего, поддерживать соотношение 1:1 будет в большинстве случаев не рационально, но важно всегда контролировать этот момент при расширении сети.


    Выбор оборудования для сетей FC


    Как это обычно бывает, предпочтения тому или иному производителю – вопрос идеологический. Но есть несколько известных игроков на рынке SAN, чьи системы вы встретите в крупной сети с большей вероятностью:


    • Сетевые адаптеры QLoqic, коммутаторы и маршрутизаторы SAN от Brocade, HP и Cisco.


    • Системы хранения HP, NetApp, IBM. Разумеется, список не полный.

    Несмотря на то, что сервисы FC могут похвастаться высокой стандартизацией и долгой историей, по-прежнему действует золотое правило проектировщика: строй сеть на оборудовании одного производителя. То есть, все, что обеспечивает связь клиента и хранилища, стоит приобрести у одного производителя. Так вы избежите проблем совместимости и разнообразных "плавающих глюков".


    Если по каким-то причинам золотое правило в вашей ситуации не применимо, то обязательно сверяйтесь с таблицами совместимости от производителей оборудования:



    Лично я только два раза сталкивался с проблемами совместимости, но каждый раз это было довольно неприятно. По одному из случаев не вспомню уже конкретных участников, но у FC-адаптера стоечного сервера периодически и без всякой причины пропадали оба оптических линка (основной и резервный), приходилось вручную переподключать. Решилось, по-моему, установкой других трансиверов. А проблемные трансиверы спокойно работали в другой сети одного из филиалов компании.


    О расстоянии


    Если вы работаете на заводе или просто в большом офисном центре, то актуальным становится вопрос территориально-распределенных сетей. Банальные несколько этажей в здании могут вылиться в несколько сотен метров оптоволокна и придется учитывать технологические особенности:


    • Нужно выбирать правильные трансиверы для одномодового волокна, так как именно оно подходит для использования на больших расстояниях.


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


    • Длинные сегменты "темной оптики" (линк между двумя клиентами, в котором нет активных сетевых устройств) можно разделять на короткие с помощью тех же коммутаторов. Кстати, это популярный вариант для построения оптической сети в здании: по паре коммутаторов на каждом этаже.

    Исходя из практики, я бы рекомендовал использовать для распределенных сегментов FCoE или даже обычную TCP/IP сеть. Отказоустойчивость и синхронизацию в таком случае можно выполнять на уровне конкретных приложений.


    image alt text


    Яркий пример – MS SQL. Совсем необязательно строить 8 Гб оптическую сеть между строениями в промзоне, чтобы обеспечить доступ всех клиентов к единой базе. Достаточно организовать подключение на уровне терминального сервера или клиентской части приложения, которое использует MS SQL (1С, например). Не всегда нужно решать вопрос "в лоб" и проектировать сложную и дорогую сеть хранения.


    Гиперконвергенция, перезагрузка


    Лет 5 назад на многих технологических конференциях активно продвигалась идея конвергентной инфраструктуры. Ее преподносили как невероятное новшество и технологию построения ЦОД будущего, не объясняя толком, в чем суть. А суть очень простая – универсальный транспорт как для сетей хранения, так и для обычных LAN. То есть, нужно проложить только 1 высокопроизводительную сеть, которую можно использовать как для работа с хранилищами, так и для доступа пользователей к 1С.


    Но дьявол, как всегда, кроется в деталях. Чтобы все так и работало, потребуется специальное сетевое оборудование и конвергентные адаптеры у каждого клиента. Разумеется, эти новшества стоят довольно дорого и в простые рабочие станции их ставить не целесообразно. Поэтому идея немного трансформировалась и теперь применяется только в рамках дата-центра.


    Вообще, конвергентность как идея появилась значительно раньше, еще в Infiniband. Это высокоскоростная (до 300 Гбит) шина обмена данными с низкой латентностью. Разумеется, решение на базе Infiniband стоит значительно дороже того же FC и применяется только в действительно высокопроизводительных кластерах.

    Ключевыми особенностями Infiniband являются поддержка прямого доступа к памяти другого устройства (RDMA) и TCP\IP, что позволяет использовать эти сети как для SAN, так и для LAN.

    image alt text


    Конвергентные сети часто используются в блейд-системах, так как отлично вписываются в идею набора серверов с общими ресурсами и минимумом внешних подключений. Но сейчас в моде уже гиперконвергентные системы, где к общей идеи виртуализации сетей добавляется модульность и более гибкое масштабирование _ каждый узел в таких решениях является программно-определяемым. В качестве яркого примера можно упомянуть Cisco ASAv и модуль OpenStack Neutron.


    Если в конвергентных решениях привычные дисковые массивы еще могут использоваться, то в гиперконвергентных системах их роль определяется программно для каждого конкретного модуля. Если у вас нет каких-то особенных требований к системе хранения, вроде поддержки специфической репликации, то я бы рекомендовал присмотреться к SDS-решениям (Software-Defined Storage).


    image alt text


    Фактически, это просто сервер с набором дисков и специальным ПО. Яркие примеры: vSAN от VMware и Storage Spaces от Microsoft. В качестве аппаратной составляющей можно использовать нечто подобное с дисковой DAS-полкой. Главное, чтобы была большая дисковая корзина и достаточный объем оперативной памяти.


    У SDS часто встречается интересная технология Cache Tiering. Два и более диска разных скоростей объединяются в один дисковый пул, часто используемые данные с которого хранятся на отдельных SSD-дисках. Подобный гибрид позволяет за минимум денег получить производительность уровня all-flash массивов, хотя и с некоторыми оговорками.


    Итого


    Время "чистой классики" постепенно уходит, и разрыв между классическими СХД и решениями SDS сокращается. Например, если судить по некоторым тестам, хранилище VMware vSAN отстает от обыкновенных классических массивов того же уровня менее чем на 10%.


    Традиционно, вот небольшой список ресурсов, которые когда-то очень помогли мне в изучении технологий SAN и SDS:


    Сервер Молл
    91,83
    серверы HP, Dell и Lenovo: новые и восстановленные
    Поделиться публикацией

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

      +1
      Спасибо за статью! Конец, конечно, смазанный получился из-за упоминания о vSAN (да простит меня инженер из VMware, который сидит рядом) и аналогах.

      Аналоги Cache Tiering есть и у классических СХД. А говоря о сравнении классических стораджей и SDS стоит вспомнить, что на крупных решениях SDS проигрывает и по цене. Это основной показатель, который их сдерживает. Надо было лучше про SVC какой вспомнить)

      А так… Punk’s FC Not Dead! FC пророчат смерть уже очень давно, но переживет он еще очень многих)
        0
        Так что самое главное в работе архитектора?
          0
          Избегать соблазна сделать заковыресто и мудрено там, где можно сделать просто :)
        +1
        Насчёт oversubscription

        Этот труднопереводимый термин предполагает следующую ситуацию:

        У вас есть несколько относительно-медленных потребителей и ограниченное число портов на коммутаторе.

        Логично, что вы решаете повесить их на один порт с помощью последовательного соединения, вроде того же каскада. В качестве вариации на тему: подключение нескольких клиентов с каналами 8 Гб к отдельным портам коммутатора; а сам коммутатор подключен к сети с хранилищами недостаточно быстрым линком.

        Если скорость порта, к которому подключены все эти устройства, не позволяет одновременно обслужить всех без проседания скорости, то с высокой вероятностью у вас будут проблемы. Закон Мерфи никто не отменял.


        Это немного узкий взгляд на термин. И даже неожиданный, я бы сказал.

        Изначально под ним имеется ввиду соотношение N-портов (конечных устройств) инициаторов к E-портам (ISL) и таргетам. То есть если мы подключим к одному свичу 10 инициаторов на 10 портов и таргет на 1 порт, получим переподписку 10:1. Если же мы таргет подключим к двум портам, то уже 5:1.
        Если на пальцах совсем.
        Вендорами рекомендуется не больше 6-7:1
          0
          Действительно, стоит дополнить, спасибо! Перебрал с образностью :)
            0
            Я бы расширил еще больше и ввел переподписку по уровням — на уровне порта, свича (коммутационной матрицы) и сети (ISL линков)
            0
            решение на базе Infiniband стоит значительно дороже того же FC

            Из расчёта доллар за гигабит выходит дешевле 10 GbE, но его подключишь не к каждой железке, а FC есть везде.
              0
              коммутаторы и маршрутизаторы SAN от Brocade, HP и Cisco

              Ну Brocade с Cisco понятно — 2 разных решения, а HPE (кстати, теперь правильно HPE, а не HP) то что? Их коммутаторы всё на тех же Cisco/Brocade построены, как и тот же Dell, IBM/Lenovo, etc. Вообще я бы весь этот абзац переписал, ибо я вот, например, на своей практике встречаю больше Hitachi, нежели NetApp и HPE. Тогда уж лучше написать туда топ-10 вендоров схд.
                0
                Все верно, сколько инженеров – столько и мнений, потому как опыт у всех разный и примеры из практики тоже.

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

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