Для экземпляра связи требуется просмотр координаций

Для экземпляра связи требуется просмотр координаций. Instance of link needs Coordination Review

Несоответствие текущей модели Revit со смежным разделом (со связанным файлом) из-за изменений в модели (оси, уровни, координаты и т.д.).

Как работать со страницами ошибок

Прочитать рекомендации ниже
Попытаться их выполнить
Помогло → оставить отзыв
Не помогло → написать в чат поддержки

Для сохранения соответствия уровней, осей и координат между текущей моделью Revit и связанным файлом, проверьте связанную модель функцией «Просмотр координаций» со вкладки «Совместная работа» и исправьте все несоответствия.

Перейдите на один из видов в котором можно выделить связанный файл.
На вкладке «Совместная работа» выберите «Просмотр координаций», а затем — «Выбрать связь».

Настройка координации в Revit

3. Выберите экземпляр связи, для которого требуется просмотр координаций.4. В появившемся окне Просмотра координаций, можно увидеть все изменения и выбрать одно из предложенных действий для применения или отказа от изменений.

«Отложить» — не принимать изменения сейчас.

Выберите это действие, если сейчас не готовы принимать решение по изменению. Это значение откладывает принятие решения по изменению на более позднее время;

«Отказаться» — не принимать изменения вообще.

Выберите это действие, если считаете, что изменение связи и вашей модели под это изменение некорректно. А вместо вашей модели изменение должно быть внесено в соответствующий отслеживаемый элемент в связанной модели.

«Принять разницу» — принимать изменения.

Выберите это действие, если считаете, что изменение корректно. Но при этом выборе элементы не перемещаются, а обновляется взаимосвязь с учетом расстояния между элементами.

«Изменить» — принимать изменения линий сетки или осевых линий стен (перемещение или изменение).

Выберите это действие для изменения соответствующего элемента в вашей модели.

«Перенести» — принимать перемещение отслеживаемого элемента.

Выберите это действие для перемещения соответствующего элемента в вашей модели.

Autodesk Revit MEP: Продвинутый уровень Средний

Продвинутый курс по построению трубопроводных систем разделов ОВ и ВК в Revit на основе архитектурной модели. Рассматриваются основные настройки программы, моделирование систем, а также формирование документации и спецификаций.

Макс. длительность: 10 часов 57 минут

Мониторинг и координация

Отслеживание координации

Отслеживание местоположения объектов в исходном файле. Предупреждения мониторинга. Просмотр координации. Решение предупреждений мониторинга. Остановка мониторинга.

Отказоустойчивая кластеризация Windows Server с SQL Server

Отказоустойчивый кластер Windows Server (WSFC) представляет собой группу независимых серверов, совместная работа которых позволяет повысить доступность приложений и служб. SQL Server поддержка экземпляров отказоустойчивого кластера Группы доступности AlwaysOn и SQL Server осуществляется с использованием служб и возможностей WSFC.

Термины и определения

Отказоустойчивый кластер Windows Server (WSFC) — это группа независимых серверов, совместная работа которых позволяет повысить доступность приложений и служб.

Узел
Сервер, который является членом WSFC.

Ресурс кластера
Физическая или логическая сущность, которая может принадлежать узлу, которую можно переводить в режимы «в сети» и «вне сети», перемещать между узлами и которой можно управлять как объектом кластера. Ресурс кластера может принадлежать одновременно только одному узлу.

Роль
Коллекция ресурсов кластера, управляемая как единый объект кластера и предоставляющая определенные функциональные возможности. Для SQL Server ролью будет группа доступности AlwaysOn или экземпляр отказоустойчивого кластера AlwaysOn. Роль содержит все ресурсы кластера, необходимые для роли группы доступности или экземпляра отказоустойчивого кластера. Отработка отказа и восстановление размещения всегда выполняются в контексте ролей. Роль экземпляра отказоустойчивого кластера содержит ресурс IP-адреса, ресурс сетевого имени и ресурсы SQL Server. Роль группы доступности содержит ресурс группы доступности, а также, если настроен прослушиватель, ресурсы сетевого имени и IP-адреса.

Ресурс сетевого имени
Имя логического сервера, которое управляется как ресурс кластера. Ресурс сетевого имени должен использоваться с ресурсом IP-адреса. Для этих элементов могут требоваться объекты в доменных службах Active Directory или в службе доменных имен (DNS).

Зависимость ресурсов
Ресурс, от которого зависит другой ресурс. Если ресурс А зависит от ресурса Б, то Б является зависимостью А. Ресурс A невозможно будет запустить, если отсутствует ресурс Б.

Предпочитаемый владелец
Предпочтительный узел для запуска группы ресурсов. Каждая группа ресурсов связана со списком предпочитаемых владельцев, отсортированных в порядке предпочтения. Во время автоматического перехода на другой ресурс группа ресурсов перемещается на следующий предпочтительный узел в списке.

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

