1. © Корпорация Cisco Systems, 2010. Все права защищены. В данном документе содержится общедоступная информация корпорации Cisco. Стр. 1
Официальный документ
Планирование миграции
корпоративных приложений в облако
Руководство по выбору варианта миграции приложений: частное или
общедоступное облако, критерии оценки приложений и лучшие
практические решения для миграции приложений
Введение
Понятие «облачные вычисления» применяется для обозначения абстрагированных
от физической инфраструктуры ИТ-ресурсов и сервисов, доступ к которым
предоставляется по запросу в совместно используемой эластичной
многопользовательской среде. Это понятие отражает смену парадигмы, от которой
выигрывают и ИТ-отделы компаний, и поставщики облачных сервисов.
Согласно определению облачных вычислений, данному Национальным институтом
стандартов и технологий (NIST), ИТ-сервисы, предоставляемые облаком, предлагают:
• модель оплаты за фактическое использование ресурсов с минимальными
начальными расходами или вовсе без них;
• ценообразование по факту использования — то есть затраты определяются
фактическим использованием ресурсов;
• эластичность — объем потребляемых пользователями ресурсов определяется
динамически;
• независимость от местоположения, высокая доступность и отказоустойчивость;
• повсеместный доступ к сервисам — пользователи могут получить доступ
к сервисам в любой точке мира с помощью любого устройства.
Облако может обеспечить доступ к таким сервисам ИТ-инфраструктуры, как
серверы, системы хранения данных, сети и сетевые сервисы (модель
«инфраструктура как услуга», или IaaS), доступ к платформе развертывания
приложений с использованием таких сервисов приложений, как базы данных
(модель «платформа как услуга», или PaaS) и доступ к программным приложениям
по подписке (модель «программное обеспечение как услуга», или SaaS).
Сегодня поставщики облачных сервисов, уже добившиеся превосходных
результатов в области подготовки, управления и масштабирования сервисов для
множества заказчиков, предлагают обслуживание на основе модели
«инфраструктура как услуга», которая позволяет заказчику оплачивать фактическое
использование вычислительной инфраструктуры, предоставленной поставщиком.
Облако, доступ к которому предоставляет поставщик облачных сервисов, называют
общедоступным.
Кроме того, некоторые предприятия предпочитают создавать частные облака —
сервисы корпоративной ИТ-инфраструктуры, управляемые самими предприятиями
и обладающие свойствами облачных структур: самообслуживание, оплата по
факту использования с возмещением, предоставление ресурсов по требованию
и видимость бесконечной масштабируемости.

