-
+86-13811808484
- majiang@jinmatimes.com
+86-13811808484
Когда говорят про организацию хранения данных, многие сразу думают про дисковые массивы, про RAID 5 или 10. Но это, если честно, лишь верхушка айсберга. Настоящая организация начинается с вопроса ?зачем?? — зачем эти данные, как к ним будут обращаться, что с ними будет через три года. Видел немало проектов, где начинали с покупки ?крутого? СХД, а потом годами мучились с миграцией и переделкой логики просто потому, что на старте не подумали о жизненном цикле данных и реальных паттернах доступа. Это как строить дом, начиная с выбора обоев.
Вот, например, типичная история. Приходит задача: нужно развернуть хранилище для документооборота в госучреждении. Объем — десятки терабайт, растет медленно. Первый импульс — взять надежный массив, скажем, на базе решений от вендоров вроде Dell EMC или Huawei, настроить RAID 6 для отказоустойчивости и раздать LUN'ы по серверам. Кажется, что все логично. Но через полгода выясняется, что 80% запросов — это чтение старых, уже архивированных документов, которые лежат на тех же ?горячих? дисках. Производительность падает, латентность растет, пользователи недовольны. А все потому, что изначально не разделили данные по ?температуре? — горячие, теплые, холодные. Железо хорошее, но логика его использования хромает.
Здесь как раз важно то, что мы в своей практике в ООО Чжунчуан Жуньцзинь (Пекин) Информационные Технологии всегда стараемся вынести на первый план. Прежде чем рекомендовать конкретную конфигурацию серверов или систем хранения, мы проводим глубокий аудит рабочих процессов. Недостаточно просто спросить ?сколько нужно места?. Нужно понять: как часто данные пишутся? Как часто читаются? Есть ли юридические требования к сроку хранения и месту размещения (например, закон о локализации данных)? Каков бюджет не только на закупку, но и на содержание (электричество, охлаждение, замена дисков)? Только ответив на эти вопросы, можно говорить об организации хранения данных на серверах как о системе, а не о наборе компонентов.
Кстати, о бюджете. Частая ошибка — экономия на софте для управления жизненным циклом данных (ILM). Купили дорогое ?железо?, а для автоматического перемещения данных с быстрых SSD на медленные, но емкие HDD или в облако взяли какое-то кустарное решение или вообще решили делать вручную. В итоге либо тратятся человеческие часы, либо система захламляется, и производительность деградирует. Нужно считать Total Cost of Ownership (TCO) целиком.
Сейчас все увлечены темой программно-определяемого хранения (SDS). И правда, идея заманчивая: абстрагируешься от конкретных дисков и массивов, управляешь всем из единой консоли, гибко перераспределяешь ресурсы. В теории. На практике же развертывание того же Ceph или VMware vSAN — это отдельный квест. Требования к сетевой инфраструктуре (low latency, high bandwidth), к однородности железа, к квалификации админов — на порядок выше. Помню один проект для среднего интернет-магазина, где решили внедрить Ceph на трех серверах. Вроде все собрали, но стабильность кластера оставляла желать лучшего из-за неправильно настроенной сетевой карты и разницы в моделях дисков в серверах. Пришлось откатываться на классическую схему с выделенным СХД.
Но это не значит, что от SDS надо отказываться. Для определенных сценариев — например, для разворачивания приватного облака в образовательном секторе или для платформы разработки и тестирования — это идеальный вариант. Гибкость и масштабируемость того стоят. Ключ в правильном выборе инструмента под задачу и, что критично, в наличии команды, которая сможет это обслуживать. Иногда проще и надежнее купить интегрированную систему, где ?железо? и софт оптимизированы друг под друга, как некоторые линейки в нашем портфеле. Это дает предсказуемость.
И вот еще что важно в контексте SDS — резервное копирование и восстановление. Когда все виртуализировано и абстрагировано, старые методы бэкапа могут не работать. Нужны агенты, которые понимают эту новую логику. Иначе в момент аварии окажется, что ты бэкапил не данные, а метаданные об их расположении. Горький опыт.
Сервер хранения — не остров. Он должен работать в связке с сетевыми коммутаторами (тут важны и пропускная способность, и функции FCoE, NVMe over Fabrics), с вычислительными серверами, с системой виртуализации. Часто узким местом становится именно сеть. Поставили быстрые всефлешовые массивы, но подключили их по гигабитной сети — и вся мощь упирается в этот канал. Или наоборот, сделали сеть 10 Гбит/с, но не настроили приоритезацию трафика, и фоновые задачи репликации начинают ?глушить? основную рабочую нагрузку.
В работе с нашими клиентами из финансового сектора или медицины мы всегда рассматриваем систему хранения как часть единого аппаратно-программного комплекса. Например, при построении отказоустойчивого ЦОДа для больницы важно не только то, как данные хранятся на основном сайте, но и как они реплицируются на резервный. Используется ли синхронная репликация для критичных баз данных? Какова реальная RPO и RTO? Эти параметры напрямую зависят от слаженной работы серверов, СХД и сети. На сайте https://www.itbktech.ru мы как раз акцентируем внимание на комплексности наших решений, потому что по отдельности даже лучшие компоненты не гарантируют результат.
Еще один момент — мониторинг и аналитика. Современные системы позволяют собирать тонны телеметрии: не только загрузку дисков, но и паттерны IOPS, латентность, количество переподключений. Важно не просто собирать эти данные, а уметь их интерпретировать, чтобы предсказывать проблемы до их возникновения. Например, медленный рост числа bad-секторов на дисках в определенном пуле может сигнализировать о необходимости плановой замены до того, как RAID-массив уйдет в деградированный режим.
То, что идеально для хостинга видео для стримингового сервиса, может быть провалом для системы электронных медицинских карт. В первом случае на первый план выходит пропускная способность и масштабируемость ?вширь? (scale-out), данные в основном последовательные, ?холодные? архивы огромны. Во втором — ключевая роль у случайных операций чтения/записи с минимальной латентностью (для работы с базами данных), плюс бескомпромиссные требования к безопасности и аудиту доступа.
Работая над проектами цифровой трансформации для МСП, мы часто сталкиваемся с запросом на ?недорогое, но надежное? решение. И здесь важно найти баланс. Иногда действительно можно обойтись NAS-устройством бизнес-класса для файлового обмена. Но если речь идет о развертывании 1С или другой бухгалтерской системы, где несколько пользователей работают параллельно, уже нужен выделенный сервер с SSD-кэшем и правильно настроенной СУБД. Подмена этих сценариев ведет к деньгам на ветер.
В госсекторе, помимо технических требований, добавляется пласт бюрократии: сертификация оборудования, требования к локализации, длительные процедуры закупок. Здесь организация хранения данных — это еще и умение работать в рамках жёстких регуляторных рамок, подбирать решения, которые им соответствуют, и документально это обосновывать. Опыт, полученный в таких проектах, бесценен.
Технологии не стоят на месте. Протокол NVMe уже перестал быть экзотикой и активно вытесняет SAS и SATA в высокопроизводительных сценариях. Задержки сокращаются в разы. Но его внедрение опять же упирается в готовность всей инфраструктуры — нужны соответствующие контроллеры, поддержка на уровне операционной системы и приложений. Это не ?просто поставить другие диски?.
При этом парадоксальным образом возвращается интерес к ленточным библиотекам для архивирования холодных данных. Почему? Потому что с точки зрения TCO, долговечности носителя (десятки лет) и энергопотребления (ленты не потребляют энергию, когда лежат на полке) для petabytes холодных данных это пока вне конкуренции. Особенно для задач долгосрочного хранения, с которыми мы сталкиваемся в научно-исследовательских институтах или медиаархивах. Так что организация хранения — это всегда микс из нового и проверенного временем.
Что касается тренда на гибридные и мультиклауд-стратегии, то здесь основная сложность — управление. Как единообразно управлять политиками хранения, если часть данных лежит на локальном всефлешовом массиве, часть — в приватном облаке на VMware, а часть — в публичном AWS S3 Glacier? Нужны системы оркестрации более высокого уровня, которые становятся новой точкой концентрации экспертизы. Без них легко получить ?разорванное? хранилище, стоимость и сложность управления которым взлетают до небес.
В итоге, возвращаясь к началу. Организация хранения данных на серверах — это непрерывный процесс, а не разовая настройка. Это поиск компромисса между стоимостью, производительностью, надежностью и сложностью управления. И главный инструмент здесь — не конкретный бренд диска, а понимание бизнес-процессов, которые эти данные обслуживают. Именно на это понимание мы и опираемся в ООО Чжунчуан Жуньцзинь, предлагая не просто ?коробки?, а именно комплексные, продуманные до мелочей решения, которые будут работать годами, а не создадут проблем завтра.
