Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method GoogleSitemapGeneratorLoader::Enable() should not be called statically in /home/sync4me/domains/aboutnetapp.ru/public_html/blog/wp-includes/plugin.php on line 311
Cluster-mode | about NetApp

Posts tagged ‘cluster-mode’

Четыре порта 10G в Cluster Interconnect

После выхода FAS8000 и Data ONTAP 8.2.1, обновилась рекомендация NetApp по использованию и числу портов 10G Ethernet, задействованных в кластерном интерконнекте, закрытой внутренней сети обмена данными между контроллерами, входящими в один кластер (тот, что именно кластер, в терминах clustered Data ONTAP, или, по старому, C-mode).
Если раньше для подключения в Interconnect использовались два порта 10G на каждом контроллере (каждый - в свой коммутатор, конечно, для надежности и отказоустойчивости, то новая рекомендация - использовать для старших систем по два таких порта, итого - четыре на контроллер. Так как onboard портов у FAS8040/8060 как раз четыре на контроллер, то эта рекомендация не будет создавать особенных сложностей.

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

Трафик интерконнекта состоит, в первую очередь, из трафика между LIF, то есть логического интерфейса SVM, Stotage Virtual Machine (или, по старому, VServer), и ее данными, которые могут оказаться, например в результате миграции SVM, на дисках, обслуживаемых другими контролерами. В этом случае трафик, входя через физические порты, привязанные к LIF с одного контроллера, достигнет своих данных, расположенных на дисках другого контроллера, пройдя через кластерный интерконнект (в терминах NetApp это называется remote workload).
А так как увеличившаяся мощность контроллера и объем NVRAM существенно лучше обрабатывают ряд “трудных” для контроллеров NetApp нагрузок, например linear-типа, способных нагрузить интерконнект трафиком, возникла необходимость рекомендовать решение, снимающее это потенциальное узкое место.

Конечно, если вы используете 7-mode и младшие модели, то вас это все пока не очень касается, но если вы строите по настоящему мощную систему, то советую заранее присмотреться к этой рекомендации. Кстати, следует отметить, что сама процедура добавления дополнительных портов в интерконнект сравнительно проста, доступна для уже построенной системы, и никаких значительных перенастроек в ней не требуется, все внутренние компоненты Data ONTAP, использующие интерконнект, самостоятельно перебалансируются, обнаружив дополнительный интерфейс.

OnCommand Performance Manager 1.0

Я чуть раньше уже упоминал о выходе нового продукта в семействе OnCommand - OnCommand Performance Manager (OPM). Несколько слов про него подробнее.
Это - Virtual Appliance, то есть образ преконфигуренной виртуальной машины, запускаемой в среде VMware ESXi, на базе ядра Linux (2.6.32) и с веб-интерфейсом, и предназначен для анализа и слежения за производительностью кластерной (clustered Data ONTAP) системы хранения. Обратите внимание, системы 7-mode - не поддерживаются, только для Clustered ONTAP.

OPM следит и анализирует состояние производительности кластерной системы хранения, отображая ее состояние на веб-дашборде.

Анализируется и отслеживается несколько ключевых точек и компонентов системы.

На рисунке выше показана потенциальная проблема в data processing.
Тут же можно посмотреть отчет о соответствующем инциденте.

? посмотреть рекомендации по устранению.

В заключение следует отметить, что OnCommand Performance Manager бесплатен для клиентов NetApp, не требует покупки лицензий, и бесплатно доступен для загрузки из support.netapp.com.
Отметьте, что для многовендорных, больших инсталляций сходные задачи решаются другим продуктом, OnCommand Insight, который, будучи значительно более мощным и объемным, а также поддерживающим оборудование разных вендоров в составе IT-инфраструктуры, уже стоит существенных денег. Однако если ваши задачи ограничиваются анализом и контролем производительности одного кластера из контроллеров NetApp FAS, то этот продукт - прекрасный вариант решения.

UPD: В блоге Видада Коснока очень детальный Quick Install Guide, который поможет разобраться с установкой.

Как перенести данные с системы 7-mode на Cluster-mode?

В связи с тем, что, постепенно, Cluster-mode Data ONTAP, или как ее теперь правильно называть Clustered Data ONTAP, входит в жизнь, и все больше пользователей задумываются о ее использовании, возникает вопрос, как бы наиболее щадящим и простым способом перенести между двумя этими системами данные.
К сожалению, разница “в потрохах” между этими двумя OS, несмотря на схожесть названий, слишком велика, чтобы просто “запустить скрипт, и все сделается за час”. К сожалению пока нет реально работающего способа преобразовать уже имеющуюся 7-mode систему в C-mode. Поэтому, обычно, о Clustered ONTAP начинают думать в случае появления новой, “чистой” системы хранения, тем более, что сегодня есть возможность сделать Clustered Data ONTAP из всего пары контроллеров. Это интересно тем, что впоследствии вы уже сможете довольно свободно добавлять к этой паре контроллеров новые пары. Например старые (если они поддерживаются) контроллеры, работавшие в 7-mode, после завершения миграции данных с них, могут быть легко добавлены в такой кластер.

Довольно быстро в голову приходит идея использовать SnapMirror, штатную репликацию данных NetApp. Но поддерживает ли она репликацию между двумя “модами”? Да, поддерживает, хотя и с ограничениями. Наиболее существенным является невозможность перенести LUN-ы FCP или iSCSI. Увы, изменения в работе с метаданными LUN-ов в C-mode слишком значительны, чтобы это можно было просто реплицировать. В случае LUN-ов вы получите при попытке репликации сообщение в логах:

wafl.voltrans.lun.exists: Volume vmware_datastore1@vserver:a0cc5791-fd70-11e2-9f1f-123478563412 contains 7-Mode LUNs. It cannot be transitioned to Cluster-Mode.

В случае LUN-ов вам придется воспользоваться ручным переносом данных, либо через хост, либо через какой-то софт создания образа диска, хотя бы Norton Ghost или Acronis True Image.

Для разделов с файловыми данными, однако, можно все сделать собственными средствами SnapMirror.

Допустим, у нас есть две физических системы: 7-mode по имени NETAPP_7MODE (192.168.2.10) и Netapp Clustered ONTAP system по имени NETAPP_CMODE (192.168.1.10).

Создадим SnapMirror peer:
NETAPP_CMODE::> vserver peer transition create -local-vserver NETAPP_CMODE -src-filers-name NETAPP_7MODE

Transition peering created

Создадим том-получатель реплики данных:
NETAPP_CMODE::> volume create -volume vmware_datastore1 -aggregate aggr1 -size 100GB -type DP

[Job 16] Job succeeded: Successful

Создадим межкластерный интерфейс LIF:
NETAPP_CMODE::> network interface create -vserver NETAPP_CMODE -lif intcl_lif1 -role intercluster -home-node NETAPP_CMODE -home-port a0a-10 -address 192.168.1.10 -netmask 255.255.255.0

NETAPP_CMODE::> network routing-groups route create -vserver NETAPP_CMODE -routing-group i192.168.1.0/24 -destination 0.0.0.0/0 -gateway 192.168.1.1

Проверим, что связь есть:
NETAPP_CMODE::> network ping -lif intcl_lif1 -lif-owner NETAPP_CMODE -destination 192.168.2.10

192.168.2.10 is alive

Устанавливаем отношения репликации SnapMirror:
NETAPP_CMODE::> snapmirror create -source-path NETAPP_7MODE:vmware_datastore1 -destination-path NETAPP_CMODE:vmware_datastore1 -type TDP

Operation succeeded: snapmirror create the relationship with destination NETAPP_CMODE:vmware_datastore1

Проводим инициализацию репликации:
NETAPP_CMODE::> snapmirror initialize -destination-path NETAPP_CMODE:vmware_datastore1

Operation is queued: snapmirror initialize of destination NETAPP_CMODE:vmware_datastore1

Ждем завершения начальной полной передачи данных, проверяя статус:
NETAPP_CMODE::> snapmirror show

При необходимости обновляем данные на получателе, если они изменились на источнике:
NETAPP_CMODE::> snapmirror update -destination-path NETAPP_CMODE:vmware_datastore1

Отрезаем реплику от источника (quiesce):
NETAPP_CMODE::> snapmirror quiesce -destination-path NETAPP_CMODE:vmware_datastore1

При необходимость снова восстановить репликацию после отреза (quiesce):
NETAPP_CMODE::> snapmirror resume -destination-path NETAPP_CMODE:vmware_datastore1

Отрываем реплику (break):
NETAPP_CMODE::> snapmirror break -destination-path NETAPP_CMODE:vmware_datastore1

При необходимости повторять репликацию назначаем расписание:
NETAPP_CMODE::> job schedule cron create -name Every15mins -minute 15

NETAPP_CMODE::> snapmirror modify -destination-path NETAPP_CMODE:vmware_datastore1 -schedule Every15mins

После завершения репликации у вас на новой системе окажется копия данных системы с 7-mode, и их можно начинать использовать.

ВАЖНО: После репликации для тома-получателя будет автоматически выставлена опция fs_fixed_size, вы не сможете ее изменить командой vol options fs_fixed_size off, вместо этого воспользуйтесь командой: vol modify -vserver -volume -filesys-size-fixed false

Соответствие команд 7-mode и C-mode

Если вам в скором времени предстоит переход на Clustered Data ONTAP, или если вы админ системы хранения, хорошо знакомый с Data ONTAP 7-mode, которому предстоит администрировать Cluster-mode, то рекомендую посмотреть документ, недавно опубликованный в библиотеке NetApp:

Clustered Data ONTAP® 8.2
Command Map for 7-Mode Administrators

В нем в таблицу собраны команды Cluster-mode, соответствующие, по выполняемым действиям, командам 7-mode. То есть если вы знаете как, допустим, создать том на aggregate в 7-mode, и не знаете какой командой это делается в Clustered ONTAP, то вот этот документ вам поможет.

Брать можно здесь: https://library.netapp.com/ecm/ecm_download_file/ECMP1196780

VServers – теперь Storage Virtual Machines (SVM)

Одной из специфических особенностей “инженерного мЫшления”, исторически присущего компании NetApp, является зачастую весьма странные и вызванные какими-то глубинными процессами названия фич. Зачастую они закрепляются как официальные, видимо выйдя из недр программистских групп, а создаватели брендов и торговых марок из программтстов – те еще.

Вспомните хотя бы загадочный Fractional Reserve, над которым сломал голову не один человек, включая в свое время и меня самого (сегодня он в документации постепенно заменяется на гораздо более понятный LUN Overwrite Reserve). Оттуда же, допустим, vif, и прочие загадочные аббревиатуры, последние были некоторое время назад официально переименованы в куда более понятный ifgrp.

Дошел черед и до VServer, краеугольного понятия Clustered ONTAP. Даже за вычетом того, что нынче в начале термина “V” – значит Вендетта почти что зарегистрированная торговая марка VMware, сам по себе термин “VServer” – крайне неясен и несамоописывающ.

? вот, я с радостью отметил, что в новых материалах NetApp наметилось новое переименование – VServer теперь SVM – Storage Virtual Machines. Я давно, объясняя людям то, как работает Cluster-mode, делал это через аналогию с куда более знакомым и понятным кластером VM в VMware VSphere. Отрадно видеть, что теперь одним инженерным непонятным термином в лексиконе NetApp стало меньше.

Опять же, это торит интересную тропинку к новому баззворду индустрии – Software-defined Storage.

?зменения в схеме лицензирования Data ONTAP 8.2

Процесс постепенного перехода и перевода пользователей с good ol’ 7-mode на shiny new Cluster-mode своей неторопливостью и неспешностью порой мне напоминает ту сердобольную семейку, которая своему щенку фокстерьера хвостик отрезала по кусочку. К меня такое ощущение, что я уже всю жизнь с NetApp провел в процессе transition-а продуктов компании с 7-моде на Кластер. Ну да впрочем хватит бухтеть. :)

