Когда стоит задуматься о SAN?

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

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

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

Очевидно, что стремление внедрить SAN настолько сильно, что нередко целые проекты разрабатываются почти без иной цели, кроме как — похоже — оправдать покупку SAN. Как и в любом проекте, первый вопрос, который необходимо задать: «Какую бизнес-задачу мы пытаемся решить?» — и отталкиваться от этого, а не от «Мы хотим купить SAN, где его применить?». SAN сложны, а сложность порождает хрупкость. Очень часто SAN несут высокие затраты. Но самый пугающий аспект SAN — повсеместная нехватка глубоких профессиональных знаний о них. SAN создают огромные технические и бизнес-риски, которые необходимо преодолеть, чтобы оправдать их применение. SAN, без сомнения, очень интересны и весьма полезны, но одного этого редко бывает достаточно, чтобы оправдать желание их приобрести.

Мы называем SAN «хранилищем последнего резерва». Это означает, что при выборе типа хранилища вы надеетесь обойтись любой другой альтернативой — локальными дисками, DAS (Direct Attach Storage) или NAS (Network Attached Storage) — вместо SAN. В большинстве случаев другие варианты отлично справляются. Но бывают ситуации, когда бизнес-потребности предъявляют требования, которые разумно можно удовлетворить только с помощью SAN. Когда такое происходит, у нас нет выбора и приходится использовать SAN. Однако, как правило, его можно избежать в пользу более простых и обычно менее затратных или рискованных вариантов.

По моим наблюдениям, большинство людей, желающих внедрить SAN, делают это под влиянием ряда заблуждений.

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

Второе: SAN означает «большой», а NAS — «маленький». Никакой такой связи нет. Как SAN, так и NAS могут быть практически любого масштаба и качества. Обе технологии охватывают весь спектр размеров, и по выбранной технологии никак нельзя судить, большое устройство или нет. Опять же, как и в предыдущем случае, SAN технически может быть «меньше» решения NAS благодаря возможной простоте, но это частный случай и в основном лишь теоретический, хотя на рынке есть SAN-продукты такой категории — просто встречаются они крайне редко.

Третье: внутри корпуса SAN и NAS кардинально различаются. Это отнюдь не так: большинство современных устройств SAN и NAS являются так называемым «унифицированным хранилищем» — аппаратным комплексом, одновременно выполняющим функции как SAN, так и NAS. Это подчёркивает, что ключевое различие между ними заключается не во внутренней технологии, аппаратном обеспечении, размере или надёжности, а исключительно в протоколах передачи данных. SAN — это блочное хранилище, предоставляющее необработанные блочные устройства по сети с использованием таких протоколов, как Fibre Channel, iSCSI, SAS, ZSAN, ATA over Ethernet (AoE) или Fibre Channel over Ethernet (FCoE). NAS, напротив, использует сетевую файловую систему и предоставляет файлы по сети с помощью протоколов прикладного уровня, таких как NFS, SMB, AFP, HTTP и FTP, работающих поверх TCP/IP.

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

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

Шестое: принадлежность устройства к классу SAN устраняет присущие проблемы, связанные с выбором хранилища. Хороший пример — использование RAID 5. В случае сервера это считается плохой практикой, однако при работе с SAN (который теоретически гораздо важнее автономного сервера) тщательное планирование подсистемы хранения нередко игнорируется из убеждения, что SAN каким-то образом решает эти проблемы или что они попросту не применимы. Действительно, некоторые высококлассные SAN обладают определёнными средствами снижения рисков, которые редко встречаются в других решениях, однако это единичные случаи, ограниченные исключительно устройствами очень высокого класса, где и без того нечасто применяются хрупкие схемы. Опасная, но весьма распространённая практика — уделять большое внимание и тщательно планировать хранилище для физического сервера, а при использовании SAN пропускать это планирование, полагая, что SAN самостоятельно решает всё внутри или что оно попросту больше не нужно.

Опровергнув многие заблуждения о SAN, можно задаться вопросом: а уместны ли SAN вообще? Разумеется, они весьма важны и чрезвычайно ценны при правильном использовании. Главные преимущества SAN — консолидация и особые виды совместного доступа к хранилищу.

Консолидация исторически была главным мотивом, побуждавшим клиентов обращаться к SAN-решениям. SAN позволяет объединить множество файловых систем в единый дисковый массив, обеспечивая значительно более эффективное использование ресурсов хранения. Поскольку SAN работает на уровне блоков, он способен делать это везде, где традиционно использовалась локальная дисковая подсистема. Во многих серверах и даже настольных ПК пространство хранения расходуется впустую из-за необходимости резервирования под рост, планирования и дискретности ёмкости дисков. Если у нас есть двадцать серверов, каждый с дисковым массивом 300 ГБ, но каждый использует лишь 80 ГБ, потери огромны. С SAN можно было бы консолидировать данные всего на 1,6 ТБ плюс небольшой объём на накладные расходы и потратить на физические диски значительно меньше, чем если бы каждый сервер поддерживал собственное хранилище.

Начав консолидацию хранилища, мы начинаем искать расширенные возможности для неё. Объединив файловые системы многих серверов на одном SAN, мы получаем возможность — если наша реализация SAN это поддерживает — дедублировать и сжать эти данные, что во многих случаях, например для файловых систем серверов, может привести к значительному сокращению занятого пространства. Так что в нашем примере 1,6 ТБ могут сократиться до 800 ГБ и менее. Цифры консолидации становятся всё лучше и лучше.

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

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

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

В очень крупных средах SAN может также использоваться для обозначения точки разграничения между командами по хранению и системным инжинирингом, позволяя передавать ответственность на сетевом уровне — как правило, Fibre Channel или iSCSI. Такое чёткое разделение обязанностей может быть критически важным для обеспечения высокой степени разграничения команд в компаниях, стремящихся к чёткому разделению команд по хранению, сетям и системам. Это позволяет команде по хранению сосредоточиться исключительно на хранилище, а команде по системам — исключительно на системах, без какой-либо необходимости в знании реализаций другой команды.

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

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

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