about NetApp

??зредка в этом блоге появляются частные объявления. Сегодня - как раз такой случай.
Друзья продают готовый сет, использовавшийся для построения private cloud в компании. ??спользовалась VMware vSphere Essential Plus, которая также имеется (железо специально подогнано под лицензионные требования 5.0 Essential Plus)

Полный состав лота:
Система хранения:
NetApp FAS2040A с Complete License Pack (то есть ?? все протоколы, ?? FlexClone, ?? SnapMirror, ?? неограниченные лицензии на SnapDrive и SnapManagers для всех платформ, в общем полный all incliusive всего, что у NetApp для этой платформы есть).
12x 1 TB SATA “в базе”.
Цена - 20000 USD
плюс к этому полка
DS4243 с 24 дисками SAS 300GB 15K

Цена - 10000 USD

Серверы Cisco UCS-series C250 (1U 19″ rack)
2 штуки:
CISCO C250 Rack Svr, 2x X5650,24×4 GB DDR3 1333 (96GB total), 2 PS, LSI308. без встроенных дисков, 2х + 4х Gigabit Ethernet ports.
Цена - 5000 USD (за каждый)
1 штука:
CISCO C250 M2 Rack Svr, 2x X5670, 24×4 GB DDR3 1333 (96GB total), 2 PS, HDD 2×1Tb, 2х + 4х Gigabit Ethernet ports.
Цена - 5500 USD

Серверы являются членами семейства UCS, управляются через UCS Manager, могут использовать все фичи UCS, такие как профили загрузки, централизованное управление, и так далее. Много памяти в базе, специально под работу хостами ESXi.

Сетевая фабрика:
2 штуки:
CISCO Catalyst 3560X 24 Port L3 switch
Цена - 1250 USD за каждый.

По фабрике бегает NFS по транкованным гигабитным портам, плюс iSCSI (не используется в текущем сете). FC не используется (в текущем решении), хотя все возможности по его использованию на стороне стораджа есть.

Все оборудование куплено “в белую”, “в белую” же и продается.
На оборудование имеется остаток вендорской warranty и саппорта. На Cisco (Smartnet) до декабря 2014, на NetApp - до июня 2015.

Сразу хотелось бы предупредить, что сет хотелось бы продать целиком, варианты с предложениями раздербанить, вида “А можно нам 8 дисков отсюда достать?” будут рассматриваться в последнюю очередь, также как и то, что объявленные цены действительны только при покупке сета целиком, и не гарантируются при дербанке на компоненты.
В настоящий момент сет работает под VMware vSphere, и может быть продан в настроенном и готовом к включению и продолжению работы состоянии.
??нсталляцию хозяйства проводил ваш покорный слуга, и за правильность ее и всех настроек отвечаю лично. :)

Этот сет был подробно описан в посте на Хабре: http://habrahabr.ru/company/netapp/blog/128301/
Единственное отличие от описанной там конфигурации - вместо Cisco Catalyst 3750X используются C3560X, без стекирования. ?? вместо Virtualisation Pack - Complete pack.

Несколько слов по близкой мне тематике стораджей. FAS2040 это, конечно, не FAS2240, он примерно в полтора-два раза слабее по мощности процессора, но все равно это очень и очень достойная машинка, а в текущей конфигурации - почти идеально подходит. У нее нет 10G Ethernet, но зато в базе по 2 порта FC 4G, и лично знаю людей, которые в свое время кусали локти, упустив последнюю распродажу в 2012 году последних 2040, и пришлось покупать существенно более дорогую FAS2240-4 с FC mezzanine.

Разумеется, вся эта кухня сопровождается бесплатным русскоязычным premium-саппортом от меня, в качестве IT-консалтера. :)

Цены - ориентировочные. Вопросы и предложения - в почту romx@mail.ru.

ЗЫ. Самовывоз из дефолтсити.

Надеюсь вы помните, что такое NetApp FlexPod. Это разработанный NetApp и Cisco, совместно валидированный “конструктор”, предлагаемый этими компаниями своим партнерам для использования в качестве базового инфраструктурного блока для IT-решений, например под системы виртуализации, баз данных, и прочих подобных задач.

NetApp FlexPod включает в себя систему хранения NetApp FAS3200 и серверную blade-ферму Cisco B-series, сетевое ядро построено с использованием коммутаторов Cisco Nexus 10Gb Ethernet.

NetApp и Cisco проделали большую работу по документированию решения и валидации дизайна, что позволяет, при необхдимости, построить такой FlexPod самостоятельно. В этом отличие FlexPod от других “конвергентных” продуктов на рынке – EMC vBlock и Oracle Exadata, которые продаются как законченные, зафиксированные, неизменные “ящики” от вендора.

