В инфраструктуре почти каждой компании наступает момент, когда дисков в сервере вроде бы еще хватает, но спокойствия уже нет. Базы данных растут, виртуальных машин становится больше, резервные копии начинают жить собственной жизнью, а файловая шара постепенно превращается в общий склад всего подряд. На этом этапе обычно и появляется вопрос: пора ли выносить хранение данных в отдельную систему?
Для многих компаний логичным вариантом становится корпоративная СХД: не обязательно огромная и сверхдорогая, но рассчитанная на круглосуточную работу, отказоустойчивость и нормальное управление данными. Например, если смотреть в сторону готовых enterprise-решений, можно изучить класс систем хранения Dell Unity: https://servermall.ru/sets/skhd-dell-unity/. Но важнее не конкретная модель, а понимание, зачем вообще нужна СХД и какие ошибки чаще всего совершают при ее выборе.
Почему просто «добавить дисков в сервер» не всегда помогает
Самый простой путь при нехватке места — докупить диски. Иногда это действительно нормально. Если сервер используется как файловое хранилище для небольшого офиса, нагрузка предсказуемая, простоев не боятся, а восстановление из бэкапа занимает приемлемое время, отдельная СХД может быть избыточной.
Проблемы начинаются, когда на одном сервере одновременно живут виртуализация, 1С или другая учетная система, файловые ресурсы, резервные копии и несколько сервисов, которым нужен стабильный доступ к данным. В такой ситуации дисковая подсистема становится не просто местом хранения, а узким горлышком всей инфраструктуры.
Главный симптом — не только нехватка терабайт. Гораздо важнее задержки, IOPS, поведение под смешанной нагрузкой и то, что происходит при отказе диска, контроллера или самого сервера. Можно иметь много свободного места и при этом получать тормоза в базе данных, долгий запуск виртуальных машин и неприятные пики нагрузки во время бэкапов.
Что дает отдельная СХД
Система хранения данных отделяет вычисления от хранения. Серверы занимаются процессорами, памятью и виртуальными машинами, а СХД — дисками, томами, кэшем, RAID, снапшотами, репликацией и доступностью данных.
На практике это дает несколько преимуществ.
Во-первых, проще масштабировать инфраструктуру. Если нужно больше вычислений — добавляем сервер. Если нужно больше места или производительности хранения — расширяем СХД или меняем профиль дисков.
Во-вторых, появляется нормальная отказоустойчивость. У корпоративной СХД обычно есть два контроллера, резервные блоки питания, горячая замена дисков, несколько сетевых или FC-путей до серверов. Один отказ не должен превращаться в остановку всей компании.
В-третьих, становится удобнее обслуживать виртуализацию. Несколько гипервизоров могут работать с общим пулом хранения, а виртуальные машины — мигрировать между хостами без привязки к локальным дискам конкретного сервера.
SAN, NAS или unified storage?
Тут часто возникает путаница. NAS отдает файлы по SMB или NFS. SAN предоставляет блочные устройства по iSCSI или Fibre Channel. Unified storage умеет и то, и другое: файловый и блочный доступ в одной системе.
Для небольшого офиса NAS может быть достаточен: общие папки, архивы, бэкапы, документы. Для виртуализации, баз данных и кластеров чаще нужен блочный доступ. А если в компании одновременно есть файловые ресурсы, VMware/Hyper-V и базы данных, unified storage выглядит практично: одна система закрывает несколько сценариев.
Но не стоит выбирать тип СХД по красивому описанию. Надо начинать с нагрузки: сколько виртуальных машин, какие базы, сколько пользователей, какой профиль чтения и записи, сколько данных меняется за день, какое допустимое время простоя и восстановления.
Терабайты — не главный параметр
Классическая ошибка — выбирать СХД по объему. «Нам нужно 50 ТБ, значит берем систему на 50 ТБ». На бумаге выглядит логично, но в реальной эксплуатации важнее другое.
Нужно учитывать рабочую емкость после RAID, hot spare, служебных данных, снапшотов и резерва на рост. Нужно понимать, какие диски будут использоваться: HDD, SSD или гибридный пул. Нужно оценивать не только максимальную производительность, а стабильность под реальной смешанной нагрузкой.
Например, файловый архив и база данных ведут себя совершенно по-разному. Архиву важны емкость и последовательное чтение. Базе данных важны задержки, случайные операции и предсказуемость. Виртуализация добавляет еще один слой: десятки виртуальных машин могут одновременно генерировать мелкие случайные операции, и именно они часто «убивают» неправильно собранную дисковую подсистему.
О чем спросить до покупки
Перед выбором СХД полезно ответить на несколько простых, но неприятных вопросов.
- Что именно будет храниться на системе?
- Сколько данных уже есть и как быстро они растут?
- Какие сервисы критичны для бизнеса?
- Сколько времени компания готова быть без доступа к данным?
- Есть ли резервная площадка?
- Кто будет администрировать СХД после внедрения?
- Что произойдет, если через год нагрузка вырастет в два раза?
Если на эти вопросы нет ответов, легко купить либо слишком слабую систему, либо слишком дорогую. В первом случае инфраструктура упрется в производительность почти сразу. Во втором — часть возможностей останется невостребованной, а бюджет можно было потратить на резервное копирование, сетевое оборудование или второй узел.
Важность сети и путей доступа
СХД не работает в вакууме. Между ней и серверами всегда есть сеть: Ethernet для iSCSI/NFS/SMB или Fibre Channel для классического SAN. И если эта часть спроектирована плохо, даже хорошая СХД не покажет нормальный результат.
Нужны резервные пути, разнесение по коммутаторам, корректная настройка multipath, достаточная пропускная способность и понимание, какие нагрузки идут по каким интерфейсам. Особенно это важно для виртуализации: когда несколько хостов одновременно обращаются к одному хранилищу, экономия на сетевой части быстро превращается в задержки и нестабильность.
СХД не отменяет бэкапы
Еще одно опасное заблуждение: «У нас же СХД с RAID, значит данные защищены». RAID защищает от отказа диска, но не от удаления файлов, ошибки администратора, шифровальщика, повреждения базы или проблем на уровне приложения.
Снапшоты тоже не являются полноценной заменой резервному копированию. Они удобны для быстрого отката, но должны быть частью общей стратегии защиты данных. Нормальная схема включает отдельные бэкапы, проверку восстановления, желательно — копию вне основной площадки.
Когда СХД действительно нужна
Отдельная система хранения оправдана, если в компании есть виртуализация, несколько критичных серверов, растущие базы данных, требования к высокой доступности или необходимость централизованно управлять большими объемами данных. Она особенно полезна, когда локальные диски серверов уже мешают масштабированию, а простой инфраструктуры стоит дороже, чем нормальное хранилище.
Если же речь идет о маленьком офисе с несколькими пользователями и простыми файловыми задачами, начинать можно с более компактного решения. Главное — не путать «нам нужно больше места» и «нам нужна отказоустойчивая платформа хранения». Это разные задачи.
Вывод
СХД стоит выбирать не по количеству терабайт и не по принципу «у конкурентов такая же». Хорошая система хранения — это баланс емкости, производительности, отказоустойчивости, удобства администрирования и возможности роста.
Правильный подход начинается с описания нагрузки и рисков: какие данные критичны, сколько стоит простой, как быстро нужно восстановиться, что будет через два-три года. После этого выбор между NAS, SAN, unified storage, гибридной или all-flash конфигурацией становится гораздо более осознанным.
Серверное оборудование часто обсуждают через процессоры и память, но на практике именно хранение данных определяет, насколько стабильно будет работать инфраструктура. Когда серверу становится тесно, важно не просто добавить дисков, а построить такую архитектуру, в которой данные будут доступны, защищены и управляемы.
