I'm creating one HDInsight cluster in resource group1, but when choosing the storage, it turns out that I can use a storage account in another resource group.
But as far as I know, all resources (including HDInsight) should be bound to only one resource group.
So how is that the HDInight cluster could reach a storage account that is not the same as itself?
This is a false statement - But as far as I know, all resources (including HDInsight) should be bound to only one resource group.
When you using Azure HDInsight - You can use Storage account which can be different Resource Group.
Note: The Azure HDInsight cluster is in the same location as the default storage.
Related
I use Azure Backup Policy to Configure the Azure VMs with Azure Backup.
I use the Tag "backup" with the Value for the Azure Backup Policy. For Example, "default/longtimearchive/ etc."...
Now when I deploy this Policy on the Subscription, I only found 2 VMs.
But I have more than 6 VMs with this Tag.
I have checked the Follow:
Subscription = Correct
The location from The Vault and the VM is the same.
The Tag is set. I have checked it with Powershell.
I have tried to use an other Tag+Value, but it doesn't work.
Why found I only 2 of these 6 VMs?
When I used the Policy "Azure Backup should be enabled for Virtual Machines," I found all of the VMs.
Thanks a lot.
Best Regards,
Phil
Few things to check:
Make sure that the VMs are within the scope of the policy. The scope of the policy can be defined by resource group, subscription, or individual VMs. If the VMs are not within the scope of the policy, they will not be included in the policy.
For VM's with unmanaged disks; If the VMs are in a "stopped" or "deallocated" state, they will not be included in the policy. Check if the ones not being backed up are unmanaged?
Check the tags on the VMs. Make sure that the tags on the VMs match the tags defined in the policy. If the tags do not match, the VMs will not be included in the policy.
what is the difference between "resource group" and "container group" in ms azure?
I tried ms docs but could not find a clear distinction, seems like resource group is a single container while container group is a collection of containers but I am not sure if I got it right.
thank you!
The top-level resource in Azure Container Instances is the container group. It's a collection of containers (Docker containers) that get scheduled on the same host machine. The containers in a container group share a lifecycle, resources, local network, and storage volumes. It's similar in concept to a pod in Kubernetes.
https://learn.microsoft.com/en-us/azure/container-instances/container-instances-container-groups
A resource group is a logical folder (not a Docker container), that groups resources (other Azure services) for an Azure solution.
https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-portal
Resource group
A resource group is a container that holds related resources for an Azure solution.
The resource group can include all the resources for the solution, or only those resources that you want to manage as a group.
You decide how you want to allocate resources to resource groups based on what makes the most sense for your organization.
Generally, add resources that share the same lifecycle to the same resource group so you can easily deploy, update, and delete them as a group.
The resource group stores metadata about the resources. Therefore, when you specify a location for the resource group, you are specifying where that metadata is stored.
For compliance reasons, you may need to ensure that your data is stored in a particular region.
Resource: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-portal
Container group
A set of containers that all run on the same host computer is known to be as a container group in Microsoft azure.
A container group's lifespan, resources, local network, and storage volumes are all shared by the containers in the group.
It's similar to a Kubernetes pod in terms of idea.
A Microsoft's Azure resource's network configuration template is a network profile.
This network profile is the one which provides the resource's network attributes, such as the subnet into which it should be deployed.
If we are going to deploy the container group into a subnet and then to a virtual network, then the azure produces a network profile for us when we use the az container create command.
Resource: https://www.javatpoint.com/what-is-a-container-group-in-microsoft-azure
I have two SQL managed instance in two different region(One in Australia East another one in Australia Southeast. They are in a Pay-As-You-Go subscription. Now I want to move those resources to a CSP subscription. Is it possible to move SQL managed instance across subscription?
Azure SQL managed instance supports the move operation: move to another resource group or another subscription. You can get this from this document: Move operation support for resources.
If you want to move the managed instance subscription, you need to operate on the resource group overview. Choose all the resource about managed instance.
For more details, please see this Azure tutorial: Move resources to new resource group or subscription:
Summary:
This article shows you how to move Azure resources to either another Azure subscription or another resource group under the same subscription. You can use the Azure portal, Azure PowerShell, Azure CLI, or the REST API to move resources.
Both the source group and the target group are locked during the move operation. Write and delete operations are blocked on the resource groups until the move completes. This lock means you can't add, update, or delete resources in the resource groups, but it doesn't mean the resources are frozen. For example, if you move a SQL Server and its database to a new resource group, an application that uses the database experiences no downtime. It can still read and write to the database.
Moving a resource only moves it to a new resource group. The move operation can't change the location of the resource. The new resource group may have a different location, but that doesn't change the location of the resource.
It also gives you many examples about how to move resource group or subscription:
By using Azure portal.
By using Azure PowerShell.
By using Azure CLI.
By using REST API.
Hope this helps.
Some times we had deleted the 'resource group' accidentally on azure cloud, its fine that if our/your resource group does not have any deployments on it and we can create immediately newer one and will proceed our stuff, but if we had deployments on it, then its becomes major problem/task.
So can we recover Resource Group? like a recovery of Virtual machine in Azure.
You can export service configurations that belong to a resource group as JSON. Within the portal, there is an option "Export Template" under the Resource Management Navigation Group.
So can we recover Resource Group? like a recovery of Virtual machine in Azure.
Unfortunately, we have no way to recovery it, if the resource group is deleted . We could get the warning if we try to delete resource group from the azure portal. Connect to Azure support team for help maybe a way, but I don't think it could be easy for restoring.
Note : based on my understanding even if we could re-create the resource with ARM template(If we have exported the ARM template before delete), it seems that just with the same resource names with deleted resource that is not equal recovery action.
Is it possible to share a particular resource (redis cache in my case) across multiple resource group?
Resource group is just logical container. It doesn't matter in which resource group resource is. You can use resources from any resource group.
Example:
Imagine that you create App Service Plan in RG1 and Web App Service in RG2. This Web App Service can use App Service Plan from RG1.
Your redis cache could be used from any code you write, whether in the cloud, on-premises, or wherever, given proper uri + access key.
As long as you have access keys/passwords/etc. to your resources, you can use your resources no matter what resource group they're in. This includes ssh keys, vm usernames/passwords, redis cache keys, storage keys, cosmos db keys, sql database logins, etc.
The only thing access-specific, with resource groups, is granted user permissions. That is: if you add someone as a contributor to resource group A, and not to resource group B, they won't be able to manipulate the settings in resource group B via the portal or any of the Management APIs. Still, they'd be able to work with all of the resources in resource group B, assuming they had the login details / keys / etc.