ГЛАВА 2

Архитектура OpenStack Swift.

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

[

Заметим, что мы используем термины долговечный и надежный как синонимы (durable и reliable)

]

Логическая организация объектов

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

Владельцу назначается учетная запись. Владельцем может быть любой объект — субъект, отдел, компания и так далее. Учетная запись содержит контейнеры. Каждый контейнер содержит объекты, как показано в следующем рисунке. Вы можете представлять объекты файлами по существу.

Владелец может создать дополнительных пользователей для доступа к учетной записи. Пользователи могут продолжать добавлять контейнеры и объекты в контейнер без необходимости заботы о каких-либо физических пределах аппаратного обеспечения, в отличие от обычных файловых или блочных систем хранения. Контейнеры в учетной записи, безусловно, должны иметь уникальное имя, но два контейнера в различных учетных записях могут иметь одно имя. Контейнеры являются плоскими, а объекты не сохраняются иерархически, в отличие от того, как файлы хранятся в файловой системе, в которой каталоги могут быть вложенными. Тем не менее, Swift предусматривает механизм для имитации псевдо-каталогов, вставляя разделитель / в имя объекта.

Реализация Swift

Существуют две основные подлежащие решению проблемы Swift:

• Где размещать и откуда извлекать данные
• Как надежно сохранять данные

Ключевые принципы архитектуры

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

• Отсутствие ведущего: ведущий одновременно создает в системе единую точку отказа и узкое место для производительности. Система без главного исключает это обстоятельство, а также позволяет нескольким участникам кластера отвечать на API запросы.
• Свобода от закрепления: Нет необходимости в жестких связях в кластере. Это также является необходимым условием для предотвращения узких мест в производительности и отказах.
• Распределение нагрузки: Нельзя достигнуть производительности, производительность, ведения учетных записей, емкость и масштабируемость объектов не могут быть достигнуты.
• Самовосстановление: Система должна автоматически регулировать сбои оборудования. В соответствии с обсуждавшейся в главе 1 Облачное хранилище: Почему я не могу быть как Google? теореме CAP должны допускаться частичные допуски.
• Организация данных: Ряд систем хранения объектов просто возвращают хэш-ключи для представленного объекта и обеспечивают полностью плоское пространство имен. Задача создания учетных записей, контейнеров и ключей соответствия именам объектов остается за пользователем. Swift упрощает работу пользователя и обеспечивает хорошо разработанный уровень организации данных.
• Доступность и согласованность в конечном счете: Об этом шла речь в главе 1 Облачное хранилище: Почему я не могу быть как Google?

Организация физических данных

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

Иерархия заключается в следующем:
• Регион: На самом высоком уровне Swift хранит данные в регионах, которые географически разделены и, таким образом, претерпевают высокие задержки при связи. Пользователь может использовать только один регион, например, если кластер использует только один центр обработки данных.
• Зона: В регионах существуют зоны. Зоны являются набором узлов хранения, которые совместно используют различные характеристики доступности. Доступность может быть определена различными: физическими зданиями, источниками питания или сетевыми соединениями. Это означает, что зоной может быть отдельный сервер хранения, стойка, или весь центр обработки данных в зависимости от ваших потребностей. Зоны должны быть соединены друг с другом с помощью низкой латентностью ссылки. Rackspace рекомендует иметь по крайней мере пять зон каждого региона.
• Серверы хранения данных: Зона состоит из множества серверов хранения в пределах от всего одного сервера до нескольких стоек.
• Диск (или устройство): Дисковые накопители являются частью сервера хранения. Это могут располагаться внутри сервера или подключаться через JBOD.

Swift будет хранить несколько реплик (копий, по умолчанию = 3) объекта на разных дисках. С использованием алгоритма в уникальный-насколько-это-возможно (as-unique-as-possible), эти реплики располагаются настолько "далеко" друг от друга, как это возможно в смысле различных регионов, зон, серверов хранения и дисков. Этот алгоритм отвечает за вопросы надежности Swift.

