Виртуальная машина SQL Server 2012 в Облаке - подключение

 

В предыдущем посте мы создали в Azure виртуальную машину из галереи с предустановленной на ней пробной версией SQL Server 2012. К машине можно подключиться через удаленное соединение (Рис.14 пред.поста) и выполнять административные задачи, в том числе администрировать SQL Server, т.к. на ней изначально имеются все необходимые компоненты, включая SSMS. С практической стороны наиболее распространенными являются не чисто облачные, а гибридные сценарии, когда данные частью хранятся в Облаке, а частью - в on-premise БД. Для их совместной обработки потребуется "сопрячь" свежесозданный SQL Server в Azure с on-premise SQL Server. Для начала было бы неплохо увидеть SQL Server на облачной виртуалке из локальной SSMS.

По умолчанию, SQL Server на виртуальной машине из галереи установлен в режиме интегрированной безопасности, в чем можно убедиться, запустив SSMS на удаленном соединении. Соединяемся в нем с SQL Server при помощи административной учетной записи Windows, автоматически созданной при создании виртуальной машины (см. Рис.9 предыдущего поста).

Рис.1

Кликаем правой кнопкой на SQL Server в Object Explorer и выбираем Properties. В свойствах на странице Security вместо Windows Authentication отмечаем SQL Server and Windows Authentication mode:

Рис.2

После чего появится напоминание о необходимости перезапуска SQL Server, чтобы сделанные изменения вступили в силу. Перезапускаем:

Рис.3

После перезапуска заходим в папку Security в Object Explorer и создаем новые SQL Serverные логины, указывая каждому имя/пароль, для соединения по стандартной аутентификации. Указываем созданным логинам членство в ролях. При необходимости создаем для них новые роли уровня БД и сервера. На всякий случай напомню, что в SQL Server 2012 можно создавать пользовательские роли не только в БД, но и на уровне сервера.

Рис.4

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

Рис.5

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

Рис.6

Осталось сделать то же самое из on-premise SSMS. Для SQL Server виртуальной машине нужно создать конечную точку так же, как она была создана (автоматически) при создании виртуальной машины для удаленного доступа. Возвращаемся в окно Windows Azure Management Portal, кликаем два раза по строчке с виртуальной машиной (см. Рис.13 предыдущего поста) и в верхнем меню выбираем пункт EndPoints, а в нижнем - Add Endpoint:

Рис.7

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

Рис.8

В целом, применимы рекомендации прошлогодней статьи "Конфигурирование SQL Server для сетевого доступа".

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

Рис.9

Процесс создания конечной точки занимает ~1-2 мин.

Рис.10

Остается зайти на файрвол виртуальной машины в удаленном соединении и открыть порт 1433 для входящих соединений:

Рис.11

Рис.12

Рис.13

Рис.14

Рис.15

Все. Запускаем on-premise SSMS, из которой непринужденно соединяемся с SQL Server на облачной виртуалке:

Рис.16

Server name = DNS-имени виртуальной машины (см. Рис.10 предыдущего поста).

Примечание

Внешний и внутренний порты конечной точки (Рис.9) могут, вообще говоря, отличаться по соображениям безопасности, балансировки и др. Отредактируем конечную точку sql-server (см. Edit Endpoint в нижнем меню на Рис.10):

Рис.17

Private port относится к взаимодействию с SQL Server внутри виртуальной машины - это собственные порты SQL Server, настройки Windows Firewall и т.д. Public port - общение извне виртуальной машины. Т.к. мы изменили внешний порт, то в соединении со стороны on-premise SSMS его потребуется указать явно (в отличие от 1433, который молчаливо подразумевается, если в явном виде не указан).

Рис.18