Wzorce sieci usługi Service Fabric

Klaster usługi Azure Service Fabric można zintegrować z innymi funkcjami sieciowymi platformy Azure. W tym artykule pokazano, jak utworzyć klastry korzystające z następujących funkcji:

Usługa Service Fabric działa w standardowym zestawie skalowania maszyn wirtualnych. Wszystkie funkcje, których można użyć w zestawie skalowania maszyn wirtualnych, można użyć z klastrem usługi Service Fabric. Sekcje sieciowe szablonów usługi Azure Resource Manager dla zestawów skalowania maszyn wirtualnych i usługi Service Fabric są identyczne. Po wdrożeniu w istniejącej sieci wirtualnej można łatwo włączyć inne funkcje sieciowe, takie jak Azure ExpressRoute, Azure VPN Gateway, sieciowa grupa zabezpieczeń i komunikacja równorzędna sieci wirtualnych.

Zezwalanie dostawcy zasobów usługi Service Fabric na wykonywanie zapytań względem klastra

Usługa Service Fabric jest unikatowa od innych funkcji sieciowych w jednym aspekcie. Azure Portal wewnętrznie używa dostawcy zasobów usługi Service Fabric do wywołania klastra w celu uzyskania informacji o węzłach i aplikacjach. Dostawca zasobów usługi Service Fabric wymaga publicznie dostępnego dostępu przychodzącego do portu bramy HTTP (domyślnie portu 19080) w punkcie końcowym zarządzania. Service Fabric Explorer używa punktu końcowego zarządzania do zarządzania klastrem. Dostawca zasobów usługi Service Fabric używa również tego portu do wysyłania zapytań o informacje o klastrze do wyświetlania w Azure Portal.

Jeśli port 19080 nie jest dostępny od dostawcy zasobów usługi Service Fabric, w portalu pojawi się komunikat taki jak Węzły nie znaleziono , a lista węzłów i aplikacji jest pusta. Jeśli chcesz zobaczyć klaster w Azure Portal, moduł równoważenia obciążenia musi uwidocznić publiczny adres IP, a sieciowa grupa zabezpieczeń musi zezwalać na ruch przychodzący na porcie 19080. Jeśli konfiguracja nie spełnia tych wymagań, Azure Portal nie wyświetla stanu klastra.

Uwaga

Zalecamy korzystanie z modułu Azure Az programu PowerShell do interakcji z platformą Azure. Zobacz Instalowanie programu Azure PowerShell, aby rozpocząć. Aby dowiedzieć się, jak przeprowadzić migrację do modułu Az PowerShell, zobacz Migracja programu Azure PowerShell z modułu AzureRM do modułu Az.

Szablony

Wszystkie szablony usługi Service Fabric znajdują się w usłudze GitHub. Aby wdrożyć szablony zgodnie z oczekiwaniami, należy użyć następujących poleceń programu PowerShell. Jeśli wdrażasz istniejący szablon usługi Azure Virtual Network lub statyczny publiczny szablon IP, najpierw przeczytaj sekcję Początkowa konfiguracja w tym artykule.

Początkowa konfiguracja

Istniejąca sieć wirtualna

W poniższym przykładzie zaczynamy od istniejącej sieci wirtualnej o nazwie ExistingRG-vnet w grupie zasobów ExistingRG . Podsieć ma nazwę domyślną. Te zasoby domyślne są tworzone podczas tworzenia standardowej maszyny wirtualnej przy użyciu Azure Portal. Sieć wirtualną i podsieć można utworzyć bez tworzenia maszyny wirtualnej, ale głównym celem dodania klastra do istniejącej sieci wirtualnej jest zapewnienie łączności sieciowej z innymi maszynami wirtualnymi. Tworzenie maszyny wirtualnej daje dobry przykład użycia istniejącej sieci wirtualnej. Jeśli klaster usługi Service Fabric używa tylko wewnętrznego modułu równoważenia obciążenia bez publicznego adresu IP, możesz użyć maszyny wirtualnej i jego publicznego adresu IP jako bezpiecznego pola przesiadkowego.

