deployed VM. The actual drive is volatile because it is getting stored on the host server itself. If the VM moved in a redeployment (e.g. due to maintenance on the host or shutdown and restart) the content of the drive is lost. Therefore it is not an option to store any important data on this drive. Hence we mostly disregard this drive for SAP deployments. Microsoft Storage provides persisted storage and the typical levels of protection and redundancy seen on SAN storage. Disks based on Azure Storage are virtual hard disk containers (VHDs) located in the Azure Storage Services. The local OS-Disk (C:\) is stored on the Azure Storage, and additional Volumes/Disks mounted to the VM get stored there, too. It is possible to upload an existing VHD container from on-premise or create empty ones from within Azure and attach those to deployed VMs. Those containers are referenced as Azure Disks. After creating or uploading a VHD container into Azure Storage, it is possible to mount and attach those containers to an existing Virtual Machine and to copy existing (unmounted) VHD containers. As those storage containers are persisted, data and changes within those containers are safe when rebooting and recreating a Virtual Machine instance. Even if an instance or a whole hosted service is deleted, these containers stay safe and can be redeployed or in case of non-OS disks can be mounted to other VMs. Within the network of Azure storage servers a redundancy equivalent to three-replica systems is provided. Hence you do not need to use software RAID measures within the VM. More information in regards to Azure Storage can be found here: When deploying services or VMs in Azure, deployment of VHDs and VM Images must be organized in containers called Azure Storage Accounts. When planning an Azure deployment, you need to carefully consider the restrictions of Azure. On the one side, there is a limit of Storage Accounts per Azure subscription. Although each Azure Storage Account can hold a large number of VHD files, there is a fixed limit on the total IOPS per Storage Account. When deploying hundreds of SAP VMs with DBMS systems creating significant IO calls, it is recommended to distribute high IOPS DBMS VMs between multiple Azure Storage Accounts. Care must be taken not exceed the current limit of Azure Storage Accounts per subscription. Because storage is a vital part of the database deployment for an SAP system, this concept
deployed VM. The actual drive is volatile because it is getting stored on the host server itself. If the VM moved in a redeployment (e.g. due to maintenance on the host or shutdown and restart) the content of the drive is lost. Therefore it is not an option to store any important data on this drive. Hence we mostly disregard this drive for SAP deployments. Microsoft Storage provides persisted storage and the typical levels of protection and redundancy seen on SAN storage. Disks based on Azure Storage are virtual hard disk containers (VHDs) located in the Azure Storage Services. The local OS-Disk (C:\) is stored on the Azure Storage, and additional Volumes/Disks mounted to the VM get stored there, too. It is possible to upload an existing VHD container from on-premise or create empty ones from within Azure and attach those to deployed VMs. Those containers are referenced as Azure Disks. After creating or uploading a VHD container into Azure Storage, it is possible to mount and attach those containers to an existing Virtual Machine and to copy existing (unmounted) VHD containers. As those storage containers are persisted, data and changes within those containers are safe when rebooting and recreating a Virtual Machine instance. Even if an instance or a whole hosted service is deleted, these containers stay safe and can be redeployed or in case of non-OS disks can be mounted to other VMs. Within the network of Azure storage servers a redundancy equivalent to three-replica systems is provided. Hence you do not need to use software RAID measures within the VM. More information in regards to Azure Storage can be found here: When deploying services or VMs in Azure, deployment of VHDs and VM Images must be organized in containers called Azure Storage Accounts. When planning an Azure deployment, you need to carefully consider the restrictions of Azure. On the one side, there is a limit of Storage Accounts per Azure subscription. Although each Azure Storage Account can hold a large number of VHD files, there is a fixed limit on the total IOPS per Storage Account. When deploying hundreds of SAP VMs with DBMS systems creating significant IO calls, it is recommended to distribute high IOPS DBMS VMs between multiple Azure Storage Accounts. Care must be taken not exceed the current limit of Azure Storage Accounts per subscription. Because storage is a vital part of the database deployment for an SAP system, this concept
SAP%20NetWeaver%20on%20Windows%20Azure%20Virtual%20Machine%20Implementation%20Guide%20V2_0.docx