Режим кворума
Конфигурация кворума в отказоустойчивом кластере, определяющая количество сбоев узлов, которое может выдержать кластер.

Обязательный кворум
Процесс запуска кластера несмотря на то, что на связи недостаточное количество элементов для кворума.

Обзор отказоустойчивого кластера Windows Server

Отказоустойчивая кластеризация Windows Server предусматривает инфраструктурные компоненты, поддерживающие сценарии высокого уровня доступности и аварийного восстановления для таких размещенных серверных приложений, как Microsoft SQL Server и Microsoft Exchange. При отказе узла кластера или службы все службы, которые размещались на этом узле, могут автоматически или вручную переноситься на другой доступный узел в рамках процесса под названием отработка отказа.

Узлы в кластере WSFC за счет совместной работы обеспечивают следующие типы возможностей:

Распределенные метаданные и уведомления. Метаданные служб и размещенных приложений WSFC хранятся на каждом узле кластера. Среди этих метаданных не только параметры размещенных приложений, но также конфигурация и состояние WSFC. Изменения в метаданных или состоянии узла автоматически распространяются на другие узлы кластера WSFC.
Управление ресурсами. Отдельные узлы в кластере WSFC могут предоставлять физические ресурсы, например подключаемое напрямую хранилище, сетевые интерфейсы и доступ к общему дисковому хранилищу. Размещенные приложения регистрируют себя как ресурсы кластера и могут настраивать запуск и зависимости от исправности других ресурсов.
Мониторинг исправности. Определение исправности основного узла и исправности между узлами осуществляется за счет сочетания сетевых соединений по типу тактовых импульсов и мониторинга ресурсов. Общее состояние работоспособности кластера WSFC определяется голосами кворума узлов в кластере.
Координация отработки отказа. Каждый ресурс настроен для размещения на основном узле, и каждый можно автоматически или вручную переносить на один или несколько второстепенных узлов. Политика отработки отказа в зависимости от исправности управляет автоматическим переносом владения ресурсами между узлами. Узлы и размещенные приложения получают уведомления об отработке отказа, что позволяет им выполнить соответствующие действия.

Дополнительные сведения см. в статье Failover Clustering Overview — Windows Server(Обзор отказоустойчивой кластеризации — Windows Server).

Технологии SQL Server AlwaysOn и WSFC

SQL Server AlwaysOn — это решение высокого уровня доступности и аварийного восстановления с использованием WSFC. Компоненты AlwaysOn представляют собой интегрированные, гибкие решения, повышающие доступность приложений, окупаемость вложений в оборудование и упрощающее развертывание систем высокого уровня доступности и управление ими.

Экземпляры Группы доступности AlwaysOn и экземпляры отказоустойчивого кластера AlwaysOn используют технологию платформы WSFC и регистрируют компоненты в качестве ресурсов кластера WSFC. Связанные ресурсы объединяются в роль, которую можно сделать зависимой от других ресурсов кластера WSFC. Затем кластер WSFC сможет выявлять необходимость в перезапуске экземпляра SQL Server (и сигнализировать об этой необходимости), а также автоматически выполнять отработку отказа с переходом на другой серверный узел в кластере WSFC.

Чтобы воспользоваться всеми возможностями технологий SQL Server AlwaysOn, вам следует выполнить несколько связанных с WSFC предварительных требований.

Высокий уровень доступности на уровне экземпляра с помощью экземпляров отказоустойчивого кластера AlwaysOn

Экземпляр отказоустойчивого кластера AlwaysOn представляет собой экземпляр SQL Server, установленный на нескольких узлах в кластере WSFC. Этот тип экземпляра зависит от ресурсов для хранения и имени виртуальной сети. Хранилище может использовать общее дисковое пространство на базе Fibre Channel, iSCSI, FCoE или SAS либо локально подключенное хранилище на основе локальных дисковых пространств (S2D). Ресурс имени виртуальной сети зависит от одного или нескольких виртуальных IP-адресов, которые расположены в разных подсетях. Служба SQL Server и служба агента SQL Server также являются ресурсами, и обе они зависят от ресурсов хранилища и имени виртуальной сети.

В случае отработки отказа служба WSFC переносит владение ресурсов экземпляра на указанный узел отработки отказа. Затем экземпляр SQL Server перезапускается на узле отработки отказа и выполняется обычное восстановление баз данных. В любой момент времени FCI и базовые ресурсы могут размещаться только на одном узле в кластере.

Экземпляру отказоустойчивого кластера Always On требуется симметричное общее дисковое хранилище, например сеть хранения данных (SAN) или общая папка SMB. Тома общего дискового хранилища должны быть доступны всем потенциальным узлам отработки отказа в кластере WSFC.

Высокий уровень доступности на уровне баз данных с Группы доступности AlwaysOn

