关于Azure存储账户中存储虚拟机VHD文件的注意事项

 Joy Qiao from MSFT  Thu, Mar 12 2015 3:16 PM   我们在使用Azure时经常都会在Azure存储账户中放一些文件,包括Azure虚机的VHD文件也都是放在存储账户中的。建议用户要注意监控Azure存储账户的每秒请求数量等指标,以免超出上限而导致触发限制机制。 每个Azure存储账户可以提供最多500 TB的存储,以及上至每秒20000个请求 Azure存储账户中的每个blob对象,可以提供上至每秒500个请求或者是每秒60MB的数据传输,注意超过这两项其中任何一项即会触发限制机制。 对于标准级别的虚机,建议在一个存储账户下最多不要放置超过40个活跃使用的VHD文件(20,000/500)。注意,当使用一个自定义的镜像创建虚机时,新的虚机文件首先会被自动放置在与镜像所属的同一个存储账户中。这样有可能会导致同一个存储账户中积累过多的虚机及VHD文件。所以当需要基于同一个镜像来创建很多个虚机的时候,建议将虚机创建完毕后尽快迁移到其它的存储账户中。 以下链接的文档中包含有详细的关于Azure订阅以及各项服务的限制、额度和约束等,建议一定要仔细监控Azure账户的使用情况,确保不会超出这些限制。 http://azure.microsoft.com/en-us/documentation/articles/azure-subscription-service-limits/?rnd=1#storagelimits 下面这个powershell示例脚本可以用来监控存储账户中的VHD文件个数。建议一定要定期检查监控所有存储账户中的VHD文件个数,以免超出上面链接文档中所列出的各项限制指标。 Get-AzureDisk|Group-Object { $_.MediaLink.Authority.Split(‘.’)[0]}|select Name,Count  如果在现有的Azure部署环境中已经存在同一个存储账户中有过多VHD文件的情况,那么建议要尽快将这些VHD文件迁移至其它的存储账户,以免触发限制机制。建议可以参考如何将虚拟机迁移至新的存储账户这篇文章来迁移虚机。 如果你有任何疑问,欢迎访问MSDN社区,由专家来为您解答Windows Azure各种技术问题,或者拨打世纪互联客户服务热线400-089-0365/010-84563652咨询各类服务信息。 本文转载自:http://blogs.msdn.com/b/cciccat/archive/2015/03/12/azure-storage-account-vhd.aspx

0

