Jump to content

Распределенная файловая система для облака

Распределенная файловая система для облака — это файловая система , которая позволяет множеству клиентов иметь доступ к данным и поддерживает операции (создание, удаление, изменение, чтение, запись) над этими данными. Каждый файл данных может быть разделен на несколько частей, называемых частями . Каждый фрагмент может храниться на разных удаленных машинах, что облегчает параллельное выполнение приложений. Обычно данные хранятся в файлах в иерархическом дереве , где узлы представляют каталоги. Существует несколько способов совместного использования файлов в распределенной архитектуре: каждое решение должно подходить для определенного типа приложения, в зависимости от того, насколько сложно приложение. При этом безопасность системы должна быть обеспечена. Конфиденциальность , доступность и целостность являются основными ключами к безопасной системе.

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

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

Сегодня существует множество реализаций распределенных файловых систем. Первые файловые серверы были разработаны исследователями в 1970-х годах. Sun Microsystem Сетевая файловая система стала доступна в 1980-х годах. До этого люди, которые хотели поделиться файлами, использовали метод сникернета , физически перенося файлы на носителях с места на место. Когда компьютерные сети начали распространяться, стало очевидно, что существующие файловые системы имеют множество ограничений и непригодны для многопользовательских сред. Первоначально пользователи использовали FTP для обмена файлами. [1] FTP впервые заработал на PDP-10 в конце 1973 года. Даже при использовании FTP файлы нужно было копировать с исходного компьютера на сервер, а затем с сервера на целевой компьютер. Пользователи должны были знать физические адреса всех компьютеров, участвующих в обмене файлами. [2]

Вспомогательные методы

[ редактировать ]

Современные центры обработки данных должны поддерживать большие гетерогенные среды, состоящие из большого количества компьютеров различной мощности. Облачные вычисления координируют работу всех таких систем с помощью таких методов, как сети центров обработки данных (DCN), платформа MapReduce , которая поддерживает вычислительные приложения с интенсивным использованием данных в параллельных и распределенных системах, а также методы виртуализации , которые обеспечивают динамическое распределение ресурсов, позволяя выполнять несколько операций. системы могут сосуществовать на одном физическом сервере.

Приложения

[ редактировать ]

Облачные вычисления обеспечивают крупномасштабные вычисления благодаря своей способности предоставлять пользователю необходимые ресурсы ЦП и хранилища с полной прозрачностью. Это делает облачные вычисления особенно подходящими для поддержки различных типов приложений, требующих крупномасштабной распределенной обработки. Для таких вычислений с интенсивным использованием данных требуется высокопроизводительная файловая система , которая может обмениваться данными между виртуальными машинами (ВМ). [3]

Облачные вычисления динамически распределяют необходимые ресурсы, освобождая их после завершения задачи, требуя от пользователей платить только за необходимые услуги, часто посредством соглашения об уровне обслуживания . Парадигмы облачных вычислений и кластерных вычислений становятся всё более важными для промышленной обработки данных и научных приложений, таких как астрономия и физика, которые часто требуют наличия большого количества компьютеров для проведения экспериментов. [4]

Архитектуры

[ редактировать ]

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

Клиент-серверная архитектура

[ редактировать ]

Сетевая файловая система (NFS) использует архитектуру клиент-сервер , которая позволяет совместно использовать файлы между несколькими компьютерами в сети, как если бы они были расположены локально, обеспечивая стандартизированное представление. Протокол NFS позволяет разнородным клиентским процессам, возможно, работающим на разных машинах и в разных операционных системах, получать доступ к файлам на удаленном сервере, игнорируя фактическое расположение файлов. Использование одного сервера приводит к тому, что протокол NFS страдает от потенциально низкой доступности и плохой масштабируемости. Использование нескольких серверов не решает проблему доступности, поскольку каждый сервер работает независимо. [5] Модель NFS представляет собой удаленный файловый сервис. Эту модель также называют моделью удаленного доступа, в отличие от модели загрузки/выгрузки:

  • Модель удаленного доступа: обеспечивает прозрачность, клиент имеет доступ к файлу. Он отправляет запросы к удаленному файлу (при этом файл остается на сервере). [6]
  • Модель загрузки/выгрузки: клиент может получить доступ к файлу только локально. Это означает, что клиент должен загрузить файл, внести изменения и загрузить его снова, чтобы его могли использовать другие клиенты.

Файловая система, используемая NFS, почти такая же, как и в системах Unix . Файлы иерархически организованы в граф именования, в котором каталоги и файлы представлены узлами.

Кластерные архитектуры

[ редактировать ]

Архитектура на основе кластера устраняет некоторые проблемы клиент-серверной архитектуры, улучшая параллельное выполнение приложений. Используемый здесь метод — чередование файлов: файл разбивается на несколько фрагментов, которые «распределяются» по нескольким серверам хранения. Цель состоит в том, чтобы разрешить параллельный доступ к различным частям файла. Если приложение не получит пользы от этого метода, то было бы удобнее хранить разные файлы на разных серверах. Однако когда дело доходит до организации распределенной файловой системы для крупных центров обработки данных, таких как Amazon и Google, которые предлагают веб-клиентам услуги, позволяющие выполнять несколько операций (чтение, обновление, удаление...) с большим количеством файлов, распределенных между большое количество компьютеров, то кластерные решения становятся более выгодными. Обратите внимание, что большое количество компьютеров может означать большее количество сбоев оборудования. [7] Двумя наиболее широко используемыми распределенными файловыми системами (DFS) этого типа являются файловая система Google (GFS) и распределенная файловая система Hadoop (HDFS). Файловые системы обоих реализуются процессами пользовательского уровня, работающими поверх стандартной операционной системы ( Linux в случае GFS). [8]

Принципы проектирования

[ редактировать ]

Файловая система Google (GFS) и Распределенная файловая система Hadoop (HDFS) специально созданы для пакетной обработки очень больших наборов данных. Для этого необходимо принять во внимание следующие гипотезы: [9]

  • Высокая доступность: кластер может содержать тысячи файловых серверов, и некоторые из них могут выйти из строя в любой момент.
  • Сервер принадлежит стойке, комнате, дата-центру, стране и континенту, чтобы точно определить его географическое положение.
  • Размер файла может варьироваться от многих гигабайт до многих терабайт. Файловая система должна поддерживать огромное количество файлов.
  • Необходимость поддержки операций добавления и обеспечения видимости содержимого файла даже во время записи файла.
  • Связь между рабочими машинами надежна: TCP/IP используется с абстракцией связи удаленного вызова процедур RPC . TCP позволяет клиенту практически сразу узнать, когда возникла проблема и необходимо установить новое соединение. [10]
Балансировка нагрузки
[ редактировать ]

