You indicated the EDI is in use, but not the specific terminal type. Keep in mind that each EDI server has a pair of registry keys that specify a primary and backup server, but neither of these would apply if the entire server is down (it would allow serve to assist with a service interruption between the EDI and print server (hence the best practice recommendation of always installing them together). If you terminals are Omega terminals, you may find that they are assigned to a specific print server with no option for a secondary or backup. If that is what you are using, I think you will likely run into issues there unless you have given modified the print server names in the Administrator to a CNAME as introduced in a hotfix to 8.3 here in the last year or so. The issue here is that the Omega is not interested in simply reaching a print server (if I recall correctly), it is interested in reaching the print server that it has been configured to reach. Perhaps the 404 error is the result of the DNS not having switched over quickly enough.
Perhaps a description of the components you are using and their configuration in the administrator would be helpful here (terminal type, print server name type - FQDN? CNAME? other?, and so forth...).
We are using Sharp MFP/MFD devices, using the built in OSA interface.
We have a single edi server running the edi service that all MFDs are pointing to.
We have a db server, and 2 print (queue) servers, q01 and q02, and one web server.
We have built a second server, edi2, but are not actively using it. We could point half our MFDs at edi2, but a load balanced solution for the previous reasons would be a better environment.
We do not have an edi service on each of the print servers - sounds like that we missed that in the best practice recommendation guide.
In testing, the load balanced address of edilb was set to forward http to edi or edi2. The test MFD pointing to the edilb address seemed quite happy accepting our swipe card authentication without fail, and listed jobs everytime. It was the selection of the job and the print option that resulted in the 404 error.
Does that answer the questions to help better explain our environment, to give a better answer?
Oh, not really sure how to answer you FQDN or CNAME question. The MFD/MFPs are programmed to point to the FQDN - the load balanced address of edilb. The LB will handle everything else - servers may be A or C name records, but they are not changing so DNS has no need to change - a service is either up or down.
Thanks for the details. Though I have not worked with the Sharp units personally, their overall workflow is similar to other iMFP units I have worked with. The workflow is pictured in the server installation guide (see page 7 - link) and shows the iMFP device reaching out to the iMFP server first (which is not the same as the EDI though they may be on the same box). That iMFP service functions as the single point of contact for all iMFP devices. The iMFP server then relays the information to the EDI server (which can be separated from the print server, but usually is not). The EDI server then talks to the print server (or backup server) as configured in the registry, and then I get a bit fuzzy on the exact path(s) it takes from there. My understanding and experience is that even though the authentication may take place against the print server (or backup server) assigned to the EDI service, the device ultimately winds up having to talk to the print server/SecureReleaseService to which it has been assigned as per the drop down in Release Stations > Printing > Print Server.
This is where the load balancing trail used to dead end (and may still) as Pharos did not support the use of CNAMES for the print servers in the past. Now, even though you cannot give two print servers the same name (the load balancer name), you could give them two CNAMEs and then use DNS to "automate" the failover from one print server to another. So if SharpDevice01 is pointed to q01-cname in the Pharos Admin and q01 goes down, DNS could update q01-cname to resolve to q02 instead of q01. At this point it has been too long for me to remember, but my recollection is that the device and/or print server cared about who it was connecting and prevented the system from functioning any further (in essence, SharpDevice01 says "hi print server/SecureReleaseService, I am supposed to connect to q01-cname" and q02 responds with "no, I am q02-cname" and the device then fails out in some way. SSL certs may make this more complicated as they not only have to reach the server but the cert also has to match. Pharos may be able to shed some more light on things, and or explain what the significance and necessity is regarding the print server association for the terminals. I expect it deals with the ability to assign scripts to print server events and/or to allow us to grant a measure of control over how the system functions (if I needed to log the interactions of the network terminal, it sure makes it easy not having to guess where the logs are being generated. Regardless, it would be nice to have the ability to assign a second print server to terminals in order to avoid the necessity of manually reassigning them.
All that said, I have commented on your original goals, and followed that up with some additional questions that may be useful (at least to us):
Your Initial Goals/Reasoning -
The advantage of putting multiple EDI servers behind the LB are:
1. If a servers fails then jobs are automatically redirected to the other servers.
--- This is not especially accurate, as the network terminal is simply reaching back down to retrieve a job list and is not capable of influencing where print jobs are stored/held (that is determined by the print server association at the popup printer/queue level).
2. When upgrades are needed then each server can be upgraded one at a time without interruption to service.
--- If your EDI servers are separate from your print servers, this sounds correct, but does not address redundancy when updating a print server.
3. Under times when there is heavy load due to a high number of user requests the service is able to evenly distribute requests across load balanced servers.
--- See my first question below - if you are running everything through a single iMFP server it is not really distributed to being with. Also, keep in mind that the communications between the device interface, the iMFP service, the EDI, and the Print server as basically nothing but text (print jobs are sent directly from the SecureReleaseService to the TCP port of the device).
- Which iMFP server are your devices pointed at and do you have more than one available (e.g. is it installed on edi and edi2)?
- Are your EDI and iMFP services on separate servers? If so, it sounds like you may still have a single point of failure in the iMFP service(s) before the EDI load balancing begins.
- When you get the 404 error, is it permanent until the server comes back up; if so, does changing the assigned print server in the Pharos Administrator as discussed above "resolve" the problem (remember the Change Control)?