Схд что это в компьютере

Обновлено: 03.07.2024

Думаю, многие заметили тенденции развития в окружающем нас компьютерном мире – переход от экстенсивной модели развития к интенсивной. Наращивание мегагерц процессоров уже не даёт видимого результата (см. обзор «Извечный вопрос: Intel или AMD?»), а развитие накопителей не поспевает за объёмом информации.

Если в случае процессоров всё более или менее понятно – достаточно собирать многопроцессорные системы и/или использовать несколько ядер в одном процессоре, то в случае вопросов хранения и обработки информации так просто от проблем не избавиться.

Существующая на данный момент панацея от информационной эпидемии – СХД. Название расшифровывается как Сеть Хранения Данных (SAN) или Система Хранения Данных. В любом случае – это специализированное железо и ПО, предназначенное для работы с огромными массивами ценной информации.

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

Основные проблемы, решаемые СХД

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

1. Децентрализация информации – если раньше все данные могли храниться буквально на одном жёстком диске, то сейчас любая функциональная система требует отдельного хранилища – к примеру, серверов электронной почты, СУБД, домена и так далее. Ситуация усложняется в случае распределённых офисов (филиалов).

2. Лавинообразный рост информации – зачастую количество жёстких дисков, которые вы можете установить в конкретный сервер, не может покрыть необходимую системе ёмкость.

Невозможность полноценно защитить хранимые данные – действительно, ведь довольно трудно произвести даже backup данных, которые находятся не только на разных серверах, но и разнесены территориально.

Недостаточная скорость обработки информации – каналы связи между удалёнными площадками пока оставляют желать лучшего, но даже при достаточно «толстом» канале не всегда возможно полноценное использование существующих сетей, например, IP, для работы.

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

3. Сложно или невозможно предугадать требуемый объём дискового пространства при развертывании компьютерной системы.

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

Неэффективная утилизация ресурсов – порой не угадать, в каком сервере данные будут расти быстрее. В сервере электронной почты может быть свободен критически малый объём дискового пространства, в то время как другое подразделение будет использовать всего лишь 20% объёма недешёвой дисковой подсистемы (например, SCSI).

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

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

6.Низкий экономический эффект внедрения «классических» решений – по мере роста информационной сети, больших объёмов данных и всё более распределённой структуры предприятия финансовые вложения оказываются не столь эффективны и зачастую не могут решить возникающих проблем.

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

В свете вышеперечисленных проблем, которые рано или поздно, полностью или частично настигают любую динамично развивающуюся компанию, попробуем обрисовать системы хранения данных – такими, какими они должны быть. Рассмотрим типовые схемы подключения и виды систем хранения данных.

Мегабайты или транзакции?

Если раньше жёсткие диски находились внутри компьютера (сервера), то теперь им там стало тесно и не очень надёжно. Самое простое решение (разработанное достаточно давно и применяемое повсеместно) – технология RAID.

При организации RAID в любых системах хранения данных дополнительно к защите информации мы получаем несколько неоспоримых преимуществ, одно из которых – скорость доступа к информации.

С точки зрения пользователя или ПО, скорость определяется не только пропускной способностью системы (Мбайт/с), но и числом транзакций – то есть числом операций ввода-вывода в единицу времени (IOPS). Увеличению IOPS способствует, что вполне логично, большее число дисков и те методики повышения производительности, которые предоставляет контроллер RAID (к примеру, кэширование).

Если для просмотра потокового видео или организации файл-сервера больше важна общая пропускная способность, то для СУБД, любых OLTP (online transaction processing) приложений критично именно число транзакций, которые способна обрабатывать система. А с этим параметром у современных жёстких дисков всё не так радужно, как с растущими объёмами и, частично, скоростями. Все эти проблемы призвана решить сама система хранения данных – чуть ниже будет видно, как и какими методами.

Уровни защиты

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

Однако, кроме схем RAID, существует и более низкоуровневая защита данных, реализованная «поверх» технологий и решений, внедрённых в сам жёсткий диск его производителем. К примеру, у одного из ведущих производителей СХД – компании ЕМС – существует методика дополнительного анализа целостности данных на уровне секторов накопителя. Секторы на жёстких дисках, установленных в системы хранения данных ЕМС, имеют размер не 512 байт (стандарт), а 520 байт – лишние 8 байт на каждый сектор играют роль своеобразной базы данных, куда СХД записывает информацию о «здоровье» каждого сектора (данная методика, насколько известно, не применяется больше ни у одного производителя).

