Хабрахабр

Переезд хуже пожара: как перевезти 3Тб данных с Dropbox на Google Drive и выжить

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

За это время команда выросла с 2 до 35 человек, и в этом году мы поняли, что пора прощаться с Dropbox и переезжать на Google Drive. Поэтому ещё 5 лет назад, основав «Банду умников» и делая тестовый тираж, мы уже хранили все данные в Dropbox — благо они тогда умещались в бесплатные лимиты. Это решение вызвало череду приключений, которые мы совсем не планировали.

В нашем случае причина была простой: мы сели, посчитали и поняли, что вместо 12 аккаунтов с безлимитным хранилищем у нас может быть 35 аккаунтов (то есть вся команда) — и всё это ровно за те же деньги. Для переезда с одного облачного сервиса на другой может быть куча разных причин: от риска блокировок (привет, Роскомнадзор) до потребности в каком-то принципиально новом функционале.

Не то, чтобы мы думали, будто перенос всех данных состоится по щелчку пальцев, но всё же на берегу представляли себе переезд куда проще. Но фраза «сказано — сделано» не случайно встречается только в сказках. А зря.

Вот 6 важных моментов, которые мы открыли для себя в процессе смены облачного провайдера.

1. За привычным порядком скрывается хаос

Когда 35 человек работают с какими-то данными, неизбежно появляются лишние файлы: дублированные или вовсе неактуальные. Со временем они множатся и распределяются относительно ровным слоем по всей структуре облачного диска.

В этом случае проще понять, что нужно, а что нет. Полбеды, если они заботливо сложены в папку «Макеты 2011 архив». Самостоятельно оценить, насколько конкретный файл важен, почти нереально: нужно каждый раз выяснять, кто пользуется тем или иным документом или папкой, насколько важно это хранить и переносить. Куда хуже, когда это «Новая папка (2)», а в ней файл «ааааааааааааасысыв.psd». Кроме этого, даже полезные и актуальные документы порой оказывались в неожиданных и неочевидных местах.

image

Поэтому мы попросили команду «причесать» существующую структуру данных: каждый брал свой блок и упорядочивал его в порядке от общего к частному, чтобы даже человеку, который никогда раньше не сталкивался с тем или иным документом, было понятно, где его найти: Актуальная общая информация \ Логотип и фирменный стиль \ Логотип (РУС и ENG).

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

Сначала мы распределяли зоны ответственности, потом проверяли логику новой структуры, что-то дорабатывали, разбирались с «бесхозными» файлами. Важно, что наведение порядка — далеко не самая быстрая штука. Всё это делалось параллельно с текущей работой и заняло около трёх недель.

В результате мы получили максимально прозрачную и логичную структуру папок и избавились от 1/4 объёма файлов.

Но приключения только начинались.

2. Автоматической миграции не существует

После наведения порядка, нам предстояло перенести с Dropbox на Google Drive 3 терабайта данных. Первое, что пришло в голову: «Наверное, существует какой-то сервис, который позволяет сделать это автоматически — так, чтобы нажать на кнопку в пятницу вечером и пойти загорать».

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

  • Список пользователей, которые участвуют в работе с данными;
  • Структура доступа: к каким папкам имеет доступ тот или иной пользователь;
  • Уровень доступа к той или иной папке: просмотр, комментирование, редактирование, передача прав и т.д.

В итоге мы поняли, что ни один из рассмотренных сервисов не позволяет перенести 3 Тб данных с сохранением структуры и уровней доступа. Более того, расчётное время «переезда» с помощью таких инструментов составляло несколько месяцев. Это нас категорически не устраивало.

3. Перенос данных — путь через тернии к звёздам

Мы арендуем хранилище в data-центре, который работает на серверной операционной системе Windows Server 2012. Оказалось, что, в отличие от Dropbox, Google Drive её не просто не поддерживает. Наше «гениальное» решение запустить процесс копирования напрямую оказалось технически нереализуемым на существующем ПО.

Им потребовалось время, чтобы поднять «десятку» на нашем пуле мощностей. Тогда мы обратились к data-центру с просьбой: «Ребята, а вы можете развернуть на серверных мощностях образ Windows 10?» Партнёры удивились — судя по всему, наш запрос был не самым популярным. Теперь можно было копировать данные. Когда это удалось сделать, мы установили там две программы: Dropbox и Google Drive — в обеих залогинились под одним сотрудником, назначенным владельцем всех папок.

Если бы мы просто запустили перенос данных, дождались завершения и успокоились, мы бы получили в новом хранилище кучу неактуальной информации, потому что во время копирования папок в них ведётся работа: вносятся изменения в существующие файлы, создаются новые. Проблема была в том, что за раз (например, за одну ночь) невозможно было перенести все данные: процесс занимал минимум несколько недель.

Программа видит новые файлы и обнаруживает изменения свойств всех ранее загруженных файлов, как бы подавая сигнал: «Файл создан, догрузи. Поэтому за первый заход мы скопировали весь объём данных, актуальный на дату начала копирования, а потом с помощью программы xStarter ежедневно догружали только те файлы, которые были изменены или созданы. Со временем догрузки становились всё меньше по объёму. Файл изменился, загрузи заново». Объём финальной догрузки составлял 20 Гб, вся процедура заняла несколько часов. Перед выходными мы перевели весь Dropbox в режим чтения, чтобы никто не внёс изменения, и запустили финальный перенос. Сравните с 3 Тб в начале.

