Difference between revisions of "Hardware"
Line 9: | Line 9: | ||
* 160 GB hard-disk space | * 160 GB hard-disk space | ||
− | Most common, a '''virtualized environment''' is used for hosting the regify-provider software. We are fine on | + | Most common, a '''virtualized environment''' is used for hosting the regify-provider software. We also recommend you to use virtualization. We are fine on using hardware, but take care about a redundant solution. If you are using visualization, we recommend to use two different hosts to serve two regify-providers. |
Using two servers (with the above specification) together with a load-balancer are able to offer the service to a few thousands of regify-users with no problems. | Using two servers (with the above specification) together with a load-balancer are able to offer the service to a few thousands of regify-users with no problems. | ||
− | |||
== performance considerations == | == performance considerations == |
Revision as of 17:49, 26 July 2012
Contents
hardware prerequisites
server hardware
Currently, you need a server (physical or virtual) that is able to run the regify Provider Appliance based on CentOS6.
There are no additional hardware requirements to the server, but we recommend a minimum of
- quad-core processor
- 8 GB RAM
- 160 GB hard-disk space
Most common, a virtualized environment is used for hosting the regify-provider software. We also recommend you to use virtualization. We are fine on using hardware, but take care about a redundant solution. If you are using visualization, we recommend to use two different hosts to serve two regify-providers.
Using two servers (with the above specification) together with a load-balancer are able to offer the service to a few thousands of regify-users with no problems.
performance considerations
On normal usage, a single regify provider instance with up to date hardware is able to handle a few thousand users with no problem. But please respect, that the real capacity depends mainly on the way the regify provider is used. There are different scenarios that are heavily affecting the performance (like mass sending).
The overall performance depends on different factors:
- internet connection bandwith (the faster, the more performance)
- usage-level (some users may not use regify every day, others surely will)
- mass-sending (in that case, you need fast machines and Internet connection)
- redundant setup (usage of a loadbalancer allows you to easily scale the solution)
- database configuration (you can optionally run a separate MySQL cluster using replication)
- cryptographic functions (if needed, you can add standard PC's to add more cryptographic power)
Here you can find more information about the regify Provider Appliance.
networking traffic
As regify is not carrying the message content itself (it is transferred directly from the sender to the recipient using the existing e-mail infrastructure), the regify provider only needs to handle the regify related traffic like login information, keys and hashcodes, e-mail addresses etc. Upon this, it does not matter how big the regify message is.
There are three types of traffic on a regify provider:
- register one transaction -> ~7KB traffic
- open one transaction -> ~6KB traffic
- using the web-portal -> depends mainly on users behaviour
Please note that the measured traffic includes login and logout procedures. If you are sending a message to multiple recipients, the traffic will increase only very little. You also can reduce traffic by using the client Software Development Kit (SDK) which allows you to login once and then to register a few thousand messages in one session.
scalability
The regify-provider software is designed to get easily enlarged to fit grown needs of performance. The following options are available to boost performance by adding more hardware resources:
- add more webserver-instances using common load-balancer appliances
- add up to 10 cryptoserver-instances on each regify-provider on external hardware (standard PC's with Linux or Windows)
- use SQL load-balancing to spread database access to multiple servers (Master-Slave)
- add additional databases using Cross-Master replication
- outsource the e-mail sending jobs to dedicated servers
If you are planning a high performance solution, please feel free to contact us directly.
redundancy
To achieve best redundancy, we recommend you to set up at least two instances (real or virtual) on different physical hosts. To distribute the requests, a common load-balancer supporting session persistance will fit perfectly. Additionally, you should use two VPN routers to set up the two tunnels to the clearing-service. There are two VPN tunnels available for this.
vpn-router
Most IPSec compatible VPN routers will fit perfectly. It needs to be able to connect to Cisco VPN routers.
load-balancer
A load-balancer is not necessary, but highly recommended for a high redundant system. It needs to be able to
- work "session based" (route the same user to the same server)
- allow SSL offloading