Azure service fabric 本地服务结构添加节点和节点类型关联

我有一个2节点的本地windows群集，群集清单中有以下节点定义

 "nodes": [
  {
    "nodeName": "node1",
    "iPAddress": "192.168.1.1",
    "nodeTypeRef": "node1",
    "faultDomain": "fd:/dc1/r1",
    "upgradeDomain": "UD1"
  },
  {
    "nodeName": "node2",
    "iPAddress": "192.168.1.2",
    "nodeTypeRef": "node2",
    "faultDomain": "fd:/dc2/r2",
    "upgradeDomain": "UD2"
  }

我正在尝试使用“AddNode.ps1”脚本添加一个名为“node3”的新节点：

---

我在powershell中收到错误“无效节点类型”。根据文档，节点类型必须是集群中的“现有”节点类型。我想知道这是为什么？clustermanifest.json中的“NodeTypeRef”表示什么？如果我使用nodetype参数“node1”或“node2”[这是现有的nodetype]运行AddNode.ps1，它会工作。

一般来说，您可以将nodetype看作是执行服务的执行环境硬件的抽象定义

举个例子：

假设您有两个服务A和B。服务A执行大量磁盘I/O绑定操作，而服务B需要大量内存才能工作

根据此信息，您可以定义两个节点类型，然后：FastSDD和HugeMemory。将节点添加到群集时，您可以根据硬件指定适当的节点类型（即，将SSD作为FastSSD的机器和将大型RAM作为HugeMemory的机器）

现在，您可以为您的服务定义以下内容：

• 服务A:NodeType==FastSSD
• 服务B:NodeType==HugeMemory

---

使用此配置ClusterManager将以某种方式组织您的服务，以确保服务a的副本放置在FastSSD类型的节点上，而服务B仅放置在HugeMemory类型的节点上。

从中您可能知道，每种节点类型都映射到一个VMS（虚拟机规模集）。VMS是具有相同配置的节点的集合，因此VMS中的每个节点将具有相同数量的RAM、CPU、操作系统和配置（端口、软件等），除非在部署后为每个节点设置单独的配置

节点类型必须是集群中的“现有”节点类型。我想知道这是为什么？clustermanifest.json中的“NodeTypeRef”表示什么

在SF上，节点类型是节点池（VM）的虚拟表示，具有相同的配置，可以处理与同一池中其他节点相同的类型和工作量

它们是虚拟的，因为它们代表一个机器池，而不是严格地绑定到虚拟机，因为当您在本地或其他云提供商上运行集群时，您不会有虚拟机，但您仍然可以有一个相同配置的虚拟机池链接到一个节点类型

您的集群很快或稍后将不得不扩展（上下）节点数量，拥有一个节点类型将更容易在新节点上放置服务，因为您知道特定的节点类型有预定义的要求，并且添加到池中的任何新节点都是兼容的，因此，您不需要在服务配置上进行复杂的配置来限制在不受支持的节点上运行的服务

另一个例子是，如果您没有节点类型，并且需要将服务分配给特定节点，那么在节点脱机的情况下，您的服务将无法运行，因为节点不可用。然后，您会想，我可以使用节点中的标签（即：Ram=8Gb）来满足特定需求，但如果您想将这些VM升级为16GB，您还必须更新服务，现在应该与16GB兼容

一个例子是这样的集群：

前端节点类型： 您将安装托管UI或API所需的服务，不需要大量磁盘，您必须配置LoadBalancer端口以打开对端口80（http）的访问

后端节点类型： 将承载将处理重负载、需要更多CPU和内存的辅助服务

DBNodeType： 将托管您的数据库，需要内存和磁盘存储

假设您将限制API在FrontEndNodetype上运行，如果您在那里添加一个新节点以减少其他节点上的负载，SF将知道它将满足服务需求，并且可以在那里运行您的API而不会出现任何问题，因为您在部署期间已经说过FrontEndNodetype包含服务所需的所有依赖项

另一个例子是基于GPU的工作，因此您的服务需要非常特定的硬件来运行

根据您的示例：

如果为添加的每个节点创建一个节点类型，那么就失去了拥有节点类型的好处，也就没有了如上所述的灵活性

---

另一个问题是，当您将具有不同配置的多个节点添加到同一节点类型时，服务结构不会出现问题，但很快或稍后您的服务将在特定节点上开始失败，可能是因为配置错误或缺少某些依赖项，由于每个节点都有不同的配置，因此很难调试和发现问题，您需要花一些时间来确定问题只发生在该节点上

我昨晚花了一些时间来解决这个问题，并克服了节点类型错误。我现在看到的是一个不同的错误，但那是一个不同的故事。如上所述，您需要将节点类型添加到现有集群，然后添加新节点。我们在内部部署安装中遇到的另一个问题是，您需要对AddNode.ps1进行更改。以下是3个步骤：

启动ServiceFabricClusterConfigurationUpgrade

更新addnode.ps1以传递windows凭据-由于某些原因，如果在连接到群集时使用windows凭据保护群集，则需要调整addnode.ps1以传递windows凭据。所以在203线

调用AddNode.ps1

---

Diego，看起来你的答案是基于使用Azure，但在这个问题中，重点是内部部署，所以在本例中，NodeType与VM没有任何关系。我也有同样的问题，我正在尝试添加一个新的

 .\AddNode.ps1 -FabricRuntimePackagePath  "G:\Downloads\ServiceFabricRuntime\MicrosoftAzureServiceFabric.6.2.274.9494.cab" -NodeName node3 -NodeType "node3" -NodeIPAddressorFQDN 192.168.1.3 -ExistingClientConnectionEndpoint node0.gbl.net:19000 -UpgradeDomain UD3 -FaultDomain fd:/dc3/r3 -AcceptEULA

    cd D:\TMHPSupport\Installs\Microsoft.Azure.ServiceFabric.WindowsServer.x.x.x
    Connect-ServiceFabricCluster -ConnectionEndpoint "mycluster.mydomain.com:19000" -WindowsCredential
    Start-ServiceFabricClusterConfigurationUpgrade -ClusterConfigPath NewNodeType.ClusterConfig.Windows.MultiMachine.json

    if($X509Credential)
    {    Connect-ServiceFabricCluster -ConnectionEndpoint $ExistingClientConnectionEndpoint -X509Credential -ServerCertThumbprint $ServerCertThumbprint -StoreLocation $StoreLocation -StoreName $StoreName -FindValue $FindValueThumbprint -FindType FindByThumbprint
    }
    else
    {
        Connect-ServiceFabricCluster $ExistingClientConnectionEndpoint **-WindowsCredential**
    }

.\AddNode.ps1 -NodeName dmz1 -NodeType newNodeType -NodeIPAddressorFQDN newnodeservername.domain.org -ExistingClientConnectionEndpoint existingnodeservername.domain.org:19000 -UpgradeDomain UD3 -FaultDomain fd:/dc1/r1 -AcceptEULA