Миграция информационная система. Этапы процесса миграции данных в проектах внедрения ис

Миграция информационная система. Этапы процесса миграции данных в проектах внедрения ис
Миграция информационная система. Этапы процесса миграции данных в проектах внедрения ис
05.03.2020

Перевод существующей информационной системы (ИС) компании на любую новую платформу, в том числе и на Microsoft Windows 2000, - сложная и трудоемкая задача, решение которой требует системного подхода и планирования.

Конкретный план работ по внедрению ОС Windows 2000 и компонентов BackOffice Server 2000 (именно такой комплекс мы и называем в данной статьей платформой Windows 2000) зависит от масштаба и особенностей вашей организации. В общем случае «правильный» план работ выглядит следующим образом:

  • анализируется существующая ИС компании;
  • планируется структура новой ИС, использующая все преимущества платформы Windows 2000;
  • выполняется пилотный проект;
  • устанавливается и настраивается программное обеспечение.

Анализ существующей системы

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

Анализ аппаратного обеспечения. Основные цели - определить, соответствует ли аппаратное обеспечение требованиям платформы Windows 2000, и определить варианты его наиболее эффективного использования. Важно, что при переходе на Windows 2000 необязательно отказываться от использования устаревшей техники - например, при использовании терминального сервера устаревшая техника будет работать даже с большей эффективностью, чем под управлением предыдущих версий Windows (см. В. Жирнов, «Терминальные решения», Enterprise Partner №15/2000, с. 24).

Анализ структуры коммуникаций. Основная цель - прорисовка детального плана коммуникаций, который можно будет использовать на этапе планирования структуры новой ИС.

Анализ сетевой инфраструктуры. Цель - построение схем, отражающих текущее состояние сетевой инфраструктуры организации. В ходе его определяется, какие используются сетевые службы, протоколы и т.д.

Составление перечня серверного ПО и используемых приложений. Цель - получение сводного отчета, в котором будут перечислены характеристики серверов, функции, которые они выполняют, используемые приложения. После составления этого отчета проводится комплексный анализ возможности перевода информационной инфраструктуры на платформу Microsoft Windows 2000; при этом рассматривается возможность оптимизировать использование имеющихся серверов.

По итогам первого этапа вы получите комплексное представление о текущем состоянии ИС и выясните, насколько она соответствует требованиям платформы Windows 2000, а также каковы приблизительные сроки и стоимость полного цикла работ по переводу системы на эту платформу.

Планирование структуры новой системы

Следует разработать несколько вариантов логической архитектуры ИС и ее аппаратно-программной реализации, в соответствии с приоритетными направлениями деятельности и интересами компании. Обычно данный этап включает разработку нескольких планов.

План информационной инфраструктуры компании по окончании миграции. В нем отражается будущая доменная структура компании, организация сетевых сервисов, обеспечение безопасного доступа в Интернет, почтовая инфраструктура, схемы резервного копирования и восстановления серверов в случае аппаратных сбоев. Кроме того, предусматривается возможность восстановления прежней инфраструктуры компании - на случай возникновения проблем при переводе серверов на платформу Windows 2000. Новое решение можно внедрять параллельно существующему. Например, если хранилище данных компании основано на СУБД Oracle и было принято решение о переходе на СУБД Microsoft SQL Server 2000, то можно создать такое решение, которое позволит сосуществовать этим двум системам на тестовый период. Тем самым снижается до минимума возможность сбоев или простоев и обеспечивается плавный переход на новую платформу.

План миграции серверов. В нем описывается порядок перевода серверов на платформу Windows 2000, формулируется список требований, которые должны выполняться при миграции. Фактически это станет основным документом, по которому будут работать инженеры, выполняющие миграцию.

План миграции клиентских компьютеров. Описывает последовательность и порядок обновления существующих в организации платформ.

План миграции серверов приложений. В зависимости от потребностей компании могут быть разработаны планы и схемы миграции существующей инфраструктуры почтовых серверов или серверов баз данных на платформу Windows 2000. Если необходимо, могут быть разработаны и схемы безопасного доступа в Интернет из офиса компании, а также схемы доступа к информационным ресурсам компании для сотрудников, находящихся вне офиса, с применением различных технологий. Возможна разработка схем создания защищенных каналов связи между географически распределенными офисами.

Итогом второго этапа должен стать календарный план-график работ по построению ИС на базе платформы Microsoft Windows 2000, с указанием видов работ, их сроков и стоимости, а также с описанием ожидаемой функциональности системы.

Пилотный проект

На данном этапе необходимо протестировать работу критичных бизнес-приложений и функций в условиях, приближенных к платформе Windows 2000. Можно смоделировать работу критичных приложений на тестовом стенде, имитирующем внедряемую структуру. Можно провести различного рода тестирования оборудования, с тем чтобы выяснить возможности использования различных конфигураций и настроек программного и аппаратного обеспечения. Можно провести сравнительное тестирование имеющейся и внедряемой систем, например, тестирование текущих линий связи с целью выяснения возможностей использования VPN-каналов или синхронизации Windows 2000 Active Directory. Кроме того, на данном этапе можно протестировать используемые в настоящий момент приложения на платформе Windows 2000.

Именно в результате третьего этапа будет подготовлена почва для успешной реализации основного проекта. На этом этапе неминуемо возникнут проблемы, и одна из целей этапа - изучить эти проблемы и выработать рекомендации по их решению и предупреждению.

Установка и настройка программного обеспечения

Заключительный этап, в ходе которого проводятся работы по установке и настройке программного обеспечения, переносу приложений и бизнес-процессов в новую среду, комплексное тестирование внедряемого решения.

Как видите, описание этого этапа занимает в статье минимум места - именно потому, что он должен быть полностью описан в ходе трех подготовительных этапов. Осуществляться он должен в кратчайшие сроки. Итогом должна стать установленная, налаженная и протестированная ИС, в полной мере реализующая возможности платформы Microsoft Windows 2000. И если вы не пренебрегли подготовительными этапами и привлекли к проекту профессиональных исполнителей, то так оно и будет.

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

