Storage: две непримиримые школы

[zVlad]

Дима, Вы говорим о разных вещах и сравниваете их. Вы все время сползаете к теме локальных устройств. Это значит что такие устройства не могут использоваться больше чем одним сервером. Таким образом Вы уходите в мир shared-nothing со всеми вытекающими последствиями.

ну да, мир гуглов и биг даты, полная противоположность централизованному МФ. про последствия я один не понял ?

Мир состоит не из гуглов, а биг даты это в большенстве случаев погоня за модными словечками и дополнительным финансированием, за job security.

[iDesperado]

Мир состоит не из гуглов, а биг даты это в большенстве случаев погоня за модными словечками и дополнительным финансированием, за job security.

вы слышали звон, но не поняли где он. как раз биг дата это попытка заменить дорогие сервера заметно менее эффективными, но чудовищно примитивными и дешевыми технологиями.

[Мальчик-Одуванчик]

Мир состоит не из гуглов, а биг даты это в большенстве случаев погоня за модными словечками и дополнительным финансированием, за job security.

вы слышали звон, но не поняли где он. как раз биг дата это попытка заменить дорогие сервера заметно менее эффективными, но чудовищно примитивными и дешевыми технологиями.

Или как сравнить добычу полезных ископаемых по традиционной технологии с добычей из отходов традиционной технологии.

[zVlad]

Мир состоит не из гуглов, а биг даты это в большенстве случаев погоня за модными словечками и дополнительным финансированием, за job security.

вы слышали звон, но не поняли где он. как раз биг дата это попытка заменить дорогие сервера заметно менее эффективными, но чудовищно примитивными и дешевыми технологиями.

Вы сами запутались в двух соснах. Вы даже Вашу неприязнь к нормальным серверам способным эффективно и экономично обрабатывать какие угодно объемы данных с действительными проблемами "примитивных и дешевых технологий" путаете и сталкиваете их где только я Вам повод подаю.
Тем не менее я повторю проблема больших данных во многом надуманная и решаема в пределах традиционных подходов. Во многих случаях результат обработки больших данных ничтожен или вообще неадекватен. Что можно вытянуть из обработки бредятины в Twitter-е?
Ну а тех случаев когда можно вести речь о big data настолько мало что её постоянное муссирование на этом форуме само собой доказывает что это дань моде, способ выделиться, показать себя.

[Mark]

О а можно я тоже модное слово вставлю - cloud. Так вот что же делать cloud провайдерам со сториджем? Что лучше локальный das (это то что Автор топика так пропагандирует) или SAN/NAS?

[flip_flop]

1
Дима, Вы говорим о разных вещах и сравниваете их. Вы все время сползаете к теме локальных устройств. Это значит что такие устройства не могут использоваться больше чем одним сервером. Таким образом Вы уходите в мир shared-nothing со всеми вытекающими последствиями.

2
8 Gbps - это трансфер рате лишь одного канала, которых, как Вы сказали выше, может быть сотни. Следовательно, 32 GBps будет достигнуто на 40-ка каналах и при этом диски могут быть доступны многим серверам одновременно. Более того одни и те же файловые системы могут доступны без каких-либо NFS-ов, или SMB. Это я про МФ как Вы поняли.

1 Совершенно верно, это тема данного топика, если вы не заметили
2 Снова верно, но - сравним стоимость решений! И если shared nothing дает такой выигрыш по производительности при цене в десятки раз ниже то это может спровоцировать "think out of the box" и перейти на новые нетривиальные решения

