Сравнение SAN и NAS

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

Наша первая задача — отбросить маркетинговые термины и перейти к техническим. NAS расшифровывается как Network Attached Storage (сетевое хранилище данных), однако означает не совсем это, а SAN расшифровывается как Storage Area Network (сеть хранения данных), но, как правило, используется для обозначения устройства SAN, а не самой сети. В строгом смысле SAN — это любая сеть, выделенная для трафика хранения данных, однако в реальном мире этот термин так обычно не используется. В данном случае мы говорим об устройствах NAS и SAN и их сравнении, поэтому не будем использовать определение, включающее сеть, а не устройство. На самом деле оба термина — NAS и SAN — являются маркетинговыми и имеют несколько размытые границы именно по этой причине. Их достаточно точно для использования в обычной технической беседе, при условии что все участники понимают, что они означают, но при обсуждении их смысла следует отбросить звучные названия и придерживаться наиболее технических описаний. Оба термина в маркетинговом использовании подразумевают, что речь идёт о некой технологии, «превращённой в аплайанс», что делает использование терминов излишне сложным, но не более полезным.

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

Более простым из двух является SAN, который в строгом смысле представляет собой блочное устройство хранения данных. Любое устройство, представляющее своё хранилище вовне как блочное устройство, попадает в эту категорию и может использоваться взаимозаменяемо в зависимости от того, как оно применяется. Блочными устройствами хранения данных являются внешние жёсткие диски, DAS (Direct Attach Storage — хранилище с прямым подключением) и SAN. Все они фактически представляют собой одно и то же. Мы называем это внешним жёстким диском, когда подключаем его к настольному компьютеру. Мы называем это DAS, когда подключаем к серверу. Мы называем это SAN, когда добавляем какую-либо форму сети, как правило коммутатор, между устройством и конечным потребителем хранилища. Технологических различий между этими устройствами нет. Традиционный SAN можно напрямую подключить к настольному компьютеру и использовать как внешний жёсткий диск. Внешний жёсткий диск можно подключить к коммутатору и использовать несколькими устройствами в сети. Интерфейс между устройством хранения и системой, использующей его, — это блок. Распространённые протоколы блочного хранения включают iSCSI, Fibre Channel, SAS, eSATA, USB, Thunderbolt, IEEE1394 (aka Firewire), Fibre Channel over Ethernet (FCoE) и ATA over Ethernet (AoE). Устройство, подключённое к блочному хранилищу, всегда будет видеть представленное хранилище как дисковый накопитель — и ничем более.

NAS, также известный как «файлер», является файловым устройством хранения данных. Это означает, что он представляет своё хранилище как сетевую файловую систему. Таким образом, устройство, подключающееся к этому хранилищу, видит не дисковый накопитель, а монтируемую файловую систему. Когда NAS не упакован в виде аплайнса, мы просто называем его файловым сервером, и практически все вычислительные устройства — от настольных компьютеров до серверов — имеют определённую степень этой функциональности. Распространённые протоколы файловых устройств хранения включают NFS, SMB / CIFS и AFP. Существует и множество других, причём технически есть специальные случаи файловых протоколов хранения, такие как FTP и HTTP, которые тоже следовало бы квалифицировать как таковые. В крайнем примере традиционный веб-сервер является очень специализированной формой файлового устройства хранения данных.

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

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

Оба типа устройств имеют возможность, но не обязанность, предоставлять расширенные функции ниже «точки разграничения», в которой они передают хранилище внешнему миру. Оба могут, но не обязаны, предоставлять RAID, управление логическими томами, мониторинг и т. д. Файловое хранилище (NAS) также может предоставлять функции файловой системы, такие как Windows NTFS ACL.

Ключевое преимущество блочного хранилища заключается в том, что подключающиеся к нему системы получают возможность управлять системой хранения так, как если бы это был традиционный дисковый накопитель. Это означает, что RAID и управление логическими томами, которые, возможно, уже выполнялись в «чёрном ящике» устройства хранения, теперь при желании могут быть выполнены снова на более высоком уровне. Клиентские устройства не знают, что именно они видят, — только то, что это выглядит как дисковый накопитель. Поэтому можно выбрать доверие к нему (например, предположить, что в нём есть RAID достаточного уровня) или объединить несколько блочных устройств в RAID точно так же, как если бы они были обычными локальными дисками. Это крайне редко, но является интересным вариантом, и существуют продукты, разработанные для использования именно таким образом.

Чаще всего управление логическими томами, такое как Linux LVM, Solaris ZFS или Windows Dynamic Disks, применяется поверх представленного блочного хранилища, а затем поверх него используется файловая система. Это важно помнить: при использовании блочных устройств файловая система создаётся и управляется клиентским устройством, а не устройством хранения. Устройство хранения абсолютно не знает, как используется представляемое им блочное хранилище, и позволяет конечному пользователю использовать его так, как он считает нужным, с полным контролем. Это простирается даже до возможности объединять блочные устройства в цепочку, когда одно предоставляет хранилище следующему, которые, возможно, объединены в группы RAID, — блочные устройства хранения могут быть организованы в слои более или менее неограниченно.

