Delen via

Veelgestelde vragen over Service Fabric

  • Artikel

Er zijn veelgestelde vragen over wat Service Fabric kan doen en hoe het moet worden gebruikt. In dit document worden veel van deze veelgestelde vragen en hun antwoorden behandeld.

Notitie

Het wordt aanbevolen de Azure Az PowerShell-module te gebruiken om te communiceren met Azure. Zie Azure PowerShell installeren om aan de slag te gaan. Raadpleeg Azure PowerShell migreren van AzureRM naar Az om te leren hoe u naar de Azure PowerShell-module migreert.

Clusterinstallatie en -beheer

Hoe kan ik mijn Service Fabric-clustercertificaat terugdraaien?

Voor het terugdraaien van een upgrade naar uw toepassing is detectie van statusfouten vereist voordat het Service Fabric-clusterquorum de wijziging doorvoert; doorgevoerde wijzigingen kunnen alleen worden doorgevoerd. Escalatie-technicus via klantenserviceservices kan vereist zijn om uw cluster te herstellen als er iets wordt geïntroduceerd dat niet wordt bewaakt als er een wijziging in het certificaat wordt geïntroduceerd die niet wordt bewaakt. De toepassingsupgrade van Service Fabric past parameters voor toepassingsupgrade toe en levert geen belofte voor de upgrade van downtime. Na de bewaakte modus voor de aanbevolen toepassingsupgrade is automatische voortgang via updatedomeinen gebaseerd op statuscontroles die automatisch worden teruggezet als het bijwerken van een standaardservice mislukt.

Als uw cluster nog steeds de klassieke certificaatvingerafdrukeigenschap in uw Resource Manager-sjabloon gebruikt, raden we u aan het cluster te wijzigen van vingerafdruk van certificaat in algemene naam, om moderne geheimenbeheerfuncties toe te passen.

Kan ik een cluster maken dat meerdere Azure-regio's of mijn eigen datacenters omvat?

Ja.

De kerntechnologie voor Service Fabric-clustering kan worden gebruikt om machines te combineren die overal ter wereld worden uitgevoerd, zolang ze netwerkconnectiviteit met elkaar hebben. Het bouwen en uitvoeren van een dergelijk cluster kan echter ingewikkeld zijn.

Als u geïnteresseerd bent in dit scenario, raden we u aan contact te krijgen via de Service Fabric GitHub Issues List of via uw ondersteuningsmedewerker om aanvullende richtlijnen te verkrijgen. Het Service Fabric-team werkt aan aanvullende duidelijkheid, richtlijnen en aanbevelingen voor dit scenario.

Een aantal punten die u daarbij in overweging moet nemen:

  1. De Service Fabric-clusterresource in Azure is momenteel regionaal, net als de virtuele-machineschaalsets waarop het cluster is gebouwd. Dit betekent dat u in het geval van een regionale storing het cluster mogelijk niet meer kunt beheren via Azure Resource Manager of Azure Portal. Dit kan gebeuren, ook al blijft het cluster actief en kunt u er rechtstreeks mee werken. Bovendien biedt Azure momenteel niet de mogelijkheid om één virtueel netwerk te hebben dat kan worden gebruikt in verschillende regio's. Dit betekent dat voor een cluster met meerdere regio's in Azure openbare IP-adressen zijn vereist voor elke VIRTUELE machine in de virtuele-machineschaalsets of Azure VPN-gateways. Deze netwerkkeuzen hebben verschillende gevolgen voor kosten, prestaties en een zekere mate van toepassingsontwerp, dus zorgvuldige analyse en planning is vereist voordat u een dergelijke omgeving opstelt.
  2. Het onderhoud, het beheer en de bewaking van deze machines kan ingewikkeld worden, met name wanneer het gaat om verschillende typen omgevingen, zoals tussen verschillende cloudproviders of tussen on-premises resources en Azure. Zorg ervoor dat upgrades, bewaking, beheer en diagnostische gegevens worden begrepen voor zowel het cluster als de toepassingen voordat productieworkloads in een dergelijke omgeving worden uitgevoerd. Als u al ervaring hebt met het oplossen van deze problemen in Azure of in uw eigen datacenters, is het waarschijnlijk dat dezelfde oplossingen kunnen worden toegepast bij het bouwen of uitvoeren van uw Service Fabric-cluster.

Ontvangen Service Fabric-knooppunten automatisch besturingssysteemupdates?

