NetApp AFF A-Series для баз данных и VDI: как выбрать

С чего начать: БД и VDI требуют разного подхода

Если вы рассматриваете NetApp AFF A-Series для баз данных и VDI, начните с простого: эти нагрузки "болят" по-разному, и один и тот же показатель IOPS не всегда отражает реальную картину.

Для баз данных чаще всего критичны задержки и их разброс. Средние IOPS могут выглядеть отлично, но если время отклика то 1 мс, то 20 мс, это сразу чувствуют и пользователи, и приложение. Типичные симптомы: медленные транзакции в пике, рост времени запросов, очереди на диске, срыв окна бэкапа или обслуживания.

VDI чаще упирается в короткие "шторма". Boot storm возникает, когда много виртуальных рабочих мест стартуют одновременно (обычно утром). Login storm - когда все заходят в систему почти в одно время, и начинается массовое чтение профилей, политик и кэшей. В обычные часы VDI может быть спокойным, но в пике резко требует больше ресурсов и очень чувствителен к задержке.

Практический принцип такой:

• Для БД важнее стабильная задержка, чем "максимальные IOPS по паспорту".
• Для VDI важнее поведение в коротком пике и то, как быстро система возвращается к норме.

До обсуждения контроллеров и дисков договоритесь, что будет считаться успехом. Обычно фиксируют 3-5 метрик: SLA по задержке (с уточнением, где измеряем - на хосте, в ОС или в приложении), время логина VDI и готовности рабочего стола, плотность VDI на хост (сколько рабочих мест на один сервер без жалоб), реальные RTO/RPO и окно бэкапа, а также поведение в пике (например, в 9:00 и в конце отчетного периода).

Дальше честно перечислите ограничения. Часто именно они сильнее всего влияют на конфигурацию:

• место в стойке, питание и охлаждение
• текущая SAN/LAN и что реально можно поменять в срок проекта
• бюджет, сроки закупки и требования к локальной поддержке
• политики по шифрованию, сегментации сети и резервному копированию

Пример: у вас одна критичная БД с регулярными пиками по записи и VDI на 300 пользователей. Для БД вы фиксируете цель "задержка не выше X мс в рабочий пик", для VDI - "логин не дольше Y секунд утром". С такими целями легче спорить не о цифрах в брошюре, а о проверяемом результате на пилоте.

Какие данные собрать до выбора конфигурации

До обсуждения контроллеров и дисков соберите факты о нагрузке. Иначе выбор будет "по ощущениям", а в случае AFF это нередко заканчивается либо переплатой, либо неожиданной задержкой под пиком.

Снимите реальные метрики хранения за типичный рабочий период (лучше 7-14 дней) и отдельно за "плохие часы" (закрытие дня, утренний вход пользователей, бэкапы). Смотрите не только средние значения, но и хвосты.

Метрики, без которых нельзя

Минимальный набор:

• latency p95/p99 (отдельно чтение и запись) и максимум на пиках
• IOPS и throughput (MB/s) за те же периоды
• размер рабочего набора: сколько данных реально "горячие" в течение дня
• очереди и глубина (queue depth) на хостах, чтобы понять, где упираетесь - в СХД, сеть или серверы

Профиль нагрузки: блоки и характер I/O

Зафиксируйте:

• размеры блоков (4K/8K/16K и крупнее) и долю каждого
• соотношение чтение/запись по часам (у VDI запись часто растет на логине)
• случайная или последовательная нагрузка, и что именно делает ее последовательной (бэкап, ETL, отчеты)

Отдельно оцените рост на 12-36 месяцев. Для БД и VDI прогноз лучше вести раздельно: у БД обычно растут объем и журналы, у VDI - число пользователей и размер профилей.

Опишите состав окружения: гипервизор, версия ОС, тип VDI (persistent/non-persistent), тип профилей (локальные, roaming, контейнеры), тип БД и критичные операции (OLTP, отчеты, batch). Формулировка "10:00-11:00 массовый логин 800 пользователей VDI + параллельно закрытие дня в БД" полезнее, чем "нагрузка высокая".

И отдельно - требования к отказоустойчивости: целевые RPO/RTO, допустимые окна обслуживания, есть ли "тихие" окна вообще. Эти ответы сразу задают рамки и по архитектуре, и по тому, как проводить пилот без риска для продакшена.

Как выбирать контроллеры AFF A-Series под вашу нагрузку

Главный риск - взять контроллеры, которые "вывозят" среднюю нагрузку, но проседают на пиках. Поэтому начинайте не с емкости, а с задержек и параллельности: сколько одновременных потоков I/O будет в пике, какая доля мелких операций, как часто бывают всплески (утренний шторм логинов в VDI, ночные джобы в БД) и как быстро растет нагрузка.

HA-пара: что проверить заранее

AFF обычно берут в HA-паре, чтобы переживать отказ одного контроллера без простоя. На практике "без простоя" зависит от деталей. До выбора модели и конфигурации проверьте:

• какие приложения чувствительны к коротким паузам (особенно VDI и транзакционные БД)
• как будет выглядеть переключение путей на хостах (MPIO, таймауты)
• есть ли запас по производительности на одном контроллере на время аварии или обслуживания
• как организованы обновления и плановые работы

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

Порты и подключение: чтобы не упереться в сеть

Частая ошибка - выбирать систему "по IOPS", а затем упереться в порты и аплинки. Для БД нередко выбирают FC или iSCSI, для VDI - NFS/SMB (зависит от платформы виртуализации и принятой архитектуры). Смысл простой: должно хватать портов и пропускной способности, чтобы не жить на 60-70% загрузки уже в первый год.

Перед закупкой быстро проверьте: сколько хостов и какие скорости портов у них уже есть, сколько путей вы реально разведете (для отказоустойчивости и балансировки), есть ли отдельные сети или фабрики под storage-трафик, и какой запас по аплинкам оставляете на рост и "шумные" периоды.

Память и кеш помогают, когда нагрузка повторяется и хорошо попадает в кеш (часто читаемые блоки). Но если сеть узкая или на хостах неверные параметры, кеш не спасет. Поэтому оценку контроллера делайте вместе с планом по сети и настройкам хостов.

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

Как выбирать диски и полки: емкость, запас и отказоустойчивость

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

Емкость и производительность

Большой SSD сам по себе не делает систему быстрее. Для БД важны стабильные задержки на записи, для VDI - всплески по утрам и "шторм" при обновлениях. Нередко конфигурация с большим числом дисков меньшей емкости работает ровнее, чем несколько очень больших SSD.

Сформулируйте приоритет заранее: максимум активной емкости или запас по производительности в пиках. От этого зависит, сколько дисков и полок нужно на старте.

Запас: рост, снапшоты и rebuild

Свободное место нужно не только "на будущее", но и на служебные задачи: снапшоты, временные пики записи, перестроение при отказе диска (rebuild). Если система постоянно заполнена почти под завязку, предсказуемость обычно ухудшается.

Перед закупкой полезно зафиксировать: ожидаемый рост на 12-18 месяцев, сколько места уйдет под снапшоты и тестовые копии, какой резерв держите под rebuild и пики, и будут ли отдельные пулы под БД и VDI или все вместе.

RAID простыми словами: риск и полезная емкость

RAID позволяет пережить отказ диска без простоя. Больше защиты - ниже риск, но меньше полезной емкости.

Если объяснять просто: двойная защита выдержит отказ двух дисков, тройная - трех. Тройная защита спокойнее для больших групп дисков, но заметнее "съедает" емкость. Выбор зависит от критичности сервисов и от того, насколько болезненна даже редкая авария.

План расширения: чтобы не переделывать продакшен

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

Если работаете через интегратора, попросите план "сегодня и через год": какие полки добавятся, как изменится защита данных и сколько полезной емкости останется после резервов. Это помогает избежать ситуации, когда расширение вроде возможно, но для него внезапно нужно останавливать и перекраивать половину системы.

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

Дедупликация и сжатие в all-flash часто дают хорошую экономию, но только если вы понимаете, какие данные будут лежать на СХД и как они меняются. Для VDI обычно много одинаковых блоков (образы ОС, однотипные профили). Для БД картина сильно зависит от типа данных, уровня шифрования и того, как устроены бэкапы и журналы.

Уточняйте не общий красивый коэффициент, а прогноз именно под ваши данные и условия, при которых он достижим. Хорошая оценка всегда привязана к конкретике: сколько одинаковых образов VDI, какая СУБД, включено ли TDE или другое шифрование, какие размеры блоков, как хранятся логи и временные таблицы.

Вопросы, которые стоит задать

Старайтесь формулировать так, чтобы в ответе были цифры, допущения и границы применимости:

• какой ожидаемый data reduction отдельно для VDI и отдельно для БД (данные, логи, бэкапы), и при каких условиях
• дедупликация работает в пределах тома или между томами, и что это означает для VDI-пулов и клонов
• сжатие выполняется inline или после записи, и есть ли сценарии, где это заметно влияет на задержку
• как меняется экономия при включенном шифровании на уровне СУБД или приложений
• какой запас по емкости и производительности закладывать, если реальный коэффициент окажется в 2 раза ниже прогноза

Важно отличать общий коэффициент по системе и реальность по рабочим наборам. VDI может дать 4:1 и выше, а БД с зашифрованными таблицами и уже сжатыми бэкапами - около 1:1, то есть почти без выигрыша.

Как проверить влияние на производительность

Экономия не должна ухудшать отклик. На пилоте заранее договоритесь, какие отчеты и графики вы получите, и что считается нормой: p95/p99 задержек чтения и записи (не только среднее), IOPS и пропускная способность в часы пиков, загрузка контроллеров и признаки упора в CPU при включенных efficiency-функциях, доля случайной записи и влияние на write latency.

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

Подключение и сеть: где чаще всего теряется производительность

Даже правильно подобранная конфигурация может показать слабые результаты, если сеть и подключение собраны "как получилось". В пилоте это видно быстро: задержка скачет, IOPS не растут, а причина часто не в СХД.

FC, iSCSI или NFS/SMB: выбирайте по навыкам и точкам риска

Самый надежный выбор обычно тот, который команда уже умеет поддерживать в продакшене.

• FC часто берут под критичные БД, когда важны предсказуемые задержки и уже есть SAN-коммутаторы и опыт с zoning.
• iSCSI проще расширять в Ethernet-сети, но он чувствительнее к качеству настройки (MTU, очереди, перегрузки uplink).
• NFS/SMB логичны для VDI и виртуализации, когда удобнее управлять датасторами на уровне файлов.

Если инфраструктура смешанная, не пытайтесь "усреднить" требования. Для БД важнее стабильная задержка и корректный multipath, для VDI - широкая полоса и отсутствие узких мест на стороне гипервизора.

Отказоустойчивость и multipath: минимум для честного пилота

Закладывайте схему "2 коммутатора, 2 пути" и проверьте, что на хостах multipath действительно работает. Типичная проблема: один путь активен, второй простаивает, и вы тестируете половину пропускной способности, не понимая почему.

Чаще всего пилот портят мелочи:

• несовпадающий MTU (jumbo включили только на части узлов)
• перегруженный uplink или общий trunk, где VDI, бэкап и продакшен мешают друг другу
• неправильный zoning (для FC) или хаотичная адресация и ACL (для IP)
• слишком маленькие очереди и лимиты на хосте или HBA/NIC, из-за чего растет latency
• один "слабый" коммутаторный порт, который стал бутылочным горлышком

Разделяйте трафик: продакшен БД и VDI - отдельно от репликации и бэкапа хотя бы на уровне VLAN/VRF и uplink-групп. Иначе в момент теста все будет хорошо, а при реальной ночной репликации задержки вырастут.

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

Пример из пилотов: VDI тестируют по NFS, но на том же uplink оставляют ночной бэкап. В "тихий" час все отлично, а при реальной нагрузке пользователи видят подвисания. Вывод тут не про СХД, а про разделение трафика и дисциплину портов.

Пилот без остановки продакшена: пошаговый план

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

Цель пилота и безопасное подключение

Сначала зафиксируйте, что именно вы хотите доказать пилотом. Для БД это обычно стабильные задержки на записи и предсказуемость под пиками. Для VDI - поведение при утреннем входе пользователей и скорость массовых операций с образами.

Дальше выберите способ подключения без риска: отдельные тома и LUN для теста (или отдельный пул) и ограничения на доступ (отдельные хост-группы, инициаторы, правила зонирования и маскирования). Так вы исключите ситуацию, когда тест заденет боевые LUN или начнет конкурировать за ресурсы в неподходящий момент.

Перенос данных, измерения и откат

Данные переносите так, чтобы тест был похож на реальность, но не требовал остановки продакшена. Для БД это обычно копия базы с восстановлением из бэкапа или репликация на тестовый экземпляр и короткая синхронизация перед нагрузочными тестами. Для VDI удобно взять эталонный образ, сделать клон и поднять небольшой тестовый пул с теми же политиками профилей и антивируса. Отдельно согласуйте с ИБ доступы, журналы и возможность использовать обезличенные данные.

Чтобы результаты сравнивались, измеряйте "до" и "после" в одинаковые окна и при одинаковой нагрузке. Обычно хватает:

• p95/p99 задержек чтения и записи (по хосту и по СХД)
• IOPS и пропускная способность
• глубина очереди и утилизация CPU на хостах
• время логина VDI и время запуска приложений
• время операций с образами (refresh, recompose, обновления)

План отката должен быть записан. Заранее определите, кто принимает решение об остановке теста и что считается деградацией: рост p95 задержки записи для БД выше порога, рост времени логина VDI, ошибки ввода-вывода, выход за окно обслуживания.

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

Пример пилота: одна БД и небольшой пул VDI

Типичная ситуация: есть действующая SAN, база в целом работает нормально, но иногда ловит пики задержки (особенно во время бэкапов или тяжелых отчетов). Параллельно VDI по утрам "проседает": пользователи долго логинятся, приложения открываются с паузами, растет нагрузка из-за boot storm.

Чтобы пилот дал честный ответ, не пытайтесь сразу перенести все. Выберите 1-2 критичных, но переносимых сервиса и небольшой, управляемый пул VDI. Например: одна БД (копия или вторичный контур, где можно повторить нагрузку) и VDI-пул на 30-80 пользователей с одинаковой ролью, чтобы сценарий был сопоставим.

Границы пилотного контура зафиксируйте заранее: какие LUN/тома переезжают, какие хосты подключаются, какие окна допускаются для переключений и как откатываетесь назад. Важно, чтобы продакшен оставался на старой SAN, а вы тестировали копию данных или сегмент, который можно вернуть без долгого простоя.

Дальше прогоните короткий набор проверок, который отражает реальные пики, а не "красивые" синтетические цифры: утренний логин VDI, массовый запуск 2-3 основных приложений, бэкап БД (или имитация) параллельно с обычной работой, тяжелые запросы БД (отчеты, сортировки, пакетные операции), небольшой стресс на запись (журналы, temp, обновления).

Сравнивайте не средние значения, а поведение под пиком и хвосты:

• перцентили задержки (p95/p99) по чтению и записи
• время логина в VDI и время запуска ключевого приложения
• стабильность: как быстро система возвращается к норме после пика
• сеть: упор в порты, MTU, очереди, ошибки

