解决了

存储节点体系结构

  • 2021年1月27日
  • 8个答复
  • 558次观看
t
徽章 +2

Nutanix存储节点可以包含比群集节点磁盘上现有容量的辅助VM副本更多的辅助VM副本吗？如果是，如何将存储节点放下以进行维护？

图标

最好的答案戴维2021年1月28日，20:57

I believe, and might double check this w Support\/Sales Engineers - in the situation you describe the VMs would continue to functions\/run (no outage of them executing\/reading\/writing to disk) however the cluster\u2019s resiliency would stay Critical (it doesn\u2019t have enough pool capacity to write 2nd copies) until the storage heavy node is back up (i.e. couldn\u2019t loose any additional disk\/nodes\/blocks).<\/p>

\u00a0<\/p>

This is one of the reasons why Storage-heavy nodes need to be added to a cluster in pairs, so storage un-balances during HA events don\u2019t end up causing, \u201csufficient_disk_space_check\u201d warnings.<\/p>

Note <\/strong>that the number of storage heavy nodes may need to be more if you\u2019re using RF=3<\/p>

https:\/\/portal.nutanix.com\/page\/documents\/kbs\/details?targetId=kA0600000008gVyCAI<\/a><\/p>

\u00a0<\/p>","className":"post__content__best_answer"}">

查看原件
Can a Nutanix Storage node contain more secondary VM copies than what would fit into the existing capacity on the cluster nodes disk? and if yes, how does one bring the storage node down for maintenance?\u00a0\u00a0<\/p>","quoteUsername":"theGman","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
该主题已关闭以供评论

8个答复

阿罗纳
秩
UserLevel 6
徽章 +5

你好 @Thegman

来自Prism Web控制台指南：仅存储节点配置

如果仅存储节点失败，请确保群集具有足够的容量。

您的群集必须具有足够的能力来处理升级操作，在此期间重新启动节点。

群集中仅存储节点的最小数量必须等于群集的复制因子（RF）。例如，如果群集的RF为两个，请至少添加两个仅存储节点。如果群集的RF为三个，请至少添加三个仅存储节点。

假设您的意思是仅存储而不是存储较重的节点，则仅存储节点不会存储多个与此相同数据的副本，这与弹性无助。因此，建议仅存储节点的数量等于RF因子。这样，每个仅存储节点将具有数据的副本。

存储节点维护过程与常规节点没有区别，除了没有VM可以迁移该节点的事实。

Hi @theGman<\/user-mention>\u00a0<\/p>

From the Prism Web Console Guide: Storage-only Node Configuration<\/a><\/p>

Ensure that your cluster has sufficient capacity if a storage-only node fails.<\/p>

Your cluster must have sufficient capacity to handle the rolling-upgrade operations during which nodes are restarted.<\/p>

The minimum number of storage-only nodes in your cluster must be equal to the replication factor (RF) of your cluster. For example, if the RF of your cluster is two, add at least two storage-only nodes. If the RF of your cluster is three, add at least three storage-only nodes.<\/p><\/blockquote>

Assuming that you meant storage-only and not storage-heavy nodes, a storage-only node will not store multiple copies of the same data as this does not help resilience. Hence the recommendation to have the number of storage-only nodes equal to RF factor. In that way, each storage-only node will have a copy of the data.<\/p>

Storage node maintenance process does not differ from a regular node except for the fact that there will be no VMs to migrate off the node.<\/p>","quoteUsername":"Alona","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

t
徽章 +2

你好 @Alona

我确实意味着存储重量，而不仅仅是存储，但是现在您将此选项提升了……。

使用Nutanix VM的群集在HA的集群中写成2倍，所以如果我错了，请纠正我，但是存储节点的目的是容纳更多的次要副本，不是吗？So what I’m looking for is an understanding of how to bring down the storage heavy node, or the storage only node, for maintenance, when there isn’t enough local disk capacity within the cluster to house the secondary copies stored on the storage node.

For storage only nodes you state that you wouldn’t want just a single instance, so that makes sense to a degree, especially if you have some VMs that has a very large disk requirement that would eat up all the storage on a single node, after all the cluster requires 2 copies of these VMs. What I’m looking for is the “how does this work” ..

我想了解在维护事件中，所有VM是否在集群中都具有HA功能，我认为，在放下存储节点时，需要将数据转移到周围。我的问题是，如果剩余的本地磁盘上没有足够的容量来编写此数据，那么该阈值如何跟踪。在我看来，在这种情况下，在这种情况下，某些VM可能需要一些停机时间。

Hi @Alona<\/user-mention>\u00a0<\/p>

I do actually mean storage heavy, not storage only, but now that you bring this option up\u2026.\u00a0<\/p>

With Nutanix VMs are written 2x within the cluster for HA, so correct me If I\u2019m wrong but the purpose of storage node is to house more of the secondary copies is it not?\u00a0 \u00a0 \u00a0So what I\u2019m looking for is an understanding of how to bring down the storage heavy node, or the storage only node, for maintenance, when there isn\u2019t enough local disk capacity within the cluster to house the secondary copies stored on the storage node.\u00a0\u00a0\u00a0\u00a0<\/p>

For storage only nodes you state that you wouldn\u2019t want just a single instance, so that makes sense to a degree, especially if you have some VMs that has a very large disk requirement that would eat up all the storage on a single node, after all the cluster requires 2 copies of these VMs.\u00a0 What I\u2019m looking for is the \u201chow does this work\u201d ..\u00a0\u00a0<\/p>

I want to understand whether during a maintenance event\u00a0all the VMs continue to have HA capability\u00a0within the cluster, and I would think in order for this to happen data would need to be moved around when bringing down the storage node.\u00a0 My question is what if there isn\u2019t enough capacity across the remaining local disk to write this data, and how is this threshold tracked.\u00a0 \u00a0It seems to me like this scenario might require some downtime for some VMs to make this happen in this case.\u00a0<\/p>","quoteUsername":"theGman","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

戴维
UserLevel 2
徽章 +4

I believe, and might double check this w Support/Sales Engineers - in the situation you describe the VMs would continue to functions/run (no outage of them executing/reading/writing to disk) however the cluster’s resiliency would stay Critical (it doesn’t have enough pool capacity to write 2nd copies) until the storage heavy node is back up (i.e. couldn’t loose any additional disk/nodes/blocks).

这就是需要成对添加存储较重的节点的原因之一，因此HA事件期间的存储平衡不会最终导致“ suffitife_disk_space_check”警告。

笔记如果您使用rf = 3，则存储重量节点的数量可能需要更多

https://portal.nutanix.com/page/documents/kbs/details?targetId=KA0600000008GVYCAI

I believe, and might double check this w Support\/Sales Engineers - in the situation you describe the VMs would continue to functions\/run (no outage of them executing\/reading\/writing to disk) however the cluster\u2019s resiliency would stay Critical (it doesn\u2019t have enough pool capacity to write 2nd copies) until the storage heavy node is back up (i.e. couldn\u2019t loose any additional disk\/nodes\/blocks).<\/p>

\u00a0<\/p>

This is one of the reasons why Storage-heavy nodes need to be added to a cluster in pairs, so storage un-balances during HA events don\u2019t end up causing, \u201csufficient_disk_space_check\u201d warnings.<\/p>

Note <\/strong>that the number of storage heavy nodes may need to be more if you\u2019re using RF=3<\/p>

https:\/\/portal.nutanix.com\/page\/documents\/kbs\/details?targetId=kA0600000008gVyCAI<\/a><\/p>

\u00a0<\/p>","quoteUsername":"DavidN","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

t
徽章 +2

谢谢大卫 - 这很有意义，为什么当它仍然可以在关键模式下运行时将其完全放下……您只需要及时完成工作即可。:)

因此，一个好的体系结构利用存储重型节点将包括一个JBOD，它允许1个以上的服务器在两个存储较重节点之间适当地连接和分配磁盘。

Thanks David - this makes sense, why bring it down completely when it can still run in critical mode\u2026\u00a0you just have to get the work done in a timely manner just in case.\u00a0 :)\u00a0\u00a0<\/p>

\u00a0<\/p>

So a good architecture that leverages storage heavy nodes would include\u00a0\u00a0a JBOD\u00a0 that allows for more than 1 server to connect and divi up the disk appropriately between the 2 storage heavy nodes..\u00a0\u00a0<\/p>","quoteUsername":"theGman","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

戴维
UserLevel 2
徽章 +4

我强烈建议您查看/使用“ nutanix sizer”来帮助您这样的右尺寸工作量……这将有助于说明像这样的一些细微差别。


考虑到重新复制的量，您可能需要将CVM/存储流量与来宾VM流量分开，并取决于在节点中使用10GB+ NIC的所讨论数据量……以帮助策展人进行弹性扫描。

对于一些背景检查：

https://nutanixbible.com/“意识条件和容忍度”部分

https://portal.nutanix.com/page/documents/kbs/details?targetId=KA0600000008I1DCAA

https://next.nutanix.com/how-it-works-22/curator-scans-types-and-frequency-frequency-requency-where-is-is-is-s-re-free-space-33516

I would highly recommend looking at\/using the \u201cNutanix Sizer\u201d to help you right-size workloads like this\u2026\u00a0It\u2019ll help account for some nuances like this.<\/p>


Given the amount of re-replication, you may want to separate CVM\/Storage traffic from Guest VM traffic and depending on the amount of data in question to use 10Gb+ nics in the nodes\u2026\u00a0to help curator with resiliency scans.<\/p>

\u00a0<\/p>

For some background check out:\u00a0<\/p>

https:\/\/nutanixbible.com\/<\/a>\u00a0 section \u201cAwareness Conditions and Tolerance\u201d<\/p>

\u00a0<\/p>

https:\/\/portal.nutanix.com\/page\/documents\/kbs\/details?targetId=kA0600000008i1dCAA<\/a><\/p>

\u00a0<\/p>

https:\/\/next.nutanix.com\/how-it-works-22\/curator-scans-types-and-frequency-or-where-is-our-free-space-33516<\/a><\/p>","quoteUsername":"DavidN","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

t
徽章 +2

嗨，大卫 - 感谢您的答复。至于将存储与VM流量分开，这意味着每个节点又有2个10GB端口（现在您需要每个主机的4个上游端口），如果您按照切换成本和数据中心硬件进行数学来缩放HCI，那么您很快就需要请参阅该模型从成本的角度分开。您可能会避免在此堆栈中有一个数组，但是缺乏网络合并，并且需要为每个节点许可，在扩展时会迅速赶上。

Hi David - thanks for\u00a0 your replies.\u00a0 As for separating storage from VM traffic, well,\u00a0 this means 2 more 10GB ports per node (Now you need 4 upstream ports for each host), and if you do the math on the cost of switching and datacenter hardware required for scaling HCI you soon see that this model falls apart from a cost perspective.\u00a0 \u00a0You might avoid an array in this stack but the lack of network consolidation, along with a need to license for each node,\u00a0catches up fast as you expand.\u00a0\u00a0\u00a0<\/p>","quoteUsername":"theGman","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
戴维
UserLevel 2
徽章 +4

哦，我很清楚各种供应商的“每10GB端口许可”……。you could employ basic VLAN separation of CVM/ESXi from Guest VM traffic and use other methods to “tier” your Guest VM traffic… I doubt many guest OS’ can saturate a 10Gb link for long, so ‘sharing’ storage & guest vm traffic on host uplinks is a small price to pay. (This of course totally depends on the types of loads you have - you know those best.)

就缩放而言……我不知道其他3层系统缩放和HCI（对于每个节点，您可以选择根据添加的节点来缩放簇IO/存储或计算）。

我去过那里（3层系统）并完成了数学（粉丝/扇出比例，分区糟糕的比率，欺负VM和“管理SSD Cache” - 实际上……不想真正想要返回。）
不要相信我的话……建议您阅读Josh Odgers（http://www.joshodgers.com/）

我也会推荐您可以与Nutanix的销售工程师保持联系，并确定您的需求和疑虑。详细信息就是全部内容，并且考虑到有多少系统具有参考文献文档和Nutanix上的100％支持性，我敢肯定，有一个适合您预算的解决方案！

