Sunday, August 7, 2022

A string S containing only the letters "A", "B" and "C" is given. The string can be transformed by removing one occurrence of "AA", "BB" or "CC".

Transformation of the string is the process of removing letters from it, based on the rules described above. As long as at least one rule can be applied, the process should be repeated. If more than one rule can be used, any one of them could be chosen. 

Write a function: 

class Solution { public String solution(String S); } 

that, given a string S consisting of N characters, returns any string that can result from a sequence of transformations as described above. 


For example, given string S = "ACCAABBC" the function may return "AC", because one of the possible sequences of transformations is as follows: 

Also, given string S = "ABCBBCBA" the function may return "", because one possible sequence of transformations is: 

Finally, for string S = "BABABA" the function must return "BABABA", because no rules can be applied to string S. 

Write an efficient algorithm for the following assumptions: 

the length of string S is within the range [0..50,000]; 

string S consists only of the following characters: "A", "B" and/or "C". 

string getReduced(string prefix, string suffix) 

{ 

bool fix = true; 

while(fix) 

{ 

if (string.IsNullOrWhitespace(suffix)) 

{fix = false;  break;} 

int I = 0; 

while (i+1 < suffix.length && suffix[i] == suffix[i+1]) 

 { 

     suffix = suffix.substring(I+2);  

     Fix = true; 

   } 

If (fix) continue; 

    While( prefix.length > 0 && prefix.last() == suffix.first()) 

    { 

        prefix = prefix.length-1; 

        suffix = suffix.substring(1, suffix.length-1); 

 .       Fix = true; 

    }  

    If(fix) continue; 

Prefix = prefix + suffix.first(); 

Suffix = suffix.substring(1, suffix.length-1); 

Fix = true; 

} 

} 

return prefix+suffix; 

} 

Saturday, August 6, 2022

This is a continuation of a series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here This article continues to discuss Azure Arc enabled servers, their sizing guidance and operational considerations when increasing the numbers but introduces the overall planning required for Azure arc enabled data services deployment.

The tasks to be undertaken include the following: 1. Plan the deployment with the details from this article, 2. Install client tools and 3. Access a Kubernetes cluster 4. Create an Azure Arc data controller in direct connectivity mode, 5. Create a data service and connect with Azure data studio.

It’s important to know the necessary background and information ready. For example, the database workloads, the business continuity, capacity requirements for memory, CPU and storage for the workloads and infrastructure to support these workloads must be studied.

Ensuring a successful deployment after this study requires the right level of access and appropriate capacity for storage, CPU, and memory.  Extensions and client tools must be installed Kubernetes cluster must be accessed to configure with the kubeconfig file. When the infrastructure is prepared, the Azure Arc enabled data services can then be deployed by

1.       Creating an Azure arc-enabled data controller on one of the validated distributions of a Kubernetes cluster and

2.       Creating an Azure arc enabled SQL managed instance and/or an Azure Arc enabled PostgreSQL Hyperscale server group.

Kubernetes services and distributions can be sourced widely but there is an option to use the Azure Kubernetes Service which also comes with a flavor for Azure Stack HCI.

When we are creating Azure arc enabled data services, regardless of the service or the distribution, the following information will be needed: data controller name, username, password, name of the Kubernetes namespace and connectivity modes, azure subscription id, azure resource group name, azure location, service principal information and infrastructure such as azure, and container runtime.

One of the ways to secure this diversity is to operate with least privilege. This grants users and service accounts specific permissions required to perform the required tasks. Both Azure and Kubernetes provide a role-based access control which can be used to grant specific permissions. This article describes common scenarios in which the security of least privilege must be applied. The Azure Arc data controller requires some permissions that fall under high privilege such as creating Kubernetes namespace or cluster role. The deployment of data controller can be separated into multiple steps and each of these can be performed by user or service account. The separation of duties ensures that each user or service account has just the right permissions and nothing more. 

 #codingexercise

int GetNodeWithKLeaves(Node root, int k, ref List<Node> result)

{

if (root == null) return 0;

if (root.left == null && root.right == null) return 1;

int left = GetNodeWithKLeaves(root.left, k, ref result);

int right = GetNodeWithKLeaves(root.right, k, ref result);

if (left + right == k)

{

 result.Add(root);

}

return left + right;

}


Friday, August 5, 2022

 This is a continuation of a series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here This article continues to discuss Azure Arc enabled servers and their sizing guidance but brings up some operational considerations when increasing the numbers. 

We noticed several different types of pods that are deployed to the Kubernetes cluster. These include bootstrapper, control, controldb, logsdb, logsui, metricsdb, metricsdc, and metricsui each with their own default values for cpu requests and memory and their limits. Some of these can be customized and controlled.  The SQL managed instances also have similar sizing considerations except that their limits and values are not necessarily double of one another. 

The cumulative sizing and baseline size are also proportional to the number of cores, memory and nodes. With such heterogeneity in the resources, access control and security become more complex than the homogeneous pods.  The high availability, planned maintenance and disaster continuity also affect the sizing. 

One of the ways to secure this diversity is to operate with least privilege. This grants users and service accounts specific permissions required to perform the required tasks. Both Azure and Kubernetes provide a role-based access control which can be used to grant specific permissions. This article describes common scenarios in which the security of least privilege must be applied. The Azure Arc data controller requires some permissions that fall under high privilege such as creating Kubernetes namespace or cluster role. The deployment of data controller can be separated into multiple steps and each of these can be performed by user or service account. The separation of duties ensures that each user or service account has just the right permissions and nothing more. 

Only a certain number of machines can be connected per resource group but there are no limits at the service level.  The networking configuration, transport level security and resource providers required for connected machine agents continue to hold for registering these instances. 

 

 

Thursday, August 4, 2022

  This is a continuation of a series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here This article discusses SQL Server on Azure Arc enabled servers and their sizing guidance.

Azure Arc-enabled servers expose hybrid inventory to Azure management plane.  The Windows and Linux physical servers and virtual machines hosted outside of Azure, on the corporate network or other clouds can become primary citizens as Azure resources when they are Azure-Arc enabled.

SQL instances are a type of resource in the Azure management plan that plays a critical role in governance and security management. Consequently, SQL Server on Azure Arc enabled servers support a set of solutions that require the Microsoft Monitoring agent server extension to be installed and connected to an Azure Log Analytics workspace.

The previous post described the registration of SQL Server instances on Azure Arc enabled servers and the connectivity modes for these instances. This article describes sizing guidance for Azure Arc at scale. Compute, memory and storage must be adequately planned to run the data controller and the number of SQL managed instances and PostGreSQL HyperScale server groups. Since these are deployed on Kubernetes, there is leeway to add additional nodes as necessary. The minimum configuration starts with data controller plus one SQL managed instance and two worker nodes. This configuration requires 16GB of RAM and four cores of available capacity on the Kubernetes cluster. A minimum Kubernetes node size must be 8GB RAM and 4 cores and a sum total capacity of 16GB RAM across all the nodes in the cluster. The data controller is a collection of pods deployed to the Kubernetes cluster to handle the traffic. Its default values for CPU requests are in the range of 20m – 400m from metrics collection to control pod and the memory is in the range of 200Mi – 3 Gi. The limits are roughly double of these values. Each setting can be overridden. The SQL managed instance sizing can however have the values same for requests and limits but with a minimum of 1 and a maximum of 24 cores to handle CPU requests and a minimum of 2Gi and a maximum of 128Gi for memory.

The overall size of an environment required for Azure Arc enabled data services is primarily a function of the number and size of the database instances that will be created. The baseline size is the size of the data controller which requires 4 cores and 16GB of RAM. In addition to cores and memory requested for each database instance, care must be taken to allocate something for agent containers as well.

Only a certain number of machines can be connected per resource group but there are no limits at the service level.  The networking configuration, transport level security and resource providers required for connected machine agents continue to hold for registering these SQL Server instances.

 


Wednesday, August 3, 2022

 This is a continuation of a series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here This article discusses SQL Server on Azure Arc enabled servers.

Azure Arc-enabled servers expose hybrid inventory to Azure management plane.  The Windows and Linux physical servers and virtual machines hosted outside of Azure, on the corporate network or other clouds can become primary citizens as Azure resources when they are Azure-Arc enabled.

SQL instances are a type of resource in the Azure management plan that plays a critical role in governance and security management. Consequently, SQL Server on Azure Arc enabled servers support a set of solutions that require the Microsoft Monitoring agent server extension to be installed and connected to an Azure Log Analytics workspace.

The previous post described the registration of SQL Server instances on Azure Arc enabled servers and the connectivity modes for these instances. This article describes connecting SQL Server instances to Azure Arc at scale.

Multiple SQL Server instances can be connected to Azure Arc as a single task. Azure policy makes this easy to do. Multiple SQL Server instances installed on multiple Windows or Linux machines can otherwise be connected via scripts.

The name of the builtin policy is to enable multiple instances is “Configure Arc-enabled machines running SQL Server to have SQL Server extension installed”. It is disabled by default but it can be assigned to a scope of choice. This installs the SQL Server extension on all Azure Arc connected servers and will assign Azure Connected SQL Server Onboarding role to Arc managed identity in the specified scope. The extension is responsible for finding and registering the SQL server instances to Azure as well as synchronizing their state with Azure.

The alternative is to use a script that is generated for a single machine. It will connect each machine and all installed SQL Server instances on it to Azure. An active directory service principal is preferred to a higher privileged account such as a tenant Administrator.

Only a certain number of machines can be connected per resource group but there are no limits at the service level.  The networking configuration, transport level security and resource providers required for connected machine agents continue to hold for registering these SQL Server instances.

Tuesday, August 2, 2022

 This is a continuation of series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here This article discusses SQL Server on Azure Arc enabled servers.

