Azure Cache for Redis
Hello, I am trying to optimize the cost for Azure Cache for Redis. Right now i have an E100 sku deployed and checking if there is a possibility to right size the instance to a lower tier. I checked the utilization metrics and could find low CPU, memory and low server load. However i am struggling to understand the metrics for the connected clients as this is one of the important criteria for rightsizing. Can someone please tell me if i need to look the MAX or SUM aggregation for connected clients? As per azure pricing E100 include upto 100,000 connection but i would like to understand if it is concurrent connection during a month or summation of all connection during a month. Can someone please help me to understand this?
Connect to Azure Cache for Redis using SSL Port 6380 from Linux VM
Scenario: You are using a Linux VM and you want to connect to Azure Cache for Redis using SSL Port 6380. Action: You can connect to Azure Cache for Redis using SSL Port with the help of Stunnel and Redis-cli. The steps are as follows: Step 1: Install the Redis-cli tool in your Linux machine. The command is as below: sudo apt-get update sudo apt-get install redis-tools Note: redis-tools package has redis-cli tool as well among other tools. Step 2: Since the redis-cli doesn’t support SSL port (6380), we can make use of stunnel to connect to Azure Cache for Redis using SSL port. We have version 4 of the utility, called stunnel4 which can be installed using the below command: sudo apt-get install stunnel4 Note: If you want to run the Redis using non SSL port 6379, in that case you do not need stunnel and you can directly access using the below command provided non-ssl port is open in Azure Cache for Redis: redis-cli -p 6379 -a <Your Access Key for Azure Cache for Redis> -h < yourcachename.redis.cache.windows.net> Step 3: To configure the service to start at booting, you must modify the /etc/default/stunnel4 file using the below command: sudo nano /etc/default/stunnel4 This opens a file where you have a variable ‘ENABLED’ which must be set to 1 to enable the service to start as shown below: You can save the changes with CTL+X and then pressing ENTER. Step 4: We need to configure the Azure Cache for Redis for redis-cli which must be mentioned in Redis configuration file of stunnel. Execute the below command: sudo nano /etc/stunnel/redis.conf This creates a new file where add the following entry and insert the actual name of your Azure Cache for Redis in place of yourcachename. [redis-cli] client = yes accept = 127.0.0.1:6380 connect = yourcachename.redis.cache.windows.net:6380 Save the file. Step 5: Now, we have configured the stunnel and hence need to restart the service which can be done with the help of below command: sudo systemctl restart stunnel4.service Step 6: If you check the services listening for connections on your Redis, you should see stunnel listening on port 6380 as below: sudo netstat -plunt Step 7: Now you can connect to Azure Cache for Redis using SSL port with the help of Redis-cli. Below is the command: redis-cli -p 6380 -a <Your Access Key for Azure Cache for Redis> You can see that Redis gets connected successfully and you will be able to perform operations on Azure Cache for Redis: Hope this helps!
Setting Up WSL for Secure Redis CLI Connections to Azure Redis Cache on Windows.
This blog will guide you through the necessary steps to set up WSL on your Windows machine, enabling you to harness the power of Redis CLI and securely connect to an Azure Redis Cache instance by running a Linux environment with Redis CLI on your Windows machine, without the need for a separate virtual machine or dual booting.
Leveraging Redis Insights for Azure Cache for Redis
The blog talks about how to leverage Redis Insights GUI tool while working with Azure Cache for Redis. We will look at some of the option what will help us with some high-level connectivity troubleshooting and insights to our data present inside the cache. To start with, we can leverage this for testing the connectivity to our Redis cache instance. After clicking on Add Redis Database button, we can fill in the other fields ahead: Host: Complete FQDN or the completed Redis cache Endpoint For Basic, Standard & Premium Tier - <Cachename>.redis.windows.net For Enterprise Tier - <Cachename>.<regionname>.redisenterprise.cache.azure.net Port: 6380 or 6379 (depending on whether we are testing for SSL or non-SSL port respectively) / 10000 for Enterprise Tier Database Alias: Cache name Password: Access Key for your cache Use TLS: Option to be checked for testing with 6380 port and also Enterprise Tier cache. Post that, we can click on Test Connection button which will help us doing a high-level check whether the cache endpoint is reachable or not. SSL Port: Non-SSL Port: Enterprise Cache: Once the test connection is successful, you can click on Add Redis Database to start exploring the insights of your cache instance. Note: All the above demo has been done without any kind of firewall, private endpoints or VNET restrictions. In case you are having VNET or private endpoints configured, then you have test it from a VM which is part of the VNET configured. On clicking My Redis Database option, it will list down all the databases you have connected too from the Redis Insights along with some high-level details such as modules if any for the enterprise tier or OSS Cluster as connection type if clustering policy selected was OSS. If Enterprise, it shows as Standalone only. For this Demo, we took an empty cache and the below snippet demonstrate on how your can-do simple Set operations or add a key to your cache instance. We can add a new key by providing the key type such as Set, String, List, Hast etc, Key name, TTL etc. We have added 3 keys initially and it will start reflecting in the left-hand window section as depicted below: Similarly, we added the keys further and all of them started listing. Selecting any of the keys shall provide insights to that particular key on the right sight window such as value, TTL , key size etc. You can also use this to do any kind of pattern match as well. E.g. In the below snippet, we tried listing all the keys that start key name as testkey. There is a Bulk Actions button available as well which has mainly 2 option available: Perform bulk deletion. Execute multiple set of Redis commands in a sequential format which can be uploaded as a plain text file. Moving ahead, there is an Analysis Tool option which can be leveraged to gain insight to the data summary residing in our cache. There is a New Report button which will generate a report providing various kind of insights on data residing in the cache. Below are some of the highlights: It provides a high-level summary key based on type. It gives you a view of how much data in under No Expiry (no TTL set) and is expected to get freed in expected time (based on TTL set). In the below example, it points around ~450 bytes of memory to get freed in less than an hour while there is approx. ~1200 bytes of data which don’t have any kind of TTL set and will not expire. It further provides high level details of top keys based on TTL or Key size which can be used to identify larger size keys. There is also a Workbench option that provides a command line option like Redis CLI, using which we can execute commands. In the below example, we have used it to do PING-PONG test, set up the keys and other operations too. Disclaimer: Please note that tool is supported by REDIS and not Azure cache for Redis so we don’t control the behavior or features for the tool. Hope that helps!
SSL/TLS connection issue troubleshooting guide
You may experience exceptions or errors when establishing TLS connections with Azure services. Exceptions are vary dramatically depending on the client and server types. A typical ones such as "Could not create SSL/TLS secure channel." "SSL Handshake Failed", etc. In this article we will discuss common causes of TLS related issue and troubleshooting steps.Troubleshooting Azure Redis Connectivity Issues
Scenario: You want to test the connectivity of REDIS endpoint from your machine using the non-SSL port 6379 or SSL port 6380 as per requirement. Actions: There are different options available to test the connectivity of your Azure Redis cache endpoint from your machine. Let’s check on few of them. 1. Test the connectivity using REDIS CLI and STUNNEL You can test the connectivity for REDIS for your machine on non-SSL port 6379 and SSL port 6380 using REDIS CLI tool. To test the connectivity to non-SSL port, kindly use the below syntax: redis-cli.exe -h <YOUR CACHE ENDPOINT> -p 6379 -a <ACCESS KEY> To test the connectivity on SSL port 6380, you need to make use of STUNNEL and make an entry in the configuration file as depicted below. Please reload the configurations after making the entry. In case the entry is missing or the configuration isn’t loaded correctly, you may receive errors like “No connection could be made because the target machine actively refused it”, “Connection Reset by Peer” or “Unknown Error” etc. Once configuration has been loaded successfully, try connecting to REDIS using the below syntax: redis-cli.exe -p 6380 -a <ACCESS KEY> In both the above tests, we made of simple PING command and received a PONG back. 2. Test the connectivity using PSPING You can test whether you are getting response from the REDIS end point on the desired port or not by making use of PSPING. The tool can be downloaded from the below link: https://docs.microsoft.com/en-us/sysinternals/downloads/psping Please try the below syntax to test the connectivity and check on the number of packets being sent and received as part of testing. psping -q <YOUR CACHE ENDPOINT>:<Port Number> If the number of sent packets are not equal to the received packets, it points to drop in connectivity. 3. Test the connectivity using Port Query tool You can also make use of the Port Query tool in order to test the connectivity and the tool can be downloaded from the below link: https://www.microsoft.com/en-in/download/details.aspx?id=24009. You need to mention the REDIS endpoint in the destination section and provide the port for which the connectivity needs to be tested. If the port is open, you will be getting the status as ‘LISTENING’ as shown below and if the port is blocked, the status will be shown as ‘FILTERED’. The below 2 screenshots depicts how the status will get reflecting depending upon the port status. If you are not getting successful response from any of the above methods, please try checking on the below parameters to isolate the issue further. 4. Checking the Firewall Rule Check if there is any firewall rule configured over the REDIS. This can be checked from the Azure Portal under the Settings blade. Below is the screenshot for the same: If there is/are any rule configured, the connection to REDIS will only be allowed from the mentioned IP or the IP ranges. In case you try to connect from an IP outside the firewall rule mentioned, you will get an error. Below is an example of a connectivity test using REDIS CLI from an IP outside the firewall rule. 5. Checking the VNET configurations and NSG rules In case you are using a Premium cache which has a VNET configuration assigned to it, the most common test can be done from the REDIS console. Incase there are any missing configurations, you will get and error like below : In this case, you can try validating the below pointers: The client application/source and the REDIS are under same regions. The below example shows to check the location/region configuration of a VM and a Azure REDIS instance The client application/source and the REDIS are under same VNET. The below example shows to check the Virtual Network configuration of a VM and a Azure REDIS instance. You can check if a VNET is assigned to your cache or not from the “Virtual Network” section under the Settings blade from the Azure Portal . In case the client application/source are under different VNET’s, both the VNET’s should have VNET peering enabled within the same Azure region. Global peering is not supported yet. All the Inbound and Outbound rules are in place as per the requirement. From isolation standpoint, the above mentioned one is a sample rule that can added be to both inbound & outbound configurations in order to allow all the ports/protocols/sources and destination and test the connectivity. Please note that the rule precedence or “Priority” should be higher for rule to get implemented. 6. Check REDIS endpoint being whitelisted Last but not the least, in case you are using a firewall or proxy in your network, please ensure that the REDIS endpoint is whitelisted with the port number i.e. *.redis.cache.windows.net should be whitelisted for the port 6379 and port 6380 as per requirement. Hope this helps!
