Что выбрать, NVMe или SAS для учетной системы?

Для учетной системы на 100 пользователей я бы по умолчанию выбирал серверные NVMe, но не потому, что у них красивее цифры последовательного чтения. Важнее низкая задержка коротких случайных операций при небольшой глубине очереди. Именно такие операции стоят между нажатием кнопки «Провести» и появлением результата у бухгалтера. Исправный массив из SAS SSD тоже может дать быстрый и предсказуемый отклик. Массив из SAS HDD при одновременной работе ста человек почти всегда проиграет, даже если его емкости и паспортной скорости хватает.

Само число пользователей ничего не доказывает. Сто кассиров с короткими документами, сто аналитиков с тяжелыми отчетами и сорок активных сотрудников из ста заведенных учетных записей создают разную нагрузку. До закупки нужно узнать задержку текущей базы, долю чтения и записи, размер активных данных, пики закрытия периода и поведение журнала транзакций. После этого выбор часто становится простым: NVMe нужен там, где накопитель уже задерживает запросы; SAS остается разумным там, где важнее совместимость, двухпортовое подключение или повторное использование исправной серверной полки.

Сто пользователей не равны ста одновременным запросам

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

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

На стороне СУБД полезны четыре группы наблюдений:

• задержка чтения и записи по файлам данных, журналу и временной базе;
• физические чтения, записи и объем данных в секунду;
• длина очереди и 95-й или 99-й процентиль времени ответа;
• ожидания СУБД, загрузка процессора, доступная память и блокировки.

Последний пункт нужен, чтобы не купить дорогие диски вместо исправления запроса. Microsoft в руководстве по диагностике SQL Server прямо разделяет задержку хранилища, лишние логические чтения, нехватку памяти, блокировки и влияние фильтрующих драйверов. Если запрос читает миллионы строк из-за отсутствующего индекса, NVMe сократит физическую часть ожидания, но не превратит плохой план выполнения в хороший. Если все рабочие страницы уже находятся в буферном кеше, замена SAS SSD на NVMe может почти не изменить обычное открытие формы.

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

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

Виртуализация добавляет еще один уровень измерений. Гостевая система может показывать очередь на своем виртуальном диске, пока реальная задержка возникает в общем datastore, на HBA или из-за соседней виртуальной машины. Снимайте метрики внутри гостя и на гипервизоре за один интервал. Ускорение локального NVMe ничего не даст виртуальному диску, который по-прежнему лежит на перегруженном общем массиве.

NVMe ускоряет короткие операции, если они доходят до диска

Реальный выигрыш NVMe заметнее всего в операциях, где пользователь ждет цепочку зависимых чтений или подтверждение записи журнала. К таким операциям относятся проведение документа, поиск по не полностью закешированному индексу, открытие карточки после длительного простоя, запись множества строк и сортировка, которая вышла во временную базу. Здесь задержка одной операции важнее максимальных мегабайт в секунду.

Протокол NVMe создавали для энергонезависимой памяти и подключения через PCI Express. В обзоре NVM Express описаны многочисленные очереди и более короткий программный путь команды по сравнению со старыми протоколами хранения. Этот запас особенно полезен при высокой параллельности, но учетная база на 100 пользователей редко держит десятки тысяч запросов в очереди. Поэтому сравнивать нужно при глубине очереди 1, 2, 4 и 8. Результат производителя при QD32 или QD128 отвечает на другой вопрос.

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

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

По моему опыту, пользователи лучше замечают исчезновение редких пауз, чем сокращение среднего открытия формы с 0,8 до 0,6 секунды. Поэтому у NVMe надо искать меньшее среднее значение и более узкий разброс под смешанной нагрузкой. Серверный накопитель, который стабильно отвечает, полезнее клиентской модели с высоким пиком и резкими провалами после заполнения кеша.

Сравнивать нужно NVMe SSD с SAS SSD, а не с интерфейсом

NVMe и SAS обозначают протоколы, а не тип памяти, поэтому фраза «NVMe против SAS» без модели накопителя неполна. Под SAS могут скрываться механические диски на 10 или 15 тысяч оборотов, серверные SSD и целая внешняя полка с кеширующим контроллером. Под NVMe встречаются клиентские M.2 без защиты от потери питания и серверные U.2, U.3 или EDSFF с телеметрией и ресурсом для постоянной нагрузки.

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