U kunt de functie voor het automatisch bijwerken van installatiekopieën van virtuele-machineschaalsets vandaag gebruiken.

Voor clusters die NIET worden uitgevoerd in Azure, hebben we een toepassing geleverd om de besturingssystemen onder uw Service Fabric-knooppunten te patchen.

Kan ik grote virtuele-machineschaalsets gebruiken in mijn SF-cluster?

Kort antwoord - Nee.

Long Answer : hoewel u met de grote virtuele-machineschaalsets een virtuele-machineschaalset kunt schalen tot 1000 VM-exemplaren, doet dit dit door gebruik te maken van plaatsingsgroepen (PG's). Foutdomeinen (FD's) en upgradedomeinen (UD's) zijn alleen consistent binnen een plaatsingsgroep Service Fabric maakt gebruik van FD's en UD's om plaatsingsbeslissingen te nemen van uw servicereplica's/service-exemplaren. Omdat de FD's en UD's alleen binnen een plaatsingsgroep vergelijkbaar zijn, kan SF deze niet gebruiken. Als VM1 in PG1 bijvoorbeeld een topologie van FD=0 heeft en VM9 in PG2 een topologie van FD=4 heeft, betekent dit niet dat VM1 en VM2 zich op twee verschillende Hardware Racks bevinden, waardoor SF de FD-waarden in dit geval niet kan gebruiken om plaatsingsbeslissingen te nemen.

Er zijn momenteel andere problemen met grote virtuele-machineschaalsets, zoals het ontbreken van ondersteuning voor taakverdeling op niveau 4. Raadpleeg voor meer informatie over grote schaalsets

Wat is de minimale grootte van een Service Fabric-cluster? Waarom kan het niet kleiner zijn?

De minimaal ondersteunde grootte voor een Service Fabric-cluster met productieworkloads is vijf knooppunten. Voor ontwikkelscenario's ondersteunen we één knooppunt (geoptimaliseerd voor snelle ontwikkelervaring in Visual Studio) en vijf knooppuntclusters.

We hebben een productiecluster nodig om ten minste vijf knooppunten te hebben vanwege de volgende drie redenen:

  1. Zelfs wanneer er geen gebruikersservices worden uitgevoerd, voert een Service Fabric-cluster een set stateful systeemservices uit, waaronder de naamgevingsservice en de failoverbeheerservice. Deze systeemservices zijn essentieel om het cluster operationeel te houden.
  2. We plaatsen altijd één replica van een service per knooppunt, dus de clustergrootte is de bovengrens voor het aantal replica's dat een service (eigenlijk een partitie) kan hebben.
  3. Omdat een clusterupgrade ten minste één knooppunt uitvalt, willen we een buffer van ten minste één knooppunt hebben. Daarom willen we dat een productiecluster naast het minimale minimum ten minste twee knooppunten heeft. Het minimale aantal is de quorumgrootte van een systeemservice, zoals hieronder wordt uitgelegd.

We willen dat het cluster beschikbaar is vanwege gelijktijdige storing van twee knooppunten. Als een Service Fabric-cluster beschikbaar is, moeten de systeemservices beschikbaar zijn. Stateful systeemservices, zoals de naamgevingsservice en failoverbeheerservice, die bijhouden welke services zijn geïmplementeerd in het cluster en waar ze momenteel worden gehost, zijn afhankelijk van sterke consistentie. Die sterke consistentie is op zijn beurt afhankelijk van de mogelijkheid om een quorum te verkrijgen voor een bepaalde update van die services, waarbij een quorum een strikte meerderheid van de replica's (N/2 +1) vertegenwoordigt voor een bepaalde service. Dus als we bestand willen zijn tegen gelijktijdig verlies van twee knooppunten (gelijktijdig verlies van twee replica's van een systeemservice), moeten we ClusterSize - QuorumSize >= 2 hebben, waardoor de minimumgrootte vijf moet zijn.

