Миграция VPS на новую версию – часто «головная боль» админов, но вариант «не переходить на новую версию» – может быть чреват проблемами в будущем. Поэтому мы продолжаем публиковать полезные обзоры для всех желающих перевести свои виртуальные машины с 5.5 на 6 версию vSphere.
В первый части мы говорили о подготовке к миграции для домена vSphere Single Sign-On и для разных моделей развёртывания vCenter. Сейчас обратим внимание еще на двух «звезд нашего шоу» — Windows vCenter Server и, конечно, Windows vCenter Database.
Когда речь идет о Windows vCenter Server сразу возникает масса моментов, касающихся сети, учетных записей, агентов, разных установленных приложений и о многом другом. Как и Windows vCenter Server, ваши данные можно предварительно оценить (еще до процесса миграции), как может пройти процесс миграции, который зависит от модели развертывания (внутренняя/внешняя), и конечно, миграция зависит от размера ваших данных. Этот пост посвящен vCenter Server Windows, базе данных и сети.
Сеть является одной из самых критичных частей миграции vCenter Server. До начала миграции удостоверьтесь что Windows vCenter Server имеет правильную конфигурацию DNS и на месте зоны прямого и обратного просмотра. Идеально, когда vCenter Server сконфигурирован как статичный DNS, но если есть необходимость в поддержке DHCP, vSphere 6.0 Update 2m поддерживает это с небольшой оговоркой.
Во-первых, убедитесь, что ваш Windows vCenter Server не использует тот же IP что и ваш хост. В этом случае вы не сможете мигрировать, потому что эта конфигурация не поддерживается при миграции через помощник, и будет заблокирована еще при подготовке к миграции.
Во-вторых, если ваш Windows vCenter Server использует FQDN с DHCP адресом, убедитесь, что все зарезервировано, в противном случае помощник миграции тоже это заблокирует. Также проверьте, что протокол Network Time Protocol (NTP) задействован и корректно синхронизирован с Windows vCenter Server.
Когда мы говорим о сетевой конфигурации при использовании vCenter Server нужно уделить внимание пользовательским портам. Какие бы изменения не были сделаны, по умолчанию, в портах vCenter Server в процессе установки, они не пройдут подтверждение в ассистенте миграции.
Только настроенные порты, которые поддерживаются в ESXi Dump Collector и Auto Deploy будут поддерживаться в веб-клиенте vSphere. Миграция происходит через порт 9123. Если порт уже используется, будет использоваться следующий свободный порт, либо вы можете указать порт. В конце концов без условия описанного ниже, процесс миграции не будет успешен. Необходимо развернуть временный IP адрес в новом vCenter Server Appliance 6.0 в то время, когда Windows vCenter Server 5.5 еще доступен.
Когда данные Windows vCenter Server будут собраны, сервер выключится и в силу особенности vCenter Server, который включает оригинальный IP Address — он тоже мигрирует. Временный IP адрес должен быть в составе марштрутизируемой сети, которая доступна для нашего Windows vCenter Server
Windows vCenter Server – самый главный пункт во время процесса миграции. Сейчас самое время провести короткий обзор, что уже входит в Windows vCenter Server. Могут быть другие приложения, части приложений, агентов, скриптов и т.д. VMware или же сторонних производителей. Смотрите не только на то, что установлено на vCenter Server, еще обратите внимание на то, что использует ваш виртуальный сервер как конечное приложение. Если мы храним наш Windows vCenter Server и все связанные приложения во время процесса миграции, после миграции мы получим ту же виртуальную машину что и до миграции. Есть такие приложения, которые могут потребовать обновления плагина или же в случае с бекапами могут нуждаться в каких-то других изменениях (о них ниже).
В vCenter vSphere 6.0 и в Appliance Server и в Windows поддерживаются бекапы только на уровне образов. Удастся мигрировать или нет — будет зависеть от того, подключен ли vCenter Server к домену Active Directory, или же рабочей группе или нет. Если Windows vCenter Server подключен к домену Active Directory, тогда пользователи с учетными данными должны обновить свои аккаунты на сервере vCenter. В этой базе знаний рассказывается о том, какими правами должны обладать пользователи в Active Directory чтобы обновить vCenter Server. Также нужно помнить, с тех пор как мы перешли с Windows на Linux, это значит, что локальные пользователи Windows и группы не мигрируют. Это очень важно, если вы используете учетные записи или группы для прав доступа в vCenter Server.
Одну вещь нужно особо отметить: нужно иметь доступ к локальному аккаунту в Windows vCenter Server, чтобы в случае необходимости откатится назад в процессе миграции (мы подробнее обсудим аспект отката в миграции в следующем обзоре).
Подытожив наш рассказ о том, что НЕ будет перенесено в процессе миграции на новую версию, нужно сказать о том, что также НЕ будет перенесено: любые установленные агенты, антивирусы, программы для мониторинга, бекапов и т.п. vCenter Server Appliance — также ничего такого не поддерживает. Если vCenter Server запущен из под сервисной учетной записи и учетной записи, из под которой проходит миграция (запущен помощник миграции), тогда нужно разрешение на функцию “Replace a process level token” из под учетной записи с правами безопасности Windows. Эти права нужны для того, чтобы помощник миграции разрешил пройти имитирующий маркер доступа.
Давайте посмотрим на те решения, которые уже установлены в Windows vCenter Server. Эти приложения, авторства VMware или сторонних вендоров, не будут доступны до тех пор, пока Windows vCenter Server будет выключен. В VMware Update Manager (VUM) уже включены общие приложения для пользователей, которые могут его установить в vCenter Server. Ассистент миграции отметит эти установленные приложения и просигнализирует, но продолжит процесс миграции, если, конечно, вы захотите его продолжить. Если эти установленные приложения вам нужны и после миграции, настоятельно рекомендуем устанавливать их на отдельный сервер до начала процесса миграции.
Эти инструкции по миграции подробнее расскажут об установке VUM на внешний сервер.
Еще одна вещь, о которой нужно сказать, особенно в отношении VUM, эти плагины приложений нужны для каждой отдельной установки для каждого пользователя. Удостоверьтесь что пользователь, который запустил процесс миграции установил уже все нужные для приложений плагины, иначе помощник миграции выдаст ошибку. Например, если вы запустили процесс миграции их под аккаунта пользователя, у которого не установлены VUM плагины — вы получите ошибку.
Как уже упоминалось в первой части, мы не только мигрируем, но и обновляемся. Вот несколько пунктов, на которые стоит обратить внимание.
База данных vCenter Server – это «второе крыло» Windows vCenter Server. Инструмент миграции поддерживает все виды данных vSphere 5.5, от Microsoft SQL (локальные или удаленные) до Oracle. Локально установленная база не будет доступна и после миграции пока будет выключен Windows vCenter Server. vCenter Server 6.0 Update 2m предоставляет возможность перенести историю событий и конфигурации. Только учтите, что это увеличит время вашей миграции. Чтобы лучше оценить сколько времени займет миграция (с конфигурациями, аналитикой, историей событий или, в варианте без них) используйте специальный скрипт. В зависимости от размера данных vCenter, есть также опции, которые помогают уменьшить время миграции, но мы рекомендуем вначале запустить скрипт оценки миграции чтобы увидеть что может получиться. Одна вещь ускорит ваши данные в vCenter Server – это встроенные инструменты статистики. Но они не будут работать после 2 уровня статистики, до тех пор, пока не будет исправлена ошибка. Здесь объясняется как использовать каждый уровень статистики, и когда и как они могут использоваться.
Если ваши данные в vCenter Server – это удаленная база SQL или Oracle, неплохо было бы проверить работает ли у вас функция отката, и запущена ли она в настройках по умолчанию. Мы всегда говорим об этом нашим клиентам, у которых большие базы данных в vCenter Server, и они не всегда знают — работает (запущена ли) у них эта очень нужная функция отката. После того, как эта функция запущена в vCenter Server, их БД значительно уменьшаются. Следующая опция, которая также поможет вам уменьшить и почистить вашу БД в vCenter Server, но ее лучше использовать очень опытным администраторам.
Если ваш vCenter Server уже давно не обновлялся или имеет большую базу данных, возможно вам нужно почистить ваши старые данные. До того как это сделать, обязательно удостоверьтесь, что вы сделали бекапы всех данных. Эти советы могут показаться назойливыми, но я настаиваю, что все это лучше сделать еще до начала миграции и обновления.
Если вы хотите проверить готова или нет ваша БД для миграции, рекомендую запустить скрипт оценки времени миграции ваших данных, чтобы увидеть не только время, но и ошибки, которые могут возникнуть. Также скопируйте папку с помощником миграции в Windows vCenter Server и запустите его. Помощник может запустить предварительную подготовку миграции и позволит вам оценить соответствует ли ваш Windows vCenter Server всем требованиям для миграции или вам нужно ещё что-то исправить. Также у вас есть отображение ваших потенциальных изменений — окно процесса миграции.
В последнем посте из этой серии мы подробнее поговорим об этой функции отката и задачах уже после завершения миграции.
SIM-CLOUD — Отказоустойчивое облако в Германии
Выделенные серверы в надежных дата-центрах Германии!
Любая конфигурация, быстрая сборка и бесплатная установка
В первый части мы говорили о подготовке к миграции для домена vSphere Single Sign-On и для разных моделей развёртывания vCenter. Сейчас обратим внимание еще на двух «звезд нашего шоу» — Windows vCenter Server и, конечно, Windows vCenter Database.
Когда речь идет о Windows vCenter Server сразу возникает масса моментов, касающихся сети, учетных записей, агентов, разных установленных приложений и о многом другом. Как и Windows vCenter Server, ваши данные можно предварительно оценить (еще до процесса миграции), как может пройти процесс миграции, который зависит от модели развертывания (внутренняя/внешняя), и конечно, миграция зависит от размера ваших данных. Этот пост посвящен vCenter Server Windows, базе данных и сети.
Сеть
Сеть является одной из самых критичных частей миграции vCenter Server. До начала миграции удостоверьтесь что Windows vCenter Server имеет правильную конфигурацию DNS и на месте зоны прямого и обратного просмотра. Идеально, когда vCenter Server сконфигурирован как статичный DNS, но если есть необходимость в поддержке DHCP, vSphere 6.0 Update 2m поддерживает это с небольшой оговоркой.
Во-первых, убедитесь, что ваш Windows vCenter Server не использует тот же IP что и ваш хост. В этом случае вы не сможете мигрировать, потому что эта конфигурация не поддерживается при миграции через помощник, и будет заблокирована еще при подготовке к миграции.
Во-вторых, если ваш Windows vCenter Server использует FQDN с DHCP адресом, убедитесь, что все зарезервировано, в противном случае помощник миграции тоже это заблокирует. Также проверьте, что протокол Network Time Protocol (NTP) задействован и корректно синхронизирован с Windows vCenter Server.
Когда мы говорим о сетевой конфигурации при использовании vCenter Server нужно уделить внимание пользовательским портам. Какие бы изменения не были сделаны, по умолчанию, в портах vCenter Server в процессе установки, они не пройдут подтверждение в ассистенте миграции.
Только настроенные порты, которые поддерживаются в ESXi Dump Collector и Auto Deploy будут поддерживаться в веб-клиенте vSphere. Миграция происходит через порт 9123. Если порт уже используется, будет использоваться следующий свободный порт, либо вы можете указать порт. В конце концов без условия описанного ниже, процесс миграции не будет успешен. Необходимо развернуть временный IP адрес в новом vCenter Server Appliance 6.0 в то время, когда Windows vCenter Server 5.5 еще доступен.
Когда данные Windows vCenter Server будут собраны, сервер выключится и в силу особенности vCenter Server, который включает оригинальный IP Address — он тоже мигрирует. Временный IP адрес должен быть в составе марштрутизируемой сети, которая доступна для нашего Windows vCenter Server
Настройки Windows
Windows vCenter Server – самый главный пункт во время процесса миграции. Сейчас самое время провести короткий обзор, что уже входит в Windows vCenter Server. Могут быть другие приложения, части приложений, агентов, скриптов и т.д. VMware или же сторонних производителей. Смотрите не только на то, что установлено на vCenter Server, еще обратите внимание на то, что использует ваш виртуальный сервер как конечное приложение. Если мы храним наш Windows vCenter Server и все связанные приложения во время процесса миграции, после миграции мы получим ту же виртуальную машину что и до миграции. Есть такие приложения, которые могут потребовать обновления плагина или же в случае с бекапами могут нуждаться в каких-то других изменениях (о них ниже).
В vCenter vSphere 6.0 и в Appliance Server и в Windows поддерживаются бекапы только на уровне образов. Удастся мигрировать или нет — будет зависеть от того, подключен ли vCenter Server к домену Active Directory, или же рабочей группе или нет. Если Windows vCenter Server подключен к домену Active Directory, тогда пользователи с учетными данными должны обновить свои аккаунты на сервере vCenter. В этой базе знаний рассказывается о том, какими правами должны обладать пользователи в Active Directory чтобы обновить vCenter Server. Также нужно помнить, с тех пор как мы перешли с Windows на Linux, это значит, что локальные пользователи Windows и группы не мигрируют. Это очень важно, если вы используете учетные записи или группы для прав доступа в vCenter Server.
Одну вещь нужно особо отметить: нужно иметь доступ к локальному аккаунту в Windows vCenter Server, чтобы в случае необходимости откатится назад в процессе миграции (мы подробнее обсудим аспект отката в миграции в следующем обзоре).
Подытожив наш рассказ о том, что НЕ будет перенесено в процессе миграции на новую версию, нужно сказать о том, что также НЕ будет перенесено: любые установленные агенты, антивирусы, программы для мониторинга, бекапов и т.п. vCenter Server Appliance — также ничего такого не поддерживает. Если vCenter Server запущен из под сервисной учетной записи и учетной записи, из под которой проходит миграция (запущен помощник миграции), тогда нужно разрешение на функцию “Replace a process level token” из под учетной записи с правами безопасности Windows. Эти права нужны для того, чтобы помощник миграции разрешил пройти имитирующий маркер доступа.
Давайте посмотрим на те решения, которые уже установлены в Windows vCenter Server. Эти приложения, авторства VMware или сторонних вендоров, не будут доступны до тех пор, пока Windows vCenter Server будет выключен. В VMware Update Manager (VUM) уже включены общие приложения для пользователей, которые могут его установить в vCenter Server. Ассистент миграции отметит эти установленные приложения и просигнализирует, но продолжит процесс миграции, если, конечно, вы захотите его продолжить. Если эти установленные приложения вам нужны и после миграции, настоятельно рекомендуем устанавливать их на отдельный сервер до начала процесса миграции.
Эти инструкции по миграции подробнее расскажут об установке VUM на внешний сервер.
Еще одна вещь, о которой нужно сказать, особенно в отношении VUM, эти плагины приложений нужны для каждой отдельной установки для каждого пользователя. Удостоверьтесь что пользователь, который запустил процесс миграции установил уже все нужные для приложений плагины, иначе помощник миграции выдаст ошибку. Например, если вы запустили процесс миграции их под аккаунта пользователя, у которого не установлены VUM плагины — вы получите ошибку.
Как уже упоминалось в первой части, мы не только мигрируем, но и обновляемся. Вот несколько пунктов, на которые стоит обратить внимание.
- Если Linked Mode сконфигурирован, конфигурация будет удалена еще до старта миграции.
- В процессе миграции Windows vCenter Server и vCenter Server Appliance имеют равные части в конечной точке миграции.
- Все сертификаты vCenter Server также перенесутся.
- Любые скрипты, которые сохранены в Windows vCenter Server, должны быть перенесены в другое место до начала миграции.
- Когда миграция Windows vCenter Server закончена, рекомендуем отключиться от сетевого адаптера и удостоверится, в случае если vCenter по каким либо причина включится, чтобы не было конфликтов сети.
vCenter Server Database
База данных vCenter Server – это «второе крыло» Windows vCenter Server. Инструмент миграции поддерживает все виды данных vSphere 5.5, от Microsoft SQL (локальные или удаленные) до Oracle. Локально установленная база не будет доступна и после миграции пока будет выключен Windows vCenter Server. vCenter Server 6.0 Update 2m предоставляет возможность перенести историю событий и конфигурации. Только учтите, что это увеличит время вашей миграции. Чтобы лучше оценить сколько времени займет миграция (с конфигурациями, аналитикой, историей событий или, в варианте без них) используйте специальный скрипт. В зависимости от размера данных vCenter, есть также опции, которые помогают уменьшить время миграции, но мы рекомендуем вначале запустить скрипт оценки миграции чтобы увидеть что может получиться. Одна вещь ускорит ваши данные в vCenter Server – это встроенные инструменты статистики. Но они не будут работать после 2 уровня статистики, до тех пор, пока не будет исправлена ошибка. Здесь объясняется как использовать каждый уровень статистики, и когда и как они могут использоваться.
Если ваши данные в vCenter Server – это удаленная база SQL или Oracle, неплохо было бы проверить работает ли у вас функция отката, и запущена ли она в настройках по умолчанию. Мы всегда говорим об этом нашим клиентам, у которых большие базы данных в vCenter Server, и они не всегда знают — работает (запущена ли) у них эта очень нужная функция отката. После того, как эта функция запущена в vCenter Server, их БД значительно уменьшаются. Следующая опция, которая также поможет вам уменьшить и почистить вашу БД в vCenter Server, но ее лучше использовать очень опытным администраторам.
Если ваш vCenter Server уже давно не обновлялся или имеет большую базу данных, возможно вам нужно почистить ваши старые данные. До того как это сделать, обязательно удостоверьтесь, что вы сделали бекапы всех данных. Эти советы могут показаться назойливыми, но я настаиваю, что все это лучше сделать еще до начала миграции и обновления.
Если вы хотите проверить готова или нет ваша БД для миграции, рекомендую запустить скрипт оценки времени миграции ваших данных, чтобы увидеть не только время, но и ошибки, которые могут возникнуть. Также скопируйте папку с помощником миграции в Windows vCenter Server и запустите его. Помощник может запустить предварительную подготовку миграции и позволит вам оценить соответствует ли ваш Windows vCenter Server всем требованиям для миграции или вам нужно ещё что-то исправить. Также у вас есть отображение ваших потенциальных изменений — окно процесса миграции.
В последнем посте из этой серии мы подробнее поговорим об этой функции отката и задачах уже после завершения миграции.
SIM-CLOUD — Отказоустойчивое облако в Германии
Выделенные серверы в надежных дата-центрах Германии!
Любая конфигурация, быстрая сборка и бесплатная установка