`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Коммутируемый SAS. Часть 2. Возможности

+99
голосов

Прожорливость приложений к вычислительным ресурсам плодит серверы, разбухающие данные — системы хранения. Постоянный рост объемов хранения и предложение новых видов сервиса ставит предприятия перед вызовом: обеспечить масштабируемость сетевой инфраструктуры при разумном уровне затрат. Конкурентным компаниям нужна соответствующая инфраструктура серверов и систем хранения данных: производительная, гибкая по встраиваемым устройствам, простая по логике управления и расширения.

Производительность систем хранения

В сегодняшней сетевой инфраструктуре находится место системам хранения данных с разными интерфейсами: 8Gb FC, 1-10Gb iSCSI, 6Gb SAS. У всех есть сильные и слабые стороны, а значит — сегменты оптимального использования. На эволюцию высокопроизводительных сетей хранения (SAN) сильно повлияло появление современных SSD с малыми задержками доступа. Сразу выросли требования к применяемым сетевым протоколам.

Пока в СХД стояли вращающиеся HDD, задержки доступа к данным составляли миллисекунды (и это в лучшем случае — для дисков со скоростью вращения 15K RPM). Объединение HDD в RAID-группы и кэширование контроллерами операций ввода/вывода позволяло нарастить число IOPS, но механические ограничения дисков оставались сдерживающим фактором. Не внешний интерфейс, а HDD лимитировали время отклика СХД. С приходом SSD, задержки которых составляют десятки микросекунд, выбор внешнего интерфейса и протокола передачи данных стали иметь большое значение.

Обладая куда большим запасом по IOPS, чем HDD и намного меньшими задержками, SSD вытесняют HDD из чувствительных к скорости отклика приложений — таких как OLTP. Транзакции требуют выполнения нескольких взаимосвязанных запросов к базам данных с переключением между ее фрагментами, произвольно расположенными на носителях. Время получения отклика приложением напрямую зависит от способности СХД отрабатывать хаотические переходы между ячейками таблиц баз данных.

Для обслуживания рандомной нагрузки идеально подходит протокол SAS, с его минимальными задержками. Разумеется, при любой модели использования СХД есть зависимость от специфики приложений, размера блока данных, которыми они оперируют, соотношения операций чтения и записи, характера следования запросов. Но, в целом, если критичны производительность и скорость отклика, реализации 6G SAS по большинству показателей превосходят 8Gb FC и 10Gb iSCSI. По уровню задержек, особенно одиночных запросов, отставание iSCSI особенно велико — всему виной вынужденные расходы наложения протоколов (инкапсуляции). Детальное сравнение показателей СХД, идентичных по контроллерам и дискам, но с разными вариантами внешнего интерфейса (8Gb FC / 10Gb iSCSI / 1Gb iSCSI / 6Gb SAS) приводится в работе Low Latency Evaluation of Fibre Channel, iSCSI and SAS Host Interfaces.

Что может cеть SAS

SAS-полнодуплексное соединение. Теоретическая пропускная способность сети с использованием типового 16-портового коммутатора LSI SAS6160:

  • 12 Gb/s (полный дуплекс) x 16 портов x 4 линии SAS на порт = 768 Gb/s.

В практических сценариях пропускную способность обычно описывают в терминах полу-дуплекса — для оценки взаимодействия серверов и СХД SAS-инфраструктуры. Пусть 8 портов коммутатора передают данные на хосты, остальные 8 — получают их от СХД. Пропускная способность 6G SAS в пересчете на порт (4 линии SAS) составляет 6 Gb/s x 4 = 24 Gb/s.

  • 24 Gb/s на порт / (8b/10b кодирование) = 2.4 GB/s на порт.

  • 2.4 GB/s на порт x 88.33% (учет задержек арбитража и дополнительных фреймов) = 2170 MB/s на порт.

  • 2170 MB/s на порт x 8 пар портов = 17 360 MB/s (!) на SAS Switch.

В коммутируемой топологии SAS задержки пропорциональны количеству звеньев в цепочке физического соединения. Так, на доступ к SAS дискам по маршруту «хост-коммутатор-SAS JBOD» уходит два «хопа». В инфраструктуре с одной СХД и каскадированием дисковых полок, чтобы добраться к третьей по счету полке, их надо уже пять.

Коммутируемый SAS. Часть 2. Возможности

Энергопотребление, длина соединений, цена реализации

У SAS низкое энергопотребление — до 5W на порт. Для консолидированных сред малая рассеиваемая мощность — несомненный плюс. Оборотная сторона малого потребления — слабый сигнал. При такой мощности поддерживается пассивное соединение по медному кабелю длиной максимум до 10 метров. С использованием активного кабеля и при наличии усиления со стороны портов контроллера или коммутатора дистанция увеличивается до 25 метров. В следующей редакции протокола SAS ожидается поддержка 100-метровых оптических кабелей.

Оценки стоимости реализации сети зависят от применяемых устройств и схемы коммутации, но даже лобовое сравнение цен 6G SAS HBA / 10GbE / 8G FC HBA (например, в лице их типичных двухпортовых представителей: LSI 9207-8e / Intel X520-DA2 / Qlogic QLE2562) показывает, что в расчете на порт SAS обходится в разы дешевле.

Технологические и ценовые параметры различных типов коммутации отражены в таблице:

Коммутируемый SAS. Часть 2. Возможности

Многоуровневое хранение

Данные не равноценны по востребованности. Одним приложениям нужны низкие задержки доступа, другим важнее емкость хранилищ. К базовым понятиям работы с данными относится многоуровневое или иерархическое хранение (tiering) — организация систем хранения c разделением информации по слоям с различным временем доступа, по разным физическим носителям. Задача многослойных СХД — обеспечить максимальную производительность работы с наиболее востребованными («горячими») данными и постепенный перенос «остывающих» данных на носители с разумным соотношением скорости доступа и удельной цены хранения [см Прикладная термодинамика систем хранения данных].

Операционные приложения крайне чувствительны к низким задержкам систем хранения и их способности обслужить поток запросов с произвольной выборкой короткими блоками (нужен запас по IOPS). Потому и переходят к SSD для работы с «горячими» данными: в OLTP-приложениях, математических вычислениях, интеллектуальном анализе данных. Если производительность важна, но не критична, следующий уровень хранения могут наполнять SAS HDD 10-15k rpm. Архивам данных подойдут недорогие диски SAS NL/SATA 7.2k rpm большой емкости. Коммутируемая среда SAS позволяет разложить устройства хранения по карте приложений и реализовать многоуровневое хранение естественным способом, масштабируя сеть, а не отдельные устройства.

Зонирование

Этот атрибут сетей хранения данных известен со времен Fibre Channel SAN. Массивы и коммутаторы SAS настраиваются по списку серверов, которые имеют право доступа к определенным LUN/устройствам на определенных портах. Зонирование SAS основано не на адресации, а соответствует многоточечной концепции, когда конечным устройствам (инициатор или целевое устройство) может быть дано или не дано разрешение на проведение транзакции на основании суммы физических подключений, которые необходимо установить.

Коммутируемый SAS. Часть 2. Возможности

Через коммутаторы инициаторы SAS способны обращаться к тысячам запоминающих устройств в рамках SAN. Экспандер зон SAS позволяет создавать различные операционные домены для коллективных и отдельных систем хранения. Централизованной точкой зонирования, просмотра и управления является SAS-коммутатор. К примеру, LSI SAS6160 содержит 16 портов miniSAS (4 физ. порта SAS на порт), и поддерживает до 192 групп зон и до 16 наборов зон.

Отказоустойчивость

Классически аппаратная отказоустойчивость обеспечивается за счет физического дублирования — дисков, контроллеров, интерфейсов ввода/вывода, каналов связи.

Коммутируемый SAS. Часть 2. Возможности

Как реализована отказоустойчивая работа с данными в Blade-серверах при дисковых операциях? На каждом лезвии стоит проприетарный двухпортовый HBA, который через проприетарные же маршрутизаторы устанавливает через раздельные пути I/O соединение с массивом-таргетом, внутри которого стоят двухпортовые SAS-диски. При аварии на любом из путей прохождения данных рабочую нагрузку обслуживают маршруты-дублеры.

В точности такой же сценарий реализуется на типовых дискретных серверах, стандартных SAS HBA и маршрутизаторах. Каждый из серверов имеет двух портовый HBA (либо два различных HBA), где каждый из портов соединен с одним из двух SAS-коммутаторов. К каждому из SAS-коммутаторов по двум портам подключаются массивы. В массивах используются двухканальные экспандеры, и стоят SAS- диски, с двумя каналами доступа каждый. Диски собраны в RAID. Источники питания и система вентиляции тоже дублированы.

Роль ОС (например, Microsoft Windows Server 2012) и управляющих приложений — обеспечить прозрачную для пользователя отработку отказов серверов и сетевых соединений. Транспортная сеть SAS предлагает для этого все возможности.

Масштабирование

В топологии коммутируемого SAS новые системы хранения добавляются просто, а структура управляется минимальным вмешательством. Устройства сети уведомляются о появлении нового участника автоматически с его включением. Зонирование СХД, обеспечивающее контроль доступа к устройствам и ограничивающее время сканирования устройств в SAS SAN, выполняется утилитами, обычно поставляемыми с SAS-коммутаторами. Разные поколения SAS-устройств (3G/6G/12G), и даже устройства SATA могут использоваться совместно — с учетом ограничений каждого из стандартов. Не все опции будут доступны в смешанной среде (например, массивы 3G SAS нельзя зонировать), но работать в общей сети можно.

Возможности расширения SAS SAN внушительны. Каскадирование коммутаторов позволяет объединять в сети множество устройств. LSI SAS6160 обеспечивает глубину каскадирования экспандеров, равную 6 (коммутатор = 1 экспандер), количество коммутаторов в каскаде может достигать 4-х, обслуживая до 1000 подключенных устройств SAS и SATA. При этом конфигурирование SAS-коммутаторов производится внеполосно относительно передачи данных — по протоколам TCP/IP, telnet.

Коммутируемый SAS. Часть 2. Возможности

Выбор есть

Сети хранения на чистом SAS пока не стали популярными, при всей преимуществах производительности и ценовой привлекательности. Это следствие молодости технологии (строить SAN на базе SAS-протокола стало возможно только с выходом SAS 2.0, не прошло и пяти лет), ограничений (длина кабеля 10/25м, отсутствие аппаратной репликации), и консервативной привычки рассматривать СХД как фундаментальное вложение в инфраструктуру. Сегодня коммутируемый SAS нуждается не столько в сильном игроке —локомотиве, сколько в согласованных действиях компаний, позиции которых он объективно усиливает. Таким альянсом на массовом серверном рынке мог бы стать треугольник Intel — LSI — Microsoft.

«Слабости» SAS SAN в большинстве задач не критичны. Организация непрерывной доступности приложений возможна в любом типе сети, ведь и FC и SAS — это всего лишь транспорт для SCSI команд. При компактном расположении всего серверного парка проблема расстояний не возникает, а задачи репликации (коль такие возникнут) —решаются программными средствами. Если нет потребности в on-line репликации в удаленный резервный ЦОД с временем простоя сервисов, близким к нулю, и не нужно подключать в сеть хранения более 1000 устройств, но важны простота расширения и умеренная стоимость владения — SAS SAN становится достойным кандидатом. В любом случае, выбор между типами сетей зависит от информированности IT-персонала компании, уже имеющегося парка оборудования, планов по росту инфраструктуры и бюджета.

Первая часть статьи - Коммутируемый SAS. Часть 1. Технология.

Третья часть статьи будет посвящена практическим реализациям SAS SAN.

+99
голосов

Напечатать Отправить другу

Читайте также

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT