最近一次停电之后，我们一直在重新评估如何最有效地提供、维护和支持我们的 IT 资源。
我们一直在考虑的一个想法是将非关键基础设施迁移到云端。例如，我们可以只在校园内维护以下服务：
- DNS（可能只是转发器）
- DHCP（带故障转移）
- 目录和 Kerberos（用于网络身份验证）
...就这样。有了这样的计划，即使发生灾难，我们只需专注于保持互联网连接，其他所有服务仍可用。
我正在研究 Amazon EC2，但还没有决定使用什么。其他大学或企业是如何做类似事情的？有什么“陷阱”或障碍是我们应该知道的吗？有没有博客/论坛可以详细介绍企业级云迁移？
答案1
潜在的困难/障碍：
带宽：当您谈论将数据库和文件服务器等带宽密集型服务移出现场时，您需要仔细考虑需要多粗的管道才能维持现有的性能水平。根据您所代表的机构类型，您可能已经或可能没有千兆或 10 千兆光纤到您的校园。如果您需要有保障的带宽并且能够负担得起投资，那么通过AWS Direct Connect可能需要考虑一些事情。
潜伏：您的用户可能拥有数据库驱动的应用程序，这些应用程序可以做一些聪明的事情，例如动态执行多个查询来填充下拉列表（如果它们针对 .mdb 文件而不是 SQL 服务器运行，情况会更糟）。或者，他们可能有一个包含 10,000 个战略性命名的 Word 文档的 Windows 文件共享，浏览可能突然需要几分钟而不是几秒钟。这些问题只能通过以下方式缓解：部分确保与托管环境建立干净、低延迟/低抖动的连接。但是，最终的解决方案是使用为云正确设计的应用程序（例如，使用 Google Apps 而不是 MS Office，或使用基于 Web 的数据库前端而不是 Access 数据库）。
成本：您需要仔细评估租用虚拟服务器的成本是否与维护现场基础设施的成本相当。有许多变量，从资本支出到电力再到维护成本，所有这些都需要在同类比较中考虑。不要忘记 EC2 会为出站带宽收费，而传统上“本地”的服务可能会消耗大量带宽。
可靠性：您的互联网连接是否比您现有的服务器基础设施更可靠？如果不是，您需要添加多少冗余，成本是多少？像 2011 年 4 月和 8 月那样的 EC2 中断会对您的运营产生什么影响？
答案2
主 Web 服务器、旧 Web 服务器、Moodle 服务器、Mahara 服务器、VoIP 服务器、打印服务器、文件服务器、Wordpress 服务器、学生 Web 服务器、两个数据库服务器和两个 SharePoint 服务器。如果将 VoIP 服务器迁移到云中导致的延迟增加不可接受，则还需要将其置于现场并被视为“关键”基础设施。否则，理想情况下，只要我们保持互联网连接，它就只是另一个“正常工作”的东西。
请考虑以下内容作为进一步讨论的要点；这里没有具体的答案，只是我脑海中浮现的一些您应该思考并与同行讨论的事情：
您可能可以排除 VoIP，以及来自云的打印服务器和文件服务器。我怀疑，如果不做大量工作，VoIP 的延迟是无法接受的。但是，您的电信/SIP 提供商可能会提供他们自己的托管服务，这可能值得研究。文件和打印可能与依赖 LAN 速度/延迟才能正常工作的旧版软件（例如图像管理）绑定在一起。我敢肯定，您越深入研究这个问题，就会发现很多问题。
数据库可能没问题，但对于使用它们的应用程序来说，延迟可能又是不可接受的。
基于 Web 的服务器可能在开箱即用的云环境中运行良好（Wordpress、Moodle 等），但如果它们依赖于此时仅驻留在校园网络内的核心服务，您将需要考虑复制或安全地远程访问这些服务（无论如何您都必须以私有云和 VPN 隧道的形式进行）。
而关于云的一个很大的误称就是，人们期望他们的软件和服务会因为“在云中”而表现不同，除非你的服务堆栈已经过优化以利用云提供的分布式架构，否则当实例发生故障时，你将遇到单点故障。
当然，软件许可可能会或不会带来额外的障碍。
显然，这些非关键服务中可能存在也可能不存在信息的隐私性和所述信息的保护，这可能会让您的法律顾问感到不安。
而且，您仍然需要改进核心服务的恢复/连续性：这才是真正的根本问题，不是吗？此外，您的核心服务现在将包括冗余、优先、高质量的互联网连接，因为如果没有这些，您的云服务实际上就毫无用处。
仅仅确定这些“非关键”服务（可能对您来说并不关键，但对另一个部门来说，可能是最重要的；如果您尚未制定服务级别协议，那么服务级别协议可能是一件好事）是否是成功的云候选者就不是一件容易的事。
好处是，您将对您的 IT 基础设施进行全面盘点/发现（这总是有益的），以确定您可以做什么或不能做什么（或至少进行试点）。而且由于您只在云运行时费用上花钱，因此您的试点不需要大量现金支出。
答案3
我真的很喜欢 EC2 的灾难恢复功能，但我总是对将大量基础设施迁移到它上面持怀疑态度。我真正喜欢 EC2 的原因是它的 DR 功能——复制所有关键数据。如果您真的做好了规划基础，您可以在 EC2 和本地安装操作系统。如果您的 IT 大楼火光四起，您可以启动一堆 EC2 实例，重新指向 DNS，然后开始提供服务。好处是，当它们处于离线状态时，它们的成本只不过是静态存储费用。
如果您确实做得正确，您可以根据需要在任一位置打开系统。这也允许您自由地进行实验并轻松使用最便宜的系统。
无论你身在校园，你都可以去真的很大使用 DR 策略。我不知道它与亚马逊打交道的语义，但许多大学都在使用 B 类地址空间。您可以踢出为镜像服务保留的 C 类 BGP 路由。如果您的 Web 服务器位于该地址空间中，校园内或直接连接的任何东西都会路由到校园机器，任何发现亚马逊更近的东西都会路由到那里。（截至 2010 年 3 月，这是不可能的。这是人们强烈要求的，现在可能实现，也可能不实现）。事实上，如果您只关注内部路由表，您实际上可以在校园内严格建立而无需 BGP 路由。
毫无疑问，这会增加复杂性，但绝对会让你变得非常有弹性。