Сервер под SAP HANA: чек-лист по памяти, сети и сертификациям

Какие проблемы решает чек-лист до старта внедрения

Сервер под SAP HANA часто выбирают по привычным метрикам: побольше CPU, «быстрые диски» и запас по блокам питания. А ограничения всплывают позже, когда железо уже закуплено и менять его сложно. Чек-лист до старта внедрения помогает заранее увидеть узкие места и не попасть в ситуацию «все купили, но не запускается как нужно».

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

Второй частый стоп-фактор - сеть. Репликация, бэкапы, доступ приложений и администрирование могут упереться в задержки, перегрузку портов или отсутствие резервирования. Если это не проверить заранее, проект рискует задержками запуска из-за переделки архитектуры, простоями на тестах и пилоте, ростом бюджета на «внезапные» апгрейды и проблемами с поддержкой, если нет нужных подтверждений совместимости.

Простой пример: компания закупила сервер «с запасом по CPU», но поставила минимальную RAM и одну сетевую карту без резервирования. На нагрузочных тестах начались просадки, а при отказе порта сервис останавливался. Исправление потребовало докупать память, менять сетевую схему и заново согласовывать дизайн.

Собираем исходные требования, без которых нельзя считать конфигурацию

Первый шаг - не железо, а понятный список требований. SAP HANA быстро показывает слабые места, если сценарий и ожидания не проговорены заранее. Даже хороший сервер под SAP HANA можно подобрать неверно, если считать «в среднем по больнице».

Начните с типа нагрузки. ERP и S/4HANA обычно дают много транзакций и чувствительны к задержкам. BW и аналитика чаще упираются в объем данных в памяти и параллельные запросы. Смешанные нагрузки почти всегда требуют запаса по ресурсам, чтобы пики одной части не «съедали» производительность другой.

Дальше оцените данные в памяти и рост. Важно знать не только текущий объем, но и прогноз на 1-3 года: новые модули, рост пользователей, увеличение истории. Полезно заранее зафиксировать бизнес-точку отказа: что делаем, если память заполнится через 12 месяцев - расширяемся, переносим часть данных, меняем класс сервера.

Отдельно согласуйте доступность. Запишите допустимое окно простоя для плановых работ и цели RPO/RTO. Это напрямую влияет на выбор схемы (одиночный сервер, кластер, репликация), а значит - на сеть, хранение и бюджет.

Не забудьте про контурность: сколько будет систем (prod, QA, dev, sandbox, обучение). Частая ошибка - купить железо только под прод, а потом «распихивать» остальные системы на случайные ресурсы и получать проблемы в тестах и релизах.

Наконец, заранее определите резервное копирование и DR: где хранятся бэкапы, как часто делаются, как проверяется восстановление, нужен ли второй сайт.

Короткий набор вводных, без которых конфигурацию лучше не считать:

• профиль нагрузки (ERP/BW/S/4HANA/смешанный)
• объем данных в памяти сейчас и прогноз на 1-3 года
• требования по простоям, RPO и RTO
• список систем и их ориентировочные размеры (prod/QA/dev и т.д.)
• подход к backup и DR (частота, место, тест восстановления)

Когда эти пункты зафиксированы, расчеты по памяти, сети и совместимости становятся предметными, а не «угадыванием».

Память: проверяем объем, компоновку и возможность роста

Для SAP HANA память - главный ресурс. Если RAM не хватает, система начинает упираться в своп или частые выгрузки, и проект быстро превращается в поиск виноватых. Прикидка «впритык» почти всегда хуже, чем разумный запас.

Объем RAM: считать и закладывать запас

Базовую цифру обычно дают sizing-отчеты SAP или результаты пилота. В реальной жизни к ней добавляются рост данных, новые отчеты, расширение функционала и временные пики. Заранее согласуйте не только «сколько нужно сейчас», но и «сколько будет через 12-24 месяца», и заложите запас так, чтобы не останавливать систему ради замены половины модулей.

