Где должны хранится корпоративные данные
Где хранить данные: почему инфраструктура начинается с бизнес-логики
Вопрос о том, где хранить корпоративные данные, часто начинают с неправильной точки.
- - стоимость серверов;
- - тарифы облака;
- - аренда площадки;
- - объём дисков.
Но вся инфраструктура выбирается вовсе не для того, чтобы где-то просто «лежали файлы». Она должна непрерывно обеспечивать работу бизнеса.
Набор критических требований к доступности корпоративных систем:
- › ERP: должна получать данные тогда, когда они нужны;
- › Производство: не терять информацию при любом сбое;
- › Аналитика: иметь доступ к необходимому объёму истории;
- › Интеграции: обмениваться данными без ручного переноса;
- › Сотрудники: доступ к системам независимо от их локации.
Поэтому вопрос правильнее формулировать иначе:
«Где конкретные корпоративные данные смогут храниться, обрабатываться и восстанавливаться с требуемым уровнем доступности, безопасности и управляемости?»
И ответ на этот вопрос далеко не всегда один и тот же для всей компании.
В компании редко бывает один тип данных
Представим обычную корпоративную информационную среду:
Для каждого обособленного класса данных могут кардинально отличаться:
- › требования к доступности;
- › объём;
- › скорость записи;
- › скорость чтения;
- › срок хранения;
- › требования к резервированию;
- › необходимость интеграции;
- › требования к контролю доступа;
- › допустимость передачи за пределы локального контура;
- › стоимость комплексной обработки.
Поэтому директивное решение «вообще всё разместить в публичном облаке» или «принципиально всё оставить только на своих физических серверах» заранее является слишком грубым и неэффективным.
Облако, локальный контур и гибрид
Условно инфраструктуру управления и хранения корпоративной информации можно разделить на три базовых подхода.
Локальная инфраструктура
Облачная инфраструктура
Гибридная инфраструктура
Но на практике эти варианты вовсе не являются жестко взаимоисключающими.
Например, распределение систем на крупном предприятии может выглядеть так:
- › Основная ERP: находится в локальном контуре;
- › Резервные копии: хранятся на отдельной удаленной площадке;
- › Аналитическая нагрузка: частично вынесена в облако;
- › Документы: размещены в облачном объектном хранилище.
Получается уже не примитивный выбор между «А или Б».
Речь идет о комплексном проектировании единой распределённой среды безопасного хранения и эффективной обработки данных.
Локальная инфраструктура: когда данные остаются внутри компании
В локальном варианте серверы и системы находятся под непосредственным контролем организации.
У компании сохраняется полная возможность самостоятельно контролировать и определять:
- › где физически находится оборудование;
- › кто именно имеет к нему прямой физический доступ;
- › как изолирована и организована локальная сеть;
- › какие корпоративные системы подключены к хранилищу;
- › какие внутренние механизмы резервирования используются;
- › как и в какие регламентные сроки проходит обновление всей инфраструктуры.
Это особенно важно для систем, тесно связанных с внутренним производственным или технологическим контуром предприятия.
Например, предприятие может иметь сквозную локальную шину:
└── Промышленная сеть
└── SCADA / MES
└── Локальные серверы
└── ERP
В таком сценарии размещение абсолютно всех компонентов в публичном облаке может оказаться не лучшим архитектурным решением.
Не потому, что облако само по себе «плохое».
А потому, что сама автоматизируемая система физически и технологически привязана к локальному контуру производства.
Но локальная инфраструктура не означает автоматическую безопасность
Это одна из наиболее распространённых ошибок в планировании ИТ-периметра.
Иногда рассуждают так: «Сервер находится у нас в серверной, значит данные защищены». На самом деле наличие собственного оборудования ничего не гарантирует.
В локальной инфраструктуре точно так же существуют критические угрозы:
- - отказ дисков;
- - повреждение оборудования;
- - ошибки администраторов;
- - вредоносное ПО;
- - удаление данных;
- - проблемы электропитания;
- - пожар;
- - затопление;
- - сбой сети;
- - потеря конфигурации;
- - отсутствие актуальных резервных копий.
Если единственная копия данных физически находится в одном серверном шкафу, это не резервирование.
Это просто одна копия данных.
Резервная копия должна решать другую задачу
Рассмотрим классическую ошибку проектирования топологии бэкапов.
└── Database
└── Backup на том же сервере
На первый взгляд резервная копия действительно есть. Но если физически выходит из строя сам сервер, вместе с ним в ту же секунду становится недоступна и копия. Поэтому архитектура резервирования обязана учитывать закон независимости отказов.
Целевая архитектурная топология безопасного резервного копирования:
Для критически важных бизнес-данных на практике может потребоваться ещё более сложная и распределенная схема.
Главная архитектурная идея проста:
Резервная копия должна оставаться гарантированно доступной именно тогда, когда основная информационная система полностью недоступна.
Облако меняет модель инфраструктуры
В облачном варианте компания не обязана самостоятельно покупать серверы, устанавливать диски и заранее рассчитывать физическую ёмкость.
Можно гибко увеличивать ресурсы по мере непосредственного роста нагрузки, мгновенно создавать дополнительные экземпляры систем, использовать готовые управляемые базы данных (Managed DB) и географически распределённые хранилища.
Но здесь критически важно понимать:
облако ни в коем случае не отменяет архитектуру.
Оно просто переносит часть ответственности за базовый инфраструктурный слой.
В облаке всё равно нужно решать вопрос доступности
Допустим, критичное приложение работает в одном-единственном экземпляре:
└── Database
Если этот изолированный экземпляр по какой-то причине становится недоступен, пользователи мгновенно теряют возможность работать.
Поэтому действительно отказоустойчивая система в облаке должна проектироваться иначе:
А сама база данных и файловое хранилище также требуют отдельного, детально продуманного резервирования на уровне облачных зон доступности.
Получается очень важный инженерный момент:
Просто механически разместить данные в облаке — далеко не то же самое, что архитектурно обеспечить их непрерывную доступность.
Гибридная инфраструктура часто оказывается практичнее
У корпоративных систем редко бывает объективная причина хранить абсолютно всё в одном месте.
Критичные операционные бизнес-системы гарантированно остаются внутри защищенного локального контура предприятия.
А внешняя облачная инфраструктура точечно используется там, где она даёт максимальные архитектурные преимущества:
- › аналитика;
- › хранение больших объёмов данных;
- › резервирование;
- › эластичные дополнительные вычислительные ресурсы;
- › внешние готовые сервисы;
- › быстро масштабируемые приложения.
Это и есть один из наиболее сбалансированных и распространённых вариантов современной гибридной архитектуры.
Но гибрид сложнее двух отдельных инфраструктур
У гибридной модели есть очевидное преимущество: можно выбирать место размещения для каждого класса данных. Но появляется дополнительная сквозная граница:
Через эту границу непрерывно должны проходить данные. А значит, на ней необходимо проектировать:
- › каналы связи;
- › маршрутизацию;
- › аутентификацию;
- › шифрование;
- › контроль доступа;
- › обработку отказов;
- › повторную отправку;
- › очереди;
- › мониторинг;
- › журналирование.
Если связь между площадками пропала, распределенная система должна четко понимать, что делать с накопленными данными.
Интеграции напрямую влияют на выбор места хранения
Рассмотрим производственное предприятие с классическим сквозным стеком автоматизации:
└── PLC / контроллеры
└── SCADA
└── MES
└── ERP
Если верхнеуровневая ERP полностью вынесена в облако, а весь производственный контур остаётся внутри предприятия, появляется уязвимая интеграционная граница.
И здесь возникает критический вопрос: что должно происходить, если интернет-соединение временно недоступно?
│
▼
Интернет
X связь потеряна
▼
Облачная система
Вся непрерывность производства оказывается в полной критической зависимости от стабильности внешнего интернет-канала провайдера.
└── Локальный контур
└── MES / буфер
└── Интеграция
└── Облако
Теперь локальные процессы цеха могут безопасно продолжаться, даже если передача данных во внешнюю среду временно полностью нарушена.
Не все данные требуют одинаковой скорости доступа
Ещё один важный критерий — частота использования информации корпоративными системами.
Профиль утилизации корпоративных слоёв:
- › Операционные данные: нужны постоянно;
- › Документы текущего года: нужны регулярно;
- › Архив: нужен крайне редко;
- › Исторические данные: используются только аналитикой.
Нет никакой инженерной необходимости дорого хранить абсолютно всё на одном типе максимально быстрого производительного хранилища.
Вместо этого гораздо рациональнее построить иерархические уровни (Data Tiering):
Чем реже используются данные, тем больше появляется естественных возможностей кардинально оптимизировать стоимость их хранения.
Это правило становится особенно критически важным для enterprise-систем, где общий объём информации неуклонно растёт годами.
Большой объём данных — отдельная архитектурная задача
Представим крупное современное предприятие, которое непрерывно получает колоссальный поток телеметрии:
├── × 10 измерений/сек
├── × 24 часа
└── × 365 дней
Даже без выполнения сложных математических расчётов понятно, что итоговый объём будет расти по экспоненте. Через несколько лет перед инженерами встанет совсем не тривиальный вопрос расширения физического дискового пространства.
Главный вопрос меняет фокус:
«Как организовать сквозной, автоматизированный жизненный цикл этих данных?»
Пример классического конвейера перемещения данных во времени:
И здесь стратегический выбор базовой инфраструктуры напрямую и неразрывно связан уже не только с физическим местом хранения, но и со сквозной архитектурой самих данных.
Доступ важнее физического расположения
Можно хранить данные внутри компании и при этом предоставить к ним слишком широкий доступ. И наоборот — данные могут находиться в облачной инфраструктуре, но доступ к ним будет строго ограничен.
Поэтому необходимо строго разделять два совершенно разных понятия:
2. Кто и при каких условиях может их получить?
Пример разграничения прав на различных слоях хранения информации:
Каждому потребителю нужен именно тот минимально достаточный уровень доступа, который необходим для непосредственного выполнения работы.
Особенно важно разделять хранение и обработку
Иногда данные не обязательно перемещать туда, где выполняется вся обработка.
В облако может контролируемо передаваться только необходимая для аналитики информация. Это позволяет не переносить целиком всю операционную систему и одновременно эффективно использовать внешние эластичные вычислительные ресурсы.
Такой архитектурный подход особенно полезен, когда:
- › операционные данные обязательно должны оставаться внутри защищенного контура;
- › аналитика требует колоссальных аппаратных ресурсов;
- › общий объём накапливаемой исторической информации постоянно растёт;
- › бизнесу критически необходимы внешние специализированные аналитические инструменты.
Стоимость хранения — это далеко не вся стоимость инфраструктуры
Ошибка возникает, когда сравнивают исключительно базовые ценники «в лоб» и выбирают меньшую цифру.
На самом деле совокупная стоимость владения (TCO) инфраструктурой включает гораздо больше скрытых слоёв:
У облачной инфраструктуры часть этих затрат выглядит иначе, но они никогда полностью не исчезают как фундаментальная архитектурная задача.
Поэтому корректно сравнивать нужно не цену физического сервера и цену облачного ресурса, а совокупную стоимость требуемого уровня эксплуатации.
Важен не только объём данных, но и скорость их роста
Статичный взгляд на объемы — частая причина инфраструктурных кризисов. Нагрузку создает именно динамика.
Если архитектура рассчитана только на сегодняшние 10 TB, через некоторое время неизбежно придётся заниматься расширением инфраструктуры в аварийном режиме под давлением бизнеса.
Поэтому при выборе и проектировании целевого хранилища необходимо комплексно оценивать:
Именно последний пункт чаще всего полностью забывают на этапе бюджетирования.
Если основные рабочие данные занимают 50 TB, резервная инфраструктура (DR) в обязательном порядке должна иметь точно такую же достаточную ёмкость.
Что происходит при отказе?
Это один из самых полезных вопросов при проектировании.
«Где будут лежать данные?»
А:
«Что произойдёт с системой, если это место станет недоступно?»
Например:
В зависимости от критичности системы может потребоваться:
├──► Реплика
└──► Backup
└── Другая площадка
А для критичных систем ещё и сценарий переключения:
│
X
│
▼
Failover
│
▼
Secondary
Но наличие второй площадки само по себе ничего не гарантирует.
Её необходимо регулярно проверять.
Резервирование без проверки — это предположение
Можно иметь:
в отчёте мониторинга. И всё равно не суметь восстановить систему.
Причины могут быть совершенно практическими:
- - резервная копия повреждена;
- - отсутствует часть данных;
- - потеряны ключи;
- - не сохранилась конфигурация;
- - неизвестна последовательность восстановления;
- - восстановление занимает слишком много времени;
- - никто не проверял процедуру после изменения архитектуры.
Поэтому зрелая инфраструктура должна проверять не только факт создания копии, но и возможность восстановления из неё.
Для разных систем допустимый простой разный
CRM может некоторое время быть недоступной. Производственная система может не иметь такой возможности.
может быть приемлемым для условной системы.
И это требование радикально меняет всю архитектуру.
То же самое касается потери данных.
Если допустимо потерять последние несколько минут, можно строить одну архитектуру.
Если потеря даже одной операции недопустима, требования будут совершенно другими.
Поэтому место хранения данных должно определяться вместе с требованиями RTO и RPO, а не отдельно от них.
Как выбирать место хранения для конкретной системы
Практически полезно пройти несколько вопросов.
Что это за данные?
Операционные, финансовые, производственные, персональные, архивные, аналитические?
Как часто они используются?
Каждую секунду, several раз в день или раз в год?
Какой объём и скорость роста?
Важно понимать не только текущий размер, но и прогноз.
Кто и откуда должен получать доступ?
Внутренняя сеть, филиалы, удалённые сотрудники, внешние системы?
Что произойдёт при потере связи?
Особенно важно для производства и распределённых организаций.
What happens on storage failure?
Есть ли резервная копия? Реплика? Другая площадка?
Сколько времени система может быть недоступна?
От этого зависит архитектура восстановления.
Можно ли передавать данные за пределы локального контура?
Это определяется требованиями конкретной системы, бизнеса и применимых правил.
С какими системами нужно интегрироваться?
Иногда именно интеграции определяют архитектуру сильнее, чем само хранилище.
Как система будет выглядеть через три года?
Инфраструктура должна выдерживать не только сегодняшний объём.
На практике получается не «облако или сервер»
Зрелая корпоративная архитектура может выглядеть примерно так:
Здесь каждый компонент находится там, где это имеет инженерный смысл.
Именно такой подход обычно оказывается устойчивее попытки разместить всю инфраструктуру по одному универсальному принципу.
Главная ошибка — выбирать место хранения раньше архитектуры
Если сначала выбрать категоричную установку, архитектура начинает работать от инфраструктуры, а не от требований бизнеса.
«Всё будет в облаке».
«Никаких облаков, всё только на собственных серверах».
Обе позиции слишком категоричны.
Правильный вопрос другой:
«Какие требования предъявляет конкретная система к данным, доступности, производительности, безопасности, резервированию и интеграциям?»
А уже после этого выбирается подходящее место размещения.
Итог
У корпоративных данных нет универсального «правильного места».
Для одной системы оптимальным решением будет локальная инфраструктура.
Для другой — облачная.
Для третьей — комбинация нескольких сред.
При этом само расположение данных — только один элемент архитектуры.
Необходимо одновременно продумать:
│
├── Где хранятся
├── Как обрабатываются
├── Кто получает доступ
├── Как интегрируются
├── Как резервируются
├── Как восстанавливаются
├── Как масштабируются
└── Что происходит при отказе
Поэтому при проектировании корпоративной инфраструктуры мы бы начинали не с выбора между «облаком» и «своим сервером».
Мы бы начали с самих данных и процессов, которые от них зависят.
Каждое бизнес-требование формирует свои условия:
- › Если критичная производственная операция должна продолжаться при потере внешнего соединения — это влияет на архитектуру.
- › Если аналитике требуется обработать десятки терабайт истории — это влияет на архитектуру.
- › Если данные должны быть доступны филиалам в разных регионах — это тоже влияет на архитектуру.
И если система должна восстановиться после серьёжного отказа за определённое время, место хранения становится только частью гораздо более важной задачи — построения всей цепочки хранения, доступа, резервирования и восстановления данных.
Именно поэтому хороший выбор инфраструктуры — это не выбор самого дешёвого места для хранения.
Это выбор архитектуры, в которой данные остаются доступными, управляемыми и пригодными для работы бизнеса тогда, когда они действительно нужны.
API, Webhook или очередь сообщений?
Когда API есть, а интеграция всё равно не работает
Как соединить производство и корпоративные системы
Все инженерные материалы и экспертные статьи
Полный алфавитный справочник ИТ-терминов
🔒 Данные и доступ к системам заказчика обрабатываются в соответствии с согласованными требованиями к безопасности и конфиденциальности. Условия доступа, хранения и обработки данных определяются архитектурой проекта и договором.
Сайт носит исключительно информационный характер и не является публичной офертой в соответствии со статьёй 437 Гражданского кодекса РФ. Цены, состав и условия предоставления услуг уточняются при проектировании решения и фиксируются в договоре. Условия технического сопровождения и уровень сервиса могут дополнительно определяться отдельным соглашением (SLA).
Автоматизация бизнеса и ИИ-решения под ключ
Самозанятый Скопец Антон Викторович ИНН 741709260870