Statyczny publiczny adres IP

Statyczny publiczny adres IP to zazwyczaj dedykowany zasób zarządzany oddzielnie od maszyny wirtualnej lub maszyn wirtualnych, do których jest przypisany. Jest ona aprowizowana w dedykowanej grupie zasobów sieci (w przeciwieństwie do samej grupy zasobów klastra usługi Service Fabric). Utwórz statyczny publiczny adres IP o nazwie staticIP1 w tej samej grupie zasobów ExistingRG w Azure Portal lub przy użyciu programu PowerShell:

PS C:\Users\user> New-AzPublicIpAddress -Name staticIP1 -ResourceGroupName ExistingRG -Location westus -AllocationMethod Static -DomainNameLabel sfnetworking

Name                     : staticIP1
ResourceGroupName        : ExistingRG
Location                 : westus
Id                       : /subscriptions/1237f4d2-3dce-1236-ad95-123f764e7123/resourceGroups/ExistingRG/providers/Microsoft.Network/publicIPAddresses/staticIP1
Etag                     : W/"fc8b0c77-1f84-455d-9930-0404ebba1b64"
ResourceGuid             : 77c26c06-c0ae-496c-9231-b1a114e08824
ProvisioningState        : Succeeded
Tags                     :
PublicIpAllocationMethod : Static
IpAddress                : 40.83.182.110
PublicIpAddressVersion   : IPv4
IdleTimeoutInMinutes     : 4
IpConfiguration          : null
DnsSettings              : {
                             "DomainNameLabel": "sfnetworking",
                             "Fqdn": "sfnetworking.westus.cloudapp.azure.com"
                           }

Szablon usługi Service Fabric

W przykładach w tym artykule używamy pliku template.json usługi Service Fabric. Kreator portalu standardowego umożliwia pobranie szablonu z portalu przed utworzeniem klastra. Możesz również użyć jednego z przykładowych szablonów, takich jak bezpieczny klaster usługi Service Fabric z pięcioma węzłami.

