about NetApp

Выходные – день оффтопиков. Вот такая идиллическая картина получилась в пятницу. Причем там еще два шкафа IBM-овских серверов сбоку на этой кухне. Не хватает только HP и Hitachi. :)

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

Я уже писал тут о NetApp MetroCluster, решении построения распределенного отказоустойчивого хранилища данных с “нулевым RPO/RTO”.

Этот продукт уже довольно давно был сертифицирован на совместимость по программе VMware vMSC (vSphere Metro Storage Cluster), но только как NFS хранилище, и включен в такой конфигурации в VMwatre HCL. Однако недавно была завершена и сертификация решения под блочные (iSCSI и FC) протоколы, и сейчас NetApp MetroCluster – единственное среди систем хранения в листе vMSC стораджевое решение географически распределенного кластера, сертифицированное по программе vMSC под блочные (iSCSI, FCP) и файловые (NFS) протоколы вместе, как в stretched-версии (до 500 метров разноса узлов), так и в switched (до 100 километров между узлами).

Про NetApp Metrocluster теперь есть статья в VMware Knowledgebase: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2031038

Так что прошу любить и жаловать. Если вам нужно распределенное отказоустойчивое хранилище под задачи VMware vSphere, причем гарантированно поддерживаемое VMware, то обратите внимание на NetApp MetroCluster. Это недешевое решение, разумеется, но, в тех случаях, когда отказ и недоступность данных на хранилище недопустим абсолютно, это одно из наилучших решений в этой области, хорошо практически отработанное, существующее на рынке уже около 10 лет, и используемое в продакшне сотнями разнообразных клиентов NetApp в мире.

Для начала терминологическое вступление. Вокруг файлового протокола Microsoft довольно много путаницы, начнем с ее распутывания.

• SMB – “Server Message Block” – первоначальная версия протокола, разработанная еще во времена MS LAN manager 1.0(почти уже никто не застал те времена, и не помнит что это, совсем каменный век IT, середина 80-х). Некоторый отголосок этой аббревиатуры остался в названии опенсорсного продукта SAMBA, реализации файлового протокола SMB путем его реверс-инжиниринга.
• CIFS – (он же SMB-“просто” или SMB 1.0) – “Common Internet File System” – название CIFS появилось, когда Microsoft в 1996 году начала процесс стандартизации уже существовавшего протокола, в качестве RFC в IETF. Процесс стандартизации этот застопорился где-то на начальном этапе, и MS решила не продолжать его, остановившись на проведении в RFC первой версии драфта (сегодня его статус уже expired). Тем не менее название CIFS в индустрии закрепилось, и постепенно почти вытеснило SMB.
• SMB 2.0 – протокол, появившийся в Windows Server 2008, Vista, и поддерживающийся в более поздних OS. Microsoft осознала в какой-то момент, что файловый протокол, разработанный в середине 80-х, пусть и весьма совершенный на тот момент, и имеющий возможности постепенного расширения и добавления возможностей на уровне протокола, страшно отстал от современности (ситуация как примерно с Internet Explorer), страдает рядом существенных проблем, которые стали более заметны с годами. ?? вот в компании дошли руки до начала глубокой модернизации протокола SMB. Обратите внимание, что SMB 2.0 уже некорректно называть “CIFS”. CIFS это только SMB 1.0, поэтому постепенно название CIFS будет уходить. Я, в свою очередь, в этом блоге также буду постепенно избавляться от термина “CIFS”. Если мы говорим о новых версиях файлового протокола Microsoft, то мы будем называть его SMB (v2.0, v2.1, v2.2 AKA v3.0). В SMB 2.0 (и последующих его модификациях: 2.1, 2.2) были улучшены многие насущно важные аспекты, мешавшие SMB 1.0. Протокол был значительно упрощен, и, вместе с тем, улучшен. Появилась возможность кэширования и объединения нескольких команд в одну “цепочку”. Улучшилась работа по “длинным” сетям с большими уровнями задержек, что позволили использовать SMB 2.0 даже в географически распределенных локальных сетях, соединенных через WAN и VPN. Улучшилась реакция на кратковременные дисконнекты сети и масштабируемость.
  Но работы в группе разработки SMB не стояли на месте, и к выходу Server 2012 была готова новая, еще более глубоко переработанная версия:
• SMB 3.0 – это самая новая на сегодня версия файлового протокола Microsoft, с которым компания готова побороться с некоторым вынужденным засилием NFS в файловых системах хранения (NAS). В ее разработке MS буквально скакнула через несколько ступенек, и подготовила крайне интересный и современный продукт, с множеством новинок и хорошим заделом на будущее. Продолжая развитие SMB 2.0, в Microsoft еще более значительно улучшили производительность работы протокола, реализовали такие интересные вещи, как SMBDirect, с использованием RDMA Transport Protocol (Remote DMA, технология, используемая в высокоскоростых сетях, таких как 10G Ethernet и Infiniband) и поддержку многоканального режима, возможность использовать Remote VSS, BranchCache v2, Transparent Failover, шифрования. Немалую роль в популяризации и распространении SMB 3.0 должен сыграть и MS Hyper-V, впервые поддерживающий в его лице файловые протоколы для подключения стораджа.

Официально о поддержке, кроме самой Microsoft, уже заявили EMC и NetApp, два крупнейших игрока рынка NAS, а также поддержка SMB 3.0 появится и в открытом проекте SAMBA. Есть надежда, что к этим игрокам, после выхода Server 2012 подтянутся и остальные, уж больно много полезного появилось в новом SMB.

Так, например, SMB 3.0 явственно нацелился не только на традиционный для SMB 1.0/CIFS/SMB 2.0 сегмент канала связи от сервера до конечной клиентской машины, но и на межсерверный коннект (как бы ни звучало это дико и невообразимо для Old Skool: “Между серверами по бэкбону гонять данные? MS SQL? Exchange? По CIFS SMB? Да вы шутите!”). Для этого в нем появились средства SMBDirect и multichannel, позволяющие полноценно использовать производительные возможности вплоть до все еще невообразимого многими 40G Ethernet. Например можно объединить на уровне протокола (а не EtherChannel) в мультилинковый “транк” четыре 10G-линка. А использование RDMA (наиболее известным пользователем технологий RDMA является протокол Infiniband, славящийся своей низкой латентностью) и iWARP (я рассказывал о них в давней заметке в этом блоге) позволит даже выйти по уровню латентности и полосе пропускания для файлового протокола на уровень FC, при этом сохранив все преимущества файлового, а не тупого блочного протокола.

SMB 2.0 поддерживается в системах NetApp уже довольно давно, и требует просто включения соответствующей опции в конфигурации (> options cifs.smb2.enable on и > options cifs.smb2.client.enable on), так что если вы используете в своей сети клиентов не ниже Windows Vista/7, и сервера не ниже Server 2008, то есть смысл включить на сторадже эти опции и перейти целиком на версию протокола SMB 2.0, вы можете получить довольно заметный прирост в производительности.

Поддержка SMB 3.0 в NetApp появится в версии Data ONTAP 8.2, планируемой к выпуску в RC осенью этого года.

Чуть больше, чем через две недели, 3 октября 2012 года, состоится очередной ежегодный съезд, собираемый компанией NetApp в Москве. Для тех, кто уже ходил на Innovation в прошлые годы, понятно будет, что это за событие, для тех же, кто только подключился, поясню, что это наиболее крупное и важное событие для NetApp в России, будут “большие люди” из главного офиса, а также “прямой доступ к телу” сотрудников российского представительства.

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

Посмотреть программу, бесплатно зарегистрироваться, и все прочее, можно по ссылке:
http://www.netapp.com/ru/forms/ru-201210-innovation.html

Программа большая, я ее не буду сюда копировать в этот раз. Будет МНОГО рассказов о российских внедрениях.

??нтересно, что в этом году обещан, кроме типовых докладов и “фуршет”, hot seats, это когда докладчик быстро, в лимите времени отвечает на вопросы. Вся вторая половина после обеда – технические секции в два потока. Общее время проведения – полный день, с 9 до 19. Место – Lotte Hotel на Новинском бульваре.

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

Некоторое время назад попал на глаза любопытный текст, рассказывающий как можно организовать загрузку серверов с RedHat Server (в общем случае – любого Linux) с сервера NFS (в нашем случае, понятно, с NetApp FAS). В практике описавшего человека речь шла о загрузке большой кластерной вычислительной фермы, но, вероятно, такая возможность подойдет и во множестве других случаев.

По поводу бездисковой загрузки, как я заметил, существует также довольно много странных предубеждений и заблуждений. Например, считается, что только по FC, и только с помощью поддерживающих это HBA можно осуществить бездисковую загрузку сервера. Однако это не совсем так. Конечно, с помощью FC это сделать достаточно просто, и я даже писал на эту тему статью в блоге, с рядом типсов и триксов. Однако кроме загрузки по FC есть и другие варианты. Можно загрузиться по iSCSI, если у вас есть iSCSI HBA с BIOS и режимом загрузки в нем. Но даже и без HBA с BIOS это сделать можно, что и показывает рассматриваемый пример.

Сегодня практически любой современный сервер умеет делать загрузку netboot с помощью PXE – Pre-boot eXecution Environment. С его помощью мы сможем, в том числе, осуществить полноценную загрузку бездисковых серверов с NFS-сервера, без какого-либо FC, а дальше уже вольны использовать все возможности сервера Linux и системы хранения NetApp.

Преимущества такой загрузки, кроме очевидной экономии на локальных дисках:

• Развертывание новых серверов, особенно когда их счет идет на десятки или даже сотни, становится тривиальным.
• Отсутствие внутреннего жесткого диска делает проблему замены сервера, например в случае выхода из строя, предельно простой. Сервер с унифицированным “железом” грузится из загрузочного образа, в котором находятся все identities.
• Очень простой становится и процедура Disaster Recovery. Устанавливаем репликацию SnapMirror между двумя сайтами, в случае проблем на основном сайте переносите или устанавливаете новые сервера (или VM) на резервном сайте, правите MAC на TFTP boot server, чтобы не исправлять этот параметр в бут-образах, и сервера грузятся также, и с тем же содержимым, что и на старом сайте.
• Нет проблем с повреждениями локальной файловой системы. Никакх fsck. Для сервера его “файловая система” – WAFL на сторадже, отдаваемая по NFS, а WAFL крайне устойчива к повреждениям, так как это транзакционная файловая система.
• Можно использовать FlexClone. Тома ваших OS и загрузочные образы это идеально подходящий случай для использования FlexClone, экономия пространства будет великолепная, а эффективность работы, в том числе за счет повышения эффективности кэширования – очень высокая.
• Работа с централизованным, легко расширяемым  стораджем решает проблему исчерпания локального места на дисках серверов.

Конечно есть и ряд недостатков (решаемых):

• TFTP-сервер и DHCP становятся критичными ресурсами, и могут даже стать “точкой отказа”, если вы не позаботитесь о их резервировании. Например можно поднять tftp-server непосредственно на NetApp FAS (options tftp.enable on и установить том для .rootdir), а для возможности работать с несколькими dhcpd, на разных машинах, можно использовать опцию next-server в файле конфигурации dhcpd.conf на загружающемся сервере.
• Сетевые интерфейсы иногда могут иметь разные имена. ??з этой ситуации можно выйти, предусмотрев возможность переименовывать в скрипте имена udev, приводя их к единообразному виду. В приведенном документе показан способ этого решения.

Подробный документ how-to по загрузке сервера Linux с NFS-шары по TFTP, со всеми полезными настройками и скриптами можно взять здесь:

RHEL 6.2 NFS Boot installation.docx (63.4 K)

На прошедшем на прошлой неделе VMworld NetApp показал крайне интересную штуку – Data ONTAP Edge. Это виртуальный appliance, виртуальная машина, с установленной в ней OS Data ONTAP, работающей как “виртуальная система хранения” в среде VMware ESXi.

Наверняка вы уже знаете и пользуетесь симулятором Data ONTAP (а если не пользуетесь, то самое время пойти почитать про него подробнее). В двух словах: Data ONTAP Simulator это код Data ONTAP, выполняемый не на реальном железе стораджа, а в среде Linux (для Simulator 7.x) или виртуальной машины FreeBSD (Simulator 8.х). Симулятор позволяет создать “эмуляцию стораджа”, протестировать те или иные решения, отработать какие-то процедуры, настроить инфраструктуру, не трогая реальный физический сторадж, проводить обучение и всякие эксперименты. Не позволяет он только сделать на симуляторе реальную систему хранения, так как в код симулятора вшиты строгие ограничения на объем. Сделано это с понятной целью, не провоцировать пользователя на попытку сделать из такой виртуальной машины реальный “сторадж”, так как производительность такого решения не идет в сравнение с нормальным физическим стораджем на физическом железе. ??ли по крайней мере “не шла”.

Однако времена меняются, и некоторое время назад NetApp объявила о появлении у нее продукта Data ONTAP-v, который предоставляется не напрямую, а через партнеров (например Fujitsu в их blade-серверах для SMB), для создания virtual appliance, как раз того самого virtual storage. Data ONTAP-v это, если по-простому, симулятор со снятыми ограничениями. А  на VMworld был сделан новый шаг – объявлено о доступности для конечных пользователей нового решения – Data ONTAP Edge – virtual storage appliance для малых офисов и филиалов.

Data ONTAP Edge это, по сути, код Data ONTAP, практически такой, как он работает в реальном сторадже. Соответственно в таком апплайенсе вы получаете практически все то, что получаете в реальном железном сторадже, то есть универсальный (NAS+SAN) доступ, снэпшоты, thin provisioning, дедупликацию, FlexClone, SnapMirror и SnapVault. Однако, как и в эмуляторе, в Edge и ONTAP-v нет FC. Управлять Edge можно как и обычным нетапповским стораджем, с помощью System Manager, консоли, а также поддерживается Virtual Storage Console в  vCenter.

Цель Data ONTAP Edge – это филиалы и малые офисы. ?? прежде всего я вижу для таких организаций интерес в отношении Edge – это использовать его как SnapVault Primary. К сожалению, прекрасная и очень полезная для как раз малых компаний с филиалами и удаленными офисами идея с централизованным бэкапом через SnapVault разбивается о необходимость для использования всех плюсов SnapVault заводить второй (и более) железный нетапповский сторадж, так как SnapVault Primary, то есть “получатель” снэпшотов на хранение, может быть только нетаппом (SnapVault Secondary, “источник”, может быть даже обычный сервер, например при использовании OSSV, Open Systems SnapVault). Также интересным может быть организация репликации через SnapMirror.

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

Data ONTAP Edge можно скачать в виде 90-дневного триала, в формате OVA, с необходимым набором лицензий. Для установки его необходим, в отличие от симулятора, ряд строгих условий. Edge устанавливается только на ESXi (симулятор можно было установить на почти любой гипервизор), он требует много памяти и процессора (строго 2 выделенных vCPU и 4GB выделенной RAM, 57,5 GB места для самой системы), а также обязательно не ниже 4-ядерного или 2 двухядерных 64bit Intel x86 процессор, более 2,27GHz, четыре и более физических диска на Hardware battery-backed RAID, минимум одна Gigabit Ethernet карта, но в реальности, для современных серьезных продакшновых инфраструктур, эти требования вполне подъемны. Существует список поддерживаемых систем в качестве хоста. Рекомендую также посмотреть и на Data ONTAP Edge datasheet.

Для получения ссылки на скачивание триала вам будет нужен логин на support.netapp.com (бывший NOW), в том числе вы можете получить его и не будучи уже зарегистрированным клиентом NetApp, по “гостевому входу”. Лицензии на триал придут на адрес почты, зарегистрированной на логин.

Обсуждение и ответы на вопросы по Data ONTAP Edge можно получить в специальном разделе communities: https://communities.netapp.com/community/products_and_solutions/data-ontap-edge

