Онбординг по миграции#

Вы можете перенести инфраструктуру из собственного ЦОД или из облака другого провайдера в К2 Облако. Ниже рассказывается, с чего начать миграцию и как мигрировать наиболее востребованные сервисы.

Note

В документации К2 Облака виртуальные машины называются экземплярами.

Перед миграцией#

Important

Из-за высокой нагрузки на инфраструктуру облака свободные ресурсы для запуска того или иного облачного сервиса могут отсутствовать в выбранной зоне доступности (ЦОД). Вы можете попробовать запустить сервис в другой зоне доступности, либо обратиться в службу поддержки через портал или по адресу support@k2.cloud.

  1. Если у вашей компании ещё нет учётной записи, оставьте запрос на регистрацию с кодовым словом CloudBro. После того как компанию зарегистрируют, на корпоративную почту придёт уведомление с паролем административной учётной записи и логином вида admin@<customer>.

  2. Войдите в веб-интерфейс. При первом входе смените пароль.

  3. Вместе с административной учётной записью создаётся проект default. Вы можете развернуть инфраструктуру в нём или создать собственный проект.

  4. Административную учётную запись используйте для управления пользователями и проектами в разделе IAM. Для миграции и повседневной работы создайте отдельных пользователей и назначьте им необходимые проектные привилегии. Для полного доступа к ресурсам проекта подходит группа CloudAdministrators.

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

  6. Настройте сетевую связность между текущей площадкой и К2 Облаком и перенесите ресурсы по инструкциям ниже.

  7. После переноса настройте DNS, резервное копирование и балансировку нагрузки.

Как выбрать регион#

В К2 Облаке два региона:

Регион

Где находится

На что обратить внимание

ru-msk

Москва

Три зоны доступности. Узлы кластера или отдельные экземпляры можно распределить по разным дата-центрам

ru-spb

Санкт-Петербург

Одна зона доступности. Для тестовых сред и в качестве дополнительного хранилища данных, если основные ресурсы развёрнуты в ru-msk

Регион необходимо выбрать до создания ресурсов. Для уже созданного ресурса его нельзя изменить. Образы и снимки дисков можно копировать между регионами.

Перед миграцией проверьте в выбранном регионе:

  • нужные типы экземпляров и дисков;

  • предоставляемые квоты.

Сервис DNSaaS глобальный: созданная в нём зона DNS обслуживает все регионы.

Как обеспечить сетевую связность#

Для подключения к облаку вы можете использовать:

  • Elastic IP-адрес (если допустимо) — публичный IP-адрес, с помощью которого можно, например, перенести данные по SSH/rsync (для переноса данных можно также использовать объектное хранилище).

  • VPN-соединение — отказоустойчивый шифруемый канал между удалённой инфраструктурой и VPC. Позволяет начать миграцию, не ожидая подключения физического канала.

  • Выделенное соединение (Direct Connect) — прямой канал с малыми задержками и гарантированной пропускной способностью. Обеспечивает связность на уровне L3 с использованием протокола BGP. Оборудование можно разместить в облачном ЦОД или арендовать внешний канал связи до точек присутствия К2 Облака. Для подключения к оборудованию облака доступны порты 1, 10 и 25 Гбит/с.

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

Для выхода экземпляров в интернет присоедините интернет-шлюз. Если вам нужно предоставлять доступ экземплярам без собственного публичного адреса, используйте NAT-шлюз. Для прямого доступа к экземпляров из интернета публикуйте их через Elastic IP-адрес или балансировщик нагрузки.

Доступ к экземплярам можно ограничить с помощью групп безопасности и сетевых списков контроля доступа. На время миграции откройте только те порты и адреса, которые нужны для репликации и администрирования: SSH (22/tcp) для Linux, RDP (3389/tcp) для Windows, порты СУБД и объектного хранилища. Когда всё будет готово к запуску, откройте доступ к вашим сервисам из необходимых сетей.

Процесс миграции#

