О сложных вещах можно иногда говорить и житейскими терминами 😉 И я говорю про маленький офис, который может позволить себе купить такое вот приятное оборудование. Ну и извините за “корявый”, я все больше читатель…

Всегда стоит проблема – вот приехала новая “железка” (в нашем случае – Sun Storage 7000). Все, ее распаковали, “облизали” со всех сторон, особо недоверчивые даже устроили вскрытие, поковырявшись в “мозгах” аппарата (на всякий случай напомню – внутри Sun Storage 7000 нет ничего аппартно-уникального! ВООБЩЕ !), вдоволь наигрались с CLI/shell (“Оо, там же оперсолярис!”), с оболочкой со смешным названием BUI… Попробовали, подключили, успокоились. Даже, возможно, прочли документацию (фантастика, ага, но все-таки есть еще такие). Но тут приходит директор (по вкусу – главный инженер, м.б. – еще кто-то) – и говорит что-то в духе “И мы уже работаем на новой и шикарной системе, на которой есть снапшоты, но почему-то я их не вижу?/У меня закончилось место под важные данные (примечание: фильмы), а вам напомнить сколько бабла мы отдали за эту (показывает на новенький блестящий ящик) хр..ь?!”

И вот тут-то у системщиков в отделе начинается беготня – надо срочно мигрировать данные с одной (старой) машины, пусть это будет старый NFS сервер, на другую, новую, быструю и красивую. Обычные, как то tar, cpio, MC, rlogin, rsync + мильон+маленькая тележка велосипедов, доступных под *NIX-подобной системой, средства всем хороши, но требуют очень длительного простой (ок, поправлю – длительность простоя будет определятся в этом случае рядом факторов, но в первую очередь – объемом данных на старом сервере – пускай у нас лежит 1 терабайт данных). В лучшем случае мы закончим миграцию (на гигабитной сети по NFS) ну пусть за, ммм, 2 часа (или 20? Кто-то позволил себе записать данные в каталогах отчетов?! Надо все начинать по новой?!). Это если мы можем себе позволить 2 часа простоя. А если нет? Начинаем читать про Shadow Migration 🙂

Простые вещи здесь, увы, заканчиваются. Начинается проза жизни 😉

Существуют, с целом, два возможных пути миграции данных. Способ попроще, назовем номер ДВА – это простой перенос данных с помощью стандартных средств *NIX (ну и не только – данные windows-сервера тоже каким-то образом мигрируют) – как то – tar, rsync, cpio (я уже писал выше, этих, простите, повторюсь – велосипедов – множество). Минусы – очевидны – это простой системы. Комментарии – излишни? Если в момент копирования Вы все-таки модифицируете исходные данные, значит, нет очевидной возможности перенести данные?

Есть способ посложнее. Называется External interposition. Назовем номер ТРИ. Как перевести-то? “Разъединение снаружи”?. Впрочем, способ прост до безобразия – между источником данных (нашим исходным NFS-сервером) и новой системой хранения – приемником – ставиться некое устройство (appliance), которое 1) занимается переносом данных из источника в приемник и 2) является сервером с точки зрения клиентов. Плюсов у такого решения предостаточно, в том числе – и минимальный простой. Но и минусы есть, куда же без них. Это и низкая пропускная способность решения (мы будем ограничены пропускной способностью устройства и каналами между серверами), и высокие задержки (само устройство НЕ содержит никаких данных, оно только ссылается на либо источник, либо приемник данных), и дополнительная точка отказа, и дополнительные затраты на обслуживание, и – в конечном итоге – простой, когда данные будут уже перенесены, а устройство пора убирать из конфигурации (справедливости ради отмечу – это все равно неизбежно, и простой в этой ситуации довольно мал – в сравнение с первым способом).

Самый первый способ, номер ОДИН – Shadow Migration – в самом конце. Оставил на сладкое 🙂 Доступен с обновлением 2009.Q3. Что это такое? Это то самое “разъединение” данных из второго способа, но лишенное его недостатков. Каких? Все очень просто. Устройство, которое занимается копированием данных из источника (старый NFS-сервер) в приемник – в этом случае и есть сам приемник. Соответственно, при обращении к данным, которые УЖЕ скопированы – производительность будет равна производительности собственно Sun Storage 7000. Данные, которые еще лежат на старом месте – да, к ним будет идти доступ через нашу новую систему хранения, потом по каналу, поверх которого будет “бежать” NFS, потом собственно данные будут отдаваться со старого сервера с доступной (и характерными) показателями его производительности, но все это будет происходить через новую систему хранения – соответственно, скорее всего, при правильной организации миграции в некоторых случаях будет происходить существенное увеличение производительности – и по мере прохождения процесса миграции данные будут попадать на заведомо более быструю машину, и тем быстрее клиенты будут получать запрошенную информацию. Базовый принцип системы – всегда отдавать файлы только с приемника, то есть – клиент запрашивает некий файл, который еще не скопировался. Приемник
скопирует этот файл с источника (чем и будет обусловлена некоторая задержка при первом доступе), и отдаст его уже на нативной, большой скорости.

В целом, для осуществления процесса миграции нам нужен лишь доступ на Read-Only по NFS (это важный момент – иначе способ номер один 😉 бессмысленный и не сможет гарантировать логической целостности данных). Специальный клиент – не требуется – только NFS-сервер на источнике данных. Специальные познания в области изобретения велосипедов в *NIX-подобных системах – нет, тоже не требуется – достаточно иметь лишь базовые познания. Это если в первом приближение.

“Засады” тоже есть, и не маленькие. Куда же без них – собственно, тоже очевидная вещь – права доступа к файлам. Копирование идет по NFS, соответственно, перед началом копирования надо быть полностью уверенным в том, что системы одинаково “понимают” права доступа (access list) – иначе миграция может потенциально превратиться в головную боль администратора. Вторая проблема – в процессе миграции у нас источник данных, есть копия источника данных и есть объем изменений, произведенный уже на копии в процессе миграции. Как обеспечить целостный бэкап такой конструкции – на вскидку не скажу, надо много подумать 😉 Из некритичных “минусов” – нет прогресса операции, только по косвенным признакам (каким – не буду цитировать документацию).

В целом – очередной шаг вперед! Viva, Sun!