Переход к любой новой технологии требует тщательного планирования и скоординированных усилий. Ниже описаны четыре способа перехода с унаследованной платформы, такой как Cloudera CDH или HDP, на CDP Public Cloud или CDP Private Cloud. Четыре метода - это In-place Upgrade, Side-car Migration, Rolling Side-car Migration и Migrate to Public Cloud.
У каждого механизма есть общие аспекты работы, методы снижения рисков и успешные результаты на всех этапах перехода с унаследованных дистрибутивов на CDP. К ним относятся анализ рабочей нагрузки, тестирование и проверка, управление соглашениями об уровне обслуживания (SLA) и минимизация времени недоступности рабочей нагрузки во время перехода.
Независимо от того, какой путь вы выберете, успешное обновление или миграция требует досконального планирования. Это утверждение особенно верно в больших средах с множеством рабочих нагрузок, большим числом клиентов и сложными зависимостями данных.
In-place Upgrade
In-Place Upgrade или «обновление на месте» - это процесс, при котором вы напрямую обновляете существующие унаследованные кластеры CDH или HDP до CDP. Этот процесс включает в себя запланированные простои и требует координации между всеми арендаторами. Координация необходима, потому что дает возможность подготовить всех к обновлению в один день.
В зависимости от унаследованной платформы, процесс обновления может сохранить некоторые из ваших существующих настроек и другие конфигурации различных сервисов и служб. При переходе на CDP Private Cloud Base Cloudera заменяет несколько устаревших компонентов. Там, где это возможно, процесс обновления предусматривает полезные инструменты и средства автоматизации. Они помогут в преобразовании устаревших компонентов в их эквиваленты в CDP. Например, пользователи CDH конвертируют свои политики Apache Sentry в Apache Ranger с помощью инструмента автоматического преобразования, а пользователи HDP переводят конфигурации Ambari в Cloudera Manager с помощью AM2CM. Однако пользователям Spark 1.6 на любой платформе все равно может потребоваться вручную обновить код для совместимости со Spark 2 и Spark 3.
Рисунок ниже описывает логические этапы и основные области работ по «обновлению на месте» в ходе перехода от оценки и выявления к обновлению сред разработки, тестирования и рабочей среды.
Преимущества
Можно использовать имеющееся оборудование с минимальным добавлением новых узлов (при необходимости).
Существующие настройки и конфигурации многих сервисов и служб останутся без изменений.
Не нужно никаких дополнительных сред или связанных с ними накладных расходов.
Недостатки
Обновление на месте требует простоя кластера. Предварительная подготовка некоторых видов работ сводит к минимуму время простоя в день обновления. В числе таких работ - обновление ОС или преобразование компонентов, например, кода Spark 1.6 в Spark 2.X.
Все арендаторы должны быть готовы к обновлению одновременно. Один клиент может задержать весь процесс, если у него возникнут проблемы, которые он должен сначала решить.
Когда используется
«Обновление на месте» лучше всего подходит для больших кластеров с более или менее значительными объемами данных. Требования SLA и времени простоя приложений также играют важную роль в принятии решения, поскольку такой процесс обновления требует запланированного простоя. Срок службы и цикл обновления оборудования унаследованных кластеров - еще один важный фактор при выборе стратегии «обновления на месте». Если узлы кластера не предполагают обновления оборудования в ближайшем будущем, «обновление на месте» может быть наиболее подходящим вариантом для перехода на CDP.
Cloudera недавно выполнила «обновление на месте» своего кластера для внутренних операций, выбрав этот способ по следующим причинам:
Желание использовать как можно более быстрый путь перехода на CDP.
Избежать больших капитальных затрат.
Наличие множества тесно взаимосвязанных рабочих нагрузок, которые усложнили бы переход по одному арендатору.
Миграция Side-car
Метод Side-Car Migration или «боковой миграции» - это второй путь перехода на CDP. На втором наборе оборудования настраивается «с нуля» новый кластер CDP Private Cloud Base. Этот процесс направлен на минимизацию времени простоя отдельных рабочих нагрузок и обеспечивает простой механизм отката для каждой рабочей нагрузки. Боковая миграция делится на три основных этапа.
Во-первых, создается и конфигурируется новый кластер CDP Private Cloud Base. Во-вторых, настраивается процесс репликации для периодического получения согласованных снимков данных, метаданных и соответствующих политик управления. В-третьих, нужно развернуть на новом кластере рабочие нагрузки, протестировать их и после проверки перевести в рабочий режим. После перемещения можно отключить их в унаследованном кластере. Это означает, что в течение периода миграции производственные рабочие нагрузки будут временно выполняться на нескольких кластерах.
Cloudera предоставляет инструменты для помощи в этом процессе, включая DistCP, Replication Manager (ранее он назывался BDR) для репликации данных и hms-mirror для схем Hive и миграции. Authzmigrator предоставляет способ преобразования политики Sentry-to-Ranger. FS2CS упрощает переключение с YARN FairScheduler на CapacityScheduler. Если преобразование не требуется, экспорт политик и конфигураций позволяет повторно использовать их напрямую, импортируя их в соответствующие компоненты на CDP.
Достоинства
Легче выполнять соглашения об уровне обслуживания для отдельных рабочих нагрузок, поскольку унаследованная версия и версия CDP могут работать параллельно, не влияя друг на друга.
Отдельных арендаторов можно переводить по одному. Нет необходимости координировать всех арендаторов.
Для отката требуется координация только на уровне рабочей нагрузки или клиента, а не на уровне всего кластера.
Позволяет перейти непосредственно на CDP с любой версии HDP2 / 3 или CDH5 / 6. Этот метод также распространяется на дистрибутивы, отличные от Cloudera.
Недостатки
Данный метод требует дублирующего набора оборудования для реализации кластера CDP «с нуля» наряду с унаследованной средой. Это может существенно повлиять на капитальные затраты и бюджет.
Дополнительные накладные расходы на обслуживание среды до тех пор, пока все арендаторы не перейдут в новую среду.
Когда используется
Этот механизм лучше всего использовать, когда есть жесткие требования по соглашениям об уровне обслуживания, которые исключают продолжительный многочасовой простой рабочих нагрузок. Кроме того, такой процесс обновления часто является отличным поводом для полного обновления систем, чтобы воспользоваться преимуществами более нового и функционального оборудования. Такие факторы, как возраст оборудования и цикл его обновления, необходимость в перемещении центра обработки данных, могут сыграть важную роль при принятии решения о данном подходе к миграции. Заказчики, совмещающие обновление оборудования и перемещение центра обработки данных, используют этот механизм для реализации жизненного цикла обновления, минимизации различных воздействий на свои бизнес-планы.
Миграция Rolling Side-car
Rolling Side-car Migration - это модификация «боковой» миграции (Side-car). При таком способе используется существующий унаследованный кластер: вы перепрофилируете его в новый кластер CDP, что очень похоже на процесс Side-Car Migration.
После запуска нового кластера выполняется миграция исходных данных, метаданных и рабочей нагрузки приложения или клиента.
Происходит тестирование и проверка рабочей нагрузки, после чего рабочая нагрузка используется на новом кластере и отключается на унаследованном. Рабочая нагрузка и ее данные удаляются из унаследованного кластера, освобождая емкость. Эта емкость из унаследованного кластера и переносится в новый кластер CDP.
Этот процесс повторяется несколько раз, пока все арендаторы, рабочие нагрузки и данные полностью не перейдут в среду CDP.
Преимущества
Повторное использование существующей резервной емкости или приобретение минимальной новой емкости, необходимой для создания небольшой начальной среды CDP Private Cloud Base «с нуля». Капитальные затраты сведены к минимуму по сравнению с предыдущим методом.
Легче выполнять соглашения об уровне обслуживания для отдельных рабочих нагрузок, поскольку унаследованная версия и версия CDP могут работать параллельно, не влияя друг на друга.
Отдельных арендаторов можно перемещать по одному. Нет необходимости в координации всех арендаторов.
Для отката требуется координация только на уровне рабочей нагрузки или клиента, а не на уровне всего кластера.
Позволяет перейти непосредственно на CDP с любой версии HDP2 / 3 или CDH5 / 6. Этот метод также распространяется на дистрибутивы, отличные от Cloudera.
Недостатки
Требуется достаточная свободная емкость. Это нецелесообразно для кластеров с более чем 70% использованием HDFS или постоянно задействующих более 90% вычислительных ресурсов.
Этот способ может временно повлиять на производительность существующих рабочих нагрузок в унаследованной среде из-за уменьшения емкости.
Он содержит больше шагов из-за вывода узлов из унаследованного кластера и их развертывания в среде CDP Private Cloud Base, что повлияет на общий график миграции.
Метод менее автоматизирован из-за процесса перемещения узла.
Требуется существенная координация и планирование для определения правильного порядка перемещения клиентов с учетом процесса перевода узлов и данных из одного кластера в другой.
Дополнительные накладные расходы на обслуживание среды до тех пор, пока все арендаторы не перейдут в новую среду.
Когда используется
Rolling Side-car Migration - хорошая альтернатива для клиента, у которого есть резервные мощности, но который не может мириться с длительным простоем при «обновлении на месте». Поскольку этот способ помогает свести к минимуму первоначальные капитальные затраты, экономные заказчики могут предпочесть именно его.
Migrate to Public Cloud - миграция в публичное облако
Миграция в публичное облако CDP с унаследованной платформы очень похожа на способ миграции Side-car с некоторыми незначительными изменениями. В методе Side-car вы создаете новую среду CDP вместе с унаследованной средой и реплицируете данные в новую HDFS. При миграции в облако данные реплицируются в облачное объектное хранилище, и вы связываете с этими сегментами ориентированные на вычисления кластеры CDP Datahub.
Такая архитектура позволяет независимо масштабировать вычислительные ресурсы и ресурсы хранения. Кроме того, перемещение клиентов в изолированные кластеры позволяет масштабировать их ресурсы и настраиваться на индивидуальные потребности, а не на максимальное использование в многоарендной среде.
Достоинства
Снижение затрат на дорогостоящие площади центра обработки данных.
Более быстрое и эффективное масштабирование отдельных рабочих нагрузок без длительных циклов покупки оборудования.
Позволяет выбирать во время миграции оптимальные размеры сред для конкретных рабочих нагрузок, чтобы минимизировать затраты и пиковое использование ресурсов, соблюдая при этом SLA, на которые часто влияют ограниченные монолитные кластеры с конкурирующими требованиями к рабочим нагрузкам.
Дает возможность реализовать экономичные стратегии аварийного восстановления, при необходимости увеличивая число дополнительных площадок.
Недостатки
Первоначальное перемещение данных в облако может занять значительное время, если нет достаточных выделенных сетевых ресурсов. Для справки, одно сетевое соединение на десять гигабит позволяет перемещать около 85 терабайт данных в день с использованием Replication Manager с достаточным распараллеливанием.
Когда используется
Миграция в облако - хороший вариант, когда ресурсы вашей локальной среды исчерпываются, и вы хотите перейти на более гибкую модель инфраструктуры. Этот способ также хорош, когда нужна большая адаптируемость и контроль процесса распределением ресурсов, которое часто замедляется из-за длительного бюджетирования и циклов покупки оборудования. В некоторых случаях можно использовать гибридный подход, при котором определенные клиенты и рабочие нагрузки переносятся в публичное облако для оптимизации затрат, в то время как другие рабочие нагрузки остаются локальными, а кластер по-прежнему проходит миграцию «на месте» или «боковую» миграцию. Публичное облако также идеально подходит для периодических рабочих нагрузок или тех, которые сильно нагружают ЦП.
Что выбрать?
Выбор правильного метода на первый взгляд может показаться сложным. Решение в конечном итоге зависит от требуемых соглашений об уровне обслуживания, уровня доступности, наличия оборудования или заинтересованности в переходе в облако. Приведенное ниже дерево решений укажет вам правильное направление. Дополнительная информация
Дополнительная информация
Чтобы спланировать обновление или миграцию на CDP Private Cloud Base, свяжитесь со специалистами Cloudera по работе с заказчиками, которые назначат время, чтобы вместе с вами изучить доступные варианты. Кроме того, вот несколько полезных ресурсов (на англ. языке):