about NetApp

Я уже писал тут о 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 осенью этого года.

Сегодня очередной перевод одного из моих любимых авторов, инженера 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?’ »

Следящие за новостями 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/

Весьма любопытная попалась на глаза презентация о использовании систем хранения NetApp в CERN, для накопления, хранения и предоставления для работы с ними данных, поступающих с детекторов Большого Адронного Коллайдера (БАК, LHC).

Где-то до 15 страницы там идет все больше про адронный коллайдер, с данными котрого и работает система, и кратко о экспериментах, и генерируемых ими объемах данных, идущих на LRC (подробнее о том, что за эксперименты идут на LHC можно почитать на русском в заметке на Хабре) а дальше начинается уже и “наша” часть.

Вкратце: на 2010 год один только Large Hadron Collider (LHC, БАК) генерировал в ходе идущих на нем четырех параллельных экспериментов около 15 петабайт “сырых” данных в год, при сумммарной емкости хранилища свыше 50 петабайт, которые обрабатываются примерно 150 тысячами процессорных ядер в научных учреждениях по всему миру (проект GRID).

Это 2010 год, еще до всех cluster-mode, все довольно просто (если к такой работе можно вообще применять такое слово), и упомянутый в заголовке scalability и performance достигается простым 7-mode и Oracle RAC (10.2.0.5, позднее 11 в Oracle VM), Flash Cache и 10G Ethernet на midrange-class системах.

С 2006 года в CERN эксплуатируют системы хранения NetApp, Oracle на Linux_x64, в конфигурации RAC по NFS, и на момент создания презентации СУБД обслуживала 96 баз.

Так, например, база ACCLOG получала, на момент публикации презентации, примерно 3,5TB записей в месяц (или около 100GB в день), причем после запуска LHC объем входящих записываемых в базу данных вырос примерно вчетверо.

Любопытно, что все это обслуживают сравнительно маломощные стораджи FAS3040 и FAS3140 с дисками SATA 2TB и FC 10Krpm

Наиболее важными для CERN особенностями систем хранения NetApp в презентации называются:

• Хорошая поддержка и удобное администрирование систем.
• Высокий уровень масштабируемости и производительности, стабильности и беспроблемности кластерного файловера, а также непрерывающего работу обновления ПО контроллеров.
• Высокая надежность хранения и поддержания целостности данных (RAID-DP, scrubbing, checksum)
• Удобные и практичные фичи, такие, как snapshots.

Посмотреть PDF презентации можно тут:
http://openlab.web.cern.ch/sites/openlab.web.cern.ch/files/presentations/2010OOW-08.pdf

Любопытная статья обнаружилась в блоге Wahl Network, который я тут уже упоминал в связи с переводами из него про LACP и агрегирование каналов Ethernet/NFS в VMware.
В очередной статье автор показывает, какие странные проблемы бывают порой у бюджетных стораджей. Он собрал для своей домашней лабы сторадж на базе Synology DS411, с 4 дисками SSD в качестве хранилки, и получил, подключившись к ней по iSCSI, чудовищно плохие (и странные) результаты при записи (да и вообще, в целом на iSCSI плохие). При том, что при работе по NFS этой же проблемы нет.
Налицо явная проблема на уровне фирмвари контроллера. ?? кто знает, сколько таких “волчьих ям” поджидает юзеров “домашних NAS”, при попытке использовании их в жестких условиях энтерпрайза.

На днях NetApp опубликовала результаты одного из тестов, которые она проводит для своих стораджей, это так называемый Exchange Solution Review Program, спецификацию которого опубликовала Microsoft. Это небольшой, но довольно популярный у многих вендоров “прикладной” тест-бенчмарк, позволяющий продемонстрировать работу стораджей для использования под хранилище MS Exchange.
Текущая версия использует MS Exchange 2010.

NetApp тестировала по данной программе различные системы, в основном “малого класса”.
Недавний тест продемонстрировал возможности системы FAS2220 для инфраструктуры начального уровня (”начального” это по американским меркам, 1000 mailboxes, размером по 2GB, такие вот там “малые предприятия”).

Подробный отчет о тестировании можно посмотреть здесь:
http://media.netapp.com/documents/netapp-fas2220-mailbox-resiliency-storage-solution.pdf

В июле-августе случится редкая возможость посмотреть на автора этого блога живьем, так сказать live ;). Произойдет это в Москве, куда я приеду на небольшой срок по личным делам, а потом, вскоре, уеду вновь (те, кто заглялывал в about знают, что я живу и работаю не в России, удаленно). Если у вас есть какие-либо идеи на эту встречу (например: попить хорошего пива в приличном месте, узнать “как оно вообще”, поговорить за жизнь, и/или не только “про нетаппы”, выяснить, как живется “на чужбине”, сколько я зарабатываю на блоге ;), и как бы такое тоже смутить, например), то пишите в комменты.

??ногда просто жаль, что я так волюнтаристски ограничил тематику блога только системами FAS, потому что сейчас очень интересные дела творятся в сегменте их новых E-series. NetApp E-series это, если кто пропустил, бывшие LSI Engenio, который были некоторое время назад куплены NetApp-ом, и активно развиваются уже под его крылом. В компании это отдельный продукт и отдельная группа разработчиков, которые делают на его базе специализированные решения под сегмент Big Data, HPC, Full Motion Video, LustreFS, Hadoop, и прочее такое же, на базе высокопроизводительного и высокоемкого блочного стораджа, первоначально разработанного в Engenio. На российский рынок NetApp свои E-series не поставляет (однако вы можете купить их проданные как OEM через каналы IBM, например. DS35xx и DS37xx это как раз они, стораджи бывшего Engenio, ныне NetApp).

Но невозможно объять необъятное, и так как я не занимаюсь областью E-series, и спецфическими задачами, для которых они предназначены, я новости о них чаще всего обхожу. Но бывают среди них весьма впечатляющие.

Так, например, в сентябре 2011 было объявлено, что систему хранения E-series выбрали для хранения данных в Lowrence Livermore National Laboratory для работы с наболее производительным в мире на сегодня суперкомпьютером. LLNL это научное учреждение, подчиняющееся U.S. Department of Energy и National Nuclear Security Administration, и занимающееся атомной энергией (нет, не только “бомбой”, хотя работы по математическому моделированию процессов атомных взрывов это, несомненно, значительная часть их задач).

Поставленная дисковая система для суперкомпьютера IBM Sequoia имеет емкость 55PB (петабайт), работает под LustreFS, и обеспечивает пропускную способность передачи данных на уровне 1,3TB/s.

Подробнее о том, как это было сделано – в посте блога Recovery Monkey:

http://recoverymonkey.org/2012/02/10/netapp-delivers-1tbs-performance-to-giant-supercomputer-for-big-data/

Любопытный пост с фотографиями про распаковку и разборку-сборку FAS2240-4 найден тут: http://jnet.kz/company/hoster/blog/2517.html

К сожалению, фотографий нетапповской техники всегда не хватает, и уж тем более всегда интересна новая техника, и “клиентские” впечатления.