Подключение схд к серверу по sas

Обновлено: 15.01.2025

Кратко: СХД (система хранения данных) — это комплексное программно-аппаратное решение по организации надёжного хранения информационных ресурсов и предоставления гарантированного доступа к ним.

Алгоритм подключения СХД довольно прост, о чем вы и можете прочитать в нашей статье. Его даже можно назвать вполне себе универсальным, если закрыть глаза на особенности настроек, которые в свою очередь зависят от использующегося оборудования и топологии сети. Отметим, что для новичков задача сложная, поэтому вы можете всегда обратиться за консультацией к специалистам компании «Яхонт».

Этапы подключения на примере «Яхонт-УВМ Э12»

Физическое соединение. Перед началом использования оборудования требуется внимательно ознакомиться с документацией производителя. Там подробно описаны все действия. Спереди расположены слоты под диски, сзади — модульные контроллеры и блоки питания. На контроллерах установлены порты. В комплект с СХД входят рельсы и технический паспорт, в котором вы найдете IP для подключения к контроллерам СХД, а также пароль администратора. Далее производится монтаж в стойку и подключение к серверу через коммутаторы, включают СХД и переходят к следующему этапу.
Настройка. Чтобы настроить управляющий интерфейс и сменить IP-адрес, требуется подключиться к СХД по SSH. Для этого используют логин и пароль. Посредством команды interfaces list выводят информацию о сетевых интерфейсах, управляющим из которых является main. Далее задают настройки на main командой interfaces mgr. Потом вводят следующее:
- имя интерфейса;
- IP-адрес;
- маску подсети;
- шлюз;
- подтверждают настройки.

Для подключения к веб-интерфейсу в адресную строку браузера вводят IP-адрес управляющего интерфейса, указывая логин и пароль. Следующий алгоритм действий таков:

Перейти во вкладку «Сетевые интерфейсы».
Выбрать «Сетевые интерфейсы».
Выбрать «Виртуальные интерфейсы».
Нажать на кнопку «Добавить VIP».

В открывшемся окне:

выбирают порт управляющего интерфейса;
задают IP-адрес и маску подсети.

При подключении нескольких СХД нужно создать дополнительные узлы. Как это сделать?

Выбрать вкладку «Управление».
Выбрать «Управление контроллером».
Нажать на кнопку «Добавить узел».

В открывшемся окне:

выбрать виртуальный интерфейс, который был создан ранее;
указать IP-адрес управляющего интерфейса и номер контроллера.

На вкладке «Системная панель» вы сможете отслеживать состояние всех настроенных узлов онлайн.

Техническая информация

Серверы СХД «Яхонт» производятся на территории России из отечественных комплектующих, полностью соответствуют требованиям безопасности и техническим регламентам Таможенного союза.

Однажды один из клиентов компании-интегратора, где я работал, попросил оперативно нарисовать проект небольшой системы хранения данных. Как назло, специальный человек по SAN оказался недоступен и задачу поручили мне. На тот момент мои знания по СХД сводились к непробиваемой идее "Fibre Channel – это круто, а iSCSI – не очень".

Для всех тех, кто попал в похожую ситуацию или немного интересуется темой SAN, мы подготовили цикл материалов в формате "конспект". Сегодняшняя статья посвящена технологиям хранения для небольших и средних организаций. Постараюсь не занудствовать с теорией и использовать побольше примеров.

Если инженер не особенно знаком с сетями хранения данных (СХД), то выбор подходящего устройства часто начинается с изучения рынка в преломлении собственных стереотипов. Например, я в свое время обычно останавливался на простых DAS-системах, что удивительно дополняло своей нелогичностью тезис про "крутость" Fibre Channel. Зато DAS был понятным и не требовал чтения длинных руководств администратора и погружения в темный мир сетей хранения.

