Has anyone on this forum, deployed SSRS in Scale-Out deployment? Having 2 SSRS instances on different machines connect to one database?
I am trying to deploy 2 SSRS server loadbalanced to connect to one database which is hosted on SQL-Always On cluster.
However while configuring the reporting services, I do not find the 2nd server waiting to join the Scale-out deployment as mentioned in the Microsoft site -
https://msdn.microsoft.com/en-us/library/ms159114(v=sql.120).aspx
Fixed it Myself - It seems like you need to have the different instance names to make the scale out deployment work. You cannot have all the servers in scaleout deployment use default instances which is what I was doing. I installed another named instance on one server and I was able to join it to the scale-out deployment.
Related
I have been looking around for the best practices when setting up Microsoft SQL Server Reporting Services (SSRS) in AWS(Amazon Web Services) environment. We have two options
SSRS on EC2: We can launch an EC2 instance with SQL Server installed on it and then we can setup SSRS using Report Server Configuration Manager.
SSRS on RDS: We can add an option group for SSRS in RDS and that will enable the SSRS on RDS instance. We can set the limit of max memory % usage for SSRS while setting up SSRS option in RDS
I am looking for comparison between SSRS on EC2 vs SSRS on RDS in terms of security, performance or any other limitations/benefits of using any of these two options.
The entire reason AWS strived to provide SSRS support is due to the cries from Dev's.
I shouldn't take all the credit as MSFT China Support helped me get it going, manually automagically setting up SSRS on an EC2 prior to RDS offering the service.
Here is the script I wrote and if you take a look it's worth paying for the RDS service. If there is only one reason you go SSRS RDS, it's ease of use.
Before you read this answer, keep in mind I have SQL Reporting Server baked into an Amazon Machine Image (AMI). I can't have an Auto Scale Group (ASG) with a server that requires a 45minute install in its UserData (Bootstrap script).
Hence I have a pre-installed SSRS image and then restore the Reporting Config database over the top during the deployment. Here are the issues with that:
RSConfig generates a Dsn Connection String doesn't work
Resort to what I did if there's a blocker, take it as a Plan B. I've walked the path before...
I'm preparing a migration plan to migrate on-premises SQL Server to Azure. On our on-prem there are two sql instance (DevSQL01\Dev and DevSQL01\Demo) running on single VM. Can we create a same scenario on azure, i.e. can we create two SQL instance on a single Auzure SQL VM or is their any other option?
I know i can create a windows VM on Auzre and install SQL Server and create two instance manually, but i like to find out options like managed instance, elastic pool, etc.. has the feature to host named instance by default.
Forgive me if this is noob question, I just started exploring cloud technologies.
On all flavors of Azure SQL PaaS (Managed Instance, DTU-model, vCore, Serverless, Hyperscale) the concept of named instance does not exist. Your best option is a SQL VM where you can run SQL Setup and install multiple instances.
It seems you need it for development purposes, then you may want to install SQL Server Developer Edition to avoid licensing costs as mentioned here. If this will be a Production server, remember to balance memory usage across the two SQL Server instances and leave some memory for the operating system to avoid impact on the server performance.
We have a single MS Server 2012 for hosting our MSSQL 2014.
On the Server we already installed two instances of MSSQL 2014.
One for the productive Business-Applications and one instance for the development Databases.
Beside the MSSQL 2014 installation we need to setup the TFS2013.
My question is if it is a good thought to make an own instance for the TFS or if we should just use one of the existing instances (Probably the dev) to store the databases.
We would love to use another instance because we would like to isolate the TFS Databases (so a restart of the TFS SQL Service should not affect the prod dbs) from the rest. We know that the administration needed for three instances is bigger than for two but we can neglect that.
Will there be a big loose in performance with a third instance, or isnt it that dramatic?
To avoid some anwsers, there is no possibility to implement the TFS or MSSQL on an other server(Because we just don't have any free resources).
The Server is from the hardware POV suitable and because we're a small company there won't be that much connections to the DB's (40 Employees to the Prod Instance, 3-5 Developers connecting to the DEV and TFS Instances).
The data tier of your TFS installation does not require any restarts. It's just a database that's created on your SQL Server.
The application tier of TFS is where the real work happens. This is where your users connect to and where the Windows Service and IIS websites are running.
It is no problem to use a shared SQL Server instance for installing Team Foundation Server.
If you want more information on how to install TFS checkout the ALM Rangers documentation. We have just released a new version of the guide that can be found here.
I would install also on a separate instance because the development or the production databases may require an SQL Server services restart which will cause a TFS unavailability.
Also you don't want to give permissions to the developers on TFS databases (usually developers are requiring higher permissions on their development databases, e.g. sysadmin for backup/restore)
Recently, we have migrated a business application database to Amazon AWS SQL Server RDS. We have loved the flexibility of backup and scaling with the cloudified database, but we have need for writing reports for our gathered analytics data. Our in house data analyst is most comfortable using SQL Reporting Services. Normally, this is installed as a component with the SQL Server install, but we obviously do not have that option on RDS.
My question is, has anyone been able to successfully deploy and use SQL Reporting services with Amazon RDS?
What I have tried:
I attempted to spin up another EC2 instance, install "SQL Server Express with Advanced Services", and point SSRS to RDS, but it said that I had incompatible license types.
I plan on contacting the AWS team directly for this as well, but I thought that I would reach out to SO first to see if anyone has run into this. Thanks.
You might need to use a certain Microsoft-created "Amazon Machine Image", specifically the "SQL Server Optimized" AMI: Microsoft AMIs.
Another option would be to apply SQL Server SSRS containers, hosted on an EC2 VM, connected to RDS. There's a blog on Windocks.com that outlines steps to deliver configured containers for improved scalability (multiple SSRS containers), with simplified management.
I have successfully ran SSRS in Docker containers on Windows ECS/2 VMs for a while and just today came across a fresh out of the oven announcement from Amazon on running SSRS natively on RDS: https://aws.amazon.com/about-aws/whats-new/2020/05/amazon-rds-for-sql-server-now-supports-sql-server-reporting-services/?nc1=h_ls
I have a SQL box and a web box; the SQL box is close to capacity. I'd like to install reporting services and thought about installing it on a SQL instance i would install on the web box, and only use that instance for reporting services. Is this a good option? What pitfalls will I have if I try to do this?
It's recommended to not mix IIS and SQL on the same box. Because 0f different access patterns and security at least.
The fact your SQL box is close to capacity should set alarm bells ringing and big red flags waving. The Report Server databases are quite small, and I'd lie awake at night if I thought it would overload my your DB server
SO: Should SQL Server be on the same machine as your IIS installation?
If you just install the Reporting Services (SSRS) web piece this should be fine. SSRS comes in 2 sections, the web piece and the database catalog so you could have a web site run on the web server and the catalog database would live on you normal database server. You will need to manually configure SSRS through the SSRS configuration utility and specify the remote server name during the database set up.
The downside of this is that you would be required to purchase an additional SQL license for the web server, since an SSRS installation counts as a SQL instance, but you should be able to use a standard edition license to for both instances.
I didn't find a lot a great resources but the steps would be like this:
--install just SSRS (and Client tools to debug connection issues) on the web server
--run the SSRS configuration tool and configure the app pools, virtual directories
--in the same config tool in the database section just specify the remote SQL server and select "create database" and it will create the database for you and apply the permissions needed to the database instance.
One thing I have found to be kind of quirky about the SQL 2005 SSRS config tool is that you have to "apply" changes when it doesn't seem that intuitive, so beware.
Here's an OK link:
http://www.databasejournal.com/features/mssql/article.php/3573361/SQL-2005-Reporting-Services-Part-1.htm