Перенос PHP-приложений с MySQL на DB2: Часть 4. Развертывание приложения

Опыт миграции интранет-приложения IBM

Узнайте, зачем переносить PHP-приложение на DB2®, как спланировать миграцию, выполнить ее, как поддержать ее и как справиться с потенциальными рисками, на основе опыта миграции интранет-приложения IBM. В этой серии статей, состоящей из четырех частей, рассматриваются уроки успешной миграции с MySQL на DB2 критично-важного PHP-приложения, которое используют 4000 пользователей из разных стран мира для управления содержимым сайта ibm.com. В четвертой части рассматриваются действия по развертыванию и поддержке приложения.

Дэниел Крук, инженер-программист, IBM

Дэниел Крук (Daniel Krook) – сертифицированный специалист (IBM/Open Group Master Certified IT Specialist), проживающий в Нью-Йорке. Имеет более чем 10-летний опыт разработки Web-приложений, а в настоящее время занимается созданием облачной инфраструктуры для IBM с использованием Java EE, DB2, REST и мобильных технологий. Имеет сертификаты по PHP, Java EE, BlackBerry, DB2 и Solaris. Пишет статьи по PHP для IBM developerWorks и является соавтором документа IBM Redbook "Разработка PHP-приложений для IBM Data Servers".



Янь Ли Му, ИТ-архитектор, IBM

Янь Ли Му (Yan Li Mu) – ИТ-архитектор, работающий в Даляне (КНР). Занимается созданием Web-приложений более 8 лет, уделяя основное внимание технологиям Java EE, PHP и разработке баз данных.



Марк Ньюскейбл, старший ИТ-архитектор, IBM

Марк Ньюскейбл (Mark Nusekabel) – сертифицированный специалист (IBM/Open Group Master Certified IT Architect), проживающий в Тампа-Бэй, Флорида. Занимается информационными технологиями более 20 лет; в настоящее время проектирует инструментальные средства с использованием JavaScript, PHP, Java и DB2. Имеет сертификаты по решениям для электронного бизнеса, а также по Java и XML.



27.07.2012

Введение в серию статей

В настоящее время MySQL является самым распространенным сервером баз данных, используемым с языком программирования PHP для создания динамичных Web-приложений. Однако популярностью пользуется еще одна база данных DB2, которая хорошо поддерживается PHP и предлагает неоспоримые преимущества в сравнении с MySQL, что делает ее идеальным выбором для многих приложений.

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

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

В данной серии статей, состоящей из четырех частей, рассматриваются уроки успешной миграции с MySQL на DB2 работающего критично-важного PHP-приложения, которое используют 4000 пользователей из разных стран мира для управления содержимым сайта ibm.com.

  • В первой части рассматриваются действия по подготовке миграции.
  • Во второй части рассматриваются действия по миграции базы данных.
  • В третьей части рассматриваются действия по преобразованию PHP-кода.
  • В четвертой части рассматриваются действия по развертыванию и поддержке приложения.

Что вы узнаете

Цель данной серии статей – предоставить информацию о том, что нужно для переноса PHP-приложения с MySQL на DB2, какие имеются дополнительные ресурсы и как группа разработчиков IBM выполнила эту задачу в начале 2010 года.

Если вы изучали миграцию с MySQL на DB2, то, возможно, заметили преимущества DB2, принимая во внимание информацию о продукте, тесты производительности, функции, описанные в документации по DB2, или сравнения в документах IBM Redbooks®, включая "Руководство по переходу с MySQL на DB2" (см. раздел Ресурсы).

Возможно, вам также известно, что DB2 Express-C является бесплатным, полнофункциональным сервером реляционных баз данных, который можно легко установить или опробовать на платформах IBM Smart Business Development and Test Cloud или Amazon EC2 (ссылки приведены в разделе Ресурсы).

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

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

Что не рассматривается

Цель данной серии статей – поделиться с читателями опытом, полученным IBM в процессе внутренней миграции с MySQL на DB2, и предоставить информацию об имеющихся ресурсах для выполнения аналогичной задачи. Она не является всеобъемлющим руководством по миграции, охватывающим все возможные сценарии.

Чтобы определить соответствующий вашим требованиям подход, обратитесь к "Руководству по переходу с MySQL на DB2" или свяжитесь с отделом Software Migration Project Office (SMPO) для бесплатной оценки миграции. Ссылки приведены в разделе Ресурсы.


Введение в развертывание

В статье рассматриваются четыре основных этапа развертывания и поддержки приложения и базы данных после завершения их подготовки к эксплуатации. Место этих действий в общем плане процесса миграции рассматривалось в первой части (EN) данной серии статей.

Этап 1: создание новой среды эксплуатации
  • Определение топологии эксплуатации и стратегии развертывания.
  • Настройка основного сервера DB2 и его копии.
  • Настройка рабочего сервера PHP-приложений.
Этап 2: подготовка стратегии мониторинга приложений
  • Реализация или обновление механизма создания отчетов об ошибках PHP.
  • Определение соответствующих значений для автономных функций DB2.
  • Подтверждение настроек резервирования и репликации базы данных.
Этап 3: развертывание обновленного приложения
  • Планирование даты развертывания для минимизации влияния на бизнес.
  • Создание резервных копий образов существующей и новой системы.
  • Развертывание DB2-данных.
  • Развертывание PHP-кода.
  • Мониторинг новой системы.
Этап 4: непрерывная поддержка
  • Исправление или предупреждение проблем производительности.
  • Реконфигурация по мере увеличения объема данных и потоков работ.

Изучение учебных примеров существующей топологии развертывания PTT

Напоминание

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

  • Главы 9 и 10 документа IBM Redbook® "Руководство по переходу с MySQL на DB2".
  • Статья developerWorks "Список рекомендованной литературы: администрирование базы данных DB2 для Linux, UNIX и Windows".
  • Статья developerWorks "Использование опыта работы с MySQL при изучении DB2 Express".
  • Документ developerWorks "Передовые методики: стратегии снижения затрат при помощи DB2".

Другим вариантом осуществления миграции является использование облака. Можно использовать виртуальные образы Amazon EC2 Linux and DB2 AMI или сервис IBM SmartCloud, ранее известный как IBM Development and Test on the IBM Cloud (см. раздел Ресурсы).

В примере топологии развертывания, рассматриваемом в статье, рабочая система Project Tracking Tool (PTT) состояла из одной Linux-машины, на которой выполнялся Web-сервер Apache, скомпилированный из исходных кодов со скомпонованным и загруженным в виде динамического модуля расширением mod_php, другой Linux-машины, на которой работала главная база данных MySQL, и третьей Linux-машины, на которой работала копия базы данных MySQL для аналитики и незапланированных запросов.

Приложение PTT выполняет различные функции поддержки обработки информации, публикуемой на Web-сайте IBM. Более 4000 пользователей со всего мира обращаются к базе данных MySQL и изменяют ее посредством Web-интерфейса, реализованного на PHP. В любой момент с системой одновременно работает несколько сотен пользователей.

Эта несложная топология показана на рисунке 1.

Рисунок 1. Топология программного обеспечения и оригинального сервера
Рисунок 1. Топология программного обеспечения и оригинального сервера

Подавляющее большинство пользователей обращается к главной базе данных при помощи Apache и PHP-интерфейса. Небольшое число пользователей подключаются напрямую к копии базы данных для выполнения незапланированных SQL-запросов или используют Hyperion Brio для генерирования отчетов.

В примере развертывания была сохранена та же трехсерверная схема, но главная и дублирующая MySQL-системы были заменены экземплярами DB2. Скомпилированный из исходных кодов Apache и конфигурация PHP были заменены бинарными версиями Apache и PHP (Zend Server с расширениями DB2).

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


Подготовка активов развертывания

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

Данные и структура стабильной и одобренной копии базы данных DB2
В зависимости от того, совпадают платформы среды эксплуатации и среды разработки или нет (например, если обе являются 64-разрядными Linux-системами), можно выбрать один из двух подходов передачи данных в эксплуатацию. Если платформы одинаковы, просто выполните резервное копирование базы данных на системе разработки и восстановите ее как новую копию на системе эксплуатации. Если платформы не совпадают, придется добавить набор сценариев на языке определения данных (data definition language – DDL) для создания структуры базы данных, включая такие объекты как ограничения по ключам и допустимым значениям, индексы и конфигурационные настройки. Также необходимо добавить сценарии импорта, использующиеся для переноса данных в новую систему DB2.
Стабильная и одобренная копия преобразованного PHP-кода и другие статические файлы
Она состоит из преобразованного PHP-кода и всех необходимых JavaScript-файлов, CSS-файлов и файлов изображений, образующих Web-приложение. Сюда также включаются shell-сценарии (которые планируются и активизируются с помощью заданий cron), предназначенные для выдачи периодических уведомлений и регулярного обслуживания, например выполнения ночного сохранения данных.

Данные на момент времени

В большинстве случаев рабочая MySQL-система будет продолжать создавать новые данные во время выполнения вами этапов, рассмотренных во второй и третьей части серии (см. раздел Ресурсы). Вероятно, вам понадобится импортировать самые свежие данные в стабильную копию при переносе ее в среду эксплуатации, как указано в этапе 2 второй части серии (EN). В листинге 3 этой статьи показано, как перенести только те данные, которые изменились после первоначального экспорта.

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

Чтобы сохранить образ конфигурации физической машины, воспользуйтесь бесплатной программой VMware vCenter Converter. В качестве альтернативы можно использовать облачную среду. Это могут быть экземпляры Amazon EC2 DB2 AMI или подписка на IBM SmartCloud (прежнее название – Development and Test on the IBM Cloud). Используя виртуальные компьютеры, вы сможете избежать первоначальных затрат на приобретение серверного оборудования, а также на установку операционной системы и DB2, что сэкономит время, ускорит процесс миграции и придаст больше уверенности при проведении экспериментов с конфигурациями, соответствующими вашим требованиям. Ссылки на все эти продукты приведены в разделе Ресурсы.


Этап 1: создание новой среды эксплуатации

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

В нашем учебном примере рабочая среда развертывания создается на новом физическом сервере (хотя виртуальные машины тоже подходят) вместо перенастройки существующих серверов с размещенными на них MySQL-системами (см. рисунок 1). Этот этап включает в себя следующие подэтапы:

Определение стратегии эксплуатации

В нашем примере устанавливаются новые база данных DB2 и ее копия, а данные переносятся на два новых 64-разрядных Linux-сервера. Старые главный и дублирующий MySQL-серверы имели четырехядерные процессоры (3.0 ГГц) и 8 Гб оперативной памяти. Два новых DB2-сервера имеют восьмиядерные процессоры (2.5 ГГц) и 16 Гб оперативной памяти. Более высокая мощность отражает скорее возраст машин, а не необходимость в более производительном оборудовании для DB2. Опыт миграции, преобразования и тестирования, полученный вами в предыдущих статьях серии (см. раздел Ресурсы), поможет правильно распределить ресурсы для рабочей нагрузки.

Методы развертывания

При подготовке обновленного приложения к эксплуатации необходимо ответить на важные вопросы:

  • Вы начнете с новой конфигурации, или замените ПО на существующей системе и будете использовать существующее оборудование? Иными словами, будет ли выполняться инсталляция DB2 и деинсталляция MySQL в рамках одной и той же операции развертывания?
  • Обновление базы данных и версии PHP будет выполняться одновременно или по отдельности? Т.е. будет ли PHP-среда обновляться на Zend Server при работающей MySQL, которая затем будет заменена на DB2?

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

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

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

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

Например, одним из рассмотренных вариантов была замена специально скомпилированных Apache и PHP на упакованные версии перед переходом с MySQL на DB2. В конечном счете, было принято решение сразу заменить все компоненты, интеграция которых была протестирована, вместо поэтапного инкрементного изменения инфраструктуры.

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

Вначале планировалось просто заменить экземпляры MySQL на базы данных DB2, но принятый вариант использования имел преимущество – обновление специально скомпонованных версий Apache и PHP на упакованные и легко обслуживаемые версии.

Настройка главного и дублирующего серверов баз данных DB2

Установите DB2 Enterprise v9.7.2 на два идентичных 64-разрядных сервера с ОС Red Hat Enterprise Linux. Как отмечалось на первой боковой вкладке данной статьи, в статьях developerWorks "Администрирование базы данных DB2 для Linux, UNIX и Windows" и "Использование опыта работы с MySQL при изучении DB2 Express: администрировании и базовые задачи DB2 в сравнении с MySQL" предоставляется отличный обзор ключевых задач настройки и администрирования (см. раздел Ресурсы).

Настройка сервера PHP-приложений

Установите на сервер приложений Apache и Zend Server. Этот сервер может использовать те же спецификации, что и серверы баз данных. На предыдущем рабочем сервере Apache был скомпилирован из исходных кодов, а PHP выполнялся как динамический общий модуль.

Для новой рабочей системы использовались сервер Zend Server и утилита управления пакетами операционной системы для работы с пакетом Apache (http) и обновлениями. Этот выбор был сделан по следующим причинам:

  • Zend Server – это бинарный дистрибутив PHP, который автоматически настраивает Web-сервер Apache. Он поддерживается и был протестирован на корпоративных версиях Linux-дистрибутивов. Его легко установить и обслуживать в формате пакетов, которыми можно управлять при помощи программы yum в Red Hat Linux.
  • Zend Server содержит драйверы для DB2 и предоставляет графический интерфейс для настройки необходимых расширений.
  • Zend Server предоставляет функции мониторинга, журналирования и отправки предупреждений, которые обеспечивают больший контроль над работой системы.

В статье developerWorks "Создание облачной среды разработки PHP-приложений" Дэниела Крука (Daniel Krook) приведена дополнительная подробная информация по установке и настройке DB2 с Zend Server (см. раздел Ресурсы). В этой статье рассматривается очень похожий процесс.

На рисунке 2 показана система после замены MySQL на DB2 и обновления на Zend Server. Последним фрагментом пазла являлась установка основанного на Web-технологиях программного обеспечения IBM Cognos Business Intelligence (вместо старого настольного приложения Hyperion Brio), которое было настроено на генерирование аналитической информации из новой базы данных DB2. Ссылка на дополнительную информацию по установке Cognos приведена в разделе Ресурсы.

Рисунок 2. Новая топология серверов и программного обеспечения
Рисунок 2. Новая топология серверов и программного обеспечения

Этап 2: подготовка стратегии мониторинга приложений

Давно эксплуатируемые системы могут иметь механизм уведомления об ошибках. В нашем случае, поскольку в PHP используется PDO уровень абстракции базы данных, была возможность использовать существующую систему для уведомления администраторов о проблемах в коде. На уровне базы данных использовался DB2 Health Monitor для выдачи уведомлений о достижении или превышении указанной границы определенными показателями. Этот этап включает в себя следующие подэтапы:

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

Настройка PHP-механизма уведомления об ошибках

Не имеет значения, насколько тщательно выполнены разработка и тестирование – все равно есть шанс возникновения непредвиденных ошибок во время эксплуатации. Приложение всегда должно иметь эффективную функцию автоматической отладки. Если в Web-приложении возникает ошибка, оно собирает всю информацию о контексте ошибки и отправляет письмо по электронной почте разработчикам, для того чтобы они смогли немедленно идентифицировать и исправить проблему. Это особенно полезно для приложений, только что перенесенных на DB2. Можно включить подробную информацию о состоянии DB2 SQL и кодах ошибок, что поможет разработчику при отладке.

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

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

  • Отправка электронного письма в службу поддержки при возникновении любых ошибок в SQL.
  • Отправка электронного письма в службу поддержки, если выполнение страницы продолжается более 60 секунд.

Для перехвата SQL-ошибок был реализован класс доступа к базе данных, предоставляющий набор методов для выполнения всех прикладных запросов. Все SQL-выражения направлялись через этот класс и его методы, так чтобы SQL-запросы могли выполняться в блоке try/catch. При возникновении ошибок класс может собрать полную отладочную информацию и отправить ее в службу поддержки. В электронные письма включалась следующая информация: код ошибки и сообщение из DB2, выполняемое SQL-выражение, трассировка стека PHP, учетная запись конечного пользователя, активизировавшего операцию. Используя эту информацию, служба поддержки может локализовать ошибку и решить проблему.

В листинге 1 приведен фрагмент PHP-класса доступа к базе данных, в котором SQL-выражения выполняются в рамках PDO-транзакции и все проблемы перехватываются посредством PDOException.

Листинг 1. Простой PHP-код для перехвата и выдачи уведомлений об ошибках в базе данных, использующий PDOException
<?php
// Запрос или обновление базы данных, указанные приложением.
// $query = ...
Database::beginTransaction();

try {                     
	$res = Database::getRawResource()->prepare($query);
	Database::$affectedRows = 0;
	foreach ($data as $itemData) {
		Database::$queryCount++;
		if (!$res->execute($itemData)) {
			throw new PDOException("Could not execute query: $query");
		}
		Database::$affectedRows += $res->rowCount();
		$res->closeCursor();
	}
	
} catch (PDOException $e) {  
	Database::rollback();
	$error = new error("Database error: " . $e->getMessage(), 0, $query);
	if (true == Config::get('DB', 'DIE')) {
		// Собирает полную информацию о трассировке ошибки и
		// отправляет уведомление.
		$error->nicedie(); 
		return $error;	
	}	
}

Database::commit();

Для выявления непроизводительного выполнения кода и запросов этот сценарий следит за временем выполнения каждой страницы. Сценарий записывает время начала выполнения основной бизнес-логики и запрашивает время окончания отображения основного содержимого, а затем оценивает время всей транзакции. Если транзакция длилась более 60 секунд, отправляется уведомление по электронной почте с содержимым PHP-стека трассировки, параметрами, отправленными вместе с HTTP-запросом, информацией о браузере и учетной записи пользователя, активизировавшего операцию.

В листинге 2 приведен PHP-сценарий, использующий константу порогового значения (60 секунд) и отправляющий уведомление на указанный адрес электронной почты администратора.

Листинг 2. Пример PHP-кода для определения времени выполнения сценария
<?php
// Эта статическая функция возвращает текущую метку времени UNIX в микросекундах.
function getmicrotime() {
	list($usec, $sec) = explode(" ", microtime());
	return ((float) $usec + (float) $sec);
}

$starttime = getmicrotime();

// Основной PHP-код для текущей страницы выполняется здесь.
// ......

$endtime = getmicrotime();

if(($starttime - $endtime) >= $CONFIG['DEBUG']['EXECUTION_THRESHOLD']) {
	$message = "Execution time > ".$CONFIG['DEBUG']['EXECUTION_THRESHOLD'].":\n\n";
	$message .= Error::createReport();
	Mailer::textmail(
		$CONFIG['DEBUG']['EXECUTION_MAIL'], 
		'Execution time greater than '. $CONFIG['DEBUG']['EXECUTION_THRESHOLD'] . 
		' seconds', $message
	);   
}

Определение настроек обслуживания DB2

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

Таблица 1. Настройки обслуживания DB2
ОписаниеНастройкаЗначение
Automatic maintenance (автоматическое обслуживание)AUTO_MAINTOn
Automatic database backup (автоматическое резервное копирование базы данных)AUTO_DB_BACKUPOff
Automatic table maintenance (автоматическое обслуживание таблиц)AUTO_TBL_MAINTOn
Automatic runstats (автоматический сбор статистики)AUTO_RUNSTATSOn
Automatic statement statistics (автоматический сбор статистики выражений)AUTO_STMT_STATSOn
Automatic statistics profiling (автоматическое профилирование статистики)AUTO_STATS_PROFOff
Automatic profile updates (автоматическое обновление профиля)AUTO_STATS_PROFOff
Automatic reorganization (автоматическая реорганизация)AUTO_STATS_PROFOn

Подтверждение настроек резервирования и репликации DB2

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

Как отмечалось во второй части (EN), можно настроить главную и дублирующую базы данных на поддержку синхронизации между ними с использованием SQL Replication. Эта политика была применена, и дублирующая база данных была заполнена данными из главной базы данных путем повторного выполнения SQL-выражений из log-файла.

Более подробная информация о стратегиях резервирования, восстановления и репликации приведена в главе 9 "Руководства по переходу с MySQL на DB2" (cм. раздел Ресурсы). Используйте его для поиска подходящих вам решений.


Этап 3: развертывание обновленного приложения

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

Планирование даты развертывания

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

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

Создание образов существующей и новой систем

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

Развертывание данных DB2

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

Листинг 3. Создание резервной копии базы данных для переноса в рабочую систему
db2 BACKUP DATABASE PTT

В листинге 4 показано, как создать пустую базу данных на рабочем главном сервере DB2. Во второй статье серии объяснялось, почему использовались именно эти параметры конфигурации (EN).

Листинг 4. Создание рабочей базы данных DB2
db2 "CREATE DATABASE PTT
USING CODESET UTF-8
TERRITORY US
COLLATE USING UCA500R1_S1
PAGESIZE 4096"