На носу у нас Data ONTAP 8.2, с новыми интересными возможностями, а пока на глаза мне попался документ, посвященный изменениям в лицензировании. Как вы заметили, NetApp экспериментиует с лицензированием уже довольно давно, что-то явно получается неплохо, взять хотя бы модель Data ONTAP Essentials.

Начиная с Data ONTAP 8.2 NetApp меняет лицензионные ключи и всю схему лицензий на 7-Mode и Cluster-mode.

Во-первых, вводятся новые, единые лицензионные ключи, единые для 7-Mode и Cluster-mode. Если вы интересовались темой, то знаете, что в Cluster-mode были отдельные ключи, и до 8.2 вам приходилось явно, на этапе покупки системы выбирать, какую систему вы покупаете, чтобы получить нужный набор. Теперь вводятся новые лицензионные ключи софтварных фич, длиной аж 28 символов, которые будут работать на обоих mode Data ONTAP, начиная с 8.2.

Во-вторых, лицензии будут привязаны к серийнику контроллера. Это неприятная новость, но рано или поздно это должно было произойти. На практике, для честного приобретателя, это означает, что теперь, при замене контроллера (head swap), вам также потребуется получит под его серийник новый набор ключей. Соответственно усложняется и удлиняется эта, ранее довольно простая, процедура.