Неа. Неверно. Наиболее передовая технология NVMe (PCIe SSD +register control, optimized for NVM) позволяет делать "много гитик" ( https://intel.activeevents.com/sz14/con ... 0_ENGf.pdf или http://www.nvmexpress.org/wp-content/up ... 141209.pdf )

1. Локальные устройства (внутри ящика) могут использоваться разными хостами, как на одной плате (узле), так и на разных узлах.

2. NVMe диски могут быть доступны многим серверам одновременно. Есть ещё такая вещь как NVMe over Fabrick, когда имеется доступ к удалённым серверам. Но не знаю, можно ли их называть локальными в этом случае. По поводу производительности - кроме transfer rate есть ещё и latency. В случае NVMe, SSD диск подключён к чипу процессора напрямую, поскольку на процессоре интегрирован контроллер NVMe и latency минимизирована. Например, сервер SGI UV300 (оптимизирован для данных/ИО с относительно малым числом CPU, но с увеличенным ИО, 24 memory dimms per socket, 2 NVMe SSD per socket) позволяет внутри одного монолитного узла с одним экземпляром ОС получать более 30 миллионов IOPS (4k data block) и 200 ГБ/сек (двести ГигаБайт в секунду) transfer rate последовательного чтения.

Ещё есть куча разных файловых систем с эффективным использованием NVMe (+ разные приблуды со стороны HW/SW), в том числе и от ИБМ, в том числе и для МФ, но я здесь пас

[Dmitry67]

Возникает куча вопросов
1. А насколько медленнее такой диск работает не на своем NUMA?
2. А насколько медленнее такой диск работает не на своем узле?
3. Можно ли использовать на VMware не на своем storage?
4. Или лучше иметь local disk и использовать Storage+Host vMotion? А как же HA?
5. Какие 200GB/s? Столько память не потянет

[flip_flop]

Возникает куча вопросов
1. А насколько медленнее такой диск работает не на своем NUMA?
2. А насколько медленнее такой диск работает не на своем узле?
3. Можно ли использовать на VMware не на своем storage?
4. Или лучше иметь local disk и использовать Storage+Host vMotion?

Не знаю. Я использую только как локальный диск без всяких примочек. Это я привёл к тому, что такие возможности есть. Но в целом, по моему, технология весьма новая и не все торопятся её внедрять. Пока что.

5. Какие 200GB/s? Столько память не потянет

Хе-хе. 32 сокета XEON E7 8890 v2. 4 канала памяти на один CPU, каждый канал имеет буфер мультиплексор на два блока диммов (по 3 димма на блок максимум). В результате на один CPU имеем максимальный BW 85 GB/s. В случае 3-х диммов на один блок максимальный BW слегка просядет по сравнению с одним диммом на блок, но немного. возьмём для простоты 70 ГБ/с. Умножьте на 32 и возрадуйтесь. Сервер как раз предназначен для всяких там in memory database, analitics, etc. 24 TB shared coherent memory.

[zVlad]

....

5. Какие 200GB/s? Столько память не потянет

Хе-хе. 32 сокета XEON E7 8890 v2. 4 канала памяти на один CPU, каждый канал имеет буфер мультиплексор на два блока диммов (по 3 димма на блок максимум). В результате на один CPU имеем максимальный BW 85 GB/s. В случае 3-х диммов на один блок максимальный BW слегка просядет по сравнению с одним диммом на блок, но немного. возьмём для простоты 70 ГБ/с. Умножьте на 32 и возрадуйтесь. Сервер как раз предназначен для всяких там in memory database, analitics, etc. 24 TB shared coherent memory.

Этот сервер слизнет 24ТБ за 10 секунд и что дальше? Какие реальные приложения могут нуждаться в таких параметрах?
Кто нибудь, кроме постановки тестов, использует такие сервера?

[Dmitry67]

Любая аналитика/OLAP ребилд куба по любой VLDB, не говоря уже о big data. Хранилище кликов, например, по ним любят аналитики строить

[Dmitry67]

С другой стороны Влад прав в том, что любой мало мальски сложный алгоритм не может потреблять данные со скоростью работы памяти, он как минимум несколько раз мусолит каждое слово...

[zVlad]

С другой стороны Влад прав в том, что любой мало мальски сложный алгоритм не может потреблять данные со скоростью работы памяти, он как минимум несколько раз мусолит каждое слово...

Да, именно так. Кроме того есть не мало данных которые используются многократно и их не надо каждый раз считывать из внешней памяти.
Главный показатель адекватности мощи железа задачe это его загруженность и выполнение требований SLA. Если железо не загружено и при этом SLA не выполняется то сколько бы железо не стоило это деньги на ветер. Деньги на ветер и если SLA выполняется, но железо не загружено полностью.

[zVlad]

Любая аналитика/OLAP ребилд куба по любой VLDB, не говоря уже о big data. Хранилище кликов, например, по ним любят аналитики строить

Такие задачи не требуют мгновенного ответа. Может и несколько дней быть приемлемо порой. Например запускаем аналитику в пятницу вечером и получаем ответ утром в понедельник и это та скорость которая удовлетворяет потребность.

[flip_flop]

Что-то я вас, господа-товарищи, не пойму. "МФ лучше х86 серверов потому что монолит и ИО сильнее", а когда сделали монолит х86 с сильным ИО - "да кому он нужен". Нужен, поэтому и сделали. Во-первых, это суперкомпьютер, но с фокусом на ИО вместо фокуса на CPU. HPC имеет очень большой спектр - от compute bounded до memory bounded applications. Dmitry67, погуглите "memory bounded application", "memory wall".

Ну ладно, не буду больше "о драконах", перейдём к "дебит-кредит". Да хотя-бы виртуализация, мне казалось она нуждается в "быстром слизывании". Одним из главным реальных приложений является SAP HANA. Ну и консолидация приложений с использованием общей памяти.

Я не копенгаген в этих ваших базах данных, но SAP вроде реальное приложение, enterprise уровня, нет?

"The ability to combine database, data processing, and application platform capabilities in-memory with the SAP® HANA®platform is truly game-changing. Imagine if your operations, financial, research, or marketing teams could operate in real time. Now imagine leveraging SAP HANA in your enterprise at extreme scale and lower total cost of ownership (TCO). SGI is making this possible."

[flip_flop]

Любая аналитика/OLAP ребилд куба по любой VLDB, не говоря уже о big data. Хранилище кликов, например, по ним любят аналитики строить

Такие задачи не требуют мгновенного ответа. Может и несколько дней быть приемлемо порой. Например запускаем аналитику в пятницу вечером и получаем ответ утром в понедельник и это та скорость которая удовлетворяет потребность.

Чиво? Эдак маленькие сиськи и маленькие пенисы лучше "удовлетворяет потребность"?

P.S. В общем, вместо "быстрее, выше, сильнее" надо делать "загруженнее"? Интересненько...

P.P.S. "Может ... порой". "Если кто-то, кое-где, у нас, порой"

[Dmitry67]

Любая аналитика/OLAP ребилд куба по любой VLDB, не говоря уже о big data. Хранилище кликов, например, по ним любят аналитики строить

Такие задачи не требуют мгновенного ответа. Может и несколько дней быть приемлемо порой. Например запускаем аналитику в пятницу вечером и получаем ответ утром в понедельник и это та скорость которая удовлетворяет потребность.

Куб как правило не доступен вр время full refresh. Ваш пример с пятницей и понедельником черезчур оптимистичен. Помню более 10 лет в osram sylvania было окно с 12 ночи до 6 утра. И оно уменьшалось а объем данных рос

[zVlad]

.....Я не копенгаген в этих ваших базах данных, но SAP вроде реальное приложение, enterprise уровня, нет?

"The ability to combine database, data processing, and application platform capabilities in-memory with the SAP® HANA®platform is truly game-changing. Imagine if your operations, financial, research, or marketing teams could operate in real time. Now imagine leveraging SAP HANA in your enterprise at extreme scale and lower total cost of ownership (TCO). SGI is making this possible."

У нас как раз сейчас идет имплементация двухлетнего проекта переноса ~3000 пользователей из SAP на Юниксе с Ораклом на МФ с DB2 и CICS. Причем несмотря на то что МФ в пиковые часы 100% busy умощнение его не заложено в проект, только на крайний случай может быть добавят MIPS-в. А это маленький МФ с всего 5 CPU.

[zVlad]

Любая аналитика/OLAP ребилд куба по любой VLDB, не говоря уже о big data. Хранилище кликов, например, по ним любят аналитики строить

Такие задачи не требуют мгновенного ответа. Может и несколько дней быть приемлемо порой. Например запускаем аналитику в пятницу вечером и получаем ответ утром в понедельник и это та скорость которая удовлетворяет потребность.

Чиво? Эдак маленькие сиськи и маленькие пенисы лучше "удовлетворяет потребность"?

P.S. В общем, вместо "быстрее, выше, сильнее" надо делать "загруженнее"? Интересненько...

Нет. Для каждой потребности есть своя конфигурация мощности. Держать больше мощности чем необходимо это дилетантский подход.

[zVlad]

Любая аналитика/OLAP ребилд куба по любой VLDB, не говоря уже о big data. Хранилище кликов, например, по ним любят аналитики строить

Такие задачи не требуют мгновенного ответа. Может и несколько дней быть приемлемо порой. Например запускаем аналитику в пятницу вечером и получаем ответ утром в понедельник и это та скорость которая удовлетворяет потребность.

Куб как правило не доступен вр время full refresh. Ваш пример с пятницей и понедельником черезчур оптимистичен. Помню более 10 лет в osram sylvania было окно с 12 ночи до 6 утра. И оно уменьшалось а объем данных рос

У нас в выходные нагрузка разко сокращается и в принципе всю нашу БД можно на месте перелопатить много раз кaк угодно без кубов и full refresh. Хотя для "аналотики" у нас есть некольколько реплик с операционной БД. На MS SQL серверах и одна в Oracle.
Зачем это делается мне лично не понятно - привычка такая и работа для нескольких человек.

[flip_flop]

У нас как раз сейчас идет имплементация двухлетнего проекта переноса ~3000 пользователей из SAP на Юниксе с Ораклом на МФ с DB2 и CICS. Причем несмотря на то что МФ в пиковые часы 100% busy умощнение его не заложено в проект, только на крайний случай может быть добавят MIPS-в. А это маленький МФ с всего 5 CPU.

Ну, значит у Вас маленький SAP, МФ хватит Ну и я не столько о базисном SAP, сколько о SAP HANA

[flip_flop]

Нет. Для каждой потребности есть своя конфигурация мощности. Держать больше мощности чем необходимо это дилетантский подход.

"Каждому - по потребности" [ В.И. Ленин]

[zVlad]

У нас как раз сейчас идет имплементация двухлетнего проекта переноса ~3000 пользователей из SAP на Юниксе с Ораклом на МФ с DB2 и CICS. Причем несмотря на то что МФ в пиковые часы 100% busy умощнение его не заложено в проект, только на крайний случай может быть добавят MIPS-в. А это маленький МФ с всего 5 CPU.

Ну, значит у Вас маленький SAP, МФ хватит Ну и я не столько о базисном SAP, сколько о SAP HANA

Маленький или не маленький, но 3000 новых пользователей - все неатомные електростанции добавляются к приложению для атомных станций. До этого SAP крутился на некоторой инфраструктуре, а теперь ее не надо будет. И проект этот во много раз дороже расходов на наш МФ.

[zVlad]

Нет. Для каждой потребности есть своя конфигурация мощности. Держать больше мощности чем необходимо это дилетантский подход.

"Каждому - по потребности" [ В.И. Ленин]

Нет, это до Ленина было сказано.

[flip_flop]

"Каждому - по потребности" [ В.И. Ленин]

Нет, это до Ленина было сказано.

Конечно. "Критика готской программы". Я скорее имел в виду имплементацию. С сарказмом Впрочем, это ну уж совсем злостный оффтопик.

[flip_flop]

У нас как раз сейчас идет имплементация двухлетнего проекта переноса ~3000 пользователей из SAP на Юниксе с Ораклом на МФ с DB2 и CICS. Причем несмотря на то что МФ в пиковые часы 100% busy умощнение его не заложено в проект, только на крайний случай может быть добавят MIPS-в. А это маленький МФ с всего 5 CPU.

Ну, значит у Вас маленький SAP, МФ хватит Ну и я не столько о базисном SAP, сколько о SAP HANA

Маленький или не маленький, но 3000 новых пользователей - все неатомные електростанции добавляются к приложению для атомных станций. До этого SAP крутился на некоторой инфраструктуре, а теперь ее не надо будет. И проект этот во много раз дороже расходов на наш МФ.

А SAP HANA там был?