При аренде физического сервера процессор и оперативная память обычно получают больше внимания, чем диски. В таблице тарифов первым делом сравнивают количество ядер, частоту CPU и гигабайты RAM, а строку с накопителями воспринимают почти как указание доступного места. Для реального сайта дисковая подсистема может оказаться не менее важной. Именно на ней находятся файлы, база данных, журналы, кэш и временные данные, а интернет-магазин или другой динамический проект постоянно что-то читает и записывает.
Особенность физического сервера в том, что здесь клиент часто получает значительно больше свободы, чем на обычном хостинге или VPS. Можно выбрать количество накопителей, их тип, объём и способ объединения. Два одинаковых сервера с одинаковым процессором и памятью способны заметно отличаться по поведению только потому, что диски организованы по-разному.
Поэтому вопрос лучше ставить не так: какой накопитель самый быстрый. Важнее понять, что будет храниться на сервере, насколько интенсивно приложение работает с данными и что должно произойти, если один из дисков внезапно выйдет из строя.
Какие диски нужны физическому серверу
Начнём с самого понятного различия. HDD используют магнитные пластины и механические головки. Такие накопители предлагают большой объём за относительно небольшие деньги, поэтому они до сих пор применяются там, где нужно хранить много данных и максимальная скорость доступа не является главным требованием. Это могут быть архивы, резервные данные, медиафайлы и другие объёмные хранилища.
Для современного динамического сайта системный HDD в качестве основного рабочего диска обычно выглядит менее привлекательно. База данных выполняет множество небольших операций, веб-приложение обращается к файлам, система постоянно пишет журналы. В таких задачах задержки механического накопителя становятся заметнее, чем при простом последовательном чтении большого файла.
SSD не имеет движущихся механических частей и значительно быстрее работает со случайным доступом. Даже обычный серверный SATA SSD для многих сайтов будет гораздо подходящим рабочим накопителем, чем HDD.
Следующий уровень — NVMe. Такие накопители работают через PCI Express и используют протокол, рассчитанный на современную флеш-память. Они способны обрабатывать большое количество операций с низкими задержками и особенно полезны там, где дисковая подсистема действительно становится частью ограничения производительности.
Но на физическом сервере действует то же правило, что и на любом другом хостинге: надпись NVMe не превращает медленное приложение в быстрое. Плохо написанный запрос к базе данных, который перебирает огромное количество строк, останется плохим запросом. Просто быстрый накопитель выполнит ненужную работу быстрее.
NVMe нужен не каждому сайту
Для интернет-магазина с большой базой данных, высоконагруженного проекта, сервиса с большим количеством запросов или системы, активно работающей с небольшими файлами, быстрый NVMe может дать реальную пользу. Особенно если приложение уже оптимизировано и именно скорость операций ввода и вывода действительно влияет на время ответа.
Для нескольких небольших корпоративных сайтов разница между хорошим серверным SATA SSD и дорогим NVMe может почти не ощущаться посетителями. В такой ситуации разумнее оценить всю конфигурацию целиком, а не переплачивать только за максимальные показатели накопителя.
Нужно смотреть и на класс самого диска. Серверный накопитель рассчитан на круглосуточную работу и определённый объём записи. У SSD существует ограниченный ресурс ячеек памяти, поэтому для базы с очень интенсивной записью характеристики долговечности могут быть важнее красивой пиковой скорости из спецификации.
Особенно внимательно стоит относиться к предложениям, где указано только SSD или NVMe без дополнительных сведений. Для обычного сайта подробная модель накопителя может быть не нужна, но при выборе серьёзного физического сервера вполне разумно узнать, используются ли серверные диски и как провайдер организует их замену в случае отказа.
Не менее важен объём. Если сайту сейчас требуется 300 ГБ, покупать два диска ровно по 300 ГБ и рассчитывать использовать каждый гигабайт не стоит. Свободное пространство требуется операционной системе, журналам, временным файлам, обновлениям и росту базы. Некоторые файловые системы и приложения также начинают вести себя хуже, когда диск заполнен почти полностью.
Нормальный запас зависит от проекта, но сама идея проста: рабочий сервер не должен постоянно жить в состоянии 95-99 процентов заполнения.
Почему два диска могут быть полезнее одного большого
Представим два варианта. В первом сервер оснащён одним NVMe на 2 ТБ. Во втором установлены два NVMe по 1 ТБ. Если смотреть только на суммарную ёмкость, варианты кажутся одинаковыми. Но два накопителя позволяют построить зеркальную схему, при которой данные существуют сразу на обоих дисках.
Именно здесь появляется RAID.
RAID объединяет несколько физических накопителей в определённую логическую схему. В зависимости от уровня массива он может использоваться для отказоустойчивости, производительности или сочетания этих задач.
Для обычного веб-сервера один из самых понятных вариантов — RAID 1. Данные записываются одновременно на два диска. Для системы они могут выглядеть как единое хранилище, но информация дублируется.
Если установлен RAID 1 из двух накопителей по 1 ТБ, доступный полезный объём будет около 1 ТБ, а не 2 ТБ. Второй диск фактически используется для зеркальной копии данных первого.
Цена такой схемы очевидна: половина суммарной ёмкости расходуется на дублирование. Зато отказ одного накопителя не обязательно означает немедленную остановку сервера и потерю данных. Массив способен продолжить работу на оставшемся диске, пока неисправный меняют.
Какой RAID выбрать для физического сервера
Для многих серверов с двумя накопителями RAID 1 является понятным базовым вариантом. Он относительно прост и хорошо решает конкретную задачу: пережить отказ одного из двух дисков без мгновенной потери всего массива.
Если накопителей четыре или больше, часто рассматривают RAID 10. В упрощённом виде он объединяет зеркалирование и распределение операций между дисками. Половина общей ёмкости также уходит на отказоустойчивость, но схема может обеспечивать хорошую производительность и удобна для нагруженных баз данных и других серверных задач.
Например, четыре накопителя по 1 ТБ в RAID 10 дадут примерно 2 ТБ полезного пространства. Оставшаяся физическая ёмкость используется для дублирования данных.
Существуют RAID 5, RAID 6 и другие схемы, позволяющие эффективнее использовать суммарный объём массива. Но выбирать уровень исключительно по тому, где меньше теряется гигабайтов, не стоит. Имеют значение количество накопителей, интенсивность записи, время восстановления массива после отказа, размер дисков и требования проекта.
Для обычного владельца сайта важен другой принцип: RAID нужно подбирать под конкретную задачу, а не считать, что более высокий номер автоматически означает более современную и надёжную технологию.
Если физический сервер арендуется у провайдера, полезно уточнить не только слова RAID 1 или RAID 10 в конфигурации, но и кто следит за состоянием массива. Неисправный диск должен быть обнаружен и заменён. RAID, который месяцами работает в деградированном состоянии после отказа накопителя, уже не даёт ожидаемой защиты.
Хороший сценарий выглядит так: система обнаруживает проблему, мониторинг отправляет уведомление, неисправный накопитель меняют, после чего массив восстанавливает необходимую избыточность. Нужно заранее понимать, кто отвечает за эти действия — сам клиент, его администратор или техническая служба провайдера.
Аппаратный или программный RAID
Аппаратный RAID строится с использованием отдельного контроллера, который управляет накопителями. В серверных конфигурациях такие решения используются давно и могут иметь собственный кэш, средства мониторинга и дополнительные функции.
Программный RAID создаётся средствами операционной системы. Современные серверы обладают достаточной вычислительной мощностью, поэтому программный вариант далеко не обязательно означает медленное или ненадёжное решение. Для многих задач он работает вполне эффективно и избавляет инфраструктуру от зависимости от конкретного аппаратного RAID-контроллера.
Поэтому выбирать сервер только по наличию дорогого контроллера не обязательно. Гораздо важнее, чтобы схема хранения была правильно настроена, контролировалась и соответствовала требованиям проекта.
Если провайдер предлагает готовую конфигурацию, стоит узнать, какой RAID фактически используется и что произойдёт после отказа диска. Если массив клиент настраивает самостоятельно, эта ответственность уже ложится на администратора сервера.
RAID не является резервной копией
Это самое важное правило всей темы. RAID защищает прежде всего от определённых аппаратных отказов накопителей. Он не создаёт независимую историческую копию данных.
Если администратор случайно удалит базу данных, удаление произойдёт на массиве. Если приложение повредит данные, повреждённая версия будет записана на диски. Если злоумышленник получит доступ и зашифрует файлы, RAID честно сохранит зашифрованные данные. Если сервер будет физически повреждён целиком, наличие зеркала внутри этой же машины тоже может не помочь.
Поэтому правильно настроенные резервные копии сайта должны существовать независимо от RAID и желательно независимо от самого физического сервера.
Это не означает, что RAID бесполезен. Он решает другую задачу. Представим сервер интернет-магазина с двумя накопителями в RAID 1. Ночью один диск выходит из строя. Сайт продолжает работать, администратор получает уведомление, а провайдер меняет неисправный накопитель. Для бизнеса это намного удобнее, чем останавливать проект, устанавливать новый диск и полностью восстанавливать сервер из бэкапа.
А теперь другая ситуация: разработчик случайно удалил важную таблицу базы данных. Оба диска RAID моментально получили одинаковое новое состояние. Здесь уже нужна вчерашняя резервная копия.
RAID и бэкап не конкурируют между собой. Первый помогает пережить некоторые проблемы оборудования, второй позволяет вернуться к предыдущему состоянию данных.
При выборе физического сервера стоит учитывать и расположение резервных копий. Хранить единственный бэкап на другом разделе тех же дисков почти бессмысленно с точки зрения серьёзной аппаратной аварии. Лучше, когда копии уходят на отдельное хранилище или другой сервер.
Для большинства обычных сайтов хорошей отправной точкой может быть довольно простая схема: два серверных SSD или NVMe в RAID 1 плюс внешнее резервное копирование. Для более высокой дисковой нагрузки и серверов с четырьмя накопителями имеет смысл рассмотреть RAID 10. Но это не универсальный рецепт для каждой задачи.
Большим файловым архивам может быть важнее объём, базам данных — задержки и количество операций, а некоторым проектам полезно разделить системные данные и большие хранилища по разным типам накопителей. Один физический сервер вполне может одновременно использовать быстрые NVMe для операционной системы и базы данных и более ёмкие диски для менее чувствительной к скорости информации.
Поэтому выбирать дисковую подсистему нужно от реальной нагрузки. Сколько данных хранится сейчас и насколько быстро они растут? Много ли операций выполняет база? Насколько критичен простой после отказа накопителя? Где находятся резервные копии? Кто заметит неисправность и заменит диск?
Ответы на эти вопросы полезнее, чем стремление купить сервер с самым быстрым NVMe из доступных. Для сайта хороший диск — это не только высокая скорость в характеристиках. Это ещё достаточный ресурс записи, нормальный запас свободного места, подходящая схема отказоустойчивости и понятный план действий при поломке.
Физический сервер как раз хорош тем, что позволяет управлять дисковой подсистемой намного свободнее многих других видов хостинга. Но этой свободой есть смысл пользоваться осознанно. Иногда два более скромных накопителя в правильно выбранном RAID окажутся для коммерческого проекта полезнее одного огромного и очень быстрого диска без какой-либо защиты от его отказа.