如何将虚拟机迁移至新的存储账户

 Joy Qiao from MSFT  Thu, Mar 12 2015 10:56 AM  Contributors: Blair Chen, Sun Wei, Liu Qing 我们在使用Azure的过程中,有时会需要把Azure虚拟机的相关VHD文件从现有的存储账户迁移到其它存储账户。比如说,当现有的存储账户下面已经存在超过了40个活跃使用的VHD文件,而由于每个VHD文件作为一个Azure Blob对象都可以产生上至每秒500个请求,导致单个存储账户的每秒20000个请求的上限可能会被超出,从而触发限制的机制。在这种情况下,建议需要将这个存储账户下的某些虚机尽快迁移至其它的存储账户,以免触发限制机制。 在讨论如何把虚拟机的VHD从一个存储账户迁移到另外一个存储账户之前,我们先来回顾一下Azure虚拟机的一些基本概念。首先,对于Azure IaaS的虚拟机在设计上是把计算和存储是分离开的。在创建虚拟机的时候,所有持久VHD(系统盘,数据盘VHD文件)都是创建在Azure存储里,而不是直接创建在虚机所处于的物理节点上。虚拟机启动的时候,会直接从存储账户里的VHD文件启动引导操作系统,存储账户中VHD文件本质上是一个blob文件。其次,创建VM的时候,Azure只允许把VHD创建在和虚拟机在同一个区域(比如北京或者上海的数据中心)的存储里,这主要是为了保证计算节点和存储之间的网络延迟尽可能小,从而保证虚拟机的IO性能。 迁移之前的准备计划 如果现有环境已经是生产环境,那么在迁移之前需要有周全的准备和计划,以确保最小化业务系统的中断时间。下面列出了在迁移之前需要检查以及准备的一些事项。 1. 梳理虚机迁移的源存储账户和目标存储账户的对应列表。 首先需要基于上述限制指标梳理一个详细的迁移列表,包括哪些虚机需要迁移,每台虚机迁移的源存储账户以及目标存储账户。如果目标存储账户还不存在,那么可以把目标存储账户先创建好备用。 2. 确认现有的部署架构是否需要虚机的内部IP地址需要保持不变。 由于在虚机的迁移过程中会删除现有的虚机,然后基于迁移至目标存储账户的VHD文件重新创建虚机,在这个过程中虚机的内部IP地址有可能会改变。所以需要确认现有的部署架构中是否对现有虚机的IP地址有任何依赖关系,比如是否使用了内部IP地址进行一些应用层的配置,IP地址的改变是否会影响应用的某些连接等等。 如果需要内部IP地址保持不变,可以在基于迁移后的VHD文件创建虚机时使用静态IP地址来确保虚机能够沿用之前的IP地址。 3. 确认现有的部署架构是否需要虚机的公有虚拟IP(VIP)地址保持不变。 如果需要迁移的虚机是其所属的云服务下面的唯一虚机,那么迁移的过程可能会导致这台虚机及其所属的云服务的公有虚拟IP地址变化。主要因为在这台虚机被删除掉后并且还未被重新创建之前这个时间段内,其所属云服务下面没有挂载任何虚机,这个状态下云服务的VIP资源将会被释放。而当新的虚机在这个云服务下重新被创建后,新的VIP则会分配给云服务。 如果确认需要保持现有的VIP不变,比如说某些客户端不是用DNS域名而是使用IP地址来指向Azure中的云服务,那么可以在迁移中增加一个步骤,比如在迁移这类虚机之前先在其所属的云服务下面创建一个A0型号的虚机。这样来确保在整个迁移过程中这个云服务下面始终至少有一台虚机,这样VIP资源就不会被释放,公有IP地址也就不会改变。在迁移完成后即可删除这个临时的A0虚机。 4. 检查并导出现有虚机的所有属性及配置信息。 通常虚机的所有属性及配置在迁移前后都是需要保持不变的,比如虚机名称、大小型号、开放的端口、所属的云服务、地缘组、虚拟网络等。所以建议导出虚机、虚拟网络的所有属性及配置信息至XML文件以保存记录。  5. 准备回滚计划及脚本。 建议要准备回滚计划,以备万一迁移失败或者时间过长无法在运维窗口时间内完成时,能够快速回滚至原有状态。迁移之前应该准备好回滚的脚本,确保虚机能够随时恢复至原有状态,避免出现预期外的系统中断。 6. 测试存储账户之间的VHD拷贝速度。 在存储账户之间拷贝文件是一个异步的操作,没有速度的SLA。但通常情况如果源和目标存储账户属于同一个物理集群的话,速度一般还是比较快的。根据经验,通常可以在10秒到3分钟之间完成一个100GB的VHD文件拷贝。 但是,如果源和目标存储账户不在同一个物理集群中,那个拷贝文件就可能会比较慢,这就需要运维窗口有足够的时间来完成迁移。同时,也可以用以下方法来控制迁移的时间长度。 a) 如果源存储账户属于一个地缘组,那么可以把目标存储账户也创建在同一个地缘组当中。这样可以确保源和目标存储账户属于同一个集群,从而避免跨集群拷贝文件可能会慢的问题。 b) 也可以进行应用层面的迁移,比如将应用以及相关的数据从现有的虚机中迁移出来,重新部署到新的虚机中。  7. 在生产环境执行迁移之前,先用一台测试虚机测试迁移脚本。 在迁移任何生产环境的虚机之前,建议使用测试虚机对测试脚本进行完整的测试。 8. 准备一台Azure虚机用来执行迁移脚本,避免执行脚本环境的网络问题。 有时用户自己的本地网络可能会有各种限制以及不稳定的问题,这可能会导致迁移脚本在执行过程中由于网络的临时不稳定或丢包造成迁移的中断,造成不必要的麻烦。所以,建议准备一台Azure虚机配置好相关的powershell环境,用来执行迁移脚本。 9. 检查确保所有虚机中的应用、数据库以及用户数据都已经做好备份。   虚机迁移步骤 如果需要迁移的虚机是生产环境,建议按照顺序逐一迁移虚机,确保一台虚机迁移成功没有问题后再迁移下一台。如果出现问题或失败,可以立即执行回滚脚本将虚机恢复至其原有状态,最小化系统中断时间。 下面是一个单台虚机的迁移步骤说明供参考。注意由于每个用户的环境和需求不同,建议可以根据具体情况参考下述步骤进行补充和调整。 1. 导出虚拟机机配置文件 迁移的第一个准备工作是把虚拟机的配置文件导出,这主要是为了后面能用同样的配置信息把虚拟机重新创建出来。下面是导出虚拟机配置文件的powershell代码: $sourceVM = Get-AzureVM –ServiceName $cloudServiceName –Name…