У SAS есть качества, которые не видны в тесте одной базы. Двухпортовые диски позволяют строить путь к накопителю через два контроллера или два узла. Зрелые RAID-контроллеры, корзины и процедуры горячей замены хорошо знакомы администраторам. Это веская причина сохранить SAS в отказоустойчивом кластере или существующей полке, если ее задержка уже укладывается в требования.

У прямого NVMe-подключения другая архитектура. Накопитель занимает линии PCIe, а программный RAID или встроенные средства платформы выполняют работу, которую в SAS-конфигурации часто берет отдельный контроллер. Сервер должен уметь разводить нужное число линий, загружаться с выбранной схемы, показывать состояние дисков через BMC и корректно обслуживать горячую замену. Наличие четырех посадочных мест еще не гарантирует четыре независимых подключения с полной полосой.

Паспортные данные полезны только для проверки класса устройства. Например, спецификация серверного Samsung PM9A3 указывает PCIe 4.0 x4, защиту от потери питания, ресурс 1 DWPD на пять лет для U.2 и разную производительность у разных емкостей. Это не обещание скорости вашей базы, но хороший пример параметров, которых нет в описании обычного клиентского SSD. У SAS SSD надо искать тот же набор: ресурс, устойчивую случайную запись, защиту кеша, формат сектора, два порта при необходимости и совместимость с контроллером.

Средняя задержка скрывает паузы, которые видит бухгалтер

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

Для SQL Server Microsoft предлагает смотреть задержку через sys.dm_io_virtual_file_stats и ожидания PAGEIOLATCH_*, WRITELOG, IO_COMPLETION. В руководстве Microsoft постоянные значения выше примерно 10-15 мс названы признаком проблемы, а не целевым уровнем для нового SSD. Это важная оговорка. Порог помогает искать неисправность в разнородных системах, но закупать современное локальное твердотельное хранилище с плановой задержкой около этого порога я бы не стал.

Разделяйте файлы по характеру операций. Файлы данных дают случайное чтение и запись страниц. Журнал транзакций чувствителен к последовательной синхронной записи и гарантии попадания данных на устойчивый носитель. Временная база получает сортировки, хеши и промежуточные результаты. Резервные копии создают большие последовательные потоки. Одна усредненная цифра по тому D:, где все лежит вместе, не объяснит, какой путь задерживает проведение.

Фраза «разнести файлы» тоже требует точности. Два логических тома на одном наборе дисков помогают управлять местом и наблюдением, но не создают две независимые очереди к носителям. Отдельный том журнала полезен, если за ним стоит отдельный отказоустойчивый ресурс или если схема контроллера дает ему предсказуемую полосу и задержку. На небольшом сервере один быстрый массив RAID 10 иногда работает лучше двух слабых массивов, где журнал получил всего пару медленных дисков.

То же относится к tempdb или временной области другой СУБД. Вынос на быстрый NVMe помогает, когда измерения показывают физическую запись сортировок и хешей. Если ожидание вызвано конкуренцией за внутренние структуры СУБД, отдельный диск не устранит причину. Сначала сопоставьте ожидания с байтами на конкретном файле, затем меняйте размещение.

Проверяйте минимум четыре числа: среднюю задержку чтения, среднюю задержку записи, p95 и p99. Добавьте IOPS и МБ/с, но не заменяйте ими время ответа. Затем повторите замер при рабочем заполнении накопителя и после продолжительной записи. Некоторые SSD быстро принимают данные в свободный внутренний кеш, а после его исчерпания отвечают заметно медленнее. База работает годами, а не первые пять минут после распаковки диска.

Контролируйте глубину очереди. Большая очередь помогает накопителю показать максимум IOPS, но одновременно означает, что запросы уже ждут. Для интерактивной системы хороший результат при QD1-QD4 часто полезнее рекорда при QD128. Тест с большой глубиной нужен отдельно: он показывает запас на обслуживание пика, перестроение массива и фоновые задачи.

Ресурс записи считают по журналу и служебным операциям

Ресурс накопителя нужно считать по фактической записи на устройство, а не по приросту размера базы. База может вырасти на 20 ГБ, но за тот же день несколько раз переписать страницы, журнал, временные файлы и служебные структуры. RAID, сборка мусора SSD и выравнивание записи тоже меняют физический объем. Поэтому прогноз по одному размеру информационной базы обычно занижен.

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

