We continue with the post from day before yesterday where we were discussing the Azure cache with Redis

 The Basic tier is a single node system with no data replication and no SLA, so use standard or premium tier.

Data loss is expected because it is an in-memory store and patching or failovers might occur.

The eviction policy of volatile-lru affects only keys with a TTL value. This is the default.

There is a performance tool available called Redis-benchmark.exe. This is recommended to be run on the Dv2 VM series.

There are statistics to show the total number of expired keys. the number of keys with timeouts and an average timeout value.

If all the keys are lost, it probably occurs due to one of three reasons: The keys have been purged manually, the azure cache for Redis is set to use a non-default database, or the Redis server is unavailable.

The local RedisCache wrapper connection uses connection multiplexing. The RedisCache object that clients interact with to get and set cache entries requires a connection to the cache. If each instance of the object opens a new connection, the server resources could be depleted real fast to the point of Denial of Service.  Therefore some economical use of the connections is needed and one approach to handle it requires the multiplexing of connections. 

The sizes of the cache can vary from 250MB to 120GB

The replication speed across regions occurs at about 63 GB in 5-10 minutes

A planned failover and swapping between primary and secondary takes 1 second

An unplanned failover with similar operation takes 10 seconds.

The persistence option an be AOF for last updates and replay or RDB for snapshots

Cache can also be hosted on a cluster with a shards on different nodes

There are options for private network, firewall and update schedules. 

 

Given a wire grid of size N * N with N-1 horizontal edges and N-1 vertical edges along the X and Y axis respectively, and a wire burning out every instant as per the given order using three matrices A, B, C such that the wire that burns is

(A[T], B[T] + 1), if C[T] = 0 or
(A[T] + 1, B[T]), if C[T] = 1

Determine the instant after which the circuit is broken

     public static boolean checkConnections(int[] h, int[] v, int N) {

        boolean[][] visited = new boolean[N][N];

        dfs(h, v, visited,0,0);

        return visited[N-1][N-1];

    }

    public static void dfs(int[]h, int[]v, boolean[][] visited, int i, int j) {

        int N = visited.length;

        if (i < N && j < N && i>= 0 && j >= 0 && !visited[i][j]) {

            visited[i][j] = true;

            if (v[i * (N-1) + j] == 1) {

                dfs(h, v, visited, i, j+1);

            }

            if (h[i * (N-1) + j] == 1) {

                dfs(h, v, visited, i+1, j);

            }

            if (i > 0 && h[(i-1)*(N-1) + j] == 1) {

                dfs(h,v, visited, i-1, j);

            }

            if (j > 0 && h[(i * (N-1) + (j-1))] == 1) {

                dfs(h,v, visited, i, j-1);

            }

        }

    }

    public static int burnout(int N, int[] A, int[] B, int[] C) {

        int[] h = new int[N*N];

        int[] v = new int[N*N];

        for (int i = 0; i < N*N; i++) { h[i] = 1; v[i] = 1; }

        for (int i = 0; i < N; i++) {

            h[(i * (N)) + N - 1] = 0;

            v[(N-1) * (N) + i] = 0;

        }

        System.out.println(printArray(h));

        System.out.println(printArray(v));

        for (int i = 0; i < A.length; i++) {

            if (C[i] == 0) {

                v[A[i] * (N-1) + B[i]] = 0;

            } else {

                h[A[i] * (N-1) + B[i]] = 0;

            }

            if (!checkConnections(h,v, N)) {

                return i+1;

            }

        }

        return -1;

    }

        int[] A = new int[9];

        int[] B = new int[9];

        int[] C = new int[9];

        A[0] = 0;    B [0] = 0;    C[0] = 0;

        A[1] = 1;    B [1] = 1;    C[1] = 1;

        A[2] = 1;    B [2] = 1;    C[2] = 0;

        A[3] = 2;    B [3] = 1;    C[3] = 0;

        A[4] = 3;    B [4] = 2;    C[4] = 0;

        A[5] = 2;    B [5] = 2;    C[5] = 1;

        A[6] = 1;    B [6] = 3;    C[6] = 1;

        A[7] = 0;    B [7] = 1;    C[7] = 0;

        A[8] = 0;    B [8] = 0;    C[8] = 1;

        System.out.println(burnout(9, A, B, C));

1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 0

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0

8
Alternatively,

    public static boolean burnWiresAtT(int N, int[] A, int[] B, int[] C, int t) {

        int[] h = new int[N*N];

        int[] v = new int[N*N];

        for (int i = 0; i < N*N; i++) { h[i] = 1; v[i] = 1; }

        for (int i = 0; i < N; i++) {

            h[(i * (N)) + N - 1] = 0;

            v[(N-1) * (N) + i] = 0;

        }

        System.out.println(printArray(h));

        System.out.println(printArray(v));

        for (int i = 0; i < t; i++) {

            if (C[i] == 0) {

                v[A[i] * (N-1) + B[i]] = 0;

            } else {

                h[A[i] * (N-1) + B[i]] = 0;

            }

        }

        return checkConnections(h, v, N);

    }

    public static int binarySearch(int N, int[] A, int[] B, int[] C, int start, int end) {

        if (start == end) {

            if (!burnWiresAtT(N, A, B, C, end)){

                return end;

            }

            return  -1;

        } else {

            int mid = (start + end)/2;

            if (burnWiresAtT(N, A, B, C, mid)) {

                return binarySearch(N, A, B, C, mid + 1, end);

            } else {

                return binarySearch(N, A, B, C, start, mid);

            }

        }

    }

