Чад, и чего же ты хочешь сказать этим заголовком?
На прошлой неделе у меня была дискуссия с японскими партнерами на тему программно-определяемых хранилищ. Обсудили, что EMC делает в этом направлении, а также поделились мыслями по поводу того, что следует делать партнерам. Интересно, что они были полностью сконцентрированы на экономических моделях применения связки «софт + сервер общего назначения». Казалось, они даже находили отличия этих моделей от других там, где я различий вообще не видел.
А за неделю до этого – когда я был в Австралии – у меня было множество разговоров с клиентами на тему сценариев разворачивания Hadoop. В частности, речь шла о том, когда имеет смысл использовать для этого Isilon. Все клиенты мыслили одинаково: взять дистрибутив и проинсталлировать его на коробочные сервера. Поначалу они никак не могли принять идею, что решение на базе Исилона может быть лучше, производительнее и дешевле. Но все-таки они к этому пришли.
… И еще на той же неделе – на конференции VMUG в Сиднее – у меня были интересные дискуссии о VSAN, ScaleIO и о программно-аппаратных комплексах Nutanix и Solidfire в сравнении с чисто софтовыми решениями.
Основная загвоздка во всех этих разговорах была одна: людям тяжело принять одну ОЧЕНЬ, ОЧЕНЬ простую вещь:
Замечу: «по большей части» означает, что существуют категории и архитектуры, которые включают либо уникальное оборудование, либо стандартное оборудование, которое настолько специфично (например, соединение узлов XtremIO или VMAX3 через InfiniBand), что отделение софта от харда не имеет смысла. (Кстати, по моей классификации, это архитектуры «Второго типа» — «горизонтально масштабируемые кластеры с тесными связями»).
Люди в корне нелогичны… ХАН!!! (Слава тебе Леонард Нимой – живи долго и процветай в наших сердцах!)
Ах, люди. Мы застреваем на визуализациях, зацикливаемся на физическом концепте вещей. Нам сложно думать об архитектуре систем в терминах того, как они ФУНКЦИОНИРУЮТ, а не в терминах того, как они УПАКОВЫВАЮТСЯ.
Позвольте мне здесь проиллюстрировать – показать, что я вообще имею в виду! Продолжайте читать – и вы поймете реальность!
Положим, мне необходимо развернуть Hadoop кластер. Петабайт на 5. Для этого я должен продумать сложные связи, вычислительную инфраструктуру и стэйджинг (staging – закачка данных в Hadoop кластер из той среды, где данные были сгенерированы или хранятся. Прим. перев.)
Если бы я был на месте большинства, то взял бы дистрибутив, а также серверы и компоненты сетевой инфраструктуры. Я бы, вероятно, начал с маленького кластера, а затем его наращивал. Я бы, вероятно, использовал серверы, монтируемые в стойки. А для грубой прикидки размера кластера использовал бы стандартные соотношения для количества дисков на сервер. И я вижу, что многие так и поступают.
Если исходить из такого сценария, то скажи вам кто-нибудь «вы знаете… если бы вы: 1) виртуализировали узлы Hadoop с помощью vSphere и Big Data Extensions – не для консолидации, а для лучшей управляемости; и 2) вместо стоечных серверов использовали Cisco UCS; и 3) вместо того, чтобы пихать пачки дисков в стоечные сервера, использовали EMC Isilon – если бы вы сделали эти три вещи, решение было бы в два раза быстрее, в два раза компактнее и в два раза дешевле в терминах совокупной стоимости владения» — ну… если бы вам кто-нибудь это сказал, вы бы решили, что он вдребезги пьян.
Но оказывается, что приведенное утверждение – правда.
Конечно, не для всех. Однако оно правдиво для интересного случая, разобранного по ссылке. Это случай реального клиента, Hadoop кластер которого разросся до 5 петабайт. Результаты по ссылке – это результаты их собственного тестирования (спасибо Дэну Береслу и Крису Бёрдвелу за то, что поделились). Клиент, о котором идет речь, — это огромная телекоммуникационная компания. Вам доступны подробные результаты тестирования, включая тестирование производительности.
А теперь интересное наблюдение: многим тяжело думать об Isilon как об HDFS-хранилище (HDFS – распределенная файловая система в составе Hadoop – прим. перев.), потому что он «выглядит» как аппаратный комплекс, а не как стандартные сервера общего назначения, несущие на себе нужный софт.
Часто клиенты, начиная работу с Hadoop, думают «Мне нужна стандартная аппаратная платформа».
Однако НЕ стоит судить книжку по обложке. «Роза пахнет розой, хоть розой назови её, хоть нет».
Взгляните на эти картинки:
Когда вы на них смотрите, вы, наверное, думаете: «Стандартные промышленные сервера».
… А теперь позвольте мне показать их лицевую сторону:
Когда вы на них смотрите, то, вероятно, думаете: «Аппаратный комплекс».
Но в обоих случаях вы смотрите на одно и то же.
Программное обеспечение под названием OneFS – это то, что дает Исилону его мощь. Подача Исилона в виде программно-аппаратного комплекса – следствие желания клиентов покупать (и поддерживать) его именно таким способом.
В разобранном по ссылке случае с HDFS, виртуализированная конфигурация на базе UCS и Исилон стала такой быстрой (в 2 раза быстрее!), компактной (в 2 раза компактнее!) и экономичной (в 2 раза экономичнее!) за счет программных функций Исилона:
… в случае телеком-клиента не было никакой магии со стороны железа (хотя был некоторый выигрыш от использования UCS. Он произошел за счет более плотной упаковки вычислительных мощностей. Отказ от локальных дисков позволил нам заменить рэковые сервера на блейды).
Во всей этой истории есть веселый момент. Скажи мы клиентам: «Вот вам программная реализация HDFS со всеми перечисленными выше свойствами, ставьте ее на свое железо» – клиенты более охотно начали бы использовать ONEFS. Им бы не пришлось столкнуться со сложностями, которые несут в себе локальные диски. Масштабирование HDFS стало бы для них менее болезненным.
Так почему же мы не делаем этого? Ответ приведен на диаграмме ниже:
Я постоянно веду этот странный диалог с клиентами. Они начинают с того, что «Я не хочу аппаратный комплекс» (ага, тогда «Вот вам ScaleIO/VSAN и Исилон в виде софта»), и затем приходят к тому, что просят аппаратный комплекс :-) Это настолько же предсказуемо, как то, что солнце взойдет на востоке. Из-за подобных диалогов, Solidfire недавно объявил о выпуске софтовой версии их продукта (готов поспорить, что продажи будут низкими, по сравнению с продажами их комплекса), а Nutanix даже начинал с чисто программных решений (а закончил комплексными). По этим же причинам, для успешного старта VSAN понадобились специальные «Узлы под VSAN» (VSAN Ready Nodes – прим. пер.) И я подозреваю, что уже скоро очень существенное потребление VSAN будет идти через комплексные решения вроде VSPEX Blue. Конечно же, такой вариант использования будет более популярным, чем вариант «установи VSAN на свое железо». То же самое справедливо и для ScaleIO.
Почему?
Ответ следующий:
Однако не поймите меня неправильно. Идея ПО, непривязанного к железу, все же важна.
Такой софт можно использовать множеством различных способов. Если ПО существует отдельно от железа, то его можно заполучить без «лишних довесков» для того, чтобы изучить, попробовать, поиграться, использовать в работе – но без поддержки. За поддержку в любом случае придется кому-то платить (независимо от того, идет ли речь об открытом или закрытом коде).
По всем этим причинам и многим другим, все ПО EMC станет постепенно доступным «без довесков», и в некоторых случаях, возможно даже, с открытым кодом.
Кстати, все сказанное не означает, что в мире железа не осталось места инновациям. Перед вами новейший узел Isilon HD, с декоративными панелями и без них:
Легко понять, почему он носит кодовое имя «Колосс». Диски установлены вертикально, так же, как и кожухи для их плотной упаковки: Viking @ 120 x 2.5” SSD/HDD и Voyager @ 60 x 3.5” HDD. Каждый узел Исилона нуждается еще и в вычислительных мощностях. Они размещены в этом же корпусе размера 4U. В итоге, имеем до 376ТБ в одном корпусе, что очень плотненько и очень клево. Этот узел разработан для гипер-емких конфигураций и для архивного использования.
Только взгляните на все это! Программно-определяемые хранилища восхитительны. И то, что их можно развернуть множеством различных способов вплоть до собственного железа — просто замечательно. Вместе с тем, я думаю, что в обозримом будущем наиболее предпочтительными моделями использования программно-определяемых хранилищ останутся комплексные решения и конвергентная/гиперконвергентная инфраструктура.
Ваши мысли?
(Об Исилон и HDFS читайте также в нашем блоге: Рецепт «Быстрых данных» на основе решения для больших данных — прим. пер.)
На прошлой неделе у меня была дискуссия с японскими партнерами на тему программно-определяемых хранилищ. Обсудили, что EMC делает в этом направлении, а также поделились мыслями по поводу того, что следует делать партнерам. Интересно, что они были полностью сконцентрированы на экономических моделях применения связки «софт + сервер общего назначения». Казалось, они даже находили отличия этих моделей от других там, где я различий вообще не видел.
А за неделю до этого – когда я был в Австралии – у меня было множество разговоров с клиентами на тему сценариев разворачивания Hadoop. В частности, речь шла о том, когда имеет смысл использовать для этого Isilon. Все клиенты мыслили одинаково: взять дистрибутив и проинсталлировать его на коробочные сервера. Поначалу они никак не могли принять идею, что решение на базе Исилона может быть лучше, производительнее и дешевле. Но все-таки они к этому пришли.
… И еще на той же неделе – на конференции VMUG в Сиднее – у меня были интересные дискуссии о VSAN, ScaleIO и о программно-аппаратных комплексах Nutanix и Solidfire в сравнении с чисто софтовыми решениями.
Основная загвоздка во всех этих разговорах была одна: людям тяжело принять одну ОЧЕНЬ, ОЧЕНЬ простую вещь:
Системы хранения (по большей части) построены по схеме «софт + коробочный сервер». Просто они УПАКОВЫВАЮТСЯ и ПРОДАЮТСЯ в форме программно-аппаратных комплексов.
Замечу: «по большей части» означает, что существуют категории и архитектуры, которые включают либо уникальное оборудование, либо стандартное оборудование, которое настолько специфично (например, соединение узлов XtremIO или VMAX3 через InfiniBand), что отделение софта от харда не имеет смысла. (Кстати, по моей классификации, это архитектуры «Второго типа» — «горизонтально масштабируемые кластеры с тесными связями»).
Люди в корне нелогичны… ХАН!!! (Слава тебе Леонард Нимой – живи долго и процветай в наших сердцах!)
Ах, люди. Мы застреваем на визуализациях, зацикливаемся на физическом концепте вещей. Нам сложно думать об архитектуре систем в терминах того, как они ФУНКЦИОНИРУЮТ, а не в терминах того, как они УПАКОВЫВАЮТСЯ.
Позвольте мне здесь проиллюстрировать – показать, что я вообще имею в виду! Продолжайте читать – и вы поймете реальность!
Положим, мне необходимо развернуть Hadoop кластер. Петабайт на 5. Для этого я должен продумать сложные связи, вычислительную инфраструктуру и стэйджинг (staging – закачка данных в Hadoop кластер из той среды, где данные были сгенерированы или хранятся. Прим. перев.)
Если бы я был на месте большинства, то взял бы дистрибутив, а также серверы и компоненты сетевой инфраструктуры. Я бы, вероятно, начал с маленького кластера, а затем его наращивал. Я бы, вероятно, использовал серверы, монтируемые в стойки. А для грубой прикидки размера кластера использовал бы стандартные соотношения для количества дисков на сервер. И я вижу, что многие так и поступают.
Если исходить из такого сценария, то скажи вам кто-нибудь «вы знаете… если бы вы: 1) виртуализировали узлы Hadoop с помощью vSphere и Big Data Extensions – не для консолидации, а для лучшей управляемости; и 2) вместо стоечных серверов использовали Cisco UCS; и 3) вместо того, чтобы пихать пачки дисков в стоечные сервера, использовали EMC Isilon – если бы вы сделали эти три вещи, решение было бы в два раза быстрее, в два раза компактнее и в два раза дешевле в терминах совокупной стоимости владения» — ну… если бы вам кто-нибудь это сказал, вы бы решили, что он вдребезги пьян.
Но оказывается, что приведенное утверждение – правда.
Конечно, не для всех. Однако оно правдиво для интересного случая, разобранного по ссылке. Это случай реального клиента, Hadoop кластер которого разросся до 5 петабайт. Результаты по ссылке – это результаты их собственного тестирования (спасибо Дэну Береслу и Крису Бёрдвелу за то, что поделились). Клиент, о котором идет речь, — это огромная телекоммуникационная компания. Вам доступны подробные результаты тестирования, включая тестирование производительности.
А теперь интересное наблюдение: многим тяжело думать об Isilon как об HDFS-хранилище (HDFS – распределенная файловая система в составе Hadoop – прим. перев.), потому что он «выглядит» как аппаратный комплекс, а не как стандартные сервера общего назначения, несущие на себе нужный софт.
Часто клиенты, начиная работу с Hadoop, думают «Мне нужна стандартная аппаратная платформа».
Однако НЕ стоит судить книжку по обложке. «Роза пахнет розой, хоть розой назови её, хоть нет».
Взгляните на эти картинки:
Когда вы на них смотрите, вы, наверное, думаете: «Стандартные промышленные сервера».
… А теперь позвольте мне показать их лицевую сторону:
Когда вы на них смотрите, то, вероятно, думаете: «Аппаратный комплекс».
Но в обоих случаях вы смотрите на одно и то же.
Программное обеспечение под названием OneFS – это то, что дает Исилону его мощь. Подача Исилона в виде программно-аппаратного комплекса – следствие желания клиентов покупать (и поддерживать) его именно таким способом.
В разобранном по ссылке случае с HDFS, виртуализированная конфигурация на базе UCS и Исилон стала такой быстрой (в 2 раза быстрее!), компактной (в 2 раза компактнее!) и экономичной (в 2 раза экономичнее!) за счет программных функций Исилона:
- Обеспечение высокой доступности данных как в пределах одной стойки, так и в пределах массива стоек, причем без трехкратного дублирования данных. Это СОФТ
- Отказ от стэйджинга, потому что одни и те же данные доступны как по NFS, так и через HDFS. Это тоже СОФТ
- Богатые возможности для создания снэпшотов и реплик HDFS-объектов. И это тоже СОФТ
… в случае телеком-клиента не было никакой магии со стороны железа (хотя был некоторый выигрыш от использования UCS. Он произошел за счет более плотной упаковки вычислительных мощностей. Отказ от локальных дисков позволил нам заменить рэковые сервера на блейды).
Во всей этой истории есть веселый момент. Скажи мы клиентам: «Вот вам программная реализация HDFS со всеми перечисленными выше свойствами, ставьте ее на свое железо» – клиенты более охотно начали бы использовать ONEFS. Им бы не пришлось столкнуться со сложностями, которые несут в себе локальные диски. Масштабирование HDFS стало бы для них менее болезненным.
Так почему же мы не делаем этого? Ответ приведен на диаграмме ниже:
Я постоянно веду этот странный диалог с клиентами. Они начинают с того, что «Я не хочу аппаратный комплекс» (ага, тогда «Вот вам ScaleIO/VSAN и Исилон в виде софта»), и затем приходят к тому, что просят аппаратный комплекс :-) Это настолько же предсказуемо, как то, что солнце взойдет на востоке. Из-за подобных диалогов, Solidfire недавно объявил о выпуске софтовой версии их продукта (готов поспорить, что продажи будут низкими, по сравнению с продажами их комплекса), а Nutanix даже начинал с чисто программных решений (а закончил комплексными). По этим же причинам, для успешного старта VSAN понадобились специальные «Узлы под VSAN» (VSAN Ready Nodes – прим. пер.) И я подозреваю, что уже скоро очень существенное потребление VSAN будет идти через комплексные решения вроде VSPEX Blue. Конечно же, такой вариант использования будет более популярным, чем вариант «установи VSAN на свое железо». То же самое справедливо и для ScaleIO.
Почему?
Ответ следующий:
- Многие не понимают, что экономика программно-аппартных решений определяется пользой для клиента и его бизнес-моделями, а вовсе не стоимостью железок. Люди приходят к этому, когда начинают строить законченные решения своими руками. Попробуйте самостоятельно построить кластер Nexenta с высокой доступностью и отказоустойчивостью. Цена будет той же, что и цена на VNX в конфигурации NetApp FAS. Попробуйте развернуть Gluster с Enterprise-поддержкой Redhat. Заплатите столько же, сколько за Исилон. Попробуйте построить кластер Ceph (опять же с enterprise-поддержкой). Получите цену ECS. Вывод: железо здесь ни при чем (по крайне мере, не в случае архитектур «третьего» и «четвертого» типов) (См. выше ссылку на классификацию архитектур от Чада Сакаша – прим. пер.)
- Даже крупнейшие компании обычно не имеют внутренней функции «голое железо в виде сервиса». Они держат команду, которая отвечает за разработку стандартов коробочного оборудования и вариантов его поддержки, а также за создание абстрактной модели железа, следуя которой можно разворачивать всевозможное ПО. У Google, Amazon, и Facebook функция «голое железо в виде сервиса» есть, у большинства остальных – нет. Вывод: модели поддержки тяготеют к моделям комплексных и конвергентных решений.
Однако не поймите меня неправильно. Идея ПО, непривязанного к железу, все же важна.
Такой софт можно использовать множеством различных способов. Если ПО существует отдельно от железа, то его можно заполучить без «лишних довесков» для того, чтобы изучить, попробовать, поиграться, использовать в работе – но без поддержки. За поддержку в любом случае придется кому-то платить (независимо от того, идет ли речь об открытом или закрытом коде).
По всем этим причинам и многим другим, все ПО EMC станет постепенно доступным «без довесков», и в некоторых случаях, возможно даже, с открытым кодом.
Кстати, все сказанное не означает, что в мире железа не осталось места инновациям. Перед вами новейший узел Isilon HD, с декоративными панелями и без них:
Легко понять, почему он носит кодовое имя «Колосс». Диски установлены вертикально, так же, как и кожухи для их плотной упаковки: Viking @ 120 x 2.5” SSD/HDD и Voyager @ 60 x 3.5” HDD. Каждый узел Исилона нуждается еще и в вычислительных мощностях. Они размещены в этом же корпусе размера 4U. В итоге, имеем до 376ТБ в одном корпусе, что очень плотненько и очень клево. Этот узел разработан для гипер-емких конфигураций и для архивного использования.
Только взгляните на все это! Программно-определяемые хранилища восхитительны. И то, что их можно развернуть множеством различных способов вплоть до собственного железа — просто замечательно. Вместе с тем, я думаю, что в обозримом будущем наиболее предпочтительными моделями использования программно-определяемых хранилищ останутся комплексные решения и конвергентная/гиперконвергентная инфраструктура.
Ваши мысли?
(Об Исилон и HDFS читайте также в нашем блоге: Рецепт «Быстрых данных» на основе решения для больших данных — прим. пер.)