Миграция виртуальных машин#

Note

Перед миграцией и запуском виртуальных машин рекомендуем ознакомиться с разделом Экземпляры.

В К2 Облаке используется гипервизор QEMU-KVM. Виртуальную машину можно перенести как образ в формате OVA или как снимки дисков в форматах VMDK, VHD, QCOW2 и RAW. Так можно мигрировать виртуальные машины из VMware, Hyper-V, KVM и других сред, если они выгружают диск в одном из этих форматов.

  1. Остановите исходную виртуальную машину и выгрузите образ OVA или снимки дисков.

  2. Проверьте, что в гостевой системе установлены драйверы VirtIO для сети и дисков. Без них экземпляр запустится, но работа с дисками и сетью будет заметно медленнее. Если драйверов нет, при импорте включите опцию Включить поддержку устаревших ОС. Для Windows драйверы VirtIO нужно установить до переноса.

  3. Загрузите файлы в бакет объектного хранилища (см. инструкцию ниже).

  4. На странице бакета выберите нужные объекты и нажмите Создать образ. Загрузочный диск должен быть первым в списке. Ход импорта виден в разделе Виртуальные машины → Хранение данных → Импорт/Экспорт.

  5. Из готового образа создайте экземпляр. Готовый образ появляется в разделе Виртуальные машины → Хранение данных → Образы.

  6. Назначьте Elastic IP, если необходимо, и разрешите доступ в группе безопасности.

  7. Проверьте загрузку системы, сеть и данные. После проверки включите резервное копирование.

Подробные шаги — в инструкции Миграция виртуальных машин в К2 Облако и в разделе документации Импорт/Экспорт.

Миграция данных в объектное хранилище#

Note

Объектное хранилище можно также использовать как промежуточное звено при импорте образов виртуальных машин и как хранилище резервных копий.

В данной инструкции описывается, как перенести в облако большие объёмы данных.

Сервис Объектное хранилище совместим с Amazon S3 API. Перед переносом создайте бакет и ключи доступа. Конечная точка региона ru-msk — https://s3.ru-msk.k2.cloud, ru-spb — https://s3.ru-spb.k2.cloud.

Для переноса большого числа объектов используйте утилиту rclone. Её следует запускать на экземплярах в разных зонах доступности. Для работы с бакетом также можно использовать AWS CLI и утилиту s3cmd.

Подготовка к миграции#

  1. Создайте целевой бакет. При необходимости включите версионирование (после включения его нельзя выключить).

  2. Если в бакет без версионирования планируется записать свыше 30 млн объектов или в бакет с версионированием — свыше 10 млн, после создания бакета сообщите в службу поддержки его имя, целевое количество объектов и включено ли версионирование. Подготовка такого бакета занимает пару минут.

  3. Убедитесь, что исходные файлы статичны (не изменяются во время копирования).

Копирование данных#

Запустите rclone на экземплярах в разных зонах доступности. Для начала достаточно двух-трёх экземпляров. Число экземпляров можно увеличить, чтобы ускорить перенос.

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

Для небольших объектов выполните:

rclone copy <источник> <бакет> \
  --checkers 64 \
  --transfers 32 \
  --size-only \
  --s3-no-check-bucket \
  --s3-storage-class STANDARD \
  --s3-use-accept-encoding-gzip=false \
  --no-gzip-encoding \
  --header-download "Accept-Encoding: identity"

где <источник> — бакет, откуда копируются объекты, <бакет> — бакет в К2 Облаке.

Для больших объектов:

rclone copy <источник> <бакет> \
 --checkers 32 \
 --transfers 32 \
 --s3-no-check-bucket \
 --size-only \
 --ignore-checksum \
 --s3-upload-cutoff 200M \
 --s3-chunk-size 64M \
 --s3-upload-concurrency 8 \
 --multi-thread-streams 8 \
 --s3-storage-class STANDARD \
 --s3-use-accept-encoding-gzip=false \
 --no-gzip-encoding \
 --header-download "Accept-Encoding: identity"

