ГК Softline: дешевый гигабайт может сделать облако дороже

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

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

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

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

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

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

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

Архитектура должна соответствовать нагрузке

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

Объектное хранилище размещает данные вместе с метаданными и уникальными идентификаторами, не используя привычную иерархию папок. Такой подход подходит для больших объемов неструктурированных данных: медиафайлов, логов, резервных копий, архивов и отдельных фрагментов кода. Распространенный пример этой архитектуры — S3-совместимое хранилище.

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

Файловое хранилище работает с привычной структурой каталогов и предоставляет доступ по файловым протоколам NFS, CIFS или SMB. Его применяют для общих сетевых папок, совместной работы с документами и некоторых сценариев резервного копирования.

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

Модель развертывания зависит от требований к контролю

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

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

Гибридная модель сочетает обе среды. Критичные системы и данные с жесткими требованиями к доступу могут оставаться в частной инфраструктуре, а резервные копии, архивы и быстро растущие массивы размещаться в публичном облаке. На практике такая схема позволяет распределять нагрузку и расходы, однако требует единых правил доступа, учета и контроля перемещения данных.

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

Температура данных определяет экономику хранения

«Горячее» хранилище рассчитано на частые операции чтения и записи. Оно обеспечивает быстрый доступ, но обычно стоит дороже, поэтому его целесообразно использовать для данных, которые постоянно участвуют в работе приложений и сотрудников.

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

«Ледяное» хранилище используют для архивов, которые требуется сохранять длительное время, но почти не приходится читать. Низкая стоимость размещения компенсируется более медленным и дорогим извлечением. Если архив начинают регулярно использовать, первоначально выгодная модель быстро теряет экономический смысл.

Опыт Softline показывает, что температурный класс нельзя назначать данным один раз и навсегда. Характер использования меняется: проект завершается, рабочие материалы переходят в архив, а старые данные неожиданно становятся нужны для проверки или расследования. Политику размещения следует пересматривать с учетом фактической частоты обращений и накопленных расходов.

Выбор начинается с последствий недоступности

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

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

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

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

У корпоративных данных должен быть владелец

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

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

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