2. © Корпорация Cisco Systems, 2010. Все права защищены. В данном документе содержится общедоступная информация корпорации Cisco. Стр. 2
Официальный документ
Независимо от того, какая модель реализации облачных сервисов
рассматривается для внедрения — частное или общедоступное облако,
предприятие должно прежде всего определить, какие из своих многочисленных
приложений следует перенести в облако и каким образом осуществить эту
миграцию. При выборе общедоступного облака поставщики облачных сервисов
могут оказать предприятиям помощь в принятии оптимального решения
о миграции приложений. Выбор приложений для миграции и подход к процессу
миграции могут повлиять не только на удобство и успех этого процесса как
такового, но также и на качество обслуживания пользователей.
Рассмотрим компоненты, задействованные в процедуре миграции приложений,
а также коммерческие и технические факторы, стоящие за принятием решения
о миграции приложений в облачную модель.
Миграция приложений и облака
Сегодня в корпоративных центрах обработки данных используется множество
приложений, реализованных на основе имеющейся инфраструктуры, которой
свойственны известные проблемы, касающиеся масштабируемости
и отказоустойчивости. Миграция в облако не решит всех присущих конкретному
приложению проблем масштабируемости или отказоустойчивости, однако
предприятия могут извлечь ощутимую финансовую и операционную выгоду
из миграции приложений с традиционных серверов в облако.
Миграция приложения — это процесс повторного развертывания приложения,
который выполняется, как правило, на новой платформе или в новой
инфраструктуре. Этот процесс включает в себя предварительное тестирование
новой среды перед фактическим переходом к ее использованию и требует
скоординированной работы ИТ-групп во время осуществления перехода. Если
миграция приложения осуществляется между совместимыми платформами,
то перекомпиляция приложения не требуется.
В случае облака приложение может быть перенесено из существующего центра
обработки данных в целевое облако. Целевая инфраструктура может
представлять собой общедоступное, частное или гибридное облако, то есть среду,
которая незаметно для пользователя сочетает использование нескольких облаков,
которые могут быть частными или общедоступными. Кроме того, миграция может
включать в себя трансформацию физического приложения в виртуальное (P2V),
если существующее приложение не работает на виртуализированной платформе.
Чтобы отобрать приложения для миграции в облако, необходимо сначала
определить и проанализировать коммерческие и технические факторы, влияющие
на миграцию. Снижение расходов и повышение гибкости бизнес-процессов
являются типичными коммерческими факторами, стимулирующими миграцию
приложений в облако. Облачные вычисления могут обеспечить значительную
экономию средств благодаря увеличению коэффициента использования ресурсов
в результате их объединения, а также за счет стандартизации и автоматизации,
необходимых для облачных сервисов.
Облачная среда предоставляет быстрый доступ к ИТ-сервисам, что повышает
эффективность бизнес-процессов. Процессы оформления заказов, которые ранее
занимали несколько недель и затрагивали несколько отделов, теперь могут быть
реализованы с помощью нескольких щелчков мышью. Повышение эффективности
ИТ-операций сказывается на общей эффективности бизнес-процессов
и формирует задел для реализации новых возможностей и инноваций.
С точки зрения управления операциями, улучшение управляемости,
производительности и масштабируемости являются типичными факторами,
которые заставляют предприятия рассматривать переход к использованию
облачных технологий. Благодаря делегированию функций управления
инфраструктурой и программными платформами поставщику облачных сервисов
заказчики могут передать этому поставщику также и ответственность за
управление операциями. При использовании модели корпоративного частного
облака единая группа управления облачной ИТ-инфраструктурой может также
взять на себя эти функции.
Среда облачных вычислений может предложить дополнительные ресурсы,
которые будут способствовать повышению производительности определенных
приложений. Приложения, предусматривающие распределение нагрузки между
несколькими серверами, смогут извлечь выгоду из автоматического
масштабирования ресурсов в зависимости от текущей потребности в них. Это
особенно привлекательно для приложений с непредсказуемой или циклической
моделью использования, поскольку диспетчер облака может контролировать
использование ресурсов и динамически увеличивать или уменьшать их объем.
Такие функциональные возможности в сочетании с оплатой за фактическое
использование облачных ресурсов могут привести к существенной экономии.

3. © Корпорация Cisco Systems, 2010. Все права защищены. В данном документе содержится общедоступная информация корпорации Cisco. Стр. 3
Официальный документ
Варианты миграции приложений
После того как на основании коммерческих и технических факторов приложение
выбрано в качестве кандидата на миграцию в облако, необходимо решить, какая
модель облачной среды лучше всего подходит для этого приложения:
«программное обеспечение как услуга», «платформа как услуга» или
«инфраструктура как услуга».
Программное обеспечение как услуга (SaaS)
В зависимости от типа приложения и наличия альтернативных решений на основе
концепции «программное обеспечение как услуга» следует определить, какие из
этих альтернативных решений отвечают как коммерческим, так и техническим
требованиям. Такое изменение представляет собой уже не миграцию приложения,
а скорее замену существующего приложения решением на основе «программного
обеспечения как услуги». При этом может возникнуть необходимость миграции
в новое приложение существующих данных.
Модель «программное обеспечение как услуга» избавляет от необходимости
управлять и приложением, и инфраструктурой, на основе которой развернуто
приложение. Этот подход может быть достаточно привлекательным, но при
рассмотрении варианта развертывания на основе модели «программное
обеспечение как услуга» необходимо тщательно проанализировать ряд критериев,
включая соглашения об уровне обслуживания (SLA), переносимость данных,
а также долгосрочные расходы.
• Соглашения об уровне обслуживания. Поставщик решения «программное
обеспечение как услуга» должен предоставить соглашение об уровне
обслуживания, оговаривающее общие показатели доступности,
масштабируемости и производительности приложения, а также
устанавливающее четкие правила и указания по обслуживанию приложения
и выделению периодов времени для обновлений.
• Переносимость данных. Поставщик решения «программное обеспечение как
услуга» должен предусмотреть механизм, позволяющий заказчикам владеть
и управлять данными своих приложений. Заказчики решений «программное
обеспечение как услуга» должны иметь возможность экспортировать все
принадлежащие им данные приложений в формате, обеспечивающем простой
разбор данных и их миграцию в другие внутренние или внешние приложения.
• Долгосрочные расходы. Благодаря низким начальным затратам модель
«программное обеспечение как услуга» может быть финансово
привлекательной для малого бизнеса или предприятий, которые еще не
вложили значительных средств в собственный центр обработки данных. Однако
по мере роста числа пользователей и увеличения срока владения необходимо
внимательно сравнивать долгосрочные периодические расходы,
распределенные во времени, с амортизированной стоимостью владения.
Как и в других финансовых моделях на основе аренды, совокупная стоимость
владения с течением времени и увеличением срока использования может быть
больше, чем в других случаях.
• Управление пользователями. Управление корпоративными пользователями,
как правило, осуществляется с помощью служб каталога, таких как Microsoft
Active Directory, или других сервисов на основе облегченного протокола доступа
к каталогам (LDAP). При добавлении, удалении или изменении учетных записей
пользователей большинство приложений, использующих модель «программное
обеспечение как услуга», не обеспечивают автоматический учет этих
изменений, создавая тем самым дополнительную работу для администраторов
ИТ-инфраструктуры и потенциальные угрозы безопасности.
• Безопасность. Приложение, хранящееся в инфраструктуре поставщика
сервисов «программное обеспечение как услуга», может содержать
конфиденциальные данные заказчика. В зависимости от характера данных
приложения заказчик должен требовать прозрачности политик безопасности
поставщика сервисов «программное обеспечение как услуга», чтобы иметь
возможность определить адекватность мер обеспечения безопасности.
Платформа как услуга (PaaS)
Концепция предоставления платформы как услуги может быть приемлемым
вариантом для миграции бизнес-приложений, которые основаны на стандартном
программном обеспечении серверов приложений, таком как Java EE 5 или
платформа Microsoft .NET.
При использовании этой модели поставщик услуг управляет программным
обеспечением платформы приложений и может предоставлять доступ к общим
сервисам приложений, таким как базы данных SQL. Платформа приложений может
быть разделена между несколькими приложениями, принадлежащими различным
заказчикам. Сопоставление платформы приложений с физической
инфраструктурой, как правило, определяется поставщиком облачных сервисов
Факторы, определяющие принятие решений о такой миграции, зависят от типа
и версии используемого сервера приложений. Некоторые среды «платформа как
услуга» могут поддерживать не все функции сервера приложений, — в этом случае
может потребоваться доработка приложения.

