1. По SSD понял, что нужна более детальная статья на тему. Обдумаем.
2. При работе QoS (в любом его виде где угодно) всегда должен быть тот несчастный, за счет которого будут выезжать избранные, если что. Разве нет? Смысл в QoS, если оба участника соревнования будут иметь наивысший приоритет? Предполагаем, что есть третий, четвертый и т.д. участники с более низким уровнем, и тогда ответ на ваш вопрос — именно за них счет будет поддерживаться должный уровень обслуживания первого и второго. Плюс еще раз касательно разделения томов 3пара по разным физическим носителям (без размазывания всех по всем) — это возможно, если реально нужно — пожалуйста. И не будет тогда железно плохого соседа на тех же носителях. Только 100 раз подумать нужно сначала — "+" будет такое разделение или "-", ну а это уже зависит от каждого конкретного случая.
3.
— Про стопы красиво :) Интересно тогда, что же тогда «всё остальное», возвращаясь к возможностям 3пар?
— «Для всего» — безусловно нет. Возможно, технически даже такую систему можно найти, но вот экономически для чего-то подходить она не будет.
— Средний массив сегодня (так называемый midrange, хотя не люблю это понятие) — это более 500 накопителей в плане масштабирования. Учитывая размер накопителя нынешний — это более чем достаточно для 99% организаций с перспективой роста на весь жизненный цикл оборудования. Так что — тонкий стэк плюс грамотные дозакупки накопителей и рост без даунтайма исключительно по мере необходимости обеспечен.
-Не согласен. Работать в многосайтовых конфигурациях 3пар умеет. Тут надо от целей и задач плясать. Что нужно и насколько это целесообразно? И в целом «Растянуть инфраструктуру» как-то нехорошо звучит.
Согласен. Фактически да. Но вот реально работающий тонкий стек, который не только умеет отдавать больше, чем есть (что по сути ничего особенного), но и потом безболезненно возвращать неиспользуемое отданное обратно в пул свободных ресурсов (дабы реально заниматься экономией пространства), был реализован именно в 3пар. Причем очень-очень давно. У многих (почти у всех) с возвращением отданного по сей день большие-большие проблемы.
Вполне возможно. Можно и наоборот: с нутаникс на vSphere + blades&3PAR :) Можно и по-другому как-то.
Но cтатья-то про AFA и про то, а можно ли уже AFA доверить по-настоящему дорогие данные. При чем тут Нутаникс? Я не улавливаю. В свете того, что нутаникс не имеет ни одного публичного теста/пруфа/бенчмарка хоть от какого-нибудь публичного ресурса (который несет ответственность за опубликованное), а напротив — имеет бегство с бенчмарка по причине плохих результатов (http://www.storagereview.com/why_we_don_t_have_a_nutanix_nx8150_review) дорогих данных ему не видать как своих ушей. И давайте всё-таки закончим про него. Итак бесплатную рекламу товарищам сделали.
Ферма в 10000 ВМ — безусловно нагрузка. Насколько большая зависит прежде всего от того, что внутри ВМ :)
А возвращаясь к нутаникс — ребята из storagereview всего-то хотели посмотреть, что по VMmark получится… Не прожать или как-то еще изнасиловать. Просто VMmark. Получилась печаль. Реально рекомендую почитать. www.storagereview.com/why_we_don_t_have_a_nutanix_nx8150_review
И нету ведь реально в сети ни одного теста нутаникса от сообщества какого-то. Попадаются от разных Джонов Ву или еще каких-то людей со своим сайтом, а от конкретного ресурса (официального лица, которое отвечает за свои слова и действия) — ни одного.
Вот наши CS250 (прямой конкурент нутаниксов как раз), например, со всех сторон облазили на IOmark.org: www.iomark.org/sites/default/files/IOmark-VDI_report_HP-CS-HC250_VDI-HC-151125-a.pdf www.iomark.org/sites/default/files/IOmark-VM_report_HP-CS-HC250_VM-HC-151125-1-a.pdf
Почему о нутаникс НИЧЕГО в сети? Ну кроме провального теста, с которого они убежали, на storagereview.com, который я уже упоминал выше.
Наценка на MLC диск какая у вас, 1000%? И мы тут про 20% емкости рассуждаем?
Про плотность. Пожалуйста, читайте внимательно, прежде чем отвечать. "… когда будет востребована в AFA такая плотность размещения", а не «когда будут востребованы AFA». Начали первыми предлагать — молодцы. Является ли это сейчас преимуществом — не уверен, скорее нет.
Кстати, а не случится ли так, что после пяти скажем лет эксплуатации фактическая емкость проданного 3PAR снизится относительно номинальной? Есть у вас статистика? Через какой период эксплуатации сбойные блоки начинают отъедать «сырое» место, которое вы анонсируете? Какой процент будет отъеден к окончанию срока гарантии? А к половине?
Да какая разница какая наценка? Мы её сделали, мы её убрали в виде скидки. И так любой производитель. Вы так говорите, будто остальные в ноль все работают — за 10 долларов сделали за 10 отдали. Ведь нет же. Ключевой момент — себестоимость гигабайта, а мы за счет того, что на том же носителе выдаем больше емкости имеем преимущество в этом компоненте.
По поводу износа SSD — по 3парам статистика есть, благо массивов подключенных к «отзвону» в наш сервис много. И именно опираясь на статистику во многом, мы SLC поменяли на MLC сначала, потом появился adaptive sparing и из MLC мы сделали cMLC (не по качеству контроллера/флеша, а по объему запасной емкости) и стали предлагать его… В среднем за год эксплуатации в 3парах по нашим данным современный SSD теряет около 1% endurance. И пока у нас нет ни одного «изношенного» SSD. Плюс напомню, что у нас на SSD — безусловная (то есть и на износ тоже) 5-ти летняя гарантия.
2. По поводу QoS… Да нет вовсе. Про соседей — это скорее для шпинделей актуально. Более того, в 3пар вы также можете развести задачи по физически разным накопителям (не вопрос совершенно). Причина наличия у нас QoS на латенси вот в чем скорее. В контексте использования флеша — латенси это ключевой момент (для многих задач, куда более важный чем IOPS), и, так как мы позиционируем линейку как готовую для AFA, мы считаем, что должна быть возможность управлять ключевым параметром для AFA. Вот и всё.
3. То, что запоздали — соглашусь. Долго запрягали, но быстро поехали.
Про фетиши. Хорошо. Тогда к каким фетишам 3пара интерес чисто факультативный? На мой взгляд, там исключительно полезные фетишы.
Интересно. А чьи горизонтально масштабируемые системы подходят для всего? Если аргументированно расскажите, буду рад.
Про тонкий стек — поспорю, тонкий стек это возможность покупать столько, сколько надо сейчас, а выделять столько, сколько планируется к использованию с прицелом на N-лет. Процесс наращивания ресурсов при его использовании превращается просто в закупку дисков без какого-либо ощутимого влияния на работающую среду. Разве нет?
Распределенная система (а речь шла именно о такой) это вовсе не всегда растянутый кластер (в прямом понимании термина кластер). Peer Motion позволяет на ходу (прозрачно для хостов) перемещать данные между 3парами, располагающихся на абсолютно любом количестве площадок, а Peer Persistence — попарно эти площадки собирать именно в кластер (с полноценной репликой данных, прозрачным переключением в случае гибели сайта целиком и т.д.). Для трехплощадочной конфигурации именно по части репликации одного и того же набора данных есть вариант Remote Copy SLD.
Ну и по части последнего абзаца… А разве не 3пар был первым с TP? Разве не 3пар был первым с sub-LUN тирингом? — en.wikipedia.org/wiki/HP_3PAR. По части Peer Motion не так уверен… А кто был первым тут, если знаете? Относительно флеша — что конкретно мы не понимаем? Вы уж давайте аргументированно. Когда кого-то упрекаешь в непонимании — надо показать, где оно. Будем исправляться, если оно действительно так.
Сергей, нет никакой зарубы. У тех. директора Nutanix CEE и CIS Максима Шапошникова (чувствуете уровень), он же shapa, случилось январское обострение. В комментариях к посту о 3пар и рынке AFA систем он, по одному ему известным причинам, рассказал, что у всех сотрудников нутаникса денег хватает на порше, а в HPE — все смешные, попутно выяснилось, что он никогда (давно) не видел в глаза проектов с SAP, очень туманно представляет себе рынок топовых серверов да и серверов вообще. Еще он страстно рассказывал про панику в рядах HPE (видимо, перед Нутаниксом) и про провал продаж 3пар в России, но фактов, к сожалению, так и не привел. Отчего я нарек его пустомелей — на английский манер получается клевый новый ник babbler. Я думаю, если продолжить диалог с ним дальше, он может перестать быть техническим директором Nutanix CEE & CIS. Обо всем этом вы можете почитать в нескончаемых комментариях выше.
А в завершение, для всех слушателей, поклонников, адептов лапши от господина Шапошникова «о величии и могучии» нутаникса без единого пруфа/теста/бенчмарка история о том, как Nutanix уносил ноги с так и не состоявшегося тестирования StorageReview.com (один из самых известных, если не самый известный тестер в мире): www.storagereview.com/why_we_don_t_have_a_nutanix_nx8150_review.
Первый случай бегства в истории к слову.
P.S. Ничего бы этого не было, если бы кое-кто не залез в чужой корпоративный блог и не начал нести откровенную чушь в перемешку с прямыми оскорблениями в адрес сотрудников HPE вместо того, чтобы вести аргументированную дискуссию.
Антон, да не хорошо и не плохо… Просто можно прикинуть подо что в основном используется Nutanix. Касательно больших нагрузок на СХД при VDI — всё зависит от идейного решения и используемого каркаса. Тот же Citrix XenDesktop позволяет реализовать VDI вообще без высокопроизводительной СХД как таковой — за счет Provisioning Server под образы и возможности организовать кэш для десктопов самыми разными способами.
А уж если возвращаться к нутаникс в свете больших нагрузок — это те еще прохиндеи. Ни одного публичного теста и бенчмарка. Была попытка у StorageReview.com (достаточно авторитетный ресурс, согласны?) их потестить, закончилась практически бегством доблестных нутаниксоведов из офиса тестеров вместе с нутаниксом под мышкой (утрирую слегка, конечно), так как тест оказался провальным.
Всем, кто вкушает лапшу господина Шапошникова (он же shapa) рекомендую: www.storagereview.com/why_we_don_t_have_a_nutanix_nx8150_review. Ну и погуглить можно, как на этот пассаж индустрия отреагировала.
Да нет, конечно. Не единым нутаниксом современные ЦОД живы :) Хаотичный диалог между Владом и товарищем из нутаникса был о миграции со сторонних систем. В моем понимании сторонние системы — это далеко не всегда «виртуализованный мир», скорее даже почти никогда, если речь идет о требовательных к производительности и 100% аптайму приложениях.
P.S. Изначально статья про 3par, рынок AFA систем и то, кто реально готов с этого рынка уже сегодня хранить на себе по-настоящему дорогие данные. Так что предлагаю про нутаникс завязать, так как он к теме ни относится ну совсем никак.
1. Ну так наценку же делает каждый вендор (собственно как и любой продавец)… И распоряжается ей. Поэтому у кого изначально себестоимость гигабайта ниже имеет преимущество. Разве нет? А получение большей емкости на том же типе носителя — это прямой путь к более низкой себестоимости. По-моему, очевидно.
Теперь касательно плотности. Так о том и речь, что мы столь высокую плотность размещения флеша начали предлагать значительно раньше остальных (естественно остальные подтянутся/подтягиваются, куда им деваться). AFA уже востребованы по полной программе — в мире флеша уже сейчас продается больше чем шпиндельных дисков (если есть возможность такая — обратитесь к данным IDC, еще кого-нибудь, кто статистику всяческую ведет и аналитику делает, мы не можем их цифры показывать на всеобщее обозрение — они обидятся), мы (Россия) немного отстаем от мирового тренда. И соответственно, кто раньше предлагает лучшее — тот и выигрывает, что с 3паром и происходит последние несколько лет.
2) Ну так опять же, у нас ничего не надо решать более сложным способом — QoS по такому основополагающему параметру для флеша как latency у нас настраиваемый параметр. И это преимущество перед теми, у кого этого нет. Разве нет? У одних есть, у других — нет, но можно придумать, если постараться, но не факт. Что лучше?
3) Тема для отдельной дискуссии — совершенно точно. EVA была на рынке более 10 лет (что-то около того) Это мало? Мне кажется нет. На смену ей пришел 3PAR. Какие технологические фетишы в 3паре сугубо факультативны? Например?
Линейно (правильнее сказать горизонтально) масштабируемые системы — отлично. Есть такие. И у нас в том числе. Но они не подходят для всего. Вы с этим будете спорить? Миграцию данных делать придется всегда (пока по крайней мере), если есть потребность получить возможности новых аппаратных мощностей для своих «старых» данных, так как каждые 5 лет (грубо говоря) меняются формфакторы, пропускные способности шин, появляются новые стандарты и т.д. Почему ушли те же евы? Потому что мощи их контроллерной архитектуры (которая славно прожила десяток лет), стало кардинально (не чуть-чуть, а кардинально, так как мы смотрели с прицелом в будущее) мало для современных объемов данных и требуемых уровней производительности при работе прежде всего с SSD. А переход к новым контроллерам, связанный с заменой процессорной архитектуры и фактически с разработкой микрокода с нуля, требовал существенных вложений. Поэтому у нас появился 3пар, который идейно и, уверен, патентно очень с евой пересекался — мы получили отличный продукт плюс конкурента превратили в союзника. Всё, что вы пишете касательно добавить ресурсов ровно столько, сколько нужно именно сейчас, выполняется 3паром (тонкий стек для того и придуман), касательно растянуть инфраструктуру на две-три-четыре площадки тоже не вопрос (Peer Motion, Peer Persistence вам в помощь), касательно новых фич в старом массиве — без проблем (все 3пары используют один микрокод), пока дело не коснется аппаратного прогресса, и новые фичи окажутся просто бесполезными в старом массиве, как масштабное использование SSD в евах, например. Как-то так.
Смеяться надо над тем, кого нутаникс держит техническими директорами в географических регионах… И еще больше над тем, чем они занимаются. У вас больше работы нет, кроме как на форумах трындеть? Да еще на темы, в которых не разбираетесь. Заканчивайте позорить контору и себя лично «одна из трех самых больших потерь российского программирования».
Потому что мир бывает и невиртуализованным. И довольно часто, если дело касается требовательных к производительности и 100% уровню аптайма приложений. Всё просто.
Антон, ну не будем мы тут саксесс стори выкладывать. Хабр — это не то место. Если реально есть интерес, как у сотрудника интегратора ныне с соответствующим кейсом — welcome, обращайтесь лично ко мне.
А по поводу DP и Veeam. Не передергивайте. Veeam — классный продукт, но до относительно недавнего времени работал только с виртуальными инфраструктурами (на момент вашей работы в Мегафоне, думаю, что железно). А бэкап инфраструктуры такого масштаба — это всё-таки не только виртуальные машины (особенно тогда). DP же тогда умел работать и с физикой плюс с самыми разными окружениями (HP-UX, например) и с VMware-средой (да, хуже чем Veeam, но умел). Это я к тому, что одним Veeam вы бы на тот момент не обошлись никак в плане резервного копирования, если быть до конца честным.
Кстати, о каком функционале речь? Узнаю у коллег, как сейчас обстоят с ним дела у DP.
Отвечу по пунктам.
1. Если физический накопитель один и тот же (а накопители в основной массе на рынке одни и те же), но кто-то выжимает с него 400/800/1600/3200 ГБ, а мы 480/920/1920/3840 ГБ, есть все основания предполагать, что стоимость на гигабайт у нас будет ниже. Вы должны понимать, что вопрос ценообразования на форуме мы обсуждать не готовы (и не один вендор не готов), но технически предпосылку к этому я показал, как мне кажется. Касательно плотности — можете сами прикинуть, как мы выглядим. На сегодня в 2U мы упаковываем 24х3.84ТБ=92.16ТБ флеша как максимум. Это сырая емкость. Что у других? Что-то не приходит никто в голову пока с подобной цифрой. Если ошибаюсь — поправьте, буду рад.
2. Относительно QoS. У нас есть QoS по параметру latency, помимо IOPS и bandwith. Насколько я в курсе (хотя всё быстро меняется, могу где-то отстать) на рынке такое не часто встречается.
3. По поводу готовности — конечно, готовы, другого ответа и не может быть :) Ев в мире продалось очень немало, и в большом количестве заказчиков они работают по сей день (при личном обращении могу хоть по телефону соединить — поговорите). В качестве дальнейшего развития ев было два пути: инвестировать в переписывание микрокода под новую процессорную архитектуру (так как в евах, если верно помню, 32-разрядные процессоры стоят) ввиду требований времени или купить во многом очень близкий по духу 3пар (кто представляет дисковый лэйаут в евах и 3паре, поймет) и с очень интересными техническими дополнениями (уже 64 разрядная архитектура, использование ASIC, отцы тонких технологий и т.д.) Был выбран вариант №2, о чем, я думаю, никто в HPE не жалеет, так как 3пар стал нашим лучшим приобретением (моё личное мнение) в 21-ом веке. Так что зря вы про медленную и печальную смерть ев — два очень близких идейно продукта эволюционировали в один, вот и всё. P.S. С каждым 3паром в комплекте 180-дней бесплатной возможности онлайн миграции с ев (да и с массивов некоторых других вендоров на самом деле) силами функционала Online Import. По истечении 180 дней можно получить ж\это функционал в рамках лицензии Peer Motion.
Заметьте, лично я не привел ни одного слайда от аналитиков. Касательно статей таких же как относительно VDI — для VDI они имеют смысл, так как VDI — это решение, совокупность подходов, продуктов и т. д. Готовых документов на тему очень немного, считай нет, поэтому имеет смысл публикация на тему, суммирующая подходы, продукты. Другое дело 3PAR — который есть законченный продукт с кучей уже готовой сопроводительной литературы.Технический обзор чего конкретно хотелось бы? Тонкого стека, метрокластера, QoS, архитектуры еще чего-то? Более того, на эту тему у HPE огромное количество общедоступных technical white papers (на английском, конечно, не на русском, но это не должно являться преградой для современного IT-шника в моем понимании). Если нужен русскоязычный перевод или выжимка по сути дайте знать — оформим в виде статьи на хабре, а пока привожу ссылки на технические вайтпеперы (не путать с документацией) и базовый концептуальный гайд:
HPE 3PAR StoreServ Concepts Guide — h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04204225
HPE 3PAR StoreServ Architecture — h20195.www2.hp.com/v2/getpdf.aspx/4aa3-3516enw.pdf
HPE 3PAR StoreServ Storage best practices guide — www8.hp.com/h20195/v2/GetDocument.aspx?docname=4AA4-4524ENW
HPE 3PAR Thin Technologies (это о тонком стеке) — h20195.www2.hp.com/V2/GetPDF.aspx%2F4AA3-8987ENW.pdf
HPE 3PAR StoreServ Storage and VMware vSphere 6 best practices — h20195.www2.hp.com/V2/GetPDF.aspx/4AA4-3286ENW.pdf
Disaster-tolerant solutions with HPE 3PAR Remote Copy (это про разные варианты распределенных конфигураций) — h20195.www2.hp.com/v2/GetPDF.aspx%2F4AA3-8318ENW.pdf
HPE 3PAR Priority Optimization (это о QoS) — h20195.www2.hp.com/v2/GetPDF.aspx%2F4AA4-7604ENW.pdf
Adaptive Optimization for HPE 3PAR (это о tiering) — h20195.www2.hp.com/v2/GetPDF.aspx/4AA4-0867ENW.pdf
HPE 3PAR StoreServ Storage: oprimized for flash (про интересные особенности работы с флешем) — h20195.www2.hp.com/V2/GetDocument.aspx?docname=4AA4-7264ENW&cc=us&lc=en
Базовое представление эти документы дают. Повторюсь, если нужно что-то большее — обозначьте тему, сделаем.
Совершенно верно. HANA в виртуальной машине под гипервизором от VMware = vHANA (такая формулировка была неформально использована несколько раз в блогах, статьях и проч.). Спасибо, что не ведетесь на мусоропоток от Нутаникса. Правила для сертификации оборудования под «vHANA» абсолютно те же что и под SAP HANA на VMware. shapa просто с этим не знаком.
Максим ошибается (или умышленно флудит, на что очень похоже). Нет у фуджи таких машин сертифицировнных под HANA. Пока. Два самых больших объема памяти, сертифицированных под HANA на сегодня 8ТБ и 12ТБ предлагает только HPE. Вот тут — global.sap.com/community/ebook/2014-09-02-hana-hardware/enEN/appliances.html#categories=Intel%20Haswell%20EX%20E7. В поле Memory выбрать объем 8 и 12ТБ для фильтрации. Более того, наш Superdome X поддерживает до 24ТБ ОЗУ, аналогов чему нет уже не только в списке под HANA, но и в целом в индустрии навскидку. Если реально есть интерес прицениться — пишите напрямую.
По первому тезису — соглашусь. Логично.
А по второму — нет. У нас были разные приобретения (как и любого другого вендора), как удачные так и не очень впоследствии. Но компания пока жива (и живет уже 77-ой год, если последнее разделение не считать, связанное с совсем разными направлениями, которыми компания занималась), значит не так всё плохо. Ваше право считать иначе.
Обычно что-то берут, не потому что кто-то рассказывает в 10 раз больше, а потому что надо решить какую-то задачу максимально эффективно и качественно. И вряд ли опираясь на форумы. Разве нет? К слову, какой технической информации вам не хватает касательно 3PAR? С удовольствием восполним пробел.
1. По SSD понял, что нужна более детальная статья на тему. Обдумаем.
2. При работе QoS (в любом его виде где угодно) всегда должен быть тот несчастный, за счет которого будут выезжать избранные, если что. Разве нет? Смысл в QoS, если оба участника соревнования будут иметь наивысший приоритет? Предполагаем, что есть третий, четвертый и т.д. участники с более низким уровнем, и тогда ответ на ваш вопрос — именно за них счет будет поддерживаться должный уровень обслуживания первого и второго. Плюс еще раз касательно разделения томов 3пара по разным физическим носителям (без размазывания всех по всем) — это возможно, если реально нужно — пожалуйста. И не будет тогда железно плохого соседа на тех же носителях. Только 100 раз подумать нужно сначала — "+" будет такое разделение или "-", ну а это уже зависит от каждого конкретного случая.
3.
— Про стопы красиво :) Интересно тогда, что же тогда «всё остальное», возвращаясь к возможностям 3пар?
— «Для всего» — безусловно нет. Возможно, технически даже такую систему можно найти, но вот экономически для чего-то подходить она не будет.
— Средний массив сегодня (так называемый midrange, хотя не люблю это понятие) — это более 500 накопителей в плане масштабирования. Учитывая размер накопителя нынешний — это более чем достаточно для 99% организаций с перспективой роста на весь жизненный цикл оборудования. Так что — тонкий стэк плюс грамотные дозакупки накопителей и рост без даунтайма исключительно по мере необходимости обеспечен.
-Не согласен. Работать в многосайтовых конфигурациях 3пар умеет. Тут надо от целей и задач плясать. Что нужно и насколько это целесообразно? И в целом «Растянуть инфраструктуру» как-то нехорошо звучит.
Согласен. Фактически да. Но вот реально работающий тонкий стек, который не только умеет отдавать больше, чем есть (что по сути ничего особенного), но и потом безболезненно возвращать неиспользуемое отданное обратно в пул свободных ресурсов (дабы реально заниматься экономией пространства), был реализован именно в 3пар. Причем очень-очень давно. У многих (почти у всех) с возвращением отданного по сей день большие-большие проблемы.
Но cтатья-то про AFA и про то, а можно ли уже AFA доверить по-настоящему дорогие данные. При чем тут Нутаникс? Я не улавливаю. В свете того, что нутаникс не имеет ни одного публичного теста/пруфа/бенчмарка хоть от какого-нибудь публичного ресурса (который несет ответственность за опубликованное), а напротив — имеет бегство с бенчмарка по причине плохих результатов (http://www.storagereview.com/why_we_don_t_have_a_nutanix_nx8150_review) дорогих данных ему не видать как своих ушей. И давайте всё-таки закончим про него. Итак бесплатную рекламу товарищам сделали.
А возвращаясь к нутаникс — ребята из storagereview всего-то хотели посмотреть, что по VMmark получится… Не прожать или как-то еще изнасиловать. Просто VMmark. Получилась печаль. Реально рекомендую почитать.
www.storagereview.com/why_we_don_t_have_a_nutanix_nx8150_review
И нету ведь реально в сети ни одного теста нутаникса от сообщества какого-то. Попадаются от разных Джонов Ву или еще каких-то людей со своим сайтом, а от конкретного ресурса (официального лица, которое отвечает за свои слова и действия) — ни одного.
Вот наши CS250 (прямой конкурент нутаниксов как раз), например, со всех сторон облазили на IOmark.org:
www.iomark.org/sites/default/files/IOmark-VDI_report_HP-CS-HC250_VDI-HC-151125-a.pdf
www.iomark.org/sites/default/files/IOmark-VM_report_HP-CS-HC250_VM-HC-151125-1-a.pdf
Почему о нутаникс НИЧЕГО в сети? Ну кроме провального теста, с которого они убежали, на storagereview.com, который я уже упоминал выше.
Да какая разница какая наценка? Мы её сделали, мы её убрали в виде скидки. И так любой производитель. Вы так говорите, будто остальные в ноль все работают — за 10 долларов сделали за 10 отдали. Ведь нет же. Ключевой момент — себестоимость гигабайта, а мы за счет того, что на том же носителе выдаем больше емкости имеем преимущество в этом компоненте.
По поводу износа SSD — по 3парам статистика есть, благо массивов подключенных к «отзвону» в наш сервис много. И именно опираясь на статистику во многом, мы SLC поменяли на MLC сначала, потом появился adaptive sparing и из MLC мы сделали cMLC (не по качеству контроллера/флеша, а по объему запасной емкости) и стали предлагать его… В среднем за год эксплуатации в 3парах по нашим данным современный SSD теряет около 1% endurance. И пока у нас нет ни одного «изношенного» SSD. Плюс напомню, что у нас на SSD — безусловная (то есть и на износ тоже) 5-ти летняя гарантия.
2. По поводу QoS… Да нет вовсе. Про соседей — это скорее для шпинделей актуально. Более того, в 3пар вы также можете развести задачи по физически разным накопителям (не вопрос совершенно). Причина наличия у нас QoS на латенси вот в чем скорее. В контексте использования флеша — латенси это ключевой момент (для многих задач, куда более важный чем IOPS), и, так как мы позиционируем линейку как готовую для AFA, мы считаем, что должна быть возможность управлять ключевым параметром для AFA. Вот и всё.
3. То, что запоздали — соглашусь. Долго запрягали, но быстро поехали.
Про фетиши. Хорошо. Тогда к каким фетишам 3пара интерес чисто факультативный? На мой взгляд, там исключительно полезные фетишы.
Интересно. А чьи горизонтально масштабируемые системы подходят для всего? Если аргументированно расскажите, буду рад.
Про тонкий стек — поспорю, тонкий стек это возможность покупать столько, сколько надо сейчас, а выделять столько, сколько планируется к использованию с прицелом на N-лет. Процесс наращивания ресурсов при его использовании превращается просто в закупку дисков без какого-либо ощутимого влияния на работающую среду. Разве нет?
Распределенная система (а речь шла именно о такой) это вовсе не всегда растянутый кластер (в прямом понимании термина кластер). Peer Motion позволяет на ходу (прозрачно для хостов) перемещать данные между 3парами, располагающихся на абсолютно любом количестве площадок, а Peer Persistence — попарно эти площадки собирать именно в кластер (с полноценной репликой данных, прозрачным переключением в случае гибели сайта целиком и т.д.). Для трехплощадочной конфигурации именно по части репликации одного и того же набора данных есть вариант Remote Copy SLD.
Ну и по части последнего абзаца… А разве не 3пар был первым с TP? Разве не 3пар был первым с sub-LUN тирингом? — en.wikipedia.org/wiki/HP_3PAR. По части Peer Motion не так уверен… А кто был первым тут, если знаете? Относительно флеша — что конкретно мы не понимаем? Вы уж давайте аргументированно. Когда кого-то упрекаешь в непонимании — надо показать, где оно. Будем исправляться, если оно действительно так.
А в завершение, для всех слушателей, поклонников, адептов лапши от господина Шапошникова «о величии и могучии» нутаникса без единого пруфа/теста/бенчмарка история о том, как Nutanix уносил ноги с так и не состоявшегося тестирования StorageReview.com (один из самых известных, если не самый известный тестер в мире):
www.storagereview.com/why_we_don_t_have_a_nutanix_nx8150_review.
Первый случай бегства в истории к слову.
P.S. Ничего бы этого не было, если бы кое-кто не залез в чужой корпоративный блог и не начал нести откровенную чушь в перемешку с прямыми оскорблениями в адрес сотрудников HPE вместо того, чтобы вести аргументированную дискуссию.
А уж если возвращаться к нутаникс в свете больших нагрузок — это те еще прохиндеи. Ни одного публичного теста и бенчмарка. Была попытка у StorageReview.com (достаточно авторитетный ресурс, согласны?) их потестить, закончилась практически бегством доблестных нутаниксоведов из офиса тестеров вместе с нутаниксом под мышкой (утрирую слегка, конечно), так как тест оказался провальным.
Всем, кто вкушает лапшу господина Шапошникова (он же shapa) рекомендую:
www.storagereview.com/why_we_don_t_have_a_nutanix_nx8150_review. Ну и погуглить можно, как на этот пассаж индустрия отреагировала.
P.S. Изначально статья про 3par, рынок AFA систем и то, кто реально готов с этого рынка уже сегодня хранить на себе по-настоящему дорогие данные. Так что предлагаю про нутаникс завязать, так как он к теме ни относится ну совсем никак.
Теперь касательно плотности. Так о том и речь, что мы столь высокую плотность размещения флеша начали предлагать значительно раньше остальных (естественно остальные подтянутся/подтягиваются, куда им деваться). AFA уже востребованы по полной программе — в мире флеша уже сейчас продается больше чем шпиндельных дисков (если есть возможность такая — обратитесь к данным IDC, еще кого-нибудь, кто статистику всяческую ведет и аналитику делает, мы не можем их цифры показывать на всеобщее обозрение — они обидятся), мы (Россия) немного отстаем от мирового тренда. И соответственно, кто раньше предлагает лучшее — тот и выигрывает, что с 3паром и происходит последние несколько лет.
2) Ну так опять же, у нас ничего не надо решать более сложным способом — QoS по такому основополагающему параметру для флеша как latency у нас настраиваемый параметр. И это преимущество перед теми, у кого этого нет. Разве нет? У одних есть, у других — нет, но можно придумать, если постараться, но не факт. Что лучше?
3) Тема для отдельной дискуссии — совершенно точно. EVA была на рынке более 10 лет (что-то около того) Это мало? Мне кажется нет. На смену ей пришел 3PAR. Какие технологические фетишы в 3паре сугубо факультативны? Например?
Линейно (правильнее сказать горизонтально) масштабируемые системы — отлично. Есть такие. И у нас в том числе. Но они не подходят для всего. Вы с этим будете спорить? Миграцию данных делать придется всегда (пока по крайней мере), если есть потребность получить возможности новых аппаратных мощностей для своих «старых» данных, так как каждые 5 лет (грубо говоря) меняются формфакторы, пропускные способности шин, появляются новые стандарты и т.д. Почему ушли те же евы? Потому что мощи их контроллерной архитектуры (которая славно прожила десяток лет), стало кардинально (не чуть-чуть, а кардинально, так как мы смотрели с прицелом в будущее) мало для современных объемов данных и требуемых уровней производительности при работе прежде всего с SSD. А переход к новым контроллерам, связанный с заменой процессорной архитектуры и фактически с разработкой микрокода с нуля, требовал существенных вложений. Поэтому у нас появился 3пар, который идейно и, уверен, патентно очень с евой пересекался — мы получили отличный продукт плюс конкурента превратили в союзника. Всё, что вы пишете касательно добавить ресурсов ровно столько, сколько нужно именно сейчас, выполняется 3паром (тонкий стек для того и придуман), касательно растянуть инфраструктуру на две-три-четыре площадки тоже не вопрос (Peer Motion, Peer Persistence вам в помощь), касательно новых фич в старом массиве — без проблем (все 3пары используют один микрокод), пока дело не коснется аппаратного прогресса, и новые фичи окажутся просто бесполезными в старом массиве, как масштабное использование SSD в евах, например. Как-то так.
А по поводу DP и Veeam. Не передергивайте. Veeam — классный продукт, но до относительно недавнего времени работал только с виртуальными инфраструктурами (на момент вашей работы в Мегафоне, думаю, что железно). А бэкап инфраструктуры такого масштаба — это всё-таки не только виртуальные машины (особенно тогда). DP же тогда умел работать и с физикой плюс с самыми разными окружениями (HP-UX, например) и с VMware-средой (да, хуже чем Veeam, но умел). Это я к тому, что одним Veeam вы бы на тот момент не обошлись никак в плане резервного копирования, если быть до конца честным.
Кстати, о каком функционале речь? Узнаю у коллег, как сейчас обстоят с ним дела у DP.
1. Если физический накопитель один и тот же (а накопители в основной массе на рынке одни и те же), но кто-то выжимает с него 400/800/1600/3200 ГБ, а мы 480/920/1920/3840 ГБ, есть все основания предполагать, что стоимость на гигабайт у нас будет ниже. Вы должны понимать, что вопрос ценообразования на форуме мы обсуждать не готовы (и не один вендор не готов), но технически предпосылку к этому я показал, как мне кажется. Касательно плотности — можете сами прикинуть, как мы выглядим. На сегодня в 2U мы упаковываем 24х3.84ТБ=92.16ТБ флеша как максимум. Это сырая емкость. Что у других? Что-то не приходит никто в голову пока с подобной цифрой. Если ошибаюсь — поправьте, буду рад.
2. Относительно QoS. У нас есть QoS по параметру latency, помимо IOPS и bandwith. Насколько я в курсе (хотя всё быстро меняется, могу где-то отстать) на рынке такое не часто встречается.
3. По поводу готовности — конечно, готовы, другого ответа и не может быть :) Ев в мире продалось очень немало, и в большом количестве заказчиков они работают по сей день (при личном обращении могу хоть по телефону соединить — поговорите). В качестве дальнейшего развития ев было два пути: инвестировать в переписывание микрокода под новую процессорную архитектуру (так как в евах, если верно помню, 32-разрядные процессоры стоят) ввиду требований времени или купить во многом очень близкий по духу 3пар (кто представляет дисковый лэйаут в евах и 3паре, поймет) и с очень интересными техническими дополнениями (уже 64 разрядная архитектура, использование ASIC, отцы тонких технологий и т.д.) Был выбран вариант №2, о чем, я думаю, никто в HPE не жалеет, так как 3пар стал нашим лучшим приобретением (моё личное мнение) в 21-ом веке. Так что зря вы про медленную и печальную смерть ев — два очень близких идейно продукта эволюционировали в один, вот и всё. P.S. С каждым 3паром в комплекте 180-дней бесплатной возможности онлайн миграции с ев (да и с массивов некоторых других вендоров на самом деле) силами функционала Online Import. По истечении 180 дней можно получить ж\это функционал в рамках лицензии Peer Motion.
HPE 3PAR StoreServ Concepts Guide — h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04204225
HPE 3PAR StoreServ Architecture — h20195.www2.hp.com/v2/getpdf.aspx/4aa3-3516enw.pdf
HPE 3PAR StoreServ Storage best practices guide — www8.hp.com/h20195/v2/GetDocument.aspx?docname=4AA4-4524ENW
HPE 3PAR Thin Technologies (это о тонком стеке) — h20195.www2.hp.com/V2/GetPDF.aspx%2F4AA3-8987ENW.pdf
HPE 3PAR StoreServ Storage and VMware vSphere 6 best practices — h20195.www2.hp.com/V2/GetPDF.aspx/4AA4-3286ENW.pdf
Disaster-tolerant solutions with HPE 3PAR Remote Copy (это про разные варианты распределенных конфигураций) — h20195.www2.hp.com/v2/GetPDF.aspx%2F4AA3-8318ENW.pdf
HPE 3PAR Priority Optimization (это о QoS) — h20195.www2.hp.com/v2/GetPDF.aspx%2F4AA4-7604ENW.pdf
Adaptive Optimization for HPE 3PAR (это о tiering) — h20195.www2.hp.com/v2/GetPDF.aspx/4AA4-0867ENW.pdf
HPE 3PAR StoreServ Storage: oprimized for flash (про интересные особенности работы с флешем) — h20195.www2.hp.com/V2/GetDocument.aspx?docname=4AA4-7264ENW&cc=us&lc=en
Базовое представление эти документы дают. Повторюсь, если нужно что-то большее — обозначьте тему, сделаем.
А по второму — нет. У нас были разные приобретения (как и любого другого вендора), как удачные так и не очень впоследствии. Но компания пока жива (и живет уже 77-ой год, если последнее разделение не считать, связанное с совсем разными направлениями, которыми компания занималась), значит не так всё плохо. Ваше право считать иначе.
1) Есть этика определенная. Не все (далеко не все заказчики), особенно крупные, согласны на распространение информации о решениях, которые они используют. И не уходите от начального вопроса. Вы заявили про провал продаж 3пар в РФ — где пруф? Пруфа нет — вы peacedoorball, если совсем простым русским языком выражаться.
2) Да что вы тыкаете всё в эту ссыль? Какое отношение она имеет к SAP HANA? Под SAP HANA вы не допущены и не планируетесь судя по роадмапу (так как нос не дорос) и это предмет обсуждения. Роадмап вот тут — service.sap.com/sap/support/sapnotes/public/services/attachment.htm?iv_key=012003146900000849922012&iv_version=0023&alt=2BCE4CB10DF674B172F4F3F7B32A284F493335B2308A770E0E8A3732B172F72ACEF00B32AF4C727172F40E4C34F3482ECD3572ACB0F477F5764D378D70C97472AAD04DF732D6750C09514BCECFCFCE4C8DCF4BCC4DB5F575F4F4F3F57771F571F6F70B01B25D83D4120B0A722092A599504EB16D715E3E00&iv_guid=FB4D9E5DD65D974389EA3BAA8219DCEA. То, что HANA — это основа основ для SAP нынче читать тут — support.sap.com/release-upgrade-maintenance/release-strategy/portfolio/product-strategy.html.
Что еще? Еще вы что-то вещали про космические сервера Fuji с большим количеством памяти, на которых вот по-настоящему работает SAP HANA. Вы будете удивлены, но крупнейшие эпплайнсы для HANA на 8ТБ и 12ТБ ОЗУ предлагает только HPE и никто более. Те самые космические сервера делаем мы — global.sap.com/community/ebook/2014-09-02-hana-hardware/enEN/appliances.html#categories=Intel%20Haswell%20EX%20E7. В поле Memory выбрать объем 8 и 12ТБ для фильтрации. В общем, Максим, не лезьте туда, где не разбираетесь, продавайте свой Нутаникс своим мега-крупным заказчикам в мега-крупные проекты и всего вам хорошего. P.S. Но до Тру Энтерпрайза вам как до луны.