0

保持与 Microsoft Azure Files 的连接

我们在最近的博客文章中介绍了 Azure StorageFiles的预览版,请单击此处 。该文章包含  Azure Files 的相关信息,说明了如何申请预览版并开始使用,还介绍了一些有助于创建共享和传输数据的工具。本文章将重点阐述如何才能创建与 Azure File共享的持久连接,以便您的计划任务、应用程序或已登录用户在  VM重新启动后仍可以使用该共享。 Windows IaaS VM 默认情况下,Windows在重新启动过程中会尝试保持到  SMB共享的连接。但是,系统在此过程中不会自动保存 Azure Files凭据,因此,重新启动后系统将无法重新连接到  Azure Files共享。保存这些凭据的方法多种多样,以下详细介绍了其中的几种方法。 保存凭据 CmdKey 要建立持久连接,最简单的方法是使用“CmdKey”命令行实用程序将您的存储帐户凭据保存到  Windows 中。以下是一个把您的存储帐户凭据保存到 VM中的命令行示例: C:\>cmdkey/add:<yourstorageaccountname>.file.core.chinacloudapi.cn/user:<yourstorageaccountname> /pass:<YourStorageAccountKeyWhichEndsIn==> Note:yourstorageaccountname is not yourlive id but the name in the endpoint. 借助 CmdKey,您还可以列出系统存储的凭据: C:\>cmdkey /list Currently stored credentials: Target:Domain:target=filedemo.file.core.chinacloudapi.cnType:DomainPasswordUser:filedemo 保存凭据后,以后在连接到共享时将不再需要提供这些凭据。也就是说,无需指定任何凭据,您就能连接: C:\>net use * \\filedemo.file.core.chinacloudapi.cn\demo1 Drive Z:is now connected to\\filedemo.file.core.chinacloudapi.cn\demo1….

0

Microsoft Azure File 服务简介

我们非常高兴地宣布在微软Azure中国区推出 Microsoft Azure File 服务预览版。Azure File 服务使用标准 SMB 2.1 协议提供文件共享。Azure 中运行的应用程序现在可以使用熟悉的标准文件系统 API(如 ReadFile 和 WriteFile)在虚拟机之间轻松共享文件。此外,您可同时通过 REST 接口(可支持各种混合应用场景)访问这些文件。最后,Azure Files 采用与 Blob、Table 和 Queue Services 相同的技术构建,这意味着 Azure File 可以利用我们平台中内置的现有可用性、持久性、可伸缩性以及跨地域冗余。 场景 迁移应用程序 很多本地应用程序使用本地服务器上的共享文件夹在各个组件之间共享数据。Azure File服务可以协助轻松地将这些应用程序迁移到云上。为此,每个虚拟机都连接到文件共享(请参阅下面的“入门”),然后虚拟机可以像使用本地共享文件夹一样读取和写入文件。 共享应用程序设置 分布式应用程序的常规模式是将配置文件放在一个集中位置,以便可以从许多不同的虚拟机进行访问。现在可以将此类配置文件存储在 Azure File 共享中,供所有应用程序实例读取。这些设置也可以通过 REST 接口管理,这允许从全世界任何位置访问配置文件。 诊断共享 Azure File 共享也可以用于保存诊断文件,如日志、指标和崩溃转储。通过 SMB 和 REST 接口提供这些文件,可以让应用程序构建或利用各种分析工具来处理和分析诊断数据。 开发/测试/调试 开发人员或管理员在云中操作虚拟机时,通常需要一整套工具或实用程序。在需要的每个虚拟机上安装和分发这些实用程序是一项非常耗时的工作。有了 Azure Files,开发人员或管理员可以将喜爱的工具存储到可以轻松从任何虚拟机连接的文件共享中。 入门 步骤 1:创建新存储帐户 微软Azure File公共预览开放之后,所有新创建的存储账户,都将自动配置文件端点。帐户的文件端点将为:<帐户名称>.file….

