Как выбрать между архитектурами SAN, NAS и DAS для ваших рабочих нагрузок?

Выбор правильной архитектуры хранения данных — одно из самых важных инфраструктурных решений, которое может принять ИТ-команда. Независимо от того, создаёте ли вы частное облако, управляете растущим кластером виртуализации или просто пытаетесь навести порядок в хаотичном разрастании данных, выбор между сетью хранения данных (SAN), сетевым хранилищем (NAS) и прямым подключением хранилища (DAS) определяет всё: от запаса производительности до операционной гибкости. Каждая из этих моделей основана на своих собственных предположениях относительно того, как осуществляется передача данных, как распределяются ресурсы и как будет масштабироваться ваша инфраструктура со временем. Понимание этих различий до закупки оборудования и прокладки кабелей обойдётся значительно дешевле, чем выявление несоответствий архитектуры уже после развёртывания.

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

Понимание основных различий между SAN, NAS и DAS

Что на самом деле делает каждая архитектура

Прямое подключение хранилища (DAS) — это именно то, на что указывает его название: устройства хранения данных физически подключены к одному серверу или рабочей станции без промежуточной сетевой инфраструктуры. Это могут быть внутренние жесткие диски, внешние массивы USB или SAS, а также накопители NVMe, установленные непосредственно в хост-системе. DAS обеспечивает низкую задержку, поскольку отсутствует сетевой переход, однако приводит к образованию изолированных хранилищ. Каждый сервер владеет собственным хранилищем, а для совместного использования этой емкости с другими хостами требуются дополнительные программные уровни или перемещение данных, что добавляет сложности и задержек.

Сетевое хранилище (NAS) представляет собой выделенный файловый сервер, который предоставляет общие каталоги по стандартной IP-сети с использованием таких протоколов, как NFS, SMB или CIFS. Несколько клиентов одновременно получают доступ к одной и той же файловой системе, что делает NAS идеальным решением для совместной работы, медиа-репозиториев, домашних каталогов и целей резервного копирования. Хранилище отображается операционной системой как удалённая файловая система, а производительность ограничена пропускной способностью сети и задержкой, присущей протоколам доступа на уровне файлов.

Сетевая хранилищная система (SAN) использует принципиально иной подход, создавая выделенную высокоскоростную сеть исключительно для трафика хранения данных. Серверы подключаются к инфраструктуре SAN через адаптеры хост-шины и воспринимают тома хранения так, будто они представляют собой локальные блочные устройства. Доступ на уровне блоков критически важен для рабочих нагрузок, требующих прямого ввода-вывода на диск без посредничества файловой системы, включая большинство корпоративных баз данных, гипервизоры виртуализации и транзакционные приложения. Коммутатор SAN является центральным устройством межсоединения, которое маршрутизирует кадры хранения по протоколу Fibre Channel или Ethernet между серверами и массивами хранения в этой выделенной инфраструктуре.

Отличия на уровне протокола и транспортного уровня

DAS использует прямые интерфейсы шины, такие как SAS, SATA, NVMe или устаревший SCSI. Это детерминированные транспорты с низкими накладными расходами, обеспечивающие максимальную пропускную способность для одного хоста. NAS полагается на сетевые технологии TCP/IP и протоколы совместного использования файлов, построенные поверх них, что означает, что производительность хранилища подвержена всему спектру вариаций общей сети, если политики обеспечения качества обслуживания (QoS) не применяются тщательно.

SAN, как правило, использует канал передачи Fibre Channel, хотя в качестве альтернативы всё чаще применяются iSCSI по Ethernet и Fibre Channel по Ethernet. Канал Fibre Channel был специально разработан с нуля для трафика хранения данных и обеспечивает детерминированную задержку, встроенное управление потоком и безошибочную доставку. Коммутатор SAN в среде Fibre Channel выполняет зонирование — логическую сегментацию структуры (fabric), при которой видимыми остаются только авторизованные пути от хоста к хранилищу. Это одновременно механизм безопасности и изоляции производительности, предотвращающий взаимное влияние рабочих нагрузок на уровне структуры (fabric).

Соответствие архитектуры характеристикам рабочей нагрузки

