Vanliga frågor och svar om Service Fabric

  • Artikel

Det finns många vanliga frågor om vad Service Fabric kan göra och hur det ska användas. Det här dokumentet beskriver många av dessa vanliga frågor och deras svar.

Kommentar

Vi rekommenderar att du använder Azure Az PowerShell-modulen för att interagera med Azure. Se Installera Azure PowerShell för att komma igång. Information om hur du migrerar till Az PowerShell-modulen finns i artikeln om att migrera Azure PowerShell från AzureRM till Az.

Konfiguration och hantering av kluster

Hur gör jag för att återställa mitt Service Fabric-klustercertifikat?

För att återställa en uppgradering till ditt program krävs hälsofelidentifiering innan ditt Service Fabric-klusterkvorum genomför ändringen. incheckade ändringar kan bara rullas framåt. Eskaleringstekniker via kundsupport kan behöva återställa klustret om en icke övervakad icke-övervakad icke-kontrollerad ändring av certifikatet har införts. Service Fabrics programuppgradering tillämpar programuppgraderingsparametrar och ger noll avbrottsuppgraderingslöfte. Efter vårt rekommenderade övervakningsläge för programuppgradering baseras automatiska förlopp via uppdateringsdomäner på hälsokontroller som skickas, och återställs automatiskt om uppdateringen av en standardtjänst misslyckas.

Om klustret fortfarande använder den klassiska egenskapen Certificate Thumbprint i Resource Manager-mallen rekommenderar vi att du ändrar kluster från tumavtryck för certifikat till eget namn för att använda moderna funktioner för hantering av hemligheter.

Kan jag skapa ett kluster som sträcker sig över flera Azure-regioner eller mina egna datacenter?

Ja.

Kärntekniken för Service Fabric-klustring kan användas för att kombinera datorer som körs var som helst i världen, så länge de har nätverksanslutning till varandra. Det kan dock vara komplicerat att skapa och köra ett sådant kluster.

Om du är intresserad av det här scenariot rekommenderar vi att du kontaktar dig antingen via Service Fabric GitHub-problemlistan eller via din supportrepresentant för att få ytterligare vägledning. Service Fabric-teamet arbetar för att ge ytterligare klarhet, vägledning och rekommendationer för det här scenariot.

Några saker som du bör tänka på:

  1. Service Fabric-klusterresursen i Azure är regional i dag, liksom de vm-skalningsuppsättningar som klustret bygger på. Det innebär att om det uppstår ett regionalt fel kan du förlora möjligheten att hantera klustret via Azure Resource Manager eller Azure-portalen. Detta kan inträffa även om klustret fortfarande körs och du kan interagera med det direkt. Dessutom erbjuder Azure idag inte möjligheten att ha ett enda virtuellt nätverk som kan användas i flera regioner. Det innebär att ett kluster med flera regioner i Azure kräver antingen offentliga IP-adresser för varje virtuell dator i vm-skalningsuppsättningarna eller Azure VPN Gateways. Dessa nätverksval har olika inverkan på kostnader, prestanda och till viss del programdesign, så noggrann analys och planering krävs innan du står upp för en sådan miljö.
  2. Underhåll, hantering och övervakning av dessa datorer kan bli komplicerat, särskilt när de omfattar olika typer av miljöer, till exempel mellan olika molnleverantörer eller mellan lokala resurser och Azure. Se till att uppgraderingar, övervakning, hantering och diagnostik förstås för både klustret och programmen innan du kör produktionsarbetsbelastningar i en sådan miljö. Om du redan har erfarenhet av att lösa dessa problem i Azure eller i dina egna datacenter är det troligt att samma lösningar kan användas när du skapar eller kör Service Fabric-klustret.

Tar Service Fabric-noder automatiskt emot OS-uppdateringar?

Du kan använda funktionen Virtual Machine Scale Set Automatic OS Image Update Allmänt tillgänglig i dag.

För kluster som INTE körs i Azure har vi tillhandahållit ett program för att korrigera operativsystemen under dina Service Fabric-noder.

Kan jag använda stora vm-skalningsuppsättningar i mitt SF-kluster?

Kort svar – Nej.

Long Answer – Även om de stora vm-skalningsuppsättningarna gör att du kan skala en vm-skalningsuppsättning upp till 1 000 VM-instanser, gör den det med hjälp av placeringsgrupper (PG). Feldomäner (FD) och uppgraderingsdomäner (UD: er) är endast konsekventa inom en placeringsgrupp Service Fabric använder FD:er och UD:er för att fatta placeringsbeslut för dina tjänstrepliker/tjänstinstanser. Eftersom FD:erna och UD:erna endast är jämförbara inom en placeringsgrupp kan SF inte använda den. Om VM1 i PG1 till exempel har topologin FD=0 och VM9 i PG2 har en topologi av FD=4 betyder det inte att VM1 och VM2 finns på två olika maskinvarurack, därför kan SF inte använda FD-värdena i det här fallet för att fatta placeringsbeslut.

Det finns andra problem med stora vm-skalningsuppsättningar för närvarande, till exempel bristen på stöd för belastningsutjämning på nivå 4. Mer information om storskaliga uppsättningar finns i

Vilken är den minsta storleken på ett Service Fabric-kluster? Varför kan den inte vara mindre?

Den minsta storlek som stöds för ett Service Fabric-kluster som kör produktionsarbetsbelastningar är fem noder. För utvecklingsscenarier stöder vi en nod (optimerad för snabb utveckling i Visual Studio) och fem nodkluster.

Vi kräver att ett produktionskluster har minst fem noder på grund av följande tre orsaker:

  1. Även när inga användartjänster körs kör ett Service Fabric-kluster en uppsättning tillståndskänsliga systemtjänster, inklusive namngivningstjänsten och redundanshanteringstjänsten. Dessa systemtjänster är viktiga för att klustret ska kunna fortsätta att fungera.
  2. Vi placerar alltid en replik av en tjänst per nod, så klusterstorleken är den övre gränsen för antalet repliker som en tjänst (faktiskt en partition) kan ha.
  3. Eftersom en klusteruppgradering tar bort minst en nod vill vi ha en buffert på minst en nod. Därför vill vi att ett produktionskluster ska ha minst två noder utöver det minsta antalet. Minimivärdet är kvorumstorleken för en systemtjänst enligt beskrivningen nedan.

Vi vill att klustret ska vara tillgängligt vid samtidiga fel på två noder. För att ett Service Fabric-kluster ska vara tillgängligt måste systemtjänsterna vara tillgängliga. Tillståndskänsliga systemtjänster som namngivningstjänst och redundanshanteringstjänst, som spårar vilka tjänster som har distribuerats till klustret och var de finns för närvarande, beror på stark konsekvens. Denna starka konsekvens beror i sin tur på möjligheten att förvärva ett kvorum för varje given uppdatering av tillståndet för dessa tjänster, där ett kvorum representerar en strikt majoritet av replikerna (N/2 +1) för en viss tjänst. Om vi vill vara motståndskraftiga mot samtidig förlust av två noder (därmed samtidig förlust av två repliker av en systemtjänst), måste vi ha ClusterSize – QuorumSize >= 2, vilket tvingar den minsta storleken att vara fem. Tänk på att klustret har N-noder och att det finns N-repliker av en systemtjänst – en på varje nod. Kvorumstorleken för en systemtjänst är (N/2 + 1). Ovanstående ojämlikhet ser ut som N - (N/2 + 1) >= 2. Det finns två fall att tänka på: när N är jämnt och när N är udda. Om N är jämnt, säg N = 2*m där m >= 1, ser ojämlikheten ut som 2*m - (2*m/2 + 1) >= 2 eller m >= 3. Minimivärdet för N är 6 och det uppnås när m = 3. Om N å andra sidan är udda, säg N = 2*m+1 där m >= 1, ser ojämlikheten ut som 2*m+1 - ( (2*m+1)/2 + 1 ) >= 2 eller 2*m+1 - (m+1) >= 2 eller m >= 2. Minimivärdet för N är 5 och det uppnås när m = 2. Därför är minimivärdet 5 bland alla värden för N som uppfyller ojämlikheten ClusterSize – QuorumSize >= 2.

