Perform Azure Storage operations from VHD within same Storage account - azure

When working with a VHD hosted within an Azure Storage account, are there any operations one can perform to access the Storage account directly?
I.e. I create a VM and store it's VHD in a blob in account A, are there any local/efficient ways to work with data in account A from the VM?

See if Azure Storage Files service will work for you. You may attach your storage as a file share and communicate with that directly using traditional APIs.
Apart of that, you may use cross-platform Azure Storage Explorer for communicating with other Storage subservices like Blobs.

Related

Blob storage compatibility with Azure Functions

I have some e-mail attachments being saved to Azure Blob.
I am now trying to write a Azure Functions App that would connect to that blob storage, run some scripts and re-save the file.
However, when selecting a storage account for the function, I couldn't select my blob storage account.
I went on the website and it said this:
When creating a function app, you must create or link to a general-purpose Azure Storage account that supports Blob, Queue, and Table storage. Some storage accounts don't support queues and tables. These accounts include blob-only storage accounts and Azure Premium Storage.
I'm wondering, is there any workaround this? and if not, perhaps any other suggestions? I'm becoming a little lost in all the options, and which one to actually choose.
Thanks!
EDIT: Might I add I writing the function Python
I think you are overlooking the fact that you can have multiple storage accounts. In order for an Azure Function to work you need a storage account. That storage account is used to store runtime information of the Azure Function for internal purposes like state management. This storage account is subject to restrictions as you already found out. There is no workaround for that.
However, if the function you are writing needs to access another storage account it is free to do so. You just have to provide details to connect to that specific storage account. In that case you also have a clear seperation between the storage account that is used by the azure function for its internal operations and the storage account your application needs to connect and which you have total control about withouth having to worry that you break things by deleting internal used blobs/tables/queues.
You can have a blob triggered function that gets triggered when changes occur on your specific blob storage. That doesn't need to be the storage account that the azure function internally uses, which is created/selected when creating the azure function.
Here is a sample that shows how to add a blob triggered azure function in Python. MyStorageAccountAppSetting refers to an app setting that holds the connection string to the storage account that you use for storage.
The snippet from the website you are quoting is for storing the function app code itself and any related modules. It does not pertain to what your function can access when the code of your function executes.
When your function executes it will need to use the Azure Blob Storage SDK/modules to connect to your blob storage account and read the email attachments. Here's a quickstart guide for using Azure Storage with Python: Quickstart with Azure Storage Blobs SDK for Python
General-purpose v2 storage accounts support the latest Azure Storage features and incorporate all of the functionality of general-purpose v1 and Blob storage accounts here
There are more integration options with GPv2 accounts including Azure Function Triggers. See: Azure Blob storage bindings for Azure Functions
Further refer: Types of storage accounts
If Blob, based on your need, you can choose an access tier based on the frequency of access for the data (e-mail attachments)Access tiers for Azure Blob Storage - hot, cool, and archive. If General purpose storage account, its standard performance tier.

Azure Media Services and existing Storage Account

Can Azure Media Services re-use an existing Storage Account, for example one we use for Table storage ? Or is this Storage Account dedicated only for AMS ?
Thanks !
You should be able to use an existing storage account as long as it's redundancy type is Locally Redundant, Geo-Redundant, or Read-only Access Geo-Redundant.

Transferring files from one blob to another through vnet in azure

I have a requirement where I need to transfer files from one blob to the other through vnets deployed in different geographies and connected to each other. As I am very new to Azure platform, I tried researching over the web but could not find any proper solution. I got a suggestion that I can achieve this through programming an app service. Please let me know how I can achieve this.
Depends on your scenario, here are options:
To perform a backup of the storage account across different gegions, you can just specify the replication parameter (while creating a new storage account) to one these values:
Geo-redundant storage
Read-access geo-redundant storage
Another article on HA applications:
Designing Highly Available Applications using RA-GRS
If you want to manually copy files from a storage account to another, you can use Azure Storage events, it will push an event to Event Grid every time a blob is created.
Reacting to Blob storage events
You can then use a Logic App or a Function App to copy blobs to another storage account.

Copy files from Azure Blob storage to Azure File Storage with Azure functions

I have files in Azure Blob Storage that I want to be able to share with users through an FTP server running on an Azure VM.
As I understand it you can't mount Blob Storage on a VM but you can mount an Azure File Share using 'net use'.
The files on the Blob Storage will be uploaded incrementally so ideally I would like to copy them to Azure files when they are uploaded and Azure Function seems like the ideal way since they are easy to set up and handle the trigger on the Blob Storage for me.
How would I go about copying a file from Blob Storage to an Azure File Share using an Azure function?
You can setup a Trigger Binding on the Azure Function to be triggered by Blobs in the Azure Blob Storage Container. Then you'll have to download the file stream of the blob and upload it to the Azure Storage File Share.
Azure Functions do not include support for an Output Binding directly to an Azure Storage File Share. So, you'll need to either use the Azure Storage SDK from in code, or look into mounting the File Share to the Azure Functions runtime environment so you can write file updates to it from within the Azure Function.
An alternative solutions would be to use Azure Logic Apps to implement this without writing any code. This article might help for integrating with an Azure Storage File Share -> Connect to on-premises file systems form logic apps with the File System connector

Difference between new and classic storage accounts in Azure

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

Resources