I get the feeling this thread might run for a while... > -----Original Message----- > From: AOLserver Discussion [mailto:[EMAIL PROTECTED] Behalf > Sent: Tuesday, March 04, 2003 7:43 PM > > > Tomasz, et. al. > > I can think of a dozen different ways (maybe not soo many) to implement name based virtual hosting, and the choice really comes down to who you are and what you are trying to do.
Yep, and I personally think that trying to get one 'product'/'application' (whatever you want to call it) to do everything is starting to tread on dangerous ground: The danger being that an application that was once very good a few things, gains the capability to do lots of other whizzy things but ends up doing none of them particularly well. I personally think that where possible it is best split functionality out by server (or even machine) to allow them to be tuned to the n'th degree (both at a code and configuration level) for the specific purpose they are built for. This also reduces the need for some of those crazy internal interdependencies you hit which makes maintaining these systems a headache. However separate processes clearly tend not to be as tightly integrated as a single one - so there are of course, pros and cons of each. The solution you go for is likely to be based on which of the various considerations you mention is most important to you, and its unlikely (in practice anyway) that they are all going to be of equal priority. Also, don't forget that there are hardware appliances out there that perform many of the functions you are discussing - it all depends to some extent on how big (or rather full) you wallet is, So: (all, forgive me if I'm stating the obvious!) > Maybe you have and or want .... > 1. One machine and many completely different websites run for completely different users (requires high security isolation from server instance to another) As you suggest separate virtual machines gives you the isolation (security often comes down to good practice and the detail of configuration) > 2. One machine and machine completely different websites run for the same user (security not as important) AOLserver will do this with either name based virtual hosting or IP based virtual hosting > 3. One machine and many different websites but not completely independent websites? (may want to share code, db, and some images) Again AOLserver will do this for you (well certainly v4 from what I can tell), with various ways to share code, db and files > 4. Variations of 1-3 above but where you want high uptime for all servers and don't want one coming down to affect others? If you are serious about high uptime you want more than one machine to reduce the effect of hardware failure. To ensure that a site failing has the least effect separate processes for each site seems to be a solution, but that doesn't stop for example one of those processes turning rogue and consuming all the resources, rending the other processes unusable.... According to the hype AOLserver is fast, efficient and reliable - I've yet to put it into production so I can't yet verify whether this is the case or not. ;-) > 5. You're need to add/remove sites at runtime. I don't think AOLserver (4) allows you to do this out of the box, but there are C,Tcl and hybrid modules available that should. > 6. You want high uptime and so you have more than one machine at maybe more than one geographical location and you want all these to be running the same dynamic website. Again, there's more than one way to skin a cat. EdgeCaching, reverse proxy caching, source based traffic routing etc. etc. > 7. You want a reverse proxy to stitch together many independent technologies (tomcat, jboss, aolserver,apache, zeus/nuke,snmp management, bob's special little webserver) that each provide an html stream in their own process all under the same port 80 url) (nsvhr does this well.) I think there's room in this area for a whole suite of products to be born - I've got a couple of ideas for one or two of them - just need the time and the money to turn them into reality.... > Okay, a baker's 1/2 dozen of reasons for virtual hosting. There's probably at least as many that you haven't though of (don't get me wrong not a criticism at all - but someone out there is bound to be putting pretty much every permutation into practice) > Unless you need to share db or session information, or unless you have very small machines, I don't see AOLserver as the best way to provide most of these solutions. Though I've tried hard in the past to make it do so.... You have the upper hand on me here as I don't have the practical experience of AOLserver that you do, but if it performs as well as is claimed then, as you say, with the help of one or two well chosen friends it ought to be able to do the job most admirably. The question is do you really want to try and get AOLserver to do it all by itself (without external help)? > But between SQUID and Apache as reverse proxies and the Linux Virtual Server project, I think there are some great, almost industry standard ways to provide a lot of virtual hosting solutions. And with that comes documentation and books and developers that already grok this. Completely agree, as mentioned above there are other hardware and software load balancing, traffic directing, caching, port mapping appliances and applications out there. Some are free others cost $$$$$s > Having said that, I've never used SQUID to do this, I've only done the most rudimentary work with Apache. I've not used SQUID myself either (I've used hardware based reverse proxy caches instead CacheFlow, Nortel etc.) My experience with Apache has completely put me off it for any serious use (talking about version 1.x here not 2). The multi-process design does not lend itself towards high traffic performance, and whilst you can get it to do all sorts of weird and wonderful things (great for hackers and developers etc.) in one installation I came across just turning off the parsing for server side includes increase performance by 600% - up to the level that the multi-threaded NES/iPlanet gives you *with* SSI support. > And when I last checked on the LVS, it seemed wonderful, but I needed more of a cookbook, more of a put together solution than what was provided then. Always the problem with OpenSource in general, if you are lucky it will run out of the box, but you then need to start configuring it, recompiling it to enable the features you really want, which requires finding the whole tree of packages and libraries it depends on, and so on. Been through a certain amount of this recently with AOLserver itself on WIN32 - thanks mainly to Jamie R and various web resources I've got there in the end, but its certainly no 5 minute job. > My understanding of virtual hosting ala aolserver 4 is that it is like Apache's -- many completely independent websites all with one single point of failure. You can share code and maybe (not sure of this, or whether its intentional!) bits of the memory space. > Good for use of resources; maybe bad for uptime and maybe management. > Maybe bad for security too. > It seems as though Tomasz's option tries to provide for more complex websites that may want to share data. That's good! > I think it's good to provide the Apache level -- It's good because Apache does it and so it becomes a burden/faq not to provide it. But that maybe the only reason. I think its a common enough things to want to do - but we shouldn't get blinkered and fooled into thinking this is the *only* way to approach the problem - you may be better off in various circumstances turning off the inbuilt vserver functionality, and using an external friendly process to do that work for you. At least it is possible.. > Or maybe my coffee is just too cold and bitter this morning. Like my heart. hehe - change your blend! > I think it's more interesting to provide for the ability to create more interesting/sophisticated websites ala datasharing and reverse proxying and the load and geographical scaling (6 & 7) above. (CS/Engineer speaking now.) > More interesting, but does anyone need it? (mba speaking now) (btw if the answer is yes and you have fund$ my email address is [EMAIL PROTECTED]) me too! ;-) see above > I dunno (dominant (?) personality taking over once more) > > Fantasy time: > > I would love to know more (that means "get my hands in a gpl like way") of how AOL itself provides for high uptime with their AOLserver instances. Hear hear! >From my limited experience AOLserver is a very capable server, but for the newbie (like me) once you've got it up and running, other than the OpenACS (and my personal jury is still out on that one) there's a dearth of 'real' code out there to play with, learn from, use in conjunction with the core server. > What monitoring code, what reverse proxy code, what heartbeat code, what restart code is around and might be useful by the community. > Or I would try to work with the Linux Virtual Server project. > > Because that project apparently aims to be the industry standard (i.e. a > large user base, some commercial support across hw and docs) for > providing 6-7 in terms of > a) monitoring systems > b) heartbeats > c) restarts > d) failovers > e) reverse proxying at several levels, from the > Apache/SQUID/nsvhr-nssock method of just piping each byte through > an intermediate proxy, to a much more interesting and scalable > across many machines method of screwing around with the underlying > TCP packets' routing so that on a network wide basis, > webserver responses respond directly to the client browser and no > longer need to get piped back through the intermediate proxy. > (That's sort of like the nsunix trick, done through routing, > and so applicable to very large sites.) > What is the old saying about slicker than shit through a goose? > I mean, um, that's really cool. If it really works, I know, I just > know that we would all be walking around with groupies on our > elbows. Kinda heavyweight though for the simpler scenarios you mention > I'd love to see various AOLserver modules, documentation, admin pages, dbs set up to cooperate well with the Linux Virtual Server. Well Tomasz and I had an off-list discussion about some of the excellent ideals of his whole MiniACS project (not just the virtual hosting side of it). I've still not had the time to take a detailed look at what he's done, but it sounded great. My angle was that the OpenACS has many widely required, and pretty widely tested, mature chunks of Tcl code that would be useful to many AOLserver users (certainly newbies wanting to quickly pull a site together). e.g. user management, session management, API/Schema browsing, templating etc. etc. However they might not, (I certainly didn't) without fully understanding it want to take on the whole OpenACS framework to just get some of these fairly standalone pieces as separate Tcl modules. (PS. I've managed to grab the OpenACS session management stuff and get that working by itself - its about 20 of their Tcl files with some pretty minor changes - with a some cleaning up it could become a standalone Tcl module for AOLserver) Tomasz's angle was more or less the opposite, sort of, I forget now, different anyway, but equally valid. Sorry it was a while ago! No I remember, (T. correct me if I'm wrong!) MiniACS gives you an OpenACS-like framework to build you application in, but is much simplified, and also pulls in many of the operational functional features you need to build/maintain high traffic/high availability sites e.g. virtual hosting, integration with version control, site staging etc. > We'll never displace Apache, Grrr, we ought to be able to! Who wants to use any language other than Tcl anyway?! > but if we had a highly available, highly scalable server, Uh oh! You mean we haven't?! > I think we could get some interesting press and projects coming our way. what about $$? It would be nice if that came our way too (well my way anyway!) just my 2p'orth regards, Tim Moss SiteSpeed Ltd Email: [EMAIL PROTECTED] Website: http://www.site-speed.com This email contains information from SiteSpeed Ltd, which may be privileged or confidential. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us immediately. I. To remove yourself from this list: Send a message to "[EMAIL PROTECTED]" with the following text in the BODY of your message: signoff aolserver II. For a complete list of listserv options please visit: http://listserv.aol.com/ III. For more AOLserver information please visit: http://www.aolserver.com/