Балансировка нагрузки необходима для эффективной работы в распределенных средах. Это означает распределение работы между разными серверами, [11] справедливо, чтобы выполнить больше работы за то же время и быстрее обслуживать клиентов. В системе, содержащей N серверов фрагментов в облаке (N равно 1000, 10000 или более), где хранится определенное количество файлов, каждый файл разбивается на несколько частей или фрагментов фиксированного размера (например, 64 мегабайта), загрузка каждого сервера фрагментов пропорциональна количеству фрагментов, размещенных на сервере. [12] В облаке с балансировкой нагрузки ресурсы могут использоваться эффективно, одновременно обеспечивая максимальную производительность приложений на основе MapReduce.

Ребалансировка нагрузки
[ редактировать ]

В среде облачных вычислений сбои являются нормой. [13] [14] а серверы фрагментов можно обновлять, заменять и добавлять в систему. Файлы также можно динамически создавать, удалять и добавлять. Это приводит к дисбалансу нагрузки в распределенной файловой системе, а это означает, что фрагменты файлов распределяются между серверами неравномерно.

Распределенные файловые системы в облаках, такие как GFS и HDFS, полагаются на центральные или главные серверы или узлы (Master для GFS и NameNode для HDFS) для управления метаданными и балансировки нагрузки. Мастер периодически перебалансирует реплики: данные необходимо перемещать с одного DataNode/сервера фрагментов на другой, если свободное пространство на первом сервере падает ниже определенного порога. [15] Однако этот централизованный подход может стать узким местом для этих главных серверов, если они не смогут управлять большим количеством обращений к файлам, поскольку это увеличивает их и без того большую нагрузку. Проблема перебалансировки нагрузки является NP-сложной . [16]

Чтобы обеспечить совместную работу большого количества серверов фрагментов и решить проблему балансировки нагрузки в распределенных файловых системах, было предложено несколько подходов, таких как перераспределение фрагментов файлов так, чтобы фрагменты могли быть распределены как можно более равномерно, при этом максимально снизить стоимость перемещения. [12]

файловая система Гугл

[ редактировать ]
Описание
[ редактировать ]

Google, одна из крупнейших интернет-компаний, создала собственную распределенную файловую систему под названием Google File System (GFS), чтобы удовлетворить быстро растущие потребности Google в обработке данных, и она используется для всех облачных сервисов. GFS — это масштабируемая распределенная файловая система для приложений с интенсивным использованием данных. Он обеспечивает отказоустойчивое высокопроизводительное хранилище данных, к которому одновременно обращается большое количество клиентов.

GFS использует MapReduce , который позволяет пользователям создавать программы и запускать их на нескольких машинах, не задумываясь о проблемах распараллеливания и балансировки нагрузки. Архитектура GFS основана на наличии одного главного сервера для нескольких серверов фрагментов и нескольких клиентов. [17]

Главный сервер, работающий на выделенном узле, отвечает за координацию ресурсов хранения и управление метаданными файлов (эквивалент, например, индексных дескрипторов в классических файловых системах). [9] Каждый файл разбит на несколько частей по 64 мегабайта. Каждый чанк хранится на сервере фрагментов. Чанк идентифицируется дескриптором чанка, который представляет собой глобальный уникальный 64-битный номер, который назначается мастером при первом создании чанка.

Мастер поддерживает все метаданные файлов, включая имена файлов, каталоги и сопоставление файлов со списком фрагментов, содержащих данные каждого файла. Метаданные хранятся в основной памяти главного сервера вместе с отображением файлов на фрагменты. Обновления этих данных записываются в журнал операций на диске. Этот журнал операций реплицируется на удаленные машины. Когда журнал становится слишком большим, создается контрольная точка, и данные основной памяти сохраняются в структуре B-дерева , чтобы облегчить отображение обратно в основную память. [18]

Отказоустойчивость
[ редактировать ]

Для повышения отказоустойчивости каждый фрагмент реплицируется на несколько (по умолчанию три) серверов фрагментов. [19] Чанк доступен по крайней мере на одном сервере фрагментов. Преимущество этой схемы – простота. Мастер отвечает за выделение серверов фрагментов для каждого фрагмента, и к нему обращаются только для получения метаданных. Для всех остальных данных клиент должен взаимодействовать с серверами фрагментов.

Мастер отслеживает, где находится чанк. Однако он не пытается точно поддерживать расположение фрагментов, а лишь время от времени обращается к серверам фрагментов, чтобы узнать, какие фрагменты они сохранили. [20] Это обеспечивает масштабируемость и помогает предотвратить узкие места из-за увеличения рабочей нагрузки. [21]

В GFS большинство файлов изменяются путем добавления новых данных, а не перезаписи существующих данных. После записи файлы обычно читаются только последовательно, а не в случайном порядке, и это делает эту DFS наиболее подходящей для сценариев, в которых много больших файлов создаются один раз, но читаются много раз. [22] [23]

Обработка файлов
[ редактировать ]

Когда клиент хочет записать/обновить файл, мастер назначит реплику, которая будет первичной репликой, если это первая модификация. Процесс написания состоит из двух этапов: [9]

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

Следовательно, мы можем различать два типа потоков: поток данных и поток управления. Поток данных связан с фазой отправки, а поток управления связан с фазой записи. Это гарантирует, что основной сервер фрагментов возьмет на себя управление порядком записи. Обратите внимание, что когда мастер назначает операцию записи реплике, он увеличивает номер версии фрагмента и сообщает всем репликам, содержащим этот фрагмент, номер новой версии. Номера версий фрагментов позволяют обнаружить ошибки обновления, если реплика не была обновлена ​​из-за отказа ее сервера фрагментов. [24]

Некоторые новые приложения Google плохо работали с размером фрагмента в 64 мегабайта. Чтобы решить эту проблему, GFS в 2004 году начала внедрять подход Bigtable . [25]

Распределенная файловая система Hadoop

[ редактировать ]

HDFS , разработанная Apache Software Foundation , представляет собой распределенную файловую систему, предназначенную для хранения очень больших объемов данных (терабайтов или даже петабайтов). Его архитектура аналогична GFS, т.е. архитектура сервер/клиент. HDFS обычно устанавливается в кластере компьютеров. Концепция дизайна Hadoop основана на Google: файловая система Google, Google MapReduce и Bigtable реализуется распределенной файловой системой Hadoop (HDFS), Hadoop MapReduce и Hadoop Base (HBase) соответственно. [26] Как и GFS, HDFS подходит для сценариев с доступом к файлам «запись-одна-чтение-много» и поддерживает добавление и усечение файлов вместо случайного чтения и записи, чтобы упростить проблемы согласованности данных. [27]

Кластер HDFS состоит из одного NameNode и нескольких компьютеров DataNode. NameNode, главный сервер, управляет и поддерживает метаданные хранилища DataNodes в своей оперативной памяти. DataNodes управляют хранилищем, прикрепленным к узлам, на которых они работают. NameNode и DataNode — это программное обеспечение, предназначенное для работы на машинах повседневного использования, которые обычно работают под управлением ОС Linux. HDFS можно запустить на любом компьютере, поддерживающем Java, и, следовательно, на нем можно запускать либо NameNode, либо программное обеспечение Datanode. [28]