Как известно, у жёстких дисков с интерфейсом IDE существует технология SMART, призванная предсказывать возможные проблемы в работе диска, которая зачастую работает очень неточно, что сводит её ценность практически к нулю. У дисков же, использующихся в серьёзных СХД (диски SCSI и FibreChannel), изначально не было технологии SMART – поэтому оценка целостности и верификация данных каждого конкретного сектора – большой плюс, позволяющий дополнительно защитить данные и уведомить администратора системы о возможных проблемах задолго до момента их реального наступления.

Жёсткий диск может быть и исправен, но обладать так называемыми проблемами «мягких ошибок» («soft errors») – когда данные в секторе записаны корректно, но чтение их может давать различный результат. Такой вариант неприемлем, но «remap» (подмена) такого сектора средствами самого жёсткого диска не происходит – в этом случае и спасает технология анализа каждого сектора, применяемая у EMC.

Интерфейсы подключения

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

Рассмотрим два «простых» внешних интерфейса подключения – самый ходовой интерфейс SCSI и самый распространённый на данный момент интерфейс сетей хранения данных FibreChannel.

SCSI чем-то похож на всем известный IDE – это параллельный интерфейс, допускающий до 16 устройств на одной шине (для IDE, как вы помните – 2 устройства на канал). На данный момент максимальная скорость протокола SCSI – 320 Мбайт/с (в разработке находится версия для 640 Мбайт/с), часто так и пишут – SCSI U320. Недостатки SCSI очевидны – толстые неудобные кабели, имеющие ограничение на максимальную длину (до 25 м), не обладающие помехозащищенностью. Также ограничения накладывает сам протокол SCSI – обычно это один инициатор на шине (SCSI-контроллер) + ведомые устройства (диски, стримеры и т.д.).

Когда внешняя дисковая стойка имеет интерфейс SCSI, нам достаточно поставить в хост-машину SCSI-адаптер или SCSI-RAID и с помощью многожильного SCSI-кабеля подключиться к разъему на внешней дисковой стойке.

FibreChannel очень популярен в среде IT-специалистов – они-то знают, какие преимущества несёт эта технология, почти неизвестная «домашним пользователям». Причина понятна – дороговизна оборудования и предназначение протокола FibreChannel (FCP) для развёртывания масштабных сетей хранения данных (SAN), что находит применение только в крупных компаниях. Однако такая практика является наилучшим решением для всех описанных выше проблем, в чем мы в дальнейшем убедимся.

Не стоит путать «Fiber» и «Fibre» – технология, как и протокол, специально названа FibreChannel, чтобы хоть чем-то отличаться от технологий, построенных на оптических средах передачи (fiber) – ведь FibreChannel может работать и по «меди». На практике современный FibreChannel имеет скорости 2 Гбит (FibreChannel 2 Gb) или 4 Гбит (FibreChannel 4 Gb) full- duplex, то есть такая скорость обеспечивается одновременно в обе стороны. В переводе на скорость канала получаем 200 или 400 Мбайт/с по оптическому двухжильному кабелю.

Расстояния практически не ограничены – от стандартных 300 метров на самом «обычном» оборудовании до 2000 км для мощных коммутаторов, так называемых «директоров». Главный плюс интерфейса FibreChannel – возможность объединения многих устройств хранения и хостов (серверов) в единую сеть хранения данных (SAN). Более приземлённые мелочи – большие расстояния (чем со SCSI), возможность агрегирования каналов, возможность резервирования путей доступа, «горячего подключения» оборудования, большая помехозащищенность.

Физически используются двухжильные многомодовые или одномодовые оптические кабели (с коннекторами типа LC или SC) и так называемые SFP – оптические трансмиттеры на основе светодиодных или лазерных излучателей – от этих двух компонент зависит скорость передачи и максимальное расстояние между устройствами.

Конструкция стоек

Далее мы будем использовать устоявшееся словосочетание «дисковая стойка». Им обозначают некую коробку с жёсткими дисками, к которой подключаются серверы и которая может содержать, кроме дисков, также кэш-память, процессоры, несколько блоков питания, внутреннее системное ПО и так далее.