В любом случае процесс миграции данных распадается на несколько взаимосвязанных последовательных этапов, в настоящем исследовании будут последовательно рассмотрены все шаги процесса миграции по методологии Oracle и IBM .

Жизненный цикл процесса миграции начинается после формирования стратегии и оценки рисков этапа миграции данных. Схема процесса миграции представлена на диаграмме процесса.

Целью любого процесса миграции данных является маппинг информации, типов и форматов данных старой системы с типами и форматами данных новой системы. При миграции данных этапу «Data Extraction» соответствует выбор и выгрузка данных из старой системы, а этапу «Data Loading» соответствует перенос полученных данных старой системы и их загрузка в новую систему. Ниже процесс миграции будет рассмотрен более детально.

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

Этап сбора требований к данным для миграции, как правило, очень тесно взаимосвязан со следующим этапом - разработки алгоритмов переноса данных из системы-источника в целевую систему. На этапе проектирования аналитиками создаются подробные спецификации с описанием типов данных системы-источника и их взаимосвязей с типами данных целевой системы. В таких спецификациях описывается структура данных для миграции, их объемы, источник, назначение. Спецификация является источником для постановки задач разработчику, который будет проектировать и разрабатывать специализированное ПО для переноса данных. На этапе проектирования проводится анализ существующей архитектуры данных в системе-источнике - анализ «as is» и разработка архитектуры данных в целевой системе - «to be». При анализе существующей архитектуры данных выявляются и учитываются все ограничения и ИТ-инфраструктуре, а также их влияние на работу целевой системы с мигрированными данными. Выходными артефактами анализа архитектуры данных могут являться такие документы, как логические модели данных (ER-диаграммы, модели баз данных), словари и справочники с детальным описанием каждого элемента и его атрибутов, описание бизнес-правил работы с данными, сведения о системах, взаимодействующих с системой-источником при информационном обмене и интеграции.

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

Описанные выше этапы анализа и планирования можно объединить в общий подготовительный этап. Разработанные процедуры и механизмы миграции регламентируют этапы извлечения, переноса и загрузки данных в новую систему, то есть осуществляются последовательно все шаги ETL-процесса. После получения необходимых для миграции данных наступает фаза загрузки этих данных в целевую систему, перед началом которой необходимо выделить отдельный этап - верификация мигрируемого контента.

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

Мероприятия тестирования не ограничиваются параллельной эксплуатацией системы-источника и целевой системы. Тесты могут проводиться на выборках из мигрируемых данных с целью раннего выявления ошибок и их исправления до начала разработки миграционного ПО. Более ранняя ликвидация ошибок позволяет экономить бюджет и избежать повторных загрузок данных. К работам по тестированию могут быть отнесены мероприятия по аудиту данных в процессе миграции. Аудит данных позволяет отслеживать состояние данных и избежать ошибок, вызванных изменениями в контенте, которые могут быть внесены пользователями уже во время проведения работ по миграции.

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

Методология проведения миграции данных, приведенная выше, предполагает, что наиболее «узким» местом при организации данного этапа проекта является этап планирования и работы с бизнес-требованиями заказчика, то есть сбор требований и проектирование, поэтому рассмотрим подходы к решению задач этих этапов подробнее в следующих частях работы. Помимо этапов планирования и разработки бизнес-требований особое внимание стоит уделить этапу оценки результатов работ этапа миграции данных, так как в соответствии с циклом Деминга (PDCA) , именно проведение мероприятий по оценке работ является условием успешности проведения аналогичных работ в аналогичных проектах.

1.1. Особенности планирования миграции данных

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

  • - Документ о рамках миграции данных;
  • - План работ по миграции данных с указанием ответственных членов проектной команды;
  • - План коммуникаций на этапе миграции.

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

Пакеты работ на этапе миграции должны соответствовать фазам жизненного цикла процесса, примерная структура плана-графика работ может быть следующей:

  • - Планирование и обозначение рамок миграции данных;
  • - Бизнес-анализ и документирование требований;
  • - Выбор, настройка или проектирование и разработка специализированного ПО;
  • - Перенос данных;
  • - Валидация мигрированных данных;
  • - Опытная эксплуатация;
  • - Пост-миграционные работы по очистке и тестированию;
  • - Согласование результатов миграции, оценка и закрытие этапа проекта внедрения.

Назначение ответственных членов проектной команды за выполнение пакетов работ этапа миграции данных происходит на этапе планирования после составления плана работ.

Выбранным проектным ролям приведены в соответствие кластеры - зоны ответственности, определенные в методологии MSF . Стоит отдельно отметить, что под управлением продуктом в контексте миграции будем понимать управление качеством мигрированных данных и работоспособностью целевой системы после миграции. Управление релизами (выпусками) в терминах процесса миграции - осуществление итераций процесса миграции, получение и загрузка данных миграции.

В соответствии с моделью MSF предполагается следующее распределение зон ответственности между ролевыми кластерами:

  • - Системный аналитик - управление программой, удовлетворение потребителя;
  • - Менеджер по разработке - управление программой, управление продуктом, управление выпуском;
  • - Разработчик - разработка алгоритмов или специализированного ПО для переноса данных в целевую Систему, специализированного ПО (при необходимости);
  • - Тестировщик - тестирование, управление выпуском.

Для того чтобы наглядно продемонстрировать участие привлеченных человеческих ресурсов в мероприятиях процесса миграции данных составим матрицу RACI - приведена в приложении 1 к работе (см. Приложение 1 - Матрица RACI для работ по миграции данных).

Нужно оговориться, что менеджер по разработке (технический менеджер) рассматривается как лидер команды, занимающейся миграцией данных, поэтому он несет ответственность за проведение всего процесса, в целом. Однако если миграция данных проводится в рамках масштабного проекта внедрения ИС, где назначен менеджер всего проекта, то технический менеджер этапа миграции будет только исполнителем в задачах, касающихся определения сроков и подбора персонала. Решения по вопросам персонала, ресурсов и сроков в таком случае принимается менеджментом проекта коллегиально.