В кластере HDFS файл разбивается на один или несколько блоков одинакового размера, за исключением того, что последний блок может быть меньше. Каждый блок хранится в нескольких узлах данных, и каждый из них может быть реплицирован на несколько узлов данных, чтобы гарантировать доступность. По умолчанию каждый блок реплицируется три раза, этот процесс называется «Репликация на уровне блоков». [29]

NameNode управляет операциями пространства имен файловой системы, такими как открытие, закрытие и переименование файлов и каталогов, а также регулирует доступ к файлам. Он также определяет сопоставление блоков с узлами данных. DataNodes отвечают за обслуживание запросов на чтение и запись от клиентов файловой системы, управление выделением или удалением блоков, а также репликацию блоков. [30]

Когда клиент хочет прочитать или записать данные, он связывается с NameNode, и NameNode проверяет, откуда данные следует читать или куда записывать. После этого клиент получает местоположение DataNode и может отправлять к нему запросы на чтение или запись.

HDFS обычно характеризуется совместимостью со схемами ребалансировки данных. В общем, управление свободным пространством на DataNode очень важно. Данные необходимо переместить из одного DataNode в другой, если свободного места недостаточно; а в случае создания дополнительных реплик данные следует переместить, чтобы обеспечить баланс системы. [29]

Другие примеры

[ редактировать ]

Распределенные файловые системы можно оптимизировать для разных целей. Некоторые из них, например, разработанные для интернет-сервисов, включая GFS, оптимизированы для масштабируемости. Другие конструкции распределенных файловых систем поддерживают ресурсоемкие приложения, обычно выполняемые параллельно. [31] Некоторые примеры включают: файловую систему MapR (MapR-FS), Ceph-FS , файловую систему Фраунгофера (BeeGFS) , файловую систему Lustre , общую параллельную файловую систему IBM (GPFS) и параллельную виртуальную файловую систему .

MapR-FS — это распределенная файловая система, лежащая в основе конвергентной платформы MapR, с возможностями распределенного хранения файлов, базой данных NoSQL с несколькими API-интерфейсами и интегрированной системой потоковой передачи сообщений. MapR-FS оптимизирован для масштабируемости, производительности, надежности и доступности. Его возможности хранения файлов совместимы с API распределенной файловой системы Apache Hadoop (HDFS), но имеют несколько конструктивных особенностей, которые отличают его от HDFS. Среди наиболее заметных отличий заключается в том, что MapR-FS — это файловая система с полным доступом для чтения и записи, метаданные для файлов и каталогов распределены по пространству имен, поэтому NameNode отсутствует. [32] [33] [34] [35] [36]

Ceph-FS — это распределенная файловая система, обеспечивающая отличную производительность и надежность. [37] Он отвечает на задачи работы с огромными файлами и каталогами, координации деятельности тысяч дисков, обеспечения параллельного доступа к метаданным в больших масштабах, управления как научными, так и универсальными рабочими нагрузками, аутентификации и шифрования в больших масштабах, а также увеличения или динамически снижается из-за частого вывода устройств из эксплуатации, сбоев устройств и расширения кластера. [38]

BeeGFS — это высокопроизводительная параллельная файловая система, разработанная Центром высокопроизводительных вычислений Фраунгофера. Архитектура распределенных метаданных BeeGFS была разработана для обеспечения масштабируемости и гибкости, необходимых для запуска HPC и аналогичных приложений с высокими требованиями к вводу-выводу. [39]

Файловая система Lustre была разработана и реализована для решения проблем узких мест, традиционно встречающихся в распределенных системах. Lustre характеризуется эффективностью, масштабируемостью и избыточностью. [40] GPFS также была разработана с целью устранения таких узких мест. [41]

Коммуникация

[ редактировать ]

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

Операции передачи данных (отправка/получение) передают данные из буфера приложения в ядро ​​машины, при этом TCP управляет процессом и реализуется в ядре. Однако в случае перегрузки сети или ошибок TCP может не отправлять данные напрямую. При передаче данных из буфера ядра в приложение машина не считывает поток байтов с удаленной машины. Фактически TCP отвечает за буферизацию данных приложения. [43]

Выбор размера буфера для чтения и записи файлов или отправки и получения файлов осуществляется на уровне приложения. Буфер поддерживается с помощью циклического связанного списка . [44] Он состоит из набора BufferNodes. Каждый BufferNode имеет DataField. DataField содержит данные и указатель NextBufferNode, который указывает на следующий BufferNode. Чтобы найти текущую позицию, используются два указателя : CurrentBufferNode и EndBufferNode, которые представляют позицию в BufferNode для последних позиций записи и чтения. Если в BufferNode нет свободного места, он отправит клиенту сигнал ожидания, чтобы тот дождался, пока не появится свободное место. [45]

Облачная синхронизация распределенной файловой системы

[ редактировать ]

Все больше и больше пользователей имеют несколько устройств с одноранговым подключением. Наборы данных, реплицированные на этих устройствах, необходимо синхронизировать между произвольным количеством серверов. Это полезно для резервного копирования, а также для работы в автономном режиме. Действительно, когда условия пользовательской сети плохие, пользовательское устройство будет выборочно реплицировать часть данных, которые будут изменены позже и в автономном режиме. Как только условия сети станут хорошими, устройство синхронизируется. [46] Существует два подхода к решению проблемы распределенной синхронизации: одноранговая синхронизация, управляемая пользователем, и синхронизация облачной главной реплики. [46]

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

Ключи безопасности

[ редактировать ]

В облачных вычислениях наиболее важными концепциями безопасности являются конфиденциальность , целостность и доступность CIA »). Конфиденциальность становится необходимой для предотвращения раскрытия частных данных. Целостность гарантирует, что данные не будут повреждены. [47]

Конфиденциальность

[ редактировать ]

Конфиденциальность означает, что данные и вычислительные задачи являются конфиденциальными: ни поставщик облачных услуг, ни другие клиенты не могут получить доступ к данным клиента. Было проведено много исследований по вопросам конфиденциальности, поскольку это один из важнейших моментов, который по-прежнему создает проблемы для облачных вычислений. Недостаток доверия к поставщикам облачных услуг также является связанной с этим проблемой. [48] Инфраструктура облака должна гарантировать, что данные клиентов не будут доступны посторонним лицам.

Среда становится небезопасной, если поставщик услуг может сделать все следующее: [49]

  • найти данные потребителя в облаке
  • доступ и получение данных потребителя
  • понимать значение данных (типы данных, функциональные возможности и интерфейсы приложения, а также формат данных).