Конструктивно дисковая стойка, то есть наша система хранения данных, рассчитана на установку в монтажный шкаф. Она включает в себя от 8 до 15 жёстких дисков «горячей замены» (на 1 дисковую полку) с интерфейсом SATA/PATA, SCSI или FibreChannel, имеет несколько внешних портов SCSI/FibreChannel для подключения хостов. Дисковая стойка может иметь несколько блоков питания «горячей замены», включать в свой состав кэш-память (и батарею резервирования кэш-памяти), контроллеры или процессорные модули, работающие на базе специализированного ПО, обеспечивающего полное управление системой и дополнительную уникальную функциональность.

Самый простой вариант внешней дисковой стойки – это SCSI+ SCSI стойка с 14 дисками, в которой установлены два блока питания и которая может подключаться одновременно к 2 серверам (каждый из них может иметь доступ к своим 7 дискам или работать в кластерном режиме со вторым сервером). Никакого кэша или процессоров в такой стойке нет – по сути, она просто расширяет внутреннюю дисковую ёмкость сервера и добавляет некоторую уникальность – позволяет создавать кластер.

При использовании таких простых стоек необходим RAID-контроллер, установленный на сервере – сама стойка в этом случае создать RAID своими силами не способна. Типичный пример – DELL PowerVault 220 S.

Более продвинутый вариант – стойка со своими процессорами, кэшем и ПО, которая уже способна сама создавать RAID-массив и управляться пользователем. Обычно он имеет интерфейсы SCSI+SATA, типичный пример – Axus DemonRAID.

Отличие в том, что уже нет надобности ставить в сервер RAID-контроллер с внешним интерфейсом – достаточно простого адаптера SCSI. В теории такие стойки обеспечивают большую производительность и функциональность, чем аналогичные неуправляемые беспроцессорные системы. Но делать управляемые стойки SCSI+SCSI особого смысла нет, а SCSI+SATA в большинстве случаев проигрывает по скорости дисковой подсистемы (SATA медленнее SCSI), хотя выигрывает по ёмкости и цене. В принципе, зная о большом числе накопителей в системах хранения данных, кэш-памяти и специализированных процессорах, можно сразу предположить, что скорости, обеспечиваемые стойкой, несоизмеримы со скоростями в любой внутренней дисковой подсистеме. Этот момент является одним из важных плюсов СХД и, естественно, позволяет работать с СХД многим хостам одновременно.

Следующий очень важный момент – обеспечение дисковой стойкой большей надёжности и уникальной функциональности, которая была недоступна (или просто практически нереализуема) при использовании в сервере внутренних дисков как основном хранилище данных. Кратко рассмотрим основные плюсы, получаемые при внедрении полноценного решения на базе СХД, а их практическую реализацию мы опишем в следующей статье, при рассмотрении конкретных моделей систем хранения:

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

Высокая доступность данных – обеспечивается продуманными функциями сохранения целостности данных (использование 520 байт в секторе, использование технологии RAID, создание полных и мгновенных копий данных внутри дисковой стойки, реплицирование данных на удаленную СХД и т.д.) и возможностью добавления (обновления) аппаратуры и программного обеспечения в беспрерывно работающую систему хранения данных без остановки комплекса;

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

Высокая производительность – определяется числом жёстких дисков, объёмом кэш-памяти, вычислительной мощностью процессорной подсистемы, числом внутренних (для жёстких дисков) и внешних (для подключения хостов) интерфейсов, а также возможностью гибкой настройки и конфигурирования системы для работы с максимальной производительностью;

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

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

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

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

Что такое СХД и какие проблемы она решает

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

Если раньше все данные могли храниться буквально на одном жёстком диске, то сейчас любая функциональная система требует отдельного хранилища – к примеру, серверов электронной почты, СУБД, домена и так далее. Поэтому с помощью СХД можно организовать децентрализацию информации (рассредоточение её по разным хранилищам).

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

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

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

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

Устройство СХД

Основные компоненты типичной СХД — массив жёстких дисков (HDD или SSD), кэш-память, контроллер дискового массива, внешний корпус и несколько блоков питания.

Главная фишка СХД — это скорость работы дисковой системы. Например, если ваши диски стоят внутри сервера они не будут работать с такой же производительностью, как сервер подключённый к СХД.