По итогам обычно бывают два типа выводов. Первый: хранилище выдерживает пик, но проблемы остаются - тогда чаще виноваты сеть, multipath, параметры ОС/гипервизора или профиль VDI. Второй: задержка на хвостах все еще высокая - тогда вы уже предметно решаете, нужна ли другая конфигурация контроллеров, больше SSD, другой шаг полок или разнос нагрузок между БД и VDI.

Типичные ошибки при выборе и пилоте AFF для БД и VDI

Чаще всего разочарование в пилоте all-flash связано с неправильными ожиданиями и измерениями. Для БД и VDI это особенно заметно: у них разный профиль I/O, а пользователи чувствуют не среднее, а редкие задержки.

Самые частые ошибки:

• смотрят на средние IOPS и задержку и игнорируют пики и p95/p99
• воспринимают дедупликацию и сжатие как гарантированную экономию (для VDI это часто верно, для БД эффект может быть скромным и меняться при шифровании и компрессии на уровне приложения)
• грузят в пилот слишком много задач сразу, а потом не могут понять, что именно дало эффект
• не закладывают емкость под снапшоты и рост: пилот проходит на маленьких данных, а в реальной работе место быстро заканчивается
• оставляют сеть и хосты "как есть" и винят СХД: неверный MTU, перегруженные порты, старые драйверы, ошибки multipath, кривые очереди легко дадут высокую задержку даже на быстрой системе

Небольшой пример: пилотируют одну БД и VDI на 50-100 пользователей. По среднему все красиво, но в 9:05 p95 задержки прыгает, и VDI начинает тормозить. Часто причина не в дисках, а в узком месте сети или гипервизора: не хватает полосы, неверно настроены очереди, или нагрузка попала в один путь.

Чтобы избежать таких ситуаций, заранее фиксируйте: какие метрики сравниваете (включая p95/p99), какие данные берете для проверки эффективности, какой объем оставляете под снапшоты, и какие настройки делаете на сети и хостах. Если пилот ведет интегратор, попросите краткий протокол: что измерили, что поменяли и какой эффект это дало.

Короткий чеклист и следующие шаги

Чтобы принять решение без лишних споров, используйте два коротких чеклиста: перед закупкой и перед пилотом.

Перед закупкой убедитесь, что собраны входные данные, которые реально влияют на контроллеры, диски и сеть: профиль нагрузки (IOPS, latency средняя и p95, throughput, размеры блоков, доля чтения/записи, пики), рост (объем и прирост, рабочий набор), требования к доступности (RPO/RTO, окна обслуживания, допустимая деградация при отказе), подключение (протоколы, число хостов и портов, MTU, uplink-ы), план расширения на 12-24 месяца.

Пилот готовьте так, чтобы он был показательный и безопасный: изоляция теста (отдельный VLAN или зона, отдельные LUN/volumes), перенос данных (реплика, восстановление из бэкапа, типичный набор, а не только "легкие" таблицы), критерии успеха (для БД - задержка на записи и стабильность в пике; для VDI - время логина, открытие профиля и отсутствие деградации в утренний пик), понятный план отката, отдельная фиксация фактической экономии от дедупликации/сжатия и ее влияния на задержки.

Полезный формат для вендора или интегратора - один файл на 10-15 строк с цифрами: IOPS/latency/throughput, объем, рост, протоколы, число хостов, RPO/RTO, целевые метрики пилота. Это ускоряет подбор и снижает риск недоконфигурации.

Решение по итогам пилота лучше принимать по "достаточному улучшению": для БД это предсказуемая задержка в пике и запас по CPU и портам контроллера, для VDI - стабильная работа при массовых логинах и понятная емкость на одно рабочее место.

Дальше обычно идут проектирование (схема сети, протоколы, отказоустойчивость), пилотный стенд, миграция по волнам и ввод в эксплуатацию, а затем регулярные проверки и поддержка. Если нужен партнер, GSE.kz может помочь как системный интегратор: закрыть не только часть со СХД, но и серверную инфраструктуру под VDI и БД, а также обеспечить 24/7 техническую поддержку после запуска.