解决了

将SQL VM从ESXI移动到AHV

l
  • 金
  • 旅行者
  • 2个答复
我们在ESXI群集上有几个生产SQL服务器，需要将其过渡到我们的新Nutanix群集。Nutanix的最佳实践表明，应该在Nutanix群集上创建新的SQL服务器，而不是从ESXI转移到AHV。

我知道Nutanix已经有一段时间的Xtract DB，这应该使SQL实例成为可能，但此后它们停止了该产品。我必须假设他们有问题。

我的问题是，使用Nutanix移动将SQL VM从ESXI移动到AHV有什么技术含义？我已经使用该工具来移动许多非SQL VM，没有任何问题。知道底层高探针组件正在发生变化，并且必须在移动前安装Virtio驱动程序，然后在移动后安装NGT，该问题可能会阻止或阻止SQL VM vm跨速度visor移动？

SQL版本是2016年的标准，无镜像或始终进行可用性。只是独立的SQL。我们在一个实例中有大约10个数据库和许多作业。实例大小是数百GB的数据和日志。
图标

最好的答案jlaunier2019年4月8日，18:29

@limin<\/user-mention> , It depends on your SQL Server. Move can't migrate multi-writer VMDKs or any VMs with pRDMs. So migration of SQL clusters using Move is almost guaranteed to be problematic. If your SQL instance is standalone and not relying on any disks exposed directly to the OS, pRDM\/iscsi LUNs, Move should be able to migrate it. Your point is valid though. The other key reason we do not recommend this is that Move is a like for like migration. It doesn't take into account disk layout changes or other BPs that we recommend for databases. So yes, it can be used for restricted SQL Server migration use cases but is not a good idea for most scenarios.","className":"post__content__best_answer"}">
查看原件
\r\n
\r\nI am aware that Nutanix had Xtract Db for awhile that was supposed to make moving a SQL instance possible but they have since discontinued the product. I must assume they had issues with it.
\r\n
\r\nMy question is what are the technical implications of using Nutanix Move to \"move\" the SQL VM from ESXi to AHV? I have used the tool to move a number of non-SQL VMs without any issues. Knowing that the underlying Hyper-visor components are changing and the VirtIO drivers must be installed before the move and then NGT installed after the move, what might the issue be that discourages or prevents a SQL VM cross-hyper-visor move?
\r\n
\r\nThe SQL version is 2016 Standard with no mirroring or Always on Availability. Just standalone SQL. We have about 10 databases within a single Instance and many jobs. Instance size is several hundred GBs of data and logs.","quoteUsername":"limin","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
该主题已关闭以供评论

6个答复

阿卢西亚尼
UserLevel 7
徽章 +34
你好 @limin

我认为 @Jlaunier可以在这里帮助分享一些见识
在Twitter上关注我：https：//twitter.com/angeloluciani
@limin<\/user-mention>
\r\n
\r\nI think @jlaunier<\/user-mention> can help share some insight here","quoteUsername":"aluciani","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
l
是的，我在原始帖子之前读了该线程。关于使用移动迁移SQL的所有真正指示的是，它不允许进行SQL设计更改。例如正确使用虚拟磁盘，文件等。但实际上，这与直接的V2V移动无关。

这一切都使我相信使用移动从ESXI到AHV进行SQL移动没有真正的技术问题。而且，Nutanix对SQL Server的正确设计感到非常强烈，以至于他们不会对使用移动进行直接V2V迁移的可行性发表评论。恕我直言，这是可悲的。我还应该说，我已经与Nutanix有关此问题的投入的支持，并得到了“遵循最佳实践”的答案。我没有询问我们的SQL Server是否已经按照最佳实践进行设计。一个工程师给出这样的答案，而没有任何理由就没有任何帮助。

爱我的Nutanix群集，但由于缺乏可靠的产品使用答案而感到沮丧。
\r\n
\r\nThis has all lead me to believe there is no real technical issues in using Move to perform a SQL move from ESXi to AHV. And that Nutanix feels so strongly about the proper design of a SQL server that they will not comment on the feasibility of using MOVE to perform a straight V2V migration. IMHO that is sad. I should also say that I have reached out to Nutanix support for input on this question and was given a an answer of \" follow best practices\". I wasn't asked whether or not our SQL server was already designed following best practices. An Engineer giving an answer like that with no reasoning behind it is no help at all.
\r\n
\r\nLove my Nutanix Cluster, but frustrated with lack of solid product usage answers.","quoteUsername":"limin","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
j
秩
UserLevel 3
徽章 +9
@limin，这取决于您的SQL Server。移动无法迁移多作者VMDK或使用PRDMS的任何VM。因此，使用移动的SQL簇迁移几乎可以肯定会出现问题。如果您的SQL实例是独立的，并且不依靠直接暴露于OS的任何磁盘，PRDM/ISCSI LUNS，则移动应该能够迁移。您的观点是有效的。我们不建议这样做的另一个关键原因是，移动是类似的迁移。它没有考虑到磁盘布局更改或我们为数据库推荐的其他BP。因此，是的，它可用于限制的SQL Server迁移用例，但对于大多数情况来说不是一个好主意。
@limin<\/user-mention> , It depends on your SQL Server. Move can't migrate multi-writer VMDKs or any VMs with pRDMs. So migration of SQL clusters using Move is almost guaranteed to be problematic. If your SQL instance is standalone and not relying on any disks exposed directly to the OS, pRDM\/iscsi LUNs, Move should be able to migrate it. Your point is valid though. The other key reason we do not recommend this is that Move is a like for like migration. It doesn't take into account disk layout changes or other BPs that we recommend for databases. So yes, it can be used for restricted SQL Server migration use cases but is not a good idea for most scenarios.","quoteUsername":"jlaunier","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
l
@Jlaunier这是有用的信息。我们的SQL服务器没有暴露任何磁盘，等等。尽管在Nutanix平台上，性能可能存在问题，但我不知道。也许您可以照亮它。