Какие бывают системы хранения данных

Существует классификация СХД: они делятся на файловые, блочные и объектные. Каждый вид СХД определяет в каком виде хранятся данные, способ доступа к ним, и, как результат, простоту управления и скорость доступа к данным.

Файловые

Хранят информацию в виде файлов, собранных в каталоги (папки). Файлы организуются и извлекаются благодаря метаданным, которые сообщают, где находится тот или иной файл. Условно такую систему можно представить в виде каталога.

Блочные

Данные хранятся независимо друг от друга. Каждому такому блоку присваивается идентификатор, который позволяет системе размещать каждый блок, где ей удобно. Блочные хранилища не полагаются на единственный путь к данным (в отличии от файловых хранилищ).

Объектные

Расщепляют файлы на «объекты», которые находятся в одном, общем хранилище. Оно может быть поделено на тома, каждый из которых может иметь уникальный идентификатор и подробные метаданные, которые позволяют быстро находить объекты. Подобный подход — это распределённая система.

Принцип работы СХД — NAS, SAN и DAS

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

На основе классификации выше выделяют два основных типа СХД: они различаются уровнем хранения, чтения и записи данных.

Первый вариант работает с данными файлового уровня. Это означает, что такое хранилище, по сути, функционирует как сервер с собственной файловой системой. На практике клиентский сервер даёт такие команды, как «записать Х битов в этот файл» или «извлечь Х битов из этого файла» соответственно. Этот тип хранилища называется NAS.

Второй вариант — это доступ к данным на уровне блоков. Это ускоряет обмен данными между сервером и хранилищем, поскольку он прямой, то есть «блок записи X» или «блок вызова X». Такие репозитории связаны друг с другом и с сервером либо как DAS, либо через SAN.

О каждом из них расскажем подробнее.

NAS расшифровывается как Network Attached Storage, что можно условно перевести как сетевое хранилище. Поскольку данные обрабатываются на уровне файлов, сервер представляется NAS как сетевой сервер со своей собственной файловой системой.

Если объяснить проще — представьте себе стационарный компьютер, который подключён к домашнему роутеру. На нём хранятся фото, видео, документы и другие данные. Сетевой доступ разрешен всем пользователям — приблизительно так выглядит NAS.

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

Преимущества NAS:

Доступность и низкая стоимость.
Простота подключения и управления.
Гибкость, возможность быстро увеличить объём для хранения данных.
Универсальность клиентов (компьютер под управлением любой операционной системы может получить доступ к файлам).

Недостатки NAS:

Хранение данных только в виде файлов.
Медленный доступ к информации по сетевым протоколам (по сравнению с локальной системой).
Невозможность работы некоторых приложений с сетевыми дисками.

DAS расшифровывается как Direct Attach Storage — прямое подключение к рабочей станции, хранилищу). Например, подключение внешнего диска по USB условно можно назвать DAS.

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

Внутри системы находится блок питания, охлаждение и RAID-контроллер, который обеспечивает надёжность и отказоустойчивость хранилища. Управляется при помощи встроенной операционной системы.

Достоинства DAS:

Легкость развёртывания и администрирования.
Высокая скорость передачи данных.
Низкая стоимость оборудования.

Недостатки DAS:

Требует выделенного сервера).
Ограничения в подключениях (не больше двух серверов).

В свою очередь SAN — это сети хранения данных. Как правило они представлены в виде внешних хранилищ на нескольких сетевых блочных устройствах и реализованы в виде протокола FC (Fiber Channel) или iSCSI (Internet Small Computer System Interface). Это блочный доступ непосредственно к устройству хранения — диску или наборов дисков в виде RAID-групп или логических устройств.

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

Преимущества SAN:

Высокая скорость работы, низкая задержка.
Гибкость и масштабируемость.
Хранение данных блоками.
Высокая надёжность обмена и хранения данных.
Разгрузка подсети от служебного трафика.

Недостатки SAN:

Сложность проектирования
Высокая стоимость.
Невозможность некоторых приложений и систем работать с протоколом iSCSI.

Как выбрать СХД?

В первую очередь нужно понимать, какие задачи она будет решать. Важно определиться с несколькими базовыми параметрами.

Тип данных

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

Объём данных

