Blob data stands for Binary Large OBject data. Blob data and can represent a wide variety of types of data you normally store on your computer including images, videos, and documents.
In Azure, you can store blobs inside of storage accounts. Storage accounts are containers capable of storing different categories of data including:
- Blobs
- Files
- Tables
- Queues
You should usually choose blob storage when dealing with unstructured data. Depending on your blob storage needs you can choose between the following types of blobs in Azure blob storage:
Block blobs are divided into blocks of up to 100MB in size. Blobs of up to 190.7 TB (terabytes) can be stored using block blobs in Azure Storage. Using multiple blocks to represent the blob allows for more efficient handling of large blobs. Usually, the complexity of managing individual blocks is handled for you so you can simply deal with the entire blob rather than individual blocks.
Append blobs are optimized for appending new data at the end of the blob. This is particularly useful for storing log data where new lines are added at the end and the data never needs to be modified after it is written.
Page blobs are optimized for random read/write operations. The name comes from the practice of operating systems organizing memory into pages of relatively small sizes that can be easily managed. In Azure, page blobs are collections of individual pages of up to 4MB each. They are used for storing virtual machine disks in Azure.
Lets see in Microsoft Azure:
Assuming we have a setup and we have already created some services which includes Storage account too.
Lets get into that storage account. These are some of my storage account subscription details.
There are a few properties specific to storage accounts in this section:
The Disk State indicates that the storage location is Available. In the event of an outage in Azure, you may see a different value here. This storage account has no secondary storage location, but you can create storage accounts with primary and secondary storage locations. The Replication property of a storage account determines this.
The Performance can be standard or premium. When you need guaranteed latency you should use premium storage. Premium storage has much higher storage costs because they use solid-state drives (SSDs) whereas standard storage uses magnetic spinning hard disk drives (HDDs).
The Replication sets the durability and availability of the storage. The following options are available:
Locally-redundant storage (LRS) is the cheapest option and stores the data in a single data center. If that data center goes offline you will not be able to access the data.
Zone-redundant storage (ZRS) stores data across three data centers in a region. It can tolerate individual data center outages but not regional outages.
Geo-redundant storage (GRS) stores data across multiple data centers in two regions, a primary region and a secondary region. This option is more expensive but can tolerate entire regional outages. There is also read-access geo-redundant storage (RA-GRS) which allows you to read from the secondary region compared to GRS which only allows you to access the secondary in the case of a Microsoft-initiated region failover to the secondary.
Finally, the Account kind describes if the storage account is general-purpose or specialized. General-purpose accounts allow storage of blobs, tables, files, and queues whereas specialized kinds only allow one type such as only blob storage. There are different pricing models for each account kind so a specialized kind may reduce your costs. StorageV2 is the recommended default.
Lets go to the Container option where blob storage is saved.
Lets create one now.
We will choose "Container" from the drop down because this allows anonymous access to the container and the blobs within it. It is also possible to allow no anonymous access or only anonymous access to blobs.
Then clicked Create.
Lets upload a sample image from our desktop which is a blob object and as we know containers are supposed to store blob storages.
If we go inside it, we will not find anything.
Notice you can configure the Blob type, Access tier, and** Upload to folder** to organize your container. Although a storage account also has an access tier, it only sets the default value for each blob. You can override the default value for each blob and this is the only possible way to set the archive access tier since it cannot be set at the storage account level.
Lets type "images" for folder.
Now press Upload .
Once done. This is what we will get.
A folder called images which will have our image.
After pressing the images folder, we can see this.
There are multiple options we might get for this blob storage now.
Blob storage can store any type of file as well but **file shares **are best suited for use cases where you want to share files using computers' file systems to make accessing and sharing files easy.
Azure file shares support the industry-standard Server Message Block (SMB) protocol and can be used to share files across Windows, macOS, and Linux machines.
Under the storage account, lets go the the files share now.
Assuming a file share was already created for us.
Shares have a quota to limit the amount of storage and, as a consequence, the maximum cost of storage for the share.
Shares can store up to 5 tebibytes (TiB) or 100 TiB* depending on the region. For **standard storage accounts, you only pay for the storage you use and not the quota you set. However, for premium storage accounts you pay for the quota since the storage is provisioned completely to provide you guaranteed performance levels.
Lets get into it and press the connect.
Once you connect to the file share you can use it the same way you would use your local hard drive and multiple users can share it at the same time.
Azure virtual machines (VMs) use Azure disks as their attached disk storage. Azure disks are built-on top of page blobs which are the type of blobs optimized for random access.
When you create Azure disks you can choose to manage the storage account yourself or to use managed disks where Azure manages the storage account for you.
Managed disks are the preferred option. Within managed disks you can choose between:
Ultra SSDs which provide the best throughput and I/O operations per second (IOPS) performance characteristics but at the highest prices. Consider Ultra SSDs for mission-critical I/O intense applications such as running databases.
Premium SSDs are the next best performing and are well-suited to production workloads with all but the highest performance I/O requirements that may benefit from using Ultra SSDs.
Standard SSDs are the least expensive SSD option and are suitable for production workloads with low I/O performance requirements such as web servers and lightly used applications.
Standard HDDs use spinning disk technology and are therefore the least expensive option but also provide the lowest performance. Use them for backups and infrequently accessed applications.
Azure disks give you the freedom to attach and detach from different VMs. They will maintain their data but the data is only usable when a disk is attached to a VM.
Lets check it out from labs.
Under the disk option, we can see this.
Each VM has one OS disk which contains the operating system and is used to boot the VM. The OS disk is a Standard SSD in this case.
In addition to the OS disk, VMs can have zero or more Data disks **attached. This VM has one data disk that is a **4 GiB Standard HDD.
All disks are encrypted at rest automatically and transparently to any users.
This means if someone were to steal a physical disk from an Azure data center the physical disk would be encrypted and unusable. This is true for all data in Azure storage accounts.
However, for Azure disks, you can also encrypt the virtual disk at the operating system level. This is referred to as Azure Disk Encryption (ADE). This protects against someone attempting to copy your Azure disk and attach it to an Azure VM because they would not be able to decrypt the data without the encryption key. Azure recommends enabling ADE for production workloads.
Lets get into the OS disk.
You can see the disk is Attached to the lab VM (Managed by: ca-lab-vm) and the Operating system is Windows.
We can see the visual report here too.
if we now access our VM which is using a windows OS, we can see this.
Look we have 29.5 GB storage which we knew from here too.
Done for this blog!
Top comments (0)