В одной из своих статей я рассказал что такое архитектура FlexPod DC и из чего она состоит, к физическим компонентам FlexPod DC относятся: СХД NetApp серии FAS, сервера Cisco UCS и Nexus свичи. Существует большое разнообразие поддерживаемых дизайнов FlexPod DC состоящего из этих трех основных компонент. Для того чтобы воспользоваться кооперативной поддержкой из «одних рук» необходимо наличие соответствующего сервиса поддержки для всех этих компонент.

Что если сервисы Cisco SnartNet и NetApp Support Edge у вас есть, а в архитектуре отсутствуют Nexus свичи, при этом СХД напрямую включена в UCS Fabric Interconnect?

Это и есть «не-FlexPod DC» архитектура о которой пойдёт речь, она тоже может поддерживаться из «одних рук» по программе Cisco «Solution Support for Critical Infrastructure» (SSCI).


Общий дизайн SAN сети с прямым включением

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


Схема подключения свичей для Cluster Interconnect

Когда у вас есть на руках (хотябы временно) больше двух контроллеров FAS, кластерный свич может понадобится, в случае:

Добавление в кластер системы хранения NetApp FAS происходит очень просто:
Подключаются порты кластерного интерконнекта в свич и выполняется команда:

cluster setup

А как вывести ноду из кластера?

Системы хранения NetApp FAS могут объединяться в кластер до 8 нод для предоставления доступа в SAN сетях и до 24 нод для Ethernet сетей. Давайте рассмотрим пример настройки зонирования и схему подключения для таких кластерных систем.

Общая схема подключения для SAN и NAS.

На сегодняшний день на рынке дисковых массивов от компании Hauwei существует легкая неразбериха. Связано это с тем, что за неполный год Huawei анонсировал целых 2 новых поколения СХД, оставляя при этом на рынке ряд решений из предыдущих линеек. При этом разница между поколениями достаточно значима.

Поэтому, я решил рассказать о текущих предложениях компании Huawei для прояснения данного вопроса.

Введение

После тестирования и написания статьи о влиянии механизмов кэширования на производительность в младшей модели (entry level) СХД EMC VNXe3200, периодически начали чесаться руки проделать то же самое с ее старшими собратьями массивами VNX2. Недавно такая возможность представилась. Удалось прогонять тесты на VNX5400. Кроме того, помимо тестирования непосредственно VNX5400, получилось потестировать еще и решение EMC ExtremCache (PCI-E SSD карточка EMC XtremSF700 на eMLC чипах + софт EMC XtremSW). Но про EMC ExtremCache будет следующая статья. Пока же поговорим про массивы VNX2.

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

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



Итак, дано:
Инфраструктура виртуализации VMware Enterprise Plus. Включает продуктив, тестовую зону и VDI. Последний реализован на базе продукта fujitsu Pano Logic, который уже 2 года как не обновляется и, судя по всему, не поддерживается.
Основной модернизируемый кластер — VDI, как самый объёмный критичный сервис и самый плотный по утилизации ресурсов. Реализован на базе полных клонов, ибо связанные клоны pano manager сам по себе не понимает, а покупать ещё и View бизнес не хочет.

В качестве СХД используется набор массивов EMC — несколько CX4-240 и пара VNX. А также есть такой изыск как IBM SVC. Используется для консолидации и виртуализации хранения (то есть lun монтируются со стораджей на SVC, там объединяются в пулы, а на этих пулах уже создаются новые LUN, отдаваемые серверам). Все хранилища подключены по FC SAN.

Введение

Недавно и не надолго ко мне в руки попала система хранения данных (СХД) VNXe3200, которая была анонсирована компанией EMC² для заказчиков 5 мая 2014 года. VNXe3200 — это второе поколение entry-level Unified СХД компании EMC². В данной модели появились технологии доступные ранее только на более старших и более дорогих midrange массивах. В частности технология FastCachе — т.е. кэш второго уровня на SSD дисках, который встает в разрез между традиционным кэшем в оперативной памяти контроллера СХД (в терминологии EMC — Storage Processor) и собственно дисками. Я решил проверить, как данная технология влияет на производительность ввода/вывода на самых младших СХД компании EMC².

