全部博文（50）
2010年（50）
分类： WINDOWS
2010-05-17 11:10:02
SQL Azure用户可以基于他们应用程序需求，提供无限制量的数据库。数据可以无大小限制的划分至多个数据库。
SQL Azure database 收费基于应用程序消耗的数据库比例。
用户或合作伙伴需要一个合法的付费地址，并且需要实际位于所支持的国家，来使用Windows Azure 平台。例外是我们允许来自非支持国家的现有CTP参与者维持他们的CTP账户直到他们的国家成为被支持国家，或他们所在国家结束CTP。
我们已经发布了 cost calculator，以便方便用户估计他们的花费。因为估计花费经常存在疑问，我们也提供了一个普通应用程序类型的案例，包括它们运行在Windows Azure平台上的花费。
Service Bus 对于独立提供的连接，基于消费的基础收取每个连接每月$3.99。数据传输收费也如此。如果您能预期您的需求，您可以购买各种连接包（Pack）。举例
5 连接一组为$9.95 ，25 连接一组为$49.75 , 100连接一组为$199.00 , 500 连接一组为$995 ，加上数据传输收费。连接包的每连接都为$1.99 。
Access Control 每100，000个事务收取$1.99,它包括令牌请求、管理操作、加上相关的数据传输。 典型的, Service Bus开发者依靠 Access Control来保证连接的安全。
Windows Azure 平台AppFabric 其通过 Service Bus 提供安全连通性服务，同Windows Azure提供多方面计算与存储服务一样。事实上， Service Bus直接运行于 Windows Azure 计算实例上。因此， Service Bus定价模式与计算/存储定价模式类似。也就是说，当您使用连接资源时，您为他们付费。您使用的Service Bus的基础资源包括计算实例资源，存储资源与网络资源。
因为Service Bus的 高效 与可拓展性，我们提供一个依据这些资源使用情况的单一定价结构。我们称之为连接（ “Connection”） ，它代表了Service Bus的基础功能: 连接2个或多个应用程序。为了使Service Bus发送或接受数据，无论是事务信息还是数据流，您需要一个Service Bus的连接，您可以将它想象为您应用程序与Service Bus 之间的一个通信会话。应用程序任何时间可以打开 （“open”） 或关闭 （“close”)它。当您创建连接至Service Bus的应用程序，我们向您针对每一个连接收费 ，而不是消息量或者数据量。 这些连接会引起打开服务，打开客户端通道，或产生与Service Bus 互动的HTTP请求。
多数情况下，对于每一个连接至Service Bus的设备或应用程序，需要至少一个连接。例如：20个设备，各自有一个连接至Service Bus的应用程序，那么需要20个连接。
如果一个设备有10个分别连接至Service Bus的应用程序，那么需要10个连接。
当您应用程序异常活跃的使用连接时，比如，发送大量信息时，我们还是收取一样的费用。 (相关数据传输的净收费)。 针对每个连接的定价模式帮助用户有效的估计他们每月的花费，并且具有按需增加或减少使用的弹性。
随着一个月内，连接的频繁打开与关闭，您的使用情况可能会有波动。为了适应此情况，我们计算一天内的已打开的链接的最大值。在每月计费期间，我们计算每日使用的平均数，它将会按每天的比例收取。
这意味着您不必为每一个您创建的连接付费。您只需为在计费期间，在某一天并发使用的连接最大值 付费。这也意味着，如果您增加连接的使用，增加的使用会每天按比例收费。您并不会因为增加的使用而收取完整一个月的费用。
举例来说，某个客户端应用程序可能在一天中打开关闭单个连接，这经常发生在HTTP绑定使用连接时。
对于目标系统，这可能会出现地理分散的连接，对于用户来说这就是一个间歇的连接。基于并发连接的收费，保证客户不会因一个间歇连接而重复收费。
案例1: 一个连接非云端数据库至云端服务的复合应用程序，需要使用2个连接。
在规定的月份内，用户可以支付这2个连接，定价为 $7.98。如果用户认为在这整个月内连接数会增加，他可以选择5连接一组的连接包。这样，无论连接数从2个增长到5个，他都只需每月$9.95。
案例 2:另一个应用程序使用 AppFabric 的Service Bus 将一系列手持设备连接至非云端数据库。这个案例中，有一个设备与数据库共用的连接，如果用户前半月使用8个连接，后半月15个连接，他的账单可以使下述三者之一。他可以选择支付一个纯基础消费，花费 $45.891 ；他可以购买25连接一组的连接包，花费 $49.75 ，并具有一定的弹性；或者购买5连接一组的连接包，并未超额的链接支付基础消费，总共花费 $35.892, 此也是最低花费。
每一种选择中，都不会对负荷额外收费，但是用户需要以Windows Azure平台的标准，为流入流出数据量付费。用户应该使用 Access Control来保证他们连接的安全，他们也会接受依据Access Control价格安排一起的价格变动。
1注意: $3.99每连接每月，等效于 $0.133 每连接每天。此案例有 (8 x 15) + (15 x 15) = 225 个连接每天。所以， $0.133 x 225 = $45.89.
2注意: 5连接一组的连接包收费为 $9.95每月。超额连接每个为 $0.133 每连接每天。此案例为 (3 x 15) + (10 x 15) = 195 个连接每天。所以 ($0.133 x 195) + $9.95 = $35.89.
尽管应用程序 与Access Control交互的方式某些程度上与Service Bus的方式类似（通过发送接收信息），但 Access Control还是有一些根本的差异。 最重要的是，这些连接是轻量级并短暂存在的。 这意味着单个 Access Control令牌处理端点可以处理大量与发送令牌请求的外部应用的连接。 基于这些因素， 主要的资源使用直接与处理令牌请求相关：解包解密令牌，依据规则进行声明转换，重新打包重新加密，将令牌返回请求者，创建修改规则。我们使用 “ACS Transactions”计价方法来直接反映事务操作与资源使用之间的关系。
当用户选择购买连接包，他们便在某种程度上“预定”了这些连接。这使得微软能够在用户需要连接前，提前提供这些连接。 当有大量用户以此方式购买链接，我们可以能够预先得知连接容量，来提供一个更有效的表现。并能充分降低提供这些连接的花费。对于用户，得到的利益就是每月更少波动的可预期的花费。然而，许多用户偏爱按次计费的购买连接，因为其更具有弹性。对于，需要弹性与预期兼备的用户，可以在一个账户中选择连接包与标准按次计费的购买方式的组合。这样，只有当连接数超出连接包内的数量时，超额连接数才会被要求按独立的按次计费标准收费。
Service Bus 连接（Connections)对于 Service Bus 端点都是开放的 (一个在 Service Bus 域中的URI),无论在何时应用程序产生如下动作：
1. 在Service Bus 终端打开了一个服务（Service）
2. 打开了一个连接至上述服务的 NetOnewayRelay, NetEventRelay 或者 NetTcpRelay Client Channel 。
3. 产生一个向开放于Service Bus Endpoint的服务（Service）或者信息缓冲区（Message Buffer ）的Http请求--直接或者通过基于HTTP的绑定
出于计费意图，每5分钟，连接便会被计量。间隔内打开的平均连接数便会被记录。我们这么做是为了防止用户因为短暂的增加打开的连接而被不适当的计费。所以在极短时间内打开的连接，例如：10秒， 您不需为此付费。
在任何计费期间内，用户可以按照系统限额与信贷限额，购买任意多的按次付费的独立连接。在计费期间内，他们也可以为每个解决方案购买最多一个连接包。在计费期间内，如果一个用户认为当前的连接包过大或者过小，他可以选择不同的连接包，且差价会按比例并入。对于某个 Service Namespace的连接包大小，每7天只能修改一次。用户不能在同个Namespace下将多个连接包组合使用。
此更改是为了有一个简便的计费方式，使得用户容易理解与预测。早期用户的反馈清晰的说明了 Message Operations 定价模式使得用户对于估算他们的消耗异常困难。计算时间和存储容量与传统非云端计算环境有着一致的概念。然而用户并不喜欢对于信息通信的频繁程度的估算，因此我们选择以开发者以及IT专业人士更为熟悉的以连接计费的方式。
信息操作（Message Operations）的计费方式非常适合于如：分散式事务信息传递的使用。 但它也能运用于更复杂的用途。举例：当您传送一个大文件流时、对一个保持开放的协议进行数据封装，或者部署 许多全天候闲置“监听”的设备时会发生什么？这些情况下，决定如何计算信息数量、预计每日使用量异常困难。
结果是我们的用户内心有许多这样使用的想法。我们的定价模式对于这些情况已经更加适用了。它将流化数据，协议数据封装，事务信息传递等融为一体。 另外，以连接计费提高了可预期性，因为, 无论您从一个月到下一个月或多或少的使用连接，收费都不会变化。我们坚信 Service Bus 定价模式定会满足我们 “简洁，可预期，多功能“的思想，竭诚为您，我们的用户，服务。
为了给客户充足时间为价格结构做准备以及观察他们自己的使用情况，对于AppFabric的收费会在2010年4月开始。到那时，您对服务的使用情况会被记录，以便我们对其计费。5月开始， 我们将发出账单。在2010年4月之前的使用将不会收取费用。直到2010年4月 AppFabric的开始收费，用户仍可以使用Windows Azure平台的支持服务。 一旦开始收费，SLAs会立即生效。
一款使用情况监测工具很快便会发布。
打开的连接的最大值会被用来计算每日花费。为了方便计算，一天定义为从子夜至下一个子夜（UTC)。每天以5分钟的间隔划分，在每一个时间间隔内，计算打开连接的时间加权平均。而此5分钟间隔的平均值的最大值会被用来计算您的每日连接花费。
因为5分钟间隔内的打开连接的最大值会被用来计算您的连接花费，所以您的连接短暂的增加并不会使您造成不适当的收费情况。举例：如果有一个连接在整个间隔内出于打开状态，而另一个只打开了10秒，您的间隔内平均值为1 + 10 ÷ (5 x 60) = 1.0333 个连接。
您可以再任何时间选择一个不同大小的连接包。您也可以增加会减少连接包的大小。每7天只能进行一次更改。
用户可以独立购买确切需要的连接（1到500个连接之间）如果他们能预先得知他们的需求，他们也可以选择连接包（5，25，100，500连接）。另外，用户可以再连接包之外独立购买连接。举例： 5个一组的连接包 + 2 个独立连接 = 总共7个连接。 这样，用户便不可使用其他小于500的连接包。用户在一个Namespace中，最多只可购买一个连接包。经要求，大于500的连接包即将推出。
需要多个连接包的客户需要创建一个额外的服务命名空间（Namespace）举例：如果用户希望拥有 200个连接，则他需要在2个不同的命名空间内各自购买100个连接一组的连接包。
在规定的 Windows Azure 平台子区域内的数据传输将免费提供。任何满足非繁忙时间流入的数据传输都将作为限时促销免费提供。任何子区域以外的流入或流出的数据传输都将按Windows Azure平台标准收费。举例：您使用 Service Bus来使2个Windows Azure应用程序在同一个子区域内通信，您不会被收费。然而，如果您使用 Service Bus ，在不同区域或子区域内通信，例如：从North Central 子区域发送数据至South Central子区域，您将在North Central被收取流出数据费用，而在South Central被收取流入数据费用。如果您在您自己的数据中心内通过 Service Bus只发送不接受数据, 您将只会被收取使用Windows Azure平台而产生的数据流出费用 。
