azure 使用_使用Azure的低成本灾难恢复解决方案

azure 使用

We already talked a lot about Azure and hybrid deployments on this. In order to better understand this article I suggest the reading of the article “Azure Blob Storage – Placing database files in the cloud”, as the presented solution will be based on the same approach.

我们已经讨论了很多有关Azure和混​​合部署的内容。 为了更好地理解本文，我建议阅读文章“ Azure Blob存储–将数据库文件放置在云中 ”，因为提出的解决方案将基于相同的方法。

低成本灾难恢复解决方案的目标是什么？ (What’s the objective of a low-cost disaster recovery solution?)

Disaster… a sudden event, such as an accident or a natural catastrophe that causes great damage or loss of life. This is the word’s definition, and fits very well here… If you are in your job, and tsunami alert sounds, are you going to keep calm, get all the servers and run to a safer place OR are you going to run to your family and look to protect them (and yourself)?

灾难…突发事件，例如事故或自然灾害，会造成巨大的伤害或生命损失。 这是单词的定义，非常适合这里...如果您在工作中，并且海啸警报声响起，您要保持镇定，获取所有服务器并奔赴更安全的地方，还是要奔赴家人并希望保护他们（和自己）？

People are more important than processes, data, and hardware. And the natural behavior of anyone is to try to save lives, not computers. And that’s why a good disaster recovery plan is needed.

人比流程，数据和硬件更重要。 任何人的自然行为都是试图挽救生命，而不是计算机。 这就是为什么需要一个好的灾难恢复计划的原因。

But what is the definition of a “good disaster recovery plan”? There’s no exact answer, as it depends from case to case, but in general, a good disaster recovery plan must focus on:

但是，“好的灾难恢复计划”的定义是什么？ 没有确切的答案，这取决于具体情况，但总的来说，一个好的灾难恢复计划必须着重于：

• Minimum (even zero) data loss (RPO);
  最小（甚至零）数据丢失（RPO）；
• Very small recovery time (RTO);
  恢复时间非常短（RTO）；

Looking for those two factors, we can easily understand that a good plan cannot rely on human intervention. As said in the first part of this article, in a disaster, people will be trying to save their skins… and more, there’s no way to have someone ready to react so quick to avoid an extended downtime, so the zero-data-loss will be never net.

寻找这两个因素，我们可以很容易地理解，好的计划不能依靠人为干预。 如本文第一部分所述，在灾难中，人们将试图挽救自己的皮肤……而且，无法让某人准备如此Swift地做出React以避免延长停机时间，因此零数据丢失永远不会净。

Talking about SQL Server, we have some options to configure a DR solution. Like AlwaysOn Availability groups, Database Mirroring, log-shipping and even a complex combination of AlwaysOn Failover Cluster Instance and replicated storage in a multi-subnet environment. But here is the first problem…which one will we choose? The answer is the default for everything related to SQL Server: it depends. Not only the RPO and RTO are factors here: the database size, the database severity in the business point of view, the available infrastructure, the network performance – which is more critical when dealing with server on different locations, etc…

在谈论SQL Server时，我们有一些配置DR解决方案的选项。 像AlwaysOn可用性组一样，数据库镜像，日志传送甚至是AlwaysOn故障转移群集实例与多子网环境中的复制存储的复杂组合。 但是这是第一个问题……我们将选择哪个？ 答案是与SQL Server相关的所有事物的默认值：这取决于。 不仅RPO和RTO都是这里的因素：数据库大小，业务角度的数据库严重性，可用的基础结构，网络性能–在与不同位置的服务器打交道时，这尤其重要……

Those factors are the responsible for changing the price of your disaster recover strategy. The cheaper, the higher arr the RPO and the RTO. The more expensive, the lesser are the RPO and the RTO.

这些因素是导致更改灾难恢复策略价格的原因。 越便宜，RPO和RTO的收益就越高。 成本越高，RPO和RTO越少。

For big companies, it’s relatively easy to deploy, i.e., an AlwaysOn Availability Group, running on a powerful multi-subnet cluster.

对于大公司而言，部署相对容易，即在强大的多子网群集上运行的AlwaysOn可用性组。

This solution is not cheap, even without the requirement of a shared storage, you still need to have two datacenters (or rent a space to collocate your server), you need to maintain a powerful network with low latency (between distinct geo-locations) and pay the SQL Server Enterprise Edition license, which is not cheap, by the way.

此解决方案并不便宜，即使不需要共享存储，您仍然需要拥有两个数据中心（或租用空间来放置服务器），还需要维护低延迟的强大网络（在不同地理位置之间）并支付SQL Server Enterprise Edition许可，这并不便宜。

For any company, a micro or a macro, the value of the data is immeasurable.

对于任何公司，无论是微观公司还是宏公司，数据的价值都是无法衡量的。

I’ve heard stories of companies that broke because they didn’t do the basic disaster recovery practice: backups!

我听说过一些公司倒闭的故事，因为它们没有执行基本的灾难恢复实践：备份！

So, let’s go to the point of this article: low-cost disaster recovery.

因此，让我们转到本文的重点：低成本灾难恢复。

Why I would need a low-cost disaster recovery solution? Well, let’s pretend you jst created a startup company and you don’t have enough money to invest in everything that you would like. Years ago, you would be in trouble! Nowadays there is something that helps a lot: The Cloud!

为什么需要低成本的灾难恢复解决方案？ 好吧，让我们假装您最初创建了一家初创公司，但是您没有足够的资金来投资所需的一切。 多年前，您会遇到麻烦！ 如今，有些东西大有帮助：云！

