Configuring Reliable Actors--KVSActorStateProvider
You can modify the default configuration of KVSActorStateProvider by changing the settings.xml file that is generated in the Microsoft Visual Studio package root under the Config folder for the specified actor.
The Azure Service Fabric runtime looks for predefined section names in the settings.xml file and consumes the configuration values while creating the underlying runtime components.
Note
Do not delete or modify the section names of the following configurations in the settings.xml file that is generated in the Visual Studio solution.
Replicator security configuration
Replicator security configurations are used to secure the communication channel that is used during replication. This means that services cannot see each other's replication traffic, ensuring that the data that is made highly available is also secure. By default, an empty security configuration section prevents replication security.
Important
On Linux nodes, certificates must be PEM-formatted. To learn more about locating and configuring certificates for Linux, see Configure certificates on Linux.
Section name
<ActorName>ServiceReplicatorSecurityConfig
Replicator configuration
Replicator configurations configure the replicator that is responsible for making the Actor State Provider state highly reliable. The default configuration is generated by the Visual Studio template and should suffice. This section talks about additional configurations that are available to tune the replicator.
Section name
<ActorName>ServiceReplicatorConfig
Configuration names
Name | Unit | Default value | Remarks |
---|---|---|---|
BatchAcknowledgementInterval | Seconds | 0.015 | Time period for which the replicator at the secondary waits after receiving an operation before sending back an acknowledgement to the primary. Any other acknowledgements to be sent for operations processed within this interval are sent as one response. |
ReplicatorEndpoint | N/A | No default--required parameter | IP address and port that the primary/secondary replicator will use to communicate with other replicators in the replica set. This should reference a TCP resource endpoint in the service manifest. Refer to Service manifest resources to read more about defining endpoint resources in the service manifest. |
RetryInterval | Seconds | 5 | Time period after which the replicator re-transmits a message if it does not receive an acknowledgement for an operation. |
MaxReplicationMessageSize | Bytes | 50 MB | Maximum size of replication data that can be transmitted in a single message. |
MaxPrimaryReplicationQueueSize | Number of operations | 1024 | Maximum number of operations in the primary queue. An operation is freed up after the primary replicator receives an acknowledgement from all the secondary replicators. This value must be greater than 64 and a power of 2. |
MaxSecondaryReplicationQueueSize | Number of operations | 2048 | Maximum number of operations in the secondary queue. An operation is freed up after making its state highly available through persistence. This value must be greater than 64 and a power of 2. |
Store configuration
Store configurations are used to configure the local store that is used to persist the state that is being replicated. The default configuration is generated by the Visual Studio template and should suffice. This section talks about additional configurations that are available to tune the local store.
Section name
<ActorName>ServiceLocalStoreConfig
Configuration names
Name | Unit | Default value | Remarks |
---|---|---|---|
MaxAsyncCommitDelayInMilliseconds | Milliseconds | 200 | Sets the maximum batching interval for durable local store commits. |
MaxVerPages | Number of pages | 16384 | The maximum number of version pages in the local store database. It determines the maximum number of outstanding transactions. |
Sample configuration file
<?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="MyActorServiceReplicatorConfig">
<Parameter Name="ReplicatorEndpoint" Value="MyActorServiceReplicatorEndpoint" />
<Parameter Name="BatchAcknowledgementInterval" Value="0.05"/>
</Section>
<Section Name="MyActorServiceLocalStoreConfig">
<Parameter Name="MaxVerPages" Value="8192" />
</Section>
<Section Name="MyActorServiceReplicatorSecurityConfig">
<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>
Remarks
The BatchAcknowledgementInterval parameter controls replication latency. A value of '0' results in the lowest possible latency, at the cost of throughput (as more acknowledgement messages must be sent and processed, each containing fewer acknowledgements). The larger the value for BatchAcknowledgementInterval, the higher the overall replication throughput, at the cost of higher operation latency. This directly translates to the latency of transaction commits.