0

如何在Azure环境里做好信息传递可扩展性经验分享

作者 王枫 发布于2014年5月15日 综述 本文介绍建立一个在Azure上使用Azure服务总线, 高吞吐量短信平台的必要步骤。在这篇文章中提出的解决方案是在响应由客户的具体要求,建立一个基于Windows Azure技术的复杂远程信息处理应用。 在Windows Azure中的通讯服务 Windows Azure平台通过不同的技术支持信息通信: 存储队列 服务总线 以下各段将给予每个类型的信息传递技术的概览。 存储队列 您可以使用Windows Azure中的队列,支持组件之间的异步通信。应用程序中的组件可以发布信息到一个队列。其他组件可以接收信息,并提供处理。队列中提供组件之间耐用的持久性存储,以及负载调平,负载均衡,和缩放的好处。 服务总线 Windows Azure服务总线为广泛的交流,大型活动分布,命名和服务发布提供了一个托管,安全和广泛可用的基础设施。服务总线为Windows Communication Foundation(WCF)和其他服务端点提供连接选项 – 包括REST端点 – 否则将很难或根本不可能达到。 针对Windows Server的服务总线是一组可安装的组件,为Windows Sever上提供Windows Azure服务总线的信息传递功能。适用于Windows Server的服务总线,使您能够在自我管理的环境,并在开发计算机上构建,测试和松耦合运行,信息驱动的应用程序。 通讯设计模式 使用存储队列构建松散耦合的信息传递方案 Windows Azure的队列存储是一个用于存储大量的信息,可以在世界任何地方通过身份验证的调用使用HTTP或HTTPS访问服务。一个单一的队列的信息可高达64KB的大小,队列可以包含数百万条信息,高达100TB的总极限容量的存储帐户。常见队列存储用途包括: 建异步处理积压的工作 Windows Azure Web角色中传递信息到Windows Azure Worker角色 队列服务包含以下组件: URL格式:队列可以通过以下URL格式访问:http://<storage account>.queue.core.windows.net/<queue>下面的URL地址针对图中的队列:http://myaccount.queue.core.windows.net/imagesToDownload 存储帐户:所有Windows Azure存储是通过一个存储帐户来访问的。存储帐户是访问队列的最高级别的命名空间。帐户内表格和队列内容存储的总大小不能超过100TB。 队列: 队列中包含一系列信息。所有信息必须在队列中。 Message: 一个信息,无论任何格式的最大上限是64KB 一个涉及多个组件之间的存储队列典型的架构设计模式,可以类似于下列: 在这个模式中,多个前端Web Role客户端发送信息到一个或多个存储队列,然后多个Worker Role实例从一个或多个队列读取信息及进行处理。 上述架构可以通过以下方式缩放: 存储队列:当信息并发数量增加,可以增加更多的存储队列…

0

StorSimple 简介

2014 年 10 月 28 日,星期二 PRACHEETI NAGARKAR DESAI 混合云存储业务资深项目经理 在此我很荣幸地宣布 StorSimple 解决方案已经在中国正式上市。该方案为IT 部门提供了一种管理飞速增长的数据,在保护数据的同时简化内部环境存储基础结构的新方法。凡客诚品等客户已经试用过该方案,并已获得大量收益。 StorSimple 解决方案是一种混合云存储解决方案,需使用位于客户数据中心内部的存储装置,并将其集成至 世纪互联运营的 Windows Azure,借此组件成一套单一的存储解决方案。StorSimple 能提供内部设备所具备的高性能,以及云存储的成本收益。StorSimple 的存储分为三层:位于本地装置中的 SSD 和 SAS 层,以及云层。数据将通过一定算法在不同层之间自动转移,确保活跃数据始终保存在本地,以提供最优化的性能,同时不活跃数据可分层至云端,获得云计算的经济效益。传入和传出 Azure,以及云端存储的所有数据都会使用 AES-256 位算法进行加密。 StorSimple 包含下列核心功能。 StorSimple 云集成存储 – 通过使用 5000、7000 系列装置,IT 部门可获得 4-100TB 完全冗余的本地高性能存储容量,整套方案的总容量最大值高达 100-500TB。 iSCSI 卷访问 – IT 存储管理员可使用 iSCSI 协议提供存储卷,应用程序无需任何改动即可直接使用这套存储解决方案。 自动化数据分层 – 热数据可自动保存在本地,获得更高性能,冷数据可分层至云端。 数据去重和压缩 – 可消除数据的重复副本,降低存储空间的消耗。 AES-256 位加密…

0

了解 Windows Azure 存储计费 – 带宽、事务和容量

我们收到关于如何估算 Windows Azure 存储成本,以便了解如何更好地构建一个经济有效的应用程序的问题。在本文中,我们将从带宽、事务和容量这三种存储成本的角度探讨这一问题。 使用 Windows AzureBlob、表和队列时,存在以下几方面的存储成本: 1. 带宽 – 从托管存储帐户的位置传入和传出的数据量 2. 事务 – 对您的存储帐户所执行请求的数量 3. 存储容量 – 持续存储的数据量 请注意,随着我们向存储系统添加更多功能,本文内容也会不时予以更新。本文将作为指导原则,使服务能够在应用程序运行于生产环境之前估算其存储带宽、事务和容量使用情况。 Azure存储服务目前在中国地区提供了一定的免费存储事务的额度。 存储事务:前100 亿个存储事务是免费的。 具体定价信息请参考:http://www.windowsazure.cn/zh-cn/pricing/overview/ 下面概述了这三个方面的计费情况:       带宽 – 由于应用程序需要基于存储数据进行计算,因此我们允许托管服务与存储归置在一起。这样我们就能在归置在一起的计算和存储之间提供免费的带宽,将仅对从数据中心外部访问存储所用的带宽计费。 事务 – Blob、表(Table)和队列(Queue)向存储服务提交的每一个 REST 请求均视为一个潜在的待计费事务。这样,应用程序就可以通过控制向存储服务发送请求的频率和数量来对事务成本加以控制。我们会分析收到的每一个请求,然后根据我们处理请求的能力及请求的结果将其划分为可计费或不可计费两类。 容量 – 我们通过汇总所存储对象(Blob、实体(Entity)和消息)及其应用程序和系统元数据的大小来测算待计费的存储容量。 接下来,我们将解释如何了解您的应用程序的这三个方面。 什么时候带宽会被计费 要访问 Blob、表和队列,首先需要通过 Windows Azure 开发人员门户创建一个存储帐户。在创建存储帐户时,您可以指定存储您的存储帐户的位置。我们目前在中国提供的数据中心位置包括: 1.  中国北部 (北京) 2.  中国东部 (上海) 存储帐户中的所有数据都将通过所选位置进行存储和访问。一些应用程序会选择在地理上最接近其客户群的位置,以尽可能降低对这些客户的延迟。这里一个关键方面是,您应该在开发人员门户中为您的托管服务选取与存储服务需要访问的存储帐户相同的位置。原因就在于在同一位置内部传输数据所用的带宽是免费的。相比之下,当从存储帐户指定位置传入或传出数据时,本文开始部分提及的带宽费用将会累计。 这里需要重点指出的是,在同一位置访问所用的带宽是免费的,但相关事务不是。对存储系统的每一次访问都计为一个待计费事务。此外,仅对被视为可计费的事务所使用的带宽收费,下文有对此类事务的具体定义。 带宽方面涉及的另一个概念是在您通过 Windows Azure 内容分发网络 (CDN) 使用…

0

USENIX 最佳论文奖:擦除 Windows Azure 存储编码

