Как перенести доменную сеть в облако Azure?

Question

[Alexander Tartmin]

Есть сеть с 2мя физическими и 2мя виртуальными серверами под WinServer 2012R2 и 5+ клиентов. Два сервера это контроллеры домена (primary и RODC), Hyper-V сервер и сервер терминальных приложений (RemoteApp). Из-за некоторых моментов начал рассматривать переезд в облако мелкософта. Из того что пытался нагуглить на эту тему вышло ещё больше вопросов:

• Для работы доменной сети в Azure есть что-то специальное или нужно будет поднять 2 ВМ?
  
• Как быть с терминальным сервером? На нём крутится SQL Server и 3 приложения доступ к которым должен остаться "из любой точки мира" через RemoteApp
  
• Как будет лицензироваться вся эта кухня? Есть лицензии на ОСь и клиентские лицензии RemoteApp полученные через Open License. Они уже будут не нужны?
  
• Стоит ли оставлять один из контроллеров домена "дома"? Есть идеи перевести клиентов на ТК, так как будет в итоге простаивать довольно производительный сервер. Хочется его чем-то полезным забить.
  

Comments

[NRinat]

Добрый день!
Очень рекомендую вам посмотреть полностью видео CloudRanger про Azure.
Все станет понятно.
Мы обслуживаем 9 серверов на Azure одного из наших заказчиков с самого начала существования данного облака.
За все это время было пару незначительных сбоев.

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

Если говорить про Azure Active Directory, то просто синхронизируйте вашу AD с AzureAD.
Для синхронизации есть несколько способов, один из них это DirSync.

На вашем месте я бы оставил один из контроллеров в локальной сети на всякий случай, разделили бы сеть на два сайта (AzureSite + PremiseSite), включил бы мгновенную репликацию, если ваш канал позволяет.

Извиняюсь за некоторую сумбурность ответа.

[Alexander Tartmin]

NRinat: Отличный ответ! Всё стало на места, хоть немного вопросов таки осталось. Будет ли верно в офисе оставить RODC и я не много не понял касательно разделения. Можно немного подробнее?

[NRinat]

Для чего Вы используете RODC? У вас сложности с физической защитой контроллера? Его могут утащить враги?
Про разделение.
Поднимаете пару контроллеров в Azure, кладете их в AvailabilitySet, чтобы они у вас запускались на разном железе в датацентрах Azure (в случае, если у МС умрет сервак, где лежит ваш контроллер, то другой контроллер останется жить)
Поднимаете один или два контроллера у себя в офисе.

Создаете в AD два сайта: AzureSite и сайт для контроллеров в офисе HQSite
Раскладываете по сайтам контроллеры. Включаете, чтобы репликация была не каждые 15 минут, а сразу (конечно, если вам это позволяет канал в Инет, и если у вас менее 500 пользователей), погуглите "notification based replication"

Какие плюсы получаете.
Клиенты в офисе будут дергать офисные контроллеры и не будут бегать в Azure, а машины в Azure будут пользовать Azure-контроллеры.

Напишите подробнее, зачем же вам RODC.

[Alexander Tartmin]

NRinat: Ну я видимо не правильно понимаю роль RODC. Мне казалось основная его задача поддерживать доступ к AD пока основной контроллер лежит.

[NRinat]

Немного поясню.
Основная роль RODC - обеспечить защиту домена от нерадивых админов в филиалах и от компрометации контроллера домена в физически незащищенных местах. В AD уже давно нет первычных и вторичных контроллеров. Все контроллеры могут нести все типы ролей (не одновременно, конечно).
Поставьте пару контроллеров в офисе и все будет хорошо.

Answer 1

[athacker]

1) Azure -- это просто облачная платформа. Рассматривайте её как средство виртуализации. Т. е. вы просто создаёте там виртуальные машины и разворачиваете там свои сервисы, и всё.

2) А что с терминальным сервером? Хотите перенести в облако -- переносите. Не хотите -- оставьте у себя. В чём вопрос-то?

3) Лицензии -- это предмет тёмный... :-)

4) Контроллер домена стоит оставить дома в любом случае. Мало ли чо -- проблемы со связью, всё такое. Чтобы не было проблем со входом юзеров в систему. На этом производительном сервере разверните Hyper-V, в нём -- виртуальный контроллер домена, ну и ещё что-нибудь, по вкусу.

Comments

[Alexander Tartmin]

Сейчас два физ.сервера
Один это основной DC, второй это Hyper-V на котором крутится и RODC сервер и RemoteApp.
С этим azure больше вопросов, так как я читал что у них там можно и домен развернуть и как я понимаю не на VM, а в самом Azure есть что-то для этого (Oficce365). Может я не так понял и этот офис это альтернатива Google Apps, то тогда он мне не подходит, понятное дело.

[Alexander Tartmin]

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

[Alexander Tartmin]

Ну и так для справки. Это все дело обслуживает только отдел бухгалтерии на предприятии. Со связью и светом траблы и из-за этого было решено переезжать. Так как все сотрудники могут работать издому я считаю что надо не просто куда-то переехать, а в облако мелкософтов. Единственное что я не понимаю, какие преимущества у них перед другими хостерами.