Swift использует полустатическую таблицу для поиска места размещения объектов и их копий. Онаявляется полустатической, поскольку таблица поиска под названием "кольцо" в Swift создается с помощью внешнего процесса, называемого конструктором кольца (ring builder). Кольцо может быть изменено, однако не динамически, и никогда самим Swift. Оно не является распределенным, следовательно каждый занимающийся размещением данных узел имеет полную копию кольца. Кольцо имеет внутри себя записи, называемые разделами (partition, этот термин не следует путать с более часто используемым названием для дисковых разделов). По сути, объект отображается в разделе, а раздел предоставляет устройства, вкоторых должны быть сохранены реплики объекта. Кольцо также предоставляет список автоматически переназначаемых устройств, на случай если любое из исходных устройств испытывает отказ.

Фактическое сохранение объекта осуществляется в файловой системе, которая находится на диске, например, в XFS. Информация об учетных записях и контейнерах хранится в базе данных SQLite. База данных учетных записей содержит список всех контейнеров, а база данных контейнеров содержит список всех его объектов. Эти базы данных хранятся в отдельных файлах, причем файлы реплицируются так же, как и любой другой объект.

Программные серверы информационных каналов

Информационные каналы состоят из следующих четырех серверов программного обеспечения:

• Прокси сервер
• Сервер учетных записей
• Сервер контейнеров
• Сервер объектов

Если вам необходима высокая производительность, то серверы учетных записей, контейнеров и объектов часто располагаются на одном физическом сервере, который называется сервером хранения (или узлом), как показано на следующем рисунке:

Ниже приводится описание каждого типа сервера:
• Прокси-сервер: Прокси-сервер отвечает за принятие HTTP запросов от пользователя. Он выполнит поиска местоположения сервера(ов) хранения, куда должен быть направлен запрос с использованием кольца. Прокси-сервер отвечает за отказы (путем поиска узлов для автоматического переназначения) и выполняет операции сродства чтения/записи (путем отправки записей или чтений в тот же регион; см. разделы Один день из жизни операций создания и Один день из жизни операций чтения). Когда объекты устремиляются к серверу объектов или с него, они также протекают непосредственно через прокси-сервер. Кроме того, прокси-серверы также отвечают за кворум чтения/записи и часто размещают встроенное программное обеспечение промежуточного уровня (что обсуждается далее в этой главе).
• Сервер учетных записей: Сервер учетных записей отслеживает имена контейнеров для конкретной учетной записи. Данные хранятся в базе данных SQLite; файлы базы данных в дальнейшем хранятся в файловой системе. Этот сервер также отслеживает статистику, однако не имеет никакой информации о местоположении контейнеров. Информация о местоположении определяется прокси-сервером на основе данных кольца. Обычно этот сервер размещен на одном физическом сервере с серверами контейнеров и объектов. Тем не менее, для крупных установок может потребоваться отдельнsq физический сервер.
• Сервер контейнеров: Этот сервер очень похож на сервер учетных записей, за исключением того, что он имеет дело с именами объектов в определенном контейнере.
• Сервер объектов: Сервер объектов просто хранит объекты. Каждый диск имеет свою файловую систему, и объекты сохраняются вэтой файловой системе.

Давайте сошьем физическую организацию данных с различными программными компонентами и исследуем четыре основные операции: создание, чтение, обновление и удаление (известные как CRUD: create, read, update и delete). Для простоты, мы сосредоточимся на сервере объектов, однако рассмотрение также можно дополнительно экстраполировать на оба сервера учетных записей и контейнеров.

Один день из жизни операций создания

Запрос create отправляется через API вызов HTTP PUT на прокси-сервер. Нет значения какой прокси-сервер получает запрос, так как Swift является распределенной системой и все прокси-серверы созданы равноправными. Прокси-сервер взаимодействует с кольцом для получения списка дисков и связанных с ними серверов объектов для записи данных. Как мы уже обсуждали ранее, эти диски будут по- возможности уникальными. В случае отказа некоторых дисков или их недоступности, кольцо предоставляет автоматически замещаемые устройства. После того, как большинство дисков подтвердили запись (например, два из трех дисков), операция возвращается как успешная. Если предположить, что оставшиеся записи завершились успешно, то у нас все хорошо. Если нет, то процесс репликации, как это показано на следующем рисунке, обеспечивает в конечном счете создание остальных копий:

Операция create работает немного по-другому в кластере с несколькими регионами. Все копии объекта записываются в локальном регионе. Это называется афинной записью (write affinity, близкой записью). Затем объект асинхронно перемещается в другую область (области). Для этой операции может быть использована выделенная сети репликации.

Один день из жизни операций чтения

Запрос read посылается к прокси-серверу через API вызов HTTP GET. Как и в предыдущем случае, любой прокси-сервер может получить этот запрос. Как и при операции create, прокси-сервер взаимодействует с кольцом для получения списка дисков и связанных с ними серверов объектов. Запрос read выдается серверам объектов в том же регионе где расположен прокси-сервер. Это называется афинным чтением (read affiity, близким чтением). Для реализации с множеством регионов, согласованность, в конечном итоге, представляет собой проблему, поскольку разные регионы могут иметь различные версии объекта. Для решения этой проблемы, может быть запрошена операция read для объекта с последней временной отметкой. В этом случае, прокси-серверы вначале запрашивают временные отметки от всех серверов объектов и читают данные с сервера с новейшей копией. Как и в случае операции create (прим. пер.: в тексте оригинала write), в случае отказа может быть запрошено автоматически замещаемое устройство.

Один день из жизни операций обновления

Запрос update обрабатывается таким же образом, как и запрос create (прим. пер.: в тексте оригинала write). Объекты хранятся со своими отметками времени для уверенности, что при чтении возвращается последняя версия объекта. Swift также поддерживает функцию контроля версий на поконтейнерной основе. Если эта опция включена, старые версии объекта также доступны в специальном контейнере под названием versions_container.

Один день из жизни операций удаления

Запрос delete, отправленный через API вызов HTTP DELETE рассматривается как обновление, но вместо новой версии, размещается версия "надгробной плиты" с нулевыми байтами. Операция удаления очень сложна в распределенной системе, посколку система будет серьезно бороться с удалением путем воссоздания удаленных копий. Решение Swift действительно очень элегантное и исключает возможность повторного внезапного появления удаленных объектов.

Компоненты программного обеспечения заключительной обработки

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

Репликации

Репликация - очень важная сторона Swift. Репликация гарантирует, что система непротиворечива, то есть, что все серверы и диски, назначенные кольцом для хранения копий объектов или баз данных действительно имеют последнюю версию. Данный процесс защищает от сбоев, миграции аппаратных средств, а также повторной балансировки кольца (когда кольцо изменяется и данные должны быть перемещены). Это выполняется путем сравнения локальных данных судаленными копиями. Если удаленная копия должна быть обновлена, процесс репликации "выталкивает" копию. Процесс сравнения довольно эффективен и осуществляется путем простого сравнения хэш- списков, в отличие от байтового сравнения всех объектов (или учетных записей или баз данных контейнеров). Для копирования данных репликация использует Rsync, утилиту дистанционной синхронизации из Linux, однако существуют планы ее замены на более быстрый механизм.

Корректоры

При определенных обстоятельствах серверы учетных записей или контейнеров могут быть заняты из-за большой загруженности или недоступности. В этом случае, обновление ставится в очередь на локальном хранилище сервера хранения. Существует два корректора для обработки этих элементов очереди. Корректор объектов будет обновлять объекты в базе данных контейнера, в то время как корректор контейнеров будет обновлять контейнеры в базе данных учетных записей. Такая ситуация может привести к интересным возможным характерам изменения согласованности, при которых объект будет доступен, но список контейнера в то же время не содержит его. Такие окна несоответствия, как правило, очень малы.

Аудиторы

Аудиторы обходят все объекты, контейнеры и учетные записи для их проверки на целостность данных. Это выполняется путем вычисления хэша MD5 и его сравнения с сохраненными значениями хешей. Если определено, что элемент поврежден, тогда он перемещается в каталог карантина, а со временем процесс репликации создаст чистую копию. Именно так система самовосстанавливается. MD5-хэш также доступна пользователям, следовательно они могen выполнять такие операции, как сравнение хэш объекта в их местоположении с тем, что хранится в Swift.

Другие процессы

Другие фоновые процессы следующие:

• Чистильщик учетных записей (Account reaper): Этот процесс выполняется в фоновом режиме и отвечает за удаление всей учетной записи после того, как она будем помечена для удаления в безе данных.
• Гаситель объектов (Object expirer): Swift позволяет пользователям устанавливать политики хранения, обеспечивая информацию "удалить-d" (delete-at) или "удалить-после" (delete-after) для объектов. Этот процесс гарантирует, что просроченные объекты удаляются.
• Аудит приводов (Drive audit): Это еще один полезный фоновый процесс, который следит за плохими дисками и демонтирует их. Это может оказаться более эффективным, нежели позволить аудитору разбираться с таким отказом.
• Синхронизация контейнер в контейнер: Наконец, при промощи процесса синхронизации контейнера в контейнер, все содержимое контейнера должно отображаться в другой контейнер. Эти контейнеры могут находиться в различных кластерах и операция использует секретный ключ синхронизации. До появления поддержки нескольких регионов, эта функция была единственным способом получить несколько копий ваших данных в двух или большем числе регионов, и, таким образом, эта функция является менее важной, чем это было ранее. Тем не менее, она по-прежнему очень полезна для гибридных (с комбинацией частных и общественных) или облаков сообществ (объединяющих несколько частных облаков).

Встроенные функции программного обеспечения промежуточного слоя

Для расширения функциональных возможностей Swift, в дополнение к упомянутым основным компонентам информационных каналов, в них могут быть размещены другие элементы. Это достигается использованием преимуществ архитектуры Swift, которые позволяют вставлять модули промежуточного программного обеспечения. Ниже приводится неполный список различных модулей промежуточного программного обеспечения. Большинство из них применяются только к прокси-серверу, однако некоторые модули, такие, как протоколирование (logging) и разведка (recon) применимы также и к другим серверам.

Аутентификация

Аутентификация является одной из самых важных встроенных функций. Все промежуточное программное обеспечение Swift является раздельным и используется для расширения Swift; таким образом, системы аутентификации являются отдельными проектами и можно выбрать один из нескольких. Аутентификация Keystone является официальной службой идентичности OpenStack и может использоваться в сочетании со Swift, хотя нет средств препятствующих возможности создания пользователем собственной системы аутентификации или выполнять аутентификацию с помощью других средств, таких как Swauth или TempAuth.

Аутентификация работает следующим образом:

1. Пользователь предоставляет системt аутентификации необходимые ей данные. Это делается путем выполнения API вызова HTTP REST.
2. Система аутентификации снабжает пользователя маркером AUTH.
3. Маркер AUTH неявляется уникальным для каждого запроса, однако его действие истекает по прошествии некоторого времени.
4. Каждый сделанный к Swift запрос имеет сопроводительный маркер AUTH.
5. Swift сверяет результат с системой авторизации и кеширует результат. Результат сбрасывается по окончанию.
6. Как правило, система идентификации имеет понятие учетных записей администраторов и учетных записей без прав администраторов. Очевидно, запросы администратора пропускаются.
7. Запросы без прав администраторов проверяются по контейнеру списков управления доступом (ACL, Access Control Lists). Эти списки позволяют администратору установить ACL на чтаение и запись для каждого пользователя без прав администратора.
8. Таким образом, для пользователей без прав администратора, ACL проверяется перед выполнением запроса прокси-сервером. На следующем рисунке показаны выполняющиеся этапы, при взаимодействии Swift с системой идентификации:

   Swift и его взаимодействие с системой аутентификации

Протоколирование

Протоколирование очень важный модуль. Этот компонент обеспечивает ведение журналов. Пользователь также может вставить свой собственный обработчик журнала.

Другие модули