Сценарий из практики: на старте хватает 1,5 ТБ, закупают ровно 1,5 ТБ. Через полгода подключают новый контур аналитики - уже нужно 2 ТБ. Если свободных слотов нет, апгрейд становится дорогим и долгим.

Компоновка: слоты, каналы и NUMA простыми словами

Память важно ставить правильно: одинаковые модули, одинаковая емкость и частоты, заполнение по каналам согласно схеме сервера. Иначе часть каналов простаивает, и вы теряете пропускную способность, даже если общий объем выглядит внушительно.

NUMA простыми словами: в двухсокетном сервере у каждого процессора есть «своя» память, к которой он обращается быстрее. Если нагрузка постоянно тянется к памяти «чужого» сокета, растут задержки, а производительность становится менее предсказуемой. Поэтому важны баланс объема по сокетам и корректные настройки в BIOS и ОС.

Надежность и рост: ECC и план расширения

Для HANA обязательны ECC-модули. Дополнительные функции надежности (например, sparing или зеркалирование) стоит обсуждать отдельно: они могут повысить отказоустойчивость, но уменьшают доступный объем RAM.

Перед заказом проверьте две вещи: сколько слотов останется свободными после установки нужного объема и поддерживает ли платформа модули большей емкости, чтобы следующий шаг был «добавили планки», а не «поменяли все».

CPU и платформа: чтобы производительность не «плавала»

Для SAP HANA важна предсказуемость. Пользователи обычно замечают не среднюю скорость, а провалы: отчеты внезапно становятся медленнее, загрузка растет, окна обслуживания не укладываются.

Смотрите не на «максимум в турбо», а на то, что будет стабильно держаться под постоянной нагрузкой. Количество сокетов и ядер выбирайте от типа работы. Если у вас много параллельных запросов и фоновых задач, дополнительные ядра помогут. Если критичны быстрые одиночные операции, часто выигрывает более высокая базовая частота на меньшем числе ядер. Лучше заранее зафиксировать, что важнее: параллелизм или скорость одного потока.

Стабильность упирается и в настройки платформы. Если оставить BIOS «по умолчанию», сервер может уходить в энергосбережение, менять частоты и давать скачки задержек. Это особенно заметно в пиковые часы.

Что стоит согласовать заранее:

• модель CPU и профиль производительности без агрессивного энергосбережения
• режим NUMA и настройки памяти, чтобы доступ к RAM был предсказуемым
• параметры Turbo и ограничения по питанию, чтобы не было «всплесков» вместо стабильной базы
• выбранную ОС и ее версию, а также поддержку драйверов чипсета и сетевых карт
• если нужен гипервизор - его совместимость и ограничения по ресурсам

Отдельный выбор - bare metal или виртуализация. Bare metal проще для максимальной и ровной производительности. Виртуализация удобнее для управления, но требует дисциплины: резервирования ресурсов, запрета переподписки CPU и понятных лимитов на соседние ВМ. Иначе тесты пройдут, а в бою начнется «плавание».

Хранение данных: как не упереться в диски и контроллеры

В SAP HANA дисковая подсистема часто становится скрытым ограничением. Память и CPU могут быть с запасом, но если журналы пишутся с задержками или бэкап не укладывается в окно, внедрение быстро превращается в «пожар».

Первое, что нужно сделать для сервера под SAP HANA, - развести роли хранения. Смешивание «всего на одном пуле» почти всегда ухудшает предсказуемость. DATA (данные) и LOG (журналы) лучше держать отдельно, системные разделы и /usr/sap - на своем томе, а бэкапы - не на тех же томах, где рабочие данные, если это не просчитано по IOPS и месту. Также заранее планируйте каталоги экспорта и временных выгрузок: они незаметно «съедают» пространство.

