我有一个小型网络，由 1xSBS2008（Exchange，大约有 50 个邮箱、Great Plains SQL、文件共享、打印机共享、DNS、DHCP、GPO 等）和 1xWin2k8（SQL Server）组成。总部大约有 10 个用户，然后我们链接到 5 个远程位置，每个位置有 3 到 6 台 PC。远程位置没有加入 AD，而且由于第三方软件/用户限制，近期不打算加入 AD。我正在研究将两台服务器迁移/替换到 Azure 的选项。我将把电子邮件迁移到 Office365。文件访问需要保留在文件共享/映射驱动器中。总部的互联网连接为 20/20。我的计划是创建 3 个 Azure VM：1xAD DC（这是 VM 而不是 Azure AD）1xGreat Plains SQL/文件服务器1xSQL Server（用于他们的 LOB 自定义应用程序）在总部，我将通过现有的 Endian 防火墙设置到 Azure 的 VPN，并将现有的远程站点 VPN 更改为直接链接到 Azure。Endian 也将成为 DHCP 和 DNS，因此本地没有 DC。DHCP 选项将 Azure DC 作为其主 DNS，Endian 作为其辅助 DNS。最终，我可能会将所有工作站移动到 Azure RDS。
有人发现这有什么问题吗？我应该在本地安装 RODC 还是 DFS 副本？远程站点仅传输少量数据（零售店），因此我相信这对他们有用，但对总部来说就没那么好了。当客户只想要一个没有本地硬件的云解决方案时，您如何升级您的 SBS 环境？
答案1
我测试了类似的配置，重点关注网络延迟（在有限的消费者宽带上）。延迟是这里的关键。好消息是，浏览文件夹等功能在 Vista 及更高版本中通过“新”网络堆栈得到了提升。但是，文件下载/上传仍然受到影响。大多数文件服务器活动都是读取。我使用 BranchCache 来加速这一点 - 在 Microserver（如果可能的话，也可能是 RODC）上托管分支缓存将是理想的选择。
您需要考虑的另一件事是 SQL 应用程序的性能。客户端是基于 Web 还是在 PC 上？如果在 PC 上，请考虑使用 RemoteApp 在云中运行客户端。哎呀，您可能非常喜欢 RemoteApp，以至于将所有应用程序都放在云中，而根本不需要查看 BranchCache，因为客户端/服务器流量将保留在 Azure 中。
另一个考虑因素是可用性集。Azure 等是为大型“为云而设计”服务而设计的。当 MSFT 进行修补周期时，故障/更新域中的所有内容都会短时间关闭。这意味着您的服务将停机。时间表被宣布为“您将在周四至周日之间看到停机时间”。解决这个问题的方法是使用可用性集创建分布在故障域中的高可用性服务。使用 DC（可能是 2 个 Basic A2）很容易做到这一点，但使用文件服务器等传统工作负载则要困难得多，而且成本更高。