где <источник> — бакет, откуда копируются объекты, <бакет> — бакет в К2 Облаке.

Important

При работе с облачным хранилищем Yandex Cloud данные параметры обязательны:

--s3-storage-class STANDARD
--s3-use-accept-encoding-gzip=false \
--no-gzip-encoding \
--header-download "Accept-Encoding: identity"

При ошибке TLS-соединения обновите rclone до более новой версии.

Миграция кластеров Kubernetes#

Перед миграцией ознакомьтесь с документацией для сервиса Кластеры Kubernetes. В К2 Облаке кластеры Kubernetes развёртываются с помощью Elastic Kubernetes Service: мастер-узлы и Ingress-контроллеры входят в кластер, группы рабочих узлов создаются отдельно.

Для работы с сервисом необходимы проектные привилегии EKSFullAccess. Если вам нужен EBS-провайдер, ELB-провайдер и/или провайдер Cluster Autoscaler, то потребуется создать сервисного пользователя для работы с каждым из них, либо одного пользователя с политикой EKSClusterPolicy для работы со всеми (см. подробнее).

Общий порядок действий:

  1. Создайте кластер EKS и группы рабочих узлов в нужных зонах доступности.

  2. Перенесите манифесты и образы контейнеров.

  3. Перенесите данные томов. Общие файлы можно разместить в файловой системе EFS и смонтировать по NFS.

  4. Переключите входящий трафик на балансировщик нагрузки кластера и проверьте рабочие нагрузки.

Миграция баз данных и других сервисов PaaS#

Информацию о поддерживаемых в К2 Облаке платформенных сервисах можно посмотреть в документации на сервисы PaaS. Развернуть необходимые сервисы можно в веб-интерфейсе в разделе PaaS Витрина сервисов, где все поддерживаемые сервисы представлены на одной странице. Для запуска сервисов можно также воспользоваться PaaS API. Подготовка экземпляров, дисков и установка ПО выполняются автоматически.

Для работы с сервисами нужна проектная привилегия PaaSFullAccess. Для сервиса баз данных можно включить резервное копирование. В этом случае пользователю потребуется назначить политику PaaSBackupPolicy.

Список поддерживаемых сервисов со ссылками на инструкции по их запуску:

Миграция DNS#

Сервис DNSaaS позволяет управлять публичными и частными зонами и ресурсными записями.

Общий порядок действий:

  1. Создайте публичную зону для домена.

  2. Перенесите ресурсные записи. На время переключения понизьте TTL.

  3. Делегируйте зону К2 Облаку: у регистратора укажите все четыре авторитативных сервера имён из NS-записи, которая создаётся вместе с зоной.

  4. Частные имена внутри VPC заведите в частной зоне.

  5. Переключите DNS после того, как новые экземпляры, балансировщики и бакеты ответят при проверках.

После миграции#

Для защиты от потери данных включите резервное копирование. Помимо резервного копирования экземпляров и дисков, K2 Cloud также предлагает опцию резервного копирования баз данных и сервис резервного копирования с помощью агентов.

  • Сервис Резервное копирование позволяет создавать резервные копии экземпляров и дисков по расписанию. Копии размещаются на выделенной системе хранения отдельно от дисков. В регионе с несколькими зонами доступности копии ресурсов из одной зоны размещаются в другой.

  • Решения на базе агентов обеспечивают более гибкую защиту данных. Резервные копии хранятся в объектном хранилище в трёх дата-центрах (в регионе ru-msk). По запросу можно настроить их хранение в любом S3-совместимом хранилище. Для подключения агентских решений оставьте заявку на портале поддержки или напишите на support@k2.cloud.

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

  • Для баз данных MySQL, MongoDB и PostgreSQL можно включить резервное копирование по расписанию. Тогда ежедневно в указанное время будут создаваться полные резервные копии указанных баз данных. Резервные копии записываются в объектное хранилище.