Также доступен ряд других модулей промежуточного программного обеспечения Swift и сторонних разработчиков; ниже приведенo несколько примеров:
• Проверка состояния (Health check): Этот модуль обеспечивает простой способ мониторинга работает ли прокси-сервер. Просто получите доступ к прокси-серверу с проверкой path/health и сервер ответит OK.
• Переназначение домена (Domain remap): Этот компонент позволяет вам переназначить учетные записи и имя контейнера с пути в имя хоста домена. Это позволяет упростить доменные имена.
• Поиск CNAME (CNAME lookup): Используя это программное обеспечение, вы можете создать дружественные доменные имена, которые перназначаются непосредственно на ваши учетные записи или контейнеры. Поиск CNAME и переназначение домена могут использоваться совместно.
• Ограничение скорости (Rate limiting): Ограничение скорости используется для ограничения скорости запросов, которое имеет результатом записи в базы данных серверов учетных записей и контейнеров.
• Квоты контейнеров и учетных записей (Container and account quotas): С помощью этих двух модулей промежуточного программного обеспечения администратор может установить квоты контейнеров или учетных записей.
• Массовое удаление (Bulk delete): Этот компонент позволяет массовые операции, таких как удаление нескольких объектов или контейнеров.
• Массовая архивация и автоизвлечение (Bulk archive auto-extraction): Используйте это программное обеспечение для выполнения массового извлечения из TAR (TAR, tar.gz, tar.bz2) файлов с помощью одной команды.
• Временный URL TempURL: Промежуточное программное обеспечение TempURL позволяет создать URL, который обеспечивает временный доступ к объекту. Этот доступ не требует аутентификации, однако истекает после определенного периода времени. Кроме того, доступ осуществляется только к одному объекту, и никакие другие объекты не могут быть доступны через этот URL.
• Сервер начала Swift (Swift origin server): Именно этот модуль позволяет использовать Swift как исходный сервер для сети доставки контента (CDN, Content Delivery Network).
• Статический веб-сайт (Static web): Это программное обеспечение преобразует Swift в статический веб-сервер. Вы также можете предоставить стили CSS для получения полного контроля над внешним видом и осязанием ваших страниц. Очевидно, запросы могут приходить от анонимных источников.
• Form post: При использовании промежуточного программного обеспечения Form post, вы получаете возможность загружать объекты Swift с использованием отправки стандартных форм HTML. Программное обеспечение промежуточного уровня преобразует различные запросы POST в разные запросы PUT, причем запросы не подвергаются аутентификации допуская сотрудничество между пользователями и не-пользователями кластера.
• Recon: Recon является программой, полезной для управления. Она обеспечивает мониторинг и возвращает различные метрики кластера.

Дополнительная функциональность

Swift имеет дополнительные функции, которые не упомянуты в предыдущих разделах. В последующих разделах детализируются некоторые из дополнительных возможностей.

Поддержка больших объектов

Swift устанавливает ограничение на размер одного загружаемого объекта (по умолчанию 5 ГБ), но позволяет хранить и скачивать объекты практически неограниченного размера. Используется техника сегментации. Объект разбивается на сегменты равного размера (за исключением последнего) и загружаются. Эти загрузки эффективны, поскольку нет одного неоправданно большого сегмента, а передача данных может быть выполнена параллельно. После завершения загрузки, загружается файл манифеста, который показывает, как сегменты образуют один большой объект. Загрузка является одной операцией при которой Swift объединяет различные сегменты воссоздавая один большой объект.

Метаданные

Swift позволяет присоединять полученные в виде пользовательских заголовков пользовательские метаданные к учетным записям, контейнерам или объектам. Метаданные являются просто парой ключ (имя) - значение. Метаданные могут быть предоставлены во время создания объекта (с помощью PUT) или обновлены позже (с помощью POST). Метаданные могут быть получены независимо от объекта с помощью метода HEAD.

Поддержка мультидиапазонности

Спецификация HTTP допускает операции GET с несколкими диапазонами, и Swift позволяет извлекать несколько диапазонов объекта вместо всего объекта.

CORS

CORS является спецификацией, которая позволяет JavaScript работать в браузере, выполняя запрос к доменам, отличным от тех, с которых был взят код. Swift поддерживает ее, и данная особенность делает возможным для вас, чтобы размещать ваши веб-страницы с JavaScript на одном домене и запрашивать объекты из кластера Swift с другого домена. Swift также поддерживает более широкий файл междоменной политики, в котором другие технологии стороны клиента, такие как Flash, Java и Silverlight, также могут взаимодействовать со Swift, который расположен в другом домене.

Копии на стороне сервера

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

Состояние кластера

Инструмент под названием swift-dispersion-report может быть использован для измерения общего состояния кластера. Она делает это путем проверки того, что различные реплики объекта и контейнера находятся на своих местах.

Заключение

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

Глава 1	Оглавление	Глава 3
Перевод: Copyright © 2014  . All rights reserved. Ссылки обязательны (Refs and links obligatory).		http://www.mdl.ru