Любопытно, что, по слухам, в начале своей истории NetApp серьезно рассмативала вариант выпустить Data ONTAP как софт, устанавливаемый на пользовательское “железо”, то есть не становиться еще одним “вендором железа”, а оставаться софтовой компанией. К сожалению, тогда, в первой половине 90-х состояние дел с надежностью доступного пользователям железа не позволило достичь приемлемого качества и производительности, и пришлось под Data ONTAP строить свою железную платфолрму. Сегодня, как видите, старинная идея переживает второе рождение.

В одном из предыдущих постов я начал описывать то, как, с помошью политик кэширования Flash Pool можно настроить индивидуально параметры кэширования для томов. Однако кроме кэширования чтения у Flash Pool появидлись средства и кэшировать запись. ??х немного, но они есть.

В настоящий момент имеется два варианта настройки кэширования записи (и один – и чтения и записи разом, который зачислен в “чтения”, и о котором я упомянул в предшествующем посте на эту тему):

• write-cache = none – тут нечего особенно рассказывать, это отключение кэширования записи, когда она включена в режиме кэширования во Flash Pool по умолчанию. Параметр этот может быть задан на каждый конкретный том, и использовать его стоит в тех случаях, когда кэширование записи не приносит пользы, например когда рабочая нагрузка не делает многочисленных и частых random-перезаписей данных тома (а напротив, записи идут секвентальные, большими блоками). С использованием такой опции данные пойдут непосредственно на HDD, собственно как они и записывались ранее, в обычных aggregates, без использования Flash Pool. В случае такого характера нагрузки данных тома, вы освободите место на кэше для тех, кому оно действительно необходимо.
• write-cache = random-write – эта опция, напротив, включает кэширование записей на aggregate для данного тома через flash. При этом данные сперва попадают в пространство SSD и кэшируются на нем. Такая политика должна хорошо работать для задач, когда данные, рандомно записываемые на том, часто перезаписываются, или перечитываются сразу после записи. Это значение политики записи по умолчанию.

Как я уже упоминал в предшествующей заметке, для управления настройкой кэширования томов на Flash Pool теперь используется новая команда priority, имеющая следующий синтаксис:

priority hybrid-cache set <volume name> read-cache=<value> write-сache=<value>

Сегодня очередной перевод одного из моих любимых авторов, инженера NetApp Dimitris Krekoukias, пишущего в блоге recoverymonkey.org. Текст крайне важный и заставляющий задуматься. Казалось бы, все мы знаем, что такое “IOPS”, но знаем ли мы это на самом деле, и не упускаем ли мы, говоря про IOPS-ы, нечто важное из виду? Насколько полнятие IOPS является однозначно идентифицируемым и можно ли показатели “в IOPS” трактовать однозначно, и сравнивать различные результаты, различных вендоров между собой?

IOPS: Возможно наиболее известный показатель производительности системы хранения.

IOPS означает Input/Output (operations) Per Second, "операций ввода-вывода в секунду". Смысл величины выглядит довольно очевидно. Он измеряет объем работы за определенный промежуток времени (и это не то же самое, что мегабайты в секунду, MB/s).

Кто из вас не видел вендоров, которые превозносят достоинства своих систем хранения, демонстрируя огромные величины IOPS ими достигнутые? Кто из вас не принимал решения покупки системы хранения, основываясь на обещаниях вендорами этих величин? Однако: как часто вендоры, приводя свои результаты, в действительности четко определяли то, что они понимали под аббревиатурой "IOPS", публикуя эти результаты?

Для нетерпеливых, скажу это с самого начала: Величина IOPS сама по себе бессмысленна, и именно так и должна рассматриваться. Без дополнительных метрик, таких как latency, процентное соотношение операций чтения и записи и размера блоков ввода-вывода, величина IOPS совершенно бесполезна.

А теперь подробнее…

Continue reading ‘Что такое IOPS?’ »

“Ну, граждане алкоголики, хулиганы и тунеядцы, кто желает поработать?” (с) Приключения Шурика

