我忙于安装一个6节点群集，出现一些错误或疑问。
我的环境：3个块，6个节点（2个节点/块）AOS 4.6.2
一。当我创建一个新容器时，请检查启用擦除编码按钮，错误会弹出“启用EC-X将破坏当前的块意识！”似乎ECX会禁用块水平意识吗？
二。正如我们许多人所知道的那样，如果需要找到磁盘的物理插槽位置，则可以简单地在该驱动器上引导。但是在功能不准确或禁用的功能可能存在可能性，在这种情况下，您必须通过磁盘ID规则找到磁盘，例如架子ID.Slot/bay ID，但是Prism硬件中的磁盘ID似乎是RAMDOR/RUL -RULENES NOUME，我可以，我可以`t找到磁盘的物理位置。
三。当我进行有关从Nutanix群集中删除节点的测试时，出现疑问：我需要还是在删除节点之前执行存储VMotion（另一个仅是VMOTION VMS）的最佳实践？我认为两种方法的差异是谁是数据推动者，一个是esxi svmotion，另一个是CVM RF？也许我完全错了，即使我选择了SVMotion，RF恢复仍然发生？谢谢你们宝贵的时间，并提前帮助！
四。我第一次启用RF3，在Somes几天后，用户想恢复为RF2，Nutanix是否支持这一点？我知道我可以在线将RF2更改为RF3；
RF的另一种情况：当我使用基础工具映像节点时，我选择默认的RF2，并且可以通过NCLI命令启用RF3支持吗？（我注意到NCLI中有相关命令）
同样，我可以启用EC-X并再次禁用它吗？我想知道可以更改两次或多次更改的通用功能，除了一个更改是永久性的。
谢谢社区朋友！
最好的答案乔恩
RE ECX<\/b>
\nYes, ECX and block awareness do not mix. There is a long technical explanation of why, but the short of it is that the majority of customers who would use ECX wouldn't have enough physical blocks to actually enforce block awareness on ECX data (due to the different way that ECX stores blocks on disk), so we have delayed working on making the two work together as of now.
\n
\nRE Physical disk LED \/ finding a disk<\/b>
\nThe disk ID is really an \"internal\" construct, do not pay much attention to it.
\n
\nIf the LED on a disk was not working, or perhaps a HDD was 100% \"dead\" and the disk was just 100% offline, you would just simply look for the node that it is attached to (which is visibile in the Prism hardware display diagram) and go to that physical node and remove it.
\n
\nAlternatively, You could flash the LED on that node as well, which would help, OR perhaps flash all of the LED's of the disks around the dead disk, so that the dead disk stands out as \"not flashing\"
\n
\nIf there was any doubt, you would compare the serial number from the Disk in Prism to the physical one printed on the drive to double check.
\n
\nThis is the general approach for almost all storage systems.
\n
\nRE Removing a node<\/b>
\nYou do not need to svMotion anything at all. The CVM's will move the data off that node.
\n
\nEven if you did \"svMotion\" all of those VM's, you'd still have data on that CVM before it is removed from the cluster, as it is a part of the clusters overall capacity, so the svMotion literally doesn't do anything but waste time.
\n
\nJust regular vMotion the VM's to another node first, then remove the node using Prism and wait for the task to complete.
\n
\nRE RF3 to RF2 change<\/b>
\nAre you talking at the cluster level? or the container level?
\n
\nCluster level can not be changed back. I *think* the container level can be changed back, but I've never tried it. Absolute worst case, just provision another container at RF2 and storage vMotion the data.
\n
\nThat said, this question is one of those that you should really think through before arbitrarily changing. This is why the \"change RF\" command is NCLI only, and not in the GUI.
\n
\nRE Foundation RF2<\/b>
\nThis is setting up the \"cluster level\" RF, but regardless of foundation, if you have a cluster that is RF2, you can go to RF3 with NCLI, yes.
\n
\nRE Enable\/Disable ECX<\/b>
\nSure, you can change that all you want. Just note that encoded data will stay encoded until the data is overwritten.
\n
\nThis is slightly different behavior than enable\/disable compression, which does actively compression\/decompress data when the setting is changed.","className":"post__content__best_answer"}">
查看原件
\nYes, ECX and block awareness do not mix. There is a long technical explanation of why, but the short of it is that the majority of customers who would use ECX wouldn't have enough physical blocks to actually enforce block awareness on ECX data (due to the different way that ECX stores blocks on disk), so we have delayed working on making the two work together as of now.
\n
\nRE Physical disk LED \/ finding a disk<\/b>
\nThe disk ID is really an \"internal\" construct, do not pay much attention to it.
\n
\nIf the LED on a disk was not working, or perhaps a HDD was 100% \"dead\" and the disk was just 100% offline, you would just simply look for the node that it is attached to (which is visibile in the Prism hardware display diagram) and go to that physical node and remove it.
\n
\nAlternatively, You could flash the LED on that node as well, which would help, OR perhaps flash all of the LED's of the disks around the dead disk, so that the dead disk stands out as \"not flashing\"
\n
\nIf there was any doubt, you would compare the serial number from the Disk in Prism to the physical one printed on the drive to double check.
\n
\nThis is the general approach for almost all storage systems.
\n
\nRE Removing a node<\/b>
\nYou do not need to svMotion anything at all. The CVM's will move the data off that node.
\n
\nEven if you did \"svMotion\" all of those VM's, you'd still have data on that CVM before it is removed from the cluster, as it is a part of the clusters overall capacity, so the svMotion literally doesn't do anything but waste time.
\n
\nJust regular vMotion the VM's to another node first, then remove the node using Prism and wait for the task to complete.
\n
\nRE RF3 to RF2 change<\/b>
\nAre you talking at the cluster level? or the container level?
\n
\nCluster level can not be changed back. I *think* the container level can be changed back, but I've never tried it. Absolute worst case, just provision another container at RF2 and storage vMotion the data.
\n
\nThat said, this question is one of those that you should really think through before arbitrarily changing. This is why the \"change RF\" command is NCLI only, and not in the GUI.
\n
\nRE Foundation RF2<\/b>
\nThis is setting up the \"cluster level\" RF, but regardless of foundation, if you have a cluster that is RF2, you can go to RF3 with NCLI, yes.
\n
\nRE Enable\/Disable ECX<\/b>
\nSure, you can change that all you want. Just note that encoded data will stay encoded until the data is overwritten.
\n
\nThis is slightly different behavior than enable\/disable compression, which does actively compression\/decompress data when the setting is changed.","className":"post__content__best_answer"}">