4. © Корпорация Cisco Systems, 2010. Все права защищены. В данном документе содержится общедоступная информация корпорации Cisco. Стр. 4
Официальный документ
При миграции приложений в облако с использованием модели «платформа как услуга»
следует учитывать те же критерии, которые рассматривались в случае с моделью
«программное обеспечение как услуга», в том числе соглашения об уровне обслуживания,
переносимость данных, долгосрочные затраты, управление пользователями и безопасность.
• Соглашения об уровне обслуживания. Поставщик решения «платформа как услуга»
должен предоставить соглашения об уровне обслуживания по доступности
и производительности платформы приложений. Поставщик облачных сервисов также
должен установить четкие правила и предоставить указания по обслуживанию
и управлению версиями платформы, а также правила в области обеспечения совместимости
версий API-интерфейсов между платформой и приложением.
• Переносимость данных. При использовании модели «платформа как услуга» данные
приложений, как правило, хранятся в базе данных, предоставленной поставщиком облачных
сервисов. Заказчик должен иметь возможность экспорта этих данных в формате,
обеспечивающем их миграцию в другие базы данных.
• Долгосрочные расходы. Финансовую модель «платформа как услуга» следует сравнить
с моделью внутреннего развертывания инфраструктуры, а также с моделями
развертывания сервера приложений/платформы на основе модели «инфраструктура как
услуга» и на облачных серверах.
• Управление пользователями. Приложение, развернутое на основе модели «платформа
как услуга», потребует введения учетных записей администратора и пользователя.
Заказчики должны согласовать использование этих типов учетных записей
с существующими службами каталогов и процессами управления пользователями.
• Безопасность. При развертывании решения на основе модели «платформа как услуга»
один и тот же сервер приложений может поддерживать приложения разных заказчиков.
В таких условиях необходимо принимать дополнительные меры безопасности, позволяющие
гарантировать, что вредоносные программы не смогут использовать уязвимости
в программной платформе для нарушения работы других приложений.
При оценке решения на основе модели «платформа как услуга» предприятия также должны
учитывать особенности управления платформой и ее масштабируемость.
• Управление платформой. Серверы приложений предоставляют консоли управления
и инструменты для контроля и управления развернутыми на них приложениями. При
развертывании решения «платформа как услуга» заказчикам следует предоставить возможность
использовать аналогичные инструменты для управления и настройки их приложений.
• Масштабируемость платформы. В качестве дополнительной функции рабочая среда
«платформа как услуга» может предлагать динамическое масштабирование (в сторону
увеличения или уменьшения) на основе возможностей используемого сервера приложений.
Функция динамического масштабирования хорошо работает с приложениями,
пользовательская нагрузка которых имеет недетерминированный характер, например
с потребительскими интернет-приложениями. При использовании этой функции поставщик
решения «платформа как услуга» должен предоставить четкие правила для
масштабирования в обе стороны и для конкуренции за обладание ресурсами.
Инфраструктура как услуга (IaaS)
Миграция приложения в облако с использованием модели «инфраструктура как услуга»
предполагает его развертывание на серверах поставщика облачных сервисов.
При принятии решения о переходе к модели «инфраструктура как услуга» прежде всего
необходимо определить, совместимы ли аппаратные средства и операционная система (ОС)
облачного сервера с аппаратными средствами и ОС используемого физического сервера.
Например, если приложение работает на сервере с процессором x86, облачные серверы
должны поддерживать выполнение команд x86. Если аппаратные средства не совместимы,
может потребоваться перекомпиляция приложения или его повторное развертывание на новой
платформе. То же относится и к операционной системе: если ОС совместимы, то при миграции
приложения потребуются лишь незначительные изменения.
При оценке возможности использования модели «инфраструктура как услуга» также следует
рассматривать те же самые критерии, которые учитываются при миграции приложений
в облако на основе моделей «программное обеспечение как услуга» или «платформа как
услуга», в том числе соглашения об уровне обслуживания, переносимость данных,
долгосрочные затраты, управление пользователями и безопасность.
• Соглашения об уровне обслуживания. Для развертывания решения «инфраструктура
как услуга» требуется соглашение об уровне обслуживания по доступности
и производительности серверов, сети и инфраструктуры хранения данных. Кроме того,
заказчик должен получить информацию о процедурах технического обслуживания
и управления инфраструктурой, а также о порядке действий при возможных простоях.
• Переносимость данных. При развертывании приложения в облаке на основе модели
«инфраструктура как услуга» оно может использовать сервер базы данных, который также
развернут в облаке. В таком случае поставщик облачных сервисов должен предоставить
способ дублирования данных или обеспечить миграцию соответствующего блока данных
или системы хранения файлов, используемого этим сервером базы данных.
• Долгосрочные расходы. Следует сравнить расходы на приложение при использовании
модели «инфраструктура как услуга» с расходами на развертывание этого приложения на
корпоративных серверах. В некоторых случаях развертывание модели «инфраструктура как
услуга» в общедоступных облаках может предлагать очевидные преимущества благодаря
динамическому масштабированию и ценообразованию на основе фактического использования.
Для постоянно работающих приложений стоимость владения при развертывании
в общедоступном облаке зависит от используемых ими вычислительных ресурсов
и в долгосрочной перспективе может превышать стоимость владения в частном облаке.

5. © Корпорация Cisco Systems, 2010. Все права защищены. В данном документе содержится общедоступная информация корпорации Cisco. Стр. 5
Официальный документ
• Управление пользователями. В модели «инфраструктура как услуга»
предусмотрено использование до трех различных ролей:
– администратор сервера;
– администратор приложения;
– пользователь приложения.
Следует оценить процедуры и инструменты управления пользователями для каждой
из этих ролей.
• Безопасность. При выборе модели «инфраструктура как услуга» на основе
совместно используемой физической инфраструктуры могут быть реализованы
виртуальные машины, принадлежащие разным заказчикам. При рассмотрении
миграции приложений необходимо изучить политики безопасности поставщика
облачных сервисов в отношении изоляции виртуальных и физических
компонентов, а также ситуацию с соблюдением нормативных требований.
Поставщик облачных сервисов должен разрешить проведение аудита системы
безопасности и соблюдения нормативных требований с использованием
перспективных технологий и спецификаций, например разработанных в рамках
проекта CloudAudit.
• Масштабируемость. Приложения, в которых предусмотрена возможность
масштабирования, выиграют от наличия функций динамического
масштабирования, реализованных в облаке. Такие приложения, как правило,
имеют многоуровневую структуру и функции распределения нагрузки по запросу,
что позволяет динамически масштабировать пул серверов приложений, не
фиксирующих состояние транзакций. Если заказчик собирается использовать
эту функцию, поставщик облачных сервисов должен предоставить ему четкие
правила функционирования механизма масштабирования и разрешения
конфликтов при конкуренции за обладание ресурсами для разных заказчиков
и приложений.
Частные и общедоступные облака
Поставщики облачных сервисов могут предложить заказчикам расширенные
возможности корпоративного уровня по безопасности и производительности
в сочетании с набором дополнительных сервисов, таких как распределение
нагрузки и сервисы оптимизации работы с глобальными сетями. После
ознакомления с этими аспектами предложений поставщика облачных сервисов
необходимо определить, всегда ли миграция приложений в общедоступное облако
является хорошей стратегией. Не каждое приложение подходит для миграции
в общедоступное облако. При принятии решения о выборе общедоступного или
частного облака для миграции приложений необходимо изучить структуру трафика
глобальной сети, вопросы защиты и управления данными, интеграции
унаследованных приложений, а также требования по безопасности и соблюдению
нормативов.
• Трафик глобальной сети. Если работа приложения подразумевает интенсивный
трафик и взаимодействие с другими приложениями или ресурсами центра
обработки данных, то миграция в общедоступное облако не будет оптимальным
решением из-за расходов на обеспечение необходимой пропускной способности
глобальной сети и возможного влияния на производительность.
• Защита и управление данными. Приложения могут зависеть от общедоступной
центральной системы хранения данных или других ресурсов, таких как службы
каталогов для управления пользователями, профилями и данными. Такие
зависимости необходимо выявлять и учитывать при оценке возможности
миграции приложений.
• Интеграция унаследованных приложений. Необходимость поддержки
унаследованных бизнес-приложений, которые работают на больших ЭВМ
и платформах AS400 и могут быть тесно интегрированы с другими бизнес-
приложениями, может представлять риск, подлежащий устранению при миграции
в общедоступное облако. Приложения, зависящие от унаследованных
приложений, очевидно, являются хорошими кандидатами для миграции
в частные облака.
• Требования по безопасности и соблюдению нормативов. При использовании
частного облака предприятие имеет более широкие возможности контроля над
архитектурой инфраструктуры и операционными политиками. Эти возможности
могут обеспечить повышение эффективности за счет индивидуальной настройки
и оптимизации, что также следует учитывать при оценке дополнительных
расходов.

