Comments 19
UFO just landed and posted this here
Есть информация о том, по какому протоколу идет SnapMirror по сети? Очень интересно, но найти не смог.
0
При нетаповские снепшоты забывают сказать одну важную штуку: они не заменяют обычные снепшты VMware, а работают параллельно с ними и придётся переделывать всю схему работы.
Это изменилось в VVOLs, но ими пока мало кто пользуется и у NetApp интеграция выполнена довольно хреново — VASA-провайдер ставивтся в виртуалку, а не интегрирован в контроллер как у 3PAR с EMC.
Это изменилось в VVOLs, но ими пока мало кто пользуется и у NetApp интеграция выполнена довольно хреново — VASA-провайдер ставивтся в виртуалку, а не интегрирован в контроллер как у 3PAR с EMC.
-1
Как-то у коментарии к моим постам всегда однобокие получаются.
Всё плохо, все не работает.
У вас используется TCP? Какой кашмар, сам факт использования TCP ужасен и говорит об ущербности ВСЕХ без исключения технологий NetApp, вы ещё скажите, не дай Бог, что SnapMirror работает поверх IP!
У вас можно использовать оптимизаторы WAN? Ужас, это прямое подтвержение первого утверждения!
Технологии снепшотов ущербынее некуда, вы посмотрите на эти снепшоты, не то что HP и EMC, они то знают что снепшоты это зло, именно по-этому у них их так долго небыло. И вообще «NetApp это на настотоящий SAN» ©!
Посмотрите на реализацию их vVol'ов, это сплошной технический беспредел, VASA провайдер вынесен из ONTAP. Только сам факт того что VASA вынесен наружу подтверждает ущербность реализации этой технологии и не важно, что NetApp был одним из главных дизайнеров этой технологии и самой первой её ревлизовал и внедрил в свои продукты! Да и вообще этот vVOL никто не использует потому что работает это отсойно, нето что в 3PAR и EMC.
Всё плохо, все не работает.
У вас используется TCP? Какой кашмар, сам факт использования TCP ужасен и говорит об ущербности ВСЕХ без исключения технологий NetApp, вы ещё скажите, не дай Бог, что SnapMirror работает поверх IP!
У вас можно использовать оптимизаторы WAN? Ужас, это прямое подтвержение первого утверждения!
Технологии снепшотов ущербынее некуда, вы посмотрите на эти снепшоты, не то что HP и EMC, они то знают что снепшоты это зло, именно по-этому у них их так долго небыло. И вообще «NetApp это на настотоящий SAN» ©!
Посмотрите на реализацию их vVol'ов, это сплошной технический беспредел, VASA провайдер вынесен из ONTAP. Только сам факт того что VASA вынесен наружу подтверждает ущербность реализации этой технологии и не важно, что NetApp был одним из главных дизайнеров этой технологии и самой первой её ревлизовал и внедрил в свои продукты! Да и вообще этот vVOL никто не использует потому что работает это отсойно, нето что в 3PAR и EMC.
0
Это прекрасный пример того как люди хотели сэкономить, получили больше чем конкуренты, но остались не давольны потому что хотели ещё больше.
0
Вы уже столько недостатков понаходили, ну прям недостаток на недостатке, вы меня снова поймали.
Не пойму как у вас интерес к нетапу ещё остался.
Я сам после ваших железобетонных аргументов подумываю бросить заниматься этим безобразием, на что я трачу свою жизнь? Одно сплошное разачарование.
Не пойму как у вас интерес к нетапу ещё остался.
Я сам после ваших железобетонных аргументов подумываю бросить заниматься этим безобразием, на что я трачу свою жизнь? Одно сплошное разачарование.
0
Интерес практический, поэтому хочу знать заранее где ждать подвоха.
0
Я правильно понимаю, что вы пытаетесь найти подвох путём заявлений на подобии?:
А по-моему вот именно эти комментарии, это самый что ни на есть подвох.
Ну что могу сказать, — вы сама объективность и непредвзятость. И последнее, что могу добавить как практик практику, — если судить по вашей «непредвзятости» и частоте нахождения «подвохов», а в этом посте вы нашли их, ну просто массу, если вы и практикуете, то явно не нетап, потому что маркетинг других вендоров вам-то как раз хорошо по ушам и поездил, потому что именно отсюда все эти ваши удивительные предположения произростают.
ЗЫ меня до сих пор улыбает мысль про «плохо оптимизированный TCP исходя из числа упоминаний WAN оптимизаторов под репликацию».
у NetApp интеграция выполнена довольно хреново — VASA-провайдер ставивтся в виртуалку, а не интегрирован в контроллер как у 3PAR с EMC
По TCP, причем не очень хорошо оптимизированному, если судить по частоте упоминаний в рекламе WAN-оптимизаторов.
А по-моему вот именно эти комментарии, это самый что ни на есть подвох.
Ну что могу сказать, — вы сама объективность и непредвзятость. И последнее, что могу добавить как практик практику, — если судить по вашей «непредвзятости» и частоте нахождения «подвохов», а в этом посте вы нашли их, ну просто массу, если вы и практикуете, то явно не нетап, потому что маркетинг других вендоров вам-то как раз хорошо по ушам и поездил, потому что именно отсюда все эти ваши удивительные предположения произростают.
ЗЫ меня до сих пор улыбает мысль про «плохо оптимизированный TCP исходя из числа упоминаний WAN оптимизаторов под репликацию».
0
Всё нормальное — вам мерещатся происки конкурентов, а мне недоговорки вендоров.
Про VASA провайдер я не сам придумал, у Кормака в комментариях несколько вендоров отписались что у них всё ОК, а нетаповец объяснил, что они сделали лучше «для тех, кто больше платит». В итоге имеем здоровенную виртуалку (4 vCPU, 8 GB) с ещё одной точкой отказа.
Про VASA провайдер я не сам придумал, у Кормака в комментариях несколько вендоров отписались что у них всё ОК, а нетаповец объяснил, что они сделали лучше «для тех, кто больше платит». В итоге имеем здоровенную виртуалку (4 vCPU, 8 GB) с ещё одной точкой отказа.
0
А если отвечать не в вашем стиле, а по-факту, то:
Действительно используется TCP/IP, при необходимости снепмирор может передавать трафик используя компрессию Over the Wire, но эта компрессия ест мошность CPU СХД. Over the Wire это когда вы жмете данные перед отправкой и потом расжимаете, когда получаете на принимающей стороне. По-этому её можно отключить и использовать выделенный WAN оптимизатор, чтобы CPU СХД не нагружать, а вынести нагрузку по компрессии на отдельное устройство — оптимизатор.
Если же используется inline компрессия и дедуп, которая оптимизирована для CPU которая выполняет запись данных уже в сжатом виде, то Over the Wire включать смысла нет, так как данные уже сжаты и задедуплицированы передаются на получатель.
Что же касается vVOL, как было сказано, Нетапп является не только технологическим партнёром, но и дизайнером этой технологии. Первой реализовал этот функционал, первой реализовал фукционал vVOL для NFS, и вы всё ещё думаете что она «хреново работает», просто потому что VASA-провайдер ставивтся в виртуалку? Нетапп рассматривал возможность установки его в ONTAP, но остановился на таком решении. Это просто такой подход имеющий право на жизнь, никак не сказывающийся на том как работает vVOL. А драйвил тему с vVOL нетап, потому что у него снепы отлично работают и ВМваровский гипервизор тоже очень хорошая технология, но снепы плохо у него работают, по-этому в сочитании технологий нетаповских снепов и ВМваре гипервизора можно получить больше плюсов.
Что же касается снепов на виртуализации, опять таки не понимание, не договоки и манипуляции с целью приуменьшить значимость снепов:
Теперь EMC сделала Unity, а HP купили 3PAR и вдруг они вспомнили что они «тоже умеют снепы как у нетап» и «тоже умеют SAN и NAS из одной коробки». Но чтобы сделать тоже самое, того же качества, интеграции и функционала им теперь нужно пройти теже 23 года. Именно по-этому у них столько «но» и столько ограничений связаных с снепами и NAS.
Всё познается в сравнении.
Действительно используется TCP/IP, при необходимости снепмирор может передавать трафик используя компрессию Over the Wire, но эта компрессия ест мошность CPU СХД. Over the Wire это когда вы жмете данные перед отправкой и потом расжимаете, когда получаете на принимающей стороне. По-этому её можно отключить и использовать выделенный WAN оптимизатор, чтобы CPU СХД не нагружать, а вынести нагрузку по компрессии на отдельное устройство — оптимизатор.
Если же используется inline компрессия и дедуп, которая оптимизирована для CPU которая выполняет запись данных уже в сжатом виде, то Over the Wire включать смысла нет, так как данные уже сжаты и задедуплицированы передаются на получатель.
Что же касается vVOL, как было сказано, Нетапп является не только технологическим партнёром, но и дизайнером этой технологии. Первой реализовал этот функционал, первой реализовал фукционал vVOL для NFS, и вы всё ещё думаете что она «хреново работает», просто потому что VASA-провайдер ставивтся в виртуалку? Нетапп рассматривал возможность установки его в ONTAP, но остановился на таком решении. Это просто такой подход имеющий право на жизнь, никак не сказывающийся на том как работает vVOL. А драйвил тему с vVOL нетап, потому что у него снепы отлично работают и ВМваровский гипервизор тоже очень хорошая технология, но снепы плохо у него работают, по-этому в сочитании технологий нетаповских снепов и ВМваре гипервизора можно получить больше плюсов.
Что же касается снепов на виртуализации, опять таки не понимание, не договоки и манипуляции с целью приуменьшить значимость снепов:
- Во-первых, да есть такая схема которая использует снеп ВМваре, потом снимается снеп нетапа, потом снеп Вмваре удаляется. Разница с «просто снепами Вмваре» в том, что её снеп на много меньше живёт и соответственно вопрос проблемы консолидации Вмваровских снепов не стоит. Эта схема хорошо подходит для средних нагрузок.
- Во-вторых, есть и другая схема снепов в среде виртуализации — RDM (кстати vVOL очень много подчерпнул из этой схемы), когда луны пробрасываюся внутрь гостевой ОС, в таком случае устраняется необходимость в снепах ВМваре вовсе. Эта схема подходит для высоких нагрузок, к примеру с базами данных (десятки тысяч IOPS, террабайты данных).
- В третьих манипуляция в том что приуменьшается таким образом нетаповские снепы. В то время как нетаповским снепам уже 23 года (появились спустя год после выпуска WAFL — в 1993 г), которые отлажены и отлично работают как на NAS так и SAN, у конкурентов они появились только недавно и только в для SAN. Ситуация с WAFL вообще смешная, маркетинг конкурентов кричали что NetApp «это не настоящий SAN», там используется «файловая система», у которой «фрагментация из-за чего она медленно она работает», а сами техоничко пилитли тоже самое.
- В четвертых давайте посмотрим на ситуацию не «относительно», а «по факту», как это сейчас устроено у других: а там всё ещё хуже, вам нужно или использовать снепы ВМвары и пока идёт фулл-бекап хранить его, всё это время дельта снепа растёт, всё это время имеются накладные расходы по производительности и только потом, после окончания его можно удалить. Альтернатива этому — делать фул-бэкап из нутри гостевой ОС, опять таки имея дополнительную и длительное время на дисковую подсистему, пока идёт фул-бэкап. В обоих вариантах имеем дополнительную нагрузку на CPU гипервизора и сетевые порты — в противовес нетаповским снепам, где этого безобразия нет.
Теперь EMC сделала Unity, а HP купили 3PAR и вдруг они вспомнили что они «тоже умеют снепы как у нетап» и «тоже умеют SAN и NAS из одной коробки». Но чтобы сделать тоже самое, того же качества, интеграции и функционала им теперь нужно пройти теже 23 года. Именно по-этому у них столько «но» и столько ограничений связаных с снепами и NAS.
Всё познается в сравнении.
+1
Sign up to leave a comment.
NetApp ONTAP: SnapMirror for SVM