- PVSM.RU - https://www.pvsm.ru -
В этой статье мы расскажем о том, какие компоненты используются для сбора, обработки и хранения метрик виртуальных машин, приведем примеры настройки использования этих компонентов в проекте VPC.
За получение метрик и их первичную обработку, отвечает компонент OpenStack Ceilometer [1].
На протяжении долгого времени он был единственным компонентом OpenStack предоставляющим все базовые возможности телеметрии.
В дальнейшем разработчики разделили функции Ceilometer между несколькими продуктами:
Aodh и Panko останутся за рамками этой статьи.
Ceilometer может собирать измерения об использовании CPU, RAM, сетевых интерфейсов, дисков, значений температуры из различных источников:
Ранее Ceilometer также предоставлял API для работы с собранными измерениями, метриками и ресурсами. Но начиная с релиза OpenStack Ocata [12] соответствующая функциональность была убрана из этого компонента, так как основным бэкендом для Ceilometer стал Gnocchi [13], имеющий собственный полнофункциональный API для работы со всеми этими объектами.
Мы пробовали использовать Ceilometer из релиза OpenStack Juno [14] несколько лет назад.
Наша первая версия биллинга для проекта VPC [15] отправляла в него отчёты, где они были доступны и служебным программам и пользователям, авторизованным с помощью стандартного токена OpenStack Keystone [16].
Основными бэкендами для Ceilometer в те времена были SQL база данных и MongoDB [17]. К сожалению, оба варианта после полугода использования переставали справляться с нагрузкой. Это происходило из-за того, что структура собираемых данных была слишком свободной, неиндексируемой и излишне подробной.
Каждое измерение хранилось в первоначальном виде, без каких либо агрегаций и изменений. На больших объемах данных простые операции выборки измерений за заданный временной период начинали выполняться очень долго и сервисом становилось невозможно пользоваться.
Для преодоления архитектурных проблем в 2014 году команда разработчиков сервисов телеметрии для OpenStack основала новый проект под названием Gnocchi. Подробное описание причин и выбранного способа решения можно прочитать в обзорной заметке в блоге основного разработчика Gnocchi – Жульена Данжу: OpenStack Ceilometer and the Gnocchi experiment [18].
Архитектура Ceilometer наглядно показана на схеме:
На каждом хосте, где установлен гипервизор, присутствует компонент Ceilometer Agent Compute [19], который собирает данные с виртуальных машин. Собранные данные в таком случае передаются центральному агенту Ceilometer Agent Notification [20] через очередь сообщений.
Если нужно собирать данные о загрузке физических хостов, то на них можно установить и использовать SNMP-агент. В таком случае, сбор данных будет осуществляться центральным агентом Ceilometer Agent Central [20].
После обработки эти данные будут переданы агенту Ceilometer Agent Notification, который отправит их в выбранный бэкенд для хранения.
Ещё центральный агент Ceilometer Agent Notification может собирать информацию о событиях других компонентов OpenStack, прослушивая очередь сообщений. Это может быть полезно, если требуется отслеживать и сохранять информацию о создании, изменении или удалении серверов, дисков или портов.
До недавних пор (а более точно — до релиза OpenStack Ocata [21], который состоялся в феврале этого года) наряду с Ceilometer Agent Notification и Ceilometer Agent Central, на управляющие хосты требовалось устанавливать еще один компонент — Ceilometer Collector.
Сейчас этот компонент уже не используется. Все его функции выполняет Ceilometer Agent Notification.
Основными конфигурационными файлами Ceilometer являются:
Шаблон файла ceilometer.conf со всеми доступными опциями можно скачать или сгенерировать, используя официальную документацию: Ceilometer Configuration Options [22].
Файл pipeline.yaml требуется заполнить самостоятельно.
Пример:
---
sources: #Источники данных
- interval: 600 # Интервал получения данных (секунды)
meters: # Список метрик
- memory.usage # Используемая память внутри виртуальной машины (МБ)
- memory.resident # Память, используемая виртуальной машиной на хосте (МБ)
name: memory_meters # Имя источника измерений
sinks: # Список получателей данных
- memory.sink # Имя получателя данных
- interval: 600 # Интервал получения данных (секунды)
meters: # Список метрик
- disk.device.read.bytes # Суммарное количество прочитанных байт на диске
- disk.device.write.bytes # Суммарное количество записанных байт на диске
name: disk_meters # Имя источника измерений
sinks: # Список потребителей измерений
- disk_sink # Имя потребителя измерений
sinks: # Потребители измерений
- name: memory_sink # Имя получателя данных (используется источником "memory_meters")
publishers: # Список бэкендов хранения, в которые будут записаны измерения
- gnocchi:// # Используется только бэкенд Gnocchi
- name: disk_sink # Имя получателя данных (используется источником "memory_meters")
publishers: # Список бэкендов для хранения измерений
- gnocchi:// # Используется только бэкенд Gnocchi (об этом речь пойдёт ниже)
В этом файле мы можем дополнительно указать трансформации для собираемых данных. К примеру, мы можем преобразовать все полученные значения метрик memory.usage и memory.resident из мегабайт в килобайты. Заодно переименуем эти метрики и добавим им единицы измерения.
Для этого нам потребуется отредактировать потребителя memory_sink таким образом:
sinks:
- name: memory_sink
transformers:
- name: "unit_conversion" # Используем встроенный метод unit_conversion
parameters:
source:
map_from:
name: "memory\.(usage|resident)" # Что переименовать
target:
map_to:
name: "memory.\1.kilobytes" # Как переименовать
scale: "volume * 1024.0" # Как преобразовать значения
unit: "KB" # Добавление единицы измерения
publishers:
- gnocchi://
Подробную информацию о формате данного файла и применении других преобразований можно узнать в официальной документации: Data processing and pipelines [23].
Далее мы рассмотрим проект Gnocchi, который позволяет хранить собираемые измерения в агрегированном виде и предоставляет API для работы с ними.
Проект Gnocchi представляет из себя базу данных временных рядов (time-series database).
Следует отметить, что, в начале мая 2017г., разработчики Gnocchi решили вывести [24] этот проект из инфраструктуры OpenStack.
Кодовая база была перенесена в GitHub [25], а в качестве багтрекера используется механизм GitHub Issues [26]. Одна из основных причин — желание позиционировать Gnocchi не только как бэкенд к Ceilometer, но как более универсальный продукт, подходящий под другие решения. К примеру, в репозитории Gnocchi уже сейчас имеется плагин [27] для сохранения данных из Collectd [28] и плагин [29] для построения графиков в Grafana [30].
Рассмотрим устройство и особенности работы Gnocchi более подробно.
Gnocchi состоит из 2х основных компонентов:
Начиная с версии 3.1 в Gnocchi появилась поддержка разных типов хранилищ для обработанных и необработанных данных. Такое разделение позволяет размещать «горячие» неагрегированные данные на быстром хранилище (например, Redis, поддержка которого появилась в Gnocchi версии 4.0), а данные в агрегированном виде сохранять уже в более надежный, масштабируемый бэкенд (например, Ceph, поддержка которого была еще в самой первой версии Gnocchi).
Помимо непосредственного хранилища данных, для Gnocchi дополнительно требуется SQL-база данных, где хранятся индексы метрик и их метаданные. Для этого можно использовать MySQL или PostgreSQL. Gnocchi использует собственных подход к сохранению измерений, так как все перечисленные технологии не предоставляют возможность хранить данные в виде временных рядов.
При получении новых данных значения не сохраняются в исходном виде. Вместо этого они агрегируются при помощи выбранных пользователем методами (в нашем примере — методами минимум, максимум, среднее) и сохраняются с указанной точностью (в нашем примере — 3600 секунд), в соответствии с созданной архивной политикой.
Мы можем создать архивную политику при помощи консольного клиента python-gnocchiclient [34]. Для примера создадим политику с именем memory_policy, которая содержит 3 метода агрегации — минимум, максимум и среднее, и 2 определения того, как данные будут храниться. Первое определение говорит о том, что мы будем хранить данные с точностью 1 час на протяжении 7 дней. Второе говорит о том, что мы будем хранить данные с точностью 1 день на протяжении 1 года.
Помимо этого укажем значение back window равное 72, что позволит нам сохранять не только метрики, созданные сейчас, но и старые, по какой-то причине зависшие метрики, сроком не более 72 дней.
controller:~# gnocchi archive-policy create memory_policy
> -b 72
> -m min -m max -m mean
> -d 'granularity:1h,timespan:7d'
> -d 'granularity:1d,timespan:365d'
В ответ мы получим описание созданной политики:
.rce lang=«python»>
+---------------------+-------------------------------------------------------------------------+
| Field | Value |
+---------------------+-------------------------------------------------------------------------+
| aggregation_methods | max, min, mean |
| back_window | 72 |
| definition | — points: 168, granularity: 1:00:00, timespan: 7 days, 0:00:00 |
| | — points: 365, granularity: 1 day, 0:00:00, timespan: 365 days, 0:00:00 |
| name | memory_policy |
+---------------------+-------------------------------------------------------------------------+
Обратите внимание на то, что для определений также было автоматически рассчитано значение points. Эта величина считается по формуле:
Points = Timespan / Granularity
Она требуется для расчета места, которое будут занимать значения сохраняемых метрик.
Разработчики Gnocchi предлагают [35] использовать следующую формулу для расчета требуемого места:
Size (in bytes) = 8 * points * aggregation methods
Указанная формула является расчетом места для худшего случая, так как информация всегда хранится в сжатом виде. Используя эту формулу, мы можем рассчитать объем места для архивной политики memory_policy. Для первого определения (точность 1 час в течение 7 дней) мы получаем 4032 байта:
4032 (байт) = 8 * 168 * 3
А для второго определения (точность 1 день на протяжении года) получаем 8760 байт:
8760 (байт) = 8 * 365 * 3
Полученные значения отображают используемое место для одной метрики, хранимой согласно политике memory_policy.
Если мы, к примеру, начнем собирать 2 метрики — memory.usage и memory.resident для 2000 виртуальных машин, то нам потребуется:
2000 * 2 * 4032 (байт) = 16.128 Мбайт (для 7 дней)
2000 * 2 * 8760 (байт) = 35.04 Мбайт (для 1 года)
Все метрики, сохраняемые в Gnocchi, относятся к каким либо ресурсам. Ресурс — это абстрактный объект, который может содержать несколько метрик и также может иметь дополнительные поля, описанные в типе этого ресурса.
Взаимоотношение объектов метрика — ресурс — тип ресурса выглядит так:
К примеру, мы имеем набор ресурсов типа instance_memory. Каждый ресурс этого типа будет содержать метрики memory.usage и memory.resident.
Если мы собираем метрики с 2000 виртуальных машин, то число ресурсов instance_memory также будет равно 2000.
Для таких ресурсов может быть полезно сохранять дополнительную информацию, например, имя хоста гипервизора, на котором запущена виртуальная машина или идентификатор образа операционной системы (хранящегося в сервисе OpenStack Glance [36]), из которого виртуальная машина была создана.
Создадим тип ресурса instance_memory при помощи консольной команды. Укажем описанные дополнительные поля host, image_ref, для хранения имени хоста и идентификатора образа, сделаем при этом поле host обязательным:
controller:~# gnocchi resource-type create instance_memory
> -a host:string:true:min_length=0:max_length=255
> -a image_ref:string:false:min_length=0:max_length=255
В ответ мы получим описание созданного типа ресурса:
+----------------------+-----------------------------------------------------------+
| Field | Value |
+----------------------+-----------------------------------------------------------+
| attributes/host | max_length=255, min_length=0, required=True, type=string |
| attributes/image_ref | max_length=255, min_length=0, required=False, type=string |
| name | instance_memory |
| state | active |
+----------------------+-----------------------------------------------------------+
Аналогичным образом создадим типы ресурсов instance_cpu и instance_disk. Первый будет иметь такие же дополнительные поля, как и instance_memory, а второй будет иметь поле instance_id, указывающий идентификатор сервера, к которому подключен диск:
controller:~# gnocchi resource-type create instance_cpu
> -a host:string:true:min_length=0:max_length=255
> -a image_ref:string:false:min_length=0:max_length=255
+----------------------+-----------------------------------------------------------+
| Field | Value |
+----------------------+-----------------------------------------------------------+
| attributes/host | max_length=255, min_length=0, required=True, type=string |
| attributes/image_ref | max_length=255, min_length=0, required=False, type=string |
| name | instance_cpu |
| state | active |
+----------------------+-----------------------------------------------------------+
controller:~# gnocchi resource-type create instance_disk
> -a instance_id:uuid:true
+------------------------+--------------------------+
| Field | Value |
+------------------------+--------------------------+
| attributes/instance_id | required=True, type=uuid |
| name | instance_disk |
| state | active |
+------------------------+--------------------------+
Теперь разберемся, как нам начать сохранять метрики Ceilometer в Gnocchi, используя созданные типы ресурсов.
Для того, чтобы Ceilometer начал использовать Gnocchi в качестве бэкенда, требуется:
1. Добавить опцию meter_dispatchers в файл ceilometer.conf:
[DEFAULT]
meter_dispatchers = gnocchi
2. Создать файл gnocchi_resources.yaml, который описывает соответствия метрик Ceilometer и типов ресурсов Gnocchi, а также указывает дополнительные поля типов ресурсов:
---
resources:
- resource_type: instance_memory # Тип ресурса для выбранных метрик
metrics:
- 'memory.usage' # Метрика используемой памяти внутри виртуальной машины
- 'memory.resident' # Метрика используемой памяти виртуальной машиной на хосте
attributes:
host: resource_metadata.instance_host # Метаданные о хосте виртуальной машины
image_ref: resource_metadata.image_ref # Метаданные об образе виртуальной машины
- resource_type: instance_disk # Тип ресурса для выбранных метрик
metrics:
- 'disk.device.read.bytes' # Метрика суммарного количества прочитанных байт на диске
- 'disk.device.write.bytes' # Метрика суммарного количества записанных байт на диске
attributes:
instance_id: resource_metadata.instance_id # Метаданные с id виртуальной машины
- resource_type: instance_cpu # Тип ресурса для выбранной метрики
metrics:
- 'cpu_util' # Метрика утилизации процессора внутри виртуальной машины
attributes:
host: resource_metadata.instance_host # Метаданные о хосте виртуальной машины
image_ref: resource_metadata.image_ref # Метаданные об образе виртуальной машины
После запуска Ceilometer, начнется сбор данных и их отправка в Gnocchi (при условии что он был настроен согласно документации [37]).
Вы можете следить за статусом обработки новых данных и сохранением их в агрегированном виде в выбранное хранилище при помощи команды:
controller:~# gnocchi status
+-----------------------------------------------------+-------+
| Field | Value |
+-----------------------------------------------------+-------+
| storage/number of metric having measures to process | 93 |
| storage/total number of measures to process | 93 |
+-----------------------------------------------------+-------+
В приведенном выводе можно увидеть, что сейчас процессы Gnocchi-metricd обрабатывают 93 измерения, распределенные по 93 метрикам.
При помощи этой команды можно следить, справляется ли компонент Gnocchi-metricd с поступающими метриками.
Скорость обработки будет напрямую зависеть от количества процессов Gnocchi-metricd и производительности выбранного хранилища данных.
После того, как полученные измерения будут обработаны и сохранены, можно будет получить доступ к ресурсам и измерениям Gnocchi.
Выведем ресурсы с типом instance_memory, ограничим вывод тремя ресурсами, и отобразим только 4 колонки — идентификатор самого ресурса его тип, имя хоста виртуальной машины и идентификатор ее образа:
controller:~# gnocchi resource list --type instance_memory --limit 3 --column id --column type --column host --column image_ref
+--------------------------------------+-----------------+-----------+--------------------------------------+
| id | type | host | image_ref |
+--------------------------------------+-----------------+-----------+--------------------------------------+
| 945ad3cc-2617-4b19-a681-5a1cb96d71e1 | instance_memory | compute00 | 3456e843-b7fe-42be-8c4c-0c7d1c2d09c7 |
| e33c895f-e38a-4f8e-be07-8fe0d7c8275f | instance_memory | compute02 | 27bbfeb7-0706-4d11-bb59-f98d6b08dc1c |
| 023fed66-3fdd-43b6-b02e-325da55b62cc | instance_memory | compute04 | f0f5e0aa-4615-462e-8340-b8258aae90e2 |
+--------------------------------------+-----------------+-----------+--------------------------------------+
Отобразим колонки с метриками и типом для ресурса 945ad3cc-2617-4b19-a681-5a1cb96d71e1:
controller:~# gnocchi resource show --column metrics --column type 945ad3cc-2617-4b19-a681-5a1cb96d71e1
+---------+-------------------------------------------------------+
| Field | Value |
+---------+-------------------------------------------------------+
| metrics | memory.resident: f56b76ad-5ce8-49fe-975f-6e5da412df31 |
| | memory.usage: aa757f46-52b9-40de-898c-524dfe29b7bc |
| type | sel_instance |
+---------+-------------------------------------------------------+
Посмотрим на средние значения для измерений метрики aa757f46-52b9-40de-898c-524dfe29b7bc, в интервале 12:00 — 18:00 для даты 25.08.2017, и точностью равной одному часу:
controller:~# gnocchi measures show --aggregation mean --granularity 3600 --start 2017-08-25T12:00 --stop 2017-08-25T18:00 aa757f46-52b9-40de-898c-524dfe29b7bc
+---------------------------+-------------+---------------+
| timestamp | granularity | value | |
+---------------------------+-------------+---------------+
| 2017-08-25T12:00:00+00:00 | 3600.0 | 2231.75 |
| 2017-08-25T13:00:00+00:00 | 3600.0 | 2238.66666667 |
| 2017-08-25T14:00:00+00:00 | 3600.0 | 2248.58333333 |
| 2017-08-25T15:00:00+00:00 | 3600.0 | 2259.08333333 |
| 2017-08-25T16:00:00+00:00 | 3600.0 | 2240.41666667 |
| 2017-08-25T17:00:00+00:00 | 3600.0 | 2249.66666667 |
+---------------------------+-------------+---------------+
Агрегированную информацию можно получать не только с помощью консольной утилиты, но и через REST API. Рассмотрим несколько примеров:
Получение значений метрики memory.usage для ресурса типа instance_memory, с точностью 24 часа, начиная с даты 28.08.2017:
controller:~# curl -XGET
> -H 'Content-Type: application/json'
> -H 'X-Auth-Token: KEYSTONE_TOKEN'
> 'controller:8041/v1/resource/instance_memory/684f5b56-2c06-485a-ae1a-66ab5c4175fb/metric/memory.usage/measures?start=2017-08-28&granularity=86400'
> | python -m json.tool
[
[
"2017-08-28T00:00:00+00:00",
86400.0,
2645.9444444444443
],
[
"2017-08-29T00:00:00+00:00",
86400.0,
2671.625
],
[
"2017-08-30T00:00:00+00:00",
86400.0,
2681.5438596491226
]
]
Поиск ресурса с типом instance_memory, созданного после 29.08.2017, со значением «compute19» в поле host:
controller:~# curl -XPOST
> -H 'Content-Type: application/json'
> -H 'X-Auth-Token: KEYSTONE_TOKEN'
> 'controller:8041/v1/search/resource/instance_memory
> -d '{
> "and": [
> {
> "=": {
> "host": "compute19"
> }
> },
> {
> ">": {
> "started_at": "2017-08-29"
> }
> }
> ]
> }'
> | python -m json.tool
[
{
"created_by_project_id": "99288fd3d178459f808c1e8bc2cf9e49",
"created_by_user_id": "7dd0582d38aa471bbe8995f63a1293a9",
"creator": "7dd0582d38aa471bbe8995f63a1293a9:99288fd3d178459f808c1e8bc2cf9e49",
"ended_at": null,
"host": "compute19",
"id": "9052e237-ad17-47be-8aa5-10aacbf6717f",
"image_ref": "e12ef13d-783c-4030-9251-ad2c8e270453",
"metrics": {
"memory.resident": "365db8ce-f4f7-4e59-ac9f-03dcdfe81195",
"memory.usage": "084157b7-09d3-45e7-a869-fad62062025a"
},
"original_resource_id": "9052e237-ad17-47be-8aa5-10aacbf6717f",
"project_id": "99288fd3d178459f808c1e8bc2cf9e49",
"revision_end": null,
"revision_start": "2017-08-30T20:35:19.214598+00:00",
"started_at": "2017-08-30T20:35:19.214577+00:00",
"type": "instance_memory",
"user_id": "7dd0582d38aa471bbe8995f63a1293a9"
}
]
Получение агрегации по максимальным значениям метрик memory.resident с точность до одного часа для виртуальных машин, запущенных на хосте compute19; метрики систематизированы по идентификаторам проектов:
controller:~# curl -XPOST
> -H 'Content-Type: application/json'
> -H 'X-Auth-Token: KEYSTONE_TOKEN'
> 'controller:8041/v1/aggregation/resource/instance_memory/metric/memory.resident&aggregation=max&granularity=3600&groupby=project_id'
> -d '{
> "=": {
> "host": "compute19"
> }
> }'
> | python -m json.tool
[
{
"group": {
"project_id": "eef577b17cfe4432b7769d0078dbb625"
},
"measures": [
[
"2017-08-29T09:00:00+00:00",
3600,
735
],
[
"2017-08-30T11:00:00+00:00",
3600,
949
]
]
},
{
"group": {
"project_id": "b998dbbb9b02474c9dc49ffc289eae8c"
},
"measures": [
[
"2017-08-29T09:00:00+00:00",
3600,
612
],
[
"2017-08-30T11:00:00+00:00",
3600,
642
]
]
}
]
Другие примеры использования REST API доступны в официальной документации [38].
В настоящее время мы используем описанные компоненты в сервисе VPC [15].
Пользователям доступны следующие метрики для виртуальных машин:
Метрики для дисков:
И метрики для сетевых интерфейсов:
Все данные можно получать как через REST API или консольный клиент Gnocchi, так и в виде встроенных графиков в панели управления серверами.
В этой статье мы рассмотрели два компонента для сбора, хранения и отображения статистики об объектах OpenStack.
Если у вас возникли вопросы, добро пожаловать в комментарии.
Если вам интересно было бы попробовать gnocchi в качестве сервиса, в который вы смогли бы писать собственные данные — напишите нам об этом.
Также будем рады, если вы поделитесь собственным опытом использования Ceilometer или Gnocchi.
Автор: aozerov
Источник [39]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/selectel/266118
Ссылки в тексте:
[1] OpenStack Ceilometer: https://docs.openstack.org/ceilometer/latest/
[2] Aodh: https://docs.openstack.org/aodh/latest/
[3] Gnocchi: http://gnocchi.xyz/index.html
[4] Panko: https://docs.openstack.org/panko/latest/
[5] KVM: https://www.linux-kvm.org/page/Main_Pag
[6] Hyper-V: https://technet.microsoft.com/en-us/library/mt169373(v=ws.11).aspx
[7] XEN: https://xenserver.org
[8] VMware: https://www.vmware.com
[9] RabbitMQ: https://www.rabbitmq.com
[10] ZeroMQ: http://zeromq.org
[11] Kafka: https://kafka.apache.org
[12] OpenStack Ocata: https://docs.openstack.org/releasenotes/ceilometer/ocata.html#upgrade-notes
[13] Gnocchi: http://gnocchi.xyz
[14] OpenStack Juno: https://www.openstack.org/software/juno/
[15] VPC: https://selectel.ru/services/cloud/vpc/
[16] OpenStack Keystone: https://docs.openstack.org/keystone/latest/
[17] MongoDB: https://www.mongodb.com/what-is-mongodb
[18] OpenStack Ceilometer and the Gnocchi experiment: https://julien.danjou.info/blog/2014/openstack-ceilometer-the-gnocchi-experiment
[19] Ceilometer Agent Compute: https://docs.openstack.org/ceilometer/latest/install/install-compute-ubuntu.html
[20] Ceilometer Agent Notification: https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html
[21] OpenStack Ocata: https://releases.openstack.org/ocata/
[22] Ceilometer Configuration Options: https://docs.openstack.org/ceilometer/latest/configuration/index.html
[23] Data processing and pipelines: https://docs.openstack.org/ceilometer/latest/admin/telemetry-data-pipelines.html
[24] решили вывести: https://julien.danjou.info/blog/2017/gnocchi-independence
[25] GitHub: https://github.com/gnocchixyz/gnocchi/
[26] GitHub Issues: https://guides.github.com/features/issues/
[27] плагин: https://github.com/gnocchixyz/collectd-gnocchi
[28] Collectd: https://collectd.org
[29] плагин: https://github.com/gnocchixyz/grafana-gnocchi-datasource
[30] Grafana: https://grafana.com/grafana
[31] Ceph: http://ceph.com
[32] Redis: https://redis.io
[33] OpenStack Swift: https://docs.openstack.org/swift/latest/
[34] python-gnocchiclient: https://github.com/gnocchixyz/python-gnocchiclient
[35] предлагают: http://gnocchi.xyz/stable_4.0/running.html#how-to-plan-for-gnocchis-storage
[36] OpenStack Glance: https://docs.openstack.org/glance/latest/
[37] документации: http://gnocchi.xyz/stable_4.0/install.html#configuration
[38] официальной документации: http://gnocchi.xyz/master/rest.html
[39] Источник: https://habrahabr.ru/post/340054/
Нажмите здесь для печати.