Oh, I\u2019m well aware of various vendor\u2019s \u201cper 10Gb port licenses\u201d\u2026. you could employ basic VLAN separation of CVM\/ESXi from Guest VM traffic and use other methods to \u201ctier\u201d your Guest VM traffic\u2026\u00a0I doubt many guest OS\u2019 can saturate a 10Gb link for long, so \u2018sharing\u2019 storage & guest vm traffic on host uplinks is a small price to pay. (This of course totally depends on the types of loads you have - you know those best.)\u00a0
\u00a0<\/p>

As far as scaling\u2026\u00a0I don\u2019t know of any other 3-tier system that scales as well as HCI (for each node you add you have a choice to scale the clusters IO\/storage or compute depending on nodes you add).<\/p>

I\u2019ve been there (3-tier systems) and done the math (fan-in\/fan-out ratios, zoning oopsies, bully VMs\u00a0and \u201cmanaging SSD cache\u201d\u00a0-manually\u2026\u00a0not really wanting to go back.)
Don\u2019t take my word for it\u2026\u00a0recommend some reading by Josh Odgers (http:\/\/www.joshodgers.com\/<\/a>)\u00a0<\/p>

\u00a0<\/p>

I would also recommend <\/strong>you get in touch w a Nutanix Sales Engineer and work out your needs & concerns. Details is what it\u2019s all about and given how many systems have reference documents & 100% supportability on Nutanix, I\u2019m sure there is a solution that\u2019s right for your budget!<\/p>","quoteUsername":"DavidN","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

t
徽章 +2

谢谢大卫 - 感谢您的回答。结束时，当需要快速扩展时，HCI很棒，您可以同时扩展计算和存储，而不必担心存储前端。但这并不是HCI带来的最好的好处。我认为它的预先自动化，合并为单个堆栈，其操作效率使其更容易管理。我将指出我们自己的基础设施中的一些事情，这些基础设施是HCI和传统W集中式阵列的混合组合：1。许多组织不需要扩展，实际上正在减少其足迹。HCI doesn’t provide the flexibility to reduce a footprint without a bit of challenge, if you have moved a large # of workloads to the cloud and no longer require the compute power you can’t just pull a couple of nodes away without addressing the reduction is storage that would accompany a compute reduction. #2, we run over 50 hypervisor nodes with about 35 VMs each against a single array and see an average of .5ms latency with very little spiking above 10ms, but our Nutanix deployments average 2ms latency with a substantial amount of spiking that far exceeds the what our centralized array exhibits, and these specific hosts don’t run ½ the # of VMs per host as our non HCI clusters do. I certainly understand the value of what HCI brings to the table and it is a perfect fit for some organizations but not so much for others.

Thanks David - I appreciate your responses.\u00a0 \u00a0In closing, HCI is great when rapid expansion is called for, you get to expand compute and storage simultaneously without concern of a storage front end.\u00a0 But this is hardly the best of the benefits HCI brings to the table in my opinion.\u00a0 I would argue its the pre-canned automation,\u00a0consolidation into a single stack, with its operational efficiencies\u00a0that make it easier to manage.\u00a0 \u00a0\u00a0\u00a0I will point out a few things from our own infrastructure which is a hybrid mix of HCI and traditional w centralized array:\u00a0 1.\u00a0 many organizations don\u2019t need to expand and are in fact reducing their footprint.\u00a0 HCI doesn\u2019t provide the flexibility to reduce a footprint without a bit of challenge, if you have moved a large # of workloads to the cloud and no longer require the compute power you can\u2019t just pull a couple of nodes away without addressing the reduction is storage that would accompany a compute reduction.\u00a0 \u00a0#2, we run over 50 hypervisor nodes with about 35 VMs each against a single array and see an average of .5ms latency with very little spiking above 10ms, but our Nutanix deployments average 2ms latency with a substantial amount of spiking that far exceeds the what our centralized array exhibits, and these specific hosts don\u2019t run \u00bd\u00a0the # of VMs per host as our non HCI clusters do.\u00a0 \u00a0I certainly understand the value of what HCI brings to the table and it is a perfect fit for some organizations but not so much for others.\u00a0\u00a0<\/p>","quoteUsername":"theGman","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
Baidu