Как отмечалось ранее, при смене платформы такой метод резервирования и восстановления данных работать не будет. Вместо этого нужно загрузить объекты и структуру базы данных, используя DDL, а затем импортировать данные отдельно. Более подробная информация о загрузке данных приведена во второй статье серии (EN).

После установки приложения и проверки его функциональности запустите сценарии и задания для настройки репликации. Более подробная информация о настройке репликации приведена во второй статье серии (EN).

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

Листинг 5. Восстановление базы данных на рабочем сервере
db2 RESTORE DB PTT TAKEN AT 20100101090000 INTO PTT REPLACE EXISTING

Итак, у нас есть полностью рабочая база данных. Убедитесь в правильности данных, выполнив несколько проверок качества, предложенных в главе 10 "Руководства по переходу с MySQL на DB2" (см. раздел Ресурсы).

Развертывание PHP-кода

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

Мониторинг новой системы

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

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


Этап 4: непрерывная поддержка

Важно внимательно следить за системой даже после достижения ею устойчивого состояния в первые часы или дни после успешного развертывания. Этот этап включает в себя следующие подэтапы:

В главе 10 "Руководства по переходу с MySQL на DB2" (cм. раздел Ресурсы) приведены подробные сведения о методиках диагностики и поиска неисправностей.

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

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

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

Реконфигурация по мере увеличения объема данных и потоков работ

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

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

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


Результаты миграции

Вскоре после развертывания нашего приложения мы определили, что многие из ожидаемых преимуществ были реализованы. В частности, было отмечено улучшение бизнес-процесса, что ожидалось, поскольку система базы данных могла точно измерить критичные для управления бизнесом показатели. Также улучшилась совместимость с расширенными функциональными возможностями DB2 (которые окажут влияние на производительность и масштабируемость при увеличении объема данных в будущем), такими как исключительная масштабируемость, продуманная система безопасности, встроенная поддержка XML и сжатие данных.

Эффект от использования Cognos Business Intelligence

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

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

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

Улучшение качества данных

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

Минимальное влияние на работу пользователей

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

Лучшая производительность и мониторинг

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

Более легкое обслуживание

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

Больше возможностей для использования решений IBM

Помимо возможности использовать Cognos Business Intelligence после миграции на DB2, есть четкий план перехода с PHP на Java EE-решение, основанное на WebSphere, если когда-нибудь будет принято такое решение. Также упростилась интеграция с другим программным обеспечением IBM, облачной инфраструктурой и сервисами платформы.


Заключение

Цель данной серии статей – предоставить информацию о том, что нужно для переноса PHP-приложения с MySQL на DB2, какие имеются дополнительные ресурсы и как эта задача была успешно решена для рассматриваемого приложения.

В первой части вы:

  • узнали о мотивах, рисках и преимуществах преобразования нашего интранет-приложения;
  • познакомились с нашим опытом сбора материалов для изучения DB2, и узнали, что необходимо для миграции с MySQL на DB2;
  • узнали об инструментальных средствах, помогающих выполнить миграцию;
  • узнали, как объединить все ресурсы, которые помогут вам на каждом этапе проекта.

Во второй части вы:

  • познакомились с исходной базой данных MySQL;
  • узнали, как преобразовать структуру этой базы данных в DB2;
  • узнали, как перенести данные в DB2;
  • узнали, как настроить функции администрирования.

В третьей части вы:

  • познакомились с исходным PHP-кодом;
  • узнали, как модифицировать приложение для работы с DB2;
  • узнали, как протестировать и настроить код после его преобразования.

В этой заключительной части серии статей по развертыванию приложений вы:

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

Надеемся, что эта серия статей поможет вам составить план миграции с MySQL на DB2 и предоставит информацию по каждому этапу этого процесса вместе с подробной информацией, полученной нами в процессе миграции нашего приложения.

Чтобы определить соответствующий вашим требованиям подход, обратитесь к "Руководству по переходу с MySQL на DB2" или свяжитесь с отделом Software Migration Project Office (SMPO) для бесплатной оценки миграции. Ссылки приведены в разделе Ресурсы.


Благодарности

Авторы благодарят Леонса Петразикиса (Leons Petrazickis) и Эмбриша Бхаргава (Ambrish Bhargava) за комментарии к статье.

Ресурсы

Научиться

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management, Open source
ArticleID=827875
ArticleTitle=Перенос PHP-приложений с MySQL на DB2: Часть 4. Развертывание приложения
publish-date=07272012