В прошлом году был также представлен “FlexPod Lite”, под названием NetApp ExpressPod. Это та же идея, но построенная с использованием компонентов пониже классом, и ориентированная на тех, для кого FlexPod “больно жирно”, то есть NetApp FAS2200, сервера Cisco C-series, коммутаторы Cisco Nexus 3000.

Это решение также валидировано обоими компаниями, например под ферму виртуализации: ExpressPod Infrastructure Solution Implementation Guide
VMware vSphere on ExpressPod
http://media.netapp.com/documents/tr-4107-VMware-vSphere-ExpressPod.pdf

Но всегда было интересно посмотреть, какое же место занимает FlexPod на рынке, среди своих гораздо более именитых конкурентов? ?? вот на глаза мне попались такие результаты, взятые в отчетах Гарднера:

Причем, судя по тому, что это первая половина 2012 года, здесь еще нет ExpressPod,и, как я подозреваю, не учитываются пользовательские “самосборы” с использованием дизайна FlexPod, что, в принципе, не возбраняется и даже поощряется.

Если вы заинтересовались упомянутым ранее продуктом ExpressPod, это недавно появившаяся у NetApp “коробка”, готовый “продукт”, состоящий из стораджа FAS2240/2220 серверов Cisco UCS C-series (1-юнитовых 19”) и коммутаторов Cisco Nexus 3000 (48x 100/1000 Ethernet + 4x 10G, под NX-OS), ориентированный, прежде всего, на задачи построения “платформы виртуализации”, то в библиотеке NetApp появился новый документ:

ExpressPod Infrastructure Solution Implementation Guide
VMware vSphere on ExpressPod
Michael Zimmerman, David Klem, Chris Reno, and Michael Ansel, NetApp
October 2012 | TR-4107

http://media.netapp.com/documents/tr-4107-VMware-vSphere-ExpressPod.pdf

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

Фото с VMware World 2012 Europe

Это, как можно догадаться, вариант FlexPod, ориентированный на small/mid-size enterprise. NetApp утверждает, что FlexPod “classic” продается очень успешно, и за время его существования продано 1300 устройств (не считая возможных инсталляций, в которых FlexPod взять как дизайн, и собран “по частям”, по опубликованной спецификации, а не куплен “как продукт”), из них 400 только в Европе. Новая версия позволит воспользоваться достоинствами FlexPod и “коробочного решения” тем компаниям, которым “большая” версия была еще не по бюджету.

Как можно понять из фотографии, это FAS2240-2 или 2220 и сервера Cisco USC C-series, а также “сетевое ядро” с использованием коммутатора Cisco Nexus 3048.

Также любопытно, что validated design FlexPod был расширен, и теперь включает в себя такие интересные области, как использование с Oracle RAC в виртуализованной среде, а также для Private Cloud под VMware vSphere с NetApp в Cluster-mode.

Не вполне про NetApp, но раз уж приходится заниматься темой, по которой находятся интересные материалы, то было бы неправильно их не публиковать, тем более, что при нынешней стратегической дружбе Cisco и NetApp в проекте FlexPod, это и к NetApp некоторым боком относится, по крайней мере мне, в ходе “разбора” с FlexPod это все было крайне интересно.

В блоге инженера Cisco Брэда Хедлунда обнаружились несколько видеопрезентаций по основам организации сети в blade-системах Cisco UCS B. У автора они выложены на Youtube, а мне показалось более удобно смотреть их в оффлайне, поэтому я скачал их и сделал в виде файлов в формате mp4, позволяющих непосредствнно копировать и просматривать на iPod/iPhone/iPad.

Оригинальная статья здесь:
http://bradhedlund.com/2011/03/08/cisco-ucs-networking-videos-in-hd-updated-improved/

690Mb HD-видео в MP4 - тут:
http://www.divshare.com/folder/845459-b15

Cisco UCS Networking - Part 01 - The Physical Architecture of UCS.mp4
Cisco UCS Networking - Part 02 - Infrasctructure Virtualization.mp4
Cisco UCS Networking - Part 03 - Switching Modes of the Fabric Interconnect.mp4
Cisco UCS Networking - Part 04 - Upstream connectivity for SAN.mp4
Cisco UCS Networking - Part 05 - Appliance Ports and NAS direct attach.mp4
Cisco UCS Networking - Part 06a - Fabric Failover with Hyper-V and bare metal OS.mp4
Cisco UCS Networking - Part 06b - Fabric Failover with VMware.mp4
Cisco UCS Networking - Part 07a - End Host mode pinning.mp4
Cisco UCS Networking - Part 07b - Upstream LAN Connectivity.mp4
Cisco UCS Networking - Part 08 - Inter-Fabric Traffic and Recommemded LAN Topologies.mp4
Cisco UCS Networking - Part 09 - Disjointed L2 Domains.mp4
Cisco UCS Networking - Part 10 - Gen2 Adapters.mp4
Cisco UCS Networking - Part 11 - Cisco VIC (Palo) QoS.mp4
Cisco UCS Networking - Part 12 - SPAN, IPv6.mp4