Когда DAS является подходящим решением

DAS по-прежнему остаётся актуальным и зачастую оптимальным решением для рабочих нагрузок на одном сервере, где совместное использование ресурсов не требуется, а приоритетом является максимальная производительность ввода-вывода. Высокопроизводительные узлы аналитики, выделенные серверы рендеринга, развертывания на периферии (edge computing) и рабочие станции разработчиков получают выгоду от использования DAS, поскольку отсутствие сетевого уровня устраняет изменчивость задержек. Когда рабочая нагрузка выполняется на одном хосте, а сам хост вряд ли будет перемещён или распределён по балансировщику нагрузки, DAS позволяет избежать затрат и сложности инфраструктуры общего хранилища без каких-либо существенных потерь.

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

Когда NAS соответствует рабочей нагрузке

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

Современные NAS-платформы также поддерживают широкий набор функций управления данными, включая создание снимков, репликацию, дедупликацию и многоуровневое хранение, что повышает ценность решений для долгосрочного хранения данных. Однако NAS не является оптимальным выбором для транзакционных баз данных, чувствительных к задержкам, развертываний крупномасштабных виртуальных машин, требующих стабильной производительности ввода-вывода менее одного миллисекунды, или любых рабочих нагрузок, зависящих от семантики «сырых» блочных устройств. Попытки запустить такие рабочие нагрузки на NAS, как правило, приводят к проблемам с производительностью, диагностика которых затруднена, а устранение — дорогостояще.

Когда архитектура SAN обеспечивает максимальную ценность

Сетевая система хранения данных (SAN) предназначена специально для сред, в которых несколько серверов должны совместно использовать высокопроизводительное блочное хранилище с предсказуемой задержкой и возможностью прозрачной миграции рабочих нагрузок между узлами. Кластеры корпоративных баз данных, фермы виртуализации VMware и Hyper-V, развертывания Oracle RAC, а также критически важные транзакционные системы полностью зависят от характеристик SAN. Коммутатор SAN обеспечивает реализацию этой общей топологии, позволяя объединить десятки серверов и несколько систем хранения данных в единую сеть, которая одновременно поддерживает как избыточность, так и изоляцию производительности.

Коммутатор SAN также обеспечивает функциональную основу для расширенных возможностей, таких как миграция хранилища в режиме реального времени, автоматическое уровневое размещение данных на хранилище и масштабирование томов без прерывания работы. Политики зонирования, применяемые на уровне коммутатора SAN, гарантируют, что тестовый сервер случайно не получит доступ к томам производственного хранилища, а конфигурации многопутевого подключения, определённые через инфраструктуру SAN-сети, обеспечивают автоматический переход на резервный путь в случае обрыва соединения между хостом и массивом хранилища. Эти возможности просто недоступны в архитектурах DAS и NAS, поэтому SAN остаётся доминирующим выбором для корпоративных рабочих нагрузок первого уровня, несмотря на более высокую сложность первоначального развертывания.

Оценка совокупной стоимости владения во всех трёх моделях

Капитальные и инфраструктурные затраты

DAS имеет самую низкую стоимость входа, поскольку требует только самих устройств хранения данных и локального интерфейса. В ней отсутствует коммутационная среда, специализированная кабельная инфраструктура и дополнительное программное обеспечение для управления, лицензирование которого необходимо. Для небольших сред с предсказуемыми, статичными рабочими нагрузками такая простота действительно ценна. Однако потолок стоимости обусловлен неэффективностью изолированного хранилища. Когда каждый сервер поддерживает собственный пул хранилища, средний уровень использования, как правило, низок, поскольку каждый пул должен быть рассчитан на пиковую нагрузку, а не на среднюю нагрузку по совместно используемому ресурсу.

NAS добавляет стоимость выделенного NAS-устройства и стандартной сетевой инфраструктуры, но распределяет эту стоимость между всеми клиентами, использующими его. Современные IP-сети, применяемые для подключения к NAS, недороги, поскольку они используют коммерческое оборудование на базе Ethernet. Высококачественное развертывание NAS может обеспечить превосходное соотношение цены и производительности для рабочих нагрузок, связанных с файлами, а интерфейс управления, как правило, значительно проще, чем администрирование SAN. Компромисс заключается в том, что NAS делит полосу пропускания с другим сетевым трафиком, если не используются выделенные VLAN для хранения данных или отдельные физические интерфейсы.

