Слияние кода завершено, страница обновится автоматически
ЧЗВ включает некоторые часто задаваемые вопросы относительно двух аспектов:
Технические вопросы не будут включены в ЧЗВ.
Dragonfly — это умная система распределения изображений и файлов на основе протокола P2P.
Целью системы является решение проблем, связанных с низкой эффективностью, низким уровнем успешности и пропускной способностью сети при передаче файлов. Особенно в масштабах крупномасштабного распространения файлов, таких как распространение приложений, кэша, журналов и изображений.
В компании Alibaba Dragonfly вызывается более 2 миллиардов раз каждый месяц, а распределяемые данные составляют 3,4 петабайта. Dragonfly стала одной из самых важных частей инфраструктуры Alibaba.
Хотя технологии контейнеризации делают жизнь DevOps проще большую часть времени, они также создают свои проблемы: эффективность распространения образов контейнеров, особенно когда требуется повторное распространение образов на нескольких хостах. Dragonfly работает очень хорошо вместе с Docker и PouchContainer в этом случае. Она также совместима со всеми другими форматами контейнеров.Система обеспечивает до 57 раз большую пропускную способность по сравнению с нативным Docker и экономит до 99,5% внешней пропускной способности реестра (*2).Драконфли обеспечивает простой и экономически выгодный процесс установки, эксплуатации и масштабирования любых типов распределения файлов/образов/данных.
Нет, Dragonfly может использоваться для распространения всех видов файлов, а не только образов контейнеров. Для скачивания файлов с помощью Dragonfly обратитесь к разделу Загрузка файла. Для получения образов с помощью Dragonfly обратитесь к разделу Получение образа.
Супернод будет поддерживать битовый массив, который отражает соответствие между участниками и кусками. Когда dfget начинает загружать, супернод вернет информацию о нескольких кусках (по четыре по умолчанию) согласно планировщику.
Примечание: Планировщик решает, загружать ли данные с супернода или других участников. Подробнее о работе планировщика см. раздел Алгоритм планировщика.
dfget должен выполнить два вида действий:ЗАМЕЧАНИЕ: Супернод не может управлять кэшированным файлом, который уже был распределён между узлами. Чтобы узнать, что произойдет, если кэшированный файл на узле будет удален, обратитесь к разделу Что произойдет, если вы завершите процесс сервера dfget или удалите исходные файлы.
Когда dfget регистрирует задачу для суперноды, супернод проверяет наличие локального кэша для файла, который требуется скачать.
Если файл ещё не кэширован на суперноде, последняя выполняет следующую последовательность действий:
If-None-Match:<etag>, так и If-Modified-Since:<lastmodified>, чтобы определить, был ли удален или изменен удаленный файл.Кроме того, супернода не должна ждать окончания скачивания всех частей, поэтому она может параллельно начинать скачивание новых частей сразу после завершения скачивания одной части.
Если файл на узле был удален вручную или сборщиком мусора, супернода этого не узнает. При последующем планировании, если несколько задач скачивания провалились из-за этого узла, планировщик добавит его в черный список. То же самое относится к ситуации, когда процесс сервера был завершен или возникли другие аварийные условия.
Распределение частей происходит равномерно. Выбираются части с наименьшим количеством в целой сети P2P таким образом, чтобы распределение каждой части в сети P2P было балансировано, что позволяет избежать "нервных ресурсов".
Приоритет по минимальному расстоянию. Для одного участника выбирается часть, которая находится ближе всего к текущей скачиваемой части, так что участник может приближенно достичь эффекта последовательного чтения и записи, что повысит эффективность ввода-вывода файла.- Локальный черный список и глобальный черный список. Пример проще понять: когда участник A не может скачать данные от участника B, B становится локальным черным списком для A, и все задачи скачивания A исключают B; когда количество неудачных попыток скачивания от B достигает некоторого порога, B становится глобальным черным списком, и все задачи скачивания исключают B.
Самоизоляция. Участник A будет скачивать файлы только от суперузла после нескольких неудачных попыток скачивания от других участников, и также будет добавлен в глобальный черный список. Таким образом, участник A больше не будет взаимодействовать с другими участниками, кроме суперузла.
Балансировка нагрузки между участниками. Эта механика контролирует количество частей для загрузки и скачивания, которое каждый участник может предоставить одновременно, а также приоритет как цели.
Dragonfly пытается сделать размер блока (части) динамическим для обеспечения эффективности.
Размер частей вычисляется согласно следующей стратегии:
4 МБ.min{общий размер / 100 МБ + 2 МБ, 15 МБ}.Алгоритмы P2P Dragonfly и BitTorrent (BT) имеют несколько ключевых различий:
Структура сети: Dragonfly использует более сложную структуру сети, которая включает в себя суперузлы для управления и балансировки нагрузки. В то время как BitTorrent имеет более простую структуру пир-к-пир, где каждый узел играет роль источника данных.
Управление ошибками: Dragonfly использует механизмы самоизоляции и глобального/локального черного списка для управления проблемами соединения и качества передачи данных. В то время как BitTorrent использует более простые методы управления ошибками, такие как повторная попытка и перезапрос.
Эффективность передачи данных: Dragonfly стремится оптимизировать размер блока (части) для повышения эффективности передачи данных. Это делается путем динамического изменения размера блока в зависимости от размера файла. В то время как BitTorrent обычно использует фиксированный размер блока.
Приоритизация задач: Dragonfly использует механизм приоритизации задач для управления количеством частей для загрузки и скачивания, что позволяет лучше использовать ресурсы каждого узла. В то время как BitTorrent не имеет такого явного механизма приоритизации.
Таким образом, хотя оба протокола используют принципы peer-to-peer, они реализуют эти принципы по-разному, чтобы адаптироваться к различным требованиям и условиям работы.Алгоритмы P2P Dragonfly и BitTorrent (BT) являются реализациями протокола peer-to-peer. Различия между ними представлены в следующей таблице:
| Аспект | Dragonfly | BitTorrent (BT) |
|---|---|---|
| Динамическое сжатие семян | Поддерживается | Неподдерживаемое |
| Возможность продолжения с прерванной точки | Поддерживается | Неподдерживаемое |
| Динамическая установка размера блока | Поддерживается, см. вопрос | Неподдерживаемое (размер блока фиксирован) |
| Прозрачность семена для клиента | Поддерживается (пользователю требуется только указать URL файла) | Неподдерживаемое (BT требует генерации семени на трекере перед его предоставлением клиенту) |
Ограничение пропускной способности сети можно применять как к пир-узлам, так и к суперузлам кластера Dragonfly.
Для самого пир-узла Dragonfly можно установить ограничение пропускной способности сети для двух частей:- одного отдельного скачивающегося задания; по умолчанию, лимит составляет 10 МБ/с на каждое скачивающееся задание. Пользователь может установить лимит пропускной способности сети для задания через параметр --locallimit внутри dfget.
totallimit внутри dfget. Если пользователь установил --totallimit=40М, то лимит как для отправки (TX), так и для получения (RX) данных составит 40 МБ/с.Для суперузла Dragonfly позволяет пользователю ограничивать как входящую, так и исходящую пропускную способность сети.Настройка также возможна через конфигурационные файлы, см. ссылку.
В пир-сети пир-узел может выполнять роль как загрузчика, так и передатчика данных.
Поэтому, когда пир-узел завершил скачивание файла/изображения, возможно, что другие пир-узлы всё ещё скачивают блок/часть от этого пир-узла. Поэтому процесс dfget продолжает работу для потенциальной услуги передачи данных.
Процесс dfget завершится только тогда, когда нет новых задач для скачивания файлов/изображений или других пир-узлов, которые бы обращались за скачиванием блока/части от данного пир-узла.
registry-mirrors. Эта операция обновления конфигурации направлена на то, чтобы запросы на получение образов, которые не содержат адреса стороннего реестра кроме dockerhub, отправлялись локальному процессу dfdaemon. Процесс dfget выполняет преобразование этих запросов и проксирует их к локальному процессу dfget. Настройка контейнерного движка registry-mirrors довольно проста. Возьмём Docker в качестве примера. Администратор должен изменить конфигурационный файл Docker /etc/docker/daemon.json, чтобы добавить следующий элемент:"registry-mirrors": ["http://127.0.0.1:65001"]
При обновлении конфигурации запрос docker pull mysql:5.6 будет отправлен в dfdaemon, а запрос docker pull a.b.com/mysql:5.6 не будет отправлен в dfdaemon. Поскольку движок Docker работает только с официальными образами из Docker Hub, чтобы воспользоваться преимуществами зеркала реестра. Однако, если вы установите --registry a.b.com в dfdaemon, и отправите запрос docker pull mysql:5.6, dfdaemon проксирует этот запрос и распределяет образ mysql:5.6 из реестра a.b.com.
Примечание: пожалуйста, запомните, что после обновления конфигурации требуется перезапустить контейнерный движок.## Можно ли настроить dfdaemon как HTTP_PROXY?
Да, обратитесь к руководству по прокси.
Нет, пока нет. В последующих выпусках мы попробуем выпустить версию Dragonfly с высокой доступностью.
Кроме того, вы можете предоставить несколько supernodes для dfget в качестве альтернативы. Когда peers начинают скачивать задачу, они регистрируются на одном из списков supernodes случайным образом. И когда supernode сталкивается с отказом, задача, которая была скачана на нём, автоматически мигрирует на другие supernodes в списке supernodes.
Существует два способа настройки одного или нескольких supernodes для dfget:
cat <<EOD > /etc/dragonfly/dfget.yml
nodes:
- supernode01
- supernode02
- supernode03
EOD
dfget --node supernode01 --node supernode02 --node supernode03
или
dfget --node supernode01,supernode02,supernode03
Замечание: Если вы используете dfdaemon для вызова dfget, вы также можете передать этот параметр dfget через dfdaemon --node.
Очень просто развернуть Dragonfly в Kubernetes с помощью Helm. Для получения более подробной информации о Helm Chart Dragonfly обратитесь к проекту dragonflyoss/helm-chart.## Может ли образ из реестра третьей стороны быть получен через Dragonfly?
Мы не можем получить образ из третьей стороны через Dragonfly. Образы из третьей стороны означают, что имя образа не содержит адреса реестра, например, образ a.b.com/admin/mysql:5.6 является образом с третьего источника, и он берется из реестра a.b.com. Наоборот, admin/mysql:5.6 не берется из третьего стороннего реестра, так как имя образа не содержит адрес реестра.
Потому что администратору требуется настроить --registry-mirrors=["http://127.0.0.1:65001"] для контейнерного движка, чтобы перенаправлять часть запросов получения образов в dfdaemon, который слушает порт 65001 локально. Образы, не взятые из третьего стороннего реестра, будут использовать это зеркало реестра. Однако, когда пользователь получает образ a.b.com/admin/mysql:5.6, содержащий адрес третьего стороннего реестра, контейнерный движок будет непосредственно обращаться к третьему стороннему реестру для получения образа, игнорируя настроенное зеркало реестра. В этом случае это никак не связано с dfdaemon внутри Dragonfly.
Журнал очень важен для отладки и трассировки. Директория журнала dfget — это $HOME/.small-dragonfly/logs/dfclient.log.
Директория метаданных dfget — это $HOME/.small-dragonfly/meta.Эта директория кэширует список адресов локального узла (IP, имя хоста, IDC, доменной безопасности и т.д.), управляемых узлов и сверхузлов.
Когда клиент Dragonfly запускается впервые, он обращается к управляемому узлу. Управляемый узел получает информацию о доменной безопасности, IDC, геолокации и другой информации об этом узле через запрос к armory, а затем назначает наиболее подходящий сверхузел. Управляемый узел также распределяет списки адресов всех остальных сверхузлов. dfget сохраняет указанную выше информацию в директории метаданных на локальном устройстве. Когда следующая задача начинается, dfget читает метаданные из этой директории, избегая повторной проверки управления узлом.
dfget всегда находит наиболее подходящий назначенный узел для регистрации. Если это невозможно, он просит другие сверхузлы последовательно. Если все они неудачны, он просит управляемый узел ещё раз, обновляет метаданные и повторяет вышеперечисленные шаги. Если это всё равно не удается, задача провалится.
Примечание: если журнал
dfclient.logуказывает, что регистрация сверхузла постоянно проваливается, попробуйте удалить все файлы из директории метаданных и попробуйте снова.
По умолчанию временная директория данных dfget находится в пути $HOME/.small-dragonfly/data, который в настоящее время не может быть настроен.По умолчанию временная директория данных dfdaemon находится в пути $HOME/.small-dragonfly/dfdaemon/data, которая может быть настроена с помощью флага --localrepo.
Когда dfdaemon скачивает образы через dfget, он устанавливает путь целевого файла dfget, который является временной директорией данных dfdaemon. Таким образом, dfget будет загружать файл в $HOME/.small-dragonfly/data и перемещать его в $HOME/.small-dragonfly/dfdaemon/data после завершения загрузки.
Обычно Dragonfly автоматически удаляет файлы, которые не были доступны в течение трёх минут из списка загружаемых файлов, а также оставшиеся файлы, которые живут более одного часа из директории данных.
Следуйте этим шагам для ручной очистки директории данных:
dfget, начатого другими аккаунтами.dfget с аккаунтом, указанным на шаге 1. Этот процесс автоматически удалит оставшиеся файлы из директории данных.В настоящее время Dragonfly не поддерживает получение образов из реестра с включённым HTTPS.dfdaemon является прокси между контейнерным движком и реестром. Он захватывает каждый запрос, отправленный от контейнерного движка к реестру, фильтрует все запросы на загрузку слоёв образов и использует dfget для их загрузки.Нам следует рассмотреть реализацию HTTPS-прокси и сделать так, чтобы dfdaemon мог получать HTTP-данные из TCP-данных, анализировать их и правильно загружать слои образов.
Мы планируем поддерживать эту функцию в версии Dragonfly 0.5.0.
Да, Dragonfly поддерживает получение приватного образа, требующего аутентификации имени пользователя/пароля. Например, когда пользователь хочет получить приватные образы из реестров Docker (например, Docker Hub https://index.docker.io/), добавьте информацию об аутентификации пользователя для приватных образов в файл /root/.docker/config.json. Формат файла config.json после добавления информации об аутентификации будет выглядеть следующим образом:
{
"auths": {
"https://index.docker.io/v1/": {
"auth": "${auth_value}"
}
}
}
Для генерации значения ${auth_value} используйте следующую команду:
echo -n "${username}:${password}" | base64
Суперузел и узлы dfget вместе строят пиринговую сеть. Лог работы dfget будет содержать информацию о том, откуда получен блок — от суперузла или другого узла dfget.
Пользователи могут получить лог dfget из файла $HOME/.small-dragonfly/logs/dfclient.log, а затем найти ключевые слова downloading piece. Если префикс поля dstCid равен cdnnode, то этот блок был получен от суперузла, в противном случае он был получен от узла dfget.```
2019-02-13 15:20:45.757 INFO sign:31923-1550042443.708 : downloading piece:{"taskID":"b4b0f175f7aef583ff6ff8da6b00024d7772b165caa66ff8ef3a9dce6701b690","superNode":"127.0.0.1","dstCid":"cdnnode:127.0.0.1~b4b0f175f7aef583ff6ff8da6b00024d7772b165caa66ff8ef3a9dce6701b690","range":"0-4194303","result":503,"status":701,"pieceSize":4194304,"pieceNum":0}
2019-02-13 15:22:40.062 INFO sign:32047-1550042560.044 : downloading piece:{"taskID":"b4b0f175f7aef583ff6ff8da6b00024d7772b165caa66ff8ef3a9dce6701b690","superNode":"127.0.0.1","dstCid":"127.0.0.1-31923-1550042443.708","range":"0-4194303","result":503,"status":701,"pieceSize":4194304,"pieceNum":0}
## How to view all task logs in dfget
You can follow these steps:
- Find a completed task with an error: `grep 'download FAIL' dfclient.log`, for example:
```sh
2019-05-22 05:40:58.120 INFO sign:38923-1558496382.915 : download FAIL cost:75.208s length:4120442 reason:0
Retrieve all logs of this task using the tag 38923-1558496382.915: grep 38923-1558496382.915 dfclient.log, for example:
2019-05-22 05:39:42.919 INFO sign:38923-1558496382.915 : get cmd params:["dfget" "-u" "https://xxx" "-o" "./a.test"]
...
...
2019-05-22 05:40:58.120 INFO sign:38923-1558496382.915 : download FAIL cost:75.208s length:4120442 reason:0
Firstly, we will state that yes, it is possible.
| Here is the list of ports that DragonFly will use:Название | Значение по умолчанию | Описание |
|---|---|---|
| порт сервера прокси dfdaemon | 65001 | Порт, который будет прослушивать сервер прокси dfdaemon. |
| порт сервера загрузчика dfget | случайное | Порт, который будет прослушивать сервер загрузчика dfget. |
| порт регистрации supernode | 8002 | Используется клиентами для регистрации себя как участников p2p-сети в supernode. |
| порт CDN-сервера файлов supernode | 8001 | Используется клиентами для скачивания частей файлов с supernode.И каждый элемент в вышеуказанной таблице может быть самостоятельно указан. |
| Название | Флаг | Примечание |
|---|---|---|
| порт сервера прокси dfdaemon | dfdaemon --port | Порт должен находиться в диапазоне от 2000 до 65535. |
| порт сервера загрузчика dfget | dfget server --port | Вы можете использовать команду dfget server, чтобы запустить сервер загрузчика перед использованием dfget для загрузки, если не хотите использовать случайный порт. |
| порт регистрации supernode | supernode --port | Вы можете использовать dfget --node host:port, чтобы зарегистрироваться с помощью указанного порта регистрации supernode. |
| порт CDN-сервера файлов supernode | supernode --download-port | Вам следует подготовить сервер файлов и прослушивать порт, используемый флагом download-port. |
ЗАМЕЧАНИЕ: Supernode поддерживает как версию на Java, так и версию на Go в настоящее время. А вышеуказанная таблица предназначена для версии на Go. Для версии на Java вы получите руководство здесь.
-v /etc/localtime:/etc/localtime:ro перед запуском контейнера. Например, вы можете запустить следующую команду, чтобы начать dfclient.```shdocker run -d --name dfclient
-v /etc/localtime:/etc/localtime:ro
-p 65001:65001
dragonflyoss/dfclient:1.0.2 --registry https://index.docker.io
## Как стать членом Dragonfly
Пожалуйста, проверьте [CONTRIBUTING.md](CONTRIBUTING.md#join-dragonfly-as-a-member)
## Как dfget подключается к суперузлам в режиме нескольких суперузлов
Если суперузлы настроены в режиме нескольких суперузлов, то dfget случайным образом подключается к одному из этих суперузлов.
Это происходит потому что dfget случайным образом упорядочивает все известные ему суперузлы и хранит их в слайсе.
Если dfget неудачно подключается к первому суперузлу, он пытается подключиться ко второму суперузлу в этом слайсе.
И так далее до тех пор, пока все известные суперузлы дважды не окажутся недоступными, тогда dfget завершает работу с ошибкой загрузки.
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )