SAN протоколы: чем FC лучше?

В данном посте кратко сформулирую преимущества Fibre Channel перед iSCSI. На рисунке ниже приведен пример передачи данных по FC сети между хостом и массивом.

Драйвер HBA "говорит" аппаратуре HBA где взять данные и куда их записать, в результате перемещение данных между памятью и сетью выполняет только HBA без использования ресурсов центрального процессора. HBA считывает блок данных из ОЗУ основной системы, инкапсулирует данные через уровни FC и пересылает в сеть поток пакетов. На другом конце сети RAID-массив выполняет аналогичные операции для записи данных на нужный диск (или диски). В этом случае данные никогда не приходят к приложению в "сыром" виде - они отображаются с помощью аппаратно реализованного менеджера томов (например, RAID 5), который определяет, на какие физические диски нужно записать конкретные блоки данных из потока.

Fibre Channel использует механизм группировки до 65 килобайт данных в последовательность (sequence). Последовательность пакетов является базовой единицей при передаче данных с использованием аппаратного ускорения, поэтому более сотни мегабайт данных можно передать через Fibre Channel HBA и при этом загрузка центрального процессора будет такая же, как при передаче только одного пакета Ethernet без применения аппаратного ускорения. Fibre Channel позволяет даже объединять последовательности в один обмен (exchange). Обычно каждая операция SCSI (чтения или записи) отображается в один exchange 

Итого Преимущество 1: на обработку iSCSI требуются процессорные мощности. Обработка FC идет без использования ЦП. 

На рисунке ниже показаны различия в пакетах передачи данных по протоколам iSCSI и FC.

Итого Преимущество 2: необоснованно большой размер заголовка в iSCSI пакетах по сравнению с FC.

 Да, можно использовать jumbo-кажры - сверхдлинные Ethernet-кадры, которые используются в высокопроизводительных сетях для увеличения производительности на длинных расстояниях, а также уменьшения нагрузки на центральный процессор. Jumbo-кадры имеют размер, превышающий стандартный размер MTU: от 1518 до 16000 байт. Но в этом случае приходится использовать дорогие коммутаторы корпоративного плана. 

Основным препятствием для распространения Ethernet как базовой технологии построения сетей хранения данных является относительно большое время задержки (близкое к 75 -80 микросекундам), которое возникает из-за особенностей стека TCP/ІР. В High-End системах при одновременном обращении к тысячам файлов это может стать серьезной проблемой. 

Преимущество 3: нет задержек в сети

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

Более подробно о FC можно почитать в Статье о FC 

Детальное описание iSCSI представлено здесь на ixbt

Репликация в СХД

Сегодня я решил обобщить свои знания о репликации по отношению к передаче данных между ЦОДами. Стоит обратить внимание, что несмотря на использование того же термина "репликация", в теории БД трактовка данного понятия немного другая (что вылилось в то, что мои знания по репликации в PostgreSQL практически неприменимы к построению архитектуры систем с дата центрами)

Репликация, прежде всего, делится на синхронную и асинхронную, которые в свою очередь имеют несколько видов. Для начала рассмотрю первый случай - синхронная репликация.

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

2 назависимые площадки: классический вариант синхронной репликации:

данные поступают в кэш на первой площадке, затем данные попадают в кэш на 2й площадке и только после этого на сервер приходит подтверждение. Данные на носители записываются уже в фоновом режиме.

При изучении виртуализации СХД столкнулся с технологией организации единой СХД, расположенной на 2х площадка, используемой в EMC VPLEX. На данный момент найти какую-либо подбробную иноформацию об этой технологии не удалось, знаю лишь, что используется EMC Distributed Cache Coherence.

Асинхронная репликация также имеет несколько подвидов:

Первый подвид торжественно назову "классикой", а второй - журнальная репликация

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

Журнальная репликация является частным случаем асинхронной "классики": данные накапливаются в неком буфере - журнале, откуда уже передаются на другую площадку. Данный случай выгоден либо при использовании плохих каналов связи, либо при жестком выделении трафика.

Offtop: оказывается, в Open Office можно генерить 3D объекты. Если грамотно расположить элементы, то получается очень даже ничего. 

Виртуализация СХД. Итог

IBM SVC

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

• Единое ПО резервирования путей и балансировки нагрузки
• Использование кэша для ускорения работы с часто используемыми данными
• Не нужен СХД IBM – работает с СХД любых производителей

Недостатки:

• Appliance = «bottleneck» - задержки при переполнении кэша

• Затруднение масштабирования - необходимость синхронизации кэширования  

HP SVSP

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

• Нет задержек при обработке данных — обрабатываются лишь управляющие данные

Недостатки:

• Меньший опыт внедрения решений на рынке

EMC Invista

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

• наиболее простое с точки зрения внедрения решение

Недостатки:

• нет внутреннего диска
• ограниченное кол-во поддерживаемых дисков
• необходимость интеллектуальных коммутаторов

EMC VPLEX

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

• В отличие от Invista не требует «умных» коммутаторов
• Использует распределнный кэш
• Позволяет серверам на разных площадках видеть 2 СХД как единое целое

Недостатки:

• необходим 1 диск EMC для метаданных
• нет асинхронного режима (больше, чем на 100 км)
• малое кол-во поддерживаемых СХД
• нет thin provisioning
• нет мгновенных снимков
• нет внутреннего диска, как и в Invista

Виртуализация СХД. Решения EMC

EMC Invista

Решение EMC Invista так же, как и HP SVSP, является представителем асинхронной виртуализации, но использует коммутирующую виртуализацию (switch-based), реализующую управление на уровне интеллектуальных коммутаторов Fibre Channel.  Решение представляет собой серверный кластер CPC (Control Path Cluster), работающий совместно с интеллектуальными коммутаторами семейства Cisco (MDS) или Brocade (AP7420). На коммутаторе располагается Data Path Controller, который передает данные. Кластер CPC базируются на платформе х86.

В отличие от IBM SVC Invista не перегружает трафик от хоста к LUN. Интеллектуальный FC switch мэппирует запросы для виртуальных томов в запросы к соответствующим LUN согласно инструкциям CRC, также CRC кластер используется для реализации функции репликации, что невозможно сделать только при помощи интеллектуальных коммутаторов.

В момент, когда поток ввода-вывода попадает в интеллектуальный SAN-коммутатор, контроллер порта (ASIC) определяет его тип и в зависимости от результата перенаправляет поток. Если тот содержит операции с данными (чтение или запись), коммутатор действует в обычном режиме, пропуская его к системе хранения. Если поток содержит служебные команды, он перенаправляется в процессор потока управления (CRC), ответственный за реализацию виртуализации. При этом приложение, инициировавшее поток ввода-вывода, не получит подтверждения об окончании репликации до тех пор, пока данные не окажутся внутри реальной физической системы хранения. Стоит отметить, что контроллеру требуется примерно 20—30 мкс на перенаправление потока и при этом, согласно статистике, около 99% потоков содержит в себе данные, что в сумме означает крайне незначительные накладные расходы при реализации технологий виртуализации в SAN-сети, не оказывающие существенного влияния на общую производительность инфраструктуры хранения. Согласно данным корпорации EMC, общая производительность комплекса в зависимости от используемой модели коммутатора составляет порядка 1,6—2 млн IOPS при максимальной пропускной способности до 12 Гбайт/с.

В общем виде архитектура Invista представлена на рис. 3. В процессе работы CPC поддерживает репозиторий метаданных, в которых отражено соответствие логических и физических ресурсов хранения. CPC загружает метаданные, при необходимости снабжает ими коммутаторы и обрабатывает возникающие исключительные ситуации. При этом CPC остается вне потока данных и не вызывает задержек ввода/вывода.

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

Источник:

www.bytemag.ru 

Несколько полезных ссылок про EMC Invista

www.youtube.com

www.youtube.com

EMC VPLEX

EMC VPLEX была представлена в мае 2010 года. Состоит из двух продуктов: VPLEX Local и VPLEX Metro. Ключевым элементом виртуальной системы хранения является объединение распределенных массивов данных: ресурсы из разных систем хранения локально и удаленно собираются в пул и начинают работать как единое целое. Предположим, есть две площадки, на каждой - по системе хранения. Между СХД – репликация. Но в итоге сервера на обоих площадках работают как будто с единственной СХД.

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

В перспективе EMC обещает еще две версии VPLEX – Global, для объединения двух площадок на расстоянии более 100км (асинхронная репликация) и VPLEX Geo, который уже позволит объединять несколько датацентров на произвольном расстоянии друг от друга. 

Минимальный модуль (VPLEX Engine) состоит из двух x86 серверов (каждый отдельно называется Director), упакованных в одно шасси высотой 4U. Максимум в кластер для увеличения производительности можно объединить до 4х Engine (8 директоров). Друг с другом директоры общаются через выделенные FC порты, для чего используются отдельные коммутаторы.  Помимо 4х узлов и двух коммутаторов в стойке также размещается управляющий сервер, через который собственно и происходит вся работа с VPLEX. Из 32ГБ памяти каждого директора, в качестве кэша используется около 20ГБ, таким образом, на каждой площадке можно получить до 160ГБ кэша. Кэш используется только для чтения: при получении запроса VPLEX проверяет наличие данных у себя в кэше, если данных там нет, то проверяется глобальный кэш (память остальных узлов) и только если данных не оказывается и там, делается запрос на чтение с дисков. Вся запись ведется “сквозным” образом, т.е. подтверждение хосту об успешном завершении отправляется только после того как VPLEX получит соответствующее подтверждение от всех дисковых систем, участвующих в записи блока данных. 

