How to implement a highly available, high performance BarTender environment Follow
Question
How to implement a highly available, high performance BarTender environment?
Answer
1. For end-users that require an implementation capable of high frequency, high speed printing, in a high availability (HA) environment, and be scalable, we would recommend something like the below configuration:
At least two physical servers should be in use for redundancy and load balancing reasons. For ultimate redundancy, you would have at least one server at two different physical locations.
The specification of each server should at least be running with an Intel Xeon quad core E5 processor with at least 8GB of RAM. A gigabit network connection is required, although dual gigabit is recommended; this again is for redundancy but also for performance reasons. Note that other customers HA printing requirements have all used a Xeon class processor, the more cores the better, and anywhere between 6GB - 18GB of RAM.
Windows Server 2016 or higher should be used in a clustered Virtual Machine (VM) environment. Either VMware or Hyper-V can be used as per the customer's preference. Each physical server should run at least two VMs for reasons of OS redundancy. Meaning that if Windows crashes in one VM instance, the other VM on the same physical machine will continue running thereby maintaining hardware redundancy and physical load balancing.
The physical servers could either be dedicated to BarTender Suite use, although if the spec of their server is truly Enterprise level (multiple CPUs and 32 GB or more RAM) capable of running multiple VMs doing other things, then a shared server may also be utilized. However, we recommend that physical storage should be reserved for BarTender Suite use if only to avoid time sensitive contention issues.
Assuming a centralized BarTender System Database (BTSDB) is to be used, then we would recommend that this is implemented in its own VM image and assigned its own physical storage array. This is important as we've seen database transaction bottlenecks accrue over time if the SQL database is located on a shared storage media item.
In each VM we recommend that you configure Printer Management so that the printer drivers used by BarTender are configured to run in ashared printer driver isolation (PDI) group. This means that printer drivers will run in their own isolated process outside of the Windows print spooler. Therefore, if a driver crashes it won't have the potential to crash the print spooler too, thus requiring the service to be manually restarted. If the isolated process crashes then the Windows spooler will automatically re-spawn it thus keeping the print capability running.
Optimal performance is for a BarTender instance per physical processor core. Therefore, if you have a quad-core physical CPU in the server, that runs two VM's that have a single dual core virtual CPU configured, then the optimal configuration is to run two BarTender processes in each VM. With the Integration Platform the Print Scheduler service will automatically scale the solution based on available hardware and demand.
2. With regards to the communication between BarTender and Seagull License Server, as you know, we offer a 72 hour grace period (since the last communication between BarTender and Seagull License Server) on which BarTender will continue to print even if the Seagull License Server isn't available for any reason. Further information on this grace period can be found in our technical document: Printer-Based Licensing.
If extra redundancy on the Seagull License Server side is required, you can find more information in our License Server Redundancy technical document.
Question
How to implement a highly available, high performance BarTender environment?
Answer
1. For end-users that require an implementation capable of high frequency, high speed printing, in a high availability (HA) environment, and be scalable, we would recommend something like the below configuration:
At least two physical servers should be in use for redundancy and load balancing reasons. For ultimate redundancy, you would have at least one server at two different physical locations.
The specification of each server should at least be running with an Intel Xeon quad core E5 processor with at least 8GB of RAM. A gigabit network connection is required, although dual gigabit is recommended; this again is for redundancy but also for performance reasons. Note that other customers HA printing requirements have all used a Xeon class processor, the more cores the better, and anywhere between 6GB - 18GB of RAM.
Windows Server 2008 R2 or higher should be used in a clustered Virtual Machine (VM) environment. Either VMware or Hyper-V can be used as per the customer's preference. Each physical server should run at least two VMs for reasons of OS redundancy. Meaning that if Windows crashes in one VM instance, the other VM on the same physical machine will continue running thereby maintaining hardware redundancy and physical load balancing.
The physical servers could either be dedicated to BarTender Suite use, although if the spec of their server is truly Enterprise level (multiple CPUs and 32 GB or more RAM) capable of running multiple VMs doing other things, then a shared server may also be utilized. However, we recommend that physical storage should be reserved for BarTender Suite use if only to avoid time sensitive contention issues.
Assuming a centralized BarTender System Database (BTSDB) is to be used, then we would recommend that this is implemented in its own VM image and assigned its own physical storage array. This is important as we've seen database transaction bottlenecks accrue over time if the SQL database is located on a shared storage media item.
In each VM we recommend that you configure Printer Management so that the printer drivers used by BarTender are configured to run in ashared printer driver isolation (PDI) group. This means that printer drivers will run in their own isolated process outside of the Windows print spooler. Therefore, if a driver crashes it won't have the potential to crash the print spooler too, thus requiring the service to be manually restarted. If the isolated process crashes then the Windows spooler will automatically re-spawn it thus keeping the print capability running. Note that PDI is supported in Windows Server 2008 onwards.
Optimal performance is for a BarTender instance per physical processor core. Therefore, if you have a quad-core physical CPU in the server, that runs two VM's that have a single dual core virtual CPU configured, then the optimal configuration is to run two BarTender processes in each VM. With the Integration Platform the Print Scheduler service will automatically scale the solution based on available hardware and demand.
2. With regards to the communication between BarTender and Seagull License Server, as you know, we offer a 72 hour grace period (since the last communication between BarTender and Seagull License Server) on which BarTender will continue to print even if the Seagull License Server isn't available for any reason. Further information on this grace period can be found in our technical document: Printer-Based Licensing.
Question
How to implement a highly available, high performance BarTender environment?
Answer
1. For end-users that require an implementation capable of high frequency, high speed printing, in a high availability (HA) environment, and be scalable, we would recommend something like the below configuration:
At least two physical servers should be in use for redundancy and load balancing reasons. For ultimate redundancy, you would have at least one server at two different physical locations.
The specification of each server should at least be running with an Intel Xeon quad core E5 processor with at least 8GB of RAM. A gigabit network connection is required, although dual gigabit is recommended; this again is for redundancy but also for performance reasons. Note that other customers HA printing requirements have all used a Xeon class processor, the more cores the better, and anywhere between 6GB - 18GB of RAM.
Windows Server 2008 R2 or higher should be used in a clustered Virtual Machine (VM) environment. Either VMware or Hyper-V can be used as per the customer's preference. Each physical server should run at least two VMs for reasons of OS redundancy. Meaning that if Windows crashes in one VM instance, the other VM on the same physical machine will continue running thereby maintaining hardware redundancy and physical load balancing.
The physical servers could either be dedicated to BarTender Suite use, although if the spec of their server is truly Enterprise level (multiple CPUs and 32 GB or more RAM) capable of running multiple VMs doing other things, then a shared server may also be utilized. However, we recommend that physical storage should be reserved for BarTender Suite use if only to avoid time sensitive contention issues.
Assuming a centralized BarTender System Database (BTSDB) is to be used, then we would recommend that this is implemented in its own VM image and assigned its own physical storage array. This is important as we've seen database transaction bottlenecks accrue over time if the SQL database is located on a shared storage media item.
In each VM we recommend that you configure Printer Management so that the printer drivers used by BarTender are configured to run in ashared printer driver isolation (PDI) group. This means that printer drivers will run in their own isolated process outside of the Windows print spooler. Therefore, if a driver crashes it won't have the potential to crash the print spooler too, thus requiring the service to be manually restarted. If the isolated process crashes then the Windows spooler will automatically re-spawn it thus keeping the print capability running. Note that PDI is supported in Windows Server 2008 onwards.
Optimal performance is for a BarTender instance per physical processor core. Therefore, if you have a quad-core physical CPU in the server, that runs two VM's that have a single dual core virtual CPU configured, then the optimal configuration is to run two BarTender processes in each VM. With the Integration Platform the Print Scheduler service will automatically scale the solution based on available hardware and demand. For Commander, in older versions, you'll need to configure a fixed number of processes that you want to run in the BarTender command handler. Of course they could choose to ignore and override the CPU core to BarTender process 1:1 ratio if so wished, it's just it would not lead to optimal performance.
2. With regards to the communication between BarTender and Seagull License Server, as you know, we offer a 72 hour grace period (since the last communication between BarTender and Seagull License Server) on which BarTender will continue to print even if the Seagull License Server isn't available for any reason.
Further information on this grace period can be found on our White Paper:
Licensing for Automation Editions
If extra redundancy on the Seagull License Server side is required, a second product key code would need to be purchased, so that you can contact an alternate Seagull License Server as well as the primary one (see screenshot from BarTender's configuration for this):
7 comments
Bart Deman
Is this usable for use with integration services (BT 2016 and onwards)? Say for example that I have two VM's, each VM residing on a different physical VM server. Could I simply run the BT integration on the both virtual machines or would this lead to collisions between both processes when polling for trigger files in the same directory?
Evan Quinn
I would also Like to know this about how two instances of bartender would poll against the same consumable files.
Fernando Ramos Miracle
ModeratorThe integration Platform has an option that you would need to activate informing it that more than one integration will be pulling files from that folder. Once that option is active there shouldn't be any sort of clash between those different integrations, even if they are looking for the same type of file.
Dev Ops
Is the bartender software windows cluster server aware ? are the bartender services setup in the windows cluster failover ?
Do you need to have windows cluster service running.
I would like to setup ha redundancy in AWS using availability zones
Noor Jahan
Our customer has bought 2 X 30 Enterprise automation licenses to run bartender in Windows Server 2-node cluster environment to have high available geo-redundant services. They are running bartender and license server in each node. So HA functionality is for license server only? But if there is 72 hour of grace period for license server what is the point to run two license server in HA fashion and pay double license fee? They could have run license server in a separate windows server and buy single license. Can you please let me know some use case of these HA environment.
peirong zhong
We have an integration service deployed on a windows server 2016. It is a VM with "Intel(R) Xeon(R) CPU E5-2640 v4 @ 2.40GHz" 8 socket and 16 virtual processors. 16GB memory.
We need to do a pressure test to see how many requests can be handled by one integration service. The test was not meet the expectation. We found the CPU is not fully used. Is there any method to optimize the service to fully use all the CPUs ?
thank you.
Magnus Olofstam
In our current setup we have 15 remote sites worldwide, connected to our HQ over VPN. However, each site have their own SLS2016 server in order to run independently in case of network latency and connection issues.
We are looking into replacing this solution with a central SLS2021, assuming that the 72 hour grace period should be enough to deal with temporary connection issues. How does SLS2021 handle a lot of requests from slow responding clients?
From the printing perspective, as far as I understand, the printing is performed first, and then the licensing check is performed afterwards. Could then the next printout potentially be delayed if the communication between BT and SLS runs slowly (or until the SLS is considered unavailable and BT enters "grace period mode").