Вы под этим замечанием FCoE имели в виду? К сожалению мимо не прошла, но я бы не стал смешивать. Транспорт все-таки ethernet со своими тараканами и, безусловно, более активно используемыми медными портами, в т.ч. и xxbase-t.
Я имел в виду, что расстояние определяет прежде всего не тип волокна, а возможность использовать медь. 100G медный линк и пара оптических трансиверов на 100G это две большие разницы :) Поэтому там, где можно жить с медью (позволяет расстояние между коммутируемыми устройствами, есть возможность разместить кабели и т.п.), проще (читаем «дешевле») ее и использовать.
Зависит от того, что соединять и на каких расстояниях(это, пожалуй, самое важное). Fibre Channel давно склонился в сторону оптики, а вот IB или NVMe, наоборот, — к медным кабелям.
Интегрированные. Встроены в материнскую плату. Отдельный чип выполняет часть задач по управлению, но всё же тоже задействует центральный процессор.
И как же у нас P410i «тоже задействует центральный процессор»? А PERC H700?
Ну и как-то в табличке путано все. Вот вдруг тот же P410i потерял BBWC, RAID 6, 256МБ кэша, а заодно еще и просел в интерфейсах.
Если «лень было искать», то вот вам уважаемые читатели множество неточностей?
Для получения тех результатов, которые опубликованы? :) Уж конечно!
И вообще, у нас отличие по стоимости IBM и DataCore в 20 раз!
Точно! Все правильно пишете — вот поэтому ниже и написано, что считать нужно правильно, а не только "гросс" суммы и гросс иопсы. Только объем системы у IBM в 10 раз больше, контроллеров два (а на самом деле есть еще много других "но" и "если"). И эти "но" и "если" далеко не так однозначны (в пользу разных решений) и зависят от конкретной задачи.
Цель не продать дорого, а подобрать решение, которое будет выполнять поставленные задачи. Но если из всех достижений проекта будут только красивые результаты синтетических тестов (а они могут получиться и там, и там), то можно считать проект провальным.
протестированные конфигурации опубликованы на сайте DataCore
Ой ли! А читали сами спеки и результаты вдумчиво? Линейно растет производительность при добавлении узлов — отлично (наверное репликация за счет святого духа работает). Памяти вот прямо 100% в compute доступно (про кэш случайно наверное забыли написать). Marketing bullshit нужно очень аккуратно читать и верить далеко не всему.
SDS часто оправдан. Часто очень финансово привлекателен (особенно на первый взгляд). Но далеко не всегда. И выбирать систему, руководствуясь только оптимистичным рекламным листком конечно можно, но часто это заканчивается не очень хорошо. И обычно для всех участников проекта.
Ну да, сервер работать перестанет, а DataCore в вакууме продолжит работать! Конечно!
Еще раз (по полочкам):
1. Сходите и выдерните CPU0 из любого своего сервера (желательно «на ходу») — посмотрим на результат. После этого обсудим что и как будет работать.
2. Да, можно поставить процессоры с большей частотой. Можно взять 32 узла, можно памяти добавить. Можно что угодно сделать. Но протестирована конфигурация с одним сервером. Одним, Карл! Следовательно отказоустойчивости нет. Точка. Нет отказоустойчивости. Ее можно получить, но это будет другая конфигурация с другой ценой. И у этой конфигурации будут другие результаты по производительности.
Если нужно масштабировать FlashSystem, есть другое решение — FlashSystem V9000. И, да, проблемы могут быть на любом оборудовании. Но это не повод отказываться от базовых принципов отказоустойчивости. Нет смысла переходить дорогу на красный свет, мотивируя это тем, что и без того многих сбивают, когда они на зеленый переходят.
Это скорее не я, а beststoragename про реальные процессоры :)
А процессор конечно ему нужен — весь функционал-то в софте. Такие штуки как тиринг, дедупликация, компрессия и т.п. даром не даются — приходится часть тактов занять полезной работой :)
Какая чушь, прости господи! Ну попробуйте выдернуть из любого современного сервера процессор CPU0 и я посмотрю, как у вас он продолжит работать «в том же режиме». А даже если CPU1 кончится, то потеряете гораздо больше, чем половину процессорной мощности (если вообще взлетит после ребута).
«Дублированные процессоры» — они не дублированные, их просто 2 :) И, если сдохнет один, то от второго толку будет не слишком много. И это совсем не то, что второй контроллер. А вот, если захотим «второй контроллер» для DataCore, то это будет второй сервер, второй набор дисков и второй набор лицензий — система станет ровно в 2 раза дороже.
Нет, на EF нет ни дедупликации, ни компрессии. Эти системы ориентированы на тех, кому производительность важнее всего и их не перегружают «лишним» функционалом. Хотя, конечно можно сказать проще :) — их архитектура не подразумевает возможности легко добавить такие штуки.
Обещан CPU оверхед меньше 1%. А далее все зависит. На производительности (за счет разгрузки бэкенда) должно сказываться положительно. Как скажется на задержках, нужно мерить на конкретных задачах (тестов вендора я еще не встречал). Судя по тому, как реализован механизм, каких-то «проседаний» в латентности ждать не надо.
На E-серию — сильно сомневаюсь, там совсем другая архитектура.
Выходит, без постпроцессинга эффективность будет очень низкая (если не гнать один паттерн потоком)?
Никто не обещает чудесного решения на все случаи. Безусловно, эффективность зависит от профиля нагрузки на конкретный том. Если дедупликация эффективна только в долгосрочной перспективе, то лучше поспроцессинг. Инлайн, кроме того, позволяет разгрузить бэкенд, а это может стать большим плюсом.
И как же у нас P410i «тоже задействует центральный процессор»? А PERC H700?
Ну и как-то в табличке путано все. Вот вдруг тот же P410i потерял BBWC, RAID 6, 256МБ кэша, а заодно еще и просел в интерфейсах.
Если «лень было искать», то вот вам уважаемые читатели множество неточностей?
Для получения тех результатов, которые опубликованы? :) Уж конечно!
Точно! Все правильно пишете — вот поэтому ниже и написано, что считать нужно правильно, а не только "гросс" суммы и гросс иопсы. Только объем системы у IBM в 10 раз больше, контроллеров два (а на самом деле есть еще много других "но" и "если"). И эти "но" и "если" далеко не так однозначны (в пользу разных решений) и зависят от конкретной задачи.
Цель не продать дорого, а подобрать решение, которое будет выполнять поставленные задачи. Но если из всех достижений проекта будут только красивые результаты синтетических тестов (а они могут получиться и там, и там), то можно считать проект провальным.
Ой ли! А читали сами спеки и результаты вдумчиво? Линейно растет производительность при добавлении узлов — отлично (наверное репликация за счет святого духа работает). Памяти вот прямо 100% в compute доступно (про кэш случайно наверное забыли написать). Marketing bullshit нужно очень аккуратно читать и верить далеко не всему.
SDS часто оправдан. Часто очень финансово привлекателен (особенно на первый взгляд). Но далеко не всегда. И выбирать систему, руководствуясь только оптимистичным рекламным листком конечно можно, но часто это заканчивается не очень хорошо. И обычно для всех участников проекта.
Еще раз (по полочкам):
1. Сходите и выдерните CPU0 из любого своего сервера (желательно «на ходу») — посмотрим на результат. После этого обсудим что и как будет работать.
2. Да, можно поставить процессоры с большей частотой. Можно взять 32 узла, можно памяти добавить. Можно что угодно сделать. Но протестирована конфигурация с одним сервером. Одним, Карл! Следовательно отказоустойчивости нет. Точка. Нет отказоустойчивости. Ее можно получить, но это будет другая конфигурация с другой ценой. И у этой конфигурации будут другие результаты по производительности.
Если нужно масштабировать FlashSystem, есть другое решение — FlashSystem V9000. И, да, проблемы могут быть на любом оборудовании. Но это не повод отказываться от базовых принципов отказоустойчивости. Нет смысла переходить дорогу на красный свет, мотивируя это тем, что и без того многих сбивают, когда они на зеленый переходят.
А процессор конечно ему нужен — весь функционал-то в софте. Такие штуки как тиринг, дедупликация, компрессия и т.п. даром не даются — приходится часть тактов занять полезной работой :)
Так именно про это и написано же!
это если четвертый, то на треть :)
Но у нас тут только один, поэтому мы добавляем второй, а значит будет в два раза дороже.
А после обновления FRU, вот прямо сразу производительность стала оптимальнее? :)
А вообще, уважающий себя сборщик (читай поставщик) сам должен был все это сделать еще до отгрузки оборудования заказчику.
Никто не обещает чудесного решения на все случаи. Безусловно, эффективность зависит от профиля нагрузки на конкретный том. Если дедупликация эффективна только в долгосрочной перспективе, то лучше поспроцессинг. Инлайн, кроме того, позволяет разгрузить бэкенд, а это может стать большим плюсом.