Виртуализация СХД. HP SVSP

HP StorageWorks SAN Virtualization Services Platform (SVSP)

Решение HP по виртуализации СХД использует противоположный подход по сравнению с IBM SVC, реализовывая асимметричную топологию. HP SVSP  обрабатывает не поток данных, а лишь командные, управляющие данные. По оценкам HP количество управляющих данных составляет примерно 5% от общего потока. Здесь трафик данных регулируется выделенными модулями (Data Path Modules), работой которых управляют средства VSM (Storage Virtualisation Manager), работающие как внешний виртуализатор на выделенных серверах. 

Наглядное сравнение двух различных подходов к организации виртуализации показано на рисунке ниже. Стрелкой изображен поток данных.

Для более подробной информации можно обратиться к презентации HP

и ее продолжение

Виртуализация СХД. IBM SVC

IBM TotalStorage SAN Volume Controller (SVC) 

IBM SVC (SAN Volume Controller) является примером симметричной топологии, когда поток данных от хостов проходит через appliance. Система включается в тракт между сетью хостов и сетью Fibre Channel в SAN, к которой могут быть подключены массивы множества производителей. Получается, что вся инфраструктура разделяется на 2 части — зону хостов и зону хранения.

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

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

Также минусом является затруднение масштабирования из-за ряда технических моментов, таких, как необходимость синхронизации кэширования.

Виртуализация СХД. Обзор

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

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

Думаю, вполне очевидно, что виртуализация позволяет более гибко подстраивать storage под свои нужды, решая такие задачи, как:

• организация многоуровнего хранилища
• повышение надежности системы
• улучшение масштабируемости системы
• более экономичное распределение данных
• объединение СХД различных вендоров в единый пул
• миграция без остановки работы системы
• снижение затрат на управление и администрирование СХД

Подчеркну, что в данном цикле будет рассматриваться виртуализация на уровне SAN  - (всего возможно 3 варианта: уровень сервера, сети и СХД). Ассоциация Storage Networking Industry Association определяет виртуализацию систем хранения на сетевом уровне (Network-based Virtualization) следующим образом: «Сетевая виртуализация интегрирует функции или сервисы заднего плана (back end) и тем самым повышает степень абстрактности представления данных; одновременно она расширяет сервисы переднего плана (front end)».

 

В данном контексте возможно деление на in-band (симметричную) и out-of-band (асиметричную) архитектуру. В первом случае весь трафик (и данные, и управляющие пакеты) обрабатываются специально выделенным компонентом (как правило, сервер x86), во втором - обрабатываются лишь управляющие данные.  

 In-band и out-of-band архитектуры

О различиях в подходах будет более подробно сказано в обзоре HP SVSP. 

У меня нет идеи выделить какое-либо решение и сказать, что оно идеально - ни в коем случае. Выбор продукта целиком и полностью зависит от конкретной среды внедрения, от существующих на момент внедрения СХД и от запущенных приложений + конечно, некий опыт инженеров заказчика (вот в далеком 199х. мы работали с EMC и тогда у нас что-то не пошло, поэтому всё, EMC предоставляет плохие решения и мы с ними больше не дружим). Для демонстрации различных подходов были выбраны следующие решения:

• IBM TotalStorage SAN Volume Controller (SVC)
• HP StorageWorks SAN Virtualization Services Platform (SVSP)
• EMC InVista.
• EMC VPLEX

Новые технологии в СХД на примере DS8800

Начну, пожалуй с обзора технологий, которые появились во флагмане СХД IBM - DS8800.

Модульная структура

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

            Модульная структура позволяет реализовать систему вентиляции в виде концепции холодных (cool aisle) и горячих(hot aisle) коридоров спереди и сзади стоек. Данное расположение позволяет использовать рассматриваемые СХД в серверных помещениях без фальшпола и вентиляционных коммуникаций.

Рис.1. Реализация концепции холодных и горячих коридоров.

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

 

Easy Tier

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

            В связи с этим необходимо обеспечить динамическое перемещение данных по физической памяти в замен статического выделения определенного объема.

            Технология Easy Tier позволяет более эффективно консолидировать ресурсы благодаря упрощению использования твердотельных дисков с помощью автоматического и динамического перемещения данных на соответствующий уровень системы на основе постоянного мониторинга производительности.