Группа доступности AlwaysOn — это одна или несколько пользовательских баз данных, для которых отработка отказа выполняется одновременно. Группа доступности состоит из первичной реплики доступности и от одной до четырех вторичных реплик, которые поддерживаются за счет перемещения данных на основании журнала SQL Server для обеспечения защиты данных, не требующей общего хранилища. Каждая реплика размещается в экземпляре SQL Server в отдельном узле кластера WSFC. Группа доступности и соответствующее имя виртуальной сети регистрируются как ресурсы в кластере WSFC.

Прослушиватель группы доступности на узле первичной реплики отвечает на входящие клиентские запросы на подключение к имени виртуальной сети и в зависимости от атрибутов в строке подключения перенаправляет каждый запрос в соответствующий экземпляр SQL Server .

При отработке отказа вместо переноса владения общих физических ресурсов на другой узел WSFC используется для перенастройки вторичной реплики на другом экземпляре SQL Server в первичную реплику группы доступности. Затем ресурс виртуального сетевого имени группы доступности переводится на этот экземпляр.

Первичная реплика баз данных группы доступности одновременно может размещаться только на одном экземпляре SQL Server , все связанные вторичные реплики должны находиться на отдельном экземпляре, и каждый экземпляр должен находиться на отдельном физическом узле.

Группы доступности AlwaysOn не требует развертывать экземпляр отказоустойчивого кластера или использовать симметричное общее хранилище (SAN или SMB).

Экземпляр отказоустойчивого кластера (FCI) может использоваться совместно с группой доступности для повышения доступности реплики доступности. Однако во избежание соперничества в кластере WSFC автоматический переход на другой ресурс группы доступности не поддерживается для реплики доступности, размещенной в FCI.

Мониторинг исправности WSFC и отработка отказа

Высокий уровень доступности для решения Always On достигается за счет упреждающего мониторинга работоспособности физических и логических ресурсов кластера WSFC, а также автоматического перехода на другой ресурс и повторной настройки избыточного оборудования. Системный администратор также может запустить переход на другой ресурс вручную для группы доступности или экземпляра SQL Server для перехода с одного узла на другой.

Политики отработки отказа для узлов, экземпляров отказоустойчивого кластера и групп доступности

Политика отработки отказа настраивается на уровне узла кластера WSFC, экземпляра отказоустойчивого кластера SQL Server и группы доступности. Эта политика на основе серьезности, продолжительности и частоты неисправного состояния ресурса кластера и времени отклика узла может включать перезапуск службы или автоматический переход на другой ресурс с переходом с одного узла на другой либо включать перевод первичной реплики группы доступности с одного экземпляра SQL Server на другой.

Отработка отказа реплики группы доступности не влияет на базовый экземпляр SQL Server . При отработке отказа экземпляра отказоустойчивого кластера вместе с этим экземпляром перемещаются размещенные реплики группы доступности.

Определение исправности ресурсов WSFC

Все ресурсы в кластере WSFC могут сообщать о своем состоянии и работоспособности периодически или по запросу. Об отказе ресурса могут говорить различные обстоятельства, например неисправность электропитания, ошибки дисков или памяти, ошибки в сети, неотвечающие службы.

Ресурсы кластера WSFC, например сети, хранилища и службы, можно делать зависимыми друг от друга. Совокупная исправность ресурса определяется путем последовательного суммирования его работоспособности с исправностью каждого из зависимых ресурсов.

Определение исправности между узлами WSFC и определение голосов в кворуме

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

Кворум — это механизм, позволяющий обеспечивать работоспособность кластера WSFC путем проверки наличия достаточного количества ресурсов в нем. Если кластер WSFC имеет достаточно голосов, он работоспособен и может обеспечивать отказоустойчивость на уровне узлов.

Режим кворума настраивается в кластере WSFC, который определяет методику голосования кворума, а также момент выполнения автоматического перехода на другой ресурс или перевода кластера в режим «вне сети».

Рекомендуется, чтобы число голосов кворума в кластере WSFC всегда было нечетным. По соображениям голосования кворума нет необходимости устанавливать SQL Server на всех узлах в кластере. Дополнительный сервер может выступать в качестве члена кворума, либо модель кворума WSFC можно настроить для использования удаленной общей папки в качестве решающего голоса.

Аварийное восстановление через принудительный кворум

В зависимости от принятых методов работы и конфигурации кластера WSFC можно использовать как автоматический, так и ручной переход на другой ресурс. При этом решение SQL Server AlwaysOn остается всегда надежным и отказоустойчивым. Однако если кворуму узлов с правом голоса в кластере WSFC не удается связаться друг с другом либо если кластеру WSFC по другим причинам не удается проверить работоспособность, то кластер WSFC может перейти в автономный режим.

При переходе кластера WSFC в автономный режим из-за неожиданной аварии или по причине постоянно возникающего сбоя в работе оборудования или ошибки связи требуется вмешательство администратора для принудительного создания кворума и переключения работоспособных кластеров обратно в режим «в сети» в неотказоустойчивой конфигурации.

