none
Перенос ВМ из разных кластеров в один

    Вопрос

  • Добрый день!

    На текущий момент имеем три Windows кластера по два сервера в каждом. Внутри кластера 4, 6 и 1 ВМ

    Есть СХД, которая подключена ко всем серверам по iSCSi

    Соответственно сами ВМ хранятся на СХД.

    Закуплено новое оборудование, шасси и одна СХД.

    На шасси из 6 серверов будет создан один кластер, к шасси будет подключена полка по FC

    Все ВМ будут жить на новой полке и в новом одном кластере.

    Есть несколько вопросов по миграции ВМ.

    Самая первая ВМ, которая поедет на новое оборудование это ВМ с базами SQL, ей выделен пул в 3Тб, но по факт у ВМ машины размер 500Гб. Я хочу выполнить миграцию через Экспорт/Импорт

    Бэкапы баз делаются DPM

    - Выключаю ВМ

    - Делаю Экспорт

    -Копирую папку экспорта

    -На новом оборудовании делаю Импорт

    - запускаю ВМ

    При таких телодвижениях на какие риски я могу попасть? 

    Возможно есть более лучший способ миграции?

    Спасибо!


    4 апреля 2019 г. 13:59

Ответы

  • При данном варианте, так же копия будет создаваться ВМ? Или данные поедут со старой СХД на новую?

    Копии не будет — операции происходят с одной и той же виртуальной машиной.

    Вы конфигурацию виртуальных машин переключите на потребление ресурсов нового кластера, вместе с томами старого СХД. После чего Вам нужно будет переместить посредством LSM, уже без остановки виртуальных машин, диски и конфигурацию ВМ на новую СХД. 
    Плюсы такого метода в том, что: 1. За счёт использования кластера копирования ролей Вы переносите все виртуальные машины с одного кластера сразу, 2. За счёт использования механизмов LSM остановки сервисов уже нет.

    Если жёстких сроков по окну обслуживания нет, то тут любой метод выбирайте.

    5 апреля 2019 г. 8:45
    Модератор
  • Это мне понятно.

    Распишу по шагам.

    Захожу в управление серверами и ставлю флаг на компоненте Хайпер-В

    Идет пошаговая настройка Хайпер-В

    И вот в одном из шагов необходимо указать интерфейс, который будет смотреть в локальную сеть.

    В моем случае выбирать два физических адаптера Ethernet1 и Ethernet2? Или интерфейс, созданного тиминга?

    До виртуальных коммутаторов еще дело не дошло

    если 2 интерфейса собраны в тим то на них уже нет ip адресови единственным "рабочим" интерфейсом в таком случае остается ваш агрегированный интерфейс

    The opinion expressed by me is not an official position of Microsoft

    • Помечено в качестве ответа Pogreb 13 мая 2019 г. 10:10
    Модератор