Новость: начались поставки 8Тб жёстких дисков, анонсированы 10Тб жёсткие диски с «черепичной» системой записи (shingled magnetic recording), которая обещает увеличение объёмов путём снижения скорости случайного доступа (подробности).

Комментарий

SSD почти полностью сожрали всё в диапазоне десятков/сотен гигабайт. HDD используется только как сверхдешёвая заглушка, и я не понимаю, почему ни один ушлый китаец не догадался сделать SD-кардридер с mSATA-интерфейсом. Для low-end'а (лишь бы загрузиться) этого хватит за глаза и за уши, а стоить будет дешевле. Если же человеку это «медленно», то очевидно, что SSD его спасёт. По мере продвижения за 300-400Гб картинка становится экономически непривлекательной для многих сегментов (1Tb стоит €50 за HDD против €350 за самую дешёвую SSD). Но все понимают, что выход на бюджетный терабайт для SSD — вопрос времени. Хотя потребности в месте растут (игры/кино всё больших разрешений), в то же самое время область потребностей сокращается (зачем качать, когда можно смотреть в онлайне), то есть десктопный рынок можно считать потерянным.

Но, кроме него есть и другие рынки.

HDD, кроме low-end'а, продолжают жить:

1. Из-за совершенно сумашедшего парка серверов, которые живут много больше, чем диски. Диски надо менять.
2. Из-за гигантских объёмов за разумные деньги
3. Из-за лучшей производительности на устоявшуюся линейную запись.

Вот последний фактор определяет уникальную нишу для HDD — они лучше подходят для линейной записи. У SSD с этим много хуже — если на SSD постоянно писать большими блоками, то housekeeep'инг перестаёт справляться (особенно, если запись циклическая внутри файла, типа серверов видеонаблюдения), кеш забивается, и SSD деградирует до уровня WD Green'ов или даже хуже. При этом стоят они дороже, износ на запись у них множится на write amplification (когда диск забит данными, SSD приходится перемещать несколько блоков, чтобы записать один), чем дешевле SSD, тем у неё обычно хуже ресурс (а в отличие от бытового «ой, моя SSD'ка изнашивается» потенциальный износ SSD на сервере видеонаблюдения — вполне объективный вопрос).

SnapManager — это набор утилит компании NetApp позволяющих автоматизировать процессы снятия так называемых Application-Consistent Backup (ACB) и Crash-Consistent Snapshots (CCS) без остановки приложений, средствами СХД NetApp FAS серии, их архивации, резервного копирования, тестирования копий и архивов, клонирования, примапливания склонированных данных к другим хостам, восстановления и др. функциями через GUI интерфейс одним только лишь оператором приложения без привлечения специалистов по серверам, сети и СХД.


SnapManager for Oracle on Windows, Cloning Operation

Зачем вообще бэкапировать данные при помощи снапшотов и тем более средствами СХД? Дело в том, что большинство современных способов бэкапирования информации подразумевают длительность процесса, ресурсоёмкость: нагрузка на хост, загрузка каналов, занимание пространства и как следствие к деградации сервисов. Тоже касается и клонирования больших объемов информации для Dev/Test подразделений, увеличивая «временной разрыв» между актуальными данными и резервируемыми, это повышает вероятность того, что бэкап может оказаться «не восстановим». С применением «аппаратных» снапшотов компании NetApp, не влияющих на производительность и занимающий не положенные 100% резервной копии, а только лишь «разницу» (своего рода инкрементального бэкапа или лучше сказать обратного инкрементального бэкапа, на снятие и сборку которого не нужно тратить время), а также возможность передачи данных для резервирования и архивирования в виде снапшотов, позволяя более элегантно решать современные высокие требования бизнеса для подобных задач, уменьшая время передачи информации и нагрузку на хосты.

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

Общая информация

XtremIO — новый (относительно) продукт компании EMC, точнее компании XtremIO, купленной компанией EMC. Представляет собой All-Flash array, состоящий из пяти модулей — два одноюнитовых сервера Intel в качестве контроллеров, два ИБП Eaton и одна дисковая полка на 25 дисков. Всё перечисленное объединяется в брик (brick) — единицу расширения XtremIO.
Киллер-фичей решения является дедупликация «на лету». Нам этот факт был особенно интересен, поскольку пользуем VDI с полными клонами и их у нас много. Маркетинг обещал, что все влезут в один брик (ёмкость брика — 7,4 ТБ). В данный момент на обычном массиве они занимают почти 70+ ТБ.
Сфотографировать предмет повествования я забыл, но в посте КРОКа можно увидеть всё в деталях. Я уверен даже, что это тот же самый массив.

Не так давно компания Huawei решила, что ей стало тесно в нишевом рынке операторов телекоммуникационных услуг. Результатом этого стало создание отдельного подразделения IT в их дивизионе Enterprise. При этом китайцы подошли к этому вопросу масштабно.

Когда Huawei говорят про IT, то они подразумевают действительно все продуктовые линейки, которые охватывают IT-инфраструктуру предприятия, причем от SOHO/ROBO до Enterprise уровня.
Понятно, что при наличии такого портфолио компания может предложить своим клиентам действительно сквозные решения, закрывающее все нужды клиента. Сегодня я хочу рассказать вам об одном из них: Huawei MicroDC.

Продолжаю вещать на тему прояснения основных представлений об FC SAN. В комментариях к первому посту меня попрекнули тем, что копнул недостаточно глубоко. В частности — мало сказал о непосредственно FC и ничего о BB credits, IP и multipathing. Multipathing и IP — темы для отдельных публикаций, а про FC, пожалуй, продолжу. Или начну, как посмотреть.

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

Fibre or Fiber?: Изначально технология Fibre Channel предполагала поддержку только волоконно-оптических линий (fiber optic). Однако, когда добавилась поддержка меди, было принято решение название в принципе сохранить, но для отсылки на стандарт использовать британское слово Fibre. Американское Fiber сохраняется преимущественно для отсылки на оптоволокно.

Оригинал

Fibre Channel was originally designed to support fiber optic cabling only. When copper support was added, the committee decided to keep the name in principle, but to use the UK English spelling (Fibre) when referring to the standard. The US English spelling (Fiber) is retained when referring generically to fiber optics and cabling.

IBM Redbook «Introduction to SAN and System Networking»

Начало

По аналогии с сетевой моделью OSI, Fibre Channel состоит из пяти уровней. Каждый уровень обеспечивает определённый набор функций.

В деле познания SAN столкнулся с определённым препятствием — труднодоступностью базовой информации. В вопросе изучения прочих инфраструктурных продуктов, с которыми доводилось сталкиваться, проще — есть пробные версии ПО, возможность установить их на вирутальной машине, есть куча учебников, референс гайдов и блогов по теме. Cisco и Microsoft клепают очень качественные учебники, MS вдобавок худо-бедно причесал свою адскую чердачную кладовку под названием technet, даже по VMware есть книга, пусть и одна (и даже на русском языке!), причём с КПД около 100%. Уже и по самим устройствам хранения данных можно получить информацию с семинаров, маркетинговых мероприятий и документов, форумов. По сети же хранения — тишина и мёртвые с косами стоять. Я нашёл два учебника, но купить не решился. Это "Storage Area Networks For Dummies" (есть и такое, оказывается. Очень любознательные англоговорящие «чайники» в целевой аудитории, видимо) за полторы тысячи рублей и "Distributed Storage Networks: Architecture, Protocols and Management" — выглядит более надёжно, но 8200р при скидке 40%. Вместе с этой книгой Ozon рекомендует также книгу «Искусство кирпичной кладки».

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

Попробую восполнить пробел, которого не хватало мне — описать базу и описать просто. Рассматривать буду SAN на базе её классического протокола — Fibre Channel.