Azure Arc-enabled servers expose hybrid inventory to Azure management plane.  The Windows and Linux physical servers and virtual machines hosted outside of Azure, on the corporate network or other clouds can become primary citizens as Azure resources when they are Azure-Arc enabled.

SQL instances are a type of resource in the Azure management plan that plays critical role in governance and security management. Consequently, SQL Server on Azure Arc enabled servers support a set of solutions that require the Microsoft Monitoring agent server extension to be installed and connected to an Azure Log Analytics workspace.

The previous post described the registration of SQL Server instances on Azure Arc enabled servers. This article describes the connectivity modes for these instances.

There are two different connectivity modes:

- directly connected

- indirectly connected

The connectivity mode provides the flexibility to choose how much data is sent to Azure and how users interact with the Arc Data Controller. Depending on the connectivity mode that is chosen, some functionality of Azure Arc-enabled data services may or may not be available. When the instances are directly connected, they can be managed via the Portal, CLI and the ARM APIs.  The experience in directly connected mode is like any other Azure service with provisioning/deprovisioning, scaling and configuring.  When the connectivity mode is indirect, the instances appear on the portal in a read-only view. Actions can be taken on these instances either locally using Azure Data Studio or using the appropriate CLI or the Kubernetes tools like kubectl. 

Azure Active Directory and Azure Role based Access Control can be used only on directly connected instances because a continuous and direct connection is required to provide this functionality. 

Only a certain number of machines can be connected per resource group but there are no limits at the service level.  The networking configuration, transport level security and resource providers required for connected machine agents continue to hold for registering these SQL Server instances.

Instance Metadata information about the connected machines is collected and stored in the region where the Azure Arc machine resource is configured and includes details such as Operating system name and version, Computer name, Computer fully qualified domain name and Connected Machine agent version.

The status for a connected machine can be viewed in the Azure Portal under Azure Arc -> Servers.

The connected machine agent sends a regular heartbeat message from a machine and if it stops, it is assumed to be disconnected within 15 to 30 minutes. The machine identity’s credential is valid up to 90 days and renewed every 45 days. Azure Arc-enabled servers has a limit for the number of instances that can be created in each resource group, but it does not have any limits at the subscription or service level.

Monday, August 1, 2022

This is a continuation of series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here This article discusses SQL Server on Azure Arc enabled servers.

Azure Arc-enabled servers expose hybrid inventory to Azure management plane.  The Windows and Linux physical servers and virtual machines hosted outside of Azure, on the corporate network or other clouds can become primary citizens as Azure resources when they are Azure-Arc enabled.

When an Azure Arc enabled Server is connected, it gets a resource ID to be included into a resource group. Standard Azure constructs such as Azure Policy and applying tags are enabled. With SQL Server on Azure Arc enabled servers, the SQL server instance is promoted to the same visibility and rules as other cloud native SQL server instances.  The Azure Arc enabled server already registers the compute with the Azure management plane, so only a registration script is required to register the SQL server instance to Azure. This registration installs a SQL Arc installation to the Connected Machine Agent which in turn shows a SQL Server – Azure Arc resource installed on that machine via the portal. The properties display some of the configuration settings of the SQL Server instance.

SQL instances are a type of resource in the Azure management plan that plays critical role in governance and security management. Consequently, SQL Server on Azure Arc enabled servers support a set of solutions that require the Microsoft Monitoring agent server extension to be installed and connected to an Azure Log Analytics workspace.

The supported cloud operations include govern, protect, configure and monitor. Governance is enabled with Azure Policy guest configurations to audit settings inside the machine. Non-Azure servers can be protected with Microsoft Defender for Endpoint and included through Microsoft Defender for cloud for threat detection, vulnerability management, and monitoring potential security threats. Microsoft Sentinel can be used for SIEM purposes. Configuration is enabled with Azure Automation for frequent and time-consuming management tasks.  Configuration changes can be assessed for installed software, Microsoft Services, Windows registry and files, and Linux daemons using change tracking and inventory. Update management can be used to update Windows and Linux servers. Post-deployment configuration and automation tasks can be performed using Arc enabled servers VM extension. Operating Systems performance can be monitored using VM insights. Other log data such as performance data and events can be stored in a Log Analytics workspace.

Only a certain number of machines can be connected per resource group but there are no limits at the service level.  The networking configuration, transport level security and resource providers required for connected machine agents continue to hold for registering these SQL Server instances.

Instance Metadata information about the connected machines is collected and stored in the region where the Azure Arc machine resource is configured and includes details such as Operating system name and version, Computer name, Computer fully qualified domain name and Connected Machine agent version.

The status for a connected machine can be viewed in the Azure Portal under Azure Arc -> Servers.

The connected machine agent sends a regular heartbeat message from a machine and if it stops, it is assumed to be disconnected within 15 to 30 minutes. The machine identity’s credential is valid up to 90 days and renewed every 45 days. Azure Arc-enabled servers has a limit for the number of instances that can be created in each resource group, but it does not have any limits at the subscription or service level.