locked
Multiple Branch Offices RRS feed

  • Question

  • Hi All,

     

    I have an app that needs to be used in multiple branch offices by 25 users on average. The application is built using c# with a thin client front end and Sql server 2005 for back end. What would be the best way to get the data back to HQ?  

    I could pop servers at each location and replicate the data down to HQ every night but would prefer to have a solution that pushed the data on a 10 min cycle back to HQ. Any thoughts on the way to go with this? From a network and application stand point how would you set something like this up?

     

    Thanks,

    Jam

    Sunday, March 30, 2008 1:42 PM

Answers

  • I think replication is a good idea, you've not mentioned the load or volumes that the 25 users will be putting on the system so you may want to tailor the exact nature of the replication based upon the stresses the system will be under against how stale you are prepared to have the data at HQ. If the volumes are low enough you may also want to look at synchonization services, e..g. http://www.codeproject.com/KB/smart/takedataoffline.aspx

    Monday, March 31, 2008 1:27 AM
  • Yes replication is the solutoin for your requirements. We have had same type of applications deployed at 4 branch offices. We have configured two type of replications , Transactional for immediate data needs and for heavy and less important data we have schedule baseed snapshot replication. Right now we have establised sound VPN and requirements are bit changes and we are now porting this to smart client solution.

     

    Monday, March 31, 2008 6:14 AM
  • You could centralize the infrastructure at HQ and let Branch sites access the application via thin client. Thin client solutions include:

    -         Citrix

    -         Terminal Services to a server with a shared client

    -         Virtualize desktops and remote to the virtual desktops

     

    If the server infrastructure needs to be at Branch Offices the following could be used:

    -         replication of database information

    -         SAN solution replicating disk

     

    Monday, March 31, 2008 8:25 AM

All replies

  • I think replication is a good idea, you've not mentioned the load or volumes that the 25 users will be putting on the system so you may want to tailor the exact nature of the replication based upon the stresses the system will be under against how stale you are prepared to have the data at HQ. If the volumes are low enough you may also want to look at synchonization services, e..g. http://www.codeproject.com/KB/smart/takedataoffline.aspx

    Monday, March 31, 2008 1:27 AM
  • Yes replication is the solutoin for your requirements. We have had same type of applications deployed at 4 branch offices. We have configured two type of replications , Transactional for immediate data needs and for heavy and less important data we have schedule baseed snapshot replication. Right now we have establised sound VPN and requirements are bit changes and we are now porting this to smart client solution.

     

    Monday, March 31, 2008 6:14 AM
  • You could centralize the infrastructure at HQ and let Branch sites access the application via thin client. Thin client solutions include:

    -         Citrix

    -         Terminal Services to a server with a shared client

    -         Virtualize desktops and remote to the virtual desktops

     

    If the server infrastructure needs to be at Branch Offices the following could be used:

    -         replication of database information

    -         SAN solution replicating disk

     

    Monday, March 31, 2008 8:25 AM
  • Thanks for getting back to me on this.

     

     Ok now what if I had 50 branches with an avg 25-50 users a piece what would you recommend?  

     

    Jam

    Monday, March 31, 2008 12:01 PM
  • It's the volume and age of the data that are important. E.g 50 branches with 100 users each that only change 1 row per day you could merge via outlook express! Wink

     

    If you want a forward looking plan then I'd bite the bullet an invest some time looking at replication, as already mentioned you can mix and match the specific mechanisms to your needs. The idea of using Terminal Services is valid too, but I'm guessing the offices want to run independantly of any network drop? (Hence the replicating SAN reference). So basically I'm saying your non functional requirements are very important.

     

    Monday, March 31, 2008 1:05 PM
  • My only concern with replication is that if the database structure gets changed by maybe adding a table to sql server that

    this could lead to serious problems like losing all your data in database being replicated too. I just heard of this happening to a company and would need something a little more fail safe.

     

    but I'm guessing the offices want to run independantly of any network drop?

     

    by network drop you mean if the network goes down?

     

    Jam

    Monday, March 31, 2008 5:11 PM
  • bump

     

    Tuesday, April 1, 2008 5:44 PM
  • I believe what pkr meant by 'network drop' is your branch office looses network connection to home office, you still want the application working at branch offices without issue.

     

    Thats exactly why replicating the database with a SAN infrastructure would work.  Based on the volume and integrity of the data you want to tweak the rate at which replication occurs.  Too little interval will make the replication 'very chatty' and too long will make the data stale at home office.  I recommend pick a interval and do the initial deployment, that can be dialed up or down depending on how it behaves.

    Tuesday, April 1, 2008 5:59 PM
  •  

    Jam,

     

    I am in complete agreement with what the guys have said in here so far.

     

    Perhaps if I put this in a different way, if you were to use each branch office independently, and then wanted HQ to receive the updates from each branch, you'd have to perform some merging rules, and those could get quite involving.

     

    I believe that the replication solution was offered largely because it gets around a lot of those problems.

     

    You could send deltas of changes back and forth between the HQ and branch offices, assuming you wanted the changes to be sent from HQ back to the branch office.  I'd have to ask why you would make all HQ and branch offices a big distributed server, as that's a lot more complicated, and quite clearly would force one to think about a single centralised solution.  You may have a good reason for wanting this, but as yet, I didn't really see anything you said that suggested that that was the case?

     

    The reason that you were asked about the frequency of change, and the amount of data at each change is because there are many ways to make this work.  You could use MSMQ, and drop any delta changes into the queue, then when connectivity to HQ was available, the data would get sent.  That's quite a scalable solution, but would require a little more work than replication.

     

    As previously mentioned, if hardly any traffic was being generated then almost any solution could be used as the merging rules would probably be simpler, and the speed would be of lesser importance.  Realistically though, we don't expect it to be low enough traffic that you'd really be able to use outlook express!

     

    I hope this helps clarify a few points, and gets you asking the right questions,

     

    We're here when you do,

     

    Martin Platt.

     

    Tuesday, April 1, 2008 9:51 PM
  • Adding to what is been said here earlier, It will be a good idea to understand what kind of operations are more here. While looking for solutions we need to consider the following:

    1. What is the ratio of Read Vs Write operations?
    2. What kind of read operations are being performed? Are the users at branch offices going to read data related to their branch only or they will also be reading data from other branch offices (including HQ)?
    3. Do you have a reliable infrastructure in place? or there are infrastructure issues as well at either Branch office or HQ?
    4. Also you need to consider what is the response time you are looking at. Is it okay if the query results take little bit of extra time or they need to be instantaneous.

    Cheers

    Samir

    Wednesday, April 2, 2008 11:27 PM
  • To understand if decentralising infrastructure to branch locations is architecturally sound I think the following needs to be considered:

     

    1. Cost of centralised to decentralised. For example decentralising increases servers, licenses, support complexity and management.

    2. Can redundant network links be provided for redundancy? This adds more weight to centralising.

    3 Client requirements on network eg bandwidth and latency
    Sunday, April 6, 2008 3:44 AM