От этого зависит выбор дисковых накопителей. Иногда можно обойтись SSD потребительского класса — если известно, что ёмкость СХД даже в худшем случае не будет превышать 300 ГБ, а скорость доступа не критична.

Отказоустойчивость

Необходимо представлять, какова стоимость потери данных за определённое время. Это поможет рассчитать RPO (Recovery-Point Objective) и RTO (Recovery Time Objective), а также избежать лишних затрат на резервное копирование. Бэкапы, бэкапы и ещё раз бэкапы.

Производительность

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

Вендор

Иногда даже для ресурсоемкого сервиса подойдет бюджетное или среднеуровневое решение (StarWind, Huawei, Fujitsu). Однако у топовых производителей — NetApp, HPE, Dell EMC — линейка продуктов достаточно широкая, и сравнительно недорогие СХД здесь также можно найти. В любом случае, желательно сильно не расширять количество вендоров на одной инфраструктуре.

Если сейчас вы находитесь в поисках решения для работы с данными, арендовать выделенный web-сервер и СХД (системы хранения данных) можно в одном из наших ЦОД. Мы, со своей стороны, обеспечим сервер быстрым соединением с интернетом на скорости до 10 Гбит/сек, постоянным подключением к электричеству и поддержкой 27/7 ;).

Решил написать небольшую статейку о сетях хранения данных (СХД), тема эта достаточно интересная, но на Хабре почему-то не раскрыта. Постараюсь поделиться личным опытом по построению и поддержке SAN.

Что это?
Сеть хранения данных, или Storage Area Network — это система, состоящая из собственно устройств хранения данных — дисковых, или RAID — массивов, ленточных библиотек и прочего, среды передачи данных и подключенных к ней серверов. Обычно используется достаточно крупными компаниями, имеющими развитую IT инфраструктуру, для надежного хранения данных и скоростного доступа к ним.
Упрощенно, СХД — это система, позволяющая раздавать серверам надежные быстрые диски изменяемой емкости с разных устройств хранения данных.

Немного теории.
Сервер к хранилищу данных можно подключить несколькими способами.
Первый и самый простой — DAS, Direct Attached Storage (прямое подключение), без затей ставим диски в сервер, или массив в адаптер сервера — и получаем много гигабайт дискового пространства со сравнительно быстрым доступом, и при использовании RAID-массива — достаточную надежность, хотя копья на тему надежности ломают уже давно.
Однако такое использование дискового пространства не оптимально — на одном сервере место кончается, на другом его еще много. Решение этой проблемы — NAS, Network Attached Storage (хранилище, подключенное по сети). Однако при всех преимуществах этого решения — гибкости и централизованного управления — есть один существенный недостаток — скорость доступа, еще не во всех организациях внедрена сеть 10 гигабит. И мы подходим к сети хранения данных.

Главное отличие SAN от NAS (помимо порядка букв в аббревиатурах) — это то, каким образом видятся подключаемые ресурсы на сервере. Если в NAS ресурсы подключаются протоколам NFS или SMB, в SAN мы получаем подключение к диску, с которым можем работать на уровне операций блочного ввода-вывода, что гораздо быстрее сетевого подключения (плюс контроллер массива с большим кэшем добавляет скорости на многих операциях).

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

* снимаем ограничения на дальность подключения SCSI-устройств, которые обычно ограничены проводом в 12 метров,
* уменьшаем время резервного копирования,
* можем грузиться с SAN,
* в случае отказа от NAS разгружаем сеть,
* получаем большую скорость ввода-вывода за счет оптимизации на стороне системы хранения,
* получаем возможность подключать несколько серверов к одному ресурсу, то нам дает следующих двух зайцев:
o на полную используем возможности VMWare — например VMotion (миграцию виртуальной машины между физическими) и иже с ними,
o можем строить отказоустойчивые кластеры и организовывать территориально распределенные сети.

Что это дает?
Помимо ~~освоения бюджета~~ оптимизации системы хранения данных, мы получаем, вдобавок к тому что я написал выше:

