 |
|
|
|
Миграция данных: преимущества, ограничения и правила
Миграция данных:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Вопрос 1. В каких случаях перенос данных, действительно, необходим? И как убедить в этом руководство?
Андрей Коненко
– Во-первых, перенос данных необходим в случае, когда информационная система морально и технически устарела, и ее становится чрезвычайно тяжело обслуживать, база и оборудование уже выработали свои сроки эксплуатации.
Второй случай, это когда текущая информационная система, то есть текущее оборудование, на котором развернута система, не справляется с нагрузкой.
И также перенос данных иногда необходим в рамках оптимизации инфраструктуры. Например, ранее один сервис работал на выделенном оборудовании, а затем в рамках оптимизации затрат на железо мы его переводим на сервер, где есть другие информационные системы.
Решение о затратах при переносе данных остается за бизнесом, поэтому в качестве доводов о необходимости изменений стоит указать риски и целевые показатели при нагрузках. Например, в первом случае, если обслуживание инфраструктуры сопряжено с риском выхода из строя, то стоит предметно описать риск того, что без переезда сервис допустим будет недоступен 5 дней в неделю.
Мы также должны предоставить временные сроки, технологические окна и необходимые затраты. Соответственно, если риски превышают затраты, то любой руководитель будет убежден в необходимости переноса данных. Второй случай, когда необходима миграция на более мощное оборудование, важно объяснить бизнесу, что без этого мы не сможем достичь целевых показателей. А вот в случае переноса данных в рамках оптимизации структуры необходимо описать выгоды, которые бизнес получит после оптимизации.
Данил Вильховский
– Перенос (миграция) данных может быть необходим в различных случаях, включая:
- Обновление информационных систем компании.
- Слияния и поглощения компаний.
- Расширение бизнеса и инфраструктуры.
- Переход на облачные вычисления или перенос виртуальных машин.
Алексей Черепанов
– Перенос данных может быть необходим в следующих случаях:
- Обновление программного обеспечения или аппаратного обеспечения: в случае, если компания обновляет программное или аппаратное обеспечение, миграция данных может понадобиться для переноса данных из старой системы в новую.
- Слияние компаний или подразделений с разными системами хранения данных. При слиянии или поглощении компаний миграция данных может потребоваться для интеграции двух или более систем в одну общую.
- Перемещение данных из локальной сети в облако или наоборот.
Чтобы убедить руководство в необходимости миграции данных, необходимо подготовить бизнес-кейс, который демонстрирует преимущества миграции.
В бизнес-кейсе можно описать, как миграция данных поможет повысить эффективность бизнес-процессов, сократить затраты на обслуживание системы, улучшить качество обработки данных, также обеспечить более безопасное и надежное хранение информации. Кроме того, можно провести демонстрацию и показать, как новая система будет работать в режиме реального времени, чтобы руководство могло оценить ее эффективность на практике.
Игорь Мильберт
– Перенос данных может быть необходим во многих случаях, включая:
- Обновление технической инфраструктуры: когда компания решает обновить или заменить существующую систему, миграция данных становится важной для переноса информации в новую среду.
- Изменение в организационной структуре компании (например, слияние или поглощение компаний): при таком сценарии может потребоваться объединение данных из разных источников в одну общую систему.
- Развитие и расширение бизнеса: при росте компании может возникнуть необходимость перенести данные на более мощные серверы или в облако, чтобы обеспечить устойчивость и масштабируемость.
- То, с чем столкнулись российские компании в последнее время – уход поставщиков ПО с рынка и сворачивание клиентской поддержки. Это влечет за собой желание менеджмента компаний переходить на другое программное обеспечение с переносом исторических данных в новую систему.
Для того, чтобы убедить руководство в необходимости переноса данных, рекомендуется подготовить детальное объяснение преимуществ и пользы, которые миграция данных может принести компании. Это может включать повышение эффективности, улучшение безопасности, снижение издержек и возможность использования новых технологий, а также уменьшение риска потери исторических данных в одном из сценариев, перечисленных выше.
Сергей Головашов
– В России мы сталкиваемся с очень большим дефицитом Центров обработки данных. Помните, как еще несколько лет назад невозможно было разместить собственный сервер на колокейшен, не то, чтобы в М9 или М10, а даже в малоизвестные ЦОДы. То, с какой скоростью растет ИТ-инфраструктура сейчас, просто заставляет всех расширяться и искать новые места для размещения своих вычислительных мощностей. Ковид и СВО, конечно, довольно сильно замедлили этот рост, в частности из-за отсутствия оборудования на рынке, но рост все равно продолжается. Оценку же росту может дать только руководитель, задающий стратегию развития и планирующий перспективы роста предприятия, поэтому убеждать необходимо только реальными цифрами роста и тем, где эти цифры упираются в свой потолок, который как раз преодолеть они смогут только лишь через масштабирование.
Михаил Чусавитин
– Миграция данных в современной, развивающейся ИТ-инфраструктуре – явление частое и местами непрекращающееся. Зарубежные аналитики делают большой акцент на процессах переноса инфраструктуры между различными средами, будь то «облачный» провайдер или другой продукт в «приземленной» инфраструктуре.
Развитию рынка «мобильности данных» способствовали следующие предпосылки:
- Повсеместное использование облачных сервисов ИТ-отделами. Каждый облачный провайдер старается предоставить уникальные сервисы и свою, более оптимальную политику оплаты для завлечения и удержания клиента. С целью оптимизации затрат компании вынуждены использовать уникальные сервисы провайдера и, в конечном счете, это приводит к полной зависимости от выбранной инфраструктуры и невозможности переноса на иную площадку.
- Ускорение развития инфраструктурных продуктов, будь то новая аппаратная платформа, среда виртуализации или СУБД. Даже в рамках одного производителя часто бывает невозможным перенос с устаревшей платформы на более современную.
- Кадровый голод. Среди молодых специалистов сложно найти сотрудников с опытом и желанием работы с устаревшими технологиями, которые силами производителей быстро «выходят из моды», поэтому для поддержания работоспособности выбранной платформы требуется все больше затрат как человеческих, так и финансовых. Часто фиксация на одном выбранном решении не позволяет развиваться ИТ-подразделению компании и является «якорем» развития бизнеса.
- Экономические ограничения, запрет экспорта и импортозамещение – характерные черты российского и, например, китайского ИТ-сегмента. Вводимые санкции и запреты заставляют пользователей отдавать предпочтения альтернативным продуктам, выбирать вместо привычных лидеров ИТ- рынка нишевые или отечественные решения.
Пожалуй, основная проблема, которая беспокоит системных администраторов сегодня – надвигающаяся необходимость перехода на отечественные продукты и решения, тестирование, выбор и миграция инфраструктуры на новый продукт.
Поэтому на основе приведенных тезисов можно сделать вывод о том, что миграция данных, перенос информации между различными средами будут являться насущной проблемой любой развивающейся компании еще долгие годы.
Среди главных показателей процесса миграции специалисты отмечают производительность, защиту данных во время переноса, время простоя и возможность отката к изначальной инфраструктуре и простоту использования.
Сергей Чуканов
– При замене старой системы на новую, например, переходе на отечественное решение, полностью обойтись без миграции данных не получится. Миграция и слияние данных обязательно потребуются и при объединении данных из разных источников: например, при выстраивании централизованной поддержки и принципа единого окна в рамках группы компаний или объединении информационных систем при приобретении сторонней компании.
Руководство будет поддерживать проект миграции в случае применения разумного подхода к определению объема переносимых данных. Переносить только ту информацию, которая минимально необходима для работы, существенно не усложняя и не затягивая проект перехода.
Александр Иванников
– Когда нет возможности быстро запустить проект, масштабироваться. Ведь обновление собственной инфраструктуры – долгосрочный процесс. Здесь облачные ресурсы помогают быстро развернуть свой сервис в облаке, и также свернуть его, и не тратить бюджеты за «простой» мощностей. Либо когда ваша инфраструктура подвержена сбоям или часто недоступна, тогда перенос данных в облако поможет обеспечить непрерывный доступ к вашим данным.
Убедить руководство в такой необходимости помогут аргументы, которые подчеркнут выгоду для компании и бизнеса, через экономические выгоды, с той точки зрения, что приобретать своё оборудование невыгодно для компаний. Проще и выгоднее арендовать вычислительные мощности и экономить на обслуживании, ведь оборудование изнашивается и устаревает через 3-4 года и требует следующих вложений. Возможно, стоит подготовить бизнес-кейс, который покажет все преимущества: снижение затрат, повышение гибкости и доступности приложений, улучшение безопасности данных.
Артур Галимарданов
– Чаще всего встречаются две основные причины – требования регуляторов и видимые высокие риски, связанные с использованием текущего ПО. Если в первом случае руководство убеждать не надо, то во втором – будет тяжелее. В основном, если вероятность рисков и их влияние высоки – решение по переносу обычно утверждается руководством.
Владислав Билай
– Необходимость переноса данных:
- Текущая система устарела или не удовлетворяет потребностям компании.
- Это финансово более выгодно.
- Необходима централизация данных из нескольких систем.
Можно убедить руководство, что переход на новую систему позволит снизить затраты на обслуживание и поддержку, повысить эффективность работы, что приведет к улучшению бизнес-показателей.
Вопрос 2. Основные подходы к миграции данных, используемые сегодня
Андрей Коненко
– Подходы к миграции данных очень сильно зависят от инфраструктуры. Как правило, под миграцией данных в современном стеке понимается развертывание контейнеров в новом месте: то есть это построение нового кластера и развертывание на нем контейнеров. Как правило, используется Kubernetes. Если речь идет о простых решениях, то здесь проблемы и методы миграции точно такие же, как и двадцать лет назад. То есть более простое решение – это планирование технологических окон и клонирование данных на новую преднастроенную инфраструктуру – восстановление резервных копий и перенос их на новом месте. Если мы говорим о базе данных, то восстановление резервных копий – это единственный правильный вариант. Но если мы хотим переехать без простоев, то используется кластеризация и репликация баз данных и у каждого инструмента она своя.
Данил Вильховский
– В зависимости от конкретных потребностей и условий можно реализовать один из представленных подходов к миграции данных:
- Пакетная миграция данных – позволяет перенести большие объемы информации.
- Постепенная миграция данных – позволяет более гибко управлять миграцией и минимизировать риски сбоев.
- Параллельная миграция данных – позволяет минимизировать простои и обеспечить непрерывность работы организации.
- Миграция с использованием ETL-процессов – используется при сложных миграциях данных, требующих обработки и преобразования информации.
- Миграция в реальном времени – позволяет обеспечивать актуальность быстро изменяющихся данных в новой системе.
В целом, выбор подхода к миграции данных зависит от ряда ограничивающих факторов, в числе которых можно выделить размер и сложность данных, допустимое время простоя системы, располагаемый бюджет и ресурсы.
Алексей Черепанов
– Существует несколько основных подходов к миграции данных, которые могут помочь перенести данные из одной системы в другую:
1. Полный перенос (Full migration) – это подход, при котором все данные переносятся из одной системы в другую сразу. Этот метод может быть эффективным, если у вас не очень большой объем данных и, если вы можете позволить себе простой перерыв в работе на время миграции.
2. Частичный перенос (Partial migration) – это подход, при котором только часть данных переносится из старой системы в новую. Этот метод может быть полезен, если у вас есть ненужные данные в старой системе или если вы хотите постепенно переходить на новую систему, чтобы не потерять ценную информацию.
3. Инкрементальная миграция (Incremental migration) – это подход, при котором данные переносятся поэтапно. Новые данные добавляются в новую систему по мере того, как они появляются, а старые данные остаются в старой системе. Этот метод может быть полезен, если вам нужно сохранить доступность старых данных в течение периода миграции.
4. Параллельная миграция (Parallel migration) – это подход, при котором старая и новая системы работают параллельно в течение периода миграции. Данные синхронизируются между системами, пока полный перенос не будет завершен. Этот метод может быть полезен, если вы не можете позволить себе остановку работы во время миграции.
5. Объединение данных (Data consolidation) – это подход, при котором данные из разных источников объединяются в одну новую систему. Этот метод может быть полезен, если у вас есть несколько систем, содержащих разные данные, которые вы хотите объединить в одну систему.
6. ETL (Extract, Transform, Load) – это метод переноса данных, который включает в себя извлечение данных из источника, их трансформацию для соответствия требованиям новой системы и загрузку данных в новую систему. Этот метод может быть полезен, если у вас есть данные, которые нужно изменить перед загрузкой в новую систему.
Каждый подход имеет свои преимущества и недостатки. Выбор конкретного подхода зависит от характеристик исходной и новой систем, а также целей миграции. Перед выбором подхода к миграции данных рекомендуется тщательно оценить все возможности и риски и составить детальный план действий для выполнения миграции.
Сергей Головашов
– Вопрос на самом деле непростой для любой организации, независимо от ее размеров. Даже для маленького НИИ или ФГБУ проблема миграции может остановить работу всего ведомства на неделю или даже месяц. Конечно же к вопросам переноса ресурсов и информации надо начинать подходить с позиции оценки, а далее пошагового построения процесса, но процессный подход редко применяется в виду отсутствия действительно опытных эффективных менеджеров, и возглавляет его местный системный администратор.
Что же касается совсем крупных структур (особенно финансовых), то там проблема вызвана вовсе не отсутствием управления, а отсутствием управляемости процесса, а также тем, что миграции происходят настолько часто, насколько этим руководство ИТ хочет показать свою значимость и необходимость во всей вертикали управления.
Михаил Чусавитин
– Миграция является отдельным серьёзным проектом и подходить к нему необходимо не с меньшей ответственностью, чем к построению ИТ-инфраструктуры с нуля.
Практически любую миграцию можно произвести собственными силами ИТ-отдела путем подготовки скриптов, небольших программ, например, на python или с использованием инструментов производителя или Open Source Software, например, CloneZilla или virt-v2v. Но у данного подхода, помимо очевидных плюсов в виде кажущейся «бесплатности», есть множество недостатков, с которыми необходимо считаться:
- Сложность, большие временные затраты на подготовку и оттачивание процесса.
- Уникальность процесса не позволит использовать его для переноса данных между другими продуктами.
- Возможные сбои, потери данных и простои во время миграции требуют либо остановки работы компании, либо проведения работ ночью, в выходные или нерабочие дни.
Вторым подходом к миграции данных может стать использование продуктов резервного копирования и восстановления, когда существующая инфраструктура восстанавливается из резервной копии на новый продукт. Не всегда данный способ можно применить на практике и не все продукты резервного копирования и восстановления совместимы с отечественными решениями, на которые наверняка будет проводиться миграция.
Данный подход, когда он может быть использован, позволяет существенно сократить время, необходимое на подготовку и тестирование процесса, а также обеспечивает дополнительную сохранность данных от повреждения или потери за счет самого процесса резервного копирования.
Выбор продуктов резервного копирования и восстановления широк, но среди отечественных стоит отметить продукты «Киберпротект» и RuBackup, как поддерживающие наиболее широкий перечень сред.
Третьим подходом является использование специализированных средств осуществления миграции, например, таких, как продукт компании MIND. Специализированные средства невыгодно выглядят по сравнению с первыми двумя подходами прежде всего тем, что стоят денег и бывают нужны всего один раз во время миграции, чего не скажешь о покупке продукта резервного копирования, который прослужит несколько лет.
При этом специализированное ПО для осуществления миграции данных зачастую обладает дополнительными специализированными функциями, которые не могут быть реализованы в первых двух сценариях, например:
- Копирование данных в фоне и минимальное время переключения между существующей и новой инфраструктурой за счет инкрементного применения изменений.
- Возможность выполнения миграции между различными средами из одного интерфейса без необходимости разработки и подготовки под каждый отдельный проект специальных утилит.
- Миграция без остановки доступа к данным и создание отказоустойчивой распределенной инфраструктуры между различными платформами как на время миграции, так и в качестве отдельной задачи по защите от катастроф и потери доступа к данным.
Сергей Чуканов
– Совершенно точно необходимо переносить справочные данные – без них нормальная работа будет невозможна в принципе, а также относительно небольшой набор транзакционных данных. Этот набор может ограничиваться выбранным периодом времени (например, за последние две недели, за текущий квартал, с начала текущего года), либо определяться статусной моделью – переносить только те записи, жизненный цикл которых не завершен. Так, например, при переходе на новый servicedesk, в такую категорию попадут все незакрытые обращения (новые, находящиеся в работе, отложенные, ожидающие подтверждения пользователя и т.п.), вне зависимости от даты создания. Часто практикуется и отказ от миграции исторических данных в случае возможности сохранения текущей системы, доступной в формате read-only.
Александр Иванников
– Сегодня используется различные подходы:
1). Перенос текущих образов. Способ подразумевает физический перенос уже существующих образов в облачную инфраструктуру провайдера.
2). Миграция с помощью специальных программных инструментов – агентов. То есть агенты устанавливаются на исходных серверах как программа, которая собирает и переносит данные в новую облачную инфраструктуру. Например, mClouds успешно мигрирует клиентские сервисы с помощью агента Hystax Acura, плюс в том, что он позволяет автоматически и безопасно переносить данные в облако.
3). Новая установка – означает создание и настройку нового окружения в облачной инфраструктуре с нуля. То есть вместо переноса или обновления существующей системы, подразумевается установка и настройка приложений заново в облачной среде.
Артур Галимарданов
– Наиболее часто встречаются два подхода. Первый – вендор приложения или информационной системы сам предлагает готовый сценарий, а иногда и помощь в миграции. Такой подход наиболее быстрый и безболезненный, вероятность ошибки крайне мала. Крупные производители ПО в большинстве случаев предоставляют готовые инструменты миграции. Второй подход более долгий и трудоемкий, чаще встречается в случаях с самописными системами. Тут уже много ручной работы, связанной с проверками на совместимость, доработками и изменением кода ИС.
Владислав Билай
– Подходы к миграции данных:
- Экспорт данных из исходной системы в файлы, которые затем импортируются в целевую систему.
- Постепенный перенос данных.
- Синхронизация данных между исходной и целевой системами в режиме реального времени.
Вопрос 3. Какие проблемы могут появиться при переходе с одной базы данных на другую? И как с ними справиться?
Андрей Коненко
– Если мы меняем одну версию баз данных на другую, то здесь проблемы сопряжены с разработкой каких-либо фич. Эти фичи уже могут не поддерживаться и на замену им пришли новые. Такие моменты необходимо отслеживать заранее и модифицировать продукт.
Например, на наших проектах по Битрикс24 при обновлении мы отслеживаем, чтобы код в ядре и дополнительных модулях был актуальный. А если говорить о смене типа СУБД, то это задача не находится в зоне ответственности системного администратора.
Данил Вильховский
– Практика показывает, что вне зависимости от применяемых решений миграция данных зачастую осложняется рядом проблем:
- Несовместимость данных – несовпадение структуры или типов данных.
- Различия в производительности и масштабируемости БД.
- Потери и повреждения данных.
Чтобы минимизировать риски возникновения проблем, также рекомендуется реализовывать следующее мероприятия:
1. Предварительный анализ и подготовка. При определении несовместимости, следует предварительно преобразовать данные в формат, поддерживаемый целевой БД. Также необходимо оценить производительность целевой БД и убедиться, что она соответствует требованиям.
2. Резервное копирование и проверка целостности данных с целью минимизации рисков потери и повреждения данных.
3. Планирование ресурсов. Перенос данных может потребовать дополнительных ресурсов, таких как вычислительная мощность, память и хранилище. Поэтому при планировании миграции следует убедиться, что имеющиеся ресурсы достаточны.
4. Тестирование и верификация. Перед полным переносом данных следует провести тестирование и верификацию на небольшом объеме данных. Это позволит выявить потенциальные проблемы и ошибки.
5. Резервное планирование. Например, возможность отката к предыдущей базе данных или другим альтернативным вариантам в случае, если возникнут непредвиденные проблемы.
6. Контроль версий и документация каждого шага. Это поможет отслеживать изменения и иметь полное представление о процессе миграции данных.
В заключении следует отметить, что каждая миграция данных уникальна и может потребовать специфических шагов и подходов. В целом, чтобы успешно выполнить миграцию данных, важно обеспечить достаточную гибкость и адаптацию к изменяющимся обстоятельствам и непредвиденным ситуациям.
Михаил Шамарин
– По понятным причинам почти все российские компании планируют или уже осуществляют переход с западных баз данных на другие решения, и мы, как дистрибутор, видим большой поток запросов по данной теме. Переходят либо на Open-source либо на отечественные СУБД, созданные на базе Open-Source решений. Так как наиболее распространенными СУБД были Oracle DB и MS SQL server, а самая распространенная замена – это СУБД на основе PostgreSQL, то основные вопросы возникают по миграции данных между этими системами.
Перечислить все проблемы миграции не представляется возможным, но условно их можно разделить на организационные и технические. Чтобы избежать первый класс проблем, обязательно нужно составить правильный план миграции. Большое количество компаний сейчас находится в стадии пилотирования, они используют тестовые версии, или переводят сначала небольшие некритичные системы – как первый этап общего плана.
Технические проблемы определяются в первую очередь архитектурой существующей системы: важно, насколько данные отделены от бизнес-логики, сколько кода хранится внутри базы данных в виде процедур, насколько интенсивно использовались проприетарные инструменты, не поддерживаемые другими производителями, как обеспечивалась отказоустойчивость и т.п. Однако вопросы различия типов данных, синтаксиса процедурных языков и языков запросов, отсутствия определенных объектов (например пакетирования для хранимых процедур) – это то, с чем столкнутся все без исключения.
Алексей Черепанов
– Переход с одной базы данных на другую может вызвать ряд проблем, которые могут затронуть как технические, так и бизнес-аспекты вашей деятельности.
Рассмотрим некоторые из возможных проблем и способы их решения:
1. Совместимость данных – если структуры данных в новой базе данных отличаются от старой системы, то могут возникнуть проблемы совместимости. Для решения этой проблемы необходимо провести анализ структур данных в обеих системах и разработать метод переноса данных. Это может включать в себя конвертацию типов данных, изменение формата данных и так далее.
2. Трудозатраты – перенос большого количества данных может требовать значительных затрат времени и ресурсов. Чтобы справиться с этой проблемой, можно использовать автоматизированные инструменты для переноса данных, которые могут значительно ускорить процесс миграции.
3. Безопасность – перенос данных может создавать потенциальные уязвимости в безопасности. При переносе конфиденциальных данных необходимо защитить их от несанкционированного доступа. Защиту можно обеспечить путем шифрования данных, использования безопасных каналов связи.
4. Потеря данных – при переносе данных могут возникнуть ошибки, которые приведут к потере данных. Чтобы этого избежать, необходимо провести тестирование перед переносом всех данных и резервного копирования старой базы данных.
5. Проблемы с производительностью – новая база данных может работать медленнее, чем старая система. Это может быть вызвано различиями в аппаратной конфигурации, оптимизацией запросов или другими факторами. Для решения этой проблемы необходимо произвести настройку новой системы для достижения оптимальной производительности.
В целом, переход с одной базы данных на другую может быть сложным процессом. Но если провести предварительный анализ, разработать план переноса данных и защиты от потенциальных угроз, то можно минимизировать возможные проблемы и обеспечить успешный переход на новую систему.
Игорь Мильберт
– При переходе с одной базы данных на другую могут возникать следующие проблемы:
- Совместимость данных: различные базы данных имеют разные структуры и форматы данных. При миграции могут возникать проблемы соответствия данных между исходной и целевой базами данных. Для их решения рекомендуется провести предварительный анализ и преобразование данных, чтобы обеспечить их совместимость
- Потеря самих данных или их целостности: во время миграции могут возникать проблемы с потерей или повреждением данных. Для предотвращения таких ситуаций важно создать резервные копии данных и провести тщательное тестирование перед миграцией. Также следует использовать механизмы проверки целостности данных для обнаружения и исправления ошибок
- Простои и недоступность системы: в процессе переноса данных может возникнуть необходимость временной недоступности системы. Чтобы минимизировать простои, рекомендуется использовать параллельную миграцию (когда новая система уже работоспособна, а старая система еще доступна) или проводить миграцию в периоды минимальной активности бизнеса.
- Управление изменениями: миграция данных требует тщательного планирования и координации с различными заинтересованными сторонами. Важно иметь процессы управления изменениями, чтобы обеспечить прозрачность, своевременность и корректность миграции данных.
Сергей Головашов
– Проблемы встраиваемости и ее контроля характерны не только для баз данных, но даже для устройств, программ, аппаратных комплексов, да даже для швабры и ручки к ней. Подход здесь должен быть системным, с большим количеством аналитики, которая позволит избежать недочетов и ошибок. В противном случае вопрос уже будет стоять в том, кто виноват и что теперь делать.
В целом существуют несколько проблем миграции.
У нас возникает проблема остановки сервера для обновления, если сервер простой. А если сложный, включающий в себя микросервисы, то добавляется еще и проблема обновления версии сервера с зависимостями.
Когда мы обновляемся с версии 1 на версию 2, все наши зависимости тоже должны обновиться на новую версию, использующую эту вторую версию.
Но если что-то пойдет не так, то возникает третья проблема – отказ от новой версии сервера с зависимостями приводит к цепной реакции. Нам придется откатиться полностью.
Но для отката нам нужна резервная копия БД, причем, когда мы будем откатываться, сервер опять будет простаивать. Кроме того, полученные во время второй версии данные будут безвозвратно утеряны.
Все это делается для того, чтобы сократить время простоя и минимизировать связанные с этим потери. Но иронично, что серверы продолжают простаивать, убытки нарастают, а разработчики выясняют проблемы. Они придумывают костыли, пытаются чинить, чтоб хотя бы просто работало… И ладно бы все починилось с первого раза, но, увы, так не работает, и убытки продолжают нарастать.
Михаил Чусавитин
– Все описанные методы имеют свои плюсы и минусы, а также могут быть использованы как системными администраторами компаний, так и проектными командами для подготовки методики миграции или выполнения работ по контракту на инфраструктуре заказчика.
Еще раз хочу отметить, что миграция является отдельным, сложным проектом с большим количеством зависимостей, который при халатном подходе может привести к простоям инфраструктуры, порче или полной потери данных без возможности восстановления.
Александр Иванников
– Можно выделить типичные ошибки, которые совершаются, и рекомендации наших инженеров к ним:
1) Запуск репликации в рабочее время, в это время может наблюдаться падение производительности дисковой подсистемы, с которой выполняется копирование данных в облако, плюс канал связи в это время будет загружен.
Что делать: настроить окно репликации за пределами рабочего дня и за пределами окна резервного копирования.
2) Заранее установить актуальную версию VMware Tools. Без неё не будут работать сетевые драйверы VMXNET3.
3) Не учесть дополнительное время на проверку. Так как после выполнения полной репликации необходимо проверить, что все компоненты запускаются и работают.
Что делать: выделить дополнительное время на выявление проблем после тестирования пользовательских действий.
4) При VPN-подключении спланировать заранее и выполнить настройку сетевого подключения, необходимо убедится, что адресное пространство не пересекается между офисом и облачной инфраструктурой.
5) Убедится, что компоненты системы не используют зависимости от других сетевых сервисов в офисе, например, DNS. Если есть зависимости, то спланировать сетевое подключение и Firewall согласно новой схеме.
Артур Галимарданов
– В зависимости от исходной и конечной СУБД могут появиться самые разные проблемы, начиная с отличий в типах данных и заканчивая логикой работы функций и хранимых процедур. Стоит отметить также используемые компоненты, поставляемые с исходной СУБД. Для некоторых из них замену найти очень проблематично.
Владислав Билай
– Проблемы при миграции:
- Исходная и целевая базы данных могут иметь различные структуры данных и форматы хранения.
- Процесс миграции может привести к потере данных.
- Проблемы совместимости исходной и целевой баз данных.
Решения проблем при миграции:
- Изучить структуру и содержимое исходной базы данных.
- Провести тестовые переносы на небольшом объеме данных.
- Создать резервные копии исходных данных перед началом миграции
Вопрос 4. Какие шаги может предпринять системный администратор, чтобы упростить процедуру миграции для себя и компании?
Сергей Головашов
– Если системный администратор знает свое дело очень хорошо, то все процессы миграции выполняются либо через резервную схему, либо с работой двух схем функционирования одновременно.
Что я имею в виду: у вас сервер баз данных должен переехать в другой ЦОД, на момент переезда работать должны оба сервера (и новый, и старый), что позволит не потерять функциональность сервиса и переехать на новый сервер. Да, тут вопрос расчетов и аналитики, а также последующего «доноса до сервиса» данных, которые успели попасть на старый сервер, пока шла миграции, но это все мелочи.
Довольно хорошо процессы тестирования и миграции показаны в документации про Blue-green deployment, canary release, которые очень хорошо позволяют и проработать процесс перехода, и в последствии совершить миграцию без проблем и технического останова. Простым языком, blue-green deployment – это способ развертывания, который позволяет обновлять приложения, не отклоняя ни одного запроса, без остановок.
Андрей Коненко
– Чтобы упростить процедуру миграции для себя и компании системный администратор может сделать две вещи:
Первое – это резервные копии. Резервных копий никогда не бывает много, поэтому перед каждым изменением важно делать резервную копию состояния системы, либо конфигурационных форм и баз данных.
Второе – это предварительное построение тестового стенда. То есть делаем копию системы и тренируемся на ней. Сначала копируем, разворачиваем на тестовой среде, смотрим аналогичные системы только в уменьшенных масштабах и наблюдаем как это работает.
Алексей Черепанов
– Системный администратор может упростить процедуру миграции базы данных для себя и компании, выполняя следующие шаги:
1. Провести анализ текущей базы данных: системный администратор должен провести анализ текущей базы данных, чтобы определить, какие данные нужно перенести, какие можно удалить и какие изменения необходимо внести в структуру данных.
2. Определить цели миграции: системный администратор должен четко определить цели миграции базы данных, например, повысить ее производительность или улучшить безопасность.
3. Выбрать подходящую базу данных: для успешной миграции необходимо выбрать подходящую базу данных, которая соответствует требованиям компании по функциональности, производительности и безопасности.
4. Разработать план миграции: системный администратор должен разработать детальный план миграции, который включает в себя все этапы процесса, от резервного копирования до тестирования новой базы данных.
5. Проверить совместимость: перед миграцией необходимо проверить совместимость старой и новой баз данных на соответствие форматам и структурам, чтобы избежать потенциальных проблем совместимости.
6. Подготовить персонал: системный администратор должен подготовить персонал компании к работе с новой базой данных, обучив их новым функциям и возможностям.
7. Обеспечить безопасность: при миграции базы данных необходимо обеспечить ее безопасность, установив правильные уровни доступа, защитив данные от несанкционированного доступа и настроив резервное копирование.
8. Протестировать новую базу данных: после миграции новой базы данных системный администратор должен провести ее тестирование, чтобы убедиться в ее корректной работе и оптимальной производительности.
В целом, выполнение этих шагов поможет системному администратору упростить процедуру миграции базы данных для себя и компании, минимизировать возможные риски и обеспечить успешную миграцию.
Игорь Мильберт
– Системный администратор может сделать следующие шаги для упрощения процедуры миграции данных:
- Тщательное планирование: разработка подробного плана миграции данных с определением ролей и ответственностей, временных рамок и ресурсов поможет снизить риски и упростить процесс.
- Подготовка данных: очистка, преобразование и проверка исходных данных перед миграцией помогут снизить возможные проблемы и несоответствия в целевой базе данных.
- Автоматизация: использование специальных инструментов (например, RPA) и скриптов для автоматического выполнения задач миграции данных может значительно упростить процесс и сократить время, а также снизить риски ошибок.
- Проведение тщательного тестирования: проведение тщательного тестирования после миграции данных позволит выявить возможные проблемы или ошибки. Тестирование включает проверку целостности данных, проверку функциональности системы и производительности.
- Обучение и поддержка: обеспечение подготовки и обучения сотрудников, которые будут работать с новой базой данных поможет упростить процесс адаптации и использования новой системы.
Сергей Чуканов
– Системный администратор может подготовить необходимый контур для миграции данных, включающий создание учетных записей с необходимыми правами доступа и выделение тестового стенда в случае, если перенос данных будет осуществляться внешним подрядчиком. Собранная информация о заменяемой системе, используемой структуре данных, качестве самих данных существенно упростит процедуру миграции.
Александр Иванников
– Для упрощения миграции в облако системный администратор может обратиться к облачному провайдеру, чаще такой способ оправдывает себя, так как облачный провайдер более опытен и компетентен в подобной задаче, этот опыт протестирован и отточен профессиональной командой на сотне клиентов.
Если же системный администратор решает самостоятельно мигрировать в облако, ему необходимо предпринять следующие шаги:
1. Определить необходимые ресурсы для миграции и выбрать подходящий облачный сервер. Это позволит более эффективно спланировать миграцию и снизить возможные проблемы.
2. Администратор должен обновить и настроить текущую инфраструктуру и приложения для совместимости с облачной платформой. Может включать установку агентов или инструментов, обновление версий ПО или внесение изменений в конфигурацию.
3. Спланировать временя и ресурсы, то есть составить детальный план миграции, определить время, бюджет, исполнителей и установить приоритеты для различных этапов миграции. Это поможет избежать незапланированных задержек и минимизировать простои в работе.
4. Перед миграцией важно создать резервные копии всех данных, чтобы в случае проблем можно было восстановить всю информацию. Провести проверку целостности данных перед переносом.
5. Перед полным переносом важно сделать тестовую миграцию, что поможет выявить и исправить возможные проблемы, оценить безопасность и стабильность работы системы.
6. После успешного тестирования – постепенно переносить данные и приложения, контролируя процесс.
Артур Галимарданов
– Больше практиковаться, делать тестовые миграции, записывать полученные результаты, анализировать и делать своего рода таблицы сопоставления объектов СУБД и логики их работы. Это может в будущем облегчить поиски решения тех или иных возникших проблем при миграции.
Владислав Билай
– Шаги для упрощения миграции:
- Разработать план, описывающий все этапы миграции.
- Использовать инструменты и скрипты для автоматизации рутинных операций.
- Обеспечить коммуникацию с сотрудниками, которых затронет миграция данных.
Вопрос 5. Какие сейчас существуют решения на ИТ-рынке по автоматизации миграции?
Андрей Коненко
– Решения по автоматизации миграции существуют и зависят от продукта.
Рассмотрим ситуацию, когда мы мигрируем облачное решение Битрикс24 в коробочное решение в периметре клиента. Здесь компания Битрикс предоставляет полный дамп наших данных, и мы их импортируем.
Если мы говорим о переезде инстанций сервиса в более мощную инфраструктуру, то здесь все будет зависеть от инфраструктуры. Например, у большинства наших клиентов имеется развернутый кластер либо на основе виртуальных машин, либо на основе контейнеризации. В этом случае используется Kubernetes или gitlab. Мы мигрируем данные в автоматическом режиме, например, используя процессы CI/CD, чтобы его данные прозрачно переехали в новую инфраструктуру.
Данил Вильховский
– В настоящее время можно легко автоматизировать перенос данных. Наиболее распространенными здесь являются следующие решения:
1. Клауд-платформы. Провайдеры облачных услуг (Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP)) и другие, предлагают собственные инструменты и сервисы для упрощения миграции из локальных сред в облачные среды.
2. Инструменты автоматической миграции данных. Существуют специализированные инструменты, (AWS Database Migration Service или Azure Database Migration Service и др.), которые позволяют автоматизировать миграцию баз данных между различными платформами и средами.
3. Инструменты контейнеризации. Так Docker и Kubernetes, облегчая процесс развертывания и масштабирования приложений, предоставляют механизмы для упаковки приложений и их автоматической миграции между различными средами.
4. Инструменты конфигурационного управления и оркестрации. Так, Ansible, Chef, Puppet и Terraform позволяют автоматизировать процессы управления инфраструктурой и могут быть использованы для автоматической миграции инфраструктуры и приложений на новые серверы или облачные платформы.
Михаил Шамарин
– Существует целый ряд бесплатных решений, позволяющих автоматизировать те или иные аспекты миграции, например широко известные утилиты Orafce и Ora2pg для миграции данных с Oracle на PostgreSQL.
Отечественные производители сейчас также активно разрабатывают и дорабатывают специальные пакеты, позволяющие облегчить миграцию данных. Среди них недавно анонсированная утилита ora2pgpro от компании Postgres Professional для автоматического портирования пакетов и автономных транзакций Oracle в пакеты и автономные транзакции Postgres Pro.
Так как СУБД является основой для прикладных приложений, а не используется бизнес-пользователями непосредственно, то, на наш взгляд, ключевую роль в процессе миграции будут играть именно разработчики прикладных решений, которые сейчас активно работают над обеспечением совместимости с такими СУБД как PostgreSQL, часто эти производители разрабатывают для заказчиков и средства автоматизированной миграции базы данных. В связи с повышенным интересом к данной теме, многие ИТ- компании предлагают услуги по миграции СУБД, учебные центры проводят специальные курсы по миграции.
Алексей Черепанов
– Существует множество решений на ИТ-рынке, которые помогают автоматизировать процесс миграции. Эти решения могут варьироваться в зависимости от того, какие данные необходимо перенести и между какими системами или платформами происходит миграция.
Некоторые из самых распространенных решений для автоматизации миграции включают в себя:
1. AWS Database Migration Service – позволяет мигрировать базы данных в облаке AWS, а также из других источников в облако AWS.
2. Microsoft SQL Server Migration Assistant – инструмент, который помогает мигрировать данные из различных источников в SQL Server.
3. Google Cloud Data Transfer Service – обеспечивает быструю и безопасную миграцию данных в облако Google Cloud Platform.
4. Apache NiFi – платформа для интеграции данных, которая может использоваться для автоматизации миграции данных между различными источниками и назначениями.
5. Attunity – решение для автоматической миграции и интеграции данных между различными платформами и источниками.
Это лишь небольшой список решений, доступных на рынке. Важно выбирать решение, которое лучше всего соответствует требованиям вашей организации и типу данных, которые необходимо мигрировать.
Игорь Мильберт
– Некоторые из популярных решений включают:
- ETL-инструменты (Extract, Transform, Load): они позволяют извлекать данные из исходных источников, преобразовывать их в соответствии с требованиями целевой базы данных и загружать в целевую систему. Примеры таких инструментов включают Apache NiFi, Talend, Informatica и Microsoft SQL Server Integration Services (SSIS).
Стоит отменить, что обычно ETL-инструменты используются, когда нужно перенести много разнородных данных: собрать их, привести к единому виду, загрузить в новую систему и сохранить всю информацию по пути. Системы бывают разными, и задача ETL – в том числе адаптировать под них данные из разных источников
- Облачные решения для миграции данных: различные облачные провайдеры предлагают специальные инструменты и сервисы для миграции данных в облако.
- Специализированное программное обеспечение для миграции: такие программы предназначены для упрощения конкретных типов миграции данных, например, миграции баз данных Oracle, MySQL или Microsoft SQL Server. Это может быть коммерческое программное обеспечение или открытые инструменты с необходимой функциональностью.
- RPA (Robotic Process Automation (Программная роботизация процессов) – это автоматизация бизнес-процессов, в том числе и процессов миграции данных с помощью так называемых «роботов» или программ, имитирующих действия человека.
Сергей Головашов
– Решений для автоматизации на рынке нет. Ситуация довольно классическая и похожа на анекдот «Приборы! Сто! Что сто?! А что приборы?!».
Вопросы миграции настолько объемны, что их невозможно объять каким-то одним решением. Если, с одной стороны, достаточно сделать клон сервера и развернуть в другом ЦОД такой же, но после поменять ему ip-адресацию и все заработает, то с крупными корпоративными системами (особенно legacy) это уже не сработает. И тут приходится очень долго и нудно заниматься планированием и попыткой учесть все возможные риски. Поэтому мое мнение однозначное – таких систем нет и не будет, потому что в целом процесс миграции уникален для каждой отдельной инфраструктуры.
Сергей Чуканов
– Многие производители разрабатывают собственные утилиты и мастера импорта, которые помогают загрузить данные или перенести их из конкурирующих решений. Использование таких инструментов позволит существенно упростить задачу миграции и трансформации данных в нужный формат. Как правило, они не требуют написания кода, имеют удобный графический интерфейс с возможностью перетаскивания «drag-and-drop».
Александр Иванников
– Популярное решение на российском рынке – это специальное программное обеспечение Hystax Acura. Это решение для автоматического переноса ИТ-инфраструктуры в режиме реального времени. Его плюсы в том, что оно позволяет автоматизировать процессы миграции и обеспечивает сохранность данных.
Другое известное решение – это Veeam Backup & Replication, включает функцию по миграции данных, позволяет переносить виртуальные машины и данные между различными платформами виртуализации и облаками.
Артур Галимарданов
– Их сейчас довольно много – как платных, так и бесплатных. Из последних мне очень понравился инструмент Yandex Data Transfer. Он поддерживает много различных источников и приемников, список которых постоянно расширяется.
Владислав Билай
– Решения по автоматизации миграции данных:
- Инструменты для экспорта и импорта данных, такие как ETL (Extract, Transform, Load).
- Интегрированные платформы для управления и автоматизации процесса миграции данных.
- Облачные провайдеры, такие как AWS, для переноса данных в облако или между облачными платформами.
Вопрос 6. Как обеспечить безопасность данных при миграции?
Александр Иванников
– Есть несколько мер, которые помогут вам обеспечить безопасность данных при миграции:
1) Перед миграцией шифровать данные, чтобы обеспечить их конфиденциальность во время миграции. Использовать протоколы шифрования, таких как: SSL/TLS, что поможет защитить данные от несанкционированного доступа.
2) Использовать безопасные каналы связи. При передаче данных между исходной системой и облачной инфраструктурой использовать VPN или защищенные протоколы передачи данных, чтобы предотвратить несанкционированный доступ к данным.
3) Проверить на наличие угроз и уязвимостей. Перед миграцией можно провести анализ и проверку на уязвимости в системе. Что поможет выявить и устранить потенциальные проблемы, которые используют потенциальные злоумышленники для взлома и кражи данных.
4) Сделать резервное копирование всех данных, чтобы в случае потери информации можно было восстановить их. Регулярное резервное копирование помогает минимизировать риски.
5) Провести аудит безопасности. После завершения миграции следует провести аудит безопасности системы, чтобы убедиться в том, что все данные были правильно перенесены и защищены.
Андрей Коненко
– Под безопасностью данных при миграции понимается не только и их утечка, но и целостность данных: верифицируемость, воспроизводимость. Защищенность данных от утечки в классическом понимании предполагает миграцию данных по защищенным каналам связи. То есть мы должны настроить старую и новую инфраструктуру таким образом, чтобы соединения между ними были защищены. Мы можем использовать дополнительно виртуальные частные сети.
Что касается защиты данных от повреждений – это резервные копии и протоколы верификации данных. Дополнительно, чтобы убедиться, что требуемый файл передан корректно, желательно посчитать его хэш на старой и на новой инфраструктурах. Если хэш совпал, данные переданы корректно.
Алексей Черепанов
– Обеспечение безопасности данных при миграции – это крайне важный аспект, который необходимо учитывать, чтобы предотвратить потенциальные угрозы и нарушения правил безопасности. Для этого можно использовать ряд мер, например:
- Использование сильных алгоритмов шифрования для защиты данных при передаче по сети.
- Проверка подлинности пользователей и установление политик доступа для минимизации рисков несанкционированного доступа.
- Обновление системы безопасности на новом месте назначения для предотвращения возможных угроз безопасности.
- Проверка целостности данных после миграции, чтобы удостовериться, что данные не были повреждены в ходе передачи или хранения.
Эти меры помогут обезопасить данные при миграции и защитить их от возможных угроз.
Игорь Мильберт
– Обеспечение безопасности данных при миграции является критическим аспектом процесса. Некоторые рекомендации по обеспечению безопасности включают:
- Шифрование данных: использование шифрования для защиты данных во время и после миграции. Это поможет предотвратить несанкционированный доступ к данным в случае утечки или перехвата.
- Установка контроля доступа: обеспечение строгого контроля доступа к данным во время миграции, чтобы только авторизованные пользователи имели доступ к информации. Это может включать установку многофакторной аутентификации, ограничение прав доступа и мониторинг активности пользователей.
- Защита сетевого трафика: использование защищенных соединений, таких как VPN (виртуальная частная сеть) или SSL (Secure Sockets Layer), для передачи данных между исходной и целевой системами.
- Резервное копирование и восстановление: создание резервных копий данных перед миграцией и наличие плана восстановления данных поможет обеспечить безопасность и сохранность информации в случае непредвиденных событий или сбоев.
- Аудит и мониторинг: внедрение механизмов аудита и мониторинга данных во время и после миграции для обнаружения любых аномалий или нарушений безопасности.
Сергей Головашов
– Здесь, кстати, довольно все просто. Пример давайте возьмем из хорошо цифровизованного финансового сектора. Для того, чтобы обеспечить безопасность данных, их просто не надо выпускать из контура безопасности. Как раз этот простой шаг и позволит свести все риски безопасности к нулю.
Сергей Чуканов
– Для обеспечения безопасности данных при миграции необходимо использовать механизмы контроля доступа к данным и мониторинга процесса миграции. Доступ к данным должен быть только у ограниченного набора авторизованных пользователей, чтобы избежать утечки данных или их повреждения. Действия, выполняемые при миграции данных, необходимо логгировать и мониторить для обеспечения возможности своевременного выявления несанкционированных операций.
Артур Галимарданов
– Все зависит от конкретного сценария. Основные принципы – максимально закрывать периметр, в котором данные переносятся, и использовать шифрование. Также стоит следить за правами и доступом к исходной и конечной СУБД.
Владислав Билай
– Обеспечение безопасности данных при миграции:
- Используйте алгоритмы шифрования данных.
- Установите строгие права доступа к данным.
- Создайте резервные копии исходных данных.
Вопрос 7. Ваш пошаговый план переноса данных, без простоев и увеличения затрат?
Сергей Чуканов
– Составление плана миграции должно начинаться с анализа текущей системы и определения набора данных, которые необходимо переносить. Причем данные могут располагаться как в одном источнике, так и в нескольких.
В рамках подготовки к миграции необходимо провести сопоставление структуры исходных данных с целевой структурой в новой системе (data mapping), а также разработать правила (скрипты) трансформации данных в нужный формат.
На следующем шаге исходные данные выгружаются в формат, подходящий для дальнейшей загрузки в новую систему. Перед выполнением итоговой миграции данных рекомендуется проводить одну или несколько тестовых миграций для выявления ошибок и предварительной проверки качества загружаемых данных.
После проведения миграции необходимо также проверить загруженные данные на соответствие качеству – на наличие дублей, заполненность обязательных полей, проверки ссылочной целостности, проверки контрольных сумм и др. По результатам проверки принимается решение о завершении миграции и возможности начала эксплуатации системы.
Алексей Черепанов
– План переноса данных может включать следующие шаги:
- Создание детального плана миграции с расписанием работ и назначением ответственных.
- Создать резервную копию всех данных, которые будут переноситься, для предотвращения потери данных в случае каких-либо проблем.
- Тестирование перед началом миграции: проверка совместимости данных, тестирование на минимальных объемах информации.
- Убедиться в том, что новая система хранения данных готова к приему данных и соответствует всем требованиям, таким как объем хранилища, производительность и безопасность.
- Определить оптимальный метод переноса данных. Например, можно использовать специальные инструменты миграции или скрипты, чтобы автоматизировать процесс и сократить время, необходимое для переноса данных.
- Приступить к переносу данных, начиная с тех, которые наиболее важны и необходимы для бизнеса. Важно следить за процессом переноса, чтобы быстро реагировать на любые проблемы или ошибки.
- Контроль качества. Проверка правильности переноса данных. Это может включать в себя проверку целостности данных, проверку соответствия форматов и т.д.
- Поддержка и обслуживание новой системы: мониторинг работы, устранение неполадок, регулярное создание бэкапов данных.
Важно также не забывать о коммуникации с другими отделами и информировании пользователей о процессе миграции и его последствиях. Это позволит избежать простоев и минимизировать затраты на перенос данных.
Игорь Мильберт
– Каждый план миграции данных может быть индивидуальным, и он должен быть адаптирован к специфическим потребностям и условиям компании. Однако есть общие моменты, которые подойдут большинству компаний при планировании мероприятий по переносу данных:
Этап 1. Анализ и планирование:
- Определение целей и требований миграции данных.
- Идентификация и анализ исходных данных.
- Оценка рисков и подготовка плана действий.
- Выбор инструментов для миграции данных.
Этап 2. Подготовка данных:
- Очистка и преобразование исходных данных.
- Создание резервных копий данных.
Этап 3. Настройка инструментов миграции:
- Настройка необходимых инструментов и программного обеспечения.
Этап 4. Тестирование:
- Проведение тестовых миграций на небольших объемах данных.
- Проверка целостности данных и функциональности системы.
Этап 5. Миграция:
- Перенос данных согласно разработанному плану.
- Мониторинг и проверка процесса миграции.
Этап 6. Проверка и верификация:
- Проверка правильности перенесенных данных.
- Проведение полноценного тестирования функциональности и производительности.
Этап 7. Внедрение и обучение:
- Переключение на новую базу данных или систему.
- Обучение сотрудников по работе с новой базой данных или системой.
Этап 8. Мониторинг и поддержка:
- Установка механизмов мониторинга и аудита данных.
- Поддержка и обслуживание системы после миграции.
- Решение возникающих проблем и неполадок.
Этап 9. Оценка и оптимизация:
- Проведение оценки и анализа результатов миграции данных.
- Внесение необходимых корректировок и оптимизаций.
Важно отметить, что каждый этап плана должен быть детализирован и подробно задокументирован, чтобы обеспечить четкость и прозрачность процесса. Кроме того, коммуникация и сотрудничество с заинтересованными сторонами, включая руководство и пользователей, являются неотъемлемой частью успешной миграции данных.
Сергей Головашов
– Планирование, создание копии переносимого контура или сервиса, перенос данных с продолжением работы боевого контура, перенос полезной нагрузки на новый контур, его тестирование и введение в эксплуатацию.
Александр Иванников
– Используем проверенный опытным путем план, который был отточен нашими инженерами в результате успешных миграций:
1. Выбор облачного сервера, определение параметров.
2. Определить, какими силами, своими или провайдера планируется провести миграцию данных в облако.
3. Выбрать инструменты, используемые при миграции.
4. Провести аудит информационных систем: инвентаризация и анализ ресурсов.
5. Определить требования ко времени простоя сервисов во время переезда в облако.
6. Определить ресурсы, необходимые для переезда.
7. Протестировать облачную площадку, выполнить тестовые миграции.
8. Учесть опыт тестовых миграций приложений в облако.
9. Провести итоговую миграцию.
10. При необходимости произвести оптимизацию потребления ресурсов облака и приложений.
Артур Галимарданов
– Каждый случай миграции индивидуален. Верхнеуровнево можно описать так:
- Анализ конечной инфраструктуры и планирование миграции.
- Подготовка миграционного окружения.
- Фазы тестовых миграций и проверок работоспособности ИС.
- Протоколирование всех проблем, их устранение.
- Миграция продуктового контура.
- Сдача в промышленную эксплуатацию.
Владислав Билай
– План переноса данных:
- Оценка объема данных, их структуры и качества.
- Создать резервную копию данных.
- Тестовый перенос данных на небольшом объеме.
- Основной перенос данных.
- Мониторинг системы и целостности данных.
Андрей Коненко
– Если мы говорим о миграции в другую инфраструктуру, то затраты на инфраструктуру уже скорее всего увеличены, либо уже запланированы. Как правило, если мы переносим Битрикс24, то делаем это в несколько этапов. Первое – необходимо построить балансировку трафика. Затем мы можем спокойно перенести данные и переключаем балансировщик трафика на новое место. В таком случае, файлы уже переносятся на новую инфраструктуру, а базы данных находятся на старой. Это может замедлить обработку запросов, но при правильном подходе незначительно. Дальше мы используем механизмы репликации СУБД, чтобы перенести уже базы данных. Сначала создаем копию СУБД в новой структуре. Благодаря встроенным механизмам данные могут быть синхронизированы. После чего мы меняем серверы местами. То есть мастер превращается в слейв и наоборот. Когда убеждаемся, что у нас все работает, мы отключаем старую инфраструктуру. eof
Ключевые слова: миграция данных, безопасность данных, СУБД, резервная копия, мониторинг системы и целостности данных.
Подпишитесь на журнал
Купите в Интернет-магазине
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