In het bovenstaande argument hebben we ervan uitgegaan dat elk knooppunt een replica van een systeemservice heeft; De quorumgrootte wordt dus berekend op basis van het aantal knooppunten in het cluster. Door TargetReplicaSetSize te wijzigen, kunnen we de quorumgrootte echter kleiner maken dan (N/2+1), wat de indruk kan geven dat we een cluster kunnen hebben dat kleiner is dan 5 knooppunten en nog steeds 2 extra knooppunten boven de quorumgrootte hebben. Als we bijvoorbeeld in een cluster met 4 knooppunten targetReplicaSetSize instellen op 3, is de quorumgrootte op basis van TargetReplicaSetSize (3/2 + 1) of 2, dus hebben we ClusterSize - QuorumSize = 4-2 >= 2. We kunnen echter niet garanderen dat de systeemservice zich op of boven quorum zal bevinden als er tegelijkertijd twee knooppunten verloren gaan. Het kan zijn dat de twee knooppunten die we verloren twee replica's hosten, zodat de systeemservice in quorumverlies gaat (met slechts één replica links) en niet meer beschikbaar is.

Met deze achtergrond gaan we enkele mogelijke clusterconfiguraties onderzoeken:

Eén knooppunt: deze optie biedt geen hoge beschikbaarheid, omdat het verlies van het enkele knooppunt om welke reden dan ook betekent dat het hele cluster verloren gaat.

Twee knooppunten: een quorum voor een service die is geïmplementeerd op twee knooppunten (N = 2) is 2 (2/2 + 1 = 2). Wanneer één replica verloren gaat, is het onmogelijk om een quorum te maken. Omdat het uitvoeren van een service-upgrade tijdelijk een replica vereist, is dit geen nuttige configuratie.

Drie knooppunten: met drie knooppunten (N=3) is de vereiste om een quorum te maken nog steeds twee knooppunten (3/2 + 1 = 2). Dit betekent dat u een afzonderlijk knooppunt kunt verliezen en nog steeds quorum kunt onderhouden, maar gelijktijdige storing van twee knooppunten zorgt ervoor dat de systeemservices in quorumverlies worden gebracht en dat het cluster niet meer beschikbaar is.

Vier knooppunten: met vier knooppunten (N=4), is de vereiste om een quorum te maken drie knooppunten (4/2 + 1 = 3). Dit betekent dat u een afzonderlijk knooppunt kunt verliezen en nog steeds quorum kunt onderhouden, maar gelijktijdige storing van twee knooppunten zorgt ervoor dat de systeemservices in quorumverlies worden gebracht en dat het cluster niet meer beschikbaar is.

Vijf knooppunten: met vijf knooppunten (N=5), is de vereiste om een quorum te maken nog steeds drie knooppunten (5/2 + 1 = 3). Dit betekent dat u twee knooppunten tegelijk kunt verliezen en nog steeds quorum voor de systeemservices kunt onderhouden.

Voor productieworkloads moet u bestand zijn tegen gelijktijdige fouten van ten minste twee knooppunten (bijvoorbeeld een vanwege een upgrade van het cluster, een vanwege andere redenen), dus vijf knooppunten zijn vereist.

Kan ik mijn cluster 's nachts/weekend uitschakelen om kosten te besparen?

In het algemeen niet. Service Fabric slaat de status op lokale, tijdelijke schijven op, wat betekent dat als de virtuele machine naar een andere host wordt verplaatst, de gegevens er niet mee worden verplaatst. Normaal gesproken is dat geen probleem omdat het nieuwe knooppunt up-to-date wordt gebracht door andere knooppunten. Als u echter alle knooppunten stopt en ze later opnieuw opstart, is er een aanzienlijke kans dat de meeste knooppunten op nieuwe hosts beginnen en het systeem niet kan herstellen.

Als u clusters wilt maken om uw toepassing te testen voordat deze wordt geïmplementeerd, raden we u aan deze clusters dynamisch te maken als onderdeel van uw pijplijn voor continue integratie/continue implementatie.

Hoe kan ik mijn besturingssysteem upgraden (bijvoorbeeld van Windows Server 2012 naar Windows Server 2016)?

Terwijl we aan een verbeterde ervaring werken, bent u vandaag verantwoordelijk voor de upgrade. U moet de installatiekopieën van het besturingssysteem upgraden op de virtuele machines van het cluster, één vm tegelijk.

Kan ik gekoppelde gegevensschijven versleutelen in een clusterknooppunttype (virtuele-machineschaalset)?

Ja. Zie Een cluster maken met gekoppelde gegevensschijven en Azure Disk Encryption voor virtuele-machineschaalsets voor meer informatie.

Kan ik VM's met lage prioriteit gebruiken in een clusterknooppunttype (virtuele-machineschaalset)?

Nee VM's met lage prioriteit worden niet ondersteund.