Observera att vi i argumentet ovan har antagit att varje nod har en replik av en systemtjänst, vilket innebär att kvorumstorleken beräknas baserat på antalet noder i klustret. Men genom att ändra TargetReplicaSetSize kan vi göra kvorumstorleken mindre än (N/2+1) vilket kan ge intrycket att vi kan ha ett kluster som är mindre än 5 noder och fortfarande har 2 extra noder över kvorumstorleken. Om vi till exempel anger TargetReplicaSetSize till 3 i ett 4-nodkluster är kvorumstorleken baserat på TargetReplicaSetSize (3/2 + 1) eller 2, vilket innebär att vi har ClusterSize – QuorumSize = 4-2 >= 2. Vi kan dock inte garantera att systemtjänsten ligger vid eller över kvorumet om vi förlorar några noder samtidigt. Det kan vara så att de två noder som vi förlorade var värdar för två repliker, så systemtjänsten hamnar i kvorumförlust (med bara en enskild replik kvar) och blir otillgänglig.

Med den bakgrunden ska vi undersöka några möjliga klusterkonfigurationer:

En nod: det här alternativet ger inte hög tillgänglighet eftersom förlusten av den enskilda noden av någon anledning innebär att hela klustret går förlorade.

Två noder: ett kvorum för en tjänst som distribueras över två noder (N = 2) är 2 (2/2 + 1 = 2). När en enskild replik går förlorad är det omöjligt att skapa ett kvorum. Eftersom en tjänstuppgradering kräver att en replik tillfälligt tas ned är detta inte en användbar konfiguration.

Tre noder: med tre noder (N=3) är kravet på att skapa ett kvorum fortfarande två noder (3/2 + 1 = 2). Det innebär att du kan förlora en enskild nod och fortfarande behålla kvorumet, men samtidiga fel på två noder gör att systemtjänsterna blir kvorumförluster och gör att klustret blir otillgängligt.

Fyra noder: med fyra noder (N=4) är kravet på att skapa ett kvorum tre noder (4/2 + 1 = 3). Det innebär att du kan förlora en enskild nod och fortfarande behålla kvorumet, men samtidiga fel på två noder gör att systemtjänsterna blir kvorumförluster och gör att klustret blir otillgängligt.

Fem noder: med fem noder (N=5) är kravet på att skapa ett kvorum fortfarande tre noder (5/2 + 1 = 3). Det innebär att du kan förlora två noder samtidigt och ändå behålla kvorum för systemtjänsterna.

För produktionsarbetsbelastningar måste du vara motståndskraftig mot samtidiga fel på minst två noder (till exempel en på grund av klusteruppgradering, en på grund av andra orsaker), så fem noder krävs.

Kan jag stänga av mitt kluster på nätter/helger för att spara kostnader?

I allmänhet, nej. Service Fabric lagrar tillstånd på lokala, tillfälliga diskar, vilket innebär att om den virtuella datorn flyttas till en annan värd flyttas inte data med den. I normal drift är det inte ett problem eftersom den nya noden uppdateras av andra noder. Men om du stoppar alla noder och startar om dem senare finns det en betydande möjlighet att de flesta noderna startar på nya värdar och gör att systemet inte kan återställas.

Om du vill skapa kluster för att testa ditt program innan det distribueras rekommenderar vi att du dynamiskt skapar dessa kluster som en del av pipelinen för kontinuerlig integrering/kontinuerlig distribution.

Hur gör jag för att uppgradera mitt operativsystem (till exempel från Windows Server 2012 till Windows Server 2016)?

Medan vi arbetar med en förbättrad upplevelse är du idag ansvarig för uppgraderingen. Du måste uppgradera OS-avbildningen på de virtuella datorerna i klustret en virtuell dator i taget.

Kan jag kryptera anslutna datadiskar i en klusternodtyp (vm-skalningsuppsättning)?

Ja. Mer information finns i Skapa ett kluster med anslutna datadiskar och Azure Disk Encryption för vm-skalningsuppsättningar.

Kan jag använda lågprioriterade virtuella datorer i en klusternodtyp (VM-skalningsuppsättning)?

Nej. Virtuella datorer med låg prioritet stöds inte.

Vilka kataloger och processer måste jag undanta när jag kör ett antivirusprogram i mitt kluster?

Undantagna kataloger för antivirus
Program Files\Microsoft Service Fabric
FabricDataRoot (från klusterkonfiguration)
FabricLogRoot (från klusterkonfiguration)
Undantagna antivirusprocesser
Fabric.exe
FabricHost.exe
FabricInstallerService.exe
FabricSetup.exe
FabricDeployer.exe
ImageBuilder.exe
FabricGateway.exe
FabricDCA.exe
FabricFAS.exe
FabricUOS.exe
FabricRM.exe
FileStoreService.exe

Hur kan mitt program autentisera till Key Vault för att hämta hemligheter?

Följande är ett sätt för ditt program att hämta autentiseringsuppgifter för autentisering till Key Vault:

A. Under bygg-/paketeringsjobbet för dina program kan du hämta ett certifikat till SF-appens datapaket och använda det för att autentisera till Key Vault. B. För MSI-aktiverade värdar för VM-skalningsuppsättningar kan du utveckla en enkel PowerShell-installationEntryPoint för din SF-app för att hämta en åtkomsttoken från MSI-slutpunkten och sedan hämta dina hemligheter från Key Vault.

Kan jag överföra min prenumeration till en annan Microsoft Entra-klientorganisation?

Nej. För tillfället skulle du behöva skapa en ny Service Fabric-klusterresurs när prenumerationen har överförts till en annan Microsoft Entra-klientorganisation.

Kan jag flytta/migrera mitt kluster mellan Microsoft Entra-klienter?

Nej. För tillfället skulle du behöva skapa en ny Service Fabric-klusterresurs under den nya klientorganisationen.

Kan jag flytta/migrera mitt kluster mellan prenumerationer?

Nej. För tillfället skulle du behöva skapa en ny Service Fabric-klusterresurs under den nya prenumerationen.

Kan jag flytta/migrera mina kluster- eller klusterresurser till andra resursgrupper eller byta namn på dem?

Nej. För tillfället skulle du behöva skapa en ny Service Fabric-klusterresurs under den nya resursgruppen/namnet.

Programdesign

Vilket är det bästa sättet att köra frågor mot data mellan partitioner i en tillförlitlig samling?

Tillförlitliga samlingar partitioneras vanligtvis för att möjliggöra utskalning för bättre prestanda och dataflöde. Det innebär att tillståndet för en viss tjänst kan spridas över tiotals eller hundratals datorer. Om du vill utföra åtgärder över den fullständiga datauppsättningen har du några alternativ:

  • Skapa en tjänst som frågar alla partitioner i en annan tjänst för att hämta nödvändiga data.
  • Skapa en tjänst som kan ta emot data från alla partitioner i en annan tjänst.
  • Skicka regelbundet data från varje tjänst till ett externt arkiv. Den här metoden är endast lämplig om de frågor som du utför inte ingår i din kärnaffärslogik, eftersom det externa arkivets data blir inaktuella.
  • Du kan också lagra data som måste ha stöd för frågor i alla poster direkt i ett datalager i stället för i en tillförlitlig samling. Detta eliminerar problemet med inaktuella data, men tillåter inte att fördelarna med tillförlitliga samlingar utnyttjas.

Vilket är det bästa sättet att fråga efter data i mina aktörer?

Aktörer är utformade för att vara oberoende enheter för tillstånd och beräkning, så det rekommenderas inte att utföra breda frågor om aktörstillstånd vid körning. Om du behöver fråga över hela uppsättningen aktörstillstånd bör du överväga något av följande:

  • Ersätta dina aktörstjänster med tillståndskänsliga tillförlitliga tjänster, så att antalet nätverksbegäranden för att samla in alla data från antalet aktörer till antalet partitioner i tjänsten.
  • Utforma dina aktörer så att de regelbundet push-överför sitt tillstånd till ett externt arkiv för enklare frågor. Som ovan är den här metoden endast användbar om de frågor du utför inte krävs för ditt körningsbeteende.

Hur mycket data kan jag lagra i en tillförlitlig samling?

Tillförlitliga tjänster partitioneras vanligtvis, så mängden du kan lagra begränsas endast av antalet datorer som du har i klustret och mängden minne som är tillgängligt på dessa datorer.