[athacker]

Alexander Tartmin: Товарищ. Вы спросили, цитирую: "Как перенести доменную сеть в облако Azure"?. Вы не спрашивали про наличие преимуществ в Azure перед другими платформами виртуализации.

Домен в Azure развернуть можно. Ровно также, как и на любой другой облачной платформе -- поднять виртуалку, установить на ней Windows Server и поднять на нём домен.

Office365 -- это вообще про другое. Это набор офисных приложений на вебе.

Я только не очень понимаю, зачем вам на одной физической площадке контроллер домена и там же виртуальный RODC :-) В удалённом офисе -- ещё понятно, зачем RODC, а локально зачем?

А в остальном -- да, вы правы, точно также можно домен и на амазоне развернуть. Поэтому разворачивать лучше там, где дешевле и что лучше знакомо.

[athacker]

Alexander Tartmin: А, ну и да. Хотя оратор выше и написал ересь, но отчасти он прав -- если у вас есть своё нормальное оборудование -- ну перенесите его туда, где нет проблем со связью и электричеством, и запилите всю виртуализацию на своём оборудовании. Всё равно даже в облаке нужно будет настраивать всё на серых IP-адресах, от греха, и делать дырочку в виде VPN-сервера в облаке для подключений извне.

[Alexander Tartmin]

Согласитесь что своё оборудование и обновлять нужно и софт покупать (увы так за много лет и не научился торрентами пользоваться). Ввиду этого облако идеальный вариант. Другое дело это возможности. Этот вопрос у меня появился уже после вашего ответа и мне следовало бы его сразу задать :). Если мелкософт позиционирует своё облако как "выбросьте ваше железо и го к нам" давая возможность не дорого, быстро и безболезненно перенести готовую инфраструктуру в облако то это одно. Если же azure не более чем VPS хостинг, тогда интересно какие есть преимущества перед тем же амазоном. Я все же верю что у них есть какие-то штуки для развёртывания Active Directory и мне очень интересно каким образом деплоятся приложения в их RemoteApp и каким образом мне подключаться к SQL серверу. Если у них это все завязано на VMах которые мне самому придётся админить (обновлять, бэкапить и все такое) то я скорее всего буду смотреть в сторону Амазона. С тем оратором я отчасти согласен, SSL сертификаты давно уже куплены у VerySign и в плане защиты сети сделано многое. Теперь вопрос как это все переместить географически из офиса так, что бы юзеры даже не заметили разницы.

[athacker]

Alexander Tartmin: А, вы про это. Есть Azure AD и Azure SQL. Про первый и возможности его синхронизации с локальной AD можно почитать тут коротенько: habrahabr.ru/company/microsoft/blog/241313

Azure SQL -- ну, просто облачная база данных :-) Аналогом является тот же Amazon RDS. Только в Azure это, условно говоря, на базе MS SQL, а у Амазона на базе других движков.

Как переместить -- ну, спланировать и переместить :-) Про синхронизацию Azure AD с локальной есть выше, про миграцию БД в Azure SQL можно почитать, например, тут: https://azure.microsoft.com/ru-ru/documentation/ar...

[Alexander Tartmin]

athacker: Во, то что я и ожидал прочесть! Спасибо большое =)

Answer 2

[HakerPolza]

Для репликации обязательно должен быть физичиский контролер домена.
з.ы. его можно сделать "дома" и виртуальным
проблем не будет при грамотной настройке перенести его с физичиского виртуального на физичиский носитель.
На твоем месте я бы не выкладывал в в "общедостпуную" сеть домен, надежность, что тебе мешает это сделать"дома".
доступ из любой точки мира, защитить не можешь?
почитай мой друг про ssl сертификаты и авторизацию по ним.
это тебе не облегчит задачу, нормальных пропускных скоростей тебе не дадут, что касается ресурсов они будут ограничены.
могу посоветовать следующее:
первое что тебе потребуется это защита
из простого, не дорогостоющего, позамарачиваешься, выведит на новый уровень
поднимаешь на unix - сервер фильтрации доступа - будет выполнять роль фаервола
далее сеть всю заганяешь - что бы она была не физичиская, а виртуальная.
дам подсказку маска должна быть 255.255.0.0 - доступ будет только как к общественой сети, т.е. из вне не подцепишься, подумаешь как подключаться. Более конкретно не хочу говорить и так довольно много сказал.
Что сажу на последок Azure - это бональная сеть виртуалок и все.

Comments

[Иван]

А каким образом маска сети класса B разграничивает доступ? Может все-таки имелись ввиду диапазоны приватных адресов?

[Иван]

P.S. Azure предоставляет виртуальную сеть класса A, доступ к сети предоставляется посредством VPN site-to-site

[NRinat]

Amigo83: Azure предоставляет приватные сети из всех трех диапазонов.
Доступ к сети Azure можно настроить через site-to-site VPN, а также на каждому серверу можно подключаться при помощи реального ip.
5 ip бесплатно, но каждый ip нужно закрепить за машиной. Также рекомендую закреплять приватные ip за контроллерами.