После этого будет необходимо также предпринять ряд действий по перенастройке кластера WSFC, восстановлению затронутых реплик баз данных и повторному созданию кворума.

Связь компонентов групп доступности Always On сервера SQL Server с WSFC

Между функциями и компонентами SQL Server AlwaysOn и WSFC существуют связи нескольких уровней.

Группы доступности AlwaysOn размещаются в экземплярах SQL Server .
Клиентский запрос с указанием логического сетевого имени прослушивателя группы доступности для подключения к базе данных-источнику или базе данных-получателю направляется на соответствующее сетевое имя экземпляра базового экземпляра SQL Server или экземпляра отказоустойчивого кластера SQL Server.

Экземпляры SQL Server активно размещаются на одном узле.
Если имеется изолированный экземпляр SQL Server , то он всегда находится на отдельном узле со статическим сетевым именем экземпляра. Экземпляр отказоустойчивого кластера SQL Server (если он есть) активен на одном из нескольких возможных узлов отработки отказа с единым виртуальным сетевым именем экземпляра.

Узлы являются членами кластера WSFC.
Метаданные и состояние конфигурации WSFC для всех узлов сохраняются на каждом узле. Каждый сервер может предоставлять тома асимметричного хранения или общего хранения (SAN) для пользовательских и системных баз данных. Каждый сервер имеет по крайней мере один физический сетевой интерфейс в одной или нескольких IP-подсетях.

Кластер WSFC контролирует работоспособность группы серверов и управляет их конфигурацией.
Механизмы WSFC распространяют изменения в метаданных и состоянии конфигурации WSFC во всех узлах кластера WSFC. Если используется диск-свидетель, метаданные также хранятся на нем. По умолчанию каждый узел кластера WSFC имеет голос в кворуме, а ресурс-свидетель используется, если он необходим и настроен.

Группы доступности AlwaysOn — это подразделы кластера WSFC.
При удалении и повторном создании кластера WSFC необходимо отключить и повторно включить функцию Группы доступности AlwaysOn на каждом экземпляре сервера, на котором была включена функция Группы доступности AlwaysOn в исходном кластере WSFC. Дополнительные сведения см. в разделе Включение и отключение групп доступности Always On (SQL Server).

Связанные задачи

Просмотр параметров NodeWeight кворума кластера
Настройка параметров NodeWeight для кворума кластера
Принудительный запуск кластера WSFC без кворума

См. также

Технологии Windows Server: отказоустойчивые кластеры
Обзор локальных дисковых пространств (S2D)
Отказоустойчивые кластеры в Windows Server 2008 R2
Просмотр событий и журналов для отказоустойчивого кластера
Командлет Get-ClusterLog отказоустойчивого кластера

Перенос экземпляра отказоустойчивого кластера в SQL Server на виртуальных машинах Azure

В этой статье описывается, как перенести экземпляр отказоустойчивого кластера Always On (FCI) в SQL Server на виртуальных машинах Azure с помощью инструмента миграции сервера в службе «Миграция Azure». Средство миграции позволяет перенести каждый узел в экземпляре отказоустойчивого кластера на виртуальную машину Azure, где размещен SQL Server, а также метаданные кластера и FCI.

Вы узнаете, как выполнять следующие задачи:

Подготовка Azure и исходной среды к миграции.
Запуск репликации виртуальных машин.
Мониторинг репликации.
Выполнение полной миграции виртуальной машины.
Изменение настройки отказоустойчивого кластера с использованием общедоступных дисков Azure.

В этом руководстве рассматривается миграция с использованием агентов в службе «Миграция Azure», который обрабатывает все серверы или виртуальные машины как физический сервер. При переносе физических компьютеров средство миграции сервера в службе «Миграция Azure» использует ту же архитектуру репликации, что и функция аварийного восстановления, использующая агенты, в Azure Site Recovery, а некоторые из компонентов используют одну и ту же базу кода. В некоторых местах может упоминаться документация по Site Recovery.

Необходимые компоненты

Для работы с этим руководством вам потребуется:

Подписка Azure. При необходимости создайте бесплатную учетную запись.
Установите модуль Az Azure PowerShell.
Скачайте примеры скриптов PowerShell из репозитория GitHub.

Подготовка Azure

Подготовка Azure к миграции с помощью средства «Миграция сервера».

Задача	Сведения
Создание проекта службы «Миграция Azure»	Для создания проекта учетная запись Azure должна иметь разрешения участника или владельца.
Проверка разрешений учетной записи Azure	Для учетной записи Azure требуются разрешения участника или владельца подписки Azure, разрешения на регистрацию приложений в идентификаторе Microsoft Entra (ранее Azure Active Directory) и разрешения доступа пользователей Администратор istrator в подписке Azure для создания хранилища ключей, создания виртуальной машины и записи на управляемый диск Azure.
Настройка виртуальной сети Azure	Настройка виртуальной сети Azure (VNet). При репликации в Azure создаются виртуальные машины Azure, которые присоединяются к виртуальной сети Azure, указанной при настройке миграции.