Anta till exempel att du har en tillförlitlig samling i en tjänst med 100 partitioner och 3 repliker som lagrar objekt som i genomsnitt är 1 kb stora. Anta nu att du har ett 10-datorkluster med 16 GB minne per dator. För enkelhetens skull och för att vara konservativ, anta att operativsystemet och systemtjänsterna, Service Fabric-körningen och dina tjänster förbrukar 6 GB av det, vilket ger 10 GB tillgängligt per dator eller 100 GB för klustret.

Med tanke på att varje objekt måste lagras tre gånger (en primär och två repliker) skulle du ha tillräckligt med minne för cirka 35 miljoner objekt i samlingen när du arbetar med full kapacitet. Vi rekommenderar dock att du är motståndskraftig mot samtidig förlust av en feldomän och en uppgraderingsdomän, som representerar cirka 1/3 kapacitet, och skulle minska antalet till ungefär 23 miljoner.

Den här beräkningen förutsätter också:

  • Att fördelningen av data mellan partitionerna är ungefär enhetlig eller att du rapporterar belastningsmått till Klusterresurshanteraren. Som standard läser Service Fabric in saldo baserat på antal repliker. I föregående exempel skulle det placera 10 primära repliker och 20 sekundära repliker på varje nod i klustret. Det fungerar bra för belastning som är jämnt fördelad över partitionerna. Om belastningen inte är jämn måste du rapportera inläsning så att Resource Manager kan packa ihop mindre repliker och tillåta större repliker att förbruka mer minne på en enskild nod.

  • Att den tillförlitliga tjänsten i fråga är den enda lagringstillståndet i klustret. Eftersom du kan distribuera flera tjänster till ett kluster måste du vara medveten om de resurser som var och en behöver för att köra och hantera dess tillstånd.

  • Att själva klustret inte växer eller krymper. Om du lägger till fler datorer balanserar Service Fabric om dina repliker för att utnyttja den extra kapaciteten tills antalet datorer överskrider antalet partitioner i tjänsten, eftersom en enskild replik inte kan sträcka sig över datorer. Om du däremot minskar storleken på klustret genom att ta bort datorer packas replikerna hårdare och har mindre total kapacitet.

Hur mycket data kan jag lagra i en aktör?

Precis som med tillförlitliga tjänster begränsas mängden data som du kan lagra i en aktörstjänst endast av det totala diskutrymmet och det tillgängliga minnet mellan noderna i klustret. Enskilda aktörer är dock mest effektiva när de används för att kapsla in en liten mängd tillstånd och tillhörande affärslogik. Som en allmän regel bör en enskild aktör ha tillstånd som mäts i kilobyte.

Var lagrar Azure Service Fabric-resursprovidern kunddata?

Azure Service Fabric-resursprovidern flyttar eller lagrar inte kunddata från den region som den distribueras i.

Övriga frågor

Hur relaterar Service Fabric till containrar?

Containrar erbjuder ett enkelt sätt att paketera tjänster och deras beroenden så att de körs konsekvent i alla miljöer och kan fungera på ett isolerat sätt på en enda dator. Service Fabric erbjuder ett sätt att distribuera och hantera tjänster, inklusive tjänster som har paketerats i en container.

Planerar du att öppna Service Fabric med öppen källkod?

Vi har delar med öppen källkod i Service Fabric (reliable services framework, reliable actors framework, ASP.NET Core Integration Libraries, Service Fabric Explorer och Service Fabric CLI) på GitHub och accepterar communitybidrag till dessa projekt.

Vi meddelade nyligen att vi planerar att köra Service Fabric med öppen källkod. Nu har vi Service Fabric-lagringsplatsen på GitHub med Linux-bygg- och testverktyg, vilket innebär att du kan klona lagringsplatsen, skapa Service Fabric för Linux, köra grundläggande tester, öppna problem och skicka pull-begäranden. Vi arbetar hårt för att även migrera Windows-byggmiljön, tillsammans med en komplett CI-miljö.

Följ Service Fabric-bloggen för mer information när de meddelas.

Nästa steg

Lär dig mer om Service Fabric-körningskoncept och metodtips