Konfigurera tillståndskänsliga tillförlitliga tjänster
Det finns två uppsättningar konfigurationsinställningar för tillförlitliga tjänster. En uppsättning är global för alla tillförlitliga tjänster i klustret medan den andra uppsättningen är specifik för en viss tillförlitlig tjänst.
Global konfiguration
Den globala tillförlitliga tjänstkonfigurationen anges i klustermanifestet för klustret under avsnittet KtlLogger. Den tillåter konfiguration av den delade loggplatsen och storleken plus de globala minnesgränser som används av loggaren. Klustermanifestet är en enda XML-fil som innehåller inställningar och konfigurationer som gäller för alla noder och tjänster i klustret. Filen kallas vanligtvis ClusterManifest.xml. Du kan se klustermanifestet för klustret med hjälp av powershell-kommandot Get-ServiceFabricClusterManifest.
Konfigurationsnamn
| Name | Enhet | Standardvärde | Kommentarer |
|---|---|---|---|
| WriteBufferMemoryPoolMinimumInKB | Kilobyte | 8388608 | Minsta antal kB som ska allokeras i kernelläge för loggningsbuffertens minnespool. Den här minnespoolen används för att cachelagra tillståndsinformation innan du skriver till disken. |
| WriteBufferMemoryPoolMaximumInKB | Kilobyte | Obegränsat | Maximal storlek som loggningsbuffertminnespoolen kan växa till. |
| SharedLogId | GUID | "" | Anger ett unikt GUID som ska användas för att identifiera standardfilen för delad logg som används av alla tillförlitliga tjänster på alla noder i klustret som inte anger SharedLogId i deras tjänstspecifika konfiguration. Om SharedLogId har angetts måste även SharedLogPath anges. |
| SharedLogPath | Fullständigt kvalificerat sökvägsnamn | "" | Anger den fullständigt kvalificerade sökvägen där den delade loggfilen som används av alla tillförlitliga tjänster på alla noder i klustret som inte anger SharedLogPath i deras tjänstspecifika konfiguration. Men om SharedLogPath har angetts måste SharedLogId också anges. |
| SharedLogSizeInMB | Megabyte | 8192 | Anger antalet MB diskutrymme som ska allokeras statiskt för den delade loggen. Värdet måste vara 2048 eller större. |
I Azure ARM eller en lokal JSON-mall visar exemplet nedan 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"
}]
}]
Exempel på lokalt utvecklarklustermanifest
Om du vill ändra detta i din lokala utvecklingsmiljö måste du redigera den lokala clustermanifest.xml filen.
<Section Name="KtlLogger">
<Parameter Name="SharedLogSizeInMB" Value="4096"/>
<Parameter Name="WriteBufferMemoryPoolMinimumInKB" Value="8192" />
<Parameter Name="WriteBufferMemoryPoolMaximumInKB" Value="8192" />
<Parameter Name="SharedLogId" Value="{7668BB54-FE9C-48ed-81AC-FF89E60ED2EF}"/>
<Parameter Name="SharedLogPath" Value="f:\SharedLog.Log"/>
</Section>
Kommentarer
Loggaren har en global pool med minne som allokerats från icke-sidigt kernelminne som är tillgängligt för alla tillförlitliga tjänster på en nod för cachelagring av tillståndsdata innan den skrivs till den dedikerade loggen som är associerad med den tillförlitliga tjänstrepliken. Poolstorleken styrs av inställningarna WriteBufferMemoryPoolMinimumInKB och WriteBufferMemoryPoolMaximumInKB. WriteBufferMemoryPoolMinimumInKB anger både den ursprungliga storleken på den här minnespoolen och den lägsta storleken som minnespoolen kan krympa till. WriteBufferMemoryPoolMaximumInKB är den högsta storleken som minnespoolen kan växa till. Varje tillförlitlig tjänstreplik som öppnas kan öka storleken på minnespoolen med en systemdefinierad mängd upp till WriteBufferMemoryPoolMaximumInKB. Om det finns större efterfrågan på minne från minnespoolen än vad som är tillgängligt fördröjs begäranden om minne tills minnet är tillgängligt. Om minnespoolen för skrivbufferten därför är för liten för en viss konfiguration kan prestandan bli lidande.
Inställningarna SharedLogId och SharedLogPath används alltid tillsammans för att definiera GUID och plats för den delade standardloggen för alla noder i klustret. Den delade standardloggen används för alla tillförlitliga tjänster som inte anger inställningarna i settings.xml för den specifika tjänsten. För bästa prestanda bör delade loggfiler placeras på diskar som endast används för den delade loggfilen för att minska konkurrensen.
SharedLogSizeInMB anger hur mycket diskutrymme som ska förallokeras för den delade standardloggen på alla noder. SharedLogId och SharedLogPath behöver inte anges för att SharedLogSizeInMB ska kunna anges.
Tjänstspecifik konfiguration
Du kan ändra tillståndskänsliga Reliable Services standardkonfigurationer med hjälp av konfigurationspaketet (Config) eller tjänstimplementeringen (kod).
- Konfiguration – Konfiguration via konfigurationspaketet utförs genom att ändra den Settings.xml fil som genereras i Microsoft Visual Studio-paketroten under mappen Config för varje tjänst i programmet.
- Kod – Konfiguration via kod utförs genom att skapa en ReliableStateManager med hjälp av ett ReliableStateManagerConfiguration-objekt med rätt alternativuppsättning.
Som standard letar Azure Service Fabric-körningen efter fördefinierade avsnittsnamn i filen Settings.xml och använder konfigurationsvärdena när de underliggande körningskomponenterna skapas.
Kommentar
Ta inte bort avsnittsnamnen för följande konfigurationer i den Settings.xml fil som genereras i Visual Studio-lösningen om du inte planerar att konfigurera tjänsten via kod. Om du byter namn på konfigurationspaketet eller avsnittsnamnen krävs en kodändring när du konfigurerar ReliableStateManager.
Replikeringssäkerhetskonfiguration
Replikeringssäkerhetskonfigurationer används för att skydda kommunikationskanalen som används under replikeringen. Det innebär att tjänsterna inte kommer att kunna se varandras replikeringstrafik, vilket säkerställer att de data som görs mycket tillgängliga också är säkra. Som standard förhindrar ett tomt säkerhetskonfigurationsavsnitt replikeringssäkerhet.
Viktigt!
På Linux-noder måste certifikaten vara PEM-formaterade. Mer information om hur du hittar och konfigurerar certifikat för Linux finns i Konfigurera certifikat på Linux.
Standardavsnittsnamn
ReplicatorSecurityConfig
Kommentar
Om du vill ändra det här avsnittsnamnet åsidosätter du parametern replicatorSecuritySectionName till konstruktorn ReliableStateManagerConfiguration när du skapar ReliableStateManager för den här tjänsten.
Replikeringskonfiguration
Replikatorkonfigurationer konfigurerar replikatorn som ansvarar för att göra den tillståndskänsliga reliable-tjänstens tillstånd mycket tillförlitligt genom att replikera och bevara tillståndet lokalt. Standardkonfigurationen genereras av Visual Studio-mallen och bör räcka. I det här avsnittet beskrivs ytterligare konfigurationer som är tillgängliga för att finjustera replikatorn.
Standardavsnittsnamn
ReplicatorConfig
Kommentar
Om du vill ändra det här avsnittsnamnet åsidosätter du parametern replicatorSettingsSectionName till konstruktorn ReliableStateManagerConfiguration när du skapar ReliableStateManager för den här tjänsten.
Konfigurationsnamn
| Name | Enhet | Standardvärde | Kommentarer |
|---|---|---|---|
| BatchAcknowledgementInterval | Sekunder | 0,015 | Tidsperiod för vilken replikatorn vid den sekundära väntar efter att ha tagit emot en åtgärd innan en bekräftelse skickas tillbaka till den primära. Alla andra bekräftelser som ska skickas för åtgärder som bearbetas inom det här intervallet skickas som ett svar. |
| ReplicatorEndpoint | Ej tillämpligt | Ingen standardparameter – obligatorisk parameter | IP-adress och port som den primära/sekundära replikatorn använder för att kommunicera med andra replikerare i replikuppsättningen. Detta bör referera till en TCP-resursslutpunkt i tjänstmanifestet. Mer information om hur du definierar slutpunktsresurser i ett tjänstmanifest finns i Tjänstmanifestresurser. |
| MaxPrimaryReplicationQueueSize | Antal åtgärder | 8192 | Maximalt antal åtgärder i den primära kön. En åtgärd frigörs när den primära replikatorn tar emot en bekräftelse från alla sekundära replikatorer. Det här värdet måste vara större än 64 och en effekt på 2. |
| MaxSecondaryReplicationQueueSize | Antal åtgärder | 16384 | Maximalt antal åtgärder i den sekundära kön. En åtgärd frigörs efter att dess tillstånd har hög tillgänglighet genom beständighet. Det här värdet måste vara större än 64 och en effekt på 2. |
| CheckpointThresholdInMB | MB | 50 | Mängden loggfilutrymme efter vilket tillståndet är kontrollpunkt. |
| MaxRecordSizeInKB | kB | 1024 | Största poststorlek som replikatorn kan skriva i loggen. Det här värdet måste vara en multipel av 4 och större än 16. |
| MinLogSizeInMB | MB | 0 (systemet bestäms) | Minsta storlek på transaktionsloggen. Loggen kommer inte att tillåtas trunkera till en storlek under den här inställningen. 0 anger att replikatorn avgör den minsta loggstorleken. Om du ökar det här värdet ökar möjligheten att göra partiella kopior och inkrementella säkerhetskopior eftersom risken för att relevanta loggposter trunkeras minskar. |
| TruncationThresholdFactor | Faktor | 2 | Avgör storleken på loggen, trunkering utlöses. Tröskelvärdet för trunkering bestäms av MinLogSizeInMB multiplicerat med TruncationThresholdFactor. TruncationThresholdFactor måste vara större än 1. MinLogSizeInMB * TruncationThresholdFactor måste vara mindre än MaxStreamSizeInMB. |
| ThrottlingThresholdFactor | Faktor | 4 | Avgör hur stor loggen är, och repliken börjar begränsas. Tröskelvärde för begränsning (i MB) bestäms av Max((MinLogSizeInMB * ThrottlingThresholdFactor),(CheckpointThresholdInMB * ThrottlingThresholdFactor)). Begränsningströskelvärdet (i MB) måste vara större än tröskelvärdet för trunkering (i MB). Tröskelvärdet för trunkering (i MB) måste vara mindre än MaxStreamSizeInMB. |
| MaxAccumulatedBackupLogSizeInMB | MB | 800 | Maximal ackumulerad storlek (i MB) för säkerhetskopieringsloggar i en viss kedja för säkerhetskopieringsloggar. En inkrementell säkerhetskopiering misslyckas om den inkrementella säkerhetskopieringen skulle generera en säkerhetskopieringslogg som skulle göra att de ackumulerade säkerhetskopieringsloggarna eftersom den relevanta fullständiga säkerhetskopieringen är större än den här storleken. I sådana fall måste användaren göra en fullständig säkerhetskopia. |
| SharedLogId | GUID | "" | Anger ett unikt GUID som ska användas för att identifiera den delade loggfilen som används med den här repliken. Tjänsterna bör vanligtvis inte använda den här inställningen. Men om SharedLogId har angetts måste även SharedLogPath anges. |
| SharedLogPath | Fullständigt kvalificerat sökvägsnamn | "" | Anger den fullständigt kvalificerade sökvägen där den delade loggfilen för den här repliken ska skapas. Tjänsterna bör vanligtvis inte använda den här inställningen. Men om SharedLogPath har angetts måste SharedLogId också anges. |
| SlowApiMonitoringDuration | Sekunder | 300 | Anger övervakningsintervallet för hanterade API-anrop. Exempel: användarinloggningsfunktionen för säkerhetskopiering. När intervallet har passerat skickas en varningshälsorapport till hälsohanteraren. |
| LogTruncationIntervalSeconds | Sekunder | 0 | Konfigurerbart intervall med vilket loggtrunkering initieras på varje replik. Den används för att säkerställa att loggen också trunkeras baserat på tid i stället för bara loggstorlek. Den här inställningen tvingar också rensning av borttagna poster i tillförlitlig ordlista. Därför kan den användas för att säkerställa att borttagna objekt rensas i tid. |
| EnableStableReads | Boolean | Falsk | Om du aktiverar stabila läsningar begränsas sekundära repliker till returnerade värden som har kvorum-acked. |
Exempelkonfiguration via kod
class Program
{
/// <summary>
/// This is the entry point of the service host process.
/// </summary>
static void Main()
{
ServiceRuntime.RegisterServiceAsync("HelloWorldStatefulType",
context => new HelloWorldStateful(context,
new ReliableStateManager(context,
new ReliableStateManagerConfiguration(
new ReliableStateManagerReplicatorSettings()
{
RetryInterval = TimeSpan.FromSeconds(3)
}
)))).GetAwaiter().GetResult();
}
}
class MyStatefulService : StatefulService
{
public MyStatefulService(StatefulServiceContext context, IReliableStateManagerReplica stateManager)
: base(context, stateManager)
{ }
...
}
Exempelkonfigurationsfil
<?xml version="1.0" encoding="utf-8"?>
<Settings xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/2011/01/fabric">
<Section Name="ReplicatorConfig">
<Parameter Name="ReplicatorEndpoint" Value="ReplicatorEndpoint" />
<Parameter Name="BatchAcknowledgementInterval" Value="0.05"/>
<Parameter Name="CheckpointThresholdInMB" Value="512" />
</Section>
<Section Name="ReplicatorSecurityConfig">
<Parameter Name="CredentialType" Value="X509" />
<Parameter Name="FindType" Value="FindByThumbprint" />
<Parameter Name="FindValue" Value="9d c9 06 b1 69 dc 4f af fd 16 97 ac 78 1e 80 67 90 74 9d 2f" />
<Parameter Name="StoreLocation" Value="LocalMachine" />
<Parameter Name="StoreName" Value="My" />
<Parameter Name="ProtectionLevel" Value="EncryptAndSign" />
<Parameter Name="AllowedCommonNames" Value="My-Test-SAN1-Alice,My-Test-SAN1-Bob" />
</Section>
</Settings>
Kommentarer
BatchAcknowledgementInterval styr replikeringsfördröjningen. Värdet "0" resulterar i lägsta möjliga svarstid, på bekostnad av dataflödet (eftersom fler bekräftelsemeddelanden måste skickas och bearbetas, var och en innehåller färre bekräftelser). Ju större värde för BatchAcknowledgementInterval, desto högre övergripande dataflöde för replikering, på bekostnad av högre åtgärdssvarstid. Detta leder direkt till svarstiden för transaktionsincheckningar.
Värdet för CheckpointThresholdInMB styr mängden diskutrymme som replikatorn kan använda för att lagra tillståndsinformation i replikens dedikerade loggfil. Om du ökar detta till ett högre värde än standardvärdet kan det leda till snabbare omkonfigurationstider när en ny replik läggs till i uppsättningen. Detta beror på den partiella tillståndsöverföring som sker på grund av tillgängligheten för mer historik över åtgärder i loggen. Detta kan potentiellt öka återställningstiden för en replik efter en krasch.
Inställningen MaxRecordSizeInKB definierar den maximala storleken på en post som kan skrivas av replikatorn till loggfilen. I de flesta fall är standardstorleken på 1 024 KB optimal. Men om tjänsten orsakar att större dataobjekt ingår i tillståndsinformationen kan det här värdet behöva ökas. Det finns små fördelar med att göra MaxRecordSizeInKB mindre än 1024, eftersom mindre poster endast använder det utrymme som behövs för den mindre posten. Vi förväntar oss att det här värdet bara behöver ändras i sällsynta fall.
Inställningarna SharedLogId och SharedLogPath används alltid tillsammans för att göra så att en tjänst använder en separat delad logg från den delade standardloggen för noden. För bästa effektivitet bör så många tjänster som möjligt ange samma delade logg. Delade loggfiler ska placeras på diskar som endast används för den delade loggfilen för att minska huvudförflyttningskonkurrationen. Vi förväntar oss att det här värdet bara behöver ändras i sällsynta fall.