Программно-определяемое хранилище и объектное хранилище в эпоху облаков
В наши дни наблюдается огромный рост количества приложений, и эти приложения начали генерировать много данных, будь то с мобильных устройств или из Интернета. Поскольку таких приложений создается все больше и больше, им необходимо доставлять контент непосредственно пользователю с более высокой скоростью, независимо от того, используют ли они мобильное устройство, планшет, ноутбук, настольный компьютер или любое подобное устройство. Наряду с этим обработка файлов все большего и большего размера стала проблемой, для этого необходимо хранить много метаданных, связанных с файлом, и к ним нужно обращаться при необходимости. Хранение данных, которое когда-то казалось очень простым, теперь стало большой проблемой.
Объектное хранилище, которое развилось за последние несколько лет, помогает решить эту задачу. SDS (Sпрограммное обеспечение dопределенное sхранилище) вместе с объектным хранилищем, которые были разработаны с учетом простоты Доступ к файлам, развертывание и управление ими, а также сохранение копий реплик решают большинство современных проблем хранения данных.
Объектный файл может быть любого типа: медиафайл, текстовый файл, обычный файл, видеофайл, символьный файл или блочный файл; все эти типы файлов обрабатываются одинаково. В дополнение к этому, обработка больших файлов в SDS очень проста. Объектное хранилище очень мощное, поскольку оно говорит на языке Интернета, используя протокол HTTP. Объектное хранилище будет идеальным выбором даже для архивов, резервного копирования файлов, цифрового хранения, совместного использования файлов и транзакций с файлами.
По данным Forbes, каждый день и каждую минуту перечислены некоторые известные транзакции и объем данных, которые они передают:
- Пользователи Snapchat поделились 527 760 фотографиями,
- Более 120 профессионалов присоединяются к LinkedIn,
- Пользователи смотрят 4 146 600 видеороликов на YouTube,
- В Твиттере отправлено 456 000 твитов,
- Пользователи Instagram выкладывают 46 740 фотографий.
Вышеуказанные транзакции будут генерировать огромные объемы байтов данных. Они будут выражаться в Зета-байтах или больше. По данным IDC, к 2025 году ежегодно будет генерироваться примерно 175 дзета-байт данных. Это составит 61 процент (сложный годовой рост). Просто помните, что хранение этих данных и управление этими данными с помощью файлов разных типов — непростая задача.
С развитием облачных технологий и острой потребностью в огромных хранилищах данных появление таких технологий, как Object Storage, стало неизбежным. Наряду с облаком объектное хранилище развивалось очень быстро, и многие сообщества с открытым исходным кодом наряду с промышленным сотрудничеством выступили вперед и внесли свой вклад в развитие объектного хранилища. Ниже приведены некоторые из хорошо известных и широко используемых технологий в области объектных хранилищ:
- Swift (в OpenStack).
- Цеф.
- GlusterFS (не чисто объектное хранилище).
- AWS S3 (простая служба хранения в облаке Amazon), хранилище BLOB-объектов Azure (от MS), облачное хранилище Google (GCS), облачное хранилище объектов IBM, Alibaba OSS и т. д. (Все это поставщики облачных хранилищ).
- Dropbox, Google Drive, Cloud Files {Облачный сервис с отдельными учетными записями}.
- Outlook 365 (электронная почта в облаке).
Поговорив об объектном хранилище, можно подумать, зачем оно нужно и каковы преимущества объектного хранилища. Ниже приведены некоторые преимущества объектного хранилища:
- Объектное хранилище (ОС) помогает с легкостью проводить анализ данных. Поскольку ОС управляется метаданными и несколькими уровнями классификации, анализ намного эффективнее по сравнению с обычным хранилищем данных.
- ОС помогает в большей степени масштабируемости. Можно продолжать добавлять данные, не беспокоясь об ограничениях/порогах.
- Доступ к данным, их передача и извлечение будут быстрее при использовании ОС. В ОС нет структуры папок, и данные классифицируются для удобства доступа, что способствует более быстрому доступу и скорости передачи.
- ОС определенно помогает снизить стоимость. Благодаря масштабируемой архитектуре реализации хранение данных станет менее затратным делом. Все данные неструктурированы, и любые требования к хранению могут быть удовлетворены с минимальными затратами и инвестициями.
- ОС также помогает в оптимизации ресурсов. Необходимо хранить только метаданные, и это легко настроить. По этой причине у ОС очень меньше недостатков и ограничений по сравнению с традиционным хранилищем на уровне файлов и блоков.
- Долговечность данных. Степень, в которой данные никогда не будут безвозвратно потеряны или повреждены, несмотря на сбои отдельных компонентов.
- Доступность данных будет высокой, а управление данными станет более плавным.
Краткая история хранения и развития программно-определяемого хранилища и объектного хранилища
Программно-определяемое хранилище и объектное хранилище в эпоху облаков и Интернета вещей
Теорема CAP
Теорема CAP (также называемая "Теорема Брюера") сыграла жизненно важную роль в развитии объектного хранилища. Эрик Брюстер (профессор компьютерного отдела Калифорнийского университета в Беркли) сформулировал эту проблему в 2000 году. Согласно этой проблеме, распределенные компьютерные системы не могут одновременно обеспечивать следующее:
- Согласованность: все клиенты одновременно видят одну и ту же версию данных.
- Адоступность: всякий раз, когда происходит чтение/запись в систему, мы гарантированно получим ответ.
- Допуск раздела: система будет работать, даже если сеть не идеальна.
Для любой распределенной компьютерной системы любой из двух вышеперечисленных должен быть выбран в зависимости от обстоятельств любой реализации подсистем хранения. Эта теорема CAP также помогла при разработке технологии объектного хранилища. Потому что последовательность и доступность данных играют очень важную роль.
Программно-определяемое хранилище
Мы знаем, что были дни, когда компьютеры «мэйнфреймы» были повсюду. Будь то банковский сектор, создание анимационного фильма, хранение данных о пациентах в больнице, фондовый рынок или мэйнфрейм, было окончательным решением. Эти мэйнфреймы работали с подключенными жесткими дисками и выделенными системами хранения данных со встроенными контроллерами.
Техно-гики старшего поколения, возможно, были свидетелями этих основных фреймов, их роста и использования в течение нескольких десятилетий. Они были очень дорогими, а обслуживание требовало квалифицированных ресурсов, а также решало такие проблемы, как миграция данных, резервное копирование и т. д. Масштабируемость всегда была проблемой в такого рода конфигурациях.
Все эти проблемы и высокие требования к хранению приводят к разработке так называемых программно-определяемых систем хранения (SDS). Механизмы анализа и доступа были отделены от базовых жестких дисков в системах SDS.
Ниже приведены четыре основных компонента, которые определяют любую систему SDS:
- Маршрутизация хранилища. Этот уровень действует как шлюз к системе хранения. Основная задача маршрутизаторов — маршрутизация запросов к хранилищу в обход аппаратных и сетевых сбоев. Этот уровень маршрутизатора масштабируется с каждым дополнительным узлом, обеспечивая все большую и большую пропускную способность для доступа к данным. Иногда эти маршрутизаторы могут быть распределены по нескольким центрам обработки данных и географическим местоположениям.
- Устойчивость хранилища. Основная цель или задача SDS — способность восстанавливаться после сбоев, используя программное обеспечение, а не оборудование. Различные механизмы или схемы защиты данных используются для обеспечения того, чтобы данные не были повреждены или потеряны в любой момент времени.
- Физическое оборудование. Это физическое оборудование используется для хранения фрагментов информации на диске. Системы маршрутизации хранилища данных будут использоваться для маршрутизации, если узел не работает.
- Внеполосный контроллер. Этот контроллер можно использовать для динамической настройки системы с целью оптимизации производительности, обновления, обслуживания и управления емкостью. В случае аппаратных сбоев возможно более быстрое восстановление, что позволит оператору реагировать на любые эксплуатационные события.
Использование SDS имеет множество преимуществ по сравнению с традиционным хранилищем или аналогичными механизмами. Поскольку SDS дает множество преимуществ, во многих отраслях корпоративного уровня техно-гики внедряют его в более быстром масштабе. Благодаря отделению физического оборудования от программного обеспечения конфигурация упрощается.
С SDS можно использовать накопители различной емкости для повышения производительности.
В этой статье я описал некоторые широко используемые технологии объектного хранилища.
Свифт (OpenStack)
Swift — это система объектного хранения. Частное облако OpenStack поддерживает и поддерживает быструю разработку, улучшение функций, внесение кода, а также поддержку сообщества открытого исходного кода.
Быстрая архитектура
Swift имеет несколько компонентов, которые взаимодействуют друг с другом, обеспечивая непрерывную доступность данных и их резервное копирование.
Ниже приведены различные компоненты Swift:
- Прокси-сервер. Этот сервер отвечает за обслуживание запросов и связывает воедино все остальные компоненты быстрой архитектуры. Этот компонент также обрабатывает политики типа «Код стирания» (кодирование и декодирование данных объекта). Этот прокси-сервер обрабатывает множество сбоев на базовом уровне. Все объекты передаются с этого прокси-сервера без какой-либо буферизации.
- The Ring: этот компонент используется для сопоставления названных объектов на диске с их фактическим физическим местоположением. Для каждой политики хранения должно быть одно кольцо объектов, и для всех учетных записей будут отдельные кольца. Кольцо поддерживает это сопоставление с использованием различных аспектов, таких как зоны, устройства, разделы, реплики и т. д. По умолчанию кольцо реплицируется 3 раза в кластере. Ring поддерживает сопоставление, и вся информация о разделах хранится здесь вместе с информацией о местоположении. В случае сбоя или катастрофы компания Ring возьмет на себя ответственность определить, какие устройства можно использовать, и обеспечит бесперебойную доступность данных. Номер по умолчанию можно изменить в зависимости от необходимости и требований резервного копирования, репликации и восстановления. Для поддержания веса данные равномерно распределяются по емкости системы. Эти веса используются для балансировки распределения разделов на устройствах в кластере.
- Политики хранения. Политики хранения помогут различать уровни обслуживания, функции и поведение при быстром развертывании. Каждая из этих политик настроена и доступна клиенту через абстрактное имя. Политика может быть «по умолчанию с 3-кратной репликацией» — один из таких примеров. Другими подобными политиками могут быть использование SSD (твердотельных устройств), Erasure Coding и т. д. На основе сопоставления политик хранения будут предприниматься различные меры и действия. Чтобы узнать больше о «коде стирания», перейдите по этой ссылке.
- Сервер объектов: Это простой объект (бинарныйбинарный Lбольшой объект ) своего рода сервер хранения, который может хранить, извлекать и удалять объекты, хранящиеся на локальных устройствах. Любой объектный файл хранится в виде файлов двоичного типа в целевых файловых системах с метаданными в атрибутах файлов. В файловых системах, таких как «ext3» и выше, опция «xattrs» по умолчанию включена. Каждый объект сохраняется с использованием пути, который получается из комбинации хэша его имени и метки времени операции. Всегда последняя операция записи имеет приоритет, и будет использоваться та же самая последняя версия.
- Сервер контейнеров. Его основная задача — обработка списков всех присутствующих объектов. Его не будет волновать, где и как хранятся эти объекты и каковы их характеристики.
- Сервер учетных записей. Это то же самое, что и сервер контейнеров, за исключением того, что этот сервер отвечает за список контейнеров, а не объектов.
- Репликация: Чтобы поддерживать систему в согласованном состоянии в случае каких-либо временных сбоев или ошибочных ситуаций, таких как сбои в работе сети, сбои дисковода и т. д., используется репликация. Репликация всегда будет сравнивать локальные данные с удаленной копией, чтобы убедиться, что все они содержат последнюю и одинаковую версию. Когда объект удаляется, репликатор гарантирует, что все соответствующие данные, соответствующие этому объекту, также будут удалены.
- Реконструкция. Используется для политик на основе Erasure Code и аналогичен репликатору для политик типа репликации.
- Обновления. В случае сбоя или высокой нагрузки, если какое-либо обновление завершается неудачно, это обновление автоматически ставится в очередь в локальной файловой системе.
Ниже приведены некоторые преимущества использования Swift:
- Благодаря кольцевой сети распределение данных, резервное копирование и извлечение данных происходит очень быстро.
- Доступность данных высокая.
- Восстановление данных происходит быстрее по сравнению с традиционными механизмами хранения.
- Используя любой интерфейс API, можно легко взаимодействовать со Swift.
- Swift — это своего рода технология хранения данных Plug-n-play, внедрить или настроить ее будет несложно.
- Любой файл большого размера можно очень легко сохранить и повторить.
Ниже приведен пример диаграммы архитектуры «Swift в OpenStack»:
Свифт в openstack
Цеф (из Redhat)
Ceph снова является одним из самых популярных решений хранения данных с открытым исходным кодом, основанным на принципах программно-определяемого хранилища и объектного хранилища. Redhat владеет и поддерживает Ceph.
Ниже приведены некоторые из хорошо известных особенностей Ceph:
- Ceph поддерживает масштабируемое хранилище.
- Ceph — экономичное решение для хранения данных.
- Поддерживает все типы файлов, включая блочные, объектные и файловые.
- Ceph обеспечивает высокую производительность с помощью объектного хранилища.
- Отсутствие привязанного к поставщику оборудования и соответствие открытым отраслевым стандартам.
- Ceph обратно совместим.
- Ceph поддерживает взаимодействие и может быть тесно интегрирован с функциями OpenStack Swift, Cinder и Manila.
Ceph рассматривается как один из отраслевых стандартов, когда речь идет о программно-определяемом хранилище, и он поддерживает аппаратное обеспечение, которое снова основано на отраслевых стандартах. Поскольку Ceph поддерживает типы блоков, объектов и файлов, управление хранилищем будет очень простым, и это помогает автоматически управлять всеми необходимыми данными. Поскольку Ceph обратно совместим, обработка существующих ресурсов блочного хранилища, таких как iSCSI, NFS (сетевая файловая система), может быть выполнена очень легко.
Как упоминалось в разделе функций, Ceph оснащен встроенной функцией масштабируемости. Большие рабочие нагрузки с интенсивным использованием данных, такие как сети доставки видео, облачный видеорегистратор, виртуализация сетевых функций и т. д., обрабатываются без каких-либо сбоев.
Ceph также поддерживает NVMe (энергонезависимая память Express), SSD (твердотельные устройства) с уровнями производительности, которые оптимизированы для поддержки требований к пропускной способности, задержке и IOPS для рабочих нагрузок с высоким потреблением данных.
Более подробную информацию о том, что такое NVMe и SSD, можно найти в справочных ссылках, приведенных в конце этого руководства.
Гластер (и глюстерфы)
Gluster – это бесплатное программное обеспечение с открытым исходным кодом и масштабируемой сетевой файловой системой. Для задач с интенсивным использованием данных и управления рабочей нагрузкой потокового мультимедиа GlusterFS будет подходящим кандидатом.
Используя gluster, несколько ресурсов дискового хранилища с разных серверов могут быть объединены в единое глобальное пространство имен. Которое позже можно будет использовать для хранения, даже если эти серверы расположены в разных географических регионах.
Ниже приведены некоторые особенности и преимущества глины:
- Gluster поддерживает масштабируемость до нескольких петабайт.
- Используя gluster, можно обслуживать тысячи клиентов.
- Gluster совместим с Posix.
- Гластер использует стандартное оборудование.
- Gluster обеспечивает репликацию, квоты, репликацию на основе географического положения, создание снимков и обнаружение BitRot.
- Gluster поддерживает оптимизацию для различных типов рабочих нагрузок.
Можно напомнить, что Gluster не основан на чистом принципе объектного хранилища, но некоторые его функции и тип конфигурации, который мы выполняем, помогают использовать его в качестве одного из программно-определяемых механизмов хранения.
Гластерная архитектура
Гластерская архитектура
Gluster широко используется во многих областях и отраслях промышленности, будь то здравоохранение, средства массовой информации или аналогичные типы, где выполняются большие рабочие нагрузки и что зависит от аспектов емкости и масштабируемости.
Рекомендуем прочитать:
- Подробное объяснение концепций и технологий хранения данных
Заключение
Изучение принципов объектного хранилища, его развития и того, что такое программно-определяемое хранилище, поможет понять, как хранилище используется в облачных средах и средах Интернета вещей. Объектное хранилище и программно-определяемое хранилище становятся де-факто стандартами для многих отраслей разработки программного обеспечения и предприятий, где интенсивное использование данных и управление рабочей нагрузкой всегда являются проблемой. Изучение этих концепций поможет решить большинство отраслевых проблем в сфере хранения данных.
Если вы обнаружите какие-либо ошибки и опечатки в этом руководстве, сообщите нам об этом. Мы внесем соответствующие изменения и обновим руководство.
Ссылки:
- https://www.forbes.com/sites/bernardmarr/2018/05/21/how-much-data-do-we-create-every-day-the-mind-blowing-stats-everyone-should-read/ #5972d61d60ba
- https://www.networkworld.com/article/3325397/idc-expect-175-zettabytes-of-data-worldwide-by-2025.html
- https://dzone.com/articles/understanding-the-cap-theorem
- https://docs.openstack.org/swift/latest/overview_architecture.html
- www.swiftstack.com
- https://www.redhat.com/en/technologies/storage/ceph
- https://searchstorage.techtarget.com/definition/SSD-solid-state-drive
- https://en.wikipedia.org/wiki/NVM_Express
- https://docs.gluster.org/en/latest/Administrator%20Guide/GlusterFS%20Introduction/