Konfigurationsinställningar för ett fristående Windows-kluster
I den här artikeln beskrivs konfigurationsinställningar för ett fristående Azure Service Fabric-kluster som kan anges i clusterConfig.json-filen . Du använder den här filen för att ange information om klustrets noder, säkerhetskonfigurationer samt nätverkstopologin när det gäller fel- och uppgraderingsdomäner. När du har ändrat eller lagt till konfigurationsinställningar kan du antingen skapa ett fristående kluster eller uppgradera konfigurationen för ett fristående kluster.
När du laddar ned det fristående Service Fabric-paketet ingår även ClusterConfig.json-exempel. Exemplen med "DevCluster" i sina namn skapar ett kluster med alla tre noderna på samma dator med hjälp av logiska noder. Av dessa noder måste minst en markeras som en primär nod. Den här typen av kluster är användbar för utvecklings- eller testmiljöer. Det stöds inte som ett produktionskluster. De exempel som har "MultiMachine" i sina namn hjälper till att skapa kluster i produktionsklass med varje nod på en separat dator. Antalet primära noder för dessa kluster baseras på klustrets tillförlitlighetsnivå. I version 5.7, API Version 05-2017, tog vi bort egenskapen på tillförlitlighetsnivå. I stället beräknar vår kod den mest optimerade tillförlitlighetsnivån för klustret. Försök inte att ange ett värde för den här egenskapen i version 5.7 och senare.
ClusterConfig.Unsecure.DevCluster.json och ClusterConfig.Unsecure.MultiMachine.json visar hur du skapar ett oskyddat test- eller produktionskluster.
ClusterConfig.Windows.DevCluster.json och ClusterConfig.Windows.MultiMachine.json visar hur du skapar test- eller produktionskluster som skyddas med hjälp av Windows-säkerhet.
ClusterConfig.X509.DevCluster.json och ClusterConfig.X509.MultiMachine.json visar hur du skapar test- eller produktionskluster som skyddas med hjälp av X509-certifikatbaserad säkerhet.
Nu ska vi undersöka de olika avsnitten i en ClusterConfig.json-fil.
Allmänna klusterkonfigurationer
Allmänna klusterkonfigurationer omfattar de breda klusterspecifika konfigurationerna, som du ser i följande JSON-kodfragment:
"name": "SampleCluster",
"clusterConfigurationVersion": "1.0.0",
"apiVersion": "01-2017",
Du kan ge service fabric-klustret ett eget namn genom att tilldela det till namnvariabeln. ClusterConfigurationVersion är klustrets versionsnummer. Öka den varje gång du uppgraderar Service Fabric-klustret. Låt apiVersion vara inställt på standardvärdet.
Noder i klustret
Du kan konfigurera noderna i Service Fabric-klustret med hjälp av nodavsnittet, som följande kodfragment visar:
"nodes": [{
"nodeName": "vm0",
"iPAddress": "localhost",
"nodeTypeRef": "NodeType0",
"faultDomain": "fd:/dc1/r0",
"upgradeDomain": "UD0"
}, {
"nodeName": "vm1",
"iPAddress": "localhost",
"nodeTypeRef": "NodeType1",
"faultDomain": "fd:/dc1/r1",
"upgradeDomain": "UD1"
}, {
"nodeName": "vm2",
"iPAddress": "localhost",
"nodeTypeRef": "NodeType2",
"faultDomain": "fd:/dc1/r2",
"upgradeDomain": "UD2"
}],
Ett Service Fabric-kluster måste innehålla minst tre noder. Du kan lägga till fler noder i det här avsnittet enligt din konfiguration. I följande tabell beskrivs konfigurationsinställningar för varje nod:
| Nodkonfiguration | Beskrivning |
|---|---|
| nodeName | Du kan ge noden valfritt eget namn. |
| Ip | Ta reda på IP-adressen för noden genom att öppna ett kommandofönster och skriva ipconfig. Anteckna IPV4-adressen och tilldela den till variabeln iPAddress. |
| nodeTypeRef | Varje nod kan tilldelas en annan nodtyp. Nodtyperna definieras i följande avsnitt. |
| faultDomain | Feldomäner gör det möjligt för klusteradministratörer att definiera de fysiska noder som kan misslyckas samtidigt på grund av delade fysiska beroenden. |
| upgradeDomain | Uppgraderingsdomäner beskriver uppsättningar av noder som stängs av för Service Fabric-uppgraderingar ungefär samtidigt. Du kan välja vilka noder som ska tilldelas till vilka uppgraderingsdomäner, eftersom de inte begränsas av några fysiska krav. |
Klusteregenskaper
Avsnittet egenskaper i ClusterConfig.json används för att konfigurera klustret enligt följande:
Tillförlitlighet
Begreppet tillförlitlighetLevel definierar antalet repliker eller instanser av Service Fabric-systemtjänsterna som kan köras på klustrets primära noder. Den avgör tillförlitligheten för dessa tjänster och därmed klustret. Värdet beräknas av systemet när klustret skapas och uppgraderas.
Diagnostik
I avsnittet diagnosticsStore kan du konfigurera parametrar för att aktivera diagnostik och felsöka nod- eller klusterfel, enligt följande kodfragment:
"diagnosticsStore": {
"metadata": "Please replace the diagnostics store with an actual file share accessible from all cluster machines.",
"dataDeletionAgeInDays": "7",
"storeType": "FileShare",
"IsEncrypted": "false",
"connectionstring": "c:\\ProgramData\\SF\\DiagnosticsStore"
}
Metadata är en beskrivning av klusterdiagnostiken och kan anges enligt konfigurationen. Dessa variabler hjälper dig att samla in ETW-spårningsloggar och kraschdumpar samt prestandaräknare. Mer information om ETW-spårningsloggar finns i Spårningslogg och ETW-spårning. Alla loggar, inklusive kraschdumpar och prestandaräknare, kan dirigeras till mappen connectionString på datorn. Du kan också använda AzureStorage för att lagra diagnostik. Se följande exempelfragment:
"diagnosticsStore": {
"metadata": "Please replace the diagnostics store with an actual file share accessible from all cluster machines.",
"dataDeletionAgeInDays": "7",
"storeType": "AzureStorage",
"IsEncrypted": "false",
"connectionstring": "xstore:DefaultEndpointsProtocol=https;AccountName=[AzureAccountName];AccountKey=[AzureAccountKey]"
}
Säkerhet
Säkerhetsavsnittet är nödvändigt för ett säkert fristående Service Fabric-kluster. Följande kodfragment visar en del av det här avsnittet:
"security": {
"metadata": "This cluster is secured using X509 certificates.",
"ClusterCredentialType": "X509",
"ServerCredentialType": "X509",
. . .
}
Metadata är en beskrivning av ditt säkra kluster och kan anges enligt din konfiguration. ClusterCredentialType och ServerCredentialType avgör vilken typ av säkerhet klustret och noderna implementerar. De kan anges till antingen X509 för en certifikatbaserad säkerhet eller Windows för Active Directory-baserad säkerhet. Resten av säkerhetsavsnittet baseras på typen av säkerhet. Information om hur du fyller i resten av säkerhetsavsnittet finns i Certifikatbaserad säkerhet i ett fristående kluster eller Windows-säkerhet i ett fristående kluster.
Nodtyper
I avsnittet nodeTypes beskrivs vilken typ av noder klustret har. Minst en nodtyp måste anges för ett kluster, enligt följande kodfragment:
"nodeTypes": [{
"name": "NodeType0",
"clientConnectionEndpointPort": "19000",
"clusterConnectionEndpointPort": "19001",
"leaseDriverEndpointPort": "19002",
"serviceConnectionEndpointPort": "19003",
"httpGatewayEndpointPort": "19080",
"reverseProxyEndpointPort": "19081",
"applicationPorts": {
"startPort": "20575",
"endPort": "20605"
},
"ephemeralPorts": {
"startPort": "20606",
"endPort": "20861"
},
"isPrimary": true
}]
Namnet är det egna namnet för den här nodtypen. Om du vill skapa en nod av den här nodtypen tilldelar du dess egna namn till nodeTypeRef-variabeln för den noden, som tidigare nämnts. För varje nodtyp definierar du de anslutningsslutpunkter som används. Du kan välja valfritt portnummer för dessa anslutningsslutpunkter, så länge de inte står i konflikt med andra slutpunkter i det här klustret. I ett multinodkluster finns det en eller flera primära noder (dvs. isPrimary är inställt på true), beroende på tillförlitlighetNivå. Mer information om primära och icke-primära nodtyper finns i Överväganden för kapacitetsplanering för Service Fabric-kluster för information om nodeTypes och reliabilityLevel.
Slutpunkter som används för att konfigurera nodtyperna
- clientConnectionEndpointPort är den port som används av klienten för att ansluta till klustret när klient-API:er används.
- clusterConnectionEndpointPort är porten där noderna kommunicerar med varandra.
- leaseDriverEndpointPort är den port som används av drivrutinen för klusterlån för att ta reda på om noderna fortfarande är aktiva.
- serviceConnectionEndpointPort är den port som används av de program och tjänster som distribueras på en nod för att kommunicera med Service Fabric-klienten på den specifika noden.
- httpGatewayEndpointPort är den port som används av Service Fabric Explorer för att ansluta till klustret.
- ephemeralPorts åsidosätter de dynamiska portar som används av operativsystemet. Service Fabric använder en del av dessa portar som programportar och de återstående är tillgängliga för operativsystemet. Det mappar även det här intervallet till det befintliga intervallet som finns i operativsystemet, så för alla ändamål kan du använda de intervall som anges i JSON-exempelfilerna. Kontrollera att skillnaden mellan start- och slutportarna är minst 255. Du kan stöta på konflikter om den här skillnaden är för låg, eftersom det här intervallet delas med operativsystemet. Om du vill se det konfigurerade dynamiska portintervallet kör du
netsh int ipv4 show dynamicport tcp. - applicationPorts är de portar som används av Service Fabric-programmen. Programmets portintervall bör vara tillräckligt stort för att täcka slutpunktskravet för dina program. Det här intervallet bör vara exklusivt från det dynamiska portintervallet på datorn, d.v.s. intervallet ephemeralPorts enligt konfigurationen. Service Fabric använder dessa portar när nya portar krävs och tar hand om att öppna brandväggen för dessa portar.
- reverseProxyEndpointPort är en valfri omvänd proxyslutpunkt. Mer information finns i Omvänd Proxy för Service Fabric.
Logginställningar
I avsnittet fabricSettings kan du ange rotkatalogerna för Service Fabric-data och -loggar. Du kan bara anpassa dessa kataloger när du skapar det första klustret. Se följande exempelfragment i det här avsnittet:
"fabricSettings": [{
"name": "Setup",
"parameters": [{
"name": "FabricDataRoot",
"value": "C:\\ProgramData\\SF"
}, {
"name": "FabricLogRoot",
"value": "C:\\ProgramData\\SF\\Log"
}]
Vi rekommenderar att du använder en icke-OS-enhet som FabricDataRoot och FabricLogRoot. Det ger mer tillförlitlighet för att undvika situationer när operativsystemet slutar svara. Om du bara anpassar dataroten placeras loggroten en nivå under dataroten.
Tillståndskänsliga inställningar för Reliable Services
I avsnittet KtlLogger kan du ange globala konfigurationsinställningar för Reliable Services. Mer information om de här inställningarna finns i Konfigurera tillståndskänsliga tillförlitliga tjänster. I följande exempel visas hur du ändrar den delade transaktionsloggen som skapas för att stödja tillförlitliga samlingar för tillståndskänsliga tjänster:
"fabricSettings": [{
"name": "KtlLogger",
"parameters": [{
"name": "SharedLogSizeInMB",
"value": "4096"
}]
}]
Tilläggsfunktioner
Om du vill konfigurera tilläggsfunktioner konfigurerar du apiVersion som 04–2017 eller senare och konfigurerar addonFeatures enligt följande:
"apiVersion": "04-2017",
"properties": {
"addOnFeatures": [
"DnsService",
"RepairManager"
]
}
Alla tillgängliga tilläggsfunktioner visas i REST API-referensen för Service Fabric.
Stöd för containrar
Om du vill aktivera containerstöd för både Windows Server-containrar och Hyper-V-containrar för fristående kluster måste tilläggsfunktionen DnsService vara aktiverad.
Nästa steg
När du har en fullständig ClusterConfig.json-fil konfigurerad enligt den fristående klusterkonfigurationen kan du distribuera klustret. Följ stegen i Skapa ett fristående Service Fabric-kluster.
Om du har ett fristående kluster distribuerat kan du även uppgradera konfigurationen av ett fristående kluster.
Lär dig hur du visualiserar klustret med Service Fabric Explorer.