Recently I started to use Microsoft Azure Free Trial and I have gone through the link
I created a VM with the help of references. Also I read about Resource Group, Storage Account and Availability Set but I couldn’t understand the requirement and differences among all.
Please be kind to explain the requirement and differences among Resource Group, Storage Account and Availability Set.
In my opinion, these three resources are the logic resources, solutions for some requirement.
The Resource Group is the basic solution for you to manage other resources in the ARM module. As the definition shows:
A container that holds related resources for an Azure solution. The
resource group includes those resources that you want to manage as a
group. You decide how to allocate resources to resource groups based
on what makes the most sense for your organization
The Storage Account, you can also think it as a logic group for storage, a storage solution. It defines some types for different data requirement. And finally, the data still will be stored in the physical disk.
Azure Storage offers a massively scalable object store for data
objects, a file system service for the cloud, a messaging store for
reliable messaging, and a NoSQL store.
The Availability Set, it's a solution for the high availability. Create resources in the
Availability Set. It will help you avoid some accidents without downtime. Also, it can Prevent some erroneous operations from expanding with the update domain and fault domain. In one word, it provides redundancy to your application.
update
As you ask in the comment, first, when you create the VM, the resource group is necessary. But the Availability Set is not necessary, it just created for the high availability. You can create it or not, all dependant on your requirement.
For the storage account, there are two points I think you should pay attention to.
One is that the storage account is just for the unmanaged VM, to store the OS disk as a VHD file that you can manage it yourself. If you create a managed VM, the storage account is not needed to you.
Another is that the storage account also can store the logs, such as the diagnostic log. If you do not want to store the logs, the storage account is also not needed to you.
Note: If needed, you could just create one storage account to store the unmanaged VM OS disk and the logs as you want.
Related
I have Azure Standard subscription, few azure SQL databases which are related to non-prod running on this subscription. Now I have purchased dev/test subscription . I am planning to move those databases/server from Standard subscription to dev/test subscription. I want to know whether it's possible to move to dev/test subscription. Do we have any limitation to move dev/test sub.
Also, will there be any impact to the AAD users(exist on the databases/subscription level) during the movement?
Yes, that is absolutely possible, just to make sure:
There wont be any impact on the Azure Active Directory if the lies in same tenant.
Both the source and destination Azure Active Directory subscriptions must be in the same Azure Active Directory tenancy.
The resources you wish to relocate must be compatible with the relocation operation. See Move operation support for resources for a list of resources that assist moving.
The subscriptions to the source and destination must both be active.
During the move procedure, the source and target groups are locked. Until the transfer is finished, write and delete actions on resource groups are restricted. You can't make changes to resources in resource groups if they're locked.
This does not imply that the resources have been frozen. Applications that use the databases will not experience any downtime if you migrate an Azure SQL logical server and its databases to a different resource group or subscription. They still have access to the databases and can read and write to them. Although the lock can last up to four hours, most movements are completed in considerably less time.
Note: A child resource cannot be transferred separately from its parent resource in most situations.
Please check this Microsoft Document to see which SQL : Move operation support for resources | Microsoft.Sql
We are making use of Azure Functions (v2) extensively to fulfill a number of business requirements.
We have recently introduced a durable function to handle a more complex business process which includes both fanning out, as well as a chain of functions.
Our problem is related to how much the storage account is being used. I made a fresh deployment on an account we use for dev testing on Friday, and left the function idling over the weekend to monitor what happens. I also set a budget to alert me if the cost start shooting up.
Less than 48 hours later, I received an alert that I was at 80% of my budget, and saw how the storage account was single handedly responsible for the entire bill. The most baffling part is, that it's mostly egress and ingress on file storage, which I'm entirely not using in the application! So it must be something internal by the azure function implementations. I've dug around and found this. In this case the issue seems to have been solved by switching to an App Service plan, but this is not an option in our case and must stick to consumption. I also double checked and made sure that I don't have the AzureWebJobsDashboard setting.
Any ideas what we can try next?
The below are some interesting charts from the storage account. Note how file egress and ingress makes up most of the activity on the entire account.
A ticket for this issue has also been opened on GitHub
The link you provided actually points to AzureWebJobsDashboard as the culprit. AzureWebJobsDashboard is an optional storage account connection string for storing logs and displaying them in the Monitor tab in the portal. The storage account must be a general-purpose one that supports blobs, queues, and tables.
For performance and experience, it is recommended to use
APPINSIGHTS_INSTRUMENTATIONKEY and App Insights for monitoring instead
of AzureWebJobsDashboard
When creating a function app in App Service, you must create or link to a general-purpose Azure Storage account that supports Blob, Queue, and Table storage. Internally, Functions uses Storage for operations such as managing triggers and logging function executions. Some storage accounts do not support queues and tables, such as blob-only storage accounts, Azure Premium Storage, and general-purpose storage accounts with ZRS replication. These accounts are filtered out of from the Storage Account blade when creating a function app.
When using the Consumption hosting plan, your function code and
binding configuration files are stored in Azure File storage in the
main storage account. When you delete the main storage account, this
content is deleted and cannot be recovered.
If you use the legacy "General Purpose V1" storage accounts, you may see your costs drop by up to 95%. I had a similar use case where my storage account costs exploded after the accounts were upgraded to "V2". In my case, we just went back to V1 instead of changing our application.
Altough V1 is now legacy, I don't see Azure dropping it any time soon. You can still create it using the Azure Portal. Could be a medium-term solution.
Some alternatives to save costs:
Try the "premium" performance tier (V2 only). It is cheaper for such workloads.
Try LRS or ZRS as the redundancy setting. Depends on the criticality of this orchestration data.
PS: Our use case were some EventHub processors which used the storage accounts for coordination and checkpointing.
PS2: Regardless of the storage account configuration, there must be a way reduce the traffic towards the storage account. It is just another thing to try to reduce costs.
Issue: I am planning to move my Azure Resources to another subscription but as an impact analysis I want to know if Access Keys to a resource such as Storage, Batch Services will be affected.
I have more than 30 services which are currently in use. I am looking forward to having least possible downtime and so I need to analyze what all services will be impacted.
I am aware of the resources which are possible to migrate from the Microsoft page: https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-group-move-resources.
Here are my few questions, I would like to know the answers in all possible cases such as migration to different directory/Azure Active directory or common Azure Active directory.
Will the Access Keys to a resource such as Storage, Batch Services etc.. will be affected after I migrate my resource to another subscription?
Do I need to reconfigure the Service Endpoints?
Thanks.
They wont change
No, storage account endpoints are not tied to resourceId
Can someone tell me the main benefits and differences between Managed disks and Unmanaged disks, various pros and cons of the managed and unmanaged disk and how best can I use this?
I would like to highlight some of the benefits of using managed disks:
Simple and scalable VM deployment: Managed Disks will allow you to create up to 10,000 VM disks in a subscription, which will enable you to create thousands of VMs in a single subscription.
Better reliability for Availability Sets: Managed Disks provides better reliability for Availability Sets by ensuring that the disks of VMs in an Availability Set are sufficiently isolated from each other to avoid single points of failure.
Highly durable and available.
Granular access control: You can use Azure Role-Based Access Control (RBAC) to assign specific permissions for a managed disk to one or more users. Managed Disks exposes a variety of operations, including read, write (create/update), delete, and retrieving a shared access signature (SAS) URI for the disk.
Azure Backup service support: Use Azure Backup service with Managed Disks to create a backup job with time-based backups, easy VM restoration and backup retention policies.
Are unmanaged disks still supported: Yes. Both support unmanaged and managed disks. We recommend that you use managed disks for new workloads and migrate your current workloads to managed disks.
Refer Azure Managed Disks Overview for more details.
Essentially, Managed Disks are easier to use because they don't require you to create a storage account. I think Azure still creates one, but this detail is hidden from you.
The benefit of not having to manage a storage account is that storage accounts have limits, like max IOPS, so that if you place too many disks in a storage account, it is possible that you will reach the IOPS limit. Azure takes care of this for you.
If you have VMs in an Availability Set, Azure will make sure that disks are on different "stamps" ensuring that disks are spread out so that you don't have a single point of failure for the disks.
As for a Con, I've encountered two (but there are probably more):
When taking snapshots they are Full Snapshots, not incremental, so
this adds to storage cost.
If you are setting up a Disaster Recovery between two Azure regions, using Recovery Services, managed disks are not yet supported.
Managed disk for Azure site recovery is now supported
Managed and unmanaged drives in Azure are different concept.
Unmanaged approach treat the drive as a service provided under storage account, you can use this "service" connecting it to your VM but from management perspective is completelly different entity.
Contrary to this approach managed drive is a HDD you connect to your VM, storage account behind it is managed by Azure, so you should get appropriate performance for your disk size. In fact because VMs have there own IOPS limits associatied with hardware profile size just resizing the disk will generally doesn't provide you better performance.
Since managed drives are newer and more "sophisticated" service they are also more expensive.
If you are interested in this topic I did quite complete comparison based on options available over az command line options here. There is also nice practical differences summary here
Managed Disks:
The managed disk provides enhanced manageability and high availability which provides the following features.
Simple - Abstracts underlying storage account/blob associated with the VM disks from customers. Eliminates the need to manage storage accounts for IaaS VMs
Secure by default – Role based access control, storage encryption by default and encryption using own keys
Storage account limits do not apply – No throttling due to storage account IOPS limits
Big scale - 20,000 disks per region per subscription
Better Storage Resiliency - Prevents single points of failure due to storage
Supports both Standard and Premium Storage disks
Unmanaged Disks:
Less availability: Unmanaged disks do not protect against single storage scale unit outage
Upgrading process is complex:
If you want to upgrade from standard to premium on unmanaged disks, process is very complex.
Apart from this unplanned downtime, security is the downsides of the unmanaged disks. However, Cost differences between managed and unmanaged are based on your workload use case
I've created a Hosted Service that talks to a Storage Account in Azure. Both have their regions set to Anywhere US but looking at the bills for the last couple of months I've found that I'm being charged for communication between the two as one is in North-Central US and the other South-Central US.
Am I correct in thinking there would be no charge if they were both hosted in the same sub-region?
If so, is it possible to move one of them and how do I go about doing it? I can't see anywhere in the Management Portal that allows me to do this.
Thanks in advance.
Adding to what astaykov said: My advice is to always select a specific region, even if you don't use affinity groups. You'll now be assured that your storage and services are in the same data center and you won't incur outbound bandwidth charges.
There isn't a way to move a storage account; you'll need to either transfer your data (and incur bandwidth costs), or re-deploy your hosted service to the region currently hosting your data (no bandwidth costs). To minimize downtime if your site is live, you can push your new hosted service up (to a new .cloudapp.net name), then change your DNS information to point to the new hosted service.
EDIT 5/23/2012 - If you re-visit the portal and create a new storage account or hosted service, you'll notice that the Anywhere options are no longer available. This doesn't impact existing accounts (although they'll now be shown at their current subregion).
In order to avoid such charges the best guideline is to use Affinity Groups. You define affinity group once, and then choose it when creating new storage account or hosted service. You can still have the Affinity Group in "Anywhere US", but as long as both the storage account and the hosted service are in the same affinity group, they will be placed in one DataCenter.
As for moving account from one region to another - I don't think it is possible. You might have to create a new account and migrate the data if required. You can use some 3rd party tool as Cerebrata's Cloud Storage Studio to first export your data and then import it into the new account.
Don't forget - use affinity groups! This is the way to make 100% sure there will no be traffic charges between Compute, Storage, SQL Azure.