Вы под этим замечанием 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%. А далее все зависит. На производительности (за счет разгрузки бэкенда) должно сказываться положительно. Как скажется на задержках, нужно мерить на конкретных задачах (тестов вендора я еще не встречал). Судя по тому, как реализован механизм, каких-то «проседаний» в латентности ждать не надо.
А почему не взять Zeep (как вариант), чтобы xml руками не собирать? https://docs.python-zeep.org/en/master/
И как же у нас P410i «тоже задействует центральный процессор»? А PERC H700?
Ну и как-то в табличке путано все. Вот вдруг тот же P410i потерял BBWC, RAID 6, 256МБ кэша, а заодно еще и просел в интерфейсах.
Если «лень было искать», то вот вам уважаемые читатели множество неточностей?
Для получения тех результатов, которые опубликованы? :) Уж конечно!
Точно! Все правильно пишете — вот поэтому ниже и написано, что считать нужно правильно, а не только "гросс" суммы и гросс иопсы. Только объем системы у IBM в 10 раз больше, контроллеров два (а на самом деле есть еще много других "но" и "если"). И эти "но" и "если" далеко не так однозначны (в пользу разных решений) и зависят от конкретной задачи.
Цель не продать дорого, а подобрать решение, которое будет выполнять поставленные задачи. Но если из всех достижений проекта будут только красивые результаты синтетических тестов (а они могут получиться и там, и там), то можно считать проект провальным.
Ой ли! А читали сами спеки и результаты вдумчиво? Линейно растет производительность при добавлении узлов — отлично (наверное репликация за счет святого духа работает). Памяти вот прямо 100% в compute доступно (про кэш случайно наверное забыли написать). Marketing bullshit нужно очень аккуратно читать и верить далеко не всему.
SDS часто оправдан. Часто очень финансово привлекателен (особенно на первый взгляд). Но далеко не всегда. И выбирать систему, руководствуясь только оптимистичным рекламным листком конечно можно, но часто это заканчивается не очень хорошо. И обычно для всех участников проекта.
Еще раз (по полочкам):
1. Сходите и выдерните CPU0 из любого своего сервера (желательно «на ходу») — посмотрим на результат. После этого обсудим что и как будет работать.
2. Да, можно поставить процессоры с большей частотой. Можно взять 32 узла, можно памяти добавить. Можно что угодно сделать. Но протестирована конфигурация с одним сервером. Одним, Карл! Следовательно отказоустойчивости нет. Точка. Нет отказоустойчивости. Ее можно получить, но это будет другая конфигурация с другой ценой. И у этой конфигурации будут другие результаты по производительности.
Если нужно масштабировать FlashSystem, есть другое решение — FlashSystem V9000. И, да, проблемы могут быть на любом оборудовании. Но это не повод отказываться от базовых принципов отказоустойчивости. Нет смысла переходить дорогу на красный свет, мотивируя это тем, что и без того многих сбивают, когда они на зеленый переходят.
А процессор конечно ему нужен — весь функционал-то в софте. Такие штуки как тиринг, дедупликация, компрессия и т.п. даром не даются — приходится часть тактов занять полезной работой :)
Так именно про это и написано же!
это если четвертый, то на треть :)
Но у нас тут только один, поэтому мы добавляем второй, а значит будет в два раза дороже.
А после обновления FRU, вот прямо сразу производительность стала оптимальнее? :)
А вообще, уважающий себя сборщик (читай поставщик) сам должен был все это сделать еще до отгрузки оборудования заказчику.