`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Активные хранилища объемных данных

+77
голосов

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

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

Большой передел

Взрывной рост объемов хранения и разнообразие моделей работы с данными привели к переделу рынка СХД. Раньше топ-вендоров от «всех остальных» отличала оснащенность дисковых массивов и развитая техническая поддержка. Новым задачам тесно в рамках любых продуктовых линеек специфических устройств. Идея SDS оторвать управление данными от физической реализации хранилищ пришлась «всем остальным» ко двору. Их оружием стали адресные наборы сервисов поверх обычных серверов, которыми они удовлетворяют потребности пользователей и потихоньку отбивают у лидеров нишу за нишей. Первыми распробовали свободу владельцы объемных данных активного обращения.

Secondary? Primary!

Данные многообразны. Физическими терминами «горячие-холодные» или «динамические-статические» описывают место данных в пирамиде хранения, степень их востребованности, изменчивости и близости к исполняющим операции ввода/вывода устройствам, в конечном счете — к процессорам.

Соответственно разнятся и хранилища. Принципиальные отличия между primary storage и secondary storage (первичным и вспомогательным) — в ожиданиях пользователей от таких устройств хранения.

От secondary storage не ждут высокой производительности, но хотят масштабируемости, совместимости с перспективными протоколами передачи данных (например, S3) и сервисов, сопутствующих работе с большими данными. Чтобы не потерять рынок, лидеры индустрии дружно добавили распределенные SDS-решения к своим традиционным аппаратным линейкам. От совокупного информационного шума может казаться, что весь SDS — это что-то облачное, гиперконвергентное и геораспределенное.

Производительность обеспечивает primary storage, и это для SDS еще больший вызов, из-за суровых требований к низким задержкам обращения к данным, высокой отдаче в IOPS и MB/sec, оптимизации трафика ввода/вывода, к обеспечению целостности данных и их защите, реализации бэкапов, архивированию и быстрому восстановлению после сбоев.

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

Объемное хранение верхнего слоя

Программно-определяемые системы хранения верхнего слоя (primary SDS) — давно не новость и не редкость. Возможно, лучший пример зрелой технологии их реализации — ZFS. Эта файловая система — одна из самых совершенных существующих. Само ее название Zettabyte File System указывает на практически неограниченный потенциал емкости СХД (1 ZB = 1 073 741 824 TB). Кроме поддержки огромных объемов, ZFS обеспечивает высокую производительность, проверяет целостность данных, противостоит их коррозии, поддерживает репликацию, мгновенные снимки (snapshots) и самовосстановление данных.

Купить можно и готовые ZFS-устройства: от настольных массивов до флагманской для Oracle NAS-стойки ZFS Storage ZS4-4. Но именно SDS на ZFS дают интеграторам и пользователям рычаги продуктивности, гибкость включения в инфраструктуру и необходимые степени свободы.

Посмотрим на хранение глазами владельцев объемных данных. Инструменты ZFS дают представление о горизонтах возможностей.

Производительность

Системы хранения на ZFS хорошо справляются с активным трафиком ввода-вывода в транзакционных базах данных, хранилищах виртуальных машин, в раздаче видеоконтента, на столах разработчиков ПО. Ключ к их производительности — поддержка гибридных пулов хранения RAM / SSD / HDD.

В ZFS есть два уровня адаптивного кэширования чтения (adaptive read cache): ARC в RAM и L2ARC на SSD. «Часто используемые данные» кэшируются в быстрой оперативной памяти. Поскольку RAM — ограниченный по объему и достаточно дорогой ресурс, к нему на помощь приходит следующий уровень кэширования — на SSD («данные недавнего обращения»). Когда появляется запрос в системе, ZFS ищет данные в ARC, если их там нет — в L2ARC, а если и не находит и там — обращается за ними к основному уровню хранения, HDD. Таким образом снижается время отклика и уменьшается количество запросов к медленным дискам.

Для оптимизации операций случайной записи используется лог намерений ZFS — ZIL (ZFS Intention Log) на SSD, он же SLOG (Separate Log). ZFS на запись работает так. Все транзакции, синхронные и асинхронные, кэшируются в памяти. Для синхронных транзакций подтверждение пишущему приложению отправляется по завершению дисковой операции на основном массиве. Для асинхронных — сразу же. Чтобы сократить время ожидания, ZFS скидывает каждую синхронную транзакцию на ZIL и отправляет приложению подтверждение.

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

Эффективность кэширования зависит от типа данных основного массива и модели их использования. Например, для хранения виртуальных машин (с 3-5% горячих данных) кэширование будет очень эффективно.

Масштабируемость

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

Традиционные файловые системы располагаются на одном устройстве, а если на нескольких — то им нужен менеджер томов. ZFS строится поверх виртуальных пулов хранения (zpool), без ограничений на размер файлов. Пул создается из виртуальных устройств (vdevs), каждое из которых является либо физическим устройством, либо зеркалом (RAID 1), либо (RAID Z) — группой из трех и более устройств. Суммарная ёмкость всех vdevs затем доступна для всех файловых систем в zpool.

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

Резервирование данных

В ZFS есть привычные термины зеркалирования (RAID 1) и четности: одинарной (RAID-Z), двойной (RAID-Z2) и даже тройной (RAID-Z3). Но, в отличие от стандартного для классических RAID метода записи Read-Modify-Write для данных и четностей, в ZFS используется Copy-on-Write. Данные пишутся не поверх старых, а в новое место, c переустановкой указателя на новое расположение данных.

RAID-Z напоминает RAID 5 по устойчивости к потере одного диска, но работает иначе. Во-первых, устранена проблема «write hole». В RAID 5 при изменении части страйпа (группы блоков, расположенных на разных дисках) для пересчета четностей надо читать весь страйп — что просаживает производительность. Если страйп пишется целиком, операция выполняется асинхронно на всех дисках. Если переписывается часть страйпа, то записи должно предшествовать синхронное чтение. Аппаратным RAID-контроллерам нужен кэш, защищенный аккумулятором (суперконденсатором с модулем памяти) — для сохранения в нем записей, пока выполняется синхронное чтение.

Принцип Copy-on-Write и динамический размер страйпа в RAID-Z, автоматически устраняющий проблему частичной перезаписи, не только закрывают проблему «Write hole». Они же дают RAID-Z преимущество в скорости — ему не нужно выполнять чтение перед записью, в отсутствие самих частичных записей страйпов.

Без фиксированного размера страйпа устройство RAID-массива усложняется — ведь где-то надо хранить метаданные о размере страйпов. За это отвечает файловая система, теперь неразрывно связанная с RAID- массивом (логическим управлением томами данных). Усложнение файловой системы не приводит к замедлению — так как при синхронизации копируются только блоки с данными, а пустые блоки — нет.

В модели Copy-on-Write ZFS все указатели на блоки внутри файловой системы содержат 256-битную контрольную сумму в целевом блоке, которая проверяется, когда блок прочитан. Блоки данных, содержащие активные (в этот момент) данные, никогда не перезаписываются вместе; напротив, выделяется новый блок, изменённые данные записываются в него, а затем метаданные любых блоков, которые на него ссылаются, таким образом всё перераспределяется и записывается. Чтобы уменьшить накладные расходы, в этом процессе группируется несколько обновлений в группу транзакции, также, если требуется, ведётся журнал использования при синхронной записи.

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

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

Важно, что RAID-Z не предъявляет особых требований к аппаратной части сервера — хватало бы оперативной памяти.

Кроме RAID-Z используются RAID-Z2 (близок RAID-6), устойчивый к отказу двух жестких дисков и RAID-Z3, выдерживающий отказ до трех дисков массива. Чем выше избыточность — тем ниже производительность.

Пулы хранения

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

ZFS объединяет доступные устройства в пулы, обращаясь с ними как единым ресурсом хранения (zpool). Пулы могут быть оптимизированы по емкости, производительности I/O, устойчивости к отказам, в одной из форм RAID. После появления в системе новых дисков они добавляются в zpool, ZFS видит новую емкость и использует ее автоматически.

Восстановление данных

Важная опция любой СХД — способность делать мгновенные снимки (snapshots) — состоятельные копии всей файловой системы или дискового объема в определенный момент времени. Это помогает обходиться без выделения временного окна под бэкап, откатываться на прежние версии ПО, восстанавливать случайно перезаписанные файлы итд. Чем меньше пространства отъедают снимки, без просаживания производительности — тем лучше.

У модели записи Copy-on-Write есть еще одно сильное преимущество: когда ZFS записывает новые данные, то вместо освобождения блоков со старыми данными она может их сохранять, создавая снимки файловой системы. Снимки создаются очень быстро, так как все данные в составе снимка уже сохранены. На основе снимков реализуют инкрементное резервное копирование хранилищ. С помощью пересылки снимков можно воссоздать в любом пуле ZFS ту же последовательность снимков. По снимкам можно узнать какие файлы были изменены, созданы, удалены и переименованы между снимками.

Целостность и состоятельность данных

Вычитываемая информация должна быть идентична той, что была размещена в системе хранения. При хранении больших данных особенно важна защита от скрытых угроз, с которыми не справляются технологии RAID. Опасны «тихие» ошибки дисков (silent data corruption)— они накапливаются и никак себя не проявляют. Со временем повреждение данных может приводить к тяжелым последствиям. Защита «от двери и до двери» (end-to-end data protection) помогает отслеживать эрозию данных по всему пути их следования от приложения до устройства хранения.

В обеспечении целостности данных ZFS уникальна — она и создавалась Sun Microsystems с фокусом на сквозной верификации end-to-end. Для каждого блока данных, отправляемого в память, вычисляется контрольная сумма, которая сохраняется в указателе на этот блок, не в составе блока данных. Указатель, в свою очередь, сверяется по контрольной сумме, которая сохраняется в указателе на указатель, и так далее. Это касается данных файлов, мета-данных и всей иерархии хранилища. Такой подход отличается от сверки контрольных сумм в RAID и позволяет выявлять «тихие» ошибки, фантомные записи, ошибки драйверов и другие неумышленные записи. Традиционные RAID не отличают «цифровой мусор».

Экономия дискового пространства

Бережливо расходовать дисковое пространство в ZFS помогают динамическое выделение емкости, сжатие данных и дедупликация.

Динамическое выделение емкости (thin provisioning) — это виртуальное выделение дискового пространства, позволяющее наращивать емкость хранилища без переформатирования. Избавляет от перерасхода дисков — их можно докупать и вводить в оборот данных по надобности.

Сжатие данных и дедупликация «на лету» экономят место на дисках, снижая накладные расходы по хранению (хотя и ценой нагрузки на процессоры и оперативную память). Коэффициент дедупликации может достигать 3:1 — когда для записи 3 ТБ данных достаточно 1ТБ физического пространства на дисках.

ZFS — это еще не СХД

Базовые возможности ZFS дают хорошую основу для СХД корпоративного уровня, но самой по себе ее недостаточно.

Пример Open E Jovian DSS на основе Linux и ZFS показывает возможности СХД уровня предприятий. Кроме штатных возможностей ZFS в ней реализованы:

  • Подключения по iSCSI, NFS, SMB3

  • Кластерные реализации High Availability Active-Active

  • Службы Off-Site Data Protection с автоматическими мгновенными снимками и репликацией для скоростного восстановления после сбоев

  • Интерфейс системного мониторинга

  • Простой язык командной строки CLI

  • Интерфейс программирования приложений RESTfull API

  • WEB GUI

  • Лицензирование по объему

СХД на Open-E Jovian DSS встраиваются в сети NAS/SAN и работают в кластерных конфигурациях с критичными приложениями в среде VMware, Hyper-V, XEN.

Альтернативы

Помимо коммерческих SDS на ZFS существуют свободные, поддерживаемые открытым сообществом продукты — например, Free NAS. В них отсутствуют все перечисленные выше опции работы в критичных приложениях, а с «сообщества» много не спросишь.

Как уже было сказано, продукты на слуху из ряда CEPH, Gluster, Scality и др. предназначены для вспомогательного (secondary) и облачного хранения. Основные системы хранения (primary storage) как минимум требуют более высокой производительности.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365

+77
голосов

Напечатать Отправить другу

Читайте также

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT