Infrastructure Successes and Challenges?
We are a medical device manufacturing organization in the process of rolling out the Archer platform. We plan to have environments for development, UAT, production, DR and perhaps one other. Ultimately, we will deploy Enterprise, Policy, Risk Assessment, Incident Management, Vulnerability Management and Vendor Management solutions. As of now I do not have an accurate guess on number of concurrent users but expect it won't be more than 500 - 1,000, nor are we certain of the number of records. Based on this limited information, would any of you mind sharing stories of your successes and challenges with your infrastructure? I'm looking for information related to number of concurrent users, number of records, SQL database disk I/O, physical versus virtual infrastructure recommendations, network connectivity/bandwidth utilization observations, along with the ability to scale as growth occurs. Thank you in advance for your thoughts.
- Community Thread
- Forum Thread
- RSA Archer
- RSA Archer Suite
Have you reviewed the Performance and Sizing Guide for the version you are targeting to install? It's a very detailed guide that should answer most, if not all, of your questions.
Thanks Scott. Yes we’ve looked at the sizing guide and are interested in experiences of Archer customers related to what worked, what didn’t work and what other things we might consider.
Besides what the sizing guide says here are some things that I have learned over the last 10 years or so in various roles\capacities.
In my experience I would say go big or go home. You can almost never have too much horsepower. Take your budget and spend what you can on a lot of database horsepower. I would also suggest a physical SQL server. I have only seen a few good virtual SQL servers, as some companies just don't know how to size a virtual machine properly or have the physical hardware behind the scenes to support the number of VM's.
The web servers can be virtual and operate just fine from a performance perspective. Get enough VM's to run several job engines that don't serve web traffic. This is so you don't have to run the job engines on the web servers. If you are planning any kind of API's or large datafeeds I would also suggest a dedicated box for those activities if you have budget.
Faster CPU clock speeds with fewer cores are much better than more cores and slower clock speeds with Archer. You need the highest clock speed and the most cores you can afford as that will allow everything to process quickly rather than a little slower across multiple threads.
When it comes to the number of web and job engine servers this is strictly up to you, your usage and expectations on performance. Just keep in mind your companies environment when it comes to getting additional VM's or hardware. If its pretty easy to spin a VM up if you reach a threshold you could probably start with a smaller environment. If it takes weeks and high level budget approval I would again loop back to what I said at the beginning, "Go Big or GO Home". The worse part is when you are implementing something and you run in to threshold where you need additional hardware.
Bob said it exactly right! Absolutely don't scrimp on the SQL server - and get the fastest network connections and high spindle speeds for where your data resides. We opted to go with physical machines for the services servers because we will be running a lot of data feeds.