6. © Корпорация Cisco Systems, 2010. Все права защищены. В данном документе содержится общедоступная информация корпорации Cisco. Стр. 6
Официальный документ
Критерии оценки приложений
После выбора типа облачной среды и модели предоставления облачных
сервисов приложение, являющееся кандидатом для миграции, подвергается
дальнейшей оценке, которая позволит убедиться в осуществимости миграции
и подготовиться к ней.
Архитектуры приложений
Архитектура приложения влияет на способ миграции приложения в облачную среду,
а иногда на саму возможность миграции. В следующих разделах обсуждаются
общие особенности архитектуры приложений и их влияние на миграцию
приложений в облако.
Многоуровневые приложения
Большинство корпоративных приложений строятся с использованием нескольких
уровней, чтобы разделить основные функции и модули системы. Один из таких
подходов предусматривает создание приложения с тремя следующими уровнями:
• уровень управления данными, который состоит из компонентов реляционных
и других баз данных;
• уровень бизнес-логики, который использует платформу приложений или
контейнеры, такие как Java EE или Microsoft .NET;
• уровень представления, который отвечает за взаимодействие
с пользовательскими интерфейсами и другими внешними системами, включая
управление состояниями и данными для представления этим внешним
системам.
Приложения, для создания которых применяется многоуровневый подход
к организации архитектуры, имеют четко определенные интерфейсы между этими
уровнями. В некоторых случаях особенности использования приложений делают
возможным миграцию отдельных уровней или модулей приложения. Например,
статическое содержимое веб-приложения можно перенести в инфраструктуру сети
доставки информации, что позволит быстрее загружать компоненты веб-сайта.
В другой ситуации ограничение пропускной способности глобальной сети может
помешать разделению уровней, что приводит к решению о миграции в облако всех
уровней приложения. В любом случае вопросы определения необходимых
ресурсов и порядка миграции в облако для каждого уровня и составляющих его
основных модулей должны рассматриваться отдельно.
Уровни приложения также могут иметь различные требования по безопасности
и зонированию. Например, для защиты некоторых данных приложения может
потребоваться применение межсетевого экрана.
Архитектуры с вертикальным и горизонтальным масштабированием
При использовании архитектуры с вертикальным масштабированием возможности
приложения расширяются за счет наращивания ресурсов (таких как
вычислительная мощность и объем памяти) конкретного сервера или узла.
С другой стороны, архитектура с горизонтальным масштабированием
предусматривает расширение возможностей приложения путем добавления
дополнительных узлов, между которыми распределяется рабочая нагрузка; то есть
масштабирование выполняется по горизонтали.
Приложения с горизонтальным масштабированием могут использовать
преимущества модели оплаты за фактическое использование ресурсов в облаке.
При большом количестве запросов к приложению справиться с повышенной
нагрузкой помогает выделение дополнительных узлов. При снижении объема
запросов дополнительные узлы можно отключить с целью сокращения расходов.
В настоящее время невозможно реализовать динамическое масштабирование
приложений, работающих на одном экземпляре виртуальной машины. В будущем
ситуация может измениться, поскольку системы виртуализации начинают
поддерживать функции горячего переключения, позволяющие динамически
подключать дополнительные процессоры и модули памяти.