* увеличение производительности, балансировку нагрузки и высокую доступность систем хранения за счет нескольких путей доступа к массивам;
* экономию на дисках за счет оптимизации расположения информации;
* ускоренное восстановление после сбоев — можно создать временные ресурсы, развернуть на них backup и подключить к ним сервера, а самим без спешки восстанавливать информацию, или перекинуть ресурсы на другие сервера и спокойно разбираться с умершим железом;
* уменьшение время резервного копирования — благодаря высокой скорости передачи можно бэкапиться на ленточную библиотеку быстрее, или вообще сделать snapshot (мгновенный снимок) с файловой системы и спокойно архивировать его;
* дисковое место по требованию — когда нам нужно — всегда можно добавить пару полок в систему хранения данных.
* уменьшаем стоимость хранения мегабайта информации — естественно, есть определенный порог, с которого эти системы рентабельны.
* надежное место для хранения mission critical и business critical данных (без которых организация не может существовать и нормально работать).
* отдельно хочу упомянуть VMWare — полностью все фишки вроде миграции виртуальных машин с сервера на сервер и прочих вкусностей доступны только на SAN.

Из чего это состоит?
Как я писал выше — СХД состоит из устройств хранения, среды передачи и подключенных серверов. Рассмотрим по порядку:

Системы хранения данных обычно состоят из жестких дисков и контроллеров, в уважающей себя системе как правило всего по 2 — по 2 контроллера, по 2 пути к каждому диску, по 2 интерфейса, по 2 блока питания, ~~по 2 администратора~~. Из наиболее уважаемых производителей систем следует упомянуть HP, IBM, EMC и Hitachi. Тут процитирую одного представителя EMC на семинаре — «Компания HP делает отличные принтеры. Вот пусть она их и делает!» Подозреваю, что в HP тоже очень любят EMC. Конкуренция между производителями нешуточная, впрочем, как и везде. Последствия конкуренции — иногда вменяемые цены за мегабайт системы хранения и проблемы с совместимостью и поддержкой стандартов конкурентов, особенно у старого оборудования.

Среда передачи данных. Обычно SAN строят на оптике, это дает на текущий момент скорость в 4, местами в 8 гигабит на канал. При построении раньше использовались специализированные хабы, сейчас больше свитчи, в основном от Qlogic, Brocade, McData и Cisco (последние два на площадках не видел ни разу). Кабели используются традиционные для оптических сетей — одномодовые и многомодовые, одномодовые более дальнобойные.
Внутри используется FCP — Fibre Channel Protocol, транспортный протокол. Как правило внутри него бегает классический SCSI, а FCP обеспечивает адресацию и доставку. Есть вариант с подключением по обычной сети и iSCSI, но он обычно использует (и сильно грузит) локальную, а не выделенную под передачу данных сеть, и требует адаптеров с поддержкой iSCSI, ну и скорость помедленнее, чем по оптике.

Есть еще умное слово топология, которое встречается во всех учебниках по SAN. Топологий несколько, простейший вариант — точка-точка (point to point), соединяем между собой 2 системы. Это не DAS, а ~~сферический конь в вакууме~~ простейший вариант SAN. Дальше идет управляемая петля (FC-AL), она работает по принципу «передай дальше» — передатчик каждого устройства соединен с приемником последующего, устройства замкнуты в кольцо. Длинные цепочки имеют свойство долго инициализироваться.

Ну и заключительный вариант — коммутируемая структура (Fabric), она создается с помощью свитчей. Структура подключений строится в зависимости от количества подключаемых портов, как и при построении локальной сети. Основной принцип построения — все пути и связи дублируются. Это значит, что до каждого устройства в сети есть минимум 2 разных пути. Здесь тоже употребимо слово топология, в смысле организации схемы подключений устройств и соединения свитчей. При этом как правило свитчи настраиваются так, что сервера не видят ничего, кроме предназначенных им ресурсов. Это достигается за счет создания виртуальных сетей и называется зонированием, ближайшая аналогия — VLAN. Каждому устройству в сети присваивается аналог MAC-адреса в сети Ethernet, он называется WWN — World Wide Name. Он присваивается каждому интерфейсу и каждому ресурсу (LUN) систем хранения данных. Массивы и свитчи умеют разграничивать доступ по WWN для серверов.

Сервера подключают к СХД через HBA - Host Bus Adapter-ы. По аналогии с сетевыми картами существуют одно-, двух-, четырехпортовые адаптеры. Лучшие собаководы рекомендуют ставить по 2 адаптера на сервер, это позволяет как осуществлять балансировку нагрузки, так и обеспечивает надежность.

