I have a number of executables that I want to migrate to azure. These executables require the I/O API in order to function properly. So in order to be able to migrate these executables I have to place them inside a cloud drive (VHD). But as far as I know a vhd can be mounted by one role at a time so how can I manage for let’s say 2 or more roles to mount the same VHD?
My first thought is to upload copies of the original VHD so each role can mount its own vhd and read/write to it and then save the files that all roles need to see in blob storage.
Make the VHD sharable via Using SMB to Share a Windows Azure Drive.
Which of the two solutions is better and is there another way I can deal with this issue?
Here's a link to an open source project that bridges System.IO calls to an ASP.NET cloud storage provider.
Related
I am designing a web application and it needs to be in the Azure web app. The app is focused on managing files, so it needs to upload files and store them.
As is a cloud app, I suppose that I am not able to create a directory in the web app service. My question is if I have to use the benefits of Azure and create a Storage Account and if this is the solution, What will be the best storage solution, Blob or File?
Thank you in advance.
Best wishes
Container is a Blob Storage, which is a great option for programmable storage, where our program can read and write to the storage account.
If we don't want to allow websites and the public to access the files, we can choose the below options.
Blob Storage Containers can contain any binary files/ binary large objects, there is no ordering and hierarchy, we can have a virtual folder structure.
Containers are usually programmed to share files to access using Shared Access Signature and Access Policy
I suppose that I am not able to create a directory in the web app service
Azure Files is more useful for mounting a file share to a server and multiple servers can mount the same file share. It can have a quota.
File share has a Directory Structure, we can create Directories and Subdirectories in a Hierarchical manner compared to Containers.
The Connect option in the File Share gives you details on how to mount drive onto a Windows/Linux machine.
Use file storage if you need the shared drive protocol, if not we can design the applications and use blob storage.
As per your requirement, if you want to create Directories you can choose AzureFile Share.
Reference link Azure Blob and Fileshare storage mentioned by #deherman-MSFT
Because Azure has no native FTP capabilities, I created a small VM where clients can drop files. I have a separate webjob that will process those files but I can't figure out how to get access to the files from the webjob. I first created a blob thinking i could attach it to the VM but that doesn't seem to be possible. How is this done?
You can't access the C drive of another VM directly. Maybe you should use Azure files which is SMB file shares? No need for FTP. You can access that share from anywhere and it should be quite easy to use.
For small temporary the cost should be near zero.
How would I write to a tmp/temp directory in windows azure website? I can write to a blob, but i'm using an NPM that requires me to give it file names so that it can directly write to those filenames.
Are you using Cloud Services (PaaS) or Virtual Machines (IaaS).
If PaaS, look at Windows Azure Local Storage. This option gives you up to 250gb of disk space per core. Its a great location for temporary storage of information in a way that traditional apps will be familiar with. However, its not persistent so if you put anything there you need to make sure will be available if the VM instance gets repaved, then copy it to Blob storage. Also, this storage is specific to a given role instance. So if you have two instances of the same role, they each have their own local storage buckets.
Alternatively, you can use Azure Drive, which allows you to keep the information persisted, but still doesn't allow multiple parallel writes.
If IaaS, then you can just mount a data disk to the VM and write to it directly. Data disks are already persisted to blob storage so there's little risk of data loss.
Just from my understanding and please correct me if anything wrong.
In Windows Azure Web Site, the content of your website will be stored in blob storage and mounted as a drive, which will be used for all instances your web site is using. And since it's in blob storage it's persistent. So if you need the local file system I think you can use the folders under your web site root path. But I don't think you can use the system tmp or temp folder.
I am using Windows Azure for a custom blog implementation. The blog uses CKEditor and the CKFinder file management plugin. Typically the file management plugin connects to a file system directory to store the files. I need to store these as if it was a local directory and serve them through HTTP requests. In Azure you cannot rely on the file system to maintain through recycles.
I assume you are to use Azure Storage, but am at a loss as to how to do this. Is there a way to "mount" these storage systems to the file system? Am I correct in my assumptions to use storage? If not any guidance as to what I am missing?
Thanks
Or, you could use AzureBlobDrive to mount blob storage as a drive in Azure directly (no VHD, no limitation on only one instance being able to write).
https://github.com/richorama/AzureBlobDrive
You can actually mount a page blob as an NTFS drive, which is then a "durable drive" (just like any other blob), and you access it via a drive letter, just like a locally-attached (but volatile) drive.
The issue is that, using mounted drives, you may only have one writer, so this might cause challenges when scaling to multiple instances.
Take a look at this MSDN post to see an example of mounting a drive. Notice that, while the example doesn't set up any cache, you can specify a cache size. The cache is stored on a local disk resource.
EDIT: For a tutorial, download the Windows Azure Training Kit. Go to hands-on labs, and open Exploring Windows Azure Storage. Check out Exercise 4: Working with Drives.
I am looking at moving to Windows Azure rather than typical hosting however I'm unsure how best to store images. After searching I've found that there are 2 possible solutions - Blob storage or Azure drive.
I have looked into Blob storage and although I have begun to get used to the idea it will require quite a lot of modification to our CMS. In my searching I have just stumbled across Azure Drive which if I understand correctly creates a virtual hard drive which allows your application to run as it would on a normal server.
Are there any disadvantages to Azure Drive over blob storage? It sounds like migrating current applications to Azure will be much easier with Azure Drive rather than Blob storage but I just wanted to check that there weren't any major flaws in this.
Thanks
Pat
Yes, there are quite a few differences. First, the Windows Azure drive is actually a VHD uploaded as a page blob and mounted by a driver to provide a NTFS partition. So, to get any data on it, you must mount it (or a snapshot). Data is not directly accessible without mounting.
Next, Drives can only be mounted for RW by one instance. If you want anything else to even read that drive, you must snapshot and mount, which introduces a 'staleness' problem to read only instances that are mounting snapshots. You can work around this with an SMB share, but that is slightly complicated.
You would lose the ability to automatically get CDN capabilities if you used a drive as well.
Drives are great for their intended purpose - getting applications that must use NTFS to work in Windows Azure.
If you were to use Blobs natively, you would a.) get the storage subsystem to scale and remove the load from your instances for serving the data and b.) be able to use the CDN to get geoscale on the
images as well.
While it is some work, I would strongly recommend putting images in blob storage. It is ideal for it.