调整Azure堆栈 - 以获得纯PaaS要求 [英] Sizing Azure Stack- for a Pure PaaS Requirements

问题描述

大家好，

我想确定一个主要基于PaaS服务运行的Azure Stack Infrastructure（比如一个4节点AzStack硬件配置）的启动器容量 

I want to determine the starter capacity for an Azure Stack Infrastructure (say a 4-Node AzStack HW Configuration) that will run largely on PaaS Services 

1。网络应用服务

2。 SQL（为应用程序操作和报告提供SQL作为PaaS）

2. SQL (Offering SQL as PaaS for Application Operations and Reporting)

3。 Blob存储

哪种指标可以帮助我调整容量？用户数量，数据存储空间等？

What kind of metrics can help me with capacity sizing ? Number of Users, Data Storage Footprint etc ?

Azure堆栈容量计算器能否以任何方式提供帮助，特别是对于所有PaaS PLAY？它似乎更适用于IaaS场景（VM）。
https://gallery.technet.microsoft.com/Azure-Stack-Capacity-24ccd822

Can the Azure Stack Capacity Calculator Help in Any Way, particularly for an all PaaS PLAY ? It seems that is more applicable to IaaS scenarios (VMs)
https://gallery.technet.microsoft.com/Azure-Stack-Capacity-24ccd822

感谢任何使用计算器调整PaaS使用案例的AzStack硬件要求的人的指导

Appreciate guidance from anyone who has used the calculator for sizing the AzStack HW requirements for PaaS Use cases

Akinzo

推荐答案

我知道这不是'答案，但这实际上是一个非常难以提出答案的主题。 太多未知变量。 你必须在某种程度上向后退工作。 此外，不知道有多少Web应用程序，函数，SQL数据库等可以单独部署，这使得容量规划有点困难。

I know this isn't an answer but this is actually a very hard topic to come up with an answer.  Too many unknown variables.  You have to kind of work backwards in some ways here.  Also, not knowing how many Web Apps, functions, SQL DB's, etc. that one may deploy alone makes capacity planning a bit difficult.

我想你可以从App开始服务示例。 首先，您需要为应用服务规划容量。例如， 这很难做到。 如果您在堆栈上进行多租户部署，则未知变量会以每个租户
的价格上涨。 如果您将此用于单个专用租户，那么计划可能会变得更容易。 这还取决于您管理订阅的方式等。 如果这是针对单个公司的，但是您允许内部组再次按照自己的意愿调整多少
订阅，则会产生太多未知数。 例如，每个订阅可以有一定数量的App Service计划。 每个计划都可以达到500 GB。   如果您打算控制订阅
，并且您已经计划好了，并且知道您将只有这个邮票上的5个订阅，那么您正在削减其中的一些未知数。 然后，您可以在那里执行一些自定义配额，限制应用服务计划的数量，限制
这些计划采用的存储空间等。 在App Service SKU中，有许多可自定义的字段可以影响您的计划。 如果您计划严格控制其中一些变量，那么您可以对App Service部署的
容量有一些估计。（nbsp;从那里，您可以规划所有受支持的App Service Server角色，例如前端服务器， 您需要支持估计容量的发布商等。所以你知道可能需要多少VM需要多少VM，需要多少VM，总内存和cpu。 然后你必须规划后端基础设施，你想要它HA。 它们是在默认提供商订阅中托管，还是托管在外部服务器上？ 
此时，您现在可以获取所有这些信息并使用Azure堆栈容量计算器，并使用您知道支持App Service部署所需的所有VM填充它。  

I guess you can start with App Service for an example.  First you need to plan for capacity for app service for instance.  Which is pretty hard to do.  If you are doing multi-tenant deployments on your Stack that unknown variable rises with each tenant.  If you are using this for a single dedicate tenant then planning may become easier.  That also depends on how you manage your subscriptions, etc.  If this is for a single company but you allow internal groups to spin up as many subscriptions as they want then again, that creates too many unknowns.  Each subscription can have a certain number of App Service plans for instance.  Each of the plans can be as large at 500 GB.    If you are going to control subscriptions and you already have that planned out and know you will only have for example 5 subscriptions on this stamp then you are cutting some of those unknowns out.  Then from there you can do some custom quota's that limit the number of app service plans, limit the storage those plans take, etc.  Within App Service SKU's there are a lot of customizable fields that can effect your planning.  If you plan to have strict control over some of these variables then you can get some kind of estimated idea of what capacity your App Service deployment will be.  From there, you can plan for all your supported App Service Server roles like the frontend servers,  the publishers, etc that you will need to support that estimated capacity. So you know may know how many VM's will be needed, what size of VM's, the total memory and cpu that will be need.  Then you have to plan the backend infrastructure, do you want it HA.  Will they be hosted within the default provider subscription, or hosted on external servers?  At this point, now you can take all this information and use the Azure Stack Capacity Calculator and fill it in with all the needed VM's you know you need to support the App Service Deployment.  

此时SQL RP也是如此，等等。 至少使用SQL RP，您可以更好地控制您可以通过配额提供的数据库数量和数据库大小。 如果您的环境是您将控制的单个租户，那么为SQL规划
应该不会太难。 如果您的SQL主机托管在Azure Stack之外，则可以更轻松地进行此规划。 由于SQL RP本身的占用空间很小。

Same thing for SQL RP at this point, etc.  At least with SQL RP you have more control over the amount of databases and sizes of databases you can offer via quotas as well.  If your environment is a single tenant that you will control then planning for SQL shouldn't be too hard.  If your SQL host are hosted outside of Azure Stack that makes this planning even easier.  Since the SQL RP is very small footprint itself.

我知道这没有帮助，但它可能会让你对这个乐趣有更大的了解即将到来？  ：）

I know this doesn't help but it may give you a bigger idea of the fun that is coming?  :)

这篇关于调整Azure堆栈 - 以获得纯PaaS要求的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！