We're in the process of moving our Tessy environment to new servers (Windows 2012 r2 paired with SQL Server 2014). In our existing environment the payment gateway service lives on its own server. Having since moved away from Transcend, we no longer require this particular server...so we're hoping to consolidate. In our environment this basically means either our REST/SOAP gateway server (or) tessitura db server.
I have asked Tessitura in the past if either location is more ideal and was told that either is fine so long as you have the resources. Though we do have ample scalable resources (virtual servers) and I like the idea of housing the pmt gateway on our rest/soap server overall, high on sale situations have potential to really slam the API...which leads me to believe that the database server may be a better location overall.
I plan on doing stress testing once all systems are configured, but am hoping to make a good informed decision before getting to that point.
All that said, I'm curious what ya'll's setup is like (and why)?
Thanks!
Hi Jason,
We keep our payment gateway on one of our API servers. My preference is to isolate SQL Server to its own VM whenever possible. For example, if you're just doing a quick check and you find CPU utilization is high on your database server, is it high because of SQL Server or because of some other service you're running on that server? Ideally, you don't want a mystery like that when it comes to troubleshooting and tuning SQL Server.
Likewise, if your API server is getting slammed in a public on-sale, it's a reasonable assumption that your database server is going to take a significant hit as well (i.e. placing it on the database server to alleviate pressure on the API server is not necessarily going to help in the overall scheme of things).
One other reason for this placement... We use Windows Server 2012 and 2012 R2 Datacenter edition primarily for unlimited virtualization rights for licensed hosts; however, another benefit is that you can add vCPUs and memory without taking the VM down (at least with VMware vSphere you can - I'm guessing that's possible on other virtualization platforms as well). Sadly, SQL Server Standard edition does not support this. So, we tend to allocate the maximum resources we can afford to the SQL Server VM. If a VM running APIs and other services are getting overwhelmed, we can dynamically add vCPUs or memory if necessary. This pretty much negates any benefit to placing the payment gateway on the database server VM for our environment (unless there are other benefits to combining the two that I'm currently not aware of).
Anyway, I hope that helps!