NetApp Metrocluster



    В 2007 году, консалтинговое агентство Forrester провело опрос 250 IT-специалистов, с целью оценить риски аварий для IT, как внутри датацентра, так и вне его, например риски природных аварий и катастроф.

    После обработки и публикации результатов стало понятно, что привычное средство обеспечения отказоустойчивости в виде, например, традиционного «дублирующего, избыточного контроллера и RAID» может защитить всего от 31% всех возможных отказов.

    На графике вы видите также такие IT-дизастеры как отказы электропитания (" — что случилось с вашим электричеством? — Оно моргнуло." ), проблемы с ПО ("…и будет закрыто"), человеческие ошибки ("как ты сказал имя тома, который надо было размонтировать и грохнуть?"), ошибки сетевых настроек (" — а какой интерфейс использовать? — попробуй eth0."), а также и разнообразные природные (и не очень) катаклизмы, такие как пожары, наводнения и так далее.

    Таким образом становится ясно, что традиционные средства защиты работоспособности данных защищают его, увы, недостаточно, сколько бы «девяток» вам ни обещали в рекламе. И когда стоимость потери или простоя данных становится весьма существенной, встает вопрос поиска решения, обеспечивающего большую надежность, чем решения традиционные.


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

    Однако для начинающих знакомство с отказоустойчивыми решениями часто бывает сюрпризом то, что наличие репликации и удаленной копии ваших рабочих данных еще не означает настоящей отказоустойчивости.

    Данные-то у вас сохранены, но для того, чтобы этими данными воспользоваться зачастую нужны довольно обширные перенастройки. Надо разорвать репликацию с уже не работающего источника, перевести копию в онлайн, объяснить серверам, что данные теперь лежат не на этой системе (с такими-то IP и WWPN), а вот на той, с совсем другими адресами и свойствами.
    Нужно перепроверить все настройки, переписать их (не забыть и не перепутать), убедиться, что все запустится, и лишь после этого ваши сервера будут готовы к тому, чтобы запуститься с сохраненной реплики.

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

    Кроме того сам процесс переключения, зачастую, происходит неединообразно.
    Делается это где-то совсем вручную, где-то полуавтоматически, но, как правило, какого-то общего решения, не отдельно для каждого приложения, а для всей инфраструктуры в целом — нет.
    А ведь системой хранения на предприятии зачастую пользуются многие десятки различных приложений. И весь этот «переезд» надо проделать для каждого из них!
    Нет, не зря, ой не зря русский народ приравнивает два переезда к одному пожару.

    Так почему бы не возложить все эти задачи непосредственно на сам контроллер системы хранения? Почему бы не сделать систему хранения, которая бы переключалась на свою «реплику» просто и «прозрачно» для приложений?

    Вот из этой такой простой идеи и родился NetApp Metrocluster — программно-аппаратное решение распределенной кластерной системы хранения.

    Идея, легшая в основу Metrocluster, была, как часто у NetApp, простая и остроумная.
    К каждому контроллеру из пары, составляющей кластер (пока, к сожалению, контроллера может быть только два), на текущей площадке подключены два набора дисков. Один набор — его собственный, а второй — точная синхронная копия данных набора дисков «соседа». Кроме этого, так как современные диски FC имеют два равноправных «порта» доступа, каждый диск подключен одним портом к локальному, а вторым — к удаленному контроллеру, «крест накрест», каждый контроллер, таким образом, имеет доступ как к основному набору дисков, так и к копии, однако в конкретный момент времени, пока не случился cluster takeover, может работать только со «своим набором». Каждая запись, поступающая на контроллер, синхронно зеркалируется на «второй комплект» дисков у соседа.

    В случае же аварии или любого «нештатного события» контроллер, в дополнение к доступу к «своим» данным, получает доступ к данным партнера по кластеру, а также переносит на себя все его ресурсы, такие как IP-адреса его интерфейсов Ethernet, WWPN интерфейсов FC, имена LUN-ов и «сетевых шар», DNS-имена, и так далее, так что после переключения приложения продолжают работать «как и раньше», просто обслуживает их данные другой контроллер.

    Просто удивительно, почему никто из основных вендоров систем хранения не реализовал такую простую но эффективную модель (нечто очень похожее по идее, правда, сейчас пытается начать продавать EMC в своем продукте VPLEX).

    NetApp Metrocluster существует в двух вариантах. Это так называемый Stretched Metrocluster, в котором максимальное расстояние разноса его компонентов определяется допустимой длиной специального кабеля кластерного интерконнекта, не более 500 метров; и Switched Metrocluster, при котором длина ограничивается только предельной длиной канала Longhaul LW Fibre Channel, в настоящий момент — 100 км.
    (На картинке с сайта VMware показано использование Metrocluster для VMware vSphere FT, но на ее месте могут быть любые приложения)

    image

    Sretched Metrocluster работает точно также как более дорогой и сложный Switched Metrocluster, но может защитить, главным образом, от «локальных» аварий, например выносом «половинки» хранилища на другой этаж, в соседний модуль датацентра, или в соседнее здание в пределах 500 метров кабеля. Но даже такой, локальный вариант, поможет сохранить работоспособность при пожаре в датацентре, «выемке», локальном отказе электропитания, и так далее.

    Switched Merocluster предлагает уже полноценную распределенную систему хранения, которая может защитить и от ряда стихийных бедствий (например NetApp Metrocluster использует турецкое производство заводов Ford Motors, одно из основных промпредприятий которого расположено в сейсмически опасном районе).

    image

    Таким образом, вы можете сделать систему хранения, в которой одна половина будет находиться в Москве, а другая, например, в Зеленограде, причем работать обе половины будут синхронно, словно логически единая структура. Сервера московского датацентра будут работать с половинкой системы хранения на своей площадке, а сервера Мытищ или Долгопрудного — своей, но при этом, в случае сбоя (например отказа питания в датацентре, выхода из строя любой части системы хранения, выхода из строя дисков, контроллера, или же канала передачи данных меду датацентрами) данные останутся доступны.

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

    Для полной ясности давайте рассмотрим возможные сценарии сбоев.

    Самый простой вариант — отказ хоста.
    Приложение поднимается средствами серверной кластеризации на хосте 2, и продолжает работать, получая доступ к данным через «фабрику» исходного датацентра к хранилищу 1. (Синими линиями показывается путь доступа к данным)

    image

    Также обычная история — отказ контроллера системы хранения.
    Как и в ранее показанном случае — переключение доступа автоматическое.

    image

    Драма нарастает. Отказ половины хранилища целиком. Оператор или контролирующее ПО принимает решение о cluster takeover, которое осуществляется за несколько секунд одной командой cf takeover, и происходит прозрачно для приложений.

    image

    Катастрофа. Потерян целиком датацентр, вместе с хостами и половиной системы хранения. Доступ к данным сохранен. Второй контроллер кластера обслуживает «свои» данные как обычно, а данные партнера — с его копии на своем сайте.

    image

    Разрыв канала связи. Контроллеры кластера изолированы. Работа продолжается нормальным образом, при восстановлении связи произойдет ресинхронизация плексов. Для предотвращения ситуации split brain, если ваше ПО может такую ситуацию создать, возможно понадобится сайт-арбитр — «tiebreaker».

    image

    Конечно решение в целом получается непростое и недешевое (хотя и дешевле, чем аналоги). Два комплекта дисков для данных (этакий распределенный Network RAID-1), по одному на каждой площадке, выделенная внутренняя «фабрика» FC-коммутации, через которую осуществляется связь внутри «кластера хранения» и взаимная синхронная репликация данных между площадками, но в тех случаях, когда надо обеспечить работу не "в 31% случаев", а «всегда», когда стоимость простоя или повреждения данных высока, организации предпочитают не экономить.

    Впрочем, с выходом новых серий систем хранения FAS3200/6200, в которых набор лицензий для организации метрокластера уже включен в базовую поставку, сделан шаг к более массовому применению этого решения.
    NetApp 26,53
    Компания
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Похожие публикации
    Комментарии 59
    • +1
      Кстати, правда, как вы решаете проблему split brain?
      • 0
        Ну, как я уже упомянул, проблема split brain возникает только для тех приложений, которые пишут в общие данные. Если, допустим, данные не общие, то каждый «брэйн» будет писать в свои, а затем, после восстановления соединения между половинками кластера, данные между оригиналом и ее «отставшей» копией засинхронизируются автоматически.

        Проблеме split brain может быть подвержена такая система, как Oracle RAC, например, где записи делаются хоть и с арбитром, но в общую базу (в случае разделения половин кластера у нас окажется две несинхронные копии этой базы, обе при этом будут «частично актуальны»).

        Для решения проблемы split brain нужен сайт-арбитр, который по избыточному каналу сможет принять решение о том, «кто виноват и что делать».
        Сейчас есть два варианта решения. Для Oracle RAC есть так называемый Tiebreaker server, использующий Operations Manager (за деньги), это решение описано, например в «TR-3816 Providing Zero Downtime with Oracle RAC, EDC, ASM and Metrocluster», либо, по-моему даже бесплатно, плагином к ApplianceWatch.

        Operations Manager и ApplianceWatch это софтовые продукты NetApp для контроляи управления (netto знает ;), уточню для читающих комментарии).
        • 0
          Да про софт знаю, спасибо.

          А насколько вообще Metrocluster популярен в мире? Почему о нем так редко упоминают?
          • 0
            Ну не могу сказать что редко упоминают. Хотя согласен, что стоило бы чаще, вот, видите, рассказываю :)

            Вообще метрокластер, как я знаю, очень популярен в Германии (там вообще NetApp как-то экстремально популярен, он там даже обгоняет EMC по продажам!), например только за 2010 год, и только среди опубликованных компанией Customer Stories, куда, конечно, попадает совсем немного из общего количества внедрений, систем с метрокластером около 20!
            Причем очень разные по «профилю» компании. Там и промышленные предприятия (Porsche, DEMAG), страховые, издательская компания (Corelio), датацентр грузового порта в Копенгагене, даже интернетный фотосервис (ORWO).
      • 0
        Просто Германия маленькая страна и метрокластер со своими 100км укладывается в размеры страны, а у нас просто расстояния в России не те, вот и популярность низкая :)
        • 0
          Ну, как сказать «маленькая» :)

          Россия тут тоже не показательный пример, подавляющее число систем NetApp сегодня продается, увы, «в Москве и области».
          • 0
            Я вообще мечтаю сделать «облако» с метрокластером на V-Series (есть куча «тупых» FC полок), VMWare и QinQ между датацентрами…

            P.S. завтра, кстати, уже VMware Forum 2011 буду там… слушать… а когда свои мечты осуществлю, то буду расказывать :)))
            • 0
              Вот про V-series будет, надеюсь, в следующей статье.
              Впрочем вы то уже, раз нацелились, уже все знаете.
          • 0
            VmWare FT не самый лучший пример для показа работы MetroCluster. SiteRecoveryManager был бы понягляднее :) А так да, круто безусловно.
            • +1
              В данном случае мне просто лень было рисовать для статьи картинку топологии, и я украл их с сайта VMware:

              kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1001783

              :)
              • 0
                SRM теоретически не нужен если у нас метрокластер (т.е. данные УЖЕ доступны в DR датацентре и готовы к использованию без всяких миграционных процессов).
                А вот если у нас скажем простой snapmirror тогда да — SRM сильно упростит выполнения сценария DR.
              • 0
                Какой красивый огонь на картинке.
                • +2
                  Там, откуда я их тырил, он еще и анимированный :)
                  • +1
                    Отличные картинки, спасибо!
                • 0
                  У нас есть старенький метрокластер на fas 3020c.
                  Работает стабильно, но достаточно сложен был в сборке и первоначальной настройке.
                  До состояния split-brain довести пока не удавалось (надеюсь что и не удастся :-) ), а гибель сайта целиком тестировали неоднократно.
                  • 0
                    «одна половина будет находиться в Москве, а другая, например, в Зеленограде, причем работать обе половины будут синхронно»

                    Ой ли? Что за волшебная технология передачи данных? Что за среда передачи данных?
                    • 0
                      Репликация — чистый FC, кластерный интерконнект — FC-VI (Fibre Channel — Virtual Interface). Для межузлового соединения необходим dark fiber, то есть эксклюзивно используемое оптоволокно.
                      • 0
                        Тогда наверное правильно будет говорить об асинхроной репликации все-таки?
                        • 0
                          Нет, репликация синхронная.
                          • 0
                            Мммм… Задам вопрос по другому:
                            Какая максимальная дистанция Для выполнения описанной вами репликации?
                            И второй вопрос: что вы подразумеваете под синхронной репликацией?
                            • +1
                              Максимальная дистанция зависит от кабеля и его свойств, от допустимых для приложения задержек, от наличия соответствующих SFP на коммутаторе и лицензий. Но при наличии всего необходимого возможна установка синхронной репликации на расстоянии до 100 км, далее величины задержек уже становятся неприемлемыми для работы.

                              Синхронная репликация, это репликация данных на вторичный сторадж, которая осуществляется непосредственно в момент и в процессе записи данных на первичный сторадж.

                              Ну я же вам ниже привел ссылку на техдоку, посмотрите, там понятно.
                              • 0
                                Обычно синхронная репликация — это когда мы ждем подтверждения записи с удаленной точки. При указанных вами 100 км на каждую операцию чтения потребуется минимум 1 миллисекунда. А на запись — 2. Это без учета накладных расходов на обработку fc-фреймов. Количество буферов для fc мне уже лень считать, но оно будет огромным, и одним донор-портом тут явно не отделаться.
                                • 0
                                  Понятне чем в тексте по ссылке я вам точно не объясню. Там, кстати, есть все расчеты. Ну не заставляйте меня копировать оттуда сюда абзацы текста. :)
                                  • 0
                                    Ну чудо там вроде не описано. Честно скажу: читал по диагонали.
                                    Возьмем для примера приложение генерящее 1000 иопсов. Стандартное такое приложение. При этом длина кабеля пусть составит 100 метров. Для выполнения операции чтения 1000 нс. Записи — 2000 нс. Я учитываю только время на передачу сигнала. Без времени на обработку
                                    При 100 км, как я написал выше чтение 1 мс, запись — 2 мс. То есть 1000 иопсов мы уже не получим. А получим что-то около 1 (одного) иопса :)
                                    Нигде не ошибся?
                                    • 0
                                      Значит где-то ошиблись :)
                                      • 0
                                        Ошибся с чем? По версии инженеров NetApp сколько иопсов будет при таких вводных?
                                        • 0
                                          Вы чертовски логичны, за недостатком знаний даже не знаю что возразить. Но факт есть факт — оно работает и мне как админу без разницы что лежит там на низком уровне. Меня устраивает что задержки в приемлемых пределах и задача решается.
                                          Кстати, тот же EMC со своим SRDF/S и наверняка куча других вендоров делают то же самое.
                                          • 0
                                            Я не знаю что делают те или инные вендоры. Во всех документах связанных с синхронной репликацией озвучивается гораздо меньшие расстояния. До 10 км, кажется.
                                            Мне стало интересно, что я получу имея такое приложение. Вообще у меня запросы чуть меньше в 700 иопсов (30/70 чтение/запись) но кто знает что будет завтра.

                                            Идем дальше: конкретно к компании нетап у меня претензий нет, имеются претензии к подаче информации. IT менеджеры, прочитав такую простыню тут же загорятся покупкой, ок. Их дело, но когда эта хрень будет работать не так как говорят рекламные проспекты, потому что «есть нюанс». Это будет уже головняк технарей. Я сразу попытался выяснить этот нюанс, и судя по ответам представителя компании, где-то здесь и зарыта собака.
                                            Ситуация похожа на технологию fault tolerance от vmware. По проспектам все красиво, но почему-то я не встречал ее реального использования. А все потому что она не поддерживает smp и является асинхронной. Хотя к чести вмвари, они все эти «тонкости» никогда и не скрывали.
                                            • +1
                                              Прошло 5 лет, а ваш вопрос остался без ответа=) Обидно.
                                              Не знаю, актуально ли еще, но напишу:
                                              Вы ошиблись дважды. Если у вас задержка 1мс, то вы успеете 1000 IOPS получить, а не 1. Но это произойдет только в том случае, если у вас IOPS следуют друг за другом и каждый следующий ждет подтверждения предыдущего. Если бы приложения работали именно так, то какой бы огромный массив у вас не был, вы бы не получили никогда более 150IOPS, так как работал бы только один диск (на флеше получили бы побольше).
                                              Но, что прекрасно, приложения генерят несколько потоков данных, которые могут обрабатываться параллельно. То есть в канал сразу полетят, например, 50 потоков, с каждого можно выжать 1000IOPS, вот у вас и 50к IOPS получилось.

                                              Много раз видел перегруженные СХД, в которых при задержке 20-30мс было около 100к IOPS.

                                              Надеюсь, смог донести мысль.
                                            • 0
                                              И, кстати, фраза «админу без разницы что лежит на низком уровне», не прибавляет этому админу стоимости на рынке труда :)
                                              • 0
                                                И не отнимает если задача решается без «нюансов» :)
                                              • 0
                                                Бывает по разному. В больших компаниях алминистратор системы хранения, администратор сети, администратор базы данных и администратор SAN (и сотрудник техподдержки) это все разные люди.

                                                Ситуация, когда администратор системы хранения не знает, для чего используется «выше по иерархии» нарезанный и выданный им LUN довольно обычна, равно как и dba чаще всего не знает как организовано то, что он получил от storage admin.
                                                • 0
                                                  Не каждый дба скажет сколько ему нужно иопсов, так как не знает нагрузку генерируемую разработчиками.
                                            • 0
                                              Извините, вовремя не увидел ваш вопрос.

                                              Мне показалось что глава 3.2 и Appendix B в приведенном документе дает достаточно исходной информации, чтобы разобраться в вопросе.

                                              В целом, эта тема далеко выходит за рамки данной статьи, это уже пресейловая работа, и если у вас есть интерес (в смысле не чтобы «слоники побегали», а действительный интерес под какой-то проект), то давайте переместимся в почту с этим, комменты на хабре не лучшее и не самое удобное место для этого разговора.
                                              • 0
                                                Я выше написал почему меня интересует данный вопрос. Расчет кредитов не даст ответа на мой вопрос, так как это касается фабрики. Например, интересный факт: при 100 км в кабеле единовременно находятся 642 кб данных при 10gfc. :) Вот для этого нужны кредиты.

                                                Я уже понял ЦА этой статьи не технари. Если ко мне подойдет менеджер я выскажу ему свои опасения.
                                                • 0
                                                  Ну аудитория Хабра все же диктует определенную «популярность» и «доступность» изложения, неизбежная плата за широту охвата аудитории.

                                                  Вот тема загрузки линукса на игровой приставке Dingoo или тема копирайтов и Михалкова здесь встречает куда больший отклик, чем тема рассказа про Fibre Channel. :)
                                                  • 0
                                                    Хотя мы уже завершили дискуссию, но недавно мне попалась на глаза интересная статья про большую реализацию метрокластера на предельной дальности в весьма большом по масштабам проекте. Посмотрите, возможно найдете зацепку понять для себя, как это работает
                                                    www.netapp.com/us/communities/tech-ontap/tot-tsystems-case-study-0909.html
                                      • 0
                                        Кстати в указанной вами доке тип синхронизации для fabric metrocluster скромно опущен.
                                        • 0
                                          Не может такого быть.

                                          Но даже если это отчего-то и так (нет времени сейчас найти это непоседственно в тексте) — он синхронный, другого в метрокластере просто нет.
                                          Верьте мне. :)
                                          • 0
                                            Страница 5, глава 2.2

                                            2.2 OPERATION
                                            MetroCluster (either stretch or fabric) behaves in most ways just like an HA pair controller. All of the protection provided by core NetApp technology (RAID-DP®, Snapshot™ copies, automatic
                                            controller failover) also exists in a MetroCluster configuration (Figure 1). However, MetroCluster adds complete synchronous mirroring along with the ability to perform a complete site failover from a storage perspective with a single command

                                            стр 13. глава 2.10

                                            As a high-availability solution, MetroCluster is often compared with other synchronous replication products. Even though it includes SyncMirror, MetroCluster is differentiated by the following features:

                                            Вы невнимательны.
                                            • 0
                                              Нет, я просто не дочитал :)
                                • +2
                                  В деталях рассказывать будет много, но если любопытно, то можете попробовать самостоятельно прочитать:
                                  media.netapp.com/documents/tr-3548.pdf
                                • 0
                                  Мне честно говоря даже не хочется читать статью, которая начинается с такой серьёзной логической ошибки. Результат опроса IT специалистов конечно же косвенно связан с вероятностью происхождения того или иного сбоя, но никак не напрямую. Намного логичнее делать выводы о вероятности сбоя из статистики по реально произошедшим сбоям.
                                  Сумма процентов побольше 100% выходит. Любопытно.
                                  Опять таки эта статистика ничего не говорит об общей надёжности датацентров. Она может быть очень даже высокой, но вот если что-то и сломается, тогда уже эта статистика начинает работать.
                                  • 0
                                    Статья не претендует на абсолютно точную научную работу в области расчета рисков. Цель упоминания результатов данного отчета была исключительно в том, чтобы привлечь внимание к тому факту, что устойчивости к аппаратным сбоям и отказам самой системы хранения еще не достаточно для сохранения работоспособности системы в целом и доступности ее данных.
                                    • 0
                                      Да. График привлекает внимание. Рассуждение под ними отпугивают своей нелогичностью.
                                      мнение <> факт
                                      Логично, что собрать статистику сбоев датацентров значительно сложнее, чем просто опросить кучу айтишников. Правда первое было бы действительно полезно, а от опроса толку мало.

                                      В целом статья просто смахивает на рекламу. У кого-то может сложиться впечатление, что это прям единственное решение. ;)
                                      • +1
                                        1. Я с удовольствием сменю приведенные данные на предоставленные вами, если они окажутся более аккуратны и достоверны.

                                        2. Я готов добавить в статью (хотя это и странно для статьи в корпоративном блоге) описание аналогичного решения от другого производителя, если вы мне его покажете и расскажете о нем, хотя бы вкратце, насколько оно аналогично описываемому.
                                        • –4
                                          1. Предлагаете мне бесплатно поработать на Вас? Забавно.
                                          Нет. Давайте уж лучше сами.

                                          2. Не стоит. Но благодарю за предложение.
                                          • 0
                                            Ну если «нет», то, по-моему, не стоило и начинать этот разговор.
                                            • –4
                                              Да. Разговор о том, чтобы я на Вас бесплатно работал действительно не стоило Вам начинать.
                                          • 0
                                            2. Конечно же наш любимый EMC с SRDF, но… по гибкости, как MetroCluster, пытаются все же сделать VPLEX. Но упаси вас господь работать с решениями EMC (IMHO)

                                            RazB0YniK, да это реклама! Все бы такую рекламу делали т.к. в отличии от остальных сторадж вендоров NetApp не занимается умалчиванием чего-либо.
                                            track, про V-Series пишите обязательно… тоже людям мозг взорвет и по-любому будет интересно :)
                                            • 0
                                              SRDF это же вроде на Симметриксе? Согласен, в принципе (хотя и плохо знаю EMC-шные дела, а у них есть прозрачный для приложений тэйковер?), но это совсем другого ценового диапазона решение.
                                              • 0
                                                Да, SRDF это на Симетриксе, прозрачный… ух… ну в EMC в это верят… продукт называется Cluster Enabler и это СОФТ устанавливаемый на ХОСТ подключенный к СХД. Чувствуете разницу? :) Только VPLEX может за собой спрятать все это безобразие.

                                                Про SRDF и Cluster Enabler на пальцах www.youtube.com/watch?v=g5Hhzay4Dqs

                                                Цены, да, космические (без кавычек — они действительно КОСМИЧЕСКИЕ)
                                                • 0
                                                  А, ну когда на хосте-то переключалка, такого-то много, а вот чтобы чисто средствами стораджа полная подмена на ходу для приложения одного контроллера другим, его собственными силами…
                                                  Из весьма бедного описания VPLEX я понял, что это вот оно только.

                                                  Цены… Зато надежно и производительно, не отнять.
                                          • +2
                                            • –1
                                              Ну в каких то случаях это единственный способ оценки. Но не в данном случае.
                                      • 0
                                        Работает только с FC полками.
                                        • 0
                                          Возможно уже этом году появится SAS-to-FC bridge для этой проблемы.
                                          • 0
                                            Интересно будет посмотреть насколько они смогут сохранить плюсы SAS при таком «изврате».
                                            Мне нравится элегантнейшее решение, но будущее его туманно.
                                            Как только RPO/RTO может быть обеспечен синхронным\асинхронным SnapMirror то гораздо дешевле сделать полуручные процедуры DR (vFiler DR тот же очень элегантен).

                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                        Самое читаемое