Дальше решите, где действительно нужны минимальные задержки. Для LOG обычно критичны latency и стабильная запись, поэтому NVMe или быстрые enterprise SSD дают реальный эффект. Для DATA важнее баланс емкости, чтения и запаса по ресурсу записи (endurance), особенно при активных нагрузках.

Узкое место часто не в дисках, а в контроллере. RAID с слабым CPU, маленьким кэшем или неверным режимом записи «урезает» скорость даже на быстрых SSD. Проверьте заранее:

• поддерживается ли нужный RAID-уровень и есть ли батарея/суперконденсатор для безопасного write-back
• сколько линий PCIe реально доступно под NVMe, без конкуренции с сетью
• есть ли мониторинг износа SSD и понятный порядок замены без простоя
• как включается шифрование и кто его выполняет: диск, контроллер или CPU

Шифрование важно для требований безопасности, но может добавить задержки. Лучше сразу понять допустимый метод и заложить запас.

Отдельная тема - бэкапы. Считайте не только место под копии, но и скорость выгрузки. Если ночное окно 2 часа, а объем растет, может потребоваться отдельное хранилище или более быстрый канал, иначе регламент начнет «съезжать».

Сеть: пропускная способность, задержки и резервирование

Сеть для SAP HANA часто вспоминают слишком поздно: сервер уже выбран, а потом выясняется, что репликация, резервное копирование или окно обслуживания не укладываются по времени. Поэтому сеть стоит проверять так же строго, как память.

По скорости портов ориентируйтесь на профиль нагрузки. Для небольших инсталляций обычно хватает 10/25GbE, но при активной репликации, плотных бэкапах по сети или нескольких узлах легко упереться в 40/100GbE. Важно не только «сколько гигабит», но и где именно они нужны: иногда один быстрый uplink на коммутатор дает больше пользы, чем набор медленных портов.

Что проверить заранее

Разделяйте потоки, чтобы один тип трафика не мешал другому. Обычно разделяют клиентский доступ приложений, репликацию между площадками, бэкапы/переносы данных и управление (out-of-band, мониторинг, админ-доступ). Так проще держать стабильные задержки и быстрее находить причину проблем.

Для репликации особенно критичны задержки и потери пакетов. Даже при высокой средней скорости «шумы» в сети дают разрывы, повторные передачи и рост RPO. Хорошо, когда в проекте есть измеримые требования по latency, jitter и packet loss, а не только «канал 10 Гбит».

Резервирование закладывайте сразу: два сетевых пути, два коммутатора, корректно настроенный LACP (или другой вариант отказоустойчивости). И отдельно проверьте совместимость NIC, драйверов и настроек offload: иногда именно они становятся причиной нестабильности на этапе запуска.

Сертификации и совместимость: что нужно подтвердить заранее

Даже если сервер по характеристикам «похож на правильный», внедрение SAP HANA часто упирается в формальные ограничения: платформа не в списке поддерживаемых, версия ОС не совпадает с требованиями, а драйвер для сетевой карты доступен только в другой ветке прошивки.

Первое, что стоит подтвердить: выбранная модель сервера и конкретная конфигурация (CPU, объем и тип памяти, контроллеры, сетевые адаптеры, накопители) есть в списках поддерживаемого оборудования SAP для HANA. Обычно это проверяют по каталогу сертифицированного оборудования SAP HANA и матрицам совместимости SAP (для ОС и гипервизора, если он используется).

Что согласовать до закупки

Зафиксируйте в ТЗ или переписке:

• платформа и конфигурация сертифицированы под ваш сценарий HANA (апплаенс или TDI)
• операционная система и релиз поддерживаются для вашей версии SAP HANA (и планируемого обновления)
• конкретные модели RAID/HBA, NIC, SSD и модулей памяти входят в поддерживаемые списки, а не просто «подходят по интерфейсу»
• набор прошивок и драйверов на запуск: кто его дает и как обновляться без сюрпризов
• границы ответственности при инцидентах: железо, ОС, SAP, и как эскалировать проблемы «на стыке»

