I have seen a similar arrangement. I typically I'm a big fan of the seapration model, which most people just think of as two files- one for interface and one for data. The reality is that there are many forms of the Separation model. The one which I am thinking of, in context to your question, is a solution which ran through four departments.
The developer was paranoid about server outages, so each department had their own server and hosted 'their' files- even though this was one contigeous system, so Sales would host the Contacts, Phones, Activities, tec table. Accounting would host Invoices, Invoice Line Items, etc.. No table was duplicated from file to file as they all related to each other.
These servers all physically sat next to each other with dual Gigabit ethernet connections (server to server communication was on a private 10.0.5.x LAN). This solution worked very well for years and to my knowlege is still in production. The 'efficency' loss of running accross the network seemed to non-existant, as I suspect the additional RAM, cachce, and CPU outweighed the slowness of the network (compared to a hard drive).
A way to test this theory with buying another server would be to install Parallels Server on your xServe. This would allow you to run two unique installations of FileMaker Server on the same physical box. Although we typically use Windows/ vmWare, we use virtualized machines every day and two virtual machines will out perform a single install 9 times out of ten. Since Intel built virtualization into that servies of Xeon processor, it runs very effeciently...
We have multiple offices and multiple FM Servers in separate cities, all with interlinked files for system-wide reports.
The issues I see which might affect your desired goal are these:
- The client needs to log into the system via the server address which they want to do the number crunching, and this may put the heaviest load on that server. It depends in part on which files are served together on each server. That server will likely still spike to 100%, but if most other clients are logged into files on the other server via the other server's IP address, that should still give some benefit, but real-world testing will be required to be certain.
- Clients which access data via one of the server IP addresses, and then during the same session open a file which reads a file they have open, but via a different stored IP address in a file's FileMaker Data Sources can trigger license conflicts which will shut down the client's FileMaker app. This is a significant problem for FM Advanced which is never multi-user licensed, and cleaning up the file data source lists to minimize such conflicts can be daunting.
- You will not be able to run these reports as Server-side scripts if the required files span multiple servers. Each server can only read its OWN files while running Server-side scripts. Scripts which require data from both servers will have to be run from a Client machine, which can see everything at once.
But it does work if you understand the limitations.
Thank yoiu both for your replies.
I'm not clear on item 2. If I have a VLA license, doesn't that apply to the client only? Why would having a client log into 2 FM servers cause a license conflict?
Regarding point 2 -- It's not the logging in that's at issue; it's this scenario:
- File 1 on Server A (IP address X.X.X.X) has a data reference allowing it to read data from or perform a script in File 2 on Server B (IP Z.Z.Z.Z).
- Client logs into File 2 via Server B. File 2 is now open via Z.Z.Z.Z.
- Without quiting FileMaker, the same client then opens File 1 at Server A's IP address.
- WhenFile 1 attempts to read data via its embedded data reference to File 2 via IP X.X.X.X, FileMaker's license conflict will kick in saying the same copy of FM is trying to open one file twice, because it's using 2 different IPs to read the same file.
As indicated, if you have enough licenses for FMPro and are using a VLA copy, this may be allowed, though it will still count as 2 VLs in use for each client where this occurs. (You can quickly run out of VLs if this happens.)
However, there is no VLA options for FileMaker Advanced, so a Developer using FMAdv would immediately be booted out of all files and FMAdv closes when this scenario occurs. Not only that, but FMAdv won't accurately report why it happened; it will report a conflicting license issue, but usually reports the wrong user as having the conflict because it is really the same user. When I encountered this the first time in a multi-server environment, ir reported a conflict with a IWP user, which is of course absurd since they aren't even using FM, just a browser. It took ages to figure out where the conflict arose.
Just be aware of the potential problem so that, if it bites you, you will know to troubleshoot the FileMaker Data References for IP conflicts.
Thnak you Stephen, now I understand, and it is good to know the limitation of FM Advanced.. Can I avoid the license conflict with the FMPro client if I alsways direct connections thru Server A?
You can try.
But image this scenario:
- Log into server A File 1 which has a data refernence to File 6 on Server B.
- Later you are in File 7 which is on Server B, though you got there from a file on Server A, and File 7 references File 6.
If the file reference in File 7 to File 6 is ONLY a relative link since they are on the same server, it should be OK. However, if the file reference is written as an IP link it will use the Server B IP, and then your conflict will trigger.
The best advice I can give to minimize this is to make sure that ALL file references from each file an every other file which is on the same server are relative (non-IP specific) references. Never leave IP references between files on the same server.
If you have never manually edited the data references, there is a good chance some old references exist which will cause trouble, especially if the files were started before FM7.
Thanks Stephen, I am familiar with the file references and the historical issues from the FM6 to FM7 upgrade. All of my current references are relative, I woudl just have to make the ones between servers, use IP.
I think that's about as good as it gets.
After a day of cleaning up data references in a converted system of 60+ files, the number of License conflicts has dropped to less than one per month, down from twice a week when we first upgraded to FM11.
FM11 is much stricter about counting these connections than 10 and earlier versions were.