Наконец, лицензи могут существовать “не-cluster-wide”, например часть узлов в кластере может иметь один набор лицензий, а часть – другой, оставаясь при этом единым кластером.* (см комментарий). Напомню, что “кластером” с прошлого года в этом блоге я называю всегда только группу HA-пар контроллеров, работающих в Cluster-mode (C-mode), а то что иногда раньше называлось “кластером”, а именно пара контроллеров под управлением “старой” 7-mode, теперь называется HA-парой (High Availability pair). На HA-пару лицензии по-прежнему единые.

Впрочем, более интересные новости грядут с самим выходом Data ONTAP 8.2, не переключайте ваши браузеры :)

Striped Volume – необходимые дополнения

Вчерашний пост про striped volume вызвал заметную реакцию. Не секрет, что ситуация с использованием концепции share nothing в NetApp FAS, и необходимостью разбивать диски между двумя контроллерами, это давний butthurt головная боль пользователей NetApp, особенно младших его систем. Да, действительно, когда дисков всего 12, допустим, то очень обидно отдавать половину на RAID и spare, по отдельности на каждый из пары контроллеров. Это не является существенной проблемой для людей, у которых дисков шкафы, сотни хостов, подключенных к системе, и так далее. В таких системах нет особенной необходимости для создания единого ресурса хранения, обычно в них LUN-ов и дисковых шар куда больше чем один. Но сомнение зудит. Все умеют, а нетапп не умеет, значит это проблема NetApp.

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