Wat zijn de mappen en processen die ik moet uitsluiten bij het uitvoeren van een antivirusprogramma in mijn cluster?

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

Hoe kan mijn toepassing worden geverifieerd bij Key Vault om geheimen op te halen?

Hier volgt een middel voor uw toepassing om referenties te verkrijgen voor verificatie bij Key Vault:

A. Tijdens de build-/verpakkingstaak van uw toepassingen kunt u een certificaat ophalen in het gegevenspakket van uw SF-app en dit gebruiken om te verifiëren bij Key Vault. B. Voor msi-hosts voor virtuele-machineschaalsets kunt u een eenvoudige PowerShell SetupEntryPoint voor uw SF-app ontwikkelen om een toegangstoken op te halen uit het MSI-eindpunt en vervolgens uw geheimen op te halen uit Key Vault.

Kan ik mijn abonnement overdragen naar een andere Microsoft Entra-tenant?

Nee Op dit moment moet u een nieuwe Service Fabric-clusterresource maken nadat het abonnement is overgedragen naar een andere Microsoft Entra-tenant.

Kan ik mijn cluster verplaatsen/migreren tussen Microsoft Entra-tenants?

Nee Op dit moment moet u een nieuwe Service Fabric-clusterresource maken onder de nieuwe tenant.

Kan ik mijn cluster verplaatsen/migreren tussen abonnementen?

Nee Op dit moment moet u een nieuwe Service Fabric-clusterresource maken onder het nieuwe abonnement.

Kan ik mijn cluster- of clusterresources verplaatsen/migreren naar andere resourcegroepen of de naam ervan wijzigen?

Nee Op dit moment moet u een nieuwe Service Fabric-clusterresource maken onder de nieuwe resourcegroep/naam.

Toepassingsontwerp

Wat is de beste manier om gegevens op te vragen over partities van een betrouwbare verzameling?

Betrouwbare verzamelingen worden doorgaans gepartitioneerd om uitschalen mogelijk te maken voor betere prestaties en doorvoer. Dat betekent dat de status voor een bepaalde service kan worden verdeeld over tientallen of honderden machines. Als u bewerkingen wilt uitvoeren voor die volledige gegevensset, hebt u een aantal opties:

  • Maak een service waarmee alle partities van een andere service worden opgevraagd om de vereiste gegevens op te halen.
  • Maak een service die gegevens kan ontvangen van alle partities van een andere service.
  • Push regelmatig gegevens van elke service naar een extern archief. Deze aanpak is alleen geschikt als de query's die u uitvoert geen deel uitmaken van uw kernbedrijfslogica, omdat de gegevens van het externe archief verlopen.
  • U kunt ook gegevens opslaan die ondersteuning moeten bieden voor het rechtstreeks uitvoeren van query's in alle records in een gegevensarchief in plaats van in een betrouwbare verzameling. Dit elimineert het probleem met verouderde gegevens, maar staat niet toe dat de voordelen van betrouwbare verzamelingen worden gebruikt.

Wat is de beste manier om gegevens op te vragen in mijn actoren?

Actoren zijn ontworpen om onafhankelijke eenheden van status en rekenkracht te zijn, dus het wordt niet aanbevolen om tijdens runtime brede query's met de actorstatus uit te voeren. Als u een query moet uitvoeren op de volledige set actorstatussen, moet u rekening houden met het volgende:

  • Vervang uw actorservices door stateful betrouwbare services, zodat het aantal netwerkaanvragen om alle gegevens van het aantal actoren te verzamelen tot het aantal partities in uw service.
  • Ontwerp uw actoren om periodiek hun status naar een externe winkel te pushen, zodat u eenvoudiger query's kunt uitvoeren. Zoals hierboven is deze aanpak alleen haalbaar als de query's die u uitvoert, niet vereist zijn voor uw runtimegedrag.

Hoeveel gegevens kan ik opslaan in een betrouwbare verzameling?

Betrouwbare services worden doorgaans gepartitioneerd, dus de hoeveelheid die u kunt opslaan, wordt alleen beperkt door het aantal computers dat u in het cluster hebt en de hoeveelheid geheugen die beschikbaar is op deze computers.

