Что такое системы хранения данных (СХД) и для чего они нужны? В чём разница между iSCSI и FibreChannel? Почему данное словосочетание только в последние годы стало известно широкому кругу IT-специалистов и почему вопросы систем хранения данных всё больше и больше тревожат вдумчивые умы?
Думаю, многие заметили тенденции развития в окружающем нас компьютерном мире – переход от экстенсивной модели развития к интенсивной. Наращивание мегагерц процессоров уже не даёт видимого результата, а развитие накопителей не поспевает за объёмом информации. Если в случае процессоров всё более или менее понятно – достаточно собирать многопроцессорные системы и/или использовать несколько ядер в одном процессоре, то в случае вопросов хранения и обработки информации так просто от проблем не избавиться. Существующая на данный момент панацея от информационной эпидемии – СХД. Название расшифровывается как Сеть Хранения Данных (Storage Area Network) или Система Хранения Данных. В любом случае – это спе
Основные проблемы, решаемые СХД
Итак, какие же задачи призвана решить СХД? Рассмотрим типичные проблемы, связанные с растущими объёмами информации в любой организации. Предположим, что это хотя бы несколько десятков компьютеров и несколько разнесённых территориально офисов.
1. Децентрализация информации – если раньше все данные могли храниться буквально на одном жёстком диске, то сейчас любая функциональная система требует отдельного хранилища – к примеру, серверов электронной почты, СУБД, домена и так далее. Ситуация усложняется в случае распределённых офисов (филиалов).
2. Лавинообразный рост информации
– зачастую количество жёстких дисков, которые вы можете установить в конкретный сервер, не может покрыть необходимую системе ёмкость. Как следствие:
Невозможность полноценно защитить хранимые данные – действительно, ведь довольно трудно произвести даже backup данных, которые находятся не только на разных серверах, но и разнесены территориально.
Недостаточная скорость обработки информации – каналы связи между удалёнными площадками пока оставляют желать лучшего, но даже при достаточно «толстом» канале не всегда возможно полноценное использование существующих сетей, например, IP, для работы.
Сложность резервного копирования – если данные читаются и записываются небольшими блоками, то произвести полное архивирование информации с удалённого сервера по существующим каналам может быть нереально – необходима передача всего объёма данных. Архивирование на местах зачастую нецелесообразно по финансовым соображениям – необходимы системы для резервного копирования (ленточные накопители, например), специальное ПО (которое может стоить немалых денег), обученный и квалифицированный персонал.
3. Сложно или невозможно предугадать требуемый объём
дискового пространства при развертывании компьютерной системы. Как следствие:
Возникают проблемы расширения дисковых ёмкостей – довольно сложно получить в сервере ёмкости порядков терабайт, особенно если система уже работает на существующих дисках небольшой ёмкости – как минимум, требуется остановка системы и неэффективные финансовые вложения.
Неэффективная утилизация ресурсов – порой не угадать, в каком сервере данные будут расти быстрее. В сервере электронной почты может быть свободен критически малый объём дискового пространства, в то время как другое подразделение будет использовать всего лишь 20% объёма недешёвой дисковой подсистемы (например, SCSI).
4. Низкая степень конфиденциальности распределённых данных – невозможно проконтролировать и ограничить доступ в соответствии с политикой безопасности предприятия. Это касается как доступа к данным по существующим для этого каналам (локальная сеть), так и физического доступа к носителям – к примеру, не исключены хищения жёстких дисков, их разрушение (с целью затруднить бизнес организации). Неквалифицированные действия пользователей и обслуживающего персонала могут нанести ещё больший вред. Когда компания в каждом офисе вынуждена решать мелкие локальные проблемы безопасности, это не даёт желаемого результата.
5. Сложность управления распределёнными потоками информации – любые действия, которые направлены на изменения данных в каждом филиале, содержащем часть распределённых данных, создает определённые проблемы, начиная от сложности синхронизации различных баз данных, версий файлов разработчиков и заканчивая ненужным дублированием информации.
6. Низкий экономический эффект внедрения «классических» решений – по мере роста информационной сети, больших объёмов данных и всё более распределённой структуры предприятия финансовые вложения оказываются не столь эффективны и зачастую не могут решить возникающих проблем.
7. Высокие затраты используемых ресурсов для поддержания работоспособности всей информационной системы предприятия – начиная от необходимости содержать большой штат квалифицированного персонала и заканчивая многочисленными недешёвыми аппаратными решениями, которые призваны решить проблему объёмов и скоростей доступа к информации вкупе с надёжностью хранения и защитой от сбоев.
В свете вышеперечисленных проблем, которые рано или поздно, полностью или частично настигают любую динамично развивающуюся компанию, попробуем обрисовать системы хранения данных – такими, какими они должны быть. Рассмотрим типовые схемы подключения и виды систем хранения данных.
Мегабайты/транзакции?
Если раньше жёсткие диски находились внутри компьютера (сервера), то теперь им там стало тесно и не очень надёжно. Самое простое решение (разработанное достаточно давно и применяемое повсеместно) – технология RAID .
images\RAID\01.jpg
При организации RAID в любых системах хранения данных дополнительно к защите информации мы получаем несколько неоспоримых преимуществ, одно из которых – скорость доступа к информации.
С точки зрения пользователя или ПО, скорость определяется не только пропускной способностью системы (Мбайт/с), но и числом транзакций – то есть числом операций ввода-вывода в единицу времени (IOPS). Увеличению IOPS способствует, что вполне логично, большее число дисков и те методики повышения производительности, которые предоставляет контроллер RAID (к примеру, кэширование).
Если для просмотра потокового видео или организации файл-сервера больше важна общая пропускная способность, то для СУБД, любых OLTP (online transaction processing) приложений критично именно число транзакций, которые способна обрабатывать система. А с этим параметром у современных жёстких дисков всё не так радужно, как с растущими объёмами и, частично, скоростями. Все эти проблемы призвана решить сама система хранения данных.
Уровни защиты
Нужно понимать, что в основе всех систем хранения данных лежит практика защиты информации на базе технологии RAID – без этого любая технически продвинутая СХД будет бесполезна, потому что жёсткие диски в этой системе являются самым ненадёжным компонентом. Организация дисков в RAID – это «нижнее звено», первый эшелон защиты информации и повышения скорости обработки.
Однако, кроме схем RAID, существует и более низкоуровневая защита данных, реализованная «поверх» технологий и решений, внедрённых в сам жёсткий диск его производителем. К примеру, у одного из ведущих производителей СХД – компании EMC – существует методика дополнительного анализа целостности данных на уровне секторов накопителя.
Разобравшись с RAID, перейдём к структуре самих СХД. Прежде всего, СХД разделяются по типу используемых интерфейсов подключения хостов (серверов). Внешние интерфейсы подключения – это, в основном SCSI или FibreChannel, а также довольно молодой стандарт iSCSI. Также не стоит сбрасывать со счетов небольшие интеллектуальные хранилища, которые могут подключаться даже по USB или FireWire. Мы не станем рассматривать более редкие (порой просто неудачные в том или ином плане) интерфейсы, как SSA от IBM или интерфейсы, разработанные для мейнфреймов – к примеру, FICON/ESCON. Особняком стоят хранилища NAS, подключаемые в сеть Ethernet. Под словом «интерфейс» в основном понимается внешний разъём, но не стоит забывать, что разъём не определяет протокол связи двух устройств. На этих особенностях мы остановимся чуть ниже.
images\RAID\02.gif
Расшифровывается как Small Computer System Interface (читается «скази») – полудуплексный параллельный интерфейс. В современных системах хранения данных чаще всего представлен разъёмом SCSI:
images\RAID\03.gif
images\RAID\04.gif
И группой протоколов SCSI, а конкретнее – SCSI-3 Parallel Interface. Отличие SCSI от знакомого нам IDE – бОльшее число устройств на канал, бОльшая длина кабеля, бОльшая скорость передачи данных, а также «эксклюзивные» особенности типа high voltage differential signaling, command quequing и некоторые другие – углубляться в этот вопрос мы не станем.
Если говорить об основных производителях компонент SCSI, например SCSI-адаптеров, RAID-контроллеров с интерфейсом SCSI, то любой специалист сразу вспомнит два названия – Аdaptec и LSI Logic . Думаю, этого достаточно, революций на этом рынке не было уже давно и, вероятно, не предвидится.
Интерфейс FibreChannel
Полнодуплексный последовательный интерфейс. Чаще всего в современном оборудовании представлен внешними оптическими разъёмами типа LC или SC (LC – меньше по размерам):
images\RAID\05.jpg
images\RAID\06.jpg
…и протоколами FibreChannel Protocols (FCP). Существует несколько схем коммутации устройств FibreChannel:
Point-to-Point – точка-точка, прямое соединение устройств между собой:
images\RAID\07.gif
Crosspoint Switched – подключение устройств в коммутатор FibreChannel (аналогичное реализации сети Ethernet на коммутаторах):
images\RAID\08.gif
Arbitrated loop – FC-AL, петля с арбитражным доступом – все устройства связаны друг с другом в кольцо, схема чем-то напоминает Token Ring. Также может использоваться коммутатор – тогда физическая топология будет реализована по схеме «звезда», а логическая – по схеме «петля» (или «кольцо»):
images\RAID\09.gif
Подключение по схеме FibreChannel Switched является самой распространённой схемой, в терминах FibreChannel такое подключение называется Fabric – в русском языке существует калька с него – «фабрика». Следует учесть, что коммутаторы FibreChannel – это довольно продвинутые устройства, по сложности наполнения близкие к IP-коммутаторам уровня 3. Если коммутаторы соединены между собой, то они функционируют в единой фабрике, имея пул настроек, действующих для всей фабрики сразу. Изменение каких-то опций на одном из коммутаторов может приводить к перекоммутации всей фабрики, не говоря уже о настройках авторизации доступа, к примеру. С другой стороны, существуют схемы SAN, которые подразумевают несколько фабрик внутри единой сети SAN. Таким образом, фабрикой можно называть только группу объединённых между собой коммутаторов – два или более не объединённых между собой устройства, введённые в SAN для повышения отказоустойчивости, образуют две или более различные фабрики.
Компоненты, позволяющие объединять хосты и системы хранения данных в единую сеть, принято обозначать термином «connectivity». Connectivity – это, конечно же, дуплексные соединительные кабели (обычно с интерфейсом LC), коммутаторы (switches) и адаптеры FibreChannel (HBA, Host Base Adapters) – то есть те платы расширения, которые, будучи установленными в хосты, позволяют подключить хост в сеть SAN. HBA обычно реализованы в виде плат стандарта PCI-X или PCI-Express.
images\RAID\10.jpg
Не стоит путать fibre и fiber – среда распространения сигнала может быть различной. FibreChannel может работать по «меди». Например, все жёсткие диски FibreChannel имеют металлические контакты, да и обычная коммутация устройств по «меди» – не редкость, просто постепенно все переходят на оптические каналы как наиболее перспективную технологию и функциональную замену «меди».
Интерфейс iSCSI
Обычно представлен внешним разъёмом RJ-45 для подключения в сеть Ethernet и собственно самим протоколом iSCSI (Internet Small Computer System Interface). По определению SNIA: «iSCSI - это протокол, который базируется на TCP/IP и разработан для установления взаимодействия и управления системами хранения данных, серверами и клиентами». На этом интерфейсе остановимся немножко подробней, хотя бы в силу того, что каждый пользователь способен использовать iSCSI даже в обычной «домашней» сети.
Необходимо знать, что протокол iSCSI определяет, как минимум, транспортный протокол для SCSI, который работает поверх TCP, и технологию инкапсуляции SCSI-команд в сеть на базе IP. Проще говоря, iSCSI – это протокол, позволяющий получить блочный доступ к данным с помощью команд SCSI, пересылаемых через сеть со стеком TCP/IP. iSCSI появился как замена FibreChannel и в современных СХД имеет перед ним несколько преимуществ – способность объединять устройства на огромных расстояниях (используя существующие сети IP), возможность обеспечивать заданный уровень QoS (Quality of Service, качество обслуживания), более низкую стоимость connectivity. Однако основная проблема использования iSCSI как замены FibreChannel – большое время задержек, возникающих в сети из-за особенностей реализации стека TCP/IP, что сводит на нет одно из важных преимуществ использования СХД – скорость доступа к информации и низкую латентность. Это серьёзный минус.
Маленькое замечание по поводу хостов – они могут использовать как обычные сетевые карты (тогда обработка стека iSCSI и инкапсуляция команд будет осуществляться программными средствами), так и специализированные карты с поддержкой технологий аналогичных TOE (TCP/IP Offload Engines). Такая технология обеспечивает аппаратную обработку соответствующей части стека протокола iSCSI. Программный метод дешевле, однако больше загружает центральный процессор сервера и в теории может приводить к бОльшим задержкам, чем аппаратный обработчик. При современной скорости сетей Ethernet в 1 Гбит/с можно предположить, что iSCSI будет работать ровно в два раза медленнее FibreChannel со скоростью 2 Гбит, однако в реальном применении разница будет ещё заметнее.
Помимо уже рассмотренных, кратко упомянем ещё пару протоколов, которые встречаются более редко и предназначены для предоставления дополнительных сервисов уже существующим сетям хранения данных (SAN):
FCIP (Fibre Channel over IP)
– туннельный протокол, построенный на TCP/IP и предназначенный для соединения географически разнесённых сетей SAN через стандартную среду IP. Например, можно объединить две сети SAN в одну через Интернет. Достигается это использованием FCIP-шлюза, который прозрачен для всех устройств в SAN.
iFCP (Internet Fibre Channel Protocol)
– протокол, позволяющий объединять устройства с интерфейсами FC через IP-сети. Важное отличие от FCIP в том, что возможно объединять именно FC-устройства через IP-сеть, что позволяет для разной пары соединений иметь разный уровень QoS, что невозможно при туннелировании через FCIP.
Мы кратко рассмотрели физические интерфейсы, протоколы и типы коммутации для систем хранения данных, не останавливаясь на перечислении всех возможных вариантов. Теперь попытаемся представить какие же параметры характеризуют системы хранения данных?
Основные аппаратные параметры СХД
Некоторые из них были перечислены выше – это тип внешних интерфейсов подключения и типы внутренних накопителей (жёстких дисков). Следующий параметр, который есть смысл рассматривать после двух вышеперечисленных при выборе дисковой системы хранения, – её надёжность. Надёжность можно оценить не по банальному времени наработки на отказ каких-то отдельных компонент (факт, что это время примерно равно у всех производителей), а по внутренней архитектуре. «Обычная» система хранения часто «внешне» представляет собой дисковую полку (для монтажа в 19-дюймовый шкаф) с жёсткими дисками, внешними интерфейсами для подключения хостов, несколькими блоками питания. Внутри обычно установлено всё то, что обеспечивает работу системы хранения – процессорные блоки, контроллеры дисков, портов ввода-вывода, кэш-память и так далее. Обычно управление стойкой осуществляется из командной строки или по web-интерфейсу, начальная конфигурация часто требует подключения по последовательному интерфейсу. Пользователь может «разбить» имеющиеся в системе диски на группы и объединить их в RAID (различных уровней), получившееся дисковое пространство разделяется на один или несколько логических блоков (LUN), к которым и имеют доступ хосты (серверы) и «видят» их как локальные жёсткие диски. Количество RAID-групп, LUN-ов, логика работы кэша, доступность LUN-ов конкретным серверам и всё остальное настраивается администратором системы. Обычно СХД предназначены для подключения к ним не одного, а нескольких (вплоть до сотен, в теории) серверов – посему такая система должна обладать высокой производительностью, гибкой системой управления и мониторинга, продуманными средствами защиты данных. Защита данных обеспечивается многими способами, самый простой из которых вы уже знаете – объединение дисков в RAID. Однако данные должны быть ещё и постоянно доступны – ведь остановка одной системы хранения данных, центральной на предприятии, способна нанести ощутимые убытки. Чем больше систем хранит данные на СХД, тем более надёжный доступ к системе должен быть обеспечен – потому что при аварии СХД останавливается работа сразу всех серверов, хранящих там данные. Высокая доступность стойки обеспечивается полным внутренним дублированием всех компонент системы – путей доступа к стойке (портов FibreChannel), процессорных модулей, кэш-памяти, блоков питания и т.д. Попытаемся принцип 100%-го резервирования (дублирования) объяснить следующим рисунком:
images\RAID\11.gif
1. Контроллер (процессорный модуль) СХД, включающий в себя:
*центральный процессор (или процессоры) – обычно на системе работает специальное ПО, выполняющее роль «операционной системы»;
*интерфейсы для коммутации с жёсткими дисками – в нашем случае это платы, обеспечивающие подключение дисков FibreChannel по схеме петли с арбитражным доступом (FC-AL);
*кэш-память;
*контроллеры внешних портов FibreChannel
2. Внешний интерфейс FC; как мы видим, тут их по 2 штуки на каждый процессорный модуль;
3. Жёсткие диски – ёмкость расширяется дополнительными дисковыми полками;
4. Кэш-память в такой схеме обычно зеркалируется, чтобы не потерять сохранённые там данные при выходе любого модуля из строя.
Касательно аппаратной части – дисковые стойки могут иметь различные интерфейсы для подключения хостов, различные интерфейсы жёстких дисков, различные схемы подключения дополнительных полок, служащих для увеличения числа дисков в системе, а также другие чисто «железные параметры».
Естественно, аппаратная мощь систем хранения должна как-то управляться, а сами СХД просто обязаны предоставлять уровень сервиса и функциональность, недоступную в обычных схемах «сервер-клиент». Если рассмотреть рисунок «Структурная схема системы хранения данных», становится понятно, что при прямом подключении сервера к стойке двумя путями они должны быть подключены к FC-портам различных процессорных модулей, для того чтобы сервер продолжал работать при выходе из строя сразу всего процессорного модуля. Естественно, для использования multipathing должна быть обеспечена поддержка этой функциональности аппаратными и программными средствами всех уровней, участвующих в передаче данных. Конечно же, полное резервирование без средств мониторинга и оповещения не имеет смысла – поэтому все серьёзные системы хранения имеют такие возможности. К примеру, оповещение о каких-либо критических событиях может происходить различными средствами – это оповещение по e-mail, автоматический модемный звонок в центр техподдержки, сообщение на пейджер (сейчас актуальнее SMS), SNMP-механизмы и прочее.
Ну и как мы уже упоминали, существуют мощные средства управления всем этим великолепием. Обычно это web-интерфейс, консоль, возможность писать скрипты и встраивать управление во внешние программные пакеты. Про механизмы, обеспечивающие высокую производительность СХД, упомянем лишь вкратце – неблокируемая архитектура с несколькими внутренними шинами и большим количеством жёстких дисков, мощные центральные процессоры, специализированная система управления (ОС), большой объём кэш-памяти, множество внешних интерфейсов ввода-вывода.
Сервисы, предоставляемые системами хранения, обычно определяются программным обеспечением, функционирующим на самой дисковой стойке. Практически всегда это сложные программные пакеты, приобретаемые по отдельным лицензиям, не входящим в стоимость самой СХД. Сразу упомянем уже знакомое вам ПО для обеспечения multipathing – вот оно как раз функционирует на хостах, а не на самой стойке.
Следующее по популярности решение – ПО для создания мгновенных и полных копий данных. Различные производители по-разному называют свои программные продукты и механизмы создания этих копий. Мы для обобщения можем манипулировать словами снапшот (snapshot) и клон (clone). Клон делается средствами дисковой стойки внутри самой стойки – это полная внутренняя копия данных. Сфера применения довольно широка – от бэкапа (backup) до создания «тестовой версии» исходных данных, к примеру, для рискованных модернизаций, в которых нет уверенности и применять которые на актуальных данных небезопасно. Тот, кто внимательно следил за всеми прелестями СХД, которые мы тут разбирали, спросит – для чего же нужен бэкап данных внутри стойки, если она обладает такой высокой надёжностью? Ответ на этот вопрос на поверхности – никто не застрахован от человеческих ошибок. Данные сохранены надёжно, но если сам оператор сделал что-то не так, к примеру, удалил нужную таблицу в базе данных, от этого не спасут никакие аппаратные ухищрения. Клонирование данных обычно выполняется на уровне LUN. Более интересная функциональность обеспечивается механизмом снапшотов. В какой-то мере мы получаем все прелести полной внутренней копии данных (клона), при этом не занимая 100% объёма копируемых данных внутри самой стойки, ведь такой объём нам не всегда доступен. По сути снапшот – мгновенный «снимок» данных, который не занимает времени и процессорных ресурсов СХД.
Конечно нельзя не упомянуть ПО для репликации (replication) данных, которое часто называют зеркалированием (mirroring). Это механизм синхронного или асинхронного реплицирования (дублирования) информации с одной системы хранения на одну или несколько удалённых систем хранения. Репликация возможна по различных каналам – к примеру, стойки с интерфейсами FibreChannel могут асинхронно, через Интернет и на большие расстояния, реплицироваться на другую СХД. Такое решение обеспечивает надёжность хранения информации и защиту от катастроф.
Кроме всех перечисленных, существует большое число других программных мехонизмов манипуляций данными...
DAS & NAS & SAN
После знакомства с самими системами хранения данных, принципами их построения, предоставляемыми ими возможностями и протоколами функционирования самое время попробовать объединить полученные знания в работающую схему. Попробуем рассмотреть типы систем хранения и топологии их подключения в единую работающую инфраструктуру.
Устройства DAS (Direct Attached Storage) – системы хранения, подключаемые напрямую к серверу. Сюда относятся как самые простые SCSI-системы, подключаемые к SCSI/RAID-контроллеру сервера, так и устройства FibreChannel, подключенные прямо к серверу, хотя и предназначены они для сетей SAN. В этом случае топология DAS является вырожденной SAN (сетью хранения данных):
images\RAID\12.gif
В этой схеме один из серверов имеет доступ к данным, хранящимся на СХД. Клиенты получают доступ к данным, обращаясь к этому серверу через сеть. То есть сервер имеет блочный доступ к данным на СХД, а уже клиенты пользуются файловым доступом – эта концепция очень важна для понимания. Минусы такой топологии очевидны:
*Низкая надежность – при проблемах сети или аварии сервера данные становятся недоступны всем сразу.
*Высокая латентность, обусловленная обработкой всех запросов одним сервером и использующимся транспортом (чаще всего – IP).
*Высокая загрузка сети, часто определяющая пределы масштабируемости путём добавления клиентов.
*Плохая управляемость – вся ёмкость доступна одному серверу, что снижает гибкость распределения данных.
*Низкая утилизация ресурсов – трудно предсказать требуемые объёмы данных, у одних устройств DAS в организации может быть избыток ёмкости (дисков), у других её может не хватать – перераспределение часто невозможно или трудоёмко.
Устройства NAS (Network Attached Storage) – устройства хранения, подключённые напрямую в сеть. В отличие от других систем NAS обеспечивает файловый доступ к данным и никак иначе. NAS-устройства представляют из себя комбинацию системы хранения данных и сервера, к которому она подключена. В простейшем варианте обычный сетевой сервер, предоставляющий файловые ресурсы, является устройством NAS:
images\RAID\13.gif
Все минусы такой схемы аналогичны DAS-топологии, за некоторым исключением. Из добавившихся минусов отметим возросшую, и часто значительно, стоимость – правда, стоимость пропорциональна функциональности, а тут уже часто «есть за что платить». NAS-устройства могут быть простейшими «коробочками» с одним портом ethernet и двумя жёсткими дисками в RAID1, позволяющими доступ к файлам по лишь одному протоколу CIFS (Common Internet File System) до огромных систем в которых могут быть установлены сотни жёстких дисков, а файловый доступ обеспечивается десятком специализированных серверов внутри NAS-системы. Число внешних Ethernet-портов может достигать многих десятков, а ёмкость хранимых данных – несколько сотен терабайт (например EMC Celerra CNS). Такие модели по надёжности и производительности могут далеко обходить многие midrange-устройства SAN. Что интересно, NAS-устройства могут быть частью SAN-сети и не иметь собственных накопителей, а лишь предоставлять файловый доступ к данным, находящимся на блочных устройствах хранения. В таком случае NAS берёт на себя функцию мощного специализированного сервера, а SAN – устройства хранения данных, то есть мы получаем топологию DAS, скомпонованную из NAS- и SAN-компонентов.
NAS-устройства очень хороши в гетерогенной среде, где необходим быстрый файловый доступ к данным для многих клиентов одновременно. Также обеспечивается отличная надёжность хранения и гибкость управления системой вкупе с простотой обслуживания. На надёжности особо останавливаться не будем – этот аспект СХД рассмотрен выше. Что касается гетерогенной среды, доступ к файлам в рамках единой NAS-системы может быть получен по протоколам TCP/IP, CIFS, NFS, FTP, TFTP и другим, включая возможность работы NAS, как iSCSI-target, что обеспечивает функционирование с различным ОС, установленными на хостах. Что касается лёгкости обслуживания и гибкости управления, то эти возможности обеспечиваются специализированной ОС, которую трудно вывести из строя и не нужно обслуживать, а также простотой разграничения прав доступа к файлам. К примеру, возможна работа в среде Windows Active Directory с поддержкой требуемой функциональности – это может быть LDAP, Kerberos Authentication, Dynamic DNS, ACLs, назначение квот (quotas), Group Policy Objects и SID-истории. Так как доступ обеспечивается к файлам, а их имена могут содержать символы различных языков, многие NAS обеспечивают поддержку кодировок UTF-8, Unicode. К выбору NAS стоит подходить даже тщательнее, чем к DAS-устройствам, ведь такое оборудование может не поддерживать необходимые вам сервисы, например, Encrypting File Systems (EFS) от Microsoft и IPSec. К слову можно заметить, что NAS распространены намного меньше, чем устройства SAN, но процент таких систем всё же постоянно, хотя и медленно, растёт – в основном за счёт вытеснения DAS.
Устройства для подключения в SAN (Storage Area Network) – устройства для подключения в сеть хранения данных. Сеть хранения данных (SAN) не стОит путать с локальной сетью – это различные сети. Чаще всего SAN основывается на стеке протоколов FibreChannel и в простейшем случае состоит из СХД, коммутаторов и серверов, объединённых оптическими каналами связи. На рисунке мы видим высоконадёжную инфраструктуру, в которой серверы включены одновременно в локальную сеть (слева) и в сеть хранения данных (справа):
images\RAID\14.gif
После довольно детального рассмотрения устройств и принципов их функционирования нам будет довольно легко понять топологию SAN. На рисунке мы видим единую для всей инфраструктуры СХД, к которой подключены два сервера. Серверы имеют резервированные пути доступа – в каждом установлено по два HBA (или один двухпортовый, что снижает отказоустойчивость). Устройство хранения имеет 4 порта, которыми оно подключено в 2 коммутатора. Предполагая, что внутри имеется два резервируемых процессорных модуля, легко догадаться, что лучшая схема подключения – когда каждый коммутатор подключён и в первый, и во второй процессорный модуль. Такая схема обеспечивает доступ к любым данным, находящимся на СХД, при выходе из строя любого процессорного модуля, коммутатора или пути доступа. Надёжность СХД нами уже изучена, два коммутатора и две фабрики ещё более увеличивают доступность топологии, так что если из-за сбоя или ошибки администратора один из коммутационных блоков вдруг отказал, второй будет функционировать нормально, ведь эти два устройства не связаны между собой.
Показанное подключение серверов называется подключением с высокой доступностью (high availability), хотя в сервере при необходимости может быть установлено ещё большее число HBA. Физически каждый сервер имеет только два подключения в SAN, однако логически система хранения доступна через четыре пути – каждая HBA предоставляет доступ к двум точкам подключения на СХД, к каждому процессорному модулю раздельно (эту возможность обеспечивает двойное подключение коммутатора к СХД). На данной схеме самое ненадежной устройство – это сервер. Два коммутатора обеспечивают надежность порядка 99,99%, а вот сервер может отказать по разным причинам. Если необходима высоконадёжная работа всей системы, серверы объединяются в кластер, приведённая схема не требует никакого аппаратного дополнения для организации такой работы и считается эталонной схемой организации SAN. Простейший же случай – серверы, подключённые единственным путем через один свитч к системе хранения. Однако система хранения при наличии двух процессорных модулей должна подключаться в коммутатор как минимум одним каналом на каждый модуль – остальные порты могут быть использованы для прямого подключения серверов к СХД, что иногда необходимо. И не стоит забывать, что SAN возможно построить не только на базе FibreChannel, но и на базе протокола iSCSI – при этом можно использовать только стандартные ethernet-устройства для коммутации, что удешевляет систему, но имеет ряд дополнительных минусов (оговоренных в разделе, рассматривающем iSCSI). Также интересна возможность загрузки серверов с системы хранения – не обязательно даже наличие внутренних жёстких дисков в сервере. Таким образом, с серверов окончательно снимается задача хранения каких-либо данных. В теории специализированный сервер может быть превращён в обычную числодробилку без каких-либо накопителей, определяющими блоками которого являются центральные процессоры, память, а так же интерфейсы взаимодействия с внешним миром, например порты Ethernet и FibreChannel. Какое-то подобие таких устройств являют собой современные blade-серверы.
Хочется отметить, что устройства, которые возможно подключить в SAN, не ограничены только дисковыми СХД – это могут быть дисковые библиотеки, ленточные библиотеки (стримеры), устройства для хранения данных на оптических дисках (CD/DVD и прочие) и многие другие.
Из минусов SAN отметим лишь высокую стоимость её компонент, однако плюсы неоспоримы:
* Высокая надёжность доступа к данным, находящимся на внешних системах хранения. Независимость топологии SAN от используемых СХД и серверов.
* Централизованное хранение данных (надёжность, безопасность).
* Удобное централизованное управление коммутацией и данными.
* Перенос интенсивного трафика ввода-вывода в отдельную сеть, разгружая LAN.
* Высокое быстродействие и низкая латентность.
* Масштабируемость и гибкость логической структуры SAN
* Географически размеры SAN, в отличие от классических DAS, практически не ограничены.
* Возможность оперативно распределять ресурсы между серверами.
* Возможность строить отказоустойчивые кластерные решения без дополнительных затрат на базе имеющейся SAN.
* Простая схема резервного копирования – все данные находятся в одном месте.
* Наличие дополнительных возможностей и сервисов (снапшоты, удаленная репликация).
* Высокая степень безопасности SAN.
В заключение
Думаю, мы достаточно полно осветили основной круг вопросов, связанных с современными системами хранения. Будем надеяться, что такие устройства будут ещё стремительнее развиваться функционально, а число механизмов управления данными будет только расти.
В заключение можно сказать, что NAS и SAN-решения в данный момент переживают настоящий бум. Число производителей и разнообразие решений увеличивается, техническая грамотность потребителей растёт. Смело можно предполагать, что в ближайшем будущем практически в каждой вычислительной среде появятся те или иные системы хранения данных.
Любые данные предстают перед нами в виде информации. Смысл работы любых вычислительных устройств – обработка информации. В последнее время объёмы её роста порой пугают, поэтому системы хранения данных и специализированное программное обеспечение, несомненно, будут самым востребованными продуктами IT-рыка в ближайшие годы.
Каким образом нужно классифицировать архитектурные схемы СХД? Мне кажется, актуальность этого вопроса в дальнейшем будет только расти. Как разобраться во всём этом многообразии предложений, имеющихся на рынке? Сразу хочу предупредить, что этот пост не предназначен для ленивых или не желающих много читать.
Можно вполне успешно классифицировать системы хранения, наподобие того, как биологи выстраивают родственные связи между видами живых организмов. Если хотите, можно назвать это «древом жизни» мира технологий хранения информации.
Построение подобных древ помогает лучше понимать окружающий мир. В частности, можно выстроить схему происхождения и развития любых видов СХД, и быстро понять, что же лежит в основе любой новой технологии, появляющейся на рынке. Это позволяет сразу определить сильные и слабые стороны того или иного решения.
Хранилища, позволяющие работать с информацией любого вида, архитектурно можно разделить на 4 основные группы. Главное, не зацикливаться на некоторых вещах, которые сбивают с толку. Многие склонны классифицировать платформы на основе таких «физических» критериев, как межкомпонентное соединение (interconnect) («У них у всех есть внутренняя шина между нодами!»), или протокол («Это блок, или NAS, или многопротокольная система!»), или делят на аппаратные и программные («Это же просто ПО на сервере!»).
Это совершенно неправильный подход к классифицированию. Единственно верным критерием является программная архитектура, используемая в том или ином решении, поскольку от этого зависят все основные характеристики системы. Остальные компоненты СХД зависят от того, какая именно программная архитектура была выбрана разработчиками. И с этой точки зрения «аппаратные» и «программные» системы могут быть лишь вариациями той или иной архитектуры.
Но не поймите меня неправильно, я не хочу сказать, что разница между ними невелика. Просто она не фундаментальна.
И хочу ещё кое-что уточнить, прежде чем перейти к делу. Для нашей натуры свойственно задавать вопросы «А что из этого самое лучшее/правильное?». Ответить на это можно только одно: «Есть лучшие решения для каких-то конкретных ситуаций или видов нагрузки, но не существует универсального идеального решения». Именно особенности нагрузки диктуют выбор архитектуры , и больше ничто другое.
К слову, недавно я участвовал в забавной беседе на тему ЦОД, работающих исключительно на флэш-накопителях. Мне импонирует страстность в любых проявлениях, и совершенно очевидно, что флэш вне конкуренции в ситуациях, когда производительность и время задержки играют решающую роль (помимо многих других факторов). Но должен признать, что мои собеседники были неправы. У нас есть один клиент, его услугами, даже не подозревая об этом, ежедневно пользуется множество людей. Может ли он полностью перейти на флэш? Нет.
Это большой клиент. А вот другой, ОГРОМНЫЙ, раз в 10 больше. И я опять не могу согласиться с тем, что этот клиент может перейти исключительно на флэш:
Обычно в качестве контраргумента заявляют, что в конце концов флэш достигнет такого уровня развития, что затмит магнитные накопители. С оговоркой, что флэш будет применяться с паре с дедупликацией. Но не во всех случаях целесообразно применять дедупликацию, как и компрессию.
Ну, с одной стороны, флэш-память будет дешеветь, до определённого предела. Мне казалось, что это будет происходить несколько быстрее, но уже доступны SSD-накопители ёмкостью 1 Тб за $550, это большой прогресс. Конечно, разработчики традиционных винчестеров тоже не сидят сложа руки. В районе 2017-2018 годов конкуренция должна усилиться, поскольку будут внедряться новые технологии (вероятнее всего, фазовый сдвиг и углеродные нанотрубки). Но дело вовсе не в противостоянии флэш и винчестеров, или даже программных и аппаратных решений, главное - архитектура .
Она настолько важна, что практически невозможно поменять архитектуру СХД, не переделав практически всё. То есть, по сути, не создав новую систему. Поэтому хранилища обычно создаются, развиваются и умирают в рамках какой-то одной изначально выбранной архитектуры.
Четыре типа систем хранения данных
Тип 1. Кластеризованные архитектуры . Они не рассчитаны на совместное использование памяти нодами, по сути, все данные находятся в одном ноде. Одной из особенностей архитектуры является то, что иногда устройства «пересекаются» (trespass), даже если они «доступны из нескольких нодов». Другая особенность заключается в том, что вы можете выбрать машину, указать ей какие-то накопители и сказать «эта машина имеет доступ к данным на этих носителях». Синим на рисунке обозначены ЦПУ/память/система ввода-вывода, а зелёным - носители, на которых хранятся данные (флэш или магнитные накопители).
Для данного типа архитектур характерен прямой и очень быстрый доступ к данным. Между машинами будут возникать небольшие задержки, поскольку для обеспечения высокой доступности применяется зеркалирование ввода-вывода и кэширование. Но в целом обеспечивается относительно прямой доступ по ветви кода. Программные хранилища достаточно просты и имеют малое время задержки, поэтому зачастую обладают богатым функционалом, службы данных легко добавляются. Неудивительно, что большинство стартапов начинают с подобных хранилищ.
Обратите внимание, что одной из разновидностей этого типа архитектур является PCIe-оборудование для не HA-серверов (карты расширения Fusion-IO, XtremeCache). Если добавить к нему ПО для распределённого хранилища, когерентность и HA-модель, то подобное программное хранилище будет соответствовать одному из четырёх типов архитектур, описываемых в этом посте.
Применение «федеративных моделей» помогает улучшить горизонтальную масштабируемость архитектур этого типа с точки зрения менеджмента. В данных моделях могут использоваться разные подходы к повышению мобильности данных для перебалансировки между управляющими машинами и хранилищами. Например, в рамках VNX это означает «мобильность VDM». Но я считаю, что называть это «горизонтально масштабируемой архитектурой» будет натяжкой. И, по моему опыту, большинство клиентов разделяют эту точку зрения. Причиной тому расположение данных на одной управляющей машине, иногда - «в аппаратном шкафе» (behind an enclosure). Их можно перемещать, но они всегда будут в каком-то одном месте. С одной стороны, это позволяет снизить количество циклов и задержку при записи. С другой стороны, все ваши данные обслуживаются единственной управляющей машиной (возможен непрямой доступ с другой машины). В отличие от второго и третьего типов архитектур, о которых поговорим ниже, здесь балансировка и настройка играют важную роль.
Объективно говоря, этот абстрактный федеративный уровень влечёт за собой и некоторое увеличение задержки, поскольку использует программное перенаправление. Это аналогично усложнению кода и увеличению задержки в типах архитектур 2 и 3, и отчасти нивелирует преимущества первого типа. В качестве конкретного примера можно привести UCS Invicta, этакий «Silicon Storage Routers». В случае с NetApp FAS 8.x, работающим в кластерном режиме, код изрядно усложнён внедрением федеративной модели.
Продукты, использующие кластерные архитектуры - VNX или NetApp FAS, Pure, Tintri, Nimble, Nexenta и (я думаю) UCS Invicta/UCS. Одни представляют собой «аппаратные» решения, другие - «чисто программные», третьи - «программные в виде аппаратных комплексов». Все они ОЧЕНЬ сильно различаются с точки зрения обработки данных (в Pure и UCS Invicta/Whiptail подразумевается использование только флэш-накопителей). Но архитектурно все перечисленные продукты родственны. Например, вы настраиваете службы обработки данных исключительно для резервного копирования, программный стек становится Data Domain, ваш NAS работает как лучший в мире инструмент для бэкапа - и это тоже архитектура «первого типа».
Тип 2. Слабо сопряжённые, горизонтально масштабированные архитектуры . Ноды не используют память совместно, но сами данные по нескольким нодам. Эта архитектура подразумевает использование большего количества межнодовых связей для записи данных, что увеличивает количество циклов. Хоть операции записи и распределены, но всегда когерентны.
Обратите внимание, что в этих архитектурах не обеспечивается высокая доступность нода в связи с операциями копирования и распределения данных. По той же причине здесь всегда больше операций ввода-вывода по сравнению с простыми кластерными архитектурами. Так что производительность получается несколько ниже, несмотря на небольшой уровень задержки при записи (NVRAM, SSD и т.д.).
В некоторых разновидностях архитектур часто нодов собираются в подгруппы, а остальные используются для управления подгруппами (ноды метаданных). Но здесь проявляются эффекты, описанные выше для «федеративных моделей».
Подобные архитектуры довольно просто масштабируются. Поскольку данные хранятся в нескольких местах и могут обрабатываться многочисленными нодами, эти архитектуры могут отлично подойти для задач, когда требуется распределённое чтение. Кроме того, они хорошо сочетаются с ПО для серверов/хранилищ. Но лучше всего применять подобные архитектуры в условиях транзакционных нагрузок: благодаря их распределённости вы можете не использовать HA-сервер, а слабая сопряжённость позволяет обойтись Ethernet.
Этот тип архитектур используется в таких продуктах, как EMC ScaleIO и Isilon, VSAN, Nutanix и Simplivity. Как в случае с Типом 1, все эти решения совершенно непохожи друг на друга.
Слабая сопряжённость означает, что зачастую эти архитектуры позволяют заметно увеличивать количество нодов. Но, напомню, они НЕ используют память совместно, код каждого нода работает независимо от других. Но дьявол, как говорится, в деталях:
- Чем больше распределены операции записи, тем выше задержки и ниже эффективность IOP. Например, в Isilon уровень распределённости очень высок файлов, и хотя с каждым обновлением задержки уменьшаются, но всё же он никогда не продемонстрирует высочайшей производительности. Зато Isilon чрезвычайно силён с точки зрения распаралеллеливания.
- Если уменьшить степень распределённости (пусть и при большом количестве нодов), то задержки могут снизиться, но при этом вы урежете свои возможности по распараллеливанию чтения данных. Например, во VSAN используется модель «виртуальная машина как объект», что позволяет запускать многочисленные копии. Казалось бы, виртуальная машина должна быть доступна определённому хосту. Но, по факту, во VSAN она «сдвигается» по направлению к ноду, который хранит её данные. Если вы используете это решение, то можете сами посмотреть, как увеличение количества копий объекта влияет на задержку и операции ввода-вывода в рамках всей системы. Подсказка: больше копий = выше нагрузка на систему в целом, причём зависимость нелинейная, как вы могли бы ожидать. Но для VSAN это не проблема благодаря преимуществам модели «виртуальная машина как объект».
- Можно добиться низкой задержки в условиях высокого масштабирования и распараллеливания при чтении, но только при условии точного разделения данных и записи небольшого количества копий. Этот подход используется в ScaleIO. Каждый том разделён на большое количество фрагментов (по умолчанию по 1 Мб), которые распределены по всем задействованным нодам. В результате достигается чрезвычайно высокая скорость чтения и перераспределения наряду с мощным распараллеливанием. Задержка при записи может быть менее 1 мсек при использовании соответствующей сетевой инфраструктуры и SSD/PCIe Flash в нодах кластера. Однако каждая операция записи производится в двух нодах. Конечно, в отличие от VSAN здесь виртуальная машина не рассматривается как объект. Но если бы рассматривалась, то масштабируемость была бы хуже.
Тип 3. Сильно сопряжённые, горизонтально масштабированные архитектуры . Здесь применяется совместное использование памяти (для кэширования и некоторых типов метаданных). Данные распределены по различным нодам. Этот тип архитектур подразумевает использование очень большого количества межнодовых соединений для всех видов операций.
Совместное использование памяти является краеугольным камнем этих архитектур. Исторически сложилось, что через все управляющие машины могут осуществляться симметричные операции ввода-вывода (см. иллюстрацию). Это позволяет перебалансировать нагрузку в случае возникновения каких-либо сбоев. Данная идея закладывалась в основу таких продуктов, как Symmetrix, IBM DS, HDS USP и VSP. В них осуществляется совместны доступ к кэшу, поэтому процедура ввод-вывода можно управлять с любой машины.
Верхняя диаграмма на иллюстрации отражает архитектуру EMC XtremIO. На первый взгляд, она аналогична Типу 2, но это не так. В данном случае модель совместно используемых распределённых метаданных подразумевает использование IB и удалённого прямого доступа к памяти, чтобы все ноды имели доступ к метаданным. При этом каждый нод представляет собой HA-пару. Как видите, Isilon и XtremIO сильно различаются архитектурно, хотя это и не так очевидно. Да, у обоих горизонтально масштабированные архитектуры, в обоих для межкомпонентного соединения используется IB. Но в Isilon, в отличие от XtremIO, это делается для максимального снижения задержки при обмене данными между нодами. Также в Isilon для связи между нодами можно использовать Ethernet (фактически, именно так на нём работает виртуальная машина), но это увеличивает задержки при операциях ввода-вывода. Что касается XtremIO, то для его производительности большое значение имеет удалённый прямой доступ к памяти.
Кстати, пусть вас не вводит в заблуждение наличие двух диаграмм на иллюстрации - на самом деле, архитектурно они одинаковые. В обоих случаях используются пары HA-контроллеров, совместный доступ к памяти и межкомпонентные соединение с очень низким уровнем задержки. Кстати, в VMAX используется проприетарная межкомпонентная шина, но в будущем появится возможность применения IB.
Для сильно сопряжённых архитектур характерна высокая сложность программного кода. Это одна из причин их невысокой распространённости. Излишняя сложность ПО влияет и на количество добавляемых служб обработки данных, поскольку это представляет собой более трудную вычислительную задачу.
К преимуществам этого типа архитектур можно отнести устойчивость к сбоям (симметричные операции ввода-вывода во всех управляющих машинах), а также, в случае с XtremIO, большие возможности в сфере AFA. Раз речь снова зашла об XtremIO, то стоит упомянуть, что его архитектура подразумевает распределённость всех служб обработки данных. Также это единственное на рынке AFA-решение с горизонтально масштабированной архитектурой, хотя динамическое добавление/отключение нодов ещё не внедрено. Помимо прочего, в XtremIO используется «естественная» дедупликация, то есть она постоянно активна и «бесплатна» с точки зрения производительности. Правда, всё это повышает сложность обслуживания системы.
Важно понимать принципиальную разницу между Типом 2 и Типом 3. Чем более сопряжённая архитектура, тем лучше и более прогнозируемо она позволяет обеспечивать низкий уровень задержек. С другой стороны, в рамках подобной архитектуры сложнее добавлять ноды и масштабировать систему. Ведь когда вы используете совместный доступ к памяти, она представляет собой единую сильно сопряжённую распределённую систему. Сложность решений растёт, а вместе с этим и вероятность ошибок. Поэтому VMAX может иметь до 16 управляющих машин в 8 движках, а XtemIO - до 8 машин в 4 X-Brick (скоро увеличится до 16 машин в 8 блоках). Учетверение, или даже удвоение этих архитектур представляет собой невероятно трудную инженерную проблему. Для сравнения, VSAN может быть масштабирован до «размера кластеров vSphere» (сейчас 32 нода), Isilon может содержать более 100 нодов, а ScaleIO позволяет создать систему из более чем 1000 нодов. При этом всё это архитектуры второго типа.
Снова хочу подчеркнуть - архитектура не зависит от реализации. В вышеупомянутых продуктах используется и Ethernet, и IB. Одни представляют собой чисто программные решения, другие являются программно-аппаратными комплексами, но при этом их объединяют архитектурные схемы.
Несмотря на разнообразие межкомпонентных соединений, во всех приведённых примерах важнейшую роль играет использование распределённой записи. Это позволяет достичь транзакционности и атомарности, но при этом необходим тщательный контроль целостности данных. Также приходится решать проблему разрастания «области отказов». Эти два момента ограничивают максимально возможную степень масштабирования описанных типов архитектур.
Небольшая проверка того, насколько внимательно вы прочитали всё вышеизложенное : к какому типу относится Cisco UCS Invicta - 1 или 3? Физически выглядит как Тип 3, но ведь это набор USC-серверов серии С, соединённых по Ethernet, на которых работает программный стек Invicta (бывший Whiptail). Подсказываю: смотрите на архитектуру, а не конкретную реализацию 🙂
В случае с UCS Invicta данные хранятся в каждом ноде (UCS-сервер с флэш-накопителями на базе MLC). Единственный нод, не HA, представляющий собой отдельный сервер, может напрямую передавать номер логического устройства (LUN). Если вы решите добавить ещё ноды, возможно система масштабируется слабосопряжённо, как ScaleIO или VSAN. Всё это подводит нас к Типу 2.
Однако увеличение количества нодов, судя во всему, производится с помощью конфигурирования и миграции на “Invicta Scaling Appliance”. При такой конфигурации у вас есть несколько “Silicon Storage Routers” (SSR) и адресное хранилище из нескольких аппаратных нодов. Доступ к данным осуществляется через единственный SSR-нод, но это можно сделать и через другой нод, работающий как HA-пара. Сами данные всегда находятся на единственном UCS-ноде серии С. Так какой же это тип архитектуры? Не важно, как выглядит решение физически, - это Тип 1. SSR представляет собой кластер (может быть больше 2). В конфигурации Scaling Appliance каждый UCS-сервер с MLC-накопителями выполняет функцию, аналогичную VNX или NetApp FAS - дисковое хранилище. Хоть и не подключён через SAS, но архитектура аналогичная.
Тип 4. Распределённые архитектуры без совместно использования каких-либо ресурсов . Несмотря на то, что данные распределяются по разным нодам, делается это безо всякой транзакционности. Обычно данные складируются на каком-то одном ноде и там живут, и время от времени делаются копии на других нодах, ради обеспечения безопасности. Но эти копии не транзакционные. Это является ключевым отличием данного типа архитектур от Типа 2 и 3.
Связь между не-HA-нодами осуществляется с помощью Ethernet, поскольку это дёшево и универсально. Распределение по нодам делается принудительно и время от времени. «Корректность» данных соблюдается не всегда, но программный стек проверяется довольно часто, чтобы обеспечивать правильность используемых данных. При некоторых видах нагрузки (например, HDFS) данные распределяются так, чтобы находиться в памяти одновременно с тем процессом, для которого они требуются. Это свойство позволяет считать данный тип архитектур наиболее масштабируемым среди всех четырёх.
Но это далеко не единственное преимущество. Подобные архитектуры чрезвычайно просты, ими очень легко управлять. Они никоим образом не зависят от оборудования и могут быть развёрнуты на самом дешёвом «железе». Это почти всегда исключительно программные решения. Архитектурам этого типа оперировать петабайтами данных так же просто, как дргугим - терабайтами. Здесь применяются объекты и неPOSIX-файловые системы, причём и те, и другие зачастую располагаются поверх локальной файловой системы каждого рядового нода.
Эти архитектуры можно совмещать с блоками и транзакционными моделями представления данных на базе NAS, но это сильно ограничивает их возможности. Не надо создавать транзакционный стек, помещая Тип 1, 2 или 3 поверх Типа 4.
Лучше всего эти архитектуры «раскрываются» на тех задачах, для которых не свойственны какие-то ограничения.
Выше я приводил пример с очень большим клиентом, у которого 200 000 накопителей. В основе таких сервисов, как Dropbox, Syncplicity, iCloud, Facebook, eBay, YouTube и почти всех Web 2.0-проектов лежат хранилища, построенные по архитектурам четвёртого типа. Вся обрабатываемая информация в Hadoop-кластерах также содержится в хранилищах на базе Типа 4. В целом, в корпоративном сегменте это не очень распространённые архитектуры, но они очень быстро завоёвывают популярность.
Тип 4 лежит в основе таких продуктов, как AWS S3 (кстати, никто за пределами AWS не знает, как устроен EBS, но готов спорить, что это Тип 3), Haystack (используется в Facebook), Atmos, ViPR, Ceph, Swift (используется в Openstack), HDFS, Centera. Многие из перечисленных продуктов могут обретать разную форму, вид конкретной реализации определяется с помощью их API. Например, объектный стек ViPR можно реализовать через объектные API S3, Swift, Atmos, и даже HDFS! А в будущем в этот список попадёт и Centera. Для кого-то это будет очевидно, но Atmos и Centera будут использоваться ещё долго, правда, в виде API, а не конкретных продуктов. Реализации могут меняться, но API остаются чем-то незыблемым, что очень хорошо для клиентов.
Хочу ещё раз обратить ваше внимание на то, что «физическое воплощение» может сбить вас с толку, и архитектуры Типа 4 вы ошибочно отнесёте к Типу 2, поскольку они, зачастую, выглядят одинаково. На физическом уровне какое-от решение может выглядеть как ScaleIO, VSAN или Nutanix, хотя это будут просто серверы с Ethernet. И правильно классифицировать то или иное решение поможет наличие или отсутствие транзакционности.
А теперь я предлагаю вам второй проверочный тест. Давайте рассмотрим архитектуру UCS Invicta. Физически этот продукт выглядит как Тип 4 (серверы, соединённые по Ethernet), но архитектурно его невозможно масштабировать под соответствующие нагрузки, поскольку на самом деле это Тип 1. Причём Invicta, как и Pure, разрабатывался для AFA.
Примите мою искреннюю благодарность за уделённое время и внимание, если вы дочитали до этого места. Перечитал написанное выше - удивительно, что мне удалось жениться и завести детей 🙂
Для чего я всё это расписал?
В мире IT хранилища занимают очень важное место, этакое «царство грибов». Разнообразие предлагаемых продуктов очень велико, и это идёт только на пользу всему делу. Но нужно уметь разбираться во всём этом, не позволять затуманить себе разум маркетинговыми слоганами и нюансами позиционирования. Ради блага как клиентов, так и самой индустрии, необходимо упростить процесс построения хранилищ. Поэтому мы прилагаем столько усилий, чтобы сделать из контроллера ViPR открытую бесплатную платформу.
Но сами по себе хранилища трудно назвать захватывающими. Что я имею в виду? Представим некую абстрактную пирамиду, на вершине которой находится «пользователь». Ниже расположены «приложения», предназначенные для обслуживания «пользователя». Ещё ниже - «инфраструктура» (включая SDDC), обслуживающая «приложения» и, соответственно, «пользователя». А в самом низу «инфраструктуры» находится хранилище.
То есть можно представить иерархию в таком виде: Пользователь->Приложение/SaaS->PaaS->IaaS->Инфраструктура. Так вот: в конце концов, любое приложение, любой PaaS-стек должны вычислять или обрабатывать какую-то информацию. И эти четыре типа архитектур предназначены для работы с разными типами информации, разными видами нагрузки. В иерархии важности информация следует сразу за пользователем. Цель существования приложения заключается в том, чтобы дать пользователю возможность взаимодействовать с нужной ему информацией. Именно поэтому архитектуры систем хранения данных имеют столь важное значение в нашем мире.
Запись опубликована автором в рубрике Без рубрики. Добавьте в закладки .И прочего, среды передачи данных и подключенных к ней серверов. Обычно используется достаточно крупными компаниями, имеющими развитую IT инфраструктуру, для надежного хранения данных и скоростного доступа к ним.
Упрощенно, СХД — это система, позволяющая раздавать серверам надежные быстрые диски изменяемой емкости с разных устройств хранения данных.
Немного теории.
Сервер к хранилищу данных можно подключить несколькими способами.
Первый и самый простой — DAS, Direct Attached Storage (прямое подключение), без затей ставим диски в сервер, или массив в адаптер сервера — и получаем много гигабайт дискового пространства со сравнительно быстрым доступом, и при использовании RAID-массива — достаточную надежность, хотя копья на тему надежности ломают уже давно.
Однако такое использование дискового пространства не оптимально — на одном сервере место кончается, на другом его еще много. Решение этой проблемы — NAS, Network Attached Storage (хранилище, подключенное по сети). Однако при всех преимуществах этого решения — гибкости и централизованного управления — есть один существенный недостаток — скорость доступа, еще не во всех организациях внедрена сеть 10 гигабит. И мы подходим к сети хранения данных.
Главное отличие SAN от NAS (помимо порядка букв в аббревиатурах) — это то, каким образом видятся подключаемые ресурсы на сервере. Если в NAS ресурсы подключаются протоколам NFS или SMB , в SAN мы получаем подключение к диску, с которым можем работать на уровне операций блочного ввода-вывода, что гораздо быстрее сетевого подключения (плюс контроллер массива с большим кэшем добавляет скорости на многих операциях).
Используя SAN, мы сочетаем преимущества DAS — скорость и простоту, и NAS — гибкость и управляемость. Плюс получаем возможность масштабирования систем хранения до тех пор, пока хватает денег, параллельно убивая одним выстрелом еще несколько зайцев, которых сразу не видно:
* снимаем ограничения на дальность подключения SCSI -устройств, которые обычно ограничены проводом в 12 метров,
* уменьшаем время резервного копирования,
* можем грузиться с SAN,
* в случае отказа от NAS разгружаем сеть,
* получаем большую скорость ввода-вывода за счет оптимизации на стороне системы хранения,
* получаем возможность подключать несколько серверов к одному ресурсу, это нам дает следующих двух зайцев:
- на полную используем возможности VMWare — например VMotion (миграцию виртуальной машины между физическими) и иже с ними,
- можем строить отказоустойчивые кластеры и организовывать территориально распределенные сети.
Что это дает?
Помимо освоения бюджета оптимизации системы хранения данных, мы получаем, вдобавок к тому что я написал выше:
* увеличение производительности, балансировку нагрузки и высокую доступность систем хранения за счет нескольких путей доступа к массивам;
* экономию на дисках за счет оптимизации расположения информации;
* ускоренное восстановление после сбоев — можно создать временные ресурсы, развернуть на них 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 storage) - устройство внешней памяти, напрямую подсоединенное к основному компьютеру и используемое только им. Простейший пример DAS - встроенный жесткий диск. Для связи хоста с внешней памятью в типовой конфигурации DAS используется SCSI, команды которого позволяют выделить определенный блок данных на специфицированном диске или смонтировать определенный картридж в ленточной библиотеке.
Конфигурация DAS приемлема для применений, нетребовательных к объемам, производительности и надежности систем хранения. DAS не обеспечивает возможности совместного использования емкости хранения разными хостами и тем более возможности разделения данных. Установка таких устройств хранения - более дешевый вариант по сравнению с сетевыми конфигурациями, однако, если иметь в виду большие организации, этот тип инфраструктуры хранения нельзя считать оптимальным. Много DAS-подключений означает разрозненные и разбросанные по всей компании островки внешней памяти, избытки которой не могут использоваться другими хост-компьютерами, что приводит к неэффективной трате емкости хранения в целом.
Кроме того, при такой организации хранения нет никакой возможности создать единую точку управления внешней памятью, что неизбежно усложняет процессы резервирования/восстановления данных и создает серьезную проблему защиты информации. В итоге общая стоимость владения подобной системой хранения может оказаться значительно выше, чем более сложная на первый взгляд и изначально более дорогая сетевая конфигурация.
SAN
Сегодня, говоря о системе хранения корпоративного уровня, мы имеем в виду сетевое хранение (storage networking). Больше известны широкой публике сети хранения - SAN (storage area network). SAN представляет собой выделенную сеть устройств хранения, которая позволяет множеству серверов использовать совокупный ресурс внешней памяти без нагрузки на локальную сеть.
SAN не зависит от среды передачи, но на данный момент фактическим стандартом является технология Fibre Channel (FC), обеспечивающая скорость передачи данных 1-2 Гбит/с. В отличие от традиционных сред передачи на базе SCSI, обеспечивающих подключение на расстояние не более чем на 25 метров, Fibre Channel позволяет работать на удалении до 100 км. Средой передачи в сети Fibre Channel могут служить как медный кабель, так и оптоволокно.
В сеть хранения могут подключаться дисковые массивы RAID, простые массивы дисков, (так называемые Just a Bunch of Disks - JBOD), ленточные или магнитооптические библиотеки для резервирования и архивирования данных. Основными компонентами для организации сети SAN помимо самих устройств хранения являются адаптеры для подключения серверов к сети Fibre Channel (host bus adapter - НВА), cетевые устройства для поддержки той или иной топологии FC-сети и специализированный программный инструментарий для управления сетью хранения. Эти программные системы могут выполняться как на сервере общего назначения, так и на самих устройствах хранения, хотя иногда часть функций выносится на специализированный тонкий сервер для управления сетью хранения (SAN appliance).
Задача программного обеспечения для SAN - это прежде всего централизованное управление сетью хранения, включая конфигурирование, мониторинг, контроль и анализ компонентов сети. Одной из наиболее важных является функция управления доступом к дисковым массивам, если в SAN хранятся данные разнородных серверов. Сети хранения обеспечивают одновременный доступ множества серверов к множеству дисковых подсистем, привязывая каждый хост к определенным дискам на определенном дисковом массиве. Для разных операционных систем необходимо расслоение дискового массива на «логические области» (logical unit - LUN), которыми они будут пользоваться без возникновения конфликтов. Выделение логических областей может понадобиться и для организации доступа к одним и тем же данным для некоторого пула серверов, например, серверов одной рабочей группы. За поддержку всех этих операций отвечают специальные программные модули.
Привлекательность сетей хранения объясняется теми преимуществами, которые они могут дать организациям, требовательным к эффективности работы с большими объемами данных. Выделенная сеть хранения разгружает основную (локальную или глобальную) сеть вычислительных серверов и клиентских рабочих станций, освобождая ее от потоков ввода/вывода данных.
Этот фактор, а также высокоскоростная среда передачи, используемая для SAN, обеспечивают повышение производительности процессов обмена данными с внешними системами хранения. SAN означает консолидацию систем хранения, создание на разных носителях единого пула ресурсов, который будет разделяться всеми вычислительными мощностями, и в результате необходимую емкость внешней памяти можно будет обеспечить меньшим числом подсистем. В SAN резервирование данных с дисковых подсистем на ленты происходит вне локальной сети и потому становится более производительным - одна ленточная библиотека может служить для резервирования данных с нескольких дисковых подсистем. Кроме того, при поддержке соответствующего ПО можно реализовать прямое резервирование в SAN без участия сервера, тем самым, разгружая процессор. Возможность разнесения серверов и памяти на большие расстояния отвечает потребностям повышения надежности корпоративных хранилищ данных. Консолидированное хранение данных в SAN лучше масштабируется, поскольку позволяет наращивать емкость хранения независимо от серверов и без прерывания их работы. Наконец, SAN дает возможность централизованного управления единым пулом внешней памяти, что упрощает администрирование.
Безусловно, сети хранения, недешевое и непростое решение и, несмотря на то, что все ведущие поставщики выпускают сегодня устройства для SAN на базе Fibre Channel, их совместимость не гарантируется, и выбор подходящего оборудования создает проблему для пользователей. Понадобятся дополнительные расходы на организацию выделенной сети и покупку управляющего ПО, и начальная стоимость SAN окажется выше организации хранения с помощью DAS, однако совокупная стоимость владения должна быть ниже.
NAS
В отличие от SAN, NAS (network attached storage) - не сеть, а сетевое устройство хранения, точнее, выделенный файловый сервер с подсоединенной к нему дисковой подсистемой. Иногда в конфигурацию NAS может входить оптическая или ленточная библиотека. NAS-устройство (NAS appliance) напрямую подключается в сеть и предоставляет хостам доступ к файлам на своей интегрированной подсистеме внешней памяти. Появление выделенных файловых серверов связано с разработкой в начале 90-х годов компанией Sun Microsystems сетевой файловой системы NFS, которая позволяла клиентским компьютерам в локальной сети использовать файлы на удаленном сервере. Затем у Microsoft появилась аналогичная система для среды Windows - Common Internet File System. Конфигурации NAS поддерживают обе эти системы, а также другие протоколы на базе IP, обеспечивая разделение файлов клиентскими приложениями.
NAS-устройство напоминает конфигурацию DAS, но принципиально отличается от нее тем, что обеспечивает доступ на уровне файлов, а не блоков данных, и позволяет всем приложениям в сети совместно использовать файлы на своих дисках. NAS специфицирует файл в файловой системе, сдвиг в этом файле (который представляется как последовательность байт) и число байт, которое необходимо прочитать или записать. Запрос к NAS-устройству не определяет том или сектор на диске, где находится файл. Задача операционной системы NAS-устройства транслировать обращение к конкретному файлу в запрос на уровне блоков данных. Файловый доступ и возможность разделения информации удобны для приложений, которые должны обслуживать множество пользователей одновременно, но не требуют загрузки очень больших объемов данных по каждому запросу. Поэтому обычной практикой становится использование NAS для Internet-приложений, Web-cлужб или CAПР, в которых над одним проектом работают сотни специалистов.
Вариант NAS прост в установке и управлении. В отличие от сети хранения, установка NAS-устройства не требует специального планирования и затрат на дополнительное управляющее ПО - достаточно просто подключить файловый сервер в локальную сеть. NAS освобождает серверы в сети от задач управления хранением, но не разгружает сетевой трафик, поскольку обмен данными между серверами общего назначения и NAS идет по той же локальной сети. На NAS-устройстве может быть сконфигурирована одна или несколько файловых систем, каждой из которых отводится определенный набор томов на диске. Всем пользователям одной и той же файловой системы по требованию выделяется некоторое дисковое пространство. Таким образом, NAS обеспечивает более эффективные по сравнению с DAS организацию и использование ресурсов памяти, поскольку подключенная напрямую подсистема хранения обслуживает только один вычислительный ресурс, и может случиться так, что у одного сервера в локальной сети будет слишком много внешней памяти, в то время как другой испытывает нехватку пространства на дисках. Но из нескольких NAS-устройств нельзя создать единый пул ресурсов хранения и потому увеличение числа NAS-узлов в сети усложнит задачу управления.
NAS + SAN = ?
Какую из форм инфраструктуры хранения выбрать: NAS или SAN? Ответ зависит от возможностей и потребностей организации, однако сравнивать или тем более противопоставлять их в принципе неверно, поскольку эти две конфигурации решают разные задачи. Файловый доступ и совместное использование информации для приложений на разнородных серверных платформах в локальной сети - это NAS. Высокопроизводительный блоковый доступ к базам данных, консолидация хранения, гарантирующая его надежность и эффективность - это SAN. В жизни, правда, все сложнее. NAS и SAN часто уже сосуществуют или должны быть одновременно реализованы в распределенной ИТ-инфраструктуре компании. Это неизбежно порождает проблемы управления и оптимального использования ресурсов хранения.
Сегодня производители ищут пути объединения обеих технологий в единую сетевую инфраструктуру хранения, которая обеспечит консолидацию данных, централизацию резервного копирования, упростит общее администрирование, масштабируемость и защиту данных. Конвергенция NAS и SAN - одна из самых важных тенденций последнего времени.
Сеть хранения позволяет создать единый пул ресурсов памяти и выделять на физическом уровне необходимую квоту дискового пространства каждому из хостов, подключенных к SAN. NAS-сервер обеспечивает разделение данных в файловой системе приложениями на разных операционных платформах, решая проблемы интерпретации структуры файловой системы, синхронизации и контроля доступа к одним и тем же данным. Поэтому, если мы хотим добавить в сеть хранения возможность разделения не только физических дисков, но и логической структуры файловых систем, нам необходим промежуточный управляющий сервер для реализации всех функций сетевых протоколов обработки запросов на уровне файлов. Отсюда общий подход к объединению SAN и NAS с помощью NAS-устройства без интегрированной дисковой подсистемы, но с возможностью подключения компонентов сети хранения. Такие устройства, которые у одних производителей называются NAS-шлюзами, у других головными NAS-устройствами, становятся своеобразным буфером между локальной сетью и SAN, обеспечивая доступ к данным в SAN на уровне файлов и разделение информации в сети хранения.
Резюме
Построение единых сетевых систем, объединяющих возможности SAN и NAS, - лишь один из шагов в направлении глобальной интеграции корпоративных систем хранения. Дисковые массивы, подключенные напрямую к отдельным серверам, перестали удовлетворять потребностям больших организаций с сложными распределенными ИТ-инфраструктурами. Сегодня просто сети хранения на основе высокопроизводительной, но специализированной технологии Fibre Channel рассматриваются не только как прорыв, но и как источник головной боли из-за сложности инсталляции, проблем с поддержкой оборудования и ПО от разных поставщиков. Однако то, что ресурсы хранения должны быть едиными и сетевыми, сомнения уже не вызывает. Ищутся пути оптимальной консолидации. Отсюда и активизация производителей решений, поддерживающих различные варианты переноса сетей хранения на IP-протокол]. Отсюда и большой интерес к различным реализациям концепции виртуализации хранения. Ведущие игроки рынка систем хранения не просто объединяют все свои продукты под общей «шапкой» (TotalStorage у IBM или SureStore у НР), но формулируют собственные стратегии создания консолидированных, сетевых инфраструктур хранения и защиты корпоративных данных. Ключевую роль в этих стратегиях будет играть идея виртуализации, поддержанная главным образом на уровне мощных программных решений централизованного управления распределенными хранилищами. В таких инициативах, как StorageTank от IBM, Federated Storage Area Management от НР, E-Infrostructure от ЕМС, программное обеспечение играет решающую роль.
Если Серверы - это универсальные устройства, выполняющие в большинстве случаев
- либо функцию сервера приложения (когда на сервере выполняются специальные программы, и идут интенсивные вычисления),
- либо функцию файл-сервера (т.е. некоего места для централизованного хранения файлов данных)
то СХД (Системы Хранения Данных) - устройства, специально спроектированные для выполнения таких серверных функций, как хранение данных.
Необходимость приобретения СХД
возникает обычно у достаточно зрелых предприятий, т.е. тех, кто задумывается над тем, как
- хранить и управлять информацией, самым ценным активом компании
- обеспечить непрерывность бизнеса и защиту от потери данных
- увеличить адаптируемость ИТ-инфраструктуры
СХД и виртуализация
Конкуренция заставляет компании МСБ работать эффективней, без простоев и с высоким КПД. Смена производственных моделей, тарифных планов, видов услуг происходит всё чаще. Весь бизнез современных компаний "завязан" на информационных технологиях. Потребности бизнеса меняются быстро, и мгновенно отражаются на ИТ - растут требования к надёжности и адаптируемости ИТ-инфраструктуры. Виртуализация предоставляет такие возможности, но для этого нужны недорогие и простые в обслуживании системы хранения данных.
Классификация СХД по типу подключения
DAS . Первые дисковые массивы соединялись с серверами по интерфейсу SCSI. При этом один сервер мог работать только с одним дисковым массивом. Это - прямое соединение СХД (DAS - Direct Attached Storage).
NAS . Для более гибкой организации структуры вычислительного центра - чтобы каждый пользователь мог использовать любую систему хранения - необходимо подключить СХД в локальную сеть. Это - NAS - Network Attached Storage). Но обмен данными между сервером и СХД во много раз более интенсивный чем между клиентом и сервером, поэтому в таком варианте варианте появились объективные трудности, связанные с пропускной способностью сети Ethernet. Да и с точки зрения безопасности не совсем правильно показывать СХД в общую сеть.
SAN . Но можно создать между серверами и СХД свою, отдельную, высокоскоростную сеть. Такую сеть назвали SAN (Storage Area Network). Быстродействие обеспечивается тем, что физической средой передачи там является оптика. Специальные адаптеры (HBA) и оптические FC-коммутаторы обеспечивают передачу данных на скорости 4 и 8Gbit/s. Надёжность такой сети повышалась резервированием (дупликацией) каналов (адаптеров, коммутаторов). Основным недостатком является высокая цена.
iSCSI . С появлением недорогих Ethernet-технологий 1Gbit/s и 10Gbit/s, оптика со скоростью передачи 4Gbit/s уже выглядит не так привлекательно, особенно с учетом цены. Поэтому всё чаще в качестве среды SAN используется протокол iSCSI (Internet Small Computer System Interface). Сеть iSCSI SAN может быть построена на любой достаточно быстрой физической основе, поддерживающей протокол IP.
Классификация Систем Хранения Данныхпо области применения:
| класс | описание |
|
personal |
Чаще всего представляют из себя обычный 3.5" или 2.5" или 1.8" жесткий диск, помещенный в специальный корпус и оснащенный интерфейсами USB и/или FireWire 1394 и/или Ethernet, и/или eSATA. |
small workgroup |
Обычно это стационарное или переносное устройство, в которое можно устанавливать несколько (чаще всего от 2 до 5) жестких дисков SATA, с возможностью горячей замены или без, имеющее интерфейс Ethernet. Диски можно организовывать в массивы - RAID различного уровня для достижения высокой надежности хранения и скорости доступа. СХД имеет специализированную ОС, обычно на основе Linux, и позволяет разграничивать уровень доступа по имени и паролю пользователей, организовывать квотирование дискового пространства и т.п. |
|
workgroup |
Устройство, обычно монтируемое в 19" стойку (rack-mount) в которое можно устанавливать 12-24 жестких дисков SATA или SAS с возможностью горячей замены HotSwap. Имеет внешний интерфейс Ethernet, и/или iSCSI. Диски организованы в массивы - RAID для достижения высокой надежности хранения и скорости доступа. СХД поставляется со специализированным программным обеспечением, которое позволяет разграничивать уровень доступа, организовывать квотирование дискового пространства, организовывать BackUp (резервное копирование информации) и т.п. Такие СХД подходят для средних и крупных предприятий, и используются совместно с одним или несколькими серверами. |
enterprise  |
Стационарное устройство или устройство, монтируемое в 19" стойку (rack-mount) в которое можно устанавливать до сотен жестких дисков. В дополнение к предыдущему классу СХД могут иметь возможность наращивания, модернизации и замены компонент без остановки системы, системы мониторинга. Программное обеспечение может поддерживать создание "моментальных снимков" и другие "продвинутые" функции. Такие СХД подходят для больших предприятий и обеспечивают повышенную надежность, скорость и защиту критически важных данных. |
|
high-end enterprise |
В дополнение к предыдущему классу СХД может поддерживать тысячи жестких дисков. |
История вопроса.
Первые серверы сочетали в одном корпусе все функции (как компьютеры) - и вычислительные (сервер приложений) и хранение данных (файл-сервер). Но по мере роста потребности приложений в вычислительных мощностях с одной стороны и по мере роста количества обрабатываемых данных с другой стороны - стало просто неудобно размещать все в одном корпусе. Эффективнее оказалось выносить дисковые массивы в отдельные корпуса. Но тут встал вопрос соединения дискового массива с сервером. Первые дисковые массивы соединялись с серверами по интерфейсу SCSI. Но в таком случае один сервер мог работать только с одним дисковым массивом. Народу захотелось более гибкой организации структуры вычислительного центра - чтобы любой сервер мог использовать любую систему хранения. Подключить все устройства напрямую в локальную сеть и организовать обмен данными по Ethernet - конечно, простое и универсальное решение. Но обмен данными между серверами и СХД во много раз более интенсивный чем между клиентами и серверами, поэтому в таком варианте варианте (NAS - см. ниже) появились объективные трудности, связанные с пропускной способностью сети Ethernet. Возникла идея создать между серверами и СХД свою, отдельную высокоскоростную сеть. Такую сеть назвали SAN (см. ниже). Она похожа на Ethernet, только физической средой передачи там является оптика. Там тоже есть адаптеры (HBA), которые устанавливаются в серверы и коммутаторы (оптические). Стандарты на скорость передачи данных по оптике - 4Gbit/s. С появлением технологий Ethernet 1Gbit/s и 10Gbit/s, а также протокола iSCSI всё чаще в качестве среды SAN используется Ethernet.
