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!
Unknown said: We're in the process of moving our Tessy environment to new servers [...] All that said, I'm curious what ya'll's setup is like (and why)?
We're in the process of moving our Tessy environment to new servers [...]
We've recently consolidated some of our servers as well, since they were all VMs on the same hosts anyway, and just moved the PGS service to the database server this morning. We are down to the db server and WebAPI server. Moving the seat service, PGS, and application services IIS sites to the db server has resulted in small, but noticeable performance improvements. We aren't missing the separate servers at all.
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!
Very true about resource utilization on database server...it's something to consider...
Actually the main reason I am leaning toward moving the payment gateway to the database server is because in prior load testing of our systems, high load eventually causes bottlenecking to occur at the SOAP/REST server long before the database server ever becomes "problematic".
SOAP/REST can really demolish CPU resources if given the opportunity and the application queue builds. Under a heavy load scenario, you could have a situation where the payment gateway is competing for the same resources as SOAP/REST, making the issue that much worse. Theoretically anyway. =)
'Course a bottleneck will occur somewhere at some point no matter how you shuffle things around.
Jason,
In our environment we segregate our servers by function. Database servers are only database servers and other applications are not installed upon them. We then have application servers dedicated to applications. There are several factors that go into why we isolate functions. 1., We can tune a server for its primary function for maximum performance. 2., We can assign priority of particular applications and separate Tier I, Tier II, and Tier III applications based on availability requirements, uptime commitments, etc. 3., If function is balanced properly and you have to reboot a server for some reason, it will not impact your other applications. Some servers end up performing a single function or serving a single application to meet both performance and uptime objectives.
As for Tessitura; we maintain a dedicated SQL server and a dedicated application server. The application server hosts all of the related applications for Tessitura, API gateway, Element Gateway, Seat Server, NScan Server, Prints Server. This configuration has worked well in our environment without any latency issues. Both servers run as virtual machines in VMWare.
Hope this helps,
David Lane
Dallas Symphony
From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Jason KaiserSent: Monday, February 09, 2015 2:33 PMTo: David E. LaneSubject: [Tessitura Technical Forum] Payment gateway home
This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Technical Forum. You may reply to this message to post to the Technical forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!
Does anyone know if Tessitura supports multiple payment gateways? If so I'm curious if anyone is running with multiple instances. If it does, one configuration option that I've been considering is housing a payment gateway on our internal-facing rest/soap server, and another on our external-facing rest/soap server. So effectively one gateway takes care of web transactions, the other client app transactions.
Tessitura does support multiple payment gateways. Several sites have done this by adding an additional CCSERVER_IP_ADDRESS and/or CCSERVER_PORT to T_DEFAULTS with a different TR_ORGANIZATION. This is the only way to configure which users connect to which Tessitura Payment Gateway service. Jason, in your case this would work because if you are separating web transactions, you could most likely add these rows using "Tessitura Web" as the parent table.
Some sites have done this because they wanted different processors for different TR_ORGANIZATIONS (such as org A on Element and org B on TranScend) but you could certainly keep the same configuration as well.
For sites that are freeing up a server/VM by moving away from TranScend and are considering where to host the Payment Gateway -- the database server is such a critical resource that I prefer not to host other components on that server/VM. I've seen situations where Tessitura components or other software have starved Microsoft SQL Server of critical resources (mostly RAM). There are also concerns with PCI-DSS v3.0 item 1.3.7 (PA-DSS v3.0 item 9.1) -- once you have a component where you are doing internet access from your database server, you have to be more careful. I believe the rules are mostly concerned with having a web server not be on the same server/vm as the database server, but I mention this because different auditors have different interpretations.
I really like the idea of breaking apart our web (external) and client (internal) transactions. If we did the tr_organization setup as mentioned (creating entries for Tessitura Web), is it as simple as that? (Ie does REST/SOAP services automatically start using the alternate payment gateway addresses, or does there need to be additional configuration on the REST/SOAP servers?)
This may have swayed me to get the gateway off of the DB server. I'll still stress test both scenarios (db vs rest/soap server) to see what the differences are in terms of resource utilization and throughput (checkouts)...just out of curiosity.
One more question: does the seat server support multiple servers as well? Could be interesting to do a similar setup with that...