Пример типовой ловушки: HANA установили, под нагрузкой появляются сетевые ошибки. Оказывается, рекомендованный драйвер NIC рассчитан на другую версию прошивки BIOS/UEFI, а обновление требует окна простоя. Если заранее согласовать стек версий и поддержку со стороны интегратора и вендора, таких пауз обычно удается избежать.

Надежность и эксплуатация: питание, охлаждение, сервис

Даже идеально подобранный сервер под SAP HANA может «упасть» не из-за CPU или памяти, а из-за питания в стойке, перегрева или отсутствия нужной детали на складе. Эти риски дешевле закрыть в проекте, чем ловить простои в продакшене.

По питанию важно смотреть не только на количество блоков, но и на схему. Для HANA обычно нужен минимум N+1 по блокам питания, но это работает только если они разведены по разным линиям и PDU. Проверьте, что в стойке хватает розеток, что линии действительно независимы и что ИБП держит нужную мощность и время.

Охлаждение часто ограничивает сильнее, чем кажется. Сверьте тепловыделение сервера с возможностями зала (кВт на стойку), проверьте направление воздушных потоков, заглушки, горячие и холодные коридоры.

Мониторинг лучше определить заранее: какие температуры и события считаются нормой, а какие требуют заявки. Обычно контролируют температуры CPU/памяти и воздуха на входе, состояние дисков и контроллера, ошибки ECC, сетевые ошибки и потери, а также нагрузку и события по питанию.

Поддержку и сервис фиксируйте конкретно: время реакции и восстановления по критичности, наличие ЗИП (на месте или в городе), порядок обновлений BIOS/firmware и ответственность за совместимость, регламент окон обслуживания и тестовый прогон после работ, единая точка контакта 24/7.

Пример сценария: как чек-лист помогает не переделывать архитектуру

Компания запускает S/4HANA на 500-800 пользователей. Планируют высокую доступность и репликацию между двумя площадками. На старте кажется, что все просто: купить сервер под SAP HANA, поставить и начать внедрение.

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

По чек-листу команда находит узкие места до закупки. По памяти расчет «на сейчас» проходит, но компоновка не оставляет места для роста. По сети 10GbE оказывается на грани для репликации, а отсутствие резервирования делает HA номинальной. По дискам не выдерживаются пики на LOG и временных данных, и полная копия не успевает завершиться в окно.

Решения тоже принимают заранее: закладывают запас по RAM с понятным планом расширения, планируют 25/40GbE и разделение трафика с резервированием, выбирают быстрые NVMe для критичных томов и заранее считают бэкапы, фиксируют требования к сервису.

Пошагово: как выбрать конфигурацию и пройти согласования

Начните с того, как система должна работать после запуска. Зафиксируйте SLA по простоям и восстановлению (RPO/RTO), окна обслуживания, план роста данных на 12-36 месяцев и зоны ответственности за бэкапы, обновления и мониторинг.

Дальше удобно идти по цепочке от расчетов к подтверждениям и только потом к заказу:

1. Снимите вводные: текущая нагрузка, объем данных, рост, критичные отчеты, интеграции, требования ИБ и регуляторов. Параллельно согласуйте RPO/RTO и ограничения площадки (стойки, питание, охлаждение).

2. Сделайте sizing и черновую конфигурацию: объем ОЗУ с запасом, класс CPU, количество сокетов, схема расширения. На этом шаге решите, будет ли один узел или кластер.

3. Проверьте совместимость и подтверждения: конкретные модели серверов, накопителей, сетевых карт, драйверов и гипервизора (если он допускается).

4. Спроектируйте сеть и хранение под бэкапы и репликацию: пропускная способность, задержки, разделение трафика, резервные каналы и место под резервные копии.

