Colocation of macola server

[MacolaHelp]

Has anyone else done the colocation option since I last asked in April 04? (see thread639-822079) We are looking at putting a number of servers at a site about 100 miles away and using dumb terminals to connect to the colo site. The remote host would take care of all server maintenance and update issues to the hardware. The macola user count is only 5. We are currently on pervasive but are willing to switch to sql. Any insight is appreciated.

 

[NEmacGuy]

I have several clients that are hosts for other locations, and had one client that was running off a remote host.

The client that was running off a remote host :
Their parent company was in California and we are on the east coast (not likely to apply at all to you) - only major issue were printing problems from time to time. A few time one side lost their internet connection, and then no macola. Both sides had T1's and DSL was already around - I had advised to add redundent means of communication such as DSL, ISDN, or a dial up modem on each side for fail over.
Largest issue was lack of customer service from their parent company with issues such as 7am EST is 3 or 4am PT and their parent should have had IT availible but didn't. They ended up switching back to a local enviroment.

Rest of our clients :
My client is the Host - printing is about the largest issue, several others like you may want the office suite and maybe adobe acrobat available to your macola. No problem right ? (Licensing, and will they work on a TS)

Curious what bandwidth do you have, and your host, and how reliable has it been ?

Did not mean to scare you, if I was in your spot I might give it a try, I would just want to know what I was getting into, and can you back out if it doesn't work to your liking?

 

[keain]

It should work without issue.

One thing to consider is uptime... I've done colos, not for Macola, but for networks that use other apps (MAS200, ACCPAC). In each case we put in redundant ISPs, and used a firewall capable of rolling over from one to the other. For example, one site used Time Warner Telecom. We also advised them to add a second ISP, and after much groaning about cost, they added USLec. USLec was a little bit cheaper in terms of cost/bandwidth, so they used that as their primary. One day USLec lost a router someplace in South Carolina and our client's connection to MAS dropped (the client's connection happened to use that route to get from their site to the datacenter). The firewall rolled over to the Time Warner Telecom circuit, people exited and reopened MAS, which restarted. They continued to use the Time Warner Telecom connection, even after the USLec route came back online.

Another thing, make sure there aren't piddly little things at the colo site you have to be responsible for. For example, if you colo with Time Warner Telecom, they have a generator that kicks in 30-45 seconds after a power failure. They do not supply a UPS to bridge that 30-45 seconds, the client is responsible for purchasing that. I was a little surprised by that.

Check to see what type of backup schedule they employ. I'd be surprised if they didn't, but see my note about the UPS above.

Make sure their aren't exorbitant early termination fees should your client decide it's not worth it.

Check to see if the colo is manned or not. Most things can be done in the data center remotely, but I always feel more comfortable if there's a physical body somewhere in the same building as the servers, just in case something should go horribly wrong.

 

[AKPolarBear]

I don't have collocated servers but have thought of that as part of some sort of disaster plan. We have about 10 users that are about 400 miles away that remote in from thinclients via VPN to the servers here. We are upgrading our system and now using W2K3 Terminal Servers and some new RDP thinclients. Much improvement in speed over current NT/Citrix Metaframe 1.8 system. Our other location, less than 100 miles by crow flight but 3 hours driving time is another story. The only DSL we could get is with the competitor to what we use at our other locations so they purposely route all the traffic through Seattle some 2500 miles away. All IP traffic must travel through the telco there in both directions even though we are physically located between the two competing wire centers here. That is a latency problem I can't overcome even with satellite service.
My thought on collocation was to image a server there every xx minutes or hours and let the routers determine when the primary system is down and switch the traffic flow to the alternate location as needed. Obviously, its more complicated then that but that was the overall thought process. We have instead set up two Terminal Servers with load balancing so if one crashes, the other can carry the load. Redundant IP did not work out for us at the time so we have none at the moment. We have more problem with backhoes digging up the final leg of the fiber then actual loss of the main IP service. We use an IP that provides redundant service that was well tested last summer when both went down or were overwhelmed at the same time. We used fax and cell phone to continue the business operation from the remote site.

 

[DirectOne]

Put Citrix with the db in the colo and it will be fine. Printing in TS isn't as robust. Citrix optimizes bandwidth as well. You can also set a Citrix Farm for picking the least busy server when users connect.