Комментарии 110
Мы не можем раскрыть информацию о фактической цене
Укажите цены по прайсу, shapa ведь их писать не стесняется.
habrahabr.ru/company/croc/blog/214139/#comment_7364367
Цены правильные — GPL, но в России цены предоставляются по запросу.
Цены правильные — GPL, но в России цены предоставляются по запросу.
Звучит не плохо, но так и не понятно, что за софт там внутри, никогда в жизни не поверю, что они меньше чем за год сделали ОС и сетевую файловую систему.
ОС Free BSD. Почему за год?
Файловая система — ext4 (там хранятся группы экстентов по 4 мегабайта), метаданные — кассандра.
Все работает поверх Centos.
Все работает поверх Centos.
Если CentOS и ext4, то честно говоря совсем не интересно.
конечно не интересно.
одна из самых производительных и надежных ФС в мире (NDFS), плоха лишь потому что использует для базового хранения экстентов ext4, а для метаданных — кассандру, и все это под «ужасным» линуксом который работает как запускалка наших сервисов ;))
это конечно пять баллов ;).
и конечно-же ничуть не смущает что сейчас самые производительные и надежные сетевые «железки» на сотни гигабит / терабиты трафиков (Arista Networks, F5 Networks и тд) — это тоже линукс и даже Centos.
…
а если без шуток — ext4 как раз идеальна в нашем случае, ибо от базового уровня нам просто надо сохранить мегабайтный файл на диске. Никакого другого функционала ext4 не используется. И надежность у нее — сотни миллионов инсталляций в мире (ни одна другая ФС кроме FAT разве что — и рядом не лежит).
одна из самых производительных и надежных ФС в мире (NDFS), плоха лишь потому что использует для базового хранения экстентов ext4, а для метаданных — кассандру, и все это под «ужасным» линуксом который работает как запускалка наших сервисов ;))
это конечно пять баллов ;).
и конечно-же ничуть не смущает что сейчас самые производительные и надежные сетевые «железки» на сотни гигабит / терабиты трафиков (Arista Networks, F5 Networks и тд) — это тоже линукс и даже Centos.
…
а если без шуток — ext4 как раз идеальна в нашем случае, ибо от базового уровня нам просто надо сохранить мегабайтный файл на диске. Никакого другого функционала ext4 не используется. И надежность у нее — сотни миллионов инсталляций в мире (ни одна другая ФС кроме FAT разве что — и рядом не лежит).
Количество инсталляций совсем не показатель. Я считаю, что xfs лучше и гугль тоже почти выбрал выбрал xfs, почти только потому, что у них ext2 и они ее сконвертировали в ext4, а так бы на xfs перешли. Считаю я так не просто исходя из названия, а исходя из опыта эксплуатации.
Количество инсталляций так же зависит от того, что ext4 много где ФС по умолчанию, но это опять же не значит, что она лучшая, не спорю может быть для этих задач она и подходит, но выбор он всегда лучше, чем его отсутствие… Zfs и FreeBSD для данного решения выглядит куда вкуснее.
Количество инсталляций так же зависит от того, что ext4 много где ФС по умолчанию, но это опять же не значит, что она лучшая, не спорю может быть для этих задач она и подходит, но выбор он всегда лучше, чем его отсутствие… Zfs и FreeBSD для данного решения выглядит куда вкуснее.
«почти» — ключевое слово.
Не надо путать файловую как ФС общего назначения, или просто хранилку наших экстентов — нам и FAT32 бы хватило, если был бы бесплатный и надежный.
Количество инсталляций — факт сверхважный, в данном случае это означает отполированность до блеска.
XFS для нашего случая был бы крайне странным, и прямо говоря глупым вариантом.
ZFS и FreeBSD для нашего решения выглядят еще более неразумным, чем XFS.
FreeBSD в сущности уже практически трупик, их только Juniper и тащит (у которого глобальные проблемы с бизнесом в общем-то по слухам — как минимум народ от них бежит, в ту же Arista или F5 Networks. А кто-то и к нам.).
Со всем уважением, ваш опыт эксплуатации generic файловых ничего не имеет общего к области кластерных ФС — это разные вещи.
Не надо путать файловую как ФС общего назначения, или просто хранилку наших экстентов — нам и FAT32 бы хватило, если был бы бесплатный и надежный.
Количество инсталляций — факт сверхважный, в данном случае это означает отполированность до блеска.
XFS для нашего случая был бы крайне странным, и прямо говоря глупым вариантом.
ZFS и FreeBSD для нашего решения выглядят еще более неразумным, чем XFS.
FreeBSD в сущности уже практически трупик, их только Juniper и тащит (у которого глобальные проблемы с бизнесом в общем-то по слухам — как минимум народ от них бежит, в ту же Arista или F5 Networks. А кто-то и к нам.).
Со всем уважением, ваш опыт эксплуатации generic файловых ничего не имеет общего к области кластерных ФС — это разные вещи.
В каждом релизе до блеска полируют :)
Вот 3.13.6 вышла…
Вот 3.13.6 вышла…
1883d76 ext4: don't leave i_crtime.tv_sec uninitialized
fe01b1a ext4: fix online resize with a non-standard blocks per group setting
385d7ce ext4: fix online resize with very large inode tables
1503cbd ext4: don't try to modify s_flags if the the file system is read-only
087cee5b7 ext4: fix error paths in swap_inode_boot_loader()
4c5e5c7 ext4: fix xfstest generic/299 block validity failures
Расскажите в паре слов как происходит обновление «прошивок» управляющих контроллеров. Есть какие-то ограничения, в момент, когда у нод одного кластера разные версии fw?
У нод нет FW — наш контроллер работает поверх стандартных гипервизоров
Так что апдейты все на лету ;)
Так что апдейты все на лету ;)
Кратко процесс обновления: прошивка заливается на один узел, он распространяет его на другие, по очереде перезагружаются ноды. Делается из командной строки. Обещают автоматизировать в следующих версиях, сделать из GUI.
Интересные железки, вернее сказать правильная концепция и хорошо написанный софт.
Но применимость ограниченна: под VDI да круто, под смешанные решения (несколько типов гипервизоров) уже не применимо как единая система, физические сервера в пролете, для них эта система не подходит. Никаких iSCSI, FCP и т.д.
По цене, если сравнивать СХД с забивкой SSD вендоров первого эшелона + сервера для обработки, то стоимость сопоставимая или выигрывает Nutanix, а если рассматривать смесь HDD+SSD то обычная СХД.
Nutanix по скорости очень крут, хоть и не во всех сценариях применим. Но там где применим, он смотрится отлично.
Но применимость ограниченна: под VDI да круто, под смешанные решения (несколько типов гипервизоров) уже не применимо как единая система, физические сервера в пролете, для них эта система не подходит. Никаких iSCSI, FCP и т.д.
По цене, если сравнивать СХД с забивкой SSD вендоров первого эшелона + сервера для обработки, то стоимость сопоставимая или выигрывает Nutanix, а если рассматривать смесь HDD+SSD то обычная СХД.
Nutanix по скорости очень крут, хоть и не во всех сценариях применим. Но там где применим, он смотрится отлично.
«уже не применимо как единая система» это не так.
с версии 4.0 ПО — у нас мультикластерный менежмент, хоть 1000 кластеров в разных точках мира на разных гипервизорах управляйте (ESXi, KVM, HyperV)
с версии 4.0 ПО — у нас мультикластерный менежмент, хоть 1000 кластеров в разных точках мира на разных гипервизорах управляйте (ESXi, KVM, HyperV)
тем не менее в виртуалках можно много чего развернуть, например:
Microsoft SQL Server Best Practices
go.nutanix.com/rs/nutanix/images/sql-on-nutanix-bp.pdf
Решение начиналось как VDI, сейчас это и серверная виртуализация
Microsoft SQL Server Best Practices
go.nutanix.com/rs/nutanix/images/sql-on-nutanix-bp.pdf
Решение начиналось как VDI, сейчас это и серверная виртуализация
Привязка к железу сделана из чисто маркетинговых соображений, или каких-то ещё?
Есть ли у вас сравнительная таблица с аналогичными решениями от конкурентов?
Есть ли у вас сравнительная таблица с аналогичными решениями от конкурентов?
Привязка к железу сделана из маркетинговых соображений, это мое мнение. В прицепе, есть возможны варианты купить Nutanix на другом железе.
Как таковых аналогов мне не известно, если брать только СХД часть, то очень похоже на LeftHand, Starwind итд.
Как таковых аналогов мне не известно, если брать только СХД часть, то очень похоже на LeftHand, Starwind итд.
Не совсем.
Как Apple — надежно потому что проверенная комбинация железа и ПО.
Впрочем, под крупные проекты / заказчиков мы делаем чисто софтовое решение.
Обращайтесь к нам по тех. вопросам напрямую, обсудим.
Как Apple — надежно потому что проверенная комбинация железа и ПО.
Впрочем, под крупные проекты / заказчиков мы делаем чисто софтовое решение.
Обращайтесь к нам по тех. вопросам напрямую, обсудим.
Кеширование горячих блоков на SSD и прочие FS-related плюшки делаются посредством ZFS?
У нас не кэширование, а полноценное хранение. Технически мы вообще без SATA дисков работать можем.
Мы намного «умнее» ZFS, вплоть до того что умеем дедуплицировать RAM кэш (!).
Мы намного «умнее» ZFS, вплоть до того что умеем дедуплицировать RAM кэш (!).
Я понимаю, но все-же, не писали же вы все с нуля. Там явно ZFS со специями?
Нет, смотрите ниже.
ext4 — хранение экстентов, кассандра — метаданные. ZFS хорошая ФС, но до нормальной кластерности ей как до луны. ZFS ARC — да, снимаю шляпу, на момент создания — была прорывной. Сейчас мы ушли кардинально дальше.
у нас одни из ключевых разработчиков кассандры (из фейсбука, гугла и ряда других контор к нам перешли целыми командами).
ext4 — хранение экстентов, кассандра — метаданные. ZFS хорошая ФС, но до нормальной кластерности ей как до луны. ZFS ARC — да, снимаю шляпу, на момент создания — была прорывной. Сейчас мы ушли кардинально дальше.
у нас одни из ключевых разработчиков кассандры (из фейсбука, гугла и ряда других контор к нам перешли целыми командами).
Это реализовано на NDFS. Поверх чего она работает, на основе чего создана не знаю.
Общий принцип тут:
go.nutanix.com/TechNoteNutanixPerformance_LP.html
go.nutanix.com/TechNoteNutanixSystemReliability_LP.html
go.nutanix.com/TechNoteNutanixSystemScalbility_LP.html
Общий принцип тут:
go.nutanix.com/TechNoteNutanixPerformance_LP.html
go.nutanix.com/TechNoteNutanixSystemReliability_LP.html
go.nutanix.com/TechNoteNutanixSystemScalbility_LP.html
А расскажите пожалуйста, какие параметры у вашей системы, интересует удельная пропускная способность на ноду по I/O. Также из статьи немного непонятно, чем решение отличается от обычного iscsi — не упомянут multipath или какие-либо пути фейловера при отказе одной ноды хранилища, буду признателен за детализацию.
блок 3461 дает около 102 тысяч I/O на чтение и 40 тысяч на запись.
на ноду — разделите на 4.
на ноду — разделите на 4.
Мультипас у нас в ДНК. Даже в случае отказа виртуального контроллера (или апгрейда — у нас все на лету, понятие даунтайма или «окна обслуживания» просто отсутствует), трафик гипервизора переадресуется на соседние ноды (в версии 4.x — per inode проксируется на весь кластер через NFS-proxy который есть на каждом ноде).
100К иопсов, это, надо полагать, с агрегацией/кешированием на клиенте? Если не грузить по уши, какое получается выдерживать SLA для латенси клиента в режиме нормальных операций и в режиме рекавери? Используется ли кворум «контроллеров» для обеспечения отказоустойчивости всего кластера?
Кворум — сильно доработанный Paxos.
en.wikipedia.org/wiki/Paxos_(computer_science)
Лейтенси чрезвычайно низкий, если не «по уши» и брать нормальные коммутаторы типа Arista Networks (и боже упаси от нексусов).
Конкретнейшие цифры есть в наших Best Practice — с замерами, таблицами и тд.
Они открыто доступны на сайте Nutanix
www.nutanix.com/resources/
100к — это абсолютные честные IOPS, тестирование FIO (у нас встроенная самодиагностика / тестирование кластера). Сегодня лично видел в одной сверх-крупной Российской компании.
С каждой версией ПО производительность сильно растет, еще прошлой осенью было около 50.000 IOPS на чтение на кластер.
en.wikipedia.org/wiki/Paxos_(computer_science)
Лейтенси чрезвычайно низкий, если не «по уши» и брать нормальные коммутаторы типа Arista Networks (и боже упаси от нексусов).
Конкретнейшие цифры есть в наших Best Practice — с замерами, таблицами и тд.
Они открыто доступны на сайте Nutanix
www.nutanix.com/resources/
100к — это абсолютные честные IOPS, тестирование FIO (у нас встроенная самодиагностика / тестирование кластера). Сегодня лично видел в одной сверх-крупной Российской компании.
С каждой версией ПО производительность сильно растет, еще прошлой осенью было около 50.000 IOPS на чтение на кластер.
Ага, теперь более-менее понятно. С цефом не сравнивали по производительности, поскольку по архитектуре у вас практически он, судя по информации на сайте?
По архитектуре скорее ceph — как мы, но опять-же только в первом приближении.
Nutanix с 2009 года существует, просто работал только на США и только на гос. рынки.
Проблема ceph — то что это просто ФС, неплохая вполне, для многих онлайн проектов — самый лучший вариант.
Мы — конвергентная платформа, с кучей высокоуровневого функционала, максимально упрощенного управления и запуска (хватает 1 среднеквалифицированного инженера на все).
Ну это как говорить что ext3 конкурент FreeBSD.
Nutanix с 2009 года существует, просто работал только на США и только на гос. рынки.
Проблема ceph — то что это просто ФС, неплохая вполне, для многих онлайн проектов — самый лучший вариант.
Мы — конвергентная платформа, с кучей высокоуровневого функционала, максимально упрощенного управления и запуска (хватает 1 среднеквалифицированного инженера на все).
Ну это как говорить что ext3 конкурент FreeBSD.
Расскажите побольше о том, как осуществляется масштабирование. Вот скажем кончилось у меня свободное место, значит я должен купить это самое место (с некоторым поправочным коэффициентом, вероятно?), а в нагрузку получу дополнительные процессоры и память. И наоборот. В любом сценарии получается, что купленное оборудование простаивает. Неужели такая хорошая цена, что одно компенсирует другое?
Еще один вопрос, как все это себя ведет в случае различных сбоев и профилактических работ. Например, выключили всю ферму, а потом начали включать по одному? Или все сразу? Что будет происходить?
Есть ли возможность в явном виде создавать мультисайтовые решения, допускающие выход из строя сайта целиком?
Или это все же по прежнему очень нишевое решение (VDI), когда соотношение производительности и емкости узла практически фиксировано во времени, а для отказоустойчивости есть только HA?
Еще один вопрос, как все это себя ведет в случае различных сбоев и профилактических работ. Например, выключили всю ферму, а потом начали включать по одному? Или все сразу? Что будет происходить?
Есть ли возможность в явном виде создавать мультисайтовые решения, допускающие выход из строя сайта целиком?
Или это все же по прежнему очень нишевое решение (VDI), когда соотношение производительности и емкости узла практически фиксировано во времени, а для отказоустойчивости есть только HA?
Доступное место считается по простой формуле, сложить пространство на все узлах и поделить попалам. (порядка 50ГБ отъедается от SSD на каждом узле для своих нужд). Новый узел добавляется просто. кнопкой Add.
В кластер можно объединять любые узлы с разной конфигурацией, часть узлов может иметь больше SSD, меньше SATA, наоборот. Есть определенный выбор CPU/ количества RAM.
Ньюанс в том, что при малом количестве узлов может быть некий дисбаланс распределения данных между емкими и быстрыми узлами.
Одно из удобств расширения блоками в том, что Вы знаете сколько будет стоить апгрейд на любое количество. При это вместе с емкостью у растет и скорость. Сейчас 20 ВМ, а через год надо 200 и это стоит в 10 раз больше. Классическая СХД, так просто не маштабируется, тут и лицензирование может быть другое и замена контроллеров, помимо того что это непредсказуемо это, как правило, дороже.
В случае сбоев — минимально надо 2 узла для работы, это деградированое состояние, но если хватит места Nutanix сделает две копии данных.
В случае включения выключения коробки тоже все просто CVM загрузились собрали кластер появился сторадж. Если вопрос в том, как включать — включать все сразу.
Мультисайт. Растянуть кластер не получиться (пока). Возможна эта фича будет. Есть асинхронная репликация, есть возможность включить машину на резервной площадке из консоли управления Nutanix. Есть интеграция c SRM.
Решение не только под VDI, но и под серверную виртуализацию. Нишевое — согласен, но виртуализация практически везде есть. Платформа так же работает с Big Data — Hadoop, Splunk.
А что кроме HA есть для отказоустойчивости ВМ? Чтобы Вы еще хотели?
В кластер можно объединять любые узлы с разной конфигурацией, часть узлов может иметь больше SSD, меньше SATA, наоборот. Есть определенный выбор CPU/ количества RAM.
Ньюанс в том, что при малом количестве узлов может быть некий дисбаланс распределения данных между емкими и быстрыми узлами.
Одно из удобств расширения блоками в том, что Вы знаете сколько будет стоить апгрейд на любое количество. При это вместе с емкостью у растет и скорость. Сейчас 20 ВМ, а через год надо 200 и это стоит в 10 раз больше. Классическая СХД, так просто не маштабируется, тут и лицензирование может быть другое и замена контроллеров, помимо того что это непредсказуемо это, как правило, дороже.
В случае сбоев — минимально надо 2 узла для работы, это деградированое состояние, но если хватит места Nutanix сделает две копии данных.
В случае включения выключения коробки тоже все просто CVM загрузились собрали кластер появился сторадж. Если вопрос в том, как включать — включать все сразу.
Мультисайт. Растянуть кластер не получиться (пока). Возможна эта фича будет. Есть асинхронная репликация, есть возможность включить машину на резервной площадке из консоли управления Nutanix. Есть интеграция c SRM.
Решение не только под VDI, но и под серверную виртуализацию. Нишевое — согласен, но виртуализация практически везде есть. Платформа так же работает с Big Data — Hadoop, Splunk.
А что кроме HA есть для отказоустойчивости ВМ? Чтобы Вы еще хотели?
Не надо говорить что наш DR сильно хуже SRM. Многие клиенты наборот считают что мы сильно лучше.
И да, SRM мы тоже официально поддерживаем, правильно замечено.
На резервной площадке не «виртуальную машину» включать, а protection domain. Это понятие описывает бизнес-логику.
И да, SRM мы тоже официально поддерживаем, правильно замечено.
На резервной площадке не «виртуальную машину» включать, а protection domain. Это понятие описывает бизнес-логику.
>>И да, SRM мы тоже официально поддерживаем, правильно замечено.
То есть, у вас есть сертифицированый SRA? (В списке доступных не нашел.)
Поддерживается ли VMImageConsistency при репликации (при использовании SRA и вашего DR)?
И кстати, поддерживается ли HardwareAcceleratedMove, HardwareAcceleratedInit (VAAI)?
То есть, у вас есть сертифицированый SRA? (В списке доступных не нашел.)
Поддерживается ли VMImageConsistency при репликации (при использовании SRA и вашего DR)?
И кстати, поддерживается ли HardwareAcceleratedMove, HardwareAcceleratedInit (VAAI)?
VAAI 100% поддержка.
Констистенси мы поддерживаем, причем уже есть App. Consistency тоже (пока в бете).
Сертификации многие нам vmware мееедленно, причины можно только догадываться.
Ровно те-же по которым нас резко попросили не участвовать в VMware PEX за неделю до него, при том что мы единственные за всю историю 3 года подряд брали золотую медаль VMworld.
www.crn.com/news/virtualization/240165846/vmware-limits-some-storage-vendors-presence-at-vmware-pex.htm
(папа у vmware кто? :))) уж не EMC ли? )
Констистенси мы поддерживаем, причем уже есть App. Consistency тоже (пока в бете).
Сертификации многие нам vmware мееедленно, причины можно только догадываться.
Ровно те-же по которым нас резко попросили не участвовать в VMware PEX за неделю до него, при том что мы единственные за всю историю 3 года подряд брали золотую медаль VMworld.
www.crn.com/news/virtualization/240165846/vmware-limits-some-storage-vendors-presence-at-vmware-pex.htm
(папа у vmware кто? :))) уж не EMC ли? )
Спасибо. Про HA я с shapa поговорю.
Место можно расширять на capacity node — там мало процессоров, мало памяти, можно использовать бесплатный гипервизор (включая esxi (!)), много дисков.
Смотрите модель NX6120 — один нод 20TB места.
Смотрите модель NX6120 — один нод 20TB места.
А теперь поехали сложные вопросы.
Как выбирается «пара» для записи? Запись синхронная или асинхронная? Если асинхронная, что делать при падении ноды, если синхронная, как защищаются от перегрузки спары? Парность полная (сервер-сервер) или блочная (а-ля ceph)? Какое latency на запись при трёх нодах и latency ethernet'а в 100µs?
Предположим, что всё железо работает исправно. Какая надёжность системы в этой конфигурации?
Как выбирается «пара» для записи? Запись синхронная или асинхронная? Если асинхронная, что делать при падении ноды, если синхронная, как защищаются от перегрузки спары? Парность полная (сервер-сервер) или блочная (а-ля ceph)? Какое latency на запись при трёх нодах и latency ethernet'а в 100µs?
Предположим, что всё железо работает исправно. Какая надёжность системы в этой конфигурации?
Пара для записи выбирается случайно, репликация поблочно, запись синхронная. Можно увеличить/ уменьшить количество копий блоков, на уровне ВМ. Nutanix пытается растащить данные между несколькими коробками если блоков несколько.
Я не готов ответить на вопрос про величину задержки.
В конфигурации с тремя нодами система гарантирована переживет потерю любой ноды. Время ребилда зависит от многих факторов, но надо понимать что поскольку нет RAID, то, при выходе из строя диска, данные ребилдятся со всех дисков и на все диски, что намного быстрее… Если вопрос про софт, то он вполне надежен — решению не первый год.
Я не готов ответить на вопрос про величину задержки.
В конфигурации с тремя нодами система гарантирована переживет потерю любой ноды. Время ребилда зависит от многих факторов, но надо понимать что поскольку нет RAID, то, при выходе из строя диска, данные ребилдятся со всех дисков и на все диски, что намного быстрее… Если вопрос про софт, то он вполне надежен — решению не первый год.
Если выбор происходит случайно, каким образом обеспечивается изоляция Fault Domain'ов? У ceph'а (давайте сравнить с текущими решениями) выбор дисков структурирован, и вполне предсказуем.
Далее: если распределение поблочное, где хранится информация о том, кто что где хранит? Как обеспечивается доступность этой информации? Какое пенальти по производительности это даёт (для понимания, у ceph'а минимальное пенальти при трёхкратной избыточности — аммортизированное 6x)?
Каким образом система защищается от партиционирования (когда две половинки кластера с потерянной связью между друг другом каждая утверждает, что она самая главная тут)?
В конце-концов, общественность жаждет сравнения лоб-в-лоб с glusterfs, ceph, parallels (забыл как их distributed вариант зовётся).
Далее: если распределение поблочное, где хранится информация о том, кто что где хранит? Как обеспечивается доступность этой информации? Какое пенальти по производительности это даёт (для понимания, у ceph'а минимальное пенальти при трёхкратной избыточности — аммортизированное 6x)?
Каким образом система защищается от партиционирования (когда две половинки кластера с потерянной связью между друг другом каждая утверждает, что она самая главная тут)?
В конце-концов, общественность жаждет сравнения лоб-в-лоб с glusterfs, ceph, parallels (забыл как их distributed вариант зовётся).
Вы от ребят слишком многого требуете :)
…
Часть информации открыта, часть — уж пардон, открывать не будем. Мы дорогу переходим слишком многим, и компания уже более миллиардов долларов value. На 100% опенсорс мы не претендуем, и «наколенные» проекты — не наш рынок.
Кворум — сильно доработанный Paxos.
en.wikipedia.org/wiki/Paxos_(computer_science)
Fault Domain — для RF2 — 3 копии метаданных в кассандре. Для RF3 — 5 копий.
Конфигурации — жестко допиленный Zookeper. Пенальти у нас нет, все цифры производительности — уже с резервированием. Ребилд системы из 20 нодов при вылете жесткого диска одного — около 10 минут.
…
Часть информации открыта, часть — уж пардон, открывать не будем. Мы дорогу переходим слишком многим, и компания уже более миллиардов долларов value. На 100% опенсорс мы не претендуем, и «наколенные» проекты — не наш рынок.
Кворум — сильно доработанный Paxos.
en.wikipedia.org/wiki/Paxos_(computer_science)
Fault Domain — для RF2 — 3 копии метаданных в кассандре. Для RF3 — 5 копий.
Конфигурации — жестко допиленный Zookeper. Пенальти у нас нет, все цифры производительности — уже с резервированием. Ребилд системы из 20 нодов при вылете жесткого диска одного — около 10 минут.
Ребилд при какой нагрузке? :)
Стандартная типовая нагрузка кластера (читай — чуть свободных мощностей есть). Если их нет — это ошибка дизайна инфраструктуры.
…
Чего уж там, раскидать 1TB данных по кластеру где десятки / сотни дисков в режиме «торрента» (экстент группы по нодам всем размазать) — проблемы большой нет.
Очевидно, что если жесткий прессинг на I/O идет (SATA уровень) — то может быть дольше, чудес тут никто не обещает.
…
Чего уж там, раскидать 1TB данных по кластеру где десятки / сотни дисков в режиме «торрента» (экстент группы по нодам всем размазать) — проблемы большой нет.
Очевидно, что если жесткий прессинг на I/O идет (SATA уровень) — то может быть дольше, чудес тут никто не обещает.
Надежность:
3.5 (текуща стейбл) — выдерживаем единовременный вылет одного нода (любого), после восстановления (обычно очень быстро) консистентности — следующего, и тд.
ребилд системы очень быстр (при достаточном количестве нодов) — по кластеру «размазываются» копии блоков.
4.0 (будет вот-вот) — выдерживаем отказ любых двух нодов одновременно, или (при наличии 3+ блоков) — целого блока (4 нода целиком).
аналогичными показателями выживаемости на рынке никто не обладает (из известных мне решений).
3.5 (текуща стейбл) — выдерживаем единовременный вылет одного нода (любого), после восстановления (обычно очень быстро) консистентности — следующего, и тд.
ребилд системы очень быстр (при достаточном количестве нодов) — по кластеру «размазываются» копии блоков.
4.0 (будет вот-вот) — выдерживаем отказ любых двух нодов одновременно, или (при наличии 3+ блоков) — целого блока (4 нода целиком).
аналогичными показателями выживаемости на рынке никто не обладает (из известных мне решений).
Переживать вылет одной любой ноды умеют любые системы, у которых хоть сколько-то думали про избыточность. Начиная от самых дешёвых лефтхендов и заканчивая нетаппами. Что не мешает быть им унылым дерьмом периодически радующим стейкхолдеров «edge cases» и предложением прислать perfstat при следующей аварии. Это если про энтерпрайз. Если про new wave, то указанная функциональность заявляется для практически всех таких систем. Just for lulz назовём pohmelfs от товарищей, тесно связанных с Яндексом (или даже в нём работающих, я точно не помню). В запасе gluster, wastsky, ceph, ocfs, gfs, etc.
Все далеко не так.
При вылете контроллера одного (и нода) — мы просядем в производительности ровно на проценты (если один нод из 10 — то на 10%).
Вылет второго контроллера никто кто «хоть сколько-то» — не выдержит. Заже NBD не поможет зачастую, ибо это все равно сутки на одном контроллере жить (оставшемся).
Не говоря уже о том что ребилд современной СХД может быть сутки и недели (если вылетела полка например с 24-я дисками).
А мы выдержим без проблем (нам надо считанные минуты в 3.5 чтобы переместить / заместить ключевые сервисы на вылетевшем ноде).
…
Лулзы можно раздавать направо и налево, но всем упомянутым проектам до энтерпрайза — еще дальше чем до луны. Так-же как Openstack пока.
Nutanix работает только на компании начиная с medium, основные клиенты — правительственные службы (США и Европа в основном пока), военные, спецслужбы, энтерпрайзы. Типа Toyota, Kia, Ebay и тд
Мягко говоря — мы говорим о разных критериях производительности и надежности.
Недавний пример — в одном из самых развитых государств в мире государственная мед. система тоже на Nutanix переходят.
…
Есть реальные проекты — берите и тестируйте.
При вылете контроллера одного (и нода) — мы просядем в производительности ровно на проценты (если один нод из 10 — то на 10%).
Вылет второго контроллера никто кто «хоть сколько-то» — не выдержит. Заже NBD не поможет зачастую, ибо это все равно сутки на одном контроллере жить (оставшемся).
Не говоря уже о том что ребилд современной СХД может быть сутки и недели (если вылетела полка например с 24-я дисками).
А мы выдержим без проблем (нам надо считанные минуты в 3.5 чтобы переместить / заместить ключевые сервисы на вылетевшем ноде).
…
Лулзы можно раздавать направо и налево, но всем упомянутым проектам до энтерпрайза — еще дальше чем до луны. Так-же как Openstack пока.
Nutanix работает только на компании начиная с medium, основные клиенты — правительственные службы (США и Европа в основном пока), военные, спецслужбы, энтерпрайзы. Типа Toyota, Kia, Ebay и тд
Мягко говоря — мы говорим о разных критериях производительности и надежности.
Недавний пример — в одном из самых развитых государств в мире государственная мед. система тоже на Nutanix переходят.
…
Есть реальные проекты — берите и тестируйте.
Я, кажется, понял. Для вас слово «энтерпрайз» — синоним слова «крутое и надёжное», а для меня синоним «говно, палки и интеллектуальная собственность в три дорога», плюс «громкое имя», которым удобно прикрывать задницу.
Иметь личное мнение не запретишь.
Похоже до многих так и не дошло что серьезные бизнесы и «наколенное» — это почти взаимоисключающие понятия. SLA готовы подписать с проектом на ceph? Миллионы долларов штрафов выплачивать если SLA нарушите? :)
…
А про опенсорс — мне не надо рассказывать. Я с кластерными ФС уже лет 15 работаю.
Особенно если учитывать что лично я делал тех инфраструктуры пачкк крупных и сверхкрупных онлайн проектов (типа мамбы и badoo), а вся команда Nutanix — из facebook / google / amazon и прочих.
Реально, спорить нечего — мы о разных мирах и вещах.
Похоже до многих так и не дошло что серьезные бизнесы и «наколенное» — это почти взаимоисключающие понятия. SLA готовы подписать с проектом на ceph? Миллионы долларов штрафов выплачивать если SLA нарушите? :)
…
А про опенсорс — мне не надо рассказывать. Я с кластерными ФС уже лет 15 работаю.
Особенно если учитывать что лично я делал тех инфраструктуры пачкк крупных и сверхкрупных онлайн проектов (типа мамбы и badoo), а вся команда Nutanix — из facebook / google / amazon и прочих.
Реально, спорить нечего — мы о разных мирах и вещах.
Ну, скажите, гугль ваши или ваших энтерпрайз конкурентов юзает? Фейсбук? Твиттер? Амазон? Майкрософт (в азуре)? Каждый из них живёт с наколенными поделками. И неплохо. А вот про всякие романтические «мы доверили все наши данные новой суперсистеме за пять миллионов долларов, а она повела себя не так, как объясняли на тренингах для персонала» я вижу довольно регулярно.
Да, насчёт SLA. А вы подпишитесь на миллионные штрафы за найденную багу в софте?
Да, насчёт SLA. А вы подпишитесь на миллионные штрафы за найденную багу в софте?
Я абсолютно «за» наколенные поделки. Если есть деньги держать штат разработчиков / инженеров и это профильный бизнес компании.
Я абсолютно «против» наколенных вещей для непрофильных (читай — не онлайн) бизнесов.
Про «романтику» — у нас данные восстановить можно из любой проблемы практически, ввиду того что базовый уровень — ext4 (надежный как танк) и 3-5 копий метаданных.
За всю историю компании — ни одной потери данных (иначе EMC / Netapp уже бегали бы с большим красным флагом).
Я не говорю что никогда не случится, но мы по дизайну реально в первую очередь на надежность (при крайне высокой производительности) закладывались.
Я абсолютно «против» наколенных вещей для непрофильных (читай — не онлайн) бизнесов.
Про «романтику» — у нас данные восстановить можно из любой проблемы практически, ввиду того что базовый уровень — ext4 (надежный как танк) и 3-5 копий метаданных.
За всю историю компании — ни одной потери данных (иначе EMC / Netapp уже бегали бы с большим красным флагом).
Я не говорю что никогда не случится, но мы по дизайну реально в первую очередь на надежность (при крайне высокой производительности) закладывались.
SLA за баги не подписывают, подписывают за потери данных / простои.
Таким образом, нет никакой разницы, что это пальцатый вендор с миллионными системами, что это apt-get install ceph — у всех жидко протекает, по шее получает IT-отдел или поставщик услуги, а решение проблемы находится в другой плоскости (перестать ожидать от СХД бесконечной надёжности и адаптировать софт).
Я ничего против вас не имею, но я точно могу предсказать по всему своему предыдущему опыту, что у вас протечёт ровно так же, и ровно так же максимум что можно будет добиться, и сообщения о том, что проблему локализовали и устранили в новой версии (это самый лучший сценарий, чаще всего всё затыкается на уровне саппорта, который просит показать, как воспроизвести аварию).
Я ничего против вас не имею, но я точно могу предсказать по всему своему предыдущему опыту, что у вас протечёт ровно так же, и ровно так же максимум что можно будет добиться, и сообщения о том, что проблему локализовали и устранили в новой версии (это самый лучший сценарий, чаще всего всё затыкается на уровне саппорта, который просит показать, как воспроизвести аварию).
Ваш опыт не совпадает с нашим.
Как известно, ошибаться не запретишь ;)
У нас собраны одни из лучших (буквально и дословно) инженеров в индустрии. Включая ключевую команду разработки GoogleFS.
Мы как раз бескончной надежности «СХД» не ожидаем, и решаем проблемы в софте. Если рассуждать кто лучше это сделает — мы или вы, то с чрезвычайно большой вероятностью мы сделаем лучше (бюджеты на R&D, лучшие разработчики и т.д.).
Как известно, ошибаться не запретишь ;)
У нас собраны одни из лучших (буквально и дословно) инженеров в индустрии. Включая ключевую команду разработки GoogleFS.
Мы как раз бескончной надежности «СХД» не ожидаем, и решаем проблемы в софте. Если рассуждать кто лучше это сделает — мы или вы, то с чрезвычайно большой вероятностью мы сделаем лучше (бюджеты на R&D, лучшие разработчики и т.д.).
Вы сумели решить проблему множественных error path? А теорему Райса? (Иными словами, «ключевая команда googlefs» делает ровно такие же ошибки, как и все остальные, и производитель за них никакой ответственности не несёт).
Вы не ожидаете бесконечной надёжности СХД, а (неявно) её обещаете. «У нас не будет отказов из-за софта, потому что „с чрезвычайно большой вероятностью мы сделаем лучше“». А проблема в том, что её не бывает — бесконечной надёжности.
(я как раз недавно про это писал: habrahabr.ru/post/124755/)
Проблема не в вас, а в том, что от вас блочные устройства виртуалок ожидают 0 ошибок на любое количество триллионов операций ввода-вывода.
Вы не ожидаете бесконечной надёжности СХД, а (неявно) её обещаете. «У нас не будет отказов из-за софта, потому что „с чрезвычайно большой вероятностью мы сделаем лучше“». А проблема в том, что её не бывает — бесконечной надёжности.
(я как раз недавно про это писал: habrahabr.ru/post/124755/)
Проблема не в вас, а в том, что от вас блочные устройства виртуалок ожидают 0 ошибок на любое количество триллионов операций ввода-вывода.
Бесконечной надежности — не бывает. Надежность выше — бывает. Вся борьба за те самые «девятки».
Вы можете предусматривать «ненадежность СХД» в вашем ПО сколько угодно, и при этом точно так-же делать косяки.
Вероятность, что у нас лучше разработчики — крайне высокая, ибо как в анекдоте «потому что можем себе позволить».
Да, сейчас Nutanix так же признан одним из самых лучших технологических «стартапов» в Кремниевой как место для работы.
Вы можете предусматривать «ненадежность СХД» в вашем ПО сколько угодно, и при этом точно так-же делать косяки.
Вероятность, что у нас лучше разработчики — крайне высокая, ибо как в анекдоте «потому что можем себе позволить».
Да, сейчас Nutanix так же признан одним из самых лучших технологических «стартапов» в Кремниевой как место для работы.
Максим, по-моему это очевидно, что «миллионы долларов штрафов» уже включены в цену «энтерпрайза».
Если не упало — значит «энтерпрайз» в плюсе, а упало — ну просто вернем клиенту его деньги :)
При условии что у «энтерпрайза» клиентов больше чем один, получается такая себе страховая компания, где риски одного клиента нивелируются деньгами другого. Таким образом сам «энтерпрайз» ничего не платит :)
Если не упало — значит «энтерпрайз» в плюсе, а упало — ну просто вернем клиенту его деньги :)
При условии что у «энтерпрайза» клиентов больше чем один, получается такая себе страховая компания, где риски одного клиента нивелируются деньгами другого. Таким образом сам «энтерпрайз» ничего не платит :)
iSCSI — сам протокол у всех одинаковый, и в данном случае протокол зависит от гипервизора. Отличие от остальных решений, что серверы используются не только как вычислительные узлы гипервизора, но и реализуют отказоустойчивую СХД. За счёт того что данные расположены локально мы получаем большую скорость. За счёт того, что всё реализовано программно — гибкость.
В данном документе чуть более подробно написано как защищаются данные:
go.nutanix.com/TechNoteNutanixSystemReliability_LP.html
Если кратко, в случае отказа возможны 2 варианта:
1) мы теряем один или несколько дисков, или саму CVM Nutanix. Тогда данные запрашиваются с других узлов, средствами MPIO гипервизора происходит переключение, как у обычных СХД. Для ВМ это незаметно, есть деградация по скорости, чем больше узлов тем менее заметная.
2) Если мы теряем целиком узел, то данные ВМ доступны на других узлах, и могу быть там перезапущены — вручную или средствами HA, например.
При это каждый из гипервизоров видит пространство как общедоступный раздел/шару. Поверх этого работают все фичи гипервизора: vMotion/Live migration; HA; SCV; DRS итд.
Что касается скорости — заявлено до 20 000 IOPS на узел. Это синтетика. С точки зрения реально производительности я бы ориентировался, я давал ссылку, вот на это: go.nutanix.com/rs/nutanix/images/Nutanix_VDI_Sizing_Guideline.pdf
5000 реальных, честных IOPS, что очень неплохо.
В данном документе чуть более подробно написано как защищаются данные:
go.nutanix.com/TechNoteNutanixSystemReliability_LP.html
Если кратко, в случае отказа возможны 2 варианта:
1) мы теряем один или несколько дисков, или саму CVM Nutanix. Тогда данные запрашиваются с других узлов, средствами MPIO гипервизора происходит переключение, как у обычных СХД. Для ВМ это незаметно, есть деградация по скорости, чем больше узлов тем менее заметная.
2) Если мы теряем целиком узел, то данные ВМ доступны на других узлах, и могу быть там перезапущены — вручную или средствами HA, например.
При это каждый из гипервизоров видит пространство как общедоступный раздел/шару. Поверх этого работают все фичи гипервизора: vMotion/Live migration; HA; SCV; DRS итд.
Что касается скорости — заявлено до 20 000 IOPS на узел. Это синтетика. С точки зрения реально производительности я бы ориентировался, я давал ссылку, вот на это: go.nutanix.com/rs/nutanix/images/Nutanix_VDI_Sizing_Guideline.pdf
5000 реальных, честных IOPS, что очень неплохо.
Господа из Advanserv
Во-первых, спасибо за приятные слова про Nutanix
Во-вторых, у вас _крайне_ большое количество неточной в статье, да и в комментариях много серьезнейших ошибок.
Было-бы лучше если сначала тех. вопросы уточняли у меня например ;)
Во-первых, спасибо за приятные слова про Nutanix
Во-вторых, у вас _крайне_ большое количество неточной в статье, да и в комментариях много серьезнейших ошибок.
Было-бы лучше если сначала тех. вопросы уточняли у меня например ;)
Будет ещё лучше, если вы напишите внятное описание алгоритмов распределения блоков, пересчёта хэшринга, хранения метаданных и т.д.
Что-то напишем, что-то — наше ноу-хау.
Метаданные / кассандру мы не закрываем, можно зайти на любой контроллер и посмотреть работу всей кассандры и содержимое (nodetool и тд)
Метаданные / кассандру мы не закрываем, можно зайти на любой контроллер и посмотреть работу всей кассандры и содержимое (nodetool и тд)
«Зайти и посмотреть» — это значит, зарыться в продукт по уши. А мы пока что про мимо проходящих людей говорим.
Почему ваше решение интереснее, чем ceph?
Почему ваше решение интереснее, чем ceph?
ceph имеет интеграцию с ESXi, HyperV? энтерпрайз поддержку «единое окно»? держит 400+ виртуалок на коробку 2U?
… я наверное сильно отстал от жизни :D
еще раз — мы не СХД. даже так — МЫ НЕ СХД :)
мы — ковергентная платформа. заточенная под промышленные применения.
ceph — просто файловая система. неплохая в целом, но с большой кучей архитектурных проблем.
…
если вы делаете онлайн проект большой — на Nutanix точно не смотрите, вы не наш клиент, только опенсорс и хардкор.
если что-то «энтерпрайзное» нужно — чрезвычайно компактное, надежное, быстрое (при этом весьма недешевое) — обращайтесь, обсудим детали.
… я наверное сильно отстал от жизни :D
еще раз — мы не СХД. даже так — МЫ НЕ СХД :)
мы — ковергентная платформа. заточенная под промышленные применения.
ceph — просто файловая система. неплохая в целом, но с большой кучей архитектурных проблем.
…
если вы делаете онлайн проект большой — на Nutanix точно не смотрите, вы не наш клиент, только опенсорс и хардкор.
если что-то «энтерпрайзное» нужно — чрезвычайно компактное, надежное, быстрое (при этом весьма недешевое) — обращайтесь, обсудим детали.
ceph имеет интеграцию с ESXi, HyperV? энтерпрайз поддержку «единое окно»? держит 400+ виртуалок на коробку 2U?
да =)
Поверх можно навинтить что угодно, от проксмокса до вмвари и иметь абсолютно то же. Дьявол будет в деталях типа цифер латенси, SLA по латенси и по бендвизу при восстановлении/перестроении итд. Нужны бенчмарки, чтобы сравнивать предметно.
Можно. Как внешнюю СХД, с ужасной производительностью, большими потерями на электричестве и месте в датацентре.
Про SLA — абсолютно верно. Смотрите бенчмарки / гайдансы и прочее, при наличии серьезного проекта — брать и тестровать.
SAP и SAP Hana на нас тоже вот-вот будет сертифицирован.
Про SLA — абсолютно верно. Смотрите бенчмарки / гайдансы и прочее, при наличии серьезного проекта — брать и тестровать.
SAP и SAP Hana на нас тоже вот-вот будет сертифицирован.
Мм, почему ужасной? Производительность чтения или записи 70-80 процентов от сырой скорости носителей с учетом уровня репликации, плюс высокая степень агрегирования операций. Иопсы получаются, конечно, на небольших масштабах не космические, но достичь 100к/клиента с 3-4 нодами возможно при использовании тьеризованного хранилища. Инктанк к тому же довольно бодро закрывает проблемы, вылезающие у клиентов на контрактах, так что уровень поддержки примерно тот же, что и во всем «хорошем» энтерпрайзе.
Ниже написали.
И я ответил.
В случае с KVM и нативным монтированием Ceph ситуация чуть получше, согласен / не спорю.
KVM в «энтерпрайзах» пропишется ой не скоро.
И я ответил.
В случае с KVM и нативным монтированием Ceph ситуация чуть получше, согласен / не спорю.
KVM в «энтерпрайзах» пропишется ой не скоро.
Зависит от клиента. Если хотят получить lowlat виртуалки — только виндривер, если хотят порезать ценник — можно поставить опинстек и сэкономить на нанятом десятке инженеров относительно лицензий на вмварь на тех же масштабах итд. С совсем закостенелым бизнесом возиться неохота, хотя они, наверное, самые денежные в расчете на килобайт-место решения :)
Логично.
А вы считали, сколько вам обойдется Ceph с коммерческой поддержкой, и еще и сервера для гипервизоров?
При том что это будет минимум в два раза больше по потреблению и в разы — по месту в ДЦ?
Ну вот взять нашу коробку 2U — NX1450. До 200 виртуалок, потребление — менее киловатта (!), 2U места в стойке.
8x10G интерфейсы (адвансерв некорректно написал, у нас на 1050 поддерживается 1G, но при этом все 10G присутствуют)
16TB + 400G*4 SSD — места на «СХД» c тирингом.
GPL — 100$k. По GPL понятно что мало кто берет.
Ну и кому реально нужен ceph-то? Без шуток, много клиентов в РФ хотя-бы? Там же тупо в пару раз больше «железа» понадобится. И кормить потом ДЦ.
А вы считали, сколько вам обойдется Ceph с коммерческой поддержкой, и еще и сервера для гипервизоров?
При том что это будет минимум в два раза больше по потреблению и в разы — по месту в ДЦ?
Ну вот взять нашу коробку 2U — NX1450. До 200 виртуалок, потребление — менее киловатта (!), 2U места в стойке.
8x10G интерфейсы (адвансерв некорректно написал, у нас на 1050 поддерживается 1G, но при этом все 10G присутствуют)
16TB + 400G*4 SSD — места на «СХД» c тирингом.
GPL — 100$k. По GPL понятно что мало кто берет.
Ну и кому реально нужен ceph-то? Без шуток, много клиентов в РФ хотя-бы? Там же тупо в пару раз больше «железа» понадобится. И кормить потом ДЦ.
Кстати, монтировать как собрались? NFS3 не параллелизуемый? NFS4 который никто не поддерживает до сих пор (типа ESXi)? SMB3?
Да, мы например с нуля свою реализацию SMB3 написали. Раза в 3 быстрее Самбы работает.
в 3.5.2 была самба, достала нас ужасно, за 3 месяца написали свое.
Да, мы например с нуля свою реализацию SMB3 написали. Раза в 3 быстрее Самбы работает.
в 3.5.2 была самба, достала нас ужасно, за 3 месяца написали свое.
Для клоузедсерся — iscsi реэкспорт, для кему и виндривер кему — нативно через драйвер эмулятора. Позиксфс слой втыкать — куча геморроя на ровном месте, сорри, от этого надо уходить.
Угу. Вот и я говорю, ceph + гипервизоры (кроме KVM / Openstack) — это для любителей большого топора и ножовки.
Нативно ни на один коммерческий (читай — самый распространенный в энтерпрайзе / правительстве / военных) — смонтировать не получится.
Куча бубнов с плясками и наслоениями протоколов. При том что iSCSI реэкспорт будет упираться все равно в производительность конкретных нодов через которые он смонтирован (никаких сотен тысяч / миллионов IOPS и близко не будет).
Нативно ни на один коммерческий (читай — самый распространенный в энтерпрайзе / правительстве / военных) — смонтировать не получится.
Куча бубнов с плясками и наслоениями протоколов. При том что iSCSI реэкспорт будет упираться все равно в производительность конкретных нодов через которые он смонтирован (никаких сотен тысяч / миллионов IOPS и близко не будет).
Реэкспорт упирается в производительность сети ноды-реэкспортера, для небольших бандлов, о которых идет речь(десяток-два нод плюс 10/40г бекнет) этот факт не будет иметь никакого значения, операции так же будут размазываться по всем машинам. Более того, при очень небольшом желании можно сделать эту процедуру автоматизированной и убрать видимость плясок. Миллионы иопсов в одном клиенте никому в принципе не нужны, даже требовательным телекомам, а сто тысяч получится сделать в таких масштабах на сата дисках.
В случае с внешней СХД — никто не будет брать Ceph для серьезных задач, возьмут Netapp / EMC / Hitachi / прочие и будут правы.
Возможно, лет через 5-10 все и изменится…
Еще раз — просьба понять, что для бизнеса — потратить несколько сотен тысяч / миллионов долларов на коммерческую технологию — не проблема, но иметь малейшие ненужные риски «наколенных» и зависеть от инженеров своих (которые требуются весьма квалифицированные) — никто не будет.
Ровно так-же как сравнивать parrot drone за 300$ и квадрокоптеры профессиональные для МЧС за 70.000$k.
Похожие технологии, разные рынки и клиенты, разные надежности и возможности.
Возможно, лет через 5-10 все и изменится…
Еще раз — просьба понять, что для бизнеса — потратить несколько сотен тысяч / миллионов долларов на коммерческую технологию — не проблема, но иметь малейшие ненужные риски «наколенных» и зависеть от инженеров своих (которые требуются весьма квалифицированные) — никто не будет.
Ровно так-же как сравнивать parrot drone за 300$ и квадрокоптеры профессиональные для МЧС за 70.000$k.
Похожие технологии, разные рынки и клиенты, разные надежности и возможности.
Ну вот один очень серьезный телеком(в топ5 по разрабатываемому софту) колеблется между цефом и гластером для своего решения. Полки невозможно перепродать в составе решения из-за ценника, ну или решение будет очень ограниченным. Плюс, начиная с определенного масштаба решения, инженеры обходятся дешевле.
Для телеком облака — мы зачастую очень хорошо подходим. Чисто если все подсчитать корректно (особенно — стойко-места и электричество не забыть). Инженеры обходятся дешевле — пока не легло все капитально.
В РФ я ни одного «серьезного телекома» не знаю без серьезнейших пролежек (кроме N1 разве что).
Говоря откровенно — крупнейший (top-1 :D ) телеком в РФ сейчас с нами активно сотрудничает и особо не скрывают этого. Как минимум очень серьезно рассматривают нас как вариант (один из основных).
Про ceph и gluster никто даже не вспоминает — не тот уровень надежности.
В РФ я ни одного «серьезного телекома» не знаю без серьезнейших пролежек (кроме N1 разве что).
Говоря откровенно — крупнейший (top-1 :D ) телеком в РФ сейчас с нами активно сотрудничает и особо не скрывают этого. Как минимум очень серьезно рассматривают нас как вариант (один из основных).
Про ceph и gluster никто даже не вспоминает — не тот уровень надежности.
В мировом top5 :)
А вы дважды упомянули электричество — эти супермикры отличаются от своих собратьев чем-то? Если совмещать роль вычислительной и сторож ноды, на питании придется сэкономить ровно 0 — машины будут гвоздями прибиты к C0, чтобы не ронять производительность виртуалок.
А вы дважды упомянули электричество — эти супермикры отличаются от своих собратьев чем-то? Если совмещать роль вычислительной и сторож ноды, на питании придется сэкономить ровно 0 — машины будут гвоздями прибиты к C0, чтобы не ронять производительность виртуалок.
Ну, с мировыми топами у нас тоже более чем хорошо. Например один из самых больших bigdata кластеров (мы умеем подменять HDFS нашим NDFS для базового map/reduce с ускорением в 2-3 раза как минимум, зачастую — в 10 раз).
На питании — вы попадаете очень сильно в случае если гипервизоры типа ESXi / HyperV (сиречь — отдельные сервера от ceph кластера с реекспортами iSCSI и прочей мишурой).
В случае телекома огромного который строит свой Amazon — ceph может быть вполне разумен, спорить с этим глупо (я сам строил мега-кластера на опенсорсе, и не в РФ).
На питании — вы попадаете очень сильно в случае если гипервизоры типа ESXi / HyperV (сиречь — отдельные сервера от ceph кластера с реекспортами iSCSI и прочей мишурой).
В случае телекома огромного который строит свой Amazon — ceph может быть вполне разумен, спорить с этим глупо (я сам строил мега-кластера на опенсорсе, и не в РФ).
Реэкспортеры висят на сторож нодах и места/ресурсов не едят. Вся моя риторика сводится к тому, что опенсерсный цеф, в принципе, равен по надежности и по производительности вашему решению и уступает только в отдельных фичах, которых там просто нет из-за ориентации в другую сторону. Риски заложить каждый может сам после тестирования, ну или если контора довольно небольшая или специализированная в ином направлении, т.е. без возможности проведения экспертизы хранилища, купить не глядя энтерпрайз.
Нет, ни по надежности ни по производительности он не равен. Мы имеем большие лаборатории, где регулярно все тестируем — в том числе опенсорс.
Прежде чем вам делать неверные _предположения_ — крайне желательно протестировать сначала и то и другое, затем уже говорить.
В реальность чуть ближе к нам будет только на KVM, и то весьма относительно.
Я понимаю желание защитить то что привычно (пришли тут какие-то Nutanix :) ), но надо объективнее.
Прежде чем вам делать неверные _предположения_ — крайне желательно протестировать сначала и то и другое, затем уже говорить.
В реальность чуть ближе к нам будет только на KVM, и то весьма относительно.
Я понимаю желание защитить то что привычно (пришли тут какие-то Nutanix :) ), но надо объективнее.
Откровенно говоря, я ничто, кроме KVM, и не рассматриваю. Все прочее за цену решениеспецифичных фич требует очень больших доплат, которые вылезут боком для меня. Цифры на цефе и у вас отличаются в примерно полтора раза для масштаба «десяток серверов», при этом на фиошных тестах не было задачи выбить максимальные цифры. Цеф надо очень сильно докручивать, да, это же опенсорц решение — из коробки цифры у него совершенно далекие от максимальных.
В EU чрезвычайно крупный телеком нас тоже выбрал (Франция), на KVM.
в Японии — та-же cитуация (крупнейший телеком, KVM кластер, мы собственно под них делали поддержку KVM).
в Китае — мы признаны лучшими для построения ДЦ нового поколения.
www.nutanix.com/2013/11/14/nutanix-wins-chinas-hpc-annual-big-data-infrastructure-award/
www.nutanix.com/2013/09/12/nutanix-wins-china-computerworld-award/
Gartner нас назвал Cool Vendor 2013 (Servers).
Далее. Если этот top-5 телеком рассматривает решения — то мы можем продать только ПО.
Экономика там меняется колоссально, но смысл имеется только от сотен нодов.
в Японии — та-же cитуация (крупнейший телеком, KVM кластер, мы собственно под них делали поддержку KVM).
в Китае — мы признаны лучшими для построения ДЦ нового поколения.
www.nutanix.com/2013/11/14/nutanix-wins-chinas-hpc-annual-big-data-infrastructure-award/
www.nutanix.com/2013/09/12/nutanix-wins-china-computerworld-award/
Gartner нас назвал Cool Vendor 2013 (Servers).
Далее. Если этот top-5 телеком рассматривает решения — то мы можем продать только ПО.
Экономика там меняется колоссально, но смысл имеется только от сотен нодов.
Ну вот жидко какающий нетапп я своими глазами видел. Было грустное зрелище. А продавали-то как…
Создавать пачки iSCSI реэкспортов для каждого гипервизора — не выйдет.
iSCSI экспорт должен быть shared, так что ВСЕ ноды кластера (гипервизоры) будут завязаны на производительность и надежность конкретных нодов Ceph кластера. Да еще и ввод-вывод уже будет упираться в сетевые интерфейсы (вместо локализации). Это называется — от чего убегали, к тому и приходим обратно.
Это — мало кому нужный ахтунг. Netapp сильно лучше сделает это, право :).
Про маленькие кластеры и клиенты мы не говорим — откровенно, если нет 100$k минимального бюджета на проект — на нас лучше не смотреть.
iSCSI экспорт должен быть shared, так что ВСЕ ноды кластера (гипервизоры) будут завязаны на производительность и надежность конкретных нодов Ceph кластера. Да еще и ввод-вывод уже будет упираться в сетевые интерфейсы (вместо локализации). Это называется — от чего убегали, к тому и приходим обратно.
Это — мало кому нужный ахтунг. Netapp сильно лучше сделает это, право :).
Про маленькие кластеры и клиенты мы не говорим — откровенно, если нет 100$k минимального бюджета на проект — на нас лучше не смотреть.
Нет, почему. Туда опять же вставляется multipath и получается красивая и удобная штука с нулевым временем простоя. Условно говоря, набросать базовый алгоритм разложения активного и бекап пути для каждого из вольюмов на сторожноды можно за день. При отсутствии перекосов (1 клиент потребляет 90 процентов бендвиза) решение мало чем будет отличаться по надежности от нативного драйвера, разве что обеспечивать его будет неэнтерпрайзный питонячий скрипт. Локализация — путь гластера, и это плохо — нода шлепается, и все обращения к конкретному набору данных подвстают раком, не очень это хорошо.
Ceph в масштабах стойки/полки/whatever позволяет получить значения, близкие к параметрам энтерпрайз полок за десятикратно меньшую цену, с той же надежностью. Говорить о том, что он намного хуже работает — бессмысленно, надежность работы софта — да, чуть ниже, если использовать текущую стабильную ветку. Тут дискуссия уже перейдет в то, что будет, если заплатить за поддержку верхнего уровня у инктанка, но в этом, как правило, нет никакой необходимости.
Ceph в масштабах стойки/полки/whatever позволяет получить значения, близкие к параметрам энтерпрайз полок за десятикратно меньшую цену, с той же надежностью. Говорить о том, что он намного хуже работает — бессмысленно, надежность работы софта — да, чуть ниже, если использовать текущую стабильную ветку. Тут дискуссия уже перейдет в то, что будет, если заплатить за поддержку верхнего уровня у инктанка, но в этом, как правило, нет никакой необходимости.
Любой мультипас (нам он кстати не нужен) — дополнительные проблемы, все равно упор в конкретные ноды (даже если пачку мультипасов делать, хотя обычно более 2-х — никто не рекомендует) и «подвисания» I/O на время отработки failover.
Далее, на HyperV некоторый (и очень интересный клиентам) функционал вообще чисто на SMB3 только работает.
Про энетрпрайз полки (и сервера) — мы точно так-же дешевле выходим в разы зачастую.
У нас стойка выдаст 2 миллиона IOPS на ура. При этом будут терабайты RAM и сотни процессорных ядер для работы приложений. На ceph-же будет только хранение.
Не надо теплое и мягкое плз ;)
Если нужна чисто хранилка без compute — ceph очень хорош, никто не спорит.
Далее, на HyperV некоторый (и очень интересный клиентам) функционал вообще чисто на SMB3 только работает.
Про энетрпрайз полки (и сервера) — мы точно так-же дешевле выходим в разы зачастую.
У нас стойка выдаст 2 миллиона IOPS на ура. При этом будут терабайты RAM и сотни процессорных ядер для работы приложений. На ceph-же будет только хранение.
Не надо теплое и мягкое плз ;)
Если нужна чисто хранилка без compute — ceph очень хорош, никто не спорит.
Хорошо, ну допустим для hyper-v и esx ваше решение будет работать только как внешняя хранилка(или esx превратится в тыкву при совмещении, хотя платформа примерно та же). В случае с кему мне ничто не мешает иметь совмещенное решение. Если честно, не представляю, как nutanix, пусть даже при наличии перебегающего между нодами айпи и сопутствующих доделок в серверной части работает лучше, чем мультипуть, если рассматривать работу с тем же айскази, при отказе ноды в плане затупов.
налицо непонимание нашей архитектуры, но это нормально — многим мозг взрывает :)
лучше — потому что каждый нод физический имеет _локальный_ контроллер и _локальный_ I/O (с сохраниением копий данных на соседние ноды).
на ESXi / HyperV мы монтируемся локально (сам с себя нод монтирует), скорость — ограничние работы процессора / памяти / PCI шины.
ESXi монтирует NFS3 датастор с виртуалки запущенной на нем самом, через логический коммутатор без физических интерфейсов. HyperV тоже самое, но по SMB3 (который мы написали). KVM — iSCSI (бинго!).
100 нодов — 100 NFS / SMB3 / iSCSI «потоков». 1000 нодов — 1000 потоков («путей»). Мы превращаем старые надежные протоколы в суперпроизводительные просто за счет логики.
Адреса везде одинаковые — 192.168.5.2 (на каждом виртуальном контроллере поднят). Поэтому для гипервизора мы shared.
Это — уникальная архитектура. Никаких тыкв.
лучше — потому что каждый нод физический имеет _локальный_ контроллер и _локальный_ I/O (с сохраниением копий данных на соседние ноды).
на ESXi / HyperV мы монтируемся локально (сам с себя нод монтирует), скорость — ограничние работы процессора / памяти / PCI шины.
ESXi монтирует NFS3 датастор с виртуалки запущенной на нем самом, через логический коммутатор без физических интерфейсов. HyperV тоже самое, но по SMB3 (который мы написали). KVM — iSCSI (бинго!).
100 нодов — 100 NFS / SMB3 / iSCSI «потоков». 1000 нодов — 1000 потоков («путей»). Мы превращаем старые надежные протоколы в суперпроизводительные просто за счет логики.
Адреса везде одинаковые — 192.168.5.2 (на каждом виртуальном контроллере поднят). Поэтому для гипервизора мы shared.
Это — уникальная архитектура. Никаких тыкв.
А как обеспечивается консистентность резервных копий в этом случае? Примерно такой же подход в плане локализованности данных исповедует гластер, но, повторюсь, это не очень удобно, по хотя бы тем соображениям, что перекосы в нагрузке придется время от времени балансировать миграциями. У нас была в свое время идея модицифировать алгоритм распределения данных в цефе для стопроцентной локализации, но по итогу это оказалось не нужным — латенси сети вводит задержки около миллисекунды для операций, а ее насыщение во всех случаях наступит примерно одновременно из-за трафика копий.
Констинтетность — нет подтверждения записи (в гостевую ОС) (softupdates) пока не прошло на других нодах запись копий. Поэтому на запись 40.000 IOPS на блок, а на чтение — 100.000+
Данные ездят вслед за виртуалкой (мы все автоматом сами делаем) — при переезде VM на другой нод, данные локализуются там максимально быстро.
Есть кластера на десятки тысяч виртуалок.
Про сеть — мир меняется :)
Наш глобальный партнер, Arista Networks (подавляющее большинство наших инсталляций — на аристах) — коммутаторы 320-350нс имеют (скорость коммутации / маршрутизации, L2-L4), при смешной цене (24 wire rate порта — GPL прайс аля 12$k).
Данные ездят вслед за виртуалкой (мы все автоматом сами делаем) — при переезде VM на другой нод, данные локализуются там максимально быстро.
Есть кластера на десятки тысяч виртуалок.
Про сеть — мир меняется :)
Наш глобальный партнер, Arista Networks (подавляющее большинство наших инсталляций — на аристах) — коммутаторы 320-350нс имеют (скорость коммутации / маршрутизации, L2-L4), при смешной цене (24 wire rate порта — GPL прайс аля 12$k).
Еще есть стек на самих машинах, который вносит задержку, я указал все вместе. К слову, это дорого за 24 порта, трайдент2 стоит столько же, портов в два раза больше, умеет плюс-минус то же, что и ариста. Да, и как вы получаете в случае синхронного коммита на копии с TCP стеком латенси внутри 10мс?
… зевая… — GPL ключевое слово :)
трайдент не умеет дофига. и по лейтенси только в теории близко. это опять примерно как ceph vs NDFS :)
Arista взяли Interop 2013. Читай — лучший коммутатор в мире.
www.aristanetworks.com/en/news/pressrelease/572-pr-20130508-01
“The 7500E is the winner in both the Networking and Grand Award categories, and its impressive specs are part of the reason,”
трайдент не умеет дофига. и по лейтенси только в теории близко. это опять примерно как ceph vs NDFS :)
Arista взяли Interop 2013. Читай — лучший коммутатор в мире.
www.aristanetworks.com/en/news/pressrelease/572-pr-20130508-01
“The 7500E is the winner in both the Networking and Grand Award categories, and its impressive specs are part of the reason,”
Ариста его взяла по умению прыгать через палку с надписью опенфлоу лучше остальных. Для коммодити — слишком дорого, для простого свичинга трайдент куда дешевле. Да, и у меня нет возможности заходить сзади с порезанным надвое прайсом, потому я смотрю только на gpl.
Ариста даже в наших прайсах есть.
А по GPL берут только очень редкие клиенты, я бы сказал — уникальные ;) Их надо холить и лелеять.
Вы пишите, мы если что направим к кому надо.
Ариста — не простой свитчинг. Ключевое — лейтенси и архитектура ОС (они — ультрастабильны и быстры).
Openflow там имеет отношение только к одной категории. Ариста взяла в двух главных.
А по GPL берут только очень редкие клиенты, я бы сказал — уникальные ;) Их надо холить и лелеять.
Вы пишите, мы если что направим к кому надо.
Ариста — не простой свитчинг. Ключевое — лейтенси и архитектура ОС (они — ультрастабильны и быстры).
Openflow там имеет отношение только к одной категории. Ариста взяла в двух главных.
Замещаем на SKALA-R
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Забудь про СХД. Nutanix – революция в виртуализации