Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 19
Есть информация о том, по какому протоколу идет SnapMirror по сети? Очень интересно, но найти не смог.
При нетаповские снепшоты забывают сказать одну важную штуку: они не заменяют обычные снепшты VMware, а работают параллельно с ними и придётся переделывать всю схему работы.
Это изменилось в VVOLs, но ими пока мало кто пользуется и у NetApp интеграция выполнена довольно хреново — VASA-провайдер ставивтся в виртуалку, а не интегрирован в контроллер как у 3PAR с EMC.
Это изменилось в VVOLs, но ими пока мало кто пользуется и у NetApp интеграция выполнена довольно хреново — VASA-провайдер ставивтся в виртуалку, а не интегрирован в контроллер как у 3PAR с EMC.
Как-то у коментарии к моим постам всегда однобокие получаются.
Всё плохо, все не работает.
У вас используется 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.
Я из тех, кто в первую очередь смотрит на недостатки и ограничения, потому что вендор рассказать про них забывает. Про NetApp есть прекрасная статья в блоге ТКС, жаль такое редко встречается.
Это прекрасный пример того как люди хотели сэкономить, получили больше чем конкуренты, но остались не давольны потому что хотели ещё больше.
Вы уже столько недостатков понаходили, ну прям недостаток на недостатке, вы меня снова поймали.
Не пойму как у вас интерес к нетапу ещё остался.
Я сам после ваших железобетонных аргументов подумываю бросить заниматься этим безобразием, на что я трачу свою жизнь? Одно сплошное разачарование.
Не пойму как у вас интерес к нетапу ещё остался.
Я сам после ваших железобетонных аргументов подумываю бросить заниматься этим безобразием, на что я трачу свою жизнь? Одно сплошное разачарование.
Интерес практический, поэтому хочу знать заранее где ждать подвоха.
Я правильно понимаю, что вы пытаетесь найти подвох путём заявлений на подобии?:
А по-моему вот именно эти комментарии, это самый что ни на есть подвох.
Ну что могу сказать, — вы сама объективность и непредвзятость. И последнее, что могу добавить как практик практику, — если судить по вашей «непредвзятости» и частоте нахождения «подвохов», а в этом посте вы нашли их, ну просто массу, если вы и практикуете, то явно не нетап, потому что маркетинг других вендоров вам-то как раз хорошо по ушам и поездил, потому что именно отсюда все эти ваши удивительные предположения произростают.
ЗЫ меня до сих пор улыбает мысль про «плохо оптимизированный TCP исходя из числа упоминаний WAN оптимизаторов под репликацию».
у NetApp интеграция выполнена довольно хреново — VASA-провайдер ставивтся в виртуалку, а не интегрирован в контроллер как у 3PAR с EMC
По TCP, причем не очень хорошо оптимизированному, если судить по частоте упоминаний в рекламе WAN-оптимизаторов.
А по-моему вот именно эти комментарии, это самый что ни на есть подвох.
Ну что могу сказать, — вы сама объективность и непредвзятость. И последнее, что могу добавить как практик практику, — если судить по вашей «непредвзятости» и частоте нахождения «подвохов», а в этом посте вы нашли их, ну просто массу, если вы и практикуете, то явно не нетап, потому что маркетинг других вендоров вам-то как раз хорошо по ушам и поездил, потому что именно отсюда все эти ваши удивительные предположения произростают.
ЗЫ меня до сих пор улыбает мысль про «плохо оптимизированный TCP исходя из числа упоминаний WAN оптимизаторов под репликацию».
Всё нормальное — вам мерещатся происки конкурентов, а мне недоговорки вендоров.
Про VASA провайдер я не сам придумал, у Кормака в комментариях несколько вендоров отписались что у них всё ОК, а нетаповец объяснил, что они сделали лучше «для тех, кто больше платит». В итоге имеем здоровенную виртуалку (4 vCPU, 8 GB) с ещё одной точкой отказа.
Про VASA провайдер я не сам придумал, у Кормака в комментариях несколько вендоров отписались что у них всё ОК, а нетаповец объяснил, что они сделали лучше «для тех, кто больше платит». В итоге имеем здоровенную виртуалку (4 vCPU, 8 GB) с ещё одной точкой отказа.
А если отвечать не в вашем стиле, а по-факту, то:
Действительно используется 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.
Всё познается в сравнении.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
NetApp ONTAP: SnapMirror for SVM