I am using 1.3 version of Nop. In our deployment we need to have our DAL layer on one server, PL on another and possibly BAL yet on another.
My question is: what do I need to do to make sure that the projects (DataAccess, Common, CommerceStore) can still communicate if placed on different servers? Do I need web services to send data or is 1.3 version compatible with n-tier (different server) deployment? Please advise. Thank you.
n-tier deployment
- 59
- 323
- 06/01/2010
- United Kingdom
Hi,
Why do you need to do this?
N-tier was designed in the 90's to enable com components to scale.
These components were registered once on a server and that's it.
Whereas, dotNet can be resident multiple times on one machine.
So, for scaleability and resilience you should deploy int the following way:
DATABASE
You should deploy your database to a single data server.
You can consider making this dataserver resilient and scaleable using clustering.
However, you will need at least 3 servers to achieve any performance gains over
a single dataserver. There are numerous blogs about this, but this is a simple summary.
Alternatively, you could simply scale-up a single dataserver by buying a hefty dataserver,
and scheduling full backups regularly. These backups would be located on separate volume.
If you have physical access to the hardware (and lots of money) you would consider NAS.
This would allow data volumes to be split away from the RAID.
This is completely inappropriate for this scale of product though. We worked with Marks and Spencer
over a couple of years with their end-to-end implementation, and we simply implemented an Amazon
z-shop.
So, in summary, your best options are:
1) big dataserver, lots of backups, feed every transaction to a separate system to mop up any
transactions that may occur between a complete disaster, and the last backup.
CHEAPEST, and best for a hosted solution.
2) Or, implement a simple dual clustered data server for the ultimate resilience.
BEST in terms of resilience. But requires full version of SQL Server 2005 or 2008.
MORE EXPENSIVE, but no lost transactions, and peace of mind for the hosting company.
3) There are other options around using Hot Failover products like Sunbelt Double-Take etc.
But you will need top expertise and consultancy to implement this. (Like us maybe).
WEB FRONT END
This is the easy bit. Simply deploy the whole site to a web server, components and all.
make sure your data connection points to the database (whereever it is located) and you are away.
Introduce more web servers and load balance them as needed.
e.g. deploy the whole app to 3 web servers, and setup load balancing between them.
I do not know enough about NopCommerce yet to know if it relies on session variables, but even if
it does, simply deploy dotNet to accommodate this. A tiny bit more tricky, but nothing a hour reading
'ASP.NET Unleashed' wont resolve.
As regards load balancing, do not implement a software solution. If you can afford it, and your hosting
company have them (many do), use a Cisco Load Balancing switch.
Load balancing is simply a way to direct requests for your website to one of your webservers.
If your site does not require the visitor to come back to the same webserver each tine, then you would
use a 'Round Robin' solution. This is a random algorithm that selects one of your webservers at random.
Not particularly great, but very very simple.
Clear Load Balancing systems, can intelligently assess the load of a particular server in the array, and
direct the visitor to the server that is under the least load.
In reality, the cost of this clever stuff does not normally outway the cost of getting a few extra webservers.
Those clever load balancers can be quite expensive, and clever engineers who know how to set them up, are
even more expensive.
So, N-Tier is not needed. What you have is a deployment issue.
This can be resolved very cheaply using Microsoft Visual SourceSafe (MS VSS) and Shared deployment folders.
Crude but highly effective.
You simply make a change to your NopCommerce site configuration files, and let MS VSS deploy the changes to
wherever your files need to be located over FTP.
We would be really happy to provide a summary for any implementation you may need in the form of an
assessment and architecture document.
However, I hope this review will be enough to help anyone wondering how to make their site resiilient.
Very Best Regards
Steve
Why do you need to do this?
N-tier was designed in the 90's to enable com components to scale.
These components were registered once on a server and that's it.
Whereas, dotNet can be resident multiple times on one machine.
So, for scaleability and resilience you should deploy int the following way:
DATABASE
You should deploy your database to a single data server.
You can consider making this dataserver resilient and scaleable using clustering.
However, you will need at least 3 servers to achieve any performance gains over
a single dataserver. There are numerous blogs about this, but this is a simple summary.
Alternatively, you could simply scale-up a single dataserver by buying a hefty dataserver,
and scheduling full backups regularly. These backups would be located on separate volume.
If you have physical access to the hardware (and lots of money) you would consider NAS.
This would allow data volumes to be split away from the RAID.
This is completely inappropriate for this scale of product though. We worked with Marks and Spencer
over a couple of years with their end-to-end implementation, and we simply implemented an Amazon
z-shop.
So, in summary, your best options are:
1) big dataserver, lots of backups, feed every transaction to a separate system to mop up any
transactions that may occur between a complete disaster, and the last backup.
CHEAPEST, and best for a hosted solution.
2) Or, implement a simple dual clustered data server for the ultimate resilience.
BEST in terms of resilience. But requires full version of SQL Server 2005 or 2008.
MORE EXPENSIVE, but no lost transactions, and peace of mind for the hosting company.
3) There are other options around using Hot Failover products like Sunbelt Double-Take etc.
But you will need top expertise and consultancy to implement this. (Like us maybe).
WEB FRONT END
This is the easy bit. Simply deploy the whole site to a web server, components and all.
make sure your data connection points to the database (whereever it is located) and you are away.
Introduce more web servers and load balance them as needed.
e.g. deploy the whole app to 3 web servers, and setup load balancing between them.
I do not know enough about NopCommerce yet to know if it relies on session variables, but even if
it does, simply deploy dotNet to accommodate this. A tiny bit more tricky, but nothing a hour reading
'ASP.NET Unleashed' wont resolve.
As regards load balancing, do not implement a software solution. If you can afford it, and your hosting
company have them (many do), use a Cisco Load Balancing switch.
Load balancing is simply a way to direct requests for your website to one of your webservers.
If your site does not require the visitor to come back to the same webserver each tine, then you would
use a 'Round Robin' solution. This is a random algorithm that selects one of your webservers at random.
Not particularly great, but very very simple.
Clear Load Balancing systems, can intelligently assess the load of a particular server in the array, and
direct the visitor to the server that is under the least load.
In reality, the cost of this clever stuff does not normally outway the cost of getting a few extra webservers.
Those clever load balancers can be quite expensive, and clever engineers who know how to set them up, are
even more expensive.
So, N-Tier is not needed. What you have is a deployment issue.
This can be resolved very cheaply using Microsoft Visual SourceSafe (MS VSS) and Shared deployment folders.
Crude but highly effective.
You simply make a change to your NopCommerce site configuration files, and let MS VSS deploy the changes to
wherever your files need to be located over FTP.
We would be really happy to provide a summary for any implementation you may need in the form of an
assessment and architecture document.
However, I hope this review will be enough to help anyone wondering how to make their site resiilient.
Very Best Regards
Steve