7. © Корпорация Cisco Systems, 2010. Все права защищены. В данном документе содержится общедоступная информация корпорации Cisco. Стр. 7
Официальный документ
Доступ с учетом географического местоположения
Некоторые приложения используются в пределах определенных географических
зон, в то время как другие можно использовать из разных точек или даже
в глобальных масштабах. Например, интернет-приложения, предназначенные для
взаимодействия с потребителями, часто используются в различных регионах мира
непредсказуемым образом. С другой стороны, предприятия, имеющие несколько
филиалов, могут выиграть от возможности размещения приложений ближе
к точкам доступа.
При миграции приложения в облако необходимо учитывать географическое
расположение точек, из которых будет осуществляться доступ к приложению.
Большинство глобальных поставщиков облачных сервисов реализуют механизм,
который позволяет оптимизировать доступ к приложениям за счет приобретения
пропускной способности каналов связи, расположенных в разных регионах или
географических зонах. В некоторых ситуациях может возникнуть необходимость
запретить или заблокировать доступ к приложениям из определенного региона,
что может быть продиктовано соображениями безопасности или требованиями
по соблюдению нормативов.
При выборе облака важно учесть эти факторы и убедиться в наличии
возможностей контроля, управления и оптимизации доступа с учетом
географического положения.
Составление карты зависимостей приложений
Составление карты зависимостей приложений (рис. 1) позволяет определить
зависимости между приложениями, а также зависимости приложений от общей
инфраструктуры центра обработки данных.
Сбор данных может осуществляться в несколько проходов или этапов: сначала
выявляются все прямые зависимости данного приложения, затем определяются
приложения, зависящие от данного приложения. Например, если два приложения,
А и Б, используют один и тот же сервер базы данных, эти зависимости необходимо
учесть, чтобы включить в план миграции комбинированное перемещение или
действия по разделению зависимостей.
Инструменты для составления карты зависимостей позволяют также создавать
карты привязки серверов и приложений, основанные на наблюдаемом трафике
между приложениями. Эти карты дают возможность оценить, какие приложения
следует объединять в пакеты для миграции.
Рисунок 1. Пример карты зависимостей приложений

8. © Корпорация Cisco Systems, 2010. Все права защищены. В данном документе содержится общедоступная информация корпорации Cisco. Стр. 8
Официальный документ
Профилирование приложений
Профилирование приложений используется для анализа и сбора данных
о фактическом использовании приложения перед его миграцией в облако. Эти
данные помогают определить объемы необходимых для работы приложения
ресурсов при его развертывании в облаке. В идеальном случае данные о работе
приложения следует собирать в течение по крайней мере 10–15 дней, чтобы
захватить вариации ежедневных и еженедельных профилей использования.
Для каждого узла, на котором выполняется приложение, должны быть собраны
следующие данные:
– использование центрального процессора;
– использование памяти;
– данные о системе хранения данных, включая пропускную способность, задержки
и количество операций ввода/вывода в секунду (IOPS);
– данные о сети, включая пропускную способность, количество соединений
в секунду и количество прерванных соединений.
Данные, собранные на уровне узла, можно использовать для оценки
количества и типов виртуальных машин, которые потребуются при миграции
приложения.
Помимо сбора статистики на уровне узла, важно также определить профиль
активности пользователей, включая общее число подключенных пользователей,
частоту запросов и транзакций, а также задержки запросов. Данные об
использовании можно применять и при создании автоматизированных тестов для
приложений, которые позволяют убедиться в том, что после миграции уровень
обслуживания сохранился или повысился.
Данные о работе узла наряду с данными об использовании приложений позволяют
получить первоначальную оценку затрат на облачные ресурсы.
Планирование и тестирование миграции приложений
Последним шагом подготовки к миграции приложений в облако является
разработка плана и тестов для реальной миграции. Глубина планирования
определяется типом приложения и соответствующими требованиями по
обеспечению непрерывности бизнес-процессов. Если простои во время миграции
неприемлемы или должны быть сведены к минимуму, то приложение следует
переносить в облако поэтапно, обеспечивая одновременную доступность
существующего и перенесенного экземпляров приложения в течение
определенного периода времени. После успешного завершения первых тестов
можно поэтапно произвести миграцию в облако пользователей; со временем также
можно увеличить пропускную способность облака.
Данные о приложении, собранные на предыдущих этапах, можно использовать
для создания пакетов тестов и моделирования различных типов пользователей
и нагрузок. План тестирования и автоматизированные тесты помогут убедиться
в успехе миграции.
Проектирование решения — возможность для оказания
профессиональных услуг
Оценка приложений, разработка планов миграции и осуществление миграции
приложений в намеченную облачную модель или модели представляют собой сложные
задачи. Для их решения требуется опыт детального проектирования процесса
миграции и глубокое понимание моделей облачных вычислений, а также подробные
знания о взаимодействии приложений друг с другом, с внешней средой (облаком)
и базовой инфраструктурой. Также требуется опыт интеграции ИТ-систем и систем
управления облаком, а также разработка структурированного подхода к управлению
всей программой (что само по себе является достаточно сложным проектом).
Сервисное подразделение Cisco Services обладает обширными знаниями
и опытом в каждой из этих областей, которые подкреплены многолетним участием
корпорации в проектах реорганизации центров обработки данных своих заказчиков.
Сервисное подразделение Cisco Services предлагает широкий спектр услуг по
внедрению облачных технологий — от разработки стратегии до проектирования
и реализации. Миграция приложений является неотъемлемой частью каждой из
этих услуг, а эксперты Cisco Services по облачным вычислениям уже разработали
детальные методики миграции. Поэтому Cisco Services идеально подходит для
оказания помощи в проектировании и разработке современного подхода
к миграции приложений для развертывания собственного облака заказчика.

