Этот год для компании станет «годом Cluster-mode», несмотря на то, что поддерживающая этот режим работы версия Data ONTAP, собственная внутренняя OS, которая работает во всех системах хранения NetApp, в версии 8.0 вышла еще в 2008 году, по настоящему ее возможности по созданию «многоузлового кластера хранения» начинают реализовываться только сейчас.
Но для начала немного истории.
О перспективах развития систем хранения в направлении «облачных» систем начали говорить уже несколько лет назад, хотя тогда еще не вошло в IT-лексикон это модное слово, и тогда говорили о GRID-системах, идущих на смену «классическим» сетевым системам хранения.
Нет ничего удивительного в том, что NetApp, как компания традиционно много внимания уделяющая перспективным направлениям в отрасли, занялась темой «облачных» кластерных систем одной из первых. И вот что из этого получилось.
Еще в 2003 году NetApp купила стартап Spinnaker, занимавшийся разработками в области кластерных файловых систем и средств Global Namespace, и несколько лет спустя выпустила на рынок специальную OS, под названием Data ONTAP Generation X (GX или v10). Это была специальная OS для некоторых систем NetApp, позволявшая строить многоузловые кластеры хранения данных. К сожалению, она имела множество ограничений, в частности, работала только как NFS-сервер, и не имела множества важных и привычных возможностей “классической” Data ONTAP 7.x, поэтому особой популярности не завоевала, была дорогой, ограниченной, требовавшей значительных специальных знаний для запуска и использования, и, в результате, ее использование было ограничено рынком высокопроизводительных файловых серверов для HPC (High-performance Computing) и систем хранения научной и аудио-видео информации. Общее число клиентов в мире, использовавших Data ONTAP GX, не превышало пары сотен.
Следующим шагом NetApp, стала попытка объединить, “слить” вместе две эти OS, «классическую» Data ONTAP 7, имеющую богатую функциональность, которую я подробно описывал в этом блоге, и работающую на десятках тысяч систем, и новую, «кластерную», «облачную». Однако объявленное в 2008 году “слияние” оказалось в значительной степени “фиктивным”, просто из одного дистрибутива OS, получившей название Data ONTAP 8.x стало возможным установить две OS: либо в режиме 7-mode, то есть “классической” Data ONTAP, либо в режиме, получившем название “Cluster-mode”, и явившемся развитием Data ONTAP 10. К сожалению это были, как я сказал выше, просто две OS, ставившихся из одного дистрибутива, и только. В Cluster-mode не появились привычные возможности Data ONTAP Classic, и по-прежнему это были две несовместимые OS, не имевшие возможности миграции данных или взаимодействия, полностью отличавшихся по структурам хранения данных и работе с ними.
Вследствие этого, имеющиеся пара сотен клиентов GX были переведены на 8.x Cluster-mode, а основная масса пользователей систем NetApp по прежнему продолжала пользоваться “7-mode”. Значительным барьером, кроме функциональных ограничений, была и цена решения, а также сложность инфраструктурной реализации, требующей дорогостоящих компонентов, таких, как внутренняя Cluster Network с использованием 10 Gigabit Ethernet.
Однако работы продолжались, и, постепенно, в 8.x Cluster-mode стали появляться все те привычные для 7-mode возможности, такие как репликация, блочная дедупликация, а также, что более всего важно, работа с блочными протоколами – FC, iSCSI и FCoE. Напомню, что, до версии 8.1, Cluster-mode была чисто “файловым хранилищем”, работающем по протоколам NFS и CIFS, что, увы, устраивало не всех.
Тем временем, как NetApp “переваривала” наследство Spinnaker, на рынке стали появляться конкуренты в данной области, так активно стал продаваться (и в итоге продался целиком EMC) продукт компании Isilon, а растущий интерес к “облачным” IT-системам естественным образом стал “локомотивом” развития и “облаков” хранения — многоузловых кластеров, своеобразных «облачных хранилищ», как нельзя лучше ложащихся в «облачную парадигму».
И вот, начиная с версии Data ONTAP 8.1 версия Cluster-mode стала уметь работать с блочными SAN-протоколами, стала уметь асинхронную репликацию и снэпшоты, привычные для Data ONTAP Classic, дедупликацию и компрессию, наконец, были снижены цены, и использование Cluster-mode стало несколько более доступным для пользователей.
Что же дает этот Cluster-mode, из того, что мы не имели до сих пор, и как он вообще работает?
Для того, чтобы дать ответ на этот вопрос, проще всего будет представить Data ONTAP в Cluster-mode как своеобразный «storage hypervisor». С тем как работает гипервизор системы серверной виртуализации, например VMware ESX, MS Hyper-V или Citrix XEN, вы уже примерно знакомы, я думаю. Data ONTAP в Cluster-mode работает очень похоже, только вместо виртуальных машин с приложениями под таким гипервизором будут создаваемые пользователем «виртуальные системы хранения» с данными, называемые Vserver, которые, также как и виртуальные машины под серверным гипервизором, могут не прерывая работы и доступа к ним мигрировать с одного физического контроллера в кластере на другой, в зависимости от их доступности или требований по быстродействию, или еще каких-то потребностей, которые вы зададите. Миграция может осуществляться в том числе и между различными платформами, также как в кластер серверного гипервизора мы можем включить различные (конечно, с рядом ограничений) по физической платформе хост-сервера и прозрачно для наших приложений перемещать их внутри с одного физического хоста на другой.
Таким образом, Data ONTAP Cluster-mode это «гипервизор» для системы хранения.
Рискуя раздуть статью множеством технических деталей, интересных только уже активным пользователям NetApp, расскажу еще немного подробностей.
Прежде всего, разбираясь с Cluster-mode, следует осознать разницу, между понятиями Global Filesystem и Global Namespace. Data ONTAP 8.1 Cluster-mode это Global Namespace, но НЕ Global Filesystem.
Global Namespace позволяет вам видеть кластер и его пространство, как совокупность нодов его составляющих, как единую “сущность”, целостное пространство, вне зависимости от того где и как хранятся ваши данные. Однако с точки зрения хранения, каждый нод-контроллер, по-прежнему оперирует данными, хранящимися на его aggregates и томах. Один единственный файл не может располагаться более чем на одном aggregate/ноде-контроллере. Также он не может мигрировать, распределяясь частью на одном, частью на другом ноде-контроллере.
Это, как мне кажется, очень важно понимать, поэтому на этом я так заостряюсь.
Безусловно, устройства, реализующие Global Filesystem, имеют в этом месте меньше ограничений (например EMC Isilon с его OneFS это как раз Global Filesystem), однако, в нашем мире, как вы помните, ничего не дается бесплатно, за все придется платить, и реализация Global Filesystem влечет за собой ряд весьма неприятных побочных негативных эффектов, в первую очередь для производительности. Isilon весьма хорош для определенного ряда задач, но он хорош, прежде всего, на определенных типах рабочей нагрузки (преимущественно последовательном доступе). Насколько в вашем конкретном случае важна возможность хранить огромного размера файл(ы), превосходящие по размерам суммарную емкость дисков, подключенных к одному контроллеру, и распределенные на несколько узлов кластера, и готовы ли вы за такую возможность заплатить ухудшением характеристик рандомного доступа к ним – решать вам. На сегодня на рынке имеется как тот, так и другой вариант.
Преимущество же в производительности довольно убедительно показал NetApp в недавнем тестировании SPECsfs2008 на протоколе NFS, где 24-нодовая система FAS6240 под управлением Data ONTAP 8.1, почти в полтора раза превзошла 140-нодовую систему EMC Isilon S200.
При этом, следует отметить, что, в случае NetApp, специально тестировался worst case, “наихудший случай” то есть только 1/24 часть всех операций шла на контроллер-owner, 23 из каждых 24 операций шли через “неродные” контроллеры, передаваясь через cluster network, и не использовались никакие существующие у NetApp средства оптимизации, такие как, например, Load Sharing Mirrors (RO-копии) на “неродных” узлах кластера, которые, безусловно, увеличат производительность «в реальной жизни».
Напомню, что тест SPECsfs2008 это классический и авторитетный тест, имитирующий усредненный типовой файловый доступ по протоколам NFS (и CIFS), сгенерированной смесью операций соответствующего протокола, и там, понятное дело, много операций с метаданными и, преимущественно, рандомный доступ.
Итак – Data ONTAP 8.1 Cluster-mode это Global Storage Namespace, но НЕ Global Storage Filesystem. Несмотря на то, что вы видите кластер как единую сущность, отдельный файл, на нем хранимый не может превышать емкость аггрегейта одного контроллера. Однако вы можете получать доступ к данным этого файла через любой из контроллеров кластера. В этом заключается разница между Global Filesystem и Global Namespace.
Второй момент, на котором мне хочется подробнее остановится, это то, как именно строится кластер физически.
Несмотря на то, что, формально, “единицей измерения” размера кластера является одна нода, представляющая собой один физический контроллер, ноды эти всегда включены в HA-пары. По этой причине количество нодов в кластере NetApp Data ONTAP 8.x Cluster-mode всегда четное. Таким образом обеспечивается надежность и высокая доступность (High Availability) ноды, тем же методом, как это делалось для контроллеров в 7.x.
Поэтому вы не можете сделать 5- или 15-нодовый кластер, а 4-, 6- или 16-нодовый можете.
В настоящий момент можно построить кластер, работающий как NAS-сервер (NFS или CIFS) из 24 узлов-контроллеров (nodes), то есть из 12 HA-пар контроллеров.
В версии Data ONTAP 8.1 появилась также поддержка блочных протоколов (iSCSI, FC, FCoE). Однако при использовании блочных протоколов (только их одних, или в комбинации с NAS) максимальный размер кластера на сегодня поддерживается в размере четырех нод, или двух HA-пар. Эта величина, как я думаю, будет расти, как только будет все отлажено и обеспечена надежность, все же 8.1 это первая версия с такой функциональностью, но пока – имейте это ввиду. Связано это, прежде всего, с тем, что файловые протоколы, такие как NFS или CIFS, по сути, полностью управляются и контролируются на стороне стораджа, и ему проще обеспечить все необходимые процедуры работы и синхронизацию процессов между узлами кластера.
Третий момент, который мне бы хотелось подробнее осветить, это то, что в настоящий момент NetApp предъявляет довольно строгие требования к оборудованию для реализации кластерных коммуникаций. Для построения Cluster network, то есть внутренней, межконтроллерной сети самого кластера, в настоящий момент поддерживаются только две модели 10-Gigabit коммутаторов, это Cisco Nexus 5010 (20 портов, кластер до 12/18 нодов) и Cisco Nexus 5020 (40 портов, кластер более 18 нодов), их продает NetApp со своими партномерами, в составе общей квотации такой системы, и на них устанавливается специально разработанный NetApp конфигурационный файл для этих коммутаторов. Причем использовать эти коммутаторы можно только под задачи внутренней кластерной сети, совмещать их с другими задачами, например для подключения в них клиентской сети – нельзя. Даже если там еще остались порты.
Однако тут есть и хорошая новость. Сейчас NetApp и Cisco, в качестве time-limited promotion, при заказе cluster-mode стораджа у NetApp, отдает необходимое для построения кластера инфраструктурное оборудование за символическую цену 1$ за Cisco Nexus для Cluster network и Cisco Catalyst 2960 для Cluster management network, плюс необходимые SFP и кабеля. При этом цена на систему Data ONTAP 8.1 Cluster-mode из двух нодов, для промоушна, уравнена с ценой аналогичной конфигурации 7-mode, а инфраструктурная часть придет по цене 5$, за пять девайсов (два Nexus 5010, два Catalyst 2960, сет кабелей), плюс сервисные платежи.
Прежде чем у вас как следуют загорятся глаза и затрясутся руки “купить Нексус 5010 за один бакс”, я бы хотел отдельной строкой уточнить, что это предложение действует только для покупки системы cluster-mode, и, по условиям покупки, не может использоваться ни для чего другого.
Купленную по промоушну систему на две ноды можно расширить до 12 нодов (6 HA-pair) докупая только SFP и кабеля.
Структура cluster-mode кластера такова (на рисунке, для примера, показана двухузловая система):
В качестве коммутаторов клиентской сети можно использовать любые коммутаторы, Ethernet или FC, в зависимости от потребностей пользователя.
В качестве коммутаторов Cluster network switch могут использоваться только Cisco Nexus 5010 (для кластеров с числом нод до 12/18) или 5020 (для большего числа нод).
В качестве Cluster Management Switch NetApp рекомендует Cisco Catalyst 2960, но, в настоящее время, не обязывает покупать именно эту модель, при необходимости использовать имеющуюся у клиента иную модель, это может быть оформлено через заведение PVR, специального запроса на проверку и аппрув конфигурации у NetApp. NB: SMARTnet для такого свитча – обязателен!
Cluster Network это выделенная только под эту задачу сеть 10Gb Ethernet. Единственное исключение – FAS2040, которая может использоваться в Cluster-mode с использованием Gigabit Ethernet, но не рекомендуется ее использование с другими контроллерами. Обратите внимание, что даже для 2040 и ее Gigabit Ethernet, другие коммутаторы, кроме Nexus 5010/5020, не поддерживаются!
Ноды кластера могут быть различными по модели. Вы можете объединить в единый кластер любые контроллеры, для которых объявлена совместимость с cluster-mode (с единственным исключением в виде FAS2040, использование которого с контроллерами другого типа не рекомендуется (хотя и возможно), по вышеописанной причине отсутствия портов 10G)
Вы также можете объединить в кластер и системы с дисками различных типов, например вы можете построить систему с дисками SAS, SATA и SSD в рамках одного единого кластера, и организовывать миграцию данных между разными контроллерами-нодами и дисками разных типов.
Таким образом, используя Data ONTAP Cluster-mode, которая, напомню, может работать на любых продаваемых сегодня контроллерах NetApp, вы создаете «виртуальные системы хранения», примерно таким же образом, как под гипервизором серверной виртуализации вы создаете «виртуальные серверы», которые независимы от аппаратной части хоста, могут произвольно и «на живую» мигрировать между физическими контроллерами по вашему или приложения требованию, вы можете на ходу увеличивать производительность кластера, масштабируя такой кластер, добавляя в него новые «хосты»-контроллеры, и делать многое, уже привычное для пользователей VMware vSphere, MS Hyper-V или Citrix Xen Server. Только для системы хранения.
Судя по той активности, с которой сейчас в NetApp публикуют у себя на сайте Best Practices для применения Cluster-mode для баз данных (включая Oracle и MS SQL Server), таких прикладных систем, как SAP, MS Sharepoint, и прочих «бизнес-тяжеловесов», спрос на такие решения сейчас весьма велик.
Думаю, что в этом году мы увидим внедрения систем с использованием Data ONTAP Cluster-mode и в России.
