Установка и настройка windows hyper-v server 2019

Базовая настройка терминального сервера

Сначала проверим имя рабочей группы и описание компьютера.

Открываем «Панель управления», переходим в раздел «Система».
Нажимаем «Изменить параметры».
На вкладке «Имя компьютера» смотрим, как он идентифицируется в сети. Если имя компьютера или рабочей группы слишком сложное, нажимаем «Изменить» и задаем другие идентификаторы. Для применения нужно перезагрузить систему.

После проверки имени смотрим и при необходимости меняем сетевые настройки. В «Панели управления» открываем раздел «Сетевые подключения».

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

Комьюнити теперь в Телеграм

Подпишитесь и будьте в курсе последних IT-новостей

Установка отказоустойчивого кластера

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

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

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

Эти шаги по конфигурации должны быть выполнены до запуска программы установки SQL Server , для их реализации необходимо использовать оснастку Windows «Администратор кластера». Для каждого экземпляра настраиваемого отказоустойчивого кластера необходимо иметь одну группу WSFC.

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

Добавление или удаление узлов из конфигурации отказоустойчивого кластера, не затрагивая другие узлы кластера. Дополнительные сведения см. на странице Добавление и удаление узлов в отказоустойчивом кластере SQL Server (настройка).

Все узлы на отказоустойчивом кластере должны работать на одной платформе: либо на 32-разрядной, либо на 64-разрядной. Кроме того, на них должен работать один и тот же выпуск и версия операционной системы. Кроме того, 64-разрядные версии выпусков SQL Server должны быть установлены на 64-разрядном оборудовании, работающем под управлением 64-разрядных версий операционной системы Windows. В этой версии отсутствует поддержка WOW64 для отказоустойчивой кластеризации.

Указание нескольких IP-адресов для каждого экземпляра отказоустойчивого кластера. Для каждой подсети можно указать несколько IP-адресов. Если в одной подсети имеется несколько IP-адресов, то программа установки SQL Server устанавливает зависимость в «И». Если выполняется кластеризация узлов по нескольким подсетям, то программа установки SQL Server устанавливает зависимость в «ИЛИ».

Для экземпляра отказоустойчивого кластера SQL Server требуется, чтобы узлы кластера были присоединены к домену. Следующие конфигурации не поддерживаются:

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

Подготовка инфраструктуры

1.1 В виртуальном дата-центре необходимо создать ВМ и пользователей. Создайте три машины, присвоив им имена в зависимости от ролей, настройте кастомизацию.

1.2 Следующий этап: настройка контроллера домена. Укажите роли AD, DNS, Failover Cluster.

1.3 Укажите роль контроллера домена

1.4 Создайте в Active Directory компьютеры ND01 и ND02.

1.5 Установите компонент Failover Cluster на ND01 и ND02

1.6 Теперь нужно создать кластер отказоустойчивости на контроллере домена DC01. Добавьте в него ранее созданные ноды.

1.7 Укажите имя кластера.

1.8 На этапе создания кластера рекомендуем не использовать опцию добавления массивов в каталог. Если забыли и оставили чекбокс включённым — не страшно, это можно сделать и позже.

1.9 Кластер создан.

Вебинар: Установка и настройка Database Lab Engine

635

01:28:06

03.12.2020

В этой сессии Николай Самохвалов и Артём Картасов (Postgres.ai) расскажут и покажут, как установить Database Lab Engine – инструмент, позволяющий выстраивать мощные non-production среды, которые ускоряют разработку и тестирование за счёт того, что становится возможным получать независимые копии Postgres–баз за секунды («одна машина с одним диском — десятки клонов»).

Обсудим в том числе:
— варианты начального получения данных («логический» dump/restore, «физическое» копирование PGDATA или восстановление из архива),
— способы обновления данных,
— конфигурирование и тюнинг Postgres для различных целей клонирования (в том числе: как заставить клоны выдавать планы запросов «как на проде»),
— преобразования с целью удаления или обфускации персональных данных,
— автоматизация процесса создания снапшотов.

Для участия в Zoom нужно быть аутентифицированным в нём (анонимы в звонке будут запрещены), ссылка — по приглашению, доступным через 🤍 Также будет работать трансляция в YouTube, в канале #RuPostgres: 🤍

Задание и проверка DNS-суффикса на всех серверах-репликах

Для кластера рабочей группы в группе доступности, независимой от домена, требуется общий DNS-суффикс. Чтобы задать и проверить DNS-суффикс на каждом сервере Windows, где будет размещаться реплика группы доступности, выполните следующие действия:

С помощью комбинации клавиш Windows+X выберите пункт «Система».
Если имя компьютера и полное имя компьютера совпадают, значит, DNS-суффикс не задан. Например, если компьютер имеет имя ALLAN, полное имя этого компьютера должно быть другим (не ALLAN). Оно должно иметь вид ALLAN.SQLHA.LAB. SQLHA.LAB — это DNS-суффикс. Для рабочей группы должно быть указано значение WORKGROUP. Если вам нужно задать DNS-суффикс, выберите пункт «Изменить параметры».
В диалоговом окне «Системные свойства» нажмите кнопку «Изменить» на вкладке «Имя компьютера».
В диалоговом окне «Изменение имени компьютера или домена» нажмите кнопку «Дополнительно».
В диалоговом окне «DNS-суффикс и NetBIOS-имя компьютера» введите в качестве основного DNS-суффикса общий DNS-суффикс.
Нажмите кнопку «ОК», чтобы закрыть диалоговое окно «DNS-суффикс и NetBIOS-имя компьютера».
Нажмите кнопку «ОК», чтобы закрыть диалоговое окно «Изменение имени компьютера или домена».
Вам будет предложено перезагрузить сервер, чтобы изменения вступили в силу. Нажмите кнопку «ОК», чтобы закрыть диалоговое окно «Изменение имени компьютера или домена».
Нажмите кнопку «Закрыть», чтобы закрыть окно «Системные свойства».
Вам будет предложено перезагрузить компьютер. Если вы не хотите выполнять перезагрузку компьютера незамедлительно, нажмите кнопку «Перезагрузить позже»; в противном случае нажмите кнопку «Перезагрузить сейчас».
После перезагрузки сервера откройте диалоговое окно «Система» еще раз и убедитесь, что общий DNS-суффикс настроен.

Примечание

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

Two Major Technologies of Always On SQL Server

Now that we know what’s AlwaysOn feature it’s time to understand the entire topic in detail. Here, to be more specific, There are two features or we can tcehnologies that are part of this AlwaysOn feature of SQL Server.

AlwaysOn Failover Clustering Instance
AlwaysOn Availibility Groups

Well, both these technologies are qute similar to each other when we look at them. This is because they both take in use the Windows Server Failover Clustering – WSFC. However, when we look at these technologies with the AlwaysOn perspective, they seems to be significantly different from each other.

To understand this, let’s have a look at both these technologies one by one respectively. This can help users know them as well as utilize them well according to business needs.

Home Assistant. Урок 3.1 Lovelace, Maria DB, конфигурация, добавление Yeelight светильников

78134

1355

567

00:19:40

29.01.2020

В этом уроке мы уделим внимание пользовательскому интерфейсу lovelace — переключим его в ручной режим и начнем настраивать, установим аддон Maria DB и пропишем компонент recorder, начнем приводить в порядок конфигурационные файлы и приступим к добавлению устройств — управляемых светильников Yeelight. Настройка lovelace — 🤍
Конфигурация сервера — 🤍
Ссылки и конфигурация урока 3.1 — 🤍
Обратная связь — ask.kvazisgmail.com
Мой канал в телеграмм 🤍smarthomesell — 🤍
Посильная помощь на развитие канала —
Paypal — 🤍
Webmoney — Z767027133804
Таблица (обновляется) по экосистеме Xiaomi — 🤍
Каталог моих обзоров с ссылками — 🤍
Получить кэшбек и экономить на покупках — 🤍
Мод MiHome от vevs (kapiba.ru) — 🤍
“Production Music courtesy of Epidemic Sound” 🤍epidemicsound.com
#kvazis #hassio #homeassistant #learn

Настройка lovelace — 🤍
Конфигурация сервера — 🤍
Ссылки и конфигурация урока 3.1 — 🤍
Обратная связь — ask.kvazisgmail.com
Мой канал в телеграмм 🤍smarthomesell — 🤍
Посильная помощь на развитие канала —
Paypal — 🤍
Webmoney — Z767027133804
Таблица (обновляется) по экосистеме Xiaomi — 🤍
Каталог моих обзоров с ссылками — 🤍
Получить кэшбек и экономить на покупках — 🤍
Мод MiHome от vevs (kapiba.ru) — 🤍
“Production Music courtesy of Epidemic Sound” 🤍epidemicsound.com
#kvazis #hassio #homeassistant #learn

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