1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 0

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0

8

 This continues on the previous post for the modus operandi of Azure Cache for Redis:

Specifically, we called out the following:

 The Basic tier is a single node system with no data replication and no SLA, so use standard or premium tier.

Data loss is expected because it is an in-memory store and patching or failovers might occur.

The eviction policy of volatile-lru affects only keys with a TTL value. This is the default.

There is a performance tool available called Redis-benchmark.exe. This is recommended to be run on the Dv2 VM series.

There are statistics to show the total number of expired keys. the number of keys with timeouts and an average timeout value.

If all the keys are lost, it probably occurs due to one of three reasons: The keys have been purged manually, the azure cache for Redis is set to use a non-default database, or the Redis server is unavailable.

Traffic is always routed to the designated primary, backed by a virtual machine that hosts the Redis server. Container and cluster-based scale-out of Redis servers are not entertained. Even if there are multiple servers, only one is primary and the others are replica. Clustered caches have many shards each with distinct primary and replica nodes.

Failover occurs when the primary goes offline and another becomes primary. Clients handle failover effects with retry and backoff. 

We continue next with connection multiplexing. The RedisCache object that clients interact with to get and set cache entries requires a connection to the cache. If each instance of the object opens a new connection, the server resources could be depleted real fast to the point of Denial of Service.  Therefore some economical use of the connections is needed and one approach to handle it requires the multiplexing of connections.  

 The modus-operandi for the use of Azure Cache with Redis.

Performance and cost-effective use of Azure Cache for Redis instance result from following best practices. These are:

 The Basic tier is a single node system with no data replication and no SLA, so use standard or premium tier.

Data loss is expected because it is an in-memory store and patching or failovers might occur.

Use a connect timeout of at least 15 seconds.

The default eviction policy is volatile-lru, which means that only keys that have a TTL value set will be eligible for eviction. If no keys have a TTL value, then the system won't evict any keys. If we want to stretch the eviction to all keys, use allkeys-lru policy. Keys can also have an expiration value set.

There is a performance tool available called redis-benchmark.exe. This is recommended to be run on Dv2 VM series.

The stats section shows the total number of expired keys. The keyspace section provides more information about the number of keys with timeouts and an average time-out value. The number of evicted keys can be monitored using the info command.

If all the keys are lost, it probably occurs due to one of three reasons: The keys have been purged manually, the azure cache for Redis is set to use a non-default database, or the Redis server is unavailable.

Redis is an in-memory data store.  It is hosted on a single VM in a basic tier. If that VM is down, all data in the cache is lost. Caches in the standard or premium tier offer much higher resiliency against data loss by using two VMs in a replicated configuration. These VMs are located on separate domains for faults and updates, to minimize the chance of both becoming unavailable simultaneously.  If a major datacenter outage happens, however, the VMs might still go down together. Data persistence and geo-replication is used to protect data against failures.

A cache is constructed of multiple virtual machines with separate, private IP addresses. Each virtual machine, also known as a node, is connected to a shared load balancer with a single virtual IP address. Each node runs the Redis server process and is accessible by means of the hostname and the Redis ports. Each node is considered either a primary or a replica node. When a client application connects to a cache, its traffic goes through this load balancer and is automatically routed to the primary node.

A basic cache has a single node which is always primary. Standard or premium cache has two nodes – one primary and the other replica. Clustered caches have many shards each with distinct primary and replica nodes.

Failover occurs when the primary goes offline and another becomes primary. Both notice changes. The old one sees the new primary and becomes a replica. Then it connects with the primary to synchronize data.

A planned failover takes place during system updates. The nodes receive advance notice and can swap roles and update the load-balancer. It finishes in less than 1 second.

 An unplanned failover might happen because of hardware failure or unexpected outages. The replica node promotes itself to primary but the process is longer because it must first detect that the primary is offline and that the failover is not unnecessary. This lasts 10 to 15 seconds.

Patching involves failover which can be synchronized by the management service.

Clients handle failover effects with retry and backoff. If errors persist for longer than a preconfigured amount of time, the connection object should be recreated. Recreating the connection without restarting the application can be accomplished by using a Lazy<T> pattern.

Reboot and scheduled updates can be tossed in to test a client’s resiliency and the mitigations by the retry and backoff technique.

Decision Tree modeling on API Error root cause analysis   

Problem statement: Given a method to collect root causes from many data points from API error codes in logs, can there be a determination of relief time? 

   

Solution: There are two stages to solving this problem:  

1.       Stage 1 – discover root cause and create a summary to capture it  

2.       Stage 2 – use a decision tree modeling to determine relief time.  

  

Stage 1:  

The first stage involves a data pipeline that converts log entries to a json object with request and response details, statuscode, error message, remote server info, query and request parameters and hashes them into buckets.  When the dictionary  are collected from a batch of log entries, we can transform it into a vector representation and using the notable request-response pairs as features. Then we can generate a hidden weighted matrix for the neural network  

We use that hidden layer to determine the salience using the gradient descent method.       

   

All values are within [0,1] co-occurrence probability range.      

   

The solution to the quadratic form representing the embeddings is found by arriving at the minima represented by Ax = b using conjugate gradient method.    

We are given input matrix A, b, a starting value x, a number of iterations i-max and an error tolerance  epsilon < 1    

   

This method proceeds this way:     

   

set I to 0     

   

set residual to b - Ax     

   

set search-direction to residual.    

   

And delta-new to the dot-product of residual-transposed.residual.    

   

Initialize delta-0 to delta-new    

   

while I < I-max and delta > epsilon^2 delta-0 do:     

   

    q = dot-product(A, search-direction)    

   

    alpha = delta-new / (search-direction-transposed. q)     

   

    x = x + alpha.search-direction    

   

    If I is divisible by 50     

   

        r = b - Ax     

   

    else     

   

        r = r - alpha.q     

   

    delta-old = delta-new    

   

    delta-new = dot-product(residual-transposed,residual)    

   

     Beta = delta-new/delta-old    

   

     Search-direction = residual + Beta. Search-direction    

   

     I = I + 1     

   

Root cause capture – API error summaries that are captured from various sources and appear in the logs can be stack hashed. The root cause can be described by a specific summaries, its associated point of time, the duration over which it appears, and the time of fix introduced, if known.   

   

Stage 2: Decision Tree modeling can help predict relief time. involves both a classification and a regression tree. A function divides the rows into two datasets based on the value of a specific column. The two list of rows that are returned are such that one set matches the criteria for the split while the other does not. When the attribute to be chosen is clear, this works well. 

To see how good an attribute is, the entropy of the whole group is calculated.  Then the group is divided by the possible values of each attribute and the entropy of the two new groups are calculated. The determination of which attribute is best to divide on, the information gain is calculated which is the difference between the current entropy and the weighted-average entropy of the two new groups. The algorithm calculates the information gain for every attribute and chooses the one with the highest information gain. 

Each set is subdivided only if the recursion of the above step can proceed. The recursion is terminated if a solid conclusion has been reached which is a way of saying that the information gain from splitting a node is no more than zero. The branches keep dividing, creating a tree by calculating the best attribute for each new node. If a threshold for entropy is set, the decision tree is ‘pruned’.  

When working with a set of tuples, it is easier to reserve the last one for results during a recursion level. Text and numeric data do not have to be differentiated for this algorithm to run. The algorithm takes all the existing rows and assumes the last row is the target value. A training/testing dataset is used with the application for each dataset. Usually, a training/testing data split of 70/30% is used in this regard.  

 

Authenticating using Azure SDK

Introduction: The previous article mentioned the way to use the new Azure.Identity credentials with the Fluent library from Azure. This article describes the use of DefaultAzureCredential for the logged-in user.  

Description: The DefaultCredential class in the previous versions of the SDK and the DefaultAzureCredential in the current version of the SDK both support common developer workflows. The DefaultAzureCredential in the Azure SDK is the recommended way to handle the authentication across the local workstation and the deployment environment. It is really automation to finding the right credential to use. It uses the most appropriate credential to use by iterating through four specific locations. These are environment variables, managed identity, the MSAL shared token cache, and the Azure CLI. The environment variables used are AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, and AZURE_TENANT_ID. Once these are set and used, other credentials can be read from the key-vault store. It is also possible to bring up an interactive browser for login with SDKs specific to some languages. Credentials once formed can be stored in encrypted locations reducing the exposure to others. The DefaultAzureCredentials supports and attempts to authenticate with a few more such as VisualStudioCredential, SharedTokenCacheCredential, and InteractiveBrowserCredential. The VisualStudioCredential is an integration with the Azure Account Extension and is the same one used with the “Azure Sign in” command. 

It is also possible to exclude some credentials. This is done with the help of DefaultAzureCredentialOptions where there are flags to exclude every one of the credentials mentioned. 

There is also a technique to fail the authentication and not try the next. This is done with the help of the CredentialUnavailableException.DefaultAzureCredential exception type. When it is added, then the next credential is tried only when CredentialUnavailableException is thrown from the current credential. If a different exception is thrown then it is propagated and the next one is not tried. 

Connecting to a client with the DefaultAzureCrendential is a breeze. Let’s review the syntax: 

In .Net: 

var client = new SecretClient(new Uri(keyVaultUrl), new DefaultAzureCredential(true)); 

And in Java: 

SecretClient client = new SecretClientBuilder() 

        .vaultUrl(keyVaultUrl) 

        .credential(new DefaultAzureCredentialBuilder().build()) 

        .buildClient();