Skip to main content

Scaling on-premise

Use Redis on-premise

warning

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

On a Windows platform, Redis is not officially supported. However, for horizontal scaling without sticky sessions, you can use Redis with, for example, Docker on Windows, or install it on a Linux server. The Redis website provides an installation guide.

To enable the eviction policy, change the following settings in a redis.conf file. This file will be used later when starting the container.

maxmemory-policy volatile-lru
maxmemory 256M

When running Docker on Windows, execute the following command to use the configuration:

docker run -it -p 6379:6379 -v ${pwd}\redis.conf:/usr/local/etc/redis/redis.conf redis redis-server /usr/local/etc/redis/redis.conf

After installation, to use the Redis cache, add the following section to the appsettings.json configuration file, and specify the ConnectionString. The connection string must have format: <host>:6379.

By default, Redis does not enable authentication. To enable authentication, please refer to the Redis documentation.

"RedisSettings": {
"ConnectionString": "<connection string>"
}

Scaling with an Azure blob container

It is possible to use an Azure blob container on-premise. This consists of:

  • Create a storage account in the Azure Portal.
  • Create a Blob container.
  • Create a new App registration in the Azure portal.
  • Configure access to the Blob container.
  • Configure some settings in the appsettings.json configuration file to use the newly created Azure Blob container.
note

You can also make a “private endpoint connection” to your on-premise server. This is beyond the scope of this documentation.

Create a storage account in Azure

To enable Azure storage account access to an App Service, you must first create a storage account using the Azure Portal:

  1. Start the Storage account creation wizard.

  2. Select the Advanced tab.

  3. Clear the Enable blob public access checkbox to disable public blob access.

  4. Optionally, if you plan to use this storage account only for caching, clear the Enable storage account key access checkbox since Indicium will not use this key access.

  5. 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.

  6. Click Save.

Now, the Virtual networks section appears. This section does not need changes. We will come back to this page after creating the Storage account to change the configuration.

  1. Select the Networking tab.
  2. In the Firewall section, add the IP address (or range) of your on-premise network.
  3. Click Save to save the newly created configuration.

After creating the Storage account, locate this account in the Azure portal to create the Blob container:

  1. Select the Containers tab.
  2. Click +Container and provide a name for it. This name will be used later when configuring Indicium.

Create a new App registration

You must create an App Registration in the Azure portal, to be able to connect to the Blob container using a client/secret:

  1. In Azure Active Directory, select App registrations to create the registration.

After creating the registration, you can find the Application (client) ID and the Tenant id in the Overview menu. These IDs will be used later.

  1. From the Certificates & secrets menu, add a new "Client secret".

  2. Copy or make a note of the secret value (not the secret id). This value is used later, when configuring settings in appsettings.json.

Configure access to the Blob container

To configure access to the blob container:

  1. Open the newly created container.

  2. On the left-hand side, click Access Control (IAM).

  3. Click Storage Blob Data Contributor, and click Next.

  4. Set the option Assign access to to: User, group, or service principal.

  5. Click +Select members.

  6. On the right-hand side, search for the App Registration created earlier, and click Save to save the role assignment.

Configure settings

To use the newly created Azure Blob container, add the following section to the appsettings.json configuration file.

The AzureTenantID, AzureClientID, and AzureClientSecret are the values copied earlier from the App Registration. The StoragePath is the name of the Blob container just created.

"FileCache": {
"Type": "AzureBlob",
"AzureStorageAccountName" : "<name of your Azure Storage account>",
"AzureTenantId": "<tenant id>",
"AzureClientId": "<client id>",
"AzureClientSecret": "<tenant id value>",
"StoragePath": "indicium-cache"
}

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:

  1. Open the Azure Storage account.
  2. In the menu on the left-hand side, click Lifecycle management.
  3. 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.


Was this article helpful?