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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Brocade Fabric OS 7.x Compatibility Matrix ^[2]

• VMware Compatibility Guide ^[3]

• NetApp Interoperability ^[4]

• QLogic Storage Networking Interoperability ^[5]

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

О расстоянии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итого

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

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

• Brocade – Основы проектирования SAN ^[10]

• Конвергентные платформы HP для виртуализации ^[11]

• Comparing VMware Virtual SAN with Microsoft Clustered Storage Spaces ^[12]

• Storage virtualization vs software-defined storage ^[13]

Автор: Сервер Молл

Источник ^[14]