How to Implement a Highly Available, High Performance BarTender Environment
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):