Смерть, развод, переезд — три наиболее стрессовых ситуаций в жизни любого человека.
«Американская история ужасов».
— Андрюх, я из дома ухожу, помоги с переездом, ко мне всё не влезет:(
— Хорошо, а много там?
— Тонн* 7-8…
*Тонна (жарг.) — Терабайт.
Недавно, в процессе интернет-сёрфинга, я обратил внимание на то, что несмотря на доступность на Хабре и на аналогичных ему ресурсах множества материалов о способах и моделях миграции различных типов данных, в сети всё ещё появляются вопросы по этой теме. Которые, почему-то, не всегда удостаиваются обстоятельных ответов. Этот факт и сподвиг меня однажды собрать заметки о реализации похожего решения и оформить их в виде отдельного поста.
Вообще, переносить данные с одних устройств, систем и сервисов на другие мне приходится с некоторой назойливой периодичностью. Которая, путём проб и ошибок позволила мне не только познакомиться с массой интересных продуктов, но и найти баланс между функционалом и стоимостью решения, о котором хочу рассказать
Проектирование
Как оказалось в результате проектно-изыскательских работ, качество и оперативность процесса миграции зависит не только от технических характеристик «площадок», где находятся или будут находиться данные, но и от их физического местоположения.
Миграционный менеджер — вычислительный узел, на котором функционирует «логика» процесса — ПО для управления миграцией.
То есть, всего существуют две модели размещения «миграционного менеджера»
- Модель А. Если хотя бы к одной из площадок есть доступ только изнутри локальной сети, то в этой же сети стоит размещать и «миграционного менеджера». Ибо производительность и время миграции всё равно ограничены скоростью и аптаймом канала, площадки связывающие.
- Модель B. Если и к источнику, и к приёмнику данных есть доступ за пределами локального сети, то «миграционного менеджера» стоит селить там, где скорость и аптайм канала между ними будет заведомо лучше.
Чтобы как-то декомпозировать вышесказанное, предлагаю вернуться к задачам из основного вопроса статьи, и формализовать их в техническое задание.
Для начала необходимо выяснить, поддерживает ли используемое мной программное обеспечение «облака»: Mail.ru, Yandex, Google Drive, Mega, Nextloud?
Короткий ответ: «ДА!»
Я использую Rclone.
Rclone — rsync для облачных хранилищ. Open Source ПО предназначенное для синхронизации файлов и папок более чем с 45 типами и видами хранилищ.
— Amazon S3
— Ceph
— DigitalOcean Spaces
— Dropbox
— Google Cloud Storage
— Google Drive
— Google Photos
— HTTP
— IBM COS S3
— Mail.ru Cloud
— Mega
— Microsoft Azure Blob Storage
— Microsoft OneDrive
— Minio
— Nextcloud
— Openstack Swift
— Oracle Cloud Storage
— ownCloud
— Rackspace Cloud Files
— rsync.net
— SFTP
— WebDAV
— Yandex Disk
— Сохранение временных меток создания/изменения файлов.
— Поддержка частичной синхронизации.
— Копирование только новых файлов.
— Синхронизация (односторонняя).
— Проверка файлов (по хэшам).
— Возможность синхронизации из одного облачного аккаунта в другой.
— Поддержка шифрования.
— Поддержка локального кэширования файлов.
— Возможность монтирования облачных сервисов через FUSE.
От себя добавлю, что Rclone также помогает мне решать львиную долю задач связанных с автоматизацией резервирования данных в проекте «Väinämöinen».
Следующая задача — выбор модели размещения «миграционного менеджера».
Ко всем источникам данных — коими являются различные публичные облачные сервисы, есть доступ через интернет. В том числе и через API. У двух из трёх приёмников — тоже. Неясно только где развёрнут сам Nextcloud и какой доступ к нему есть?
Возможных вариантов я насчитал пять:
- На собственном сервере в домашней/корпоративной сети.
- На собственном сервере в арендуемой стойке дата-центра сервис-провайдера.
- На арендуемом у сервис-провайдера сервере.
- На виртуальном сервере (VDS/VPS) у сервис/хостинг-провайдера
- У сервис-провайдера по модели SaaS
Учитывая то, что Nextcloud это всё-таки ПО для создания и использования облачного хранилища, можно смело утверждать что доступ к нему через интернет доступен во всех пяти вариантах. И оптимальным в этом случае моделью размещения «миграционного менеджера» станет — модель B.
Согласно выбранной в качестве площадки для «миграционного менеджера» модели, я выберу один из оптимальных, с моей точки зрения, вариантов — виртуальный сервер в дата-центре М9 крупнейшей в России точки обмена интернет-трафиком MSK-IX.
Третье решение, которое необходимо принять — это определиться с конфигурацией виртуального сервера.
При выборе параметров конфигурации
Если планируется запускать несколько процессов миграции, да ещё и определённой периодичностью, то стоит рассмотреть вариант аренды
Создание
Согласно вышеизложенному, при создании прототипа для этой статьи я выбрал
стоимостью 560 руб./мес. с учётом 15% скидки по купону NOSTRESS.
Такой выбор обусловлен тем, что узел под ОС Windows, для соответствия условиям нашего ТЗ, настраивается легче, чем под другие ОС, доступные к заказу.
Оффтопик: Кстати, для пущей безопасности, этот виртуальный сервер назначен одним из узлов защищенной виртуальной сети. и доступ к нему по RDP разрешён только оттуда…
После создания
После подготовки окружения загружаем архив с программным пакетом Rclone для Windows и распаковываем его.
Далее — в режиме командной строки Windows выполняем команду перехода в папку с извлечёнными файлами. У меня она располагается в домашней папке администратора:
C:UsersAdministrator>cd rclone
После перехода — выполняем команду запуска Rclone c Web-GUI:
C:UsersAdministratorrclone>rclone rcd --rc-web-gui --rc-user=”login” --rc-pass=”password” -L
где “login” и “password”, заданные вами логин и пароль, естественно, без кавычек.
По факту выполнения команды в терминале выводится
2020/05/17 22:34:10 NOTICE: Web GUI exists. Update skipped.
2020/05/17 22:34:10 NOTICE: Serving Web GUI
2020/05/17 22:34:10 NOTICE: Serving remote control on http://127.0.0.1:5572/
а в браузере автоматически открывается графический веб-интерфейс Rclone.
Несмотря на то, что Web-GUI ещё находится в стадии тестовой версии и не обладает пока всеми возможностями управления Rclone, которые есть у интерфейса командной строки, его возможностей вполне достаточно для осуществления миграции данных. И даже чуть больше.
Настройка
Следующим этапом мы настроим подключения к площадкам где находятся или будут находится данные. И первым в очереди будет основной приёмник данных — Nextcloud.
1. Для этого переходим в раздел Configs Web-GUI.
2. Инициируем создание новой конфигурации — кнопка New Config.
3. Задаём имя площадке — поле Name of this drive (For your reference): Nextcloud.
4. Выбираем тип или вид хранилища Select: Для Nextcloud и Owncloud основной интерфейс обмена данными — WebDAV.
5. Далее кликом на Step 2: Setup drive раскрываем список параметров соединения и заполняем.
— 5.1. URL of http host to connect to URL — гипертекстовая ссылка интерфейса WebDAV. В Nextcloud находятся в настройках — левый нижний угол интерфейса.
— 5.2. Name of the Webdav site/service/software you are using — имя интерфейса WebDAV. Поле необязательное, для себя, чтобы не запутаться если таких подключений много.
— 5.3 User name — Имя пользователя при авторизации
— 5.4. Password — Пароль для авторизации
— 5.5. Bearer token instead of user/pass (eg a Macaroon) и Command to run to get a bearer token в расширенных опциях дополнительные параемтры и команды авторизации. В моём Nextcloud они не задействованы.
6. Далее жмём Create config и для того чтобы убедиться в создании конфигурации, переходим в раздел Сonfig веб-интерфейса… Через эту же страницу вновь созданную конфигурацию можно удалить или отредактировать.
Для того чтобы проверить работоспособность подключения к площадке — переходим в раздел Explorer. В поле Remotes вводим название настроенной площадки и нажимаем Open. Если вы увидели список файлов и каталогов — соединение с площадкой работает.
Для пущей убедительности можете через веб-интерфейс создать/удалить папку или скачать/удалить какой-либо файл.
Второй по порядку подключаемой площадкой будет Яндекс диск.
- Первые четыре шага аналогичны процессу подключения Nextcloud.
- Далее всё оставляем как есть, то есть — поля в Step 2: Setup drive оставляем пустыми, в расширенных опциях ничего не меняем.
- Жмём Сreate Config.
- В браузере открывается страница авторизации на Яндексе, после прохождения которой, сообщение об успешном подключении и предложением вернуться к Rclone.
- Что мы и делаем, проверяя раздел Config.
Миграция
Когда у нас подключены две площадки, мы уже можем осуществить миграцию данных между ними. Собственно процесс похож на проверку работоспособности подключения к Nextcloud, что мы проводили ранее.
- Переходим в Explorer.
- Выбираем шаблон 2-side by side.
- В каждом из Remotes указываем имя своей площадки.
- Жмём Open.
- Видим каталог файлов и папок каждой из них.
Для начала процесса миграции остаётся только выбрать нужную папку с файлами в каталоге источника данных и перетащить её мышкой в каталог приёмника.
Механизм добавления оставшихся площадок и действий по миграции данных между ними аналогичен операциям, выполненным выше. Если в процессе работы вы сталкиваетесь с ошибками, то подробности о них можно изучить в терминале, где запущен Rclone с Web-GUI.
Вообще, документация по Rclone обширна и доступна на сайте и в интернете, и не должна вызвать каких-то сложностей в использовании. На этом, первый пост о том, как перенести файлы с одного облака на другое, минуя свой ПК, считаю завершённым.
P.S. Если вы не согласны с последним утверждением - пишите в комментариях: какая «тема не раскрыта» и в каком ключе стоит продолжать.
Автор: ruvds