В предыдущем посте мы создали в 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