Stel dat u een betrouwbare verzameling in een service hebt met 100 partities en 3 replica's, waarbij objecten met een gemiddelde grootte van 1 kB worden opgeslagen. Stel nu dat u een cluster van 10 machines hebt met 16 gb geheugen per machine. Om het eenvoudig te maken en conservatief te zijn, gaat u ervan uit dat het besturingssysteem en de systeemservices, de Service Fabric-runtime en uw services 6 gb daarvan verbruiken, waardoor 10 gb beschikbaar is per machine of 100 gb voor het cluster.

Houd er rekening mee dat elk object drie keer moet worden opgeslagen (één primaire en twee replica's), zou u voldoende geheugen hebben voor ongeveer 35 miljoen objecten in uw verzameling wanneer u op volledige capaciteit werkt. We raden u echter aan bestand te zijn tegen gelijktijdig verlies van een foutdomein en een upgradedomein, dat ongeveer 1/3 aan capaciteit vertegenwoordigt, en het aantal tot ongeveer 23 miljoen zou verminderen.

In deze berekening wordt ook uitgegaan van:

  • Dat de distributie van gegevens over de partities grofweg uniform is of dat u metrische gegevens over belasting rapporteert aan clusterbronbeheer. Service Fabric laadt standaard balans op basis van het aantal replica's. In het vorige voorbeeld zou dat 10 primaire replica's en 20 secundaire replica's op elk knooppunt in het cluster plaatsen. Dit werkt goed voor belasting die gelijkmatig over de partities wordt verdeeld. Als de belasting niet eens is, moet u de belasting rapporteren, zodat Resource Manager kleinere replica's samen kan verpakken en grotere replica's meer geheugen op een afzonderlijk knooppunt kunnen gebruiken.

  • Dat de betrouwbare service in kwestie de enige opslagstatus in het cluster is. Omdat u meerdere services in een cluster kunt implementeren, moet u rekening houden met de resources die elk nodig hebben om de status ervan uit te voeren en te beheren.

  • Dat het cluster zelf niet groeit of verkleint. Als u meer machines toevoegt, worden uw replica's in Service Fabric opnieuw verdeeld om gebruik te maken van de extra capaciteit totdat het aantal machines het aantal partities in uw service overschrijdt, omdat een afzonderlijke replica geen machines kan omvatten. Als u daarentegen de grootte van het cluster verkleint door machines te verwijderen, worden uw replica's strakker verpakt en hebben ze minder totale capaciteit.

Hoeveel gegevens kan ik opslaan in een actor?

Net als bij betrouwbare services wordt de hoeveelheid gegevens die u in een actorservice kunt opslaan, alleen beperkt door de totale schijfruimte en het beschikbare geheugen op de knooppunten in uw cluster. Afzonderlijke actoren zijn echter het effectiefst wanneer ze worden gebruikt om een kleine hoeveelheid status en bijbehorende bedrijfslogica in te kapselen. In de regel moet een afzonderlijke actor de status hebben die wordt gemeten in kilobytes.

Waar worden klantgegevens opgeslagen in Azure Service Fabric Resource Provider?

Azure Service Fabric Resource Provider verplaatst of slaat geen klantgegevens op uit de regio waarin deze is geïmplementeerd.

Andere vragen

Hoe verhoudt Service Fabric zich tot containers?

Containers bieden een eenvoudige manier om services en hun afhankelijkheden te verpakken, zodat ze consistent worden uitgevoerd in alle omgevingen en op een geïsoleerde manier op één computer kunnen werken. Service Fabric biedt een manier om services te implementeren en beheren, waaronder services die in een container zijn verpakt.

Bent u van plan om opensource Service Fabric te openen?

We hebben opensource-onderdelen van Service Fabric (reliable services framework, reliable actors framework, ASP.NET Core integration libraries, Service Fabric Explorer en Service Fabric CLI) op GitHub en accepteren communitybijdragen aan deze projecten.

We hebben onlangs aangekondigd dat we van plan zijn om de Service Fabric-runtime te openen. Op dit moment hebben we de Service Fabric-opslagplaats op GitHub met Linux-build- en testhulpprogramma's. Dit betekent dat u de opslagplaats kunt klonen, Service Fabric voor Linux kunt bouwen, basistests kunt uitvoeren, problemen kunt openen en pull-aanvragen kunt indienen. We werken er hard aan om de Windows-buildomgeving ook te migreren, samen met een volledige CI-omgeving.

Volg de Service Fabric-blog voor meer informatie zoals ze worden aangekondigd.

Volgende stappen

Meer informatie over Service Fabric-runtimeconcepten en aanbevolen procedures