Мы строили системы и на JS200, и на JS300 — всё было в порядке, виделся один набор multipath дисков на обеих нодах, количество enclosure по детекту совпадало с физическим количеством (пробовали параллельное подключение и каскады).
На микре могла быть какая-то проблема с прошивкой экспандеров, они всегда были криворуки по этой части.
Что считает MVP — сказать сложно, он не раскрывает тему. Не нравятся ему в принципе взаимодействие с компанией или конкретные нюансы работы/особенности архитектуры, тайна сия велика есть. Могу только повториться — мы пробовали все варианты работы полок, негативного опыта не было.
По производительности нужно 45 штук, по ёмкости (считаю 1.2TB) 70.
По цене обойдутся плюс-минус одинаково, но на 2 полках не работает enclosure awareness (нужно минимум 3).
Альтернатива жизнеспособная, кому что понравится.
Да, при реальном заказе есть смысл позвонить/написать и поговорить.
И мы готовы отвечать. Более того, можно пообщаться с нашим техотделом и попросить удаленный доступ на север в тестовой лаборатории.
Про круглосуточную поддержку — есть, но это действительно стоит обговаривать, потому что в любом случае на такой запрос будет заключаться отдельный договор обслуживания, с прописыванием SLA.
Вопросы — это хорошо.
1. Да, за узел (в самом верху есть примечание, что «Поставляются в составе шасси. Минимальное количество для заказа 4 штуки»).
2. А с чего ему себя ненормально чувствовать? С его точки зрения это 4 совершенно стандартных сервера, ничем не отличающихся от обычных 1U серверов.
3. Нет, просто это выходит за пределы стандартных гарантийных планов и обговаривается отдельно.
Попробовать можно, но пока это не верифицируется на уровне SAS — это автоматически вычеркивает нас из культурного разговора с вендором, потому что «не пихайте, чего нет в HCL), а глючных SAS у нас на руках нет.
Да и жалоб на зависание бэкплейна оптом не было, так что вероятность возникновения проблемы явно небольшая (да, мы понимаем, что когда оно случится в продакшене — никому с размера вероятности легче не станет). При случае посмотрим, но пока наше мнение не изменилось: надо смотреть протокол, чтобы понимать, как именно устройство умудряется поставить в неприличную позу весь бэкплейн.
Кстати, хороший вопрос к Вам и Вашим коллегам: а у вас среди зависших были варианты с парой экспандеров на бекплейн, то есть работающим MPIO?
Смотрите, общее хранилище кластера в коробке — это два SAS-экспандера с общей дисковой полкой. С одной стороны к этим экспандерам подключаются жесткие диски (поскольку это SAS, то каждый диск можно подключить одновременно к двум экспандерам), а с другой к ним подключаются контроллеры Syncro. Соответственно, линия синхронизации (точнее две линии) это Syncro1 — SAS экспандер — Syncro 2.
Вы не учитываете, чем матрица связана с управляющей частью.
PCIe Gen2 x4, в лучшем случае и это именно интерфейс для программирования матрицы. При большом желании можно, наверное, обработку трафика тоже через него гонять, но это нетривиальная задача.
Потому что этого атома с избытком хватает на потребности ОС в том случае, если сетевой трафик не надо гонять на процессор и обратно и он бегает в пределах портов и ASIC'а.
А парочка даже не самых топовых зеонов с четвертью терабайта памяти уже удваивает цену коммутатора (а это 48 х 10G). Пока не видно сколько-нибудь значимого количества клиентов, желающих оплачивать создание такого удовольствия. А главное, не очень понятно зачем оно такое: какие вы видите задачи, чтобы их в принципе было выгодно решать на дорогостоящей (по энергопотреблению и стоимости обработки трафика) универсальной архитектуре и нельзя было реализовать на NPU?
Не нужно это, делать отдельный подвид ящиков сейчас нет смысла. Слишком специфична коммутационная часть.
>> Очевидно, что если компьютер поставить на базе архитектуры AMD64 (проц amd или intel), то он будет дешевле и быстрее, чем любые специализированные процессоры, просто из-за массовости производства.
Посмотрите на современный коммутатор — там уже стоят массовые PPC или Intel Atom, ось кидается на SSD, а за управление матрицей отвечает драйвер :)
На тот же Cumulus Linux можно ставить любой сторонний софт.
Мы строили системы и на JS200, и на JS300 — всё было в порядке, виделся один набор multipath дисков на обеих нодах, количество enclosure по детекту совпадало с физическим количеством (пробовали параллельное подключение и каскады).
На микре могла быть какая-то проблема с прошивкой экспандеров, они всегда были криворуки по этой части.
Что считает MVP — сказать сложно, он не раскрывает тему. Не нравятся ему в принципе взаимодействие с компанией или конкретные нюансы работы/особенности архитектуры, тайна сия велика есть. Могу только повториться — мы пробовали все варианты работы полок, негативного опыта не было.
По цене обойдутся плюс-минус одинаково, но на 2 полках не работает enclosure awareness (нужно минимум 3).
Альтернатива жизнеспособная, кому что понравится.
И мы готовы отвечать. Более того, можно пообщаться с нашим техотделом и попросить удаленный доступ на север в тестовой лаборатории.
Про круглосуточную поддержку — есть, но это действительно стоит обговаривать, потому что в любом случае на такой запрос будет заключаться отдельный договор обслуживания, с прописыванием SLA.
1. Да, за узел (в самом верху есть примечание, что «Поставляются в составе шасси. Минимальное количество для заказа 4 штуки»).
2. А с чего ему себя ненормально чувствовать? С его точки зрения это 4 совершенно стандартных сервера, ничем не отличающихся от обычных 1U серверов.
3. Нет, просто это выходит за пределы стандартных гарантийных планов и обговаривается отдельно.
RS235
Берете
Развертываете Ceph и получается аналогичное изделие.
Общего хранилища нет, связи между нодами нет.
Да и жалоб на зависание бэкплейна оптом не было, так что вероятность возникновения проблемы явно небольшая (да, мы понимаем, что когда оно случится в продакшене — никому с размера вероятности легче не станет). При случае посмотрим, но пока наше мнение не изменилось: надо смотреть протокол, чтобы понимать, как именно устройство умудряется поставить в неприличную позу весь бэкплейн.
Кстати, хороший вопрос к Вам и Вашим коллегам: а у вас среди зависших были варианты с парой экспандеров на бекплейн, то есть работающим MPIO?
Не за что, обращайтесь ))
Как-то вот так:
PCIe Gen2 x4, в лучшем случае и это именно интерфейс для программирования матрицы. При большом желании можно, наверное, обработку трафика тоже через него гонять, но это нетривиальная задача.
А парочка даже не самых топовых зеонов с четвертью терабайта памяти уже удваивает цену коммутатора (а это 48 х 10G). Пока не видно сколько-нибудь значимого количества клиентов, желающих оплачивать создание такого удовольствия. А главное, не очень понятно зачем оно такое: какие вы видите задачи, чтобы их в принципе было выгодно решать на дорогостоящей (по энергопотреблению и стоимости обработки трафика) универсальной архитектуре и нельзя было реализовать на NPU?
Не нужно это, делать отдельный подвид ящиков сейчас нет смысла. Слишком специфична коммутационная часть.
>> Очевидно, что если компьютер поставить на базе архитектуры AMD64 (проц amd или intel), то он будет дешевле и быстрее, чем любые специализированные процессоры, просто из-за массовости производства.
Посмотрите на современный коммутатор — там уже стоят массовые PPC или Intel Atom, ось кидается на SSD, а за управление матрицей отвечает драйвер :)
На тот же Cumulus Linux можно ставить любой сторонний софт.