Производительность в 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, базы, настроек оборудования. Для затравки вам картинка, остальное по ссылке на полный отчет с описанием методики тестирования.
Как вы видите, согласно этому тесту производительность Cluster-mode ниже аналогичной системы 7-mode не более чем на 7% в наихудшем случае, при, безусловно, значительно большем количестве возможностей, “фич” и перспективах масштабирования решения Cluster-mode.
Я правильно понимаю, что и в 7-mode и в cluster-mode использовалось по два контроллера?
Т.е. в первом случае два контроллера собирались в HA-пару, а во втором в cluster-mode конфигурацию?
Алексей:
Да, конечно. Полная конфигурация описана в документе.
Вы забыли описать такой важный недостаток Cluster-mode, как невозможность построения катастрофоустойчивых конфигураций.
Аналог MetroCluster еще не реализован в Cluster-mode, а для многих это принципиально.
На мой взгляд, так агресивно продвигать новую технологию без реализации в ней ВСЕЙ функциональности старой технологии, все же не стоит.
Виталий Филатов:
Нет, я не забыл.
Дело в том, что катастрофоустойчивость это довольно сложный и многосторонний аспект (аппаратная его составляющая, кстати сказать, не только не самая главная, но даже не самая важная, но это отдельный разговор). Metrocluster это, безусловно, отличное решение само по себе. Но оно же и самое дорогое, и, во многих случаях, избыточное.
Переводя на любимые в этом блоге автомобильные аналогии, это все равно что сказать на какой-то новый автомобиль: “Но у него же нет полного привода!” Ну нет, да. Полный привод отличная вещь, сама по себе, но стоит денег, и вообще-то также нужна не всем. Следует ли говорить, что автомобили без полного привода, лебедки самовытаскивания, блокировки межосевого дифференциала, и прочего фарша - “не нужны”, и обладание ими для автомобиля и его владельца - “принципиально”?
Надеюсь вы видите, что - нет.
По поводу “аггрессивности продвижения новой технологии, без реализации в ней ВСЕЙ” - во-первых, я думаю, вы все же немного не то слово хотели использовать, да? В чем же вы видите “агрессивность”? Вас кто-то ударил?
Во-вторых - о Метрокластере. ??з нескольких десятков продаж систем NetApp, в которых я участвовал, хотя бы как-нибудь, продаж метрокластера было - две. Можно ли при таком проценте продаж говорить о “принципиальности” Метрокластера?
Мне кажется вы сильно переоцениваете его.
Еще раз, в заключение: Метрокластер это отличное решение, само по себе. Но само по себе оно не означает катастрофоустойчивости. Катастрофоустойчивость это гораздо более широкое понятие, и ее можно получить множеством способов, среди которых Метрокластер - лучший, но совсем не единственный, и даже не определяющий.
Про агрессивность продвижения, я возможно выразился не совсем корректно, но мое мнение состоит в том, что не стоит переводить разработку всех новых фич на Cluster-mode не реализовав всех возможностей доступных в 7-mode. По поводу не большой “принципиальности” Метрокластера, позвольте с вами не согласится. Решения на Cluster-mode сейчас активно продвигаются в верхний сегмент Enterprise, а там эта технология очень востребована. Крупные компании, выбрав СХД NetApp например для работы критически важной БД Oracle (с режимом работы 24×7), очень часто предусматривают катастрофоустойчивые решения. Возможно у нас в России продажи Метрокластера не очень развиты, но например для Германии доля рынка систем с Метрокластером составляет несколько десятков процентов от общего числа (точное число не помню, но достаточно много, слышал по моему от Увкина на одном из NetApp Innovation). Продолжая предложенные вами автомобильные аналогии… Если машину использовать в городе, то полный привод не нужен (иногда даже вреден, большой расход), но если требуются систематические поездки за город где существуют только направления, то наличие полного привода обязательно, а наличие фич типа лебедки и самоблокирующегося дифференциала очень желательно.
Виталий,
“Вам шашечки или ехать”? Есть задачи, где нужен Метрокластер, есть задачи где нужны фичи кластеред ОНТАП, а есть задачи где более интересно смотрятся E-Series. Вместо “one size fits all” сейчас “поливариативность решений”.
Пост Ромы был в том( ??МХО), что “не надо боятся”. Там где вам нужны фиги кластеред ОНТАП - это работает и скорости при этом вы получаете сопоставимые. Если при этом, у вас в требованиях есть rpo=0, то надо подумать, как можно реализовать на данном оборудовании. Возможно будет другое решение, другой производитель, а может и требование rpo=0 окажется не столь жестким :)
В своем первом посте я просто указал, что Роман перечислил не все недостатки решения на базе Cluster-mode, поэтому акцентировал внимание на том, что данное решение не предоставляет катастрофоустойчивых решений (как правильно говорилось выше “Есть задачи, где нужен Метрокластер, есть задачи где нужны фичи кластеред ОНТАП, а есть задачи где более интересно смотрятся E-Series”) и людям которым всетаки нужно это решение, неплохо бы знать об этом “временном” недостатке Cluster-mode. Я вообще считаю, что решение на Cluster-mode еще сыровато и использовать его ранее чем через год полтора, я бы не стал. Хотя как говорится “Хозяин Барин”, может некоторым нравиться работать со всем новым, а я предпочитаю только хорошо обкатанные технологии (я в продакшен не ставлю даже релиз кандидаты ОС, хотя NetApp и поддерживает их в том числе для промышленного использования).
Виталий, это был бы “недостаток”, если бы вам обещали Метрокластер на Cluster-mode, а он бы не работал, или бы работал плохо (хуже). А его просто нет. Ну нет, всегда есть чего-то чего нет. Разве можно говорить, что, дескать, у SAN-стораджей есть недостаток к том, что нельзя к одному LUN, без использования кластерной файловой системы на нем, подключить несколько хостов (а очень хочется), или что на чистом NAS нельзя использовать блочный доступ.
Я не вижу в том, что чего-то (вдобавок такого нишевого как Метрокластер) нет, какой-то настолько принципиальный “недостаток”, что этому стоит посвящать целый третий коммент.
Да там много чего нет. SnapLock например нет, и IPv6. Что же теперь, считать это “принципиальным недостатком решения”?
Ну да, для использующих SnapLock - вероятно, для остальных, его не использующих - пофиг на это.
А осуществимо ли технически на двух одноконтроллерных 2220 собрать cluster-mode? Может ли являться подобная конфигурация альтернативой двухконтроллерной системе с полкой?
panvartan - такой конструктив не является альтернативой нормальной HA-паре и более того работать не будет.
2 panvartan, Odna Ptichka
а как на счет впихнуть в корпус первой системы контролер из второй системы, а потом настроить СМ?