Чтобы проверить наличие требуемых разрешений, выполните следующие действия.

На портале Azure откройте подписку, а затем выберите Управление доступом (IAM).
В разделе Проверка доступа найдите соответствующую учетную запись и выберите ее, чтобы просмотреть разрешения.
Вы должны обладать разрешениями уровня Участник или Владелец.
- Если вы создали бесплатную учетную запись Azure, вы являетесь владельцем подписки.
- Если вы не являетесь владельцем подписки, назначьте эту роль совместно с владельцем.

Если требуется назначить разрешения, выполните действия, описанные в разделе Подготовка учетной записи пользователя Azure.

Подготовка к переносу

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

Проверка требований к компьютеру

Убедитесь, что компьютеры соответствуют требованиям для миграции в Azure.

Проверьте соответствие требованиям к серверу.
Убедитесь в том, что исходные компьютеры, которые реплицируются в Azure, соответствуют требованиям к виртуальным машинам Azure.
Для некоторых источников Windows потребуется внести ряд дополнительных изменений. Миграция источника перед внесением этих изменений может препятствовать загрузке виртуальной машины в Azure. В некоторых операционных системах Миграция Azure вносит эти изменения автоматически.

Подготовка к репликации

Средство миграции сервера службы «Миграция Azure» использует модуль репликации для репликации компьютеров в Azure. Устройство репликации запускает следующие компоненты.

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

Выполните подготовку к развертыванию устройства следующим образом:

Создайте компьютер под управлением Windows Server 2016 для размещения устройства репликации. Просмотрите требования к компьютеру.
Модуль репликации использует MySQL. Проверьте параметры для установки MySQL в модуле.
Проверьте URL-адреса Azure, к которым модуль репликации будет обращаться в общедоступных облаках и облаках для государственных организаций.
Проверьте требования к доступу к портам для устройства репликации.

Устройство репликации должно быть установлено не на том компьютере, на котором выполняется репликация или миграция. При этом это не должен быть компьютер, на котором ранее было установлено устройство для обнаружения и оценки службы «Миграция Azure».

Загрузка установщика устройства репликации

Чтобы загрузить установщик устройства репликации, выполните следующие действия.

В проекте «Миграция Azure» в разделе Серверы, Azure Migrate: Server Migration (Средство миграции сервера службы «Миграция Azure»), выберите Обнаружение.
В разделе Обнаружение компьютеров>Ваши компьютеры виртуализированы? выберите Физическое или другое (AWS, GCP, Xen и т. д.).
В поле Целевой регион выберите регион Azure, в который необходимо перенести компьютеры.
Выберите параметр Подтвердите, что целевым регионом для миграции является «имя-региона».
Выберите Создание ресурсов. После этого в фоновом режиме создается хранилище Azure Site Recovery.
- Если вы уже настроили миграцию с помощью средства «Миграция сервера» службы «Миграция Azure», целевой параметр нельзя настроить, так как ресурсы были настроены ранее.
- После нажатия этой кнопки вы не сможете изменить целевой регион для этого проекта.
- Все последующие миграции будут выполняться в этот регион.
В разделе Do you want to install a new replication appliance? (Вы хотите установить новое устройство репликации?) щелкните Установить устройство репликации.
В разделе Download and install the replication appliance software (Скачайте и установите ПО устройства репликации) скачайте установщик устройства и регистрационный ключ. Для регистрации устройства необходим ключ. Ключ действителен в течение пяти дней после скачивания.
Скопируйте файл установки устройства и файл ключа на компьютер под управлением Windows Server 2016, который вы создали для устройства.
После установки будет автоматически запущен мастер настройки устройства (мастер можно также запустить вручную с помощью ярлыка cspsconfigtool, который создается на рабочем столе компьютера, где установлено устройство). Используйте вкладку Управление учетными записями мастера, чтобы создать фиктивную учетную запись со следующими сведениями:
- guest в качестве понятного имени;
- username в качестве имени пользователя;
- password в качестве пароля учетной записи.

Такая фиктивная учетная запись потребуется вам на шаге «Включение репликации».

Screenshot of the Finalize registration option.

После завершения настройки и перезапуска устройства на вкладке Обнаружение компьютеров выберите новое устройство в разделе Выберите сервер конфигурации и нажмите кнопку Завершить регистрацию. Завершение регистрации выполняет пару заключительных задач по подготовке устройства репликации.

Установка службы Mobility

Установка службы «Мобильность» на серверах, которые нужно перенести. Установщики агента доступны на устройстве репликации. Найдите правильный установщик и установите агент на каждой машине, которую вы хотите перенести.

Выполните следующие действия по установке службы «Мобильность».

