Microsoft SQL Server and recording software
-
Good day all,
I’m working on a solution with a third party on a project for a client. Project is for call recording and live monitoring software. Third party wants to use call recording software from a firm called Crystal Quality (http://www.crystalrs.com/). Client has a main site and 4 branch offices. The system needs to be fully redundant and in case of a branch connection loss the main site needs to listen to recordings from the branch site that were made till the connection loss. Recording software supports Microsoft SQL Server and Oracle database. Third party proposed 2 servers on each location and 2 servers on the main site. I’m not much of a database expert so here are my doubts. We still haven’t received trial licenses for the recording software but from what I could tell the audio files are saved on the files system and only referenced paths are stored in the database. So what would be the best choice of action and what Microsoft SQL Server versions supports the scenario. We think to use a SQL active/passive cluster scenario on all sites with database replication or mirroring from the branch offices to the main site. Also we need to use DFSR replication or scripts to replicate audio files that are stored on the file system. We also need to make the recording software highly available but it has no by design mechanism for it so I haven’t used a non-Microsoft product in a NLB or cluster scenario. Is it possible to use Microsoft NLB or cluster for the recording software? I don’t know if the recording software needs to be Microsoft cluster or NLB aware for it to work? I don’t know if I provided enough information but any kind of help or input would be appreciated. -
I would think a clustered SQL farm with everything getting pushed to a central store would address the issue here.
The software uses SQL, that database can essentially reside anywhere. The software shouldn't know the difference (shouldn't care).
Of course this complicates the setup, are you going to have individual databases for each remote site, or just have one, and seed all of the information into one massive database?
The software vendor should provide you those details on what would be the best approach to do this.
-
Well i don't know if the network connectivity would be good enough to make a clustered SQL farm. I don't know the requirements for bandwidth and latency for SQL Server Multi-Subnet Failover Cluster. From what I could gather most likely scenario would be that the branches have their individual database and that their databases would be mirrored or replicated to the main site. Of course it would be easier to have one database but i don't know if it will be double. What kind of Microsoft SQL license would be required for any of these scenarios ? I also need to make the software highly available. Recording software will be installed on the main site and in each branch location. In each location the software needs to be highly available but it doesn't have any kind of feature by design. So can Microsoft NLB or cluster be used in this scenario and dose the software need to be aware of it for it to work ? Each site will have 2x Servers for redundancy.
-
NLB is for performance balancing, I believe it would address the need for HA.
And the SQL database still wouldn't care where the database resides (you'd point it to the cluster).
Which so long as the cluster is accessible you'd be protected from most failures, and the software wouldn't know the difference.
-
Are you stuck with this software? If not, start looking for other software packages that are designed for this situation.
The MS licensing is going to be huge for this. I think you'd have to have MS SQL Enterprise licensing. Why not look for solution that uses any of the number of Open Source Free DB Solution? Of course, finding a solution for your needs is the most important thing, so you might be stuck with SQL.
Does each location have it's own PBX and it's own telephone terminations? or do they all run through the main branch?
Take the rest of this with a grain of salt, because I've never clustered an app before.
don't you have to have cluster aware software to make that work?
Wouldn't you more likely have to work at the VM level to get HA and or Fault Tolerance?I'm going to let @scottalanmiller chime in. I'm way outside my depth.
-
@Dashrender said in Microsoft SQL Server and recording software:
The MS licensing is going to be huge for this. I think you'd have to have MS SQL Enterprise licensing. Why not look for solution that uses any of the number of Open Source Free DB Solution?
Sounded like they are not supported. Vendor only supports MS SQL and Oracle, pretty sad choices to be the "only" ones.
-
My first thought is that the recording software is not meeting your needs and have you evaluated looking at another option?
-
One of the first questions is... is the recording software stateless (other than the file serving needs?)
-
@djdanilo I would highly recommend looking at StarWind Virtual SAN.
With it you will be able to configure redundant storage pool. It will allow you to create a 2 node cluster at your branch office side and present synchronous storage pool to the cluster as a CSV. This way in case of a failure, your SQL server will simply migrate to the partner node and continue running, as for the storage, there will be 0 downtime since StarWind has synchronous active-active replication. -
@scottalanmiller said in Microsoft SQL Server and recording software:
My first thought is that the recording software is not meeting your needs and have you evaluated looking at another option?
Before you are going to buy 2 + (2*branch offices) SQL Server & Windows Server licenses and the required number of CALs, which would be a huge invest, you could at least try to
a) look for alternatives
b) talk to the vendor and ask them if they could implement other databases like MySQL/MariaDB or even a customer provided webservice to set and retrieve the paths. Webservices can be great to put a layer between a database and the application and let you choose your data backend yourself - even NoSQL DBs can be a choice in this case.
Better give the vendor a slice of your budget to implement another interface than to buy an insane amount of SQL Servers (which you will need to replace at some point in time, increasing costs even more) -
Good day,
I've been out of the country working on a project so I couldn't replay immediately. Thank you for suggestions.
Unfortunately we are stuck with the software and the databases it supports. When we get the trial license I'll try alternative databases because they were my first choice in the matter but we will probably lose support and warranty. Each site will has a PBX so all branch offices will be autonomous in that way. Because the time frame is short vendor can't implement anything. StarWind Virtual San is a good solution for the SQL redundancy and in that way we could cut cost on the SQL licenses and maybe the recording application can be done in the same way. I've been looking at Xen and DRBD but because I've only done that in my lab I'm not confident enough to propose that solution. If we go down the path of virtualization and distributive replicated storage I don't know to make the branch offices SQL servers available if the branch office loses network connectivity or something goes wrong. I guess the databases from each branch office can be replicated or mirrored to the main office and maybe even SQL express license will be sufficient for that. ButI don't have experience with MS SQL replication or mirroring. Also there is one more problem with virtualization because that software requires a PCI express card on each server for redundancy that is used for recording the analog lines. I don't know if it's possible to represent both cards to a single VM where the recording software resides and what drivers are available for it. Of course I'll test every solution in a lab environment and see in what I'm confident enough to do. -
DFS-R has issues with a distributed locks (it got none actually, need expensive third-party software to do bolt-on) so I'd recommend something less complicated
-
Wow - this is a very heady project. I'm slightly envious of your getting to work on it, but mostly not because of my complete lack of experience or knowledge in the space.
You have some pretty high end demands/requirements. Just making copies of the SQL DB at the branches available at HQ regardless of branch status is not a simple task. Now you've just tossed on the fact that you need to rely on legacy hardware (Analog phone cards) and maintain - is it HA or FT or both?
