在 Azure 上从 IaaS 迁移到 PaaS 有多难

Question

所以我想在 Azure 池中试一试

我们的网络应用套件很快就会成为纯 ASP.Net + SQL Server 的事情

由于各种原因，最初创建 SQL VM 并从那里运行所有内容会更简单。

这有多难……

• ...将 SQL 从 VM 迁移到“云服务”或“数据管理”？
• ...将 WebApp 套件从 VM 迁移到“网站”中？

据我了解，完成此迁移后，操作系统级别的更新将不再是我关心的问题，因为它们将由服务处理。因此，在这一点上，我将能够扔掉原来的 VM :)

Answer 1

这并不能完全回答您的问题，但它可能会帮助您了解更多要问的问题，并为您提供动力。这些都是我们将系统迁移到 Azure 之前、期间或之后的经验教训。现在我们已经到了那里，我们有一个约 50GB 的数据库，其中有约 6 个服务在约 30 个实例上运行。只要我们的数据库备份正常，升级所有的总工作量不到一个小时（如果我们没有许多旨在迫使我们注意的安全措施，可能会少得多迁移过程中发生的事情 - 我们不希望它太易于部署，只是为了保护我们自己）。

准备将您的系统迁移到 Azure：

如果您计划使用 Azure，首先需要确保您的体系结构和技术兼容。这并不是说您必须编写所有特定于 Azure 的代码。这意味着以下一些事情：

• 您应该意识到“高可用性”并不意味着“无错误”。事实上，高可用性环境通常有更多个错误你必须处理和管理。例如，如果您有一个请求通过网络发送到刚刚出现主板故障并离线的服务器，则该网络请求将不成功。这通常不是您在“标准”服务器应用程序中编码的问题。更进一步，如果失败的网络是用于被放回连接池的数据库连接怎么办？这将导致该连接在下次有人将其拔出时被毒化并中断，而不管该服务器的未来状态如何！这里有一些额外的事情需要担心，因为您不再依赖于仅具有 4 个服务器的 1 个网络，而是现在依赖于具有数千个服务器的数百个网络。这种 0.05% 的错误场景发生在您身上的频率将比您过去所经历的要多得多，您真的必须意识到这一点！
• 你应该使用依赖注入来轻松地改变周围的事物。适当的关注点分离将使看似非常困难的更改在 Azure 中变得非常容易。
• 您应该使用“高可用性”架构。例如，在 Web 场中运行时会中断的 Web 应用程序也会在 Azure 中中断，但设计用于在 Web 场中运行的 Web 应用程序在 Azure 中运行起来非常容易。
• 您应该对所有应用程序进行自动化部署和配置转换。其他任何东西都是不可持续的，除非它只不过是一个小网站或类似的东西。
• 根据您的需要，您可以分阶段进行。如果数据库延迟不是什么大问题，也许可以采用混合方法（通过从 Azure 到数据中心的 VPN）先在 Azure 中获取应用程序，然后再迁移数据库。或者也许相反。我们所做的是将主要应用程序和数据库保留在我们的数据中心，但首先将辅助应用程序放在 Azure 中。然后是一些主要应用程序（直到一个月的性能受到影响）后来我们的数据库和关键应用程序。最后的迁移确实让我们度过了一个很长的周末，而且睡眠时间也不长，但是现在我们完成了，感觉好多了！

将您的应用程序迁移到 Azure：

这最终在很大程度上取决于您的应用程序是什么或做什么，并且每个场景都有不同的步骤/问题/好处。除了说：“使用 Google，它是你的朋友！”之外，我不会深入讨论这个问题。除此之外，对我们而言，与我们的数据相比，将我们的应用程序放到 Azure 中是最大的回报。在托管成本、许可和管理工作之间，我们的应用迁移的投资回报率不到一个月。我现在可以花一天时间为我们所有的 SaaS 应用程序/数据库/等设置一个全新的重复环境，并让它们在大约 25 个不同的云实例上运行，而不是花几天时间来设置服务器！

与其试图告诉您如何迁移这些，让我提醒您几句话，以便您早日知道：

• 如果您在 Windows 2012 中遇到应用程序问题，请幽默并在 Windows 2008 R2 中尝试。他们准备的一些 2012 图像中有几个错误。来回切换非常简单！
• 让您的日志记录比现在好 1000 倍。如果你现在不这样做，你会后悔的。
• 不要 100% 依赖于易于实施的“Azure 日志记录”。它工作得很好，但它或多或少需要您的应用程序成功启动，并且在调试启动问题时绝对没用。如果您没有其他选择，那么当您的应用程序启动时，您将浪费很多很多时间来调试愚蠢的小问题。当您完成它时，您可以轻松添加 5 个其他日志框架，并拥有一个非常棒的日志系统以及一个正在运行的应用程序，而不仅仅是一个正在运行的应用程序来显示相同​​的时间。真的，这样做！ （分析也是一个好主意，尽管如果您有多个实例，Mini-Profiler 会出现负载平衡问题。）
• 如果您将新端点添加到您的部署（端口等），您不能简单地“升级”现有部署。您必须删除它（部署，而不是服务）并从头开始安装。您可以删除 Staging 一个，部署到 Staging，然后交换。
• 如果您有 WCF 应用程序，请假装您不了解 Windows 激活服务。默认情况下，它们在 Azure 中被禁用。您可以破解它们以打开它们（启动脚本）或创建自己的自托管应用程序。我们自托管，因此我们可以在部署后更轻松地调整服务配置（以固定在 Azure 中的方式编辑 web.config 文件并不容易）。 Web 服务在 Azure 中的“IIS”中工作，但 TCP、命名管道等不能。
• 去了解并添加瞬态错误应用程序块（或等效的东西）到您与之通信的任何东西。如果你现在不这样做，你会后悔的。
• 让您的日志记录变得更好！真的，真的，真的要这样做！