А дальше на системах хранения нарезаются ресурсы, они же диски (LUN) для каждого сервера и оставляется место в запас, все включается, установщики системы прописывают топологию, ловят глюки в настройке свитчей и доступа, все запускается и все живут долго и счастливо*.
Я специально не касаюсь разных типов портов в оптической сети, кому надо — тот и так знает или прочитает, кому не надо — только голову забивать. Но как обычно, при неверно установленном типе порта ничего работать не будет.

Из опыта.
Обычно при создании SAN заказывают массивы с несколькими типами дисков: FC для скоростных приложений, и SATA или SAS для не очень быстрых. Таким образом получаются 2 дисковые группы с различной стоимостью мегабайта — дорогая и быстрая, и медленная и печальная дешевая. На быструю вешаются обычно все базы данных и прочие приложения с активным и быстрым вводом-выводом, на медленную — файловые ресурсы и все остальное.

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

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

Часто при создании СХД фирмы не заказывают поддержку системы производителем. Обычно это оправдано, если у фирмы есть штат грамотных компетентных админов (которые уже 100 раз назвали меня чайником) и изрядный капитал, позволяющий закупить запасные комплектующие в потребных количествах. Однако компетентных админов обычно переманивают интеграторы (сам видел), а денег на закупку не выделяют, и после сбоев начинается цирк с криками «Всех уволю!» вместо звонка в саппорт и приезда инженера с запасной деталью.

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

Про VMWare. Насколько я знаю (спецы по виртуализации поправьте меня), только у VMWare и Hyper-V есть функционал, позволяющий «на лету» перекидывать виртуальные машины между физическими серверами. И для его реализации требуется, чтобы все сервера, между которыми перемещается виртуальная машина, были подсоединены к одному диску.

Про кластеры. Аналогично случаю с VMWare, известные мне системы построения отказоустойчивых кластеров (Sun Cluster, Veritas Cluster Server) — требуют подключенного ко всем системам хранилища.

Пока писал статью — у меня спросили — в какие RAIDы обычно объединяют диски?
В моей практике обычно делали или по RAID 1+0 на каждую дисковую полку с FC дисками, оставляя 1 запасной диск (Hot Spare) и нарезали из этого куска LUN-ы под задачи, или делали RAID5 из медленных дисков, опять же оставляя 1 диск на замену. Но тут вопрос сложный, и обычно способ организации дисков в массиве выбирается под каждую ситуацию и обосновывается. Та же EMC например идет еще дальше, и у них есть дополнительная настройка массива под приложения, работающие с ним (например под OLTP, OLAP). С остальными вендорами я так глубоко не копал, но догадываюсь, что тонкая настройка есть у каждого.

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

Специалисты, которые отвечают за выбор СХД, часто сталкиваются со множеством терминов: чего стоят только репликация, дедупликация и компрессия. Многие из них могут оказаться непонятными – особенно если человек раньше мало интересовался темой хранения данных.

Какие основные понятия необходимо знать ИТ-директору или системному администратору, принимая решение о выборе СХД – рассказывает генеральный директор компании «Аэродиск» Вячеслав Володкович.

Ответственный специалист может столкнуться со сложностями ещё на первых этапах выбора СХД – определяя, какой тип системы необходим компании. В целом СХД могут быть реализованы в трёх вариантах: DAS, SAN и NAS. Накопители DAS (Direct Attached Storages) напрямую подключаются к устройствам, управляющим их работой. Например, по такому принципу работает компьютер с жёстким диском или другим внешним устройством, хранящим данные. Однако изначально термин применялся к мейнфреймам – большим высокопроизводительным серверам.

Системы вида DAS появились первыми, но они не обеспечивали необходимую скорость передачи данных – а ещё не могли предоставить условия для их совместного использования. Поэтому сегодня более распространены два других типа СХД, а именно NAS и SAN.

NAS или Network-attached Storage – это сетевое хранилище данных; система хранения, которая предоставляет файловый доступ к сети. Здесь сервер получает доступ к сети, выполненной на определённой файловой системе. И эта файловая система уже установлена на СХД. В случае NAS доступ к сети чаще всего реализован в виде протоколов NFS (Network File System) или SMB (Server Message Block).