Войдите на устройство репликации.
Перейдите к %ProgramData%\ASR\home\svsystems\pushinstallsvc\repository .
Найдите версию установщика, которая соответствует ОС компьютера. Проверьте поддерживаемые операционные системы.
Скопируйте файл установщика на компьютер, который вы хотите перенести.
Убедитесь, что у вас есть пароль, сгенерированный при развертывании устройства.
- Сохраните файл во временный текстовый файл на компьютере.
- На устройстве репликации можно получить парольную фразу. В командной строке выполните команду C:\ProgramData\ASR\home\svsystems\bin\genpassphrase.exe -v , чтобы просмотреть текущую парольную фразу.
- Не создавайте парольную фразу повторно. Это нарушит соединение и вам придется перерегистрировать устройство репликации.
- В параметре /Platform укажите VMware как для компьютеров VMware, так и для физических компьютеров.
Подключитесь к компьютеру и извлеките содержимое файла установщика в локальную папку (например, С:\temp). Выполните эту команду в командной строке с правами администратора.

ren Microsoft-ASR_UA*Windows*release.exe MobilityServiceInstaller.exe MobilityServiceInstaller.exe /q /x:C:\Temp\Extracted cd C:\Temp\Extracted

UnifiedAgent.exe /Role "MS" /Platform "VmWare" /Silent

cd C:\Program Files (x86)\Microsoft Azure Site Recovery\agent UnifiedAgentConfigurator.exe /CSEndPoint /PassphraseFilePath

После завершения установки может пройти некоторое время, пока обнаруженные компьютеры не отобразятся в средстве миграции сервера службы «Миграция Azure». При обнаружении виртуальных машин количество обнаруженных серверов увеличивается.

Screenshot of the Discovered servers option.

Подготовка исходных компьютеров

Чтобы подготовить исходные компьютеры, вам потребуется информация из кластера.

Сохраняйте владение диском на всех этапах процесса репликации вплоть до окончательной прямой миграции. Если владелец диска изменяется, то есть вероятность повреждения томов и необходимости перезапуска репликации. Установите предпочтительного владельца для каждого диска, чтобы избежать передачи прав владения во время репликации.
Избегайте действий по исправлению и перезапусков системы во время процесса реплика tion, чтобы избежать передачи владения диском.

Для подготовки исходных компьютеров выполните следующие действия.

Определение владельца диска: войдите в один из узлов кластера и откройте диспетчер отказоустойчивости кластеров. Определите узел владельца дисков, чтобы определить диски, которые необходимо перенести с каждого сервера.
Получение сведений о кластере: выполните Get-ClusterInfo.ps1 сценарий на узле кластера, чтобы получить сведения о ресурсах кластера. Сценарий выводит имя роли, имя ресурса, IP-адрес и порт пробы в файле Cluster-Config.csv . Используйте этот CSV-файл для создания и назначения ресурсов в Azure, как описано далее в этой статье.

./Get-ClusterInfo.ps1

Создание подсистемы балансировки нагрузки

Чтобы кластер и роли кластера правильно отвечали на запросы, требуется подсистема балансировки нагрузки Azure. Без подсистемы балансировки нагрузки другим виртуальным машинам не удастся подключиться к IP-адресу кластера, так как он не распознается как принадлежащий сети или кластеру.

Заголовок столбца	Description
NewIP	Укажите IP-адрес в виртуальной сети Azure (или подсети) для каждого ресурса в CSV-файле.
ServicePort	Укажите порт службы, который будет использоваться каждым ресурсом в CSV-файле. Для кластерного ресурса SQL используйте то же значение для порта службы, что и для порта пробы в CSV-файле. Для других ролей кластера используется значение по умолчанию 1433, однако вы можете по-прежнему применять текущие настроенные номера портов.

Заголовок столбца

Description

NewIP

Укажите IP-адрес в виртуальной сети Azure (или подсети) для каждого ресурса в CSV-файле.

ServicePort

Укажите порт службы, который будет использоваться каждым ресурсом в CSV-файле. Для кластерного ресурса SQL используйте то же значение для порта службы, что и для порта пробы в CSV-файле. Для других ролей кластера используется значение по умолчанию 1433, однако вы можете по-прежнему применять текущие настроенные номера портов.

Параметр	Тип	Description
ConfigFilePath	Обязательный	Укажите путь к файлу Cluster-Config.csv , который вы заполнили на предыдущем шаге.
ResourceGroupName	Обязательный	Укажите имя группы ресурсов, в которой будет создана подсистема балансировки нагрузки.
VNetName	Обязательный	Укажите имя виртуальной сети Azure, с которой будет связана подсистема балансировки нагрузки.
SubnetName	Обязательный	Укажите имя подсети в виртуальной сети Azure, с которой будет связана подсистема балансировки нагрузки.
VNetResourceGroupName	Обязательный	Укажите имя группы ресурсов в виртуальной сети Azure, с которой будет связана подсистема балансировки нагрузки.
Местонахождение	Обязательный	Укажите расположение, в котором должна быть создана подсистема балансировки нагрузки.
LoadBalancerName	Обязательный	Укажите имя создаваемой подсистемы балансировки нагрузки.

