...

понедельник, 28 мая 2018 г.

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

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

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

Для переезда с одного облачного сервиса на другой может быть куча разных причин: от риска блокировок (привет, Роскомнадзор) до потребности в каком-то принципиально новом функционале. В нашем случае причина была простой: мы сели, посчитали и поняли, что вместо 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 ежедневно догружали только те файлы, которые были изменены или созданы. Программа видит новые файлы и обнаруживает изменения свойств всех ранее загруженных файлов, как бы подавая сигнал: «Файл создан, догрузи. Файл изменился, загрузи заново». Со временем догрузки становились всё меньше по объёму. Перед выходными мы перевели весь Dropbox в режим чтения, чтобы никто не внёс изменения, и запустили финальный перенос. Объём финальной догрузки составлял 20 Гб, вся процедура заняла несколько часов. Сравните с 3 Тб в начале.

image

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

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


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

image

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

Let's block ads! (Why?)

Комментариев нет:

Отправить комментарий