В свою очередь SAN – это сети хранения данных. Как правило они представлены в виде внешних хранилищ на нескольких сетевых блочных устройствах и реализованы в виде протокола FC (Fiber Channel) или iSCSI (Internet Small Computer System Interface). Чаще используется Fiber Channel – он основан на оптических сетях и способен обеспечить высокую пропускную способность и низкий уровень задержек. При этом протокол iSCSI основан на классических IP-сетях, и его внедрение связано с меньшими затратами.

Системы SAN предоставляют блочный доступ непосредственно к устройству хранения – диску или наборов дисков в виде RAID-групп или логических устройств. Такие логические устройства называются LUN или Logical Unit Number. И одно логическое устройство доступно одному серверу или кластеру серверов.

Таким образом, сервер (точнее операционная система сервера), который получает блочный доступ к системе хранения, форматирует LUN в свою файловую систему в зависимости от задач. Если он работает на ОС Microsoft Windows, то это файловая система NTFS или ReFS; если продукты VMware – файловая система VMFS. А если сервер работает на Linux, то он может воспроизводить целую «гирлянду» файловых систем Extfs, Ext2, Ext3, XFS и тому подобных.

После того, как специалист разобрался с типами СХД, а также видами доступа к данным и различными протоколами, возникает ещё один вопрос – как правильно оценить производительность системы? Здесь на помощь приходят три ключевых показателя: IOPS, то есть количество операций ввода-вывода в секунду; latencу или задержка, а также MBS – количество мегабайт в секунду.

Количество переданных мегабайт в секунду характеризует скорость потока чтения и записи данных, измеряемого в мегабайтах в секунду. А показатель IOPS (Input/Output Operations Per Second) говорит о том, какое максимальное количество операций чтения или записи может выдержать СХД в зависимости от размера блока данных. Эти операции могут быть очень разными: отличаться размерами блока и глубиной очереди, иметь случайный или последовательный характер.

Что касается показателя latency, то он используется в двух случаях: при чтении и записи информации. Для оценки задержки при чтении он показывает, какое время проходит с момента получения задания до отправки информации. А для оценки задержки при записи – сколько времени занимает весь процесс с момента получения информации до подтверждения записи.

Показатели производительности имеют ключевое значение при тестировании СХД – и акцент на том или ином показателе зависит от задач, которые будут стоять перед системой.

Например, компания создаёт высоконагруженную транзакционную систему управления базами данных – скажем, PostgreSQL или Oracle. В таком случае необходимо воспроизвести характерную для этой СУБД нагрузку. Выполнив тест, можно понять, как примерно будет себя вести система хранения при решении задач СУБД, а также на какие показатели обращать особое внимание, каких значений они будут достигать. Для примера с транзакционными СУБД обычно подходит тест, который эмулирует случайный характер чтения и записи (как правило в соотношении 70 на 30) с небольшим блоком данных (как правило от 4-х до 64-х килобайт в секунду). Выполнив подобный тест, можно в первом приближении сделать вывод о возможности использования СХД для целей транзакционной СУБД.

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

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

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

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

В целом снэпшоты бывают двух видов: пересылка при записи или redirect on write, а также копирование при записи – copy on write. Снэпшоты вида redirect on write не снижают производительности СХД, при этом не почти не занимают дополнительного объема (они ничего не копируют). Этим они отличаются от copy on write, при которых данные копируются, что создает дополнительную нагрузку на СХД и «съедает» часть полезного объема.

Основным средством обеспечения катастрофоустойчивости СХД выступает репликация – постоянное копирование данных в другие источники. Она бывает двух видов: синхронная и асинхронная. И репликация снова не может заменить резервное копирование, как не может заменить и снэпшоты.

Как это работает? Представим ситуацию: на площадке в Московской области были записаны данные, а у системы хранения данных настроена репликация с площадкой в Твери. Если площадка в Московской области выйдет из строя, эти данные можно будет использовать с СХД в Твери.

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

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

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

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

Конечно, это далеко не все понятия, с которыми может столкнуться системный администратор или ИТ-директор при выборе СХД. Характеристик систем намного больше; а вопросы управления и производительности – шире и сложнее. К тому же это только общие термины из мира хранения данных: без внимания остались более узкие вопросы виртуальных RAID-ов, гиперконвергенции, QOS-ов и так далее. Однако всё это другие темы – и разговор для совсем другой статьи.

Какие еще термины важно знать, чтобы правильно выбрать СХД? Делитесь в комментариях!

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