./Create-ClusterLoadBalancer.ps1 -ConfigFilePath ./cluster-config.csv -ResourceGroupName $resoucegroupname -VNetName $vnetname -subnetName $subnetname -VnetResourceGroupName $vnetresourcegroupname -Location "eastus" -LoadBalancerName $loadbalancername

Репликация компьютеров

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

В проекте «Миграция Azure» в разделе Серверы, Azure Migrate: Server Migration (Средство миграции сервера службы «Миграция Azure»), выберите Репликация.
В разделе Репликация, Параметры источника, Ваши компьютеры виртуализированы? выберите Physical or other (AWS, GCP, Xen, etc.) (Физическое или другое (AWS, GCP, Xen и т. д.)).
В разделе Локальное устройство выберите имя устройства Миграции Azure, которое вы настроили.
В разделе Сервер обработки выберите имя устройства репликации.
В окне Учетные данные гостя выберите фиктивную учетную запись, созданную ранее во время установки установщика репликации. Затем выберите Далее: виртуальные машины.
В разделе Виртуальные машины на вкладке Импортировать параметры миграции из оценки? оставьте параметр по умолчанию No, I’ll specify the migration settings manually (Нет, я укажу параметры миграции вручную).
Проверьте каждую виртуальную машину, которую требуется перенести. Затем нажмите Далее: целевые параметры.
В разделе Целевые параметры выберите подписку и целевой регион, в который вы хотите выполнить миграцию, а также укажите группу ресурсов, в которой будут находиться виртуальные машины Azure после миграции.
В разделе Виртуальная сеть выберите виртуальную сеть или подсеть Azure, к которой будут подключены виртуальные машины Azure после миграции.
В области Параметры доступности выберите следующие параметры.
- Зона доступности, чтобы закрепить перенесенный компьютер в определенной зоне доступности в регионе. Используйте этот параметр для распределения серверов, образующих уровень приложения с несколькими узлами, по зонам доступности. Если вы выберете этот параметр, нужно будет указать зону доступности, чтобы использовать ее для каждого из выбранных компьютеров на вкладке «Вычисление». Этот параметр доступен только в том случае, если в целевом регионе, выбранном для миграции, поддерживаются зоны доступности.
- Группа доступности, чтобы поместить перенесенную виртуальную машину в группу доступности. Чтобы использовать этот параметр, выбранная целевая группа ресурсов должна содержать одну или несколько групп доступности.
- Параметр «Избыточность инфраструктуры не требуется», если вам не нужна ни одна из этих конфигураций доступности для перенесенных виртуальных машин.
В разделе Disk encryption type (Тип шифрования диска) выберите один из следующих вариантов:
- шифрование неактивных данных с помощью ключа, управляемого платформой;
- шифрование неактивных данных с помощью ключа, управляемого клиентом.
- Двойное шифрование с помощью ключей, управляемых платформой и управляемых клиентом

Чтобы реплицировать виртуальные машины с помощью CMK, вам потребуется создать набор шифрования дисков в целевой группе ресурсов. Объект набора шифрования дисков сопоставляет управляемые диски с Key Vault, где содержится CMK для использования в SSE.

выберите вариант Нет, если вы не хотите применять Преимущество гибридного использования Azure. Затем выберите Далее.
Выберите вариант Да, если у вас есть компьютеры с Windows Server, на которые распространяются активные подписки Software Assurance или Windows Server, и вы хотите применить это преимущество к компьютерам, которые вы переносите. Затем выберите Далее.

Screenshot of the Target settings option.

Размер виртуальной машины. Если вы используете рекомендации по оценке, в раскрывающемся списке размеров виртуальных машин отобразится рекомендуемый размер. В противном случае Миграция Azure выбирает размер в зависимости от ближайшего совпадения в подписке Azure. В качестве альтернативы выберите размер вручную в разделе Размер виртуальной машины Azure.
Диск ОС. Укажите загрузочный диск ОС для виртуальной машины. Диск ОС — это диск с загрузчиком операционной системы и установщиком.
Зона доступности. Укажите используемую зону доступности.
Группа доступности. Укажите используемую группу доступности.

Screenshot of the Compute settings option.

Используйте ранее созданный список, чтобы выбрать диски для репликации на каждом сервере. Исключите другие диски из репликации.

Screenshot of the Disk settings option.

Вы можете обновить параметры репликации в любое время до начала репликации в разделе Управление>Репликация компьютеров. Настройки невозможно изменить после начала репликации.

Отслеживание и мониторинг

Репликация продолжается в следующем порядке.

Когда вы нажимаете кнопку Репликация, начинается выполнение задания Запуск репликации.
После успешного завершения задания Запуск репликации компьютеры начинают первоначальную репликацию в Azure.
После завершения начальной репликации начинается разностная репликация. Добавочные изменения локальных дисков периодически реплицируются на диски реплики в Azure.
После завершения начальной репликации следует настроить элементы вычислений и элементы сети для каждой виртуальной машины. Кластеры обычно имеют несколько сетевых адаптеров, но для миграции требуется только один из них (установите для остальных адаптеров значение «Не создавать»).