MAC Load-Balancing
Этот алгоритм используется не так часто, так как ему присущ ряд недостатков. Основанный на использовании MAC алгоритм балансировки вычисляет XOR между MAC-адресами пар источника и получателя. ??сточником будет MAC-адрес сетевой карты хосте, подключенного к контроллеру  NetApp. Получателем будет MAC-адрес VIF-интерфейса контроллера NetApp. Алгоритм работает хорошо, когда хосты и контроллер NetApp размещаются в одной подсети или VLAN. Когда хост расположен в другой подсети относительно контроллера NetApp, мы сталкиваемся с недостатками алгоритма. Для понимания того, что происходит, нам надо разобраться с тем, что происходит с фреймом Ethernet, когда он маршрутизируется по сети.

Допустим, мы хотим соединить Host1 с Controller1.

Host1 IP address - 10.10.1.10/24 (default gateway для Host1 - 10.10.1.1)
Controller1 IP address - 10.10.3.100/24 (default gateway для Controller1 - 10.10.3.1)

Выше мы задали для Host1 и Controller1 две отдельные подсети. Единственный путь передачи данных в том случае - через роутер. В рассматриваемом случае, роутер для подсетей 10.10.1.1 и 10.10.3.1 это один и тот же физический роутер, эти адреса просто два физических его интерфейса. Задача роутера - связать две подсети, и обеспечить передачу данных между ними.

Когда Host1 передает frame предназначенный для Controller1, он отправляет его на роутер по адресу default gateway, так как видит, что адрес 10.10.3.100 это IP-адрес не его локальной подсети, потому он отправляет его в адрес default gateway, по которому расположен роутер, в надежде, что роутер знает что с ним делать дальше, и найдет путь к получателю.

с Host1 на Host1Router

-IP Source: Host1 (10.10.1.10)
-MAC Source: Host1
-IP Destination: VIFController1 (10.10.3.100)
-MAC Destination: Host1DefaultRouter

с Host1Router на Controller1

-IP Source: Host1 (10.10.1.10)
-MAC Source: Controller1DefaultRouter
-IP Destination: VIFController1 (10.10.3.100)
-MAC Destination: VIFController1

Обратите внимание: MAC-адреса источника и получателя меняются, когда фрейм передается по сети. Так работает маршрутизация, и когда маршрутизаторы встречаются на пути несколько раз, то и MAC будет изменен несколько раз по пути от источника к получателю. Не важно сколько раз конкретно, главное что он меняется когда фрейм попадает в локальный сегмент контроллера. MAC источника будет являться MAC-ом роутера, а получателем – MAC-адрес VIF контроллера. Для полного понимания проблемы, допустим у нас есть четыре 1Gbps канала, объединенных в Etherchannel на Controller1. Допустим у нас есть 50 хостов в той же подсети, что и  Host1. Пары source и destination для соединения Host1 к Controller1 будут ровно теми же, что и любых других хостов в подсети host1, так как  MAC-адреса source и destination всегда будут равны Controller1DefaultRouter и VIFController1.

IP Load-Balancing
IP Load-Balancing это параметр по умолчанию для всех NetApp MultiMode VIF и наиболее часто используемый на практике метод построения MultiMode VIF на сегодня. Алгоритм не отличается от уже рассмотренного алгоритма с использованием MAC, который мы расмотрели выше. Разница только в том, что мы используем IP-адреса ??сточника (Source) и Получателя (Destination), которые, если вы посмотрите рассмотренный ранее вариант, никогда не менятся, в отличие от  адресов MAC. Факт того, что IP-адреса не меняются, создает сценарий, в котором у вас больше шансов получить уникальные пары, что, в результате, приводит к более равномерному распределению трафика по физическим линкам.

Для правильного понимания механизма работы следует учесть один важный момент, касающийся пар IP-адресов source и destination: при вычислении пар source-destination принимаются во внимание только последние октеты адресов. Это означает, что в адресе 10.10.1.10 будет использован для идентификации только 10 – последний октет адреса, в адресе 10.10.3.100 - только 100. Принимать во внимание этот момент следует в случае развертывания системы в сети, состоящей из нескольких подсетей, в этом случае может получиться так, что адреса из разных подсетей (но с одинаковым последним октетом) будут передаваться по одному физическому линку.

IP Aliasing
Понимание принципов алгоритмов Load-Balancing позволяет вам, как администратору, использовать их к собственной выгоде. Все NetApp VIF и физичские интерфейсы имеют возможность назначить им так называемые “алиасы”. Это просто дополнительный адрес для самого VIF. Рекомендуется назначит адреса(для VIF + определенное количество алиасов) равное числу физических линков в EtherChannel между контроллером и коммутатором, к которому подключен контроллер. Таким образом если вы используете VIF, состоящий из  4 штук 1Gbps линков в виде MultiMode VIF между контроллером и коммутатором, то назначьте один адрес для VIF и добавьте к нему три алиаса для того же VIF.

Простое назначение дополнительных адресов не поможет использовать преимущества дополнительных адресов. Вы должны убедиться, что хосты, которые смонтировали данные с контроллеров NetApp используют все эти адреса. Этого можно достичь несколькими разными путями, в зависимости от того, какие протоколы используются для доступа к данным, ниже приведены некоторые примеры для NFS.

Oracle NFS -  хосты с Oracle должны монтировать тома NFS равномерно распределяя их по доступным  IP-адресам контроллера. Если у вас есть 4 различных NFS ресурса, то смонтируйте их используя для доступа четыре различных IP-адреса контроллера. Каждый ресурс будет иметь различную пару из источника и получателя (source and destination pair) и полоса передачи между хостом и контроллером будет использована более эффективно.

VMware NFS – хосты ESX должны монтировать каждый NFS Datastore через различные IP-адреса контроллера NetApp. Такой вариант наилучшим способом использует один интерфейс VMkernel (адрес источника (source)). Если у вас больше датасторов, чем  IP-адресов, то просто распределите датасторы по доступным IP-адресам контроллера NetApp поравномернее.

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

Ну и, наконец, обещанные шаблоны:

Continue reading ‘Multimode VIF в NetApp (часть 2)’ »

NetApp и Cisco давно связывают многие и просто хорошие отношения, и бизнес-инициативы. Недавно был опубликован очередной отчет в success stories.

http://media.netapp.com/documents/cisco.pdf

Cisco перевела свыше петабайта своих стораджей под БД Oracle на 4 штуки NetApp FAS6070C по FC и NFS, и за 8 месяцев сэкономила в терминах TCO около 8 миллионов долларов на электропитании и стоимости хранения, и в ближайшее время ожидается еще около 10 миллионов экономии при развертывани новых баз.

67 инстансов (backend Oracle 9.2, 10.2 и frontend 11i), размером некоторых до 30TB, на 22 серверах HP-UX, с применением thin provisioning и дедупликации удалось сократить в объемах storage footprint на 67 процентов.

Наверняка многие слышали за последний год-два о новом направлении развития протокола FC, по замыслу Cisco (и, отчасти Brocade) его транспортом станет “нативный” Ethernet, что неудивительно при таком успехе стремительно дешевеюшего 10G Ethernet. По видимому на сегодня будущее FC в конвергенции транспорта из собственного проперитарного в широкодоступный Ethernet.

?? вот, NetApp снова на острие. По сообщению SearchStorage
14 октября объявлено о нативной поддержке FCoE в системах хранения NetApp моделей FAS и V.

Ожидается, что доступные к концу года native FCoE target cards, устанавливаемые в систему хранения, будут стоить сравнимо с нынешними 8GB FC.

??нтерес к этой технологии у NetApp не случаен, компания давно и прочно удерживает лидерство среди стремительно набирающих популярность систем хранения протокола iSCSI или (IP-SAN), конвергирующего SAN в транспорт IP обычно over того же Gigabit и 10G Ethernet. Теперь сюда логично прибавится FCoE.

Напомню, что в отличие от iSCSI, использующего транспортные возможности протокола IP, FCoE транспортируется не поверх IP, а уровнем ниже, непосредственно на “канальном” (в терминах ISO/OSI) уровне Ethernet. Это позволяет преодолеть ряд недостатков, присущих iSCSI, передающегося на “сетевом” уровне, инкапсулированного в IP-пакеты, однако получающего свои недостатки, характерные для работы на таком уровне.

Думаю подробный разбор FCoE как такового я напишу чуть позже, тогда станет понятнее место и назначение этого “новичка” в команде протоколов, поддерживаемых NetApp.