Как подключить схд к компьютеру

Подключение СХД Qsan к серверам в среде Windows Server и Hyper-V

Мы продолжаем цикл публикаций из серии How To для пользователей СХД Qsan. В данной статье пойдет речь о подключении СХД к серверам на базе Windows Server, в том числе при использовании функционала виртуализации Hyper-V.

В статье мы будем рассматривать подключения СХД Qsan с использованием блочных протоколов доступа iSCSI и Fibre Channel. Сам процесс подключения можно разделить на несколько основных этапов:

В статье приведены скриншоты настройки операционной системы Windows Server 2016/2019 с нелокализованным интерфейсом. Часть описания, не относящаяся напрямую к ОС, взята из нашего предыдущего обзора по настройке ESXi.

Физическая и логическая коммутация

Совокупность оборудования и линий связи между СХД и серверами образуют так называемую SAN сеть. Отказоустойчивое подключение участников SAN сети подразумевает постоянное наличие хотя бы одного пути между инициатором (хост) и таргетом (СХД). Т.к. СХД сейчас практически поголовно имеют минимум два контроллера, каждый сервер должен иметь связь с каждым из них. В простейшем варианте серверы подключаются к СХД напрямую. Такой режим работы называют Direct Attach. СХД Qsan поддерживают такой режим работы. В этом случае каждый сервер должен иметь двухпортовую HBA для соединения с каждым контроллером СХД. Т.е. между сервером и СХД будет 2 пути. При наличии максимального количества опциональных портов в таком режиме к СХД можно подключить до 10 серверов через iSCSI или до 8 серверов через Fibre Channel.

В большинстве случаев серверы соединяются с СХД через коммутаторы. Для большей надежности их должно быть два (в общем случае их, конечно же, может быть больше, но это они все равно делятся на две группы – фабрики). Этим выполняется защита от выхода из строя самого коммутатора, линка и порта контроллера СХД/HBA. В этом случае каждый сервер и каждый контроллер СХД подключается к каждому коммутатору. Т.е. между каждым сервером и СХД будет 4 пути (в случае двух коммутаторов).

Для Qsan параметр MTU меняется на каждом порту каждого контроллера в меню iSCSI Ports

В Windows Server параметр MTU меняется в настройках драйвера адаптера:
Control Panel\Network and Internet\Network Connections → Свойства конкретного адаптера → Configure → Advanced → Jumbo Packet (у некоторых адаптеров этот пункт может называться что-то типа Large Packets)

Для получения инструкций по изменению MTU у физических коммутаторов рекомендуем обратиться к документации конкретного производителя.

Действия на стороне СХД

Необходимые настройки на СХД можно разделить на два этапа:

Настраивать интерфейсы требуется в основном в случае использования протокола iSCSI: необходимо задать IP адреса портов на вкладке iSCSI Ports. IP адреса портов должны быть из разных подсетей, чтобы однозначно маршрутизировался трафик на стороне хоста.

В случае использования интерфейса Fibre Channel ничего настраивать, как правило, не нужно.

Далее необходимо создать пространство хранения. Сначала создается пул – группа физических накопителей, работающих совместно. Пулов в пределах СХД может быть несколько. Накопители внутри пула объединяются в соответствии с выбранным при его создании уровнем RAID, обеспечивая заданную надежность. Пулы создаются на вкладке Pools → Create Pool, где запускается пошаговый мастер.

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

После создания пула(ов) необходимо создать тома (volume): Volumes → Create volumes. Также запустится пошаговый мастер создания тома.

Необходимо задать требуемый размер тома, тип тома выбирается как RAID volume. Рассмотрим их более подробно.

Заключительным этапом в настройке СХД является публикация томов для доступа к ним со стороны хостов через функционал LUN mapping → Map LUN.

Действия на стороне хоста

Первоначально необходимо один раз установить на сервере компонент Multipath IO, который обеспечивает работу многопутевого ввода/вывода. Данное действие производится через стандартный диалог Add Roles and Features

При использовании протокола iSCSI необходимо выполнить:

При использовании протокола Fibre Channel все гораздо проще: достаточно выполнить Rescan для обнаружения нового тома. В нашем примере это том с LUN доступный по 4 путям. Как и в случае с iSCSI следует убедиться, что для диска установлена политика Round Robin, при которой все доступные пути до СХД будут использоваться равномерно.

Важное замечание касательно конфигурирования MPIO. По умолчанию Windows видит дисковые устройства по отдельности, т.е. каждый путь к устройству – это отдельный диск.