В качестве альтернативы файловое устройство хранения данных содержит всю блочную часть хранилища, поэтому любые RAID, управление логическими томами и мониторинг должны обрабатываться файловым устройством. Затем поверх блочного хранилища применяется файловая система. Обычно это EXT4 в Linux, ZFS в FreeBSD и Solaris, Windows NTFS, хотя возможны и другие файловые системы — WAFL, XFS, JFS, BtrFS, UFS и другие. В этой файловой системе хранятся данные. Для их совместного использования с внешним миром применяется сетевая файловая система (также известная как распределённая файловая система), обеспечивающая интерфейс файловой системы с поддержкой сети — NFS, SMB и AFP являются наиболее распространёнными, хотя, как и в любом семействе протоколов, существуют многочисленные специальные и экзотические варианты.

Удалённое устройство, желающее использовать хранилище на файловом устройстве, будет видеть его по сети так же, как локальную файловую систему, и сможет монтировать его идентичным образом. Это делает файловое хранилище особенно простым и очевидным для конечных потребителей, поскольку оно совершенно естественно во всех отношениях. Мы используем сетевые файловые системы каждый день для обычной работы на настольном компьютере. Когда мы «подключаем диск» в Windows, например, мы используем сетевую файловую систему.

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

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

Файловое устройство хранения, с другой стороны, имеет естественный арбитраж, поскольку сетевая файловая система обрабатывает взаимодействие для доступа к реальной файловой системе, а файловые системы по своей природе являются многопользовательскими. Таким образом, если одна система, подключённая к файловому устройству хранения, вносит изменение, все системы немедленно осведомлены об этом изменении и не будут «наступать на ноги друг другу». Даже если они попытаются это сделать, файловая система устройства арбитрирует доступ и имеет последнее слово, не допуская этого. Это делает совместное использование данных простым и прозрачным для конечных пользователей. (Под «конечными пользователями» здесь я имею в виду в том числе системных администраторов.)

Это не означает, что нет средств совместного использования хранилища с блочного устройства, однако арбитраж не может быть обеспечен самим блочным устройством. Блочные устройства хранения можно сделать «совместно используемыми» с помощью так называемой кластерной файловой системы. Этот тип файловых систем берёт начало со времён, когда серверные кластеры совместно использовали ресурсы хранения, подключая два сервера контроллером SCSI с обоих концов одного SCSI-кабеля и присоединяя общие диски в середине кабеля. Единственным средством коммуникации между серверами была сама файловая система, поэтому были разработаны специальные кластерные файловые системы, позволяющие организовать взаимодействие между устройствами — уведомление каждого из них об изменениях, вносимых другим, — через саму файловую систему. На удивление это работает достаточно хорошо, однако кластерные файловые системы относительно редки: GFS от Red Hat и OCFS от Oracle являются одними из наиболее известных в традиционном серверном мире, а VMFS от VMware стала чрезвычайно известной благодаря использованию для хранения данных виртуализации. Обычные пользователи, включая системных администраторов, могут не иметь доступа к кластерным файловым системам или иметь потребности, не позволяющие их использовать. Важно также отметить, что арбитраж осуществляется через доверие, а не через принуждение, как в случае с файловым устройством хранения. В файловом устройстве само устройство обрабатывает арбитраж доступа, и обойти это невозможно. В случае блочных устройств с кластерной файловой системой любое устройство, подключённое к хранилищу, может игнорировать кластерную файловую систему и просто обойти пассивный арбитраж — это настолько просто, что обычно происходит случайно. Это может случиться при монтировании файловой системы с указанием неправильного типа файловой системы, через неправильное поведение накопителя или любое злонамеренное действие. Поэтому безопасность доступа на сетевом уровне критически важна для защиты блочного хранилища.

Базовая концепция, раскрываемая здесь, состоит в том, что блочные устройства хранения — это «тупые» устройства (нечто вроде продвинутого дискового накопителя), а файловые устройства хранения — «умные» устройства (нечто вроде традиционного сервера). Файловые устройства хранения должны содержать полноценный работающий «компьютер» с процессором, памятью, хранилищем, файловой системой и сетевыми интерфейсами. Блочные устройства хранения могут содержать всё это, но не обязаны. В простейшем виде блочные устройства хранения могут представлять собой не более чем дисковый накопитель с подключённым USB- или Ethernet-адаптером. На самом деле нередко они представляют собой не более чем RAID-контроллер плюс адаптеры Ethernet или Fibre Channel.

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

Я люблю думать о протоколах блочного хранения как о потоке «standard out», как в командной строке. Таким образом, базовым уровнем любого «конвейера» хранения всегда является блочное устройство, и многочисленные блочные устройства или преобразования могут существовать, причём каждое передаётся следующему, пока результат остаётся протоколом блочного хранения. Мы прерываем цепочку только тогда, когда применяем файловую систему. Таким образом, аппаратный RAID, сетевой RAID, управление логическими томами и т. д. могут применяться в различных комбинациях по мере необходимости. Блочное хранилище — это воистину не просто блоки данных, но строительные блоки систем хранения.

Один весьма интересный момент: поскольку блочные устройства хранения можно объединять в цепочки, а сетевые устройства хранения должны принимать блочное хранилище в качестве «входных данных», довольно распространена ситуация, когда блочное устройство хранения (SAN) используется в качестве резервного хранилища для файлового устройства хранения (NAS), особенно в высокопроизводительных системах. Они могут сосуществовать в одном корпусе или работать совместно в сети.