Шаг	Ссылки
Создайте группу доступности. Создание группы доступности на экземпляре SQL Server , содержащем базы данных, которые необходимо добавить к группе доступности. Как минимум, создайте первоначальную первичную реплику на экземпляре SQL Server , на котором будет создана группа доступности. Можно задать от 1 до 4 вторичных реплик. Сведения о свойствах группы доступности и реплики см. в статье CREATE AVAILABILITY GROUP (Transact-SQL). Настоятельно рекомендуется создать прослушиватель группы доступности.Предварительные условия: экземпляры SQL Server, на которых размещаются реплики доступности для конкретной группы доступности, должны размещаться на отдельных узлах одного кластера WSFC. Единственное исключение состоит в том, что при переносе в другой кластер WSFC группа доступности может временно находится в двух кластерах. Сведения о других условиях см. в разделах «Обязательные условия и ограничения для группы доступности», «Обязательные условия и ограничения для базы данных доступности» и «Предварительные условия и ограничения для экземпляров SQL Server» статьи Предварительные требования, ограничения и рекомендации для групп доступности Always On (SQL Server).	Для создания группы доступности можно воспользоваться следующими средствами.Мастер создания группы доступностиTransact-SQLSQL Server PowerShell
Присоединение дополнительных реплик к группе доступности. Подключитесь ко всем экземплярам SQL Server , на которых размещена вторичная реплика, и присоедините локальную вторичную реплику к группе доступности.	Присоединение вторичной реплики к группе доступности Совет. При использовании мастера создания групп доступности этот этап выполняется автоматически.
Подготовка баз данных-получателей. На всех экземплярах сервера, где размещена вторичная реплика, восстановите резервные копии базы данных-источника с помощью инструкции RESTORE WITH NORECOVERY.	Подготовка базы данных-получателя вручную Совет. Мастер создания группы доступности может подготовить базы данных-получатели автоматически. Дополнительные сведения см. в разделе «Предварительные условия для использования полной начальной синхронизации данных» статьи Выбор страницы начальной синхронизации данных (мастера группы доступности Always On).
Присоедините базы данных-получатели к группе доступности. На каждом экземпляре сервера, размещающем вторичную реплику, присоедините все локальные базы данных-получатели к группе доступности. При присоединении группы доступности эта база данных-получатель инициирует синхронизацию данных с соответствующей базой данных-источником.	Присоединение базы данных-получателя к группе доступности Совет. Мастер создания группы доступности может выполнить этот шаг, если на каждой вторичной реплике существует каждая база данных-получатель.
Создание прослушивателя группы доступности. Этот шаг обязателен, если прослушиватель группы доступности еще не был создан при создании группы доступности.	Создание или настройка прослушивателя группы доступности (SQL Server)
Передайте имя узла DNS для прослушивателя разработчикам приложений. Им необходимо указать это имя в строке подключения, которая будет использоваться для запроса прямого подключения к прослушивателю группы доступности. Дополнительные сведения см. в разделе Прослушиватели групп доступности, возможность подключения клиентов и отработка отказа приложений (SQL Server).	См. раздел «Дальнейшие действия. Действия после создания прослушивателя группы доступности» статьи Создание или настройка прослушивателя группы доступности (SQL Server)
Настройка места выполнения заданий резервного копирования. Если нужно выполнить резервное копирование баз данных-получателей, то необходимо создать скрипт задания резервного копирования, который учитывает автоматический выбор при создании резервной копии. Создайте скрипт для каждой базы данных в группе доступности на каждом экземпляре сервера, на котором размещена реплика доступности для этой группы доступности.	См. раздел «Дальнейшие действия. После настройки резервного копирования во вторичных репликах» статьи Настройка резервного копирования в репликах доступности (SQL Server).

Добавление тестовой базы данных в MSSQL

3.1 Установите тестовую БД в ноде ND01. Присвойте ей название, например, Bike-Store. Мы взяли БД для теста отсюда.

3.2 Когда БД установится, выделите созданную базу данных и выберите файл БД комбинацией Ctrl+O.

3.3 Когда файл откроется, нажмите F5 или «Выполнить».

3.4 Новая база добавлена, теперь её нужно наполнить. Откройте файл BikeStores Sample Database — load data.sql и добавьте аналогичным способом. Если вы всё сделали правильно, в нижней части экрана появится сообщение «Запрос успешно выполнен».

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

Add Windows Failover Cluster (WSFC) to each replica

On each replica, open Server Manager > click Add Roles & Features > select Add Failover Clustering > click Install. Proceed through the wizard, and when you get to the Select Features page, select the Failover Clustering checkbox.

If you do not already have .NET Framework 3.5.1 or greater installed on your server, select that checkbox as well to install. (If you do need to install the .NET Framework, you will need to reboot the server after installing).

Proceed next through the wizard and click Install to finish the wizard. You will need to do this on every replica in your AG.

Configure WSFC on primary replica

From Administrative Tools, open Failover Cluster Manager and click on Validate Configuration

Add the names of all the SQL Servers you want to configure as replicas in your AlwaysOn group.

On the Testing Options page, click Run all tests (recommended). It is normal to see some warning messages. Make sure to review the warnings and correct anything necessary.

After the validation and summary is complete, the Create Cluster Wizard will open. In the Access Point for Administering the Cluster dialog box, enter the virtual cluster name (not the server or instance name), and the virtual IP address of your cluster.

Proceed next through the wizard, and your cluster will be created. The secondary nodes will be added to the cluster, and your cluster should now show up on all replicas (through Failover Cluster Manager). You do not have to go through these steps on the other replicas…you’re all done with setting up the cluster.

Always On: проверка работы, автоматическая отработка отказа

Посмотрим на панель мониторинга групп доступности (Show Dashboard).

Все OK, группа доступности создана и работает.

Попробуем перевести основную роль на экземпляр node2 в ручном режиме. Щелкните ПКМ по группе доступности и выберите Failover.

Стоит обратить внимание на пункт Failover Readiness. Значение No data loss значит, что потеря данных при переходе исключена

Соединяемся с node2.

Проверяем, что node2 стал основной репликой в группе доступности (Primary Instance).

Убедимся, что слушатель работает как надо. В SSMS укажите DNS имя слушателе и порт через запятую: ag1-listener-1,1445

Сделаем простые insert, select и update запросы в нашу базу SQL Server.

Теперь проверим автоматическую отработку отказа основной реплики. Просто завершите процесс sqlservr.exe на TESTNODE2.

Проверяем состояние группы доступности на оставшемся узле – TESTNODE1\NODE1.

Кластер автоматически перевёл статус реплики testnode1\node1 в primary, так как testnode2\node2 стал недоступен.

Проверим состояние слушателя, потому что соединения клиентов будут поступать именно на него.

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

Эта ошибка возникла из-за параметра “Required synchronized secondaries to commit”. Так как при настройке мы выставляли это значение в 1, Always On не даёт подключиться к базе данных, потому что у нас осталась всего одна primary реплика.

Установим это значение в и попробуем снова.

Включаем testnode2 и проверяем статус группы.

Статус Primary реплики остался у testnode1, а testnode2 стал вторичной репликой. Данные, которые мы меняли на testnode1 при выключенной testnode2 успешно синхронизировались после включения машины.

На этом тестирование закончено. Мы убедились всё работает корректно и при критическом сбое данные останутся доступны для read/write доступа.

Группы доступности Always On достаточно просты в настройке. Если перед вами стоит задача построить отказоустойчивое решение на базе SQL Server, то группы доступности отлично справятся с этой задачей.

С выпуском SQL Server 2017 и SQL Server 2019 в SQL Server Management Studio 18.x появились настройки Always On, которые раньше были доступны только через T-SQL, поэтому рекомендуется пользоваться последней версией SSMS.

Источник

Characteristics of AlwaysOn FCI and AlwaysOn AG

Each of the two technologies differs in its purpose. It is possible to combine
AlwaysOn FCI and AlwaysOn AG. Business requirements might require local high availability
within a data center using AlwaysOn FCI, and cross data center disaster recovery
using AlwaysOn AG. It just means the solution would then consist of a combination
of shared storage and non-shared storage in the implementation.

If you’re wondering which solution to implement, the table below summarizes the
similarity and differences in characteristics between SQL Server AlwaysOn FCI and
AlwaysOn AG solutions as a guide when evaluating SQL Server AlwaysOn.

AlwaysOn FCI for HA and DR	AlwaysOn AG for HA and DR
Shared Storage solution	Non-Shared Storage solution
Instance level HA Logins, SQL Agent jobs, certificates and other SQL Server instance level objects are in-tact after failover	Database level HA (can be one or more databases)Manual adding logins, SQL Agent jobs, certificates and other SQL Server instance level objects to all secondary’s
Instance-level protection without data redundancy	Each group of secondary AG database(s) are redundant copy of primary
Have Active\Passive nodes. No concept of a secondary database.	DR replica can be Active Secondary for backup, read-only workload.
Application connects via virtual server name	Application connects via AG listener name
Does not maintain a redundant copy of the data hence does not protect against an I/O subsystem failure	Protection against an I/O subsystem failure i.e Automatic Page Repair
No special requirements with respect to database recovery models	Database(s) in AG must be in FULL recovery model

Other things to note for both:

Every single AlwaysOn deployment
is a WSFC deployment
Both FCIs and AGs can span multiple
data centers, but with different implementations
Can be implemented on physical SQL
Server systems, or on SQL Server systems that are running as virtual
machines

Characteristics of Always On FCI and Always On AG

Both the technologies serve different purposes. However, you can combine Always On FCI and Always On AG as per your requirement of High Availability and Disaster Recovery. Some of your tasks may require local High Availability within a Data Center via Always On FCI and cross Data Center Disaster Recovery via Always On AG. This means the solution would hold a combination of shared storage and non-shared storage.

The below table summarizes the characteristics of Always On SQL Server AG and FCI to help you understand both the solutions.

Always On FCI	Always On AG
Shared Storage solution	Non-Shared Storage solution
Supports Instance-level HA	Supports Database-level HA
Provides Instance-level protection without data redundancy.	Secondary AG Database(s) are redundant copies of Primary Databases.
Have ActivePassive nodes. No concept of a secondary database.	DR replica can be Active Secondary for the backup, read-only workload.
The application connects via a virtual server name.	The application connects via the AG listener name.
A redundant copy of the data is not stored, hence it does not protect against an I/O subsystem failure.	Automatic Page Repair provides protection against an I/O subsystem failure.

Always On FCI vs Always On AG

V. Отслеживать текущее состояние распределенной группы доступности.

Вся подробная информация о распределенной группе доступности находится в SQL Server, в частности, в динамическом административном представлении группы доступности.

В настоящее время SSMS отображает информацию о распределенной группе доступности только в главной копии группы доступности.

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

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

1. Перечислите все доступные имена реплик через DMV

Следующий запрос может просмотреть все группы доступности (обычные и распределенные) и участвующие в нем узлы, этот результат отображается только при запросе мастер-копии. В sys.availability_groups есть новый столбец is_distributed, который отображается как 1 для распределенных групп доступности.

Вывод показан на рисунке ниже, SPAG1 состоит из двух копий DENNIS и JY. Однако распределенная группа доступности SPDistAG отображает имена двух участвующих групп доступности (SPAG1 и SPAG2) вместо отображения имен экземпляров, как в традиционной группе доступности.

2. Перечислите текущий статус распределенного AG через DMV.

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

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

5. Отображение рабочего состояния AG и распределенного AG через DMV

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

6. Просмотр метаданных распределенного AG через DMV

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

7. Отобразите текущее состояние настроек семян через DMV.

Следующий запрос отображает информацию о текущем состоянии заполнения. Это очень полезно для устранения ошибок синхронизации между копиями.

Характеристики AlwaysOn FCI и AlwaysOn AG

Каждая из этих двух технологий отличается своей целью. Можно комбинировать AlwaysOn FCI и AlwaysOn AG. Для бизнес-требований может потребоваться локальная высокая доступность в центре обработки данных с использованием AlwaysOn FCI и переадресация сбоя центра обработки данных с использованием AlwaysOn AG. Это просто означает, что решение будет состоять из комбинации общего хранилища и неразделенного хранилища при реализации.

Если вам интересно, какое решение реализовать, приведенная ниже таблица суммирует сходство и различия в характеристиках между SQL Server AlwaysOn FCI и решениями AlwaysOn AG в качестве руководства при оценке SQL Server AlwaysOn

AlwaysOn FCI для HA и DR

AlwaysOn AG для HA и DR

Решение с совместным хранилищем

Решение с неразделенным хранилищем

Уровень экземпляра HA

Лог-серверы, задания агента SQL, сертификаты и другие объекты уровня экземпляра SQL Server находятся в тактическом режиме после отказа

Уровень базы данных HA (может быть одной или нескольких баз данных)

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

Защита на уровне экземпляра без избыточности данных

Каждая группа вторичных баз данных AG является избыточной копией первичной

Есть Активные \ пассивные узлы. Нет концепции вторичной базы данных.

Реплика DR может быть активной вторичной для резервного копирования, только для чтения.

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

Приложение подключается через имя прослушивателя AG

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

Защита от сбоя подсистемы ввода-вывода, то есть Автоматический ремонт страницы

Никаких особых требований в отношении моделей восстановления базы данных

Базы данных в AG должна быть в модели восстановления FULL

Другие примечания, касающиеся обоих решений

Каждое развертывание AlwaysOn — это развертывание WSFC
И FCI, и AG могут охватывать несколько центров обработки данных, но реализованы по разному.
Решения могут быть реализованы на физических системах SQL Server или работающих под управлением виртуальных машин