Чтобы ОС «склеила» все одинаковые диски в единое устройство, необходимо в стандартной оснастке MPIO добавить новое устройство как многопутевое. Для iSCSI устройств устанавливается отдельное разрешение. По окончании настройки потребуется перезагрузить сервер. Данную настройку необходимо произвести однократно для каждой СХД. После чего все вновь презентованные диски будут опознаваться ОС как многопутевые.

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

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

Источник

Подключение СХД к серверу: пошаговая инструкция

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

Здесь же остановимся на технической части. А точнее — на процессе подключения СХД к серверу предприятия. Чтобы все правильно работало, отвечало критериям безопасности, не вызывало проблем на дистанции. Тема объемная, затрагивает массу смежных протоколов и сервисов. Но если разобраться — ничего сложного.

Общие сведения и определения

Для начала давайте пройдемся по терминологии. Системы хранения данных (или сети хранения данных) в кругу специалистов принято именовать SAN (Storage Area Network). Основные компоненты SAN — накопители и контроллеры. Чтобы равномерно распределять нагрузку между дисками и серверами, не потеряв при этом в скорости и надежности, используют несколько путей ввода-вывода, не менее двух интерфейсов подключения и HBA (Host Bus Adapter) — выделенную плату-контроллер, которая связывает диски.

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

Подключение производят посредством LUN-интерфейса (Logical UNit). Это отчасти аналог раздела на жестком диске, но используемый для контроллеров. Благодаря такому подходу сервер видит LUN-диски как физические копии. Полезный подход, поскольку в дальнейшем через LUN можно подключить неограниченное количество физических и облачных мощностей в единую систему, формируя один полноценный диск. С него и будет раздаваться информация по серверам.

Распределение происходит через Disk Manager, или посредством утилит уровня LAN/SAN Mapping. Сам же хост LUN-интерфейс не видит.

Специалисты отмечают, что цеплять все имеющиеся LUN-ы на единый контроллер не стоит — быстро перегрузите систему. Всегда разделяйте мощности.

При создании СХД можно использовать как SATA, так и SAS-диски. Зависит от бюджета и потребностей.

Само же подключение SAN к хосту выполняется по следующему принципу:

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

Схема подключения СХД к серверу по SCSI, SAS, FC

Опустим различия между производителями и сосредоточимся на сути. Основной процесс создания системы выглядит следующим образом:

Если все сделано правильно, то возле раздела с HBA появится соответствующая пиктограмма.

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

Первым делом, необходимо разрезать диски на LUN-ы и оставить 1-2 ГБ свободного места на всякий случай. Далее переведите все накопители в статус «онлайн», но буквы никому не присваивайте — особенности работы. А вот форматировать стоит (NTFS. ExFAT или другой алгоритм на усмотрение администратора).

Завершаем настройку установкой HBA-драйверов под FC, SAS или SCSI.

На этом можно считать, что работы завершены. Системой можно управлять специализированным ПО от производителя, или благодаря веб-морде. Это не принципиально.

Полезные советы

Если вы создаете СХД с нуля, настоятельно рекомендуем закупить железо единого производителя. В идеале — одной серии. Так вы избежите 90% ошибок, нестыковок, проблем совместимости.

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

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

И самое главное. При отсутствии опыта у штатных техников и администраторов, обращайтесь к аккредитированным специалистам. Это не та сфера, где можно по щелчку пальцев настроить все самостоятельно — большое количество смежного оборудования, коннекторов, плат управления и контроллеров. Специалисты Маркет.Марвел, имея большой опыт работы в этом направлении, помогут вам подобрать грамотную конфигурацию и оборудование для неё.

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

Если у вас еще остались вопросы по эксплуатации СХД, вы всегда можете задать их нашим специалистам. Закажите консультацию, и мы предоставим вам всю требуемую информацию.

Подключение СХД к серверу: пошаговая инструкция

Источник

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

Однажды один из клиентов компании-интегратора, где я работал, попросил оперативно нарисовать проект небольшой системы хранения данных. Как назло, специальный человек по 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, 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. Но в программных реализациях больше нюансов и «слабых звеньев» из-за большей сложности системы. Да и производительность обычно ниже.

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

Дисковый массив возьмем для примера 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 нужно обращать внимание на логические типы портов. В разных моделях поддерживаются разные сочетания основных типов из таблицы:

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

Использование привычного Ethernet

Можно обойтись и без изучения новых видов сетей, используя старый добрый 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, могу порекомендовать следующие бестселлеры:

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

Источник