Capacity allocation

Power BI Premium provides organizations with significant flexibility for both allocating their resources to premium capacities, as well as assigning Power BI content to those capacities. A single premium capacity can be provisioned and created for an organization or, for larger and more diverse deployments, multiple premium capacities can be created with different sizes (CPU, memory, bandwidth) appropriate for their specific workloads. 

In terms of allocating resources to premium capacities, an organization is only limited by the number of virtual cores (v-cores) that have been purchased. For example, an organization could initially purchase a P2 capacity, which includes 16 v-cores. Once purchased, a P2 capacity could be created in the Capacity settings page of the Admin portal that utilizes all of these cores. However, at some later date, this capacity could be changed to a P1 capacity which only uses 8 v-cores. This would allow the organization to create a second P1 capacity given the eight remaining v-cores available. Alternatively, a second P2 capacity could be purchased, providing another 16 v-cores. With 32 total v-cores purchased by the organization, an existing P2 capacity could be increased to a P3 capacity (32 v-cores). 

The following diagram illustrates this example of capacity allocation:

Power BI Premium capacity allocation

Regardless of the premium SKU (P1, P2, or P3), the combination of SKUs purchased in the Office 365 admin center, or the number of specific SKUs (instances), an organization can use the total number of v-cores purchased as it wishes. For example, purchasing a P3 SKU provides 32 v-cores, the same as purchasing four instances of a P1 SKU (8 X 4 = 32).

For organizations getting started with Power BI and that are comfortable with actively managing their premium capacities, individual instances of the P1 SKU with no annual commitment (month-to-month) could make sense. For example, a single P1 instance could be purchased to start and then, if it's determined that more resources are needed, a second P1 instance could be purchased, making 16 cores available for either a P2 capacity or two P1 capacities.

In this diagram, an organization has chosen to isolate the sales and purchasing app workspaces to their own P1 capacities with eight v-cores each. This isolation ensures that the resources required for one workspace, such as the user's connection to the Sales app, will not impact the other workspace (Purchasing). Additionally, the Finance and Marketing workspaces have been left in shared (free) capacity for now, but could later be assigned to Capacity A or Capacity B if sufficient resources are available.

Whether Power BI workspaces (dashboards, reports, datasets) are allocated to premium capacity or shared capacity is transparent to end users. For example, the same login and content navigation experience in the Power BI web service and Power BI mobile apps applies to both premium and shared capacity. Therefore, organizations can selectively allocate certain workspaces, such as production workspaces accessed by many Power BI Free users, to premium capacity while allowing other small or team workspaces to remain in the shared capacity.

Different patterns for deploying premium capacity are discussed in the following chapters but, at a minimum, administrators should be familiar with the relationships between purchased premium capacity and premium capacities configured for an organization, as well as the assignment of app workspaces to those capacities. 

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.137.220.92