Стоимость инфраструктуры SAN является самой высокой, поскольку она требует установки адаптеров шины хоста (HBA) на каждом сервере, выделенной кабельной системы Fibre Channel или iSCSI, коммутатора SAN для каждого узла ткани и массива хранения данных, предназначенного для доступа на уровне блоков. Коммутатор SAN начального уровня, например BR-6505, позволяет внедрить полноценные возможности SAN в небольших развертываниях без необходимости вложений, сопоставимых с затратами на полностью модульные корпоративные директоры, что делает SAN более доступным решением для среднего рынка при построении частных облачных хранилищ. Такие затраты оправданы, если рабочие нагрузки действительно требуют тех возможностей, которые предоставляет SAN; однако развертывание инфраструктуры SAN в основном для задач совместного использования файлов представляет собой дорогостоящее несоответствие.

Операционная сложность и требования к квалификации персонала

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

Администрирование СХД требует специализированных знаний в области концепций волоконно-оптической сети (Fibre Channel fabric), настройки зонирования, драйверов многопутевого ввода-вывода (multipath I/O) и управления массивами хранения данных. Коммутатор СХД обычно является устройством, на котором осуществляется администрирование политик зонирования, а ошибки при настройке зонирования могут вызывать незначительные проблемы с подключением, диагностика которых занимает много времени. Инвестиции в надлежащее обучение администраторов СХД окупаются за счёт предотвращения ошибок конфигурации, приводящих к простою производственных систем. Операционная сложность представляет собой реальную статью расходов, которую необходимо учитывать при расчёте общей стоимости владения (TCO) наряду с ценой оборудования.

Масштабируемость и обеспечение будущей совместимости вашего решения для хранения данных

То, как масштабируется каждая архитектура

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

NAS хорошо масштабируется по объёму файлового хранилища, и современные NAS-платформы поддерживают кластерные конфигурации, позволяющие одновременно наращивать как ёмкость, так и производительность путём добавления узлов в кластер. Для файловых рабочих нагрузок, растущих в объёме, а не по интенсивности операций ввода-вывода (I/O), NAS обеспечивает естественный и экономически эффективный путь расширения. Сложности у NAS возникают при масштабировании под требования I/O транзакционных рабочих нагрузок, поскольку слой файловой системы вносит накладные расходы, которые невозможно устранить независимо от количества добавляемого оборудования.

Сети хранения данных (SAN) масштабируются одновременно по нескольким измерениям. К ткани можно подключать дополнительные массивы хранения, в качестве хостов можно добавлять новые серверы, а дополнительные коммутаторы SAN — объединять в единую ткань для расширения её топологии. Ткани Fibre Channel поддерживают межкоммутаторные соединения (ISL), позволяющие отдельным доменам коммутаторов совместно использовать ресурсы и таблицы маршрутизации, что даёт крупным средам возможность расширять ткань без её полного перепроектирования. Для предприятий, ожидающих значительного роста рабочих нагрузок или частого развертывания серверов, модель масштабируемости SAN представляет собой существенное преимущество по сравнению как с NAS, так и с DAS.

Аспекты гибридных облаков и частных облаков

По мере того как организации всё чаще создают частные облачные среды с использованием платформ виртуализации, вопрос архитектуры хранения данных приобретает дополнительные аспекты. Среды VMware с возможностями vSphere, vMotion и vSAN зависят от общей блочной системы хранения для поддержки живой миграции виртуальных машин между узлами. Без общей инфраструктуры хранения живая миграция недоступна, а функции высокой доступности не могут работать так, как задумано. Коммутатор SAN является базовым компонентом любого развертывания инфраструктуры VMware, где серьёзно относятся к обеспечению доступности.

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

Краткое резюме практических критериев выбора

Факторы, подлежащие оценке перед выбором

