Application deployment is failing in newly deployed cluster

Question

We tried deploying cluster and vmss in location other than resource group location which is west europe and tried deploying vmss &cluster in westus2. Resource deployment got successful but applictaion deployment is failing in cluster .We need help to understand th eissue .

Answer 1

Hello Garima.

Your cluster and VM Scale Sets deployed successfully in the new location (westus2), but the fabric:/AzureStackEdge application is in an Error health state. The Cluster Resource Manager cannot place secondary replicas for partition [GUID REMOVED] because no nodes satisfy the placement constraint NodeType==awrnode2. Many nodes were eliminated (15 by placement constraints and 5 by ServiceTypeDisabled/NodesBlockListed), leaving zero suitable nodes for the required replica set size.

This is a common Service Fabric placement-constraint mismatch that occurs when an application’s service manifest expects a specific node type that is either missing, not scaled out, or unhealthy in the target cluster.

Recommended solution Check and align your cluster’s node types with the requirements of the AzureStackEdge application:

1. Open Service Fabric Explorer → Nodes and verify:
   • Are any nodes listed with NodeType = awrnode2.
   • Are those nodes in Up and OK health state?
2. If the awrnode2 node type is missing or has zero healthy nodes:
   • Update your cluster ARM template (or Bicep) to include a VM Scale Set with nodeTypeRef: "awrnode2".
   • Redeploy or scale the cluster to add the missing node type.
3. Review the full constraint elimination sequence in the partition’s details for any additional block-listing or disabled service types.

Latest Update from the PG upon investigation :

The error we see is because of App issue and not related to SF runtime specific, it could be because of -

1. Code package activation failures on the node (exe crashes at startup, DllMain failures, missing dependencies).
2. Service package download / image store failures for that service type.
3. Configuration issues – port conflicts, endpoint binding errors, invalid certs/secrets, missing resource-governance capacity.
4. Repeated crashes / exit codes from the service host shortly after activation.
5. Health check / safety check failures attributed to that partition on that node.

PG suggested to login into the Node and check if there any Cert expiry issue is with the App config not from the Engineering side.

Link :

https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-resource-manager-cluster-description#node-properties-and-placement-constraints
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-understand-and-troubleshoot-with-system-health-reports

Thanks,
Manish.

Answer 2

I think the naming primary just never settles after the cross‑region build… if SFX shows no steady primary, rebuild everything in one region; if that still fails, recreate the RG to clear the metadata.