|
cloning load balanced servers
I work on an application that runs on Windows 2003 servers. It's mainly comprised of web pages, some web services, and many COM+ applications.
Some of our clients have multiple web servers, and want to use Network Load Balancing to spread the load. Currently this means we have to install the application (it's a pretty manual process) on each machine, configure them identically, and keep their patches synchronized.
I know there are tools out there to help manage this sort of thing, but I've never used any of them. Would anyone care to make a recomendation?
Jason
Monday, February 9, 2004
You might find it easier to make a MSI package for your app to make the installation more automatic, and then possibly write a config app that could run on one of the servers to configure the settings amongst all of the servers.
What is the reason you app is such a manual process to install? Is it just to get more "consulting" dollars? If it is you can still get away with charging consulting dollars to install an app even if it makes use of an install routine (we do it all the time).
And to keep them synced with patches, if you mean Windows patches then you might want to look at Software Update Server from Microsoft - it is a local version of Windows Update where you can specify what updates to install on the servers.
Chris Ormerod
Monday, February 9, 2004
by 'patches', I mean patches to our application.
It's manual because we don't (or won't) take the time to develop an install process. Shortsighted, I know, but that's the way it is. We don't charge for the time it takes us to install and patch the application.
Jason
Monday, February 9, 2004
"It's manual because we don't (or won't) take the time to develop an install process. "
Thats your first step then.
"We don't charge for the time it takes us to install and patch the application."
Which is an even bigger reason to minimize the time you take to do installs - i.e. implement step 1.
We have a web site based application and we have always had an install routine, but the first few versions of it were pretty bad and we would often spend a week debugging a failed install - our latest iteration (which has probably been at least 1-2 months effort to develop) has now ensured we have a >95% success ratio, the savings in support has paid for the development of the install routine many times over.
Chris Ormerod
Monday, February 9, 2004
"Which is an even bigger reason to minimize the time you take to do installs - i.e. implement step 1."
I'm not sure it's a "no brainer" to write an installer. A lot depends on how complex it is to code up the installer, vs. how complex it is to do the work. At this point, our patching "system" involves copying all the files up that are already prepared by the build system.
Writing an installer here would: (a) slow down the build process, as it would take time to make the installer; (b) require significant investment in time to do it right and well; (c) open a whole new avenue of bugs to fix.
Take the example of trying to convince someone today that it's worth spending 20 or 30 hours on an installer, that saves you 30 minutes every month. You'll get your money back... in 5 years. If nothing goes wrong, and you never have to fix any bugs, and the app never evolves to require anything new from the installer that wasn't originally anticipated and coded for.
That's a tough sell. :)
Brad Wilson (dotnetguy.techieswithcats.com)
Monday, February 9, 2004
sounds like your installer should be something like (syntax below is all conceptual):
installer.bat
xcopy sourcefiles destfiles
or maybe
installer.build
<nant>
<target name="install>
<copy>
<fileset="named fileset">
</copy>
</target>
</nant>
mb
Monday, February 9, 2004
Brad,
If Jasons installs only take 30 minutes then yes writing an installer may not be worth it, but from the tone of his first post it definately didn't sound like his current manual process was that easy - hence his question here today.
And making an install, while it did take us all that work to begin with, now it is just 2 lines in our buildscript and an extra 6 minutes on the compile (which already took 40 minutes anyway)
But you are right, it isn't a complete "no brainer" to make an install program or not, but I am pretty sure from a support cost point of view it probably is, especially if they don't charge for installs. What if they need to fly accross the country?
Chris Ormerod
Monday, February 9, 2004
 Recent Topics
Fog Creek Home
| 
