Scaling Indicium on Azure
Introduction
You can configure Indicium to use an Azure Storage Account when scaling is required.
Indicium supports the Blob container configuration for an Azure Storage account. When configuring a Blob container for Indicium, it is important to limit access to the storage account so only authorized applications can use it.
This topic lists some best practices.
Scaling Indicium on Azure
You can use an Azure Blob container with Azure App Service. This consists of:
- Create a storage account in the Azure Portal.
- Create a Blob container and configure access to it.
- Configure some settings in the
appsettings.json
configuration file to use the newly created Azure Blob container.
Create an Azure storage account
To enable Azure storage account access to an App Service, you must first create a storage account in the Azure Portal:
-
Start the Storage accounts creation wizard.
-
Select the Advanced tab.
-
Clear the Enable blob public access checkbox to disable public blob access.
-
Optionally, if you plan to use this storage account for caching only, clear the Enable storage account key access checkbox since Indicium will not use this key access.
-
In the Firewalls and virtual networks tab, under Public network access, select Enabled from selected virtual networks and IP addresses to configure networking on the storage account.
-
Click Save. Now, the Virtual networks section appears.
-
Select a virtual network. If there is no virtual network, you must first create one using the Azure portal.
Create a Blob container
- After creating the Storage account, locate this account in the Azure portal to create the Blob container:
- Select the Containers tab.
- Click + Container and enter a name for it. This name will be used later when configuring the file cache settings for Indicium.
Configure access to the blob container:
-
Open the newly created container.
-
On the left-hand side, click Access Control (IAM).
-
Click + Add, and then Add role assignment.
-
On this screen, click Storage Blob Data Contributor and click Next.
-
Change the option Assign access to to Managed Identity.
-
Click +Select members.
-
On the right-hand side, change Managed identity to App Service and select the Azure App Service. If the Azure App Service is not on the list, make sure that your App Service has System assigned selected. You can find this setting in the Azure Portal, on the Identity tab of your Azure App Service.
-
Click Save to save the role assignment. Now, in the Azure Portal, add the Virtual network to the Indicium app service:
-
In the Networking tab of the app service, on the right-hand side, click VNet integration. A new VNet Integration tab opens.
-
In this screen, click Add VNet, and select the Virtual network just created.
File cache settings for Indicium
To write the cache to the newly created Azure Blob container, add the following section to the appsettings.json
configuration file, and specify the required values:
"FileCache": {
"Type": "AzureBlob",
"AzureStorageAccountName": "<name of your Azure Storage account>",
"AzureTenantID": "<tenantid of the blob storage> ", // Usually not necessary because Azure solves this if hosted in Azure.
"AzureClientID": "<clientid of the blob storage>", // Usually not necessary because Azure solves this if hosted in Azure.
"AzureClientSecret": "<ClientSecret of the blobstorage>", // Usually not necessary because Azure solves this if hosted in Azure.
"StoragePath": "indicium-cache", // The name of the just created Blob container.
"ClearLocalCacheOnStartup": true // See explanation below
}
ClearLocalCacheOnStartup
- Optional. If not set or true
, the local cache is cleared on startup.
Set it to false
if multiple instances of Indicium share the same cache folder.
For example, when running multiple app service instances.
It prevents that one instance clears the cache while another one tries to access files in the cache.
Alternatively, you can add the settings by adding Application settings to the Indicium App Service:
- Name:
FileCache:Type
, Value:AzureBlob
- Name:
FileCache:AzureStorageAccountName
, Value:<storage account name>
- Name:
FileCache:StoragePath
, Value:indicium-cache
(the name of file blob container)
After changing the settings, Indicium uses use the blob container to store the files.
Configure a Redis cache
The purpose of Redis is to share the users' states between multiple instances. Never use Redis when you are using:
- Vertical scaling (only one instance)
- Horizontal scaling with sticky sessions. Because in-memory is faster, it is a waste of performance to use a Redis cache when sticky sessions are used.
For more information, see Load balancing, sticky sessions, and Redis
When scaling Indicium without sticky sessions, you must configure a Redis cache. Indicium will use this cache to store the state that all Indicium instances can access. The size of the cache depends on your usage scenario, the number of users, and the application model.
We cannot specify a general cache size. We advise to monitor for “evicted” keys and the amount of memory the cache uses, so you can scale up when required.
Configure an Azure cache for Redis
In the Azure Portal, you can use the Azure Cache for Redis wizard to configure a Redis cache to store data. We advise to use private endpoints to limit access to your Redis instance. For this, your Indicium App Service must be in a Virtual Network.
To create and configure an Azure Cache for Redis:
-
If you do not have a virtual network, create one in the Azure Portal.
-
This virtual network must have two subnets, one for the Indicium App Service and one for the Redis private endpoint.
By default, there is one default subnet with address range: 10.1.0.0/24. -
Provide a name for the other subnet, for example, “Redis”, with address range: 10.2.0.0/24.
-
In the Azure Portal, add the virtual network to the Indicium App Service.
-
In the Networking tab of the app service, on the right-hand side, click VNet integration.
A new VNet Integration tab opens. -
In this screen, click Add VNet, and select the virtual network just created.
-
In the Azure cache for Redis wizard, select the Private endpoint tab.
-
Click +Private Endpoint.
-
Select the correct subscription and resource group and provide a name for the private endpoint.
-
Select the Resource tab.
-
In the Resource type field, select Microsoft.Cache/Redis.
-
In the Resource field, select the Redis instance.
-
Click Next.
-
In the Virtual networks section, select the correct Virtual Network. This must be the same network as the Indicium App Service uses.
-
Select the subnet created earlier.
-
Finish the wizard to create the private endpoint.
To use the newly created Redis cache, add the following section to the appsettings.json
configuration file, and specify the ConnectionString.
"RedisSettings": {
"ConnectionString": "<connection string>"
}
Alternatively, you can add an Application setting to the Indicium App Service:
- Name: RedisSettings:ConnectionString
- Value:
@Microsoft.KeyVault(VaultName=<key-vault-name>;SecretName=<secret-name>)
When adding this application setting, we advise saving the ConnectionString in an Azure Key vault. By using the above notation, the secret is stored in a safe location in Azure and referenced by the App Service.
Do not use the private link name to connect when using private endpoints.
Instead, always connect to the <cache_name>.redis.cache.windows.net
endpoint.
You can find the host name in the Overview tab of the Azure Cache for Redis wizard.
Add a Blob Lifecycle policy
The blob container can grow in size and in some cases might contain stale files. This can happen when a user uploads a file but closes the browser without saving the record.
Azure provides an automatic way to delete files from the container:
- Open the Azure Storage account.
- In the menu on the left-hand side, click Lifecycle management.
- Click +Add a rule to create a new rule and provide a name for it.
For example, you can create a condition to automatically delete files that were last modified 7 days ago to keep the cache clean. Also, this will keep your blob storage cost low.