допустимая запись в сутки = емкость накопителя × DWPD

Для SSD на 3,84 ТБ с рейтингом 1 DWPD это 3,84 ТБ записи в сутки в пределах указанного производителем срока и профиля нагрузки. Рейтинг 0,3 DWPD для той же емкости дает около 1,15 ТБ в сутки. Это не команда заполнять диск до предела. Нужен запас на пики, перестроение, изменение нагрузки и тот факт, что условия рейтинга производителя могут отличаться от вашего шаблона записи.

Соберите счетчики записи минимум за полный рабочий цикл, в который входит закрытие месяца. В Windows можно сопоставить байты записи тома со статистикой СУБД и SMART-телеметрией накопителя. В Linux полезны счетчики блочного устройства и поле Data Units Written в журнале NVMe. Смотрите дельту, а не значение с момента выпуска диска. Отдельно запишите объем резервного копирования, перестроения индексов и антивирусного сканирования, если оно затрагивает путь базы.

Покупать накопитель только по наибольшему DWPD тоже ошибочно. Учетная система с умеренной записью и большим активным набором данных может годами работать на read-intensive серверном SSD. Деньги разумнее направить в резервирование, оперативную память или второй узел. Но клиентский SSD без ясного рейтинга, защиты питания и предсказуемого поведения после заполнения я не ставлю под журнал транзакций, даже если расчет TBW формально сходится.

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

Контроллер и защита записи важнее пиковых IOPS

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

Руководство Microsoft по вводу-выводу SQL Server требует гарантированной доставки на устойчивый носитель, правильного порядка записей и стабильности кеша. Документ отдельно предупреждает о кешировании без защиты. Я согласен с жесткостью этого требования: ИБП полезен, но он не заменяет защиту от отказа блока питания, контроллера, прошивки или самого сервера между подтверждением и физической записью.

В SAS-схеме проверьте модель RAID-контроллера, версию прошивки, состояние батареи или суперконденсатора, политику write-back при отказе защиты и поддержку выбранных дисков. Хороший контроллер автоматически переводит кеш в безопасный режим, если модуль защиты неисправен. Это снижает скорость, зато не превращает сбой батареи в скрытый риск данных.

В NVMe-схеме отдельного аппаратного RAID-контроллера может не быть. Тогда нужны серверные накопители с power-loss protection, корректная поддержка команд сброса, подходящий программный RAID или зеркалирование средствами ОС и наблюдение за каждым диском. Аппаратный RAID для NVMe существует, но он добавляет стоимость, собственную задержку и еще одну таблицу совместимости. Не покупайте его по инерции: сначала определите, какую функцию он должен дать, которую платформа не дает иначе.

RAID 10 обычно понятен для транзакционной базы: зеркало переживает отказ диска, а чередование распределяет нагрузку. RAID 5 или RAID 6 экономит емкость, но запись проходит операцию с четностью, а восстановление большого SSD создает длительную смешанную нагрузку. Универсального запрета на RAID 5 нет, однако для активной базы на четырех накопителях я предпочитаю объяснимую производительность RAID 10, если бюджет допускает половину полезной емкости.

Зеркало из двух NVMe часто достаточно по производительности для базы такого масштаба, но оно не дает запаса емкости четырехдискового RAID 10 и обслуживает чтение иначе в разных реализациях. Проверьте, с какого диска читает выбранный программный или аппаратный массив, как он сообщает отказ и как долго перестраивается на реально заполненной емкости. Скорость пустого зеркала не отвечает на эти вопросы.

Путь отказа надо пройти до закупки. Отключите один накопитель на тестовом стенде штатным способом, убедитесь, что СУБД продолжает работу, система мониторинга подает понятную тревогу, а администратор может сопоставить логический номер с физическим отсеком. После замены проверьте p99 во время перестроения и состояние данных средствами СУБД. Красный индикатор без адресного уведомления бесполезен ночью, а неверная маркировка корзины превращает замену одного диска в отказ всего массива.

Отказоустойчивость массива не заменяет резервную копию. Ошибка оператора, повреждение на уровне СУБД и шифровальщик могут затронуть все зеркала. Нужны отдельные проверенные копии и регулярное тестовое восстановление. Тип интерфейса накопителя эту обязанность не меняет.

NVMe требует спланировать линии PCIe и поток воздуха

Сервер с NVMe нужно проектировать целиком, потому что накопителю требуются линии PCIe, совместимая корзина, питание, охлаждение и управление. Переходник, который физически принимает U.2 или M.2, не создает недостающие линии и не добавляет горячую замену. Особенно часто это выясняется после покупки второго процессора, без которого часть слотов на плате не работает.

Составьте карту подключения: какой процессор обслуживает каждый слот, есть ли PCIe-коммутатор, не делят ли накопители полосу с сетевой картой или ускорителем, поддерживает ли плата bifurcation и видит ли BMC состояние диска. Для четырех PCIe 4.0 x4 накопителей нужны соответствующие линии и разводка. Реальная учетная база может не исчерпать их полосу, но ошибка топологии способна отключить диск или увести обмен через межпроцессорное соединение.

Охлаждение нельзя оставлять на потом. Серверный U.2 NVMe под нагрузкой потребляет около десятка и более ватт в небольшом корпусе. В спецификации PM9A3, например, указаны средние активные значения до 13,5 Вт в зависимости от емкости и режима, а рабочая температура ограничена 70 °C. Это не универсальная норма для всех моделей, а указание читать тепловой раздел конкретной спецификации и проверять температуру в своей корзине.

Тепловое дросселирование выглядит как странный провал производительности: первые минуты тест быстрый, затем задержка растет без явной ошибки. Снимайте температуру и флаги throttling одновременно с p99, прогоняйте запись достаточно долго и проверяйте худший летний режим серверной. Два свободных отсека рядом не гарантируют обдув, если воздушный канал корпуса рассчитан на другую корзину.

У SAS тоже есть требования к температуре, но экосистема 2,5-дюймовых корзин обычно предсказуемее для старых серверов. Зато дополнительный RAID-контроллер сам выделяет тепло и нуждается в обдуве. При расчете питания и охлаждения складывайте накопители, контроллер, процессоры, память и сетевые адаптеры, а не рассматривайте диски отдельно.

Цена за терабайт включает полезную емкость и запас

Сравнивать цену одного накопителя неправильно: считать нужно стоимость готового отказоустойчивого контура на полезный терабайт. В нее входят диски, корзина, контроллер или PCIe-коммутатор, лицензии на функции контроллера, кабели, второй узел при необходимости, запасной диск, поддержка и электроэнергия. Для RAID 10 четыре накопителя по 3,84 ТБ дают около 7,68 ТБ сырой полезной емкости до учета формата, резерва файловой системы и свободного места SSD.

Оставлять свободное место нужно не для красоты. База растет, операции обслуживания требуют временного пространства, а SSD устойчивее держит запись при наличии внутреннего резерва и незанятой емкости. Я закладываю отдельно прогноз роста, место для временных операций и эксплуатационный запас. Процент зависит от базы и регламента, поэтому фиксированное «всегда оставляйте 30 процентов» менее полезно, чем расчет по наблюдаемому росту и крупнейшей операции обслуживания.

Формула для сравнения конфигураций выглядит так:

стоимость полезного ТБ = полная стоимость контура / емкость, доступная базе после RAID и резерва

Добавьте цену простоя. Более дешевый массив, для которого нет запасного диска и знакомого специалиста, может оказаться дороже при первом отказе. С другой стороны, переплата за четыре высокоресурсных NVMe не оправдана, если база занимает 400 ГБ, почти вся помещается в память, а запись не достигает и малой доли их ресурса.

SAS часто выигрывает в уже купленной инфраструктуре: совместимая полка, контроллер и запасные диски существуют, персонал знает процедуру замены. NVMe часто выигрывает в новом сервере: меньше посредников в пути, выше плотность производительности и ниже задержка. Сравнение должно проходить на одинаковом уровне резервирования и поддержки. Один NVMe против четырех SAS в RAID 10 дает эффектную, но бесполезную таблицу.

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

Сравните срок поддержки компонентов. Накопитель, контроллер, корзина, прошивка и операционная система должны существовать в одной матрице совместимости. Дешевый диск из розницы может потребовать ручного обновления, не передавать телеметрию через BMC или постоянно включать вентиляторы на максимальную скорость из-за неизвестного датчика. Цена закупки при этом остается низкой, а эксплуатационная стоимость растет.

Тест должен повторять рабочую очередь, а не рекламу диска

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

Для Windows утилита DiskSpd от Microsoft позволяет задать размер блока, долю записи, случайный доступ, число потоков, глубину очереди и сбор процентилей. Следующая команда создает тестовый файл 20 ГБ, выполняет случайные операции блоками 8 КБ, пишет 30 процентов запросов, использует четыре потока с глубиной 2 на поток, прогревается 30 секунд и измеряет 120 секунд:

diskspd.exe -c20G -b8K -r -w30 -t4 -o2 -W30 -d120 -Sh -L D:\io-test.dat

Запускайте ее только на пустом тестовом томе: параметр создает и изменяет файл. В результате ищите таблицы total, read и write с IOPS, MiB/s и средней задержкой, затем раздел Percentile с p95 и p99. Повторите тест при -o1, -o4 и -o8, а для журнала сделайте отдельный последовательный тест записи 8 КБ с одним потоком и глубиной 1. Не смешивайте эти результаты в одно среднее.

Затем снимите задержку файлов самой базы. Для SQL Server подойдет запрос:

SELECT
    DB_NAME(vfs.database_id) AS database_name,
    mf.type_desc,
    mf.physical_name,
    vfs.num_of_reads,
    CASE WHEN vfs.num_of_reads = 0 THEN 0
         ELSE vfs.io_stall_read_ms / vfs.num_of_reads END AS read_ms,
    vfs.num_of_writes,
    CASE WHEN vfs.num_of_writes = 0 THEN 0
         ELSE vfs.io_stall_write_ms / vfs.num_of_writes END AS write_ms
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS vfs
JOIN sys.master_files AS mf
  ON vfs.database_id = mf.database_id
 AND vfs.file_id = mf.file_id;

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

Не переносите результат между разными схемами защиты. Тест одного чистого NVMe не описывает пару в зеркале, а тест SAS SSD с включенным защищенным write-back не описывает контроллер с разряженной батареей и отключенным кешем. Финальный прогон должен использовать те же прошивки, RAID, политику кеша, заполнение и охлаждение, с которыми сервер пойдет в эксплуатацию.

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

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

Выбор сводится к трем проверяемым сценариям

Для нового локального сервера учетной системы на 100 пользователей разумная исходная конфигурация состоит из серверных NVMe с защитой от потери питания, зеркалирования и отдельного проверенного резервного копирования. Она дает низкую задержку, хороший запас на пики и не требует большого числа дисков ради IOPS. Емкость, DWPD и число накопителей выбирают по измерениям, а не по числу пользователей.

SAS SSD стоит выбрать, если сервер или отказоустойчивый контур уже построен вокруг совместимой двухпортовой полки, нужен доступ с двух контроллеров, а замеры подтверждают приемлемые p95 и p99. Менять исправную схему только ради названия NVMe нет смысла. При обновлении сравните стоимость всего контура и убедитесь, что SAS-контроллер не ограничивает новые SSD.

SAS HDD можно оставить для резервных копий, архивов и редко читаемых данных. Для активных файлов транзакционной базы это выбор только при очень спокойной нагрузке и подтвержденной задержке. Экономия на терабайте быстро исчезает, когда закрытие месяца ставит случайные запросы в очередь.

Короткая матрица решения помогает остановить спор о любимом интерфейсе:

• Для нового одиночного сервера или пары узлов берите серверные NVMe с защитой питания, если тест подтверждает p99 при малой очереди, работу зеркала и нормальную температуру.
• Для существующей двухконтроллерной SAS-полки берите совместимые SAS SSD, если замер подтверждает задержку через оба пути и приемлемый режим при отказе контроллера.
• Для дешевой большой емкости под архив оставляйте SAS HDD или другой емкий уровень, если он укладывается в окно копирования, восстановления и проверки.
• Если база почти целиком находится в памяти, а диск не ограничивает проблемную операцию, сохраняйте текущую схему до появления иных измерений.

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

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

Решение о покупке должно помещаться в короткий протокол: текущие p95 и p99, объем и доля записи, активный набор данных, требуемая полезная емкость, схема отказоустойчивости, гарантия устойчивой записи, карта PCIe или SAS и температура под продолжительной нагрузкой. Если поставщик не может заполнить эти строки, цифра IOPS на первой странице спецификации не спасет проект.