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
Related
we have a working Netapp with ESXi (VMWare 5.5) setup. With multiple VMs running on 3 ESXi Systems but they are residing entirely on Netapp Storage.
We are thinking of moving this entire setup to private Cloud consists of HP Nimble cloud storage. This cloud is currently owned by one of our departments and are ready to give us space(in terms of storage) and ESXis(VMI Cluster) to run our VMs on a rental basis. So immediate advantage for us is more space, more network speed, DR Setup and not anymore worry about the hardware.
Ofcourse it is in discussion phase but I still would like to ask you experts following questions.
Netapp Storage is all about data plus its configuration (Snapshot, User Quota Policies, Export Rules etc.). When we talk about storage space in cloud, then how are we going to control/administrate the configuration parts listed above? Or will this not be anymore possible to administrate? And the Cloud administrators take this control in their hands and we have to be dependant on them for every configuration changes? This is very important factor.
Will VMs running on Netapp Storage be migrated without much efforts? Is there any documented method for this?
Your view on this will be really helpful.
Thanx in advance.
Regards,
Admin
On point #1, a common way to provide multi-tenant administrator access on NetApp is to create a separate SVM [1] (Storage Virtual Machine) that a tenant administrator can use to manage volume capacity, snapshots, quotas, etc.
For #2, a common migration path for moving VMware VMs is to use Storage vMotion [2]. The private cloud provider can remap the ESXi hosts in your environment to be managed under their vCenter Server first. Then from there, they will have the ability to (non-disruptively, in most cases) move the VMs from your old NetApp datastores to new datastores on their array. They can do the same for vMotioning these VMs over to their managed ESXi hosts.
[1] https://docs.netapp.com/us-en/ontap/concepts/storage-virtualization-concept.html
[2] https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.vcenterhost.doc/GUID-AB266895-BAA4-4BF3-894E-47F99DC7B77F.html
I am confused with azure SQL database backup plan (short term backup retention).
As far as i understood,
In DTU purchasing model, no extra charge for backup storage, you only pay for redundancy type (such as LRS,ZRS)
In vCore purchase model, you will have to pay for backup storage.
am i right ?
does that mean , i will not have any backups if do not subscribe to backup storage in vCore ?
further, in azure pricing calculator, in vCore, General purpose option, you have two redundancy drop down options (i am not talking about long term retention plan) , what is the difference between them ?
Thanks.
i will not have any backups if do not subscribe to backup storage in vCore ?
Yes, in vCore, if you do not allocate a storage account for backups, you will not be able to perform backup operations, either manually or automatically. If you believe you do not need backups, then you might be a fool ;), Azure will maintain access to your database according to the standard SLAs but the infrastructure will not provide a way for you to point-in-time restore the state of your database, only backups can adequately do that for you. But the storage costs are usually a very minimal component of your overall spend. Once the backup operation is complete you can download the backup for local storage and then clear the blob, making this aspect virtually cost free, but you will need a storage account to complete the backup process at all.
in azure pricing calculator, in vCore, General purpose option, you have two redundancy drop down options
Are you referring to the Computer Redundancy:
Zone redundancy for Azure SQL Database general purpose tier
The zone redundant configuration utilizes Azure Availability Zones to replicate databases across multiple physical locations within an Azure region. By selecting zone redundancy, you can make your serverless and provisioned general purpose single databases and elastic pools resilient to a much larger set of failures, including catastrophic datacenter outages, without any changes of the application logic. This configuration offers 99.995% availability SLA and RPO=0. For more information see general purpose service tier zone redundant availability.
In the other tiers, these redundancy modes are referred to as LRS (Locally Redundant) and ZRS (Zone Redundant). Think of this your choice on what happens when your data centre is affected by some sort of geological or political event that means the server cluster, pod or whole data centre is offline.
Locally Redundant offers redundancy only from a geographically local (often the same physical site). In general this protects from local hardware failures but not usually against scenarios that take the whole data center off-line. This is the minimal level of redundancy that Azure requires for their hardware management and maintenance plans.
Zone Redundant offers redundancy across multiple geographically independent zones but still within the same Azure Region. Each Azure availability zone is an individual physical location with its own independent networking, power, and cooling. ZRS provides a minimum of 99.9999999999% durability for objects during a given year.
There is a third type of redundancy offered in higher tiers: Geo-Redundant Storage (GRS). This has the same Zone level redundancy but configures additional replicas in other Azure regions around the world.
In the case of Azure SQL DB, these terms for Compute (So the actual server and CPU) have almost identical implications as that of Storage Redundancy. So with regard to available options, the pricing calculator is pretty well documented for everything else, use the info tips for quick info and go to the reference pages for the extended information:
The specifics are listed here: Azure Storage redundancy but redundancy in Azure is achieved via replication. That means that an entire workable and usable version of your database is maintained so that in the event of failure, the replica takes the load.
A special feature of replication is that you can actively utilise the replicated instance for Read Only workloads, which gives us as developers and architects some interesting performance opportunities for moving complex reporting and analytic workloads out of the transactional data manipulations OOTB, traditionally this was a non-trivial configuration.
The RA prefix on redundancy options is an acronym for Read Access.
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.
I'm using Azure Virtual Machines, specifically Linux. I went to add a blank disk ("attach...blank disk" in the portal) and discovered that Azure only allows a maximum size of 1023GB for disks. The portal won't allow you to specify a size beyond 1023GB.
What I'm looking for is a 4TB filesystem. The disks present themselves as /dev/xd?. I'm wondering if I could take four 1TB disks and stripe them (RAID 0) in the OS? If they're SAN disks then I'm not concerned about the redundancy since presumably they're already protected. I admit it sounds kind of hokey.
Is there another option to get bigger disks in Azure?
To be clear, I want persistent storage, not the ephemeral /mnt/storage.
You are correct. You need 4 disks in Raid0 to get 4TB of data. You can follow the guide below; just make sure to change parameters accordingly because the guide uses 3 disks only.
Configure Software RAID on Linux
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-configure-raid/
Regarding redundancy, no matter what kind of storage you configured in Azure, the worst you can get is 3 mirrors for each disk so just go for full performance.
Azure Storage Replication
https://azure.microsoft.com/en-us/documentation/articles/storage-redundancy/
For Windows you may use Storage Spaces
http://blogs.msdn.com/b/dfurman/archive/2014/04/27/using-storage-spaces-on-an-azure-vm-cluster-for-sql-server-storage.aspx
https://technet.microsoft.com/en-us/library/hh831739.aspx
I'm currently looking into a high-availability approach for a file server within Azure in which I will need to be deploying VMs for. The data on the file server will be constantly changing. From what I read so far, I will need at least 2 VMs and grouping them together into a shared availability set along with creating a cloud service. Although this will address the application and server aspect, what about the storage and the data on them?
I understand that I can't attach a single disk to multiple VMs so I'm a bit lost on how to proceed with this. Any thoughts or ideas on how to move forward with this?
In short, I have a VM with direct data disk attached to it that I'm looking to provide high-availability in the event that the VM goes offline; either through an outage, host patching, hardware maintenance, etc...
Have a look into Azure Blob Storage - don't worry about disks etc, just let the Azure fabric handle the data redundancy and scalability for you!
Here's an "all you need" introduction to WIndows Azure Storage: