Comments 4
HANA как известно любит память. Какие лимиты (сокеты, TB ram) на узел для Hyperflex?
При публикации из текста случайно пропала ссылка на страницу сертификации, где указаны параметры. Спасибо, что подметили. Вот она.
Базовым вариантом является 2-процессорная конфигурация узла с 768GB памяти, при необходимости, объем памяти 2-процессорного узла может быть увеличен до 3ТБ.
Также стоит отметить, что в кластере HyperFlex могут находиться «бездисковые» узлы, в том числе и 4-процессорные с объемом памяти до 6ТБ.
Напомним, Cisco давно и успешно реализует проекты SAP HANA в трех основных вариантах:
• bare-metal appliance на базе стоечных серверов, который хранит данные на локальных SSD дисках, защита данных обеспечивается программной репликацией;
• Горизонтально-масштабируемый scale-out bare-metal appliance для аналитических систем с реализацией вычислительных узлов на блейдах, подсистемы хранения – на распределенной файловой системе;
• Виртуализированная платформа на базе блейд-серверов и «корпоративного» сертифицированного дискового массива, на основе одного из имеющихся типовых дизайнов Flexpod, FlashStack и т.д.
По сути, HyperFlex – еще одна дополнительная опция, со своими очевидными преимуществами для своего спектра задач. Что важно: ВСЕ эти варианты построены на одной платформе Cisco UCS с интегрированной коммутацией и интегрированным управлением на основе политик и шаблонов. Никто не мешает (если в этом есть необходимость, продиктованная, например, масштабами, историческими причинами, принятыми стандартами и т.д. и т.п.) в рамках одной системы с одной архитектурой с единым управлением строить комбинированный ландшафт HANA на базе scale-up appliance (например, для критичных HANA-систем под ERP-задачи), scale-out appliance (например, для крупной системы аналитики) и HyperFlex (например, для средних по масштабу продуктивных нагрузок, а также систем DEV и QA).
Безусловно, в той же серверной системе с интегрированной коммутацией и управлением, как правило, размещаются и серверы приложений (часто виртуализированные), но что еще интереснее, там же могут быть размещены системы для построения инфраструктуры SAP Data Hub на базе контейнеров поверх HyperFlex, а также системы машинного обучения SAP Leonardo на базе специализированной платформы C480 ML (c 8-ю адаптерами Nvidia V100 объединенных транспортом NVLink).
Базовым вариантом является 2-процессорная конфигурация узла с 768GB памяти, при необходимости, объем памяти 2-процессорного узла может быть увеличен до 3ТБ.
Также стоит отметить, что в кластере HyperFlex могут находиться «бездисковые» узлы, в том числе и 4-процессорные с объемом памяти до 6ТБ.
Напомним, Cisco давно и успешно реализует проекты SAP HANA в трех основных вариантах:
• bare-metal appliance на базе стоечных серверов, который хранит данные на локальных SSD дисках, защита данных обеспечивается программной репликацией;
• Горизонтально-масштабируемый scale-out bare-metal appliance для аналитических систем с реализацией вычислительных узлов на блейдах, подсистемы хранения – на распределенной файловой системе;
• Виртуализированная платформа на базе блейд-серверов и «корпоративного» сертифицированного дискового массива, на основе одного из имеющихся типовых дизайнов Flexpod, FlashStack и т.д.
По сути, HyperFlex – еще одна дополнительная опция, со своими очевидными преимуществами для своего спектра задач. Что важно: ВСЕ эти варианты построены на одной платформе Cisco UCS с интегрированной коммутацией и интегрированным управлением на основе политик и шаблонов. Никто не мешает (если в этом есть необходимость, продиктованная, например, масштабами, историческими причинами, принятыми стандартами и т.д. и т.п.) в рамках одной системы с одной архитектурой с единым управлением строить комбинированный ландшафт HANA на базе scale-up appliance (например, для критичных HANA-систем под ERP-задачи), scale-out appliance (например, для крупной системы аналитики) и HyperFlex (например, для средних по масштабу продуктивных нагрузок, а также систем DEV и QA).
Безусловно, в той же серверной системе с интегрированной коммутацией и управлением, как правило, размещаются и серверы приложений (часто виртуализированные), но что еще интереснее, там же могут быть размещены системы для построения инфраструктуры SAP Data Hub на базе контейнеров поверх HyperFlex, а также системы машинного обучения SAP Leonardo на базе специализированной платформы C480 ML (c 8-ю адаптерами Nvidia V100 объединенных транспортом NVLink).
Проще SAP в облаке по подписке взять,
чем строить свою компонуемо адаптируемую гиперконвергентность.
Использовать облачную ИТ-платформу или строить свою – это решение, которое зачастую лежит не в технической плоскости.
По сути, это решение, где провести границу ответственности, брать ли на себя организационные вопросы обеспечения работы платформы, или найти подрядчика для их решения.
У облачного варианта ведь тоже есть свои особенности, например, организация сквозных политик безопасности, аутентификации и защиты конфиденциальных данных.
Построение ландшафта SAP традиционно считалось достаточно сложной задачей, чтобы серьезно обсуждать вариант ее разворачивание в облаке.
Задача гиперконвергентных решений – понизить уровень сложности on premises внедрений, и в случае с HyperFlex это действительно происходит.
В любом случае – финальное решение всегда за заказчиком.
По сути, это решение, где провести границу ответственности, брать ли на себя организационные вопросы обеспечения работы платформы, или найти подрядчика для их решения.
У облачного варианта ведь тоже есть свои особенности, например, организация сквозных политик безопасности, аутентификации и защиты конфиденциальных данных.
Построение ландшафта SAP традиционно считалось достаточно сложной задачей, чтобы серьезно обсуждать вариант ее разворачивание в облаке.
Задача гиперконвергентных решений – понизить уровень сложности on premises внедрений, и в случае с HyperFlex это действительно происходит.
В любом случае – финальное решение всегда за заказчиком.
Sign up to leave a comment.
Cертифицированная инфраструктура на базе HyperFlex для SAP HANA