Географическое расположение данных помогает определить конфиденциальность и конфиденциальность. Следует учитывать местоположение клиентов. Например, клиенты в Европе не будут заинтересованы в использовании дата-центров, расположенных в США, поскольку это влияет на гарантию конфиденциальности данных. Чтобы решить эту проблему, некоторые поставщики облачных вычислений включили географическое местоположение хоста в качестве параметра соглашения об уровне обслуживания, заключенного с клиентом. [50] позволяя пользователям самим выбирать расположение серверов, на которых будут размещаться их данные.

Другой подход к конфиденциальности предполагает шифрование данных. [51] В противном случае возникнет серьезный риск несанкционированного использования. Существует множество решений, таких как шифрование только конфиденциальных данных, [52] и поддерживает только некоторые операции, чтобы упростить вычисления. [53] Кроме того, криптографические методы и инструменты, такие как FHE , используются для сохранения конфиденциальности в облаке. [47]

Честность

[ редактировать ]

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

На целостность данных могут повлиять вредоносные события или ошибки администрирования (например, во время резервного копирования и восстановления, миграции данных или изменения членства в P2P- системах). [54]

Целостности легко добиться с помощью криптографии (обычно с помощью кода аутентификации сообщения или MAC-адресов в блоках данных). [55]

Существуют механизмы проверки, влияющие на целостность данных. Например:

  • HAIL (уровень высокой доступности и целостности) — это распределенная криптографическая система, которая позволяет набору серверов доказывать клиенту, что сохраненный файл не поврежден и его можно восстановить. [56]
  • Hach POR (доказательства возможности восстановления больших файлов) [57] основан на симметричной криптографической системе, в которой существует только один ключ проверки, который необходимо хранить в файле для повышения его целостности. Этот метод служит для шифрования файла F, а затем генерирует случайную строку с именем «дозорный», которую необходимо добавить в конец зашифрованного файла. Сервер не может найти дозорный блок, который невозможно отличить от других блоков, поэтому небольшое изменение укажет, был ли файл изменен или нет.
  • Проверка PDP (доказуемое владение данными) — это класс эффективных и практичных методов, которые обеспечивают эффективный способ проверки целостности данных на ненадежных серверах:
    • ПРП: [58] Прежде чем хранить данные на сервере, клиент должен локально сохранить некоторые метаданные. Позднее, без загрузки данных, клиент может попросить сервер проверить, не были ли данные фальсифицированы. Этот подход используется для статических данных.
    • Масштабируемый PDP: [59] Этот подход основан на симметричном ключе, который более эффективен, чем шифрование с открытым ключом. Он поддерживает некоторые динамические операции (изменение, удаление и добавление), но его нельзя использовать для публичной проверки.
    • Динамический ППД: [60] Этот подход расширяет модель PDP для поддержки нескольких операций обновления, таких как добавление, вставка, изменение и удаление, что хорошо подходит для интенсивных вычислений.

Доступность

[ редактировать ]

Доступность обычно обеспечивается репликацией . [61] [62] [63] [64] При этом необходимо гарантировать последовательность. Однако последовательность и доступность не могут быть достигнуты одновременно; каждому отдается приоритет за счет другого. Необходимо найти баланс. [65]

Чтобы быть доступными, данные должны иметь идентичность. Например, Скут [61] — это механизм, основанный на хранении ключей/значений, который позволяет эффективно распределять динамические данные. Каждый сервер должен быть идентифицирован меткой в ​​виде континент-страна-центр обработки данных-комната-стойка-сервер. Сервер может ссылаться на несколько виртуальных узлов, причем каждый узел имеет набор данных (или несколько разделов нескольких данных). Каждый фрагмент данных идентифицируется пространством ключей, которое генерируется односторонней криптографической хэш-функцией (например, MD5 ) и локализуется по значению хеш-функции этого ключа. Пространство ключей может быть разделено на несколько разделов, каждый из которых относится к фрагменту данных. Для выполнения репликации виртуальные узлы должны быть реплицированы и на них ссылаются другие серверы. Чтобы максимизировать надежность и доступность данных, реплики должны быть размещены на разных серверах, и каждый сервер должен находиться в другом географическом положении, поскольку доступность данных увеличивается с увеличением географического разнообразия. Процесс репликации включает в себя оценку доступности пространства, которая должна быть выше определенного минимального порога на каждом сервере фрагментов. В противном случае данные реплицируются на другой сервер фрагментов. Каждый раздел i имеет значение доступности, представленное следующей формулой:

где это серверы, на которых размещены реплики, и доверие серверов и (опираясь на технические факторы, такие как аппаратные компоненты, и нетехнические факторы, такие как экономическая и политическая ситуация в стране), а разнообразие - это географическое расстояние между и . [66]

Репликация — отличное решение для обеспечения доступности данных, но она требует слишком больших затрат памяти. [67] Дискредуце [67] — это модифицированная версия HDFS, основанная на технологии RAID (RAID-5 и RAID-6) и обеспечивающая асинхронное кодирование реплицируемых данных. Действительно, существует фоновый процесс, который ищет широко реплицируемые данные и удаляет лишние копии после их кодирования. Другой подход заключается в замене репликации стирающим кодированием. [68] Кроме того, для обеспечения доступности данных существует множество подходов, позволяющих восстановить данные. Фактически данные должны быть закодированы, и в случае их утери их можно восстановить из фрагментов, созданных на этапе кодирования. [69] Некоторые другие подходы, в которых применяются различные механизмы для обеспечения доступности: код Рида-Соломона Microsoft Azure и RaidNode для HDFS. Кроме того, Google все еще работает над новым подходом, основанным на механизме стирающего кодирования. [70]

Для облачного хранилища не существует реализации RAID. [68]

Экономические аспекты

[ редактировать ]

Экономика облачных вычислений быстро растет. Правительство США решило потратить 40% совокупного годового темпа роста (CAGR), который, как ожидается, к 2015 году составит 7 миллиардов долларов. [71]

Все больше и больше компаний используют облачные вычисления для управления огромными объемами данных и преодоления нехватки емкости хранилища, а также потому, что это позволяет им использовать такие ресурсы в качестве услуги, гарантируя, что их вычислительные потребности будут удовлетворены без необходимости инвестиций. в инфраструктуре (модель Pay-as-you-go). [72]

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