Если в организации просто заканчивается место на общем сетевом диске, то хватит и недорогого сервера с относительно высокой плотностью дисков, в качестве задела на будущее. Из специализированных систем неплохо подойдет сетевое файловое хранилище (NAS), вроде Synology DS414 SLim. На нем и общие папки создавать удобно, и права гибко настраиваются, и с Active Directory интеграция есть.

Чем мне нравятся хранилища Synology, так это удобным интерфейсом с множеством плагинов на любые сценарии использования. Но поведение у них бывает весьма странным. Например, у одного заказчика был Synology DS411+II. Работал прекрасно до очередной перезагрузки, после которой не включился. Не спрашивайте, как я до этого дошел, но алгоритм запуска после сбоя был следующий:

1. Вынуть все диски, включить устройство, выключить устройство;

2. Воткнуть один диск, включить устройство, выключить устройство;

3. Воткнуть второй диск, включить устройство, выключить устройство;

4. Повторить для третьего и четвертого диска. После установки четвертого диска, устройство включается и работает.

Способ был опубликован на форуме Synology и оказалось, что я не один такой везучий. С тех пор предпочитаю небольшие серверы с GNU\Linux на борту, у них хотя бы с диагностикой проще.

Из сборок для NAS могу порекомендовать Openmediavault.

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

Пара слов о том, что такое SAN и DAS. Просто освежить память.

SAN, Storage Area Network – архитектурное решение для подключения по сети внешних устройств хранения данных, вроде дисковых массивов и ленточных библиотек. Причем, подключить на блочном уровне, чтобы клиент работал с ними так же, как с обыкновенными локальными дисками. В русскоязычной литературе используется аббревиатура СХД (Сеть Хранения Данных) – не путайте с Системой Хранения Данных, которой может считаться любая дисковая полка.

В этой статье я не буду касаться программных реализаций, вроде Storage Spaces в среде Windows, а ограничусь железными и архитектурными нюансами СХД.

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

Самым недорогим способом организации SAN является интерфейс Serial Attached SCSI (SAS). Тот самый, с помощью которого подключаются диски в любом современном сервере. Используют SAS и для прямого подключения внешнего дискового массива к серверу.

Для массива DAS возможна организация отказоустойчивого подключения к нескольким серверам. Делается это с помощью Multipath, технологии коммутации клиента и СХД по нескольким маршрутам. Но большей популярностью пользуется разделение дисков между серверами, которые уже самостоятельно собирают из них группы RAID и делят на тома. Подобная схема называется "Разделяемый JBOD".

Для подключение к серверу используются адаптеры (HBA) под конкретный интерфейс, которые просто позволяют ОС увидеть готовые дисковые тома.

Стоит отметить, что SAS поддерживает три стандарта:

SAS-1, со скоростью 3 Гб/с на устройство;

SAS-2, со скоростью 6 Гб/с;

При планировании архитектуры стоит также иметь в виду отличия в разъемах SAS, что часто приводит к путанице при заказе кабелей. Самыми популярными при подключении внешнего оборудования являются SFF-8088 (mini-SAS) и SFF-8644 (mini-SAS HD).

Являясь частностью SCSI, SAS поддерживает экспандеры, что позволяет подключать до 65 535 устройств к одному контроллеру и порту. Конечно, цифра скорее теоретическая и не учитывает различные накладные расходы. Чаще всего встречаются контроллеры с реальным ограничением в 128 дисков, но масштабировать подобный SAN для двух и более серверов простыми экспандерами уже не так удобно. В качестве более адекватной альтернативы можно использовать коммутаторы SAS. По сути, это те же экспандеры, но с поддержкой распределения ресурсов по серверам, т.н "зонирование". Например, для стандарта SAS-2 наибольшей популярностью пользуется LSI 6160.

С помощью коммутаторов SAS возможна реализация отказоустойчивых схем для нескольких серверов без единой точки отказа.

Из плюсов использования SAS можно отметить:

Низкую стоимость решения;

Высокую пропускную способность – даже при использовании SAS-2 получится 24 Гб/с на каждый порт контроллера;

Не обошлось и без минусов:

Отсутствуют механизмы репликации средствами дискового массива;

В качестве типового решения для малых и средних организаций разберем создание небольшого отказоустойчивого кластера виртуальных машин. Под кластер выделим два узла с единственным дисковым массивом. В качестве условного среднего объема дискового тома выберем 1 ТБ.

Замечу, что программными решениями вроде StarWind Native SAN можно получить такой же кластер без отдельного дискового массива, или же с простыми JBOD. Кроме того, большинство гипервизоров поддерживают в качестве хранилищ сетевые ресурсы NFS или SMB 3.0. Но в программных реализациях больше нюансов и «слабых звеньев» из-за большей сложности системы. Да и производительность обычно ниже.

Для сборки такой системы понадобится:

HBA для серверов;

Дисковый массив возьмем для примера HP MSA 2040 с двенадцатью отсеками под HDD. Для подключения будем использовать SAS 3.0 на скорости 12 Гб/с. Посчитаем первым попавшимся

Каждый сервер будет соединятся с каждым контроллером СХД для Multipathing.

На мой взгляд, SAS 3.0 оптимален, если не нужны распределенные SAN-сети и не требуется детальное разграничение прав доступа к СХД. Для небольшой организации так можно достичь отличного баланса цены и производительности.

После приобретения второго массива в будущем станет возможным соединение каждого сервера с контроллером каждой дисковой полки, но при росте числа клиентов это серьезно усложнит архитектуру. Для большего числа клиентов лучше приобрести один SAS коммутатор. Или два, для построения отказоустойчивого решения.

Традиционным выбором для построения SAN является Fibre Channel (FC) – интерфейс, связующий узлы сети по оптическому волокну.

FC поддерживает несколько скоростей: от 1 до 128 Гб/с (стандарт 128GFC вышел как раз в 2016). В основном используются 4GFC, 8GFC и 16GFC.

Существенные различия по сравнению с SAS-системами проявляются при проектировании крупных SAN:

Расширение производится не за счет экспандеров, а возможностями топологии сети;

В небольших организациях обычно применяют структуру с одним коммутатором (single-switch), когда один сервер через один коммутатор подключается к дисковому массиву. Такая схема составляет основу остальных топологий: каскад (cascade), решетка (mesh) и кольцо (ring).

Наиболее масштабируемая и отказоустойчивая схема называется "центрально-распределенная" (core-edge). Она напоминает известную всем сетевую топологию “звезда”, но только в середине два центральных коммутатора, распределяющих трафик по периферийным. Частным случаем этой схемы является “коммутируемая архитектура” (switched fabric), без периферийных коммутаторов.

При проектировании стоит обратить внимание на разные типы трансиверов. Это специальные модули, которые преобразуют цифровой сигнал в оптический, для чего используются светодиоды или лазерные излучатели. Трансиверы поддерживают разные длины волны и разные оптические кабели, что влияет на протяженность сегмента.

Есть два типа трансиверов:

Коротковолновые (Short Wave, SW, SX) – подходят только для многомодовых волокон;

К обоим типам кабель подключается разъемом LC, а вот SC-разъемы встречаются довольно редко.

Типичный HBA c двумя портами FC

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

К плюсам решений на FC можно отнести:

Возможность построения территориально распределенной SAN;

Высокая скорость передачи данных;

На другой чаше весов традиционно лежит стоимость.

Системы хранения из раздела про SAS можно построить и на 16GFC, заменив лишь HBA и контроллер дисковой полки. Стоимость при этом вырастет уже до 1 845 790 ₽.

В своей практике я встречал у заказчика даже построенный на FC массив DAS, заполненным дисками менее, чем наполовину. Почему не использовали SAS? Самый оригинальный ответ был такой: «а что, можно было?».

