I created a new Storage account in the Azure portal and choosed an existing Resource Group. It did not create a classic storage account but some kind of resource group-ish storage account that doesn´t have all the options a classic storage account has.
As an example, I could create the "files" folder through code, but I can´t use the code: "blockBlob.UploadFromStream(fileStream);", it gives me error 400 bad request. The same code works when I upload to a classic storage account.
What kind of storage account is seen in my image? Which is more correct, to create a classic storage account (blue icon in image) or the one I did (green/white/grey icon in image)?
First, I would suggest you have a look at David's reply in this thread to know the difference between new Azure storage account and classic Azure storage account.
it gives me error 400 bad request.
There are a lot of issues to caused 400 error. I would suggest your check your code to find out detailed issues. Please test use your code to create container (container name must meet the limitations) to see whether it will work. It is better if you could provide key code.
You created an Azure Resource Manager storage account of type Premium storage in region "North Europe" within your given resource group.
There is not really a right or wrong. As almost always it depends on your use-case.
I want to suggest these docs and samples for getting started with code addressing block blobs and Azure storage in general. Run and explore this code against the storage emulator and/or live storage accounts (classic/ARM standard/ARM premium). May be this helps finding a bug or a misconfiguration in your project.
Azure Blob Storage Samples for .NET
Azure Storage Samples
The issue here has nothing to do with Classic vs Resource Manager. It's related to the fact that the storage account is of type "Premium."
Premium storage accounts are exclusively used for Azure disks (attached durable storage), which are Page Blobs.
Premium storage doesn't support generic blobs/tables/queues. For that, you'd need a non-premium storage account.
Related
I am currently using Azure Blobs to store data for a project. I want Azure to automatically delete old entries (data points) which are older then X number of days. I have found the following documentation:
https://learn.microsoft.com/en-us/azure/storage/blobs/storage-lifecycle-management-concepts?tabs=azure-portal
It essentially says that this can be done using lifecycle management and defining a new rule.
However, this documentation is over 6 months old and I cannot seem to find an option to select lifecycle management and define a new rule.
Has anyone else encountered this problem or know where I can access lifecycle management for an Azure Blob as of 2020?
Yes, this is a feature available today, I just confirmed on a storage account. You need to make sure you are using a V2 storage account, it will not be present on a v1, or blob only storage account.
I was experiencing the same issue, where the option for Life cycle management wasn't available but it was available on other storage accounts.
Check the performance/access tier. If it's set to Premium then its Life cycle management isn't available. Try creating a storage account with Standard.
If your using an arm template try Standard_RAGRS for the sku parameter.
screenshot of storage account in portal:
Doing some work with Azure and queues, and I can get it to work with a classic storage account, but not the standard (newer) storage account.
"Modern" Azure storage account
Classic Storage Account
If I run this code against each of them...:
CloudQueueClient queueClient = storageAccount.CreateCloudQueueClient();
var documentProcessQueue = queueClient.GetQueueReference("documentprocessrequest");
documentProcessQueue.CreateIfNotExists();
...It works for Classic, but with "modern" I get this error:
An unhandled exception of type
'Microsoft.WindowsAzure.Storage.StorageException' occurred in
Microsoft.WindowsAzure.Storage.dll
Additional information: The remote name could not be resolved:
'xxxxxxdocstest.queue.core.windows.net'
What am I missing? Am I doing something wrong, or does queues simply not work with "moderns" storage accounts (sounds unlikely)?
I am using the latest version of the Azure SDK. I have tested the connectionstrings to the storage accounts with other things, like uploading a blog, and they do work.
EDIT:
I created a "modern" Azure Storage account like the below screenshot (and tested with this one, same error) - and I changed the first image to reflect this account.
Basically you're getting this error is because you created a Blob Storage kind of storage account which only supports blobs. Please see this link to learn more about account kinds: https://azure.microsoft.com/en-in/documentation/articles/storage-create-storage-account/.
At this moment, it is not possible to convert this account into a regular (standard) storage account. Thus you would need to create a new storage account and transfer any blobs that you may have in this account to a newer account.
When you create the new storage account, please ensure that the redundancy type of that account is not ZRS or Premium LRS as storage accounts with these redundancy type only support blobs again.
I deployed WorkerRole to Azure Cloud Service (classic) in new portal. With this, I also created Azure Storage account for queue.
Try to add AutoScale rule, the storage account is not listed. Tried to select Other Resource and put Resource Identifier of storage, there's no Metric name listed.
Is it by design that classic Cloud Service and new Storage account not working together?
Storage account data (e.g. blobs, queues, containers, tables) are accessible simply with account name + key. Any app can work with them.
However, to manage/enumerate available storage accounts, there are Classic-created and ARM-created accounts, each with different API's.
The original Azure Service Management (ASM) API doesn't know anything about ARM resources. There's a fairly good chance that, since you're deploying to a Classic cloud service, it's using ASM only and will not be able to enumerate ARM-created storage accounts.
If you create a Classic storage account (which has zero difference in functionality), you should be able to see it as an option for auto-scale.
I have a bit more details on the differences in this answer.
At this time, it is not possible to autoscale anything based on a new "v2" storage account. It has nothing to do with the fact that you are using the classic Azure Cloud Service. I am having the same issue with using Azure App Services. In the end, I just created a classic storage account to use for the autoscaling. There is no difference in how you interact with the different types of storage accounts.
Whenever I create a new Storage (classic) account through the Azure portal I consistently have issues whereby the Table/Queue/File storage is not created at all, leaving the account with only Blob storage, like this:
Instead of like this (separate account):
I have tried this multiple times and all have had the same result. I don't see how I can be getting this wrong as there is only 4 options on the form to create the account, and none of them govern the content of the account.
When I then attempt to create a new Table or Queue in this new account I get a 502 Bad Gateway error.
Am I missing something here? Can anyone tell me how I can add the required storage types to the account.
Not sure what's up with the portal, but a storage account always comprises blob, table, queue, and file storage (unless you create a Premium storage account - that's strictly blobs).
You should be able to confirm this by creating an app to, say, create, write, and read from a queue or table.
EDIT I see you edited your question, showing that you did try to create a table/queue. If this is a non-premium account, I suggest reaching out to support, as this makes no sense.
EDIT 4/2017 Aside from Premium storage accounts (which only have page blobs), there is another type of general (non-premium) storage account, specific to blobs only, where you won't be able to create Tables and Queues, but it's not available via the "Classic" deployment model; it's available only via "Resource Manager" deployment model:
In my case the issue was due to selecting Zone Redundant Storage (ZRS).
Since ZRS accounts only support Block Blobs, you will not see the
table, queue or file endpoints listed on the portal for the new
account.
https://blogs.msdn.microsoft.com/windowsazurestorage/2014/08/01/introducing-zone-redundant-storage/
Recreating the storage account using Globaly Redundant Storage (GRS) worked.
Azure has Storage accounts and Storage accounts (classic) in the Azure Portal.
What are the differences between them? Is there any reason to migrate from a classic storage account to a new storage account?
Classic storage accounts are created using existing Service Management API's (the REST API stack that's been available for the past several years). The newer storage accounts are created with the new Azure Resource Manager (ARM) API's (which are also wrapped in PowerShell and CLI now). Ultimately they provide the same resources to your apps, but they're created/managed differently, and there are a few nuanced differences (such as the ability to tag resources that are created via ARM scripts).
You can't convert a classic storage account (or any classic resource) to a newer type. You don't really need to anyway, unless you're trying to mix resources from classic and new, such as adding ARM-based virtual machines to a classic-based virtual network, or spin up an ARM-based VM from a vhd image sitting in a classic storage account (and for that example, you could always just copy the vhd to a new storage account). Note that, for general storage usage (blobs/tables/queues), you just need the URI and the primary (or secondary) key. With those, you can access your storage resources from anywhere, from any VM/website/etc, regardless if you're accessing storage from classic or new virtual machines, for example.
Check out this link for a general list of differences between classic and new resources.
One advantage of the new over the classic storage accounts is Storage Service Encryption (SSE):
Q: I have an existing classic storage account. Can I enable SSE on it?
A: No, SSE is only supported on Resource Manager storage accounts.
Q: How can I encrypt data in my classic storage account?
A: You can create a new Resource Manager storage account and copy your
data using AzCopy from your existing classic storage account to your
newly created Resource Manager storage account.
There is now a way to migrate Classic resources to the new ARM model. I've done a few myself and it worked as expected. Here's a guide from Microsoft:
https://learn.microsoft.com/en-us/azure/virtual-machines/virtual-machines-windows-ps-migration-classic-resource-manager
In addition to #David Makogon's answer, the new Azure Storage offers reselling resources to sub-subscriptions.
This means that you are able to buy storage from Azure and sell it to your customers.
You can now migrate Classic Storage Accounts to ARM from within Azure.
Settings --> Migrate to ARM
With Azure
With Powershell