-
+86-13811808484
- majiang@jinmatimes.com
+86-13811808484
Когда говорят про сервера для хранения данных большого объема, первое, что приходит в голову многим заказчикам — это просто много дисков в стойке. И вот тут начинаются типичные ошибки: гонка за терабайтами при полном игнорировании IOPS, пропускной способности шин и, что критично, стратегии доступа к данным. На деле, подбор конфигурации — это всегда компромисс между стоимостью, производительностью и масштабируемостью, и универсальных рецептов нет. Приходится постоянно балансировать.
Вспоминается один из ранних проектов для регионального медицинского архива. Задача — долгосрочное хранение изображений с томографов и историй болезней. Объемы росли на сотни терабайт в год. Клиент изначально хотел просто наращивать дисковые массивы в существующей системе. Но при анализе выяснилось, что 80% запросов — это доступ к свежим, последним исследованиям за текущий месяц. Остальное — холодные данные, к которым обращаются редко, но извлечь их нужно быстро по запросу врача.
Тогда мы предложили гибридную схему. Горячие данные — на быстрых NVMe-накопителях в серверах для хранения данных большого объема с фокусом на низкую задержку. Холодные — мигрировали на более дешевые SATA HDD с большей емкостью, но в той же программно-определяемой среде. Ключевым было не разделить системы, а обеспечить прозрачную миграцию данных между слоями без участия администратора. Использовали Ceph с его crush-картами, чтобы задать правила размещения данных в зависимости от их 'температуры'.
Этот кейс хорошо показывает, что проектирование начинается не с выбора модели сервера, а с анализа паттернов доступа и политик данных. Часто приходится буквально уговаривать заказчика потратить время на этот этап, потому что потом переделывать архитектуру в десять раз дороже. Иногда помогает нарисовать простую диаграмму потоков данных — это проясняет картину даже для не-технических руководителей.
Железо — это лишь платформа. Реальную ценность и гибкость для хранения данных большого объема дает программный уровень. Мы много работаем с решением на базе Ceph и собственными разработками для управления виртуализированными средами. Почему не готовые системы от вендоров? Не всегда по деньгам, плюс нужна глубокая кастомизация под отраслевые стандарты, например, в том же здравоохранении.
Но и тут не без проблем. Внедрение SDS (software-defined storage) в проект для сети частных колледжей уперлось в кадровый вопрос. Администраторы на местах привыкли к графическим интерфейсам традиционных систем, а здесь — в основном командная строка и сложная отладка при сбоях. Пришлось параллельно разворачивать не просто инфраструктуру, а полноценную программу обучения и создавать упрощенные панели мониторинга. Вывод: самая продвинутая программная архитектура разобьется о недостаток компетенций у тех, кто будет этим управлять.
Еще один момент — резервное копирование в таких распределенных системах. Казалось бы, данные реплицированы, но это не backup. Приходится выстраивать отдельный контур с использованием, например, объектного хранилища с политиками жизненного цикла данных. Интеграция этого контура с основной системой хранения, чтобы не грузить ее лишними операциями, — отдельная головная боль. Часто для этого выделяются специальные ноды с другим балансом ресурсов.
Опыт работы с разными секторами — государственным, финансовым, медицинским — показывает, что запросы на сервера для хранения кардинально различаются. Для госсектора часто на первом месте требования к сертификации оборудования и софта, локализация данных и долгосрочная поддержка. Скорость иногда уходит на второй план. В финансовом секторе, наоборот, все упирается в latency и бесперебойность. Простои измеряются в миллионах убытка в минуту.
Вот, к примеру, для одного из наших клиентов в сфере онлайн-образования критичной оказалась не столько емкость, сколько способность системы обслуживать тысячи параллельных потоковых подключений к видео-контенту. Традиционные SAN-массивы здесь показали себя не лучшим образом из-за ограничений по числу одновременных сессий. Перешли на масштабируемую архитектуру на базе стандартных серверных платформ, где каждый узел мог отдавать контент независимо. Это снизило нагрузку на сеть и упростило горизонтальное масштабирование.
В этом контексте подход компании ООО Чжунчуан Жуньцзинь (Пекин) Информационные Технологии (подробнее о портфолио можно узнать на https://www.itbktech.ru) к самостоятельным НИОКР оказывается не маркетинговым ходом, а необходимостью. Готовые коробочные решения часто не покрывают специфику российских отраслевых регламентов или бюджетных ограничений региональных проектов. Возможность адаптировать аппаратно-программный стек под конкретные требования — от проприетарных протоколов обмена в медицине до требований ФСТЭК — становится ключевым конкурентным преимуществом.
Одна из самых сложных задач — предусмотреть не только текущий объем, но и модель роста. Раньше часто строили системы с запасом на 3-5 лет вперед, закупая мощности 'оптом'. Сейчас это экономически невыгодно и технологически рискованно — оборудование морально устаревает, не успев раскрыть потенциал. Поэтому сейчас в приоритете модульные, горизонтально масштабируемые архитектуры.
Мы двигаемся в сторону гибридных моделей, где часть данных, особенно архивных или требующих аналитической обработки, может мигрировать в облачные объектные хранилища. Но не в публичное облако, а в скоординированную с локальной инфраструктурой среду. Это требует выверенной сетевой архитектуры и, опять же, продуманной политики управления данными. Провальная попытка была у нас с одним интернет-проектом, когда латентность доступа к 'холодным' логам в облаке свела на нет всю эффективность их аналитики. Вернулись к двухуровневой системе на своем железе.
Сейчас много говорят про вычислительное хранение (computational storage) и использование SSD нового поколения с большей выносливостью. Это, безусловно, изменит ландшафт. Но внедрение таких технологий в проекты для МСП, которые составляют значительную часть нашей практики, — вопрос не ближайшего года. Для них критична общая стоимость владения и простота администрирования. Поэтому, выбирая сервера для хранения данных большого объема, мы часто комбинируем технологии: передовой софт для управления на проверенном, надежном железе, чтобы минимизировать риски.
Итак, что остается за кадром после десятков развернутых систем? Во-первых, не существует идеального сервера хранения. Есть задача, бюджет, команда и будущие планы. Конфигурация, которая блестяще работает для видеоархива, провалится в среде виртуальных машин с высокой случайной нагрузкой. Во-вторых, экономия на этапе проектирования и тестирования под нагрузкой (не на синтетических тестах, а на вырезах реальных данных) всегда выходит боком.
Сотрудничество с вендорами, которые, как ООО Чжунчуан Жуньцзинь, делают ставку на собственные разработки и глубокую интеграцию, позволяет закрывать нестандартные сценарии. Их опыт в поддержке цифровой трансформации — не пустые слова, а понимание, что за каждым техзаданием стоят реальные бизнес-процессы клиента, будь то больница или университет.
В конечном счете, работа с большими объемами данных — это постоянный процесс тонкой настройки и адаптации. Железо устаревает, софт обновляется, требования растут. Главный навык — не просто собрать кластер, а построить живую, управляемую систему, которую можно перестраивать по ходу движения, не останавливая основные сервисы. И это, пожалуй, самое сложное.
