Комментарии 82
Участвую в конкурсе самых внимательных, надеюсь, что много вариантов можно
Nutanix, Nutanix Acropolis, Nutanix KVM.
Последний вариант на уровне кэпа, но, а вдруг?)
Nutanix, Nutanix Acropolis, Nutanix KVM.
Последний вариант на уровне кэпа, но, а вдруг?)
К сожалению на мой взгляд без маркетинга обойтись в статье не удалось (да и где сейчас от наго спрячешься :)?). Пока в основном вижу только размахивание чужими флагами (Google / Facebook / Amazon). Да и по описанию плюс/минус то же самое что и у остальных вендоров, начинающих развивать Software Defined решения.
За сим ждем ждем технических подробностей, что бы понять «в чем уникальность?» :) и «почему всем нужен именно Nutanix?».
За сим ждем ждем технических подробностей, что бы понять «в чем уникальность?» :) и «почему всем нужен именно Nutanix?».
Безусловно, целью конкретной статьи не ставилось сделать deep dive.
Статьи будут, и там уже сделаете выводы.
Насчет плюс-минус — тут можно вопросом на вопрос :)
Назовите любое другое software-defined решение на рынке, не имеющее границ по масштабированию (ввиду использования NoSQL)(VSAN / EVO:RAIL — 32/16 нодов, ввиду того что это просто сетевой RAID), отсутствии точек отказа (сервера блокировок и прочее как например GPFS), так-же как выдерживающее множественные отказы оборудования одновременные, и работающее с HyperV / KVM / ESXi (ceph уже не вариант).
Реально, возможно что-то упустили и про что-то не знаем.
Статьи будут, и там уже сделаете выводы.
Насчет плюс-минус — тут можно вопросом на вопрос :)
Назовите любое другое software-defined решение на рынке, не имеющее границ по масштабированию (ввиду использования NoSQL)(VSAN / EVO:RAIL — 32/16 нодов, ввиду того что это просто сетевой RAID), отсутствии точек отказа (сервера блокировок и прочее как например GPFS), так-же как выдерживающее множественные отказы оборудования одновременные, и работающее с HyperV / KVM / ESXi (ceph уже не вариант).
Реально, возможно что-то упустили и про что-то не знаем.
По общим принципам похожи на ceph :) ну во всяком случае такое ощущение складывается. И да — много флагов, которые пока не ваши)) сделайте инженерное сравнение nutanix, CEPH, openvstorage.
Ну про выдерживание множественных отказов — это мы будем делать выводы после «deep dive» :).
Ну что за практика ответов вопросом на вопрос? Давайте тогда и я попробую так же :).
Решение работает с HyperV / KVM / ESXi одновременно в том числе?
Или как насчет работы не только с гипервизорами, в средах где пока еще не все можно (или не все успели) перенести в виртуализацию?
Как насчет сервисов, для которых производительности одной стандартной ноды Nutanix не достаточно?
Как насчет работы с «разномастными» нодами по составу железа (и вообще с «китайским» самосбором)?
Остальные вопросы оставлю для технических статей ;), вдруг эти вопросы отпадут сами собой :).
Ну что за практика ответов вопросом на вопрос? Давайте тогда и я попробую так же :).
Решение работает с HyperV / KVM / ESXi одновременно в том числе?
Или как насчет работы не только с гипервизорами, в средах где пока еще не все можно (или не все успели) перенести в виртуализацию?
Как насчет сервисов, для которых производительности одной стандартной ноды Nutanix не достаточно?
Как насчет работы с «разномастными» нодами по составу железа (и вообще с «китайским» самосбором)?
Остальные вопросы оставлю для технических статей ;), вдруг эти вопросы отпадут сами собой :).
1) Решение работает с HyperV / KVM / ESXi одновременно в том числе?
Да. Делаются разные кластера но управляется как единое целое (Prism Central)
2) Нет, не работаем — рынок стремительно уходит «в ноль».
3) У нас есть BestPractices для практически любых задач. Базы данных, сервера, VDI и тд
Например, MS Exchange на 1.4 миллиона пользователей — легко.
longwhiteclouds.com/2014/09/28/exchange-best-practices-and-1-4million-mailboxes-on-nutanix-nx-8150/
4) Ноды у нас можно миксовать в кластере совершенно разные (спектр от 1000 до 9000 моделей), работаем на supermicro :)
Да. Делаются разные кластера но управляется как единое целое (Prism Central)
2) Нет, не работаем — рынок стремительно уходит «в ноль».
3) У нас есть BestPractices для практически любых задач. Базы данных, сервера, VDI и тд
Например, MS Exchange на 1.4 миллиона пользователей — легко.
longwhiteclouds.com/2014/09/28/exchange-best-practices-and-1-4million-mailboxes-on-nutanix-nx-8150/
4) Ноды у нас можно миксовать в кластере совершенно разные (спектр от 1000 до 9000 моделей), работаем на supermicro :)
В общем-то, забегая вперед, привожу неполный список функционала (о котором и будет много статей).
…
Поддержка ESXi / KVM / HyperV
Централизованное управление из единой точки множеством кластеров (включая на разных гипервизорах — например ESXi и KVM)
Апгрейд ПО «на лету» без остановки сервиса
Расширение и уменьшение кластера без остановки сервиса (добавление или удаление нодов)
Дедупликация — «на лету» и отложенная (по всему кластеру)
Сжатие — «на лету» и отложенное
Встроенное Disaster Recovery (по любой топологии, включая many to many)
Встроенный metro cluster до 400км (синхронная репликация) с конфигурацией за 15 секунд
Наличие All-Flash нодов
Плотность виртуализации — 400+ VM на 2U стойко-места
100000 / 50000 IOPS на блок 2U (для 1xxx / 3xxx серии)
Встроенный тиринг данных (холодный / горячий уровень)
Поддержка VAAI/VCAI для ESXi и ODX аккселерации для HyperV
Локализация ввода-вывода (данные перемещаются вслед за VM)
RESTful API
Встроенное управление KVM
…
И многое, многое другое ;)
…
Поддержка ESXi / KVM / HyperV
Централизованное управление из единой точки множеством кластеров (включая на разных гипервизорах — например ESXi и KVM)
Апгрейд ПО «на лету» без остановки сервиса
Расширение и уменьшение кластера без остановки сервиса (добавление или удаление нодов)
Дедупликация — «на лету» и отложенная (по всему кластеру)
Сжатие — «на лету» и отложенное
Встроенное Disaster Recovery (по любой топологии, включая many to many)
Встроенный metro cluster до 400км (синхронная репликация) с конфигурацией за 15 секунд
Наличие All-Flash нодов
Плотность виртуализации — 400+ VM на 2U стойко-места
100000 / 50000 IOPS на блок 2U (для 1xxx / 3xxx серии)
Встроенный тиринг данных (холодный / горячий уровень)
Поддержка VAAI/VCAI для ESXi и ODX аккселерации для HyperV
Локализация ввода-вывода (данные перемещаются вслед за VM)
RESTful API
Встроенное управление KVM
…
И многое, многое другое ;)
угадайте как называется наше решение для управления KVM
Какое-нибудь NVM, NDVM, Nut-VM, NKVM или типа того.
Спасибо за введение. Ждем deep dive статей. Nutanix Controller VM (CVM)?
Да, Controller VM
Вся логика 100% вынесена в ПО и не зависит от гипервизора.
Мы считаем это лучшим вариантом, ввиду того что системы которые встраиваются в ядро значительно снижают безопасность и отказоустойчивость.
Как пример — отказ VSAN, встроенной в ядро ESXi, ведет к отказу работы всего хоста. В нашем случае — мы просто перераспределяем ввод-вывод по кластеру, за счет чего можем апгрейдить все ПО «на лету» даже между major версиями (с 3.x на 4.x например).
Насколько я знаю, практически никто так больше не делает.
Вся логика 100% вынесена в ПО и не зависит от гипервизора.
Мы считаем это лучшим вариантом, ввиду того что системы которые встраиваются в ядро значительно снижают безопасность и отказоустойчивость.
Как пример — отказ VSAN, встроенной в ядро ESXi, ведет к отказу работы всего хоста. В нашем случае — мы просто перераспределяем ввод-вывод по кластеру, за счет чего можем апгрейдить все ПО «на лету» даже между major версиями (с 3.x на 4.x например).
Насколько я знаю, практически никто так больше не делает.
Максим, спасибо за интересную статью.
Интересует ваше мнение (как официального представителя) — по какие задачи не следует предлагать Nutanix? С физическими серверами — понятно, интересуют другие варианты. С ходу я смог придумать такие:
1) Развертывание Monster VM (64 vCPU, 1 TB RAM) под задачи какой-нибудь большой-большой СУБД или ERP системы. Конфигурация самой старшей ноды (NX-9040), на текущий момент, слабее лимитов гипервизоров.
2) Требование к дешевому дисковому пространство (например, для хранения бекапов или файлопомойки). В NX-8150 установлено 20 x 1 TB дисков, классическая архитектура с какой-нибудь JBOD полкой или просто дешевым массивом позволяет устанавливать более емкие 3.5" диски с большей плотностью размещения.
3) Малый (сверхмалый :-)) бизнес или бранч-офис. У меня нет под рукой прайс-листа Nutanix, но полагаю, что для небольшого бранч-офиса купить 2-3 обычных сервера и выделенный массив или дисковую полку, подключаемую по SAS, выйдет дешевле, чем купить NX-1020.
4) Использование Infiniband и всевозможных ускорителей (NVIDIA Tesla, Intel Xeon Phi).
Что вы думаете по поводу приведенных выше примеров? Возможно что-то еще?
Интересует ваше мнение (как официального представителя) — по какие задачи не следует предлагать Nutanix? С физическими серверами — понятно, интересуют другие варианты. С ходу я смог придумать такие:
1) Развертывание Monster VM (64 vCPU, 1 TB RAM) под задачи какой-нибудь большой-большой СУБД или ERP системы. Конфигурация самой старшей ноды (NX-9040), на текущий момент, слабее лимитов гипервизоров.
2) Требование к дешевому дисковому пространство (например, для хранения бекапов или файлопомойки). В NX-8150 установлено 20 x 1 TB дисков, классическая архитектура с какой-нибудь JBOD полкой или просто дешевым массивом позволяет устанавливать более емкие 3.5" диски с большей плотностью размещения.
3) Малый (сверхмалый :-)) бизнес или бранч-офис. У меня нет под рукой прайс-листа Nutanix, но полагаю, что для небольшого бранч-офиса купить 2-3 обычных сервера и выделенный массив или дисковую полку, подключаемую по SAS, выйдет дешевле, чем купить NX-1020.
4) Использование Infiniband и всевозможных ускорителей (NVIDIA Tesla, Intel Xeon Phi).
Что вы думаете по поводу приведенных выше примеров? Возможно что-то еще?
1. В данный момент лимит узла Nutanix 512Гб, в конце года будет релиз на базе Dell 720XD, который сейчас уже поддерживает 768Гб.
«Проблема» с объемом памяти для ВМ скорее связана с числом слотов в сервере, а не архитектуре Nutanix.
Много ли серверов 2U, которые имеют более 24 слотов?
При большом числе хостов, можно купить только софт Nutanix и использовать его на серверах например с 4 процессорами и которые будут иметь более 24 слотов — сможете выдать такие параметры для своей Monster VM.
2. Никто и не спорит, что для задач где вообще не требуются вычислительные ресурсы (архив например), Nutanix будет не так хорош в ценовом плане, ведь Nutanix (говоря о коробке, а не только софте внутри нее) это не только SDS, но и Compute.
3. Рекомендованная цена на 1420 около 60к, на минимальную конфигурацию 1320 около 45к. С учетом скидок цена может быть более-менее сравнимая (3-5к за один сервер, 10-15 за СХД), а функционал более богатый. Для SMB может оказаться и не так интересно, для ROBO с возможностью централизованно управлять всеми кластерами и при необходимости организовать DR вполне интересное решение
4. Модель с Nvidia GRID уже есть — 7110, вполне возможно Dell XC в конце года все это сможет обеспечить.
Есть ли хоть один вендор, который гарантирует для работы VDI производительность N виртуальных машин и при недостаточной мощности предоставляет бесплатно дополнительное оборудование?
www.nutanix.com/nutanix-vdi-assurance/
«Проблема» с объемом памяти для ВМ скорее связана с числом слотов в сервере, а не архитектуре Nutanix.
Много ли серверов 2U, которые имеют более 24 слотов?
При большом числе хостов, можно купить только софт Nutanix и использовать его на серверах например с 4 процессорами и которые будут иметь более 24 слотов — сможете выдать такие параметры для своей Monster VM.
2. Никто и не спорит, что для задач где вообще не требуются вычислительные ресурсы (архив например), Nutanix будет не так хорош в ценовом плане, ведь Nutanix (говоря о коробке, а не только софте внутри нее) это не только SDS, но и Compute.
3. Рекомендованная цена на 1420 около 60к, на минимальную конфигурацию 1320 около 45к. С учетом скидок цена может быть более-менее сравнимая (3-5к за один сервер, 10-15 за СХД), а функционал более богатый. Для SMB может оказаться и не так интересно, для ROBO с возможностью централизованно управлять всеми кластерами и при необходимости организовать DR вполне интересное решение
4. Модель с Nvidia GRID уже есть — 7110, вполне возможно Dell XC в конце года все это сможет обеспечить.
Есть ли хоть один вендор, который гарантирует для работы VDI производительность N виртуальных машин и при недостаточной мощности предоставляет бесплатно дополнительное оборудование?
www.nutanix.com/nutanix-vdi-assurance/
1) Если у вас ест конкретный клиент на giantic VM с конкретным проектом, обращайтесь. У нас есть что предложить ;)
Мы не все модели публично показываем. Намек — мы можем работать на любом количество сокетов.
2) NX6020 — 2U, 40TB места
3) Сравнивать три сервера и простую СХД vs Nutanix сложно по функциональности но не цене.
Мы не скрываем особо GPL, 1020 «под ключ» — GPL 40$k. Понятно, что в зависимости от объема проекта бывают существенные оптимизации.
4) Infiniband не нужен уже чаще всего, наши партнеры Arista Networks делают коммутаторы с 320нс задержек.
K1/K2 поддержка полная (7000-я серия), но для научных вычислений они слабо подходят — память не та.
Мы не все модели публично показываем. Намек — мы можем работать на любом количество сокетов.
2) NX6020 — 2U, 40TB места
3) Сравнивать три сервера и простую СХД vs Nutanix сложно по функциональности но не цене.
Мы не скрываем особо GPL, 1020 «под ключ» — GPL 40$k. Понятно, что в зависимости от объема проекта бывают существенные оптимизации.
4) Infiniband не нужен уже чаще всего, наши партнеры Arista Networks делают коммутаторы с 320нс задержек.
K1/K2 поддержка полная (7000-я серия), но для научных вычислений они слабо подходят — память не та.
Окей, полстатьи занимает теория о распределенной файловой системе. Было стойкое ощущение, что вы рассказывали про HDFS. Лично я так и не понял, чем ваш продукт отличается от экосистемы Hadoop — бесплатной, оттестированной и используемой повсеместно.
У хадупа другие задачи и возможности, впрочем, авторы статьи могут сами перечислить различия. Экосистема Nutanix довольно близка к нам (Flops), где-то он существенно нас превосходит (в плане интеграции протоколов хранилищ и локализации данных), где-то наш стек умеет то, что в nutanix не реализовано вообще (SDN, к примеру).
Вы просто упустили главную идею — HDFS это только для Hadoop, наше решение — для виртуализации любых масштабов и всех основных гипервизоров.
Вы не можете поверх HDFS крутить ничего кроме bigdata.
Ну и чисто по скорости — при mapreduce тестах, просто подменой HDFS на NDFS ускорение в разы (это буквально).
Вы не можете поверх HDFS крутить ничего кроме bigdata.
Ну и чисто по скорости — при mapreduce тестах, просто подменой HDFS на NDFS ускорение в разы (это буквально).
Конечно замечательно, что без «маркетингового пустословия», но статья получилась похожая на набор технических фактов не объединённых общим смыслом и идеей. В итоге в голове ничего не отложилось.
Надеюсь статьи с техническими деталями, будут более цельными т.к. продукт ваш интересный, то технических деталей хочется знать побольше.
Надеюсь статьи с техническими деталями, будут более цельными т.к. продукт ваш интересный, то технических деталей хочется знать побольше.
А кто ЦА продукта?
1) Все что выше Small Business
2) Сервис провайдеры
3) Облачные провайдеры
4) Большие интернет проекты (изредка но есть).
2) Сервис провайдеры
3) Облачные провайдеры
4) Большие интернет проекты (изредка но есть).
А что насчет Openstack? Он по сути придуман для того же самого, но его вы как-то обошли стороной.
Придуман-то он придуман, но мы все знаем как реально обстоят дела. IBM насколько я знаю вообще закрыли это направление — слишком много проблем.
Для копроративного применения (энтерпрайза) он не подходит сейчас никоим образом, для сервис провайдеров — с помощью огромных усилий. Даже коммерческие дистрибутивы (Mirantis и т.д.) страшно далеки от народа.
Мы работаем над своей версий Openstack (поверх Acropolis), будет в следующем году (весьма скоро).
Для копроративного применения (энтерпрайза) он не подходит сейчас никоим образом, для сервис провайдеров — с помощью огромных усилий. Даже коммерческие дистрибутивы (Mirantis и т.д.) страшно далеки от народа.
Мы работаем над своей версий Openstack (поверх Acropolis), будет в следующем году (весьма скоро).
Дополнительно, опенстак никоим образом не решает проблему хранения данных — это чисто инструмент да оркестрации и различных *aaS
Cinder — весьма неуклюж, нет поддержки протоколов акселерации СХД (аналога VAAI). Собственно, это основная проблема почему сейчас OpenStack поверх Nutanix неэффективен.
Мы делали патч Cinder и передавали в Mirantis, но позднее решили что сами сделаем свою реализацию Openstack (Mirantis не оказался для нас надежным партнером).
Как итог: в общем-то Nutanix пересекается с OpenStack (и чем дальше тем больше) но закрывает вопросы с самого низа — начиная с оборудования, заканчивая оркестрацией VM (в системе управления KVM).
Cinder — весьма неуклюж, нет поддержки протоколов акселерации СХД (аналога VAAI). Собственно, это основная проблема почему сейчас OpenStack поверх Nutanix неэффективен.
Мы делали патч Cinder и передавали в Mirantis, но позднее решили что сами сделаем свою реализацию Openstack (Mirantis не оказался для нас надежным партнером).
Как итог: в общем-то Nutanix пересекается с OpenStack (и чем дальше тем больше) но закрывает вопросы с самого низа — начиная с оборудования, заканчивая оркестрацией VM (в системе управления KVM).
Хорошая вводная статья, ждем продолжения и подробностей. Как мне кажется, BigData — это довольно специализированная область, где необходима быстрая постоянная обработка большого объема данных «здесь и сейчас». Но иногда стоит вопрос вопрос простого хранения данных. Так что традиционные СХД все равно останутся, но в этой области их потеснят безусловно, ну они и не создавались для BigData.
Также есть ряд практических и общих вопросов/нюансов по тексту:
1) Как решается вопрос резервирования данных на уровне ноды?
2) Три ноды — это уже с учетом fault tolerance? Если да, то получается 2 рабочие ноды и одна «запасная», так? Если нет, то сколько еще нужно standby нод для реальной минимальной конфигурации?
3) Какова максимальная конфигурация вашего кластера (количество нод, суммарная емкость дисков и суммарная полезная емкость)? Какова максимальная полезная емкость одной вашей ноды?
4) На мой взгляд не очень корректное сравнение.
Либо первое и Сколько будет перестраиваться диск на 4TB в RAID6?
или
Либо второе и Сколько будет перестраиваться RAIN на сотни терабайт?
5) Почему же тогда для вычисления тех же самых биткойнов люди делали специальные процессоры или использовали FPGA?
Обычный процессор умеет многое и быстро, если грамотно написан софт. Но все же спец.железка, заточенная под определенную функцию будет быстрее.
6) Звучит как будто вы создали вечный двигатель :) Вы гарантируете, что железо собрано на заводе без технолгических отклонений? Что софт написан без единой ошибки?
Также есть ряд практических и общих вопросов/нюансов по тексту:
1) Как решается вопрос резервирования данных на уровне ноды?
«стартовать с определенного количества ресурсов (в нашем случае — 3 узла / нода / сервера)»
2) Три ноды — это уже с учетом fault tolerance? Если да, то получается 2 рабочие ноды и одна «запасная», так? Если нет, то сколько еще нужно standby нод для реальной минимальной конфигурации?
3) Какова максимальная конфигурация вашего кластера (количество нод, суммарная емкость дисков и суммарная полезная емкость)? Какова максимальная полезная емкость одной вашей ноды?
«после отказа жесткого диска на 4TB, восстановление целостности»+
«Сколько времени будет перестраиваться большой массив (скажем на сотни терабайт) и RAID 6»
4) На мой взгляд не очень корректное сравнение.
Либо первое и Сколько будет перестраиваться диск на 4TB в RAID6?
или
Либо второе и Сколько будет перестраиваться RAIN на сотни терабайт?
«Современные процессоры Intel умеют очень многое, причем очень быстро.»
5) Почему же тогда для вычисления тех же самых биткойнов люди делали специальные процессоры или использовали FPGA?
Обычный процессор умеет многое и быстро, если грамотно написан софт. Но все же спец.железка, заточенная под определенную функцию будет быстрее.
да, SLA 100% реален
6) Звучит как будто вы создали вечный двигатель :) Вы гарантируете, что железо собрано на заводе без технолгических отклонений? Что софт написан без единой ошибки?
Cпасибо за очень интересные вопросы по существу.
«Так что традиционные СХД все равно останутся, но в этой области их потеснят безусловно, ну они и не создавались для BigData.»
наше решение далеко не только для bigdata, но для хранения и работы с совершенно обычными данными. мы просто работаем по принципам bigdata.
1) «Как решается вопрос резервирования данных на уровне ноды?»
На уровне ноды — никак, все диски независимы и каждый просто смонтирован локально по ext4
Данные именно что «размазываются» по кластеру, и всегда есть помимо локальной копии — еще 1 или 2 копия на других нодах кластера
Это node awareness (у нас есть еще block awareness и скоро будет rack awareness).
2) «Три ноды — это уже с учетом fault tolerance?»
Да, это уже отказоустойчивый кластер — любой элемент (диск, или нода целиком) может выйти из строя и датастор будет доступен. Потери данных при этом не будет.
Поэтому наша минимальная конфигурация 1320 идет как раз с 3-я нодами стартово.
3) " Какова максимальная конфигурация вашего кластера"
У нас есть ноды по 6.4TB flash + 20TB SATA, итого 26.4TB RAW места с тирингом.
Именно на них например запускают очень крупные базы данных.
Полезное место соответственно при RF2 будет около 12.5TB на каждую ноду.
www.nutanix.com/2014/08/13/nx-8000-series/
Максимальной конфигурации — лимита не существует, Cassandra — есть в мире инсталляции на тысячи серверов.
В реальных условиях я видел кластера на сотни серверов на Nutanix, далее просто начинают делить на части по принципу «не класть все яйца в одну корзину».
4) «Либо первое и Сколько будет перестраиваться диск на 4TB в RAID6?
или
Либо второе и Сколько будет перестраиваться RAIN на сотни терабайт?»
Если честно, не понял некорректности.
Пример приведенный (там есть ссылка) — 32 ноды 6020, каждая из которых 20TB. Итого — 640 терабайт.
Берем RAIN решение на 640TB и берем RAID6 на 640TB (говорим о RAW).
Сравниваем время ребилда после вылета одного диска на 4TB.
Оно будет кардинально отличаться, на такой размер массива может быть около суток для RAID системы.
5) «люди делали специальные процессоры»
Это (ускорение обсчета биткоинов) сугубо специфичная задача, при том что современная система хранения данных — чрезвычайно широкий спектр решаемых вопросов. Просто физически нереально сделать ускорители для акселерации этого спектра задач.
В добавок, если бы Intel сделал аппаратную поддержку «обсчета биткоинов» в процессоре — FPGA был бы не нужен.
Как пример, есть компания которая является неким псевдоконкурентом нам (Simplivity).
Они сделали плату аппаратную для сжатия и дедупликации.
Cухой итог — простой IOmeter тест заваливает I/O запросами эту плату и все просто «валится», потому что уходит в ПО.
6) «Звучит как будто вы создали вечный двигатель :) Вы гарантируете, что железо собрано на заводе без технолгических отклонений? Что софт написан без единой ошибки?»
Мы сделаны так (акцентировано в статье), что можем выдерживать множественные одновременные отказы оборудования.
Например, в случае с Block Awareness и 3+ блока в кластере, целиком один блок (4 нода). Если у вас есть Metro Cluster — то 8 нод одновременно (из 24).
По поводу ПО — ошибки безусловно бывают, но тут как раз вопрос правильного резервирования.
У нас поддерживается DR (Disater Recovery) на множественные датацентры (many to many).
Опыт показывает, что SLA сильно больше 5 девяток, при правильном дизайне архитектуры, в нашем случае вполне возможен (если буквально — не было ни одного отказа системы и потерь данных) — мы не скрываем, что один из самых крупных клиентов компании это правительство и военные США (включая ВВС и многие другие подразделения c названиями из 3 букв ;) ).
Собственно, это одна из причин почему на рынки Европы начали выходить достаточно поздно.
«Так что традиционные СХД все равно останутся, но в этой области их потеснят безусловно, ну они и не создавались для BigData.»
наше решение далеко не только для bigdata, но для хранения и работы с совершенно обычными данными. мы просто работаем по принципам bigdata.
1) «Как решается вопрос резервирования данных на уровне ноды?»
На уровне ноды — никак, все диски независимы и каждый просто смонтирован локально по ext4
Данные именно что «размазываются» по кластеру, и всегда есть помимо локальной копии — еще 1 или 2 копия на других нодах кластера
Это node awareness (у нас есть еще block awareness и скоро будет rack awareness).
2) «Три ноды — это уже с учетом fault tolerance?»
Да, это уже отказоустойчивый кластер — любой элемент (диск, или нода целиком) может выйти из строя и датастор будет доступен. Потери данных при этом не будет.
Поэтому наша минимальная конфигурация 1320 идет как раз с 3-я нодами стартово.
3) " Какова максимальная конфигурация вашего кластера"
У нас есть ноды по 6.4TB flash + 20TB SATA, итого 26.4TB RAW места с тирингом.
Именно на них например запускают очень крупные базы данных.
Полезное место соответственно при RF2 будет около 12.5TB на каждую ноду.
www.nutanix.com/2014/08/13/nx-8000-series/
Максимальной конфигурации — лимита не существует, Cassandra — есть в мире инсталляции на тысячи серверов.
В реальных условиях я видел кластера на сотни серверов на Nutanix, далее просто начинают делить на части по принципу «не класть все яйца в одну корзину».
4) «Либо первое и Сколько будет перестраиваться диск на 4TB в RAID6?
или
Либо второе и Сколько будет перестраиваться RAIN на сотни терабайт?»
Если честно, не понял некорректности.
Пример приведенный (там есть ссылка) — 32 ноды 6020, каждая из которых 20TB. Итого — 640 терабайт.
Берем RAIN решение на 640TB и берем RAID6 на 640TB (говорим о RAW).
Сравниваем время ребилда после вылета одного диска на 4TB.
Оно будет кардинально отличаться, на такой размер массива может быть около суток для RAID системы.
5) «люди делали специальные процессоры»
Это (ускорение обсчета биткоинов) сугубо специфичная задача, при том что современная система хранения данных — чрезвычайно широкий спектр решаемых вопросов. Просто физически нереально сделать ускорители для акселерации этого спектра задач.
В добавок, если бы Intel сделал аппаратную поддержку «обсчета биткоинов» в процессоре — FPGA был бы не нужен.
Как пример, есть компания которая является неким псевдоконкурентом нам (Simplivity).
Они сделали плату аппаратную для сжатия и дедупликации.
Cухой итог — простой IOmeter тест заваливает I/O запросами эту плату и все просто «валится», потому что уходит в ПО.
6) «Звучит как будто вы создали вечный двигатель :) Вы гарантируете, что железо собрано на заводе без технолгических отклонений? Что софт написан без единой ошибки?»
Мы сделаны так (акцентировано в статье), что можем выдерживать множественные одновременные отказы оборудования.
Например, в случае с Block Awareness и 3+ блока в кластере, целиком один блок (4 нода). Если у вас есть Metro Cluster — то 8 нод одновременно (из 24).
По поводу ПО — ошибки безусловно бывают, но тут как раз вопрос правильного резервирования.
У нас поддерживается DR (Disater Recovery) на множественные датацентры (many to many).
Опыт показывает, что SLA сильно больше 5 девяток, при правильном дизайне архитектуры, в нашем случае вполне возможен (если буквально — не было ни одного отказа системы и потерь данных) — мы не скрываем, что один из самых крупных клиентов компании это правительство и военные США (включая ВВС и многие другие подразделения c названиями из 3 букв ;) ).
Собственно, это одна из причин почему на рынки Европы начали выходить достаточно поздно.
Мы сделаны так (акцентировано в статье), что можем выдерживать множественные одновременные отказы оборудования.
Отказы вида «умер диск», «выдернули питание» и так далее — скучные отказы, от них слишком легко защититься. И конечно маркетологи от вендоров всеми силами стараются закрыть глаза на то, что бывают и другие фейлы, при которых сервис встает колом, но все компоненты при этом вроде как пингуются…
Напомнить, что и у многократно восхваляемого в статье гугла случались фейлы, причем с потерей данных, причем сразу на много процентов пользователей? :)
Amazon вообще относится к так называемым "udp cloud" (нравится мне этот термин). Его инфраструктура не является надежной. Это не является проблемой, если сбои нормально обрабатываются вышестоящим приложением.
А Nutanix — «udp хранилище»? Традиционные массивы — скорее «tcp».
Если коротко, то на 2U cтойко-места (Nutanix NX-3461 например) вы «выжимаем» около 120.000 IOPS на чтение, и более 50.000 IOPS на запись.
Есть, кстати, такой производитель флеш-массивов как Violin, там цифры почти на порядок выше в пересчете на юнит.
Тут стоит упомянуть 2 аспекта.
Первое — именно что Violin — это flash-массив. То есть, если не ошибаюсь, какое-то сравнение может быть с 9000й серией Nutanix. Максим, есть ли данные хотя бы в тех же iops-попугаях по 9000й серии?
Ну и второе — «немного» разные цены. Нолик к цене Nutanix 900й серии просто смело рисуем (в реальности больше, а на поддержку у Violin вообще конские цены), хотя да, вопрос — кому что надо — денег потратить (такое бывает) или работу работать :)
Первое — именно что Violin — это flash-массив. То есть, если не ошибаюсь, какое-то сравнение может быть с 9000й серией Nutanix. Максим, есть ли данные хотя бы в тех же iops-попугаях по 9000й серии?
Ну и второе — «немного» разные цены. Нолик к цене Nutanix 900й серии просто смело рисуем (в реальности больше, а на поддержку у Violin вообще конские цены), хотя да, вопрос — кому что надо — денег потратить (такое бывает) или работу работать :)
«Отказы вида «умер диск», «выдернули питание» и так далее»
согласен.
поэтому мы держим для sync кластера отказ 8 нодов (вместе со всеми дисками) из 24-х, предусмотрели множественный DR и прочее. да, это решается как раз не надежностью оборудования но множеством уровней резервирования данных.
" многократно восхваляемого в статье гугла случались фейлы"
случались, ибо они первопроходцы собственно. любые изменения в подходе к архитектурам поначалу влекут за собой сбор шишек и граблей. но это было давно и уже можно сказать что «неправда» :)
Идеальный термин «udp cloud». Cпасибо, будем использовать. Ибо это про нас.
«Его инфраструктура не является надежной. » мы являемся именно таким решением, ибо у нас вся логика на app уровне (еще раз — 100% программное решение).
Прямо сейчас идет тендер Росатома ( zakupki.rosatom.ru/1410020528906 ) на Nutanix + Arista, где коллеги сообщили что очень устали от безумных цен на Viloin. Который при этом является просто очень быстрой традиционной RAID-флеш коробкой.
В пересчете IOPS / $$$ мы кардинально выигрываем у Violin, тем более что помимо СХД / SSD вы получаете сразу очень много мощностей (процессоры и память).
Именно поэтому Nutanix оценочная стоимость сейчас около 2-х миллиардов долларов и бурно растет, а Violin — на грани банкротства.
blogs.barrons.com/techtraderdaily/2014/04/17/violin-after-58-collapse-new-chief-denuccio-has-high-hopes-for-enterprise-growth-besting-emc/
согласен.
поэтому мы держим для sync кластера отказ 8 нодов (вместе со всеми дисками) из 24-х, предусмотрели множественный DR и прочее. да, это решается как раз не надежностью оборудования но множеством уровней резервирования данных.
" многократно восхваляемого в статье гугла случались фейлы"
случались, ибо они первопроходцы собственно. любые изменения в подходе к архитектурам поначалу влекут за собой сбор шишек и граблей. но это было давно и уже можно сказать что «неправда» :)
Идеальный термин «udp cloud». Cпасибо, будем использовать. Ибо это про нас.
«Его инфраструктура не является надежной. » мы являемся именно таким решением, ибо у нас вся логика на app уровне (еще раз — 100% программное решение).
Прямо сейчас идет тендер Росатома ( zakupki.rosatom.ru/1410020528906 ) на Nutanix + Arista, где коллеги сообщили что очень устали от безумных цен на Viloin. Который при этом является просто очень быстрой традиционной RAID-флеш коробкой.
В пересчете IOPS / $$$ мы кардинально выигрываем у Violin, тем более что помимо СХД / SSD вы получаете сразу очень много мощностей (процессоры и память).
Именно поэтому Nutanix оценочная стоимость сейчас около 2-х миллиардов долларов и бурно растет, а Violin — на грани банкротства.
blogs.barrons.com/techtraderdaily/2014/04/17/violin-after-58-collapse-new-chief-denuccio-has-high-hopes-for-enterprise-growth-besting-emc/
поэтому мы держим для sync кластера отказ 8 нодов (вместе со всеми дисками) из 24-х, предусмотрели множественный DR и прочее
А всякие сценарии split brain, рассинхронизации, торможения всего кластера из-за торможения (но не полного падения) одной ноды и прочее? С участием (или по вине) багов в вашем ПО?
случались, ибо они первопроходцы собственно
Ну последний фейл гмейла был не так давно…
мы являемся именно таким решением, ибо у нас вся логика на app уровне (еще раз — 100% программное решение).
Нет-нет. Для того же приложения VMWare вы — черный ящик, инфраструктура. Наравне с любым классическим массивом.
«А всякие сценарии split brain, рассинхронизации, торможения всего кластера из-за торможения (но не полного падения) одной ноды и прочее?»
Еще раз — доступно multi-site DR. Резервирование одного ДЦ на два других ДЦ например может быть, причем на разных версиях железа и ПО (чтобы как раз обезопаситься от проблем в новом ПО)
«Ну последний фейл гмейла был не так давно…» если у них не было доп. копий данных, то вы их можете спокойно делать — столько, сколько нужно. metro cluster, DR, snapshots (локальные и удаленные) и тд.
Поэтому и нужны грамотные архитекторы. Nutanix — это просто очень мощный и один самых надежных на сегодня инструментов, но головы человека не отменяет :)
«Для того же приложения VMWare вы — черный ящик, инфраструктура»
А причем тут VMware? Мы кстати с vcenter не работаем вообще, а работаем с SDK каждого хоста напрямую. поэтому от проблем vCenter защищены кстати.
Да и не то чтобы «черный» — VAAI / VCAI поддержка.
Так вот — мы сделали свое KVM управление, которое для многих вообще заменит ESXi / vCenter. Там мы вообще имеем 100% контроль над происходящим.
Презентация решения будет сделана на HighLoad, можно приходить. Но в принципе суть уже описана тут:
www.highload.ru/2014/abstracts/1645.html
Еще раз — доступно multi-site DR. Резервирование одного ДЦ на два других ДЦ например может быть, причем на разных версиях железа и ПО (чтобы как раз обезопаситься от проблем в новом ПО)
«Ну последний фейл гмейла был не так давно…» если у них не было доп. копий данных, то вы их можете спокойно делать — столько, сколько нужно. metro cluster, DR, snapshots (локальные и удаленные) и тд.
Поэтому и нужны грамотные архитекторы. Nutanix — это просто очень мощный и один самых надежных на сегодня инструментов, но головы человека не отменяет :)
«Для того же приложения VMWare вы — черный ящик, инфраструктура»
А причем тут VMware? Мы кстати с vcenter не работаем вообще, а работаем с SDK каждого хоста напрямую. поэтому от проблем vCenter защищены кстати.
Да и не то чтобы «черный» — VAAI / VCAI поддержка.
Так вот — мы сделали свое KVM управление, которое для многих вообще заменит ESXi / vCenter. Там мы вообще имеем 100% контроль над происходящим.
Презентация решения будет сделана на HighLoad, можно приходить. Но в принципе суть уже описана тут:
www.highload.ru/2014/abstracts/1645.html
доступно multi-site DR
Безумно дорого в плане каналов и все равно наверняка без гарантии консистентности (вы же не волшебники?). Хотя это в любом случае надо делать. Но стараться свести вероятность применения сценария DR поближе к нулю.
если у них не было доп. копий данных, то вы их можете спокойно делать — столько, сколько нужно. metro cluster, DR, snapshots (локальные и удаленные) и тд.
Они данные с лент восстанавливали… И я уверен, что у них умные люди тоже много чего наворотили. Но отказ был именно со стороны подсистемы хранения данных.
а работаем с SDK каждого хоста напрямую.
Ну то есть грубо говоря виртуалка все равно монтирует в качестве диска LUN, который хранится на ваших системах. Общение вроде по NFS происходит? Ничего особо не меняется.
поэтому от проблем vCenter защищены кстати.
Не припомню у коллег ни одной связанной с vCenter проблемы. VMWare вообще любят за стабильность.
мы сделали свое KVM управление
Когда я последний раз проверял, KVM по функционалу существенно отставал от vSphere.
«все равно наверняка без гарантии консистентности»
Metro Cluster — по опеределению дает гарантии консистентности, ввиду синхронности. Да, больше никто из вендоров не умеет делать метро кластера на 400км.
Наш DR (асинхронная репликация) — поддерживает consistency groups: группы VM которые надо снимать снапшоты одновременно. Мы не работаем per-LUN, у нас нет этого, защита ведется именно per-VM.
По поводу каналов (помимо того что они стоят уже смешных денег — 10 гигабит из Мск во Франкфурт можно взять за 10-15$k) — мы передаем дельты снапшотов в сжатом виде, что является крайне эффективным способом.
«был именно со стороны подсистемы хранения данных.»
поэтому надо делать DR / снапшоты, причем не на ленту. Никто не идеализирует гугл, очень большая компания работающая на B2C рынок. Но основные принципы именно они продвигают.
Мы заточены под B2B и для нас вопрос сохранности данных — ключевой.
«ни одной связанной с vCenter проблемы.»
Значит ваши коллеги эксплуатируют небольшие кластера.
На сегодняшний день, vCenter имеет множество очень существенных ограничений — максимальный размер кластера 32 нода (что в общем-то уже даже не смешно), ограничение по максимальному количеству VM и прочее.
Корни проблемы — используются традиционные SQL базы для хранения конфигурации VM / событий и прочего.
Кстати, совсем недавно была критическая бага в очередном апдейте ESXi, которая затронула сотни тысяч инсталляций по всему миру. Фактически, для многих это было катастрофичной проблемой.
Фиксили ее около 2-х (!) месяцев.
kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2076392
…
Гхм. KVM == ESXi, Acropolis == vShpere
Так что мне не очень ясно как можно сравнивать гипервизор с системой управления оным :)
И да, многие вещи мы уже делаем намного лучше чем vShpere (тот же DR который заменяет SRM), а многие — вообще уникальны (как Metro Cluster на 400км)
Metro Cluster — по опеределению дает гарантии консистентности, ввиду синхронности. Да, больше никто из вендоров не умеет делать метро кластера на 400км.
Наш DR (асинхронная репликация) — поддерживает consistency groups: группы VM которые надо снимать снапшоты одновременно. Мы не работаем per-LUN, у нас нет этого, защита ведется именно per-VM.
По поводу каналов (помимо того что они стоят уже смешных денег — 10 гигабит из Мск во Франкфурт можно взять за 10-15$k) — мы передаем дельты снапшотов в сжатом виде, что является крайне эффективным способом.
«был именно со стороны подсистемы хранения данных.»
поэтому надо делать DR / снапшоты, причем не на ленту. Никто не идеализирует гугл, очень большая компания работающая на B2C рынок. Но основные принципы именно они продвигают.
Мы заточены под B2B и для нас вопрос сохранности данных — ключевой.
«ни одной связанной с vCenter проблемы.»
Значит ваши коллеги эксплуатируют небольшие кластера.
На сегодняшний день, vCenter имеет множество очень существенных ограничений — максимальный размер кластера 32 нода (что в общем-то уже даже не смешно), ограничение по максимальному количеству VM и прочее.
Корни проблемы — используются традиционные SQL базы для хранения конфигурации VM / событий и прочего.
Кстати, совсем недавно была критическая бага в очередном апдейте ESXi, которая затронула сотни тысяч инсталляций по всему миру. Фактически, для многих это было катастрофичной проблемой.
Фиксили ее около 2-х (!) месяцев.
kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2076392
…
Гхм. KVM == ESXi, Acropolis == vShpere
Так что мне не очень ясно как можно сравнивать гипервизор с системой управления оным :)
И да, многие вещи мы уже делаем намного лучше чем vShpere (тот же DR который заменяет SRM), а многие — вообще уникальны (как Metro Cluster на 400км)
Metro Cluster — по опеределению дает гарантии консистентности, ввиду синхронности.
Ну тогда ждем описания, как оно работает.
мы передаем дельты снапшотов в сжатом виде, что является крайне эффективным способом.
Но на канал все равно будет обрушиваться нагрузка, сравнимая с нагрузкой на запись на диски.
А то, что было записано после снятия снапшота и до снятия следующего снапшота, безвозвратно потеряно в случае сбоя?
Значит ваши коллеги эксплуатируют небольшие кластера.
Вроде сотни хостов суммарно… Не слишком много, но и не мало.
vCenter имеет множество очень существенных ограничений — максимальный размер кластера 32 нода (что в общем-то уже даже не смешно), ограничение по максимальному количеству VM и прочее.
А куда вам сильно больше?
К одному vcenter'у можно и тыщу хостов подключить.
KVM == ESXi, Acropolis == vShpere
ESXi как бы не существует. Теперь он vSphere Hypervisor вроде бы. А vCenter управляет ими.
многие вещи мы уже делаем намного лучше чем vShpere (тот же DR который заменяет SRM), а многие — вообще уникальны (как Metro Cluster на 400км)
Что-то лучше. Многое хуже. Ну и конечно же нужны детали. Можно заявить, что можете делать репликацию и на другое полушарие — но работает ли это на практике?
«обрушиваться нагрузка, сравнимая с нагрузкой на запись на диски.»
Я надеюсь есть понимание того что такое дельта снапшота? раз в 15 минут скажем снимается снапшот очередной, причем только изменившиеся данные на VM. далее — передается только это изменившаяся часть, которая еще и сжимается на лету.
Объем передаваемых данных в сумме — кардинально ниже посравнению с «нагрузкой на запись на диск».
Если говорить про синхронную репликацию — да, там выше требования, но опять-же каналы связи нынче крайне дешевы.
Мы работаем с задержками до 5 миллисекунд, что позволяет говорить о ~400км.
«К одному vcenter'у можно и тыщу хостов подключить.»
Нет, это неверно. Точнее подключить можно, работать это нормально не будет. Проблема именно в том что начинаются проблемы с централизованными SQL базами. Да, можно наворотить Oracle RAC кластер — но это будет стоить как космолет. И требует серьезного обслуживания.
Простой момент — если начать дергать метрики VM нужные из vcenter, он просто падает, в случае хотя-бы нескольких тысяч VM. Именно поэтому мы берем всю информацию напрямую из SDK хостов.
«ESXi как бы не существует. „
Как бы это ошибочное заявление :)
“Free VMware vSphere Hypervisor, Free Virtualization (ESXi…
www.vmware.com/uk/products/vsphere-hypervisor
Get started with virtualization for free with the VMware vSphere Hypervisor ( based on ESXi), a bare-metal hypervisor.»
«можете делать репликацию и на другое полушарие „
Работает, причем прекрасно. Собственно на VMworld показывали репликацию между Брюсселем и Калифорнией (Сан-Хозе). Собственно, я не вижу причин никаких почему это не должно работать.
Я надеюсь есть понимание того что такое дельта снапшота? раз в 15 минут скажем снимается снапшот очередной, причем только изменившиеся данные на VM. далее — передается только это изменившаяся часть, которая еще и сжимается на лету.
Объем передаваемых данных в сумме — кардинально ниже посравнению с «нагрузкой на запись на диск».
Если говорить про синхронную репликацию — да, там выше требования, но опять-же каналы связи нынче крайне дешевы.
Мы работаем с задержками до 5 миллисекунд, что позволяет говорить о ~400км.
«К одному vcenter'у можно и тыщу хостов подключить.»
Нет, это неверно. Точнее подключить можно, работать это нормально не будет. Проблема именно в том что начинаются проблемы с централизованными SQL базами. Да, можно наворотить Oracle RAC кластер — но это будет стоить как космолет. И требует серьезного обслуживания.
Простой момент — если начать дергать метрики VM нужные из vcenter, он просто падает, в случае хотя-бы нескольких тысяч VM. Именно поэтому мы берем всю информацию напрямую из SDK хостов.
«ESXi как бы не существует. „
Как бы это ошибочное заявление :)
“Free VMware vSphere Hypervisor, Free Virtualization (ESXi…
www.vmware.com/uk/products/vsphere-hypervisor
Get started with virtualization for free with the VMware vSphere Hypervisor ( based on ESXi), a bare-metal hypervisor.»
«можете делать репликацию и на другое полушарие „
Работает, причем прекрасно. Собственно на VMworld показывали репликацию между Брюсселем и Калифорнией (Сан-Хозе). Собственно, я не вижу причин никаких почему это не должно работать.
Get started with virtualization for free with the VMware vSphere Hypervisor ( based on ESXi), a bare-metal hypervisor.»
Так сейчас маркетологи переименовали ESX в vSphere Hypervisor. Но пока, чтобы народ совсем с ума не сошел, упоминают, что это одно и то же.
Собственно на VMworld показывали репликацию между Брюсселем и Калифорнией (Сан-Хозе).
Так речь про синхронную репликацию? Если, допустим, мы говорим про процессинг, то потеря 14 минут транзакций — жопа эпических размеров.
«переименовали ESX в vSphere Hypervisor»
Не видел объявлений о переименовании, речь идет о том что Sphere Hypervisor базируется на ESXi
«Так речь про синхронную репликацию?»
Речь и про то и другое. В зависимости от задач.
Для процессинга делается синхронный кластер, что логично. Там RTO — секунды. Между Брюсселем и Амстердамом работает отлично (у нас там очень крупные банки-клиенты), расстояние около 300км.
Для множества других задач — хватает RTO 15 минут и даже выше (очень часто вижу требования 30 минут или час).
Не видел объявлений о переименовании, речь идет о том что Sphere Hypervisor базируется на ESXi
«Так речь про синхронную репликацию?»
Речь и про то и другое. В зависимости от задач.
Для процессинга делается синхронный кластер, что логично. Там RTO — секунды. Между Брюсселем и Амстердамом работает отлично (у нас там очень крупные банки-клиенты), расстояние около 300км.
Для множества других задач — хватает RTO 15 минут и даже выше (очень часто вижу требования 30 минут или час).
Ну и заодно:
Гонять реплики СХД через интернет-канал? Под такое и провайдерские L2 каналы не очень годятся, нужна темная оптика или хотя бы лямбда DWDM. И возникают вопросы вроде «как вы переживаете потери, разрывы соединений между кластерами и прочее?».
А волокно длиной 400км — довольно дорого.
Примеры гуглов, которые, возможно, гоняют реплики через интернет, приводить не надо. Кто знает, на что они договорились с провайдерами? У нас доступность любого интернет-канала и на две девятки не тянет, а уж периодические проседания в разных направлениях — норма. Хотя возможно, что те, кто не мониторят это, со мной не согласятся.
10 гигабит из Мск во Франкфурт можно взять за 10-15$k
Гонять реплики СХД через интернет-канал? Под такое и провайдерские L2 каналы не очень годятся, нужна темная оптика или хотя бы лямбда DWDM. И возникают вопросы вроде «как вы переживаете потери, разрывы соединений между кластерами и прочее?».
А волокно длиной 400км — довольно дорого.
Примеры гуглов, которые, возможно, гоняют реплики через интернет, приводить не надо. Кто знает, на что они договорились с провайдерами? У нас доступность любого интернет-канала и на две девятки не тянет, а уж периодические проседания в разных направлениях — норма. Хотя возможно, что те, кто не мониторят это, со мной не согласятся.
Нам не нужен L2.
Нам хватает L3. И да, асинхронная репликация прекрасно работает и в первую очередь затачивалась на рынок (госструктур || военных) США. Репликация между Майями и NY — совершенно нормальное дело, а это тысячи км.
Доступность каналов — не стоит сгущать краски, у RETN например все прекрасно работает без проблем годами.
Ну и никто не мешает (ввиду того что нам L3 хватает) использовать несколько каналов одновременно.
И да, репликация работает даже через ssh туннель и http прокси. (!).
Нам хватает L3. И да, асинхронная репликация прекрасно работает и в первую очередь затачивалась на рынок (госструктур || военных) США. Репликация между Майями и NY — совершенно нормальное дело, а это тысячи км.
Доступность каналов — не стоит сгущать краски, у RETN например все прекрасно работает без проблем годами.
Ну и никто не мешает (ввиду того что нам L3 хватает) использовать несколько каналов одновременно.
И да, репликация работает даже через ssh туннель и http прокси. (!).
у RETN например все прекрасно работает без проблем годами.
Ну а я сейчас пытаюсь доказать провайдеру в районе Кавказа, что у него проблемы на магистрали — у меня несколько десятков точек у разных провайдеров имеют около 5% потерь до наших AS, и во всех случаях трафик ходит через того несчастного провайдера. Бои идут с переменным успехом. Никто никому ничего не обязан. Скоро останется крайний вариант — в свои анонсы коммьюнити насовать, чтобы пойти в обход того провайдера. Но нет гарантии, что это поможет.
Вот с L2VPN/L3VPN каналами проще, там если есть проблема — сразу есть на кого катить бочку, и проблема быстро устраняется.
Ну и никто не мешает (ввиду того что нам L3 хватает) использовать несколько каналов одновременно.
Конечно ничто не мешает. Но надо очень тщательно их мониторить и очень быстро их фейловерить. Тут уже нужен тот самый «sub-second convergence», а низя, если будут сравнительно небольшие потери, те самые 5-10% к примеру, которые практически прибьют TCP обмен, но при этом не приведут к стабильной потере кипалайвов чего угодно.
Небольшие потери нам не сильно страшны — это L3 / tcp, будут просто ретрансмиты.
Ну и надо использовать правильные технологии — типа www.talari.com
Там все мониторится и отрабатывает на полном автомате, прозрачно для клиента.
Ну и надо использовать правильные технологии — типа www.talari.com
Там все мониторится и отрабатывает на полном автомате, прозрачно для клиента.
Небольшие потери нам не сильно страшны — это L3 / tcp, будут просто ретрансмиты.
0,1% очень сильно просаживает скорость, в несколько раз (проверено эмпирически).
5% может почти парализовать обмен.
Ну и надо использовать правильные технологии — типа www.talari.com
Смотрим топовую железку:
T5000H: designed for large data centers and call centers, T5000H supports aggregation of WAN bandwidth up to 3 Gbps uplink/3 Gbps downlink (3 Gbps full-duplex)
Вопросы?
Нет, есть, разумеется, тот же Cisco ASR1k с PfRv3, где обещают обнаружение brownout за 2 секунды по анализу data plane трафика, и где скорости повыше будут… Но не тестировал, ничего сказать не могу. PfRv2 был уродцем, стонавшим «kill me».
«5% может почти парализовать обмен.»
Пардон, это совершенно неверно.
мы в Badoo.com синхрили (и сейчас синхрят) очень большие объемы данных, Майями-Прага. Там потери бывают очень немаленькие.
Стек на линуксе можно очень гибко настраивать.
«Вопросы?»
3 гигабита — это 250 мегабайт в секунду. Это что, мало???? Пардон, если нужно больше — это явная ошибка разработки архитектуры ПО.
Пардон, это совершенно неверно.
мы в Badoo.com синхрили (и сейчас синхрят) очень большие объемы данных, Майями-Прага. Там потери бывают очень немаленькие.
Стек на линуксе можно очень гибко настраивать.
«Вопросы?»
3 гигабита — это 250 мегабайт в секунду. Это что, мало???? Пардон, если нужно больше — это явная ошибка разработки архитектуры ПО.
3 гигабита — это 250 мегабайт в секунду. Это что, мало????
Для канала между нагруженными датацентрами? Ну вообще-то немного (если вы не Амазон и вам не наплевать на DR). А выше речь вообще шла про 10G линки…
250 мегабайт в секунду — это как пара хомячковых жестких дисков на 7200 оборотов.
Пардон, если нужно больше — это явная ошибка разработки архитектуры ПО.
Есть ПО, которое само по себе — одна большая ошибка. Но оно приносит конторе деньги. Большие деньги. Позволяющее покупать и те крутые сервера за лямы долларов, и крутые массивы. А сравнительно кратковременный (10-20 секунд, причем эта цифра даже не от таймеров TCP берется) сбой связи между компонентами ПО может привести к часовому даунтайму из-за необходимости рестартовать много-много разных систем, которые ну очень медленно поднимаются, а пока они рестартуют — бизнес частично или полностью стоит. И ни черта с этим не сделаешь. Опять же, кто работал в финансовом секторе, тот знает. Я с этим, к счастью, не сталкивался, но многие вынуждены и L2 между датацентрами протягивать. Да, на цискин OTV много покупателей, и далеко не все из них безумцы. Где-то это позволит обойти ущербность ПО и не остановить бизнес при попадании метеорита в основной датацентр. А кто-то даже таскает ВМ между датацентрами без смены адресов (есть разные мерзкие системы, отлично виртуализирующиеся, но при генерации лицензии учитывающие IP адрес)…
Для передачи изменений снапшотов со скоростью 250 мегабайт в секунду требуется очень огромное количество операций, которые могут позволить очень большие организации. Для них уже и требования к каналам связи будут больше и соответственно они будут готовы заплатить за эти каналы и большие деньги.
По поводу лицензий, которые учитывают IP адреса, никто не мешает использовать виртуализацию сети или же оркестрацию, когда основной ЦОД не отвечает — меняется маршрутизация на существующее адресное пространство в другой ЦОД.
По поводу лицензий, которые учитывают IP адреса, никто не мешает использовать виртуализацию сети или же оркестрацию, когда основной ЦОД не отвечает — меняется маршрутизация на существующее адресное пространство в другой ЦОД.
Причем тут канал между нагруженными датацентрами, мне не очень понятно.
Очевидно, что metro cluster делается только для необходимых приложений.
И для них 250 мегабайт в секунду — более чем достаточно.
Если недостаточно — ставить еще железок.
У нас как-то плавно все сошло к обсуждению сетевых вещей, которые на самом деле совершенно вторичны.
Очевидно, что metro cluster делается только для необходимых приложений.
И для них 250 мегабайт в секунду — более чем достаточно.
Если недостаточно — ставить еще железок.
У нас как-то плавно все сошло к обсуждению сетевых вещей, которые на самом деле совершенно вторичны.
Про «мы одни умеем синхронно и на 400 км» я не стал бы так категорично утверждать, во избежание казусов :-).
Тут еще вопрос какая задержка на кананале должна выдерживаться при таких дистанциях? Раньше на более коротких отрезках говорили про round-trip time time 5ms. Сейчас с увеличением дистанций все чаще говорят про round-trip time 10ms.
Тут еще вопрос какая задержка на кананале должна выдерживаться при таких дистанциях? Раньше на более коротких отрезках говорили про round-trip time time 5ms. Сейчас с увеличением дистанций все чаще говорят про round-trip time 10ms.
Всегда рад научиться новому и признать если где-то неправ был.
Если не сложно, подскажите другое решение (СХД или конвергентное) enterprise-уровня с репликацией на ~400км (5 мс).
Возможно, что-то упустили.
Насколько я знаю, Netapp и EMC — 100 и 200км максимум.
Реально нам не проблема и больше сделать, но 10мс — это уже too much для синхронного датастора, latency записи на диск будет совсем уже грустной :)
p.s. правило простое — 0.25мс на каждые 100км (если идеальный линк L2). роутеры и прочее конечно-же сильно прибавляют.
Если не сложно, подскажите другое решение (СХД или конвергентное) enterprise-уровня с репликацией на ~400км (5 мс).
Возможно, что-то упустили.
Насколько я знаю, Netapp и EMC — 100 и 200км максимум.
Реально нам не проблема и больше сделать, но 10мс — это уже too much для синхронного датастора, latency записи на диск будет совсем уже грустной :)
p.s. правило простое — 0.25мс на каждые 100км (если идеальный линк L2). роутеры и прочее конечно-же сильно прибавляют.
Вы используете TCP транспорт для этих целей или что-то иное? RTT в 5мс будет очень сильно ограничивать возможности синхронных операций для профиля нагрузки с резкими всплесками записи, так что эта затея по большей части малореальна на приличном ио из-за фундаментальных лимитаций.
TCP но с тюнингом стека.
Всплески нагрузки не так важны как раз пока не уперлись в полосу, у нас есть oplog в который уходит I/O (на SSD), будет задержка с подтверждением операции ввода-вывода в ОС (soft updates, гарантированная запись данных).
Если правильно настроить работу виртуальных SCSI / SAS адаптеров в ОС (включая размер очереди) — работает все весьма прилично, мало того адаптеров можно делать много для парралелизации (а далее объединять на уровне ОС чем-то вроде LVM)
5мс протестировано и признано вполне рабочим, можно было и больше но там как раз уже начинает сильно сказываться.
На забывайте, что мы не блочном уровне оперируем, а на уровне логических объектов (контейнеров) для Metro.
Вот (поверхностное) описание Metro:
В любом случае, чудес не бывает и если надо максимально высокие параметры производительности — надо решать другими способами (на уровне приложения и асинхронной репликации, которая вообще не сказывается на производительности).
По поводу oplog:
Всплески нагрузки не так важны как раз пока не уперлись в полосу, у нас есть oplog в который уходит I/O (на SSD), будет задержка с подтверждением операции ввода-вывода в ОС (soft updates, гарантированная запись данных).
Если правильно настроить работу виртуальных SCSI / SAS адаптеров в ОС (включая размер очереди) — работает все весьма прилично, мало того адаптеров можно делать много для парралелизации (а далее объединять на уровне ОС чем-то вроде LVM)
5мс протестировано и признано вполне рабочим, можно было и больше но там как раз уже начинает сильно сказываться.
На забывайте, что мы не блочном уровне оперируем, а на уровне логических объектов (контейнеров) для Metro.
Вот (поверхностное) описание Metro:
В любом случае, чудес не бывает и если надо максимально высокие параметры производительности — надо решать другими способами (на уровне приложения и асинхронной репликации, которая вообще не сказывается на производительности).
По поводу oplog:
> TCP но с тюнингом стека.
Расскажите, пожалуйста, про методики и/или рекомендации такого тюнинга.
Расскажите, пожалуйста, про методики и/или рекомендации такого тюнинга.
Никаких «ноу-хау» тут нет.
Много вещей еще на Badoo.com в свое время отлаживали для межконтинентальной репликации, скорость в десятки раз поднимали.
1) Размер окна приемо-передачи
2) SACK
3) Правильный алгоритм congestion-control
4) Параллельные потоки
5) и тд. — еще с пару десятков параметров наберется.
Гугл выдаст пачку ссылок :)
sites.google.com/site/tfsidc/superfast-networking
www.taos.com/2012/08/01/optimizing-long-haul-tcp-throughput/
etc
Много вещей еще на Badoo.com в свое время отлаживали для межконтинентальной репликации, скорость в десятки раз поднимали.
1) Размер окна приемо-передачи
2) SACK
3) Правильный алгоритм congestion-control
4) Параллельные потоки
5) и тд. — еще с пару десятков параметров наберется.
Гугл выдаст пачку ссылок :)
sites.google.com/site/tfsidc/superfast-networking
www.taos.com/2012/08/01/optimizing-long-haul-tcp-throughput/
etc
Еще один момент — не припоминается ни один LFN-оптимизированный алгоритм, который бы подошел к этой задаче на сто процентов. Это не к вопросу о вытягивании нюансов, просто интересно, существующий используется или свой.
Это безусловно верно, 100% алгоритмов не бывает.
Собственно, у нас встроена такая вещь как Nutanix Pulse, которая в том числе позволяет собирать с реальных клиентов реальную статистику (в том случае когда они не против конечно) и тюнить настройки под наиболее часто встречаемые задачи.
В любом случае, если встают специфические вопросы — у нас есть «под капотом» сотни параметров для тюнинга и отладки, так называемые gflags
Например, вот тут прошлогодняя статья по поводу отладки асинхронного DR
nutanix.blogspot.co.uk/2013/09/nutanix-dr-troubleshooting.html
Собственно, у нас встроена такая вещь как Nutanix Pulse, которая в том числе позволяет собирать с реальных клиентов реальную статистику (в том случае когда они не против конечно) и тюнить настройки под наиболее часто встречаемые задачи.
В любом случае, если встают специфические вопросы — у нас есть «под капотом» сотни параметров для тюнинга и отладки, так называемые gflags
Например, вот тут прошлогодняя статья по поводу отладки асинхронного DR
nutanix.blogspot.co.uk/2013/09/nutanix-dr-troubleshooting.html
Вот это собственно говоря очень важно:
To resolve this problem, TCP Selective Acknowledgement, defined in RFC 2018, allows the receiving system to acknowledge all packets received even if an intermediate packet has not been received. This results in retransmission of only the lost packets, instead of an entire window worth of data.
Но при этом в линуксе есть нюансы :) Зависит от версии ядра.
fasterdata.es.net/host-tuning/linux/expert/
To resolve this problem, TCP Selective Acknowledgement, defined in RFC 2018, allows the receiving system to acknowledge all packets received even if an intermediate packet has not been received. This results in retransmission of only the lost packets, instead of an entire window worth of data.
Но при этом в линуксе есть нюансы :) Зависит от версии ядра.
fasterdata.es.net/host-tuning/linux/expert/
SACK поддерживается давно и, вероятно, везде. Очень странно хвастаться его наличием.
По какой причине для такой задачи был выбран TCP? Почему не обрабатывать дропы/реордеры/прочее на уровне приложения, гоняя сервис поверх UDP? Нет, наличие SACK вовсе не означает отсутствия мощного спада пропускной способности всего потока от потери одного-единственного пакета. Просто не требуется перепосылать всё окно. Да и ни один congestion management алгоритм для TCP не сможет достичь эффективности и скорости работы собственного протокола (например, поверх UDP — неважно). И колоссального размера буфера, позволящие свести к минимуму паузы при ожидании ACK, не нужны.
Единственное что приходит в голову — stateful файрволы любят TCP, потому что у альтернатив отсутствует понятие сессии на транспортном уровне.
По какой причине для такой задачи был выбран TCP? Почему не обрабатывать дропы/реордеры/прочее на уровне приложения, гоняя сервис поверх UDP? Нет, наличие SACK вовсе не означает отсутствия мощного спада пропускной способности всего потока от потери одного-единственного пакета. Просто не требуется перепосылать всё окно. Да и ни один congestion management алгоритм для TCP не сможет достичь эффективности и скорости работы собственного протокола (например, поверх UDP — неважно). И колоссального размера буфера, позволящие свести к минимуму паузы при ожидании ACK, не нужны.
Единственное что приходит в голову — stateful файрволы любят TCP, потому что у альтернатив отсутствует понятие сессии на транспортном уровне.
Насчет «хвастается» — тут уже каждый видит что хочет увидеть.
Вообще-то дословно написано — "никакого ноу-хау тут нет".
Насчет TCP в данном случае — нет никаких причин переходить на UDP, на наших тестах и у клиентов все работает прекрасно, мало того это работает и в других компаниях (пример уже приводился — badoo.com спокойно синхрит данные между континентами разными).
Дискуссия не имеет смысла, я понимаю что (как в анекдоте про блок / собак / кошек) каждый переводит на ту область в которой силен (в данном случае — сеть), но функциональность метро-кластера это лишь несколько процентов от того что умеет и делает Nutanix.
Вообще-то дословно написано — "никакого ноу-хау тут нет".
Насчет TCP в данном случае — нет никаких причин переходить на UDP, на наших тестах и у клиентов все работает прекрасно, мало того это работает и в других компаниях (пример уже приводился — badoo.com спокойно синхрит данные между континентами разными).
Дискуссия не имеет смысла, я понимаю что (как в анекдоте про блок / собак / кошек) каждый переводит на ту область в которой силен (в данном случае — сеть), но функциональность метро-кластера это лишь несколько процентов от того что умеет и делает Nutanix.
Давайте уточним про какие 5 ms вы пишете. В случае nutanix 5 ms это RTT (туда и обратно)? Упрощенно говоря прохождение пакета данных в одну сторону 2,5 ms и возвращение ask о записи тоже 2,5 ms, в сумме 5 ms. Или все таки имеется в ввиду по аналогии с пингом, прохождение сигнала в одну сторону 5 ms?
RTT, безусловно.
Если в одну сторону 5ms — это будет уже 10ms RTT и сильно больше 400 км.
Если очень примерно говорить, то с накладными расходами — 100км это миллисекунда RTT.
Вот кстати у Brocade вплоне неплохая статья
community.brocade.com/t5/Design-Build/Data-Center-Infrastructure-Validation-Test-FCIP-amp-Fibre/ta-p/36925
Если в одну сторону 5ms — это будет уже 10ms RTT и сильно больше 400 км.
Если очень примерно говорить, то с накладными расходами — 100км это миллисекунда RTT.
Вот кстати у Brocade вплоне неплохая статья
community.brocade.com/t5/Design-Build/Data-Center-Infrastructure-Validation-Test-FCIP-amp-Fibre/ta-p/36925
Насколько помню, по моему «нежно любимый» вами EMC заявлял прошедшей весной о тех же максимальных характеристиках для своего решения VPLEX Metro (5ms RTT и до 400km расстояние между сайтами).
Хотя тут все еще и от софта может зависеть. Та же VMware по-моему поддерживает растянутый HA кластер с характеристиками канала до 10ms RTT между площадками, со всеми live миграциями машин и etc.
Хотя тут все еще и от софта может зависеть. Та же VMware по-моему поддерживает растянутый HA кластер с характеристиками канала до 10ms RTT между площадками, со всеми live миграциями машин и etc.
1) www.emc.com/storage/vplex/models-vplex-metro.htm — смотрю, ничего не вижу про дистанции / RTT.
можно навести точнее?
То что я вижу — прямо указано 100км
kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1026692
«EMC VPLEX is a federation solution that can be stretched across two geographically dispersed datacenters separated by synchronous distances (maximum distance of separation = 100 km, maximum round trip latency = 5 msec»
2) Уточните пожалуйста, что подразумевается под VMware HA cluster.
Если предполагается что ему не нужна «нижележащая» СХД — то это далеко не так.
можно навести точнее?
То что я вижу — прямо указано 100км
kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1026692
«EMC VPLEX is a federation solution that can be stretched across two geographically dispersed datacenters separated by synchronous distances (maximum distance of separation = 100 km, maximum round trip latency = 5 msec»
2) Уточните пожалуйста, что подразумевается под VMware HA cluster.
Если предполагается что ему не нужна «нижележащая» СХД — то это далеко не так.
1) У EMC как и у Nutanix, да и у других вендоров, более менее полная документация доступна только «для своих» и на закрытых разделах порталов. Про EMC и VPLEX Metro я помню по каким то анонсам с EMC World 2014. Документальное подтверждение найти сейчас проблема :).
То что нашлось в открытом доступе. 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.
То что нашлось в открытом доступе. 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.
Спасибо за развёрнутый ответ. Звучит все действительно очень «вкусно» и интересно.
Забыл раскрыть один момент (по поводу FPGA / аппаратного ускорения vs решение в ПО).
Если коротко, то на 2U cтойко-места (Nutanix NX-3461 например) вы «выжимаем» около 120.000 IOPS на чтение, и более 50.000 IOPS на запись.
Это реальные и честные цифры, random I/O.
10 блоков (20U, половина стойка) покажут соответственно 1.2 миллиона IOPS на чтение. И так далее (линейное расширение).
Вот пример (прошлогодний, на сегодня цифры значительно выше за счет оптимизации ПО):
https://www.youtube.com/watch?v=B-RBDtKgQTo&feature=youtu.be
Как видите, чисто программное решение может показывать выдающиеся результаты по производительности.
Если коротко, то на 2U cтойко-места (Nutanix NX-3461 например) вы «выжимаем» около 120.000 IOPS на чтение, и более 50.000 IOPS на запись.
Это реальные и честные цифры, random I/O.
10 блоков (20U, половина стойка) покажут соответственно 1.2 миллиона IOPS на чтение. И так далее (линейное расширение).
Вот пример (прошлогодний, на сегодня цифры значительно выше за счет оптимизации ПО):
https://www.youtube.com/watch?v=B-RBDtKgQTo&feature=youtu.be
Как видите, чисто программное решение может показывать выдающиеся результаты по производительности.
Ваша проприетарщина — еще более проприетарная, чем у других вендоров.
Не смешите нас рассказами про архаичность стандартных «закрытых» решений.
А взлетит или нет — посмотрим.
Не смешите нас рассказами про архаичность стандартных «закрытых» решений.
А взлетит или нет — посмотрим.
А расскажите, что же у нас пропиетарного из железа? :)
Прямо интересно стало.
Или даже ОС? Это ничего что на 95% это opensource, а «железо» — сервера Supermicro или Dell, причем абсолютно стандартные?
И что сейчас уже made in Russia вовсю обсуждается?
Насчет «взлетит» — уже взлетело, и давно.
Официальные продажи последний год (в этом явно сильно лучше будет) — более 200 миллионов долларов.
www.nutanix.com/2014/08/06/nutanix-closes-strong-fiscal-year-exceeds-200-million-bookings-run-rate/
Прямо интересно стало.
Или даже ОС? Это ничего что на 95% это opensource, а «железо» — сервера Supermicro или Dell, причем абсолютно стандартные?
И что сейчас уже made in Russia вовсю обсуждается?
Насчет «взлетит» — уже взлетело, и давно.
Официальные продажи последний год (в этом явно сильно лучше будет) — более 200 миллионов долларов.
www.nutanix.com/2014/08/06/nutanix-closes-strong-fiscal-year-exceeds-200-million-bookings-run-rate/
Посмотрел ваш профайл, стало все понятно — откуда такие странные комментарии :)
В общем-то для netapp действительно приходят тяжелые времена.
Выдержки из ваших опусов:
«Netapp — реальность против маркетинга 67
+2 mirrik,14 февраля 2014 в 14:32#
Есть полноценный QoS с ограничением по IOPS или MB/s — он доступен в cDOT.
Никакой связи в записи с объемом кэша нет — запись ведется через NVRAM, который размером в несколько гигабайт.
Про все остальное прекрасно ответил bakset.»
«FilerView уже давно нет, да и FlashCache ставится куда угодно, кроме младших моделей FAS2xxx.»
«Расскажите это NetApp. У них TP был даже тогда, когда он не назывался TP — можно было отдавать объемы большие, чем есть физически, увеличивать и уменьшать размер мета-RAID-групп (у NetApp они называются aggregate).»
В общем-то для netapp действительно приходят тяжелые времена.
Выдержки из ваших опусов:
«Netapp — реальность против маркетинга 67
+2 mirrik,14 февраля 2014 в 14:32#
Есть полноценный QoS с ограничением по IOPS или MB/s — он доступен в cDOT.
Никакой связи в записи с объемом кэша нет — запись ведется через NVRAM, который размером в несколько гигабайт.
Про все остальное прекрасно ответил bakset.»
«FilerView уже давно нет, да и FlashCache ставится куда угодно, кроме младших моделей FAS2xxx.»
«Расскажите это NetApp. У них TP был даже тогда, когда он не назывался TP — можно было отдавать объемы большие, чем есть физически, увеличивать и уменьшать размер мета-RAID-групп (у NetApp они называются aggregate).»
Пока не докажете, что в NetApp настапают тяжелые времена — говорить, видимо, не о чем (:
Умные люди просто смотрят вперед.
1) 2017 год — 50% (или более) энтерпрайз-рынка — конвергентные системы (см. Гартнер)
2) Netapp — акции были 60$, сейчас уже 40$
3) За оставшиеся 50% рынка будут драться все традиционные вендоры, причем рынок постоянно сокращается.
4) Конторы типа EMC выживут, просто купив кого-то из производителей серверов (по рынку уже ходят слухи о HP, есть партнерства с Lenovo), для того чтобы делать конвергентные решения. Netapp — не потянет, денег намного меньше.
5) Flexpod — крайне странное образование, Cisco ведет себя как неверная жена ;) Вон уже и с Simplivity договорились. Недаром VCE будет забирать под себя EMC — на Cisco надежды мало.
…
Ну и после ваших крайне смешных заявлений про «пропиетарщину» — реально нет смысла учавстовать в дискуссиях ;)
1) 2017 год — 50% (или более) энтерпрайз-рынка — конвергентные системы (см. Гартнер)
2) Netapp — акции были 60$, сейчас уже 40$
3) За оставшиеся 50% рынка будут драться все традиционные вендоры, причем рынок постоянно сокращается.
4) Конторы типа EMC выживут, просто купив кого-то из производителей серверов (по рынку уже ходят слухи о HP, есть партнерства с Lenovo), для того чтобы делать конвергентные решения. Netapp — не потянет, денег намного меньше.
5) Flexpod — крайне странное образование, Cisco ведет себя как неверная жена ;) Вон уже и с Simplivity договорились. Недаром VCE будет забирать под себя EMC — на Cisco надежды мало.
…
Ну и после ваших крайне смешных заявлений про «пропиетарщину» — реально нет смысла учавстовать в дискуссиях ;)
А ничего, что как раз EMC по слухам продать хотят, а не ОНИ кого-то покупают? И второе: если вы не способны понять, что ваша проприетарщина на любом уровне (начиная от кластеризации и заканчивая хранением в разы) более проприетарная — чем тот же FlexPod — говорить и правда не о чем.
Ну, тут только руками развести.
Нет понимания того что не важно HP (Dell / кто-угодно) купит EMC или EMC купит часть HP / Lenovo / кого угодно — результат один, конвергентные решения.
Нет понимания того что «пропиетарщины» в Nutanix практически нет, но есть на 95% opensource и 100% описанная архитектура.
Реально, вам незачем тратить свое время на нас.
p.s. www.businessinsider.com/r-exclusive-tech-firms-hp-emc-call-off-merger-talks---sources-2014-10
Нет понимания того что не важно HP (Dell / кто-угодно) купит EMC или EMC купит часть HP / Lenovo / кого угодно — результат один, конвергентные решения.
Нет понимания того что «пропиетарщины» в Nutanix практически нет, но есть на 95% opensource и 100% описанная архитектура.
Реально, вам незачем тратить свое время на нас.
p.s. www.businessinsider.com/r-exclusive-tech-firms-hp-emc-call-off-merger-talks---sources-2014-10
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О Nutanix, Web-Scale, конвергентных платформах и смене парадигм построения IT инфраструктур