Forum Discussion
Report Server architecture and licensing question
- 4 years ago
- 4 years ago
I'm not licensing expert, but I think no.
-Even though technically and internaly is PBIRS composed of several components (Web Portal, SSRS, PowerBI and SSAS (in tabular diskless mode)) and SSAS is key performance component, from customer, installation and licencing point of view it is only one component = PBIRS. And all cores where PBIRS is running (regadless which internal componet uses which cores) must be licensed.
-By default PBIRS is running on all cores which is avaliable on machine. And you need licence for all cores where PBIRS can potentialy run.
-It is mean, if you have 8core machine, you need 8licences (4x 2pack). If you want limit number of cores, it must unavaliable on OS level (e.g. turning off in BIOS, or lower virtual cores on virtual machine).
-But with EE with SA you have two option how to licence. On virtual cores (for each core on virtual machine you need licence), or physical cores (for each physical core on physical machine you need licence, regardless number of virtual machines and total number virtual cores, which can be much more).
To second question, I'm not sure, but I think is not possible, but most importatntly it is not good way. Main difference between import mode and live connection mode is not technical backgroud (both is based on xVelocity engine), but developing cost and user learning path. For Import mode PBI, user need only Power BI Desktop RS, and average user, can produce nice PBI reports within ten minutes. But for Live connection mode, mean for design dedicated tabular model, which bring more opportunities (like much larger models, incremental update, multiple reports per model, and so on), you need advanced user, and need more developer tools (like visual studio or tabular editor) and much more SSAS experience. In my real practise, we have on PBIRS thousands Import mode small reports, but only tens dedicated SSAS models (but in total size much larger then all import mode reports. These are two way, for different approach, but both are correct. Yes, there is challenge how to balance performance, one option is to licence physical cores, and balance power between virtual machines using virtual cores, which you can change anytime.
1. Report Server Database is MSSQL (relational DB), and is only for Report Server Catalog.
2. For "Import Mode" PBI Report, SSAS server is covered by PowerBIReportServer.exe instalation, and hosting inmemory database and executing dax queries, is always on same server as web portal, and cannot be separated. Only procesing (scheduled refresh) of import mode reports can be separated to another machine (but is still covered by PowerBIReportServer.exe installation.
3. It is not possible for import mode, If you using import mode report, you do not need separated SSAS server. Techically SSAS integrated in PBIRS working in diskless mode, Report Server separate definition and data, but both is persisted stored in Catalog Database, and non-persist are also loaded to inmemory SSAS integrated database (on same machine as web portal).
4. Maybe yes, but it is not recommended. By default, all cores and all memory on machine is used for xVelocity engine. The reason is simple, there is nothing else (nothing important), Power BI Report Server is some portal web (but it not resource intensive), and SSAS instance (which is only resource important).
5. ODBC (or any refresh related part) for import mode must be installed on Power BI Report Server (covered PowerBIReportServer.exe), but you can scale out installation on mutiple servers, and is possible one machine use only for scheduled refresh.
My recomendation:
-use Scale out deployment of PBIRS, at least on three machines, two loadbalanced as frontend (web+xVelocity SSAS) and third for background (xVelocity SSAS+PQ+ODBC)
-do not limit on "import mode" reports, because there much more limitations in compare with PBI Service, for large model you will need dedicated SSAS server + PBI report with Live connection mode
- josef784 years ago
Memorable Member
6. You need licences for every core where you running any piece of SQL Server. You can licence virtual cores, on some virtualisation platform, or in case of EE with SA you can licence physical cores, independent how many virtual machines and how many virtual cores you have (on licenced physical server).
7. Right approach, but you need licences for both. If you install PBIRS on one machine you need licence for SQL Server (EE with SA), and also for second machine with SSAS you will need also SQL licences (posible Standard without SA, but in real case you will need Enterprise). In this case, from perfomance perspective, importat is SSAS server. But in real case, clear import-mode approach or clear live-connection approach is not ideal, in real case scenarion you will need mix both approaches, import-mode approach for simple, small and fast-delivery reports, and live-connection (with dedicated SSAS) for large and strong developed models.
8. Not possible (yet, officially) for import mode report. If you need use paginated report on your models, you need use dedicated tabular model on dedicated SSAS server, which will serve data to you PBI report and also for paginated reports.
- Anonymous4 years agoNot applicable
Thank you josef78 for your very, very clear explanation!
Two more questions, just to be sure:
Regarding licensing, from your answer to question 6. I assume the PBIRS checks the number of cores that are licensed and uses only the licensed number of cores for the xVelocity engine. Right?
You wrote that I'll probably face use case where I want to use the import mode even though I have a separtate SSAS. Nevertheless, would it possible for the administrator to forbid publishing import mode files so that using live connection to the SSAS is enforced? Then I could set up a large machine for SSAS and a small machine for PBIRS without running into users complaining about slow (import mode) reports.
BR,
Martin- josef784 years ago
Memorable Member
I'm not licensing expert, but I think no.
-Even though technically and internaly is PBIRS composed of several components (Web Portal, SSRS, PowerBI and SSAS (in tabular diskless mode)) and SSAS is key performance component, from customer, installation and licencing point of view it is only one component = PBIRS. And all cores where PBIRS is running (regadless which internal componet uses which cores) must be licensed.
-By default PBIRS is running on all cores which is avaliable on machine. And you need licence for all cores where PBIRS can potentialy run.
-It is mean, if you have 8core machine, you need 8licences (4x 2pack). If you want limit number of cores, it must unavaliable on OS level (e.g. turning off in BIOS, or lower virtual cores on virtual machine).
-But with EE with SA you have two option how to licence. On virtual cores (for each core on virtual machine you need licence), or physical cores (for each physical core on physical machine you need licence, regardless number of virtual machines and total number virtual cores, which can be much more).
To second question, I'm not sure, but I think is not possible, but most importatntly it is not good way. Main difference between import mode and live connection mode is not technical backgroud (both is based on xVelocity engine), but developing cost and user learning path. For Import mode PBI, user need only Power BI Desktop RS, and average user, can produce nice PBI reports within ten minutes. But for Live connection mode, mean for design dedicated tabular model, which bring more opportunities (like much larger models, incremental update, multiple reports per model, and so on), you need advanced user, and need more developer tools (like visual studio or tabular editor) and much more SSAS experience. In my real practise, we have on PBIRS thousands Import mode small reports, but only tens dedicated SSAS models (but in total size much larger then all import mode reports. These are two way, for different approach, but both are correct. Yes, there is challenge how to balance performance, one option is to licence physical cores, and balance power between virtual machines using virtual cores, which you can change anytime.
- josef784 years ago
Memorable Member