Все ответы

  • Да в принципе ни на какие, тем более у вас останется ВМ на старом расположении в случае чего.
    4 апреля 2019 г. 14:51
  • Возможно есть более лучший способ миграции?


    Использование мастера Copy Cluster Roles с последующим Live Storage Migration между хранилищами:
    1. Подключение старых кластерных томов iSCSI к новому шестиузловому кластеру,
    2. Запуск и отработка на новом кластере мастера Copy Cluster Roles для копирования конфигураций выключенных виртуальных машин,
    3. Запуск виртуальных машин на ресурсах нового кластера, перемещение их посредством Live Storage Migration на новое хранилище,
    4. Отключение томов iSCSI от нового кластера, вывод из эксплуатации серверов и хранилищ старых кластеров.

    Время простоя виртуальных машин — время работы по п. 2.
    4 апреля 2019 г. 19:20
    Модератор
  • Да в принципе ни на какие, тем более у вас останется ВМ на старом расположении в случае чего.

    Вот меня вопрос интересует. При моем копировании останется старая ВМ на старой СХД, плюс при экспорте создается еще одна ВМ и копия всех баз так же создается на новой СХД? Текущая конфигурация ВМ никак не изменится, т.к. на новой СХД будет копия создаваться? 

    5 апреля 2019 г. 6:15
  • Возможно есть более лучший способ миграции?


    Использование мастера Copy Cluster Roles с последующим Live Storage Migration между хранилищами:
    1. Подключение старых кластерных томов iSCSI к новому шестиузловому кластеру,
    2. Запуск и отработка на новом кластере мастера Copy Cluster Roles для копирования конфигураций выключенных виртуальных машин,
    3. Запуск виртуальных машин на ресурсах нового кластера, перемещение их посредством Live Storage Migration на новое хранилище,
    4. Отключение томов iSCSI от нового кластера, вывод из эксплуатации серверов и хранилищ старых кластеров.

    Время простоя виртуальных машин — время работы по п. 2.
    При данном варианте, так же копия будет создаваться ВМ? Или данные поедут со старой СХД на новую?
    5 апреля 2019 г. 6:16
  • Если делать экспорт\импорт, то в случае удачного импорта конфигурация останется прежней. 

    Так же, для удачного импорта на новом кластере необходимы виртуальные коммутаторы hyper-v назвать так же как и на старом. 

    У вас версия гипервизора на старом и новом кластере останется одинаковой?

    5 апреля 2019 г. 8:12
  • При данном варианте, так же копия будет создаваться ВМ? Или данные поедут со старой СХД на новую?

    Копии не будет — операции происходят с одной и той же виртуальной машиной.

    Вы конфигурацию виртуальных машин переключите на потребление ресурсов нового кластера, вместе с томами старого СХД. После чего Вам нужно будет переместить посредством LSM, уже без остановки виртуальных машин, диски и конфигурацию ВМ на новую СХД. 
    Плюсы такого метода в том, что: 1. За счёт использования кластера копирования ролей Вы переносите все виртуальные машины с одного кластера сразу, 2. За счёт использования механизмов LSM остановки сервисов уже нет.

    Если жёстких сроков по окну обслуживания нет, то тут любой метод выбирайте.

    5 апреля 2019 г. 8:45
    Модератор
  • У вас версия гипервизора на старом и новом кластере останется одинаковой?

    Да
    5 апреля 2019 г. 13:47
  • Плюсы такого метода в том, что: 1. За счёт использования кластера копирования ролей Вы переносите все виртуальные машины с одного кластера сразу, 2. За счёт использования механизмов LSM остановки сервисов уже нет. 


    Если жёстких сроков по окну обслуживания нет, то тут любой метод выбирайте.

    Спасибо, по изучаю метод
    5 апреля 2019 г. 13:47
  • Коллеги, подскажите, пожалуйста по еще одному возникшему вопросу.

    Подскажи, пожалуйста, по тимингу. Новый кластер будет жить на шасси из 6 блэйдов. К шасси по FC подключена СХД. Шасси подключено к стэку cisco3850. Соответственно на каждом блэйде две сетевые карты,которые соединяются с ядром (3850). Я объединил эти карты в тиминг LACP. В тиминг я уже добавил 3 виртуальные сети с моими вланами, соответственно появились виртуальные сети.
    Теперь поднимаю роль Hyper-V и мне надо указать сетевые карты, которые смотрят в локалку. Мне указать два физических адаптера или мой собранный тиминг?
    Спасибо за ответ!

  • Для виртуального коммутатора Вам нужно указывать агрегированный интерфейс.
    Модератор
  • Только в моем случае это будет минимум три коммутатора. Они будут основаны на виртуальной сети из тиминга (их три), а при поднятии роди хайпер-в указывать нужно тиминг или физические адаптеры сервера?

    • Изменено Pogreb 13 мая 2019 г. 7:58
  • У Вас в каждом сервере два физических адаптера, Ethernet1 и Ethernet2, на их базе средствами нативного тиминга сделаете агрегированый интерфейс tEthernet. При создании виртуального коммутатора указываете tEthernet.
    Модератор
  • Это мне понятно.

    Распишу по шагам.

    Захожу в управление серверами и ставлю флаг на компоненте Хайпер-В

    Идет пошаговая настройка Хайпер-В

    И вот в одном из шагов необходимо указать интерфейс, который будет смотреть в локальную сеть.

    В моем случае выбирать два физических адаптера Ethernet1 и Ethernet2? Или интерфейс, созданного тиминга?

    До виртуальных коммутаторов еще дело не дошло

  • Выносите в отдельное обсуждение со скриншотами. Сдаётся мне, что Вы ошибаетесь с тем, что это выбор интерфейса для локальной сети.
    Модератор
  • Это мне понятно.

    Распишу по шагам.

    Захожу в управление серверами и ставлю флаг на компоненте Хайпер-В

    Идет пошаговая настройка Хайпер-В

    И вот в одном из шагов необходимо указать интерфейс, который будет смотреть в локальную сеть.

    В моем случае выбирать два физических адаптера Ethernet1 и Ethernet2? Или интерфейс, созданного тиминга?

    До виртуальных коммутаторов еще дело не дошло

    если 2 интерфейса собраны в тим то на них уже нет ip адресови единственным "рабочим" интерфейсом в таком случае остается ваш агрегированный интерфейс

    The opinion expressed by me is not an official position of Microsoft

    • Помечено в качестве ответа Pogreb 13 мая 2019 г. 10:10
    Модератор
  • Vector BCO, спасибо за ответ, значит, в моем случае, выбираю мой созданный тиминг

  • Картинка для полного понимая

    Denis Dyagilev ,прошу прощения, что ввел в заблуждение. Вы били правы по поводу коммутаторов