See the article on the minimum requirements for askiavista here
This configuration is the baseline for askiavista clients - it simply hosts everything required on a single server.
However, this architecture also implies that both the survey data being served and askiavista's SQL databases are physically located on a server which is "on the web", which can be something clients prefer to avoid.
Note: for this configuration, you should not install SQL Server Management Studio on the server - only install the SQL engine. You can install SQL Server Management Studio on an other machine/server in order for you to administrate this server's SQL instance.
Standalone web application server
In this configuration, we have one server running both the AskiaVista .NET web application & the AVS engine, so there is no provision for load-balancing or failover.
However, both the SQL instance and the \AskiaQes\folder are better secured as they lie behind a firewall.
- The SQL Server instance can be firewalled away & secured.
- askiavista only requires the ability to establish a SQL connection string to the SQL Server instance.
- Bandwidth required for this SQL connection dialogue is minimal.
- \AskiaQes\, hosted on a NAS, SAN or other, can be firewalled away & secured
- askiavista only requires that its IIS_WPG user be granted Read/Write SMB access to the remote \AskiaQes\ repository.
Simple and Scale-out ready
In this configuration, we have one web-facing server running the \AskiaVista\ .NET web application, and another behind a firewall running askiavista's AVS engine.
More than improving security by pushing as many elements behind a firewall, the key aspect of this architecture is that it easily lends itself to be built-up into a big scale platform, ie. this architecture can be scaled up by adding load-balancing as well as failovers (as illustrated in by the next two sections: IV. & V.).
Scaled, load-balanced front+backends
In this configuration, we have two web-facing servers running the AskiaVista .NET web application - and therefore sharing the user connection/session load.
Behind the firewall we have two askiavista AVS engines sharing the \AskiaQes\ workload, ie. each AVS engine is responsible for its own set of surveys.
Scaled, load-balanced + failover
This configuration copies the above IV., but adds two failover AVS engines. Such failover instances shadow their parent AVS, and seamlessly take over should the parent AVS not respond, thereby ensuring that the users have an optimal experience on the askiavista platform.