Операции ввода/вывода	Разница между SSD и HDD (разы)
Произвольное чтение	100
Произвольная запись	40
Последовательное чтение/запись	2

Очевидно, что с точки зрения производительности дисковой системы все HDD стоит заменить на SSD, но это не является хорошим решением с точки зрения стоимости проекта. Поэтому без системы эффективного размещения данных на различных уровнях дисковой системы необходимость в твердотельных накопителях не была бы столь высокой, так было бы непонятно, какие данные следует размещать на данных носителях. Могут возникать такие вопросы, как стоит ли переносить весь том с SAS на SSD-диск, если преимущество будет только для небольшой части данных? 

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

Easy Tier также включает возможность динамического перемещения отдельных логических томов на другой уровень дисковой системы или на другой тип дисков в рамках одного уровня. Например возможно перемещение тома из набора дисков со скоростью вращения 15,000 об/мин на набор дисков со скоростью вращения 10,000 об/мин. Более того, можно изменить тип RAID, а также изменить способ страйпинга данных в рамках системы.

            Помимо автоматического режима возможно ручное управление объединением ресурсов и перемещением томов.

Рис.2. Стандартная конфигурация DS8700 с SSD и HDD дисками

 

На Рис.2. представлена стандартная конфигурация системы хранения данных DS8700 с 8 SSD и 24 HDD дисками. SSD диски установлены на первых местах в дисковой паре для использования в рамках одной дисковой области (enclosure). Дополнительные SSD диски могут быть установлены в зарезервированные позиции. Нижняя половина второго фрейма (33-40) могут содержать только HDD диски. 

Dynamic Volume Expansion и Thin Provisioning

            Очень часто приходится решать задачу по расширению емкости буквально “на ходу” в случае невозможности прогнозирования жесткой верхней границы емкости. Для реализации этой возможности в DS8800 были созданы функции динамического расширения томов (Dynamic Volume Expansion) и экономного распределения ресурсов (Thin Provisioning).

            Особенностью технологии Dynamic Volume Expansion является динамическое увеличение размера LUN без потери данных. В случае DS8800 дополнительные ресурсы будут добавлены к тому, но важно, чтобы операционная система поддерживала изменение размера томов. В целях избегания потери данных данная технология не позволяет уменьшать объем тома.

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

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

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

            Если рассматривать  пользователей, сотрудников организации, как потребителей физической памяти, то, например, предполагается, что каждому не требуется больше 20 Гб памяти, а средняя потребность составляет меньше 12Гб. Из этого слудет, что виртуально каждому пользователю будет выделено по 20 Гб, а реальный физический пул будет состоять лишь из 12 Гб. При количестве сотрудников в одну сотню, используемая память равняется всего 1,2 Тб, а разница между виртуальным и физическим пулом будет составлять 800 Гб (40%), которую можно выдать пользователям с потребностью более 20 Гб либо использовать для других нужд. Важно отметить роль системного администратора, который должен следить за перемещением ресурсов и контролировать  выделение памяти.

Из представленных выше примеров следует, что данная технология четко разделяет процессы конфигурирования и выделения памяти.

Рис.3. Выделение памяти по технологии Thin Provisioning

            Thin Provisioning реализуется на основе следующих модулей: Виртуальный пул емкости – некий контейнер, где будут созданы запрашиваемые тома. Важно обратить внимание, что это именно логический контейнер, где нет реальной физической емкости. Реальный пул емкости – это физическая совокупность дисков, являющийся резервом при запросе на физические носители. Тома с эффективным объемом (Space efficient Volume) могут быть привязаны к любому хосту. Эти тома при создании не имеют никакой физической емкости за исключением места под необходимые метаданные, но при первой записи в том физическая емкость из реального пула емкости будет перенесена в данный том.

Выводы

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

            Технология Easy Tier позволяет более эффективно использовать возможности SSD накопителей в совокупности с HDD дисками, что приводит к увеличению производительности всей системы в целом. Стоит отметить, что оптимизация может выполняться как вручную, так и полностью автоматически, что минимизирует усилия при наладке.

            Технологии динамического расширения томов (Dynamic Volume Expansion) и экономного распределения ресурсов (Thin Provisioning) позволяют избежать простаивания ресурсов и более эффективно распоряжаться имеющейся емкостью. Технология четко разграничивает конфигурирование и выделение памяти, что облегчает процесс проектирования, так как не нужно закладывать определенные объемы памяти в начале разработки системы, а можно перемещать дисковые мощности динамически по системе при ее эксплуатации

Вариант статьи в формате *.doc размещен здесь:

Новые технологии в системах хранения данных на примере IBM DS8800