Uw zelfstandige Service Fabric-clusterimplementatie plannen en voorbereiden
Voer de volgende stappen uit voordat u uw cluster maakt.
Uw clusterinfrastructuur plannen
U staat op het punt om een Service Fabric-cluster te maken op machines waarvan u de eigenaar bent, zodat u kunt bepalen welke soorten fouten het cluster moet overleven. Hebt u bijvoorbeeld afzonderlijke voedingslijnen of internetverbinding nodig die aan deze machines worden geleverd? Houd bovendien rekening met de fysieke beveiliging van deze machines. Waar bevinden de machines zich en wie heeft toegang tot deze machines nodig? Nadat u deze beslissingen hebt genomen, kunt u de machines logisch toewijzen aan verschillende foutdomeinen (zie volgende stap). De infrastructuurplanning voor productieclusters is meer betrokken dan voor testclusters.
Het aantal foutdomeinen en upgradedomeinen bepalen
Een foutdomein (FD) is een fysieke storingseenheid en is rechtstreeks gerelateerd aan de fysieke infrastructuur in de datacenters. Een foutdomein bestaat uit hardwareonderdelen (computers, switches, netwerken en meer) die één storingspunt delen. Hoewel er geen 1:1-toewijzing tussen foutdomeinen en racks bestaat, kan elk rek losjes worden beschouwd als een foutdomein.
Wanneer u FD's opgeeft in ClusterConfig.json, kunt u de naam voor elke FD kiezen. Service Fabric ondersteunt hiërarchische FD's, zodat u uw infrastructuurtopologie hierin kunt weergeven. De volgende FD's zijn bijvoorbeeld geldig:
- "faultDomain": "fd:/Room1/Rack1/Machine1"
- "faultDomain": "fd:/FD1"
- "faultDomain": "fd:/Room1/Rack1/PDU1/M1"
Een upgradedomein (UD) is een logische eenheid van knooppunten. Tijdens georgradeerde Service Fabric-upgrades (een upgrade van een toepassing of een clusterupgrade) worden alle knooppunten in een UD verwijderd om de upgrade uit te voeren terwijl knooppunten in andere UD's beschikbaar blijven om aanvragen te verwerken. De firmware-upgrades die u op uw computers uitvoert, voldoen niet aan UD's, dus u moet ze één machine tegelijk doen.
De eenvoudigste manier om na te denken over deze concepten is om FD's te beschouwen als de eenheid van ongeplande storingen en UD's als eenheid van gepland onderhoud.
Wanneer u UD's opgeeft in ClusterConfig.json, kunt u de naam voor elke UD kiezen. De volgende namen zijn bijvoorbeeld geldig:
- "upgradeDomain": "UD0"
- "upgradeDomain": "UD1A"
- "upgradeDomain": "DomainRed"
- "upgradeDomain": "Blauw"
Zie Beschrijving van een Service Fabric-cluster voor meer gedetailleerde informatie over FD's en UD's.
Een cluster in productie moet ten minste drie FD's omvatten om te worden ondersteund in een productieomgeving, als u volledige controle hebt over het onderhoud en beheer van de knooppunten, dat wil gezegd, bent u verantwoordelijk voor het bijwerken en vervangen van machines. Voor clusters die worden uitgevoerd in omgevingen (dat wil gezegd Amazon Web Services VM-exemplaren) waarvoor u geen volledige controle over de machines hebt, moet u minimaal vijf FD's in uw cluster hebben. Elke FD kan een of meer knooppunten hebben. Dit is om problemen te voorkomen die worden veroorzaakt door machineupgrades en -updates, die, afhankelijk van hun timing, de uitvoering van toepassingen en services in clusters kunnen verstoren.
De oorspronkelijke clustergrootte bepalen
Over het algemeen wordt het aantal knooppunten in uw cluster bepaald op basis van de behoeften van uw bedrijf, dat wil zeggen hoeveel services en containers op het cluster worden uitgevoerd en hoeveel resources u nodig hebt om uw workloads te ondersteunen. Voor productieclusters wordt u aangeraden ten minste vijf knooppunten in uw cluster te hebben, met 5 FD's. Zoals hierboven beschreven, moet u echter ook de taak uitvoeren als u volledige controle hebt over uw knooppunten en drie FD's kan omvatten.
Testclusters met stateful workloads moeten drie knooppunten hebben, terwijl testclusters die alleen stateless workloads uitvoeren slechts één knooppunt nodig hebben. Er moet ook worden opgemerkt dat u voor ontwikkelingsdoeleinden meer dan één knooppunt op een bepaalde computer kunt hebben. In een productieomgeving ondersteunt Service Fabric echter slechts één knooppunt per fysieke of virtuele machine.
De machines voorbereiden die als knooppunten fungeren
Hier volgen aanbevolen specificaties voor machines in een Service Fabric-cluster:
- Minimaal 16 GB RAM
- Minimaal 40 GB beschikbare schijfruimte
- Een 4 kern of een hoger CPU-gebruik
- Connectiviteit met een beveiligd netwerk of netwerken voor alle computers
- Windows Server-besturingssysteem geïnstalleerd (geldige versies: 2012 R2, 2016, 1709 of 1803). Service Fabric versie 6.4.654.9590 en hoger ondersteunt ook Server 2019 en 1809.
- .NET Framework 4.5.1 of hoger, volledige installatie
- Windows PowerShell 3.0
- De RemoteRegistry-service moet worden uitgevoerd op alle computers
- Service Fabric-installatiestation moet NTFS-bestandssysteem zijn
- Prestatielogboeken en waarschuwingen voor Windows-services en Windows-gebeurtenislogboeken moeten zijn ingeschakeld.
- Extern gebruikersaccountbeheer moet worden uitgeschakeld
Belangrijk
De clusterbeheerder die het cluster implementeert en configureert, moet beheerdersbevoegdheden hebben op elk van de computers. U kunt Service Fabric niet installeren op een domeincontroller.
Het zelfstandige Service Fabric-pakket voor Windows Server downloaden
Download Link - Zelfstandig Service Fabric-pakket - Windows Server en pak het pakket uit op een implementatiecomputer die geen deel uitmaakt van het cluster of naar een van de computers die deel uitmaken van uw cluster.
Clusterconfiguratie wijzigen
Als u een zelfstandig cluster wilt maken, moet u een zelfstandig clusterconfiguratie ClusterConfig.json bestand maken, waarin de specificatie van het cluster wordt beschreven. U kunt het configuratiebestand baseren op de sjablonen die u op de onderstaande koppeling vindt.
Zelfstandige clusterconfiguraties
Zie Configuratie-instellingen voor een zelfstandig Windows-cluster voor meer informatie over de secties in dit bestand.
Open een van de ClusterConfig.json bestanden uit het pakket dat u hebt gedownload en wijzig de volgende instellingen:
Configuratie-instelling | Beschrijving |
---|---|
NodeTypes | Met knooppunttypen kunt u uw clusterknooppunten scheiden in verschillende groepen. Een cluster moet ten minste één NodeType hebben. Alle knooppunten in een groep hebben de volgende algemene kenmerken: Naam : dit is de naam van het knooppunttype. Eindpuntpoorten : dit zijn benoemde eindpunten (poorten) die zijn gekoppeld aan dit knooppunttype. U kunt elk gewenst poortnummer gebruiken, zolang ze niet conflicteren met iets anders in dit manifest en nog niet worden gebruikt door een andere toepassing die wordt uitgevoerd op de machine/VM. Plaatsingseigenschappen : deze beschrijven eigenschappen voor dit knooppunttype dat u gebruikt als plaatsingsbeperkingen voor de systeemservices of uw services. Deze eigenschappen zijn door de gebruiker gedefinieerde sleutel-waardeparen die extra metagegevens bieden voor een bepaald knooppunt. Voorbeelden van knooppunteigenschappen zijn of het knooppunt een harde schijf of grafische kaart heeft, het aantal spindels op de harde schijf, kernen en andere fysieke eigenschappen. Capaciteiten : knooppuntcapaciteiten definiëren de naam en hoeveelheid van een bepaalde resource die een bepaald knooppunt beschikbaar heeft voor verbruik. Een knooppunt kan bijvoorbeeld definiëren dat het capaciteit heeft voor een metrische waarde met de naam 'MemoryInMb' en dat het standaard 2048 MB beschikbaar is. Deze capaciteiten worden tijdens runtime gebruikt om ervoor te zorgen dat services waarvoor bepaalde hoeveelheden resources zijn vereist, worden geplaatst op de knooppunten met die resources die beschikbaar zijn in de vereiste bedragen. IsPrimary : als u meer dan één NodeType hebt gedefinieerd, moet u ervoor zorgen dat er slechts één is ingesteld op primair met de waarde true. Dit is waar de systeemservices worden uitgevoerd. Alle andere knooppunttypen moeten worden ingesteld op de waarde false |
Knooppunten | Dit zijn de details voor elk van de knooppunten die deel uitmaken van het cluster (knooppunttype, knooppuntnaam, IP-adres, foutdomein en upgradedomein van het knooppunt). De machines waarop u het cluster wilt maken, moeten hier worden vermeld met hun IP-adressen. Als u hetzelfde IP-adres voor alle knooppunten gebruikt, wordt er een éénvakcluster gemaakt, dat u kunt gebruiken voor testdoeleinden. Gebruik geen one-box-clusters voor het implementeren van productieworkloads. |
Nadat de clusterconfiguratie alle instellingen voor de omgeving heeft geconfigureerd, kan deze worden getest op basis van de clusteromgeving (stap 7).
Omgeving instellen
Wanneer een clusterbeheerder een zelfstandig Service Fabric-cluster configureert, moet de omgeving worden ingesteld met de volgende criteria:
De gebruiker die het cluster maakt, moet beveiligingsbevoegdheden op beheerdersniveau hebben voor alle computers die worden vermeld als knooppunten in het clusterconfiguratiebestand.
De computer waarop het cluster wordt gemaakt, evenals elke clusterknooppuntmachine moet:
- Service Fabric SDK verwijderen
- Service Fabric-runtime verwijderen
- Zorg ervoor dat de Windows Firewall-service (mpssvc) is ingeschakeld
- De Remote Registry-service (extern register) hebben ingeschakeld
- Bestandsdeling (SMB) is ingeschakeld
- De benodigde poorten hebben geopend op basis van clusterconfiguratiepoorten
- Vereiste poorten hebben geopend voor windows SMB- en remote registry-service: 135, 137, 138, 139 en 445
- Netwerkconnectiviteit met elkaar hebben
Geen van de clusterknooppuntcomputers moet een domeincontroller zijn.
Als het cluster dat moet worden geïmplementeerd een beveiligd cluster is, controleert u of de vereiste beveiligingsvereisten aanwezig zijn en juist zijn geconfigureerd voor de configuratie.
Als de clustercomputers niet toegankelijk zijn voor internet, stelt u het volgende in de clusterconfiguratie in:
- Telemetrie uitschakelen: onder eigenschappenset 'enableTelemetry': false
- Schakel het automatisch downloaden van infrastructuurversies uit en meldingen dat de huidige clusterversie bijna eindigt op het einde van de ondersteuning: onder eigenschappen ingesteld 'fabricClusterAutoupgradeEnabled': false
- Als internettoegang via het netwerk beperkt is tot toegestane domeinen, zijn de onderstaande domeinen ook vereist voor automatische upgrade: go.microsoft.com download.microsoft.com
Stel de juiste Service Fabric-antivirusuitsluitingen in:
Uitgesloten antivirusmappen |
---|
Program Files\Microsoft Service Fabric |
FabricDataRoot (van clusterconfiguratie) |
FabricLogRoot (van clusterconfiguratie) |
Uitgesloten antivirusprocessen |
---|
Fabric.exe |
FabricHost.exe |
FabricInstallerService.exe |
FabricSetup.exe |
FabricDeployer.exe |
ImageBuilder.exe |
FabricGateway.exe |
FabricDCA.exe |
FabricFAS.exe |
FabricUOS.exe |
FabricRM.exe |
FileStoreService.exe |
Omgeving valideren met behulp van TestConfiguration-script
Het Script TestConfiguration.ps1 vindt u in het zelfstandige pakket. Het wordt gebruikt als Best Practices Analyzer om een aantal van de bovenstaande criteria te valideren en moet worden gebruikt als een sanity-controle om te valideren of een cluster kan worden geïmplementeerd in een bepaalde omgeving. Als er een fout optreedt, raadpleegt u de lijst onder Omgevingsinstellingen voor probleemoplossing.
Dit script kan worden uitgevoerd op elke computer die beheerderstoegang heeft tot alle computers die worden vermeld als knooppunten in het clusterconfiguratiebestand. De computer waarop dit script wordt uitgevoerd, hoeft geen deel uit te maken van het cluster.
PS C:\temp\Microsoft.Azure.ServiceFabric.WindowsServer> .\TestConfiguration.ps1 -ClusterConfigFilePath .\ClusterConfig.Unsecure.DevCluster.json
Trace folder already exists. Traces will be written to existing trace folder: C:\temp\Microsoft.Azure.ServiceFabric.WindowsServer\DeploymentTraces
Running Best Practices Analyzer...
Best Practices Analyzer completed successfully.
LocalAdminPrivilege : True
IsJsonValid : True
IsCabValid : True
RequiredPortsOpen : True
RemoteRegistryAvailable : True
FirewallAvailable : True
RpcCheckPassed : True
NoConflictingInstallations : True
FabricInstallable : True
Passed : True
Op dit moment valideert deze module voor het testen van de configuratie de beveiligingsconfiguratie niet, dus dit moet onafhankelijk worden uitgevoerd.
Notitie
We brengen voortdurend verbeteringen aan om deze module robuuster te maken, dus als er een foutieve of ontbrekende zaak is die u denkt dat deze momenteel niet wordt gedetecteerd door TestConfiguration, laat het ons dan weten via onze ondersteuningskanalen.