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

Например, редко кто всерьёз оценивает, как быстро в конкретной компании растёт объём данных. Все ориентируются на «в среднем по рынку», и это первая серьезная ошибка. Два года назад на одном проекте объём хранимых данных удвоился за семь месяцев, хотя изначально планировалось, что это займёт не меньше трёх лет. Система не выдержала, и всё пришлось перестраивать почти с нуля.

Немало трудностей возникает и тогда, когда выбирается не та архитектура. Чаще всего это касается вот такой СХД NAS: кто-то пытается экономить и ставит дешёвое решение, не проверив, подходит ли оно под конкретную нагрузку или нет. А кто-то, наоборот, берёт избыточную конфигурацию, переплачивает, а потом не использует и половины возможностей данной системы. Похожая история — и с пропускной способностью. Люди покупают быстрые накопители, но забывают проверить, насколько хорошо работает сеть, к которой всё это подключено. И получается, что данные просто застревают на уровне коммутаторов. А ведь казалось бы — ничего сложного, просто подключи и пользуйся.

Ещё один момент, который часто упускают, — это человеческий фактор. Да, сама по себе система СХД может быть надёжной, мощной и даже с запасом по производительности, но если те, кто с ней работает каждый день, не до конца понимают, как всё устроено, рано или поздно они допустят ошибку. Не со зла, а просто по незнанию. И проблема не всегда в недостатке навыков — иногда всё упирается в то, что администратору никто толком не объяснил, как работает конкретная настройка, и он делает так, как привык, не подозревая, что в этой системе всё по-другому.

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