Сравнение IPFS и EdgeFS для сценариев использования безопасности Edge / IoT разработки

Сравнение IPFS и EdgeFS для сценариев использования безопасности Edge / IoT разработки

Источник · Перевод автора

Безопасность данных представляет собой серьезную проблему роста вычислительных возможностей Edge / Fog. Узнайте, как преодолеть проблемы с введением современного децентрализованного слоя данных EdgeFS.

Мы сформулировали преобразование Edge / Fog для вычислений с аргументами в значительную экономию затрат из-за уменьшения потребления полосы пропускания, повышения эффективности аналитики из-за улучшенного необходимого времени реакции на события в физическом мире, максимального времени безотказной работы, не полагаясь на WAN (Wide Area Network) как сотовая связь, которая может быть менее надежной, чем проводная, и улучшенная безопасность.

С точки зрения безопасности, выгоды приходят от защиты активов, расположенных рядом с источником данных, которые никогда не предназначались для подключения к более широким сетям, а тем более к Интернету.

Однако по мере того, как приложения, данные, вычислительные услуги отталкиваются от централизованных местоположений, фрагменты данных должны реплицироваться во все большем количестве распределенных сетей. Имея это в виду, безопасность данных по-прежнему представляет собой серьезную проблему роста вычислительных возможностей Edge / Fog.

Для решения этих задач нам нужны концептуально новые децентрализованные уровни распределения и доступа к данным, разработанные с учетом безопасности Edge / Fog.

