Forum Discussion
Report Server architecture and licensing question
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.
Memorable Member1. 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
Memorable Member