Достаточно часто у многих пользователей возникает вопрос, связанный с тем, как осуществить перенос Windows 10 с HDD на SSD, поскольку твердотельные накопители являются намного более быстрыми. Сейчас будет рассмотрено, зачем это нужно, а также приведены некоторые основные методы, позволяющие осуществить данную операцию без особых усилий и затрат по времени.

Зачем нужен перенос на SSD, и какие преимущества получает пользователь?

Для начала давайте определимся, зачем вообще пытаться проделывать такие операции. Тут все дело в том, что, как уже говорилось выше, винчестеры SSD-типа обладают большей скоростью считывания данных по сравнению с обычными HDD-дисками.

Отсюда напрашивается самый простой вывод: после того как будет выполнен перенос Windows 10 на SSD-накопитель, система станет работать намного быстрее, как принято говорить, «летать». На новый винчестер предполагается скопировать исключительно операционную систему , без всякого стороннего мусора. При всем этом, если отдать предпочтение некоторым специфичным программным продуктам по или предназначенных для переноса системы с HDD на SSD, в некоторых случаях можно скопировать только саму систему, клонировать Windows со всеми установленными в ней программами и пользовательскими файлами , даже сформировать образы со всеми пользовательскими настройками. Здесь, как уже понятно, основное условие - выбор соответствующей программы в зависимости от того, что нужно получить в итоге. Но обо всем по порядку.

Общие принципы переноса системы на SSD-накопитель

Оговоримся сразу: глубоко заблуждаются все те пользователи, которые считают, быстрый перенос Windows 10 на SSD можно осуществить обычным копированием всех файлов и папок, пусть даже скрытых. Ничего путного из этого не выйдет, а сама система попросту не загрузится. Здесь нужно применять другую методику. При этом возможным является использование и Windows 10, и сторонних программных продуктов, специально для этого предназначенных. Перенос Windows 10 на SSD и в первом, и во втором случае осуществляется достаточно просто и не требует особых усилий или специальных знаний.

С помощью утилиты Winaero WEI tool можно произвести расчет производительности операционной системы. После переноса Виндовс 10, показатель «Primary Hard Drive » был увеличен с 5.6 до 7.95.

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

А потом восстановить их в чистой установке Windows . Однако я уверен, что найдутся люди, которые захотят перенести тщательно настроенную систему с одного диска на другой. Изначально я не планировал эту запись, но получив очередной вопрос по почте, решил осветить этот несложный процесс в блоге.

Для клонирования дисков есть специальные программы (например, Acronis или Paragon). В них маркетинговый фокус нередко делается именно на переносе системы с HDD на SSD, как и в заголовке этого руководства:) Однако можно решить эту задачу с помощью бесплатных средств Microsoft, обходясь без неприятных неожиданностей , причем мои инструкции применимы к любым типам дисков.

Я хочу подчеркнуть, что это руководство описывает процесс клонирования системы и ее переноса на другой диск в рамках одного и того же ПК . Перенос системы на другой ПК (даже с такой же аппаратной конфигурацией) поддерживается только для образов, обобщенных с помощью утилиты sysprep . Формально Microsoft вообще не поддерживает клонирование без sysprep (даже сторонним ПО). В предлагаемом мной методе поддержке препятствует несколько технических ограничений, но я не считаю их существенными для домашних ПК.

Сегодня в программе

Вам понадобятся…

Для начала давайте определимся с терминологией. Там, где вы видите фразы «установочный диск», «диск Windows PE», «диск восстановления», с равным успехом можно использовать как оптический диск (CD/DVD), так и съемный USB-диск (флэшку).