Во-первых, давайте разберемся, что в реальной жизни дает striped volume, какие недостатки имеет, и как те же самые задачи можно решить иным путем, то есть, как можно уже сейчас, без использования striped volume, достичь всего того, что он позволяет делать.

Striped Volume позволяет:

  1. Потенциально может помочь увеличить производительность дискового ресурса, особенно если он такой на системе один, и не может быть распределен своими частями между контроллерами естественным образом.
  2. Обеспечивает равномерную загрузку несущих его нодов.
  3. Позволяет делать cross-bound ресурсы, например очень большие файловые шары (для LUN это, как правило, не столь важно, так как они сами по себе ограничены, например 2TB в MBR-LUN, или же  64TB VMFS5.

Это так, как я уже упомянул выше, прежде всего в случае, когда такой ресурс (том, LUN, сетевая шара) ровно один. Однако в реальной жизни очень редко когда сторадж несет на себе ровно один LUN, датастор, файловую шару. Обычно, в моей практике, таких ресурсов десяток, и не один. ?, в общем, проблема “одного дискового ресурса” на мой взгляд довольно надумана. Вручную, на маленьких системах, или с помощью имеющихся средств, типа Data Motion и OnCommand Balance, для больших, это сравнительно несложно сделать.

Проблема Cross-bound ресурсов сложнее, но тоже, на мой взгляд, довольно “бумажная”. В свое время, во времена ONTAP GX, когда контроллеры были не чета нынешним, ограничения на объем хранения на одном контроллере дествительно иногда создавали проблемы, и требовали найти пути выхода. Сегодняшние контроллеры часто имеют лимиты по объемам, превышающий реально эксплуатируемые, и, что немаловажно, имеющий смысл эксплуатировать на данном контроллере. Я очень редко вижу ситуацию, когда владелец контроллера NetApp добивает его дисками “под крышку”, до его лимита по объемам. Это просто довольно таки недальновидно с точки зрения производительности системы в целом.

?так, какие же есть “подводные камни” для Striped Volume, и какие ограничения с ним связаны.

Во-первых, как мне уже тут указали “за кадром”, это в настоящий момент фича “положенная на холд”, она не развивается и скорее всего будет выпилена вовсе. Почему – ниже.

Во-вторых, striped volume есть объективное ограничение для самой идеи scaled-out архитектуры. например он требует, чтобы все контроллеры в кластере, по крайней мере в пределах striped volume) были однотипны (одинаковые контроллеры было требованием в GX, но это уже не так в Clustered ONTAP, и именно это направление, по моим наблюдениям, активно развивается компанией). Представьте себе, что striped volume оказался на двух узлах кластера: FAS6240 и FAS2240. Что будет с производительностью такого тома?

Соответственно использование striped volume естественным образом убивает возможность миграции тома между узлами кластера, крайне важной и нужной фичи Clustered ONTAP. Как результат, это делает невозможность миграцию такого тома в пределах кластера, например если вам нужно выполнить обслуживание или отключение одного из кластеров, содержащих striped volume. Соответственно это потенциально понижает общую availability кластерной системы в целом.

Наконец, люди, пользовавшиеся striped volume отмечали странное поведение и глюки, в особенности в области производительности, а так как, см. выше, эта фича явно идет в разрез с основным движением Clustered ONTAP в компании, то, вероятнее всего, эта фича будет вскоре просто убрана как таковая, и уж точно доделывать и вылавливать баги из нее не будут.

? последнее, задача сверхбольших томов в  настоящее время решается с помощью Infinite Volume, и не требует поддержки striped volume.

Таким образом, несмотря на то, что фича striped volume в Data ONTAP Cluster-mode и имеется, использовать ее в реальной жизни, иначе, как  если у вас абсолютносовершенноточноиникакиначе имеется такое требование для ее использования, объективно не стоит.

Striped Volume в Cluster-mode

Как вы уже знаете, архитектура системы хранения NetApp не позволяет, при наличии двух контроллеров, организовать один общий дисковый раздел, доступ к которому имели бы оба контроллера одновременно. Почему так было сделано, отчего, и что это дает полезного – об этом мы уже в блоге говорили, не будем отвлекаться. А сегодня я покажу, как это ограничение может быть снято при использовании Data ONTAP Cluster-mode, новой модели работы со стораджем, которая активно развивается компанией уже не первый год.

В Data ONTAP 8.x Cluster-mode вы можете использовать так называемый режим Striped Volume, при котором доступ к данным на томе может быть осуществлен параллельно с любых контроллеров кластера, в частности с двух контроллеров, составляющих HA-пару.

Для начала надо убедиться, что лицензия Striped Volume введена, что позволяет системе такой том создать.

f3240-sqltest::> license show
(system license show)
Feature Cluster SN Limit Description
————— ———– ——- ———–
Base 1-80-000011 666 Base License w/cluster size limit (nodes)
iSCSI 1-80-000011 666 iSCSI License
Striped_Volume 1-80-000011 666 Striped Volume License
FCP 1-80-000011 666 FCP License
4 entries were displayed.

Раз лицензия есть, то можно создать striped aggregate:

f3240-sqltest::> aggr create -aggregate myAggr -nodes f3240-sqltest-01,f3240-sqltest-02 -diskcount 16 -disktype SAS -raidtype raid_dp -maxraidsize 16
[Job 818] Job succeeded: DONE

Создан aggregate, распределенный (striped) на два узла кластерной системы - f3240-sqltest-01 и fas3240-sqltest-02.

Посмотреть, что получилось можно командой aggr show myAggr.

w680

Данный aggregate распределен на два узла, состоит из 16  дисков, 8 из которых на узле 01, и 8 – на узле 02. Создано также два плекса и две RAID-группы. Это означает, что такой striped aggregate состоит, по сути, из двух “обычных” aggregate. Обратите также, что Volume Style указан как striped.

Понятнее про состав striped aggregate станет после вывода команды aggr member show.

f3240-sqltest::> aggr member show
Aggregate     Size Available Used% State    #Vols Node             RAID Status
——— ——– ——— —– ——- —— —————- ————
myAggr_000 2.15TB    2.15TB    0% online       0 f3240-sqltest-01 raid_dp,normal
myAggr_001 2.15TB    2.15TB    0% online       0 f3240-sqltest-02 raid_dp,normal
2 entries were displayed.

Как видите, striped aggregate myAggr состоит из двух “мемберов”, myAggr_000 и myAggr_001, каждый на своем узле. Если бы мы создали такой aggregate на трех, четырех, и так далее узлах кластера – мы бы получили три, четыре, и так далее под-“аггрегейта”. Созданный же на таком aggregate, поверх него том (volume) и данные на нем, окажутся равномерно распределенными по доступу между несколькими узлами, и операции доступа к ним более или менее равномерно нагрузят все входящие в группу контроллеры.

FlashRay

Следует отметить, что новости про flash прошлой недели показывают, что для NetApp это не просто “ну еще один all-flash сторадж, раз у всех есть”, налицо стратегическая линия. Одновременно с EF540 был анонсирован продукт, который пока не выпущен, но о котором, что, в общем, необычно для NetApp, уже рассказывается: FlashRay.