9. © Корпорация Cisco Systems, 2010. Все права защищены. В данном документе содержится общедоступная информация корпорации Cisco. Стр. 9
Официальный документ
Выводы
При выборе вариантов, оценке и планировании миграции приложений центра
обработки данных в облако следует учитывать множество различных аспектов.
Этот процесс начинается с анализа различных факторов, свойственных
приложениям, и сравнения этих факторов с учетом применения в облачных
средах различных типов. На следующих этапах выполняется анализ и оценка
особенностей приложений, что позволяет создать план миграции, а также план
для тестирования каждого этапа процесса миграции. Этот процесс (рис. 2) часто
носит итеративный характер, поскольку в ходе его реализации могут
обнаружиться данные, ведущие к переоценке результатов, полученных на
предыдущих этапах. Ни один подход не будет одинаково хорошо работать для
всех приложений, однако лучшие практические решения, рекомендованные Cisco,
помогут определить пригодность приложений для миграции и беспроблемно
осуществить саму миграцию. И, наконец, Cisco Services занимает идеальные
позиции, чтобы помочь заказчикам в подготовке и разработке расширенного
подхода к миграции приложений, который обеспечит быстрый возврат инвестиций
в облачные технологии.
Рисунок 2. Процесс миграции приложений
Для получения дополнительной информации об облачных технологиях
Cisco
®
посетите веб-сайт www.cisco.com/go/cloud enablement.
Для получения дополнительной информации об услугах по составлению карты
зависимостей приложений посетите веб-сайт
www.cisco.com/en/US/products/ps10437/services_segment_service_home.html.
Штаб-квартира в Северной
и Южной Америке
Корпорация Cisco Systems
Сан-Хосе, Калифорния
Штаб-квартира в Азиатско-
Тихоокеанском регионе
Cisco Systems (USA) Pte. Ltd.
Сингапур
Штаб-квартира в Европе
Cisco Systems International BV
Амстердам, Нидерланды
У Cisco более 200 офисов, расположенных по всему миру. Адреса, номера телефонов и факсов приведены на веб-сайте Cisco по адресу:
www.cisco.com/go/offices.
Cisco и логотип Cisco являются товарными знаками корпорации Cisco Systems и/или ее дочерних компаний в США и других странах. Список товарных знаков Cisco можно просмотреть на странице
www.cisco.com/go/trademarks. Товарные знаки сторонних организаций, упомянутые в настоящем документе, являются собственностью соответствующих владельцев. Использование слова «партнер»
не предполагает отношений партнерства между Cisco и какой-либо другой компанией. (1005R)
Отпечатано в США C11-618438-00 08/10