Давайте сравним два проекта децентрализованных уровней хранения с открытым исходным кодом, которые могут соответствовать списку требований с точки зрения безопасности данных: EdgeFS (http://edgefs.io, Лицензия Apache) и IPFS (Interplanetary File System https://ipfs.io, Лицензия MIT).

Когда мы разрабатывали EdgeFS, безопасность данных была нашим главным приоритетом. В EdgeFS, после записи, данные в любом данном блоке не могут быть изменены задним числом, так как это сделает недействительными все хэши SHA-3 в предыдущих блоках в подобном блокчейну n-арном дереве и нарушит консенсус, согласованный между децентрализованными местоположениями. То же самое можно сказать и о IPFS.

EdgeFS основана на архитектуре с неизменяемыми самопроверяющимися метаданными, не зависящими от местоположения, которые ссылаются на самопроверяемые полезные данные, независимые от местоположения.

Несмотря на то, что обработка двух фрагментов хранилища полезных данных очень схожа, различия в именах и обнаружении объектов почти настолько различны, насколько это возможно. IPFS была разработана главным образом для криптографических транзакций одноранговой бухгалтерской книги, в то время как EdgeFS не делает таких предположений и фокусируется на высокой производительности для многих локальных или удаленных операций с адресацией содержимого.

Неизменяемые блоки полезной нагрузки

Конечный результат размещения фрагмента данных в IPFS состоит в том, что он идентифицируется и проверяется с помощью надежного криптографического хэша и что криптографический хэш может использоваться для поиска фрагмента для извлечения. Это очень похоже на EdgeFS, но есть несколько отличий:

IPFS принимает чанк, а затем генерирует криптографический хеш. Клиент EdgeFS (через API библиотеки шлюза CCOW «Cloud-Copy-On-Write») криптографически хеширует чанк перед тем, как запросить его установку. Это позволяет избежать передачи дублированных фрагментов полезной нагрузки, также известных как встроенная дедупликация данных. IPFS-маршрутизация является последовательным решением хеширования. Вместо этого EdgeFS направляет запрос ввода-вывода в целевую группу, а затем проводит быстрые переговоры внутри группы, чтобы найти и динамически поместить новые фрагменты в наименее загруженные цели. Это улучшает балансировку емкости, использование запоминающих устройств, также известных как динамическое размещение данных.

Таблица EdgeFS FlexHash – это локальная конструкция сайта. Он автоматически обнаруживается и находится в памяти сервера локального сайта. FlexHash отвечает за маршрутизацию ввода-вывода и играет важную роль в логике динамической балансировки нагрузки. На основе обнаруженной топологии сайта определяются так называемые целевые группы для согласования, которые обычно формируются на 8–24 зонированных устройствах хранения для обеспечения надлежащего распределения доменов сбоев.

Различия в философии метаданных

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

IPFS берет криптографический хеш атомарного объекта и встраивает эти ссылки в другие именованные объекты, которые в основном функционируют как каталоги.

Каждый из этих объектов каталога также является неизменным, ссылаясь на конкретное замороженное содержимое во времени. Сам объект каталога имеет криптографический хеш, на который можно ссылаться в каталогах более высокого уровня. Наконец, публикуется «корневой» каталог, на который затем указывает изменяемое имя для сопоставления объекта каталога. Я подозреваю, что на такой дизайн сильно повлияла необходимость обеспечить высоконадежный постоянный уровень для алгоритмов регистра криптовалюты за счет общей гибкости и производительности хранилища.

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

В EdgeFS информация, которая поддерживает поиск хранимого объекта по имени или по другим критериям поиска, всегда записывается как метаданные отдельно от полезной нагрузки. Он обрабатывает сохраненную полезную нагрузку как непрозрачные большие двоичные объекты с организацией на диске, которая не требует поиска ссылок в самом чанке, что позволяет осуществлять сквозное шифрование, управляемое клиентом. То есть это предполагает, что вся полезная нагрузка зашифрована и никогда не пытается ее проанализировать. Изменяемая информация метаданных всегда хранится локально (кластер локального сайта), что позволяет всегда локально, немедленно согласовывать политику ввода-вывода, не жертвуя гибкостью или производительностью.

Неизменная версия метаданных

По определению, большинство метаданных о конкретной версии объекта должны быть неизменяемыми. Некоторые метаданные могут быть независимыми от содержимого версии, например, метаданные, управляющие сохранением версии объекта, переопределения репликации локального сайта, ACL и так далее.

Одной из сильных сторон IPFS является то, что она не меняет хранилище для объекта каталога, когда изменяемая ссылка на именование изменяется, чтобы указывать на новую версию. Это очень похоже на то, как EdgeFS обрабатывает изменяемые ссылки на имена, и, на мой взгляд, гораздо предпочтительнее практики создания явно версионного имени. В EdgeFS изменяемое именование всегда предполагается локальным и «повторно гидратируется» при удаленной передаче между сайтами. Это позволяет всегда осуществлять глобальную передачу данных между географическими точками и, как таковое, обеспечивает глобальную репликацию, которая очень эффективно избегает ненужных сетевых передач, например встроенной дедупликации данных через глобальную сеть.

Резюме

Есть много других функций современной подсистемы хранения метаданных, которые требуются для хранения контента с контролем версий, который IPFS кажется просто еще не адресованным:

Возможность быстрого поиска имен, которые попадают в любой заданный каталог folder / directoryPredictable, или поиск по сегменту bucket. Элемент управления timeTenant контролирует доступ и модификацию метаданных арендатора, сохраняя ссылочную полезную нагрузку.

Хотя я признаю, что первичные и оригинальные цели IPFS не заключались в том, чтобы обслуживать сценарии использования Edge / Fog-вычислений, его преимущества в области безопасности и глобальной масштабируемости соответствуют профилю. И, возможно, однажды она наверстает упущенное по остальным требованиям. Но зачем ждать? EdgeFS доступна сегодня и соответствует самым важным требованиям для Edge / Fog вычислений – безопасность данных, снижение затрат и производительность.

EdgeFS использует локально доступные ресурсы сайта и представляет их как высокодоступный кластерный сегмент, который является частью географически децентрализованного слоя данных.

Выдающиеся характеристики производительности локального сайта достигаются благодаря неизменной структуре структуры данных, динамическому размещению данных по протоколу на основе UDP с малой задержкой, встроенным многопротокольным шлюзом хранения (S3, NoSQL DB, NFS, iSCSI и так далее) и высокой масштабируемости архитектуры без совместного использования ресурсов может стать настоящим средством поддержки приложений, разработанных для эры Edge / Fog.

Попробуйте сегодня! Запустите наш репозиторий GitHub и дайте мне знать, что вы думаете?

Узнайте больше, присоединившись к нашему растущему сообществу на http://edgefs.io и http://rook.io