You as an entrepreneur who cares about your company and customers, decides to create a disaster recovery solution for your current environment, but after building your dream diagram, you had to start cutting some points, because you had no budget… After all the cuts, talking about the database part, you end up with a log-shipping solution working in a VM, hosted by the same platform where your production is running! This is not a disaster recovery solution…

作为关心公司和客户的企业家，您决定为当前环境创建灾难恢复解决方案，但是在构建梦想图之后，由于没有预算，您不得不开始削减一些要点。谈到数据库部分，您最终将获得一个在VM中运行的日志传送解决方案，该解决方案由生产运行所在的同一平台托管！ 这不是灾难恢复解决方案……

Azure解决方案 (The solutions with Azure)

We already talked about backups to Azure in another article. That solution works very well and brings the capability of save your backup files in another location, far away from your datacenter. If you are still keeping your backups in the same datacenter as you have your server, you are doing this wrong. Check that article, and see how easy and cheap is to store your backups in the cloud.

我们已经在另一篇文章中讨论了到Azure的备份。 该解决方案效果很好，并具有将备份文件保存在远离数据中心的另一个位置的功能。 如果仍将备份与服务器保留在同一数据中心中，则说明您做错了。 查看该文章，了解将备份存储在云中有多么容易和便宜。

Now, literally talking about Disaster Recovery solutions, let’s see the options….

现在，从字面上谈论灾难恢复解决方案，让我们看看这些选择。

Option #1: I have money to invest, but not that much.

选择1：我有钱可投资，但没有那么多。

We have a solution for you! Where you won’t need to have another datacenter, you won’t need to hire extra staff to keep the new infrastructure and is easy to configure: AlwaysOn Availability Groups replica in Azure.

我们为您提供解决方案！ 在不需要其他数据中心的地方，不需要雇用额外的人员来保留新的基础结构，并且易于配置：Azure中的AlwaysOn可用性组副本。

Yes, this is possible, precisely, since SQL Server 2012 SP1 CU2+.

是的，正是因为SQL Server 2012 SP1 CU2 +，这才有可能。

Requirements:

要求：

• Already have an AG replica working on-premises.
  已经有一个AG副本在本地工作。
• An active Azure account (of course).
  一个有效的Azure帐户（当然）。
• here).一点 ）。

How to configure?

如何配置？

You have two option: manually or using the wizard.

您有两个选择：手动或使用向导。

If you opt to do this manually, the overall steps are:

如果您选择手动执行此操作，则总体步骤为：

1. • Install SQL Server, if you choose a clean template.
     如果选择干净的模板，请安装SQL Server。
2. Join the VM into the domain
   将虚拟机加入域
3. Add the VM as cluster node
   将VM添加为群集节点
4. Enable HADR feature.
   启用HADR功能。
5. Join the instance as AG replica
   作为AG副本加入实例
6. Start syncing the databases
   开始同步数据库

If you choose the wizard, the task is way simpler… Just follow the steps and everything will be fine!

如果选择向导，则任务将变得更加简单……只需按照以下步骤操作，一切都会好起来！

Option #2: I’m counting coins, but I really need a disaster recovery solution…

选项2：我在数硬币，但我确实需要灾难恢复解决方案…

Well, you don’t have all the budget that you would like to, and you are ok in have a high RTO and an a not zero data loss (RPO). This solution is for you!

好吧，您没有想要的所有预算，并且可以拥有较高的RTO和不为零的数据丢失（RPO）。 此解决方案适合您！

Basically we will be taking advantage of two Azure features: Azure VM and Azure Blob Storage.

基本上，我们将利用Azure的两个功能：Azure VM和Azure Blob存储。

The idea is very simple:

这个想法很简单：

• You have your physical server on premises
  您在本地拥有物理服务器
• • this article本文章
  • Note #2: If you don’t want to have your database in Azure Blob Storage, you can work around this by having a replica of your database attached in the same instance (with another name), with the files in Azure
    注意＃2：如果您不希望将数据库存储在Azure Blob存储中，则可以通过在同一实例（具有另一个名称）中附加数据库的副本以及Azure中的文件来解决此问题。
• • This VM should have scripts ready to attach the database file that are in Azure Blob Storage
    此VM应该已准备好脚本来附加Azure Blob存储中的数据库文件
  • You can also script out the instance objects, on daily basis, and store the scripts in Azure Blob Storage. After that you just need to create a job to be triggered once SQL Server start-up and execute the scripts
    您还可以每天编写脚本出实例对象，并将脚本存储在Azure Blob存储中。 之后，您只需要创建一个作业即可在SQL Server启动后触发并执行脚本
  • After deploying this VM, and prepare everything, you just shutdown the VM in order to reduce costs
    部署此虚拟机并准备好一切之后，只需关闭虚拟机即可降低成本
• In case of a disaster, you will lose your server on-premises, but your files will be safe in Azure, and you just need to start-up the VM nd redirect the connections to that Virtual Machine
  万一发生灾难，您将在本地丢失服务器，但是文件在Azure中将是安全的，您只需要启动VM并将连接重定向到该虚拟机即可

Of course, this is not the best solution, but works well and is really low-cost. That’s Azure flexibility!

当然，这不是最好的解决方案，但效果很好，而且成本很低。 这就是Azure的灵活性！

I hope you liked it… Keep tuned for more articles. “See” you in another post.

希望您喜欢它。敬请期待更多文章。 在另一篇文章中“看到”您。

翻译自: https://www.sqlshack.com/low-cost-disaster-recovery-solution-using-azure/

azure 使用