Istniejąca sieć wirtualna lub podsieć

  1. Zmień parametr podsieci na nazwę istniejącej podsieci, a następnie dodaj dwa nowe parametry, aby odwołać się do istniejącej sieci wirtualnej:

        "subnet0Name": {
                "type": "string",
                "defaultValue": "default"
            },
            "existingVNetRGName": {
                "type": "string",
                "defaultValue": "ExistingRG"
            },
    
            "existingVNetName": {
                "type": "string",
                "defaultValue": "ExistingRG-vnet"
            },
            /*
            "subnet0Name": {
                "type": "string",
                "defaultValue": "Subnet-0"
            },
            "subnet0Prefix": {
                "type": "string",
                "defaultValue": "10.0.0.0/24"
            },*/
    

    Możesz również oznaczyć jako komentarz parametr o nazwie "virtualNetworkName", aby nie monitować o wprowadzenie nazwy sieci wirtualnej dwa razy w bloku wdrażania klastra w Azure Portal.

  2. nicPrefixOverride Oznacz jako komentarz atrybut , Microsoft.Compute/virtualMachineScaleSetsponieważ używasz istniejącej podsieci i ta zmienna została wyłączona w kroku 1.

            /*"nicPrefixOverride": "[parameters('subnet0Prefix')]",*/
    
  3. Zmień zmienną, vnetID aby wskazywała istniejącą sieć wirtualną:

            /*old "vnetID": "[resourceId('Microsoft.Network/virtualNetworks',parameters('virtualNetworkName'))]",*/
            "vnetID": "[concat('/subscriptions/', subscription().subscriptionId, '/resourceGroups/', parameters('existingVNetRGName'), '/providers/Microsoft.Network/virtualNetworks/', parameters('existingVNetName'))]",
    
  4. Usuń Microsoft.Network/virtualNetworks z zasobów, więc platforma Azure nie tworzy nowej sieci wirtualnej:

    /*{
    "apiVersion": "[variables('vNetApiVersion')]",
    "type": "Microsoft.Network/virtualNetworks",
    "name": "[parameters('virtualNetworkName')]",
    "location": "[parameters('computeLocation')]",
    "properties": {
        "addressSpace": {
            "addressPrefixes": [
                "[parameters('addressPrefix')]"
            ]
        },
        "subnets": [
            {
                "name": "[parameters('subnet0Name')]",
                "properties": {
                    "addressPrefix": "[parameters('subnet0Prefix')]"
                }
            }
        ]
    },
    "tags": {
        "resourceType": "Service Fabric",
        "clusterName": "[parameters('clusterName')]"
    }
    },*/
    
  5. Oznacz jako komentarz sieć wirtualną z atrybutu dependsOnMicrosoft.Compute/virtualMachineScaleSets, więc nie zależysz od utworzenia nowej sieci wirtualnej:

    "apiVersion": "[variables('vmssApiVersion')]",
    "type": "Microsoft.Computer/virtualMachineScaleSets",
    "name": "[parameters('vmNodeType0Name')]",
    "location": "[parameters('computeLocation')]",
    "dependsOn": [
        /*"[concat('Microsoft.Network/virtualNetworks/', parameters('virtualNetworkName'))]",
        */
        "[Concat('Microsoft.Storage/storageAccounts/', variables('uniqueStringArray0')[0])]",
    
    
  6. Wdróż szablon:

    New-AzResourceGroup -Name sfnetworkingexistingvnet -Location westus
    New-AzResourceGroupDeployment -Name deployment -ResourceGroupName sfnetworkingexistingvnet -TemplateFile C:\SFSamples\Final\template\_existingvnet.json
    

    Po wdrożeniu sieć wirtualna powinna zawierać nowe maszyny wirtualne zestawu skalowania. Typ węzła zestawu skalowania maszyn wirtualnych powinien zawierać istniejącą sieć wirtualną i podsieć. Możesz również użyć protokołu RDP (Remote Desktop Protocol), aby uzyskać dostęp do maszyny wirtualnej, która była już w sieci wirtualnej, i wysłać polecenie ping do nowych maszyn wirtualnych zestawu skalowania:

    C:>\Users\users>ping 10.0.0.5 -n 1
    C:>\Users\users>ping NOde1000000 -n 1
    

W innym przykładzie zobacz ten, który nie jest specyficzny dla usługi Service Fabric.

Statyczny publiczny adres IP

  1. Dodaj parametry dla nazwy istniejącej statycznej grupy zasobów ip, nazwy i w pełni kwalifikowanej nazwy domeny (FQDN):

    "existingStaticIPResourceGroup": {
                "type": "string"
            },
            "existingStaticIPName": {
                "type": "string"
            },
            "existingStaticIPDnsFQDN": {
                "type": "string"
    }
    
  2. dnsName Usuń parametr. (Statyczny adres IP ma już jeden).

    /*
    "dnsName": {
        "type": "string"
    },
    */
    
  3. Dodaj zmienną, aby odwoływać się do istniejącego statycznego adresu IP:

    "existingStaticIP": "[concat('/subscriptions/', subscription().subscriptionId, '/resourceGroups/', parameters('existingStaticIPResourceGroup'), '/providers/Microsoft.Network/publicIPAddresses/', parameters('existingStaticIPName'))]",
    
  4. Usuń Microsoft.Network/publicIPAddresses z zasobów, więc platforma Azure nie tworzy nowego adresu IP:

    /*
    {
        "apiVersion": "[variables('publicIPApiVersion')]",
        "type": "Microsoft.Network/publicIPAddresses",
        "name": "[concat(parameters('lbIPName'),)'-', '0')]",
        "location": "[parameters('computeLocation')]",
        "properties": {
            "dnsSettings": {
                "domainNameLabel": "[parameters('dnsName')]"
            },
            "publicIPAllocationMethod": "Dynamic"        
        },
        "tags": {
            "resourceType": "Service Fabric",
            "clusterName": "[parameters('clusterName')]"
        }
    }, */
    
  5. Oznacz jako komentarz adres IP z atrybutu dependsOnMicrosoft.Network/loadBalancers, więc nie zależysz od utworzenia nowego adresu IP:

    "apiVersion": "[variables('lbIPApiVersion')]",
    "type": "Microsoft.Network/loadBalancers",
    "name": "[concat('LB', '-', parameters('clusterName'), '-', parameters('vmNodeType0Name'))]",
    "location": "[parameters('computeLocation')]",
    /*
    "dependsOn": [
        "[concat('Microsoft.Network/publicIPAddresses/', concat(parameters('lbIPName'), '-', '0'))]"
    ], */
    "properties": {
    
  6. W zasobie Microsoft.Network/loadBalancers zmień publicIPAddress element frontendIPConfigurations , aby odwołać się do istniejącego statycznego adresu IP zamiast nowo utworzonego:

                "frontendIPConfigurations": [
                        {
                            "name": "LoadBalancerIPConfig",
                            "properties": {
                                "publicIPAddress": {
                                    /*"id": "[resourceId('Microsoft.Network/publicIPAddresses',concat(parameters('lbIPName'),'-','0'))]"*/
                                    "id": "[variables('existingStaticIP')]"
                                }
                            }
                        }
                    ],
    
  7. W zasobie Microsoft.ServiceFabric/clusters zmień managementEndpoint nazwę FQDN DNS na statyczny adres IP. Jeśli używasz bezpiecznego klastra, upewnij się, że zmienisz http:// na https://. (Należy pamiętać, że ten krok dotyczy tylko klastrów usługi Service Fabric. Jeśli używasz zestawu skalowania maszyn wirtualnych, pomiń ten krok).

                    "fabricSettings": [],
                    /*"managementEndpoint": "[concat('http://',reference(concat(parameters('lbIPName'),'-','0')).dnsSettings.fqdn,':',parameters('nt0fabricHttpGatewayPort'))]",*/
                    "managementEndpoint": "[concat('http://',parameters('existingStaticIPDnsFQDN'),':',parameters('nt0fabricHttpGatewayPort'))]",
    
  8. Wdróż szablon:

    New-AzResourceGroup -Name sfnetworkingstaticip -Location westus
    
    $staticip = Get-AzPublicIpAddress -Name staticIP1 -ResourceGroupName ExistingRG
    
    $staticip
    
    New-AzResourceGroupDeployment -Name deployment -ResourceGroupName sfnetworkingstaticip -TemplateFile C:\SFSamples\Final\template\_staticip.json -existingStaticIPResourceGroup $staticip.ResourceGroupName -existingStaticIPName $staticip.Name -existingStaticIPDnsFQDN $staticip.DnsSettings.Fqdn
    

Po wdrożeniu widać, że moduł równoważenia obciążenia jest powiązany z publicznym statycznym adresem IP z innej grupy zasobów. Punkt końcowy połączenia klienta usługi Service Fabric i punkt końcowy Service Fabric Explorer wskazują nazwę FQDN DNS statycznego adresu IP.

Moduł równoważenia obciążenia tylko wewnętrzny

Ten scenariusz zastępuje zewnętrzny moduł równoważenia obciążenia w domyślnym szablonie usługi Service Fabric za pomocą modułu równoważenia obciążenia tylko wewnętrznego. Zapoznaj się z wcześniejszym artykułem, aby uzyskać implikacje dotyczące Azure Portal i dostawcy zasobów usługi Service Fabric.

  1. dnsName Usuń parametr. (To nie jest potrzebne).

    /*
    "dnsName": {
        "type": "string"
    },
    */
    
  2. Opcjonalnie, jeśli używasz metody alokacji statycznej, możesz dodać statyczny parametr adresu IP. Jeśli używasz metody alokacji dynamicznej, nie musisz wykonywać tego kroku.

            "internalLBAddress": {
                "type": "string",
                "defaultValue": "10.0.0.250"
            }
    
  3. Usuń Microsoft.Network/publicIPAddresses z zasobów, więc platforma Azure nie tworzy nowego adresu IP:

    /*
    {
        "apiVersion": "[variables('publicIPApiVersion')]",
        "type": "Microsoft.Network/publicIPAddresses",
        "name": "[concat(parameters('lbIPName'),)'-', '0')]",
        "location": "[parameters('computeLocation')]",
        "properties": {
            "dnsSettings": {
                "domainNameLabel": "[parameters('dnsName')]"
            },
            "publicIPAllocationMethod": "Dynamic"        
        },
        "tags": {
            "resourceType": "Service Fabric",
            "clusterName": "[parameters('clusterName')]"
        }
    }, */
    
  4. Usuń atrybut adresu dependsOn IP elementu Microsoft.Network/loadBalancers, aby nie zależeć od utworzenia nowego adresu IP. Dodaj atrybut sieci dependsOn wirtualnej, ponieważ moduł równoważenia obciążenia teraz zależy od podsieci z sieci wirtualnej:

                "apiVersion": "[variables('lbApiVersion')]",
                "type": "Microsoft.Network/loadBalancers",
                "name": "[concat('LB','-', parameters('clusterName'),'-',parameters('vmNodeType0Name'))]",
                "location": "[parameters('computeLocation')]",
                "dependsOn": [
                    /*"[concat('Microsoft.Network/publicIPAddresses/',concat(parameters('lbIPName'),'-','0'))]"*/
                    "[concat('Microsoft.Network/virtualNetworks/',parameters('virtualNetworkName'))]"
                ],
    
  5. Zmień ustawienie modułu równoważenia frontendIPConfigurations obciążenia z przy użyciu elementu publicIPAddress, na używając podsieci i privateIPAddress. privateIPAddress używa wstępnie zdefiniowanego statycznego wewnętrznego adresu IP. Aby użyć dynamicznego adresu IP, usuń privateIPAddress element, a następnie przejdź do dynamicznegoprivateIPAllocationMethod.

                "frontendIPConfigurations": [
                        {
                            "name": "LoadBalancerIPConfig",
                            "properties": {
                                /*
                                "publicIPAddress": {
                                    "id": "[resourceId('Microsoft.Network/publicIPAddresses',concat(parameters('lbIPName'),'-','0'))]"
                                } */
                                "subnet" :{
                                    "id": "[variables('subnet0Ref')]"
                                },
                                "privateIPAddress": "[parameters('internalLBAddress')]",
                                "privateIPAllocationMethod": "Static"
                            }
                        }
                    ],
    
  6. W zasobie Microsoft.ServiceFabric/clusters zmień wartość managementEndpoint , aby wskazać wewnętrzny adres modułu równoważenia obciążenia. Jeśli używasz bezpiecznego klastra, upewnij się, że zmienisz http:// na https://. (Należy pamiętać, że ten krok dotyczy tylko klastrów usługi Service Fabric. Jeśli używasz zestawu skalowania maszyn wirtualnych, pomiń ten krok).

                    "fabricSettings": [],
                    /*"managementEndpoint": "[concat('http://',reference(concat(parameters('lbIPName'),'-','0')).dnsSettings.fqdn,':',parameters('nt0fabricHttpGatewayPort'))]",*/
                    "managementEndpoint": "[concat('http://',reference(variables('lbID0')).frontEndIPConfigurations[0].properties.privateIPAddress,':',parameters('nt0fabricHttpGatewayPort'))]",
    
  7. Wdróż szablon:

    New-AzResourceGroup -Name sfnetworkinginternallb -Location westus
    
    New-AzResourceGroupDeployment -Name deployment -ResourceGroupName sfnetworkinginternallb -TemplateFile C:\SFSamples\Final\template\_internalonlyLB.json
    

Po wdrożeniu moduł równoważenia obciążenia używa prywatnego statycznego adresu IP 10.0.0.250. Jeśli masz inną maszynę w tej samej sieci wirtualnej, możesz przejść do wewnętrznego punktu końcowego Service Fabric Explorer. Należy pamiętać, że łączy się z jednym z węzłów modułu równoważenia obciążenia.

Wewnętrzny i zewnętrzny moduł równoważenia obciążenia

W tym scenariuszu zaczniesz od istniejącego modułu równoważenia obciążenia zewnętrznego typu pojedynczego węzła i dodasz wewnętrzny moduł równoważenia obciążenia dla tego samego typu węzła. Port zaplecza dołączony do puli adresów zaplecza można przypisać tylko do jednego modułu równoważenia obciążenia. Wybierz, który moduł równoważenia obciążenia będzie miał porty aplikacji i który moduł równoważenia obciążenia będzie miał punkty końcowe zarządzania (porty 19000 i 19080). Jeśli punkty końcowe zarządzania są umieszczane w wewnętrznym module równoważenia obciążenia, pamiętaj o ograniczeniach dostawcy zasobów usługi Service Fabric omówionych wcześniej w artykule. W przykładzie używanym przez nas punkty końcowe zarządzania pozostają w zewnętrznym module równoważenia obciążenia. Dodajesz również port aplikacji 80 portów i umieszczasz go w wewnętrznym module równoważenia obciążenia.

W klastrze dwuwęźle jeden typ węzła znajduje się w zewnętrznym module równoważenia obciążenia. Drugi typ węzła znajduje się w wewnętrznym module równoważenia obciążenia. Aby użyć klastra typu dwa węzły, w portalu utworzony szablon dwuwęźle typu (który jest dostarczany z dwoma modułami równoważenia obciążenia), przełącz drugi moduł równoważenia obciążenia do wewnętrznego modułu równoważenia obciążenia. Aby uzyskać więcej informacji, zobacz sekcję Moduł równoważenia obciążenia tylko do użytku wewnętrznego .

  1. Dodaj parametr adresu IP statycznego wewnętrznego modułu równoważenia obciążenia. (Uwagi związane z używaniem dynamicznego adresu IP można znaleźć we wcześniejszych sekcjach tego artykułu).

            "internalLBAddress": {
                "type": "string",
                "defaultValue": "10.0.0.250"
            }
    
  2. Dodaj parametr portu 80 aplikacji.

  3. Aby dodać wewnętrzne wersje istniejących zmiennych sieciowych, skopiuj je i wklej, a następnie dodaj ciąg "-Int" do nazwy:

    /* Add internal load balancer networking variables */
            "lbID0-Int": "[resourceId('Microsoft.Network/loadBalancers', concat('LB','-', parameters('clusterName'),'-',parameters('vmNodeType0Name'), '-Internal'))]",
            "lbIPConfig0-Int": "[concat(variables('lbID0-Int'),'/frontendIPConfigurations/LoadBalancerIPConfig')]",
            "lbPoolID0-Int": "[concat(variables('lbID0-Int'),'/backendAddressPools/LoadBalancerBEAddressPool')]",
            "lbProbeID0-Int": "[concat(variables('lbID0-Int'),'/probes/FabricGatewayProbe')]",
            "lbHttpProbeID0-Int": "[concat(variables('lbID0-Int'),'/probes/FabricHttpGatewayProbe')]",
            "lbNatPoolID0-Int": "[concat(variables('lbID0-Int'),'/inboundNatPools/LoadBalancerBEAddressNatPool')]",
            /* Internal load balancer networking variables end */
    
  4. Jeśli zaczniesz od szablonu wygenerowanego przez portal, który używa portu 80 aplikacji, domyślny szablon portalu doda port AppPort1 (port 80) w zewnętrznym module równoważenia obciążenia. W takim przypadku usuń element AppPort1 z zewnętrznego modułu równoważenia loadBalancingRules obciążenia i sond, aby dodać go do wewnętrznego modułu równoważenia obciążenia:

    "loadBalancingRules": [
        {
            "name": "LBHttpRule",
            "properties":{
                "backendAddressPool": {
                    "id": "[variables('lbPoolID0')]"
                },
                "backendPort": "[parameters('nt0fabricHttpGatewayPort')]",
                "enableFloatingIP": "false",
                "frontendIPConfiguration": {
                    "id": "[variables('lbIPConfig0')]"            
                },
                "frontendPort": "[parameters('nt0fabricHttpGatewayPort')]",
                "idleTimeoutInMinutes": "5",
                "probe": {
                    "id": "[variables('lbHttpProbeID0')]"
                },
                "protocol": "tcp"
            }
        } /* Remove AppPort1 from the external load balancer.
        {
            "name": "AppPortLBRule1",
            "properties": {
                "backendAddressPool": {
                    "id": "[variables('lbPoolID0')]"
                },
                "backendPort": "[parameters('loadBalancedAppPort1')]",
                "enableFloatingIP": "false",
                "frontendIPConfiguration": {
                    "id": "[variables('lbIPConfig0')]"            
                },
                "frontendPort": "[parameters('loadBalancedAppPort1')]",
                "idleTimeoutInMinutes": "5",
                "probe": {
                    "id": "[concate(variables('lbID0'), '/probes/AppPortProbe1')]"
                },
                "protocol": "tcp"
            }
        }*/
    
    ],
    "probes": [
        {
            "name": "FabricGatewayProbe",
            "properties": {
                "intervalInSeconds": 5,
                "numberOfProbes": 2,
                "port": "[parameters('nt0fabricTcpGatewayPort')]",
                "protocol": "tcp"
            }
        },
        {
            "name": "FabricHttpGatewayProbe",
            "properties": {
                "intervalInSeconds": 5,
                "numberOfProbes": 2,
                "port": "[parameters('nt0fabricHttpGatewayPort')]",
                "protocol": "tcp"
            }
        } /* Remove AppPort1 from the external load balancer.
        {
            "name": "AppPortProbe1",
            "properties": {
                "intervalInSeconds": 5,
                "numberOfProbes": 2,
                "port": "[parameters('loadBalancedAppPort1')]",
                "protocol": "tcp"
            }
        } */
    
    ],
    "inboundNatPools": [
    
  5. Dodaj drugi Microsoft.Network/loadBalancers zasób. Wygląda podobnie do wewnętrznego modułu równoważenia obciążenia utworzonego w sekcji Moduł równoważenia obciążenia tylko wewnętrznego , ale używa zmiennych modułu równoważenia obciążenia "-Int" i implementuje tylko port aplikacji 80. Spowoduje to również usunięcie inboundNatPoolselementu , aby zachować punkty końcowe protokołu RDP w publicznym module równoważenia obciążenia. Jeśli chcesz korzystać z protokołu RDP w wewnętrznym module równoważenia obciążenia, przejdź inboundNatPools z zewnętrznego modułu równoważenia obciążenia do tego wewnętrznego modułu równoważenia obciążenia:

            /* Add a second load balancer, configured with a static privateIPAddress and the "-Int" load balancer variables. */
            {
                "apiVersion": "[variables('lbApiVersion')]",
                "type": "Microsoft.Network/loadBalancers",
                /* Add "-Internal" to the name. */
                "name": "[concat('LB','-', parameters('clusterName'),'-',parameters('vmNodeType0Name'), '-Internal')]",
                "location": "[parameters('computeLocation')]",
                "dependsOn": [
                    /* Remove public IP dependsOn, add vnet dependsOn
                    "[concat('Microsoft.Network/publicIPAddresses/',concat(parameters('lbIPName'),'-','0'))]"
                    */
                    "[concat('Microsoft.Network/virtualNetworks/',parameters('virtualNetworkName'))]"
                ],
                "properties": {
                    "frontendIPConfigurations": [
                        {
                            "name": "LoadBalancerIPConfig",
                            "properties": {
                                /* Switch from Public to Private IP address
                                */
                                "publicIPAddress": {
                                    "id": "[resourceId('Microsoft.Network/publicIPAddresses',concat(parameters('lbIPName'),'-','0'))]"
                                }
                                */
                                "subnet" :{
                                    "id": "[variables('subnet0Ref')]"
                                },
                                "privateIPAddress": "[parameters('internalLBAddress')]",
                                "privateIPAllocationMethod": "Static"
                            }
                        }
                    ],
                    "backendAddressPools": [
                        {
                            "name": "LoadBalancerBEAddressPool",
                            "properties": {}
                        }
                    ],
                    "loadBalancingRules": [
                        /* Add the AppPort rule. Be sure to reference the "-Int" versions of backendAddressPool, frontendIPConfiguration, and the probe variables. */
                        {
                            "name": "AppPortLBRule1",
                            "properties": {
                                "backendAddressPool": {
                                    "id": "[variables('lbPoolID0-Int')]"
                                },
                                "backendPort": "[parameters('loadBalancedAppPort1')]",
                                "enableFloatingIP": "false",
                                "frontendIPConfiguration": {
                                    "id": "[variables('lbIPConfig0-Int')]"
                                },
                                "frontendPort": "[parameters('loadBalancedAppPort1')]",
                                "idleTimeoutInMinutes": "5",
                                "probe": {
                                    "id": "[concat(variables('lbID0-Int'),'/probes/AppPortProbe1')]"
                                },
                                "protocol": "tcp"
                            }
                        }
                    ],
                    "probes": [
                    /* Add the probe for the app port. */
                    {
                            "name": "AppPortProbe1",
                            "properties": {
                                "intervalInSeconds": 5,
                                "numberOfProbes": 2,
                                "port": "[parameters('loadBalancedAppPort1')]",
                                "protocol": "tcp"
                            }
                        }
                    ],
                    "inboundNatPools": [
                    ]
                },
                "tags": {
                    "resourceType": "Service Fabric",
                    "clusterName": "[parameters('clusterName')]"
                }
            },
    
  6. W networkProfile obszarze dla Microsoft.Compute/virtualMachineScaleSets zasobu dodaj wewnętrzną pulę adresów zaplecza:

    "loadBalancerBackendAddressPools": [
                                                        {
                                                            "id": "[variables('lbPoolID0')]"
                                                        },
                                                        {
                                                            /* Add internal BE pool */
                                                            "id": "[variables('lbPoolID0-Int')]"
                                                        }
    ],
    
  7. Wdróż szablon:

    New-AzResourceGroup -Name sfnetworkinginternalexternallb -Location westus
    
    New-AzResourceGroupDeployment -Name deployment -ResourceGroupName sfnetworkinginternalexternallb -TemplateFile C:\SFSamples\Final\template\_internalexternalLB.json
    

Po wdrożeniu w grupie zasobów są widoczne dwa moduły równoważenia obciążenia. Jeśli przeglądasz moduły równoważenia obciążenia, zobaczysz publiczny adres IP i punkty końcowe zarządzania (porty 19000 i 19080) przypisane do publicznego adresu IP. Można również zobaczyć statyczny wewnętrzny adres IP i punkt końcowy aplikacji (port 80) przypisany do wewnętrznego modułu równoważenia obciążenia. Oba moduły równoważenia obciążenia używają tej samej puli zaplecza zestawu skalowania maszyn wirtualnych.

Uwagi dotyczące obciążeń produkcyjnych

Powyższe szablony usługi GitHub są przeznaczone do pracy z domyślną jednostkę SKU dla usługi Azure usługa Load Balancer w warstwie Standardowa (SLB), jednostki SKU w warstwie Podstawowa. Podstawowy moduł równoważenia obciążenia jednostki SKU nie ma umowy SLA, dlatego w przypadku obciążeń produkcyjnych należy użyć jednostki SKU w warstwie Standardowa. Aby uzyskać więcej informacji na ten temat, zobacz Omówienie usługi Azure usługa Load Balancer w warstwie Standardowa. Każdy klaster usługi Service Fabric używający standardowej jednostki SKU dla usługi SLB musi mieć pewność, że każdy typ węzła ma regułę zezwalającą na ruch wychodzący na porcie 443. Jest to konieczne do ukończenia konfiguracji klastra, a każde wdrożenie bez takiej reguły zakończy się niepowodzeniem. W powyższym przykładzie modułu równoważenia obciążenia "tylko wewnętrznego" należy dodać do szablonu dodatkowy zewnętrzny moduł równoważenia obciążenia z regułą zezwalającą na ruch wychodzący dla portu 443.

Następne kroki

Tworzenie klastra