Если вы уже начинаете запутываться в том, что где и для чего у NetApp на flash-рынке предназначено, то давайте посмотрим на схему:

На ней вы видите позиционирование всех на сегодняший момент flash-продуктов NetApp: Flash Cache находится в контроллере, Flash Pool -  во “встроенном” хранилище самого NetApp, его часть, Flash Accel – софтверное решение внутри хост-серверов, использующая их внутренние SSD. EF450 – это standalone-сторадж, никак, архитектурно, не связанный с FAS. А вот что будет в этой картине мира делать анонсированный FlashRay?

FlashRay – это компонент развивающейся силами Clustered ONTAP (Data ONTAP 8 Cluster-mode) архитектуры scale-out, или, если по-русски, “горизонтального масштабирования. Напомню, что такое “горизонтальное” и “вертикальное” масштабирование.

Если вы переросли ваш сторадж,  и меняете его на более мощный – это “вертикальное масштабирование”. Если вы увеличиваете мощность имеющегося стораджа, добавляя непосредственно в имеющуюся инфраструктуру новый контроллер и диски, которые не образуют новую, более мощную “сущность”, а расширяя емкость и производительность уже имеющейся системы – это “горизонтальное масштабирование”. В NetApp “горизонтальное”, или scale-out (в отличие от scale-up, “вертикального”) масштабирование – это Cluster-mode.

Хорошо знакомые с номенклатурой NetApp могут увидеть в FlashRay наследника NetApp SA, специальных кэширующих систем, нацеленных на ускорение работы NFS. Такие системы, представляющие собой контроллер соответствующей системы хранения и небольшой объем дисков, подключенных к нему для хранения закэшированных данных, устанавливаются на пути между клиентским приложением на хост-сервере, и собственно хранилищем данных, и ускоряют доступ к часто обращаемым данным, как, например, в рассмотренном выше по ссылке кейсе.

В отличие от NetApp SA, согласно анонсу, FlashRay это будут all-flash устройства, ускоряющие доступ к бэкэнд-стораджу FAS, он будет поддерживать кластерность, многопротокольность (а не только NFS), inline-компрессию и inline-дедупликацию данных с переменной длинной блока (неужели пригодились-таки разработки для VTL в этой области?), и ряд других, более обычных для NetApp опций, включая репликацию и автобалансировку нагрузки в кластере FlashRay.

Таким образом, если после анонса EF540 вам показалось, что NetApp начала отходить от своей парадигмы “во flash выгоднее кэшировать, чем хранить”, то анонс FlashRay показывает, что концепция жива, здорова, и передает всем пламенный привет с нового уровня своего развития. Ждем более подробных новостей с техническими деталями.

Производительность в Cluster-mode: опубликованы результаты

Мы уже весь этот год понемногу говорим о новой для пользователей NetApp “классической”, 7-mode архитектуры, схеме Cluster-mode. В отрасли все еще довлеет определенный груз недоверия, Cluster-mode считается, во-первых,  дорогим (но о цене и спецпредложении двухузловой cluster-mode по цене HA-пары 7-mode, и о “Cisco Nexus за 1$” мы уже говорили ранее), сложным в развертывании и установке (но рекомендую сделать поиск по Techlibrary по слову “cluster-mode”) и имеющим значительный оверхед по производительности, в сравнении с системой 7-mode. ? вот об этом последнем мы поговорим сегодня.

К моему глубокому сожалению некоторые такие предрассудки о производительности системы в Cluster-mode  разделяли и отдельные знакомые мне специалисты самого NetApp.

Поэтому так интересно было посмотреть на официально опубликованный отчет по измерению и сравнению производительности системы Cluster-mode и 7-mode.

Была протестирована производительность работы системы хранения FAS6240 под задачи четырехнодового Oracle RAC на OLTP нагрузке, под всеми поддерживаемыми протоколами, в конфигурации хранилища как 7-mode, так и Cluster-mode, в максимально идентичной конфигурации OS, базы, настроек оборудования. Для затравки вам картинка, остальное по ссылке на полный отчет с описанием методики тестирования.

image

Как вы видите, согласно этому тесту производительность Cluster-mode ниже аналогичной системы 7-mode не более чем на 7% в наихудшем случае, при, безусловно, значительно большем количестве возможностей, “фич” и перспективах масштабирования решения Cluster-mode.

20/0.124

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

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.