Полноценные бэкапы — это все же отдельные физические копии данных, размещенные на другом устройстве хранения (в идеале на удаленной площадке), с которыми не работаю в онлайне никакие боевые сервисы и которые можно восстановить в том числе на другое железо. Другой сервер, диски, СХД и т.д.
Тут я бы не согласился. Зачем мне снапшоты сразу на всю ферму серверов с разными OS (условно лежащих на одном агрегате), если в конкретный момент времени мне нужно сделать только консистентный бэкап MS Exchange. Не забываем что снапшот «не равно» полная резервная копия.
Я думаю тут ничего уникального нет. Если с точки зрения VMware, то думают все будет зависеть от того насколько «правильно» настроен VMware SRM. В соответствии с этим либо будет, либо не будет выполнен перезапуск VM на удаленной площадке. Кстати в плане временного лага «подозрение» вызывает таймаут в 15 минут :). Помниться у VMware он точно такой же, если SRM организован на базе собственных аплайнсов VMware, а не на стороннем решении для репликации данных. Хотя при «умелом» подходе или некотором «везении» можно наверно и «split brain» поймать.
А как обстоят дела с репликацией для Hyper-V?
Ждем продолжение про синхронную репликацию. 400км — это хорошая заявка, но интересны детали реализации. На свитчах каких вендоров может быть построено такое решение (обеспечивающее RTT 5 мс на таком расстоянии)? Какие требования к каналу помимо RTT?
Про различные версии FS с вами полностью согласен, но в таком случае имеет смысл проводить несколько тестов с интересующими FS. Кроме того, могу дополнить. Если взять тот же LInux, то там, в зависимости от профиля нагрузки, очень сильно на результат влияет выбранный IO sheduller (noop, anticipatory, deadline, cfq). И не всегда дефолтный [cfq] бывает оптимальным выбором :).
На практике сталкивался с тем, что при тестировании современных СХД при помощи IOMETR и использовании LUN как блочного устройства без создания на нем FS, получаешь совершенно непредсказуемые результаты. Если же все таки не лениться и создавать FS и тестовый файл на ней, то результаты обычно ближе к действительности и коррелируют с предварительными теоретическими расчетами.
Я думаю свой эффект накладывают современные технологии кэширования на стороне СХД. И при «чистой» эмуляции I/O СХД стоит и ничего не делает, так как каким то образом понимает, что на самом деле никаких запросов к несуществующим данным не происходит. Может быть существует более правильное и научное объяснение данного эффекта, но к сожалению я его для себя не нашел.
Статья очень похожа на рекламный буклет. Даже скорее на вырезки из нескольких рекламных буклетов. Если бы не имел представления об VMAX ранее, то честно говоря мало бы что понял. Интереснее было бы почитать более подробно о том «как это работает внутри». Чем достаточно общие маркетинговые фразы о том как все теперь стало круто.
Ок, постараемся не уходить в холивар :). Сразу оговорюсь, что искренее считаю NetApp одним из технологических лидеров и инноваторов на рынке систем хранения данных. Но меня всегда улыбают попытки какого либо из вендоров сказать, что мы лучше всех и мы одни тут такие. Особенно когда это приобретает форму «Все п......., а я — д'Артаньян» :). На самом деле просто не принято говорить о минусах своих решений и это вполне объяснимо и даже наверно по человечески нормально.
Теперь по существу. Я не являюсь человеком глубоко подкованным в технических особенностях СХД компании NetApp и могу ошибаться. Но насколько понимаю snapshots у NetApp делаются на уровне так называемых «flex volume». А луны при этом создаются «уровнем ниже». Т.е. пространство в flex volume разбивается на LUN-ы. Соответственно луны (блочные устройства) уже могут быть отданы различным серверам (потребителям). twistedminds.ru/wp-content/uploads/2012/06/netapp.png
Соответственно при создании снапшота на flex volume начинают отслеживаться изменения по всем лунам на данном flex volume. А не потому единственному луну, где лежит например база MS SQL и который необходимо консистентно бэкапить. Получается перерасход диского пространства на хранение измененных блоков всех остальных лунов, для которых в данный конкретный момент снапшотинг не нужен. Если я не прав, давно все изменилось и работает совершенно не так, то поправьте меня пожалуйста.
Еще раз CoW — это копирование блока, который необходимо изменить в резервный пул, а затем перезапись исходной копии блока. У VMware работает не так, исходный блок никуда не копируется и не перезаписывается. Внимание вопрос: где здесь CoW?
Вчитайтесь еще раз в приведенный вами документ по VMWare. При снятии снапшота исходный «vmdk» файл «замораживается» для изменений. То есть операции записи на него больше не идут. Его блоки ни в какую отдельную резервную область не копируются перед изменением. Где тут CoW по вашему? Все новые записи и записи меняющие существующие блоки перенаправляются в новый созданный на том же DataStore файл «delta.vmdk». Ни чего не напоминает? Да детали реализации у разных производителей отличаются, но все же это механизм и идеология RoW.
За счет этого возврат к снапшоту — это так же просто отмена использования ссылок на блоки delta файла. Т.е. происходит «мгновенно». Естественно виртуалку для этого нужно предварительно выключить.
Проблемы с производительностью заснапшченных виртуалок на VMware есть — это верно. Но тут дело больше реализации механизмов работы самого vmkernel с уже созданными снапшотами (в том числе операция поиска наиболее актуальной версии блока для операций чтения), а не в механизме создания этих снапшотов. Я уже писал «Нет ничего совершенного в этом мире». ;)
Снапшоты у NetApp имеют свои минусы, насколько мне известно (дело не в производительности). Но устраивать холивары не вижу смысла.
Статья несет в себе массу полезной информации. Но к сожалению создает впечатление, что только NetApp использует подход RoW (Redirect of Write), а все остальные производители живут все еще в XX веке и используют подход CoW (Copy on Write). Вернее мне кажется более правильной аббревиатура CoFW (Copy on First Write), так как она более точно отображает суть процесса.
На самом деле все давно не так. И реализация снапшотинга через механизм RoW встречается во многих решениях. Как софтовых (Н-р: снапшоты у VMWare или работа Windows Shadow Services у мелкомягких), так и в хардварных.
При этом тот же механизм снапшотинга RoW имеет также свое негативное влияние на системы в целом и на их производительность. Но размер этого влияния во много раз меньше, чем при использовании старого механизма CoW/CoFW. Нет ничего совершенного в этом мире.
1) У EMC как и у Nutanix, да и у других вендоров, более менее полная документация доступна только «для своих» и на закрытых разделах порталов. Про EMC и VPLEX Metro я помню по каким то анонсам с EMC World 2014. Документальное подтверждение найти сейчас проблема :).
2) Разговор просто про VMware HA cluster, не важно как и на чем организованы датасторы. Возвращаясь к моей первоначальной реплике, из-за которой «разгорелась» наша дискуссия. Я бы не стал с полной уверенностью утверждать, что Nutanix абсолютно уникален со своей синхронной репликацией на 400km.
Насколько помню, по моему «нежно любимый» вами EMC заявлял прошедшей весной о тех же максимальных характеристиках для своего решения VPLEX Metro (5ms RTT и до 400km расстояние между сайтами).
Хотя тут все еще и от софта может зависеть. Та же VMware по-моему поддерживает растянутый HA кластер с характеристиками канала до 10ms RTT между площадками, со всеми live миграциями машин и etc.
За долгие работы вывел уникальную формулу — процентов 95 продавцов не компетентны и не достаточно знают продукт, который продают. И EMC тут далеко не уникально :-). Точно такой же вывод можно сделать про любого ИТ вендора и не только :-).
Если переходить в частности, то Nutanix тоже не спешит техническую документацию в свободный доступ выложить. А без нее что-то кому-то доказывать достаточно сложно и бесперспективно.
А если уж говорить про альтернативы XtremIO, то они есть. Но называть их в блоге EMC не считаю уместным. Ну и врятли к ним можно отнести Nutanix, IMНO решения все таки разноплановые.
Давайте уточним про какие 5 ms вы пишете. В случае nutanix 5 ms это RTT (туда и обратно)? Упрощенно говоря прохождение пакета данных в одну сторону 2,5 ms и возвращение ask о записи тоже 2,5 ms, в сумме 5 ms. Или все таки имеется в ввиду по аналогии с пингом, прохождение сигнала в одну сторону 5 ms?
Не плохо бы названия конкурирующих продуктов писать все таки без ошибок, просто по правилам хорошего тона. Да и что бы проводить «квалифицированные» сравнения, как минимум, необходимо быть специалистом в обоих сравниваемых решениях. Мне в этом плане импонирует подход HDS, которая расширяя свой офис, набирала специалистов от всех своих основных конкурентов. Как раз, что бы новые сотрудники могли проводить квалифицированые сравнения :-).
Про «мы одни умеем синхронно и на 400 км» я не стал бы так категорично утверждать, во избежание казусов :-).
Тут еще вопрос какая задержка на кананале должна выдерживаться при таких дистанциях? Раньше на более коротких отрезках говорили про round-trip time time 5ms. Сейчас с увеличением дистанций все чаще говорят про round-trip time 10ms.
Ну про выдерживание множественных отказов — это мы будем делать выводы после «deep dive» :).
Ну что за практика ответов вопросом на вопрос? Давайте тогда и я попробую так же :).
Решение работает с HyperV / KVM / ESXi одновременно в том числе?
Или как насчет работы не только с гипервизорами, в средах где пока еще не все можно (или не все успели) перенести в виртуализацию?
Как насчет сервисов, для которых производительности одной стандартной ноды Nutanix не достаточно?
Как насчет работы с «разномастными» нодами по составу железа (и вообще с «китайским» самосбором)?
Остальные вопросы оставлю для технических статей ;), вдруг эти вопросы отпадут сами собой :).
К сожалению на мой взгляд без маркетинга обойтись в статье не удалось (да и где сейчас от наго спрячешься :)?). Пока в основном вижу только размахивание чужими флагами (Google / Facebook / Amazon). Да и по описанию плюс/минус то же самое что и у остальных вендоров, начинающих развивать Software Defined решения.
За сим ждем ждем технических подробностей, что бы понять «в чем уникальность?» :) и «почему всем нужен именно Nutanix?».
А как обстоят дела с репликацией для Hyper-V?
Ждем продолжение про синхронную репликацию. 400км — это хорошая заявка, но интересны детали реализации. На свитчах каких вендоров может быть построено такое решение (обеспечивающее RTT 5 мс на таком расстоянии)? Какие требования к каналу помимо RTT?
Я думаю свой эффект накладывают современные технологии кэширования на стороне СХД. И при «чистой» эмуляции I/O СХД стоит и ничего не делает, так как каким то образом понимает, что на самом деле никаких запросов к несуществующим данным не происходит. Может быть существует более правильное и научное объяснение данного эффекта, но к сожалению я его для себя не нашел.
Теперь по существу. Я не являюсь человеком глубоко подкованным в технических особенностях СХД компании NetApp и могу ошибаться. Но насколько понимаю snapshots у NetApp делаются на уровне так называемых «flex volume». А луны при этом создаются «уровнем ниже». Т.е. пространство в flex volume разбивается на LUN-ы. Соответственно луны (блочные устройства) уже могут быть отданы различным серверам (потребителям).
twistedminds.ru/wp-content/uploads/2012/06/netapp.png
Соответственно при создании снапшота на flex volume начинают отслеживаться изменения по всем лунам на данном flex volume. А не потому единственному луну, где лежит например база MS SQL и который необходимо консистентно бэкапить. Получается перерасход диского пространства на хранение измененных блоков всех остальных лунов, для которых в данный конкретный момент снапшотинг не нужен. Если я не прав, давно все изменилось и работает совершенно не так, то поправьте меня пожалуйста.
За счет этого возврат к снапшоту — это так же просто отмена использования ссылок на блоки delta файла. Т.е. происходит «мгновенно». Естественно виртуалку для этого нужно предварительно выключить.
Проблемы с производительностью заснапшченных виртуалок на VMware есть — это верно. Но тут дело больше реализации механизмов работы самого vmkernel с уже созданными снапшотами (в том числе операция поиска наиболее актуальной версии блока для операций чтения), а не в механизме создания этих снапшотов. Я уже писал «Нет ничего совершенного в этом мире». ;)
Снапшоты у NetApp имеют свои минусы, насколько мне известно (дело не в производительности). Но устраивать холивары не вижу смысла.
На самом деле все давно не так. И реализация снапшотинга через механизм RoW встречается во многих решениях. Как софтовых (Н-р: снапшоты у VMWare или работа Windows Shadow Services у мелкомягких), так и в хардварных.
При этом тот же механизм снапшотинга RoW имеет также свое негативное влияние на системы в целом и на их производительность. Но размер этого влияния во много раз меньше, чем при использовании старого механизма CoW/CoFW. Нет ничего совершенного в этом мире.
То что нашлось в открытом доступе. EMC про VPLEX Metro говорит обтекаемо о «over synchronous distance». www.emc.com/collateral/hardware/data-sheet/h7070-vplex-family-ds.pdf
Cisco говорит о максимальном пределе дистанций с RTT 5ms по FC — 400km:
www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Data_Center/DCI/4-0/EMC/dciEmc/EMC_2.html
Brocade тоже не отстает и говорится вообще о реальности RTT 10ms и 900km между датацентрами на VPLEX+растянутый кластер VMware HA:
www.brocade.com/downloads/documents/solution_briefs/new-business-continuity-moving-applications-across-data-centers-without-interruption.pdf
По VMware вы привели ссылку на версии 4.x, на дворе давно версии 5.x. Например вот эта статья более свежая (Раздел «Configuration Requirements»): kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=2007545&sliceId=1&docTypeID=DT_KB_1_1&dialogID=423728455&stateId=1%200%20409622847
2) Разговор просто про VMware HA cluster, не важно как и на чем организованы датасторы. Возвращаясь к моей первоначальной реплике, из-за которой «разгорелась» наша дискуссия. Я бы не стал с полной уверенностью утверждать, что Nutanix абсолютно уникален со своей синхронной репликацией на 400km.
Хотя тут все еще и от софта может зависеть. Та же VMware по-моему поддерживает растянутый HA кластер с характеристиками канала до 10ms RTT между площадками, со всеми live миграциями машин и etc.
Если переходить в частности, то Nutanix тоже не спешит техническую документацию в свободный доступ выложить. А без нее что-то кому-то доказывать достаточно сложно и бесперспективно.
А если уж говорить про альтернативы XtremIO, то они есть. Но называть их в блоге EMC не считаю уместным. Ну и врятли к ним можно отнести Nutanix, IMНO решения все таки разноплановые.
Тут еще вопрос какая задержка на кананале должна выдерживаться при таких дистанциях? Раньше на более коротких отрезках говорили про round-trip time time 5ms. Сейчас с увеличением дистанций все чаще говорят про round-trip time 10ms.
Ну что за практика ответов вопросом на вопрос? Давайте тогда и я попробую так же :).
Решение работает с HyperV / KVM / ESXi одновременно в том числе?
Или как насчет работы не только с гипервизорами, в средах где пока еще не все можно (или не все успели) перенести в виртуализацию?
Как насчет сервисов, для которых производительности одной стандартной ноды Nutanix не достаточно?
Как насчет работы с «разномастными» нодами по составу железа (и вообще с «китайским» самосбором)?
Остальные вопросы оставлю для технических статей ;), вдруг эти вопросы отпадут сами собой :).
За сим ждем ждем технических подробностей, что бы понять «в чем уникальность?» :) и «почему всем нужен именно Nutanix?».