I am working on modifying DNN 4.9 to connect to multiple databases in order to power multiple sites from a single installation of DNN. Unfortunately we cannot use the portals solution because we have corporate requirements for data seperation (our clients also recieve backups of their databases on a regular basis and we cannot give the database of another client to them). We have a deployment process which keeps our clients all with the latest versions of whatever we are working on, but unfortunately it means that it currently takes about 5 mins to deploy to each client and install the latest modules (and the occasional DNN upgrade itself). Since we currently have one physical copy of DNN on the servers for each client, our deployment times are hovering around 2 hours right now (and we are expecting to have 8 times as many clients within the next year as we continue to bring in clients from an older system). We have some projects in the works which will cut our deployment times down to about 30 seconds per site (as we would no longer need to install modules), but we still will have multi-hour deployments (one advantage of the old system is that we have a <10 second deployment time).


The only way to speed up deployments is to get rid of the restriction that one directory on the webserver is tied to only one database and only serves one site and its portals. In order to do this I think we need to do two things:

1. modify the method Config.GetConnectionString to get the correct database connection string (we can call our IoC container here and get the actual connection string from a service that starts up on the first request to the site)

2. somehow modify something so that we are either using files from a different directory based on site location (eg if the virtual directory was dnn_c1 then use the folder dnn_c1_Portals instead of Portals for the portals folder) or (prefered) do not write any files to the webserver at all (skin and module installs are ok, because we can assure that if a file has the same name it is the same skin for two different clients).


Could anybody give some direction on what I am considering doing? I think the first item makes some sense, but nobody here is too sure about the second section. What areas would we need to modify?
 

We control the skins and the dlls that are installed for the clients and we manage the versions for their applications. All of them will always have all of the same skins, modules and dlls installed. We do update all of them at the same time. This is why we want to share the physical directory.

We also ultimately want to be able to have multiple web servers that are each connecting to any number of databases and serving for any number of sites.

Perhaps a picture would clarify things:

http://www.flickr.com/photos/16148317@N03/3152928823/in/set-72157611899142655/

We don't want to share application space, only physical space (eg all sites are located at c:\inetpub\dnn as the actual website folder). All virtual directories will be in their own app pools (well, 1 app pool per client; the linked image was portals on one level, then app pools then physical dirs then databases).

I am pretty sure that I can take care of the databases by replacing the contents of Config.GetConnectionString with the following:

Public Shared Function GetConnectionString() as String
    Return IoC.Resolve(Of ILocationInfo).ConnectionString
End Function

(we already have this interface locating another database that we need to connect to based on the website url)

This should take care of connection string issues simply by the fact that all websites are actually different locations. Unfortunately it doesn't take care of problems relating to files that have been written to the webserver. If Client1 creates a file with one name and Client2 creates a different file with the same name then I wind up with a conflict (suppose both upload an image for an html module on their homepage and they both call it home.jpg; or if both modify a language string that happens to be in the same file).

I think it could work if I were to ensure that each portal on each site was unique (ie site1 has portals 0,1 and 2, site2 has portals 3 and 4, site3 has portal 5 and site4 has portals 6 and 7). If I were to ensure that each site has unique portals then perhaps I can avoid nearly all file modifications; but I don't know the ramifications of not having a master portal available for each instance (ie the portalalias table would only have an entry for the specific portal for a particular site; site3 might have www.example.com/asdf linked to portal 5 and nothing would be linked to portal 0 for that database). What would be ramifications to doing this?

Our process for creating new sites would be:
1. visit the "empty" site as host
2. create portal "newsiteid"
3. make a copy of empty database and call it the newsiteid database
4. setup the information necessary to link the new location to the new database
5. make the new database think that the portal it is for is the host portal

Ultimately what we would end up with is a bunch of databases that are all copies from this original empty database and each have information about the portals created before them. The only question I guess is if information would bleed through from one portal directory to another.

The only issue this (as long as it would work) doesn't solve is the problem of actually writing files to the webserver at all. We want to be able to ultimately provide webfarm support for our clients without having a file server share (which is still a single point of failure) or doing replication and not to require a sticky session. We manage skins, modules and other things that can be installed on a site (and they are installed everywhere, 99% are developed in house).