5. Согласуйте план поставки и ввода: сроки, набор тестов, критерии приемки, план отката. Если это госзакупка, заранее проверьте требования к локальному происхождению и пакету документов.

Перед запуском в продуктив проведите приемочные проверки (память, NUMA, сеть, отказоустойчивость), зафиксируйте настройки и версии прошивок, оформите протоколы. Тест на фактический RPO/RTO часто выявляет узкое место не в CPU, а в канале для бэкапов.

Частые ошибки при закупке сервера под HANA

Самая частая ошибка - выбрать сервер по числу ядер, а не по памяти. Для SAP HANA почти все упирается в RAM: если объема не хватает, система начинает жить на дисках, и даже мощный CPU уже не спасает. Сначала фиксируйте память с запасом, потом подбирайте процессоры и платформу.

Вторая типовая ошибка - память «из того, что было». Когда в одном сервере смешивают модули разного объема, рангов или частот, контроллер памяти может перейти в менее выгодный режим, а иногда появляются странные просадки под нагрузкой. Проще сразу закладывать симметричную компоновку и проверять, как сервер масштабируется при добавлении RAM.

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

С дисками легко ошибиться «на бумаге»: покупают быстрые SSD, но упираются в контроллер, кэш или неверный RAID-профиль. Всегда проверяйте, выдерживает ли контроллер нужный IOPS и пропускную способность, и согласуйте RAID под роли томов.

И еще одна проблема - не фиксируют версии прошивок и драйверов. Затем теряют совместимость после обновлений или получают инциденты на стыке компонентов. Параллельно часто забывают план расширения: данные растут быстрее прогноза, и через год приходится менять архитектуру вместо простого апгрейда.

Быстрый чек-лист перед заказом и что делать дальше

Перед тем как фиксировать спецификацию и отправлять ее в закупку, пройдитесь по короткому чек-листу. Он помогает поймать ограничения заранее и не переделывать архитектуру уже на внедрении.

Проверьте:

• RAM: хватает ли объема с запасом под рост, правильная ли компоновка по каналам, есть ли план расширения без замены платформы.
• CPU и платформа: выбран ли поддерживаемый класс процессоров, согласованы ли стабильные настройки (частоты, энергопрофили), понятны ли требования к виртуализации, если она планируется.
• Диски и бэкап: разделены ли DATA и LOG, прозрачен ли RAID (какой именно и почему), хватает ли производительности контроллера, укладываются ли бэкапы и восстановление в окна.
• Сеть: подходят ли скорости под сценарий, есть ли резервирование (каналы и коммутаторы), разделен ли трафик (пользовательский, репликация, бэкап, администрирование).
• Сертификация и совместимость: подтверждены ли поддержка платформы, ОС и ключевых компонентов (NIC, RAID/HBA, NVMe), чтобы не упереться в формальные ограничения.

Дальше важна фиксация договоренностей на бумаге. Даже небольшая неоднозначность (например, по сетевому резервированию или типу RAID) часто превращается в допзакупку и сдвиг сроков.

Что сделать после чек-листа:

1. Сформировать короткое ТЗ: нагрузка, объемы, SLA, рост на 2-3 года, ограничения по стойкам и питанию.
2. Сверить ТЗ с интегратором и поставщиком, включая совместимость компонентов и план масштабирования.
3. Попросить финальную спецификацию с явными параметрами (RAM по слотам, модели NIC и HBA, тип RAID, порты, кабели).
4. Согласовать схему сети и резервирования с командой эксплуатации.
5. Зафиксировать поддержку и сервис: кто и как реагирует, есть ли 24/7 и запчасти.

Если нужен быстрый подбор и предварительная проверка совместимости, это удобно делать с производителем и системным интегратором, который отвечает и за поставку, и за поддержку. Например, GSE.kz (gse.kz) может закрыть серверную часть и интеграцию, а также обеспечить поддержку 24/7 через сервисную сеть по Казахстану.