我读到它们是每个虚拟磁盘的单个OPLOG，这是实现多个磁盘的原因之一。我还不了解Oplogs，但这也许对我们来说是一个问题。在我们的实例中，我们有大约10个DB。当然，有些人比其他忙。当前的实现将单个磁盘用于日志，数据和温度。Nutanix BP建议根据情况，最多8个虚拟磁盘。我们的Nutanix群集是一个混合动力1465 G6，每个节点上的SSD为1.92GBS。如果我正确理解OPLOG函数，那么所有DBS都有一个数据磁盘可能是一个争夺问题。

通过移动，我们可以将其转移到Nutanix群集，并在需要时添加虚拟磁盘，并将一些DBS移至它们。

我们正在实时紧缩，以使SQL服务器从现有平台移出新的Nutanix群集。因此，我正在权衡“从头开始构建”与以后可能进行修改的动作的时间。
@jlaunier<\/user-mention> This is the kind of info that is helpful. Our SQL Servers do not have any disks exposed, etc. There may be an issue with performance though on the Nutanix platform but I don't know. Maybe you can shine some light on it.
\r\n
\r\nI have read that their is a single OPLog per virtual disk which is one reason to implement multiple disks. I don't fully understand OPLogs yet, but perhaps this poses a an issue for us. We have about 10 DBs within our instance. Some busier than others of course. The current implementation uses individual disks for logs, data, and temp. Nutanix BP suggests IIRC up to 8 virtual disks depending on situation. Our Nutanix cluster is a Hybrid 1465 G6 with 1.92GBs SSD on each node. If I understand the OPLog function correctly, having a single data disk for all the Dbs could be a contention problem.
\r\n
\r\nWith Move we could transfer to the Nutanix cluster and if needed add virtual disks where needed and move some of the DBs to them.
\r\n
\r\nWe are under a real time crunch to get the SQL servers moved off of the existing platform to the new Nutanix cluster. So I am weighing the time for a \"build from scratch\" vs. a Move with possible modifications afterwards.","quoteUsername":"limin","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
b
徽章
这是回答的吗？？？
我也被告知相信我们可以使用MOVE将VM（应用，SQL和Exchange）从ESXI移动到AHV。现在我不确定。因此，我面对每年保持VMware而不是AHV的额外费用。这是卖点之一， /或Nutanix销售经理知道这一点，但从未透露可能的问题。
确实归结为这一点，Nutanix可以从ESXI到AHV迁移我们现有的SQL服务器吗？？？
\ni too was told to believe that we can move our VMs (application, SQL and Exchange) from ESXi to AHV using MOVE. Now I am not sure. So I am faced with keeping VMware and not AHV with added costs each year. This was one of the selling points and or Nutanix sales manager knew this but never disclosed the possible issue.
\nit really comes down to this, can Nutanix migrate our existing SQL servers in their entirety from ESXi to AHV???","quoteUsername":"Bmcgrath","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
j
秩
UserLevel 3
徽章 +9
@bmcgrath如上所述，只要您不使用PRDMS或Multi-Writer VMDKS作为Microsoft Failover群集的一部分，就可以使用移动来迁移DB VM以及将VMS交换为AHV。我们建议您在迁移后使用磁盘布局最佳实践的这些类型的应用程序。对于SQL Server，即使是相对直接的备份/还原仍然会导致源数据库服务器的原始磁盘布局，因此，无论您是否使用移动，您仍然需要按照我们的最佳方式添加所需的磁盘数量练习，然后通过迁移后通过DB收缩操作重新平衡数据。为了交换，它有些细微差别。虽然可以使用移动，但是构建新的Exchange服务器然后在邮箱级别迁移到新服务器可能更实用。
@Bmcgrath<\/user-mention> as I mentioned above, Move can be used to migrate DB VMs as well as Exchange VMs to AHV as long as you aren't using pRDMs or multi-writer VMDKs as a part of a Microsoft failover cluster. We recommend that for these types of applications that you apply disk layout best practices after migration. In the case of SQL server, even a relatively straight forward backup\/restore still results in the original disk layout of the source DB server, so whether you use Move or not, you will still want to add the needed number of disks per our best practices and then re-balance your data via db shrink operations after the migration. For Exchange it is a bit more nuanced. While it may be possible to use Move, it may be more practical to build a new Exchange server and then migrate at the mailbox level over to the new server.","quoteUsername":"jlaunier","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
条款和条件
Learn more about our cookies.<\/a>","cookiepolicy.button":"Accept cookies","cookiepolicy.button.deny":"Deny all","cookiepolicy.link":"Cookie settings","cookiepolicy.modal.title":"Cookie settings","cookiepolicy.modal.content":"We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.<\/a>","cookiepolicy.modal.level1":"Basic
Functional","cookiepolicy.modal.level2":"Normal
Functional + analytics","cookiepolicy.modal.level3":"Complete
Functional + analytics + social media + embedded videos"}}}">
Baidu