Самым важным фактором в процессе выбора является точная характеристика профиля операций ввода-вывода (I/O) ваших рабочих нагрузок. Транзакционные базы данных, гипервизоры виртуализации и приложения, выполняющие частые небольшие случайные операции ввода-вывода с низкими требованиями к задержке, относятся к рабочим нагрузкам SAN. Файловые репозитории, цели резервного копирования, среды совместного редактирования и архивы мультимедиа относятся к рабочим нагрузкам NAS. Приложения, работающие на одном сервере с предсказуемыми локальными шаблонами доступа, относятся к рабочим нагрузкам DAS. Неправильная идентификация профиля операций ввода-вывода является наиболее распространённой причиной несоответствия архитектуры.

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

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

Разработка стратегии многоуровневого хранения данных

Многие зрелые среды не выбирают единую архитектуру, а вместо этого внедряют многоуровневую стратегию, при которой каждый тип архитектуры используется для рабочих нагрузок, для которых он наиболее подходит. Производственные базы данных уровня 1 и хранилища данных виртуальных машин работают на инфраструктуре SAN с выделенной коммутационной сетью SAN для обеспечения максимальной производительности и доступности. Обмен файлами, домашние каталоги и архивы отделов реализуются на NAS. Серверы разработки, граничные узлы и специализированные устройства используют DAS там, где совместный доступ не требуется. Такой многоуровневый подход оптимизирует затраты за счёт избежания чрезмерного проектирования инфраструктуры для малокритичных рабочих нагрузок и одновременно гарантирует, что критически важные системы получают инфраструктуру требуемого качества.

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

Часто задаваемые вопросы

Какие типы рабочих нагрузок чаще всего требуют использования коммутатора SAN?

Рабочие нагрузки, которые наиболее выигрывают от инфраструктуры СХД, и, следовательно, требуют использования коммутатора СХД, включают корпоративные реляционные базы данных, кластеры виртуализации VMware и Hyper-V, конфигурации Oracle RAC, а также любые приложения, генерирующие высокие объёмы небольших случайных операций ввода-вывода блоками при критичных к задержкам пороговых значениях. Коммутатор СХД обеспечивает общую тканевую связность, позволяющую нескольким серверам одновременно обращаться к одному и тому же массиву хранения с постоянной производительностью и избыточностью путей. Без коммутатора СХД тканевая структура отсутствует, и модель совместно используемого блочного хранилища не может функционировать.

Может ли малый или средний бизнес оправдать инвестиции в коммутатор СХД?

Да, особенно если в среде используется виртуализация или требуется высокая доступность для любых рабочих нагрузок в производственной среде. Продукты начального уровня для SAN-коммутаторов разработаны специально для того, чтобы предоставить возможности SAN небольшим развертываниям без затрат и сложности полностью модульных корпоративных коммутаторов-директоров. Если в компании эксплуатируется более двух–трех серверов, используется VMware или Hyper-V для консолидации или невозможна незапланированная остановка производственных систем, то стоимость SAN-коммутатора, как правило, оправдана операционными преимуществами и повышением доступности, которые он обеспечивает.

Как iSCSI сравнивается с Fibre Channel в качестве протокола передачи данных в SAN?

iSCSI запускает протоколы блочного хранения данных поверх стандартной инфраструктуры Ethernet, что снижает стоимость оборудования за счёт устранения необходимости в специализированных адаптерах Fibre Channel и специализированной кабельной системе. Это жизнеспособный вариант транспорта для СХД в средах, где требования к задержкам являются умеренными, а существующая инфраструктура Ethernet уже развернута. Fibre Channel по-прежнему остаётся предпочтительным решением для наиболее требовательных к производительности и чувствительных к задержкам рабочих нагрузок, поскольку он был разработан исключительно для трафика хранения данных и обеспечивает детерминированные характеристики доставки, которые Ethernet может обеспечить лишь при тщательной настройке механизмов управления качеством обслуживания (QoS). Выбор между этими двумя технологиями зависит от требований к производительности и допустимого уровня затрат на выделенную или конвергентную сетевую инфраструктуру.

Что происходит при отказе коммутатора СХД и как минимизируется этот риск?

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