Отслеживать состояние задания можно в уведомлениях портала.

Вы можете отслеживать состояние репликации, щелкнув Репликация серверов в разделе Миграция Azure: миграция сервера.

Screenshot of the Monitor replication option.

Перенос виртуальных машин

После репликации компьютеры готовы к миграции. Для переноса серверов выполните следующие действия.

Screenshot of the Replicating servers option.

В проекте «Миграция Azure» щелкните Серверы, Azure Migrate: Server Migration (Средство миграции сервера службы «Миграция Azure»), и выберите Репликация серверов.
Чтобы убедиться, что перенесенный сервер синхронизирован с исходным, закройте ресурс SQL Server (в разделе Диспетчер отказоустойчивости кластеров>Роли>Другие ресурсы) и убедитесь, что диски кластера подключены к сети.
На компьютерах> с репликацией выберите обзор имени >сервера, убедитесь, что после того, как вы остановили ресурс SQL Server на серверах, которые необходимо перенести, прежде чем перейти к следующему шагу, убедитесь, что после последнего синхронизированного метки времени. Это займет не более нескольких минут.
В области Репликация компьютеров щелкните правой кнопкой мыши виртуальную машину и выберите Миграция.
В разделе Миграция>Завершить работу виртуальных машин и выполнить запланированную миграцию без потери данных? выберите вариант Нет>ОК.

Примечание. При переносе физического сервера автоматическое завершение работы исходного компьютера не поддерживается. Рекомендуется перевести приложение в окно миграции (не позволяя приложениям принимать подключения), а затем инициировать миграцию (сервер должен продолжать работу, чтобы оставшиеся изменения можно было синхронизировать) до завершения процесса.

Изменение настройки кластера

После переноса виртуальных машин перенастройте кластер. Выполните следующие действия:

Завершите работу перенесенных серверов в Azure.
Добавьте перенесенные виртуальные машины в серверный пул подсистемы балансировки нагрузки. Перейдите к пулам серверной части Load Balancer>.
Выберите внутренний пул и добавьте перенесенные компьютеры.
Перенастройте перенесенные диски серверов как общие диски, выполнив скрипт Create-SharedDisks.ps1 . Скрипт является интерактивным. Он запросит список компьютеров, а затем отобразит доступные диски для извлечения (только диски данных). Вам будет предложено выбрать компьютеры, которые содержат диски для включения в общие диски. После этого отобразится запрос на выбор конкретных дисков на каждом компьютере.

Параметр	Тип	Description
ResourceGroupName	Обязательный	Укажите имя группы ресурсов, которая содержит перенесенные серверы.
NumberofNodes	Необязательно	Укажите количество узлов в экземпляре отказоустойчивого кластера. Этот параметр используется, чтобы указать правильный номер SKU для создаваемых общих дисков. По умолчанию скрипт предполагает, что количество узлов в кластере равно 2.
DiskNamePrefix	Необязательно	Укажите префикс, который нужно добавить к именам общих дисков.

./Create-SharedDisks.ps1 -ResourceGroupName $resoucegroupname -NumberofNodes $nodesincluster -DiskNamePrefix $disknameprefix

Параметр	Тип	Description
ResourceGroupName	Обязательный	Укажите имя группы ресурсов, которая содержит перенесенные серверы.
StartingLunNumber	Необязательно	Укажите начальный номер LUN, доступный для присоединения общих дисков. По умолчанию скрипт пытается присоединить общие диски к устройствам с логическими номерами, начиная с 0.

./Attach-ShareDisks.ps1 -ResourceGroupName $resoucegroupname

./Update-ClusterConfig.ps1 -ConfigFilePath $filepath

Экземпляр отказоустойчивого кластера SQL Server готов к работе.

Выполнение переноса

После завершения миграции щелкните правой кнопкой мыши виртуальную машину и выберите Остановить миграцию. Это делает следующее:
- Остановите репликацию для локального компьютера.
- Удалите компьютер из списка Репликация серверов в средстве миграции сервера службы «Миграция Azure».
- Очистите информацию о состоянии репликации для компьютера.
Установите агент виртуальной машины Azure для Windows на перенесенных компьютерах.
Выполните любые действия по настройке после миграции приложения, такие как обновление строк подключения к базе данных и конфигурация веб-сервера.
Выполните приемочное тестирование конечного приложения и миграции на перенесенном приложении, работающем в Azure.
Остановите трафик для перенесенного экземпляра виртуальной машины Azure.
Удалите локальные виртуальные машины из списка локальных виртуальных машин.
Удалите локальные виртуальные машины из локальных заданий резервного копирования.
Обновите внутренние документы и отразите в них новое расположение и IP-адреса виртуальных машин Azure.

Для экземпляра связи требуется просмотр координаций