我们发表了一篇介绍Windows Azure 存储如何用编码方式擦除数据的论文,此论文在 2012 年 6 月的 USENIX 技术年会上荣获最佳论文奖。这是 Microsoft Research 和 Windows Azure 存储团队共同努力的成果。 您可以在此处找到此论文。 Windows Azure 存储是一个云存储系统,可使客户能够按任何期限无限量存储数据,使数据具备高可用性和持久性。在使用 Windows Azure 存储时,您可以随时随地访问您的数据,而且只需为您所使用和存储的内容付费。 Windows Azure 存储如何工作的内部细节在我们的 SOSP 论文中有所介绍,您可单击此处查看此论文。SOSP 论文中简要说明的一个方面是,我们在保持您的数据持久性和高可用性的同时,在后台通过仅在需要时擦除数据来降低存储开销。 在 USENIX 论文中,我们介绍了 Windows Azure存储如何用编码方式擦除数据。我们引入了一个新的编码集,称之为本地重建编码 (LRC)。LRC 在重建离线数据段时,可减少需要读取的擦除编码段数量,但同时还能将存储开销保持在较低水平。LRC 的重要优势之一在于,可减少在之前编码上重建读取所需的带宽和 I/O,同时仍能显著降低存储开销。适用于在以下情况下有效重建段:(a) 单一段失败(如磁盘、节点或机架失败);(b) 升级导致段离线;或者 (c) 访问某个段速度较慢。在论文中,我们介绍了Windows Azure 存储如何使用 LRC,以提供具有持续低读取延迟的低开销持久存储。此外,我们还介绍了涉及其中的擦除编码实施和重要的设计决策。 Brad Calder 本文翻译自: http://blogs.msdn.com/b/windowsazurestorage/archive/2012/06/13/usenix-best-paper-award-erasure-coding-in-windows-azure-storage.aspx

0

将大型 Page Blob 的页范围进行分段

Windows Azure 存储支持一种 Blob 类型,即 Page Blob。Page Blob 通过仅将已写入但未清除的页存入物理存储, 来有效存储稀疏数据。每页大小为 512 字节。Get Page Ranges REST 服务调用将返回包含有效数据的所有连续页范围的列表。在 Windows Azure 存储客户端库中,GetPageRanges 方法提供此功能。 如果服务处理请求的时间过长,Get Page Ranges 在某些情况下可能会失败。与所有 Blob REST API 类似,Get Page Ranges 使用超时参数,此参数用于指定允许请求的时间,包括通过网络进行读/写。但是,仅给服务器一段固定时间来处理请求和开始发送响应。如果此服务器超时已过,则即使还未到 API 超时参数指定的时间,请求也会失败。 在一个高度分散但具有大量写入的 Page Blob 中,填充 Get Page Ranges 返回的列表可能要比服务器超时的时间更长,所以请求将失败。因此,如果应用程序使用的模式中含有大量 Page Blob写入,并且您想要调用 GetPageRanges,建议应用程序应一次检索一部分页范围。 例如,假设 500 GB 的 Page Blob 通过 500,000 次写入来填充整个 Blob。默认情况下,存储客户端指定 Get…

0

了解 Windows Azure 存储的可伸缩性、可用性、持久性和计费

借助 Windows Azure存储,应用程序开发者及其应用程序和用户可以在云中使用可用性更高、持久性更长、可伸缩性更强的海量存储。开发者可以构建能随时随地高效访问数据的服务,在所需的时间段内存储任意数量的数据,并按基于实际使用情况进行付费(仅以所使用和存储的数据为基础)。我们提供以下  3种存储抽象技术: Blob –为存储命名文件以及该文件的元数据提供一个简单接口。  表–提供大规模可伸缩的结构化存储。表是一组包含一系列属性的实体  (Entity)。应用程序可以使用这些实体,并对表中存储的任何属性进行查询。 队列 –为应用程序提供可靠的消息存储和传递,从而在应用程序的不同部分(角色)之间构建松耦合和可伸缩的工作流。 Windows Azure现已在中国发售,我们也收到了有关  Windows Azure存储工作原理以及如何从中获取最佳性能等问题。因此,在接下来的一段时间内,我们将发布一系列博客文章,主要专注于了解如何有效利用 Windows Azure存储及其可伸缩性、可用性、持久性以及计费情况。 以下内容概述了计划翻译的一系列文章(发布顺序可能有所不同)。文章发布后,我们将在此处分享所有链接: 1. 存储抽象技术及其可伸缩性 Windows Azure 存储抽象技术及其可伸缩性目标是什么? 如何访问及扩展 Blob? 如何访问及扩展Table? 如何访问及扩展队列?  2. 计费 如何了解和估计应用程序的  Windows Azure 存储带宽、事务和存储容量?  3.存储体系结构概述 Windows Azure 存储体系结构的模式是什么,以及它如何提供可伸缩性、持久性和可用性? Brad Calder 本文翻译自: http://blogs.msdn.com/b/windowsazurestorage/archive/2010/05/07/understanding-the-scalability-availability-durability-and-billing-of-windows-azure-storage.aspx

0