Ничего странного в их позиции нет. Если вы хотите мигрировать на сDOT вы можете сделать это:
Сами, бесплатно. Скачиваете прошивку и обновляетесь. Повторюсь, другие вендоры вам этого вообще не дали бы сделать, а сказали бы что новый функционал доступен на новом железе — покупайте новое железо.
Привлекая NetApp Professional Support
Привлечение Professional Support это платная услуга, не относящаяся к Technical Support о котором вы говорите.
Кстати говоря за Technical Support очень часто заказчик вообще ничего не платит: Точнейе базовый сапорт стоит 0$ на 3 года, в таком случае сапорт оказывает ТОЛЬКО удалённые консультации без выезда инженера.
Что же касается парка железа, повторюсь, они им «делиться» ни с кем не обязаны, вообще. Но иногда это делают:
Вендор или дистрибютор могут пойти на встречу и дать железо для миграции бесплатно. У меня на практике было масса таких примеров. Но это исключительно на их рассуждение и добрую волю, они этого делать не обязаны…
Поймите дистрибьютора и вендора тоже: они это железо не бесплатно получили. Как ни крути они его тоже покупают и тратят на это деньги, оно им не бесплатно достаётся.
В данном примере, как вы корректно заметили, вам для защиты от подобной ситуации стоит иметь вторую систему FAS, ONTAP Select или Cloud ONTAP, на которой будет храниться бэкап для восстановления с данными которые уже сжаты/дедуплицированны.
При восстановлении на основе SnapMirror данные будут переданы в сжатом/дедублицированном виде.
Важно кстати отметить, что если данные начнут зашифровываться вирусом, то такие данные крайне плохо компрессируются/жмуться. Другими словами если на системе всего 1ТБ пространства, сжатие давало вам 4х кратную экономию на 4ТБ базе, то полезное пространство закончиться крайне быстро после начала шифрования вирусом так как по-сути пройзойдёт распаковка данных с точки зрения занятого пространства.
Как общее правило в любых системах (не только СХД): чем выше степень защищённости и чем от больших потенциальных угроз бизнес требует защиты, тем дороже получается решение.
Вы ещё на 7-моде? Если вы уже на Clustered ONTAP, то обновление прошивки (если есть действующий сапорт) совершенно не проблема: обновление можно выполнить без миграции и простоя накатывая прошывки до самой последней. Ваш FAS поддерживает 9ку?
Вендор или дистрибютор могут пойти на встречу и дать железо для миграции бесплатно. У меня на практике было масса таких примеров.
Но это исключительно на их рассуждение и добрую волю, они этого делать не обязаны…
Опять таки всё познаётся в сравнении: многие вендоры вообще не дали бы такой возможности, а предложили бы просто купить новое железо.
На этом фоне оплата за аренду временного хранилища для апгрейда не такая уж и большая проблема…
Поймите дистрибьютора и вендора тоже: они это железо не бесплатно получили. Как ни крути они его тоже покупают и тратят на это деньги, оно им не бесплатно достаётся. Попробуйте связаться с вендором напрямую и попросить вам помочь. У вас много данных?
Дело в том, что каждый производитель СХД А-класса продумывает такие моменты.
И у каждого из них, исходя из набора функционала в их массивах, есть свой подход и комплексное видение решения тех или иных проблем, в том числе вопроса бэкапа и восстановления. Это по-моему и является определением СХД А-класса.
Чего нельзя сказать о других, более дешевых СХД, у которых такого видения или вовсе нет или они обрывчастые, примитивное.
Я уже писал о парадигме резарвного копирования данных на нетапе.
Если отвечать на ваш конкретный вопрос, то у нетапа свой подход к решению этого вопроса:
Подход заключается в репликации оригинального набора данных (с сохранением дедупа и компрессии) на второй DR сайт, где должна стоять СХД с софтом ONTAP. Это может быть схема, когда на основном сайте стоит AFF, а на резервной FAS с обычными дисками или ONTAP Select (VSA SDS) или даже ONTAP Cloud (Статью опубликую позже).
В таких схемах, при передаче (И ВОССТАНОВЛЕНИИ) данных сохраняется сжатие + дедуп, заданный вами вопрос в принципе не стоит.
Если же пробовать микроскопом забить гвоздь, то и гвоздь может погнуться и микроскоп повредится.
У гарантии есть свои условия, рекомендую обратиться к представительству нетапа и запросить их.
Если в кратце, то чтобы работала «гарантия 4:1», нужно включать все механизмы эффективности.
В нашем тесте важно было получить лучший перфоменс, а сжатие в два раза был приятный бонус за которым никто не гнался ввиду того что система итак была существенно дешевле конкурентов. Обращу ваше внимение, что в нашем тесте не были включены пост дедуп и пост компрессия.
Спасибо за вопрос.
Могу вам ответить из практики но к сожалению не могу раскрывать некоторых деталей о ходе тестирования.
Тестировалась система
AFF8040
прошивка ONTAP9 RC1
с базой данных 6ТБ
и включёнными и выключенными механизмами инлайн компрессии, инлайн дедупа и дата компакции
пост компрессия и пост дедуп были всегда выключены.
в ходе тестирования запускали набор бизнес процессов использующих БД на All Flash
Критерием оценки скорости работы системы хранения, для заказчика, было суммарное время выполнения этих бизнес процессов. Ранее на High End системе хранения с 15к дисками это занимало 6-9 часов. На ряду с системой AFF тестировалось ещё несколько All Flash систем.
AFF8040 с выключенной инлайн компрессией и выключенным инлайн делупом показывали 2 часа 30 минут, тест был проведён множество раз, результат повторялся.
AFF8040 с включенной инлайн компрессией и включенным инлайн делупом показывали 2 часа 45 минут, тест был проведён множество раз, результат повторялся. Сжатие БД было в два раза.
С точки зрения нагрузки ЦПУ на системе хранения, она никогда не прыгала выше 15%.
Ближайший конкурент с технологией «MicroLatency», специальными Flash модулями (там используются не SSD диски) и последней моделью All Flash системой хранения показывал 3 часа и не имел компрессии и дедупа в принципе.
С точки зрения стоимости AFF была в разы дешевле системы со специализированными MicroLatency Flash модулями. Сразу предупреждаю по вопросам цен на оборудование NetApp я вам не помогу.
Вайпконфиг чистит хвосты старой конфиги онтапа на флеше.
Вообще-то 4 пункт бутменю делает инициалмзацию и Вайпконфиг.
Его было обязательно выполнять в более старой версии онтапа после перехода с 7-мода на кластер. У меня как-то давно была ситуация, что кластер не хотел собираться, я долго не мог понять почему и Вайпконфиг мне помог именно ДО того как я конвертировал онтап в кластер мод, ПОТОМ конвертировал в кластер, выполнил 4-й пункт бутменю и все получилось.
Теперь я его всегда делаю, выполнить не сложно и совсем не долго, так что я его делаю по старой памяти, чтобы не наступать на старые грабли дважды. Может сейчас уже этого делать и не нужно.
Уверен что господин navion сам или прекрасно это знает, ему это объяснять не нужно или его это на самом деле не не волнует.
Он просто любит кидать каких на вентилятор.
Особенно когда дело касается нетапа, он у меня в блоге тоже постоянно это делает.
Потому что он любит hp и EMC и наслушался от маркетинга про тормозящий нетап.
Я правильно понимаю, что вы пытаетесь найти подвох путём заявлений на подобии?:
у NetApp интеграция выполнена довольно хреново — VASA-провайдер ставивтся в виртуалку, а не интегрирован в контроллер как у 3PAR с EMC
По TCP, причем не очень хорошо оптимизированному, если судить по частоте упоминаний в рекламе WAN-оптимизаторов.
А по-моему вот именно эти комментарии, это самый что ни на есть подвох.
Ну что могу сказать, — вы сама объективность и непредвзятость. И последнее, что могу добавить как практик практику, — если судить по вашей «непредвзятости» и частоте нахождения «подвохов», а в этом посте вы нашли их, ну просто массу, если вы и практикуете, то явно не нетап, потому что маркетинг других вендоров вам-то как раз хорошо по ушам и поездил, потому что именно отсюда все эти ваши удивительные предположения произростают.
ЗЫ меня до сих пор улыбает мысль про «плохо оптимизированный TCP исходя из числа упоминаний WAN оптимизаторов под репликацию».
Действительно используется 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.
Как-то у коментарии к моим постам всегда однобокие получаются.
Всё плохо, все не работает.
У вас используется TCP? Какой кашмар, сам факт использования TCP ужасен и говорит об ущербности ВСЕХ без исключения технологий NetApp, вы ещё скажите, не дай Бог, что SnapMirror работает поверх IP!
У вас можно использовать оптимизаторы WAN? Ужас, это прямое подтвержение первого утверждения!
Посмотрите на реализацию их vVol'ов, это сплошной технический беспредел, VASA провайдер вынесен из ONTAP. Только сам факт того что VASA вынесен наружу подтверждает ущербность реализации этой технологии и не важно, что NetApp был одним из главных дизайнеров этой технологии и самой первой её ревлизовал и внедрил в свои продукты! Да и вообще этот vVOL никто не использует потому что работает это отсойно, нето что в 3PAR и EMC.
Привлечение Professional Support это платная услуга, не относящаяся к Technical Support о котором вы говорите.
Кстати говоря за Technical Support очень часто заказчик вообще ничего не платит: Точнейе базовый сапорт стоит 0$ на 3 года, в таком случае сапорт оказывает ТОЛЬКО удалённые консультации без выезда инженера.
Что же касается парка железа, повторюсь, они им «делиться» ни с кем не обязаны, вообще. Но иногда это делают:
Ждем, не дождемся!
При восстановлении на основе SnapMirror данные будут переданы в сжатом/дедублицированном виде.
Важно кстати отметить, что если данные начнут зашифровываться вирусом, то такие данные крайне плохо компрессируются/жмуться. Другими словами если на системе всего 1ТБ пространства, сжатие давало вам 4х кратную экономию на 4ТБ базе, то полезное пространство закончиться крайне быстро после начала шифрования вирусом так как по-сути пройзойдёт распаковка данных с точки зрения занятого пространства.
Как общее правило в любых системах (не только СХД): чем выше степень защищённости и чем от больших потенциальных угроз бизнес требует защиты, тем дороже получается решение.
Вендор или дистрибютор могут пойти на встречу и дать железо для миграции бесплатно. У меня на практике было масса таких примеров.
Но это исключительно на их рассуждение и добрую волю, они этого делать не обязаны…
Опять таки всё познаётся в сравнении: многие вендоры вообще не дали бы такой возможности, а предложили бы просто купить новое железо.
На этом фоне оплата за аренду временного хранилища для апгрейда не такая уж и большая проблема…
Поймите дистрибьютора и вендора тоже: они это железо не бесплатно получили. Как ни крути они его тоже покупают и тратят на это деньги, оно им не бесплатно достаётся. Попробуйте связаться с вендором напрямую и попросить вам помочь. У вас много данных?
И у каждого из них, исходя из набора функционала в их массивах, есть свой подход и комплексное видение решения тех или иных проблем, в том числе вопроса бэкапа и восстановления. Это по-моему и является определением СХД А-класса.
Чего нельзя сказать о других, более дешевых СХД, у которых такого видения или вовсе нет или они обрывчастые, примитивное.
Я уже писал о парадигме резарвного копирования данных на нетапе.
Если отвечать на ваш конкретный вопрос, то у нетапа свой подход к решению этого вопроса:
Подход заключается в репликации оригинального набора данных (с сохранением дедупа и компрессии) на второй DR сайт, где должна стоять СХД с софтом ONTAP. Это может быть схема, когда на основном сайте стоит AFF, а на резервной FAS с обычными дисками или ONTAP Select (VSA SDS) или даже ONTAP Cloud (Статью опубликую позже).
В таких схемах, при передаче (И ВОССТАНОВЛЕНИИ) данных сохраняется сжатие + дедуп, заданный вами вопрос в принципе не стоит.
Если же пробовать микроскопом забить гвоздь, то и гвоздь может погнуться и микроскоп повредится.
Вполне логично что видео и картинки не возможно сжать без потери качества, а СХД конечно же, этого делать не станет.
Другими словами в условиях программы экономии 4:1 прописано что на видео и картинки эта программа не расспространяется.
Если в кратце, то чтобы работала «гарантия 4:1», нужно включать все механизмы эффективности.
В нашем тесте важно было получить лучший перфоменс, а сжатие в два раза был приятный бонус за которым никто не гнался ввиду того что система итак была существенно дешевле конкурентов. Обращу ваше внимение, что в нашем тесте не были включены пост дедуп и пост компрессия.
Могу вам ответить из практики но к сожалению не могу раскрывать некоторых деталей о ходе тестирования.
Тестировалась система
Критерием оценки скорости работы системы хранения, для заказчика, было суммарное время выполнения этих бизнес процессов. Ранее на High End системе хранения с 15к дисками это занимало 6-9 часов. На ряду с системой AFF тестировалось ещё несколько All Flash систем.
AFF8040 с выключенной инлайн компрессией и выключенным инлайн делупом показывали 2 часа 30 минут, тест был проведён множество раз, результат повторялся.
AFF8040 с включенной инлайн компрессией и включенным инлайн делупом показывали 2 часа 45 минут, тест был проведён множество раз, результат повторялся. Сжатие БД было в два раза.
С точки зрения нагрузки ЦПУ на системе хранения, она никогда не прыгала выше 15%.
Ближайший конкурент с технологией «MicroLatency», специальными Flash модулями (там используются не SSD диски) и последней моделью All Flash системой хранения показывал 3 часа и не имел компрессии и дедупа в принципе.
С точки зрения стоимости AFF была в разы дешевле системы со специализированными MicroLatency Flash модулями. Сразу предупреждаю по вопросам цен на оборудование NetApp я вам не помогу.
Остается только признать что TCP плохо у нетапа оптимизирован, а vVol вообще не работает.
Вообще-то 4 пункт бутменю делает инициалмзацию и Вайпконфиг.
Его было обязательно выполнять в более старой версии онтапа после перехода с 7-мода на кластер. У меня как-то давно была ситуация, что кластер не хотел собираться, я долго не мог понять почему и Вайпконфиг мне помог именно ДО того как я конвертировал онтап в кластер мод, ПОТОМ конвертировал в кластер, выполнил 4-й пункт бутменю и все получилось.
Теперь я его всегда делаю, выполнить не сложно и совсем не долго, так что я его делаю по старой памяти, чтобы не наступать на старые грабли дважды. Может сейчас уже этого делать и не нужно.
Он просто любит кидать каких на вентилятор.
Особенно когда дело касается нетапа, он у меня в блоге тоже постоянно это делает.
Потому что он любит hp и EMC и наслушался от маркетинга про тормозящий нетап.
Означает ли появление агента поддержку RDM в среде виртуализации?
Если да, поддерживаются ли снепшоты СХД в таком решении?
Спасибо за статью!
А по-моему вот именно эти комментарии, это самый что ни на есть подвох.
Ну что могу сказать, — вы сама объективность и непредвзятость. И последнее, что могу добавить как практик практику, — если судить по вашей «непредвзятости» и частоте нахождения «подвохов», а в этом посте вы нашли их, ну просто массу, если вы и практикуете, то явно не нетап, потому что маркетинг других вендоров вам-то как раз хорошо по ушам и поездил, потому что именно отсюда все эти ваши удивительные предположения произростают.
ЗЫ меня до сих пор улыбает мысль про «плохо оптимизированный TCP исходя из числа упоминаний WAN оптимизаторов под репликацию».
Не пойму как у вас интерес к нетапу ещё остался.
Я сам после ваших железобетонных аргументов подумываю бросить заниматься этим безобразием, на что я трачу свою жизнь? Одно сплошное разачарование.
Действительно используется 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? Какой кашмар, сам факт использования TCP ужасен и говорит об ущербности ВСЕХ без исключения технологий NetApp, вы ещё скажите, не дай Бог, что SnapMirror работает поверх IP!
У вас можно использовать оптимизаторы WAN? Ужас, это прямое подтвержение первого утверждения!
Технологии снепшотов ущербынее некуда, вы посмотрите на эти снепшоты, не то что HP и EMC, они то знают что снепшоты это зло, именно по-этому у них их так долго небыло. И вообще «NetApp это на настотоящий SAN» ©!
Посмотрите на реализацию их vVol'ов, это сплошной технический беспредел, VASA провайдер вынесен из ONTAP. Только сам факт того что VASA вынесен наружу подтверждает ущербность реализации этой технологии и не важно, что NetApp был одним из главных дизайнеров этой технологии и самой первой её ревлизовал и внедрил в свои продукты! Да и вообще этот vVOL никто не использует потому что работает это отсойно, нето что в 3PAR и EMC.