Модель оплаты по мере использования также облегчила нагрузку на начинающие компании, которые хотят извлечь выгоду из бизнеса с интенсивными вычислениями. Облачные вычисления также открывают возможности для многих стран третьего мира, у которых в противном случае не было бы таких вычислительных ресурсов. Облачные вычисления могут снизить ИТ-барьеры на пути к инновациям. [74]

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

  1. ^ Микросистема Солнца , с. 1
  2. ^ Кон 1996 , стр. 1.
  3. ^ Кобаяши и др. 2011 , с. 1
  4. ^ Ангабини и др. 2011 , с. 1
  5. ^ Ди Сано и др. 2012 , с. 2
  6. ^ Эндрю и Маартен 2006 , с. 492
  7. ^ Эндрю и Маартен 2006 , с. 496
  8. ^ Хумбетов 2012 , с. 2
  9. ^ Перейти обратно: а б с Кшижановский 2012 , с. 2
  10. ^ Павел Бжоч , г-н. 7
  11. ^ Кай и др. 2013 , с. 23
  12. ^ Перейти обратно: а б Сяо и др. 2013 , стр. 2.
  13. ^ Сяо и др. 2013 , с. 952.
  14. ^ Гемават, Гобиофф и Люнг 2003 , стр. 1
  15. ^ Гемават, Гобиофф и Люнг 2003 , стр. 8
  16. ^ Сяо и др. 2013 , с. 953.
  17. ^ Сано и др. 2012 , стр. 1–2
  18. ^ Кржижановский 2012 , с. 4
  19. ^ Ди Сано и др. 2012 , с. 2
  20. ^ Эндрю и Маартен 2006 , с. 497
  21. ^ Хумбетов 2012 , с. 3
  22. ^ Хумбетов 2012 , с. 5
  23. ^ Эндрю и Маартен 2006 , с. 498
  24. ^ Кржижановский 2012 , с. 5
  25. ^ «Большой диск в небе: как веб-гиганты хранят большие — мы имеем в виду большие — данные» . 27 января 2012 г.
  26. ^ Фань-Сюнь и др. 2012 , с. 2
  27. ^ «Apache Hadoop 2.9.2 — архитектура HDFS» .
  28. ^ Аззедин 2013 , с. 2
  29. ^ Перейти обратно: а б Адамов 2012 , с. 2
  30. ^ Йи и Ту Наинг 2011 , с. 122
  31. ^ Соарес и др. 2013 , с. 158
  32. ^ Перес, Николас (2 января 2016 г.). «Как MapR повышает нашу производительность и упрощает проектирование» . Середина . Проверено 21 июня 2016 г.
  33. ^ Вуди, Алекс (08 марта 2016 г.). «От Hadoop к Zeta: внутри конвергентного преобразования MapR» . Датанами . Табор Коммуникейшнз Инк . Проверено 21 июня 2016 г.
  34. ^ Бреннан, Боб. «Саммит флэш-памяти» . ютуб . Samsung . Проверено 21 июня 2016 г.
  35. ^ Шривас, MC. «Файловая система MapR» . Саммит Hadoop 2011 . Хортонворкс . Проверено 21 июня 2016 г.
  36. ^ Даннинг, Тед; Фридман, Эллен (январь 2015 г.). «Глава 3: Понимание дистрибутива MapR для Apache Hadoop» . Реальный мир Hadoop (первое изд.). Севастополь, Калифорния: O'Reilly Media, Inc., стр. 23–28. ISBN  978-1-4919-2395-5 . Проверено 21 июня 2016 г.
  37. ^ Вейль и др. 2006 , с. 307
  38. ^ Мальцан и др. 2010 , с. 39
  39. ^ Якоби и Лингеманн , с. 10
  40. ^ Лебедь Филипп 2003 , с. 401
  41. ^ Джонс, Кенигес и Йейтс 2000 , с. 1
  42. ^ Упадхьяя и др. 2008 , с. 400
  43. ^ Упадхьяя и др. 2008 , с. 403
  44. ^ Упадхьяя и др. 2008 , с. 401
  45. ^ Упадхьяя и др. 2008 , с. 402
  46. ^ Перейти обратно: а б Uppoor, Flowers & Bilas 2010 , с. 1
  47. ^ Перейти обратно: а б Чжифэн и Ян 2013 , с. 854
  48. ^ Чжифэн и Ян 2013 , стр. 845–846
  49. ^ Яу и Ан 2010 , с. 353
  50. ^ Векчиола, Пандей и Буйя 2009 , стр. 14
  51. ^ Яу и Ан 2010 , с. 352
  52. ^ Миранда и Сиани, 2009 г.
  53. ^ Наериг и Лаутер, 2013 г.
  54. ^ Чжифэн и Ян 2013 , с. 5
  55. ^ Джуэлс и Опрея 2013 , с. 4
  56. ^ Бауэрс, Джулс и Опрея, 2009 г.
  57. ^ Джулс и С. Калиски 2007 , стр. 2.
  58. ^ Афинский и др. 2007 год
  59. ^ Афинский и др. 2008 , с. 5, 9
  60. ^ Эрвей и др. 2009 , с. 2
  61. ^ Перейти обратно: а б Бонвин, Папайоанну и Аберер, 2009 г. , с. 206
  62. ^ Куонг и др. 2012 , с. 5
  63. ^ А., А. и П. 2011 , с. 3
  64. ^ Цянь, Д. и Т. 2011 , с. 3
  65. ^ Фогельс 2009 , с. 2
  66. ^ Бонвин, Папайоанну и Аберер 2009 , стр. 208
  67. ^ Перейти обратно: а б Карнеги и др. 2009 , с. 1
  68. ^ Перейти обратно: а б Ван и др. 2012 , стр. 1.
  69. ^ Абу-Либде, Princehouse & Weatherspoon 2010 , стр. 2
  70. ^ Ван и др. 2012 , стр. 9.
  71. ^ Лори М. Кауфман 2009 , с. 2
  72. ^ Ангабини и др. 2011 , с. 1
  73. ^ Бонвин, Папайоанну и Аберер 2009 , стр. 3
  74. ^ Марстон и др. 2011 , с. 3

Библиография

[ редактировать ]
  1. Архитектура, структура и дизайн:
    • Чжан, Ци-фэй; Пан, Сюэ-цзэн; Шен, Ян; Ли, Вэнь-цзюань (2012). «Новая масштабируемая архитектура облачной системы хранения небольших файлов на основе P2P». Семинары Международной конференции IEEE по кластерным вычислениям , 2012 г. Колл. вычислительной техники. наук. и технологии, Чжэцзянский университет, Ханчжоу, Китай. п. 41. дои : 10.1109/ClusterW.2012.27 . ISBN  978-0-7695-4844-9 . S2CID   12430485 .
    • Аззедин, Фараг (2013). «На пути к масштабируемой архитектуре HDFS». 2013 Международная конференция по технологиям и системам совместной работы (CTS) . Факультет информации и компьютерных наук Университета нефти и полезных ископаемых имени короля Фахда. стр. 155–161. дои : 10.1109/CTS.2013.6567222 . ISBN  978-1-4673-6404-1 . S2CID   45293053 .
    • Кшижановский, Пол (2012). «Распределенные файловые системы» (PDF) . Архивировано из оригинала (PDF) 27 декабря 2013 г. Проверено 27 декабря 2013 г.
    • Кобаяши, К; Миками, С; Кимура, Х; Татебе, О (2011). Файловая система Gfarm в вычислительных облаках . Семинары по параллельной и распределенной обработке и докторский форум (IPDPSW), Международный симпозиум IEEE 2011 г. по . Град. Щ. системы & Инф. инженер, унив. Цукуба, Цукуба, Япония. дои : 10.1109/IPDPS.2011.255 .
    • Гумбетов, Шамиль (2012). «Вычисления с интенсивным использованием данных с помощью Map-Reduce и Hadoop». 2012 6-я Международная конференция по применению информационных и коммуникационных технологий (AICT) . Кафедра компьютерной инженерии Кавказского университета Баку, Азербайджан. стр. 1–5. дои : 10.1109/ICAICT.2012.6398489 . ISBN  978-1-4673-1740-5 . S2CID   6113112 .
    • Сяо, Хун-Чанг; Чунг, Сюэ-И; Шен, Хайин; Чао, Ю-Чанг (2013). «Ребалансировка нагрузки для распределенных файловых систем в облаках». Параллельные и распределенные системы, транзакции IEEE на . 24 (5). Национальный университет Ченг Кунг, Тайнань: 951–962. дои : 10.1109/TPDS.2012.196 . S2CID   11271386 .
    • Кай, Фан; Даян, Чжан; Хуэй, Ли; Иньтан, Ян (2013). «Алгоритм балансировки нагрузки с адаптивной обратной связью в HDFS». 2013 5-я Международная конференция по интеллектуальным сетям и системам совместной работы . Государственная ключевая лаборатория. Сети интегрированного обслуживания, Университет Сидиан, Сиань, Китай. стр. 23–29. дои : 10.1109/INCoS.2013.14 . ISBN  978-0-7695-4988-0 . S2CID   14821266 .
    • Упадхьяя, Б; Азимов, Ф; Доан, ТТ; Чхве, Ынми; Ким, Санбум; Ким, Пилсунг (2008). «Распределенная файловая система: эксперименты по повышению эффективности доступа к данным и связи». 2008 Четвертая Международная конференция по сетевым вычислениям и передовому управлению информацией . Щ. автобуса. ИТ, Университет Кукмин, Сеул. стр. 400–405. дои : 10.1109/NCM.2008.164 . ISBN  978-0-7695-3322-3 . S2CID   18933772 .
    • Соареш, Тьяго С.; Дантас†, МарАР; де Маседо, Дуглас диджей; Бауэр, Майкл А. (2013). «Управление данными в частной облачной среде хранения с использованием высокопроизводительных распределенных файловых систем». Семинары 2013 г. по перспективным технологиям: инфраструктура для совместных предприятий . нф. и статистический департамент (INE), Федеральная резервная система. унив. Санта-Катарина (UFSC), Флорианополис, Бразилия. стр. 158–163. дои : 10.1109/WETICE.2013.12 . ISBN  978-1-4799-0405-1 . S2CID   6155753 .
    • Адамов, Абзетдин (2012). «Распределенная файловая система как основа вычислений с интенсивным использованием данных». 2012 6-я Международная конференция по применению информационных и коммуникационных технологий (AICT) . Вычислить. англ. Кафедра Кавказского университета, Баку, Азербайджан. стр. 1–3. дои : 10.1109/ICAICT.2012.6398484 . ISBN  978-1-4673-1740-5 . S2CID   16674289 .
    • Шван Филип (2003). «Lustre: создание файловой системы для кластеров из 1000 узлов» (PDF) . Материалы симпозиума Linux 2003 года . Кластерные файловые системы, Inc.: 400–407.
    • Джонс, Терри; Конигес, Алиса; Йейтс, Р. Ким (2000). «Производительность общей параллельной файловой системы IBM» (PDF) . Симпозиум по параллельной и распределенной обработке, 2000. IPDPS 2000. Труды. 14-й Интернационал . Ливерморская национальная лаборатория Лоуренса. Архивировано из оригинала (PDF) 26 февраля 2013 г. Проверено 24 января 2014 г.
    • Вейль, Сейдж А.; Брандт, Скотт А.; Миллер, Итан Л.; Лонг, Даррелл Д.Э. (2006). Ceph: Масштабируемая, высокопроизводительная распределенная файловая система (PDF) . Материалы 7-й конференции по проектированию и внедрению операционных систем (OSDI '06). Архивировано из оригинала (PDF) 9 марта 2012 г. Проверено 24 января 2014 г.
    • Мальцан, Карлос; Молина-Эстолано, Эстебан; Хурана, Амандип; Нельсон, Алекс Дж.; Брандт, Скотт А.; Вейль, Мудрец (2010). Ceph как масштабируемая альтернатива распределенной файловой системе Hadoop (PDF) (отчет).
    • С.А., Брандт; ЭЛ, Миллер; ДДЕ, длинный; Лан, Сюэ (2003). «Эффективное управление метаданными в больших распределенных системах хранения». 20-я Годдардская конференция IEEE/НАСА по системам и технологиям хранения данных, 2003 г. (MSST 2003). Слушания . Система хранения. Рез. Центр, Калифорнийский университет, Санта-Круз, Калифорния, США. стр. 290–298. CiteSeerX   10.1.1.13.2537 . дои : 10.1109/MASS.2003.1194865 . ISBN  978-0-7695-1914-2 . S2CID   5548463 .
    • Гарт А., Гибсон; Родни, MVan Meter (ноябрь 2000 г.). «Архитектура сетевого хранилища» (PDF) . Коммуникации АКМ . 43 (11): 37–45. дои : 10.1145/353360.353362 . S2CID   207644891 .
    • Да, Тин Тин; Ту Наинг, Тинн (2011). «Архитектура системы хранения данных на основе кластера ПК для облачного хранилища». arXiv : 1112.2025 [ cs.DC ].
    • Чо Чо, Хаинг; Тинн Ту, Наинг (2011). «Эффективная система управления хранением данных в кластерном частном облачном центре обработки данных». Международная конференция IEEE 2011 по облачным вычислениям и интеллектуальным системам . стр. 235–239. дои : 10.1109/CCIS.2011.6045066 . ISBN  978-1-61284-203-5 . S2CID   224635 .
    • С.А., Брандт; ЭЛ, Миллер; ДДЕ, длинный; Лан, Сюэ (2011). «Сервис-ориентированная архитектура хранения файлов операторского уровня для облачных вычислений». 2011 3-й симпозиум по веб-сообществу . Центр PCN&CAD Пекинского университета. Почты и телекоммуникаций, Пекин, Китай. стр. 16–20. дои : 10.1109/SWS.2011.6101263 . ISBN  978-1-4577-0211-2 . S2CID   14791637 .
    • Гемават, Санджай; Гобиофф, Ховард; Люн, Шун-Так (2003). «Файловая система Google» . Материалы девятнадцатого симпозиума ACM по принципам операционных систем - SOSP '03 . стр. 29–43. дои : 10.1145/945445.945450 . ISBN  978-1-58113-757-6 . S2CID   221261373 .
  2. Безопасность
    • Веккьола, К; Панди, С; Буя, Р. (2009). «Высокопроизводительные облачные вычисления: взгляд на научные приложения». 2009 10-й Международный симпозиум по всеобъемлющим системам, алгоритмам и сетям . Департамент вычислительной техники. наук. и инженер-программное обеспечение, унив. Мельбурн, Мельбурн, Виктория, Австралия. стр. 4–16. arXiv : 0910.1979 . дои : 10.1109/I-SPAN.2009.150 . ISBN  978-1-4244-5403-7 . S2CID   1810240 .
    • Миранда, Моубрей; Сиани, Пирсон (2009). «Клиентский менеджер конфиденциальности для облачных вычислений». Материалы четвертой Международной конференции ICST по программному и промежуточному обеспечению коммуникационных систем – COMSWARE '09 . п. 1. дои : 10.1145/1621890.1621897 . ISBN  978-1-60558-353-2 . S2CID   10130310 .
    • Наэриг, Майкл; Лаутер, Кристин (2013). «Может ли гомоморфное шифрование быть практичным?». Материалы 3-го семинара ACM по безопасности облачных вычислений — CCSW '11 . стр. 113–124. CiteSeerX   10.1.1.225.8007 . дои : 10.1145/2046660.2046682 . ISBN  978-1-4503-1004-8 . S2CID   12274859 .
    • Ду, Хунтао; Ли, Чжаньхуай (2012). «PsFS: параллельная файловая система с высокой пропускной способностью для безопасной системы облачного хранилища». 2012 Международная конференция по измерению, информации и контролю (MIC) . Том. 1. Вычислить. Сб., Северо-Западный политех. Университет, Сиань, Китай. стр. 327–331. дои : 10.1109/MIC.2012.6273264 . ISBN  978-1-4577-1604-1 . S2CID   40685246 .
    • А.Брандт, Скотт; Л.Миллер, Итан; ДЭЛонг, Даррелл; Сюэ, Лан (2003). «Эффективное управление метаданными в больших распределенных системах хранения» (PDF) . 11-я Годдардская конференция НАСА по системам и технологиям хранения данных, Сан-Диего, Калифорния . Исследовательский центр систем хранения данных Калифорнийского университета, Санта-Круз. Архивировано из оригинала (PDF) 22 августа 2013 г. Проверено 27 декабря 2013 г.
    • Лори М. Кауфман (2009). «Безопасность данных в мире облачных вычислений». Безопасность и конфиденциальность, IEEE . 7 (4): 161–64. дои : 10.1109/MSP.2009.87 . S2CID   16233643 .
    • Бауэрс, Кевин; Джулс, Ари; Опря, Алина (2009). «HAIL: уровень высокой доступности и целостности для облачного хранилища». Материалы 16-й конференции ACM «Компьютерная и коммуникационная безопасность» . стр. 187–198. дои : 10.1145/1653662.1653686 . ISBN  978-1-60558-894-0 . S2CID   207176701 .
    • Джулс, Ари; Опря, Алина (февраль 2013 г.). «Новые подходы к безопасности и доступности облачных данных». Коммуникации АКМ . 56 (2): 64–73. дои : 10.1145/2408776.2408793 . S2CID   17596621 .
    • Чжан, Цзин; У, Гунцин; Ху, Сюэган; Ву, Синьдун (2012). «Распределенный кэш для распределенной файловой системы Hadoop в облачных службах реального времени». 2012 13-я Международная конференция ACM/IEEE по грид-вычислениям . Департамент вычислительной техники. наук, Университет Хэфэй. технологий., Хэфэй, Китай. стр. 12–21. дои : 10.1109/Grid.2012.17 . ISBN  978-1-4673-2901-9 . S2CID   10778240 .
    • А., Пан; Дж. П., Уолтерс; В.С., Пай; Д.-ИД, Канг; СП, Краго (2012). «Интеграция высокопроизводительных файловых систем в среду облачных вычислений». 2012 SC Companion: Высокопроизводительные вычисления, сетевое хранилище и анализ . Отдел электрики. И компьютер. инженер, Университет Пердью, Вест-Лафайет, Индиана, США. стр. 753–759. дои : 10.1109/SC.Companion.2012.103 . ISBN  978-0-7695-4956-9 . S2CID   5554936 .
    • Фань-Сюнь, Цэн; Чи-Юань, Чен; Ли-Дер, Чжоу; Хан-Чье, Чао (2012). «Внедрение надежной и безопасной облачной распределенной файловой системы». 2012 Международный симпозиум по интеллектуальным системам обработки сигналов и связи . Департамент вычислительной техники. наук. & Инф. англ., физ. Центральный университет, Таоюань, Тайвань. стр. 227–232. дои : 10.1109/ISPACS.2012.6473485 . ISBN  978-1-4673-5082-2 . S2CID   18260943 .
    • Ди Сано, М; Ди Стефано, А; Морана, Дж; Зито, Д. (2012). «Файловая система как услуга: предоставление временных и согласованных представлений файлов для взаимодействующих приложений в облаках». 2012 IEEE 21-й международный семинар по перспективным технологиям: инфраструктура для совместных предприятий . Кафедра электрики, Электрон. И компьютер. инженер, унив. Катания, Катания, Италия. стр. 173–178. дои : 10.1109/WETICE.2012.104 . ISBN  978-1-4673-1888-4 . S2CID   19798809 .
    • Чжифэн, Сяо; Ян, Сяо (2013). «Безопасность и конфиденциальность в облачных вычислениях». Обзоры и учебные пособия IEEE по коммуникациям . 15 (2): 843–859. CiteSeerX   10.1.1.707.3980 . дои : 10.1109/SURV.2012.060912.00182 . S2CID   206583820 .
    • Джон Б., Хорриган (2008). «Использование приложений и услуг облачных вычислений» (PDF) . Архивировано из оригинала (PDF) 12 июля 2013 г. Проверено 27 декабря 2013 г.
    • Яу, Стивен; Ан, Хо (2010). «Защита конфиденциальности в системах облачных вычислений» . Int J Software Информатика : 351–365.
    • Карнеги, Бин Фан; Тантисириродж, Виттават; Сяо, Линь; Гибсон, Гарт (2009). «DiskReduce: RAID для масштабируемых вычислений с интенсивным использованием данных». Материалы 4-го ежегодного семинара по петамасштабному хранению данных . стр. 6–10. дои : 10.1145/1713072.1713075 . ISBN  978-1-60558-883-4 . S2CID   15194567 .
    • Ван, Цзяньцзун; Гун, Вэйцзяо; П., Варман; Се, Чаншэн (2012). «Сокращение накладных расходов на хранилище за счет исключения небольших узких мест при записи в облачной RAID-системе». 2012 13-я Международная конференция ACM/IEEE по грид-вычислениям . стр. 174–183. дои : 10.1109/Grid.2012.29 . ISBN  978-1-4673-2901-9 . S2CID   16827141 .
    • Абу-Либде, Хусам; Принсхаус, Лонни; Уэзерспун, Хаким (2010). «RACS: аргументы в пользу разнообразия облачных хранилищ». Материалы 1-го симпозиума ACM по облачным вычислениям . стр. 229–240. дои : 10.1145/1807128.1807165 . ISBN  978-1-4503-0036-0 . S2CID   1283873 .
    • Фогельс, Вернер (2009). «В конечном итоге последовательно» . Коммуникации АКМ . 52 (1): 40–44. дои : 10.1145/1435417.1435432 .
    • Куонг, Фам; Цао, Фуонг; Калбарчик, З; Айер, РК (2012). «На пути к облаку высокой доступности: методы и проблемы». Семинары Международной конференции IEEE/IFIP по надежным системам и сетям (DSN 2012) . стр. 1–6. дои : 10.1109/DSNW.2012.6264687 . ISBN  978-1-4673-2266-9 . S2CID   9920903 .
    • А., Ундхейм; А., Чилван; П., Хигор (2011). «Дифференцированная доступность в соглашениях об уровне обслуживания облачных вычислений». 2011 12-я Международная конференция IEEE/ACM по грид-вычислениям . стр. 129–136. дои : 10.1109/Grid.2011.25 . ISBN  978-1-4577-1904-2 . S2CID   15047580 .
    • Цянь, Хайян; Д., Медхи; Т., Триведи (2011). «Иерархическая модель для оценки качества работы онлайн-сервисов, размещенных на облачных вычислениях». Коммуникации АКМ . 52 (1): 105–112. CiteSeerX   10.1.1.190.5148 . дои : 10.1109/INM.2011.5990680 . S2CID   15912111 .
    • Атенезе, Джузеппе; Бернс, Рэндал; Куртмола, Реза; Сельдь, Джозеф; Кисснер, Леа; Петерсон, Закари; Песня, Рассвет (2007). «Доказуемое хранение данных в ненадежных магазинах». Материалы 14-й конференции ACM «Компьютерная и коммуникационная безопасность – CCS '07» . стр. 598–609. дои : 10.1145/1315245.1315318 . ISBN  978-1-59593-703-2 . S2CID   8010083 .
    • Атенезе, Джузеппе; Ди Пьетро, ​​Роберто; В. Манчини, Луиджи; Цудик, Джин (2008). «Масштабируемое и эффективное доказуемое владение данными». Материалы 4-й международной конференции «Безопасность и конфиденциальность в сетях связи — Secure Comm '08 » . п. 1. CiteSeerX   10.1.1.208.8270 . дои : 10.1145/1460877.1460889 . ISBN  978-1-60558-241-2 . S2CID   207170639 .
    • Эрвей, Крис; Купчу, Альптекин; Тамассия, Роберто; Папаманту, Харалампос (2009). «Динамическое доказуемое владение данными». Материалы 16-й конференции ACM «Компьютерная и коммуникационная безопасность – CCS '09» . стр. 213–222. дои : 10.1145/1653662.1653688 . ISBN  978-1-60558-894-0 . S2CID   52856440 .
    • Джулс, Ари; С. Калиски, Бертон (2007). «Порс: доказательства возможности восстановления больших файлов». Материалы 14-й конференции ACM «Компьютерная и коммуникационная безопасность» . стр. 584–597. дои : 10.1145/1315245.1315317 . ISBN  978-1-59593-703-2 . S2CID   6032317 .
    • Бонвен, Николя; Папайоанну, Танасис; Аберер, Карл (2009). «Самоорганизующаяся, отказоустойчивая и масштабируемая схема репликации для облачного хранилища». Материалы 1-го симпозиума ACM по облачным вычислениям — SoCC '10 . стр. 205–216. дои : 10.1145/1807128.1807162 . ISBN  978-1-4503-0036-0 . S2CID   3261817 .
    • Тим, Краска; Мартин, Хентшель; Густаво, Алонсо; Дональд, Косма (2009). «Постоянство нормирования в облаке: платите только тогда, когда это важно». Труды Фонда VLDB . 2 (1): 253–264. дои : 10.14778/1687627.1687657 .
    • Дэниел, Дж. Абади (2009). Управление данными в облаке: ограничения и возможности (Отчет). CiteSeerX   10.1.1.178.200 .
    • Ари, Джулс; С., Бертон; Младший, Калиски (2007). «Порс: доказательства возможности восстановления больших файлов». Коммуникации АКМ . 56 (2): 584–597. дои : 10.1145/1315245.1315317 . S2CID   6032317 .
    • Ари, Атенезе; Рэндал, Бернс; Джонс, Реза; Куртмола, Джозеф; Херринг, Бертон; Леа, Кисснер; Закари, Петерсон; Рассвет, Песня (2007). «Доказуемое хранение данных в ненадежных магазинах». CCS '07 Материалы 14-й конференции ACM по компьютерной и коммуникационной безопасности . стр. 598–609. дои : 10.1145/1315245.1315318 . ISBN  978-1-59593-703-2 . S2CID   8010083 .
  3. Синхронизация
    • Аппур, С; Флорис, доктор медицины; Билас, А (2010). «Облачная синхронизация иерархий распределенных файловых систем». Международная конференция IEEE по кластерным вычислениям, семинары и плакаты 2010 г. (CLUSTER WORKSHOPS) . Инст. вычислительной техники. наук. (ICS), Найден. для Рез. и Технол. - Эллада (ЧЕТВЕРТЫЙ), Ираклион, Греция. стр. 1–4. дои : 10.1109/CLUSTERWKSP.2010.5613087 . ISBN  978-1-4244-8395-2 . S2CID   14577793 .
  4. Экономические аспекты
    • Лори М., Кауфман (2009). «Безопасность данных в мире облачных вычислений». Безопасность и конфиденциальность, IEEE . 7 (4): 161–64. дои : 10.1109/MSP.2009.87 . S2CID   16233643 .
    • Марстон, Шон; Лия, Чжи; Бандйопадхьяя, Субхаджьоти; Жанга, Джухэн; Галсаси, Ананд (2011). Облачные вычисления — перспектива бизнеса . Системы поддержки принятия решений, том 51, выпуск 1. стр. 176–189. дои : 10.1016/j.dss.2010.12.006 .
    • Ангабини, А; Яздани, Н; Мундт, Т; Хассани, Ф (2011). «Пригодность облачных вычислений для приложений анализа научных данных; эмпирическое исследование». 2011 Международная конференция по P2P, параллельным, грид, облачным и интернет-вычислениям . Щ. электр. И компьютер. инженер, унив. Тегеран, Тегеран, Иран. стр. 193–199. дои : 10.1109/3PGCIC.2011.37 . ISBN  978-1-4577-1448-1 . S2CID   13393620 .
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 5aea081b9a4ea5048911f83182fcd1ef__1722385620
URL1:https://arc.ask3.ru/arc/aa/5a/ef/5aea081b9a4ea5048911f83182fcd1ef.html
Заголовок, (Title) документа по адресу, URL1:
Distributed file system for cloud - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)