image

В понедельник утром мы получили полностью актуальные структурированные данные на диске Google Drive. Уже после переноса всех данных, мы заново настроили все параметры, связанные с доступом сотрудников к разным папкам и доработали структуру.

4. Инструктаж — всему голова

Чтобы всем было понятно, как быстро начать работать с данными в новых условиях, мы сделали и опубликовали подробную инструкцию.

image

Вот основные её элементы:

Чтобы разобраться, что где лежит, не приходилось копаться во всех папках — достаточно было посмотреть на карту. • Новая структура папок, наглядно изображённая в Mindmeister. На условном примере это выглядело так: Плюс ко всему, новая структура файлов стала максимально логичной.

Полет в космос
1. 1. Постройка ракеты
1. 1. 1. 1. 1. Архив ракет
1. Актуальная схема ракеты
1. 2. Архив документации
1. 2. Актуальный план-график запуска
3.

• Инструкция по установке и работе с программой Google Drive.

• Основные отличия в работе Google и Dropbox, чтобы позже они не стали неожиданным открытием.

• Правила работы с личными и общими папками.

Инструкция позволила ответить на 90% возникающих вопросов и существенно сэкономить время: как тех, кто мог бы озадачиться вопросом, так и тех, кому бы предстояло отвечать.

Как бы не так! Всё, хэппи энд?

5. Если не контролировать поток данных, начинается давка

В первый же день работы в Google Drive выяснилось: мы не учли заранее, что ребятам нужно иметь у себя часть данных в офлайн-режиме, а не в виде ссылок на файлы в облаке — например, тяжёлые макеты. Когда дизайнеры стали одновременно грузить себе в папки все исходники и макеты, нашему интернет-каналу стало плохо. Очень плохо. Часть процессов в компании просто встала — не работала даже 1C. Теперь, оглядываясь назад, мы понимаем, что нам следовало предпринять заранее:

Главное правило: не грузить всё и сразу. A. Договорится с ребятами о щадящем графике загрузки. По возможности делать это ночью или на выходных. Сначала только те файлы, с которыми прямо сейчас работаем, потом следующие по приоритетности, и так далее.

Это позволяет исключает ситуацию, когда из 100 Мбит канала 90 сразу забирают трое дизайнеров, а остальные 32 человека вынуждены делить 10 Мбит. B. Заранее попросить сисадмина настроить квоты на сетевом оборудовании, когда у каждого есть своя гарантированная полоса.

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

Допустим, VOIP и RDP подключения сдалать самыми приоритетными, чтобы всегда работал скайп и удалённые сервера. D. Настроить приоритет трафику. Для этих целей мы выбрали оборудование MikroTik и без проблем всё настроили. Важная деталь: не всё сетевое оборудование имеет такую опцию.

6. Неисповедимы пути Google Drive

В первые дни работы выяснилась ещё одна неприятная особенность, после обнаружения которой мы точно будем вдвое внимательнее проверять всё ПО перед запуском. Когда мы включали оффлайн-доступ к папке или файлу в программе Google Drive, весь кэш сохранялся… только на диске «C». Возможность выбора в настройках диска для сохранения кэша отсутствовала.

Проблемы начинаются, когда нужен офлайн-доступ к макетам и исходникам видео, каждый из которых может весить гигабайты. Не беда, если это 10 текстовых документов, с которыми работает копирайтер. При его объёме 250 Гб это быстро приводило к переполнению, а диск «D» на 4 Тб оставался незадействованным в этом процессе. В итоге у дизайнеров кэш всех файлов падал на маленький SSD-диск с системой.

Возможность внести изменения есть только у администратора, который для этого запускает специальную команду в редакторе реестров — а отдельный пользователь по-прежнему не имеет такой возможности. Позже выяснилось, что Google Drive только недавно реализовал функцию, позволяющую изменить место хранения кэша тех файлов, которые находятся в оффлайн-доступе — с диска «C» на диск «D».

Вывод простой: перед принятием решения о запуске нового ПО, его следует внимательно и многократно тестировать во всех рабочих сценариях.

Три коротких вывода

1. Выбор подходящего облака — жизненно важная штука.

В случае ошибки и последующего разочарования в выборе можно «попасть» на переезд. Здесь надо внимательно взвесить все за и против: изучить тарифы, софт и функционал. А это, мягко говоря, нетривиальная процедура, которая может заморозить всю работу и повлечь за собой немалые затраты.

2. Полезно всегда держать файлы в порядке и на всякий случай иметь план «B».

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

3. Переезд — это не только про технику, но и про команду.

Может и разберутся, но без прозрачного и заботливого инструктажа работа этот процесс будет куда более трудозатратным и изматывающим. Все манипуляции с переносом файлов и наведением порядка могут обернуться полным провалом, если не держать команду в курсе и действовать по принципу «разберутся как-нибудь сами».

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть