Перенос корпоративных сервисов в публичное или частное облако вызывает множество вопросов. Подготовили руководство о том, как подготовиться к миграции, выбрать поставщика услуг и сами приложения для размещения в облаке, а также несколько рекомендаций, которые помогут оптимизировать сам процесс.
- Публичные и частные облака для бизнеса
- Миграция бизнес-приложений в облако: основные аспекты
- Выбор корпоративных приложений для миграции в облако
- Миграция корпоративных приложений в публичное облако
- Публичное или частное облако?
- Критерии оценки приложений
- Профилирование приложений
- Планирование миграции
- Почему важно доверить реализацию проекта профессионалам
- Резюме
Публичные и частные облака для бизнеса
Облако представляет собой модель услуг, при которой провайдер на своей площадке выделяет в пользование клиентов IT-ресурсы на базе собственного оборудования, а клиенты получают к этим ресурсам доступ по сети. Публичное облако (Public Cloud), под которым мы также понимаем IaaS или «инфраструктуру как сервис», позволяет использовать серверы, хранилища данных и сетевые услуги.
Особенности публичного облака для бизнеса:
- гибкая модель оплаты: только за выделенные провайдером ресурсы;
- эластичность: можно быстро получать дополнительные ресурсы по запросу;
- оптимизация начальных затрат: нулевые или минимальные вложения на развертывание IT-инфраструктуры в облаке;
- отказоустойчивость и высокая доступность данных: в любой момент сервисы доступны из любой точки мира при наличии стабильного интернет-подключения.
Компании, которые выдвигают повышенные требования к безопасности, желают монопольно распоряжаться выделенными провайдером IT-ресурсами или нуждаются в индивидуальной конфигурации этих ресурсов, предпочитают частное облако — Private Cloud. В этом случае они получают доступ не только к виртуальным серверам и хранилищу, но также к аппаратной части и гипервизору. В частном облаке вы можете самостоятельно заниматься администрированием и получить больше инструментов для контроля и управления, чем в Public Cloud.
Независимо от выбора модели облачных услуг вам необходимо решить, какие именно бизнес-приложения вы перенесете в облако и как реализуете это на практике. Выбранная стратегия и перечень сервисов, подлежащих миграции, повлияют не только на сложность реализации проекта и конечный результат, но на удовлетворенность пользователей — ваших клиентов.
Предлагаем рассмотреть организационные и технические аспекты миграции бизнес-приложений в облако.
Миграция бизнес-приложений в облако: основные аспекты
Некоторые корпоративные сервисы сталкиваются со сложностью масштабирования или недостаточно высокой отказоустойчивостью. Хотя облако само по себе не позволяет преодолеть внутренние ограничения на расширение или повысить доступность приложений, миграция инфраструктуры в облако может принести вашей компании ощутимые финансовые выгоды, особенно если ранее IT-инфраструктура была развернута на локальном устаревшем оборудовании.
Миграция бизнес-сервисов представляет собой процесс их повторного развертывания на новой платформе. При этом если миграция выполняется между совместимыми платформами, вторичная компиляция приложений не потребуется.
В контексте облачных вычислений новая платформа будет представлять собой площадку — дата-центр, который построили и обслуживают профессионалы, — полностью подготовленную для размещения клиентских приложений. Ваша задача заключается в том, чтобы выбрать надежного провайдера: такого, который предлагает разместить IT-инфраструктуру в сертифицированном дата-центре, имеет большую IT-экспертизу, хорошую репутацию и может оказать профессиональную помощь с миграцией и последующим администрированием.
Откуда можно мигрировать бизнес-приложения:
- отдельно стоящий сервер (малый и средний бизнес);
- построенный клиентом дата-центр (крупный бизнес);
- арендованный клиентом сервер (локально или в дата-центре);
- сервер, размещенный в локально развернутом облаке;
- SaaS-сервис (импорт или перенос данных). Куда именно в облако можно мигрировать бизнес-приложения:
- в общедоступное облако;
- в частное облако;
- в гибридную среду: комбинация частного и общедоступного облака.
Возможные частные случаи переноса данных. Например, миграция вида P2V (Physical–to–Virtual), когда физический сервер полностью переносится в виртуальную среду, включая операционную систему, приложения и их данные. Существуют специальные программные решения (конвертеры), позволяющие автоматизировать процесс такой миграции и сократить количество ошибок, которые могут возникнуть при этом. Если приложение размещалось на виртуальном сервере, его достаточно смигрировать/конвертировать.
Выбор корпоративных приложений для миграции в облако
Определитесь, какие технические и коммерческие цели вы преследуете. Часто компания принимает решение о миграции в облако, когда приходит время обновлять или масштабировать локальную IT-инфраструктуру со всеми вытекающими последствиями. В таком случае организации необходимо согласовать модернизацию, выделить бюджет или оформить покупку в лизинг/кредит, а затем дождаться поставки, разместить и настроить оборудование.
Все это влечет за собой крупные затраты, которые не всегда целесообразны. В то же время некоторые облачные модели (в частности, Public Cloud) позволяют быстро получать необходимые ресурсы по запросу, повышают доступность и эффективность работы приложений. Вам больше не придется тратить недели на модернизацию серверов, если вырастет потребность в вычислительных ресурсах. В публичном облаке их можно получить практически мгновенно, что очень важно для приложений со скачкообразным спросом.
Есть и другие причины, по которым бизнес выбирает облачную модель работы, — это улучшенная управляемость, производительность и масштабируемость IT-инфраструктуры. Вы можете полностью делегировать провайдеру задачи по миграции данных, а также дальнейшее управление инфраструктурой независимо от того, в каком облаке она будет размещаться: частном или публичном.
В отдельных сценариях облачная среда может стать идеальной площадкой для развертывания высокопроизводительных приложений. Балансировщик нагрузки будет автоматически перераспределять нагрузку между несколькими серверами в пределах одного или нескольких кластеров (для сервисов высокой доступности), чтобы более гибко реагировать на меняющийся спрос. А вариант оплаты только за те ресурсы, которые вы запросили у провайдера для своих приложений, позволяет ощутимо сократить операционные расходы компании.
Миграция корпоративных приложений в публичное облако
После определения списка приложений-кандидатов на перенос в облако необходимо детально изучить технические и организационные аспекты миграции. Сделаем это на примере Public Cloud, которое поставщики услуг предлагают в виде продукта с названием IaaS (Infrastructure as a Service).
Первое, что необходимо сделать — это оценить возможность переноса выбранных приложений с учетом их требований к техническим параметрам оборудования и перечня поддерживаемых ОС. Если в новой конфигурации вычислительных ресурсов используется несовместимое с вашим сервисом оборудование, может потребоваться перекомпиляция приложения.
Рассказываем, что следует предусмотреть и изучить до миграции IT-инфраструктуры в публичное облако.
Договор и SLA
Необходимо понять, какой уровень доступности гарантирует поставщик услуг и какую финансовую ответственность несет в случае невыполнения обязательств. Здесь важно различать доступность IT-инфраструктуры (серверы, системы хранения данных) от доступности сетевой инфраструктуры и доступности сервисов самого дата-центра, которая обязательно подтверждается сертификатами. Если для ЦОД, расположенных в США, оценить надежность можно по уровню Tier (классификация Uptime Institute), то качество работы и надежность европейских дата-центров обычно подтверждают сразу несколько сертификатов: ISO/IEC 27001:2005, ISAE3402 / SSAE16, ISO 9001: 2008, ISO/IEC 27001:2005 и другие.
На что еще необходимо обратить внимание в договоре и SLA:
- какие услуги администрирования можно запросить у провайдера;
- на каких условиях оказывается поддержка аппаратного обеспечения, администрирование виртуальных машин, ОС и отдельных приложений;
- какие уровни обслуживания действуют для конкретных продуктов и от чего они зависят (варианты: от локации дата-центра, типа дисков и виртуальных машин);
- на какие случаи не распространяется гарантия поставщика услуг;
- процедура выплаты компенсации и ее размеры в случае нарушения SLA.
Работа БД на новой платформе
При миграции данных в Public Cloud приложения могут использовать серверы базы данных, также развернутые в облаке. Тогда провайдер должен предоставить возможность репликации или переноса хранилища того типа, который необходим для работы сервера баз данных.
Долгосрочные затраты
В большинстве случаев развертывание приложений в публичном облаке позволяет бизнесу оптимизировать затраты на IT-инфраструктуру. Это возможно за счет перехода от модели фактического владения IT-инфраструктуры (капитальные затраты, CapEx) к оплате необходимых ресурсов по подписке (операционные затраты, OpEx). Однако для приложений, которые должны быть доступны постоянно и требуют больших объемов вычислительных ресурсов, долгосрочная стоимость владения в публичном облаке может оказаться выше, чем стоимость развертывания и дальнейшей поддержки частного облака.
Управление безопасностью и надежностью хранения
При развертывании IT-инфраструктуры в Public Cloud виртуальные машины, находящиеся в аренде у разных клиентов, могут размещаться на единой физической инфраструктуре. Это обязывает вас тщательно подходить к оценке того, насколько ответственно провайдер решает задачу полной изоляции виртуальных машин друг от друга. Для этого важно, чтобы поставщик услуг работал открыто и, соответственно, разрешал проводить аудит политик безопасности на соответствие требованиям, а также выкладывал результаты аудита в общий доступ.
Некоторые провайдеры предлагают дополнительные услуги для повышения надежности и отказоустойчивости клиентской IT-инфраструктуры. Примерами таких услуг могут быть BaaS и DRaaS.
BaaS («бэкап как сервис») позволяет комплексно управлять созданием, хранением и восстановлением данных из резервных копий. Провайдер предоставляет подходящее по объему хранилище на базе своего дата-центра, а также специализированное ПО, которое позволяет в значительной степени автоматизировать работу с бэкапами и дополнительно обезопасить данные от случайного или преднамеренного удаления. Это может произойти в результате поломки или изъятия оборудования, кибератак, пожаров и других стихийных бедствий на площадке клиента, а также человеческого фактора.
DRaaS («аварийное восстановление как сервис») позволяет в сжатые сроки и максимально эффективно восстанавливать IT-инфраструктуру после серьезного сбоя из копии, которая хранится в облачном репозитории на стороне провайдера. Вы получаете ПО для синхронизации данных, а также помощь в подготовке и реализации плана аварийного восстановления.
Принцип работы сервиса BaaS:
Масштабируемость
Комфортнее всего в облаке бизнес-сервисам, поддерживающим горизонтальное масштабирование. Динамическое выделение вычислительных ресурсов идеально подходит для многоуровневых приложений с функцией балансировки нагрузки. Вам необходимо ознакомиться с положениями провайдера, в которых он описывает порядок такого масштабирования и предотвращения конфликтных ситуаций при превышении допустимого лимита ресурсов.
Публичное или частное облако?
После оценки потребности в ресурсах, совместимости платформ, возможности масштабирования и других аспектов миграции в публичное облако может возникнуть вопрос о целесообразности использования более сложного решения корпоративного уровня — частного облака. Оно позволяет задействовать больше инструментов безопасности, соответствовать специфическим требованиям к аппаратной платформе и в ряде случаев оказывается более экономически выгодным в долгосрочной перспективе.
Выбирая между публичным и частным облаком, следует детально изучить требования к защите данных, физической архитектуре, объемы трафика и все то, что также может влиять на производительность и работоспособность бизнес-приложений.
Возможности кастомизации
Под индивидуальные требования клиента и его бизнес-приложений можно построить только частное облако. В публичном вы получаете пул необходимых ресурсов с конкретными характеристиками, которые нельзя кастомизировать под конкретные задачи. В частном облаке, наоборот, можно выбрать желаемое количество процессоров с определенными параметрами (частота, поколение, производитель), объем и другие характеристики оперативной памяти, размеры хранилища и получить остальные компоненты свои задачи — например, конкретные модели видеокарт.
Объемы потребляемых ресурсов
В большинстве случаев нерационально переносить в публичное облако нагрузки, которые генерируют интенсивный сетевой трафик из-за возможного влияния на них «соседей». Аналогичная ситуация с другими вычислительными ресурсами — процессорной мощностью и дисковыми накопителями. Таким образом, высоконагруженные, требовательные к качеству сервиса виртуальные машины рекомендуется размещать в частном облаке.
Управление данными
Отдельные бизнес-приложения регулярно обмениваются данными с локальным хранилищем на стороне клиента или со сторонними ресурсами. При оценке возможности миграции все подобные взаимосвязи должны быть проанализированы и сохранены либо же архитектура приложения должна быть перестроена с учетом новых требований облачной IT-инфраструктуры.
Интеграция с устаревшими приложениями
Некоторые современные бизнес-приложения до сих пор работают с устаревшим ПО, что может вызвать проблемы в процессе миграции в облако. Если эти зависимости нельзя адаптировать для работы в облачной IT-инфраструктуре, стоит рассмотреть возможность миграции таких приложений в Private Cloud.
Масштабирование
Публичное облако масштабируется практически мгновенно — с момента отправки запроса до фактического выделения дополнительных ресурсов может пройти меньше часа. Частное облако в этом отношении менее гибкое: на заказ, поставку и введение в эксплуатацию дополнительных аппаратных ресурсов может потребоваться 2-3 недели. Но можно сработать на опережение: спланировать масштабирование и заблаговременно запросить дополнительные ресурсы у провайдера.
Стоимость владения
В модели IaaS до определенной конфигурации размеры регулярных платежей при сопоставимых объемах ресурсов будут ниже, чем у Private Cloud. С небольшим количеством используемых ресурсов у последнего будет выше совокупная стоимость владения за счет появления инсталляционного платежа. Если IT-инфраструктура достигла таких размеров, что ее целесообразно выносить в частное облако, размер ежемесячного платежа в большинстве случаев будет ниже, чем при оплате аналогичного объема ресурсов в публичном облаке.
Соответствие специфическим требованиям
В IaaS вы можете устанавливать ОС и приложения, в то время как в Private Cloud у вас будет прямой доступ к аппаратной части IT-инфраструктуры и гипервизору. Это важно, если вы планируете получить больше инструментов для контроля и управления, а также самостоятельно заниматься администрированием, чтобы оптимизировать инфраструктуру под конкретные бизнес-задачи.
Критерии оценки приложений
После выбора облачной модели и сервисов необходимо убедиться в отсутствии технических ограничений на миграцию и начать подготовку к переносу бизнес-приложений.
Архитектура
От архитектуры напрямую зависит то, подходит ли приложение для переноса в облако и каким образом будет осуществляться миграция. Разбираем, как разные типы архитектуры влияют на миграцию приложений в облако.
Приложения с многоуровневой архитектурой
Многие бизнес-приложения создаются с использованием нескольких уровней, что позволяет отделить основные модули от дополнительных функций. Так выглядит архитектура в трехуровневом приложении:
- уровень управления данными, который включает реляционные и другие компоненты баз данных;
- уровень бизнес-логики, который использует платформу приложений или контейнеры (Java EE/Microsoft.NET);
- уровень представления, отвечающий за взаимодействие с пользовательскими интерфейсами или другими внешними системами.
Приложения с многоуровневой архитектурой можно переносить целиком или помодульно внутри каждого уровня. В любом случае, каждый из них, как и компоненты внутри уровней, необходимо оценивать отдельно, когда речь идет о переносе в облако. Также разные уровни приложений могут выдвигать различные требования к безопасности.
Вертикально- и горизонтально-масштабируемые приложения
Вертикально-масштабируемую (scaling up) архитектуру имеют приложения, которые могут извлекать пользу из выделения дополнительных ресурсов (преимущественно процессорной мощности и памяти) на одном сервере или узле.
Горизонтально-масштабируемую (scaling out) архитектуру имеют приложения, которые могут извлекать пользу при увеличении количества серверов или узлов. Соответственно, когда нагрузка увеличится, то нужно развернуть дополнительные узлы, а когда потребность в ресурсах снизится, неиспользованные серверы/узлы можно будет отключить. Такие приложения появились позже вертикально-масштабируемых, а период их активного распространения связан с массовым переходом на архитектуру х86.
Географическая доступность
География пользователей бизнес-сервисов бывает довольно широкой или, наоборот, к приложению могут обращаться только из одного региона. Это также необходимо учесть до миграции в облако. Чтобы быть ближе к своим пользователям, крупный бизнес может разместить приложения в нескольких дата-центрах, расположенных в регионах с наибольшей интенсивностью запросов. Возможен и другой вариант, когда отдельные приложения нужно будет целенаправленно сделать недоступными в некоторых локациях по соображениям безопасности или другим причинам. Таким образом, при выборе облака важно убедиться, что вы можете контролировать, оптимизировать и отслеживать их локацию и удаленность от конечных пользователей.
Профилирование приложений
Процедура профилирования позволяет получить реальную статистику об использовании приложения до миграции и оценить реальные масштабы развертывания. Данные необходимо собирать в течение 10-15 дней подряд, чтобы зафиксировать все ежедневные и еженедельные отклонения от обычной нагрузки.
Вам предстоит собрать данные об использовании мощности процессора, памяти, хранилища, пропускной способности, количестве запросов и пользователей сервиса. На уровне узла эти данные можно использовать для анализа количества и конфигурации виртуальных машин, которые понадобятся в облаке.
Дополнительно к сбору статистику важно выполнить профилирование действий пользователей: оценить количество одновременно подключенных клиентов, скорость выполнения запросов и транзакций, длительность задержек. Эта информация пригодится для тестирования работы приложения в облаке и выбора оптимальной конфигурации облачных ресурсов на основе результатов теста, а также прогнозирования затрат на облачную IT-инфраструктуру.
Планирование миграции
Последним этапом будет разработка рабочего плана и непосредственно сама миграция данных в облако. Сложность его реализации напрямую зависит от типа приложений и требований к непрерывности их выполнения. Если даже минимальное время простоя критично для бизнеса, желательно разбить процесс миграции на несколько этапов — так, чтобы на любом из них приложения оставались доступными. Перенос в облако первой части сервисов будет тестовым. Используя заранее подготовленный план тестирования и автоматические тесты, можно смоделировать действия различных типов пользователей и нагрузок на приложение. По результатам станет понятно, сколько облачных ресурсов вам необходимо запросить у провайдера.
Почему важно доверить реализацию проекта профессионалам
Анализ, выбор оптимальной модели облака, разработка плана миграции и поэтапный перенос приложений в облако могут оказаться сложной задачи для компании, в которой IT не является профильным направлением. Тогда реализацию данного проекта следует доверить профессионалам, которые накопили большую экспертизу и опыт в задачах подобной вашей, а также понимают, как именно приложения взаимодействуют друг с другом, внешними ресурсами и базовой IT-инфраструктурой.
С 2010 года команда сертифицированных специалистов Colobridge накопила большой практический опыт в вопросах миграции в облако и не останавливается на достигнутом: сотрудники регулярно повышают компетенции и актуализируют знания. Они выполнят комплекс работ по переносу IT-инфраструктуры и данных в публичное или частное облако, а также обеспечат круглосуточную поддержку на нескольких языках, включая украинский и русский.
Резюме
При выборе облачной модели, оценке приложений и планировании их переноса в облако необходимо учитывать множество факторов. В первую очередь проанализируйте сами приложения и их совместимость с различными типами облачных моделей. После этого составьте планы миграции и тестирования на каждом этапе переноса данных. Хотя универсального подхода к миграции в облако не существует, подготовленная командой наших экспертов информация поможет сделать этот процесс максимально мягким и безболезненным для вашего бизнеса, свести к минимуму риски простоя приложений и на выходе получить ожидаемые результаты. Платформа Colobridge идеально подходит для размещения любых IT-приложений и предлагает больше, чем альтернативные площадки, в том числе позволяя реализовать передовые отраслевые решения от двух независимых географически удаленных дата-центров класса Tier III+ из рук единого провайдера.