将 SQL Server 数据库迁移到 Azure：

将您的数据库加入 Azure 是一个痛苦的过程。没有一种快速简便的方法可以将其安装到那里并使其工作。有些人必须做出一些重大改变，而另一些人只需要在这里和那里调整一些可忽略的事情。然而，无论你的数据库有多大或多小，你真的必须花很多时间来测试它。测试您的迁移过程。测试您的脚本以准备您的数据库。在云端测试数据库的性能和稳定性。测试您的备份程序。测试您的升级程序。测试您的备份恢复程序。测试所有这些，因为我保证你会发现一些惊喜！

架构：

• 了解 SQL Azure 的所有限制。没有堆等。在开始之前学习它们！现在就去学习吧！它们大多都非常合理。
• 注意 2GB T-Log 限制！这意味着一些非常大的索引永远无法重建！ （也就是说，我们的 30GB 表还没有达到这个目标）
• 要部署架构，请进入本地数据库的 SSMS 并使用“任务 -> 提取数据层应用程序...”功能（在不同版本的 SSMS 中位于菜单的不同区域）。获取此文件并进入 Azure 数据库的 SSMS 并使用“部署数据层应用程序”功能。 （如果此过程失败，这将帮助您捕获一些您不遵守的 Azure 限制。）到目前为止，这是将数据库的空版本放入 Azure 的最简单方法。
• 使用 Redgate SQL Compare 之类的工具来验证您的工作（您必须调整几个选项，例如 WITH NOCHECK 以获得清晰的比较）。
• 在您成功之前，您必须清理用户、模式、损坏的存储过程等。 （这是一件好事！）

数据：

• 了解 SQL Azure 的所有限制。在开始之前学习它们！现在就去学习吧！它们大多都非常合理。
• 从 Codeplex（或最新版本所在的任何位置）下载 Azure 数据库迁移向导。它不是最棒的软件（有点不稳定），但即使它在您身上崩溃一两次，它仍然可以为您节省大量时间！
• 我强烈推荐 RedGate 的 SQL 数据比较。前面提到的迁移向导将帮助您识别问题（由您来解决这些问题），并将让您迁移大约 98%，但您需要在它之后回来清理。它有一些错误会遗漏可空的 BIT 字段（和大写 ascii 字符）以及 SQL 数据比较等工具可以轻松识别和修复的其他一些东西。它还可以让您高枕无忧，您可以依赖您的数据库。
• 如果您的数据库很大，请考虑在 Azure 中启动一个临时 VM（他们预装了 SQL Server 并在大约 20 分钟内可用）来进行迁移。如果这样做，最好将压缩的数据库备份上传到 Blob 存储（Cerebrata 的存储也非常适合此操作），然后将其抓取并还原到该 VM 中的 SQL Server。然后从那里开始您的迁移！

测试，测试，测试！！！

Answer 2

在虚拟机上运行 SQL 时要小心，这不是高可用性解决方案。 Azure VM 很容易不时重新启动。除非您在可用性组中有多个运行 SQL Server 的 VM，或者您有某种镜像和负载平衡设置，否则您将没有高可用性解决方案。我最初也赞成 IaaS 到 PaaS 的路线，最后它似乎是一种虚假的经济，因为将 IaaS 迁移到 PaaS 与将内部部署迁移到 PaaS 的工作量差不多。最后我决定花时间优化我的 PaaS 应用程序，即将持久存储移动到 blob，实现瞬态错误处理和重试逻辑等。

您的提议当然是可行的，但是使用多 VM 安排来提供高可用性 SQL 需要一些工作并且成本高昂！阅读以下指南，当我开始迁移过程时，它对我很有帮助：

Top 7 Concerns of Migrating a .NET Application to Azure

Answer 3

就在昨天，微软宣布了他们计划在其 Azure 平台上托管 Iaas 解决方案，而不仅仅是 Saas 解决方案。 http://weblogs.asp.net/scottgu/archive/2013/04/16/windows-azure-general-availability-of-infrastructure-as-a-service-iaas.aspx

关于迁移，这真的取决于。我们使用一种分发机制：TFS + Octopus，因此部署非常简单，它可以在 Iaas 或 SQL Azure 上运行，这并不重要。 进入 Saas 时，还需要考虑其他事项。如果您的代码不是面向 Saas 的，或者您的应用程序可能比 Azure 具有非常高的托管成本，则可能应该重构您的代码。