Skip to content

Commit

Permalink
Merge pull request #637 from MicrosoftDocs/main
Browse files Browse the repository at this point in the history
11/21/2024 AM Publish
  • Loading branch information
Taojunshen authored Nov 21, 2024
2 parents 33eba73 + b41c536 commit e8953c4
Show file tree
Hide file tree
Showing 21 changed files with 96 additions and 49 deletions.
52 changes: 52 additions & 0 deletions articles/service-fabric/how-to-managed-cluster-ip-tags.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
---
title: Set up IP tags on a Service Fabric managed cluster
description: Learn how to set IP tags on a Service Fabric managed cluster.
ms.topic: how-to
ms.author: tomcassidy
author: tomvcassidy
ms.service: azure-service-fabric
services: service-fabric
ms.date: 10/30/2024
---

# Set up IP tags on a Service Fabric managed cluster (SFMC)

An IP tag represents a group of IP address prefixes from a given Azure service. Microsoft manages the address prefixes encompassed by the IP tag and automatically updates the service tag as addresses change, minimizing the complexity of frequent updates to network security rules. You can use IP tags to define network access controls on [network security groups](/azure/virtual-network/network-security-groups-overview#security-rules), [Azure Firewall](/azure/firewall/service-tags), and user-defined routes. By adding IP tags, an SFMC cluster has an added layer of security.

> [!NOTE]
> The `IPTag` property only applies to the public IPv4 and IPv6 addresses of the default cluster load balancer.
## Limitations

You shouldn't implement IP tags on existing clusters.

## Prerequisites

Ensure that you [provisioned IPTags beforehand](/powershell/module/az.network/new-azpublicipaddress#example-3-create-a-new-public-ip-address-with-iptag).

## Modify your ARM template

When creating a new Service Fabric managed cluster, you need to add to the ARM template with the following property:


```json
{
"type": "Microsoft.ServiceFabric/managedClusters",
"apiVersion": "2021-07-01-preview",
"properties": {
"ipTags": [
{
"ipTagType": "string",
"tag": "string"
}
]
}
}
```

Then, deploy your SFMC cluster as normal.

## Next steps

* To see more about Service Fabric managed cluster network settings, see [Configure network settings for Service Fabric managed clusters](how-to-managed-cluster-networking.md).
* To learn about using public IP prefixes in managed clusters, see [Use a Public IP address prefix in a Service Fabric managed cluster](how-to-managed-cluster-public-ip-prefix.md).
4 changes: 2 additions & 2 deletions articles/service-fabric/how-to-managed-cluster-networking.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ author: tomvcassidy
ms.service: azure-service-fabric
ms.custom: devx-track-azurepowershell
services: service-fabric
ms.date: 07/11/2022
ms.date: 11/21/2024
---

# Configure network settings for Service Fabric managed clusters
Expand Down Expand Up @@ -607,7 +607,7 @@ Managed clusters create an Azure public Standard Load Balancer and fully qualifi
> You can not switch from the default load balancer to a custom one after deployment of a node type, but you can modify custom load balancer configuration post-deployment if enabled.
**Feature Requirements**
* Basic and Standard SKU Azure Load Balancer types are supported
* The Standard SKU Azure Load Balancer type is supported
* You must have backend and NAT pools configured on the Azure Load Balancer
* You must enable outbound connectivity either using a provided public load balancer or the default public load balancer

Expand Down
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
4 changes: 2 additions & 2 deletions articles/service-fabric/overview-managed-cluster.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ ms.author: tomcassidy
author: tomvcassidy
ms.service: azure-service-fabric
services: service-fabric
ms.date: 03/12/2024
ms.date: 11/21/2024
---

# Service Fabric managed clusters
Expand Down Expand Up @@ -63,7 +63,7 @@ Service Fabric managed clusters are available in both Basic and Standard SKUs.

| Feature | Basic | Standard |
| ------- | ----- | -------- |
| Network resource (SKU for [Load Balancer](/azure/load-balancer/skus), [Public IP](/azure/virtual-network/ip-services/public-ip-addresses)) | Basic | Standard |
| Network resource (SKU for [Load Balancer](/azure/load-balancer/skus), [Public IP](/azure/virtual-network/ip-services/public-ip-addresses)) | Standard | Standard |
| Min node (virtual machine instance) count | 3 | 5 |
| Max node count per node type | 100 | 1000 |
| Max node type count | 1 | 50 |
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ ms.author: tomcassidy
author: tomvcassidy
ms.service: azure-service-fabric
services: service-fabric
ms.date: 08/29/2022
ms.date: 11/14/2024
---

# Set up Microsoft Entra ID for client authentication
Expand Down Expand Up @@ -178,8 +178,6 @@ $resourceGroupName = 'mysftestcluster'

It may be necessary to 'Grant admin consent' for the 'API permissions' being configured. Navigate to [Azure App registrations](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/RegisteredApps) blade and add name of cluster to the filter. For both registrations, open 'API permissions', and select 'Grant admin consent for' if available.

![Screenshot that shows Grant admin consent selected on the Azure App registrations blade.](media/service-fabric-cluster-creation-setup-aad/portal-client-api-grant.png)

![Screenshot that shows the Grant admin consent confirmation with Yes highlighted.](media/service-fabric-cluster-creation-setup-aad/portal-client-api-grant-confirm.png)


Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ ms.author: tomcassidy
author: tomvcassidy
ms.service: azure-service-fabric
services: service-fabric
ms.date: 07/14/2022
ms.date: 11/14/2024
---

# Remote connect to a virtual machine scale set instance or a cluster node
Expand All @@ -20,8 +20,6 @@ To find an IP address and port that you can use to remotely connect to a specifi

On the page for your load balancer in Azure portal, select **Settings** > **Inbound NAT rules**:

![Screenshot of a load balancer page in the Azure portal. In the left-hand menu, under SETTINGS, Inbound NAT rules is selected.](./media/service-fabric-cluster-remote-connect-to-azure-cluster-node/lb-window.png)

The following screenshot shows the inbound NAT rules for a node type named FrontEnd:

![Screenshot showing the inbound NAT rules for a load balancer. The Name, IP Version, Destination, Target and Service are listed for each rule.](./media/service-fabric-cluster-remote-connect-to-azure-cluster-node/nat-rules.png)
Expand Down
19 changes: 9 additions & 10 deletions articles/service-fabric/service-fabric-cross-availability-zones.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ ms.author: tomcassidy
author: tomvcassidy
ms.service: azure-service-fabric
services: service-fabric
ms.date: 07/14/2022
ms.date: 11/21/2024
---

# Deploy an Azure Service Fabric cluster across Availability Zones
Expand Down Expand Up @@ -62,7 +62,7 @@ The Service Fabric load balancer brings up replicas in the working zones to matc

### Public IP and load balancer resource

To enable the `zones` property on a virtual machine scale set resource, the load balancer and the IP resource referenced by that virtual machine scale set must both use a Standard SKU. Creating a load balancer or IP resource without the SKU property creates a Basic SKU, which does not support Availability Zones. A Standard SKU load balancer blocks all traffic from the outside by default. To allow outside traffic, deploy an NSG to the subnet.
To enable the `zones` property on a virtual machine scale set resource, the load balancer and the IP resource referenced by that virtual machine scale set must both use a Standard SKU. Creating an IP resource without the SKU property creates a Basic SKU, which does not support Availability Zones. A Standard SKU load balancer blocks all traffic from the outside by default. To allow outside traffic, deploy an NSG to the subnet.

```json
{
Expand Down Expand Up @@ -110,7 +110,7 @@ To enable the `zones` property on a virtual machine scale set resource, the load
```

>[!NOTE]
> It isn't possible to do an in-place change of SKU on the public IP and load balancer resources. If you're migrating from existing resources that have a Basic SKU, see the migration section of this article.
> It isn't possible to do an in-place change of SKU on public IP resources. If you're migrating from existing resources that have a Basic SKU, see the [migration section](#migrate-to-availability-zones-from-a-cluster-by-using-a-basic-sku-ip) of this article.
### NAT rules for virtual machine scale sets

Expand Down Expand Up @@ -161,7 +161,7 @@ The inbound network address translation (NAT) rules for the load balancer should

### Outbound rules for a Standard SKU load balancer

The Standard SKU load balancer and public IP introduce new abilities and different behaviors to outbound connectivity when compared to using Basic SKUs. If you want outbound connectivity when you're working with Standard SKUs, you must explicitly define it with either a Standard SKU public IP addresses or a Standard SKU load balancer. For more information, see [Outbound connections](/azure/load-balancer/load-balancer-outbound-connections) and [What is Azure Load Balancer?](/azure/load-balancer/load-balancer-overview).
The Standard SKU public IP introduces new abilities and different behaviors to outbound connectivity when compared to using Basic SKUs. If you want outbound connectivity when you're working with Standard SKUs, you must explicitly define it with either a Standard SKU public IP addresses or a Standard SKU load balancer. For more information, see [Outbound connections](/azure/load-balancer/load-balancer-outbound-connections) and [What is Azure Load Balancer?](/azure/load-balancer/load-balancer-overview).

>[!NOTE]
> The standard template references an NSG that allows all outbound traffic by default. Inbound traffic is limited to the ports that are required for Service Fabric management operations. The NSG rules can be modified to meet your requirements.
Expand Down Expand Up @@ -273,11 +273,10 @@ The Service Fabric node type must be enabled to support multiple Availability Zo
For all migration scenarios, you need to add a new node type that supports multiple Availability Zones. An existing node type can't be migrated to support multiple zones.
The [Scale up a Service Fabric cluster primary node type](./service-fabric-scale-up-primary-node-type.md) article includes detailed steps to add a new node type and the other resources required for the new node type, such as IP and load balancer resources. That article also describes how to retire the existing node type after a new node type with multiple Availability Zones is added to the cluster.

* Migration from a node type that uses basic load balancer and IP resources: This process is already described in [a sub-section below](#migrate-to-availability-zones-from-a-cluster-by-using-a-basic-sku-load-balancer-and-a-basic-sku-ip) for the solution with one node type per Availability Zone.
* Migration from a node type that uses basic IP resources: This process is already described in [a sub-section below](#migrate-to-availability-zones-from-a-cluster-by-using-a-basic-sku-ip) for the solution with one node type per Availability Zone.

For the new node type, the only difference is that there's only one virtual machine scale set and one node type for all Availability Zones instead of one each per Availability Zone.
* Migration from a node type that uses the Standard SKU load balancer and IP resources with an NSG: Follow the same procedure described previously. However, there's no need to add new load balancer, IP, and NSG resources. The same resources can be reused in the new node type.

* Migration from a node type that uses the Standard SKU IP resources with an NSG: Follow the same procedure described previously. However, there's no need to add new IP and NSG resources. The same resources can be reused in the new node type.

## 2. Deploy zones by pinning one virtual machine scale set to each zone

Expand Down Expand Up @@ -405,11 +404,11 @@ To set one or more node types as primary in a cluster resource, set the `isPrima
}
```

## Migrate to Availability Zones from a cluster by using a Basic SKU load balancer and a Basic SKU IP
## Migrate to Availability Zones from a cluster by using a Basic SKU IP

To migrate a cluster that's using a load balancer and IP with a basic SKU, you must first create an entirely new load balancer and IP resource using the standard SKU. It isn't possible to update these resources.
To migrate a cluster that's using an IP with a Basic SKU, you must first create an entirely new IP resource using the Standard SKU. It isn't possible to update these resources.

Reference the new load balancer and IP in the new cross-Availability Zone node types that you want to use. In the previous example, three new virtual machine scale set resources were added in zones 1, 2, and 3. These virtual machine scale sets reference the newly created load balancer and IP and are marked as primary node types in the Service Fabric cluster resource.
Reference the new IP in the new cross-Availability Zone node types that you want to use. In the previous example, three new virtual machine scale set resources were added in zones 1, 2, and 3. These virtual machine scale sets reference the newly created IP and are marked as primary node types in the Service Fabric cluster resource.

1. To begin, add the new resources to your existing Azure Resource Manager template. These resources include:

Expand Down
4 changes: 2 additions & 2 deletions articles/service-fabric/service-fabric-patterns-networking.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ ms.author: tomcassidy
author: tomvcassidy
ms.service: azure-service-fabric
services: service-fabric
ms.date: 07/11/2022
ms.date: 11/21/2024
---

# Service Fabric networking patterns
Expand Down Expand Up @@ -599,7 +599,7 @@ After deployment, you can see two load balancers in the resource group. If you b

## Notes for production workloads

The above GitHub templates are designed to work with the default SKU for Azure Standard Load Balancer (SLB), the Basic SKU. The Basic SKU LB has no SLA, so for production workloads the Standard SKU should be used. For more on this, see the [Azure Standard Load Balancer overview](/azure/load-balancer/load-balancer-overview). Any Service Fabric cluster using the Standard SKU for SLB needs to ensure that each node type has a rule allowing outbound traffic on port 443. This is necessary to complete cluster setup, and any deployment without such a rule will fail. In the above example of an "internal only" load balancer, an additional external load balancer must be added to the template with a rule allowing outbound traffic for port 443.
The above GitHub templates are designed to work with the default SKU for Azure Standard Load Balancer (SLB), the Standard SKU. Any Service Fabric cluster using the Standard SKU for SLB needs to ensure that each node type has a rule allowing outbound traffic on port 443. This is necessary to complete cluster setup, and any deployment without such a rule will fail. In the above example of an "internal only" load balancer, an additional external load balancer must be added to the template with a rule allowing outbound traffic for port 443.

## Next steps
[Create a cluster](service-fabric-cluster-creation-via-arm.md)
Original file line number Diff line number Diff line change
Expand Up @@ -132,11 +132,7 @@ Right-click **MyFirstContainer** in the Solution Explorer and choose **Publish**

Copy the content following **CN=** in the PowerShell window when you ran the `Import-PfxCertificate` command above, and add port `19000` to it. For example, `mysfcluster.SouthCentralUS.cloudapp.azure.com:19000`. Copy it into the **Connection Endpoint** field. Remember this value because you'll need it in a future step.

Click **Advanced Connection Parameters** and verify the connection parameter information. *FindValue* and *ServerCertThumbprint* values must match the thumbprint of the certificate installed when you ran `Import-PfxCertificate` in the previous step.

![Publish Dialog](./media/service-fabric-quickstart-containers/publish-app.png)

Click **Publish**.
Click **Advanced Connection Parameters** and verify the connection parameter information. *FindValue* and *ServerCertThumbprint* values must match the thumbprint of the certificate installed when you ran `Import-PfxCertificate` in the previous step. Then, select **Publish**.

Each application in the cluster must have a unique name. If there's a name conflict, rename the Visual Studio project and deploy again.

Expand Down
Loading

0 comments on commit e8953c4

Please sign in to comment.