В более сложной инфраструктуре FC становится структурно более похож на TCP\IP. У протокола также описаны уровни, как и у стека TCP\IP, существуют маршрутизаторы и коммутаторы, описано даже "тегирование" для изоляции сегментов на манер VLAN. Кроме того, на FC-коммутаторах исполняются службы разрешения имен и обнаружения устройств.

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

Тип Устройства	Наименование	Описание
Сервер	N_Port (Node port)	Используется для подключения к коммутатору или конечному устройству.
NL_Port (Node Loop port)	Порт с поддержкой топологии «петля».
Коммутатор\ Маршрутизатор	F_Port (Fabric port	Для подключения N_Port, «петля» не поддерживается.
FL_Port (Fabric Loop port),	Порт с поддержкой «петли».
E_Port (Expansion port	Порт для соединения коммутаторов.
EX_port	Порт для соединения коммутатора и маршрутизатора.
TE_port (Trunking Expansion port)	E-port с поддержкой VSAN.
Общие	L_Port (Loop port)	Любой порт с поддержкой петли (NL_port или FL_port).
G_port (Generic port)	Любой незанятый порт устройства с авто определением.

Статья была бы неполной без упоминания варианта построения SAN на InfiniBand. Этот протокол позволяет достичь действительно высоких скоростей передачи данных, но по стоимости выходит далеко за рамки SMB.

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

Популярный протокол для создания SAN в Ethernet-сетях называется Internet Small Computer Systems Interface (iSCSI). Строится он поверх TCP\IP, и основной его плюс в приличной работе по обычной гигабитной сети. В обиходе такие решения часто называют "бесплатный SAN". Разумеется, гигабита под серьезные задачи не хватит, и к вашим услугам сети 10 Гб/с.

К безусловным плюсам можно отнести низкую стоимость базового оборудования. Так как iSCSI реализуется программно, можно установить соответствующие приложения на обычные серверы. Большинство NAS класса SOHO поддерживают этот протокол изначально.

У заказчика однажды остро встал вопрос перемещения Exchange 2003 с умирающего сервера. Решили виртуализировать его с минимальным простоем. Для этого подняли iSCSI-target на том самом NAS Synology DS411 из первой части статьи и подключили к Exchange. Далее перенесли туда БД и мигрировали на MS Virtual Server 2005 c помощью disk2vhd. После успешной миграции перенесли базу обратно. Позже такие операции проводились при переходе с MS Virtual Server на VMware.

Разумеется, для построения SAN на iSCSI, даже если для задач хватает и гигабитной сети, не стоит "выпускать" его в общий LAN. Работать оно будет, но широковещательные запросы и прочий служебный трафик непременно скажутся на скорости и создадут помехи пользователям. Лучше построить отдельную изолированную сеть со своим оборудованием. Или, в крайнем случае, хотя бы выделить подсеть с iSCSI в отдельный VLAN. Стоит отметить, что для достижения максимальной производительности таких систем необходимо включать поддержку Jumbo Frames на всем пути следования пакетов.

В качестве меры экономии бюджета может возникнуть мысль об объединении гигабитных портов при помощи агрегации каналов (LACP). Но, как правильно заметил VitalKoshalew в комментариях, реальной балансировки между отдельным сервером и хранилищем с помощью LACP не получится. Более правильным бюджетным решением будет использование технологий Multipath на верхних уровнях модели OSI.

К слову, совсем правильное iSCSI-решение на базе 10 Гб сети, с поддерживающими аппаратное ускорение iSCSI сетевыми картами и соответствующими коммутаторами приближается по стоимости к FC.

Подобная схема сети возможна благодаря тому, что iSCSI работает поверх TCP\IP.

Из интересных решений на базе iSCSI можно отметить работу тонких клиентов без сервера терминалов – вместо локальных дисков используется том iSCSI. Гигабитной сети вполне достаточно для такой работы, а реализовать что-либо подобное другими средствами не так просто.

Возможность построения территориально распределенной сети;

Задержки при обращении к данным могут быть существенными, особенно при работе с пулом виртуальных машин;

Есть и более "взрослая" альтернатива iSCSI. Можно использовать ту же сеть Ethernet, но протокол хранения завернуть непосредственно в кадры Ethernet, минуя TCP\IP. Протокол называется Fibre Channel over Ethernet (FCoE) и для работы использует Ethernet 10 Гб. Помимо традиционной оптики, можно использовать специальные медные кабели или витую пару категории 6a.

Важное отличие от FC в том, что порт Ethernet можно использовать совместно с TCP\IP. Для этого нужны специальные сетевые адаптеры, так называемые Converged Network Adapter (CNA) с поддержкой FC и FCoE, хотя есть и программные решения. Поскольку протокол работает ниже уровня TCP\IP, то простой коммутатор не подойдет. Кроме того, обязательно должна быть поддержка Jumbo Frames и Data Center Bridging (DCB, иногда встречается Data Center Ethernet). Подобные решения обычно стоят дороже (например, Cisco серии Nexus).

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

Если вернуться к нашему маленькому, но гордому кластеру виртуализации, то для него решения на 10 Гб/с iSCSI и FCoE будут практически одинаковыми по стоимости, но в случае с iSCSI можно использовать дешевые гигабитные сети.

Также стоит упомянуть и довольно экзотичный протокол ATA over Ethernet (AoE), схожий по своей работе с FCoE. Дисковые массивы с ним – редкость, обычно используются программные решения.

Выбор конкретной реализации системы хранения требует вдумчивого изучения конкретной ситуации. Не стоит подключать дисковый массив с помощью FC просто потому, что "оптика" звучит гордо. Решение на SAS даст аналогичную или даже большую производительность там, где оно архитектурно уместно. Если не брать в расчет стоимость и сложности обслуживания, то существенным отличием между всеми описанными технологиями подключения СХД будет дистанция соединений. Эту мысль хорошо иллюстрирует один из кадров презентации SNIA:

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

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

Алгоритм подключения системы хранения данных к хосту достаточно универсален. Безусловно, существуют нюансы настройки, которые зависят от конкретного оборудования и топологии вашей сети.

Создание SAN является сложной задачей. Если это ваш первый опыт, обратитесь к специалистам ВИСТЛАН за консультацией, помощью в проектировании системы и подборе оборудования

Подключение СХД к хосту делится на два этапа:

Физическое соединение.

Настройка.

Перед началом внимательно ознакомьтесь с документацией производителя на полку. Она подробно описывает все действия. Пример документации от Oracle .

Техническая информация

SAN состоит из нескольких HDD и контроллеров. Для равномерного распределения нагрузки и обеспечения надёжности стараются использовать два HBA (Host Bus Adapter), несколько путей ввода-вывода, как минимум два интерфейса.

Главным правилом подключения СХД к хосту является использование как минимум двух связей и путей для каждого устройства.

Свичи обеспечивают для серверов доступ только к предназначенным им ресурсам. Для этого в SAN каждому интерфейсу и каждому LUN-у присваивается World Wide Name (WWN) — подобие MAC-адреса.

LUN — Logical UNit — с точки зрения контроллера — это аналог раздела на жёстком диске. Сервер видит их как физические диски. Можно подключить все хосты к одному диску или раздать LUN-ы по серверам.

Распределение выполняется в Disk Manager конкретного сервера или с помощью утилит (LAN Mapping, SAN Mapping и т.п) хосту принудительно запрещается видеть LUN.

Не вешайте все LUN-ы на один контроллер. Разделите особо нагруженные LUN-ы по разным.

При создании SAN можно использовать разные типы HDD. Помедленнее и подешевле, типа SAS или SATA, — для ОС сервера и файловых ресурсов; FC — для скоростных приложений и баз данных.

Алгоритм подключения

В сервер установите HBA-контроллер.

Подключите СХД с помощью кабелей соответствующих интерфейсам, установленным на дисковой хранилище (FC, SAS, SCSI) по вашей схеме.

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

Скачайте с сайта производителя ПО. Однако, оно может идти в комплекте, но это не обязательно.

Установите ПО. Пройдите регистрацию, если требуется.

Включите HBA хоста и дисковую полку в одну подсеть на одном физическом коммутаторе.

Запустите утилиту сканирования SAN для определения топологии. Она покажет все устройства и их номера.

Зарегистрируйте хост на полке. Это можно сделать с помощью утилиты или вручную через веб-интерфейс полки. Автоматически — корректней.

Введите в браузере IP-адрес хоста и сделайте привязку полки. При первом подключении может понадобиться создать пароль админа.

Зайдите в систему управления дисками на хосте, убедитесь, что подключенные диски видны. Они выглядят там как обычные SCSI.

Перейдите по IP-адресу СХД в браузере. Проверьте наличие серверов, регистрация которых уже выполнена.

Найдите вкладку с инициаторами, связывающими хосты с блоками СХД. Проверьте IP-адреса. Если нужно, перенастройте их вручную.

Свяжите LUN-ы и хосты. Действия типа: Create -> Connect LUNs -> Connect Hosts.

Посмотрите наличие отметки около HBA, сигнализирующей о корректности подключения.

На этом настройка полки закончена.

Нарежьте диски на LUN-ы. Их можно сделать много. Оставьте около 1 Гб свободного места

Переведите диски в режим онлайн. Буквы не присваивайте.

Отформатируйте диски в нужный формат, например, NTFS.

Установите драйверы HBA (FC, SAS или SCSI).

Подключение завершено. Можно управлять системой с помощью специального софта или через веб-интерфейс.

СХД - система хранения данных - это не полка

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

Отличие СХД от полки это наличие “Мозга”. Контроллеры СХД это мини-серверы, со своими процессорами, памятью и операционной системой. СХД собирают из дисков RAID массивы, и передают данные по протоколам высокого уровня (iSCSI, NFS), контролируют целостность данных, позволяют создавать снапшоты и многое другое. СХД нужна если наша задача построить отказоустойчивый кластер

Однако, в случае если мы просто хотим добавить дисков в сервер, наличие “мозга” создаёт сложности: Не все СХД понимают диски объемом более 2Tb. Редкие СХД принимают от независимых производителей. Несмотря на то, что СХД полезное устройство - в этой статье мы не будем рассматривать использование СХД. Сегодня давайте разберёмся с полками.

Полка - это не СХД

Полка - достаточно простое устройство. Корпус, два блока питания, бэкплэйн и JBOD* контроллеры. Задача полки, без какой либо обработки, передать данные из накопителя в адаптер (карту RAID или HBA). Любая полка поддерживает диски любого объёма и любого производителя. Всё решает карточка в сервере. Контроллер полки - это набор микросхем с жесткой логикой.

Так выглядит подключение дисков внутри сервера

Так подключение сервер + полка.

С точки зрения схемотехники (и операционной системы), диски, установленные в полку, ничем не отличаются от дисков установленных в сервер**.
Полка имеет отдельный корпус, отдельные блоки питания, но в обоих случаях подключение производиться через RAID карточку установленную в сервер -, отличие лишь в том, что в случае с полкой, кабель подключается не по внутреннему а по внешнему разъёму.

*JBOD = Just A Bunch of Disks ( просто пачка дисков )
** Если быть совсем точным, полку можно сравнивать с сервером в котором установлен SAS экспандер - это серверы в которых количество дисков превышает 8. Для операционной системы SAS экспандер не заметен.

Вот широко распространённый RAID контроллер LSI9260-8i
8i означает 8 внутренних портов SAS/SATA

А вот его брат LSI9280-4i4e

4 внутренних и 4 внешних порта

Как называется вот этот контроллер, я думаю вы уже догадались )

Правильно - это LSI9280-8e

Все эти контроллеры собраны на одном и том же чипе LSI2108. Они обеспечивают работу по протоколам SAS/SATA со скоростью 6Gb/s и “понимают” диски объёмом более 2Tb. Попутно замечу, что на этом чипе собраны RAID контроллеры в серверах Supermicro, Intel, IBM, DELL, Fujitsu и CISCO. Многие из производителей даже не утруждают себя разработкой собственной печатной платы - меняют только прошивку. Но впрочем RAID и HBA - тема для отдельной статьи.

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

Еще несколько нюансов

Полки бывают не только SAS, но других типов, например FC (скорее всего они вам не нужны).

Полки могут быть 3, 6 и 12Gb/s. Не все знают, что в одном кабеле mini-SAS четыре канала. Это значит, что для вычисления скорости обмена полка-контроллер показатель 3,6,12 нужно умножить на 4, а в случае если полка и контроллер соединяются двумя кабелями, на 8. Для примера 3-х гигабитная полка сможет отдавать в сервер 3x4 = 12 Гигабит! Что очень неплохо, особенно, если вы устанавливаете шпиндельные накопители. Для работы диска с сервером важна не скорость передачи данных а количество операций ввода-вывода IOPS. Об этом читайте в пункте 7.

Не важно Supermicro, IBM, DELL или HP. Любая SAS полка будет работать с любым SAS контроллером. Брэнд имеет значение только когда вы подключаете полку к СХД.

Полки можно собирать в гирлянду - подключая к одному контроллеру сразу несколько полок.***

*** Если вы используете SATA диски, длина подключения не должна превышать 1М.

При использовании SAS дисков (или SATA дисков с интерпозерами) можно подключать полку по двум путям, через два контроллера. Это позволяет избежать отказа в случае выхода их строя одного из контроллеров.

Полки можно добавлять по мере роста количества данных, подключая их двумя путями
“в гирлянду” вот так:

SFF* полки ( обычно бывают 2U на 24-25 дисков)

Для чего нужны SFF полки?

Типичный сервер редко перекидывает большие блоки данных - в основном он производит хаотичные запросы чтения или записи маленьких блоков из совершенно разных мест массива. Скорость по этому показателю измеряется не в Гигабитах в секунду, а в количестве операций ввода-вывода (IOPS). И именно IOPS, а не трансфер основной параметр которому следует уделять внимание. Пользователи ПК сравнивают диски по показателям 3Gb/s, 6Gb/s, 12Gb/s, но зачастую, скорость потока диск - сервер это не Гигабиты, и даже не Мегабиты, а Килобиты! Скорости 3Gb/s, которую обеспечивают даже устаревшие интерфейсы в большинстве случаев достаточно. Сильно ошибаются те, кто думают, что улучшат производительность, сменив диски 3Gb/s на 12Gb/s. Если не изменился форм-фактор и обороты диска - скорость IOPS не измениться.

На увеличение IOPS положительно влияют: увеличение оборотов, уменьшение физического размера, увеличение числа дисков в массиве.

LFF диски, (особенно низкооборотистые 7200RPM) не предназначены на работу в режиме случайного доступа - их назначение хранение ColdData (например бэкапов)

*SFF Small Form Factor - это диски 2,5” Обычно это высоко-оборотистые 10-15К SAS диски объёмом 300-1200GB. Не стоит путать их с ноутбучными дисками.
LFF Large Form Factor - это диски 3,5” Обычно низко-оборотистые 7200 диски, объёмом 2TB и более.

И наконец, если у вас уже есть СХД, добавив полку вы можете увеличить не только объём, но и существенно повысить скорость работы. Ведь показатель IOPS напрямую зависит от количества дисков.

У нас имеются полки для наиболее распространённых СХД производства NetAPP, HP, Dell, IBM.

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