В знакомой хорошей московской компании, продающей NetApp (среди прочего) есть вакансия пресейла по этому вендору. Если у вас есть желание, читая мой блог, позаниматься продажами систем NetApp (например у вас все же не взорвалась голова после моего давешнего поста про Flash Pool;), и вы в Москве, или можете в Москву переехать, знаете что такое pre-sale, и чувствуете себя достаточно компетентным, то рекомендую попробовать.

Контактировать первоначально можно со мной,  на romx@mail.ru, дальше я вас перекину на компанLию, она сама не хочет ясно светиться в этом блоге, по ряду личных причин.

UPD: Эта запись уже появлялась в блоге, по ряду причин меня попросили ее пока придержать, на время собеседования с возникшим кандидатом. Сейчас она вновь актуальна, и снова опубликована.

Следящие за новостями IT в мире не могли пройти мимо нового баззворда, стремительно катящегося сейчас по англоязычным источникам - Big Data.

Согласно определению Википедии: “Big Data - это серия подходов, инструментов и методов обработки структурированных и неструктурированных данных огромных объёмов и значительного многообразия, для получения человеко-читаемых результатов, эффективных в условиях непрерывного прироста, распределения по многочисленным узлам вычислительной сети, альтернативных традиционным системам управления базами данных и решениями класса Business Intelligence. В данную серию включают средства массово-параллельной обработки неопределённо структурированных данных, прежде всего, решениями категории NoSQL, алгоритмами MapReduce, программными каркасами и библиотеками проекта Hadoop.” Сам же по себе термин “Big Data” (”Большие Данные”) родился в статье 2008 года в журнале Nature, и образован по аналогии с понятиями “Большая Нефть”, или “Большие Деньги”, символизирующие переход количества (объемов, скоростей обработки) данных в их некое новое качество.

Таким образом, в первую очередь, Big Data это то, что не помещается в базу данных, и методы работы с такими данными, когда нельзя “написать SQL-запрос” к ним.

В значительной степени, сложность работы с Big Data как раз и определяется сложностью нового подхода, для которого не получается применять эффективно привычные методы. Представьте, каково это, например, работать с несколькими миллионами или даже миллиардами файлов, искать в них, извлекать из них данные, записывать.
Сравнительно недавняя покупка компанией продуктовой линейки Engenio, и ряда программных продуктов стороних разработчиков, будучи слитой воедино, дала значительный толчок для работ в этом направлении. Так, NetApp активно занялся работами в области Hadoop, одного из открытых продуктов Apache Foundation (один из крупнейших клиентов NetApp - компания Yahoo! - как раз давний и активный пользователь и разработчик решений с Hadoop). ??звестны их работы в области высокопроизводительных решений с использованием Lustre (о использующей Lustre системе хранения для суперкомпьютера в Lowrence Livermore National Laboratory я уже писал ранее).

Другим продуктом, активно развиваемым в NetApp в области Big Data, является решение StorageGRID, объектное хранилище данных, позволяющее, используя высокий параллелизм, строить хранилища данных для миллионов и миллиардов файлов, с мультиплатформенным доступом, в сотни петабайтов объемом.
Недавно вышедшая версия StorageGRID 9.0 добавила к уже существующим возможностям доступа по NFS и CIFS и доступ по недавно описанному и стандартизированному в SNIA протоколу Cloud Data Management Interface (CDMI), который позволяет обращаться к объектному хранилищу с помощью HTTP-подобных запросов, создавать, администрировать и доступаться к данным облачного хранилища, с размерами, превышающими общепринятые сегодня.
Хотя на сегодня, уверен, большинству пользователей такие задачи, что решаются объектными стораджами и Big Data, все еще кажутся далеким будущим, многие вещи, казавшиеся далеким будущим еще три-пять лет назад, стали практически повседневностью сегодня, и готовиться вендорам к таким делам приходится заранее, чтобы не оказаться “на обочине” рынка.

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

В связи же с тем, что, по некоторым смутным слухам, NetApp раздумывает о том, чтобы поставлять решения на базе стораджей E-series, в первую очередь под Big Data, и на российский рынок, вполне возможно, что StorageGRID, CDMI, Hadoop и прочие решения найдут свое место и среди российских компаний.

http://dilbert.com/strips/comic/2012-07-29/