У меня небольшая сеть, состоящая из 1xSBS2008 (Exchange примерно с 50 почтовыми ящиками, Great Plains SQL, общие файловые ресурсы, общие принтеры, DNS, DHCP, GPO и т. Д.) И 1xWin2k8 (SQL Server). В головном офисе около 10 пользователей, а затем у нас есть ссылки на 5 удаленных точек, в каждом из которых находится от 3 до 6 компьютеров. Удаленные местоположения не присоединены к AD, и это не планируется делать в ближайшее время из-за ограничений программного обеспечения / пользователей третьей стороны. Я изучаю возможность переноса / замены обоих серверов в Azure. Я буду переносить электронную почту в Office365. Доступ к файлам должен оставаться в общих файловых ресурсах / подключенных дисках. Подключение к Интернету в головном офисе составляет 20/20. Я планирую создать 3 виртуальные машины Azure: 1xAD DC (это виртуальная машина, а не Azure AD) 1xGreat Plains SQL / File Server 1xSQL Server для их пользовательского приложения LOB В головном офисе я затем настроил бы VPN для Azure через существующий брандмауэр Endian и измените существующую виртуальную частную сеть удаленного сайта на прямую связь с Azure. Endian также станет DHCP и DNS, поэтому нет постоянного контроллера домена. В параметрах DHCP в качестве основного DNS-сервера будет использоваться Azure DC, а в качестве вторичного - Endian. В конце концов я, вероятно, переведу все рабочие станции на Azure RDS.
Кто-нибудь видит с этим проблемы? Какой у меня контроллер домена только для чтения, или реплика DFS? Удаленные сайты передают только небольшие объемы данных (розничные магазины), поэтому я уверен, что это сработает для них, но не в основном для головного офиса. Как вы обновляете свои среды SBS, когда клиентам нужно только облачное решение без внутреннего оборудования?
Я протестировал аналогичную конфигурацию, сосредоточив внимание на задержке в сети (на ограниченном потребительском широкополосном доступе). Ключевым моментом здесь является задержка. Хорошая новость заключается в том, что просмотр папок и т. Д. Был расширен с помощью «нового» сетевого стека в Vista и более поздних версиях. Однако загрузка / выгрузка файлов по-прежнему затронуты. Большая часть активности файлового сервера - это чтение. Я использовал BranchCache, чтобы ускорить это - размещение ветвления на микросервере (возможно, также RODC, если это возможно) было бы идеально.
Еще вам нужно учитывать производительность вашего SQL-приложения. Клиентский веб-сайт или ПК? Если он находится на ПК, попробуйте использовать RemoteApp для запуска клиента в облаке. Черт возьми, вам может настолько понравиться RemoteApp, что вы помещаете все приложения в облако и вам вообще не нужно смотреть на BranchCache, поскольку трафик клиент / сервер останется в Azure.
Другое соображение - это наборы доступности. Azure и т. Д. Были разработаны для больших служб, «предназначенных для облака». Когда MSFT выполняет цикл исправлений, все в домене сбоя / обновления отключается на короткое время. Это означает, что у ваших услуг будут простои. График объявлен как что-то вроде «вы увидите время простоя с четверга по воскресенье». Они способствуют созданию высокодоступных сервисов, которые распределяются по доменам сбоя с помощью наборов доступности. Это легко с DC (возможно, с двумя базовыми A2), но намного сложнее и дороже с традиционными рабочими нагрузками, такими как файловые серверы.