Итак, вам нужны:

  1. Среда в любой форме. Это может быть:
  • установочный диск Windows
  • среда восстановления на диске восстановления, соответствующий операционной системе (см. инструкции для Windows 7 или для Windows 8 и выше)
  • созданный вами диск Windows PE 3.1 или 4.0
  • Внешний или внутренний диск, на котором достаточного свободного пространства для сохранения сжатого образа системного раздела.
  • Умение загружаться в Windows PE и определяться с буквами дисков .
  • Утилита imagex той же разрядности, что и среда Windows PE. Утилита может находиться где угодно, за исключением раздела, который вы клонируете.

    • Почему imagex и где взять утилиту

    Здравствуйте друзья! Мне часто доводилось переносить и с простого жёсткого диска HDD на SSD. Применял в основном программы: , Paragon Migrate OS to SSD, Paragon Домашний Эксперт 12 и AOMEI Partition Assistant Home Edition. Самый долгий, но интересный, способ перенести Windows 7 с HDD на SSD с помощью встроенных в Windows средств.

    1. Кому интересен процесс переноса программой Paragon Домашний Эксперт 12, переходите по ссылке и читайте статью.
    2. Ещё вам будут интересны наши новые статьи
    3. Если Вас заинтересовала статья, посетите специальный раздел , где собраны с одного накопителя информации на другой.

    Самый простой и удивительно быстрый способ перенести Windows 7 с HDD на SSD с помощью программы Paragon Migrate OS to SSD , с помощью этой программы я и предлагаю Вам сегодня осуществить перенос системы на SSD.

    Программа платная, стоит целое состояние 390 рублей. Если у вас Windows 8, то для миграции подойдёт только последняя версия программы Paragon Migrate OS to SSD 3.0.

    Сайт http://www.paragon.ru/home/migrate-OS-to-SSD


    Важное примечание: Если у вас установлена программа Paragon Домашний Эксперт 12, то утилита Paragon Migrate OS to SSD входит в пакет этой программы.


    Если вы хотите перенести Windows 7 с HDD на SSD с помощью Paragon Домашний Эксперт 12 перейдите в конец этой статьи, там есть небольшая инструкция.

    После переноса операционной системы с HDD на SSD нужно проверить корректность выравнивания разделов диска относительно архитектуры SSD. Выравненные разделы гарантируют максимальную производительность , скорость работы и долговечность вашего твердотельного накопителя SSD , поверьте, это очень важно. Корректность выравнивания разделов будем проверять бесплатной утилитой AS SSD Benchmark.

    Как перенести Windows 7 с HDD на SSD с помощью программы Paragon Migrate OS to SSD

    Итак обратите внимание на окно Управления дисками моего компьютера, имеется жёсткий диск объёмом 250 ГБ, поделённый на два раздела, на одном из них - диске (C:) находится операционная система Windows 7, её и будем переносить на твердотельный накопитель SSD объём 120 ГБ, представляющий из себя нераспределённое пространство.


    Запускаем программу Paragon Migrate OS to SSD. Next.


    Программа автоматически нашла мой диск SSD и готова к переносу операционной системы. Обратите внимание на пункт «Use all available space for the partition with OS», поставьте здесь обязательно галочку и всё пространство твердотельного накопителя будет отведено для создания одного нового диска (C:) с перенесённой Windows. Ведь твердотельные накопители и используются в основном только для установки операционной системы.
    Если нажать на «Please select what folders should be copied», то вы можете выбрать нужные для копирования папки. Мне нужна вся Windows целиком, поэтому я оставлю всё как есть.



    Жмём на кнопку Copy.


    Происходит подозрительно недолгий процесс миграции безо всяких перезагрузок.


    Мне невольно вспомнился старый добрый Acronis True Image, где нужно было создать образ операционной системы, затем развернуть его на SSD, хотя Acronis работает и безупречно, но времени занимает в несколько раз больше.

    Пока мы с вами вели речь про Acronis, программа Paragon Migrate OS to SSD уже перенесла нашу Windows 7 на SSD. Финальное окно, в котором нам предлагают загрузиться уже с твердотельного накопителя SSD. Перезагружаемся.


    Теперь нужно войти в БИОС и выставить загрузку с SSD. Выбираем Меню загрузки (F8).


    С помощью стрелок на клавиатуре выбираем наш твердотельный накопитель и жмём Enter. Происходит загрузка компьютера с SSD.


    Примечание: Чем мне нравится БИОС UEFI, так это наличием собственного загрузчика, который вмещает в себя все имеющиеся загрузчики и никогда в них не запутается. БИОС UEFI помнит последнюю загруженную Вами операционку и в следующий раз загрузит именно её. Переключение между операционными системами (сколько бы у вас их не было установлено) происходит просто, быстро и безошибочно.

    Если у вас обычный БИОС, то перенос должен произойти тоже без проблем. Единственное что вам нужно сделать, то найти в нём параметр ответственный за главенство жёстких дисков Hard Disk Drives (AMI BIOS) или Hard Disk Boot Priority (AWARD BIOS) и выставить первым устройством ваш SSD. Как найти эти параметры, можно узнать в.

    Требования к компьютеру

    Прежде чем выполнять какие-либо действия по переносу ОС, убедитесь, что ваше устройство отвечает всем минимальным требованиям, которые позволяют утилите взаимодействовать с SSD и переносить большие объемы данных. Минимальные требования указаны в следующей таблице:

    Сравнить параметры вашего компьютера с указанными выше характеристиками можно с помощью окна «О системе». Оно отображает правильные данные о главных аппаратных и программных компонентах девайса:

    Рис.2 – окно просмотра параметров Windows и компьютера

    Используем встроенные возможности Виндоус

    Следуйте инструкции, чтобы выполнить перенос операционной системы на флеш-устройство:

    • Откройте окно «Управление дисками». Для этого в окне выполнить пропишите команду diskmgmt.msc и подтвердите действие;

    Рис.3 – запуск средства управления дисками

    • Теперь нужно уменьшить объем ОС на диске. Выполнить действие можно с помощью функции «Сжать том». Все данные останутся в прежнем состоянии, только занимаемое место на HDD уменьшится. Кликните правой клавишей на раздел «System», а затем на «Сжать том»;

    Рис.4 – Сжатие тома

    • После успешного уменьшения объема ОС, в схеме диска появится свободный раздел. Это означает, что всё было сделано правильно;
    • Подключите накопитель к компьютеру и перезагрузите окно «Управление дисками»;
    • Теперь кликните на вкладке «Мастер» и в списке выберите «Перенос OS SSD»;

    Рис.5 -вкладка «Мастер»

    • Откроется стандартная утилита для клонирования операционной системы. Нажмите на клавишу «Далее», чтобы перейти к настройкам;
    • Кликните на пункт «Незанятое пространство» и перейдите в следующее окно;

    Рис.6 – выбор дискового пространства

    • Теперь вы можете самостоятельно изменить размер будущего диска или же оставить все параметры без изменений;

    Рис.7 – изменение размера раздела диска

    • После нажатия на клавишу «Далее» мастер начнёт перемещение системы. После завершения действия вы сможете выключить компьютер и при следующей загрузке выбрать ту ОС, которая находится на SSD.

    Windows на твердом диске тоже останется. Вы можете удалить её или же использовать в качестве резервной копии , когда понадобится восстановить систему.

    Рис.8 – результат успешного перемещения Виндоус

    Не забудьте нажать на клавишу «Применить» в левой верхней части окна «Управление дисками», иначе все внесённые изменения не будут сохранены. Если во время переноса возникали окна с ошибками или зависания, следует сбросить настройки, перезагрузить ПК и попробовать выполнить перенос еще раз.

    Рис.9 - применение изменений

    Инструкция для SSD от Samsung

    Выпустила официальную утилиту, которая позволяет быстро переместить ОС из жесткого диска на приобретённый флеш-накопитель. Утилита называется Samsung Data Migration. Загрузить её можно бесплатно с официального сайта компании (раздел «Память»-«SSD») или с помощью диска, который есть в комплектации устройства.

    Начальное окно программы выглядит следующим образом:

    Рис.10 – окно утилиты Samsung Data Migration

    Сразу после запуска утилиты подключите к компьютеру SSD с помощью соответствующего переходника. Кликните на клавишу «Начать». Далее приложение автоматически просканирует используемый HDD и выведет на экран информацию об оставшемся свободном месте и разделах носителя.

    Рис.11 – анализ диска с установленной копией Windows

    После анализа программа автоматически определит присоединённый к компьютеру SSD и покажет его на экране:

    Рис.12 – сверка исходного и конечного диска

    Если место, которое занимает Windows на HDD не превышает доступное место на SSD, вы можете сразу приступать к переносу, нажав на клавишу «Начать». Начнётся автоматическое перемещение всех компонентов. Процедура может занять от 30 минут до 1.5 часов, в зависимости от используемой версии Windows.

    Рис.13 - успешный перенос системы

    В результате, вы получите уведомление об успешном клонировании операционной системы на флеш-накопитель. Закройте окно и удалите все данные о Windows из HDD.

    Плюс использования Samsung Data Migration заключается в простом интерфейсе. Программа сделает всю работу за вас и максимально снизит вероятность появления ошибок или багов после переноса ОС.

    Что делать, если на этапе анализа вы обнаружили, что места для ОС не хватает на SSD? В таком случае, необходимо очистить Windows от неиспользуемых данных и приложений. Сделать это можно прямо в окне утилиты Samsung Data Migration.

    Рис.14 – Ошибка. Недостаточно места на SSD

    После появления текста ошибки (подсвечен красным цветом) нажмите на кнопку «Далее» и в новом окне удалите все файлы библиотеки, которые захламляют систему. Проводите очистку ОС до тех пор, пока в главном окне утилиты не появится текст «Готово к клонированию на SSD».

    Рис.15 – успешная очистка лишних файлов

    Утилита Acronis True Image

    Рис.16 – главное окно приложения Acroins

    Для перемещения системы подключите съемный носитель к компьютеру и в окне программы кликните на плитку «Клонирование диска»-«Копирование разделов». В открывшемся окне выберите автоматический режим перемещения. Он подходит для всех задач и быстро выполняет копирование данных.

    Рис.17 - выбор режима клонирования

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

    Рис.18 – процесс копирования

    Утилита Seagate DiscWizard

    Утилита полностью повторяет интерфейс Acronis. Её нужно использовать в том случае, если на вашем ПК есть хотя бы один жесткий диск от производителя Seagate. Для клонирования следует выполнить те же действия, которые были описаны в предыдущем пункте статьи.

    Рис.19 – главное окно Seagate Disc Wizard

    Изменение конфигурации загрузчика

    После клонирования системы на компьютере останется копия ОС, а при каждой загрузке будет появляться окно с выбором загрузки. После переноса советуем выполнить ряд действий:

    • Не удаляя первоначальную копию с HDD, протестируйте работу Windows на HDD. Бывают случаи, когда система начинает тормозить, ухудшается производительность. Это происходит крайне редко и зависит исключительно от выбранного SSD. Пока первая копия не удалена, у вас всегда будет возможность вернуться к её использованию и удалить ОС с SSD;
    • Измените настройки загрузчика системы.

    Диспетчер загрузки – это встроенный компонент, с помощью которого компьютер определяет, какую из установленных ОС запускать. Также, можно настроить порядок запуска аппаратных компонентов.

    Сразу после клонирования в диспетчере будут показаны две системы с идентичными названиями – первоначальная и скопированная. В случае нормальной работы Windows на SSD, нужно удалить ту версию, которая осталась на жестком диске компьютера. Следуйте инструкции:

    • Перезагрузите ПК и запустите ту версию, которая перемещена на флеш-накопитель;
    • Откройте командную строку Windows;
    • Введите указанную на рисунке ниже команду, задав копии ОС на SSD уникальное имя;

    Многое изменилось в мире информационных технологий за последние 32 года, с тех пор как Microsoft выпустила Windows 1.0. Единственное, что осталось прежним, - сложность процессов миграции, или перехода на новую версию операционной системы, и развертывания обновлений. Если спросить пользователей, чего они хотят от миграции, вы получите ответ: плавного перехода с минимальными простоями и привычного взаимодействия с рабочим столом. Некоторые заявят, что вообще против миграции, но таких обычно немного.

    Для чего нужна миграция

    Существует много причин в пользу миграции на уровне настольных компьютеров. Две основные - безопасность и стоимость эксплуатации. Разработчики Microsoft неуклонно повышали безопасность настольных операционных систем; список технологий обеспечения безопасности, которых не было в старых версиях, производит сильное впечатление. Угрозы становятся все более изощренными, и Microsoft пришлось добавить такие функции, как запуск на первом этапе загрузки антивредоносного решения ELAM (https://docs.microsoft.com/en-us/windows-hardware/drivers/install/early-launch-antimalware) и управляемый доступ к папкам (https://docs.microsoft.com/en-us/windows/threat-protection/windows-defender-exploit-guard/controlled-folders-exploit-guard), превосходный способ защиты от программ-шантажистов, сам по себе достаточный повод задуматься о миграции. Безопасность - особенно серьезная проблема для компаний, все еще работающих с версиями операционной системы Windows 7 (и даже Windows XP), поскольку с тех пор угрозы значительно изменились, и усовершенствования, внесенные в Windows 10, в некотором отношении представляют самый начальный и не всегда достаточный уровень безопасности.

    Операционные затраты - еще один важный фактор; миграция часто бывает привязана к аппаратным средствам и циклам обновления комплекса средств Microsoft Office, поэтому все больше компаний рассматривают вопрос виртуализации, чтобы разорвать зависимость от оборудования и обновлений настольной операционной системы. Даже компании, желающие сохранить физическое оборудование, может привлечь потенциальная экономия от работы с версией Windows текущего поколения на современном оборудовании.

    Процесс миграции

    На приведенном рисунке показана простая схема основных этапов процесса миграции.

    Рисунок. Основные этапы процесса миграции

    Существует много разных подходов к тому, как проводить каждый этап; целые книги написаны о том, как выполнять, например, пилотные ИТ-проекты. Коротко рассмотрим каждый этап с позиций миграции.

    Инвентаризация среды

    Многие компании располагают развитыми системами инвентаризации и управления, с помощью которых можно получить ответы на вопросы типа «как много активно используемых настольных компьютеров работает с Windows 8.1 с пакетом обновления 2?» или «сколько ноутбуков Dell XPS 13 имеется в наличии?» Системы управления, такие как System Center Configuration Manager (SCCM) и Microsoft Intune, можно задействовать для инвентаризации, если вы располагаете достаточными средствами и развернули их. В противном случае вам, возможно, придется прибегнуть к менее эффективным методам, например запросить отзывы пользователей, подготовить средство инвентаризации и продвигать его через групповую политику или вручную выполнить инвентаризацию и настроить параметры систем. Ключевое условие на данном этапе - получить точную модель существующих систем, чтобы правильно планировать нужное состояние.

    Проектирование требуемого состояния

    Термин «проектирование требуемого состояния» подразумевает поиск вида, к которому мы хотим привести нашу среду в будущем. Более того, на данном этапе строится перспективный план для реализации ваших намерений. План для достижения нужного состояния при миграции должен содержать следующую информацию.

    • Что вы переносите из исходного пункта (необходима инвентаризация среды).
    • Что вы переносите в пункт назначения. При этом необходимо ответить на многочисленные вопросы, в том числе: на какую версию Windows выполняется переход? Вы остаетесь на физических настольных компьютерах, переходите в локальную виртуальную среду или перемещаетесь в «облако»? Как будет настроена целевая среда? Что делать в случае сбоя миграции или невозможности переноса систем?
    • Ваше расписание. Большинству компаний приходится выполнять миграцию в течение продолжительного периода, а не одним гигантским прыжком. Когда следует переводить тех или иных пользователей? Как выглядит расписание в целом и как на нем отражаются внешние события (например, начало учебного года, конец финансового года или сезон распродаж)?
    • Ваш бизнес. Вы выполняете миграцию для достижения определенных целей? Возможно, существуют бизнес-приложения, которые необходимо перенести, или особые требования нормативных актов либо соответствия к новой среде.

    Цель данного этапа - помочь вам понять, какими должны быть возможности завершенной среды и как перейти из вашей текущей ситуации в нужное положение. Здесь невозможно потратить слишком много времени или уделить чрезмерное внимание деталям. Старая пословица - семь раз отмерь, один раз отрежь - лучшее руководство к действию. На этом этапе обычно не требуется вносить какие-либо изменения в среду.

    Приступаем к созданию прототипа

    Теперь вы приступаете к строительству среды, описанной на этапе проектирования требуемого состояния. Представьте, что вы строите дом: вы начинаете на пустом участке земли, вынимаете грунт, заливаете бетон для фундамента и начинаете возводить стены. Существует определенный минимальный объем работ, который необходимо выполнить, чтобы въехать в дом, но вы можете жить и в недостроенном доме. То же относится и к миграции: прежде чем выполнить пилотный проект, по крайней мере часть новой среды должна быть спроектирована, построена и протестирована. Например, для внутренних развертываний инфраструктуры виртуальных рабочих столов VDI потребуется создать среду гипервизора соответствующего размера, получить нужные лицензии и т. д., прежде чем можно будет перенести в рамках пилотного проекта один настольный компьютер. Но не обязательно полностью строить всю среду требуемого состояния. Расписание данного этапа часто составляют таким образом, чтобы согласовать развертывание различных компонентов с реальной миграцией.

    Одно из достоинств этапа строительства - удобная возможность предусмотреть дополнительные меры предосторожности в расписании. Дело в том, что в зависимости от природы миграции небольшое число пользователей в рамках пилотного проекта обычно можно перевести на новую платформу в самом начале. Это позволяет профилактически контролировать среду и устранять любые возникающие проблемы, а также экспериментировать с инструментами и настройками, прежде чем их получат все пользователи пилотного проекта.

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

    Пилотный этап

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

    Хотя это действие не считается отдельным этапом, данный момент самый подходящий, чтобы познакомить пользователей с новой средой. Было бы прекрасно, если бы можно было развернуть новую настольную среду, не обучая пользователей, но в действительности необходимо выделить время для ознакомления пользователей с особенностями среды. Имея стабильную пилотную программу, вы можете проводить демонстрации, записывать обучающие видеофильмы или предоставить пользователям «песочницу» с ограниченным доступом к новой среде в процессе обучения. Не забудьте, что обучение, вероятно, понадобится и техникам группы поддержки. Не исключено, что потребуется дополнительный персонал, чтобы справиться с возросшим потоком запросов на обслуживание: «Не могу найти функцию X» - типичная жалоба на ранних стадиях миграции.

    Развертывание

    Основные события происходят на этапе полномасштабного развертывания. Этот этап миграции не сильно отличается от любого другого сложного технического проекта: вы определяете график миграции различных групп пользователей, а затем выполняете запланированные шаги, решая проблемы по мере их возникновения. Если этапы построения прототипа и пилотный проект выполнены грамотно, у вас не должно возникнуть серьезных новых проблем. Как правило, при проектировании данного этапа лучше проявлять осторожность; если вы планируете переносить 100 настольных компьютеров в неделю, а в действительности вам удается переносить 150, это лучше, чем планировать 150, а сделать 100. Не забудьте о праздниках, отпусках и других ограничениях, связанных с персоналом. Для успешного развертывания необходимо учитывать, что вы переносите среду, от которой зависит работа пользователей, поэтому делать это нужно так, чтобы они испытали как можно меньше неудобств.

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

    Эксплуатация

    Этап эксплуатации немного скучен, поскольку вынуждает вернуться к тому, с чего вы начали: обычной поддержке и операциям управления в стабильной среде. На данном этапе выполняется повседневная работа по обслуживанию новой среды, в том числе исправление неполадок, с которыми сталкиваются пользователи, тестирование и применение регулярных обновлений безопасности от поставщика. Пилотный этап подобен подъездной дороге к процессу миграции, а данный этап - автострада; вы без затруднений движетесь на постоянной скорости (по крайней мере, до следующего крупного обновления от Microsoft).

    Упрощение процесса

    Правильный выбор инструментов позволит заметно упростить пилотный этап и выпуск в производство. Пользователи должны иметь возможность работать с минимальными неудобствами, и лучший способ удовлетворить эту потребность - продуманное проектирование, миграция профиля и управляемые решения разных компаний. Например, компания Liquidware предлагает пакет Workspace Environment Management, который поможет выполнить каждый этап миграции Windows, в том числе оценку и проектирование с использованием Stratusphere, и миграцию с помощью ProfileUnity User Management. Stratusphere обнаруживает установленные и используемые приложения и помогает оценить и подготовить оборудование для Windows 10. С помощью ProfileUnity можно без проблем переносить профили пользователей между любыми версиями Windows и значительно уменьшить трудоемкость миграции. Технология Profile Bridge, применяемая в ProfileUnity, позволяет поместить профили пользователей в контейнеры и без проблем работать с ними на разных версиях Windows, совместимых как в обратном, так и в прямом направлении. Благодаря функциональности ProfileUnity сокращается время перемещения и синхронизации, и вы можете выполнять развертывание на настольных компьютерах, ноутбуках, виртуальных и «облачных» системах, чтобы обеспечить пользователям привычную среду на всех устройствах одновременно.

    Любой бизнес стремится тратить как можно меньше, в том числе на ИТ. Один из способов сэкономить - перенести информационные системы в облако. При переносе данных в виртуализированную среду надо учесть требования законодательства о хранении и обработке персональных данных. Эти требования касаются любой организации.

    О тонкостях процесса миграции нам рассказал Владимир Лебедев, директор по развитию бизнеса Stack Group .

    Требования законодательства

    В 2006 году был принят 152-ФЗ «О персональных данных» , который призван защитить физических лиц при автоматизированной обработке персональных данных. В прошлом году вступил в силу пакет поправок о локализации персональных данных на территории России, что, по мнению авторов, должно повысить уровень информационной безопасности внутри государства и простимулировать российский рынок технологических решений и рынок информационной безопасности.

    По закону бизнес обязан собирать, хранить и обрабатывать персональные данные на территории РФ. Все требования совершенно одинаковы как для российских, так и для зарубежных компаний, если их деятельность направлена на территорию России. При этом передавать персональные данные за пределы страны можно, но они должны быть неизменяемыми, и их объем не должен превышать объем в российских базах данных.

    Для кого закон?

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

    В план проверок Роскомнадзора на 2016 год вошли: крупнейшие софтверные компании, международные банки, сетевые торговые компании и интернет-магазины.

    Сложности переноса персональных данных для международных компаний

    Зачастую глобальные международные игроки, чтобы выполнить требования законодательства, вынуждены переносить в Россию не только сами данные, но и все сопутствующие системы: компаниям с централизованными ИТ-системами крайне сложно изменить архитектуру информационной системы под одно локальное законодательство, потому что изначально в ней не было разнесенных центров обработки информации. Чтобы перестроить информационные системы, требуются существенные инвестиции.

    Виртуализация

    Переехать в облачную среду менее затратно, чем покупать и монтировать оборудование. В конце 2014 года цены на российские облака были в среднем на 15–30% выше, чем на европейские, а в конце 2015 года, наоборот, наши цены стали на 20–30% ниже: изменился валютный курс и относительная стоимость размещения в российских дата-центрах.

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

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

    Риски, возникающие при миграции систем хранения данных

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

    Этапы миграции в облако

    Общие принципы миграции сервиса, то есть переноса операционных систем, отвечающих за работу этого сервиса, в виртуализированную среду, рассмотрим на примере решения VMware vSphere .

    Архитектуру информационных систем компании желательно разделить на выполняющие конкретные задачи сервисы. Обычно в облако перемещается все, кроме сервисов, которые несовместимы с cloud-технологией по техническим причинам (RISC-архитектура) и тех, что нельзя переместить из-за лицензии.

    Далее необходим аудит информационных систем . На этом этапе определяется состав сервисов (какие ОС относятся к тому или иному сервису), а также их связность. Главная сложность заключается в многообразии исходных ОС и физической архитектуры серверов, на которых они работают. На основе этой информации составляется план миграции с учетом текущих бизнес-процессов: определяются требования к связности физической и виртуальной инфраструктур, порядок миграции, задаются допустимые «окна миграции». Важно помнить, что нельзя во время миграции обновлять версии программных продуктов или операционных систем. Одновременно с миграцией допускается только пересмотр вычислительных ресурсов (CPU, RAM, HDD).

    Как правило, для миграции используется утилита VMware converter , которая эффективно работает при переносе ОС семейства Microsoft Windows (но у миграции работающих в этих ОС служб есть свои нюансы). А вот из-за особенностей файловых систем Linux примерно в 40% случаев после окончания работы VMware converter виртуальная машина может не запуститься. Если в Linux используется LVM, то надо развернуть в виртуальной среде новый экземпляр ОС из шаблона провайдера и затем перенести данные, программные продукты и внутренние службы.

    Для любого типа ОС есть общие условия, затрудняющие миграцию: во-первых, способ хранения данных, из-за которого прямая миграция невозможна, - это динамические диски в Windows или LVM в Linux, а во-вторых, сложности из-за использования программных и аппаратных массивов RAID. Так, даже точный перенос данных сам по себе не гарантирует, что виртуальная машина успешно запустится. На физическом сервере работу виртуальных машин обеспечивает гипервизор - ОС, разделяющая физический сервер на несколько виртуальных машин, которые могут работать одновременно и использовать одни и те же физические ресурсы. Естественно, что набор виртуального оборудования у гипервизора не совпадает с оборудованием физического сервера, на котором работала ОС до миграции. Соответственно, из-за разницы драйверов возникает множество отличий доступа к этому оборудованию.

    Миграция ADDS и MS SQL без остановки сервисов

    Практически всегда для бизнеса необходимо, чтобы ряд сервисов оставался доступным в ходе миграции. При этом зачастую миграция без остановки сервиса рекомендуется как самая надежная. Поэтому рассмотрим особенности миграции без остановки наиболее популярных служб ОС Microsoft: Active Directory Domain Services (ADDS или AD) и Microsoft SQL (MS SQL). Для миграции Active Directory без остановки службы применяется следующий алгоритм:

    • Формируется сетевая связность между физическим оборудованием и виртуализированной средой. Как правило, это site-to-site VPN - он создает логическую сеть поверх другой сети. При этом трафик может быть защищен шифрованием по протоколам IPsec.
    • В облаке разворачиваем новые виртуальные машины из шаблона, где настраиваем контроллеры домена AD с добавлением их в лес.
    • Базу данных Active Directory реплицируем по сети через VPN с работающих контроллеров на стороне физического оборудования в облачные.
    • После репликации данных переназначаем мастеры ролей операций на облачные контроллеры и убираем роли контроллеров домена с серверов.
    • Затем проверяем работу сервисов и отключаем учетные записи старых контроллеров и физическое оборудование.

    Алгоритм миграции MS SQL более сложен, так как MS SQL обычно применятся в многоуровневом сервисе в качестве бэкенда. В записях DNS в приложениях, использующих базы данных (в клиентах MS SQL), приходится вручную указывать новое расположение базы данных. Поэтому совсем исключить простой нельзя, но его можно свести к минимуму. Существуют механизмы и безостановочной миграции MS SQL, к ним относятся Mirroring и AlwaysOn , но их применение не всегда оправданно. AlwaysOn доступен только в дорогих редакциях Enterprise-уровня, а Mirroring должен поддерживаться клиентами MS SQL. К тому же для применения механизмов Mirroring нужна дополнительная настройка всех клиентов MS SQL.
    Рассмотрим наиболее частый вариант миграции MS SQL в облако:

    • Настраивается сетевая связность между облаком и физическим оборудованием.
    • Убеждаемся, что модель восстановления базы MS SQL полная, тогда можно сделать и перенести полную резервную копию, а затем синхронизировать обе базы данных, перенося копии транзакционных логов.
    • В облаке разворачиваем виртуальную машину из шаблона, в которой устанавливаем и настраиваем новый MS SQL сервер.
    • Создаем полную резервную копию базы данных MS SQL сервера, работающего на физическом сервере, затем восстанавливаем ее в облачном, при этом способ переноса резервной копии зависит от размеров файла и пропускной способности сети - перемещаем на физическом носителе либо копируем по сети.
    • После восстановления базы данных в облаке делаем копию транзакционных логов и их также восстанавливаем в облаке.
    • Во время «окна миграции» останавливаем работающий на физическом оборудовании MS SQL сервер, создаем и восстанавливаем последнюю минимальную по размеру копию транзакционных логов в облаке, запускаем MS SQL сервер в облаке и переключаем клиенты на новое месторасположение базы.
    • Проверяем работу сервисов, отключаем физическое оборудование.

    Для каждой службы и сервиса существует множество способов миграции, зависящих от условий. Избежать трудностей, которые могут возникать при миграции, поможет сервис-провайдер.

    Информационная безопасность

    Компании должны не только перенести данные в Россию, но и обеспечить надлежащий уровень информационной безопасности их хранения.

    В перечне документов, определяющих требования и описывающих меры, необходимые для защиты информационных систем, на первом месте находится, разумеется, сам закон, который устанавливает общие требования. Конкретные действия регламентируются постановлениями Правительства РФ и нормативными документами ФСТЭК (Федеральная служба по техническому и экспортному контролю) и ФСБ (Федеральная служба безопасности).

    Требования к хранению персональных данных

    Требования к технической защите конфиденциальной информации и предоставлению услуг по защите информации достаточно четко сформулированы. Инструменты их реализации многообразны. В частности, это могут быть сетевые экраны, системы обнаружения вторжений, средства анализа защищенности, антивирусной защиты, средства защиты сред виртуализации. На рынке представлен широкий спектр средств защиты информации - и российских, и зарубежных вендоров. Есть уже правоприменительная практика, так как закон действует с 2007 года. В целом подход к регулированию в России отличается от, например, европейского подхода. Так, в России неисполнение предписанных требований по информационной безопасности ведет к возникновению ответственности. А на Западе компания может самостоятельно определять, каким способом выполнять требования, и ответственность наступает, только если совершены неправомерные действия с персональными данными.

    Требования к инфраструктуре

    Определенные требования регуляторы предъявляют и к инфраструктуре. Например, существует аттестация построенных автоматизированных систем, обеспечивающих защиту информации . Аттестат выдается независимой лабораторией, которая подтверждает, что инфраструктура готова и соответствует всем требованиям по защищенности информационных систем. Этот аттестат необязателен для коммерческих организаций, но дает возможность понять, что дата-центр имеет необходимую защиту и способен обеспечить безопасность данных компании.

    Также есть международные стандарты ISO, регламентирующие построение системы управления информационной безопасностью (комплекс стандартов ISO 2700х ). Многие иностранные компании соответствуют этим стандартам.

    Кроме того, применяется модель аутсорсинга по защите данных. Компании, предоставляющие такие услуги, должны иметь необходимые лицензии и компетенции.

    INFO

    В Китае полная копия персональных данных должна храниться на территории страны, а любые банковские данные вообще запрещено передавать за ее пределы.

    Прогноз на перенос

    Довольно сложно подсчитать, сколько точно данных подлежат переносу в Россию, но, исходя из заполняемости рынка ЦОД, можно сказать, что мощностей вполне достаточно для локализации данных в соответствии с законом. Например, на рынке Московского региона наблюдается переизбыток мощностей: общая емкость составляет около 27 тысяч стоек , и почти 40% из них свободны. Многие дата-центры имеют площади высокой степени готовности. Нужно учесть и что плотность данных в одной стойке может различаться в зависимости от оборудования. Сегодня один юнит серверной стойки обрабатывает значительно больше информации, чем несколько лет назад.

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